From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id DA5B32CA9; Mon, 25 Nov 2024 03:30:51 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1732505451; cv=none; b=FXOmvl7YgNdENxz3YUC6hUIOcumiLHeDKJ4CqtEUMtGPC28b+NayN25UsU1o2+ppyuDJAy9Eq2Wkl141BUZNt9iwzQ/vj7WkwWo8rEW2Yv1kymM/gqAt07JfGqR7+ff2/HMhPUj3C+i4Gh+W4T/VzJlMafdTKE6Boys6IhaCvRM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1732505451; c=relaxed/simple; bh=yh9xxPO7u3XiOMx960+hEjEKDNvbp11Xdp0TxwKxFb0=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=gaPDF06+otAdtCpM+gDqf3bB23PADhVtkc9+dKZI43vUbGYwZbjxo3TQYQ8D9vB2MJsSQLTxE+ncAs/PtqD+1jQqGCoIGx3KFtjQrG+9MsFLOi/eBfQ5Or44ssdhHDbN0mW7VtaydmCA/lGjPJ+8glefQYc+DpIIe/k859Guog0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5F322C4CECC; Mon, 25 Nov 2024 03:30:47 +0000 (UTC) Date: Sun, 24 Nov 2024 22:30:45 -0500 From: Steven Rostedt To: Alexei Starovoitov Cc: Peter Zijlstra , Ruan Bonan , "mingo@redhat.com" , "will@kernel.org" , "longman@redhat.com" , "boqun.feng@gmail.com" , "linux-kernel@vger.kernel.org" , "kpsingh@kernel.org" , "mattbobrowski@google.com" , "ast@kernel.org" , "daniel@iogearbox.net" , "andrii@kernel.org" , "martin.lau@linux.dev" , "eddyz87@gmail.com" , "song@kernel.org" , "yonghong.song@linux.dev" , "john.fastabend@gmail.com" , "sdf@fomichev.me" , "haoluo@google.com" , "jolsa@kernel.org" , "mhiramat@kernel.org" , "mathieu.desnoyers@efficios.com" , "bpf@vger.kernel.org" , "linux-trace-kernel@vger.kernel.org" , "netdev@vger.kernel.org" , Fu Yeqi Subject: Re: [BUG] possible deadlock in __schedule (with reproducer available) Message-ID: <20241124223045.4e47e8b7@rorschach.local.home> In-Reply-To: References: <24481522-69BF-4CE7-A05D-1E7398400D80@u.nus.edu> <20241123202744.GB20633@noisy.programming.kicks-ass.net> <20241123180000.5e219f2e@gandalf.local.home> X-Mailer: Claws Mail 3.17.8 (GTK+ 2.24.33; x86_64-pc-linux-gnu) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Sun, 24 Nov 2024 18:02:35 -0800 Alexei Starovoitov wrote: > > > -EWONTFIX. Don't do stupid. > > > > Ack. BPF should not be causing deadlocks by doing code called from > > tracepoints. > > I sense so much BPF love here that it diminishes the ability to read > stack traces :) You know I love BPF ;-) I do recommend it when I feel it's the right tool for the job. > Above is one of many printk related splats that syzbot keeps finding. > This is not a new issue and it has nothing to do with bpf. I had to fight printk related spats too. But when that happens, its not considered a bug to the code that is being attached to. Note, my response is more about the subject title, which sounds like it's blaming the schedule code. Which is not the issue. > > > Tracepoints have a special context similar to NMIs. If you add > > a hook into an NMI handler that causes a deadlock, it's a bug in the hook, > > not the NMI code. If you add code that causes a deadlock when attaching to a > > tracepoint, it's a bug in the hook, not the tracepoint. > > trace events call strncpy_from_user_nofault() just as well. > kernel/trace/trace_events_filter.c:830 Well, in some cases you could do that from NMI as well. The point is, tracepoints are a different context, and things need to be careful when using it. If any deadlock occurs by attaching to a tracepoint (and this isn't just BPF, I have code too that needs to be very careful about this as well), then the bug is with the attached callback. I agree with Peter. This isn't his problem. Hence my Ack. -- Steve