8250 serial issues in 2.6.0-test9

From: Bjorn Helgaas (bjorn.helgaas_at_hp.com)
Date: 10/30/03

  • Next message: jlnance_at_unity.ncsu.edu: "Re: Things that Longhorn seems to be doing right" 
    To: Russell King <rmk@arm.linux.org.uk>
Date:	Thu, 30 Oct 2003 14:23:47 -0700

    Hi Russell,

    I know you don't want to mess with the setserial problem I
    tripped over, and that's fine -- it's not a huge issue for
    me. While poking around at it, I noticed a couple other
    issues, which I'll just mention here in case anybody else
    wants to have a go at reworking this code.

    Mostly this mail is just because I'm about to go on vacation,
    and didn't want all my pondering to be completely wasted :-)

    Bjorn

    serial8250_release_port():
            When releasing an RSA port, it looks like serial8250_release_port()
            releases the wrong range ("start + offset" rather than "start")
            for the standard IO port region.

    serial8250_request_port():
            The error path ("ret < 0") leaks memory because request_region()
            kmallocs the new resource, but release_resource() doesn't free it.

    serial8250_config_port():
            Same leak as in serial8250_request_port().

    serial8250_release_port()/serial8250_request_port():
            The problem I mentioned before -- _request_port() doesn't
            ioremap the region that was iounmapped by _release_port(),
            so "setserial /dev/ttyS0 port 0x3f8" causes an oops if
            ttyS0 is an MMIO uart:

                uart_set_info()
                    serial8250_release_port()
                        iounmap(membase);
                        membase = NULL;
                        release_mem_region(mapbase, ...);
                    serial8250_request_port()
                        request_mem_region(mapbase, ...);
                    serial8250_startup()
                        serial_out()
                            port.iotype == IO_MEM, so
                                writeb(value, membase);
                                    oops - null pointer dereference (membase == NULL)

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  • Next message: jlnance_at_unity.ncsu.edu: "Re: Things that Longhorn seems to be doing right"

    Relevant Pages

    • Re: Fwd: Telecom Clock Driver for MPCBL0010 ATCA computer blade
      ... On 10/14/05, Greg KH wrote: ... >> Ick, no, that's a mess. ... To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ ...
      (Linux-Kernel)
    • Re: no DRQ after issuing WRITE
      ... I do not have time to pause and trace/fix the mess. ... However if you both can kindly finger the last kernel when you did not ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Missing /dev/pts?
      ... this point I think except I can't log in via xterm, eterm or ssh. ... Poking around, the most obvious factor is that /dev/pts is empty. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: Fw: [POSSIBLE-BUG] telldir() broken on ext3 dir_indexd directories just after the first entry.
      ... >> IMO it's better to fix the mess all at once to have it weeded out for some ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: IDE bug - was: Re: uncorrectable ext2 errors
      ... my patch turned into a mess of rejects ... > after your layout changes of earlier patches from that series. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)