| Message ID | 659f5e52d04c2293d020eda2827212186dfbf92d.1701944612.git.fweimer@redhat.com |
|---|---|
| State | New |
| Headers | show |
| Series | RELRO linkmaps | expand |
On Thu, 7 Dec 2023, Florian Weimer wrote:
> It is currently not used by any target.
OK.
* Joseph Myers: > On Thu, 7 Dec 2023, Florian Weimer wrote: > >> It is currently not used by any target. > > OK. Thank you for your reviews. Is it fine with you if I add “Reviewed-By: Joseph Myers <josmyers@redhat.com>” tags for those patches that you OKed to a repost of the series? Florian
On Mon, 11 Mar 2024, Florian Weimer wrote: > * Joseph Myers: > > > On Thu, 7 Dec 2023, Florian Weimer wrote: > > > >> It is currently not used by any target. > > > > OK. > > Thank you for your reviews. Is it fine with you if I add “Reviewed-By: > Joseph Myers <josmyers@redhat.com>” tags for those patches that you > OKed to a repost of the series? Yes. It's probably helpful also to clearly mark the ones that need a fresh review (the ones that I commented on but didn't give a specific "OK" or "OK subject to these changes" to). Of course anything that was approved (with or without changes) and makes sense without any unapproved patches can just be committed (subject to any required retesting), so the next revision of the series may have fewer patches.
* Joseph Myers: > On Mon, 11 Mar 2024, Florian Weimer wrote: > >> * Joseph Myers: >> >> > On Thu, 7 Dec 2023, Florian Weimer wrote: >> > >> >> It is currently not used by any target. >> > >> > OK. >> >> Thank you for your reviews. Is it fine with you if I add “Reviewed-By: >> Joseph Myers <josmyers@redhat.com>” tags for those patches that you >> OKed to a repost of the series? > > Yes. > > It's probably helpful also to clearly mark the ones that need a fresh > review (the ones that I commented on but didn't give a specific "OK" or > "OK subject to these changes" to). I thought that the other category was just the rest? If there is a third category, maybe that's easier to mark for me? Thanks, Florian
On Mon, 11 Mar 2024, Florian Weimer wrote: > > It's probably helpful also to clearly mark the ones that need a fresh > > review (the ones that I commented on but didn't give a specific "OK" or > > "OK subject to these changes" to). > > I thought that the other category was just the rest? If there is a > third category, maybe that's easier to mark for me? I think there are just two categories: (a) approved (possibly subject to changes) and (b) others (all of which should have either questions or requested changes). But I also think it's useful to be explicit for each patch which category it's in (rather than just marking (a) with Reviewed-By and having (b) implied by the absence of Reviewed-By).
* Joseph Myers: > On Mon, 11 Mar 2024, Florian Weimer wrote: > >> > It's probably helpful also to clearly mark the ones that need a fresh >> > review (the ones that I commented on but didn't give a specific "OK" or >> > "OK subject to these changes" to). >> >> I thought that the other category was just the rest? If there is a >> third category, maybe that's easier to mark for me? > > I think there are just two categories: (a) approved (possibly subject to > changes) and (b) others (all of which should have either questions or > requested changes). But I also think it's useful to be explicit for each > patch which category it's in (rather than just marking (a) with > Reviewed-By and having (b) implied by the absence of Reviewed-By). Thanks for the clarification. I'm just worried that the markers for (b) end up in the official commit history, which really wouldn't be ideal. Is there anything we can add to the commit subject that is already recognized by the server-side hooks? Florian
diff --git a/elf/dl-load.c b/elf/dl-load.c index 25ea4f7a4e..692c9a47ad 100644 --- a/elf/dl-load.c +++ b/elf/dl-load.c @@ -72,7 +72,6 @@ struct filebuf #include <dl-map-segments.h> #include <dl-unmap-segments.h> #include <dl-machine-reject-phdr.h> -#include <dl-sysdep-open.h> #include <dl-prop.h> #include <not-cancel.h> @@ -2091,20 +2090,6 @@ _dl_map_object (struct link_map *loader, const char *name, &loader->l_runpath_dirs, &realname, &fb, loader, LA_SER_RUNPATH, &found_other_class); - if (fd == -1) - { - realname = _dl_sysdep_open_object (name, namelen, &fd); - if (realname != NULL) - { - fd = open_verify (realname, fd, - &fb, loader ?: GL(dl_ns)[nsid]._ns_loaded, - LA_SER_CONFIG, mode, &found_other_class, - false); - if (fd == -1) - free (realname); - } - } - #ifdef USE_LDCONFIG if (fd == -1 && (__glibc_likely ((mode & __RTLD_SECURE) == 0) diff --git a/elf/dl-sysdep-open.h b/elf/dl-sysdep-open.h deleted file mode 100644 index 185d6c72ab..0000000000 --- a/elf/dl-sysdep-open.h +++ /dev/null @@ -1,45 +0,0 @@ -/* System-specific call to open a shared object by name. Stub version. - Copyright (C) 2015-2023 Free Software Foundation, Inc. - This file is part of the GNU C Library. - - The GNU C Library is free software; you can redistribute it and/or - modify it under the terms of the GNU Lesser General Public - License as published by the Free Software Foundation; either - version 2.1 of the License, or (at your option) any later version. - - The GNU C Library is distributed in the hope that it will be useful, - but WITHOUT ANY WARRANTY; without even the implied warranty of - MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU - Lesser General Public License for more details. - - You should have received a copy of the GNU Lesser General Public - License along with the GNU C Library; if not, see - <https://www.gnu.org/licenses/>. */ - -#ifndef _DL_SYSDEP_OPEN_H -#define _DL_SYSDEP_OPEN_H 1 - -#include <assert.h> -#include <stddef.h> - -/* NAME is a name without slashes, as it appears in a DT_NEEDED entry - or a dlopen call's argument or suchlike. NAMELEN is (strlen (NAME) + 1). - - Find NAME in an OS-dependent fashion, and return its "real" name. - Optionally fill in *FD with a file descriptor open on that file (or - else leave its initial value of -1). The return value is a new - malloc'd string, which will be free'd by the caller. If NAME is - resolved to an actual file that can be opened, then the return - value should name that file (and if *FD was not set, then a normal - __open call on that string will be made). If *FD was set by some - other means than a normal open and there is no "real" name to use, - then __strdup (NAME) is fine (modulo error checking). */ - -static inline char * -_dl_sysdep_open_object (const char *name, size_t namelen, int *fd) -{ - assert (*fd == -1); - return NULL; -} - -#endif /* dl-sysdep-open.h */