- 07 Aug, 2006 19 commits
-
-
Andrew de Quincey authored
Currently I am doing lots of refactoring work in the dvb tree. This bugfix became necessary to fix 2.6.17 whilst I was in the middle of this work. Unfortunately after I tested the original code for the patch, I generated the diff against the wrong tree (I accidentally used a tree with part of the refactoring code in it). This resulted in the reported compile errors because that tree (a) was incomplete, and (b) used features which are simply not in the mainline kernel yet. Many apologies for the error and problems this has caused. :( Signed-off-by:
Andrew de Quincey <adq_dvb@lidskialf.net> Signed-off-by:
Michael Krufky <mkrufky@linuxtv.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Andrew Morton authored
Fix a bug identified by Zou Nan hai <nanhai.zou@intel.com>: If the system is in state SYSTEM_BOOTING, and need_resched() is true, cond_resched() returns true even though it didn't reschedule. Consequently need_resched() remains true and JBD locks up. Fix that by teaching cond_resched() to only return true if it really did call schedule(). cond_resched_lock() and cond_resched_softirq() have a problem too. If we're in SYSTEM_BOOTING state and need_resched() is true, these functions will drop the lock and will then try to call schedule(), but the SYSTEM_BOOTING state will prevent schedule() from being called. So on return, need_resched() will still be true, but cond_resched_lock() has to return 1 to tell the caller that the lock was dropped. The caller will probably lock up. Bottom line: if these functions dropped the lock, they _must_ call schedule() to clear need_resched(). Make it so. Also, uninline __cond_resched(). It's largeish, and slowpath. Acked-by:
Ingo Molnar <mingo@elte.hu> Signed-off-by:
Andrew Morton <akpm@osdl.org> Signed-off-by:
Linus Torvalds <torvalds@osdl.org> Signed-off-by:
-
Auke Kok authored
The Intel(R) PRO/1000 82572EI card is fully supported by 7.0.33-k2 and onward. Add the device ID so this card works with 2.6.17.y onward. This device ID was accidentally omitted. Signed-off-by:
Auke Kok <auke-jan.h.kok@intel.com> Signed-off-by:
-
Neil Brown authored
The inode number out of an NFS file handle gets passed eventually to ext3_get_inode_block() without any checking. If ext3_get_inode_block() allows it to trigger an error, then bad filehandles can have unpleasant effect - ext3_error() will usually cause a forced read-only remount, or a panic if `errors=panic' was used. So remove the call to ext3_error there and put a matching check in ext3/namei.c where inode numbers are read off storage. [akpm@osdl.org: fix off-by-one error] Signed-off-by:
Neil Brown <neilb@suse.de> Signed-off-by:
Jan Kara <jack@suse.cz> Cc: Marcel Holtmann <marcel@holtmann.org> Cc: "Stephen C. Tweedie" <sct@redhat.com> Cc: Eric Sandeen <esandeen@redhat.com> Signed-off-by:
-
Badari Pulavarty authored
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:
-
Neil Brown authored
Fix race related problem when adding items to and svcrpc auth cache. If we don't find the item we are lookng for, we allocate a new one, and then grab the lock again and search to see if it has been added while we did the alloc. If it had been added we need to 'cache_put' the newly created item that we are never going to use. But as it hasn't been initialised properly, putting it can cause an oops. So move the ->init call earlier to that it will always be fully initilised if we have to put it. Thanks to Philipp Matthias Hahn <pmhahn@svs.Informatik.Uni-Oldenburg.de> for reporting the problem. Signed-off-by:
-
Stefan Richter authored
At least Maxtor OneTouch III require a "start stop unit" command after auto spin-down before the next access can proceed. This patch activates the responsible code in scsi_mod for all Maxtor SBP-2 disks. https://bugzilla.novell.com/show_bug.cgi?id=183011 Maybe that should be done for all SBP-2 disks, but better be cautious. Signed-off-by:
Stefan Richter <stefanr@s5r6.in-berlin.de> Signed-off-by:
-
Andrew Morton authored
We can immediately bale from invalidate_bdev() if the blockdev has no pagecache. This solves the huge IPI storms which hald is causing on the big ia64 machines when it polls CDROM drives. Acked-by:
Jes Sorensen <jes@sgi.com> Signed-off-by:
-
David Miller authored
[SPARC64]: Fix quad-float multiply emulation. Something is wrong with the 3-multiply (vs. 4-multiply) optimized version of _FP_MUL_MEAT_2_*(), so just use the slower version which actually computes correct values. Noticed by Rene Rebe Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Stefan Rompf authored
[VLAN]: Fix link state propagation When the queue of the underlying device is stopped at initialization time or the device is marked "not present", the state will be propagated to the vlan device and never change. Based on an analysis by Patrick McHardy. Signed-off-by:
Stefan Rompf <stefan@loplof.de> ACKed-by:
Patrick McHardy <kaber@trash.net> Signed-off-by:
-
Herbert Xu authored
[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:
-
Alan Stern authored
This patch (as753) fixes the way uhci-hcd handles a short packet when it is the last packet of an URB. Right now the driver handles short packets the same no matter when they occur. However, the controller stops transferring packets when the short packet is not the last one (otherwise it would be reading beyond the end of the device's data) and needs to be restarted, whereas no such need occurs when the short packet is the last one. The result of the bug is that USB endpoint queues experience intermittent hangs, a regression in 2.6.17 with respect to earlier kernels. The bug was raised in Bugzilla #6752 and this patch fixed it. Signed-off-by:
Alan Stern <stern@rowland.harvard.edu> Signed-off-by:
-
Stephen Hemminger authored
If the sky2 driver decides to defer processing because it's NAPI packet quota is done, then it won't correctly handle the rest when it is rescheduled. Signed-off-by:
Stephen Hemminger <sch@sch-laptop.localdomain> Signed-off-by:
-
Mark M. Hoffman authored
This patch fixes a bug in the handling of 'ignore' module parameters of I2C client drivers. Signed-off-by:
Mark M. Hoffman <mhoffman@lightlink.com> Signed-off-by:
Jean Delvare <khali@linux-fr.org> Signed-off-by:
-
Jean Delvare authored
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:
-
Thomas Andrews authored
Fix the scx200_acb state machine: * Nack was sent one byte too late on reads >= 2 bytes. * Stop bit was set one byte too late on reads. Signed-off-by:
-
Patrick McHardy authored
[NETFILTER]: H.323 helper: fix possible NULL-ptr dereference An RCF message containing a timeout results in a NULL-ptr dereference if no RRQ has been seen before. Noticed by the "SATURN tool", reported by Thomas Dillig <tdillig@stanford.edu> and Isil Dillig <isil@stanford.edu>. Signed-off-by:
-
Marcel Holtmann authored
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. Signed-off-by:
Eugene Teo <eteo@redhat.com> Signed-off-by:
Marcel Holtmann <marcel@holtmann.org> Signed-off-by:
-
Chuck Ebbert authored
On 15 Jun 2006 03:45:10 +0200, Andi Kleen wrote: > Anyways I would say that if the BIOS can't get MCFG right then > it's likely not been validated on that board and shouldn't be used. According to Petr Vandrovec: ... "What is important (and checked) is address of MMCONFIG reported by MCFG table... Unfortunately code does not bother with printing that address :-( "Another problem is that code has hardcoded that MMCONFIG area is 256MB large. Unfortunately for the code PCI specification allows any power of two between 2MB and 256MB if vendor knows that such amount of busses (from 2 to 128) will be sufficient for system. With notebook it is quite possible that not full 8 bits are implemented for MMCONFIG bus number." So here is a patch. Unfortunately my system still fails the test because it doesn't reserve any part of the MMCONFIG area, but this may fix others. Booted on x86_64, only compiled on i386. x86_64 still remaps the max area (256MB) even though only 2MB is checked... but 2.6.16 had no check at all so it is still better. PCI: reduce size of x86 MMCONFIG reserved area check 1. Print the address of the MMCONFIG area when the test for that area being reserved fails. 2. Only check if the first 2MB is reserved, as that is the minimum. Signed-off-by:Chuck Ebbert <76306.1226@compuserve.com> Acked-by:
Arjan van de Ven <arjan@linux.intel.com> Signed-off-by:
Chris Wright <chrisw@sous-sol.org>
-
- 25 Jul, 2006 21 commits
-
-
Greg Kroah-Hartman authored
-
Kirill Korotaev authored
2.6.16 leaks like hell. While testing, I found massive leakage (reproduced in openvz) in: *filp *size-4096 And 1 object leaks in *size-32 *size-64 *size-128 It is the fix for the first one. filp leaks in the bowels of namei.c. Seems, size-4096 is file table leaking in expand_fdtables. I have no idea what are the rest and why they show only accompanying another leaks. Some debugging structs? [akpm@osdl.org, Trond: remove the IS_ERR() check] Signed-off-by:
Alexey Kuznetsov <kuznet@ms2.inr.ac.ru> Cc: Kirill Korotaev <dev@openvz.org> Cc: Trond Myklebust <trond.myklebust@fys.uio.no> Signed-off-by:
-
Andrew Morton authored
Fix http://bugzilla.kernel.org/show_bug.cgi?id=6716 Doing a sysrq over a serial line into an SMP machine presently deadlocks. Cc: Russell King <rmk@arm.linux.org.uk> Cc: Enrico Scholz <enrico.scholz@informatik.tu-chemnitz.de> Signed-off-by:
-
Pavel Machek authored
2.6.16 needs this. It was merged into 2.6.18-rc1 in http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=d616e09ab33aa4d013a93c9b393efd5cebf78521 . pdflush is carefully designed to ensure that all wakeups have some corresponding work to do - if a woken-up pdflush thread discovers that it hasn't been given any work to do then this is considered an error. That all broke when swsusp came along - because a timer-delivered wakeup to a frozen pdflush thread will just get lost. This causes the pdflush thread to get lost as well: the writeback timer is supposed to be re-armed by pdflush in process context, but pdflush doesn't execute the callout which does this. Fix that up by ignoring the return value from try_to_freeze(): jsut proceed, see if we have any work pending and only go back to sleep if that is not the case. Signed-off-by:
Pavel Machek <pavel@suse.cz> Signed-off-by:
-
Chuck Ebbert authored
ieee80211_crypt_tkip will not work without CRC32. LD .tmp_vmlinux1 net/built-in.o: In function `ieee80211_tkip_encrypt': net/ieee80211/ieee80211_crypt_tkip.c:349: undefined reference to `crc32_le' Reported by Toralf Foerster <toralf.foerster@gmx.de> Signed-off-by:
-
Patrick McHardy authored
When more rules are present than fit in a single skb, the remaining rules are incorrectly skipped. Signed-off-by:
-
Kirill Korotaev authored
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). Signed-off-by:
Kirill Korotaev <dev@openvz.org> Signed-off-by:
-
Takashi Iwai authored
Suppress 'irq handler mismatch' messages at auto-probing of irqs in ALSA ISA drivers. Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
Jaroslav Kysela <perex@suse.cz> Signed-off-by:
-
Remy Bruno authored
From: Remy Bruno <remy.bruno@trinnov.com> Signed-off-by:
-
Takashi Iwai authored
Call iounmap after free_irq to avoid invalid accesses in the shared irq. The patch is taken from https://bugzilla.novell.com/show_bug.cgi?id=167869Signed-off-by:
-
Takashi Iwai authored
Fix the workaround for AD1988A rev2 codec not to apply to AD1988B codec chips. Signed-off-by:
-
Takashi Iwai authored
WARNING: /lib/modules/2.6.18-rc1-mm1/kernel/sound/isa/opti9xx/snd-miro.ko needs unknown symbol snd_cs4231_create WARNING: /lib/modules/2.6.18-rc1-mm1/kernel/sound/isa/opti9xx/snd-miro.ko needs unknown symbol snd_cs4231_pcm WARNING: /lib/modules/2.6.18-rc1-mm1/kernel/sound/isa/opti9xx/snd-miro.ko needs unknown symbol snd_cs4231_timer WARNING: /lib/modules/2.6.18-rc1-mm1/kernel/sound/isa/opti9xx/snd-miro.ko needs unknown symbol snd_cs4231_mixer WARNING: /lib/modules/2.6.18-rc1-mm1/kernel/fs/reiser4/reiser4.ko needs unknown symbol generic_file_read Signed-off-by:
Randy Dunlap <rdunlap@xenotime.net> Signed-off-by:
-
Takashi Iwai authored
CONFIG_SND_FM801=y, CONFIG_SND_FM801_TEA575X=m resulted in the following compile error: <-- snip --> ... LD vmlinux sound/built-in.o: In function 'snd_fm801_free': fm801.c:(.text+0x3c15b): undefined reference to 'snd_tea575x_exit' sound/built-in.o: In function 'snd_card_fm801_probe': fm801.c:(.text+0x3cfde): undefined reference to 'snd_tea575x_init' make: *** [vmlinux] Error 1 <-- snip --> This patch fixes kernel Bugzilla #6458. Signed-off-by:
Adrian Bunk <bunk@stusta.de> Signed-off-by:
-
Takashi Iwai authored
Fixed the master mute switch on VAIO laptops with STAC7661 codec chip. Signed-off-by:
-
Takashi Iwai authored
Changed the assigned model for HP dc7600 with ALC260 codec to match better with the actual I/O assignment. Patch taken from ALSA bug#2157. Signed-off-by:
-
Takashi Iwai authored
Fixed the missing array terminators in AD1988 codec support code. Signed-off-by:
-
Takashi Iwai authored
Fix an occasional deadlock occuring with snd-rtctimer driver, added irqsave to the lock in tasklet (ALSA bug#952). Signed-off-by:
-
Takashi Iwai authored
Fix 64bit address of MPU401 MMIO port on au88x0 chip. Signed-off-by:
-
Herbert Xu authored
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:
-
Andrew Morton authored
The recent generic_file_write() deadlock fix caused generic_file_buffered_write() to loop inifinitely when presented with a zero-length iovec segment. Fix. Note that this fix deliberately avoids calling ->prepare_write(), ->commit_write() etc with a zero-length write. This is because I don't trust all filesystems to get that right. This is a cautious approach, for 2.6.17.x. For 2.6.18 we should just go ahead and call ->prepare_write() and ->commit_write() with the zero length and fix any broken filesystems. So I'll make that change once this code is stabilised and backported into 2.6.17.x. The reason for preferring to call ->prepare_write() and ->commit_write() with the zero-length segment: a zero-length segment _should_ be sufficiently uncommon that this is the correct way of handling it. We don't want to optimise for poorly-written userspace at the expense of well-written userspace. Cc: "Vladimir V. Saveliev" <vs@namesys.com> Cc: Neil Brown <neilb@suse.de> Cc: Martin Schwidefsky <schwidefsky@de.ibm.com> Cc: Chris Wright <chrisw@sous-sol.org> Cc: Greg KH <greg@kroah.com> Cc: <stable@kernel.org> Cc: walt <wa1ter@myrealbox.com> Signed-off-by:
-
Vladimir V. Saveliev authored
generic_file_buffered_write() prefaults in user pages in order to avoid deadlock on copying from the same page as write goes to. However, it looks like there is a problem when write is vectored: fault_in_pages_readable brings in current segment or its part (maxlen). OTOH, filemap_copy_from_user_iovec is called to copy number of bytes (bytes) which may exceed current segment, so filemap_copy_from_user_iovec switches to the next segment which is not brought in yet. Pagefault is generated. That causes the deadlock if pagefault is for the same page write goes to: page being written is locked and not uptodate, pagefault will deadlock trying to lock locked page. [akpm@osdl.org: somewhat rewritten] Cc: Neil Brown <neilb@suse.de> Cc: Martin Schwidefsky <schwidefsky@de.ibm.com> Cc: <stable@kernel.org> Signed-off-by:
-
