[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