Tudor Ambarus [Wed, 16 Dec 2020 09:23:21 +0000 (11:23 +0200)]
spi: Fix the clamping of spi->max_speed_hz
If spi->controller->max_speed_hz is zero, a non-zero spi->max_speed_hz
will be overwritten by zero. Make sure spi->controller->max_speed_hz
is not zero when clamping spi->max_speed_hz.
Put the spi->controller->max_speed_hz non-zero check higher in the if,
so that we avoid a superfluous init to zero when both spi->max_speed_hz
and spi->controller->max_speed_hz are zero.
The __init annotations on hyp_cpu_pm_{init,exit} are obviously incorrect,
and the build system shouts at you if you enable DEBUG_SECTION_MISMATCH.
Nothing really bad happens as we never execute that code outside of the
init context, but we can't label the callers as __int either, as kvm_init
isn't __init itself. Oh well.
Randy Dunlap [Tue, 29 Dec 2020 03:47:06 +0000 (19:47 -0800)]
fs: block_dev.c: fix kernel-doc warnings from struct block_device changes
Fix new kernel-doc warnings in fs/block_dev.c:
../fs/block_dev.c:1066: warning: Excess function parameter 'whole' description in 'bd_abort_claiming'
../fs/block_dev.c:1837: warning: Function parameter or member 'dev' not described in 'lookup_bdev'
Linus Torvalds [Tue, 29 Dec 2020 23:45:49 +0000 (15:45 -0800)]
Merge branch 'akpm' (patches from Andrew)
Merge misc fixes from Andrew Morton:
"16 patches
Subsystems affected by this patch series: mm (selftests, hugetlb,
pagecache, mremap, kasan, and slub), kbuild, checkpatch, misc, and
lib"
* emailed patches from Andrew Morton <[email protected]>:
mm: slub: call account_slab_page() after slab page initialization
zlib: move EXPORT_SYMBOL() and MODULE_LICENSE() out of dfltcc_syms.c
lib/zlib: fix inflating zlib streams on s390
lib/genalloc: fix the overflow when size is too big
kdev_t: always inline major/minor helper functions
sizes.h: add SZ_8G/SZ_16G/SZ_32G macros
local64.h: make <asm/local64.h> mandatory
kasan: fix null pointer dereference in kasan_record_aux_stack
mm: generalise COW SMC TLB flushing race comment
mm/mremap.c: fix extent calculation
mm: memmap defer init doesn't work as expected
mm: add prototype for __add_to_page_cache_locked()
checkpatch: prefer strscpy to strlcpy
Revert "kbuild: avoid static_assert for genksyms"
mm/hugetlb: fix deadlock in hugetlb_cow error path
selftests/vm: fix building protection keys test
Roman Gushchin [Tue, 29 Dec 2020 23:15:07 +0000 (15:15 -0800)]
mm: slub: call account_slab_page() after slab page initialization
It's convenient to have page->objects initialized before calling into
account_slab_page(). In particular, this information can be used to
pre-alloc the obj_cgroup vector.
Let's call account_slab_page() a bit later, after the initialization of
page->objects.
This commit doesn't bring any functional change, but is required for
further optimizations.
[[email protected]: undo changes needed by forthcoming mm-memcg-slab-pre-allocate-obj_cgroups-for-slab-caches-with-slab_account.patch]
Randy Dunlap [Tue, 29 Dec 2020 23:15:04 +0000 (15:15 -0800)]
zlib: move EXPORT_SYMBOL() and MODULE_LICENSE() out of dfltcc_syms.c
In commit 11fb479ff5d9 ("zlib: export S390 symbols for zlib modules"), I
added EXPORT_SYMBOL()s to dfltcc_inflate.c but then Mikhail said that
these should probably be in dfltcc_syms.c with the other
EXPORT_SYMBOL()s.
However, that is contrary to the current kernel style, which places
EXPORT_SYMBOL() immediately after the function that it applies to, so
move all EXPORT_SYMBOL()s to their respective function locations and
drop the dfltcc_syms.c file. Also move MODULE_LICENSE() from the
deleted file to dfltcc.c.
Ilya Leoshkevich [Tue, 29 Dec 2020 23:15:01 +0000 (15:15 -0800)]
lib/zlib: fix inflating zlib streams on s390
Decompressing zlib streams on s390 fails with "incorrect data check"
error.
Userspace zlib checks inflate_state.flags in order to byteswap checksums
only for zlib streams, and s390 hardware inflate code, which was ported
from there, tries to match this behavior. At the same time, kernel zlib
does not use inflate_state.flags, so it contains essentially random
values. For many use cases either zlib stream is zeroed out or checksum
is not used, so this problem is masked, but at least SquashFS is still
affected.
Fix by always passing a checksum to and from the hardware as is, which
matches zlib_inflate()'s expectations.
Randy Dunlap [Tue, 29 Dec 2020 23:14:49 +0000 (15:14 -0800)]
local64.h: make <asm/local64.h> mandatory
Make <asm-generic/local64.h> mandatory in include/asm-generic/Kbuild and
remove all arch/*/include/asm/local64.h arch-specific files since they
only #include <asm-generic/local64.h>.
This fixes build errors on arch/c6x/ and arch/nios2/ for
block/blk-iocost.c.
Build-tested on 21 of 25 arch-es. (tools problems on the others)
Yes, we could even rename <asm-generic/local64.h> to
<linux/local64.h> and change all #includes to use
<linux/local64.h> instead.
Nicholas Piggin [Tue, 29 Dec 2020 23:14:43 +0000 (15:14 -0800)]
mm: generalise COW SMC TLB flushing race comment
I'm not sure if I'm completely missing something here, but AFAIKS the
reference to the mysterious "COW SMC race" confuses the issue. The
original changelog and mailing list thread didn't help me either.
This SMC race is where the problem was detected, but isn't the general
problem bigger and more obvious: that the new PTE could be picked up at
any time by any TLB while entries for the old PTE exist in other TLBs
before the TLB flush takes effect?
The case where the iTLB and dTLB of a CPU are pointing at different pages
is an interesting one but follows from the general problem.
The other (minor) thing with the comment I think it makes it a bit clearer
to say what the old code was doing (i.e., it avoids the race as opposed to
what?).
Baoquan He [Tue, 29 Dec 2020 23:14:37 +0000 (15:14 -0800)]
mm: memmap defer init doesn't work as expected
VMware observed a performance regression during memmap init on their
platform, and bisected to commit 73a6e474cb376 ("mm: memmap_init:
iterate over memblock regions rather that check each PFN") causing it.
Before the commit:
[0.033176] Normal zone: 1445888 pages used for memmap
[0.033176] Normal zone: 89391104 pages, LIFO batch:63
[0.035851] ACPI: PM-Timer IO Port: 0x448
With commit
[0.026874] Normal zone: 1445888 pages used for memmap
[0.026875] Normal zone: 89391104 pages, LIFO batch:63
[2.028450] ACPI: PM-Timer IO Port: 0x448
The root cause is the current memmap defer init doesn't work as expected.
Before, memmap_init_zone() was used to do memmap init of one whole zone,
to initialize all low zones of one numa node, but defer memmap init of
the last zone in that numa node. However, since commit 73a6e474cb376,
function memmap_init() is adapted to iterater over memblock regions
inside one zone, then call memmap_init_zone() to do memmap init for each
region.
E.g, on VMware's system, the memory layout is as below, there are two
memory regions in node 2. The current code will mistakenly initialize the
whole 1st region [mem 0xab00000000-0xfcffffffff], then do memmap defer to
iniatialize only one memmory section on the 2nd region [mem
0x10000000000-0x1033fffffff]. In fact, we only expect to see that there's
only one memory section's memmap initialized. That's why more time is
costed at the time.
Now, let's add a parameter 'zone_end_pfn' to memmap_init_zone() to pass
down the real zone end pfn so that defer_init() can use it to judge
whether defer need be taken in zone wide.
Souptick Joarder [Tue, 29 Dec 2020 23:14:34 +0000 (15:14 -0800)]
mm: add prototype for __add_to_page_cache_locked()
Otherwise it causes a gcc warning:
mm/filemap.c:830:14: warning: no previous prototype for `__add_to_page_cache_locked' [-Wmissing-prototypes]
A previous attempt to make this function static led to compilation
errors when CONFIG_DEBUG_INFO_BTF is enabled because
__add_to_page_cache_locked() is referred to by BPF code.
Macro Elver had sent a fix proper fix earlier, and also pointed out
corner cases:
"I guess what you propose is simpler, but might still have corner cases
where we still get warnings. In particular, if some file (for whatever
reason) does not include build_bug.h and uses a raw _Static_assert(),
then we still get warnings. E.g. I see 1 user of raw _Static_assert()
(drivers/gpu/drm/amd/amdgpu/amdgv_sriovmsg.h )."
I believe the raw use of _Static_assert() should be allowed, so this
should be fixed in genksyms.
Even after commit 14dc3983b5df ("kbuild: avoid static_assert for
genksyms"), I confirmed the following test code emits the warning.
Mike Kravetz [Tue, 29 Dec 2020 23:14:25 +0000 (15:14 -0800)]
mm/hugetlb: fix deadlock in hugetlb_cow error path
syzbot reported the deadlock here [1]. The issue is in hugetlb cow
error handling when there are not enough huge pages for the faulting
task which took the original reservation. It is possible that other
(child) tasks could have consumed pages associated with the reservation.
In this case, we want the task which took the original reservation to
succeed. So, we unmap any associated pages in children so that they can
be used by the faulting task that owns the reservation.
The unmapping code needs to hold i_mmap_rwsem in write mode. However,
due to commit c0d0381ade79 ("hugetlbfs: use i_mmap_rwsem for more pmd
sharing synchronization") we are already holding i_mmap_rwsem in read
mode when hugetlb_cow is called.
Technically, i_mmap_rwsem does not need to be held in read mode for COW
mappings as they can not share pmd's. Modifying the fault code to not
take i_mmap_rwsem in read mode for COW (and other non-sharable) mappings
is too involved for a stable fix.
Instead, we simply drop the hugetlb_fault_mutex and i_mmap_rwsem before
unmapping. This is OK as it is technically not needed. They are
reacquired after unmapping as expected by calling code. Since this is
done in an uncommon error path, the overhead of dropping and reacquiring
mutexes is acceptable.
While making changes, remove redundant BUG_ON after unmap_ref_private.
Harish [Tue, 29 Dec 2020 23:14:22 +0000 (15:14 -0800)]
selftests/vm: fix building protection keys test
Commit d8cbe8bfa7d ("tools/testing/selftests/vm: fix build error") tried
to include a ARCH check for powerpc, however ARCH is not defined in the
Makefile before including lib.mk. This makes test building to skip on
both x86 and powerpc.
Fix the arch check by replacing it using machine type as it is already
defined and used in the test.
Jens Axboe [Tue, 29 Dec 2020 17:50:46 +0000 (10:50 -0700)]
io_uring: don't assume mm is constant across submits
If we COW the identity, we assume that ->mm never changes. But this
isn't true of multiple processes end up sharing the ring. Hence treat
id->mm like like any other process compontent when it comes to the
identity mapping. This is pretty trivial, just moving the existing grab
into io_grab_identity(), and including a check for the match.
Iskren Chernev [Mon, 28 Dec 2020 21:31:30 +0000 (23:31 +0200)]
drm/msm: Fix null dereference in _msm_gem_new
The crash was caused by locking an uninitialized lock during init of
drm_gem_object. The lock changed in the breaking commit, but the init
was not moved accordingly.
8<--- cut here ---
Unable to handle kernel NULL pointer dereference at virtual address 00000000
pgd = (ptrval)
[00000000] *pgd=00000000
Internal error: Oops: 5 [#1] PREEMPT SMP ARM
Modules linked in: msm(+) qcom_spmi_vadc qcom_vadc_common dm_mod usb_f_rndis rmi_i2c rmi_core qnoc_msm8974 icc_smd_rpm pm8941_pwrkey
CPU: 2 PID: 1020 Comm: udevd Not tainted 5.10.0-postmarketos-qcom-msm8974 #8
Hardware name: Generic DT based system
PC is at ww_mutex_lock+0x20/0xb0
LR is at _msm_gem_new+0x13c/0x298 [msm]
pc : [<c0be31e8>] lr : [<bf0b3404>] psr: 20000013
sp : c36e7ad0 ip : c3b3d800 fp : 00000000
r10: 00000001 r9 : c3b22800 r8 : 00000000
r7 : c3b23000 r6 : c3b3d600 r5 : c3b3d600 r4 : 00000000
r3 : c34b4780 r2 : c3b3d6f4 r1 : 00000000 r0 : 00000000
Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none
Control: 10c5787d Table: 03ae406a DAC: 00000051
Process udevd (pid: 1020, stack limit = 0x(ptrval))
Stack: (0xc36e7ad0 to 0xc36e8000)
[...]
[<c0be31e8>] (ww_mutex_lock) from [<bf0b3404>] (_msm_gem_new+0x13c/0x298 [msm])
[<bf0b3404>] (_msm_gem_new [msm]) from [<bf0b3aa8>] (_msm_gem_kernel_new+0x20/0x190 [msm])
[<bf0b3aa8>] (_msm_gem_kernel_new [msm]) from [<bf0b4a30>] (msm_gem_kernel_new+0x24/0x2c [msm])
[<bf0b4a30>] (msm_gem_kernel_new [msm]) from [<bf0b8e2c>] (msm_gpu_init+0x308/0x548 [msm])
[<bf0b8e2c>] (msm_gpu_init [msm]) from [<bf060a90>] (adreno_gpu_init+0x13c/0x240 [msm])
[<bf060a90>] (adreno_gpu_init [msm]) from [<bf062b1c>] (a3xx_gpu_init+0x78/0x1dc [msm])
[<bf062b1c>] (a3xx_gpu_init [msm]) from [<bf05f394>] (adreno_bind+0x1cc/0x274 [msm])
[<bf05f394>] (adreno_bind [msm]) from [<c087a254>] (component_bind_all+0x11c/0x278)
[<c087a254>] (component_bind_all) from [<bf0b11d4>] (msm_drm_bind+0x18c/0x5b4 [msm])
[<bf0b11d4>] (msm_drm_bind [msm]) from [<c0879ea0>] (try_to_bring_up_master+0x200/0x2c8)
[<c0879ea0>] (try_to_bring_up_master) from [<c087a648>] (component_master_add_with_match+0xc8/0xfc)
[<c087a648>] (component_master_add_with_match) from [<bf0b0c3c>] (msm_pdev_probe+0x288/0x2c4 [msm])
[<bf0b0c3c>] (msm_pdev_probe [msm]) from [<c08844cc>] (platform_drv_probe+0x48/0x98)
[<c08844cc>] (platform_drv_probe) from [<c0881cc4>] (really_probe+0x108/0x528)
[<c0881cc4>] (really_probe) from [<c0882480>] (driver_probe_device+0x78/0x1d4)
[<c0882480>] (driver_probe_device) from [<c08828dc>] (device_driver_attach+0xa8/0xb0)
[<c08828dc>] (device_driver_attach) from [<c0882998>] (__driver_attach+0xb4/0x154)
[<c0882998>] (__driver_attach) from [<c087fa1c>] (bus_for_each_dev+0x78/0xb8)
[<c087fa1c>] (bus_for_each_dev) from [<c0880e98>] (bus_add_driver+0x10c/0x208)
[<c0880e98>] (bus_add_driver) from [<c0883504>] (driver_register+0x88/0x118)
[<c0883504>] (driver_register) from [<c0302098>] (do_one_initcall+0x50/0x2b0)
[<c0302098>] (do_one_initcall) from [<c03bace4>] (do_init_module+0x60/0x288)
[<c03bace4>] (do_init_module) from [<c03bdf1c>] (sys_finit_module+0xd4/0x120)
[<c03bdf1c>] (sys_finit_module) from [<c0300060>] (ret_fast_syscall+0x0/0x54)
Exception stack(0xc36e7fa8 to 0xc36e7ff0)
7fa0: 000200000000000000000007b6edd5b000000000b6f2ff20
7fc0: 00020000000000000000017b0000017bb6eef980bedc3a5400473c9900000000
7fe0: b6edd5b0bedc3918b6ed8a5fb6f6a8b0
Code: e3c3303fe593300ce1a04000f590f000 (e1940f9f)
---[ end trace 277e2a3da40bbb76 ]---
Fixes: 6c0e3ea250476 ("drm/msm/gem: Switch over to obj->resv for locking") Signed-off-by: Iskren Chernev <[email protected]> Signed-off-by: Rob Clark <[email protected]>
Jiang Wang [Thu, 24 Dec 2020 01:12:42 +0000 (01:12 +0000)]
selftests/bpf: Fix a compile error for BPF_F_BPRM_SECUREEXEC
When CONFIG_BPF_LSM is not configured, running bpf selftesting will show
BPF_F_BPRM_SECUREEXEC undefined error for bprm_opts.c.
The problem is that bprm_opts.c includes vmliunx.h. The vmlinux.h is
generated by "bpftool btf dump file ./vmlinux format c". On the other
hand, BPF_F_BPRM_SECUREEXEC is defined in include/uapi/linux/bpf.h
and used only in bpf_lsm.c. When CONFIG_BPF_LSM is not set, bpf_lsm
will not be compiled, so vmlinux.h will not include definition of
BPF_F_BPRM_SECUREEXEC.
Ideally, we want to compile bpf selftest regardless of the configuration
setting, so change the include file from vmlinux.h to bpf.h.
Xu Yilun [Tue, 29 Dec 2020 05:27:41 +0000 (13:27 +0800)]
spi: altera: fix return value for altera_spi_txrx()
This patch fixes the return value for altera_spi_txrx. It should return
1 for interrupt transfer mode, and return 0 for polling transfer mode.
The altera_spi_txrx() implements the spi_controller.transfer_one
callback. According to the spi-summary.rst, the transfer_one should
return 0 when transfer is finished, return 1 when transfer is still in
progress.
Xiaolei Wang [Tue, 29 Dec 2020 10:50:46 +0000 (18:50 +0800)]
regmap: debugfs: Fix a memory leak when calling regmap_attach_dev
After initializing the regmap through
syscon_regmap_lookup_by_compatible, then regmap_attach_dev to the
device, because the debugfs_name has been allocated, there is no
need to redistribute it again
Dan Carpenter [Mon, 14 Dec 2020 11:56:52 +0000 (14:56 +0300)]
dmaengine: dw-edma: Fix use after free in dw_edma_alloc_chunk()
If the dw_edma_alloc_burst() function fails then we free "chunk" but
it's still on the "desc->chunk->list" list so it will lead to a use
after free. Also the "->chunks_alloc" count is incremented when it
shouldn't be.
In current kernels small allocations are guaranteed to succeed and
dw_edma_alloc_burst() can't fail so this will not actually affect
runtime.
dmaengine: milbeaut-xdmac: Fix a resource leak in the error handling path of the probe function
'disable_xdmac()' should be called in the error handling path of the
probe function to undo a previous 'enable_xdmac()' call, as already
done in the remove function.
dmaengine: mediatek: mtk-hsdma: Fix a resource leak in the error handling path of the probe function
'mtk_hsdma_hw_deinit()' should be called in the error handling path of the
probe function to undo a previous 'mtk_hsdma_hw_init()' call, as already
done in the remove function.
Xiaoming Ni [Fri, 18 Dec 2020 10:41:37 +0000 (18:41 +0800)]
dmaengine: qcom: gpi: Fixes a format mismatch
drivers/dma/qcom/gpi.c:1419:3: warning: format '%lu' expects argument of
type 'long unsigned int', but argument 8 has type 'size_t {aka unsigned
int}' [-Wformat=]
drivers/dma/qcom/gpi.c:1427:31: warning: format '%lu' expects argument of
type 'long unsigned int', but argument 3 has type 'size_t {aka unsigned
int}' [-Wformat=]
drivers/dma/qcom/gpi.c:1447:3: warning: format '%llx' expects argument of
type 'long long unsigned int', but argument 4 has type 'dma_addr_t {aka
unsigned int}' [-Wformat=]
drivers/dma/qcom/gpi.c:1447:3: warning: format '%llx' expects argument of
type 'long long unsigned int', but argument 5 has type 'phys_addr_t {aka
unsigned int}' [-Wformat=]
Dan Carpenter [Wed, 16 Dec 2020 08:29:46 +0000 (11:29 +0300)]
dmaengine: idxd: off by one in cleanup code
The clean up is off by one so this will start at "i" and it should start
with "i - 1" and then it doesn't unregister the zeroeth elements in the
array.
The following pull-request contains BPF updates for your *net* tree.
There is a small merge conflict between bpf tree commit 69ca310f3416
("bpf: Save correct stopping point in file seq iteration") and net tree
commit 66ed594409a1 ("bpf/task_iter: In task_file_seq_get_next use
task_lookup_next_fd_rcu"). The get_files_struct() does not exist anymore
in net, so take the hunk in HEAD and add the `info->tid = curr_tid` to
the error path:
Xie He [Mon, 28 Dec 2020 02:53:39 +0000 (18:53 -0800)]
net: hdlc_ppp: Fix issues when mod_timer is called while timer is running
ppp_cp_event is called directly or indirectly by ppp_rx with "ppp->lock"
held. It may call mod_timer to add a new timer. However, at the same time
ppp_timer may be already running and waiting for "ppp->lock". In this
case, there's no need for ppp_timer to continue running and it can just
exit.
If we let ppp_timer continue running, it may call add_timer. This causes
kernel panic because add_timer can't be called with a timer pending.
This patch fixes this problem.
Fixes: e022c2f07ae5 ("WAN: new synchronous PPP implementation for generic HDLC.") Cc: Krzysztof Halasa <[email protected]> Signed-off-by: Xie He <[email protected]> Signed-off-by: David S. Miller <[email protected]>
This was tested on a RaptorCS Talos II with IBM POWER9 DD2.2 CPUs and an
ASUS XG-C100F PCI-e card without any issue. Speeds of ~8Gbps could be
attained with not-very-scientific (wget HTTP) both-ways measurements on
a local network. No warning or error reported in kernel logs. The
drivers seems to be portable enough for it not to be gated like such.
Cong Wang [Sat, 26 Dec 2020 23:44:53 +0000 (15:44 -0800)]
erspan: fix version 1 check in gre_parse_header()
Both version 0 and version 1 use ETH_P_ERSPAN, but version 0 does not
have an erspan header. So the check in gre_parse_header() is wrong,
we have to distinguish version 1 from version 0.
We can just check the gre header length like is_erspan_type1().
Randy Dunlap [Fri, 25 Dec 2020 06:23:44 +0000 (22:23 -0800)]
net: sched: prevent invalid Scell_log shift count
Check Scell_log shift size in red_check_params() and modify all callers
of red_check_params() to pass Scell_log.
This prevents a shift out-of-bounds as detected by UBSAN:
UBSAN: shift-out-of-bounds in ./include/net/red.h:252:22
shift exponent 72 is too large for 32-bit type 'int'
weichenchen [Fri, 25 Dec 2020 05:44:45 +0000 (13:44 +0800)]
net: neighbor: fix a crash caused by mod zero
pneigh_enqueue() tries to obtain a random delay by mod
NEIGH_VAR(p, PROXY_DELAY). However, NEIGH_VAR(p, PROXY_DELAY)
migth be zero at that point because someone could write zero
to /proc/sys/net/ipv4/neigh/[device]/proxy_delay after the
callers check it.
This patch uses prandom_u32_max() to get a random delay instead
which avoids potential division by zero.
Guillaume Nault [Thu, 24 Dec 2020 19:01:09 +0000 (20:01 +0100)]
ipv4: Ignore ECN bits for fib lookups in fib_compute_spec_dst()
RT_TOS() only clears one of the ECN bits. Therefore, when
fib_compute_spec_dst() resorts to a fib lookup, it can return
different results depending on the value of the second ECN bit.
For example, ECT(0) and ECT(1) packets could be treated differently.
$ ip netns add ns0
$ ip netns add ns1
$ ip link add name veth01 netns ns0 type veth peer name veth10 netns ns1
$ ip -netns ns0 link set dev lo up
$ ip -netns ns1 link set dev lo up
$ ip -netns ns0 link set dev veth01 up
$ ip -netns ns1 link set dev veth10 up
$ ip -netns ns0 address add 192.0.2.10/24 dev veth01
$ ip -netns ns1 address add 192.0.2.11/24 dev veth10
$ ip -netns ns1 address add 192.0.2.21/32 dev lo
$ ip -netns ns1 route add 192.0.2.10/32 tos 4 dev veth10 src 192.0.2.21
$ ip netns exec ns1 sysctl -wq net.ipv4.icmp_echo_ignore_broadcasts=0
With TOS 4 and ECT(1), ns1 replies using source address 192.0.2.21
(ping uses -Q to set all TOS and ECN bits):
$ ip netns exec ns0 ping -c 1 -b -Q 5 192.0.2.255
[...]
64 bytes from 192.0.2.21: icmp_seq=1 ttl=64 time=0.544 ms
But with TOS 4 and ECT(0), ns1 replies using source address 192.0.2.11
because the "tos 4" route isn't matched:
$ ip netns exec ns0 ping -c 1 -b -Q 6 192.0.2.255
[...]
64 bytes from 192.0.2.11: icmp_seq=1 ttl=64 time=0.597 ms
After this patch the ECN bits don't affect the result anymore:
$ ip netns exec ns0 ping -c 1 -b -Q 6 192.0.2.255
[...]
64 bytes from 192.0.2.21: icmp_seq=1 ttl=64 time=0.591 ms
Fixes: 35ebf65e851c ("ipv4: Create and use fib_compute_spec_dst() helper.") Signed-off-by: Guillaume Nault <[email protected]> Signed-off-by: David S. Miller <[email protected]>
The packet coalescing interrupt threshold has separated registers
for different aggregated/cpu (sw-thread). The required value should
be loaded for every thread but not only for 1 current cpu.
====================
net: ipa: fix some new build warnings
I got a super friendly message from the Intel kernel test robot that
pointed out that two patches I posted last week caused new build
warnings. I already had these problems fixed in my own tree but
the fix was not included in what I sent out last week.
====================
Alex Elder [Sat, 26 Dec 2020 21:37:37 +0000 (15:37 -0600)]
net: ipa: don't return a value from evt_ring_command()
Callers of evt_ring_command() no longer care whether the command
times out, and don't use what evt_ring_command() returns. Redefine
that function to have void return type.
Reported-by: kernel test robot <[email protected]> Fixes: 428b448ee764a ("net: ipa: use state to determine event ring command success") Signed-off-by: Alex Elder <[email protected]> Signed-off-by: Jakub Kicinski <[email protected]>
Alex Elder [Sat, 26 Dec 2020 21:37:36 +0000 (15:37 -0600)]
net: ipa: don't return a value from gsi_channel_command()
Callers of gsi_channel_command() no longer care whether the command
times out, and don't use what gsi_channel_command() returns. Redefine
that function to have void return type.
Reported-by: kernel test robot <[email protected]> Fixes: 6ffddf3b3d182 ("net: ipa: use state to determine channel command success") Signed-off-by: Alex Elder <[email protected]> Signed-off-by: Jakub Kicinski <[email protected]>
Michael Chan [Sun, 27 Dec 2020 19:18:18 +0000 (14:18 -0500)]
bnxt_en: Check TQM rings for maximum supported value.
TQM rings are hardware resources that require host context memory
managed by the driver. The driver supports up to 9 TQM rings and
the number of rings to use is requested by firmware during run-time.
Cap this number to the maximum supported to prevent accessing beyond
the array. Future firmware may request more than 9 TQM rings. Define
macros to remove the magic number 9 from the C code.
Fixes: ac3158cb0108 ("bnxt_en: Allocate TQM ring context memory according to fw specification.") Reviewed-by: Pavan Chebbi <[email protected]> Reviewed-by: Vasundhara Volam <[email protected]> Signed-off-by: Michael Chan <[email protected]> Signed-off-by: Jakub Kicinski <[email protected]>
Vasundhara Volam [Sun, 27 Dec 2020 19:18:17 +0000 (14:18 -0500)]
bnxt_en: Fix AER recovery.
A recent change skips sending firmware messages to the firmware when
pci_channel_offline() is true during fatal AER error. To make this
complete, we need to move the re-initialization sequence to
bnxt_io_resume(), otherwise the firmware messages to re-initialize
will all be skipped. In any case, it is more correct to re-initialize
in bnxt_io_resume().
Also, fix the reverse x-mas tree format when defining variables
in bnxt_io_slot_reset().
Fixes: b340dc680ed4 ("bnxt_en: Avoid sending firmware messages when AER error is detected.") Reviewed-by: Edwin Peer <[email protected]> Signed-off-by: Vasundhara Volam <[email protected]> Signed-off-by: Michael Chan <[email protected]> Signed-off-by: Jakub Kicinski <[email protected]>
Jakub Kicinski [Mon, 28 Dec 2020 22:04:03 +0000 (14:04 -0800)]
Merge branch '1GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/net-queue
Tony Nguyen says:
====================
Intel Wired LAN Driver Updates 2020-12-23
Commit e086ba2fccda ("e1000e: disable s0ix entry and exit flows for ME
systems") disabled S0ix flows for systems that have various incarnations of
the i219-LM ethernet controller. This was done because of some regressions
caused by an earlier commit 632fbd5eb5b0e ("e1000e: fix S0ix flows for
cable connected case") with i219-LM controller.
Per discussion with Intel architecture team this direction should be
changed and allow S0ix flows to be used by default. This patch series
includes directional changes for their conclusions in
https://lkml.org/lkml/2020/12/13/15.
* '1GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/net-queue:
e1000e: Export S0ix flags to ethtool
Revert "e1000e: disable s0ix entry and exit flows for ME systems"
e1000e: bump up timeout to wait when ME un-configures ULP mode
e1000e: Only run S0ix flows if shutdown succeeded
====================
userspace programs provide arbitrarily high values of 'len' in sendmsg():
this is causing integer overflow of 'amount'. Cap forward allocation to 1
megabyte: higher values are not really useful.
Yunjian Wang [Fri, 25 Dec 2020 02:52:16 +0000 (10:52 +0800)]
tun: fix return value when the number of iovs exceeds MAX_SKB_FRAGS
Currently the tun_napi_alloc_frags() function returns -ENOMEM when the
number of iovs exceeds MAX_SKB_FRAGS + 1. However this is inappropriate,
we should use -EMSGSIZE instead of -ENOMEM.
The following distinctions are matters:
1. the caller need to drop the bad packet when -EMSGSIZE is returned,
which means meeting a persistent failure.
2. the caller can try again when -ENOMEM is returned, which means
meeting a transient failure.
net: ethernet: ti: cpts: fix ethtool output when no ptp_clock registered
The CPTS driver registers PTP PHC clock when first netif is going up and
unregister it when all netif are down. Now ethtool will show:
- PTP PHC clock index 0 after boot until first netif is up;
- the last assigned PTP PHC clock index even if PTP PHC clock is not
registered any more after all netifs are down.
This patch ensures that -1 is returned by ethtool when PTP PHC clock is not
registered any more.
Linus Torvalds [Mon, 28 Dec 2020 21:32:16 +0000 (13:32 -0800)]
Merge tag 'for-5.11/dm-fix' of git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm
Pull device mapper fix from Mike Snitzer:
"Revert WQ_SYSFS change that broke reencryption (and all other
functionality that requires reloading a dm-crypt DM table)"
* tag 'for-5.11/dm-fix' of git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm:
Revert "dm crypt: export sysfs of kcryptd workqueue"
====================
net-sysfs: fix race conditions in the xps code
This series fixes race conditions in the xps code, where out of bound
accesses can occur when dev->num_tc is updated, triggering oops. The
root cause is linked to locking issues. An explanation is given in each
of the commit logs.
We had a discussion on the v1 of this series about using the xps_map
mutex instead of the rtnl lock. While that seemed a better compromise,
v2 showed the added complexity wasn't best for fixes. So we decided to
go back to v1 and use the rtnl lock.
Because of this, the only differences between v1 and v3 are improvements
in the commit messages.
====================
Antoine Tenart [Wed, 23 Dec 2020 21:23:23 +0000 (22:23 +0100)]
net-sysfs: take the rtnl lock when accessing xps_rxqs_map and num_tc
Accesses to dev->xps_rxqs_map (when using dev->num_tc) should be
protected by the rtnl lock, like we do for netif_set_xps_queue. I didn't
see an actual bug being triggered, but let's be safe here and take the
rtnl lock while accessing the map in sysfs.
Fixes: 8af2c06ff4b1 ("net-sysfs: Add interface for Rx queue(s) map per Tx queue") Signed-off-by: Antoine Tenart <[email protected]> Reviewed-by: Alexander Duyck <[email protected]> Signed-off-by: Jakub Kicinski <[email protected]>
Antoine Tenart [Wed, 23 Dec 2020 21:23:22 +0000 (22:23 +0100)]
net-sysfs: take the rtnl lock when storing xps_rxqs
Two race conditions can be triggered when storing xps rxqs, resulting in
various oops and invalid memory accesses:
1. Calling netdev_set_num_tc while netif_set_xps_queue:
- netif_set_xps_queue uses dev->tc_num as one of the parameters to
compute the size of new_dev_maps when allocating it. dev->tc_num is
also used to access the map, and the compiler may generate code to
retrieve this field multiple times in the function.
- netdev_set_num_tc sets dev->tc_num.
If new_dev_maps is allocated using dev->tc_num and then dev->tc_num
is set to a higher value through netdev_set_num_tc, later accesses to
new_dev_maps in netif_set_xps_queue could lead to accessing memory
outside of new_dev_maps; triggering an oops.
2. Calling netif_set_xps_queue while netdev_set_num_tc is running:
2.1. netdev_set_num_tc starts by resetting the xps queues,
dev->tc_num isn't updated yet.
2.2. netif_set_xps_queue is called, setting up the map with the
*old* dev->num_tc.
2.3. netdev_set_num_tc updates dev->tc_num.
2.4. Later accesses to the map lead to out of bound accesses and
oops.
A similar issue can be found with netdev_reset_tc.
One way of triggering this is to set an iface up (for which the driver
uses netdev_set_num_tc in the open path, such as bnx2x) and writing to
xps_rxqs in a concurrent thread. With the right timing an oops is
triggered.
Both issues have the same fix: netif_set_xps_queue, netdev_set_num_tc
and netdev_reset_tc should be mutually exclusive. We do that by taking
the rtnl lock in xps_rxqs_store.
Fixes: 8af2c06ff4b1 ("net-sysfs: Add interface for Rx queue(s) map per Tx queue") Signed-off-by: Antoine Tenart <[email protected]> Reviewed-by: Alexander Duyck <[email protected]> Signed-off-by: Jakub Kicinski <[email protected]>
Antoine Tenart [Wed, 23 Dec 2020 21:23:21 +0000 (22:23 +0100)]
net-sysfs: take the rtnl lock when accessing xps_cpus_map and num_tc
Accesses to dev->xps_cpus_map (when using dev->num_tc) should be
protected by the rtnl lock, like we do for netif_set_xps_queue. I didn't
see an actual bug being triggered, but let's be safe here and take the
rtnl lock while accessing the map in sysfs.
Fixes: 184c449f91fe ("net: Add support for XPS with QoS via traffic classes") Signed-off-by: Antoine Tenart <[email protected]> Reviewed-by: Alexander Duyck <[email protected]> Signed-off-by: Jakub Kicinski <[email protected]>
Antoine Tenart [Wed, 23 Dec 2020 21:23:20 +0000 (22:23 +0100)]
net-sysfs: take the rtnl lock when storing xps_cpus
Two race conditions can be triggered when storing xps cpus, resulting in
various oops and invalid memory accesses:
1. Calling netdev_set_num_tc while netif_set_xps_queue:
- netif_set_xps_queue uses dev->tc_num as one of the parameters to
compute the size of new_dev_maps when allocating it. dev->tc_num is
also used to access the map, and the compiler may generate code to
retrieve this field multiple times in the function.
- netdev_set_num_tc sets dev->tc_num.
If new_dev_maps is allocated using dev->tc_num and then dev->tc_num
is set to a higher value through netdev_set_num_tc, later accesses to
new_dev_maps in netif_set_xps_queue could lead to accessing memory
outside of new_dev_maps; triggering an oops.
2. Calling netif_set_xps_queue while netdev_set_num_tc is running:
2.1. netdev_set_num_tc starts by resetting the xps queues,
dev->tc_num isn't updated yet.
2.2. netif_set_xps_queue is called, setting up the map with the
*old* dev->num_tc.
2.3. netdev_set_num_tc updates dev->tc_num.
2.4. Later accesses to the map lead to out of bound accesses and
oops.
A similar issue can be found with netdev_reset_tc.
One way of triggering this is to set an iface up (for which the driver
uses netdev_set_num_tc in the open path, such as bnx2x) and writing to
xps_cpus in a concurrent thread. With the right timing an oops is
triggered.
Both issues have the same fix: netif_set_xps_queue, netdev_set_num_tc
and netdev_reset_tc should be mutually exclusive. We do that by taking
the rtnl lock in xps_cpus_store.
Fixes: 184c449f91fe ("net: Add support for XPS with QoS via traffic classes") Signed-off-by: Antoine Tenart <[email protected]> Reviewed-by: Alexander Duyck <[email protected]> Signed-off-by: Jakub Kicinski <[email protected]>
Roland Dreier [Thu, 24 Dec 2020 03:21:16 +0000 (19:21 -0800)]
CDC-NCM: remove "connected" log message
The cdc_ncm driver passes network connection notifications up to
usbnet_link_change(), which is the right place for any logging.
Remove the netdev_info() duplicating this from the driver itself.
This stops devices such as my "TRENDnet USB 10/100/1G/2.5G LAN"
(ID 20f4:e02b) adapter from spamming the kernel log with
WQ_SYSFS breaks the ability to reload a DM table due to sysfs kobject
collision (due to active and inactive table). Given lack of
demonstrated need for exposing this workqueue via sysfs: revert
exposing it.
Ilya Dryomov [Tue, 15 Dec 2020 15:49:07 +0000 (16:49 +0100)]
libceph: align session_key and con_secret to 16 bytes
crypto_shash_setkey() and crypto_aead_setkey() will do a (small)
GFP_ATOMIC allocation to align the key if it isn't suitably aligned.
It's not a big deal, but at the same time easy to avoid.
The actual alignment requirement is dynamic, queryable with
crypto_shash_alignmask() and crypto_aead_alignmask(), but shouldn't
be stricter than 16 bytes for our algorithms.
Ilya Dryomov [Tue, 15 Dec 2020 15:40:59 +0000 (16:40 +0100)]
libceph: fix auth_signature buffer allocation in secure mode
auth_signature frame is 68 bytes in plain mode and 96 bytes in
secure mode but we are requesting 68 bytes in both modes. By luck,
this doesn't actually result in any invalid memory accesses because
the allocation is satisfied out of kmalloc-96 slab and so exactly
96 bytes are allocated, but KASAN rightfully complains.
Ilya Dryomov [Wed, 16 Dec 2020 16:19:58 +0000 (17:19 +0100)]
ceph: reencode gid_list when reconnecting
On reconnect, cap and dentry releases are dropped and the fields
that follow must be reencoded into the freed space. Currently these
are timestamp and gid_list, but gid_list isn't reencoded. This
results in
failed to decode message of type 24 v4: End of buffer
errors on the MDS.
While at it, make a change to encode gid_list unconditionally,
without regard to what head/which version was used as a result
of checking whether CEPH_FEATURE_FS_BTIME is supported or not.
Linus Torvalds [Mon, 28 Dec 2020 19:16:38 +0000 (11:16 -0800)]
Merge branch 'for-5.11' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup
Pull cgroup updates from Tejun Heo:
"These three patches were scheduled for the merge window but I forgot
to send them out. Sorry about that.
None of them are significant and they fit well in a fix pull request
too - two are cosmetic and one fixes a memory leak in the mount option
parsing path"
* 'for-5.11' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup:
cgroup: Fix memory leak when parsing multiple source parameters
cgroup/cgroup.c: replace 'of->kn->priv' with of_cft()
kernel: cgroup: Mundane spelling fixes throughout the file
Jerome Brunet [Mon, 21 Dec 2020 17:35:28 +0000 (18:35 +0100)]
usb: gadget: f_uac2: reset wMaxPacketSize
With commit 913e4a90b6f9 ("usb: gadget: f_uac2: finalize wMaxPacketSize according to bandwidth")
wMaxPacketSize is computed dynamically but the value is never reset.
Because of this, the actual maximum packet size can only decrease each time
the audio gadget is instantiated.
Reset the endpoint maximum packet size and mark wMaxPacketSize as dynamic
to solve the problem.
First of all the commit e0082698b689 ("usb: dwc3: ulpi: conditionally
resume ULPI PHY") introduced the Suspend USB2.0 HS/FS/LS PHY regression,
as by design of the fix any attempt to read/write from/to the PHY control
registers will completely disable the PHY suspension, which consequently
will increase the USB bus power consumption. Secondly the fix won't work
well for the very first attempt of the ULPI PHY control registers IO,
because after disabling the USB2.0 PHY suspension functionality it will
still take some time for the bus to resume from the sleep state if one has
been reached before it. So the very first PHY register read/write
operation will take more time than the busy-loop provides and the IO
timeout error might be returned anyway.
Here we suggest to fix the denoted problems in the following way. First of
all let's not disable the Suspend USB2.0 HS/FS/LS PHY functionality so to
make the controller and the USB2.0 bus more power efficient. Secondly
instead of that we'll extend the PHY IO op wait procedure with 1 - 1.2 ms
sleep if the PHY suspension is enabled (1ms should be enough as by LPM
specification it is at most how long it takes for the USB2.0 bus to resume
from L1 (Sleep) state). Finally in case if the USB2.0 PHY suspension
functionality has been disabled on the DWC USB3 controller setup procedure
we'll compensate the USB bus resume process latency by extending the
busy-loop attempts counter.
Serge Semin [Thu, 10 Dec 2020 08:50:07 +0000 (11:50 +0300)]
usb: dwc3: ulpi: Replace CPU-based busyloop with Protocol-based one
Originally the procedure of the ULPI transaction finish detection has been
developed as a simple busy-loop with just decrementing counter and no
delays. It's wrong since on different systems the loop will take a
different time to complete. So if the system bus and CPU are fast enough
to overtake the ULPI bus and the companion PHY reaction, then we'll get to
take a false timeout error. Fix this by converting the busy-loop procedure
to take the standard bus speed, address value and the registers access
mode into account for the busy-loop delay calculation.
Here is the way the fix works. It's known that the ULPI bus is clocked
with 60MHz signal. In accordance with [1] the ULPI bus protocol is created
so to spend 5 and 6 clock periods for immediate register write and read
operations respectively, and 6 and 7 clock periods - for the extended
register writes and reads. Based on that we can easily pre-calculate the
time which will be needed for the controller to perform a requested IO
operation. Note we'll still preserve the attempts counter in case if the
DWC USB3 controller has got some internals delays.
[1] UTMI+ Low Pin Interface (ULPI) Specification, Revision 1.1,
October 20, 2004, pp. 30 - 36.
Serge Semin [Thu, 10 Dec 2020 08:50:06 +0000 (11:50 +0300)]
usb: dwc3: ulpi: Use VStsDone to detect PHY regs access completion
In accordance with [1] the DWC_usb3 core sets the GUSB2PHYACCn.VStsDone
bit when the PHY vendor control access is done and clears it when the
application initiates a new transaction. The doc doesn't say anything
about the GUSB2PHYACCn.VStsBsy flag serving for the same purpose. Moreover
we've discovered that the VStsBsy flag can be cleared before the VStsDone
bit. So using the former as a signal of the PHY control registers
completion might be dangerous. Let's have the VStsDone flag utilized
instead then.
[1] Synopsys DesignWare Cores SuperSpeed USB 3.0 xHCI Host Controller
Databook, 2.70a, December 2013, p.388
Johan Hovold [Mon, 14 Dec 2020 10:30:53 +0000 (11:30 +0100)]
USB: yurex: fix control-URB timeout handling
Make sure to always cancel the control URB in write() so that it can be
reused after a timeout or spurious CMD_ACK.
Currently any further write requests after a timeout would fail after
triggering a WARN() in usb_submit_urb() when attempting to submit the
already active URB.
Yu Kuai [Tue, 17 Nov 2020 01:14:30 +0000 (09:14 +0800)]
usb: chipidea: ci_hdrc_imx: add missing put_device() call in usbmisc_get_init_data()
if of_find_device_by_node() succeed, usbmisc_get_init_data() doesn't have
a corresponding put_device(). Thus add put_device() to fix the exception
handling for this function implementation.
Manish Narani [Tue, 17 Nov 2020 07:13:35 +0000 (12:43 +0530)]
usb: gadget: u_ether: Fix MTU size mismatch with RX packet size
Fix the MTU size issue with RX packet size as the host sends the packet
with extra bytes containing ethernet header. This causes failure when
user sets the MTU size to the maximum i.e. 15412. In this case the
ethernet packet received will be of length 15412 plus the ethernet header
length. This patch fixes the issue where there is a check that RX packet
length must not be more than max packet length.
usb: gadget: Fix spinlock lockup on usb_function_deactivate
There is a spinlock lockup as part of composite_disconnect
when it tries to acquire cdev->lock as part of usb_gadget_deactivate.
This is because the usb_gadget_deactivate is called from
usb_function_deactivate with the same spinlock held.
This would result in the below call stack and leads to stall.
Zqiang [Thu, 10 Dec 2020 02:01:48 +0000 (10:01 +0800)]
usb: gadget: function: printer: Fix a memory leak for interface descriptor
When printer driver is loaded, the printer_func_bind function is called, in
this function, the interface descriptor be allocated memory, if after that,
the error occurred, the interface descriptor memory need to be free.
USB: xhci: fix U1/U2 handling for hardware with XHCI_INTEL_HOST quirk set
The commit 0472bf06c6fd ("xhci: Prevent U1/U2 link pm states if exit
latency is too long") was constraining the xhci code not to allow U1/U2
sleep states if the latency to wake up from the U-states reached the
service interval of an periodic endpoint. This fix was not taking into
account that in case the quirk XHCI_INTEL_HOST is set, the wakeup time
will be calculated and configured differently.
It checks for u1_params.mel/u2_params.mel as a limit. But the code could
decide to write another MEL into the hardware. This leads to broken
cases where not enough bandwidth is available for other devices:
usb 1-2: can't set config #1, error -28
This patch is fixing that case by checking for timeout_ns after the
wakeup time was calculated depending on the quirks.
usb: typec: intel_pmc_mux: Configure HPD first for HPD+IRQ request
Warm reboot scenarios some times type C Mux driver gets Mux configuration
request as HPD=1,IRQ=1. In that scenario typeC Mux driver need to configure
Mux as follows as per IOM requirement:
(1). Confgiure Mux HPD = 1, IRQ = 0
(2). Configure Mux with HPD = 1, IRQ = 1
IOM expects TypeC Mux configuration as follows:
(1). HPD=1, IRQ=0
(2). HPD=1, IRQ=1
if IOM gets mux config request (2) without configuring (1), it will ignore
the request. The impact of this is there is no DP_alt mode display.
Tetsuo Handa [Sat, 19 Dec 2020 15:25:53 +0000 (00:25 +0900)]
USB: cdc-wdm: Fix use after free in service_outstanding_interrupt().
syzbot is reporting UAF at usb_submit_urb() [1], for
service_outstanding_interrupt() is not checking WDM_DISCONNECTING
before calling usb_submit_urb(). Close the race by doing same checks
wdm_read() does upon retry.
Also, while wdm_read() checks WDM_DISCONNECTING with desc->rlock held,
service_interrupt_work() does not hold desc->rlock. Thus, it is possible
that usb_submit_urb() is called from service_outstanding_interrupt() from
service_interrupt_work() after WDM_DISCONNECTING was set and kill_urbs()
from wdm_disconnect() completed. Thus, move kill_urbs() in
wdm_disconnect() to after cancel_work_sync() (which makes sure that
service_interrupt_work() is no longer running) completed.
Although it seems to be safe to dereference desc->intf->dev in
service_outstanding_interrupt() even if WDM_DISCONNECTING was already set
because desc->rlock or cancel_work_sync() prevents wdm_disconnect() from
reaching list_del() before service_outstanding_interrupt() completes,
let's not emit error message if WDM_DISCONNECTING is set by
wdm_disconnect() while usb_submit_urb() is in progress.
staging: mt7621-dma: Fix a resource leak in an error handling path
If an error occurs after calling 'mtk_hsdma_init()', it must be undone by
a corresponding call to 'mtk_hsdma_uninit()' as already done in the
remove function.
Arnd Bergmann [Mon, 28 Dec 2020 12:03:02 +0000 (14:03 +0200)]
interconnect: qcom: fix rpmh link failures
When CONFIG_COMPILE_TEST is set, it is possible to build some
of the interconnect drivers into the kernel while their dependencies
are loadable modules, which is bad:
arm-linux-gnueabi-ld: drivers/interconnect/qcom/bcm-voter.o: in function `qcom_icc_bcm_voter_commit':
(.text+0x1f8): undefined reference to `rpmh_invalidate'
arm-linux-gnueabi-ld: (.text+0x20c): undefined reference to `rpmh_write_batch'
arm-linux-gnueabi-ld: (.text+0x2b0): undefined reference to `rpmh_write_batch'
arm-linux-gnueabi-ld: (.text+0x2e8): undefined reference to `rpmh_write_batch'
arm-linux-gnueabi-ld: drivers/interconnect/qcom/icc-rpmh.o: in function `qcom_icc_bcm_init':
(.text+0x2ac): undefined reference to `cmd_db_read_addr'
arm-linux-gnueabi-ld: (.text+0x2c8): undefined reference to `cmd_db_read_aux_data'
The exact dependencies are a bit complicated, so split them out into a
hidden Kconfig symbol that all drivers can in turn depend on to get it
right.
projects / linux.git / log