Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754251AbbBQT1V (ORCPT ); Tue, 17 Feb 2015 14:27:21 -0500 Received: from mail-yk0-f177.google.com ([209.85.160.177]:43718 "EHLO mail-yk0-f177.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753906AbbBQT1T (ORCPT ); Tue, 17 Feb 2015 14:27:19 -0500 Date: Tue, 17 Feb 2015 14:27:14 -0500 From: Jeff Layton To: Linus Torvalds Cc: "J. Bruce Fields" , "Kirill A. Shutemov" , linux-fsdevel , Linux Kernel Mailing List , Christoph Hellwig , Dave Chinner , Sasha Levin Subject: Re: [GIT PULL] please pull file-locking related changes for v3.20 Message-ID: <20150217142714.36ed9ddb@tlielax.poochiereds.net> In-Reply-To: References: <20150209055540.2f2a3689@tlielax.poochiereds.net> <20150216133200.GB3270@node.dhcp.inet.fi> <20150216090054.62455465@tlielax.poochiereds.net> <20150217190844.GC27900@fieldses.org> X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.25; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1659 Lines: 43 On Tue, 17 Feb 2015 11:13:39 -0800 Linus Torvalds wrote: > On Tue, Feb 17, 2015 at 11:08 AM, J. Bruce Fields wrote: > > > > I agree that it's weird, but I think it's what we're stuck with. > > And if by "weird" you mean "flock is really not a well-defined or sane > interface", I'll agree with you. > > That said, I'm not at all sure about the "we're stuck with it". We can > improve the semantics without anybody noticing, because it's not like > anybody could *depend* on the weaker semantics - they needed > particular races and timings to hit anyway. > > Linus I'm not sure we want to make that change here and now though. That's something that really ought to be approached a bit more carefully since we might break some userland apps that depend on this (admittedly strange) behavior. What about this instead then? - leave the "drop the spinlock" thing in place in flock_lock_file for v3.20 - change locks_remove_flock to just walk the list and delete any locks associated with the filp being closed That should pretty closely mirror the behavior of v3.19. Yes, that leaves the bug in place where you can end up with two locks associated with the same filp, but that's the way it has worked now for years. I'm leery of changing that behavior in the context of this set. -- Jeff Layton -- 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/