[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <56D5D592.2020800@kernel.dk>
Date: Tue, 1 Mar 2016 10:46:58 -0700
From: Jens Axboe <axboe@...nel.dk>
To: Tejun Heo <tj@...nel.org>, Tahsin Erdogan <tahsin@...gle.com>
Cc: Jan Kara <jack@...e.cz>, cgroups@...r.kernel.org,
Theodore Ts'o <tytso@....edu>,
Nauman Rafique <nauman@...gle.com>,
linux-kernel@...r.kernel.org, Jan Kara <jack@...e.com>,
Al Viro <viro@...IV.linux.org.uk>
Subject: Re: [PATCH v2 block/for-linus] writeback: flush inode cgroup wb
switches instead of pinning super_block
On 02/29/2016 04:28 PM, Tejun Heo wrote:
> If cgroup writeback is in use, inodes can be scheduled for
> asynchronous wb switching. Before 5ff8eaac1636 ("writeback: keep
> superblock pinned during cgroup writeback association switches"), this
> could race with umount leading to super_block being destroyed while
> inodes are pinned for wb switching. 5ff8eaac1636 fixed it by bumping
> s_active while wb switches are in flight; however, this allowed
> in-flight wb switches to make umounts asynchronous when the userland
> expected synchronosity - e.g. fsck immediately following umount may
> fail because the device is still busy.
>
> This patch removes the problematic super_block pinning and instead
> makes generic_shutdown_super() flush in-flight wb switches. wb
> switches are now executed on a dedicated isw_wq so that they can be
> flushed and isw_nr_in_flight keeps track of the number of in-flight wb
> switches so that flushing can be avoided in most cases.
>
> v2: Move cgroup_writeback_umount() further below and add MS_ACTIVE
> check in inode_switch_wbs() as Jan an Al suggested.
I queued this up for 4.5, but I'm feeling a bit uneasy about it. But
it's either that, or revert 5ff8eaac1636 and fix it for real in 4.6.
Jan/Tejun, what do you think?
--
Jens Axboe
Powered by blists - more mailing lists