Re: Fix MIPS o32 posix_fadvise [committed]

[Joseph Myers <joseph at codesourcery dot com>]

On Thu, 12 Jan 2017, Adhemerval Zanella wrote:

> Thanks for fixing it Joseph and I although I agree this fix should be the
> most straightforward one for 2.25, I would like to get back on it on 2.26.
> If arm behavior for posix_advise is not an outliner (as I wrongly supposed)
> I think we can incorporate it on generic code an get rid of both arch
> specific implementations.

Note that at the syscall level ARM and MIPS are different; it's just using 
__posix_fadvise64_l64 that works for both.

ARM defines only __NR_arm_fadvise64_64.  That syscall has permuted 
arguments (__ASSUME_FADVISE64_64_6ARG defined in kernel-features.h for 
ARM).  kernel-features.h then defines __NR_fadvise64_64 to 
__NR_arm_fadvise64_64 so that generic code can work for ARM.  I suspect 
the generic C version of posix_fadvise should work for ARM, given those 
definitions and care about avoiding the alignment argument.  (Why does 
posix_fadvise64.c do

#ifdef __ASSUME_FADVISE64_64_6ARG
  int ret = INTERNAL_SYSCALL_CALL (fadvise64_64, err, fd, advise,
                                   SYSCALL_LL64 (offset), SYSCALL_LL64 (len));
#else

with the alignment argument never used in that case, but posix_fadvise.c 
do

#  ifdef __ASSUME_FADVISE64_64_6ARG
  int ret = INTERNAL_SYSCALL_CALL (fadvise64_64, err, fd, advise,
                                   __ALIGNMENT_ARG SYSCALL_LL (offset),
                                   SYSCALL_LL (len));
#  else

which does use an alignment argument with the same syscall and argument 
order?)

MIPS defines only __NR_fadvise64, but it has the fadvise64_64 semantics 
(and does not permute arguments, so uses a 7-argument syscall for o32).  
To use generic C code for o32, you'd need to e.g. have a macro that says 
to prefer fadvise64_64 to fadvise64 (and then define __NR_fadvise64_64 to 
__NR_fadvise64 if not already defined, as done in posix_fadvise64.c).

-- 
Joseph S. Myers
joseph@codesourcery.com