lkml.org 
[lkml]   [2004]   [Nov]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    Subject[patch 0/4] Cleanup file_count usage
    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
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 14:08    [W:2.756 / U:0.436 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site