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

[Jim Cromie <jim.cromie@gmail.com>]

Ingo Molnar wrote:
> * Jim Cromie <jim.cromie@gmail.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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/