Re: [PATCH v3 1/2] include/fcntl.h: Define O_IGNORE_CTTY

2023-06-13 Thread Adhemerval Zanella Netto
On 13/06/23 06:42, Sergey Bugaev wrote: > Hello, > > On Mon, Jun 12, 2023 at 9:56 PM Adhemerval Zanella Netto > wrote: >>> Do you think the Linux port should define O_IGNORE_CTTY to O_NOCTTY >>> and not to 0? >> >> Hurd O_IGNORE_CTTY and Linux O

Re: [PATCH v3 1/2] include/fcntl.h: Define O_IGNORE_CTTY

2023-06-12 Thread Adhemerval Zanella Netto
On 09/06/23 06:29, Sergey Bugaev wrote: > Hello, > > On Mon, Jun 5, 2023 at 9:25 PM Adhemerval Zanella Netto > wrote: >> We currently are trying to avoid the >> "#ifdef ...", so a code that does not define, where is should, would fail >> at compile

Re: [PATCH v3 1/2] include/fcntl.h: Define O_IGNORE_CTTY

2023-06-05 Thread Adhemerval Zanella Netto
On 04/06/23 17:42, Sergey Bugaev via Libc-alpha wrote: > This internal definition makes it possible to use O_IGNORE_CTTY in > the glibc codebase unconditionally, no matter whether the current port > provides it or not (i.e. both on Hurd and on Linux). Along with the > definition, this adds a

Re: [RFC PATCH 1/2] elf: Port ldconfig away from stack-allocated paths

2023-05-23 Thread Adhemerval Zanella Netto
On 20/05/23 16:03, Sergey Bugaev wrote: > Hello, > > On Fri, May 19, 2023 at 3:25 PM Florian Weimer wrote: >> Missing error checking? > > Indeed, thanks. Fixed. > >> I think we use x* functions such a xstrdup elsewhere in ldconfig, so you >> could add xasprintf as well. > > Apparently the

Re: [RFC PATCH 1/2] elf: Port ldconfig away from stack-allocated paths

2023-05-18 Thread Adhemerval Zanella Netto
On 17/05/23 15:54, Sergey Bugaev via Libc-alpha wrote: > ldconfig was allocating PATH_MAX bytes on the stack for the library file > name. The issues with PATH_MAX usage are well documented [0][1]; even if > a program does not rely on paths being limited to PATH_MAX bytes, > allocating 4096

Re: [PATCH 1/4] hurd: Fix aligning signal stack pointer

2023-05-15 Thread Adhemerval Zanella Netto
On 15/05/23 13:27, Samuel Thibault via Libc-alpha wrote: > Applied, thanks! > > Sergey Bugaev via Libc-alpha, le lun. 15 mai 2023 11:33:20 +0300, a ecrit: >> Fixes 60f9bf974694d50daf58d46347b06a5975ac5ddd >> "hurd: Port trampoline.c to x86_64" >> >> Checked on x86_64-gnu. >> >> Reported-by:

Re: [VERY RFC PATCH 2/2] hurd: Make it possible to call memcpy very early

2023-04-21 Thread Adhemerval Zanella Netto
On 21/04/23 10:56, Sergey Bugaev wrote: > On Fri, Apr 21, 2023 at 3:58 PM Adhemerval Zanella Netto > wrote: >>> Yes, sure, I wasn't really suggesting we do that change. My point is, >>> I would like to make the same memcpy callsites both work during early >>> s

Re: [VERY RFC PATCH 2/2] hurd: Make it possible to call memcpy very early

2023-04-21 Thread Adhemerval Zanella Netto
On 21/04/23 09:38, Sergey Bugaev wrote: > On Fri, Apr 21, 2023 at 2:50 PM Adhemerval Zanella Netto > wrote: >> It might work if you don't care about a different architecture than x86, >> and that's why I added the alias (so each architecture is free to name &g

Re: [RFC PATCH v2 3/7] Use O_CLOEXEC in more places (BZ #15722)

2023-04-21 Thread Adhemerval Zanella Netto
On 19/04/23 13:02, Sergey Bugaev wrote: > When opening a temporary file without O_CLOEXEC we risk leaking the > file descriptor if another thread calls (fork and then) exec while we > have the fd open. Fix this by consistently passing O_CLOEXEC everywhere > where we open a file for internal use

Re: [RFC PATCH v2 2/7] misc: Ignore SIGHUP in daemon () while forking

2023-04-21 Thread Adhemerval Zanella Netto
On 19/04/23 13:02, Sergey Bugaev wrote: > Under certain conditions, SIGHUP will be sent to the child process when > the parent process (the one calling daemon ()) terminates -- namely, if > the parent process was the session leader and the child process was in > the same session (which will be

Re: [RFC PATCH v2 1/7] misc: Convert daemon () to GNU coding style

2023-04-21 Thread Adhemerval Zanella Netto
On 19/04/23 13:02, Sergey Bugaev wrote: > This is nicer, and is going to be required for the following changes > to reasonably stay within the 79 column limit. > > No functional change. > > Signed-off-by: Sergey Bugaev LGTM, thanks. I can be installed independently. Reviewed-by:

Re: [VERY RFC PATCH 2/2] hurd: Make it possible to call memcpy very early

2023-04-21 Thread Adhemerval Zanella Netto
On 21/04/23 06:27, Sergey Bugaev wrote: > Hello, > > On Thu, Apr 20, 2023 at 11:38 PM Adhemerval Zanella Netto > wrote: >> Can't you use a similar strategy done by >> 5355f9ca7b10183ce06e8a18003ba30f43774858 ? > > Do I understand it right that that is the mo

Re: [VERY RFC PATCH 2/2] hurd: Make it possible to call memcpy very early

2023-04-20 Thread Adhemerval Zanella Netto
On 20/04/23 17:25, H.J. Lu via Libc-alpha wrote: > On Thu, Apr 20, 2023 at 11:43 AM Sergey Bugaev wrote: >> >> Normally, in static builds, the first code that runs is _start, in e.g. >> sysdeps/x86_64/start.S, which quickly calls __libc_start_main, passing >> it the argv etc. Among the first

Re: [RFC PATCH v2 4/7] csu: Fix standard fds' mode

2023-04-20 Thread Adhemerval Zanella Netto
On 20/04/23 09:06, Cristian Rodríguez wrote: > > > On Thu, Apr 20, 2023 at 7:47 AM Adhemerval Zanella Netto > mailto:adhemerval.zane...@linaro.org>> wrote: > > > > > I am not really sure how effective is this hardening, it seems more a > de

Re: [RFC PATCH v2 4/7] csu: Fix standard fds' mode

2023-04-20 Thread Adhemerval Zanella Netto
On 19/04/23 18:16, Sergey Bugaev wrote: > On Wed, Apr 19, 2023 at 11:45 PM Adhemerval Zanella Netto >>>> is this really needed now? playing silly games with this fds will always >>>> result in silly prices. >> >> My understanding of this code is to enfor

Re: [RFC PATCH v2 4/7] csu: Fix standard fds' mode

2023-04-19 Thread Adhemerval Zanella Netto
On 19/04/23 16:40, Sergey Bugaev wrote: > On Wed, Apr 19, 2023, 22:13 Cristian Rodríguez > wrote: >> Im a little bit lost on what it was supposed to do in this old form.. as >> the open flags are all wrong.. >> >> Changelog says: >> >> (__libc_check_standard_fds): Reverse modes so that

Re: [RFC PATCH 1/5] misc: Convert daemon () to GNU coding style

2023-04-18 Thread Adhemerval Zanella Netto
On 18/04/23 10:48, Cristian Rodríguez wrote: > > > On Tue, Apr 18, 2023 at 8:02 AM Adhemerval Zanella Netto via Libc-alpha > mailto:libc-al...@sourceware.org>> wrote: > > > > On 17/04/23 19:58, Sergey Bugaev via Libc-alpha wrote: > > This i

Re: [RFC PATCH 4/4] socket: Add a test for MSG_CMSG_CLOEXEC

2023-04-18 Thread Adhemerval Zanella Netto
On 18/04/23 12:37, Sergey Bugaev wrote: > Hello, > > On Tue, Apr 18, 2023 at 3:13 PM Adhemerval Zanella Netto wrote: >> On 17/04/23 10:39, Sergey Bugaev via Libc-alpha wrote: >>> Signed-off-by: Sergey Bugaev >> >> Add some description of what the test is

Re: [RFC PATCH 4/4] socket: Add a test for MSG_CMSG_CLOEXEC

2023-04-18 Thread Adhemerval Zanella Netto
On 17/04/23 10:39, Sergey Bugaev via Libc-alpha wrote: > Signed-off-by: Sergey Bugaev Add some description of what the test is accomplishing here. Some small nits below, the patch LGTM. > --- > > This is an attempt to write a test, roughly based on > sysdeps/unix/sysv/linux/tst-scm_rights.c

Re: [RFC PATCH 2/5] Use O_CLOEXEC in more places

2023-04-18 Thread Adhemerval Zanella Netto
On 17/04/23 19:58, Sergey Bugaev via Libc-alpha wrote: > When opening a temporary file without O_CLOEXEC we risk leaking the > file descriptor if another thread calls (fork and then) exec while we > have the fd open. Fix this by consistently passing O_CLOEXEC everywhere > where we open a file

Re: [RFC PATCH 1/5] misc: Convert daemon () to GNU coding style

2023-04-18 Thread Adhemerval Zanella Netto
On 17/04/23 19:58, Sergey Bugaev via Libc-alpha wrote: > This is nicer, and is going to be required for the following changes > to reasonably stay within the 79 column limit. > > No functional change. > > Signed-off-by: Sergey Bugaev LGTM, some minor nits below. > --- > misc/daemon.c | 88