[PATCH] mm: util: update the kerneldoc for kstrdup_const()

[PATCH] mm: util: update the kerneldoc for kstrdup_const()

[Bartosz Golaszewski]

From: Bartosz Golaszewski <bgolaszewski@baylibre.com>

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.

Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
---
 mm/util.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/mm/util.c b/mm/util.c
index c63c8e47be57..27d6155edb8f 100644
--- a/mm/util.c
+++ b/mm/util.c
@@ -69,7 +69,8 @@ EXPORT_SYMBOL(kstrdup);
  * @s: the string to duplicate
  * @gfp: the GFP mask used in the kmalloc() call when allocating memory
  *
- * Note: Strings allocated by kstrdup_const should be freed by kfree_const.
+ * Note: Strings allocated by kstrdup_const should be freed by kfree_const and
+ * must not be passed to krealloc().
  *
  * Return: source string if it is in .rodata section otherwise
  * fallback to kstrdup.
-- 
2.26.1

Re: [PATCH] mm: util: update the kerneldoc for kstrdup_const()

[Joe Perches]

On Sun, 2020-06-28 at 17:25 +0200, Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
> 
> 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;

Re: [PATCH] mm: util: update the kerneldoc for kstrdup_const()

[Bartosz Golaszewski]

On Sun, Jun 28, 2020 at 7:37 PM Joe Perches <joe@perches.com> wrote:
>
> On Sun, 2020-06-28 at 17:25 +0200, Bartosz Golaszewski wrote:
> > From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
> >
> > 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()

[Joe Perches]

On Sun, 2020-06-28 at 20:06 +0200, Bartosz Golaszewski wrote:
> On Sun, Jun 28, 2020 at 7:37 PM Joe Perches <joe@perches.com> wrote:
> > On Sun, 2020-06-28 at 17:25 +0200, Bartosz Golaszewski wrote:
> > > From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
> > > 
> > > 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()

[David Hildenbrand]

On 28.06.20 19:37, Joe Perches wrote:
> On Sun, 2020-06-28 at 17:25 +0200, Bartosz Golaszewski wrote:
>> From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
>>
>> 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()

[Joe Perches]

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 <bgolaszewski@baylibre.com>
> > > 
> > > 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.camel@perches.com/

Re: [PATCH] mm: util: update the kerneldoc for kstrdup_const()

[David Hildenbrand]

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 <bgolaszewski@baylibre.com>
>>>>
>>>> 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.camel@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()

[Joe Perches]

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 <bgolaszewski@baylibre.com>
> > > > > 
> > > > > 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.camel@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()

[David Hildenbrand]

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 <bgolaszewski@baylibre.com>
>>>>>>
>>>>>> 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.camel@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()

[Joe Perches]

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 <bgolaszewski@baylibre.com>
> > > > > > > 
> > > > > > > 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.camel@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.