linux-kernel - Re: [PATCH RT 2/2] fix printk flush of messages

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]

Date:	Mon, 21 May 2012 13:59:24 -0700
From:	Frank Rowand <frank.rowand@...sony.com>
To:	Venkat Subbiah <vsubbiah@...iumnetworks.com>
CC:	"Rowand, Frank" <Frank_Rowand@...yusa.com>,
	"tglx@...utronix.de" <tglx@...utronix.de>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-rt-users@...r.kernel.org" <linux-rt-users@...r.kernel.org>
Subject: Re: [PATCH RT 2/2] fix printk flush of messages

On 05/21/12 13:10, Venkat Subbiah wrote:
> On 05/16/2012 06:09 PM, Frank Rowand wrote:
>> Updates console-make-rt-friendly.patch
>>
>> #ifdef CONFIG_PREEMPT_RT_FULL, printk() output is never flushed by
>> printk() because:
> So this is an issue for printk() itself and is not just for early_printk()?
> 
> 
>     # some liberties taken in this pseudo-code to make it easier to follow
>     printk()
>        vprintk()
>           raw_spin_lock(&logbuf_lock)
>              # increment preempt_count():
>              preempt_disable()
>        result = console_trylock_for_printk()
> 
> As I read it console_trylock_for_printk() is called from printk() but in 
> code it is called from vprintk()

Yes, I goofed on the indentation, starting at console_trylock_for_printk().
It should have been:

   # some liberties taken in this pseudo-code to make it easier to follow
   printk()
      vprintk()
         raw_spin_lock(&logbuf_lock)
            # increment preempt_count():
            preempt_disable()
         result = console_trylock_for_printk()
            retval = 0
            # lock will always be false, because preempt_count() will be >= 1
            lock = ... && !preempt_count()
            if (lock)
               retval = 1
            return retval
         # result will always be false since lock will always be false
         if (result)
            console_unlock()
               # this is where the printk() output would be flushed

Thanks,

Frank

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