Messages in this thread | | | Date | Fri, 29 Jul 2022 10:48:51 -0600 | From | Tycho Andersen <> | Subject | Re: [PATCH] sched: __fatal_signal_pending() should also check PF_EXITING |
| |
On Fri, Jul 29, 2022 at 11:15:28AM -0500, Eric W. Biederman wrote: > Tycho Andersen <tycho@tycho.pizza> writes: > > > On Fri, Jul 29, 2022 at 12:04:17AM -0500, Eric W. Biederman wrote: > >> Tycho Andersen <tycho@tycho.pizza> writes: > >> > >> > On Thu, Jul 28, 2022 at 11:12:20AM +0200, Oleg Nesterov wrote: > > > >> >> Finally. if fuse_flush() wants __fatal_signal_pending() == T when the > >> >> caller exits, perhaps it can do it itself? Something like > >> >> > >> >> if (current->flags & PF_EXITING) { > >> >> spin_lock_irq(siglock); > >> >> set_thread_flag(TIF_SIGPENDING); > >> >> sigaddset(¤t->pending.signal, SIGKILL); > >> >> spin_unlock_irq(siglock); > >> >> } > >> >> > >> >> Sure, this is ugly as hell. But perhaps this can serve as a workaround? > >> > > >> > or even just > >> > > >> > if (current->flags & PF_EXITING) > >> > return; > >> > > >> > since we don't have anyone to send the result of the flush to anyway. > >> > If we don't end up converging on a fix here, I'll just send that > >> > patch. Thanks for the suggestion. > >> > >> If that was limited to the case you care about that would be reasonable. > >> > >> That will have an effect on any time a process that opens files on a > >> fuse filesystem exits and depends upon the exit path to close it's file > >> descriptors to the fuse filesystem. > >> > >> > >> I do see a plausible solution along those lines. > >> > >> In fuse_flush instead of using fuse_simple_request call an equivalent > >> function that when PF_EXITING is true skips calling request_wait_answer. > >> Or perhaps when PF_EXITING is set uses schedule_work to call the > >> request_wait_answer. > > > > I don't see why this is any different than what I proposed. It changes > > the semantics to flush happening out-of-order with task exit, instead > > of strictly before, which you point out might be a problem. What am I > > missing? > > What you proposed skips the flush operation entirely.
Sorry, I wasn't clear. I was thinking of roughly similar to what you were, returning from request_wait_answer() early if we have PF_EXITING. Sounds like we agree that it shouldn't be an issue. I'll give it a test and send out a patch Monday.
Tycho
| |