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
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
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 ++
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
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 +-
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
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
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
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"
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
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
>
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:
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
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
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
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
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);
> >
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:
> > 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
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
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-4-26/ 0:48:39
收件人: "linux-nvdimm";
___
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm
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
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
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
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
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;
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
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
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
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
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
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
>
> 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
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.
>
>
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.
36 matches
Mail list logo