linux-next: manual merge of the block tree with the drbd tree

linux-next: manual merge of the block tree with the drbd tree

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1405 bytes --]

Hi all,

Today's linux-next merge of the block tree got a conflict in:

  drivers/block/drbd/drbd_nl.c

between commit:

  ffa847f8ff11d ("drbd: rework netlink interface for DRBD 9 multi-peer config")

from the drbd tree and commit:

  630bbba45cfd3 ("drbd: use genl pre_doit/post_doit")

from the block tree.

These changes are both quite large and the conflicts substantial,
ffa847f8ff11d ("drbd: rework netlink interface for DRBD 9 multi-peer
config") in particular has a diffstat of:

 drivers/block/drbd/drbd_nl.c | 7260 ++++++++++++++++++++++++++++++------------
 1 file changed, 5167 insertions(+), 2093 deletions(-)

which would be enormous even for a non-mechanical change, based on the
size and a glance over the changelog it seems clear to me that it should
be split up into a series of patches.  This would make resolving the
conflicts much more tractable as it would be clearer what each change is
trying to accomplish.

630bbba45cfd3 ("drbd: use genl pre_doit/post_doit") is much less of a
concern as while it's fairly large it is mostly mechanical.

Since I've got no confidence in my ability to do so rather than
resolving this I have marked the DRBD driver as BROKEN for today
(there's a half completed merge in the tree which shows how far I got)
and I will reorder the drbd tree after the block tree going forward
since it seems to feed into there.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: manual merge of the block tree with the drbd tree

[Jens Axboe]

On 3/25/26 9:41 AM, Mark Brown wrote:
> Hi all,
> 
> Today's linux-next merge of the block tree got a conflict in:
> 
>   drivers/block/drbd/drbd_nl.c
> 
> between commit:
> 
>   ffa847f8ff11d ("drbd: rework netlink interface for DRBD 9 multi-peer config")
> 
> from the drbd tree and commit:
> 
>   630bbba45cfd3 ("drbd: use genl pre_doit/post_doit")
> 
> from the block tree.

Christian... See previous reply on this.

> These changes are both quite large and the conflicts substantial,
> ffa847f8ff11d ("drbd: rework netlink interface for DRBD 9 multi-peer
> config") in particular has a diffstat of:
> 
>  drivers/block/drbd/drbd_nl.c | 7260 ++++++++++++++++++++++++++++++------------
>  1 file changed, 5167 insertions(+), 2093 deletions(-)
> 
> which would be enormous even for a non-mechanical change, based on the
> size and a glance over the changelog it seems clear to me that it should
> be split up into a series of patches.  This would make resolving the
> conflicts much more tractable as it would be clearer what each change is
> trying to accomplish.
> 
> 630bbba45cfd3 ("drbd: use genl pre_doit/post_doit") is much less of a
> concern as while it's fairly large it is mostly mechanical.
> 
> Since I've got no confidence in my ability to do so rather than
> resolving this I have marked the DRBD driver as BROKEN for today
> (there's a half completed merge in the tree which shows how far I got)
> and I will reorder the drbd tree after the block tree going forward
> since it seems to feed into there.

It _should_ feed into there, for some reason their tree got added to
-next rather than go the usual route.

-- 
Jens Axboe

Re: linux-next: manual merge of the block tree with the drbd tree

[Christoph Böhmwalder]

Am 25.03.26 um 16:41 schrieb Mark Brown:
> Hi all,
> 
> Today's linux-next merge of the block tree got a conflict in:
> 
>   drivers/block/drbd/drbd_nl.c
> 
> between commit:
> 
>   ffa847f8ff11d ("drbd: rework netlink interface for DRBD 9 multi-peer config")
> 
> from the drbd tree and commit:
> 
>   630bbba45cfd3 ("drbd: use genl pre_doit/post_doit")
> 
> from the block tree.
> 
> These changes are both quite large and the conflicts substantial,
> ffa847f8ff11d ("drbd: rework netlink interface for DRBD 9 multi-peer
> config") in particular has a diffstat of:
> 
>  drivers/block/drbd/drbd_nl.c | 7260 ++++++++++++++++++++++++++++++------------
>  1 file changed, 5167 insertions(+), 2093 deletions(-)
> 
> which would be enormous even for a non-mechanical change, based on the
> size and a glance over the changelog it seems clear to me that it should
> be split up into a series of patches.  This would make resolving the
> conflicts much more tractable as it would be clearer what each change is
> trying to accomplish.
> 
> 630bbba45cfd3 ("drbd: use genl pre_doit/post_doit") is much less of a
> concern as while it's fairly large it is mostly mechanical.
> 
> Since I've got no confidence in my ability to do so rather than
> resolving this I have marked the DRBD driver as BROKEN for today
> (there's a half completed merge in the tree which shows how far I got)
> and I will reorder the drbd tree after the block tree going forward
> since it seems to feed into there.

Ah, sorry, that's on me, I should have called ahead.

It's a long story: the DRBD changes in drbd-next (and thus linux-next)
replay about 15 years of development history. The out-of-tree DRBD
module got de-synced from the in-tree version, and never truly caught
up. The gap just grew over the years, and we're trying to fix that now.
That's how we ended up with the enormous patch series that is now in
linux-next.

We submitted the preliminary series to linux-next to "test the waters"
in regards to integration with the mainline kernel, CI checks, etc.
This preliminary series still breaks some old userspace tooling, though,
so we can't truly submit it "officially" yet.

And that is precisely what we are working on now: we intend on starting
a new genetlink family that enables compatibility with both the old and
new userspace tools. This will take some more time, we are taking the
first preparing steps now (such as "drbd: use genl pre_doit/post_doit").
Since this is useful for the current in-tree module as well, we have
decided to submit those patches "normally" via the block tree.
And obviously that caused conflicts with the next tree, since that has
not been rebased (yet).

Jens, how do you want to handle this?
Should I send the (technically working, but maybe
old-userspace-breaking) DRBD 9 patch series to you so you can carry it
in block/for-next? So far I was under the impression that these patches
would be too large and unfinished for the block/for-next branch.

Mark, thanks for your efforts and please keep the drbd-next branch
marked as broken for now. I will rebase the tree in the following days,
and we'll see via which path it gets resubmitted.

Thanks,
Christoph

-- 
Christoph Böhmwalder
LINBIT | Keeping the Digital World Running
DRBD HA —  Disaster Recovery — Software defined Storage

Re: linux-next: manual merge of the block tree with the drbd tree

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 832 bytes --]

On Wed, Mar 25, 2026 at 09:56:57AM -0600, Jens Axboe wrote:
> On 3/25/26 9:41 AM, Mark Brown wrote:

> > Since I've got no confidence in my ability to do so rather than
> > resolving this I have marked the DRBD driver as BROKEN for today
> > (there's a half completed merge in the tree which shows how far I got)
> > and I will reorder the drbd tree after the block tree going forward
> > since it seems to feed into there.

> It _should_ feed into there, for some reason their tree got added to
> -next rather than go the usual route.

It's fine and normal to have multiple levels of tree in -next, some
trees like the soc tree even require that any pull requests sent to them
have had some soaking in -next.  It does look like this goes in as
patches rather than pull requests though?  That has more likelyhood of
causing issues.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: manual merge of the block tree with the drbd tree

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 451 bytes --]

On Wed, Mar 25, 2026 at 03:41:05PM +0000, Mark Brown wrote:

> Since I've got no confidence in my ability to do so rather than
> resolving this I have marked the DRBD driver as BROKEN for today
> (there's a half completed merge in the tree which shows how far I got)
> and I will reorder the drbd tree after the block tree going forward
> since it seems to feed into there.

Actually I had to redo the merge so the partial resolution got lost,
sorry.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: manual merge of the block tree with the drbd tree

[Jens Axboe]

On 3/25/26 10:07 AM, Christoph B?hmwalder wrote:
> Am 25.03.26 um 16:41 schrieb Mark Brown:
>> Hi all,
>>
>> Today's linux-next merge of the block tree got a conflict in:
>>
>>   drivers/block/drbd/drbd_nl.c
>>
>> between commit:
>>
>>   ffa847f8ff11d ("drbd: rework netlink interface for DRBD 9 multi-peer config")
>>
>> from the drbd tree and commit:
>>
>>   630bbba45cfd3 ("drbd: use genl pre_doit/post_doit")
>>
>> from the block tree.
>>
>> These changes are both quite large and the conflicts substantial,
>> ffa847f8ff11d ("drbd: rework netlink interface for DRBD 9 multi-peer
>> config") in particular has a diffstat of:
>>
>>  drivers/block/drbd/drbd_nl.c | 7260 ++++++++++++++++++++++++++++++------------
>>  1 file changed, 5167 insertions(+), 2093 deletions(-)
>>
>> which would be enormous even for a non-mechanical change, based on the
>> size and a glance over the changelog it seems clear to me that it should
>> be split up into a series of patches.  This would make resolving the
>> conflicts much more tractable as it would be clearer what each change is
>> trying to accomplish.
>>
>> 630bbba45cfd3 ("drbd: use genl pre_doit/post_doit") is much less of a
>> concern as while it's fairly large it is mostly mechanical.
>>
>> Since I've got no confidence in my ability to do so rather than
>> resolving this I have marked the DRBD driver as BROKEN for today
>> (there's a half completed merge in the tree which shows how far I got)
>> and I will reorder the drbd tree after the block tree going forward
>> since it seems to feed into there.
> 
> Ah, sorry, that's on me, I should have called ahead.
> 
> It's a long story: the DRBD changes in drbd-next (and thus linux-next)
> replay about 15 years of development history. The out-of-tree DRBD
> module got de-synced from the in-tree version, and never truly caught
> up. The gap just grew over the years, and we're trying to fix that now.
> That's how we ended up with the enormous patch series that is now in
> linux-next.

At least that's a worthy goal, I believe I have complained about that
multiple times over the last couple of years :)

> We submitted the preliminary series to linux-next to "test the waters"
> in regards to integration with the mainline kernel, CI checks, etc.
> This preliminary series still breaks some old userspace tooling, though,
> so we can't truly submit it "officially" yet.
> 
> And that is precisely what we are working on now: we intend on starting
> a new genetlink family that enables compatibility with both the old and
> new userspace tools. This will take some more time, we are taking the
> first preparing steps now (such as "drbd: use genl pre_doit/post_doit").
> Since this is useful for the current in-tree module as well, we have
> decided to submit those patches "normally" via the block tree.
> And obviously that caused conflicts with the next tree, since that has
> not been rebased (yet).
> 
> Jens, how do you want to handle this?
> Should I send the (technically working, but maybe
> old-userspace-breaking) DRBD 9 patch series to you so you can carry it
> in block/for-next? So far I was under the impression that these patches
> would be too large and unfinished for the block/for-next branch.

How about this - rebase it against for-7.1/block, and send the series.
I can stash it in for-7.1/drbd, which can go into for-next. Then the
separate tree can be dropped.

I won't submit the changes in for-7.1/drbd, but just expect you to send
a new series against for-7.2/block when that is a thing. The 7.2 one
should be closer to going upstream, and so forth. Within a few revisions
of the mainline kernel, we'll get to the point where for-7.x/drbd can be
included in the merge window pull request as well, and we're done at
that point and future drbd changes will just get submitted against
for-7.x/block like any other block driver.

?

-- 
Jens Axboe

Re: linux-next: manual merge of the block tree with the drbd tree

[Christoph Böhmwalder]

Am 25.03.26 um 17:30 schrieb Jens Axboe:
> On 3/25/26 10:07 AM, Christoph B?hmwalder wrote:
>> Jens, how do you want to handle this?
>> Should I send the (technically working, but maybe
>> old-userspace-breaking) DRBD 9 patch series to you so you can carry it
>> in block/for-next? So far I was under the impression that these patches
>> would be too large and unfinished for the block/for-next branch.
> 
> How about this - rebase it against for-7.1/block, and send the series.
> I can stash it in for-7.1/drbd, which can go into for-next. Then the
> separate tree can be dropped.
> 
> I won't submit the changes in for-7.1/drbd, but just expect you to send
> a new series against for-7.2/block when that is a thing. The 7.2 one
> should be closer to going upstream, and so forth. Within a few revisions
> of the mainline kernel, we'll get to the point where for-7.x/drbd can be
> included in the merge window pull request as well, and we're done at
> that point and future drbd changes will just get submitted against
> for-7.x/block like any other block driver.
> 
> ?
> 

Sounds like a plan. I'll send the rebased series this week.
We already have a few "get it closer to going upstream" patches in the
pipeline targeted for the 7.1 and 7.2 merge windows, but none of them
are truly ready yet. So this approach would fit very well.

Exactly, once we are done with all this we will adopt a "normal"
upstream-first dev approach again. We've already discussed changes to
our internal workflow to make sure we never digress this far from
upstream again -- I think that's in all our interests :)

Thanks,
Christoph

-- 
Christoph Böhmwalder
LINBIT | Keeping the Digital World Running
DRBD HA —  Disaster Recovery — Software defined Storage

Re: linux-next: manual merge of the block tree with the drbd tree

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1227 bytes --]

On Wed, Mar 25, 2026 at 05:47:34PM +0100, Christoph Böhmwalder wrote:
> Am 25.03.26 um 17:30 schrieb Jens Axboe:

> > I won't submit the changes in for-7.1/drbd, but just expect you to send
> > a new series against for-7.2/block when that is a thing. The 7.2 one
> > should be closer to going upstream, and so forth. Within a few revisions
> > of the mainline kernel, we'll get to the point where for-7.x/drbd can be
> > included in the merge window pull request as well, and we're done at
> > that point and future drbd changes will just get submitted against
> > for-7.x/block like any other block driver.

> Sounds like a plan. I'll send the rebased series this week.
> We already have a few "get it closer to going upstream" patches in the
> pipeline targeted for the 7.1 and 7.2 merge windows, but none of them
> are truly ready yet. So this approach would fit very well.

> Exactly, once we are done with all this we will adopt a "normal"
> upstream-first dev approach again. We've already discussed changes to
> our internal workflow to make sure we never digress this far from
> upstream again -- I think that's in all our interests :)

So I should just drop the drbd tree entirely from tomorrow?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: manual merge of the block tree with the drbd tree

[Christoph Böhmwalder]

Am 25.03.26 um 17:57 schrieb Mark Brown:
> On Wed, Mar 25, 2026 at 05:47:34PM +0100, Christoph Böhmwalder wrote:
>> Am 25.03.26 um 17:30 schrieb Jens Axboe:
> 
>>> I won't submit the changes in for-7.1/drbd, but just expect you to send
>>> a new series against for-7.2/block when that is a thing. The 7.2 one
>>> should be closer to going upstream, and so forth. Within a few revisions
>>> of the mainline kernel, we'll get to the point where for-7.x/drbd can be
>>> included in the merge window pull request as well, and we're done at
>>> that point and future drbd changes will just get submitted against
>>> for-7.x/block like any other block driver.
> 
>> Sounds like a plan. I'll send the rebased series this week.
>> We already have a few "get it closer to going upstream" patches in the
>> pipeline targeted for the 7.1 and 7.2 merge windows, but none of them
>> are truly ready yet. So this approach would fit very well.
> 
>> Exactly, once we are done with all this we will adopt a "normal"
>> upstream-first dev approach again. We've already discussed changes to
>> our internal workflow to make sure we never digress this far from
>> upstream again -- I think that's in all our interests :)
> 
> So I should just drop the drbd tree entirely from tomorrow?

I guess that would actually be the easiest path then, yes.
Sorry for the churn on your side.

-- 
Christoph Böhmwalder
LINBIT | Keeping the Digital World Running
DRBD HA —  Disaster Recovery — Software defined Storage

Re: linux-next: manual merge of the block tree with the drbd tree

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 321 bytes --]

On Wed, Mar 25, 2026 at 06:33:09PM +0100, Christoph Böhmwalder wrote:
> Am 25.03.26 um 17:57 schrieb Mark Brown:

> > So I should just drop the drbd tree entirely from tomorrow?

> I guess that would actually be the easiest path then, yes.

OK, I'll do that.

> Sorry for the churn on your side.

No problem.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: manual merge of the block tree with the drbd tree

[Jens Axboe]

On 3/25/26 10:47 AM, Christoph B?hmwalder wrote:
> Am 25.03.26 um 17:30 schrieb Jens Axboe:
>> On 3/25/26 10:07 AM, Christoph B?hmwalder wrote:
>>> Jens, how do you want to handle this?
>>> Should I send the (technically working, but maybe
>>> old-userspace-breaking) DRBD 9 patch series to you so you can carry it
>>> in block/for-next? So far I was under the impression that these patches
>>> would be too large and unfinished for the block/for-next branch.
>>
>> How about this - rebase it against for-7.1/block, and send the series.
>> I can stash it in for-7.1/drbd, which can go into for-next. Then the
>> separate tree can be dropped.
>>
>> I won't submit the changes in for-7.1/drbd, but just expect you to send
>> a new series against for-7.2/block when that is a thing. The 7.2 one
>> should be closer to going upstream, and so forth. Within a few revisions
>> of the mainline kernel, we'll get to the point where for-7.x/drbd can be
>> included in the merge window pull request as well, and we're done at
>> that point and future drbd changes will just get submitted against
>> for-7.x/block like any other block driver.
>>
>> ?
>>
> 
> Sounds like a plan. I'll send the rebased series this week.
> We already have a few "get it closer to going upstream" patches in the
> pipeline targeted for the 7.1 and 7.2 merge windows, but none of them
> are truly ready yet. So this approach would fit very well.
> 
> Exactly, once we are done with all this we will adopt a "normal"
> upstream-first dev approach again. We've already discussed changes to
> our internal workflow to make sure we never digress this far from
> upstream again -- I think that's in all our interests :)

OK, all on the same page then! Thanks.

-- 
Jens Axboe