From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f169.google.com (mail-pl1-f169.google.com [209.85.214.169]) (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 F0864381EB0 for ; Tue, 18 Aug 2026 23:59:21 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.169 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787097563; cv=none; b=PdxhvzLPDW5SexfK/KPbmRf/1TQvVu3EXgvqYYzqnLQLLQ41htUHt3PEU7SvKBLcyffxldHUZ1jcyLDFSNihpU02FSimYMcTEaHv7agDj2xtelRpL6KYiWK2jlblvj3a+iUtkeyBK45CK2ofubiNjWsDZN3y5tLv7Qj/8YAsDCI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787097563; c=relaxed/simple; bh=3/FC3+rTB7zenyYUb/SAoT6ao55r7Msw4PLNzKlY1/I=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=YJu24S5aGjjTnzmAwKOotPdHRaopVdEN6EYQYn0+Pxy3RxXOHyNzjMBNR/JqnMz6nJC68lujHKmv/+zMaRxYgaT/MM6fCuVo09lIqHtK9APUOAWs3szBLxAYHRxJtEcZhnfD2OBXaxWHSg9rbjEUo1RnKQzB4+zwKPfsgZuL3bw= 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=AvGalExL; arc=none smtp.client-ip=209.85.214.169 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="AvGalExL" Received: by mail-pl1-f169.google.com with SMTP id d9443c01a7336-2ccf2360620so3037755ad.3 for ; Tue, 18 Aug 2026 16:59:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1787097561; x=1787702361; darn=vger.kernel.org; h=in-reply-to:content-disposition:content-type:mime-version :references:message-id:subject:cc:to:from:date:from:to:cc:subject :date:message-id:reply-to:content-type; bh=9UA11QdsDBQZZwlQ8Rx/R/X7VYyb6gM0uXTt1nPuef8=; b=AvGalExL57zB9dAd6e/zsohPJQ4EjxjlxdyXQ35qSFnq6v+xVESozfqfHbSWZc+UQc rILD5x1YHKhM+izDD8POVAwJ40uIjHA2uDwYoBYagrxtS6UIdY6bjBeE1Nht4vOIAxWt 3ILnmro/pldKVNBIggkZtXV+Xxar1l17naq99FSE+dJc9gmg+YnyB37c5NEKO/VMWKb5 qmauLF2iC4LlJPCNWpXAPgEf0poz8gROp3vXR2IBir//40deagwXupiw2EZbKkRCx/9j T1XmMABCtiZGzL7Dau7QC5h/Yuqgjbu41rCMSpm68ohfwcDzhDevediqrO5T4/LKplUa zTAQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1787097561; x=1787702361; h=in-reply-to:content-disposition:content-type:mime-version :references:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=9UA11QdsDBQZZwlQ8Rx/R/X7VYyb6gM0uXTt1nPuef8=; b=FtiB3LlF0kWN2bCni+I3VkUU8HUNcULoWSraz1Q8/LPu1VjbYtkUrpOkZlmKvG8+M4 njQTaZM/4w0K0vLHjvZgd61bkne+Rd91vyu5vAXYE3FiYAbf/4jEYLdQyPrrceQRk7OW EYpGReOhnBmc9zezmpBJNltNiDc7KzuwZz2gXAuGbVClT3jpk+bf5w0WbglhE9HDBKmK /VrrNu9wBmdMuPutIZ1VBmYmwJ0+eS676Tx0i9uSqx+t7R6RnTflST/vi8/ZCLlmzc5B R8gzWpqJoE4sQnhbsMTgdn0Z3Owi7Vw8o0zRK8OVLTlxN89e8c4XzBeLQWKCAbHOBjJa TzEg== X-Forwarded-Encrypted: i=1; AHgh+RoRHVOPbOrmev6puHzHbSNwiDq35/O7ia+D3/qovE1Jj5hoFjRNAt2ygpFzA2Gc0NsuH3c3zyU8qruBttc=@vger.kernel.org X-Gm-Message-State: AOJu0Yxe/y5oQLIaMromI9JeIpX2uxjGan3Z54NXbdMoHQZzm1BgahIk 2VCXGd8RxuHjhsV/nUjKB0WtKITK4HSLFMjCQC/ekpkrSmWrK1+9RWpH X-Gm-Gg: AR+sD13veGUk7IifMi1BByr8OsdQSv/1dkNqhyd8YKDkKStI0lIgT6FWkw/C8lRV43V rWiBiF82r0gswvOxlL5IPeRZIzSkUN2CXlvijnYd7K8z4LpL/DPRnpgOrPCJR6cHehTNUY0kq5u 7trA3ODqKW+iW8hb7dgE6KRCahmeFZRTx6yZNTELJmL8cfAwATdlYxlxasWlyS6LCbLdDPkuWd2 nnvkYcHMRqyYajOsOscKhgRLl6G/10aY+dvZx7+Q69K1DCm7CKW2vY7WMrNYpLX6EbOJxiFlXqU +3f5dI/OsW5dN/+STKcrYAN4pom4wA2ADtpQkjjeMt5qC5WRzCrIQ+oqVy1Y+e3pVV/lVvHXB1I ifveAjlp7BKS+GLUtkLlIWxGrHH9I+3qaCbipK/PD7SFrRcKbBx9e4MoVFApY1hY1DFFukhB5Cd OjxRH5BWiOv2KLES32LbYkqmeiTn+hLu4LSBkV3L1kXE1zNk89azVVcT2YxSX6AtacTpxV4t3p9 w1+FltUKrfl0cAfMr4= X-Received: by 2002:a17:90b:4a4b:b0:38f:240d:b857 with SMTP id 98e67ed59e1d1-39580a4d03cmr971369a91.2.1787097561159; Tue, 18 Aug 2026 16:59:21 -0700 (PDT) Received: from devvm16600.scu0.facebook.com ([2a03:2880:9ff:73::]) by smtp.gmail.com with ESMTPSA id a92af1059eb24-1416ae5f1ffsm1121775c88.13.2026.08.18.16.59.19 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 18 Aug 2026 16:59:20 -0700 (PDT) Date: Tue, 18 Aug 2026 16:59:17 -0700 From: Ziyang Men To: Tejun Heo Cc: Johannes Weiner , Michal =?iso-8859-1?Q?Koutn=FD?= , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , Eduard Zingerman , Kumar Kartikeya Dwivedi , Shuah Khan , kernel-team@meta.com, Ingo Molnar , Peter Zijlstra , Vincent Guittot , Ben Segall , Dietmar Eggemann , Martin KaFai Lau , Song Liu , Yonghong Song , Jiri Olsa , Emil Tsalapatis , Roman Gushchin , Shakeel Butt , JP Kobryn , bpf@vger.kernel.org, cgroups@vger.kernel.org, linux-kselftest@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2 1/2] cgroup: add BPF kfuncs to read a cpu cgroup's stats Message-ID: References: <20260818002450.3071325-1-ziyang.meme@gmail.com> <20260818002450.3071325-2-ziyang.meme@gmail.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: Hi Tejun, On Tue, Aug 18, 2026 at 12:47:11PM -1000, Tejun Heo wrote: >On Tue, Aug 18, 2026 at 03:44:36PM -0700, Ziyang Men wrote: >> > > +BTF_KFUNCS_START(bpf_rstat_common_kfunc_ids) >> > > +BTF_ID_FLAGS(func, bpf_css_flush_rstat, KF_SLEEPABLE) >> > > +BTF_ID_FLAGS(func, bpf_cgroup_base_stat, KF_SLEEPABLE) >> > >> > Why are these SLEEPABLE? >> > >> >> The css_rstat_flush() calls might_sleep() and cond_resched(). > >I see. > >> The bpf_cgroup_base_stat() takes an rstat spinlock_t, which can sleep on >> PREEMPT_RT. > >Is this actually required? This doesn't really make sense to me. Shouldn't >what SLEEPABLE mean change on RT kernels instead? Oh sorry, I didn't notice that. I might be wrong: this function calls the cputime_adjust(), which in turn acquires raw_spin_lock_irqsave(), so there would be NMI deadlock in the perf_event program. The __css_rstat_lock() take the spin_lock_irq() as well. So maybe a SLEEPABLE tag is still necessary? Please let me know your concerns. Thanks! Best, Ziyang > >Thanks. > >-- >tejun