[uml-devel] Re: Fwd: [PATCH] UML - close host file descriptors properly

[Bodo S. <bst...@fu...>]

Blaisorblade wrote:
> On Thursday 25 November 2004 12:44, Bodo Stroesser wrote:
> 
>>Blaisorblade wrote:
>>
>>>This patch was sent by Jeff for merging in mainline - since you
>>>complained on an earlier version, have you still something to correct in
>>>it?
> 
> 
>>AFAICS, it's the same patch as you have in bb3 with the name
>>"uml-close-all-fds". So, it's OK. To have reboot on SKAS working,
>>fix-reboot-skas is required also.
> 
> Yes, that is in -bb3.
> 
>>>Btw, the reboot problem is not fixed for me - even in -bb3, with your
>>>last patch tarball excluding SYSEMU_SINGLESTEP, rebooting does not always
>>>work.
> 
> 
>>That's bad. On my system, since the patches are applied, I never saw a
>>reboot failing.
> 
> I got the same randomical failure before. And what's more, with the use-va_end 
> cleanup, it *always* crashed (not retested, but going to do this now).
> 
> Without va_end, sometimes (1 on 3 on average, I'd say) I get:
> 
> "Remounting root filesystem read-only.
> Rebooting.
> Restarting system.
> 
> deactivate_all_fds failed, errno = 9
> Segmentation fault"
OK. Let's read the code: if deactivate_all_fds fails, the handler for SIGIO isn't
set to SIG_IGN, since it does return(err) without calling set_handler() (maybe
you call this a bug, but *normally* deactivate_all_fds must not fail). Thus, if
there is a SIGIO in the queue, UML *must* segfault when calling unblock_signals().

The question here is, which fd is in the list active_fds and is invalid?
Could you please change the error output to contain the fd-number?
And before doing the reboot, please get a list of the open fds. This could help to
find out, which driver is having a bug.
> 
> 
>>I have an idea to find out, what happens on your machine.
> 
> Ok, going to test ASAP.
> 
>>First let me