"Eric W. Biederman" <ebiederm@xxxxxxxxxxxx> writes: > Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> writes: > >> So I'd really like to finish this. Even if we end up with a hack or >> two in signal handling that we can hopefully fix up later by having >> vhost fix up some of its current assumptions. > > > The real sticky widget for me is how to handle one of these processes > coredumping. It really looks like it will result in a reliable hang. > > Limiting ourselves to changes that will only affect vhost, all I can > see would be allowing the vhost_worker thread to exit as soon as > get_signal reports the process is exiting. Then vhost_dev_flush > would need to process the pending work. > Oleg recently pointed out that the trickiest case currently appears to be what happens if someone calls exec, in a process using vhost. do_close_on_exec is called after de_thread, and after the mm has changed. Which means that my idea of moving the work from vhost_worker into vhost_dev_flush can't work. At the point that flush is called it has the wrong mm. Which means the flush or cancel of the pending work needs to happen in the vhost thread, we can't assume there is any other thread available to do the work. What makes this all nice is that the vhost code has vhost_dev_check_owner which ensures only one mm can initiate I/O. Which means file descriptor passing is essentially an academic concern. In the case of both process exit, and exec except for a racing on which piece of code shuts down first there should be no more I/O going into the work queues. But it is going to take someone who understands and cares about vhost to figure out how to stop new I/O from going into the work queues and to ensure that on-going work is dealt with. Eric _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/virtualization
