[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAMRc=Mdre+ZKQEXGdavHXqoo=41YDmfnU_-im=4FepYdy1ob0g@mail.gmail.com>
Date: Fri, 19 Oct 2018 16:42:28 +0200
From: Bartosz Golaszewski <brgl@...ev.pl>
To: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc: Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [RESEND PATCH v6 2/4] mm: move is_kernel_rodata() to asm-generic/sections.h
wt., 16 paź 2018 o 12:53 Greg Kroah-Hartman
<gregkh@...uxfoundation.org> napisał(a):
>
> On Sun, Oct 14, 2018 at 05:20:08PM +0200, Bartosz Golaszewski wrote:
> > Export this routine so that we can use it later in devm_kstrdup_const()
> > and devm_kfree().
> >
> > Signed-off-by: Bartosz Golaszewski <brgl@...ev.pl>
> > Reviewed-by: Bjorn Andersson <bjorn.andersson@...aro.org>
> > Acked-by: Mike Rapoport <rppt@...ux.vnet.ibm.com>
> > Acked-by: Rasmus Villemoes <linux@...musvillemoes.dk>
> > Reviewed-by: Geert Uytterhoeven <geert+renesas@...der.be>
> > Reviewed-by: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
> > ---
> > include/asm-generic/sections.h | 14 ++++++++++++++
> > mm/util.c | 7 -------
> > 2 files changed, 14 insertions(+), 7 deletions(-)
> >
> > diff --git a/include/asm-generic/sections.h b/include/asm-generic/sections.h
> > index 849cd8eb5ca0..d79abca81a52 100644
> > --- a/include/asm-generic/sections.h
> > +++ b/include/asm-generic/sections.h
> > @@ -141,4 +141,18 @@ static inline bool init_section_intersects(void *virt, size_t size)
> > return memory_intersects(__init_begin, __init_end, virt, size);
> > }
> >
> > +/**
> > + * is_kernel_rodata - checks if the pointer address is located in the
> > + * .rodata section
> > + *
> > + * @addr: address to check
> > + *
> > + * Returns: true if the address is located in .rodata, false otherwise.
> > + */
> > +static inline bool is_kernel_rodata(unsigned long addr)
> > +{
> > + return addr >= (unsigned long)__start_rodata &&
> > + addr < (unsigned long)__end_rodata;
>
> Those symbols are not exported, are you sure this is going to work for a
> kernel module that ends up using this function?
>
I tested it with a loaded module, yes.
> I'll take it, but be aware of the future complications that might happen
> here...
>
These symbols are built-in for all architectures. Do they even need
exporting? On the off-chance that something fails, we can move this
function back to mm/util.c as it was in the first version of this
series.
Best regards,
Bartosz Golaszewski
Powered by blists - more mailing lists