Dmitry Mishin [Fri, 17 Nov 2006 16:53:07 +0000 (17:53 +0100)]
Fix timer race in dst GC code
Replace add_timer() by mod_timer() in dst_run_gc
in order to avoid BUG message.
CPU1 CPU2
dst_run_gc() entered dst_run_gc() entered
spin_lock(&dst_lock) .....
del_timer(&dst_gc_timer) fail to get lock
.... mod_timer() <--- puts
timer back
to the list
add_timer(&dst_gc_timer) <--- BUG because timer is in list already.
Found during OpenVZ internal testing.
At first we thought that it is OpenVZ specific as we
added dst_run_gc(0) call in dst_dev_event(),
but as Alexey pointed to me it is possible to trigger
this condition in mainstream kernel.
F.e. timer has fired on CPU2, but the handler was preeempted
by an irq before dst_lock is tried.
Meanwhile, someone on CPU1 adds an entry to gc list and
starts the timer.
If CPU2 was preempted long enough, this timer can expire
simultaneously with resuming timer handler on CPU1, arriving
exactly to the situation described.
Badari Pulavarty [Fri, 17 Nov 2006 16:47:22 +0000 (17:47 +0100)]
ext3 -nobh option causes oops
For files other than IFREG, nobh option doesn't make sense. Modifications
to them are journalled and needs buffer heads to do that. Without this
patch, we get kernel oops in page_buffers().
Signed-off-by: Badari Pulavarty <pbadari@us.ibm.com> Signed-off-by: Adrian Bunk <bunk@stusta.de>
Paul Fulghum [Thu, 16 Nov 2006 23:13:41 +0000 (00:13 +0100)]
synclink_gt fix receive tty error handling
Fix receive tty error handling in synclink_gt driver.
Adrian reported compiler warning for incorrect bit test
against char variable. I determined these and other
device specific error bits were incorrectly defined.
Signed-off-by: Paul Fulghum <paulkf@microgate.com> Signed-off-by: Adrian Bunk <bunk@stusta.de>
Daniel Ritz [Wed, 15 Nov 2006 16:07:33 +0000 (17:07 +0100)]
fix via586 irq routing for pirq 5
fix interrput routing for via 586 bridges. pirq can be 5 which needs to be
mapped to INTD. but currently the access functions can handle only pirq 1-4.
this is similar to the other via chipsets where pirq 4 and 5 are both mapped
to INTD. fixes bugzilla #7490
Signed-off-by: Daniel Ritz <daniel.ritz@gmx.ch> Signed-off-by: Adrian Bunk <bunk@stusta.de>
Bob Moore [Wed, 15 Nov 2006 15:20:37 +0000 (16:20 +0100)]
Reduce ACPI verbosity on null handle condition
As detailed at http://bugs.gentoo.org/131534 :
2.6.16 converted many ACPI debug messages into error or warning
messages. One extraneous message was incorrectly converted, resulting in
logs being flooded by "Handle is NULL and Pathname is relative" messages
on some systems.
This patch (part of a larger ACPICA commit) converts the message back to
debug level.
Signed-off-by: Daniel Drake <dsd@gentoo.org> Signed-off-by: Adrian Bunk <bunk@stusta.de>
Fix longstanding load balancing bug in the scheduler
The scheduler will stop load balancing if the most busy processor contains
processes pinned via processor affinity.
The scheduler currently only does one search for busiest cpu. If it cannot
pull any tasks away from the busiest cpu because they were pinned then the
scheduler goes into a corner and sulks leaving the idle processors idle.
F.e. If you have processor 0 busy running four tasks pinned via taskset,
there are none on processor 1 and one just started two processes on
processor 2 then the scheduler will not move one of the two processes away
from processor 2.
This patch fixes that issue by forcing the scheduler to come out of its
corner and retrying the load balancing by considering other processors for
load balancing.
This patch was originally developed by John Hawkes and discussed at
I have removed extraneous material and gone back to equipping struct rq
with the cpu the queue is associated with since this makes the patch much
easier and it is likely that others in the future will have the same
difficulty of figuring out which processor owns which runqueue.
The overhead added through these patches is a single word on the stack if
the kernel is configured to support 32 cpus or less (32 bit). For 32 bit
environments the maximum number of cpus that can be configued is 255 which
would result in the use of 32 bytes additional on the stack. On IA64 up to
1k cpus can be configured which will result in the use of 128 additional
bytes on the stack. The maximum additional cache footprint is one
cacheline. Typically memory use will be much less than a cacheline and the
additional cpumask will be placed on the stack in a cacheline that already
contains other local variable.
Signed-off-by: Christoph Lameter <clameter@sgi.com> Signed-off-by: Adrian Bunk <bunk@stusta.de>
Paul Mackerras [Fri, 10 Nov 2006 23:28:30 +0000 (00:28 +0100)]
nvidia fbdev: fix powerpc xmon scribbles
xmon writes garbage on the screen because the nvidia console driver has
changed the line pitch from what the firmware set it to. Fix it by making
the nvidia driver inform the btext engine (which xmon uses if the screen is
its output device) about changes to display resolution.
Signed-off-by: Paul Mackerras <paulus@samba.org> Signed-off-by: Adrian Bunk <bunk@stusta.de>
Paul Mackerras [Fri, 10 Nov 2006 23:17:57 +0000 (00:17 +0100)]
[POWERPC] Fix return value from memcpy
As pointed out by Herbert Xu <herbert@gondor.apana.org.au>, our
memcpy implementation didn't return the destination pointer as its
return value, and there is code in the kernel that expects that.
This fixes it.
Signed-off-by: Paul Mackerras <paulus@samba.org> Signed-off-by: Adrian Bunk <bunk@stusta.de>
Herbert Xu [Fri, 10 Nov 2006 23:15:10 +0000 (00:15 +0100)]
[NET]: Update frag_list in pskb_trim
When pskb_trim has to defer to ___pksb_trim to trim the frag_list part of
the packet, the frag_list is not updated to reflect the trimming. This
will usually work fine until you hit something that uses the packet length
or tail from the frag_list.
Examples include esp_output and ip_fragment.
Another problem caused by this is that you can end up with a linear packet
with a frag_list attached.
It is possible to get away with this if we audit everything to make sure
that they always consult skb->len before going down onto frag_list. In
fact we can do the samething for the paged part as well to avoid copying
the data area of the skb. For now though, let's do the conservative fix
and update frag_list.
Many thanks to Marco Berizzi for helping me to track down this bug.
This 4-year old bug took 3 months to track down. Marco was very patient
indeed :)
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Adrian Bunk <bunk@stusta.de>
Jean Delvare [Fri, 10 Nov 2006 23:13:32 +0000 (00:13 +0100)]
scx200_acb: Fix the block transactions
The scx200_acb i2c bus driver pretends to support SMBus block
transactions, but in fact it implements the more simple I2C block
transactions. Additionally, it lacks sanity checks on the length
of the block transactions, which could lead to a buffer overrun.
This fixes an oops reported by Alexander Atanasov:
http://marc.theaimsgroup.com/?l=linux-kernel&m=114970382125094
Thanks to Ben Gardner for fixing my bugs :)
Signed-off-by: Jean Delvare <khali@linux-fr.org> Signed-off-by: Adrian Bunk <bunk@stusta.de>
Jeff Mahoney [Thu, 9 Nov 2006 10:31:23 +0000 (11:31 +0100)]
[DISKLABEL] SUN: Fix signed int usage for sector count
The current sun disklabel code uses a signed int for the sector count.
When partitions larger than 1 TB are used, the cast to a sector_t causes
the partition sizes to be invalid:
This patch switches the sector count to an unsigned int to fix this.
Eric Sandeen also submitted the same patch.
Signed-off-by: Jeff Mahoney <jeffm@suse.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Adrian Bunk <bunk@stusta.de>
Larry Woodman [Thu, 9 Nov 2006 10:05:38 +0000 (11:05 +0100)]
[NET]: __alloc_pages() failures reported due to fragmentation
We have seen a couple of __alloc_pages() failures due to
fragmentation, there is plenty of free memory but no large order pages
available. I think the problem is in sock_alloc_send_pskb(), the
gfp_mask includes __GFP_REPEAT but its never used/passed to the page
allocator. Shouldnt the gfp_mask be passed to alloc_skb() ?
Signed-off-by: Larry Woodman <lwoodman@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Adrian Bunk <bunk@stusta.de>
Herbert Xu [Thu, 9 Nov 2006 10:03:56 +0000 (11:03 +0100)]
[NET]: Set truesize in pskb_copy
Since pskb_copy tacks on the non-linear bits from the original
skb, it needs to count them in the truesize field of the new skb.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Adrian Bunk <bunk@stusta.de>
John Heffner [Thu, 9 Nov 2006 10:01:54 +0000 (11:01 +0100)]
[TCP]: Don't use highmem in tcp hash size calculation.
This patch removes consideration of high memory when determining TCP
hash table sizes. Taking into account high memory results in tcp_mem
values that are too large.
Signed-off-by: John Heffner <jheffner@psc.edu> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Adrian Bunk <bunk@stusta.de>
Kirill Korotaev [Wed, 8 Nov 2006 07:12:01 +0000 (08:12 +0100)]
[IPV4]: Limit rt cache size properly.
During OpenVZ stress testing we found that UDP traffic with random src
can generate too much excessive rt hash growing leading finally to OOM
and kernel panics.
It was found that for 4GB i686 system (having 1048576 total pages and
225280 normal zone pages) kernel allocates the following route hash:
syslog: IP route cache hash table entries: 262144 (order: 8, 1048576
bytes) => ip_rt_max_size = 4194304 entries, i.e. max rt size is 4194304 * 256b = 1Gb of RAM > normal_zone
Attached the patch which removes HASH_HIGHMEM flag from
alloc_large_system_hash() call.
Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Adrian Bunk <bunk@stusta.de>
Marcel Holtmann [Wed, 8 Nov 2006 07:10:30 +0000 (08:10 +0100)]
Don't allow chmod() on the /proc/<pid>/ files
This just turns off chmod() on the /proc/<pid>/ files, since there is no
good reason to allow it, and had we disallowed it originally, the nasty
/proc race exploit wouldn't have been possible.
The other patches already fixed the problem chmod() could cause, so this
is really just some final mop-up..
This particular version is based off a patch by Eugene and Marcel which
had much better naming than my original equivalent one.
Herbert Xu [Wed, 8 Nov 2006 06:47:29 +0000 (07:47 +0100)]
[NET]: Add missing UFO initialisations
This bug was unknowingly fixed the GSO patches (or rather, its effect was
unknown at the time).
Thanks to Marco Berizzi's persistence which is documented in the thread
"ipsec tunnel asymmetrical mtu", we now know that it can have highly
non-obvious symptoms.
What happens is that uninitialised uso_size fields can cause packets to
be incorrectly identified as UFO, which means that it does not get
fragmented even if it's over the MTU.
The fix is simple enough.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Adrian Bunk <bunk@stusta.de>
from mm/memory.c:
1434 static inline void cow_user_page(struct page *dst, struct page *src, unsigned long va)
1435 {
1436 /*
1437 * If the source page was a PFN mapping, we don't have
1438 * a "struct page" for it. We do a best-effort copy by
1439 * just copying from the original user address. If that
1440 * fails, we just zero-fill it. Live with it.
1441 */
1442 if (unlikely(!src)) {
1443 void *kaddr = kmap_atomic(dst, KM_USER0);
1444 void __user *uaddr = (void __user *)(va & PAGE_MASK);
1445
1446 /*
1447 * This really shouldn't fail, because the page is there
1448 * in the page tables. But it might just be unreadable,
1449 * in which case we just give up and fill the result with
1450 * zeroes.
1451 */
1452 if (__copy_from_user_inatomic(kaddr, uaddr, PAGE_SIZE))
1453 memset(kaddr, 0, PAGE_SIZE);
1454 kunmap_atomic(kaddr, KM_USER0);
#### D-cache have to be flushed here.
#### It seems it is just forgotten.
1455 return;
1456
1457 }
1458 copy_user_highpage(dst, src, va);
#### Ok here. flush_dcache_page() called from this func if arch need it
1459 }
Signed-off-by: Dmitriy Monakhov <dmonakhov@openvz.org> Acked-by: David Miller <davem@davemloft.net> Signed-off-by: Adrian Bunk <bunk@stusta.de>
Thomas Graf [Tue, 7 Nov 2006 14:30:21 +0000 (15:30 +0100)]
PKT_SCHED: Fix error handling while dumping actions
"return -err" and blindly inheriting the error code in the netlink
failure exception handler causes errors codes to be returned as
positive value therefore making them being ignored by the caller.
May lead to sending out incomplete netlink messages.
Signed-off-by: Thomas Graf <tgraf@suug.ch> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Adrian Bunk <bunk@stusta.de>
Dave Jones [Tue, 7 Nov 2006 14:14:04 +0000 (15:14 +0100)]
[CPUFREQ] Make powernow-k7 work on SMP kernels.
Even though powernow-k7 doesn't work in SMP environments,
it can work on an SMP configured kernel if there's only
one CPU present, however recalibrate_cpu_khz was returning
-EINVAL on such kernels, so we failed to init the cpufreq driver.
Signed-off-by: Dave Jones <davej@redhat.com> Signed-off-by: Adrian Bunk <bunk@stusta.de>
As reported by Mark Dowd <Mark_Dowd@McAfee.com>, ip6_tables is susceptible
to a fragmentation attack causing false negatives on extension header
matches.
When extension headers occur in the non-first fragment after the fragment
header (possibly with an incorrect nexthdr value in the fragment header)
a rule looking for this extension header will never match.
Drop fragments that are at offset 0 and don't contain the final protocol
header regardless of the ruleset, since this should not happen normally.
Since all extension headers are before the protocol header this makes sure
an extension header is either not present or in the first fragment, where
we can properly parse it.
With help from Yasuyuki KOZAKAI <yasuyuki.kozakai@toshiba.co.jp>.
Signed-off-by: Patrick McHardy <kaber@trash.net> Signed-off-by: Adrian Bunk <bunk@stusta.de>
As reported by Mark Dowd <Mark_Dowd@McAfee.com>, ip6_tables is susceptible
to a fragmentation attack causing false negatives on protocol matches.
When the protocol header doesn't follow the fragment header immediately,
the fragment header contains the protocol number of the next extension
header. When the extension header and the protocol header are sent in
a second fragment a rule like "ip6tables .. -p udp -j DROP" will never
match.
Drop fragments that are at offset 0 and don't contain the final protocol
header regardless of the ruleset, since this should not happen normally.
With help from Yasuyuki KOZAKAI <yasuyuki.kozakai@toshiba.co.jp>.
Signed-off-by: Patrick McHardy <kaber@trash.net> Signed-off-by: Adrian Bunk <bunk@stusta.de>
Neil Brown [Sun, 5 Nov 2006 08:03:18 +0000 (09:03 +0100)]
knfsd: Fix race that can disable NFS server.
This is a long standing bug that seems to have only recently become
apparent, presumably due to increasing use of NFS over TCP - many
distros seem to be making it the default.
The SK_CONN bit gets set when a listening socket may be ready
for an accept, just as SK_DATA is set when data may be available.
It is entirely possible for svc_tcp_accept to be called with neither
of these set. It doesn't happen often but there is a small race in
svc_sock_enqueue as SK_CONN and SK_DATA are tested outside the
spin_lock. They could be cleared immediately after the test and
before the lock is gained.
This normally shouldn't be a problem. The sockets are non-blocking so
trying to read() or accept() when ther is nothing to do is not a problem.
However: svc_tcp_recvfrom makes the decision "Should I accept() or
should I read()" based on whether SK_CONN is set or not. This usually
works but is not safe. The decision should be based on whether it is
a TCP_LISTEN socket or a TCP_CONNECTED socket.
Signed-off-by: Neil Brown <neilb@suse.de> Signed-off-by: Adrian Bunk <bunk@stusta.de>
Thomas Gleixner [Sun, 5 Nov 2006 08:02:46 +0000 (09:02 +0100)]
posix-cpu-timers: prevent signal delivery starvation
The integer divisions in the timer accounting code can round the result
down to 0. Adding 0 is without effect and the signal delivery stops.
Clamp the division result to minimum 1 to avoid this.
Problem was reported by Seongbae Park <spark@google.com>, who provided
also an inital patch.
Roland sayeth:
I have had some more time to think about the problem, and to reproduce it
using Toyo's test case. For the record, if my understanding of the problem
is correct, this happens only in one very particular case. First, the
expiry time has to be so soon that in cputime_t units (usually 1s/HZ ticks)
it's < nthreads so the division yields zero. Second, it only affects each
thread that is so new that its CPU time accumulation is zero so now+0 is
still zero and ->it_*_expires winds up staying zero. For the VIRT and PROF
clocks when cputime_t is tick granularity (or the SCHED clock on
configurations where sched_clock's value only advances on clock ticks), this
is not hard to arrange with new threads starting up and blocking before they
accumulate a whole tick of CPU time. That's what happens in Toyo's test
case.
Note that in general it is fine for that division to round down to zero,
and set each thread's expiry time to its "now" time. The problem only
arises with thread's whose "now" value is still zero, so that now+0 winds up
0 and is interpreted as "not set" instead of ">= now". So it would be a
sufficient and more precise fix to just use max(ticks, 1) inside the loop
when setting each it_*_expires value.
But, it does no harm to round the division up to one and always advance
every thread's expiry time. If the thread didn't already fire timers for
the expiry time of "now", there is no expectation that it will do so before
the next tick anyway. So I followed Thomas's patch in lifting the max out
of the loops.
This patch also covers the reload cases, which are harder to write a test
for (and I didn't try). I've tested it with Toyo's case and it fixes that.
[toyoa@mvista.com: fix: min_t -> max_t] Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Roland McGrath <roland@redhat.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Adrian Bunk <bunk@stusta.de>
James Morris [Sun, 5 Nov 2006 08:00:45 +0000 (09:00 +0100)]
[IPV6]: fix lockup via /proc/net/ip6_flowlabel (CVE-2006-5619)
There's a bug in the seqfile handling for /proc/net/ip6_flowlabel, where,
after finding a flowlabel, the code will loop forever not finding any
further flowlabels, first traversing the rest of the hash bucket then just
looping.
This patch fixes the problem by breaking after the hash bucket has been
traversed.
Note that this bug can cause lockups and oopses, and is trivially invoked
by an unpriveleged user.
Signed-off-by: James Morris <jmorris@namei.org> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Adrian Bunk <bunk@stusta.de>
[S390] fix user readable uninitialised kernel memory, take 2.
The previous patch to correct the copy_from_user padding is quite
broken. The execute instruction needs to be done via the register %r4,
not via %r2 and 31 bit doesn't know the instructions lgr and ahji.
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com> Signed-off-by: Adrian Bunk <bunk@stusta.de>
[S390] fix user readable uninitialised kernel memory (CVE-2006-5174)
A user space program can read uninitialised kernel memory
by appending to a file from a bad address and then reading
the result back. The cause is the copy_from_user function
that does not clear the remaining bytes of the kernel
buffer after it got a fault on the user space address.
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com> Signed-off-by: Adrian Bunk <bunk@stusta.de>
David S. Miller [Sat, 14 Oct 2006 08:35:26 +0000 (10:35 +0200)]
[SPARC64]: Kill bogus check from bootmem_init().
There is an ancient and totally incorrect sanity check being
done on the ramdisk location. The check assumes that the
kernel is always loaded to physical address zero, which is
wrong. It was trying to validate the ramdisk value by saying that
if it fell within the kernel image address range it must be wrong.
Anyways, kill this because it actually creates problems. The
'ramdisk_image' should always be adjusted down by KERNBASE.
SILO can easily put the ramdisk in a location which causes
this test to trigger, breaking things.
[ Based almost entirely upon a patch from Ben Collins. ]
Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Adrian Bunk <bunk@stusta.de>
David S. Miller [Sat, 14 Oct 2006 08:33:10 +0000 (10:33 +0200)]
[SPARC64]: Fix sched_clock() wrapping every ~17 seconds.
Unfortunately, sparc64 doesn't have an easy way to do a "64 X 64 -->
128" bit multiply like PowerPC and IA64 do. We were doing a
"64 X 64 --> 64" bit multiple which causes overflow very quickly with
a 30-bit quotient shift.
So use a quotientshift count of 10 instead of 30, just like x86 and
ARM do.
This also fixes the wrapping of printk timestamp values every ~17
seconds.
Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Adrian Bunk <bunk@stusta.de>
Signed-off-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Adrian Bunk <bunk@stusta.de>
Olaf Hering [Fri, 13 Oct 2006 16:16:26 +0000 (18:16 +0200)]
fbdev: add modeline for 1680x1050@60
Add a modeline for the Philips 200W display. aty128fb does not do DDC, it
picks 1920x1440 or similar. It works ok with nvidiafb because it can ask
for DDC data.
Oliver Endriss [Fri, 13 Oct 2006 16:05:48 +0000 (18:05 +0200)]
v4l/dvb: Backport the budget driver DISEQC instability fix
Backport the budget driver DISEQC instability fix.
Signed-off-by: Oliver Endriss <o.endriss@gmx.de> Signed-off-by: Andrew de Quincey <adq_dvb@lidskialf.net> Signed-off-by: Michael Krufky <mkrufky@linuxtv.org>
Signed-off-by: Andrew de Quincey <adq_dvb@lidskialf.net> Signed-off-by: Michael Krufky <mkrufky@linuxtv.org> Signed-off-by: Adrian Bunk <bunk@stusta.de>
The budget-av needs this GPIO set low for most cards to work.
Signed-off-by: Andrew de Quincey <adq_dvb@lidskialf.net> Signed-off-by: Michael Krufky <mkrufky@linuxtv.org> Signed-off-by: Adrian Bunk <bunk@stusta.de>
Ang Way Chuang [Fri, 13 Oct 2006 16:01:44 +0000 (18:01 +0200)]
dvb-core: Proper handling ULE SNDU length of 0 (CVE-2006-4623)
ULE (Unidirectional Lightweight Encapsulation RFC 4326) decapsulation
code has a bug that allows an attacker to send a malformed ULE packet
with SNDU length of 0 and bring down the receiving machine. This patch
fix the bug and has been tested on version 2.6.17.11. This bug is 100%
reproducible and the modified source code (GPL) used to produce this bug
will be posted on http://nrg.cs.usm.my/downloads.htm shortly. The
kernel will produce a dump during CRC32 checking on faulty ULE packet.
Signed-off-by: Ang Way Chuang <wcang@nrg.cs.usm.my> Signed-off-by: Adrian Bunk <bunk@stusta.de>
Kirill Korotaev [Fri, 13 Oct 2006 15:58:30 +0000 (17:58 +0200)]
fix fdset leakage
When found, it is obvious. nfds calculated when allocating fdsets is
rewritten by calculation of size of fdtable, and when we are unlucky, we
try to free fdsets of wrong size.
Found due to OpenVZ resource management (User Beancounters).
USB: add YEALINK phones to the HID_QUIRK_IGNORE blacklist
Keys on Yealink based phones will not function properly when using the
generic HID driver. This patch prevents the generic HID code from
grabbing the device before the regular yealink driver can get a grip on
it.
USB: Fix unload oops and memory leak in yealink driver
This patch fixes a memory leak and a kernel oops when trying to unload
the driver, due to an unbalanced cleanup.
Thanks Ivar Jensen for spotting my mistake.
kernel/kmod.c: fix a race condition in usermodehelper.
There is a race between call_usermodehelper_keys, __call_usermodehelper
and wait_for_helper. It should only happen if preemption is enabled or
on a virtualized system.
If the cpu is preempted or put to sleep by the hypervisor in
__call_usermodehelper between the creation of the wait_for_helper
thread and the second check on sub_info->wait, the whole execution
of wait_for_helper including the complete call and the continuation
after the wait_for_completion in call_usermodehelper_keys can have
happened before __call_usermodehelper checks sub_info->wait for the
second time. Since sub_info can already have been clobbered,
sub_info->wait could be zero and complete is called a second time
with an invalid argument. This has happened on s390. It took me only
three days to find out ..
Thanks to Arnd Bergmann for his help to spot this bug.
Kenneth Lee also sent the same patch independently.
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com> Signed-off-by: Adrian Bunk <bunk@stusta.de>
This patch
- works around a bug in the I2C bridge that makes the initialization
of the TDA10046 fail on recent LifeView cards
- puts the AGC output to tristate in sleep mode. This is necessary for
recent hybrid cards that switch the AGC via tristateing.
Signed-off-by: Hartmut Hackmann <hartmut.hackmann@t-online.de> Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org> Acked-by: Michael Krufky <mkrufky@linuxtv.org> Signed-off-by: Adrian Bunk <bunk@stusta.de>
Roland Dreier [Mon, 18 Sep 2006 17:28:17 +0000 (19:28 +0200)]
Convert idr's internal locking to _irqsave variant
Currently, the code in lib/idr.c uses a bare spin_lock(&idp->lock) to do
internal locking. This is a nasty trap for code that might call idr
functions from different contexts; for example, it seems perfectly
reasonable to call idr_get_new() from process context and idr_remove() from
interrupt context -- but with the current locking this would lead to a
potential deadlock.
The simplest fix for this is to just convert the idr locking to use
spin_lock_irqsave().
In particular, this fixes a very complicated locking issue detected by
lockdep, involving the ib_ipoib driver's priv->lock and dev->_xmit_lock,
which get involved with the ib_sa module's query_idr.lock.
Signed-off-by: Roland Dreier <rolandd@cisco.com> Signed-off-by: Adrian Bunk <bunk@stusta.de>
Michael Rash [Mon, 18 Sep 2006 17:26:29 +0000 (19:26 +0200)]
[TEXTSEARCH]: Fix Boyer Moore initialization bug
The pattern is set after trying to compute the prefix table, which tries
to use it. Initialize it before calling compute_prefix_tbl, make
compute_prefix_tbl consistently use only the data from struct ts_bm
and remove the now unnecessary arguments.
Signed-off-by: Michael Rash <mbr@cipherdyne.org> Signed-off-by: Patrick McHardy <kaber@trash.net> Acked-by: David Miller <davem@davemloft.net> Signed-off-by: Adrian Bunk <bunk@stusta.de>
Jay Cliburn [Mon, 18 Sep 2006 17:23:20 +0000 (19:23 +0200)]
via-velocity: fix speed and link status reported by ethtool
The via-velocity driver reports incorrect speed and link detected status
as viewed by ethtool (and probably other tools). This patch fixes those
incorrect reports and prettifies a long line.
Signed-off-by: Jay Cliburn <jacliburn@bellsouth.net> Signed-off-by: Francois Romieu <romieu@fr.zoreil.com> Signed-off-by: Adrian Bunk <bunk@stusta.de>
Magnus Kessler [Mon, 18 Sep 2006 17:17:43 +0000 (19:17 +0200)]
[AGPGART] VIA PT880 Ultra support.
This patch enables agpgart on a Via "PT880 Ultra" based motherboard
(Asus P4V800D-X). The PCI ID of the PT880 Ultra is 0x0308 instead of
0x0258 of the PT880.
The patched via-agp passes testgart.
Signed-off-by: Magnus Kessler <Magnus.Kessler@gmx.net> Signed-off-by: Dave Jones <davej@redhat.com> Signed-off-by: Adrian Bunk <bunk@stusta.de>
- Set outputs to tristate in sleep mode
- Reduce dangerously high firmware download speed with 16MHz xtal
- added tda827x configuration with GPIOs low
- added comments to stupid looking IIC reads that work around bugs in
the tda10046.
- some minor updates
V4L/DVB: Added support for the new Lifeview hybrid cardbus modules
There seem to be many variants of this cards with different
feature sets. This entry supports
analog TV, CVBS and s-video input, FM radio and DVB-T
if they are supported by the hardware.
Michael Krufky [Sat, 16 Sep 2006 21:36:05 +0000 (23:36 +0200)]
V4L/DVB: Medion 7134: Autodetect second bridge chip
The device, Medion 7134, has two saa7134 chips on it, but only one of them
is functional in the current saa7134 driver.
This patch adds autodetection for the second, unsupported saa7134 chip,
as SAA7134_BOARD_MD7134_BRIDGE_2, and displays a message to the user
(in dmesg) indicating that the second chip isn't yet functional.
This is useful for users, since two instances of the saa7134 driver
will spawn. This patch will prevent confusion by warning the user that
only one of the chips on the board are functional.
There are other versions of the SAA7134_BOARD_MD7134 with only a single
saa7134 bridge/decoder -- those devices will not be affected by this patch.
Only devices containing the second chip will display the warning.
Signed-off-by: Michael Krufky <mkrufky@linuxtv.org> Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org> Signed-off-by: Adrian Bunk <bunk@stusta.de>
Michael Krufky [Sat, 16 Sep 2006 21:35:11 +0000 (23:35 +0200)]
V4L/DVB: Saa7134: make unsupported secondary decoder message generic
There are already some supported devices that contain two
saa713x chips on-board, where only one of these chips is
currently functional in the driver.
We are already printing a warning message for the second
saa7134 decoder in SAA7134_BOARD_AVERMEDIA_A169_B. This
patch alters that case to make it generic, so that other
cards in the same situation can use it.
Signed-off-by: Michael Krufky <mkrufky@linuxtv.org> Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org> Signed-off-by: Adrian Bunk <bunk@stusta.de>
V4L/DVB: Saa7134: add support for AVerMedia A169 Dual Analog tuner card
- Added support for AVerMedia A169 Dual Analog tuner card
(dual saa7134 decoders - only 1 working right now)
- Added autodetection for both parts of the card.
It shows up like 2 cards, B1 and B
- Enabled tuner B1, SVIDEO on B1 and composite1 through SVIDEO,
FIXME: B is more or less dead at this point and I suspect the
FM-radio is on the B part of the board
Adrian Bunk:
slightly adapted to 2.6.16
Signed-off-by: Rickard Osser <ricky@osser.se> Signed-off-by: Michael Krufky <mkrufky@linuxtv.org> Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org> Signed-off-by: Adrian Bunk <bunk@stusta.de>