lkml.org 
[lkml]   [2014]   [Aug]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    SubjectRe: [PATCH 5/6] fuse: fix synchronous case of fuse_file_put()
    From
    On Thu, Aug 21, 2014 at 6:09 PM, Maxim Patlasov <MPatlasov@parallels.com> wrote:
    > If fuse_file_put() is called with sync==true, the user may be blocked for
    > a while, until userspace ACKs our FUSE_RELEASE request. This blocking must be
    > uninterruptible. Otherwise request could be interrupted, but file association
    > in user space remains.
    >
    > Signed-off-by: Maxim Patlasov <mpatlasov@parallels.com>
    > ---
    > fs/fuse/file.c | 4 ++++
    > 1 file changed, 4 insertions(+)
    >
    > diff --git a/fs/fuse/file.c b/fs/fuse/file.c
    > index cd55488..b92143a 100644
    > --- a/fs/fuse/file.c
    > +++ b/fs/fuse/file.c
    > @@ -136,6 +136,10 @@ static void fuse_file_put(struct fuse_file *ff, bool sync)
    > path_put(&req->misc.release.path);
    > fuse_put_request(ff->fc, req);
    > } else if (sync) {
    > + /* Must force. Otherwise request could be interrupted,
    > + * but file association in user space remains.
    > + */
    > + req->force = 1;
    > req->background = 0;
    > fuse_request_send(ff->fc, req);
    > path_put(&req->misc.release.path);
    >


    Some thought needs to go into this: if RELEASE is interrupted, then
    we should possibly allow that, effectively backgrounding the request.

    The synchronous nature is just an optimization and we really don't
    know where we are being interrupted, possibly in a place which very
    much *should* allow interruption.

    Also fuse really should distinguish fatal and non-fatal interruptions
    and handle them accordingly...

    Thanks,
    Miklos


    \
     
     \ /
      Last update: 2014-08-22 16:41    [W:4.250 / U:0.032 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site