Skip to content
  • Al Viro's avatar
    make default ->i_fop have ->open() fail with ENXIO · bd9b51e7
    Al Viro authored
    
    
    As it is, default ->i_fop has NULL ->open() (along with all other methods).
    The only case where it matters is reopening (via procfs symlink) a file that
    didn't get its ->f_op from ->i_fop - anything else will have ->i_fop assigned
    to something sane (default would fail on read/write/ioctl/etc.).
    
    	Unfortunately, such case exists - alloc_file() users, especially
    anon_get_file() ones.  There we have tons of opened files of very different
    kinds sharing the same inode.  As the result, attempt to reopen those via
    procfs succeeds and you get a descriptor you can't do anything with.
    
    	Moreover, in case of sockets we set ->i_fop that will only be used
    on such reopen attempts - and put a failing ->open() into it to make sure
    those do not succeed.
    
    	It would be simpler to put such ->open() into default ->i_fop and leave
    it unchanged both for anon inode (as we do anyway) and for socket ones.  Result:
    	* everything going through do_dentry_open() works as it used to
    	* sock_no_open() kludge is gone
    	* attempts to reopen anon-inode files fail as they really ought to
    	* ditto for aio_private_file()
    	* ditto for perfmon - this one actually tried to imitate sock_no_open()
    trick, but failed to set ->i_fop, so in the current tree reopens succeed and
    yield completely useless descriptor.  Intent clearly had been to fail with
    -ENXIO on such reopens; now it actually does.
    	* everything else that used alloc_file() keeps working - it has ->i_fop
    set for its inodes anyway
    
    Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
    bd9b51e7