Messages in this thread | | | Subject | Re: [PATCH] staging: vchiq: rework remove_event handling | From | Nicolas Saenz Julienne <> | Date | Wed, 12 Dec 2018 17:24:40 +0100 |
| |
On Tue, 2018-12-11 at 15:20 +0100, Arnd Bergmann wrote: > On Tue, Dec 11, 2018 at 1:36 PM Nicolas Saenz Julienne > <nsaenzjulienne@suse.de> wrote: > > On Mon, 2018-12-10 at 22:11 +0100, Arnd Bergmann wrote: > > > @@ -447,26 +444,26 @@ remote_event_wait(VCHIQ_STATE_T *state, > > > REMOTE_EVENT_T *event) > > > } > > > > > > static inline void > > > -remote_event_signal_local(VCHIQ_STATE_T *state, REMOTE_EVENT_T > > > *event) > > > +remote_event_signal_local(wait_queue_head_t *wq, REMOTE_EVENT_T > > > *event) > > > { > > > event->armed = 0; > > > - complete((struct completion *)((char *)state + event- > > > >event)); > > > + wake_up_all(wq); > > > > Shouldn't this just be "wake_up(wq)"? > > I wasn't entirely sure if we could get with more than one thread > waiting > for the wakeup. With the semaphore or completion that would already > be broken because we'd only wake up one of them, but I was hoping > to stay on the safe side with wake_up_all().
You're right. Had a look at the code and there shouldn't be more than one thread waiting. wake_up_all() looks OK.
Reviewed-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
Regards, Nicolas [unhandled content-type:application/pgp-signature] | |