From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr2-f2.google.com (mail-wr2-f2.google.com [74.125.225.66]) (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 1B783442106 for ; Fri, 31 Jul 2026 19:20:53 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.225.66 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785525654; cv=none; b=MlAJbSxHXXf1CxA3uSqjRfsIePJzP33qBmNU/+ZzsNeUIjqigUCp3GnxaRFVbT4XbTncycKDUy7EVP74LL/XUKAOOj9PGAu/9d6Leprroj0r3fk9Xo/HpHh943u1PPuxez4vwGcW6yqG2APpfq3fUYWMX+c0SmBBs5mQndFV3uQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785525654; c=relaxed/simple; bh=W/cQazly5+ZSmwW+vMYjDeAOiE27Kjc1Cr7JvjQ9jfs=; h=Mime-Version:Content-Type:Date:Message-Id:Subject:From:To:Cc: References:In-Reply-To; b=D9RmRa2pOtzYrvjSjGe4Io50lDnuXy8EjzMCV1xtGi5cbnSLY52UQpzX42zKne8SAcQa8XE0iVprcJgEi7C6yR7LXmtu+umfyvTubic2aoOpFiUt9ukN/a/Z+khlBXVKFqS+e2Yc6C3QPwRCw48dOWSoKJK0Gf9nPHJAPxG3kOw= 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=nhAFGLhV; arc=none smtp.client-ip=74.125.225.66 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="nhAFGLhV" Received: by mail-wr2-f2.google.com with SMTP id ffacd0b85a97d-47301772842so669623f8f.0 for ; Fri, 31 Jul 2026 12:20:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1785525651; x=1786130451; darn=vger.kernel.org; h=in-reply-to:references:cc:to:from:subject:message-id:date :content-type:content-transfer-encoding:mime-version:from:to:cc :subject:date:message-id:reply-to:content-type; bh=3/Y6YcDM4/zvWNQ6LoR9jhMZHzjhOIbqHOCYPbHDmdw=; b=nhAFGLhVLCPf3TVFJtApTCWIQHVQvV9MPsEf6fHLya8JT19sY+BBoWI8P2L631IEIJ JIkv0qRStiFochcRnso74FFbiEfM/zttVtvwqSjkUbHlVPAeIAYxgorGBqyGf2MlJ6Ns ytLz0mKTS35yftkeGpuJ+kqpCzkq6UjL1Rl0VaszcxCHb61UAIvcd/ADrkHlbSKM5uyk AHjkndgGbiaAlzFO8cM0IHpd4pxrKvRZUkari1tm7Q1M8zoC5MO5t2ioOxxnfyNtiapG /zuGi/w7A7XStv38XKLTDte6pi/D36FArcTi/C/rsmrow9rW5NNV6udYKSzDpjoXZfyB aJSA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1785525651; x=1786130451; h=in-reply-to:references:cc:to:from:subject: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=3/Y6YcDM4/zvWNQ6LoR9jhMZHzjhOIbqHOCYPbHDmdw=; b=FhqevSQpWaSSGE5j4pg6Clm/x9yNCr0nGSdYQMF710zokoBlHD142BOfYWvIzi9+WH eV0Fv9jrbR6KrzZgCciQ5KPOdD+sIHvpn2Osl/WaXReUF131Sf2H4uEf4QhJAHH8q4tZ ntt25zWzWPUYVLT60KII1u5YltyXNac03mHFtD9cH+6DCa91vHNlxQta8DIgj0uV73sO et2rPydGl4UwnWux8If9k6beCrhLQbtKp3OLkdXsTr6V6DgPzyK7STRvsD8bru0EqseI ipeGRFipd8RmjnN5d1jHtfVTdn6TpwZimjae9PludrzcV0TxpRIVNpSLkOEm+9gCEXVf LaHg== X-Forwarded-Encrypted: i=1; AHgh+RrwmbyIhahaePtRzGvCqNE8PmTORQ6xS8VQX3pHbG3RCYtO4yEWQGDHxtMml+Hq9mK/hCWlrIawn4Wt6tOh2/M=@vger.kernel.org X-Gm-Message-State: AOJu0YxJLPbBBecmQIeWnO5NZb/T5bNo5ujALbQKhkP70OsSegKmlYlO 5Mkr/mXwqeAyE0JUNsPczmSe64JQNgzboTtZYM0yThPloe3f1CAFfnfJ X-Gm-Gg: AR+sD10hNIc5myw1TPxgzkSoQQczfQWRZjRvLkhVOvE8gPB6NTHeMWzP20TCv71Hpvy DqcOs1swYf2R501Q31gTOZ3/1N357aVk1cZUpKM4Wx1pK1gxk8VrdlTH8vUZmJZxFdgGoCK592Y lI/1JJyjVcfKmCU1Wx2/otEDWK3cEna9/kKW+IvLX3VBLsCS7I6z+aXCu4IDNgywt6klsNEds5h DqpOWrP/vC/UMUt4vYgGYbc4IytFDLfLvAtCdpm8ue5nlZWri609FE0ZzOzxi4r12woZTjTZywy 5g/wbXJLeuS6JSPpIXaE6NQRFShHwHIvr3t1ms9hmWyk/044cgRA6d3c9fTZVpv4FjhyDLWsP0V wnOcQjEv1f3Ube/GexMBkHKgGy4yLWi+/gbZxAFHjvZh4pOpegkIyaVLQv52z2TCpuY3ah+Oejl pTPn6PBNqAzvdCuq8ZC41rLDjQJUe9AB9QC3hU8t7bZjmprr+ZFmgUm0VZT89twTd7neTPRi3DJ HHVSuWFqIJXm6Zvx7DEvAgYaRV5oz0l/eukGzDrBwVDuCcrZeD9rjZzOq3Yujv56sojZ9xcAQhX 98KHxoQr9JmMzUZdx6UTcpk+t1A= X-Received: by 2002:adf:eac3:0:b0:47d:dfc6:b28b with SMTP id ffacd0b85a97d-47fd72e1887mr1421938f8f.30.1785525651097; Fri, 31 Jul 2026 12:20:51 -0700 (PDT) Received: from localhost (nat-icclus-192-26-29-3.epfl.ch. [192.26.29.3]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-47fd456a6cbsm7789645f8f.23.2026.07.31.12.20.50 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 31 Jul 2026 12:20:50 -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: Fri, 31 Jul 2026 21:20:50 +0200 Message-Id: Subject: Re: [PATCH v6 bpf-next 3/4] bpf: add bpf_init_inode_xattr kfunc for atomic inode labeling From: "Kumar Kartikeya Dwivedi" To: "Paul Moore" Cc: "David Windsor" , "Alexei Starovoitov" , "Daniel Borkmann" , "Andrii Nakryiko" , "Martin KaFai Lau" , "Eduard Zingerman" , "Song Liu" , "Yonghong Song" , "John Fastabend" , "KP Singh" , "Jiri Olsa" , "Emil Tsalapatis" , "Matt Bobrowski" , "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: <20260730234533.1912709-1-dwindsor@gmail.com> <20260730234533.1912709-4-dwindsor@gmail.com> In-Reply-To: On Fri Jul 31, 2026 at 9:05 PM CEST, Paul Moore wrote: > On Fri, Jul 31, 2026 at 2:50=E2=80=AFPM Kumar Kartikeya Dwivedi > wrote: >> On Fri Jul 31, 2026 at 8:42 PM CEST, Paul Moore wrote: >> > On Fri, Jul 31, 2026 at 2:18=E2=80=AFPM Kumar Kartikeya Dwivedi >> > wrote: >> >> On Fri Jul 31, 2026 at 6:59 PM CEST, Paul Moore wrote: >> >> > On Fri, Jul 31, 2026 at 12:32=E2=80=AFPM Kumar Kartikeya Dwivedi >> >> > wrote: >> >> >> On Fri Jul 31, 2026 at 6:02 PM CEST, Paul Moore wrote: >> >> >> > On Fri, Jul 31, 2026 at 11:44=E2=80=AFAM Kumar Kartikeya Dwivedi >> >> >> > wrote: >> >> >> >> On Fri Jul 31, 2026 at 5:30 PM CEST, David Windsor wrote: >> >> >> >> > On Fri, Jul 31, 2026 at 11:17=E2=80=AFAM Paul Moore wrote: >> > >> > ... >> > >> >> Yes, I understand you feel it should be placed under security/. You a= re entitled >> >> to your opinion. >> >> >> >> No, I do not think the newly added kfunc is a big enough layering vio= lation such >> >> that we need to do it ASAP, disregarding everything else outlined abo= ve. I am >> >> sure you see that too. There are several other instances of similar k= funcs. >> >> >> >> Therefore, please attempt to meet me halfway here. >> > >> > I'm happy to work with you, and/or anyone else, who wants to work on >> > finding a way to test kfuncs that live in security/bpf_lsm_kfuncs.c. >> >> Right, and for that file to exist, you need to get everyone (FS, BPF fol= ks) to >> agree on whether placing all such kfuncs there makes sense. It is not fo= r both >> of us to decide on our own. So let's revisit this whole topic once you'v= e done >> that exercise. > > The kfunc that David has proposed must be located in > security/bpf_lsm_kfuncs.c, similar to the VFS kfuncs and > fs/bpf_fs_kfuncs.c. If you read David's bpf_init_inode_xattr() kfunc Sigh. I now went and read the archives, and Christian already told you no before = [0], which I missed in my first read. So two people whom this code affects alrea= dy objected to your proposal. [0]: https://lore.kernel.org/bpf/20260625-schnabel-rennmaschine-parieren-= bcb352c3cf59@brauner > you will notice there is nothing in the function relating to the VFS, > well other than the "inode" and "xattr" in the name of the function; I can also read it the other way. There is only one "security_lsmxattr_add(= )" call that is LSM related, and the rest is VFS or BPF specific stuff. There would be no xattr support in LSM code without filesystems implementin= g them. Please avoid making absurd and non-sensical arguments. If we went by this logic, we would have to move the entirety of the kernel = under security/, since anything that calls into LSM code becomes eligible to go t= here. > this is purely a LSM kfunc and I stand by my previous comments. The > BPF maintainers have seen fit to decide quite a few things LSM related > solely on their own, I see no reason why requiring a LSM kfunc be > located in security/bpf_lsm_kfuncs.c is unreasonable given our current > situation. > > As I said earlier, I'm happy to work with you, David, or anyone else > on ensuring security/bpf_lsm_kfuncs.c has the proper test coverage, > but I'm not going to continue to go back and forth about the location > of the bpf_init_inode_xattr() kfunc that is proposed in this patchset. > If you, or any of the other BPF maintainers, are not able to live with > that location then David will need to find another way. Yeah, I think we've spilled enough ink on this. We'll figure out a way to m= ove things forward. Since VFS people disagree too, the kfunc should stay where= it is in this series. I am always open to revisiting all this once you can convince others by mak= ing useful arguments, instead of imposing your will onto them and throwing a ta= ntrum.