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>] [day] [month] [year] [list]
Message-ID: <4D127B78.7060707@codeaurora.org>
Date:	Wed, 22 Dec 2010 14:28:08 -0800
From:	Abhijeet Dharmapurikar <adharmap@...eaurora.org>
To:	linux-kernel@...r.kernel.org
CC:	Andrew Morton <akpm@...ux-foundation.org>,
	Namhyung Kim <namhyung@...il.com>,
	Kees Cook <kees.cook@...onical.com>,
	James Morris <jmorris@...ei.org>, Ingo Molnar <mingo@...e.hu>,
	linux-arm-msm@...r.kernel.org, smuckle@...eaurora.org
Subject: release_console_sem() and disabling interrupts

release_console_sem() disables interrupts while it calls upon the 
console drivers to dump the pending characters. This disabling of 
interrupt is delaying the handling of interrupts leading to weird 
latencies and bugs.

The specific scenario is while resuming, the __log_buf has accumulated 
around 11,000 bytes of characters and resume_console takes for ever to 
send them out. On my system with serial running at 115200 baud it takes 
almost a second to flush 11,000 bytes.

I was thinking about limiting the characters to say N bytes and before 
  the next set of N bytes is sent, we enable interrupts and do the 
spin_lock_irqsave again. Basically spin in the for ( ; ; ) loop until 
all the outstanding bytes are sent in sets of N bytes.

This issue has been brought up many times earlier -
http://www.webservertalk.com/archive242-2006-6-1537307.html
http://www.webservertalk.com/archive242-2007-11-2129981.html

One reason I gather is that we want to prevent interrupts from printing 
unorderly stuff in the __log_buf. But dont interrupts get the 
spin_lock(&logbuf_lock) and then update the log_[end/start], con_start 
etc? If so we wont see unorderly prints in the __log_buf, the spin_lock 
protects those pointers.

Would like ask if limiting the number of characters per loop in 
release_console_sem() is a good idea.

Thanks
Abhijeet

Sent by an Employee of the Qualcomm Innovation Center, Inc. The Qualcomm 
Innovation Center, Inc is a member of code aurora forum.
--
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ