| Age | Commit message (Collapse) | Author |
|---|
|
This adds a new seq_...() helper:
seq_path(seq_file, mnt, dentry, escape)
It spits the pathname into seq_file, does octal escapes for given set of
characters, returns the number of characters it'd produced or -1 in case
of error. Long names are handled gracefully - you don't need anything
to do, generic seq_file logics will do the right thing.
/proc/mounts and /proc/swaps are converted to use of seq_path(), some
junk removed.
/proc/pid/maps will be converted next.
|
|
Most cache-lookups to find export information will cause
an upcall, but currently the lookup to find the pseudo root
for nfsv4 wont asthe cache-handle isn't made available.
This patch makes it available and makes sure that if the
upcall is made, the request is dropped (for now).
|
|
From: "William A.(Andy) Adamson" <andros@citi.umich.edu>
this open share state patch creates all the structures and hash tables needed
to create and destroy share state on OPEN.
a struct nfs4_stateowner is introduced. this is currently only used for share
state, but will also be used as an anchor for byte-range lock state. e.g. it
will be either an (open)stateowner or a (lock)stateower.
a struct nfs4_stateid is introduced with holds stateid info for openfiles per
(open)stateowner. this struct will also hold byte-range lock info for
(lock)stateowners.
ownerstr_hashtbl[] holds nfs4_stateowners hashed by the nfs4_open owner and
clientid, and is used to lookup nfs4_stateowners on OPEN.
a struct nfs4_file is introduced which holds info on open files with state.
file_hashtbl[] holds nfs4_files, and is used to find a file in order to search
for conflicting share locks on OPEN. delegation info will hang off the
nf4_file struct.
i moved nfsd4_process_open1() into nfs4state.c, and added nfs4_process_open2()
there as well
i've left lease management, state reclaim, and the special replay management
on sequenceid mutating operations like OPEN for subsequent patches.
|
|
state management.
From: "William A.(Andy) Adamson" <andros@citi.umich.edu>
this is the first of several patches against 2.5 concerning NFSv4 state for
nfsd. it cleans up the names of state structures in preperation for future
share, lease, byte-range, and delegation patches. specifically, it
1) renames portions of the stateid_t and moves it along with the clientid_t
from xdr.h into state.h
2) uses xdr_netobj to gather related data and length fields in struct
nfs4_open (in xdr4.h) (e.g. we have op_fname.data and op_fname.len
instead of op_name and op_namelen).
3) renames NFSD4_CLIENT_MAXNAME to NFS4_OPAQUE_LIMIT which will be used in
other state fields (not just for name length)
|
|
|
|
into nuts.ninka.net:/home/davem/src/BK/net-2.5
|
|
|
|
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.
|
|
into tetrachloride.(none):/mnt/raid/src/kernel/2.5/agpgart
|
|
|
|
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.
|
|
|
|
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.
|
|
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.
|
|
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.
|
|
into home.transmeta.com:/home/torvalds/v2.5/linux
|
|
From: William Lee Irwin III <wli@holomorphy.com>
put_page_testzero() does BUG_ON(page_count(page)) when its argument is p.
|
|
From: Oleg Drokin <green@namesys.com>
With the current 'one block at a time' algorithm, writes past the end of a
file are slow because each new file block is separately added into the tree
causing shifting of other items which is CPU expensive.
With this new implementation if you write into file with big enough chunks,
it uses half as much CPU. Also this version is more SMP friendly than the
current one.
There are some known-bad applications that break with this patch (ie. start
to work very slow or even hang).
This is because the filesystem returns a large value in the stat.st_blocksize
hint (128k instead of 4k). This tickles a small number of application bugs.
One is KDE's kmail 3.04 (fixed by upgrading to 3.1+) and the other is
sleepycat's database from before 1997.
If you hit a slowdown problem that you believe is related to the increased
"recommended i/o size" value, try to mount your fs with nolargeio=1 mount
option (remount should work too).
This patch exports block_commit_write(), generic_osync_inode() and
remove_suid() to modules.
|
|
- generic_file_open() comment fix (Bill Irwin)
- kerneldoc fix in truncate.c (Aniruddha M Marathe)
- remove truncate debug check.
- page_lock comment fix (Robert Love)
- remove unused device mapper label.
- 3c509 docco fix ("Mark Tranchant" <mark@tranchant.freeserve.co.uk>)
--
Documentation/networking/3c509.txt | 2 +-
drivers/md/dm-ioctl.c | 1 -
fs/open.c | 2 +-
include/linux/fs.h | 2 +-
mm/truncate.c | 8 +++-----
5 files changed, 6 insertions(+), 9 deletions(-)
|
|
|
|
This is what a lot of the callers really wanted.
|
|
into kernel.bkbits.net:/home/davem/net-2.5
|
|
|
|
|
|
into kernel.bkbits.net:/home/davem/net-2.5
|
|
|
|
into nuts.ninka.net:/home/davem/src/BK/net-2.5
|
|
|
|
|
|
Also use kernel-doc for struct cycx_hw
|
|
|
|
|
|
net_device
|
|
|
|
into nuts.ninka.net:/home/davem/src/BK/net-2.5
|
|
into nuts.ninka.net:/home/davem/src/BK/net-2.5
|
|
into nuts.ninka.net:/home/davem/src/BK/net-2.5
|
|
into nuts.ninka.net:/home/davem/src/BK/net-2.5
|
|
into nuts.ninka.net:/home/davem/src/BK/net-2.5
|
|
|
|
|
|
into osdl.org:/home/mochel/src/kernel/devel/linux-2.5-core
|
|
This way, we can easily handle devices that contain an arbitrary number of
resources reported by the platform.
|
|
This is a bit neater.
|
|
into osdl.org:/home/mochel/src/kernel/devel/linux-2.5-core
|
|
From: Christoph Hellwig <hch@lst.de>
Remove smp.h leftovers. From the ia64 tree.
|
|
From: Petr Vandrovec <vandrove@vc.cvut.cz>
While I was trying to hunt down problem with spin_lock_irq in
send_sig_info, I noticed that debugging spinlocks are a bit unusable.
The problem is that these spinlocks first print warning, and then
decrement babble. So if the lock is used by printk code (like runqueue
lock was), we get nothing, just a lockup or a double fault... When we
first decrement babble and then print the error message we can break
this unfortunate situation and the error message (5 of the same...)
appear on screen.
|
|
put_dirty_page() currently assumes PAGE_COPY for the stack page's ptes. But
for x86_64 (at least) this is not the case.
The patch adds the extra arg to put_dirty_page(), updates all callers and fixes
x86_64.
|
|
From Russell King:
The location and interrupt of some platform devices are only known by
platform specific code. In order to avoid putting platform specific
parameters into drivers, place resource and irq members into struct
platform_device.
|
|
Originally from Matt Dobson. I've been running with this for a while
in -dj, with no noticable side-effects.
Matt:
node_zonelists looks like it should really be declared of size
MAX_NR_ZONES, not GFP_ZONEMASK. GFP_ZONEMASK is currently 15, making
node_zonelists an array of 16 elements. The extra zonelists are all
just duplicates of the *real* zonelists, namely the first 3 entries.
Again, if anyone can explain to me why I'm wrong in my thinking, I'd
love to know. There's certainly no way you could bitwise-and something
with any combination of the GFP_DMA and GFP_HIGHMEM flags to refer to
the 12th zonelist or some such! Or am I crazy?
|
