Received: by 2002:a25:ca44:0:0:0:0:0 with SMTP id a65csp99380ybg; Tue, 28 Jul 2020 00:37:12 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwx9dAeucUBjkxcDYw2nvv5MIM2HljocMg37ecw5rKhfNLEbf7aF8acL3RuwdCyeEoxwI8K X-Received: by 2002:aa7:d04e:: with SMTP id n14mr25734818edo.161.1595921832108; Tue, 28 Jul 2020 00:37:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1595921832; cv=none; d=google.com; s=arc-20160816; b=tIGBpOX3NnyjJoiUTmY3Bp1TS49PC0TIFGmeztmBCIoyNQHKNsmtoTKVaA6y02VxiV sYrpaPk5qJp0Cw8ZsAeB60tSt/27lbX1xhqPAxwcuLw9JSiF5SletEHsFa+3c9/T5c2F v5pVN0G1a7TV23RhpnwCuwmyK8NlJxZwgF1P/9brtatIvsFFPeVYIsMQl3d5X3haaUeC 6SKRy+Ls4pKMLzl61ruFpIFTlbzrdqb417Fe/3aSHZ9Efsr4nHnQSrSNTd2WQyV1XVKd EUX/a/h5rkDqKSUqKtC3AHMbNJNsSRvpUg72A3tprRdSaMiiRBR0Lsno5FpqyYSfORYM ZVWQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date :dkim-signature; bh=+WddsceetGEH7lTa097j6aCPD4UcMjn/dep91iQggfw=; b=VzP5T70+8bDZ/Z7OWA5LGAuqVY724I9QXY5pD2/Wjy8eSfIIpbUoUnN+jBMHWgxrQ5 8YMvTvUSiQNFajka9QDdl4Py4dRYxrHpukPqBHIJzpkXKoO1p5hJj8anReMp4SyU+L1g B31i899DO02yOK6WFLBqAU2Qfix4R+siZXMaBf2vjcyRBRxvJ3pl6BSGumV75fDb1Ego ho5RzwshFVl93LzZXqRKgNA/iaDzgOEHY6Zq9Ei2YRyElysiz+R5BivX61+EyaQgJQwT 2uO+s6Fc+r47zaKh8sHSFXX2dmPQOpo1kj5ux3ajDxG++37seD2bPqUQumU9ti5+etBH mQgQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=Ai+28Ik6; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id dv20si6923897ejb.582.2020.07.28.00.36.49; Tue, 28 Jul 2020 00:37:12 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=Ai+28Ik6; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727962AbgG1HeH (ORCPT + 99 others); Tue, 28 Jul 2020 03:34:07 -0400 Received: from mail.kernel.org ([198.145.29.99]:58436 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727072AbgG1HeH (ORCPT ); Tue, 28 Jul 2020 03:34:07 -0400 Received: from devnote2 (NE2965lan1.rev.em-net.ne.jp [210.141.244.193]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 02F342070B; Tue, 28 Jul 2020 07:34:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1595921646; bh=4CctEpqXsw2X+EjiNA/gb/+djSwvwlkPMoJAMblIkKA=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=Ai+28Ik68vLxiJUscY/lUed8N+B4bpestmgqJb+Y188jeEcl/ULmEZNiUbbLRHcnL FpljcWZVuNziex5ab5DM4RlpXDXdv/GtI/VRstcF2Y6qkkM029uPwxkFnrvf1JBqZA sh3gtZfs7ncSrVqEIBHPyAHtkDoVBw5CtOGSj96w= Date: Tue, 28 Jul 2020 16:34:00 +0900 From: Masami Hiramatsu To: Ingo Molnar Cc: Jarkko Sakkinen , linux-kernel@vger.kernel.org, linux-mm@kvack.org, Andi Kleen , Peter Zijlstra , Masami Hiramatsu , Jessica Yu , "Naveen N. Rao" , Anil S Keshavamurthy , "David S. Miller" , Steven Rostedt , Ingo Molnar Subject: Re: [PATCH v5 1/6] kprobes: Remove dependency to the module_mutex Message-Id: <20200728163400.e00b09c594763349f99ce6cb@kernel.org> In-Reply-To: <20200725102110.GA757173@gmail.com> References: <20200724050553.1724168-1-jarkko.sakkinen@linux.intel.com> <20200724050553.1724168-2-jarkko.sakkinen@linux.intel.com> <20200724091711.GB517988@gmail.com> <20200725030107.GF17052@linux.intel.com> <20200725102110.GA757173@gmail.com> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.32; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, 25 Jul 2020 12:21:10 +0200 Ingo Molnar wrote: > > * Jarkko Sakkinen wrote: > > > On Fri, Jul 24, 2020 at 11:17:11AM +0200, Ingo Molnar wrote: > > > > > > * Jarkko Sakkinen wrote: > > > > > > > --- a/kernel/kprobes.c > > > > +++ b/kernel/kprobes.c > > > > @@ -564,7 +564,7 @@ static void kprobe_optimizer(struct work_struct *work) > > > > cpus_read_lock(); > > > > mutex_lock(&text_mutex); > > > > /* Lock modules while optimizing kprobes */ > > > > - mutex_lock(&module_mutex); > > > > + lock_modules(); > > > > > > > > /* > > > > * Step 1: Unoptimize kprobes and collect cleaned (unused and disarmed) > > > > @@ -589,7 +589,7 @@ static void kprobe_optimizer(struct work_struct *work) > > > > /* Step 4: Free cleaned kprobes after quiesence period */ > > > > do_free_cleaned_kprobes(); > > > > > > > > - mutex_unlock(&module_mutex); > > > > + unlock_modules(); > > > > mutex_unlock(&text_mutex); > > > > cpus_read_unlock(); > > > > > > BTW., it would be nice to expand on the comments above - exactly which > > > parts of the modules code is being serialized against and why? > > > > > > We already hold the text_mutex here, which should protect against most > > > kprobes related activities interfering - and it's unclear (to me) > > > which part of the modules code is being serialized with here, and the > > > 'lock modules while optimizing kprobes' comments is unhelpful. :-) > > > > > > Thanks, > > > > > > Ingo > > > > AFAIK, only if you need to call find_module(), you ever need to acquire > > this mutex. 99% of time it is internally taken care by kernel/module.c. > > > > I cannot make up any obvious reason to acquire it here. > > If it's unnecessary, then it needs to be removed. > > If it's necessary, then it needs to be documented better. Good catch! This is not needed anymore. It has been introduced to avoid conflict with text modification, at that point we didn't get text_mutex. But after commit f1c6ece23729 ("kprobes: Fix potential deadlock in kprobe_optimizer()") moved the text_mutex in the current position, we don't need it. (and anyway, keeping kprobe_mutex locked means any module unloading will be stopped inside kprobes_module_callback()) This may help? From 2355ecd941c3234b12a6de7443592848ed4e2087 Mon Sep 17 00:00:00 2001 From: Masami Hiramatsu Date: Tue, 28 Jul 2020 16:32:34 +0900 Subject: [PATCH] kprobes: Remove unneeded module_mutex lock from the optimizer Remove unneeded module_mutex locking from the optimizer. Since we already locks both kprobe_mutex and text_mutex in the optimizer, text will not be changed and the module unloading will be stopped inside kprobes_module_callback(). Suggested-by: Ingo Molnar Signed-off-by: Masami Hiramatsu --- kernel/kprobes.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/kernel/kprobes.c b/kernel/kprobes.c index 4a904cc56d68..d1b02e890793 100644 --- a/kernel/kprobes.c +++ b/kernel/kprobes.c @@ -563,8 +563,6 @@ static void kprobe_optimizer(struct work_struct *work) mutex_lock(&kprobe_mutex); cpus_read_lock(); mutex_lock(&text_mutex); - /* Lock modules while optimizing kprobes */ - mutex_lock(&module_mutex); /* * Step 1: Unoptimize kprobes and collect cleaned (unused and disarmed) @@ -589,7 +587,6 @@ static void kprobe_optimizer(struct work_struct *work) /* Step 4: Free cleaned kprobes after quiesence period */ do_free_cleaned_kprobes(); - mutex_unlock(&module_mutex); mutex_unlock(&text_mutex); cpus_read_unlock(); -- 2.25.1 -- Masami Hiramatsu