From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752313AbbJFKv4 (ORCPT ); Tue, 6 Oct 2015 06:51:56 -0400 Received: from mout.kundenserver.de ([212.227.126.130]:60709 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751451AbbJFKvy (ORCPT ); Tue, 6 Oct 2015 06:51:54 -0400 From: Arnd Bergmann To: Dave Martin Cc: linux-arm-kernel@lists.infradead.org, catalin.marinas@arm.com, will.deacon@arm.com, linux-kernel@vger.kernel.org, Akhilesh Kumar , Rohit Thapliyal , Manjeet Pawar , pankaj.m@samsung.com, Andreas Schwab Subject: Re: [PATCHv2] ARM64:Fix MINSIGSTKSZ and SIGSTKSZ Date: Tue, 06 Oct 2015 12:51:24 +0200 Message-ID: <5340366.WTVksOGb0G@wuerfel> User-Agent: KMail/4.11.5 (Linux/3.16.0-10-generic; KDE/4.11.5; x86_64; ; ) In-Reply-To: <20151006103128.GN6281@e103592.cambridge.arm.com> References: <1444109743-8561-1-git-send-email-manjeet.p@samsung.com> <5022096.8QRzW0l3EJ@wuerfel> <20151006103128.GN6281@e103592.cambridge.arm.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V03:K0:iPAN3SokxT6q0Jhjm4Wb45XP5KR4IJbUvb8+WiOvq444nYbpQbY ARB6hqLePmfnG6MqPUSXnAS0Rt7aGrUOsUZf++R8mOQfjS3IbuphDf9or8SRVpAUbEEANtA IOxy0/BPtcU5Z0QJ09/0Wc6gkBi/yytiqcGMLsIIEJPRdI3w6XjbcDLluzeEyPHmqbLmMG5 ozJlAd8Bp4MAEwB+DG4ig== X-UI-Out-Filterresults: notjunk:1;V01:K0:lTz1ulCsXOY=:7iLkvXCfD+/Obla/yBXaSU +TpaJ7muXYV1Wx9B/6PRAvuJN5e/5X5LKTFaYMZbO6B87lV7GcKW1Q3fZ9fT5sU4ioXB3/Pzm +tthzjWiWOaW8/KLy3RjSpMHOBWpw9XQU1d7Ig6414+CvWR8aQTH/X+Zk/3xqxBSBPFYO+WPG h7gP77PgjpJYqvqstMF8xZKRdvu9GUo1B3Nx/y/ELopWi02Aa7tlj0AL16m519wcaFPbL2eM6 rOJ5SoLz4s7l67KhRgB+7WSD5/zQkUyAMQzRYndIiVyFgBv8EzAC7hj62hk0TvYlJlMqBPgyE dTmzIt5esj865BXRp2TtMAII+acZcrmYiKw2oQokfJZOMV3LV6PaKm7FJKejvNFLtOY3sA2Hn xJCM5x8ZJt9mi10XMmqsVN4stQpqRGviNIutJ0lfuhKbcFfBQEkCPETOh+OSxHeXPRAGKW1Am CmAwHt6tlV5hyD/SkSU2LgxzluFO8NINrheaMyFxO/iUuFcs0jcmuxWZtU/WRC+zBooPgfdTs WgNpoIJuNGPgQDGVKqzDJHU6mHXDuzG12HvCSXZ6Jx157Jhg8irTugJ5laS9ORvAsOrneHKXd KI3GRT/A/kmx5XPzODn7Zb5wYKUHmComL3B9skrG0tlnMS/LR5GO2AUNtim7gNJlQ3PS6VAXa eGw07YcR0YeRVYFFbWf4ghWx8imu4vnNGqALkGQiGZRhLe5D473ERIorF6emPAk5a9nCSCot7 o7XiyHe7y5OlAUuf Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tuesday 06 October 2015 11:31:34 Dave Martin wrote: > On Tue, Oct 06, 2015 at 09:49:29AM +0200, Arnd Bergmann wrote: > > * Can you explain in the changelog how the numbers were decided? > > I don't see any other architecture using 5kb and cannot see why > > it has to be this value rather than something else. > > glibc quietly "fixed" this earlier this year, by inventing these numbers > and putting them in the glibc headers. [1] I saw the commit, but the changelog is not really useful. > Except for a moribund architecture that will never be extended I > think that the idea of MINSIGSTKSZ is badly flawed -- a #define > for not-necessarily-quite-enough-stack-to-realistically-take-a-signal > is a pretty useless concept even if the signal frame never grows, and > it looks like it is little used in practice. Right, even if we modified the constants in the kernel/glibc headers at that point, it would remain broken for new kernels and old user space. > Since this bug hasn't been reported until now, I suspect that > MINSIGSTKSZ is used very rarely or not at all by real userspace > software. I wonder whether we can get away with simply raising > MINSIGSTKSZ to match SIGSTKSZ, since it's clear that any software > using MINSIGSTKSZ was already broken. I think it makes sense to stick with the traditional definition of MINSIGSTKSZ == "the minimum amount that you will always need, add whatever you require yourself" and SIGSTKSZ == "Should be enough for a couple of function calls". If we want to be conservative in the kernel, using 8192 and 32768, to stay with the x4 ratio that everyone else uses would be my first pick, though I'm not particularly attached to those values. Arnd > [1] https://sourceware.org/ml/libc-alpha/2015-04/msg00033.html