- 17 Oct, 2006 40 commits
-
-
Stephen Hemminger authored
When using flow control, the PHY needs to accept multicast pause frames. Without this fix, these frames were getting discarded by the PHY before doing any flow control. Signed-off-by:Stephen Hemminger <shemminger@osdl.org>
-
Stephen Hemminger authored
Mark version, this has been a lot of patches. Signed-off-by: -
Stephen Hemminger authored
Under high load it is possible to make the receiver FIFO get overloaded. The driver/hardware recover properly, so there is no reason to fill the log with lots of extra messages, just update counter. Signed-off-by: -
Stephen Hemminger authored
The result of flow control negotiation should not limit the next negotiatition. If board is plugged into an old half duplex 10Mbit port, without pause, then replugged into a gigabit port, it should negotiate what is desired, not inherit that last negotiation. Signed-off-by: -
Stephen Hemminger authored
Don't need to reset PHY twice on startup. Signed-off-by: -
Stephen Hemminger authored
The result of duplex negotiation is avaliable in the phy status register, so use that to simplify code and avoid rereading the PHY. Signed-off-by: -
Stephen Hemminger authored
The advertising bits (from ethtool.h) fit in 16 bits.
-
Stephen Hemminger authored
The advertisement bits for flow control are located in different location on fiber (1000baseX) Signed-off-by: -
Stephen Hemminger authored
When PHY is turned off on shutdown, it causes the IRQ to get stuck on. Make sure and disable the IRQ first, and if IRQ occurs when device is not running, don't access PHY because that will hang. Signed-off-by: -
Stephen Hemminger authored
The workaround timer is not needed in most systems with proper IRQ routing and by perodically waking up it adds to laptop power consumption. Signed-off-by: -
Stephen Hemminger authored
Some motherboards don't implement MSI correctly. The driver handles this but the warning is too verbose and overly cautious. Signed-off-by: -
git://git.kernel.org/pub/scm/linux/kernel/git/dtor/inputLinus Torvalds authored
* git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input: Input: fm801-gp - handle errors from pci_enable_device() Input: gameport core - handle errors returned by device_bind_driver() Input: serio core - handle errors returned by device_bind_driver() Lockdep: fix compile error in drivers/input/serio/serio.c Input: serio - add lockdep annotations Lockdep: add lockdep_set_class_and_subclass() and lockdep_set_subclass() Input: atkbd - supress "too many keys" error message Input: i8042 - supress ACK/NAKs when blinking during panic Input: add missing exports to fix modular build
-
git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpcLinus Torvalds authored
* 'merge' of git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc: [POWERPC] Check for offline nodes in pci NUMA code [POWERPC] Better check in show_instructions [POWERPC] POWER6 has 6 PMCs [POWERPC] Never panic when taking altivec exceptions from userspace [POWERPC] Fix IO Window Updates on P2P bridges. [POWERPC] Add Makefile entry for MPC832x_mds support [POWERPC] Fix MPC8360EMDS PB board support [POWERPC] ppc: Add missing calls to set_irq_regs [POWERPC] Off-by-one in /arch/ppc/platforms/mpc8* [POWERPC] Add DOS partition table support to mpc834x_itx_defconfig [POWERPC] spufs: fix support for read/write on cntl [POWERPC] Don't crash on cell with 2 BEs when !CONFIG_NUMA
-
Jeff Garzik authored
Most of the ISDN ->readstat() implementations needed to check copy_to_user() and put_user() return values. Signed-off-by:
Jeff Garzik <jeff@garzik.org> Cc: Karsten Keil <kkeil@suse.de> Signed-off-by:
Andrew Morton <akpm@osdl.org> Signed-off-by:
Linus Torvalds <torvalds@osdl.org>
-
Jeff Garzik authored
This is a particularly ugly on-failure bug, possibly security, since the lack of error handling here is covering up another class of bug: failure to handle copy_to_user() return values. The I4L API function ->readstat() returns an integer, and by looking at several existing driver implementations, it is clear that a negative return value was meant to indicate an error. Given that several drivers already return a negative value indicating an errno-style error, the current code would blindly accept that [negative] value as a valid amount of bytes read. Obvious damage ensues. Correcting ->readstat() handling to properly notice errors fixes the existing code to work correctly on error, and enables future patches to more easily indicate errors during operation. Signed-off-by:
-
Amol Lad authored
Signed-off-by:
Amol Lad <amol@verismonetworks.com> Acked-by:
Karsten Keil <kkeil@suse.de> Signed-off-by:
-
Amol Lad authored
With Karsten Keil <kkeil@suse.de> save_flags()/cli() pair is replaced with spin_lock_irqsave() and restore_flags() replaced with spin_unlock_irqrestore() Tested compile only using allmodconfig Signed-off-by:
-
Neil Brown authored
The use of blocking notifier by _cpu_up and _cpu_down in cpu.c has two problem. 1/ An interaction with the workqueue notifier causes lockdep to spit a warning. 2/ A notifier could conceivable be added or removed while _cpu_up or _cpu_down are in process. As each notifier is called twice (prepare then commit/abort) this could be unhealthy. To fix to we simply take cpu_add_remove_lock while adding or removing notifiers to/from the list. This makes the 'blocking' usage unnecessary as all accesses to cpu_chain are now protected by cpu_add_remove_lock. So change "blocking" to "raw" in all relevant places. This fixes 1. Credit: Andrew Morton Cc: Rusty Russell <rusty@rustcorp.com.au> Cc: Michal Piotrowski <michal.k.k.piotrowski@gmail.com> (reporter) Signed-off-by:
Neil Brown <neilb@suse.de> Signed-off-by:
-
Peter Zijlstra authored
BUG: warning at kernel/rtmutex-debug.c:125/rt_mutex_debug_task_free() (Not tainted) [<c04051e3>] show_trace_log_lvl+0x58/0x16a [<c04057f0>] show_trace+0xd/0x10 [<c0405900>] dump_stack+0x19/0x1b [<c043f03d>] rt_mutex_debug_task_free+0x35/0x6a [<c04224c0>] free_task+0x15/0x24 [<c042378c>] copy_process+0x12bd/0x1324 [<c0423835>] do_fork+0x42/0x113 [<c04021dd>] sys_fork+0x19/0x1b [<c0403fb7>] syscall_call+0x7/0xb In copy_process(), dup_task_struct() also duplicates the ->pi_lock, ->pi_waiters and ->pi_blocked_on members. rt_mutex_debug_task_free() called from free_task() validates these members. However free_task() can be invoked before these members are reset for the new task. Move the initialization code before the first bail that can hit free_task(). Signed-off-by:
Peter Zijlstra <a.p.zijlstra@chello.nl> Acked-by:
Ingo Molnar <mingo@elte.hu> Signed-off-by:
-
Aneesh Kumar K.V authored
Add functions defined using ENTRY macro to the tags file. Signed-off-by:
Aneesh Kumar K.V <aneesh.kumar@gmail.com> Cc: Sam Ravnborg <sam@ravnborg.org> Signed-off-by:
-
Greg Banks authored
Some people want to do crazy things like pass multiple directories as the value of $(SUBDIRS) or $M. Mostly this kinda works, except that Makefile.modpost constructs a modpost commandline which fails modpost's argument parsing. This patch fixes that little wrinkle. Signed-off-by:
Greg Banks <gnb@melbourne.sgi.com> Cc: Sam Ravnborg <sam@ravnborg.org> Signed-off-by:
-
Akinobu Mita authored
Make epca fail on initialization failure instead of panic. Cc: "Digi International, Inc" <Eng.Linux@digi.com> Signed-off-by:
Akinobu Mita <akinobu.mita@gmail.com> Acked-by:
Alan Cox <alan@redhat.com> Acked-by:
Scott Kilau <scottk@digi.com> Signed-off-by:
-
Akinobu Mita authored
If RAM disk driver initialization fails due to blk_alloc_queue() faulure, the gendisk structs stored in rd_disks[] will not be freed completely. This patch resolves that memory leak case by doing alloc_disk() and blk_alloc_queue() at the same time. Signed-off-by:
-
Peter Zijlstra authored
Lockdep doesn't like to enable interrupts when they are enabled already. BUG: warning at kernel/lockdep.c:1814/trace_hardirqs_on() (Not tainted) [<c04051ed>] show_trace_log_lvl+0x58/0x16a [<c04057fa>] show_trace+0xd/0x10 [<c0405913>] dump_stack+0x19/0x1b [<c043abfb>] trace_hardirqs_on+0xa2/0x11e [<c041463c>] apm_bios_call_simple+0xcd/0xfd [<c0415242>] apm+0x92/0x5b1 [<c0402005>] kernel_thread_helper+0x5/0xb DWARF2 unwinder stuck at kernel_thread_helper+0x5/0xb Leftover inexact backtrace: [<c04057fa>] show_trace+0xd/0x10 [<c0405913>] dump_stack+0x19/0x1b [<c043abfb>] trace_hardirqs_on+0xa2/0x11e [<c041463c>] apm_bios_call_simple+0xcd/0xfd [<c0415242>] apm+0x92/0x5b1 [<c0402005>] kernel_thread_helper+0x5/0xb Signed-off-by:
-
Jeff Garzik authored
With 64-bit resources on 32-bit platforms, the resource address might be larger than a void*. Fix printk to work regardless of resource size. Signed-off-by:
-
Jeff Garzik authored
Handle errors thrown in disk_sysfs_symlinks(), and propagate back to caller. The callers and associated functions don't do a real good job of handling kobject errors anyway (add_partition, register_disk, rescan_partitions), so this should do until something better comes along. Signed-off-by:
-
Jeff Garzik authored
Signed-off-by:
-
Jeff Garzik authored
Signed-off-by:
-
Jan Kara authored
When IO error happens on metadata buffer, buffer is freed from memory and later fsync() is called, filesystems like ext2 fail to report EIO. We solve the problem by introducing a pointer to associated address space into the buffer_head. When a buffer is removed from a list of metadata buffers associated with an address space, IO error is transferred from the buffer to the address space, so that fsync can later report it. Signed-off-by:
Jan Kara <jack@suse.cz> Signed-off-by:
-
NeilBrown authored
It is possible for the ->fopen callback from lockd into nfsd to find that an answer cannot be given straight away (an upcall is needed) and so the request has to be 'dropped', to be retried later. That error status is not currently propagated back. So: Change nlm_fopen to return nlm error codes (rather than a private protocol) and define a new nlm_drop_reply code. Cause nlm_drop_reply to cause the rpc request to get rpc_drop_reply when this error comes back. Cause svc_process to drop a request which returns a status of rpc_drop_reply. [akpm@osdl.org: fix warning storm] Cc: Marc Eshel <eshel@almaden.ibm.com> Signed-off-by:
-
NeilBrown authored
When an nfs server shuts down, lockd needs to release all the locks even though the client still holds them. It should therefore not 'unmonitor' the clients, so that the files in nfs/sm will still be there when the nfs server restarts, so that those clients will be told to reclaim their locks. However the hosts are fully unmonitored, so statd may well remove the files. lockd has a test for 'sm_sticky' and avoid the unmonitor call if it is set, but it is currently not set. So set it when tearing down lockd. Signed-off-by:
-
J. Bruce Fields authored
Coverity noticed that the error handling code in the NFSv4 callback client sets cb->cb_client to NULL, then calls rpc_shutdown_client with the NULL pointer. Coverity: #cid 1397 Signed-off-by:
Chuck Lever <chuck.lever@oracle.com> Signed-off-by:
J. Bruce Fields <bfields@citi.umich.edu> Signed-off-by:
-
J. Bruce Fields authored
We weren't actually checking for SHARE_ACCESS_WRITE, with the result that the owner could open a non-writeable file for write! Continue to allow DENY_WRITE only with write access. Thanks to Jim Rees for reporting the bug. Signed-off-by:
-
J. Bruce Fields authored
If a client creates a file using an open which sets the mode to 000, or if a chmod changes permissions after a file is opened, then situations may arise where an NFS client knows that some IO is permitted (because a process holds the file open), but the NFS server does not (because it doesn't know about the open, and only sees that the IO conflicts with the current mode of the file). As a hack to solve this problem, NFS servers normally allow the owner to override permissions on IO. The client can still enforce correct permissions-checking on open by performing an explicit access check. In NFSv4 the client can rely on the explicit on-the-wire open instead of an access check. Therefore we should not be allowing the owner to override permissions on an over-the-wire open! However, we should still allow the owner to override permissions in the case where the client is claiming an open that it already made either before a reboot, or while it was holding a delegation. Thanks to Jim Rees for reporting the bug. Signed-off-by:
-
Miklos Szeredi authored
There's no locking for ->d_revalidate, so fuse_dentry_revalidate() should use dget_parent() instead of simply dereferencing ->d_parent. Due to topology changes in the directory tree the parent could become negative or be destroyed while being used. There hasn't been any reports about this yet. Signed-off-by:
Miklos Szeredi <miklos@szeredi.hu> Signed-off-by:
-
Miklos Szeredi authored
Fuse considered it an error (EIO) if lookup returned a directory inode, to which a dentry already refered. This is because directory aliases are not allowed. But in a network filesystem this could happen legitimately, if a directory is moved on a remote client. This patch attempts to relax the restriction by trying to first evict the offending alias from the cache. If this fails, it still returns an error (EBUSY). A rarer situation is if an mkdir races with an indenpendent lookup, which finds the newly created directory already moved. In this situation the mkdir should return success, but that would be incorrect, since the dentry cannot be instantiated, so return EBUSY. Previously checking for a directory alias and instantiation of the dentry weren't done atomically in lookup/mkdir, hence two such calls racing with each other could create aliased directories. To prevent this introduce a new per-connection mutex: fuse_conn->inst_mutex, which is taken for instantiations with a directory inode. Signed-off-by:
-
Miklos Szeredi authored
Fix a spurious BUG in an unlikely race, where at least three parallel lookups return the same inode, but with different file type. This has not yet been observed in real life. Allowing unlimited retries could delay fuse_iget() indefinitely, but this is really for the broken userspace filesystem to worry about. Signed-off-by:
-
Miklos Szeredi authored
An inode could be returned by independent parallel lookups, in this case an update of the lookup counter could be lost resulting in a memory leak in userspace. Signed-off-by:
-
Miklos Szeredi authored
Unless someone reads the documentation for write_seqcount_{begin,end} it is not obvious, that i_size_write() needs locking. Especially, that lack of such locking can result in a system hang. Signed-off-by: -
Miklos Szeredi authored
Fuse didn't always call i_size_write() with i_mutex held which caused rare hangs on SMP/32bit. This bug has been present since fuse-2.2, well before being merged into mainline. The simplest solution is to protect i_size_write() with the per-connection spinlock. Using i_mutex for this purpose would require some restructuring of the code and I'm not even sure it's always safe to acquire i_mutex in all places i_size needs to be set. Since most of vmtruncate is already duplicated for other reasons, duplicate the remaining part as well, making all i_size_write() calls internal to fuse. Using i_size_write() was unnecessary in fuse_init_inode(), since this function is only called on a newly created locked inode. Reported by a few people over the years, but special thanks to Dana Henriksen who was persistent enough in helping me debug it. Signed-off-by:
-
