Distributed Replicated Block Device (DRBD) development
 help / color / mirror / Atom feed
From: "Björn Stabel" <bjoern.stabel@data-experts.de>
To: drbd-dev@lists.linux.dev
Subject: [PATCH] drbd: fix ldev refcount imbalance when resync request allocation fails
Date: Thu, 16 Jul 2026 13:36:40 +0200	[thread overview]
Message-ID: <02903afc-cda1-4d97-8155-4e03c3cc0e51@data-experts.de> (raw)

make_one_resync_request() does not take its own ldev reference; it
relies on the reference held by its only caller, make_resync_request().
Nevertheless, when drbd_alloc_peer_req() fails, the error path called
put_ldev() before returning -EAGAIN. The caller then handles -EAGAIN by
jumping to request_done and eventually releases its reference again at
out_put_ldev. The result is two put_ldev() calls for a single
get_ldev(), so device->local_cnt underflows.

Once local_cnt is negative, every subsequent get_ldev()/put_ldev() pair
trips D_ASSERT(device, i >= 0) in put_ldev(), flooding the kernel log
with "ASSERTION i >= 0 FAILED in put_ldev" for every I/O completion on
the device. Worse, the "last reference dropped" detection (i == 0) is
permanently skewed: a later detach either never sees the counter reach
zero (hanging the transition to diskless) or sees it reach zero while
references are still in flight, with use-after-free potential in the
ldev destroy path.

The allocation failure itself is expected transient behavior: resync
requests are allocated with GFP_TRY & ~__GFP_RECLAIM on purpose, so the
mempool can run dry under a burst of parallel resyncs and the request is
simply retried later. Observed in production on a Proxmox/LINSTOR
cluster after ten "linstor resource toggle-disk" migrations resynced
concurrently: five volumes hit the allocation failure and spammed the
assertion at the full I/O rate afterwards.

The sister path read_for_csum() takes and releases its own reference
and is balanced. Fix make_one_resync_request() by dropping the stray
put_ldev() so the reference is released exactly once, by the caller.

Fixes: 223009b6369f ("drbd: synchronize resync with interval tree and 
dagtags")
Signed-off-by: Christian Taeumel <christian.taeumel@data-experts.de>
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
---
  drbd/drbd_sender.c | 1 -
  1 file changed, 1 deletion(-)

diff --git a/drbd/drbd_sender.c b/drbd/drbd_sender.c
index 907f042b4..f90d3a9f6 100644
--- a/drbd/drbd_sender.c
+++ b/drbd/drbd_sender.c
@@ -680,7 +680,6 @@ static int make_one_resync_request(struct 
drbd_peer_device *peer_device, int dis
                 size, REQ_OP_WRITE);
    if (!peer_req) {
      drbd_err(device, "Could not allocate resync request\n");
-    put_ldev(device);
      return -EAGAIN;
    }

-- 
2.43.0

Diese E-Mail sowie etwaige Anhänge enthalten vertrauliche und/oder rechtlich geschützte Informationen und sind ausschließlich für die im Adressfeld genannte(n) Person(en) bestimmt. Sollten Sie nicht zum vorgesehenen Empfängerkreis gehören oder diese Nachricht irrtümlich erhalten haben, bitten wir Sie, die absendende Person zu informieren und die E-Mail sowie alle Anhänge zu löschen. In diesem Fall ist jede Kenntnisnahme, Verwendung, Weitergabe oder Vervielfältigung der Inhalte nicht gestattet.

                 reply	other threads:[~2026-07-16 11:36 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=02903afc-cda1-4d97-8155-4e03c3cc0e51@data-experts.de \
    --to=bjoern.stabel@data-experts.de \
    --cc=drbd-dev@lists.linux.dev \
    /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