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
Hello, Jens.
On Tue, Mar 1, 2016 at 12:46 PM, Jens Axboe <[email protected]> wrote:
> 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?
Given that this only matters for cgroup writeback cases, this should
still be fairly low impact, so I don't think it'd matter too much
whether we fix this in this cycle or for 4.6. However, that also means
that we're not risking much by doing it in this cycle, so I'd vote for
doing it now.
Thanks.
--
tejun
On Tue 01-03-16 12:50:19, Tejun Heo wrote:
> Hello, Jens.
>
> On Tue, Mar 1, 2016 at 12:46 PM, Jens Axboe <[email protected]> wrote:
> > 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?
>
> Given that this only matters for cgroup writeback cases, this should
> still be fairly low impact, so I don't think it'd matter too much
> whether we fix this in this cycle or for 4.6. However, that also means
> that we're not risking much by doing it in this cycle, so I'd vote for
> doing it now.
Yeah, without CGROUP_WRITEBACK enabled this patch is NOP so I don't care
much when this gets merged.
Honza
--
Jan Kara <[email protected]>
SUSE Labs, CR