Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1330099
| From | Ingo Molnar <mingo@kernel.org> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: + kernel-locking-lockdepc-make-lockdep-initialize-itself-on-demand.patch added to -mm tree |
| Date | 2016-02-09 12:20 +0100 |
| Message-ID | <r0euR-3fE-15@gated-at.bofh.it> (permalink) |
| References | <qY0mm-7ok-27@gated-at.bofh.it> <qY0mm-7ok-25@gated-at.bofh.it> <qY8MW-4sb-9@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
* Andrew Morton <akpm@linux-foundation.org> wrote: > > and it should happen in a well defined place, not be opportunistic (and > > relatively random) like this, making it dependent on config options and > > calling contexts. > > That's an unusable assertion, sorry. > > Initializing lockdep in the above manner guarantees that it is initialized > before it is used. It is *much* more reliable than "try to initialize it before > some piece of code which hasn't even been written yet tries to take a lock". So I didn't like that patch because it called into lockdep in a messy way, without having any real knowledge about whether it's safe to do. Should lockdep ever grow more complex initialization, such a solution could break in subtle ways. I prefer clearly broken code with static dependencies over context-dependent broken code with dynamic call ordering/dependencies. Fortunately we don't have to apply the patch: > The conceptual problem is that if some piece of code does spin_lock_init() or > DEFINE_SPINLOCK(), that lock isn't necessarily initialized yet. The conceptual problem is that the data structures are not build time initialized - but the hlist conversion patch solves that problem nicely! So I'm a happy camper. Thanks, Ingo
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Re: + kernel-locking-lockdepc-make-lockdep-initialize-itself-on-demand.patch added to -mm tree Ingo Molnar <mingo@kernel.org> - 2016-02-03 08:50 +0100
Re: + kernel-locking-lockdepc-make-lockdep-initialize-itself-on-demand.patch added to -mm tree Andrey Ryabinin <aryabinin@virtuozzo.com> - 2016-02-03 10:50 +0100
Re: + kernel-locking-lockdepc-make-lockdep-initialize-itself-on-demand.patch added to -mm tree Ingo Molnar <mingo@kernel.org> - 2016-02-03 10:50 +0100
Re: + kernel-locking-lockdepc-make-lockdep-initialize-itself-on-demand.patch added to -mm tree Andrew Morton <akpm@linux-foundation.org> - 2016-02-03 17:50 +0100
Re: + kernel-locking-lockdepc-make-lockdep-initialize-itself-on-demand.patch added to -mm tree Andrew Morton <akpm@linux-foundation.org> - 2016-02-03 21:50 +0100
Re: + kernel-locking-lockdepc-make-lockdep-initialize-itself-on-demand.patch added to -mm tree Andrew Morton <akpm@linux-foundation.org> - 2016-02-03 22:50 +0100
Re: + kernel-locking-lockdepc-make-lockdep-initialize-itself-on-demand.patch added to -mm tree Andrey Ryabinin <aryabinin@virtuozzo.com> - 2016-02-04 14:20 +0100
Re: + kernel-locking-lockdepc-make-lockdep-initialize-itself-on-demand.patch added to -mm tree Michael Ellerman <mpe@ellerman.id.au> - 2016-02-08 10:40 +0100
Re: + kernel-locking-lockdepc-make-lockdep-initialize-itself-on-demand.patch added to -mm tree Ingo Molnar <mingo@kernel.org> - 2016-02-09 12:10 +0100
Re: + kernel-locking-lockdepc-make-lockdep-initialize-itself-on-demand.patch added to -mm tree Ingo Molnar <mingo@kernel.org> - 2016-02-09 12:20 +0100
Re: + kernel-locking-lockdepc-make-lockdep-initialize-itself-on-demand.patch added to -mm tree Andrew Morton <akpm@linux-foundation.org> - 2016-02-09 21:20 +0100
csiph-web