From owner-freebsd-hackers@FreeBSD.ORG Sun Sep 21 20:19:39 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4ED20E16 for ; Sun, 21 Sep 2014 20:19:39 +0000 (UTC) Received: from mail-vc0-x234.google.com (mail-vc0-x234.google.com [IPv6:2607:f8b0:400c:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0C2D429F for ; Sun, 21 Sep 2014 20:19:38 +0000 (UTC) Received: by mail-vc0-f180.google.com with SMTP id hq11so3494051vcb.11 for ; Sun, 21 Sep 2014 13:19:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=FeQqNFd69Pf2z4RfkwtKTPWT576N3iHabnoOwuzNcCo=; b=CcKIIf+gRg9TfZ6+xkvBVK/le36BXgCANPNPcRqCFxjxwMk2teuoOQZe7Z94P/9Op/ vhVBEzYL5ZbrKntwPf+XhJnCS/nG+rmkRnBMWvtbCvMbEbEJuDVXusSFgam7ZEcUJrDf O+B1+zKlUcxrslPRZMQpjfKQtEcmjZuZ4WA9RyeJ0jRU54gdJkuO97/C3qCEsHmFU4pk dXRGvbD2h1RIF+We7y6LxzwwphaYomCpNbhiX/SURJnPzhAfyDvGKZL+/vm/MTItfcPq FP4ti/VUanM6HvuZFpKHnj7v9vWKszSdotW4IGNM+VQdaYb+PdgAX7Ar2MV0fMvU2hhA lxtQ== MIME-Version: 1.0 X-Received: by 10.52.35.105 with SMTP id g9mr2550087vdj.61.1411330778174; Sun, 21 Sep 2014 13:19:38 -0700 (PDT) Received: by 10.221.22.130 with HTTP; Sun, 21 Sep 2014 13:19:38 -0700 (PDT) In-Reply-To: <20140921195943.GK2210@kib.kiev.ua> References: <20140921195943.GK2210@kib.kiev.ua> Date: Sun, 21 Sep 2014 16:19:38 -0400 Message-ID: Subject: Re: stack size rlimit From: suresh gumpula To: Konstantin Belousov X-Mailman-Approved-At: Sun, 21 Sep 2014 20:28:03 +0000 Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 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 20:19:39 -0000 Thank you ! . So we cannot have the stack size beyond 512M . correct ? % sudo ./test_stack Current limit value is : 8M max limit value is : 512M Changing the limits to infinity... Current limit value now is : 512M max limit value now is : 512M Thanks Suresh On Sun, Sep 21, 2014 at 3:59 PM, Konstantin Belousov wrote: > 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 > > > > 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. > > > > 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. > > > > 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. > > > > % 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 > vnode > > /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 >