Re: [PATCH] arm64: configurable sparsemem section size

2019-04-25 Thread Michal Hocko
On Thu 25-04-19 13:57:25, Pavel Tatashin wrote: > > > I gave *vague* memories of running out of bits in the page flags if we > > > changed this, but that was a while back. If that's no longer the case, > > > then I'm open to changing the value, but I really don't want to expose > > > it as a

[PATCH v7 6/6] xfs: disable map_sync for async flush

2019-04-25 Thread Pankaj Gupta
Dont support 'MAP_SYNC' with non-DAX files and DAX files with asynchronous dax_device. Virtio pmem provides asynchronous host page cache flush mechanism. We don't support 'MAP_SYNC' with virtio pmem and xfs. Signed-off-by: Pankaj Gupta --- fs/xfs/xfs_file.c | 9 ++--- 1 file changed, 6

[PATCH v7 5/6] ext4: disable map_sync for async flush

2019-04-25 Thread Pankaj Gupta
Dont support 'MAP_SYNC' with non-DAX files and DAX files with asynchronous dax_device. Virtio pmem provides asynchronous host page cache flush mechanism. We don't support 'MAP_SYNC' with virtio pmem and ext4. Signed-off-by: Pankaj Gupta Reviewed-by: Jan Kara --- fs/ext4/file.c | 10 ++

[PATCH v7 4/6] dax: check synchronous mapping is supported

2019-04-25 Thread Pankaj Gupta
This patch introduces 'daxdev_mapping_supported' helper which checks if 'MAP_SYNC' is supported with filesystem mapping. It also checks if corresponding dax_device is synchronous. Virtio pmem device is asynchronous and does not not support VM_SYNC. Suggested-by: Jan Kara Signed-off-by: Pankaj

[PATCH v7 3/6] libnvdimm: add dax_dev sync flag

2019-04-25 Thread Pankaj Gupta
This patch adds 'DAXDEV_SYNC' flag which is set for nd_region doing synchronous flush. This later is used to disable MAP_SYNC functionality for ext4 & xfs filesystem for devices don't support synchronous flush. Signed-off-by: Pankaj Gupta --- drivers/dax/bus.c| 2 +-

[PATCH v7 2/6] virtio-pmem: Add virtio pmem driver

2019-04-25 Thread Pankaj Gupta
This patch adds virtio-pmem driver for KVM guest. Guest reads the persistent memory range information from Qemu over VIRTIO and registers it on nvdimm_bus. It also creates a nd_region object with the persistent memory range information so that existing 'nvdimm/pmem' driver can reserve this into

[PATCH v7 0/6] virtio pmem driver

2019-04-25 Thread Pankaj Gupta
This patch series has implementation for "virtio pmem". "virtio pmem" is fake persistent memory(nvdimm) in guest which allows to bypass the guest page cache. This also implements a VIRTIO based asynchronous flush mechanism. Sharing guest kernel driver in this patchset with the changes

[PATCH v7 1/6] libnvdimm: nd_region flush callback support

2019-04-25 Thread Pankaj Gupta
This patch adds functionality to perform flush from guest to host over VIRTIO. We are registering a callback based on 'nd_region' type. virtio_pmem driver requires this special flush function. For rest of the region types we are registering existing flush function. Report error returned by host

Message could not be delivered

2019-04-25 Thread Automatic Email Delivery Software
The original message was received at Fri, 26 Apr 2019 11:38:18 +0800 from lists.01.org [178.80.134.166] - The following addresses had permanent fatal errors - - Transcript of session follows - while talking to lists.01.org.: >>> MAIL From:"Automatic Email Delivery Software"

Re: [PATCH v2] mm: Fix modifying of page protection by insert_pfn_pmd()

2019-04-25 Thread Matthew Wilcox
On Thu, Apr 25, 2019 at 05:33:04PM -0700, Dan Williams wrote: > On Thu, Apr 25, 2019 at 12:32 AM Jan Kara wrote: > > > > We also call vmf_insert_pfn_pmd() in dax_insert_pfn_mkwrite() -- does > > > > that need to change too? > > > > > > It wasn't clear to me that it was a problem. I think that one

Re: [PATCH v2] mm: Fix modifying of page protection by insert_pfn_pmd()

2019-04-25 Thread Dan Williams
On Thu, Apr 25, 2019 at 12:32 AM Jan Kara wrote: > > On Wed 24-04-19 11:13:48, Dan Williams wrote: > > On Wed, Apr 24, 2019 at 10:38 AM Matthew Wilcox wrote: > > > > > > On Wed, Apr 24, 2019 at 10:13:15AM -0700, Dan Williams wrote: > > > > I think unaligned addresses have always been passed to >

Re: [PATCH v1 11/17] kunit: test: add test managed resource tests

2019-04-25 Thread Brendan Higgins
On Wed, Apr 24, 2019 at 12:00 PM Masayoshi Mizuma wrote: > > On Thu, Apr 04, 2019 at 03:06:46PM -0700, Brendan Higgins wrote: > > From: Avinash Kondareddy > > > > Tests how tests interact with test managed resources in their lifetime. > > > > Signed-off-by: Avinash Kondareddy > > Signed-off-by:

Re: [PATCH v1 14/17] Documentation: kunit: add documentation for KUnit

2019-04-25 Thread Brendan Higgins
On Wed, Apr 24, 2019 at 11:58 AM Masayoshi Mizuma wrote: > > Hi Brendan, > > KUNIT_ASSERT_NOT_ERR_OR_NULL() should be replaced to > KUNIT_EXPECT_NOT_ERR_OR_NULL(), right? Generally speaking, no. There may be places that I have used it improperly, but I think it is generally okay to use. If you

Re: [PATCH v3 12/26] compat_ioctl: move more drivers to compat_ptr_ioctl

2019-04-25 Thread Johannes Berg
On Thu, 2019-04-25 at 17:55 +0200, Arnd Bergmann wrote: > On Thu, Apr 25, 2019 at 5:35 PM Al Viro wrote: > > > > On Thu, Apr 25, 2019 at 12:21:53PM -0300, Mauro Carvalho Chehab wrote: > > > > > If I understand your patch description well, using compat_ptr_ioctl > > > only works if the driver is

Re: [v3 2/2] device-dax: "Hotremove" persistent memory that is used like normal RAM

2019-04-25 Thread Pavel Tatashin
On Thu, Apr 25, 2019 at 3:01 PM Dave Hansen wrote: > > Hi Pavel, > > Thanks for doing this! I knew we'd have to get to it eventually, but > sounds like you needed it sooner rather than later. Hi Dave, Thank you for taking time reviewing this work, my comments below: > > > > +#ifdef

Re: [v3 2/2] device-dax: "Hotremove" persistent memory that is used like normal RAM

2019-04-25 Thread Dave Hansen
Hi Pavel, Thanks for doing this! I knew we'd have to get to it eventually, but sounds like you needed it sooner rather than later. ... > static inline struct dev_dax *to_dev_dax(struct device *dev) > diff --git a/drivers/dax/kmem.c b/drivers/dax/kmem.c > index 4c0131857133..6f1640462df9 100644

Re: [v3 1/2] device-dax: fix memory and resource leak if hotplug fails

2019-04-25 Thread Pavel Tatashin
On Thu, Apr 25, 2019 at 2:32 PM Dave Hansen wrote: > > On 4/25/19 10:54 AM, Pavel Tatashin wrote: > > rc = add_memory(numa_node, new_res->start, resource_size(new_res)); > > - if (rc) > > + if (rc) { > > + release_resource(new_res); > > + kfree(new_res); > >

Re: [v3 1/2] device-dax: fix memory and resource leak if hotplug fails

2019-04-25 Thread Dave Hansen
On 4/25/19 10:54 AM, Pavel Tatashin wrote: > rc = add_memory(numa_node, new_res->start, resource_size(new_res)); > - if (rc) > + if (rc) { > + release_resource(new_res); > + kfree(new_res); > return rc; > + } Looks good to me: Reviewed-by:

Re: [PATCH] arm64: configurable sparsemem section size

2019-04-25 Thread Pavel Tatashin
> > I gave *vague* memories of running out of bits in the page flags if we > > changed this, but that was a while back. If that's no longer the case, > > then I'm open to changing the value, but I really don't want to expose > > it as a Kconfig option as proposed in this patch. People won't have a

[v3 1/2] device-dax: fix memory and resource leak if hotplug fails

2019-04-25 Thread Pavel Tatashin
When add_memory() function fails, the resource and the memory should be freed. Fixes: c221c0b0308f ("device-dax: "Hotplug" persistent memory for use like normal RAM") Signed-off-by: Pavel Tatashin --- drivers/dax/kmem.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git

[v3 0/2] "Hotremove" persistent memory

2019-04-25 Thread Pavel Tatashin
Changelog: v3 - Addressed comments from David Hildenbrand. Don't release lock_device_hotplug after checking memory status, and rename memblock_offlined_cb() to check_memblock_offlined_cb() v2 - Dan Williams mentioned that drv->remove() return is ignored by unbind. Unbind always succeeds.

答复:建立科学的标准工时制定方法,合理制定劳动定额

2019-04-25 Thread 邀请函
发件人: "邀请函";; 发送时间: 2019-4-26/ 0:48:39 收件人: "linux-nvdimm"; ___ Linux-nvdimm mailing list Linux-nvdimm@lists.01.org https://lists.01.org/mailman/listinfo/linux-nvdimm

Re: [PATCH v3 12/26] compat_ioctl: move more drivers to compat_ptr_ioctl

2019-04-25 Thread Al Viro
On Thu, Apr 25, 2019 at 05:55:23PM +0200, Arnd Bergmann wrote: > On Thu, Apr 25, 2019 at 5:35 PM Al Viro wrote: > > > > On Thu, Apr 25, 2019 at 12:21:53PM -0300, Mauro Carvalho Chehab wrote: > > > > > If I understand your patch description well, using compat_ptr_ioctl > > > only works if the

Re: [PATCH v3 12/26] compat_ioctl: move more drivers to compat_ptr_ioctl

2019-04-25 Thread Arnd Bergmann
On Thu, Apr 25, 2019 at 5:35 PM Al Viro wrote: > > On Thu, Apr 25, 2019 at 12:21:53PM -0300, Mauro Carvalho Chehab wrote: > > > If I understand your patch description well, using compat_ptr_ioctl > > only works if the driver is not for s390, right? > > No; s390 is where "oh, just set

Re: [PATCH v3 12/26] compat_ioctl: move more drivers to compat_ptr_ioctl

2019-04-25 Thread Mauro Carvalho Chehab
Em Thu, 25 Apr 2019 16:35:34 +0100 Al Viro escreveu: > On Thu, Apr 25, 2019 at 12:21:53PM -0300, Mauro Carvalho Chehab wrote: > > > If I understand your patch description well, using compat_ptr_ioctl > > only works if the driver is not for s390, right? > > No; s390 is where "oh, just set

Re: [PATCH] arm64: configurable sparsemem section size

2019-04-25 Thread Michal Hocko
On Thu 25-04-19 16:31:38, Will Deacon wrote: > On Thu, Apr 25, 2019 at 05:25:50PM +0200, Michal Hocko wrote: > > On Tue 23-04-19 16:38:43, Pavel Tatashin wrote: > > > sparsemem section size determines the maximum size and alignment that > > > is allowed to offline/online memory block. The bigger

Re: [PATCH v3 12/26] compat_ioctl: move more drivers to compat_ptr_ioctl

2019-04-25 Thread Al Viro
On Thu, Apr 25, 2019 at 12:21:53PM -0300, Mauro Carvalho Chehab wrote: > If I understand your patch description well, using compat_ptr_ioctl > only works if the driver is not for s390, right? No; s390 is where "oh, just set ->compat_ioctl same as ->unlocked_ioctl and be done with that;

Re: [PATCH v3 12/26] compat_ioctl: move more drivers to compat_ptr_ioctl

2019-04-25 Thread Arnd Bergmann
On Thu, Apr 25, 2019 at 5:22 PM Mauro Carvalho Chehab wrote: > Em Tue, 16 Apr 2019 22:25:33 +0200 Arnd Bergmann escreveu: > > If I understand your patch description well, using compat_ptr_ioctl > only works if the driver is not for s390, right? No, the purpose of compat_ptr_ioctl() is to make

Re: [PATCH] arm64: configurable sparsemem section size

2019-04-25 Thread Will Deacon
On Thu, Apr 25, 2019 at 05:25:50PM +0200, Michal Hocko wrote: > On Tue 23-04-19 16:38:43, Pavel Tatashin wrote: > > sparsemem section size determines the maximum size and alignment that > > is allowed to offline/online memory block. The bigger the size the less > > the clutter in

Re: [PATCH] arm64: configurable sparsemem section size

2019-04-25 Thread Michal Hocko
On Tue 23-04-19 16:38:43, Pavel Tatashin wrote: > sparsemem section size determines the maximum size and alignment that > is allowed to offline/online memory block. The bigger the size the less > the clutter in /sys/devices/system/memory/*. On the other hand, however, > there is less flexability

Re: [PATCH v3 12/26] compat_ioctl: move more drivers to compat_ptr_ioctl

2019-04-25 Thread Mauro Carvalho Chehab
Em Tue, 16 Apr 2019 22:25:33 +0200 Arnd Bergmann escreveu: > The .ioctl and .compat_ioctl file operations have the same prototype so > they can both point to the same function, which works great almost all > the time when all the commands are compatible. > > One exception is the s390

Re: [PATCH v6 03/12] mm/sparsemem: Add helpers track active portions of a section at boot

2019-04-25 Thread Oscar Salvador
On Wed, 2019-04-17 at 11:39 -0700, Dan Williams wrote: > Prepare for hot{plug,remove} of sub-ranges of a section by tracking a > section active bitmask, each bit representing 2MB (SECTION_SIZE > (128M) / > map_active bitmask length (64)). If it turns out that 2MB is too > large > of an active

Re: [v2 2/2] device-dax: "Hotremove" persistent memory that is used like normal RAM

2019-04-25 Thread David Hildenbrand
On 25.04.19 14:30, Pavel Tatashin wrote: >> >> Yes, also I think you can let go of the device_lock in >> check_memblocks_offline_cb, lock_device_hotplug() should take care of >> this (see Documentation/core-api/memory-hotplug.rst - "locking internals") >> > Hi David, > > Thank you for your

Re: [v2 2/2] device-dax: "Hotremove" persistent memory that is used like normal RAM

2019-04-25 Thread Pavel Tatashin
> > Yes, also I think you can let go of the device_lock in > check_memblocks_offline_cb, lock_device_hotplug() should take care of > this (see Documentation/core-api/memory-hotplug.rst - "locking internals") > Hi David, Thank you for your comments. I went through memory-hotplug.rst, and I still

Re: [v2 2/2] device-dax: "Hotremove" persistent memory that is used like normal RAM

2019-04-25 Thread David Hildenbrand
On 24.04.19 23:34, Pavel Tatashin wrote: +static int +offline_memblock_cb(struct memory_block *mem, void *arg) >>> >>> Function name suggests that you are actually trying to offline memory >>> here. Maybe check_memblocks_offline_cb(), just like we have in >>> mm/memory_hotplug.c. > >

Re: [PATCH v2] mm: Fix modifying of page protection by insert_pfn_pmd()

2019-04-25 Thread Jan Kara
On Wed 24-04-19 11:13:48, Dan Williams wrote: > On Wed, Apr 24, 2019 at 10:38 AM Matthew Wilcox wrote: > > > > On Wed, Apr 24, 2019 at 10:13:15AM -0700, Dan Williams wrote: > > > I think unaligned addresses have always been passed to > > > vmf_insert_pfn_pmd(), but nothing cared until this patch.