Messages in this thread | | | Subject | Re: [RFC] seqlock,lockdep: Add lock primitives to read_seqbegin(). | From | Peter Zijlstra <> | Date | Tue, 29 Mar 2011 15:14:54 +0200 |
| |
On Sat, 2011-03-26 at 13:12 +0900, Tetsuo Handa wrote: > > But there is still a problem. It seems to me that lockdep checks for this bug > only when a new locking pattern (a locking pattern which was not already added > to lockdep database) is added.
That's how it works. Why is that a problem?
> This freeze can be triggered by running > > while :; do newns /sbin/pivot_root /proc/ /proc/sys/; done > > on one terminal and running > > while :; do /bin/ls -l /proc/*/exe; done > > on another terminal. (The "newns" is a program that unshares the mnt namespace > before execve() using CLONE_NEWNS.) But even after applying the patch above, > lockdep does not show the trace above.
Then you're still missing something.
> lockdep shows the trace above only after I run test programs for TOMOYO (which > causes a locking pattern that was generated by neither > "/sbin/pivot_root /proc/ /proc/sys/" nor "/bin/ls -l /proc/*/exe" to be added > to lockdep database).
And tomoyo manages to close the cycle for some reason.
> I think that we want some method for rechecking already added locking pattern. > Maybe it is run by (e.g.) every 60 seconds. Maybe it is run when stall checking > mechanisms report the possibility of stall. (The sysrq key didn't work after > the freeze occurred.)
I don't get this, why would you need to recheck anything? lockdep does a full analysis on every addition, rechecking when nothing changed should not yield another result.
| |