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=-7.1 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS autolearn=ham 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 9193AC2BA19 for ; Wed, 15 Apr 2020 16:22:34 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 6D9C3208FE for ; Wed, 15 Apr 2020 16:22:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1586967754; bh=5W2f+v9XZr0qP/kIWQkjbbEgQ09ZuCIq5zRy2H1Fv6w=; h=Subject:From:To:Cc:Date:In-Reply-To:References:List-ID:From; b=nkPx/EjQpgy4kqMD0xnpGDvdmTi0q2NEwDjRBIsnP/OpNxe15jiNJ1H6dSc7FrRBJ OChTvw0H6A1aesLG7zO4gnQET56PqH5lnwBWB9UBu+Q6X/fWk9/P4ceVkU+LzfoERu Jj56asKhKZFCh0YmEn52kfz0z6ohpIRi48wJx8A4= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1415690AbgDOQWd (ORCPT ); Wed, 15 Apr 2020 12:22:33 -0400 Received: from mail.kernel.org ([198.145.29.99]:37062 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1415627AbgDOQWa (ORCPT ); Wed, 15 Apr 2020 12:22:30 -0400 Received: from tleilax.poochiereds.net (68-20-15-154.lightspeed.rlghnc.sbcglobal.net [68.20.15.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 15BB720737; Wed, 15 Apr 2020 16:22:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1586967750; bh=5W2f+v9XZr0qP/kIWQkjbbEgQ09ZuCIq5zRy2H1Fv6w=; h=Subject:From:To:Cc:Date:In-Reply-To:References:From; b=WJUQ8ieGLmlGLrey/1gl+9cKf1orwABumVzG+ZVsi5cy7RnBGl0XQ4psiRRGb2GBh FrKZQAHQzUvHQrGQxI8A08EPAumadauxzV9Tc48BExxmXmHc4a62vfKO2Xlzj4G4Y4 vKUO6nz0Pz3hnSTT7GPVVr3J2qfGi+gPg7ZgKP2A= Message-ID: Subject: Re: [PATCH v5 2/2] buffer: record blockdev write errors in super_block that it backs From: Jeff Layton To: Jan Kara Cc: viro@zeniv.linux.org.uk, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-api@vger.kernel.org, andres@anarazel.de, willy@infradead.org, dhowells@redhat.com, hch@infradead.org, akpm@linux-foundation.org, david@fromorbit.com Date: Wed, 15 Apr 2020 12:22:27 -0400 In-Reply-To: <20200415140642.GK6126@quack2.suse.cz> References: <20200415121300.228017-1-jlayton@kernel.org> <20200415121300.228017-3-jlayton@kernel.org> <20200415140642.GK6126@quack2.suse.cz> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.34.4 (3.34.4-1.fc31) MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-api-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-api@vger.kernel.org On Wed, 2020-04-15 at 16:06 +0200, Jan Kara wrote: > On Wed 15-04-20 08:13:00, Jeff Layton wrote: > > From: Jeff Layton > > > > When syncing out a block device (a'la __sync_blockdev), any error > > encountered will only be recorded in the bd_inode's mapping. When the > > blockdev contains a filesystem however, we'd like to also record the > > error in the super_block that's stored there. > > > > Make mark_buffer_write_io_error also record the error in the > > corresponding super_block when a writeback error occurs and the block > > device contains a mounted superblock. > > > > Since superblocks are RCU freed, hold the rcu_read_lock to ensure > > that the superblock doesn't go away while we're marking it. > > > > Signed-off-by: Jeff Layton > > --- > > fs/buffer.c | 7 +++++++ > > 1 file changed, 7 insertions(+) > > > > diff --git a/fs/buffer.c b/fs/buffer.c > > index f73276d746bb..2a4a5cc20418 100644 > > --- a/fs/buffer.c > > +++ b/fs/buffer.c > > @@ -1154,12 +1154,19 @@ EXPORT_SYMBOL(mark_buffer_dirty); > > > > void mark_buffer_write_io_error(struct buffer_head *bh) > > { > > + struct super_block *sb; > > + > > set_buffer_write_io_error(bh); > > /* FIXME: do we need to set this in both places? */ > > if (bh->b_page && bh->b_page->mapping) > > mapping_set_error(bh->b_page->mapping, -EIO); > > if (bh->b_assoc_map) > > mapping_set_error(bh->b_assoc_map, -EIO); > > + rcu_read_lock(); > > + sb = bh->b_bdev->bd_super; > > You still need READ_ONCE() here. Otherwise the dereference below can still > result in refetch and NULL ptr deref. > > Honza > Huh? That seems like a really suspicious thing for the compiler/arch to do. We are checking that sb isn't NULL before we dereference it. Doesn't that imply a data dependency? How could the value of "sb" change after that? I'm also not sure I understand how using READ_ONCE really helps there if we can't count on the value of a local variable not changing. > > + if (sb) > > + errseq_set(&sb->s_wb_err, -EIO); > > + rcu_read_unlock(); > > } > > EXPORT_SYMBOL(mark_buffer_write_io_error); > > > > -- > > 2.25.2 > > -- Jeff Layton