From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr2-f0.google.com (mail-wr2-f0.google.com [74.125.225.64]) (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 DB75B355819 for ; Fri, 31 Jul 2026 18:18:05 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.225.64 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785521887; cv=none; b=eEGhvOdAspD30+RaWBuj+AtMd7QawAI/6IcYbaERBe1srjxekleG5mmFfsaH4PEfMVs40giZP5+YN6ldaKlbyu9o2LcRr6vymRbenPq4z2psSTlHNy6a66wyfZy9mrprqWho6JUIoHIoPhPw21wnM0f7VsXsWd0QhQAFk1xbh/A= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785521887; c=relaxed/simple; bh=8g7KXe528qNP4LXN8HqY8b8J0ptgbH/4lXoqEsFZCQ4=; h=Mime-Version:Content-Type:Date:Message-Id:Cc:Subject:From:To: References:In-Reply-To; b=cIeFVpEELiCtccQbox613lha6QwHR0zT8jbE85cV2rZii3x+1nrP+MecXzAQbwpW03998OHcG1K3n3aKqaaPqhXUf3QxeQwZOSIleIAiHsYLN1X9haqyssw7BOY2gm5AZaZN91cKJEZ1ENXrQV12f+wBpy3K4hThUEoi22RYJHQ= 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=KZsB/vvC; arc=none smtp.client-ip=74.125.225.64 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="KZsB/vvC" Received: by mail-wr2-f0.google.com with SMTP id ffacd0b85a97d-4784b41f3aeso417513f8f.1 for ; Fri, 31 Jul 2026 11:18:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1785521884; x=1786126684; 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=NfTR8XppsBKdhupdPij7rDfGq57BVGWLklEXWleA36Q=; b=KZsB/vvCejDkWdB0KEZdr3hj2NOryJhOXJLbJJBOD8grenwokohrNJeJR9hxFK9PUf 8CjY1PnT2qX8MDqhDlWQdgstN0QZCWgaZnwcBgqMPUinoqAcBLDu+JHNvolOaTgiEKe+ TVDELCJqwkvHQt3QofXdChuvIQB9Z3TWnuSh+DtXvtN17iZusn/RkV/UQ6hLLOdOkDDE eQ5TYRMbCBAfUBTjkJKd40YlkGaVCqqGiEvCvYSegHzPUCCIaI+m1IS/IamQhRAyrZmK LHcWGwwZp8wV1RSuIaUr8X/28LZg7J90Lktwi6aQ3TTUTw8Rz2+xBOWgMMR8x4SRPhDQ AgEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1785521884; x=1786126684; 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=NfTR8XppsBKdhupdPij7rDfGq57BVGWLklEXWleA36Q=; b=OUuuPk5MAUbEfjLV0bUrs91A1Dmzi6hBfL7p1/0CRR+A+afvwolsmriBLc0EfaP8b0 9UCZURqtVxdtH5Eo04CZdJ2o7kAwfcuqMQlpMpgx5paFgsTMQiIVkdsAS+oK1jXBweZ6 PXXPSsekFcOL1DJMRs3WRbXyx05d77fpB4p9SvxfCidCiT5f1PHJlmbgAWC3yNIHmaWH j0YjoLfVc3pPtI0Bbh7aLD5sw4aIpoNzPAyUuuSCdo2TY3ymLjSVNpGzbDuSQnbVFmjP q1IlDdVPw5DGAzEhnnxN+xJ3WSLdGf02ZHxYF1GxWcbQ4nvNyuo78u6dX3G1JggExvop JpDg== X-Forwarded-Encrypted: i=1; AHgh+RpHSAewtiVor7+K8klxK9H4jYOwHm32V3Oz9OiXWL+bu2nz35SMtL98VO9MReMwvYB3/kny8OXIebfAdCYB@vger.kernel.org X-Gm-Message-State: AOJu0YxPL/0Wc+WfiRPFyGMmDbZ0KK1Y8BwyWRmtIDONoFidHHpo2koI Ez+H4qL5FUGqJH1aBLNoW7iROSjIOyNwJw0dP5GmC17Vk7VWeKJpiow0 X-Gm-Gg: AR+sD10d6QQwC+4uSMpi1OuAYJrbSDi32Ol1uAy337ZeTBm6qD6LQ/kJNR+326aqaTW nSpvzMfMYlIbPz72TNpnPI78FTuO3XOoeCOoFPl1c+NQGkkI7UENZxLgE5jbBONiNSIHPeYNOXW n6xmhnfcldXskplQqPPeE9wzbrFicJbwvdoL39cKMBCnkGSLY57i+EtR4uzvKOdCJGlheQdeMz0 XDuT5OKtTP14pLi62vK0V93hYiXBbsYwKnFUARn/IjhP/DNHreq4PYHiWxLgE98gEMFh1VdYdJO H3L/+sFItFwP+FU5d7Z6IrN7DroVtrP2ayFieOoIibYJ3EANzAANR6QF3n+kauaeV16jOOcg5X9 NoEYFL1pk4cPTiytBWekqjmkf4j155LUhpCQ8jpO+k1dsMnESxwj+cBDCxt0J5+xtYbnQ5GAOUP 19NYbZFT/ewvYjdHi/t5uTK9WENWXLsf9O4U15mVMx/XnTLQbU/CiSzljcNYpJA163k2/p39Eq3 kTjLlwTwsv9G0DjrtUd0MziJMKsy8yYjrozfjkQycuGewKgnMG/Eucsj3Fvjw2xJQC6gm8fppl1 O8gBroBOEIwHS3Go/I40etO9i89XVw0Y6X+2gw== X-Received: by 2002:a5d:5f51:0:b0:475:f0f0:9ec8 with SMTP id ffacd0b85a97d-47fd7328eb4mr1388509f8f.51.1785521883948; Fri, 31 Jul 2026 11:18:03 -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-47fd45a1abfsm7033628f8f.37.2026.07.31.11.18.03 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 31 Jul 2026 11:18:03 -0700 (PDT) Precedence: bulk X-Mailing-List: linux-fsdevel@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 20:18:03 +0200 Message-Id: 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" , , , , , , , 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" 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 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: >> >> >> >> >> >> >> >> >> Okay, it looks like there was some confusion/misunderstanding. >> >> >> >> >> >> My understanding of Kumar's comments was that he was referring to = the >> >> >> exisiting LSM related kfuncs that are located in fs/bpf_fs_kfuncs.= c, >> >> >> not necessarily the new kfunc you are proposing in this patchset. >> >> >> Kumar is welcome to correct either one or both of us, if we read t= hat >> >> >> wrong :) >> >> >> >> >> > >> >> > Yes, after another reading, that does appear to be the case =3D). >> >> > >> >> > We'll need v7 anyway to fix the ocfs-related UAF the bot found. >> >> > >> >> >> >> Since there is confusion, let me clear it up. >> >> >> >> I meant it for all of them. I don't think it makes sense to keep this= one in >> >> security/ when others are in fs/bpf_fs_kfuncs.c. That confusing limbo= state is >> >> worse than just placing it where others already are. >> >> >> >> As I already said, the discussion around whether all of them they sho= uld go in >> >> security/ is orthogonal and should be done separately; it isn't produ= ctive to >> >> repeatedly bring it up in the context of this patch set. >> >> >> >> I honestly don't get the urgency; it will be a mechanical change if w= e need to >> >> make such changes. The worst outcome would be stalling David's work o= ver it. >> >> >> >> As for landing this stuff, we can let Paul take the patches touching = security/ >> >> and route the rest (3-4) through bpf-next after the merge window. We = need them >> >> to go through BPF CI anyway to ensure nothing breaks. >> > >> > Some existing LSM kfuncs are located in the wrong files. I'm not >> > suggesting that David needs to fix the existing problems, but there is >> > no reason to keep making the same mistakes. The new LSM kfunc must go >> > in security/bpf_lsm_kfuncs.c; if that isn't acceptable to the BPF >> > developers then David will need to find a new way that doesn't involve >> > kfuncs. >> >> What "mistakes"? Really? It's just code organization bureaucracy. Callin= g it a >> mistake is just blowing things out of proportion. > > :D > > You've no doubt seen the challenging interactions between some of the > BPF and LSM developers over the past several years. A recent BPF LSM > bug/vulnerability as well as these interactions between the BPF/LSM > devs, has caused me to take a much closer look at how things have been > done regarding the BPF LSM and there are a number of things that > should be addressed. Not all of those things will be addressed now, > but I won't support patches that continue to do things the wrong way > because I currently have very little faith in our ability to correct > them later. I am not sure whether you shared whatever concerns you are talking about. = If they are valid, we would be happy to engage and resolve them. I am aware of the past discussions, but we did spend additional effort to f= ind a way that worked well for everyone in the end. > I do hope that at some time in the future we can reach a > point where there is more cooperation between the two communities, but > given the recent difficulties over even the small things, we are not > there yet. > I think it takes two hands to clap. So far, I have tried to engage constructively, and offered to discuss where these kfuncs collectively should stay in a separate discussion. Explained w= hy it cannot be done unilaterally, and that we need consensus from all stakeholde= rs (FS, BPF, LSM). Explained that we need to figure out how the testing strate= gy for such cross-cutting changes would work if they don't go through BPF tree= . In response, I have only seen you continually tried to derail the whole thi= ng over the location of the kfunc, threatening to not let it move forward. Yes, I understand you feel it should be placed under security/. You are ent= itled to your opinion. No, I do not think the newly added kfunc is a big enough layering violation= such that we need to do it ASAP, disregarding everything else outlined above. I = am sure you see that too. There are several other instances of similar kfuncs. Therefore, please attempt to meet me halfway here. It is calling a single security_lsmxattr_add() kfunc cleanly abstracted and already placed under security/, where it belongs. >> I don't think you can simply decide this unilaterally either. Do you tak= e full >> responsibility that kfuncs going there won't introduce BPF side regressi= ons? Who >> makes sure patches touching the new location run through BPF CI? All of = this >> needs to be thought through before we decide upon anything. > > I would expect, and require, that patch submitters perform the > necessary testing for the patches they submit; this is no different > from any other patch today that is submitted for the LSM framework. It doesn't scale. The amount of combinations (architectures x compilers x m= odes) that need to be tested for the BPF subsystem is beyond reasonable for any p= atch submitter to test themselves. The only realistic approach is letting it go through BPF CI and exercising the full matrix on submission. It is fairly apparent to me that you do not have a clear picture how BPF co= de gets tested (which is fine and understandable). It only underscores my point: we need to move this discussion elsewhere, an= d have a broader dialogue and form consensus. Not litigate over it in this th= read. David spent considerable effort on this set, and has carefully reworked his= code several times. Blocking his work over this terriotrial argument would be a = loss for everyone, including the users of the kernel. Anyhow, I cannot stop you, but it would be unfortunate if you continue to d= ouble down, in that case we'll have to figure out other ways of moving things for= ward. > [...]