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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id BBEEBC0219B for ; Mon, 10 Feb 2025 18:14:07 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4D2286B0089; Mon, 10 Feb 2025 13:14:07 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 45BBB6B008A; Mon, 10 Feb 2025 13:14:07 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2FBA66B008C; Mon, 10 Feb 2025 13:14:07 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 0AE886B0089 for ; Mon, 10 Feb 2025 13:14:07 -0500 (EST) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 8C6F21203D1 for ; Mon, 10 Feb 2025 18:14:06 +0000 (UTC) X-FDA: 83104834092.20.0A2042C Received: from mail-qt1-f171.google.com (mail-qt1-f171.google.com [209.85.160.171]) by imf09.hostedemail.com (Postfix) with ESMTP id A176514000E for ; Mon, 10 Feb 2025 18:14:04 +0000 (UTC) Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=cpCP6dEv; spf=pass (imf09.hostedemail.com: domain of joannelkoong@gmail.com designates 209.85.160.171 as permitted sender) smtp.mailfrom=joannelkoong@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1739211244; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=9GAon67fTF+Z/QksfmcN1Wg362w+GO/sYKO+48/Qp2g=; b=wTt/Lf4oCxttrRCcI4VsXldLhNAuK7rad9z/nVNzEkdJXNNyFVp93+d5dkP+8umS59wAz+ +hLxEmHXySgTADQvRWUsYcIquLuvsOgOYGUN8rJth97Mlsx5DnUF4NrRT7lIs8nGud+LMH Z1EE/BFoNpTFrIfsgSSR4m6FcxZH6fs= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=cpCP6dEv; spf=pass (imf09.hostedemail.com: domain of joannelkoong@gmail.com designates 209.85.160.171 as permitted sender) smtp.mailfrom=joannelkoong@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1739211244; a=rsa-sha256; cv=none; b=iyUyTaIvoID5HHEt+cUe6ciR0uIlYugs5rBfgaOdJq4OLUttNo8vJqAD+pDWwfrYESA9J5 owfImK4WZdUZZmY85kZSa7GKgIvGgnqwmYcKrdFl+Joyj0mnjHrayZ9WuVvXzrXbmAREll 8kx9+vZSU+fVsAPrfRixEdAQ4jnMCWI= Received: by mail-qt1-f171.google.com with SMTP id d75a77b69052e-471953ab6d8so6134341cf.1 for ; Mon, 10 Feb 2025 10:14:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1739211244; x=1739816044; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=9GAon67fTF+Z/QksfmcN1Wg362w+GO/sYKO+48/Qp2g=; b=cpCP6dEvJfXaOT8vubsn8vvQk2QHp4u2WttUo/U29vvtn4KKqynFLbJTp26Es6toOf FfV+IP/ZNE//4JsaAU7r91fPe9ecKa/r1+273Tr8gOSJyPk0IOjM56NLsMvxFO7EQrw2 Vkswo/itigwTJ2Lx87b0Sf3mq73GAMOM6tp4Z6PcN5aj1ahveh65aErEJC03M+pu2Aau dnMm1rfdXJSsLs6K4Y3BZLqbGgNtR4BICfR/2CncjlXzZb/136C6ApuNhimcjxx2ZCpE 8j8N+JjKIhcOTuUx0G3vqBKFQlXr2pskzIhXp9Nh6Bzr1yWzU63i4tyDTyQbLUzbgOS/ FAVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1739211244; x=1739816044; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=9GAon67fTF+Z/QksfmcN1Wg362w+GO/sYKO+48/Qp2g=; b=fkOSjiu4N3bePM0qcxH8h/NbjY5a1C2m3ESoXbCun5hje9iEaE7jCmuRn8+p/KUPEs tDy7FQu/LeR4qP7bFeNLqZNBc8pLBlX8UvtGjQWiIIlmQE7ETyJMaSaOHQCKn6M/qyZ2 622QSEeoYIszwsI4uBgPJjTzyrCf3gTjU+6kkoOsCqlYURUYpWoTk1BEp20xhgXAFTkU ItJDqp8bPY66lc+lOgWzZ/cAkKuObst6gitYdgSilEJ5zeEx1qor0ve72cSs7q+ah9D4 Z6nZ8HUn0qc4cs7d5BKEJzJUL5I9pqZd6pBQ9rUrXaKvOjeYbD4jX5PFdu7pwGw3bQMg JXrg== X-Forwarded-Encrypted: i=1; AJvYcCU02QNxFGtVvtFPhnOHj54hQT892QdhvL2k0r3a/ojwtaQWMXF/S7Hj2ZTAof5O2h0PxmOzV7YVmQ==@kvack.org X-Gm-Message-State: AOJu0Yxm9Nsx4nfL3cFIe/4DF8+oRVu2xfUo77UUj4tVT40scBgIJ2hZ /RCyDXQEUfXins7p7BdCj7bDX5kcqDtqn6zg33F8iNKrviV+vPbcwHpOqzzsVcnbfVSOrC8EOVQ S4OMgRVToEbq0tSl7PuO4T782+7E= X-Gm-Gg: ASbGncsMu+8EJ94qfuOPAQR7jtRLmLVEsSTvinleRGEnQjKDuezCVdvDQpN5e5GK5IL 9AGqhRaKNUMzb7sr0h7cMMTbYlu/jBLzzWSmx+NikcDK+p1/CSHwn/AqiPTygUaNEY0SV/Jlefi yGHtQSj1HpRo3v X-Google-Smtp-Source: AGHT+IHw7qyHtO12sVFUjn+ibik5SqtRzWi/aq5Gq5MrMU1FTFBx2agmOq4G5FuHhwgn6PL4m2EdV38mrVh7lb23k5M= X-Received: by 2002:a05:622a:1f06:b0:471:997f:39ec with SMTP id d75a77b69052e-471997f3e9cmr41192771cf.30.1739211243688; Mon, 10 Feb 2025 10:14:03 -0800 (PST) MIME-Version: 1.0 References: <2f681f48-00f5-4e09-8431-2b3dbfaa881e@heusel.eu> <9cd88643-daa8-4379-be0a-bd31de277658@suse.cz> <20250207172917.GA2072771@perftesting> <8f7333f2-1ba9-4df4-bc54-44fd768b3d5b@suse.cz> <81298bd1-e630-4940-ae5b-7882576b6bf4@suse.cz> In-Reply-To: <81298bd1-e630-4940-ae5b-7882576b6bf4@suse.cz> From: Joanne Koong Date: Mon, 10 Feb 2025 10:13:51 -0800 X-Gm-Features: AWEUYZnd9EDodvxc9WlMkRecfw_ALKaRXXREZ3ZlXO6DJg6l6ogEuCyV301mPcc Message-ID: Subject: Re: [REGRESSION][BISECTED] Crash with Bad page state for FUSE/Flatpak related applications since v6.13 To: Vlastimil Babka Cc: Matthew Wilcox , Josef Bacik , Miklos Szeredi , Christian Heusel , Miklos Szeredi , regressions@lists.linux.dev, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-mm , =?UTF-8?Q?Mantas_Mikul=C4=97nas?= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: A176514000E X-Stat-Signature: iixunbitierozkhjuqw9e9wmoqbq394i X-HE-Tag: 1739211244-730204 X-HE-Meta: U2FsdGVkX18h/mYxbuRh/aRC86IQRI4xiyJsa3gX7LBJsxlMEN6ppHWbJVD1XAWQW9uXJ3D7fflLMhWkQuzFcYmkkREt1Bo92cZcse69GqrS4QfIxrZptBOChFE/oLZvLCfo8Eor87ueDFw7L7Rkin4O35qJZ3IXGi/olpfHATcyi8maA4do13VmreuUZb4Q7jpZqYylVf6gZBqBaUDOd+ErpUn4SU4+YTOnqXyTOKiXompTcsY0LQfBoIF+Xt8C/d4Rcv4cOLl4UAtrSB7xjWbmPx9tAV7P1RYft1NZ060Co+87viye8oxEEfBmVDY5BNkTLBUPrHQl4M5323zBbr+DgXhb5ICK88SjCVvNnxqWSau48EYLmN2A8YRrlKzODFygLQieNcc8POokS5zB+bSIhyxL7EKWbIMifgQdzZNs5Gj0aLUI4kvmfUjS8Vm7Xo4T+WnHpW6iOGUQUfDhy7k60wF+c/U6VubUS9+Z4ElCMcApHD2GYjkZgFoQNA8PzHBlF1VHJH1MQKPUg1ABEGGMcDA5mvH6WkeMR49dhUNIvSCQopLRz6LLU54gZgaxnyZAoIzNae5y3rHih9VM1S4I87auakdtrQ9ZYo4rI0RsngOIKY96KSivjuRgEkrQeHF7QJ+3STeS+HSF20SVbxe8DWlg8/a6M59BpDgm5nILGVPI1MTh4znF49jVigLCrJUsMvDnpJ6XxjZNHQTtcjHx2BQIe9/0QF+3qMi6OidqLrxdWjedLkBhZQZLMxTytbFq9piuTn6kK7ZIT0BvzHQLTznWEuLTxEDxA1kTwWUApAIBcuRa80CdPOuLvitihIJS9DHJSMj2FAw+aSpUbbdFySnmony8ojZOCeCThot8HDQUDh6kuWaATLENMaj1mA2w9dVxPC82v2A0alpHo/XWfSEK7B1vu7yDFNn+m7HQHYGTgvRfzekywqBoF66RUK5bP+M7dGiEsp0HwBJ fQ6VCEou McbdOf2BVUtyqbfKYr9blYm+dqWpTlxVwlouOR6UAFVBA7tMdyFFFATx1FUyp8Azv5riUVpoxdwt5S6Fytuha02Lf8Mnmp3qPlNvJNQKTe4F04MZYB10YMiSXM92Xwmt1kYWxN5yKvKvTfzw57iZaFM6hF8Vt8uLTuJziWUtZEjrzXGZyWXdrde7swaOBKmEEy/64tXQXL+qWewIGVYG+u7NE8x/2ItYsM04APN34sarmxcRKkx4kBEfMvu7sO/wnL9hfuTTgZVQN9mDK3CLVOt768zk19WsI8PHgiyjgm8CAeeba3wRaZcJCInM3mahJ1YkrK++HtudYakYldSIPt5INzoCRfVkHHrW4J22m1TqjWWyWu0HwbDGetITbKL4tHdpU X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Mon, Feb 10, 2025 at 12:27=E2=80=AFAM Vlastimil Babka w= rote: > > On 2/8/25 16:46, Joanne Koong wrote: > > On Sat, Feb 8, 2025 at 2:11=E2=80=AFAM Matthew Wilcox wrote: > >> > >> On Fri, Feb 07, 2025 at 04:22:56PM -0800, Joanne Koong wrote: > >> > > Thanks, Josef. I guess we can at least try to confirm we're on the= right track. > >> > > Can anyone affected see if this (only compile tested) patch fixes = the issue? > >> > > Created on top of 6.13.1. > >> > > >> > This fixes the crash for me on 6.14.0-rc1. I ran the repro using > >> > Mantas's instructions for Obfuscate. I was able to trigger the crash > >> > on a clean build and then with this patch, I'm not seeing the crash > >> > anymore. > >> > >> Since this patch fixes the bug, we're looking for one call to folio_pu= t() > >> too many. Is it possibly in fuse_try_move_page()? In particular, thi= s > >> one: > >> > >> /* Drop ref for ap->pages[] array */ > >> folio_put(oldfolio); > >> > >> I don't know fuse very well. Maybe this isn't it. > > > > Yeah, this looks it to me. We don't grab a folio reference for the > > ap->pages[] array for readahead and it tracks with Mantas's > > fuse_dev_splice_write() dmesg. this patch fixed the crash for me when > > I tested it yesterday: > > > > diff --git a/fs/fuse/file.c b/fs/fuse/file.c > > index 7d92a5479998..172cab8e2caf 100644 > > --- a/fs/fuse/file.c > > +++ b/fs/fuse/file.c > > @@ -955,8 +955,10 @@ static void fuse_readpages_end(struct fuse_mount > > *fm, struct fuse_args *args, > > fuse_invalidate_atime(inode); > > } > > > > - for (i =3D 0; i < ap->num_folios; i++) > > + for (i =3D 0; i < ap->num_folios; i++) { > > folio_end_read(ap->folios[i], !err); > > + folio_put(ap->folios[i]); > > + } > > if (ia->ff) > > fuse_file_put(ia->ff, false); > > > > @@ -1049,6 +1051,7 @@ static void fuse_readahead(struct readahead_contr= ol *rac) > > > > while (ap->num_folios < cur_pages) { > > folio =3D readahead_folio(rac); > > + folio_get(folio); > > This is almost the same as my patch, but balances the folio_put() in > readahead_folio() with another folio_get(), while mine uses > __readahead_folio() that does not do folio_put() in the first place. > > But I think neither patch proves the extraneous folio_put() comes from > fuse_try_move_page(). > > > ap->folios[ap->num_folios] =3D folio; > > ap->descs[ap->num_folios].length =3D folio_size= (folio); > > ap->num_folios++; > > > > > > I reran it just now with a printk by that ref drop in > > fuse_try_move_page() and I'm indeed seeing that path get hit. > > It might get hit, but is it hit in the readahead paths? One way to test > would be to instead of yours above or mine change, to stop doing the > foio_put() in fuse_try_move_page(). But maybe it's called also from other > contexts that do expect it, and will leak memory otherwise. When I tested it a few days ago, I printk-ed the address of the folio and it matched in fuse_readahead() and try_move_page(). I think that proves that the extra folio_put() came from fuse_try_move_page() through the readahead path. > > > Not sure why fstests didn't pick this up though since splice is > > enabled by default in passthrough_hp, i'll look into this next week. > > >