lkml.org 
[lkml]   [2017]   [Feb]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [PATCH v3 0/2] iov_iter: allow iov_iter_get_pages_alloc to allocate more pages per call
On Wed, Feb 8, 2017 at 6:54 AM, Al Viro <viro@zeniv.linux.org.uk> wrote:
> 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...

Added comment.

> 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...

Goes back to v2.6.15 (commit fd72faac95d7 "[PATCH] FUSE: atomic
create+open"). Didn't make sense back then, and it doesn't now.
Fixed.

> Another thing: am I right assuming that ff->nodeid will be the same
> for all ff over given inode (== get_node_id(inode))?

Yes. Except for cuse, where it's zero.

> What about ff->fh?
> Is that a per-open thing, or will it be identical for all opens of the same
> inode?

A per-open thing (opaque identifier used by userspace fs to identify
the open file)

Thanks,
Miklos

\
 
 \ /
  Last update: 2017-02-08 12:10    [W:0.755 / U:0.308 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site