find_vma() can be called by multiple threads with read lock
held on mm->mmap_sem and any of them can update mm->mmap_cache.
Prevent compiler from re-fetching mm->mmap_cache, because other
readers could update it in the meantime:
thread 1 thread 2
|
find_vma() | find_vma()
struct vm_area_struct *vma = NULL; |
vma = mm->mmap_cache; |
if (!(vma && vma->vm_end > addr |
&& vma->vm_start <= addr)) { |
| mm->mmap_cache = vma;
return vma; |
^^ compiler may optimize this |
local variable out and re-read |
mm->mmap_cache |
This issue can be reproduced with gcc-4.8.0-1 on s390x by running
mallocstress testcase from LTP, which triggers:
kernel BUG at mm/rmap.c:1088!
Call Trace:
([<000003d100c57000>] 0x3d100c57000)
[<000000000023a1c0>] do_wp_page+0x2fc/0xa88
[<000000000023baae>] handle_pte_fault+0x41a/0xac8
[<000000000023d832>] handle_mm_fault+0x17a/0x268
[<000000000060507a>] do_protection_exception+0x1e2/0x394
[<0000000000603a04>] pgm_check_handler+0x138/0x13c
[<000003fffcf1f07a>] 0x3fffcf1f07a
Last Breaking-Event-Address:
[<000000000024755e>] page_add_new_anon_rmap+0xc2/0x168
Thanks to Jakub Jelinek for his insight on gcc and helping to
track this down.
Signed-off-by: Jan Stancek <jstancek@redhat.com>
Acked-by: David Rientjes <rientjes@google.com>
Signed-off-by: Hugh Dickins <hughd@google.com>
Cc: stable@vger.kernel.org
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
mounted R/O and then remounted R/W.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iQIcBAABAgAGBQJRXZxUAAoJECmIfjd9wqK0jTUP/2QvNLRxMwKp984D0M6euIPg
fMGsz73wwB+d0P1AlOIP2y5DG787SGDmmpP9SPFWiI9QH+vuJUlp01Di2MxJFGiL
yh9iuhJ0MHGQFIKbSuolGiooJIABnQi9629L29Li8wbGrbwWK7WI+bQfb7EaTLSN
1c4PX+42fAi6UP84IXtkFHl3hbGSuZ9+dSPJ0U6VAuLl0zQRv6PxIxwR+Fqi1Wqq
VJXrU6bkUbbTFndm7UfkQGQ+Z4DQ5gnXnSdUHkd6dsPoLqNyIor7AjW5/IKvTPkN
5OBpLv7Eo4WBiozlJdu2I26HBgyyQKIgL9HA2CYSoFzopl8Pa+lhoNPOseA6axMq
abXK2nRGAxmMGkGdUGOlugNylVDpsJJ1cX8mjwX0G3L4aZZBLGflflYo+X8pm1c4
TV+MlloSv4SwKrgpgfiJS7q0kzOMEZNIyoIIPYeMf7VcLsbbDCv2bOTvR3LxL9Bt
TlVESqSlcImsgTG0fMK/YFefpEAkLVJPTw3T25yJ/vtoZsbw4HVa30/A5mleDEUk
b4r43KWW9Nodz81klQUj9WF5aK/7yl2oyNzyIg8CdCY7b2sDyf6ixrkS51mYY3Jm
1PagVOcJZ4CBBrerP13+dc5/9m+rsHkRw9aVvvw2U5cqqVdJnd8EdvHNRCETgTZ6
REd95pyaBsjqBUwkHUVc
=79wn
-----END PGP SIGNATURE-----
Merge tag 'upstream-3.9-rc6' of git://git.infradead.org/linux-ubifs
Pull UBIFS fix from Artem Bityutskiy:
"Make the space fixup feature work in the case when the file-system is
first mounted R/O and then remounted R/W."
* tag 'upstream-3.9-rc6' of git://git.infradead.org/linux-ubifs:
UBIFS: make space fixup work in the remount case
* pm-fixes:
cpufreq: Correct header guards typo
cpufreq: check OF node /cpus presence before dereferencing it
PM / devfreq: Fix compiler warnings for CONFIG_PM_DEVFREQ unset
PM / QoS: Avoid possible deadlock related to sysfs access
USB / PM: Don't try to hide PM QoS flags from usb_port_device_release()
* acpi-fixes:
ACPI / BGRT: Don't let users configure BGRT on non X86 systems
cpuidle / ACPI: recover percpu ACPI processor cstate
ACPI / I2C: Use parent's ACPI_HANDLE() in acpi_i2c_register_devices()
ACPI / SPI: Use parent's ACPI_HANDLE() in acpi_register_spi_devices()
Pull HID fixes from Jiri Kosina:
- Workaround for device ID conflict between Masterkit MA901 usb radio
device and Atmel V-USB devices, to avoid regressions from older
kernels, by Alexey Klimov
- fix for possible race during input device registration in magicmouse
driver, by Benjamin Tissoires
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/hid:
HID: magicmouse: fix race between input_register() and probe()
media: radio-ma901: return ENODEV in probe if usb_device doesn't match
HID: fix Masterkit MA901 hid quirks
- Fix erroneous return value in the ICH driver
- Make the STMPE driver proper properly on device tree boots
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (GNU/Linux)
iQIcBAABAgAGBQJRXURwAAoJEEEQszewGV1zH1oQALDh9V1Lc8IuEKfhNqw1lWoI
kgoEeHc22ccx8Q2GiP1vSCLZjNH9Z63SEP+DQbSDd2mEI9jePZSkZyR1dXhde6Hv
VSGGTxi2SfJumzaz+BqIpGcTpNfEaipcX8OkYvZFAULa9cGxHOSDXu5rwt3q/vH2
2BVR4/USW6r9QUXnwZXp3WVf7ADyocFvtJZbO7bs8wzcE27A9ur9FFpk9ZvjLUPC
E+oH5Oih9GeuQOVdXJPdF3RN1m/p9DRfa/6acsyvgqAfLsRA7kffGRuXIzE5c3BI
QBNc5UHf0KR+hhwFPsOb37YTBuYOIk9RftYIej7XJymmxaigRucJQMWpCb42ZWEi
oTcR0Ny62v5DsDntqunVuNxRVRENC0fCgPrpcPEJtVruEquzeXc2vbgs6vfto4ng
mb5ewUStCzxYHLAPSJE+sDa9odsHK4akb7NEetHTFz8Gr6OZrUtomgDBa9aMPlOS
RpguIMy1AvFFEUDKOyItOc5mXvYijan8mQACFRcNmz5yH7Cx5ZE6Xg3fYCqAnmrk
Zf4Q/EqejvSqjIwG6kb1hR/uH+lzSFNwJy9GZWRlttG2boAEmDEcCoEC8FLqjd8j
7xzccZa+pA4RLsielZsL7JOE0OJjr5oWXoS2vYzkG5PZO5J+kOpN0xcLb9fd8bUR
SxO7vbNF/bqSJILoeI/Y
=lfbO
-----END PGP SIGNATURE-----
Merge tag 'gpio-fixes-v3.9' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio
Pull GPIO fixes from Linus Walleij:
"Two GPIO fixes for the v3.9 series:
- Fix erroneous return value in the ICH driver
- Make the STMPE driver proper properly on device tree boots"
* tag 'gpio-fixes-v3.9' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio:
gpio: stmpe: pass DT node to irqdomain
gpio-ich: Fix value returned by ichx_gpio_request
This reverts commit 6ab317419c.
The commit [6ab317419c: ALSA: hda - Allow power_save_controller option
override DCAPS] changed the behavior of power_save_controller so that
it can override the driver capability. This assumed that this option
is rarely changed dynamically unlike power_save option. Too naive.
It turned out that the user-space power-management tool tries to set
power_save_controller option to 1 together with power_save option
without knowing what's actually doing. This enabled forcibly the
runtime PM of the controller, which is known to be broken om many
chips thus disabled as default.
So, the only sane fix is to revert this commit again. It was intended
to ease debugging/testing for runtime PM enablement, but obviously we
need another way for it.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=56171
Reported-and-tested-by: Nikita Tsukanov <keks9n@gmail.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Rename "Digitial In" to "Digital In". This function is only used for
proc output, so should not cause any problems to change.
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
When withdraw occurs, we need to continue to allow unlocks of fcntl
locks to occur, however these will only be local, since the node has
withdrawn from the cluster. This prevents triggering a VFS level
bug trap due to locks remaining when a file is closed.
Signed-off-by: Steven Whitehouse <swhiteho@redhat.com>
The error code in gfs2_rs_alloc() is set to ENOMEM when error
but never be used, instead, gfs2_rs_alloc() always return 0.
Fix to return 'error'.
Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Signed-off-by: Steven Whitehouse <swhiteho@redhat.com>
Use memchr_inv to verify that the specified memory range is cleared.
Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com>
Cc: Steven Whitehouse <swhiteho@redhat.com>
Cc: cluster-devel@redhat.com
Cc: Christine Caulfield <ccaulfie@redhat.com>
Cc: David Teigland <teigland@redhat.com>
The temp lvb bitmap was on the stack, which could
be an alignment problem for __set_bit_le. Use
kmalloc for it instead.
Signed-off-by: David Teigland <teigland@redhat.com>
Signed-off-by: Steven Whitehouse <swhiteho@redhat.com>
Since kernel 3.7, it appears that the input registration occured before
the end of magicmouse_setup_input(). This is shown by receiving a lot of
"EV_SYN SYN_REPORT 1" instead of normal "EV_SYN SYN_REPORT 0".
This value means that the output buffer is full, and the user space
is loosing events.
Using .input_configured guarantees that the race is not occuring, and that
the call of "input_set_events_per_packet(input, 60)" is taken into account
by input_register().
Fixes:
https://bugzilla.redhat.com/show_bug.cgi?id=908604
Cc: stable@vger.kernel.org
Reported-and-Tested-By: Clarke Wixon <cwixon@usa.net>
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
* Added the device ID to the modalias list and assinged ALC662 patches
for it
* Added 4 port support for the device ID 0671 in alc662_parse_auto_config
Signed-off-by: Rainer Koenig <Rainer.Koenig@ts.fujitsu.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Pull ARM fixes from Russell King:
"Another round of ARM fixes, which include:
- Fixing a problem with LPAE mapping sections
- Reporting of some hwcaps on Krait CPUs
- Avoiding repetitive warnings in the breakpoint code
- Fixing a build error noticed on Dove platforms with PJ4 CPUs
- Fix masking of level 2 cache revision.
- Fixing timer-based udelay()
- A larger fix for an erratum causing people major grief with Cortex
A15 CPUs"
* 'fixes' of git://git.linaro.org/people/rmk/linux-arm:
ARM: 7690/1: mm: fix CONFIG_LPAE typos
ARM: 7689/1: add unwind annotations to ftrace asm
ARM: 7685/1: delay: use private ticks_per_jiffy field for timer-based delay ops
ARM: 7684/1: errata: Workaround for Cortex-A15 erratum 798181 (TLBI/DSB operations)
ARM: 7682/1: cache-l2x0: fix masking of RTL revision numbering and set_debug init
ARM: iWMMXt: always enable iWMMXt support with PJ4 CPUs
ARM: 7681/1: hw_breakpoint: use warn_once to avoid spam from reset_ctrl_regs()
ARM: 7678/1: Work around faulty ISAR0 register in some Krait CPUs
ARM: 7680/1: Detect support for SDIV/UDIV from ISAR0 register
ARM: 7679/1: Clear IDIVT hwcap if CONFIG_ARM_THUMB=n
ARM: 7677/1: LPAE: Fix mapping in alloc_init_section for unaligned addresses
ARM: KVM: vgic: take distributor lock on sync_hwstate path
ARM: KVM: vgic: force EOIed LRs to the empty state
The runtime PM of PCIe ports turns out to be quite fragile, as in
some cases things work while in some other cases they don't and we
don't seem to have a good way to determine whether or not they are
going to work in advance.
For this reason, avoid enabling runtime PM for PCIe ports by
keeping their runtime PM reference counters always above 0 for the
time being.
When a PCIe port is suspended, it can no longer report events like
hotplug, so hotplug below the port may not work, as in the bug
report below.
[bhelgaas: changelog, stable]
Reference: https://bugzilla.kernel.org/show_bug.cgi?id=53811
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
CC: stable@vger.kernel.org # v3.6+
It turns out that the _Lxx control methods provided by some BIOSes
clear the PME Status bit of PCI devices they handle, which means that
pci_acpi_wake_dev() cannot really use that bit to check whether or
not the device has signalled wakeup.
One symptom of the problem is, for example, that when an affected PCI
USB controller is runtime-suspended, then plugging in a new USB device
into one of the controller's ports will not wake up the controller,
which should happen.
For this reason, make pci_acpi_wake_dev() always attempt to resume
the device it is called for regardless of the device's PME Status bit
value (that bit still has to be cleared if set at this point,
though).
Reported-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Matthew Garrett <mjg59@srcf.ucam.org>
CC: stable@vger.kernel.org # v3.7+
merge window. Fortunately, Cai and Christian noticed before 3.9
shipped.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iQIcBAABCAAGBQJRXG7FAAoJENNvdpvBGATw7GAQALbl5LxmVmGR6JRQzNoINP+H
v29ulo1Kly4j2vt+3b0rXKv9axWl0C/dItFlC/9WqmwuB/0BptBKIVnkKH+6zu2v
F+cO41gfpJo3ozcgsCrjvWfdkTWbjbPTQ4XiQDFILkwiB4R9KdpynKcVcjDY+gQE
umwJpXwDDd+fdr4FNQiFFPqd8rCC8fEeClWTtOFx7UidKl8v18iZ0/OPiAr+jBOY
rlcaZ9F8nmOJTwgriGbod4X827xEDj7Jwe7/C6oy/lKLOTLhaahgHPDW/l0O4KZA
4eJLj/5nxmYling4Y+rQvglVhNJ4LNv+IAXu5IpqRxosPYFnxQq+JYn8D5BlXifd
0/hG+BwTkhm4RLJ8uQvUxxglZNQEWeSuIma4dnZX3Xf9AzsvNW9x3Iilj3F7dhUS
6h9aeoYKv9y7GY9Out1P/UZYVi4HmB3jHiOcdTNCK4plQ3Sn2NYMw6RK1z4cXvE+
Pokc0a9KNyusNSI83tDtjRjan9NzsRbTggoGVf19RVoIVqIjkyXzUGasO/y+mKhp
LENAjkABdbLB1Re8B/99KwgIloUTvxGcojLKzkEbgcobruvEwKvxIrTi+fgNOiu6
GqJOh8TwZtx3SGJujsyOSBBrdPfjPHReBWrX0VRHl/Wsd4RWCaDT8H1EdNONQ+to
lQ+JvTZgFwQB2GABjNB6
=n1ir
-----END PGP SIGNATURE-----
Merge tag 'ext4_for_linus_stable' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4
Pull ext4 fixes from Ted Ts'o:
"Unfortunately, we introduced some big-endian bugs during the last
merge window. Fortunately, Cai and Christian noticed before 3.9
shipped."
* tag 'ext4_for_linus_stable' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4:
ext4: fix big-endian bugs which could cause fs corruptions
Pull reiserfs fix from Jan Kara:
"A fix for reiserfs xattr bug exposed by changes to lookup_one_len()"
* 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs:
reiserfs: Fix warning and inode leak when deleting inode with xattrs
Pull s390 fixes from Martin Schwidefsky:
"Just a bunch of bugfixes"
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux:
s390/mm: provide emtpy check_pgt_cache() function
s390/uaccess: fix page table walk
s390/3270: fix minor_start issue
s390/uaccess: fix clear_user_pt()
s390/scm_blk: fix error return code in scm_blk_init()
s390/scm_block: fix printk format string
drivers/Kconfig: add several missing GENERIC_HARDIRQS dependencies
When an extent was zeroed out, we forgot to do convert from cpu to le16.
It could make us hit a BUG_ON when we try to write dirty pages out. So
fix it.
[ Also fix a bug found by Dmitry Monakhov where we were missing
le32_to_cpu() calls in the new indirect punch hole code.
There are a number of other big endian warnings found by static code
analyzers, but we'll wait for the next merge window to fix them all
up. These fixes are designed to be Obviously Correct by code
inspection, and easy to demonstrate that it won't make any
difference (and hence, won't introduce any bugs) on little endian
architectures such as x86. --tytso ]
Signed-off-by: Zheng Liu <wenqing.lz@taobao.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Reported-by: CAI Qian <caiqian@redhat.com>
Reported-by: Christian Kujau <lists@nerdbynature.de>
Cc: Dmitry Monakhov <dmonakhov@openvz.org>
CONFIG_LPAE doesn't exist: the correct option is CONFIG_ARM_LPAE, so fix
up the two typos under arch/arm/.
The fix to head.S is slightly scary, but this is just for setting up
an early io-mapping for the serial port when running on a big-endian,
LPAE system. Since these systems don't exist in the wild (at least, I
have no access to one outside of kvmtool, which doesn't provide a serial
port suitable for earlyprintk), then we can revisit the code later if it
causes any problems.
Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Add unwind annotations to the ftrace assembly code so that the function
tracer's stacktracing options (func_stack_trace, etc.) work when
CONFIG_ARM_UNWIND is enabled.
Signed-off-by: Rabin Vincent <rabin@rab.in>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Commit 70264367a2 ("ARM: 7653/2: do not scale loops_per_jiffy when
using a constant delay clock") fixed a problem with our timer-based
delay loop, where loops_per_jiffy is scaled by cpufreq yet used directly
by the timer delay ops.
This patch fixes the problem in a more elegant way by keeping a private
ticks_per_jiffy field in the delay ops, independent of loops_per_jiffy
and therefore not subject to scaling. The loop-based delay continues to
use loops_per_jiffy directly, as it should.
Acked-by: Nicolas Pitre <nico@linaro.org>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
On Cortex-A15 (r0p0..r3p2) the TLBI/DSB are not adequately shooting down
all use of the old entries. This patch implements the erratum workaround
which consists of:
1. Dummy TLBIMVAIS and DSB on the CPU doing the TLBI operation.
2. Send IPI to the CPUs that are running the same mm (and ASID) as the
one being invalidated (or all the online CPUs for global pages).
3. CPU receiving the IPI executes a DMB and CLREX (part of the exception
return code already).
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Commit b8db6b8 (ARM: 7547/4: cache-l2x0: add support for Aurora L2 cache
ctrl) moved the masking of the part ID which caused the RTL version to be
lost. Commit 6248d06 (ARM: 7545/1: cache-l2x0: make outer_cache_fns a
field of l2x0_of_data) changed how .set_debug is initialized. Both commits
break commit 74ddcdb (ARM: 7608/1: l2x0: Only set .set_debug
on PL310 r3p0 and earlier) which uses the RTL version to conditionally set
.set_debug function pointer. Commit b8db6b8 also caused the printed cache
ID to be missing the version information.
Fix this by reverting how the part number is masked so the RTL version
info is maintained. The cache-id-part DT property does not set the RTL
bits so masking them should have no effect. Also, re-arrange the order
of the function pointer init so the .set_debug function can be overridden.
Reported-by: Paolo Pisati <paolo.pisati@canonical.com>
Signed-off-by: Rob Herring <rob.herring@calxeda.com>
Cc: Gregory CLEMENT <gregory.clement@free-electrons.com>
Cc: Yehuda Yitschak <yehuday@marvell.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Jason Cooper reports these build errors:
arch/arm/kernel/built-in.o: In function `iwmmxt_do':
/.../arch/arm/kernel/pj4-cp0.c:36: undefined reference to `iwmmxt_task_release'
/.../arch/arm/kernel/pj4-cp0.c:40: undefined reference to `iwmmxt_task_switch'
make: *** [vmlinux] Error 1
This is caused because the PJ4 code explicitly references the iWMMXt
code, but doesn't require it to be built. Fix this by ensuring that
iWMMXt is always enabled with PJ4.
Reported-by: Jason Cooper <jason@lakedaemon.net>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
The C-Media CM6631 USB receiver doesn't respond to changes in sample rate
while the interface is active. The same behavior is observed in other UAC2
hardware like the VIA VT1731.
Reset the interface after setting the sampling frequency on sample rate
changes, to ensure that the sample rate set by snd_usb_init_sample_rate() is
used. Otherwise, the device will try to use the sample rate of the previous
stream, causing distorted sound on sample rate changes.
The reset is performed for all UAC2 devices, as it should not affect a
standards compliant device, but it is only necessary for C-Media CM6631,
VIA VT1731 and possibly others.
Failure to read sample rate from the device is not handled as an error in
set_sample_rate_v2(), as (permanent or intermittent) failure to read sample
rate isn't essential for a successful sample rate set.
Signed-off-by: Torstein Hegge <hegge@resisty.net>
Acked-by: Clemens Ladisch <clemens@ladisch.de>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Fengguang Wu's 0-Day kernel build testing backend found the
following build error for an allmodconfig build on ia64:
drivers/built-in.o: In function `show_yoffset':
>> bgrt.c:(.text+0xe5a71): undefined reference to `bgrt_tab'
>> bgrt.c:(.text+0xe5a91): undefined reference to `bgrt_tab'
drivers/built-in.o: In function `show_xoffset':
>> bgrt.c:(.text+0xe5b51): undefined reference to `bgrt_tab'
>> bgrt.c:(.text+0xe5b71): undefined reference to `bgrt_tab'
drivers/built-in.o: In function `show_type':
>> bgrt.c:(.text+0xe5c31): undefined reference to `bgrt_tab'
drivers/built-in.o:bgrt.c:(.text+0xe5c51): more undefined references to `bgrt_tab' follow
drivers/built-in.o: In function `bgrt_init':
bgrt.c:(.init.text+0x8931): undefined reference to `bgrt_image'
bgrt.c:(.init.text+0x8932): undefined reference to `bgrt_image_size'
bgrt.c:(.init.text+0x8950): undefined reference to `bgrt_image'
bgrt.c:(.init.text+0x8960): undefined reference to `bgrt_image_size'
The problem is that all these undefined names are provided by
arch/x86/platform/efi/efi-bgrt.c - which is obviously not available
to the ia64 build.
It doesn't seem useful to provide the BGRT support for Itanium
(many systems are headless and have no graphics at all). So
just don't let users configure this driver on non-X86 machines.
Reported-by: Fengguang Wu <fengguang.wu@intel.com>
Acked-by: H. Peter Anvin <hpa@zytor.com>
Signed-off-by: Tony Luck <tony.luck@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
The bitmask used for the prefix mangling was being calculated
incorrectly, leading to the wrong part of the address being replaced
when the prefix length wasn't a multiple of 32.
Signed-off-by: Matthias Schiffer <mschiffer@universe-factory.net>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Pull networking fixes from David Miller:
1) Fix VSOCK layer handling of context ID changes, from Reilly Grant.
2) Now that we have a synchronize_net() in netdev_rx_handler_unregister(),
we can't let any call sites hold locks. Unfortunately bonding does,
so we have to drop the rwlock there a little bit earlier, fix from
Veaceslav Falico.
3) MAC address setting loop exits one iteration too early in mlx4
driver, from Yan Burman.
4) Restore ipv6 routes properly upon ifdown/ifup of loopback, from
Balakumaran Kannan.
* git://git.kernel.org/pub/scm/linux/kernel/git/davem/net:
VSOCK: Handle changes to the VMCI context ID.
net IPv6 : Fix broken IPv6 routing table after loopback down-up
cbq: incorrect processing of high limits
net/mlx4_en: Fix setting initial MAC address
bonding: get netdev_rx_handler_unregister out of locks
A small collection of fixes. The most important ones are those from
Stephen and Lars-Peter both of which fix cache issues that have been
lurking for a while but not manifesting noticably enough for anyone to
report them.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iQIcBAABAgAGBQJRWLjSAAoJELSic+t+oim9fHgP/i3g9zqKJM8n4vG/pAi4NJEl
zUgKn5sdHinIqbTZ6712MvMTtiOZtGmarPKHhR63G1Z6jJFFukWuLW4P+KJiIKI/
Gen/gEOt6NEed/Q5es9SRzoP1Nz8EMmht7G7JJ3e1u0+ZRjmdTjNALmr/BV6FwGq
Oul2PpF/O2F08eLl8GtD7wbqbKAq8qOnBjjjTdeJRX7zinDef8PqaCRIASYY5B1Q
i05oREcQt4IaJj5IV7OdXCfuiw2+N2E9gmEYFWOXHpSXmABmgiEYJ5OYjUkPQUHm
Nzf9pRhRgcWFZ/LtKZYZ1o8Vl7SehXUNxWx8QUcm4qohO1Wk/MO7ln+blqpDxuSS
D0DpFS09+o4yB2UR0agX5LyYNyQN8e9kLIf7GfaRyxWERs1g7f2hPehuyz2Pb3AU
L5EvuTl9QXbaNefIJuxaigXo3kK0WUkPEQwJFafQjhmFpa/LJJn2YA4P5zx6ovps
1eby5ssCOANVAASoUIbWqP1xZ1/A3KP6B5okxmSFSruOYaG7AiEW30B1n2dNOZKq
X0ZWwWx+qswQltvqTYcgkMRxiyL69d1MHHSEq4R82e8ZvgCSCb73ImCsy6C3nIQk
aEX6ZiUbLCXO+0mEc7e8airamEG24Y7sMW0kVQ1M3J3XDJdEpX7656IXM6JvVXFm
x4+HNj5yua4yccNZN9KX
=QF+V
-----END PGP SIGNATURE-----
Merge tag 'regmap-v3.9-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap
Pull regmap fixes from Mark Brown:
"A small collection of fixes. The most important ones are those from
Stephen and Lars-Peter both of which fix cache issues that have been
lurking for a while but not manifesting noticably enough for anyone to
report them."
* tag 'regmap-v3.9-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap:
regmap: async: Add missing return
regmap: don't corrupt work buffer in _regmap_raw_write()
regmap: cache Fix regcache-rbtree sync
regmap: Initialize `map->debugfs' before regcache
Pull DRM fixes from Dave Airlie:
"Two core fixes, both regressions, along with some intel and some
nouveau fixes for regressions and oopses"
* 'drm-fixes' of git://people.freedesktop.org/~airlied/linux:
drm: correctly restore mappings if drm_open fails
drm/nouveau: fix NULL ptr dereference from nv50_disp_intr()
drm/nouveau: fix handling empty channel list in ioctl's
drm: don't unlock in the addfb error paths
drm/i915: Fix build failure
drm/i915: Be sure to turn hsync/vsync back on at crt enable (v2)
drm/i915: duct-tape locking when eDP init fails
Pull MIPS fixes from Ralf Baechle:
"A collection of fixes pretty much across the MIPS code. Even the
change to include/linux/signal.h by David Howells' 2a1486981c ("Fix
breakage in MIPS siginfo handling") should be considered MIPS-specific
as it touches an ifdefed segment that is only relevant to MIPS and
which unfortunately can't be made to go away entirely."
* 'upstream' of git://git.linux-mips.org/pub/scm/ralf/upstream-linus:
Fix breakage in MIPS siginfo handling
Revert "MIPS: BCM63XX: Call board_register_device from device_initcall()"
MIPS: BCM63XX: Make nvram checksum failure non fatal
MIPS: Fix code generation for non-DSP capable CPUs
MIPS: Fix inconsistent formatting inside /proc/cpuinfo
MIPS: SEAD3: Enable LL/SC.
MIPS: Get rid of CONFIG_CPU_HAS_LLSC again
MIPS: Add dependencies for HAVE_ARCH_TRANSPARENT_HUGEPAGE
MIPS: VR4133: Fix probe for LL/SC.
MIPS: Fix logic errors in bitops.c
MIPS: Use CONFIG_CPU_MIPSR2 in csum_partial.S
MIPS: compat: Return same error ENOSYS as native for invalid operation.
This is a fix for commit 7897e60227 ("PCI: Disable Bus Master
unconditionally in pci_device_shutdown()"). Vivek reported that
with this commit, kexec failed because none of his SATA disks
came up.
A ->shutdown() callback might put the device in D3cold, which means config
space is no longer available.
[bhelgaas: changelog]
Link: https://lkml.org/lkml/2013/3/12/529
Reported-and-Tested-by: Vivek Goyal <vgoyal@redhat.com>
Signed-off-by: Konstantin Khlebnikov <khlebnikov@openvz.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
This reverts commit 8c33f51df4.
Conflicts:
drivers/acpi/pci_root.c
This commit broke some pre-1.1 PCIe devices by leaving them with
ASPM enabled. Previously, we had disabled ASPM on these devices
because many of them don't implement it correctly (per 149e1637).
Requesting _OSC control early means that aspm_disabled may be set
before we scan the PCI bus and configure link ASPM state. But the
ASPM configuration currently skips the check for pre-PCIe 1.1 devices
when aspm_disabled is set, like this:
acpi_pci_root_add
acpi_pci_osc_support
if (flags != base_flags)
pcie_no_aspm
aspm_disabled = 1
pci_acpi_scan_root
...
pcie_aspm_init_link_state
pcie_aspm_sanity_check
if (!aspm_disabled)
/* check for pre-PCIe 1.1 device */
Therefore, setting aspm_disabled early means that we leave ASPM enabled
on these pre-PCIe 1.1 devices, which is a regression for some devices.
The best fix would be to clean up the ASPM init so we can evaluate
_OSC before scanning the bug (that way boot-time and hot-add discovery
will work the same), but that requires significant rework.
For now, we'll just revert the _OSC change as the lowest-risk fix.
Reference: https://bugzilla.kernel.org/show_bug.cgi?id=55211
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Yinghai Lu <yinghai@kernel.org>
CC: stable@vger.kernel.org # v3.8+
Commit fca460f95e simplified the x32
implementation by creating a syscall bitmask, equal to 0x40000000, that
could be applied to x32 syscalls such that the masked syscall number
would be the same as a x86_64 syscall. While that patch was a nice
way to simplify the code, it went a bit too far by adding the mask to
syscall_get_nr(); returning the masked syscall numbers can cause
confusion with callers that expect syscall numbers matching the x32
ABI, e.g. unmasked syscall numbers.
This patch fixes this by simply removing the mask from syscall_get_nr()
while preserving the other changes from the original commit. While
there are several syscall_get_nr() callers in the kernel, most simply
check that the syscall number is greater than zero, in this case this
patch will have no effect. Of those remaining callers, they appear
to be few, seccomp and ftrace, and from my testing of seccomp without
this patch the original commit definitely breaks things; the seccomp
filter does not correctly filter the syscalls due to the difference in
syscall numbers in the BPF filter and the value from syscall_get_nr().
Applying this patch restores the seccomp BPF filter functionality on
x32.
I've tested this patch with the seccomp BPF filters as well as ftrace
and everything looks reasonable to me; needless to say general usage
seemed fine as well.
Signed-off-by: Paul Moore <pmoore@redhat.com>
Link: http://lkml.kernel.org/r/20130215172143.12549.10292.stgit@localhost
Cc: <stable@vger.kernel.org>
Cc: Will Drewry <wad@chromium.org>
Cc: H. Peter Anvin <hpa@zytor.com>
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
If first drm_open fails, the error-handling path will
incorrectly restore inode's mapping to NULL. This can
cause the crash later on. Fix by separately storing
away mapping pointers that drm_open can touch and
restore each from its own respective variable if the
call fails.
Fixes: https://bugzilla.novell.com/show_bug.cgi?id=807850
(thanks to Michal Hocko for investigating investigating and
finding the root cause of the bug)
Reference:
http://lists.freedesktop.org/archives/dri-devel/2013-March/036564.html
v2: Use one variable to store file and inode mapping
since they are the same at the function entry.
Fix spelling mistakes in commit message.
v3: Add reference to the original bug report.
Reported-by: Marco Munderloh <munderl@tnt.uni-hannover.de>
Tested-by: Marco Munderloh <munderl@tnt.uni-hannover.de>
Signed-off-by: Ilija Hadzic <ihadzic@research.bell-labs.com>
Cc: Michal Hocko <mhocko@suse.cz>
Cc: stable@vger.kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
One locking regression fix, and a couple of other i915 ones.
* 'drm-intel-fixes' of git://people.freedesktop.org/~danvet/drm-intel:
drm: don't unlock in the addfb error paths
drm/i915: Fix build failure
drm/i915: Be sure to turn hsync/vsync back on at crt enable (v2)
drm/i915: duct-tape locking when eDP init fails
The VMCI context ID of a virtual machine may change at any time. There
is a VMCI event which signals this but datagrams may be processed before
this is handled. It is therefore necessary to be flexible about the
destination context ID of any datagrams received. (It can be assumed to
be correct because it is provided by the hypervisor.) The context ID on
existing sockets should be updated to reflect how the hypervisor is
currently referring to the system.
Signed-off-by: Reilly Grant <grantr@vmware.com>
Acked-by: Andy King <acking@vmware.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
IPv6 Routing table becomes broken once we do ifdown, ifup of the loopback(lo)
interface. After down-up, routes of other interface's IPv6 addresses through
'lo' are lost.
IPv6 addresses assigned to all interfaces are routed through 'lo' for internal
communication. Once 'lo' is down, those routing entries are removed from routing
table. But those removed entries are not being re-created properly when 'lo' is
brought up. So IPv6 addresses of other interfaces becomes unreachable from the
same machine. Also this breaks communication with other machines because of
NDISC packet processing failure.
This patch fixes this issue by reading all interface's IPv6 addresses and adding
them to IPv6 routing table while bringing up 'lo'.
==Testing==
Before applying the patch:
$ route -A inet6
Kernel IPv6 routing table
Destination Next Hop Flag Met Ref Use If
2000::20/128 :: U 256 0 0 eth0
fe80::/64 :: U 256 0 0 eth0
::/0 :: !n -1 1 1 lo
::1/128 :: Un 0 1 0 lo
2000::20/128 :: Un 0 1 0 lo
fe80::xxxx:xxxx:xxxx:xxxx/128 :: Un 0 1 0 lo
ff00::/8 :: U 256 0 0 eth0
::/0 :: !n -1 1 1 lo
$ sudo ifdown lo
$ sudo ifup lo
$ route -A inet6
Kernel IPv6 routing table
Destination Next Hop Flag Met Ref Use If
2000::20/128 :: U 256 0 0 eth0
fe80::/64 :: U 256 0 0 eth0
::/0 :: !n -1 1 1 lo
::1/128 :: Un 0 1 0 lo
ff00::/8 :: U 256 0 0 eth0
::/0 :: !n -1 1 1 lo
$
After applying the patch:
$ route -A inet6
Kernel IPv6 routing
table
Destination Next Hop Flag Met Ref Use If
2000::20/128 :: U 256 0 0 eth0
fe80::/64 :: U 256 0 0 eth0
::/0 :: !n -1 1 1 lo
::1/128 :: Un 0 1 0 lo
2000::20/128 :: Un 0 1 0 lo
fe80::xxxx:xxxx:xxxx:xxxx/128 :: Un 0 1 0 lo
ff00::/8 :: U 256 0 0 eth0
::/0 :: !n -1 1 1 lo
$ sudo ifdown lo
$ sudo ifup lo
$ route -A inet6
Kernel IPv6 routing table
Destination Next Hop Flag Met Ref Use If
2000::20/128 :: U 256 0 0 eth0
fe80::/64 :: U 256 0 0 eth0
::/0 :: !n -1 1 1 lo
::1/128 :: Un 0 1 0 lo
2000::20/128 :: Un 0 1 0 lo
fe80::xxxx:xxxx:xxxx:xxxx/128 :: Un 0 1 0 lo
ff00::/8 :: U 256 0 0 eth0
::/0 :: !n -1 1 1 lo
$
Signed-off-by: Balakumaran Kannan <Balakumaran.Kannan@ap.sony.com>
Signed-off-by: Maruthi Thotad <Maruthi.Thotad@ap.sony.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
currently cbq works incorrectly for limits > 10% real link bandwidth,
and practically does not work for limits > 50% real link bandwidth.
Below are results of experiments taken on 1 Gbit link
In shaper | Actual Result
-----------+---------------
100M | 108 Mbps
200M | 244 Mbps
300M | 412 Mbps
500M | 893 Mbps
This happen because of q->now changes incorrectly in cbq_dequeue():
when it is called before real end of packet transmitting,
L2T is greater than real time delay, q_now gets an extra boost
but never compensate it.
To fix this problem we prevent change of q->now until its synchronization
with real time.
Signed-off-by: Vasily Averin <vvs@openvz.org>
Reviewed-by: Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>
Acked-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Make sure that msg pointer is set back to error value in case of
MSG_COPY flag is set and desired message to copy wasn't found. This
garantees that msg is either a error pointer or a copy address.
Otherwise the last message in queue will be freed without unlinking from
the queue (which leads to memory corruption) and the dummy allocated
copy won't be released.
Signed-off-by: Stanislav Kinsbursky <skinsbursky@parallels.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Commit 6bbb6d9 "net/mlx4_en: Optimize Rx fast path filter checks" introduced a regression
under which the MAC address read from the card was not converted correctly
(the most significant byte was not handled), fix that.
Reviewed-by: Or Gerlitz <ogerlitz@mellanox.com>
Signed-off-by: Yan Burman <yanb@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Now that netdev_rx_handler_unregister contains synchronize_net(), we need
to call it outside of bond->lock, cause it might sleep. Also, remove the
already unneded synchronize_net().
Signed-off-by: Veaceslav Falico <vfalico@redhat.com>
Acked-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
After a quiet set of fixes for 3.9-rc4, a lot of people woke up and sent
urgent fixes for 3.9. I pushed back on a number of them that got
deferred to 3.10, but these are the ones that seemed important.
Regression in 3.9:
- Multiple regressions in OMAP2+ clock cleanup
- SH-Mobile frame buffer bug fix that merged here because of maintainer MIA
- ux500 prcmu changes broke DT booting
- MMCI duplicated regulator setup on ux500
- New ux500 clock driver broke ethernet on snowball
- Local interrupt driver for mvebu broke ethernet
- MVEBU GPIO driver did not get set up right on Orion DT
- incorrect interrupt number on Orion crypto for DT
Long-standing bugs, including candidates for stable:
- Kirkwood MMC needs to disable invalid card detect pins
- MV SDIO pinmux was wrong on Mirabox
- GoFlex Net board file needs to set NAND chip delay
- MSM timer restart race
- ep93xx early debug code broke in 3.7
- i.MX CPU hotplug race
- Incorrect clock setup for OMAP1 USB
- Workaround for bad clock setup by some old OMAP4 boot loaders
- Static I/O mappings on cns3xxx since 3.2
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iQIVAwUAUVrxWGCrR//JCVInAQLsoQ/+IQKk3v3xOhsvLaPxYjpO1dZqwxmWHwCz
ujmpnsUabYwuVfVL982k3RTSry5brgOB75CdztOyYsnckF1ZJ3zPjBN+TQM7G/aF
1lpfUTdCEQFgWFb69G6Lr5ZIDk7co3nRJk1GFS/xi/EAlnmUY/tC1Epco2Y0z0g4
dWz34sor22lxwWkUTdgXKwynoxmmjBzZIJOhtSOeednVPxN2qUe9IDAy9qk43U3a
Xg8j4OQT59TTmAZgAB7DLlJ3BGpFvTFAeZ4sDwrCCnibmB5E9LiaYwS9vrk9SQB1
D8CYIUqcP+cGKnftCCIzgjXHYvJw8fa7NKBUw9CzusIuk+c5AbE28KZRIL4D24Oq
ImlFV4Neec3Iab6IWfD0+PQK6PkwqnvPd5IBSFO4zUv2adafl7sTASlMnNPZtWbo
gV+GNVlCyab3l1KYBPo+CQGup3UpIAs5trQoCUh7BRf4HEsL+HILr/SFRQk3GQ6H
B+3HgSleiipT8n81VDFiWY1o5KuXmjUd2qpbc0a45VtM6EFBONwqBaKew93NkDYa
oIhI6yS8aIMYPXC6ZP5R2OvKUuL+mypKKXlt9BMCnDG9mrGMks8BLumcHco+Jmkt
9p6DChibxsaH6QArAi16shFPm0VqFUI6cidgTUcY024bZSiXpBMF52mIu6SEf0/S
agIwGxpuXFg=
=oQbL
-----END PGP SIGNATURE-----
Merge tag 'fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc
Pull ARM SoC bug fixes from Arnd Bergmann:
"After a quiet set of fixes for 3.9-rc4, a lot of people woke up and
sent urgent fixes for 3.9. I pushed back on a number of them that got
deferred to 3.10, but these are the ones that seemed important.
Regression in 3.9:
- Multiple regressions in OMAP2+ clock cleanup
- SH-Mobile frame buffer bug fix that merged here because of
maintainer MIA
- ux500 prcmu changes broke DT booting
- MMCI duplicated regulator setup on ux500
- New ux500 clock driver broke ethernet on snowball
- Local interrupt driver for mvebu broke ethernet
- MVEBU GPIO driver did not get set up right on Orion DT
- incorrect interrupt number on Orion crypto for DT
Long-standing bugs, including candidates for stable:
- Kirkwood MMC needs to disable invalid card detect pins
- MV SDIO pinmux was wrong on Mirabox
- GoFlex Net board file needs to set NAND chip delay
- MSM timer restart race
- ep93xx early debug code broke in 3.7
- i.MX CPU hotplug race
- Incorrect clock setup for OMAP1 USB
- Workaround for bad clock setup by some old OMAP4 boot loaders
- Static I/O mappings on cns3xxx since 3.2"
* tag 'fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc:
ARM: cns3xxx: fix mapping of private memory region
arm: mvebu: Fix pinctrl for Armada 370 Mirabox SDIO port.
arm: orion5x: correct IRQ used in dtsi for mv_cesa
arm: orion5x: fix orion5x.dtsi gpio parameters
ARM: Kirkwood: fix unused mvsdio gpio pins
arm: mvebu: Use local interrupt only for the timer 0
ARM: kirkwood: Fix chip-delay for GoFlex Net
ARM: ux500: Enable the clock controlling Ethernet on Snowball
ARM: ux500: Stop passing ios_handler() as an MMCI power controlling call-back
ARM: ux500: Apply the TCPM and TCDM locations and sizes to dbx5x0 DT
fbdev: sh_mobile_lcdc: fixup B side hsync adjust settings
ARM: OMAP: clocks: Delay clk inits atleast until slab is initialized
ARM: imx: fix sync issue between imx_cpu_die and imx_cpu_kill
ARM: msm: Stop counting before reprogramming clockevent
ARM: ep93xx: Fix wait for UART FIFO to be empty
ARM: OMAP4: PM: fix PM regression introduced by recent clock cleanup
ARM: OMAP3: hwmod data: keep MIDLEMODE in force-standby for musb
ARM: OMAP4: clock data: lock USB DPLL on boot
ARM: OMAP1: fix USB host on 1710
Jan Stancek