Date:  Fri Sep 13 06:24:23 PDT 2002
Workarea:  dhcp212.munich.sgi.com:/home/hch/repo/ptools/linux-2.5-xfs
Author:  hch
Merged by:  hch
Merged mods:  2.4.x-xfs:slinx:127345a

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs


Modid:  2.5.x-xfs:slinx:127345a
linux/fs/xfs/pagebuf/page_buf_locking.c - 1.28
linux/fs/xfs/pagebuf/page_buf.c - 1.58
	- Merge of 2.4.x-xfs:slinx:127345a by hch.
	  Fix up comments:  Pagebuf is only used for metadata nowdays

Date:  Thu Sep 12 20:10:49 PDT 2002
Workarea:  snort.melbourne.sgi.com:/home/nathans/2.5.x-xfs
Author:  nathans
Merged by:  nathans
Merged mods:  2.4.x-xfs:slinx:127321a

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs


Modid:  2.5.x-xfs:slinx:127321a
linux/fs/xfs/linux/xfs_super.c - 1.227
	- Merge of 2.4.x-xfs:slinx:127321a by nathans.
	  tidy up code consistency - same argument formatting throughout and make
	  consistent use of STATIC.

Date:  Wed Sep 11 12:12:31 PDT 2002
Workarea:  stout.americas.sgi.com:/localhome/src/sandeen/2.5.x-xfs/workarea
Merged by:  sandeen
Merged mods:  
2.4.x-xfs:slinx:127120a
2.4.x-xfs:slinx:127147a
Author:  sandeen

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs


Modid:  2.5.x-xfs:slinx:127150a
linux/fs/xfs/linux/xfs_iops.c - 1.180
	- Merge of 2.4.x-xfs:slinx:127120a originally by sandeen on 09/11/02

linux/fs/xfs/linux/xfs_aops.c - 1.4
	- Merge of 2.4.x-xfs:slinx:127147a originally by sandeen on 09/11/02
	  add error checks to linvfs_direct_IO

Date:  Tue Sep 10 14:07:19 PDT 2002
Workarea:  jen.americas.sgi.com:/src/lord/xfs-merge.2.5
Author:  sandeen
Merged by:  lord
Merged mods:  2.4.x-xfs:slinx:127049a

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs


Modid:  2.5.x-xfs:slinx:127049a
linux/fs/xfs/linux/xfs_iops.c - 1.179
	- Merge of 2.4.x-xfs:slinx:127049a by lord.

Date:  Tue Sep 10 09:56:09 PDT 2002
Workarea:  jen.americas.sgi.com:/src/lord/xfs-merge.2.5
Author:  sandeen
Merged by:  lord
Merged mods:  2.4.x-xfs:slinx:127029a

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs


Modid:  2.5.x-xfs:slinx:127029a
linux/fs/xfs/support/debug.c - 1.9
	- Merge of 2.4.x-xfs:slinx:127029a by lord.

into dhcp212.munich.sgi.com:/home/hch/repo/bk/linux-2.5-xfs

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

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

into samba.org:/scratch/anton/linux-2.5_ppc64drivers

into samba.org:/scratch/anton/linux-2.5_ppc64_new

Exporting kbd_pt_regs in keyboard.c.

into samba.org:/scratch/anton/linux-2.5_ppc64_new

of pcspkr.o and another 90 elsewhere in the .o file.

md currently tries to set_capacity() *after* freeing
the gendisk structure.

It also frees the gendisk even when switching to read-only.

That patch open-codes free_mddev (which is only called once)
and cleans all this up.

This is used:
  to iterate all exports when making /proc/fs/nfs/exports
  to find all exports of a client to unexport them.

The first can just as easily be done by iterating the export_table
hash table.

The second is very rarely called and can be done by iterating the
hash table looking for exports for the given client.

Instead of a separate hash table per client we now
have one hash table which includes the client in the key.

Filehandle lookup currently breaks out the interesting pieces of
a filehandle and passes them to exp_get or exp_get_fsid, which put the
pieces back into a filehandle fragment.

We define a new interface "exp_find" which does a lookup based on
a filehandle fragment to avoid this double handling.

In the process, common code in exp_get_key and exp_get_fsid_key is united
into exp_find_key.

Also, filehandle composition now uses the mk_fsid_v? inline functions.

Currently each entry in the export table had two hash chains
going through it, one for hash-by-dev/ino,  One for hash-by-fsid.
This is contrary to the goal of a simple hash table structure.

The two hash-tables per client are replace by one which stores 'exp_key's
which contain the key (as a file handle fragment) and a pointer to the
real export entry.

The export entries are then all stored in a single hash table indexed
by client+vfsmount+dentry;

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.