[LEDE-DEV] [PATCH 4/4] toolchain: musl: update to current HEAD

[Christian Lamparter]

On Tuesday, November 21, 2017 9:56:12 AM CET Koen Vandeputte wrote:
> > This is all documented on the musl ML.
> >
> > musl 1.1.17 was rushed due to this CVE:
> > <http://www.cvedetails.com/cve/CVE-2017-15650/>
> >
> > However, the 1.1.17 release had accumulated like 11 months of patches since
> > the previous 1.1.16 release. There have been several regressions that went
> > unnoticed. But this only really came to light after 1.1.17 was already
> > released. Because the different projects and people actually started to test
> > it now.
> >
> > In fact, Syrone Wong actually discovered the regression earlier.
> > <http://lists.infradead.org/pipermail/lede-dev/2017-October/009237.html>
> > (Koen issued an patch to update to the latest 1.1.16 git head and part of
> > the later discussion was also CC'd to the musl ML.)
> > But this wasn't fixed in time for 1.1.17.
> >
> > However, this regression and two other problems then let to the 1.1.18 release
> > shortly thereafter. <https://marc.info/?l=musl&m=150860332132027&w=2>
> Yes,
> 
> Main reason in that specific case was mainly for these 2 fixes:
> 
> /9e01be6 fix signal masking race in pthread_create with priority (I use 
> lots of threading & thread priority in my app) //51bdcdc fix OOB reads in Xbyte_memmem (used by memmem() ) /
>
Hm? Are you now talking about something else? I remember seeing these
commits listed in your musl update to 1.1.16+. 
<http://lists.infradead.org/pipermail/lede-dev/2017-October/009234.html>

But Felix did the update musl to 1.1.18 on the 5th (I noticed that he had
a patch queued). This update included the changes you listed, right?

> fwiw, my 2 cents:
>
> I try to carefully judge whether there's a good reason to bump head or 
> not, and I mostly wait for min 48 hrs to let the latest commits soak a bit.
"waiting" around doesn't help in regression cases. I think this
glob-regression is another case in point. The issue was discovered
more than a week before 1.1.17 was released:
<https://www.mail-archive.com/lede-dev@lists.infradead.org/msg09180.html>
and when I posted the request to move to 1.1.17 (again).
But it only received the attention, once people started testing the new 
1.1.17 and did bisections.

> One could argue for backporting only importing changes (which I've done
> in the past), [1]
> but it was argued that it's better sometimes to just bump the git head
> instead
> as it can take months before a new release is done containing critical
> fixes, which is the reason for the switch to git download [2]
> 
> Maybe a balanced solution would be to wait for 1 .. 2  tested-by's 
> before pushing these to master?
Great that you bring this up. So, did you test >this patch< already too?
And if so, what's your verdict? Does it perform as expected on your cns3xxx?
Can you please post a "tested-by" tag then?

As for pushing to master: From most past experience, a patch usually sits
in the patchwork queue for some time (a few days to months). Then one of
the commiter adds it to his/her public staging tree and if all went well, 
the patch moves to master eventually.
 
Regards,
Christian