[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID:
<SY8P300MB086017654F4E1BD883AA1A35FCD42@SY8P300MB0860.AUSP300.PROD.OUTLOOK.COM>
Date: Sat, 8 Mar 2025 19:12:13 +0000
From: Mouri Kenji <Mouri_Naruto@...look.com>
To: Rich Felker <dalias@...c.org>
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
Hi Rich,
First, thanks for your reply.
I'm curious about why we need to call mremap with size expansion in musl's pthread_getattr_np implementation. It seems get the current stack size for the specific thread. I want to know more details for helping me think how to workaround that. Thanks.
Kenji Mouri (https://github.com/MouriNaruto)
-----Original Message-----
From: Rich Felker <dalias@...c.org>
Sent: Sunday, March 9, 2025 2:09 AM
To: Mouri Kenji <Mouri_Naruto@...look.com>
Cc: 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: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.
