All of lore.kernel.org
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@linux-foundation.org>
To: Al Viro <viro@zeniv.linux.org.uk>
Cc: Thomas Gleixner <tglx@linutronix.de>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [RFC][PATCH 5/7] x86: convert arch_futex_atomic_op_inuser() to user_access_begin/user_access_end()
Date: Mon, 23 Mar 2020 12:06:39 -0700	[thread overview]
Message-ID: <CAHk-=wgMmmnQTFT7U9+q2BsyV6Ge+LAnnhPmv0SUtFBV1D4tVw@mail.gmail.com> (raw)
In-Reply-To: <20200323185127.252501-5-viro@ZenIV.linux.org.uk>

On Mon, Mar 23, 2020 at 11:53 AM Al Viro <viro@zeniv.linux.org.uk> wrote:
>
> From: Al Viro <viro@zeniv.linux.org.uk>
>
> Lift stac/clac pairs from __futex_atomic_op{1,2} into arch_futex_atomic_op_inuser(),
> fold them with access_ok() in there.

So this is a deep internal macro and already has the double
underscore, but I'm inclined to say "add the unsafe here too" for
those __futex_atomic_opX() macros that are now called inside that
user_access_begin/end region.

And wouldn't it be lovely to get rid of the error return thing, and
pass in a label instead, the way "usafe_get/put_user()" works too?
That might be a separate patch from the "reorg" thing, though.

             Linus

  reply	other threads:[~2020-03-23 19:07 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-23 18:50 [RFC][PATCHSET] futex uaccess cleanups Al Viro
2020-03-23 18:51 ` [RFC][PATCH 1/7] futex: arch_futex_atomic_op_inuser() calling conventions change Al Viro
2020-03-23 18:51   ` [RFC][PATCH 2/7] sh: no need of access_ok() in arch_futex_atomic_op_inuser() Al Viro
2020-03-23 18:51   ` [RFC][PATCH 3/7] [parisc, s390, sparc64] no need for access_ok() in futex handling Al Viro
2020-03-23 18:51   ` [RFC][PATCH 4/7] objtool: whitelist __sanitizer_cov_trace_switch() Al Viro
2020-03-23 18:51   ` [RFC][PATCH 5/7] x86: convert arch_futex_atomic_op_inuser() to user_access_begin/user_access_end() Al Viro
2020-03-23 19:06     ` Linus Torvalds [this message]
2020-03-24  2:08       ` Al Viro
2020-03-24 16:19         ` Linus Torvalds
2020-03-24 20:42           ` Al Viro
2020-03-24 20:57             ` Linus Torvalds
2020-03-27  2:42               ` Al Viro
2020-03-27  3:42                 ` Linus Torvalds
2020-03-27  3:49                   ` Linus Torvalds
2020-03-27  4:03                     ` Linus Torvalds
2020-03-27  4:35                       ` Josh Poimboeuf
2020-03-23 18:51   ` [RFC][PATCH 6/7] generic arch_futex_atomic_op_inuser() doesn't need access_ok() Al Viro
2020-03-23 18:51   ` [RFC][PATCH 7/7] x86: get rid of user_atomic_cmpxchg_inatomic() Al Viro

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAHk-=wgMmmnQTFT7U9+q2BsyV6Ge+LAnnhPmv0SUtFBV1D4tVw@mail.gmail.com' \
    --to=torvalds@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tglx@linutronix.de \
    --cc=viro@zeniv.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.