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: Thu, 15 Mar 2012 20:17:12 +0100 (CET) From: Thomas Gleixner <tglx@...utronix.de> To: Al Viro <viro@...IV.linux.org.uk> cc: LKML <linux-kernel@...r.kernel.org>, Linus Torvalds <torvalds@...l.org>, Ingo Molnar <mingo@...e.hu>, Peter Zijlstra <peterz@...radead.org>, Nick Piggin <npiggin@...nel.dk> Subject: Re: [patch 0/5] seqlock consolidation On Thu, 15 Mar 2012, Al Viro wrote: > On Thu, Mar 15, 2012 at 06:55:18PM +0100, Thomas Gleixner wrote: > > > If that's it, I suggest to look for a solution that would express just that... > > > Or do you want something on the reader side as well? > > > > The problem is the reader side. If the reader preempts the writer then > > the only way to make progress is to take the lock, but therefor I need > > to know which lock I should take. > > So just make writers non-preemptable in those sections. Really, the > worst non-deterministic behaviour you get for d_seq ones is memcpy() > of up to ->d_name.len bytes. And on the fs_struct side it's trivial > to reduce the work done in those sections to several comparisons and > assignments. Not even path_get_longterm() needs to be there - see > below for how it can be done: Yeah, path_get_longterm() was what worried me due to dget() taking d_lock, but yeah, I'm happy to avoid all that churn that way. Thanks a lot! > if (fs) { > + int hits = 0; > spin_lock(&fs->lock); > write_seqcount_begin(&fs->seq); > - if (fs->root.dentry == old_root->dentry > - && fs->root.mnt == old_root->mnt) { > - path_get_longterm(new_root); > - fs->root = *new_root; > + hits += replace_path(&fs->root, old_root, new_root); > + hits += replace_path(&fs->pwd, old_root, new_root); Wouldn't it be simpler to just do: + count += replace_path(&fs->root, old_root, new_root); + count += replace_path(&fs->pwd, old_root, new_root); > + write_seqcount_end(&fs->seq); > + while (hits--) { > count++; Instead of that loop ? Thanks, tglx -- 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