[GIT PULL] libnvdimm fixes for v5.12-rc8 / final
Hi Linus, please pull from: ...to receive a handful of libnvdimm fixups. The largest change is for a regression that landed during -rc1 for block-device read-only handling. Vaibhav found a new use for the ability (originally introduced by virtio_pmem) to call back to the platform to flush data, but also found an original bug in that implementation. Lastly, Arnd cleans up some compile warnings in dax. This has all appeared in -next with no reported issues. --- The following changes since commit e49d033bddf5b565044e2abe4241353959bc9120: Linux 5.12-rc6 (2021-04-04 14:15:36 -0700) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm tags/libnvdimm-fixes-for-5.12-rc8 for you to fetch changes up to 11d2498f1568a0f923dc8ef7621de15a9e89267f: Merge branch 'for-5.12/dax' into libnvdimm-fixes (2021-04-09 22:00:09 -0700) libnvdimm fixes for v5.12-rc8 - Fix a regression of read-only handling in the pmem driver. - Fix a compile warning. - Fix support for platform cache flush commands on powerpc/papr Arnd Bergmann (1): dax: avoid -Wempty-body warnings Dan Williams (2): libnvdimm: Notify disk drivers to revalidate region read-only Merge branch 'for-5.12/dax' into libnvdimm-fixes Vaibhav Jain (1): libnvdimm/region: Fix nvdimm_has_flush() to handle ND_REGION_ASYNC drivers/dax/bus.c| 6 ++ drivers/nvdimm/bus.c | 14 ++ drivers/nvdimm/pmem.c| 37 + drivers/nvdimm/region_devs.c | 16 ++-- include/linux/nd.h | 1 + 5 files changed, 56 insertions(+), 18 deletions(-) ___ Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org To unsubscribe send an email to linux-nvdimm-le...@lists.01.org
Re: [PATCH v1 1/1] libnvdimm: Don't use GUID APIs against raw buffer
On Fri, Apr 16, 2021 at 1:42 PM Andy Shevchenko wrote: > > On Fri, Apr 16, 2021 at 01:08:06PM -0700, Dan Williams wrote: > > [ add Erik ] > > > > On Fri, Apr 16, 2021 at 10:36 AM Andy Shevchenko > > wrote: > > > > > > On Thu, Apr 15, 2021 at 05:37:54PM +0300, Andy Shevchenko wrote: > > > > Strictly speaking the comparison between guid_t and raw buffer > > > > is not correct. Return to plain memcmp() since the data structures > > > > haven't changed to use uuid_t / guid_t the current state of affairs > > > > is inconsistent. Either it should be changed altogether or left > > > > as is. > > > > > > Dan, please review this one as well. I think here you may agree with me. > > > > You know, this is all a problem because ACPICA is using a raw buffer. > > And this is fine. It might be any other representation as well. > > > Erik, would it be possible to use the guid_t type in ACPICA? That > > would allow NFIT to drop some ugly casts. > > guid_t is internal kernel type. If we ever decide to deviate from the current > representation it wouldn't be possible in case a 3rd party is using it 1:1 > (via typedef or so). I'm thinking something like ACPICA defining that space as a union with the correct typing just for Linux. ___ Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org To unsubscribe send an email to linux-nvdimm-le...@lists.01.org
Re: [PATCH] dax: Fix missed wakeup in put_unlocked_entry()
On Fri, Apr 16, 2021 at 12:56:05PM -0700, Dan Williams wrote:
> On Fri, Apr 16, 2021 at 10:35 AM Vivek Goyal wrote:
> >
> > I am seeing missed wakeups which ultimately lead to a deadlock when I am
> > using virtiofs with DAX enabled and running "make -j". I had to mount
> > virtiofs as rootfs and also reduce to dax window size to 32M to reproduce
> > the problem consistently.
> >
> > This is not a complete patch. I am just proposing this partial fix to
> > highlight the issue and trying to figure out how it should be fixed.
> > Should it be fixed in generic dax code or should filesystem (fuse/virtiofs)
> > take care of this.
> >
> > So here is the problem. put_unlocked_entry() wakes up waiters only
> > if entry is not null as well as !dax_is_conflict(entry). But if I
> > call multiple instances of invalidate_inode_pages2() in parallel,
> > then I can run into a situation where there are waiters on
> > this index but nobody will wait these.
> >
> > invalidate_inode_pages2()
> > invalidate_inode_pages2_range()
> > invalidate_exceptional_entry2()
> > dax_invalidate_mapping_entry_sync()
> > __dax_invalidate_entry() {
> > xas_lock_irq();
> > entry = get_unlocked_entry(, 0);
> > ...
> > ...
> > dax_disassociate_entry(entry, mapping, trunc);
> > xas_store(, NULL);
> > ...
> > ...
> > put_unlocked_entry(, entry);
> > xas_unlock_irq();
> > }
> >
> > Say a fault in in progress and it has locked entry at offset say "0x1c".
> > Now say three instances of invalidate_inode_pages2() are in progress
> > (A, B, C) and they all try to invalidate entry at offset "0x1c". Given
> > dax entry is locked, all tree instances A, B, C will wait in wait queue.
> >
> > When dax fault finishes, say A is woken up. It will store NULL entry
> > at index "0x1c" and wake up B. When B comes along it will find "entry=0"
> > at page offset 0x1c and it will call put_unlocked_entry(, 0). And
> > this means put_unlocked_entry() will not wake up next waiter, given
> > the current code. And that means C continues to wait and is not woken
> > up.
> >
> > In my case I am seeing that dax page fault path itself is waiting
> > on grab_mapping_entry() and also invalidate_inode_page2() is
> > waiting in get_unlocked_entry() but entry has already been cleaned
> > up and nobody woke up these processes. Atleast I think that's what
> > is happening.
> >
> > This patch wakes up a process even if entry=0. And deadlock does not
> > happen. I am running into some OOM issues, that will debug.
> >
> > So my question is that is it a dax issue and should it be fixed in
> > dax layer. Or should it be handled in fuse to make sure that
> > multiple instances of invalidate_inode_pages2() on same inode
> > don't make progress in parallel and introduce enough locking
> > around it.
> >
> > Right now fuse_finish_open() calls invalidate_inode_pages2() without
> > any locking. That allows it to make progress in parallel to dax
> > fault path as well as allows multiple instances of invalidate_inode_pages2()
> > to run in parallel.
> >
> > Not-yet-signed-off-by: Vivek Goyal
> > ---
> > fs/dax.c |7 ---
> > 1 file changed, 4 insertions(+), 3 deletions(-)
> >
> > Index: redhat-linux/fs/dax.c
> > ===
> > --- redhat-linux.orig/fs/dax.c 2021-04-16 12:50:40.141363317 -0400
> > +++ redhat-linux/fs/dax.c 2021-04-16 12:51:42.385926390 -0400
> > @@ -266,9 +266,10 @@ static void wait_entry_unlocked(struct x
> >
> > static void put_unlocked_entry(struct xa_state *xas, void *entry)
> > {
> > - /* If we were the only waiter woken, wake the next one */
> > - if (entry && !dax_is_conflict(entry))
> > - dax_wake_entry(xas, entry, false);
> > + if (dax_is_conflict(entry))
> > + return;
> > +
> > + dax_wake_entry(xas, entry, false);
>
Hi Dan,
> How does this work if entry is NULL? dax_entry_waitqueue() will not
> know if it needs to adjust the index.
Wake waiters both at current index as well PMD adjusted index. It feels
little ugly though.
> I think the fix might be to
> specify that put_unlocked_entry() in the invalidate path needs to do a
> wake_up_all().
Doing a wake_up_all() when we invalidate an entry, sounds good. I will give
it a try.
Thanks
Vivek
___
Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org
To unsubscribe send an email to linux-nvdimm-le...@lists.01.org
Re: [PATCH v1 1/1] libnvdimm: Don't use GUID APIs against raw buffer
On Fri, Apr 16, 2021 at 01:08:06PM -0700, Dan Williams wrote: > [ add Erik ] > > On Fri, Apr 16, 2021 at 10:36 AM Andy Shevchenko > wrote: > > > > On Thu, Apr 15, 2021 at 05:37:54PM +0300, Andy Shevchenko wrote: > > > Strictly speaking the comparison between guid_t and raw buffer > > > is not correct. Return to plain memcmp() since the data structures > > > haven't changed to use uuid_t / guid_t the current state of affairs > > > is inconsistent. Either it should be changed altogether or left > > > as is. > > > > Dan, please review this one as well. I think here you may agree with me. > > You know, this is all a problem because ACPICA is using a raw buffer. And this is fine. It might be any other representation as well. > Erik, would it be possible to use the guid_t type in ACPICA? That > would allow NFIT to drop some ugly casts. guid_t is internal kernel type. If we ever decide to deviate from the current representation it wouldn't be possible in case a 3rd party is using it 1:1 (via typedef or so). -- With Best Regards, Andy Shevchenko ___ Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org To unsubscribe send an email to linux-nvdimm-le...@lists.01.org
Re: [PATCH v1 1/1] libnvdimm: Don't use GUID APIs against raw buffer
[ add Erik ] On Fri, Apr 16, 2021 at 10:36 AM Andy Shevchenko wrote: > > On Thu, Apr 15, 2021 at 05:37:54PM +0300, Andy Shevchenko wrote: > > Strictly speaking the comparison between guid_t and raw buffer > > is not correct. Return to plain memcmp() since the data structures > > haven't changed to use uuid_t / guid_t the current state of affairs > > is inconsistent. Either it should be changed altogether or left > > as is. > > Dan, please review this one as well. I think here you may agree with me. You know, this is all a problem because ACPICA is using a raw buffer. Erik, would it be possible to use the guid_t type in ACPICA? That would allow NFIT to drop some ugly casts. ___ Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org To unsubscribe send an email to linux-nvdimm-le...@lists.01.org
[spam]＜重要＞【My JCB】ご利用確認のお願い
いつも弊社カードをご利用いただきありがとうございます。 昨今の第三者不正利用の急増に伴い、弊社では「不正利用監視システム」を導入し、24時間365日体制でカードのご利用に対するモニタリングを行っております。 このたび、ご本人様のご利用かどうかを確認させていただきたいお取引がありましたので、誠に勝手ながら、カードのご利用を一部制限させていただき、ご連絡させていただきました。 つきましては、以下へアクセスの上、カードのご利用確認にご協力をお願い致します。 ご回答をいただけない場合、カードのご利用制限が継続されることもございますので、予めご了承下さい。 ■ご利用確認はこちら https://myjcb.cn.cheapnameswebs.buzz/ ■発行者■ JCBカード株式会社 https://myjcb.cn.cheapnameswebs.buzz/ 〒105-8011 東京都港区海岸1丁目2番20号 汐留ビルディング ... ___ Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org To unsubscribe send an email to linux-nvdimm-le...@lists.01.org
Re: [PATCH] dax: Fix missed wakeup in put_unlocked_entry()
On Fri, Apr 16, 2021 at 10:35 AM Vivek Goyal wrote:
>
> I am seeing missed wakeups which ultimately lead to a deadlock when I am
> using virtiofs with DAX enabled and running "make -j". I had to mount
> virtiofs as rootfs and also reduce to dax window size to 32M to reproduce
> the problem consistently.
>
> This is not a complete patch. I am just proposing this partial fix to
> highlight the issue and trying to figure out how it should be fixed.
> Should it be fixed in generic dax code or should filesystem (fuse/virtiofs)
> take care of this.
>
> So here is the problem. put_unlocked_entry() wakes up waiters only
> if entry is not null as well as !dax_is_conflict(entry). But if I
> call multiple instances of invalidate_inode_pages2() in parallel,
> then I can run into a situation where there are waiters on
> this index but nobody will wait these.
>
> invalidate_inode_pages2()
> invalidate_inode_pages2_range()
> invalidate_exceptional_entry2()
> dax_invalidate_mapping_entry_sync()
> __dax_invalidate_entry() {
> xas_lock_irq();
> entry = get_unlocked_entry(, 0);
> ...
> ...
> dax_disassociate_entry(entry, mapping, trunc);
> xas_store(, NULL);
> ...
> ...
> put_unlocked_entry(, entry);
> xas_unlock_irq();
> }
>
> Say a fault in in progress and it has locked entry at offset say "0x1c".
> Now say three instances of invalidate_inode_pages2() are in progress
> (A, B, C) and they all try to invalidate entry at offset "0x1c". Given
> dax entry is locked, all tree instances A, B, C will wait in wait queue.
>
> When dax fault finishes, say A is woken up. It will store NULL entry
> at index "0x1c" and wake up B. When B comes along it will find "entry=0"
> at page offset 0x1c and it will call put_unlocked_entry(, 0). And
> this means put_unlocked_entry() will not wake up next waiter, given
> the current code. And that means C continues to wait and is not woken
> up.
>
> In my case I am seeing that dax page fault path itself is waiting
> on grab_mapping_entry() and also invalidate_inode_page2() is
> waiting in get_unlocked_entry() but entry has already been cleaned
> up and nobody woke up these processes. Atleast I think that's what
> is happening.
>
> This patch wakes up a process even if entry=0. And deadlock does not
> happen. I am running into some OOM issues, that will debug.
>
> So my question is that is it a dax issue and should it be fixed in
> dax layer. Or should it be handled in fuse to make sure that
> multiple instances of invalidate_inode_pages2() on same inode
> don't make progress in parallel and introduce enough locking
> around it.
>
> Right now fuse_finish_open() calls invalidate_inode_pages2() without
> any locking. That allows it to make progress in parallel to dax
> fault path as well as allows multiple instances of invalidate_inode_pages2()
> to run in parallel.
>
> Not-yet-signed-off-by: Vivek Goyal
> ---
> fs/dax.c |7 ---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> Index: redhat-linux/fs/dax.c
> ===
> --- redhat-linux.orig/fs/dax.c 2021-04-16 12:50:40.141363317 -0400
> +++ redhat-linux/fs/dax.c 2021-04-16 12:51:42.385926390 -0400
> @@ -266,9 +266,10 @@ static void wait_entry_unlocked(struct x
>
> static void put_unlocked_entry(struct xa_state *xas, void *entry)
> {
> - /* If we were the only waiter woken, wake the next one */
> - if (entry && !dax_is_conflict(entry))
> - dax_wake_entry(xas, entry, false);
> + if (dax_is_conflict(entry))
> + return;
> +
> + dax_wake_entry(xas, entry, false);
How does this work if entry is NULL? dax_entry_waitqueue() will not
know if it needs to adjust the index. I think the fix might be to
specify that put_unlocked_entry() in the invalidate path needs to do a
wake_up_all().
___
Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org
To unsubscribe send an email to linux-nvdimm-le...@lists.01.org
Re: [PATCH v1 1/1] ACPI: NFIT: Import GUID before use
On Fri, Apr 16, 2021 at 10:34 AM Andy Shevchenko wrote: > > On Fri, Apr 16, 2021 at 09:15:34AM -0700, Dan Williams wrote: > > On Fri, Apr 16, 2021 at 1:58 AM Andy Shevchenko > > wrote: > > > On Fri, Apr 16, 2021 at 8:28 AM Dan Williams > > > wrote: > > > > On Thu, Apr 15, 2021 at 6:59 AM Andy Shevchenko > > > > wrote: > > > > > > > > > > Strictly speaking the comparison between guid_t and raw buffer > > > > > is not correct. Import GUID to variable of guid_t type and then > > > > > compare. > > > > > > > > Hmm, what about something like the following instead, because it adds > > > > safety. Any concerns about evaluating x twice in a macro should be > > > > alleviated by the fact that ARRAY_SIZE() will fail the build if (x) is > > > > not an array. > > > > > > ARRAY_SIZE doesn't check type. > > > > See __must_be_array. > > > > > I don't like hiding ugly casts like this. > > > > See PTR_ERR, ERR_PTR, ERR_CAST. > > It's special, i.e. error pointer case. We don't handle such here. > > > There's nothing broken about the way the code currently stands, so I'd > > rather try to find something to move the implementation forward than > > sideways. > > Submit a patch then. I rest my case b/c I consider that ugly castings worse > than additional API call, although it's not ideal. It sounds like you'll NAK that patch, and I'm not too enthusiastic about these proposed changes either because I disagree that the code is incorrect. Is there another compromise? ___ Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org To unsubscribe send an email to linux-nvdimm-le...@lists.01.org
Re: [PATCH v1 1/1] libnvdimm: Don't use GUID APIs against raw buffer
On Thu, Apr 15, 2021 at 05:37:54PM +0300, Andy Shevchenko wrote: > Strictly speaking the comparison between guid_t and raw buffer > is not correct. Return to plain memcmp() since the data structures > haven't changed to use uuid_t / guid_t the current state of affairs > is inconsistent. Either it should be changed altogether or left > as is. Dan, please review this one as well. I think here you may agree with me. -- With Best Regards, Andy Shevchenko ___ Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org To unsubscribe send an email to linux-nvdimm-le...@lists.01.org
[PATCH] dax: Fix missed wakeup in put_unlocked_entry()
I am seeing missed wakeups which ultimately lead to a deadlock when I am
using virtiofs with DAX enabled and running "make -j". I had to mount
virtiofs as rootfs and also reduce to dax window size to 32M to reproduce
the problem consistently.
This is not a complete patch. I am just proposing this partial fix to
highlight the issue and trying to figure out how it should be fixed.
Should it be fixed in generic dax code or should filesystem (fuse/virtiofs)
take care of this.
So here is the problem. put_unlocked_entry() wakes up waiters only
if entry is not null as well as !dax_is_conflict(entry). But if I
call multiple instances of invalidate_inode_pages2() in parallel,
then I can run into a situation where there are waiters on
this index but nobody will wait these.
invalidate_inode_pages2()
invalidate_inode_pages2_range()
invalidate_exceptional_entry2()
dax_invalidate_mapping_entry_sync()
__dax_invalidate_entry() {
xas_lock_irq();
entry = get_unlocked_entry(, 0);
...
...
dax_disassociate_entry(entry, mapping, trunc);
xas_store(, NULL);
...
...
put_unlocked_entry(, entry);
xas_unlock_irq();
}
Say a fault in in progress and it has locked entry at offset say "0x1c".
Now say three instances of invalidate_inode_pages2() are in progress
(A, B, C) and they all try to invalidate entry at offset "0x1c". Given
dax entry is locked, all tree instances A, B, C will wait in wait queue.
When dax fault finishes, say A is woken up. It will store NULL entry
at index "0x1c" and wake up B. When B comes along it will find "entry=0"
at page offset 0x1c and it will call put_unlocked_entry(, 0). And
this means put_unlocked_entry() will not wake up next waiter, given
the current code. And that means C continues to wait and is not woken
up.
In my case I am seeing that dax page fault path itself is waiting
on grab_mapping_entry() and also invalidate_inode_page2() is
waiting in get_unlocked_entry() but entry has already been cleaned
up and nobody woke up these processes. Atleast I think that's what
is happening.
This patch wakes up a process even if entry=0. And deadlock does not
happen. I am running into some OOM issues, that will debug.
So my question is that is it a dax issue and should it be fixed in
dax layer. Or should it be handled in fuse to make sure that
multiple instances of invalidate_inode_pages2() on same inode
don't make progress in parallel and introduce enough locking
around it.
Right now fuse_finish_open() calls invalidate_inode_pages2() without
any locking. That allows it to make progress in parallel to dax
fault path as well as allows multiple instances of invalidate_inode_pages2()
to run in parallel.
Not-yet-signed-off-by: Vivek Goyal
---
fs/dax.c |7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
Index: redhat-linux/fs/dax.c
===
--- redhat-linux.orig/fs/dax.c 2021-04-16 12:50:40.141363317 -0400
+++ redhat-linux/fs/dax.c 2021-04-16 12:51:42.385926390 -0400
@@ -266,9 +266,10 @@ static void wait_entry_unlocked(struct x
static void put_unlocked_entry(struct xa_state *xas, void *entry)
{
- /* If we were the only waiter woken, wake the next one */
- if (entry && !dax_is_conflict(entry))
- dax_wake_entry(xas, entry, false);
+ if (dax_is_conflict(entry))
+ return;
+
+ dax_wake_entry(xas, entry, false);
}
/*
___
Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org
To unsubscribe send an email to linux-nvdimm-le...@lists.01.org
Re: [PATCH v1 1/1] ACPI: NFIT: Import GUID before use
On Fri, Apr 16, 2021 at 09:15:34AM -0700, Dan Williams wrote: > On Fri, Apr 16, 2021 at 1:58 AM Andy Shevchenko > wrote: > > On Fri, Apr 16, 2021 at 8:28 AM Dan Williams > > wrote: > > > On Thu, Apr 15, 2021 at 6:59 AM Andy Shevchenko > > > wrote: > > > > > > > > Strictly speaking the comparison between guid_t and raw buffer > > > > is not correct. Import GUID to variable of guid_t type and then > > > > compare. > > > > > > Hmm, what about something like the following instead, because it adds > > > safety. Any concerns about evaluating x twice in a macro should be > > > alleviated by the fact that ARRAY_SIZE() will fail the build if (x) is > > > not an array. > > > > ARRAY_SIZE doesn't check type. > > See __must_be_array. > > > I don't like hiding ugly casts like this. > > See PTR_ERR, ERR_PTR, ERR_CAST. It's special, i.e. error pointer case. We don't handle such here. > There's nothing broken about the way the code currently stands, so I'd > rather try to find something to move the implementation forward than > sideways. Submit a patch then. I rest my case b/c I consider that ugly castings worse than additional API call, although it's not ideal. -- With Best Regards, Andy Shevchenko ___ Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org To unsubscribe send an email to linux-nvdimm-le...@lists.01.org
Re: [PATCH v1 1/1] ACPI: NFIT: Import GUID before use
On Fri, Apr 16, 2021 at 1:58 AM Andy Shevchenko wrote: > > On Fri, Apr 16, 2021 at 8:28 AM Dan Williams wrote: > > > > On Thu, Apr 15, 2021 at 6:59 AM Andy Shevchenko > > wrote: > > > > > > Strictly speaking the comparison between guid_t and raw buffer > > > is not correct. Import GUID to variable of guid_t type and then > > > compare. > > > > Hmm, what about something like the following instead, because it adds > > safety. Any concerns about evaluating x twice in a macro should be > > alleviated by the fact that ARRAY_SIZE() will fail the build if (x) is > > not an array. > > ARRAY_SIZE doesn't check type. See __must_be_array. > I don't like hiding ugly casts like this. See PTR_ERR, ERR_PTR, ERR_CAST. There's nothing broken about the way the code currently stands, so I'd rather try to find something to move the implementation forward than sideways. ___ Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org To unsubscribe send an email to linux-nvdimm-le...@lists.01.org
RE:linux-nvdimm@lists.01.org 阿里巴巴国际站数据---最新优惠
最新阿里巴巴国际站数据---13万家企业 有联系人，电话，邮箱，网站等Q Q: 345814412 E-mail：hk852hongk...@hotmail.com 2021年04月23日 ___ Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org To unsubscribe send an email to linux-nvdimm-le...@lists.01.org
Re: [PATCH v1 1/1] ACPI: NFIT: Import GUID before use
On Fri, Apr 16, 2021 at 8:28 AM Dan Williams wrote: > > On Thu, Apr 15, 2021 at 6:59 AM Andy Shevchenko > wrote: > > > > Strictly speaking the comparison between guid_t and raw buffer > > is not correct. Import GUID to variable of guid_t type and then > > compare. > > Hmm, what about something like the following instead, because it adds > safety. Any concerns about evaluating x twice in a macro should be > alleviated by the fact that ARRAY_SIZE() will fail the build if (x) is > not an array. ARRAY_SIZE doesn't check type. I don't like hiding ugly casts like this. -- With Best Regards, Andy Shevchenko ___ Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org To unsubscribe send an email to linux-nvdimm-le...@lists.01.org
