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
