24 Jun, 2011
40 commits
-
commit 51e65257142a87fe46a1ce5c35c86c5baf012614 upstream.
We use priv->mutex to avoid race conditions between chswitch_done()
and mac_channel_switch(), when marking channel switch in
progress. But chswitch_done() can be called in atomic context
from rx_csa() or with mutex already taken from commit_rxon().To fix remove mutex from chswitch_done() and use atomic bitops
for marking channel switch pending.Signed-off-by: Stanislaw Gruszka
Signed-off-by: John W. Linville
Signed-off-by: Greg Kroah-Hartman -
commit 6f213ff1919fab6f8244ceae55631b5d6ef750a7 upstream.
We use priv->mutex to avoid race conditions between iwl_chswitch_done()
and iwlagn_mac_channel_switch(), when marking channel switch in
progress. But iwl_chswitch_done() can be called in atomic context
from iwl_rx_csa() or with mutex already taken from iwlagn_commit_rxon().These bugs were introduced by:
commit 79d07325502e73508f917475bc1617b60979dd94
Author: Wey-Yi Guy
Date: Thu May 6 08:54:11 2010 -0700iwlwifi: support channel switch offload in driver
To fix remove mutex from iwl_chswitch_done() and use atomic bitops for
marking channel switch pending.Also remove iwl2030_hw_channel_switch() since 2000 series adapters are
2.4GHz only devices.Signed-off-by: Stanislaw Gruszka
Acked-by: Wey-Yi Guy
Signed-off-by: John W. Linville
Signed-off-by: Greg Kroah-Hartman -
commit 43e4e0b94984b45d52048e3ac027cac15c718b65 upstream.
During channge channel, tx power will not send to uCode, the tx power command
should send after scan complete. but should also can send after RXON command.Stable fix identified by Stanislaw Gruszka .
Signed-off-by: Wey-Yi Guy
Signed-off-by: John W. Linville
Signed-off-by: Greg Kroah-Hartman -
commit b062962edb086011e94ec4d9eb3f6a6d814f2a8f upstream.
Commit e9c7469bb4f5 ("md: implment REQ_FLUSH/FUA support")
introduced R5_WantFUA flag and set rw to WRITE_FUA in that case.
However remaining code still checks whether rw is exactly same
as WRITE or not, so FUAed-write ends up with being treated as
READ. Fix it.This bug has been present since 2.6.37 and the fix is suitable for any
-stable kernel since then. It is not clear why this has not caused
more problems.Cc: Tejun Heo
Signed-off-by: Namhyung Kim
Signed-off-by: NeilBrown
Signed-off-by: Greg Kroah-Hartman -
commit 9b2dc8b665932a8e681a7ab3237f60475e75e161 upstream.
The @bio->bi_phys_segments consists of active stripes count in the
lower 16 bits and processed stripes count in the upper 16 bits. So
logical-OR operator should be bitwise one.This bug has been present since 2.6.27 and the fix is suitable for any
-stable kernel since then. Fortunately the bad code is only used on
error paths and is relatively unlikely to be hit.Signed-off-by: Namhyung Kim
Signed-off-by: NeilBrown
Signed-off-by: Greg Kroah-Hartman -
commit 01393f3d5836b7d62e925e6f4658a7eb22b83a11 upstream.
Check pers->hot_remove_disk instead of pers->hot_add_disk in slot_store()
during disk removal. The linear personality only has ->hot_add_disk and
no ->hot_remove_disk, so that removing disk in the array resulted to
following kernel bug:$ sudo mdadm --create /dev/md0 --level=linear --raid-devices=4 /dev/loop[0-3]
$ echo none | sudo tee /sys/block/md0/md/dev-loop2/slot
BUG: unable to handle kernel NULL pointer dereference at (null)
IP: [< (null)>] (null)
PGD c9f5d067 PUD 8575a067 PMD 0
Oops: 0010 [#1] SMP
CPU 2
Modules linked in: linear loop bridge stp llc kvm_intel kvm asus_atk0110 sr_mod cdrom sgPid: 10450, comm: tee Not tainted 3.0.0-rc1-leonard+ #173 System manufacturer System Product Name/P5G41TD-M PRO
RIP: 0010:[] [< (null)>] (null)
RSP: 0018:ffff880085757df0 EFLAGS: 00010282
RAX: ffffffffa00168e0 RBX: ffff8800d1431800 RCX: 000000000000006e
RDX: 0000000000000001 RSI: 0000000000000002 RDI: ffff88008543c000
RBP: ffff880085757e48 R08: 0000000000000002 R09: 000000000000000a
R10: 0000000000000000 R11: ffff88008543c2e0 R12: 00000000ffffffff
R13: ffff8800b4641000 R14: 0000000000000005 R15: 0000000000000000
FS: 00007fe8c9e05700(0000) GS:ffff88011fa00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 0000000000000000 CR3: 00000000b4502000 CR4: 00000000000406e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process tee (pid: 10450, threadinfo ffff880085756000, task ffff8800c9f08000)
Stack:
ffffffff8138496a ffff8800b4641000 ffff88008543c268 0000000000000000
ffff8800b4641000 ffff88008543c000 ffff8800d1431868 ffffffff81a78a90
ffff8800b4641000 ffff88008543c000 ffff8800d1431800 ffff880085757e98
Call Trace:
[] ? slot_store+0xaa/0x265
[] rdev_attr_store+0x89/0xa8
[] sysfs_write_file+0x108/0x144
[] vfs_write+0xb1/0x10d
[] ? trace_hardirqs_on_caller+0x111/0x135
[] sys_write+0x4d/0x77
[] system_call_fastpath+0x16/0x1b
Code: Bad RIP value.
RIP [< (null)>] (null)
RSP
CR2: 0000000000000000
---[ end trace ba5fc64319a826fb ]---Signed-off-by: Namhyung Kim
Signed-off-by: NeilBrown
Signed-off-by: Greg Kroah-Hartman -
commit 4e78c724d47e2342aa8fde61f6b8536f662f795f upstream.
In tomoyo_mount_acl() since 2.6.36, kern_path() was called without checking
dev_name != NULL. As a result, an unprivileged user can trigger oops by issuing
mount(NULL, "/", "ext3", 0, NULL) request.
Fix this by checking dev_name != NULL before calling kern_path(dev_name).Signed-off-by: Tetsuo Handa
Signed-off-by: James Morris
Signed-off-by: Greg Kroah-Hartman -
commit 13f067537f34456443f61c950cd6dc37d1d5f3ee upstream.
cpufreq_stats leaves behind its sysfs entries, which causes a panic
when something stumbled across them.
(Discovered by unloading cpufreq_stats while powertop was loaded).Signed-off-by: Dave Jones
Signed-off-by: Greg Kroah-Hartman -
commit fd8a7de177b6f56a0fc59ad211c197a7df06b1ad upstream.
After a newly plugged CPU sets the cpu_online bit it enables
interrupts and goes idle. The cpu which brought up the new cpu waits
for the cpu_online bit and when it observes it, it sets the cpu_active
bit for this cpu. The cpu_active bit is the relevant one for the
scheduler to consider the cpu as a viable target.With forced threaded interrupt handlers which imply forced threaded
softirqs we observed the following race:cpu 0 cpu 1
bringup(cpu1);
set_cpu_online(smp_processor_id(), true);
local_irq_enable();
while (!cpu_online(cpu1));
timer_interrupt()
-> wake_up(softirq_thread_cpu1);
-> enqueue_on(softirq_thread_cpu1, cpu0);^^^^
cpu_notify(CPU_ONLINE, cpu1);
-> sched_cpu_active(cpu1)
-> set_cpu_active((cpu1, true);When an interrupt happens before the cpu_active bit is set by the cpu
which brought up the newly onlined cpu, then the scheduler refuses to
enqueue the woken thread which is bound to that newly onlined cpu on
that newly onlined cpu due to the not yet set cpu_active bit and
selects a fallback runqueue. Not really an expected and desirable
behaviour.So far this has only been observed with forced hard/softirq threading,
but in theory this could happen without forced threaded hard/softirqs
as well. It's probably unobservable as it would take a massive
interrupt storm on the newly onlined cpu which causes the softirq loop
to wake up the softirq thread and an even longer delay of the cpu
which waits for the cpu_online bit.Signed-off-by: Thomas Gleixner
Reviewed-by: Peter Zijlstra
Signed-off-by: Greg Kroah-Hartman -
commit 977cb76d52e7aa040e18a84b29fe6fd80d79319b upstream.
This patch fixes the following build failure:
drivers/built-in.o: In function `early_init_dt_check_for_initrd':
/home/florian/dev/kernel/x86/linux-2.6-x86/drivers/of/fdt.c:571:
undefined reference to `early_init_dt_setup_initrd_arch'
make: *** [.tmp_vmlinux1] Error 1which happens as soon as we enable initrd support on a x86 devicetree
platform such as Intel CE4100.Signed-off-by: Florian Fainelli
Acked-by: Grant Likely
Cc: Maxime Bizon
Acked-by: Sebastian Andrzej Siewior
Link: http://lkml.kernel.org/r/201106061015.50039.ffainelli@freebox.fr
Signed-off-by: Thomas Gleixner
Signed-off-by: Greg Kroah-Hartman -
commit f3209bea110cade12e2b133da8b8499689cb0e2e upstream.
Ignacy reports that sometimes after leaving an IBSS
joining a new one didn't work because there still
were stations on the list. He fixed it by flushing
stations when attempting to join a new IBSS, but
this shouldn't be happening in the first case. When
I looked into it I saw a race condition in teardown
that could cause stations to be added after flush,
and thus cause this situation. Ignacy confirms that
after applying my patch he hasn't seen this happen
again.Reported-by: Ignacy Gawedzki
Debugged-by: Ignacy Gawedzki
Tested-by: Ignacy Gawedzki
Signed-off-by: Johannes Berg
Signed-off-by: John W. Linville
Signed-off-by: Greg Kroah-Hartman -
commit 665c8c8ee405738375b679246b49342ce38ba056 upstream.
When SR-IOV is enabled, i350 devices fail to pass traffic. This is due to
the driver attempting to enable RSS on the PF device, which is not
supported by the i350.When max_vfs is specified on an i350 adapter, set the number of RSS queues
to 1.This issue affects 2.6.39 as well.
Signed-off-by: Mitch Williams
Tested-by: Jeff Pieper
Signed-off-by: Jeff Kirsher
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman -
commit 51892dbbd511911c0f965a36b431fc3e8f1e4f8a upstream.
Setting tx power can be deferred during scan or changing channel.
If after that correct tx power settings will not be sent to device,
we can observe transmission problems and timeouts. Force to send
tx power settings also after partial rxon change, to assure device
always be configured with up-to-date settings.Resolves:
https://bugzilla.kernel.org/show_bug.cgi?id=36492Signed-off-by: Stanislaw Gruszka
Signed-off-by: John W. Linville
Signed-off-by: Greg Kroah-Hartman -
commit 42b70a5f6d18165a075d189d1bee82fad7cdbf29 upstream.
This patch fixes 802.11n stability and performance regression we have
since 2.6.35. It boost performance on my 5GHz N-only network from about
5MB/s to 8MB/s. Similar percentage boost can be observed on 2.4 GHz.These are test results of 5x downloading of approximately 700MB iso
image:vanilla: 5.27 5.22 4.94 4.47 5.31 ; avr 5.0420 std 0.35110
patched: 8.07 7.95 8.06 7.99 7.96 ; avr 8.0060 std 0.055946This was achieved with NetworkManager configured to do not perform
periodical scans, by configuring constant BSSID. With periodical scans,
after some time, performance downgrade to unpatched driver level, like
in example below:patched: 7.40 7.61 4.28 4.37 4.80 avr 5.6920 std 1.6683
However patch still make better here, since similar test on unpatched
driver make link disconnects with below messages after some time:wlan1: authenticate with 00:23:69:35:d1:3f (try 1)
wlan1: authenticate with 00:23:69:35:d1:3f (try 2)
wlan1: authenticate with 00:23:69:35:d1:3f (try 3)
wlan1: authentication with 00:23:69:35:d1:3f timed outOn 2.6.35 kernel patch helps against connection hangs with messages:
iwlagn 0000:20:00.0: queue 10 stuck 3 time. Fw reload.
iwlagn 0000:20:00.0: On demand firmware reload
iwlagn 0000:20:00.0: Stopping AGG while state not ON or startingSigned-off-by: Stanislaw Gruszka
Acked-by: Wey-Yi Guy
Signed-off-by: John W. Linville
Signed-off-by: Greg Kroah-Hartman -
commit a27bb4b209dd6c327fa4e7185f2487f9508a58db upstream.
To my knowledge, the limit is 16 on r300.
(the docs don't say what the limit is)The lack of bounds checking can be abused to do all sorts of things
(from bypassing parts of the CS checker to crashing the kernel).Bugzilla:
https://bugs.freedesktop.org/show_bug.cgi?id=36745Signed-off-by: Marek Olšák
Signed-off-by: Dave Airlie
Signed-off-by: Greg Kroah-Hartman -
commit fe47ae7f53e179d2ef6771024feb000cbb86640f upstream.
The lockdep warning below detects a possible A->B/B->A locking
dependency of mm->mmap_sem and dcookie_mutex. The order in
sync_buffer() is mm->mmap_sem/dcookie_mutex, while in
sys_lookup_dcookie() it is vice versa.Fixing it in sys_lookup_dcookie() by unlocking dcookie_mutex before
copy_to_user().oprofiled/4432 is trying to acquire lock:
(&mm->mmap_sem){++++++}, at: [] might_fault+0x53/0xa3but task is already holding lock:
(dcookie_mutex){+.+.+.}, at: [] sys_lookup_dcookie+0x45/0x149which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 (dcookie_mutex){+.+.+.}:
[] lock_acquire+0xf8/0x11e
[] mutex_lock_nested+0x63/0x309
[] get_dcookie+0x30/0x144
[] sync_buffer+0x196/0x3ec [oprofile]
[] task_exit_notify+0x16/0x1a [oprofile]
[] notifier_call_chain+0x37/0x63
[] __blocking_notifier_call_chain+0x50/0x67
[] blocking_notifier_call_chain+0x14/0x16
[] profile_task_exit+0x1a/0x1c
[] do_exit+0x2a/0x6fc
[] do_group_exit+0x83/0xae
[] sys_exit_group+0x17/0x1b
[] system_call_fastpath+0x16/0x1b-> #0 (&mm->mmap_sem){++++++}:
[] __lock_acquire+0x1085/0x1711
[] lock_acquire+0xf8/0x11e
[] might_fault+0x80/0xa3
[] sys_lookup_dcookie+0x104/0x149
[] system_call_fastpath+0x16/0x1bother info that might help us debug this:
1 lock held by oprofiled/4432:
#0: (dcookie_mutex){+.+.+.}, at: [] sys_lookup_dcookie+0x45/0x149stack backtrace:
Pid: 4432, comm: oprofiled Not tainted 2.6.39-00008-ge5a450d #9
Call Trace:
[] print_circular_bug+0xae/0xbc
[] __lock_acquire+0x1085/0x1711
[] ? get_parent_ip+0x11/0x42
[] ? might_fault+0x53/0xa3
[] lock_acquire+0xf8/0x11e
[] ? might_fault+0x53/0xa3
[] ? path_put+0x22/0x27
[] might_fault+0x80/0xa3
[] ? might_fault+0x53/0xa3
[] sys_lookup_dcookie+0x104/0x149
[] system_call_fastpath+0x16/0x1bReferences: https://bugzilla.kernel.org/show_bug.cgi?id=13809
Signed-off-by: Robert Richter
Signed-off-by: Greg Kroah-Hartman -
commit 130c5ce716c9bfd1c2a2ec840a746eb7ff9ce1e6 upstream.
This fixes the A->B/B->A locking dependency, see the warning below.
The function task_exit_notify() is called with (task_exit_notifier)
.rwsem set and then calls sync_buffer() which locks buffer_mutex. In
sync_start() the buffer_mutex was set to prevent notifier functions to
be started before sync_start() is finished. But when registering the
notifier, (task_exit_notifier).rwsem is locked too, but now in
different order than in sync_buffer(). In theory this causes a locking
dependency, what does not occur in practice since task_exit_notify()
is always called after the notifier is registered which means the lock
is already released.However, after checking the notifier functions it turned out the
buffer_mutex in sync_start() is unnecessary. This is because
sync_buffer() may be called from the notifiers even if sync_start()
did not finish yet, the buffers are already allocated but empty. No
need to protect this with the mutex.So we fix this theoretical locking dependency by removing buffer_mutex
in sync_start(). This is similar to the implementation before commit:750d857 oprofile: fix crash when accessing freed task structs
which introduced the locking dependency.
Lockdep warning:
oprofiled/4447 is trying to acquire lock:
(buffer_mutex){+.+...}, at: [] sync_buffer+0x31/0x3ec [oprofile]but task is already holding lock:
((task_exit_notifier).rwsem){++++..}, at: [] __blocking_notifier_call_chain+0x39/0x67which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 ((task_exit_notifier).rwsem){++++..}:
[] lock_acquire+0xf8/0x11e
[] down_write+0x44/0x67
[] blocking_notifier_chain_register+0x52/0x8b
[] profile_event_register+0x2d/0x2f
[] sync_start+0x47/0xc6 [oprofile]
[] oprofile_setup+0x60/0xa5 [oprofile]
[] event_buffer_open+0x59/0x8c [oprofile]
[] __dentry_open+0x1eb/0x308
[] nameidata_to_filp+0x60/0x67
[] do_last+0x5be/0x6b2
[] path_openat+0xc7/0x360
[] do_filp_open+0x3d/0x8c
[] do_sys_open+0x110/0x1a9
[] sys_open+0x20/0x22
[] system_call_fastpath+0x16/0x1b-> #0 (buffer_mutex){+.+...}:
[] __lock_acquire+0x1085/0x1711
[] lock_acquire+0xf8/0x11e
[] mutex_lock_nested+0x63/0x309
[] sync_buffer+0x31/0x3ec [oprofile]
[] task_exit_notify+0x16/0x1a [oprofile]
[] notifier_call_chain+0x37/0x63
[] __blocking_notifier_call_chain+0x50/0x67
[] blocking_notifier_call_chain+0x14/0x16
[] profile_task_exit+0x1a/0x1c
[] do_exit+0x2a/0x6fc
[] do_group_exit+0x83/0xae
[] sys_exit_group+0x17/0x1b
[] system_call_fastpath+0x16/0x1bother info that might help us debug this:
1 lock held by oprofiled/4447:
#0: ((task_exit_notifier).rwsem){++++..}, at: [] __blocking_notifier_call_chain+0x39/0x67stack backtrace:
Pid: 4447, comm: oprofiled Not tainted 2.6.39-00007-gcf4d8d4 #10
Call Trace:
[] print_circular_bug+0xae/0xbc
[] __lock_acquire+0x1085/0x1711
[] ? sync_buffer+0x31/0x3ec [oprofile]
[] lock_acquire+0xf8/0x11e
[] ? sync_buffer+0x31/0x3ec [oprofile]
[] ? mark_lock+0x42f/0x552
[] ? sync_buffer+0x31/0x3ec [oprofile]
[] mutex_lock_nested+0x63/0x309
[] ? sync_buffer+0x31/0x3ec [oprofile]
[] sync_buffer+0x31/0x3ec [oprofile]
[] ? __blocking_notifier_call_chain+0x39/0x67
[] ? __blocking_notifier_call_chain+0x39/0x67
[] task_exit_notify+0x16/0x1a [oprofile]
[] notifier_call_chain+0x37/0x63
[] __blocking_notifier_call_chain+0x50/0x67
[] blocking_notifier_call_chain+0x14/0x16
[] profile_task_exit+0x1a/0x1c
[] do_exit+0x2a/0x6fc
[] ? retint_swapgs+0xe/0x13
[] do_group_exit+0x83/0xae
[] sys_exit_group+0x17/0x1b
[] system_call_fastpath+0x16/0x1bReported-by: Marcin Slusarz
Cc: Carl Love
Signed-off-by: Robert Richter
Signed-off-by: Greg Kroah-Hartman -
commit 6ac6519b93065625119a347be1cbcc1b89edb773 upstream.
After registering the task free notifier we possibly have tasks in our
dying_tasks list. Free them after unregistering the notifier in case
of an error.Signed-off-by: Robert Richter
Signed-off-by: Greg Kroah-Hartman -
commit 0a1896b27b030529ec770aefd790544a1bdb7d5a upstream.
BugLink: https://launchpad.net/bugs/792712
The original reporter states that sound from the internal speakers is
inaudible until using the model=auto quirk. This symptom is due to an
existing quirk mask for 0x102802b* that uses the model=dell quirk. To
limit the possible regressions, leave the existing quirk mask but add
a higher priority specific mask for the reporter's PCI SSID.Reported-and-tested-by: rodni hipp
Signed-off-by: Daniel T Chen
Signed-off-by: Takashi Iwai
Signed-off-by: Greg Kroah-Hartman -
commit 33195500edf260e8c8809ab9dfc67f50e0ce031f upstream.
If DMA active status should be checked, I2SCON register should be referenced.
In this patch, Fix the incorrect referencing of I2SCON register.Reported-by : Lakkyung Jung
Signed-off-by: Sangbeom Kim
Acked-by: Jassi Brar
Acked-by: Liam Girdwood
Signed-off-by: Mark Brown
Signed-off-by: Greg Kroah-Hartman -
commit 4b80b8c2eee5282dab57f094fd3893c0c09f750c upstream.
Currently it is possible that snd_soc_new_{mixer,mux,pga} is called with a
DAPM context not matching the widgets context. This can lead to a wrong
prefix_len calculation, which will result in undefined behaviour. To avoid
this always use the DAPM context from the widget itself.Signed-off-by: Lars-Peter Clausen
Acked-by: Liam Girdwood
Signed-off-by: Mark Brown
Signed-off-by: Greg Kroah-Hartman -
commit 3115ae174620eeab4b16f52c8d0a9a35d2717e3c upstream.
Reported-by: Kieran O'Leary
Signed-off-by: Mark Brown
Acked-by: Liam Girdwood
Signed-off-by: Greg Kroah-Hartman -
commit 0f82bdf572fc6e42147151aa4d52542f7fc6d793 upstream.
Signed-off-by: Mark Brown
Acked-by: Liam Girdwood
Signed-off-by: Greg Kroah-Hartman -
commit 8ca695f273709a9d147826716a8dee3e0eb2407f upstream.
Signed-off-by: Lars-Peter Clausen
Acked-by: Liam Girdwood
Signed-off-by: Mark Brown
Signed-off-by: Greg Kroah-Hartman -
commit 7fdbaa1b8daa1009b705985b903e3d2ebccad456 upstream.
It's possible for the following set of events to happen:
cifsd calls cifs_reconnect which reconnects the socket. A userspace
process then calls cifs_negotiate_protocol to handle the NEGOTIATE and
gets a reply. But, while processing the reply, cifsd calls
cifs_reconnect again. Eventually the GlobalMid_Lock is dropped and the
reply from the earlier NEGOTIATE completes and the tcpStatus is set to
CifsGood. cifs_reconnect then goes through and closes the socket and sets the
pointer to zero, but because the status is now CifsGood, the new socket
is not created and cifs_reconnect exits with the socket pointer set to
NULL.Fix this by only setting the tcpStatus to CifsGood if the tcpStatus is
CifsNeedNegotiate, and by making sure that generic_ip_connect is always
called at least once in cifs_reconnect.Note that this is not a perfect fix for this issue. It's still possible
that the NEGOTIATE reply is handled after the socket has been closed and
reconnected. In that case, the socket state will look correct but it no
NEGOTIATE was performed on it be for the wrong socket. In that situation
though the server should just shut down the socket on the next attempted
send, rather than causing the oops that occurs today.Reported-and-Tested-by: Ben Greear
Signed-off-by: Jeff Layton
Signed-off-by: Steve French
Signed-off-by: Greg Kroah-Hartman -
commit 1780f2d3839a0d3eb85ee014a708f9e2c8f8ba0e upstream.
Affected kernels 2.6.36 - 3.0
AppArmor may do a GFP_KERNEL memory allocation with task_lock(tsk->group_leader);
held when called from security_task_setrlimit. This will only occur when the
task's current policy has been replaced, and the task's creds have not been
updated before entering the LSM security_task_setrlimit() hook.BUG: sleeping function called from invalid context at mm/slub.c:847
in_atomic(): 1, irqs_disabled(): 0, pid: 1583, name: cupsd
2 locks held by cupsd/1583:
#0: (tasklist_lock){.+.+.+}, at: [] do_prlimit+0x61/0x189
#1: (&(&p->alloc_lock)->rlock){+.+.+.}, at: []
do_prlimit+0x94/0x189
Pid: 1583, comm: cupsd Not tainted 3.0.0-rc2-git1 #7
Call Trace:
[] __might_sleep+0x10d/0x112
[] slab_pre_alloc_hook.isra.49+0x2d/0x33
[] kmem_cache_alloc+0x22/0x132
[] prepare_creds+0x35/0xe4
[] aa_replace_current_profile+0x35/0xb2
[] aa_current_profile+0x45/0x4c
[] apparmor_task_setrlimit+0x19/0x3a
[] security_task_setrlimit+0x11/0x13
[] do_prlimit+0xd2/0x189
[] sys_setrlimit+0x3b/0x48
[] system_call_fastpath+0x16/0x1bSigned-off-by: John Johansen
Reported-by: Miles Lane
Signed-off-by: James Morris
Signed-off-by: Greg Kroah-Hartman -
commit cd3c18ba2fac14b34d03cae111f215009735ea06 upstream.
Full-speed isoc endpoints specify interval in exponent based form in
frames, not microframes, so we need to adjust accordingly.NEC xHCI host controllers will return an error code of 0x11 if a full
speed isochronous endpoint is added with the Interval field set to
something less than 3 (2^3 = 8 microframes, or one frame). It is
impossible for a full speed device to have an interval smaller than one
frame.This was always an issue in the xHCI driver, but commit
dfa49c4ad120a784ef1ff0717168aa79f55a483a "USB: xhci - fix math in
xhci_get_endpoint_interval()" removed the clamping of the minimum value
in the Interval field, which revealed this bug.This needs to be backported to stable kernels back to 2.6.31.
Reported-by: Matt Evans
Signed-off-by: Dmitry Torokhov
Signed-off-by: Sarah Sharp
Signed-off-by: Greg Kroah-Hartman -
commit f5182b4155b9d686c5540a6822486400e34ddd98 upstream.
Some Fresco Logic hosts, including those found in the AUAU N533V laptop,
advertise MSI, but fail to actually generate MSI interrupts. Add a new
xHCI quirk to skip MSI enabling for the Fresco Logic host controllers.
Fresco Logic confirms that all chips with PCI vendor ID 0x1b73 and device
ID 0x1000, regardless of PCI revision ID, do not support MSI.This should be backported to stable kernels as far back as 2.6.36, which
was the first kernel to support MSI on xHCI hosts.Signed-off-by: Sarah Sharp
Reported-by: Sergey Galanov
Signed-off-by: Greg Kroah-Hartman -
commit 001fd3826f4c736ce292315782d015f768399080 upstream.
xHCI controllers respond to a Reset Device command when the Slot is in the
Enabled/Disabled state by returning an error. This is fine on other host
controllers, but the Etron xHCI host controller returns a vendor-specific
error code that the xHCI driver doesn't understand. The xHCI driver then
gives up on device enumeration.Instead of issuing a command that will fail, just return. This fixes the
issue with the xhci driver not working on ASRock P67 Pro/Extreme boards.This should be backported to stable kernels as far back as 2.6.34.
Signed-off-by: Maarten Lankhorst
Signed-off-by: Sarah Sharp
Signed-off-by: Greg Kroah-Hartman -
commit e2b0217715c6d10379d94bdfe5560af96eecbb7c upstream.
This needs to be added to the stable trees back to 2.6.34 to support an
upcoming bug fix.Signed-off-by: Maarten Lankhorst
Signed-off-by: Sarah Sharp
Signed-off-by: Greg Kroah-Hartman -
This reverts commit 0aed459e8487eb6ebdb4efe8cefe1eafbc704b30, which was
commit 916f676f8dc016103f983c7ec54c18ecdbb6e349 upstream.It breaks some people's machines, so this will all get worked out in the
3.0 kernel release, it's not quite ready for 2.6.39 just yet.Thanks to Maarten Lankhorst for reporting the
issue.Cc: Maarten Lankhorst
Cc: Jim Bos
Cc: Matthew Garrett
Cc: H. Peter Anvin
Cc: Tony Luck
Cc: Yinghai Lu
Signed-off-by: Greg Kroah-Hartman -
commit 21c13a4f7bc185552c4b402b792c3bbb9aa69df0 upstream.
Some USB mass-storage devices have bugs that cause them not to handle
the first READ(10) command they receive correctly. The Corsair
Padlock v2 returns completely bogus data for its first read (possibly
it returns the data in encrypted form even though the device is
supposed to be unlocked). The Feiya SD/SDHC card reader fails to
complete the first READ(10) command after it is plugged in or after a
new card is inserted, returning a status code that indicates it thinks
the command was invalid, which prevents the kernel from retrying the
read.Since the first read of a new device or a new medium is for the
partition sector, the kernel is unable to retrieve the device's
partition table. Users have to manually issue an "hdparm -z" or
"blockdev --rereadpt" command before they can access the device.This patch (as1470) works around the problem. It adds a new quirk
flag, US_FL_INVALID_READ10, indicating that the first READ(10) should
always be retried immediately, as should any failing READ(10) commands
(provided the preceding READ(10) command succeeded, to avoid getting
stuck in a loop). The patch also adds appropriate unusual_devs
entries containing the new flag.Signed-off-by: Alan Stern
Tested-by: Sven Geggus
Tested-by: Paul Hartman
CC: Matthew Dharm
Signed-off-by: Greg Kroah-Hartman -
commit a26d31cef06f43a76327c21235e75450869df2b8 upstream.
E.g. newer CAN 2.0 A/B USB 2.0 converters report idProduct=f3c2.
Signed-off-by: Steffen Sledz
Signed-off-by: Greg Kroah-Hartman -
commit 3824c1ddaf744be44b170a335332b9d6afe79254 upstream.
Protocol stall should not be fatal while reading port or hub status as it is
transient state. Currently hub EP0 STALL during port status read results in
failed device enumeration. This has been observed with ST-Ericsson (formerly
Philips) USB 2.0 Hub (04cc:1521) after connecting keyboard.Signed-off-by: Libor Pechacek
Acked-by: Alan Stern
Signed-off-by: Greg Kroah-Hartman -
commit 3095ec895fd5ec19a7cb60b5cbfa766d68a74a24 upstream.
This reverts commit a559d2c8c1bf652ea2d0ecd6ab4a250fcdb37db8.
Turns out that device id 0x1d6b:0x0002 is a USB hub, which causes havoc
when the option driver tries to bind to it.So revert this as it doesn't seem to be needed at all.
Thanks to Michael Tokarev and Paweł Drobek for working on resolving this
issue.Cc: Paweł Drobek
Cc: Michael Tokarev
Cc: Dominik Brodowski
Signed-off-by: Greg Kroah-Hartman -
commit 7e8e62e4a5d26e4cb45f25dddd093837d75616c2 upstream.
The funtion option_send_status times out when sending USB messages
to the interfaces 0, 1, and 2 of this UMTS stick. This results in a
5s timeout in the function causing other tty operations to feel very
sluggish.This patch adds a blacklist entry for these 3 interfaces on the ZTE
K3765-Z device.I was also able to reproduce the problem with v2.6.38 and v2.6.39.
This is very similar to a problem fixed in
commit 7a89e4cb9cdaba92f5fbc509945cf4e3c48db4e2
Author: Herton Ronaldo Krzesinski
Date: Wed Mar 9 09:19:48 2011 +0000USB: serial: option: Apply OPTION_BLACKLIST_SENDSETUP also for ZTE MF626
Signed-off-by: Torsten Hilbrich
Signed-off-by: Greg Kroah-Hartman -
commit 5c3e4076ee8253c1e3688d10653ddee47a03b0db upstream.
Simple ID addition.
Signed-off-by: Dan Williams
Signed-off-by: Greg Kroah-Hartman -
commit 15badbcc8eede58b0d7e53a3acde1c90a7b6e40e upstream.
This modem really wants sendsetup blacklisted for interfaces 0 and 1,
otherwise the kernel hardlocks for about 10 seconds while waiting for
the modem's firmware to respond, which it of course doesn't do.A slight complication here is that TCT (who owns the Alcatel brand) used
the same USB IDs for the X200 as the X060s despite the devices having
completely different firmware and AT command sets, so we end up adding
the X060s to the blacklist at the same time. PSA to OEMs: don't use the
same USB IDs for different devices. Really. It makes your kittens cry.Signed-off-by: Dan Williams
Signed-off-by: Greg Kroah-Hartman -
commit cdacb598fe7ab85de80908c818dd7d66a2971117 upstream.
Uses Longcheer-based firmware and AT command set.
Signed-off-by: Dan Williams
Signed-off-by: Greg Kroah-Hartman
