On Wed, 16 Oct 2019, Al Viro wrote:
> On Tue, Oct 15, 2019 at 07:08:46PM +0100, Al Viro wrote:
> > [futex folks and linux-arch Cc'd]
>
> > Another question: right now we have
> > if (!access_ok(uaddr, sizeof(u32)))
> > return -EFAULT;
> >
> > ret = arch_futex_atomic_op_inuser(op, oparg, &oldval, uaddr);
> > if (ret)
> > return ret;
> > in kernel/futex.c. Would there be any objections to moving access_ok()
> > inside the instances and moving pagefault_disable()/pagefault_enable()
> > outside?
> >
> > Reasons:
> > * on x86 that would allow folding access_ok() with STAC into
> > user_access_begin(). The same would be doable on other usual suspects
> > (arm, arm64, ppc, riscv, s390), bringing access_ok() next to their
> > STAC counterparts.
> > * pagefault_disable()/pagefault_enable() pair is universal on
> > all architectures, really meant to by the nature of the beast and
> > lifting it into kernel/futex.c would get the same situation as with
> > futex_atomic_cmpxchg_inatomic(). Which also does access_ok() inside
> > the primitive (also foldable into user_access_begin(), at that).
> > * access_ok() would be closer to actual memory access (and
> > out of the generic code).
> >
> > Comments?
>
> FWIW, completely untested patch follows; just the (semimechanical) conversion
> of calling conventions, no per-architecture followups included. Could futex
> folks ACK/NAK that in principle?
Makes sense and does not change any of the futex semantics. Go wild.
Thanks,
tglx
