From: Leon Romanovsky <leon@kernel.org>
To: Jean Delvare <jdelvare@suse.de>
Cc: "Bjorn Helgaas" <helgaas@kernel.org>,
"Krzysztof Wilczyński" <kw@linux.com>,
linux-pci@vger.kernel.org, "Ariel Almog" <ariela@nvidia.com>,
"Aditya Prabhune" <aprabhune@nvidia.com>,
"Hannes Reinecke" <hare@suse.de>,
"Heiner Kallweit" <hkallweit1@gmail.com>,
"Arun Easi" <aeasi@marvell.com>,
"Jonathan Chocron" <jonnyc@amazon.com>,
"Bert Kenward" <bkenward@solarflare.com>,
"Matt Carlson" <mcarlson@broadcom.com>,
"Kai-Heng Feng" <kai.heng.feng@canonical.com>,
"Alex Williamson" <alex.williamson@redhat.com>,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
"Jakub Kicinski" <kuba@kernel.org>,
"Thomas Weißschuh" <linux@weissschuh.net>,
"Stephen Hemminger" <stephen@networkplumber.org>
Subject: Re: [PATCH v2] PCI/sysfs: Change read permissions for VPD attributes
Date: Thu, 21 Nov 2024 19:00:20 +0200 [thread overview]
Message-ID: <20241121170020.GB160612@unreal> (raw)
In-Reply-To: <20241121151116.4213c144@endymion.delvare>
On Thu, Nov 21, 2024 at 03:11:16PM +0100, Jean Delvare wrote:
> On Thu, 21 Nov 2024 14:13:01 +0200, Leon Romanovsky wrote:
> > On Thu, Nov 21, 2024 at 01:01:27PM +0100, Jean Delvare wrote:
> > > On Wed, 13 Nov 2024 14:59:58 +0200, Leon Romanovsky wrote:
> > > > --- a/drivers/pci/vpd.c
> > > > +++ b/drivers/pci/vpd.c
> > > > @@ -332,6 +332,14 @@ static umode_t vpd_attr_is_visible(struct kobject *kobj,
> > > > if (!pdev->vpd.cap)
> > > > return 0;
> > > >
> > > > + /*
> > > > + * Mellanox devices have implementation that allows VPD read by
> > > > + * unprivileged users, so just add needed bits to allow read.
> > > > + */
> > > > + WARN_ON_ONCE(a->attr.mode != 0600);
> > > > + if (unlikely(pdev->vendor == PCI_VENDOR_ID_MELLANOX))
> > > > + return a->attr.mode + 0044;
> > >
> > > When manipulating bitfields, | is preferred. This would make the
> > > operation safe regardless of the initial value, so you can even get rid
> > > of the WARN_ON_ONCE() above.
> >
> > The WARN_ON_ONCE() is intended to catch future changes in VPD sysfs
> > attributes. My intention is that once that WARN will trigger, the
> > author will be forced to reevaluate the latter if ( ... PCI_VENDOR_ID_MELLANOX)
> > condition and maybe we won't need it anymore. Without WARN_ON_ONCE, it
> > is easy to miss that code.
>
> The default permissions are 10 lines above in the same file. Doesn't
> seem that easy to miss to me.
>
> In my opinion, WARN_ON should be limited to cases where something really
> bad has happened. It's not supposed to be a reminder for developers to
> perform some code clean-up. Remember that WARN_ON has a run-time cost
> and it could be evaluated for a possibly large number of PCI devices
> (although admittedly VPD support seems to be present only in a limited
> number of PCI device).
Sorry about which run-time cost are you referring? This is slow path and
extra if() inside WARN_ON which has unlikely keyword, makes no difference
when accessing HW.
In addition, this check is for devices which already known to have VPD
(see pdev->vpd.cap check above).
>
> Assuming you properly use | instead of +, then nothing bad will happen
> if the default permissions change, the code will simply become a no-op,
> until someone notices and deletes it. No harm done.
>
> I'm not maintaining this part of the kernel so I can't speak or decide
> on behalf of the maintainers, but in my opinion, if you really want to
> leave a note for future developers, then a comment in the source code
> is a better way, as it has no run-time cost, and will also be found
> earlier by the developers (no need for run-time testing).
I don't have any strong feelings about this WARN_ON_ONCE, will remove.
Thanks
>
> Thanks,
> --
> Jean Delvare
> SUSE L3 Support
next prev parent reply other threads:[~2024-11-21 17:00 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-13 12:59 [PATCH v2] PCI/sysfs: Change read permissions for VPD attributes Leon Romanovsky
2024-11-21 12:01 ` Jean Delvare
2024-11-21 12:13 ` Leon Romanovsky
2024-11-21 14:11 ` Jean Delvare
2024-11-21 17:00 ` Leon Romanovsky [this message]
2024-11-21 22:41 ` Bjorn Helgaas
2024-11-22 19:43 ` Leon Romanovsky
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20241121170020.GB160612@unreal \
--to=leon@kernel.org \
--cc=aeasi@marvell.com \
--cc=alex.williamson@redhat.com \
--cc=aprabhune@nvidia.com \
--cc=ariela@nvidia.com \
--cc=bkenward@solarflare.com \
--cc=hare@suse.de \
--cc=helgaas@kernel.org \
--cc=hkallweit1@gmail.com \
--cc=jdelvare@suse.de \
--cc=jonnyc@amazon.com \
--cc=kai.heng.feng@canonical.com \
--cc=kuba@kernel.org \
--cc=kw@linux.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=linux@weissschuh.net \
--cc=mcarlson@broadcom.com \
--cc=netdev@vger.kernel.org \
--cc=stephen@networkplumber.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).