mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Matthew Wilcox <matthew@wil.cx>
To: Amol Lad <amol@verismonetworks.com>
Cc: linux kernel <linux-kernel@vger.kernel.org>,
	kernel Janitors <kernel-janitors@lists.osdl.org>
Subject: Re: [KJ] [PATCH] drivers/serial/dz.c: Remove	save_flags()/cli()/restore_flags()
Date: Mon, 16 Oct 2006 07:23:27 -0600	[thread overview]
Message-ID: <20061016132326.GE22289@parisc-linux.org> (raw)
In-Reply-To: <1160983732.19143.420.camel@amol.verismonetworks.com>

On Mon, Oct 16, 2006 at 12:58:52PM +0530, Amol Lad wrote:
> Replaced save_flags()/cli()/restore_flags() pair with spin_lock
> alternatives.
> 
> For this case, I believe spin lock plays no role but I also do not have
> a better way.

I think there's a better way.  Here's the full stretch covered by that:

        save_flags(flags);
        cli();

#ifndef CONFIG_SERIAL_DZ_CONSOLE
        /* reset the chip */
        dz_reset(&dz_ports[0]);
#endif

        /* order matters here... the trick is that flags
           is updated... in request_irq - to immediatedly obliterate
           it is unwise. */
        restore_flags(flags);

Now, we can obviously move the junk inside the ifdef:

#ifndef CONFIG_SERIAL_DZ_CONSOLE
        save_flags(flags);
        cli();

        /* reset the chip */
        dz_reset(&dz_ports[0]);

        restore_flags(flags);
#endif

Now, there's only one other place that dz_reset is called from, and to
be honest, it looks like it's missing some locking too.  Looking at the
other uses of spin_lock within this file, we can see that it's used to
protect the DZ_ ports.

So I think a better patch would look like this:

diff --git a/drivers/serial/dz.c b/drivers/serial/dz.c
index 8a98aae..de7a0b1 100644
--- a/drivers/serial/dz.c
+++ b/drivers/serial/dz.c
@@ -661,6 +661,8 @@ static void __init dz_init_ports(void)
 
 static void dz_reset(struct dz_port *dport)
 {
+       unsigned long flags;
+       spin_lock_irqsave((&dport->port.lock, flags);
        dz_out(dport, DZ_CSR, DZ_CLR);
 
        while (dz_in(dport, DZ_CSR) & DZ_CLR);
@@ -670,6 +672,7 @@ static void dz_reset(struct dz_port *dpo
 
        /* enable scanning */
        dz_out(dport, DZ_CSR, DZ_MSE);
+       spin_unlock_irqrestore((&dport->port.lock, flags);
 }
 
 #ifdef CONFIG_SERIAL_DZ_CONSOLE
@@ -783,19 +786,11 @@ int __init dz_init(void)
 
        dz_init_ports();
 
-       save_flags(flags);
-       cli();
-
 #ifndef CONFIG_SERIAL_DZ_CONSOLE
        /* reset the chip */
        dz_reset(&dz_ports[0]);
 #endif
 
-       /* order matters here... the trick is that flags
-          is updated... in request_irq - to immediatedly obliterate
-          it is unwise. */
-       restore_flags(flags);
-
        if (request_irq(dz_ports[0].port.irq, dz_interrupt,
                        IRQF_DISABLED, "DZ", &dz_ports[0]))
                panic("Unable to register DZ interrupt");

But looking at the driver, there's some places we're missing locking.

In dz_set_mctrl(), we read-modify-write DZ_TCR without holding a lock.
We also do that in dz_console_setup(), but I suspect we're guaranteed
by higher levels not to race with anything.

I suspect it can't hit us in practice (due to the dz driver being for
hardware that's UP only, but maybe with preemption, it could bite
us ...), but there's no locking in the interrupt handler.  I think
dz_transmit_chars() needs locking against dz_console_putchar(), for
example.

Anyway, that's enough to be going on with.

  reply	other threads:[~2006-10-16 13:23 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-10-16  7:28 Amol Lad
2006-10-16 13:23 ` Matthew Wilcox [this message]
2006-10-16 14:01   ` [KJ] " Amol Lad

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=20061016132326.GE22289@parisc-linux.org \
    --to=matthew@wil.cx \
    --cc=amol@verismonetworks.com \
    --cc=kernel-janitors@lists.osdl.org \
    --cc=linux-kernel@vger.kernel.org \
    /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

all inboxes | Powered by JetHome®