Commits · 0day-ci/linux

Add Keem Bay Camera sub-system documentation Signed-off-by: Gjorgji Rosikopulos <gjorgjix.rosikopulos@intel.com> Signed-off-by: Martina Krasteva <martinax.krasteva@intel.com> Acked-by: Paul J. Murphy <paul.j.murphy@intel.com> Acked-by: Daniele Alessandrelli <daniele.alessandrelli@intel.com>

Metadata video node implements output and capture meta type interface. - Output video node is used to provide isp parameters for processing. Each buffer internally has real vpu isp params structure allocated. User space params are copied on every qbuf based on update flags. Since vpu need every time all parameters to be provided, params are copied on every qbuf. Based on update flags they are copied from userspace buffer or last buffer processed. To reduce coping of the tables, they are allocated separately in table buffer pool. The tables are copied only when there is update from the userspace, otherwise they are only reference from last processed frame. This is possible because vpu interface has separate address for each table. - Capture video node is used to provide statistics to userspace. Capture video node statistics memory addresses are copied to isp params before processing, and corresponding update flags are set based on statistics availability. Signed-off-by: Gjorgji Rosikopulos <gjorgjix.rosikopulos@intel.com> Co-developed-by: Ivan Dimitrov <ivanx.dimitrov@intel.com> Signed-off-by: Ivan Dimitrov <ivanx.dimitrov@intel.com> Co-developed-by: Martina Krasteva <martinax.krasteva@intel.com> Signed-off-by: Martina Krasteva <martinax.krasteva@intel.com> Acked-by: Paul J. Murphy <paul.j.murphy@intel.com> Acked-by: Daniele Alessandrelli <daniele.alessandrelli@intel.com>

Capture video node implements v4l2 capture interface and XLink VPU Camera buffer pool operations. Build and set stream pipeline operations are also executed from capture video node. Resolution depends on remote entity pad connected to this video node. Co-developed-by: Gjorgji Rosikopulos <gjorgjix.rosikopulos@intel.com> Signed-off-by: Gjorgji Rosikopulos <gjorgjix.rosikopulos@intel.com> Signed-off-by: Martina Krasteva <martinax.krasteva@intel.com> Acked-by: Paul J. Murphy <paul.j.murphy@intel.com> Acked-by: Daniele Alessandrelli <daniele.alessandrelli@intel.com>

Keem Bay pipeline object is responsible for handling of all pipeline management operations. It handles pipeline lifecycle states and configuration. Co-developed-by: Gjorgji Rosikopulos <gjorgjix.rosikopulos@intel.com> Signed-off-by: Gjorgji Rosikopulos <gjorgjix.rosikopulos@intel.com> Signed-off-by: Martina Krasteva <martinax.krasteva@intel.com> Acked-by: Paul J. Murphy <paul.j.murphy@intel.com> Acked-by: Daniele Alessandrelli <daniele.alessandrelli@intel.com>

ISP sub-device has two sink pads and two source pads. Sink pads are connected to sensor and metadata params output video node. Source pads are connected to capture video node and capture metadata. All links are immutable active and are required for streaming session. Isp sub-device implements v4l2 event interface, each event received on VPU ISP channel is also sent as event to userspace. ISP sub-device is managing ISP configuration buffers, the reason for that is they are sent through XLink ISP channel. ISP sub-device is also owner of VPU pipeline. It is responsible for the pipeline configuration, which is executed on set_fmt pad op called on sensor source pad. The source is started/stopped on s_stream video operation. Build/delete pipeline are executed on video nodes streaming operations. When all video nodes with active linked are in stream on state the pipeline is started. Isp sub-device is using metadata output video nodes for parameters and filling the statistics to metadata capture video node. The statistics can be matched with params using buffer sequence number. V4L2_EVENT_FRAME_SYNC is also support. frame_sequence is matching with metadata video buffer sequence number. Signed-off-by: Gjorgji Rosikopulos <gjorgjix.rosikopulos@intel.com> Co-developed-by: Ivan Dimitrov <ivanx.dimitrov@intel.com> Signed-off-by: Ivan Dimitrov <ivanx.dimitrov@intel.com> Co-developed-by: Martina Krasteva <martinax.krasteva@intel.com> Signed-off-by: Martina Krasteva <martinax.krasteva@intel.com> Acked-by: Paul J. Murphy <paul.j.murphy@intel.com> Acked-by: Daniele Alessandrelli <daniele.alessandrelli@intel.com>

Add Keem Bay Camera specific meta formats for processing parameters and statistics: V4L2_META_FMT_KMB_PARAMS V4L2_META_FMT_KMB_STATS Signed-off-by: Gjorgji Rosikopulos <gjorgjix.rosikopulos@intel.com> Co-developed-by: Ivan Dimitrov <ivanx.dimitrov@intel.com> Signed-off-by: Ivan Dimitrov <ivanx.dimitrov@intel.com> Co-developed-by: Martina Krasteva <martinax.krasteva@intel.com> Signed-off-by: Martina Krasteva <martinax.krasteva@intel.com> Acked-by: Paul J. Murphy <paul.j.murphy@intel.com> Acked-by: Daniele Alessandrelli <daniele.alessandrelli@intel.com>

ISP parameters passed to the “keembay-metadata-params” metadata output video node Signed-off-by: Gjorgji Rosikopulos <gjorgjix.rosikopulos@intel.com> Co-developed-by: Ivan Dimitrov <ivanx.dimitrov@intel.com> Signed-off-by: Ivan Dimitrov <ivanx.dimitrov@intel.com> Co-developed-by: Martina Krasteva <martinax.krasteva@intel.com> Signed-off-by: Martina Krasteva <martinax.krasteva@intel.com> Acked-by: Paul J. Murphy <paul.j.murphy@intel.com> Acked-by: Daniele Alessandrelli <daniele.alessandrelli@intel.com>

Communication with VPU firmware is over XLink. XLink has a channel-based communication, each channel has a unique ID. The communication between VPU FW and camera driver starts with one channel with negotiated ID. Currently this ID it is hard-coded on both sides and should not be changed. Three main channel types are used for streaming session: 1. Pipeline management channel: This is fixed channel used to configure/build/delete the streaming pipelines. When pipeline is built the channel IDs used for communication are provided from linux kernel camera driver. 2. Isp control channel: This channel is used for ISP and MIPI RX configuration. For each pipeline a separate ISP channel is required. 3. Buffer pool channels: Each endpoint and buffer pool from VPU FW is associated with a separate XLink channel. This channel is used for buffer management. Messages in "1" and "2" are using cmd sturct as payload data which contains message type and physical address containing message payload. "3" messages are small and the whole message is in XLink payload data. Pipeline management: Each pipeline instance is created on pipeline XLink channel "1". The pipeline lifecycle states are: - Configuration: Pipeline mode and input resolution are sent, as a result min/max resolutions for the available outputs in that mode are received. - Build: The returned pipeline configuration is passed to build command in addition with filled output channel configurations for each output endpoint. After this command pipeline is ready for streaming and can accept messages on ISP and buffer pool channels. - Delete: The command deletes constructed pipeline. NOTE: Now pipeline lifecycle should be always configuration->build->delete it is not allowed to mix the states. However an request was sent to VPU firmware team to be able to delete configured pipeline without going in build state. ISP control: ISP control channel is used for controlling VPU ISP. This includes: - Isp source configuration: MIPI RX configuration - Isp source start/stop: start/stop MIPI RX - Sending ISP params for processing Events from VPU ISP are also received on ISP control channel. Those are MIPI RX events, ISP events and error events. VPU ISP works in per-frame control mode - ISP configuration is required for every processed endpoint. ISP configuration has a lifecycle. The following event sequence needs to be received for each ISP configuration, then it is released by the VPU: - Readout start - MIPI SOF - Readout end - MIPI EOF - Isp start - Isp processing SOF - Isp end - Isp processing EOF If VPU wants to discard ISP configuration because of some internal error, ISP configuration skip event is sent. NOTE: Received events' payload data contains an ISP configuration address this event corresponds to or 0 if the event is not for ISP configuration. Signed-off-by: Gjorgji Rosikopulos <gjorgjix.rosikopulos@intel.com> Co-developed-by: Ivan Dimitrov <ivanx.dimitrov@intel.com> Signed-off-by: Ivan Dimitrov <ivanx.dimitrov@intel.com> Signed-off-by: Martina Krasteva <martinax.krasteva@intel.com> Acked-by: Paul J. Murphy <paul.j.murphy@intel.com> Acked-by: Daniele Alessandrelli <daniele.alessandrelli@intel.com>

Keem Bay camera driver is a v4l2 media device which implements media controller interface. It has one sub-device (ISP sub-device) endpoint which can be connected to a remote CSI2 TX endpoint. The camera supports up to 6 ports, each of which is separate CSI2-PHY interface. Camera driver uses Xlink for communication with remote VPU camera. The Xlink camera protocol uses one control channel for pipeline management and configuration, one ISP channel for ISP control and one channel for each endpoint. Signed-off-by: Gjorgji Rosikopulos <gjorgjix.rosikopulos@intel.com> Co-developed-by: Martina Krasteva <martinax.krasteva@intel.com> Signed-off-by: Martina Krasteva <martinax.krasteva@intel.com> Acked-by: Paul J. Murphy <paul.j.murphy@intel.com> Acked-by: Daniele Alessandrelli <daniele.alessandrelli@intel.com>

- Add dt-bindings documentation for Intel Keem Bay Camera driver. - Add MAINTAINERS entry for Intel Keem Bay Camera binding documentation. Co-developed-by: Gjorgji Rosikopulos <gjorgjix.rosikopulos@intel.com> Signed-off-by: Gjorgji Rosikopulos <gjorgjix.rosikopulos@intel.com> Signed-off-by: Martina Krasteva <martinax.krasteva@intel.com> Acked-by: Paul J. Murphy <paul.j.murphy@intel.com> Acked-by: Daniele Alessandrelli <daniele.alessandrelli@intel.com>

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>

The test verifies that file descriptor created with memfd_secret does not allow read/write operations, that secret memory mappings respect RLIMIT_MEMLOCK and that remote accesses with process_vm_read() and ptrace() to the secret memory fail. Link: https://lkml.kernel.org/r/20210303162209.8609-10-rppt@kernel.org Signed-off-by: Mike Rapoport <rppt@linux.ibm.com> Cc: Alexander Viro <viro@zeniv.linux.org.uk> Cc: Andy Lutomirski <luto@kernel.org> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Borislav Petkov <bp@alien8.de> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Christopher Lameter <cl@linux.com> Cc: Dan Williams <dan.j.williams@intel.com> Cc: Dave Hansen <dave.hansen@linux.intel.com> Cc: David Hildenbrand <david@redhat.com> Cc: Elena Reshetova <elena.reshetova@intel.com> Cc: Hagen Paul Pfeifer <hagen@jauu.net> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: "Kirill A. Shutemov" <kirill@shutemov.name> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Matthew Wilcox <willy@infradead.org> Cc: Michael Kerrisk <mtk.manpages@gmail.com> Cc: Palmer Dabbelt <palmer@dabbelt.com> Cc: Palmer Dabbelt <palmerdabbelt@google.com> Cc: Paul Walmsley <paul.walmsley@sifive.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Rick Edgecombe <rick.p.edgecombe@intel.com> Cc: Roman Gushchin <guro@fb.com> Cc: Shakeel Butt <shakeelb@google.com> Cc: Shuah Khan <shuah@kernel.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Tycho Andersen <tycho@tycho.ws> Cc: Will Deacon <will@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>

Wire up memfd_secret system call on architectures that define ARCH_HAS_SET_DIRECT_MAP, namely arm64, risc-v and x86. Link: https://lkml.kernel.org/r/20210303162209.8609-9-rppt@kernel.org Signed-off-by: Mike Rapoport <rppt@linux.ibm.com> Acked-by: Palmer Dabbelt <palmerdabbelt@google.com> Acked-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Catalin Marinas <catalin.marinas@arm.com> Cc: Alexander Viro <viro@zeniv.linux.org.uk> Cc: Andy Lutomirski <luto@kernel.org> Cc: Borislav Petkov <bp@alien8.de> Cc: Christopher Lameter <cl@linux.com> Cc: Dan Williams <dan.j.williams@intel.com> Cc: Dave Hansen <dave.hansen@linux.intel.com> Cc: David Hildenbrand <david@redhat.com> Cc: Elena Reshetova <elena.reshetova@intel.com> Cc: Hagen Paul Pfeifer <hagen@jauu.net> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: "Kirill A. Shutemov" <kirill@shutemov.name> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Matthew Wilcox <willy@infradead.org> Cc: Michael Kerrisk <mtk.manpages@gmail.com> Cc: Palmer Dabbelt <palmer@dabbelt.com> Cc: Paul Walmsley <paul.walmsley@sifive.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Rick Edgecombe <rick.p.edgecombe@intel.com> Cc: Roman Gushchin <guro@fb.com> Cc: Shakeel Butt <shakeelb@google.com> Cc: Shuah Khan <shuah@kernel.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Tycho Andersen <tycho@tycho.ws> Cc: Will Deacon <will@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>

It is unsafe to allow saving of secretmem areas to the hibernation snapshot as they would be visible after the resume and this essentially will defeat the purpose of secret memory mappings. Prevent hibernation whenever there are active secret memory users. Link: https://lkml.kernel.org/r/20210303162209.8609-8-rppt@kernel.org Signed-off-by: Mike Rapoport <rppt@linux.ibm.com> Cc: Alexander Viro <viro@zeniv.linux.org.uk> Cc: Andy Lutomirski <luto@kernel.org> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Borislav Petkov <bp@alien8.de> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Christopher Lameter <cl@linux.com> Cc: Dan Williams <dan.j.williams@intel.com> Cc: Dave Hansen <dave.hansen@linux.intel.com> Cc: David Hildenbrand <david@redhat.com> Cc: Elena Reshetova <elena.reshetova@intel.com> Cc: Hagen Paul Pfeifer <hagen@jauu.net> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: "Kirill A. Shutemov" <kirill@shutemov.name> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Matthew Wilcox <willy@infradead.org> Cc: Michael Kerrisk <mtk.manpages@gmail.com> Cc: Palmer Dabbelt <palmer@dabbelt.com> Cc: Palmer Dabbelt <palmerdabbelt@google.com> Cc: Paul Walmsley <paul.walmsley@sifive.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Rick Edgecombe <rick.p.edgecombe@intel.com> Cc: Roman Gushchin <guro@fb.com> Cc: Shakeel Butt <shakeelb@google.com> Cc: Shuah Khan <shuah@kernel.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Tycho Andersen <tycho@tycho.ws> Cc: Will Deacon <will@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>

Introduce "memfd_secret" system call with the ability to create memory areas visible only in the context of the owning process and not mapped not only to other processes but in the kernel page tables as well. The secretmem feature is off by default and the user must explicitly enable it at the boot time. Once secretmem is enabled, the user will be able to create a file descriptor using the memfd_secret() system call. The memory areas created by mmap() calls from this file descriptor will be unmapped from the kernel direct map and they will be only mapped in the page table of the processes that have access to the file descriptor. The file descriptor based memory has several advantages over the "traditional" mm interfaces, such as mlock(), mprotect(), madvise(). File descriptor approach allows explict and controlled sharing of the memory areas, it allows to seal the operations. Besides, file descriptor based memory paves the way for VMMs to remove the secret memory range from the userpace hipervisor process, for instance QEMU. Andy Lutomirski says: "Getting fd-backed memory into a guest will take some possibly major work in the kernel, but getting vma-backed memory into a guest without mapping it in the host user address space seems much, much worse." memfd_secret() is made a dedicated system call rather than an extention to memfd_create() because it's purpose is to allow the user to create more secure memory mappings rather than to simply allow file based access to the memory. Nowadays a new system call cost is negligible while it is way simpler for userspace to deal with a clear-cut system calls than with a multiplexer or an overloaded syscall. Moreover, the initial implementation of memfd_secret() is completely distinct from memfd_create() so there is no much sense in overloading memfd_create() to begin with. If there will be a need for code sharing between these implementation it can be easily achieved without a need to adjust user visible APIs. The secret memory remains accessible in the process context using uaccess primitives, but it is not exposed to the kernel otherwise; secret memory areas are removed from the direct map and functions in the follow_page()/get_user_page() family will refuse to return a page that belongs to the secret memory area. Once there will be a use case that will require exposing secretmem to the kernel it will be an opt-in request in the system call flags so that user would have to decide what data can be exposed to the kernel. Removing of the pages from the direct map may cause its fragmentation on architectures that use large pages to map the physical memory which affects the system performance. However, the original Kconfig text for CONFIG_DIRECT_GBPAGES said that gigabyte pages in the direct map "... can improve the kernel's performance a tiny bit ..." (commit 00d1c5e ("x86: add gbpages switches")) and the recent report [1] showed that "... although 1G mappings are a good default choice, there is no compelling evidence that it must be the only choice". Hence, it is sufficient to have secretmem disabled by default with the ability of a system administrator to enable it at boot time. Pages in the secretmem regions are unevictable and unmovable to avoid accidental exposure of the sensitive data via swap or during page migration. Since the secretmem mappings are locked in memory they cannot exceed RLIMIT_MEMLOCK. Since these mappings are already locked independently from mlock(), an attempt to mlock()/munlock() secretmem range would fail and mlockall()/munlockall() will ignore secretmem mappings. However, unlike mlock()ed memory, secretmem currently behaves more like long-term GUP: secretmem mappings are unmovable mappings directly consumed by user space. With default limits, there is no excessive use of secretmem and it poses no real problem in combination with ZONE_MOVABLE/CMA, but in the future this should be addressed to allow balanced use of large amounts of secretmem along with ZONE_MOVABLE/CMA. A page that was a part of the secret memory area is cleared when it is freed to ensure the data is not exposed to the next user of that page. The following example demonstrates creation of a secret mapping (error handling is omitted): fd = memfd_secret(0); ftruncate(fd, MAP_SIZE); ptr = mmap(NULL, MAP_SIZE, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0); [1] https://lore.kernel.org/linux-mm/213b4567-46ce-f116-9cdf-bbd0c884eb3c@linux.intel.com/ Link: https://lkml.kernel.org/r/20210303162209.8609-7-rppt@kernel.org Signed-off-by: Mike Rapoport <rppt@linux.ibm.com> Acked-by: Hagen Paul Pfeifer <hagen@jauu.net> Cc: Alexander Viro <viro@zeniv.linux.org.uk> Cc: Andy Lutomirski <luto@kernel.org> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Borislav Petkov <bp@alien8.de> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Christopher Lameter <cl@linux.com> Cc: Dan Williams <dan.j.williams@intel.com> Cc: Dave Hansen <dave.hansen@linux.intel.com> Cc: Elena Reshetova <elena.reshetova@intel.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: "Kirill A. Shutemov" <kirill@shutemov.name> Cc: Matthew Wilcox <willy@infradead.org> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Michael Kerrisk <mtk.manpages@gmail.com> Cc: Palmer Dabbelt <palmer@dabbelt.com> Cc: Palmer Dabbelt <palmerdabbelt@google.com> Cc: Paul Walmsley <paul.walmsley@sifive.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Rick Edgecombe <rick.p.edgecombe@intel.com> Cc: Roman Gushchin <guro@fb.com> Cc: Shakeel Butt <shakeelb@google.com> Cc: Shuah Khan <shuah@kernel.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Tycho Andersen <tycho@tycho.ws> Cc: Will Deacon <will@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>

…bled On arm64, set_direct_map_*() functions may return 0 without actually changing the linear map. This behaviour can be controlled using kernel parameters, so we need a way to determine at runtime whether calls to set_direct_map_invalid_noflush() and set_direct_map_default_noflush() have any effect. Extend set_memory API with can_set_direct_map() function that allows checking if calling set_direct_map_*() will actually change the page table, replace several occurrences of open coded checks in arm64 with the new function and provide a generic stub for architectures that always modify page tables upon calls to set_direct_map APIs. [arnd@arndb.de: arm64: kfence: fix header inclusion ] Link: https://lkml.kernel.org/r/20210303162209.8609-6-rppt@kernel.org Signed-off-by: Mike Rapoport <rppt@linux.ibm.com> Reviewed-by: Catalin Marinas <catalin.marinas@arm.com> Reviewed-by: David Hildenbrand <david@redhat.com> Cc: Alexander Viro <viro@zeniv.linux.org.uk> Cc: Andy Lutomirski <luto@kernel.org> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Borislav Petkov <bp@alien8.de> Cc: Christopher Lameter <cl@linux.com> Cc: Dan Williams <dan.j.williams@intel.com> Cc: Dave Hansen <dave.hansen@linux.intel.com> Cc: Elena Reshetova <elena.reshetova@intel.com> Cc: Hagen Paul Pfeifer <hagen@jauu.net> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: "Kirill A. Shutemov" <kirill@shutemov.name> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Matthew Wilcox <willy@infradead.org> Cc: Michael Kerrisk <mtk.manpages@gmail.com> Cc: Palmer Dabbelt <palmer@dabbelt.com> Cc: Palmer Dabbelt <palmerdabbelt@google.com> Cc: Paul Walmsley <paul.walmsley@sifive.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Rick Edgecombe <rick.p.edgecombe@intel.com> Cc: Roman Gushchin <guro@fb.com> Cc: Shakeel Butt <shakeelb@google.com> Cc: Shuah Khan <shuah@kernel.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Tycho Andersen <tycho@tycho.ws> Cc: Will Deacon <will@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>

The underlying implementations of set_direct_map_invalid_noflush() and set_direct_map_default_noflush() allow updating multiple contiguous pages at once. Add numpages parameter to set_direct_map_*_noflush() to expose this ability with these APIs. Link: https://lkml.kernel.org/r/20210303162209.8609-5-rppt@kernel.org Signed-off-by: Mike Rapoport <rppt@linux.ibm.com> Acked-by: Catalin Marinas <catalin.marinas@arm.com> [arm64] Cc: Alexander Viro <viro@zeniv.linux.org.uk> Cc: Andy Lutomirski <luto@kernel.org> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Borislav Petkov <bp@alien8.de> Cc: Christopher Lameter <cl@linux.com> Cc: Dan Williams <dan.j.williams@intel.com> Cc: Dave Hansen <dave.hansen@linux.intel.com> Cc: David Hildenbrand <david@redhat.com> Cc: Elena Reshetova <elena.reshetova@intel.com> Cc: Hagen Paul Pfeifer <hagen@jauu.net> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: "Kirill A. Shutemov" <kirill@shutemov.name> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Matthew Wilcox <willy@infradead.org> Cc: Michael Kerrisk <mtk.manpages@gmail.com> Cc: Palmer Dabbelt <palmer@dabbelt.com> Cc: Palmer Dabbelt <palmerdabbelt@google.com> Cc: Paul Walmsley <paul.walmsley@sifive.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Rick Edgecombe <rick.p.edgecombe@intel.com> Cc: Roman Gushchin <guro@fb.com> Cc: Shakeel Butt <shakeelb@google.com> Cc: Shuah Khan <shuah@kernel.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Tycho Andersen <tycho@tycho.ws> Cc: Will Deacon <will@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>

ARCH_HAS_SET_DIRECT_MAP and ARCH_HAS_SET_MEMORY configuration options have no meaning when CONFIG_MMU is disabled and there is no point to enable them for the nommu case. Add an explicit dependency on MMU for these options. Link: https://lkml.kernel.org/r/20210303162209.8609-4-rppt@kernel.org Signed-off-by: Mike Rapoport <rppt@linux.ibm.com> Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>

It will be used by the upcoming secret memory implementation. Link: https://lkml.kernel.org/r/20210303162209.8609-3-rppt@kernel.org Signed-off-by: Mike Rapoport <rppt@linux.ibm.com> Cc: Alexander Viro <viro@zeniv.linux.org.uk> Cc: Andy Lutomirski <luto@kernel.org> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Borislav Petkov <bp@alien8.de> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Christopher Lameter <cl@linux.com> Cc: Dan Williams <dan.j.williams@intel.com> Cc: Dave Hansen <dave.hansen@linux.intel.com> Cc: David Hildenbrand <david@redhat.com> Cc: Elena Reshetova <elena.reshetova@intel.com> Cc: Hagen Paul Pfeifer <hagen@jauu.net> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: "Kirill A. Shutemov" <kirill@shutemov.name> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Matthew Wilcox <willy@infradead.org> Cc: Michael Kerrisk <mtk.manpages@gmail.com> Cc: Palmer Dabbelt <palmer@dabbelt.com> Cc: Palmer Dabbelt <palmerdabbelt@google.com> Cc: Paul Walmsley <paul.walmsley@sifive.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Rick Edgecombe <rick.p.edgecombe@intel.com> Cc: Roman Gushchin <guro@fb.com> Cc: Shakeel Butt <shakeelb@google.com> Cc: Shuah Khan <shuah@kernel.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Tycho Andersen <tycho@tycho.ws> Cc: Will Deacon <will@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>

Patch series "mm: introduce memfd_secret system call to create "secret" memory areas", v18. This is an implementation of "secret" mappings backed by a file descriptor. The file descriptor backing secret memory mappings is created using a dedicated memfd_secret system call The desired protection mode for the memory is configured using flags parameter of the system call. The mmap() of the file descriptor created with memfd_secret() will create a "secret" memory mapping. The pages in that mapping will be marked as not present in the direct map and will be present only in the page table of the owning mm. Although normally Linux userspace mappings are protected from other users, such secret mappings are useful for environments where a hostile tenant is trying to trick the kernel into giving them access to other tenants mappings. Additionally, in the future the secret mappings may be used as a mean to protect guest memory in a virtual machine host. For demonstration of secret memory usage we've created a userspace library https://git.kernel.org/pub/scm/linux/kernel/git/jejb/secret-memory-preloader.git that does two things: the first is act as a preloader for openssl to redirect all the OPENSSL_malloc calls to secret memory meaning any secret keys get automatically protected this way and the other thing it does is expose the API to the user who needs it. We anticipate that a lot of the use cases would be like the openssl one: many toolkits that deal with secret keys already have special handling for the memory to try to give them greater protection, so this would simply be pluggable into the toolkits without any need for user application modification. Hiding secret memory mappings behind an anonymous file allows usage of the page cache for tracking pages allocated for the "secret" mappings as well as using address_space_operations for e.g. page migration callbacks. The anonymous file may be also used implicitly, like hugetlb files, to implement mmap(MAP_SECRET) and use the secret memory areas with "native" mm ABIs in the future. Removing of the pages from the direct map may cause its fragmentation on architectures that use large pages to map the physical memory which affects the system performance. However, the original Kconfig text for CONFIG_DIRECT_GBPAGES said that gigabyte pages in the direct map "... can improve the kernel's performance a tiny bit ..." (commit 00d1c5e ("x86: add gbpages switches")) and the recent report [1] showed that "... although 1G mappings are a good default choice, there is no compelling evidence that it must be the only choice". Hence, it is sufficient to have secretmem disabled by default with the ability of a system administrator to enable it at boot time. In addition, there is also a long term goal to improve management of the direct map. [1] https://lore.kernel.org/linux-mm/213b4567-46ce-f116-9cdf-bbd0c884eb3c@linux.intel.com/ This patch (of 9): The definition of PMD_PAGE_ORDER denoting the number of base pages in the second-level leaf page is already used by DAX and maybe handy in other cases as well. Several architectures already have definition of PMD_ORDER as the size of second level page table, so to avoid conflict with these definitions use PMD_PAGE_ORDER name and update DAX respectively. Link: https://lkml.kernel.org/r/20210303162209.8609-1-rppt@kernel.org Link: https://lkml.kernel.org/r/20210303162209.8609-2-rppt@kernel.org Signed-off-by: Mike Rapoport <rppt@linux.ibm.com> Reviewed-by: David Hildenbrand <david@redhat.com> Cc: Alexander Viro <viro@zeniv.linux.org.uk> Cc: Andy Lutomirski <luto@kernel.org> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Borislav Petkov <bp@alien8.de> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Christopher Lameter <cl@linux.com> Cc: Dan Williams <dan.j.williams@intel.com> Cc: Dave Hansen <dave.hansen@linux.intel.com> Cc: Elena Reshetova <elena.reshetova@intel.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: "Kirill A. Shutemov" <kirill@shutemov.name> Cc: Matthew Wilcox <willy@infradead.org> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Michael Kerrisk <mtk.manpages@gmail.com> Cc: Palmer Dabbelt <palmer@dabbelt.com> Cc: Paul Walmsley <paul.walmsley@sifive.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Rick Edgecombe <rick.p.edgecombe@intel.com> Cc: Roman Gushchin <guro@fb.com> Cc: Shakeel Butt <shakeelb@google.com> Cc: Shuah Khan <shuah@kernel.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Tycho Andersen <tycho@tycho.ws> Cc: Will Deacon <will@kernel.org> Cc: Hagen Paul Pfeifer <hagen@jauu.net> Cc: Palmer Dabbelt <palmerdabbelt@google.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>

# Conflicts: # Makefile

# Conflicts: # drivers/nvmem/Kconfig

Commits on Mar 19, 2021