Messages in this thread | | | Date | Mon, 19 Nov 2007 22:00:45 +0100 | From | Milan Broz <> | Subject | Re: 2.6.24-rc2-mm1: kcryptd vs lockdep |
| |
Torsten Kaiser wrote: > On Nov 19, 2007 8:56 AM, Ingo Molnar <mingo@elte.hu> wrote: >> * Torsten Kaiser <just.for.lkml@googlemail.com> wrote: ... > Above this acquire/release sequence is the following comment: > #ifdef CONFIG_LOCKDEP > /* > * It is permissible to free the struct work_struct > * from inside the function that is called from it, > * this we need to take into account for lockdep too. > * To avoid bogus "held lock freed" warnings as well > * as problems when looking into work->lockdep_map, > * make a copy and use that here. > */ > struct lockdep_map lockdep_map = work->lockdep_map; > #endif > > Did something trigger this anyway? > > Anything I could try, apart from more boots with slub_debug=F?
Please could you try which patch from the dm-crypt series cause this ? (agk-dm-dm-crypt* names.)
I suspect agk-dm-dm-crypt-move-bio-submission-to-thread.patch because there is one work struct used subsequently in two threads... (io thread already started while crypt thread is processing lockdep_map after calling f(work)...)
(btw these patches prepare dm-crypt for next patchset introducing async cryptoapi, so there should be no functional changes yet.)
Milan -- mbroz@redhat.com
- 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/
| |