linux-kernel - Re: [PATCH] mm: util: update the kerneldoc for kstrdup

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 30 Jun 2020 16:36:34 +0200
From:   David Hildenbrand <david@...hat.com>
To:     Joe Perches <joe@...ches.com>, Bartosz Golaszewski <brgl@...ev.pl>,
        Andrew Morton <akpm@...ux-foundation.org>
Cc:     linux-mm@...ck.org, linux-kernel@...r.kernel.org,
        Bartosz Golaszewski <bgolaszewski@...libre.com>
Subject: 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 <bgolaszewski@...libre.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