linux-kernel - Re: [git pull] fixes for 3.12-final

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 6 Nov 2013 15:10:04 +0000
From:	Al Viro <viro@...IV.linux.org.uk>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Bruce Fields <bfields@...ldses.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	linux-fsdevel <linux-fsdevel@...r.kernel.org>
Subject: Re: [git pull] fixes for 3.12-final

On Mon, Nov 04, 2013 at 12:53:00AM +0000, Al Viro wrote:

> Maybe...  OTOH, that crap really needs doing something only with nfsd on
> filesystems with 64bit inode numbers living on 32bit hosts (i_ino is
> unsigned long, not u32 right now).  Hell knows; I'm somewhat concerned about
> setups like e.g. ext2 on VIA C7 mini-itx boxen (and yes, I do have such
> beasts).  FWIW, the whole area around iget_locked() needs profiling;
> in particular, I really wonder if this
>                 spin_lock(&inode->i_lock);
>                 if (inode->i_ino != ino) {
>                         spin_unlock(&inode->i_lock);
>                         continue;
>                 }
>                 if (inode->i_sb != sb) {
>                         spin_unlock(&inode->i_lock);
>                         continue;
>                 }
> makes any sense; both ->i_ino and ->i_sb are assign-once and assigned before
> the sucker gets inserted into hash, so inode_hash_lock provides all barriers
> we need here.  Sure, we want to grab ->i_lock for this:
>                 if (inode->i_state & (I_FREEING|I_WILL_FREE)) {
>                         __wait_on_freeing_inode(inode);
>                         goto repeat;
>                 }
>                 __iget(inode);
>                 spin_unlock(&inode->i_lock);
> but that's once per find_inode{_fast,}(), not once per inode in hash chain
> being traversed...
> 
> And picking them from dentries is fine, but every time we associate an inode
> with dentry, we end up walking the hash chain in icache and the time we
> spend in that loop can get sensitive - we are holding a system-wide lock,
> after all (and the way it's implemented right now, we end up touching
> a cacheline in a bunch of struct inode for no good reason).

FWIW, not taking ->i_lock there definitely looks like a good thing.  As for
64bit ->i_ino itself...  Looks like the main problem is the shitload of
printks - the actual uses of ->i_ino are fine, but these suckers create
a lot of noise.  So for now I'm going with Bruce's variant; 64bit i_ino
doesn't look too bad (even on i386, actually), but it'll have to wait
until 3.14.  Too noisy and late in this cycle...
--
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/