2013/2/7 J. Bruce Fields bfields@fieldses.org:
On Thu, Feb 07, 2013 at 06:32:38PM +0400, Pavel Shilovsky wrote:
2013/2/7 J. Bruce Fields bfields@fieldses.org:
On Thu, Feb 07, 2013 at 01:53:46PM +0400, Pavel Shilovsky wrote:
Nothing prevents it. If somebody grabbed a share mode lock on a file before we call deny_lock_file, we simply close this file and return -ETXTBSY.
But leave the newly-created file there--ugh.
We can't grab it before atomic_open because we don't have an inode there.
If you can get the lock while still holding the directory i_mutex can't you prevent anyone else from looking up the new file until you've gotten the lock?
Hm..., seems you are right, I missed this part: mutex_lock lookup_open -> atomic_open -> deny_lock_file mutex_unlock
that means that nobody can open and of course set flock on the newly created file (because flock is done through file descriptor). So, it should be fine to call flock after f_ops->atomic_open in atomic_open function. Thanks.
Whether that works may also depend on how the new dentry is set up? If it's hashed before you call flock then I suppose it's already visible to others.
It seems it should be hashed in f_ops->atomic_open() (at least cifs and nfs do it this way). In do_last when we do an ordinary open, we don't hit parent i_mutex if lookup is succeeded through lookup_fast. lookup_fast can catch newly created dentry and set it's share mode before atomic_open codepath hits deny_lock_file.
Also, I noted that: atomic open does f_ops->atomic_open and then it processes may_open check; if may_open fails, the file is closed and open returns with a error code (but file is created anyway) . I think there is no difference between this case and the situation with deny_lock_file there.