linux-kernel - Re: [PATCH 5/6] fuse: fix synchronous case of fuse_file

lists.openwall.net		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 linux-cve-announce 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 <miklos@...redi.hu>
To:	Maxim Patlasov <mpatlasov@...allels.com>
Cc:	fuse-devel <fuse-devel@...ts.sourceforge.net>,
	Anand Avati <avati@...ster.org>,
	Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 5/6] fuse: fix synchronous case of fuse_file_put()

On Thu, Sep 11, 2014 at 6:14 PM, Maxim Patlasov <mpatlasov@...allels.com> 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:

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

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

Thanks,
Miklos
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/