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:	Thu, 13 Nov 2008 23:29:17 +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

Miklos Szeredi wrote:
> On Thu, 13 Nov 2008, Tejun Heo wrote:
>> We don't need POLL_RELEASE
> 
> What happens on timeout?  Do we just let userspace continue polling
> the file descriptor, and then ignore the notification?

Yeap, spurious notifications don't cause any problems.

>>  but we still need POLL-reply (to request) to
>> send revents.  We can put that into notification too.  Hmmm... Yeah,
>> that could be simpler for FUSE servers.  I'll venture that way.
> 
> Then in fact the notification could just become the reply:
> 
> <- POLL-request (sent with request_send_nowait())
> ...
> -> POLL-reply  (calls req->end())
> 
> So there won't even be a need to implement notification (we'll need
> that for other things in the future) simplifying things even further.
> Even if we want to cancel the request because of a timeout, that could
> be done with the existing INTERRUPT request.

poll/select/epoll can poll on massive number of files.  I don't think
it's wise to have that many outstanding requests.  FUSE currently uses
linear list to match replies to requests and libfuse will consume one
thread per each poll if implemented like other requests.  It can be made
asynchronous from libfuse tho.

I kind of like the original implementation tho.  The f_ops->poll
interface is designed to be used like ->poll returning events if
available immediately and queue for later notification as necessary.
Notification is asynchronous and can be spurious (this actually comes
pretty handy for low level implementation).  When notified, upper layer
queries the same way using ->poll.  This is quite convenient for low
level implementation as the actual logic of poll can live in ->poll
proper while notifications can be scattered around places where events
can occur.

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/