- 19 May, 2003 40 commits
-
-
Benjamin Herrenschmidt authored
Support more chips and split out all the complex PHY handling into a seperate file.
-
David S. Miller authored
-
David S. Miller authored
Revert the rtnl_lock API change, it is totally unneeded. Instead we manage the todo work inside of net/core/dev.c Also, we have to move sbin hotplug invocation outside of the RTNL semaphore as well, both for register and unregister.
-
David S. Miller authored
We had two major issues when unregistering networking devices. 1) Even trying to run hotplug asynchronously could deadlock if keventd was currently trying to get the RTNL semaphore in order to process linkwatch events. 2) Unregister needs to wait for the last reference to go away before the finalization of the unregister can execute. This cannot occur under the RTNL semaphore as this is deadlock prone as well. The solution is to do all of this stuff after dropping the RTNL semaphore. rtnl_lock, if it is about to protect a region of code that could unregister network devices, registers a list to which unregistered netdevs are attached. At rtnl_unlock time this list is processed to wait for refcounts to drop to zero and then finalize the unregister.
-
David S. Miller authored
into nuts.ninka.net:/home/davem/src/BK/net-2.5
-
ssh://master.kernel.org//home/hch/BK/xfs/linux-2.5/Linus Torvalds authored
into penguin.transmeta.com:/home/torvalds/v2.5/linux
-
bk://cifs.bkbits.net/linux-2.5cifsLinus Torvalds authored
into penguin.transmeta.com:/home/torvalds/v2.5/linux
-
Christoph Hellwig authored
-
Nathan Scott authored
SGI Modid: 2.5.x-xfs:slinx:149409a
-
Nathan Scott authored
SGI Modid: 2.5.x-xfs:slinx:149400a
-
Nathan Scott authored
the rest of XFS. Fix numerous crimes against whitespace. SGI Modid: 2.5.x-xfs:slinx:149398a
-
Nathan Scott authored
which is unnecessary in log recovery, clarify some recovery debug code. SGI Modid: 2.5.x-xfs:slinx:149396a
-
Nathan Scott authored
field from the xfs_mount structure to the log structure (saves a couple of pointer dereferences when writing to the log, with v2 logs only). SGI Modid: 2.5.x-xfs:slinx:149395a
-
Nathan Scott authored
SGI Modid: 2.5.x-xfs:slinx:149232a
-
Nathan Scott authored
one spot, which lets us keep more common code in sync, 2.4/2.5 and is slightly cleaner anyway. SGI Modid: 2.5.x-xfs:slinx:149231a
-
Nathan Scott authored
changes to make log recovery respect the log device sector size. SGI Modid: 2.5.x-xfs:slinx:149230a
-
Stephen Lord authored
basically turned it off. SGI Modid: 2.5.x-xfs:slinx:148955a
-
Christoph Hellwig authored
SGI Modid: 2.5.x-xfs:slinx:148940a
-
Christoph Hellwig authored
SGI Modid: 2.5.x-xfs:slinx:148933a
-
Nathan Scott authored
record write during log recovery head/tail calculations. SGI Modid: 2.5.x-xfs:slinx:148895a
-
Christoph Hellwig authored
SGI Modid: 2.5.x-xfs:slinx:148598a
-
Stephen Lord authored
SGI Modid: 2.5.x-xfs:slinx:148433a
-
Nathan Scott authored
SGI Modid: 2.5.x-xfs:slinx:148595a
-
Christoph Hellwig authored
SGI Modid: 2.5.x-xfs:slinx:148415a
-
Nathan Scott authored
SGI Modid: 2.5.x-xfs:slinx:148285a
-
Charles Fumuso authored
SGI Modid: 2.5.x-xfs:slinx:132737a
-
Christoph Hellwig authored
SGI Modid: 2.5.x-xfs:slinx:147932a
-
Ingo Molnar authored
Noticed by Julie DeWandel <jdewand@redhat.com>. do_fork() needs to return the pid (or error), not the pointer to the resulting process structure. The process structure may not even be valid any more, since do_fork() has already woken the process up (and as a result it might already have done its thing and gone away). Besides, doing it this way cleans up the users, which all really just wanted the pid or error number _anyway_. This fixes the x86 users, other architectures need to be fixed up as well.
-
Andries E. Brouwer authored
A familar type of Oops: d_path() can return an error ENAMETOOLONG, and if we fail to test a segfault occurs. So we must test. What we do is a different matter. Rather arbitrarily I return the string " (too long)" for use in /proc/mounts.
-
Andries E. Brouwer authored
Several SCSI drivers confuse CHECK_CONDITION and CHECK_CONDITION << 1. One of them is NCR5380.c. Below a patch adding status_byte() twice. (On the other hand, sun3_NCR5380.c does this right, and generally looks better. Maybe they can be merged eventually.)
-
Andries E. Brouwer authored
After # mount --rbind /tmp /mnt (on 2.5.68) I have a corrupted namespace. Umounting /mnt fails, and /proc/mounts contains ... /dev/root /mnt ext3 rw 0 0 proc /mnt/proc proc rw 0 0 usbfs /mnt/proc/bus/usb usbfs rw 0 0 /dev/hdb5 /mnt/usr reiserfs rw 0 0 ... where of course no directories /mnt/proc or /mnt/usr exist. This is caused by the fact that copy_tree() thinks that the dentry it is called with is the root of the filesystem. If it is not, confusion arose. This patch fixes this confusion.
-
Ben Collins authored
- Fix possible memory leak in iso.c - Added handling for more than 1 Logical_Unit_Number entry in a unit directory for SBP-2. This allows for handling the second type of LUN that we didn't support yet.
-
bk://bk.arm.linux.org.uk/linux-2.5-rmkLinus Torvalds authored
into home.transmeta.com:/home/torvalds/v2.5/linux
-
Ingo Molnar authored
This fixes a race noticed by Mike Galbraith: the scheduler can lose a rebalance tick if some task happens to not be rescheduled in time. This is not a fatal condition, but an inconsistency nevertheless.
-
Ingo Molnar authored
This fixes the scheduler's sync-wakeup code to be consistent on UP as well. Right now there's a behavioral difference between an UP kernel and an SMP kernel running on a UP box: sync wakeups (which are only activated on SMP) can cause a wakeup of a higher prio task, without preemption. On UP kernels this does not happen. This difference in wakeup behavior is bad. This patch activates sync wakeups on UP as well - in the cases sync wakeups are done the waker knows that it will schedule away soon, so this 'delay preemption' decision is correct on UP as well.
-
Ingo Molnar authored
This removes the unused requeueing code.
-
Ingo Molnar authored
This fixes an SMP window where the kernel could miss to handle a signal, and increase signal delivery latency up to 200 msecs. Sun has reported to Ulrich that their JVM sees occasional unexpected signal delays under Linux. The more CPUs, the more delays. The cause of the problem is that the current signal wakeup implementation is racy in kernel/signal.c:signal_wake_up(): if (t->state == TASK_RUNNING) kick_if_running(t); ... if (t->state & mask) { wake_up_process(t); return; } If thread (or process) 't' is woken up on another CPU right after the TASK_RUNNING check, and thread starts to run, then the wake_up_process() here will do nothing, and the signal stays pending up until the thread will call into the kernel next time - which can be up to 200 msecs later. The solution is to do the 'kicking' of a running thread on a remote CPU atomically with the wakeup. For this i've added wake_up_process_kick(). There is no slowdown for the other wakeup codepaths, the new flag to try_to_wake_up() is compiled off for them. Some other subsystems might want to use this wakeup facility as well in the future (eg. AIO). In fact this race triggers quite often under Volanomark rusg, with this change added, Volanomark performance is up from 500-800 to 2000-3000, on a 4-way x86 box.
-
bk://kernel.bkbits.net/davem/net-2.5Linus Torvalds authored
into home.transmeta.com:/home/torvalds/v2.5/linux
-
Andrew Morton authored
ioctl_by_bdev() passes in a NULL file*, so we had better not dereference it.
-
Andrew Morton authored
From: William Lee Irwin III <wli@holomorphy.com> put_page_testzero() does BUG_ON(page_count(page)) when its argument is p.
-