Re: [PATCH] PCI/IOV: "virtfn4294967295\0" requires 17 bytes

[Bjorn Helgaas <helgaas@kernel.org>]

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