| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
There is only one Kconfig user of CONFIG_EMBEDDED and it can be switched
to EXPERT or "if !ARCH_MULTIPLATFORM" (suggested by Arnd).
Link: https://lkml.kernel.org/r/[email protected]
Signed-off-by: Randy Dunlap <[email protected]>
Acked-by: Geert Uytterhoeven <[email protected]>
Acked-by: Arnd Bergmann <[email protected]>
Acked-by: Palmer Dabbelt <[email protected]> [RISC-V]
Acked-by: Greg Ungerer <[email protected]>
Acked-by: Jason A. Donenfeld <[email protected]>
Acked-by: Michael Ellerman <[email protected]> [powerpc]
Cc: Russell King <[email protected]>
Cc: Vineet Gupta <[email protected]>
Cc: Brian Cain <[email protected]>
Cc: Michal Simek <[email protected]>
Cc: Thomas Bogendoerfer <[email protected]>
Cc: Dinh Nguyen <[email protected]>
Cc: Jonas Bonn <[email protected]>
Cc: Stefan Kristiansson <[email protected]>
Cc: Stafford Horne <[email protected]>
Cc: Nicholas Piggin <[email protected]>
Cc: Christophe Leroy <[email protected]>
Cc: Paul Walmsley <[email protected]>
Cc: Albert Ou <[email protected]>
Cc: Yoshinori Sato <[email protected]>
Cc: Rich Felker <[email protected]>
Cc: John Paul Adrian Glaubitz <[email protected]>
Cc: Max Filippov <[email protected]>
Cc: Josh Triplett <[email protected]>
Cc: Masahiro Yamada <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
|
|
As explained in [1], we would like to remove SLOB if possible.
- There are no known users that need its somewhat lower memory footprint
so much that they cannot handle SLUB (after some modifications by the
previous patches) instead.
- It is an extra maintenance burden, and a number of features are
incompatible with it.
- It blocks the API improvement of allowing kfree() on objects allocated
via kmem_cache_alloc().
As the first step, rename the CONFIG_SLOB option in the slab allocator
configuration choice to CONFIG_SLOB_DEPRECATED. Add CONFIG_SLOB
depending on CONFIG_SLOB_DEPRECATED as an internal option to avoid code
churn. This will cause existing .config files and defconfigs with
CONFIG_SLOB=y to silently switch to the default (and recommended
replacement) SLUB, while still allowing SLOB to be configured by anyone
that notices and needs it. But those should contact the slab maintainers
and [email protected] as explained in the updated help. With no valid
objections, the plan is to update the existing defconfigs to SLUB and
remove SLOB in a few cycles.
To make SLUB more suitable replacement for SLOB, a CONFIG_SLUB_TINY
option was introduced to limit SLUB's memory overhead.
There is a number of defconfigs specifying CONFIG_SLOB=y. As part of
this patch, update them to select CONFIG_SLUB and CONFIG_SLUB_TINY.
[1] https://lore.kernel.org/all/[email protected]/
Cc: Russell King <[email protected]>
Cc: Aaro Koskinen <[email protected]>
Cc: Janusz Krzysztofik <[email protected]>
Cc: Tony Lindgren <[email protected]>
Cc: Jonas Bonn <[email protected]>
Cc: Stefan Kristiansson <[email protected]>
Cc: Stafford Horne <[email protected]>
Cc: Yoshinori Sato <[email protected]>
Cc: Rich Felker <[email protected]>
Cc: Arnd Bergmann <[email protected]>
Cc: Josh Triplett <[email protected]>
Cc: Conor Dooley <[email protected]>
Cc: Damien Le Moal <[email protected]>
Cc: Christophe Leroy <[email protected]>
Cc: Geert Uytterhoeven <[email protected]>
Signed-off-by: Vlastimil Babka <[email protected]>
Acked-by: Aaro Koskinen <[email protected]> # OMAP1
Reviewed-by: Damien Le Moal <[email protected]> # riscv k210
Acked-by: Arnd Bergmann <[email protected]> # arm
Acked-by: Roman Gushchin <[email protected]>
Acked-by: Mike Rapoport <[email protected]>
Reviewed-by: Christoph Lameter <[email protected]>
|
|
I have been developing a new qemu virt platform to help with more
efficient toolchain and kernel testing [1].
This patch adds the defconfig which is needed to support booting
linux on the platform.
[1] https://lore.kernel.org/qemu-devel/YpwNtowUTxRbh2Uq@antec/T/#m6db180b0d682785fb320e4a05345c12a063e0c47
Signed-off-by: Stafford Horne <[email protected]>
|
|
I have been using a litex SoC for glibc verification. Update the
default litex config to support required userspace API's needed for the
full glibc testsuite to pass.
This includes enabling the litex mmc driver and filesystems used
in a typical litex environment.
Signed-off-by: Stafford Horne <[email protected]>
|
|
Add the liteeth network device and basic network options, and update the
options by doing a savedefconfig.
Signed-off-by: Joel Stanley <[email protected]>
Signed-off-by: Stafford Horne <[email protected]>
|
|
Patch series "drivers/char: remove /dev/kmem for good".
Exploring /dev/kmem and /dev/mem in the context of memory hot(un)plug and
memory ballooning, I started questioning the existence of /dev/kmem.
Comparing it with the /proc/kcore implementation, it does not seem to be
able to deal with things like
a) Pages unmapped from the direct mapping (e.g., to be used by secretmem)
-> kern_addr_valid(). virt_addr_valid() is not sufficient.
b) Special cases like gart aperture memory that is not to be touched
-> mem_pfn_is_ram()
Unless I am missing something, it's at least broken in some cases and might
fault/crash the machine.
Looks like its existence has been questioned before in 2005 and 2010 [1],
after ~11 additional years, it might make sense to revive the discussion.
CONFIG_DEVKMEM is only enabled in a single defconfig (on purpose or by
mistake?). All distributions disable it: in Ubuntu it has been disabled
for more than 10 years, in Debian since 2.6.31, in Fedora at least
starting with FC3, in RHEL starting with RHEL4, in SUSE starting from
15sp2, and OpenSUSE has it disabled as well.
1) /dev/kmem was popular for rootkits [2] before it got disabled
basically everywhere. Ubuntu documents [3] "There is no modern user of
/dev/kmem any more beyond attackers using it to load kernel rootkits.".
RHEL documents in a BZ [5] "it served no practical purpose other than to
serve as a potential security problem or to enable binary module drivers
to access structures/functions they shouldn't be touching"
2) /proc/kcore is a decent interface to have a controlled way to read
kernel memory for debugging puposes. (will need some extensions to
deal with memory offlining/unplug, memory ballooning, and poisoned
pages, though)
3) It might be useful for corner case debugging [1]. KDB/KGDB might be a
better fit, especially, to write random memory; harder to shoot
yourself into the foot.
4) "Kernel Memory Editor" [4] hasn't seen any updates since 2000 and seems
to be incompatible with 64bit [1]. For educational purposes,
/proc/kcore might be used to monitor value updates -- or older
kernels can be used.
5) It's broken on arm64, and therefore, completely disabled there.
Looks like it's essentially unused and has been replaced by better
suited interfaces for individual tasks (/proc/kcore, KDB/KGDB). Let's
just remove it.
[1] https://lwn.net/Articles/147901/
[2] https://www.linuxjournal.com/article/10505
[3] https://wiki.ubuntu.com/Security/Features#A.2Fdev.2Fkmem_disabled
[4] https://sourceforge.net/projects/kme/
[5] https://bugzilla.redhat.com/show_bug.cgi?id=154796
Link: https://lkml.kernel.org/r/[email protected]
Link: https://lkml.kernel.org/r/[email protected]
Signed-off-by: David Hildenbrand <[email protected]>
Acked-by: Michal Hocko <[email protected]>
Acked-by: Kees Cook <[email protected]>
Cc: Linus Torvalds <[email protected]>
Cc: Greg Kroah-Hartman <[email protected]>
Cc: "Alexander A. Klimov" <[email protected]>
Cc: Alexander Viro <[email protected]>
Cc: Alexandre Belloni <[email protected]>
Cc: Andrew Lunn <[email protected]>
Cc: Andrey Zhizhikin <[email protected]>
Cc: Arnd Bergmann <[email protected]>
Cc: Benjamin Herrenschmidt <[email protected]>
Cc: Brian Cain <[email protected]>
Cc: Christian Borntraeger <[email protected]>
Cc: Christophe Leroy <[email protected]>
Cc: Chris Zankel <[email protected]>
Cc: Corentin Labbe <[email protected]>
Cc: "David S. Miller" <[email protected]>
Cc: "Eric W. Biederman" <[email protected]>
Cc: Geert Uytterhoeven <[email protected]>
Cc: Gerald Schaefer <[email protected]>
Cc: Greentime Hu <[email protected]>
Cc: Gregory Clement <[email protected]>
Cc: Heiko Carstens <[email protected]>
Cc: Helge Deller <[email protected]>
Cc: Hillf Danton <[email protected]>
Cc: huang ying <[email protected]>
Cc: Ingo Molnar <[email protected]>
Cc: Ivan Kokshaysky <[email protected]>
Cc: "James E.J. Bottomley" <[email protected]>
Cc: James Troup <[email protected]>
Cc: Jiaxun Yang <[email protected]>
Cc: Jonas Bonn <[email protected]>
Cc: Jonathan Corbet <[email protected]>
Cc: Kairui Song <[email protected]>
Cc: Krzysztof Kozlowski <[email protected]>
Cc: Kuninori Morimoto <[email protected]>
Cc: Liviu Dudau <[email protected]>
Cc: Lorenzo Pieralisi <[email protected]>
Cc: Luc Van Oostenryck <[email protected]>
Cc: Luis Chamberlain <[email protected]>
Cc: Matthew Wilcox <[email protected]>
Cc: Matt Turner <[email protected]>
Cc: Max Filippov <[email protected]>
Cc: Michael Ellerman <[email protected]>
Cc: Mike Rapoport <[email protected]>
Cc: Mikulas Patocka <[email protected]>
Cc: Minchan Kim <[email protected]>
Cc: Niklas Schnelle <[email protected]>
Cc: Oleksiy Avramchenko <[email protected]>
Cc: [email protected]
Cc: Palmer Dabbelt <[email protected]>
Cc: Paul Mackerras <[email protected]>
Cc: "Pavel Machek (CIP)" <[email protected]>
Cc: Pavel Machek <[email protected]>
Cc: "Peter Zijlstra (Intel)" <[email protected]>
Cc: Pierre Morel <[email protected]>
Cc: Randy Dunlap <[email protected]>
Cc: Richard Henderson <[email protected]>
Cc: Rich Felker <[email protected]>
Cc: Robert Richter <[email protected]>
Cc: Rob Herring <[email protected]>
Cc: Russell King <[email protected]>
Cc: Sam Ravnborg <[email protected]>
Cc: Sebastian Andrzej Siewior <[email protected]>
Cc: Sebastian Hesselbarth <[email protected]>
Cc: [email protected]
Cc: Stafford Horne <[email protected]>
Cc: Stefan Kristiansson <[email protected]>
Cc: Steven Rostedt <[email protected]>
Cc: Sudeep Holla <[email protected]>
Cc: Theodore Dubois <[email protected]>
Cc: Thomas Bogendoerfer <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Cc: Vasily Gorbik <[email protected]>
Cc: Viresh Kumar <[email protected]>
Cc: William Cohen <[email protected]>
Cc: Xiaoming Ni <[email protected]>
Cc: Yoshinori Sato <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
|
|
This adds support for a basic LiteX-based SoC with a mor1kx soft CPU.
Signed-off-by: Filip Kokosinski <[email protected]>
Signed-off-by: Mateusz Holenko <[email protected]>
[shorne: Merged in soc-cntl patch, removed CROSS_COMPILE, sort MAINT.]
Signed-off-by: Stafford Horne <[email protected]>
|
|
CONFIG_CROSS_COMPILE is gone since commit f1089c92da79 ("kbuild: remove
CONFIG_CROSS_COMPILE support").
Signed-off-by: Krzysztof Kozlowski <[email protected]>
Signed-off-by: Stafford Horne <[email protected]>
|
|
This Kconfig option was removed during v4.19 development in commit
771c035372a0 ("deprecate the '__deprecated' attribute warnings entirely
and for good") so there's no point to keep it in defconfigs any longer.
FWIW defconfigs were patched with:
--------------------------->8----------------------
find . -name *_defconfig -exec sed -i '/CONFIG_ENABLE_WARN_DEPRECATED/d' {} \;
--------------------------->8----------------------
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Alexey Brodkin <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
|
|
Simple enough to be compatible with simulation environments,
such as verilated systems, QEMU and other targets supporting OpenRISC
SMP. This also supports our base FPGA SoC's if the cpu frequency is
upped to 50Mhz.
Signed-off-by: Stefan Kristiansson <[email protected]>
[[email protected]: Added defconfig]
Signed-off-by: Stafford Horne <[email protected]>
|
|
Remove old, dead Kconfig option INET_LRO. It is gone since
commit 7bbf3cae65b6 ("ipv4: Remove inet_lro library").
Signed-off-by: Krzysztof Kozlowski <[email protected]>
Signed-off-by: Stafford Horne <[email protected]>
|
|
The openrisc toolchain prefix changed a few years ago. No one
should be using this anylonger. This also saves from people
having to manually update or specify this every build.
Signed-off-by: Stafford Horne <[email protected]>
|
|
Signed-off-by: Geert Uytterhoeven <[email protected]>
Signed-off-by: Jonas Bonn <[email protected]>
|
|
Signed-off-by: Jonas Bonn <[email protected]>
Reviewed-by: Arnd Bergmann <[email protected]>
|