Hi Valentin, On Tue, Jul 19, 2022 at 04:15:02PM +0100, Valentin Schneider wrote: > On 11/07/22 13:53, Jason A. Donenfeld wrote: > > Hi Valentin, > > > > On 7/11/22, Valentin Schneider <vschneid@xxxxxxxxxx> wrote: > >> Thanks for the Cc. > >> > >> I'm not hot on the export of wake_up_state(), IMO any wakeup with > >> !(state & TASK_NORMAL) should be reserved to kernel internals. Now, here > >> IIUC the problem is that the patch uses an inline invoking > >> > >> wake_up_state(p, TASK_INTERRUPTIBLE) > >> > >> so this isn't playing with any 'exotic' task state, thus it shouldn't > >> actually need the export. > >> > >> I've been trying to figure out if this could work with just a > >> wake_up_process(), but the sleeping pattern here is not very conforming > >> (cf. 'wait loop' pattern in sched/core.c), AFAICT the signal is used to > >> circumvent that :/ > > > > I don't intend to work on this patch more. If you'd like to ack the > > trivial scheduler change (adding EXPORT_SYMBOL), that'd help, and then > > this can move forward as planned. Otherwise, if you have particular > > opinions about this patch that you want to happen, feel free to pick > > up the patch and send your own revisions (though I don't intend to do > > further review). Alternatively, I'll just send a patch to remove the > > driver entirely. Hopefully you do find this ack-able, though. > > > > I'm not for a blanket wake_up_state() export, however if we *really* need > it then I suppose we could have a wake_up_process_interruptible() exported > and used by __set_notify_signal(). > Thanks for keeping this thread alive. I'll do what you suggest and send a v+1. I think I understand the idea. Let's see how it goes. Jason
