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: Mon, 14 Sep 2015 11:50:08 +0200 From: Ingo Molnar <mingo@...nel.org> To: Thomas Gleixner <tglx@...utronix.de> Cc: Steven Rostedt <rostedt@...dmis.org>, linux-kernel@...r.kernel.org, linux-rt-users <linux-rt-users@...r.kernel.org>, Carsten Emde <C.Emde@...dl.org>, Sebastian Andrzej Siewior <bigeasy@...utronix.de>, John Kacur <jkacur@...hat.com>, Paul Gortmaker <paul.gortmaker@...driver.com>, Peter Zijlstra <peterz@...radead.org>, Clark Williams <clark.williams@...il.com>, Arnaldo Carvalho de Melo <acme@...hat.com> Subject: Re: [RFC][PATCH RT 0/3] RT: Fix trylock deadlock without msleep() hack * Thomas Gleixner <tglx@...utronix.de> wrote: > > And if we are into getting reference counts, why not solve it at a higher > > level and get a reference count to 'x' to make sure it's safe to use? Then we > > could do: > > > > lock(y->lock); > > retry: > > x = y->x; > > if (!trylock(x->lock)) { > > get_ref(x->count) > > unlock(y->lock); > > lock(x->lock); > > lock(y->lock); > > put_ref(x->count); > > if (y->x != x) { /* Retry if 'x' got dropped meanwhile */ > > unlock(x->lock); > > goto retry; > > } > > } > > > > Or so. > > In the case of dcache::dentry_kill() we probably do not have to take refcounts > and it might be actually counterproductive to do so. y->x, i.e. dentry->parent, > cannot vanish under us, if I understand the life time rules correctly. Ok, that's even better. > Aside of that, yes, I was thinking about a similar scheme for that. I need some > more time to grok all the rules there :) Ok, great! :-) I really don't think we need a new locking primitive - and with something like the above we could improve the code upstream as well and make it scale better in some scenarios, right? Thanks, Ingo -- 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