linux-kernel - Regression after commit 19809c2da28a ("mm, vmalloc: use __GFP

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 for Android: free password hash cracker in your pocket

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

Date:   Thu, 8 Feb 2018 14:29:57 +0800
From:   Kai Heng Feng <kai.heng.feng@...onical.com>
To:     Michal Hocko <mhocko@...e.com>, Laura Abbott <labbott@...hat.com>
Cc:     linux-mm@...ck.org,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Regression after commit 19809c2da28a ("mm, vmalloc: use __GFP_HIGHMEM
 implicitly")

A user with i386 instead of AMD64 machine reports [1] that commit 19809c2da28a ("mm, vmalloc: use __GFP_HIGHMEM implicitly”) causes a regression.
BUG_ON(PageHighMem(pg)) in drivers/media/common/saa7146/saa7146_core.c always gets triggered after that commit.

Commit 704b862f9efd ("mm/vmalloc.c: don't unconditonally use __GFP_HIGHMEM”) adjusts the mask logic, now the __GFP_HIGHMEM only gets applied when there is no GFP_DMA or GFP_DMA32.

So I tried to adjust its malloc to "__vmalloc(nr_pages * sizeof(struct scatterlist), GFP_KERNEL | GFP_DMA | __GFP_ZERO, PAGE_KERNEL)”, but both GFP_DMA or GFP_DMA32 still trigger the BUG_ON(PageHighMem()) macro.

Also there are other BUG_ON(PageHighMem()) in drivers/media, I think they will get hit by same regression in 32bit machine too.

[1] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1742316

Kai-Heng