From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pf1-f171.google.com (mail-pf1-f171.google.com [209.85.210.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 14D31279DCD for ; Wed, 8 Oct 2025 14:41:02 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.171 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1759934464; cv=none; b=QgWpMYZ6VYfiEuBGYtARagjnZ+C15yNZrziGrL49Mfa6hEOVVurajjQRQs6SB8IXbq/8/7EmJcDeZy9amVTFycdtOwbIhCwxae6KpX9sSsrr0mK8XRgT+teaFfLofT33ribT5vfP0E57q7dWYUxk3C5t5qeIm5cAt5z79LvG+lw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1759934464; c=relaxed/simple; bh=vHtHumejN87ncgya2ViWzvqch41xHhCK9RHyEy9NXFM=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=aSH1ho5gt6WfDRfrpsC4B0i9v1CuZK/jllopjKnIhG8nIJ5w+mTINcUm+5stMKZ385FwP/BZi8r0f4mTx0OPdmB51EggaAzkyGpLdNZ/pps099+K6iqhiAaAa/8n/sPlQWnVfp5hN2dDUPpS5Ghm4M82hFwyX6dM3zvVdciJlNc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=RhaCNuNP; arc=none smtp.client-ip=209.85.210.171 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="RhaCNuNP" Received: by mail-pf1-f171.google.com with SMTP id d2e1a72fcca58-76e4fc419a9so7070383b3a.0 for ; Wed, 08 Oct 2025 07:41:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1759934462; x=1760539262; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=XRgXZBDqFKfDqLPTjTiL4KlNwfATNNhaPH2ClvCy9+g=; b=RhaCNuNPm/Daj/eJYGaVERBTnTuSQ0eH6665Yjtn5DNLtjLXZNmPyNJH8LeOC3AtKO 70UNXk8fY8KDtFJqOuHr/j7ALWn4cv2qhcZKLj8XLIKD3unlPu8H9uUiqxIc+Q06xzV6 /N1+gNXFCQ7sp6wAXASY9CAAyelrfGlEXrR2ghtf5RTB0zvEtDeQqvA2uz1AehobIlcc jUV/v9gay/LfMbNRPiS+08CwHTTm9R7Lu/zGe9wGxpM8Vsi2LRB9qNMbtHWoU3Z2N1zG AFMDE0L1xuif+R6u1ROneshCqVi7FdbNGOVwFFgfopxE7zwR4c0G8ZgagiIa2nQPFs3A nftw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1759934462; x=1760539262; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=XRgXZBDqFKfDqLPTjTiL4KlNwfATNNhaPH2ClvCy9+g=; b=U934nUZVO0P/3K0MUlTX+cVx+a3gRWIc4vWwy1Wj9NJU3Fi/tEVoW/XAY304QquIIQ 28mU9YyZVJvaE2WXFI1vzpgAEUmz4fFAittmyJ4nDpM1f4gly+qpFYadhlbKU4bPQ02b 9oOZxUVfhIiG/Il10QrcmRRMVHg8UazCMYRzgC7m3T5oH/f/9jgHqIEi22N0hmIJMYIK prEgxj1V21+3Ftp+wuGhyLad+4skUYbF32FNPW8h/r2ZuwENOEpIegD6SlWqZo4NYscz 9FE8D3/+L8lq6Qd1tzBlH8pc/rrhL33tnt7x/q6nrTBq9AadC7LTEq/3m4j2DQHBQAt1 jnYg== X-Forwarded-Encrypted: i=1; AJvYcCWr63gOh+REO35V70GWYKK2lWzVtRBT8MK8oRWis6uWbuPvlWr1y7ZAgkTz9aYon3Y2YA35vhHTOSRq4p8=@vger.kernel.org X-Gm-Message-State: AOJu0YxMgkp3hd5wUAKnIuoHQi2ZvH8MOwzbczmf0fB5xpTBGqzwRch0 j6XcPC/Lvq6rHnJIi5EIpwZOdz8vcBvz+socxmfN7KsX6wBCaC718dHXfImrCQ== X-Gm-Gg: ASbGncvZJyjnNLXAZ2/Wt2HFA2WqnH616R9woVtuzR20lIpaEZb7Rm/ceDvGoYLgWb9 uw3lo6Smh4rxW4fOeYzs4yF4j4TuGnEFx27XWDgEsxhKT+BDT6fv+71QTPj71vmo0VAzzPQE4gS 7lRrWpAtGA9M7dehDHwD8UuRBia3nYhMUkYyZD2WQc8DCM4Ib+bsoUEooJuc4gj9vQdlMyhPWZN LmWTFVFLbjRqX23l9wXU6ly4avzr/XtSbIzHdO8NUMbMh1rwG/GtGKGartvIgc+uWhgBMmtO8Ty qSgqWWBQNJODMx09DABSbzSvZnfV70s6M7Fq+cRVtVvFveWBlutcPu5p2fKaBiqJHrJP6C91SJc 1IAp1DpKIz2meFRkFO8tbzI3ltYy3lbVEPICMmBcjr4GR7N8Z2kHi0VWymOw= X-Google-Smtp-Source: AGHT+IGSyyuPMEa9ur5aJQiYNGUh201mREentuTgFoSL+6iYa1/r7WdugU0gxZJgmxiXoNAAFCxmjA== X-Received: by 2002:a05:6a20:2584:b0:2e5:655c:7f8f with SMTP id adf61e73a8af0-32da83e6319mr5293800637.46.1759934462272; Wed, 08 Oct 2025 07:41:02 -0700 (PDT) Received: from [172.20.10.4] ([117.20.154.54]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-78b01f9daf3sm19043382b3a.8.2025.10.08.07.40.58 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 08 Oct 2025 07:41:01 -0700 (PDT) Message-ID: <7f28937c-121a-4ea8-b66a-9da3be8bccad@gmail.com> Date: Wed, 8 Oct 2025 22:40:57 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH RFC bpf-next 1/3] bpf: report probe fault to BPF stderr To: Menglong Dong , Menglong Dong , Alexei Starovoitov Cc: Alexei Starovoitov , bpf , LKML , linux-trace-kernel , jiang.biao@linux.dev References: <20250927061210.194502-1-menglong.dong@linux.dev> <20250927061210.194502-2-menglong.dong@linux.dev> <3571660.QJadu78ljV@7950hx> Content-Language: en-US From: Leon Hwang In-Reply-To: <3571660.QJadu78ljV@7950hx> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 2025/10/7 14:14, Menglong Dong wrote: > On 2025/10/2 10:03, Alexei Starovoitov wrote: >> On Fri, Sep 26, 2025 at 11:12 PM Menglong Dong wrote: >>> >>> Introduce the function bpf_prog_report_probe_violation(), which is used >>> to report the memory probe fault to the user by the BPF stderr. >>> >>> Signed-off-by: Menglong Dong [...] >> >> Interesting idea, but the above message is not helpful. >> Users cannot decipher a fault_ip within a bpf prog. >> It's just a random number. > > Yeah, I have noticed this too. What useful is the > bpf_stream_dump_stack(), which will print the code > line that trigger the fault. > >> But stepping back... just faults are common in tracing. >> If we start printing them we will just fill the stream to the max, >> but users won't know that the message is there, since no one > > You are right, we definitely can't output this message > to STDERR directly. We can add an extra flag for it, as you > said below. > > Or, maybe we can introduce a enum stream_type, and > the users can subscribe what kind of messages they > want to receive. > >> expects it. arena and lock errors are rare and arena faults >> were specifically requested by folks who develop progs that use arena. >> This one is different. These faults have been around for a long time >> and I don't recall people asking for more verbosity. >> We can add them with an extra flag specified at prog load time, >> but even then. Doesn't feel that useful. > > Generally speaking, users can do invalid checking before > they do the memory reading, such as NULL checking. And > the pointer in function arguments that we hook is initialized > in most case. So the fault is someting that can be prevented. > > I have a BPF tools which is writed for 4.X kernel and kprobe > based BPF is used. Now I'm planing to migrate it to 6.X kernel > and replace bpf_probe_read_kernel() with bpf_core_cast() to > obtain better performance. Then I find that I can't check if the > memory reading is success, which can lead to potential risk. > So my tool will be happy to get such fault event :) > > Leon suggested to add a global errno for each BPF programs, > and I haven't dig deeply on this idea yet. > Yeah, as we discussed, a global errno would be a much more lightweight approach for handling such faults. The idea would look like this: DEFINE_PER_CPU(int, bpf_errno); __bpf_kfunc void bpf_errno_clear(void); __bpf_kfunc void bpf_errno_set(int errno); __bpf_kfunc int bpf_errno_get(void); When a fault occurs, the kernel can simply call 'bpf_errno_set(-EFAULT);'. If users want to detect whether a fault happened, they can do: bpf_errno_clear(); header = READ_ONCE(skb->network_header); if (header == 0 && bpf_errno_get() == -EFAULT) /* handle fault */; This way, users can identify faults immediately and handle them gracefully. Furthermore, these kfuncs can be inlined by the verifier, so there would be no runtime function call overhead. Thanks, Leon