From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f46.google.com (mail-wm1-f46.google.com [209.85.128.46]) (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 DEBD415DBC1 for ; Fri, 24 Oct 2025 11:42:52 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.46 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1761306174; cv=none; b=iStZBdwrXcwldW8KeBbE6SPgkw1iV3U6w4KdQYoa93gFPZ3Jfdg+aXNLPyffkF9NtJr3xabZwS/q7dldNaBiGD5CZCOc7HcRpohMWK8eDo6GYO6WgG3N2FPReVZCFnWcH4JjTasEMbsb5XOyxZg+u8gfcpWECQ0zlD/VU7h+Np4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1761306174; c=relaxed/simple; bh=BSa+n0RHtBRMZcEWJek59r2Jv4nIb4dvimkE2lkcU5M=; h=From:Date:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=PPwJjFuG0eEhJpbtx5ywTQwnf6BXbJrMHSbdiNjABMcawX0aiC520MxAr034rXoA7c0o+iccszIZxnvbXPpvYiGwL6sHuJqZfQTu5E3URY2jXby3Nr5MwfpS4uuo8gcecaKYyM5BEM8C3pW3M96lKovd7oNuw/3wiloBWCSbwCw= 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=So529veH; arc=none smtp.client-ip=209.85.128.46 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="So529veH" Received: by mail-wm1-f46.google.com with SMTP id 5b1f17b1804b1-471b80b994bso27696415e9.3 for ; Fri, 24 Oct 2025 04:42:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1761306171; x=1761910971; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:date:from:from:to:cc:subject:date:message-id:reply-to; bh=dYSOpLWf0KKSMlI5IP80glPUH7vqI7+Tr3W3w2SASQg=; b=So529veHjy38XsuZYlINGFEIeO+Brf0ht4wtROg2ZPr06pn5Tj2zewjpGottF/qylw NLSS/MzfNONDrBHY1aTs7s0xiwj1EYeC2Aslh+Wh6AO3oqE58oNquIxD8IuYVoZMxP3K txdHsSmh4st4vr+09ULp3XpJO7B7wjBmQrYX6A318YtmY3JSj/LAWgePlGL/weDcceIe /FGmRjVc7vXLMMX+ruo78ScnrN2Ui8QpNeZ6bgUTJAoiMwmpurGLHjml6CSuVx1kE7jm ynV0kbTs3hc/TE9dqBGnfliZ6uGf2b9qiqyyXUHKyCQhTYC6FkLuMLASkDdEYx10tHbs sjVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1761306171; x=1761910971; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:date:from:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=dYSOpLWf0KKSMlI5IP80glPUH7vqI7+Tr3W3w2SASQg=; b=iTTsm4y07y+Rvw5HA0lj8HW0pqWdplOuKI6LvM4FiTk2+hP2baWvTqvQvVe0TSABJL I/Qz7swrIhT/ohse7Yzysomkk2+S4FZP8/r90sy6gbr7mKB2zUmqhQPKDgwc2UlsHcEu +ItBRzT3r6MXFLRRMfdO9ba8dxTEkEHPX0mQd56dH6PYnWR2Mf33jEsMFKWgGXYe6W2D 2otQL+7lftesHQX9QdLdLpGBCI9KcegMJHW2+z0Ju0ysERzIa5LzpAGsB31uB6y1bQKU ZwNNiJyNPBgfKupN09E9fSZOcNgBJqvbxT0py0DEPBMc0a7gAvFtRMyoDRwjnPCuPtXJ Cw1Q== X-Forwarded-Encrypted: i=1; AJvYcCUi+8HkrAmXw+Tr2Aol8y2s5u9e90Pr833p6aZAb5jy2JptWNg8b3TISxB0ZKKibhEcT1+F+b1bltzvIcnbgvkpUGs=@vger.kernel.org X-Gm-Message-State: AOJu0YzhVTggqJJ/h6uLcXJN2Va4IzXHqlPXBdlZX5X2tawKOSGKgZ02 041CmbjHdJDNe4BzoKk1Ngcj1IElahTpZMkQc9G6r5VKdqlDhFi3H1mI X-Gm-Gg: ASbGncsN4FWvKYAmIg9GgClPhxuvZoQsWoWkeXP5+/WYdwwLsoJ6Jilh7AACnI+rDuD vLTCBI7syZIOw5pd/wCInfiDzM46keib2Kp4Btx2Al/q/EEjDJiuahJZqoev8h2sitwVZf0xCJC lSEPHRYHz9GHTyPS/SHl69+QWu7UxCy5FuX0B6XZm0ek6DqaXzfB3/DFePc4b8mO7pKfZ7saPns xJDmPPVglDgFAI50oqGvIzwvix3uveoGI///xCuAyAlyM2Smd1YB2r3SO7asFQyemZa56mBdfAW Epu/8MLJNjYza0rG1rQHT6/K3L0/42mZjQCNNC98MdUH9Xbp+v3sFU47S9CeNrezPhtuafEvzsl YsnVzv6usjvR4ihaektnSUaPbO7dYE2Abo0eAFkCUNzWX03UcIUnB5rbR4L0r X-Google-Smtp-Source: AGHT+IFIUsw6TyOf0Ycr6/XFbQuoCfiAQ0G0a0V5A5EXttedAZG47NAs1I680hPCSVoLr15fOIrshA== X-Received: by 2002:a05:600c:3e12:b0:45b:7d77:b592 with SMTP id 5b1f17b1804b1-471178a74demr202375115e9.12.1761306171044; Fri, 24 Oct 2025 04:42:51 -0700 (PDT) Received: from krava ([2a02:8308:a00c:e200::b44f]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-429898ecadbsm9269121f8f.45.2025.10.24.04.42.50 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 24 Oct 2025 04:42:50 -0700 (PDT) From: Jiri Olsa X-Google-Original-From: Jiri Olsa Date: Fri, 24 Oct 2025 13:42:48 +0200 To: Song Liu Cc: bpf@vger.kernel.org, linux-trace-kernel@vger.kernel.org, live-patching@vger.kernel.org, ast@kernel.org, daniel@iogearbox.net, andrii@kernel.org, rostedt@goodmis.org, andrey.grodzovsky@crowdstrike.com, mhiramat@kernel.org, kernel-team@meta.com, stable@vger.kernel.org Subject: Re: [PATCH bpf-next 1/3] ftrace: Fix BPF fexit with livepatch Message-ID: References: <20251024071257.3956031-1-song@kernel.org> <20251024071257.3956031-2-song@kernel.org> Precedence: bulk X-Mailing-List: linux-trace-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20251024071257.3956031-2-song@kernel.org> On Fri, Oct 24, 2025 at 12:12:55AM -0700, Song Liu wrote: > When livepatch is attached to the same function as bpf trampoline with > a fexit program, bpf trampoline code calls register_ftrace_direct() > twice. The first time will fail with -EAGAIN, and the second time it > will succeed. This requires register_ftrace_direct() to unregister > the address on the first attempt. Otherwise, the bpf trampoline cannot > attach. Here is an easy way to reproduce this issue: > > insmod samples/livepatch/livepatch-sample.ko > bpftrace -e 'fexit:cmdline_proc_show {}' > ERROR: Unable to attach probe: fexit:vmlinux:cmdline_proc_show... > > Fix this by cleaning up the hash when register_ftrace_function_nolock hits > errors. > > Fixes: d05cb470663a ("ftrace: Fix modification of direct_function hash while in use") > Cc: stable@vger.kernel.org # v6.6+ > Reported-by: Andrey Grodzovsky > Closes: https://lore.kernel.org/live-patching/c5058315a39d4615b333e485893345be@crowdstrike.com/ > Cc: Steven Rostedt (Google) > Cc: Masami Hiramatsu (Google) > Acked-and-tested-by: Andrey Grodzovsky > Signed-off-by: Song Liu > --- > kernel/trace/ftrace.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c > index 42bd2ba68a82..7f432775a6b5 100644 > --- a/kernel/trace/ftrace.c > +++ b/kernel/trace/ftrace.c > @@ -6048,6 +6048,8 @@ int register_ftrace_direct(struct ftrace_ops *ops, unsigned long addr) > ops->direct_call = addr; > > err = register_ftrace_function_nolock(ops); > + if (err) > + remove_direct_functions_hash(hash, addr); should this be handled by the caller of the register_ftrace_direct? fops->hash is updated by ftrace_set_filter_ip in register_fentry seems like it's should be caller responsibility, also you could do that just for (err == -EAGAIN) case to address the use case directly jirka > > out_unlock: > mutex_unlock(&direct_mutex); > -- > 2.47.3 > >