lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Tue, 16 Sep 2014 10:19:21 +0200
From:	Miklos Szeredi <>
To:	Maxim Patlasov <>
Cc:	fuse-devel <>,
	Anand Avati <>,
	Kernel Mailing List <>
Subject: Re: [PATCH 5/6] fuse: fix synchronous case of fuse_file_put()

On Thu, Sep 11, 2014 at 6:14 PM, Maxim Patlasov <> wrote:

> I really need your help to proceed with this patch. Could you please explain
> what those places are where we should allow interruption.
> BTW, as for "just an optimization", I've recently noticed that __fput()
> calls locks_remove_file(). So guarantees provided by the patch-set are on
> the same level as flock(2) behaviour.

SIGKILL trumps that.  At least that's what I think, and that's what
NFS currently does as well, AFAICS.

>> Also fuse really should distinguish fatal and non-fatal interruptions
>> and handle them accordingly...
> And elaborate on this concern, please.

Requests have two states where they stay for any significant amount of
time: PENDING (queued to userspace) and SENT (in userspace).

Currently we do the following for interrupted requests:

   - non-fatal signal: do nothing
   - fatal signal: dequeue and return -EINTR, unless force is set

   - send INTERRUPT request to userspace

This is fine, but fatal interrupts should be able to abort SENT and
forced requests as well without having to wait for the userspace
reply.  This is what I was referring to.

This would not be difficult, were it not for i_mutex and
s_vfs_rename_mutex being held by some operations.   For correctness,
we can't release these while a reply is not received, since the
locking expecations of the userspace filesystem would not be met.
This can be solved by adding shadow locks to fuse that we hold onto
even after the request is interrupted.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists