On Tue, Feb 07, 2017 at 12:35:54PM +0100, Miklos Szeredi wrote:
> > Another thing: what guarantees that places in writepages-related paths
> > where we store a reference into req->ff won't hit a request with already
> > non-NULL ->ff?
>
> Well, it is set before being sent (queued onto queued_writes or queued on the
> fuse device), but not when queued as secondary request onto an already in-flight
> one. It looks okay to me.
> void fuse_sync_release(struct fuse_file *ff, int flags)
> {
> - WARN_ON(atomic_read(&ff->count) > 1);
> + WARN_ON(atomic_read(&ff->count) != 1);
> fuse_prepare_release(ff, flags, FUSE_RELEASE);
> - __set_bit(FR_FORCE, &ff->reserved_req->flags);
> - __clear_bit(FR_BACKGROUND, &ff->reserved_req->flags);
> - fuse_request_send(ff->fc, ff->reserved_req);
> - fuse_put_request(ff->fc, ff->reserved_req);
> - kfree(ff);
> + fuse_file_put(ff, true);
Umm... At the very least, that deserves a comment re "iput(NULL) is a no-op
and since the refcount is 1 and everything's synchronous, we are fine with
not doing igrab/iput here". There's enough mysteries in that code as it is...
Speaking of mysteries - how can ->private_data ever be NULL in
fuse_release_common()? AFAICS, it's only called from ->release() instances
and those are only called after ->open() or ->atomic_open() on that struct file
has returned 0. On the ->open() side, it means fuse_do_open() having returned
0; on ->atomic_open() one - fuse_create_open() having done the same. Neither
is possible with ->private_data remaining NULL, and I don't see any places
that would modify it afterwards...
Another thing: am I right assuming that ff->nodeid will be the same
for all ff over given inode (== get_node_id(inode))? What about ff->fh?
Is that a per-open thing, or will it be identical for all opens of the same
inode?
