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@xxxxxxxxxxxx>
>>>>>>
>>>>>> 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@xxxxxxxxxxx/
> []
>> 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