From owner-freebsd-hackers@FreeBSD.ORG Sun Sep 21 19:59:49 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1A04EB67 for ; Sun, 21 Sep 2014 19:59:49 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 95084FE for ; Sun, 21 Sep 2014 19:59:48 +0000 (UTC) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id s8LJxh22045017 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 21 Sep 2014 22:59:43 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua s8LJxh22045017 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id s8LJxhdk045016; Sun, 21 Sep 2014 22:59:43 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 21 Sep 2014 22:59:43 +0300 From: Konstantin Belousov To: suresh gumpula Subject: Re: stack size rlimit Message-ID: <20140921195943.GK2210@kib.kiev.ua> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="nEsDIrWrg+hrB7l1" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Sep 2014 19:59:49 -0000 --nEsDIrWrg+hrB7l1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Sep 21, 2014 at 03:28:38PM -0400, suresh gumpula wrote: > Hi, > I am experimenting the RLIMIT_INFINITY for RLIMIT_STACK and I observed > that we set to maximize(512M) . > Looking at kern_setrlimit() , it seems we are checking this condition and > reseting to maxssize >=20 > While reading through the "design and implementation of freebsd" book , I > came across a point that we map the shared libraries just below the stack > limit. But looking at sample map of curproc, I don't see shared libraries > just below the stack limit. >=20 > in linux , we have two different address map layouts , one is traditional > layout which maps shared libraries somewhere in the middle and the other > one which maps just below the stack limit. > And it seems by default, it prefers the flexible layout. >=20 > Can somebody please confirm freebsd layout convention. ? > This is what I see on freebsd, does not look like its starting below the > stack. The default mmap() area starts right after the end of the max data fragment. I.e., it is after the data segment of the main binary + RLIMIT_DATA. The runtime linker and kernel image activator (for the interpreter mapping) utilize default mmap() selection of the address. You can see this in your map below. >=20 > % cat /proc/curproc/map > 0x400000 0x403000 3 0 0xffffff0003711d80 r-x 1 0 0x1000 COW NC vnode > /bin/cat NCH -1 > 0x602000 0x800000 1 0 0xffffff014816aa20 rw- 1 0 0x3000 NCOW NNC default - > CH 1002 > 0x800602000 0x800638000 34 0 0xffffff0003661ca8 r-x 81 40 0x1004 COW NC > vnode /libexec/ld-elf.so.1 NCH -1 > 0x800638000 0x800640000 7 0 0xffffff0147f2ee58 rw- 1 0 0x3000 NCOW NNC > default - CH 1002 > 0x800837000 0x80083b000 4 0 0xffffff0156ec0000 rw- 1 0 0x3000 COW NNC vno= de > /libexec/ld-elf.so.1 CH 1002 > 0x80083b000 0x80084a000 5 0 0xffffff0147fa16c0 rw- 1 0 0x3000 NCOW NNC > default - CH 1002 > 0x80084a000 0x800984000 116 0 0xffffff00036156c0 r-x 81 40 0x1004 COW NC > vnode /lib/libc.so.7 NCH -1 > 0x800984000 0x800b84000 0 0 0xffffff0147f32d80 --- 1 0 0x2000 NCOW NNC > default - NCH -1 > 0x800b84000 0x800b8f000 11 0 0xffffff0147fb7510 rw- 1 0 0x3000 COW NNC > vnode /lib/libc.so.7 CH 1002 > 0x800b8f000 0x800bf4000 4 0 0xffffff01481676c0 rw- 2 0 0x3000 NCOW NNC > default - CH 1002 > 0x800c00000 0x800e00000 4 0 0xffffff01481676c0 rw- 2 0 0x3000 NCOW NNC > default - CH 1002 > 0x7ffffffe0000 0x800000000000 3 0 0xffffff0156e09000 rwx 1 0 0x3000 NCOW > NNC default - CH 1002 --nEsDIrWrg+hrB7l1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJUHy4vAAoJEJDCuSvBvK1BcEYP/iWGThVZWXBuifB5WDl/NuR9 ykIx/+1mPXPXnULhEK0d21rBAh34Ay0Jog8+XXrgszomPv2c1WfRtxmgvH0b1HBU j32BKjfJmAxkY6iFUp9MN5Zb2NqvlJT93/qMS+XBxzC7kTOQBMWvanqHwz5Hw/y0 Ge/lMp7fQ5a9+ErzN/yytGW+4k1zmmUwlBsHUaZunTa/m/Tqi+nuUfGOxjDCK3um e43QXqCXywwo7UnNcwIrKl6CvyOFZWGG50/3suSu1UNtqlHoHgSabK4KPHLP5FFj f1iM7hP8hqkCJv7VudKyxOZIiNhki2t+GQ2/tOJMTv1qMv3ZipWm2sm1K8Ojr/Tw S2DQL4zBXkwiawkcSk5ZXDfecrSOhVnz3VIM8ab8UZjdESSuAeO4eSkQ5DBg4ox7 NCFhgz2mTWkhZdIrkIClo1UOM6RQ1jHMsNe8mp6vI1Uo/FJh2/Y+l/HafJUAbvnq opUYZj9h4swExiauWbHZHXbqUtT/j4oyJm3dGSVu9xNaQmtSs8Dd7O5B/qN6saly mb3UedFVyXlynMCWCsca1kYVyooMkYx0y9rW37IwPTIBy8ctb3cQIJtMBoBzfmDG pucPo79OQ+FgP0jxgN33CbJEMJowhyC9DbX+YSCfe0uS67n3opLWHklXhzOcfv5B inhuM0Xp/nIqw5jWIT3I =CzS0 -----END PGP SIGNATURE----- --nEsDIrWrg+hrB7l1--