Hi, This is v2 of the series with 2/5 updated to use `vscnprintf' rather than `vsnprintf'. No other changes. So we are here owing to Christoph's recent ISA bounce buffering sweep: <https://lore.kernel.org/linux-scsi/20210331073001.46776-1-hch@xxxxxx/T/#m981284e74e93216626a0728ce1601ca18fca92e8> which has prompted me to verify the current version of Linux with my old server, which has been long equipped with venerable Linux 2.6.18 and which I now have available for general experimenting, and the BusLogic BT-958 PCI SCSI host bus adapter the server has used for 20-something years now. This revealed numerous issues with the BusLogic driver. Firstly (1/5) it has suffered from some bitrot and messages produced have become messy from the lack of update for proper `pr_cont' support. Secondly (2/5) there has been a potential buffer overrun/stack corruption security issue from using an unbounded `vsprintf' call. Thirdly (3/5) it has become obvious the BusLogic driver would have been non-functional, should I have upgraded the kernel, at least with this configuration for some 8 years now, and the underlying cause has been a long-known issue with the MultiMaster firmware I have dealt with already, back in 2003. To put it short the firmware cannot cope with commands that request an allocation length exceeding the length of actual data returned. I have originally observed it with a LOG SENSE command in the course of investigating why smartmontools bring the system to a death, and worked it around: <https://sourceforge.net/p/smartmontools/mailman/message/4993087/> by issuing the command twice, first just to obtain the allocation length required. As it turns out we need a similar workaround in the kernel now. But in the course of investigating this issue I have discovered there is a second bottom to it and hence I have prepared follow-up changes (4-5/5) to address problems with our handling of Vital Product Data INQUIRY pages. See individual change descriptions for further details. Questions, comments, concerns? Otherwise please apply. Maciej
