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
next prev 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