linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Haren Myneni <haren@linux.ibm.com>
To: Michael Neuling <mikey@neuling.org>
Cc: herbert@gondor.apana.org.au, npiggin@gmail.com,
	hch@infradead.org, oohall@gmail.com, sukadev@linux.vnet.ibm.com,
	linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH V5 06/14] powerpc/vas: Setup thread IRQ handler per VAS instance
Date: Sun, 09 Feb 2020 21:17:36 -0800	[thread overview]
Message-ID: <1581311856.18705.23.camel@hbabu-laptop> (raw)
In-Reply-To: <71427c6b8d8e00461fa27e603db2012e8215f467.camel@neuling.org>

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
> 



  reply	other threads:[~2020-02-10  5:19 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-22  7:56 [PATCH V5 00/14] powerpc/vas: Page fault handling for user space NX requests Haren Myneni
2020-01-22  8:06 ` [PATCH V5 01/14] powerpc/xive: Define xive_native_alloc_irq_on_chip() Haren Myneni
2020-01-22  8:06 ` [PATCH V5 02/14] powerpc/xive: Define xive_native_alloc_get_irq_info() Haren Myneni
2020-01-22  8:07 ` [PATCH V5 03/14] powerpc/vas: Define nx_fault_stamp in coprocessor_request_block Haren Myneni
2020-01-22  8:08 ` [PATCH V5 04/14] powerpc/vas: Alloc and setup IRQ and trigger port address Haren Myneni
2020-01-22  8:08 ` [PATCH V5 05/14] powerpc/vas: Setup fault window per VAS instance Haren Myneni
2020-01-22  8:10 ` [PATCH V5 06/14] powerpc/vas: Setup thread IRQ handler " Haren Myneni
2020-02-07  5:57   ` Michael Neuling
2020-02-10  5:17     ` Haren Myneni [this message]
2020-02-11  4:08       ` Michael Neuling
2020-01-22  8:11 ` [PATCH V5 07/14] powerpc/vas: Register NX with fault window ID and IRQ port value Haren Myneni
2020-01-22  8:12 ` [PATCH V5 08/14] powerpc/vas: Take reference to PID and mm for user space windows Haren Myneni
2020-01-22  8:17 ` [PATCH V5 09/14] powerpc/vas: Update CSB and notify process for fault CRBs Haren Myneni
2020-02-07  5:46   ` Michael Neuling
2020-02-10  5:12     ` Haren Myneni
2020-02-10  9:25       ` Michael Neuling
2020-01-22  8:18 ` [PATCH V5 10/14] powerpc/vas: Print CRB and FIFO values Haren Myneni
2020-01-22  8:21 ` [PATCH V5 11/14] powerpc/vas: Do not use default credits for receive window Haren Myneni
2020-01-22  8:24 ` [PATCH V5 12/14] powerpc/VAS: Return credits after handling fault Haren Myneni
2020-01-22  8:25 ` [PATCH V5 13/14] powerpc/vas: Display process stuck message Haren Myneni
2020-01-22  8:26 ` [PATCH V5 14/14] powerpc/vas: Free send window in VAS instance after credits returned Haren Myneni

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1581311856.18705.23.camel@hbabu-laptop \
    --to=haren@linux.ibm.com \
    --cc=hch@infradead.org \
    --cc=herbert@gondor.apana.org.au \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=mikey@neuling.org \
    --cc=npiggin@gmail.com \
    --cc=oohall@gmail.com \
    --cc=sukadev@linux.vnet.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).