Hi Greg, On Sat, 13 Aug 2022, 6:46am, Greg KH wrote: > > ---------------------------------------------------------------------- > On Sat, Aug 13, 2022 at 03:30:37PM +0200, gregkh@xxxxxxxxxxxxxxxxxxx wrote: > > The patch below was submitted to be applied to the 5.19-stable tree. > > > > I fail to see how this patch meets the stable kernel rules as found at > > Documentation/process/stable-kernel-rules.rst. > > > > I could be totally wrong, and if so, please respond to > > <stable@xxxxxxxxxxxxxxx> and let me know why this patch should be > > applied. Otherwise, it is now dropped from my patch queues, never to be > > seen again. > > > > thanks, > > > > greg k-h > > > > ------------------ original commit in Linus's tree ------------------ > > > > >From b1f707146923335849fb70237eec27d4d1ae7d62 Mon Sep 17 00:00:00 2001 > > From: Arun Easi <aeasi@xxxxxxxxxxx> > > Date: Tue, 12 Jul 2022 22:20:39 -0700 > > Subject: [PATCH] scsi: qla2xxx: Fix response queue handler reading stale > > packets > > > > On some platforms, the current logic of relying on finding new packet > > solely based on signature pattern can lead to driver reading stale > > packets. Though this is a bug in those platforms, reduce such exposures by > > limiting reading packets until the IN pointer. > > > > Two module parameters are introduced: > > > > ql2xrspq_follow_inptr: > > > > When set, on newer adapters that has queue pointer shadowing, look for > > response packets only until response queue in pointer. > > > > When reset, response packets are read based on a signature pattern > > logic (old way). > > > > ql2xrspq_follow_inptr_legacy: > > > > Like ql2xrspq_follow_inptr, but for those adapters where there is no > > queue pointer shadowing. > > On a meta-note, this patch seems VERY wrong. You are adding a > driver-wide module option for a device-specific action. That should be > a device-specific functionality, not a module. > > Again, as I say many times, this isn't the 1990's, please never add new > module parameters. Use the other interfaces we have in the kernel to > configure individual devices properly, module parameters are not to be > used for that at all for anything new. > > So, can you revert this commit and do it properly please? > The reason I chose module parameter way was because of these primarily: 1 As this is a platform specific issue, this behavior does not require a device granular level tuning. Either all the said adapters turns the behavior on or off. 2 Module parameters allowed persistence without complexity: Since this adapter is also used in booting on some environments, module parameter allowed the configurability as well as simplicity. If the above approach is discouraged, the alternatives that comes to my mind are: 1 Add a sysfs node 2 Add a debugfs node 3 /proc/sys/kernel ? (but that is not per adapter specific) 4 Add a udev script to watch for PCI adapter addition and set/reset 1, 2 or 3 If udev route is taken, I'd have to come up with a configuration file to save tunable state, which could be a bit cumbersome and needs documentation and be different (in terms of script location/submitting) distro to distro. Are there other options that you have in mind? Please do tell, if so. Regards, -Arun
