- 09 Mar, 2007 40 commits
-
-
David S. Miller authored
This fixes http://bugzilla.kernel.org/show_bug.cgi?id=8134Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Chris Wright <chrisw@sous-sol.org>
-
Eric W. Biederman authored
Occasionally the kernel has bugs that result in no irq being found for a given cpu vector. If we acknowledge the irq the system has a good chance of continuing even though we dropped an irq message. If we continue to simply print a message and not acknowledge the irq the system is likely to become non-responsive shortly there after. AK: Fixed compilation for UP kernels Signed-off-by:
Eric W. Biederman <ebiederm@xmission.com> Signed-off-by:
Andi Kleen <ak@suse.de> Cc: "Luigi Genoni" <luigi.genoni@pirelli.com> Cc: Andi Kleen <ak@suse.de> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
-
Marcel Holtmann authored
Based on a patch from Don Howard <dhoward@redhat.com> When calling write() with a buffer larger than 512 bytes, the driver's write buffer overflows, allowing to overwrite the EIP and execute arbitrary code with kernel privileges. In read(), there exists a similar problem, but coming from the device. A malicous or buggy device sending more than 512 bytes can overflow of the driver's read buffer, with the same effects as above. Signed-off-by:
Marcel Holtmann <marcel@holtmann.org> Signed-off-by:
Harald Welte <laforge@gnumonks.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Arnaldo Carvalho de Melo authored
On 2/28/07, KOVACS Krisztian <hidden@balabit.hu> wrote: > > Hi, > > While reading TCP minisock code I've found this suspiciously looking > code fragment: > > - 8< - > struct sock *tcp_create_openreq_child(struct sock *sk, struct request_sock *req, struct sk_buff *skb) > { > struct sock *newsk = inet_csk_clone(sk, req, GFP_ATOMIC); > > if (newsk != NULL) { > const struct inet_request_sock *ireq = inet_rsk(req); > struct tcp_request_sock *treq = tcp_rsk(req); > struct inet_connection_sock *newicsk = inet_csk(sk); > struct tcp_sock *newtp; > - 8< - > > The above code initializes newicsk to inet_csk(sk), isn't that supposed > to be inet_csk(newsk)? As far as I can tell this might leave > icsk_ack.last_seg_size zero even if we do have received data. Good catch! David, please apply the attached patch. Signed-off-by:Arnaldo Carvalho de Melo <acme@redhat.com> Signed-off-by:
-
Josef Whiter authored
Fix a locking mistake in the quota code, we do a mutex_lock instead of a mutex_unlock. Signed-off-by:
Josef Whiter <jwhiter@redhat.com> Cc: Steven Whitehouse <swhiteho@redhat.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Zhang, Yanmin authored
If an ATA drive uses legacy mode, ata driver will choose 14 and 15 as the fixed irq number. On ia64 platform, such numbers are GSI and should be converted to irq vector. Signed-off-by:
Zhang Yanmin <yanmin.zhang@intel.com> Cc: Jeff Garzik <jeff@garzik.org> Cc: Tony Luck <tony.luck@intel.com> Signed-off-by:
-
Gerhard Dirschl authored
Fixes http://bugzilla.kernel.org/show_bug.cgi?id=7810 - a silly copy-paste bug introduced by the latest change. Signed-off-by:
Gerhard Dirschl <gd@spherenet.de> Cc: Peter Osterlund <petero2@telia.com> Signed-off-by:
-
David Miller authored
CT based mach64 cards were reported to hang on sparc64 boxes when compiled with gcc-4.1.x and later. Looking at this piece of code, it's no surprise. A critical delay was implemented as an empty for() loop, and gcc 4.0.x and previous did not optimize it away, so we did get a delay. But gcc-4.1.x and later can optimize it away, and we get crashes. Use a real udelay() to fix this. Fix verified on SunBlade100. Signed-off-by:
-
Andrew Morton authored
Revert 7628b0a8. Thomas Bachler reports: Commit 7628b0a8 (drivers/net/tulip/dmfe: support basic carrier detection) breaks networking on my Davicom DM9009. ethtool always reports there is no link. tcpdump shows incoming packets, but TX is disabled. Reverting the above patch fixes the problem. Cc: Samuel Thibault <samuel.thibault@ens-lyon.org> Cc: Jeff Garzik <jeff@garzik.org> Cc: Valerie Henson <val_henson@linux.intel.com> Cc: Thomas Bachler <thomas@archlinux.org> Signed-off-by:
-
Andrew Morton authored
throttle_vm_writeout() is designed to wait for the dirty levels to subside. But if the caller holds IO or FS locks, we might be holding up that writeout. So change it to take a single nap to give other devices a chance to clean some memory, then return. Cc: Nick Piggin <nickpiggin@yahoo.com.au> Cc: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp> Cc: Kumar Gala <galak@kernel.crashing.org> Cc: Pete Zaitcev <zaitcev@redhat.com> Signed-off-by:
-
Sam Ravnborg authored
lockdep_init() is marked __init but used in several places outside __init code. This causes following warnings: $ scripts/mod/modpost kernel/lockdep.o WARNING: kernel/built-in.o - Section mismatch: reference to .init.text:lockdep_init from .text.lockdep_init_map after 'lockdep_init_map' (at offset 0x105) WARNING: kernel/built-in.o - Section mismatch: reference to .init.text:lockdep_init from .text.lockdep_reset_lock after 'lockdep_reset_lock' (at offset 0x35) WARNING: kernel/built-in.o - Section mismatch: reference to .init.text:lockdep_init from .text.__lock_acquire after '__lock_acquire' (at offset 0xb2) The warnings are less obviously due to heavy inlining by gcc - this is not altered. Fix the section mismatch warnings by removing the __init marking, which seems obviously wrong. Signed-off-by:
Sam Ravnborg <sam@ravnborg.org> Acked-by:
Ingo Molnar <mingo@elte.hu> Signed-off-by:
-
Randy Dunlap authored
Driver needs sched.h for try_to_freeze(). Signed-off-by:
Randy Dunlap <randy.dunlap@oracle.com> Cc: Greg KH <greg@kroah.com> Signed-off-by:
-
S.Caglar Onur authored
lldt does not accept immediate operands, which "g" allows. Signed-off-by:
S.Caglar Onur <caglar@pardus.org.tr> Signed-off-by:
Avi Kivity <avi@qumranet.com> Cc: Ingo Molnar <mingo@elte.hu> Signed-off-by:
-
Heiko Carstens authored
3117df04 causes this: In file included from arch/s390/kernel/early.c:13: include/linux/lockdep.h:300: warning: "struct task_struct" declared inside parameter list include/linux/lockdep.h:300: warning: its scope is only this definition or declaration, which is probably not what you want Acked-by:
Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by:
-
Jiri Slaby authored
specialix, isr have 2 params pt_regs are no longer the third parameter of isr, call sx_interrupt without it. Signed-off-by:
Jiri Slaby <jirislaby@gmail.com> Signed-off-by:
-
Nick Piggin authored
unlock_buffer(), like unlock_page(), must not clear the lock without ensuring that the critical section is closed. Mingming later sent the same patch, saying: We are running SDET benchmark and saw double free issue for ext3 extended attributes block, which complains the same xattr block already being freed (in ext3_xattr_release_block()). The problem could also been triggered by multiple threads loop untar/rm a kernel tree. The race is caused by missing a memory barrier at unlock_buffer() before the lock bit being cleared, resulting in possible concurrent h_refcounter update. That causes a reference counter leak, then later leads to the double free that we have seen. Inside unlock_buffer(), there is a memory barrier is placed *after* the lock bit is being cleared, however, there is no memory barrier *before* the bit is cleared. On some arch the h_refcount update instruction and the clear bit instruction could be reordered, thus leave the critical section re-entered. The race is like this: For example, if the h_refcount is initialized as 1, cpu 0: cpu1
-
Mathieu Desnoyers authored
kernel/time/clocksource.c needs struct task_struct on m68k. Because it uses spin_unlock_irq(), which, on m68k, uses hardirq_count(), which uses preempt_count(), which needs to dereference struct task_struct, we have to include sched.h. Because it would cause a loop inclusion, we cannot include sched.h in any other of asm-m68k/system.h, linux/thread_info.h, linux/hardirq.h, which leaves this ugly include in a C file as the only simple solution. Signed-off-by:
Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca> Cc: Ingo Molnar <mingo@elte.hu> Cc: Roman Zippel <zippel@linux-m68k.org> Cc: Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
-
Hirokazu Takata authored
Additional fixes for processors without ISA_DSP_LEVEL2. sigcontext_t does not have dummy_acc1h, dummy_acc1l members any longer. Signed-off-by:
Hirokazu Takata <takata@linux-m32r.org> Signed-off-by:
-
Ken Chen authored
__unmap_hugepage_range() is buggy that it does not preserve dirty state of huge_pte when unmapping hugepage range. It causes data corruption in the event of dop_caches being used by sys admin. For example, an application creates a hugetlb file, modify pages, then unmap it. While leaving the hugetlb file alive, comes along sys admin doing a "echo 3 > /proc/sys/vm/drop_caches". drop_pagecache_sb() will happily free all pages that aren't marked dirty if there are no active mapping. Later when application remaps the hugetlb file back and all data are gone, triggering catastrophic flip over on application. Not only that, the internal resv_huge_pages count will also get all messed up. Fix it up by marking page dirty appropriately. Signed-off-by:
Ken Chen <kenchen@google.com> Cc: "Nish Aravamudan" <nish.aravamudan@gmail.com> Cc: Adam Litke <agl@us.ibm.com> Cc: David Gibson <david@gibson.dropbear.id.au> Acked-by:
William Irwin <bill.irwin@oracle.com> Cc: Hugh Dickins <hugh@veritas.com> Signed-off-by:
-
Soeren Sonnenburg authored
As macbook/macbook pro's also have to live with a single mouse button the following patch just enables the Macintosh device drivers menu in Kconfig + adds the macintosh dir to the obj-* to make macbook* users happy (who use exactly that since months.... Signed-off-by:
Soeren Sonnenburg <kernel@nn7.de> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Paul Mackerras <paulus@samba.org> Cc: Dmitry Torokhov <dtor@mail.ru> Signed-off-by:
-
Adrian Bunk authored
Fix a double free of "dfid" introduced by commit da977b2c and spotted by the Coverity checker. Signed-off-by:
Adrian Bunk <bunk@stusta.de> Cc: Eric Van Hensbergen <ericvh@gmail.com> Signed-off-by:
-
Evgeniy Dushistov authored
This is a fix of regression, which triggered by ~2.6.16. Patch with name ufs-directory-and-page-cache-from-blocks-to-pages.patch: in additional to conversation from block to page cache mechanism added new checks of directory integrity, one of them that directory entry do not across directory chunks. But some kinds of UFS: OpenStep UFS and Apple UFS (looks like these are the same filesystems) have different directory chunk size, then common UFSes(BSD and Solaris UFS). So this patch adds ability to works with variable size of directory chunks, and set it for ufstype=openstep to right size. Tested on darwin ufs. Signed-off-by:
Evgeniy Dushistov <dushistov@mail.ru> Signed-off-by:
-
Zwane Mwaikambo authored
The MTRR compat code wasn't calling the lowlevel MTRR setup due to a switch block not handling the compat case. Before: (WW) I810(0): Failed to set up write-combining range (0xd0000000,0x10000000) After: reg00: base=0x00000000 ( 0MB), size=1024MB: write-back, count=1 reg01: base=0x40000000 (1024MB), size= 512MB: write-back, count=1 reg02: base=0x5f700000 (1527MB), size= 1MB: uncachable, count=1 reg03: base=0x5f800000 (1528MB), size= 8MB: uncachable, count=1 reg04: base=0xd0000000 (3328MB), size= 256MB: write-combining, count=1 Signed-off-by:
Zwane Mwaikambo <zwane@infradead.org> Cc: Andi Kleen <ak@suse.de> Signed-off-by:
-
Magnus Damm authored
Kexec support for 2.6.20 on ia64 does not build properly using a config made up by CONFIG_SMP=n and CONFIG_HOTPLUG_CPU=n: CC arch/ia64/kernel/machine_kexec.o arch/ia64/kernel/machine_kexec.c: In function `machine_shutdown': arch/ia64/kernel/machine_kexec.c:77: warning: implicit declaration of function `cpu_down' AS arch/ia64/kernel/relocate_kernel.o CC arch/ia64/kernel/crash.o arch/ia64/kernel/crash.c: In function `kdump_cpu_freeze': arch/ia64/kernel/crash.c:139: warning: implicit declaration of function `ia64_jump_to_sal' arch/ia64/kernel/crash.c:139: error: `sal_boot_rendez_state' undeclared (first use in this function) arch/ia64/kernel/crash.c:139: error: (Each undeclared identifier is reported only once arch/ia64/kernel/crash.c:139: error: for each function it appears in.) arch/ia64/kernel/crash.c: At top level: arch/ia64/kernel/crash.c:84: warning: 'kdump_wait_cpu_freeze' defined but not used make[1]: *** [arch/ia64/kernel/crash.o] Error 1 make: *** [arch/ia64/kernel] Error 2 Signed-off-by:
Magnus Damm <magnus@valinux.co.jp> Acked-by:
Simon Horman <horms@verge.net.au> Acked-by:
Jay Lan <jlan@sgi.com> Cc: Tony Luck <tony.luck@intel.com> Signed-off-by:
-
Trond Myklebust authored
rpc_call_async() will always call rpc_release_calldata(), so it is an error for __nlm_async_call() to do so as well. Addresses http://bugzilla.kernel.org/show_bug.cgi?id=7923Signed-off-by:
Trond Myklebust <Trond.Myklebust@netapp.com> Cc: Jan "Yenya" Kasprzak <kas@fi.muni.cz> Cc: Neil Brown <neilb@suse.de> Signed-off-by:
Andrew Morton <akpm@osdl.org> Signed-off-by:
-
Trond Myklebust authored
rpc_run_task is guaranteed to always call ->rpc_release. Signed-off-by:
-
Linus Torvalds authored
Revert "[PATCH] LOG2: Alter get_order() so that it can make use of ilog2() on a constant" This reverts commit 39d61db0. The commit was buggy in multiple ways: - the conversion to ilog2() was incorrect to begin with - it tested the wrong #defines, so on all architectures but FRV you'd never see the bug except for constant arguments. - the new "get_order()" macro used its arguments multiple times, and didn't even parenthesize them properly - despite the comments, it was not true that you could use it for constant initializers, since not all architectures even use the generic page.h header file. All of the problems are individually fixable, but it all boils down to: better just revert it, and re-do it from scratch. Cc: David Howells <dhowells@redhat.com> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Paul Mackerras <paulus@samba.org> Cc: Andrew Morton <akpm@osdl.org> Cc: David Woodhouse <dwmw2@infradead.org> Signed-off-by:
-
Thomas Renninger authored
This patch works back to 2.6.17 (earlier kernels seem to need up/down operations on mutex/semaphore). psmouse - properly reset mouse on shutdown/suspend Some people report that they need psmouse module unloaded for suspend to ram/disk to work properly. Let's make port cleanup behave the same way as driver unload. This fixes "bad state" problem on various HP laptops, such as nx7400. Signed-off-by:
Dmitry Torokhov <dtor@mail.ru> Signed-off-by:
Thomas Renninger <trenn@suse.de> 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:
-
Ingo Molnar authored
The SMT scheduler incorrectly skips kernel threads even if they are runnable (but they are preempted by a higher-prio user-space task which got SMT-delayed by an even higher-priority task running on a sibling CPU). Fix this for now by only doing the SMT-nice optimization if the to-be-delayed task is the only runnable task. (This should cover most of the real-life cases anyway.) This bug has been in the SMT scheduler since 2.6.17 or so, but has only been noticed now by the active check in the dynticks code. Signed-off-by:
-
Aristeu Sergio Rozanski Filho authored
This patch fixes a possible race that leads to double freeing an idr index. When the master begin to close, release_dev() is called and then pty_close() is called: if (tty->driver->close) tty->driver->close(tty, filp); This is done without helding any locks other than BKL. Inside pty_close(), being a master close, the devpts entry will be removed: #ifdef CONFIG_UNIX98_PTYS if (tty->driver == ptm_driver) devpts_pty_kill(tty->index); #endif But devpts_pty_kill() will call get_node() that may sleep while waiting for &devpts_root->d_inode->i_sem. When this happens and the slave is being opened, tty_open() just found the driver and index: driver = get_tty_driver(device, &index); if (!driver) { mutex_unlock(&tty_mutex); return -ENODEV; } This part of the code is already protected under tty_mute. The problem is that the slave close already got an index. Then init_dev() is called and blocks waiting for the same &devpts_root->d_inode->i_sem. When the master close resumes, it removes the devpts entry, and the relation between idr index and the tty is gone. The master then sleeps waiting for the tty_mutex on release_dev(). Slave open resumes and found no tty for that index. As result, a NULL tty is returned and init_dev() doesn't flow to fast_track: /* check whether we're reopening an existing tty */ if (driver->flags & TTY_DRIVER_DEVPTS_MEM) { tty = devpts_get_tty(idx); if (tty && driver->subtype == PTY_TYPE_MASTER) tty = tty->link; } else { tty = driver->ttys[idx]; } if (tty) goto fast_track; The result of this, is that a new tty will be created and init_dev() returns sucessfull. After returning, tty_mutex is dropped and master close may resume. Master close finds it's the only use and both sides are closing, then releases the tty and the index. At this point, the idr index is free, but slave still has it. Slave open then calls pty_open() and finds that tty->link->count is 0, because there's no master and returns error. Then tty_open() calls release_dev() which executes without any warning, as it was a case of last slave close when the master is already closed (master->count == 0, slave->count == 1). The tty is then released with the already released idr index. This normally would only issue a warning on idr_remove() but in case of a customer's critical application, it's never too simple: thread1: opens master, gets index X thread1: begin closing master thread2: begin opening slave with index X thread1: finishes closing master, index X released thread3: opens master, gets index X, just released thread2: fails opening slave, releases index X <---- thread4: opens master, gets index X, init_dev() then find an already in use and healthy tty and fails If no more indexes are released, ptmx_open() will keep failing, as the first free index available is X, and it will make init_dev() fail because you're trying to "reopen a master" which isn't valid. The patch notices when this race happens and make init_dev() fail imediately. The init_dev() function is called with tty_mutex held, so it's safe to continue with tty till the end of function because release_dev() won't make any further changes without grabbing the tty_mutex. Without the patch, on some machines it's possible get easily idr warnings like this one: idr_remove called for id=15 which is not allocated. [<c02555b9>] idr_remove+0x139/0x170 [<c02a1b62>] release_mem+0x182/0x230 [<c02a28e7>] release_dev+0x4b7/0x700 [<c02a0ea7>] tty_ldisc_enable+0x27/0x30 [<c02a1e64>] init_dev+0x254/0x580 [<c02a0d64>] check_tty_count+0x14/0xb0 [<c02a4f05>] tty_open+0x1c5/0x340 [<c02a4d40>] tty_open+0x0/0x340 [<c017388f>] chrdev_open+0xaf/0x180 [<c017c2ac>] open_namei+0x8c/0x760 [<c01737e0>] chrdev_open+0x0/0x180 [<c0167bc9>] __dentry_open+0xc9/0x210 [<c0167e2c>] do_filp_open+0x5c/0x70 [<c0167a91>] get_unused_fd+0x61/0xd0 [<c0167e93>] do_sys_open+0x53/0x100 [<c0167f97>] sys_open+0x27/0x30 [<c010303b>] syscall_call+0x7/0xb using this test application available on: http://www.ruivo.org/~aris/pty_sodomizer.cSigned-off-by:Aristeu Sergio Rozanski Filho <aris@ruivo.org> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Chuck Ebbert <cebbert@redhat.com> Signed-off-by:
-
Ayaz Abdulla authored
forcedeth: disable msix There seems to be an issue when both MSI-X is enabled and NAPI is configured. This patch disables MSI-X until the issue is root caused. Signed-off-by:
Ayaz Abdulla <aabdulla@nvidia.com> Signed-off-by:
Jeff Garzik <jeff@garzik.org> Cc: Chuck Ebbert <cebbert@redhat.com> Signed-off-by:
-
Neil Brown authored
On Monday February 12, marcm@liquid-nexus.net wrote: > > > > Thanks for the quick response Neil unfortunately the kernel doesn't build with > > this patch due to a missing symbol: > > > > WARNING: "blk_recount_segments" [drivers/md/raid456.ko] undefined! > > > > Is that in another file that needs patching or within raid5.c? Yes. I keep forgetting about that bit. Sorry. Signed-off-by:
Neil Brown <neilb@suse.de> Signed-off-by:
-
Micha� Miros�aw authored
Fix reference counting (memory leak) problem in __nfulnl_send() and callers related to packet queueing. Signed-off-by:
MichaÅ MirosÅaw <mirq-linux@rere.qmqm.pl> Signed-off-by:
-
David Stevens authored
[IPV6]: /proc/net/anycast6 unbalanced inet6_dev refcnt From: David Stevens <dlstevens@us.ibm.com> Reading /proc/net/anycast6 when there is no anycast address on an interface results in an ever-increasing inet6_dev reference count, as well as a reference to the netdevice you can't get rid of. From: David Stevens <dlstevens@us.ibm.com> Signed-off-by:
-
Michal Wrobel authored
[IPV6]: anycast refcnt fix This patch fixes a bug in Linux IPv6 stack which caused anycast address to be added to a device prior DAD has been completed. This led to incorrect reference count which resulted in infinite wait for unregister_netdevice completion on interface removal. Signed-off-by:
Michal Wrobel <xmxwx@asn.pl> Signed-off-by:
-
David Miller authored
[TCP]: Fix MD5 signature pool locking. The locking calls assumed that these code paths were only invoked in software interrupt context, but that isn't true. Therefore we need to use spin_{lock,unlock}_bh() throughout. Signed-off-by: -
David Miller authored
[SPARC64] bbc_i2c: Fix kenvctrld eating %100 cpu. Based almost entirely upon a patch by Joerg Friedrich Signed-off-by: -
Arnaldo Carvalho de Melo authored
[XFRM_TUNNEL]: Reload header pointer after pskb_may_pull/pskb_expand_head Please consider applying, this was found on your latest net-2.6 tree while playing around with that ip_hdr() + turn skb->nh/h/mac pointers as offsets on 64 bits idea :-) Signed-off-by:
-
David Miller authored
[XFRM] xfrm_user: Fix return values of xfrm_add_sa_expire. As noted by Kent Yoder, this function will always return an error. Make sure it returns zero on success. Signed-off-by:
-
