Re: [GIT PULL] io_uring fix for 6.17-rc5

[Jens Axboe <axboe@kernel.dk>]

On 9/5/25 1:04 PM, Jens Axboe wrote:
> On 9/5/25 11:24 AM, Linus Torvalds wrote:
>> On Fri, 5 Sept 2025 at 04:18, Jens Axboe <axboe@kernel.dk> wrote:
>>>
>>> Just a single fix for an issue with the resource node rewrite that
>>> happened a few releases ago. Please pull!
>>
>> I've pulled this, but the commentary is strange, and the patch makes
>> no sense to me, so I unpulled it again.
>>
>> Yes, it changes things from kvmalloc_array() to kvcalloc(). Fine.
>>
>> And yes, kvcalloc() clearly clears the resulting allocation. Also fine.
>>
>> But even in the old version, it used __GFP_ZERO.
>>
>> In fact, afaik the *ONLY* difference between kvcalloc() and
>> kvmalloc_array() array is that kvcalloc() adds the __GFP_ZERO to the
>> flags argument:
>>
>>    #define kvcalloc_node_noprof(_n,_s,_f,_node)  \
>>       kvmalloc_array_node_noprof(_n,_s,(_f)|__GFP_ZERO,_node)
>>
>> so afaik, this doesn't actually fix anything at all.
> 
> Agree, I think I was too hasty in queueing that up. I overlooked that we
> already had __GFP_ZERO in there. On the road this week and tending to
> these kinds of duties in between, my bad. Caleb??
> 
>> And dammit, this commit has that promising "Link:" argument that I
>> hoped would explain why this pointless commit exists, but AS ALWAYS
>> that link only wasted my time by pointing to the same damn information
>> that was already there.
> 
> [snip long rant on Link: tags]
> 
> I just always add these, because discussion might happen after the fact.
> For example, someone might run into an issue from an added patch, and
> reply to the list. That does happen.
> 
> IMHO it's better to have a Link and it _potentially_ being useful than
> not to have it and then need to search around for it. Searching is MUCH
> worse than the disappointment of a Link that tells you nothing that
> isn't in the commit already, and it wastes a lot more time.
> 
> And if you're applying a series of patches, then it'll take you to the
> cover letter. Which is useful. All without needing to go search on lore.
> You could argue that you could turn any applied series into a merge and
> add the cover letter there, or link it at least, but lots of things
> don't end up in a merge commit before you pull it.
> 
> What is the hurt here, really, other than you being disappointed there's
> nothing extra in the link?
> 
> I, and everybody else, can surely start making judgement calls on when
> to add the Link or not. But that seems error prone, and might indeed
> miss useful cases because a bug report comes in AFTER the fact.
> 
> In any case, if it really bothers you that much, then just make it
> policy. Historically I suppose policy has very much been formed by Linus
> rants in replies, which then gets picked up by LWN and others and then
> it becomes part of "Linux kernel lore" of this is what Linus expects.
> But I bet you that LWN would pick up a Linus email on the topic that
> isn't a reply, which said that you've observed Link: tag being used
> frivilously and why you find that annoying. And THAT would save you a
> lot more time rather than need to rant about it multiple times.

Oh, and I totally forgot the relevant tag this time:

Link: https://media.tenor.com/74lPb8mSRQMAAAAM/abe-simpson-abe-simpson-cloud.gif

;-)

-- 
Jens Axboe