Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1742243

Re: [PATCH v3 3/3] kernel/uprobes: Fix check for active uprobe

From Oleg Nesterov <oleg@redhat.com>
Newsgroups linux.kernel
Subject Re: [PATCH v3 3/3] kernel/uprobes: Fix check for active uprobe
Date 2017-09-29 19:00 +0200
Message-ID <uv6NP-gs-11@gated-at.bofh.it> (permalink)
References <usshP-4kK-7@gated-at.bofh.it> <usshP-4kK-17@gated-at.bofh.it> <utEgX-iV-25@gated-at.bofh.it> <uv3wD-6Hg-41@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


On 09/29, Srikar Dronamraju wrote:
>
> > This is correct because we do this check under mmap_sem so we can't race with
> > install_breakpoint(), so is_trap_at_addr() == T can't be falsely true if
> > UPROBE_COPY_INSN is not set.
> >
>
> Right, Given that we are doing this in the mmap_sem, we should also be
> removing the rmb/wmb pairs too.

Well, down_read(&mm->mmap_sem) can only guarantee that this mm can not be
modified by install_breakpoint().

But what if, say, another task with different ->mm does uprobe_mmap() and
calls prepare_uprobe() for the 1st time?

Or suppose we race with unregister+register...

OTOH, I agree that we can remove these barriers, but this needs a lengthy
comment while the current code looks "obviously correct" in that you do
not even need to think about potential races.

Oleg.

Back to linux.kernel | Previous | NextPrevious in thread | Find similar | Unroll thread


Thread

Re: [PATCH v3 3/3] kernel/uprobes: Fix check for active uprobe Srikar Dronamraju <srikar@linux.vnet.ibm.com> - 2017-09-29 15:30 +0200
  Re: [PATCH v3 3/3] kernel/uprobes: Fix check for active uprobe Oleg Nesterov <oleg@redhat.com> - 2017-09-29 19:00 +0200

csiph-web