Received: by 2002:a25:8b12:0:0:0:0:0 with SMTP id i18csp62625ybl; Mon, 12 Aug 2019 11:44:26 -0700 (PDT) X-Google-Smtp-Source: APXvYqzkRxX76iPaLtbXC6e5ggZCcTCYClwRn7Cf4pGnG9qsEJNkxFgj/pS+3qrUN20USudizHaS X-Received: by 2002:a17:90a:800a:: with SMTP id b10mr606722pjn.23.1565635465913; Mon, 12 Aug 2019 11:44:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1565635465; cv=none; d=google.com; s=arc-20160816; b=qoi4ubKggp3kS+ta8zNy+ZR+GRlZW+YkRLB/xHUkizINQuqz+KTBsdi4yyp0oZ6PFM h93ZTbwmSXRtfNSMeVlcVBdAFerLJ2HrECSs912utiPibvWtarU8V927kcjYv6St3eBw /xwcRoMs1/HNaSPZWh/LNYtuIN/1nh8xzxwFrRZfVpVv2w0MFWANPX/C+rhNvzbQbqWY qXX9TioeKfDNpl9Mzd4Y8/faWpojjRq/2KQP9YkLItoJa/1wKBR22OsQcYOl4X2nc/zr YMKw5n/qPbBIgQh5F6zMhQlgfN+kAGJ3ObUQW5m1jlJHhf+J/e4zqKU9TzV8/Q3kdnI3 haLw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:content-disposition :mime-version:message-id:subject:cc:to:from:date; bh=zOSc9bmVuG5obO3oziTzKmJN7+pvSQBbPqrqY+V06TY=; b=GkPNJXpUSockRRz0VGj2M7x/Lo9LdjiVjdWo/YYw5E1Mp0A6e8Q/0bJbtEyuXcPkwb kFk/ZCMOR+RlCctxiFaFD4NGn9cChRnFJo7aFZqVIDRG+7CJlU94yReXlNtYzrTSdzms beOa27XE/ho8DYPl3gSYVfazY8/vVeQ1iidcsmbHNvF/6nUeQ2k7DwWZGn3DY0dX+18I Y+baMW74glk9aMYBjAztUHesHebWkdkMZQqNkazwX7oao8UqudFp3zBv4pXw0KgtDQr5 oba+w6Zj8YP5Sun0opjLeAXJ2Mgn0YqwEQ7mqkliOw83RpJjgRzHRvPDmjtX/hiRAyZp dRqQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=canonical.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id a2si224293pjk.63.2019.08.12.11.44.09; Mon, 12 Aug 2019 11:44:25 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=canonical.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726757AbfHLSnI (ORCPT + 99 others); Mon, 12 Aug 2019 14:43:08 -0400 Received: from youngberry.canonical.com ([91.189.89.112]:54224 "EHLO youngberry.canonical.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726185AbfHLSnI (ORCPT ); Mon, 12 Aug 2019 14:43:08 -0400 Received: from mail-wm1-f72.google.com ([209.85.128.72]) by youngberry.canonical.com with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.76) (envelope-from ) id 1hxFHd-0002W0-8q for linux-kernel@vger.kernel.org; Mon, 12 Aug 2019 18:43:05 +0000 Received: by mail-wm1-f72.google.com with SMTP id r9so151269wme.8 for ; Mon, 12 Aug 2019 11:43:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:mime-version :content-disposition:user-agent; bh=zOSc9bmVuG5obO3oziTzKmJN7+pvSQBbPqrqY+V06TY=; b=AG00wf73f7w/p7Iyd6X5XHgAj2xss0Dn0VVBSn2itkiiZ7v2Dfr4BA0/Uevtb9y5BH VdMcl2ws4fQhHb2LW16fzus0I9vUpAz34mPzpg9yGnsMkqLtqaIPVVaZDyhLaizMo+Cc rDLFZGtuXbiJ0ArYmwNOdUjCyOVpq/9425xrD2QMEpjKetHSIoWQHKFk0ImOdOA7numU ZwMsLAsKsp73dNFLMhwK/BIh3cj8CAzD6TCcCuS+8tdCQgDloZavP0XZrIyOIyoBJC/7 +ukmEi9I92Z8BQjnT9ZHJoH4pY0u+rB3ztVCa67f6los9rrJOdaykmPHzA+gzFUQxkep UpLw== X-Gm-Message-State: APjAAAVhxFS81KIp4g8zK3jzOR94b+oWX6NPZuXnr+S8Vtx4v2oIFqXG BQgO6fP0rtQcb0T9NX+YDGKW4bLFGtgfTfQJh1AZSPe8SdAhLTxuLVFinJpyP6bKAgV3+AOPHli OwEQey6qErZHPS4eA0E+al0Onz0neUWhhzetmwcex9A== X-Received: by 2002:a05:600c:21ca:: with SMTP id x10mr724456wmj.112.1565635384883; Mon, 12 Aug 2019 11:43:04 -0700 (PDT) X-Received: by 2002:a05:600c:21ca:: with SMTP id x10mr724435wmj.112.1565635384567; Mon, 12 Aug 2019 11:43:04 -0700 (PDT) Received: from localhost ([95.238.207.169]) by smtp.gmail.com with ESMTPSA id l3sm26644952wrb.41.2019.08.12.11.43.03 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 12 Aug 2019 11:43:04 -0700 (PDT) Date: Mon, 12 Aug 2019 20:43:02 +0200 From: Andrea Righi To: Masami Hiramatsu , "David S. Miller" , Anil S Keshavamurthy , "Naveen N. Rao" Cc: linux-kernel@vger.kernel.org Subject: [PATCH] kprobes: fix potential deadlock in kprobe_optimizer() Message-ID: <20190812184302.GA7010@xps-13> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org lockdep reports the following: WARNING: possible circular locking dependency detected kworker/1:1/48 is trying to acquire lock: 000000008d7a62b2 (text_mutex){+.+.}, at: kprobe_optimizer+0x163/0x290 but task is already holding lock: 00000000850b5e2d (module_mutex){+.+.}, at: kprobe_optimizer+0x31/0x290 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (module_mutex){+.+.}: __mutex_lock+0xac/0x9f0 mutex_lock_nested+0x1b/0x20 set_all_modules_text_rw+0x22/0x90 ftrace_arch_code_modify_prepare+0x1c/0x20 ftrace_run_update_code+0xe/0x30 ftrace_startup_enable+0x2e/0x50 ftrace_startup+0xa7/0x100 register_ftrace_function+0x27/0x70 arm_kprobe+0xb3/0x130 enable_kprobe+0x83/0xa0 enable_trace_kprobe.part.0+0x2e/0x80 kprobe_register+0x6f/0xc0 perf_trace_event_init+0x16b/0x270 perf_kprobe_init+0xa7/0xe0 perf_kprobe_event_init+0x3e/0x70 perf_try_init_event+0x4a/0x140 perf_event_alloc+0x93a/0xde0 __do_sys_perf_event_open+0x19f/0xf30 __x64_sys_perf_event_open+0x20/0x30 do_syscall_64+0x65/0x1d0 entry_SYSCALL_64_after_hwframe+0x49/0xbe -> #0 (text_mutex){+.+.}: __lock_acquire+0xfcb/0x1b60 lock_acquire+0xca/0x1d0 __mutex_lock+0xac/0x9f0 mutex_lock_nested+0x1b/0x20 kprobe_optimizer+0x163/0x290 process_one_work+0x22b/0x560 worker_thread+0x50/0x3c0 kthread+0x112/0x150 ret_from_fork+0x3a/0x50 other info that might help us debug this: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(module_mutex); lock(text_mutex); lock(module_mutex); lock(text_mutex); *** DEADLOCK *** As a reproducer I've been using bcc's funccount.py (https://github.com/iovisor/bcc/blob/master/tools/funccount.py), for example: # ./funccount.py '*interrupt*' That immediately triggers the lockdep splat. Fix by acquiring text_mutex before module_mutex in kprobe_optimizer(). Fixes: d5b844a2cf50 ("ftrace/x86: Remove possible deadlock between register_kprobe() and ftrace_run_update_code()") Signed-off-by: Andrea Righi --- kernel/kprobes.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/kernel/kprobes.c b/kernel/kprobes.c index 9873fc627d61..d9770a5393c8 100644 --- a/kernel/kprobes.c +++ b/kernel/kprobes.c @@ -470,6 +470,7 @@ static DECLARE_DELAYED_WORK(optimizing_work, kprobe_optimizer); */ static void do_optimize_kprobes(void) { + lockdep_assert_held(&text_mutex); /* * The optimization/unoptimization refers online_cpus via * stop_machine() and cpu-hotplug modifies online_cpus. @@ -487,9 +488,7 @@ static void do_optimize_kprobes(void) list_empty(&optimizing_list)) return; - mutex_lock(&text_mutex); arch_optimize_kprobes(&optimizing_list); - mutex_unlock(&text_mutex); } /* @@ -500,6 +499,7 @@ static void do_unoptimize_kprobes(void) { struct optimized_kprobe *op, *tmp; + lockdep_assert_held(&text_mutex); /* See comment in do_optimize_kprobes() */ lockdep_assert_cpus_held(); @@ -507,7 +507,6 @@ static void do_unoptimize_kprobes(void) if (list_empty(&unoptimizing_list)) return; - mutex_lock(&text_mutex); arch_unoptimize_kprobes(&unoptimizing_list, &freeing_list); /* Loop free_list for disarming */ list_for_each_entry_safe(op, tmp, &freeing_list, list) { @@ -524,7 +523,6 @@ static void do_unoptimize_kprobes(void) } else list_del_init(&op->list); } - mutex_unlock(&text_mutex); } /* Reclaim all kprobes on the free_list */ @@ -556,6 +554,7 @@ 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); @@ -583,6 +582,7 @@ static void kprobe_optimizer(struct work_struct *work) do_free_cleaned_kprobes(); mutex_unlock(&module_mutex); + mutex_unlock(&text_mutex); cpus_read_unlock(); mutex_unlock(&kprobe_mutex); -- 2.20.1