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: <1260731835.2612.21.camel@localhost>
Date:	Sun, 13 Dec 2009 14:17:15 -0500
From:	Trond Myklebust <trond.myklebust@....uio.no>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	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, 2009-12-13 at 11:07 -0800, Linus Torvalds wrote: 
> 
> On Sun, 13 Dec 2009, Trond Myklebust wrote:
> > 
> > The main remaining problem area is that of file locking (i.e. anything
> > that references inode->i_flock). I've started work on that, but a couple
> > of higher interrupts have prevented me from pulling it all together in
> > time for this merge window...
> 
> I'm pretty sure we've had at least two trees with the file locking code 
> fixed, but NFS in a status of "unknown".
> 
> If I recall correctly, the file locking code itself is not that hard: 
> we've done it without the kernel lock in the past (long long ago), and the 
> lock usage doesn't nest (or at least it didn't at some point back then ;). 
> In fact, I think we even do the actual lock data structure allocations 
> outside of the kernel lock exactly because we at one time had a patch that 
> used a spinlock for protection of the lists.

After the current set of patches, have been merged by you, the only
stuff that will continue to rely on nested BKL will be lockd. I can fix
that up in the next cycle.

> (Again, not only my memory, but the code itself may have bitrotted in the 
> meantime, of course).

Agreed. I'm not saying that it's hard. I'm just saying that I ran out of
time due to other commitments.

Cheers
  Trond

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