- 23 Aug, 2006 8 commits
-
-
Stephen Hemminger authored
This patch will linearize and check there is enough data. It handles the pprop case as well as avoiding a whole audit of the routing code. Signed-off-by:Stephen Hemminger <shemminger@osdl.org>
-
Andrew Morton authored
We've confirmed that the debug version of write_lock() can get stuck for long enough to cause NMI watchdog timeouts and hence a crash. We don't know why, yet. Disable it for now. Also disable the similar read_lock() code. Just in case. Thanks to Dave Olson <olson@unixfolk.com> for reporting and testing. Acked-by:
Ingo Molnar <mingo@elte.hu> Signed-off-by:
Andrew Morton <akpm@osdl.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Diego Calleja authored
In bugzilla #6941, Jens Kilian reported: "The function befs_utf2nls (in fs/befs/linuxvfs.c) writes a 0 byte past the end of a block of memory allocated via kmalloc(), leading to memory corruption. This happens only for filenames which are pure ASCII and a multiple of 4 bytes in length. [...] Without DEBUG_SLAB, this leads to further corruption and hard lockups; I believe this is the bug which has made kernels later than 2.6.8 unusable for me. (This must be due to changes in memory management, the bug has been in the BeFS driver since the time it was introduced (AFAICT).) Steps to reproduce: Create a directory (in BeOS, naturally :-) with files named, e.g., "1", "22", "333", "4444", ... Mount it in Linux and do an "ls" or "find"" This patch implements the suggested fix. Credits to Jens Kilian for debugging the problem and finding the right fix. Signed-off-by:
Diego Calleja <diegocg@gmail.com> Cc: Jens Kilian <jjk@acm.org> Signed-off-by:
-
David Miller authored
[RTNETLINK]: Fix IFLA_ADDRESS handling. The ->set_mac_address handlers expect a pointer to a sockaddr which contains the MAC address, whereas IFLA_ADDRESS provides just the MAC address itself. So whip up a sockaddr to wrap around the netlink attribute for the ->set_mac_address call. Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Dmitry Mishin authored
[NET]: add_timer -> mod_timer() in dst_run_gc() Patch from Dmitry Mishin <dim@openvz.org>: 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. Signed-off-by:
Dmitry Mishin <dim@openvz.org> Signed-off-by:
Kirill Korotaev <dev@openvz.org> Signed-off-by:
Alexey Kuznetsov <kuznet@ms2.inr.ac.ru> Signed-off-by:
-
Kirill Korotaev authored
[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:
-
Stephen Hemminger authored
On the 88E805X chipsets (used in laptops), the PHY was not getting powered out of shutdown properly. The variable reg1 was getting reused incorrectly. This is probably the cause of the bug. http://bugzilla.kernel.org/show_bug.cgi?id=6471Signed-off-by:
-
Eric Sandeen authored
blatantly ripped off from Neil Brown's ext2 patch. Signed-off-by:
Eric Sandeen <sandeen@sandeen.net> Acked-by:
"Theodore Ts'o" <tytso@mit.edu> Signed-off-by:
-
- 22 Aug, 2006 4 commits
-
-
Greg Kroah-Hartman authored
-
Oleg Nesterov authored
An exiting task or process which didn't do I/O yet have no io context, elv_unregister() should check it is not NULL. Signed-off-by:
Oleg Nesterov <oleg@tv-sign.ru> Acked-by:
Jens Axboe <axboe@suse.de> Signed-off-by:
-
Jan Kara authored
UDF code is not really ready to handle extents larger that 1GB. This is the easy way to forbid creating those. Also truncation code did not count with the case when there are no extents in the file and we are extending the file. Signed-off-by:
Jan Kara <jack@suse.cz> Signed-off-by:
-
Sridhar Samudrala authored
sctp_make_abort_user() now takes the msg_len along with the msg so that we don't have to recalculate the bytes in iovec. It also uses memcpy_fromiovec() so that we don't go beyond the length allocated. It is good to have this fix even if verify_iovec() is fixed to return error on overflow. Signed-off-by:
Sridhar Samudrala <sri@us.ibm.com> Signed-off-by:
-
- 18 Aug, 2006 2 commits
-
-
Greg Kroah-Hartman authored
-
Olof Johansson authored
Clear HID0[en_attn] at CPU init time on PPC970. Closes CVE-2006-4093. Signed-off-by:
Olof Johansson <olof@lixom.net> Signed-off-by:
Paul Mackerras <paulus@samba.org> Signed-off-by:
-
- 07 Aug, 2006 24 commits
-
-
Greg Kroah-Hartman authored
-
Takashi Iwai authored
Accept O_RDWR at opening a PCM OSS device that is read- or write-only, just for the compatibility with the behavior of older versions. Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Steven Rostedt authored
While helping someone to submit a patch to the stable branch, I noticed that the stable branch is not listed in the MAINTAINERS file. This was after I went there to look for the email addresses for the stable branch list (stable@kernel.org). This patch adds the stable branch to the maintainers file so that people can find where to send patches when they have a fix for the stable team. Signed-off-by:
Steven Rostedt <rostedt@goodmis.org> Signed-off-by:
Chris Wright <chrisw@sous-sol.org> Signed-off-by:
-
Paul Fulghum authored
Serialize processing of tty buffers in flush_to_ldisc to fix (very rare) corruption of tty buffer free list on SMP systems. Signed-off-by:
Paul Fulghum <paulkf@microgate.com> Acked-by:
Alan Cox <alan@redhat.com> Signed-off-by:
-
Martin Schwidefsky authored
[S390] fix futex_atomic_cmpxchg_inatomic futex_atomic_cmpxchg_inatomic has the same bug as the other atomic futex operations: the operation needs to be done in the user address space, not the kernel address space. Add the missing sacf 256 & sacf 0. Signed-off-by:
Martin Schwidefsky <schwidefsky@de.ibm.com> Signed-off-by:
-
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:
-
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:
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:
-
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:
-
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:
-
- 25 Jul, 2006 2 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:
-
