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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 27B9AC7EE24 for ; Tue, 9 May 2023 20:49:20 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235178AbjEIUtS (ORCPT ); Tue, 9 May 2023 16:49:18 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40134 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230181AbjEIUtN (ORCPT ); Tue, 9 May 2023 16:49:13 -0400 Received: from verein.lst.de (verein.lst.de [213.95.11.211]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 472574EDD for ; Tue, 9 May 2023 13:49:07 -0700 (PDT) Received: by verein.lst.de (Postfix, from userid 2407) id 8CD1F6732A; Tue, 9 May 2023 22:49:02 +0200 (CEST) Date: Tue, 9 May 2023 22:49:02 +0200 From: Christoph Hellwig To: Linus Torvalds Cc: Dan Carpenter , Anna Schumaker , Trond Myklebust , Andrew Morton , "Matthew Wilcox (Oracle)" , Josef Bacik , Johannes Weiner , linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, syzbot+48011b86c8ea329af1b9@syzkaller.appspotmail.com, Christoph Hellwig , David Sterba , Bob Peterson , Andreas Gruenbacher Subject: Re: [PATCH] filemap: Handle error return from __filemap_get_folio() Message-ID: <20230509204902.GA2047@lst.de> References: <20230506160415.2992089-1-willy@infradead.org> <20230506104122.e9ab27f59fd3d8294cb1356d@linux-foundation.org> <7bd22265-f46c-4347-a856-eecd1429dcce@kili.mountain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org On Tue, May 09, 2023 at 10:37:12AM -0700, Linus Torvalds wrote: > In fs/btrfs/extent_io.c, we have > > while (index <= end_index) { > folio = filemap_get_folio(mapping, index); > filemap_dirty_folio(mapping, folio); > > and in fs/gfs2/lops.c we have a similar case of filemap_get_folio -> > folio_wait_locked use without checking for any errors. > > I assume it's probably hard to trigger errors in those paths, but it > does look dodgy. The pages are pinned at the point. That being said this code is absolutely for many other reasons and needs to go away. I've been looking into it, but it will probably take several more months to unpile the onion to get to the hear of the btrfs writeback code problems..