From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752554AbdI2Qyb (ORCPT ); Fri, 29 Sep 2017 12:54:31 -0400 Received: from mx1.redhat.com ([209.132.183.28]:37230 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752448AbdI2Qy2 (ORCPT ); Fri, 29 Sep 2017 12:54:28 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 04138883D6 Authentication-Results: ext-mx02.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx02.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=oleg@redhat.com Date: Fri, 29 Sep 2017 18:54:25 +0200 From: Oleg Nesterov To: Srikar Dronamraju Cc: "Naveen N. Rao" , Ingo Molnar , Ananth N Mavinakayanahalli , Anton Blanchard , Michael Ellerman , linux-kernel@vger.kernel.org Subject: Re: [PATCH v3 3/3] kernel/uprobes: Fix check for active uprobe Message-ID: <20170929165425.GA21087@redhat.com> References: <6718c4ebec1d71524bb81c907180bad90fc8d3c3.1506061547.git.naveen.n.rao@linux.vnet.ibm.com> <20170925161619.GA15325@redhat.com> <20170929132723.GA2318@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170929132723.GA2318@linux.vnet.ibm.com> User-Agent: Mutt/1.5.24 (2015-08-30) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.26]); Fri, 29 Sep 2017 16:54:28 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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.