From patchwork Fri Jun 19 09:39:14 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Andreas Gruenbacher X-Patchwork-Id: 11613611 Return-Path: Received: from mail.kernel.org (pdx-korg-mail-1.web.codeaurora.org [172.30.200.123]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 0FDE292A for ; Fri, 19 Jun 2020 09:39:41 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id EC85B20786 for ; Fri, 19 Jun 2020 09:39:40 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="SU0jvVAG" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731364AbgFSJjj (ORCPT ); Fri, 19 Jun 2020 05:39:39 -0400 Received: from us-smtp-2.mimecast.com ([207.211.31.81]:43632 "EHLO us-smtp-delivery-1.mimecast.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726196AbgFSJjj (ORCPT ); Fri, 19 Jun 2020 05:39:39 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1592559577; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding; bh=owa0qFAPsKpu74jXgvEbAGd5tDvX5jYwWR6WKxTC83E=; b=SU0jvVAGJOt5au1unmW8s4PfsgoPCEeJ3czkr5wFQs6EWbnq+zDCyYy3wdQeX9Sbpy1fSl N22xaH33U+Vwc6IR6IwmQnGZwUch/DnnzbeO4J1sL4Wa7U9k0+b9GMsNonry899L0n2vKj H1MP93obGwERR7pQcHl0vCmFMEFMA/s= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-263-E2DQ6Q59N3WWMbSJVCOn4A-1; Fri, 19 Jun 2020 05:39:29 -0400 X-MC-Unique: E2DQ6Q59N3WWMbSJVCOn4A-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id BE7B8107B265; Fri, 19 Jun 2020 09:39:26 +0000 (UTC) Received: from max.home.com (unknown [10.40.195.140]) by smtp.corp.redhat.com (Postfix) with ESMTP id 4E9A15D9E8; Fri, 19 Jun 2020 09:39:18 +0000 (UTC) From: Andreas Gruenbacher To: Matthew Wilcox , Linus Torvalds Cc: Andreas Gruenbacher , Andrew Morton , linux-xfs , Junxiao Bi , William Kucharski , Joseph Qi , John Hubbard , linux-kernel@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net, cluster-devel@redhat.com, linux-mm@kvack.org, ocfs2-devel@oss.oracle.com, linux-fsdevel@vger.kernel.org, linux-ext4@vger.kernel.org, linux-erofs@lists.ozlabs.org, Christoph Hellwig , linux-btrfs@vger.kernel.org Subject: [RFC PATCH 0/2] gfs2 readahead regression in v5.8-rc1 Date: Fri, 19 Jun 2020 11:39:14 +0200 Message-Id: <20200619093916.1081129-1-agruenba@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 Sender: linux-btrfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-btrfs@vger.kernel.org Hello, can the two patches in this set still be considered for v5.8? Commit d4388340ae0b ("fs: convert mpage_readpages to mpage_readahead") which converts gfs2 and other filesystems to use the new ->readahead address space operation is leading to deadlocks between the inode glocks and page locks: ->readahead is called with the pages to readahead already locked. When gfs2_readahead then tries to lock the associated inode glock, another process already holding the inode glock may be trying to lock the same pages. We could work around this in gfs by using a LM_FLAG_TRY lock in ->readahead for now. The real reason for this deadlock is that gfs2 shouldn't be taking the inode glock in ->readahead in the first place though, so I'd prefer to fix this "properly" instead. Unfortunately, this depends on a new IOCB_CACHED flag for generic_file_read_iter. A previous version was posted in November: https://lore.kernel.org/linux-fsdevel/20191122235324.17245-1-agruenba@redhat.com/ Thanks, Andreas Andreas Gruenbacher (2): fs: Add IOCB_CACHED flag for generic_file_read_iter gfs2: Rework read and page fault locking fs/gfs2/aops.c | 27 ++------------------ fs/gfs2/file.c | 61 ++++++++++++++++++++++++++++++++++++++++++++-- include/linux/fs.h | 1 + mm/filemap.c | 16 ++++++++++-- 4 files changed, 76 insertions(+), 29 deletions(-) base-commit: af42d3466bdc8f39806b26f593604fdc54140bcb