linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: dillon min <dillon.minfei@gmail.com>
To: Johan Hovold <johan@kernel.org>
Cc: Greg KH <gregkh@linuxfoundation.org>,
	jirislaby@kernel.org, Maxime Coquelin <mcoquelin.stm32@gmail.com>,
	Alexandre TORGUE <alexandre.torgue@foss.st.com>,
	kernel test robot <lkp@intel.com>,
	linux-serial@vger.kernel.org,
	linux-stm32@st-md-mailman.stormreply.com,
	Linux ARM <linux-arm-kernel@lists.infradead.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	kbuild-all@lists.01.org, clang-built-linux@googlegroups.com,
	Gerald Baeza <gerald.baeza@foss.st.com>,
	Erwan Le Ray <erwan.leray@foss.st.com>
Subject: Re: [PATCH v2] serial: stm32: optimize spin lock usage
Date: Fri, 16 Apr 2021 16:56:57 +0800	[thread overview]
Message-ID: <CAL9mu0K4L-vGL1EyYc+p0q7tadQ39-VHcp1nd4gZs_HGKSmP2w@mail.gmail.com> (raw)
In-Reply-To: <YHlMYZCCxL+SS9ye@hovoldconsulting.com>

Hi Johan,

On Fri, Apr 16, 2021 at 4:35 PM Johan Hovold <johan@kernel.org> wrote:
>
> On Tue, Apr 13, 2021 at 07:44:39AM +0800, dillon min wrote:
> > Hi Johan, Erwan
> >
> > It seems still a bit of a problem in the current version, not deadlock
> > but access register at the same time.
> >
> > For driver , we should consider it running under smp, let's think
> > about it for this case:
> >
> > static void stm32_usart_console_write(struct console *co, const char *s,
> >                                       unsigned int cnt)
> > {
> >          .....
> >          local_irq_save(flags);
> >          if (port->sysrq)
> >                     locked = 0;
> >          .....
> >          access register cr1, tdr, isr
> >          .....
> >
> >          local_irq_restore(flags);
> > }
> >
> > if port->sysrq is 1, stm32_usart_console_write() just disable local
> > irq response by local_irq_save(), at the time of access register cr1,
> > tdr, isr. an TXE interrupt raised, for other cores(I know stm32
> > mpu/mcu do not have multi cores, just assume it has), it still has a
> > chance to handle interrupt.  Then there is no lock to protect the uart
> > register.
>
> Right, the sysrq handling is a bit of a hack.
>
> > changes to below, should be more safe:
> >
> > .....
> > if (port->sysrq || oops_in_progress)
> >       locked = spin_trylock_irqsave(&port->lock, flags);
>
> Except that the lock debugging code would detect the attempt at
> recursive locking here and complain loudly on UP.
>
> If you really want to fix this, we have uart_unlock_and_check_sysrq()
> which can be used to defer sysrq processing until the interrupt handler
> has released the lock.

Great, uart_unlock_and_check_sysrq() is fit to fix this. you mean make
the flow like below:

    stm32_usart_threaded_interrupt()
      spin_lock(&port->lock);
      uart_unlock_and_check_sysrq(port, flags);
      ...
      uart_prepare_sysrq_char();
          printk();
            stm32_usart_console_write();
              locked = spin_trylock_irqsave(&port->lock); //only
handle oops, normal case

If so, I will submit v3 as you suggested. thanks.

Best regards.
Dillon,
>
> > else
> >       spin_lock_irqsave(&port->lock, flags);
> >
> > ....
> >
> > if (locked)
> >      spin_unlock_irqrestore(&port->lock, flags);
>
> Johan

      reply	other threads:[~2021-04-16  8:57 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-12  9:31 [PATCH v2] serial: stm32: optimize spin lock usage dillon.minfei
2021-04-12 13:08 ` Johan Hovold
2021-04-12 14:04   ` dillon min
2021-04-12 23:44     ` dillon min
2021-04-15 17:09       ` Erwan LE RAY
2021-04-16  0:06         ` Hua Dillon
2021-04-16  8:51         ` Johan Hovold
2021-04-16  8:35       ` Johan Hovold
2021-04-16  8:56         ` dillon min [this message]

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=CAL9mu0K4L-vGL1EyYc+p0q7tadQ39-VHcp1nd4gZs_HGKSmP2w@mail.gmail.com \
    --to=dillon.minfei@gmail.com \
    --cc=alexandre.torgue@foss.st.com \
    --cc=clang-built-linux@googlegroups.com \
    --cc=erwan.leray@foss.st.com \
    --cc=gerald.baeza@foss.st.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=jirislaby@kernel.org \
    --cc=johan@kernel.org \
    --cc=kbuild-all@lists.01.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-serial@vger.kernel.org \
    --cc=linux-stm32@st-md-mailman.stormreply.com \
    --cc=lkp@intel.com \
    --cc=mcoquelin.stm32@gmail.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).