[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <cover.1315846441.git.jan.kiszka@siemens.com>
Date: Mon, 12 Sep 2011 18:54:01 +0200
From: Jan Kiszka <jan.kiszka@...mens.com>
To: linux-pci@...r.kernel.org, linux-kernel@...r.kernel.org
Cc: Jesse Barnes <jbarnes@...tuousgeek.org>,
"Hans J. Koch" <hjk@...sjkoch.de>,
Greg Kroah-Hartman <gregkh@...e.de>,
"Michael S. Tsirkin" <mst@...hat.com>, kvm@...r.kernel.org,
Brian King <brking@...ux.vnet.ibm.com>
Subject: [PATCH 0/3] PCI: Rework config space locking, add INTx masking services
This series tries to heal the currently broken locking scheme around PCI
config space accesses.
We have an interface lock out access via sysfs, but that service wrongly
assumes it is only called by one instance at a time for some device. So
two loops doing
echo 1 > /sys/bus/pci/devices/<some-device>/reset
in parallel will trigger a kernel BUG at the moment.
Besides synchronizing with user space, we also need to manage config
space access of generic PCI drivers. They need to mask legacy interrupt
lines while the specific driver runs in user space or a guest OS.
The approach taken here is provide mutex-like locking for general
access - which still requires a special mechanism due to requirements of
the IBM Power RAID SCSI driver. Furthermore, INTx masking is now
available via the PCI core and synchronized via the internal pci_lock.
Not sure who may want to take this, so I'm CC'ing broadly.
CC: Brian King <brking@...ux.vnet.ibm.com>
Jan Kiszka (3):
pci: Rework config space blocking services
pci: Introduce INTx check & mask API
uio: Convert uio_generic_pci to new intx masking API
drivers/pci/access.c | 76 +++++++++++++++++----------
drivers/pci/iov.c | 12 ++--
drivers/pci/pci.c | 114 ++++++++++++++++++++++++++++++++++++++++-
drivers/pci/pci.h | 2 +
drivers/scsi/ipr.c | 66 +++++++++++++++++++++---
drivers/scsi/ipr.h | 1 +
drivers/uio/uio_pci_generic.c | 82 +++---------------------------
include/linux/pci.h | 17 ++++--
8 files changed, 248 insertions(+), 122 deletions(-)
--
1.7.3.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists