lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20130821133804.87ca602dd864df712e67342a@linux-foundation.org>
Date:	Wed, 21 Aug 2013 13:38:04 -0700
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Maxim Patlasov <mpatlasov@...allels.com>
Cc:	riel@...hat.com, jack@...e.cz, dev@...allels.com,
	miklos@...redi.hu, fuse-devel@...ts.sourceforge.net,
	xemul@...allels.com, linux-kernel@...r.kernel.org,
	jbottomley@...allels.com, linux-mm@...ck.org,
	viro@...iv.linux.org.uk, linux-fsdevel@...r.kernel.org,
	fengguang.wu@...el.com, devel@...nvz.org, mgorman@...e.de
Subject: Re: [PATCH] mm: strictlimit feature -v4

On Wed, 21 Aug 2013 17:56:32 +0400 Maxim Patlasov <mpatlasov@...allels.com> wrote:

> The feature prevents mistrusted filesystems to grow a large number of dirty
> pages before throttling. For such filesystems balance_dirty_pages always
> check bdi counters against bdi limits. I.e. even if global "nr_dirty" is under
> "freerun", it's not allowed to skip bdi checks. The only use case for now is
> fuse: it sets bdi max_ratio to 1% by default and system administrators are
> supposed to expect that this limit won't be exceeded.
> 
> The feature is on if a BDI is marked by BDI_CAP_STRICTLIMIT flag.
> A filesystem may set the flag when it initializes its BDI.

Now I think about it, I don't really understand the need for this
feature.  Can you please go into some detail about the problematic
scenarios and why they need fixing?  Including an expanded descritopn
of the term "mistrusted filesystem"?

Is this some theoretical happens-in-the-lab thing, or are real world
users actually hurting due to the lack of this feature?

I think I'll apply it to -mm for now to get a bit of testing, but would
very much like it if Fengguang could find time to review the
implementation, please.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ