Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754007AbZLMTRy (ORCPT ); Sun, 13 Dec 2009 14:17:54 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753987AbZLMTRx (ORCPT ); Sun, 13 Dec 2009 14:17:53 -0500 Received: from mail-out1.uio.no ([129.240.10.57]:39286 "HELO mail-out1.uio.no" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1753962AbZLMTRw (ORCPT ); Sun, 13 Dec 2009 14:17:52 -0500 Subject: Re: [GIT PATCH] TTY patches for 2.6.33-git From: Trond Myklebust To: Linus Torvalds Cc: Ingo Molnar , Thomas Gleixner , Alan Cox , Andrew Morton , Greg KH , Peter Zijlstra , linux-kernel@vger.kernel.org In-Reply-To: References: <20091212101032.GB25286@elte.hu> <20091212023603.93768833.akpm@linux-foundation.org> <20091212214235.31429790@lxorguk.ukuu.org.uk> <20091213065844.GA20244@elte.hu> <20091213181726.GA14558@elte.hu> <1260729195.2612.7.camel@localhost> Content-Type: text/plain; charset="UTF-8" Date: Sun, 13 Dec 2009 14:17:15 -0500 Message-Id: <1260731835.2612.21.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.28.0 (2.28.0-2.fc12) Content-Transfer-Encoding: 7bit X-UiO-Ratelimit-Test: rcpts/h 17 msgs/h 2 sum rcpts/h 22 sum msgs/h 2 total rcpts 2031 max rcpts/h 27 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 7BE470456589CD8B61048B318D2309ACFB87EE6A X-UiO-SPAM-Test: remote_host: 68.40.206.115 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 2 total 40 max/h 3 blacklist 0 greylist 0 ratelimit 0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1562 Lines: 37 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/