Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933308AbYB2UED (ORCPT ); Fri, 29 Feb 2008 15:04:03 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751504AbYB2UDw (ORCPT ); Fri, 29 Feb 2008 15:03:52 -0500 Received: from smtp-out.google.com ([216.239.33.17]:36893 "EHLO smtp-out.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751194AbYB2UDv (ORCPT ); Fri, 29 Feb 2008 15:03:51 -0500 DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=received:message-id:date:from:to:subject:cc:in-reply-to: mime-version:content-type:content-transfer-encoding: content-disposition:references; b=Qki3vv+tBct62bLvW/dBHFMzpk51/TeSt2MRCcxpqrInsjOLF/SsQ5msCGUbK0OlM 6pXSw4x5TKNThTLb6KZoQ== Message-ID: <65dd6fd50802291203g5c183b49mb2717e1cd9f691b5@mail.gmail.com> Date: Fri, 29 Feb 2008 12:03:40 -0800 From: "Ollie Wild" To: "Linus Torvalds" Subject: Re: [RFC/PATCH] RLIMIT_ARG_MAX Cc: "Jakub Jelinek" , "Peter Zijlstra" , "Michael Kerrisk" , "Andrew Morton" , michael.kerrisk@gmail.com, carlos@codesourcery.com, "Alan Cox" , linux-kernel , drepper@redhat.com, mtk.manpages@gmail.com In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1204119455.6242.403.camel@lappy> <1204305488.6243.113.camel@lappy> <1204306934.6243.119.camel@lappy> <65dd6fd50802291101j3786ee60iec0f3a24f5df9945@mail.gmail.com> <20080229190952.GM24887@devserv.devel.redhat.com> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1299 Lines: 27 On Fri, Feb 29, 2008 at 11:50 AM, Linus Torvalds wrote: > > Another thing we could decide to do is to just check the size of the stack > that is left at the end of all the stack setup code, and just say "if it's > less than X bytes, just return ENOMEM rather than set up a process with a > really unusably small stack". What would be a reasonable value, though? Whereas argument space is static and known at process execution time, required stack space is program dependent. If the program is going to crash, I'd rather it do so at exec time. Otherwise, we end up with corrupted files, partially committed database transactions, and so forth. I'd rather error on the side of small argument space. In the common situation, a 25% argument allocation is vastly larger than the pre-2.6.23 limit. We're really only talking about cases where the limits have been set to unusually small values. I'd be interested in hearing from people that do this in practice. Why do they do this? What are their expectations? Ollie -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/