linux-kernel - Re: [PATCH 1/1] serial: mcf: Don't take spinlocks in already protected functions

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Mon, 14 Jun 2010 22:20:30 +0200
From:	Yury Georgievskiy <ygeorgie@...il.com>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/1] serial: mcf: Don't take spinlocks in already
 protected functions

Andrew Morton wrote:
> On Wed,  9 Jun 2010 09:56:26 +0200
> ygeorgie@...il.com wrote:
> 
> > From: Yury Georgievskiy <ygeorgie@...il.com>
> > 
> > Don't take the port spinlock in uart functions where the serial core
> > already takes care of locking/unlocking them.
> > 
> > The code would actually lock up on architectures where spinlocks are
> > implemented.
> > 
> > Also protect calling mcf_rx_chars/mcf_tx_chars in the
> > interrupt handler by the port spinlock and use IRQ_RETVAL
> > to return from isr.
> > 
> 
> Thanks.  Did you runtime test this?

Unfortunately not.

I spotted it as I am now writing the UART driver for Philips SCC2698B integrated circuit
and was looking for serial drivers examples.

And also came across d8d721f4c005f9a69bd1b5d5c6ba99b7e1d464de commit that has patched a
similar problem.

> 
> > @@ -368,11 +354,15 @@ static irqreturn_t mcf_interrupt(int irq, void *data)
> >  	unsigned int isr;
> >  
> >  	isr = readb(port->membase + MCFUART_UISR) & pp->imr;
> > +
> > +	spin_lock(&port->lock);
> >  	if (isr & MCFUART_UIR_RXREADY)
> >  		mcf_rx_chars(pp);
> >  	if (isr & MCFUART_UIR_TXREADY)
> >  		mcf_tx_chars(pp);
> > -	return IRQ_HANDLED;
> > +	spin_unlock(&port->lock);
> > +
> > +	return IRQ_RETVAL(isr);
> >  }
> 
> I think this is a little abusive of IRQ_RETVAL.  If there are some bits
> set in `isr' other than MCFUART_UIR_RXREADY and MCFUART_UIR_TXREADY, we
> claim we handled it, only we didn't.
> 
> Probably the code works OK, but it all seems a bit uncomfortable. 
> Perhaps make it more explicit?
> 

Fair enough.
The code looks more relevant.

> 
> --- a/drivers/serial/mcf.c~serial-mcf-dont-take-spinlocks-in-already-protected-functions-fix
> +++ a/drivers/serial/mcf.c
> @@ -352,17 +352,22 @@ static irqreturn_t mcf_interrupt(int irq
>  	struct uart_port *port = data;
>  	struct mcf_uart *pp = container_of(port, struct mcf_uart, port);
>  	unsigned int isr;
> +	irqreturn_t ret = IRQ_NONE;
>  
>  	isr = readb(port->membase + MCFUART_UISR) & pp->imr;
>  
>  	spin_lock(&port->lock);
> -	if (isr & MCFUART_UIR_RXREADY)
> +	if (isr & MCFUART_UIR_RXREADY) {
>  		mcf_rx_chars(pp);
> -	if (isr & MCFUART_UIR_TXREADY)
> +		ret = IRQ_HANDLED;
> +	}
> +	if (isr & MCFUART_UIR_TXREADY) {
>  		mcf_tx_chars(pp);
> +		ret = IRQ_HANDLED;
> +	}
>  	spin_unlock(&port->lock);
>  
> -	return IRQ_RETVAL(isr);
> +	return ret;
>  }
>  
>  /****************************************************************************/
> _
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/