Re: [PATCH v3 2/2] aarch64: Use mmap to add PROT_BTI instead of mprotect [BZ #26831]

2020-12-10 Thread Adhemerval Zanella
ainly needed because currently > _dl_process_gnu_properties does not propagate failures such that > the required cleanups happen. Using the link_map_machine struct for > error propagation is not ideal, but this seemed to be the least > intrusive solution. > > Fixes bug 26831. LGTM, thanks. Reviewed

Re: [PATCH v3 1/2] aarch64: align address for BTI protection [BZ #26988]

2020-12-10 Thread Adhemerval Zanella
> Fixes bug 26988. LGTM, thanks. Reviewed-by: Adhemerval Zanella > --- > v3: > - split the last patch in two so this bug is fixed separately. > - pushed to nsz/btifix-v3 branch. > > sysdeps/aarch64/dl-bti.c | 14 -- > 1 file changed, 8 insertions(+), 6 deletio

Re: [PATCH v2 5/6] elf: Pass the fd to note processing

2020-12-10 Thread Adhemerval Zanella
fd is passed to both _dl_process_pt_gnu_property and > _dl_process_pt_note for consistency. Target specific note > processing functions are updated accordingly. LGTM, thanks. Reviewed-by: Adhemerval Zanella > --- > elf/dl-load.c | 12 +++- > elf/rtld.c

Re: [PATCH v2 3/6] elf: Fix failure handling in _dl_map_object_from_fd

2020-12-10 Thread Adhemerval Zanella
On 27/11/2020 10:20, Szabolcs Nagy via Libc-alpha wrote: > There are many failure paths that call lose to do local cleanups > in _dl_map_object_from_fd, but it did not clean everything. > > Handle l_phdr, l_libname and mapped segments in the common failure > handling code. > > There are

Re: [PATCH v2 1/6] aarch64: Fix missing BTI protection from dependencies [BZ #26926]

2020-12-10 Thread Adhemerval Zanella
On 27/11/2020 10:19, Szabolcs Nagy via Libc-alpha wrote: > The _dl_open_check and _rtld_main_check hooks are not called on the > dependencies of a loaded module, so BTI protection was missed on > every module other than the main executable and directly dlopened > libraries. > > The fix just

Re: clock_gettime64 vdso bug on 32-bit arm, rpi-4

2020-05-19 Thread Adhemerval Zanella
On 19/05/2020 16:54, Arnd Bergmann wrote: > Jack Schmidt reported a bug for the arm32 clock_gettimeofday64 vdso call last > month: https://github.com/richfelker/musl-cross-make/issues/96 and > https://github.com/raspberrypi/linux/issues/3579 > > As Will Deacon pointed out, this was never

Re: d_off field in struct dirent and 32-on-64 emulation

2019-01-02 Thread Adhemerval Zanella
On 31/12/2018 15:03, Joseph Myers wrote: > On Fri, 28 Dec 2018, Adhemerval Zanella wrote: > >>>> Currently we only have nios2 and csky (unfortunately). But since generic >>>> definition for off_t and off64_t still assumes non-LFS support, all new >>>

Re: d_off field in struct dirent and 32-on-64 emulation

2018-12-28 Thread Adhemerval Zanella
On 28/12/2018 10:01, Florian Weimer wrote: > * Florian Weimer: > >> * Adhemerval Zanella: >> >>> On 27/12/2018 16:09, Florian Weimer wrote: >>>> * Adhemerval Zanella: >>>> >>>>> Also for glibc standpoint, although reverting

Re: d_off field in struct dirent and 32-on-64 emulation

2018-12-28 Thread Adhemerval Zanella
On 27/12/2018 16:09, Florian Weimer wrote: > * Adhemerval Zanella: > >> Also for glibc standpoint, although reverting it back to use getdents >> syscall for non-LFS mode might fix this issue for architectures that >> provides non-LFS getdents syscall it won't be

Re: d_off field in struct dirent and 32-on-64 emulation

2018-12-27 Thread Adhemerval Zanella
On 27/12/2018 15:18, Florian Weimer wrote: > We have a bit of an interesting problem with respect to the d_off > field in struct dirent. > > When running a 64-bit kernel on certain file systems, notably ext4, > this field uses the full 63 bits even for small directories (strace -v > output,

Re: [PATCH 23/23] [AARCH64] Take utmp{,x}.h from s390 port

2016-06-28 Thread Adhemerval Zanella
On 28/06/2016 14:59, Yury Norov wrote: > On Tue, Jun 28, 2016 at 05:18:04PM +, Joseph Myers wrote: >> On Tue, 28 Jun 2016, Yury Norov wrote: >> >>> aarch64 and ilp32 has different size of time_t. So to have common >>> layout for struct utmp and utmpx, corresponding headers are taken >>> from

Re: [PATCH 23/23] [AARCH64] Take utmp{,x}.h from s390 port

2016-06-28 Thread Adhemerval Zanella
On 28/06/2016 14:59, Yury Norov wrote: > On Tue, Jun 28, 2016 at 05:18:04PM +, Joseph Myers wrote: >> On Tue, 28 Jun 2016, Yury Norov wrote: >> >>> aarch64 and ilp32 has different size of time_t. So to have common >>> layout for struct utmp and utmpx, corresponding headers are taken >>> from

Re: [PATCH 18/23] [AARCH64] ILP32: support stat syscall family

2016-06-28 Thread Adhemerval Zanella
On 28/06/2016 16:08, Yury Norov wrote: > On Tue, Jun 28, 2016 at 05:15:13PM +, Joseph Myers wrote: >> still >> applies. Unify implementations instead of proliferating variants. > > I think on it. I don't see simple way to unify

Re: [PATCH 18/23] [AARCH64] ILP32: support stat syscall family

2016-06-28 Thread Adhemerval Zanella
On 28/06/2016 16:08, Yury Norov wrote: > On Tue, Jun 28, 2016 at 05:15:13PM +, Joseph Myers wrote: >> still >> applies. Unify implementations instead of proliferating variants. > > I think on it. I don't see simple way to unify

Re: [RFC2 PATCH 00/23] ARM64: support ILP32

2016-06-28 Thread Adhemerval Zanella
Hi Yury, Please address all previous reviews comment and concerns before send a new RFC/patch set. As Joseph pointed out, he raised different question in different patch iterations (some even back from 2014) and there is no point is just resent the same patch without first review such comments.

Re: [RFC2 PATCH 00/23] ARM64: support ILP32

2016-06-28 Thread Adhemerval Zanella
Hi Yury, Please address all previous reviews comment and concerns before send a new RFC/patch set. As Joseph pointed out, he raised different question in different patch iterations (some even back from 2014) and there is no point is just resent the same patch without first review such comments.