Messages in this thread |  | | Subject | Re: [PATCH 2/3] introduce probe_slab_address() | From | Kirill Tkhai <> | Date | Tue, 28 Oct 2014 08:44:51 +0300 |
| |
В Пн, 27/10/2014 в 20:54 +0100, Oleg Nesterov пишет: > Extract the ifdef(CONFIG_DEBUG_PAGEALLOC) code from get_freepointer_safe() > into the new generic helper, probe_slab_address(). The next patch will add > another user. > > Signed-off-by: Oleg Nesterov <oleg@redhat.com> > --- > include/linux/uaccess.h | 15 +++++++++++++++ > mm/slub.c | 6 +----- > 2 files changed, 16 insertions(+), 5 deletions(-) > > diff --git a/include/linux/uaccess.h b/include/linux/uaccess.h > index effb637..3367396 100644 > --- a/include/linux/uaccess.h > +++ b/include/linux/uaccess.h > @@ -71,6 +71,21 @@ static inline unsigned long __copy_from_user_nocache(void *to, > __probe_kernel_read(&(retval), (__force void *)(addr), sizeof(retval)) > > /* > + * Same as probe_kernel_address(), but @addr must be the valid pointer > + * to a slab object, potentially freed/reused/unmapped. > + */ > +#ifdef CONFIG_DEBUG_PAGEALLOC > +#define probe_slab_address(addr, retval) \ > + probe_kernel_address(addr, retval) > +#else > +#define probe_slab_address(addr, retval) \ > + ({ \ > + (retval) = *(typeof(retval) *)(addr); \ > + 0; \ > + }) > +#endif > + > +/* > * probe_kernel_read(): safely attempt to read from a location > * @dst: pointer to the buffer that shall take the data > * @src: address to read from > diff --git a/mm/slub.c b/mm/slub.c > index 3e8afcc..0467d22 100644 > --- a/mm/slub.c > +++ b/mm/slub.c > @@ -265,11 +265,7 @@ static inline void *get_freepointer_safe(struct kmem_cache *s, void *object) > { > void *p; > > -#ifdef CONFIG_DEBUG_PAGEALLOC > - probe_kernel_read(&p, (void **)(object + s->offset), sizeof(p)); > -#else > - p = get_freepointer(s, object); > -#endif > + probe_slab_address(object + s->offset, p); > return p; > } >
probe_kernel_read() was arch-dependent on tree platforms:
arch/blackfin/mm/maccess.c arch/parisc/lib/memcpy.c arch/um/kernel/maccess.c
But now we skip these arch-dependent implementations. Is there no a problem?
Kirill
-- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |