Re: [GIT PULL] md-6.17-20250803

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 8/2/25 5:50 PM, Yu Kuai wrote:
> Hi, Jens
> 
> ? 2025/8/3 5:42, Jens Axboe ??:
>> On 8/2/25 12:29 PM, Jens Axboe wrote:
>>> On 8/2/25 11:25 AM, Yu Kuai wrote:
>>>> Hi, Jens
>>>>
>>>> Please consider pulling following changes on your block-6.17 branch,
>>>> this pull request contains:
>>>>
>>>> - mddev null-ptr-dereference fix, by Erkun
>>>> - md-cluster fail to remove the faulty disk regression fix, by Heming
>>>> - minor cleanup, by Li Nan
>>>> - mdadm lifetime regression fix reported by syzkaller, by Yu Kuai
>>>> - experimental feature: introduce new lockless bitmap, by Yu Kuai
>>> Why was this sent in so late? You're at least a week later sending in
>>> big changes for the merge window, as we're already half way through it.
>>> Generally anything big should land in my tree a week before the merge
>>> window OPENS, not a week into it.
>> I took a closer look, because perhaps you just sent in the pull request
>> pretty late. And it's a bit hard to tell because it looks like you
>> rebased this code (why?), but at least the lockless bitmap code looks
>> like it was finished up inside the merge window. That looks late. The
>> rest looks more reasonably timed, just rebased for some reason.
>>
>> If I'm going to get yelled at by a traveling Linus, there better be a
>> good reason for it. In other words, is there a justification for the
>> lockless bitmap code being in there?
> 
> Apologies for the late submission - this was unintentional. The core
> changes were ready before 6.15, but the final llbitmap patch got
> delayed due to review backlog.

> 
> About the last patch:
>  - all feedback are addressed 2 weeks ago
>  - still waiting formal Reviewed-by tag, not sure why, possibly due to
>  this patch is huge.
> 
> About the rebase, this is because llbitmap set has conflicts with
> other patches during the period, and I sent a new version and just
> pick it last night.
> 
> I do take a bet sending this pr last night, and hoping llbitmap won't
> delayed to next merge window again.  However, I fully understand if
> this misses 6.17, I'm prepared to defer to 6.18.

Let's defer it to 6.18 then, if you're fine with that, as this really
should've been sent out ~2 weeks ago. FWIW, it's not an issue to have
conflicts with my tree or master, I can resolve those. What is generally
nice is if you have a merged branch somewhere you can point at, then I
can double check if it's all good in case it's a complicated merge. But
that is greatly preferable to deferring pull requests or rebasing them
to avoid the merges.

If you have fixes in your current tree that should go into 6.17-rc1,
then please do send those separately.

-- 
Jens Axboe




[Index of Archives]     [Linux RAID]     [Linux SCSI]     [Linux ATA RAID]     [IDE]     [Linux Wireless]     [Linux Kernel]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Device Mapper]

  Powered by Linux