linux-pci.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Matthew Wilcox <willy@infradead.org>
To: Bjorn Helgaas <helgaas@kernel.org>
Cc: "Alexey V. Vissarionov" <gremlin@altlinux.org>,
	"Krzysztof Wilczyński" <kw@linux.com>,
	"Bjorn Helgaas" <bhelgaas@google.com>,
	"Alex Williamson" <alex.williamson@redhat.com>,
	"Jesse Barnes" <jbarnes@virtuousgeek.org>,
	"Yu Zhao" <yu.zhao@intel.com>,
	linux-pci@vger.kernel.org, lvc-project@linuxtesting.org
Subject: Re: [PATCH] PCI/IOV: "virtfn4294967295\0" requires 17 bytes
Date: Thu, 29 Dec 2022 21:09:56 +0000	[thread overview]
Message-ID: <Y64CJLnU2WGhPY3O@casper.infradead.org> (raw)
In-Reply-To: <20221229181258.GA616291@bhelgaas>

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?

  reply	other threads:[~2022-12-29 21:10 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-18  3:33 [PATCH] PCI/IOV: "virtfn4294967295\0" requires 17 bytes Alexey V. Vissarionov
2022-12-18 10:57 ` Krzysztof Wilczyński
2022-12-18 12:21   ` Alexey V. Vissarionov
2022-12-18 22:19     ` Matthew Wilcox
2022-12-18 23:24       ` Alexey V. Vissarionov
2022-12-19 10:16       ` Niklas Schnelle
2022-12-29 18:12       ` Bjorn Helgaas
2022-12-29 21:09         ` Matthew Wilcox [this message]
2023-01-12 23:00     ` Bjorn Helgaas

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Y64CJLnU2WGhPY3O@casper.infradead.org \
    --to=willy@infradead.org \
    --cc=alex.williamson@redhat.com \
    --cc=bhelgaas@google.com \
    --cc=gremlin@altlinux.org \
    --cc=helgaas@kernel.org \
    --cc=jbarnes@virtuousgeek.org \
    --cc=kw@linux.com \
    --cc=linux-pci@vger.kernel.org \
    --cc=lvc-project@linuxtesting.org \
    --cc=yu.zhao@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).