From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.4 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 41248C4727D for ; Mon, 5 Oct 2020 06:12:53 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id AA61C207F7 for ; Mon, 5 Oct 2020 06:12:52 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=suse.com header.i=@suse.com header.b="Zn00WraD" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org AA61C207F7 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=suse.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id F12C86B005D; Mon, 5 Oct 2020 02:12:51 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id EC3E46B0062; Mon, 5 Oct 2020 02:12:51 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D8B3A6B0068; Mon, 5 Oct 2020 02:12:51 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0213.hostedemail.com [216.40.44.213]) by kanga.kvack.org (Postfix) with ESMTP id A6FCA6B005D for ; Mon, 5 Oct 2020 02:12:51 -0400 (EDT) Received: from smtpin16.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 3B0761EE6 for ; Mon, 5 Oct 2020 06:12:51 +0000 (UTC) X-FDA: 77336853342.16.dad06_37154e0271bb Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin16.hostedemail.com (Postfix) with ESMTP id 1B6E5100C5897 for ; Mon, 5 Oct 2020 06:12:51 +0000 (UTC) X-HE-Tag: dad06_37154e0271bb X-Filterd-Recvd-Size: 3094 Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by imf34.hostedemail.com (Postfix) with ESMTP for ; Mon, 5 Oct 2020 06:12:50 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1601878369; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=9UlIgNYow+e5d0wNkhgzXJXHRjARVpEObiHO2PF7OdQ=; b=Zn00WraDkJM6dqF1L360RuBWNmu4+J8ozMIdWZzbF5QtByD1IVAkBJuPRwFF1MoIL6oCPC oPBJdZQcJZd7yrDqbyRB83/6apWx8tgsEJjWC6jPRJLfh82+UPn8VJU3kojRC9eWvWkemG WrAxPKFdPxuOAk1GG3OXlTeyBG6S1AQ= Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 8B9A5B1B9; Mon, 5 Oct 2020 06:12:49 +0000 (UTC) Date: Mon, 5 Oct 2020 08:12:48 +0200 From: Michal Hocko To: Topi Miettinen Cc: David Hildenbrand , akpm@linux-foundation.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] mm: optionally disable brk() Message-ID: <20201005061248.GN4555@dhcp22.suse.cz> References: <20201002171921.3053-1-toiwoton@gmail.com> <653873ef-2a57-37e0-1ac3-fba763652b35@redhat.com> <2a0f5ade-d770-c36e-50bc-ff0c8e9dacbf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2a0f5ade-d770-c36e-50bc-ff0c8e9dacbf@gmail.com> User-Agent: Mutt/1.10.1 (2018-07-13) X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Sat 03-10-20 00:44:09, Topi Miettinen wrote: > On 2.10.2020 20.52, David Hildenbrand wrote: > > On 02.10.20 19:19, Topi Miettinen wrote: > > > The brk() system call allows to change data segment size (heap). This > > > is mainly used by glibc for memory allocation, but it can use mmap() > > > and that results in more randomized memory mappings since the heap is > > > always located at fixed offset to program while mmap()ed memory is > > > randomized. > > > > Want to take more Unix out of Linux? > > > > Honestly, why care about disabling? User space can happily use mmap() if > > it prefers. > > brk() interface doesn't seem to be used much and glibc is happy to switch to > mmap() if brk() fails, so why not allow disabling it optionally? If you > don't care to disable, don't do it and this is even the default. I do not think we want to have config per syscall, do we? There are many other syscalls which are rarely used. Your changelog is actually missing the most important part. Why do we care so much to increase the config space and make the kerneel even more tricky for users to configure? How do I know that something won't break? brk() is one of those syscalls that has been here for ever and a lot of userspace might depend on it. I haven't checked but the code size is very unlikely to be shrunk much as this is mostly a tiny wrapper around mmap code. We are not going to get rid of any complexity. So what is the point? -- Michal Hocko SUSE Labs