From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f48.google.com (mail-wr1-f48.google.com [209.85.221.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 22A343EC2C4 for ; Wed, 25 Mar 2026 16:07:32 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.48 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774454854; cv=none; b=G0Zzl8LcdTevKpiERuTmNZw+tKqSNZsxw8q+G71vYDiV8sguat/mEri4+p45X+7C+mPvOmeLz+8WbBjyM3yJomRNhkZ04O4/E7VzyoV8qsqTvNjZ6Ub72kcmW1Dxa/mtbl8lcXTQQArXWuReG4aEgTCx30aeHSYkqemtxld/gso= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774454854; c=relaxed/simple; bh=FH5JCd6BfJHiLBlh4yk5NBY0gRb7erW1xuTyJM3f280=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=C9hqGDosMIMT/5DOKGBY5fPg/M/6xCF+3aDMYIGSTp0Lvai5ariEmp2TwTuO03tvAIh4uwZPaU6dmxQYEofDA70qBSIbWpY42RQHzJB6CcfNqDhqdbYO6mSYqLiRbjvv7lDYNLtJUr3Ez1w4rm3h+Kw1R+Gs+6/65eqqnSYbLyo= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linbit.com; spf=pass smtp.mailfrom=linbit.com; dkim=pass (2048-bit key) header.d=linbit-com.20230601.gappssmtp.com header.i=@linbit-com.20230601.gappssmtp.com header.b=gR7aztUB; arc=none smtp.client-ip=209.85.221.48 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linbit.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linbit.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=linbit-com.20230601.gappssmtp.com header.i=@linbit-com.20230601.gappssmtp.com header.b="gR7aztUB" Received: by mail-wr1-f48.google.com with SMTP id ffacd0b85a97d-43b4d734678so2503606f8f.1 for ; Wed, 25 Mar 2026 09:07:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linbit-com.20230601.gappssmtp.com; s=20230601; t=1774454850; x=1775059650; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:content-language:from :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=WoigNGk5cMWhKXOt/Vv6EUh1Su5Qhq3xBfx8jQN83d0=; b=gR7aztUBjwnYg+R5GgeC9wgsGeuP397+w36d0uZiYydxZTYPTwmS874IjqeH5s2xkZ k5VXC+baIn9mVOR/FAW6fE2YwQtPtyKjg3oJ4GZ/S296OKQSJkoXUZksbScLy/ASTZBH DxhqMbV5u6/QXu3o8HfCP54Rr2iDNHiQ8rdO2/lwa/k6cOdZg74izkqEk4zd99MwKt2g sgrhYMWac1qHZ+BOnLV6Ss5syVpBygMup0+TaprlMVtbyb6eIqncJ7KwoT69HEDVw2xm wCAAbpYMgChyVERBVRO+wkfeWx7mzp45WsK+eNjxgIz4K6jHDU788z0EscsnrFXCWEDM MHUw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1774454850; x=1775059650; h=content-transfer-encoding:in-reply-to:content-language:from :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=WoigNGk5cMWhKXOt/Vv6EUh1Su5Qhq3xBfx8jQN83d0=; b=eXmnUklFleOlxtbuALEFcfxS9+6DMMMW9btN2NjPV5rANtTTfpEo6JqFaTjt0ZURtm uv0DtP8Ejvf83kQYmC+NXyUDIHxxbJ3E3BAt/OsBK+tipiT6lkCFXlTRgv6ybbzZcfGK 8djW5g9M36+fu8sAByNxsskeOWRVIzny/iJ3kn70G85Mlxsh102WWjzrQws6AWwe/nF8 ALYhL5MZPd61LBV1AbAkWlDh3tUCZhWUoC6CYSDAH6tmfeEi1eHHMYLTLjRZa+GpEx1x g8XXDWu/M9wVF7wfXpy4qevKnG2Z9+PisQc8aFPJeFvTBmnuInqBjM/DCUK5MXo9PvlU Q07g== X-Forwarded-Encrypted: i=1; AJvYcCXljtNI7RrvDHb+EFyMFpeRIak0X64M7sQAPorj+JFiEadVGUSTS2MCV0qwoVHZiGRVZqzKJcbGnZmJn3U=@vger.kernel.org X-Gm-Message-State: AOJu0YwLrFg1+ARln6XSwhOuExadB6NkJVFUBrnNyp12z8FnwqrsngZh cBEEXIGs5jwhvJHG7QhdZG7Motkc0v+4RkBlUZZCx4tEyopN0iBwlGO4Y2QFT3qKNtmTLBhg/H/ 2OG2f X-Gm-Gg: ATEYQzxw29k269c9stLCoYM1Aj4DGuax1bzCXVLytHVfAy/0IVIgusFp8ZUVNXhw8/P iUA97zpkW3Ii0Pp9PdxEQlbWZ4PpOxOI4MOVk/8igvybnP4DwFAyDOa9vKz+jp742uScDHeaTvo F8q5K9nqqzAf1AvxeUwE89ICaDLo5SxZi4THZFWH3y8Hw2za7nOMKPlXQaddqB4S+SksevsK+F/ CmZ2DX34xm5s1fN5TOCYtXetJrUVPkWKaZ1TrgND5sryUenMdo5t5XJ6DR0PGaj1qaVEJbBRvl/ VTe77hCAqxEPdtFtzKdC3siPsTEvCDc3kyr4g9BUAyd9hBbO2tFZ8r0cWrNxpVO+Gem0yJqinMh W7hN7AfwhEC0KIibVsvCL17+OhQ8H/ci2H+pUsEzvJHlL46Ky1DrsL0U0Bpt3G3kZ4I0LlIGinZ ePvV7YqLc9mWkNZPGdnGAAQOrj5QSzsAR1oQgwoz0fZ8hJk+GD41ymz4QwHpxEHr6aBNyCIaAEg KyVNjjD2X+22W0= X-Received: by 2002:adf:f78c:0:b0:43b:9111:a1d1 with SMTP id ffacd0b85a97d-43b9111a1dbmr951145f8f.0.1774454850327; Wed, 25 Mar 2026 09:07:30 -0700 (PDT) Received: from [192.168.178.55] (h082218028181.host.wavenet.at. [82.218.28.181]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-43b919df903sm655408f8f.30.2026.03.25.09.07.29 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 25 Mar 2026 09:07:29 -0700 (PDT) Message-ID: Date: Wed, 25 Mar 2026 17:07:28 +0100 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: linux-next: manual merge of the block tree with the drbd tree To: Mark Brown , Jens Axboe Cc: Philipp Reisner , Lars Ellenberg , Linux Kernel Mailing List , Linux Next Mailing List References: From: =?UTF-8?Q?Christoph_B=C3=B6hmwalder?= Content-Language: en-US In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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