From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.4 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5FCB7C33CB3 for ; Wed, 15 Jan 2020 14:49:52 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 14D5F214AF for ; Wed, 15 Jan 2020 14:49:52 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=ziepe.ca header.i=@ziepe.ca header.b="lqMsQAnX" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 14D5F214AF Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=ziepe.ca Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id B007F8E0006; Wed, 15 Jan 2020 09:49:51 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id AAE838E0003; Wed, 15 Jan 2020 09:49:51 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9C5328E0006; Wed, 15 Jan 2020 09:49:51 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0207.hostedemail.com [216.40.44.207]) by kanga.kvack.org (Postfix) with ESMTP id 866588E0003 for ; Wed, 15 Jan 2020 09:49:51 -0500 (EST) Received: from smtpin12.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with SMTP id 3A9EE2DFA for ; Wed, 15 Jan 2020 14:49:51 +0000 (UTC) X-FDA: 76380152982.12.fly26_73122864d653c X-HE-Tag: fly26_73122864d653c X-Filterd-Recvd-Size: 4838 Received: from mail-qv1-f65.google.com (mail-qv1-f65.google.com [209.85.219.65]) by imf42.hostedemail.com (Postfix) with ESMTP for ; Wed, 15 Jan 2020 14:49:50 +0000 (UTC) Received: by mail-qv1-f65.google.com with SMTP id p2so7449181qvo.10 for ; Wed, 15 Jan 2020 06:49:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ziepe.ca; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=cm5cr0KkaFdqdflwJkN3g1ehM0Qx8fj0jos08WlEqzM=; b=lqMsQAnXFU2Rt1775zA/Y9RpU+D9BdtIlQNRV5pcYeoMkgjr8kts7UivMPIOiL0e5n f10UOZ9PUDQKAc4uo8oxCDRPATVBy+4x0jxET5bAEYC/jRQba05LCqA5mFdDPXZKT+lb OBhCmsKyjTUS/lbEpqcO3YgoacGz12Msnp2wVNAfyc8QXres7PpHjPHKsi2ZXkAcjK24 L01d3NeJlem45mPJulNzAcL08AlMmZ5ok7aIP/9KMn5V/0cTFYAPgtVCpTokVMp8STJN Oyz87SA3j4IaBLjvR+j0YWYGrVgSfqgGG1K43pIfxbDt8YK8NEtcqI1PpfT+bfXVdzrt 6cIA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=cm5cr0KkaFdqdflwJkN3g1ehM0Qx8fj0jos08WlEqzM=; b=oE2ckFQUvSwunL3RRor3NmGLuK1M8Roi7NbTV1jWxSLclXN8hvrBP3M71W2HcJpxxQ OzuSWkpszJvUjUyJ8XKgg1yKA7F6nyL6bsPtJIuYDRzqYiMUOORKUc334M3rBw6zeWUi BRLMuOSDcQSqsx0O9KSnVkS/T297eAx3Rs6h17fE1bugyrf846EuXQ/pMbCf0rDGV05T ZlPkVWvzfmGyZHhbRRYwA63Om5xDR+6df3h1aXVi6hSN4EV4r5PjR/eIDThPIZbAUT95 VYqE+13wP7jRLQRZnKw7Ga/lj3AJZAYNRW+zZwnR9O6uYSr6ahlR+PIocC42odUHj2iv ZEOQ== X-Gm-Message-State: APjAAAUZ9265IxFurIA2q6IDGUsgpVQM1y7oUClLQO7CXqwiWH4Q5xlk oyAqXa4+a6SCqjyKzCx/BiuN1JkJQCY= X-Google-Smtp-Source: APXvYqyFIeQqkTbqfmHkLFxl6XwrUnGz4rIsK+5vF2sMxHxXVPVwnMtL57gUSF9TASMuieCBEj6hKA== X-Received: by 2002:a05:6214:11a8:: with SMTP id u8mr26158641qvv.16.1579099789994; Wed, 15 Jan 2020 06:49:49 -0800 (PST) Received: from ziepe.ca (hlfxns017vw-142-68-57-212.dhcp-dynamic.fibreop.ns.bellaliant.net. [142.68.57.212]) by smtp.gmail.com with ESMTPSA id n32sm9400465qtk.66.2020.01.15.06.49.49 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 15 Jan 2020 06:49:49 -0800 (PST) Received: from jgg by mlx.ziepe.ca with local (Exim 4.90_1) (envelope-from ) id 1irjzQ-0008QI-RY; Wed, 15 Jan 2020 10:49:48 -0400 Date: Wed, 15 Jan 2020 10:49:48 -0400 From: Jason Gunthorpe To: Peter Zijlstra Cc: Christoph Hellwig , linux-xfs@vger.kernel.org, linux-fsdevel@vger.kernel.org, Waiman Long , Thomas Gleixner , Ingo Molnar , Will Deacon , Andrew Morton , linux-ext4@vger.kernel.org, cluster-devel@redhat.com, linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: RFC: hold i_rwsem until aio completes Message-ID: <20200115144948.GB25201@ziepe.ca> References: <20200114161225.309792-1-hch@lst.de> <20200114192700.GC22037@ziepe.ca> <20200115065614.GC21219@lst.de> <20200115132428.GA25201@ziepe.ca> <20200115143347.GL2827@hirez.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200115143347.GL2827@hirez.programming.kicks-ass.net> User-Agent: Mutt/1.9.4 (2018-02-28) X-Bogosity: Ham, tests=bogofilter, spamicity=0.000001, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Wed, Jan 15, 2020 at 03:33:47PM +0100, Peter Zijlstra wrote: > On Wed, Jan 15, 2020 at 09:24:28AM -0400, Jason Gunthorpe wrote: > > > I was interested because you are talking about allowing the read/write side > > of a rw sem to be held across a return to user space/etc, which is the > > same basic problem. > > No it is not; allowing the lock to be held across userspace doesn't > change the owner. This is a crucial difference, PI depends on there > being a distinct owner. That said, allowing the lock to be held across > userspace still breaks PI in that it completely wrecks the ability to > analyze the critical section. I'm not sure what you are contrasting? I was remarking that I see many places open code a rwsem using an atomic and a completion specifically because they need to do the things Christoph identified: > (1) no unlocking by another process than the one that acquired it > (2) no return to userspace with locks held As an example flow: obtain the read side lock, schedual a work queue, return to user space, and unlock the read side from the work queue. If we can make some general primative that addresses this then maybe those open coded places can convert as well? Regards, Jason