Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp1027202imu; Thu, 20 Dec 2018 08:59:46 -0800 (PST) X-Google-Smtp-Source: AFSGD/WQlS1eqygAobsQ6VYhMJuj8ap0otRVa9Ou/3GtsEV/A1Xr35NGExe2DtSjalGhlCbChJL7 X-Received: by 2002:a63:da45:: with SMTP id l5mr23996169pgj.111.1545325186459; Thu, 20 Dec 2018 08:59:46 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1545325186; cv=none; d=google.com; s=arc-20160816; b=X9S4VhL0AJYgfeCMWoiCA3jdE+gSi9W52BUyxPX+X8Jji/6ATsSTPGMgR5JR21CuET SQlD2ib3Uj6s6pwVp7WIptoakvZjbCUguys2FSMCQ5V0sNDYUu7yst4x5Terj3W+WNN/ 6FoQ7CpoZyTOosZBFSmnGFUuuuGyrOhYgVJQOi76Z7igExh2y0eyFznmS6Ehta1quvXO bz2vxf/hfQAqF/c6Odf0iMkQoEp8f1nDdDsCV5w4zLAxAwLhbB9VAZZTkei7RltbHgot Nl3iSc02gxkAkvEJhbehDzgh1aRHhqkUrc4pu1GPNPKVmplF+g5+NyFc03IIfglIhI2U RcFQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:references:in-reply-to:message-id:date :subject:cc:to:from; bh=bR6nvuDam6cLDCzFJvSOHrAwmnDiUoEfXmIoY7CCLfY=; b=dz10FQUJjybtgrZTMzgSLkDOSh+C0MgB/wPKIPvLVfIKb5NIk3BkswV1elXNda4A+j GSXMPjTf1q7lqi+o5462kU0qz+EoFwqeBzaFDPN8KJABRKj6H5EKDXeyDLlBi0xWXaSl 3HTZzCPVY+ZHiOhh0VbZKuDXFYxM0HqNSwLAGis/bfuheh6qSQo4wwYZinWLjAitMcEC WEVziwvq+c5qeYFOc3qFyLvZ5LckYoq+4AwaYkxMLlCg3BZNSHAPXqAB0dpjIO+4UW/b uy2hqAZkqo0T5z8K8QfF6r2JdPTYD80UlX5WjMpzoJMNxhL8LDlR6kFOniG1J21NKAPw WDFQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id i63si16370006pgc.116.2018.12.20.08.59.30; Thu, 20 Dec 2018 08:59:46 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730509AbeLTQej (ORCPT + 99 others); Thu, 20 Dec 2018 11:34:39 -0500 Received: from mail09.linbit.com ([212.69.161.110]:50096 "EHLO mail09.linbit.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727387AbeLTQei (ORCPT ); Thu, 20 Dec 2018 11:34:38 -0500 Received: from soda.linbit (212-186-191-219.static.upcbusiness.at [212.186.191.219]) by mail09.linbit.com (LINBIT Mail Daemon) with ESMTP id 548541045C31; Thu, 20 Dec 2018 17:23:48 +0100 (CET) From: Lars Ellenberg To: Jens Axboe , linux-kernel@vger.kernel.org, linux-block@vger.kernel.org Cc: drbd-dev@lists.linbit.com Subject: [PATCH 10/17] drbd: do not block when adjusting "disk-options" while IO is frozen Date: Thu, 20 Dec 2018 17:23:37 +0100 Message-Id: <20181220162344.8430-11-lars.ellenberg@linbit.com> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20181220162344.8430-1-lars.ellenberg@linbit.com> References: <20181220162344.8430-1-lars.ellenberg@linbit.com> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org "suspending" IO is overloaded. It can mean "do not allow new requests" (obviously), but it also may mean "must not complete pending IO", for example while the fencing handlers do their arbitration. When adjusting disk options, we suspend io (disallow new requests), then wait for the activity-log to become unused (drain all IO completions), and possibly replace it with a new activity log of different size. If the other "suspend IO" aspect is active, pending IO completions won't happen, and we would block forever (unkillable drbdsetup process). Fix this by skipping the activity log adjustment if the "al-extents" setting did not change. Also, in case it did change, fail early without blocking if it looks like we would block forever. Signed-off-by: Lars Ellenberg --- drivers/block/drbd/drbd_nl.c | 37 ++++++++++++++++++++++++++++-------- 1 file changed, 29 insertions(+), 8 deletions(-) diff --git a/drivers/block/drbd/drbd_nl.c b/drivers/block/drbd/drbd_nl.c index 4b934e543e2d..1958eb33b643 100644 --- a/drivers/block/drbd/drbd_nl.c +++ b/drivers/block/drbd/drbd_nl.c @@ -1540,6 +1540,30 @@ static void sanitize_disk_conf(struct drbd_device *device, struct disk_conf *dis } } +static int disk_opts_check_al_size(struct drbd_device *device, struct disk_conf *dc) +{ + int err = -EBUSY; + + if (device->act_log && + device->act_log->nr_elements == dc->al_extents) + return 0; + + drbd_suspend_io(device); + /* If IO completion is currently blocked, we would likely wait + * "forever" for the activity log to become unused. So we don't. */ + if (atomic_read(&device->ap_bio_cnt)) + goto out; + + wait_event(device->al_wait, lc_try_lock(device->act_log)); + drbd_al_shrink(device); + err = drbd_check_al_size(device, dc); + lc_unlock(device->act_log); + wake_up(&device->al_wait); +out: + drbd_resume_io(device); + return err; +} + int drbd_adm_disk_opts(struct sk_buff *skb, struct genl_info *info) { struct drbd_config_context adm_ctx; @@ -1602,15 +1626,12 @@ int drbd_adm_disk_opts(struct sk_buff *skb, struct genl_info *info) } } - drbd_suspend_io(device); - wait_event(device->al_wait, lc_try_lock(device->act_log)); - drbd_al_shrink(device); - err = drbd_check_al_size(device, new_disk_conf); - lc_unlock(device->act_log); - wake_up(&device->al_wait); - drbd_resume_io(device); - + err = disk_opts_check_al_size(device, new_disk_conf); if (err) { + /* Could be just "busy". Ignore? + * Introduce dedicated error code? */ + drbd_msg_put_info(adm_ctx.reply_skb, + "Try again without changing current al-extents setting"); retcode = ERR_NOMEM; goto fail_unlock; } -- 2.17.1