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")? My biggest concern here is that there's no connection between the VIRTFN_ID_LEN definition and the use. Even a comment about how the value of 16 or 17 was derived would help. Bjorn
