françois romieu [Mon, 8 Nov 2010 13:23:58 +0000 (13:23 +0000)]
r8169: fix sleeping while holding spinlock.
[ Upstream commit
ea80907ff066edd1dd43c5fe90ae6677d15e6384 ]
As device_set_wakeup_enable can now sleep, move the call to outside
the critical section.
Signed-off-by: Daniel J Blueman <daniel.blueman@gmail.com>
Acked-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Andrew Hendry <andrew.hendry@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Shan Wei [Wed, 17 Nov 2010 19:55:08 +0000 (11:55 -0800)]
8139cp: fix checksum broken
[ Upstream commit
24b7ea9f6c9787fad885442ed0cc010f1aa69cca ]
I am not family with RealTek RTL-8139C+ series 10/100 PCI Ethernet driver.
I try to guess the meaning of RxProtoIP and IPFail.
RxProtoIP stands for received IPv4 packet that upper protocol is not tcp and udp.
!(status & IPFail) is true means that driver correctly to check checksum in IPv4 header.
If these are right, driver will set ip_summed with CHECKSUM_UNNECESSARY for other
upper protocol, e.g. sctp, igmp protocol. This will cause protocol stack ignores
checksum check for packets with invalid checksum.
This patch is only compile-test.
Signed-off-by: Shan Wei <shanwei@cn.fujitsu.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Eric Dumazet [Tue, 7 Dec 2010 12:20:47 +0000 (12:20 +0000)]
tcp: protect sysctl_tcp_cookie_size reads
[ Upstream commit
f19872575ff7819a3723154657a497d9bca66b33 ]
Make sure sysctl_tcp_cookie_size is read once in
tcp_cookie_size_check(), or we might return an illegal value to caller
if sysctl_tcp_cookie_size is changed by another cpu.
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Cc: Ben Hutchings <bhutchings@solarflare.com>
Cc: William Allen Simpson <william.allen.simpson@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Eric Dumazet [Tue, 7 Dec 2010 12:03:55 +0000 (12:03 +0000)]
tcp: avoid a possible divide by zero
[ Upstream commit
ad9f4f50fe9288bbe65b7dfd76d8820afac6a24c ]
sysctl_tcp_tso_win_divisor might be set to zero while one cpu runs in
tcp_tso_should_defer(). Make sure we dont allow a divide by zero by
reading sysctl_tcp_tso_win_divisor exactly once.
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@suse.de>
Nandita Dukkipati [Fri, 3 Dec 2010 13:33:44 +0000 (13:33 +0000)]
tcp: Bug fix in initialization of receive window.
[ Upstream commit
b1afde60f2b9ee8444fba4e012dc99a3b28d224d ]
The bug has to do with boundary checks on the initial receive window.
If the initial receive window falls between init_cwnd and the
receive window specified by the user, the initial window is incorrectly
brought down to init_cwnd. The correct behavior is to allow it to
remain unchanged.
Signed-off-by: Nandita Dukkipati <nanditad@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
David S. Miller [Wed, 24 Nov 2010 19:47:22 +0000 (11:47 -0800)]
tcp: Make TCP_MAXSEG minimum more correct.
[ Upstream commit
c39508d6f118308355468314ff414644115a07f3 ]
Use TCP_MIN_MSS instead of constant 64.
Reported-by: Min Zhang <mzhang@mvista.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
David S. Miller [Thu, 11 Nov 2010 05:35:37 +0000 (21:35 -0800)]
tcp: Increase TCP_MAXSEG socket option minimum.
[ Upstream commit
7a1abd08d52fdeddb3e9a5a33f2f15cc6a5674d2 ]
As noted by Steve Chen, since commit
f5fff5dc8a7a3f395b0525c02ba92c95d42b7390 ("tcp: advertise MSS
requested by user") we can end up with a situation where
tcp_select_initial_window() does a divide by a zero (or
even negative) mss value.
The problem is that sometimes we effectively subtract
TCPOLEN_TSTAMP_ALIGNED and/or TCPOLEN_MD5SIG_ALIGNED from the mss.
Fix this by increasing the minimum from 8 to 64.
Reported-by: Steve Chen <schen@mvista.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
David S. Miller [Fri, 12 Nov 2010 21:35:00 +0000 (13:35 -0800)]
tcp: Don't change unlocked socket state in tcp_v4_err().
[ Upstream commit
8f49c2703b33519aaaccc63f571b465b9d2b3a2d ]
Alexey Kuznetsov noticed a regression introduced by
commit
f1ecd5d9e7366609d640ff4040304ea197fbc618
("Revert Backoff [v3]: Revert RTO on ICMP destination unreachable")
The RTO and timer modification code added to tcp_v4_err()
doesn't check sock_owned_by_user(), which if true means we
don't have exclusive access to the socket and therefore cannot
modify it's critical state.
Just skip this new code block if sock_owned_by_user() is true
and eliminate the now superfluous sock_owned_by_user() code
block contained within.
Reported-by: Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>
Signed-off-by: David S. Miller <davem@davemloft.net>
CC: Damian Lukowski <damian@tvk.rwth-aachen.de>
Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
David S. Miller [Wed, 1 Dec 2010 04:15:58 +0000 (20:15 -0800)]
sparc: Write to prom console using indirect buffer.
[ Upstream commit
595a251c0740785fd3c0d2156d78578c7479811e ]
sparc64 systems have a restriction in that passing in buffer
addressses above 4GB to prom calls is not reliable.
We end up violating this when we do prom console writes, because we
use an on-stack buffer to translate '\n' into '\r\n'.
So instead, do this translation into an intermediate buffer, which is
in the kernel image and thus below 4GB, then pass that to the PROM
console write calls.
On the 32-bit side we don't have to deal with any of these issues, so
the new prom_console_write_buf() uses the existing prom_nbputchar()
implementation. However we can now mark those routines static.
Since the 64-bit side completely uses new code we can delete the
putchar bits as they are now completely unused.
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
David S. Miller [Tue, 30 Nov 2010 22:53:05 +0000 (14:53 -0800)]
sparc: Delete prom_*getchar().
[ Upstream commit
12c7a35ee6a1c605e740733f2cbd5b5079f09f0f ]
Completely unused.
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
David S. Miller [Tue, 30 Nov 2010 22:33:29 +0000 (14:33 -0800)]
sparc: Pass buffer pointer all the way down to prom_{get,put}char().
[ Upstream commit
e62cac1fd035b4cde707285008499dbe71955a86 ]
This gets us closer to being able to eliminate the use
of dynamic and stack based buffers, so that we can adhere
to the "no buffer addresses above 4GB" rule for PROM calls.
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
David S. Miller [Wed, 17 Nov 2010 18:22:56 +0000 (10:22 -0800)]
sparc: Do not export prom_nb{get,put}char().
[ Upstream commit
91921fef7c658b12de53376b312d071d757f7770 ]
Never used outside of console_{32,64}.c
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
David S. Miller [Tue, 16 Nov 2010 20:50:19 +0000 (12:50 -0800)]
sparc64: Delete prom_setcallback().
[ Upstream commit
c540ee70e49b573535c7ddfd0e9a0fc9d549c8b7 ]
Unused.
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
David S. Miller [Tue, 16 Nov 2010 20:24:16 +0000 (12:24 -0800)]
sparc64: Unexport prom_service_exists().
[ Upstream commit
f7b5f55ac1623dfde24ef5319ad77c1746645f3f ]
Only used by functions in misc_64.c so make it private
to that file.
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
David S. Miller [Tue, 16 Nov 2010 20:23:20 +0000 (12:23 -0800)]
sparc: Kill prom devops_{32,64}.c
[ Upstream commit
b148246912bea92bde2a0cba125ca94f1f776b12 ]
Completely unused.
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
David S. Miller [Tue, 16 Nov 2010 20:11:15 +0000 (12:11 -0800)]
sparc: Remove prom_pathtoinode()
[ Upstream commit
17d70d6df0c4ea7a203b444001572a91ad9c2bef ]
Unused.
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
David S. Miller [Tue, 16 Nov 2010 20:08:23 +0000 (12:08 -0800)]
sparc64: Delete prom_puts() unused.
[ Upstream commit
ce05a94efaf71d562eeefd30d6bbc2ab42b06bac ]
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Daniel Hellstrom [Fri, 29 Oct 2010 20:25:24 +0000 (13:25 -0700)]
SPARC/LEON: removed constant timer initialization as if HZ=100, now it reflects the value of HZ
[ Upstream commit
b690c425fe07c725e7f1f7d40303588416cba67f ]
Signed-off-by: Daniel Hellstrom <daniel@gaisler.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Helmut Schaa [Thu, 2 Dec 2010 17:44:09 +0000 (18:44 +0100)]
mac80211: Fix BUG in pskb_expand_head when transmitting shared skbs
commit
7e2447075690860e2cea96b119fc9cadbaa7e83c upstream.
mac80211 doesn't handle shared skbs correctly at the moment. As a result
a possible resize can trigger a BUG in pskb_expand_head.
[ 676.030000] Kernel bug detected[#1]:
[ 676.030000] Cpu 0
[ 676.030000] $ 0 :
00000000 00000000 819662ff 00000002
[ 676.030000] $ 4 :
81966200 00000020 00000000 00000020
[ 676.030000] $ 8 :
819662e0 800043c0 00000002 00020000
[ 676.030000] $12 :
3b9aca00 00000000 00000000 00470000
[ 676.030000] $16 :
80ea2000 00000000 00000000 00000000
[ 676.030000] $20 :
818aa200 80ea2018 80ea2000 00000008
[ 676.030000] $24 :
00000002 800ace5c
[ 676.030000] $28 :
8199a000 8199bd20 81938f88 80f180d4
[ 676.030000] Hi :
0000026e
[ 676.030000] Lo :
0000757e
[ 676.030000] epc :
801245e4 pskb_expand_head+0x44/0x1d8
[ 676.030000] Not tainted
[ 676.030000] ra :
80f180d4 ieee80211_skb_resize+0xb0/0x114 [mac80211]
[ 676.030000] Status:
1000a403 KERNEL EXL IE
[ 676.030000] Cause :
10800024
[ 676.030000] PrId :
0001964c (MIPS 24Kc)
[ 676.030000] Modules linked in: mac80211_hwsim rt2800lib rt2x00soc rt2x00pci rt2x00lib mac80211 crc_itu_t crc_ccitt cfg80211 compat arc4 aes_generic deflate ecb cbc [last unloaded: rt2800pci]
[ 676.030000] Process kpktgend_0 (pid: 97, threadinfo=
8199a000, task=
81879f48, tls=
00000000)
[ 676.030000] Stack :
ffffffff 00000000 00000000 00000014 00000004 80ea2000 00000000 00000000
[ 676.030000]
818aa200 80f180d4 ffffffff 0000000a 81879f78 81879f48 81879f48 00000018
[ 676.030000]
81966246 80ea2000 818432e0 80f1a420 80203050 81814d98 00000001 81879f48
[ 676.030000]
81879f48 00000018 81966246 818432e0 0000001a 8199bdd4 0000001c 80f1b72c
[ 676.030000]
80203020 8001292c 80ef4aa2 7f10b55d 801ab5b8 81879f48 00000188 80005c90
[ 676.030000] ...
[ 676.030000] Call Trace:
[ 676.030000] [<
801245e4>] pskb_expand_head+0x44/0x1d8
[ 676.030000] [<
80f180d4>] ieee80211_skb_resize+0xb0/0x114 [mac80211]
[ 676.030000] [<
80f1a420>] ieee80211_xmit+0x150/0x22c [mac80211]
[ 676.030000] [<
80f1b72c>] ieee80211_subif_start_xmit+0x6f4/0x73c [mac80211]
[ 676.030000] [<
8014361c>] pktgen_thread_worker+0xfac/0x16f8
[ 676.030000] [<
8002ebe8>] kthread+0x7c/0x88
[ 676.030000] [<
80008e0c>] kernel_thread_helper+0x10/0x18
[ 676.030000]
[ 676.030000]
[ 676.030000] Code:
24020001 10620005 2502001f <
0200000d>
0804917a 00000000 2502001f 00441023 00531021
Fix this by making a local copy of shared skbs prior to mangeling them.
To avoid copying the skb unnecessarily move the skb_copy call below the
checks that don't need write access to the skb.
Also, move the assignment of nh_pos and h_pos below the skb_copy to point
to the correct skb.
It would be possible to avoid another resize of the copied skb by using
skb_copy_expand instead of skb_copy but that would make the patch more
complex. Also, shared skbs are a corner case right now, so the resize
shouldn't matter much.
Cc: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Matteo Croce [Fri, 3 Dec 2010 01:25:08 +0000 (02:25 +0100)]
ath9k: fix bug in tx power
commit
841051602e3fa18ea468fe5a177aa92b6eb44b56 upstream.
The ath9k driver subtracts 3 dBm to the txpower as with two radios the
signal power is doubled.
The resulting value is assigned in an u16 which overflows and makes
the card work at full power.
Signed-off-by: Matteo Croce <matteo@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Felix Fietkau [Wed, 1 Dec 2010 18:07:46 +0000 (19:07 +0100)]
ath9k_hw: fix endian issues with CTLs on AR9003
commit
e702ba18f25887c76d26c8a85cc1706463c62e9a upstream.
Parsing data using bitfields is messy, because it makes endian handling
much harder. AR9002 and earlier got it right, AR9003 got it wrong.
This might lead to either using too high or too low tx power values,
depending on frequency and eeprom settings.
Fix it by getting rid of the CTL related bitfields entirely and use
masks instead.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Vasanthakumar Thiagarajan [Wed, 1 Dec 2010 07:24:09 +0000 (23:24 -0800)]
ath9k: Fix bug in reading input gpio state for ar9003
commit
9306990a656d9cfd8bf3586938012729c1f2ea50 upstream.
The register which gives input gpio state is 0x404c for ar9003,
currently 0x4048 is wrongly used. This will disable RF and make
it unusable on some of AR9003.
Signed-off-by: Vasanthakumar Thiagarajan <vasanth@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Senthil Balasubramanian [Tue, 30 Nov 2010 14:45:39 +0000 (20:15 +0530)]
ath9k: Fix STA disconnect issue due to received MIC failed bcast frames
commit
916448e77f6bcaaa7f13c3de0c3851783ae2bfd0 upstream.
AR_RxKeyIdxValid will not be set for bcast/mcast frames and so relying
this status for MIC failed frames is buggy.
Due to this, MIC failure events for broadcast frames are not sent to
supplicant resulted in AP disconnecting the STA.
Able to pass Wifi Test case 5.2.18 with this fix.
Signed-off-by: Senthil Balasubramanian <senthilkumar@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Rajkumar Manoharan [Fri, 26 Nov 2010 17:54:31 +0000 (23:24 +0530)]
ath9k: Disable SWBA interrupt on remove_interface
commit
46047784b8cdcfc916f6c1cccee0c18dd1223dfd upstream.
while removing beaconing mode interface, SWBA interrupt
was never disabled when there are no other beaconing interfaces.
Signed-off-by: Rajkumar Manoharan <rmanoharan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Eric Dumazet [Sun, 5 Dec 2010 02:03:26 +0000 (02:03 +0000)]
llc: fix a device refcount imbalance
commit
35d9b0c906ad92d32a0b8db5daa6fabfcc2f068d upstream.
Le dimanche 05 décembre 2010 à 12:23 +0100, Eric Dumazet a écrit :
> Le dimanche 05 décembre 2010 à 09:19 +0100, Eric Dumazet a écrit :
>
> > Hmm..
> >
> > If somebody can explain why RTNL is held in arp_ioctl() (and therefore
> > in arp_req_delete()), we might first remove RTNL use in arp_ioctl() so
> > that your patch can be applied.
> >
> > Right now it is not good, because RTNL wont be necessarly held when you
> > are going to call arp_invalidate() ?
>
> While doing this analysis, I found a refcount bug in llc, I'll send a
> patch for net-2.6
Oh well, of course I must first fix the bug in net-2.6, and wait David
pull the fix in net-next-2.6 before sending this rcu conversion.
Note: this patch should be sent to stable teams (2.6.34 and up)
[PATCH net-2.6] llc: fix a device refcount imbalance
commit
abf9d537fea225 (llc: add support for SO_BINDTODEVICE) added one
refcount imbalance in llc_ui_bind(), because dev_getbyhwaddr() doesnt
take a reference on device, while dev_get_by_index() does.
Fix this using RCU locking. And since an RCU conversion will be done for
2.6.38 for dev_getbyhwaddr(), put the rcu_read_lock/unlock exactly at
their final place.
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Cc: Octavian Purdila <opurdila@ixiacom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Mike Hernandez [Wed, 24 Nov 2010 00:52:46 +0000 (16:52 -0800)]
qla2xxx: Populate Command Type 6 LUN field properly.
commit
85727e1f78bd8392a0657ad6a4ff85fef1cc4a6d upstream.
Use the host_to_fcp_swap call to correctly populate the LUN field
in the Command Type 6 path. This field is used during LUN reset
cleanup and must match the field used in the FCP command.
Signed-off-by: Mike Hernandez <michael.hernandez@qlogic.com>
Signed-off-by: Madhuranath Iyengar <Madhu.Iyengar@qlogic.com>
Signed-off-by: James Bottomley <James.Bottomley@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Andrew Vasquez [Wed, 24 Nov 2010 00:52:48 +0000 (16:52 -0800)]
qla2xxx: Correct issue where NPIV-config data was not being allocated for 82xx parts.
commit
087c621e22f49c326cdc65d98c6fc0737ac13533 upstream.
This would cause a panic while reading the NPIV-config data.
Signed-off-by: Andrew Vasquez <andrew.vasquez@qlogic.com>
Signed-off-by: Madhuranath Iyengar <Madhu.Iyengar@qlogic.com>
Signed-off-by: James Bottomley <James.Bottomley@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Valentine Barshak [Mon, 13 Dec 2010 23:03:16 +0000 (00:03 +0100)]
ARM: 6535/1: V6 MPCore v6_dma_inv_range and v6_dma_flush_range RWFO fix
commit
85b093bcc5322baa811a03ec73de0909c157f181 upstream.
Cache ownership must be acquired by reading/writing data from the
cache line to make cache operation have the desired effect on the
SMP MPCore CPU. However, the ownership is never acquired in the
v6_dma_inv_range function when cleaning the first line and
flushing the last one, in case the address is not aligned
to D_CACHE_LINE_SIZE boundary.
Fix this by reading/writing data if needed, before performing
cache operations.
While at it, fix v6_dma_flush_range to prevent RWFO outside
the buffer.
Signed-off-by: Valentine Barshak <vbarshak@mvista.com>
Signed-off-by: George G. Davis <gdavis@mvista.com>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Takashi Iwai [Thu, 9 Dec 2010 23:16:39 +0000 (00:16 +0100)]
PM / Hibernate: Fix PM_POST_* notification with user-space suspend
commit
1497dd1d29c6a53fcd3c80f7ac8d0e0239e7389e upstream.
The user-space hibernation sends a wrong notification after the image
restoration because of thinko for the file flag check. RDONLY
corresponds to hibernation and WRONLY to restoration, confusingly.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Dan Carpenter [Wed, 13 Oct 2010 09:13:12 +0000 (09:13 +0000)]
IB/uverbs: Handle large number of entries in poll CQ
commit
7182afea8d1afd432a17c18162cc3fd441d0da93 upstream.
In ib_uverbs_poll_cq() code there is a potential integer overflow if
userspace passes in a large cmd.ne. The calls to kmalloc() would
allocate smaller buffers than intended, leading to memory corruption.
There iss also an information leak if resp wasn't all used.
Unprivileged userspace may call this function, although only if an
RDMA device that uses this function is present.
Fix this by copying CQ entries one at a time, which avoids the
allocation entirely, and also by moving this copying into a function
that makes sure to initialize all memory copied to userspace.
Special thanks to Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
for his help and advice.
Signed-off-by: Dan Carpenter <error27@gmail.com>
[ Monkey around with things a bit to avoid bad code generation by gcc
when designated initializers are used. - Roland ]
Signed-off-by: Roland Dreier <rolandd@cisco.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Suresh Siddha [Tue, 16 Nov 2010 21:23:51 +0000 (13:23 -0800)]
x86, xsave: Use alloc_bootmem_align() instead of alloc_bootmem()
commit
10340ae130fb70352eae1ae8a00b7906d91bf166 upstream.
Alignment of alloc_bootmem() depends on the value of
L1_CACHE_SHIFT. What we need here, however, is 64 byte alignment. Use
alloc_bootmem_align() and explicitly specify the alignment instead.
This fixes a kernel boot crash reported by Jody when the cpu in .config
is set to MPENTIUMII but the kernel is booted on a xsave-capable CPU.
Reported-by: Jody Bruchon <jody@nctritech.com>
Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com>
LKML-Reference: <
20101116212442.
059967454@sbsiddha-MOBL3.sc.intel.com>
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Suresh Siddha [Tue, 16 Nov 2010 21:23:50 +0000 (13:23 -0800)]
bootmem: Add alloc_bootmem_align()
commit
53dde5f385bc56e312f78b7cb25ffaf8efd4735d upstream.
Add an alloc_bootmem_align() interface to allocate bootmem with
specified alignment. This is necessary to be able to allocate the
xsave area in a subsequent patch.
Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com>
LKML-Reference: <
20101116212441.
977574826@sbsiddha-MOBL3.sc.intel.com>
Acked-by: H. Peter Anvin <hpa@linux.intel.com>
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Dmitry Artamonow [Wed, 8 Dec 2010 20:36:17 +0000 (23:36 +0300)]
ASoC: fix deemphasis control in wm8904/55/60 codecs
commit
3f343f8512c7882a3637d9aea4ec6b3801cbcdc5 upstream.
Deemphasis control's .get callback should update control's value instead
of returning it - return value of callback function is used for indicating
error or success of operation.
Signed-off-by: Dmitry Artamonow <mad_soft@inbox.ru>
Acked-by: Liam Girdwood <lrg@slimlogic.co.uk>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Seungwhan Youn [Thu, 9 Dec 2010 09:07:52 +0000 (18:07 +0900)]
ASoC: WM8580: Fix R8 initial value
commit
a0968628097380be52db8b4664da98fc425546a5 upstream.
Acc to WM8580 manual, the default value for R8 is 0x10, not 0x1c.
Signed-off-by: Seungwhan Youn <sw.youn@samsung.com>
Acked-by: Liam Girdwood <lrg@slimlogic.co.uk>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Uk Kim [Sun, 5 Dec 2010 08:32:16 +0000 (17:32 +0900)]
ASoC: Fix off by one error in WM8994 EQ register bank size
commit
3fcc0afbb9c93f3599ba03273e59915670b6c2c2 upstream.
Signed-off-by: Uk Kim <w0806.kim@samsung.com>
Acked-by: Liam Girdwood <lrg@slimlogic.co.uk>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Uk Kim [Sun, 5 Dec 2010 08:26:07 +0000 (17:26 +0900)]
ASoC: Fix swap of left and right channels for WM8993/4 speaker boost gain
commit
ed8cc471d75365f8590c76f580def899d58028c0 upstream.
SPKOUTL_BOOST start from third bit, SPKOUTLR_BOOST start from 0 bit.
Signed-off-by: Uk Kim <w0806.kim@samsung.com>
Acked-by: Liam Girdwood <lrg@slimlogic.co.uk>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Borislav Petkov [Mon, 6 Dec 2010 15:20:25 +0000 (16:20 +0100)]
amd64_edac: Fix interleaving check
commit
e726f3c368e7c1919a7166ec09c5705759f1a69d upstream.
When matching error address to the range contained by one memory node,
we're in valid range when node interleaving
1. is disabled, or
2. enabled and when the address bits we interleave on match the
interleave selector on this node (see the "Node Interleaving" section in
the BKDG for an enlightening example).
Thus, when we early-exit, we need to reverse the compound logic
statement properly.
Signed-off-by: Borislav Petkov <borislav.petkov@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Borislav Petkov [Thu, 2 Dec 2010 16:48:35 +0000 (17:48 +0100)]
EDAC: Fix workqueue-related crashes
commit
bb31b3122c0dd07d2d958da17a50ad771ce79e2b upstream.
00740c58541b6087d78418cebca1fcb86dc6077d changed edac_core to
un-/register a workqueue item only if a lowlevel driver supplies a
polling routine. Normally, when we remove a polling low-level driver, we
go and cancel all the queued work. However, the workqueue unreg happens
based on the ->op_state setting, and edac_mc_del_mc() sets this to
OP_OFFLINE _before_ we cancel the work item, leading to NULL ptr oops on
the workqueue list.
Fix it by putting the unreg stuff in proper order.
Reported-and-tested-by: Tobias Karnat <tobias.karnat@googlemail.com>
LKML-Reference: <
1291201307.3029.21.camel@Tobias-Karnat>
Signed-off-by: Borislav Petkov <borislav.petkov@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Gabriele Gorla [Wed, 8 Dec 2010 15:27:22 +0000 (16:27 +0100)]
hwmon: (adm1026) Fix setting fan_div
commit
52bc9802ce849d0d287cc5fe76d06b0daa3986ca upstream.
Prevent setting fan_div from stomping on other fans that share the
same I2C register.
Signed-off-by: Gabriele Gorla <gorlik@penguintown.net>
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Gabriele Gorla [Wed, 8 Dec 2010 15:27:22 +0000 (16:27 +0100)]
hwmon: (adm1026) Allow 1 as a valid divider value
commit
8b0f1840a46449e1946fc88860ef3ec8d6b1c2c7 upstream.
Allow 1 as a valid div value as specified in the ADM1026 datasheet.
Signed-off-by: Gabriele Gorla <gorlik@penguintown.net>
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
NeilBrown [Tue, 16 Nov 2010 05:55:19 +0000 (16:55 +1100)]
sunrpc: prevent use-after-free on clearing XPT_BUSY
commit
ed2849d3ecfa339435818eeff28f6c3424300cec upstream.
When an xprt is created, it has a refcount of 1, and XPT_BUSY is set.
The refcount is *not* owned by the thread that created the xprt
(as is clear from the fact that creators never put the reference).
Rather, it is owned by the absence of XPT_DEAD. Once XPT_DEAD is set,
(And XPT_BUSY is clear) that initial reference is dropped and the xprt
can be freed.
So when a creator clears XPT_BUSY it is dropping its only reference and
so must not touch the xprt again.
However svc_recv, after calling ->xpo_accept (and so getting an XPT_BUSY
reference on a new xprt), calls svc_xprt_recieved. This clears
XPT_BUSY and then svc_xprt_enqueue - this last without owning a reference.
This is dangerous and has been seen to leave svc_xprt_enqueue working
with an xprt containing garbage.
So we need to hold an extra counted reference over that call to
svc_xprt_received.
For safety, any time we clear XPT_BUSY and then use the xprt again, we
first get a reference, and the put it again afterwards.
Note that svc_close_all does not need this extra protection as there are
no threads running, and the final free can only be called asynchronously
from such a thread.
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Sergey Vlasov [Sun, 28 Nov 2010 21:04:05 +0000 (21:04 +0000)]
NFS: Fix fcntl F_GETLK not reporting some conflicts
commit
21ac19d484a8ffb66f64487846c8d53afef04d2b upstream.
The commit
129a84de2347002f09721cda3155ccfd19fade40 (locks: fix F_GETLK
regression (failure to find conflicts)) fixed the posix_test_lock()
function by itself, however, its usage in NFS changed by the commit
9d6a8c5c213e34c475e72b245a8eb709258e968c (locks: give posix_test_lock
same interface as ->lock) remained broken - subsequent NFS-specific
locking code received F_UNLCK instead of the user-specified lock type.
To fix the problem, fl->fl_type needs to be saved before the
posix_test_lock() call and restored if no local conflicts were reported.
Reference: https://bugzilla.kernel.org/show_bug.cgi?id=23892
Tested-by: Alexander Morozov <amorozov@etersoft.ru>
Signed-off-by: Sergey Vlasov <vsu@altlinux.ru>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Neil Brown [Thu, 2 Dec 2010 00:14:30 +0000 (11:14 +1100)]
nfsd: Fix possible BUG_ON firing in set_change_info
commit
c1ac3ffcd0bc7e9617f62be8c7043d53ab84deac upstream.
If vfs_getattr in fill_post_wcc returns an error, we don't
set fh_post_change.
For NFSv4, this can result in set_change_info triggering a BUG_ON.
i.e. fh_post_saved being zero isn't really a bug.
So:
- instead of BUGging when fh_post_saved is zero, just clear ->atomic.
- if vfs_getattr fails in fill_post_wcc, take a copy of i_ctime anyway.
This will be used i seg_change_info, but not overly trusted.
- While we are there, remove the pointless 'if' statements in set_change_info.
There is no harm setting all the values.
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Chuck Lever [Fri, 10 Dec 2010 17:31:14 +0000 (12:31 -0500)]
NFS: Fix panic after nfs_umount()
commit
5b362ac3799ff4225c40935500f520cad4d7ed66 upstream.
After a few unsuccessful NFS mount attempts in which the client and
server cannot agree on an authentication flavor both support, the
client panics. nfs_umount() is invoked in the kernel in this case.
Turns out nfs_umount()'s UMNT RPC invocation causes the RPC client to
write off the end of the rpc_clnt's iostat array. This is because the
mount client's nrprocs field is initialized with the count of defined
procedures (two: MNT and UMNT), rather than the size of the client's
proc array (four).
The fix is to use the same initialization technique used by most other
upper layer clients in the kernel.
Introduced by commit
0b524123, which failed to update nrprocs when
support was added for UMNT in the kernel.
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=24302
BugLink: http://bugs.launchpad.net/bugs/683938
Reported-by: Stefan Bader <stefan.bader@canonical.com>
Tested-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Stefan Richter [Tue, 7 Dec 2010 19:32:40 +0000 (20:32 +0100)]
firewire: ohci: fix regression with Agere FW643 rev 06, disable MSI
commit
9993e0fe0f5f29c69e79efcb271ffc9843002985 upstream.
Agere FW643 rev 06, listed as "11c1:5901 (rev 06) (prog-if 10 [OHCI])",
produced SBP-2 I/O errors since kernel 2.6.36. Disabling MSI fixes it.
Since MSI work on Agere FW643-E (same vendor and device ID, but rev 07),
introduce a device revision field into firewire-ohci's quirks list so
that different quirks can be defined for older and newer revisions.
Reported-by: Jonathan Isom <jeisom@gmail.com>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Stefan Richter [Tue, 7 Dec 2010 18:16:02 +0000 (19:16 +0100)]
firewire: ohci: fix regression with VIA VT6315, disable MSI
commit
af0cdf4947818becfe209610b209315578645ab4 upstream.
"VIA Technologies, Inc. VT6315 Series Firewire Controller [1106:3403]"
does not generate any interrupts if Message Signaled Interrupts were
enabled. This is a regression since kernel 2.6.36 in which MSI support
was added to firewire-ohci. Hence blacklist MSI on all VIA controllers.
Reported-by: Robin Cook <rcook@wyrms.net>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Heiko Carstens [Wed, 1 Dec 2010 09:11:09 +0000 (10:11 +0100)]
nohz: Fix get_next_timer_interrupt() vs cpu hotplug
commit
dbd87b5af055a0cc9bba17795c9a2b0d17795389 upstream.
This fixes a bug as seen on 2.6.32 based kernels where timers got
enqueued on offline cpus.
If a cpu goes offline it might still have pending timers. These will
be migrated during CPU_DEAD handling after the cpu is offline.
However while the cpu is going offline it will schedule the idle task
which will then call tick_nohz_stop_sched_tick().
That function in turn will call get_next_timer_intterupt() to figure
out if the tick of the cpu can be stopped or not. If it turns out that
the next tick is just one jiffy off (delta_jiffies == 1)
tick_nohz_stop_sched_tick() incorrectly assumes that the tick should
not stop and takes an early exit and thus it won't update the load
balancer cpu.
Just afterwards the cpu will be killed and the load balancer cpu could
be the offline cpu.
On 2.6.32 based kernel get_nohz_load_balancer() gets called to decide
on which cpu a timer should be enqueued (see __mod_timer()). Which
leads to the possibility that timers get enqueued on an offline cpu.
These will never expire and can cause a system hang.
This has been observed 2.6.32 kernels. On current kernels
__mod_timer() uses get_nohz_timer_target() which doesn't have that
problem. However there might be other problems because of the too
early exit tick_nohz_stop_sched_tick() in case a cpu goes offline.
The easiest and probably safest fix seems to be to let
get_next_timer_interrupt() just lie and let it say there isn't any
pending timer if the current cpu is offline.
I also thought of moving migrate_[hr]timers() from CPU_DEAD to
CPU_DYING, but seeing that there already have been fixes at least in
the hrtimer code in this area I'm afraid that this could add new
subtle bugs.
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
LKML-Reference: <
20101201091109.GA8984@osiris.boeblingen.de.ibm.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Heiko Carstens [Fri, 26 Nov 2010 12:00:59 +0000 (13:00 +0100)]
nohz: Fix printk_needs_cpu() return value on offline cpus
commit
61ab25447ad6334a74e32f60efb135a3467223f8 upstream.
This patch fixes a hang observed with 2.6.32 kernels where timers got enqueued
on offline cpus.
printk_needs_cpu() may return 1 if called on offline cpus. When a cpu gets
offlined it schedules the idle process which, before killing its own cpu, will
call tick_nohz_stop_sched_tick(). That function in turn will call
printk_needs_cpu() in order to check if the local tick can be disabled. On
offline cpus this function should naturally return 0 since regardless if the
tick gets disabled or not the cpu will be dead short after. That is besides the
fact that __cpu_disable() should already have made sure that no interrupts on
the offlined cpu will be delivered anyway.
In this case it prevents tick_nohz_stop_sched_tick() to call
select_nohz_load_balancer(). No idea if that really is a problem. However what
made me debug this is that on 2.6.32 the function get_nohz_load_balancer() is
used within __mod_timer() to select a cpu on which a timer gets enqueued. If
printk_needs_cpu() returns 1 then the nohz_load_balancer cpu doesn't get
updated when a cpu gets offlined. It may contain the cpu number of an offline
cpu. In turn timers get enqueued on an offline cpu and not very surprisingly
they never expire and cause system hangs.
This has been observed 2.6.32 kernels. On current kernels __mod_timer() uses
get_nohz_timer_target() which doesn't have that problem. However there might be
other problems because of the too early exit tick_nohz_stop_sched_tick() in
case a cpu goes offline.
Easiest way to fix this is just to test if the current cpu is offline and call
printk_tick() directly which clears the condition.
Alternatively I tried a cpu hotplug notifier which would clear the condition,
however between calling the notifier function and printk_needs_cpu() something
could have called printk() again and the problem is back again. This seems to
be the safest fix.
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
LKML-Reference: <
20101126120235.
406766476@de.ibm.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Eric Anholt [Thu, 18 Nov 2010 01:32:58 +0000 (09:32 +0800)]
drm/i915: Always set the DP transcoder config to 8BPC.
commit
220cad3cbf553f893432919b458da36489373fc6 upstream.
The pipe is always set to 8BPC, but here we were leaving whatever
previous bits were set by the BIOS in place.
Signed-off-by: Eric Anholt <eric@anholt.net>
Tested-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Alex Deucher [Fri, 3 Dec 2010 19:37:22 +0000 (14:37 -0500)]
drm/radeon/kms: fix vram base calculation on rs780/rs880
commit
8961d52d4cc52edf5672f8f2712c57162b736793 upstream.
Avoid overflowing a 32 bit value.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Alex Deucher [Thu, 9 Dec 2010 00:09:42 +0000 (19:09 -0500)]
drm/kms: remove spaces from connector names (v2)
commit
e76116ca9671e2e5239054a40303b94feab585ad upstream.
Grub doesn't parse spaces in parameters correctly, so
this makes it impossible to force video= parameters
for kms on the grub kernel command line.
v2: shorten the names to make them easier to type.
Reported-by: Sergej Pupykin <ml@sergej.pp.ru>
Cc: Sergej Pupykin <ml@sergej.pp.ru>
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Alex Deucher [Wed, 8 Dec 2010 15:05:34 +0000 (10:05 -0500)]
drm/radeon/kms: don't apply 7xx HDP flush workaround on AGP
commit
f3886f85cfde578f1d0ba6e40ac5f9d70043923b upstream.
It should be required for all 7xx asics, but seems to cause
problems on some AGP 7xx chips.
Fixes:
https://bugzilla.kernel.org/show_bug.cgi?id=19002
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Reported-and-Tested-by: Duncan <1i5t5.duncan@cox.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Daniel T Chen [Fri, 3 Dec 2010 03:45:45 +0000 (22:45 -0500)]
ALSA: hda: Use model=lg quirk for LG P1 Express to enable playback and capture
commit
77c4d5cdb81d25a45fbdfb84dd3348121219a072 upstream.
BugLink: https://launchpad.net/bugs/595482
The original reporter states that audible playback from the internal
speaker is inaudible despite the hardware being properly detected. To
work around this symptom, he uses the model=lg quirk to properly enable
both playback, capture, and jack sense. Another user corroborates this
workaround on separate hardware. Add this PCI SSID to the quirk table
to enable it for further LG P1 Expresses.
Reported-and-tested-by: Philip Peitsch <philip.peitsch@gmail.com>
Tested-by: nikhov
Signed-off-by: Daniel T Chen <crimsun@ubuntu.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Daniel T Chen [Sun, 5 Dec 2010 13:43:14 +0000 (08:43 -0500)]
ALSA: hda: Use position_fix=1 for Acer Aspire 5538 to enable capture on internal mic
commit
dd5a089edfa51a74692604b4b427953d8e16bc35 upstream.
BugLink: https://launchpad.net/bugs/685161
The reporter of the bug states that he must use position_fix=1 to enable
capture for the internal microphone, so set it for his machine's PCI
SSID. Verified using 2.6.35 and the 2010-12-04 alsa-driver build.
Reported-and-tested-by: Ralph Wabel <rwabel@gmx.net>
Signed-off-by: Daniel T Chen <crimsun@ubuntu.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Anssi Hannula [Tue, 7 Dec 2010 18:56:19 +0000 (20:56 +0200)]
ALSA: hda - Always allow basic audio irrespective of ELD info
commit
3dc86429032910bdf762adeb2969112bb303924c upstream.
Commit
bbbe33900d1f3c added functionality to restrict PCM parameters
based on ELD info (derived from EDID data) of the audio sink.
However, according to CEA-861-D no SAD is needed for basic audio
(32/44.1/48kHz stereo 16-bit audio), which is instead indicated with a
basic audio flag in the CEA EDID Extension.
The flag is not present in ELD. However, as all audio capable sinks are
required to support basic audio, we can assume it to be always
available.
Fix allowed audio formats with sinks that have SADs (Short Audio
Descriptors) which do not completely overlap with the basic audio
formats (there are no reports of affected devices so far) by always
assuming that basic audio is supported.
Reported-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Anssi Hannula <anssi.hannula@iki.fi>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Anssi Hannula [Tue, 7 Dec 2010 16:41:35 +0000 (18:41 +0200)]
ALSA: hda - Do not wrongly restrict min_channels based on ELD
commit
4b0dbdb17f846a8887e5f7fbeea2deb0703236bd upstream.
Commit
bbbe33900d1f3c added functionality to restrict PCM parameters
based on ELD info (derived from EDID data) of the audio sink.
However, it wrongly assumes that the bits 0-2 of the first byte of
CEA Short Audio Descriptors mean a supported number of channels. In
reality, they mean the maximum number of channels (as per CEA-861-D
7.5.2). This means that the channel count can only be used to restrict
max_channels, not min_channels.
Restricting min_channels causes us to deny opening the device in stereo
mode if the sink only has SADs that declare larger numbers of channels
(like Primare SP32 AV Processor does).
Fix that by not restricting min_channels based on ELD information.
Signed-off-by: Anssi Hannula <anssi.hannula@iki.fi>
Reported-by: Jean-Yves Avenard <jyavenard@gmail.com>
Tested-by: Jean-Yves Avenard <jyavenard@gmail.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
David Henningsson [Thu, 9 Dec 2010 06:17:27 +0000 (07:17 +0100)]
ALSA: HDA: Quirk for Dell Vostro 320 to make microphone work
commit
8a96b1e02029aa512199b1b6d281dcede9ed81f1 upstream.
BugLink: http://launchpad.net/497546
Confirmed that the ideapad model works better than the current
quirk for Dell Vostro 320.
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>
Miklos Szeredi [Tue, 30 Nov 2010 15:39:27 +0000 (16:39 +0100)]
fuse: fix ioctl when server is 32bit
commit
d9d318d39dd5cb686660504a3565aac453709ccc upstream.
If a 32bit CUSE server is run on 64bit this results in EIO being
returned to the caller.
The reason is that FUSE_IOCTL_RETRY reply was defined to use 'struct
iovec', which is different on 32bit and 64bit archs.
Work around this by looking at the size of the reply to determine
which struct was used. This is only needed if CONFIG_COMPAT is
defined.
A more permanent fix for the interface will be to use the same struct
on both 32bit and 64bit.
Reported-by: "ccmail111" <ccmail111@yahoo.com>
Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
CC: Tejun Heo <tj@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Miklos Szeredi [Tue, 30 Nov 2010 15:39:27 +0000 (16:39 +0100)]
fuse: verify ioctl retries
commit
7572777eef78ebdee1ecb7c258c0ef94d35bad16 upstream.
Verify that the total length of the iovec returned in FUSE_IOCTL_RETRY
doesn't overflow iov_length().
Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
CC: Tejun Heo <tj@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
H. Peter Anvin [Sat, 11 Dec 2010 04:55:22 +0000 (23:55 -0500)]
x86, hotplug: Use mwait to offline a processor, fix the legacy case
upstream
ea53069231f9317062910d6e772cca4ce93de8c8
x86, hotplug: Use mwait to offline a processor, fix the legacy case
Here included also some small follow-on patches to the same code:
upstream
a68e5c94f7d3dd64fef34dd5d97e365cae4bb42a
x86, hotplug: Move WBINVD back outside the play_dead loop
upstream
ce5f68246bf2385d6174856708d0b746dc378f20
x86, hotplug: In the MWAIT case of play_dead, CLFLUSH the cache line
https://bugzilla.kernel.org/show_bug.cgi?id=5471
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Greg Kroah-Hartman [Thu, 9 Dec 2010 22:17:27 +0000 (14:17 -0800)]
Linux 2.6.36.2
Linus Torvalds [Mon, 29 Nov 2010 00:27:19 +0000 (16:27 -0800)]
Un-inline get_pipe_info() helper function
commit
72083646528d4887b920deb71b37e09bc7d227bb upstream.
This avoids some include-file hell, and the function isn't really
important enough to be inlined anyway.
Reported-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Linus Torvalds [Sun, 28 Nov 2010 22:09:57 +0000 (14:09 -0800)]
Export 'get_pipe_info()' to other users
commit
c66fb347946ebdd5b10908866ecc9fa05ee2cf3d upstream.
And in particular, use it in 'pipe_fcntl()'.
The other pipe functions do not need to use the 'careful' version, since
they are only ever called for things that are already known to be pipes.
The normal read/write/ioctl functions are called through the file
operations structures, so if a file isn't a pipe, they'd never get
called. But pipe_fcntl() is special, and called directly from the
generic fcntl code, and needs to use the same careful function that the
splice code is using.
Cc: Jens Axboe <jaxboe@fusionio.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Dave Jones <davej@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Linus Torvalds [Sun, 28 Nov 2010 21:56:09 +0000 (13:56 -0800)]
Rename 'pipe_info()' to 'get_pipe_info()'
commit
71993e62a47dabddf10302807d6aa260455503f4 upstream.
.. and change it to take the 'file' pointer instead of an inode, since
that's what all users want anyway.
The renaming is preparatory to exporting it to other users. The old
'pipe_info()' name was too generic and is already used elsewhere, so
before making the function public we need to use a more specific name.
Cc: Jens Axboe <jaxboe@fusionio.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Dave Jones <davej@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Heiko Carstens [Thu, 25 Nov 2010 08:52:45 +0000 (09:52 +0100)]
nmi: fix clock comparator revalidation
commit
e8129c642155616d9e2160a75f103e127c8c3708 upstream.
On each machine check all registers are revalidated. The save area for
the clock comparator however only contains the upper most seven bytes
of the former contents, if valid.
Therefore the machine check handler uses a store clock instruction to
get the current time and writes that to the clock comparator register
which in turn will generate an immediate timer interrupt.
However within the lowcore the expected time of the next timer
interrupt is stored. If the interrupt happens before that time the
handler won't be called. In turn the clock comparator won't be
reprogrammed and therefore the interrupt condition stays pending which
causes an interrupt loop until the expected time is reached.
On NOHZ machines this can result in unresponsive machines since the
time of the next expected interrupted can be a couple of days in the
future.
To fix this just revalidate the clock comparator register with the
expected value.
In addition the special handling for udelay must be changed as well.
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Shan Wei [Fri, 12 Nov 2010 00:15:25 +0000 (00:15 +0000)]
r8169: fix checksum broken
commit
d5d3ebe3be5c5123f2d444e186717f45284151e2 upstream.
If r8196 received packets with invalid sctp/igmp(not tcp, udp) checksum, r8196 set skb->ip_summed
wit CHECKSUM_UNNECESSARY. This cause that upper protocol don't check checksum field.
I am not family with r8196 driver. I try to guess the meaning of RxProtoIP and IPFail.
RxProtoIP stands for received IPv4 packet that upper protocol is not tcp and udp.
!(opts1 & IPFail) is true means that driver correctly to check checksum in IPv4 header.
If it's right, I think we should not set ip_summed wit CHECKSUM_UNNECESSARY for my sctp packets
with invalid checksum.
If it's not right, please tell me.
Signed-off-by: Shan Wei <shanwei@cn.fujitsu.com>
Acked-by: Francois Romieu <romieu@fr.zoreil.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
françois romieu [Mon, 8 Nov 2010 13:23:05 +0000 (13:23 +0000)]
r8169: revert "Handle rxfifo errors on 8168 chips"
commit
53f57357ff0afc37804f4e82ee3123e0c0a2cad6 upstream.
The original patch helps under obscure conditions (no pun) but
some 8168 do not like it. The change needs to be tightened with
a specific 8168 version.
This reverts commit
801e147cde02f04b5c2f42764cd43a89fc7400a2
("r8169: Handle rxfifo errors on 8168 chips").
Regression at https://bugzilla.kernel.org/show_bug.cgi?id=20882
Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
Tested-by: Andreas Radke <a.radke@arcor.de>
Cc: Matthew Garrett <mjg@redhat.com>
Cc: Daniel J Blueman <daniel.blueman@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Stanislaw Gruszka [Wed, 20 Oct 2010 22:25:42 +0000 (22:25 +0000)]
r8169: (re)init phy on resume
commit
fccec10b33503a2b1197c8e7a3abd30443bedb08 upstream.
Fix switching device to low-speed mode after resume reported in:
https://bugzilla.redhat.com/show_bug.cgi?id=502974
Reported-and-tested-by: Laurentiu Badea <bugzilla-redhat@wotevah.com>
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Cc: Francois Romieu <romieu@fr.zoreil.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Eric Dumazet [Mon, 6 Sep 2010 03:04:05 +0000 (20:04 -0700)]
r8169: fix rx checksum offload
commit
adea1ac7effbddbe60a9de6d63462bfe79289e59 upstream.
While porting GRO to r8169, I found this driver has a bug in its rx
path.
All skbs given to network stack had their ip_summed set to
CHECKSUM_NONE, while hardware said they had correct TCP/UDP checksums.
The reason is driver sets skb->ip_summed on the original skb before the
copy eventually done by copybreak. The fresh skb gets the ip_summed =
CHECKSUM_NONE value, forcing network stack to recompute checksum, and
preventing my GRO patch to work.
Fix is to make the ip_summed setting after skb copy.
Note : rx_copybreak current value is 16383, so all frames are copied...
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Acked-by: Francois Romieu <romieu@fr.zoreil.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Hans Verkuil [Sun, 17 Oct 2010 10:24:20 +0000 (07:24 -0300)]
msp3400: fix mute audio regression
commit
0310871d8f71da4ad8643687fbc40f219a0dac4d upstream.
The switch to the new control framework caused a regression where the audio was
no longer unmuted after the carrier scan finished.
The original code attempted to set the volume control to its current value in
order to have the set-volume control code to be called that handles the volume
and muting. However, the framework will not call that code unless the new volume
value is different from the old.
Instead we now call msp_s_ctrl directly.
It is a bit of a hack: we really need a v4l2_ctrl_refresh_ctrl function for this
(or something along those lines).
Thanks to Andy Walls for bisecting this and to Shane Shrybman for reporting it!
Reported-by: Shane Shrybman <shrybman@teksavvy.com>
Thanks-to: Andy Walls <awalls@md.metrocast.net>
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Chad Dupuis [Fri, 15 Oct 2010 18:27:40 +0000 (11:27 -0700)]
qla2xxx: Add module parameter to enable/disable GFF_ID device type check.
commit
4da26e162b69d89c3186a35a052c05e61a555637 upstream.
Add the module parameter ql2xgffidenable to disable/enable the use of the
GFF_ID name server command to prevent non FCP SCSI devices from being added to
the driver's internal fc_port database.
Signed-off-by: Chad Dupuis <chad.dupuis@qlogic.com>
Signed-off-by: Madhuranath Iyengar <Madhu.Iyengar@qlogic.com>
Signed-off-by: James Bottomley <James.Bottomley@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Luis R. Rodriguez [Sat, 13 Nov 2010 00:31:23 +0000 (16:31 -0800)]
cfg80211: fix extension channel checks to initiate communication
commit
9236d838c920e90708570d9bbd7bb82d30a38130 upstream.
When operating in a mode that initiates communication and using
HT40 we should fail if we cannot use both primary and secondary
channels to initiate communication. Our current ht40 allowmap
only covers STA mode of operation, for beaconing modes we need
a check on the fly as the mode of operation is dynamic and
there other flags other than disable which we should read
to check if we can initiate communication.
Do not allow for initiating communication if our secondary HT40
channel has is either disabled, has a passive scan flag, a
no-ibss flag or is a radar channel. Userspace now has similar
checks but this is also needed in-kernel.
Reported-by: Jouni Malinen <jouni.malinen@atheros.com>
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Dan Rosenberg [Wed, 17 Nov 2010 06:37:16 +0000 (06:37 +0000)]
rds: Integer overflow in RDS cmsg handling
commit
218854af84038d828a32f061858b1902ed2beec6 upstream.
In rds_cmsg_rdma_args(), the user-provided args->nr_local value is
restricted to less than UINT_MAX. This seems to need a tighter upper
bound, since the calculation of total iov_size can overflow, resulting
in a small sock_kmalloc() allocation. This would probably just result
in walking off the heap and crashing when calling rds_rdma_pages() with
a high count value. If it somehow doesn't crash here, then memory
corruption could occur soon after.
Signed-off-by: Dan Rosenberg <drosenberg@vsecurity.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Phil Blundell [Wed, 24 Nov 2010 19:51:47 +0000 (11:51 -0800)]
econet: fix CVE-2010-3848
commit
a27e13d370415add3487949c60810e36069a23a6 upstream.
Don't declare variable sized array of iovecs on the stack since this
could cause stack overflow if msg->msgiovlen is large. Instead, coalesce
the user-supplied data into a new buffer and use a single iovec for it.
Signed-off-by: Phil Blundell <philb@gnu.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Phil Blundell [Wed, 24 Nov 2010 19:49:53 +0000 (11:49 -0800)]
econet: fix CVE-2010-3850
commit
16c41745c7b92a243d0874f534c1655196c64b74 upstream.
Add missing check for capable(CAP_NET_ADMIN) in SIOCSIFADDR operation.
Signed-off-by: Phil Blundell <philb@gnu.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Phil Blundell [Wed, 24 Nov 2010 19:49:19 +0000 (11:49 -0800)]
econet: disallow NULL remote addr for sendmsg(), fixes CVE-2010-3849
commit
fa0e846494792e722d817b9d3d625a4ef4896c96 upstream.
Later parts of econet_sendmsg() rely on saddr != NULL, so return early
with EINVAL if NULL was passed otherwise an oops may occur.
Signed-off-by: Phil Blundell <philb@gnu.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Sergey Senozhatsky [Thu, 28 Oct 2010 01:30:04 +0000 (21:30 -0400)]
ext4: fix NULL pointer dereference in print_daily_error_info()
commit
a1c6c5698d53db4c47a25c3a8d11731a4d7b8370 upstream.
Fix NULL pointer dereference in print_daily_error_info, when
called on unmounted fs (EXT4_SB(sb) returns NULL), by removing error
reporting timer in ext4_put_super.
Google-Bug-Id:
3017663
Signed-off-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Cc: Thomas Meyer <thomas@m3y3r.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Herbert Xu [Thu, 4 Nov 2010 18:38:39 +0000 (14:38 -0400)]
crypto: padlock - Fix AES-CBC handling on odd-block-sized input
commit
c054a076a1bd4731820a9c4d638b13d5c9bf5935 upstream.
On certain VIA chipsets AES-CBC requires the input/output to be
a multiple of 64 bytes. We had a workaround for this but it was
buggy as it sent the whole input for processing when it is meant
to only send the initial number of blocks which makes the rest
a multiple of 64 bytes.
As expected this causes memory corruption whenever the workaround
kicks in.
Reported-by: Phil Sutter <phil@nwl.cc>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Dan Rosenberg [Fri, 12 Nov 2010 20:44:42 +0000 (12:44 -0800)]
x25: Prevent crashing when parsing bad X.25 facilities
commit
5ef41308f94dcbb3b7afc56cdef1c2ba53fa5d2f upstream.
Now with improved comma support.
On parsing malformed X.25 facilities, decrementing the remaining length
may cause it to underflow. Since the length is an unsigned integer,
this will result in the loop continuing until the kernel crashes.
This patch adds checks to ensure decrementing the remaining length does
not cause it to wrap around.
Signed-off-by: Dan Rosenberg <drosenberg@vsecurity.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Oliver Hartkopp [Wed, 10 Nov 2010 12:10:30 +0000 (12:10 +0000)]
can-bcm: fix minor heap overflow
commit
0597d1b99fcfc2c0eada09a698f85ed413d4ba84 upstream.
On 64-bit platforms the ASCII representation of a pointer may be up to 17
bytes long. This patch increases the length of the buffer accordingly.
http://marc.info/?l=linux-netdev&m=
128872251418192&w=2
Reported-by: Dan Rosenberg <drosenberg@vsecurity.com>
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
CC: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
David S. Miller [Wed, 10 Nov 2010 18:38:24 +0000 (10:38 -0800)]
filter: make sure filters dont read uninitialized memory
commit
57fe93b374a6b8711995c2d466c502af9f3a08bb upstream.
There is a possibility malicious users can get limited information about
uninitialized stack mem array. Even if sk_run_filter() result is bound
to packet length (0 .. 65535), we could imagine this can be used by
hostile user.
Initializing mem[] array, like Dan Rosenberg suggested in his patch is
expensive since most filters dont even use this array.
Its hard to make the filter validation in sk_chk_filter(), because of
the jumps. This might be done later.
In this patch, I use a bitmap (a single long var) so that only filters
using mem[] loads/stores pay the price of added security checks.
For other filters, additional cost is a single instruction.
[ Since we access fentry->k a lot now, cache it in a local variable
and mark filter entry pointer as const. -DaveM ]
Reported-by: Dan Rosenberg <drosenberg@vsecurity.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@suse.de>
Arnaud Lacombe [Mon, 23 Aug 2010 16:01:24 +0000 (12:01 -0400)]
kbuild: use getopt_long(), not its _only() variant
commit
c94d3fb01fb6db1899cdf53ea4eb9d38e08a08fe upstream.
NetBSD lacks getopt_long_only() whereas getopt_long() works just fine.
Signed-off-by: Arnaud Lacombe <lacombar@gmail.com>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: Michal Marek <mmarek@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Jesse Gross [Mon, 8 Nov 2010 21:23:01 +0000 (13:23 -0800)]
vlan: Avoid hwaccel vlan packets when vid not used.
[This patch applies only to 2.6.36 stable. The problem was introduced
in that release and is already fixed by larger changes to the vlan
code in 2.6.37.]
Normally hardware accelerated vlan packets are quickly dropped if
there is no corresponding vlan device configured. The one exception
is promiscuous mode, where we allow all of these packets through so
they can be picked up by tcpdump. However, this behavior causes a
crash if we actually try to receive these packets. This fixes that
crash by ignoring packets with vids not corresponding to a configured
device in the vlan hwaccel routines and then dropping them before they
get to consumers in the network stack.
Reported-by: Ben Greear <greearb@candelatech.com>
Tested-by: Nikola Ciprich <extmaillist@linuxbox.cz>
Signed-off-by: Jesse Gross <jesse@nicira.com>
Acked-by: David Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
andrew hendry [Wed, 3 Nov 2010 12:54:53 +0000 (12:54 +0000)]
memory corruption in X.25 facilities parsing
commit
a6331d6f9a4298173b413cf99a40cc86a9d92c37 upstream.
Signed-of-by: Andrew Hendry <andrew.hendry@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Peter Ujfalusi [Mon, 11 Oct 2010 21:18:56 +0000 (14:18 -0700)]
OMAP3: DMA: Errata i541: sDMA FIFO draining does not finish
commit
0e4905c0199d683497833be60a428c784d7575b8 upstream.
Implement the suggested workaround for OMAP3 regarding to sDMA draining
issue, when the channel is disabled on the fly.
This errata affects the following configuration:
sDMA transfer is source synchronized
Buffering is enabled
SmartStandby is selected.
The issue can be easily reproduced by creating overrun situation while
recording audio.
Either introduce load to the CPU:
nice -19 arecord -D hw:0 -M -B 10000 -F 5000 -f dat > /dev/null & \
dd if=/dev/urandom of=/dev/null
or suspending the arecord, and resuming it:
arecord -D hw:0 -M -B 10000 -F 5000 -f dat > /dev/null
CTRL+Z; fg; CTRL+Z; fg; ...
In case of overrun audio stops DMA, and restarts it (without reseting
the sDMA channel). When we hit this errata in stop case (sDMA drain did
not complete), at the coming start the sDMA will not going to be
operational (it is still draining).
This leads to DMA stall condition.
On OMAP3 we can recover with sDMA channel reset, it has been observed
that by introducing unrelated sDMA activity might also help (reading
from MMC for example).
The same errata exists for OMAP2, where the suggestion is to disable the
buffering to avoid this type of error.
On OMAP3 the suggestion is to set sDMA to NoStandby before disabling
the channel, and wait for the drain to finish, than configure sDMA to
SmartStandby again.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@nokia.com>
Acked-by: Jarkko Nikula <jhnikula@gmail.com>
Acked-by : Santosh Shilimkar <santosh.shilimkar@ti.com>
Acked-by : Manjunath Kondaiah G <manjugk@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Jarkko Nikula [Mon, 11 Oct 2010 21:18:45 +0000 (14:18 -0700)]
omap: dma: Fix buffering disable bit setting for omap24xx
commit
3e57f1626b5febe5cc99aa6870377deef3ae03cc upstream.
An errata workaround for omap24xx is not setting the buffering disable bit
25 what is the purpose but channel enable bit 7 instead.
Background for this fix is the DMA stalling issue with ASoC omap-mcbsp
driver. Peter Ujfalusi <peter.ujfalusi@nokia.com> has found an issue in
recording that the DMA stall could happen if there were a buffer overrun
detected by ALSA and the DMA was stopped and restarted due that. This
problem is known to occur on both OMAP2420 and OMAP3. It can recover on
OMAP3 after dma free, dma request and reconfiguration cycle. However, on
OMAP2420 it seems that only way to recover is a reset.
Problem was not visible before the commit
c12abc0. That commit changed that
the McBSP transmitter/receiver is released from reset only when needed. That
is, only enabled McBSP transmitter without transmission was able to prevent
this DMA stall problem in receiving side and underlying problem did not show
up until now. McBSP transmitter itself seems to no be reason since DMA
stall does not recover by enabling the transmission after stall.
Debugging showed that there were a DMA write active during DMA stop time and
it never completed even when restarting the DMA. Experimenting showed that
the DMA buffering disable bit could be used to avoid stalling when using
source synchronized transfers. However that could have performance hit and
OMAP3 TRM states that buffering disable is not allowed for destination
synchronized transfers so subsequent patch will implement a method to
complete DMA writes when stopping.
This patch is based on assumtion that complete lock-up on OMAP2420 is
different but related problem. I don't have access to OMAP2420 errata but
I believe this old workaround here is put for a reason but unfortunately
a wrong bit was typed and problem showed up only now.
Signed-off-by: Jarkko Nikula <jhnikula@gmail.com>
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@nokia.com>
Acked-by: Manjunath Kondaiah G <manjugk@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Dmitry Torokhov [Thu, 4 Nov 2010 16:12:44 +0000 (09:12 -0700)]
Input: i8042 - add Sony VAIO VPCZ122GX to nomux list
[Note that the mainline will not have this particular fix but rather
will blacklist entire VAIO line based off DMI board name. For stable
I am being a bit more cautious and blacklist one particular product.]
Trying to query/activate active multiplexing mode on this VAIO makes
both keyboard and touchpad inoperable. Futher kernels will blacklist
entire VAIO line, however here we blacklist just one particular model.
Reported-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
David S. Miller [Thu, 28 Oct 2010 18:41:55 +0000 (11:41 -0700)]
net: Limit socket I/O iovec total length to INT_MAX.
commit
8acfe468b0384e834a303f08ebc4953d72fb690a upstream.
This helps protect us from overflow issues down in the
individual protocol sendmsg/recvmsg handlers. Once
we hit INT_MAX we truncate out the rest of the iovec
by setting the iov_len members to zero.
This works because:
1) For SOCK_STREAM and SOCK_SEQPACKET sockets, partial
writes are allowed and the application will just continue
with another write to send the rest of the data.
2) For datagram oriented sockets, where there must be a
one-to-one correspondance between write() calls and
packets on the wire, INT_MAX is going to be far larger
than the packet size limit the protocol is going to
check for and signal with -EMSGSIZE.
Based upon a patch by Linus Torvalds.
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Linus Torvalds [Sat, 30 Oct 2010 23:43:10 +0000 (16:43 -0700)]
net: Truncate recvfrom and sendto length to INT_MAX.
commit
253eacc070b114c2ec1f81b067d2fed7305467b0 upstream.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Kenji Kaneshige [Tue, 30 Nov 2010 08:36:08 +0000 (17:36 +0900)]
genirq: Fix incorrect proc spurious output
commit
25c9170ed64a6551beefe9315882f754e14486f4 upstream.
Since commit
a1afb637(switch /proc/irq/*/spurious to seq_file) all
/proc/irq/XX/spurious files show the information of irq 0.
Current irq_spurious_proc_open() passes on NULL as the 3rd argument,
which is used as an IRQ number in irq_spurious_proc_show(), to the
single_open(). Because of this, all the /proc/irq/XX/spurious file
shows IRQ 0 information regardless of the IRQ number.
To fix the problem, irq_spurious_proc_open() must pass on the
appropreate data (IRQ number) to single_open().
Signed-off-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
Reviewed-by: Yong Zhang <yong.zhang0@gmail.com>
LKML-Reference: <
4CF4B778.90604@jp.fujitsu.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Heiko Carstens [Wed, 1 Dec 2010 09:08:01 +0000 (10:08 +0100)]
nohz/s390: fix arch_needs_cpu() return value on offline cpus
commit
398812159e328478ae49b4bd01f0d71efea96c39 upstream.
This fixes the same problem as described in the patch "nohz: fix
printk_needs_cpu() return value on offline cpus" for the arch_needs_cpu()
primitive:
arch_needs_cpu() may return 1 if called on offline cpus. When a cpu gets
offlined it schedules the idle process which, before killing its own cpu,
will call tick_nohz_stop_sched_tick().
That function in turn will call arch_needs_cpu() in order to check if the
local tick can be disabled. On offline cpus this function should naturally
return 0 since regardless if the tick gets disabled or not the cpu will be
dead short after. That is besides the fact that __cpu_disable() should already
have made sure that no interrupts on the offlined cpu will be delivered anyway.
In this case it prevents tick_nohz_stop_sched_tick() to call
select_nohz_load_balancer(). No idea if that really is a problem. However what
made me debug this is that on 2.6.32 the function get_nohz_load_balancer() is
used within __mod_timer() to select a cpu on which a timer gets enqueued.
If arch_needs_cpu() returns 1 then the nohz_load_balancer cpu doesn't get
updated when a cpu gets offlined. It may contain the cpu number of an offline
cpu. In turn timers get enqueued on an offline cpu and not very surprisingly
they never expire and cause system hangs.
This has been observed 2.6.32 kernels. On current kernels __mod_timer() uses
get_nohz_timer_target() which doesn't have that problem. However there might
be other problems because of the too early exit tick_nohz_stop_sched_tick()
in case a cpu goes offline.
This specific bug was indrocuded with
3c5d92a0 "nohz: Introduce
arch_needs_cpu".
In this case a cpu hotplug notifier is used to fix the issue in order to keep
the normal/fast path small. All we need to do is to clear the condition that
makes arch_needs_cpu() return 1 since it is just a performance improvement
which is supposed to keep the local tick running for a short period if a cpu
goes idle. Nothing special needs to be done except for clearing the condition.
Acked-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Thadeu Lima de Souza Cascardo [Sun, 28 Nov 2010 21:46:50 +0000 (19:46 -0200)]
wmi: use memcmp instead of strncmp to compare GUIDs
commit
8b14d7b22c61f17ccb869e0047d9df6dd9f50a9f upstream.
While looking for the duplicates in /sys/class/wmi/, I couldn't find
them. The code that looks for duplicates uses strncmp in a binary GUID,
which may contain zero bytes. The right function is memcmp, which is
also used in another section of wmi code.
It was finding
49142400-C6A3-40FA-BADB-
8A2652834100 as a duplicate of
39142400-C6A3-40FA-BADB-
8A2652834100. Since the first byte is the fourth
printed, they were found as equal by strncmp.
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@holoscopio.com>
Signed-off-by: Matthew Garrett <mjg@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Rafael J. Wysocki [Fri, 3 Dec 2010 21:57:45 +0000 (22:57 +0100)]
PM / Hibernate: Fix memory corruption related to swap
commit
c9e664f1fdf34aa8cede047b206deaa8f1945af0 upstream.
There is a problem that swap pages allocated before the creation of
a hibernation image can be released and used for storing the contents
of different memory pages while the image is being saved. Since the
kernel stored in the image doesn't know of that, it causes memory
corruption to occur after resume from hibernation, especially on
systems with relatively small RAM that need to swap often.
This issue can be addressed by keeping the GFP_IOFS bits clear
in gfp_allowed_mask during the entire hibernation, including the
saving of the image, until the system is finally turned off or
the hibernation is aborted. Unfortunately, for this purpose
it's necessary to rework the way in which the hibernate and
suspend code manipulates gfp_allowed_mask.
This change is based on an earlier patch from Hugh Dickins.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Reported-by: Ondrej Zary <linux@rainbow-software.org>
Acked-by: Hugh Dickins <hughd@google.com>
Reviewed-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Anton Vorontsov [Mon, 29 Nov 2010 15:46:22 +0000 (18:46 +0300)]
ARM: cns3xxx: Fix build with CONFIG_PCI=y
commit
44266416f786514ec43a0d15ad951c34566b99c9 upstream.
commit
6338a6aa7c082f11d55712251e14178c68bf5869 ("ARM: 6269/1: Add 'code'
parameter for hook_fault_code()") breaks CNS3xxx build:
CC arch/arm/mach-cns3xxx/pcie.o
pcie.c: In function 'cns3xxx_pcie_init':
pcie.c:373: warning: passing argument 4 of 'hook_fault_code' makes integer from pointer without a cast
pcie.c:373: error: too few arguments to function 'hook_fault_code'
This commit fixes the small issue.
Signed-off-by: Anton Vorontsov <cbouatmailru@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Marcelo Roberto Jimenez [Mon, 18 Oct 2010 21:38:08 +0000 (22:38 +0100)]
ARM: 6456/1: Fix for building DEBUG with sa11xx_base.c as a module.
commit
b9f515e3e3861abbaa093359f7c6f31283695228 upstream.
This patch fixes a compilation issue when compiling PCMCIA SA1100
support as a module with PCMCIA_DEBUG enabled. The symbol
soc_pcmcia_debug was not beeing exported.
ARM: pcmcia: Fix for building DEBUG with sa11xx_base.c as a module.
This patch fixes a compilation issue when compiling PCMCIA SA1100
support as a module with PCMCIA_DEBUG enabled. The symbol
soc_pcmcia_debug was not beeing exported.
Signed-off-by: Marcelo Roberto Jimenez <mroberto@cpti.cetuc.puc-rio.br>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Thomas Gleixner [Wed, 24 Nov 2010 09:05:55 +0000 (10:05 +0100)]
perf: Fix inherit vs. context rotation bug
commit
dddd3379a619a4cb8247bfd3c94ca9ae3797aa2e upstream.
It was found that sometimes children of tasks with inherited events had
one extra event. Eventually it turned out to be due to the list rotation
no being exclusive with the list iteration in the inheritance code.
Cure this by temporarily disabling the rotation while we inherit the events.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
LKML-Reference: <new-submission>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Marek Lindner [Mon, 22 Nov 2010 11:34:49 +0000 (12:34 +0100)]
Staging: batman-adv: ensure that eth_type_trans gets linear memory
commit
b6faaae1a15a352d68b3e3cd8b840e56709820bf upstream.
eth_type_trans tries to pull data with the length of the ethernet header
from the skb. We only ensured that enough data for the first ethernet
header and the batman header is available in non-paged memory of the skb
and not for the ethernet after the batman header.
eth_type_trans would fail sometimes with drivers which don't ensure that
all there data is perfectly linearised.
The failure was noticed through a kernel bug Oops generated by the
skb_pull inside eth_type_trans.
Reported-by: Rafal Lesniak <lesniak@eresi-project.org>
Signed-off-by: Marek Lindner <lindner_marek@yahoo.de>
Signed-off-by: Sven Eckelmann <sven.eckelmann@gmx.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Larry Finger [Sat, 13 Nov 2010 19:01:56 +0000 (13:01 -0600)]
staging: rtl8187se: Change panic to warn when RF switch turned off
commit
f36d83a8cb7224f45fdfa1129a616dff56479a09 upstream.
This driver issues a kernel panic over conditions that do not
justify such drastic action. Change these to log entries with
a stack dump.
This patch fixes the system crash reported in
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/674285.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Reported-and-Tested-by: Robie Basik <rb-oss-3@justgohome.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Greg Kroah-Hartman [Tue, 16 Nov 2010 19:18:33 +0000 (11:18 -0800)]
Staging: frontier: fix up some sysfs attribute permissions
commit
3bad28ec006ad6ab2bca4e5103860b75391e3c9d and
2a767fda5d0d8dcff465724dfad6ee131489b3f2 upstream merged together.
They should not be writable by any user
Reported-by: Linus Torvalds <torvalds@linux-foundation.org>
Cc: David Taht <d@teklibre.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Greg Kroah-Hartman [Thu, 18 Nov 2010 19:21:04 +0000 (11:21 -0800)]
Staging: samsung-laptop: fix up my fixup for some sysfs attribute permissions
commit
4d7bc388b44e42a1feafa35e50eef4f24d6ca59d upstream.
They should be writable by root, not readable.
Doh, stupid me with the wrong flags.
Reported-by: Jonathan Cameron <jic23@cam.ac.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>