On 3/23/23 11:08, David Hildenbrand wrote:
On 23.03.23 10:52, Vlastimil Babka wrote:
On 2/3/22 19:26, Yang Shi wrote:
--- a/fs/proc/task_mmu.c +++ b/fs/proc/task_mmu.c @@ -440,7 +440,8 @@ static void smaps_page_accumulate(struct mem_size_stats *mss, } static void smaps_account(struct mem_size_stats *mss, struct page *page,
bool compound, bool young, bool dirty, bool locked)
bool compound, bool young, bool dirty, bool locked,bool migration)@@ -467,8 +468,15 @@ static void smaps_account(struct mem_size_stats *mss, struct page *page, * page_count(page) == 1 guarantees the page is mapped exactly once. * If any subpage of the compound page mapped with PTE it would elevate * page_count().
** The page_mapcount() is called to get a snapshot of the mapcount.* Without holding the page lock this snapshot can be slightly wrong as* we cannot always read the mapcount atomically. It is not safe to* call page_mapcount() even with PTL held if the page is not mapped,* especially for migration entries. Treat regular migration entries* as mapcount == 1.
- if (page_count(page) == 1) {
- if ((page_count(page) == 1) || migration) {
Since this is now apparently a CVE-2023-1582 for whatever RHeasons...
wonder if the patch actually works as intended when (page_count() || migration) is in this particular order and not the other one?
Only the page_mapcount() call to a page that should be problematic, not the page_count() call. There might be the rare chance of the page
Oh right, page_mapcount() vs page_count(), I need more coffee.
getting remove due to memory offlining... but we're still holding the page table lock with the migration entry, so we should be protected against that.
Regarding the CVE, IIUC the main reason for the CVE should be RHEL-specific -- which behaves differently than other code bases; for other code bases, it's just a way to trigger a BUG_ON as described here.
That's good to know so at least my bogus mail was useful for that, thanks!