This is the start of the stable review cycle for the 3.10.77 release.
There are 65 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.
Responses should be made by Mon May 4 19:00:04 UTC 2015.
Anything received after that time might be too late.
The whole patch series can be found in one patch at:
kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.10.77-rc1.gz
and the diffstat can be found below.
thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:
Greg Kroah-Hartman <[email protected]>
Linux 3.10.77-rc1
Dan Carpenter <[email protected]>
memstick: mspro_block: add missing curly braces
Nishanth Menon <[email protected]>
C6x: time: Ensure consistency in __init
Nicolas Iooss <[email protected]>
wl18xx: show rx_frames_per_rates as an array as it really is
mancha security <[email protected]>
lib: memzero_explicit: use barrier instead of OPTIMIZER_HIDE_VAR
Sabrina Dubroca <[email protected]>
e1000: add dummy allocator to fix race condition between mtu change and netpoll
Calvin Owens <[email protected]>
ksoftirqd: Enable IRQs and call cond_resched() before poking RCU
Al Viro <[email protected]>
RCU pathwalk breakage when running into a symlink overmounting something
Dmitry Torokhov <[email protected]>
drm/i915: cope with large i2c transfers
Alex Deucher <[email protected]>
drm/radeon: fix doublescan modes (v2)
Mark Brown <[email protected]>
i2c: core: Export bus recovery functions
Rabin Vincent <[email protected]>
tracing: Handle ftrace_dump() atomic context in graph_trace_open()
Erez Shitrit <[email protected]>
IB/mlx4: Fix WQE LSO segment calculation
Yann Droneaud <[email protected]>
IB/core: don't disallow registering region starting at 0x0
Yann Droneaud <[email protected]>
IB/core: disallow registering 0-sized memory region
Ezequiel Garcia <[email protected]>
stk1160: Make sure current buffer is released
James Bottomley <[email protected]>
mvsas: fix panic on expander attached SATA devices
K. Y. Srinivasan <[email protected]>
Drivers: hv: vmbus: Fix a bug in the error path in vmbus_open()
Gregory CLEMENT <[email protected]>
gpio: mvebu: Fix mask/unmask managment per irq chip type
Max Filippov <[email protected]>
xtensa: provide __NR_sync_file_range2 instead of __NR_sync_file_range
Max Filippov <[email protected]>
xtensa: xtfpga: fix hardware lockup caused by LCD driver
Lv Zheng <[email protected]>
ACPICA: Utilities: split IO address types from data type models.
Guenter Roeck <[email protected]>
drivers: parport: Kconfig: exclude arm64 for PARPORT_PC
K. Y. Srinivasan <[email protected]>
scsi: storvsc: Fix a bug in copy_from_bounce_buffer()
Brian Norris <[email protected]>
UBI: fix check for "too many bytes"
Brian Norris <[email protected]>
UBI: initialize LEB number variable
Brian Norris <[email protected]>
UBI: fix out of bounds write
Brian Norris <[email protected]>
UBI: account for bitflips in both the VID header and data
Thomas D <[email protected]>
tools/power turbostat: Use $(CURDIR) instead of $(PWD) and add support for O= option in Makefile
Anton Blanchard <[email protected]>
powerpc/perf: Cap 64bit userspace backtraces to PERF_MAX_STACK_DEPTH
Lukas Czerner <[email protected]>
ext4: make fsync to sync parent dir in no-journal for real this time
Chen Gang <[email protected]>
arm64: kernel: compiling issue, need delete read_current_timer()
Mark Brown <[email protected]>
video: vgacon: Don't build on arm64
Geert Uytterhoeven <[email protected]>
console: Disable VGA text console support on cris
Chen Gang <[email protected]>
drivers: parport: Kconfig: exclude h8300 for PARPORT_PC
Geert Uytterhoeven <[email protected]>
parport: disable PC-style parallel port support on cris
Marek Vasut <[email protected]>
rtlwifi: rtl8192cu: Add new device ID
Larry Finger <[email protected]>
rtlwifi: rtl8192cu: Add new USB ID
Oleg Nesterov <[email protected]>
ptrace: fix race between ptrace_resume() and wait_task_stopped()
Michael Davidson <[email protected]>
fs/binfmt_elf.c: fix bug in loading of PIE binaries
Ulrik De Bie <[email protected]>
Input: elantech - fix absolute mode setting on some ASUS laptops
Michael Gernoth <[email protected]>
ALSA: emu10k1: don't deadlock in proc-functions
Felipe Balbi <[email protected]>
usb: core: hub: use new USB_RESUME_TIMEOUT
Felipe Balbi <[email protected]>
usb: host: sl811: use new USB_RESUME_TIMEOUT
Felipe Balbi <[email protected]>
usb: host: xhci: use new USB_RESUME_TIMEOUT
Felipe Balbi <[email protected]>
usb: host: isp116x: use new USB_RESUME_TIMEOUT
Felipe Balbi <[email protected]>
usb: host: r8a66597: use new USB_RESUME_TIMEOUT
Felipe Balbi <[email protected]>
usb: define a generic USB_RESUME_TIMEOUT macro
Axel Lin <[email protected]>
usb: phy: Find the right match in devm_usb_phy_match
Charles Keepax <[email protected]>
ARM: S3C64XX: Use fixed IRQ bases to avoid conflicts on Cragganmore
Andrey Ryabinin <[email protected]>
ARM: 8320/1: fix integer overflow in ELF_ET_DYN_BASE
Krzysztof Kozlowski <[email protected]>
power_supply: lp8788-charger: Fix leaked power supply on probe fail
Steven Rostedt <[email protected]>
ring-buffer: Replace this_cpu_*() with __this_cpu_*()
Ian Abbott <[email protected]>
spi: spidev: fix possible arithmetic overflow for multi-transfer message
Oliver Neukum <[email protected]>
cdc-wdm: fix endianness bug in debug statements
Huacai Chen <[email protected]>
MIPS: Hibernate: flush TLB entries earlier
Radim Krčmář <[email protected]>
KVM: use slowpath for cross page cached accesses
Heiko Carstens <[email protected]>
s390/hibernate: fix save and restore of kernel text section
Ekaterina Tumanova <[email protected]>
KVM: s390: Zero out current VMDB of STSI before including level3 data.
Felipe Balbi <[email protected]>
usb: gadget: composite: enable BESL support
Len Brown <[email protected]>
sched/idle/x86: Restore mwait_idle() to fix boot hangs, to improve power savings and to improve performance
Filipe Manana <[email protected]>
Btrfs: fix inode eviction infinite loop after cloning into it
Filipe Manana <[email protected]>
Btrfs: fix log tree corruption when fs mounted with -o discard
Eric Dumazet <[email protected]>
tcp: avoid looping in tcp_send_fin()
Eric Dumazet <[email protected]>
tcp: fix possible deadlock in tcp_send_fin()
Sebastian Pöhn <[email protected]>
ip_forward: Drop frames with attached skb->sk
-------------
Diffstat:
Makefile | 4 +-
arch/arm/include/asm/elf.h | 2 +-
arch/arm/mach-s3c64xx/crag6410.h | 1 +
arch/arm/mach-s3c64xx/mach-crag6410.c | 1 +
arch/arm64/include/asm/timex.h | 6 +-
arch/arm64/kernel/time.c | 6 --
arch/c6x/kernel/time.c | 2 +-
arch/mips/power/hibernate.S | 3 +-
arch/powerpc/perf/callchain.c | 2 +-
arch/s390/kernel/suspend.c | 4 ++
arch/s390/kvm/priv.c | 1 +
arch/x86/kernel/process.c | 49 ++++++++++++++++
arch/xtensa/Kconfig | 30 ++++++++++
arch/xtensa/include/uapi/asm/unistd.h | 2 +-
arch/xtensa/platforms/xtfpga/Makefile | 3 +-
.../platforms/xtfpga/include/platform/hardware.h | 3 -
.../xtensa/platforms/xtfpga/include/platform/lcd.h | 15 +++++
arch/xtensa/platforms/xtfpga/lcd.c | 55 +++++++++++-------
drivers/gpio/gpio-mvebu.c | 24 +++++---
drivers/gpu/drm/i915/i915_reg.h | 1 +
drivers/gpu/drm/i915/intel_i2c.c | 66 ++++++++++++++++++----
drivers/gpu/drm/radeon/atombios_crtc.c | 8 ++-
drivers/hv/channel.c | 7 ++-
drivers/i2c/i2c-core.c | 3 +
drivers/infiniband/core/umem.c | 7 ++-
drivers/infiniband/hw/mlx4/qp.c | 3 +-
drivers/input/mouse/elantech.c | 22 ++++++++
drivers/input/mouse/elantech.h | 1 +
drivers/media/usb/stk1160/stk1160-v4l.c | 17 +++++-
drivers/memstick/core/mspro_block.c | 3 +-
drivers/mtd/ubi/attach.c | 2 +-
drivers/mtd/ubi/cdev.c | 2 +-
drivers/mtd/ubi/eba.c | 3 +-
drivers/mtd/ubi/wl.c | 2 +-
drivers/net/ethernet/intel/e1000/e1000_main.c | 10 +++-
drivers/net/wireless/rtlwifi/rtl8192cu/sw.c | 2 +
drivers/net/wireless/ti/wl18xx/debugfs.c | 2 +-
drivers/net/wireless/ti/wlcore/debugfs.h | 4 +-
drivers/parport/Kconfig | 4 +-
drivers/power/lp8788-charger.c | 4 +-
drivers/scsi/mvsas/mv_sas.c | 5 +-
drivers/scsi/storvsc_drv.c | 15 ++---
drivers/spi/spidev.c | 5 +-
drivers/usb/class/cdc-wdm.c | 12 ++--
drivers/usb/core/hub.c | 4 +-
drivers/usb/gadget/composite.c | 2 +-
drivers/usb/host/isp116x-hcd.c | 2 +-
drivers/usb/host/r8a66597-hcd.c | 2 +-
drivers/usb/host/sl811-hcd.c | 2 +-
drivers/usb/host/xhci-ring.c | 2 +-
drivers/usb/phy/phy.c | 4 +-
drivers/video/console/Kconfig | 5 +-
fs/binfmt_elf.c | 9 ++-
fs/btrfs/extent-tree.c | 5 +-
fs/btrfs/ioctl.c | 5 ++
fs/ext4/namei.c | 20 ++++---
fs/namei.c | 6 +-
include/acpi/actypes.h | 20 +++++++
include/acpi/platform/acenv.h | 1 +
include/linux/usb.h | 26 +++++++++
kernel/ptrace.c | 20 +++++++
kernel/softirq.c | 6 +-
kernel/trace/ring_buffer.c | 11 ++--
kernel/trace/trace_functions_graph.c | 8 ++-
lib/string.c | 2 +-
net/ipv4/ip_forward.c | 3 +
net/ipv4/tcp_output.c | 64 ++++++++++++++-------
sound/pci/emu10k1/emuproc.c | 12 ----
tools/power/x86/turbostat/Makefile | 6 +-
virt/kvm/kvm_main.c | 4 +-
70 files changed, 509 insertions(+), 165 deletions(-)
3.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: =?UTF-8?q?Sebastian=20P=C3=B6hn?= <[email protected]>
[ Upstream commit 2ab957492d13bb819400ac29ae55911d50a82a13 ]
Initial discussion was:
[FYI] xfrm: Don't lookup sk_policy for timewait sockets
Forwarded frames should not have a socket attached. Especially
tw sockets will lead to panics later-on in the stack.
This was observed with TPROXY assigning a tw socket and broken
policy routing (misconfigured). As a result frame enters
forwarding path instead of input. We cannot solve this in
TPROXY as it cannot know that policy routing is broken.
v2:
Remove useless comment
Signed-off-by: Sebastian Poehn <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
net/ipv4/ip_forward.c | 3 +++
1 file changed, 3 insertions(+)
--- a/net/ipv4/ip_forward.c
+++ b/net/ipv4/ip_forward.c
@@ -126,6 +126,9 @@ int ip_forward(struct sk_buff *skb)
struct rtable *rt; /* Route we use */
struct ip_options *opt = &(IPCB(skb)->opt);
+ if (unlikely(skb->sk))
+ goto drop;
+
if (skb_warn_if_lro(skb))
goto drop;
3.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Eric Dumazet <[email protected]>
[ Upstream commit d83769a580f1132ac26439f50068a29b02be535e ]
Using sk_stream_alloc_skb() in tcp_send_fin() is dangerous in
case a huge process is killed by OOM, and tcp_mem[2] is hit.
To be able to free memory we need to make progress, so this
patch allows FIN packets to not care about tcp_mem[2], if
skb allocation succeeded.
In a follow-up patch, we might abort tcp_send_fin() infinite loop
in case TIF_MEMDIE is set on this thread, as memory allocator
did its best getting extra memory already.
This patch reverts d22e15371811 ("tcp: fix tcp fin memory accounting")
Fixes: d22e15371811 ("tcp: fix tcp fin memory accounting")
Signed-off-by: Eric Dumazet <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
net/ipv4/tcp_output.c | 20 +++++++++++++++++++-
1 file changed, 19 insertions(+), 1 deletion(-)
--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
@@ -2571,6 +2571,21 @@ begin_fwd:
}
}
+/* We allow to exceed memory limits for FIN packets to expedite
+ * connection tear down and (memory) recovery.
+ * Otherwise tcp_send_fin() could loop forever.
+ */
+static void sk_forced_wmem_schedule(struct sock *sk, int size)
+{
+ int amt, status;
+
+ if (size <= sk->sk_forward_alloc)
+ return;
+ amt = sk_mem_pages(size);
+ sk->sk_forward_alloc += amt * SK_MEM_QUANTUM;
+ sk_memory_allocated_add(sk, amt, &status);
+}
+
/* Send a fin. The caller locks the socket for us. This cannot be
* allowed to fail queueing a FIN frame under any circumstances.
*/
@@ -2593,11 +2608,14 @@ void tcp_send_fin(struct sock *sk)
} else {
/* Socket is locked, keep trying until memory is available. */
for (;;) {
- skb = sk_stream_alloc_skb(sk, 0, sk->sk_allocation);
+ skb = alloc_skb_fclone(MAX_TCP_HEADER,
+ sk->sk_allocation);
if (skb)
break;
yield();
}
+ skb_reserve(skb, MAX_TCP_HEADER);
+ sk_forced_wmem_schedule(sk, skb->truesize);
/* FIN eats a sequence byte, write_seq advanced by tcp_queue_skb(). */
tcp_init_nondata_skb(skb, tp->write_seq,
TCPHDR_ACK | TCPHDR_FIN);
3.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Eric Dumazet <[email protected]>
[ Upstream commit 845704a535e9b3c76448f52af1b70e4422ea03fd ]
Presence of an unbound loop in tcp_send_fin() had always been hard
to explain when analyzing crash dumps involving gigantic dying processes
with millions of sockets.
Lets try a different strategy :
In case of memory pressure, try to add the FIN flag to last packet
in write queue, even if packet was already sent. TCP stack will
be able to deliver this FIN after a timeout event. Note that this
FIN being delivered by a retransmit, it also carries a Push flag
given our current implementation.
By checking sk_under_memory_pressure(), we anticipate that cooking
many FIN packets might deplete tcp memory.
In the case we could not allocate a packet, even with __GFP_WAIT
allocation, then not sending a FIN seems quite reasonable if it allows
to get rid of this socket, free memory, and not block the process from
eventually doing other useful work.
Signed-off-by: Eric Dumazet <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
net/ipv4/tcp_output.c | 50 +++++++++++++++++++++++++++++---------------------
1 file changed, 29 insertions(+), 21 deletions(-)
--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
@@ -2573,7 +2573,8 @@ begin_fwd:
/* We allow to exceed memory limits for FIN packets to expedite
* connection tear down and (memory) recovery.
- * Otherwise tcp_send_fin() could loop forever.
+ * Otherwise tcp_send_fin() could be tempted to either delay FIN
+ * or even be forced to close flow without any FIN.
*/
static void sk_forced_wmem_schedule(struct sock *sk, int size)
{
@@ -2586,33 +2587,40 @@ static void sk_forced_wmem_schedule(stru
sk_memory_allocated_add(sk, amt, &status);
}
-/* Send a fin. The caller locks the socket for us. This cannot be
- * allowed to fail queueing a FIN frame under any circumstances.
+/* Send a FIN. The caller locks the socket for us.
+ * We should try to send a FIN packet really hard, but eventually give up.
*/
void tcp_send_fin(struct sock *sk)
{
+ struct sk_buff *skb, *tskb = tcp_write_queue_tail(sk);
struct tcp_sock *tp = tcp_sk(sk);
- struct sk_buff *skb = tcp_write_queue_tail(sk);
- int mss_now;
- /* Optimization, tack on the FIN if we have a queue of
- * unsent frames. But be careful about outgoing SACKS
- * and IP options.
+ /* Optimization, tack on the FIN if we have one skb in write queue and
+ * this skb was not yet sent, or we are under memory pressure.
+ * Note: in the latter case, FIN packet will be sent after a timeout,
+ * as TCP stack thinks it has already been transmitted.
*/
- mss_now = tcp_current_mss(sk);
-
- if (tcp_send_head(sk) != NULL) {
- TCP_SKB_CB(skb)->tcp_flags |= TCPHDR_FIN;
- TCP_SKB_CB(skb)->end_seq++;
+ if (tskb && (tcp_send_head(sk) || sk_under_memory_pressure(sk))) {
+coalesce:
+ TCP_SKB_CB(tskb)->tcp_flags |= TCPHDR_FIN;
+ TCP_SKB_CB(tskb)->end_seq++;
tp->write_seq++;
+ if (!tcp_send_head(sk)) {
+ /* This means tskb was already sent.
+ * Pretend we included the FIN on previous transmit.
+ * We need to set tp->snd_nxt to the value it would have
+ * if FIN had been sent. This is because retransmit path
+ * does not change tp->snd_nxt.
+ */
+ tp->snd_nxt++;
+ return;
+ }
} else {
- /* Socket is locked, keep trying until memory is available. */
- for (;;) {
- skb = alloc_skb_fclone(MAX_TCP_HEADER,
- sk->sk_allocation);
- if (skb)
- break;
- yield();
+ skb = alloc_skb_fclone(MAX_TCP_HEADER, sk->sk_allocation);
+ if (unlikely(!skb)) {
+ if (tskb)
+ goto coalesce;
+ return;
}
skb_reserve(skb, MAX_TCP_HEADER);
sk_forced_wmem_schedule(sk, skb->truesize);
@@ -2621,7 +2629,7 @@ void tcp_send_fin(struct sock *sk)
TCPHDR_ACK | TCPHDR_FIN);
tcp_queue_skb(sk, skb);
}
- __tcp_push_pending_frames(sk, mss_now, TCP_NAGLE_OFF);
+ __tcp_push_pending_frames(sk, tcp_current_mss(sk), TCP_NAGLE_OFF);
}
/* We get here when a process closes a file descriptor (either due to
3.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Filipe Manana <[email protected]>
commit dcc82f4783ad91d4ab654f89f37ae9291cdc846a upstream.
While committing a transaction we free the log roots before we write the
new super block. Freeing the log roots implies marking the disk location
of every node/leaf (metadata extent) as pinned before the new super block
is written. This is to prevent the disk location of log metadata extents
from being reused before the new super block is written, otherwise we
would have a corrupted log tree if before the new super block is written
a crash/reboot happens and the location of any log tree metadata extent
ended up being reused and rewritten.
Even though we pinned the log tree's metadata extents, we were issuing a
discard against them if the fs was mounted with the -o discard option,
resulting in corruption of the log tree if a crash/reboot happened before
writing the new super block - the next time the fs was mounted, during
the log replay process we would find nodes/leafs of the log btree with
a content full of zeroes, causing the process to fail and require the
use of the tool btrfs-zero-log to wipeout the log tree (and all data
previously fsynced becoming lost forever).
Fix this by not doing a discard when pinning an extent. The discard will
be done later when it's safe (after the new super block is committed) at
extent-tree.c:btrfs_finish_extent_commit().
Fixes: e688b7252f78 (Btrfs: fix extent pinning bugs in the tree log)
Signed-off-by: Filipe Manana <[email protected]>
Signed-off-by: Chris Mason <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
fs/btrfs/extent-tree.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
--- a/fs/btrfs/extent-tree.c
+++ b/fs/btrfs/extent-tree.c
@@ -6363,12 +6363,11 @@ static int __btrfs_free_reserved_extent(
return -ENOSPC;
}
- if (btrfs_test_opt(root, DISCARD))
- ret = btrfs_discard_extent(root, start, len, NULL);
-
if (pin)
pin_down_extent(root, cache, start, len, 1);
else {
+ if (btrfs_test_opt(root, DISCARD))
+ ret = btrfs_discard_extent(root, start, len, NULL);
btrfs_add_free_space(cache, start, len);
btrfs_update_reserved_bytes(cache, len, RESERVE_FREE);
}
3.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Filipe Manana <[email protected]>
commit ccccf3d67294714af2d72a6fd6fd7d73b01c9329 upstream.
If we attempt to clone a 0 length region into a file we can end up
inserting a range in the inode's extent_io tree with a start offset
that is greater then the end offset, which triggers immediately the
following warning:
[ 3914.619057] WARNING: CPU: 17 PID: 4199 at fs/btrfs/extent_io.c:435 insert_state+0x4b/0x10b [btrfs]()
[ 3914.620886] BTRFS: end < start 4095 4096
(...)
[ 3914.638093] Call Trace:
[ 3914.638636] [<ffffffff81425fd9>] dump_stack+0x4c/0x65
[ 3914.639620] [<ffffffff81045390>] warn_slowpath_common+0xa1/0xbb
[ 3914.640789] [<ffffffffa03ca44f>] ? insert_state+0x4b/0x10b [btrfs]
[ 3914.642041] [<ffffffff810453f0>] warn_slowpath_fmt+0x46/0x48
[ 3914.643236] [<ffffffffa03ca44f>] insert_state+0x4b/0x10b [btrfs]
[ 3914.644441] [<ffffffffa03ca729>] __set_extent_bit+0x107/0x3f4 [btrfs]
[ 3914.645711] [<ffffffffa03cb256>] lock_extent_bits+0x65/0x1bf [btrfs]
[ 3914.646914] [<ffffffff8142b2fb>] ? _raw_spin_unlock+0x28/0x33
[ 3914.648058] [<ffffffffa03cbac4>] ? test_range_bit+0xcc/0xde [btrfs]
[ 3914.650105] [<ffffffffa03cb3c3>] lock_extent+0x13/0x15 [btrfs]
[ 3914.651361] [<ffffffffa03db39e>] lock_extent_range+0x3d/0xcd [btrfs]
[ 3914.652761] [<ffffffffa03de1fe>] btrfs_ioctl_clone+0x278/0x388 [btrfs]
[ 3914.654128] [<ffffffff811226dd>] ? might_fault+0x58/0xb5
[ 3914.655320] [<ffffffffa03e0909>] btrfs_ioctl+0xb51/0x2195 [btrfs]
(...)
[ 3914.669271] ---[ end trace 14843d3e2e622fc1 ]---
This later makes the inode eviction handler enter an infinite loop that
keeps dumping the following warning over and over:
[ 3915.117629] WARNING: CPU: 22 PID: 4228 at fs/btrfs/extent_io.c:435 insert_state+0x4b/0x10b [btrfs]()
[ 3915.119913] BTRFS: end < start 4095 4096
(...)
[ 3915.137394] Call Trace:
[ 3915.137913] [<ffffffff81425fd9>] dump_stack+0x4c/0x65
[ 3915.139154] [<ffffffff81045390>] warn_slowpath_common+0xa1/0xbb
[ 3915.140316] [<ffffffffa03ca44f>] ? insert_state+0x4b/0x10b [btrfs]
[ 3915.141505] [<ffffffff810453f0>] warn_slowpath_fmt+0x46/0x48
[ 3915.142709] [<ffffffffa03ca44f>] insert_state+0x4b/0x10b [btrfs]
[ 3915.143849] [<ffffffffa03ca729>] __set_extent_bit+0x107/0x3f4 [btrfs]
[ 3915.145120] [<ffffffffa038c1e3>] ? btrfs_kill_super+0x17/0x23 [btrfs]
[ 3915.146352] [<ffffffff811548f6>] ? deactivate_locked_super+0x3b/0x50
[ 3915.147565] [<ffffffffa03cb256>] lock_extent_bits+0x65/0x1bf [btrfs]
[ 3915.148785] [<ffffffff8142b7e2>] ? _raw_write_unlock+0x28/0x33
[ 3915.149931] [<ffffffffa03bc325>] btrfs_evict_inode+0x196/0x482 [btrfs]
[ 3915.151154] [<ffffffff81168904>] evict+0xa0/0x148
[ 3915.152094] [<ffffffff811689e5>] dispose_list+0x39/0x43
[ 3915.153081] [<ffffffff81169564>] evict_inodes+0xdc/0xeb
[ 3915.154062] [<ffffffff81154418>] generic_shutdown_super+0x49/0xef
[ 3915.155193] [<ffffffff811546d1>] kill_anon_super+0x13/0x1e
[ 3915.156274] [<ffffffffa038c1e3>] btrfs_kill_super+0x17/0x23 [btrfs]
(...)
[ 3915.167404] ---[ end trace 14843d3e2e622fc2 ]---
So just bail out of the clone ioctl if the length of the region to clone
is zero, without locking any extent range, in order to prevent this issue
(same behaviour as a pwrite with a 0 length for example).
This is trivial to reproduce. For example, the steps for the test I just
made for fstests:
mkfs.btrfs -f SCRATCH_DEV
mount SCRATCH_DEV $SCRATCH_MNT
touch $SCRATCH_MNT/foo
touch $SCRATCH_MNT/bar
$CLONER_PROG -s 0 -d 4096 -l 0 $SCRATCH_MNT/foo $SCRATCH_MNT/bar
umount $SCRATCH_MNT
A test case for fstests follows soon.
Signed-off-by: Filipe Manana <[email protected]>
Reviewed-by: Omar Sandoval <[email protected]>
Signed-off-by: Chris Mason <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
fs/btrfs/ioctl.c | 5 +++++
1 file changed, 5 insertions(+)
--- a/fs/btrfs/ioctl.c
+++ b/fs/btrfs/ioctl.c
@@ -2572,6 +2572,11 @@ static noinline long btrfs_ioctl_clone(s
if (off + len == src->i_size)
len = ALIGN(src->i_size, bs) - off;
+ if (len == 0) {
+ ret = 0;
+ goto out_unlock;
+ }
+
/* verify the end result is block aligned */
if (!IS_ALIGNED(off, bs) || !IS_ALIGNED(off + len, bs) ||
!IS_ALIGNED(destoff, bs))
3.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Len Brown <[email protected]>
commit b253149b843f89cd300cbdbea27ce1f847506f99 upstream.
In Linux-3.9 we removed the mwait_idle() loop:
69fb3676df33 ("x86 idle: remove mwait_idle() and "idle=mwait" cmdline param")
The reasoning was that modern machines should be sufficiently
happy during the boot process using the default_idle() HALT
loop, until cpuidle loads and either acpi_idle or intel_idle
invoke the newer MWAIT-with-hints idle loop.
But two machines reported problems:
1. Certain Core2-era machines support MWAIT-C1 and HALT only.
MWAIT-C1 is preferred for optimal power and performance.
But if they support just C1, cpuidle never loads and
so they use the boot-time default idle loop forever.
2. Some laptops will boot-hang if HALT is used,
but will boot successfully if MWAIT is used.
This appears to be a hidden assumption in BIOS SMI,
that is presumably valid on the proprietary OS
where the BIOS was validated.
https://bugzilla.kernel.org/show_bug.cgi?id=60770
So here we effectively revert the patch above, restoring
the mwait_idle() loop. However, we don't bother restoring
the idle=mwait cmdline parameter, since it appears to add
no value.
Maintainer notes:
For 3.9, simply revert 69fb3676df
for 3.10, patch -F3 applies, fuzz needed due to __cpuinit use in
context For 3.11, 3.12, 3.13, this patch applies cleanly
Tested-by: Mike Galbraith <[email protected]>
Signed-off-by: Len Brown <[email protected]>
Acked-by: Mike Galbraith <[email protected]>
Cc: <[email protected]> # 3.9+
Cc: Borislav Petkov <[email protected]>
Cc: H. Peter Anvin <[email protected]>
Cc: Ian Malone <[email protected]>
Cc: Josh Boyer <[email protected]>
Cc: Linus Torvalds <[email protected]>
Cc: Mike Galbraith <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Link: http://lkml.kernel.org/r/345254a551eb5a6a866e048d7ab570fd2193aca4.1389763084.git.len.brown@intel.com
[ Ported to recent kernels. ]
[ Mike: 3.10 backport ]
Signed-off-by: Ingo Molnar <[email protected]>
Signed-off-by: Mike Galbraith <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
arch/x86/kernel/process.c | 49 ++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 49 insertions(+)
--- a/arch/x86/kernel/process.c
+++ b/arch/x86/kernel/process.c
@@ -398,6 +398,52 @@ static void amd_e400_idle(void)
default_idle();
}
+/*
+ * Intel Core2 and older machines prefer MWAIT over HALT for C1.
+ * We can't rely on cpuidle installing MWAIT, because it will not load
+ * on systems that support only C1 -- so the boot default must be MWAIT.
+ *
+ * Some AMD machines are the opposite, they depend on using HALT.
+ *
+ * So for default C1, which is used during boot until cpuidle loads,
+ * use MWAIT-C1 on Intel HW that has it, else use HALT.
+ */
+static int prefer_mwait_c1_over_halt(const struct cpuinfo_x86 *c)
+{
+ if (c->x86_vendor != X86_VENDOR_INTEL)
+ return 0;
+
+ if (!cpu_has(c, X86_FEATURE_MWAIT))
+ return 0;
+
+ return 1;
+}
+
+/*
+ * MONITOR/MWAIT with no hints, used for default default C1 state.
+ * This invokes MWAIT with interrutps enabled and no flags,
+ * which is backwards compatible with the original MWAIT implementation.
+ */
+
+static void mwait_idle(void)
+{
+ if (!current_set_polling_and_test()) {
+ if (static_cpu_has(X86_FEATURE_CLFLUSH_MONITOR)) {
+ mb();
+ clflush((void *)¤t_thread_info()->flags);
+ mb();
+ }
+
+ __monitor((void *)¤t_thread_info()->flags, 0, 0);
+ if (!need_resched())
+ __sti_mwait(0, 0);
+ else
+ local_irq_enable();
+ } else
+ local_irq_enable();
+ __current_clr_polling();
+}
+
void __cpuinit select_idle_routine(const struct cpuinfo_x86 *c)
{
#ifdef CONFIG_SMP
@@ -411,6 +457,9 @@ void __cpuinit select_idle_routine(const
/* E400: APIC timer interrupt does not wake up CPU from C1e */
pr_info("using AMD E400 aware idle routine\n");
x86_idle = amd_e400_idle;
+ } else if (prefer_mwait_c1_over_halt(c)) {
+ pr_info("using mwait in idle threads\n");
+ x86_idle = mwait_idle;
} else
x86_idle = default_idle;
}
3.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Felipe Balbi <[email protected]>
commit a6615937bcd9234e6d6bb817c3701fce44d0a84d upstream.
According to USB 2.0 ECN Errata for Link Power
Management (USB2-LPM-Errata-final.pdf), BESL
must be enabled if LPM is enabled.
This helps with USB30CV TD 9.21 LPM L1
Suspend Resume Test.
Signed-off-by: Felipe Balbi <[email protected]>
Signed-off-by: Du, Changbin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/usb/gadget/composite.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/usb/gadget/composite.c
+++ b/drivers/usb/gadget/composite.c
@@ -528,7 +528,7 @@ static int bos_desc(struct usb_composite
usb_ext->bLength = USB_DT_USB_EXT_CAP_SIZE;
usb_ext->bDescriptorType = USB_DT_DEVICE_CAPABILITY;
usb_ext->bDevCapabilityType = USB_CAP_TYPE_EXT;
- usb_ext->bmAttributes = cpu_to_le32(USB_LPM_SUPPORT);
+ usb_ext->bmAttributes = cpu_to_le32(USB_LPM_SUPPORT | USB_BESL_SUPPORT);
/*
* The Superspeed USB Capability descriptor shall be implemented by all
3.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ekaterina Tumanova <[email protected]>
commit b75f4c9afac2604feb971441116c07a24ecca1ec upstream.
s390 documentation requires words 0 and 10-15 to be reserved and stored as
zeros. As we fill out all other fields, we can memset the full structure.
Signed-off-by: Ekaterina Tumanova <[email protected]>
Reviewed-by: David Hildenbrand <[email protected]>
Signed-off-by: Christian Borntraeger <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
arch/s390/kvm/priv.c | 1 +
1 file changed, 1 insertion(+)
--- a/arch/s390/kvm/priv.c
+++ b/arch/s390/kvm/priv.c
@@ -328,6 +328,7 @@ static void handle_stsi_3_2_2(struct kvm
for (n = mem->count - 1; n > 0 ; n--)
memcpy(&mem->vm[n], &mem->vm[n - 1], sizeof(mem->vm[0]));
+ memset(&mem->vm[0], 0, sizeof(mem->vm[0]));
mem->vm[0].cpus_total = cpus;
mem->vm[0].cpus_configured = cpus;
mem->vm[0].cpus_standby = 0;
3.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Heiko Carstens <[email protected]>
commit d74419495633493c9cd3f2bbeb7f3529d0edded6 upstream.
Sebastian reported a crash caused by a jump label mismatch after resume.
This happens because we do not save the kernel text section during suspend
and therefore also do not restore it during resume, but use the kernel image
that restores the old system.
This means that after a suspend/resume cycle we lost all modifications done
to the kernel text section.
The reason for this is the pfn_is_nosave() function, which incorrectly
returns that read-only pages don't need to be saved. This is incorrect since
we mark the kernel text section read-only.
We still need to make sure to not save and restore pages contained within
NSS and DCSS segment.
To fix this add an extra case for the kernel text section and only save
those pages if they are not contained within an NSS segment.
Fixes the following crash (and the above bugs as well):
Jump label code mismatch at netif_receive_skb_internal+0x28/0xd0
Found: c0 04 00 00 00 00
Expected: c0 f4 00 00 00 11
New: c0 04 00 00 00 00
Kernel panic - not syncing: Corrupted kernel text
CPU: 0 PID: 9 Comm: migration/0 Not tainted 3.19.0-01975-gb1b096e70f23 #4
Call Trace:
[<0000000000113972>] show_stack+0x72/0xf0
[<000000000081f15e>] dump_stack+0x6e/0x90
[<000000000081c4e8>] panic+0x108/0x2b0
[<000000000081be64>] jump_label_bug.isra.2+0x104/0x108
[<0000000000112176>] __jump_label_transform+0x9e/0xd0
[<00000000001121e6>] __sm_arch_jump_label_transform+0x3e/0x50
[<00000000001d1136>] multi_cpu_stop+0x12e/0x170
[<00000000001d1472>] cpu_stopper_thread+0xb2/0x168
[<000000000015d2ac>] smpboot_thread_fn+0x134/0x1b0
[<0000000000158baa>] kthread+0x10a/0x110
[<0000000000824a86>] kernel_thread_starter+0x6/0xc
Reported-and-tested-by: Sebastian Ott <[email protected]>
Signed-off-by: Heiko Carstens <[email protected]>
Signed-off-by: Martin Schwidefsky <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
arch/s390/kernel/suspend.c | 4 ++++
1 file changed, 4 insertions(+)
--- a/arch/s390/kernel/suspend.c
+++ b/arch/s390/kernel/suspend.c
@@ -138,6 +138,8 @@ int pfn_is_nosave(unsigned long pfn)
{
unsigned long nosave_begin_pfn = PFN_DOWN(__pa(&__nosave_begin));
unsigned long nosave_end_pfn = PFN_DOWN(__pa(&__nosave_end));
+ unsigned long eshared_pfn = PFN_DOWN(__pa(&_eshared)) - 1;
+ unsigned long stext_pfn = PFN_DOWN(__pa(&_stext));
/* Always save lowcore pages (LC protection might be enabled). */
if (pfn <= LC_PAGES)
@@ -145,6 +147,8 @@ int pfn_is_nosave(unsigned long pfn)
if (pfn >= nosave_begin_pfn && pfn < nosave_end_pfn)
return 1;
/* Skip memory holes and read-only pages (NSS, DCSS, ...). */
+ if (pfn >= stext_pfn && pfn <= eshared_pfn)
+ return ipl_info.type == IPL_TYPE_NSS ? 1 : 0;
if (tprot(PFN_PHYS(pfn)))
return 1;
return 0;
3.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Huacai Chen <[email protected]>
commit a843d00d038b11267279e3b5388222320f9ddc1d upstream.
We found that TLB mismatch not only happens after kernel resume, but
also happens during snapshot restore. So move it to the beginning of
swsusp_arch_suspend().
Signed-off-by: Huacai Chen <[email protected]>
Cc: Steven J. Hill <[email protected]>
Cc: [email protected]
Cc: Fuxin Zhang <[email protected]>
Cc: Zhangjin Wu <[email protected]>
Patchwork: https://patchwork.linux-mips.org/patch/9621/
Signed-off-by: Ralf Baechle <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
arch/mips/power/hibernate.S | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/arch/mips/power/hibernate.S
+++ b/arch/mips/power/hibernate.S
@@ -30,6 +30,8 @@ LEAF(swsusp_arch_suspend)
END(swsusp_arch_suspend)
LEAF(swsusp_arch_resume)
+ /* Avoid TLB mismatch during and after kernel resume */
+ jal local_flush_tlb_all
PTR_L t0, restore_pblist
0:
PTR_L t1, PBE_ADDRESS(t0) /* source */
@@ -43,7 +45,6 @@ LEAF(swsusp_arch_resume)
bne t1, t3, 1b
PTR_L t0, PBE_NEXT(t0)
bnez t0, 0b
- jal local_flush_tlb_all /* Avoid TLB mismatch after kernel resume */
PTR_LA t0, saved_regs
PTR_L ra, PT_R31(t0)
PTR_L sp, PT_R29(t0)
3.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Oliver Neukum <[email protected]>
commit 323ece54e0761198946ecd0c2091f1d2bfdfcb64 upstream.
Values directly from descriptors given in debug statements
must be converted to native endianness.
Signed-off-by: Oliver Neukum <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/usb/class/cdc-wdm.c | 12 +++++++-----
1 file changed, 7 insertions(+), 5 deletions(-)
--- a/drivers/usb/class/cdc-wdm.c
+++ b/drivers/usb/class/cdc-wdm.c
@@ -244,7 +244,7 @@ static void wdm_int_callback(struct urb
case USB_CDC_NOTIFY_RESPONSE_AVAILABLE:
dev_dbg(&desc->intf->dev,
"NOTIFY_RESPONSE_AVAILABLE received: index %d len %d",
- dr->wIndex, dr->wLength);
+ le16_to_cpu(dr->wIndex), le16_to_cpu(dr->wLength));
break;
case USB_CDC_NOTIFY_NETWORK_CONNECTION:
@@ -257,7 +257,9 @@ static void wdm_int_callback(struct urb
clear_bit(WDM_POLL_RUNNING, &desc->flags);
dev_err(&desc->intf->dev,
"unknown notification %d received: index %d len %d\n",
- dr->bNotificationType, dr->wIndex, dr->wLength);
+ dr->bNotificationType,
+ le16_to_cpu(dr->wIndex),
+ le16_to_cpu(dr->wLength));
goto exit;
}
@@ -403,7 +405,7 @@ static ssize_t wdm_write
USB_RECIP_INTERFACE);
req->bRequest = USB_CDC_SEND_ENCAPSULATED_COMMAND;
req->wValue = 0;
- req->wIndex = desc->inum;
+ req->wIndex = desc->inum; /* already converted */
req->wLength = cpu_to_le16(count);
set_bit(WDM_IN_USE, &desc->flags);
desc->outbuf = buf;
@@ -417,7 +419,7 @@ static ssize_t wdm_write
rv = usb_translate_errors(rv);
} else {
dev_dbg(&desc->intf->dev, "Tx URB has been submitted index=%d",
- req->wIndex);
+ le16_to_cpu(req->wIndex));
}
out:
usb_autopm_put_interface(desc->intf);
@@ -780,7 +782,7 @@ static int wdm_create(struct usb_interfa
desc->irq->bRequestType = (USB_DIR_IN | USB_TYPE_CLASS | USB_RECIP_INTERFACE);
desc->irq->bRequest = USB_CDC_GET_ENCAPSULATED_RESPONSE;
desc->irq->wValue = 0;
- desc->irq->wIndex = desc->inum;
+ desc->irq->wIndex = desc->inum; /* already converted */
desc->irq->wLength = cpu_to_le16(desc->wMaxCommand);
usb_fill_control_urb(
3.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ian Abbott <[email protected]>
commit f20fbaad7620af2df36a1f9d1c9ecf48ead5b747 upstream.
`spidev_message()` sums the lengths of the individual SPI transfers to
determine the overall SPI message length. It restricts the total
length, returning an error if too long, but it does not check for
arithmetic overflow. For example, if the SPI message consisted of two
transfers and the first has a length of 10 and the second has a length
of (__u32)(-1), the total length would be seen as 9, even though the
second transfer is actually very long. If the second transfer specifies
a null `rx_buf` and a non-null `tx_buf`, the `copy_from_user()` could
overrun the spidev's pre-allocated tx buffer before it reaches an
invalid user memory address. Fix it by checking that neither the total
nor the individual transfer lengths exceed the maximum allowed value.
Thanks to Dan Carpenter for reporting the potential integer overflow.
Signed-off-by: Ian Abbott <[email protected]>
Signed-off-by: Mark Brown <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/spi/spidev.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
--- a/drivers/spi/spidev.c
+++ b/drivers/spi/spidev.c
@@ -243,7 +243,10 @@ static int spidev_message(struct spidev_
k_tmp->len = u_tmp->len;
total += k_tmp->len;
- if (total > bufsiz) {
+ /* Check total length of transfers. Also check each
+ * transfer length to avoid arithmetic overflow.
+ */
+ if (total > bufsiz || k_tmp->len > bufsiz) {
status = -EMSGSIZE;
goto done;
}
3.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Steven Rostedt <[email protected]>
commit 80a9b64e2c156b6523e7a01f2ba6e5d86e722814 upstream.
It has come to my attention that this_cpu_read/write are horrible on
architectures other than x86. Worse yet, they actually disable
preemption or interrupts! This caused some unexpected tracing results
on ARM.
101.356868: preempt_count_add <-ring_buffer_lock_reserve
101.356870: preempt_count_sub <-ring_buffer_lock_reserve
The ring_buffer_lock_reserve has recursion protection that requires
accessing a per cpu variable. But since preempt_disable() is traced, it
too got traced while accessing the variable that is suppose to prevent
recursion like this.
The generic version of this_cpu_read() and write() are:
#define this_cpu_generic_read(pcp) \
({ typeof(pcp) ret__; \
preempt_disable(); \
ret__ = *this_cpu_ptr(&(pcp)); \
preempt_enable(); \
ret__; \
})
#define this_cpu_generic_to_op(pcp, val, op) \
do { \
unsigned long flags; \
raw_local_irq_save(flags); \
*__this_cpu_ptr(&(pcp)) op val; \
raw_local_irq_restore(flags); \
} while (0)
Which is unacceptable for locations that know they are within preempt
disabled or interrupt disabled locations.
Paul McKenney stated that __this_cpu_() versions produce much better code on
other architectures than this_cpu_() does, if we know that the call is done in
a preempt disabled location.
I also changed the recursive_unlock() to use two local variables instead
of accessing the per_cpu variable twice.
Link: http://lkml.kernel.org/r/[email protected]
Link: http://lkml.kernel.org/r/[email protected]
Acked-by: Christoph Lameter <[email protected]>
Reported-by: Uwe Kleine-Koenig <[email protected]>
Tested-by: Uwe Kleine-Koenig <[email protected]>
Signed-off-by: Steven Rostedt <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
kernel/trace/ring_buffer.c | 11 +++++------
1 file changed, 5 insertions(+), 6 deletions(-)
--- a/kernel/trace/ring_buffer.c
+++ b/kernel/trace/ring_buffer.c
@@ -2650,7 +2650,7 @@ static DEFINE_PER_CPU(unsigned int, curr
static __always_inline int trace_recursive_lock(void)
{
- unsigned int val = this_cpu_read(current_context);
+ unsigned int val = __this_cpu_read(current_context);
int bit;
if (in_interrupt()) {
@@ -2667,18 +2667,17 @@ static __always_inline int trace_recursi
return 1;
val |= (1 << bit);
- this_cpu_write(current_context, val);
+ __this_cpu_write(current_context, val);
return 0;
}
static __always_inline void trace_recursive_unlock(void)
{
- unsigned int val = this_cpu_read(current_context);
+ unsigned int val = __this_cpu_read(current_context);
- val--;
- val &= this_cpu_read(current_context);
- this_cpu_write(current_context, val);
+ val &= val & (val - 1);
+ __this_cpu_write(current_context, val);
}
#else
3.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Krzysztof Kozlowski <[email protected]>
commit a7117f81e8391e035c49b3440792f7e6cea28173 upstream.
Driver forgot to unregister charger power supply if registering of
battery supply failed in probe(). In such case the memory associated
with power supply leaked.
Signed-off-by: Krzysztof Kozlowski <[email protected]>
Fixes: 98a276649358 ("power_supply: Add new lp8788 charger driver")
Signed-off-by: Sebastian Reichel <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/power/lp8788-charger.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/drivers/power/lp8788-charger.c
+++ b/drivers/power/lp8788-charger.c
@@ -417,8 +417,10 @@ static int lp8788_psy_register(struct pl
pchg->battery.num_properties = ARRAY_SIZE(lp8788_battery_prop);
pchg->battery.get_property = lp8788_battery_get_property;
- if (power_supply_register(&pdev->dev, &pchg->battery))
+ if (power_supply_register(&pdev->dev, &pchg->battery)) {
+ power_supply_unregister(&pchg->charger);
return -EPERM;
+ }
return 0;
}
3.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Andrey Ryabinin <[email protected]>
commit 8defb3367fcd19d1af64c07792aade0747b54e0f upstream.
Usually ELF_ET_DYN_BASE is 2/3 of TASK_SIZE. With 3G/1G user/kernel
split this is not so, because 2*TASK_SIZE overflows 32 bits,
so the actual value of ELF_ET_DYN_BASE is:
(2 * TASK_SIZE / 3) = 0x2a000000
When ASLR is disabled PIE binaries will load at ELF_ET_DYN_BASE address.
On 32bit platforms AddressSanitzer uses addresses [0x20000000 - 0x40000000]
for shadow memory [1]. So ASan doesn't work for PIE binaries when ASLR disabled
as it fails to map shadow memory.
Also after Kees's 'split ET_DYN ASLR from mmap ASLR' patchset PIE binaries
has a high chance of loading somewhere in between [0x2a000000 - 0x40000000]
even if ASLR enabled. This makes ASan with PIE absolutely incompatible.
Fix overflow by dividing TASK_SIZE prior to multiplying.
After this patch ELF_ET_DYN_BASE equals to (for CONFIG_VMSPLIT_3G=y):
(TASK_SIZE / 3 * 2) = 0x7f555554
[1] https://code.google.com/p/address-sanitizer/wiki/AddressSanitizerAlgorithm#Mapping
Signed-off-by: Andrey Ryabinin <[email protected]>
Reported-by: Maria Guseva <[email protected]>
Signed-off-by: Russell King <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
arch/arm/include/asm/elf.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/arm/include/asm/elf.h
+++ b/arch/arm/include/asm/elf.h
@@ -116,7 +116,7 @@ int dump_task_regs(struct task_struct *t
the loader. We need to make sure that it is out of the way of the program
that it will "exec", and that there is sufficient room for the brk. */
-#define ELF_ET_DYN_BASE (2 * TASK_SIZE / 3)
+#define ELF_ET_DYN_BASE (TASK_SIZE / 3 * 2)
/* When the program starts, a1 contains a pointer to a function to be
registered with atexit, as per the SVR4 ABI. A value of 0 means we
3.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Charles Keepax <[email protected]>
commit 4e330ae4ab2915444f1e6dca1358a910aa259362 upstream.
There are two PMICs on Cragganmore, currently one dynamically assign
its IRQ base and the other uses a fixed base. It is possible for the
statically assigned PMIC to fail if its IRQ is taken by the dynamically
assigned one. Fix this by statically assigning both the IRQ bases.
Signed-off-by: Charles Keepax <[email protected]>
Signed-off-by: Kukjin Kim <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
arch/arm/mach-s3c64xx/crag6410.h | 1 +
arch/arm/mach-s3c64xx/mach-crag6410.c | 1 +
2 files changed, 2 insertions(+)
--- a/arch/arm/mach-s3c64xx/crag6410.h
+++ b/arch/arm/mach-s3c64xx/crag6410.h
@@ -14,6 +14,7 @@
#include <linux/gpio.h>
#define GLENFARCLAS_PMIC_IRQ_BASE IRQ_BOARD_START
+#define BANFF_PMIC_IRQ_BASE (IRQ_BOARD_START + 64)
#define PCA935X_GPIO_BASE GPIO_BOARD_START
#define CODEC_GPIO_BASE (GPIO_BOARD_START + 8)
--- a/arch/arm/mach-s3c64xx/mach-crag6410.c
+++ b/arch/arm/mach-s3c64xx/mach-crag6410.c
@@ -558,6 +558,7 @@ static struct wm831x_touch_pdata touch_p
static struct wm831x_pdata crag_pmic_pdata = {
.wm831x_num = 1,
+ .irq_base = BANFF_PMIC_IRQ_BASE,
.gpio_base = BANFF_PMIC_GPIO_BASE,
.soft_shutdown = true,
3.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Axel Lin <[email protected]>
commit 869aee0f31429fa9d94d5aef539602b73ae0cf4b upstream.
The res parameter passed to devm_usb_phy_match() is the location where the
pointer to the usb_phy is stored, hence it needs to be dereferenced before
comparing to the match data in order to find the correct match.
Fixes: 410219dcd2ba ("usb: otg: utils: devres: Add API's to associate a device with the phy")
Signed-off-by: Axel Lin <[email protected]>
Signed-off-by: Felipe Balbi <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/usb/phy/phy.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/drivers/usb/phy/phy.c
+++ b/drivers/usb/phy/phy.c
@@ -78,7 +78,9 @@ static void devm_usb_phy_release(struct
static int devm_usb_phy_match(struct device *dev, void *res, void *match_data)
{
- return res == match_data;
+ struct usb_phy **phy = res;
+
+ return *phy == match_data;
}
/**
3.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Felipe Balbi <[email protected]>
commit 62f0342de1f012f3e90607d39e20fce811391169 upstream.
Every USB Host controller should use this new
macro to define for how long resume signalling
should be driven on the bus.
Currently, almost every single USB controller
is using a 20ms timeout for resume signalling.
That's problematic for two reasons:
a) sometimes that 20ms timer expires a little
before 20ms, which makes us fail certification
b) some (many) devices actually need more than
20ms resume signalling.
Sure, in case of (b) we can state that the device
is against the USB spec, but the fact is that
we have no control over which device the certification
lab will use. We also have no control over which host
they will use. Most likely they'll be using a Windows
PC which, again, we have no control over how that
USB stack is written and how long resume signalling
they are using.
At the end of the day, we must make sure Linux passes
electrical compliance when working as Host or as Device
and currently we don't pass compliance as host because
we're driving resume signallig for exactly 20ms and
that confuses certification test setup resulting in
Certification failure.
Acked-by: Greg Kroah-Hartman <[email protected]>
Acked-by: Peter Chen <[email protected]>
Signed-off-by: Felipe Balbi <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
include/linux/usb.h | 26 ++++++++++++++++++++++++++
1 file changed, 26 insertions(+)
--- a/include/linux/usb.h
+++ b/include/linux/usb.h
@@ -206,6 +206,32 @@ void usb_put_intf(struct usb_interface *
#define USB_MAXINTERFACES 32
#define USB_MAXIADS (USB_MAXINTERFACES/2)
+/*
+ * USB Resume Timer: Every Host controller driver should drive the resume
+ * signalling on the bus for the amount of time defined by this macro.
+ *
+ * That way we will have a 'stable' behavior among all HCDs supported by Linux.
+ *
+ * Note that the USB Specification states we should drive resume for *at least*
+ * 20 ms, but it doesn't give an upper bound. This creates two possible
+ * situations which we want to avoid:
+ *
+ * (a) sometimes an msleep(20) might expire slightly before 20 ms, which causes
+ * us to fail USB Electrical Tests, thus failing Certification
+ *
+ * (b) Some (many) devices actually need more than 20 ms of resume signalling,
+ * and while we can argue that's against the USB Specification, we don't have
+ * control over which devices a certification laboratory will be using for
+ * certification. If CertLab uses a device which was tested against Windows and
+ * that happens to have relaxed resume signalling rules, we might fall into
+ * situations where we fail interoperability and electrical tests.
+ *
+ * In order to avoid both conditions, we're using a 40 ms resume timeout, which
+ * should cope with both LPJ calibration errors and devices not following every
+ * detail of the USB Specification.
+ */
+#define USB_RESUME_TIMEOUT 40 /* ms */
+
/**
* struct usb_interface_cache - long-term representation of a device interface
* @num_altsetting: number of altsettings defined.
3.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Felipe Balbi <[email protected]>
commit 7a606ac29752a3e571b83f9b3fceb1eaa1d37781 upstream.
While this driver was already using a 50ms resume
timeout, let's make sure everybody uses the same
macro so it's easy to fix later should anything
go wrong.
It also gives a more "stable" expectation to Linux
users.
Signed-off-by: Felipe Balbi <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/usb/host/r8a66597-hcd.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/usb/host/r8a66597-hcd.c
+++ b/drivers/usb/host/r8a66597-hcd.c
@@ -2301,7 +2301,7 @@ static int r8a66597_bus_resume(struct us
rh->port &= ~USB_PORT_STAT_SUSPEND;
rh->port |= USB_PORT_STAT_C_SUSPEND << 16;
r8a66597_mdfy(r8a66597, RESUME, RESUME | UACT, dvstctr_reg);
- msleep(50);
+ msleep(USB_RESUME_TIMEOUT);
r8a66597_mdfy(r8a66597, UACT, RESUME | UACT, dvstctr_reg);
}
3.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Felipe Balbi <[email protected]>
commit 8c0ae6574ccfd3d619876a65829aad74c9d22ba5 upstream.
Make sure we're using the new macro, so our
resume signaling will always pass certification.
Signed-off-by: Felipe Balbi <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/usb/host/isp116x-hcd.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/usb/host/isp116x-hcd.c
+++ b/drivers/usb/host/isp116x-hcd.c
@@ -1488,7 +1488,7 @@ static int isp116x_bus_resume(struct usb
spin_unlock_irq(&isp116x->lock);
hcd->state = HC_STATE_RESUMING;
- msleep(20);
+ msleep(USB_RESUME_TIMEOUT);
/* Go operational */
spin_lock_irq(&isp116x->lock);
3.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Felipe Balbi <[email protected]>
commit b9e451885deb6262dbaf5cd14aa77d192d9ac759 upstream.
Make sure we're using the new macro, so our
resume signaling will always pass certification.
Acked-by: Mathias Nyman <[email protected]>
Signed-off-by: Felipe Balbi <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/usb/host/xhci-ring.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -1697,7 +1697,7 @@ static void handle_port_status(struct xh
} else {
xhci_dbg(xhci, "resume HS port %d\n", port_id);
bus_state->resume_done[faked_port_index] = jiffies +
- msecs_to_jiffies(20);
+ msecs_to_jiffies(USB_RESUME_TIMEOUT);
set_bit(faked_port_index, &bus_state->resuming_ports);
mod_timer(&hcd->rh_timer,
bus_state->resume_done[faked_port_index]);
3.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Felipe Balbi <[email protected]>
commit 08debfb13b199716da6153940c31968c556b195d upstream.
Make sure we're using the new macro, so our
resume signaling will always pass certification.
Signed-off-by: Felipe Balbi <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/usb/host/sl811-hcd.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/usb/host/sl811-hcd.c
+++ b/drivers/usb/host/sl811-hcd.c
@@ -1251,7 +1251,7 @@ sl811h_hub_control(
sl811_write(sl811, SL11H_CTLREG1, sl811->ctrl1);
mod_timer(&sl811->timer, jiffies
- + msecs_to_jiffies(20));
+ + msecs_to_jiffies(USB_RESUME_TIMEOUT));
break;
case USB_PORT_FEAT_POWER:
port_power(sl811, 0);
3.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Felipe Balbi <[email protected]>
commit bbc78c07a51f6fd29c227b1220a9016e585358ba upstream.
Make sure we're using the new macro, so our
resume signaling will always pass certification.
Signed-off-by: Felipe Balbi <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/usb/core/hub.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -3282,10 +3282,10 @@ int usb_port_resume(struct usb_device *u
dev_dbg(hub->intfdev, "can't resume port %d, status %d\n",
port1, status);
} else {
- /* drive resume for at least 20 msec */
+ /* drive resume for USB_RESUME_TIMEOUT msec */
dev_dbg(&udev->dev, "usb %sresume\n",
(PMSG_IS_AUTO(msg) ? "auto-" : ""));
- msleep(25);
+ msleep(USB_RESUME_TIMEOUT);
/* Virtual root hubs can trigger on GET_PORT_STATUS to
* stop resume signaling. Then finish the resume
3.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Michael Gernoth <[email protected]>
commit 91bf0c2dcb935a87e5c0795f5047456b965fd143 upstream.
The functions snd_emu10k1_proc_spdif_read and snd_emu1010_fpga_read
acquire the emu_lock before accessing the FPGA. The function used
to access the FPGA (snd_emu1010_fpga_read) also tries to take
the emu_lock which causes a deadlock.
Remove the outer locking in the proc-functions (guarding only the
already safe fpga read) to prevent this deadlock.
[removed superfluous flags variables too -- tiwai]
Signed-off-by: Michael Gernoth <[email protected]>
Signed-off-by: Takashi Iwai <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
sound/pci/emu10k1/emuproc.c | 12 ------------
1 file changed, 12 deletions(-)
--- a/sound/pci/emu10k1/emuproc.c
+++ b/sound/pci/emu10k1/emuproc.c
@@ -241,31 +241,22 @@ static void snd_emu10k1_proc_spdif_read(
struct snd_emu10k1 *emu = entry->private_data;
u32 value;
u32 value2;
- unsigned long flags;
u32 rate;
if (emu->card_capabilities->emu_model) {
- spin_lock_irqsave(&emu->emu_lock, flags);
snd_emu1010_fpga_read(emu, 0x38, &value);
- spin_unlock_irqrestore(&emu->emu_lock, flags);
if ((value & 0x1) == 0) {
- spin_lock_irqsave(&emu->emu_lock, flags);
snd_emu1010_fpga_read(emu, 0x2a, &value);
snd_emu1010_fpga_read(emu, 0x2b, &value2);
- spin_unlock_irqrestore(&emu->emu_lock, flags);
rate = 0x1770000 / (((value << 5) | value2)+1);
snd_iprintf(buffer, "ADAT Locked : %u\n", rate);
} else {
snd_iprintf(buffer, "ADAT Unlocked\n");
}
- spin_lock_irqsave(&emu->emu_lock, flags);
snd_emu1010_fpga_read(emu, 0x20, &value);
- spin_unlock_irqrestore(&emu->emu_lock, flags);
if ((value & 0x4) == 0) {
- spin_lock_irqsave(&emu->emu_lock, flags);
snd_emu1010_fpga_read(emu, 0x28, &value);
snd_emu1010_fpga_read(emu, 0x29, &value2);
- spin_unlock_irqrestore(&emu->emu_lock, flags);
rate = 0x1770000 / (((value << 5) | value2)+1);
snd_iprintf(buffer, "SPDIF Locked : %d\n", rate);
} else {
@@ -410,14 +401,11 @@ static void snd_emu_proc_emu1010_reg_rea
{
struct snd_emu10k1 *emu = entry->private_data;
u32 value;
- unsigned long flags;
int i;
snd_iprintf(buffer, "EMU1010 Registers:\n\n");
for(i = 0; i < 0x40; i+=1) {
- spin_lock_irqsave(&emu->emu_lock, flags);
snd_emu1010_fpga_read(emu, i, &value);
- spin_unlock_irqrestore(&emu->emu_lock, flags);
snd_iprintf(buffer, "%02X: %08X, %02X\n", i, value, (value >> 8) & 0x7f);
}
}
3.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ulrik De Bie <[email protected]>
commit bd884149aca61de269fd9bad83fe2a4232ffab21 upstream.
On ASUS TP500LN and X750JN, the touchpad absolute mode is reset each
time set_rate is done.
In order to fix this, we will verify the firmware version, and if it
matches the one in those laptops, the set_rate function is overloaded
with a function elantech_set_rate_restore_reg_07 that performs the
set_rate with the original function, followed by a restore of reg_07
(the register that sets the absolute mode on elantech v4 hardware).
Also the ASUS TP500LN and X750JN firmware version, capabilities, and
button constellation is added to elantech.c
Reported-and-tested-by: George Moutsopoulos <[email protected]>
Signed-off-by: Ulrik De Bie <[email protected]>
Signed-off-by: Dmitry Torokhov <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/input/mouse/elantech.c | 22 ++++++++++++++++++++++
drivers/input/mouse/elantech.h | 1 +
2 files changed, 23 insertions(+)
--- a/drivers/input/mouse/elantech.c
+++ b/drivers/input/mouse/elantech.c
@@ -784,6 +784,21 @@ static psmouse_ret_t elantech_process_by
}
/*
+ * This writes the reg_07 value again to the hardware at the end of every
+ * set_rate call because the register loses its value. reg_07 allows setting
+ * absolute mode on v4 hardware
+ */
+static void elantech_set_rate_restore_reg_07(struct psmouse *psmouse,
+ unsigned int rate)
+{
+ struct elantech_data *etd = psmouse->private;
+
+ etd->original_set_rate(psmouse, rate);
+ if (elantech_write_reg(psmouse, 0x07, etd->reg_07))
+ psmouse_err(psmouse, "restoring reg_07 failed\n");
+}
+
+/*
* Put the touchpad into absolute mode
*/
static int elantech_set_absolute_mode(struct psmouse *psmouse)
@@ -985,6 +1000,8 @@ static int elantech_get_resolution_v4(st
* Asus K53SV 0x450f01 78, 15, 0c 2 hw buttons
* Asus G46VW 0x460f02 00, 18, 0c 2 hw buttons
* Asus G750JX 0x360f00 00, 16, 0c 2 hw buttons
+ * Asus TP500LN 0x381f17 10, 14, 0e clickpad
+ * Asus X750JN 0x381f17 10, 14, 0e clickpad
* Asus UX31 0x361f00 20, 15, 0e clickpad
* Asus UX32VD 0x361f02 00, 15, 0e clickpad
* Avatar AVIU-145A2 0x361f00 ? clickpad
@@ -1452,6 +1469,11 @@ int elantech_init(struct psmouse *psmous
goto init_fail;
}
+ if (etd->fw_version == 0x381f17) {
+ etd->original_set_rate = psmouse->set_rate;
+ psmouse->set_rate = elantech_set_rate_restore_reg_07;
+ }
+
if (elantech_set_input_params(psmouse)) {
psmouse_err(psmouse, "failed to query touchpad range.\n");
goto init_fail;
--- a/drivers/input/mouse/elantech.h
+++ b/drivers/input/mouse/elantech.h
@@ -138,6 +138,7 @@ struct elantech_data {
struct finger_pos mt[ETP_MAX_FINGERS];
unsigned char parity[256];
int (*send_cmd)(struct psmouse *psmouse, unsigned char c, unsigned char *param);
+ void (*original_set_rate)(struct psmouse *psmouse, unsigned int rate);
};
#ifdef CONFIG_MOUSE_PS2_ELANTECH
3.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Michael Davidson <[email protected]>
commit a87938b2e246b81b4fb713edb371a9fa3c5c3c86 upstream.
With CONFIG_ARCH_BINFMT_ELF_RANDOMIZE_PIE enabled, and a normal top-down
address allocation strategy, load_elf_binary() will attempt to map a PIE
binary into an address range immediately below mm->mmap_base.
Unfortunately, load_elf_ binary() does not take account of the need to
allocate sufficient space for the entire binary which means that, while
the first PT_LOAD segment is mapped below mm->mmap_base, the subsequent
PT_LOAD segment(s) end up being mapped above mm->mmap_base into the are
that is supposed to be the "gap" between the stack and the binary.
Since the size of the "gap" on x86_64 is only guaranteed to be 128MB this
means that binaries with large data segments > 128MB can end up mapping
part of their data segment over their stack resulting in corruption of the
stack (and the data segment once the binary starts to run).
Any PIE binary with a data segment > 128MB is vulnerable to this although
address randomization means that the actual gap between the stack and the
end of the binary is normally greater than 128MB. The larger the data
segment of the binary the higher the probability of failure.
Fix this by calculating the total size of the binary in the same way as
load_elf_interp().
Signed-off-by: Michael Davidson <[email protected]>
Cc: Alexander Viro <[email protected]>
Cc: Jiri Kosina <[email protected]>
Cc: Kees Cook <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
fs/binfmt_elf.c | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
--- a/fs/binfmt_elf.c
+++ b/fs/binfmt_elf.c
@@ -756,6 +756,7 @@ static int load_elf_binary(struct linux_
i < loc->elf_ex.e_phnum; i++, elf_ppnt++) {
int elf_prot = 0, elf_flags;
unsigned long k, vaddr;
+ unsigned long total_size = 0;
if (elf_ppnt->p_type != PT_LOAD)
continue;
@@ -820,10 +821,16 @@ static int load_elf_binary(struct linux_
#else
load_bias = ELF_PAGESTART(ELF_ET_DYN_BASE - vaddr);
#endif
+ total_size = total_mapping_size(elf_phdata,
+ loc->elf_ex.e_phnum);
+ if (!total_size) {
+ error = -EINVAL;
+ goto out_free_dentry;
+ }
}
error = elf_map(bprm->file, load_bias + vaddr, elf_ppnt,
- elf_prot, elf_flags, 0);
+ elf_prot, elf_flags, total_size);
if (BAD_ADDR(error)) {
send_sig(SIGKILL, current, 0);
retval = IS_ERR((void *)error) ?
3.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Oleg Nesterov <[email protected]>
commit b72c186999e689cb0b055ab1c7b3cd8fffbeb5ed upstream.
ptrace_resume() is called when the tracee is still __TASK_TRACED. We set
tracee->exit_code and then wake_up_state() changes tracee->state. If the
tracer's sub-thread does wait() in between, task_stopped_code(ptrace => T)
wrongly looks like another report from tracee.
This confuses debugger, and since wait_task_stopped() clears ->exit_code
the tracee can miss a signal.
Test-case:
#include <stdio.h>
#include <unistd.h>
#include <sys/wait.h>
#include <sys/ptrace.h>
#include <pthread.h>
#include <assert.h>
int pid;
void *waiter(void *arg)
{
int stat;
for (;;) {
assert(pid == wait(&stat));
assert(WIFSTOPPED(stat));
if (WSTOPSIG(stat) == SIGHUP)
continue;
assert(WSTOPSIG(stat) == SIGCONT);
printf("ERR! extra/wrong report:%x\n", stat);
}
}
int main(void)
{
pthread_t thread;
pid = fork();
if (!pid) {
assert(ptrace(PTRACE_TRACEME, 0,0,0) == 0);
for (;;)
kill(getpid(), SIGHUP);
}
assert(pthread_create(&thread, NULL, waiter, NULL) == 0);
for (;;)
ptrace(PTRACE_CONT, pid, 0, SIGCONT);
return 0;
}
Note for stable: the bug is very old, but without 9899d11f6544 "ptrace:
ensure arch_ptrace/ptrace_request can never race with SIGKILL" the fix
should use lock_task_sighand(child).
Signed-off-by: Oleg Nesterov <[email protected]>
Reported-by: Pavel Labath <[email protected]>
Tested-by: Pavel Labath <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
kernel/ptrace.c | 20 ++++++++++++++++++++
1 file changed, 20 insertions(+)
--- a/kernel/ptrace.c
+++ b/kernel/ptrace.c
@@ -720,6 +720,8 @@ static int ptrace_peek_siginfo(struct ta
static int ptrace_resume(struct task_struct *child, long request,
unsigned long data)
{
+ bool need_siglock;
+
if (!valid_signal(data))
return -EIO;
@@ -747,8 +749,26 @@ static int ptrace_resume(struct task_str
user_disable_single_step(child);
}
+ /*
+ * Change ->exit_code and ->state under siglock to avoid the race
+ * with wait_task_stopped() in between; a non-zero ->exit_code will
+ * wrongly look like another report from tracee.
+ *
+ * Note that we need siglock even if ->exit_code == data and/or this
+ * status was not reported yet, the new status must not be cleared by
+ * wait_task_stopped() after resume.
+ *
+ * If data == 0 we do not care if wait_task_stopped() reports the old
+ * status and clears the code too; this can't race with the tracee, it
+ * takes siglock after resume.
+ */
+ need_siglock = data && !thread_group_empty(current);
+ if (need_siglock)
+ spin_lock_irq(&child->sighand->siglock);
child->exit_code = data;
wake_up_state(child, __TASK_TRACED);
+ if (need_siglock)
+ spin_unlock_irq(&child->sighand->siglock);
return 0;
}
3.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Larry Finger <[email protected]>
commit 2f92b314f4daff2117847ac5343c54d3d041bf78 upstream.
USB ID 2001:330d is used for a D-Link DWA-131.
Signed-off-by: Larry Finger <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/net/wireless/rtlwifi/rtl8192cu/sw.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/net/wireless/rtlwifi/rtl8192cu/sw.c
+++ b/drivers/net/wireless/rtlwifi/rtl8192cu/sw.c
@@ -369,6 +369,7 @@ static struct usb_device_id rtl8192c_usb
{RTL_USB_DEVICE(0x2001, 0x3307, rtl92cu_hal_cfg)}, /*D-Link-Cameo*/
{RTL_USB_DEVICE(0x2001, 0x3309, rtl92cu_hal_cfg)}, /*D-Link-Alpha*/
{RTL_USB_DEVICE(0x2001, 0x330a, rtl92cu_hal_cfg)}, /*D-Link-Alpha*/
+ {RTL_USB_DEVICE(0x2001, 0x330d, rtl92cu_hal_cfg)}, /*D-Link DWA-131 */
{RTL_USB_DEVICE(0x2019, 0xab2b, rtl92cu_hal_cfg)}, /*Planex -Abocom*/
{RTL_USB_DEVICE(0x20f4, 0x624d, rtl92cu_hal_cfg)}, /*TRENDNet*/
{RTL_USB_DEVICE(0x2357, 0x0100, rtl92cu_hal_cfg)}, /*TP-Link WN8200ND*/
3.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Marek Vasut <[email protected]>
commit 9374e7d2fdcad3c36dafc8d3effd554bc702c4b6 upstream.
Add new ID for ASUS N10 WiFi dongle.
Signed-off-by: Marek Vasut <[email protected]>
Tested-by: Marek Vasut <[email protected]>
Cc: Larry Finger <[email protected]>
Cc: John W. Linville <[email protected]>
Acked-by: Larry Finger <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/net/wireless/rtlwifi/rtl8192cu/sw.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/net/wireless/rtlwifi/rtl8192cu/sw.c
+++ b/drivers/net/wireless/rtlwifi/rtl8192cu/sw.c
@@ -313,6 +313,7 @@ static struct usb_device_id rtl8192c_usb
{RTL_USB_DEVICE(0x07b8, 0x8188, rtl92cu_hal_cfg)}, /*Abocom - Abocom*/
{RTL_USB_DEVICE(0x07b8, 0x8189, rtl92cu_hal_cfg)}, /*Funai - Abocom*/
{RTL_USB_DEVICE(0x0846, 0x9041, rtl92cu_hal_cfg)}, /*NetGear WNA1000M*/
+ {RTL_USB_DEVICE(0x0b05, 0x17ba, rtl92cu_hal_cfg)}, /*ASUS-Edimax*/
{RTL_USB_DEVICE(0x0bda, 0x5088, rtl92cu_hal_cfg)}, /*Thinkware-CC&C*/
{RTL_USB_DEVICE(0x0df6, 0x0052, rtl92cu_hal_cfg)}, /*Sitecom - Edimax*/
{RTL_USB_DEVICE(0x0df6, 0x005c, rtl92cu_hal_cfg)}, /*Sitecom - Edimax*/
3.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Geert Uytterhoeven <[email protected]>
commit cb1ff5f90e1550d5752521205506b99f1aa8b1e0 upstream.
Signed-off-by: Geert Uytterhoeven <[email protected]>
Cc: Guenter Roeck <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/parport/Kconfig | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/drivers/parport/Kconfig
+++ b/drivers/parport/Kconfig
@@ -36,7 +36,9 @@ if PARPORT
config PARPORT_PC
tristate "PC-style hardware"
depends on (!SPARC64 || PCI) && !SPARC32 && !M32R && !FRV && !S390 && \
- (!M68K || ISA) && !MN10300 && !AVR32 && !BLACKFIN && !XTENSA
+ (!M68K || ISA) && !MN10300 && !AVR32 && !BLACKFIN && \
+ !XTENSA && !CRIS
+
---help---
You should say Y here if you have a PC-style parallel port. All
IBM PC compatible computers and some Alphas have PC-style
3.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Chen Gang <[email protected]>
commit d94bb2d756e525a7c67fa71762227533d48b03c9 upstream.
h8300 does not support PARPORT_PC.
The related error (with allmodconfig for h8300):
CC [M] drivers/parport/parport_pc.o
drivers/parport/parport_pc.c:67:25: fatal error: asm/parport.h: No such file or directory
Signed-off-by: Chen Gang <[email protected]>
Cc: Guenter Roeck <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/parport/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/parport/Kconfig
+++ b/drivers/parport/Kconfig
@@ -37,7 +37,7 @@ config PARPORT_PC
tristate "PC-style hardware"
depends on (!SPARC64 || PCI) && !SPARC32 && !M32R && !FRV && !S390 && \
(!M68K || ISA) && !MN10300 && !AVR32 && !BLACKFIN && \
- !XTENSA && !CRIS
+ !XTENSA && !CRIS && !H8300
---help---
You should say Y here if you have a PC-style parallel port. All
3.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Geert Uytterhoeven <[email protected]>
commit 3535629264e69ddbec0bd44b6f9a119947fbe4e2 upstream.
Signed-off-by: Geert Uytterhoeven <[email protected]>
Cc: Guenter Roeck <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/video/console/Kconfig | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/drivers/video/console/Kconfig
+++ b/drivers/video/console/Kconfig
@@ -6,7 +6,9 @@ menu "Console display driver support"
config VGA_CONSOLE
bool "VGA text console" if EXPERT || !X86
- depends on !4xx && !8xx && !SPARC && !M68K && !PARISC && !FRV && !SUPERH && !BLACKFIN && !AVR32 && !MN10300 && (!ARM || ARCH_FOOTBRIDGE || ARCH_INTEGRATOR || ARCH_NETWINDER)
+ depends on !4xx && !8xx && !SPARC && !M68K && !PARISC && !FRV && \
+ !SUPERH && !BLACKFIN && !AVR32 && !MN10300 && !CRIS && \
+ (!ARM || ARCH_FOOTBRIDGE || ARCH_INTEGRATOR || ARCH_NETWINDER)
default y
help
Saying Y here will allow you to use Linux in text mode through a
3.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mark Brown <[email protected]>
commit ee23794b86689e655cedd616e98c03bc3c74f5ec upstream.
arm64 is unlikely to have a VGA console and does not export screen_info
causing build failures if the driver is build, for example in all*config.
Add a dependency on !ARM64 to prevent this.
This list is getting quite long, it may be easier to depend on a symbol
which architectures that do support the driver can select.
Signed-off-by: Mark Brown <[email protected]>
[[email protected]: moved && to first modified line]
Signed-off-by: Tomi Valkeinen <[email protected]>
Cc: Guenter Roeck <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/video/console/Kconfig | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/drivers/video/console/Kconfig
+++ b/drivers/video/console/Kconfig
@@ -8,7 +8,8 @@ config VGA_CONSOLE
bool "VGA text console" if EXPERT || !X86
depends on !4xx && !8xx && !SPARC && !M68K && !PARISC && !FRV && \
!SUPERH && !BLACKFIN && !AVR32 && !MN10300 && !CRIS && \
- (!ARM || ARCH_FOOTBRIDGE || ARCH_INTEGRATOR || ARCH_NETWINDER)
+ (!ARM || ARCH_FOOTBRIDGE || ARCH_INTEGRATOR || ARCH_NETWINDER) && \
+ !ARM64
default y
help
Saying Y here will allow you to use Linux in text mode through a
3.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Chen Gang <[email protected]>
commit 6916b14ea140ff5c915895eefe9431888a39a84d upstream.
Under arm64, we will calibrate the delay loop statically using a known
timer frequency, so delete read_current_timer(), or it will cause
compiling issue with allmodconfig.
The related error:
ERROR: "read_current_timer" [lib/rbtree_test.ko] undefined!
ERROR: "read_current_timer" [lib/interval_tree_test.ko] undefined!
ERROR: "read_current_timer" [fs/ext4/ext4.ko] undefined!
ERROR: "read_current_timer" [crypto/tcrypt.ko] undefined!
Signed-off-by: Chen Gang <[email protected]>
Acked-by: Marc Zyngier <[email protected]>
Signed-off-by: Catalin Marinas <[email protected]>
Cc: Guenter Roeck <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
arch/arm64/include/asm/timex.h | 6 +++---
arch/arm64/kernel/time.c | 6 ------
2 files changed, 3 insertions(+), 9 deletions(-)
--- a/arch/arm64/include/asm/timex.h
+++ b/arch/arm64/include/asm/timex.h
@@ -16,14 +16,14 @@
#ifndef __ASM_TIMEX_H
#define __ASM_TIMEX_H
+#include <asm/arch_timer.h>
+
/*
* Use the current timer as a cycle counter since this is what we use for
* the delay loop.
*/
-#define get_cycles() ({ cycles_t c; read_current_timer(&c); c; })
+#define get_cycles() arch_counter_get_cntvct()
#include <asm-generic/timex.h>
-#define ARCH_HAS_READ_CURRENT_TIMER
-
#endif
--- a/arch/arm64/kernel/time.c
+++ b/arch/arm64/kernel/time.c
@@ -68,12 +68,6 @@ unsigned long long notrace sched_clock(v
return arch_timer_read_counter() * sched_clock_mult;
}
-int read_current_timer(unsigned long *timer_value)
-{
- *timer_value = arch_timer_read_counter();
- return 0;
-}
-
void __init time_init(void)
{
u32 arch_timer_rate;
3.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Lukas Czerner <[email protected]>
commit e12fb97222fc41e8442896934f76d39ef99b590a upstream.
Previously commit 14ece1028b3ed53ffec1b1213ffc6acaf79ad77c added a
support for for syncing parent directory of newly created inodes to
make sure that the inode is not lost after a power failure in
no-journal mode.
However this does not work in majority of cases, namely:
- if the directory has inline data
- if the directory is already indexed
- if the directory already has at least one block and:
- the new entry fits into it
- or we've successfully converted it to indexed
So in those cases we might lose the inode entirely even after fsync in
the no-journal mode. This also includes ext2 default mode obviously.
I've noticed this while running xfstest generic/321 and even though the
test should fail (we need to run fsck after a crash in no-journal mode)
I could not find a newly created entries even when if it was fsynced
before.
Fix this by adjusting the ext4_add_entry() successful exit paths to set
the inode EXT4_STATE_NEWENTRY so that fsync has the chance to fsync the
parent directory as well.
Signed-off-by: Lukas Czerner <[email protected]>
Signed-off-by: Theodore Ts'o <[email protected]>
Reviewed-by: Jan Kara <[email protected]>
Cc: Frank Mayhar <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
fs/ext4/namei.c | 20 +++++++++++---------
1 file changed, 11 insertions(+), 9 deletions(-)
--- a/fs/ext4/namei.c
+++ b/fs/ext4/namei.c
@@ -1880,7 +1880,7 @@ static int ext4_add_entry(handle_t *hand
struct inode *inode)
{
struct inode *dir = dentry->d_parent->d_inode;
- struct buffer_head *bh;
+ struct buffer_head *bh = NULL;
struct ext4_dir_entry_2 *de;
struct ext4_dir_entry_tail *t;
struct super_block *sb;
@@ -1905,14 +1905,14 @@ static int ext4_add_entry(handle_t *hand
return retval;
if (retval == 1) {
retval = 0;
- return retval;
+ goto out;
}
}
if (is_dx(dir)) {
retval = ext4_dx_add_entry(handle, dentry, inode);
if (!retval || (retval != ERR_BAD_DX_DIR))
- return retval;
+ goto out;
ext4_clear_inode_flag(dir, EXT4_INODE_INDEX);
dx_fallback++;
ext4_mark_inode_dirty(handle, dir);
@@ -1924,14 +1924,15 @@ static int ext4_add_entry(handle_t *hand
return PTR_ERR(bh);
retval = add_dirent_to_buf(handle, dentry, inode, NULL, bh);
- if (retval != -ENOSPC) {
- brelse(bh);
- return retval;
- }
+ if (retval != -ENOSPC)
+ goto out;
if (blocks == 1 && !dx_fallback &&
- EXT4_HAS_COMPAT_FEATURE(sb, EXT4_FEATURE_COMPAT_DIR_INDEX))
- return make_indexed_dir(handle, dentry, inode, bh);
+ EXT4_HAS_COMPAT_FEATURE(sb, EXT4_FEATURE_COMPAT_DIR_INDEX)) {
+ retval = make_indexed_dir(handle, dentry, inode, bh);
+ bh = NULL; /* make_indexed_dir releases bh */
+ goto out;
+ }
brelse(bh);
}
bh = ext4_append(handle, dir, &block);
@@ -1947,6 +1948,7 @@ static int ext4_add_entry(handle_t *hand
}
retval = add_dirent_to_buf(handle, dentry, inode, de, bh);
+out:
brelse(bh);
if (retval == 0)
ext4_set_inode_state(inode, EXT4_STATE_NEWENTRY);
3.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Anton Blanchard <[email protected]>
commit 9a5cbce421a283e6aea3c4007f141735bf9da8c3 upstream.
We cap 32bit userspace backtraces to PERF_MAX_STACK_DEPTH
(currently 127), but we forgot to do the same for 64bit backtraces.
Signed-off-by: Anton Blanchard <[email protected]>
Signed-off-by: Michael Ellerman <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
arch/powerpc/perf/callchain.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/powerpc/perf/callchain.c
+++ b/arch/powerpc/perf/callchain.c
@@ -243,7 +243,7 @@ static void perf_callchain_user_64(struc
sp = regs->gpr[1];
perf_callchain_store(entry, next_ip);
- for (;;) {
+ while (entry->nr < PERF_MAX_STACK_DEPTH) {
fp = (unsigned long __user *) sp;
if (!valid_user_sp(sp, 1) || read_user_stack_64(fp, &next_sp))
return;
3.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Thomas D <[email protected]>
commit f82263c6989c31ae9b94cecddffb29dcbec38710 upstream.
Since commit ee0778a30153
("tools/power: turbostat: make Makefile a bit more capable")
turbostat's Makefile is using
[...]
BUILD_OUTPUT := $(PWD)
[...]
which obviously causes trouble when building "turbostat" with
make -C /usr/src/linux/tools/power/x86/turbostat ARCH=x86 turbostat
because GNU make does not update nor guarantee that $PWD is set.
This patch changes the Makefile to use $CURDIR instead, which GNU make
guarantees to set and update (i.e. when using "make -C ...") and also
adds support for the O= option (see "make help" in your root of your
kernel source tree for more details).
Link: https://bugs.gentoo.org/show_bug.cgi?id=533918
Fixes: ee0778a30153 ("tools/power: turbostat: make Makefile a bit more capable")
Signed-off-by: Thomas D. <[email protected]>
Cc: Mark Asselstine <[email protected]>
Signed-off-by: Len Brown <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
tools/power/x86/turbostat/Makefile | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
--- a/tools/power/x86/turbostat/Makefile
+++ b/tools/power/x86/turbostat/Makefile
@@ -1,8 +1,12 @@
CC = $(CROSS_COMPILE)gcc
-BUILD_OUTPUT := $(PWD)
+BUILD_OUTPUT := $(CURDIR)
PREFIX := /usr
DESTDIR :=
+ifeq ("$(origin O)", "command line")
+ BUILD_OUTPUT := $(O)
+endif
+
turbostat : turbostat.c
CFLAGS += -Wall
CFLAGS += -DMSRHEADER='"../../../../arch/x86/include/uapi/asm/msr-index.h"'
3.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Brian Norris <[email protected]>
commit 8eef7d70f7c6772c3490f410ee2bceab3b543fa1 upstream.
We are completely discarding the earlier value of 'bitflips', which
could reflect a bitflip found in ubi_io_read_vid_hdr(). Let's use the
bitwise OR of header and data 'bitflip' statuses instead.
Coverity CID #1226856
Signed-off-by: Brian Norris <[email protected]>
Signed-off-by: Richard Weinberger <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/mtd/ubi/attach.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/mtd/ubi/attach.c
+++ b/drivers/mtd/ubi/attach.c
@@ -408,7 +408,7 @@ int ubi_compare_lebs(struct ubi_device *
second_is_newer = !second_is_newer;
} else {
dbg_bld("PEB %d CRC is OK", pnum);
- bitflips = !!err;
+ bitflips |= !!err;
}
mutex_unlock(&ubi->buf_mutex);
3.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Brian Norris <[email protected]>
commit d74adbdb9abf0d2506a6c4afa534d894f28b763f upstream.
If aeb->len >= vol->reserved_pebs, we should not be writing aeb into the
PEB->LEB mapping.
Caught by Coverity, CID #711212.
Signed-off-by: Brian Norris <[email protected]>
Signed-off-by: Richard Weinberger <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/mtd/ubi/eba.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/drivers/mtd/ubi/eba.c
+++ b/drivers/mtd/ubi/eba.c
@@ -1362,7 +1362,8 @@ int ubi_eba_init(struct ubi_device *ubi,
* during re-size.
*/
ubi_move_aeb_to_list(av, aeb, &ai->erase);
- vol->eba_tbl[aeb->lnum] = aeb->pnum;
+ else
+ vol->eba_tbl[aeb->lnum] = aeb->pnum;
}
}
3.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Brian Norris <[email protected]>
commit f16db8071ce18819fbd705ddcc91c6f392fb61f8 upstream.
In some of the 'out_not_moved' error paths, lnum may be used
uninitialized. Don't ignore the warning; let's fix it.
This uninitialized variable doesn't have much visible effect in the end,
since we just schedule the PEB for erasure, and its LEB number doesn't
really matter (it just gets printed in debug messages). But let's get it
straight anyway.
Coverity CID #113449
Signed-off-by: Brian Norris <[email protected]>
Signed-off-by: Richard Weinberger <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/mtd/ubi/wl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/mtd/ubi/wl.c
+++ b/drivers/mtd/ubi/wl.c
@@ -999,7 +999,7 @@ static int wear_leveling_worker(struct u
int cancel)
{
int err, scrubbing = 0, torture = 0, protect = 0, erroneous = 0;
- int vol_id = -1, uninitialized_var(lnum);
+ int vol_id = -1, lnum = -1;
#ifdef CONFIG_MTD_UBI_FASTMAP
int anchor = wrk->anchor;
#endif
3.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Brian Norris <[email protected]>
commit 299d0c5b27346a77a0777c993372bf8777d4f2e5 upstream.
The comparison from the previous line seems to have been erroneously
(partially) copied-and-pasted onto the next. The second line should be
checking req.bytes, not req.lnum.
Coverity CID #139400
Signed-off-by: Brian Norris <[email protected]>
[rw: Fixed comparison]
Signed-off-by: Richard Weinberger <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/mtd/ubi/cdev.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/mtd/ubi/cdev.c
+++ b/drivers/mtd/ubi/cdev.c
@@ -475,7 +475,7 @@ static long vol_cdev_ioctl(struct file *
/* Validate the request */
err = -EINVAL;
if (req.lnum < 0 || req.lnum >= vol->reserved_pebs ||
- req.bytes < 0 || req.lnum >= vol->usable_leb_size)
+ req.bytes < 0 || req.bytes > vol->usable_leb_size)
break;
err = get_exclusive(desc);
3.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: "K. Y. Srinivasan" <[email protected]>
commit 8de580742fee8bc34d116f57a20b22b9a5f08403 upstream.
We may exit this function without properly freeing up the maapings
we may have acquired. Fix the bug.
Signed-off-by: K. Y. Srinivasan <[email protected]>
Reviewed-by: Long Li <[email protected]>
Signed-off-by: James Bottomley <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/scsi/storvsc_drv.c | 15 ++++++++-------
1 file changed, 8 insertions(+), 7 deletions(-)
--- a/drivers/scsi/storvsc_drv.c
+++ b/drivers/scsi/storvsc_drv.c
@@ -631,21 +631,22 @@ static unsigned int copy_to_bounce_buffe
if (bounce_sgl[j].length == PAGE_SIZE) {
/* full..move to next entry */
sg_kunmap_atomic(bounce_addr);
+ bounce_addr = 0;
j++;
+ }
- /* if we need to use another bounce buffer */
- if (srclen || i != orig_sgl_count - 1)
- bounce_addr = sg_kmap_atomic(bounce_sgl,j);
+ /* if we need to use another bounce buffer */
+ if (srclen && bounce_addr == 0)
+ bounce_addr = sg_kmap_atomic(bounce_sgl, j);
- } else if (srclen == 0 && i == orig_sgl_count - 1) {
- /* unmap the last bounce that is < PAGE_SIZE */
- sg_kunmap_atomic(bounce_addr);
- }
}
sg_kunmap_atomic(src_addr - orig_sgl[i].offset);
}
+ if (bounce_addr)
+ sg_kunmap_atomic(bounce_addr);
+
local_irq_restore(flags);
return total_copied;
3.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Guenter Roeck <[email protected]>
Fix build problem seen with arm64:allmodconfig.
drivers/parport/parport_pc.c:67:25: fatal error: asm/parport.h: No such file or
directory
arm64 does not support PARPORT_PC.
Signed-off-by: Guenter Roeck <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
Please consider applying this patch to 3.10 and 3.12 (only).
There is no matching upstream commit; the problem was fixed differently
in later kernel versions. The upstream fix would require ~10 separate
patches and thus add more risk than it is worth (in my opinion).
drivers/parport/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/parport/Kconfig
+++ b/drivers/parport/Kconfig
@@ -37,7 +37,7 @@ config PARPORT_PC
tristate "PC-style hardware"
depends on (!SPARC64 || PCI) && !SPARC32 && !M32R && !FRV && !S390 && \
(!M68K || ISA) && !MN10300 && !AVR32 && !BLACKFIN && \
- !XTENSA && !CRIS && !H8300
+ !XTENSA && !CRIS && !H8300 && !ARM64
---help---
You should say Y here if you have a PC-style parallel port. All
3.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Lv Zheng <[email protected]>
commit 2b8760100e1de69b6ff004c986328a82947db4ad upstream.
ACPICA commit aacf863cfffd46338e268b7415f7435cae93b451
It is reported that on a physically 64-bit addressed machine, 32-bit kernel
can trigger crashes in accessing the memory regions that are beyond the
32-bit boundary. The region field's start address should still be 32-bit
compliant, but after a calculation (adding some offsets), it may exceed the
32-bit boundary. This case is rare and buggy, but there are real BIOSes
leaked with such issues (see References below).
This patch fixes this gap by always defining IO addresses as 64-bit, and
allows OSPMs to optimize it for a real 32-bit machine to reduce the size of
the internal objects.
Internal acpi_physical_address usages in the structures that can be fixed
by this change include:
1. struct acpi_object_region:
acpi_physical_address address;
2. struct acpi_address_range:
acpi_physical_address start_address;
acpi_physical_address end_address;
3. struct acpi_mem_space_context;
acpi_physical_address address;
4. struct acpi_table_desc
acpi_physical_address address;
See known issues 1 for other usages.
Note that acpi_io_address which is used for ACPI_PROCESSOR may also suffer
from same problem, so this patch changes it accordingly.
For iasl, it will enforce acpi_physical_address as 32-bit to generate
32-bit OSPM compatible tables on 32-bit platforms, we need to define
ACPI_32BIT_PHYSICAL_ADDRESS for it in acenv.h.
Known issues:
1. Cleanup of mapped virtual address
In struct acpi_mem_space_context, acpi_physical_address is used as a virtual
address:
acpi_physical_address mapped_physical_address;
It is better to introduce acpi_virtual_address or use acpi_size instead.
This patch doesn't make such a change. Because this should be done along
with a change to acpi_os_map_memory()/acpi_os_unmap_memory().
There should be no functional problem to leave this unchanged except
that only this structure is enlarged unexpectedly.
Link: https://github.com/acpica/acpica/commit/aacf863c
Reference: https://bugzilla.kernel.org/show_bug.cgi?id=87971
Reference: https://bugzilla.kernel.org/show_bug.cgi?id=79501
Reported-and-tested-by: Paul Menzel <[email protected]>
Reported-and-tested-by: Sial Nije <[email protected]>
Signed-off-by: Lv Zheng <[email protected]>
Signed-off-by: Bob Moore <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
include/acpi/actypes.h | 20 ++++++++++++++++++++
include/acpi/platform/acenv.h | 1 +
2 files changed, 21 insertions(+)
--- a/include/acpi/actypes.h
+++ b/include/acpi/actypes.h
@@ -198,9 +198,29 @@ typedef int INT32;
typedef s32 acpi_native_int;
typedef u32 acpi_size;
+
+#ifdef ACPI_32BIT_PHYSICAL_ADDRESS
+
+/*
+ * OSPMs can define this to shrink the size of the structures for 32-bit
+ * none PAE environment. ASL compiler may always define this to generate
+ * 32-bit OSPM compliant tables.
+ */
typedef u32 acpi_io_address;
typedef u32 acpi_physical_address;
+#else /* ACPI_32BIT_PHYSICAL_ADDRESS */
+
+/*
+ * It is reported that, after some calculations, the physical addresses can
+ * wrap over the 32-bit boundary on 32-bit PAE environment.
+ * https://bugzilla.kernel.org/show_bug.cgi?id=87971
+ */
+typedef u64 acpi_io_address;
+typedef u64 acpi_physical_address;
+
+#endif /* ACPI_32BIT_PHYSICAL_ADDRESS */
+
#define ACPI_MAX_PTR ACPI_UINT32_MAX
#define ACPI_SIZE_MAX ACPI_UINT32_MAX
--- a/include/acpi/platform/acenv.h
+++ b/include/acpi/platform/acenv.h
@@ -76,6 +76,7 @@
#define ACPI_LARGE_NAMESPACE_NODE
#define ACPI_DATA_TABLE_DISASSEMBLY
#define ACPI_SINGLE_THREADED
+#define ACPI_32BIT_PHYSICAL_ADDRESS
#endif
/* acpi_exec configuration. Multithreaded with full AML debugger */
3.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Max Filippov <[email protected]>
commit 4949009eb8d40a441dcddcd96e101e77d31cf1b2 upstream.
LCD driver is always built for the XTFPGA platform, but its base address
is not configurable, and is wrong for ML605/KC705. Its initialization
locks up KC705 board hardware.
Make the whole driver optional, and its base address and bus width
configurable. Implement 4-bit bus access method.
Signed-off-by: Max Filippov <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
arch/xtensa/Kconfig | 30 ++++++++
arch/xtensa/platforms/xtfpga/Makefile | 3
arch/xtensa/platforms/xtfpga/include/platform/hardware.h | 3
arch/xtensa/platforms/xtfpga/include/platform/lcd.h | 15 ++++
arch/xtensa/platforms/xtfpga/lcd.c | 55 +++++++++------
5 files changed, 81 insertions(+), 25 deletions(-)
--- a/arch/xtensa/Kconfig
+++ b/arch/xtensa/Kconfig
@@ -287,6 +287,36 @@ menu "Executable file formats"
source "fs/Kconfig.binfmt"
+config XTFPGA_LCD
+ bool "Enable XTFPGA LCD driver"
+ depends on XTENSA_PLATFORM_XTFPGA
+ default n
+ help
+ There's a 2x16 LCD on most of XTFPGA boards, kernel may output
+ progress messages there during bootup/shutdown. It may be useful
+ during board bringup.
+
+ If unsure, say N.
+
+config XTFPGA_LCD_BASE_ADDR
+ hex "XTFPGA LCD base address"
+ depends on XTFPGA_LCD
+ default "0x0d0c0000"
+ help
+ Base address of the LCD controller inside KIO region.
+ Different boards from XTFPGA family have LCD controller at different
+ addresses. Please consult prototyping user guide for your board for
+ the correct address. Wrong address here may lead to hardware lockup.
+
+config XTFPGA_LCD_8BIT_ACCESS
+ bool "Use 8-bit access to XTFPGA LCD"
+ depends on XTFPGA_LCD
+ default n
+ help
+ LCD may be connected with 4- or 8-bit interface, 8-bit access may
+ only be used with 8-bit interface. Please consult prototyping user
+ guide for your board for the correct interface width.
+
endmenu
source "net/Kconfig"
--- a/arch/xtensa/platforms/xtfpga/Makefile
+++ b/arch/xtensa/platforms/xtfpga/Makefile
@@ -6,4 +6,5 @@
#
# Note 2! The CFLAGS definitions are in the main makefile...
-obj-y = setup.o lcd.o
+obj-y += setup.o
+obj-$(CONFIG_XTFPGA_LCD) += lcd.o
--- a/arch/xtensa/platforms/xtfpga/include/platform/hardware.h
+++ b/arch/xtensa/platforms/xtfpga/include/platform/hardware.h
@@ -44,9 +44,6 @@
/* UART */
#define DUART16552_PADDR (XCHAL_KIO_PADDR + 0x0D050020)
-/* LCD instruction and data addresses. */
-#define LCD_INSTR_ADDR ((char *)IOADDR(0x0D040000))
-#define LCD_DATA_ADDR ((char *)IOADDR(0x0D040004))
/* Misc. */
#define XTFPGA_FPGAREGS_VADDR IOADDR(0x0D020000)
--- a/arch/xtensa/platforms/xtfpga/include/platform/lcd.h
+++ b/arch/xtensa/platforms/xtfpga/include/platform/lcd.h
@@ -11,10 +11,25 @@
#ifndef __XTENSA_XTAVNET_LCD_H
#define __XTENSA_XTAVNET_LCD_H
+#ifdef CONFIG_XTFPGA_LCD
/* Display string STR at position POS on the LCD. */
void lcd_disp_at_pos(char *str, unsigned char pos);
/* Shift the contents of the LCD display left or right. */
void lcd_shiftleft(void);
void lcd_shiftright(void);
+#else
+static inline void lcd_disp_at_pos(char *str, unsigned char pos)
+{
+}
+
+static inline void lcd_shiftleft(void)
+{
+}
+
+static inline void lcd_shiftright(void)
+{
+}
+#endif
+
#endif
--- a/arch/xtensa/platforms/xtfpga/lcd.c
+++ b/arch/xtensa/platforms/xtfpga/lcd.c
@@ -1,50 +1,63 @@
/*
- * Driver for the LCD display on the Tensilica LX60 Board.
+ * Driver for the LCD display on the Tensilica XTFPGA board family.
+ * http://www.mytechcorp.com/cfdata/productFile/File1/MOC-16216B-B-A0A04.pdf
*
* This file is subject to the terms and conditions of the GNU General Public
* License. See the file "COPYING" in the main directory of this archive
* for more details.
*
* Copyright (C) 2001, 2006 Tensilica Inc.
+ * Copyright (C) 2015 Cadence Design Systems Inc.
*/
-/*
- *
- * FIXME: this code is from the examples from the LX60 user guide.
- *
- * The lcd_pause function does busy waiting, which is probably not
- * great. Maybe the code could be changed to use kernel timers, or
- * change the hardware to not need to wait.
- */
-
+#include <linux/delay.h>
#include <linux/init.h>
#include <linux/io.h>
#include <platform/hardware.h>
#include <platform/lcd.h>
-#include <linux/delay.h>
-#define LCD_PAUSE_ITERATIONS 4000
+/* LCD instruction and data addresses. */
+#define LCD_INSTR_ADDR ((char *)IOADDR(CONFIG_XTFPGA_LCD_BASE_ADDR))
+#define LCD_DATA_ADDR (LCD_INSTR_ADDR + 4)
+
#define LCD_CLEAR 0x1
#define LCD_DISPLAY_ON 0xc
/* 8bit and 2 lines display */
#define LCD_DISPLAY_MODE8BIT 0x38
+#define LCD_DISPLAY_MODE4BIT 0x28
#define LCD_DISPLAY_POS 0x80
#define LCD_SHIFT_LEFT 0x18
#define LCD_SHIFT_RIGHT 0x1c
+static void lcd_put_byte(u8 *addr, u8 data)
+{
+#ifdef CONFIG_XTFPGA_LCD_8BIT_ACCESS
+ ACCESS_ONCE(*addr) = data;
+#else
+ ACCESS_ONCE(*addr) = data & 0xf0;
+ ACCESS_ONCE(*addr) = (data << 4) & 0xf0;
+#endif
+}
+
static int __init lcd_init(void)
{
- *LCD_INSTR_ADDR = LCD_DISPLAY_MODE8BIT;
+ ACCESS_ONCE(*LCD_INSTR_ADDR) = LCD_DISPLAY_MODE8BIT;
mdelay(5);
- *LCD_INSTR_ADDR = LCD_DISPLAY_MODE8BIT;
+ ACCESS_ONCE(*LCD_INSTR_ADDR) = LCD_DISPLAY_MODE8BIT;
udelay(200);
- *LCD_INSTR_ADDR = LCD_DISPLAY_MODE8BIT;
+ ACCESS_ONCE(*LCD_INSTR_ADDR) = LCD_DISPLAY_MODE8BIT;
+ udelay(50);
+#ifndef CONFIG_XTFPGA_LCD_8BIT_ACCESS
+ ACCESS_ONCE(*LCD_INSTR_ADDR) = LCD_DISPLAY_MODE4BIT;
+ udelay(50);
+ lcd_put_byte(LCD_INSTR_ADDR, LCD_DISPLAY_MODE4BIT);
udelay(50);
- *LCD_INSTR_ADDR = LCD_DISPLAY_ON;
+#endif
+ lcd_put_byte(LCD_INSTR_ADDR, LCD_DISPLAY_ON);
udelay(50);
- *LCD_INSTR_ADDR = LCD_CLEAR;
+ lcd_put_byte(LCD_INSTR_ADDR, LCD_CLEAR);
mdelay(10);
lcd_disp_at_pos("XTENSA LINUX", 0);
return 0;
@@ -52,10 +65,10 @@ static int __init lcd_init(void)
void lcd_disp_at_pos(char *str, unsigned char pos)
{
- *LCD_INSTR_ADDR = LCD_DISPLAY_POS | pos;
+ lcd_put_byte(LCD_INSTR_ADDR, LCD_DISPLAY_POS | pos);
udelay(100);
while (*str != 0) {
- *LCD_DATA_ADDR = *str;
+ lcd_put_byte(LCD_DATA_ADDR, *str);
udelay(200);
str++;
}
@@ -63,13 +76,13 @@ void lcd_disp_at_pos(char *str, unsigned
void lcd_shiftleft(void)
{
- *LCD_INSTR_ADDR = LCD_SHIFT_LEFT;
+ lcd_put_byte(LCD_INSTR_ADDR, LCD_SHIFT_LEFT);
udelay(50);
}
void lcd_shiftright(void)
{
- *LCD_INSTR_ADDR = LCD_SHIFT_RIGHT;
+ lcd_put_byte(LCD_INSTR_ADDR, LCD_SHIFT_RIGHT);
udelay(50);
}
3.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Max Filippov <[email protected]>
commit 01e84c70fe40c8111f960987bcf7f931842e6d07 upstream.
xtensa actually uses sync_file_range2 implementation, so it should
define __NR_sync_file_range2 as other architectures that use that
function. That fixes userspace interface (that apparently never worked)
and avoids special-casing xtensa in libc implementations.
See the thread ending at
http://lists.busybox.net/pipermail/uclibc/2015-February/048833.html
for more details.
Signed-off-by: Max Filippov <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
arch/xtensa/include/uapi/asm/unistd.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/xtensa/include/uapi/asm/unistd.h
+++ b/arch/xtensa/include/uapi/asm/unistd.h
@@ -715,7 +715,7 @@ __SYSCALL(323, sys_process_vm_writev, 6)
__SYSCALL(324, sys_name_to_handle_at, 5)
#define __NR_open_by_handle_at 325
__SYSCALL(325, sys_open_by_handle_at, 3)
-#define __NR_sync_file_range 326
+#define __NR_sync_file_range2 326
__SYSCALL(326, sys_sync_file_range2, 6)
#define __NR_perf_event_open 327
__SYSCALL(327, sys_perf_event_open, 5)
3.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Gregory CLEMENT <[email protected]>
commit 61819549f572edd7fce53f228c0d8420cdc85f71 upstream.
Level IRQ handlers and edge IRQ handler are managed by tow different
sets of registers. But currently the driver uses the same mask for the
both registers. It lead to issues with the following scenario:
First, an IRQ is requested on a GPIO to be triggered on front. After,
this an other IRQ is requested for a GPIO of the same bank but
triggered on level. Then the first one will be also setup to be
triggered on level. It leads to an interrupt storm.
The different kind of handler are already associated with two
different irq chip type. With this patch the driver uses a private
mask for each one which solves this issue.
It has been tested on an Armada XP based board and on an Armada 375
board. For the both boards, with this patch is applied, there is no
such interrupt storm when running the previous scenario.
This bug was already fixed but in a different way in the legacy
version of this driver by Evgeniy Dushistov:
9ece8839b1277fb9128ff6833411614ab6c88d68 "ARM: orion: Fix for certain
sequence of request_irq can cause irq storm". The fact the new version
of the gpio drive could be affected had been discussed there:
http://thread.gmane.org/gmane.linux.ports.arm.kernel/344670/focus=364012
Reported-by: Evgeniy A. Dushistov <[email protected]>
Signed-off-by: Gregory CLEMENT <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/gpio/gpio-mvebu.c | 24 ++++++++++++++++--------
1 file changed, 16 insertions(+), 8 deletions(-)
--- a/drivers/gpio/gpio-mvebu.c
+++ b/drivers/gpio/gpio-mvebu.c
@@ -304,11 +304,13 @@ static void mvebu_gpio_edge_irq_mask(str
{
struct irq_chip_generic *gc = irq_data_get_irq_chip_data(d);
struct mvebu_gpio_chip *mvchip = gc->private;
+ struct irq_chip_type *ct = irq_data_get_chip_type(d);
u32 mask = 1 << (d->irq - gc->irq_base);
irq_gc_lock(gc);
- gc->mask_cache &= ~mask;
- writel_relaxed(gc->mask_cache, mvebu_gpioreg_edge_mask(mvchip));
+ ct->mask_cache_priv &= ~mask;
+
+ writel_relaxed(ct->mask_cache_priv, mvebu_gpioreg_edge_mask(mvchip));
irq_gc_unlock(gc);
}
@@ -316,11 +318,13 @@ static void mvebu_gpio_edge_irq_unmask(s
{
struct irq_chip_generic *gc = irq_data_get_irq_chip_data(d);
struct mvebu_gpio_chip *mvchip = gc->private;
+ struct irq_chip_type *ct = irq_data_get_chip_type(d);
+
u32 mask = 1 << (d->irq - gc->irq_base);
irq_gc_lock(gc);
- gc->mask_cache |= mask;
- writel_relaxed(gc->mask_cache, mvebu_gpioreg_edge_mask(mvchip));
+ ct->mask_cache_priv |= mask;
+ writel_relaxed(ct->mask_cache_priv, mvebu_gpioreg_edge_mask(mvchip));
irq_gc_unlock(gc);
}
@@ -328,11 +332,13 @@ static void mvebu_gpio_level_irq_mask(st
{
struct irq_chip_generic *gc = irq_data_get_irq_chip_data(d);
struct mvebu_gpio_chip *mvchip = gc->private;
+ struct irq_chip_type *ct = irq_data_get_chip_type(d);
+
u32 mask = 1 << (d->irq - gc->irq_base);
irq_gc_lock(gc);
- gc->mask_cache &= ~mask;
- writel_relaxed(gc->mask_cache, mvebu_gpioreg_level_mask(mvchip));
+ ct->mask_cache_priv &= ~mask;
+ writel_relaxed(ct->mask_cache_priv, mvebu_gpioreg_level_mask(mvchip));
irq_gc_unlock(gc);
}
@@ -340,11 +346,13 @@ static void mvebu_gpio_level_irq_unmask(
{
struct irq_chip_generic *gc = irq_data_get_irq_chip_data(d);
struct mvebu_gpio_chip *mvchip = gc->private;
+ struct irq_chip_type *ct = irq_data_get_chip_type(d);
+
u32 mask = 1 << (d->irq - gc->irq_base);
irq_gc_lock(gc);
- gc->mask_cache |= mask;
- writel_relaxed(gc->mask_cache, mvebu_gpioreg_level_mask(mvchip));
+ ct->mask_cache_priv |= mask;
+ writel_relaxed(ct->mask_cache_priv, mvebu_gpioreg_level_mask(mvchip));
irq_gc_unlock(gc);
}
3.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: "K. Y. Srinivasan" <[email protected]>
commit 40384e4bbeb9f2651fe9bffc0062d9f31ef625bf upstream.
Correctly rollback state if the failure occurs after we have handed over
the ownership of the buffer to the host.
Signed-off-by: K. Y. Srinivasan <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/hv/channel.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
--- a/drivers/hv/channel.c
+++ b/drivers/hv/channel.c
@@ -169,7 +169,7 @@ int vmbus_open(struct vmbus_channel *new
GFP_KERNEL);
if (!open_info) {
err = -ENOMEM;
- goto error0;
+ goto error_gpadl;
}
init_completion(&open_info->waitevent);
@@ -185,7 +185,7 @@ int vmbus_open(struct vmbus_channel *new
if (userdatalen > MAX_USER_DEFINED_BYTES) {
err = -EINVAL;
- goto error0;
+ goto error_gpadl;
}
if (userdatalen)
@@ -226,6 +226,9 @@ error1:
list_del(&open_info->msglistentry);
spin_unlock_irqrestore(&vmbus_connection.channelmsg_lock, flags);
+error_gpadl:
+ vmbus_teardown_gpadl(newchannel, newchannel->ringbuffer_gpadlhandle);
+
error0:
free_pages((unsigned long)out,
get_order(send_ringbuffer_size + recv_ringbuffer_size));
3.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: James Bottomley <[email protected]>
commit 56cbd0ccc1b508de19561211d7ab9e1c77e6b384 upstream.
mvsas is giving a General protection fault when it encounters an expander
attached ATA device. Analysis of mvs_task_prep_ata() shows that the driver is
assuming all ATA devices are locally attached and obtaining the phy mask by
indexing the local phy table (in the HBA structure) with the phy id. Since
expanders have many more phys than the HBA, this is causing the index into the
HBA phy table to overflow and returning rubbish as the pointer.
mvs_task_prep_ssp() instead does the phy mask using the port properties.
Mirror this in mvs_task_prep_ata() to fix the panic.
Reported-by: Adam Talbot <[email protected]>
Tested-by: Adam Talbot <[email protected]>
Signed-off-by: James Bottomley <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/scsi/mvsas/mv_sas.c | 5 +----
1 file changed, 1 insertion(+), 4 deletions(-)
--- a/drivers/scsi/mvsas/mv_sas.c
+++ b/drivers/scsi/mvsas/mv_sas.c
@@ -441,14 +441,11 @@ static u32 mvs_get_ncq_tag(struct sas_ta
static int mvs_task_prep_ata(struct mvs_info *mvi,
struct mvs_task_exec_info *tei)
{
- struct sas_ha_struct *sha = mvi->sas;
struct sas_task *task = tei->task;
struct domain_device *dev = task->dev;
struct mvs_device *mvi_dev = dev->lldd_dev;
struct mvs_cmd_hdr *hdr = tei->hdr;
struct asd_sas_port *sas_port = dev->port;
- struct sas_phy *sphy = dev->phy;
- struct asd_sas_phy *sas_phy = sha->sas_phy[sphy->number];
struct mvs_slot_info *slot;
void *buf_prd;
u32 tag = tei->tag, hdr_tag;
@@ -468,7 +465,7 @@ static int mvs_task_prep_ata(struct mvs_
slot->tx = mvi->tx_prod;
del_q = TXQ_MODE_I | tag |
(TXQ_CMD_STP << TXQ_CMD_SHIFT) |
- (MVS_PHY_ID << TXQ_PHY_SHIFT) |
+ ((sas_port->phy_mask & TXQ_PHY_MASK) << TXQ_PHY_SHIFT) |
(mvi_dev->taskfileset << TXQ_SRS_SHIFT);
mvi->tx[mvi->tx_prod] = cpu_to_le32(del_q);
3.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ezequiel Garcia <[email protected]>
commit aeff09276748b66072f2db2e668cec955cf41959 upstream.
The available (i.e. not used) buffers are returned by stk1160_clear_queue(),
on the stop_streaming() path. However, this is insufficient and the current
buffer must be released as well. Fix it.
Signed-off-by: Ezequiel Garcia <[email protected]>
Signed-off-by: Hans Verkuil <[email protected]>
Signed-off-by: Mauro Carvalho Chehab <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/media/usb/stk1160/stk1160-v4l.c | 17 +++++++++++++++--
1 file changed, 15 insertions(+), 2 deletions(-)
--- a/drivers/media/usb/stk1160/stk1160-v4l.c
+++ b/drivers/media/usb/stk1160/stk1160-v4l.c
@@ -245,6 +245,11 @@ static int stk1160_stop_streaming(struct
if (mutex_lock_interruptible(&dev->v4l_lock))
return -ERESTARTSYS;
+ /*
+ * Once URBs are cancelled, the URB complete handler
+ * won't be running. This is required to safely release the
+ * current buffer (dev->isoc_ctl.buf).
+ */
stk1160_cancel_isoc(dev);
/*
@@ -665,8 +670,16 @@ void stk1160_clear_queue(struct stk1160
stk1160_info("buffer [%p/%d] aborted\n",
buf, buf->vb.v4l2_buf.index);
}
- /* It's important to clear current buffer */
- dev->isoc_ctl.buf = NULL;
+
+ /* It's important to release the current buffer */
+ if (dev->isoc_ctl.buf) {
+ buf = dev->isoc_ctl.buf;
+ dev->isoc_ctl.buf = NULL;
+
+ vb2_buffer_done(&buf->vb, VB2_BUF_STATE_ERROR);
+ stk1160_info("buffer [%p/%d] aborted\n",
+ buf, buf->vb.v4l2_buf.index);
+ }
spin_unlock_irqrestore(&dev->buf_lock, flags);
}
3.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Yann Droneaud <[email protected]>
commit 8abaae62f3fdead8f4ce0ab46b4ab93dee39bab2 upstream.
If ib_umem_get() is called with a size equal to 0 and an
non-page aligned address, one page will be pinned and a
0-sized umem will be returned to the caller.
This should not be allowed: it's not expected for a memory
region to have a size equal to 0.
This patch adds a check to explicitly refuse to register
a 0-sized region.
Link: http://mid.gmane.org/[email protected]
Cc: Shachar Raindel <[email protected]>
Cc: Jack Morgenstein <[email protected]>
Cc: Or Gerlitz <[email protected]>
Signed-off-by: Yann Droneaud <[email protected]>
Signed-off-by: Doug Ledford <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/infiniband/core/umem.c | 3 +++
1 file changed, 3 insertions(+)
--- a/drivers/infiniband/core/umem.c
+++ b/drivers/infiniband/core/umem.c
@@ -94,6 +94,9 @@ struct ib_umem *ib_umem_get(struct ib_uc
if (dmasync)
dma_set_attr(DMA_ATTR_WRITE_BARRIER, &attrs);
+ if (!size)
+ return ERR_PTR(-EINVAL);
+
/*
* If the combination of the addr and size requested for this memory
* region causes an integer overflow, return error.
3.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Yann Droneaud <[email protected]>
commit 66578b0b2f69659f00b6169e6fe7377c4b100d18 upstream.
In a call to ib_umem_get(), if address is 0x0 and size is
already page aligned, check added in commit 8494057ab5e4
("IB/uverbs: Prevent integer overflow in ib_umem_get address
arithmetic") will refuse to register a memory region that
could otherwise be valid (provided vm.mmap_min_addr sysctl
and mmap_low_allowed SELinux knobs allow userspace to map
something at address 0x0).
This patch allows back such registration: ib_umem_get()
should probably don't care of the base address provided it
can be pinned with get_user_pages().
There's two possible overflows, in (addr + size) and in
PAGE_ALIGN(addr + size), this patch keep ensuring none
of them happen while allowing to pin memory at address
0x0. Anyway, the case of size equal 0 is no more (partially)
handled as 0-length memory region are disallowed by an
earlier check.
Link: http://mid.gmane.org/[email protected]
Cc: Shachar Raindel <[email protected]>
Cc: Jack Morgenstein <[email protected]>
Cc: Or Gerlitz <[email protected]>
Signed-off-by: Yann Droneaud <[email protected]>
Reviewed-by: Sagi Grimberg <[email protected]>
Reviewed-by: Haggai Eran <[email protected]>
Signed-off-by: Doug Ledford <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/infiniband/core/umem.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/infiniband/core/umem.c
+++ b/drivers/infiniband/core/umem.c
@@ -101,8 +101,8 @@ struct ib_umem *ib_umem_get(struct ib_uc
* If the combination of the addr and size requested for this memory
* region causes an integer overflow, return error.
*/
- if ((PAGE_ALIGN(addr + size) <= size) ||
- (PAGE_ALIGN(addr + size) <= addr))
+ if (((addr + size) < addr) ||
+ PAGE_ALIGN(addr + size) < (addr + size))
return ERR_PTR(-EINVAL);
if (!can_do_mlock())
3.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Erez Shitrit <[email protected]>
commit ca9b590caa17bcbbea119594992666e96cde9c2f upstream.
The current code decreases from the mss size (which is the gso_size
from the kernel skb) the size of the packet headers.
It shouldn't do that because the mss that comes from the stack
(e.g IPoIB) includes only the tcp payload without the headers.
The result is indication to the HW that each packet that the HW sends
is smaller than what it could be, and too many packets will be sent
for big messages.
An easy way to demonstrate one more aspect of the problem is by
configuring the ipoib mtu to be less than 2*hlen (2*56) and then
run app sending big TCP messages. This will tell the HW to send packets
with giant (negative value which under unsigned arithmetics becomes
a huge positive one) length and the QP moves to SQE state.
Fixes: b832be1e4007 ('IB/mlx4: Add IPoIB LSO support')
Reported-by: Matthew Finlay <[email protected]>
Signed-off-by: Erez Shitrit <[email protected]>
Signed-off-by: Or Gerlitz <[email protected]>
Signed-off-by: Doug Ledford <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/infiniband/hw/mlx4/qp.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
--- a/drivers/infiniband/hw/mlx4/qp.c
+++ b/drivers/infiniband/hw/mlx4/qp.c
@@ -2174,8 +2174,7 @@ static int build_lso_seg(struct mlx4_wqe
memcpy(wqe->header, wr->wr.ud.header, wr->wr.ud.hlen);
- *lso_hdr_sz = cpu_to_be32((wr->wr.ud.mss - wr->wr.ud.hlen) << 16 |
- wr->wr.ud.hlen);
+ *lso_hdr_sz = cpu_to_be32(wr->wr.ud.mss << 16 | wr->wr.ud.hlen);
*lso_seg_len = halign;
return 0;
}
3.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Rabin Vincent <[email protected]>
commit ef99b88b16bee753fa51207abdc58ae660453ec6 upstream.
graph_trace_open() can be called in atomic context from ftrace_dump().
Use GFP_ATOMIC for the memory allocations when that's the case, in order
to avoid the following splat.
BUG: sleeping function called from invalid context at mm/slab.c:2849
in_atomic(): 1, irqs_disabled(): 128, pid: 0, name: swapper/0
Backtrace:
..
[<8004dc94>] (__might_sleep) from [<801371f4>] (kmem_cache_alloc_trace+0x160/0x238)
r7:87800040 r6:000080d0 r5:810d16e8 r4:000080d0
[<80137094>] (kmem_cache_alloc_trace) from [<800cbd60>] (graph_trace_open+0x30/0xd0)
r10:00000100 r9:809171a8 r8:00008e28 r7:810d16f0 r6:00000001 r5:810d16e8
r4:810d16f0
[<800cbd30>] (graph_trace_open) from [<800c79c4>] (trace_init_global_iter+0x50/0x9c)
r8:00008e28 r7:808c853c r6:00000001 r5:810d16e8 r4:810d16f0 r3:800cbd30
[<800c7974>] (trace_init_global_iter) from [<800c7aa0>] (ftrace_dump+0x90/0x2ec)
r4:810d2580 r3:00000000
[<800c7a10>] (ftrace_dump) from [<80414b2c>] (sysrq_ftrace_dump+0x1c/0x20)
r10:00000100 r9:809171a8 r8:808f6e7c r7:00000001 r6:00000007 r5:0000007a
r4:808d5394
[<80414b10>] (sysrq_ftrace_dump) from [<800169b8>] (return_to_handler+0x0/0x18)
[<80415498>] (__handle_sysrq) from [<800169b8>] (return_to_handler+0x0/0x18)
r8:808c8100 r7:808c8444 r6:00000101 r5:00000010 r4:84eb3210
[<80415668>] (handle_sysrq) from [<800169b8>] (return_to_handler+0x0/0x18)
[<8042a760>] (pl011_int) from [<800169b8>] (return_to_handler+0x0/0x18)
r10:809171bc r9:809171a8 r8:00000001 r7:00000026 r6:808c6000 r5:84f01e60
r4:8454fe00
[<8007782c>] (handle_irq_event_percpu) from [<80077b44>] (handle_irq_event+0x4c/0x6c)
r10:808c7ef0 r9:87283e00 r8:00000001 r7:00000000 r6:8454fe00 r5:84f01e60
r4:84f01e00
[<80077af8>] (handle_irq_event) from [<8007aa28>] (handle_fasteoi_irq+0xf0/0x1ac)
r6:808f52a4 r5:84f01e60 r4:84f01e00 r3:00000000
[<8007a938>] (handle_fasteoi_irq) from [<80076dc0>] (generic_handle_irq+0x3c/0x4c)
r6:00000026 r5:00000000 r4:00000026 r3:8007a938
[<80076d84>] (generic_handle_irq) from [<80077128>] (__handle_domain_irq+0x8c/0xfc)
r4:808c1e38 r3:0000002e
[<8007709c>] (__handle_domain_irq) from [<800087b8>] (gic_handle_irq+0x34/0x6c)
r10:80917748 r9:00000001 r8:88802100 r7:808c7ef0 r6:808c8fb0 r5:00000015
r4:8880210c r3:808c7ef0
[<80008784>] (gic_handle_irq) from [<80014044>] (__irq_svc+0x44/0x7c)
Link: http://lkml.kernel.org/r/[email protected]
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Rabin Vincent <[email protected]>
Signed-off-by: Steven Rostedt <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
kernel/trace/trace_functions_graph.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
--- a/kernel/trace/trace_functions_graph.c
+++ b/kernel/trace/trace_functions_graph.c
@@ -1382,15 +1382,19 @@ void graph_trace_open(struct trace_itera
{
/* pid and depth on the last trace processed */
struct fgraph_data *data;
+ gfp_t gfpflags;
int cpu;
iter->private = NULL;
- data = kzalloc(sizeof(*data), GFP_KERNEL);
+ /* We can be called in atomic context via ftrace_dump() */
+ gfpflags = (in_atomic() || irqs_disabled()) ? GFP_ATOMIC : GFP_KERNEL;
+
+ data = kzalloc(sizeof(*data), gfpflags);
if (!data)
goto out_err;
- data->cpu_data = alloc_percpu(struct fgraph_cpu_data);
+ data->cpu_data = alloc_percpu_gfp(struct fgraph_cpu_data, gfpflags);
if (!data->cpu_data)
goto out_err_free;
3.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mark Brown <[email protected]>
commit c1c21f4e60ed4523292f1a89ff45a208bddd3849 upstream.
Current -next fails to link an ARM allmodconfig because drivers that use
the core recovery functions can be built as modules but those functions
are not exported:
ERROR: "i2c_generic_gpio_recovery" [drivers/i2c/busses/i2c-davinci.ko] undefined!
ERROR: "i2c_generic_scl_recovery" [drivers/i2c/busses/i2c-davinci.ko] undefined!
ERROR: "i2c_recover_bus" [drivers/i2c/busses/i2c-davinci.ko] undefined!
Add exports to fix this.
Fixes: 5f9296ba21b3c (i2c: Add bus recovery infrastructure)
Signed-off-by: Mark Brown <[email protected]>
Signed-off-by: Wolfram Sang <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/i2c/i2c-core.c | 3 +++
1 file changed, 3 insertions(+)
--- a/drivers/i2c/i2c-core.c
+++ b/drivers/i2c/i2c-core.c
@@ -206,6 +206,7 @@ int i2c_generic_scl_recovery(struct i2c_
adap->bus_recovery_info->set_scl(adap, 1);
return i2c_generic_recovery(adap);
}
+EXPORT_SYMBOL_GPL(i2c_generic_scl_recovery);
int i2c_generic_gpio_recovery(struct i2c_adapter *adap)
{
@@ -220,6 +221,7 @@ int i2c_generic_gpio_recovery(struct i2c
return ret;
}
+EXPORT_SYMBOL_GPL(i2c_generic_gpio_recovery);
int i2c_recover_bus(struct i2c_adapter *adap)
{
@@ -229,6 +231,7 @@ int i2c_recover_bus(struct i2c_adapter *
dev_dbg(&adap->dev, "Trying i2c bus recovery\n");
return adap->bus_recovery_info->recover_bus(adap);
}
+EXPORT_SYMBOL_GPL(i2c_recover_bus);
static int i2c_device_probe(struct device *dev)
{
3.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alex Deucher <[email protected]>
commit fd99a0943ffaa0320ea4f69d09ed188f950c0432 upstream.
Use the correct flags for atom.
v2: handle DRM_MODE_FLAG_DBLCLK
Signed-off-by: Alex Deucher <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/gpu/drm/radeon/atombios_crtc.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
--- a/drivers/gpu/drm/radeon/atombios_crtc.c
+++ b/drivers/gpu/drm/radeon/atombios_crtc.c
@@ -312,8 +312,10 @@ atombios_set_crtc_dtd_timing(struct drm_
misc |= ATOM_COMPOSITESYNC;
if (mode->flags & DRM_MODE_FLAG_INTERLACE)
misc |= ATOM_INTERLACE;
- if (mode->flags & DRM_MODE_FLAG_DBLSCAN)
+ if (mode->flags & DRM_MODE_FLAG_DBLCLK)
misc |= ATOM_DOUBLE_CLOCK_MODE;
+ if (mode->flags & DRM_MODE_FLAG_DBLSCAN)
+ misc |= ATOM_H_REPLICATIONBY2 | ATOM_V_REPLICATIONBY2;
args.susModeMiscInfo.usAccess = cpu_to_le16(misc);
args.ucCRTC = radeon_crtc->crtc_id;
@@ -356,8 +358,10 @@ static void atombios_crtc_set_timing(str
misc |= ATOM_COMPOSITESYNC;
if (mode->flags & DRM_MODE_FLAG_INTERLACE)
misc |= ATOM_INTERLACE;
- if (mode->flags & DRM_MODE_FLAG_DBLSCAN)
+ if (mode->flags & DRM_MODE_FLAG_DBLCLK)
misc |= ATOM_DOUBLE_CLOCK_MODE;
+ if (mode->flags & DRM_MODE_FLAG_DBLSCAN)
+ misc |= ATOM_H_REPLICATIONBY2 | ATOM_V_REPLICATIONBY2;
args.susModeMiscInfo.usAccess = cpu_to_le16(misc);
args.ucCRTC = radeon_crtc->crtc_id;
3.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dmitry Torokhov <[email protected]>
commit 9535c4757b881e06fae72a857485ad57c422b8d2 upstream.
The hardware, according to the specs, is limited to 256 byte transfers,
and current driver has no protections in case users attempt to do larger
transfers. The code will just stomp over status register and mayhem
ensues.
Let's split larger transfers into digestable chunks. Doing this allows
Atmel MXT driver on Pixel 1 function properly (it hasn't since commit
9d8dc3e529a19e427fd379118acd132520935c5d "Input: atmel_mxt_ts -
implement T44 message handling" which tries to consume multiple
touchscreen/touchpad reports in a single transaction).
Reviewed-by: Chris Wilson <[email protected]>
Signed-off-by: Dmitry Torokhov <[email protected]>
Signed-off-by: Jani Nikula <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/gpu/drm/i915/i915_reg.h | 1
drivers/gpu/drm/i915/intel_i2c.c | 66 +++++++++++++++++++++++++++++++++------
2 files changed, 57 insertions(+), 10 deletions(-)
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -909,6 +909,7 @@
#define GMBUS_CYCLE_INDEX (2<<25)
#define GMBUS_CYCLE_STOP (4<<25)
#define GMBUS_BYTE_COUNT_SHIFT 16
+#define GMBUS_BYTE_COUNT_MAX 256U
#define GMBUS_SLAVE_INDEX_SHIFT 8
#define GMBUS_SLAVE_ADDR_SHIFT 1
#define GMBUS_SLAVE_READ (1<<0)
--- a/drivers/gpu/drm/i915/intel_i2c.c
+++ b/drivers/gpu/drm/i915/intel_i2c.c
@@ -276,18 +276,17 @@ gmbus_wait_idle(struct drm_i915_private
}
static int
-gmbus_xfer_read(struct drm_i915_private *dev_priv, struct i2c_msg *msg,
- u32 gmbus1_index)
+gmbus_xfer_read_chunk(struct drm_i915_private *dev_priv,
+ unsigned short addr, u8 *buf, unsigned int len,
+ u32 gmbus1_index)
{
int reg_offset = dev_priv->gpio_mmio_base;
- u16 len = msg->len;
- u8 *buf = msg->buf;
I915_WRITE(GMBUS1 + reg_offset,
gmbus1_index |
GMBUS_CYCLE_WAIT |
(len << GMBUS_BYTE_COUNT_SHIFT) |
- (msg->addr << GMBUS_SLAVE_ADDR_SHIFT) |
+ (addr << GMBUS_SLAVE_ADDR_SHIFT) |
GMBUS_SLAVE_READ | GMBUS_SW_RDY);
while (len) {
int ret;
@@ -309,11 +308,35 @@ gmbus_xfer_read(struct drm_i915_private
}
static int
-gmbus_xfer_write(struct drm_i915_private *dev_priv, struct i2c_msg *msg)
+gmbus_xfer_read(struct drm_i915_private *dev_priv, struct i2c_msg *msg,
+ u32 gmbus1_index)
{
- int reg_offset = dev_priv->gpio_mmio_base;
- u16 len = msg->len;
u8 *buf = msg->buf;
+ unsigned int rx_size = msg->len;
+ unsigned int len;
+ int ret;
+
+ do {
+ len = min(rx_size, GMBUS_BYTE_COUNT_MAX);
+
+ ret = gmbus_xfer_read_chunk(dev_priv, msg->addr,
+ buf, len, gmbus1_index);
+ if (ret)
+ return ret;
+
+ rx_size -= len;
+ buf += len;
+ } while (rx_size != 0);
+
+ return 0;
+}
+
+static int
+gmbus_xfer_write_chunk(struct drm_i915_private *dev_priv,
+ unsigned short addr, u8 *buf, unsigned int len)
+{
+ int reg_offset = dev_priv->gpio_mmio_base;
+ unsigned int chunk_size = len;
u32 val, loop;
val = loop = 0;
@@ -325,8 +348,8 @@ gmbus_xfer_write(struct drm_i915_private
I915_WRITE(GMBUS3 + reg_offset, val);
I915_WRITE(GMBUS1 + reg_offset,
GMBUS_CYCLE_WAIT |
- (msg->len << GMBUS_BYTE_COUNT_SHIFT) |
- (msg->addr << GMBUS_SLAVE_ADDR_SHIFT) |
+ (chunk_size << GMBUS_BYTE_COUNT_SHIFT) |
+ (addr << GMBUS_SLAVE_ADDR_SHIFT) |
GMBUS_SLAVE_WRITE | GMBUS_SW_RDY);
while (len) {
int ret;
@@ -343,6 +366,29 @@ gmbus_xfer_write(struct drm_i915_private
if (ret)
return ret;
}
+
+ return 0;
+}
+
+static int
+gmbus_xfer_write(struct drm_i915_private *dev_priv, struct i2c_msg *msg)
+{
+ u8 *buf = msg->buf;
+ unsigned int tx_size = msg->len;
+ unsigned int len;
+ int ret;
+
+ do {
+ len = min(tx_size, GMBUS_BYTE_COUNT_MAX);
+
+ ret = gmbus_xfer_write_chunk(dev_priv, msg->addr, buf, len);
+ if (ret)
+ return ret;
+
+ buf += len;
+ tx_size -= len;
+ } while (tx_size != 0);
+
return 0;
}
3.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Al Viro <[email protected]>
commit 3cab989afd8d8d1bc3d99fef0e7ed87c31e7b647 upstream.
Calling unlazy_walk() in walk_component() and do_last() when we find
a symlink that needs to be followed doesn't acquire a reference to vfsmount.
That's fine when the symlink is on the same vfsmount as the parent directory
(which is almost always the case), but it's not always true - one _can_
manage to bind a symlink on top of something. And in such cases we end up
with excessive mntput().
Signed-off-by: Al Viro <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
fs/namei.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -1542,7 +1542,8 @@ static inline int walk_component(struct
if (should_follow_link(inode, follow)) {
if (nd->flags & LOOKUP_RCU) {
- if (unlikely(unlazy_walk(nd, path->dentry))) {
+ if (unlikely(nd->path.mnt != path->mnt ||
+ unlazy_walk(nd, path->dentry))) {
err = -ECHILD;
goto out_err;
}
@@ -2824,7 +2825,8 @@ finish_lookup:
if (should_follow_link(inode, !symlink_ok)) {
if (nd->flags & LOOKUP_RCU) {
- if (unlikely(unlazy_walk(nd, path->dentry))) {
+ if (unlikely(nd->path.mnt != path->mnt ||
+ unlazy_walk(nd, path->dentry))) {
error = -ECHILD;
goto out;
}
3.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Calvin Owens <[email protected]>
commit 28423ad283d5348793b0c45cc9b1af058e776fd6 upstream.
While debugging an issue with excessive softirq usage, I encountered the
following note in commit 3e339b5dae24a706 ("softirq: Use hotplug thread
infrastructure"):
[ paulmck: Call rcu_note_context_switch() with interrupts enabled. ]
...but despite this note, the patch still calls RCU with IRQs disabled.
This seemingly innocuous change caused a significant regression in softirq
CPU usage on the sending side of a large TCP transfer (~1 GB/s): when
introducing 0.01% packet loss, the softirq usage would jump to around 25%,
spiking as high as 50%. Before the change, the usage would never exceed 5%.
Moving the call to rcu_note_context_switch() after the cond_sched() call,
as it was originally before the hotplug patch, completely eliminated this
problem.
Signed-off-by: Calvin Owens <[email protected]>
Signed-off-by: Paul E. McKenney <[email protected]>
Signed-off-by: Mike Galbraith <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
kernel/softirq.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
--- a/kernel/softirq.c
+++ b/kernel/softirq.c
@@ -774,9 +774,13 @@ static void run_ksoftirqd(unsigned int c
local_irq_disable();
if (local_softirq_pending()) {
__do_softirq();
- rcu_note_context_switch(cpu);
local_irq_enable();
cond_resched();
+
+ preempt_disable();
+ rcu_note_context_switch(cpu);
+ preempt_enable();
+
return;
}
local_irq_enable();
3.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Sabrina Dubroca <[email protected]>
commit 08e8331654d1d7b2c58045e549005bc356aa7810 upstream.
There is a race condition between e1000_change_mtu's cleanups and
netpoll, when we change the MTU across jumbo size:
Changing MTU frees all the rx buffers:
e1000_change_mtu -> e1000_down -> e1000_clean_all_rx_rings ->
e1000_clean_rx_ring
Then, close to the end of e1000_change_mtu:
pr_info -> ... -> netpoll_poll_dev -> e1000_clean ->
e1000_clean_rx_irq -> e1000_alloc_rx_buffers -> e1000_alloc_frag
And when we come back to do the rest of the MTU change:
e1000_up -> e1000_configure -> e1000_configure_rx ->
e1000_alloc_jumbo_rx_buffers
alloc_jumbo finds the buffers already != NULL, since data (shared with
page in e1000_rx_buffer->rxbuf) has been re-alloc'd, but it's garbage,
or at least not what is expected when in jumbo state.
This results in an unusable adapter (packets don't get through), and a
NULL pointer dereference on the next call to e1000_clean_rx_ring
(other mtu change, link down, shutdown):
BUG: unable to handle kernel NULL pointer dereference at (null)
IP: [<ffffffff81194d6e>] put_compound_page+0x7e/0x330
[...]
Call Trace:
[<ffffffff81195445>] put_page+0x55/0x60
[<ffffffff815d9f44>] e1000_clean_rx_ring+0x134/0x200
[<ffffffff815da055>] e1000_clean_all_rx_rings+0x45/0x60
[<ffffffff815df5e0>] e1000_down+0x1c0/0x1d0
[<ffffffff811e2260>] ? deactivate_slab+0x7f0/0x840
[<ffffffff815e21bc>] e1000_change_mtu+0xdc/0x170
[<ffffffff81647050>] dev_set_mtu+0xa0/0x140
[<ffffffff81664218>] do_setlink+0x218/0xac0
[<ffffffff814459e9>] ? nla_parse+0xb9/0x120
[<ffffffff816652d0>] rtnl_newlink+0x6d0/0x890
[<ffffffff8104f000>] ? kvm_clock_read+0x20/0x40
[<ffffffff810a2068>] ? sched_clock_cpu+0xa8/0x100
[<ffffffff81663802>] rtnetlink_rcv_msg+0x92/0x260
By setting the allocator to a dummy version, netpoll can't mess up our
rx buffers. The allocator is set back to a sane value in
e1000_configure_rx.
Fixes: edbbb3ca1077 ("e1000: implement jumbo receive with partial descriptors")
Signed-off-by: Sabrina Dubroca <[email protected]>
Tested-by: Aaron Brown <[email protected]>
Signed-off-by: Jeff Kirsher <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/net/ethernet/intel/e1000/e1000_main.c | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
--- a/drivers/net/ethernet/intel/e1000/e1000_main.c
+++ b/drivers/net/ethernet/intel/e1000/e1000_main.c
@@ -144,6 +144,11 @@ static bool e1000_clean_rx_irq(struct e1
static bool e1000_clean_jumbo_rx_irq(struct e1000_adapter *adapter,
struct e1000_rx_ring *rx_ring,
int *work_done, int work_to_do);
+static void e1000_alloc_dummy_rx_buffers(struct e1000_adapter *adapter,
+ struct e1000_rx_ring *rx_ring,
+ int cleaned_count)
+{
+}
static void e1000_alloc_rx_buffers(struct e1000_adapter *adapter,
struct e1000_rx_ring *rx_ring,
int cleaned_count);
@@ -3555,8 +3560,11 @@ static int e1000_change_mtu(struct net_d
msleep(1);
/* e1000_down has a dependency on max_frame_size */
hw->max_frame_size = max_frame;
- if (netif_running(netdev))
+ if (netif_running(netdev)) {
+ /* prevent buffers from being reallocated */
+ adapter->alloc_rx_buf = e1000_alloc_dummy_rx_buffers;
e1000_down(adapter);
+ }
/* NOTE: netdev_alloc_skb reserves 16 bytes, and typically NET_IP_ALIGN
* means we reserve 2 more, this pushes us to allocate from the next
3.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: mancha security <[email protected]>
commit 0b053c9518292705736329a8fe20ef4686ffc8e9 upstream.
OPTIMIZER_HIDE_VAR(), as defined when using gcc, is insufficient to
ensure protection from dead store optimization.
For the random driver and crypto drivers, calls are emitted ...
$ gdb vmlinux
(gdb) disassemble memzero_explicit
Dump of assembler code for function memzero_explicit:
0xffffffff813a18b0 <+0>: push %rbp
0xffffffff813a18b1 <+1>: mov %rsi,%rdx
0xffffffff813a18b4 <+4>: xor %esi,%esi
0xffffffff813a18b6 <+6>: mov %rsp,%rbp
0xffffffff813a18b9 <+9>: callq 0xffffffff813a7120 <memset>
0xffffffff813a18be <+14>: pop %rbp
0xffffffff813a18bf <+15>: retq
End of assembler dump.
(gdb) disassemble extract_entropy
[...]
0xffffffff814a5009 <+313>: mov %r12,%rdi
0xffffffff814a500c <+316>: mov $0xa,%esi
0xffffffff814a5011 <+321>: callq 0xffffffff813a18b0 <memzero_explicit>
0xffffffff814a5016 <+326>: mov -0x48(%rbp),%rax
[...]
... but in case in future we might use facilities such as LTO, then
OPTIMIZER_HIDE_VAR() is not sufficient to protect gcc from a possible
eviction of the memset(). We have to use a compiler barrier instead.
Minimal test example when we assume memzero_explicit() would *not* be
a call, but would have been *inlined* instead:
static inline void memzero_explicit(void *s, size_t count)
{
memset(s, 0, count);
<foo>
}
int main(void)
{
char buff[20];
snprintf(buff, sizeof(buff) - 1, "test");
printf("%s", buff);
memzero_explicit(buff, sizeof(buff));
return 0;
}
With <foo> := OPTIMIZER_HIDE_VAR():
(gdb) disassemble main
Dump of assembler code for function main:
[...]
0x0000000000400464 <+36>: callq 0x400410 <printf@plt>
0x0000000000400469 <+41>: xor %eax,%eax
0x000000000040046b <+43>: add $0x28,%rsp
0x000000000040046f <+47>: retq
End of assembler dump.
With <foo> := barrier():
(gdb) disassemble main
Dump of assembler code for function main:
[...]
0x0000000000400464 <+36>: callq 0x400410 <printf@plt>
0x0000000000400469 <+41>: movq $0x0,(%rsp)
0x0000000000400471 <+49>: movq $0x0,0x8(%rsp)
0x000000000040047a <+58>: movl $0x0,0x10(%rsp)
0x0000000000400482 <+66>: xor %eax,%eax
0x0000000000400484 <+68>: add $0x28,%rsp
0x0000000000400488 <+72>: retq
End of assembler dump.
As can be seen, movq, movq, movl are being emitted inlined
via memset().
Reference: http://thread.gmane.org/gmane.linux.kernel.cryptoapi/13764/
Fixes: d4c5efdb9777 ("random: add and use memzero_explicit() for clearing data")
Cc: Theodore Ts'o <[email protected]>
Signed-off-by: mancha security <[email protected]>
Signed-off-by: Daniel Borkmann <[email protected]>
Acked-by: Hannes Frederic Sowa <[email protected]>
Acked-by: Stephan Mueller <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
lib/string.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/lib/string.c
+++ b/lib/string.c
@@ -598,7 +598,7 @@ EXPORT_SYMBOL(memset);
void memzero_explicit(void *s, size_t count)
{
memset(s, 0, count);
- OPTIMIZER_HIDE_VAR(s);
+ barrier();
}
EXPORT_SYMBOL(memzero_explicit);
3.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Nicolas Iooss <[email protected]>
commit a3fa71c40f1853d0c27e8f5bc01a722a705d9682 upstream.
In struct wl18xx_acx_rx_rate_stat, rx_frames_per_rates field is an
array, not a number. This means WL18XX_DEBUGFS_FWSTATS_FILE can't be
used to display this field in debugfs (it would display a pointer, not
the actual data). Use WL18XX_DEBUGFS_FWSTATS_FILE_ARRAY instead.
This bug has been found by adding a __printf attribute to
wl1271_format_buffer. gcc complained about "format '%u' expects
argument of type 'unsigned int', but argument 5 has type 'u32 *'".
Fixes: c5d94169e818 ("wl18xx: use new fw stats structures")
Signed-off-by: Nicolas Iooss <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/net/wireless/ti/wl18xx/debugfs.c | 2 +-
drivers/net/wireless/ti/wlcore/debugfs.h | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
--- a/drivers/net/wireless/ti/wl18xx/debugfs.c
+++ b/drivers/net/wireless/ti/wl18xx/debugfs.c
@@ -136,7 +136,7 @@ WL18XX_DEBUGFS_FWSTATS_FILE(rx_filter, p
WL18XX_DEBUGFS_FWSTATS_FILE(rx_filter, accum_arp_pend_requests, "%u");
WL18XX_DEBUGFS_FWSTATS_FILE(rx_filter, max_arp_queue_dep, "%u");
-WL18XX_DEBUGFS_FWSTATS_FILE(rx_rate, rx_frames_per_rates, "%u");
+WL18XX_DEBUGFS_FWSTATS_FILE_ARRAY(rx_rate, rx_frames_per_rates, 50);
WL18XX_DEBUGFS_FWSTATS_FILE_ARRAY(aggr_size, tx_agg_vs_rate,
AGGR_STATS_TX_AGG*AGGR_STATS_TX_RATE);
--- a/drivers/net/wireless/ti/wlcore/debugfs.h
+++ b/drivers/net/wireless/ti/wlcore/debugfs.h
@@ -26,8 +26,8 @@
#include "wlcore.h"
-int wl1271_format_buffer(char __user *userbuf, size_t count,
- loff_t *ppos, char *fmt, ...);
+__printf(4, 5) int wl1271_format_buffer(char __user *userbuf, size_t count,
+ loff_t *ppos, char *fmt, ...);
int wl1271_debugfs_init(struct wl1271 *wl);
void wl1271_debugfs_exit(struct wl1271 *wl);
3.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Nishanth Menon <[email protected]>
commit f4831605f2dacd12730fe73961c77253cc2ea425 upstream.
time_init invokes timer64_init (which is __init annotation)
since all of these are invoked at init time, lets maintain
consistency by ensuring time_init is marked appropriately
as well.
This fixes the following warning with CONFIG_DEBUG_SECTION_MISMATCH=y
WARNING: vmlinux.o(.text+0x3bfc): Section mismatch in reference from the function time_init() to the function .init.text:timer64_init()
The function time_init() references
the function __init timer64_init().
This is often because time_init lacks a __init
annotation or the annotation of timer64_init is wrong.
Fixes: 546a39546c64 ("C6X: time management")
Signed-off-by: Nishanth Menon <[email protected]>
Signed-off-by: Mark Salter <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
arch/c6x/kernel/time.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/c6x/kernel/time.c
+++ b/arch/c6x/kernel/time.c
@@ -49,7 +49,7 @@ u64 sched_clock(void)
return (tsc * sched_clock_multiplier) >> SCHED_CLOCK_SHIFT;
}
-void time_init(void)
+void __init time_init(void)
{
u64 tmp = (u64)NSEC_PER_SEC << SCHED_CLOCK_SHIFT;
3.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dan Carpenter <[email protected]>
commit 13f6b191aaa11c7fd718d35a0c565f3c16bc1d99 upstream.
Using the indenting we can see the curly braces were obviously intended.
This is a static checker fix, but my guess is that we don't read enough
bytes, because we don't calculate "t_len" correctly.
Fixes: f1d82698029b ('memstick: use fully asynchronous request processing')
Signed-off-by: Dan Carpenter <[email protected]>
Cc: Alex Dubov <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/memstick/core/mspro_block.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/drivers/memstick/core/mspro_block.c
+++ b/drivers/memstick/core/mspro_block.c
@@ -758,7 +758,7 @@ static int mspro_block_complete_req(stru
if (error || (card->current_mrq.tpc == MSPRO_CMD_STOP)) {
if (msb->data_dir == READ) {
- for (cnt = 0; cnt < msb->current_seg; cnt++)
+ for (cnt = 0; cnt < msb->current_seg; cnt++) {
t_len += msb->req_sg[cnt].length
/ msb->page_size;
@@ -766,6 +766,7 @@ static int mspro_block_complete_req(stru
t_len += msb->current_page - 1;
t_len *= msb->page_size;
+ }
}
} else
t_len = blk_rq_bytes(msb->block_req);
On 05/02/2015 12:03 PM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 3.10.77 release.
> There are 65 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Mon May 4 19:00:04 UTC 2015.
> Anything received after that time might be too late.
>
Build results:
total: 127 pass: 113 fail: 14
Failed builds:
arm:allmodconfig
arm:multi_v7_defconfig
arm:bcm2835_defconfig
arm:orion5x_defconfig
arm:kirkwood_defconfig
arm:mvebu_defconfig
mips:allmodconfig
powerpc:allmodconfig
powerpc:ppc6xx_defconfig
s390:defconfig
s390:allmodconfig
sparc64:allmodconfig
x86_64:allyesconfig
x86_64:allmodconfig
Qemu test results:
total: 27 pass: 17 fail: 10
Failed tests:
arm:arm_versatile_defconfig
microblaze:microblaze_defconfig
powerpc:ppc_book3s_defconfig
powerpc:ppc_book3s_smp_defconfig
powerpc:ppc64_book3s_defconfig
powerpc:ppc64_book3s_smp_defconfig
x86:x86_pc_defconfig
x86:x86_pc_nosmp_defconfig
x86_64:x86_64_pc_defconfig
x86_64:x86_64_pc_nosmp_defconfig
Builds fail with:
kernel/trace/trace_functions_graph.c: In function 'graph_trace_open':
kernel/trace/trace_functions_graph.c:1397:2: error: implicit declaration of function 'alloc_percpu_gfp' [-Werror=implicit-function-declaration]
kernel/trace/trace_functions_graph.c:1397:36: error: expected expression before 'struct'
Bisect points to 'tracing: Handle ftrace_dump() atomic context in graph_trace_open()'.
Guenter
On 05/03/2015 12:49 PM, Guenter Roeck wrote:
> On 05/02/2015 12:03 PM, Greg Kroah-Hartman wrote:
>> This is the start of the stable review cycle for the 3.10.77 release.
>> There are 65 patches in this series, all will be posted as a response
>> to this one. If anyone has any issues with these being applied, please
>> let me know.
>>
>> Responses should be made by Mon May 4 19:00:04 UTC 2015.
>> Anything received after that time might be too late.
>>
>
> Build results:
> total: 127 pass: 113 fail: 14
> Failed builds:
> arm:allmodconfig
> arm:multi_v7_defconfig
> arm:bcm2835_defconfig
> arm:orion5x_defconfig
> arm:kirkwood_defconfig
> arm:mvebu_defconfig
> mips:allmodconfig
> powerpc:allmodconfig
> powerpc:ppc6xx_defconfig
> s390:defconfig
> s390:allmodconfig
> sparc64:allmodconfig
> x86_64:allyesconfig
> x86_64:allmodconfig
>
> Qemu test results:
> total: 27 pass: 17 fail: 10
> Failed tests:
> arm:arm_versatile_defconfig
> microblaze:microblaze_defconfig
> powerpc:ppc_book3s_defconfig
> powerpc:ppc_book3s_smp_defconfig
> powerpc:ppc64_book3s_defconfig
> powerpc:ppc64_book3s_smp_defconfig
> x86:x86_pc_defconfig
> x86:x86_pc_nosmp_defconfig
> x86_64:x86_64_pc_defconfig
> x86_64:x86_64_pc_nosmp_defconfig
>
> Builds fail with:
>
> kernel/trace/trace_functions_graph.c: In function 'graph_trace_open':
> kernel/trace/trace_functions_graph.c:1397:2: error: implicit declaration of function 'alloc_percpu_gfp' [-Werror=implicit-function-declaration]
> kernel/trace/trace_functions_graph.c:1397:36: error: expected expression before 'struct'
>
> Bisect points to 'tracing: Handle ftrace_dump() atomic context in graph_trace_open()'.
>
Also, for s390, similar to the error seen in 3.14:
arch/s390/kernel/suspend.c: In function 'pfn_is_nosave':
arch/s390/kernel/suspend.c:141:30: error: '_eshared' undeclared (first use in this function)
arch/s390/kernel/suspend.c:141:30: note: each undeclared identifier is reported only once for each function it appears in
arch/s390/kernel/suspend.c:142:28: error: '_stext' undeclared (first use in this function)
arch/s390/kernel/suspend.c:151:10: error: 'ipl_info' undeclared (first use in this function)
arch/s390/kernel/suspend.c:151:27: error: 'IPL_TYPE_NSS' undeclared (first use in this function)
Presumably for the same reason ('s390/hibernate: fix save and restore of kernel text section').
Guenter
On Sun, May 03, 2015 at 09:40:11PM -0700, Guenter Roeck wrote:
> On 05/03/2015 12:49 PM, Guenter Roeck wrote:
> >On 05/02/2015 12:03 PM, Greg Kroah-Hartman wrote:
> >>This is the start of the stable review cycle for the 3.10.77 release.
> >>There are 65 patches in this series, all will be posted as a response
> >>to this one. If anyone has any issues with these being applied, please
> >>let me know.
> >>
> >>Responses should be made by Mon May 4 19:00:04 UTC 2015.
> >>Anything received after that time might be too late.
> >>
> Also, for s390, similar to the error seen in 3.14:
>
> arch/s390/kernel/suspend.c: In function 'pfn_is_nosave':
> arch/s390/kernel/suspend.c:141:30: error: '_eshared' undeclared (first use in this function)
> arch/s390/kernel/suspend.c:141:30: note: each undeclared identifier is reported only once for each function it appears in
> arch/s390/kernel/suspend.c:142:28: error: '_stext' undeclared (first use in this function)
> arch/s390/kernel/suspend.c:151:10: error: 'ipl_info' undeclared (first use in this function)
> arch/s390/kernel/suspend.c:151:27: error: 'IPL_TYPE_NSS' undeclared (first use in this function)
>
> Presumably for the same reason ('s390/hibernate: fix save and restore of kernel text section').
Oh, crap.. for 3.10 two includes are missing within arch/s390/kernel/suspend.c:
<asm/ipl.h> and <asm/sections.h>
The corresponding commits are:
ipl.h:
77e844b9644026c11c5883144540155de39af767
"s390/hibernate: add early resume function"
(applies cleanly to 3.10, and was merged with 3.12)
sections.h
7f8998c7aef3ac9c5f3f2943e083dfa6302e90d0
"nosave: consolidate __nosave_{begin,end} in <asm/sections.h>"
This one is ugly, since it touches a lot of architectures and depends on a
lot of other unrelated patches. I'd say it's easier to add an extra patch that
simply adds the missing include, hm? (or add the include to the patch)
The same as true for the build failure on 3.14, unfortunately.
Does that make sense?
Guenther, thank you for reporting and testing!
On 05/04/2015, 10:09 AM, Heiko Carstens wrote:
> sections.h
> 7f8998c7aef3ac9c5f3f2943e083dfa6302e90d0
> "nosave: consolidate __nosave_{begin,end} in <asm/sections.h>"
I have added this to 3.12, except the arm part (does not have
hibernation yet) and s390 builds just fine for me now.
thanks,
--
js
suse labs
On Mon, May 04, 2015 at 11:54:52AM +0200, Jiri Slaby wrote:
> On 05/04/2015, 10:09 AM, Heiko Carstens wrote:
> > sections.h
> > 7f8998c7aef3ac9c5f3f2943e083dfa6302e90d0
> > "nosave: consolidate __nosave_{begin,end} in <asm/sections.h>"
>
> I have added this to 3.12, except the arm part (does not have
> hibernation yet) and s390 builds just fine for me now.
Ok, then it is easier than I thought. Thanks!
On 05/02/2015 01:03 PM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 3.10.77 release.
> There are 65 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Mon May 4 19:00:04 UTC 2015.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.10.77-rc1.gz
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
Compiled, but failed to boot on my test system. I am starting bisect
and will report back with results.
-- Shuah
--
Shuah Khan
Sr. Linux Kernel Developer
Open Source Innovation Group
Samsung Research America (Silicon Valley)
[email protected] | (970) 217-8978
On Mon, May 04, 2015 at 10:09:14AM +0200, Heiko Carstens wrote:
> On Sun, May 03, 2015 at 09:40:11PM -0700, Guenter Roeck wrote:
> > On 05/03/2015 12:49 PM, Guenter Roeck wrote:
> > >On 05/02/2015 12:03 PM, Greg Kroah-Hartman wrote:
> > >>This is the start of the stable review cycle for the 3.10.77 release.
> > >>There are 65 patches in this series, all will be posted as a response
> > >>to this one. If anyone has any issues with these being applied, please
> > >>let me know.
> > >>
> > >>Responses should be made by Mon May 4 19:00:04 UTC 2015.
> > >>Anything received after that time might be too late.
> > >>
> > Also, for s390, similar to the error seen in 3.14:
> >
> > arch/s390/kernel/suspend.c: In function 'pfn_is_nosave':
> > arch/s390/kernel/suspend.c:141:30: error: '_eshared' undeclared (first use in this function)
> > arch/s390/kernel/suspend.c:141:30: note: each undeclared identifier is reported only once for each function it appears in
> > arch/s390/kernel/suspend.c:142:28: error: '_stext' undeclared (first use in this function)
> > arch/s390/kernel/suspend.c:151:10: error: 'ipl_info' undeclared (first use in this function)
> > arch/s390/kernel/suspend.c:151:27: error: 'IPL_TYPE_NSS' undeclared (first use in this function)
> >
> > Presumably for the same reason ('s390/hibernate: fix save and restore of kernel text section').
>
> Oh, crap.. for 3.10 two includes are missing within arch/s390/kernel/suspend.c:
> <asm/ipl.h> and <asm/sections.h>
>
> The corresponding commits are:
> ipl.h:
> 77e844b9644026c11c5883144540155de39af767
> "s390/hibernate: add early resume function"
> (applies cleanly to 3.10, and was merged with 3.12)
>
> sections.h
> 7f8998c7aef3ac9c5f3f2943e083dfa6302e90d0
> "nosave: consolidate __nosave_{begin,end} in <asm/sections.h>"
>
> This one is ugly, since it touches a lot of architectures and depends on a
> lot of other unrelated patches. I'd say it's easier to add an extra patch that
> simply adds the missing include, hm? (or add the include to the patch)
> The same as true for the build failure on 3.14, unfortunately.
>
> Does that make sense?
>
Adding the missing include file(s) to the patch seems to be an easier solution
and would be a valid backport, at least in my opinion.
I did a quick test. The s390:defconfig build passes after adding commit
77e844b9644026c11c5883144540155de39af767 and adding "#include <asm/sections.h>"
to the hibernate patch.
s390:allmodconfig still fails to build for other reasons (because
devm_request_threaded_irq and irq_create_mapping are not supported
for s390 in 3.10), but that is a different issue.
Guenter
On Mon, May 04, 2015 at 12:40:13PM +0200, Heiko Carstens wrote:
> On Mon, May 04, 2015 at 11:54:52AM +0200, Jiri Slaby wrote:
> > On 05/04/2015, 10:09 AM, Heiko Carstens wrote:
> > > sections.h
> > > 7f8998c7aef3ac9c5f3f2943e083dfa6302e90d0
> > > "nosave: consolidate __nosave_{begin,end} in <asm/sections.h>"
> >
> > I have added this to 3.12, except the arm part (does not have
> > hibernation yet) and s390 builds just fine for me now.
>
> Ok, then it is easier than I thought. Thanks!
Ok, I've done that here for 3.10 and 3.14 as well, thanks.
greg k-h
On Sun, May 03, 2015 at 12:49:48PM -0700, Guenter Roeck wrote:
> On 05/02/2015 12:03 PM, Greg Kroah-Hartman wrote:
> >This is the start of the stable review cycle for the 3.10.77 release.
> >There are 65 patches in this series, all will be posted as a response
> >to this one. If anyone has any issues with these being applied, please
> >let me know.
> >
> >Responses should be made by Mon May 4 19:00:04 UTC 2015.
> >Anything received after that time might be too late.
> >
>
> Build results:
> total: 127 pass: 113 fail: 14
> Failed builds:
> arm:allmodconfig
> arm:multi_v7_defconfig
> arm:bcm2835_defconfig
> arm:orion5x_defconfig
> arm:kirkwood_defconfig
> arm:mvebu_defconfig
> mips:allmodconfig
> powerpc:allmodconfig
> powerpc:ppc6xx_defconfig
> s390:defconfig
> s390:allmodconfig
> sparc64:allmodconfig
> x86_64:allyesconfig
> x86_64:allmodconfig
>
> Qemu test results:
> total: 27 pass: 17 fail: 10
> Failed tests:
> arm:arm_versatile_defconfig
> microblaze:microblaze_defconfig
> powerpc:ppc_book3s_defconfig
> powerpc:ppc_book3s_smp_defconfig
> powerpc:ppc64_book3s_defconfig
> powerpc:ppc64_book3s_smp_defconfig
> x86:x86_pc_defconfig
> x86:x86_pc_nosmp_defconfig
> x86_64:x86_64_pc_defconfig
> x86_64:x86_64_pc_nosmp_defconfig
>
> Builds fail with:
>
> kernel/trace/trace_functions_graph.c: In function 'graph_trace_open':
> kernel/trace/trace_functions_graph.c:1397:2: error: implicit declaration of function 'alloc_percpu_gfp' [-Werror=implicit-function-declaration]
> kernel/trace/trace_functions_graph.c:1397:36: error: expected expression before 'struct'
>
> Bisect points to 'tracing: Handle ftrace_dump() atomic context in graph_trace_open()'.
Oops, that wasn't supposed to be in 3.10, thanks, now removed.
greg k-h
On Mon, May 04, 2015 at 10:16:46AM -0600, Shuah Khan wrote:
> On 05/02/2015 01:03 PM, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 3.10.77 release.
> > There are 65 patches in this series, all will be posted as a response
> > to this one. If anyone has any issues with these being applied, please
> > let me know.
> >
> > Responses should be made by Mon May 4 19:00:04 UTC 2015.
> > Anything received after that time might be too late.
> >
> > The whole patch series can be found in one patch at:
> > kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.10.77-rc1.gz
> > and the diffstat can be found below.
> >
> > thanks,
> >
> > greg k-h
>
> Compiled, but failed to boot on my test system. I am starting bisect
> and will report back with results.
Ick, that's not good, please let me know what you find.
thanks,
greg k-h
On 05/02/2015 01:03 PM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 3.10.77 release.
> There are 65 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Mon May 4 19:00:04 UTC 2015.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.10.77-rc1.gz
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
Greg,
Could you please double-check the above commit in your patch.
I see
arch/x86/kernel/process.c
I don't see arch/x86/include/asm/mwait.h in
patch-3.10.77-rc1.gz patch.
Missing from the diffstat below.
I am comparing it with
http://www.spinics.net/lists/stable-commits/msg43642.html
I still don't know why my test system doesn't boot with
patch-3.10.77-rc1
thanks,
-- Shuah
>
> Len Brown <[email protected]>
> sched/idle/x86: Restore mwait_idle() to fix boot hangs, to improve power savings and to improve performance
>
>
> -------------
>
> Diffstat:
>
> Makefile | 4 +-
> arch/arm/include/asm/elf.h | 2 +-
> arch/arm/mach-s3c64xx/crag6410.h | 1 +
> arch/arm/mach-s3c64xx/mach-crag6410.c | 1 +
> arch/arm64/include/asm/timex.h | 6 +-
> arch/arm64/kernel/time.c | 6 --
> arch/c6x/kernel/time.c | 2 +-
> arch/mips/power/hibernate.S | 3 +-
> arch/powerpc/perf/callchain.c | 2 +-
> arch/s390/kernel/suspend.c | 4 ++
> arch/s390/kvm/priv.c | 1 +
> arch/x86/kernel/process.c | 49 ++++++++++++++++
> arch/xtensa/Kconfig | 30 ++++++++++
> arch/xtensa/include/uapi/asm/unistd.h | 2 +-
> arch/xtensa/platforms/xtfpga/Makefile | 3 +-
> .../platforms/xtfpga/include/platform/hardware.h | 3 -
> .../xtensa/platforms/xtfpga/include/platform/lcd.h | 15 +++++
> arch/xtensa/platforms/xtfpga/lcd.c | 55 +++++++++++-------
> drivers/gpio/gpio-mvebu.c | 24 +++++---
> drivers/gpu/drm/i915/i915_reg.h | 1 +
> drivers/gpu/drm/i915/intel_i2c.c | 66 ++++++++++++++++++----
> drivers/gpu/drm/radeon/atombios_crtc.c | 8 ++-
> drivers/hv/channel.c | 7 ++-
> drivers/i2c/i2c-core.c | 3 +
> drivers/infiniband/core/umem.c | 7 ++-
> drivers/infiniband/hw/mlx4/qp.c | 3 +-
> drivers/input/mouse/elantech.c | 22 ++++++++
> drivers/input/mouse/elantech.h | 1 +
> drivers/media/usb/stk1160/stk1160-v4l.c | 17 +++++-
> drivers/memstick/core/mspro_block.c | 3 +-
> drivers/mtd/ubi/attach.c | 2 +-
> drivers/mtd/ubi/cdev.c | 2 +-
> drivers/mtd/ubi/eba.c | 3 +-
> drivers/mtd/ubi/wl.c | 2 +-
> drivers/net/ethernet/intel/e1000/e1000_main.c | 10 +++-
> drivers/net/wireless/rtlwifi/rtl8192cu/sw.c | 2 +
> drivers/net/wireless/ti/wl18xx/debugfs.c | 2 +-
> drivers/net/wireless/ti/wlcore/debugfs.h | 4 +-
> drivers/parport/Kconfig | 4 +-
> drivers/power/lp8788-charger.c | 4 +-
> drivers/scsi/mvsas/mv_sas.c | 5 +-
> drivers/scsi/storvsc_drv.c | 15 ++---
> drivers/spi/spidev.c | 5 +-
> drivers/usb/class/cdc-wdm.c | 12 ++--
> drivers/usb/core/hub.c | 4 +-
> drivers/usb/gadget/composite.c | 2 +-
> drivers/usb/host/isp116x-hcd.c | 2 +-
> drivers/usb/host/r8a66597-hcd.c | 2 +-
> drivers/usb/host/sl811-hcd.c | 2 +-
> drivers/usb/host/xhci-ring.c | 2 +-
> drivers/usb/phy/phy.c | 4 +-
> drivers/video/console/Kconfig | 5 +-
> fs/binfmt_elf.c | 9 ++-
> fs/btrfs/extent-tree.c | 5 +-
> fs/btrfs/ioctl.c | 5 ++
> fs/ext4/namei.c | 20 ++++---
> fs/namei.c | 6 +-
> include/acpi/actypes.h | 20 +++++++
> include/acpi/platform/acenv.h | 1 +
> include/linux/usb.h | 26 +++++++++
> kernel/ptrace.c | 20 +++++++
> kernel/softirq.c | 6 +-
> kernel/trace/ring_buffer.c | 11 ++--
> kernel/trace/trace_functions_graph.c | 8 ++-
> lib/string.c | 2 +-
> net/ipv4/ip_forward.c | 3 +
> net/ipv4/tcp_output.c | 64 ++++++++++++++-------
> sound/pci/emu10k1/emuproc.c | 12 ----
> tools/power/x86/turbostat/Makefile | 6 +-
> virt/kvm/kvm_main.c | 4 +-
> 70 files changed, 509 insertions(+), 165 deletions(-)
>
>
--
Shuah Khan
Sr. Linux Kernel Developer
Open Source Innovation Group
Samsung Research America (Silicon Valley)
[email protected] | (970) 217-8978
On 05/04/2015 03:13 PM, Shuah Khan wrote:
> On 05/02/2015 01:03 PM, Greg Kroah-Hartman wrote:
>> This is the start of the stable review cycle for the 3.10.77 release.
>> There are 65 patches in this series, all will be posted as a response
>> to this one. If anyone has any issues with these being applied, please
>> let me know.
>>
>> Responses should be made by Mon May 4 19:00:04 UTC 2015.
>> Anything received after that time might be too late.
>>
>> The whole patch series can be found in one patch at:
>> kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.10.77-rc1.gz
>> and the diffstat can be found below.
>>
>> thanks,
>>
>> greg k-h
>
> Greg,
>
> Could you please double-check the above commit in your patch.
> I see
>
> arch/x86/kernel/process.c
>
> I don't see arch/x86/include/asm/mwait.h in
>
> patch-3.10.77-rc1.gz patch.
> Missing from the diffstat below.
>
> I am comparing it with
> http://www.spinics.net/lists/stable-commits/msg43642.html
>
> I still don't know why my test system doesn't boot with
>
My qemu test image doesn't even compile :-(
Guenter
On 05/03/2015 09:40 PM, Guenter Roeck wrote:
> On 05/03/2015 12:49 PM, Guenter Roeck wrote:
>> On 05/02/2015 12:03 PM, Greg Kroah-Hartman wrote:
>>> This is the start of the stable review cycle for the 3.10.77 release.
>>> There are 65 patches in this series, all will be posted as a response
>>> to this one. If anyone has any issues with these being applied, please
>>> let me know.
>>>
>>> Responses should be made by Mon May 4 19:00:04 UTC 2015.
>>> Anything received after that time might be too late.
>>>
>>
>> Build results:
>> total: 127 pass: 113 fail: 14
>> Failed builds:
>> arm:allmodconfig
>> arm:multi_v7_defconfig
>> arm:bcm2835_defconfig
>> arm:orion5x_defconfig
>> arm:kirkwood_defconfig
>> arm:mvebu_defconfig
>> mips:allmodconfig
>> powerpc:allmodconfig
>> powerpc:ppc6xx_defconfig
>> s390:defconfig
>> s390:allmodconfig
>> sparc64:allmodconfig
>> x86_64:allyesconfig
>> x86_64:allmodconfig
>>
>> Qemu test results:
>> total: 27 pass: 17 fail: 10
>> Failed tests:
>> arm:arm_versatile_defconfig
>> microblaze:microblaze_defconfig
>> powerpc:ppc_book3s_defconfig
>> powerpc:ppc_book3s_smp_defconfig
>> powerpc:ppc64_book3s_defconfig
>> powerpc:ppc64_book3s_smp_defconfig
>> x86:x86_pc_defconfig
>> x86:x86_pc_nosmp_defconfig
>> x86_64:x86_64_pc_defconfig
>> x86_64:x86_64_pc_nosmp_defconfig
>>
>> Builds fail with:
>>
>> kernel/trace/trace_functions_graph.c: In function 'graph_trace_open':
>> kernel/trace/trace_functions_graph.c:1397:2: error: implicit declaration of function 'alloc_percpu_gfp' [-Werror=implicit-function-declaration]
>> kernel/trace/trace_functions_graph.c:1397:36: error: expected expression before 'struct'
>>
>> Bisect points to 'tracing: Handle ftrace_dump() atomic context in graph_trace_open()'.
>>
>
> Also, for s390, similar to the error seen in 3.14:
>
> arch/s390/kernel/suspend.c: In function 'pfn_is_nosave':
> arch/s390/kernel/suspend.c:141:30: error: '_eshared' undeclared (first use in this function)
> arch/s390/kernel/suspend.c:141:30: note: each undeclared identifier is reported only once for each function it appears in
> arch/s390/kernel/suspend.c:142:28: error: '_stext' undeclared (first use in this function)
> arch/s390/kernel/suspend.c:151:10: error: 'ipl_info' undeclared (first use in this function)
> arch/s390/kernel/suspend.c:151:27: error: 'IPL_TYPE_NSS' undeclared (first use in this function)
>
> Presumably for the same reason ('s390/hibernate: fix save and restore of kernel text section').
>
> Guenter
>
Much better, but s390 images still fail to build:
arch/s390/kernel/suspend.c: In function 'pfn_is_nosave':
arch/s390/kernel/suspend.c:147:10: error: 'ipl_info' undeclared (first use in this function)
arch/s390/kernel/suspend.c:147:10: note: each undeclared identifier is reported only once for each function it appears in
arch/s390/kernel/suspend.c:147:27: error: 'IPL_TYPE_NSS' undeclared (first use in this function)
make[2]: *** [arch/s390/kernel/suspend.o] Error 1
The problem can be fixed by adding "#include <asm/ipl.h>" to
arch/s390/kernel/suspend.c in "s390/hibernate: fix save and restore
of kernel text section" or possibly in "nosave: consolidate
__nosave_{begin,end} in <asm/sections.h>". Or, of course,
in a separate patch, such as the one attached.
Guenter
On Mon, May 04, 2015 at 04:13:15PM -0600, Shuah Khan wrote:
> On 05/02/2015 01:03 PM, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 3.10.77 release.
> > There are 65 patches in this series, all will be posted as a response
> > to this one. If anyone has any issues with these being applied, please
> > let me know.
> >
> > Responses should be made by Mon May 4 19:00:04 UTC 2015.
> > Anything received after that time might be too late.
> >
> > The whole patch series can be found in one patch at:
> > kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.10.77-rc1.gz
> > and the diffstat can be found below.
> >
> > thanks,
> >
> > greg k-h
>
> Greg,
>
> Could you please double-check the above commit in your patch.
> I see
>
> arch/x86/kernel/process.c
>
> I don't see arch/x86/include/asm/mwait.h in
>
> patch-3.10.77-rc1.gz patch.
> Missing from the diffstat below.
>
> I am comparing it with
> http://www.spinics.net/lists/stable-commits/msg43642.html
Ok, that's odd, I've now deleted this patch, I don't know what happened
here, sorry about that.
Let me do a -rc2 and see if that solves your issues for you.
thanks,
greg k-h
On Mon, May 04, 2015 at 09:42:41PM -0700, Guenter Roeck wrote:
> On 05/03/2015 09:40 PM, Guenter Roeck wrote:
> >On 05/03/2015 12:49 PM, Guenter Roeck wrote:
> >>On 05/02/2015 12:03 PM, Greg Kroah-Hartman wrote:
> >>>This is the start of the stable review cycle for the 3.10.77 release.
> >>>There are 65 patches in this series, all will be posted as a response
> >>>to this one. If anyone has any issues with these being applied, please
> >>>let me know.
> >>>
> >>>Responses should be made by Mon May 4 19:00:04 UTC 2015.
> >>>Anything received after that time might be too late.
> >>>
> >>
> >>Build results:
> >> total: 127 pass: 113 fail: 14
> >>Failed builds:
> >> arm:allmodconfig
> >> arm:multi_v7_defconfig
> >> arm:bcm2835_defconfig
> >> arm:orion5x_defconfig
> >> arm:kirkwood_defconfig
> >> arm:mvebu_defconfig
> >> mips:allmodconfig
> >> powerpc:allmodconfig
> >> powerpc:ppc6xx_defconfig
> >> s390:defconfig
> >> s390:allmodconfig
> >> sparc64:allmodconfig
> >> x86_64:allyesconfig
> >> x86_64:allmodconfig
> >>
> >>Qemu test results:
> >> total: 27 pass: 17 fail: 10
> >>Failed tests:
> >> arm:arm_versatile_defconfig
> >> microblaze:microblaze_defconfig
> >> powerpc:ppc_book3s_defconfig
> >> powerpc:ppc_book3s_smp_defconfig
> >> powerpc:ppc64_book3s_defconfig
> >> powerpc:ppc64_book3s_smp_defconfig
> >> x86:x86_pc_defconfig
> >> x86:x86_pc_nosmp_defconfig
> >> x86_64:x86_64_pc_defconfig
> >> x86_64:x86_64_pc_nosmp_defconfig
> >>
> >>Builds fail with:
> >>
> >>kernel/trace/trace_functions_graph.c: In function 'graph_trace_open':
> >>kernel/trace/trace_functions_graph.c:1397:2: error: implicit declaration of function 'alloc_percpu_gfp' [-Werror=implicit-function-declaration]
> >>kernel/trace/trace_functions_graph.c:1397:36: error: expected expression before 'struct'
> >>
> >>Bisect points to 'tracing: Handle ftrace_dump() atomic context in graph_trace_open()'.
> >>
> >
> >Also, for s390, similar to the error seen in 3.14:
> >
> >arch/s390/kernel/suspend.c: In function 'pfn_is_nosave':
> >arch/s390/kernel/suspend.c:141:30: error: '_eshared' undeclared (first use in this function)
> >arch/s390/kernel/suspend.c:141:30: note: each undeclared identifier is reported only once for each function it appears in
> >arch/s390/kernel/suspend.c:142:28: error: '_stext' undeclared (first use in this function)
> >arch/s390/kernel/suspend.c:151:10: error: 'ipl_info' undeclared (first use in this function)
> >arch/s390/kernel/suspend.c:151:27: error: 'IPL_TYPE_NSS' undeclared (first use in this function)
> >
> >Presumably for the same reason ('s390/hibernate: fix save and restore of kernel text section').
> >
> >Guenter
> >
> Much better, but s390 images still fail to build:
>
> arch/s390/kernel/suspend.c: In function 'pfn_is_nosave':
> arch/s390/kernel/suspend.c:147:10: error: 'ipl_info' undeclared (first use in this function)
> arch/s390/kernel/suspend.c:147:10: note: each undeclared identifier is reported only once for each function it appears in
> arch/s390/kernel/suspend.c:147:27: error: 'IPL_TYPE_NSS' undeclared (first use in this function)
> make[2]: *** [arch/s390/kernel/suspend.o] Error 1
>
> The problem can be fixed by adding "#include <asm/ipl.h>" to
> arch/s390/kernel/suspend.c in "s390/hibernate: fix save and restore
> of kernel text section" or possibly in "nosave: consolidate
> __nosave_{begin,end} in <asm/sections.h>". Or, of course,
> in a separate patch, such as the one attached.
>
> Guenter
>
>
> >From 5eca5cfdb114a2ccff8bf25c2273104eb8946b55 Mon Sep 17 00:00:00 2001
> From: Guenter Roeck <[email protected]>
> Date: Mon, 4 May 2015 21:40:06 -0700
> Subject: [PATCH v3.10] s390: Fix build error
>
> s390 images fail to build in 3.10 with
>
> arch/s390/kernel/suspend.c: In function 'pfn_is_nosave':
> arch/s390/kernel/suspend.c:147:10: error: 'ipl_info' undeclared
> arch/s390/kernel/suspend.c:147:27: error: 'IPL_TYPE_NSS' undeclared
>
> due to a missing include file.
>
> Signed-off-by: Guenter Roeck <[email protected]>
> ---
> arch/s390/kernel/suspend.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/s390/kernel/suspend.c b/arch/s390/kernel/suspend.c
> index a3ab6798ce68..58cbb75e89e9 100644
> --- a/arch/s390/kernel/suspend.c
> +++ b/arch/s390/kernel/suspend.c
> @@ -11,6 +11,7 @@
> #include <linux/mm.h>
> #include <asm/sections.h>
> #include <asm/ctl_reg.h>
> +#include <asm/ipl.h>
>
> /*
> * The restore of the saved pages in an hibernation image will set
> --
> 2.1.0
>
Thanks, now applied.
greg k-h
On Sat, May 02, 2015 at 09:03:30PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 3.10.77 release.
> There are 65 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Mon May 4 19:00:04 UTC 2015.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.10.77-rc1.gz
> and the diffstat can be found below.
Ok, due to all of the issues in the -rc1 release, there's a -rc2 out now
that hopefully will boot for people now :)
kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.10.77-rc2.gz
thanks,
greg k-h
On 05/05/2015 03:05 PM, Greg Kroah-Hartman wrote:
> On Sat, May 02, 2015 at 09:03:30PM +0200, Greg Kroah-Hartman wrote:
>> This is the start of the stable review cycle for the 3.10.77 release.
>> There are 65 patches in this series, all will be posted as a response
>> to this one. If anyone has any issues with these being applied, please
>> let me know.
>>
>> Responses should be made by Mon May 4 19:00:04 UTC 2015.
>> Anything received after that time might be too late.
>>
>> The whole patch series can be found in one patch at:
>> kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.10.77-rc1.gz
>> and the diffstat can be found below.
>
> Ok, due to all of the issues in the -rc1 release, there's a -rc2 out now
> that hopefully will boot for people now :)
>
> kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.10.77-rc2.gz
>
Build results:
total: 127 pass: 126 fail: 1
Failed builds:
s390:allmodconfig
Qemu test results:
total: 27 pass: 27 fail: 0
Results are as expected. s390:allmodconfig fails because s390 does not
support HAVE_GENERIC_HARDIRQS in v3.10, and that would be too difficult
to fix (at least for me).
Details are available at http://server.roeck-us.net:8010/builders.
Guenter
On 05/05/2015 04:05 PM, Greg Kroah-Hartman wrote:
> On Sat, May 02, 2015 at 09:03:30PM +0200, Greg Kroah-Hartman wrote:
>> This is the start of the stable review cycle for the 3.10.77 release.
>> There are 65 patches in this series, all will be posted as a response
>> to this one. If anyone has any issues with these being applied, please
>> let me know.
>>
>> Responses should be made by Mon May 4 19:00:04 UTC 2015.
>> Anything received after that time might be too late.
>>
>> The whole patch series can be found in one patch at:
>> kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.10.77-rc1.gz
>> and the diffstat can be found below.
>
> Ok, due to all of the issues in the -rc1 release, there's a -rc2 out now
> that hopefully will boot for people now :)
>
> kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.10.77-rc2.gz
>
> thanks,
>
> greg k-h
>
rc2 is good. Compiled and booted. No demsg regressions.
-- Shuah
--
Shuah Khan
Sr. Linux Kernel Developer
Open Source Innovation Group
Samsung Research America (Silicon Valley)
[email protected] | (970) 217-8978