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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4D7E2C25B74 for ; Sun, 2 Jun 2024 11:36:12 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5F58F6B009A; Sun, 2 Jun 2024 07:36:11 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 57E576B009E; Sun, 2 Jun 2024 07:36:11 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3F7386B00A0; Sun, 2 Jun 2024 07:36:11 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 1F4396B009A for ; Sun, 2 Jun 2024 07:36:11 -0400 (EDT) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 7D7D11A04DD for ; Sun, 2 Jun 2024 11:36:10 +0000 (UTC) X-FDA: 82185744900.12.E8767AD Received: from mail-ed1-f47.google.com (mail-ed1-f47.google.com [209.85.208.47]) by imf11.hostedemail.com (Postfix) with ESMTP id 7680F4000A for ; Sun, 2 Jun 2024 11:36:08 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=J4PaOCGJ; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf11.hostedemail.com: domain of richard.weiyang@gmail.com designates 209.85.208.47 as permitted sender) smtp.mailfrom=richard.weiyang@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1717328168; h=from:from:sender:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=EJnUfRpYDIz1jm/Tu3w6AMIdtyuVPoIRBKnHAV8Af8U=; b=TX3YVB6wSajmySQOFNHc2V56ST8y6s5EGDVY8jvCHZshdLTCap06Rmhkj8HZaj9xoacTyn vUUj/FwrksVApBP2NG8fl651NH5pkuO1Iz9Zl7SjRB3cc/gxsi9C3LoD9FMUSueaw/D6vD EmcJu+t5yihfYpUdL3jR2yZODTUs00Q= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=J4PaOCGJ; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf11.hostedemail.com: domain of richard.weiyang@gmail.com designates 209.85.208.47 as permitted sender) smtp.mailfrom=richard.weiyang@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1717328168; a=rsa-sha256; cv=none; b=4GNSz8SJiAMM69RfebvMDpwoRtB8j8opCnXDEZs/LIjWSCoqKTXr8bLyfJI9xW7+TN99yN LtxQkjx6N7YPBNOgtgCfrdNXpPz5tA9o/hCE/Etth4ahUrgIMyxVzt56oH5Sszs9MWKCNN O26PYBEG1dxPO+R6GDk+2Abm4ahdi/k= Received: by mail-ed1-f47.google.com with SMTP id 4fb4d7f45d1cf-57a1fe6392eso3878048a12.0 for ; Sun, 02 Jun 2024 04:36:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1717328167; x=1717932967; darn=kvack.org; h=user-agent:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:reply-to:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=EJnUfRpYDIz1jm/Tu3w6AMIdtyuVPoIRBKnHAV8Af8U=; b=J4PaOCGJqL5sJ1cF2rzVAsMhW+1JELEmWwCkNauAKtGIhSkVyeG+lYUMRTqSh+cN+z B4QdnLbYUtYN4EHuL1afrdUdOzHW9lZBBMlEFrIBNceL3feBxey8jO1/XdT88rgu7wZI 2XIdk5mwWeSkTCPSLyA0KDIR1a+d03MVKR28EjbJN/7/3NevoZNQcYbh35Mav4na33rC L+YrwgabeH1hFW+r5vx93TsrWqnR1ESj9ErJ17TBEkXbzsxOxfz6wN29wcUtKS1I+bCm A9DxYZfs32lvQV7WcoKndpV+AMyfGIf9I4s10cKyCjn9IDk1FBaID+zdyKb9Z9RRDix8 nowg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1717328167; x=1717932967; h=user-agent:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:reply-to:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=EJnUfRpYDIz1jm/Tu3w6AMIdtyuVPoIRBKnHAV8Af8U=; b=K6sE/LhbrG1WbBj5PzmezHtuyhYxVsII1sJHciEO+oCJcU7pTsiKNpgZpT1K+hvc77 G7kjN+hz2LO2vArwzBOtCHZY5rPlrViTdFNGwZ2roS6t+j5isqXCIQDrdInZcDTOvRar pCCTkJ4HT13C99HOFPwafP9z+6e1N/fseLy6v8hcFhYKjalVybCItMA8z4o4UaFwPRpf i9d0yO4zesDRyVwpLblO08v35Ptt3I5P1/v9teP6I8E9KMMP88ttQAaHQyRlb5LLbHcY 91PtGVn3bodFJ+FODnGRVcQF6fGoPHc14zBrrE4GVy2u7Rvn9f5g3HdzF13n+wWuUURb EWng== X-Forwarded-Encrypted: i=1; AJvYcCURcHtbX9bKic6KpbGYAEtWFSTi9EMDtkG/8xwu85AG+Kwa5TyeEpNsUrehh5PmOwlAi+KC7ZSzfxcP0ExE7g8ldZI= X-Gm-Message-State: AOJu0Yx92XNtIjfUcjg5lwA0nXILQEeKiZZr/qTJ5vldBthUXjO9vbc8 Yn1yYoY7qz4tNbHLbiIEpO0rJAaV8sSY2a3h2h9IC9B9wZ8ArBPm X-Google-Smtp-Source: AGHT+IGjoFBqQ+UJLG3MIUhLGnmrgpKYVEVPilTn/+DpSFGXEUPnSuIltG8U2ylx3xnjxCsjWVdjiw== X-Received: by 2002:a17:906:1455:b0:a69:2fc:8340 with SMTP id a640c23a62f3a-a6902fc841bmr32663866b.73.1717328166465; Sun, 02 Jun 2024 04:36:06 -0700 (PDT) Received: from localhost ([185.92.221.13]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-a68b59e925csm190030966b.220.2024.06.02.04.36.05 (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Sun, 02 Jun 2024 04:36:05 -0700 (PDT) Date: Sun, 2 Jun 2024 11:36:04 +0000 From: Wei Yang To: Vlastimil Babka , g@master.kvack.org Cc: Akinobu Mita , Christoph Lameter , David Rientjes , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , "Naveen N. Rao" , Anil S Keshavamurthy , "David S. Miller" , Masami Hiramatsu , Steven Rostedt , Mark Rutland , Jiri Olsa , Roman Gushchin , Hyeonggon Yoo <42.hyeyoo@gmail.com>, linux-kernel@vger.kernel.org, linux-mm@kvack.org, bpf@vger.kernel.org, linux-trace-kernel@vger.kernel.org Subject: Re: [PATCH RFC 0/4] static key support for error injection functions Message-ID: <20240602113604.pn74o7g2lazr7ugk@master> Reply-To: Wei Yang References: <20240531-fault-injection-statickeys-v1-0-a513fd0a9614@suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20240531-fault-injection-statickeys-v1-0-a513fd0a9614@suse.cz> User-Agent: NeoMutt/20170113 (1.7.2) X-Rspamd-Queue-Id: 7680F4000A X-Stat-Signature: hcpcyu7ck5hin5nuftftjbh1dhq63qda X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1717328168-200132 X-HE-Meta: U2FsdGVkX1+ATZ3RR/enuucnyTMWOINWhkTFCVgEfJNA4wzxOFOsA7swDtiv+GZTpdkUjLhqRKCZs4jxKiyliGw3p40Y/EVGy0ZszlH235Sdi7Z5GcBr2X0mFn8XmUmx8cGyaLm3rR0U5SQc+V7agJYNAL1Tkox1CCvlCU5Sie0PYRg17nK92fHiQC8Odalrl5Jynmjwf87/4nYpJPkXm53mnqDhdV+PYPuV3yulkc6big35LljbwsyiQYY7E+Oj+CK3nI1tgibWHeslIfMh+eMV8r45qc3WeGapx+IOVl5tpBarhgG/oXi62jeixAZmbiJbXcb373GKY0zNnYcFzk9yv0/NK+JgCH8r+wiJ/PkHWDugZHf7h0j/WNwL7yHmdTfb1E0krvd3845atnBRme2LxCKs9pA8Yjt1EVKM0Z3xFik9938AksTfGzZZTyQ4Ut1pS41iRCyukzxe8prwUz4ovSQ9XmR463ETzbPRKw4Ads90fdp/+L2wCMzMlhChs7u6m4oysnvWnSbvPNnNNN834Nv0kX+mVymKAUzPauKG2XoF9EavrQdg+ltFb9NmAxN+Z5J5d70Z1dpmLZkgJDnp4CJiHlpSKmI1xEPHtZy6kOKZVRlTLE06Ugy4aKHsqp/MjSq7ss3Bp13DqGo06890nU5vqL2IIpFtP91MjkFAjtIFsid3KhFQjvSco4bkyAQm7WLe+W7Gdb1XE+DIh//myAeGRPIJX0D8sl2/N4FKxCz8aGmBqT9KwBAPkjeyespzE0thDIcd+qSq9SzJ5VnUoVQg24dcG5xZOo2/kmEXtMuOonPE/keBMdHuwSVkwK5d1cV1DmrKpZd0FOBvYbjc8D8qMz/0Sv+y4pYIUoQ8+pkDmnOrlQ8VVVP6EcBYqyNJbu8fX6e3yZLXWPneVHZfBjAJfHAGGRnd0qkaN+x6ktNrodRIMQtjT+kUeqNXgcNFaNzT09mDw5LrnC4 sa5qq0+4 VQ4LYD8FzExEE+ZMrdgTKfEfHAZlA5SEu3o3M4fRQkpRq0GWzMfsGOgrvBVaVXvg0PuUXl5XTlGJ70gHBqRmcumd3VuBs78kKqERc9DVfxGVC0UEyS+NyNCRRnG6Qo60cVOfq3g9J9mOf3eWYr2NFvOc4uP+HP9+467I2QP1tAgSD6n72ESglKggSBzD4xHJq+tG6rIdgr9iTbd+K6vB9b7/pU+PmhritBUMM9Ef8ZmVvrQsWD5t2lbWQJuRC+HzpNBkqtt2gjJcHoOjEOjPbPr66yUzSGsEpTCJrDaQsSQ48W7N8fmib6clhSn6enD2xZXCh9b9O4LcGy19NZfSWnQBFXZnKr1E6aTGSZpSRcyOe79gSm6xmsPTynjoijm//xodVVfKw7xcU52WeMLFnHAc+BcuguaVjJJaBE5Sxz0COV1re6++8kMVybPYV0+ApDWt3Lv4h32rIG+iapUOYK2+qPeuVlmEb7ik854J3SSgFTaUe99IkhtnPbd3GzGAGw+YjianfhfDH393CJHRHQU35n5yVd6L1JNDXWfrcMB+SwYCyZg/MlaQRzlpShVIB9W3KuQcTuriuzepRB1ETXjfleOpCg1mJi60QXhjqsQvOPB3A7mq+Dw9SaSze55KNbPDebUhg4t7zW6iloXYepsHjBVZUrXmayHnNtbRtq3ysl4NitvVzERZV2qdeUI/56a26Veh6a6XFs13pnSJY6GQSZHZ2UIF1+Nj/qQ3U4vpFJPBdApLGODcXDw== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Fri, May 31, 2024 at 11:33:31AM +0200, Vlastimil Babka wrote: >Incomplete, help needed from ftrace/kprobe and bpf folks. > >As previously mentioned by myself [1] and others [2] the functions >designed for error injection can bring visible overhead in fastpaths >such as slab or page allocation, because even if nothing hooks into them >at a given moment, they are noninline function calls regardless of >CONFIG_ options since commits 4f6923fbb352 ("mm: make should_failslab >always available for fault injection") and af3b854492f3 >("mm/page_alloc.c: allow error injection"). > >Live patching their callsites has been also suggested in both [1] and >[2] threads, and this is an attempt to do that with static keys that >guard the call sites. When disabled, the error injection functions still >exist and are noinline, but are not being called. Any of the existing >mechanisms that can inject errors should make sure to enable the >respective static key. I have added that support to some of them but >need help with the others. > >- the legacy fault injection, i.e. CONFIG_FAILSLAB and > CONFIG_FAIL_PAGE_ALLOC is handled in Patch 1, and can be passed the > address of the static key if it exists. The key will be activated if the > fault injection probability becomes non-zero, and deactivated in the > opposite transition. This also removes the overhead of the evaluation > (on top of the noninline function call) when these mechanisms are > configured in the kernel but unused at the moment. > >- the generic error injection using kretprobes with > override_function_with_return is handled in patch 2. The > ALLOW_ERROR_INJECTION() annotation is extended so that static key > address can be passed, and the framework controls it when error > injection is enabled or disabled in debugfs for the function. > >There are two more users I know of but am not familiar enough to fix up >myself. I hope people that are more familiar can help me here. > >- ftrace seems to be using override_function_with_return from > #define ftrace_override_function_with_return but I found no place > where the latter is used. I assume it might be hidden behind more > macro magic? But the point is if ftrace can be instructed to act like > an error injection, it would also have to use some form of metadata > (from patch 2 presumably?) to get to the static key and control it. > > If ftrace can only observe the function being called, maybe it > wouldn't be wrong to just observe nothing if the static key isn't > enabled because nobody is doing the fault injection? > >- bpftrace, as can be seen from the example in commit 4f6923fbb352 > description. I suppose bpf is already aware what functions the > currently loaded bpf programs hook into, so that it could look up the > static key and control it. Maybe using again the metadata from patch 2, > or extending its own, as I've noticed there's e.g. BTF_ID(func, > should_failslab) > >Now I realize maybe handling this at the k(ret)probe level would be >sufficient for all cases except the legacy fault injection from Patch 1? >Also wanted to note that by AFAIU by using the static_key_slow_dec/inc >API (as done in patches 1/2) should allow all mechanisms to coexist >naturally without fighting each other on the static key state, and also >handle the reference count for e.g. active probes or bpf programs if >there's no similar internal mechanism. > >Patches 3 and 4 implement the static keys for the two mm fault injection >sites in slab and page allocators. For a quick demonstration I've run a >VM and the simple test from [1] that stresses the slab allocator and got I took a look into [1] and I see some data like "1.43% plus the overhead in its caller", but not clearly find which test cases are. Sorry for my unfamiliarity, would you mind giving more words on the cases? >this time before the series: > >real 0m8.349s >user 0m0.694s >sys 0m7.648s > >with perf showing > > 0.61% nonexistent [kernel.kallsyms] [k] should_failslab.constprop.0 > 0.00% nonexistent [kernel.kallsyms] [k] should_fail_alloc_page ▒ > >And after the series > >real 0m7.924s >user 0m0.727s >sys 0m7.191s > Maybe add the percentage here would be more helpful. >and the functions gone from perf report. > >There might be other such fault injection callsites in hotpaths of other >subsystems but I didn't search for them at this point. > >[1] https://lore.kernel.org/all/6d5bb852-8703-4abf-a52b-90816bccbd7f@suse.cz/ >[2] https://lore.kernel.org/all/3j5d3p22ssv7xoaghzraa7crcfih3h2qqjlhmjppbp6f42pg2t@kg7qoicog5ye/ > >Signed-off-by: Vlastimil Babka >--- >Vlastimil Babka (4): > fault-inject: add support for static keys around fault injection sites > error-injection: support static keys around injectable functions > mm, slab: add static key for should_failslab() > mm, page_alloc: add static key for should_fail_alloc_page() > > include/asm-generic/error-injection.h | 13 ++++++++++- > include/asm-generic/vmlinux.lds.h | 2 +- > include/linux/error-injection.h | 9 +++++--- > include/linux/fault-inject.h | 7 +++++- > kernel/fail_function.c | 22 +++++++++++++++--- > lib/error-inject.c | 6 ++++- > lib/fault-inject.c | 43 ++++++++++++++++++++++++++++++++++- > mm/fail_page_alloc.c | 3 ++- > mm/failslab.c | 2 +- > mm/internal.h | 2 ++ > mm/page_alloc.c | 11 ++++++--- > mm/slab.h | 3 +++ > mm/slub.c | 10 +++++--- > 13 files changed, 114 insertions(+), 19 deletions(-) >--- >base-commit: 1613e604df0cd359cf2a7fbd9be7a0bcfacfabd0 >change-id: 20240530-fault-injection-statickeys-66b7222e91b7 > >Best regards, >-- >Vlastimil Babka > -- Wei Yang Help you, Help me