linux-kernel - Re: [PATCH 0/5] fuse: handle release synchronously (v4)

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]

Message-ID: <CAJfpegsaL6zRS-EaB3cd-Uk7nDsZnb0vO07-0W6xfYvAuuB6mA@mail.gmail.com>
Date:	Wed, 1 Oct 2014 05:47:23 +0200
From:	Miklos Szeredi <miklos@...redi.hu>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Anand Avati <avati@...ster.org>,
	Maxim Patlasov <MPatlasov@...allels.com>,
	"open list:FUSE: FILESYSTEM..." <fuse-devel@...ts.sourceforge.net>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 0/5] fuse: handle release synchronously (v4)

On Tue, Sep 30, 2014 at 10:44 PM, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
> On Tue, Sep 30, 2014 at 12:19 PM, Miklos Szeredi <miklos@...redi.hu> wrote:
>>
>> What about flock(2), FL_SETLEASE, etc semantics (which are the sane ones,
>> compared to the POSIX locks shit which mandates release of lock on each close(2)
>> instead of "when all [duplicate] descriptors have been closed")?
>>
>> You have to do that from ->release(), there's no question about that.
>
> We do locks_remove_file() independently on ->release, but yes, it's
> basically done just before the last release.
>
> But it has the *exact* same semantics as release, including very much
> having nothing what-so-ever to do with "last close()".
>
> If the file descriptor is opened for other reasons (ie mmap, /proc
> accesses, whatever), then that delays locks_remove_file() the same way
> it delays release.
>
> None of that has *anothing* to do with "synchronous". Thinking it does is wrong.

Oh, and btw. nfsv4 has a synchronous ->release implementation.
Probably for exactly the same reason Anand and Maxim wants it in their
server.  Note: locks_remove_file() works for local locking, but
distributed filesystems need to release locks and leases in their
->release.

And yes, /proc does temporary ref of file.  But it's an implementation
detail, and should be fixable.  As to mmap, it's almost like dup(2)
regarding the file, we could actually handle it that way and have a
flush at munmap time too.

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/