linux-kernel - Re: Spinlock debugging

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] [thread-next>] [day] [month] [year] [list]

Message-Id: <1158068628.6780.9.camel@localhost.localdomain>
Date:	Tue, 12 Sep 2006 14:43:48 +0100
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	Andrew Bird <ajb@...eresystems.co.uk>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: Spinlock debugging

Ar Maw, 2006-09-12 am 08:47 +0100, ysgrifennodd Andrew Bird:
> Alan
> 	thanks that did the trick. 
> One further question, on the later kernels 2.6.17+, I don't have low_latency 
> set. Can I still guarantee that after calling tty_flip_buffer_push() I have 
> made space in the tty for my buffer? For example, is this legal? 

It makes no guarantee in any kernel.

In the new tty case however tty_buffer_request_room() will only fail if
you have 64K queued or the box is completely out of atomic memory and
also doing stuff like dropping network packets and console keystrokes.

So all you need in your IRQ handler is

	if (tty_insert_flip_string(tty, buf, size))
		tty_flip_buffer_push(tty);

the rest will occur automatically. Hinting with tty_buffer_request_room
may improve performance for some workloads (notably virtualized uarts)
or when using DMA but otherwise the above should be fine.

Most existing drivers were a straight conversion so at the moment try
too hard.

-
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/