struct be typed, so struct_group_typed() is added.
>
> Given there is a need for a handful of UAPI uses too, the underlying
> __struct_group() macro has been defined in UAPI so it can be used there
> too.
>
> Co-developed-by: Keith Packard
> Signed-off-by: Keith Packard
> Signed-off-by: Kees Cook
> Acked-by: Gustavo A. R. Silva
> Link: https://lore.kernel.org/lkml/20210728023217.GC35706@embeddedor
> Enhanced-by: Rasmus Villemoes
> Link:
> https://lore.kernel.org/lkml/41183a98-bdb9-4ad6-7eab-5a7292a6d...@rasmusvillemoes.dk
> Enhanced-by: Dan Williams
Acked-by: Dan Williams
nel.org
> Suggested-by: Dan Williams
Looks good and tests ok here:
Reviewed-by: Dan Williams
On Tue, Nov 3, 2020 at 1:28 PM Bjorn Helgaas wrote:
>
> On Fri, Oct 30, 2020 at 11:08:11AM +0100, Daniel Vetter wrote:
> > There's three ways to access PCI BARs from userspace: /dev/mem, sysfs
> > files, and the old proc interface. Two check against
> > iomem_is_exclusive, proc never did. And with
On Wed, Nov 4, 2020 at 8:50 AM Bjorn Helgaas wrote:
>
> On Wed, Nov 04, 2020 at 09:44:04AM +0100, Daniel Vetter wrote:
> > On Tue, Nov 3, 2020 at 11:09 PM Dan Williams
> > wrote:
> > > On Tue, Nov 3, 2020 at 1:28 PM Bjorn Helgaas wrote:
> > > > On Fri, O
On Thu, Sep 2, 2021 at 1:18 AM Christoph Hellwig wrote:
>
> On Wed, Sep 01, 2021 at 11:40:43AM -0400, Felix Kuehling wrote:
> > >>> It looks like I'm totally misunderstanding what you are adding here
> > >>> then. Why do we need any special treatment at all for memory that
> > >>> has normal stru
On Thu, Oct 14, 2021 at 11:45 AM Matthew Wilcox wrote:
>
>
> It would probably help if you cc'd Dan on this.
Thanks.
[..]
>
> On Thu, Oct 14, 2021 at 02:06:34PM -0300, Jason Gunthorpe wrote:
> > On Thu, Oct 14, 2021 at 10:39:28AM -0500, Alex Sierra wrote:
> > > From: Ralph Campbell
> > >
> > >
On Thu, Oct 14, 2021 at 4:06 PM Jason Gunthorpe wrote:
>
> On Thu, Oct 14, 2021 at 12:01:14PM -0700, Dan Williams wrote:
> > > > Does anyone know why devmap is pte_special anyhow?
> >
> > It does not need to be special as mentioned here:
> >
> > http
On Sat, Oct 16, 2021 at 9:39 AM Matthew Wilcox wrote:
>
> On Sat, Oct 16, 2021 at 12:44:50PM -0300, Jason Gunthorpe wrote:
> > Assuming changing FSDAX is hard.. How would DAX people feel about just
> > deleting the PUD/PMD support until it can be done with compound pages?
>
> I think there are cus
On Sat, Oct 16, 2021 at 8:45 AM Jason Gunthorpe wrote:
>
> On Thu, Oct 14, 2021 at 06:37:35PM -0700, Dan Williams wrote:
> > On Thu, Oct 14, 2021 at 4:06 PM Jason Gunthorpe wrote:
> > >
> > > On Thu, Oct 14, 2021 at 12:01:14PM -0700, Dan Williams wrote:
> > &g
On Mon, Oct 18, 2021 at 11:26 AM Jason Gunthorpe wrote:
>
> On Sun, Oct 17, 2021 at 11:35:35AM -0700, Dan Williams wrote:
>
> > > DAX is stuffing arrays of 4k pages into the PUD/PMDs. Aligning with
> > > THP would make using normal refconting much simpler. I looked at
On Tue, Oct 19, 2021 at 9:02 AM Jason Gunthorpe wrote:
>
> On Tue, Oct 19, 2021 at 04:13:34PM +0100, Joao Martins wrote:
> > On 10/19/21 00:06, Jason Gunthorpe wrote:
> > > On Mon, Oct 18, 2021 at 12:37:30PM -0700, Dan Williams wrote:
> > >
> > >>>
On Wed, Oct 20, 2021 at 10:09 AM Joao Martins wrote:
>
> On 10/19/21 20:21, Dan Williams wrote:
> > On Tue, Oct 19, 2021 at 9:02 AM Jason Gunthorpe wrote:
> >>
> >> On Tue, Oct 19, 2021 at 04:13:34PM +0100, Joao Martins wrote:
> >>> On 10/19/21 00:06, Ja
is the practical benefit of these "optimize out the case when a
range is updated to read only" optimizations? Any numbers to show this
is worth the code thrash?
>
> [1]
> https://www.ozlabs.org/~akpm/mmotm/broken-out/mm-mmu_notifier-contextual-information-for-event-triggering-invalidation-
On Wed, Jan 23, 2019 at 3:05 PM Jerome Glisse wrote:
>
> On Wed, Jan 23, 2019 at 02:54:40PM -0800, Dan Williams wrote:
> > On Wed, Jan 23, 2019 at 2:23 PM wrote:
> > >
> > > From: Jérôme Glisse
> > >
> > > Hi Andrew, i see that you still have my e
On Tue, Feb 19, 2019 at 12:04 PM wrote:
>
> From: Jérôme Glisse
>
> Since last version [4] i added the extra bits needed for the change_pte
> optimization (which is a KSM thing). Here i am not posting users of
> this, they will be posted to the appropriate sub-systems (KVM, GPU,
> RDMA, ...) once
On Tue, Feb 19, 2019 at 12:30 PM Jerome Glisse wrote:
>
> On Tue, Feb 19, 2019 at 12:15:55PM -0800, Dan Williams wrote:
> > On Tue, Feb 19, 2019 at 12:04 PM wrote:
> > >
> > > From: Jérôme Glisse
> > >
> > > Since last version [4]
On Tue, Feb 19, 2019 at 12:41 PM Jason Gunthorpe wrote:
>
> On Tue, Feb 19, 2019 at 03:30:33PM -0500, Jerome Glisse wrote:
> > On Tue, Feb 19, 2019 at 12:15:55PM -0800, Dan Williams wrote:
> > > On Tue, Feb 19, 2019 at 12:04 PM wrote:
> > > >
> > > &g
On Tue, Feb 19, 2019 at 12:58 PM Jerome Glisse wrote:
>
> On Tue, Feb 19, 2019 at 12:40:37PM -0800, Dan Williams wrote:
> > On Tue, Feb 19, 2019 at 12:30 PM Jerome Glisse wrote:
> > >
> > > On Tue, Feb 19, 2019 at 12:15:55PM -0800, 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 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
ctl = dimm_ioctl,
> - .compat_ioctl = dimm_ioctl,
> + .compat_ioctl = compat_ptr_ioctl,
> .llseek = noop_llseek,
> };
Acked-by: Dan Williams
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
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
.com/KSPP/linux/issues/78
> Build-tested-by:
> https://lore.kernel.org/lkml/62b675ec.wkx6aoz6cbe71vtf%25...@intel.com/
> Signed-off-by: Gustavo A. R. Silva
> ---
> Hi all!
>
> JFYI: I'm adding this to my -next tree. :)
>
[..]
> include/uapi/linux/ndctl.h| 10 +--
For ndctl.h
Acked-by: Dan Williams
Christoph Hellwig wrote:
> On Wed, Sep 07, 2022 at 09:33:11AM -0300, Jason Gunthorpe wrote:
> > Yes, you said that, and I said that when the AMD driver first merged
> > it - but it went in anyhow and now people are using it in a bunch of
> > places.
>
> drm folks made up their own weird rules, if
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
[ 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
On Mon, Nov 11, 2019 at 4:07 PM John Hubbard wrote:
>
> As it says in the updated comment in gup.c: current FOLL_LONGTERM
> behavior is incompatible with FAULT_FLAG_ALLOW_RETRY because of the
> FS DAX check requirement on vmas.
>
> However, the corresponding restriction in get_user_pages_remote()
On Tue, Nov 12, 2019 at 2:24 PM John Hubbard wrote:
>
> On 11/12/19 1:57 PM, Dan Williams wrote:
> ...
> >> diff --git a/drivers/vfio/vfio_iommu_type1.c
> >> b/drivers/vfio/vfio_iommu_type1.c
> >> index d864277ea16f..017689b7c32b 100644
> >> ---
On Tue, Nov 12, 2019 at 2:43 PM John Hubbard wrote:
>
> On 11/12/19 12:43 PM, Jason Gunthorpe wrote:
> ...
> >> -}
> >> +ret = get_user_pages_remote(NULL, mm, vaddr, 1, flags | FOLL_LONGTERM,
> >> +page, vmas, NULL);
> >> +/*
> >> + * The lif
On Tue, Nov 12, 2019 at 3:08 PM John Hubbard wrote:
>
> On 11/12/19 2:43 PM, Dan Williams wrote:
> ...
> > Ah, sorry. This was the first time I had looked at this series and
> > jumped in without reading the background.
> >
> > Your patch as is looks ok, I assume
On Tue, Nov 12, 2019 at 3:43 PM Jason Gunthorpe wrote:
>
> On Tue, Nov 12, 2019 at 02:45:51PM -0800, Dan Williams wrote:
> > On Tue, Nov 12, 2019 at 2:43 PM John Hubbard wrote:
> > >
> > > On 11/12/19 12:43 PM, Jason Gunthorpe wrote:
> > > ...
&g
On Tue, Nov 12, 2019 at 5:08 PM John Hubbard wrote:
>
> On 11/12/19 4:58 PM, Dan Williams wrote:
> ...
> >>> It's not redundant relative to upstream which does not do anything the
> >>> FOLL_LONGTERM in the gup-slow path... but I have not looked at patches
&g
On Wed, Nov 13, 2019 at 2:43 AM Jan Kara wrote:
>
> On Tue 12-11-19 20:26:56, John Hubbard wrote:
> > Introduce pin_user_pages*() variations of get_user_pages*() calls,
> > and also pin_longterm_pages*() variations.
> >
> > These variants all set FOLL_PIN, which is also introduced, and
> > thoroug
On Tue, Nov 12, 2019 at 8:27 PM John Hubbard wrote:
>
> An upcoming patch changes and complicates the refcounting and
> especially the "put page" aspects of it. In order to keep
> everything clean, refactor the devmap page release routines:
>
> * Rename put_devmap_managed_page() to page_is_devmap_
On Wed, Nov 13, 2019 at 11:23 AM Dan Williams wrote:
>
> On Tue, Nov 12, 2019 at 8:27 PM John Hubbard wrote:
> >
> > An upcoming patch changes and complicates the refcounting and
> > especially the "put page" aspects of it. In order to keep
> > everything
On Wed, Nov 13, 2019 at 2:49 PM John Hubbard wrote:
>
> On 11/13/19 2:00 PM, Dan Williams wrote:
> ...
> >> Ugh, when did all this HMM specific manipulation sneak into the
> >> generic ZONE_DEVICE path? It used to be gated by pgmap type with its
> >> own
ser_page() experiments.
> Since then, Jérôme Glisse suggested the refactoring described above.
>
> Cc: Christoph Hellwig
> Suggested-by: Jérôme Glisse
> Reviewed-by: Dan Williams
> Reviewed-by: Jan Kara
> Signed-off-by: Ira Weiny
> Signed-off-by: John Hubbard
> -
On Wed, Dec 18, 2019 at 9:51 PM John Hubbard wrote:
>
> On 12/18/19 9:27 PM, Dan Williams wrote:
> ...
> >> @@ -461,5 +449,5 @@ void __put_devmap_managed_page(struct page *page)
> >> page->mapping = NULL;
> >> page->pgmap->ops-&
On Fri, Dec 20, 2019 at 5:34 AM Jason Gunthorpe wrote:
>
> On Thu, Dec 19, 2019 at 01:13:54PM -0800, John Hubbard wrote:
> > On 12/19/19 1:07 PM, Jason Gunthorpe wrote:
> > > On Thu, Dec 19, 2019 at 12:30:31PM -0800, John Hubbard wrote:
> > > > On 12/19/19 5:26 AM, Leon Romanovsky wrote:
> > > > >
On Fri, Dec 20, 2019 at 1:22 AM Jan Kara wrote:
>
> On Thu 19-12-19 12:30:31, John Hubbard wrote:
> > On 12/19/19 5:26 AM, Leon Romanovsky wrote:
> > > On Mon, Dec 16, 2019 at 02:25:12PM -0800, John Hubbard wrote:
> > > > Hi,
> > > >
> > > > This implements an API naming change (put_user_page*() -
On Fri, Dec 20, 2019 at 4:41 PM John Hubbard wrote:
>
> On 12/20/19 4:33 PM, Dan Williams wrote:
> ...
> >> I believe there might be also a different solution for this: For
> >> transparent huge pages, we could find a space in 'struct page' of the
> >&g
On Thu, Nov 21, 2019 at 12:57 AM John Hubbard wrote:
>
> On 11/21/19 12:05 AM, Christoph Hellwig wrote:
> > So while this looks correct and I still really don't see the major
> > benefit of the new code organization, especially as it bloats all
> > put_page callers.
> >
> > I'd love to see code si
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
Jason Gunthorpe via Lsf-pc wrote:
> I would like to have a session at LSF to talk about Matthew's
> physr discussion starter:
>
> https://lore.kernel.org/linux-mm/ydykweu0htv8m...@casper.infradead.org/
>
> I have become interested in this with some immediacy because of
> IOMMUFD and this other d
Matthew Wilcox wrote:
> On Mon, Jan 23, 2023 at 11:36:51AM -0800, Dan Williams wrote:
> > Jason Gunthorpe via Lsf-pc wrote:
> > > I would like to have a session at LSF to talk about Matthew's
> > > physr discussion starter:
> > >
> > &g
: Christoph Hellwig
Cc: John Hubbard
Cc: Alistair Popple
Cc: Felix Kuehling
Cc: Alex Deucher
Cc: "Christian König"
Cc: "Pan, Xinhui"
Cc: David Airlie
Cc: Daniel Vetter
Cc: Ben Skeggs
Cc: Karol Herbst
Cc: Lyude Paul
Cc: "Jérôme Glisse"
Suggested-by: J
Felix Kuehling wrote:
> Am 2022-10-20 um 17:56 schrieb Dan Williams:
> > A 'struct dev_pagemap' (pgmap) represents a collection of ZONE_DEVICE
> > pages. The pgmap is a reference counted object that serves a similar
> > role as a 'struct request_queue'. Liv
Jason Gunthorpe wrote:
> On Thu, Oct 20, 2022 at 02:56:39PM -0700, Dan Williams wrote:
> > A 'struct dev_pagemap' (pgmap) represents a collection of ZONE_DEVICE
> > pages. The pgmap is a reference counted object that serves a similar
> > role as a 'struct
On Sun, Oct 16, 2016 at 1:53 PM, Dave Airlie wrote:
> On 17 October 2016 at 04:41, Marek Olšák wrote:
>> On Fri, Oct 14, 2016 at 3:33 AM, Michel Dänzer
>> wrote:
>>>
>>> [ Adding Dan Williams and dri-devel ]
>>>
>>> On 14/10/16 03:28 AM, S
On Mon, Oct 17, 2016 at 8:48 PM, Dave Airlie wrote:
[..]
>>> Aren't there only 2 possibilities for this regression?
>>>
>>> 1/ a memtype entry was never made so track_pfn_insert() returns an
>>> uncached mapping
>>>
>>> 2/ a conflicting memtype entry exists and undefined behavior due to
>>> mixed
On Mon, Nov 21, 2016 at 12:36 PM, Deucher, Alexander
wrote:
> This is certainly not the first time this has been brought up, but I'd like
> to try and get some consensus on the best way to move this forward. Allowing
> devices to talk directly improves performance and reduces latency by avoidin
On Tue, Nov 22, 2016 at 10:59 AM, Serguei Sagalovitch
wrote:
> Dan,
>
> I personally like "device-DAX" idea but my concerns are:
>
> - How well it will co-exists with the DRM infrastructure / implementations
>in part dealing with CPU pointers?
Inside the kernel a device-DAX range is "just m
On Tue, Nov 22, 2016 at 12:10 PM, Daniel Vetter wrote:
> On Tue, Nov 22, 2016 at 9:01 PM, Dan Williams
> wrote:
>> On Tue, Nov 22, 2016 at 10:59 AM, Serguei Sagalovitch
>> wrote:
>>> I personally like "device-DAX" idea but my concerns are:
>>>
&
On Tue, Nov 22, 2016 at 1:03 PM, Daniel Vetter wrote:
> On Tue, Nov 22, 2016 at 9:35 PM, Serguei Sagalovitch
> wrote:
>>
>> On 2016-11-22 03:10 PM, Daniel Vetter wrote:
>>>
>>> On Tue, Nov 22, 2016 at 9:01 PM, Dan Williams
>>> wrote:
>&g
On Wed, Nov 23, 2016 at 9:27 AM, Bart Van Assche
wrote:
> On 11/23/2016 09:13 AM, Logan Gunthorpe wrote:
>>
>> IMO any memory that has been registered for a P2P transaction should be
>> locked from being evicted. So if there's a get_user_pages call it needs
>> to be pinned until the put_page. The
On Wed, Nov 23, 2016 at 1:55 PM, Jason Gunthorpe
wrote:
> On Wed, Nov 23, 2016 at 02:11:29PM -0700, Logan Gunthorpe wrote:
>> > As I said, there is no possible special handling. Standard IB hardware
>> > does not support changing the DMA address once a MR is created. Forget
>> > about doing that.
he
typical -mm route for v4.9 since it has potential to change behavior in
its DRI usages, needs soak time in -next, and there no known memtype
conflict problems it would fix.
[1]: https://lists.01.org/pipermail/linux-nvdimm/2016-September/006781.html
---
Dan Williams (2):
mm: fix cache mode
arrange for devm_memremap_pages() to
establish the write-back-cache reservation in the memtype tree.
Cc:
Cc: Matthew Wilcox
Cc: Andrew Morton
Cc: Ross Zwisler
Cc: Nilesh Choudhury
Cc: Kirill A. Shutemov
Reported-by: Toshi Kani
Reported-by: Kai Zhang
Signed-off-by: Dan Williams
---
arch/x86/mm
given physical address range.
Cc: David Airlie
Cc: dri-devel at lists.freedesktop.org
Cc: Matthew Wilcox
Cc: Andrew Morton
Cc: Ross Zwisler
Signed-off-by: Dan Williams
---
mm/memory.c |8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/mm/memory.c b/mm/memory.c
On Wed, Feb 17, 2016 at 4:17 AM, Andy Shevchenko
wrote:
> Instead of opencoding the existing library functions let's use them directly.
>
> The conversion fixes a potential bug in int340x_thermal as well since we have
> to use memcmp() on binary data.
>
> Signed-off-by: Andy Shevchenko
> ---
> d
1 - 100 of 222 matches
Mail list logo
