Re: [PATCH] mm: util: update the kerneldoc for kstrdup_const()
On Tue, 2020-06-30 at 16:36 +0200, David Hildenbrand wrote: > On 30.06.20 16:14, Joe Perches wrote: > > On Tue, 2020-06-30 at 10:57 +0200, David Hildenbrand wrote: > > > On 29.06.20 21:21, Joe Perches wrote: > > > > On Mon, 2020-06-29 at 12:54 +0200, David Hildenbrand wrote: > > > > > On 28.06.20 19:37, Joe Perches wrote: > > > > > > On Sun, 2020-06-28 at 17:25 +0200, Bartosz Golaszewski wrote: > > > > > > > From: Bartosz Golaszewski > > > > > > > > > > > > > > Memory allocated with kstrdup_const() must not be passed to > > > > > > > regular > > > > > > > krealloc() as it is not aware of the possibility of the chunk > > > > > > > residing > > > > > > > in .rodata. Since there are no potential users of krealloc_const() > > > > > > > at the moment, let's just update the doc to make it explicit. > > > > > > > > > > > > Another option would be to return NULL if it's > > > > > > used from krealloc with a pointer into rodata > > > > [] > > > > > > diff --git a/mm/slab_common.c b/mm/slab_common.c > > > > [] > > > > > > @@ -1683,6 +1683,9 @@ static __always_inline void > > > > > > *__do_krealloc(const void *p, size_t new_size, > > > > > > * @new_size: how many bytes of memory are required. > > > > > > * @flags: the type of memory to allocate. > > > > > > * > > > > > > + * If the object pointed to is in rodata (likely from > > > > > > kstrdup_const) > > > > > > + * %NULL is returned. > > > > > > + * > > > > [] > > > > > Won't we have similar issues if somebody would do a kfree() instead > > > > > of a > > > > > kfree_const()? So I think the original patch makes sense. > > > > > > > > Which is why I also suggested making kfree work for > > > > more types of memory freeing earlier this month. > > > > > > > > https://lore.kernel.org/lkml/573b3fbd5927c643920e1364230c296b23e7584d.ca...@perches.com/ > > [] > > > what's the real benefit that is worth spending extra runtime cycles? > > > > I very much doubt there is an actual instance > > where the runtime cycles matter. Where could > > there be a fast-path instance of free? > > Well, looking at kfree() I can directly spot "unlikely()", which sounds > like somebody cares about branch prediction in the slab. Or is telling the compiler of a 95%+ likely case. > Once you have cases that can happen equally likely it most certainly > degrades performance. The question is if we care. Right. Does 4 additional tests in what appears to be almost exclusively non-fast paths matter? > Coming back to my question, so the major benefit you see is coding > simplicity, correct? Yes.
Re: [PATCH] mm: util: update the kerneldoc for kstrdup_const()
On 30.06.20 16:14, Joe Perches wrote: > On Tue, 2020-06-30 at 10:57 +0200, David Hildenbrand wrote: >> On 29.06.20 21:21, Joe Perches wrote: >>> On Mon, 2020-06-29 at 12:54 +0200, David Hildenbrand wrote: On 28.06.20 19:37, Joe Perches wrote: > On Sun, 2020-06-28 at 17:25 +0200, Bartosz Golaszewski wrote: >> From: Bartosz Golaszewski >> >> Memory allocated with kstrdup_const() must not be passed to regular >> krealloc() as it is not aware of the possibility of the chunk residing >> in .rodata. Since there are no potential users of krealloc_const() >> at the moment, let's just update the doc to make it explicit. > > Another option would be to return NULL if it's > used from krealloc with a pointer into rodata >>> [] > diff --git a/mm/slab_common.c b/mm/slab_common.c >>> [] > @@ -1683,6 +1683,9 @@ static __always_inline void *__do_krealloc(const > void *p, size_t new_size, > * @new_size: how many bytes of memory are required. > * @flags: the type of memory to allocate. > * > + * If the object pointed to is in rodata (likely from kstrdup_const) > + * %NULL is returned. > + * >>> [] Won't we have similar issues if somebody would do a kfree() instead of a kfree_const()? So I think the original patch makes sense. >>> >>> Which is why I also suggested making kfree work for >>> more types of memory freeing earlier this month. >>> >>> https://lore.kernel.org/lkml/573b3fbd5927c643920e1364230c296b23e7584d.ca...@perches.com/ > [] >> what's the real benefit that is worth spending extra runtime cycles? > > I very much doubt there is an actual instance > where the runtime cycles matter. Where could > there be a fast-path instance of free? Well, looking at kfree() I can directly spot "unlikely()", which sounds like somebody cares about branch prediction in the slab. Once you have cases that can happen equally likely it most certainly degrades performance. The question is if we care. Coming back to my question, so the major benefit you see is coding simplicity, correct? -- Thanks, David / dhildenb
Re: [PATCH] mm: util: update the kerneldoc for kstrdup_const()
On Tue, 2020-06-30 at 10:57 +0200, David Hildenbrand wrote: > On 29.06.20 21:21, Joe Perches wrote: > > On Mon, 2020-06-29 at 12:54 +0200, David Hildenbrand wrote: > > > On 28.06.20 19:37, Joe Perches wrote: > > > > On Sun, 2020-06-28 at 17:25 +0200, Bartosz Golaszewski wrote: > > > > > From: Bartosz Golaszewski > > > > > > > > > > Memory allocated with kstrdup_const() must not be passed to regular > > > > > krealloc() as it is not aware of the possibility of the chunk residing > > > > > in .rodata. Since there are no potential users of krealloc_const() > > > > > at the moment, let's just update the doc to make it explicit. > > > > > > > > Another option would be to return NULL if it's > > > > used from krealloc with a pointer into rodata > > [] > > > > diff --git a/mm/slab_common.c b/mm/slab_common.c > > [] > > > > @@ -1683,6 +1683,9 @@ static __always_inline void *__do_krealloc(const > > > > void *p, size_t new_size, > > > > * @new_size: how many bytes of memory are required. > > > > * @flags: the type of memory to allocate. > > > > * > > > > + * If the object pointed to is in rodata (likely from kstrdup_const) > > > > + * %NULL is returned. > > > > + * > > [] > > > Won't we have similar issues if somebody would do a kfree() instead of a > > > kfree_const()? So I think the original patch makes sense. > > > > Which is why I also suggested making kfree work for > > more types of memory freeing earlier this month. > > > > https://lore.kernel.org/lkml/573b3fbd5927c643920e1364230c296b23e7584d.ca...@perches.com/ [] > what's the real benefit that is worth spending extra runtime cycles? I very much doubt there is an actual instance where the runtime cycles matter. Where could there be a fast-path instance of free? ANd kvfree consolidation and coding simplicity make it somewhat useful.
Re: [PATCH] mm: util: update the kerneldoc for kstrdup_const()
On 29.06.20 21:21, Joe Perches wrote: > On Mon, 2020-06-29 at 12:54 +0200, David Hildenbrand wrote: >> On 28.06.20 19:37, Joe Perches wrote: >>> On Sun, 2020-06-28 at 17:25 +0200, Bartosz Golaszewski wrote: From: Bartosz Golaszewski Memory allocated with kstrdup_const() must not be passed to regular krealloc() as it is not aware of the possibility of the chunk residing in .rodata. Since there are no potential users of krealloc_const() at the moment, let's just update the doc to make it explicit. >>> >>> Another option would be to return NULL if it's >>> used from krealloc with a pointer into rodata > [] >>> diff --git a/mm/slab_common.c b/mm/slab_common.c > [] >>> @@ -1683,6 +1683,9 @@ static __always_inline void *__do_krealloc(const void >>> *p, size_t new_size, >>> * @new_size: how many bytes of memory are required. >>> * @flags: the type of memory to allocate. >>> * >>> + * If the object pointed to is in rodata (likely from kstrdup_const) >>> + * %NULL is returned. >>> + * > [] >> Won't we have similar issues if somebody would do a kfree() instead of a >> kfree_const()? So I think the original patch makes sense. > > Which is why I also suggested making kfree work for > more types of memory freeing earlier this month. > > https://lore.kernel.org/lkml/573b3fbd5927c643920e1364230c296b23e7584d.ca...@perches.com/ I'm curious, do we see a lot of BUGs that resulted from wrong usage such that we need runtime checks for such things that the code can just statically specify (If I use kstrdup_const() for allocation I can just use kfree_const() for freeing - no runtime checks needed). IOW, what's the real benefit that is worth spending extra runtime cycles? -- Thanks, David / dhildenb
Re: [PATCH] mm: util: update the kerneldoc for kstrdup_const()
On Mon, 2020-06-29 at 12:54 +0200, David Hildenbrand wrote: > On 28.06.20 19:37, Joe Perches wrote: > > On Sun, 2020-06-28 at 17:25 +0200, Bartosz Golaszewski wrote: > > > From: Bartosz Golaszewski > > > > > > Memory allocated with kstrdup_const() must not be passed to regular > > > krealloc() as it is not aware of the possibility of the chunk residing > > > in .rodata. Since there are no potential users of krealloc_const() > > > at the moment, let's just update the doc to make it explicit. > > > > Another option would be to return NULL if it's > > used from krealloc with a pointer into rodata [] > > diff --git a/mm/slab_common.c b/mm/slab_common.c [] > > @@ -1683,6 +1683,9 @@ static __always_inline void *__do_krealloc(const void > > *p, size_t new_size, > > * @new_size: how many bytes of memory are required. > > * @flags: the type of memory to allocate. > > * > > + * If the object pointed to is in rodata (likely from kstrdup_const) > > + * %NULL is returned. > > + * [] > Won't we have similar issues if somebody would do a kfree() instead of a > kfree_const()? So I think the original patch makes sense. Which is why I also suggested making kfree work for more types of memory freeing earlier this month. https://lore.kernel.org/lkml/573b3fbd5927c643920e1364230c296b23e7584d.ca...@perches.com/
Re: [PATCH] mm: util: update the kerneldoc for kstrdup_const()
On 28.06.20 19:37, Joe Perches wrote:
> On Sun, 2020-06-28 at 17:25 +0200, Bartosz Golaszewski wrote:
>> From: Bartosz Golaszewski
>>
>> Memory allocated with kstrdup_const() must not be passed to regular
>> krealloc() as it is not aware of the possibility of the chunk residing
>> in .rodata. Since there are no potential users of krealloc_const()
>> at the moment, let's just update the doc to make it explicit.
>
> Another option would be to return NULL if it's
> used from krealloc with a pointer into rodata
> ---
> mm/slab_common.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/mm/slab_common.c b/mm/slab_common.c
> index 37d48a56431d..f8b49656171b 100644
> --- a/mm/slab_common.c
> +++ b/mm/slab_common.c
> @@ -1683,6 +1683,9 @@ static __always_inline void *__do_krealloc(const void
> *p, size_t new_size,
> * @new_size: how many bytes of memory are required.
> * @flags: the type of memory to allocate.
> *
> + * If the object pointed to is in rodata (likely from kstrdup_const)
> + * %NULL is returned.
> + *
> * The contents of the object pointed to are preserved up to the
> * lesser of the new and old sizes. If @p is %NULL, krealloc()
> * behaves exactly like kmalloc(). If @new_size is 0 and @p is not a
> @@ -1694,6 +1697,9 @@ void *krealloc(const void *p, size_t new_size, gfp_t
> flags)
> {
> void *ret;
>
> + if (unlikely(is_kernel_rodata((unsigned long)p)))
> + return NULL;
> +
> if (unlikely(!new_size)) {
> kfree(p);
> return ZERO_SIZE_PTR;
>
Won't we have similar issues if somebody would do a kfree() instead of a
kfree_const()? So I think the original patch makes sense.
--
Thanks,
David / dhildenb
Re: [PATCH] mm: util: update the kerneldoc for kstrdup_const()
On Sun, 2020-06-28 at 20:06 +0200, Bartosz Golaszewski wrote:
> On Sun, Jun 28, 2020 at 7:37 PM Joe Perches wrote:
> > On Sun, 2020-06-28 at 17:25 +0200, Bartosz Golaszewski wrote:
> > > From: Bartosz Golaszewski
> > >
> > > Memory allocated with kstrdup_const() must not be passed to regular
> > > krealloc() as it is not aware of the possibility of the chunk residing
> > > in .rodata. Since there are no potential users of krealloc_const()
> > > at the moment, let's just update the doc to make it explicit.
> >
> > Another option would be to return NULL if it's
> > used from krealloc with a pointer into rodata
> > ---
> > mm/slab_common.c | 6 ++
> > 1 file changed, 6 insertions(+)
> >
> > diff --git a/mm/slab_common.c b/mm/slab_common.c
> > index 37d48a56431d..f8b49656171b 100644
> > --- a/mm/slab_common.c
> > +++ b/mm/slab_common.c
> > @@ -1683,6 +1683,9 @@ static __always_inline void *__do_krealloc(const void
> > *p, size_t new_size,
> > * @new_size: how many bytes of memory are required.
> > * @flags: the type of memory to allocate.
> > *
> > + * If the object pointed to is in rodata (likely from kstrdup_const)
> > + * %NULL is returned.
> > + *
> > * The contents of the object pointed to are preserved up to the
> > * lesser of the new and old sizes. If @p is %NULL, krealloc()
> > * behaves exactly like kmalloc(). If @new_size is 0 and @p is not a
> > @@ -1694,6 +1697,9 @@ void *krealloc(const void *p, size_t new_size, gfp_t
> > flags)
> > {
> > void *ret;
> >
> > + if (unlikely(is_kernel_rodata((unsigned long)p)))
> > + return NULL;
> > +
> > if (unlikely(!new_size)) {
> > kfree(p);
> > return ZERO_SIZE_PTR;
> >
> >
> >
>
> In that case we should probably add a WARN_ON() - otherwise the user
> will be baffled by krealloc() failing.
Maybe:
---
mm/slab_common.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/mm/slab_common.c b/mm/slab_common.c
index a143a8c8f874..06c2714ab8c9 100644
--- a/mm/slab_common.c
+++ b/mm/slab_common.c
@@ -1073,6 +1073,9 @@ static __always_inline void *__do_krealloc(const void *p,
size_t new_size,
* @new_size: how many bytes of memory are required.
* @flags: the type of memory to allocate.
*
+ * If the object pointed to is in rodata (likely from kstrdup_const)
+ * %NULL is returned.
+ *
* The contents of the object pointed to are preserved up to the
* lesser of the new and old sizes. If @p is %NULL, krealloc()
* behaves exactly like kmalloc(). If @new_size is 0 and @p is not a
@@ -1084,6 +1087,14 @@ void *krealloc(const void *p, size_t new_size, gfp_t
flags)
{
void *ret;
+ if (unlikely(is_kernel_rodata((unsigned long)p))) {
+ if (!(flags & __GFP_NOWARN)) {
+ printk(KERN_DEFAULT "invalid use of krealloc with const
rodata\n");
+ dump_stack();
+ }
+ return NULL;
+ }
+
if (unlikely(!new_size)) {
kfree(p);
return ZERO_SIZE_PTR;
Re: [PATCH] mm: util: update the kerneldoc for kstrdup_const()
On Sun, Jun 28, 2020 at 7:37 PM Joe Perches wrote:
>
> On Sun, 2020-06-28 at 17:25 +0200, Bartosz Golaszewski wrote:
> > From: Bartosz Golaszewski
> >
> > Memory allocated with kstrdup_const() must not be passed to regular
> > krealloc() as it is not aware of the possibility of the chunk residing
> > in .rodata. Since there are no potential users of krealloc_const()
> > at the moment, let's just update the doc to make it explicit.
>
> Another option would be to return NULL if it's
> used from krealloc with a pointer into rodata
> ---
> mm/slab_common.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/mm/slab_common.c b/mm/slab_common.c
> index 37d48a56431d..f8b49656171b 100644
> --- a/mm/slab_common.c
> +++ b/mm/slab_common.c
> @@ -1683,6 +1683,9 @@ static __always_inline void *__do_krealloc(const void
> *p, size_t new_size,
> * @new_size: how many bytes of memory are required.
> * @flags: the type of memory to allocate.
> *
> + * If the object pointed to is in rodata (likely from kstrdup_const)
> + * %NULL is returned.
> + *
> * The contents of the object pointed to are preserved up to the
> * lesser of the new and old sizes. If @p is %NULL, krealloc()
> * behaves exactly like kmalloc(). If @new_size is 0 and @p is not a
> @@ -1694,6 +1697,9 @@ void *krealloc(const void *p, size_t new_size, gfp_t
> flags)
> {
> void *ret;
>
> + if (unlikely(is_kernel_rodata((unsigned long)p)))
> + return NULL;
> +
> if (unlikely(!new_size)) {
> kfree(p);
> return ZERO_SIZE_PTR;
>
>
>
In that case we should probably add a WARN_ON() - otherwise the user
will be baffled by krealloc() failing.
Bartosz
Re: [PATCH] mm: util: update the kerneldoc for kstrdup_const()
On Sun, 2020-06-28 at 17:25 +0200, Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski
>
> Memory allocated with kstrdup_const() must not be passed to regular
> krealloc() as it is not aware of the possibility of the chunk residing
> in .rodata. Since there are no potential users of krealloc_const()
> at the moment, let's just update the doc to make it explicit.
Another option would be to return NULL if it's
used from krealloc with a pointer into rodata
---
mm/slab_common.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/mm/slab_common.c b/mm/slab_common.c
index 37d48a56431d..f8b49656171b 100644
--- a/mm/slab_common.c
+++ b/mm/slab_common.c
@@ -1683,6 +1683,9 @@ static __always_inline void *__do_krealloc(const void *p,
size_t new_size,
* @new_size: how many bytes of memory are required.
* @flags: the type of memory to allocate.
*
+ * If the object pointed to is in rodata (likely from kstrdup_const)
+ * %NULL is returned.
+ *
* The contents of the object pointed to are preserved up to the
* lesser of the new and old sizes. If @p is %NULL, krealloc()
* behaves exactly like kmalloc(). If @new_size is 0 and @p is not a
@@ -1694,6 +1697,9 @@ void *krealloc(const void *p, size_t new_size, gfp_t
flags)
{
void *ret;
+ if (unlikely(is_kernel_rodata((unsigned long)p)))
+ return NULL;
+
if (unlikely(!new_size)) {
kfree(p);
return ZERO_SIZE_PTR;
