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 t
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 that
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 acce
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 emula
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 targets
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 +
