- 26 Jan, 2007 3 commits
-
-
Marcel Holtmann authored
The command complete event of the exit periodic inquiry command must clear the HCI_INQUIRY flag and finish the HCI request. Signed-off-by:
Marcel Holtmann <marcel@holtmann.org> Signed-off-by:
Adrian Bunk <bunk@stusta.de>
-
Marcel Holtmann authored
In case of non-blocking socket calls we should return EINPROGRESS and not EAGAIN. Signed-off-by:
Ulisses Furquim <ulissesf@gmail.com> Signed-off-by:
-
Adrian Bunk authored
Ubuntu has enabled -fstack-protector per default in gcc breaking kernel build. Explicit turn it off for now. Backported based on several patches by Sam Ravnborg <sam@ravnborg.org>. Signed-off-by:
-
- 25 Jan, 2007 4 commits
-
-
Marcel Holtmann authored
When calling send() with a zero length parameter on a RFCOMM socket it returns a positive value. In this rare case the variable err is used uninitialized and unfortunately its value is returned. Signed-off-by:
-
Marcel Holtmann authored
If the DLC device is no longer attached to the TTY device, then return errors or default values for various callbacks of the TTY layer. Signed-off-by:
-
David S. Miller authored
The "u16 *" derefs of skb->data need to be wrapped inside of a get_unaligned(). Thanks to Gustavo Zacarias for the bug report. Signed-off-by:
David S. Miller <davem@davemloft.net> Acked-by:
-
Marcel Holtmann authored
If the DLC device is no longer attached to the TTY device, then it makes no sense to go through with changing the termios settings. Signed-off-by:
-
- 24 Jan, 2007 4 commits
-
-
Jan Andersson authored
Add sg->offset to sg->dvma_address in pci_map_sg() on sparc32. Without the offset, transfers to buffers that do not begin on a page boundary will not work as expected. Signed-off-by:
Jan Andersson <jan.andersson@ieee.org> Acked-By:
-
Eric Sesterhenn authored
Stumbled over this because of coverity (id #492), seems like we are missing a return statement here and fail to do proper bounds checking. If this assumption is false we should at least change the identation to make it clear Signed-off-by:
Eric Sesterhenn <snakebyte@gmx.de> Signed-off-by:
-
Alexey Dobriyan authored
.. fix debug printk. Why, oh why, one would want to do (u16 & 0xff) << 8 and print it with %02x format? Signed-off-by:
Alexey Dobriyan <adobriyan@gmail.com> Signed-off-by:
-
Andrew de Quincey authored
Spotted by coverity/Adrian Bunk. Signed-off-by:
Andrew de Quincey <adq_dvb@lidskialf.net> Signed-off-by:
-
- 23 Jan, 2007 3 commits
-
-
Adrian Bunk authored
This patch lets BT_HIDP depend on instead of select INPUT. This fixes the following warning during an s390 build: net/bluetooth/hidp/Kconfig:4:warning: 'select' used by config symbol 'BT_HIDP' refer to undefined symbol 'INPUT' A dependency on INPUT also implies !S390 (and therefore makes the explicit dependency obsolete) since INPUT is not available on s390. The practical difference should be nearly zero, since INPUT is always set to y unless EMBEDDED=y (or S390=y). Signed-off-by: -
Shaohua Li authored
In VMSPLIT mode, kernel PGD might have more entries than user space Signed-off-by:
Shaohua Li <shaohua.li@intel.com> Signed-off-by:
-
Hugh Dickins authored
Ramiro Voicu hits the BUG_ON(!pte_none(*pte)) in zeromap_pte_range: kernel bugzilla 7645. Right: read_zero_pagealigned uses down_read of mmap_sem, but another thread's racing read of /dev/zero, or a normal fault, can easily set that pte again, in between zap_page_range and zeromap_page_range getting there. It's been wrong ever since 2.4.3. The simple fix is to use down_write instead, but that would serialize reads of /dev/zero more than at present: perhaps some app would be badly affected. So instead let zeromap_page_range return the error instead of BUG_ON, and read_zero_pagealigned break to the slower clear_user loop in that case - there's no need to optimize for it. Use -EEXIST for when a pte is found: BUG_ON in mmap_zero (the other user of zeromap_page_range), though it really isn't interesting there. And since mmap_zero wants -EAGAIN for out-of-memory, the zeromaps better return that than -ENOMEM. Signed-off-by:
Hugh Dickins <hugh@veritas.com> Signed-off-by:
-
- 22 Jan, 2007 7 commits
-
-
Alan Cox authored
When the old IDE layer calls into methods in the driver during error handling it is essentially random whether ide_lock is already held. This causes a deadlock in the atiixp driver which also uses ide_lock internally for locking. Switch to a private lock instead. [akpm@osl.org: cleanup] Signed-off-by:
Alan Cox <alan@redhat.com> Acked-by:
Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> Signed-off-by:
Andrew Morton <akpm@osdl.org> Signed-off-by:
-
Jens Axboe authored
It's a known fact that Windows times out commands after 7 seconds, so drives generally try and respond if they can before that happens. We default to 5 seconds, which sometimes is a bit too short. Jeremy Higdon reported here: http://lkml.org/lkml/2007/1/1/145 that his drive takes longer than 5 seconds for a "read track information" command, later confirming that it is about 6.7 seconds. So just do the sane thing and change the default command timeout to 7 seconds to avoid other surprises. Signed-off-by:Jens Axboe <jens.axboe@oracle.com> Signed-off-by:
-
Jes Sorensen authored
Fix typo in check of return value of qla1280_bus_reset() which would result in an adapter reset in addition to the bus reset. Signed-off-by:
Jes Sorensen <jes@sgi.com> Signed-off-by:
-
Jes Sorensen authored
Original patch from Ian Dall in bugzilla. Set command timeout as specified by the SCSI layer rather than hardcode it to 30 seconds. I have received a couple of reports of people hitting this one with various tape configurations and the patch looks obviously correct. From http://bugzilla.kernel.org/show_bug.cgi?id=6275 Ian Dall <ian@beware.dropbear.id.au>: The command sent to the card was using a 30second timeout regardless of the timeout requested in the scsi command passed down from higher levels. Signed-off-by:
-
James Bursa authored
Fix filenames on adfs discs being terminated at the first character greater than 128 (adfs filenames are Latin 1). I saw this problem when using a loopback adfs image on a 2.6.17-rc5 x86_64 machine, and the patch fixed it there. Signed-off-by: -
Martin Schwidefsky authored
Include connector config in the s390 arch Kconfig to get support for connectors. This also fixes the following Kconfig warning: fs/Kconfig:1728:warning: 'select' used by config symbol 'CIFS_UPCALL' refer to undefined symbol 'CONNECTOR' Signed-off-by:
Martin Schwidefsky <schwidefsky@de.ibm.com> Signed-off-by:
-
Patrick McHardy authored
Signed-off-by:
Patrick McHardy <kaber@trash.net> Signed-off-by:
-
- 20 Jan, 2007 3 commits
-
-
Patrick McHardy authored
The whole idea with the NOTRACK netfilter target is that you can force the netfilter code to avoid connection tracking, and all costs assosciated with it, by making traffic match a NOTRACK rule. But this is totally broken by the fact that we do a checksum calculation over the packet before we do the NOTRACK bypass check, which is very expensive. People setup NOTRACK rules explicitly to avoid all of these kinds of costs. This patch from Patrick, already in Linus's tree, fixes the bug. Move the check for ip_conntrack_untracked before the call to skb_checksum_help to fix NOTRACK excemptions from NAT. Pre-2.6.19 NAT code breaks TSO by invalidating hardware checksums for every packet, even if explicitly excluded from NAT through NOTRACK. 2.6.19 includes a fix that makes NAT and TSO live in harmony, but the performance degradation caused by this deserves making at least the workaround work properly in -stable. Signed-off-by:
-
Nick Piggin authored
This was triggered, but not the fault of, the dirty page accounting patches. Suitable for -stable as well, after it goes upstream. Unable to handle kernel NULL pointer dereference at virtual address 0000004c EIP is at _spin_lock+0x12/0x66 Call Trace: [<401766e7>] __set_page_dirty_buffers+0x15/0xc0 [<401401e7>] set_page_dirty+0x2c/0x51 [<40140db2>] set_page_dirty_balance+0xb/0x3b [<40145d29>] __do_fault+0x1d8/0x279 [<40147059>] __handle_mm_fault+0x125/0x951 [<401133f1>] do_page_fault+0x440/0x59f [<4034d0c1>] error_code+0x39/0x40 [<08048a33>] 0x8048a33 ======================= Signed-off-by:
Nick Piggin <npiggin@suse.de> Signed-off-by:
-
Adrian Bunk authored
-
- 18 Jan, 2007 2 commits
-
-
Adrian Bunk authored
-
YOSHIFUJI Hideaki authored
Signed-off-by:
-
- 14 Jan, 2007 1 commit
-
-
Paolo 'Blaisorblade' Giarrusso authored
Signed-off-by:
Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it> Signed-off-by:
-
- 09 Jan, 2007 13 commits
-
-
Adrian Bunk authored
-
Adrian Bunk authored
RESTORE_CONTEXT lost a newline: http://www.mail-archive.com/kgdb-bugreport@lists.sourceforge.net/msg00559.html Reported by Steven M. Christey. Signed-off-by:
-
Clemens Ladisch authored
The calls to rtc_control() from inside the interrupt handler can deadlock the RTC code, so move our interrupt handling code to a tasklet. Signed-off-by:
Clemens Ladisch <clemens@ladisch.de> Acked-By:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Arnaud Patard authored
The emu10k1 driver saves the A_IOCFG and HCFG register on suspend and restores it on resumes. Unfortunately, this doesn't work as the arguments to outl() are reversed. Signed-off-by:
Arnaud Patard <arnaud.patard@rtp-net.org> Signed-off-by:
-
Takashi Iwai authored
Fix an assertion when accessing a user-defined control due to lack of initialization (appears only when CONFIG_SND_DEBUg is enabled). ALSA sound/core/control.c:660: BUG? (info->access == 0) Signed-off-by:
-
Andrey Mirkin authored
OpenVZ Linux kernel team has found a problem with mounting in compat mode. Simple command "mount -t smbfs ..." on Fedora Core 5 distro in 32-bit mode leads to oops: Unable to handle kernel NULL pointer dereference at 0000000000000000 RIP: [<ffffffff802bc7c6>] compat_sys_mount+0xd6/0x290 PGD 34d48067 PUD 34d03067 PMD 0 Oops: 0000 [1] SMP CPU: 0 Modules linked in: iptable_nat simfs smbfs ip_nat ip_conntrack vzdquota parport_pc lp parport 8021q bridge llc vznetdev vzmon nfs lockd sunrpc vzdev iptable_filter af_packet xt_length ipt_ttl xt_tcpmss ipt_TCPMSS iptable_mangle xt_limit ipt_tos ipt_REJECT ip_tables x_tables thermal processor fan button battery asus_acpi ac uhci_hcd ehci_hcd usbcore i2c_i801 i2c_core e100 mii floppy ide_cd cdrom Pid: 14656, comm: mount RIP: 0060:[<ffffffff802bc7c6>] [<ffffffff802bc7c6>] compat_sys_mount+0xd6/0x290 RSP: 0000:ffff810034d31f38 EFLAGS: 00010292 RAX: 000000000000002c RBX: 0000000000000000 RCX: 0000000000000000 RDX: ffff810034c86bc0 RSI: 0000000000000096 RDI: ffffffff8061fc90 RBP: ffff810034d31f78 R08: 0000000000000000 R09: 000000000000000d R10: ffff810034d31e58 R11: 0000000000000001 R12: ffff810039dc3000 R13: 000000000805ea48 R14: 0000000000000000 R15: 00000000c0ed0000 FS: 0000000000000000(0000) GS:ffffffff80749000(0033) knlGS:00000000b7d556b0 CS: 0060 DS: 007b ES: 007b CR0: 000000008005003b CR2: 0000000000000000 CR3: 0000000034d43000 CR4: 00000000000006e0 Process mount (pid: 14656, veid=300, threadinfo ffff810034d30000, task ffff810034c86bc0) Stack: 0000000000000000 ffff810034dd0000 ffff810034e4a000 000000000805ea48 0000000000000000 0000000000000000 0000000000000000 0000000000000000 000000000805ea48 ffffffff8021e64e 0000000000000000 0000000000000000 Call Trace: [<ffffffff8021e64e>] ia32_sysret+0x0/0xa Code: 83 3b 06 0f 85 41 01 00 00 0f b7 43 0c 89 43 14 0f b7 43 0a RIP [<ffffffff802bc7c6>] compat_sys_mount+0xd6/0x290 RSP <ffff810034d31f38> CR2: 0000000000000000 The problem is that data_page pointer can be NULL, so we should skip data conversion in this case. Signed-off-by:
Andrey Mirkin <amirkin@openvz.org> Signed-off-by:
-
Peter Zijlstra authored
BUG: warning at kernel/lockdep.c:1816/trace_hardirqs_on() (Not tainted) [<c04051ee>] show_trace_log_lvl+0x58/0x171 [<c0405802>] show_trace+0xd/0x10 [<c040591b>] dump_stack+0x19/0x1b [<c043abee>] trace_hardirqs_on+0xa2/0x11e [<c06143c3>] _spin_unlock_irq+0x22/0x26 [<c0541540>] rtc_get_rtc_time+0x32/0x176 [<c0419ba4>] hpet_rtc_interrupt+0x92/0x14d [<c0450f94>] handle_IRQ_event+0x20/0x4d [<c0451055>] __do_IRQ+0x94/0xef [<c040678d>] do_IRQ+0x9e/0xbd [<c0404a49>] common_interrupt+0x25/0x2c DWARF2 unwinder stuck at common_interrupt+0x25/0x2c Signed-off-by:
Peter Zijlstra <a.p.zijlstra@chello.nl> Signed-off-by:
-
Chuck Ebbert authored
Check struct type before dereferencing fields in ebt_entry. Failure to check can cause oops. Signed-off-by:
Chuck Ebbert <76306.1226@compuserve.com> Acked-by:
Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
-
Maxime Bizon authored
I have a Marvell board which has the same i2c hw block than mv64xxx, so I'm trying to use i2c-mv64xxx driver. But I get the following random oops at boot: Unable to handle kernel NULL pointer dereference at virtual address 00000002 Backtrace: [<c0397e4c>] (mv64xxx_i2c_intr+0x0/0x2b8) from [<c02879c4>] (__do_irq+0x4c/0x8c) [<c0287978>] (__do_irq+0x0/0x8c) from [<c0287c0c>] (do_level_IRQ+0x68/0xc0) r8 = C0501E08 r7 = 00000005 r6 = C0501E08 r5 = 00000005 r4 = C048BB78 [<c0287ba4>] (do_level_IRQ+0x0/0xc0) from [<c02885f8>] (asm_do_IRQ+0x50/0x134) r6 = C0449C78 r5 = F1020000 r4 = FFFFFFFF [<c02885a8>] (asm_do_IRQ+0x0/0x134) from [<c02869c4>] (__irq_svc+0x24/0x100) r8 = C1CAC400 r7 = 00000005 r6 = 00000002 r5 = F1020000 r4 = FFFFFFFF [<c0287efc>] (setup_irq+0x0/0x124) from [<c02880d0>] (request_irq+0xb0/0xd0) r7 = C041B2AC r6 = C0397E4C r5 = 00000000 r4 = 00000005 [<c0288020>] (request_irq+0x0/0xd0) from [<c03985f4>] (mv64xxx_i2c_probe+0x148/0x244) [<c03984ac>] (mv64xxx_i2c_probe+0x0/0x244) from [<c038bedc>] (platform_drv_probe+0x20/0x24) The oops is caused by a spurious interrupt that occurs when request_irq is called. mv64xxx_i2c_fsm() tries to read drv_data->msg, which is NULL. I noticed that hardware init is done after requesting irq. Thus any pending irq from previous hardware usage may cause this. Signed-off-by:
Maxime Bizon <mbizon@freebox.fr> Signed-off-by:
Jean Delvare <khali@linux-fr.org> Signed-off-by:
-
Jean Delvare authored
reference to .init.text: from .text between 'cx88_card_setup' (at offset 0x68c) and 'cx88_risc_field' Caused by leadtek_eeprom() being declared __devinit and called from a non-devinit context. Signed-off-by:
-
Phillip Lougher authored
Steve Grubb's fzfuzzer tool (http://people.redhat.com/sgrubb/files/ fsfuzzer-0.6.tar.gz) generates corrupt Cramfs filesystems which cause Cramfs to kernel oops in cramfs_uncompress_block(). The cause of the oops is an unchecked corrupted block length field read by cramfs_readpage(). This patch adds a sanity check to cramfs_readpage() which checks that the block length field is sensible. The (PAGE_CACHE_SIZE << 1) size check is intentional, even though the uncompressed data is not going to be larger than PAGE_CACHE_SIZE, gzip sometimes generates compressed data larger than the original source data. Mkcramfs checks that the compressed size is always less than or equal to PAGE_CACHE_SIZE << 1. Of course Cramfs could use the original uncompressed data in this case, but it doesn't. Signed-off-by:
Phillip Lougher <phillip@lougher.org.uk> Signed-off-by:
-
Eric Sandeen authored
I've been using Steve Grubb's purely evil "fsfuzzer" tool, at http://people.redhat.com/sgrubb/files/fsfuzzer-0.4.tar.gz Basically it makes a filesystem, splats some random bits over it, then tries to mount it and do some simple filesystem actions. At best, the filesystem catches the corruption gracefully. At worst, things spin out of control. As you might guess, we found a couple places in ext3 where things spin out of control :) First, we had a corrupted directory that was never checked for consistency... it was corrupt, and pointed to another bad "entry" of length 0. The for() loop looped forever, since the length of ext3_next_entry(de) was 0, and we kept looking at the same pointer over and over and over and over... I modeled this check and subsequent action on what is done for other directory types in ext3_readdir... (adding this check adds some computational expense; I am testing a followup patch to reduce the number of times we check and re-check these directory entries, in all cases. Thanks for the idea, Andreas). Next we had a root directory inode which had a corrupted size, claimed to be > 200M on a 4M filesystem. There was only really 1 block in the directory, but because the size was so large, readdir kept coming back for more, spewing thousands of printk's along the way. Per Andreas' suggestion, if we're in this read error condition and we're trying to read an offset which is greater than i_blocks worth of bytes, stop trying, and break out of the loop. With these two changes fsfuzz test survives quite well on ext3. Signed-off-by:
Eric Sandeen <sandeen@redhat.com> Signed-off-by:
-
Eric Sandeen authored
This one was pointed out on the MOKB site: http://kernelfun.blogspot.com/2006/11/mokb-09-11-2006-linux-26x-ext2checkpage.html If a directory's i_size is corrupted, ext2_find_entry() will keep processing pages until the i_size is reached, even if there are no more blocks associated with the directory inode. This patch puts in some minimal sanity-checking so that we don't keep checking pages (and issuing errors) if we know there can be no more data to read, based on the block count of the directory inode. This is somewhat similar in approach to the ext3 patch I sent earlier this year. Signed-off-by:
-
