[patch 0/4] Cleanup file_count usage

[Ravikiran G Thirumalai <kiran@in.ibm.com>]

This patchset is an attempt to cleanup some bogus and some not so bogus 
reads to struct file.f_count of the vfs from various subsystems in the 
kernel. This patchset doesn't cleanup uses of f_count completely;
Geting rid of all reads to f_count was suggested by Viro during the discussion
on kref based lockfree fd management sometime back.

This cleans up:
1. Wrong usage of f_count in .open and .release routines of some file
   systems
2. Error messages and warnings based on reads to f_count
3. Redundant check based on file_count in the vfs
4. Usage of file_count in hugetlb to report number of attaches

Patchset to follow.

What remains:
1. Hack to return error code to user space at last close through file_count
   check at the driver's flush routine.  This hack is used in scsi/st.c,
   scsi/osst.c and coda/file.c to return error code through .flush() 
   (Although it is doubtful if applications check for error during close(2)).
   Kai has a patch to cleanup scsi/st.c.  I will make patches to move last 
   close code from .flush() to .release() in the coda filesystem if no one 
   objects to it.  Not sure if you can do anything on errors at close...
   Suggestions on alternatives welcome.
2. Read to f_count at drivers/net/ppp_generic.c:
   The PPPIOCDETACH ioctl is failed if the device fd is duped and
   being polled by another process -- which is determined by a read
   to f_count.  The comments in the code indicate that the PPPIOCDETACH 
   ioctl should be junked and userland can use a workaround
   by closing the fd and reopening /dev/ppp.  I can make a patch to junk
   PPPIOCDETACH, but is it okay to break binary compatibility? Paul?
3. Usage of file_count in the AF_UNIX garbage collector (unix_gc)

Thanks,
Kiran