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]

Date:	Fri, 14 Nov 2008 01:00:44 +0900
From:	Tejun Heo <tj@...nel.org>
To:	Miklos Szeredi <miklos@...redi.hu>
CC:	fuse-devel@...ts.sourceforge.net, greg@...ah.com,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCHSET] FUSE: extend FUSE to support more operations

Hello,

Miklos Szeredi wrote:
>> * 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.

Ah, that's the right place.

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

Alrighty then.  I'll convert it.

Thanks.

-- 
tejun
--
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/