lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Sun, 10 Dec 2006 00:43:18 -0800 From: Andrew Morton <akpm@...l.org> To: Ingo Molnar <mingo@...e.hu> Cc: vatsa@...ibm.com, Bjorn Helgaas <bjorn.helgaas@...com>, linux-kernel@...r.kernel.org, Myron Stowe <myron.stowe@...com>, Jens Axboe <axboe@...nel.dk>, Dipankar <dipankar@...ibm.com>, Gautham shenoy <ego@...ibm.com> Subject: Re: workqueue deadlock On Sun, 10 Dec 2006 09:26:16 +0100 Ingo Molnar <mingo@...e.hu> wrote: > > * Andrew Morton <akpm@...l.org> wrote: > > > > > Could do, not sure. I'm planning on converting all the locking > > > > around here to preempt_disable() though. > > > > > > please at least use an owner-recursive per-CPU lock, > > > > a wot? > > something like the pseudocode further below - when applied to a data > structure it has semantics and scalability close to that of > preempt_disable(), but it is still preemptible and the lock is specific. > > > > not a naked preempt_disable()! The concurrency rules for data > > > structures changed via preempt_disable() are quite hard to sort out > > > after the fact. (preempt_disable() is too opaque, > > > > preempt_disable() is the preferred way of holding off cpu hotplug. > > well, preempt_disable() is the scheduler's internal mechanism to keep > tasks from being preempted. It is fast but it also has non-nice > side-effect: > > 1) nothing tells us what the connection between preempt-disable and data > structure is. If we let preempt_disable() spread then we'll end up > with a situation like the BKL: all preempt_disable() sections become > one big blob of code with hard-to-define specifications, and if we > take out code from that blob stuff mysteriously breaks. Well we can add some suitably-named wrapper around preempt_disable() to make it obvious why we're calling it. But I haven't noticed any such problem with existing usages. > void cpu_hotplug_lock(void) > { > int cpu = raw_smp_processor_id(); > /* > * Interrupts/softirqs are hotplug-safe: > */ > if (in_interrupt()) > return; > if (current->hotplug_depth++) > return; > current->hotplug_lock = &per_cpu(hotplug_lock, cpu); > mutex_lock(current->hotplug_lock); > } That's functionally equivalent to what we have now, and it isn't working too well. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists