It looks like all distributions will enable INIT_STACK_ALL_ZERO.
Reflect that in the default configurations.
Acked-by: Alexander Gordeev <agordeev@linux.ibm.com>
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
31 bit support has been removed from the kernel more than eight years
ago. The last 31 bit distribution is many years older. There shouldn't be
any 31 bit code around anymore.
Therefore avoid providing an unused and only partially tested user space
interface and change the default for CONFIG_COMPAT from "yes" to "no".
Acked-by: Christian Borntraeger <borntraeger@linux.ibm.com>
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
Set CONFIG_INIT_STACK_NONE=y in defconfigs to avoid the extra overhead of
initializing all stack variables by default. Users who want to have that
must change the configuration on their own.
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
It's very unusual to have both a command line option and a compile time
option, and apparently that's confusing to people. Also, basically
everybody enables the compile time option now, which means people who
want to disable this wind up having to use the command line option to
ensure that anyway. So just reduce the number of moving pieces and nix
the compile time option in favor of the more versatile command line
option.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
CONFIG_DEBUG_INFO_BTF significantly increases compile time for the
kernel. E.g. when changing a single C file compile time for a new bzImage
is increased by ~50% if BTF debug info is generated.
Therefore remove CONFIG_DEBUG_INFO_BTF from all defconfigs and introduce a
btf.config addon config file. Quickly enabling CONFIG_DEBUG_INFO_BTF into
the current kernel config can be done by simply invoking
make btf.config
Reviewed-by: Alexander Gordeev <agordeev@linux.ibm.com>
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
When RDRAND was introduced, there was much discussion on whether it
should be trusted and how the kernel should handle that. Initially, two
mechanisms cropped up, CONFIG_ARCH_RANDOM, a compile time switch, and
"nordrand", a boot-time switch.
Later the thinking evolved. With a properly designed RNG, using RDRAND
values alone won't harm anything, even if the outputs are malicious.
Rather, the issue is whether those values are being *trusted* to be good
or not. And so a new set of options were introduced as the real
ones that people use -- CONFIG_RANDOM_TRUST_CPU and "random.trust_cpu".
With these options, RDRAND is used, but it's not always credited. So in
the worst case, it does nothing, and in the best case, maybe it helps.
Along the way, CONFIG_ARCH_RANDOM's meaning got sort of pulled into the
center and became something certain platforms force-select.
The old options don't really help with much, and it's a bit odd to have
special handling for these instructions when the kernel can deal fine
with the existence or untrusted existence or broken existence or
non-existence of that CPU capability.
Simplify the situation by removing CONFIG_ARCH_RANDOM and using the
ordinary asm-generic fallback pattern instead, keeping the two options
that are actually used. For now it leaves "nordrand" for now, as the
removal of that will take a different route.
Acked-by: Michael Ellerman <mpe@ellerman.id.au>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Acked-by: Borislav Petkov <bp@suse.de>
Acked-by: Heiko Carstens <hca@linux.ibm.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Support for expanded storage was only available until z13 and z/VM 6.3
respectively. However there haven't been any use cases a long time
before for this device driver.
Therefore remove it.
Acked-by: Christian Borntraeger <borntraeger@de.ibm.com>
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
Implement generic vdso time namespace support which also enables time
namespaces for s390. This is quite similar to what arm64 has.
Reviewed-by: Alexander Gordeev <agordeev@linux.ibm.com>
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
Remove the CONFIG_UEVENT_HELPER_PATH because:
1. It is disabled since commit 1be01d4a57 ("driver: base: Disable
CONFIG_UEVENT_HELPER by default") as its dependency (UEVENT_HELPER) was
made default to 'n',
2. It is not recommended (help message: "This should not be used today
[...] creates a high system load") and was kept only for ancient
userland,
3. Certain userland specifically requests it to be disabled (systemd
README: "Legacy hotplug slows down the system and confuses udev").
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Acked-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
It doesn't actually do anything. Merge its help text into
EXTRA_FIRMWARE.
Fixes: 5620a0d1aa ("firmware: delete in-kernel firmware")
Fixes: 0946b2fb38 ("firmware: cleanup FIRMWARE_IN_KERNEL message")
Signed-off-by: Benjamin Gilbert <benjamin.gilbert@coreos.com>
Signed-off-by: Robin H. Johnson <robbat2@gentoo.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
zipl from s390-tools generates root=/dev/ram0 kernel cmdline for
zfcpdump, thus BLK_DEV_RAM is required.
zfcpdump initrd mounts DEBUG_FS, thus is also required.
Bug-Ubuntu: https://launchpad.net/bugs/1722735
Bug-Ubuntu: https://launchpad.net/bugs/1719290
Signed-off-by: Dimitri John Ledkov <xnox@ubuntu.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
This config option is completely irrelevant for zfcpdump and
unfortunately causes a kernel panic on recent kernels in
"mspro_block_init()/driver_register()".
Signed-off-by: Michael Holzheu <holzheu@linux.vnet.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Commit df568d8e ("scsi: Use 'depends' with LIBFC instead of
'select'.") removed what happened to be the only instance of 'select
NET'. Defconfigs that were relying on the select now lack networking
support.
Signed-off-by: David S. Miller <davem@davemloft.net>
Add four more defconfigs which we maintained outside of
the kernel tree for no good reason.
Inside of the kernel tree they can be easily used:
make whatever_defconfig
"make help" shows the available defconfigs.
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
