[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20171014025940.GN1627@brightrain.aerifal.cx>
Date: Fri, 13 Oct 2017 22:59:40 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: open issues
On Wed, Sep 06, 2017 at 10:32:01PM -0400, Rich Felker wrote:
> Updated status:
>
> Pending decision(s) of what do to:
>
> - fix nftw when called with paths ending in slash
> http://www.openwall.com/lists/musl/2017/03/07/1
Planning to just commit my minimal fix for now since further changes
are still incomplete/pending discussion.
> - use-after-free in __unlock of pthread struct
> http://www.openwall.com/lists/musl/2017/06/01/7
I really want to adopt the new lock but the release is way past due
without having thoroughly reviewed and tested. I have a trivial patch
to just make pthread_detach always call __wake rather than using the
waiters count which fixes the bug for now. We can switch back to lock
primitives once the new lock is in use.
> - missed underflow in fma
> http://www.openwall.com/lists/musl/2017/03/19/6
> new fma, depends on a_clz_64
> http://www.openwall.com/lists/musl/2017/04/23/10
> [new patch on top of old one submitted, still not ideal
> but no volatile]
Applying nsz's latest patch that fixed the volatile hacks.
> Pending updated patch:
>
> - make dlsym and reloc time lookup consistent
> http://www.openwall.com/lists/musl/2017/02/16/1
Punting to next release cycle.
> Pending analysis of cause:
>
> - mips64 utime issue?
> "tar binary can't fix the modification/access times on any extracted symbolic links,"
> http://www.openwall.com/lists/musl/2017/07/06/1
Punting to next release cycle.
> Additional issue that was left out that I promised for a long time to
> review; pending tests to ensure it doesn't break anything in the
> standard functionality it touches:
>
> - strftime extensions
> http://www.openwall.com/lists/musl/2016/11/22/1
I'm still waiting for tests to show that this doesn't introduce
regressions, so won't be including the patch.
But for the purpose of Alpine or any other distros that want to patch
it themselves without introducing incompatibility, please consider it
"accepted" in that the interface (the extensions) will make it
upstream; it's just the implementation that still needs checking (and
may need changes if there are problems).
I think this mostly concludes what's pending for release.
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.
