[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20201031153557.0b7c2bf6@vostro.wlan>
Date: Sat, 31 Oct 2020 15:35:57 +0200
From: Timo Teras <timo.teras@....fi>
To: Szabolcs Nagy <nsz@...t70.net>
Cc: Ariadne Conill <ariadne@...eferenced.org>, musl@...ts.openwall.com,
"Milan P. Stanić" <mps@...anta.net>, Rich Felker
<dalias@...c.org>
Subject: Re: [PATCH v2] MT fork
On Sat, 31 Oct 2020 14:29:32 +0100
Szabolcs Nagy <nsz@...t70.net> wrote:
> * Timo Teras <timo.teras@....fi> [2020-10-31 09:22:04 +0200]:
>
> > On Fri, 30 Oct 2020 15:31:54 -0600
> > Ariadne Conill <ariadne@...eferenced.org> wrote:
> >
> > > I have pushed current musl git plus the MT fork patch to Alpine
> > > edge as Alpine musl 1.2.2_pre0, and reenabling parallel mark has
> > > worked fine.
> > >
> > > It would be nice to have a musl 1.2.2 release that I can use for
> > > the source tarball instead of a git snapshot, but this will do
> > > for now.
> >
> > And now firefox is utterly broken. Though seems to be not related
> > to MT fork patch.
> >
> > Bisected it down to commit b8b729bd22c28c9116c2fce65dce207a35299c26
> > "fix missing O_LARGEFILE values on x86_64, x32, and mips64"
> >
> > I think this breaks the seccomp because now e.g. fopen() calls has
> > this bit set for the syscall and seccomp does not like it.
> >
> > Wondering whether to fix firefox seccomp ignore this bit, or if this
> > commit needs reconsideration?
>
> please report it to firefox while we work out what's best.
>
> this is something they sould be aware of.
Turns out the rebuilding firefox was enough. They allow O_LARGEFILE
there, but when built with earlier musl version it was zero...
So basically the change there requires rebuild of certain applications.
Even if from kernel side the bit makes no big difference, but from
seccomp side it does.
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.
