Re: page fault panic in scioctl and console-kit-daemon

On Mon, Mar 17, 2008 at 10:02:39PM +0900, Alexander Nedotsukov wrote:
> 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?
Just commit it. If needed, add Approved by: kib.

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