[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <20200408115926.1467567-1-hch@lst.de>
Date: Wed, 8 Apr 2020 13:58:58 +0200
From: Christoph Hellwig <hch@....de>
To: Andrew Morton <akpm@...ux-foundation.org>,
"K. Y. Srinivasan" <kys@...rosoft.com>,
Haiyang Zhang <haiyangz@...rosoft.com>,
Stephen Hemminger <sthemmin@...rosoft.com>,
Wei Liu <wei.liu@...nel.org>, x86@...nel.org,
David Airlie <airlied@...ux.ie>,
Daniel Vetter <daniel@...ll.ch>,
Laura Abbott <labbott@...hat.com>,
Sumit Semwal <sumit.semwal@...aro.org>,
Sakari Ailus <sakari.ailus@...ux.intel.com>,
Minchan Kim <minchan@...nel.org>,
Nitin Gupta <ngupta@...are.org>
Cc: Robin Murphy <robin.murphy@....com>,
Christophe Leroy <christophe.leroy@....fr>,
Peter Zijlstra <peterz@...radead.org>,
linuxppc-dev@...ts.ozlabs.org, linux-hyperv@...r.kernel.org,
dri-devel@...ts.freedesktop.org, linaro-mm-sig@...ts.linaro.org,
linux-arch@...r.kernel.org, linux-mm@...ck.org,
iommu@...ts.linux-foundation.org,
linux-arm-kernel@...ts.infradead.org, linux-s390@...r.kernel.org,
bpf@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: decruft the vmalloc API
Hi all,
Peter noticed that with some dumb luck you can toast the kernel address
space with exported vmalloc symbols.
I used this as an opportunity to decruft the vmalloc.c API and make it
much more systematic. This also removes any chance to create vmalloc
mappings outside the designated areas or using executable permissions
from modules. Besides that it removes more than 300 lines of code.
A git tree is also available here:
git://git.infradead.org/users/hch/misc.git sanitize-vmalloc-api
Gitweb:
http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/sanitize-vmalloc-api
Powered by blists - more mailing lists