> "mem" in the name already indicates the root, similar to
> release_mem_region() and devm_request_mem_region(). Make it implicit.
> The only single caller always passes iomem_resource, other parents are
> not applicable.
>
> Suggested-by: Wei Yang
> Cc: Andrew Morton
> Cc: Michal Hocko
> Cc:
On Wed, Sep 16, 2020 at 04:20:20PM -0700, Andrew Morton wrote:
> On Wed, 16 Sep 2020 10:35:34 +0300 Mike Rapoport wrote:
>
> > This is an implementation of "secret" mappings backed by a file descriptor.
> > I've dropped the boot time reservation patch for now as it is not strictly
> > required
On Wed, Sep 16, 2020 at 10:40:13AM -0700, Dan Williams wrote:
> > Before nvfs gets included in the kernel, I need to distribute it as a
> > module. So, it would make my maintenance easier. But if you don't want to
> > export it now, no problem, I can just copy __copy_user_flushcache from the
> >
On Wed 16-09-20 11:22:05, Mike Snitzer wrote:
> On Wed, Sep 16 2020 at 11:14am -0400,
> Jan Kara wrote:
>
> > DM was calling generic_fsdax_supported() to determine whether a device
> > referenced in the DM table supports DAX. However this is a helper for
> > "leaf" device drivers so that
> >
On Thu, Sep 17, 2020 at 07:46:12AM +0200, Michael Kerrisk (man-pages) wrote:
> On Thu, 17 Sep 2020 at 01:20, Andrew Morton wrote:
> >
> > On Wed, 16 Sep 2020 10:35:34 +0300 Mike Rapoport wrote:
> >
> > > This is an implementation of "secret" mappings backed by a file
> > > descriptor.
> > >
On Mon, Sep 14, 2020 at 02:48:12PM +0800, Yi Zhang wrote:
>
> I check the commit, seems it was introduced with bellow commit:
>
> commit 6180bb446ab624b9ab8bf201ed251ca87f07b413
> Author: Coly Li
> Date: Fri Sep 4 00:16:25 2020 +0800
>
> dax: fix detection of dax support for
On Thu, Sep 17, 2020 at 7:58 AM Huang Adrian wrote:
>
> On Thu, Sep 17, 2020 at 6:42 PM Jan Kara wrote:
> >
> > On Thu 17-09-20 02:28:57, Dan Williams wrote:
> > > On Wed, Sep 16, 2020 at 8:15 AM Jan Kara wrote:
> > > >
> > > > DM was calling generic_fsdax_supported() to determine whether a
On Fri, Sep 11, 2020 at 12:47:04AM +0100, Matthew Wilcox (Oracle) wrote:
> Instead of counting bio segments, count the number of bytes submitted.
> This insulates us from the block layer's definition of what a 'same page'
> is, which is not necessarily clear once THPs are involved.
>
>
On Thu, Sep 17, 2020 at 11:11:15PM +0100, Matthew Wilcox wrote:
> On Thu, Sep 17, 2020 at 03:05:00PM -0700, Darrick J. Wong wrote:
> > > -static loff_t
> > > -iomap_zero_range_actor(struct inode *inode, loff_t pos, loff_t count,
> > > - void *data, struct iomap *iomap, struct iomap
On Fri, Sep 11, 2020 at 12:47:05AM +0100, Matthew Wilcox (Oracle) wrote:
> Instead of counting bio segments, count the number of bytes submitted.
> This insulates us from the block layer's definition of what a 'same page'
> is, which is not necessarily clear once THPs are involved.
>
>
On Fri, Sep 11, 2020 at 12:47:06AM +0100, Matthew Wilcox (Oracle) wrote:
> iomap_write_end cannot return an error, so switch it to return
> size_t instead of int and remove the error checking from the callers.
> Also convert the arguments to size_t from unsigned int, in case anyone
> ever wants to
On Fri, Sep 11, 2020 at 12:47:03AM +0100, Matthew Wilcox (Oracle) wrote:
> Size the uptodate array dynamically to support larger pages in the
> page cache. With a 64kB page, we're only saving 8 bytes per page today,
> but with a 2MB maximum page size, we'd have to allocate more than 4kB
> per
On Fri, Sep 11, 2020 at 12:47:07AM +0100, Matthew Wilcox (Oracle) wrote:
> Pass the full length to iomap_zero() and dax_iomap_zero(), and have
> them return how many bytes they actually handled. This is preparatory
> work for handling THP, although it looks like DAX could actually take
>
On Thu, Sep 17, 2020 at 03:05:00PM -0700, Darrick J. Wong wrote:
> > -static loff_t
> > -iomap_zero_range_actor(struct inode *inode, loff_t pos, loff_t count,
> > - void *data, struct iomap *iomap, struct iomap *srcmap)
> > +static loff_t iomap_zero_range_actor(struct inode *inode,
On Wed, Sep 16, 2020 at 6:41 AM Adrian Huang wrote:
>
> From: Adrian Huang
>
> When mounting fsdax pmem device, commit 6180bb446ab6 ("dax: fix
> detection of dax support for non-persistent memory block devices")
> introduces the stack overflow [1][2]. Here is the call path for
> mounting ext4
On Thu 17-09-20 02:28:57, Dan Williams wrote:
> On Wed, Sep 16, 2020 at 8:15 AM Jan Kara wrote:
> >
> > DM was calling generic_fsdax_supported() to determine whether a device
> > referenced in the DM table supports DAX. However this is a helper for
> > "leaf" device drivers so that
> > they
On Sat, 12 Sep 2020 13:44:51 +0530, Vaibhav Jain wrote:
> A warning is reported by the kernel in case perf_stats_show() returns
> an error code. The warning is of the form below:
>
> papr_scm ibm,persistent-memory:ibm,pmemory@4411:
> Failed to query performance stats, Err:-10
>
From: Adrian Huang
When mounting fsdax pmem device, commit 6180bb446ab6 ("dax: fix
detection of dax support for non-persistent memory block devices")
introduces the stack overflow [1][2]. Here is the call path for
mounting ext4 file system:
ext4_fill_super
bdev_dax_supported
On Wed, Sep 16, 2020 at 11:57 AM Mikulas Patocka wrote:
>
>
>
> On Wed, 16 Sep 2020, Dan Williams wrote:
>
> > On Wed, Sep 16, 2020 at 10:24 AM Mikulas Patocka
> > wrote:
> > >
> > >
> > >
> > > On Wed, 16 Sep 2020, Dan Williams wrote:
> > >
> > > > On Wed, Sep 16, 2020 at 3:57 AM Mikulas
On Thu, Sep 17, 2020 at 4:18 AM Adrian Huang wrote:
>
> From: Adrian Huang
>
> When mounting fsdax pmem device, commit 6180bb446ab6 ("dax: fix
> detection of dax support for non-persistent memory block devices")
> introduces the stack overflow [1][2]. Here is the call path for
> mounting ext4
___
Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org
To unsubscribe send an email to linux-nvdimm-le...@lists.01.org
On Thu, Sep 17, 2020 at 10:49 AM Dan Williams wrote:
>
> On Thu, Sep 17, 2020 at 7:58 AM Huang Adrian
> wrote:
> >
> > On Thu, Sep 17, 2020 at 6:42 PM Jan Kara wrote:
> > >
> > > On Thu 17-09-20 02:28:57, Dan Williams wrote:
> > > > On Wed, Sep 16, 2020 at 8:15 AM Jan Kara wrote:
> > > > >
>
From: Jan Kara
DM was calling generic_fsdax_supported() to determine whether a device
referenced in the DM table supports DAX. However this is a helper for "leaf"
device drivers so that
they don't have to duplicate common generic checks. High level code
should call dax_supported() helper which
___
Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org
To unsubscribe send an email to linux-nvdimm-le...@lists.01.org
On Wed, 2020-09-16 at 10:35 +0300, Mike Rapoport wrote:
> From: Mike Rapoport
>
> Hi,
>
> This is an implementation of "secret" mappings backed by a file descriptor.
> I've dropped the boot time reservation patch for now as it is not strictly
> required for the basic usage and can be easily
On Wed, Sep 16, 2020 at 8:15 AM Jan Kara wrote:
>
> DM was calling generic_fsdax_supported() to determine whether a device
> referenced in the DM table supports DAX. However this is a helper for "leaf"
> device drivers so that
> they don't have to duplicate common generic checks. High level code
On Thu, Sep 17, 2020 at 6:42 PM Jan Kara wrote:
>
> On Thu 17-09-20 02:28:57, Dan Williams wrote:
> > On Wed, Sep 16, 2020 at 8:15 AM Jan Kara wrote:
> > >
> > > DM was calling generic_fsdax_supported() to determine whether a device
> > > referenced in the DM table supports DAX. However this is
On Thu, Sep 17, 2020 at 10:57 PM Huang Adrian wrote:
>
> Note: Still no lock after applying Dan's fixup. It shows the same call
> trace with/without Dan's fixup.
Sorry, fat-finger. Should be 'Still no *luck*'
-- Adrian
___
Linux-nvdimm mailing list --
On Sat, Sep 12, 2020 at 11:39:01AM +0800, Jason Yan wrote:
> This eliminates the following sparse warning:
>
> drivers/dax/kmem.c:38:5: warning: symbol 'dev_dax_kmem_probe' was not
> declared. Should it be static?
>
> Reported-by: Hulk Robot
> Signed-off-by: Jason Yan
Reviewed-by: Ira Weiny
29 matches
Mail list logo
