Currently get_parent (needed to find the exportpoint
above a given dentry) walks the hash table of export points
checking each with is_subdir.  Now it walks up the d_parent
link checking each for membership in the hashtable.

nfsd_lookup currently does that walk too (when crossing
a mountpoint backwards) so the code gets unified.

This approach makes more sense as we move towards a cache
for export information that can be filled on demand.
It also assumes less about the hash table (which will change).

The nfs server currently doesn't allow you to export both a
directory and an ancestor of that directory on the same filesystem.

This check is more of a problem than a solution and can be
done in user-space if needed, so it is removed.

The potential for a security problem is because the files
below the lower directory could be accessed as though it were under
either of the export points, and so the access control that is
applied might not be what is expected (by the nieve admin).

e.g.  export /a as readwrite and /a/b as readonly.  Then a/b/c
can be accessed readwrite as it is in /a which might not be the
intend.  Altering the user to this can be done in userspace though.

The current restriction also stops exporting / as readonly and
/tmp as read-write which some people want to do.  Providing
/tmp is also exported subtree_check (the default) there is no
security issue here.

They can be deduced from ex_dentry

We currently store the address list with each
client and use it only to print out comments
on /proc/fs/nfs/exports
While these can be helpful, they are not critical and
could be added back later after we restructure the exports
table.

Instead, use d_path to find path from dentry/vfsmnt.
This requires allocating a buffer at exp_open time,
and releasing it when closing.

It is never used

Don't print if default, which should be "-2", but is currently 65534..
We really need a 32bit uid interface for 2.6.

I was never entirely sure what it was for, but it
is not used now, only set, so it can go.

It is un-used and never will be.  uid mapping will be done a
different way (if at all).

lockd currently asks nfsd for a 'client handle' for each
request.

This is used as a key for finding (or creating) a 'nlm_host'
structure, so that there is only one of these per client...almost.
There can currently be up to 4 nlm_hosts for a given client,
depending on protocol (udp/tcp) or version (v1 or v4).

But this isn't handled very well.

So the question is: is there any advantage in having only on
nlm_host per real host, or have we simply have one for each IP
address that makes requests, whether they are separate hosts or not.

The nlm_host structure is used:
 1/ to hold a lockd rpc client for talking to the
    remote lockd.  Having multiple lockd clients cannot hurt
    except possibly to waste a little space.
 2/ to identify resources to free when we receive notification
    from statd that a client has restarted.
    As statd gets a hostname and looks up all IP addresses,
    and then sends a notification for each IP for which it has
    a registration, there is no need to minimise the number
    of nlm_host structures (each of which register for monitoring).
 3/ to identify resources to free when a client sends a
    "free_all" request.  If a client uses multiple IP addresses to
    create locks, and then sends free_all from just one IP address
    we will loose here.
    However it is not clear that a client would ever want to send
    a free_all request, and the linux client doesn't seem to, so
    there is unlikely to be any loss here.

This patch does not ask nfsd for a client identifier, but rather
finds an nlm_host based on IP, version, protocol (udp/tcp) and
whether we are acting as NFS server or client.

All of this information is then placed in the cookie that is
passed to statd and returned by statd when the client restarts.
Previously only the IP address was passing the cookie, so possibly
not all nlm_host structures would have been found.

Because of these changes, lockd does not need to know
anything about the nfsd export table, so the interface to
nfsd is much more narrow.

Another consequence is that when nfsd is told to delete a client,
it cannot tell lockd to forget all the locks for that client.
However it is not clear that lockd should ever forget any locks
unless it is told to shutdown (or simulate a shutdown), and in
anycase, the current nfsd admin tools never tell nfsd to delete
a client anyway.

Currently, when lockd wants to invalidate all it's
clients, it asks nfsd to iterate through them.  Now
it iterates itself.

Just the new structure initialisers.

both md.c and raid5.c can be compiled with debugging and compile
errors in this code aren't normally noticed as they aren't even
compiled.

Now the debugging messages are compiled but optimised out so we will
always see the errors.

Current errors are fixed.

That recent bug fix in raid5 just changed the bug, it didn't fix it.
I think that the original code was actually wrong, which didn't
help.

This time, the code actually matches the nearby comment, that has been expanded
a bit, so I feel somewhat more confident that it is actually right.

Since 2.5.33, the blk_dev[].queue is called without
the device open, so md_queue_proc can no-longer assume
that the device is open.

into home.transmeta.com:/home/torvalds/v2.5/linux

into home.transmeta.com:/home/torvalds/v2.5/linux

Use the same rule as in Rules.make for preprocessing 
vmlinux.lds.S, that also gives automatic dependency tracking.
This means we should also use the standard AFLAGS_... instead
of CPPFLAGS_... to provide specific additional flags.

When using cp to copy the shipped file to its actual name,
permissions would be preserved, particularly the copy would be
read-only when the original was (BitKeeper) read-only, leading
to an error when executing the rule a second time.

So now we use cat, which will generate a writable file.

Just some cosmetical changes to align output in non-verbose mode.

Linus spotted one cut-n-pasto ('tracing' argument) but didn't see the
other: we were walking the ptrace_children list by the sibling field.

So we got garbage for your task_structs when this happened.  If the list
wasn't empty, it would crash.  Strace detaches from all tasks when it
receives a Control-C so only with enough threads and SMP would this be
easily seen.

into home.transmeta.com:/home/torvalds/v2.5/linux

This patch implements UML for 2.5.34.

I have changed the name of a local variable "l" to be "j", because with some
fonts should be difficult to see if [1+l+i] means [2+i] or what.

using init_etherdev(0, 0) in probe is a race. The struct net_device must be
allocate and filled before init_etherdev is called, or there's a race which
creates a network interface that isn't usable.
The patch for kaweth for 2.5 fixes it.

	ata_attach in linux-2.5.34/drivers/ide/ide.c builds a list of
IDE drives that do not yet have a device driver bound to them, in case
ide-disk, ide-scsi, or whatever driver you want to use is not loaded
yet.

	The problem was that ata_attach was adding to the head of
the list, so the list was being built in reverse order.  So, if
you had two IDE disks, and ide-disk was a loadable module, the
devfs entries for the disks would be numbered in reverse (the
first disk would be /dev/discs/disc1, and the second would be
/dev/discs/disc0).

	This fixes the problem by changing the relevant list_add to
list_add_tail.  Incidentally, the generic code in drivers/base/ already
does it this way.

One more patch:  this turns off async schedule processing
if there are no control or bulk transactions for a while
(currently HZ/3).  Consequence:  no PCI accesses unless
there's work to do.  (And a FIXME comment is gone!)

 Minor nit: the subject driver depends on ATM, so a config-time check to
 see if ATM support is enabled is appropriate.

this handles the error case.

new device ids for hpusbscsi

This removes some bugs:

 - a short read problem with control requests
 - only creates one control qh (memleak fix)
 - adds an omitted hardware handshake
 - reset timeout in octal, say what?
 - a couple BUG()s outlived their value

Plus it deletes unused stub code for split ISO
and updates some internal doc.

  * Tells about some Epson firmware that uses this as part
    of a Linux interop solution (PDA-ish SoCs, hmm)
  * Includes some GeneSys info from emails
  * Minor cleanups

HandyTech's Braille displays support a USB port, those are
implemented with a GoHubs usb serial converter.  The only difference
is that the pID is 0x1200, not 0x1000.

252 for exit_group

This fixes the old-pthreads breakage i can reproduce.

the fix is to only do the thread-group exit-completion logic in case of
thread-groups.

This is another step to have better threading support under Linux, it
implements the sys_exit_group() system call.

It's a straightforward extension of the generic 'thread group' concept,
which extension also comes handy to solve a number of problems when
implementing POSIX threads.

POSIX exit() [the C library function] has the following semantics: all
thread have to exit and the waiting parent has to get the exit code that
was specified for the exit() function.  It also has to be ensured that
every thread has truly finished its work by the time the parent gets the
notification.  The exit code has to be propagated properly to the parent
thread even if not the thread group leader calls the exit() function.

Normal single-thread exit is done via the pthread_exit() function, which
calls sys_exit().

Previous incarnations of Linux POSIX threads implementations chose the
following solution: send a 'thread management' signal to the thread
group leader via tkill(), which thread goes around and kills every
thread in the group (except itself), then calls sys_exit() with the
proper exit code.  Both old libpthreads and NGPT use this solution.

This works to a certain degree, unless a userspace threading library
uses the initial thread for normal thread work [like the new
libpthreads], which 'work' can cause the initial thread to exit
prematurely.

At this point the threading library has to catch the group leader in
pthread_exit() and has to keep the management thread 'hanging around'
artificially, waiting for the management signal. Besides being slightly
confusing to users ('why is this thread still around?') even this variant
is unrobust: if the initial thread is killed by the kernel (SIGSEGV or any
other thread-specific event that triggers do_exit()) then the thread goes
away without the thread library having a chance to intervene.

the sys_exit_group() syscall implements the mechanism within the kernel,
which, besides robustness, is also *much* faster. Instead of the threading
library having to tkill() every thread available, the kernel can use the
already existing 'broadcast signal' capability. (the threading library
cannot use broadcast signals because that would kill the initial thread as
well.)

as a side-effect of the completion mechanism used by sys_exit_group() it
was also possible to make the initial thread hang around as a zombie until
every other thread in the group has exited. A 'Z' state thread is much
easier to understand by users - it's around because it has to wait for all
other threads to exit first.

and as a side-effect of the initial thread hanging around in a guaranteed
way, there are three advantages:

 - signals sent to the thread group via sys_kill() work again. Previously
   if the initial thread exited then all subsequent sys_kill() calls to
   the group PID failed with a -ESRCH.

 - the get_pid() function got faster: it does not have to check for tgid
   collision anymore.

 - procps has an easier job displaying threaded applications - since the
   thread group leader is always around, no thread group can 'hide' from
   procps just because the thread group leader has exited.

 [ - NOTE: the same mechanism can/will also be used by the upcoming
     threaded-coredumps patch. ]

there's also another (small) advantage for threading libraries: eg. the
new libpthreads does not even have any notion of 'group of threads'
anymore - it does not maintain any global list of threads. Via this
syscall it can purely rely on the kernel to manage thread groups.

the patch itself does some internal changes to the way a thread exits: now
the unhashing of the PID and the signal-freeing is done atomically. This
is needed to make sure the thread group leader unhashes itself precisely
when the last thread group member has exited.

(the sys_exit_group() syscall has been used by glibc's new libpthreads
code for the past couple of weeks and the concept is working just fine.)