- 05 Nov, 2006 8 commits
-
-
Al Viro authored
open-coded variant there works only for little-endian Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Michael Chan authored
This fixes a bug reported in: http://bugzilla.kernel.org/show_bug.cgi?id=7438 tg3_close() turns off the PHY if WoL and ASF are both disabled. On the next tg3_open(), some devices such as the 5752M will not be brought up correctly without a PHY reset early in the reset sequence. The PHY clock is needed for some internal MAC blocks to function correctly. This problem is fixed by always resetting the PHY early in tg3_reset_hw() when it is called from tg3_open() or tg3_resume(). tg3_setup_phy() can then be called later in the sequence without the reset_phy parameter set to 1, since the PHY reset is already done. Update version to 3.68. Signed-off-by:
Michael Chan <mchan@broadcom.com> Signed-off-by:
-
Al Viro authored
htons() is not needed (and no, it's not misspelled ntohs() - userland expects net-endian here). Signed-off-by:
-
Al Viro authored
Signed-off-by:
-
Al Viro authored
Signed-off-by:
-
Al Viro authored
__constant_htons(2<<4) is not a replacement for htonl(2<<20). Signed-off-by:
-
Al Viro authored
Calculation of IPX checksum got buggered about 2.4.0. The old variant mangled the packet; that got fixed, but calculation itself got buggered. Restored the correct logics, fixed a subtle breakage we used to have even back then: if the sum is 0 mod 0xffff, we want to return 0, not 0xffff. The latter has special meaning for IPX (cheksum disabled). Observation (and obvious fix) nicked from history of FreeBSD ipx_cksum.c... Signed-off-by:
-
Al Viro authored
Signed-off-by:
-
- 04 Nov, 2006 5 commits
-
-
Linus Torvalds authored
The previous commit (45c18b0b, aka "Fix unlikely (but possible) race condition on task->user access") fixed a potential oops due to __sigqueue_alloc() getting its "user" pointer out of sync with switch_user(), and accessing a user pointer that had been de-allocated on another CPU. It still left another (much less serious) problem, where a concurrent __sigqueue_alloc and swich_user could cause sigqueue_alloc to do signal pending reference counting for a _different_ user than the one it then actually ended up using. No oops, but we'd end up with the wrong signal accounting. Another case of Oleg's eagle-eyes picking up the problem. This is trivially fixed by just making sure we load whichever "user" structure we decide to use (it doesn't matter _which_ one we pick, we just need to pick one) just once. Acked-by:
Oleg Nesterov <oleg@tv-sign.ru> Cc: Andrew Morton <akpm@osdl.org> Cc: Ingo Molnar <mingo@elte.hu> Signed-off-by:
Linus Torvalds <torvalds@osdl.org>
-
Linus Torvalds authored
There's a possible race condition when doing a "switch_uid()" from one user to another, which could race with another thread doing a signal allocation and looking at the old thread ->user pointer as it is freed. This explains an oops reported by Lukasz Trabinski: http://permalink.gmane.org/gmane.linux.kernel/462241 We fix this by delaying the (reference-counted) freeing of the user structure until the thread signal handler lock has been released, so that we know that the signal allocation has either seen the new value or has properly incremented the reference count of the old one. Race identified by Oleg Nesterov. Cc: Lukasz Trabinski <lukasz@wsisiz.edu.pl> Cc: Oleg Nesterov <oleg@tv-sign.ru> Cc: Andrew Morton <akpm@osdl.org> Cc: Ingo Molnar <mingo@elte.hu> Signed-off-by:
-
Linus Torvalds authored
Commit 5a06a363 ("[PATCH] ipc/msg.c: clean up coding style") breaks fakeroot on Alpha (variously hangs or oopses), according to a report by Falk Hueffner. The fact that the code seems to rely on compiler access ordering through the use of "volatile" is a pretty certain sign that the code has locking problems, and we should fix those properly and then remove the whole "volatile" entirely. But in the meantime, the movement of "volatile" was unintentional, and should be reverted. Cc: Falk Hueffner <falk@debian.org> Cc: Andrew Morton <akpm@osdl.org> Acked-by:
Ingo Molnar <mingo@elte.hu> Signed-off-by:
-
Jens Axboe authored
After the inode slimming patch that unionised i_pipe/i_bdev/i_cdev, it's no longer enough to check for existance of ->i_pipe to verify that this is a pipe. Original patch from Eric Dumazet <dada1@cosmosbay.com> Final solution suggested by Linus. Signed-off-by:
Jens Axboe <jens.axboe@oracle.com> Signed-off-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/shaggy/jfs-2.6Linus Torvalds authored
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/shaggy/jfs-2.6: JFS: Remove redundant xattr permission checking
-
- 03 Nov, 2006 27 commits
-
-
Linus Torvalds authored
* master.kernel.org:/pub/scm/linux/kernel/git/gregkh/pci-2.6: PCI: Let PCI_MULTITHREAD_PROBE depend on BROKEN PCI: Revert "PCI: i386/x86_84: disable PCI resource decode on device disable"
-
Linus Torvalds authored
* master.kernel.org:/pub/scm/linux/kernel/git/gregkh/usb-2.6: USB: use MII hooks only if CONFIG_MII is enabled USB Storage: unusual_devs.h entry for Sony Ericsson P990i USB: xpad: additional USB id's added USB: fix compiler issues with newer gcc versions USB: HID: add blacklist AIRcable USB, little beautification USB: usblp: fix system suspend for some systems USB: failure in usblp's error path usbtouchscreen: use endpoint address from endpoint descriptor USB: sierra: Fix id for Sierra Wireless MC8755 in new table USB: new VID/PID-combos for cp2101 hid-core: big-endian fix fix USB: usb-storage: Unusual_dev update USB: add another sierra wireless device id
-
Andreas Gruenbacher authored
The user.* extended attributes are only allowed on regular files and directories. Sticky directories further restrict write access to the owner and privileged users. (See the attr(5) man page for an explanation.) The original check in ext2/ext3 when user.* xattrs were merged was more restrictive than intended, and when the xattr permission checks were moved into the VFS, read access to user.* attributes on sticky directores ended up being denied in addition. Originally-from: Gerard Neil <xyzzy@devferret.org> Signed-off-by:
Andreas Gruenbacher <agruen@suse.de> Cc: Dave Kleikamp <shaggy@austin.ibm.com> Cc: Jan Engelhardt <jengelh@linux01.gwdg.de> Signed-off-by:
Andrew Morton <akpm@osdl.org> Signed-off-by:
-
Stephen Rothwell authored
sys_move_pages() uses vmalloc() to allocate an array of structures that is fills with information passed from user mode and then passes to do_stat_pages() (in the case the node list is NULL). do_stat_pages() depends on a marker in the node field of the structure to decide how large the array is and this marker is correctly inserted into the last element of the array. However, vmalloc() doesn't zero the memory it allocates and if the user passes NULL for the node list, then the node fields are not filled in (except for the end marker). If the memory the vmalloc() returned happend to have a word with the marker value in it in just the right place, do_pages_stat will fail to fill the status field of part of the array and we will return (random) kernel data to user mode. Signed-off-by:
Stephen Rothwell <sfr@canb.auug.org.au> Cc: Christoph Lameter <clameter@engr.sgi.com> Cc: <stable@kernel.org> Signed-off-by:
-
Peer Chen authored
Add support for PATA controllers of MCP67 to amd74xx.c. Signed-off-by:
Peer Chen <pchen@nvidia.com> Cc: Jeff Garzik <jeff@garzik.org> Acked-by:
Alan Cox <alan@redhat.com> Signed-off-by:
-
Oleg Nesterov authored
getdelays reports a "fatal reply error, errno 258". We don't have enough room for multi-threaded exit (PID + TGID). Signed-off-by:
-
Amol Lad authored
spin_lock_irq{save,restore} is incorrectly called here (the function can sleep after acquring the lock). done the necessary corrections and removed unwanted cli/sti. Signed-off-by:Amol Lad <amol@verismonetworks.com> Signed-off-by:
Karsten Keil <kkeil@suse.de> Signed-off-by:
-
Stephen Rothwell authored
Signed-off-by:
-
Stephen Rothwell authored
This is needed on bigendian 64bit architectures. Signed-off-by:
Christoph Lameter <clameter@sgi.com> Signed-off-by:
-
Jeff Dike authored
In order to get the __NR_* constants, we need sys/syscall.h. linux/unistd.h works as well since it includes syscall.h, however syscall.h is more parsimonious. We were inconsistent in this, and this patch adds syscall.h includes where necessary and removes linux/unistd.h includes where they are not needed. asm/unistd.h also includes the __NR_* constants, but these are not the glibc-sanctioned ones, so this also removes one such inclusion. Signed-off-by:
Jeff Dike <jdike@addtoit.com> Cc: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it> Signed-off-by:
-
Jeff Dike authored
Fix a UML hang in which everything would just stop until some I/O happened - a ping, someone whacking the keyboard - at which point everything would start up again as though nothing had happened. The cause was gcc reordering some code which absolutely needed to be executed in the order in the source. When unblock_signals switches signals from off to on, it needs to see if any interrupts had happened in the critical section. The interrupt handlers check signals_enabled - if it is zero, then the handler adds a bit to the "pending" bitmask and returns. unblock_signals checks this mask to see if any signals need to be delivered. The crucial part is this: signals_enabled = 1; save_pending = pending; if(save_pending == 0) return; pending = 0; In order to avoid an interrupt arriving between reading pending and setting it to zero, in which case, the record of the interrupt would be erased, signals are enabled. What happened was that gcc reordered this so that 'save_pending = pending' came before 'signals_enabled = 1', creating a one-instruction window within which an interrupt could arrive, set its bit in pending, and have it be immediately erased. When the I/O workload is purely disk-based, the loss of a block device interrupt stops the entire I/O system because the next block request will wait for the current one to finish. Thus the system hangs until something else causes some I/O to arrive, such as a network packet or console input. The fix to this particular problem is a memory barrier between enabling signals and reading the pending signal mask. An xchg would also probably work. Looking over this code for similar problems led me to do a few more things: - make signals_enabled and pending volatile so that they don't get cached in registers - add an mb() to the return paths of block_signals and unblock_signals so that the modification of signals_enabled doesn't get shuffled into the caller in the event that these are inlined in the future. Signed-off-by:
-
Jeff Mahoney authored
Callers after reiserfs_init_bitmap_cache() expect errval to contain -EINVAL until much later. If a condition fails before errval is reset later, reiserfs_fill_super() will mistakenly return 0, causing an Oops in do_add_mount(). This patch resets errval to -EINVAL after the call. I view this as a temporary fix and real error codes should be used throughout reiserfs_fill_super(). Signed-off-by:
Jeff Mahoney <jeffm@suse.com> Signed-off-by:
-
Andrew Morton authored
WARNING: vmlinux - Section mismatch: reference to .init.text:spi_register_board_info from __ksymtab_gpl between '__ksymtab_spi_register_board_info' (at offset 0xc032f7d0) and '__ksymtab_spi_alloc_master' Fix this by removing the export. Acked-by:
David Brownell <david-b@pacbell.net> Signed-off-by:
-
Rafael J. Wysocki authored
Add a swsusp debugging mode. This does everything that's needed for a suspend except for actually suspending. So we can look in the log messages and work out a) what code is being slow and b) which drivers are misbehaving. (1) # echo testproc > /sys/power/disk # echo disk > /sys/power/state This should turn off the non-boot CPU, freeze all processes, wait for 5 seconds and then thaw the processes and the CPU. (2) # echo test > /sys/power/disk # echo disk > /sys/power/state This should turn off the non-boot CPU, freeze all processes, shrink memory, suspend all devices, wait for 5 seconds, resume the devices etc. Cc: Pavel Machek <pavel@ucw.cz> Cc: Stefan Seyfried <seife@suse.de> Signed-off-by:
-
Andrew Morton authored
WARNING: vmlinux - Section mismatch: reference to .init.data:acpi_noirq from .text between 'pcibios_penalize_isa_irq' (at offset 0xc026ffa1) and 'pirq_serverworks_get' Acked-by:
"Brown, Len" <len.brown@intel.com> Cc: Andi Kleen <ak@suse.de> Signed-off-by:
-
Andrew Morton authored
Apparently FUTEX_FD is unfixably racy and nothing uses it (or if it does, it shouldn't). Add a warning printk, give any remaining users six months to migrate off it. Cc: Ulrich Drepper <drepper@redhat.com> Cc: Ingo Molnar <mingo@elte.hu> Acked-by:
Thomas Gleixner <tglx@linutronix.de> Cc: Rusty Russell <rusty@rustcorp.com.au> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk> Signed-off-by:
-
Andrew Morton authored
printk_ratelimit() has global state which makes it not useful for callers which wish to perform ratelimiting at a particular frequency. Add a printk_timed_ratelimit() which utilises caller-provided state storage to permit more flexibility. This function can in fact be used for things other than printk ratelimiting and is perhaps poorly named. Cc: Ulrich Drepper <drepper@redhat.com> Cc: Ingo Molnar <mingo@elte.hu> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Rusty Russell <rusty@rustcorp.com.au> Signed-off-by:
-
Daniel Yeisley authored
It looks like there is a bug in init_reap_node() in slab.c that can cause multiple oops's on certain ES7000 configurations. The variable reap_node is defined per cpu, but only initialized on a single CPU. This causes an oops in next_reap_node() when __get_cpu_var(reap_node) returns the wrong value. Fix is below. Signed-off-by:
Dan Yeisley <dan.yeisley@unisys.com> Cc: Andi Kleen <ak@suse.de> Acked-by:
Christoph Lameter <clameter@engr.sgi.com> Cc: Pekka Enberg <penberg@cs.helsinki.fi> Cc: Manfred Spraul <manfred@colorfullife.com> Cc: <stable@kernel.org> Signed-off-by:
-
Yvan Seth authored
Taken from http://bugzilla.kernel.org/show_bug.cgi?id=7439 It looks like device registration in drivers/char/ipmi/ipmi_si_intf.c was cleaned up and a small error was made when setting the class_mask. The fix is simple as the correct mask value is defined in the code but is not used. Acked-by:
Corey Minyard <minyard@acm.org> Cc: <stable@kernel.org> Signed-off-by:
-
Srinivasa Ds authored
When I was performing some operations on NFS, I got below error on server side. ============================================= [ INFO: possible recursive locking detected ] 2.6.19-prep #1 --------------------------------------------- nfsd4/3525 is trying to acquire lock: (&inode->i_mutex){--..}, at: [<c0611e5a>] mutex_lock+0x21/0x24 but task is already holding lock: (&inode->i_mutex){--..}, at: [<c0611e5a>] mutex_lock+0x21/0x24 other info that might help us debug this: 2 locks held by nfsd4/3525: #0: (client_mutex){--..}, at: [<c0611e5a>] mutex_lock+0x21/0x24 #1: (&inode->i_mutex){--..}, at: [<c0611e5a>] mutex_lock+0x21/0x24 stack backtrace: [<c04051ed>] show_trace_log_lvl+0x58/0x16a [<c04057fa>] show_trace+0xd/0x10 [<c0405913>] dump_stack+0x19/0x1b [<c043b6f1>] __lock_acquire+0x778/0x99c [<c043be86>] lock_acquire+0x4b/0x6d [<c0611ceb>] __mutex_lock_slowpath+0xbc/0x20a [<c0611e5a>] mutex_lock+0x21/0x24 [<c047fd7e>] vfs_rmdir+0x76/0xf8 [<f94b7ce9>] nfsd4_clear_clid_dir+0x2c/0x41 [nfsd] [<f94b7de9>] nfsd4_remove_clid_dir+0xb1/0xe8 [nfsd] [<f94b307b>] laundromat_main+0x9b/0x1c3 [nfsd] [<c04333d6>] run_workqueue+0x7a/0xbb [<c0433d0b>] worker_thread+0xd2/0x107 [<c0436285>] kthread+0xc3/0xf2 [<c0402005>] kernel_thread_helper+0x5/0xb =================================================================== Cause for this problem was,2 successive mutex_lock calls on 2 diffrent inodes ,as shown below static int nfsd4_clear_clid_dir(struct dentry *dir, struct dentry *dentry) { int status; /* For now this directory should already be empty, but we empty it of * any regular files anyway, just in case the directory was created by * a kernel from the future.... */ nfsd4_list_rec_dir(dentry, nfsd4_remove_clid_file); mutex_lock(&dir->d_inode->i_mutex); status = vfs_rmdir(dir->d_inode, dentry); ... int vfs_rmdir(struct inode *dir, struct dentry *dentry) { int error = may_delete(dir, dentry, 1); if (error) return error; if (!dir->i_op || !dir->i_op->rmdir) return -EPERM; DQUOT_INIT(dir); mutex_lock(&dentry->d_inode->i_mutex); ... So I have developed the patch to overcome this problem. Signed-off-by:Srinivasa DS <srinivasa@in.ibm.com> Cc: Neil Brown <neilb@suse.de> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Signed-off-by:
-
Akinobu Mita authored
Call sysdev_class_unregister() on failure in edac_sysfs_memctrl_setup() and decrease identation level for clear logic. Acked-by:
Doug Thompson <norsk5@xmission.com> Signed-off-by:
Akinobu Mita <akinobu.mita@gmail.com> Signed-off-by:
-
OGAWA Hirofumi authored
This just ignore the remaining pages, and remove unneeded unlock_pages(). Signed-off-by:
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp> Cc: Steven French <sfrench@us.ibm.com> Cc: Miklos Szeredi <miklos@szeredi.hu> Acked-by:
Steven Whitehouse <swhiteho@redhat.com> Cc: Trond Myklebust <trond.myklebust@fys.uio.no> Signed-off-by:
-
OGAWA Hirofumi authored
This just ignore the remaining pages. Signed-off-by:
-
OGAWA Hirofumi authored
This just ignore the remaining pages, and will fix a forgot put_pages_list(). Signed-off-by:
-
OGAWA Hirofumi authored
Current read_pages() assume ->readpages() frees the passed pages. This patch free the pages in ->read_pages(), if those were remaining in the pages_list. So, readpages() just can ignore the remaining pages in pages_list. Signed-off-by:
-
Randy Dunlap authored
Fix module_param/sysfs file permission typo. Clean up MODULE_PARM_DESC strings to avoid fancy (and incorrect) formatting. Fix header includes for lkdtm; add some needed ones, remove unused ones; and fix this gcc warning: drivers/misc/lkdtm.c:150: warning: 'struct buffer_head' declared inside parameter list drivers/misc/lkdtm.c:150: warning: its scope is only this definition or declaration, which is probably not what you want Signed-off-by:
Randy Dunlap <randy.dunlap@oracle.com> Cc: Ankita Garg <ankita@in.ibm.com> Cc: Vivek Goyal <vgoyal@in.ibm.com> Signed-off-by:
-
Eric Sandeen authored
ufs2 fails to mount on x86_64, claiming bad magic. This is because ufs_super_block_third's fs_un1 member is padded out by 4 bytes for 8-byte alignment, pushing down the rest of the struct. Forcing this to be packed solves it. I took a quick look over other on-disk structures and didn't immediately find other problems. I was able to mount & ls a populated ufs2 filesystem w/ this change. Signed-off-by:
Eric Sandeen <sandeen@redhat.com> Cc: Evgeniy Dushistov <dushistov@mail.ru> Cc: <stable@kernel.org> Signed-off-by:
-
