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 6E0BEC433EF for ; Wed, 24 Nov 2021 00:40:33 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231422AbhKXAni (ORCPT ); Tue, 23 Nov 2021 19:43:38 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34506 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231303AbhKXAnh (ORCPT ); Tue, 23 Nov 2021 19:43:37 -0500 Received: from mail-ed1-x535.google.com (mail-ed1-x535.google.com [IPv6:2a00:1450:4864:20::535]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9D030C061714 for ; Tue, 23 Nov 2021 16:40:28 -0800 (PST) Received: by mail-ed1-x535.google.com with SMTP id v1so2517111edx.2 for ; Tue, 23 Nov 2021 16:40:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linuxtx.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Ed+8AqhHF9LjEr/ddfnjb/lBhu42SN2dE9F+PFAVeQg=; b=Wjy9BYZ5+F1SRnk/hYqJ3NtmC+mUEmtMz4qmtTJQ+Ye6g4k5viv8imLHHlueIpW36O XhrHCg6JEMBQGwQQEFVZk3mYiJ8cZX8hAstxngm1XAbRnUha9uOMrMiod2zJ9Ly9IVLG //hBllSGIduKzKU+Hb+GdwLTqbl9CFkjl5hEE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Ed+8AqhHF9LjEr/ddfnjb/lBhu42SN2dE9F+PFAVeQg=; b=8HwzdGj944YcpxmpzuHHy8iZ5ved/5iemB4rcvLMQE6RtkA744haX8HErU7VLEOltx PcLDf5MrjLKv6h0QNfCi790TQPQHxVriLxEPmOhZXDXaKFv0wSI3+x1IxetLcMhZHPeW /fn5nK3qmcH0QjrZpi14STaFiSpbGnjOk3SPfzlowuUJi0EL5AbUcaX6OrDWQ7ZkBeoJ Ql4fGVf4DkIFqXt3+cWQKTzoBvj7W1XueJCimTqkEG1vqUe7bBZWhCD835F7v1lfFs5o QEhd12IZYDQZE5QVbwr5YGoqn0X7SxdCrqmiIGMt3CNf1nP2va7HvKXro4jeagBApB1f 6Sug== X-Gm-Message-State: AOAM532zL8u2yJAFAvDZQ3OXAw2fWc/5I1awT7h+Od5v5QEBZLu3IO63 qtnl1vPgWrNqTGrNEk5PrSPSQ3xdhDbqpmSCBgd86g== X-Google-Smtp-Source: ABdhPJzHFWzgRzJHLlh6KVWQt8e26YwrEE7uC1O57pOjDKUKDxspr4TM+rmdsIxLCyMh+Tjh0FG2Ks3d6gpvlTC9gqU= X-Received: by 2002:a05:6402:11c8:: with SMTP id j8mr17158976edw.33.1637714427186; Tue, 23 Nov 2021 16:40:27 -0800 (PST) MIME-Version: 1.0 References: <20211115165428.722074685@linuxfoundation.org> <20211115165430.669780058@linuxfoundation.org> In-Reply-To: From: Justin Forbes Date: Tue, 23 Nov 2021 18:40:16 -0600 Message-ID: Subject: Re: [PATCH 5.15 056/917] fuse: fix page stealing To: Miklos Szeredi Cc: Greg Kroah-Hartman , LKML , Stable , Frank Dinoff Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Nov 23, 2021 at 1:22 PM Miklos Szeredi wrote: > > On Tue, Nov 23, 2021 at 7:29 PM Justin Forbes wrote: > > > > On Mon, Nov 15, 2021 at 7:04 PM Greg Kroah-Hartman > > wrote: > > > > > > From: Miklos Szeredi > > > > > > commit 712a951025c0667ff00b25afc360f74e639dfabe upstream. > > > > > > It is possible to trigger a crash by splicing anon pipe bufs to the fuse > > > device. > > > > > > The reason for this is that anon_pipe_buf_release() will reuse buf->page if > > > the refcount is 1, but that page might have already been stolen and its > > > flags modified (e.g. PG_lru added). > > > > > > This happens in the unlikely case of fuse_dev_splice_write() getting around > > > to calling pipe_buf_release() after a page has been stolen, added to the > > > page cache and removed from the page cache. > > > > > > Fix by calling pipe_buf_release() right after the page was inserted into > > > the page cache. In this case the page has an elevated refcount so any > > > release function will know that the page isn't reusable. > > > > > > Reported-by: Frank Dinoff > > > Link: https://lore.kernel.org/r/CAAmZXrsGg2xsP1CK+cbuEMumtrqdvD-NKnWzhNcvn71RV3c1yw@mail.gmail.com/ > > > Fixes: dd3bb14f44a6 ("fuse: support splice() writing to fuse device") > > > Cc: # v2.6.35 > > > Signed-off-by: Miklos Szeredi > > > Signed-off-by: Greg Kroah-Hartman > > > > It appears this patch causes a rather serious regression in flatpacks > > using portals to access files. Reverting this patch restores expected > > behavior. I have asked users in the Fedora bug to test with 5.16-rc2 > > to see if we are just missing a dependent patch in stable, or if this > > is broken there as well, but no response yet.: > > > > https://bugzilla.redhat.com/show_bug.cgi?id=2025285 > > https://github.com/flatpak/flatpak/issues/4595 > > Hi, > > Thanks for the report. Can someone with the reproducer try the attached patch? > > I think the race there is unlikely but possible. > Thanks, did a scratch build for that and dropped it in the bug. Only one user has reported back, but the report was that it did not fix the issue. I have also gotten confirmation now that the issue is occuring with 5.16-rc2. Thanks, Justin