From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-dl1-f48.google.com (mail-dl1-f48.google.com [74.125.82.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D0A1D1F30A4 for ; Sat, 31 Jan 2026 01:31:47 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.82.48 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769823109; cv=none; b=MWpJ7u1Lmr/4Ns2YwBH3NEvcYxCYDh4UhHa6GQF+oUc3oCZTVA4guEYp47pAX8j779ZktaLRgM9p4tU4l0x8nG3DrZK99ZfbI8rHIexr/lTXuhyvNgOFEGpzisEjLkY4TU7bSiDIeVng91dcB48wNTiKeqyvvEjuOK5DvWFVxDk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769823109; c=relaxed/simple; bh=uxSptuxlUKEWbRT4Igc31bABpRpRKBUi1VOuQjhIz3M=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=hLy9NO+rbmDqfHY9Hbq50GHwacciQtrB/s35aym3huz/ytvo+MjNd2sqCHKyKqGIKUT2jOu7FymvKuV8X4QLnvKj57vAm7Pk709MXCTI9mCmOC7ZcLac3GodwWpz8SYgvDuHsikRrvuYIvd/Rhlb+hF1I4AI3AbzCFU6ENvPdFU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=F5v7s4RF; arc=none smtp.client-ip=74.125.82.48 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="F5v7s4RF" Received: by mail-dl1-f48.google.com with SMTP id a92af1059eb24-1248d27f293so4210403c88.0 for ; Fri, 30 Jan 2026 17:31:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1769823107; x=1770427907; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=MjS5gUmrvNUnt6r0vg+c+3hL04GhprNpFcL6xVhUsws=; b=F5v7s4RFW8lc3h8rSc+Bm/hPByCo6FLA6lqBA7e0dL1XIoMeUd5xAbOyKHx2jXvLF1 07x0uluV1v0S+wDlNCeJ+HoQz9ah9w+a0XJx5O78NraA8zl8CCjU/vWGPaEF01WCU2nq 2Qlj7CSr8MRKsRKgoqX892Yz1DPTPVNHumprNcNWbLFXSZRhCYl09ChC7qDy8ASOnblG SXvEDeG5isOd97Adi1SH2ybSB/OKzEHEgW35tOoOQazufr26M31q8cVaquZryaJAyaW0 +UgFrzrn+v232nbYUqGTaAbbkyjjKZkr/RuOUPmOLzBzBD8vexfbPSV+upYuXj0DSGis mONg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769823107; x=1770427907; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=MjS5gUmrvNUnt6r0vg+c+3hL04GhprNpFcL6xVhUsws=; b=db9Z0jyp/pZ6H+YvRXClPA5lmH5dSoyyLWulg0ZjRp2uMXFUuTqUy55vy/9bXz4WtO 7aGgQqTHP3Rkegz1ynqeEC7inZAYdQ6ZAkctHyYmTgOAFV3/tvj1ile4wPrsZGviZzhR MihLs/kiwjQPjjrqvHL8o7R3cnJHOIfvyB26tOsA9LmoGw28RQu/9pkJ6MZapff+CB2T YE2wy1LKSiGaIIH+4WsLm9atkkyThTIDG3e9Yn0/7+Vt6Pk8hvMrREdtPLvUMwaErPF+ QoA3IIt5CrCZe6LauYXDfKyqoUad4+JxhFOXW2Lmf8dMxQeSSZu0wXEXj5ENMx0NTNKw FzDw== X-Forwarded-Encrypted: i=1; AJvYcCWBsYDD3vPYp1LDl5QdQw1E8aDczYMvlyLMrIQtYxd2XYtpPPN+Bh9Z6JPStx84oEahfvJ1MATlXXKVDE8=@vger.kernel.org X-Gm-Message-State: AOJu0YxtIXna/To5rDHVUV5j+6dpCP7SMothP7JmFxd6wrNKSGhw8t70 U6dRkCjuFie4taRDOKRLltgj2wlpLckoXiJTM3kmKeNEtNY68QdIrMb7 X-Gm-Gg: AZuq6aJFQMU67B1GGYYUwEOSCVoqD8+v+cLKPr3vdjCZQgQ938BaPDDWqhozpo72Xd3 TzlOrUENKknkYRf/Ya59q+TPUcNKt3FYUZJYTe0NbAzVAxbevTgXAuf9Pm48LCvHvSegk0ItdXy IY14WcCzF1gflS4dqOabiKlkllBv2ho4oDPMjb3ZUo6RMCwOxQj2QSee5OprMD5TiTz9PMJ/y64 7qXYnYQLeZ/wR0iFaHYehSIxzYWlMknDYVgUy71aeYJvwd8d05Hq5ah7oAFhQqCAQnWb/bQE9Bd nFyL7kwt+/b2ypBpHGwiCAO/Y/EKzsG4nF7wdNndZQiby/pdE5oDi6CzFK/6f0n9G0k0XC0Tfh8 fTAp2U7iGdba37weVolMvEcCRGyNbBtCJMAuWs9ri9YsTRpHZaOiZVg8y+8K3zOJu2XKgJ3scWW MtUj5m/xE4hhy7OX+GWkPUBqE= X-Received: by 2002:a05:7022:2488:b0:119:e56b:c762 with SMTP id a92af1059eb24-125c1014ed5mr2266211c88.39.1769823106769; Fri, 30 Jan 2026 17:31:46 -0800 (PST) Received: from [172.25.67.25] ([172.59.130.240]) by smtp.gmail.com with ESMTPSA id a92af1059eb24-124a9e0304bsm12535789c88.14.2026.01.30.17.31.45 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 30 Jan 2026 17:31:46 -0800 (PST) Message-ID: <96d01e75-337b-45cf-9950-e5d4a2981921@gmail.com> Date: Fri, 30 Jan 2026 17:31:39 -0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC PATCH] btrfs: defer freeing of subpage private state to free_folio To: Qu Wenruo , Matthew Wilcox Cc: boris@bur.io, clm@fb.com, dsterba@suse.com, linux-btrfs@vger.kernel.org, linux-kernel@vger.kernel.org, kernel-team@meta.com, "linux-fsdevel@vger.kernel.org" References: <20260129230822.168034-1-inwardvessel@gmail.com> <776e54f6-c9b7-4b22-bde5-561dc65c9be7@gmx.com> <00d098da-0d01-43f9-9efb-c18b6e8a771e@gmail.com> Content-Language: en-US From: JP Kobryn In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 1/30/26 12:36 PM, Qu Wenruo wrote: > > > 在 2026/1/31 03:40, JP Kobryn 写道: >> On 1/29/26 9:14 PM, Matthew Wilcox wrote: >>> On Fri, Jan 30, 2026 at 01:46:59PM +1030, Qu Wenruo wrote: >>>> Another question is, why only two fses (nfs for dir inode, and >>>> orangefs) are >>>> utilizing the free_folio() callback. >>> >>> Alas, secretmem and guest_memfd are also using it.  Nevertheless, I'm >>> not a fan of this interface existing, and would prefer to not introduce >>> new users.  Like launder_folio, which btrfs has also mistakenly used. >>> >> >> The part that felt concerning is how the private state is lost. If >> release_folio() frees this state but the folio persists in the cache, >> users of the folio afterward have to recreate the state. Is that the >> expectation on how filesystems should handle this situation? > > I believe that's the case. > > Just like what we did in btrfs_do_readpage() and prepare_one_folio(). > > There is no difference between getting a new page and a page that is > released but not removed from the filemap. > >> >> In the case of the existing btrfs code, when the state is recreated (in >> subpage mode), the bitmap data and lock states are all zeroed. > > That's expected. > Thanks all for the feedback. I get it now that we should treat it like a fresh folio where applicable. With that said, I may have found a path where unguarded access to the private field is happening. I'll send a patch shortly and you can let me know your thoughts.