Re: [PATCH v8] ath9k: let sleep be interrupted when unregistering hwrng

Jason A. Donenfeld
2022-07-19T17:21:50Z

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@redhat.com> 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