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
| ||
|
Date: Mon, 17 Jan 2011 07:35:34 +0100 From: Michal Simek <monstr@...str.eu> To: Peter Korsgaard <jacmet@...site.dk> CC: linux-serial@...r.kernel.org, LKML <linux-kernel@...r.kernel.org> Subject: Re: Uartlite - ulite_transmit Peter Korsgaard wrote: >>>>>> "Michal" == Michal Simek <monstr@...str.eu> writes: > > Hi, > > Michal> Hi Peter, > Michal> sorry for delay. I had to look at another issue. > > No problem. > > Michal> Below is full log: > Michal> 1. I setup baudrate to 50. (It could be possible to set it up to 0 too) > Michal> That's why I think that doesn't matter what baudrate is setup. > > Michal> 2. You see where ulite_startup is called. It is called only once. > > Ok, good. > > Michal> 3. You see that there is no call __uart_wait_until_sent(). It could be > Michal> called for ASYNC mode. The second thing is __uart_wait_until_sent > Michal> function is checking if tx fifo is empty not circ buffer is empty. > > Yes, that's afaik what that function should do. > > Michal> 4. Next thing is that in uart_close. port->count is 2 which means that > Michal> the executing path is > Michal> if (port->count) { > Michal> spin_unlock_irqrestore(&port->lock, flags); > Michal> goto done; > Michal> } > Michal> which means that there is no chance to call __uart_wait_until_sent > Michal> function anyway. > > And no buffer flushing, so that's fine. > > Michal> 5. I did one modification to add simple while loop till circ buffer is > Michal> empty to the same location to see what happen (timouts are bogus > Michal> values). > > Michal> if (port->count) { > Michal> spin_unlock_irqrestore(&port->lock, flags); > Michal> printk("************ %x %x\n", (&uport->state->xmit)->tail, > Michal> (&uport->state->xmit)->head); > Michal> while (!uart_circ_empty(&uport->state->xmit)) { > Michal> msleep_interruptible(jiffies_to_msecs((uport->timeout - HZ/50))); > Michal> if (signal_pending(current)) > Michal> break; > Michal> if (time_after(jiffies, jiffies + uport->timeout)) > Michal> break; > Michal> } > Michal> printk("************\n"); > Michal> goto done; > Michal> } > > Ok, so this shows that there's still data in the circular buffer when > uart is closed, like expected. > > For me, it all looks normal: > > 1. serial port gets opened, uart_open -> uart_startup -> ulite_startup > gets called, ASYNC_INITIALIZED gets set, circular buffer and hardware > TX fifo cleared. But ASYNC_INITIALIZED is not set. > > 2. Some time later serial port gets opened again, and uart_startup is a > NOP because ASYNC_INITIALIZED is set. No circular buffer / hw fifo > clear. > > 3. serial port gets closed, uart_close is a NOP because port->count > 0 > > 4. serial port gets opened again, NOP like in 2. > > The problem is the uart_flush_buffer() call we see after uart_open() in > 4. If doesn't seem to come from serial_core (only called from uart_close > / uart_hangup), so presumably it comes from the TTY core or > userspace. Could you add a bit more debug to figure out where exactly it > comes from? ok. will do. Thanks, Michal > > Michal> ************ > Michal> uart_open(0) called > Michal> uart_flush_buffer(0) called > -- Michal Simek, Ing. (M.Eng) w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/ Microblaze U-BOOT custodian -- 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/
Powered by blists - more mailing lists