Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753426AbbBQUR4 (ORCPT ); Tue, 17 Feb 2015 15:17:56 -0500 Received: from mail-ig0-f171.google.com ([209.85.213.171]:37986 "EHLO mail-ig0-f171.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752135AbbBQURy (ORCPT ); Tue, 17 Feb 2015 15:17:54 -0500 MIME-Version: 1.0 In-Reply-To: <20150217151224.2dc31ad8@tlielax.poochiereds.net> References: <20150209055540.2f2a3689@tlielax.poochiereds.net> <20150216133200.GB3270@node.dhcp.inet.fi> <20150216090054.62455465@tlielax.poochiereds.net> <20150217190844.GC27900@fieldses.org> <20150217142714.36ed9ddb@tlielax.poochiereds.net> <20150217151224.2dc31ad8@tlielax.poochiereds.net> Date: Tue, 17 Feb 2015 12:17:53 -0800 X-Google-Sender-Auth: UV9B999lu9KEEPjTApaUaHJk5mw Message-ID: Subject: Re: [GIT PULL] please pull file-locking related changes for v3.20 From: Linus Torvalds To: Jeff Layton Cc: "J. Bruce Fields" , "Kirill A. Shutemov" , linux-fsdevel , Linux Kernel Mailing List , Christoph Hellwig , Dave Chinner , Sasha Levin Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1561 Lines: 34 On Tue, Feb 17, 2015 at 12:12 PM, Jeff Layton wrote: > > I agree that there's no deadlock. I also agree that allowing two > LOCK_EX's (or a LOCK_SH + LOCK_EX) on the file is broken. I'm just > leery on making a user-visible change at this point. I'd prefer to let > something like that soak in linux-next for a while. Umm. The *current* behavior is user-visible. As in "catastrophic bug" user visible. Not just Kirill's report, but the silent "possibly exclusive file locks aren't exclusive". No, we're not delaying fixing this because of concerns of other user-visible behavior. There is absolutely no way other behavior could possibly be *less* catastrophic than data corruption (in user space) due to non-working exclusive locks. > Another possibility is to keep dropping the spinlock, but check to see > if someone set a new lock on the same filp in the loop after that. What would that buy? I agree that replacing the "re-get the spin-lock" with a "goto repeat" to the top (which will re-get the spinlock and then look for new existing locks) would also fix the problem with multiple locks, but it's just more code to do complex stuff that doesn't actually fix anything. Just removing the known buggy code is actually the simpler and safer fix. Linus -- 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/