Check whether we evaluated _ADR successfully. Previously we ignored
failure, so we would have used garbage data from the stack as the device
and function number.
We return AE_OK so that we ignore only this slot and continue looking
for other slots.
Bjorn Helgaas [Tue, 19 Jun 2012 13:45:44 +0000 (07:45 -0600)]
PCI: fix P2P bridge I/O port window sign extension
On P2P bridges with 32-bit I/O decoding, we incorrectly sign-extended
windows starting at 0x80000000 or above. In "base |= (io_base_hi << 16)",
"io_base_hi" is promoted to a signed int before being extended to an
unsigned long.
This would cause a window starting at I/O address 0x80000000 to be
treated as though it started at 0xffffffff80008000 instead, which
should cause "no compatible bridge window" errors when we enumerate
devices using that I/O space.
The mmio and mmio_pref casts are not strictly necessary, but without
them, correctness depends on the types of the PCI_MEMORY_RANGE_MASK and
PCI_PREF_RANGE_MASK constants, which are not obvious from reading the
local code.
Bjorn Helgaas [Tue, 19 Jun 2012 13:35:34 +0000 (07:35 -0600)]
PCI: fix upstream P2P bridge checks when enabling OBFF and LTR
pci_enable_obff() and pci_enable_ltr() incorrectly check "dev->bus" instead
of "dev->bus->self" to determine whether the upstream device is a P2P
bridge or a host bridge. For devices on the root bus, the upstream device
is a host bridge, "dev->bus != NULL" and "dev->bus->self == NULL", and we
panic with a null pointer dereference.
These functions should previously have panicked when called on devices
supporting OBFF or LTR, so they should be regarded as untested.
Warning(drivers/pci/setup-bus.c:277): No description found for parameter 'fail_head'
Warning(drivers/pci/setup-bus.c:277): Excess function parameter 'failed_list' description in 'assign_requested_resources_sorted'
Signed-off-by: Wanpeng Li <liwp.linux@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Bjorn Helgaas [Mon, 18 Jun 2012 18:14:10 +0000 (12:14 -0600)]
Merge branch 'topic/sebastian-devinit-fixups' into next
* topic/sebastian-devinit-fixups:
scripts/modpost: check for bad references in .pci.fixups area
sh/PCI: move fixup hooks from __init to __devinit
powerpc/PCI: move fixup hooks from __init to __devinit
frv/PCI: move fixup hooks from __init to __devinit
arm/PCI: move fixup hooks from __init to __devinit
alpha/PCI: move fixup hooks from __init to __devinit
PCI: move fixup hooks from __init to __devinit
x86/PCI: move fixup hooks from __init to __devinit
Alex Williamson [Thu, 7 Jun 2012 17:01:59 +0000 (11:01 -0600)]
PCI: add Ralink RT2800 broken INTx masking quirk
Passes pci_intx_mask_supported test but continues to send interrupts
as discovered through VFIO-based device assignment.
http://www.spinics.net/lists/kvm/msg73738.html
[bhelgaas: use HEADER, not FINAL, which is currently broken for hotplug] Tested-by: Andreas Hartmann <andihartmann@01019freenet.de> Signed-off-by: Alex Williamson <alex.williamson@redhat.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
the T310 does not properly support INTx masking as it fails to keep the
PCI_STATUS_INTERRUPT bit updated once the interrupt is masked. Mark this
adapter as broken so that pci_intx_mask_supported won't report it as
compatible.
[bhelgaas: use HEADER, not FINAL, which is currently broken for hotplug] Tested-by: Alexey Kardashevskiy <aik@ozlabs.ru> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Bjorn Helgaas [Sat, 16 Jun 2012 20:40:22 +0000 (14:40 -0600)]
PCI: add infrastructure for devices with broken INTx masking
pci_intx_mask_supported() assumes INTx masking is supported if the
PCI_COMMAND_INTX_DISABLE bit is writable. But when that bit is set,
some devices don't actually mask INTx or update PCI_STATUS_INTERRUPT
as we expect.
This patch adds a way for quirks to identify these broken devices.
[bhelgaas: split out from Chelsio quirk addition] Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
scripts/modpost: check for bad references in .pci.fixups area
Functions used for PCI fixups (like DECLARE_PCI_FIXUP_HEADER) are often
marked __init. This is okay as long as nobody is using PCI hotplug.
However if one does execute
| echo 1 > /sys/bus/pci/rescan
and we hit a module which is marked __init istead of __devinit then we
go boom because the code is removed after the kernel booted. This patch
help to see those section mismatches.
Cc: Michal Marek <mmarek@suse.cz> Cc: linux-kbuild@vger.kernel.org Cc: Rusty Russell <rusty@rustcorp.com.au> Signed-off-by: Sebastian Andrzej Siewior <sebastian@breakpoint.cc> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
The fixups are executed once the pci-device is found which is during
boot process so __init seems fine as long as the platform does not
support hotplug.
However it is possible to remove the PCI bus at run time and have it
rediscovered again via "echo 1 > /sys/bus/pci/rescan" and this will call
the fixups again.
Cc: Paul Mundt <lethal@linux-sh.org> Signed-off-by: Sebastian Andrzej Siewior <sebastian@breakpoint.cc> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
powerpc/PCI: move fixup hooks from __init to __devinit
The fixups are executed once the pci-device is found which is during
boot process so __init seems fine as long as the platform does not
support hotplug.
However it is possible to remove the PCI bus at run time and have it
rediscovered again via "echo 1 > /sys/bus/pci/rescan" and this will call
the fixups again.
Cc: Kumar Gala <galak@kernel.crashing.org> Cc: Paul Mackerras <paulus@samba.org> Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Sebastian Andrzej Siewior <sebastian@breakpoint.cc> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Bjorn Helgaas [Wed, 13 Jun 2012 23:04:40 +0000 (17:04 -0600)]
Merge branch 'topic/kong-acpiphp-remove' into next
* topic/kong-acpiphp-remove:
PCI: acpiphp: remove all functions in slot, even without ACPI _EJx
PCI: acpiphp: fix function 0 leak when disabling a slot
Amos Kong [Wed, 23 May 2012 16:20:35 +0000 (10:20 -0600)]
PCI: acpiphp: remove all functions in slot, even without ACPI _EJx
When we add a device with acpiphp, we enumerate all functions in the
slot with pci_scan_slot(), regardless of whether they have associated
ACPI methods such as _EJ0.
When removing the device, we previously removed only the functions
with those ACPI methods. This patch makes the remove symmetric with the
add: we remove all functions in the slot, whether they have associated
ACPI methods or not.
With qemu-kvm and SeaBIOS, we can build a multi-function device where
only function 0 has _EJ0 and _ADR (see bugzilla below). Removing and
re-adding that slot (including all functions of the device) works correctly
with Windows guests. This patch makes it also work in Linux guests.
[bhelgaas: restructure loop iteration, pull out of slot->funcs loop]
Reference: https://bugzilla.kernel.org/show_bug.cgi?id=43219 Signed-off-by: Amos Kong <kongjianjun@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Amos Kong [Wed, 23 May 2012 03:58:40 +0000 (21:58 -0600)]
PCI: acpiphp: fix function 0 leak when disabling a slot
Previously, we acquired two references to function 0, but only released
one.
[bhelgaas: split this out from "remove all functions" fix] Signed-off-by: Amos Kong <kongjianjun@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Yinghai Lu [Fri, 18 May 2012 01:58:41 +0000 (18:58 -0700)]
PCI: pciehp: use generic pci_hp_add_bridge()
Use the new generic pci_hp_add_bridge() interface.
[bhelgaas: split "add generic pci_hp_add_bridge()" into a separate patch] Signed-off-by: Yinghai Lu <yinghai@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Yinghai Lu [Fri, 18 May 2012 01:51:12 +0000 (18:51 -0700)]
parisc/PCI: register busn_res for root buses
Add the host bridge bus number aperture to the resource list.
Like the MMIO and I/O port apertures, this is used when assigning
resources to hot-added devices or in the case of conflicts.
[bhelgaas: changelog, set flags directly, at LBA bus_num init] CC: Kyle McMartin <kyle@mcmartin.ca> CC: Helge Deller <deller@gmx.de> CC: linux-parisc@vger.kernel.org Signed-off-by: Yinghai Lu <yinghai@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Yinghai Lu [Fri, 18 May 2012 01:51:12 +0000 (18:51 -0700)]
powerpc/PCI: register busn_res for root buses
Add the host bridge bus number aperture to the resource list.
Like the MMIO and I/O port apertures, this is used when assigning
resources to hot-added devices or in the case of conflicts.
[bhelgaas: changelog] CC: Paul Mackerras <paulus@samba.org> CC: linuxppc-dev@lists.ozlabs.org CC: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Yinghai Lu <yinghai@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Yinghai Lu [Fri, 18 May 2012 01:51:12 +0000 (18:51 -0700)]
sparc/PCI: register busn_res for root buses
Add the host bridge bus number aperture to the resource list.
Like the MMIO and I/O port apertures, this is used when assigning
resources to hot-added devices or in the case of conflicts.
[bhelgaas: changelog, fix "pci_last_busn" typo] Acked-by: "David S. Miller" <davem@davemloft.net> CC: sparclinux@vger.kernel.org Signed-off-by: Yinghai Lu <yinghai@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Yinghai Lu [Fri, 18 May 2012 01:51:12 +0000 (18:51 -0700)]
ia64/PCI: register busn_res for root buses
Add the host bridge bus number aperture from _CRS to the resource list.
Like the MMIO and I/O port apertures, this is used when assigning
resources to hot-added devices or in the case of conflicts.
[bhelgaas: changelog] CC: Tony Luck <tony.luck@intel.com> CC: Fenghua Yu <fenghua.yu@intel.com> CC: linux-ia64@vger.kernel.org Signed-off-by: Yinghai Lu <yinghai@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Yinghai Lu [Fri, 18 May 2012 01:51:12 +0000 (18:51 -0700)]
x86/PCI: put busn resource in pci_root_info for native host bridge drivers
Add the host bridge bus number aperture to the resource list.
Like the MMIO and I/O port apertures, this will be used when assigning
resources to hot-added devices or in the case of conflicts.
Yinghai Lu [Fri, 18 May 2012 01:51:12 +0000 (18:51 -0700)]
x86/PCI: use _CRS bus number aperture for host bridges from ACPI
Add the host bridge bus number aperture from _CRS to the resource list.
Like the MMIO and I/O port apertures, this will be used when assigning
resources to hot-added devices or in the case of conflicts.
Note that we always use the _CRS bus number aperture, even if we're
ignoring _CRS otherwise.
[bhelgaas: changelog] Signed-off-by: Yinghai Lu <yinghai@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Yinghai Lu [Fri, 18 May 2012 01:51:12 +0000 (18:51 -0700)]
PCI: checking busn_res in pci_scan_root_bus()
Some callers do not supply the bus number aperture, usually because they do
not know the end. In this case, we assume the aperture extends from the
root bus number to bus 255, scan the bus, and shrink the bus number
resource so it ends at the largest bus number we found.
This is obviously not correct because the actual end of the aperture may
well be larger than the largest bus number we found. But I guess it's all
we have for now.
Also print out one info about that, so we could find out which path
does not have busn_res in resources list.
[bhelgaas: changelog, _safe iterator unnecessary, use %pR format for bus] Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Yinghai Lu [Fri, 18 May 2012 01:51:11 +0000 (18:51 -0700)]
PCI: build a bus number resource tree for every domain
This adds get_pci_domain_busn_res(), which returns the root of the
bus number resource tree for a domain, creating it if necessary.
We will later populate the tree with the bus numbers used by host
bridges and P2P bridges in the domain.
[bhelgaas: changelog] Signed-off-by: Yinghai Lu <yinghai@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Yinghai Lu [Fri, 18 May 2012 01:51:11 +0000 (18:51 -0700)]
PCI: add busn_res in struct pci_bus
This adds a busn_res resource in struct pci_bus. This will replace the
secondary/subordinate members and will be used to build a bus number
resource tree to help with bus number allocation.
[bhelgaas: changelog] CC: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Yinghai Lu <yinghai@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Alex Williamson [Mon, 11 Jun 2012 05:27:07 +0000 (05:27 +0000)]
PCI: add ACS validation utility
In a PCI environment, transactions aren't always required to reach
the root bus before being re-routed. Intermediate switches between
an endpoint and the root bus can redirect DMA back downstream before
things like IOMMUs have a chance to intervene. Legacy PCI is always
susceptible to this as it operates on a shared bus. PCIe added a
new capability to describe and control this behavior, Access Control
Services, or ACS.
The utility function pci_acs_enabled() allows us to test the ACS
capabilities of an individual devices against a set of flags while
pci_acs_path_enabled() tests a complete path from a given downstream
device up to the specified upstream device. We also include the
ability to add device specific tests as it's likely we'll see
devices that do not implement ACS, but want to indicate support
for various capabilities in this space.
Signed-off-by: Alex Williamson <alex.williamson@redhat.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
frv/PCI: move fixup hooks from __init to __devinit
The fixups are executed once the pci-device is found which is during
boot process so __init seems fine as long as the platform does not
support hotplug.
However it is possible to remove the PCI bus at run time and have it
rediscovered again via "echo 1 > /sys/bus/pci/rescan" and this will call
the fixups again.
Cc: David Howells <dhowells@redhat.com> Signed-off-by: Sebastian Andrzej Siewior <sebastian@breakpoint.cc> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
arm/PCI: move fixup hooks from __init to __devinit
The fixups are executed once the pci-device is found which is during
boot process so __init seems fine as long as the platform does not
support hotplug.
However it is possible to remove the PCI bus at run time and have it
rediscovered again via "echo 1 > /sys/bus/pci/rescan" and this will call
the fixups again.
Cc: Russell King <linux@arm.linux.org.uk> Signed-off-by: Sebastian Andrzej Siewior <sebastian@breakpoint.cc> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
alpha/PCI: move fixup hooks from __init to __devinit
The fixups are executed once the pci-device is found which is during
boot process so __init seems fine as long as the platform does not
support hotplug.
However it is possible to remove the PCI bus at run time and have it
rediscovered again via "echo 1 > /sys/bus/pci/rescan" and this will call
the fixups again.
Cc: Richard Henderson <rth@twiddle.net> Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru> Cc: Matt Turner <mattst88@gmail.com> Signed-off-by: Sebastian Andrzej Siewior <sebastian@breakpoint.cc> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
The fixups are executed once the pci-device is found which is during
boot process so __init seems fine as long as the platform does not
support hotplug.
However it is possible to remove the PCI bus at run time and have it
rediscovered again via "echo 1 > /sys/bus/pci/rescan" and this will call
the fixups again.
Signed-off-by: Sebastian Andrzej Siewior <sebastian@breakpoint.cc> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
x86/PCI: move fixup hooks from __init to __devinit
The fixups are executed once the pci-device is found which is during
boot process so __init seems fine as long as the platform does not
support hotplug.
However it is possible to remove the PCI bus at run time and have it
rediscovered again via "echo 1 > /sys/bus/pci/rescan" and this will call
the fixups again.
Cc: x86@kernel.org Signed-off-by: Sebastian Andrzej Siewior <sebastian@breakpoint.cc> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Myron Stowe [Fri, 1 Jun 2012 21:16:43 +0000 (15:16 -0600)]
PCI: remove redundant capabilities checking in pci_{save, restore}_pcie_state
Unlike PCI Express v1's Capabilities Structure, v2's requires the entire
structure to be implemented. In v2 structures, register fields that
are not implemented are present but hardwired to 0x0. These may
include: Link Capabilities, Status, and Control; Slot Capabilities,
Status, and Control; Root Capabilities, Status, and Control; and all of
the '2' (Device, Link, and Slot) Capabilities, Status, and Control
registers.
This patch removes the redundant capability checks corresponding to the
Link 2's and Slot 2's, Capabilities, Status, and Control registers as they
will be present if Device Capabilities 2's registers are (which explains
why the macros for each of the three are identical).
Myron Stowe [Fri, 1 Jun 2012 21:16:37 +0000 (15:16 -0600)]
PCI: add pci_pcie_cap2() check for PCIe feature capabilities >= v2
This patch resolves potential issues when accessing PCI Express
Capability structures. The makeup of the capability varies
substantially between v1 and v2:
Version 1 of the PCI Express Capability (defined by PCI Express
1.0 and 1.1 base) neither requires the endpoint to implement the
entire PCIe capability structure nor specifies default values of
registers that are not implemented by the device.
Version 2 of the PCI Express Capability (defined by PCIe 1.1
Capability Structure Expansion ECN, PCIe 2.0, 2.1, and 3.0) added
additional registers to the structure and requires all registers
to be either implemented or hardwired to 0.
Due to the differences in the capability structures, code dealing with
capability features must be careful not to access the additional
registers introduced with v2 unless the device is specifically known to
be a v2 capable device. Otherwise, attempts to access non-existant
registers will occur. This is a subtle issue that is hard to track down
when it occurs (and it has - see commit 864d296cf94).
To try and help mitigate such occurrences, this patch introduces
pci_pcie_cap2() which is similar to pci_pcie_cap() but also checks
that the PCIe capability version is >= 2. pci_pcie_cap2() should be
used for qualifying PCIe capability features introduced after v1.
Myron Stowe [Fri, 1 Jun 2012 21:16:25 +0000 (15:16 -0600)]
PCI: make pci_ltr_supported() static
The PCI Express Latency Tolerance Reporting (LTR) feature's
pci_ltr_supported() routine is currently only used within
drivers/pci/pci.c so make it static.
Alex Williamson [Mon, 11 Jun 2012 05:26:55 +0000 (05:26 +0000)]
PCI: add PCI DMA source ID quirk
DMA transactions are tagged with the source ID of the device making
the request. Occasionally hardware screws this up and uses the
source ID of a different device (often the wrong function number of
a multifunction device). A specific Ricoh multifunction device is
a prime example of this problem and included in this patch.
Given a pci_dev, this function returns the pci_dev to use as the
source ID for DMA. When hardware works correctly, this returns
the input device. For the components of the Ricoh multifunction
device, it returns the pci_dev for function 0.
This will be used by IOMMU drivers for determining the boundaries
of IOMMU groups as multiple devices using the same source ID must
be contained within the same group. This can also be used by
existing streaming DMA paths for the same purpose.
[bhelgaas: fold in pci_dev_get() for !CONFIG_PCI] Signed-off-by: Alex Williamson <alex.williamson@redhat.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
David Rientjes [Fri, 8 Jun 2012 20:21:26 +0000 (13:21 -0700)]
mm, oom: fix badness score underflow
If the privileges given to root threads (3% of allowable memory) or a
negative value of /proc/pid/oom_score_adj happen to exceed the amount of
rss of a thread, its badness score overflows as a result of commit a7f638f999ff ("mm, oom: normalize oom scores to oom_score_adj scale only
for userspace").
Fix this by making the type signed and return 1, meaning the thread is
still eligible for kill, if the value is negative.
Reported-by: Dave Jones <davej@redhat.com> Acked-by: Oleg Nesterov <oleg@redhat.com> Signed-off-by: David Rientjes <rientjes@google.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Randy Dunlap [Fri, 8 Jun 2012 20:18:33 +0000 (13:18 -0700)]
sched/fair: fix lots of kernel-doc warnings
Fix lots of new kernel-doc warnings in kernel/sched/fair.c:
Warning(kernel/sched/fair.c:3625): No description found for parameter 'env'
Warning(kernel/sched/fair.c:3625): Excess function parameter 'sd' description in 'update_sg_lb_stats'
Warning(kernel/sched/fair.c:3735): No description found for parameter 'env'
Warning(kernel/sched/fair.c:3735): Excess function parameter 'sd' description in 'update_sd_pick_busiest'
Warning(kernel/sched/fair.c:3735): Excess function parameter 'this_cpu' description in 'update_sd_pick_busiest'
.. more warnings
Signed-off-by: Randy Dunlap <rdunlap@xenotime.net> Cc: Ingo Molnar <mingo@redhat.com> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
It incorrectly finds VGA connectors where none are attached, apparently
not noticing that nothing replied to the EDID queries, and happily using
the default EDID modes that have nothing to do with actual hardware.
That in turn then causes X to fall down to the lowest common
denominator, which is usually the default 1024x768 mode that is in the
default EDID and pretty much anything supports).
I'd suggest that if not relying on the HDP pin, the code should at least
check whether it gets valid EDID data back, rather than just assume
there's something on the VGA connector.
Cc: Dave Airlie <airlied@linux.ie> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Linus Torvalds [Fri, 8 Jun 2012 18:15:31 +0000 (11:15 -0700)]
Merge tag 'ext4_for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4
Pull ext4 bug fixes from Theodore Ts'o:
"This update contains two bug fixes, both destined for the stable tree.
Perhaps the most important is one which fixes ext4 when used with file
systems originally formatted for use with ext3, but then later
converted to take advantage of ext4."
* tag 'ext4_for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4:
ext4: don't set i_flags in EXT4_IOC_SETFLAGS
ext4: fix the free blocks calculation for ext3 file systems w/ uninit_bg
Linus Torvalds [Fri, 8 Jun 2012 18:06:01 +0000 (11:06 -0700)]
Merge branch 'merge' of git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc
Pull powerpc fixes from Paul Mackerras:
"Two small fixes for powerpc:
- a fix for a regression since 3.2 that causes 4-second (or longer)
pauses
- a fix for a potential oops when loading kernel modules on 32-bit
embedded systems."
* 'merge' of git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc:
powerpc: Fix kernel panic during kernel module load
powerpc/time: Sanity check of decrementer expiration is necessary
Linus Torvalds [Fri, 8 Jun 2012 18:04:06 +0000 (11:04 -0700)]
Merge tag 'upstream-3.5-rc2' of git://git.infradead.org/linux-ubifs
Pull UBI/UBIFS fixes from Artem Bityutskiy:
"Fix UBI and UBIFS - they refuse to work without debugfs. This was
broken by the 3.5-rc1 UBI/UBIFS changes when we removed the debugging
Kconfig switches.
Also, correct locking in 'ubi_wl_flush()' - it was extended to support
flushing a specific LEB in 3.5-rc1, and the locking was sub-optimal."
* tag 'upstream-3.5-rc2' of git://git.infradead.org/linux-ubifs:
UBI: correct ubi_wl_flush locking
UBIFS: fix debugfs-less systems support
UBI: fix debugfs-less systems support
We're chasing an elusive bug that Dave Jones can apparently reproduce
using his system call fuzzer tool, and that looks like some kind of
locking ordering problem on the directory i_mutex chain. Our i_mutex
locking is rather complex, and depends on the topological ordering of
the directories, which is why we have been very wary of splicing
directory entries around.
Of course, we really don't want to ever see aliased unconnected
directories anyway, so none of this should ever happen, but this revert
aims to basically get us back to a known older state.
Bruce points to some of the previous discussion at
It should be noted that it's possible that Dave's problems come from
other changes altohgether, including possibly just the fact that Dave
constantly is teachning his fuzzer new tricks. So what appears to be a
new bug could in fact be an old one that just gets newly triggered, but
reverting these patches as "still under heavy discussion" is the right
thing regardless.
Requested-by: Al Viro <viro@zeniv.linux.org.uk> Acked-by: J. Bruce Fields <bfields@fieldses.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Linus Torvalds [Fri, 8 Jun 2012 16:26:55 +0000 (09:26 -0700)]
Merge branch 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull x86 fixes from Ingo Molnar.
* 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
x86/nmi: Fix section mismatch warnings on 32-bit
x86/uv: Fix UV2 BAU legacy mode
x86/mm: Only add extra pages count for the first memory range during pre-allocation early page table space
x86, efi stub: Add .reloc section back into image
x86/ioapic: Fix NULL pointer dereference on CPU hotplug after disabling irqs
x86/reboot: Fix a warning message triggered by stop_other_cpus()
x86/intel/moorestown: Change intel_scu_devices_create() to __devinit
x86/numa: Set numa_nodes_parsed at acpi_numa_memory_affinity_init()
x86/gart: Fix kmemleak warning
x86: mce: Add the dropped timer interval init back
x86/mce: Fix the MCE poll timer logic
Linus Torvalds [Fri, 8 Jun 2012 16:14:46 +0000 (09:14 -0700)]
Merge branch 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull perf fixes from Ingo Molnar:
"A bit larger than what I'd wish for - half of it is due to hw driver
updates to Intel Ivy-Bridge which info got recently released,
cycles:pp should work there now too, amongst other things. (but we
are generally making exceptions for hardware enablement of this type.)
There are also callchain fixes in it - responding to mostly
theoretical (but valid) concerns. The tooling side sports perf.data
endianness/portability fixes which did not make it for the merge
window - and various other fixes as well."
* 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: (26 commits)
perf/x86: Check user address explicitly in copy_from_user_nmi()
perf/x86: Check if user fp is valid
perf: Limit callchains to 127
perf/x86: Allow multiple stacks
perf/x86: Update SNB PEBS constraints
perf/x86: Enable/Add IvyBridge hardware support
perf/x86: Implement cycles:p for SNB/IVB
perf/x86: Fix Intel shared extra MSR allocation
x86/decoder: Fix bsr/bsf/jmpe decoding with operand-size prefix
perf: Remove duplicate invocation on perf_event_for_each
perf uprobes: Remove unnecessary check before strlist__delete
perf symbols: Check for valid dso before creating map
perf evsel: Fix 32 bit values endianity swap for sample_id_all header
perf session: Handle endianity swap on sample_id_all header data
perf symbols: Handle different endians properly during symbol load
perf evlist: Pass third argument to ioctl explicitly
perf tools: Update ioctl documentation for PERF_IOC_FLAG_GROUP
perf tools: Make --version show kernel version instead of pull req tag
perf tools: Check if callchain is corrupted
perf callchain: Make callchain cursors TLS
...
Linus Torvalds [Fri, 8 Jun 2012 16:12:21 +0000 (09:12 -0700)]
Merge branch 'drm-fixes' of git://people.freedesktop.org/~airlied/linux
Pull drm intel and exynos fixes from Dave Airlie:
"A bunch of fixes for Intel and exynos, nothing too major, a new intel
PCI ID, and a fix for CRT detection."
* 'drm-fixes' of git://people.freedesktop.org/~airlied/linux:
drm/i915: pch_irq_handler -> {ibx, cpt}_irq_handler
char/agp: add another Ironlake host bridge
drm/i915: fix up ivb plane 3 pageflips
drm/exynos: fixed blending for hdmi graphic layer
drm/exynos: Remove dummy encoder get_crtc operation implementation
drm/exynos: Keep a reference to frame buffer GEM objects
drm/exynos: Don't cast GEM object to Exynos GEM object when not needed
drm/exynos: DRIVER_BUS_PLATFORM is not a driver feature
drm/exynos: fixed size type.
drm/exynos: Use DRM_FORMAT_{NV12, YUV420} instead of DRM_FORMAT_{NV12M, YUV420M}
drm/i915: hold forcewake around ring hw init
drm/i915: Mark the ringbuffers as being in the GTT domain
drm/i915/crt: Do not rely upon the HPD presence pin
drm/i915: Reset last_retired_head when resetting ring
Linus Torvalds [Fri, 8 Jun 2012 16:10:35 +0000 (09:10 -0700)]
Merge tag 'moduleparam-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux-2.6-for-linus
Pull minor module param fixes from Rusty Russell:
"One bugfix for multiple moduleparam levels, one removal of overzealous
printk."
* tag 'moduleparam-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux-2.6-for-linus:
init: Drop initcall level output
module_param: stop double-calling parameters.
WARNING: arch/x86/built-in.o(.data+0x5af0): Section mismatch in
reference from the variable test_nmi_ipi_callback_na.10451 to
the function .init.text:test_nmi_ipi_callback() [...]
WARNING: arch/x86/built-in.o(.data+0x5b04): Section mismatch in
reference from the variable nmi_unk_cb_na.10399 to the function
.init.text:nmi_unk_cb() The variable nmi_unk_cb_na.10399
references the function __init nmi_unk_cb() [...]
Both of these are attributed to the internal representation of
the nmiaction struct created during register_nmi_handler. The
reason for this is that those structs are not defined in the
init section whereas the rest of the code in nmi_selftest.c is.
To resolve this, I created a new #define,
register_nmi_handler_initonly, that tags the struct as
__initdata to resolve the mismatch. This #define should only be
used in rare situations where the register/unregister is called
during init of the kernel.
Big thanks to Jan Beulich for decoding this for me as I didn't
have a clue what was going on.
Steffen Rumler [Wed, 6 Jun 2012 14:37:17 +0000 (16:37 +0200)]
powerpc: Fix kernel panic during kernel module load
This fixes a problem which can causes kernel oopses while loading
a kernel module.
According to the PowerPC EABI specification, GPR r11 is assigned
the dedicated function to point to the previous stack frame.
In the powerpc-specific kernel module loader, do_plt_call()
(in arch/powerpc/kernel/module_32.c), GPR r11 is also used
to generate trampoline code.
This combination crashes the kernel, in the case where the compiler
chooses to use a helper function for saving GPRs on entry, and the
module loader has placed the .init.text section far away from the
.text section, meaning that it has to generate a trampoline for
functions in the .init.text section to call the GPR save helper.
Because the trampoline trashes r11, references to the stack frame
using r11 can cause an oops.
The fix just uses GPR r12 instead of GPR r11 for generating the
trampoline code. According to the statements from Freescale, this is
safe from an EABI perspective.
I've tested the fix for kernel 2.6.33 on MPC8541.
Cc: stable@vger.kernel.org Signed-off-by: Steffen Rumler <steffen.rumler.ext@nsn.com>
[paulus@samba.org: reworded the description] Signed-off-by: Paul Mackerras <paulus@samba.org>
Cliff Wickman [Thu, 7 Jun 2012 13:31:40 +0000 (08:31 -0500)]
x86/uv: Fix UV2 BAU legacy mode
The SGI Altix UV2 BAU (Broadcast Assist Unit) as used for
tlb-shootdown (selective broadcast mode) always uses UV2
broadcast descriptor format. There is no need to clear the
'legacy' (UV1) mode, because the hardware always uses UV2 mode
for selective broadcast.
But the BIOS uses general broadcast and legacy mode, and the
hardware pays attention to the legacy mode bit for general
broadcast. So the kernel must not clear that mode bit.
Dave Airlie [Fri, 8 Jun 2012 08:42:51 +0000 (09:42 +0100)]
Merge branch 'exynos-drm-fixes' of git://git.infradead.org/users/kmpark/linux-samsung into drm-fixes
* 'exynos-drm-fixes' of git://git.infradead.org/users/kmpark/linux-samsung:
drm/exynos: fixed blending for hdmi graphic layer
drm/exynos: Remove dummy encoder get_crtc operation implementation
drm/exynos: Keep a reference to frame buffer GEM objects
drm/exynos: Don't cast GEM object to Exynos GEM object when not needed
drm/exynos: DRIVER_BUS_PLATFORM is not a driver feature
drm/exynos: fixed size type.
drm/exynos: Use DRM_FORMAT_{NV12, YUV420} instead of DRM_FORMAT_{NV12M, YUV420M}
Dave Airlie [Fri, 8 Jun 2012 08:42:35 +0000 (09:42 +0100)]
Merge branch 'drm-intel-fixes' of git://people.freedesktop.org/~danvet/drm-intel into drm-fixes
* 'drm-intel-fixes' of git://people.freedesktop.org/~danvet/drm-intel:
drm/i915: pch_irq_handler -> {ibx, cpt}_irq_handler
char/agp: add another Ironlake host bridge
drm/i915: fix up ivb plane 3 pageflips
drm/i915: hold forcewake around ring hw init
drm/i915: Mark the ringbuffers as being in the GTT domain
drm/i915/crt: Do not rely upon the HPD presence pin
drm/i915: Reset last_retired_head when resetting ring
but they don't contain any info for the general user staring at dmesg.
I'm very doubtful the count of initcalls registered per level helps
anyone so drop that output completely.
Cc: Jim Cromie <jim.cromie@gmail.com> Cc: Rusty Russell <rusty@rustcorp.com.au> Cc: Jason Baron <jbaron@redhat.com> Signed-off-by: Borislav Petkov <borislav.petkov@amd.com> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Rusty Russell [Fri, 8 Jun 2012 05:28:13 +0000 (14:58 +0930)]
module_param: stop double-calling parameters.
Commit 026cee0086fe1df4cf74691cf273062cc769617d "params:
<level>_initcall-like kernel parameters" set old-style module
parameters to level 0. And we call those level 0 calls where we used
to, early in start_kernel().
We also loop through the initcall levels and call the levelled
module_params before the corresponding initcall. Unfortunately level
0 is early_init(), so we call the standard module_param calls twice.
(Turns out most things don't care, but at least ubi.mtd does).
Change the level to -1 for standard module_param calls.
Reported-by: Benoît Thébaudeau <benoit.thebaudeau@advansee.com> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> Cc: stable@kernel.org
Paul Mackerras [Fri, 1 Jun 2012 08:13:43 +0000 (18:13 +1000)]
powerpc/time: Sanity check of decrementer expiration is necessary
This reverts 68568add2c ("powerpc/time: Remove unnecessary sanity check
of decrementer expiration"). We do need to check whether we have reached
the expiration time of the next event, because we sometimes get an early
decrementer interrupt, most notably when we set the decrementer to 1 in
arch_irq_work_raise(). The effect of not having the sanity check is that
if timer_interrupt() gets called early, we leave the decrementer set to
its maximum value, which means we then don't get any more decrementer
interrupts for about 4 seconds (or longer, depending on timebase
frequency). I saw these pauses as a consequence of getting a stray
hypervisor decrementer interrupt left over from exiting a KVM guest.
This isn't quite a straight revert because of changes to the surrounding
code, but it restores the same algorithm as was previously used.
Cc: stable@vger.kernel.org Acked-by: Anton Blanchard <anton@samba.org> Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
It's horribly and utterly broken for at least the following reasons:
- calling sync_mm_rss() from mmput() is fundamentally wrong, because
there's absolutely no reason to believe that the task that does the
mmput() always does it on its own VM. Example: fork, ptrace, /proc -
you name it.
- calling it *after* having done mmdrop() on it is doubly insane, since
the mm struct may well be gone now.
- testing mm against NULL before you call it is insane too, since a
NULL mm there would have caused oopses long before.
.. and those are just the three bugs I found before I decided to give up
looking for me and revert it asap. I should have caught it before I
even took it, but I trusted Andrew too much.
Cc: Konstantin Khlebnikov <khlebnikov@openvz.org> Cc: Markus Trippelsdorf <markus@trippelsdorf.de> Cc: Hugh Dickins <hughd@google.com> Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> Cc: Oleg Nesterov <oleg@redhat.com> Cc: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
projects / linux-beck.git / log