On Thu, 13 Nov 2008, Tejun Heo wrote:

quoted text
> Hello, Miklos.

>

> Miklos Szeredi wrote:

> >   0006-FUSE-implement-unsolicited-notification.patch

> >   0007-FUSE-implement-poll-support.patch

> >

> > This would be nice, but...  I don't really like the fact that it uses

> > the file handle.  Could we have a separate "poll handle" that is

> > returned in the POLL reply?

>

> Eh... I replied too early for this.  I'm now trying to convert it to its

> own handle but there is a rather serious problem.  It's usually much

> easier to have the entity to be waken up registered before calling

> ->poll so that ->poll can use the same notification path from ->poll ans

> for later.

>

> However, if we allocate poll handle from ->poll and tell it to kernel

> via reply, it creates two problem.  1. the entity which is to be waken

> up can't be registered prior to calling ->poll as there's nothing to

> identify it, 2. the interval from reply write and in-kernel polled

> entity registration must be made atomic so that no notification can come

> through inbetween.  #1 means that ->poll can't call the same

> notification path from ->poll itself and #2 means that there needs to be

> special provision from dev.c::fuse_dev_write() to

> file.c::fuse_file_poll() so that atomicity can be guaranteed.  Both of

> which can be done but I'm not really sure whether using a separate

> handle would be a good idea even with the involved cost.

Yeah, I see the problems.
> Why do you think using separate poll handle would be better?  And do you

quoted text
> still think the overhead is justifiable?

Because it would be a change in the semantics of the file handle.

Previously it was just an opaque cookie that the kernel stored for the

filesystem, not making any assumptions about it (like uniqueness).
OK, we can say that if the filesystems wants to implement poll, it has

to make the file handle unique.  Also now the filesystem (or

something) has to deal with races between poll notification and

reuse of the file handle (release/open).
With a new poll handle we'd have more room to properly deal with these

without overloading the file handle with extra requirements.
How about this: the poll handle is allocated by the kernel, not by the

filesystem.  This guarantees uniqueness, so the filesystem cannot get

this wrong.  Releasing the poll handle is still tricky, there could be

various races... only the userspace filesystem knows if it has no

outstanding notificiatons on a poll handle, so the release has to come

after all outstanding notifications have been ack'ed.  Something like

this:
(userspace <- kernel)
<- POLL-request(pollhandle) (alloc handle)

-> POLL-reply

...

-> POLL-notification(pollhandle)

<- POLL-ack

...

<- POLL_RELEASE(pollhandle)

-> POLL_RELEASE-reply (free handle)
Thanks,

Miklos

--

unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

the body of a message to majordomo@vger.kernel.org

More majordomo info at  http://vger.kernel.org/majordomo-info.html

Please read the FAQ at  http://www.tux.org/lkml/