Received: by 2002:a05:6a10:17d3:0:0:0:0 with SMTP id hz19csp398083pxb; Wed, 14 Apr 2021 19:05:56 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzY79bJ5RZ3AKXDYkkKDr37sRlzIyY/qUPaN6SGi8R4cK22AjXM4uvMJeT8nLL/F/PWzuhg X-Received: by 2002:a17:907:2d9f:: with SMTP id gt31mr967245ejc.463.1618452356673; Wed, 14 Apr 2021 19:05:56 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1618452356; cv=none; d=google.com; s=arc-20160816; b=p01vnkr5ptJg6CfzDaY5W5rKeFdu9/t5aiNuFBZvyDoXRD8lHoIU5yH2qk7Qoy21CC dfIUwnbVv256Y67S94CMEUm0eiSSl863owlaPk4jeDdbIPrXNO8g2K9iClbnLfdSKuj+ dFENK4bsPkQ+HJcst8o1CvM6YMwyZGpDL9o8EOFVlK9a0FTi5LhFfRD4t2vLLPsltsWs Yq2FEBEAxiLSoeY1jntBiG4KyYk4qK9Gsic8sNef+5wOcU8skvktZqyLjZEjxnAPx9FY LfkhzLDVhToEGIAwTY+pFaeTo5FAzz1QmWDbVfK0V7Utd4AnXZ5dgzDX25AMPQb2eiVZ 7xYg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=lH3eoHHjFzkvANkrbNDRCvOIGCjJL2L1Au4xor6Q7k0=; b=dTDJ6VMGr/xHUusstlQ4KEHjjsSMqDVBD++04oP0efa++9UEM9MAu4WrpUeUdb3lCf XozipUMpu8Ml97s143F0BdW5tgGhzB62QTsdu8HnjQMURtK+qec7QxLBxaiOhjN5LmEy Bmw47SHH2fb1Rh5zRhZZ59+HTmC/lgsFMmDLU3ej3wqwFaJcquauAfpwyBrCONVoWhi3 54H/mA4+Md2qYsPmVxSqME5xq+g17M3krPNtpBXUJEE1UgwUv0hxY7PxRqRFsYUkFIDQ lm0a71mZ6nm7r1V8SdpxwKXi3WpX7HUxjUX2swehI2dYzwchmNwx5HcnRUyKstMNKPvy werg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id nb19si1092404ejc.427.2021.04.14.19.05.29; Wed, 14 Apr 2021 19:05:56 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229450AbhDOCFt (ORCPT + 99 others); Wed, 14 Apr 2021 22:05:49 -0400 Received: from mail105.syd.optusnet.com.au ([211.29.132.249]:48290 "EHLO mail105.syd.optusnet.com.au" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229449AbhDOCFr (ORCPT ); Wed, 14 Apr 2021 22:05:47 -0400 Received: from dread.disaster.area (pa49-181-239-12.pa.nsw.optusnet.com.au [49.181.239.12]) by mail105.syd.optusnet.com.au (Postfix) with ESMTPS id 4C0FC1043F1E; Thu, 15 Apr 2021 12:05:21 +1000 (AEST) Received: from dave by dread.disaster.area with local (Exim 4.92.3) (envelope-from ) id 1lWrNg-008UKw-J2; Thu, 15 Apr 2021 12:05:20 +1000 Date: Thu, 15 Apr 2021 12:05:20 +1000 From: Dave Chinner To: Matthew Wilcox Cc: Jan Kara , linux-fsdevel@vger.kernel.org, linux-ext4@vger.kernel.org, linux-xfs@vger.kernel.org, Ted Tso , Christoph Hellwig , Amir Goldstein Subject: Re: [PATCH 2/7] mm: Protect operations adding pages to page cache with i_mapping_lock Message-ID: <20210415020520.GI63242@dread.disaster.area> References: <20210413105205.3093-1-jack@suse.cz> <20210413112859.32249-2-jack@suse.cz> <20210414000113.GG63242@dread.disaster.area> <20210414222531.GZ2531743@casper.infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210414222531.GZ2531743@casper.infradead.org> X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.3 cv=YKPhNiOx c=1 sm=1 tr=0 cx=a_idp_f a=gO82wUwQTSpaJfP49aMSow==:117 a=gO82wUwQTSpaJfP49aMSow==:17 a=kj9zAlcOel0A:10 a=3YhXtTcJ-WEA:10 a=7-415B0cAAAA:8 a=8hQybC9s4a2M7SgXXjwA:9 a=CjuIK1q_8ugA:10 a=biEYGPWJfzWAr4FL6Ov7:22 Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org On Wed, Apr 14, 2021 at 11:25:31PM +0100, Matthew Wilcox wrote: > On Wed, Apr 14, 2021 at 10:01:13AM +1000, Dave Chinner wrote: > > > + if (iocb->ki_flags & IOCB_NOWAIT) { > > > + if (!down_read_trylock(&mapping->host->i_mapping_sem)) > > > + return -EAGAIN; > > > + } else { > > > + down_read(&mapping->host->i_mapping_sem); > > > + } > > > > We really need a lock primitive for this. The number of times this > > exact lock pattern is being replicated all through the IO path is > > getting out of hand. > > > > static inline bool > > down_read_try_or_lock(struct rwsem *sem, bool try) > > { > > if (try) { > > if (!down_read_trylock(sem)) > > return false; > > } else { > > down_read(&mapping->host->i_mapping_sem); > > } > > return true; > > } > > > > and the callers become: > > > > if (!down_read_try_or_lock(sem, (iocb->ki_flags & IOCB_NOWAIT))) > > return -EAGAIN; > > I think that should be written: > > if (!iocb_read_lock(iocb, &rwsem)) > return -EAGAIN; > > and implemented as: > > static inline int iocb_read_lock(struct kiocb *iocb, struct rwsem *sem) > { > if (iocb->ki_flags & IOCB_NOWAIT) > return down_read_trylock(sem) ? 0 : -EAGAIN; > return down_read_killable(sem); > } Yup, we already have done that with xfs_ilock_iocb(), but my point is that this "non blocking try lock or lock" pattern is slowly being used in more places than just IOCB_NOWAIT situations. e.g. We use if for IOMAP_NOWAIT locking in XFS, too, and ISTR other places where optimisitic locking is used are replicating it, too. Hence my suggestion that is moved up into the locking primitives, not merely have context specific wrappers added... Cheers, Dave. -- Dave Chinner david@fromorbit.com