serial core: crash / race condition on unbind

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



When unbinding a serial driver, uart_remove_one_port() clears
uart_state.uart_port:

        state->uart_port = NULL;

If the serial port is still in use (e.g. by getty), uart_close() will be
called later:

        static void uart_close(struct tty_struct *tty, struct file *filp)
        {
                struct uart_state *state = tty->driver_data;
                struct uart_port *uport;

                ...

                if (!state)
                        return;

                uport = state->uart_port;

uport is NULL

                ...

                pr_debug("uart_close(%d) called\n", uport->line);

If debugging is enabled, it will already crash here while dereferencing uport
(this one is easily fixed)

                if (tty_port_close_start(port, tty, filp) == 0)
                        return;

                ...

                uart_flush_buffer(tty);

uart_flush_buffer() will try to obtain the port's spinlock:

        static void uart_flush_buffer(struct tty_struct *tty)
        {
                struct uart_state *state = tty->driver_data;
                struct uart_port *port;

                ...

                port = state->uart_port;

port is NULL

                ...

                spin_lock_irqsave(&port->lock, flags);

Crash!!

It doesn't always crash, though.

Sometimes uart_close() returns after the tty_port_close_start() above,
without a crash (bypassing e.g. the call to uart_change_pm() :-(
Sometimes it crashs in uart_chars_in_buffer(), which also tries to take the
spinlock:
    tty_port_close_start()
        tty_wait_until_sent_from_close()
            tty_wait_until_sent()
                tty_chars_in_buffer()
                    uart_chars_in_buffer()
                        spin_lock_irqsave(&state->uart_port->lock, flags);

I'm not that familiar with the internals of the serial core. Perhaps
uart_close()
should return early if uport is NULL, just like if state is NULL?
However, that means the uart_change_pm(state, UART_PM_STATE_OFF)
is bypassed again.

This is with sh-sci, but I don't think the driver matters.

Thanks for your comments and suggestions!

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Linux PPP]     [Linux FS]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Linmodem]     [Device Mapper]     [Linux Kernel for ARM]

  Powered by Linux