Re: [LEDE-DEV] [PATCH 1/2] musl: update to 1.1.16+ git HEAD 2017-09-28

Re: [LEDE-DEV] [PATCH 1/2] musl: update to 1.1.16+ git HEAD 2017-09-28

[Szabolcs Nagy]

* Koen Vandeputte <koen.vandeputte@ncentric.com> [2017-10-16 10:31:11 +0200]:
> I've proposed to update the musl libc within the LEDE project and received
> some feedback from Syrone Wong (in cc).
> 
> According to him, your upstream commit in musl [1] seems to break something.
> (see below)
> 
> - Can you confirm this?
> - Would you have any clue what the reason could be?
...
> [1]
> "powerpc{64}: fix MAP_NORESERVE and MAP_LOCKED in mman.h"
> http://git.musl-libc.org/cgit/musl/commit/?id=c10bc61508dc52b8315084e628f36a6c3c2dabb1
> 

these are rarely used mmap flags, i think my patch is correct.

the old value in musl was wrong on powerpc (i think the old
value did not collide with other map flags so the kernel would
report EINVAL if these flags were ever used).

> On 2017-10-09 12:01, Syrone Wong wrote:
> > Based on my previous test on mvebu/WRT3200ACM, when I update to
> > 
> > c10bc61 powerpc{64}: fix MAP_NORESERVE and MAP_LOCKED in mman.h
> > 
> > hostapd and pppd won't start, if you start pppd manually, it will
> > output garbage.
...
> > On Mon, Oct 9, 2017 at 5:21 PM, Koen Vandeputte
> > <koen.vandeputte@ncentric.com> wrote:
> > > 48be5b6 fix use of memset without declaration in sched.h cpu set macros
> > > c10bc61 powerpc{64}: fix MAP_NORESERVE and MAP_LOCKED in mman.h
> > > da438ee work around incorrect EPERM from mmap syscall

note that this EPERM workaround also affects mmap behaviour

but i don't immediately see why either patches would cause problem

> > > 8c4be3e fix glob descent into . and .. with GLOB_PERIOD
> > > 565dbee don't treat numeric port strings as servent records in
> > > getservby*()
> > > 9e01be6 fix signal masking race in pthread_create with priority
> > > attributes
> > > 822dddf make syscall.h consistent with linux
> > > 9255dad handle whitespace before %% in scanf
> > > 51bdcdc fix OOB reads in Xbyte_memmem
> > > cc0dbd5 free allocations in clearenv
> > > 8e93279 overhaul environment functions
> > > 39db00a fix erroneous acceptance of f4 9x xx xx code sequences by utf-8
> > > decoder
> > > 11ddc31 fix erroneous stop before input limit in mbsnrtowcs and
> > > wcsnrtombs
> > > 8459c6f arm: add HWCAP_ARM_ hwcap macros
> > > 06fbefd add a_clz_64 helper function
> > > 3356177 s390x: add bits/hwcap.h
> > > 
> > > Tested on cns3xxx
> > > 
> > > Signed-off-by: Koen Vandeputte <koen.vandeputte@ncentric.com>
> > > ---
> > >   toolchain/musl/common.mk | 4 ++--
> > >   1 file changed, 2 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/toolchain/musl/common.mk b/toolchain/musl/common.mk
> > > index 0a45828..966ff98 100644
> > > --- a/toolchain/musl/common.mk
> > > +++ b/toolchain/musl/common.mk
> > > @@ -13,8 +13,8 @@ PKG_RELEASE=1
> > > 
> > >   PKG_SOURCE_PROTO:=git
> > >   PKG_SOURCE_SUBDIR:=$(PKG_NAME)-$(PKG_VERSION)
> > > -PKG_SOURCE_VERSION:=5f7efb87a28a311ad377dd26adf53715dedb096d
> > > -PKG_MIRROR_HASH:=da18ef24f270e5cae6bc4c440479da17bec1949ae5a1bc990352ca04f24c4378
> > > +PKG_SOURCE_VERSION:=48be5b6313d7b827acf555769e93b389fa9f6307
> > > +PKG_MIRROR_HASH:=c3766c0613d20491c4662e1f2914c50f5a69ec07d8e5cf8930afc5041226e5b8
> > >   PKG_SOURCE_URL:=git://git.musl-libc.org/musl
> > >   PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION)-$(PKG_SOURCE_VERSION).tar.xz
> > > 
> > > --
> > > 2.7.4
> > > 
> > > 
> > > _______________________________________________
> > > Lede-dev mailing list
> > > Lede-dev@lists.infradead.org
> > > http://lists.infradead.org/mailman/listinfo/lede-dev
> 
> -- 
> Koen Vandeputte - Software Developer
> koen.vandeputte@ncentric.com | +32499736158

Re: [LEDE-DEV] [PATCH 1/2] musl: update to 1.1.16+ git HEAD 2017-09-28

[Felix Fietkau]

On 2017-10-16 16:03, Szabolcs Nagy wrote:
> * Koen Vandeputte <koen.vandeputte@ncentric.com> [2017-10-16 10:31:11 +0200]:
>> I've proposed to update the musl libc within the LEDE project and received
>> some feedback from Syrone Wong (in cc).
>> 
>> According to him, your upstream commit in musl [1] seems to break something.
>> (see below)
>> 
>> - Can you confirm this?
>> - Would you have any clue what the reason could be?
> ...
>> [1]
>> "powerpc{64}: fix MAP_NORESERVE and MAP_LOCKED in mman.h"
>> http://git.musl-libc.org/cgit/musl/commit/?id=c10bc61508dc52b8315084e628f36a6c3c2dabb1
>> 
> 
> these are rarely used mmap flags, i think my patch is correct.
> 
> the old value in musl was wrong on powerpc (i think the old
> value did not collide with other map flags so the kernel would
> report EINVAL if these flags were ever used).
I don't think this commit is the cause at all. The bug reporter was
using an ARM device and this commit only touches powerpc header files.
Probably the issue is somewhere between the version that LEDE uses now
and the version with this commit id.

- Felix

Re: Re: [LEDE-DEV] [PATCH 1/2] musl: update to 1.1.16+ git HEAD 2017-09-28

[Szabolcs Nagy]

* Felix Fietkau <nbd@nbd.name> [2017-10-16 16:09:16 +0200]:
> On 2017-10-16 16:03, Szabolcs Nagy wrote:
> > * Koen Vandeputte <koen.vandeputte@ncentric.com> [2017-10-16 10:31:11 +0200]:
> >> I've proposed to update the musl libc within the LEDE project and received
> >> some feedback from Syrone Wong (in cc).
> >> 
> >> According to him, your upstream commit in musl [1] seems to break something.
> >> (see below)
> >> 
> >> - Can you confirm this?
> >> - Would you have any clue what the reason could be?
> > ...
> >> [1]
> >> "powerpc{64}: fix MAP_NORESERVE and MAP_LOCKED in mman.h"
> >> http://git.musl-libc.org/cgit/musl/commit/?id=c10bc61508dc52b8315084e628f36a6c3c2dabb1
> >> 
> > 
> > these are rarely used mmap flags, i think my patch is correct.
> > 
> > the old value in musl was wrong on powerpc (i think the old
> > value did not collide with other map flags so the kernel would
> > report EINVAL if these flags were ever used).
> I don't think this commit is the cause at all. The bug reporter was
> using an ARM device and this commit only touches powerpc header files.
> Probably the issue is somewhere between the version that LEDE uses now
> and the version with this commit id.
> 

some more details would be useful, e.g. strace
output of the failing processes.

or libc.so before and after (mmap code in my libc.so
looks ok, but there might be some toolchain issue).

does the system use >4k page size?