Received: by 2002:a05:6a10:22f:0:0:0:0 with SMTP id 15csp3699244pxk; Tue, 29 Sep 2020 04:09:17 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwstxpmTGz/uMnGSNcuj9qNfN03XIc7u4bKp8FII+Smxip87nrb2svFluD0uK2//Rjl/R8J X-Received: by 2002:a17:906:4d57:: with SMTP id b23mr3171202ejv.496.1601377756902; Tue, 29 Sep 2020 04:09:16 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1601377756; cv=none; d=google.com; s=arc-20160816; b=SOmFahf5QTcr2iQ6YA5B9GFryP/QupZZ2VLDPrdYlvbqTIdrzibElB5vT6SHRTwe7q PJ2jJYIeIjwJ4H82WdbZpLFr1XWrPn1CTjF4/5HHYa830mXbVE5Z53iR1HxMU1QjoTtt xIo6jaElLXO7B9XtBE6FlzJXuCY1C3LpEZ7EOnxwNexCzUY8vN5c2AUWPAt1upSfa1Vm YU1+ckHLXBWh9mCzEwghK30hm9Sz9OMSAj3vt+U+BEac6jazXJeWU6DkA8zsFzX7W0Ni za2hk7vta+fmBPsor3gxXWqoA9zB/RoEfEHvNIBt7Mb5doh6Il1HxIRrvr1bffHLucwU 4m7Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=CfkIRoUjIeBKeO25HW8uV6ThD49hY+jfqO9hehOKqaU=; b=r6fedJCxNMilOmuobWQwQ04WqJnKiMYJWyK8dOl0BT3baLO3WBk8SmLY3nfZr5YlTu F0+DdnJHgwOUUPinn7GlePA7j8CVmykzMxapWWgtFLfyZHsQAn7ONozjyp5w/zEqTGzP nQY8g0p6oEL+OizezflWNOtZJ/30bmn0dbxQIg5mIsDbmmQK4I0vwZ9h5WF560wp+d74 7K+/qfBs1zNujPlzH/lfc7ySah2p5Cqci1bidB+my4ksDVl27lWIuGjGf6x4TttnTNja /96LTJCB2SrAk/++vOfjAlSKlyxkUr8adkn0HX8/uMNVPFVX9xNx8LNJByoeGYOi3EWa A15w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=PIh3ucjs; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id e14si2678712edm.126.2020.09.29.04.08.53; Tue, 29 Sep 2020 04:09:16 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=PIh3ucjs; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728672AbgI2LE5 (ORCPT + 99 others); Tue, 29 Sep 2020 07:04:57 -0400 Received: from mail.kernel.org ([198.145.29.99]:40994 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728586AbgI2LEq (ORCPT ); Tue, 29 Sep 2020 07:04:46 -0400 Received: from localhost (83-86-74-64.cable.dynamic.v4.ziggo.nl [83.86.74.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 1E94021941; Tue, 29 Sep 2020 11:04:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1601377485; bh=Jahdm4xMGPlEmC2nqoU6EoQ5t9b52s1eHlmXkV9EV9Y=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=PIh3ucjsa7mudIkTAU8+xdLaclDAuWzSCN6zzqsu9GQENJPD15ELq01PXgkd8wun8 p1hKOygGBvabGSYO2+lYa4ONW7pStSAorxuYXPLSgiFuELkl/ISnvS4rmqhUckpPr5 0SLMyucEZif/iWkGyz5xLmtXRyLXXy45flNcoCcg= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Douglas Anderson , Guenter Roeck , Christoph Hellwig , Jens Axboe , Sasha Levin Subject: [PATCH 4.4 52/85] bdev: Reduce time holding bd_mutex in sync in blkdev_close() Date: Tue, 29 Sep 2020 13:00:19 +0200 Message-Id: <20200929105930.829340482@linuxfoundation.org> X-Mailer: git-send-email 2.28.0 In-Reply-To: <20200929105928.198942536@linuxfoundation.org> References: <20200929105928.198942536@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Douglas Anderson [ Upstream commit b849dd84b6ccfe32622988b79b7b073861fcf9f7 ] While trying to "dd" to the block device for a USB stick, I encountered a hung task warning (blocked for > 120 seconds). I managed to come up with an easy way to reproduce this on my system (where /dev/sdb is the block device for my USB stick) with: while true; do dd if=/dev/zero of=/dev/sdb bs=4M; done With my reproduction here are the relevant bits from the hung task detector: INFO: task udevd:294 blocked for more than 122 seconds. ... udevd D 0 294 1 0x00400008 Call trace: ... mutex_lock_nested+0x40/0x50 __blkdev_get+0x7c/0x3d4 blkdev_get+0x118/0x138 blkdev_open+0x94/0xa8 do_dentry_open+0x268/0x3a0 vfs_open+0x34/0x40 path_openat+0x39c/0xdf4 do_filp_open+0x90/0x10c do_sys_open+0x150/0x3c8 ... ... Showing all locks held in the system: ... 1 lock held by dd/2798: #0: ffffff814ac1a3b8 (&bdev->bd_mutex){+.+.}, at: __blkdev_put+0x50/0x204 ... dd D 0 2798 2764 0x00400208 Call trace: ... schedule+0x8c/0xbc io_schedule+0x1c/0x40 wait_on_page_bit_common+0x238/0x338 __lock_page+0x5c/0x68 write_cache_pages+0x194/0x500 generic_writepages+0x64/0xa4 blkdev_writepages+0x24/0x30 do_writepages+0x48/0xa8 __filemap_fdatawrite_range+0xac/0xd8 filemap_write_and_wait+0x30/0x84 __blkdev_put+0x88/0x204 blkdev_put+0xc4/0xe4 blkdev_close+0x28/0x38 __fput+0xe0/0x238 ____fput+0x1c/0x28 task_work_run+0xb0/0xe4 do_notify_resume+0xfc0/0x14bc work_pending+0x8/0x14 The problem appears related to the fact that my USB disk is terribly slow and that I have a lot of RAM in my system to cache things. Specifically my writes seem to be happening at ~15 MB/s and I've got ~4 GB of RAM in my system that can be used for buffering. To write 4 GB of buffer to disk thus takes ~4000 MB / ~15 MB/s = ~267 seconds. The 267 second number is a problem because in __blkdev_put() we call sync_blockdev() while holding the bd_mutex. Any other callers who want the bd_mutex will be blocked for the whole time. The problem is made worse because I believe blkdev_put() specifically tells other tasks (namely udev) to go try to access the device at right around the same time we're going to hold the mutex for a long time. Putting some traces around this (after disabling the hung task detector), I could confirm: dd: 437.608600: __blkdev_put() right before sync_blockdev() for sdb udevd: 437.623901: blkdev_open() right before blkdev_get() for sdb dd: 661.468451: __blkdev_put() right after sync_blockdev() for sdb udevd: 663.820426: blkdev_open() right after blkdev_get() for sdb A simple fix for this is to realize that sync_blockdev() works fine if you're not holding the mutex. Also, it's not the end of the world if you sync a little early (though it can have performance impacts). Thus we can make a guess that we're going to need to do the sync and then do it without holding the mutex. We still do one last sync with the mutex but it should be much, much faster. With this, my hung task warnings for my test case are gone. Signed-off-by: Douglas Anderson Reviewed-by: Guenter Roeck Reviewed-by: Christoph Hellwig Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin --- fs/block_dev.c | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/fs/block_dev.c b/fs/block_dev.c index b2ebfd96785b7..a71d442ef7d0e 100644 --- a/fs/block_dev.c +++ b/fs/block_dev.c @@ -1515,6 +1515,16 @@ static void __blkdev_put(struct block_device *bdev, fmode_t mode, int for_part) struct gendisk *disk = bdev->bd_disk; struct block_device *victim = NULL; + /* + * Sync early if it looks like we're the last one. If someone else + * opens the block device between now and the decrement of bd_openers + * then we did a sync that we didn't need to, but that's not the end + * of the world and we want to avoid long (could be several minute) + * syncs while holding the mutex. + */ + if (bdev->bd_openers == 1) + sync_blockdev(bdev); + mutex_lock_nested(&bdev->bd_mutex, for_part); if (for_part) bdev->bd_part_count--; -- 2.25.1