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
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
