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=-0.9 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS 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 EB598C433E0 for ; Tue, 16 Jun 2020 22:36:29 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id A1DDC207E8 for ; Tue, 16 Jun 2020 22:36:29 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="cGmxIWLF" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A1DDC207E8 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 3E4FA6B0003; Tue, 16 Jun 2020 18:36:29 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 394B66B000A; Tue, 16 Jun 2020 18:36:29 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2A8996B000D; Tue, 16 Jun 2020 18:36:29 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0061.hostedemail.com [216.40.44.61]) by kanga.kvack.org (Postfix) with ESMTP id 120656B0003 for ; Tue, 16 Jun 2020 18:36:29 -0400 (EDT) Received: from smtpin30.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id BE7D88245571 for ; Tue, 16 Jun 2020 22:36:28 +0000 (UTC) X-FDA: 76936535256.30.cows09_5a0182226e02 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin30.hostedemail.com (Postfix) with ESMTP id 9813F18031B21 for ; Tue, 16 Jun 2020 22:36:28 +0000 (UTC) X-HE-Tag: cows09_5a0182226e02 X-Filterd-Recvd-Size: 4722 Received: from us-smtp-1.mimecast.com (us-smtp-delivery-1.mimecast.com [207.211.31.120]) by imf44.hostedemail.com (Postfix) with ESMTP for ; Tue, 16 Jun 2020 22:36:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1592346987; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=pjA7zgwqv80y4xmAR3IWOMUOAyE53XKax4l1DtqqEck=; b=cGmxIWLFerDvmbXx9wGIMeV5qMwmY3+Vdf3tc8EjWZawWwMkXzWRwUX2wIM+hUs+ubjH9r JbpnGLG9iGe8fL6LRrD9HPxPCIXKXVSMkNvTKSv3KYw+hKuxH565kv4Omy8lEWJn7ZZHyl Rk2uAlwgeRwCQ2AYEdLUaShoAbHpLig= Received: from mail-ot1-f71.google.com (mail-ot1-f71.google.com [209.85.210.71]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-95-LVEzPQo1NUyCZlK1H0X0ww-1; Tue, 16 Jun 2020 18:36:25 -0400 X-MC-Unique: LVEzPQo1NUyCZlK1H0X0ww-1 Received: by mail-ot1-f71.google.com with SMTP id t17so149168otp.22 for ; Tue, 16 Jun 2020 15:36:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=pjA7zgwqv80y4xmAR3IWOMUOAyE53XKax4l1DtqqEck=; b=JvSG8MpaMn36GSLgGk1e58SXZJRG6nbRPRg4UVU1Es32bEA3gQTpmtJzAkIkurgs5k nSdeYOaBw9mhDO5eEdf1lDqA+pW/dl5z7TQHsLYfWgz2P33Z0OJX59xncBqrBIpEgwEb 6Vqvq6d8rHCvuPyzR7evlyNoIKKK5c9h2zMzYvYl4pT0pIfBU53uln56uUNKWYHhivjS 1OkBDRFSIg5dju8VX9HX3whU6o9UCemhyROH+VW9G8sX8LqO9AmwxoKmEoTQiImnEy7e Pyw7P2f9MpiGcvJNrhpzkFl2qt7wOXcdndBcnnf7W0bQM8m/kgIZuVHTjLK6+v7GFT9l XvrQ== X-Gm-Message-State: AOAM5311IDrYnnhPEtgg9TNAAgveTty6QRJLcFRcUWPI1buDf6makH2U B2kfdmRILGpIB+EcJ12qlhH1xyUneCxsW42GYyDoFp5NN/5j6jS/R09bqixOJlgQc9a3dTk0ZRl OlLjgLi3fm3jduxVD89XUdJ3ZP5Q= X-Received: by 2002:a9d:6e96:: with SMTP id a22mr4427250otr.58.1592346984856; Tue, 16 Jun 2020 15:36:24 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyoYNEk859HKJnIJ4XSJZ0fYGYB8IyuHx9XmftKrB9TO1HP0sg3cpUFv1zd47ilgV+zJ3II6JUZaM7vtE9AC3A= X-Received: by 2002:a9d:6e96:: with SMTP id a22mr4427227otr.58.1592346984642; Tue, 16 Jun 2020 15:36:24 -0700 (PDT) MIME-Version: 1.0 References: <20200414150233.24495-1-willy@infradead.org> <20200414150233.24495-17-willy@infradead.org> In-Reply-To: <20200414150233.24495-17-willy@infradead.org> From: Andreas Gruenbacher Date: Wed, 17 Jun 2020 00:36:13 +0200 Message-ID: Subject: Re: [Cluster-devel] [PATCH v11 16/25] fs: Convert mpage_readpages to mpage_readahead To: Matthew Wilcox Cc: Andrew Morton , linux-xfs@vger.kernel.org, Junxiao Bi , William Kucharski , Joseph Qi , John Hubbard , LKML , linux-f2fs-devel@lists.sourceforge.net, cluster-devel , Linux-MM , ocfs2-devel@oss.oracle.com, linux-fsdevel , linux-ext4 , linux-erofs@lists.ozlabs.org, Christoph Hellwig , linux-btrfs@vger.kernel.org, Steven Whitehouse , Bob Peterson X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 9813F18031B21 X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam01 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: Am Mi., 15. Apr. 2020 um 23:39 Uhr schrieb Matthew Wilcox : > From: "Matthew Wilcox (Oracle)" > > Implement the new readahead aop and convert all callers (block_dev, > exfat, ext2, fat, gfs2, hpfs, isofs, jfs, nilfs2, ocfs2, omfs, qnx6, > reiserfs & udf). The callers are all trivial except for GFS2 & OCFS2. This patch leads to an ABBA deadlock in xfstest generic/095 on gfs2. Our lock hierarchy is such that the inode cluster lock ("inode glock") for an inode needs to be taken before any page locks in that inode's address space. However, the readahead address space operation is called with the pages already locked. When we try to grab the inode glock inside gfs2_readahead, we'll deadlock with processes that are holding that inode glock and trying to lock one of those same pages. One possible solution is to use a trylock on the glock in gfs2_readahead, and to give up the readahead in case of a locking conflict. I have no idea how this is going to affect performance. Any other ideas? Thanks, Andreas