From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.openvz.org (mail.openvz.org [69.168.225.77]) by lore.virtuozzo.com (Postfix) with ESMTPS id 9F2ED8017D for ; Tue, 3 Nov 2026 06:23:32 +0000 (UTC) Received: from mail.openvz.org (localhost [127.0.0.1]) by mail.openvz.org (8.14.4/8.14.4) with ESMTP id 6A36MILE001112; Tue, 3 Nov 2026 09:22:19 +0300 DKIM-Filter: OpenDKIM Filter v2.11.0 mail.openvz.org 6A36MILE001112 Authentication-Results: mail.openvz.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=virtuozzo.com header.i=@virtuozzo.com header.b="Sr472Q8c" Received: from mail-wm1-f69.google.com (mail-wm1-f69.google.com [209.85.128.69]) by mail.openvz.org (8.14.4/8.14.4) with ESMTP id 6A36MCWc001083 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=FAIL) for ; Tue, 3 Nov 2026 09:22:12 +0300 DKIM-Filter: OpenDKIM Filter v2.11.0 mail.openvz.org 6A36MCWc001083 Received: by mail-wm1-f69.google.com with SMTP id 5b1f17b1804b1-4a4af69e06fso25508655e9.2 for ; Mon, 02 Nov 2026 22:22:12 -0800 (PST) X-Gm-Message-State: APuU4Z9MGAManqrYByjoh/ec0RRx0K32VESkjOc4r/to5ztvaaKZJ23v N4G8/EqO4iOB6wAKAr/UsDQYX2y9p/ouzb1K1wggKRiu41GX19SLeG8Zgt2eW6Pw28JLOo0Q5I3 6aa7y/WX78Gtu8IJdv2G1oP8k7xPbpOXjdj+XjkkTzuuuftYu9GY+hw== X-Gm-Gg: AYBFou0iFUE5RBvHvii4DKbjusc1nvs5Pr2AvQ0H4g+FHo6vfT1r01RYcuk0RdcyYFR GJtcZaoaifRvSPZINHSjhFMtAge2t4iS9Pe+3WVPI4nLUoFSwMRWTX586qTswwJwrZRjeH2M0d3 IZKEqrf52287QXGVbZD1z09zy1a0v9LcHZFHZw7TsJrkkHLbovIZJ34qA5A9O1gtk0/GPvScM+k fqRgCI3/NrpjkvjhWmNw0cT5RQ5OODGI6nI9toaRYXIeWNnBgAeMpmPNiAXejAf9RuedmFDPxqY +M6Y+wFt+xtTi8hlpYQWojvtIjls+0ZVKg30ljgX9L3+CIA22c8Zxfkuqb8sNA3uJ4kGtT3ERZi GW/cpAI41qz121hvnDHMY4gIRqN1b X-Received: by 2002:a05:600c:6095:b0:4a0:1b21:2628 with SMTP id 5b1f17b1804b1-4ac18b7e1c1mr245669755e9.23.1793686932130; Mon, 02 Nov 2026 22:22:12 -0800 (PST) X-Received: by 2002:a05:600c:6095:b0:4a0:1b21:2628 with SMTP id 5b1f17b1804b1-4ac18b7e1c1mr245669505e9.23.1793686931594; Mon, 02 Nov 2026 22:22:11 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1793686931; cv=none; d=google.com; s=arc-20260327; b=j6mRby0mPTIWl2IIDuuCktmvWp8p+Vo+8pai+jxLjW41FC7sug/vzxx79+HQ1sO8r/ VhXNMm/b71kci8dKRnRp6NkcjdRgA4/Wk4zcHp2snVc7pdl7kg5tWMbMeGbkmVlZSUZN t3+ZcD3NieXnWmM+z5tO/wwuJNNfkKzDKPi1LuxZ96ruY+EY52JT4S/f+MTfFS1dSpYw ERCLu+RKc/LRdkChN4QS3O97ws4ho4/jyufHm/0Lz4WY4WPJOr0OPtlBIuCGHouKmZI+ s4N2O69Ksq11tAxxquDIm1RRrr5V6pxcz3hHe9sEPaPZSjSpOk8YN1dVbaSMb22O2U7b t9rA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:dkim-signature; bh=CzRpKelTl9CrAimj3ofHOhvtMfleasVCXHL1PviGDPs=; fh=1tuYsFJiQCT5Wkm/n4xHdwYbo1LrtdB1ozKduz9MEDE=; b=nTXo/NL8NusDpNuBD0XGe4fmDQhtsqO9279riznLUW3xJ/JIjhN3dt3D49PcQ5o5SO CJW4a1QS7d9P7clSlhn9EH++EJhLECT1Rmm0Y3NHtdkHZ5z/vEAX9pu52oC4W16mxM0c hu94BaakCtF23TtZXuj7Nq/aa5uAetXNBUxY2+5jFM9BqL5iJZKloWZl60vDaOJjxxK+ 1hn6Ifg3LKC058W4EASl0i8MeU2EuMXLbsHgl1UmR5IXL++5LbE6jimbW/BwOgqVr6BM eycBcxwu0+pcjWV7HV6MTpsakrM7QobMnV9YUBsd+ZUGsj7CesGUWYU14UCtiT9/ndMf cQVQ==; dara=google.com ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@virtuozzo.com header.s=relay header.b=Sr472Q8c; spf=pass (google.com: domain of andrey.zhadchenko@virtuozzo.com designates 130.117.225.111 as permitted sender) smtp.mailfrom=andrey.zhadchenko@virtuozzo.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=virtuozzo.com Received: from relay.virtuozzo.com (relay.virtuozzo.com. [130.117.225.111]) by mx.google.com with ESMTPS id ffacd0b85a97d-48e71bc0068si23092506f8f.303.2026.11.02.22.22.11 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 02 Nov 2026 22:22:11 -0800 (PST) Received-SPF: pass (google.com: domain of andrey.zhadchenko@virtuozzo.com designates 130.117.225.111 as permitted sender) client-ip=130.117.225.111; Authentication-Results: mx.google.com; dkim=pass header.i=@virtuozzo.com header.s=relay header.b=Sr472Q8c; spf=pass (google.com: domain of andrey.zhadchenko@virtuozzo.com designates 130.117.225.111 as permitted sender) smtp.mailfrom=andrey.zhadchenko@virtuozzo.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=virtuozzo.com DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=virtuozzo.com; s=relay; h=MIME-Version:Message-ID:Date:Subject:From: Content-Type; bh=CzRpKelTl9CrAimj3ofHOhvtMfleasVCXHL1PviGDPs=; b=Sr472Q8ceMB+ B5a7ujRH7N/yB3MO7fmGgysMiX18DjHF49Vx2vCVI5Zp3y5JvyfKz0/9uCvapGS8uS0tJTa3uulin LXBreIcAXtO15iqWqEExwuIBdpqmxsh9Q/qkwXJzjZaRKBh2Nexk+vqMO6iKWxN0xRx3Ik54rOap4 5Ddj/wRdOpl1bPP54p5x1moMzISVx7bi6A1UJdXbq9XVtfoGZ3FPEiMjgWpVwnsMpVAbnSX2SNL8u ekoEhlyOjNe/S754J6XB1FDyNb1P7i5u8g0lRSWmp6IeZ1UxWzBL/hPpBi2VJiYG2I1wjqF4vC5kZ USGwAwUaoKWimpL+PI8o2A==; Received: from [130.117.225.5] (helo=vz9-demens-1.aci.vzint.dev) by relay.virtuozzo.com with esmtp (Exim 4.96) (envelope-from ) id 1xO7qS-005EVh-1L; Tue, 03 Nov 2026 07:22:01 +0100 From: Andrey Zhadchenko To: alexander.ivanov@virtuozzo.com Date: Tue, 3 Nov 2026 09:17:46 +0300 Message-ID: <20261103061752.720813-1-andrey.zhadchenko@virtuozzo.com> X-Mailer: git-send-email 2.43.5 MIME-Version: 1.0 X-OZ-Fwd: true Cc: devel@openvz.org Subject: [Devel] [PATCH hci-8.1 v3 0/6] dm/push_backup: event fd interface and fixes X-BeenThere: devel@openvz.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OpenVZ development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: devel-bounces@openvz.org Errors-To: devel-bounces@openvz.org The push_backup target currently makes the backup tool wait for the next cluster range inside the "push_backup_read" target message. dm runs target_message() under dm_get_live_table(), i.e. with md->io_barrier SRCU read-locked, so while the tool sleeps there anything that needs synchronize_srcu(&md->io_barrier) on that device is stuck: suspend, table reload/remove and dm_internal_suspend_fast() from "@stats_create". An unrelated dm-stats user hangs, and everything that later queues behind md->suspend_lock hangs with it. Patch 6 adds a file descriptor based interface instead. The tool gets an anon inode fd via the "push_backup_get_fd" message and then uses plain read()/write() of struct dm_push_backup_range to fetch the next range and to acknowledge it, without going through dm messages on the data path. The fd pins struct push_backup with a kref so it survives target removal and simply returns -ENODEV afterwards. The legacy messages are kept for compatibility. Patches 1-5 are fixes found while working on this: 1. init the lock, waitqueue and timer before anything that can fail so pb_destroy() is safe from any error path; 2. clear pb->alive under pb->lock like the other users do; 3. drop the redundant mod_timer() in push_backup_write(). The timer re-arms itself from pb->deadline_jiffies, so updating the deadline under the lock is enough. This was also the only place that armed the timer outside the window push_backup_stop() waits for, which matters once writes may arrive via the fd without pb->ctl_rwsem; 4. pass absolute expiry to mod_timer(). Both remaining callers passed a relative value, so after ~5 min of uptime the timer fired and re-armed on every tick while a write was delayed; 5. arm the timer under pb->lock and wait for its callback properly. pb_timer_func() and postpone_if_required_for_backup() both decided under the lock and armed after dropping it, so a stale S64_MAX could overwrite a fresh deadline and park the timer ~12 days out with delayed writes still pending. Also, timer_delete_sync_try() does not wait for a running callback, so one blocked on pb->lock could outlive push_backup_stop() and expire a later session. With arming done under the lock, the callback checking pb->alive and stop/destroy waiting via timer_delete_sync()/timer_shutdown_sync(), the RCU dance between postpone and stop is no longer needed and is removed. v3: - 5/6: pb_timer_func() bails out when !pb->alive; push_backup_stop() uses timer_delete_sync() and pb_destroy() timer_shutdown_sync() instead of WARNing on timer_delete_sync_try() < 0, which never waited for a running callback. Commit message corrected accordingly. - 6/6: push_backup_get_fd() installs the fd only after its number fits into the result buffer (reserve -> emit -> check -> install), so a too small buffer no longer leaks the fd with its pb kref and module reference. pb->dead renamed to pb->destroyed. UAPI type namespaced as struct dm_push_backup_range. read() now requires exactly sizeof(range) like write(). Subject prefix aligned with the rest of the series. v2: - 2/6: reworded the commit message, dropped the KCSAN claim. - 5/6: new patch: arm the deadline timer under pb->lock and drop the rcu_read_lock()/synchronize_rcu() between postpone_if_required_for_backup() and push_backup_stop(). - 6/6: resubmit_pbios() now frees the pbio before dm_requeue_original_rq(). The requeue drops the md reference held by the in-flight request, after which __dm_destroy() may run .dtr and destroy pbio_pool under the fd writer's feet. https://virtuozzo.atlassian.net/browse/VSTOR-152912 Andrey Zhadchenko (6): drivers/md/push_backup: correct initialization drivers/md/push_backup: clear pb->alive under pb->lock drivers/md/push_backup: do not re-arm deadline timer in push_backup_write() drivers/md/push_backup: fix mod_timer() usage drivers/md/push_backup: arm deadline timer under pb->lock drivers/md/push_backup: add event file descriptor interface drivers/md/dm-push-backup.c | 268 +++++++++++++++++++++------- include/uapi/linux/dm-push-backup.h | 39 ++++ 2 files changed, 246 insertions(+), 61 deletions(-) create mode 100644 include/uapi/linux/dm-push-backup.h -- 2.43.5 _______________________________________________ Devel mailing list Devel@openvz.org https://lists.openvz.org/mailman/listinfo/devel