On Thu, Dec 29, 2022 at 12:12:58PM -0600, Bjorn Helgaas wrote: > On Sun, Dec 18, 2022 at 10:19:24PM +0000, Matthew Wilcox wrote: > > On Sun, Dec 18, 2022 at 03:21:39PM +0300, Alexey V. Vissarionov wrote: > > > On 2022-12-18 19:57:02 +0900, Krzysztof Wilczyński wrote: > > ... > > > > Although unlikely, the 'id' value may be as big as 4294967295 > > > (uint32_max) and "virtfn4294967295\0" would require 17 bytes > > > instead of 16 to make sure that buffer has enough space to > > > properly NULL-terminate the ID string. > > > > Wait, what? How can we get to a number that large for the virtual > > function ID? devfn is 8 bits, bus is a further 8 bits. Sure, domain > > is an extra 16 bits on top of that but I'm pretty sure that virtual > > functions can't span multiple domains. Unless that's changed recently? > > > > Even if they can, we'd need to span 2^14 domains to get up to a billion > > IDs. That's a hell of a system and I think overflowing here is the > > least of our problems. > > > > So while this is typed as u32, I don't think it can get anywhere close. > > Is there an argument *against* this patch (as opposed to "this is > probably unnecessary and it requires a lot of analysis to prove that > we don't need it")? It consumes additional stack space? It's an example of changing code to shut up a tool that is of dubious value?
