linux-kernel - Re: [GIT PATCH] TTY patches for 2.6.33-git

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]

Message-ID: <alpine.LFD.2.00.0912131116360.13952@localhost.localdomain>
Date:	Sun, 13 Dec 2009 11:19:33 -0800 (PST)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Trond Myklebust <trond.myklebust@....uio.no>
cc:	Frederic Weisbecker <fweisbec@...il.com>,
	Ingo Molnar <mingo@...e.hu>,
	Thomas Gleixner <tglx@...utronix.de>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Greg KH <gregkh@...e.de>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	linux-kernel@...r.kernel.org
Subject: Re: [GIT PATCH] TTY patches for 2.6.33-git

On Sun, 13 Dec 2009, Trond Myklebust wrote:

> On Sun, 2009-12-13 at 20:04 +0100, Frederic Weisbecker wrote: 
> > In the above cases we have the following comment:
> > 
> > /* Protect inode->i_flock using the BKL */
> > 
> > And really it doesn't seem to protect anything else,
> > fortunately it is acquired in a short path.
> 
> As I said in my reply, this is the tough one, because the BKL protection
> is imposed by the VFS locking scheme used in fs/locks.c.
> 
> There is a similar dependency imposed upon fs/lockd/

Note that since NFS seems to be the only one who really cares, I think the 
appropriate course of action is to just replace the BKL - preferably with 
a spinlock that you just drop before you do anything that blocks.

Not only does the BKL already do that (so the locking doesn't change), but 
I think most _users_ of the BKL actually already do the explicit dropping 
of the lock (rather than the implicit one done by schedule()) because it's 
already been a scalability issue and we've had some history of trying 
alternative approaches that didn't do that whole auto-dropping anyway 
(whether those alternate approaches be semaphores or spinlocks).

So don't worry about the "imposed by the VFS" thing. I think you can 
fairly easily change the VFS side. 

			Linus
--
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/