linux-kernel - Re: [PATCH 1/6] rbtree: add rb_find_add

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] [day] [month] [year] [list]

Message-ID: <25ab4458-06a4-46a3-b42b-a7dc52d44b1e@suse.com>
Date: Tue, 17 Dec 2024 09:10:14 +1030
From: Qu Wenruo <wqu@...e.com>
To: Peter Zijlstra <peterz@...radead.org>, Qu Wenruo <quwenruo.btrfs@....com>
Cc: "Roger L. Beckermeyer III" <beckerlee3@...il.com>, dsterba@...e.cz,
 oleg@...hat.com, mhiramat@...nel.org, linux-kernel@...r.kernel.org,
 josef@...icpanda.com, linux-btrfs@...r.kernel.org, lkp@...el.com
Subject: Re: [PATCH 1/6] rbtree: add rb_find_add_cached() to rbtree.h

在 2024/12/17 08:52, Peter Zijlstra 写道:
> On Tue, Dec 17, 2024 at 08:43:26AM +1030, Qu Wenruo wrote:
>>
>>
>> 在 2024/12/13 19:36, Peter Zijlstra 写道:
>>> On Thu, Dec 12, 2024 at 10:46:18AM -0600, Roger L. Beckermeyer III wrote:
>>>> Adds rb_find_add_cached() as a helper function for use with
>>>> red-black trees. Used in btrfs to reduce boilerplate code.
>>>>
>>>> Suggested-by: Josef Bacik <josef@...icpanda.com>
>>>> Signed-off-by: Roger L. Beckermeyer III <beckerlee3@...il.com>
>>>
>>> Acked-by: Peter Zijlstra (Intel) <peterz@...radead.org>
>>
>> I guess it's fine to merge this change through btrfs tree?
> 
> Yeah, I think so. I don't think there's anything else pending for this
> file -- its not touched much.
> 
>>
>> Just curious about the existing cmp() and less() functions, as they only
>> accept the exist node as const.
>>
>> I'm wondering if this is intentional to allow the less/cmp() functions
>> to modify the new node if needed.
>> As I normally assume such cmp()/less() should never touch any node nor
>> its entries.
> 
> Oh yeah, they probably should not. I think it's just because the
> callchain as a whole does not have const on the new node (for obvious
> raisins), and I failed to put it on for the comparators.
> 
> You could add it (and fix up the whole tree) and see if anything comes
> apart.
> 
Thanks for confirming this.

I'll make the cmp() for the new helper to accept all const parameter, 
and give a try to do a tree-wide cleanup to make existing cmp/less() to 
accept all const parameters. (pretty sure a lot of things will fall 
apart though).

Thanks,
Qu