Message ID | 20210714224225.Gmo7sht2E%akpm@linux-foundation.org |
---|---|
State | New |
Headers | show |
Series | + kfence-skip-all-gfp_zonemask-allocations.patch added to -mm tree | expand |
On Thu, Jul 15, 2021 at 12:42 AM <akpm@linux-foundation.org> wrote: > > > The patch titled > Subject: kfence: skip all GFP_ZONEMASK allocations > has been added to the -mm tree. Its filename is > kfence-skip-all-gfp_zonemask-allocations.patch > > This patch should soon appear at > https://ozlabs.org/~akpm/mmots/broken-out/kfence-skip-all-gfp_zonemask-allocations.patch > and later at > https://ozlabs.org/~akpm/mmotm/broken-out/kfence-skip-all-gfp_zonemask-allocations.patch Hi Andrew, mmotm and mmots were last updated on 2021-06-25, did some automation break?
On Thu, 15 Jul 2021 15:51:30 +0200 Alexander Potapenko <glider@google.com> wrote: > On Thu, Jul 15, 2021 at 12:42 AM <akpm@linux-foundation.org> wrote: > > > > > > The patch titled > > Subject: kfence: skip all GFP_ZONEMASK allocations > > has been added to the -mm tree. Its filename is > > kfence-skip-all-gfp_zonemask-allocations.patch > > > > This patch should soon appear at > > https://ozlabs.org/~akpm/mmots/broken-out/kfence-skip-all-gfp_zonemask-allocations.patch > > and later at > > https://ozlabs.org/~akpm/mmotm/broken-out/kfence-skip-all-gfp_zonemask-allocations.patch > > Hi Andrew, > > mmotm and mmots were last updated on 2021-06-25, did some automation break? This happens after -rc1. I'm in the process of going through all the material which was sent along too late for 5.14. And mainline & -next tend to be a bit chaotic at this point, so it's a decent time to just sit and wait for the dust to settle. Hopefully I'll be able to push something out later today.
--- a/mm/kfence/core.c~kfence-skip-all-gfp_zonemask-allocations +++ a/mm/kfence/core.c @@ -741,6 +741,15 @@ void *__kfence_alloc(struct kmem_cache * return NULL; /* + * Skip allocations from non-default zones, including DMA. We cannot + * guarantee that pages in the KFENCE pool will have the requested + * properties (e.g. reside in DMAable memory). + */ + if ((flags & GFP_ZONEMASK) || + (s->flags & (SLAB_CACHE_DMA | SLAB_CACHE_DMA32))) + return NULL; + + /* * allocation_gate only needs to become non-zero, so it doesn't make * sense to continue writing to it and pay the associated contention * cost, in case we have a large number of concurrent allocations.