From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7FB26C5479D for ; Tue, 27 Dec 2022 20:39:40 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232347AbiL0UjL (ORCPT ); Tue, 27 Dec 2022 15:39:11 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48054 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232266AbiL0UiY (ORCPT ); Tue, 27 Dec 2022 15:38:24 -0500 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9E120E099; Tue, 27 Dec 2022 12:34:35 -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 dfw.source.kernel.org (Postfix) with ESMTPS id CB8E06123B; Tue, 27 Dec 2022 20:34:22 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id EAF69C433F2; Tue, 27 Dec 2022 20:34:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1672173262; bh=Wm82mcz0e6ebaGdyvWMP+jh49P0bE1bsWiNWLYfcrF8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=banj49NilK1A3SL6Wo+jZbhAOTzOpRepYeJaO2aOofQipnGJ5tEQgoWrEB6HouCjK 0JHXucWk1mZQDvhx+GP3jyvdcBUW5HNKKR/9UXS50Fbek4eRdbJ7Cy4wUfoG3xVosj PBW3RIb1WX2AIauIh2o1MvtE4qD9Z/QgjdNSi9/OYQgQXdwKB4hwoSbMWEGGK5wJuD qYZWMkk7u2rUSFRvmP1gzM5qr8XSLu3q1fc0HAGf5xpTfyQNeYC+/1KKjd7HJ1ewpg moTTSr9fkHoUQ+oCTn1v5NvmbhYl3lC6S/7zsq/+uQCTD6YIobqYzS/5PvTB7tVBpR Y59YXL201+flw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: wuqiang , Solar Designer , Masami Hiramatsu , Sasha Levin , rostedt@goodmis.org, naveen.n.rao@linux.ibm.com, anil.s.keshavamurthy@intel.com, davem@davemloft.net, corbet@lwn.net, linux-doc@vger.kernel.org Subject: [PATCH AUTOSEL 6.0 24/27] kprobes: kretprobe events missing on 2-core KVM guest Date: Tue, 27 Dec 2022 15:33:39 -0500 Message-Id: <20221227203342.1213918-24-sashal@kernel.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20221227203342.1213918-1-sashal@kernel.org> References: <20221227203342.1213918-1-sashal@kernel.org> MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: wuqiang [ Upstream commit 3b7ddab8a19aefc768f345fd3782af35b4a68d9b ] Default value of maxactive is set as num_possible_cpus() for nonpreemptable systems. For a 2-core system, only 2 kretprobe instances would be allocated in default, then these 2 instances for execve kretprobe are very likely to be used up with a pipelined command. Here's the testcase: a shell script was added to crontab, and the content of the script is: #!/bin/sh do_something_magic `tr -dc a-z < /dev/urandom | head -c 10` cron will trigger a series of program executions (4 times every hour). Then events loss would be noticed normally after 3-4 hours of testings. The issue is caused by a burst of series of execve requests. The best number of kretprobe instances could be different case by case, and should be user's duty to determine, but num_possible_cpus() as the default value is inadequate especially for systems with small number of cpus. This patch enables the logic for preemption as default, thus increases the minimum of maxactive to 10 for nonpreemptable systems. Link: https://lore.kernel.org/all/20221110081502.492289-1-wuqiang.matt@bytedance.com/ Signed-off-by: wuqiang Reviewed-by: Solar Designer Acked-by: Masami Hiramatsu (Google) Signed-off-by: Masami Hiramatsu (Google) Signed-off-by: Sasha Levin --- Documentation/trace/kprobes.rst | 3 +-- kernel/kprobes.c | 8 ++------ 2 files changed, 3 insertions(+), 8 deletions(-) diff --git a/Documentation/trace/kprobes.rst b/Documentation/trace/kprobes.rst index f318bceda1e6..97d086b23ce8 100644 --- a/Documentation/trace/kprobes.rst +++ b/Documentation/trace/kprobes.rst @@ -131,8 +131,7 @@ For example, if the function is non-recursive and is called with a spinlock held, maxactive = 1 should be enough. If the function is non-recursive and can never relinquish the CPU (e.g., via a semaphore or preemption), NR_CPUS should be enough. If maxactive <= 0, it is -set to a default value. If CONFIG_PREEMPT is enabled, the default -is max(10, 2*NR_CPUS). Otherwise, the default is NR_CPUS. +set to a default value: max(10, 2*NR_CPUS). It's not a disaster if you set maxactive too low; you'll just miss some probes. In the kretprobe struct, the nmissed field is set to diff --git a/kernel/kprobes.c b/kernel/kprobes.c index 6d2a8623ec7b..f2413aae1aba 100644 --- a/kernel/kprobes.c +++ b/kernel/kprobes.c @@ -2209,13 +2209,9 @@ int register_kretprobe(struct kretprobe *rp) rp->kp.post_handler = NULL; /* Pre-allocate memory for max kretprobe instances */ - if (rp->maxactive <= 0) { -#ifdef CONFIG_PREEMPTION + if (rp->maxactive <= 0) rp->maxactive = max_t(unsigned int, 10, 2*num_possible_cpus()); -#else - rp->maxactive = num_possible_cpus(); -#endif - } + #ifdef CONFIG_KRETPROBE_ON_RETHOOK rp->rh = rethook_alloc((void *)rp, kretprobe_rethook_handler); if (!rp->rh) -- 2.35.1