search for: memory_device_fsdax

...ge() call. > > release_pages only called put_devmap_managed_page for device public > pages. So I can't see how that is in any way a problem. It's a bug that the call to put_devmap_managed_page() was gated by MEMORY_DEVICE_PUBLIC in release_pages(). That path is also applicable to MEMORY_DEVICE_FSDAX because it needs to trigger the ->page_free() callback to wake up wait_on_var() via fsdax_pagefree(). So I guess you could argue that the MEMORY_DEVICE_PUBLIC removal patch left the original bug in place. In that sense we're no worse off, but since we know about the bug, the fix and the pat...

...flags); > - locked_pgdat = NULL; > - } > - put_devmap_managed_page(page); > - continue; > - } > - This collides with Ira's bug fix [1]. The MEMORY_DEVICE_FSDAX case needs this to be converted to be independent of "public" pages. Perhaps it should be pulled out of -mm and incorporated in this series. [1]: https://lore.kernel.org/lkml/20190605214922.17684-1-ira.weiny at intel.com/

...> - locked_pgdat = NULL; > > - } > > - put_devmap_managed_page(page); > > - continue; > > - } > > - > > This collides with Ira's bug fix [1]. The MEMORY_DEVICE_FSDAX case > needs this to be converted to be independent of "public" pages. > Perhaps it should be pulled out of -mm and incorporated in this > series. > > [1]: https://lore.kernel.org/lkml/20190605214922.17684-1-ira.weiny at intel.com/ Agreed and Andrew picked the first 2 ver...

On Fri, Jun 28, 2019 at 11:59:19AM -0700, Dan Williams wrote: > It's a bug that the call to put_devmap_managed_page() was gated by > MEMORY_DEVICE_PUBLIC in release_pages(). That path is also applicable > to MEMORY_DEVICE_FSDAX because it needs to trigger the ->page_free() > callback to wake up wait_on_var() via fsdax_pagefree(). > > So I guess you could argue that the MEMORY_DEVICE_PUBLIC removal patch > left the original bug in place. In that sense we're no worse off, but > since we know about the...

...:02 PM Christoph Hellwig <hch at lst.de> wrote: > > On Fri, Jun 28, 2019 at 11:59:19AM -0700, Dan Williams wrote: > > It's a bug that the call to put_devmap_managed_page() was gated by > > MEMORY_DEVICE_PUBLIC in release_pages(). That path is also applicable > > to MEMORY_DEVICE_FSDAX because it needs to trigger the ->page_free() > > callback to wake up wait_on_var() via fsdax_pagefree(). > > > > So I guess you could argue that the MEMORY_DEVICE_PUBLIC removal patch > > left the original bug in place. In that sense we're no worse off, but > >...

On Fri, Jun 28, 2019 at 11:29 AM Jason Gunthorpe <jgg at mellanox.com> wrote: > > On Fri, Jun 28, 2019 at 10:10:12AM -0700, Dan Williams wrote: > > On Fri, Jun 28, 2019 at 10:08 AM Dan Williams <dan.j.williams at intel.com> wrote: > > > > > > On Fri, Jun 28, 2019 at 10:02 AM Jason Gunthorpe <jgg at mellanox.com> wrote: > > > > > >

Hi Dan, Jérôme and Jason, below is a series that cleans up the dev_pagemap interface so that it is more easily usable, which removes the need to wrap it in hmm and thus allowing to kill a lot of code Note: this series is on top of Linux 5.2-rc5 and has some minor conflicts with the hmm tree that are easy to resolve. Diffstat summary: 32 files changed, 361 insertions(+), 1012 deletions(-) Git