[PATCH V5 06/14] powerpc/vas: Setup thread IRQ handler per VAS instance
Haren Myneni
haren at linux.ibm.com
Mon Feb 10 16:17:36 AEDT 2020
On Fri, 2020-02-07 at 16:57 +1100, Michael Neuling wrote:
> > /*
> > + * Process CRBs that we receive on the fault window.
> > + */
> > +irqreturn_t vas_fault_handler(int irq, void *data)
> > +{
> > + struct vas_instance *vinst = data;
> > + struct coprocessor_request_block buf, *crb;
> > + struct vas_window *window;
> > + void *fifo;
> > +
> > + /*
> > + * VAS can interrupt with multiple page faults. So process all
> > + * valid CRBs within fault FIFO until reaches invalid CRB.
> > + * NX updates nx_fault_stamp in CRB and pastes in fault FIFO.
> > + * kernel retrives send window from parition send window ID
> > + * (pswid) in nx_fault_stamp. So pswid should be non-zero and
> > + * use this to check whether CRB is valid.
> > + * After reading CRB entry, it is reset with 0's in fault FIFO.
> > + *
> > + * In case kernel receives another interrupt with different page
> > + * fault and CRBs are processed by the previous handling, will be
> > + * returned from this function when it sees invalid CRB (means 0's).
> > + */
> > + do {
> > + mutex_lock(&vinst->mutex);
>
> This isn't going to work.
>
> From Documentation/locking/mutex-design.rst
>
> - Mutexes may not be used in hardware or software interrupt
> contexts such as tasklets and timers.
Initially used kernel thread per VAS instance and later using IRQ
thread.
vas_fault_handler() is IRQ thread function, not IRQ handler. I thought
we can use mutex_lock() in thread function.
>
> Mikey
>
More information about the Linuxppc-dev
mailing list