page fault panic in scioctl and console-kit-daemon

[Alexander Nedotsukov]

Better late than never :-) I am back. I understand your concerns and  
can assure that use-mode code will do right. I changed wchan address  
from system wide cdev pointer to syscons private address. What else  
need to be done to get this checked in and/or will you do that or I  
can proceed myself?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sys_dev_syscons.patch
Type: application/octet-stream
Size: 1934 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20080317/cc65a03f/sys_dev_syscons.obj
-------------- next part --------------



Thanks,
Alexander.

On 23.02.2008, at 2:29, Kostik Belousov wrote:

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