[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20241121151116.4213c144@endymion.delvare>
Date: Thu, 21 Nov 2024 15:11:16 +0100
From: Jean Delvare <jdelvare@...e.de>
To: Leon Romanovsky <leon@...nel.org>
Cc: Bjorn Helgaas <helgaas@...nel.org>, Krzysztof Wilczyński <kw@...ux.com>, linux-pci@...r.kernel.org, Ariel Almog
<ariela@...dia.com>, Aditya Prabhune <aprabhune@...dia.com>, Hannes
Reinecke <hare@...e.de>, Heiner Kallweit <hkallweit1@...il.com>, Arun Easi
<aeasi@...vell.com>, Jonathan Chocron <jonnyc@...zon.com>, Bert Kenward
<bkenward@...arflare.com>, Matt Carlson <mcarlson@...adcom.com>, Kai-Heng
Feng <kai.heng.feng@...onical.com>, Alex Williamson
<alex.williamson@...hat.com>, linux-kernel@...r.kernel.org,
netdev@...r.kernel.org, Jakub Kicinski <kuba@...nel.org>, Thomas
Weißschuh <linux@...ssschuh.net>, Stephen Hemminger
<stephen@...workplumber.org>
Subject: Re: [PATCH v2] PCI/sysfs: Change read permissions for VPD
attributes
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).
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).
Thanks,
--
Jean Delvare
SUSE L3 Support
Powered by blists - more mailing lists