- 20 Apr, 2007 1 commit
-
-
Ard van Breemen authored
The calls made by parse_parms to other initialization code might enable interrupts again way too early. Having interrupts on this early can make systems PANIC when they initialize the IRQ controllers (which happens later in the code). This patch detects that irq's are enabled again, barfs about it and disables them again as a safety net. [akpm@osdl.org: cleanups] Signed-off-by:
Ard van Breemen <ard@telegraafnet.nl> Signed-off-by:
Andrew Morton <akpm@osdl.org> Signed-off-by:
Adrian Bunk <bunk@stusta.de>
-
- 19 Apr, 2007 7 commits
-
-
Olaf Kirch authored
This patch fixes an oops first reported in mid 2006 - see http://lkml.org/lkml/2006/8/29/358 The cause of this bug report is that when an error is signalled on the socket, irda_recvmsg_stream returns without removing a local wait_queue variable from the socket's sk_sleep queue. This causes havoc further down the road. In response to this problem, a patch was made that invoked sock_orphan on the socket when receiving a disconnect indication. This is not a good fix, as this sets sk_sleep to NULL, causing applications sleeping in recvmsg (and other places) to oops. Signed-off-by:
Olaf Kirch <olaf.kirch@oracle.com> Signed-off-by:
Samuel Ortiz <samuel@sortiz.org> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Jean Delvare authored
Users have been complaining about the w83627ehf driver flooding their logs with debug messages like: w83627ehf 9191-0a10: Increasing fan 4 clock divider from 64 to 128 or: w83627ehf 9191-0290: Increasing fan 4 clock divider from 4 to 8 The reason is that we failed to actually write the LSB of the encoded clock divider value for that fan, causing the next read to report the same old value again and again. Additionally, the fan number was improperly reported, making the bug harder to find. Signed-off-by:
Jean Delvare <khali@linux-fr.org> Signed-off-by:
-
Aubrey Li authored
In net poll mode, the current checksum function doesn't consider the kind of packet which is padded to reach a specific minimum length. I believe that's the problem causing my test case failed. The following patch fixed this issue. Signed-off-by:
Aubrey Li <aubreylee@gmail.com> Signed-off-by:
-
Tom Callaway authored
While building a test kernel for the new esp driver (against git-current), I hit this bug. Trivial fix, put the inline declaration in the right place. :) Signed-off-by:
Tom Callaway <tcallawa@redhat.com> Signed-off-by:
-
David S. Miller authored
Do not sign extend args using the sys32_ipc stub, that is buggy and unnecessary. Based upon an excellent report by Mikael Pettersson. Signed-off-by:
-
David S. Miller authored
There are several IOMMU allocator bugs. Instead of trying to fix this overly complicated code, just mirror the PCI IOMMU arena allocator which is very stable and well stress tested. I tried to make the code as identical as possible so we can switch sun4u PCI and SBUS over to a common piece of IOMMU code. All that will be need are two callbacks, one to do a full IOMMU flush and one to do a streaming buffer flush. This patch gets rid of a lot of hangs and mysterious crashes on SBUS sparc64 systems, at least for me. Signed-off-by:
-
David S. Miller authored
We only map DMA when cmd->request_bufflen is non-zero for non-sg buffers, we thus should make the same check when unmapping. Based upon a report from Pasi Pirhonen. Signed-off-by:
-
- 15 Apr, 2007 1 commit
-
-
Adrian Bunk authored
-
- 13 Apr, 2007 19 commits
-
-
Adrian Bunk authored
-
Patrick McHardy authored
Userspace uses an integer for TCA_TCINDEX_SHIFT, the kernel was changed to expect and use a u16 value in 2.6.11, which broke compatibility on big endian machines. Change back to use int. Reported by Ole Reinartz <ole.reinartz@gmx.de> Signed-off-by:
Patrick McHardy <kaber@trash.net> Signed-off-by:
-
Herbert Xu authored
Up until this point we've accepted replay window settings greater than 32 but our bit mask can only accomodate 32 packets. Thus any packet with a sequence number within the window but outside the bit mask would be accepted. This patch causes those packets to be rejected instead. Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
-
John Heffner authored
Signed-off-by:
John Heffner <jheffner@psc.edu> Signed-off-by:
-
YOSHIFUJI Hideaki authored
In article <20070329.142644.70222545.davem@davemloft.net> (at Thu, 29 Mar 2007 14:26:44 -0700 (PDT)), David Miller <davem@davemloft.net> says: > From: Sridhar Samudrala <sri@us.ibm.com> > Date: Thu, 29 Mar 2007 14:17:28 -0700 > > > The check for length in rawv6_sendmsg() is incorrect. > > As len is an unsigned int, (len < 0) will never be TRUE. > > I think checking for IPV6_MAXPLEN(65535) is better. > > > > Is it possible to send ipv6 jumbo packets using raw > > sockets? If so, we can remove this check. > > I don't see why such a limitation against jumbo would exist, > does anyone else? > > Thanks for catching this Sridhar. A good compiler should simply > fail to compile "if (x < 0)" when 'x' is an unsigned type, don't > you think :-) Dave, we use "int" for returning value, so we should fix this anyway, IMHO; we should not allow len > INT_MAX. Signed-off-by:
YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org> Acked-by:
Sridhar Samudrala <sri@us.ibm.com> Signed-off-by:
-
Patrick McHardy authored
tp->root is not freed on destruction. Signed-off-by:
-
Andreas Oberritter authored
The ADEF bits in the TSCR register have different meanings in read and write mode. For this reason ADEF has to be reset on every read-modify-write operation. This patch introduces a special write function for this register, which takes care of it. Thanks to Holger Magnussen for pointing my nose at this problem. Signed-off-by:
Andreas Oberritter <obi@linuxtv.org> Signed-off-by:
-
Oliver Endriss authored
Olaf Hering pointed out that SAA7146_CLIPPING_MEM would become very large for PAGE_SIZE > 4K. In fact, the number of clipping windows is limited to 16, and calculate_clipping_registers_rect() does not use more than 256 bytes. SAA7146_CLIPPING_MEM adjusted accordingly. (cherry picked from commit 7a7cd192) Thanks-to: Olaf Hering <olaf@aepfle.de> Signed-off-by:
Oliver Endriss <o.endriss@gmx.de> Signed-off-by:
Michael Krufky <mkrufky@linuxtv.org> Signed-off-by:
-
Trent Piepho authored
All the radio drivers need video_dev, but they were depending on VIDEO_DEV!=n. That meant that one could try to compile the driver into the kernel when VIDEO_DEV=m, which will not work. If video_dev is a module, then the radio drivers must be modules too. (cherry picked from commit b10fece5) Signed-off-by:
Trent Piepho <xyzzy@speakeasy.org> Signed-off-by:
-
Michael Krufky authored
Autodetect LG TAPC G701D as tuner type 37, fixing mis-detected tuners in some Hauppauge tv tuner cards. Thanks to Adonis Papas, for pointing this out. (cherry picked from commit 1323fbda) Signed-off-by:
-
Stephen Hemminger authored
Some of these chips are disabled until clock is enabled. This fixes: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=404107Signed-off-by:Stephen Hemminger <shemminger@linux-foundation.org> Signed-off-by:
-
Stephen Hemminger authored
Driver needs to turn off carrier when down. Signed-off-by:
-
Stephen Hemminger authored
Driver needs to turn off carrier when down, otherwise it can confuse bonding and bridging and looks like carrier is on immediately when it is brought back up. Signed-off-by:
-
Thomas Gleixner authored
The __copy_to_user_inatomic() calls in file_read_actor() and pipe_read() are broken on original i386 machines, where WP-works-ok == false, as __copy_to_user_inatomic() on such systems calls functions which might sleep and/or contain cond_resched() calls inside of a kmap_atomic() region. The original check for WP-works-ok was in access_ok(), but got moved during the 2.5 series to fix a race vs. swap. Return the number of bytes to copy in the case where we are in an atomic region, so the non atomic code pathes in file_read_actor() and pipe_read() are taken. This could be optimized to avoid the kmap_atomicby moving the check for WP-works-ok into fault_in_pages_writeable(), but this is more intrusive and can be done later. Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Acked-by:
Ingo Molnar <mingo@elte.hu> Signed-off-by:
-
Francois Romieu authored
The irq handler schedules a NAPI poll request unconditionally as soon as the status register is not clean. It has been there - and wrong - for ages but a recent timing change made it apparently easier to trigger. Adrian Bunk: backported to 2.6.16 Signed-off-by:
Francois Romieu <romieu@fr.zoreil.com> Signed-off-by:
-
Francois Romieu authored
The PM hooks are no-op if the r8169 interface is down (i.e. !IFF_UP). However, as the chipset is enabled, the device will not work after a suspend/resume cycle. The patch always issue the required PCI suspend sequence and removes the module unload/reload workaround. Signed-off-by:
Arnaud Patard <apatard@mandriva.com> Signed-off-by:
-
Francois Romieu authored
Initialize the timer with the rest of the private-struct. Signed-off-by:
-
David Brownell authored
The attached fixes an oops in the usbnet driver. The same patch is in 2.6.21-rc1, but that one has many whitespace changes. This is much smaller. Signed-off-by:
David Brownell <david-b@pacbell.net> Signed-off-by:
-
Adrian Bunk authored
-
- 10 Apr, 2007 2 commits
-
-
Adrian Bunk authored
-
Jean Delvare authored
When we receive an AppleTalk frame shorter than what its header says, we still attempt to verify its checksum, and trip on the BUG_ON() at the end of function atalk_sum_skb() because of the length mismatch. This has security implications because this can be triggered by simply sending a specially crafted ethernet frame to a target victim, effectively crashing that host. Thus this qualifies, I think, as a remote DoS. Here is the frame I used to trigger the crash, in npg format: <Appletalk Killer> { # Ethernet header ----- XX XX XX XX XX XX # Destination MAC 00 00 00 00 00 00 # Source MAC 00 1D # Length # LLC header ----- AA AA 03 08 00 07 80 9B # Appletalk # Appletalk header ----- 00 1B # Packet length (invalid) 00 01 # Fake checksum 00 00 00 00 # Destination and source networks 00 00 00 00 # Destination and source nodes and ports # Payload ----- 0C 0D 0E 0F 10 11 12 13 14 } The destination MAC address must be set to those of the victim. The severity is mitigated by two requirements: * The target host must have the appletalk kernel module loaded. I suspect this isn't so frequent. * AppleTalk frames are non-IP, thus I guess they can only travel on local networks. I am no network expert though, maybe it is possible to somehow encapsulate AppleTalk packets over IP. The bug has been reported back in June 2004: http://bugzilla.kernel.org/show_bug.cgi?id=2979 But it wasn't investigated, and was closed in July 2006 as both reporters had vanished meanwhile. This code was new in kernel 2.6.0-test5: http://git.kernel.org/?p=linux/kernel/git/tglx/history.git;a=commitdiff;h=7ab442d7e0a76402c12553ee256f756097cae2d2 And not modified since then, so we can assume that vanilla kernels 2.6.0-test5 and later, and distribution kernels based thereon, are affected. Note that I still do not know for sure what triggered the bug in the real-world cases. The frame could have been corrupted by the kernel if we have a bug hiding somewhere. But more likely, we are receiving the faulty frame from the network. Signed-off-by:Jean Delvare <jdelvare@suse.de> Signed-off-by:
-
- 08 Apr, 2007 7 commits
-
-
Sergei Shtylyov authored
Fix two typos found by SiI680A documentation check. They caused the taskfile transfer overclocking: - in PIO mode 1 as 0x2283 must be used for both data and taskfile transfers; - in PIO mode 2 as data and taskfile timings are swapped when writing to the MMIO regs. Fix coding style and trailing whitespace in enclosing statements while at it... Signed-off-by:
Sergei Shtylyov <sshtylyov@ru.mvista.com> Signed-off-by:
-
Thomas Gleixner authored
hrtimer_forward() does not check for the possible overflow of timer->expires. This can happen on 64 bit machines with large interval values and results currently in an endless loop in the softirq because the expiry value becomes negative and therefor the timer is expired all the time. Check for this condition and set the expiry value to the max. expiry time in the future. Signed-off-by:
-
Thomas Gleixner authored
The maximum seconds value we can handle on 32bit is LONG_MAX. Signed-off-by: -
Thomas Gleixner authored
Frank v. Waveren pointed out that on 64bit machines the timespec to ktime_t conversion might overflow. This is also true for timeval to time_t conversions. This breaks a "sleep inf" on 64bit machines. While a timespec/timeval with tx.sec = MAX_LONG is valid by specification the internal representation of ktime_t is based on nanoseconds. The conversion of seconds to nanoseconds overflows for seconds values >= (MAX_LONG / NSEC_PER_SEC). Check the seconds argument to the conversion and limit it to the maximum time which can be represented by ktime_t. Signed-off-by:
-
David Moore authored
This together with the phys_to_virt fix in lib/swiotlb.c::swiotlb_sync_sg fixes video1394 DMA on machines with DMA bounce buffers, especially Intel x86-64 machines with > 3GB RAM. Signed-off-by:
David Moore <dcm@acm.org> Signed-off-by:
Stefan Richter <stefanr@s5r6.in-berlin.de> Signed-off-by:
-
Eric W. Biederman authored
This patch fixes the case when we reparent to a different thread in the same thread group. This modifies the code so that we do not send signals and do not change the signal to send to SIGCHLD unless we have change the thread group of our parents. It also suppresses sending pdeath_sig in this cas as well since the result of geppid doesn't change. Thanks to Oleg for spotting my bug of only fixing this for non-ptraced tasks. This fixes the issues identified by Albert Cahalan in thread http://lkml.org/lkml/2006/12/21/22Signed-off-by:
Eric W. Biederman <ebiederm@xmission.com> Signed-off-by:
-
Stephen Hemminger authored
Doug Leith observed a discrepancy between the version of CUBIC described in the papers and the version in 2.6.18. A math error related to scaling causes Cubic to grow too slowly. Patch is from "Sangtae Ha" <sha2@ncsu.edu>. I validated that it does fix the problems. See the following to show behavior over 500ms 100 Mbit link. Sender (2.6.19-rc3) --- Bridge (2.6.18-rt7) ------- Receiver (2.6.19-rc3) 1G [netem] 100M http://developer.osdl.org/shemminger/tcp/2.6.19-rc3/cubic-orig.png http://developer.osdl.org/shemminger/tcp/2.6.19-rc3/cubic-fix.pngSigned-off-by:Stephen Hemminger <shemminger@osdl.org> Signed-off-by:
-
- 04 Apr, 2007 3 commits
-
-
Jeff Garzik authored
Noticed by Doug Nazar (via David Miller). Signed-off-by:
Jeff Garzik <jeff@garzik.org> Signed-off-by:
-
Al Viro authored
Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
-
Alan Cox authored
A ZIP or similar with unformatted media will cause crashes when attempts are made to read/write it in some cases. This is because bs_factor is zero and we divide by it causing an oops. As the size of a non-accessible/non-existant media is really a bit of a zen question it doesn't matter if non-existant media is 512 bytes per sector or zero. Setting it to 1 causes us to generate 512 bytes/sector accesses and error properly. Based on a fix found lurking in an ancient bugzilla entry since about 2004 (ugghhh) Signed-off-by:
Alan Cox <alan@redhat.com> Signed-off-by:
-
