Militarist
Müdavim
- Katılım
- 4 Mayıs 2008
- Mesajlar
- 7,620
- Reaksiyon puanı
- 130
- Puanları
- 63
Kod:
commit 1c8f63c2758096c3b6425f4ecb274901151d6f17
Author: Greg Kroah-Hartman <[email protected]>
Date: Thu Jul 19 12:11:49 2012 -0700
Linux 3.4.6
commit 016e7d822a72c4cbcbf7e4bc6d590cf50879ec26
Author: Samuel Ortiz <[email protected]>
Date: Thu May 10 19:45:51 2012 +0200
NFC: Export nfc.h to userland
commit dbd4fcaf8d664fab4163b1f8682e41ad8bff3444 upstream.
The netlink commands and attributes, along with the socket structure
definitions need to be exported.
Signed-off-by: Samuel Ortiz <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit 3cdeda1e763ccb2287c6ee76ece14145027653a9
Author: Thomas Gleixner <[email protected]>
Date: Tue Jul 17 02:39:56 2012 -0400
timekeeping: Add missing update call in timekeeping_resume()
This is a backport of 3e997130bd2e8c6f5aaa49d6e3161d4d29b43ab0
The leap second rework unearthed another issue of inconsistent data.
On timekeeping_resume() the timekeeper data is updated, but nothing
calls timekeeping_update(), so now the update code in the timer
interrupt sees stale values.
This has been the case before those changes, but then the timer
interrupt was using stale data as well so this went unnoticed for quite
some time.
Add the missing update call, so all the data is consistent everywhere.
Reported-by: Andreas Schwab <[email protected]>
Reported-and-tested-by: "Rafael J. Wysocki" <[email protected]>
Reported-and-tested-by: Martin Steigerwald <[email protected]>
Cc: John Stultz <[email protected]>
Cc: Ingo Molnar <[email protected]>
Cc: Peter Zijlstra <[email protected]>,
Cc: Prarit Bhargava <[email protected]>
Signed-off-by: Thomas Gleixner <[email protected]>
Signed-off-by: John Stultz <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Cc: Prarit Bhargava <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Signed-off-by: John Stultz <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit 6321a0a1a3a9d6c9cbd73d9a4159a97ac3bc0919
Author: John Stultz <[email protected]>
Date: Tue Jul 17 02:39:55 2012 -0400
hrtimer: Update hrtimer base offsets each hrtimer_interrupt
This is a backport of 5baefd6d84163443215f4a99f6a20f054ef11236
The update of the hrtimer base offsets on all cpus cannot be made
atomically from the timekeeper.lock held and interrupt disabled region
as smp function calls are not allowed there.
clock_was_set(), which enforces the update on all cpus, is called
either from preemptible process context in case of do_settimeofday()
or from the softirq context when the offset modification happened in
the timer interrupt itself due to a leap second.
In both cases there is a race window for an hrtimer interrupt between
dropping timekeeper lock, enabling interrupts and clock_was_set()
issuing the updates. Any interrupt which arrives in that window will
see the new time but operate on stale offsets.
So we need to make sure that an hrtimer interrupt always sees a
consistent state of time and offsets.
ktime_get_update_offsets() allows us to get the current monotonic time
and update the per cpu hrtimer base offsets from hrtimer_interrupt()
to capture a consistent state of monotonic time and the offsets. The
function replaces the existing ktime_get() calls in hrtimer_interrupt().
The overhead of the new function vs. ktime_get() is minimal as it just
adds two store operations.
This ensures that any changes to realtime or boottime offsets are
noticed and stored into the per-cpu hrtimer base structures, prior to
any hrtimer expiration and guarantees that timers are not expired early.
Signed-off-by: John Stultz <[email protected]>
Reviewed-by: Ingo Molnar <[email protected]>
Acked-by: Peter Zijlstra <[email protected]>
Acked-by: Prarit Bhargava <[email protected]>
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Thomas Gleixner <[email protected]>
Cc: Prarit Bhargava <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Signed-off-by: John Stultz <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit 765bdc4d82fadcddfec19222a545e904633c7816
Author: Thomas Gleixner <[email protected]>
Date: Tue Jul 17 02:39:54 2012 -0400
timekeeping: Provide hrtimer update function
This is a backport of f6c06abfb3972ad4914cef57d8348fcb2932bc3b
To finally fix the infamous leap second issue and other race windows
caused by functions which change the offsets between the various time
bases (CLOCK_MONOTONIC, CLOCK_REALTIME and CLOCK_BOOTTIME) we need a
function which atomically gets the current monotonic time and updates
the offsets of CLOCK_REALTIME and CLOCK_BOOTTIME with minimalistic
overhead. The previous patch which provides ktime_t offsets allows us
to make this function almost as cheap as ktime_get() which is going to
be replaced in hrtimer_interrupt().
Signed-off-by: Thomas Gleixner <[email protected]>
Reviewed-by: Ingo Molnar <[email protected]>
Acked-by: Peter Zijlstra <[email protected]>
Acked-by: Prarit Bhargava <[email protected]>
Signed-off-by: John Stultz <[email protected]>
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Thomas Gleixner <[email protected]>
Cc: Prarit Bhargava <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Signed-off-by: John Stultz <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit dd3cded0f516201d3b72999e588a6d67e00cb82f
Author: Thomas Gleixner <[email protected]>
Date: Tue Jul 17 02:39:53 2012 -0400
hrtimers: Move lock held region in hrtimer_interrupt()
This is a backport of 196951e91262fccda81147d2bcf7fdab08668b40
We need to update the base offsets from this code and we need to do
that under base->lock. Move the lock held region around the
ktime_get() calls. The ktime_get() calls are going to be replaced with
a function which gets the time and the offsets atomically.
Signed-off-by: Thomas Gleixner <[email protected]>
Reviewed-by: Ingo Molnar <[email protected]>
Acked-by: Peter Zijlstra <[email protected]>
Acked-by: Prarit Bhargava <[email protected]>
Signed-off-by: John Stultz <[email protected]>
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Thomas Gleixner <[email protected]>
Cc: Prarit Bhargava <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Signed-off-by: John Stultz <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit 7d1f07113b1b32da1eabce0dc74d9f96bbb7b90a
Author: Thomas Gleixner <[email protected]>
Date: Tue Jul 17 02:39:52 2012 -0400
timekeeping: Maintain ktime_t based offsets for hrtimers
This is a backport of 5b9fe759a678e05be4937ddf03d50e950207c1c0
We need to update the hrtimer clock offsets from the hrtimer interrupt
context. To avoid conversions from timespec to ktime_t maintain a
ktime_t based representation of those offsets in the timekeeper. This
puts the conversion overhead into the code which updates the
underlying offsets and provides fast accessible values in the hrtimer
interrupt.
Signed-off-by: Thomas Gleixner <[email protected]>
Signed-off-by: John Stultz <[email protected]>
Reviewed-by: Ingo Molnar <[email protected]>
Acked-by: Peter Zijlstra <[email protected]>
Acked-by: Prarit Bhargava <[email protected]>
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Thomas Gleixner <[email protected]>
Cc: Prarit Bhargava <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Signed-off-by: John Stultz <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit 2e947d469fba2c2036ff50a2e58a1875ab2ea6b6
Author: John Stultz <[email protected]>
Date: Tue Jul 17 02:39:51 2012 -0400
timekeeping: Fix leapsecond triggered load spike issue
This is a backport of 4873fa070ae84a4115f0b3c9dfabc224f1bc7c51
The timekeeping code misses an update of the hrtimer subsystem after a
leap second happened. Due to that timers based on CLOCK_REALTIME are
either expiring a second early or late depending on whether a leap
second has been inserted or deleted until an operation is initiated
which causes that update. Unless the update happens by some other
means this discrepancy between the timekeeping and the hrtimer data
stays forever and timers are expired either early or late.
The reported immediate workaround - $ data -s "`date`" - is causing a
call to clock_was_set() which updates the hrtimer data structures.
See: http://www.sheeri.com/content/mysql-and-leap-second-high-cpu-and-fix
Add the missing clock_was_set() call to update_wall_time() in case of
a leap second event. The actual update is deferred to softirq context
as the necessary smp function call cannot be invoked from hard
interrupt context.
Signed-off-by: John Stultz <[email protected]>
Reported-by: Jan Engelhardt <[email protected]>
Reviewed-by: Ingo Molnar <[email protected]>
Acked-by: Peter Zijlstra <[email protected]>
Acked-by: Prarit Bhargava <[email protected]>
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Thomas Gleixner <[email protected]>
Cc: Prarit Bhargava <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Signed-off-by: John Stultz <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit 5e5006e64cae9603841405af9febb67064869d83
Author: John Stultz <[email protected]>
Date: Tue Jul 17 02:39:50 2012 -0400
hrtimer: Provide clock_was_set_delayed()
This is a backport of f55a6faa384304c89cfef162768e88374d3312cb
clock_was_set() cannot be called from hard interrupt context because
it calls on_each_cpu().
For fixing the widely reported leap seconds issue it is necessary to
call it from hard interrupt context, i.e. the timer tick code, which
does the timekeeping updates.
Provide a new function which denotes it in the hrtimer cpu base
structure of the cpu on which it is called and raise the hrtimer
softirq. We then execute the clock_was_set() notificiation from
softirq context in run_hrtimer_softirq(). The hrtimer softirq is
rarely used, so polling the flag there is not a performance issue.
[ tglx: Made it depend on CONFIG_HIGH_RES_TIMERS. We really should get
rid of all this ifdeffery ASAP ]
Signed-off-by: John Stultz <[email protected]>
Reported-by: Jan Engelhardt <[email protected]>
Reviewed-by: Ingo Molnar <[email protected]>
Acked-by: Peter Zijlstra <[email protected]>
Acked-by: Prarit Bhargava <[email protected]>
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Thomas Gleixner <[email protected]>
Cc: Prarit Bhargava <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Signed-off-by: John Stultz <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit 738c88c1b8ebe16c3ecd1694871474b470275d82
Author: Michal Kazior <[email protected]>
Date: Fri Jun 8 10:55:44 2012 +0200
cfg80211: check iface combinations only when iface is running
commit f8cdddb8d61d16a156229f0910f7ecfc7a82c003 upstream.
Don't validate interface combinations on a stopped
interface. Otherwise we might end up being able to
create a new interface with a certain type, but
won't be able to change an existing interface
into that type.
This also skips some other functions when
interface is stopped and changing interface type.
Signed-off-by: Michal Kazior <[email protected]>
Signed-off-by: Johannes Berg <[email protected]>
[Fixes regression introduced by cherry pick of 463454b5dbd8]
Signed-off-by: Paul Gortmaker <[email protected]>
commit 871d4f5e1d82cf0ad56ae076c8535004e7837416
Author: Pawel Moll <[email protected]>
Date: Fri Jun 8 14:04:06 2012 +0100
clk: Check parent for NULL in clk_change_rate
commit bf47b4fd8f9f81cd5ce40e1945c6334d088226d1 upstream.
clk_change_rate() is accessing parent's rate without checking
if the parent exists at all. In case of root clocks this will
cause NULL pointer dereference.
This patch follows what clk_calc_new_rates() does in such
situation.
Signed-off-by: Pawel Moll <[email protected]>
Signed-off-by: Mike Turquette <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit c5e42b8d692877676fc3ba9fdf3dbcbd723b4c2b
Author: Ryan Bourgeois <[email protected]>
Date: Tue Jul 10 09:43:33 2012 -0700
HID: add support for 2012 MacBook Pro Retina
commit b2e6ad7dfe26aac5bf136962d0b11d180b820d44 upstream.
Add support for the 15'' MacBook Pro Retina. The keyboard is
the same as recent models.
The patch needs to be synchronized with the bcm5974 patch for
the trackpad - as usual.
Patch originally written by clipcarl (forums.opensuse.org).
[[email protected]: Amended mouse ignore lines]
Signed-off-by: Ryan Bourgeois <[email protected]>
Signed-off-by: Henrik Rydberg <[email protected]>
Acked-by: Jiri Kosina <[email protected]>
Signed-off-by: Dmitry Torokhov <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit 256cf2738cb242af70ea6f6117446a98ed949a9c
Author: Yuri Khan <[email protected]>
Date: Wed Jul 11 22:12:31 2012 -0700
Input: xpad - add Andamiro Pump It Up pad
commit e76b8ee25e034ab601b525abb95cea14aa167ed3 upstream.
I couldn't find the vendor ID in any of the online databases, but this
mat has a Pump It Up logo on the top side of the controller compartment,
and a disclaimer stating that Andamiro will not be liable on the bottom.
Signed-off-by: Yuri Khan <[email protected]>
Signed-off-by: Dmitry Torokhov <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit 07793cd472f688c266eedff79f46f6c512d84ce4
Author: Ilia Katsnelson <[email protected]>
Date: Wed Jul 11 00:54:20 2012 -0700
Input: xpad - add signature for Razer Onza Tournament Edition
commit cc71a7e899cc6b2ff41e1be48756782ed004d802 upstream.
Signed-off-by: Ilia Katsnelson <[email protected]>
Signed-off-by: Dmitry Torokhov <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit abee143740c3388cc34869b9320aed3fa28f9cdb
Author: Yuri Khan <[email protected]>
Date: Wed Jul 11 00:49:18 2012 -0700
Input: xpad - handle all variations of Mad Catz Beat Pad
commit 3ffb62cb9ac2430c2504c6ff9727d0f2476ef0bd upstream.
The device should be handled by xpad driver instead of generic HID driver.
Signed-off-by: Yuri Khan <[email protected]>
Acked-by: Jiri Kosina <[email protected]>
Signed-off-by: Dmitry Torokhov <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit edb5132a255e3f594b662018acced9037c6989b5
Author: Henrik Rydberg <[email protected]>
Date: Tue Jul 10 09:43:57 2012 -0700
Input: bcm5974 - Add support for 2012 MacBook Pro Retina
commit 3dde22a98e94eb18527f0ff0068fb2fb945e58d4 upstream.
Add support for the 15'' MacBook Pro Retina model (MacBookPro10,1).
Patch originally written by clipcarl (forums.opensuse.org).
Signed-off-by: Henrik Rydberg <[email protected]>
Signed-off-by: Dmitry Torokhov <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit d418f998832c7fd8f783e05cec7da6125720360d
Author: Eric W. Biederman <[email protected]>
Date: Mon Jul 9 10:51:45 2012 +0000
bonding: Manage /proc/net/bonding/ entries from the netdev events
commit a64d49c3dd504b685f9742a2f3dcb11fb8e4345f upstream.
It was recently reported that moving a bonding device between network
namespaces causes warnings from /proc. It turns out after the move we
were trying to add and to remove the /proc/net/bonding entries from the
wrong network namespace.
Move the bonding /proc registration code into the NETDEV_REGISTER and
NETDEV_UNREGISTER events where the proc registration and unregistration
will always happen at the right time.
Signed-off-by: "Eric W. Biederman" <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit f4e2229ea5d49e338fce36b2c36f22b525fbeff6
Author: Eric W. Biederman <[email protected]>
Date: Mon Jul 9 10:52:43 2012 +0000
bonding: debugfs and network namespaces are incompatible
commit 96ca7ffe748bf91f851e6aa4479aa11c8b1122ba upstream.
The bonding debugfs support has been broken in the presence of network
namespaces since it has been added. The debugfs support does not handle
multiple bonding devices with the same name in different network
namespaces.
I haven't had any bug reports, and I'm not interested in getting any.
Disable the debugfs support when network namespaces are enabled.
Signed-off-by: "Eric W. Biederman" <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit b98522a7cf0ff60bcf49330d9467089515cf9dad
Author: Deepak Sikri <[email protected]>
Date: Sun Jul 8 21:14:45 2012 +0000
stmmac: Fix for nfs hang on multiple reboot
commit 8e83989106562326bfd6aaf92174fe138efd026b upstream.
It was observed that during multiple reboots nfs hangs. The status of
receive descriptors shows that all the descriptors were in control of
CPU, and none were assigned to DMA.
Also the DMA status register confirmed that the Rx buffer is
unavailable.
This patch adds the fix for the same by adding the memory barriers to
ascertain that the all instructions before enabling the Rx or Tx DMA are
completed which involves the proper setting of the ownership bit in DMA
descriptors.
Signed-off-by: Deepak Sikri <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit 3cf16f7e388934d4458d0d6cebdf752e4424f226
Author: Eliad Peller <[email protected]>
Date: Mon Jul 2 14:42:03 2012 +0300
mac80211: destroy assoc_data correctly if assoc fails
commit 10a9109f2705fdc3caa94d768b2559587a9a050c upstream.
If association failed due to internal error (e.g. no
supported rates IE), we call ieee80211_destroy_assoc_data()
with assoc=true, while we actually reject the association.
This results in the BSSID not being zeroed out.
After passing assoc=false, we no longer have to call
sta_info_destroy_addr() explicitly. While on it, move
the "associated" message after the assoc_success check.
Signed-off-by: Eliad Peller <[email protected]>
Reviewed-by: Johannes Berg <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit c8ed7cf355f41b649524029c49f101d878499482
Author: Federico Fuga <[email protected]>
Date: Mon Jul 16 10:36:51 2012 +0300
rpmsg: fix dependency on initialization order
commit 9634252617441991b01dacaf4040866feecaf36f upstream.
When rpmsg drivers are built into the kernel, they must not initialize
before the rpmsg bus does, otherwise they'd trigger a BUG() in
drivers/base/driver.c line 169 (driver_register()).
To fix that, and to stop depending on arbitrary linkage ordering of
those built-in rpmsg drivers, we make the rpmsg bus initialize at
subsys_initcall.
Signed-off-by: Federico Fuga <[email protected]>
[ohad: rewrite the commit log]
Signed-off-by: Ohad Ben-Cohen <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit 1214b7852425b78a2b73b0a759ec55210340396d
Author: Emmanuel Grumbach <[email protected]>
Date: Wed Jul 4 13:59:08 2012 +0200
iwlegacy: don't mess up the SCD when removing a key
commit b48d96652626b315229b1b82c6270eead6a77a6d upstream.
When we remove a key, we put a key index which was supposed
to tell the fw that we are actually removing the key. But
instead the fw took that index as a valid index and messed
up the SRAM of the device.
This memory corruption on the device mangled the data of
the SCD. The impact on the user is that SCD queue 2 got
stuck after having removed keys.
Reported-by: Paul Bolle <[email protected]>
Signed-off-by: Emmanuel Grumbach <[email protected]>
Signed-off-by: Stanislaw Gruszka <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit 57cff816121720c80b39e3b3fb0ef36128fdc45b
Author: Stanislaw Gruszka <[email protected]>
Date: Wed Jul 4 13:20:20 2012 +0200
iwlegacy: always monitor for stuck queues
commit c2ca7d92ed4bbd779516beb6eb226e19f7f7ab0f upstream.
This is iwlegacy version of:
commit 342bbf3fee2fa9a18147e74b2e3c4229a4564912
Author: Johannes Berg <[email protected]>
Date: Sun Mar 4 08:50:46 2012 -0800
iwlwifi: always monitor for stuck queues
If we only monitor while associated, the following
can happen:
- we're associated, and the queue stuck check
runs, setting the queue "touch" time to X
- we disassociate, stopping the monitoring,
which leaves the time set to X
- almost 2s later, we associate, and enqueue
a frame
- before the frame is transmitted, we monitor
for stuck queues, and find the time set to
X, although it is now later than X + 2000ms,
so we decide that the queue is stuck and
erroneously restart the device
Signed-off-by: Stanislaw Gruszka <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit 3cc4e0e187e4187a6ec13a79dafc1b0f72e31afa
Author: Tushar Dave <[email protected]>
Date: Thu Jul 12 08:56:56 2012 +0000
e1000e: Correct link check logic for 82571 serdes
commit d0efa8f23a644f7cb7d1f8e78dd9a223efa412a3 upstream.
SYNCH bit and IV bit of RXCW register are sticky. Before examining these bits,
RXCW should be read twice to filter out one-time false events and have correct
values for these bits. Incorrect values of these bits in link check logic can
cause weird link stability issues if auto-negotiation fails.
Reported-by: Dean Nelson <[email protected]>
Signed-off-by: Tushar Dave <[email protected]>
Reviewed-by: Bruce Allan <[email protected]>
Tested-by: Jeff Pieper <[email protected]>
Signed-off-by: Jeff Kirsher <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit a3c021d25debc6278951e0112b1a06d8b7376d22
Author: Stanislaw Gruszka <[email protected]>
Date: Wed Jul 4 13:10:02 2012 +0200
rt2x00usb: fix indexes ordering on RX queue kick
commit efd821182cec8c92babef6e00a95066d3252fda4 upstream.
On rt2x00_dmastart() we increase index specified by Q_INDEX and on
rt2x00_dmadone() we increase index specified by Q_INDEX_DONE. So entries
between Q_INDEX_DONE and Q_INDEX are those we currently process in the
hardware. Entries between Q_INDEX and Q_INDEX_DONE are those we can
submit to the hardware.
According to that fix rt2x00usb_kick_queue(), as we need to submit RX
entries that are not processed by the hardware. It worked before only
for empty queue, otherwise was broken.
Note that for TX queues indexes ordering are ok. We need to kick entries
that have filled skb, but was not submitted to the hardware, i.e.
started from Q_INDEX_DONE and have ENTRY_DATA_PENDING bit set.
From practical standpoint this fixes RX queue stall, usually reproducible
in AP mode, like for example reported here:
https://bugzilla.redhat.com/show_bug.cgi?id=828824
Reported-and-tested-by: Franco Miceli <[email protected]>
Reported-and-tested-by: Tom Horsley <[email protected]>
Signed-off-by: Stanislaw Gruszka <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit b9311277c28fab089ee0816307035c3a5f546bcf
Author: Anders Kaseorg <[email protected]>
Date: Sun Jul 15 17:14:25 2012 -0400
fifo: Do not restart open() if it already found a partner
commit 05d290d66be6ef77a0b962ebecf01911bd984a78 upstream.
If a parent and child process open the two ends of a fifo, and the
child immediately exits, the parent may receive a SIGCHLD before its
open() returns. In that case, we need to make sure that open() will
return successfully after the SIGCHLD handler returns, instead of
throwing EINTR or being restarted. Otherwise, the restarted open()
would incorrectly wait for a second partner on the other end.
The following test demonstrates the EINTR that was wrongly thrown from
the parents open(). Change .sa_flags = 0 to .sa_flags = SA_RESTART
to see a deadlock instead, in which the restarted open() waits for a
second reader that will never come. (On my systems, this happens
pretty reliably within about 5 to 500 iterations. Others report that
it manages to loop ~forever sometimes; YMMV.)
#include <sys/stat.h>
#include <sys/types.h>
#include <sys/wait.h>
#include <fcntl.h>
#include <signal.h>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#define CHECK(x) do if ((x) == -1) {perror(#x); abort();} while(0)
void handler(int signum) {}
int main()
{
struct sigaction act = {.sa_handler = handler, .sa_flags = 0};
CHECK(sigaction(SIGCHLD, &act, NULL));
CHECK(mknod("fifo", S_IFIFO | S_IRWXU, 0));
for (;;) {
int fd;
pid_t pid;
putc('.', stderr);
CHECK(pid = fork());
if (pid == 0) {
CHECK(fd = open("fifo", O_RDONLY));
_exit(0);
}
CHECK(fd = open("fifo", O_WRONLY));
CHECK(close(fd));
CHECK(waitpid(pid, NULL, 0));
}
}
This is what I suspect was causing the Git test suite to fail in
t9010-svn-fe.sh:
http://bugs.debian.org/678852
Signed-off-by: Anders Kaseorg <[email protected]>
Reviewed-by: Jonathan Nieder <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit 665c7a83a1a64582c4393dd45430c848150a10dd
Author: Takashi Iwai <[email protected]>
Date: Mon Jun 25 15:07:17 2012 +0200
intel_ips: blacklist HP ProBook laptops
commit 88ca518b0bb4161e5f20f8a1d9cc477cae294e54 upstream.
intel_ips driver spews the warning message
"ME failed to update for more than 1s, likely hung"
at each second endlessly on HP ProBook laptops with IronLake.
As this has never worked, better to blacklist the driver for now.
Signed-off-by: Takashi Iwai <[email protected]>
Signed-off-by: Matthew Garrett <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit 7490d0a4cfefa16f9d8ce636eb5b2e13d2432db3
Author: Peter Zijlstra <[email protected]>
Date: Fri Jun 22 15:52:09 2012 +0200
sched/nohz: Rewrite and fix load-avg computation -- again
commit 5167e8d5417bf5c322a703d2927daec727ea40dd upstream.
Thanks to Charles Wang for spotting the defects in the current code:
- If we go idle during the sample window -- after sampling, we get a
negative bias because we can negate our own sample.
- If we wake up during the sample window we get a positive bias
because we push the sample to a known active period.
So rewrite the entire nohz load-avg muck once again, now adding
copious documentation to the code.
Reported-and-tested-by: Doug Smythies <[email protected]>
Reported-and-tested-by: Charles Wang <[email protected]>
Signed-off-by: Peter Zijlstra <[email protected]>
Cc: Linus Torvalds <[email protected]>
Cc: Andrew Morton <[email protected]>
Link: http://lkml.kernel.org/r/1340373782.18025.74.camel@twins
[ minor edits ]
Signed-off-by: Ingo Molnar <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit 667fb5508900340d657645e0bfc9bf210a1fc363
Author: Thomas Renninger <[email protected]>
Date: Thu Jul 12 12:24:33 2012 +0200
cpufreq / ACPI: Fix not loading acpi-cpufreq driver regression
commit c4686c71a9183f76e3ef59098da5c098748672f6 upstream.
Commit d640113fe80e45ebd4a5b420b introduced a regression on SMP
systems where the processor core with ACPI id zero is disabled
(typically should be the case because of hyperthreading).
The regression got spread through stable kernels.
On 3.0.X it got introduced via 3.0.18.
Such platforms may be rare, but do exist.
Look out for a disabled processor with acpi_id 0 in dmesg:
ACPI: LAPIC (acpi_id[0x00] lapic_id[0x10] disabled)
This problem has been observed on a:
HP Proliant BL280c G6 blade
This patch restricts the introduced workaround to platforms
with nr_cpu_ids <= 1.
Signed-off-by: Thomas Renninger <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit af3a2390c0f80345516524c3fe7e717f465ce6bd
Author: Bob Moore <[email protected]>
Date: Wed Jul 4 10:02:32 2012 +0800
ACPICA: Fix possible fault in return package object repair code
commit 46befd6b38d802dfc5998e7d7938854578b45d9d upstream.
Fixes a problem that can occur when a lone package object is
wrapped with an outer package object in order to conform to
the ACPI specification. Can affect these predefined names:
_ALR,_MLS,_PSS,_TRT,_TSS,_PRT,_HPX,_DLM,_CSD,_PSD,_TSD
https://bugzilla.kernel.org/show_bug.cgi?id=44171
This problem was introduced in 3.4-rc1 by commit
6a99b1c94d053b3420eaa4a4bc8b2883dd90a2f9
(ACPICA: Object repair code: Support to add Package wrappers)
Reported-by: Vlastimil Babka <[email protected]>
Signed-off-by: Bob Moore <[email protected]>
Signed-off-by: Lin Ming <[email protected]>
Signed-off-by: Len Brown <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit 5c77ea89ed79a692b0097dbca3652fbc83e30619
Author: Todd Poynor <[email protected]>
Date: Fri Jul 13 15:30:48 2012 +0900
ARM: SAMSUNG: fix race in s3c_adc_start for ADC
commit 8265981bb439f3ecc5356fb877a6c2a6636ac88a upstream.
Checking for adc->ts_pend already claimed should be done with the
lock held.
Signed-off-by: Todd Poynor <[email protected]>
Acked-by: Ben Dooks <[email protected]>
Signed-off-by: Kukjin Kim <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit e301f7b1dbbb0af6dcb8ed10c800fa95bb34917a
Author: NeilBrown <[email protected]>
Date: Mon Jul 9 11:34:13 2012 +1000
md/raid1: fix use-after-free bug in RAID1 data-check code.
commit 2d4f4f3384d4ef4f7c571448e803a1ce721113d5 upstream.
This bug has been present ever since data-check was introduce
in 2.6.16. However it would only fire if a data-check were
done on a degraded array, which was only possible if the array
has 3 or more devices. This is certainly possible, but is quite
uncommon.
Since hot-replace was added in 3.3 it can happen more often as
the same condition can arise if not all possible replacements are
present.
The problem is that as soon as we submit the last read request, the
'r1_bio' structure could be freed at any time, so we really should
stop looking at it. If the last device is being read from we will
stop looking at it. However if the last device is not due to be read
from, we will still check the bio pointer in the r1_bio, but the
r1_bio might already be free.
So use the read_targets counter to make sure we stop looking for bios
to submit as soon as we have submitted them all.
This fix is suitable for any -stable kernel since 2.6.16.
Reported-by: Arnold Schulz <[email protected]>
Signed-off-by: NeilBrown <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit a3a13c9974160030550ae28b3fa2c1ea8992b9c5
Author: Herton Ronaldo Krzesinski <[email protected]>
Date: Wed May 16 16:21:52 2012 -0300
mtd: nandsim: don't open code a do_div helper
commit 596fd46268634082314b3af1ded4612e1b7f3f03 upstream.
We don't need to open code the divide function, just use div_u64 that
already exists and do the same job. While this is a straightforward
clean up, there is more to that, the real motivation for this.
While building on a cross compiling environment in armel, using gcc
4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5), I was getting the following build
error:
ERROR: "__aeabi_uldivmod" [drivers/mtd/nand/nandsim.ko] undefined!
After investigating with objdump and hand built assembly version
generated with the compiler, I narrowed __aeabi_uldivmod as being
generated from the divide function. When nandsim.c is built with
-fno-inline-functions-called-once, that happens when
CONFIG_DEBUG_SECTION_MISMATCH is enabled, the do_div optimization in
arch/arm/include/asm/div64.h doesn't work as expected with the open
coded divide function: even if the do_div we are using doesn't have a
constant divisor, the compiler still includes the else parts of the
optimized do_div macro, and translates the divisions there to use
__aeabi_uldivmod, instead of only calling __do_div_asm -> __do_div64 and
optimizing/removing everything else out.
So to reproduce, gcc 4.6 plus CONFIG_DEBUG_SECTION_MISMATCH=y and
CONFIG_MTD_NAND_NANDSIM=m should do it, building on armel.
After this change, the compiler does the intended thing even with
-fno-inline-functions-called-once, and optimizes out as expected the
constant handling in the optimized do_div on arm. As this also avoids a
build issue, I'm marking for Stable, as I think is applicable for this
case.
Signed-off-by: Herton Ronaldo Krzesinski <[email protected]>
Acked-by: Nicolas Pitre <[email protected]>
Signed-off-by: Artem Bityutskiy <[email protected]>
Signed-off-by: David Woodhouse <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit a3fa551238b526b7b345da724b988650468cf36e
Author: Santosh Nayak <[email protected]>
Date: Sat Jun 23 07:59:54 2012 -0300
media: dvb-core: Release semaphore on error path dvb_register_device()
commit 82163edcdfa4eb3d74516cc8e9f38dd3d039b67d upstream.
There is a missing "up_write()" here. Semaphore should be released
before returning error value.
Signed-off-by: Santosh Nayak <[email protected]>
Signed-off-by: Mauro Carvalho Chehab <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit e2ea6a3e16a36e26af184f781ede7a12f6cff8b5
Author: Jeff Moyer <[email protected]>
Date: Thu Jul 12 09:43:14 2012 -0400
block: fix infinite loop in __getblk_slow
commit 91f68c89d8f35fe98ea04159b9a3b42d0149478f upstream.
Commit 080399aaaf35 ("block: don't mark buffers beyond end of disk as
mapped") exposed a bug in __getblk_slow that causes mount to hang as it
loops infinitely waiting for a buffer that lies beyond the end of the
disk to become uptodate.
The problem was initially reported by Torsten Hilbrich here:
https://lkml.org/lkml/2012/6/18/54
and also reported independently here:
http://www.sysresccd.org/forums/viewtopic.php?f=13&t=4511
and then Richard W.M. Jones and Marcos Mello noted a few separate
bugzillas also associated with the same issue. This patch has been
confirmed to fix:
https://bugzilla.redhat.com/show_bug.cgi?id=835019
The main problem is here, in __getblk_slow:
for (;;) {
struct buffer_head * bh;
int ret;
bh = __find_get_block(bdev, block, size);
if (bh)
return bh;
ret = grow_buffers(bdev, block, size);
if (ret < 0)
return NULL;
if (ret == 0)
free_more_memory();
}
__find_get_block does not find the block, since it will not be marked as
mapped, and so grow_buffers is called to fill in the buffers for the
associated page. I believe the for (;;) loop is there primarily to
retry in the case of memory pressure keeping grow_buffers from
succeeding. However, we also continue to loop for other cases, like the
block lying beond the end of the disk. So, the fix I came up with is to
only loop when grow_buffers fails due to memory allocation issues
(return value of 0).
The attached patch was tested by myself, Torsten, and Rich, and was
found to resolve the problem in call cases.
Signed-off-by: Jeff Moyer <[email protected]>
Reported-and-Tested-by: Torsten Hilbrich <[email protected]>
Tested-by: Richard W.M. Jones <[email protected]>
Reviewed-by: Josh Boyer <[email protected]>
[ Jens is on vacation, taking this directly - Linus ]
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit 175063bccaefa0b6a4934ffaf3a9639a4a7616d0
Author: Jean Delvare <[email protected]>
Date: Thu Jul 12 22:47:37 2012 +0200
hwmon: (it87) Preserve configuration register bits on init
commit 41002f8dd5938d5ad1d008ce5bfdbfe47fa7b4e8 upstream.
We were accidentally losing one bit in the configuration register on
device initialization. It was reported to freeze one specific system
right away. Properly preserve all bits we don't explicitly want to
change in order to prevent that.
Reported-by: Stevie Trujillo <[email protected]>
Signed-off-by: Jean Delvare <[email protected]>
Reviewed-by: Guenter Roeck <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit 9ab2f39f3ebbd4ccf2cdd75d564ee09c77c722ab
Author: David Dillow <[email protected]>
Date: Mon Jun 18 00:15:21 2012 -0300
media: cx231xx: don't DMA to random addresses
commit a7deca6fa79d5c65575532e780f3c93f6bf8ddad upstream.
Commit 7a6f6c29d264cdd2fe0eb3d923217eed5f0ad134 (cx231xx: use
URB_NO_TRANSFER_DMA_MAP) was intended to avoid mapping the DMA buffer
for URB twice. This works for the URBs allocated with usb_alloc_urb(),
as those are allocated from cohernent DMA pools, but the flag was also
added for the VBI and audio URBs, which have a manually allocated area.
This leaves the random trash in the structure after allocation as the
DMA address, corrupting memory and preventing VBI and audio from
working. Letting the USB core map the buffers solves the problem.
Signed-off-by: David Dillow <[email protected]>
Cc: Sri Deevi <[email protected]>
Signed-off-by: Mauro Carvalho Chehab <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit dfd45e89bc8040c45ad5df89fb01d7d0138ec953
Author: Dave Jones <[email protected]>
Date: Fri Jul 13 13:35:36 2012 -0400
Remove easily user-triggerable BUG from generic_setlease
commit 8d657eb3b43861064d36241e88d9d61c709f33f0 upstream.
This can be trivially triggered from userspace by passing in something unexpected.
kernel BUG at fs/locks.c:1468!
invalid opcode: 0000 [#1] SMP
RIP: 0010:generic_setlease+0xc2/0x100
Call Trace:
__vfs_setlease+0x35/0x40
fcntl_setlease+0x76/0x150
sys_fcntl+0x1c6/0x810
system_call_fastpath+0x1a/0x1f
Signed-off-by: Dave Jones <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
