linux-kernel - Re: [PATCH v3 1/3] btrfs: use bdev_rw_virt() to read and scratch the disk super block

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <38777db8-f90b-4437-988d-558231747750@suse.com>
Date: Sat, 10 Jan 2026 16:32:52 +1030
From: Qu Wenruo <wqu@...e.com>
To: Matthew Wilcox <willy@...radead.org>
Cc: linux-btrfs@...r.kernel.org, linux-mm@...ck.org,
 linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
 Johannes Thumshirn <johannes.thumshirn@....com>
Subject: Re: [PATCH v3 1/3] btrfs: use bdev_rw_virt() to read and scratch the
 disk super block



在 2026/1/10 16:26, Matthew Wilcox 写道:
> On Sat, Jan 10, 2026 at 02:26:19PM +1030, Qu Wenruo wrote:
>> Furthermore read_cache_page*() can race with device block size setting,
>> thus requires extra locking.
> 
> What?  There's supposed to be sufficient locking to prevent this.
> Is there a bug report I can look at?

The comment of read_cache_page_gfp() already mentions that invalidate 
lock is required, but we didn't hold inside btrfs, and it's already 
fixed now, nothing to be worried from mm side:

https://lore.kernel.org/linux-btrfs/tencent_A63C4B6C74A576F566AA3C0B37CE96AC3609@qq.com/

This report and fix just reminds me to finally push the series to get 
rid of read_cache_page_gfp() completely.

Thanks,
Qu