Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1030415AbdLSNFS (ORCPT ); Tue, 19 Dec 2017 08:05:18 -0500 Received: from mx2.suse.de ([195.135.220.15]:38478 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S936916AbdLSNE4 (ORCPT ); Tue, 19 Dec 2017 08:04:56 -0500 Date: Tue, 19 Dec 2017 14:04:54 +0100 From: Jan Kara To: Tejun Heo Cc: Jan Kara , Jens Axboe , cgroups@vger.kernel.org, xuejiufei , kernel-team@fb.com, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org Subject: Re: [PATCH v2] writeback: synchronize sync(2) against cgroup writeback membership switches Message-ID: <20171219130454.GJ2277@quack2.suse.cz> References: <20171205182007.GV2421075@devbig577.frc2.facebook.com> <8844b550-d91c-38d5-997a-a899d1e4aa42@gmail.com> <20171211195052.GN2421075@devbig577.frc2.facebook.com> <20171212163830.GC3919388@devbig577.frc2.facebook.com> <20171213110004.GB23068@quack2.suse.cz> <20171213153930.GO3919388@devbig577.frc2.facebook.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20171213153930.GO3919388@devbig577.frc2.facebook.com> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1062 Lines: 30 On Wed 13-12-17 07:39:30, Tejun Heo wrote: > Hello, > > On Wed, Dec 13, 2017 at 12:00:04PM +0100, Jan Kara wrote: > > OK, but this effectively prevents writeback from sync_inodes_sb() to ever > > make inode switch wbs. Cannot that be abused in some way like making sure > > writeback of our memcg is "invisible" by forcing it out using sync(2)? It > > just looks a bit dangerous to me... > > That's true. There are a couple mitigating factors tho. > > * While it can delay switching during sync(2), it'll all still be > recorded and the switch will happen soon if needed. > > * sync(2) is hugely disruptive with or without this and can easily be > used to DOS the whole system. People are working on restricting the > blast radius of sync(2) to mitigate this problem, which most likely > make this a non-problem too. > > If you can think of a better solution, I'm all ears. After some thinking about this I don't have a better solution. So you can add: Acked-by: Jan Kara Honza -- Jan Kara SUSE Labs, CR