Re: [PATCH] Fix undefined behavior in radix-tree.c.

From: Satoru Takeuchi <takeuchi_satoru@jp.fujitsu.com>
To: <dsterba@suse.cz>, Adam Buchbinder <abuchbinder@google.com>,
	<linux-btrfs@vger.kernel.org>
Subject: Re: [PATCH] Fix undefined behavior in radix-tree.c.
Date: Fri, 20 Jun 2014 08:51:01 +0900	[thread overview]
Message-ID: <53A37765.7020206@jp.fujitsu.com> (raw)
In-Reply-To: <20140619132845.GC1903@suse.cz>

Hi David,

(2014/06/19 22:28), David Sterba wrote:
> On Thu, Jun 19, 2014 at 10:10:55AM +0900, Satoru Takeuchi wrote:
>> It's fixed at 430d275a399.
>>
>> ===============================================================================
>> commit 430d275a399175c7c0673459738979287ec1fd22
>> Author: Peter Lund <firefly@vax64.dk>
>> Date:   Tue Oct 16 23:29:35 2007 -0700
>>
>>      avoid negative (and full-width) shifts in radix-tree.c
>> ...
>> ===============================================================================
>>
>> Adam, David, how about import this patch from kernel, rather than
>> writing btrfs-progs's own patch?
>
> Well, I think there's non-trivial time spent by Adam on the patch so I'd
> rather keep the credit, even if a patch that backports the fix from
> kernel would look cleaner in git log. Such things happen, sometimes it
> makes sense to replace patches or do changes inline.
>
> The progs development is moving forward quickly, a clean patch history
> is most useful when there is a separate stable branch that receives
> bugfixes as it helps the backporters to identify complete fixes. Not the
> case for progs right now.
>
>> I consider It's better to regularly sync such utility code with
>> the newest kernel code for the long term...
>
> Yes. The radix- or rb- tree code does not change often though, we can do
> a sync now and be fine for some time.

OK, I see. Thank you for your clear explanation.

Thanks,
Satoru