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=-1.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS autolearn=ham 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 DE111C43219 for ; Thu, 2 May 2019 15:51:12 +0000 (UTC) Received: from shelob.surriel.com (shelob.surriel.com [96.67.55.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 76585204EC for ; Thu, 2 May 2019 15:51:12 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 76585204EC Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=vt.edu Authentication-Results: mail.kernel.org; spf=fail smtp.mailfrom=kernelnewbies-bounces@kernelnewbies.org Received: from localhost ([::1] helo=shelob.surriel.com) by shelob.surriel.com with esmtp (Exim 4.91) (envelope-from ) id 1hMDzB-0000Dk-IY; Thu, 02 May 2019 11:51:01 -0400 Received: from omr2.cc.ipv6.vt.edu ([2607:b400:92:8400:0:33:fb76:806e] helo=omr2.cc.vt.edu) by shelob.surriel.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1hMDz9-0000Db-5X for kernelnewbies@kernelnewbies.org; Thu, 02 May 2019 11:50:59 -0400 Received: from mr4.cc.vt.edu (mr4.cc.ipv6.vt.edu [IPv6:2607:b400:92:8300:0:7b:e2b1:6a29]) by omr2.cc.vt.edu (8.14.4/8.14.4) with ESMTP id x42FovBK003660 for ; Thu, 2 May 2019 11:50:58 -0400 Received: from mail-qk1-f198.google.com (mail-qk1-f198.google.com [209.85.222.198]) by mr4.cc.vt.edu (8.14.7/8.14.7) with ESMTP id x42Foqpl007650 for ; Thu, 2 May 2019 11:50:57 -0400 Received: by mail-qk1-f198.google.com with SMTP id o64so2742862qka.16 for ; Thu, 02 May 2019 08:50:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:to:cc:subject:in-reply-to:references :mime-version:content-transfer-encoding:date:message-id; bh=5jPMUbgQBYIvkdG0BMJHfWh0QaZuNR8i8yh+/b1nXJU=; b=jyDfTZN5geN9grwwgTaPlwFG5haqEl2hdX3JVZ/p1JFF89PvHr2g+KZpDtotI9jLv6 xCCbSfZT9yIJP5lps42FP+ampWIo7EYjceXljTPu+Sn7hjGEpSF6+mkp725sFEmsylMa 3k6O0//+Vl310srua216MO5A8Sw3nC9a0XWpwu2SUsfiROzmEFmjsrwZwNK3GLoq8vOk awyPicoU/oUOhRAtfHVwFT/ZdDsED3usdtGcW3OfxAOMtnuGKFthvQYjA30VWZw53VhS yjsmMmIxNe4oSKfse/JHhvNV2eTFtRxfuO8u3vuHzGHtFNJIQ5coQF8XdtylPuDHIvJb 3G7A== X-Gm-Message-State: APjAAAXqtr1eCgUBKM0zdSBI+T+AHVNouGPCDnrw59scMgH0dgcH6pCk RK1BlkZxsVk+fhIZD1mc8BC6NLmGu2FDO+AQAE1L5bQ50zdRLizekqT3ozl3Xu8JF4kRFTVJ/CW C7m2oDHaWF/YWz5E48pnXKo6xEg77hEesHf7Jrzs= X-Received: by 2002:aed:3eb8:: with SMTP id n53mr2414594qtf.286.1556812251754; Thu, 02 May 2019 08:50:51 -0700 (PDT) X-Google-Smtp-Source: APXvYqwx0OZ5V21kM0Mruq5lXbDimsLwQqiRDJ9UaYBpMwbECeJ0jYijZr67IJSOwKRac8rHpFniag== X-Received: by 2002:aed:3eb8:: with SMTP id n53mr2414567qtf.286.1556812251414; Thu, 02 May 2019 08:50:51 -0700 (PDT) Received: from turing-police ([2601:5c0:c001:4341:5952:f06b:5958:9b7c]) by smtp.gmail.com with ESMTPSA id h27sm28312049qtc.1.2019.05.02.08.50.48 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 02 May 2019 08:50:49 -0700 (PDT) From: "Valdis Kl=?utf-8?Q?=c4=93?=tnieks" X-Google-Original-From: "Valdis Kl=?utf-8?Q?=c4=93?=tnieks" X-Mailer: exmh version 2.9.0 11/07/2018 with nmh-1.7+dev To: Karaoui mohamed lamine Subject: Re: ULIMIT: limiting user virtual address space (stack inluded) In-Reply-To: References: Mime-Version: 1.0 Date: Thu, 02 May 2019 11:50:47 -0400 Message-ID: <13792.1556812247@turing-police> Cc: kernelnewbies@kernelnewbies.org X-BeenThere: kernelnewbies@kernelnewbies.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Learn about the Linux kernel List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============3775399706765224241==" Errors-To: kernelnewbies-bounces@kernelnewbies.org --===============3775399706765224241== Content-Type: multipart/signed; boundary="==_Exmh_1556812247_11736P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit --==_Exmh_1556812247_11736P Content-Type: text/plain; charset=us-ascii On Thu, 02 May 2019 09:06:09 -0400, Karaoui mohamed lamine said: > According to the man page of "ulimit", it is possible to limit the virtual > address space of a user process: https://ss64.com/bash/ulimit.html > To limit the virtual address space to 2 GB: > $ ulimit -SH -v 1048576 It's possible. It also probably doesn't do what you think it does. In particular, you may be looking for the -d (data) and/or -m (memory) flags. Also, to limit it to 2G, you're going to need 'ulimit -v 2097152' > However, it seems that "stack" allocation ignores this limit (I tried with > both kernel 4.4 and 4.15). I'm going to go out on a limb and say that what you think is happening is not in fact what is happening. > I found this article (patch) that seems to fix the problem: > https://lwn.net/Articles/373701/ It's unclear what your actual problem is, but given that the patch has been in the kernel for a decade, it's almost certainly not related. > My questions are: > - Why is the stack allocation not placed within the "ulimit" limit? (is it > a bug?) Rule of thumb: Before asking why something happens, verify that it does in fact happen. Consider the following C program: [~] cat > moby-stack.c #include #define MOBYSTACK 16384 #define BIG 2048 int recurse(int level) { double a[BIG]; /* chew up stack space */ if (level == MOBYSTACK) sleep(9999999); recurse(level+1); } int main() {recurse(0); }; ^D [~] gcc moby-stack.c [~] ulimit -v 16384 [~] ulimit -s 32768 [~] ./a.out Segmentation fault (core dumped) Examination of the core file shows it created 895 stack entries, for a total of 895 * 8 * 2048 or 14,663,680 or so bytes of stack. That's about what you'd expect given a virtual limit of 16M, and a bit of space taken up by shared libraries and so on. Re-running with a virtual limit of 32768 lets it get 1916 stack entries deep. Again, that's about where you'd expect the explosion to happen with that virtual limit in place. So regardless of the stack limit, it blows up when it gets to the -v limit. Conclusion: The stack *is* included in the -v virtual limit. > - Is there a way, in user space, to force the stack to be allocated at a > certain address? Sure. mmap() yourself a chunk of anonymous pages at the address you want, and call a little assembler stub that sets your registers. You'll probably have to ensure you allocate enough pages, or handle expanding onto new pages yourself (including making sure there's free pages to grow into). And of course, you're basically stuck with that stack, returning to older functions on the old stack is going to be *really* hard. So you'll probably want to do that in main(). Google for 'linux green threads' for the gory details. Java used them on Linux until 2017 or so. > - Will the patch above (or similar) ever be integrated into the Linux > kernel? See above. It's been in the kernel for a decade. --==_Exmh_1556812247_11736P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Comment: Exmh version 2.9.0 11/07/2018 iQIVAwUBXMsR1gdmEQWDXROgAQIJthAAl3iND5ayx7KR1qEbHdN7bTZyinQ7H66j DfMuhHa+QH8rmjkQzy8YmwgIm6VfzkjaUiv+DdYKOW1r+N3cytYI2glGn2BNk5r/ wAGP8Ttd8OL+GwEw0exV6uusvC5qmgkHYtottnZec0XRechQXbgqJlL0d6eSnt38 fItrg13vhLnRmzV/l7Ji9IN3rQKXQoX+xKeBLdCtDiMSurl7kx6frh+d+caIM0bA 6g45PiOHYAkICQlrMWvUQ5FZwvi8BOxZmiOIo9eTlSaQANHoKGVbPwTm+DVy3xsu wsHTh6a3az3hQ4kVI9RHetNsuIgIrGAsNOu+FoW2RcI6kU17jktHoR43orbcdWK6 NLmhfUQs+uGsLtpCqUIyav5kKpfV7aPzKORsF6Bt+3ahJxf6CstQjXlbqLiiK67s JNCJKXmlbzv7zVizLDwyMLbBZ0DMv+BgXgoN9u7WstqgZ36NdJhhKu1YxEUsUrEQ 0TOHohnopKMCrUbw8mAOCIntbR13+Qut9GjEBbi7iRAfBbmcHkyoNb8oFSsyUqL2 WZAVXXVMphoBbrnptJ3gkWQUaYs0Ra50pOpJ90RJTh25Zoyv3DErlPcgrUl9MBS4 WORLCF1sBvwvdxgk/YbJlH6ndu27EMPjwM2sP9Rj9vwAEpTknGfXp/N7K14MFHkQ jRg7QUuefNA= =AYxc -----END PGP SIGNATURE----- --==_Exmh_1556812247_11736P-- --===============3775399706765224241== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies --===============3775399706765224241==--