Linux block layer
 help / color / mirror / Atom feed
From: Ionut Nechita <ionut.nechita@windriver.com>
To: "Christoph Böhmwalder" <christoph.boehmwalder@linbit.com>,
	"Jens Axboe" <axboe@kernel.dk>
Cc: Philipp Reisner <philipp.reisner@linbit.com>,
	Lars Ellenberg <lars.ellenberg@linbit.com>,
	Joel Colledge <joel.colledge@linbit.com>,
	Ionut Nechita <ionut.nechita@windriver.com>,
	drbd-dev@lists.linux.dev, linux-block@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: [PATCH 2/2] drbd: increase maximum CPU mask size
Date: Sun,  2 Aug 2026 14:05:52 +0300	[thread overview]
Message-ID: <20260802110552.50757-3-ionut.nechita@windriver.com> (raw)
In-Reply-To: <20260802110552.50757-1-ionut.nechita@windriver.com>

The cpu-mask resource option is limited to DRBD_CPU_MASK_SIZE - 1, i.e.
31 characters. bitmap_parse() reads the string as comma separated chunks
of up to eight hex digits, each describing 32 bits, so 31 characters
describe at most 112 CPUs. A full mask cannot be expressed on anything
larger, which by now includes most two-socket machines.

Sparse masks can still reach higher CPU numbers by padding with zero
chunks - "8,0,0,0" selects CPU 99 - but that only helps when few bits
are set.

Userspace has already moved on. drbd-utils carries its own copy of these
headers, where DRBD_CPU_MASK_SIZE has been 256 since 2023 ("drbd:
increase maximum CPU mask size" by Joel Colledge, in LINBIT's
drbd-headers repository). A drbdsetup built against those headers is
rejected with -ERANGE by validate_nla() as soon as the mask does not fit
in the 31 characters this driver accepts.

Raise the limit to match userspace. 255 characters allow a full mask for
908 CPUs: a leading chunk of three hex digits followed by 28 chunks of
eight.

The cpu_mask member of struct res_opts grows accordingly. Two instances
live on the stack, in drbd_adm_resource_opts() and in
drbd_adm_new_resource(), which is uncritical at this size.

This only relaxes an upper bound, so an old drbdsetup keeps working
against a kernel with this change, and a new drbdsetup keeps working
against a kernel without it as long as the mask string still fits in the
old limit.

The new size will likely be too small again eventually. Describing the
mask with bitmap_parselist() would avoid that, but the list and hex
formats are ambiguous for the same input - "8" means CPU 3 in one and
CPU 8 in the other - so it would have to be a separate attribute rather
than a reinterpretation of this one.

Signed-off-by: Ionut Nechita <ionut.nechita@windriver.com>
---
 include/uapi/linux/drbd.h | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/include/uapi/linux/drbd.h b/include/uapi/linux/drbd.h
index cf1ec3eb872f..1327ce1006ac 100644
--- a/include/uapi/linux/drbd.h
+++ b/include/uapi/linux/drbd.h
@@ -368,7 +368,12 @@ enum write_ordering_e {
 #define DRBD_MD_INDEX_FLEX_EXT -2
 #define DRBD_MD_INDEX_FLEX_INT -3
 
-#define DRBD_CPU_MASK_SIZE 32
+/*
+ * Maximum size of the cpu-mask string, including the terminating NUL.
+ * The netlink policy accepts DRBD_CPU_MASK_SIZE - 1 characters, which is
+ * enough for a full mask covering 908 CPUs.
+ */
+#define DRBD_CPU_MASK_SIZE 256
 
 /**
  * struct drbd_genlmsghdr - DRBD specific header used in NETLINK_GENERIC requests
-- 
2.55.0


  parent reply	other threads:[~2026-08-02 11:06 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-02 11:05 [PATCH 0/2] drbd: fix netlink string policy lengths, raise cpu-mask limit Ionut Nechita
2026-08-02 11:05 ` [PATCH 1/2] drbd: fix off-by-one in netlink NUL-string policy lengths Ionut Nechita
2026-08-10 14:46   ` Christoph Böhmwalder
2026-08-02 11:05 ` Ionut Nechita [this message]
2026-08-10 14:52   ` [PATCH 2/2] drbd: increase maximum CPU mask size Christoph Böhmwalder

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260802110552.50757-3-ionut.nechita@windriver.com \
    --to=ionut.nechita@windriver.com \
    --cc=axboe@kernel.dk \
    --cc=christoph.boehmwalder@linbit.com \
    --cc=drbd-dev@lists.linux.dev \
    --cc=joel.colledge@linbit.com \
    --cc=lars.ellenberg@linbit.com \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=philipp.reisner@linbit.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox