Received: by 2002:a25:ab43:0:0:0:0:0 with SMTP id u61csp3948189ybi; Mon, 10 Jun 2019 21:12:11 -0700 (PDT) X-Google-Smtp-Source: APXvYqxXn2aXnxRY4rZeG3dcr/oP24VQysj+G3lnmqX0ySmva+KrUHTWYFZnJCA0AIT3A6VvUpOQ X-Received: by 2002:a17:902:aa88:: with SMTP id d8mr65059792plr.73.1560226331520; Mon, 10 Jun 2019 21:12:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1560226331; cv=none; d=google.com; s=arc-20160816; b=QjUUwdWmswdSMaVCUHvXzOiDZ0MBa+r56H7lKe5ErLwYrzRINklc4c74tCOVsYTMjd NWbh2213PHmSxBybfD/sShTZOGR2d+daQLIf7VLxsjyS8JQTorDF0EB6D/srWYjdKKDk idz1Pv1e8WrteHz7XG7V8FqyxUOOL5W43zNVGFD+e/Atazcv5D5nD8/+TQL0YP5FqgRu rXyCFPjdDht8DADfmLTbpLkj0mrJ7v7m5kwD8AsB8/2tQl8hduv6czaV87suVGiXmLdJ hbnz2hDiRJrwnd4rbIIGCX0g+0nkYKmeE+OK3ioRuvASJlXfauCS0WQQm5ittXrHirqj 0gLw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=VllHfPbV7UWREAIgNUf056/AN62kzcWyd5y1ZA/lhhI=; b=eIFRD3vxJP8yJTsDRTVbP9UgGI5x4eCp8iOAjmtbgDvTr+yFQuB3aQHDUrv9PhynZP M+feWB8n4+iX05ZuMwka8auxBTnmTuhRFK3I9Pi3hdVpq/OJQwz4DFq10CrNsVpMIW1s pWjTyoQnk5eUScpWMzSyNHDnqkUqJX8r97bNm2Sq+Ax1ktYmHckQsz5VY94FSXgMOkFh /5OyG4KNTay+7a8/R2htRK85iGpCPSIFtizv6kH5pYufENuDs4HG1TnE7S/9d87fFkuR IbwrTGrhQXvNEjVoyw7FCiPZuaFlMtrsffhmHbRj46kkN/Q44y+GcnThmYxweqiyHugT K5oA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id k186si5547198pgd.148.2019.06.10.21.11.55; Mon, 10 Jun 2019 21:12:11 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726385AbfFKELv (ORCPT + 99 others); Tue, 11 Jun 2019 00:11:51 -0400 Received: from mail105.syd.optusnet.com.au ([211.29.132.249]:48278 "EHLO mail105.syd.optusnet.com.au" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725799AbfFKELv (ORCPT ); Tue, 11 Jun 2019 00:11:51 -0400 Received: from dread.disaster.area (pa49-195-189-25.pa.nsw.optusnet.com.au [49.195.189.25]) by mail105.syd.optusnet.com.au (Postfix) with ESMTPS id 5765E1ED746; Tue, 11 Jun 2019 14:11:43 +1000 (AEST) Received: from dave by dread.disaster.area with local (Exim 4.92) (envelope-from ) id 1haY7R-0004JE-8B; Tue, 11 Jun 2019 14:10:45 +1000 Date: Tue, 11 Jun 2019 14:10:45 +1000 From: Dave Chinner To: Linus Torvalds Cc: Kent Overstreet , Linux List Kernel Mailing , linux-fsdevel , linux-bcache@vger.kernel.org, Dave Chinner , "Darrick J . Wong" , Zach Brown , Peter Zijlstra , Jens Axboe , Josef Bacik , Alexander Viro , Andrew Morton , Tejun Heo Subject: Re: bcachefs status update (it's done cooking; let's get this sucker merged) Message-ID: <20190611041045.GA14363@dread.disaster.area> References: <20190610191420.27007-1-kent.overstreet@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.2 cv=FNpr/6gs c=1 sm=1 tr=0 cx=a_idp_d a=K5LJ/TdJMXINHCwnwvH1bQ==:117 a=K5LJ/TdJMXINHCwnwvH1bQ==:17 a=jpOVt7BSZ2e4Z31A5e1TngXxSK0=:19 a=kj9zAlcOel0A:10 a=dq6fvYVFJ5YA:10 a=7-415B0cAAAA:8 a=m6GSVp5TBz7OGOtiG6UA:9 a=CjuIK1q_8ugA:10 a=biEYGPWJfzWAr4FL6Ov7:22 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jun 10, 2019 at 10:46:35AM -1000, Linus Torvalds wrote: > I also get the feeling that the "intent" part of the six-locks could > just be done as a slight extension of the rwsem, where an "intent" is > the same as a write-lock, but without waiting for existing readers, > and then the write-lock part is just the "wait for readers to be > done". Please, no, let's not make the rwsems even more fragile than they already are. I'm tired of the ongoing XFS customer escalations that end up being root caused to yet another rwsem memory barrier bug. > Have you talked to Waiman Long about that? Unfortunately, Waiman has been unable to find/debug multiple rwsem exclusion violations we've seen in XFS bug reports over the past 2-3 years. Those memory barrier bugs have all been fixed by other people long after Waiman has said "I can't reproduce any problems in my testing" and essentially walked away from the problem. We've been left multiple times wondering how the hell we even prove it's a rwsem bug because there's no way to reproduce the inconsistent rwsem state we see in the kernel crash dumps. Hence, as a downstream rwsem user, I have relatively little confidence in upstream's ability to integrate new functionality into rwsems without introducing yet more subtle regressions that are only exposed by heavy rwsem users like XFS. As such, I consider rwsems to be extremely fragile and are now a prime suspect whenever see some one-off memory corruption in a structure protected by a rwsem. As such, please keep SIX locks separate to rwsems to minimise the merge risk of bcachefs. Cheers, Dave. -- Dave Chinner david@fromorbit.com