page fault panic in scioctl and console-kit-daemon

[Kostik Belousov]

On Sat, Feb 23, 2008 at 01:01:59AM +0900, Alexander Nedotsukov wrote:
> 
> On 22.02.2008, at 0:47, Kostik Belousov wrote:
> 
> >On Thu, Feb 21, 2008 at 09:26:16AM +0900, Alexander Nedotsukov wrote:
> >>Hi,
> >>
> >>May I ask to revisit this issue? To me ENXIO is not semantically
> >>correct in this particular case. It also turns out that doing
> >>workaround in userspace may not be that good as we used to think. I
> >>propose is to fix VT_WAITACTIVE so it simply wait for bound device
> >>activation. For my understanding this change should not have any
> >>impact on existing code. I also removed really strange console  
> >>cleanup
> >>bit sticked in a long time ago (see ioctl() part).
> >>It will be nice to see this patch
> >
> >
> >>(successfully tested by our affected users) committed to all  
> >>branches.
> >>
> >>Thanks,
> >>Alexander.
> >
> >I mostly agree with the patch, given it is tested.
> >
> >The first (not important) note is that change of the wait channel from
> >the address of the private structure to the address of the cdev could
> >cause more spurious wakeups then before. I expect you usermode code to
> >deal with it properly.
> Do you know any potential wakeup()s around the kernel? I did not see  
> any spurious wakeups myself nor user reported it so far. However they  
> are not welcome so if it considered to be unsafe we can use address of  
> cdev pointer (&SC_DEV()) which is private to syscons.
Nothing prevents any code in the the kernel from performing wakeup on
any wait channel. Due to tradition, wait channel is usually an address
of some data structure that is owned by the code performing wakeup.
I do not know of any other code that uses cdev address as wait channel,

The issue of spurious wakeup is not very important per se. I think more
essential for the correct operation is the fact that when the user-mode
code is executed, console may already be inactive (again). This is quite
similar to the unintended wakeups.

Does the code handle this ? If yes, I think it shall handle the
wakeups too without any additional actions.

I underline that this is not an objection against the patch.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20080222/6fd96a71/attachment.pgp