Le 09/10/2022 à 08:08, WANG Xuerui a écrit :
User space has been preferring this syscall for a while, due to its
closer match with C semantics, and newer platforms such as LoongArch
apparently have libc implementations that don't fallback to faccessat
so normal access checks are failing without
On 18/10/22 11:58, Michael Tokarev wrote:
10.10.2022 11:53, Helge Deller wrote:
On 10/9/22 08:08, WANG Xuerui wrote:
User space has been preferring this syscall for a while, due to its
closer match with C semantics, and newer platforms such as LoongArch
apparently have libc implementations
10.10.2022 11:53, Helge Deller wrote:
On 10/9/22 08:08, WANG Xuerui wrote:
User space has been preferring this syscall for a while, due to its
closer match with C semantics, and newer platforms such as LoongArch
apparently have libc implementations that don't fallback to faccessat
so normal
On 10/9/22 08:08, WANG Xuerui wrote:
User space has been preferring this syscall for a while, due to its
closer match with C semantics, and newer platforms such as LoongArch
apparently have libc implementations that don't fallback to faccessat
so normal access checks are failing without the
User space has been preferring this syscall for a while, due to its
closer match with C semantics, and newer platforms such as LoongArch
apparently have libc implementations that don't fallback to faccessat
so normal access checks are failing without the emulation in place.
Tested by successfully
On 7/29/22 13:14, Richard Henderson wrote:
-ret = get_errno(access(path(p), arg2));
-unlock_user(p, arg1, 0);
-return ret;
+return do_faccessat2(AT_FDCWD, arg1, arg2, 0);
Oops, dropped path().
Should perhaps be incorporated into the helper, because newer
Split out do_faccessat2 helper, and use it for
accessat and faccessat as well.
Signed-off-by: Richard Henderson
---
Will we ever have a system libc for which __NR_faccessat2 is present,
but faccessat() does not try faccessat2 first?
r~
---
linux-user/syscall.c | 44
