All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jann Horn <jannh@google.com>
To: Oleg Nesterov <oleg@redhat.com>
Cc: "Eric W . Biederman" <ebiederm@xmission.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Kees Cook <keescook@chromium.org>,
	David Howells <dhowells@redhat.com>,
	kernel list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] ptrace: restore smp_rmb() in __ptrace_may_access()
Date: Fri, 31 May 2019 21:37:18 +0200	[thread overview]
Message-ID: <CAG48ez3R=hjfKgh9zR6uoXBM54CRwh99QBqZNvAyHznBd8edgg@mail.gmail.com> (raw)
In-Reply-To: <20190531133535.GB31323@redhat.com>

On Fri, May 31, 2019 at 3:35 PM Oleg Nesterov <oleg@redhat.com> wrote:
> On 05/31, Jann Horn wrote:
> >
> > So I guess I should make a v2 that still adds the smp_rmb() in
> > __ptrace_may_access(), but gets rid of the smp_wmb() in
> > commit_creds()? (With a comment above the rcu_assign_pointer() that
> > explains the ordering?)
>
> I am fine either way, whatever you like more.
>
> If you prefer v1 (this patch), feel free to add
>
> Acked-by: Oleg Nesterov <oleg@redhat.com>

Thanks! I think I actually like the current version more, since this
way, we have a nice simple pairing of smp_rmb() and smp_wmb().
Otherwise we end up mixing smp_rmb() with smp_store_release(), which I
find kind of weird. And to me, semantically, it also seems slightly
weird to use rcu_assign_pointer() as a barrier for previous writes
that are not pointed to by the pointer being assigned. Maybe I'm just
not familiar enough with the details of how memory ordering works to
feel comfortable with it...

      reply	other threads:[~2019-05-31 19:37 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-29 11:31 [PATCH] ptrace: restore smp_rmb() in __ptrace_may_access() Jann Horn
2019-05-29 15:59 ` Eric W. Biederman
2019-05-29 16:01   ` Jann Horn
2019-05-29 16:21 ` Oleg Nesterov
2019-05-29 17:38   ` Jann Horn
2019-05-30  1:41     ` Eric W. Biederman
2019-05-31 15:04       ` Jann Horn
2019-05-30 10:34     ` Andrea Parri
2019-05-31  9:08       ` Peter Zijlstra
2019-05-30 12:05     ` Oleg Nesterov
2019-05-31  9:12       ` Peter Zijlstra
2019-05-31  9:55         ` Oleg Nesterov
2019-05-29 21:02   ` Jann Horn
2019-05-29 18:55 ` Kees Cook
2019-05-30 12:34 ` Oleg Nesterov
2019-05-31 11:56   ` Jann Horn
2019-05-31 13:35     ` Oleg Nesterov
2019-05-31 19:37       ` Jann Horn [this message]

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='CAG48ez3R=hjfKgh9zR6uoXBM54CRwh99QBqZNvAyHznBd8edgg@mail.gmail.com' \
    --to=jannh@google.com \
    --cc=akpm@linux-foundation.org \
    --cc=dhowells@redhat.com \
    --cc=ebiederm@xmission.com \
    --cc=keescook@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=oleg@redhat.com \
    /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.