Tim Gardner [Tue, 8 Jun 2010 17:33:02 +0000 (11:33 -0600)]
hostap: Protect against initialization interrupt
commit
d6a574ff6bfb842bdb98065da053881ff527be46 upstream.
Use an irq spinlock to hold off the IRQ handler until
enough early card init is complete such that the handler
can run without faulting.
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Vivek Natarajan [Tue, 27 Apr 2010 07:35:38 +0000 (13:05 +0530)]
ath9k: Avoid corrupt frames being forwarded to mac80211.
commit
3a37495268ab45507b4cab9d4cb18c5496ab7a10 upstream.
If bit 29 is set, MAC H/W can attempt to decrypt the received aggregate
with WEP or TKIP, eventhough the received frame may be a CRC failed
corrupted frame. If this bit is set, H/W obeys key type in keycache.
If it is not set and if the key type in keycache is neither open nor
AES, H/W forces key type to be open. But bit 29 should be set to 1
for AsyncFIFO feature to encrypt/decrypt the aggregate with WEP or TKIP.
Reported-by: Johan Hovold <johan.hovold@lundinova.se>
Signed-off-by: Vivek Natarajan <vnatarajan@atheros.com>
Signed-off-by: Ranga Rao Ravuri <ranga.ravuri@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Luis R. Rodriguez [Fri, 18 Dec 2009 16:26:04 +0000 (11:26 -0500)]
ath9k: re-enable ps by default for new single chip families
commit
14acdde6e527950f66c084dbf19bad6fbfcaeedc upstream.
The newer single chip hardware family of chipsets have not been
experiencing issues with power saving set by default with recent
fixes merged (even into stable). The remaining issues are only
reported with AR5416 and since enabling PS by default can increase
power savings considerably best to take advantage of that feature
as this has been tested properly.
For more details on this issue see the bug report:
http://bugzilla.kernel.org/show_bug.cgi?id=14267
We leave AR5416 with PS disabled by default, that seems to require
some more work.
Cc: Peter Stuge <peter@stuge.se>
Cc: Justin P. Mattock <justinmattock@gmail.com>
Cc: Kristoffer Ericson <kristoffer.ericson@gmail.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>
Luis R. Rodriguez [Mon, 10 May 2010 19:26:27 +0000 (15:26 -0400)]
ath5k: drop warning on jumbo frames
commit
9637e516d16a58b13f6098cfe899e22963132be3 upstream.
Jumbo frames are not supported, and if they are seen it is likely
a bogus frame so just silently discard them instead of warning on
them all time. Also, instead of dropping them immediately though
move the check *after* we check for all sort of frame errors. This
should enable us to discard these frames if the hardware picks
other bogus items first. Lets see if we still get those jumbo
counters increasing still with this.
Jumbo frames would happen if we tell hardware we can support
a small 802.11 chunks of DMA'd frame, hardware would split RX'd
frames into parts and we'd have to reconstruct them in software.
This is done with USB due to the bulk size but with ath5k we
already provide a good limit to hardware and this should not be
happening.
This is reported quite often and if it fills the logs then this
needs to be addressed and to avoid spurious reports.
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>
Trond Myklebust [Wed, 16 Jun 2010 17:57:32 +0000 (13:57 -0400)]
SUNRPC: Fix a re-entrancy bug in xs_tcp_read_calldir()
commit
b76ce56192bcf618013fb9aecd83488cffd645cc upstream.
If the attempt to read the calldir fails, then instead of storing the read
bytes, we currently discard them. This leads to a garbage final result when
upon re-entry to the same routine, we read the remaining bytes.
Fixes the regression in bugzilla number 16213. Please see
https://bugzilla.kernel.org/show_bug.cgi?id=16213
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Trond Myklebust [Fri, 18 Jun 2010 16:23:58 +0000 (12:23 -0400)]
NFSv4: Ensure that /proc/self/mountinfo displays the minor version number
commit
0be8189f2c87fcc747d6a4a657a0b6e2161b2318 upstream.
Currently, we do not display the minor version mount parameter in the
/proc mount info.
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Trond Myklebust [Tue, 22 Jun 2010 12:52:39 +0000 (08:52 -0400)]
NFSv4: Fix an embarassing typo in encode_attrs()
commit
d3f6baaa34c54040b3ef30950e59b54ac0624b21 upstream.
Apparently, we have never been able to set the atime correctly from the
NFSv4 client.
Reported-by: 小倉一夫 <ka-ogura@bd6.so-net.ne.jp>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Mikael Pettersson [Wed, 21 Jul 2010 01:45:14 +0000 (18:45 -0700)]
math-emu: correct test for downshifting fraction in _FP_FROM_INT()
commit
f8324e20f8289dffc646d64366332e05eaacab25 upstream.
The kernel's math-emu code contains a macro _FP_FROM_INT() which is
used to convert an integer to a raw normalized floating-point value.
It does this basically in three steps:
1. Compute the exponent from the number of leading zero bits.
2. Downshift large fractions to put the MSB in the right position
for normalized fractions.
3. Upshift small fractions to put the MSB in the right position.
There is an boundary error in step 2, causing a fraction with its
MSB exactly one bit above the normalized MSB position to not be
downshifted. This results in a non-normalized raw float, which when
packed becomes a massively inaccurate representation for that input.
The impact of this depends on a number of arch-specific factors,
but it is known to have broken emulation of FXTOD instructions
on UltraSPARC III, which was originally reported as GCC bug 44631
<http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44631>.
Any arch which uses math-emu to emulate conversions from integers to
same-size floats may be affected.
The fix is simple: the exponent comparison used to determine if the
fraction should be downshifted must be "<=" not "<".
I'm sending a kernel module to test this as a reply to this message.
There are also SPARC user-space test cases in the GCC bug entry.
Signed-off-by: Mikael Pettersson <mikpe@it.uu.se>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Rob Landley [Sat, 27 Mar 2010 15:36:18 +0000 (08:36 -0700)]
sparc: Fix use of uid16_t and gid16_t in asm/stat.h
commit
7469a9acf919d36836f6c635099d8edc9be4528a upstream.
Signed-off-by: Rob Landley <rob@landley.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Alexander Duyck [Mon, 5 Oct 2009 06:34:25 +0000 (06:34 +0000)]
igb: change how we handle alternate mac addresses
commit
22896639af98ebc721a94ed71fc3acf2fb4a24dc upstream.
This patch allows us to treat the alternate mac address as though it is the
physical address on the adapter. This is accomplished by letting the
alt_mac_address function to only fail on an NVM error. If no errors occur
and the alternate mac address is not present then RAR0 is read as the
default mac address.
Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Cc: Brandon Philips <bphilips@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Brandon Philips [Wed, 16 Jun 2010 16:21:58 +0000 (16:21 +0000)]
sky2: enable rx/tx in sky2_phy_reinit()
commit
38000a94a902e94ca8b5498f7871c6316de8957a upstream.
sky2_phy_reinit is called by the ethtool helpers sky2_set_settings,
sky2_nway_reset and sky2_set_pauseparam when netif_running.
However, at the end of sky2_phy_init GM_GP_CTRL has GM_GPCR_RX_ENA and
GM_GPCR_TX_ENA cleared. So, doing these commands causes the device to
stop working:
$ ethtool -r eth0
$ ethtool -A eth0 autoneg off
Fix this issue by enabling Rx/Tx after running sky2_phy_init in
sky2_phy_reinit.
Signed-off-by: Brandon Philips <bphilips@suse.de>
Tested-by: Brandon Philips <bphilips@suse.de>
Cc: stable@kernel.org
Tested-by: Mike McCormack <mikem@ring3k.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Florian Fainelli [Sun, 20 Jun 2010 22:07:48 +0000 (22:07 +0000)]
cpmac: do not leak struct net_device on phy_connect errors
commit
ed770f01360b392564650bf1553ce723fa46afec upstream.
If the call to phy_connect fails, we will return directly instead of freeing
the previously allocated struct net_device.
Signed-off-by: Florian Fainelli <florian@openwrt.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Luke Yelavich [Tue, 22 Jun 2010 01:04:19 +0000 (11:04 +1000)]
ALSA: hda - Add Macbook 5,2 quirk
commit
3bfea98ff73d377ffce0d4c7f938b7ef958cdb35 upstream.
BugLink: https://bugs.launchpad.net/bugs/463178
Set Macbook 5,2 (106b:4a00) hardware to use ALC885_MB5
Signed-off-by: Luke Yelavich <luke.yelavich@canonical.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
David Howells [Thu, 22 Jul 2010 11:53:18 +0000 (12:53 +0100)]
CIFS: Fix a malicious redirect problem in the DNS lookup code
commit
4c0c03ca54f72fdd5912516ad0a23ec5cf01bda7 upstream.
Fix the security problem in the CIFS filesystem DNS lookup code in which a
malicious redirect could be installed by a random user by simply adding a
result record into one of their keyrings with add_key() and then invoking a
CIFS CFS lookup [CVE-2010-2524].
This is done by creating an internal keyring specifically for the caching of
DNS lookups. To enforce the use of this keyring, the module init routine
creates a set of override credentials with the keyring installed as the thread
keyring and instructs request_key() to only install lookup result keys in that
keyring.
The override is then applied around the call to request_key().
This has some additional benefits when a kernel service uses this module to
request a key:
(1) The result keys are owned by root, not the user that caused the lookup.
(2) The result keys don't pop up in the user's keyrings.
(3) The result keys don't come out of the quota of the user that caused the
lookup.
The keyring can be viewed as root by doing cat /proc/keys:
2a0ca6c3 I----- 1 perm
1f030000 0 0 keyring .dns_resolver: 1/4
It can then be listed with 'keyctl list' by root.
# keyctl list 0x2a0ca6c3
1 key in keyring:
726766307: --alswrv 0 0 dns_resolver: foo.bar.com
Signed-off-by: David Howells <dhowells@redhat.com>
Reviewed-and-Tested-by: Jeff Layton <jlayton@redhat.com>
Acked-by: Steve French <smfrench@gmail.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Jeff Layton [Tue, 1 Jun 2010 20:21:01 +0000 (16:21 -0400)]
cifs: don't attempt busy-file rename unless it's in same directory
commit
ed0e3ace576d297a5c7015401db1060bbf677b94 upstream.
Busy-file renames don't actually work across directories, so we need
to limit this code to renames within the same dir.
This fixes the bug detailed here:
https://bugzilla.redhat.com/show_bug.cgi?id=591938
Signed-off-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: Steve French <sfrench@us.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Jeff Layton [Wed, 16 Jun 2010 17:40:18 +0000 (13:40 -0400)]
cifs: remove bogus first_time check in NTLMv2 session setup code
commit
8a224d489454b7457105848610cfebebdec5638d upstream.
This bug appears to be the result of a cut-and-paste mistake from the
NTLMv1 code. The function to generate the MAC key was commented out, but
not the conditional above it. The conditional then ended up causing the
session setup key not to be copied to the buffer unless this was the
first session on the socket, and that made all but the first NTLMv2
session setup fail.
Fix this by removing the conditional and all of the commented clutter
that made it difficult to see.
Reported-by: Gunther Deschner <gdeschne@redhat.com>
Signed-off-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Jean Delvare [Fri, 9 Jul 2010 14:22:48 +0000 (16:22 +0200)]
hwmon: (it87) Fix in7 on IT8720F
commit
436cad2a41a40c6c32bd9152b63d17eeb1f7c99b upstream.
The IT8720F has no VIN7 pin, so VCCH should always be routed
internally to VIN7 with an internal divider. Curiously, there still
is a configuration bit to control this, which means it can be set
incorrectly. And even more curiously, many boards out there are
improperly configured, even though the IT8720F datasheet claims that
the internal routing of VCCH to VIN7 is the default setting. So we
force the internal routing in this case.
It turns out that all boards with the wrong setting are from Gigabyte,
so I suspect a BIOS bug. But it's easy enough to workaround in the
driver, so let's do it.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Cc: Jean-Marc Spaggiari <jean-marc@spaggiari.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Jean Delvare [Fri, 9 Jul 2010 14:22:49 +0000 (16:22 +0200)]
hwmon: (coretemp) Skip duplicate CPU entries
commit
d883b9f0977269d519469da72faec6a7f72cb489 upstream.
On hyper-threaded CPUs, each core appears twice in the CPU list. Skip
the second entry to avoid duplicate sensors.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Acked-by: Huaxu Wan <huaxu.wan@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Jean Delvare [Fri, 9 Jul 2010 14:22:51 +0000 (16:22 +0200)]
hwmon: (coretemp) Properly label the sensors
commit
3f4f09b4be35d38d6e2bf22c989443e65e70fc4c upstream.
Don't assume that CPU entry number and core ID always match. It
worked in the simple cases (single CPU, no HT) but fails on
multi-CPU systems.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Acked-by: Huaxu Wan <huaxu.wan@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Andreas Herrmann [Fri, 9 Jul 2010 14:22:47 +0000 (16:22 +0200)]
hwmon: (k8temp) Fix temperature reporting for ASB1 processor revisions
commit
d535bad90dad4eb42ec6528043fcfb53627d4f89 upstream.
Reported temperature for ASB1 CPUs is too high.
Add ASB1 CPU revisions (these are also non-desktop variants) to the
list of CPUs for which the temperature fixup is not required.
Example: (from LENOVO ThinkPad Edge 13, 01972NG, system was idle)
Current kernel reports
$ sensors
k8temp-pci-00c3
Adapter: PCI adapter
Core0 Temp: +74.0 C
Core0 Temp: +70.0 C
Core1 Temp: +69.0 C
Core1 Temp: +70.0 C
With this patch I have
$ sensors
k8temp-pci-00c3
Adapter: PCI adapter
Core0 Temp: +54.0 C
Core0 Temp: +51.0 C
Core1 Temp: +48.0 C
Core1 Temp: +49.0 C
Cc: Rudolf Marek <r.marek@assembler.cz>
Signed-off-by: Andreas Herrmann <andreas.herrmann3@amd.com>
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Jean Delvare [Sun, 20 Jun 2010 07:22:32 +0000 (09:22 +0200)]
hwmon: (k8temp) Bypass core swapping on single-core processors
commit
cd4de21f7e65a8cd04860f5661b3c18648ee52a1 upstream.
Commit
a2e066bba2aad6583e3ff648bf28339d6c9f0898 introduced core
swapping for CPU models 64 and later. I recently had a report about
a Sempron 3200+, model 95, for which this patch broke temperature
reading. It happens that this is a single-core processor, so the
effect of the swapping was to read a temperature value for a core
that didn't exist, leading to an incorrect value (-49 degrees C.)
Disabling core swapping on singe-core processors should fix this.
Additional comment from Andreas:
The BKDG says
Thermal Sensor Core Select (ThermSenseCoreSel)-Bit 2. This bit
selects the CPU whose temperature is reported in the CurTemp
field. This bit only applies to dual core processors. For
single core processors CPU0 Thermal Sensor is always selected.
k8temp_probe() correctly detected that SEL_CORE can't be used on single
core CPU. Thus k8temp did never update the temperature values stored
in temp[1][x] and -49 degrees was reported. For single core CPUs we
must use the values read into temp[0][x].
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Tested-by: Rick Moritz <rhavin@gmx.net>
Acked-by: Andreas Herrmann <andreas.herrmann3@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Christoph Fritz [Sun, 11 Jul 2010 23:26:15 +0000 (18:26 -0500)]
ssb: Handle Netbook devices where the SPROM address is changed
For some Netbook computers with Broadcom BCM4312 wireless interfaces,
the SPROM has been moved to a new location. When the ssb driver tries to
read the old location, the systems hangs when trying to read a
non-existent location. Such freezes are particularly bad as they do not
log the failure.
This patch is modified from commit
da1fdb02d9200ff28b6f3a380d21930335fe5429 with some pieces from other
mainline changes so that it can be applied to stable 2.6.34.Y.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Michael S. Tsirkin [Thu, 24 Jun 2010 04:49:06 +0000 (22:49 -0600)]
virtio-pci: disable msi at startup
commit
b03214d559471359e2a85ae256686381d0672f29 upstream.
virtio-pci resets the device at startup by writing to the status
register, but this does not clear the pci config space,
specifically msi enable status which affects register
layout.
This breaks things like kdump when they try to use e.g. virtio-blk.
Fix by forcing msi off at startup. Since pci.c already has
a routine to do this, we export and use it instead of duplicating code.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Tested-by: Vivek Goyal <vgoyal@redhat.com>
Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: linux-pci@vger.kernel.org
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Greg Kroah-Hartman [Mon, 5 Jul 2010 18:14:00 +0000 (11:14 -0700)]
Linux 2.6.32.16
Wei Yongjun [Tue, 18 May 2010 05:51:58 +0000 (22:51 -0700)]
sctp: fix append error cause to ERROR chunk correctly
commit
2e3219b5c8a2e44e0b83ae6e04f52f20a82ac0f2 upstream.
commit
5fa782c2f5ef6c2e4f04d3e228412c9b4a4c8809
sctp: Fix skb_over_panic resulting from multiple invalid \
parameter errors (CVE-2010-1173) (v4)
cause 'error cause' never be add the the ERROR chunk due to
some typo when check valid length in sctp_init_cause_fixed().
Signed-off-by: Wei Yongjun <yjwei@cn.fujitsu.com>
Reviewed-by: Neil Horman <nhorman@tuxdriver.com>
Acked-by: Vlad Yasevich <vladislav.yasevich@hp.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Ben Hutchings [Fri, 19 Mar 2010 23:59:19 +0000 (16:59 -0700)]
qla2xxx: Disable MSI on qla24xx chips other than QLA2432.
commit
6377a7ae1ab82859edccdbc8eaea63782efb134d upstream.
On specific platforms, MSI is unreliable on some of the QLA24xx chips, resulting
in fatal I/O errors under load, as reported in <http://bugs.debian.org/572322>
and by some RHEL customers.
Signed-off-by: Giridhar Malavali <giridhar.malavali@qlogic.com>
Signed-off-by: James Bottomley <James.Bottomley@suse.de>
Cc: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Toshiyuki Okajima [Fri, 30 Apr 2010 13:32:13 +0000 (14:32 +0100)]
KEYS: find_keyring_by_name() can gain access to a freed keyring
commit
cea7daa3589d6b550546a8c8963599f7c1a3ae5c upstream.
find_keyring_by_name() can gain access to a keyring that has had its reference
count reduced to zero, and is thus ready to be freed. This then allows the
dead keyring to be brought back into use whilst it is being destroyed.
The following timeline illustrates the process:
|(cleaner) (user)
|
| free_user(user) sys_keyctl()
| | |
| key_put(user->session_keyring) keyctl_get_keyring_ID()
| || //=> keyring->usage = 0 |
| |schedule_work(&key_cleanup_task) lookup_user_key()
| || |
| kmem_cache_free(,user) |
| . |[KEY_SPEC_USER_KEYRING]
| . install_user_keyrings()
| . ||
| key_cleanup() [<= worker_thread()] ||
| | ||
| [spin_lock(&key_serial_lock)] |[mutex_lock(&key_user_keyr..mutex)]
| | ||
| atomic_read() == 0 ||
| |{ rb_ease(&key->serial_node,) } ||
| | ||
| [spin_unlock(&key_serial_lock)] |find_keyring_by_name()
| | |||
| keyring_destroy(keyring) ||[read_lock(&keyring_name_lock)]
| || |||
| |[write_lock(&keyring_name_lock)] ||atomic_inc(&keyring->usage)
| |. ||| *** GET freeing keyring ***
| |. ||[read_unlock(&keyring_name_lock)]
| || ||
| |list_del() |[mutex_unlock(&key_user_k..mutex)]
| || |
| |[write_unlock(&keyring_name_lock)] ** INVALID keyring is returned **
| | .
| kmem_cache_free(,keyring) .
| .
| atomic_dec(&keyring->usage)
v *** DESTROYED ***
TIME
If CONFIG_SLUB_DEBUG=y then we may see the following message generated:
=============================================================================
BUG key_jar: Poison overwritten
-----------------------------------------------------------------------------
INFO: 0xffff880197a7e200-0xffff880197a7e200. First byte 0x6a instead of 0x6b
INFO: Allocated in key_alloc+0x10b/0x35f age=25 cpu=1 pid=5086
INFO: Freed in key_cleanup+0xd0/0xd5 age=12 cpu=1 pid=10
INFO: Slab 0xffffea000592cb90 objects=16 used=2 fp=0xffff880197a7e200 flags=0x200000000000c3
INFO: Object 0xffff880197a7e200 @offset=512 fp=0xffff880197a7e300
Bytes b4 0xffff880197a7e1f0: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZZZZZZZZZ
Object 0xffff880197a7e200: 6a 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b jkkkkkkkkkkkkkkk
Alternatively, we may see a system panic happen, such as:
BUG: unable to handle kernel NULL pointer dereference at
0000000000000001
IP: [<
ffffffff810e61a3>] kmem_cache_alloc+0x5b/0xe9
PGD
6b2b4067 PUD
6a80d067 PMD 0
Oops: 0000 [#1] SMP
last sysfs file: /sys/kernel/kexec_crash_loaded
CPU 1
...
Pid: 31245, comm: su Not tainted 2.6.34-rc5-nofixed-nodebug #2 D2089/PRIMERGY
RIP: 0010:[<
ffffffff810e61a3>] [<
ffffffff810e61a3>] kmem_cache_alloc+0x5b/0xe9
RSP: 0018:
ffff88006af3bd98 EFLAGS:
00010002
RAX:
0000000000000000 RBX:
0000000000000001 RCX:
ffff88007d19900b
RDX:
0000000100000000 RSI:
00000000000080d0 RDI:
ffffffff81828430
RBP:
ffffffff81828430 R08:
ffff88000a293750 R09:
0000000000000000
R10:
0000000000000001 R11:
0000000000100000 R12:
00000000000080d0
R13:
00000000000080d0 R14:
0000000000000296 R15:
ffffffff810f20ce
FS:
00007f97116bc700(0000) GS:
ffff88000a280000(0000) knlGS:
0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0:
0000000080050033
CR2:
0000000000000001 CR3:
000000006a91c000 CR4:
00000000000006e0
DR0:
0000000000000000 DR1:
0000000000000000 DR2:
0000000000000000
DR3:
0000000000000000 DR6:
00000000ffff0ff0 DR7:
0000000000000400
Process su (pid: 31245, threadinfo
ffff88006af3a000, task
ffff8800374414c0)
Stack:
0000000512e0958e 0000000000008000 ffff880037f8d180 0000000000000001
0000000000000000 0000000000008001 ffff88007d199000 ffffffff810f20ce
0000000000008000 ffff88006af3be48 0000000000000024 ffffffff810face3
Call Trace:
[<
ffffffff810f20ce>] ? get_empty_filp+0x70/0x12f
[<
ffffffff810face3>] ? do_filp_open+0x145/0x590
[<
ffffffff810ce208>] ? tlb_finish_mmu+0x2a/0x33
[<
ffffffff810ce43c>] ? unmap_region+0xd3/0xe2
[<
ffffffff810e4393>] ? virt_to_head_page+0x9/0x2d
[<
ffffffff81103916>] ? alloc_fd+0x69/0x10e
[<
ffffffff810ef4ed>] ? do_sys_open+0x56/0xfc
[<
ffffffff81008a02>] ? system_call_fastpath+0x16/0x1b
Code: 0f 1f 44 00 00 49 89 c6 fa 66 0f 1f 44 00 00 65 4c 8b 04 25 60 e8 00 00 48 8b 45 00 49 01 c0 49 8b 18 48 85 db 74 0d 48 63 45 18 <48> 8b 04 03 49 89 00 eb 14 4c 89 f9 83 ca ff 44 89 e6 48 89 ef
RIP [<
ffffffff810e61a3>] kmem_cache_alloc+0x5b/0xe9
This problem is that find_keyring_by_name does not confirm that the keyring is
valid before accepting it.
Skipping keyrings that have been reduced to a zero count seems the way to go.
To this end, use atomic_inc_not_zero() to increment the usage count and skip
the candidate keyring if that returns false.
The following script _may_ cause the bug to happen, but there's no guarantee
as the window of opportunity is small:
#!/bin/sh
LOOP=100000
USER=dummy_user
/bin/su -c "exit;" $USER || { /usr/sbin/adduser -m $USER; add=1; }
for ((i=0; i<LOOP; i++))
do
/bin/su -c "echo '$i' > /dev/null" $USER
done
(( add == 1 )) && /usr/sbin/userdel -r $USER
exit
Note that the nominated user must not be in use.
An alternative way of testing this may be:
for ((i=0; i<100000; i++))
do
keyctl session foo /bin/true || break
done >&/dev/null
as that uses a keyring named "foo" rather than relying on the user and
user-session named keyrings.
Reported-by: Toshiyuki Okajima <toshi.okajima@jp.fujitsu.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Tested-by: Toshiyuki Okajima <toshi.okajima@jp.fujitsu.com>
Acked-by: Serge Hallyn <serue@us.ibm.com>
Signed-off-by: James Morris <jmorris@namei.org>
Cc: Ben Hutchings <ben@decadent.org.uk>
Cc: Chuck Ebbert <cebbert@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Dan Carpenter [Mon, 17 May 2010 13:42:35 +0000 (14:42 +0100)]
KEYS: Return more accurate error codes
commit
4d09ec0f705cf88a12add029c058b53f288cfaa2 upstream.
We were using the wrong variable here so the error codes weren't being returned
properly. The original code returns -ENOKEY.
Signed-off-by: Dan Carpenter <error27@gmail.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: James Morris <jmorris@namei.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Mikulas Patocka [Thu, 10 Dec 2009 23:52:08 +0000 (23:52 +0000)]
dm snapshot: simplify sector_to_chunk expression
commit
102c6ddb1d081a6a1fede38c43a42c9811313ec7 upstream.
Removed unnecessary 'and' masking: The right shift discards the lower
bits so there is no need to clear them.
(A later patch needs this change to support a 32-bit chunk_mask.)
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Reviewed-by: Mike Snitzer <snitzer@redhat.com>
Reviewed-by: Jonathan Brassow <jbrassow@redhat.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Helge Deller [Mon, 3 May 2010 20:44:21 +0000 (20:44 +0000)]
parisc: clear floating point exception flag on SIGFPE signal
commit
550f0d922286556c7ea43974bb7921effb5a5278 upstream.
Clear the floating point exception flag before returning to
user space. This is needed, else the libc trampoline handler
may hit the same SIGFPE again while building up a trampoline
to a signal handler.
Fixes debian bug #559406.
Signed-off-by: Helge Deller <deller@gmx.de>
Signed-off-by: Kyle McMartin <kyle@mcmartin.ca>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Yin Kangkai [Tue, 15 Dec 2009 22:48:25 +0000 (14:48 -0800)]
jbd: jbd-debug and jbd2-debug should be writable
commit
765f8361902d015c864d5e62019b2f139452d7ef upstream.
jbd-debug and jbd2-debug is currently read-only (S_IRUGO), which is not
correct. Make it writable so that we can start debuging.
Signed-off-by: Yin Kangkai <kangkai.yin@intel.com>
Reviewed-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Jan Kara <jack@suse.cz>
Cc: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Roedel, Joerg [Thu, 6 May 2010 09:38:43 +0000 (11:38 +0200)]
KVM: x86: Inject #GP with the right rip on efer writes
This patch fixes a bug in the KVM efer-msr write path. If a
guest writes to a reserved efer bit the set_efer function
injects the #GP directly. The architecture dependent wrmsr
function does not see this, assumes success and advances the
rip. This results in a #GP in the guest with the wrong rip.
This patch fixes this by reporting efer write errors back to
the architectural wrmsr function.
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
Signed-off-by: Avi Kivity <avi@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
(cherry picked from commit
b69e8caef5b190af48c525f6d715e7b7728a77f6)
Avi Kivity [Thu, 13 May 2010 08:50:19 +0000 (11:50 +0300)]
KVM: x86: Add missing locking to arch specific vcpu ioctls
Signed-off-by: Avi Kivity <avi@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
(cherry picked from commit
8fbf065d625617bbbf6b72d5f78f84ad13c8b547)
Avi Kivity [Tue, 4 May 2010 12:00:37 +0000 (15:00 +0300)]
KVM: Fix wallclock version writing race
Wallclock writing uses an unprotected global variable to hold the version;
this can cause one guest to interfere with another if both write their
wallclock at the same time.
Acked-by: Glauber Costa <glommer@redhat.com>
Signed-off-by: Avi Kivity <avi@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
(cherry picked from commit
9ed3c444ab8987c7b219173a2f7807e3f71e234e)
Avi Kivity [Tue, 4 May 2010 09:58:32 +0000 (12:58 +0300)]
KVM: MMU: Don't read pdptrs with mmu spinlock held in mmu_alloc_roots
On svm, kvm_read_pdptr() may require reading guest memory, which can sleep.
Push the spinlock into mmu_alloc_roots(), and only take it after we've read
the pdptr.
Tested-by: Joerg Roedel <joerg.roedel@amd.com>
Signed-off-by: Avi Kivity <avi@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
(cherry picked from commit
8facbbff071ff2b19268d3732e31badc60471e21)
Shane Wang [Thu, 29 Apr 2010 16:09:01 +0000 (12:09 -0400)]
KVM: VMX: enable VMXON check with SMX enabled (Intel TXT)
Per document, for feature control MSR:
Bit 1 enables VMXON in SMX operation. If the bit is clear, execution
of VMXON in SMX operation causes a general-protection exception.
Bit 2 enables VMXON outside SMX operation. If the bit is clear, execution
of VMXON outside SMX operation causes a general-protection exception.
This patch is to enable this kind of check with SMX for VMXON in KVM.
Signed-off-by: Shane Wang <shane.wang@intel.com>
Signed-off-by: Avi Kivity <avi@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
(cherry picked from commit
cafd66595d92591e4bd25c3904e004fc6f897e2d)
Avi Kivity [Wed, 12 May 2010 08:48:18 +0000 (11:48 +0300)]
KVM: MMU: Segregate shadow pages with different cr0.wp
When cr0.wp=0, we may shadow a gpte having u/s=1 and r/w=0 with an spte
having u/s=0 and r/w=1. This allows excessive access if the guest sets
cr0.wp=1 and accesses through this spte.
Fix by making cr0.wp part of the base role; we'll have different sptes for
the two cases and the problem disappears.
Signed-off-by: Avi Kivity <avi@redhat.com>
Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
(cherry picked from commit
3dbe141595faa48a067add3e47bba3205b79d33c)
Sheng Yang [Wed, 12 May 2010 08:40:40 +0000 (16:40 +0800)]
KVM: x86: Check LMA bit before set_efer
kvm_x86_ops->set_efer() would execute vcpu->arch.efer = efer, so the
checking of LMA bit didn't work.
Signed-off-by: Sheng Yang <sheng@linux.intel.com>
Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
(cherry picked from commit
a3d204e28579427609c3d15d2310127ebaa47d94)
Avi Kivity [Tue, 11 May 2010 21:28:44 +0000 (00:28 +0300)]
KVM: Don't allow lmsw to clear cr0.pe
The current lmsw implementation allows the guest to clear cr0.pe, contrary
to the manual, which breaks EMM386.EXE.
Fix by ORing the old cr0.pe with lmsw's operand.
Signed-off-by: Avi Kivity <avi@redhat.com>
Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
(cherry picked from commit
f78e917688edbf1f14c318d2e50dc8e7dad20445)
Glauber Costa [Tue, 11 May 2010 16:17:40 +0000 (12:17 -0400)]
x86, paravirt: Add a global synchronization point for pvclock
In recent stress tests, it was found that pvclock-based systems
could seriously warp in smp systems. Using ingo's time-warp-test.c,
I could trigger a scenario as bad as 1.5mi warps a minute in some systems.
(to be fair, it wasn't that bad in most of them). Investigating further, I
found out that such warps were caused by the very offset-based calculation
pvclock is based on.
This happens even on some machines that report constant_tsc in its tsc flags,
specially on multi-socket ones.
Two reads of the same kernel timestamp at approx the same time, will likely
have tsc timestamped in different occasions too. This means the delta we
calculate is unpredictable at best, and can probably be smaller in a cpu
that is legitimately reading clock in a forward ocasion.
Some adjustments on the host could make this window less likely to happen,
but still, it pretty much poses as an intrinsic problem of the mechanism.
A while ago, I though about using a shared variable anyway, to hold clock
last state, but gave up due to the high contention locking was likely
to introduce, possibly rendering the thing useless on big machines. I argue,
however, that locking is not necessary.
We do a read-and-return sequence in pvclock, and between read and return,
the global value can have changed. However, it can only have changed
by means of an addition of a positive value. So if we detected that our
clock timestamp is less than the current global, we know that we need to
return a higher one, even though it is not exactly the one we compared to.
OTOH, if we detect we're greater than the current time source, we atomically
replace the value with our new readings. This do causes contention on big
boxes (but big here means *BIG*), but it seems like a good trade off, since
it provide us with a time source guaranteed to be stable wrt time warps.
After this patch is applied, I don't see a single warp in time during 5 days
of execution, in any of the machines I saw them before.
Signed-off-by: Glauber Costa <glommer@redhat.com>
Acked-by: Zachary Amsden <zamsden@redhat.com>
CC: Jeremy Fitzhardinge <jeremy@goop.org>
CC: Avi Kivity <avi@redhat.com>
CC: Marcelo Tosatti <mtosatti@redhat.com>
CC: Zachary Amsden <zamsden@redhat.com>
Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
(cherry picked from commit
489fb490dbf8dab0249ad82b56688ae3842a79e8)
Wei Yongjun [Tue, 9 Mar 2010 06:13:43 +0000 (14:13 +0800)]
KVM: PPC: Do not create debugfs if fail to create vcpu
If fail to create the vcpu, we should not create the debugfs
for it.
Signed-off-by: Wei Yongjun <yjwei@cn.fujitsu.com>
Acked-by: Alexander Graf <agraf@suse.de>
Cc: stable@kernel.org
Signed-off-by: Avi Kivity <avi@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
(cherry picked from commit
06056bfb944a0302a8f22eb45f09123de7fb417b)
Wei Yongjun [Tue, 9 Mar 2010 06:37:53 +0000 (14:37 +0800)]
KVM: s390: Fix possible memory leak of in kvm_arch_vcpu_create()
This patch fixed possible memory leak in kvm_arch_vcpu_create()
under s390, which would happen when kvm_arch_vcpu_create() fails.
Signed-off-by: Wei Yongjun <yjwei@cn.fujitsu.com>
Acked-by: Carsten Otte <cotte@de.ibm.com>
Cc: stable@kernel.org
Signed-off-by: Avi Kivity <avi@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
(cherry picked from commit
7b06bf2ffa15e119c7439ed0b024d44f66d7b605)
Dmitry Torokhov [Thu, 13 May 2010 07:42:23 +0000 (00:42 -0700)]
Input: psmouse - reset all types of mice before reconnecting
commit
ef110b24e28f36620f63dab94708a17c7e267358 upstream.
Synaptics hardware requires resetting device after suspend to ram
in order for the device to be operational. The reset lives in
synaptics-specific reconnect handler, but it is not being invoked
if synaptics support is disabled and the device is handled as a
standard PS/2 device (bare or IntelliMouse protocol).
Let's add reset into generic reconnect handler as well.
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
Cc: Tim Gardner <tim.gardner@canonical.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Neil Horman [Wed, 3 Mar 2010 08:31:23 +0000 (08:31 +0000)]
tipc: Fix oops on send prior to entering networked mode (v3)
commit
d0021b252eaf65ca07ed14f0d66425dd9ccab9a6 upstream.
Fix TIPC to disallow sending to remote addresses prior to entering NET_MODE
user programs can oops the kernel by sending datagrams via AF_TIPC prior to
entering networked mode. The following backtrace has been observed:
ID: 13459 TASK:
ffff810014640040 CPU: 0 COMMAND: "tipc-client"
[exception RIP: tipc_node_select_next_hop+90]
RIP:
ffffffff8869d3c3 RSP:
ffff81002d9a5ab8 RFLAGS:
00010202
RAX:
0000000000000001 RBX:
0000000000000001 RCX:
0000000000000001
RDX:
0000000000000000 RSI:
0000000000000001 RDI:
0000000001001001
RBP:
0000000001001001 R8:
0074736575716552 R9:
0000000000000000
R10:
ffff81003fbd0680 R11:
00000000000000c8 R12:
0000000000000008
R13:
0000000000000001 R14:
0000000000000001 R15:
ffff810015c6ca00
ORIG_RAX:
ffffffffffffffff CS: 0010 SS: 0018
RIP:
0000003cbd8d49a3 RSP:
00007fffc84e0be8 RFLAGS:
00010206
RAX:
000000000000002c RBX:
ffffffff8005d116 RCX:
0000000000000000
RDX:
0000000000000008 RSI:
00007fffc84e0c00 RDI:
0000000000000003
RBP:
0000000000000000 R8:
00007fffc84e0c10 R9:
0000000000000010
R10:
0000000000000000 R11:
0000000000000246 R12:
0000000000000000
R13:
00007fffc84e0d10 R14:
0000000000000000 R15:
00007fffc84e0c30
ORIG_RAX:
000000000000002c CS: 0033 SS: 002b
What happens is that, when the tipc module in inserted it enters a standalone
node mode in which communication to its own address is allowed <0.0.0> but not
to other addresses, since the appropriate data structures have not been
allocated yet (specifically the tipc_net pointer). There is nothing stopping a
client from trying to send such a message however, and if that happens, we
attempt to dereference tipc_net.zones while the pointer is still NULL, and
explode. The fix is pretty straightforward. Since these oopses all arise from
the dereference of global pointers prior to their assignment to allocated
values, and since these allocations are small (about 2k total), lets convert
these pointers to static arrays of the appropriate size. All the accesses to
these bits consider 0/NULL to be a non match when searching, so all the lookups
still work properly, and there is no longer a chance of a bad dererence
anywhere. As a bonus, this lets us eliminate the setup/teardown routines for
those pointers, and elimnates the need to preform any locking around them to
prevent access while their being allocated/freed.
I've updated the tipc_net structure to behave this way to fix the exact reported
problem, and also fixed up the tipc_bearers and media_list arrays to fix an
obvious simmilar problem that arises from issuing tipc-config commands to
manipulate bearers/links prior to entering networked mode
I've tested this for a few hours by running the sanity tests and stress test
with the tipcutils suite, and nothing has fallen over. There have been a few
lockdep warnings, but those were there before, and can be addressed later, as
they didn't actually result in any deadlock.
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
CC: Allan Stephens <allan.stephens@windriver.com>
CC: David S. Miller <davem@davemloft.net>
CC: tipc-discussion@lists.sourceforge.net
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Jiajun Wu [Mon, 18 Jan 2010 05:47:50 +0000 (05:47 +0000)]
ucc_geth: Fix full TX queue processing
commit
34692421bc7d6145ef383b014860f4fde10b7505 upstream.
commit
7583605b6d29f1f7f6fc505b883328089f3485ad ("ucc_geth: Fix empty
TX queue processing") fixed empty TX queue mishandling, but didn't
account another corner case: when TX queue becomes full.
Without this patch the driver will stop transmiting when TX queue
becomes full since 'bd == ugeth->txBd[txQ]' actually checks for
two things: queue empty or full.
Let's better check for NULL skb, which unambiguously signals an empty
queue.
Signed-off-by: Jiajun Wu <b06378@freescale.com>
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Anton Vorontsov [Thu, 24 Dec 2009 05:31:05 +0000 (05:31 +0000)]
ucc_geth: Fix netdev watchdog triggering on link changes
commit
08b5e1c91ce95793c59a59529a362a1bcc81faae upstream.
Since commit
864fdf884e82bacbe8ca5e93bd43393a61d2e2b4 ("ucc_geth:
Fix hangs after switching from full to half duplex") ucc_geth driver
disables the controller during MAC configuration changes. Though,
disabling the controller might take quite awhile, and so the netdev
watchdog might get upset:
NETDEV WATCHDOG: eth2 (ucc_geth): transmit queue 0 timed out
------------[ cut here ]------------
Badness at
c02729a8 [verbose debug info unavailable]
NIP:
c02729a8 LR:
c02729a8 CTR:
c01b6088
REGS:
c0451c40 TRAP: 0700 Not tainted (2.6.32-trunk-8360e)
[...]
NIP [
c02729a8] dev_watchdog+0x280/0x290
LR [
c02729a8] dev_watchdog+0x280/0x290
Call Trace:
[
c0451cf0] [
c02729a8] dev_watchdog+0x280/0x290 (unreliable)
[
c0451d50] [
c00377c4] run_timer_softirq+0x164/0x224
[
c0451da0] [
c0032a38] __do_softirq+0xb8/0x13c
[
c0451df0] [
c00065cc] do_softirq+0xa0/0xac
[
c0451e00] [
c003280c] irq_exit+0x7c/0x9c
[
c0451e10] [
c00640c4] __ipipe_sync_stage+0x248/0x24c
[...]
This patch fixes the issue by detaching the netdev during the
time we change the configuration.
Reported-by: Lennart Sorensen <lsorense@csclub.uwaterloo.ca>
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Tested-by: Lennart Sorensen <lsorense@csclub.uwaterloo.ca>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Anton Vorontsov [Thu, 24 Dec 2009 05:31:03 +0000 (05:31 +0000)]
ucc_geth: Fix empty TX queue processing
commit
7583605b6d29f1f7f6fc505b883328089f3485ad upstream.
Following oops was seen with the ucc_geth driver:
Unable to handle kernel paging request for data at address 0x00000058
Faulting instruction address: 0xc024f2fc
Oops: Kernel access of bad area, sig: 11 [#1]
[...]
NIP [
c024f2fc] skb_recycle_check+0x14/0x100
LR [
e30aa0a4] ucc_geth_poll+0xd8/0x4e0 [ucc_geth_driver]
Call Trace:
[
df857d50] [
c000b03c] __ipipe_grab_irq+0x3c/0xa4 (unreliable)
[
df857d60] [
e30aa0a4] ucc_geth_poll+0xd8/0x4e0 [ucc_geth_driver]
[
df857dd0] [
c0258cf8] net_rx_action+0xf8/0x1b8
[
df857e10] [
c0032a38] __do_softirq+0xb8/0x13c
[
df857e60] [
c00065cc] do_softirq+0xa0/0xac
[...]
This is because ucc_geth_tx() tries to process an empty queue when
queues are logically stopped. Stopping the queues doesn't disable
polling, and since nowadays ucc_geth_tx() is actually called from
the polling routine, the oops above might pop up.
Fix this by removing 'netif_queue_stopped() == 0' check.
Reported-by: Lennart Sorensen <lsorense@csclub.uwaterloo.ca>
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Tested-by: Lennart Sorensen <lsorense@csclub.uwaterloo.ca>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Shi Weihua [Tue, 18 May 2010 00:50:32 +0000 (00:50 +0000)]
Btrfs: should add a permission check for setfacl
commit
2f26afba46f0ebf155cf9be746496a0304a5b7cf upstream.
On btrfs, do the following
------------------
# su user1
# cd btrfs-part/
# touch aaa
# getfacl aaa
# file: aaa
# owner: user1
# group: user1
user::rw-
group::rw-
other::r--
# su user2
# cd btrfs-part/
# setfacl -m u::rwx aaa
# getfacl aaa
# file: aaa
# owner: user1
# group: user1
user::rwx <- successed to setfacl
group::rw-
other::r--
------------------
but we should prohibit it that user2 changing user1's acl.
In fact, on ext3 and other fs, a message occurs:
setfacl: aaa: Operation not permitted
This patch fixed it.
Signed-off-by: Shi Weihua <shiwh@cn.fujitsu.com>
Signed-off-by: Chris Mason <chris.mason@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
James Chapman [Tue, 16 Mar 2010 06:46:31 +0000 (06:46 +0000)]
l2tp: Fix oops in pppol2tp_xmit
commit
3feec9095d12e311b7d4eb7fe7e5dfa75d4a72a5 upstream.
When transmitting L2TP frames, we derive the outgoing interface's UDP
checksum hardware assist capabilities from the tunnel dst dev. This
can sometimes be NULL, especially when routing protocols are used and
routing changes occur. This patch just checks for NULL dst or dev
pointers when checking for netdev hardware assist features.
BUG: unable to handle kernel NULL pointer dereference at
0000000c
IP: [<
f89d074c>] pppol2tp_xmit+0x341/0x4da [pppol2tp]
*pde =
00000000
Oops: 0000 [#1] SMP
last sysfs file: /sys/class/net/lo/operstate
Modules linked in: pppol2tp pppox ppp_generic slhc ipv6 dummy loop snd_hda_codec_atihdmi snd_hda_intel snd_hda_codec snd_pcm snd_timer snd soundcore snd_page_alloc evdev psmouse serio_raw processor button i2c_piix4 i2c_core ati_agp agpgart pcspkr ext3 jbd mbcache sd_mod ide_pci_generic atiixp ide_core ahci ata_generic floppy ehci_hcd ohci_hcd libata e1000e scsi_mod usbcore nls_base thermal fan thermal_sys [last unloaded: scsi_wait_scan]
Pid: 0, comm: swapper Not tainted (2.6.32.8 #1)
EIP: 0060:[<
f89d074c>] EFLAGS:
00010297 CPU: 3
EIP is at pppol2tp_xmit+0x341/0x4da [pppol2tp]
EAX:
00000000 EBX:
f64d1680 ECX:
000005b9 EDX:
00000000
ESI:
f6b91850 EDI:
f64d16ac EBP:
f6a0c4c0 ESP:
f70a9cac
DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
Process swapper (pid: 0, ti=
f70a8000 task=
f70a31c0 task.ti=
f70a8000)
Stack:
000005a9 000005b9 f734c400 f66652c0 f7352e00 f67dc800 00000000 f6b91800
<0>
000005a3 f70ef6c4 f67dcda9 000005a3 f89b192e 00000246 000005a3 f64d1680
<0>
f63633e0 f6363320 f64d1680 f65a7320 f65a7364 f65856c0 f64d1680 f679f02f
Call Trace:
[<
f89b192e>] ? ppp_push+0x459/0x50e [ppp_generic]
[<
f89b217f>] ? ppp_xmit_process+0x3b6/0x430 [ppp_generic]
[<
f89b2306>] ? ppp_start_xmit+0x10d/0x120 [ppp_generic]
[<
c11c15cb>] ? dev_hard_start_xmit+0x21f/0x2b2
[<
c11d0947>] ? sch_direct_xmit+0x48/0x10e
[<
c11c19a0>] ? dev_queue_xmit+0x263/0x3a6
[<
c11e2a9f>] ? ip_finish_output+0x1f7/0x221
[<
c11df682>] ? ip_forward_finish+0x2e/0x30
[<
c11de645>] ? ip_rcv_finish+0x295/0x2a9
[<
c11c0b19>] ? netif_receive_skb+0x3e9/0x404
[<
f814b791>] ? e1000_clean_rx_irq+0x253/0x2fc [e1000e]
[<
f814cb7a>] ? e1000_clean+0x63/0x1fc [e1000e]
[<
c1047eff>] ? sched_clock_local+0x15/0x11b
[<
c11c1095>] ? net_rx_action+0x96/0x195
[<
c1035750>] ? __do_softirq+0xaa/0x151
[<
c1035828>] ? do_softirq+0x31/0x3c
[<
c10358fe>] ? irq_exit+0x26/0x58
[<
c1004b21>] ? do_IRQ+0x78/0x89
[<
c1003729>] ? common_interrupt+0x29/0x30
[<
c101ac28>] ? native_safe_halt+0x2/0x3
[<
c1008c54>] ? default_idle+0x55/0x75
[<
c1009045>] ? c1e_idle+0xd2/0xd5
[<
c100233c>] ? cpu_idle+0x46/0x62
Code: 8d 45 08 f0 ff 45 08 89 6b 08 c7 43 68 7e fb 9c f8 8a 45 24 83 e0 0c 3c 04 75 09 80 63 64 f3 e9 b4 00 00 00 8b 43 18 8b 4c 24 04 <8b> 40 0c 8d 79 11 f6 40 44 0e 8a 43 64 75 51 6a 00 8b 4c 24 08
EIP: [<
f89d074c>] pppol2tp_xmit+0x341/0x4da [pppol2tp] SS:ESP 0068:
f70a9cac
CR2:
000000000000000c
Signed-off-by: James Chapman <jchapman@katalix.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Miklos Szeredi [Wed, 10 Feb 2010 11:15:53 +0000 (12:15 +0100)]
vfs: add NOFOLLOW flag to umount(2)
commit
db1f05bb85d7966b9176e293f3ceead1cb8b5d79 upstream.
Add a new UMOUNT_NOFOLLOW flag to umount(2). This is needed to prevent
symlink attacks in unprivileged unmounts (fuse, samba, ncpfs).
Additionally, return -EINVAL if an unknown flag is used (and specify
an explicitly unused flag: UMOUNT_UNUSED). This makes it possible for
the caller to determine if a flag is supported or not.
CC: Eugene Teo <eugene@redhat.com>
CC: Michael Kerrisk <mtk.manpages@gmail.com>
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>
Steve French [Thu, 22 Apr 2010 19:21:55 +0000 (19:21 +0000)]
CIFS: Allow null nd (as nfs server uses) on create
commit
fa588e0c57048b3d4bfcd772d80dc0615f83fd35 upstream.
While creating a file on a server which supports unix extensions
such as Samba, if a file is being created which does not supply
nameidata (i.e. nd is null), cifs client can oops when calling
cifs_posix_open.
Signed-off-by: Shirish Pargaonkar <shirishp@us.ibm.com>
Signed-off-by: Steve French <sfrench@us.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Neil Horman [Wed, 28 Apr 2010 10:30:59 +0000 (10:30 +0000)]
sctp: Fix skb_over_panic resulting from multiple invalid parameter errors (CVE-2010-1173) (v4)
commit
5fa782c2f5ef6c2e4f04d3e228412c9b4a4c8809 upstream.
Ok, version 4
Change Notes:
1) Minor cleanups, from Vlads notes
Summary:
Hey-
Recently, it was reported to me that the kernel could oops in the
following way:
<5> kernel BUG at net/core/skbuff.c:91!
<5> invalid operand: 0000 [#1]
<5> Modules linked in: sctp netconsole nls_utf8 autofs4 sunrpc iptable_filter
ip_tables cpufreq_powersave parport_pc lp parport vmblock(U) vsock(U) vmci(U)
vmxnet(U) vmmemctl(U) vmhgfs(U) acpiphp dm_mirror dm_mod button battery ac md5
ipv6 uhci_hcd ehci_hcd snd_ens1371 snd_rawmidi snd_seq_device snd_pcm_oss
snd_mixer_oss snd_pcm snd_timer snd_page_alloc snd_ac97_codec snd soundcore
pcnet32 mii floppy ext3 jbd ata_piix libata mptscsih mptsas mptspi mptscsi
mptbase sd_mod scsi_mod
<5> CPU: 0
<5> EIP: 0060:[<
c02bff27>] Not tainted VLI
<5> EFLAGS:
00010216 (2.6.9-89.0.25.EL)
<5> EIP is at skb_over_panic+0x1f/0x2d
<5> eax:
0000002c ebx:
c033f461 ecx:
c0357d96 edx:
c040fd44
<5> esi:
c033f461 edi:
df653280 ebp:
00000000 esp:
c040fd40
<5> ds: 007b es: 007b ss: 0068
<5> Process swapper (pid: 0, threadinfo=
c040f000 task=
c0370be0)
<5> Stack:
c0357d96 e0c29478 00000084 00000004 c033f461 df653280 d7883180
e0c2947d
<5>
00000000 00000080 df653490 00000004 de4f1ac0 de4f1ac0 00000004
df653490
<5>
00000001 e0c2877a 08000800 de4f1ac0 df653490 00000000 e0c29d2e
00000004
<5> Call Trace:
<5> [<
e0c29478>] sctp_addto_chunk+0xb0/0x128 [sctp]
<5> [<
e0c2947d>] sctp_addto_chunk+0xb5/0x128 [sctp]
<5> [<
e0c2877a>] sctp_init_cause+0x3f/0x47 [sctp]
<5> [<
e0c29d2e>] sctp_process_unk_param+0xac/0xb8 [sctp]
<5> [<
e0c29e90>] sctp_verify_init+0xcc/0x134 [sctp]
<5> [<
e0c20322>] sctp_sf_do_5_1B_init+0x83/0x28e [sctp]
<5> [<
e0c25333>] sctp_do_sm+0x41/0x77 [sctp]
<5> [<
c01555a4>] cache_grow+0x140/0x233
<5> [<
e0c26ba1>] sctp_endpoint_bh_rcv+0xc5/0x108 [sctp]
<5> [<
e0c2b863>] sctp_inq_push+0xe/0x10 [sctp]
<5> [<
e0c34600>] sctp_rcv+0x454/0x509 [sctp]
<5> [<
e084e017>] ipt_hook+0x17/0x1c [iptable_filter]
<5> [<
c02d005e>] nf_iterate+0x40/0x81
<5> [<
c02e0bb9>] ip_local_deliver_finish+0x0/0x151
<5> [<
c02e0c7f>] ip_local_deliver_finish+0xc6/0x151
<5> [<
c02d0362>] nf_hook_slow+0x83/0xb5
<5> [<
c02e0bb2>] ip_local_deliver+0x1a2/0x1a9
<5> [<
c02e0bb9>] ip_local_deliver_finish+0x0/0x151
<5> [<
c02e103e>] ip_rcv+0x334/0x3b4
<5> [<
c02c66fd>] netif_receive_skb+0x320/0x35b
<5> [<
e0a0928b>] init_stall_timer+0x67/0x6a [uhci_hcd]
<5> [<
c02c67a4>] process_backlog+0x6c/0xd9
<5> [<
c02c690f>] net_rx_action+0xfe/0x1f8
<5> [<
c012a7b1>] __do_softirq+0x35/0x79
<5> [<
c0107efb>] handle_IRQ_event+0x0/0x4f
<5> [<
c01094de>] do_softirq+0x46/0x4d
Its an skb_over_panic BUG halt that results from processing an init chunk in
which too many of its variable length parameters are in some way malformed.
The problem is in sctp_process_unk_param:
if (NULL == *errp)
*errp = sctp_make_op_error_space(asoc, chunk,
ntohs(chunk->chunk_hdr->length));
if (*errp) {
sctp_init_cause(*errp, SCTP_ERROR_UNKNOWN_PARAM,
WORD_ROUND(ntohs(param.p->length)));
sctp_addto_chunk(*errp,
WORD_ROUND(ntohs(param.p->length)),
param.v);
When we allocate an error chunk, we assume that the worst case scenario requires
that we have chunk_hdr->length data allocated, which would be correct nominally,
given that we call sctp_addto_chunk for the violating parameter. Unfortunately,
we also, in sctp_init_cause insert a sctp_errhdr_t structure into the error
chunk, so the worst case situation in which all parameters are in violation
requires chunk_hdr->length+(sizeof(sctp_errhdr_t)*param_count) bytes of data.
The result of this error is that a deliberately malformed packet sent to a
listening host can cause a remote DOS, described in CVE-2010-1173:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=2010-1173
I've tested the below fix and confirmed that it fixes the issue. We move to a
strategy whereby we allocate a fixed size error chunk and ignore errors we don't
have space to report. Tested by me successfully
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
Acked-by: Vlad Yasevich <vladislav.yasevich@hp.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Steven Whitehouse [Mon, 24 May 2010 13:36:48 +0000 (14:36 +0100)]
GFS2: Fix permissions checking for setflags ioctl()
commit
7df0e0397b9a18358573274db9fdab991941062f upstream.
We should be checking for the ownership of the file for which
flags are being set, rather than just for write access.
Reported-by: Dan Rosenberg <dan.j.rosenberg@gmail.com>
Signed-off-by: Steven Whitehouse <swhiteho@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Grazvydas Ignotas [Fri, 4 Jun 2010 23:25:47 +0000 (02:25 +0300)]
wl1251: fix a memory leak in probe
commit
aa679c36756003f1fabdb9fc6f00eb159559f7c3 upstream.
wl1251_sdio_probe() error path is missing wl1251_free_hw, add it.
Signed-off-by: Grazvydas Ignotas <notasas@gmail.com>
Acked-by: Kalle Valo <kvalo@adurom.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Wey-Yi Guy [Fri, 20 Nov 2009 20:05:03 +0000 (12:05 -0800)]
iwlwifi: update supported PCI_ID list for 5xx0 series
commit
ac592574a577162183b5c1dd040a188caa068a29 upstream.
Update the PCI_ID list for 5xx0 series.
Remove all the PCI_IDs which never made into production or not longer in
production.
Also make sure the supported bands(a/b/g/n) match specified PCI_IDs
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Reinette Chatre [Mon, 3 May 2010 17:55:07 +0000 (10:55 -0700)]
iwlwifi: recalculate average tpt if not current
commit
3d79b2a9eeaa066b35c49fbb17e3156a3c482c3e upstream.
We currently have this check as a BUG_ON, which is being hit by people.
Previously it was an error with a recalculation if not current, return that
code.
The BUG_ON was introduced by:
commit
3110bef78cb4282c58245bc8fd6d95d9ccb19749
Author: Guy Cohen <guy.cohen@intel.com>
Date: Tue Sep 9 10:54:54 2008 +0800
iwlwifi: Added support for 3 antennas
... the portion adding the BUG_ON is reverted since we are encountering the error
and BUG_ON was created with assumption that error is not encountered.
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Wey-Yi Guy [Wed, 3 Feb 2010 20:24:44 +0000 (12:24 -0800)]
iwlwifi: check for aggregation frame and queue
commit
45d427001b5eec03cecaacddb53c73af46bb263e upstream.
Error checking for aggregation frames should go into aggregation queue,
if aggregation queue not available, use legacy queue instead.
Also make sure the aggregation queue is available to activate,
if driver and mac80211 is out-of-sync, try to disable the queue and
sync-up with mac80211.
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Roberto Sassu [Thu, 3 Jun 2010 09:58:28 +0000 (11:58 +0200)]
wrong type for 'magic' argument in simple_fill_super()
commit
7d683a09990ff095a91b6e724ecee0ff8733274a upstream.
It's used to superblock ->s_magic, which is unsigned long.
Signed-off-by: Roberto Sassu <roberto.sassu@polito.it>
Reviewed-by: Mimi Zohar <zohar@us.ibm.com>
Signed-off-by: Eric Paris <eparis@redhat.com>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Jesse Barnes [Fri, 12 Feb 2010 17:30:00 +0000 (09:30 -0800)]
drm/i915: give up on 8xx lid status
commit
7b9c5abee98c54f85bcc04bd4d7ec8d5094c73f4 upstream.
These old machines more often than not lie about their lid state. So
don't use it to detect LVDS presence, but leave the event handler to
deal with lid open/close, when we might need to reset the mode.
Fixes kernel bug #15248
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Eric Anholt <eric@anholt.net>
Cc: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Luis R. Rodriguez [Tue, 2 Feb 2010 16:58:33 +0000 (11:58 -0500)]
ath9k: add support for 802.11n bonded out AR2427
commit
5ffaf8a361b4c9025963959a744f21d8173c7669 upstream.
Some single chip family devices are sold in the market with
802.11n bonded out, these have no hardware capability for
802.11n but ath9k can still support them. These are called
AR2427.
[bwh: backported to 2.6.32]
Reported-by: Rolf Leggewie <bugzilla.kernel.org@rolf.leggewie.biz>
Tested-by: Bernhard Reiter <ockham@raz.or.at>
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Cc: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
John W. Linville [Wed, 9 Dec 2009 21:43:52 +0000 (16:43 -0500)]
wireless: report reasonable bitrate for MCS rates through wext
commit
254416aae70ab2e6b57fd79782c8a67196234d02 upstream.
Previously, cfg80211 had reported "0" for MCS (i.e. 802.11n) bitrates
through the wireless extensions interface. However, nl80211 was
converting MCS rates into a reasonable bitrate number. This patch moves
the nl80211 code to cfg80211 where it is now shared between both the
nl80211 interface and the wireless extensions interface.
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Cc: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Ben Hutchings [Mon, 11 Jan 2010 23:53:45 +0000 (15:53 -0800)]
Documentation/3c509: document ethtool support
commit
aa4e2e171385bb77b4da8b760d26dea2aa291587 upstream.
3c509 was changed to support ethtool in 2002, making the 'xcvr' module
parameter obsolete in most cases. More recently 3c509 was converted
to the modern driver model and this parameter was removed. Fix the
documentation to refer to ethtool rather than the module parameter.
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Ben Hutchings [Thu, 7 Jan 2010 02:41:51 +0000 (02:41 +0000)]
dmfe/tulip: Let dmfe handle DM910x except for SPARC on-board chips
commit
4d907069bc1b745f4abd4745c332d33098e733b8 upstream.
The Davicom DM9100 and DM9102 chips are used on the motherboards of
some SPARC systems (supported by the tulip driver) and also in PCI
expansion cards (supported by the dmfe driver). There is no
difference in the PCI device ids for the two different configurations,
so these drivers both claim the device ids. However, it is possible
to distinguish the two configurations by the presence of Open Firmware
properties for them, so we do that.
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Grant Grundler <grundler@parisc-linux.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Ben Hutchings [Mon, 14 Dec 2009 16:05:09 +0000 (16:05 +0000)]
via-velocity: Give RX descriptors to the NIC later on open or MTU change
commit
35bb5cadc8c7b1462df57e32e08d964f1be7a75c upstream.
velocity_open() calls velocity_give_many_rx_descs(), which gives RX
descriptors to the NIC, before installing an interrupt handler or
calling velocity_init_registers(). I think this is very unsafe and it
appears to explain the bug report <http://bugs.debian.org/508527>.
On MTU change, velocity_give_many_rx_descs() is again called before
velocity_init_registers(). I'm not sure whether this is unsafe but
it does look wrong.
Therefore, move the calls to velocity_give_many_rx_descs() after
request_irq() and velocity_init_registers().
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Tested-by: Jan Ceuleers <jan.ceuleers@computer.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Ben Hutchings [Tue, 1 Dec 2009 19:09:52 +0000 (19:09 +0000)]
atl1e: Allow TX checksum offload and TSO to be disabled and reenabled
commit
ac936929092dc6a5409b627c4c67305ab9b626b3 upstream.
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Jason Dravet [Sat, 5 Jun 2010 20:08:29 +0000 (15:08 -0500)]
p54usb: Add device ID for Dell WLA3310 USB
commit
0f666a08901f8b01f294ca0ad751019375240ae3 upstream.
Add Dell WLA3310 USB wireless card, which has a Z-Com XG-705A chipset, to the
USB Ids in p54usb.
Signed-off-by: Jason Dravet <dravet@hotmail.com>
Tested-by: Richard Gregory Tillmore <rtillmore@gmail.com>
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Acked-by: Christian Lamparter <chunkeey@googlemail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Axel Lin [Mon, 31 May 2010 00:04:47 +0000 (08:04 +0800)]
USB: cdc-acm: fix resource reclaim in error path of acm_probe
commit
c2572b78aa0447244a38e555ebb1b3b48a0088a5 upstream.
This patch fixes resource reclaim in error path of acm_probe:
1. In the case of "out of memory (read urbs usb_alloc_urb)\n")", there
is no need to call acm_read_buffers_free(acm) here. Fix it by goto
alloc_fail6 instead of alloc_fail7.
2. In the case of "out of memory (write urbs usb_alloc_urb)",
usb_alloc_urb may fail in any iteration of the for loop. Current
implementation does not properly free allocated snd->urb. Fix it by
goto alloc_fail8 instead of alloc_fail7.
3. In the case of device_create_file(&intf->dev,&dev_attr_iCountryCodeRelDate)
fail, acm->country_codes is kfreed. As a result, device_remove_file
for dev_attr_wCountryCodes will not be executed in acm_disconnect.
Fix it by calling device_remove_file for dev_attr_wCountryCodes
before goto skip_countries.
Signed-off-by: Axel Lin <axel.lin@gmail.com>
Acked-by: Oliver Neukum <oneukum@suse.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Daniel Mack [Thu, 3 Jun 2010 11:55:02 +0000 (13:55 +0200)]
USB: ftdi_sio: fix DTR/RTS line modes
commit
6a1a82df91fa0eb1cc76069a9efe5714d087eccd upstream.
Call set_mctrl() and clear_mctrl() according to the flow control mode
selected. This makes serial communication for FT232 connected devices
work when CRTSCTS is not set.
This fixes a regression introduced by
4175f3e31 ("tty_port: If we are
opened non blocking we still need to raise the carrier"). This patch
calls the low-level driver's dtr_rts() function which consequently sets
TIOCM_DTR | TIOCM_RTS. A later call to set_termios() without CRTSCTS in
cflags, however, does not reset these bits, and so data is not actually
sent out on the serial wire.
Signed-off-by: Daniel Mack <daniel@caiaq.de>
Cc: Johan Hovold <jhovold@gmail.com>
Cc: Alan Cox <alan@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Sarah Sharp [Mon, 24 May 2010 20:25:15 +0000 (13:25 -0700)]
USB: xhci: Wait for controller to be ready after reset.
commit
2d62f3eea98354d61f90d6b115eecf9be5f4bdfe upstream.
After software resets an xHCI host controller, it must wait for the
"Controller Not Ready" (CNR) bit in the status register to be cleared.
Software is not supposed to ring any doorbells or write to any registers
except the status register until this bit is cleared.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Sarah Sharp [Mon, 24 May 2010 20:25:21 +0000 (13:25 -0700)]
USB: xhci: Wait for host to start running.
commit
ed07453fd356025cc25272629e982f5e4607632c upstream.
When the run bit is set in the xHCI command register, it may take a few
microseconds for the host to start running. We cannot ring any doorbells
until the host is actually running, so wait until the status register says
the host is running.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Reported-by: Shinya Saito <shinya.saito.sx@renesas.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Johan Hovold [Wed, 19 May 2010 20:13:17 +0000 (22:13 +0200)]
USB: mos7840: fix null-pointer dereference
commit
b41709f1263bb1ad37efc43fea0bb0b670c12e78 upstream.
Fix null-pointer dereference on error path.
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Chris Wilson [Thu, 27 May 2010 12:18:18 +0000 (13:18 +0100)]
drm/i915: Rebind bo if currently bound with incorrect alignment.
commit
ac0c6b5ad3b3b513e1057806d4b7627fcc0ecc27 upstream.
Whilst pinning the buffer, check that that its current alignment
matches the requested alignment. If it does not, rebind.
This should clear up any final render errors whilst resuming,
for reference:
Bug 27070 - [i915] Page table errors with empty ringbuffer
https://bugs.freedesktop.org/show_bug.cgi?id=27070
Bug 15502 - render error detected, EIR: 0x00000010
https://bugzilla.kernel.org/show_bug.cgi?id=15502
Bug 13844 - i915 error: "render error detected"
https://bugzilla.kernel.org/show_bug.cgi?id=13844
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Tejun Heo [Mon, 31 May 2010 14:26:48 +0000 (16:26 +0200)]
sata_via: magic vt6421 fix for transmission problems w/ WD drives
commit
8b27ff4cf6d15964aa2987aeb58db4dfb1f87a19 upstream.
vt6421 has problems talking to recent WD drives. It causes a lot of
transmission errors while high bandwidth transfer as reported in the
following bugzilla entry.
https://bugzilla.kernel.org/show_bug.cgi?id=15173
Joseph Chan provided the following fix. I don't have any idea what it
does but I can verify the issue is gone with the patch applied.
Signed-off-by: Tejun Heo <tj@kernel.org>
Originally-from: Joseph Chan <JosephChan@via.com.tw>
Reported-by: Jorrit Tijben <sjorrit@gmail.com>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Tejun Heo [Tue, 1 Jun 2010 15:29:21 +0000 (17:29 +0200)]
sata_nv: don't diddle with nIEN on mcp55
commit
f3faf8fc3fab45c3526efe8c9e99bb23f8723350 upstream.
On mcp55, nIEN gets stuck once set and liteon blueray rom iHOS104-08
violates ATA specification and fails to set I on D2H Reg FIS if nIEN
is set when the command was issued. When the other party is following
the spec, both devices can work fine but when the two flaws are put
together, they can't talk to each other.
mcp55 has its own IRQ masking mechanism and there's no reason to mess
with nIEN in the first place. Fix it by dropping nIEN diddling from
nv_mcp55_freeze/thaw().
This was originally reported by Cengiz. Although Cengiz hasn't
verified the fix yet, I could reproduce this problem and verfiy the
fix. Even if Cengiz is experiencing different or additional problems,
this patch is needed.
Signed-off-by: Tejun Heo <tj@kernel.org>
Reported-by: Cengiz Günay <cgunay@emory.edu>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Stephane Eranian [Wed, 17 Mar 2010 21:21:01 +0000 (23:21 +0200)]
perf_events: Fix resource leak in x86 __hw_perf_event_init()
commit
4b24a88b35e15e04bd8f2c5dda65b5dc8ebca05f upstream.
If reserve_pmc_hardware() succeeds but reserve_ds_buffers()
fails, then we need to release_pmc_hardware. It won't be done
by the destroy() callback because we return before setting it
in case of error.
Signed-off-by: Stephane Eranian <eranian@google.com>
Cc: peterz@infradead.org
Cc: paulus@samba.org
Cc: davem@davemloft.net
Cc: fweisbec@gmail.com
Cc: robert.richter@amd.com
Cc: perfmon2-devel@lists.sf.net
LKML-Reference: <
4ba1568b.
15185e0a.182a.7802@mx.google.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Stefan Richter [Sun, 30 May 2010 17:43:52 +0000 (19:43 +0200)]
firewire: core: check for 1394a compliant IRM, fix inaccessibility of Sony camcorder
commit
10389536742cefbedecb67a5b2906f155cf3a1c3 upstream.
Per IEEE 1394 clause 8.4.2.3, a contender for the IRM role shall check
whether the current IRM complies to 1394a-2000 or later. If not force a
compliant node (e.g. itself) to become IRM. This was implemented in the
older ieee1394 driver but not yet in firewire-core.
An older Sony camcorder (Sony DCR-TRV25) which implements 1394-1995 IRM
but neither 1394a-2000 IRM nor BM was now found to cause an
interoperability bug:
- Camcorder becomes root node when plugged in, hence gets IRM role.
- firewire-core successfully contends for BM role, proceeds to perform
gap count optimization and resets the bus.
- Sony camcorder ignores presence of a BM (against the spec, this is
a firmware bug), performs its idea of gap count optimization and
resets the bus.
- Preceding two steps are repeated endlessly, bus never settles,
regular I/O is practically impossible.
http://thread.gmane.org/gmane.linux.kernel.firewire.user/3913
This is an interoperability regression from the old to the new drivers.
Fix it indirectly by adding the 1394a IRM check. The spec suggests
three and a half methods to determine 1394a compliance of a remote IRM;
we choose the method of testing the Config_ROM.Bus_Info.generation
field. This is data that firewire-core should have readily available at
this point, i.e. does not require extra I/O.
Reported-by: Clemens Ladisch <clemens@ladisch.de> (missing 1394a check)
Reported-by: H. S. <hs.samix@gmail.com> (issue with Sony DCR-TRV25)
Tested-by: H. S. <hs.samix@gmail.com>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Tejun Heo [Thu, 3 Jun 2010 09:57:04 +0000 (11:57 +0200)]
ahci: add pci quirk for JMB362
commit
4daedcfe8c6851aa01cc1997220f2577f4039c13 upstream.
JMB362 is a new variant of jmicron controller which is similar to
JMB360 but has two SATA ports instead of one. As there is no PATA
port, single function AHCI mode can be used as in JMB360. Add pci
quirk for JMB362.
Signed-off-by: Tejun Heo <tj@kernel.org>
Reported-by: Aries Lee <arieslee@jmicron.com>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Bob Copeland [Fri, 4 Jun 2010 12:14:14 +0000 (08:14 -0400)]
ath5k: retain promiscuous setting
commit
6b5dcccb495b66b3b0b9581cdccfed038e5d68a2 upstream.
Commit
56d1de0a21db28e41741cfa0a66e18bc8d920554, "ath5k: clean up
filter flags setting" introduced a regression in monitor mode such
that the promisc filter flag would get lost.
Although we set the promisc flag when it changed, we did not
preserve it across subsequent calls to configure_filter. This patch
restores the original functionality.
Bisected-by: weedy2887@gmail.com
Tested-by: weedy2887@gmail.com
Tested-by: Rick Farina <sidhayn@gmail.com>
Signed-off-by: Bob Copeland <me@bobcopeland.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Paul Mundt [Wed, 2 Jun 2010 08:10:44 +0000 (17:10 +0900)]
clocksource: sh_cmt: compute mult and shift before registration
commit
f4d7c3565c1692c54d9152b52090fe73f0029e37 upstream.
Based on the sh_tmu change in
66f49121ffa41a19c59965b31b046d8368fec3c7
("clocksource: sh_tmu: compute mult and shift before registration").
The same issues impact the sh_cmt driver, so we take the same approach
here.
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Martin Homuth-Rosemann [Mon, 31 May 2010 20:33:04 +0000 (22:33 +0200)]
Staging: comedi - correct parameter gainlkup for DAQCard-6024E in driver ni_mio_cs.c
commit
ebe8622342f12bed387f7de4b5fb7c52005ccb29 upstream.
Correct at least one of the incorrect specs for a national instrument
data acquisition card DAQCard-6024E. This card has only four different
gain settings (+-10V, +-5V, +-0.5V, +-0.05V).
Signed-off-by: Martin Homuth-Rosemann <homuth-rosemann@gmx.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Daniel T Chen [Sun, 30 May 2010 17:08:41 +0000 (13:08 -0400)]
ALSA: hda: Use LPIB for ASUS M2V
commit
9f75c1b12c5ef392ddcea575b13560842c28b1b3 upstream.
BugLink: https://launchpad.net/bugs/587546
Symptom: On the reporter's ASUS M2V, using PulseAudio in Ubuntu 10.04 LTS
results in the PA daemon crashing shortly after attempting playback of an
audio file.
Test case: Using Ubuntu 10.04 LTS (Linux 2.6.32.12), Linux 2.6.33, or
Linux 2.6.34, attempt playback of an audio file while PulseAudio is
active.
Resolution: add SSID for this machine to the position_fix quirk table,
explicitly specifying the LPIB method.
Reported-and-Tested-By: D Tangman
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, 30 May 2010 23:31:41 +0000 (19:31 -0400)]
ALSA: hda: Use LPIB for another mainboard
commit
b90c076424da8166797bdc34187660fd0124f530 upstream.
BugLink: https://launchpad.net/bugs/580749
Symptom: on the original reporter's VIA VT1708-based board, the
PulseAudio daemon dies shortly after the user attempts to play an audio
file.
Test case: boot from Ubuntu 10.04 LTS live cd; attempt to play an audio
file.
Resolution: add SSID for the original reporter's hardware to the
position_fix quirk table, explicitly specifying the LPIB method.
Reported-and-Tested-By: Harald
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, 30 May 2010 13:55:23 +0000 (09:55 -0400)]
ALSA: hda: Use mb31 quirk for an iMac model
commit
26fd74fc01991a18f0e3bd54f8b1b75945ee3dbb upstream.
BugLink: https://launchpad.net/bugs/542550
Symptom: On the reporter's iMac, in Ubuntu 10.04 LTS neither playback
nor capture appear audible out-of-the-box.
Test case: Boot from an Ubuntu 10.04 LTS live cd or from an installed
configuration and attempt to play or capture audio.
Resolution: Specify the mb31 quirk for this machine in the codec SSID
table.
Reported-and-Tested-By: f3a97
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, 30 May 2010 05:17:03 +0000 (01:17 -0400)]
ALSA: hda: Use LPIB for an ASUS device
commit
dd37f8e8659bc617c3f2a84e007a4824ccdac458 upstream.
BugLink: https://launchpad.net/bugs/465942
Symptom: On the reporter's ASUS device, using PulseAudio in Ubuntu 10.04
LTS results in the PA daemon crashing shortly after attempting to select
capture or to configure the audio hardware profile.
Test case: Using Ubuntu 10.04 LTS (Linux 2.6.32.12), Linux 2.6.33, or
Linux 2.6.34, adjust the HDA device's capture volume with PulseAudio.
Resolution: add SSID for this machine to the position_fix quirk table,
explicitly specifying the LPIB method.
Reported-and-Tested-By: Irihapeti
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>
Ian Campbell [Tue, 25 May 2010 09:45:35 +0000 (10:45 +0100)]
xen: avoid allocation causing potential swap activity on the resume path
commit
b3831cb55d383e8eb55d3b56c715fb48459b87c9 upstream.
Since the device we are resuming could be the device containing the
swap device we should ensure that the allocation cannot cause
IO.
On resume, this path is triggered when the running system tries to
continue using its devices. If it cannot then the resume will fail;
to try to avoid this we let it dip into the emergency pools.
The majority of these changes were made when linux-2.6.18-xen.hg
changeset
e8b49cfbdac0 was ported upstream in
a144ff09bc52ef3f3684ed23eadc9c7c0e57b3aa but somehow this hunk was
dropped.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Jeremy Fitzhardinge <jeremy@goop.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Ian Campbell [Wed, 19 May 2010 15:19:25 +0000 (16:19 +0100)]
xen: ensure timer tick is resumed even on CPU driving the resume
commit
cd52e17ea8278f8449b6174a8e5ed439a2e44ffb upstream.
The core suspend/resume code is run from stop_machine on CPU0 but
parts of the suspend/resume machinery (including xen_arch_resume) are
run on whichever CPU happened to schedule the xenwatch kernel thread.
As part of the non-core resume code xen_arch_resume is called in order
to restart the timer tick on non-boot processors. The boot processor
itself is taken care of by core timekeeping code.
xen_arch_resume uses smp_call_function which does not call the given
function on the current processor. This means that we can end up with
one CPU not receiving timer ticks if the xenwatch thread happened to
be scheduled on CPU > 0.
Use on_each_cpu instead of smp_call_function to ensure the timer tick
is resumed everywhere.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Jeremy Fitzhardinge <jeremy@goop.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Gabor Gombas [Mon, 24 May 2010 19:13:18 +0000 (12:13 -0700)]
x86, setup: Phoenix BIOS fixup is needed on Dell Inspiron Mini 1012
commit
3d6e77a3ddb8e4156b89f4273ff8c7d37abaf781 upstream.
The low-memory corruption checker triggers during suspend/resume, so we
need to reserve the low 64k. Don't be fooled that the BIOS identifies
itself as "Dell Inc.", it's still Phoenix BIOS.
[ hpa: I think we blacklist almost every BIOS in existence. We should
either change this to a whitelist or just make it unconditional. ]
Signed-off-by: Gabor Gombas <gombasg@digikabel.hu>
LKML-Reference: <
201005241913.o4OJDIMM010877@imap1.linux-foundation.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Jiri Kosina [Wed, 26 May 2010 21:43:53 +0000 (14:43 -0700)]
ipmi: handle run_to_completion properly in deliver_recv_msg()
commit
a747c5abc329611220f16df0bb4cf0ca4a7fdf0c upstream.
If run_to_completion flag is set, it means that we are running in a
single-threaded mode, and thus no locks are held.
This fixes a deadlock when IPMI notifier is being called during panic.
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Acked-by: Corey Minyard <minyard@acm.org>
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>
Jeff Moyer [Wed, 26 May 2010 15:49:40 +0000 (11:49 -0400)]
do_generic_file_read: clear page errors when issuing a fresh read of the page
commit
91803b499cca2fe558abad709ce83dc896b80950 upstream.
I/O errors can happen due to temporary failures, like multipath
errors or losing network contact with the iSCSI server. Because
of that, the VM will retry readpage on the page.
However, do_generic_file_read does not clear PG_error. This
causes the system to be unable to actually use the data in the
page cache page, even if the subsequent readpage completes
successfully!
The function filemap_fault has had a ClearPageError before
readpage forever. This patch simply adds the same to
do_generic_file_read.
Signed-off-by: Jeff Moyer <jmoyer@redhat.com>
Signed-off-by: Rik van Riel <riel@redhat.com>
Acked-by: Larry Woodman <lwoodman@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Oleg Nesterov [Wed, 26 May 2010 21:42:54 +0000 (14:42 -0700)]
signals: check_kill_permission(): don't check creds if same_thread_group()
commit
065add3941bdca54fe04ed3471a96bce9af88793 upstream.
Andrew Tridgell reports that aio_read(SIGEV_SIGNAL) can fail if the
notification from the helper thread races with setresuid(), see
http://samba.org/~tridge/junkcode/aio_uid.c
This happens because check_kill_permission() doesn't permit sending a
signal to the task with the different cred->xids. But there is not any
security reason to check ->cred's when the task sends a signal (private or
group-wide) to its sub-thread. Whatever we do, any thread can bypass all
security checks and send SIGKILL to all threads, or it can block a signal
SIG and do kill(gettid(), SIG) to deliver this signal to another
sub-thread. Not to mention that CLONE_THREAD implies CLONE_VM.
Change check_kill_permission() to avoid the credentials check when the
sender and the target are from the same thread group.
Also, move "cred = current_cred()" down to avoid calling get_current()
twice.
Note: David Howells pointed out we could relax this even more, the
CLONE_SIGHAND (without CLONE_THREAD) case probably does not need
these checks too.
Roland said:
: The glibc (libpthread) that does set*id across threads has
: been in use for a while (2.3.4?), probably in distro's using kernels as old
: or older than any active -stable streams. In the race in question, this
: kernel bug is breaking valid POSIX application expectations.
Reported-by: Andrew Tridgell <tridge@samba.org>
Signed-off-by: Oleg Nesterov <oleg@redhat.com>
Acked-by: Roland McGrath <roland@redhat.com>
Acked-by: David Howells <dhowells@redhat.com>
Cc: Eric Paris <eparis@parisplace.org>
Cc: Jakub Jelinek <jakub@redhat.com>
Cc: James Morris <jmorris@namei.org>
Cc: Roland McGrath <roland@redhat.com>
Cc: Stephen Smalley <sds@tycho.nsa.gov>
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>
Ira W. Snyder [Thu, 27 May 2010 17:59:02 +0000 (19:59 +0200)]
hwmon: (ltc4245) Read only one GPIO pin
commit
df16dd53c575d0cb9dbee20a3149927c862a9ff6 upstream.
Read only one of the GPIO pins as an analog voltage. The ADC can be
switched to a different GPIO pin at runtime, but this is not supported.
Previously, this driver would report the analog voltage of the currently
selected GPIO pin as all three GPIO voltages: in9_input, in10_input and
in11_input.
Signed-off-by: Ira W. Snyder <iws@ovro.caltech.edu>
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Dave Airlie [Fri, 28 May 2010 20:50:37 +0000 (06:50 +1000)]
drm/radeon: fix the r100/r200 ums block 0 page fix
commit
cf22f20ade30f8c03955324aaf27b1049e182600 upstream.
airlied -> brown paper bag.
I blame Hi-5 or the Wiggles for lowering my IQ, move the fix inside some
brackets instead of breaking everything in site.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Dave Airlie [Wed, 24 Feb 2010 07:17:13 +0000 (17:17 +1000)]
drm/radeon: r100/r200 ums: block ability for userspace app to trash 0 page and beyond
commit
566d84d172161cb6c0c4dd834c34abbac6bf7b38 upstream.
radeon's have a special ability to passthrough writes in their internal
memory space directly to PCI, this ability means that if some of the internal
surfaces like the depth buffer point at 0x0, any writes to these will
go directly to RAM at 0x0 via PCI busmastering.
Now mesa used to always emit clears after emitting state, since the
radeon mesa driver was refactored a year or more ago, it was found it
could generate a clear request without ever sending any setup state to the
card. So the clear would attempt to clear the depth buffer at 0x0, which
would overwrite main memory at this point. fs corruption ensues.
Also once one app did this correctly, it would never get set back to 0
making this messy to reproduce.
The kernel should block this from happening as mesa runs without privs,
though it does require the user be connected to the current running X session.
This patch implements a check to make sure the depth offset has been set
before a depth clear occurs and if it finds one it prints a warning and
ignores the depth clear request. There is also a mesa fix to avoid sending
the badness going into mesa.
This only affects r100/r200 GPUs in user modesetting mode.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Mark Brown [Tue, 25 May 2010 17:49:00 +0000 (10:49 -0700)]
ASoC: Fix dB scales for WM8990
commit
f68596c6d8711650722b2a54328a088a2c21bc5b upstream.
These should be regular, not linear.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Acked-by: Liam Girdwood <lrg@slimlogic.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Mark Brown [Tue, 25 May 2010 17:48:31 +0000 (10:48 -0700)]
ASoC: Fix dB scales for WM8400
commit
3351e9fbb0fda6498ee149ee88c67f5849813c57 upstream.
These scales should be regular, not linear.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Acked-by: Liam Girdwood <lrg@slimlogic.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Mark Brown [Tue, 25 May 2010 17:46:05 +0000 (10:46 -0700)]
ASoC: Fix dB scales for WM835x
commit
e6a08c5a8990102bcd1f4bae84b668da6c23caa9 upstream.
These should be regular rather than linear scales.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Acked-by: Liam Girdwood <lrg@slimlogic.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Russell King [Thu, 27 May 2010 07:23:29 +0000 (08:23 +0100)]
ARM: VFP: Fix vfp_put_double() for d16-d31
commit
138de1c44a8e0606501cd8593407e9248e84f1b7 upstream.
vfp_put_double() takes the double value in r0,r1 not r1,r2.
Reported-by: Tarun Kanti DebBarma <tarun.kanti@ti.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Linus Walleij [Wed, 26 May 2010 06:37:57 +0000 (07:37 +0100)]
ARM: 6144/1: TCM memory bug freeing bug
commit
ea208f646c8fb91c39c852e952fc911e1ad045ab upstream.
This fixes a bug in mm/init.c when freeing the TCM compile memory,
this was being referred to as a char * which is incorrect: this
will dereference the pointer and feed in the value at the location
instead of the address to it. Change it to a plain char and use
&(char) to reference it.
Signed-off-by: Linus Walleij <linus.walleij@stericsson.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Marek Vašut [Wed, 26 May 2010 22:53:09 +0000 (23:53 +0100)]
ARM: 6146/1: sa1111: Prevent deadlock in resume path
commit
3defb2476166445982a90c12d33f8947e75476c4 upstream.
This patch reorganises the sa1111_resume() function in a manner the spinlock
happens after calling the sa1111_wake(). This fixes two bugs:
1) This function called sa1111_wake() which tried to claim the same spinlock
the sa1111_resume() already claimed. This would result in certain deadlock.
Original idea for this part: Russell King <rmk+kernel@arm.linux.org.uk>
2) The function didn't unlock the spinlock in case the chip didn't report
correct ID.
Original idea for this part: Julia Lawall <julia@diku.dk>
Signed-off-by: Marek Vasut <marek.vasut@gmail.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Khem Raj [Fri, 4 Jun 2010 03:05:15 +0000 (04:05 +0100)]
ARM: 6164/1: Add kto and kfrom to input operands list.
commit
9a40ac86152c9cffd3dca482a15ddf9a8c5716b3 upstream.
When functions incoming parameters are not in input operands list gcc
4.5 does not load the parameters into registers before calling this
function but the inline assembly assumes valid addresses inside this
function. This breaks the code because r0 and r1 are invalid when
execution enters v4wb_copy_user_page ()
Also the constant needs to be used as third input operand so account
for that as well.
Tested on qemu arm.
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>