精准找客户---业务好帮手
by 精准找客户---业务好帮手
你好
linux-nvdimm(a)lists.01.org
很高兴认识你，你能收到我的电邮，说明你的邮箱在某些平台有公布， 比如：贵公司网站上，Facebook，论坛上，展会上，Twitter，领英，招聘网等
我们通过软件，把你的邮箱数据提取出来，然后通过邮件把我们的服务推送到你邮箱的 你能收到我们的电邮，那你也可以通过我们的软件推广你的产品
免费帮你查找潜在客户负责人邮箱，提供潜在客户邮箱或者网址即可
提供开发国外客户软件，输入产品名搜索，全球公司尽收眼底。如有针对性公司，无法找到负责人的，通过我的外贸软件，输入公司名，10秒钟内帮你挖掘到负责人邮箱，也许你会质疑，有这么神奇吗？可以给几个公司名我帮你免费查找。
联系我们： E-mail：salestrade86(a)hotmail.com Q Q: 2234340823
1 year, 1 month
[PATCH v9 0/7] Mark the namespace disabled on pfn superblock mismatch
by Aneesh Kumar K.V
We add new members to pfn superblock (PAGE_SIZE and struct page size) in this series.
This is now checked while initializing the namespace. If we find a mismatch we mark
the namespace disabled.
This series also handle configs where hugepage support is not enabled by default.
This can result in different align restrictions for dax namespace. We mark the
dax namespace disabled if we find the alignment not supported.
Changes from v8:
* updated patch 7 for addressing review feedback
Changes from v6:
* Formatting changes
Changes from v5:
* Split patch 3
* Update commit message
* Add MAX_STRUCT_PAGE_SIZE with value 64 and use that when allocating reserve block
* Add BUILD_BUG_ON if we find sizeof(struct page) > 64
Aneesh Kumar K.V (6):
libnvdimm/pmem: Advance namespace seed for specific probe errors
libnvdimm/pfn_dev: Add a build check to make sure we notice when
struct page size change
libnvdimm/pfn_dev: Add page size and struct page size to pfn
superblock
libnvdimm/label: Remove the dpa align check
libnvdimm: Use PAGE_SIZE instead of SZ_4K for align check
libnvdimm/dax: Pick the right alignment default when creating dax
devices
Dan Williams (1):
libnvdimm/region: Rewrite _probe_success() to _advance_seeds()
drivers/nvdimm/bus.c | 8 +--
drivers/nvdimm/label.c | 5 --
drivers/nvdimm/namespace_devs.c | 40 +++++++++---
drivers/nvdimm/nd-core.h | 3 +-
drivers/nvdimm/nd.h | 10 +--
drivers/nvdimm/pfn.h | 5 +-
drivers/nvdimm/pfn_devs.c | 110 +++++++++++++++++++++++++-------
drivers/nvdimm/pmem.c | 29 +++++++--
drivers/nvdimm/region_devs.c | 76 ++++------------------
include/linux/huge_mm.h | 7 +-
10 files changed, 176 insertions(+), 117 deletions(-)
--
2.21.0
1 year, 1 month
Change your password immediately. Your account has been hacked.
by linux-nvdimm＠lists.01.org
I greet you!
I have bad news for you.
11/06/2019 - on this day I hacked your operating system and got full access to your account linux-nvdimm(a)lists.01.org
It is useless to change the password, my malware intercepts it every time.
How it was:
In the software of the router to which you were connected that day, there was a vulnerability.
I first hacked this router and placed my malicious code on it.
When you entered in the Internet, my trojan was installed on the operating system of your device.
After that, I made a full dump of your disk (I have all your address book, history of viewing sites, all files, phone numbers and addresses of all your contacts).
A month ago, I wanted to lock your device and ask for a small amount of money to unlock.
But I looked at the sites that you regularly visit, and came to the big delight of your favorite resources.
I'm talking about sites for adults.
I want to say - you are a big pervert. You have unbridled fantasy!
After that, an idea came to my mind.
I made a screenshot of the intimate website where you have fun (you know what it is about, right?).
After that, I took off your joys (using the camera of your device). It turned out beautifully, do not hesitate.
I am strongly belive that you would not like to show these pictures to your relatives, friends or colleagues.
I think $700 is a very small amount for my silence.
Besides, I spent a lot of time on you!
I accept money only in Bitcoins.
My BTC wallet: 1PKQvF9qK3zuB8KVwmDVDUxtpUVfE1P6fp
You do not know how to replenish a Bitcoin wallet?
In any search engine write "how to send money to btc wallet".
It's easier than send money to a credit card!
For payment you have a little more than two days (exactly 50 hours).
Do not worry, the timer will start at the moment when you open this letter. Yes, yes .. it has already started!
After payment, my virus and dirty photos with you self-destruct automatically.
Narrative, if I do not receive the specified amount from you, then your device will be blocked, and all your contacts will receive a photos with your "joys".
I want you to be prudent.
- Do not try to find and destroy my virus! (All your data is already uploaded to a remote server)
- Do not try to contact me (this is not feasible, I sent you an email from your account)
- Various security services will not help you; formatting a disk or destroying a device will not help either, since your data is already on a remote server.
P.S. I guarantee you that I will not disturb you again after payment, as you are not my single victim.
This is a hacker code of honor.
>From now on, I advise you to use good antiviruses and update them regularly (several times a day)!
Don't be mad at me, everyone has their own work.
Farewell.
1 year, 1 month
Change your password immediately. Your account has been hacked.
by linux-nvdimm＠lists.01.org
I greet you!
I have bad news for you.
11/06/2019 - on this day I hacked your operating system and got full access to your account linux-nvdimm(a)lists.01.org
It is useless to change the password, my malware intercepts it every time.
How it was:
In the software of the router to which you were connected that day, there was a vulnerability.
I first hacked this router and placed my malicious code on it.
When you entered in the Internet, my trojan was installed on the operating system of your device.
After that, I made a full dump of your disk (I have all your address book, history of viewing sites, all files, phone numbers and addresses of all your contacts).
A month ago, I wanted to lock your device and ask for a small amount of money to unlock.
But I looked at the sites that you regularly visit, and came to the big delight of your favorite resources.
I'm talking about sites for adults.
I want to say - you are a big pervert. You have unbridled fantasy!
After that, an idea came to my mind.
I made a screenshot of the intimate website where you have fun (you know what it is about, right?).
After that, I took off your joys (using the camera of your device). It turned out beautifully, do not hesitate.
I am strongly belive that you would not like to show these pictures to your relatives, friends or colleagues.
I think $720 is a very small amount for my silence.
Besides, I spent a lot of time on you!
I accept money only in Bitcoins.
My BTC wallet: 1PKQvF9qK3zuB8KVwmDVDUxtpUVfE1P6fp
You do not know how to replenish a Bitcoin wallet?
In any search engine write "how to send money to btc wallet".
It's easier than send money to a credit card!
For payment you have a little more than two days (exactly 50 hours).
Do not worry, the timer will start at the moment when you open this letter. Yes, yes .. it has already started!
After payment, my virus and dirty photos with you self-destruct automatically.
Narrative, if I do not receive the specified amount from you, then your device will be blocked, and all your contacts will receive a photos with your "joys".
I want you to be prudent.
- Do not try to find and destroy my virus! (All your data is already uploaded to a remote server)
- Do not try to contact me (this is not feasible, I sent you an email from your account)
- Various security services will not help you; formatting a disk or destroying a device will not help either, since your data is already on a remote server.
P.S. I guarantee you that I will not disturb you again after payment, as you are not my single victim.
This is a hacker code of honor.
>From now on, I advise you to use good antiviruses and update them regularly (several times a day)!
Don't be mad at me, everyone has their own work.
Farewell.
1 year, 1 month
员工辅导与有效激励..
by 从牺
Message-ID: 3816540231811
From: =?2iptxha??= <linux-nvdimm(a)lists.01.org>
To: <rmyrruz(a)hak.com>
员工辅导与有效激励
培训时间/地点：2019年9月9~10日（星期一~星期二）/上 海
课程目标：
² 建立辅导部属的正确认知与观念，化管为教
² 掌握员工辅导实施的步骤与方法，提高员工辅导的有效性
² 掌握有效的日常行为激励要点，提高员工的工作积极性
课程特色：
本课程从管理领导角度出发，引导学习者认识到一个好的领导者就是一名出色的教练，化管为教。协助学习者掌握教练技术的基本要点，通过案例的研讨与分析使学员掌握教练技术在日常工作辅导中的运用技巧。运用行为冰山理论模型分析不同类型部属的辅导方法，并结合面谈技巧与行为激励技巧提升与强化辅导效果。
教学方式：
² 主题讲授
² 案例研讨
² 经验分享
² 提问互动
课程大纲：
1. 一流的教练是最伟大的领导者
1） 教练看人之大、用人之长
2） 教练技术与培训的区别
3） 教练式辅导的要点
² 协助确立目标，激发意愿动力
² 提供实践机会，予以行为影响
² 排除障碍盲点，引导心态建设
² 归纳提炼总结，鼓励运用尝试
2. 员工辅导（岗位在职训练）的实施要点与技巧
1） 工作辅导常见问题分析
2） 成年人的学习特性与辅导要点
3） 员工辅导的实施步骤
4） 如何辅导不同类型员工的方法与技巧
² 不愿发挥型
² 唐吉诃德型
² 理论优先型
² 老实守旧型
5） 教练技术GROW模型的运用技巧
² 目标确定（Goal）
² 事实分析（Reality）
² 选择方案（Option ）
² 激发意愿（Will）
6） 教练技术常用问话
² 你想要的目标是什么？它对你有什么意义？
² 是什么阻止了目标的达成？目前的现状如何？
² 发生了什么？对你有什么影响？
² 你打算这么做的原因是？那对你意味着什么？
² 是什么因素促使了这种改变？
² 从这件事中你了解了什么？感悟了什么？
3. 有效的激励技巧
1） 何谓有效的激励
2） 激励的基本理论与运用要点
² 需求理论在激励上的运用要点
² 公平理论在激励上的运用要点
² 期望理论在激励上的运用要点
3） 激励的三大方法
² 物质激励
² 恐惧激励
² 行为激励
4） 行为激励法五大法宝
² 肯定
² 尊重
² 关怀
² 赞赏
² 肯定
5） 行为激励的八大手法
² 榜样激励
² 目标激励
² 尊重激励
² 参与激励
² 关怀激励
² 竞争激励
² 赞赏激励
² 奖罚激励
4. 总结与Ｑ＆Ａ
讲师介绍：贾老师
曾历任顾问咨询公司总经理、集团公司人力资源总监、培训中心经理等职，具有多种背景体制企业经营管理工作经验，十多年人力资源与管理培训实务心得，专精于企业内人力资源管理与发展、管理领导技能及企业内部讲师养成的培训，注重简易与实效的工作方法。
授课以实务、启发见长，重视与学员间的互动与交流，使学员能够真正的“学有所得，得之能用”。
现 任：
交通大学海外教育学院特聘讲师
宝钢集团人才开发学院特聘讲师
复旦大学医学管理学院特聘讲师
财经大学MBA进修学院特聘讲师
主要学习研修：
历史、教育管理心理、工商管理
擅长课程：
《企业内讲师训练》、《企业内教育训练规划实务》、《人力资源管理与发展》系列课程、《管理与领导技能》系列课程等。
部分内训服务企业：
制造业：宝钢集团、中国石化集团、天正集团、凯士比泵、东风蓝鸟汽车、松下电器、新大洲本田、爱德士鞋业集团、惠尔浦电器、ABB变压器、松尾钢结构有限公司、金光（APP）集团、法国拉法基、唐纳森（亚洲）、德国博西华电器、联合利华、德国怡人工艺品（宁波）公司、中集（集团）远东集装箱有限公司、和成卫浴、奥迪斯西子电梯、东风康明斯发动机、恒力集团、威瑞工具、协鑫集团、华立集团、一胜百模具、新飞电器、中纺（股份）有限公司、 上海电气集团、美特斯邦威、上海电器科学研究所（集团）有限公司、恩斯克轴承、中海油、上海广电集团（SVA）、圣马纸业、爱普生（中国）、法国液化空气（杭州）有限公司、联合汽车电子、柳工机械股份、科世达-华阳汽车电器、敏实集团、英特普莱特（中国）装饰材料有限公司、日立电梯、上海耀皮玻璃、上海造船厂、天地科技股份公司、向兴集团、博世、沪东重机、三花集团、上海大众联合发展有限公司、东芝信息机器有限公司、金龙汽车、NGK（苏州）环保陶瓷有限公司、普旭真空设备国际贸易（上海）有限公司、耐落螺丝（昆山）有限公司、上海海立(集团)股份有限公司、申雅密封件有限公司
房产业：汤臣集团、置信房产、复星集团、金地集团、上房物业、永升旭日集团、上海保集集团、金茂集团、宏泉集团、上海万星房产、三盛集团、北京万科、仁恒地产、东合置业、中金集团、易居臣信房产、东渡集团、新城房产公司、南银物业
电子业：达丰电脑、英业达集团、中兴通讯有限公司、东方通信集团、波导股份有限公司、大唐电信、神州数码有限公司、上海欣泰通信技术有限公司、凯虹电子、华威电子、欧亚测量（徕卡）、华虹NEC、创值工业、东软集团、苏州三星电子、保力马科技、金斯顿芯片、达方电子、明基集团、泰金宝电子、峻凌电子、AMD、英顺达电子、贝岭电子、沪士电子、扬宣电子、广达电脑、上海仪表、扬名光学、楼氏电子、三原电缆、千欣仪器、爱威电子、德国巴鲁夫（上海）、四川长虹、上海天道启科
零售业：香港新世界百货、上海第一八佰伴、上海东方商厦、山东三联集团、上海联华超市、华地企业（集团）、永乐家电、苏宁电器、李宁体育、美津浓、百安居
信息业：盛大网络、上海电子商务管理有限公司、上海有线网络有限公司（上海热线）中国(上海)电信、中国移动、上海邮电通信、法国申美（上海）商品检验检测公司、中国(苏州)电信、湖北通信服务公司
医药业：新亚药业、百特医疗、宝龙药业、欧姆龙（中国）、信谊药业、中美史克、卫材（中国）药业、纽迪希亚制药、德国拜耳、南京鼓楼医院、上海中山医院、广州医学院第二附属医院
流通业：中国远洋运输（集团）、百岁物流、圣泽集团、上海图书进出口公司、上海大众集团、上海沪东集装箱码头有限公司、丹沙中福货运（DHL）、上气销售、上海恒荣货运有限公司、上海磁浮交通、台骅国际、中国国际航空、上海浦东国际集装箱码头有限公司、上海外高桥贸易进出口有限公司、上海东方远航物流有限公司、上海浦东国际机场
金融业：上海浦东发展银行、中国银行、新华人寿、生命人寿、交通银行、广州天河信用社、交银施罗德基金、国泰君安证券、建设银行
食品业：山东秦老太食品、海霸王食品、养生堂、东福集团、福喜食品、立顿茶、上海高扬国际卷烟公司、德之馨香料、上海烟草集团、不凡帝梅特勒糖果、中萃食品有限公司、农夫山泉、三得利啤酒、贝因美集团、浙江商源食品、统一集团、箭牌糖果
其 它：韦博英语、德勤会计事务所、上海兴国宾馆、中国电力投资集团、上海集成电路研究中心、上海文广新闻传媒集团（SMG）、秦山核电公司、上海人民广播电台、文新报业集团、上海现代设计集团、新华传媒集团、田湾核电公司、华映文化传媒、宝洁公司、上海证券报社
贾先生现为上海强思企业管理服务有限公司高级培训讲师。
授课形式：
知识讲解、案例分析讨论、角色演练、小组讨论、互动交流、游戏感悟、头脑风暴、强调学员参与。
报名详情：
收费标准：￥4000/人（含授课费、证书费、资料费、午餐费、茶点费、会务费、税费）
报名咨询电话：021-31261580 手机：18890700600 （微信同号）赵先生
在线咨询QQ/邮箱：6983436 (报名请回复索取报名表）
1 year, 1 month
[PATCH v8] libnvdimm/dax: Pick the right alignment default when creating dax devices
by Aneesh Kumar K.V
Allow arch to provide the supported alignments and use hugepage alignment only
if we support hugepage. Right now we depend on compile time configs whereas this
patch switch this to runtime discovery.
Architectures like ppc64 can have THP enabled in code, but then can have
hugepage size disabled by the hypervisor. This allows us to create dax devices
with PAGE_SIZE alignment in this case.
Existing dax namespace with alignment larger than PAGE_SIZE will fail to
initialize in this specific case. We still allow fsdax namespace initialization.
With respect to identifying whether to enable hugepage fault for a dax device,
if THP is enabled during compile, we default to taking hugepage fault and in dax
fault handler if we find the fault size > alignment we retry with PAGE_SIZE
fault size.
This also addresses the below failure scenario on ppc64
ndctl create-namespace --mode=devdax | grep align
"align":16777216,
"align":16777216
cat /sys/devices/ndbus0/region0/dax0.0/supported_alignments
65536 16777216
daxio.static-debug -z -o /dev/dax0.0
Bus error (core dumped)
$ dmesg | tail
lpar: Failed hash pte insert with error -4
hash-mmu: mm: Hashing failure ! EA=0x7fff17000000 access=0x8000000000000006 current=daxio
hash-mmu: trap=0x300 vsid=0x22cb7a3 ssize=1 base psize=2 psize 10 pte=0xc000000501002b86
daxio[3860]: bus error (7) at 7fff17000000 nip 7fff973c007c lr 7fff973bff34 code 2 in libpmem.so.1.0.0[7fff973b0000+20000]
daxio[3860]: code: 792945e4 7d494b78 e95f0098 7d494b78 f93f00a0 4800012c e93f0088 f93f0120
daxio[3860]: code: e93f00a0 f93f0128 e93f0120 e95f0128 <f9490000> e93f0088 39290008 f93f0110
The failure was due to guest kernel using wrong page size.
The namespaces created with 16M alignment will appear as below on a config with
16M page size disabled.
$ ndctl list -Ni
[
{
"dev":"namespace0.1",
"mode":"fsdax",
"map":"dev",
"size":5351931904,
"uuid":"fc6e9667-461a-4718-82b4-69b24570bddb",
"align":16777216,
"blockdev":"pmem0.1",
"supported_alignments":[
65536
]
},
{
"dev":"namespace0.0",
"mode":"fsdax", <==== devdax 16M alignment marked disabled.
"map":"mem",
"size":5368709120,
"uuid":"a4bdf81a-f2ee-4bc6-91db-7b87eddd0484",
"state":"disabled"
}
]
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar(a)linux.ibm.com>
---
drivers/nvdimm/nd.h | 6 ----
drivers/nvdimm/pfn_devs.c | 69 +++++++++++++++++++++++++++++----------
include/linux/huge_mm.h | 8 ++++-
3 files changed, 59 insertions(+), 24 deletions(-)
diff --git a/drivers/nvdimm/nd.h b/drivers/nvdimm/nd.h
index e89af4b2d8e9..401a78b02116 100644
--- a/drivers/nvdimm/nd.h
+++ b/drivers/nvdimm/nd.h
@@ -289,12 +289,6 @@ static inline struct device *nd_btt_create(struct nd_region *nd_region)
struct nd_pfn *to_nd_pfn(struct device *dev);
#if IS_ENABLED(CONFIG_NVDIMM_PFN)
-#ifdef CONFIG_TRANSPARENT_HUGEPAGE
-#define PFN_DEFAULT_ALIGNMENT HPAGE_PMD_SIZE
-#else
-#define PFN_DEFAULT_ALIGNMENT PAGE_SIZE
-#endif
-
int nd_pfn_probe(struct device *dev, struct nd_namespace_common *ndns);
bool is_nd_pfn(struct device *dev);
struct device *nd_pfn_create(struct nd_region *nd_region);
diff --git a/drivers/nvdimm/pfn_devs.c b/drivers/nvdimm/pfn_devs.c
index ce9ef18282dd..4cb240b3d5b0 100644
--- a/drivers/nvdimm/pfn_devs.c
+++ b/drivers/nvdimm/pfn_devs.c
@@ -103,27 +103,36 @@ static ssize_t align_show(struct device *dev,
return sprintf(buf, "%ld\n", nd_pfn->align);
}
-static const unsigned long *nd_pfn_supported_alignments(void)
+const unsigned long *nd_pfn_supported_alignments(void)
{
- /*
- * This needs to be a non-static variable because the *_SIZE
- * macros aren't always constants.
- */
- const unsigned long supported_alignments[] = {
- PAGE_SIZE,
-#ifdef CONFIG_TRANSPARENT_HUGEPAGE
- HPAGE_PMD_SIZE,
+ static unsigned long supported_alignments[3];
+
+ supported_alignments[0] = PAGE_SIZE;
+
+ if (has_transparent_hugepage()) {
+
+ supported_alignments[1] = HPAGE_PMD_SIZE;
+
#ifdef CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD
- HPAGE_PUD_SIZE,
-#endif
+ supported_alignments[2] = HPAGE_PUD_SIZE;
#endif
- 0,
- };
- static unsigned long data[ARRAY_SIZE(supported_alignments)];
+ } else {
+ supported_alignments[1] = 0;
+ supported_alignments[2] = 0;
+ }
- memcpy(data, supported_alignments, sizeof(data));
+ return supported_alignments;
+}
+
+/*
+ * Use pmd mapping if supported as default alignment
+ */
+unsigned long nd_pfn_default_alignment(void)
+{
- return data;
+ if (has_transparent_hugepage())
+ return HPAGE_PMD_SIZE;
+ return PAGE_SIZE;
}
static ssize_t align_store(struct device *dev,
@@ -302,7 +311,7 @@ struct device *nd_pfn_devinit(struct nd_pfn *nd_pfn,
return NULL;
nd_pfn->mode = PFN_MODE_NONE;
- nd_pfn->align = PFN_DEFAULT_ALIGNMENT;
+ nd_pfn->align = nd_pfn_default_alignment();
dev = &nd_pfn->dev;
device_initialize(&nd_pfn->dev);
if (ndns && !__nd_attach_ndns(&nd_pfn->dev, ndns, &nd_pfn->ndns)) {
@@ -412,6 +421,20 @@ static int nd_pfn_clear_memmap_errors(struct nd_pfn *nd_pfn)
return 0;
}
+static bool nd_supported_alignment(unsigned long align)
+{
+ int i;
+ const unsigned long *supported = nd_pfn_supported_alignments();
+
+ if (align == 0)
+ return false;
+
+ for (i = 0; supported[i]; i++)
+ if (align == supported[i])
+ return true;
+ return false;
+}
+
/**
* nd_pfn_validate - read and validate info-block
* @nd_pfn: fsdax namespace runtime state / properties
@@ -496,6 +519,18 @@ int nd_pfn_validate(struct nd_pfn *nd_pfn, const char *sig)
return -EOPNOTSUPP;
}
+ /*
+ * Check whether the we support the alignment. For Dax if the
+ * superblock alignment is not matching, we won't initialize
+ * the device.
+ */
+ if (!nd_supported_alignment(align) &&
+ !memcmp(pfn_sb->signature, DAX_SIG, PFN_SIG_LEN)) {
+ dev_err(&nd_pfn->dev, "init failed, alignment mismatch: "
+ "%ld:%ld\n", nd_pfn->align, align);
+ return -EOPNOTSUPP;
+ }
+
if (!nd_pfn->uuid) {
/*
* When probing a namepace via nd_pfn_probe() the uuid
diff --git a/include/linux/huge_mm.h b/include/linux/huge_mm.h
index 45ede62aa85b..36708c43ef8e 100644
--- a/include/linux/huge_mm.h
+++ b/include/linux/huge_mm.h
@@ -108,7 +108,13 @@ static inline bool __transparent_hugepage_enabled(struct vm_area_struct *vma)
if (transparent_hugepage_flags & (1 << TRANSPARENT_HUGEPAGE_FLAG))
return true;
-
+ /*
+ * For dax let's try to do hugepage fault always. If the kernel doesn't
+ * support hugepages, namespaces with hugepage alignment will not be
+ * enabled. For namespace with PAGE_SIZE alignment, we try to handle
+ * hugepage fault but will fallback to PAGE_SIZE via the check in
+ * __dev_dax_pmd_fault
+ */
if (vma_is_dax(vma))
return true;
--
2.21.0
1 year, 1 month
[ndctl PATCH v2 1/2] libdaxctl: fix the system-ram capability check
by Vishal Verma
When checking a daxctl device for system-ram capability, we needn't look
at the symlink resolution for /sys/bus/dax.../driver/module since the
driver in question may not always have an associated module, and could
be builtin instead.
Change the symlink we resolve to simply '/sys/bus/dax.../driver' and
since that too resolves to '.../kmem' in the system-ram case, the
rest of the check remains unchanged.
This is a pre-requisite to making daxctl-reconfigure-device work
correctly when the target mode's driver might be builtin.
Cc: Dan Williams <dan.j.williams(a)intel.com>
Reviewed-by: Dan Williams <dan.j.williams(a)intel.com>
Signed-off-by: Vishal Verma <vishal.l.verma(a)intel.com>
---
v2: Collect Reviewed-by tags
daxctl/lib/libdaxctl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/daxctl/lib/libdaxctl.c b/daxctl/lib/libdaxctl.c
index c0a859c..d9f2c33 100644
--- a/daxctl/lib/libdaxctl.c
+++ b/daxctl/lib/libdaxctl.c
@@ -406,7 +406,7 @@ static int dev_is_system_ram_capable(struct daxctl_dev *dev)
if (!daxctl_dev_is_enabled(dev))
return false;
- if (snprintf(path, len, "%s/driver/module", dev->dev_path) >= len) {
+ if (snprintf(path, len, "%s/driver", dev->dev_path) >= len) {
err(ctx, "%s: buffer too small!\n", devname);
return false;
}
--
2.20.1
1 year, 1 month
[RFC PATCH v2 00/19] RDMA/FS DAX truncate proposal V1,000,002 ;-)
by ira.weiny＠intel.com
From: Ira Weiny <ira.weiny(a)intel.com>
Pre-requisites
==============
Based on mmotm tree.
Based on the feedback from LSFmm, the LWN article, the RFC series since
then, and a ton of scenarios I've worked in my mind and/or tested...[1]
Solution summary
================
The real issue is that there is no use case for a user to have RDMA pinn'ed
memory which is then truncated. So really any solution we present which:
A) Prevents file system corruption or data leaks
...and...
B) Informs the user that they did something wrong
Should be an acceptable solution.
Because this is slightly new behavior. And because this is going to be
specific to DAX (because of the lack of a page cache) we have made the user
"opt in" to this behavior.
The following patches implement the following solution.
0) Registrations to Device DAX char devs are not affected
1) The user has to opt in to allowing page pins on a file with an exclusive
layout lease. Both exclusive and layout lease flags are user visible now.
2) page pins will fail if the lease is not active when the file back page is
encountered.
3) Any truncate or hole punch operation on a pinned DAX page will fail.
4) The user has the option of holding the lease or releasing it. If they
release it no other pin calls will work on the file.
5) Closing the file is ok.
6) Unmapping the file is ok
7) Pins against the files are tracked back to an owning file or an owning mm
depending on the internal subsystem needs. With RDMA there is an owning
file which is related to the pined file.
8) Only RDMA is currently supported
9) Truncation of pages which are not actively pinned nor covered by a lease
will succeed.
Reporting of pinned files in procfs
===================================
A number of alternatives were explored for how to report the file pins within
procfs. The following incorporates ideas from Jan Kara, Jason Gunthorpe, Dave
Chinner, Dan Williams and myself.
A new entry is added to procfs
/proc/<pid>/file_pins
For processes which have pinned DAX file memory file_pins reference come in 2
flavors. Those which are attached to another open file descriptor (For example
what is done in the RDMA subsytem) and those which are attached to a process
mm.
For those which are attached to another open file descriptor (such as RDMA)
the file pin references go through the 'struct file' associated with that pin.
In RDMA this is the RDMA context struct file.
The resulting output from proc fs is something like.
$ cat /proc/<pid>/file_pins
3: /dev/infiniband/uverbs0
/mnt/pmem/foo
Where '3' is the file descriptor (and file path) of the rdma context within the
process. The paths of the files pinned using that context are then listed.
RDMA contexts may have multiple MR each of which may have multiple files pinned
within them. So an output like the following is possible.
$ cat /proc/<pid>/file_pins
4: /dev/infiniband/uverbs0
/mnt/pmem/foo
/mnt/pmem/bar
/mnt/pmem/another
/mnt/pmem/one
The actual memory regions associated with the file pins are not reported.
For processes which are pinning memory which is not associated with a specific
file descriptor memory pins are reported directly as paths to the file.
$ cat /proc/<pid>/file_pins
/mnt/pmem/foo
Putting the above together if a process was using RDMA and another subsystem
the output could be something like:
$ cat /proc/<pid>/file_pins
4: /dev/infiniband/uverbs0
/mnt/pmem/foo
/mnt/pmem/bar
/mnt/pmem/another
/mnt/pmem/one
/mnt/pmem/foo
/mnt/pmem/another
/mnt/pmem/mm_mapped_file
[1] https://lkml.org/lkml/2019/6/5/1046
Background
==========
It should be noted that one solution for this problem is to use RDMA's On
Demand Paging (ODP). There are 2 big reasons this may not work.
1) The hardware being used for RDMA may not support ODP
2) ODP may be detrimental to the over all network (cluster or cloud)
performance
Therefore, in order to support RDMA to File system pages without On Demand
Paging (ODP) a number of things need to be done.
1) "longterm" GUP users need to inform other subsystems that they have taken a
pin on a page which may remain pinned for a very "long time". The
definition of long time is debatable but it has been established that RDMAs
use of pages for, minutes, hours, or even days after the pin is the extreme
case which makes this problem most severe.
2) Any page which is "controlled" by a file system needs to have special
handling. The details of the handling depends on if the page is page cache
fronted or not.
2a) A page cache fronted page which has been pinned by GUP long term can use a
bounce buffer to allow the file system to write back snap shots of the page.
This is handled by the FS recognizing the GUP long term pin and making a copy
of the page to be written back.
NOTE: this patch set does not address this path.
2b) A FS "controlled" page which is not page cache fronted is either easier
to deal with or harder depending on the operation the filesystem is trying
to do.
2ba) [Hard case] If the FS operation _is_ a truncate or hole punch the
FS can no longer use the pages in question until the pin has been
removed. This patch set presents a solution to this by introducing
some reasonable restrictions on user space applications.
2bb) [Easy case] If the FS operation is _not_ a truncate or hole punch
then there is nothing which need be done. Data is Read or Written
directly to the page. This is an easy case which would currently work
if not for GUP long term pins being disabled. Therefore this patch set
need not change access to the file data but does allow for GUP pins
after 2ba above is dealt with.
This patch series and presents a solution for problem 2ba)
Ira Weiny (19):
fs/locks: Export F_LAYOUT lease to user space
fs/locks: Add Exclusive flag to user Layout lease
mm/gup: Pass flags down to __gup_device_huge* calls
mm/gup: Ensure F_LAYOUT lease is held prior to GUP'ing pages
fs/ext4: Teach ext4 to break layout leases
fs/ext4: Teach dax_layout_busy_page() to operate on a sub-range
fs/xfs: Teach xfs to use new dax_layout_busy_page()
fs/xfs: Fail truncate if page lease can't be broken
mm/gup: Introduce vaddr_pin structure
mm/gup: Pass a NULL vaddr_pin through GUP fast
mm/gup: Pass follow_page_context further down the call stack
mm/gup: Prep put_user_pages() to take an vaddr_pin struct
{mm,file}: Add file_pins objects
fs/locks: Associate file pins while performing GUP
mm/gup: Introduce vaddr_pin_pages()
RDMA/uverbs: Add back pointer to system file object
RDMA/umem: Convert to vaddr_[pin|unpin]* operations.
{mm,procfs}: Add display file_pins proc
mm/gup: Remove FOLL_LONGTERM DAX exclusion
drivers/infiniband/core/umem.c | 26 +-
drivers/infiniband/core/umem_odp.c | 16 +-
drivers/infiniband/core/uverbs.h | 1 +
drivers/infiniband/core/uverbs_main.c | 1 +
fs/Kconfig | 1 +
fs/dax.c | 38 ++-
fs/ext4/ext4.h | 2 +-
fs/ext4/extents.c | 6 +-
fs/ext4/inode.c | 26 +-
fs/file_table.c | 4 +
fs/locks.c | 291 +++++++++++++++++-
fs/proc/base.c | 214 +++++++++++++
fs/xfs/xfs_file.c | 21 +-
fs/xfs/xfs_inode.h | 5 +-
fs/xfs/xfs_ioctl.c | 15 +-
fs/xfs/xfs_iops.c | 14 +-
include/linux/dax.h | 12 +-
include/linux/file.h | 49 +++
include/linux/fs.h | 5 +-
include/linux/huge_mm.h | 17 --
include/linux/mm.h | 69 +++--
include/linux/mm_types.h | 2 +
include/rdma/ib_umem.h | 2 +-
include/uapi/asm-generic/fcntl.h | 5 +
kernel/fork.c | 3 +
mm/gup.c | 418 ++++++++++++++++----------
mm/huge_memory.c | 18 +-
mm/internal.h | 28 ++
28 files changed, 1048 insertions(+), 261 deletions(-)
--
2.20.1
1 year, 1 month
[PATCH v4] libnvdimm: Enable unit test infrastructure compile checks
by Dan Williams
The infrastructure to mock core libnvdimm routines for unit testing
purposes is prone to bitrot relative to refactoring of that core.
Arrange for the unit test core to be built when CONFIG_COMPILE_TEST=y.
This does not result in a functional unit test environment, it is only a
helper for 0day to catch unit test build regressions.
Note that there are a few x86isms in the implementation, so this does
not bother compile testing this architectures other than 64-bit x86.
Cc: Jérôme Glisse <jglisse(a)redhat.com>
Cc: Jason Gunthorpe <jgg(a)mellanox.com>
Reported-by: Christoph Hellwig <hch(a)lst.de>
Signed-off-by: Dan Williams <dan.j.williams(a)intel.com>
Link: https://lore.kernel.org/r/156097224232.1086847.9463861924683372741.stgit@...
---
Changes since v3:
- Switch the Makefile operator from := to += to make sure the unit test
infrastructure is incrementally included.
Jason, lets try this again. This seems to resolve the build error for
me. I believe ":=" would have intermittent results in a parallel build
and sometimes result in other targets in drivers/nvdimm/Makefile being
bypassed. This has been exposed to the 0day robot for a day with no
reports.
drivers/nvdimm/Kconfig | 12 ++++++++++++
drivers/nvdimm/Makefile | 4 ++++
2 files changed, 16 insertions(+)
diff --git a/drivers/nvdimm/Kconfig b/drivers/nvdimm/Kconfig
index a5fde15e91d3..36af7af6b7cf 100644
--- a/drivers/nvdimm/Kconfig
+++ b/drivers/nvdimm/Kconfig
@@ -118,4 +118,16 @@ config NVDIMM_KEYS
depends on ENCRYPTED_KEYS
depends on (LIBNVDIMM=ENCRYPTED_KEYS) || LIBNVDIMM=m
+config NVDIMM_TEST_BUILD
+ tristate "Build the unit test core"
+ depends on m
+ depends on COMPILE_TEST && X86_64
+ default m if COMPILE_TEST
+ help
+ Build the core of the unit test infrastructure. The result of
+ this build is non-functional for unit test execution, but it
+ otherwise helps catch build errors induced by changes to the
+ core devm_memremap_pages() implementation and other
+ infrastructure.
+
endif
diff --git a/drivers/nvdimm/Makefile b/drivers/nvdimm/Makefile
index cefe233e0b52..29203f3d3069 100644
--- a/drivers/nvdimm/Makefile
+++ b/drivers/nvdimm/Makefile
@@ -29,3 +29,7 @@ libnvdimm-$(CONFIG_BTT) += btt_devs.o
libnvdimm-$(CONFIG_NVDIMM_PFN) += pfn_devs.o
libnvdimm-$(CONFIG_NVDIMM_DAX) += dax_devs.o
libnvdimm-$(CONFIG_NVDIMM_KEYS) += security.o
+
+TOOLS := ../../tools
+TEST_SRC := $(TOOLS)/testing/nvdimm/test
+obj-$(CONFIG_NVDIMM_TEST_BUILD) += $(TEST_SRC)/iomap.o
1 year, 1 month
Re: [RFC PATCH v2 16/19] RDMA/uverbs: Add back pointer to system file object
by Ira Weiny
On Wed, Aug 14, 2019 at 09:23:08AM -0300, Jason Gunthorpe wrote:
> On Tue, Aug 13, 2019 at 01:38:59PM -0700, Ira Weiny wrote:
> > On Tue, Aug 13, 2019 at 03:00:22PM -0300, Jason Gunthorpe wrote:
> > > On Tue, Aug 13, 2019 at 10:41:42AM -0700, Ira Weiny wrote:
> > >
> > > > And I was pretty sure uverbs_destroy_ufile_hw() would take care of (or ensure
> > > > that some other thread is) destroying all the MR's we have associated with this
> > > > FD.
> > >
> > > fd's can't be revoked, so destroy_ufile_hw() can't touch them. It
> > > deletes any underlying HW resources, but the FD persists.
> >
> > I misspoke. I should have said associated with this "context". And of course
> > uverbs_destroy_ufile_hw() does not touch the FD. What I mean is that the
> > struct file which had file_pins hanging off of it would be getting its file
> > pins destroyed by uverbs_destroy_ufile_hw(). Therefore we don't need the FD
> > after uverbs_destroy_ufile_hw() is done.
> >
> > But since it does not block it may be that the struct file is gone before the
> > MR is actually destroyed. Which means I think the GUP code would blow up in
> > that case... :-(
>
> Oh, yes, that is true, you also can't rely on the struct file living
> longer than the HW objects either, that isn't how the lifetime model
> works.
Reviewing all these old threads... And this made me think. While the HW
objects may out live the struct file.
They _are_ going away in a finite amount of time right? It is not like they
could be held forever right?
Ira
>
> If GUP consumes the struct file it must allow the struct file to be
> deleted before the GUP pin is released.
>
> > The drivers could provide some generic object (in RDMA this could be the
> > uverbs_attr_bundle) which represents their "context".
>
> For RDMA the obvious context is the struct ib_mr *
>
> > But for the procfs interface, that context then needs to be associated with any
> > file which points to it... For RDMA, or any other "FD based pin mechanism", it
> > would be up to the driver to "install" a procfs handler into any struct file
> > which _may_ point to this context. (before _or_ after memory pins).
>
> Is this all just for debugging? Seems like a lot of complication just
> to print a string
>
> Generally, I think you'd be better to associate things with the
> mm_struct not some struct file... The whole design is simpler as GUP
> already has the mm_struct.
>
> Jason
1 year, 1 month
