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=-5.8 required=3.0 tests=BAYES_00,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 C068FC433F5 for ; Fri, 3 Sep 2021 15:52:22 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id AC4D9610E5 for ; Fri, 3 Sep 2021 15:52:22 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1349756AbhICPxV (ORCPT ); Fri, 3 Sep 2021 11:53:21 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57696 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235629AbhICPxT (ORCPT ); Fri, 3 Sep 2021 11:53:19 -0400 Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com [IPv6:2a00:1450:4864:20::136]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5D406C061575 for ; Fri, 3 Sep 2021 08:52:19 -0700 (PDT) Received: by mail-lf1-x136.google.com with SMTP id l10so12609314lfg.4 for ; Fri, 03 Sep 2021 08:52:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Kr5rIfOe6Hwe2+y+jDes91fVUZ+f9S7J89384UtJgA8=; b=N8R50bKnZffPltj2pL6sAt/boekXEIz4AQ9Z/o/XuD4vPBxfG3r/2QGNeC3Td8/XlQ R0kZIgMPO8AoZ5aHXt7NM2HAmls86mjYLAHi42E+wudU8oKf8/JE6qalzvKuxXxORS9D NAlDdP45oLxOK+MFKC/0wdIbO7rTVRb8fcucQ= 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=Kr5rIfOe6Hwe2+y+jDes91fVUZ+f9S7J89384UtJgA8=; b=sg8C9V25fmhlgh5PI5SZ++W5KCo8JUdJw5CKGNbQhfBQX+rO1OLp3Ldsjg90w84+DE aRvgEXtLVqjkOzgH6aJFIjUe1ngQ0ecoxnNAh1Wu4UuoOFDta/Wdu1C0bE+4hE0lBPOg v9GEFlyLTVH9KRtijTs4s9A7T8tUY/s7yPy0u5Mlszlp2TE5KT3jORO6XWUtfXSil1io wTNVxNyfL6AikJFS9QibqzfqvzTROIthMDCDhzm5As05MKGXCMjaYGGX3SRkcgyU0fh2 PG8rTemdR5LEcx/hqSb6+T+Lzm+c4FenGJniYjhFtORc/wQxvx2rNyC4QbmTH2ZR+ywT SgQQ== X-Gm-Message-State: AOAM530EpALil6mnp/sofYs9anMS12AxU+qoJs47y67ZEcbxcfXIQ7NI dvu9d7InwOcNV16Xax1KGlc+BSWNSNNO9ChS53o= X-Google-Smtp-Source: ABdhPJyVDcCLxufizkt9s76MangxkOFfzatuQ/IIQosvROTVvmqAXu5fBHjy3TbHu3PJWuzIfxx67w== X-Received: by 2002:ac2:4e62:: with SMTP id y2mr3366732lfs.9.1630684337333; Fri, 03 Sep 2021 08:52:17 -0700 (PDT) Received: from mail-lf1-f48.google.com (mail-lf1-f48.google.com. [209.85.167.48]) by smtp.gmail.com with ESMTPSA id c19sm625234ljn.75.2021.09.03.08.52.16 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 03 Sep 2021 08:52:16 -0700 (PDT) Received: by mail-lf1-f48.google.com with SMTP id bq28so12590519lfb.7 for ; Fri, 03 Sep 2021 08:52:16 -0700 (PDT) X-Received: by 2002:a05:6512:3da5:: with SMTP id k37mr3415205lfv.655.1630684336092; Fri, 03 Sep 2021 08:52:16 -0700 (PDT) MIME-Version: 1.0 References: <20210827164926.1726765-1-agruenba@redhat.com> In-Reply-To: From: Linus Torvalds Date: Fri, 3 Sep 2021 08:52:00 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v7 00/19] gfs2: Fix mmap + page fault deadlocks To: Andreas Gruenbacher Cc: Alexander Viro , Christoph Hellwig , "Darrick J. Wong" , Paul Mackerras , Jan Kara , Matthew Wilcox , cluster-devel , linux-fsdevel , Linux Kernel Mailing List , ocfs2-devel@oss.oracle.com, kvm-ppc@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Sep 1, 2021 at 12:53 PM Andreas Gruenbacher wrote: > > So there's a minor merge conflict between Christoph's iomap_iter > conversion and this patch queue now, and I should probably clarify the > description of "iomap: Add done_before argument to iomap_dio_rw" that > Darrick ran into. Then there are the user copy issues that Al has > pointed out. Fixing those will create superficial conflicts with this > patch queue, but probably nothing serious. > > So how should I proceed: do you expect a v8 of this patch queue on top > of the current mainline? So if you rebase for fixes, it's going to be a "next merge window" thing again. Personally, I'm ok with the series as is, and the conflict isn't an issue. So I'd take it as is, and then people can fix up niggling issues later. But if somebody screams loudly.. Linus 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=-3.8 required=3.0 tests=BAYES_00, 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 2BC2AC433EF for ; Fri, 3 Sep 2021 15:52:28 +0000 (UTC) Received: from mx0a-00069f02.pphosted.com (mx0a-00069f02.pphosted.com [205.220.165.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id A1F526108E for ; Fri, 3 Sep 2021 15:52:27 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org A1F526108E Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linux-foundation.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=oss.oracle.com Received: from pps.filterd (m0246627.ppops.net [127.0.0.1]) by mx0b-00069f02.pphosted.com (8.16.1.2/8.16.1.2) with SMTP id 183DOVr9000337; Fri, 3 Sep 2021 15:52:27 GMT Received: from userp3020.oracle.com (userp3020.oracle.com [156.151.31.79]) by mx0b-00069f02.pphosted.com with ESMTP id 3audq7hkbn-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 03 Sep 2021 15:52:26 +0000 Received: from pps.filterd (userp3020.oracle.com [127.0.0.1]) by userp3020.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 183Fa1Dx080329; Fri, 3 Sep 2021 15:52:25 GMT Received: from oss.oracle.com (oss-old-reserved.oracle.com [137.254.22.2]) by userp3020.oracle.com with ESMTP id 3ate01r3rq-1 (version=TLSv1 cipher=AES256-SHA bits=256 verify=NO); Fri, 03 Sep 2021 15:52:25 +0000 Received: from localhost ([127.0.0.1] helo=lb-oss.oracle.com) by oss.oracle.com with esmtp (Exim 4.63) (envelope-from ) id 1mMBUN-00066A-Vt; Fri, 03 Sep 2021 08:52:23 -0700 Received: from userp3030.oracle.com ([156.151.31.80]) by oss.oracle.com with esmtp (Exim 4.63) (envelope-from ) id 1mMBUM-000657-BR for ocfs2-devel@oss.oracle.com; Fri, 03 Sep 2021 08:52:22 -0700 Received: from pps.filterd (userp3030.oracle.com [127.0.0.1]) by userp3030.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 183Faau5194971 for ; Fri, 3 Sep 2021 15:52:22 GMT Received: from mx0b-00069f01.pphosted.com (mx0b-00069f01.pphosted.com [205.220.177.26]) by userp3030.oracle.com with ESMTP id 3ate07nvcf-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Fri, 03 Sep 2021 15:52:21 +0000 Received: from pps.filterd (m0246577.ppops.net [127.0.0.1]) by mx0b-00069f01.pphosted.com (8.16.1.2/8.16.0.43) with SMTP id 18397gLq030887 for ; Fri, 3 Sep 2021 15:52:20 GMT Received: from mail-lj1-f175.google.com (mail-lj1-f175.google.com [209.85.208.175]) by mx0b-00069f01.pphosted.com with ESMTP id 3au7wc9wc4-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=OK) for ; Fri, 03 Sep 2021 15:52:20 +0000 Received: by mail-lj1-f175.google.com with SMTP id j12so10235609ljg.10 for ; Fri, 03 Sep 2021 08:52:19 -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=Kr5rIfOe6Hwe2+y+jDes91fVUZ+f9S7J89384UtJgA8=; b=RF9Tho32IT3To6OC9LHlpPqms+E9zgWJn+BB5Ud925PdvLSaAiWLvIQ7hYBAMdbzK6 WRmpRVDVGZ0x8hdXKguB4zAcGFJZgcaGKIeJbJkdML424CMhIYTNJ6NQxtxqarQ0Ronf bbfbxgX/m4grta4p5MCxMkI0a8Jdyp1fqWkGbp6d2e1dGGxuZLP1eYEfJKEnsOGINy3a 71lM9hMr089H4ReywYm+3ANS8bRpRdku+t9H25i5nBvl02peeYps8IbmEE/LIyeudZMZ z2Z4gl+rYgvzf0WemrC1NPUQ7RUDlcKWOwkklHzgZ++vuLaXICHBJBN4Je/x5yZR+CdK BtGg== X-Gm-Message-State: AOAM533dW1v6aDanZ0Q51jcIXqtaqjcHO4Qt8JA9WWgVAKhC0+W5cYkQ CmD7f1kw2lYk+1fMjHEZJ6vEzEevu3LBbjdHBFY= X-Google-Smtp-Source: ABdhPJzZdz6Fi9pnNBvXGq8XLUoQ46eL5QfvCj6lrCwt1AIVytz3id96wO62Ye3Sz6GW4DXgOoAlsA== X-Received: by 2002:a2e:bf0d:: with SMTP id c13mr3414968ljr.101.1630684337453; Fri, 03 Sep 2021 08:52:17 -0700 (PDT) Received: from mail-lf1-f51.google.com (mail-lf1-f51.google.com. [209.85.167.51]) by smtp.gmail.com with ESMTPSA id b18sm622391ljk.24.2021.09.03.08.52.16 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 03 Sep 2021 08:52:16 -0700 (PDT) Received: by mail-lf1-f51.google.com with SMTP id t12so12441605lfg.9 for ; Fri, 03 Sep 2021 08:52:16 -0700 (PDT) X-Received: by 2002:a05:6512:3da5:: with SMTP id k37mr3415205lfv.655.1630684336092; Fri, 03 Sep 2021 08:52:16 -0700 (PDT) MIME-Version: 1.0 References: <20210827164926.1726765-1-agruenba@redhat.com> In-Reply-To: From: Linus Torvalds Date: Fri, 3 Sep 2021 08:52:00 -0700 X-Gmail-Original-Message-ID: Message-ID: To: Andreas Gruenbacher X-Source-IP: 209.85.208.175 X-ServerName: mail-lj1-f175.google.com X-Proofpoint-SPF-Result: pass X-Proofpoint-SPF-Record: v=spf1 ip4:198.145.29.98/31 ip4:72.55.140.81 include:_spf.google.com include:amazonses.com include:_spf.salesforce.com ~all X-Proofpoint-Virus-Version: vendor=nai engine=6300 definitions=10096 signatures=668682 X-Proofpoint-Spam-Details: rule=tap_notspam policy=tap score=0 phishscore=0 spamscore=0 impostorscore=0 malwarescore=0 bulkscore=0 suspectscore=0 mlxlogscore=999 priorityscore=0 clxscore=358 adultscore=0 mlxscore=0 lowpriorityscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2108310000 definitions=main-2109030095 domainage_hfrom=5372 X-Spam: Clean Cc: kvm-ppc@vger.kernel.org, Paul Mackerras , cluster-devel , Jan Kara , Linux Kernel Mailing List , Christoph Hellwig , Alexander Viro , linux-fsdevel , ocfs2-devel@oss.oracle.com Subject: Re: [Ocfs2-devel] [PATCH v7 00/19] gfs2: Fix mmap + page fault deadlocks X-BeenThere: ocfs2-devel@oss.oracle.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ocfs2-devel-bounces@oss.oracle.com Errors-To: ocfs2-devel-bounces@oss.oracle.com X-Proofpoint-Virus-Version: vendor=nai engine=6300 definitions=10096 signatures=668682 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0 bulkscore=0 mlxlogscore=999 mlxscore=0 suspectscore=0 spamscore=0 phishscore=0 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2108310000 definitions=main-2109030095 X-Proofpoint-ORIG-GUID: vD84y5dUT3eu_ID9vfdeSkdiZPYT6DEb X-Proofpoint-GUID: vD84y5dUT3eu_ID9vfdeSkdiZPYT6DEb On Wed, Sep 1, 2021 at 12:53 PM Andreas Gruenbacher wrote: > > So there's a minor merge conflict between Christoph's iomap_iter > conversion and this patch queue now, and I should probably clarify the > description of "iomap: Add done_before argument to iomap_dio_rw" that > Darrick ran into. Then there are the user copy issues that Al has > pointed out. Fixing those will create superficial conflicts with this > patch queue, but probably nothing serious. > > So how should I proceed: do you expect a v8 of this patch queue on top > of the current mainline? So if you rebase for fixes, it's going to be a "next merge window" thing again. Personally, I'm ok with the series as is, and the conflict isn't an issue. So I'd take it as is, and then people can fix up niggling issues later. But if somebody screams loudly.. Linus _______________________________________________ Ocfs2-devel mailing list Ocfs2-devel@oss.oracle.com https://oss.oracle.com/mailman/listinfo/ocfs2-devel From mboxrd@z Thu Jan 1 00:00:00 1970 From: Linus Torvalds Date: Fri, 3 Sep 2021 08:52:00 -0700 Subject: [Cluster-devel] [PATCH v7 00/19] gfs2: Fix mmap + page fault deadlocks In-Reply-To: References: <20210827164926.1726765-1-agruenba@redhat.com> Message-ID: List-Id: To: cluster-devel.redhat.com MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit On Wed, Sep 1, 2021 at 12:53 PM Andreas Gruenbacher wrote: > > So there's a minor merge conflict between Christoph's iomap_iter > conversion and this patch queue now, and I should probably clarify the > description of "iomap: Add done_before argument to iomap_dio_rw" that > Darrick ran into. Then there are the user copy issues that Al has > pointed out. Fixing those will create superficial conflicts with this > patch queue, but probably nothing serious. > > So how should I proceed: do you expect a v8 of this patch queue on top > of the current mainline? So if you rebase for fixes, it's going to be a "next merge window" thing again. Personally, I'm ok with the series as is, and the conflict isn't an issue. So I'd take it as is, and then people can fix up niggling issues later. But if somebody screams loudly.. Linus From mboxrd@z Thu Jan 1 00:00:00 1970 From: Linus Torvalds Date: Fri, 03 Sep 2021 15:52:00 +0000 Subject: Re: [PATCH v7 00/19] gfs2: Fix mmap + page fault deadlocks Message-Id: List-Id: References: <20210827164926.1726765-1-agruenba@redhat.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Andreas Gruenbacher Cc: Alexander Viro , Christoph Hellwig , "Darrick J. Wong" , Paul Mackerras , Jan Kara , Matthew Wilcox , cluster-devel , linux-fsdevel , Linux Kernel Mailing List , ocfs2-devel@oss.oracle.com, kvm-ppc@vger.kernel.org On Wed, Sep 1, 2021 at 12:53 PM Andreas Gruenbacher wrote: > > So there's a minor merge conflict between Christoph's iomap_iter > conversion and this patch queue now, and I should probably clarify the > description of "iomap: Add done_before argument to iomap_dio_rw" that > Darrick ran into. Then there are the user copy issues that Al has > pointed out. Fixing those will create superficial conflicts with this > patch queue, but probably nothing serious. > > So how should I proceed: do you expect a v8 of this patch queue on top > of the current mainline? So if you rebase for fixes, it's going to be a "next merge window" thing again. Personally, I'm ok with the series as is, and the conflict isn't an issue. So I'd take it as is, and then people can fix up niggling issues later. But if somebody screams loudly.. Linus