On Mon, Aug 04, 2008 at 04:38:16PM -0700, Arjan van de Ven wrote:I reported it to Peter. If you see David's email, I guess it can be implied that I wasn't the only one aware that prove-locking made certain systems non functional, I thought it was widespread knowledge maybe not. It's amazing that things seem to have improved on that side, it surely gives me more confidence in prove-locking! So let me understand better: your opinion is that all of lockdep is useful, not just the AB BA detection? By reading the source again after 11 months to me it still looks check_deadlock() only has knowledge of the current context. It loops over the task struct checking all the locks of the current task! Combine the great feature that check_deadlock provides, with crashing at boot, and I hope that better explains my feeling about lockdep-prove-locking. This check_deadlock() thing is the real core of my dislike of prove-locking! The check_noncircular part I totally agree it's useful now that I see it works differently than check_deadlock (when I read it last time I thought it worked the same as check_deadlock). check_noncircular being useful doesn't automatically make check_deadlock useful. And incidentally it's exactly this check_deadlock part that is trapping on my code and that is now requiring silly changes to the common code (the ones I did) or to make the common code even more complex (what Peter is planning I guess). --
| Jeremy Fitzhardinge | Re: [RFC 00/15] x86_64: Optimize percpu accesses |
| Vladislav Bolkhovitin | Re: Integration of SCST in the mainstream Linux kernel |
| Mike Galbraith | Re: regression: CD burning (k3b) went broke |
git: | |
| Jarek Poplawski | [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| Gerrit Renker | [PATCH 27/37] dccp: Integration of dynamic feature activation - part 2 (server side) |
| Linus Torvalds | Re: [GIT]: Networking |
| Michael Grollman | Re: 8169 Intermittent ifup Failure Issue With RTL8102E Chipset in Intel's New D945... |
