linux-kernel - Re: [PATCH v3] mm/pagewalk.c: walk_page_range should avoid VM

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-prev] [day] [month] [year] [list]

Message-Id: <20130523164018.bed0409e29b46901bcc67960@linux-foundation.org>
Date:	Thu, 23 May 2013 16:40:18 -0700
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Cliff Wickman <cpw@....com>
Cc:	linux-kernel@...r.kernel.org, mgorman@...e.de, aarcange@...hat.com,
	dave.hansen@...el.com, dsterba@...e.cz, hannes@...xchg.org,
	kosaki.motohiro@...il.com, kirill.shutemov@...ux.intel.com,
	mpm@...enic.com, n-horiguchi@...jp.nec.com, rdunlap@...radead.org
Subject: Re: [PATCH v3] mm/pagewalk.c: walk_page_range should avoid
 VM_PFNMAP areas

On Wed, 15 May 2013 07:46:36 -0500 Cliff Wickman <cpw@....com> wrote:

> Certain tests in walk_page_range() (specifically split_huge_page_pmd())
> assume that all the mapped PFN's are backed with page structures. And this is
> not usually true for VM_PFNMAP areas. This can result in panics on kernel
> page faults when attempting to address those page structures.
> 
> There are a half dozen callers of walk_page_range() that walk through
> a task's entire page table (as N. Horiguchi pointed out). So rather than
> change all of them, this patch changes just walk_page_range() to ignore 
> VM_PFNMAP areas.
> 
> The logic of hugetlb_vma() is moved back into walk_page_range(), as we
> want to test any vma in the range.
> 
> VM_PFNMAP areas are used by:
> - graphics memory manager   gpu/drm/drm_gem.c
> - global reference unit     sgi-gru/grufile.c
> - sgi special memory        char/mspec.c
> - and probably several out-of-tree modules

What are your thoughts on the urgency/scheduling of this fix?


(Just to be irritating: "When writing a changelog, please describe the
end-user-visible effects of the bug, so that others can more easily
decide which kernel version(s) should be fixed, and so that downstream
kernel maintainers can more easily work out whether this patch will fix
a problem which they or their customers are observing.")
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/