On Mon, Sep 14, 2020 at 3:45 PM Ralph Campbell wrote:
>
> ZONE_DEVICE struct pages have an extra reference count that complicates the
> code for put_page() and several places in the kernel that need to check the
> reference count to see that a page is not being used (gup, compaction,
> migration,
test_hmm uses normal pages to fake this up, so
> > I was wrong about the third caller. But I think we can just call
> > set_page_count just before freeing the page there with a comment
> > explaining what is goin on.
>
> Dan Williams thought that having the ZONE_DEVICE s
On Fri, Sep 25, 2020 at 1:45 PM Ralph Campbell wrote:
>
> There are several places where ZONE_DEVICE struct pages assume a reference
> count == 1 means the page is idle and free. Instead of open coding this,
> add a helper function to hide this detail.
>
> Signed-off-by: Ralph Campbell
> ---
> f
On Thu, Oct 1, 2020 at 11:17 AM Ralph Campbell wrote:
>
> This is still an RFC because after looking at the pmem/dax code some
> more, I realized that the ZONE_DEVICE struct pages are being inserted
> into the process' page tables with vmf_insert_mixed() and a zero
> refcount on the ZONE_DEVICE st
On Mon, Oct 12, 2020 at 10:46 AM Ralph Campbell wrote:
>
> ZONE_DEVICE struct pages have an extra reference count that complicates the
> code for put_page() and several places in the kernel that need to check the
> reference count to see that a page is not being used (gup, compaction,
> migration,
/drivers/nvdimm/claim.c
> +++ b/drivers/nvdimm/claim.c
> @@ -200,11 +200,10 @@ ssize_t nd_namespace_store(struct device *dev,
> }
> break;
> default:
> len = -EBUSY;
> goto out_attach;
> - break;
> }
Acked-by: Dan Williams
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
On Sun, Feb 6, 2022 at 10:33 PM Christoph Hellwig wrote:
>
> memremap.c is only built when CONFIG_ZONE_DEVICE is set, so remove
> the superflous extra check.
Looks good to me.
Reviewed-by: Dan Williams
On Sun, Feb 6, 2022 at 10:33 PM Christoph Hellwig wrote:
>
> __KERNEL__ ifdefs don't make sense outside of include/uapi/.
Yes.
Reviewed-by: Dan Williams
On Sun, Feb 6, 2022 at 10:33 PM Christoph Hellwig wrote:
>
> free_devmap_managed_page has nothing to do with the code in swap.c,
> move it to live with the rest of the code for devmap handling.
>
Looks good.
Reviewed-by: Dan Williams
On Sun, Feb 6, 2022 at 10:33 PM Christoph Hellwig wrote:
>
> Make put_devmap_managed_page return if it took charge of the page
> or not and remove the separate page_is_devmap_managed helper.
Looks good to me:
Reviewed-by: Dan Williams
Reviewed-by: Dan Williams
>
> Signed-off-by: Christoph Hellwig
> ---
> arch/arm64/mm/mmu.c| 1 +
> drivers/gpu/drm/amd/amdkfd/kfd_priv.h | 1 +
> drivers/gpu/drm/drm_cache.c| 2 +-
> drivers/gpu/drm/nouveau/nouveau_dmem.c | 1 +
> d
On Mon, Feb 7, 2022 at 3:49 PM Dan Williams wrote:
>
> On Sun, Feb 6, 2022 at 10:33 PM Christoph Hellwig wrote:
> >
> > Move the check for the actual pgmap types that need the free at refcount
> > one behavior into the out of line helper, and thus avoid the need to
>
ge cache.
This looks ok to me, and passes my tests. So given I'm still working
my way back to fixing the references properly I'm ok for this hack to
replace the more broken hack that is there presently.
Reviewed-by: Dan Williams
[ add dri-devel and nouveau ]
Dan Williams wrote:
> The core of devm_request_free_mem_region() is a helper that searches for
> free space in iomem_resource and performs __request_region_locked() on
> the result of that search. The policy choices of the implementation
> con
Alistair Popple wrote:
>
> Jason Gunthorpe writes:
>
> > On Mon, Sep 26, 2022 at 04:03:06PM +1000, Alistair Popple wrote:
> >> Since 27674ef6c73f ("mm: remove the extra ZONE_DEVICE struct page
> >> refcount") device private pages have no longer had an extra reference
> >> count when the page is
Alistair Popple wrote:
>
> Dan Williams writes:
>
> > Alistair Popple wrote:
> >>
> >> Jason Gunthorpe writes:
> >>
> >> > On Mon, Sep 26, 2022 at 04:03:06PM +1000, Alistair Popple wrote:
> >> >> Since 27674ef6c73f (&q
On Thu, Jun 13, 2019 at 2:43 AM Christoph Hellwig 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
>
> Diffstat:
>
> 22 files c
On Thu, Jun 13, 2019 at 12:35 PM Jason Gunthorpe wrote:
>
> On Thu, Jun 13, 2019 at 11:43:12AM +0200, Christoph Hellwig wrote:
> > Just check if there is a ->page_free operation set and take care of the
> > static key enable, as well as the put using device managed resources.
> > diff --git a/mm/h
n he introduced the
> callback[1].
>
> Reviewed-by: Logan Gunthorpe
Reviewed-by: Dan Williams
Reported-by: Logan Gunthorpe :)
>
> Logan
>
> [1]
> https://lore.kernel.org/lkml/8f0cae82-130f-8a64-cfbd-fda5fd76b...@deltatee.com/T/#u
>
___
On Thu, Jun 13, 2019 at 1:18 PM Logan Gunthorpe wrote:
>
>
>
> On 2019-06-13 12:27 p.m., Dan Williams wrote:
> > On Thu, Jun 13, 2019 at 2:43 AM Christoph Hellwig wrote:
> >>
> >> Hi Dan, Jérôme and Jason,
> >>
> >> below is a series that
On Thu, Jun 13, 2019 at 11:14 PM Christoph Hellwig wrote:
>
> On Thu, Jun 13, 2019 at 11:27:39AM -0700, Dan Williams wrote:
> > It also turns out the nvdimm unit tests crash with this signature on
> > that branch where base v5.2-rc3 passes:
>
> How do you run that test
On Sat, Jun 15, 2019 at 1:34 AM Christoph Hellwig wrote:
>
> On Fri, Jun 14, 2019 at 06:14:45PM -0700, Dan Williams wrote:
> > On Thu, Jun 13, 2019 at 11:14 PM Christoph Hellwig wrote:
> > >
> > > On Thu, Jun 13, 2019 at 11:27:39AM -0700, Dan Williams wrote:
> &
On Mon, Jun 17, 2019 at 5:27 AM Christoph Hellwig wrote:
>
> Keep the physical address allocation that hmm_add_device does with the
> rest of the resource code, and allow future reuse of it without the hmm
> wrapper.
>
> Signed-off-by: Christoph Hellwig
> Reviewed-by: Jason Gunthorpe
> Reviewed-
On Mon, Jun 17, 2019 at 5:27 AM Christoph Hellwig wrote:
>
> The dev_pagemap is a growing too many callbacks. Move them into a
> separate ops structure so that they are not duplicated for multiple
> instances, and an attacker can't easily overwrite them.
>
> Signed-off-by: Christoph Hellwig
> Re
On Mon, Jun 17, 2019 at 5:27 AM Christoph Hellwig wrote:
>
> Most pgmap types are only supported when certain config options are
> enabled. Check for a type that is valid for the current configuration
> before setting up the pagemap.
>
> Signed-off-by: Christoph Hellwig
> ---
> kernel/memremap.
On Mon, Jun 17, 2019 at 5:28 AM Christoph Hellwig wrote:
>
> Just check if there is a ->page_free operation set and take care of the
> static key enable, as well as the put using device managed resources.
> Also check that a ->page_free is provided for the pgmaps types that
> require it, and check
On Mon, Jun 17, 2019 at 12:59 PM Christoph Hellwig wrote:
>
> On Mon, Jun 17, 2019 at 12:02:09PM -0700, Dan Williams wrote:
> > Need a lead in patch that introduces MEMORY_DEVICE_DEVDAX, otherwise:
>
> Or maybe a MEMORY_DEVICE_DEFAULT = 0 shared by fsdax and p2pdma?
I thought
On Mon, Jun 17, 2019 at 12:59 PM Christoph Hellwig wrote:
>
> On Mon, Jun 17, 2019 at 10:51:35AM -0700, Dan Williams wrote:
> > > - struct dev_pagemap *pgmap = _pgmap;
> >
> > Whoops, needed to keep this line to avoid:
> >
> > tools/testing/nv
s/dax/device.c | 43 ---
> 2 files changed, 47 deletions(-)
This needs the mock devm_memremap_pages() to setup the common
percpu_ref. Incremental patch attached:
From 875e71489c8485448a5b7df2d8a8b2ed77d2b555 Mon Sep 17 00:00:00 2001
From: Dan Williams
Date: Tue, 18 Jun 2019 11:58:24 -0700
Sub
s from the reviews
Attached is my incremental fixups on top of this series, with those
integrated you can add:
Tested-by: Dan Williams
...to the patches that touch kernel/memremap.c, drivers/dax, and drivers/nvdimm.
You can also add:
Reviewed-by: Dan Williams
...for the series.
diff --git a/dr
On Wed, Jun 19, 2019 at 9:37 AM Jason Gunthorpe wrote:
>
> On Wed, Jun 19, 2019 at 11:40:32AM +0200, Christoph Hellwig wrote:
> > On Tue, Jun 18, 2019 at 12:47:10PM -0700, Dan Williams wrote:
> > > > Git tree:
> > > >
> > > > git://git.infra
On Wed, Jun 19, 2019 at 12:42 PM Jason Gunthorpe wrote:
>
> On Thu, Jun 13, 2019 at 06:23:04PM -0700, John Hubbard wrote:
> > On 6/13/19 5:43 PM, Ira Weiny wrote:
> > > On Thu, Jun 13, 2019 at 07:58:29PM +, Jason Gunthorpe wrote:
> > >> On Thu, Jun 13, 2019 at 12:53:02PM -0700, Ralph Campbell
On Thu, Jun 20, 2019 at 12:17 PM Michal Hocko wrote:
>
> On Thu 13-06-19 11:43:08, Christoph Hellwig wrote:
> > noveau is currently using this through an odd hmm wrapper, and I plan
> > to switch it to the real thing later in this series.
> >
> > Signed-off-by: Christoph Hellwig
> > ---
> > mm/m
On Tue, Jun 25, 2019 at 8:01 AM Michal Hocko wrote:
>
> On Tue 25-06-19 09:23:17, Christoph Hellwig wrote:
> > On Mon, Jun 24, 2019 at 11:24:48AM -0700, Dan Williams wrote:
> > > I asked for this simply because it was not exported historically. In
> > > general I wan
On Tue, Jun 25, 2019 at 12:01 PM Michal Hocko wrote:
>
> On Tue 25-06-19 11:03:53, Dan Williams wrote:
> > On Tue, Jun 25, 2019 at 8:01 AM Michal Hocko wrote:
> > >
> > > On Tue 25-06-19 09:23:17, Christoph Hellwig wrote:
> > > > On Mon, Jun 24, 20
[ add Ira ]
On Wed, Jun 26, 2019 at 5:27 AM Christoph Hellwig wrote:
>
> The code hasn't been used since it was added to the tree, and doesn't
> appear to actually be usable.
>
> Signed-off-by: Christoph Hellwig
> Reviewed-by: Jason Gunthorpe
> Acked-by: Michal Hocko
[..]
> diff --git a/mm/swa
On Tue, Jun 25, 2019 at 10:46 PM Michal Hocko wrote:
>
> On Tue 25-06-19 12:52:18, Dan Williams wrote:
> [...]
> > > Documentation/process/stable-api-nonsense.rst
> >
> > That document has failed to preclude symbol export fights in the past
> > and there is
On Fri, Jun 28, 2019 at 8:39 AM Jason Gunthorpe wrote:
>
> On Wed, Jun 26, 2019 at 02:27:15PM +0200, Christoph Hellwig wrote:
> > The functionality is identical to the one currently open coded in
> > device-dax.
> >
> > Signed-off-by: Christoph Hellwig
> > Reviewed-by: Ira Weiny
> > ---
> > dri
On Fri, Jun 28, 2019 at 10:02 AM Jason Gunthorpe wrote:
>
> On Fri, Jun 28, 2019 at 09:27:44AM -0700, Dan Williams wrote:
> > On Fri, Jun 28, 2019 at 8:39 AM Jason Gunthorpe wrote:
> > >
> > > On Wed, Jun 26, 2019 at 02:27:15PM +0200, Christoph Hellwig wrote
On Fri, Jun 28, 2019 at 10:08 AM Dan Williams wrote:
>
> On Fri, Jun 28, 2019 at 10:02 AM Jason Gunthorpe wrote:
> >
> > On Fri, Jun 28, 2019 at 09:27:44AM -0700, Dan Williams wrote:
> > > On Fri, Jun 28, 2019 at 8:39 AM Jason Gunthorpe wrote:
> > > >
>
On Fri, Jun 28, 2019 at 11:29 AM Jason Gunthorpe 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
> > wrote:
> > >
> > > On Fri, Jun 28, 2019 at 10:02 AM Jason Gunthorpe
> > >
On Fri, Jun 28, 2019 at 11:52 AM Christoph Hellwig wrote:
>
> On Fri, Jun 28, 2019 at 11:44:35AM -0700, Dan Williams wrote:
> > There is a problem with the series in CH's tree. It removes the
> > ->page_free() callback from the release_pages() path because it goes
&
On Fri, Jun 28, 2019 at 12:02 PM Christoph Hellwig 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
>
On Tue, Jul 2, 2019 at 11:42 AM Jason Gunthorpe wrote:
>
> On Mon, Jul 01, 2019 at 10:25:17AM +0200, Christoph Hellwig wrote:
> > And I've demonstrated that I can't send patch series.. While this
> > has all the right patches, it also has the extra patches already
> > in the hmm tree, and four ex
On Wed, Aug 7, 2019 at 10:45 AM Jason Gunthorpe wrote:
>
> On Tue, Aug 06, 2019 at 07:05:42PM +0300, Christoph Hellwig wrote:
> > There is only a single place where the pgmap is passed over a function
> > call, so replace it with local variables in the places where we deal
> > with the pgmap.
> >
On Wed, Aug 7, 2019 at 11:59 PM Christoph Hellwig wrote:
>
> On Wed, Aug 07, 2019 at 11:47:22AM -0700, Dan Williams wrote:
> > > Unrelated to this patch, but what is the point of getting checking
> > > that the pgmap exists for the page and then immediately releasing it?
On Wed, Aug 14, 2019 at 6:28 AM Jason Gunthorpe wrote:
>
> On Wed, Aug 14, 2019 at 09:38:54AM +0200, Christoph Hellwig wrote:
> > On Tue, Aug 13, 2019 at 06:36:33PM -0700, Dan Williams wrote:
> > > Section alignment constraints somewhat save us here. The only example
>
On Thu, Aug 15, 2019 at 11:07 AM Jerome Glisse wrote:
>
> On Wed, Aug 14, 2019 at 07:48:28AM -0700, Dan Williams wrote:
> > On Wed, Aug 14, 2019 at 6:28 AM Jason Gunthorpe wrote:
> > >
> > > On Wed, Aug 14, 2019 at 09:38:54AM +0200, Christoph Hellwig wrote:
> &g
On Thu, Aug 15, 2019 at 12:44 PM Jerome Glisse wrote:
>
> On Thu, Aug 15, 2019 at 12:36:58PM -0700, Dan Williams wrote:
> > On Thu, Aug 15, 2019 at 11:07 AM Jerome Glisse wrote:
> > >
> > > On Wed, Aug 14, 2019 at 07:48:28AM -0700, Dan Williams wrote:
> >
On Thu, Aug 15, 2019 at 1:41 PM Jason Gunthorpe wrote:
>
> On Thu, Aug 15, 2019 at 04:33:06PM -0400, Jerome Glisse wrote:
>
> > So nor HMM nor driver should dereference the struct page (i do not
> > think any iommu driver would either),
>
> Er, they do technically deref the struct page:
>
> nouvea
On Thu, Aug 15, 2019 at 5:41 PM Jason Gunthorpe wrote:
>
> On Thu, Aug 15, 2019 at 01:47:12PM -0700, Dan Williams wrote:
> > On Thu, Aug 15, 2019 at 1:41 PM Jason Gunthorpe wrote:
> > >
> > > On Thu, Aug 15, 2019 at 04:33:06PM -0400, Jerome Glisse wrote:
>
On Fri, Aug 16, 2019 at 5:24 AM Jason Gunthorpe wrote:
>
> On Thu, Aug 15, 2019 at 08:54:46PM -0700, Dan Williams wrote:
>
> > > However, this means we cannot do any processing of ZONE_DEVICE pages
> > > outside the driver lock, so eg, doing any
ersion and it's safe to
> get rid of it.
>
> The conversion fixes a potential bug in int340x_thermal as well since
> we have to use memcmp() on binary data.
>
> Cc: Rafael J. Wysocki
> Cc: Mika Westerberg
> Cc: Borislav Petkov
> Cc: Dan Williams
> Cc: Amir Goldste
53 matches
Mail list logo