[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250308180829.GZ1827@brightrain.aerifal.cx>
Date: Sat, 8 Mar 2025 13:08:30 -0500
From: Rich Felker <dalias@...c.org>
To: Mouri Kenji <Mouri_Naruto@...look.com>
Cc: "musl@...ts.openwall.com" <musl@...ts.openwall.com>
Subject: Re: Calling pthread_getattr_np won't return in the mremap
loop when using musl in FreeBSD's Linux compatibility layer
On Sat, Mar 08, 2025 at 02:34:42PM +0000, Mouri Kenji wrote:
> Hi,
>
> I think we can have the hope for that because glibc's
> pthread_getattr_np won't hung in FreeBSD's Linux compatibility
> layer.
That's because glibc's doesn't actually compute the initial thread's
stack size. Instead it just uses the RLIMIT_STACK as a proxy for it.
This gives the completely wrong result if the rlimit has been changed
since execution started or if the rlimit is infinite. Even when it's
"right", it's measuring a maximum possible size it certainly can't
grow beyond, not a size it actually has or necessarily could attain.
Rich
> -----Original Message-----
> From: Yao Zi <ziyao@...root.org>
> Sent: Saturday, March 8, 2025 10:31 PM
> To: musl@...ts.openwall.com
> Subject: Re: [musl] Calling pthread_getattr_np won't return in the mremap loop when using musl in FreeBSD's Linux compatibility layer
>
> On Sat, Mar 08, 2025 at 02:18:04PM +0000, Mouri Kenji wrote:
> > Hello all,
> >
> > When I tried to use musl-based userspace in FreeBSD's Linux
> > compatibility layer, I found some app will hung.
> >
> > I do some debugging with lldb. I have found app hang in mremap loop
> > in the musl's pthread_getattr_np implementation.
> >
> > I read the FreeBSD's Linux compatibility layer source code, it seems
> > mremap in FreeBSD's Linux compatibility layer in won't support expand the size.
> >
> > Here is the source code for FreeBSD's Linux compatibility layer mremap
> > implementation: https://github.com/freebsd/freebsd-src/blob/780a4667bbde0daa90db900bb0f93f6337d6208b/sys/compat/linux/linux_misc.c#L302
> >
> > I only can send a report e-mail to this mail list instead of making a
> > patch because I'm the newbie of Linux's libc internals, and I feel
> > sorry for that.
>
> imho the report and the patch should all go into the FreeBSD's mailing
> list or similar things. Honestly, why should musl workaround for a
> non-officially-supported platform?
If there were an easy fix I'd happily work around it, since support
for FreeBSD's linux compat layer has always been a nice perk and a
good answer to "can I use musl on FreeBSD?"
If there's a way to detect the broken mremap and error out, maybe we
could do that?
But hopefully FreeBSD can fix this.
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
