linux-kernel - Re: Uartlite

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 for Android: free password hash cracker in your pocket

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

Date:	Sun, 16 Jan 2011 22:02:06 +0100
From:	Peter Korsgaard <jacmet@...site.dk>
To:	monstr@...str.eu
Cc:	linux-serial@...r.kernel.org, LKML <linux-kernel@...r.kernel.org>
Subject: Re: Uartlite - ulite_transmit

>>>>> "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.

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?

 Michal> ************
 Michal> uart_open(0) called
 Michal> uart_flush_buffer(0) called

-- 
Bye, Peter Korsgaard
--
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/