Received: by 2002:a25:683:0:0:0:0:0 with SMTP id 125csp1672733ybg; Thu, 4 Jun 2020 16:16:19 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzX75esMvXJ9O2nWneXZcjkKgwzLplUhNK6BQHRAOjpPe2NAPas8Q8dMJZTMKy0aOPtwcha X-Received: by 2002:a05:6402:943:: with SMTP id h3mr6796563edz.89.1591312579292; Thu, 04 Jun 2020 16:16:19 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1591312579; cv=none; d=google.com; s=arc-20160816; b=UWr4mjRkJwOCSP+bPAq/pVFdh6XfmEw3kjFbDigfk/FoQ3Ew7eLJqIcZ7fWT/sL4jP HWqjosrgiIUG6rMbRl9ijHrdY0ZtnW5w/MtKfJHYnJsjzZv9G/bTmsMZoN9MITnf4i9z UxwBj2KZ1Kjgd9cEauXVjM3B3XpK8lVnzccTF6C88R6VwszkoQdIP+7VIX7eYVHkWCSt r/keqFJ6KeP8I3WTe18JMb+J3U9z3jVV/B53k8mH35aTayFkcU4gxqfh/wjAaDDTmkEq H8anEGhU6/ffZrMf/udEgIgww/9t5JbZRho2wnSEjgWm/+Gj/DZ4gTfT1seONt/hflJ7 hScA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature; bh=vLkbveTzLrm+1mGeplB+ePn3QIH8H7o1DVPIYYdiRK4=; b=mQ3+MVt83mz1GOP/ObYGSoyPXdYg7Q/J7HeX4yxwn4//rECZy9vdL5zfMluK/QoBjs 2sCXVhVF0aBfHtFVKMJ4VVau8cN5OMgudZuHbM0tcO1cXl6V7ffXCAJXX8UNhyBn+RX/ yZ/Ja/s5Suw7nPb40wRON3VZLIt/crqMOcaPCwZAls+pjpOknXtLYq2V8y+A6+6+s8E7 iadtCAtM+ZcqghVS3jNn3A58ZOFaGeHlmWO002tiTwV7D+yH19LS7hH4NBmTf13NaccF nVXfJ+hrdGloPETB/wDmdBpweNj+r9flyJsVuSrasYCu/wMteyWSMQc1fQQ1W0Yj+gmA 5t+A== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@infradead.org header.s=bombadil.20170209 header.b=E9BARcPt; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-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 di12si2574459edb.27.2020.06.04.16.15.57; Thu, 04 Jun 2020 16:16:19 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=fail header.i=@infradead.org header.s=bombadil.20170209 header.b=E9BARcPt; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726068AbgFDXMu (ORCPT + 99 others); Thu, 4 Jun 2020 19:12:50 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49802 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725863AbgFDXMt (ORCPT ); Thu, 4 Jun 2020 19:12:49 -0400 Received: from bombadil.infradead.org (bombadil.infradead.org [IPv6:2607:7c80:54:e::133]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 41C20C08C5C1; Thu, 4 Jun 2020 16:05:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20170209; h=In-Reply-To:Content-Type:MIME-Version :References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=vLkbveTzLrm+1mGeplB+ePn3QIH8H7o1DVPIYYdiRK4=; b=E9BARcPtQWALfSiXDWtgpM6WrE i9SCajNKsOHN3OIlAKCN8L+EXFCmTQfZFDkPB9dsuSvNB1GEuDhe2b6JMcAQs1ebIB9YC287ZeqVm 8Mu/IN6GcVUsXXLw7ojs5NN1ckyOD5Xjk4YCEcRFM/Svsuqw2G1Bzzoe3ecj0pKqXocCzsI+tOTVh gx4vLL2jzB+v1k2zmSbEaZw6yfYt5NhxXANP5pAMu18eSx83Lw8LDr3lxaPO1gM4g+kSomsDyt0rc NrBM4jaz5upjrR+VoRbIN6nyZADbQuRT0XOgeECGztuYiBO0Adj0GqWpesV3Y7RkHm9SJJOKQUMCc Jmhar29Q==; Received: from willy by bombadil.infradead.org with local (Exim 4.92.3 #3 (Red Hat Linux)) id 1jgyvH-0006iF-G0; Thu, 04 Jun 2020 23:05:19 +0000 Date: Thu, 4 Jun 2020 16:05:19 -0700 From: Matthew Wilcox To: Dave Chinner Cc: Christoph Hellwig , "Darrick J. Wong" , linux-xfs@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] iomap: Handle I/O errors gracefully in page_mkwrite Message-ID: <20200604230519.GW19604@bombadil.infradead.org> References: <20200604202340.29170-1-willy@infradead.org> <20200604225726.GU2040@dread.disaster.area> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200604225726.GU2040@dread.disaster.area> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Jun 05, 2020 at 08:57:26AM +1000, Dave Chinner wrote: > On Thu, Jun 04, 2020 at 01:23:40PM -0700, Matthew Wilcox wrote: > > From: "Matthew Wilcox (Oracle)" > > > > Test generic/019 often results in: > > > > WARNING: at fs/iomap/buffered-io.c:1069 iomap_page_mkwrite_actor+0x57/0x70 > > > > Since this can happen due to a storage error, we should not WARN for it. > > Just return -EIO, which will be converted to a SIGBUS for the hapless > > task attempting to write to the page that we can't read. > > Why didn't the "read" part of the fault which had the EIO error fail > the page fault? i.e. why are we waiting until deep inside the write > fault path to error out on a failed page read? I have a hypothesis that I don't know how to verify. First the task does a load from the page and we put a read-only PTE in the page tables. Then it writes to the page using write(). The page gets written back, but hits an error in iomap_writepage_map() which calls ClearPageUptodate(). Then the task with it mapped attempts to store to it. I haven't dug through what generic/019 does, so I don't know how plausible this is.