Re: [PATCH v13 2/4] mm/slub: allow to set node and align in k[v]realloc
"Danilo Krummrich" <[email protected]>
| Newsgroups | org.kernel.vger.linux-bcachefs,org.kernel.vger.bpf,org.kernel.vger.linux-kernel,org.kernel.vger.rust-for-linux,org.kvack.linux-mm |
|---|---|
| Message-ID | <[email protected]> |
On Tue Jul 15, 2025 at 5:48 PM CEST, Danilo Krummrich wrote:
> On Tue Jul 15, 2025 at 5:34 PM CEST, Vlastimil Babka wrote:
>> On 7/15/25 16:33, Danilo Krummrich wrote:
>>> On Tue Jul 15, 2025 at 3:58 PM CEST, Vitaly Wool wrote:
>>>> diff --git a/fs/bcachefs/darray.c b/fs/bcachefs/darray.c
>>>> index e86d36d23e9e..928e83a1ce42 100644
>>>> --- a/fs/bcachefs/darray.c
>>>> +++ b/fs/bcachefs/darray.c
>>>> @@ -21,7 +21,7 @@ int __bch2_darray_resize_noprof(darray_char *d, size_t element_size, size_t new_
>>>> return -ENOMEM;
>>>>
>>>> void *data = likely(bytes < INT_MAX)
>>>> - ? kvmalloc_noprof(bytes, gfp)
>>>> + ? kvmalloc_node_align_noprof(bytes, 1, gfp, NUMA_NO_NODE)
>>>> : vmalloc_noprof(bytes);
>>>> if (!data)
>>>> return -ENOMEM;
>>>> diff --git a/fs/bcachefs/util.h b/fs/bcachefs/util.h
>>>> index 0a4b1d433621..2d6d4b547db8 100644
>>>> --- a/fs/bcachefs/util.h
>>>> +++ b/fs/bcachefs/util.h
>>>> @@ -61,7 +61,7 @@ static inline void *bch2_kvmalloc_noprof(size_t n, gfp_t flags)
>>>> {
>>>> void *p = unlikely(n >= INT_MAX)
>>>> ? vmalloc_noprof(n)
>>>> - : kvmalloc_noprof(n, flags & ~__GFP_ZERO);
>>>> + : kvmalloc_node_align_noprof(n, 1, flags & ~__GFP_ZERO, NUMA_NO_NODE);
>>>> if (p && (flags & __GFP_ZERO))
>>>> memset(p, 0, n);
>>>> return p;
>>>
>>> I assume this is because kvmalloc(), and hence kvrealloc(), does this:
>>>
>>> /* Don't even allow crazy sizes */
>>> if (unlikely(size > INT_MAX)) {
>>> WARN_ON_ONCE(!(flags & __GFP_NOWARN));
>>> return NULL;
>>> }
>>>
>>> Do we still consider this a "crazy size"? :)
>>
>> Yeah, with "we" including Linus:
>> https://lore.kernel.org/all/CAHk-=wi=PrbZnwnvhKEF6UUQNCZdNsUbr+hk-jOWGr-q4Mmz=Q@mail.gmail.com/
>
> I don't know why bcachefs needs this, hence my question. But I agree that this
> clearly raises an eyebrow. :)
I.e. this is me noting that we're considering anything larger to be unreasonable
while having an in-tree user bypassing this check intentionally.