linux-kernel - Re: kernel/panic.c warn_slowpath_common printk timestamp weirdness

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

Message-ID: <6895.1279733737@localhost>
Date:	Wed, 21 Jul 2010 13:35:37 -0400
From:	Valdis.Kletnieks@...edu
To:	Arjan van de Ven <arjan@...ux.intel.com>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	linux-kernel@...r.kernel.org
Subject: Re: kernel/panic.c warn_slowpath_common printk timestamp weirdness

On Wed, 21 Jul 2010 06:36:41 PDT, Arjan van de Ven said:
> On 7/21/2010 5:54 AM, Valdis.Kletnieks@...edu wrote:
> > Seeing this on my Dell Latitude.  The timestamps from the 'cut here' and
> > WARNING lines are different even though they're issued by sequential lines 
in
> > panic.c - but then the printk timestamps remain identical even through an
> > *entire second* WARN call.  Is somebody blocking clock interrupts and faili
ng
> > to re-enable them, or is something different going on here?
> >
> > [42875.543219] ------------[ cut here ]------------
> > [42875.544006] WARNING: at lib/plist.c:57 plist_check_head+0x47/0x114()
> >    
> 
> > [42875.544006] WARNING: at lib/plist.c:57 plist_check_head+0x47/0x114()
> > [42875.544006] Hardware name: Latitude E6500
> >    
> 
> > [42882.428016] ------------[ cut here ]------------
> > [42882.428016] WARNING: at lib/plist.c:57 plist_check_head+0x47/0x114()
> >    
> 
> 
> Maybe I have not have had coffee yet.. but I don't see the one second 
> jump in the three cases you mailed...

I mean the value stays nailed down, even through a second WARN call - it outputs
two entire WARN tracebacks with the exact same timestamp.  Even if the same
timestamp gets used for the traceback, I'd expect the next 'cut here' to have a
new timestamp, and the second WARN trace to have a different timestamp as
well.


Content of type "application/pgp-signature" skipped