aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2018-02-08selftests/ftrace: Add some missing glob checksSteven Rostedt (VMware)1-0/+6
Al Viro discovered a bug in the glob ftrace filtering code where "*a*b" is treated the same as "a*b", and functions that would be selected by "*a*b" but not "a*b" are not selected with "*a*b". Add tests for patterns "*a*b" and "a*b*" to the glob selftest. Link: http://lkml.kernel.org/r/[email protected] Cc: Shuah Khan <[email protected]> Acked-by: Masami Hiramatsu <[email protected]> Signed-off-by: Steven Rostedt (VMware) <[email protected]>
2018-02-08selftests/ftrace: Have reset_ftrace_filter handle multiple instancesSteven Rostedt (VMware)1-0/+3
If a probe is attached to a static function that is in multiple files with the same name, removing it by name will remove all instances: # grep jump_label_unlock set_ftrace_filter jump_label_unlock:traceoff:unlimited jump_label_unlock:traceoff:unlimited # echo '!jump_label_unlock:traceoff' >> set_ftrace_filter # grep jump_label_unlock set_ftrace_filter # But the loop in reset_ftrace_filter will try to remove multiple instances multiple times. If this happens the second time will error and cause the test to fail. At each iteration of the loop, check to see if the probe being removed still exists. Cc: Shuah Khan <[email protected]> Signed-off-by: Steven Rostedt (VMware) <[email protected]>
2018-02-08selftests/ftrace: Have reset_ftrace_filter handle modulesSteven Rostedt (VMware)1-3/+4
If a function probe in set_ftrace_filter belongs to a module, it will contain the module name. Like: wmi_query_block [wmi]:traceoff:unlimited But writing: '!wmi_query_block [wmi]:traceoff' > set_ftrace_filter will cause an error. We still need to write: '!wmi_query_block:traceoff' > set_ftrace_filter Cc: Shuah Khan <[email protected]> Signed-off-by: Steven Rostedt (VMware) <[email protected]>
2018-02-08tracing: Fix parsing of globs with a wildcard at the beginningSteven Rostedt (VMware)1-5/+4
Al Viro reported: For substring - sure, but what about something like "*a*b" and "a*b"? AFAICS, filter_parse_regex() ends up with identical results in both cases - MATCH_GLOB and *search = "a*b". And no way for the caller to tell one from another. Testing this with the following: # cd /sys/kernel/tracing # echo '*raw*lock' > set_ftrace_filter bash: echo: write error: Invalid argument With this patch: # echo '*raw*lock' > set_ftrace_filter # cat set_ftrace_filter _raw_read_trylock _raw_write_trylock _raw_read_unlock _raw_spin_unlock _raw_write_unlock _raw_spin_trylock _raw_spin_lock _raw_write_lock _raw_read_lock Al recommended not setting the search buffer to skip the first '*' unless we know we are not using MATCH_GLOB. This implements his suggested logic. Link: http://lkml.kernel.org/r/[email protected] Cc: [email protected] Fixes: 60f1d5e3bac44 ("ftrace: Support full glob matching") Reviewed-by: Masami Hiramatsu <[email protected]> Reported-by: Al Viro <[email protected]> Suggsted-by: Al Viro <[email protected]> Signed-off-by: Steven Rostedt (VMware) <[email protected]>
2018-02-08ftrace: Remove incorrect setting of glob search fieldSteven Rostedt (VMware)1-1/+0
__unregister_ftrace_function_probe() will incorrectly parse the glob filter because it resets the search variable that was setup by filter_parse_regex(). Al Viro reported this: After that call of filter_parse_regex() we could have func_g.search not equal to glob only if glob started with '!' or '*'. In the former case we would've buggered off with -EINVAL (not = 1). In the latter we would've set func_g.search equal to glob + 1, calculated the length of that thing in func_g.len and proceeded to reset func_g.search back to glob. Suppose the glob is e.g. *foo*. We end up with func_g.type = MATCH_MIDDLE_ONLY; func_g.len = 3; func_g.search = "*foo"; Feeding that to ftrace_match_record() will not do anything sane - we will be looking for names containing "*foo" (->len is ignored for that one). Link: http://lkml.kernel.org/r/[email protected] Cc: [email protected] Fixes: 3ba009297149f ("ftrace: Introduce ftrace_glob structure") Reviewed-by: Dmitry Safonov <[email protected]> Reviewed-by: Masami Hiramatsu <[email protected]> Reported-by: Al Viro <[email protected]> Signed-off-by: Steven Rostedt (VMware) <[email protected]>
2018-02-08Merge branch ↵David S. Miller9-23/+53
'nfp-fix-disabling-TC-offloads-in-flower-max-TSO-segs-and-module-version' Jakub Kicinski says: ==================== nfp: fix disabling TC offloads in flower, max TSO segs and module version This set corrects the way nfp deals with the NETIF_F_HW_TC flag. It has slipped the review that flower offload does not currently refuse disabling this flag when filter offload is active. nfp's flower offload does not actually keep track of how many filters for each port are offloaded. The accounting of the number of filters is added to the nfp core structures, and BPF moved to use these structures as well. If users are allowed to disable TC offloads while filters are active, not only is it incorrect behaviour, but actually the NFP will never be told to remove the flows, leading to use-after-free when stats arrive. Fourth patch makes sure we declare the max number of TSO segments. FW should drop longer packets cleanly (otherwise this would be a security problem for untrusted VFs) but dropping longer TSO frames is not nice and driver should prevent them from being generated. Last small addition populates MODULE_VERSION with kernel version. ==================== Signed-off-by: David S. Miller <[email protected]>
2018-02-08nfp: populate MODULE_VERSIONJakub Kicinski1-0/+1
DKMS and similar out-of-tree module replacement services use module version to make sure the out-of-tree software is not older than the module shipped with the kernel. We use the kernel version in ethtool -i output, put it into MODULE_VERSION as well. Reported-by: Jan Gutter <[email protected]> Signed-off-by: Jakub Kicinski <[email protected]> Reviewed-by: Dirk van der Merwe <[email protected]> Reviewed-by: Simon Horman <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2018-02-08nfp: limit the number of TSO segmentsJakub Kicinski2-1/+6
Most FWs limit the number of TSO segments a frame can produce to 64. This is for fairness and efficiency (of FW datapath) reasons. If a frame with larger number of segments is submitted the FW will drop it. Signed-off-by: Jakub Kicinski <[email protected]> Reviewed-by: Simon Horman <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2018-02-08nfp: forbid disabling hw-tc-offload on representors while offload activeJakub Kicinski7-21/+33
All netdevs which can accept TC offloads must implement .ndo_set_features(). nfp_reprs currently do not do that, which means hw-tc-offload can be turned on and off even when offloads are active. Whether the offloads are active is really a question to nfp_ports, so remove the per-app tc_busy callback indirection thing, and simply count the number of offloaded items in nfp_port structure. Fixes: 8a2768732a4d ("nfp: provide infrastructure for offloading flower based TC filters") Signed-off-by: Jakub Kicinski <[email protected]> Reviewed-by: Simon Horman <[email protected]> Tested-by: Pieter Jansen van Vuuren <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2018-02-08nfp: don't advertise hw-tc-offload on non-port netdevsJakub Kicinski1-1/+1
nfp_port is a structure which represents an ASIC port, both PCIe vNIC (on a PF or a VF) or the external MAC port. vNIC netdev (struct nfp_net) and pure representor netdev (struct nfp_repr) both have a pointer to this structure. nfp_reprs always have a port associated. nfp_nets, however, only represent a device port in legacy mode, where they are considered the MAC port. In switchdev mode they are just the CPU's side of the PCIe link. By definition TC offloads only apply to device ports. Don't set the flag on vNICs without a port (i.e. in switchdev mode). Signed-off-by: Jakub Kicinski <[email protected]> Reviewed-by: Simon Horman <[email protected]> Tested-by: Pieter Jansen van Vuuren <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2018-02-08nfp: bpf: require ETH tableJakub Kicinski1-0/+12
Upcoming changes will require all netdevs supporting TC offloads to have a full struct nfp_port. Require those for BPF offload. The operation without management FW reporting information about Ethernet ports is something we only support for very old and very basic NIC firmwares anyway. Signed-off-by: Jakub Kicinski <[email protected]> Reviewed-by: Simon Horman <[email protected]> Tested-by: Pieter Jansen van Vuuren <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2018-02-08MIPS: CPC: Map registers using DT in mips_cpc_default_phys_base()Paul Burton1-0/+13
Reading mips_cpc_base value from the DT allows each platform to define it according to its needs. This is especially convenient for MIPS_GENERIC kernel where this kind of information should be determined in runtime. Use mti,mips-cpc compatible string with just a reg property to specify the register location for your platform. Signed-off-by: Paul Burton <[email protected]> Signed-off-by: Miodrag Dinic <[email protected]> Signed-off-by: Aleksandar Markovic <[email protected]> Cc: [email protected] Cc: Ralf Baechle <[email protected]> Patchwork: https://patchwork.linux-mips.org/patch/18513/ Signed-off-by: James Hogan <[email protected]>
2018-02-08dt-bindings: Document mti,mips-cpc bindingPaul Burton2-0/+9
Document a binding for the MIPS Cluster Power Controller (CPC) that allows the device tree to specify where the CPC registers are located. Signed-off-by: Paul Burton <[email protected]> Signed-off-by: Aleksandar Markovic <[email protected]> Reviewed-by: Rob Herring <[email protected]> Cc: [email protected] Cc: [email protected] Patchwork: https://patchwork.linux-mips.org/patch/18512/ Signed-off-by: James Hogan <[email protected]>
2018-02-08powerpc/mm/radix: Split linear mapping on hot-unplugBalbir Singh1-21/+74
This patch splits the linear mapping if the hot-unplug range is smaller than the mapping size. The code detects if the mapping needs to be split into a smaller size and if so, uses the stop machine infrastructure to clear the existing mapping and then remap the remaining range using a smaller page size. The code will skip any region of the mapping that overlaps with kernel text and warn about it once. We don't want to remove a mapping where the kernel text and the LMB we intend to remove overlap in the same TLB mapping as it may affect the currently executing code. I've tested these changes under a kvm guest with 2 vcpus, from a split mapping point of view, some of the caveats mentioned above applied to the testing I did. Fixes: 4b5d62ca17a1 ("powerpc/mm: add radix__remove_section_mapping()") Signed-off-by: Balbir Singh <[email protected]> [mpe: Tweak change log to match updated behaviour] Signed-off-by: Michael Ellerman <[email protected]>
2018-02-08powerpc/64s/radix: Boot-time NULL pointer protection using a guard-PIDNicholas Piggin1-1/+20
This change restores and formalises the behaviour that access to NULL or other user addresses by the kernel during boot should fault rather than succeed and modify memory. This was inadvertently broken when fixing another bug, because it was previously not well defined and only worked by chance. powerpc/64s/radix uses high address bits to select an address space "quadrant", which determines which PID and LPID are used to translate the rest of the address (effective PID, effective LPID). The kernel mapping at 0xC... selects quadrant 3, which uses PID=0 and LPID=0. So the kernel page tables are installed in the PID 0 process table entry. An address at 0x0... selects quadrant 0, which uses PID=PIDR for translating the rest of the address (that is, it uses the value of the PIDR register as the effective PID). If PIDR=0, then the translation is performed with the PID 0 process table entry page tables. This is the kernel mapping, so we effectively get another copy of the kernel address space at 0. A NULL pointer access will access physical memory address 0. To prevent duplicating the kernel address space in quadrant 0, this patch allocates a guard PID containing no translations, and initializes PIDR with this during boot, before the MMU is switched on. Any kernel access to quadrant 0 will use this guard PID for translation and find no valid mappings, and therefore fault. After boot, this PID will be switchd away to user context PIDs, but those contain user mappings (and usually NULL pointer protection) rather than kernel mapping, which is much safer (and by design). It may be in future this is tightened further, which the guard PID could be used for. Commit 371b8044 ("powerpc/64s: Initialize ISAv3 MMU registers before setting partition table"), introduced this problem because it zeroes PIDR at boot. However previously the value was inherited from firmware or kexec, which is not robust and can be zero (e.g., mambo). Fixes: 371b80447ff3 ("powerpc/64s: Initialize ISAv3 MMU registers before setting partition table") Cc: [email protected] # v4.15+ Reported-by: Florian Weimer <[email protected]> Tested-by: Mauricio Faria de Oliveira <[email protected]> Signed-off-by: Nicholas Piggin <[email protected]> Signed-off-by: Michael Ellerman <[email protected]>
2018-02-08ocxl: fix signed comparison with less than zeroColin Ian King1-1/+1
Currently the comparison of used < 0 is always false because uses is a size_t. Fix this by making used a ssize_t type. Detected by Coccinelle: drivers/misc/ocxl/file.c:320:6-10: WARNING: Unsigned expression compared with zero: used < 0 Fixes: 5ef3166e8a32 ("ocxl: Driver code for 'generic' opencapi devices") Signed-off-by: Colin Ian King <[email protected]> Acked-by: Andrew Donnellan <[email protected]> Acked-by: Frederic Barrat <[email protected]> Signed-off-by: Michael Ellerman <[email protected]>
2018-02-08powerpc/64s: Fix may_hard_irq_enable() for PMI soft maskingNicholas Piggin3-4/+16
The soft IRQ masking code has to hard-disable interrupts in cases where the exception is not cleared by the masked handler. External interrupts used this approach for soft masking. Now recently PMU interrupts do the same thing. The soft IRQ masking code additionally allowed for interrupt handlers to hard-enable interrupts after soft-disabling them. The idea is to allow PMU interrupts through to profile interrupt handlers. So when interrupts are being replayed when there is a pending interrupt that requires hard-disabling, there is a test to prevent those handlers from hard-enabling them if there is a pending external interrupt. may_hard_irq_enable() handles this. After f442d00480 ("powerpc/64s: Add support to mask perf interrupts and replay them"), may_hard_irq_enable() could prematurely enable MSR[EE] when a PMU exception exists, which would result in the interrupt firing again while masked, and MSR[EE] being disabled again. I haven't seen that this could cause a serious problem, but it's more consistent to handle these soft-masked interrupts in the same way. So introduce a define for all types of interrupts that require MSR[EE] masking in their soft-disable handlers, and use that in may_hard_irq_enable(). Fixes: f442d004806e ("powerpc/64s: Add support to mask perf interrupts and replay them") Signed-off-by: Nicholas Piggin <[email protected]> Reviewed-by: Madhavan Srinivasan <[email protected]> Signed-off-by: Michael Ellerman <[email protected]>
2018-02-08powerpc/64s: Fix MASKABLE_RELON_EXCEPTION_HV_OOL macroMadhavan Srinivasan1-1/+1
Commit f14e953b191f ("powerpc/64s: Add support to take additional parameter in MASKABLE_* macro") messed up MASKABLE_RELON_EXCEPTION_HV_OOL macro by adding the wrong SOFTEN test which caused guest kernel crash at boot. Patch to fix the macro to use SOFTEN_TEST_HV instead of SOFTEN_NOTEST_HV. Fixes: f14e953b191f ("powerpc/64s: Add support to take additional parameter in MASKABLE_* macro") Reported-by: Alexey Kardashevskiy <[email protected]> Fix-Suggested-by: Michael Ellerman <[email protected]> Signed-off-by: Madhavan Srinivasan <[email protected]> Tested-by: Alexey Kardashevskiy <[email protected]> Signed-off-by: Michael Ellerman <[email protected]>
2018-02-08powerpc/numa: Invalidate numa_cpu_lookup_table on cpu removeNathan Fontenot3-5/+7
When DLPAR removing a CPU, the unmapping of the cpu from a node in unmap_cpu_from_node() should also invalidate the CPUs entry in the numa_cpu_lookup_table. There is not a guarantee that on a subsequent DLPAR add of the CPU the associativity will be the same and thus could be in a different node. Invalidating the entry in the numa_cpu_lookup_table causes the associativity to be read from the device tree at the time of the add. The current behavior of not invalidating the CPUs entry in the numa_cpu_lookup_table can result in scenarios where the the topology layout of CPUs in the partition does not match the device tree or the topology reported by the HMC. This bug looks like it was introduced in 2004 in the commit titled "ppc64: cpu hotplug notifier for numa", which is 6b15e4e87e32 in the linux-fullhist tree. Hence tag it for all stable releases. Cc: [email protected] Signed-off-by: Nathan Fontenot <[email protected]> Reviewed-by: Tyrel Datwyler <[email protected]> Signed-off-by: Michael Ellerman <[email protected]>
2018-02-08Revert "ath10k: add sanity check to ie_len before parsing fw/board ie"Ryan Hsu1-7/+7
This reverts commit 9ed4f91628737c820af6a1815b65bc06bd31518f. The commit introduced a regression that over read the ie with the padding. - the expected IE information ath10k_pci 0000:03:00.0: found firmware features ie (1 B) ath10k_pci 0000:03:00.0: Enabling feature bit: 6 ath10k_pci 0000:03:00.0: Enabling feature bit: 7 ath10k_pci 0000:03:00.0: features ath10k_pci 0000:03:00.0: 00000000: c0 00 00 00 00 00 00 00 - the wrong IE with padding is read (0x77) ath10k_pci 0000:03:00.0: found firmware features ie (4 B) ath10k_pci 0000:03:00.0: Enabling feature bit: 6 ath10k_pci 0000:03:00.0: Enabling feature bit: 7 ath10k_pci 0000:03:00.0: Enabling feature bit: 8 ath10k_pci 0000:03:00.0: Enabling feature bit: 9 ath10k_pci 0000:03:00.0: Enabling feature bit: 10 ath10k_pci 0000:03:00.0: Enabling feature bit: 12 ath10k_pci 0000:03:00.0: Enabling feature bit: 13 ath10k_pci 0000:03:00.0: Enabling feature bit: 14 ath10k_pci 0000:03:00.0: Enabling feature bit: 16 ath10k_pci 0000:03:00.0: Enabling feature bit: 17 ath10k_pci 0000:03:00.0: Enabling feature bit: 18 ath10k_pci 0000:03:00.0: features ath10k_pci 0000:03:00.0: 00000000: c0 77 07 00 00 00 00 00 Tested-by: Mike Lothian <[email protected]> Signed-off-by: Ryan Hsu <[email protected]> Signed-off-by: Kalle Valo <[email protected]>
2018-02-08crypto: sun4i_ss_prng - convert lock to _bh in sun4i_ss_prng_generateArtem Savkov1-2/+2
Lockdep detects a possible deadlock in sun4i_ss_prng_generate() and throws an "inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage" warning. Disabling softirqs to fix this. Fixes: b8ae5c7387ad ("crypto: sun4i-ss - support the Security System PRNG") Signed-off-by: Artem Savkov <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2018-02-08crypto: sun4i_ss_prng - fix return value of sun4i_ss_prng_generateArtem Savkov1-1/+1
According to crypto/rng.h generate function should return 0 on success and < 0 on error. Fixes: b8ae5c7387ad ("crypto: sun4i-ss - support the Security System PRNG") Signed-off-by: Artem Savkov <[email protected]> Acked-by: Corentin Labbe <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2018-02-08crypto: caam - fix endless loop when DECO acquire failsHoria Geantă1-2/+6
In case DECO0 cannot be acquired - i.e. run_descriptor_deco0() fails with -ENODEV, caam_probe() enters an endless loop: run_descriptor_deco0 ret -ENODEV -> instantiate_rng -ENODEV, overwritten by -EAGAIN ret -EAGAIN -> caam_probe -EAGAIN results in endless loop It turns out the error path in instantiate_rng() is incorrect, the checks are done in the wrong order. Cc: <[email protected]> # 3.13+ Fixes: 1005bccd7a4a6 ("crypto: caam - enable instantiation of all RNG4 state handles") Reported-by: Bryan O'Donoghue <[email protected]> Suggested-by: Auer Lukas <[email protected]> Signed-off-by: Horia Geantă <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2018-02-08crypto: sha3-generic - Use __optimize to support old compilersGeert Uytterhoeven1-1/+1
With gcc-4.1.2: crypto/sha3_generic.c:39: warning: ‘__optimize__’ attribute directive ignored Use the newly introduced __optimize macro to fix this. Fixes: 83dee2ce1ae791c3 ("crypto: sha3-generic - rewrite KECCAK transform to help the compiler optimize") Signed-off-by: Geert Uytterhoeven <[email protected]> Acked-by: Ard Biesheuvel <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2018-02-08compiler-gcc.h: __nostackprotector needs gcc-4.4 and upGeert Uytterhoeven1-2/+1
Gcc versions before 4.4 do not recognize the __optimize__ compiler attribute: warning: ‘__optimize__’ attribute directive ignored Fixes: 7375ae3a0b79ea07 ("compiler-gcc.h: Introduce __nostackprotector function attribute") Signed-off-by: Geert Uytterhoeven <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2018-02-08compiler-gcc.h: Introduce __optimize function attributeGeert Uytterhoeven2-0/+8
Create a new function attribute __optimize, which allows to specify an optimization level on a per-function basis. Signed-off-by: Geert Uytterhoeven <[email protected]> Acked-by: Ard Biesheuvel <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2018-02-08crypto: sha3-generic - deal with oversize stack framesArd Biesheuvel1-100/+118
As reported by kbuild test robot, the optimized SHA3 C implementation compiles to mn10300 code that uses a disproportionate amount of stack space, i.e., crypto/sha3_generic.c: In function 'keccakf': crypto/sha3_generic.c:147:1: warning: the frame size of 1232 bytes is larger than 1024 bytes [-Wframe-larger-than=] As kindly diagnosed by Arnd, this does not only occur when building for the mn10300 architecture (which is what the report was about) but also for h8300, and builds for other 32-bit architectures show an increase in stack space utilization as well. Given that SHA3 operates on 64-bit quantities, and keeps a state matrix of 25 64-bit words, it is not surprising that 32-bit architectures with few general purpose registers are impacted the most by this, and it is therefore reasonable to implement a workaround that distinguishes between 32-bit and 64-bit architectures. Arnd figured out that taking the round calculation out of the loop, and inlining it explicitly but only on 64-bit architectures preserves most of the performance gain achieved by the rewrite, and also gets rid of the excessive use of stack space. Reported-by: kbuild test robot <[email protected]> Suggested-by: Arnd Bergmann <[email protected]> Signed-off-by: Ard Biesheuvel <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2018-02-08crypto: talitos - fix Kernel Oops on hashing an empty fileLEROY Christophe1-0/+4
Performing the hash of an empty file leads to a kernel Oops [ 44.504600] Unable to handle kernel paging request for data at address 0x0000000c [ 44.512819] Faulting instruction address: 0xc02d2be8 [ 44.524088] Oops: Kernel access of bad area, sig: 11 [#1] [ 44.529171] BE PREEMPT CMPC885 [ 44.532232] CPU: 0 PID: 491 Comm: md5sum Not tainted 4.15.0-rc8-00211-g3a968610b6ea #81 [ 44.540814] NIP: c02d2be8 LR: c02d2984 CTR: 00000000 [ 44.545812] REGS: c6813c90 TRAP: 0300 Not tainted (4.15.0-rc8-00211-g3a968610b6ea) [ 44.554223] MSR: 00009032 <EE,ME,IR,DR,RI> CR: 48222822 XER: 20000000 [ 44.560855] DAR: 0000000c DSISR: c0000000 [ 44.560855] GPR00: c02d28fc c6813d40 c6828000 c646fa40 00000001 00000001 00000001 00000000 [ 44.560855] GPR08: 0000004c 00000000 c000bfcc 00000000 28222822 100280d4 00000000 10020008 [ 44.560855] GPR16: 00000000 00000020 00000000 00000000 10024008 00000000 c646f9f0 c6179a10 [ 44.560855] GPR24: 00000000 00000001 c62f0018 c6179a10 00000000 c6367a30 c62f0000 c646f9c0 [ 44.598542] NIP [c02d2be8] ahash_process_req+0x448/0x700 [ 44.603751] LR [c02d2984] ahash_process_req+0x1e4/0x700 [ 44.608868] Call Trace: [ 44.611329] [c6813d40] [c02d28fc] ahash_process_req+0x15c/0x700 (unreliable) [ 44.618302] [c6813d90] [c02060c4] hash_recvmsg+0x11c/0x210 [ 44.623716] [c6813db0] [c0331354] ___sys_recvmsg+0x98/0x138 [ 44.629226] [c6813eb0] [c03332c0] __sys_recvmsg+0x40/0x84 [ 44.634562] [c6813f10] [c03336c0] SyS_socketcall+0xb8/0x1d4 [ 44.640073] [c6813f40] [c000d1ac] ret_from_syscall+0x0/0x38 [ 44.645530] Instruction dump: [ 44.648465] 38c00001 7f63db78 4e800421 7c791b78 54690ffe 0f090000 80ff0190 2f870000 [ 44.656122] 40befe50 2f990001 409e0210 813f01bc <8129000c> b39e003a 7d29c214 913e003c This patch fixes that Oops by checking if src is NULL. Fixes: 6a1e8d14156d4 ("crypto: talitos - making mapping helpers more generic") Cc: <[email protected]> Signed-off-by: Christophe Leroy <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2018-02-08crypto: sha512-mb - initialize pending lengths correctlyEric Biggers1-4/+6
The SHA-512 multibuffer code keeps track of the number of blocks pending in each lane. The minimum of these values is used to identify the next lane that will be completed. Unused lanes are set to a large number (0xFFFFFFFF) so that they don't affect this calculation. However, it was forgotten to set the lengths to this value in the initial state, where all lanes are unused. As a result it was possible for sha512_mb_mgr_get_comp_job_avx2() to select an unused lane, causing a NULL pointer dereference. Specifically this could happen in the case where ->update() was passed fewer than SHA512_BLOCK_SIZE bytes of data, so it then called sha_complete_job() without having actually submitted any blocks to the multi-buffer code. This hit a NULL pointer dereference if another task happened to have submitted blocks concurrently to the same CPU and the flush timer had not yet expired. Fix this by initializing sha512_mb_mgr->lens correctly. As usual, this bug was found by syzkaller. Fixes: 45691e2d9b18 ("crypto: sha512-mb - submit/flush routines for AVX2") Reported-by: syzbot <[email protected]> Cc: <[email protected]> # v4.8+ Signed-off-by: Eric Biggers <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2018-02-08Merge branch 'bpf-misc-nfp-bpftool-doc-fixes'Daniel Borkmann6-10/+81
Jakub Kicinski says: ==================== First patch in this series fixes applying the relocation to immediate load instructions in the NFP JIT. The remaining patches come from Quentin. Small addition to libbpf makes sure it recognizes all standard section names. Makefile in bpftool/Documentation is improved to explicitly check for rst2man being installed on the system, otherwise we risk installing empty files. Man page for bpftool-map is corrected to include program as a potential value for map of programs. Last two patches are slightly longer, those update bash completions to include this release cycle's additions from Roman. Maybe the use of Fixes tags is slightly frivolous there, but having bash completions which don't cover all commands and options could be disruptive to work flow for users. ==================== Signed-off-by: Daniel Borkmann <[email protected]>
2018-02-08tools: bpftool: add bash completion for cgroup commandsQuentin Monnet2-6/+62
Add bash completion for "bpftool cgroup" command family. While at it, also fix the formatting of some keywords in the man page for cgroups. Fixes: 5ccda64d38cc ("bpftool: implement cgroup bpf operations") Signed-off-by: Quentin Monnet <[email protected]> Reviewed-by: Jakub Kicinski <[email protected]> Signed-off-by: Daniel Borkmann <[email protected]>
2018-02-08tools: bpftool: add bash completion for `bpftool prog load`Quentin Monnet1-2/+6
Add bash completion for bpftool command `prog load`. Completion for this command is easy, as it only takes existing file paths as arguments. Fixes: 49a086c201a9 ("bpftool: implement prog load command") Signed-off-by: Quentin Monnet <[email protected]> Reviewed-by: Jakub Kicinski <[email protected]> Signed-off-by: Daniel Borkmann <[email protected]>
2018-02-08tools: bpftool: make syntax for program map update explicit in man pageQuentin Monnet1-1/+2
Specify in the documentation that when using bpftool to update a map of type BPF_MAP_TYPE_PROG_ARRAY, the syntax for the program used as a value should use the "id|tag|pinned" keywords convention, as used with "bpftool prog" commands. Fixes: ff69c21a85a4 ("tools: bpftool: add documentation") Signed-off-by: Quentin Monnet <[email protected]> Reviewed-by: Jakub Kicinski <[email protected]> Signed-off-by: Daniel Borkmann <[email protected]>
2018-02-08tools: bpftool: exit doc Makefile early if rst2man is not availableQuentin Monnet1-0/+5
If rst2man is not available on the system, running `make doc` from the bpftool directory fails with an error message. However, it creates empty manual pages (.8 files in this case). A subsequent call to `make doc-install` would then succeed and install those empty man pages on the system. To prevent this, raise a Makefile error and exit immediately if rst2man is not available before generating the pages from the rst documentation. Fixes: ff69c21a85a4 ("tools: bpftool: add documentation") Reported-by: Jason van Aaardt <[email protected]> Signed-off-by: Quentin Monnet <[email protected]> Reviewed-by: Jakub Kicinski <[email protected]> Signed-off-by: Daniel Borkmann <[email protected]>
2018-02-08libbpf: complete list of strings for guessing program typeQuentin Monnet1-0/+5
It seems that the type guessing feature for libbpf, based on the name of the ELF section the program is located in, was inspired from samples/bpf/prog_load.c, which was not used by any sample for loading programs of certain types such as TC actions and classifiers, or LWT-related types. As a consequence, libbpf is not able to guess the type of such programs and to load them automatically if type is not provided to the `bpf_load_prog()` function. Add ELF section names associated to those eBPF program types so that they can be loaded with e.g. bpftool as well. Signed-off-by: Quentin Monnet <[email protected]> Reviewed-by: Jakub Kicinski <[email protected]> Signed-off-by: Daniel Borkmann <[email protected]>
2018-02-08nfp: bpf: fix immed relocation for larger offsetsJakub Kicinski1-1/+1
Immed relocation is missing a shift which means for larger offsets the lower and higher part of the address would be ORed together. Fixes: ce4ebfd859c3 ("nfp: bpf: add helpers for updating immediate instructions") Signed-off-by: Jakub Kicinski <[email protected]> Reviewed-by: Jiong Wang <[email protected]> Signed-off-by: Daniel Borkmann <[email protected]>
2018-02-08Merge branches 'acpi-video', 'acpi-battery' and 'acpi-cppc'Rafael J. Wysocki3-2/+18
* acpi-video: ACPI / video: Use true for boolean value * acpi-battery: ACPI / battery: Add quirk for Asus UX360UA and UX410UAK * acpi-cppc: ACPI / CPPC: Use 64-bit arithmetic instead of 32-bit
2018-02-08Merge branches 'acpi-tables', 'acpi-bus' and 'acpi-processor'Rafael J. Wysocki14-47/+109
* acpi-tables: ACPI: SPCR: Make SPCR available to x86 ACPI / tables: Add IORT to injectable table list * acpi-bus: ACPI / bus: Parse tables as term_list for Dell XPS 9570 and Precision M5530 ACPI / scan: Use acpi_bus_get_status() to initialize ACPI_TYPE_DEVICE devs ACPI / bus: Do not call _STA on battery devices with unmet dependencies PCI: acpiphp_ibm: prepare for acpi_get_object_info() no longer returning status ACPI: export acpi_bus_get_status_handle() * acpi-processor: ACPI / processor: Set default C1 idle state description ACPI: processor_perflib: Do not send _PPC change notification if not ready
2018-02-08Merge branch 'acpica'Rafael J. Wysocki229-237/+237
* acpica: ACPICA: Update version to 20180105 ACPICA: All acpica: Update copyrights to 2018 ACPICA: Add a missing pair of parentheses ACPICA: Prefer ACPI_TO_POINTER() over ACPI_ADD_PTR() ACPICA: Avoid NULL pointer arithmetic ACPICA: Linux: add support for X32 ABI compilation
2018-02-08CRIS: Restore mistakenly cleared kernel MakefileJesper Nilsson1-0/+17
Commit 0fbc0b67a89d7 ("cris: remove arch specific early DT functions") was a bit overzealous in removing the CRIS DT handling, and the complete contents of the Makefile was erased instead of just the line for the devicetree file. This lead to a complete link failure for all SoCs in the CRIS port due to missing symbols. Restore the contents except the line for the devicetree file. Signed-off-by: Jesper Nilsson <[email protected]> Fixes: 0fbc0b67a89d7
2018-02-08xen: Fix {set,clear}_foreign_p2m_mapping on autotranslating guestsSimon Gaiser1-0/+6
Commit 82616f9599a7 ("xen: remove tests for pvh mode in pure pv paths") removed the check for autotranslation from {set,clear}_foreign_p2m_mapping but those are called by grant-table.c also on PVH/HVM guests. Cc: <[email protected]> # 4.14 Fixes: 82616f9599a7 ("xen: remove tests for pvh mode in pure pv paths") Signed-off-by: Simon Gaiser <[email protected]> Reviewed-by: Juergen Gross <[email protected]> Signed-off-by: Juergen Gross <[email protected]>
2018-02-08Merge branches 'pm-cpufreq', 'pm-cpuidle' and 'pm-domains'Rafael J. Wysocki18-238/+166
* pm-cpufreq: arm: imx: Add MODULE_ALIAS for cpufreq cpufreq: Add and use cpufreq_for_each_{valid_,}entry_idx() cpufreq: intel_pstate: Enable HWP during system resume on CPU0 cpufreq: scpi: fix error return code in scpi_cpufreq_init() cpufreq: scpi: fix static checker warning cdev isn't an ERR_PTR cpufreq: remove at32ap-cpufreq cpufreq: AMD: Ignore the check for ProcFeedback in ST/CZ cpufreq: Skip cpufreq resume if it's not suspended * pm-cpuidle: x86: PM: Make APM idle driver initialize polling state * pm-domains: PM / domains: Fix up domain-idle-states OF parsing
2018-02-08arm: imx: Add MODULE_ALIAS for cpufreqNicolas Chauvet1-0/+1
Without this, the imx6q-cpufreq driver isn't loaded automatically when built as a module Tested on wandboard quad with a fedora 27 kernel rpm Signed-off-by: Nicolas Chauvet <[email protected]> Acked-by: Viresh Kumar <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
2018-02-08cpufreq: Add and use cpufreq_for_each_{valid_,}entry_idx()Dominik Brodowski8-63/+100
Pointer subtraction is slow and tedious. Therefore, replace all instances where cpufreq_for_each_{valid_,}entry loops contained such substractions with an iteration macro providing an index to the frequency_table entry. Suggested-by: Al Viro <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Acked-by: Viresh Kumar <[email protected]> Signed-off-by: Dominik Brodowski <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
2018-02-08cpufreq: intel_pstate: Enable HWP during system resume on CPU0Chen Yu1-0/+5
When maxcpus=1 is in the kernel command line, the BP is responsible for re-enabling the HWP - because currently only the APs invoke intel_pstate_hwp_enable() during their online process - which might put the system into unstable state after resume. Fix this by enabling the HWP explicitly on BP during resume. Reported-by: Doug Smythies <[email protected]> Suggested-by: Srinivas Pandruvada <[email protected]> Signed-off-by: Yu Chen <[email protected]> [ rjw: Subject/changelog, minor modifications ] Signed-off-by: Rafael J. Wysocki <[email protected]>
2018-02-08cpufreq: scpi: fix error return code in scpi_cpufreq_init()Wei Yongjun1-0/+1
Fix to return a negative error code from the clk_get() error handling case instead of 0, as done elsewhere in this function. Fixes: 343a8d17fa8d (cpufreq: scpi: remove arm_big_little dependency) Signed-off-by: Wei Yongjun <[email protected]> Acked-by: Viresh Kumar <[email protected]> Acked-by: Sudeep Holla <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
2018-02-08ACPI: sbshc: remove raw pointer from printk() messageGreg Kroah-Hartman1-2/+2
There's no need to be printing a raw kernel pointer to the kernel log at every boot. So just remove it, and change the whole message to use the correct dev_info() call at the same time. Reported-by: Wang Qize <[email protected]> Cc: All applicable <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
2018-02-08s390/kconfig: Remove ARCH_WANTS_PROT_NUMA_PROT_NONE selectUlf Magnusson1-1/+0
The ARCH_WANTS_PROT_NUMA_PROT_NONE symbol was removed by commit 6a33979d5bd7 ("mm: remove misleading ARCH_USES_NUMA_PROT_NONE"), but S390 still selects it. Remove the ARCH_WANTS_PROT_NUMA_PROT_NONE select from the S390 symbol. Discovered with the https://github.com/ulfalizer/Kconfiglib/blob/master/examples/list_undefined.py script. Signed-off-by: Ulf Magnusson <[email protected]> Signed-off-by: Heiko Carstens <[email protected]> Signed-off-by: Martin Schwidefsky <[email protected]>
2018-02-08KVM: PPC: Book3S PR: Fix broken select due to misspellingUlf Magnusson1-1/+1
Commit 76d837a4c0f9 ("KVM: PPC: Book3S PR: Don't include SPAPR TCE code on non-pseries platforms") added a reference to the globally undefined symbol PPC_SERIES. Looking at the rest of the commit, PPC_PSERIES was probably intended. Change PPC_SERIES to PPC_PSERIES. Discovered with the https://github.com/ulfalizer/Kconfiglib/blob/master/examples/list_undefined.py script. Fixes: 76d837a4c0f9 ("KVM: PPC: Book3S PR: Don't include SPAPR TCE code on non-pseries platforms") Cc: [email protected] # v4.12+ Signed-off-by: Ulf Magnusson <[email protected]> Signed-off-by: Paul Mackerras <[email protected]>
2018-02-07tcp: tracepoint: only call trace_tcp_send_reset with full socketSong Liu2-2/+4
tracepoint tcp_send_reset requires a full socket to work. However, it may be called when in TCP_TIME_WAIT: case TCP_TW_RST: tcp_v6_send_reset(sk, skb); inet_twsk_deschedule_put(inet_twsk(sk)); goto discard_it; To avoid this problem, this patch checks the socket with sk_fullsock() before calling trace_tcp_send_reset(). Fixes: c24b14c46bb8 ("tcp: add tracepoint trace_tcp_send_reset") Signed-off-by: Song Liu <[email protected]> Reviewed-by: Lawrence Brakmo <[email protected]> Signed-off-by: David S. Miller <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.