Luis R. Rodriguez [Mon, 4 Jan 2010 15:40:39 +0000 (10:40 -0500)]
ath5k: Fix eeprom checksum check for custom sized eeproms
commit
359207c687cc8f4f9845c8dadd0d6dabad44e584 upstream.
Commit
8bf3d79bc401ca417ccf9fc076d3295d1a71dbf5 enabled EEPROM
checksum checks to avoid bogus bug reports but failed to address
updating the code to consider devices with custom EEPROM sizes.
Devices with custom sized EEPROMs have the upper limit size stuffed
in the EEPROM. Use this as the upper limit instead of the static
default size. In case of a checksum error also provide back the
max size and whether or not this was the default size or a custom
one. If the EEPROM is busted we add a failsafe check to ensure
we don't loop forever or try to read bogus areas of hardware.
This closes bug 14874
http://bugzilla.kernel.org/show_bug.cgi?id=14874
Cc: David Quan <david.quan@atheros.com>
Cc: Stephen Beahm <stephenbeahm@comcast.net>
Reported-by: Joshua Covington <joshuacov@googlemail.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>
Zhu Yi [Fri, 8 Jan 2010 18:04:30 +0000 (10:04 -0800)]
iwlwifi: fix iwl_queue_used bug when read_ptr == write_ptr
commit
c8106d7625a58ee4387cb2efe3e82320ad44b467 upstream.
When txq read_ptr equals to write_ptr, iwl_queue_used should
always return false. Because there is no used TFD in this case.
This is a complementary fix to the fix already included in commit "iwl3945:
fix panic in iwl3945 driver". Both fixes are needed to address the panic
below.
This problem was discussed on linux-wireless in
http://thread.gmane.org/gmane.linux.kernel.wireless.general/43568
<1>[ 7290.414172] IP: [<
ffffffffa0dd53a1>] iwl3945_rx_reply_tx+0xc1/0x450 [iwl3945]
<4>[ 7290.414205] PGD 0
<1>[ 7290.414214] Thread overran stack, or stack corrupted
<0>[ 7290.414229] Oops: 0002 [#1] PREEMPT SMP
<0>[ 7290.414246] last sysfs file: /sys/devices/platform/coretemp.1/temp1_input
<4>[ 7290.414265] CPU 0
<4>[ 7290.414274] Modules linked in: af_packet nfsd usb_storage usb_libusual cpufreq_powersave exportfs cpufreq_conservative iwl3945 nfs cpufreq_userspace snd_hda_codec_realtek acpi_cpufreq uvcvideo lockd iwlcore snd_hda_intel joydev coretemp nfs_acl videodev snd_hda_codec mac80211 v4l1_compat snd_hwdep sbp2 v4l2_compat_ioctl32 uhci_hcd psmouse auth_rpcgss ohci1394 cfg80211 ehci_hcd video ieee1394 snd_pcm serio_raw battery ac nvidia(P) usbcore output sunrpc evdev lirc_ene0100 snd_page_alloc rfkill tg3 libphy fuse lzo lzo_decompress lzo_compress
<6>[ 7290.414486] Pid: 0, comm: swapper Tainted: P 2.6.32-rc8-wl #213 Aspire 5720
<6>[ 7290.414507] RIP: 0010:[<
ffffffffa0dd53a1>] [<
ffffffffa0dd53a1>] iwl3945_rx_reply_tx+0xc1/0x450 [iwl3945]
<6>[ 7290.414541] RSP: 0018:
ffff880002203d60 EFLAGS:
00010246
<6>[ 7290.414557] RAX:
000000000000004f RBX:
ffff880064c11600 RCX:
0000000000000013
<6>[ 7290.414576] RDX:
ffffffffa0ddcf20 RSI:
ffff8800512b7008 RDI:
0000000000000038
<6>[ 7290.414596] RBP:
ffff880002203dd0 R08:
0000000000000000 R09:
0000000000000100
<6>[ 7290.414616] R10:
0000000000000001 R11:
0000000000000000 R12:
00000000000000a0
<6>[ 7290.414635] R13:
0000000000000002 R14:
0000000000000013 R15:
0000000000020201
<6>[ 7290.414655] FS:
0000000000000000(0000) GS:
ffff880002200000(0000) knlGS:
0000000000000000
<6>[ 7290.414677] CS: 0010 DS: 0018 ES: 0018 CR0:
000000008005003b
<6>[ 7290.414693] CR2:
0000000000000041 CR3:
0000000001001000 CR4:
00000000000006f0
<6>[ 7290.414712] DR0:
0000000000000000 DR1:
0000000000000000 DR2:
0000000000000000
<6>[ 7290.414732] DR3:
0000000000000000 DR6:
00000000ffff0ff0 DR7:
0000000000000400
<4>[ 7290.414752] Process swapper (pid: 0, threadinfo
ffffffff81524000, task
ffffffff81528b60)
<0>[ 7290.414772] Stack:
<4>[ 7290.414780]
ffff880002203da0 0000000000000046 0000000000000000 0000000000000046
<4>[ 7290.414804] <0>
0000000000000282 0000000000000282 0000000000000282 ffff880064c12010
<4>[ 7290.414830] <0>
ffff880002203db0 ffff880064c11600 ffff880064c12e50 ffff8800512b7000
<0>[ 7290.414858] Call Trace:
<0>[ 7290.414867] <IRQ>
<4>[ 7290.414884] [<
ffffffffa0dc8c47>] iwl3945_irq_tasklet+0x657/0x1740 [iwl3945]
<4>[ 7290.414910] [<
ffffffff8138fc60>] ? _spin_unlock+0x30/0x60
<4>[ 7290.414931] [<
ffffffff81049a21>] tasklet_action+0x101/0x110
<4>[ 7290.414950] [<
ffffffff8104a3d0>] __do_softirq+0xc0/0x160
<4>[ 7290.414968] [<
ffffffff8100d01c>] call_softirq+0x1c/0x30
<4>[ 7290.414986] [<
ffffffff8100eff5>] do_softirq+0x75/0xb0
<4>[ 7290.415003] [<
ffffffff81049ee5>] irq_exit+0x95/0xa0
<4>[ 7290.415020] [<
ffffffff8100e547>] do_IRQ+0x77/0xf0
<4>[ 7290.415038] [<
ffffffff8100c7d3>] ret_from_intr+0x0/0xf
<0>[ 7290.415052] <EOI>
<4>[ 7290.415067] [<
ffffffff81234efa>] ? acpi_idle_enter_bm+0x270/0x2a5
<4>[ 7290.415087] [<
ffffffff81234f04>] ? acpi_idle_enter_bm+0x27a/0x2a5
<4>[ 7290.415107] [<
ffffffff81234efa>] ? acpi_idle_enter_bm+0x270/0x2a5
<4>[ 7290.415130] [<
ffffffff812c11f3>] ? cpuidle_idle_call+0x93/0xf0
<4>[ 7290.415149] [<
ffffffff8100b0d7>] ? cpu_idle+0xa7/0x110
<4>[ 7290.415168] [<
ffffffff8137b3d5>] ? rest_init+0x75/0x80
<4>[ 7290.415187] [<
ffffffff8158cd0a>] ? start_kernel+0x3a7/0x3b3
<4>[ 7290.415206] [<
ffffffff8158c315>] ? x86_64_start_reservations+0x125/0x129
<4>[ 7290.415227] [<
ffffffff8158c3fd>] ? x86_64_start_kernel+0xe4/0xeb
<0>[ 7290.415243] Code: 00 41 39 ce 0f 8d e8 01 00 00 48 8b 47 40 48 63 d2 48 69 d2 98 00 00 00 4c 8b 04 02 48 c7 c2 20 cf dd a0 49 8d 78 38 49 8d 40 4f <c6> 47 09 00 c6 47 0c 00 c6 47 0f 00 c6 47 12 00 c6 47 15 00 49
<1>[ 7290.415382] RIP [<
ffffffffa0dd53a1>] iwl3945_rx_reply_tx+0xc1/0x450 [iwl3945]
<4>[ 7290.415410] RSP <
ffff880002203d60>
<0>[ 7290.415421] CR2:
0000000000000041
<4>[ 7290.415436] ---[ end trace
ec46807277caa515 ]---
<0>[ 7290.415450] Kernel panic - not syncing: Fatal exception in interrupt
<4>[ 7290.415468] Pid: 0, comm: swapper Tainted: P D 2.6.32-rc8-wl #213
<4>[ 7290.415486] Call Trace:
<4>[ 7290.415495] <IRQ> [<
ffffffff8138c040>] panic+0x7d/0x13a
<4>[ 7290.415519] [<
ffffffff8101071a>] oops_end+0xda/0xe0
<4>[ 7290.415538] [<
ffffffff8102e1ea>] no_context+0xea/0x250
<4>[ 7290.415557] [<
ffffffff81038991>] ? select_task_rq_fair+0x511/0x780
<4>[ 7290.415578] [<
ffffffff8102e475>] __bad_area_nosemaphore+0x125/0x1e0
<4>[ 7290.415597] [<
ffffffff81038d0c>] ? __enqueue_entity+0x7c/0x80
<4>[ 7290.415616] [<
ffffffff81039201>] ? enqueue_task_fair+0x111/0x150
<4>[ 7290.415636] [<
ffffffff8102e53e>] bad_area_nosemaphore+0xe/0x10
<4>[ 7290.415656] [<
ffffffff8102e8fa>] do_page_fault+0x26a/0x320
<4>[ 7290.415674] [<
ffffffff813905df>] page_fault+0x1f/0x30
<4>[ 7290.415697] [<
ffffffffa0dd53a1>] ? iwl3945_rx_reply_tx+0xc1/0x450 [iwl3945]
<4>[ 7290.415723] [<
ffffffffa0dc8c47>] iwl3945_irq_tasklet+0x657/0x1740 [iwl3945]
<4>[ 7290.415746] [<
ffffffff8138fc60>] ? _spin_unlock+0x30/0x60
<4>[ 7290.415764] [<
ffffffff81049a21>] tasklet_action+0x101/0x110
<4>[ 7290.415783] [<
ffffffff8104a3d0>] __do_softirq+0xc0/0x160
<4>[ 7290.415801] [<
ffffffff8100d01c>] call_softirq+0x1c/0x30
<4>[ 7290.415818] [<
ffffffff8100eff5>] do_softirq+0x75/0xb0
<4>[ 7290.415835] [<
ffffffff81049ee5>] irq_exit+0x95/0xa0
<4>[ 7290.415852] [<
ffffffff8100e547>] do_IRQ+0x77/0xf0
<4>[ 7290.415869] [<
ffffffff8100c7d3>] ret_from_intr+0x0/0xf
<4>[ 7290.415883] <EOI> [<
ffffffff81234efa>] ? acpi_idle_enter_bm+0x270/0x2a5
<4>[ 7290.415911] [<
ffffffff81234f04>] ? acpi_idle_enter_bm+0x27a/0x2a5
<4>[ 7290.415931] [<
ffffffff81234efa>] ? acpi_idle_enter_bm+0x270/0x2a5
<4>[ 7290.415952] [<
ffffffff812c11f3>] ? cpuidle_idle_call+0x93/0xf0
<4>[ 7290.415971] [<
ffffffff8100b0d7>] ? cpu_idle+0xa7/0x110
<4>[ 7290.415989] [<
ffffffff8137b3d5>] ? rest_init+0x75/0x80
<4>[ 7290.416007] [<
ffffffff8158cd0a>] ? start_kernel+0x3a7/0x3b3
<4>[ 7290.416026] [<
ffffffff8158c315>] ? x86_64_start_reservations+0x125/0x129
<4>[ 7290.416047] [<
ffffffff8158c3fd>] ? x86_64_start_kernel+0xe4/0xeb
Reported-by: Maxim Levitsky <maximlevitsky@gmail.com>
Tested-by: Maxim Levitsky <maximlevitsky@gmail.com>
Signed-off-by: Zhu Yi <yi.zhu@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>
Ian Campbell [Thu, 17 Dec 2009 13:57:09 +0000 (13:57 +0000)]
xen: fix hang on suspend.
commit
c5cae661d6cf808b6984762f763261adf35f3eb7 upstream.
In
65f63384 "xen: improve error handling in do_suspend" I said:
- xs_suspend()/xs_resume() and dpm_suspend_noirq()/dpm_resume_noirq() were not
nested in the obvious way.
and changed the ordering of the calls as so:
BEFORE AFTER
xs_suspend dpm_suspend_noirq
dpm_suspend_noirq xs_suspend
*SUSPEND* *SUSPEND*
dpm_resume_noirq dpm_resume_noirq
xs_resume xs_resume
Clearly this is not an improvement and I was talking rubbish.
In particular the new ordering is susceptible to a hang if a xenstore write is
in progress at the point at which the suspend kicks in. When the suspend
process calls xs_suspend it tries to take the request_mutex but if a write is
in progress it could be looping in xenbus_xs.c:read_reply() waiting for
something to arrive on &xs_state.reply_list while holding the request_mutex
(taken in the caller of read_reply).
However if we have done dpm_suspend_noirq before xs_suspend then we won't get
any more xenstore interrupts and process_msg() will never be woken up to add
anything to the reply_list.
Fix this by calling xs_suspend before dpm_suspend_noirq. If dpm_suspend_noirq
fails then make sure we go through the xs_suspend_cancel() code path.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Jan Kara [Wed, 6 Jan 2010 17:03:36 +0000 (18:03 +0100)]
quota: Fix dquot_transfer for filesystems different from ext4
commit
05b5d898235401c489c68e1f3bc5706a29ad5713 upstream.
Commit
fd8fbfc1 modified the way we find amount of reserved space
belonging to an inode. The amount of reserved space is checked
from dquot_transfer and thus inode_reserved_space gets called
even for filesystems that don't provide get_reserved_space callback
which results in a BUG.
Fix the problem by checking get_reserved_space callback and return 0 if
the filesystem does not provide it.
CC: Dmitry Monakhov <dmonakhov@openvz.org>
Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Roger Blofeld [Sun, 10 Jan 2010 19:52:32 +0000 (20:52 +0100)]
hwmon: (adt7462) Fix pin 28 monitoring
commit
bb595c923bc51dff9cdd112de18deb57ac7945d2 upstream.
The ADT7462_PIN28_VOLT value is a 4-bit field, so the corresponding
shift must be 4.
Signed-off-by: Roger Blofeld <blofeldus@yahoo.com>
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Yong Wang [Sun, 10 Jan 2010 19:52:34 +0000 (20:52 +0100)]
hwmon: (coretemp) Fix TjMax for Atom N450/D410/D510 CPUs
commit
1fe63ab47a617ee95f562eaa7ddbbc59981ff8c6 upstream.
The max junction temperature of Atom N450/D410/D510 CPUs is 100 degrees
Celsius. Since these CPUs are always coupled with Intel NM10 chipset in
one package, the best way to verify whether an Atom CPU is N450/D410/D510
is to check the host bridge device.
Signed-off-by: Yong Wang <yong.y.wang@intel.com>
Acked-by: Huaxu Wan <huaxu.wan@intel.com>
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Patrick McHardy [Thu, 7 Jan 2010 17:33:18 +0000 (18:33 +0100)]
netfilter: nf_ct_ftp: fix out of bounds read in update_nl_seq()
commit
aaff23a95aea5f000895f50d90e91f1e2f727002 upstream.
As noticed by Dan Carpenter <error27@gmail.com>, update_nl_seq()
currently contains an out of bounds read of the seq_aft_nl array
when looking for the oldest sequence number position.
Fix it to only compare valid positions.
Signed-off-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Florian Westphal [Fri, 8 Jan 2010 16:31:24 +0000 (17:31 +0100)]
netfilter: ebtables: enforce CAP_NET_ADMIN
commit
dce766af541f6605fa9889892c0280bab31c66ab upstream.
normal users are currently allowed to set/modify ebtables rules.
Restrict it to processes with CAP_NET_ADMIN.
Note that this cannot be reproduced with unmodified ebtables binary
because it uses SOCK_RAW.
Signed-off-by: Florian Westphal <fwestphal@astaro.com>
Signed-off-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Mark Brown [Thu, 7 Jan 2010 16:29:20 +0000 (16:29 +0000)]
ASoC: Fix WM8350 DSP mode B configuration
commit
5ee518ecbcb5934e284ea51a19a939c891f5f7ea upstream.
We need to set the LRCLK inversion bit to select DSP mode.
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>
Daniel T Chen [Sun, 27 Dec 2009 20:48:40 +0000 (15:48 -0500)]
ALSA: atiixp: Specify codec for Foxconn RC4107MA-RS2
commit
dfb12eeb0f04b37e5eb3858864d074af4ecd2ac7 upstream.
BugLink: https://bugs.launchpad.net/ubuntu/+bug/498863
This mainboard needs ac97_codec=0.
Tested-by: Apoorv Parle <apparle@yahoo.co.in>
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 [Sat, 9 Jan 2010 06:22:29 +0000 (01:22 -0500)]
ALSA: ac97: Add Dell Dimension 2400 to Headphone/Line Jack Sense blacklist
commit
af9a75dd1a1f8a9aa406466cc8bb16208120488a upstream.
This model needs both 'Headphone Jack Sense' and 'Line Jack Sense' muted
for audible playback, so just add it to the ad1981 jack sense blacklist.
Tested-by: Pete <x41215201@gmail.com>
Signed-off-by: Daniel T Chen <crimsun@ubuntu.com>
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Takashi Iwai [Tue, 12 Jan 2010 13:00:11 +0000 (14:00 +0100)]
ALSA: hda - Fix ALC861-VD capture source mixer
commit
9c0afc861a7228f718cb6a79fa7f9d46bf9ff300 upstream.
The capture source or input source mixer element wasn't created properly
for ALC861-VD codec due to the wrong NID passed to
alc_auto_create_input_ctls().
References: Novell bnc#568305
http://bugzilla.novell.com/show_bug.cgi?id=568305
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Adrian Hunter [Fri, 8 Jan 2010 22:43:00 +0000 (14:43 -0800)]
mmc_block: fix queue cleanup
commit
5fa83ce284a4b7cd9dcfadd01500b0ed4ab9b740 upstream.
The main bug was that 'blk_cleanup_queue()' was called while the block
device could still be in use, for example, because the card was removed
while files were still open.
In addition, to be sure that 'mmc_request()' will get called for all new
requests (so it can error them out), the queue is emptied during cleanup.
This is done after the worker thread is stopped to avoid racing with it.
Finally, it is not a device error for this to be happening, so quiet the
(sometimes very many) error messages.
Signed-off-by: Adrian Hunter <adrian.hunter@nokia.com>
Cc: <linux-mmc@vger.kernel.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>
Jarkko Lavinen [Fri, 8 Jan 2010 22:42:59 +0000 (14:42 -0800)]
mmc_block: fix probe error cleanup bug
commit
0a74ff29b8dd8b748f8856352f9a9b5c6cc362cc upstream.
If mmc_blk_set_blksize() fails mmc_blk_probe() the request queue and its
thread have been set up and they need to be shut down properly before
putting the disk.
Signed-off-by: Jarkko Lavinen <jarkko.lavinen@nokia.com>
Signed-off-by: Adrian Hunter <adrian.hunter@nokia.com>
Cc: <linux-mmc@vger.kernel.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>
Anna Lemehova [Fri, 8 Jan 2010 22:42:58 +0000 (14:42 -0800)]
mmc_block: add dev_t initialization check
commit
7d92df692994472cab6045bbd9d0e2c4afa4365f upstream.
When a card is removed before mmc_blk_probe() has called add_disk(), then
the minor field is uninitialized and has value 0. This caused
mmc_blk_put() to always release devidx 0 even if 0 was still in use. Then
the next mmc_blk_probe() used the first free idx of 0, which oopses in
sysfs, since it is used by another card.
Signed-off-by: Anna Lemehova <EXT-Anna.Lemehova@nokia.com>
Signed-off-by: Adrian Hunter <adrian.hunter@nokia.com>
Cc: <linux-mmc@vger.kernel.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>
Andi Kleen [Fri, 8 Jan 2010 22:42:52 +0000 (14:42 -0800)]
kernel/signal.c: fix kernel information leak with print-fatal-signals=1
commit
b45c6e76bc2c72f6426c14bed64fdcbc9bf37cb0 upstream.
When print-fatal-signals is enabled it's possible to dump any memory
reachable by the kernel to the log by simply jumping to that address from
user space.
Or crash the system if there's some hardware with read side effects.
The fatal signals handler will dump 16 bytes at the execution address,
which is fully controlled by ring 3.
In addition when something jumps to a unmapped address there will be up to
16 additional useless page faults, which might be potentially slow (and at
least is not very efficient)
Fortunately this option is off by default and only there on i386.
But fix it by checking for kernel addresses and also stopping when there's
a page fault.
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Oleg Nesterov <oleg@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Krzysztof Halasa [Fri, 8 Jan 2010 22:42:36 +0000 (14:42 -0800)]
dma-debug: allow DMA_BIDIRECTIONAL mappings to be synced with DMA_FROM_DEVICE and
commit
42d53b4ff7d61487d18274ebdf1f70c1aef6f122 upstream.
There is no need to perform full BIDIR sync (copying the buffers in case
of swiotlb and similar schemes) if we know that the owner (CPU or device)
hasn't altered the data.
Addresses the false-positive reported at
http://bugzilla.kernel.org/show_bug.cgi?id=14169
Signed-off-by: Krzysztof Halasa <khc@pm.waw.pl>
Cc: David Miller <davem@davemloft.net>
Cc: Joerg Roedel <joerg.roedel@amd.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Sascha Hauer [Fri, 8 Jan 2010 22:42:47 +0000 (14:42 -0800)]
lib/rational.c needs module.h
commit
7ee3aebe31d2cb22c84e1c8f48182947b13a3607 upstream.
lib/rational.c:62: warning: data definition has no type or storage class
lib/rational.c:62: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL'
lib/rational.c:62: warning: parameter names (without types) in function declaration
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Acked-by: WANG Cong <xiyou.wangcong@gmail.com>
Cc: Oskar Schirmer <os@emlix.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Dave Anderson [Fri, 8 Jan 2010 22:42:50 +0000 (14:42 -0800)]
cgroups: fix 2.6.32 regression causing BUG_ON() in cgroup_diput()
commit
bd4f490a079730aadfaf9a728303ea0135c01945 upstream.
The LTP cgroup test suite generates a "kernel BUG at kernel/cgroup.c:790!"
here in cgroup_diput():
/*
* if we're getting rid of the cgroup, refcount should ensure
* that there are no pidlists left.
*/
BUG_ON(!list_empty(&cgrp->pidlists));
The cgroup pidlist rework in 2.6.32 generates the BUG_ON, which is caused
when pidlist_array_load() calls cgroup_pidlist_find():
(1) if a matching cgroup_pidlist is found, it down_write's the mutex of the
pre-existing cgroup_pidlist, and increments its use_count.
(2) if no matching cgroup_pidlist is found, then a new one is allocated, it
down_write's its mutex, and the use_count is set to 0.
(3) the matching, or new, cgroup_pidlist gets returned back to pidlist_array_load(),
which increments its use_count -- regardless whether new or pre-existing --
and up_write's the mutex.
So if a matching list is ever encountered by cgroup_pidlist_find() during
the life of a cgroup directory, it results in an inflated use_count value,
preventing it from ever getting released by cgroup_release_pid_array().
Then if the directory is subsequently removed, cgroup_diput() hits the
BUG_ON() when it finds that the directory's cgroup is still populated with
a pidlist.
The patch simply removes the use_count increment when a matching pidlist
is found by cgroup_pidlist_find(), because it gets bumped by the calling
pidlist_array_load() function while still protected by the list's mutex.
Signed-off-by: Dave Anderson <anderson@redhat.com>
Reviewed-by: Li Zefan <lizf@cn.fujitsu.com>
Acked-by: Ben Blum <bblum@andrew.cmu.edu>
Cc: Paul Menage <menage@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Stephen Hemminger [Fri, 8 Jan 2010 22:43:08 +0000 (14:43 -0800)]
drivers/cpuidle/governors/menu.c: fix undefined reference to `__udivdi3'
commit
5787536edf18e33d06e2bf038bfd0910f4def213 upstream.
menu: use proper 64 bit math
The new menu governor is incorrectly doing a 64 bit divide. Compile
tested only
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Cc: Arjan van de Ven <arjan@linux.intel.com>
Cc: Len Brown <len.brown@intel.com>
Cc: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
OGAWA Hirofumi [Fri, 8 Jan 2010 22:43:11 +0000 (14:43 -0800)]
rtc_cmos: convert shutdown to new pnp_driver->shutdown
commit
004731b2c7c658d36bee167cb1e1a399c2cbccc9 upstream.
commit
abd6633c67925f90775bb74755f9c547e30f1f20 ("pnp: add a shutdown
method to pnp drivers") adds shutdown method to bus driver blindly. With
it, driver->shutdown is no longer valid.
Use pnp_driver->shutdown instead.
Addresses http://bugzilla.kernel.org/show_bug.cgi?id=14889
Signed-off-by: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
Reported-by: Malte Schröder <maltesch@gmx.de>
Cc: "Rafael J. Wysocki" <rjw@sisk.pl>
Cc: Bjorn Helgaas <bjorn.helgaas@hp.com>
Cc: David Hardeman <david@hardeman.nu>
Cc: Dmitry Torokhov <dtor@mail.ru>
Cc: Alessandro Zummo <a.zummo@towertech.it>
Cc: Paul Gortmaker <p_gortmaker@yahoo.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Andrew Morton [Tue, 17 Nov 2009 22:08:52 +0000 (14:08 -0800)]
drm/i915: fix unused var
commit
29bd0ae25f8cb96b63560c2cbccec77b425e1603 upstream.
drivers/gpu/drm/i915/i915_dma.c: In function 'i915_driver_load':
drivers/gpu/drm/i915/i915_dma.c:1114: warning: 'll_base' may be used uninitialized in this function
Partly this is because gcc isn't smart enough. But `ll_base' does get used
uninitialised in the DRM_DEBUG() call.
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: Eric Anholt <eric@anholt.net>
Cc: Dave Airlie <airlied@linux.ie>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Zhao Yakui [Mon, 4 Jan 2010 08:29:32 +0000 (16:29 +0800)]
drm/i915: Select the correct BPC for LVDS on Ironlake
commit
e5a95eb778690bc864eb330202d2c1b974caaeb4 upstream.
Select the correct BPC for LVDS on Ironlake. If it is 18-bit LVDS panel,
the BPC will be 6. When it is 24-bit LVDS panel, the BPC will 8.
At the same time the BPC will be 8 when the output device is CRT/HDMI/DP.
Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Zhao Yakui [Mon, 4 Jan 2010 08:29:31 +0000 (16:29 +0800)]
drm/i915: Make the BPC in FDI rx/transcoder be consistent with that in pipeconf on Ironlake
commit
8faf3b317471179c02db339aa80955a2e88c036d upstream.
Make the BPC in FDI rx/transcoder be consistent with that in pipeconf on Ironlake.
Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Zhao Yakui [Mon, 4 Jan 2010 08:29:30 +0000 (16:29 +0800)]
drm/i915: Enable/disable the dithering for LVDS based on VBT setting
commit
898822ce9561ab9b58a7eb60580a162a83dadecd upstream.
Enable/disable the dithering for LVDS based on VBT setting. On the 965/g4x
platform the dithering flag is defined in LVDS register. And on the ironlake
the dithering flag is defined in pipeconf register.
Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Zhenyu Wang [Tue, 5 Jan 2010 03:25:05 +0000 (11:25 +0800)]
drm: remove address mask param for drm_pci_alloc()
commit
e6be8d9d17bd44061116f601fe2609b3ace7aa69 upstream.
drm_pci_alloc() has input of address mask for setting pci dma
mask on the device, which should be properly setup by drm driver.
And leave it as a param for drm_pci_alloc() would cause confusion
or mistake would corrupt the correct dma mask setting, as seen on
intel hw which set wrong dma mask for hw status page. So remove
it from drm_pci_alloc() function.
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Chris Wilson [Mon, 4 Jan 2010 18:57:57 +0000 (18:57 +0000)]
drm/i915: Permit pinning whilst the device is 'suspended'
commit
e3d8affb0d2d95f2da61e30ce86b33177feb91e8 upstream.
As pinning (allocating and binding GTT memory) does not actually invoke
GPU commands, it is safe, and indeed is attempted, during resumption
from suspension:
[drm:intel_init_clock_gating] *ERROR* failed to pin power context: -16
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reported-by: Hugh Dickins <hugh.dickins@tiscali.co.uk>
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Daniel Vetter [Tue, 15 Dec 2009 16:50:00 +0000 (17:50 +0100)]
drm/i915: fix order of fence release wrt flushing
commit
96b47b65594fe2365f73aede060cb5203561fed3 upstream.
i915_gem_object_unbind had the ordering wrong. The other user,
i915_gem_object_put_fence_reg already has the correct ordering.
Results was usually corrupted pixmaps, especially garbled font glyphs
after a suspend/resume (because this evicts everything).
I'm still waiting for the feedback from the bug-reporters, but
because this obviously fixes a bug (at least for me) I'm already
submitting it.
Bugzilla: http://bugs.freedesktop.org/show_bug.cgi?id=25406
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Zhao Yakui [Fri, 11 Dec 2009 01:26:11 +0000 (09:26 +0800)]
drm/i915: Update LVDS connector status when receiving ACPI LID event
commit
a2565377a5c31e25c77c7cabaf6752abe9a2d83a upstream.
Dirk reports that nothing is displayed on LVDS when using ubuntu 9.1 after
close/reopen the LID. And I also reproduce this issue on another laptop.
After some tests and debug, it seems that it is related with that the
LVDS status is not updated in time in course of suspend/resume.
Now the LID state is used to check whether the LVDS is connected or
disconnected. And when the LID is closed, it means that the LVDS is
disconnected. When it is reopened, it means that the LVDS is connected.
At the same time on some distributions the LID event is also used to put
the system into suspend state. When the LID is closed, the system will enter
the suspend state. When the LID is reopened, the system will be resumed.
In such case when the LID is closed, user-space script will receive the LID
notification event and detect the LVDS as disconnected. Then the system will
enter the suspended state. When the LID is reopened, the system will be
resumed. As the LVDS status is not updated in course of resume, it will cause
that the LVDS connector is marked as unused and disabled. After the resume is
finished,user-space script will try to configure the display mode for LVDS.
But unfortunately as the LVDS status is not updated in time and it is still
marked as disconnected, the LVDS and its corresponding CRTC will be disabled
again in the function of drm_helper_disable_unused_functions after changing
mode for LVDS.
So we had better check and update the status of LVDS connector after receiving
the LID notication event. Then after the system is resumed from suspended
state, we can set the display mode for LVDS correctly.
Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
Reported-by: Dirk Hohndel <hohndel@infradead.org>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Jeff Layton [Fri, 18 Dec 2009 21:28:20 +0000 (16:28 -0500)]
sunrpc: on successful gss error pipe write, don't return error
commit
486bad2e40e938cd68fd853b7a9fa3115a9d3a4a upstream.
When handling the gssd downcall, the kernel should distinguish between a
successful downcall that contains an error code and a failed downcall
(i.e. where the parsing failed or some other sort of problem occurred).
In the former case, gss_pipe_downcall should be returning the number of
bytes written to the pipe instead of an error. In the event of other
errors, we generally want the initiating task to retry the upcall so
we set msg.errno to -EAGAIN. An unexpected error code here is a bug
however, so BUG() in that case.
Signed-off-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Trond Myklebust [Fri, 18 Dec 2009 21:28:12 +0000 (16:28 -0500)]
SUNRPC: Fix the return value in gss_import_sec_context()
commit
b891e4a05ef6beac85465295a032431577c66b16 upstream.
If the context allocation fails, it will return GSS_S_FAILURE, which is
neither a valid error code, nor is it even negative.
Return ENOMEM instead...
Reported-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Trond Myklebust [Fri, 18 Dec 2009 21:28:05 +0000 (16:28 -0500)]
SUNRPC: Fix up an error return value in gss_import_sec_context_kerberos()
commit
14ace024b1e16d2bb9445c8387494fbbd820a738 upstream.
If the context allocation fails, the function currently returns a random
error code, since the variable 'p' still points to a valid memory location.
Ensure that it returns ENOMEM...
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Xiaotian Feng [Thu, 31 Dec 2009 02:52:36 +0000 (10:52 +0800)]
sunrpc: fix peername failed on closed listener
commit
b292cf9ce70d221c3f04ff62db5ab13d9a249ca8 upstream.
There're some warnings of "nfsd: peername failed (err 107)!"
socket error -107 means Transport endpoint is not connected.
This warning message was outputed by svc_tcp_accept() [net/sunrpc/svcsock.c],
when kernel_getpeername returns -107. This means socket might be CLOSED.
And svc_tcp_accept was called by svc_recv() [net/sunrpc/svc_xprt.c]
if (test_bit(XPT_LISTENER, &xprt->xpt_flags)) {
<snip>
newxpt = xprt->xpt_ops->xpo_accept(xprt);
<snip>
So this might happen when xprt->xpt_flags has both XPT_LISTENER and XPT_CLOSE.
Let's take a look at commit
b0401d72, this commit has moved the close
processing after do recvfrom method, but this commit also introduces this
warnings, if the xpt_flags has both XPT_LISTENER and XPT_CLOSED, we should
close it, not accpet then close.
Signed-off-by: Xiaotian Feng <dfeng@redhat.com>
Cc: J. Bruce Fields <bfields@fieldses.org>
Cc: Neil Brown <neilb@suse.de>
Cc: Trond Myklebust <Trond.Myklebust@netapp.com>
Cc: David S. Miller <davem@davemloft.net>
Cc: Nikola Ciprich <extmaillist@linuxbox.cz>
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Christoph Hellwig [Fri, 25 Dec 2009 16:44:45 +0000 (17:44 +0100)]
nfsd: make sure data is on disk before calling ->fsync
commit
7211a4e859ad070b28545c06e0a6cb60b3b8aa31 upstream.
nfsd is not using vfs_fsync, so I missed it when changing the calling
convention during the 2.6.32 window. This patch fixes it to not only
start the data writeout, but also wait for it to complete before calling
into ->fsync.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Rusty Russell [Tue, 5 Jan 2010 02:18:49 +0000 (12:48 +1030)]
Revert "x86: Side-step lguest problem by only building cmpxchg8b_emu for pre-Pentium"
commit
db677ffa5f5a4f15b9dad4d132b3477b80766d82 upstream.
This reverts commit
ae1b22f6e46c03cede7cea234d0bf2253b4261cf.
As Linus said in
982d007a6ee: "There was something really messy about
cmpxchg8b and clone CPU's, so if you enable it on other CPUs later, do it
carefully."
This breaks lguest for those configs, but we can fix that by emulating
if we have to.
Fixes: http://bugzilla.kernel.org/show_bug.cgi?id=14884
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Boaz Harrosh [Sun, 27 Dec 2009 15:01:42 +0000 (17:01 +0200)]
exofs: simple_write_end does not mark_inode_dirty
commit
efd124b999fb4d426b30675f1684521af0872789 upstream.
exofs uses simple_write_end() for it's .write_end handler. But
it is not enough because simple_write_end() does not call
mark_inode_dirty() when it extends i_size. So even if we do
call mark_inode_dirty at beginning of write out, with a very
long IO and a saturated system we might get the .write_inode()
called while still extend-writing to file and miss out on the last
i_size updates.
So override .write_end, call simple_write_end(), and afterwords if
i_size was changed call mark_inode_dirty().
It stands to logic that since simple_write_end() was the one extending
i_size it should also call mark_inode_dirty(). But it looks like all
users of simple_write_end() are memory-bound pseudo filesystems, who
could careless about mark_inode_dirty(). I might submit a
warning-comment patch to simple_write_end() in future.
Signed-off-by: Boaz Harrosh <bharrosh@panasas.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Ben Hutchings [Sat, 19 Dec 2009 14:43:01 +0000 (14:43 +0000)]
modules: Skip empty sections when exporting section notes
commit
10b465aaf9536ee5a16652fa0700740183d48ec9 upstream.
Commit
35dead4 "modules: don't export section names of empty sections
via sysfs" changed the set of sections that have attributes, but did
not change the iteration over these attributes in add_notes_attrs().
This can lead to add_notes_attrs() creating attributes with the wrong
names or with null name pointers.
Introduce a sect_empty() function and use it in both add_sect_attrs()
and add_notes_attrs().
Reported-by: Martin Michlmayr <tbm@cyrius.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Tested-by: Martin Michlmayr <tbm@cyrius.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Guennadi Liakhovetski [Thu, 24 Dec 2009 00:13:51 +0000 (01:13 +0100)]
ASoC: fix params_rate() macro use in several codecs
commit
b3172f222ab5afdc91ea058bd11c42cf169728f3 upstream.
Sevelar ASoC codec drivers wrongly assume, that the params_rate() macro
returns one of SNDRV_PCM_RATE_* defines instead of the actual numerical
sampling rate. Fix them.
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
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>
Linus Torvalds [Wed, 16 Dec 2009 16:23:37 +0000 (08:23 -0800)]
fasync: split 'fasync_helper()' into separate add/remove functions
commit
53281b6d34d44308372d16acb7fb5327609f68b6 upstream.
Yes, the add and remove cases do share the same basic loop and the
locking, but the compiler can inline and then CSE some of the end result
anyway. And splitting it up makes the code way easier to follow,
and makes it clearer exactly what the semantics are.
In particular, we must make sure that the FASYNC flag in file->f_flags
exactly matches the state of "is this file on any fasync list", since
not only is that flag visible to user space (F_GETFL), but we also use
that flag to check whether we need to remove any fasync entries on file
close.
We got that wrong for the case of a mixed use of file locking (which
tries to remove any fasync entries for file leases) and fasync.
Splitting the function up also makes it possible to do some future
optimizations without making the function even messier. In particular,
since the FASYNC flag has to match the state of "is this on a list", we
can do the following future optimizations:
- on remove, we don't even need to get the locks and traverse the list
if FASYNC isn't set, since we can know a priori that there is no
point (this is effectively the same optimization that we already do
in __fput() wrt removing fasync on file close)
- on add, we can use the FASYNC flag to decide whether we are changing
an existing entry or need to allocate a new one.
but this is just the cleanup + fix for the FASYNC flag.
Acked-by: Al Viro <viro@ZenIV.linux.org.uk>
Tested-by: Tavis Ormandy <taviso@google.com>
Cc: Jeff Dike <jdike@addtoit.com>
Cc: Matt Mackall <mpm@selenic.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Al Viro [Thu, 14 Jan 2010 19:39:39 +0000 (11:39 -0800)]
Greg Kroah-Hartman [Wed, 6 Jan 2010 23:07:45 +0000 (15:07 -0800)]
Linux 2.6.32.3
Serge E. Hallyn [Tue, 29 Dec 2009 20:50:19 +0000 (14:50 -0600)]
generic_permission: MAY_OPEN is not write access
commit
7ea6600148c265b1fd53e521022b1d7aec81d974 upstream.
generic_permission was refusing CAP_DAC_READ_SEARCH-enabled
processes from opening DAC-protected files read-only, because
do_filp_open adds MAY_OPEN to the open mask.
Ignore MAY_OPEN. After this patch, CAP_DAC_READ_SEARCH is
again sufficient to open(fname, O_RDONLY) on a file to which
DAC otherwise refuses us read permission.
Reported-by: Mike Kazantsev <mk.fraggod@gmail.com>
Signed-off-by: Serge E. Hallyn <serue@us.ibm.com>
Tested-by: Mike Kazantsev <mk.fraggod@gmail.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Gertjan van Wingerde [Mon, 14 Dec 2009 19:33:55 +0000 (20:33 +0100)]
rt2x00: Disable powersaving for rt61pci and rt2800pci.
commit
93b6bd26b74efe46b4579592560f9f1cb7b61994 upstream.
We've had many reports of rt61pci failures with powersaving enabled.
Therefore, as a stop-gap measure, disable powersaving of the rt61pci
until we have found a proper solution.
Also disable powersaving on rt2800pci as it most probably will show
the same problem.
Signed-off-by: Gertjan van Wingerde <gwingerde@gmail.com>
Acked-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Hugh Dickins [Wed, 30 Dec 2009 23:00:30 +0000 (23:00 +0000)]
ksm: fix mlockfreed to munlocked
2.6.33-rc1 commit
73848b4684e84a84cfd1555af78d41158f31e16b, adjusted
to include
31e855ea7173bdb0520f9684580423a9560f66e0's movement of
the unlock_page(oldpage), but omit other intervening cleanups.
When KSM merges an mlocked page, it has been forgetting to munlock it:
that's been left to free_page_mlock(), which reports it in /proc/vmstat
as unevictable_pgs_mlockfreed instead of unevictable_pgs_munlocked,
which indicates that such pages _might_ be left unevictable for long
after they should be evictable. Call munlock_vma_page() to fix that.
Signed-off-by: Hugh Dickins <hugh.dickins@tiscali.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Rik van Riel [Tue, 15 Dec 2009 01:59:48 +0000 (17:59 -0800)]
vmscan: do not evict inactive pages when skipping an active list scan
commit
b39415b2731d7dec5e612d2d12595da82399eedf upstream.
In AIM7 runs, recent kernels start swapping out anonymous pages well
before they should. This is due to shrink_list falling through to
shrink_inactive_list if !inactive_anon_is_low(zone, sc), when all we
really wanted to do is pre-age some anonymous pages to give them extra
time to be referenced while on the inactive list.
The obvious fix is to make sure that shrink_list does not fall through to
scanning/reclaiming inactive pages when we called it to scan one of the
active lists.
This change should be safe because the loop in shrink_zone ensures that we
will still shrink the anon and file inactive lists whenever we should.
[kosaki.motohiro@jp.fujitsu.com: inactive_file_is_low() should be inactive_anon_is_low()]
Reported-by: Larry Woodman <lwoodman@redhat.com>
Signed-off-by: Rik van Riel <riel@redhat.com>
Acked-by: Johannes Weiner <hannes@cmpxchg.org>
Cc: Tomasz Chmielewski <mangoo@wpkg.org>
Signed-off-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Rik Theys <rik.theys@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Rusty Russell [Mon, 4 Jan 2010 08:56:14 +0000 (19:26 +1030)]
lguest: fix bug in setting guest GDT entry
commit
3e27249c84beed1c79d767b350e52ad038db9053 upstream.
We kill the guest, but then we blatt random stuff.
Reported-by: Dan Carpenter <error27@gmail.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Fang Wenqi [Thu, 24 Dec 2009 22:51:42 +0000 (17:51 -0500)]
ext4: Update documentation to correct the inode_readahead_blks option name
commit
6d3b82f2d31f22085e5711b28dddcb9fb3d97a25 upstream.
Per commit
240799cd, the option name for readahead should be
inode_readahead_blks, not inode_readahead.
Signed-off-by: Fang Wenqi <antonf@turbolinux.com.cn>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Peter Zijlstra [Mon, 16 Nov 2009 09:28:09 +0000 (10:28 +0100)]
sched: Sched_rt_periodic_timer vs cpu hotplug
commit
047106adcc85e3023da210143a6ab8a55df9e0fc upstream.
Heiko reported a case where a timer interrupt managed to
reference a root_domain structure that was already freed by a
concurrent hot-un-plug operation.
Solve this like the regular sched_domain stuff is also
synchronized, by adding a synchronize_sched() stmt to the free
path, this ensures that a root_domain stays present for any
atomic section that could have observed it.
Reported-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Acked-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: Gregory Haskins <ghaskins@novell.com>
Cc: Siddha Suresh B <suresh.b.siddha@intel.com>
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
LKML-Reference: <
1258363873.26714.83.camel@laptop>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Borislav Petkov [Mon, 21 Dec 2009 17:55:18 +0000 (18:55 +0100)]
amd64_edac: fix forcing module load/unload
commit
43f5e68733cfe8bed3c30b5c14c4993dffb29766 upstream.
Clear the override flag after force-loading the module.
Signed-off-by: Borislav Petkov <borislav.petkov@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Borislav Petkov [Mon, 21 Dec 2009 17:13:01 +0000 (18:13 +0100)]
amd64_edac: make driver loading more robust
commit
56b34b91e22313294154cee0c16e294cf8a45b61 upstream.
Currently, the module does not initialize fully when the DIMMs aren't
ECC but remains still loaded. Propagate the error when no instance of
the driver is properly initialized and prevent further loading.
Reorganize and polish error handling in amd64_edac_init() while at it.
Signed-off-by: Borislav Petkov <borislav.petkov@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Borislav Petkov [Mon, 21 Dec 2009 14:15:59 +0000 (15:15 +0100)]
amd64_edac: fix driver instance freeing
commit
8f68ed9728193b1f2fb53ba06031b06bd8b3d1b4 upstream.
Fix use-after-free errors by pushing all memory-freeing calls to the end
of amd64_remove_one_instance().
Reported-by: Darren Jenkins <darrenrjenkins@gmail.com>
LKML-Reference: <
1261370306.11354.52.camel@ICE-BOX>
Signed-off-by: Borislav Petkov <borislav.petkov@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Borislav Petkov [Wed, 16 Dec 2009 23:16:25 +0000 (00:16 +0100)]
x86, msr: msrs_alloc/free for CONFIG_SMP=n
commit
6ede31e03084ee084bcee073ef3d1136f68d0906 upstream.
Randy Dunlap reported the following build error:
"When CONFIG_SMP=n, CONFIG_X86_MSR=m:
ERROR: "msrs_free" [drivers/edac/amd64_edac_mod.ko] undefined!
ERROR: "msrs_alloc" [drivers/edac/amd64_edac_mod.ko] undefined!"
This is due to the fact that <arch/x86/lib/msr.c> is conditioned on
CONFIG_SMP and in the UP case we have only the stubs in the header.
Fork off SMP functionality into a new file (msr-smp.c) and build
msrs_{alloc,free} unconditionally.
Reported-by: Randy Dunlap <randy.dunlap@oracle.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Signed-off-by: Borislav Petkov <petkovbb@gmail.com>
LKML-Reference: <
20091216231625.GD27228@liondog.tnic>
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Borislav Petkov [Fri, 11 Dec 2009 17:14:40 +0000 (18:14 +0100)]
x86, msr: Add support for non-contiguous cpumasks
commit
505422517d3f126bb939439e9d15dece94e11d2c upstream.
The current rd/wrmsr_on_cpus helpers assume that the supplied
cpumasks are contiguous. However, there are machines out there
like some K8 multinode Opterons which have a non-contiguous core
enumeration on each node (e.g. cores 0,2 on node 0 instead of 0,1), see
http://www.gossamer-threads.com/lists/linux/kernel/
1160268.
This patch fixes out-of-bounds writes (see URL above) by adding per-CPU
msr structs which are used on the respective cores.
Additionally, two helpers, msrs_{alloc,free}, are provided for use by
the callers of the MSR accessors.
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Mauro Carvalho Chehab <mchehab@redhat.com>
Cc: Aristeu Rozanski <aris@redhat.com>
Cc: Randy Dunlap <randy.dunlap@oracle.com>
Cc: Doug Thompson <dougthompson@xmission.com>
Signed-off-by: Borislav Petkov <borislav.petkov@amd.com>
LKML-Reference: <
20091211171440.GD31998@aftab>
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Borislav Petkov [Tue, 3 Nov 2009 14:29:26 +0000 (15:29 +0100)]
amd64_edac: unify MCGCTL ECC switching
commit
f6d6ae965760906d79ab29bc38507608c5971549 upstream.
Unify almost identical code into one function and remove NUMA-specific
usage (specifically cpumask_of_node()) in favor of generic topology
methods.
Remove unused defines, while at it.
Signed-off-by: Borislav Petkov <borislav.petkov@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Rusty Russell [Tue, 3 Nov 2009 04:26:35 +0000 (14:56 +1030)]
cpumask: use modern cpumask style in drivers/edac/amd64_edac.c
commit
ba578cb34a71fb08fff14ac0796b934a8c9991e1 upstream.
cpumask_t -> struct cpumask, and don't put one on the stack. (Note: this
is actually on the stack unless CONFIG_CPUMASK_OFFSTACK=y).
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: Borislav Petkov <borislav.petkov@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Borislav Petkov [Thu, 30 Jul 2009 09:10:02 +0000 (11:10 +0200)]
x86, msr: Unify rdmsr_on_cpus/wrmsr_on_cpus
commit
b8a4754147d61f5359a765a3afd3eb03012aa052 upstream.
Since rdmsr_on_cpus and wrmsr_on_cpus are almost identical, unify them
into a common __rwmsr_on_cpus helper thus avoiding code duplication.
While at it, convert cpumask_t's to const struct cpumask *.
Signed-off-by: Borislav Petkov <borislav.petkov@amd.com>
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Dmitry Monakhov [Thu, 10 Dec 2009 16:36:27 +0000 (16:36 +0000)]
ext4: fix sleep inside spinlock issue with quota and dealloc (#14739)
commit
39bc680a8160bb9d6743f7873b535d553ff61058 upstream.
Unlock i_block_reservation_lock before vfs_dq_reserve_block().
This patch fixes http://bugzilla.kernel.org/show_bug.cgi?id=14739
Cc: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Dmitry Monakhov <dmonakhov@openvz.org>
Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Dmitry Monakhov [Mon, 14 Dec 2009 12:21:14 +0000 (15:21 +0300)]
ext4: Convert to generic reserved quota's space management.
commit
a9e7f4472075fb6937c545af3f6329e9946bbe66 upstream.
This patch also fixes write vs chown race condition.
Acked-by: "Theodore Ts'o" <tytso@mit.edu>
Signed-off-by: Dmitry Monakhov <dmonakhov@openvz.org>
Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Dmitry Monakhov [Mon, 14 Dec 2009 12:21:13 +0000 (15:21 +0300)]
quota: decouple fs reserved space from quota reservation
commit
fd8fbfc1709822bd94247c5b2ab15a5f5041e103 upstream.
Currently inode_reservation is managed by fs itself and this
reservation is transfered on dquot_transfer(). This means what
inode_reservation must always be in sync with
dquot->dq_dqb.dqb_rsvspace. Otherwise dquot_transfer() will result
in incorrect quota(WARN_ON in dquot_claim_reserved_space() will be
triggered)
This is not easy because of complex locking order issues
for example http://bugzilla.kernel.org/show_bug.cgi?id=14739
The patch introduce quota reservation field for each fs-inode
(fs specific inode is used in order to prevent bloating generic
vfs inode). This reservation is managed by quota code internally
similar to i_blocks/i_bytes and may not be always in sync with
internal fs reservation.
Also perform some code rearrangement:
- Unify dquot_reserve_space() and dquot_reserve_space()
- Unify dquot_release_reserved_space() and dquot_free_space()
- Also this patch add missing warning update to release_rsv()
dquot_release_reserved_space() must call flush_warnings() as
dquot_free_space() does.
Signed-off-by: Dmitry Monakhov <dmonakhov@openvz.org>
Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Dmitry Monakhov [Mon, 14 Dec 2009 12:21:12 +0000 (15:21 +0300)]
Add unlocked version of inode_add_bytes() function
commit
b462707e7ccad058ae151e5c5b06eb5cadcb737f upstream.
Quota code requires unlocked version of this function. Off course
we can just copy-paste the code, but copy-pasting is always an evil.
Signed-off-by: Dmitry Monakhov <dmonakhov@openvz.org>
Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Jan Kara [Mon, 30 Nov 2009 18:47:55 +0000 (19:47 +0100)]
udf: Try harder when looking for VAT inode
commit
e971b0b9e0dd50d9ceecb67a6a6ab80a80906033 upstream.
Some disks do not contain VAT inode in the last recorded block as required
by the standard but a few blocks earlier (or the number of recorded blocks
is wrong). So look for the VAT inode a bit before the end of the media.
Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Andrey Borzenkov [Tue, 22 Dec 2009 18:38:44 +0000 (21:38 +0300)]
orinoco: fix GFP_KERNEL in orinoco_set_key with interrupts disabled
commit
5b0691508aa99d309101a49b4b084dc16b3d7019 upstream.
orinoco_set_key is called from two places both with interrupts disabled
(under orinoco_lock). Use GFP_ATOMIC instead of GFP_KERNEL. Fixes following
warning:
[ 77.254109] WARNING: at /home/bor/src/linux-git/kernel/lockdep.c:2465 lockdep_trace_alloc+0x9a/0xa0()
[ 77.254109] Hardware name: PORTEGE 4000
[ 77.254109] Modules linked in: af_packet irnet ppp_generic slhc ircomm_tty ircomm binfmt_misc dm_mirror dm_region_hash dm_log dm_round_robin dm_multipath dm_mod loop nvram toshiba cryptomgr aead pcompress crypto_blkcipher michael_mic crypto_hash crypto_algapi orinoco_cs orinoco cfg80211 smsc_ircc2 pcmcia irda toshiba_acpi yenta_socket video i2c_ali1535 backlight rsrc_nonstatic ali_agp pcmcia_core psmouse output crc_ccitt i2c_core alim1535_wdt rfkill sg evdev ohci_hcd agpgart usbcore pata_ali libata reiserfs [last unloaded: scsi_wait_scan]
[ 77.254109] Pid: 2296, comm: wpa_supplicant Not tainted 2.6.32-1avb #1
[ 77.254109] Call Trace:
[ 77.254109] [<
c011f0ad>] warn_slowpath_common+0x6d/0xa0
[ 77.254109] [<
c014206a>] ? lockdep_trace_alloc+0x9a/0xa0
[ 77.254109] [<
c014206a>] ? lockdep_trace_alloc+0x9a/0xa0
[ 77.254109] [<
c011f0f5>] warn_slowpath_null+0x15/0x20
[ 77.254109] [<
c014206a>] lockdep_trace_alloc+0x9a/0xa0
[ 77.254109] [<
c018d296>] __kmalloc+0x36/0x130
[ 77.254109] [<
dffcb6a8>] ? orinoco_set_key+0x48/0x1c0 [orinoco]
[ 77.254109] [<
dffcb6a8>] orinoco_set_key+0x48/0x1c0 [orinoco]
[ 77.254109] [<
dffcb9fc>] orinoco_ioctl_set_encodeext+0x1dc/0x2d0 [orinoco]
[ 77.254109] [<
c035b117>] ioctl_standard_call+0x207/0x3b0
[ 77.254109] [<
dffcb820>] ? orinoco_ioctl_set_encodeext+0x0/0x2d0 [orinoco]
[ 77.254109] [<
c0307f1f>] ? rtnl_lock+0xf/0x20
[ 77.254109] [<
c0307f1f>] ? rtnl_lock+0xf/0x20
[ 77.254109] [<
c02fb115>] ? __dev_get_by_name+0x85/0xb0
[ 77.254109] [<
c035b616>] wext_handle_ioctl+0x176/0x200
[ 77.254109] [<
dffcb820>] ? orinoco_ioctl_set_encodeext+0x0/0x2d0 [orinoco]
[ 77.254109] [<
c030020f>] dev_ioctl+0x6af/0x730
[ 77.254109] [<
c02eec65>] ? move_addr_to_kernel+0x55/0x60
[ 77.254109] [<
c02eed59>] ? sys_sendto+0xe9/0x130
[ 77.254109] [<
c02ed77e>] sock_ioctl+0x7e/0x250
[ 77.254109] [<
c02ed700>] ? sock_ioctl+0x0/0x250
[ 77.254109] [<
c019cf4c>] vfs_ioctl+0x1c/0x70
[ 77.254109] [<
c019d1fa>] do_vfs_ioctl+0x6a/0x590
[ 77.254109] [<
c0178e50>] ? might_fault+0x90/0xa0
[ 77.254109] [<
c0178e0a>] ? might_fault+0x4a/0xa0
[ 77.254109] [<
c02ef90e>] ? sys_socketcall+0x17e/0x280
[ 77.254109] [<
c019d759>] sys_ioctl+0x39/0x60
[ 77.254109] [<
c0102e3b>] sysenter_do_call+0x12/0x32
[ 77.254109] ---[ end trace
95ef563548d21efd ]---
Signed-off-by: Andrey Borzenkov <arvidjaar@mail.ru>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Paolo Bonzini [Wed, 8 Jul 2009 10:27:39 +0000 (12:27 +0200)]
xen: wait up to 5 minutes for device connetion
commit
ae7888012969355a548372e99b066d9e31153b62 upstream.
Increases the device timeout from 10s to 5 minutes, giving the user a
visual indication during that time in case there are problems. The patch
is a backport of changesets 144 and 150 in the Xenbits tree.
Cc: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Paolo Bonzini [Wed, 8 Jul 2009 10:27:38 +0000 (12:27 +0200)]
xen: improvement to wait_for_devices()
commit
f8dc33088febc63286b7a60e6b678de8e064de8e upstream.
When printing a warning about a timed-out device, print the
current state of both ends of the device connection (i.e., backend as
well as frontend). This backports half of changeset 146 from the
Xenbits tree.
Cc: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Paolo Bonzini [Wed, 8 Jul 2009 10:27:37 +0000 (12:27 +0200)]
xen: fix is_disconnected_device/exists_disconnected_device
commit
c6e1971139be1342902873181f3b80a979bfb33b upstream.
The logic of is_disconnected_device/exists_disconnected_device is wrong
in that they are used to test whether a device is trying to connect (i.e.
connecting). For this reason the patch fixes them to not consider a
Closing or Closed device to be connecting. At the same time the patch
also renames the functions according to what they really do; you could
say a closed device is "disconnected" (the old name), but not "connecting"
(the new name).
This patch is a backport of changeset 909 from the Xenbits tree.
Cc: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Stefan Weinhuber [Mon, 7 Dec 2009 11:51:48 +0000 (12:51 +0100)]
S390: dasd: support DIAG access for read-only devices
commit
22825ab7693fd29769518a0d25ba43c01a50092a upstream.
When a DASD device is used with the DIAG discipline, the DIAG
initialization will indicate success or error with a respective
return code. So far we have interpreted a return code of 4 as error,
but it actually means that the initialization was successful, but
the device is read-only. To allow read-only devices to be used with
DIAG we need to accept a return code of 4 as success.
Re-initialization of the DIAG access is also part of the DIAG error
recovery. If we find that the access mode of a device has been
changed from writable to read-only while the device was in use,
we print an error message.
Signed-off-by: Stefan Weinhuber <wein@de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Cc: Stephen Powell <zlinuxman@wowway.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Zhao Yakui [Wed, 9 Dec 2009 03:23:42 +0000 (11:23 +0800)]
drm: disable all the possible outputs/crtcs before entering KMS mode
commit
b16d9acbdb97452d1418420e069acf7381ef10bb upstream.
Sometimes we will use a crtc for integerated LVDS, which is different with
that assigned by BIOS. If we want to get flicker-free transitions,
then we could read out the current state for it and set our current state
accordingly.
But it is true that if we aren't reading current state out, we do need
to turn everything off before modesetting. Otherwise the clocks can get very
angry and we get things worse than a flicker at boot.
In fact we also do the similar thing in UMS mode. We will disable all the
possible outputs/crtcs for the first modesetting.
So we disable all the possible outputs/crtcs before entering the KMS mode.
Before we configure connector/encoder/crtc, the function of
drm_helper_disable_unused_function can disable all the possible outputs/crtcs.
Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Rafal Milecki <zajec5@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Dave Airlie [Mon, 21 Dec 2009 04:33:52 +0000 (14:33 +1000)]
drm/radeon/kms: fix crtc vblank update for r600
In 2.6.32.2 r600 had no IRQ support, however the patch in
500b758725314ab1b5316eb0caa5b0fa26740e6b to fix vblanks on avivo
cards, needs irqs.
So check for an R600 card and avoid this path if so.
This is a stable only patch for 2.6.32.2 as 2.6.33 has IRQs for r600.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Peter Zijlstra [Wed, 25 Nov 2009 12:31:39 +0000 (13:31 +0100)]
sched: Fix balance vs hotplug race
commit
6ad4c18884e864cf4c77f9074d3d1816063f99cd upstream.
Since (
e761b77: cpu hotplug, sched: Introduce cpu_active_map and redo
sched domain managment) we have cpu_active_mask which is suppose to rule
scheduler migration and load-balancing, except it never (fully) did.
The particular problem being solved here is a crash in try_to_wake_up()
where select_task_rq() ends up selecting an offline cpu because
select_task_rq_fair() trusts the sched_domain tree to reflect the
current state of affairs, similarly select_task_rq_rt() trusts the
root_domain.
However, the sched_domains are updated from CPU_DEAD, which is after the
cpu is taken offline and after stop_machine is done. Therefore it can
race perfectly well with code assuming the domains are right.
Cure this by building the domains from cpu_active_mask on
CPU_DOWN_PREPARE.
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
LKML-Reference: <new-submission>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Holger Hoffstätte <holger.hoffstaette@googlemail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Geert Uytterhoeven [Sun, 13 Dec 2009 19:21:34 +0000 (20:21 +0100)]
Keys: KEYCTL_SESSION_TO_PARENT needs TIF_NOTIFY_RESUME architecture support
commit
a00ae4d21b2fa9379914f270ffffd8d3bec55430 upstream.
As of commit
ee18d64c1f632043a02e6f5ba5e045bb26a5465f ("KEYS: Add a keyctl to
install a process's session keyring on its parent [try #6]"), CONFIG_KEYS=y
fails to build on architectures that haven't implemented TIF_NOTIFY_RESUME yet:
security/keys/keyctl.c: In function 'keyctl_session_to_parent':
security/keys/keyctl.c:1312: error: 'TIF_NOTIFY_RESUME' undeclared (first use in this function)
security/keys/keyctl.c:1312: error: (Each undeclared identifier is reported only once
security/keys/keyctl.c:1312: error: for each function it appears in.)
Make KEYCTL_SESSION_TO_PARENT depend on TIF_NOTIFY_RESUME until
m68k, and xtensa have implemented it.
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: James Morris <jmorris@namei.org>
Acked-by: Mike Frysinger <vapier@gentoo.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Larry Finger [Tue, 24 Nov 2009 00:40:45 +0000 (18:40 -0600)]
b43: avoid PPC fault during resume
commit
c2ff581acab16c6af56d9e8c1a579bf041ec00b1 upstream.
The routine b43_is_hw_radio_enabled() has long been a problem.
For PPC architecture with PHY Revision < 3, a read of the register
B43_MMIO_HWENABLED_LO will cause a CPU fault unless b43_status()
returns a value of 2 (B43_STAT_STARTED) (BUG 14181). Fixing that
results in Bug 14538 in which the driver is unable to reassociate
after resuming from hibernation because b43_status() returns 0.
The correct fix would be to determine why the status is 0; however,
I have not yet found why that happens. The correct value is found for
my device, which has PHY revision >= 3.
Returning TRUE when the PHY revision < 3 and b43_status() returns 0 fixes
the regression for 2.6.32.
This patch fixes the problem in Red Hat Bugzilla #538523.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Tested-by: Christian Casteyde <casteyde.christian@free.fr>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Jonathan Cameron [Wed, 16 Dec 2009 20:38:28 +0000 (21:38 +0100)]
hwmon: (sht15) Off-by-one error in array index + incorrect constants
commit
4235f684b66d6f00d2cd8849c884cf8f8b57ecad upstream.
Fix an off-by-one error in array index + incorrect constants.
Signed-off-by: Christoph Walser <walser@tik.ee.ethz.ch>
Signed-off-by: Jonathan Cameron <jic23@cam.ac.uk>
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Patrick McHardy [Tue, 15 Dec 2009 15:59:59 +0000 (16:59 +0100)]
netfilter: fix crashes in bridge netfilter caused by fragment jumps
commit
8fa9ff6849bb86c59cc2ea9faadf3cb2d5223497 upstream.
When fragments from bridge netfilter are passed to IPv4 or IPv6 conntrack
and a reassembly queue with the same fragment key already exists from
reassembling a similar packet received on a different device (f.i. with
multicasted fragments), the reassembled packet might continue on a different
codepath than where the head fragment originated. This can cause crashes
in bridge netfilter when a fragment received on a non-bridge device (and
thus with skb->nf_bridge == NULL) continues through the bridge netfilter
code.
Add a new reassembly identifier for packets originating from bridge
netfilter and use it to put those packets in insolated queues.
Fixes http://bugzilla.kernel.org/show_bug.cgi?id=14805
Reported-and-Tested-by: Chong Qiao <qiaochong@loongson.cn>
Signed-off-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Patrick McHardy [Tue, 15 Dec 2009 15:59:18 +0000 (16:59 +0100)]
ipv6: reassembly: use seperate reassembly queues for conntrack and local delivery
commit
0b5ccb2ee250136dd7385b1c7da28417d0d4d32d upstream.
Currently the same reassembly queue might be used for packets reassembled
by conntrack in different positions in the stack (PREROUTING/LOCAL_OUT),
as well as local delivery. This can cause "packet jumps" when the fragment
completing a reassembled packet is queued from a different position in the
stack than the previous ones.
Add a "user" identifier to the reassembly queue key to seperate the queues
of each caller, similar to what we do for IPv4.
Signed-off-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Roger Oksanen [Sat, 19 Dec 2009 04:18:21 +0000 (20:18 -0800)]
e100: Fix broken cbs accounting due to missing memset.
commit
70abc8cb90e679d8519721e2761d8366a18212a6 upstream.
Alan Stern noticed that e100 caused slab corruption.
commit
98468efddb101f8a29af974101c17ba513b07be1 changed
the allocation of cbs to use dma pools that don't return zeroed memory,
especially the cb->status field used to track which cb to clean, causing
(the visible) double freeing of skbs and a wrong free cbs count.
Now the cbs are explicitly zeroed at allocation time.
Reported-by: Alan Stern <stern@rowland.harvard.edu>
Tested-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Roger Oksanen <roger.oksanen@cs.helsinki.fi>
Acked-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Daisuke Nishimura [Wed, 16 Dec 2009 00:47:12 +0000 (16:47 -0800)]
memcg: avoid oom-killing innocent task in case of use_hierarchy
commit
d31f56dbf8bafaacb0c617f9a6f137498d5c7aed upstream.
task_in_mem_cgroup(), which is called by select_bad_process() to check
whether a task can be a candidate for being oom-killed from memcg's limit,
checks "curr->use_hierarchy"("curr" is the mem_cgroup the task belongs
to).
But this check return true(it's false positive) when:
<some path>/aa use_hierarchy == 0 <- hitting limit
<some path>/aa/00 use_hierarchy == 1 <- the task belongs to
This leads to killing an innocent task in aa/00. This patch is a fix for
this bug. And this patch also fixes the arg for
mem_cgroup_print_oom_info(). We should print information of mem_cgroup
which the task being killed, not current, belongs to.
Signed-off-by: Daisuke Nishimura <nishimura@mxp.nes.nec.co.jp>
Acked-by: Balbir Singh <balbir@linux.vnet.ibm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Linus Torvalds [Thu, 17 Dec 2009 15:04:56 +0000 (07:04 -0800)]
x86/ptrace: make genregs[32]_get/set more robust
commit
04a1e62c2cec820501f93526ad1e46073b802dc4 upstream.
The loop condition is fragile: we compare an unsigned value to zero, and
then decrement it by something larger than one in the loop. All the
callers should be passing in appropriately aligned buffer lengths, but
it's better to just not rely on it, and have some appropriate defensive
loop limits.
Acked-by: Roland McGrath <roland@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Dan Carpenter [Thu, 10 Dec 2009 19:44:51 +0000 (16:44 -0300)]
V4L/DVB (13596): ov511.c typo: lock => unlock
commit
50e9d31183ed61c787b870cb3ee8f6c3db8c8a1e upstream.
This was found with a static checker and has not been tested, but it seems
pretty clear that the mutex_lock() was supposed to be mutex_unlock()
Signed-off-by: Dan Carpenter <error27@gmail.com>
Signed-off-by: Douglas Schilling Landgraf <dougsland@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Cc: Brandon Philips <brandon@ifup.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
WANG Cong [Thu, 17 Dec 2009 23:27:05 +0000 (15:27 -0800)]
kernel/sysctl.c: fix the incomplete part of sysctl_max_map_count-should-be-non-negative.patch
commit
3e26120cc7c819c97bc07281ca1fb9017cfe9a39 upstream.
It is a mistake that we used 'proc_dointvec', it should be
'proc_dointvec_minmax', as in the original patch.
Signed-off-by: WANG Cong <amwang@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Amerigo Wang [Tue, 15 Dec 2009 01:59:52 +0000 (17:59 -0800)]
'sysctl_max_map_count' should be non-negative
commit
70da2340fbc68e91e701762f785479ab495a0869 upstream.
Jan Engelhardt reported we have this problem:
setting max_map_count to a value large enough results in programs dying at
first try. This is on 2.6.31.6:
15:59 borg:/proc/sys/vm # echo $[1<<31-1] >max_map_count
15:59 borg:/proc/sys/vm # cat max_map_count
1073741824
15:59 borg:/proc/sys/vm # echo $[1<<31] >max_map_count
15:59 borg:/proc/sys/vm # cat max_map_count
Killed
This is because we have a chance to make 'max_map_count' negative. but
it's meaningless. Make it only accept non-negative values.
Reported-by: Jan Engelhardt <jengelh@medozas.de>
Signed-off-by: WANG Cong <amwang@redhat.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: James Morris <jmorris@namei.org>
Cc: Alexey Dobriyan <adobriyan@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
David Howells [Tue, 15 Dec 2009 19:27:45 +0000 (19:27 +0000)]
NOMMU: Optimise away the {dac_,}mmap_min_addr tests
commit
6e1415467614e854fee660ff6648bd10fa976e95 upstream.
In NOMMU mode clamp dac_mmap_min_addr to zero to cause the tests on it to be
skipped by the compiler. We do this as the minimum mmap address doesn't make
any sense in NOMMU mode.
mmap_min_addr and round_hint_to_min() can be discarded entirely in NOMMU mode.
Signed-off-by: David Howells <dhowells@redhat.com>
Acked-by: Eric Paris <eparis@redhat.com>
Signed-off-by: James Morris <jmorris@namei.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Luis R. Rodriguez [Thu, 24 Dec 2009 20:26:09 +0000 (15:26 -0500)]
mac80211: fix race with suspend and dynamic_ps_disable_work
commit
b98c06b6debfe84c90200143bb1102f312f50a33 upstream.
When mac80211 suspends it calls a driver's suspend callback
as a last step and after that the driver assumes no calls will
be made to it until we resume and its start callback is kicked.
If such calls are made, however, suspend can end up throwing
hardware in an unexpected state and making the device unusable
upon resume.
Fix this by preventing mac80211 to schedule dynamic_ps_disable_work
by checking for when mac80211 starts to suspend and starts
quiescing. Frames should be allowed to go through though as
that is part of the quiescing steps and we do not flush the
mac80211 workqueue since it was already done towards the
beginning of suspend cycle.
The other mac80211 issue will be hanled in the next patch.
For further details see refer to the thread:
http://marc.info/?t=
126144866100001&r=1&w=2
Cc: stable@kernel.org
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>
Reinette Chatre [Mon, 14 Dec 2009 22:12:13 +0000 (14:12 -0800)]
iwlwifi: fix 40MHz operation setting on cards that do not allow it
commit
6c3069b1e7e983e176a5f826e2edffefdd404a08 upstream.
Some devices have 40MHz operation disabled entirely. Ensure that driver do
not enable 40MHz operation if a channel does not allow this.
This fixes http://bugzilla.intellinuxwireless.org/show_bug.cgi?id=2135
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>
Johannes Berg [Mon, 14 Dec 2009 22:12:09 +0000 (14:12 -0800)]
iwlwifi: fix more eeprom endian bugs
commit
b7bb1756cb6a610cdbac8cfdad9e79bb5670b63b upstream.
I've also for a long time had a problem with the
temperature calculation code, which I had fixed
by byte-swapping the values, and now it turns out
that was the correct fix after all.
Also, any use of iwl_eeprom_query_addr() that is
for more than a u8 must be cast to little endian,
and some structs as well.
Fix all this. Again, no real impact on platforms
that already are little endian.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
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>
Johannes Berg [Mon, 14 Dec 2009 22:12:08 +0000 (14:12 -0800)]
iwlwifi: fix EEPROM/OTP reading endian annotations and a bug
commit
af6b8ee38833b39f70946f767740565ceb126961 upstream.
The construct "le16_to_cpu((__force __le16)(r >> 16))" has
always bothered me when looking through the iwlwifi code,
it shouldn't be necessary to __force anything, and before
this code, "r" was obtained with an ioread32, which swaps
each of the two u16 values in it properly when swapping the
entire u32 value. I've had arguments about this code with
people before, but always conceded they were right because
removing it only made things not work at all on big endian
platforms.
However, analysing a failure of the OTP reading code, I now
finally figured out what is going on, and why my intuition
about that code being wrong was right all along.
It turns out that the 'priv->eeprom' u8 array really wants
to have the data in it in little endian. So the force code
above and all really converts *to* little endian, not from
it. Cf., for instance, the function iwl_eeprom_query16() --
it reads two u8 values and combines them into a u16, in a
little-endian way. And considering it more, it makes sense
to have the eeprom array as on the device, after all not
all values really are 16-bit values, the MAC address for
instance is not.
Now, what this really means is that all the annotations are
completely wrong. The eeprom reading code should fill the
priv->eeprom array as a __le16 array, with __le16 values.
This also means that iwl_read_otp_word() should really have
a __le16 pointer as the data argument, since it should be
filling that in a format suitable for priv->eeprom.
Propagating these changes throughout, iwl_find_otp_image()
is found to be, now obviously visible, defective -- it uses
the data returned by iwl_read_otp_word() directly as if it
was CPU endianness. Fixing that, which is this hunk of the
patch:
- next_link_addr = link_value * sizeof(u16);
+ next_link_addr = le16_to_cpu(link_value) * sizeof(u16);
is the only real change of this patch. Everything else is
just fixing the sparse annotations.
Also, the bug only shows up on big endian platforms with a
1000 series card. 5000 and previous series do not use OTP,
and 6000 series has shadow RAM support which means we don't
ever use the defective code on any cards but 1000.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
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>
Zhu Yi [Mon, 14 Dec 2009 22:12:12 +0000 (14:12 -0800)]
iwl3945: fix panic in iwl3945 driver
commit
dc57a303faab8562b92e85df0d79c4a05d7e2a61 upstream.
3945 updated write_ptr without regard to read_ptr on the Tx path.
This messes up our TFD on high load and result in the following:
<1>[ 7290.414172] IP: [<
ffffffffa0dd53a1>] iwl3945_rx_reply_tx+0xc1/0x450 [iwl3945]
<4>[ 7290.414205] PGD 0
<1>[ 7290.414214] Thread overran stack, or stack corrupted
<0>[ 7290.414229] Oops: 0002 [#1] PREEMPT SMP
<0>[ 7290.414246] last sysfs file: /sys/devices/platform/coretemp.1/temp1_input
<4>[ 7290.414265] CPU 0
<4>[ 7290.414274] Modules linked in: af_packet nfsd usb_storage usb_libusual cpufreq_powersave exportfs cpufreq_conservative iwl3945 nfs cpufreq_userspace snd_hda_codec_realtek acpi_cpufreq uvcvideo lockd iwlcore snd_hda_intel joydev coretemp nfs_acl videodev snd_hda_codec mac80211 v4l1_compat snd_hwdep sbp2 v4l2_compat_ioctl32 uhci_hcd psmouse auth_rpcgss ohci1394 cfg80211 ehci_hcd video ieee1394 snd_pcm serio_raw battery ac nvidia(P) usbcore output sunrpc evdev lirc_ene0100 snd_page_alloc rfkill tg3 libphy fuse lzo lzo_decompress lzo_compress
<6>[ 7290.414486] Pid: 0, comm: swapper Tainted: P 2.6.32-rc8-wl #213 Aspire 5720
<6>[ 7290.414507] RIP: 0010:[<
ffffffffa0dd53a1>] [<
ffffffffa0dd53a1>] iwl3945_rx_reply_tx+0xc1/0x450 [iwl3945]
<6>[ 7290.414541] RSP: 0018:
ffff880002203d60 EFLAGS:
00010246
<6>[ 7290.414557] RAX:
000000000000004f RBX:
ffff880064c11600 RCX:
0000000000000013
<6>[ 7290.414576] RDX:
ffffffffa0ddcf20 RSI:
ffff8800512b7008 RDI:
0000000000000038
<6>[ 7290.414596] RBP:
ffff880002203dd0 R08:
0000000000000000 R09:
0000000000000100
<6>[ 7290.414616] R10:
0000000000000001 R11:
0000000000000000 R12:
00000000000000a0
<6>[ 7290.414635] R13:
0000000000000002 R14:
0000000000000013 R15:
0000000000020201
<6>[ 7290.414655] FS:
0000000000000000(0000) GS:
ffff880002200000(0000) knlGS:
0000000000000000
<6>[ 7290.414677] CS: 0010 DS: 0018 ES: 0018 CR0:
000000008005003b
<6>[ 7290.414693] CR2:
0000000000000041 CR3:
0000000001001000 CR4:
00000000000006f0
<6>[ 7290.414712] DR0:
0000000000000000 DR1:
0000000000000000 DR2:
0000000000000000
<6>[ 7290.414732] DR3:
0000000000000000 DR6:
00000000ffff0ff0 DR7:
0000000000000400
<4>[ 7290.414752] Process swapper (pid: 0, threadinfo
ffffffff81524000, task
ffffffff81528b60)
<0>[ 7290.414772] Stack:
<4>[ 7290.414780]
ffff880002203da0 0000000000000046 0000000000000000 0000000000000046
<4>[ 7290.414804] <0>
0000000000000282 0000000000000282 0000000000000282 ffff880064c12010
<4>[ 7290.414830] <0>
ffff880002203db0 ffff880064c11600 ffff880064c12e50 ffff8800512b7000
<0>[ 7290.414858] Call Trace:
<0>[ 7290.414867] <IRQ>
<4>[ 7290.414884] [<
ffffffffa0dc8c47>] iwl3945_irq_tasklet+0x657/0x1740 [iwl3945]
<4>[ 7290.414910] [<
ffffffff8138fc60>] ? _spin_unlock+0x30/0x60
<4>[ 7290.414931] [<
ffffffff81049a21>] tasklet_action+0x101/0x110
<4>[ 7290.414950] [<
ffffffff8104a3d0>] __do_softirq+0xc0/0x160
<4>[ 7290.414968] [<
ffffffff8100d01c>] call_softirq+0x1c/0x30
<4>[ 7290.414986] [<
ffffffff8100eff5>] do_softirq+0x75/0xb0
<4>[ 7290.415003] [<
ffffffff81049ee5>] irq_exit+0x95/0xa0
<4>[ 7290.415020] [<
ffffffff8100e547>] do_IRQ+0x77/0xf0
<4>[ 7290.415038] [<
ffffffff8100c7d3>] ret_from_intr+0x0/0xf
<0>[ 7290.415052] <EOI>
<4>[ 7290.415067] [<
ffffffff81234efa>] ? acpi_idle_enter_bm+0x270/0x2a5
<4>[ 7290.415087] [<
ffffffff81234f04>] ? acpi_idle_enter_bm+0x27a/0x2a5
<4>[ 7290.415107] [<
ffffffff81234efa>] ? acpi_idle_enter_bm+0x270/0x2a5
<4>[ 7290.415130] [<
ffffffff812c11f3>] ? cpuidle_idle_call+0x93/0xf0
<4>[ 7290.415149] [<
ffffffff8100b0d7>] ? cpu_idle+0xa7/0x110
<4>[ 7290.415168] [<
ffffffff8137b3d5>] ? rest_init+0x75/0x80
<4>[ 7290.415187] [<
ffffffff8158cd0a>] ? start_kernel+0x3a7/0x3b3
<4>[ 7290.415206] [<
ffffffff8158c315>] ? x86_64_start_reservations+0x125/0x129
<4>[ 7290.415227] [<
ffffffff8158c3fd>] ? x86_64_start_kernel+0xe4/0xeb
<0>[ 7290.415243] Code: 00 41 39 ce 0f 8d e8 01 00 00 48 8b 47 40 48 63 d2 48 69 d2 98 00 00 00 4c 8b 04 02 48 c7 c2 20 cf dd a0 49 8d 78 38 49 8d 40 4f <c6> 47 09 00 c6 47 0c 00 c6 47 0f 00 c6 47 12 00 c6 47 15 00 49
<1>[ 7290.415382] RIP [<
ffffffffa0dd53a1>] iwl3945_rx_reply_tx+0xc1/0x450 [iwl3945]
<4>[ 7290.415410] RSP <
ffff880002203d60>
<0>[ 7290.415421] CR2:
0000000000000041
<4>[ 7290.415436] ---[ end trace
ec46807277caa515 ]---
<0>[ 7290.415450] Kernel panic - not syncing: Fatal exception in interrupt
<4>[ 7290.415468] Pid: 0, comm: swapper Tainted: P D 2.6.32-rc8-wl #213
<4>[ 7290.415486] Call Trace:
<4>[ 7290.415495] <IRQ> [<
ffffffff8138c040>] panic+0x7d/0x13a
<4>[ 7290.415519] [<
ffffffff8101071a>] oops_end+0xda/0xe0
<4>[ 7290.415538] [<
ffffffff8102e1ea>] no_context+0xea/0x250
<4>[ 7290.415557] [<
ffffffff81038991>] ? select_task_rq_fair+0x511/0x780
<4>[ 7290.415578] [<
ffffffff8102e475>] __bad_area_nosemaphore+0x125/0x1e0
<4>[ 7290.415597] [<
ffffffff81038d0c>] ? __enqueue_entity+0x7c/0x80
<4>[ 7290.415616] [<
ffffffff81039201>] ? enqueue_task_fair+0x111/0x150
<4>[ 7290.415636] [<
ffffffff8102e53e>] bad_area_nosemaphore+0xe/0x10
<4>[ 7290.415656] [<
ffffffff8102e8fa>] do_page_fault+0x26a/0x320
<4>[ 7290.415674] [<
ffffffff813905df>] page_fault+0x1f/0x30
<4>[ 7290.415697] [<
ffffffffa0dd53a1>] ? iwl3945_rx_reply_tx+0xc1/0x450 [iwl3945]
<4>[ 7290.415723] [<
ffffffffa0dc8c47>] iwl3945_irq_tasklet+0x657/0x1740 [iwl3945]
<4>[ 7290.415746] [<
ffffffff8138fc60>] ? _spin_unlock+0x30/0x60
<4>[ 7290.415764] [<
ffffffff81049a21>] tasklet_action+0x101/0x110
<4>[ 7290.415783] [<
ffffffff8104a3d0>] __do_softirq+0xc0/0x160
<4>[ 7290.415801] [<
ffffffff8100d01c>] call_softirq+0x1c/0x30
<4>[ 7290.415818] [<
ffffffff8100eff5>] do_softirq+0x75/0xb0
<4>[ 7290.415835] [<
ffffffff81049ee5>] irq_exit+0x95/0xa0
<4>[ 7290.415852] [<
ffffffff8100e547>] do_IRQ+0x77/0xf0
<4>[ 7290.415869] [<
ffffffff8100c7d3>] ret_from_intr+0x0/0xf
<4>[ 7290.415883] <EOI> [<
ffffffff81234efa>] ? acpi_idle_enter_bm+0x270/0x2a5
<4>[ 7290.415911] [<
ffffffff81234f04>] ? acpi_idle_enter_bm+0x27a/0x2a5
<4>[ 7290.415931] [<
ffffffff81234efa>] ? acpi_idle_enter_bm+0x270/0x2a5
<4>[ 7290.415952] [<
ffffffff812c11f3>] ? cpuidle_idle_call+0x93/0xf0
<4>[ 7290.415971] [<
ffffffff8100b0d7>] ? cpu_idle+0xa7/0x110
<4>[ 7290.415989] [<
ffffffff8137b3d5>] ? rest_init+0x75/0x80
<4>[ 7290.416007] [<
ffffffff8158cd0a>] ? start_kernel+0x3a7/0x3b3
<4>[ 7290.416026] [<
ffffffff8158c315>] ? x86_64_start_reservations+0x125/0x129
<4>[ 7290.416047] [<
ffffffff8158c3fd>] ? x86_64_start_kernel+0xe4/0xeb
Reported-by: Maxim Levitsky <maximlevitsky@gmail.com>
Tested-by: Maxim Levitsky <maximlevitsky@gmail.com>
Signed-off-by: Zhu Yi <yi.zhu@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, 14 Dec 2009 22:12:10 +0000 (14:12 -0800)]
iwl3945: disable power save
commit
bc45a67079c916a9bd0a95b0b879cc0f259bac6e upstream.
we see from http://bugzilla.intellinuxwireless.org/show_bug.cgi?id=2125
that power saving does not work well on 3945. Since then power saving has
also been connected with association problems where an AP deathenticates a
3945 after it is unable to transmit data to it - this happens when 3945
enters power savings mode.
Disable power save support until issues are resolved.
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>
Vasanthakumar Thiagarajan [Fri, 13 Nov 2009 09:02:40 +0000 (14:32 +0530)]
ath9k_hw: Fix AR_GPIO_INPUT_EN_VAL_BT_PRIORITY_BB and its shift value in 0x4054
commit
c37919bfe0a5c1bee9a31701a31e05a2f8840936 upstream.
The bit value of AR_GPIO_INPUT_EN_VAL_BT_PRIORITY_BB is wrong, it should
be 0x400 and the number of bits to be right shifted is 10. Having this
wrong value in 0x4054 sometimes affects bt quality on btcoex environment.
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>
Vasanthakumar Thiagarajan [Fri, 13 Nov 2009 09:02:39 +0000 (14:32 +0530)]
ath9k_hw: Fix possible OOB array indexing in gen_timer_index[] on 64-bit
commit
c90017dd43f0cdb42134b9229761e8be02bcd524 upstream.
debruijn32 (0x077CB531) is used to index gen_timer_index[]
which is an array of 32 u32. Having debruijn32 as unsigned
long on a 64-bit platform will result in indexing more than 32
in gen_timer_index[] and there by causing a crash. Make it
unsigned to fix this issue.
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>
Sujith [Thu, 24 Dec 2009 01:03:27 +0000 (20:03 -0500)]
ath9k: fix suspend by waking device prior to stop
commit
3867cf6a8c699846e928e8f5a9f31013708df192 upstream.
Ensure the device is awake prior to trying to tell hardware
to stop it. Impact of not doing this is we can likely leave
the device in an undefined state likely causing issues with
suspend and resume. This patch ensures harware is where it
should be prior to suspend.
Signed-off-by: Sujith <Sujith.Manoharan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Luis R. Rodriguez [Thu, 24 Dec 2009 01:03:29 +0000 (20:03 -0500)]
ath9k: wake hardware during AMPDU TX actions
commit
8b685ba9de803f210936400612a32a2003f47cd3 upstream.
AMDPDU actions poke hardware for TX operation, as such
we want to turn hardware on for these actions. AMDPU RX operations
do not require hardware on as nothing is done in hardware for
those actions. Without this we cannot guarantee hardware has
been programmed correctly for each AMPDU TX action.
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>
Felix Fietkau [Thu, 24 Dec 2009 13:04:32 +0000 (14:04 +0100)]
ath9k: fix missed error codes in the tx status check
commit
5b479a076de091590423a9e6dfc2584126b28761 upstream.
My previous change added in:
commit
815833e7ecf0b9a017315cae6aef4d7cd9517681
ath9k: fix tx status reporting
was not checking all possible tx error conditions. This could possibly
lead to throughput issues due to slow rate control adaption or missed
retransmissions of failed A-MPDU frames.
This patch adds a mask for all possible error conditions and uses it
in the xmit ok check.
Reported-by: Björn Smedman <bjorn.smedman@venatech.se>
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>
Sujith [Mon, 14 Dec 2009 09:27:08 +0000 (14:57 +0530)]
ath9k: Fix TX queue draining
commit
e8009e9850d59000d518296af372888911a129bd upstream.
When TX DMA termination has failed, the HW has to be reset
completely. Doing a fast channel change in this case is insufficient.
Also, change the debug level of a couple of messages to FATAL.
Signed-off-by: Sujith <Sujith.Manoharan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Luis R. Rodriguez [Thu, 24 Dec 2009 01:03:28 +0000 (20:03 -0500)]
ath9k: wake hardware for interface IBSS/AP/Mesh removal
commit
5f70a88f631c3480107853cae12925185eb4c598 upstream.
When we remove a IBSS/AP/Mesh interface we stop DMA
but to do this we should ensure hardware is on. Awaken
the device prior to these calls. This should ensure
DMA is stopped upon suspend and plain device removal.
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>
Bob Copeland [Tue, 22 Dec 2009 03:26:48 +0000 (22:26 -0500)]
ath5k: fix SWI calibration interrupt storm
commit
242ab7ad689accafd5e87ffd22b85cf1bf7fbbef upstream.
The calibration period is now invoked by triggering a software
interrupt from within the ISR by ath5k_hw_calibration_poll()
instead of via a timer.
However, the calibration interval isn't initialized before
interrupts are enabled, so we can have a situation where an
interrupt occurs before the interval is assigned, so the
interval is actually negative. As a result, the ISR will
arm a software interrupt to schedule the tasklet, and then
rearm it when the SWI is processed, and so on, leading to a
softlockup at modprobe time.
Move the initialization order around so the calibration interval
is set before interrupts are active. Another possible fix
is to schedule the tasklet directly from the poll routine,
but I think there are additional plans for the SWI.
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>
Johannes Berg [Wed, 23 Dec 2009 12:12:05 +0000 (13:12 +0100)]
cfg80211: fix race between deauth and assoc response
commit
3bdb2d48c5f58c781a4099c99044384a23620884 upstream.
Joseph Nahmias reported, in http://bugs.debian.org/562016,
that he was getting the following warning (with some log
around the issue):
ath0: direct probe to AP 00:11:95:77:e0:b0 (try 1)
ath0: direct probe responded
ath0: authenticate with AP 00:11:95:77:e0:b0 (try 1)
ath0: authenticated
ath0: associate with AP 00:11:95:77:e0:b0 (try 1)
ath0: deauthenticating from 00:11:95:77:e0:b0 by local choice (reason=3)
ath0: direct probe to AP 00:11:95:77:e0:b0 (try 1)
ath0: RX AssocResp from 00:11:95:77:e0:b0 (capab=0x421 status=0 aid=2)
ath0: associated
------------[ cut here ]------------
WARNING: at net/wireless/mlme.c:97 cfg80211_send_rx_assoc+0x14d/0x152 [cfg80211]()
Hardware name: 7658CTO
...
Pid: 761, comm: phy0 Not tainted 2.6.32-trunk-686 #1
Call Trace:
[<
c1030a5d>] ? warn_slowpath_common+0x5e/0x8a
[<
c1030a93>] ? warn_slowpath_null+0xa/0xc
[<
f86cafc7>] ? cfg80211_send_rx_assoc+0x14d/0x152
...
ath0: link becomes ready
ath0: deauthenticating from 00:11:95:77:e0:b0 by local choice (reason=3)
ath0: no IPv6 routers present
ath0: link is not ready
ath0: direct probe to AP 00:11:95:77:e0:b0 (try 1)
ath0: direct probe responded
ath0: authenticate with AP 00:11:95:77:e0:b0 (try 1)
ath0: authenticated
ath0: associate with AP 00:11:95:77:e0:b0 (try 1)
ath0: RX ReassocResp from 00:11:95:77:e0:b0 (capab=0x421 status=0 aid=2)
ath0: associated
It is not clear to me how the first "direct probe" here
happens, but this seems to be a race condition, if the
user requests to deauth after requesting assoc, but before
the assoc response is received. In that case, it may
happen that mac80211 tries to report the assoc success to
cfg80211, but gets blocked on the wdev lock that is held
because the user is requesting the deauth.
The result is that we run into a warning. This is mostly
harmless, but maybe cause an unexpected event to be sent
to userspace; we'd send an assoc success event although
userspace was no longer expecting that.
To fix this, remove the warning and check whether the
race happened and in that case abort processing.
Reported-by: Joseph Nahmias <joe@nahmias.net>
Cc: 562016-quiet@bugs.debian.org
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Sujith [Mon, 2 Nov 2009 07:03:23 +0000 (12:33 +0530)]
mac80211: Fix IBSS merge
commit
450aae3d7b60a970f266349a837dfb30a539198b upstream.
Currently, in IBSS mode, a single creator would go into
a loop trying to merge/scan. This happens because the IBSS timer is
rearmed on finishing a scan and the subsequent
timer invocation requests another scan immediately.
This patch fixes this issue by checking if we have just completed
a scan run trying to merge with other IBSS networks.
Signed-off-by: Sujith <Sujith.Manoharan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Cc: Luis Rodriguez <lrodriguez@atheros.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Johannes Berg [Thu, 17 Dec 2009 15:16:53 +0000 (16:16 +0100)]
mac80211: fix WMM AP settings application
commit
0183826b58a2712ffe608bc3302447be3e6a3ab8 upstream.
My
commit
77fdaa12cea26c204cc12c312fe40bc0f3dcdfd8
Author: Johannes Berg <johannes@sipsolutions.net>
Date: Tue Jul 7 03:45:17 2009 +0200
mac80211: rework MLME for multiple authentications
inadvertedly broke WMM because it removed, along with
a bunch of other now useless initialisations, the line
initialising sdata->u.mgd.wmm_last_param_set to -1
which would make it adopt any WMM parameter set. If,
as is usually the case, the AP uses WMM parameter set
sequence number zero, we'd never update it until the
AP changes the sequence number.
Add the missing initialisation back to get the WMM
settings from the AP applied locally.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Luis R. Rodriguez [Thu, 24 Dec 2009 20:38:22 +0000 (15:38 -0500)]
mac80211: fix propagation of failed hardware reconfigurations
commit
24feda0084722189468a65e20019cdd8ef99702b upstream.
mac80211 does not propagate failed hardware reconfiguration
requests. For suspend and resume this is important due to all
the possible issues that can come out of the suspend <-> resume
cycle. Not propagating the error means cfg80211 will assume
the resume for the device went through fine and mac80211 will
continue on trying to poke at the hardware, enable timers,
queue work, and so on for a device which is completley
unfunctional.
The least we can do is to propagate device start issues and
warn when this occurs upon resume. A side effect of this patch
is we also now propagate the start errors upon harware
reconfigurations (non-suspend), but this should also be desirable
anyway, there is not point in continuing to reconfigure a
device if mac80211 was unable to start the device.
For further details refer to the thread:
http://marc.info/?t=
126151038700001&r=1&w=2
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>
Zhu Yi [Mon, 28 Dec 2009 06:23:11 +0000 (14:23 +0800)]
iwmc3200wifi: fix array out-of-boundary access
commit
6c853da3f30c93eae847ecbcd9fdf10ba0da04c2 upstream.
Allocate priv->rx_packets[IWM_RX_ID_HASH + 1] because the max array
index is IWM_RX_ID_HASH according to IWM_RX_ID_GET_HASH().
Signed-off-by: Zhu Yi <yi.zhu@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
projects / firefly-linux-kernel-4.4.55.git / log