Date: Sat, 13 Feb 2021 17:16:47 +0000 From: bugzilla-noreply@freebsd.org To: emulation@FreeBSD.org Subject: [Bug 253337] Linuxulator: glibc's pthread_getattr_np reports stack size as 124K Message-ID: <bug-253337-4077-jDgTCCGQbJ@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-253337-4077@https.bugs.freebsd.org/bugzilla/> References: <bug-253337-4077@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D253337 --- Comment #7 from Conrad Meyer <cem@freebsd.org> --- In exec, we map the stack with vm_map_stack() with rlim_cur (I think); in vm_map_stack, we set the init_ssize with MIN(sysctl kern.sgrowsiz, rlim_cur= ).=20=20 kern.sgrowsiz is 128kB. There's a comment about the behavior in vm/vm_map.c:4565. At line 4585 we insert the normal stack mapping. At line 4599 we insert the reservation for the unallocated portion of the stack with no access (---). We won't insert the --- mapping if gap_bot =3D=3D gap_top, which I think on= ly happens if kern.sgrowsiz happens to match the stack rlimit.rl_cur. So... a crappy workaround here might be to set kern.sgrowsiz to 8MB.=20 Obviously, that's system-wide, and doesn't chase rlim_cur. I'm not sure of= the ramifications. I don't think this actually faults in backing physical memo= ry pages, and both RW- and no-prot (---) pages consume the same amount of virt= ual memory. So it might be pretty harmless. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-253337-4077-jDgTCCGQbJ>