From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm2-f1.google.com (mail-wm2-f1.google.com [74.125.225.129]) (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 B5A3F3403E9 for ; Wed, 8 Jul 2026 03:12:30 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.225.129 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783480352; cv=none; b=G4wGC685b/J9ZyDhumuNrbSsstmKiCmsK0wVqwarTYUAJ6N6ABm7+szGXcXy1SqZvgyiMOhLSjTMy/M/+u6vmRCHGdbConoIT7ssx5zycKUrvOIPDNyUxs44Gv8kUZFFsyAU/jk7dlJNnxDGxUSuXvg1hgHJVFysn0ViDKvNzGI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783480352; c=relaxed/simple; bh=Pfob3D8mbkTTmUhLmKjlXVr2c00IRc98rAq6J6IGM8w=; h=Mime-Version:Content-Type:Date:Message-Id:Cc:Subject:From:To: References:In-Reply-To; b=AD2ZZZ4PO7ie4Si9xwcVc1nyq/7uhvEELlY1eDeeJj7lt1j7Lkb9zlk/rBuxKr2lcx1CjHwdE2JOtfWYWqmYdhCajGQ3hNsQybW4zf5fkjnoZJ/IgMv1B/Nws73dEX0WVwStEQCS0jlBiDJdIDqEeE6MgMZf7KOMPO7ffCQcg6Y= 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=k/Fkq1VY; arc=none smtp.client-ip=74.125.225.129 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="k/Fkq1VY" Received: by mail-wm2-f1.google.com with SMTP id 5b1f17b1804b1-493b829982dso470185e9.0 for ; Tue, 07 Jul 2026 20:12:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1783480349; x=1784085149; darn=vger.kernel.org; h=in-reply-to:references:to:from:subject:cc:message-id:date :content-type:content-transfer-encoding:mime-version:from:to:cc :subject:date:message-id:reply-to:content-type; bh=Pfob3D8mbkTTmUhLmKjlXVr2c00IRc98rAq6J6IGM8w=; b=k/Fkq1VY6aeB5pCEiugfcDxREjIseLxREzoYRra3lE9/nqbw3tzGUDUwgcfTQhdPsO 6YRANdwssFS43X6i5wjYdG1mWrE/DRmgirvreyqiSlkwWfdz4a5eCsDpZRC+RTdSPmw0 s+W5PsJt+eRo2JyW4vt8cm8j6o18Bwrkmz2tCwBaIMcyksROnhGmOYOIVuwU8XGA3Wqy P9nmOlHdFf5X58K68DiuTgf7FFiW5HMU1uSojZ53q8h1A6VVKcR3ii21saKSMp6KCCIm 4KgFIa31hmpuSnLYxbi7pq9tr33pEdk0kCkz2ENTEr0iq5VKs6yKz183SaDGqJl8eQ5U mB8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1783480349; x=1784085149; h=in-reply-to:references:to:from:subject:cc:message-id:date :content-type:content-transfer-encoding:mime-version:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=Pfob3D8mbkTTmUhLmKjlXVr2c00IRc98rAq6J6IGM8w=; b=ZDsJDMYm3FzpA18l1rOgIQAIZxw68ibRuF0q+H02ei4PgSkBKXjnDiZxpDQgTElBCK 7YXoNbbldP6fpY4xfZNBPpXtAcvijNpEHRPyXWUnMuYHXIciaK25fyuOisplyef1N9cu Sh1/OY1hD38/Omcnz76ZB7t3q/B0MuQc6PHzrx7jvhs1eIQq3hbYV4iht94p0UNdpvfU 7LyvV+tR0djEKzYiCWpyCZdv2JEZ+H+UrlJgIxOLdamue4cdd3VNybVAIOKUmhSEBFGy 6UPEPD/kYh8a2u+CU4FlQFilYqtnfTZ21WaOxKub0rd1MvPTpR64BlasDm4EounQ//Qq mG8w== X-Forwarded-Encrypted: i=1; AHgh+Rrw+XqfMzIpkKjLTZwuetEXFXFEzHDyW217K0273Nprc5RZ1oau3fs8x6opT/tXy+UIk4Ff5uDyfkO0FEV+Jts=@vger.kernel.org X-Gm-Message-State: AOJu0YzMD1HnszCEq40sd1FrUa3ArZI0HsxCVKU0krARaA0TQww8b36S Or56ohbRkGt1OD0MJ8x6hz2Q3H6pAWClLQH3iM3MKDNjQPlhkWImllv0 X-Gm-Gg: AfdE7cmEtiR2lCLBFXJ89UhtcTuPh+Ewm7r0azAnmwgL7trVl49heNmP+QKCORVmP+F WZn9t4W/V80nw7MGpvTW0veDQt2k6ozYRN3NEs8ATM2JZyFqf1j1vVZxYECidreruSbh6z7LC/Y fR4E8GGPcvxwbDhN7ttqcgMunpnMnw1Sv2qdx11U8qu5w8QJys+nO7ESbsYnfQgr53G12Ai0W9j m0xOV3cUUIQMgoMEY4cZeAy9IkWRslS8dwh35FEYlSYKGvENPvkReYF44+6RUPuUfWAnhEJt9Ja IlDaSZwrCJOdt2zkqVuPQ+0w0qNWZVmCaQDK12H53qCTKO58kOsDbQRuH+0FurWS7FTnSodN/Vs i469WirWv18Q4orpo6bRpkFA39D2a/bDwT4sqQeA+1SgTKqIWPLZTpeL45fhvrpk2REaH3I52t+ zRRHtCOwkEbRZ6WpyHl371FBqMtDf3Zvz6iVQDe0KFI8Og1RLJtZ2N5J16xxSA0fRIKY2uAGtoq s03b6hswXZeM5YjMtIiwmyYD1C/e+mAgvZxk3TjcFt9Em0l3P9aTWU= X-Received: by 2002:a05:600c:6085:b0:492:454c:347c with SMTP id 5b1f17b1804b1-493e6859969mr4220535e9.7.1783480348874; Tue, 07 Jul 2026 20:12:28 -0700 (PDT) Received: from localhost (nat-icclus-192-26-29-3.epfl.ch. [192.26.29.3]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-493e610532fsm19286465e9.0.2026.07.07.20.12.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 07 Jul 2026 20:12:28 -0700 (PDT) Precedence: bulk X-Mailing-List: linux-kselftest@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Wed, 08 Jul 2026 05:12:28 +0200 Message-Id: Cc: , , , , , , Subject: Re: [PATCH v5 bpf-next 0/3] bpf: add bpf_init_inode_xattr kfunc for atomic inode labeling From: "Kumar Kartikeya Dwivedi" To: "David Windsor" , "Alexei Starovoitov" , "Daniel Borkmann" , "Andrii Nakryiko" , "Martin KaFai Lau" , "Eduard Zingerman" , "Song Liu" , "Yonghong Song" , "John Fastabend" , "KP Singh" , "Jiri Olsa" , "Kumar Kartikeya Dwivedi" , "Emil Tsalapatis" , "Matt Bobrowski" , "Paul Moore" , "James Morris" , "Serge E . Hallyn" , "Casey Schaufler" , "Stephen Smalley" , "Ondrej Mosnacek" , "Mimi Zohar" , "Roberto Sassu" , "Dmitry Kasatkin" , "Eric Snowberg" , "Alexander Viro" , "Christian Brauner" , "Jan Kara" , "Shuah Khan" X-Mailer: aerc 0.21.0 References: <20260708000956.46138-1-dwindsor@gmail.com> In-Reply-To: <20260708000956.46138-1-dwindsor@gmail.com> On Wed Jul 8, 2026 at 2:09 AM CEST, David Windsor wrote: > Many in-kernel LSMs (SELinux, Smack, IMA) store security labels in > extended attributes. For these LSMs, atomic labeling during inode > creation is critical: if the inode becomes accessible before its xattr > is set, it is briefly unlabeled, which can disrupt LSMs making policy > decisions based on file labels. > > Existing LSMs solve this by setting xattrs directly in the > inode_init_security hook, which runs before the inode becomes > accessible. BPF LSM programs currently lack this capability because > the hook uses an output parameter (xattr_count) that BPF programs > cannot write to, and existing kfuncs like bpf_set_dentry_xattr > require a dentry that isn't available until after the inode is > accessible. > > This series introduces the bpf_init_inode_xattr() kfunc, which takes > the combined inode_init_security xattr context argument and claims a > slot in it via the new security_lsmxattr_add() LSM helper. > There are various CI failures in newly added tests, I don't think any of th= em are passing. Please fix before respinning. https://github.com/kernel-patches/bpf/pull/12730 E.g. both test_init_inode_xattr and test_init_inode_xattr_slot do not have expected results. pw-bot: cr > [...]