Message ID | 20221125135500.1653800-1-frederic@kernel.org |
---|---|
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:adf:f944:0:0:0:0:0 with SMTP id q4csp4036917wrr; Fri, 25 Nov 2022 06:00:04 -0800 (PST) X-Google-Smtp-Source: AA0mqf6/2WvAYdU10b6H6E8uhUhrnXECXd0mM6WK/ZxwiDaVeCcLMH4WVW3vR9fLNTyING3tKusT X-Received: by 2002:a17:906:3a14:b0:7ad:79c0:4662 with SMTP id z20-20020a1709063a1400b007ad79c04662mr32633847eje.400.1669384804179; Fri, 25 Nov 2022 06:00:04 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1669384804; cv=none; d=google.com; s=arc-20160816; b=CnVh3vGRJUoG/8zhs5ujUg5U0x3gpQ1wk80nq9feI/MJcQ9qMokonEd2pZwLImJqdD ZRZLWO+4VcoSRwOlwiIex2hsMJyq42M/ZkW/tmMl9fYkXD33swJu39D9eq7hzUo7o3jH fz+1VpqTDqCewOhzmdUmkAw7eeQA0f+Q5GKUgjRQis3w61xYsy+ighqWk2egJnbsu9FO wLXIMfpi9YJogDYpO97feSNHV6KOCB+XxqFgF2mDDbVK5BzLHKD1LIS0655t9ljnFbMu iStlJmRPnJybZJ6PiV8Kqou8NvHEKVHtXWzPylqnyqbZFyn5mItJQ+eptjyQeMaSP3x7 IL1w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=XP+Tu46jmNsxp7hO8o5RwqV1Qt3CrDydkzrQ6wjpsQc=; b=lWAB34lSQHVFVMg0yPtlfTOJwtEHh8MB5pB0Lr+rLHcSKtgnTWYcUJvi8tOcUH1lmH 2zi2GCu8JttR9Gic7x5d2XYhf7+W7ksT/YPu0xFX+HxG403jdkdnJG8OnEF4a3zTLwj1 l0fED/PthJuEnkhAhBMy7/KFn/lSmBZD/ZQWq6n2tmVN0E0H0FsU8P2Hqs/VWdS55sih 2LH36yqPJKi3CDjdqtylpmYh1scigO2PeimoTVSkoUBWT1V4Uj4oBtAsca/qhVwEDjQe uPIxDlf9lUQwpPyUVlvJFSyBlsdKDFgoOhlwZCjJ0aRXF6rLWLbRpkwQgOdaOOZqqz14 zP/A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=OySoHP9+; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id l15-20020a170906794f00b00780488c11bbsi3386792ejo.388.2022.11.25.05.59.39; Fri, 25 Nov 2022 06:00:04 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=OySoHP9+; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 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 S229753AbiKYNzL (ORCPT <rfc822;zxc52fgh@gmail.com> + 99 others); Fri, 25 Nov 2022 08:55:11 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50770 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229506AbiKYNzJ (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Fri, 25 Nov 2022 08:55:09 -0500 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 51686D2EA; Fri, 25 Nov 2022 05:55:09 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 085DDB82AC8; Fri, 25 Nov 2022 13:55:08 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id A9510C433C1; Fri, 25 Nov 2022 13:55:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1669384506; bh=VXa83RlqoumhQA/Jh/3yZg/Ss1tzTts+aOw3XPdmkvw=; h=From:To:Cc:Subject:Date:From; b=OySoHP9+T5BWpbzme6cidsdtNlwxdV0ZzkGEs3PTy3uW/7QR4zmAmmglrwbKJ8Qru F4ekcBCIRgMDn6KxOFffjKWI5LsLThCnoSxL2EFMFcnfsh+8/3pPuujlnnWNLcyPHm mfx9mD3tuYlBPxUbBfnI+EVsdCBCRutN7edJTJH77AgG1unH7RS6FPi6Sw6yEhyhmi sgtfnIKhc8ICDOcMIveqeubhiMMWP5JCfnXKAp2ciJXcONJj14yXw6miFNmU11KA8q ScsoQHNuuhjzkMFc8JSrvXlnCiznGRNSah30xY1N1fEWE/vTgXv3x+OD2xQ9m9HSIq OV20ONg/l7twQ== From: Frederic Weisbecker <frederic@kernel.org> To: "Paul E . McKenney" <paulmck@kernel.org> Cc: LKML <linux-kernel@vger.kernel.org>, Frederic Weisbecker <frederic@kernel.org>, "Eric W . Biederman" <ebiederm@xmission.com>, Neeraj Upadhyay <quic_neeraju@quicinc.com>, Oleg Nesterov <oleg@redhat.com>, Pengfei Xu <pengfei.xu@intel.com>, Boqun Feng <boqun.feng@gmail.com>, Lai Jiangshan <jiangshanlai@gmail.com>, rcu@vger.kernel.org Subject: [PATCH 0/3] rcu-tasks: Fix race against exiting pid_ns Date: Fri, 25 Nov 2022 14:54:57 +0100 Message-Id: <20221125135500.1653800-1-frederic@kernel.org> X-Mailer: git-send-email 2.25.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-7.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI, SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1750476840409050820?= X-GMAIL-MSGID: =?utf-8?q?1750476840409050820?= |
Series | rcu-tasks: Fix race against exiting pid_ns | |
Message
Frederic Weisbecker
Nov. 25, 2022, 1:54 p.m. UTC
Pengfei Xu has reported a deadlock involving calls to unshare(), perf_event_open() and clone3() calls. It requires CAP_SYS_ADMIN to reproduce (at least I don't see a way for a non privilege process to reproduce). See this thread for details: https://lore.kernel.org/all/Y3sOgrOmMQqPMItu@xpf.sh.intel.com/ And this document for the collaborative analysis with Boqun, Paul and Neeraj: https://docs.google.com/document/d/1hJxgiZ5TMZ4YJkdJPLAkRvq7sYQ-A7svgA8no6i-v8k The two first patches are small improvements. The fix is in the last patch. git://git.kernel.org/pub/scm/linux/kernel/git/frederic/linux-dynticks.git rcu/dev HEAD: 45ef5a0a4be4e0db9eadcc86e8f346d34c62e744 Thanks, Frederic --- Frederic Weisbecker (3): rcu-tasks: Improve comments explaining tasks_rcu_exit_srcu purpose rcu-tasks: Remove preemption disablement around srcu_read_[un]lock() calls rcu-tasks: Fix synchronize_rcu_tasks() VS zap_pid_ns_processes() include/linux/rcupdate.h | 2 ++ kernel/pid_namespace.c | 17 +++++++++++++++ kernel/rcu/tasks.h | 55 ++++++++++++++++++++++++++++++++++++------------ 3 files changed, 60 insertions(+), 14 deletions(-)
Comments
On Fri, Nov 25, 2022 at 02:54:57PM +0100, Frederic Weisbecker wrote: > Pengfei Xu has reported a deadlock involving calls to unshare(), > perf_event_open() and clone3() calls. It requires CAP_SYS_ADMIN > to reproduce (at least I don't see a way for a non privilege process to > reproduce). > > See this thread for details: https://lore.kernel.org/all/Y3sOgrOmMQqPMItu@xpf.sh.intel.com/ > And this document for the collaborative analysis with Boqun, Paul and Neeraj: > https://docs.google.com/document/d/1hJxgiZ5TMZ4YJkdJPLAkRvq7sYQ-A7svgA8no6i-v8k > > The two first patches are small improvements. The fix is in the last patch. > > git://git.kernel.org/pub/scm/linux/kernel/git/frederic/linux-dynticks.git > rcu/dev > > HEAD: 45ef5a0a4be4e0db9eadcc86e8f346d34c62e744 Hearing no objections, queued for further review and testing. And thank you very much! That race between synchronize_rcu_tasks() and zap_pid_ns_processes() certainly was more than a bit on the non-trivial side. Good show!!! Thanx, Paul > Thanks, > Frederic > --- > > Frederic Weisbecker (3): > rcu-tasks: Improve comments explaining tasks_rcu_exit_srcu purpose > rcu-tasks: Remove preemption disablement around srcu_read_[un]lock() calls > rcu-tasks: Fix synchronize_rcu_tasks() VS zap_pid_ns_processes() > > > include/linux/rcupdate.h | 2 ++ > kernel/pid_namespace.c | 17 +++++++++++++++ > kernel/rcu/tasks.h | 55 ++++++++++++++++++++++++++++++++++++------------ > 3 files changed, 60 insertions(+), 14 deletions(-)
On Mon, Nov 28, 2022 at 04:22:40PM -0800, Paul E. McKenney wrote: > On Fri, Nov 25, 2022 at 02:54:57PM +0100, Frederic Weisbecker wrote: > > Pengfei Xu has reported a deadlock involving calls to unshare(), > > perf_event_open() and clone3() calls. It requires CAP_SYS_ADMIN > > to reproduce (at least I don't see a way for a non privilege process to > > reproduce). > > > > See this thread for details: https://lore.kernel.org/all/Y3sOgrOmMQqPMItu@xpf.sh.intel.com/ > > And this document for the collaborative analysis with Boqun, Paul and Neeraj: > > https://docs.google.com/document/d/1hJxgiZ5TMZ4YJkdJPLAkRvq7sYQ-A7svgA8no6i-v8k > > > > The two first patches are small improvements. The fix is in the last patch. > > > > git://git.kernel.org/pub/scm/linux/kernel/git/frederic/linux-dynticks.git > > rcu/dev > > > > HEAD: 45ef5a0a4be4e0db9eadcc86e8f346d34c62e744 > > Hearing no objections, queued for further review and testing. > > And thank you very much! That race between synchronize_rcu_tasks() and > zap_pid_ns_processes() certainly was more than a bit on the non-trivial > side. Good show!!! Thanks! Also please replace the last patch with the following to fix a !CONFIG_RCU_TASKS issue: --- From: Frederic Weisbecker <frederic@kernel.org> Date: Thu, 24 Nov 2022 18:15:46 +0100 Subject: [PATCH] rcu-tasks: Fix synchronize_rcu_tasks() VS zap_pid_ns_processes() RCU Tasks and PID-namespace unshare can interact in do_exit() in a complicated circular dependency: 1) TASK A calls unshare(CLONE_NEWPID), this creates a new PID namespace that every subsequent child of TASK A will belong to. But TASK A doesn't itself belong to that new PID namespace. 2) TASK A forks() and creates TASK B. TASK A stays attached to its PID namespace (let's say PID_NS1) and TASK B is the first task belonging to the new PID namespace created by unshare() (let's call it PID_NS2). 3) Since TASK B is the first task attached to PID_NS2, it becomes the PID_NS2 child reaper. 4) TASK A forks() again and creates TASK C which get attached to PID_NS2. Note how TASK C has TASK A as a parent (belonging to PID_NS1) but has TASK B (belonging to PID_NS2) as a pid_namespace child_reaper. 5) TASK B exits and since it is the child reaper for PID_NS2, it has to kill all other tasks attached to PID_NS2, and wait for all of them to die before getting reaped itself (zap_pid_ns_process()). 6) TASK A calls synchronize_rcu_tasks() which leads to synchronize_srcu(&tasks_rcu_exit_srcu). 7) TASK B is waiting for TASK C to get reaped. But TASK B is under a tasks_rcu_exit_srcu SRCU critical section (exit_notify() is between exit_tasks_rcu_start() and exit_tasks_rcu_finish()), blocking TASK A. 8) TASK C exits and since TASK A is its parent, it waits for it to reap TASK C, but it can't because TASK A waits for TASK B that waits for TASK C. Pid_namespace semantics can hardly be changed at this point. But the coverage of tasks_rcu_exit_srcu can be reduced instead. The current task is assumed not to be concurrently reapable at this stage of exit_notify() and therefore tasks_rcu_exit_srcu can be temporarily relaxed without breaking its constraints, providing a way out of the deadlock scenario. Fixes: 3f95aa81d265 ("rcu: Make TASKS_RCU handle tasks that are almost done exiting") Reported-by: Pengfei Xu <pengfei.xu@intel.com> Suggested-by: Boqun Feng <boqun.feng@gmail.com> Suggested-by: Neeraj Upadhyay <quic_neeraju@quicinc.com> Suggested-by: Paul E. McKenney <paulmck@kernel.org> Cc: Oleg Nesterov <oleg@redhat.com> Cc: Lai Jiangshan <jiangshanlai@gmail.com> Cc: Eric W . Biederman <ebiederm@xmission.com> Signed-off-by: Frederic Weisbecker <frederic@kernel.org> --- include/linux/rcupdate.h | 2 ++ kernel/pid_namespace.c | 17 +++++++++++++++++ kernel/rcu/tasks.h | 15 +++++++++++++-- 3 files changed, 32 insertions(+), 2 deletions(-) diff --git a/include/linux/rcupdate.h b/include/linux/rcupdate.h index 89b3036746d2..a19d91d5461c 100644 --- a/include/linux/rcupdate.h +++ b/include/linux/rcupdate.h @@ -238,6 +238,7 @@ void synchronize_rcu_tasks_rude(void); #define rcu_note_voluntary_context_switch(t) rcu_tasks_qs(t, false) void exit_tasks_rcu_start(void); +void exit_tasks_rcu_stop(void); void exit_tasks_rcu_finish(void); #else /* #ifdef CONFIG_TASKS_RCU_GENERIC */ #define rcu_tasks_classic_qs(t, preempt) do { } while (0) @@ -246,6 +247,7 @@ void exit_tasks_rcu_finish(void); #define call_rcu_tasks call_rcu #define synchronize_rcu_tasks synchronize_rcu static inline void exit_tasks_rcu_start(void) { } +static inline void exit_tasks_rcu_stop(void) { } static inline void exit_tasks_rcu_finish(void) { } #endif /* #else #ifdef CONFIG_TASKS_RCU_GENERIC */ diff --git a/kernel/pid_namespace.c b/kernel/pid_namespace.c index f4f8cb0435b4..fc21c5d5fd5d 100644 --- a/kernel/pid_namespace.c +++ b/kernel/pid_namespace.c @@ -244,7 +244,24 @@ void zap_pid_ns_processes(struct pid_namespace *pid_ns) set_current_state(TASK_INTERRUPTIBLE); if (pid_ns->pid_allocated == init_pids) break; + /* + * Release tasks_rcu_exit_srcu to avoid following deadlock: + * + * 1) TASK A unshare(CLONE_NEWPID) + * 2) TASK A fork() twice -> TASK B (child reaper for new ns) + * and TASK C + * 3) TASK B exits, kills TASK C, waits for TASK A to reap it + * 4) TASK A calls synchronize_rcu_tasks() + * -> synchronize_srcu(tasks_rcu_exit_srcu) + * 5) *DEADLOCK* + * + * It is considered safe to release tasks_rcu_exit_srcu here + * because we assume the current task can not be concurrently + * reaped at this point. + */ + exit_tasks_rcu_stop(); schedule(); + exit_tasks_rcu_start(); } __set_current_state(TASK_RUNNING); diff --git a/kernel/rcu/tasks.h b/kernel/rcu/tasks.h index 9a8114114b48..4dda8e6e5707 100644 --- a/kernel/rcu/tasks.h +++ b/kernel/rcu/tasks.h @@ -1016,16 +1016,27 @@ void exit_tasks_rcu_start(void) __acquires(&tasks_rcu_exit_srcu) * task is exiting and may be removed from the tasklist. See * corresponding synchronize_srcu() for further details. */ -void exit_tasks_rcu_finish(void) __releases(&tasks_rcu_exit_srcu) +void exit_tasks_rcu_stop(void) __releases(&tasks_rcu_exit_srcu) { struct task_struct *t = current; __srcu_read_unlock(&tasks_rcu_exit_srcu, t->rcu_tasks_idx); - exit_tasks_rcu_finish_trace(t); +} + +/* + * Contribute to protect against tasklist scan blind spot while the + * task is exiting and may be removed from the tasklist. See + * corresponding synchronize_srcu() for further details. + */ +void exit_tasks_rcu_finish(void) +{ + exit_tasks_rcu_stop(); + exit_tasks_rcu_finish_trace(current); } #else /* #ifdef CONFIG_TASKS_RCU */ void exit_tasks_rcu_start(void) { } +void exit_tasks_rcu_stop(void) { } void exit_tasks_rcu_finish(void) { exit_tasks_rcu_finish_trace(current); } #endif /* #else #ifdef CONFIG_TASKS_RCU */
On Tue, Nov 29, 2022 at 10:55:00AM +0100, Frederic Weisbecker wrote: > On Mon, Nov 28, 2022 at 04:22:40PM -0800, Paul E. McKenney wrote: > > On Fri, Nov 25, 2022 at 02:54:57PM +0100, Frederic Weisbecker wrote: > > > Pengfei Xu has reported a deadlock involving calls to unshare(), > > > perf_event_open() and clone3() calls. It requires CAP_SYS_ADMIN > > > to reproduce (at least I don't see a way for a non privilege process to > > > reproduce). > > > > > > See this thread for details: https://lore.kernel.org/all/Y3sOgrOmMQqPMItu@xpf.sh.intel.com/ > > > And this document for the collaborative analysis with Boqun, Paul and Neeraj: > > > https://docs.google.com/document/d/1hJxgiZ5TMZ4YJkdJPLAkRvq7sYQ-A7svgA8no6i-v8k > > > > > > The two first patches are small improvements. The fix is in the last patch. > > > > > > git://git.kernel.org/pub/scm/linux/kernel/git/frederic/linux-dynticks.git > > > rcu/dev > > > > > > HEAD: 45ef5a0a4be4e0db9eadcc86e8f346d34c62e744 > > > > Hearing no objections, queued for further review and testing. > > > > And thank you very much! That race between synchronize_rcu_tasks() and > > zap_pid_ns_processes() certainly was more than a bit on the non-trivial > > side. Good show!!! > > Thanks! > > Also please replace the last patch with the following to fix > a !CONFIG_RCU_TASKS issue: Like this? ;-) a0c355bbdfee ("squash! rcu-tasks: Fix synchronize_rcu_tasks() VS zap_pid_ns_processes()") Thanx, Paul > --- > From: Frederic Weisbecker <frederic@kernel.org> > Date: Thu, 24 Nov 2022 18:15:46 +0100 > Subject: [PATCH] rcu-tasks: Fix synchronize_rcu_tasks() VS > zap_pid_ns_processes() > > RCU Tasks and PID-namespace unshare can interact in do_exit() in a > complicated circular dependency: > > 1) TASK A calls unshare(CLONE_NEWPID), this creates a new PID namespace > that every subsequent child of TASK A will belong to. But TASK A > doesn't itself belong to that new PID namespace. > > 2) TASK A forks() and creates TASK B. TASK A stays attached to its PID > namespace (let's say PID_NS1) and TASK B is the first task belonging > to the new PID namespace created by unshare() (let's call it PID_NS2). > > 3) Since TASK B is the first task attached to PID_NS2, it becomes the > PID_NS2 child reaper. > > 4) TASK A forks() again and creates TASK C which get attached to PID_NS2. > Note how TASK C has TASK A as a parent (belonging to PID_NS1) but has > TASK B (belonging to PID_NS2) as a pid_namespace child_reaper. > > 5) TASK B exits and since it is the child reaper for PID_NS2, it has to > kill all other tasks attached to PID_NS2, and wait for all of them to > die before getting reaped itself (zap_pid_ns_process()). > > 6) TASK A calls synchronize_rcu_tasks() which leads to > synchronize_srcu(&tasks_rcu_exit_srcu). > > 7) TASK B is waiting for TASK C to get reaped. But TASK B is under a > tasks_rcu_exit_srcu SRCU critical section (exit_notify() is between > exit_tasks_rcu_start() and exit_tasks_rcu_finish()), blocking TASK A. > > 8) TASK C exits and since TASK A is its parent, it waits for it to reap > TASK C, but it can't because TASK A waits for TASK B that waits for > TASK C. > > Pid_namespace semantics can hardly be changed at this point. But the > coverage of tasks_rcu_exit_srcu can be reduced instead. > > The current task is assumed not to be concurrently reapable at this > stage of exit_notify() and therefore tasks_rcu_exit_srcu can be > temporarily relaxed without breaking its constraints, providing a way > out of the deadlock scenario. > > Fixes: 3f95aa81d265 ("rcu: Make TASKS_RCU handle tasks that are almost done exiting") > Reported-by: Pengfei Xu <pengfei.xu@intel.com> > Suggested-by: Boqun Feng <boqun.feng@gmail.com> > Suggested-by: Neeraj Upadhyay <quic_neeraju@quicinc.com> > Suggested-by: Paul E. McKenney <paulmck@kernel.org> > Cc: Oleg Nesterov <oleg@redhat.com> > Cc: Lai Jiangshan <jiangshanlai@gmail.com> > Cc: Eric W . Biederman <ebiederm@xmission.com> > Signed-off-by: Frederic Weisbecker <frederic@kernel.org> > --- > include/linux/rcupdate.h | 2 ++ > kernel/pid_namespace.c | 17 +++++++++++++++++ > kernel/rcu/tasks.h | 15 +++++++++++++-- > 3 files changed, 32 insertions(+), 2 deletions(-) > > diff --git a/include/linux/rcupdate.h b/include/linux/rcupdate.h > index 89b3036746d2..a19d91d5461c 100644 > --- a/include/linux/rcupdate.h > +++ b/include/linux/rcupdate.h > @@ -238,6 +238,7 @@ void synchronize_rcu_tasks_rude(void); > > #define rcu_note_voluntary_context_switch(t) rcu_tasks_qs(t, false) > void exit_tasks_rcu_start(void); > +void exit_tasks_rcu_stop(void); > void exit_tasks_rcu_finish(void); > #else /* #ifdef CONFIG_TASKS_RCU_GENERIC */ > #define rcu_tasks_classic_qs(t, preempt) do { } while (0) > @@ -246,6 +247,7 @@ void exit_tasks_rcu_finish(void); > #define call_rcu_tasks call_rcu > #define synchronize_rcu_tasks synchronize_rcu > static inline void exit_tasks_rcu_start(void) { } > +static inline void exit_tasks_rcu_stop(void) { } > static inline void exit_tasks_rcu_finish(void) { } > #endif /* #else #ifdef CONFIG_TASKS_RCU_GENERIC */ > > diff --git a/kernel/pid_namespace.c b/kernel/pid_namespace.c > index f4f8cb0435b4..fc21c5d5fd5d 100644 > --- a/kernel/pid_namespace.c > +++ b/kernel/pid_namespace.c > @@ -244,7 +244,24 @@ void zap_pid_ns_processes(struct pid_namespace *pid_ns) > set_current_state(TASK_INTERRUPTIBLE); > if (pid_ns->pid_allocated == init_pids) > break; > + /* > + * Release tasks_rcu_exit_srcu to avoid following deadlock: > + * > + * 1) TASK A unshare(CLONE_NEWPID) > + * 2) TASK A fork() twice -> TASK B (child reaper for new ns) > + * and TASK C > + * 3) TASK B exits, kills TASK C, waits for TASK A to reap it > + * 4) TASK A calls synchronize_rcu_tasks() > + * -> synchronize_srcu(tasks_rcu_exit_srcu) > + * 5) *DEADLOCK* > + * > + * It is considered safe to release tasks_rcu_exit_srcu here > + * because we assume the current task can not be concurrently > + * reaped at this point. > + */ > + exit_tasks_rcu_stop(); > schedule(); > + exit_tasks_rcu_start(); > } > __set_current_state(TASK_RUNNING); > > diff --git a/kernel/rcu/tasks.h b/kernel/rcu/tasks.h > index 9a8114114b48..4dda8e6e5707 100644 > --- a/kernel/rcu/tasks.h > +++ b/kernel/rcu/tasks.h > @@ -1016,16 +1016,27 @@ void exit_tasks_rcu_start(void) __acquires(&tasks_rcu_exit_srcu) > * task is exiting and may be removed from the tasklist. See > * corresponding synchronize_srcu() for further details. > */ > -void exit_tasks_rcu_finish(void) __releases(&tasks_rcu_exit_srcu) > +void exit_tasks_rcu_stop(void) __releases(&tasks_rcu_exit_srcu) > { > struct task_struct *t = current; > > __srcu_read_unlock(&tasks_rcu_exit_srcu, t->rcu_tasks_idx); > - exit_tasks_rcu_finish_trace(t); > +} > + > +/* > + * Contribute to protect against tasklist scan blind spot while the > + * task is exiting and may be removed from the tasklist. See > + * corresponding synchronize_srcu() for further details. > + */ > +void exit_tasks_rcu_finish(void) > +{ > + exit_tasks_rcu_stop(); > + exit_tasks_rcu_finish_trace(current); > } > > #else /* #ifdef CONFIG_TASKS_RCU */ > void exit_tasks_rcu_start(void) { } > +void exit_tasks_rcu_stop(void) { } > void exit_tasks_rcu_finish(void) { exit_tasks_rcu_finish_trace(current); } > #endif /* #else #ifdef CONFIG_TASKS_RCU */ > > -- > 2.25.1 >
On Tue, Nov 29, 2022 at 06:48:34AM -0800, Paul E. McKenney wrote: > On Tue, Nov 29, 2022 at 10:55:00AM +0100, Frederic Weisbecker wrote: > > On Mon, Nov 28, 2022 at 04:22:40PM -0800, Paul E. McKenney wrote: > > > On Fri, Nov 25, 2022 at 02:54:57PM +0100, Frederic Weisbecker wrote: > > > > Pengfei Xu has reported a deadlock involving calls to unshare(), > > > > perf_event_open() and clone3() calls. It requires CAP_SYS_ADMIN > > > > to reproduce (at least I don't see a way for a non privilege process to > > > > reproduce). > > > > > > > > See this thread for details: https://lore.kernel.org/all/Y3sOgrOmMQqPMItu@xpf.sh.intel.com/ > > > > And this document for the collaborative analysis with Boqun, Paul and Neeraj: > > > > https://docs.google.com/document/d/1hJxgiZ5TMZ4YJkdJPLAkRvq7sYQ-A7svgA8no6i-v8k > > > > > > > > The two first patches are small improvements. The fix is in the last patch. > > > > > > > > git://git.kernel.org/pub/scm/linux/kernel/git/frederic/linux-dynticks.git > > > > rcu/dev > > > > > > > > HEAD: 45ef5a0a4be4e0db9eadcc86e8f346d34c62e744 > > > > > > Hearing no objections, queued for further review and testing. > > > > > > And thank you very much! That race between synchronize_rcu_tasks() and > > > zap_pid_ns_processes() certainly was more than a bit on the non-trivial > > > side. Good show!!! > > > > Thanks! > > > > Also please replace the last patch with the following to fix > > a !CONFIG_RCU_TASKS issue: > > Like this? ;-) > > a0c355bbdfee ("squash! rcu-tasks: Fix synchronize_rcu_tasks() VS zap_pid_ns_processes()") You got it! :)