[prev in list] [next in list] [prev in thread] [next in thread] 

List:       fuse-devel
Subject:    Re: [fuse-devel] write vs getattr/lookup file size update race in
From:       Miklos Szeredi <miklos () szeredi ! hu>
Date:       2007-08-30 17:28:49
Message-ID: E1IQnp3-0001Fd-00 () dorka ! pomaz ! szeredi ! hu
[Download RAW message or body]

> So we'd finally have something like:
> 
> new field in fuse_conn:
> u64 version
> 
> new fields in fuse_inode:
> u64 version
> int(?) written
> 
> write:
> spin_lock(&fc->lock)
> inode->written++
> spin_unlock(&fc->lock)
> ... write request, i_size update
> spin_lock(&fc->lock)
> inode->version = ++(fc->version)
> inode->written--
> spin_unlock(&fc->lock)
> 
> setattr:
> spin_lock(&fc->lock)
> inode->written++
> spin_unlock(&fc->lock)
> ... setattr request, vmtruncate etc., i_size update
> spin_lock(&fc->lock)
> inode->version = ++(fc->version)
> inode->written--
> spin_unlock(&fc->lock)
> 
> getattr/lookup:
> spin_lock(&fc->lock)
> v1 = fs_version
> spin_unlock(&fc->lock)
> ... getattr/lookup request
> spin_lock(&fc->lock)
> v2 = fs_version
> if((v1 == v2) && !inode->written) {
>     ...update attr
> } else {
>     ...invalidate attr
> }
> spin_unlock(&fc->lock)
> 

Yes, this is what I was thinking about.

> In this solution (with lock still held during attr update/invalidation)
> I don't see any race scenario currently.
> But there is another problem: getattr must return valid attributes, so
> without inode locking it would need to repeat whole action (with
> userspace request) until attributes are valid; and during countinuous
> write it could be many times to complete whole operation without being
> disturbed.

Well, the getattr() request can actually return the attributes it got
from userspace.  Yes, it raced with the write, but that doesn't
matter, the attributes _are_ valid, we just don't know if it is valid
before the write or after.

So the only important thing is to not update the _cached_ attributes
in that case.

Miklos


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
fuse-devel mailing list
fuse-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fuse-devel
[prev in list] [next in list] [prev in thread] [next in thread]