linux-kernel - Re: + doc-lockdep-design-explain-display-of-state-bits.patch added to -mm tree

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: <451564A9.5030208@gmail.com>
Date:	Sat, 23 Sep 2006 10:45:29 -0600
From:	Jim Cromie <jim.cromie@...il.com>
To:	Ingo Molnar <mingo@...e.hu>
CC:	Linux kernel <linux-kernel@...r.kernel.org>
Subject: Re: + doc-lockdep-design-explain-display-of-state-bits.patch added
 to -mm tree

Ingo Molnar wrote:
> * Jim Cromie <jim.cromie@...il.com> wrote:
>
>   
>   
>> btw '?' carries *is this really what you want ?* connotations.  Is 
>> that intended ? If not, maybe '=' is better..  2 lines --> 'both'
>>     
>
> well i dont see '=' any better than '?'.
>
>   
let me rephrase.

for someone who knows intimately what they mean, how the flags are 
rendered is unimportant.

but for someone who is looking to understand what lockdep 
errors/messages mean,
they may look for hints in the the choice of flag-char, which could 
convey 'severity'

! - something went bang, oh shit
* - splatted on landing
? - huh?  - did you mean to do this ?
_ - blank, unspecified ..

It could be that making any such inferences is looking for hints that 
dont exist,
otoh - if some messages are more severe, it would make sense to connote 
that in the
choice of symbols to represent the flags/states.

IOW, were I to find a lockdep errmsg with {--??} vs {--..} in dmesg,
would it warrant any extra attention (as in *fix-me-first*) ?  or just 
investigated



>>> [ btw.: truly '....' locks are candiates for optimization, as they 
>>>  unnecessarily disable interrupts in process context. ]
>>>       
>> is that a future optimization, needing another pair of 
>> functions/macros ?
>>     
>
> it means they dont really have to be spin_lock_irq()/spin_unlock_irq() 
> uses but spin_lock()/spin_unlock() would be enough. (but it's not 
> guaranted - some rare codepath that has not triggered yet might use 
> those locks from IRQ context, at which point the irq-safety in process 
> context is compulsory.)
>   

Thats helpful. So continuing this line..
If joe-hacker were to falsely optimize, and then trigger the rare path 
later,
would the lockdep errmsg contain {  ??}, or do I oversimplify ?

> 	Ingo
>
>   

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