From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757528AbdJPVCK (ORCPT ); Mon, 16 Oct 2017 17:02:10 -0400 Received: from www62.your-server.de ([213.133.104.62]:36911 "EHLO www62.your-server.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754745AbdJPVCJ (ORCPT ); Mon, 16 Oct 2017 17:02:09 -0400 Message-ID: <59E51E4E.4060009@iogearbox.net> Date: Mon, 16 Oct 2017 23:02:06 +0200 From: Daniel Borkmann User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Richard Weinberger CC: netdev@vger.kernel.org, linux-kernel@vger.kernel.org, ast@kernel.org Subject: Re: [PATCH 3/3] bpf: Make sure that ->comm does not change under us. References: <20171016181856.12497-1-richard@nod.at> <20171016181856.12497-3-richard@nod.at> <59E51BA3.8040106@iogearbox.net> <3636052.F7cf4ubS1t@blindfold> In-Reply-To: <3636052.F7cf4ubS1t@blindfold> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated-Sender: daniel@iogearbox.net Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 10/16/2017 10:55 PM, Richard Weinberger wrote: > Am Montag, 16. Oktober 2017, 22:50:43 CEST schrieb Daniel Borkmann: >>> struct task_struct *task = current; >>> >>> + task_lock(task); >>> >>> strncpy(buf, task->comm, size); >>> >>> + task_unlock(task); >> >> Wouldn't this potentially lead to a deadlock? E.g. you attach yourself >> to task_lock() / spin_lock() / etc, and then the BPF prog triggers the >> bpf_get_current_comm() taking the lock again ... > > Yes, but doesn't the same apply to the use case when I attach to strncpy() > and run bpf_get_current_comm()? You mean due to recursion? In that case trace_call_bpf() would bail out due to the bpf_prog_active counter.