linux-kernel - Re: [PATCHSET] FUSE: extend FUSE to support more operations

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: <E1L0eUz-0007D0-Tp@pomaz-ex.szeredi.hu>
Date:	Thu, 13 Nov 2008 16:52:49 +0100
From:	Miklos Szeredi <miklos@...redi.hu>
To:	tj@...nel.org
CC:	miklos@...redi.hu, fuse-devel@...ts.sourceforge.net,
	greg@...ah.com, linux-kernel@...r.kernel.org
Subject: Re: [PATCHSET] FUSE: extend FUSE to support more operations

On Fri, 14 Nov 2008, Tejun Heo wrote:
> Given that the number of in-flight requests are not too high, I think
> linear search is fine for now but switching it to b-tree shouldn't be
> difficult.
> 
> So, pros for req/reply approach.
> 
> * Less context switch per event notification.
> 
> * No need for separate async notification mechanism.
> 
> Cons.
> 
> * More interface impedence matching from libfuse.
> 
> * Higher overhead when poll/select finishes.  Either all outstanding
>   requests need to be cancelled using INTERRUPT whenever poll/select
>   returns or kernel needs to keep persistent list of outstanding polls
>   so that later poll/select can reuse them.  The problem here is that
>   kernel doesn't know when or whether they'll be re-used.  We can put
>   in LRU-based heuristics but it's getting too complex.

Why not just link the outstanding poll requests into a list anchored
in 'fuse_file'?  Easy to reuse, don't care about cancellation.

>  Note that
>   it's different from userland server keeping track.  The same problem
>   exists with userland based tracking but for many servers it would be
>   just a bit in existing structure and we can be much more lax on
>   userland.  ie. actual storage backed files usually don't need
>   notification at all as data is always available, so the amount of
>   overhead is limited in most cases but we can't assume things like
>   that for the kernel.
> 
> Overall, I think being lazy about cancellation and let userland notify
> asynchronously would be better performance and simplicity wise.  What
> do you think?

Lazy cancellation (no cancellation, esentially) sounds good.  But that
works fine with the simplified protocol.

Think of it this way, this is what a poll event would look like with
your scheme:

1) -> POLL-notification
2) <- POLL-req
3) -> POLL-reply (revents)

Notice, how 1) and 2) don't carry _any_ information (the notification
can be spurious, the events in the POLL request is just repeated from
the original request).  All the info is in 3), so I really don't see
any reason why the above would be better than just omitting the first
two steps.

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/