[PATCH v4 1/4] device-dax: Don't leak kernel memory to user space after unloading kmem

Assume we have kmem configured and loaded: [root@localhost ~]# cat /proc/iomem ... 14000-33fff : Persistent Memory$ 14000-1481f : namespace0.0 15000-33fff : dax0.0 15000-33fff : System RAM Assume we try to unload kmem. This force-unloading will w

[PATCH v4 2/4] mm/memory_hotplug: Introduce add_memory_driver_managed()

Some device drivers rely on memory they managed to not get added to the initial (firmware) memmap as system RAM - so it's not used as initial system RAM by the kernel and the driver is under control. While this is the case during cold boot and after a reboot, kexec is not aware of that and might ad

[PATCH v4 3/4] kexec_file: Don't place kexec images on IORESOURCE_MEM_DRIVER_MANAGED

Memory flagged with IORESOURCE_MEM_DRIVER_MANAGED is special - it won't be part of the initial memmap of the kexec kernel and not all memory might be accessible. Don't place any kexec images onto it. Cc: Andrew Morton Cc: Michal Hocko Cc: Pankaj Gupta Cc: Wei Yang Cc: Baoquan He Cc: Dave Hans

[PATCH v4 4/4] device-dax: Add memory via add_memory_driver_managed()

Currently, when adding memory, we create entries in /sys/firmware/memmap/ as "System RAM". This will lead to kexec-tools to add that memory to the fixed-up initial memmap for a kexec kernel (loaded via kexec_load()). The memory will be considered initial System RAM by the kexec'd kernel and can no

[PATCH v4 0/4] mm/memory_hotplug: Interface to add driver-managed system ram

I did some more testing to v3 and found issues with unloading the kmem module, followed by reconfiguring the namespace. kexec (via kexec_load()) can currently not properly handle memory added via dax/kmem, and will have similar issues with virtio-mem. kexec-tools will currently add all memory to t

Re: [PATCH v2] kernel: add panic_on_taint

On Thu, May 07, 2020 at 10:25:58PM +, Luis Chamberlain wrote: > On Thu, May 07, 2020 at 06:06:06PM -0400, Rafael Aquini wrote: > > On Thu, May 07, 2020 at 08:33:40PM +, Luis Chamberlain wrote: > > > I *think* that a cmdline route to enable this would likely remove the > > > need for the ker

Re: [PATCH v4 1/4] device-dax: Don't leak kernel memory to user space after unloading kmem

On Fri, 8 May 2020 10:42:14 +0200 David Hildenbrand wrote: > Assume we have kmem configured and loaded: > [root@localhost ~]# cat /proc/iomem > ... > 14000-33fff : Persistent Memory$ > 14000-1481f : namespace0.0 > 15000-33fff : dax0.0 > 15000-33fff

Re: [PATCH 2/3] mm/memory_hotplug: Allow arch override of non boot memory resource names

On Thu, 26 Mar 2020 18:07:29 + James Morse wrote: > Memory added to the system by hotplug has a 'System RAM' resource created > for it. This is exposed to user-space via /proc/iomem. > > This poses problems for kexec on arm64. If kexec decides to place the > kernel in one of these newly onli

Re: [PATCH v2] kernel: add panic_on_taint

On Fri, May 08, 2020 at 08:47:19AM -0400, Rafael Aquini wrote: > On Thu, May 07, 2020 at 10:25:58PM +, Luis Chamberlain wrote: > > On Thu, May 07, 2020 at 06:06:06PM -0400, Rafael Aquini wrote: > > > On Thu, May 07, 2020 at 08:33:40PM +, Luis Chamberlain wrote: > > > > I *think* that a cmdl

Re: [PATCH v4 1/4] device-dax: Don't leak kernel memory to user space after unloading kmem

> Am 09.05.2020 um 01:53 schrieb Andrew Morton : > > On Fri, 8 May 2020 10:42:14 +0200 David Hildenbrand > wrote: > >> Assume we have kmem configured and loaded: >> [root@localhost ~]# cat /proc/iomem >> ... >> 14000-33fff : Persistent Memory$ >>14000-1481f : namespac