From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pg0-f72.google.com (mail-pg0-f72.google.com [74.125.83.72]) by kanga.kvack.org (Postfix) with ESMTP id 6B5516B0003 for ; Thu, 8 Feb 2018 13:56:51 -0500 (EST) Received: by mail-pg0-f72.google.com with SMTP id b4so2073733pgs.5 for ; Thu, 08 Feb 2018 10:56:51 -0800 (PST) Received: from bombadil.infradead.org (bombadil.infradead.org. [65.50.211.133]) by mx.google.com with ESMTPS id v8-v6si327111plp.785.2018.02.08.10.56.50 for (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 08 Feb 2018 10:56:50 -0800 (PST) Date: Thu, 8 Feb 2018 10:56:48 -0800 From: Matthew Wilcox Subject: Re: [RFC] Warn the user when they could overflow mapcount Message-ID: <20180208185648.GB9524@bombadil.infradead.org> References: <20180208021112.GB14918@bombadil.infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: owner-linux-mm@kvack.org List-ID: To: Daniel Micay Cc: Jann Horn , linux-mm@kvack.org, Kernel Hardening , kernel list , "Kirill A. Shutemov" On Thu, Feb 08, 2018 at 01:05:33PM -0500, Daniel Micay wrote: > The standard map_max_count / pid_max are very low and there are many > situations where either or both need to be raised. [snip good reasons] > I do think the default value in the documentation should be fixed but > if there's a clear problem with raising these it really needs to be > fixed. Google either of the sysctl names and look at all the people > running into issues and needing to raise them. It's only going to > become more common to raise these with people trying to use lots of > fine-grained sandboxing. Process-per-request is back in style. So we should make the count saturate instead, then? That's going to be interesting. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org