Björn Töpel [Fri, 11 Dec 2020 14:57:12 +0000 (15:57 +0100)]
i40e, xsk: clear the status bits for the next_to_use descriptor
On the Rx side, the next_to_use index points to the next item in the
HW ring to be refilled/allocated, and next_to_clean points to the next
item to potentially be processed.
When the HW Rx ring is fully refilled, i.e. no packets has been
processed, the next_to_use will be next_to_clean - 1. When the ring is
fully processed next_to_clean will be equal to next_to_use. The latter
case is where a bug is triggered.
If the next_to_use bits are not cleared, and the "fully processed"
state is entered, a stale descriptor can be processed.
The skb-path correctly clear the status bit for the next_to_use
descriptor, but the AF_XDP zero-copy path did not do that.
This change adds the status bits clearing of the next_to_use
descriptor.
Fixes: 3b4f0b66c2b3 ("i40e, xsk: Migrate to new MEM_TYPE_XSK_BUFF_POOL") Signed-off-by: Björn Töpel <[email protected]> Signed-off-by: Jakub Kicinski <[email protected]>
Björn Töpel [Fri, 11 Dec 2020 14:57:11 +0000 (15:57 +0100)]
ice, xsk: clear the status bits for the next_to_use descriptor
On the Rx side, the next_to_use index points to the next item in the
HW ring to be refilled/allocated, and next_to_clean points to the next
item to potentially be processed.
When the HW Rx ring is fully refilled, i.e. no packets has been
processed, the next_to_use will be next_to_clean - 1. When the ring is
fully processed next_to_clean will be equal to next_to_use. The latter
case is where a bug is triggered.
If the next_to_use bits are not cleared, and the "fully processed"
state is entered, a stale descriptor can be processed.
The skb-path correctly clear the status bit for the next_to_use
descriptor, but the AF_XDP zero-copy path did not do that.
This change adds the status bits clearing of the next_to_use
descriptor.
Fixes: 2d4238f55697 ("ice: Add support for AF_XDP") Signed-off-by: Björn Töpel <[email protected]> Signed-off-by: Jakub Kicinski <[email protected]>
Linus Torvalds [Wed, 16 Dec 2020 18:45:11 +0000 (10:45 -0800)]
Merge tag 'printk-for-5.11' of git://git.kernel.org/pub/scm/linux/kernel/git/printk/linux
Pull printk updates from Petr Mladek:
- Finally allow parallel writes and reads into/from the lockless
ringbuffer. But it is not a complete solution. Readers are still
serialized against each other. And nested writes are still prevented
by printk_safe per-CPU buffers.
- Use ttynull as the ultimate fallback for /dev/console.
- Officially allow disabling console output by using console="" or
console=null
- A few code cleanups
* tag 'printk-for-5.11' of git://git.kernel.org/pub/scm/linux/kernel/git/printk/linux:
printk: remove logbuf_lock writer-protection of ringbuffer
printk: inline log_output(),log_store() in vprintk_store()
printk: remove obsolete dead assignment
printk/console: Allow to disable console output by using console="" or console=null
init/console: Use ttynull as a fallback when there is no console
printk: ringbuffer: Reference text_data_ring directly in callees.
Miquel Raynal [Wed, 16 Dec 2020 17:48:16 +0000 (18:48 +0100)]
Merge tags 'spi-nor/for-5.11' and 'nand/for-5.11' into mtd/next
SPI NOR core changes:
- Initial support for stateful Octal DTR mode using volatile settings
- Preliminary support for JEDEC 251 (xSPI) and JEDEC 216D standards
- Support for Cypress Semper flash
- Support to specify ECC block size of SPI NOR flashes
- Fixes to avoid clearing of non-volatile Block Protection bits at probe
Generic NAND core:
* ECC management:
- Add an I/O request tweaking mechanism
- Entire rework of the software BCH ECC driver, creation of a real
ECC engine, getting rid of raw NAND structures, migration to more
generic prototypes, misc fixes and style cleanup. Moved now to the
Generic NAND layer.
- Entire rework of the software Hamming ECC driver, creation of a
real ECC engine, getting rid of raw NAND structures, misc renames,
comment updates, cleanup, and style fixes. Moved now to the
generic NAND layer.
- Necessary plumbing at the NAND level to retrieve generic NAND ECC
engines (softwares and on-die).
- Update of the bindings.
Raw NAND core:
* Geting rid of the chip->ecc.priv entry.
* Fix miscellaneous typos in kernel-doc
Raw NAND controller drivers:
* AU1550: Ensure the presence of the right includes
* Davinci: Do not use extra dereferencing
* GPMI:
- Fix the driver only sense CS0 R/B issue
- Fix the random DMA timeout issue
- Use a single line for of_device_id
- Use of_device_get_match_data()
- Fix reference count leak in gpmi ops
- Cleanup makefile
- Fix binding matching of clocks on different SoCs
* Ingenic: remove redundant get_device() in ingenic_ecc_get()
* Intel LGM: New NAND controller driver
* Marvell: Drop useless line
* Meson:
- Fix a resource leak in init
- Fix meson_nfc_dma_buffer_release() arguments
* mxc:
- Use device_get_match_data()
- Use a single line for of_device_id
- Remove platform data support
* Qcom:
- Add support for SDX55
- Support for IPQ6018 QPIC NAND controller
- Fix DMA sync on FLASH_STATUS register read
* Rockchip: New NAND controller driver for RK3308, RK2928 and others
* Sunxi: Add MDMA support
SPI-NAND core:
* Creation of a SPI-NAND on-die ECC engine
* Move ECC related definitions earlier in the driver
* Fix typo in comment
* Fill a default ECC provider/algorithm
* Remove outdated comment
* Fix OOB read
* Allow the case where there is no ECC engine
* Use the external ECC engine logic
SPI-NAND chip drivers:
* Micron:
- Add support for MT29F2G01AAAED
- Use more specific names
* Macronix:
- Add support for MX35LFxG24AD
- Add support for MX35LFxGE4AD
Others:
* onenand: Use mtd->oops_panic_write as condition
* plat-ram: correctly free memory on error path in platram_probe()
Even if there is more rx data waiting on the chip, the rx napi poll fn
will never run more than once - it will always read a few buffers, then
bail out and re-arm interrupts. Which results in ping-pong between napi
and interrupt.
This defeats the purpose of napi, and is bad for performance.
Fix by making the rx napi poll behave identically to other ethernet
drivers:
1. initialize rx napi polling with an arbitrary budget (64).
2. in the polling fn, return full weight if rx queue is not depleted,
this tells the napi core to "keep polling".
3. update the rx tail ("ring the doorbell") once for every 8 processed
rx ring buffers.
Thanks to Jakub Kicinski, Eric Dumazet and Andrew Lunn for their expert
opinions and suggestions.
Tested with 20 seconds of full bandwidth receive (iperf3):
rx irqs softirqs(NET_RX)
-----------------------------
before 23827 33620
after 129 4081
Colin Ian King [Wed, 16 Dec 2020 12:25:13 +0000 (12:25 +0000)]
NFSv4.2: fix error return on memory allocation failure
Currently when an alloc_page fails the error return is not set in
variable err and a garbage initialized value is returned. Fix this
by setting err to -ENOMEM before taking the error return path.
Addresses-Coverity: ("Uninitialized scalar variable") Fixes: a1f26739ccdc ("NFSv4.2: improve page handling for GETXATTR") Signed-off-by: Colin Ian King <[email protected]> Signed-off-by: Trond Myklebust <[email protected]>
writeback: don't warn on an unregistered BDI in __mark_inode_dirty
BDIs get unregistered during device removal, and this WARN can be
trivially triggered by hot-removing a NVMe device while running fsx
It is otherwise harmless as we still hold a BDI reference, and the
writeback has been shut down already.
Jiri Kosina [Wed, 16 Dec 2020 10:33:06 +0000 (11:33 +0100)]
Merge branch 'for-5.11/amd-sfh-hid' into for-linus
From Sandeep Singh.
AMD SFH (Sensor Fusion Hub) is HID based driver.SFH FW is part of MP2 processor
(MP2 which is an ARM core connected to x86 for processing sensor data) and it
runs on MP2 where in the driver resides on X86. The driver functionalities are
divided into three parts:
1: amd-mp2-pcie:- This part of the module will communicate with MP2
firmware. MP2 which is exposed as a PCI device to the
X86, uses mailboxes to talk to MP2 firmware to
send/receive commands.
2: Client Layer:- This part of the driver will use DRAM data and convert
the data into HID format based on HID reports.
3: Transport layer :- This part of the driver the will communicate with HID
core.Communication between devices and HID core is
mostly done via HID reports
In terms of architecture, it resembles like ISH (Intel Integrated Sensor Hub).
However the major difference is all the hid reports are generated as part of
the kernel driver.
AMD SFH is integrated as a part of SoC, starting from 17h family of processors.
The solution is working well on several OEM products. AMD SFH uses HID over
PCIe bus.
- lib: Fix fall-through warnings for Clang (Gustavo A. R. Silva)"
* tag 'fallthrough-fixes-clang-5.11-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gustavoars/linux:
lib: Fix fall-through warnings for Clang
powerpc: fix -Wimplicit-fallthrough
Revert "lib: Revert use of fallthrough pseudo-keyword in lib/"
powerpc: boot: include compiler_attributes.h
Linus Torvalds [Wed, 16 Dec 2020 08:19:28 +0000 (00:19 -0800)]
Merge tag 'linux-kselftest-kunit-5.11-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest
Pull Kunit updates from Shuah Khan:
- documentation update and fix to kunit_tool to parse diagnostic
messages correctly from David Gow
- Support for Parameterized Testing and fs/ext4 test updates to use
KUnit parameterized testing feature from Arpitha Raghunandan
- Helper to derive file names depending on --build_dir argument from
Andy Shevchenko
* tag 'linux-kselftest-kunit-5.11-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest:
fs: ext4: Modify inode-test.c to use KUnit parameterized testing feature
kunit: Support for Parameterized Testing
kunit: kunit_tool: Correctly parse diagnostic messages
Documentation: kunit: provide guidance for testing many inputs
kunit: Introduce get_file_path() helper
Linus Torvalds [Wed, 16 Dec 2020 08:17:58 +0000 (00:17 -0800)]
Merge tag 'linux-kselftest-next-5.11-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest
Pull Kselftest updates from Shuah Khan:
- Much needed gpio test Makefile cleanup to various problems with test
dependencies and build errors from Michael Ellerman
- Enabling vDSO test on non x86 platforms from Vincenzo Frascino
- Fix intel_pstate to replace deprecated ftime() usages with
clock_gettime() from Tommi Rantala
- cgroup test build fix on older releases from Sachin Sant
- A couple of spelling mistake fixes
* tag 'linux-kselftest-next-5.11-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest:
selftests/cgroup: Fix build on older distros
selftests/run_kselftest.sh: fix dry-run typo
tool: selftests: fix spelling typo of 'writting'
selftests/memfd: Fix implicit declaration warnings
selftests: intel_pstate: ftime() is deprecated
selftests/gpio: Add to CLEAN rule rather than overriding
selftests/gpio: Fix build when source tree is read only
selftests/gpio: Move include of lib.mk up
selftests/gpio: Use TEST_GEN_PROGS_EXTENDED
kselftest: Extend vdso correctness test to clock_gettime64
kselftest: Move test_vdso to the vDSO test suite
kselftest: Extend vDSO selftest to clock_getres
kselftest: Extend vDSO selftest
kselftest: Enable vDSO test on non x86 platforms
Linus Torvalds [Wed, 16 Dec 2020 08:15:46 +0000 (00:15 -0800)]
Merge tag 'linux-kselftest-fixes-5.11-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest
Pull Kselftest fixes from Shuah Khan:
"Build fixes for clone3 and rseq tests"
* tag 'linux-kselftest-fixes-5.11-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest:
selftests/clone3: Fix build error
rseq/selftests: Fix MEMBARRIER_CMD_PRIVATE_EXPEDITED_RSEQ build error under other arch.
Linus Torvalds [Wed, 16 Dec 2020 08:07:17 +0000 (00:07 -0800)]
Merge tag 'asm-generic-timers-5.11' of git://git.kernel.org/pub/scm/linux/kernel/git/arnd/asm-generic
Pull asm-generic cross-architecture timer cleanup from Arnd Bergmann:
"This cleans up two ancient timer features that were never completed in
the past, CONFIG_GENERIC_CLOCKEVENTS and CONFIG_ARCH_USES_GETTIMEOFFSET.
There was only one user left for the ARCH_USES_GETTIMEOFFSET variant
of clocksource implementations, the ARM EBSA110 platform. Rather than
changing to use modern timekeeping, we remove the platform entirely as
Russell no longer uses his machine and nobody else seems to have one
any more.
The conditional code for using arch_gettimeoffset() is removed as a
result.
For CONFIG_GENERIC_CLOCKEVENTS, there are still a couple of platforms
not using clockevent drivers: parisc, ia64, most of m68k, and one Arm
platform. These all do timer ticks slighly differently, and this gets
cleaned up to the point they at least all call the same helper
function.
Instead of most platforms using 'select GENERIC_CLOCKEVENTS' in
Kconfig, the polarity is now reversed, with the few remaining ones
selecting LEGACY_TIMER_TICK instead"
* tag 'asm-generic-timers-5.11' of git://git.kernel.org/pub/scm/linux/kernel/git/arnd/asm-generic:
timekeeping: default GENERIC_CLOCKEVENTS to enabled
timekeeping: remove xtime_update
m68k: remove timer_interrupt() function
m68k: change remaining timers to legacy_timer_tick
m68k: m68328: use legacy_timer_tick()
m68k: sun3/sun3c: use legacy_timer_tick
m68k: split heartbeat out of timer function
m68k: coldfire: use legacy_timer_tick()
parisc: use legacy_timer_tick
ARM: rpc: use legacy_timer_tick
ia64: convert to legacy_timer_tick
timekeeping: add CONFIG_LEGACY_TIMER_TICK
timekeeping: remove arch_gettimeoffset
net: remove am79c961a driver
ARM: remove ebsa110 platform
Linus Torvalds [Wed, 16 Dec 2020 07:58:04 +0000 (23:58 -0800)]
Merge tag 'asm-generic-mmu-context-5.11' of git://git.kernel.org/pub/scm/linux/kernel/git/arnd/asm-generic
Pull asm-generic mmu-context cleanup from Arnd Bergmann:
"This is a cleanup series from Nicholas Piggin, preparing for later
changes. The asm/mmu_context.h header are generalized and common code
moved to asm-gneneric/mmu_context.h.
This saves a bit of code and makes it easier to change in the future"
* tag 'asm-generic-mmu-context-5.11' of git://git.kernel.org/pub/scm/linux/kernel/git/arnd/asm-generic: (25 commits)
h8300: Fix generic mmu_context build
m68k: mmu_context: Fix Sun-3 build
xtensa: use asm-generic/mmu_context.h for no-op implementations
x86: use asm-generic/mmu_context.h for no-op implementations
um: use asm-generic/mmu_context.h for no-op implementations
sparc: use asm-generic/mmu_context.h for no-op implementations
sh: use asm-generic/mmu_context.h for no-op implementations
s390: use asm-generic/mmu_context.h for no-op implementations
riscv: use asm-generic/mmu_context.h for no-op implementations
powerpc: use asm-generic/mmu_context.h for no-op implementations
parisc: use asm-generic/mmu_context.h for no-op implementations
openrisc: use asm-generic/mmu_context.h for no-op implementations
nios2: use asm-generic/mmu_context.h for no-op implementations
nds32: use asm-generic/mmu_context.h for no-op implementations
mips: use asm-generic/mmu_context.h for no-op implementations
microblaze: use asm-generic/mmu_context.h for no-op implementations
m68k: use asm-generic/mmu_context.h for no-op implementations
ia64: use asm-generic/mmu_context.h for no-op implementations
hexagon: use asm-generic/mmu_context.h for no-op implementations
csky: use asm-generic/mmu_context.h for no-op implementations
...
Linus Torvalds [Wed, 16 Dec 2020 07:41:19 +0000 (23:41 -0800)]
Merge tag 'asm-generic-cleanup-5.11' of git://git.kernel.org/pub/scm/linux/kernel/git/arnd/asm-generic
Pull asm-generic cleanups from Arnd Bergmann:
"These are a couple of compiler warning fixes to make 'make W=2' less
noisy, as well as some fixes to code comments in asm-generic"
* tag 'asm-generic-cleanup-5.11' of git://git.kernel.org/pub/scm/linux/kernel/git/arnd/asm-generic:
syscalls: Fix file comments for syscalls implemented in kernel/sys.c
ctype.h: remove duplicate isdigit() helper
qspinlock: use signed temporaries for cmpxchg
asm-generic: fix ffs -Wshadow warning
asm-generic: percpu: avoid Wshadow warning
asm-generic/sembuf: Update architecture related information in comment
Linus Torvalds [Wed, 16 Dec 2020 07:26:37 +0000 (23:26 -0800)]
Merge branch 'akpm' (patches from Andrew)
Merge yet more updates from Andrew Morton:
- lots of little subsystems
- a few post-linux-next MM material. Most of the rest awaits more
merging of other trees.
Subsystems affected by this series: alpha, procfs, misc, core-kernel,
bitmap, lib, lz4, checkpatch, nilfs, kdump, rapidio, gcov, bfs, relay,
resource, ubsan, reboot, fault-injection, lzo, apparmor, and mm (swap,
memory-hotplug, pagemap, cleanups, and gup).
* emailed patches from Andrew Morton <[email protected]>: (86 commits)
mm: fix some spelling mistakes in comments
mm: simplify follow_pte{,pmd}
mm: unexport follow_pte_pmd
apparmor: remove duplicate macro list_entry_is_head()
lib/lzo/lzo1x_compress.c: make lzogeneric1x_1_compress() static
fault-injection: handle EI_ETYPE_TRUE
reboot: hide from sysfs not applicable settings
reboot: allow to override reboot type if quirks are found
reboot: remove cf9_safe from allowed types and rename cf9_force
reboot: allow to specify reboot mode via sysfs
reboot: refactor and comment the cpu selection code
lib/ubsan.c: mark type_check_kinds with static keyword
kcov: don't instrument with UBSAN
ubsan: expand tests and reporting
ubsan: remove UBSAN_MISC in favor of individual options
ubsan: enable for all*config builds
ubsan: disable UBSAN_TRAP for all*config
ubsan: disable object-size sanitizer under GCC
ubsan: move cc-option tests into Kconfig
ubsan: remove redundant -Wno-maybe-uninitialized
...
Merge __follow_pte_pmd, follow_pte_pmd and follow_pte into a single
follow_pte function and just pass two additional NULL arguments for the
two previous follow_pte callers.
Strangely I hadn't had noticed the existence of the list_entry_is_head()
in apparmor code when added the same one in the list.h. Luckily it's
fully identical and didn't break builds. In any case we don't need a
duplicate anymore, thus remove it from apparmor code.
Barnabás Pőcze [Wed, 16 Dec 2020 04:47:10 +0000 (20:47 -0800)]
fault-injection: handle EI_ETYPE_TRUE
Commit af3b854492f351d1 ("mm/page_alloc.c: allow error injection")
introduced EI_ETYPE_TRUE, but did not extend
* lib/error-inject.c:error_type_string(), and
* kernel/fail_function.c:adjust_error_retval()
to accommodate for this change.
Handle EI_ETYPE_TRUE in both functions appropriately by
* returning "TRUE" in error_type_string(),
* adjusting the return value to true (1) in adjust_error_retval().
Furthermore, simplify the logic of handling EI_ETYPE_NULL in
adjust_error_retval().
Matteo Croce [Wed, 16 Dec 2020 04:47:04 +0000 (20:47 -0800)]
reboot: allow to override reboot type if quirks are found
Patch series "reboot: sysfs improvements".
Some improvements to the sysfs reboot interface: hide not working settings
and support machines with known reboot quirks.
This patch (of 2):
On some machines a quirk can force a specific reboot type. Quirks are
found during a DMI scan, the list of machines which need special reboot
handling is defined in reboot_dmi_table.
The kernel command line reboot= option overrides this via a global
variable `reboot_default`, so that the reboot type requested in the
command line is really performed.
This was not true when setting the reboot type via the new sysfs
interface. Fix this by setting reboot_default upon the first change, like
reboot_setup() does for the command line.
Matteo Croce [Wed, 16 Dec 2020 04:46:57 +0000 (20:46 -0800)]
reboot: allow to specify reboot mode via sysfs
The kernel cmdline reboot= option offers some sort of control on how the
reboot is issued.
We don't always know in advance what type of reboot to perform.
Sometimes a warm reboot is preferred to persist certain memory regions
across the reboot. Others a cold one is needed to apply a future system
update that makes a memory memory model change, like changing the base
page size or resizing a persistent memory region.
Or simply we want to enable reboot_force because we noticed that
something bad happened.
Add handles in sysfs to allow setting these reboot options, so they can
be changed when the system is booted, other than at boot time.
The handlers are under <sysfs>/kernel/reboot, can be read to get the
current configuration and written to alter it.
Before setting anything, check for CAP_SYS_BOOT capability, so it's
possible to allow an unpriviledged process to change these settings simply
by relaxing the handles permissions, without opening them to the world.
Dmitry Vyukov [Wed, 16 Dec 2020 04:46:46 +0000 (20:46 -0800)]
kcov: don't instrument with UBSAN
Both KCOV and UBSAN use compiler instrumentation. If UBSAN detects a bug
in KCOV, it may cause infinite recursion via printk and other common
functions. We already don't instrument KCOV with KASAN/KCSAN for this
reason, don't instrument it with UBSAN as well.
As a side effect this also resolves the following gcc warning:
conflicting types for built-in function '__sanitizer_cov_trace_switch';
expected 'void(long unsigned int, void *)'
[-Wbuiltin-declaration-mismatch]
It's only reported when kcov.c is compiled with any of the sanitizers
enabled. Size of the arguments is correct, it's just that gcc uses 'long'
on 64-bit arches and 'long long' on 32-bit arches, while kernel type is
always 'long long'.
Kees Cook [Wed, 16 Dec 2020 04:46:43 +0000 (20:46 -0800)]
ubsan: expand tests and reporting
Expand the UBSAN tests to include some additional UB cases. Notably the
out-of-bounds enum loading appears not to work. Also include per-test
reporting, including the relevant CONFIG_UBSAN... Kconfigs.
Kees Cook [Wed, 16 Dec 2020 04:46:39 +0000 (20:46 -0800)]
ubsan: remove UBSAN_MISC in favor of individual options
Make each UBSAN option individually selectable and remove UBSAN_MISC which
no longer has any purpose. Add help text for each Kconfig, and include a
reference to the Clang sanitizer documentation. Disable unsigned overflow
by default (not available with GCC and makes x86 unbootable with Clang).
Disable unreachable when objtool is in use (redundant and confuses things:
instrumentation appears at unreachable locations).
Kees Cook [Wed, 16 Dec 2020 04:46:35 +0000 (20:46 -0800)]
ubsan: enable for all*config builds
With UBSAN_OBJECT_SIZE disabled for GCC, only UBSAN_ALIGNMENT remained a
noisy UBSAN option. Disable it for COMPILE_TEST so the rest of UBSAN can
be used for full all*config builds or other large combinations.
Kees Cook [Wed, 16 Dec 2020 04:46:31 +0000 (20:46 -0800)]
ubsan: disable UBSAN_TRAP for all*config
Doing all*config builds attempts to build as much as possible. UBSAN_TRAP
effectively short-circuits lib/usban.c, so it should be disabled for
COMPILE_TEST so that the lib/ubsan.c code gets built.
Kees Cook [Wed, 16 Dec 2020 04:46:24 +0000 (20:46 -0800)]
ubsan: move cc-option tests into Kconfig
Instead of doing if/endif blocks with cc-option calls in the UBSAN
Makefile, move all the tests into Kconfig and use the Makefile to collect
the results.
Kees Cook [Wed, 16 Dec 2020 04:46:20 +0000 (20:46 -0800)]
ubsan: remove redundant -Wno-maybe-uninitialized
Patch series "Clean up UBSAN Makefile", v2.
This series attempts to address the issues seen with UBSAN's object-size
sanitizer causing problems under GCC. In the process, the Kconfig and
Makefile are refactored to do all the cc-option calls in the Kconfig.
Additionally start to detangle -Wno-maybe-uninitialized, disable
UBSAN_TRAP under COMPILE_TEST for wider build coverage, and expand the
libusan tests.
This patch (of 7):
In commit 78a5255ffb6a ("Stop the ad-hoc games with
-Wno-maybe-initialized") -Wmaybe-uninitialized was disabled globally, so
keeping the disabling logic here too doesn't make sense.
Jani Nikula [Wed, 16 Dec 2020 04:45:57 +0000 (20:45 -0800)]
relay: allow the use of const callback structs
None of the relay users require the use of mutable structs for callbacks,
however the relay code does. Instead of assigning the default callback
for subbuf_start, add a wrapper to conditionally call the client callback
if available, and fall back to default behaviour otherwise.
This lets all relay users make their struct rchan_callbacks const data.
Jani Nikula [Wed, 16 Dec 2020 04:45:53 +0000 (20:45 -0800)]
relay: make create_buf_file and remove_buf_file callbacks mandatory
All clients provide create_buf_file and remove_buf_file callbacks, and
they're required for relay to make sense. There is no point in them being
optional.
Also document whether each callback is mandatory/optional.
Jani Nikula [Wed, 16 Dec 2020 04:45:50 +0000 (20:45 -0800)]
relay: require non-NULL callbacks in relay_open()
There are no clients passing NULL callbacks, which makes sense as it
wouldn't even create a file. Require non-NULL callbacks, and throw away
the handling for NULL callbacks.
Jani Nikula [Wed, 16 Dec 2020 04:45:47 +0000 (20:45 -0800)]
relay: remove unused buf_mapped and buf_unmapped callbacks
Patch series "relay: cleanup and const callbacks", v2.
None of the relay users require the use of mutable structs for callbacks,
however the relay code does. Instead of assigning default callbacks when
there is none, add callback wrappers to conditionally call the client
callbacks if available, and fall back to default behaviour (typically
no-op) otherwise.
This lets all relay users make their struct rchan_callbacks const data.
This series starts with a number of cleanups first based on Christoph's
feedback.
This patch (of 9):
No relay client uses the buf_mapped or buf_unmapped callbacks. Remove
them. This makes relay's vm_operations_struct close callback a dummy,
remove it as well.
Randy Dunlap [Wed, 16 Dec 2020 04:45:44 +0000 (20:45 -0800)]
bfs: don't use WARNING: string when it's just info.
Make the printk() [bfs "printf" macro] seem less severe by changing
"WARNING:" to "NOTE:".
<asm-generic/bug.h> warns us about using WARNING or BUG in a format string
other than in WARN() or BUG() family macros. bfs/inode.c is doing just
that in a normal printk() call, so change the "WARNING" string to be
"NOTE".
Alex Shi [Wed, 16 Dec 2020 04:45:40 +0000 (20:45 -0800)]
gcov: fix kernel-doc markup issue
Fix the following kernel-doc issue in gcov:
kernel/gcov/gcc_4_7.c:238: warning: Function parameter or member 'dst' not described in 'gcov_info_add'
kernel/gcov/gcc_4_7.c:238: warning: Function parameter or member 'src' not described in 'gcov_info_add'
kernel/gcov/gcc_4_7.c:238: warning: Excess function parameter 'dest' description in 'gcov_info_add'
kernel/gcov/gcc_4_7.c:238: warning: Excess function parameter 'source' description in 'gcov_info_add'
Nick Desaulniers [Wed, 16 Dec 2020 04:45:37 +0000 (20:45 -0800)]
gcov: remove support for GCC < 4.9
Since commit 0bddd227f3dc ("Documentation: update for gcc 4.9
requirement") the minimum supported version of GCC is gcc-4.9. It's now
safe to remove this code.
Similar to commit 10415533a906 ("gcov: Remove old GCC 3.4 support") but
that was for GCC 4.8 and this is for GCC 4.9.
rapidio: remove unused rio_get_asm() and rio_get_device()
The functions rio_get_asm() and rio_get_device() are globally exported
but have almost no users in tree. The only user is rio_init_mports()
which invokes it via rio_init().
rio_init() iterates over every registered device and invokes
rio_fixup_device(). It looks like a fixup function which should perform a
"change" to the device but does nothing. It has been like this since its
introduction in commit 394b701ce4fbf ("[PATCH] RapidIO support: core
base") which was merged into v2.6.15-rc1.
Remove rio_init() because the performed fixup function
(rio_fixup_device()) does nothing. Remove rio_get_asm() and
rio_get_device() which have no callers now.
kdump: append uts_namespace.name offset to VMCOREINFO
The offset of the field 'init_uts_ns.name' has changed since commit 9a56493f6942 ("uts: Use generic ns_common::count").
Make the offset of the field 'uts_namespace.name' available in VMCOREINFO
because tools like 'crash-utility' and 'makedumpfile' must be able to read
it from crash dumps.
Alex Shi [Wed, 16 Dec 2020 04:45:27 +0000 (20:45 -0800)]
fs/nilfs2: remove some unused macros to tame gcc
There some macros are unused and cause gcc warning. Remove them.
fs/nilfs2/segment.c:137:0: warning: macro "nilfs_cnt32_gt" is not used [-Wunused-macros]
fs/nilfs2/segment.c:144:0: warning: macro "nilfs_cnt32_le" is not used [-Wunused-macros]
fs/nilfs2/segment.c:143:0: warning: macro "nilfs_cnt32_lt" is not used [-Wunused-macros]
Dwaipayan Ray [Wed, 16 Dec 2020 04:45:15 +0000 (20:45 -0800)]
checkpatch: add warning for unnecessary use of %h[xudi] and %hh[xudi]
Modifiers %h and %hh should never be used.
Commit cbacb5ab0aa0 ("docs: printk-formats: Stop encouraging use of
unnecessary %h[xudi] and %hh[xudi]") specifies that:
"Standard integer promotion is already done and %hx and %hhx is useless
so do not encourage the use of %hh[xudi] or %h[xudi]."
"The "h" and "hh" things should never be used. The only reason for them
being used if you have an "int", but you want to print it out as a
"char" (and honestly, that is a really bad reason, you'd be better off
just using a proper cast to make the code more obvious)."
Add a new check to emit a warning on finding an unneeded use of %h or
%hh modifier.
checkpatch: add fix and improve warning msg for non-standard signature
Currently checkpatch warns for BAD_SIGN_OFF on non-standard signature
styles.
A large number of these warnings occur because of typo mistakes in
signature tags. An evaluation over v4.13..v5.8 showed that out of 539
warnings due to non-standard signatures, 87 are due to typo mistakes.
Following are the standard signature tags which are often incorrectly
used, along with their individual counts of incorrect use (over
v4.13..v5.8):
Reviewed-by: 42 Signed-off-by: 25 Reported-by: 6 Acked-by: 4 Tested-by: 4 Suggested-by: 4
Provide a fix by calculating levenshtein distance for the signature tag
with all the standard signatures and suggest a fix with a signature, whose
edit distance is less than or equal to 2 with the misspelled signature.
Out of the 86 mispelled signatures fixed with this approach, 85 were found
to be good corrections and 1 was bad correction.
Following was found to be a bad correction:
Tweeted-by (count: 1) => Tested-by
checkpatch: add fix option for LOGICAL_CONTINUATIONS
Currently, checkpatch warns if logical continuations are placed at the
start of a line and not at the end of previous line.
E.g., running checkpatch on commit 3485507fc272 ("staging: bcm2835-camera:
Reduce length of enum names") reports:
CHECK:LOGICAL_CONTINUATIONS: Logical continuations should be on the previous line
+ if (!ret
+ && camera_port ==
Provide a simple fix by inserting logical operator at the last
non-comment, non-whitespace char of the previous line and removing from
current line, if both the lines are additions(ie start with '+')
checkpatch: add fix option for ASSIGNMENT_CONTINUATIONS
Currently, checkpatch warns us if an assignment operator is placed at the
start of a line and not at the end of previous line.
E.g., running checkpatch on commit 8195b1396ec8 ("hv_netvsc: fix
deadlock on hotplug") reports:
CHECK: Assignment operator '=' should be on the previous line
+ struct netvsc_device *nvdev
+ = container_of(w, struct netvsc_device, subchan_work);
Provide a simple fix by appending assignment operator to the previous
line and removing from the current line, if both the lines are additions
(ie start with '+')
Dwaipayan Ray [Wed, 16 Dec 2020 04:45:02 +0000 (20:45 -0800)]
checkpatch: fix unescaped left brace
There is an unescaped left brace in a regex in OPEN_BRACE check. This
throws a runtime error when checkpatch is run with --fix flag and the
OPEN_BRACE check is executed.
- Multiple name comments should not be allowed.
- Comments inside address should not be allowed.
- In general comments should be enclosed within parentheses.
Relaxation is given to comments beginning with #.
- Stable addresses should not begin with a name.
- Comments in stable addresses should begin only
with a #.
Improvements to parsing:
- Detect and report unexpected content after email.
- Quoted names are excluded from comment parsing.
- Trailing dots, commas or quotes in email are removed during
formatting. Correspondingly a BAD_SIGN_OFF warning
is emitted.
- Improperly quoted email like '"name <address>"' are now
warned about.
In addition, added fixes for all the possible rules.
commit 33def8498fdd ("treewide: Convert macro and uses of
__section(foo) to __section("foo")") removed the stringification of the
section name and now requires quotes around the named section.
Update checkpatch to not remove any quotes when suggesting conversion
of __attribute__((section("name"))) to __section("name")
Miscellanea:
o Add section to the hash with __section replacement
o Remove separate test for __attribute__((section
o Remove the limitation on converting attributes containing only
known, possible conversions. Any unknown attribute types are now
left as-is and known types are converted and moved before
__attribute__ and removed from within the __attribute__((list...)).
Dwaipayan Ray [Wed, 16 Dec 2020 04:44:36 +0000 (20:44 -0800)]
checkpatch: extend attributes check to handle more patterns
It is generally preferred that the macros from
include/linux/compiler_attributes.h are used, unless there is a reason not
to.
checkpatch currently checks __attribute__ for each of packed, aligned,
section, printf, scanf, and weak. Other declarations in
compiler_attributes.h are not handled.
Add a generic test to check the presence of such attributes. Some
attributes require more specific handling and are kept separate.
Also add fixes to the generic attributes check to substitute the correct
conversions.
Declarations which contain multiple attributes like
__attribute__((__packed__, __cold__)) are also handled except when proper
conversions for one or more attributes of the list cannot be determined.
Here, it reports 'ff' and 'root' to be repeated, but it is in fact part
of some address or code, where it has to be repeated.
In these cases, the intent of the warning to find stylistic issues in
commit messages is not met and the warning is just completely wrong in
this case.
To avoid these warnings, add an additional regex check for the directory
permission pattern and avoid checking the line for this class of
warning. Similarly, to avoid hex pattern, check if the word consists of
hex symbols and skip this warning if it is not among the common english
words formed using hex letters.
A quick evaluation on v5.6..v5.8 showed that this fix reduces
REPEATED_WORD warnings by the frequency of 1890.
A quick manual check found all cases are related to hex output or list
command outputs in commit messages.
Dwaipayan Ray [Wed, 16 Dec 2020 04:44:20 +0000 (20:44 -0800)]
checkpatch: add new exception to repeated word check
Recently, commit 4f6ad8aa1eac ("checkpatch: move repeated word test")
moved the repeated word test to check for more file types. But after
this, if checkpatch.pl is run on MAINTAINERS, it generates several
new warnings of the type:
WARNING: Possible repeated word: 'git'
For example:
WARNING: Possible repeated word: 'git'
+T: git git://git.kernel.org/pub/scm/linux/kernel/git/rw/uml.git
So, the pattern "git git://..." is a false positive in this case.
There are several other combinations which may produce a wrong warning
message, such as "@size size", ":Begin begin", etc.
Extend repeated word check to compare the characters before and after
the word matches.
If there is a non whitespace character before the first word or a non
whitespace character excluding punctuation characters after the second
word, then the check is skipped and the warning is avoided.
Also add case insensitive word matching to the repeated word check.
Gao Xiang [Wed, 16 Dec 2020 04:44:03 +0000 (20:44 -0800)]
lib/lz4: explicitly support in-place decompression
LZ4 final literal copy could be overlapped when doing
in-place decompression, so it's unsafe to just use memcpy()
on an optimized memcpy approach but memmove() instead.
Upstream LZ4 has updated this years ago [1] (and the impact
is non-sensible [2] plus only a few bytes remain), this commit
just synchronizes LZ4 upstream code to the kernel side as well.
It can be observed as EROFS in-place decompression failure
on specific files when X86_FEATURE_ERMS is unsupported,
memcpy() optimization of commit 59daa706fbec ("x86, mem:
Optimize memcpy by avoiding memory false dependece") will
be enabled then.
Currently most modern x86-CPUs support ERMS, these CPUs just
use "rep movsb" approach so no problem at all. However, it can
still be verified with forcely disabling ERMS feature...
We didn't observe any strange on arm64/arm/x86 platform before
since most memcpy() would behave in an increasing address order
("copy upwards" [3]) and it's the correct order of in-place
decompression but it really needs an update to memmove() for sure
considering it's an undefined behavior according to the standard
and some unique optimization already exists in the kernel.
Francis Laniel [Wed, 16 Dec 2020 04:43:54 +0000 (20:43 -0800)]
drivers/misc/lkdtm: add new file in LKDTM to test fortified strscpy
This new test ensures that fortified strscpy has the same behavior than
vanilla strscpy (e.g. returning -E2BIG when src content is truncated).
Finally, it generates a crash at runtime because there is a write overflow
in destination string.
Daniel Axtens [Wed, 16 Dec 2020 04:43:47 +0000 (20:43 -0800)]
lkdtm: tests for FORTIFY_SOURCE
Add code to test both:
- runtime detection of the overrun of a structure. This covers the
__builtin_object_size(x, 0) case. This test is called FORTIFY_OBJECT.
- runtime detection of the overrun of a char array within a structure.
This covers the __builtin_object_size(x, 1) case which can be used
for some string functions. This test is called FORTIFY_SUBOBJECT.
Daniel Axtens [Wed, 16 Dec 2020 04:43:44 +0000 (20:43 -0800)]
lib: string.h: detect intra-object overflow in fortified string functions
Patch series "Fortify strscpy()", v7.
This patch implements a fortified version of strscpy() enabled by setting
CONFIG_FORTIFY_SOURCE=y. The new version ensures the following before
calling vanilla strscpy():
1. There is no read overflow because either size is smaller than src
length or we shrink size to src length by calling fortified strnlen().
2. There is no write overflow because we either failed during
compilation or at runtime by checking that size is smaller than dest
size. Note that, if src and dst size cannot be got, the patch defaults
to call vanilla strscpy().
The patches adds the following:
1. Implement the fortified version of strscpy().
2. Add a new LKDTM test to ensures the fortified version still returns
the same value as the vanilla one while panic'ing when there is a write
overflow.
3. Correct some typos in LKDTM related file.
I based my modifications on top of two patches from Daniel Axtens which
modify calls to __builtin_object_size, in fortified string functions, to
ensure the true size of char * are returned and not the surrounding
structure size.
About performance, I measured the slow down of fortified strscpy(), using
the vanilla one as baseline. The hardware I used is an Intel i3 2130 CPU
clocked at 3.4 GHz. I ran "Linux 5.10.0-rc4+ SMP PREEMPT" inside qemu
3.10 with 4 CPU cores. The following code, called through LKDTM, was used
as a benchmark:
#define TIMES 10000
char *src;
char dst[7];
int i;
ktime_t begin;
src = kstrdup("foobar", GFP_KERNEL);
if (src == NULL)
return;
begin = ktime_get();
for (i = 0; i < TIMES; i++)
strscpy(dst, src, strlen(src));
pr_info("%d fortified strscpy() tooks %lld", TIMES, ktime_get() - begin);
begin = ktime_get();
for (i = 0; i < TIMES; i++)
__real_strscpy(dst, src, strlen(src));
pr_info("%d vanilla strscpy() tooks %lld", TIMES, ktime_get() - begin);
kfree(src);
I called the above code 30 times to compute stats for each version (in ns,
round to int):
On average, fortified strscpy() is approximately 1.42 times slower than
vanilla strscpy(). For the 95th percentile, the fortified version is
about 1.50 times slower.
So, clearly the stats are not in favor of fortified strscpy(). But, the
fortified version loops the string twice (one in strnlen() and another in
vanilla strscpy()) while the vanilla one only loops once. This can
explain why fortified strscpy() is slower than the vanilla one.
This patch (of 5):
When the fortify feature was first introduced in commit 6974f0c4555e
("include/linux/string.h: add the option of fortified string.h
functions"), Daniel Micay observed:
* It should be possible to optionally use __builtin_object_size(x, 1) for
some functions (C strings) to detect intra-object overflows (like
glibc's _FORTIFY_SOURCE=2), but for now this takes the conservative
approach to avoid likely compatibility issues.
This is a case that often cannot be caught by KASAN. Consider:
The questionable copy overflows foo.a and writes to foo.b as well. It
cannot be detected by KASAN. Currently it is also not detected by
fortify, because strcpy considers __builtin_object_size(x, 0), which
considers the size of the surrounding object (here, struct foo). However,
if we switch the string functions over to use __builtin_object_size(x, 1),
the compiler will measure the size of the closest surrounding subobject
(here, foo.a), rather than the size of the surrounding object as a whole.
See https://gcc.gnu.org/onlinedocs/gcc/Object-Size-Checking.html for more
info.
Only do this for string functions: we cannot use it on things like memcpy,
memmove, memcmp and memchr_inv due to code like this which purposefully
operates on multiple structure members: (arch/x86/kernel/traps.c)
/*
* regs->sp points to the failing IRET frame on the
* ESPFIX64 stack. Copy it to the entry stack. This fills
* in gpregs->ss through gpregs->ip.
*
*/
memmove(&gpregs->ip, (void *)regs->sp, 5*8);
This change passes an allyesconfig on powerpc and x86, and an x86 kernel
built with it survives running with syz-stress from syzkaller, so it seems
safe so far.
Nick Desaulniers [Wed, 16 Dec 2020 04:43:40 +0000 (20:43 -0800)]
lib/string: remove unnecessary #undefs
A few architecture specific string.h functions used to be implemented in
terms of preprocessor defines to the corresponding compiler builtins.
Since this is no longer the case, remove unused #undefs.
Only memcmp is still defined in terms of builtins for a few arches.
Jakub Jelinek [Wed, 16 Dec 2020 04:43:37 +0000 (20:43 -0800)]
ilog2: improve ilog2 for constant arguments
As discussed in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97445 the
const_ilog2 macro generates a lot of code which interferes badly with GCC
inlining heuristics, until it can be proven that the ilog2 argument can or
can't be simplified into a constant.
It can be expressed using __builtin_clzll builtin which is supported by
GCC 3.4 and later and when used only in the __builtin_constant_p guarded
code it ought to always fold back to a constant. Other compilers support
the same builtin for many years too.
Other option would be to change the const_ilog2 macro, though as the
description says it is meant to be used also in C constant expressions,
and while GCC will fold it to constant with constant argument even in
those, perhaps it is better to avoid using extensions in that case.
Andy Shevchenko [Wed, 16 Dec 2020 04:43:30 +0000 (20:43 -0800)]
lib/cmdline: allow NULL to be an output for get_option()
In the future we would like to use get_option() to only validate the
string and parse it separately. To achieve this, allow NULL to be an
output for get_option().
lib/stackdepot.c: use flex_array_size() helper in memcpy()
Make use of the flex_array_size() helper to calculate the size of a
flexible array member within an enclosing structure.
This helper offers defense-in-depth against potential integer overflows,
while at the same time makes it explicitly clear that we are dealing with
a flexible array member.
lib/stackdepot.c: replace one-element array with flexible-array member
Patch series "lib/stackdepot.c: Replace one-element array with flexible-array member".
This series aims to replace a one-element array with a flexible-array
member. Also, make use of the struct_size(), flexible_array_size() and
array_size() helpers.
This patch (of 3):
There is a regular need in the kernel to provide a way to declare having a
dynamically sized set of trailing elements in a structure. Kernel code
should always use “flexible array members”[1] for these cases. The
older style of one-element or zero-length arrays should no longer be
used[2].
Refactor the code according to the use of a flexible-array member in
struct stack_record, instead of a one-element array, and use the
struct_size() helper to calculate the size for the allocation.
The test module to check that free_pages() does not leak memory does not
provide any feedback whatsoever its state or progress, but may take some
time on slow machines. Add the printing of messages upon starting each
phase of the test, and upon completion.
projects / linux.git / log