PCI: Fail new_id for vendor/device values already built into driver
authorBandan Das <bsd@redhat.com>
Wed, 2 Apr 2014 01:32:59 +0000 (21:32 -0400)
committerBjorn Helgaas <bhelgaas@google.com>
Tue, 29 Apr 2014 23:36:44 +0000 (17:36 -0600)
commit8895d3bcb8ba960b1b83f95d772b641352ea8e51
treefe6a3d11c5e029fc59cef437afede23a63d91d60
parent7c82126a94e69bbbac586f0249e7ef11e681246c
PCI: Fail new_id for vendor/device values already built into driver

While using the sysfs new_id interface, the user can unintentionally feed
incorrect values if the driver static table has a matching entry.  This is
possible since only the device and vendor fields are mandatory and the rest
are optional.  As a result, store_new_id() will fill in default values that
are then passed on to the driver and can have unintended consequences.

As an example, consider the ixgbe driver and the 82599EB network card:

  echo "8086 10fb" > /sys/bus/pci/drivers/ixgbe/new_id

This will pass a pci_device_id with driver_data = 0 to ixgbe_probe(), which
uses that zero to index a table of card operations.  The zeroth entry of
the table does *not* correspond to the 82599 operations.

This change returns an error if the user attempts to add a dynid for a
vendor/device combination for which a static entry already exists.
However, if the user intentionally wants a different set of values, she
must provide all the 7 fields and that will be accepted.

[bhelgaas: drop KVM text since the problem isn't KVM-specific]
Signed-off-by: Bandan Das <bsd@redhat.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Alex Williamson <alex.williamson@redhat.com>
drivers/pci/pci-driver.c