Neal Cardwell [Sat, 28 Jan 2012 17:29:46 +0000 (17:29 +0000)]
tcp: fix tcp_trim_head() to adjust segment count with skb MSS
[ Upstream commit
5b35e1e6e9ca651e6b291c96d1106043c9af314a ]
This commit fixes tcp_trim_head() to recalculate the number of
segments in the skb with the skb's existing MSS, so trimming the head
causes the skb segment count to be monotonically non-increasing - it
should stay the same or go down, but not increase.
Previously tcp_trim_head() used the current MSS of the connection. But
if there was a decrease in MSS between original transmission and ACK
(e.g. due to PMTUD), this could cause tcp_trim_head() to
counter-intuitively increase the segment count when trimming bytes off
the head of an skb. This violated assumptions in tcp_tso_acked() that
tcp_trim_head() only decreases the packet count, so that packets_acked
in tcp_tso_acked() could underflow, leading tcp_clean_rtx_queue() to
pass u32 pkts_acked values as large as 0xffffffff to
ca_ops->pkts_acked().
As an aside, if tcp_trim_head() had really wanted the skb to reflect
the current MSS, it should have called tcp_set_skb_tso_segs()
unconditionally, since a decrease in MSS would mean that a
single-packet skb should now be sliced into multiple segments.
Signed-off-by: Neal Cardwell <ncardwell@google.com>
Acked-by: Nandita Dukkipati <nanditad@google.com>
Acked-by: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
David S. Miller [Tue, 24 Jan 2012 22:03:44 +0000 (17:03 -0500)]
rds: Make rds_sock_lock BH rather than IRQ safe.
[ Upstream commit
efc3dbc37412c027e363736b4f4c74ee5e8ecffc ]
rds_sock_info() triggers locking warnings because we try to perform a
local_bh_enable() (via sock_i_ino()) while hardware interrupts are
disabled (via taking rds_sock_lock).
There is no reason for rds_sock_lock to be a hardware IRQ disabling
lock, none of these access paths run in hardware interrupt context.
Therefore making it a BH disabling lock is safe and sufficient to
fix this bug.
Reported-by: Kumar Sanghvi <kumaras@chelsio.com>
Reported-by: Josh Boyer <jwboyer@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Eric Dumazet [Wed, 18 Jan 2012 07:21:42 +0000 (07:21 +0000)]
net: bpf_jit: fix divide by 0 generation
[ Upstream commit
d00a9dd21bdf7908b70866794c8313ee8a5abd5c ]
Several problems fixed in this patch :
1) Target of the conditional jump in case a divide by 0 is performed
by a bpf is wrong.
2) Must 'generate' the full function prologue/epilogue at pass=0,
or else we can stop too early in pass=1 if the proglen doesnt change.
(if the increase of prologue/epilogue equals decrease of all
instructions length because some jumps are converted to near jumps)
3) Change the wrong length detection at the end of code generation to
issue a more explicit message, no need for a full stack trace.
Reported-by: Phil Oester <kernel@linuxace.com>
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
James Chapman [Wed, 25 Jan 2012 02:39:05 +0000 (02:39 +0000)]
l2tp: l2tp_ip - fix possible oops on packet receive
[ Upstream commit
68315801dbf3ab2001679fd2074c9dc5dcf87dfa ]
When a packet is received on an L2TP IP socket (L2TPv3 IP link
encapsulation), the l2tpip socket's backlog_rcv function calls
xfrm4_policy_check(). This is not necessary, since it was called
before the skb was added to the backlog. With CONFIG_NET_NS enabled,
xfrm4_policy_check() will oops if skb->dev is null, so this trivial
patch removes the call.
This bug has always been present, but only when CONFIG_NET_NS is
enabled does it cause problems. Most users are probably using UDP
encapsulation for L2TP, hence the problem has only recently
surfaced.
EIP: 0060:[<
c12bb62b>] EFLAGS:
00210246 CPU: 0
EIP is at l2tp_ip_recvmsg+0xd4/0x2a7
EAX:
00000001 EBX:
d77b5180 ECX:
00000000 EDX:
00200246
ESI:
00000000 EDI:
d63cbd30 EBP:
d63cbd18 ESP:
d63cbcf4
DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
Call Trace:
[<
c1218568>] sock_common_recvmsg+0x31/0x46
[<
c1215c92>] __sock_recvmsg_nosec+0x45/0x4d
[<
c12163a1>] __sock_recvmsg+0x31/0x3b
[<
c1216828>] sock_recvmsg+0x96/0xab
[<
c10b2693>] ? might_fault+0x47/0x81
[<
c10b2693>] ? might_fault+0x47/0x81
[<
c1167fd0>] ? _copy_from_user+0x31/0x115
[<
c121e8c8>] ? copy_from_user+0x8/0xa
[<
c121ebd6>] ? verify_iovec+0x3e/0x78
[<
c1216604>] __sys_recvmsg+0x10a/0x1aa
[<
c1216792>] ? sock_recvmsg+0x0/0xab
[<
c105a99b>] ? __lock_acquire+0xbdf/0xbee
[<
c12d5a99>] ? do_page_fault+0x193/0x375
[<
c10d1200>] ? fcheck_files+0x9b/0xca
[<
c10d1259>] ? fget_light+0x2a/0x9c
[<
c1216bbb>] sys_recvmsg+0x2b/0x43
[<
c1218145>] sys_socketcall+0x16d/0x1a5
[<
c11679f0>] ? trace_hardirqs_on_thunk+0xc/0x10
[<
c100305f>] sysenter_do_call+0x12/0x38
Code: c6 05 8c ea a8 c1 01 e8 0c d4 d9 ff 85 f6 74 07 3e ff 86 80 00 00 00 b9 17 b6 2b c1 ba 01 00 00 00 b8 78 ed 48 c1 e8 23 f6 d9 ff <ff> 76 0c 68 28 e3 30 c1 68 2d 44 41 c1 e8 89 57 01 00 83 c4 0c
Signed-off-by: James Chapman <jchapman@katalix.com>
Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jiri Bohac [Wed, 18 Jan 2012 12:24:54 +0000 (12:24 +0000)]
bonding: fix enslaving in alb mode when link down
[ Upstream commit
b924551bed09f61b64f21bffe241afc5526b091a ]
bond_alb_init_slave() is called from bond_enslave() and sets the slave's MAC
address. This is done differently for TLB and ALB modes.
bond->alb_info.rlb_enabled is used to discriminate between the two modes but
this flag may be uninitialized if the slave is being enslaved prior to calling
bond_open() -> bond_alb_initialize() on the master.
It turns out all the callers of alb_set_slave_mac_addr() pass
bond->alb_info.rlb_enabled as the hw parameter.
This patch cleans up the unnecessary parameter of alb_set_slave_mac_addr() and
makes the function decide based on the bonding mode instead, which fixes the
above problem.
Reported-by: Narendra K <Narendra_K@Dell.com>
Signed-off-by: Jiri Bohac <jbohac@suse.cz>
Signed-off-by: Jay Vosburgh <fubar@us.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Eric W. Biederman [Thu, 26 Jan 2012 14:04:53 +0000 (14:04 +0000)]
net caif: Register properly as a pernet subsystem.
[ Upstream commit
8a8ee9aff6c3077dd9c2c7a77478e8ed362b96c6 ]
caif is a subsystem and as such it needs to register with
register_pernet_subsys instead of register_pernet_device.
Among other problems using register_pernet_device was resulting in
net_generic being called before the caif_net structure was allocated.
Which has been causing net_generic to fail with either BUG_ON's or by
return NULL pointers.
A more ugly problem that could be caused is packets in flight why the
subsystem is shutting down.
To remove confusion also remove the cruft cause by inappropriately
trying to fix this bug.
With the aid of the previous patch I have tested this patch and
confirmed that using register_pernet_subsys makes the failure go away as
it should.
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
Acked-by: Sjur Brændeland <sjur.brandeland@stericsson.com>
Tested-by: Sasha Levin <levinsasha928@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Eric W. Biederman [Thu, 26 Jan 2012 14:02:55 +0000 (14:02 +0000)]
netns: Fail conspicously if someone uses net_generic at an inappropriate time.
[ Upstream commit
5ee4433efe99b9f39f6eff5052a177bbcfe72cea ]
By definition net_generic should never be called when it can return
NULL. Fail conspicously with a BUG_ON to make it clear when people mess
up that a NULL return should never happen.
Recently there was a bug in the CAIF subsystem where it was registered
with register_pernet_device instead of register_pernet_subsys. It was
erroneously concluded that net_generic could validly return NULL and
that net_assign_generic was buggy (when it was just inefficient).
Hopefully this BUG_ON will prevent people to coming to similar erroneous
conclusions in the futrue.
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
Tested-by: Sasha Levin <levinsasha928@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Eric Dumazet [Thu, 26 Jan 2012 00:41:38 +0000 (00:41 +0000)]
netns: fix net_alloc_generic()
[ Upstream commit
073862ba5d249c20bd5c49fc6d904ff0e1f6a672 ]
When a new net namespace is created, we should attach to it a "struct
net_generic" with enough slots (even empty), or we can hit the following
BUG_ON() :
[ 200.752016] kernel BUG at include/net/netns/generic.h:40!
...
[ 200.752016] [<
ffffffff825c3cea>] ? get_cfcnfg+0x3a/0x180
[ 200.752016] [<
ffffffff821cf0b0>] ? lockdep_rtnl_is_held+0x10/0x20
[ 200.752016] [<
ffffffff825c41be>] caif_device_notify+0x2e/0x530
[ 200.752016] [<
ffffffff810d61b7>] notifier_call_chain+0x67/0x110
[ 200.752016] [<
ffffffff810d67c1>] raw_notifier_call_chain+0x11/0x20
[ 200.752016] [<
ffffffff821bae82>] call_netdevice_notifiers+0x32/0x60
[ 200.752016] [<
ffffffff821c2b26>] register_netdevice+0x196/0x300
[ 200.752016] [<
ffffffff821c2ca9>] register_netdev+0x19/0x30
[ 200.752016] [<
ffffffff81c1c67a>] loopback_net_init+0x4a/0xa0
[ 200.752016] [<
ffffffff821b5e62>] ops_init+0x42/0x180
[ 200.752016] [<
ffffffff821b600b>] setup_net+0x6b/0x100
[ 200.752016] [<
ffffffff821b6466>] copy_net_ns+0x86/0x110
[ 200.752016] [<
ffffffff810d5789>] create_new_namespaces+0xd9/0x190
net_alloc_generic() should take into account the maximum index into the
ptr array, as a subsystem might use net_generic() anytime.
This also reduces number of reallocations in net_assign_generic()
Reported-by: Sasha Levin <levinsasha928@gmail.com>
Tested-by: Sasha Levin <levinsasha928@gmail.com>
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Cc: Sjur Brændeland <sjur.brandeland@stericsson.com>
Cc: Eric W. Biederman <ebiederm@xmission.com>
Cc: Pavel Emelyanov <xemul@openvz.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bjørn Mork [Fri, 20 Jan 2012 00:49:57 +0000 (01:49 +0100)]
USB: cdc-wdm: Avoid hanging on interface with no USB_CDC_DMM_TYPE
commit
15699e6fafc3a90e5fdc2ef30555a04dee62286f upstream.
The probe does not strictly require the USB_CDC_DMM_TYPE
descriptor, which is a good thing as it makes the driver
usable on non-conforming interfaces. A user could e.g.
bind to it to a CDC ECM interface by using the new_id and
bind sysfs files. But this would fail with a 0 buffer length
due to the missing descriptor.
Fix by defining a reasonable fallback size: The minimum
device receive buffer size required by the CDC WMC standard,
revision 1.1
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bjørn Mork [Mon, 16 Jan 2012 14:11:59 +0000 (15:11 +0100)]
USB: cdc-wdm: better allocate a buffer that is at least as big as we tell the USB core
commit
655e247daf52b202a6c2d0f8a06dd2051e756ce4 upstream.
As it turns out, there was a mismatch between the allocated inbuf size
(desc->bMaxPacketSize0, typically something like 64) and the length we
specified in the URB (desc->wMaxCommand, typically something like 2048)
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Cc: Oliver Neukum <oliver@neukum.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bjørn Mork [Mon, 16 Jan 2012 14:11:57 +0000 (15:11 +0100)]
USB: cdc-wdm: call wake_up_all to allow driver to shutdown on device removal
commit
62aaf24dc125d7c55c93e313d15611f152b030c7 upstream.
wdm_disconnect() waits for the mutex held by wdm_read() before
calling wake_up_all(). This causes a deadlock, preventing device removal
to complete. Do the wake_up_all() before we start waiting for the locks.
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Cc: Oliver Neukum <oliver@neukum.org>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Vivien Didelot [Thu, 26 Jan 2012 20:59:00 +0000 (15:59 -0500)]
hwmon: (sht15) fix bad error code
commit
6edf3c30af01854c416f8654d3d5d2652470afd4 upstream.
When no platform data was supplied, returned error code was 0.
Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
Signed-off-by: Guenter Roeck <guenter.roeck@ericsson.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Guenter Roeck [Sat, 28 Jan 2012 01:56:06 +0000 (17:56 -0800)]
hwmon: (w83627ehf) Disable setting DC mode for pwm2, pwm3 on NCT6776F
commit
ad77c3e1808f07fa70f707b1c92a683b7c7d3f85 upstream.
NCT6776F only supports pwm mode for pwm2 and pwm3. Return error if an attempt
is made to set those pwm channels to DC mode.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Acked-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Guenter Roeck <guenter.roeck@ericsson.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jean Delvare [Fri, 20 Jan 2012 15:09:23 +0000 (10:09 -0500)]
hwmon: (f71805f) Fix clamping of temperature limits
commit
86b2bbfdbd1fcc4a3aa62ccd3f245c40c5ad5b85 upstream.
Properly clamp temperature limits set by the user. Without this fix,
attempts to write temperature limits above the maximum supported by
the chip (255 degrees Celsius) would arbitrarily and unexpectedly
result in the limit being set to 0 degree Celsius.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Guenter Roeck <guenter.roeck@ericsson.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Andiry Xu [Wed, 18 Jan 2012 09:47:12 +0000 (17:47 +0800)]
xHCI: Cleanup isoc transfer ring when TD length mismatch found
commit
cf840551a884360841bd3d3ce1ad0868ff0b759a upstream.
When a TD length mismatch is found during isoc TRB enqueue, it directly
returns -EINVAL. However, isoc transfer is partially enqueued at this time,
and the ring should be cleared.
This should be backported to kernels as old as 2.6.36, which contain the
commit
522989a27c7badb608155b1f1dea3487ed431f74 "xhci: Fix failed
enqueue in the middle of isoch TD."
Signed-off-by: Andiry Xu <andiry.xu@amd.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Sarah Sharp [Tue, 15 Nov 2011 01:51:39 +0000 (17:51 -0800)]
xhci: Fix USB 3.0 device restart on resume.
commit
d0cd5d482b8a6dc92c6c69a5387baf72ea84f23a upstream.
The xHCI hub port code gets passed a zero-based port number by the USB
core. It then adds one to in order to find a device slot by port number
and device speed by calling xhci_find_slot_id_by_port. That function
clearly states it requires a one-based port number. The xHCI port
status change event handler was using a zero-based port number that it
got from find_faked_portnum_from_hw_portnum, not a one-based port
number. This lead to the doorbells never being rung for a device after
a resume, or worse, a different device with the same speed having its
doorbell rung (which could lead to bad power management in the xHCI host
controller).
This patch should be backported to kernels as old as 2.6.39.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Acked-by: Andiry Xu <andiry.xu@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Julia Lawall [Thu, 12 Jan 2012 09:55:13 +0000 (10:55 +0100)]
drivers/usb/host/ehci-fsl.c: add missing iounmap
commit
2492c6e6454ff3edb11e273b071a6ea80a199c71 upstream.
Add missing iounmap in error handling code, in a case where the function
already preforms iounmap on some other execution path.
A simplified version of the semantic match that finds this problem is as
follows: (http://coccinelle.lip6.fr/)
// <smpl>
@@
expression e;
statement S,S1;
int ret;
@@
e = \(ioremap\|ioremap_nocache\)(...)
... when != iounmap(e)
if (<+...e...+>) S
... when any
when != iounmap(e)
*if (...)
{ ... when != iounmap(e)
return ...; }
... when any
iounmap(e);
// </smpl>
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Harrison Metzger [Sun, 15 Jan 2012 14:43:24 +0000 (08:43 -0600)]
USB: usbsevseg: fix max length
commit
1097ccebe630170080c41df0edcf88e0626e9c75 upstream.
This changes the max length for the usb seven segment delcom device to 8
from 6. Delcom has both 6 and 8 variants and having 8 works fine with
devices which are only 6.
Signed-off-by: Harrison Metzger <harrisonmetz@gmail.com>
Signed-off-by: Stuart Pook <stuart@acm.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ryan Mallon [Fri, 27 Jan 2012 21:51:40 +0000 (08:51 +1100)]
vmwgfx: Fix assignment in vmw_framebuffer_create_handle
commit
bf9c05d5b6d19b3e4c9fe21047694e94f48db89b upstream.
The assignment of handle in vmw_framebuffer_create_handle doesn't actually do anything useful and is incorrectly assigning an integer value to a pointer argument. It appears that this is a typo and should be dereferencing handle rather than assigning to it directly. This fixes a bug where an undefined handle value is potentially returned to user-space.
Signed-off-by: Ryan Mallon <rmallon@gmail.com>
Reviewed-by: Jakob Bornecrantz<jakob@vmware.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Lucas Kannebley Tavares [Mon, 9 Jan 2012 12:58:06 +0000 (10:58 -0200)]
jsm: Fixed EEH recovery error
commit
26aa38cafae0dbef3b2fe75ea487c83313c36d45 upstream.
There was an error on the jsm driver that would cause it to be unable to
recover after a second error is detected.
At the first error, the device recovers properly:
[72521.485691] EEH: Detected PCI bus error on device 0003:02:00.0
[72521.485695] EEH: This PCI device has failed 1 times in the last hour:
...
[72532.035693] ttyn3 at MMIO 0x0 (irq = 49) is a jsm
[72532.105689] jsm: Port 3 added
However, at the second error, it cascades until EEH disables the device:
[72631.229549] Call Trace:
...
[72641.725687] jsm: Port 3 added
[72641.725695] EEH: Detected PCI bus error on device 0003:02:00.0
[72641.725698] EEH: This PCI device has failed 3 times in the last hour:
It was caused because the PCI state was not being saved after the first
restore. Therefore, at the second recovery the PCI state would not be
restored.
Signed-off-by: Lucas Kannebley Tavares <lucaskt@linux.vnet.ibm.com>
Signed-off-by: Breno Leitao <brenohl@br.ibm.com>
Acked-by: Thadeu Lima de Souza Cascardo <cascardo@linux.vnet.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Rabin Vincent [Tue, 17 Jan 2012 10:52:28 +0000 (11:52 +0100)]
serial: amba-pl011: lock console writes against interrupts
commit
ef605fdb33883d687cff5ba75095a91b313b4966 upstream.
Protect against pl011_console_write() and the interrupt for
the console UART running concurrently on different CPUs.
Otherwise the console_write could spin for a long time
waiting for the UART to become not busy, while the other
CPU continuously services UART interrupts and keeps the
UART busy.
The checks for sysrq and oops_in_progress are taken
from 8250.c.
Signed-off-by: Rabin Vincent <rabin.vincent@stericsson.com>
Reviewed-by: Srinidhi Kasagar <srinidhi.kasagar@stericsson.com>
Reviewed-by: Bibek Basu <bibek.basu@stericsson.com>
Reviewed-by: Shreshtha Kumar Sahu <shreshthakumar.sahu@stericsson.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jiri Slaby [Thu, 12 Jan 2012 21:55:15 +0000 (22:55 +0100)]
TTY: fix UV serial console regression
commit
0eee50af5b13e00b3fb7a5fe8480419a71b8235d upstream.
Commit
74c2107759d (serial: Use block_til_ready helper) and its fixup
3f582b8c110 (serial: fix termios settings in open) introduced a
regression on UV systems. The serial eventually freezes while being
used. It's completely unpredictable and sometimes needs a heap of
traffic to happen first.
To reproduce this, yast installation was used as it turned out to be
pretty reliable in reproducing. Especially during installation process
where one doesn't have an SSH daemon running. And no monitor as the HW
is completely headless. So this was fun to find. Given the machine
doesn't boot on vanilla before 2.6.36 final. (And the commits above
are older.)
Unless there is some bad race in the code, the hardware seems to be
pretty broken. Otherwise pure MSR read should not cause such a bug,
or?
So to prevent the bug, revert to the old behavior. I.e. read modem
status only if we really have to -- for non-CLOCAL set serials.
Non-CLOCAL works on this hardware OK, I tried. See? I don't.
And document that shit.
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
References: https://lkml.org/lkml/2011/12/6/573
References: https://bugzilla.novell.com/show_bug.cgi?id=718518
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Eric W. Biederman [Sat, 14 Jan 2012 05:32:06 +0000 (21:32 -0800)]
usb: io_ti: Make edge_remove_sysfs_attrs the port_remove method.
commit
6d443d8499e4e59ffb949759cdded32730f8d2f6 upstream.
Calling edge_remove_sysfs_attrs from edge_disconnect is too late
as the device has already been removed from sysfs.
Do the simple and obvious thing and make edge_remove_sysfs_attrs
the port_remove method.
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
Reported-by: Wolfgang Frisch <wfpub@roembden.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Dan Williams [Tue, 24 Jan 2012 23:16:54 +0000 (17:16 -0600)]
qcaux: add more Pantech UML190 and UML290 ports
commit
074cc73506f529f39fef32ad1c9e1d4cdd8acf6c upstream.
More ports we now know how to talk to.
Signed-off-by: Dan Williams <dcbw@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bjørn Mork [Mon, 16 Jan 2012 11:41:48 +0000 (12:41 +0100)]
USB: cdc-wdm: use two mutexes to allow simultaneous read and write
commit
e8537bd2c4f325a4796da33564ddcef9489b7feb upstream.
using a separate read and write mutex for locking is sufficient to make the
driver accept simultaneous read and write. This improves useability a lot.
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Cc: Oliver Neukum <oneukum@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bjørn Mork [Mon, 16 Jan 2012 11:41:47 +0000 (12:41 +0100)]
USB: cdc-wdm: updating desc->length must be protected by spin_lock
commit
c428b70c1e115c5649707a602742e34130d19428 upstream.
wdm_in_callback() will also touch this field, so we cannot change it without locking
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Acked-by: Oliver Neukum <oneukum@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alan Cox [Thu, 26 Jan 2012 17:41:34 +0000 (17:41 +0000)]
USB: ftdi_sio: Add more identifiers
commit
2353f806c97020d4c7709f15eebb49b591f7306d upstream.
0x04d8, 0x000a: Hornby Elite
Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Peter Naulls [Wed, 18 Jan 2012 02:27:09 +0000 (18:27 -0800)]
USB: serial: ftdi additional IDs
commit
fc216ec363f4d174932df90bbf35c77d0540e561 upstream.
I tested this against 2.6.39 in the Ubuntu kernel, however I see the IDs
are not in latest 3.2 git.
This adds IDs for the FTDI controller in the Rainforest Automation
Zigbee dongle.
Signed-off-by: Peter Naulls <peter@chocky.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Peter Korsgaard [Wed, 18 Jan 2012 22:43:45 +0000 (23:43 +0100)]
USB: ftdi_sio: add PID for TI XDS100v2 / BeagleBone A3
commit
55f13aeae0346f0c89bfface91ad9a97653dc433 upstream.
Port A for JTAG, port B for serial.
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Johan Hovold [Wed, 18 Jan 2012 00:46:00 +0000 (01:46 +0100)]
USB: ftdi_sio: fix initial baud rate
commit
108e02b12921078a59dcacd048079ece48a4a983 upstream.
Fix regression introduced by commit
b1ffb4c851f1 ("USB: Fix Corruption
issue in USB ftdi driver ftdi_sio.c") which caused the termios settings
to no longer be initialised at open. Consequently it was no longer
possible to set the port to the default speed of 9600 baud without first
changing to another baud rate and back again.
Reported-by: Roland Ramthun <mail@roland-ramthun.de>
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Tested-by: Roland Ramthun <mail@roland-ramthun.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Johan Hovold [Tue, 10 Jan 2012 22:33:37 +0000 (23:33 +0100)]
USB: ftdi_sio: fix TIOCSSERIAL baud_base handling
commit
eb833a9e0972f60beb4ab8104ad7ef6bf30f02fc upstream.
Return EINVAL if new baud_base does not match the current one.
The baud_base is device specific and can not be changed. This restores
the old (pre-2005) behaviour which was changed due to a
misunderstanding regarding this fact (see
https://lkml.org/lkml/2005/1/20/84).
Reported-by: Torbjörn Lofterud <torbjorn@pi.nxs.se>
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Kentaro Matsuyama [Thu, 12 Jan 2012 14:07:51 +0000 (23:07 +0900)]
USB: option: Add LG docomo L-02C
commit
e423d7401fd0717cb56a6cf51dd8341cc3e800d2 upstream.
Add vendor and product ID for USB 3G/LTE modem of docomo L-02C
Signed-off-by: Kentaro Matsuyama <kentaro.matsuyama@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Will Deacon [Fri, 20 Jan 2012 11:10:18 +0000 (12:10 +0100)]
ARM: 7296/1: proc-v7.S: remove HARVARD_CACHE preprocessor guards
commit
612539e81f655f6ac73c7af1da8701c1ee618aee upstream.
On v7, we use the same cache maintenance instructions for data lines
as for unified lines. This was not the case for v6, where HARVARD_CACHE
was defined to indicate the L1 cache topology.
This patch removes the erroneous compile-time check for HARVARD_CACHE in
proc-v7.S, ensuring that we perform I-side invalidation at boot.
Reported-and-Acked-by: Shawn Guo <shawn.guo@linaro.org>
Acked-by: Catalin Marinas <Catalin.Marinas@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Srinidhi KASAGAR [Thu, 12 Jan 2012 05:37:43 +0000 (11:07 +0530)]
mach-ux500: enable ARM errata 764369
commit
d65015f7c5c5be9fd3f5e567889c844ba81bdc9c upstream.
This applies ARM errata 764369 for all ux500 platforms.
Signed-off-by: Srinidhi Kasagar <srinidhi.kasagar@stericsson.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jonathan Nieder [Mon, 8 Aug 2011 04:22:43 +0000 (06:22 +0200)]
cap_syslog: don't use WARN_ONCE for CAP_SYS_ADMIN deprecation warning
commit
f2c0d0266cc5eb36a4aa44944b4096ec121490aa upstream.
syslog-ng versions before 3.3.0beta1 (2011-05-12) assume that
CAP_SYS_ADMIN is sufficient to access syslog, so ever since CAP_SYSLOG
was introduced (2010-11-25) they have triggered a warning.
Commit
ee24aebffb75 ("cap_syslog: accept CAP_SYS_ADMIN for now")
improved matters a little by making syslog-ng work again, just keeping
the WARN_ONCE(). But still, this is a warning that writes a stack trace
we don't care about to syslog, sets a taint flag, and alarms sysadmins
when nothing worse has happened than use of an old userspace with a
recent kernel.
Convert the WARN_ONCE to a printk_once to avoid that while continuing to
give userspace developers a hint that this is an unwanted
backward-compatibility feature and won't be around forever.
Reported-by: Ralf Hildebrandt <ralf.hildebrandt@charite.de>
Reported-by: Niels <zorglub_olsen@hotmail.com>
Reported-by: Paweł Sikora <pluto@agmk.net>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Liked-by: Gergely Nagy <algernon@madhouse-project.org>
Acked-by: Serge Hallyn <serge@hallyn.com>
Acked-by: James Morris <jmorris@namei.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Christoph Biedl <linux-kernel.bfrz@manchmal.in-ulm.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Paulo Zanoni [Fri, 6 Jan 2012 21:45:34 +0000 (19:45 -0200)]
drm/i915/sdvo: always set positive sync polarity
commit
ba68e086223a5f149f37bf8692c8cdbf1b0ba3ef upstream.
This is a revert of
81a14b46846fea0741902e8d8dfcc6c6c78154c8.
We already set the mode polarity using the SDVO commands with struct
intel_sdvo_dtd. We have at least 3 bugs that get fixed with this patch.
The documentation, despite not clear, can also be interpreted in a way
that suggests this patch is needed.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=15766
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=42174
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=43333
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Takashi Iwai [Thu, 26 Jan 2012 14:56:16 +0000 (15:56 +0100)]
ALSA: hda - Fix silent output on Haier W18 laptop
commit
b3a81520bd37a28f77cb0f7002086fb14061824d upstream.
The very same problem is seen on Haier W18 laptop with ALC861 as seen
on ASUS A6Rp, which was fixed by the commit
3b25eb69.
Now we just need to add a new SSID entry pointing to the same fixup.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=42656
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Takashi Iwai [Wed, 25 Jan 2012 08:55:46 +0000 (09:55 +0100)]
ALSA: hda - Fix silent output on ASUS A6Rp
commit
3b25eb690e8c7424eecffe1458c02b87b32aa001 upstream.
The refactoring of Realtek codec driver in 3.2 kernel caused a
regression for ASUS A6Rp laptop; it doesn't give any output.
The reason was that this machine has a secret master mute (or EAPD)
control via NID 0x0f VREF. Setting VREF50 on this node makes the
sound working again.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=42588
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Andreas Herrmann [Fri, 20 Jan 2012 16:44:12 +0000 (17:44 +0100)]
x86/microcode_amd: Add support for CPU family specific container files
commit
5b68edc91cdc972c46f76f85eded7ffddc3ff5c2 upstream.
We've decided to provide CPU family specific container files
(starting with CPU family 15h). E.g. for family 15h we have to
load microcode_amd_fam15h.bin instead of microcode_amd.bin
Rationale is that starting with family 15h patch size is larger
than 2KB which was hard coded as maximum patch size in various
microcode loaders (not just Linux).
Container files which include patches larger than 2KB cause
different kinds of trouble with such old patch loaders. Thus we
have to ensure that the default container file provides only
patches with size less than 2KB.
Signed-off-by: Andreas Herrmann <andreas.herrmann3@amd.com>
Cc: Borislav Petkov <borislav.petkov@amd.com>
Cc: <stable@kernel.org>
Link: http://lkml.kernel.org/r/20120120164412.GD24508@alberich.amd.com
[ documented the naming convention and tidied the code a bit. ]
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Russ Anderson [Thu, 19 Jan 2012 02:07:54 +0000 (20:07 -0600)]
x86/uv: Fix uv_gpa_to_soc_phys_ram() shift
commit
5a51467b146ab7948d2f6812892eac120a30529c upstream.
uv_gpa_to_soc_phys_ram() was inadvertently ignoring the
shift values. This fix takes the shift into account.
Signed-off-by: Russ Anderson <rja@sgi.com>
Link: http://lkml.kernel.org/r/20120119020753.GA7228@sgi.com
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Dave Chinner [Thu, 26 Jan 2012 19:47:42 +0000 (13:47 -0600)]
xfs: fix endian conversion issue in discard code
commit
b1c770c273a4787069306fc82aab245e9ac72e9d upstream
When finding the longest extent in an AG, we read the value directly
out of the AGF buffer without endian conversion. This will give an
incorrect length, resulting in FITRIM operations potentially not
trimming everything that it should.
Note, for 3.0-stable this has been modified to apply to
fs/xfs/linux-2.6/xfs_discard.c instead of fs/xfs/xfs_discard.c. -bpm
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Ben Myers <bpm@sgi.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Nick Bowler [Thu, 10 Nov 2011 09:01:27 +0000 (09:01 +0000)]
ah: Don't return NET_XMIT_DROP on input.
commit
4b90a603a1b21d63cf743cc833680cb195a729f6 upstream.
When the ahash driver returns -EBUSY, AH4/6 input functions return
NET_XMIT_DROP, presumably copied from the output code path. But
returning transmit codes on input doesn't make a lot of sense.
Since NET_XMIT_DROP is a positive int, this gets interpreted as
the next header type (i.e., success). As that can only end badly,
remove the check.
Signed-off-by: Nick Bowler <nbowler@elliptictech.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jiri Olsa [Mon, 5 Dec 2011 17:22:48 +0000 (18:22 +0100)]
ftrace: Fix unregister ftrace_ops accounting
commit
30fb6aa74011dcf595f306ca2727254d708b786e upstream.
Multiple users of the function tracer can register their functions
with the ftrace_ops structure. The accounting within ftrace will
update the counter on each function record that is being traced.
When the ftrace_ops filtering adds or removes functions, the
function records will be updated accordingly if the ftrace_ops is
still registered.
When a ftrace_ops is removed, the counter of the function records,
that the ftrace_ops traces, are decremented. When they reach zero
the functions that they represent are modified to stop calling the
mcount code.
When changes are made, the code is updated via stop_machine() with
a command passed to the function to tell it what to do. There is an
ENABLE and DISABLE command that tells the called function to enable
or disable the functions. But the ENABLE is really a misnomer as it
should just update the records, as records that have been enabled
and now have a count of zero should be disabled.
The DISABLE command is used to disable all functions regardless of
their counter values. This is the big off switch and is not the
complement of the ENABLE command.
To make matters worse, when a ftrace_ops is unregistered and there
is another ftrace_ops registered, neither the DISABLE nor the
ENABLE command are set when calling into the stop_machine() function
and the records will not be updated to match their counter. A command
is passed to that function that will update the mcount code to call
the registered callback directly if it is the only one left. This
means that the ftrace_ops that is still registered will have its callback
called by all functions that have been set for it as well as the ftrace_ops
that was just unregistered.
Here's a way to trigger this bug. Compile the kernel with
CONFIG_FUNCTION_PROFILER set and with CONFIG_FUNCTION_GRAPH not set:
CONFIG_FUNCTION_PROFILER=y
# CONFIG_FUNCTION_GRAPH is not set
This will force the function profiler to use the function tracer instead
of the function graph tracer.
# cd /sys/kernel/debug/tracing
# echo schedule > set_ftrace_filter
# echo function > current_tracer
# cat set_ftrace_filter
schedule
# cat trace
# tracer: nop
#
# entries-in-buffer/entries-written: 692/
68108025 #P:4
#
# _-----=> irqs-off
# / _----=> need-resched
# | / _---=> hardirq/softirq
# || / _--=> preempt-depth
# ||| / delay
# TASK-PID CPU# |||| TIMESTAMP FUNCTION
# | | | |||| | |
kworker/0:2-909 [000] .... 531.235574: schedule <-worker_thread
<idle>-0 [001] .N.. 531.235575: schedule <-cpu_idle
kworker/0:2-909 [000] .... 531.235597: schedule <-worker_thread
sshd-2563 [001] .... 531.235647: schedule <-schedule_hrtimeout_range_clock
# echo 1 > function_profile_enabled
# echo 0 > function_porfile_enabled
# cat set_ftrace_filter
schedule
# cat trace
# tracer: function
#
# entries-in-buffer/entries-written: 159701/
118821262 #P:4
#
# _-----=> irqs-off
# / _----=> need-resched
# | / _---=> hardirq/softirq
# || / _--=> preempt-depth
# ||| / delay
# TASK-PID CPU# |||| TIMESTAMP FUNCTION
# | | | |||| | |
<idle>-0 [002] ...1 604.870655: local_touch_nmi <-cpu_idle
<idle>-0 [002] d..1 604.870655: enter_idle <-cpu_idle
<idle>-0 [002] d..1 604.870656: atomic_notifier_call_chain <-enter_idle
<idle>-0 [002] d..1 604.870656: __atomic_notifier_call_chain <-atomic_notifier_call_chain
The same problem could have happened with the trace_probe_ops,
but they are modified with the set_frace_filter file which does the
update at closure of the file.
The simple solution is to change ENABLE to UPDATE and call it every
time an ftrace_ops is unregistered.
Link: http://lkml.kernel.org/r/1323105776-26961-3-git-send-email-jolsa@redhat.com
Signed-off-by: Jiri Olsa <jolsa@redhat.com>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Steven Rostedt [Wed, 13 Jul 2011 19:08:31 +0000 (15:08 -0400)]
ftrace: Update filter when tracing enabled in set_ftrace_filter()
commit
072126f4529196f71a97960248bca54fd4554c2d upstream.
Currently, if set_ftrace_filter() is called when the ftrace_ops is
active, the function filters will not be updated. They will only be updated
when tracing is disabled and re-enabled.
Update the functions immediately during set_ftrace_filter().
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Steven Rostedt [Wed, 13 Jul 2011 19:03:44 +0000 (15:03 -0400)]
ftrace: Balance records when updating the hash
commit
41fb61c2d08107ce96a5dcb3a6289b2afd3e135c upstream.
Whenever the hash of the ftrace_ops is updated, the record counts
must be balance. This requires disabling the records that are set
in the original hash, and then enabling the records that are set
in the updated hash.
Moving the update into ftrace_hash_move() removes the bug where the
hash was updated but the records were not, which results in ftrace
triggering a warning and disabling itself because the ftrace_ops filter
is updated while the ftrace_ops was registered, and then the failure
happens when the ftrace_ops is unregistered.
The current code will not trigger this bug, but new code will.
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alexey Dobriyan [Sat, 14 Jan 2012 18:40:57 +0000 (21:40 +0300)]
crypto: sha512 - reduce stack usage to safe number
commit
51fc6dc8f948047364f7d42a4ed89b416c6cc0a3 upstream.
For rounds 16--79, W[i] only depends on W[i - 2], W[i - 7], W[i - 15] and W[i - 16].
Consequently, keeping all W[80] array on stack is unnecessary,
only 16 values are really needed.
Using W[16] instead of W[80] greatly reduces stack usage
(~750 bytes to ~340 bytes on x86_64).
Line by line explanation:
* BLEND_OP
array is "circular" now, all indexes have to be modulo 16.
Round number is positive, so remainder operation should be
without surprises.
* initial full message scheduling is trimmed to first 16 values which
come from data block, the rest is calculated before it's needed.
* original loop body is unrolled version of new SHA512_0_15 and
SHA512_16_79 macros, unrolling was done to not do explicit variable
renaming. Otherwise it's the very same code after preprocessing.
See sha1_transform() code which does the same trick.
Patch survives in-tree crypto test and original bugreport test
(ping flood with hmac(sha512).
See FIPS 180-2 for SHA-512 definition
http://csrc.nist.gov/publications/fips/fips180-2/fips180-2withchangenotice.pdf
Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alexey Dobriyan [Sat, 14 Jan 2012 18:27:37 +0000 (21:27 +0300)]
crypto: sha512 - make it work, undo percpu message schedule
commit
84e31fdb7c797a7303e0cc295cb9bc8b73fb872d upstream.
commit
f9e2bca6c22d75a289a349f869701214d63b5060
aka "crypto: sha512 - Move message schedule W[80] to static percpu area"
created global message schedule area.
If sha512_update will ever be entered twice, hash will be silently
calculated incorrectly.
Probably the easiest way to notice incorrect hashes being calculated is
to run 2 ping floods over AH with hmac(sha512):
#!/usr/sbin/setkey -f
flush;
spdflush;
add IP1 IP2 ah 25 -A hmac-sha512 0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000025;
add IP2 IP1 ah 52 -A hmac-sha512 0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000052;
spdadd IP1 IP2 any -P out ipsec ah/transport//require;
spdadd IP2 IP1 any -P in ipsec ah/transport//require;
XfrmInStateProtoError will start ticking with -EBADMSG being returned
from ah_input(). This never happens with, say, hmac(sha1).
With patch applied (on BOTH sides), XfrmInStateProtoError does not tick
with multiple bidirectional ping flood streams like it doesn't tick
with SHA-1.
After this patch sha512_transform() will start using ~750 bytes of stack on x86_64.
This is OK for simple loads, for something more heavy, stack reduction will be done
separatedly.
Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jan Kara [Wed, 11 Jan 2012 18:52:10 +0000 (18:52 +0000)]
xfs: Fix missing xfs_iunlock() on error recovery path in xfs_readlink()
commit
9b025eb3a89e041bab6698e3858706be2385d692 upstream.
Commit
b52a360b forgot to call xfs_iunlock() when it detected corrupted
symplink and bailed out. Fix it by jumping to 'out' instead of doing return.
CC: Carlos Maiolino <cmaiolino@redhat.com>
Signed-off-by: Jan Kara <jack@suse.cz>
Reviewed-by: Alex Elder <elder@kernel.org>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Ben Myers <bpm@sgi.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Thomas Hellstrom [Tue, 24 Jan 2012 17:54:21 +0000 (18:54 +0100)]
drm: Fix authentication kernel crash
commit
598781d71119827b454fd75d46f84755bca6f0c6 upstream.
If the master tries to authenticate a client using drm_authmagic and
that client has already closed its drm file descriptor,
either wilfully or because it was terminated, the
call to drm_authmagic will dereference a stale pointer into kmalloc'ed memory
and corrupt it.
Typically this results in a hard system hang.
This patch fixes that problem by removing any authentication tokens
(struct drm_magic_entry) open for a file descriptor when that file
descriptor is closed.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alex Deucher [Sun, 15 Jan 2012 13:51:12 +0000 (08:51 -0500)]
drm/radeon/kms: Add an MSI quirk for Dell RS690
commit
44517c44496062180a6376cc704b33129441ce60 upstream.
Interrupts only work with MSIs.
https://bugs.freedesktop.org/show_bug.cgi?id=37679
Reported-by: Dmitry Podgorny <pasis.uax@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Tyler Hicks [Tue, 24 Jan 2012 16:02:22 +0000 (10:02 -0600)]
eCryptfs: Fix oops when printing debug info in extent crypto functions
commit
58ded24f0fcb85bddb665baba75892f6ad0f4b8a upstream.
If pages passed to the eCryptfs extent-based crypto functions are not
mapped and the module parameter ecryptfs_verbosity=1 was specified at
loading time, a NULL pointer dereference will occur.
Note that this wouldn't happen on a production system, as you wouldn't
pass ecryptfs_verbosity=1 on a production system. It leaks private
information to the system logs and is for debugging only.
The debugging info printed in these messages is no longer very useful
and rather than doing a kmap() in these debugging paths, it will be
better to simply remove the debugging paths completely.
https://launchpad.net/bugs/913651
Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Tyler Hicks [Fri, 20 Jan 2012 02:33:44 +0000 (20:33 -0600)]
eCryptfs: Check inode changes in setattr
commit
a261a03904849c3df50bd0300efb7fb3f865137d upstream.
Most filesystems call inode_change_ok() very early in ->setattr(), but
eCryptfs didn't call it at all. It allowed the lower filesystem to make
the call in its ->setattr() function. Then, eCryptfs would copy the
appropriate inode attributes from the lower inode to the eCryptfs inode.
This patch changes that and actually calls inode_change_ok() on the
eCryptfs inode, fairly early in ecryptfs_setattr(). Ideally, the call
would happen earlier in ecryptfs_setattr(), but there are some possible
inode initialization steps that must happen first.
Since the call was already being made on the lower inode, the change in
functionality should be minimal, except for the case of a file extending
truncate call. In that case, inode_newsize_ok() was never being
called on the eCryptfs inode. Rather than inode_newsize_ok() catching
maximum file size errors early on, eCryptfs would encrypt zeroed pages
and write them to the lower filesystem until the lower filesystem's
write path caught the error in generic_write_checks(). This patch
introduces a new function, called ecryptfs_inode_newsize_ok(), which
checks if the new lower file size is within the appropriate limits when
the truncate operation will be growing the lower file.
In summary this change prevents eCryptfs truncate operations (and the
resulting page encryptions), which would exceed the lower filesystem
limits or FSIZE rlimits, from ever starting.
Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
Reviewed-by: Li Wang <liwang@nudt.edu.cn>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Tyler Hicks [Thu, 19 Jan 2012 00:30:04 +0000 (18:30 -0600)]
eCryptfs: Make truncate path killable
commit
5e6f0d769017cc49207ef56996e42363ec26c1f0 upstream.
ecryptfs_write() handles the truncation of eCryptfs inodes. It grabs a
page, zeroes out the appropriate portions, and then encrypts the page
before writing it to the lower filesystem. It was unkillable and due to
the lack of sparse file support could result in tying up a large portion
of system resources, while encrypting pages of zeros, with no way for
the truncate operation to be stopped from userspace.
This patch adds the ability for ecryptfs_write() to detect a pending
fatal signal and return as gracefully as possible. The intent is to
leave the lower file in a useable state, while still allowing a user to
break out of the encryption loop. If a pending fatal signal is detected,
the eCryptfs inode size is updated to reflect the modified inode size
and then -EINTR is returned.
Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Tim Gardner [Thu, 12 Jan 2012 15:31:55 +0000 (16:31 +0100)]
ecryptfs: Improve metadata read failure logging
commit
30373dc0c87ffef68d5628e77d56ffb1fa22e1ee upstream.
Print inode on metadata read failure. The only real
way of dealing with metadata read failures is to delete
the underlying file system file. Having the inode
allows one to 'find . -inum INODE`.
[tyhicks@canonical.com: Removed some minor not-for-stable parts]
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Tyler Hicks [Thu, 12 Jan 2012 10:30:44 +0000 (11:30 +0100)]
eCryptfs: Sanitize write counts of /dev/ecryptfs
commit
db10e556518eb9d21ee92ff944530d84349684f4 upstream.
A malicious count value specified when writing to /dev/ecryptfs may
result in a a very large kernel memory allocation.
This patch peeks at the specified packet payload size, adds that to the
size of the packet headers and compares the result with the write count
value. The resulting maximum memory allocation size is approximately 532
bytes.
Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
Reported-by: Sasha Levin <levinsasha928@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Takashi Iwai [Mon, 23 Jan 2012 17:23:36 +0000 (18:23 +0100)]
ALSA: hda - Fix silent outputs from docking-station jacks of Dell laptops
commit
b4ead019afc201f71c39cd0dfcaafed4a97b3dd2 upstream.
The recent change of the power-widget handling for IDT codecs caused
the silent output from the docking-station line-out jack. This was
partially fixed by the commit
f2cbba7602383cd9cdd21f0a5d0b8bd1aad47b33
"ALSA: hda - Fix the lost power-setup of seconary pins after PM resume".
But the line-out on the docking-station is still silent when booted
with the jack plugged even by this fix.
The remainig bug is that the power-widget is set off in stac92xx_init()
because the pins in cfg->line_out_pins[] aren't checked there properly
but only hp_pins[] are checked in is_nid_hp_pin().
This patch fixes the problem by checking both HP and line-out pins
and leaving the power-map correctly.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=42637
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Greg Kroah-Hartman [Thu, 26 Jan 2012 01:26:46 +0000 (17:26 -0800)]
Linux 3.0.18
Artem Bityutskiy [Wed, 11 Jan 2012 13:13:27 +0000 (15:13 +0200)]
UBIFS: make debugging messages light again
commit
1f5d78dc4823a85f112aaa2d0f17624f8c2a6c52 upstream.
We switch to dynamic debugging in commit
56e46742e846e4de167dde0e1e1071ace1c882a5 but did not take into account that
now we do not control anymore whether a specific message is enabled or not.
So now we lock the "dbg_lock" and release it in every debugging macro, which
make them not so light-weight.
This commit removes the "dbg_lock" protection from the debugging macros to
fix the issue.
The downside is that now our DBGKEY() stuff is broken, but this is not
critical at all and will be fixed later.
Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Stanislaw Gruszka [Fri, 23 Dec 2011 07:13:50 +0000 (08:13 +0100)]
iwlegacy: 3945: fix hw passive scan on radar channels
commit
68acc4afb040d98ddfd2cae0de09e2f4e1ee127f upstream.
Patch fix firmware error on "iw dev wlan0 scan passive" for
hardware scanning (with disable_hw_scan=0 module parameter).
iwl3945 0000:03:00.0: Microcode SW error detected. Restarting 0x82000008.
iwl3945 0000:03:00.0: Loaded firmware version: 15.32.2.9
iwl3945 0000:03:00.0: Start IWL Error Log Dump:
iwl3945 0000:03:00.0: Status: 0x0002A2E4, count: 1
iwl3945 0000:03:00.0: Desc Time asrtPC blink2 ilink1 nmiPC Line
iwl3945 0000:03:00.0: SYSASSERT (0x5)
0041263900 0x13756 0x0031C 0x00000 764
iwl3945 0000:03:00.0: Error Reply type 0x000002FC cmd C_SCAN (0x80) seq 0x443E ser 0x00340000
iwl3945 0000:03:00.0: Command C_SCAN failed: FW Error
iwl3945 0000:03:00.0: Can't stop Rx DMA.
We have disable ability to change passive scanning to active on
particular channel when traffic is detected on that channel. Otherwise
firmware will report error, when we try to do passive scan on radar
channels.
Reported-and-debugged-by: Pedro Francisco <pedrogfrancisco@gmail.com>
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Wey-Yi Guy [Thu, 10 Nov 2011 14:55:04 +0000 (06:55 -0800)]
iwlagn: check for SMPS mode
commit
b2ccccdca46273c7b321ecf5041c362cd950da20 upstream.
Check and report WARN only when its invalid
Resolves:
https://bugzilla.kernel.org/show_bug.cgi?id=42621
https://bugzilla.redhat.com/show_bug.cgi?id=766071
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Michal Hocko [Fri, 20 Jan 2012 22:33:55 +0000 (14:33 -0800)]
mm: fix NULL ptr dereference in __count_immobile_pages
commit
687875fb7de4a95223af20ee024282fa9099f860 upstream.
Fix the following NULL ptr dereference caused by
cat /sys/devices/system/memory/memory0/removable
Pid: 13979, comm: sed Not tainted 3.0.13-0.5-default #1 IBM BladeCenter LS21 -[7971PAM]-/Server Blade
RIP: __count_immobile_pages+0x4/0x100
Process sed (pid: 13979, threadinfo
ffff880221c36000, task
ffff88022e788480)
Call Trace:
is_pageblock_removable_nolock+0x34/0x40
is_mem_section_removable+0x74/0xf0
show_mem_removable+0x41/0x70
sysfs_read_file+0xfe/0x1c0
vfs_read+0xc7/0x130
sys_read+0x53/0xa0
system_call_fastpath+0x16/0x1b
We are crashing because we are trying to dereference NULL zone which
came from pfn=0 (struct page
ffffea0000000000). According to the boot
log this page is marked reserved:
e820 update range:
0000000000000000 -
0000000000010000 (usable) ==> (reserved)
and early_node_map confirms that:
early_node_map[3] active PFN ranges
1: 0x00000010 -> 0x0000009c
1: 0x00000100 -> 0x000bffa3
1: 0x00100000 -> 0x00240000
The problem is that memory_present works in PAGE_SECTION_MASK aligned
blocks so the reserved range sneaks into the the section as well. This
also means that free_area_init_node will not take care of those reserved
pages and they stay uninitialized.
When we try to read the removable status we walk through all available
sections and hope that the zone is valid for all pages in the section.
But this is not true in this case as the zone and nid are not initialized.
We have only one node in this particular case and it is marked as node=1
(rather than 0) and that made the problem visible because page_to_nid will
return 0 and there are no zones on the node.
Let's check that the zone is valid and that the given pfn falls into its
boundaries and mark the section not removable. This might cause some
false positives, probably, but we do not have any sane way to find out
whether the page is reserved by the platform or it is just not used for
whatever other reasons.
Signed-off-by: Michal Hocko <mhocko@suse.cz>
Acked-by: Mel Gorman <mgorman@suse.de>
Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: Andrea Arcangeli <aarcange@redhat.com>
Cc: David Rientjes <rientjes@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Will Deacon [Fri, 20 Jan 2012 22:34:09 +0000 (14:34 -0800)]
proc: clear_refs: do not clear reserved pages
commit
85e72aa5384b1a614563ad63257ded0e91d1a620 upstream.
/proc/pid/clear_refs is used to clear the Referenced and YOUNG bits for
pages and corresponding page table entries of the task with PID pid, which
includes any special mappings inserted into the page tables in order to
provide things like vDSOs and user helper functions.
On ARM this causes a problem because the vectors page is mapped as a
global mapping and since
ec706dab ("ARM: add a vma entry for the user
accessible vector page"), a VMA is also inserted into each task for this
page to aid unwinding through signals and syscall restarts. Since the
vectors page is required for handling faults, clearing the YOUNG bit (and
subsequently writing a faulting pte) means that we lose the vectors page
*globally* and cannot fault it back in. This results in a system deadlock
on the next exception.
To see this problem in action, just run:
$ echo 1 > /proc/self/clear_refs
on an ARM platform (as any user) and watch your system hang. I think this
has been the case since 2.6.37
This patch avoids clearing the aforementioned bits for reserved pages,
therefore leaving the vectors page intact on ARM. Since reserved pages
are not candidates for swap, this change should not have any impact on the
usefulness of clear_refs.
Signed-off-by: Will Deacon <will.deacon@arm.com>
Reported-by: Moussa Ba <moussaba@micron.com>
Acked-by: Hugh Dickins <hughd@google.com>
Cc: David Rientjes <rientjes@google.com>
Cc: Russell King <rmk@arm.linux.org.uk>
Acked-by: Nicolas Pitre <nico@linaro.org>
Cc: Matt Mackall <mpm@selenic.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Ananth N Mavinakayanahalli [Fri, 20 Jan 2012 22:34:04 +0000 (14:34 -0800)]
kprobes: initialize before using a hlist
commit
d496aab567e7e52b3e974c9192a5de6e77dce32c upstream.
Commit
ef53d9c5e ("kprobes: improve kretprobe scalability with hashed
locking") introduced a bug where we can potentially leak
kretprobe_instances since we initialize a hlist head after having used
it.
Initialize the hlist head before using it.
Reported by: Jim Keniston <jkenisto@us.ibm.com>
Acked-by: Jim Keniston <jkenisto@us.ibm.com>
Signed-off-by: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
Acked-by: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
Cc: Srinivasa D S <srinivasa@in.ibm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Dan Rosenberg [Fri, 20 Jan 2012 22:34:27 +0000 (14:34 -0800)]
score: fix off-by-one index into syscall table
commit
c25a785d6647984505fa165b5cd84cfc9a95970b upstream.
If the provided system call number is equal to __NR_syscalls, the
current check will pass and a function pointer just after the system
call table may be called, since sys_call_table is an array with total
size __NR_syscalls.
Whether or not this is a security bug depends on what the compiler puts
immediately after the system call table. It's likely that this won't do
anything bad because there is an additional NULL check on the syscall
entry, but if there happens to be a non-NULL value immediately after the
system call table, this may result in local privilege escalation.
Signed-off-by: Dan Rosenberg <drosenberg@vsecurity.com>
Cc: Chen Liqin <liqin.chen@sunplusct.com>
Cc: Lennox Wu <lennox.wu@gmail.com>
Cc: Eugene Teo <eugeneteo@kernel.sg>
Cc: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Toshiharu Okada [Mon, 26 Sep 2011 07:16:23 +0000 (16:16 +0900)]
i2c-eg20t: modified the setting of transfer rate.
commit
ff35e8b18984ad2a82cbd259fc07f0be4b34b1aa upstream.
This patch modified the setting value of
I2C Bus Transfer Rate Setting Counter regisrer.
Signed-off-by: Toshiharu Okada <toshiharu-linux@dsn.okisemi.com>
Signed-off-by: Ben Dooks <ben-linux@fluff.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Dirk Eibach [Tue, 18 Oct 2011 03:04:11 +0000 (03:04 +0000)]
net: Fix driver name for mdio-gpio.c
commit
f42af6c486aa5ca6ee62800cb45c5b252020509d upstream.
Since commit
"7488876... dt/net: Eliminate users of of_platform_{,un}register_driver"
there are two platform drivers named "mdio-gpio" registered.
I renamed the of variant to "mdio-ofgpio".
Signed-off-by: Dirk Eibach <eibach@gdsys.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Boaz Harrosh [Fri, 6 Jan 2012 07:31:20 +0000 (09:31 +0200)]
pnfs-obj: Must return layout on IO error
commit
fe0fe83585f88346557868a803a479dfaaa0688a upstream.
As mandated by the standard. In case of an IO error, a pNFS
objects layout driver must return it's layout. This is because
all device errors are reported to the server as part of the
layout return buffer.
This is implemented the same way PNFS_LAYOUTRET_ON_SETATTR
is done, through a bit flag on the pnfs_layoutdriver_type->flags
member. The flag is set by the layout driver that wants a
layout_return preformed at pnfs_ld_{write,read}_done in case
of an error.
(Though I have not defined a wrapper like pnfs_ld_layoutret_on_setattr
because this code is never called outside of pnfs.c and pnfs IO
paths)
Without this patch 3.[0-2] Kernels leak memory and have an annoying
WARN_ON after every IO error utilizing the pnfs-obj driver.
Signed-off-by: Boaz Harrosh <bharrosh@panasas.com>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Boaz Harrosh [Fri, 6 Jan 2012 07:28:12 +0000 (09:28 +0200)]
pnfs-obj: pNFS errors are communicated on iodata->pnfs_error
commit
5c0b4129c07b902b27d3f3ebc087757f534a3abd upstream.
Some time along the way pNFS IO errors were switched to
communicate with a special iodata->pnfs_error member instead
of the regular RPC members. But objlayout was not switched
over.
Fix that!
Without this fix any IO error is hanged, because IO is not
switched to MDS and pages are never cleared or read.
Signed-off-by: Boaz Harrosh <bharrosh@panasas.com>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Stanislaw Gruszka [Fri, 13 Jan 2012 11:59:32 +0000 (12:59 +0100)]
rt2800pci: fix spurious interrupts generation
commit
dfd00c4c8f3dfa1fd7cec45f83d98b2a49743dcd upstream.
Same devices can generate interrupt without properly setting bit in
INT_SOURCE_CSR register (spurious interrupt), what will cause IRQ line
will be disabled by interrupts controller driver.
We discovered that clearing INT_MASK_CSR stops such behaviour. We
previously first read that register, and then clear all know interrupt
sources bits and do not touch reserved bits. After this patch, we write
to all register content (I believe writing to reserved bits on that
register will not cause any problems, I tested that on my rt2800pci
device).
This fix very bad performance problem, practically making device
unusable (since worked without interrupts), reported in:
https://bugzilla.redhat.com/show_bug.cgi?id=658451
We previously tried to workaround that issue in commit
4ba7d9997869d25bd223dea7536fc1ce9fab3b3b "rt2800pci: handle spurious
interrupts", but it was reverted in commit
82e5fc2a34fa9ffea38f00c4066b7e600a0ca5e6
as thing, that will prevent to detect real spurious interrupts.
Reported-and-tested-by: Amir Hedayaty <hedayaty@gmail.com>
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Acked-by: Gertjan van Wingerde <gwingerde@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Cliff Wickman [Mon, 16 Jan 2012 21:18:48 +0000 (15:18 -0600)]
x86/UV2: Fix BAU destination timeout initialization
commit
d059f9fa84a30e04279c6ff615e9e2cf3b260191 upstream.
Move the call to enable_timeouts() forward so that
BAU_MISC_CONTROL is initialized before using it in
calculate_destination_timeout().
Fix the calculation of a BAU destination timeout
for UV2 (in calculate_destination_timeout()).
Signed-off-by: Cliff Wickman <cpw@sgi.com>
Link: http://lkml.kernel.org/r/20120116211848.GB5767@sgi.com
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Alexander Aring [Thu, 8 Dec 2011 14:43:53 +0000 (15:43 +0100)]
I2C: OMAP: correct SYSC register offset for OMAP4
commit
2727b1753934e154931d6b3bdf20c9b2398457a2 upstream.
Correct OMAP_I2C_SYSC_REG offset in omap4 register map.
Offset 0x20 is reserved and OMAP_I2C_SYSC_REG has 0x10 as offset.
Signed-off-by: Alexander Aring <a.aring@phytec.de>
[khilman@ti.com: minor changelog edits]
Signed-off-by: Kevin Hilman <khilman@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Roland Dreier [Tue, 13 Dec 2011 22:55:33 +0000 (14:55 -0800)]
target: Set additional sense length field in sense data
commit
895f3022523361e9b383cf48f51feb1f7d5e7e53 upstream.
The target code was not setting the additional sense length field in the
sense data it returned, which meant that at least the Linux stack
ignored the ASC/ASCQ fields. For example, without this patch, on a
tcm_loop device:
# sg_raw -v /dev/sda 2 0 0 0 0 0
gives
cdb to send: 02 00 00 00 00 00
SCSI Status: Check Condition
Sense Information:
Fixed format, current; Sense key: Illegal Request
Raw sense data (in hex):
70 00 05 00 00 00 00 00
while after the patch we correctly get the following (which matches what
a regular disk returns):
cdb to send: 02 00 00 00 00 00
SCSI Status: Check Condition
Sense Information:
Fixed format, current; Sense key: Illegal Request
Additional sense: Invalid command operation code
Raw sense data (in hex):
70 00 05 00 00 00 00 0a 00 00 00 00 20 00 00 00
00 00
Signed-off-by: Roland Dreier <roland@purestorage.com>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Roland Dreier [Tue, 6 Dec 2011 18:02:09 +0000 (10:02 -0800)]
target: Set response format in INQUIRY response
commit
ce136176fea522fc8f4c16dcae7e8ed1d890ca39 upstream.
Current SCSI specs say that the "response format" field in the standard
INQUIRY response should be set to 2, and all the real SCSI devices I
have do put 2 here. So let's do that too.
Signed-off-by: Roland Dreier <roland@purestorage.com>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Stratos Psomadakis [Sun, 4 Dec 2011 00:23:54 +0000 (02:23 +0200)]
sym53c8xx: Fix NULL pointer dereference in slave_destroy
commit
cced5041ed5a2d1352186510944b0ddfbdbe4c0b upstream.
sym53c8xx_slave_destroy unconditionally assumes that sym53c8xx_slave_alloc has
succesesfully allocated a sym_lcb. This can lead to a NULL pointer dereference
(exposed by commit 4e6c82b).
Signed-off-by: Stratos Psomadakis <psomas@gentoo.org>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Lin Ming [Tue, 13 Dec 2011 01:36:03 +0000 (09:36 +0800)]
ACPI: processor: fix acpi_get_cpuid for UP processor
commit
d640113fe80e45ebd4a5b420b220d3f6bf37f682 upstream.
For UP processor, it is likely that no _MAT method or MADT table defined.
So currently acpi_get_cpuid(...) always return -1 for UP processor.
This is wrong. It should return valid value for CPU0.
In the other hand, BIOS may define multiple CPU handles even for UP
processor, for example
Scope (_PR)
{
Processor (CPU0, 0x00, 0x00000410, 0x06) {}
Processor (CPU1, 0x01, 0x00000410, 0x06) {}
Processor (CPU2, 0x02, 0x00000410, 0x06) {}
Processor (CPU3, 0x03, 0x00000410, 0x06) {}
}
We should only return valid value for CPU0's acpi handle.
And return invalid value for others.
http://marc.info/?t=
132329819900003&r=1&w=2
Reported-and-tested-by: wallak@free.fr
Signed-off-by: Lin Ming <ming.m.lin@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Lin Ming [Tue, 29 Nov 2011 14:13:35 +0000 (22:13 +0800)]
ACPICA: Put back the call to acpi_os_validate_address
commit
da4d8b287abe783d30e968155614531a0937d090 upstream.
The call to acpi_os_validate_address in acpi_ds_get_region_arguments was
removed by mistake in commit 9ad19ac(ACPICA: Split large dsopcode and
dsload.c files).
Put it back.
Reported-and-bisected-by: Luca Tettamanti <kronos.it@gmail.com>
Signed-off-by: Lin Ming <ming.m.lin@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Kurt Garloff [Tue, 17 Jan 2012 09:21:49 +0000 (04:21 -0500)]
ACPI, ia64: Use SRAT table rev to use 8bit or 16/32bit PXM fields (ia64)
commit
9f10f6a520deb3639fac78d81151a3ade88b4e7f upstream.
In SRAT v1, we had 8bit proximity domain (PXM) fields; SRAT v2 provides
32bits for these. The new fields were reserved before.
According to the ACPI spec, the OS must disregrard reserved fields.
ia64 did handle the PXM fields almost consistently, but depending on
sgi's sn2 platform. This patch leaves the sn2 logic in, but does also
use 16/32 bits for PXM if the SRAT has rev 2 or higher.
The patch also adds __init to the two pxm accessor functions, as they
access __initdata now and are called from an __init function only anyway.
Note that the code only uses 16 bits for the PXM field in the processor
proximity field; the patch does not address this as 16 bits are more than
enough.
Signed-off-by: Kurt Garloff <kurt@garloff.de>
Signed-off-by: Len Brown <len.brown@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Kurt Garloff [Tue, 17 Jan 2012 09:20:31 +0000 (04:20 -0500)]
ACPI, x86: Use SRAT table rev to use 8bit or 32bit PXM fields (x86/x86-64)
commit
cd298f60a2451a16e0f077404bf69b62ec868733 upstream.
In SRAT v1, we had 8bit proximity domain (PXM) fields; SRAT v2 provides
32bits for these. The new fields were reserved before.
According to the ACPI spec, the OS must disregrard reserved fields.
x86/x86-64 was rather inconsistent prior to this patch; it used 8 bits
for the pxm field in cpu_affinity, but 32 bits in mem_affinity.
This patch makes it consistent: Either use 8 bits consistently (SRAT
rev 1 or lower) or 32 bits (SRAT rev 2 or higher).
cc: x86@kernel.org
Signed-off-by: Kurt Garloff <kurt@garloff.de>
Signed-off-by: Len Brown <len.brown@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Kurt Garloff [Tue, 17 Jan 2012 09:18:02 +0000 (04:18 -0500)]
ACPI: Store SRAT table revision
commit
8df0eb7c9d96f9e82f233ee8b74e0f0c8471f868 upstream.
In SRAT v1, we had 8bit proximity domain (PXM) fields; SRAT v2 provides
32bits for these. The new fields were reserved before.
According to the ACPI spec, the OS must disregrard reserved fields.
In order to know whether or not, we must know what version the SRAT
table has.
This patch stores the SRAT table revision for later consumption
by arch specific __init functions.
Signed-off-by: Kurt Garloff <kurt@garloff.de>
Signed-off-by: Len Brown <len.brown@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Shaohua Li [Tue, 10 Jan 2012 23:48:19 +0000 (15:48 -0800)]
intel_idle: fix API misuse
commit
39a74fdedd1c1461d6fb6d330b5266886513c98f upstream.
smp_call_function() only lets all other CPUs execute a specific function,
while we expect all CPUs do in intel_idle. Without the fix, we could have
one cpu which has auto_demotion enabled or has no broadcast timer setup.
Usually we don't see impact because auto demotion just harms power and the
intel_idle init is called in CPU 0, where boradcast timer delivers
interrupt, but this still could be a problem.
Signed-off-by: Shaohua Li <shaohua.li@intel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Len Brown <len.brown@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Thomas Renninger [Sun, 4 Dec 2011 21:17:29 +0000 (22:17 +0100)]
intel idle: Make idle driver more robust
commit
5c2a9f06a9cd7194f884cdc88144866235dec07d upstream.
kvm -cpu host passes the original cpuid info to the guest.
Latest kvm version seem to return true for mwait_leaf cpuid
function on recent Intel CPUs. But it does not return mwait
C-states (mwait_substates), instead zero is returned.
While real CPUs seem to always return non-zero values, the intel
idle driver should not get active in kvm (mwait_substates == 0)
case and bail out.
Otherwise a Null pointer exception will happen later when the
cpuidle subsystem tries to get active:
[0.984807] BUG: unable to handle kernel NULL pointer dereference at (null)
[0.984807] IP: [<(null)>] (null)
...
[0.984807][<
ffffffff8143cf34>] ? cpuidle_idle_call+0xb4/0x340
[0.984807][<
ffffffff8159e7bc>] ? __atomic_notifier_call_chain+0x4c/0x70
[0.984807][<
ffffffff81001198>] ? cpu_idle+0x78/0xd0
Reference:
https://bugzilla.novell.com/show_bug.cgi?id=726296
Signed-off-by: Thomas Renninger <trenn@suse.de>
CC: Bruno Friedmann <bruno@ioda-net.ch>
Signed-off-by: Len Brown <len.brown@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
David Henningsson [Mon, 16 Jan 2012 09:52:20 +0000 (10:52 +0100)]
ALSA: HDA: Fix internal microphone on Dell Studio 16 XPS 1645
commit
ffe535edb9a9c5b4d5fe03dfa3d89a1495580f1b upstream.
More than one user reports that changing the model from "both" to
"dmic" makes their Internal Mic work.
Tested-by: Martin Ling <martin-launchpad@earth.li>
BugLink: https://bugs.launchpad.net/bugs/795823
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Clemens Ladisch [Sat, 14 Jan 2012 15:42:24 +0000 (16:42 +0100)]
ALSA: virtuoso: Xonar DS: fix polarity of front output
commit
f0e48b6bd4e407459715240cd241ddb6b89bdf81 upstream.
The two DACs for the front output and the surround/center/LFE/back
outputs are wired up out of phase, so when channels are duplicated,
their sound can cancel out each other and result in a weaker bass
response. To fix this, reverse the polarity of the neutron flow to
the front output.
Reported-any-tested-by: Daniel Hill <daniel@enemyplanet.geek.nz>
Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Linus Torvalds [Tue, 17 Jan 2012 23:21:19 +0000 (15:21 -0800)]
proc: clean up and fix /proc/<pid>/mem handling
commit
e268337dfe26dfc7efd422a804dbb27977a3cccc upstream.
Jüri Aedla reported that the /proc/<pid>/mem handling really isn't very
robust, and it also doesn't match the permission checking of any of the
other related files.
This changes it to do the permission checks at open time, and instead of
tracking the process, it tracks the VM at the time of the open. That
simplifies the code a lot, but does mean that if you hold the file
descriptor open over an execve(), you'll continue to read from the _old_
VM.
That is different from our previous behavior, but much simpler. If
somebody actually finds a load where this matters, we'll need to revert
this commit.
I suspect that nobody will ever notice - because the process mapping
addresses will also have changed as part of the execve. So you cannot
actually usefully access the fd across a VM change simply because all
the offsets for IO would have changed too.
Reported-by: Jüri Aedla <asd@ut.ee>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Paolo Bonzini [Thu, 12 Jan 2012 15:01:29 +0000 (16:01 +0100)]
dm: do not forward ioctls from logical volumes to the underlying device
commit
ec8013beddd717d1740cfefb1a9b900deef85462 upstream.
A logical volume can map to just part of underlying physical volume.
In this case, it must be treated like a partition.
Based on a patch from Alasdair G Kergon.
Cc: Alasdair G Kergon <agk@redhat.com>
Cc: dm-devel@redhat.com
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Paolo Bonzini [Thu, 12 Jan 2012 15:01:28 +0000 (16:01 +0100)]
block: fail SCSI passthrough ioctls on partition devices
commit
0bfc96cb77224736dfa35c3c555d37b3646ef35e upstream.
[ Changes with respect to 3.3: return -ENOTTY from scsi_verify_blk_ioctl
and -ENOIOCTLCMD from sd_compat_ioctl. ]
Linux allows executing the SG_IO ioctl on a partition or LVM volume, and
will pass the command to the underlying block device. This is
well-known, but it is also a large security problem when (via Unix
permissions, ACLs, SELinux or a combination thereof) a program or user
needs to be granted access only to part of the disk.
This patch lets partitions forward a small set of harmless ioctls;
others are logged with printk so that we can see which ioctls are
actually sent. In my tests only CDROM_GET_CAPABILITY actually occurred.
Of course it was being sent to a (partition on a) hard disk, so it would
have failed with ENOTTY and the patch isn't changing anything in
practice. Still, I'm treating it specially to avoid spamming the logs.
In principle, this restriction should include programs running with
CAP_SYS_RAWIO. If for example I let a program access /dev/sda2 and
/dev/sdb, it still should not be able to read/write outside the
boundaries of /dev/sda2 independent of the capabilities. However, for
now programs with CAP_SYS_RAWIO will still be allowed to send the
ioctls. Their actions will still be logged.
This patch does not affect the non-libata IDE driver. That driver
however already tests for bd != bd->bd_contains before issuing some
ioctl; it could be restricted further to forbid these ioctls even for
programs running with CAP_SYS_ADMIN/CAP_SYS_RAWIO.
Cc: linux-scsi@vger.kernel.org
Cc: Jens Axboe <axboe@kernel.dk>
Cc: James Bottomley <JBottomley@parallels.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
[ Make it also print the command name when warning - Linus ]
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Paolo Bonzini [Thu, 12 Jan 2012 15:01:27 +0000 (16:01 +0100)]
block: add and use scsi_blk_cmd_ioctl
commit
577ebb374c78314ac4617242f509e2f5e7156649 upstream.
Introduce a wrapper around scsi_cmd_ioctl that takes a block device.
The function will then be enhanced to detect partition block devices
and, in that case, subject the ioctls to whitelisting.
Cc: linux-scsi@vger.kernel.org
Cc: Jens Axboe <axboe@kernel.dk>
Cc: James Bottomley <JBottomley@parallels.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Martin Schwidefsky [Thu, 15 Dec 2011 13:56:10 +0000 (14:56 +0100)]
fix cputime overflow in uptime_proc_show
commit
c3e0ef9a298e028a82ada28101ccd5cf64d209ee upstream.
For 32-bit architectures using standard jiffies the idletime calculation
in uptime_proc_show will quickly overflow. It takes (2^32 / HZ) seconds
of idle-time, or e.g. 12.45 days with no load on a quad-core with HZ=1000.
Switch to 64-bit calculations.
Cc: Michael Abbott <michael.abbott@diamond.ac.uk>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Benjamin Tissoires [Fri, 23 Dec 2011 14:41:00 +0000 (15:41 +0100)]
HID: multitouch: add support for 3M 32"
commit
c4fad877cd0efb51d8180ae2eaa791c99c92051c upstream.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Acked-by: Henrik Rydberg <rydberg@euromail.se>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Benjamin Tissoires [Wed, 23 Nov 2011 09:54:33 +0000 (10:54 +0100)]
HID: multitouch: add support for the MSI Windpad 110W
commit
66f06127f34ad6e8a1b24a2c03144b694d19f99f upstream.
Just another eGalax device.
Please note that adding this device to have_special_driver
in hid-core.c is not required anymore.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@enac.fr>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Marek Vasut [Wed, 23 Nov 2011 09:54:32 +0000 (10:54 +0100)]
HID: multitouch: Add egalax ID for Acer Iconia W500
commit
bb9ff21072043634f147c05ac65dbf8185d4af6d upstream.
This patch adds USB ID for the touchpanel in Acer Iconia W500. The panel
supports up to five fingers, therefore the need for a new addition of panel
types.
Signed-off-by: Marek Vasut <marek.vasut@gmail.com>
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@enac.fr>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Benjamin Tissoires [Wed, 23 Nov 2011 09:54:31 +0000 (10:54 +0100)]
HID: multitouch: cleanup with eGalax PID definitions
commit
e36f690b37945e0a9bb1554e1546eeec93f7d1f6 upstream.
This is just a renaming of USB_DEVICE_ID_DWAV_EGALAX_MULTITOUCH{N}
to USB_DEVICE_ID_DWAV_EGALAX_MULTITOUCH_{PID} to handle more eGalax
devices.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@enac.fr>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Chris Bagwell [Wed, 23 Nov 2011 09:54:27 +0000 (10:54 +0100)]
HID: hid-multitouch - add another eGalax id
commit
1fd8f047490dd0ec4e4db710fcbc1bd4798d944c upstream.
This allows ASUS Eee Slate touchscreens to work.
Signed-off-by: Chris Bagwell <chris@cnpbagwell.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Nick Bowler [Tue, 8 Nov 2011 12:12:45 +0000 (12:12 +0000)]
ah: Read nexthdr value before overwriting it in ahash input callback.
commit
b7ea81a58adc123a4e980cb0eff9eb5c144b5dc7 upstream.
The AH4/6 ahash input callbacks read out the nexthdr field from the AH
header *after* they overwrite that header. This is obviously not going
to end well. Fix it up.
Signed-off-by: Nick Bowler <nbowler@elliptictech.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Nick Bowler [Tue, 8 Nov 2011 12:12:44 +0000 (12:12 +0000)]
ah: Correctly pass error codes in ahash output callback.
commit
069294e813ed5f27f82613b027609bcda5f1b914 upstream.
The AH4/6 ahash output callbacks pass nexthdr to xfrm_output_resume
instead of the error code. This appears to be a copy+paste error from
the input case, where nexthdr is expected. This causes the driver to
continuously add AH headers to the datagram until either an allocation
fails and the packet is dropped or the ahash driver hits a synchronous
fallback and the resulting monstrosity is transmitted.
Correct this issue by simply passing the error code unadulterated.
Signed-off-by: Nick Bowler <nbowler@elliptictech.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Miklos Szeredi [Tue, 10 Jan 2012 17:22:25 +0000 (18:22 +0100)]
fix shrink_dcache_parent() livelock
commit
eaf5f9073533cde21c7121c136f1c3f072d9cf59 upstream.
Two (or more) concurrent calls of shrink_dcache_parent() on the same dentry may
cause shrink_dcache_parent() to loop forever.
Here's what appears to happen:
1 - CPU0: select_parent(P) finds C and puts it on dispose list, returns 1
2 - CPU1: select_parent(P) locks P->d_lock
3 - CPU0: shrink_dentry_list() locks C->d_lock
dentry_kill(C) tries to lock P->d_lock but fails, unlocks C->d_lock
4 - CPU1: select_parent(P) locks C->d_lock,
moves C from dispose list being processed on CPU0 to the new
dispose list, returns 1
5 - CPU0: shrink_dentry_list() finds dispose list empty, returns
6 - Goto 2 with CPU0 and CPU1 switched
Basically select_parent() steals the dentry from shrink_dentry_list() and thinks
it found a new one, causing shrink_dentry_list() to think it's making progress
and loop over and over.
One way to trigger this is to make udev calls stat() on the sysfs file while it
is going away.
Having a file in /lib/udev/rules.d/ with only this one rule seems to the trick:
ATTR{vendor}=="0x8086", ATTR{device}=="0x10ca", ENV{PCI_SLOT_NAME}="%k", ENV{MATCHADDR}="$attr{address}", RUN+="/bin/true"
Then execute the following loop:
while true; do
echo -bond0 > /sys/class/net/bonding_masters
echo +bond0 > /sys/class/net/bonding_masters
echo -bond1 > /sys/class/net/bonding_masters
echo +bond1 > /sys/class/net/bonding_masters
done
One fix would be to check all callers and prevent concurrent calls to
shrink_dcache_parent(). But I think a better solution is to stop the
stealing behavior.
This patch adds a new dentry flag that is set when the dentry is added to the
dispose list. The flag is cleared in dentry_lru_del() in case the dentry gets a
new reference just before being pruned.
If the dentry has this flag, select_parent() will skip it and let
shrink_dentry_list() retry pruning it. With select_parent() skipping those
dentries there will not be the appearance of progress (new dentries found) when
there is none, hence shrink_dcache_parent() will not loop forever.
Set the flag is also set in prune_dcache_sb() for consistency as suggested by
Linus.
Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Haogang Chen [Tue, 29 Nov 2011 21:32:25 +0000 (18:32 -0300)]
uvcvideo: Fix integer overflow in uvc_ioctl_ctrl_map()
commit
806e23e95f94a27ee445022d724060b9b45cb64a upstream.
There is a potential integer overflow in uvc_ioctl_ctrl_map(). When a
large xmap->menu_count is passed from the userspace, the subsequent call
to kmalloc() will allocate a buffer smaller than expected.
map->menu_count and map->menu_info would later be used in a loop (e.g.
in uvc_query_v4l2_ctrl), which leads to out-of-bound access.
The patch checks the ioctl argument and returns -EINVAL for zero or too
large values in xmap->menu_count.
Signed-off-by: Haogang Chen <haogangchen@gmail.com>
[laurent.pinchart@ideasonboard.com Prevent excessive memory consumption]
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
David Daney [Tue, 20 Dec 2011 01:42:42 +0000 (17:42 -0800)]
recordmcount: Fix handling of elf64 big-endian objects.
commit
2e885057b7f75035f0b85e02f737891482815a81 upstream.
In ELF64, the sh_flags field is 64-bits wide. recordmcount was
erroneously treating it as a 32-bit wide field. For little endian
objects this works because the flags of interest (SHF_EXECINSTR)
reside in the lower 32 bits of the word, and you get the same result
with either a 32-bit or 64-bit read. Big endian objects on the
other hand do not work at all with this error.
The fix: Correctly treat sh_flags as 64-bits wide in elf64 objects.
The symptom I observed was that my
__start_mcount_loc..__stop_mcount_loc was empty even though ftrace
function tracing was enabled.
Link: http://lkml.kernel.org/r/1324345362-12230-1-git-send-email-ddaney.cavm@gmail.com
Signed-off-by: David Daney <david.daney@cavium.com>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Jack Steiner [Fri, 6 Jan 2012 19:19:00 +0000 (13:19 -0600)]
x86, UV: Update Boot messages for SGI UV2 platform
commit
da517a08ac5913cd80ce3507cddd00f2a091b13c upstream.
SGI UV systems print a message during boot:
UV: Found <num> blades
Due to packaging changes, the blade count is not accurate for
on the next generation of the platform. This patch corrects the
count.
Signed-off-by: Jack Steiner <steiner@sgi.com>
Link: http://lkml.kernel.org/r/20120106191900.GA19772@sgi.com
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Miklos Szeredi [Thu, 12 Jan 2012 16:59:46 +0000 (17:59 +0100)]
fsnotify: don't BUG in fsnotify_destroy_mark()
commit
fed474857efbed79cd390d0aee224231ca718f63 upstream.
Removing the parent of a watched file results in "kernel BUG at
fs/notify/mark.c:139".
To reproduce
add "-w /tmp/audit/dir/watched_file" to audit.rules
rm -rf /tmp/audit/dir
This is caused by fsnotify_destroy_mark() being called without an
extra reference taken by the caller.
Reported by Francesco Cosoleto here:
https://bugzilla.novell.com/show_bug.cgi?id=689860
Fix by removing the BUG_ON and adding a comment about not accessing mark after
the iput.
Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>