linux-kernel - Re: [PATCH] FUSE: add the async option for the flush/release operation

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:	Wed, 10 Aug 2016 09:50:01 -0700
From:	Enke Chen <enkechen@...co.com>
To:	Miklos Szeredi <miklos@...redi.hu>
Cc:	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
	"Helios Tsoi (hetsoi)" <hetsoi@...co.com>,
	Enke Chen <enkechen@...co.com>
Subject: Re: [PATCH] FUSE: add the async option for the flush/release
 operation

Hi, Miklos:

On 8/9/16 11:52 PM, Miklos Szeredi wrote:
> On Wed, Aug 10, 2016 at 5:26 AM, Enke Chen <enkechen@...co.com> wrote:
>> Hi, Miklos:
>>
>> This patch adds the async option for the flush/release operation in FUSE.
>>
>> The async flush/release option allows a FUSE-based application to be terminated
>> without being blocked in the flush/release operation even in the presence of
>> complex external interactions. In addition, the async operation can be more
>> efficient when a large number of fuse-based files is involved.
>>
>> ---
>> Deadlock Example:
>>
>>     Process A is a multi-threaded application that interacts with Process B,
>>     a FUSE-server.
>>
>>
>>                UNIX-domain socket
>>     App (A)  -----------------------  FUSE-server (B)
>>        |                                   |
>>        |                                   |
>>        |                                   |
>>        +-----------------------------------+
>>                open/flush/release
> 
> Why would the fuse server want to communicate with the app (using
> other than the filesystem)?

In this particular case, the other communication channel is used to coordinate
the allocation (with "open") and de-alocation (with "flush/release") of the
shared memory associated with the opened "file".

In general an application may have special handling for the "flush/release"
operation that involve external interactions with one or more other processes,
and that is where this "async" operation can help.

IMO it would be even better if the "async" operation can be made the default so
folks do not need to worry about this types of deadlocks.  From reading of the
code, it seems that FUSE does "async" release under certain conditions already.

Thanks.  -- Enke