В Пн, 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 <o...@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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
