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 524ADE77188 for ; Fri, 10 Jan 2025 21:21:25 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 933C46B00B4; Fri, 10 Jan 2025 16:21:24 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 8E4656B00B5; Fri, 10 Jan 2025 16:21:24 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 736566B00B6; Fri, 10 Jan 2025 16:21:24 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 59B9F6B00B4 for ; Fri, 10 Jan 2025 16:21:24 -0500 (EST) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 0655180DB7 for ; Fri, 10 Jan 2025 21:21:24 +0000 (UTC) X-FDA: 82992813288.04.2A541FC Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf29.hostedemail.com (Postfix) with ESMTP id 0D45C120007 for ; Fri, 10 Jan 2025 21:21:19 +0000 (UTC) Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=f+AUIfbJ; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf29.hostedemail.com: domain of david@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=david@redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1736544081; a=rsa-sha256; cv=none; b=VpMxzt6ieFur06dtD7b5Qm2LbDhBCGhUJfkMQB4UIgaAyHBl03djujUsEne2d5Rf+GshQm dhHOj5jOcLEsqu+WZ+BqqVUy4AKIOds8Le5Jasvd4EDuCnFBMRPKK0sTjSMNbQ9CKT8ZI7 UoOmEhtN42UWxvEVUyTVUWaDlb/4R4M= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=f+AUIfbJ; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf29.hostedemail.com: domain of david@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=david@redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1736544081; 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=sthEKVmb10XAo4rNGJPWmHpmDGbVRVERpD7LcYoTGpY=; b=bysqY1IWdZPtoVZirs4/dDnKAwx1R3W7mSv+TNlrA3tFxPB82UuART6dhhSGNOH3qP0din 7gQKas/Q9LyRaCO4hKPlERYi6OmqGu9UH5+cKacO8guVRyhK040cDBeFbO78Mtk1kwLE9l s/lmBJxac1hh2YXonrkNfY4LSg54JSk= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1736544079; h=from:from: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:autocrypt:autocrypt; bh=sthEKVmb10XAo4rNGJPWmHpmDGbVRVERpD7LcYoTGpY=; b=f+AUIfbJMNC9gurZRCT4boLXE8qYhlr7vyZtbV20H9xbc4m1PE/bnydmMtCet0NjgQhDnX gjLAn4fSBvrs/2yvzfS6E6djSJvjn5yFjnD2EDPqnZT8UprbXAxVAcMczcCH+yTWk9n+3c 4Z3vzt5TuOPhb0NRrbR/6mVLWj8FzoM= Received: from mail-wm1-f69.google.com (mail-wm1-f69.google.com [209.85.128.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-70--LKRdWyyNrm_KOy_G_c5nQ-1; Fri, 10 Jan 2025 16:21:15 -0500 X-MC-Unique: -LKRdWyyNrm_KOy_G_c5nQ-1 X-Mimecast-MFC-AGG-ID: -LKRdWyyNrm_KOy_G_c5nQ Received: by mail-wm1-f69.google.com with SMTP id 5b1f17b1804b1-43626224274so13707035e9.0 for ; Fri, 10 Jan 2025 13:21:15 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736544074; x=1737148874; h=content-transfer-encoding:in-reply-to:organization:autocrypt :content-language:from:references:cc:to:subject:user-agent :mime-version:date:message-id:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to; bh=sthEKVmb10XAo4rNGJPWmHpmDGbVRVERpD7LcYoTGpY=; b=cWkl8NRjmvO3Ynqpd9HifgEXsEZ+pIL4nQQScCzVZreCiV/Ik9pHwVdT7T2Zh1RLLw 1b8ekzdcSOuNz0UJ9nnUwiJhQjNieA2OuwK37/O7K7DAHlG5K1Nr8SIBlaEDBjwbfDOX QAc/mAUoNrVlovfZdR4sZjNhr1bphENkVmLgaWURQlDP4waBdmt0G7WGZRse1Bov/fcq HowGdD6pHvBiDzO909uzmMk91g63lEwM9njlq2cswNw/zLazs8Uhr6+/VUSQ72XRy+og we8iflEAcMc6c/QbEVOtVPv/j9nvYIRD9j0/vUZh9rCn4JcGbDbleVlPjYV2pjS/DVGg YI5Q== X-Forwarded-Encrypted: i=1; AJvYcCWcSrqH8+R30Bi86r2pFMCttb+NnmiFVtnN9Wh8nxoPkyg9ebL/gn7fHlWIZ9okAyUkKOoSRip0XQ==@kvack.org X-Gm-Message-State: AOJu0YxSoHCrpjMNvhxgQ6wZ3BIzYKrkiE9uSmxCUdi2duWFvxGCyJwU mmlCqOn9HuU0Sl6YKG6OzFMuTH+hakpNIPPwkQtFhdVlaWw4yOVgDYZqYBIHktcaS35ycv2TmWp 8GnLJcNj92G0SdHUxYtx3aUK3lXBnkWNzUga53QCZ5MtydwbC X-Gm-Gg: ASbGnct+xaDItrwA/5drxKobEfB9DBzAAENwm83Wh0syyMsmmda4/ENalpCCsM/SxbG n/U/Q8KdJwRCnpjOHXsOX5xfwwuZlZRNh/7uIUOMGw/VXdBRx9vsBZazMGrId3NRDopgImTOcX4 LrhrGG4mcMFy4YR9w0269EC1EKlceKRlpXo/6cJs0d6roJ19T3vUE9CRYOFHNwcYO/KZITSpx4l 3X8iMhX5wXAMP+n3StXoQGZCXBOv7MeiDEPN4F8DF0faKp88fH5N5PY0uAiv+3k8nAiLrd/wL5P tvZAkS9HRaT81nptjhn9DrNd7PFCQ95AzAao3zGg+LgqVjbEWRvSD5oy/knzBh2KNKQbJbv/zqt HIEBNZYLy X-Received: by 2002:a05:600c:5698:b0:434:a7f1:6545 with SMTP id 5b1f17b1804b1-436e2d91910mr101284945e9.27.1736544074652; Fri, 10 Jan 2025 13:21:14 -0800 (PST) X-Google-Smtp-Source: AGHT+IFJ8wFczgFhHwFzj/WleUwk7pix9NascQqOgaTNxpuzbcw4rPO0K0tR8E5rTCDbNHnYqRI57w== X-Received: by 2002:a05:600c:5698:b0:434:a7f1:6545 with SMTP id 5b1f17b1804b1-436e2d91910mr101284755e9.27.1736544074165; Fri, 10 Jan 2025 13:21:14 -0800 (PST) Received: from ?IPV6:2003:cb:c708:e100:4f41:ff29:a59f:8c7a? (p200300cbc708e1004f41ff29a59f8c7a.dip0.t-ipconnect.de. [2003:cb:c708:e100:4f41:ff29:a59f:8c7a]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-436e2da66e6sm98625705e9.4.2025.01.10.13.21.11 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 10 Jan 2025 13:21:12 -0800 (PST) Message-ID: Date: Fri, 10 Jan 2025 22:21:10 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v6 4/5] mm/migrate: skip migrating folios under writeback with AS_WRITEBACK_INDETERMINATE mappings To: Jeff Layton , Shakeel Butt , Miklos Szeredi Cc: Joanne Koong , 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 References: <0ed5241e-10af-43ee-baaf-87a5b4dc9694@redhat.com> <446704ab-434e-45ac-a062-45fef78815e4@redhat.com> <791d4056-cac1-4477-a8e3-3a2392ed34db@redhat.com> <153c5a4f08daf60e1bbbdde02975392dc608cfdf.camel@kernel.org> <47fff939fc1fb3153af5b129be600a018c8485e9.camel@kernel.org> <956ae3eba9ef549d4f1ab3dff9e0bb09a39101b2.camel@kernel.org> From: David Hildenbrand Autocrypt: addr=david@redhat.com; keydata= xsFNBFXLn5EBEAC+zYvAFJxCBY9Tr1xZgcESmxVNI/0ffzE/ZQOiHJl6mGkmA1R7/uUpiCjJ dBrn+lhhOYjjNefFQou6478faXE6o2AhmebqT4KiQoUQFV4R7y1KMEKoSyy8hQaK1umALTdL QZLQMzNE74ap+GDK0wnacPQFpcG1AE9RMq3aeErY5tujekBS32jfC/7AnH7I0v1v1TbbK3Gp XNeiN4QroO+5qaSr0ID2sz5jtBLRb15RMre27E1ImpaIv2Jw8NJgW0k/D1RyKCwaTsgRdwuK Kx/Y91XuSBdz0uOyU/S8kM1+ag0wvsGlpBVxRR/xw/E8M7TEwuCZQArqqTCmkG6HGcXFT0V9 PXFNNgV5jXMQRwU0O/ztJIQqsE5LsUomE//bLwzj9IVsaQpKDqW6TAPjcdBDPLHvriq7kGjt WhVhdl0qEYB8lkBEU7V2Yb+SYhmhpDrti9Fq1EsmhiHSkxJcGREoMK/63r9WLZYI3+4W2rAc UucZa4OT27U5ZISjNg3Ev0rxU5UH2/pT4wJCfxwocmqaRr6UYmrtZmND89X0KigoFD/XSeVv jwBRNjPAubK9/k5NoRrYqztM9W6sJqrH8+UWZ1Idd/DdmogJh0gNC0+N42Za9yBRURfIdKSb B3JfpUqcWwE7vUaYrHG1nw54pLUoPG6sAA7Mehl3nd4pZUALHwARAQABzSREYXZpZCBIaWxk ZW5icmFuZCA8ZGF2aWRAcmVkaGF0LmNvbT7CwZgEEwEIAEICGwMGCwkIBwMCBhUIAgkKCwQW AgMBAh4BAheAAhkBFiEEG9nKrXNcTDpGDfzKTd4Q9wD/g1oFAl8Ox4kFCRKpKXgACgkQTd4Q 9wD/g1oHcA//a6Tj7SBNjFNM1iNhWUo1lxAja0lpSodSnB2g4FCZ4R61SBR4l/psBL73xktp rDHrx4aSpwkRP6Epu6mLvhlfjmkRG4OynJ5HG1gfv7RJJfnUdUM1z5kdS8JBrOhMJS2c/gPf wv1TGRq2XdMPnfY2o0CxRqpcLkx4vBODvJGl2mQyJF/gPepdDfcT8/PY9BJ7FL6Hrq1gnAo4 3Iv9qV0JiT2wmZciNyYQhmA1V6dyTRiQ4YAc31zOo2IM+xisPzeSHgw3ONY/XhYvfZ9r7W1l pNQdc2G+o4Di9NPFHQQhDw3YTRR1opJaTlRDzxYxzU6ZnUUBghxt9cwUWTpfCktkMZiPSDGd KgQBjnweV2jw9UOTxjb4LXqDjmSNkjDdQUOU69jGMUXgihvo4zhYcMX8F5gWdRtMR7DzW/YE BgVcyxNkMIXoY1aYj6npHYiNQesQlqjU6azjbH70/SXKM5tNRplgW8TNprMDuntdvV9wNkFs 9TyM02V5aWxFfI42+aivc4KEw69SE9KXwC7FSf5wXzuTot97N9Phj/Z3+jx443jo2NR34XgF 89cct7wJMjOF7bBefo0fPPZQuIma0Zym71cP61OP/i11ahNye6HGKfxGCOcs5wW9kRQEk8P9 M/k2wt3mt/fCQnuP/mWutNPt95w9wSsUyATLmtNrwccz63XOwU0EVcufkQEQAOfX3n0g0fZz Bgm/S2zF/kxQKCEKP8ID+Vz8sy2GpDvveBq4H2Y34XWsT1zLJdvqPI4af4ZSMxuerWjXbVWb T6d4odQIG0fKx4F8NccDqbgHeZRNajXeeJ3R7gAzvWvQNLz4piHrO/B4tf8svmRBL0ZB5P5A 2uhdwLU3NZuK22zpNn4is87BPWF8HhY0L5fafgDMOqnf4guJVJPYNPhUFzXUbPqOKOkL8ojk CXxkOFHAbjstSK5Ca3fKquY3rdX3DNo+EL7FvAiw1mUtS+5GeYE+RMnDCsVFm/C7kY8c2d0G NWkB9pJM5+mnIoFNxy7YBcldYATVeOHoY4LyaUWNnAvFYWp08dHWfZo9WCiJMuTfgtH9tc75 7QanMVdPt6fDK8UUXIBLQ2TWr/sQKE9xtFuEmoQGlE1l6bGaDnnMLcYu+Asp3kDT0w4zYGsx 5r6XQVRH4+5N6eHZiaeYtFOujp5n+pjBaQK7wUUjDilPQ5QMzIuCL4YjVoylWiBNknvQWBXS lQCWmavOT9sttGQXdPCC5ynI+1ymZC1ORZKANLnRAb0NH/UCzcsstw2TAkFnMEbo9Zu9w7Kv AxBQXWeXhJI9XQssfrf4Gusdqx8nPEpfOqCtbbwJMATbHyqLt7/oz/5deGuwxgb65pWIzufa N7eop7uh+6bezi+rugUI+w6DABEBAAHCwXwEGAEIACYCGwwWIQQb2cqtc1xMOkYN/MpN3hD3 AP+DWgUCXw7HsgUJEqkpoQAKCRBN3hD3AP+DWrrpD/4qS3dyVRxDcDHIlmguXjC1Q5tZTwNB boaBTPHSy/Nksu0eY7x6HfQJ3xajVH32Ms6t1trDQmPx2iP5+7iDsb7OKAb5eOS8h+BEBDeq 3ecsQDv0fFJOA9ag5O3LLNk+3x3q7e0uo06XMaY7UHS341ozXUUI7wC7iKfoUTv03iO9El5f XpNMx/YrIMduZ2+nd9Di7o5+KIwlb2mAB9sTNHdMrXesX8eBL6T9b+MZJk+mZuPxKNVfEQMQ a5SxUEADIPQTPNvBewdeI80yeOCrN+Zzwy/Mrx9EPeu59Y5vSJOx/z6OUImD/GhX7Xvkt3kq Er5KTrJz3++B6SH9pum9PuoE/k+nntJkNMmQpR4MCBaV/J9gIOPGodDKnjdng+mXliF3Ptu6 3oxc2RCyGzTlxyMwuc2U5Q7KtUNTdDe8T0uE+9b8BLMVQDDfJjqY0VVqSUwImzTDLX9S4g/8 kC4HRcclk8hpyhY2jKGluZO0awwTIMgVEzmTyBphDg/Gx7dZU1Xf8HFuE+UZ5UDHDTnwgv7E th6RC9+WrhDNspZ9fJjKWRbveQgUFCpe1sa77LAw+XFrKmBHXp9ZVIe90RMe2tRL06BGiRZr jPrnvUsUUsjRoRNJjKKA/REq+sAnhkNPPZ/NNMjaZ5b8Tovi8C0tmxiCHaQYqj7G2rgnT0kt WNyWQQ== Organization: Red Hat In-Reply-To: <956ae3eba9ef549d4f1ab3dff9e0bb09a39101b2.camel@kernel.org> X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: 06QHOjVpUR7FN4h0U-nJEy2dph-FRiJ7ngBuXXCU89s_1736544075 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspam-User: X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 0D45C120007 X-Stat-Signature: begbr1fu559d95r1njq8q9xu67f7jion X-HE-Tag: 1736544079-978621 X-HE-Meta: U2FsdGVkX19AYSplsx4zyam4vjJOez/KXU9TZyGk7rC6Kqjvxv5BYlszjuwyMoG/xNTBWKratPZaFAb+pKyYwlzDiLEf2nHUKd2FolYRRK/58bNBRBGiP0Hgeod3Nz2CSJ3tIiOmU3+rHhXSGFs95ij+W0jbKvojIueum6YdJ0LQJyHJcmAiISx5vy3INWsP29KFd6R80e/50jFmNx4LUJnbnc/+r+JhF1QhnGXzJ6kSuUGMBLTNkMQXJpCj0dFwkXvijkfEVhUaVjZcKELqTJS3MPQiixiTj2LobKKQFHJE6io5Kvbfa8pP8SXLhrqIAJv3z/DPgytz1tJnju+ZWzxNzTQ0pLWhyJRNuiCNvICtG/0U1Y2OXTKgrZdfJN2Z0e6UWKCgJIs1r/W8bLC7b8KhaY5joDRyw14A28RdPpX6wtGT5ua8R/9PvmsS5RTGXI6Ro4fwq1O3jT9q015XLPEDCorEwJioCN2hulGnoAd5pZrA+2LDY3Zx79y0nWKWnd2tIC8EfdRnbODxzmzd9RZV0nA2oZeXPXHMA8bdAZnoudZQZ5KOcnxFLgIKVdZnpc8jG7+T/jViciHTOWE2bJkx34CjjVkFTMMBJPkqkPm7WkQs4HbfSl3vvGPtu637Vuz8sPi6roKDZeJ9a5V5mTmMCPLIZVV5mLF1sevtJc6VW44TGrcQvmwIDqF9zW/Xqcz4o0+6FeY5YYzdAKGWPpIFXhk6i1tSsTo3RvSUXosX7SK+Zy/HpsK6e0VhMI9VnGXdP0cVQvS325FXBS4RZTvq4vd/KRvJqzg2Uuo7GYnqMz1YaO09iBXWeytZFm3hhpILrW4XPrt5V0PeA2AYvx8ami1TnEKpr4/M2EmhCwH7HfDy/XSzqbk+td4aoMztKjjcTUD0s4WvXJ5JvFZqGi7ft5XCQ0DYSnuJgAK0MvxbM/AV0Z6EIG9l/SWRf+E4mb7Z9arjmLXL5dmKeZ6 HRs2hEH4 jQnQCpm/v58YZEOnyytH5UtbzjJfKeUUMBcbc795Zjh/Ihu0pojXVt1UB6+z0uuHwVRrIn+hW4S3F4dhGi+uok4FssUHjIhIP4uTiU5Rgm17Urz29LN9FnmXAhWb5GvZ4SvHPpqQB97KjS6ol9FodMKl+ZgBqm+4SAodwp1Igg1YLT/y8/3S/1gwHc07fJNNKZsbgvzvaffM+ka1QVZAo9PWk13FPnMXzpYGut/gY7uQod1V0lRaUW4yvvCgLK17sxhpK9ZWZPKwVAnxxjOYPqASN0PW8pVGUrI3WbRME1OKmlGf6t9ngur4VyCqkiAzNnjmA41CIwk22pxFsr6uv7jdpWKTWd2YYdTE6dWp+LAyxXBupz9CEfOrMRbqfIeXOWnyRLoEHHKDOd8eX7+1UmIuxO1tiwfGLQmtGz4oprhcadhUECrWjhMtBSqzgEHoudrulz4OzS674cVpciKflvISQ6g== 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 10.01.25 22:07, Jeff Layton wrote: > On Fri, 2025-01-10 at 22:00 +0100, David Hildenbrand wrote: >> On 10.01.25 21:43, Jeff Layton wrote: >>> On Fri, 2025-01-10 at 21:20 +0100, David Hildenbrand wrote: >>>> On 10.01.25 21:16, Jeff Layton wrote: >>>>> On Tue, 2025-01-07 at 09:34 +0100, David Hildenbrand wrote: >>>>>> On 06.01.25 19:17, Shakeel Butt wrote: >>>>>>> On Mon, Jan 06, 2025 at 11:19:42AM +0100, Miklos Szeredi wrote: >>>>>>>> On Fri, 3 Jan 2025 at 21:31, David Hildenbrand wrote: >>>>>>>>> In any case, having movable pages be turned unmovable due to persistent >>>>>>>>> writaback is something that must be fixed, not worked around. Likely a >>>>>>>>> good topic for LSF/MM. >>>>>>>> >>>>>>>> Yes, this seems a good cross fs-mm topic. >>>>>>>> >>>>>>>> So the issue discussed here is that movable pages used for fuse >>>>>>>> page-cache cause a problems when memory needs to be compacted. The >>>>>>>> problem is either that >>>>>>>> >>>>>>>> - the page is skipped, leaving the physical memory block unmovable >>>>>>>> >>>>>>>> - the compaction is blocked for an unbounded time >>>>>>>> >>>>>>>> While the new AS_WRITEBACK_INDETERMINATE could potentially make things >>>>>>>> worse, the same thing happens on readahead, since the new page can be >>>>>>>> locked for an indeterminate amount of time, which can also block >>>>>>>> compaction, right? >>>>>> >>>>>> Yes, as memory hotplug + virtio-mem maintainer my bigger concern is >>>>>> these pages residing in ZONE_MOVABLE / MIGRATE_CMA areas where there >>>>>> *must not be unmovable pages ever*. Not triggered by an untrusted >>>>>> source, not triggered by an trusted source. >>>>>> >>>>>> It's a violation of core-mm principles. >>>>>> >>>>>> Even if we have a timeout of 60s, making things like alloc_contig_page() >>>>>> wait for that long on writeback is broken and needs to be fixed. >>>>>> >>>>>> And the fix is not to skip these pages, that's a workaround. >>>>>> >>>>>> I'm hoping I can find an easy way to trigger this also with NFS. >>>>>> >>>>> >>>>> I imagine that you can just open a file and start writing to it, pull >>>>> the plug on the NFS server, and then issue a fsync or something to >>>>> ensure some writeback occurs. >>>> >>>> Yes, that's the plan, thanks! >>>> >>>>> >>>>> Any dirty pagecache folios should be stuck in writeback at that point. >>>>> The NFS client is also very patient about waiting for the server to >>>>> come back, so it should stay that way indefinitely. >>>> >>>> Yes, however the default timeout for UDP is fairly small (for TCP >>>> certainly much longer). So one thing I'd like to understand what that >>>> "cancel writeback -> redirty folio" on timeout does, and when it >>>> actually triggers with TCP vs UDP timeouts. >>>> >>> >>> >>> The lifetime of the pagecache pages is not at all related to the socket >>> lifetimes. IOW, the client can completely lose the connection to the >>> server and the page will just stay dirty until the connection can be >>> reestablished and the server responds. >> >> Right. It cannot get reclaimed while that is the case. >> >>> >>> The exception here is if you mount with "-o soft" in which case, an RPC >>> request will time out with an error after a major RPC timeout (usually >>> after a minute or so). See nfs(5) for the gory details of timeouts and >>> retransmission. The default is "-o hard" since that's necessary for >>> data-integrity in the face of spotty network connections. >>> >>> Once a soft mount has a writeback RPC time out, the folio is marked >>> clean and a writeback error is set on the mapping, so that fsync() will >>> return an error. >> >> I assume that's the code I stumbled over in nfs_page_async_flush(), >> where we end up calling folio_redirty_for_writepage() + >> nfs_redirty_request(), unless we run into a fatal error; in that case, >> we end up in nfs_write_error() where we set the mapping error and stop >> writeback using nfs_page_end_writeback(). >> > > Exactly. > > The upshot is that you can dirty NFS pages that will sit in the > pagecache indefinitely, if you can disrupt the connection to the server > indefinitely. This is substantially the same in other netfs's too -- > CIFS, Ceph, etc. > > The big difference vs FUSE is that they don't allow unprivileged users > to mount arbitrary filesystems, so it's a harder for an attacker to do > this with only a local unprivileged account to work with. Exactly my point/concern. With most netfs's I would assume that reliable connections are mandatory, otherwise you might be in bigger trouble, maybe one of the reasons being stuck forever waiting for writeback on folios was not identified as a problem so far. Maybe :) -- Cheers, David / dhildenb