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 EC62CE77188 for ; Tue, 14 Jan 2025 18:58:20 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6C09728000F; Tue, 14 Jan 2025 13:58:20 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 670E928000C; Tue, 14 Jan 2025 13:58:20 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4EAC028000F; Tue, 14 Jan 2025 13:58:20 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 3088728000C for ; Tue, 14 Jan 2025 13:58:20 -0500 (EST) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 942EDA0C72 for ; Tue, 14 Jan 2025 18:58:19 +0000 (UTC) X-FDA: 83006967918.30.467F0CE Received: from mail-qt1-f171.google.com (mail-qt1-f171.google.com [209.85.160.171]) by imf26.hostedemail.com (Postfix) with ESMTP id AA8BB140007 for ; Tue, 14 Jan 2025 18:58:17 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=e1lLQlZd; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf26.hostedemail.com: domain of joannelkoong@gmail.com designates 209.85.160.171 as permitted sender) smtp.mailfrom=joannelkoong@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1736881097; 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=Z7AHvURHt1sKIC0K/sgbG2CCAchF8Mz6y7cTbsB1kc0=; b=LxMzTgtyPGX+GHlyh90jdgKrLwXxB0SLf9dsLrZSuhPzTYVVMp5kkrdOWsRbhsIgPmUo4F igpIIqrhZzZ1PvlFYszX+Mqw657WSjg02qvIB87TlUWnzRKhQNYqbqxpnCs5i29KHdCpwZ H2D7CnNZ6/vJCi7LcZ67tCoHpc5S5Zo= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1736881097; a=rsa-sha256; cv=none; b=E3JMwrPhQ3mNrkbO3F4idGmK+cXLwrVXjEOqvsnw/jCkduDhRtIvCIiSMCCkGOov9ln1Z4 mBdaN2wc2uukBMz1d6FC9HhX3ITtNOf01UC3Ls1F+z1bwqg2z3YVMMHLYBXFPjwXFuBYFM 5rqt5hv+GhATRZz8Q/tZvQpYHoG/5oE= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=e1lLQlZd; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf26.hostedemail.com: domain of joannelkoong@gmail.com designates 209.85.160.171 as permitted sender) smtp.mailfrom=joannelkoong@gmail.com Received: by mail-qt1-f171.google.com with SMTP id d75a77b69052e-46769b34cbfso83278021cf.0 for ; Tue, 14 Jan 2025 10:58:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1736881097; x=1737485897; 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=Z7AHvURHt1sKIC0K/sgbG2CCAchF8Mz6y7cTbsB1kc0=; b=e1lLQlZdQlJUF/SEpG0wRtna2737viqbsxunuVWIRtfNuCqNXGj91umkvlJE0qndqD o8gXU7tSQgO7ZETH3D4UJFMZcF+GXkjDbNCcN/WpGHLGRx/bBCfB7Khrz84ViyGMlWqR pyf669fTAdUsHZPucLMEbGQtVQQ/vdPbOcSAmVCAlNdNpUaCKr0kwgMiQAb2QKX1Z1tz Z9sul7wkfRDyXqR7UcKpLrN7SR0aeuQBsflA/nq5QuEHaLMS26x1nl8dz6OBEHFFNPzI tbfrNet15JMaVnP29hK3usQx+0U0l7dzYiWFiuo8jgOdtZk7bgLuxlhu/E4W/ElBVXvM pZrg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736881097; x=1737485897; 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=Z7AHvURHt1sKIC0K/sgbG2CCAchF8Mz6y7cTbsB1kc0=; b=IDtEheiGeeMvOssHHwP5Iku7Ris9f9NJHVPHsvCLTLswlurAt7naQsrych4F/RE9Qj LNMThbQVEHNlzryAKB7ePWipHdmLVoqQssxQUtyv2pBLNcqoe0aXczUnGI+qRi+LfYHy dOjVM5Y/4uCUj7j+oVk2HpERhM7b5UTainfk9s1++qXV74GGZiLioGuKKEQZiR1fVRZ2 eXm+qBYw1z85XTurisIOcYRlOG0fY9oYXl1Ka9RXdALwxDWBXZHXELQluZGVE/sBJBz0 YZ7YvnVnD5fkQ3QrmsyOyZLDfvaw2YRT48eBBQZEcYfBKfL7wS+HPctM4XiiE7L8YZxU fGGQ== X-Forwarded-Encrypted: i=1; AJvYcCU4EpKI+d14wD/3K1b7iDdHzzaB7GsAU1SzyiBZ0fcNawoqQhWuky1lZLmVSF3tbqCGEmBv7GRQEg==@kvack.org X-Gm-Message-State: AOJu0Yz1YHAaGeMY5HvkiPW5JcV0q0MCXk2FsGFMRFJxwcj9cKqh8nNE 2arxE8PxVnomUMK2F4PT/RsngdC4L+DBHXLglq9GBFoAZUiAoeUFZY1LwZ9rn93gQV0s9OQcwlG XJCm0ZVpIIrcrhrPhOkdhVWjSvHE= X-Gm-Gg: ASbGncsME5J5QHZ90AZYaGFCLpsbGUb/61cg//zwjtFpBBKh/wyBmt0ZcD32WnvvNZW mCizxvsaxL1tmdfhQxt7MAtaT+w2etLXAvwgSzl0= X-Google-Smtp-Source: AGHT+IE4Rh/65OQNsqN594Fzvl9PsXE8GDgTzXWH2A1d9OdMFSVVx2oCrnq5vsEhCqmx2aLdBGxS2pkGyg/ZFOdXlPc= X-Received: by 2002:a05:622a:1a83:b0:467:5d0b:c750 with SMTP id d75a77b69052e-46c7100592amr438305131cf.22.1736881096201; Tue, 14 Jan 2025 10:58:16 -0800 (PST) MIME-Version: 1.0 References: <791d4056-cac1-4477-a8e3-3a2392ed34db@redhat.com> <1fdc9d50-584c-45f4-9acd-3041d0b4b804@redhat.com> <54ebdef4205781d3351e4a38e5551046482dbba0.camel@kernel.org> <2848b566-3cae-4e89-916c-241508054402@redhat.com> In-Reply-To: From: Joanne Koong Date: Tue, 14 Jan 2025 10:58:04 -0800 X-Gm-Features: AbW1kvYm6u6PzLmjyHjCePO02piHbTxSPKYgO94EhEVGoQp0QMSeqzJZVjdSzfg Message-ID: Subject: Re: [PATCH v6 4/5] mm/migrate: skip migrating folios under writeback with AS_WRITEBACK_INDETERMINATE mappings To: Jeff Layton Cc: Miklos Szeredi , David Hildenbrand , Shakeel Butt , Bernd Schubert , Zi Yan , linux-fsdevel@vger.kernel.org, jefflexu@linux.alibaba.com, josef@toxicpanda.com, linux-mm@kvack.org, kernel-team@meta.com, Matthew Wilcox , Oscar Salvador , Michal Hocko Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Stat-Signature: ptncsbsdid6nip9g3q3jr7ne8uo1awuy X-Rspamd-Queue-Id: AA8BB140007 X-Rspam-User: X-Rspamd-Server: rspam01 X-HE-Tag: 1736881097-133850 X-HE-Meta: U2FsdGVkX19X94H21PVppdImqZy2dDKNmyg7yPm4wAn6wVcJUU6upk8Xl/e71JWVePyYReNZtWnmNoi3lI2vvjPxEoyh3H1f6V5u8K881xnzHDiFOUFEqk7xi0SuZexNYwddcXafbULkIajqcHCdNiZAErXh0AgHjGp8JERTh7Bj7YDFT+TIkpKOV5wtYjU8FRVWgUgyz1eYWWCVQ7l+ZTba8nWZnSUozok/Lgl4kieNjK/tiraioPIsv/MfjPCPieL6O+FYObW5FZkgGqryRjPq/B5PyV+eOG4bryHABG8+M+hedgx2pEUWXZSAZGIFOhBgQEz8LYr6vKyhhNLCrtMKvs6s22iIkhMG7giFhcuFTtl1bHcZ9WRihf9ph0rE2rilVYUHSBf02ZZugLTiJv02IttIs/1NU9658wgRmqcLtrpk3xFWyA8H3YnELR2KEpkV5/ABWeDD43Ryy7B8V8kFKOmwqhvAcpVi6yZWn31UDm/+4vDL3Oq5rYPUGberQ+24d70506Dhcs2AdDZLnwNV9fUHkGEjyySyznukBvVFIbMZ+F0pYT4DXEDYOiq9/lh3dmzu9BvQr1/oMp+wyF5xSTJ5//aVfaSF27tT+tdQb/VsR6889Fy+quFHeL/bMVh9301E3+AmaRyOrUDxcxb93waC2L7JNASyFfswabv1+FyygyKyD8CI+zev5S6UtHB8yhcy5eCOtjpyhCQGdzkRSvidr6qS65WxSiBWkL//0xml0xpSwQ6JhUBb1tuv8Yj5eyBHzaRkdxnRuB3rc8T2qOZFDISl9j+FJi5vWzoz8NjsWRVmI5Xil3Imh+Q46DUAnrRixQUT+7N9+/6iS9L5R0srvtIrAHibBZgq7g0Z1tb5hVmtQcj55AXIl7C/IUwOQx4NhW3HqWWT8vhG/MJGpdYsYm/JxFvlpvsvH7xtaqGnXAS3ukruoz4K+utKzH/8V1Jc8lOQtRonYcg vp2oRNTJ IVNaSP6q2nsdOxR1w99RqWX1LDVXeZhqYZXT7HtEmjEt+XjpcV49LcqhFBLl4xDHpd/3g6717vp4QJfBEokG/A9XUvCEaVBopqaWhH90q269QEKFVeSGqfuKYf/zFr6gPz1sO7pgHdREeLRRRG+jAGJH7I7K5l5jRvAn1dYV6k4liBDkgXKrDIPaVa52hE2Nno56pSLDIlkZeri7nfNYfnARllxpij/3hb9Cp4Xo1XEaeD6SL0vZZ6XMEDMQdvA0j1uW9ajfE7PlmQ04e0xzK3ikRGibRGDF3WY/aneRqCPPZJ2qbjfS9q+paVaB+bEYEHa5UOu20iqOiNHuh2k9qRhl9mJVyflDXYiLTxvm4uXV6qDlY+v2f1g3AIL0LxEvAyi/BnRwS17p+PVs= 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 Tue, Jan 14, 2025 at 7:44=E2=80=AFAM Jeff Layton wr= ote: > > On Tue, 2025-01-14 at 09:38 +0100, Miklos Szeredi wrote: > > On Mon, 13 Jan 2025 at 22:44, Jeff Layton wrote: > > > > > What if we were to allow the kernel to kill off an unprivileged FUSE > > > server that was "misbehaving" [1], clean any dirty pagecache pages th= at > > > it has, and set writeback errors on the corresponding FUSE inodes [2]= ? > > > We'd still need a rather long timeout (on the order of at least a > > > minute or so, by default). > > > > How would this be different from Joanne's current request timeout patch= ? > > > > When the timeout pops with Joanne's set, the pages still remain dirty > (IIUC). The idea here would be that after a call times out and we've > decided the server is "misbehaving", we'd want to clean the pages and > mark the inode with a writeback error. That frees up the page to be > migrated, but a later msync or fsync should return an error. This is > the standard behavior for writeback errors on filesystems. I think the pages already get cleaned and the inode marked with an error in the case of a timeout. The timeout calls into the abort path, so the abort path should already be doing this. When the connection is aborted, fuse_request_end() will get invoked, which will call the req->args->end() callback which for writebacks will be fuse_writepage_end(). In fuse_writepage_end(), the inode->i_mapping gets set to the error code and the writeback state will be cleared on the folio as well (in fuse_writepage_finish()). > > > I think it makes sense, but it *has* to be opt in, for the same reason > > that NFS soft timeout is opt in, so it can't really solve the page > > migration issue generally. > > > > Does it really need to be though? We're talking unprivileged mounts > here. Imposing a hard timeout on reads or writes as a mechanism to > limit resource consumption by an unprivileged user seems like a > reasonable thing to do. Writeback errors suck, but what other recourse > do we have in this situation? > > We could also consider only enforcing this when memory gets low, or a > migration has failed. > I think there's a case to be made here that this "resource checking" of unprivileged mounts should be behavior that already exists (eg automatically enforcing timeouts instead of only by opt-in). The only issue with this I see is that it might potentially break backwards-compatibility, but I think it could be argued that protecting memory resources outweighs that. Though the timeout would have to be somewhat large, and I don't know if that would be acceptable for migration. Thanks, Joanne > > Also page reading has exactly the same issues, so fixing writeback is > > not enough. > > > > Reads are synchronous, so we could just return an error directly on > those. > > > Maybe an explicit callback from the migration code to the filesystem > > would work. I.e. move the complexity of dealing with migration for > > problematic filesystems (netfs/fuse) to the filesystem itself. I'm > > not sure how this would actually look, as I'm unfamiliar with the > > details of page migration, but I guess it shouldn't be too difficult > > to implement for fuse at least. > > > > We already have a ->migrate_folio operation. Maybe we could consider > pushing down the PG_writeback check into the ->migrate_folio ops? As an > initial step, we could just make them all return -EBUSY, and then allow > some (like FUSE) to handle the situation properly. > -- > Jeff Layton