kernel/git/next/linux-next.git/arch/xtensa/include/uapi, branch master

Merge branch 'xtensa-for-next' of https://github.com/jcmvbkbc/linux-xtensa.git

2026-09-08T12:34:56+00:00

init, arch: make CONFIG_COMMAND_LINE_SIZE globally configurable

2026-09-06T03:23:22+00:00

Currently, s390 has the ability to configure the maximum kernel command line size via Kconfig (CONFIG_COMMAND_LINE_SIZE). Other architectures define a hardcoded COMMAND_LINE_SIZE macro in their setup.h headers. In some use cases, such as netboot kernels, rootfs configurations, or larger initramfs setups, a larger command line size is required. While for embedded workloads, it can be reduced to save memory. Move CONFIG_COMMAND_LINE_SIZE out of arch/s390/Kconfig and into init/Kconfig under General setup, and update every architecture's setup.h header to define COMMAND_LINE_SIZE as CONFIG_COMMAND_LINE_SIZE. For user-space API (uapi) headers, wrap the definition in an `#ifdef __KERNEL__` guard and retain the historical hardcoded default in the `#else` block. When user-space headers are installed via `make headers_install`, unifdef strips out the kernel section, ensuring the same value as before for user-space applications including ``. For S390, the range is kept the same, but other architectures have varying constraints. S390 requires a minimum of 896 bytes to protect legacy bootloaders from overwriting the .text section. ARM, M68K, and NIOS2 allocate the command line directly on severely constrained decompressor stacks, so their ranges are strictly capped at 2048 bytes to prevent deterministic stack exhaustion and boot panics. PowerPC (PPC) boot wrappers silently truncate arguments past 2048 bytes, so it is also capped at 2048 to prevent silent parameter loss. The SuperH (SUPERH) boot parameter page allocates exactly PAGE_SIZE (typically 4096 bytes), and placing a 4096-byte command line starting at offset 256 would cause strscpy() to read out of bounds; it is capped at 3840 bytes. Alpha physically limits its boot parameter block to 256 bytes, so its limit is strictly locked to 256. All other architectures are capped at 4096 bytes to prevent unreasonable allocations. Link: https://lore.kernel.org/20260818231646.804507-2-wfelipe@google.com Signed-off-by: Maciej Żenczykowski Signed-off-by: Wilson Felipe Pereira Cc: Albert Ou Cc: Alexander Gordeev Cc: Alexandre Ghiti Cc: Arnd Bergmann Cc: Christian Borntraeger Cc: Heiko Carstens Cc: Palmer Dabbelt Cc: Sven Schnelle Cc: Vasily Gorbik Signed-off-by: Andrew Morton

xtensa: fix typos in comments

2026-09-04T13:53:13+00:00

Fix typos in comments, reported by scripts/checkpatch.pl using the misspelling list in scripts/spelling.txt. Only touches comments, no code changes. Assisted-by: Cursor:claude-opus-5 Signed-off-by: Hemanth Selam Message-ID: <20260904115443.10393-1-hemanth.selam@gmail.com> Signed-off-by: Max Filippov

xtensa: uapi: Reuse asm-generic ucontext.h

2026-03-14T13:56:20+00:00

Drop the custom non-uapi definition which is the same as the generic uapi one. Signed-off-by: Thomas Weißschuh Message-ID: <20260314-uapi-ucontext-xtensa-v1-1-08dceca7e6a2@weissschuh.net> [Max: Move new generic-y line to the arch/xtensa/include/uapi/asm/Kbuild] Signed-off-by: Max Filippov

Merge tag 'xtensa-20250808' of https://github.com/jcmvbkbc/linux-xtensa

2025-08-09T04:35:03+00:00

Pull xtensa update from Max Filippov: - replace __ASSEMBLY__ with __ASSEMBLER__ in arch headers * tag 'xtensa-20250808' of https://github.com/jcmvbkbc/linux-xtensa: xtensa: Replace __ASSEMBLY__ with __ASSEMBLER__ in non-uapi headers xtensa: Replace __ASSEMBLY__ with __ASSEMBLER__ in uapi headers

xtensa: get rid uapi/asm/param.h

2025-06-25T02:02:05+00:00

The only difference between it and generic is the stray (and utterly useless) definition of NGROUPS. It had been removed on all architectures back in 2004; xtensa port began prior to that and hadn't been merged until 2005, so it had missed the purge. Reviewed-by: Arnd Bergmann Signed-off-by: Al Viro

xtensa: Replace ASSEMBLY with ASSEMBLER in uapi headers

2025-06-06T08:03:35+00:00

__ASSEMBLY__ is only defined by the Makefile of the kernel, so this is not really useful for uapi headers (unless the userspace Makefile defines it, too). Let's switch to __ASSEMBLER__ which gets set automatically by the compiler when compiling assembly code. This is a completely mechanical patch (done with a simple "sed -i" statement). Cc: Chris Zankel Cc: Max Filippov Signed-off-by: Thomas Huth Message-Id: <20250314071013.1575167-39-thuth@redhat.com> Signed-off-by: Max Filippov

mm: madvise: implement lightweight guard page mechanism

2024-11-11T08:26:45+00:00

Implement a new lightweight guard page feature, that is regions of userland virtual memory that, when accessed, cause a fatal signal to arise. Currently users must establish PROT_NONE ranges to achieve this. However this is very costly memory-wise - we need a VMA for each and every one of these regions AND they become unmergeable with surrounding VMAs. In addition repeated mmap() calls require repeated kernel context switches and contention of the mmap lock to install these ranges, potentially also having to unmap memory if installed over existing ranges. The lightweight guard approach eliminates the VMA cost altogether - rather than establishing a PROT_NONE VMA, it operates at the level of page table entries - establishing PTE markers such that accesses to them cause a fault followed by a SIGSGEV signal being raised. This is achieved through the PTE marker mechanism, which we have already extended to provide PTE_MARKER_GUARD, which we installed via the generic page walking logic which we have extended for this purpose. These guard ranges are established with MADV_GUARD_INSTALL. If the range in which they are installed contain any existing mappings, they will be zapped, i.e. free the range and unmap memory (thus mimicking the behaviour of MADV_DONTNEED in this respect). Any existing guard entries will be left untouched. There is therefore no nesting of guarded pages. Guarded ranges are NOT cleared by MADV_DONTNEED nor MADV_FREE (in both instances the memory range may be reused at which point a user would expect guards to still be in place), but they are cleared via MADV_GUARD_REMOVE, process teardown or unmapping of memory ranges. The guard property can be removed from ranges via MADV_GUARD_REMOVE. The ranges over which this is applied, should they contain non-guard entries, will be untouched, with only guard entries being cleared. We permit this operation on anonymous memory only, and only VMAs which are non-special, non-huge and not mlock()'d (if we permitted this we'd have to drop locked pages which would be rather counterintuitive). Racing page faults can cause repeated attempts to install guard pages that are interrupted, result in a zap, and this process can end up being repeated. If this happens more than would be expected in normal operation, we rescind locks and retry the whole thing, which avoids lock contention in this scenario. Link: https://lkml.kernel.org/r/6aafb5821bf209f277dfae0787abb2ef87a37542.1730123433.git.lorenzo.stoakes@oracle.com Signed-off-by: Lorenzo Stoakes Suggested-by: Vlastimil Babka Suggested-by: Jann Horn Suggested-by: David Hildenbrand Suggested-by: Vlastimil Babka Suggested-by: Jann Horn Suggested-by: David Hildenbrand Acked-by: Vlastimil Babka Cc: Arnd Bergmann Cc: Christian Brauner Cc: Christoph Hellwig Cc: Chris Zankel Cc: Helge Deller Cc: James E.J. Bottomley Cc: Jeff Xu Cc: John Hubbard Cc: Liam R. Howlett Cc: Matthew Wilcox (Oracle) Cc: Matt Turner Cc: Max Filippov Cc: Muchun Song Cc: Paul E. McKenney Cc: Richard Henderson Cc: Shuah Khan Cc: Shuah Khan Cc: Sidhartha Kumar Cc: Suren Baghdasaryan Cc: Thomas Bogendoerfer Signed-off-by: Andrew Morton

Merge tag 'mm-stable-2022-10-08' of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm

2022-10-11T00:53:04+00:00

Pull MM updates from Andrew Morton: - Yu Zhao's Multi-Gen LRU patches are here. They've been under test in linux-next for a couple of months without, to my knowledge, any negative reports (or any positive ones, come to that). - Also the Maple Tree from Liam Howlett. An overlapping range-based tree for vmas. It it apparently slightly more efficient in its own right, but is mainly targeted at enabling work to reduce mmap_lock contention. Liam has identified a number of other tree users in the kernel which could be beneficially onverted to mapletrees. Yu Zhao has identified a hard-to-hit but "easy to fix" lockdep splat at [1]. This has yet to be addressed due to Liam's unfortunately timed vacation. He is now back and we'll get this fixed up. - Dmitry Vyukov introduces KMSAN: the Kernel Memory Sanitizer. It uses clang-generated instrumentation to detect used-unintialized bugs down to the single bit level. KMSAN keeps finding bugs. New ones, as well as the legacy ones. - Yang Shi adds a userspace mechanism (madvise) to induce a collapse of memory into THPs. - Zach O'Keefe has expanded Yang Shi's madvise(MADV_COLLAPSE) to support file/shmem-backed pages. - userfaultfd updates from Axel Rasmussen - zsmalloc cleanups from Alexey Romanov - cleanups from Miaohe Lin: vmscan, hugetlb_cgroup, hugetlb and memory-failure - Huang Ying adds enhancements to NUMA balancing memory tiering mode's page promotion, with a new way of detecting hot pages. - memcg updates from Shakeel Butt: charging optimizations and reduced memory consumption. - memcg cleanups from Kairui Song. - memcg fixes and cleanups from Johannes Weiner. - Vishal Moola provides more folio conversions - Zhang Yi removed ll_rw_block() :( - migration enhancements from Peter Xu - migration error-path bugfixes from Huang Ying - Aneesh Kumar added ability for a device driver to alter the memory tiering promotion paths. For optimizations by PMEM drivers, DRM drivers, etc. - vma merging improvements from Jakub Matěn. - NUMA hinting cleanups from David Hildenbrand. - xu xin added aditional userspace visibility into KSM merging activity. - THP & KSM code consolidation from Qi Zheng. - more folio work from Matthew Wilcox. - KASAN updates from Andrey Konovalov. - DAMON cleanups from Kaixu Xia. - DAMON work from SeongJae Park: fixes, cleanups. - hugetlb sysfs cleanups from Muchun Song. - Mike Kravetz fixes locking issues in hugetlbfs and in hugetlb core. Link: https://lkml.kernel.org/r/CAOUHufZabH85CeUN-MEMgL8gJGzJEWUrkiM58JkTbBhh-jew0Q@mail.gmail.com [1] * tag 'mm-stable-2022-10-08' of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm: (555 commits) hugetlb: allocate vma lock for all sharable vmas hugetlb: take hugetlb vma_lock when clearing vma_lock->vma pointer hugetlb: fix vma lock handling during split vma and range unmapping mglru: mm/vmscan.c: fix imprecise comments mm/mglru: don't sync disk for each aging cycle mm: memcontrol: drop dead CONFIG_MEMCG_SWAP config symbol mm: memcontrol: use do_memsw_account() in a few more places mm: memcontrol: deprecate swapaccounting=0 mode mm: memcontrol: don't allocate cgroup swap arrays when memcg is disabled mm/secretmem: remove reduntant return value mm/hugetlb: add available_huge_pages() func mm: remove unused inline functions from include/linux/mm_inline.h selftests/vm: add selftest for MADV_COLLAPSE of uffd-minor memory selftests/vm: add file/shmem MADV_COLLAPSE selftest for cleared pmd selftests/vm: add thp collapse shmem testing selftests/vm: add thp collapse file and tmpfs testing selftests/vm: modularize thp collapse memory operations selftests/vm: dedup THP helpers mm/khugepaged: add tracepoint to hpage_collapse_scan_file() mm/madvise: add file and shmem support to MADV_COLLAPSE ...

xtensa: add FDPIC and static PIE support for noMMU

2022-09-14T01:28:00+00:00

Define ELFOSABI_XTENSA_FDPIC and use it as an OSABI tag in the ELF header to distinguish FDPIC ELF files from regular ELF files. Define ELF_FDPIC_PLAT_INIT and put executable map, interpreter map and executable dynamic section addresses into registers a4..a6. Update start_thread macro to preserve register values in the current register window. Add definitions for PTRACE_GETFDPIC, PTRACE_GETFDPIC_EXEC and PTRACE_GETFDPIC_INTERP. Signed-off-by: Max Filippov