aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2020-01-02ftrace: Avoid potential division by zero in function profilerWen Yang1-3/+3
The ftrace_profile->counter is unsigned long and do_div truncates it to 32 bits, which means it can test non-zero and be truncated to zero for division. Fix this issue by using div64_ul() instead. Link: http://lkml.kernel.org/r/[email protected] Cc: [email protected] Fixes: e330b3bcd8319 ("tracing: Show sample std dev in function profiling") Fixes: 34886c8bc590f ("tracing: add average time in function to function profiler") Signed-off-by: Wen Yang <[email protected]> Signed-off-by: Steven Rostedt (VMware) <[email protected]>
2020-01-02tracing: Have stack tracer compile when MCOUNT_INSN_SIZE is not definedSteven Rostedt (VMware)1-0/+5
On some archs with some configurations, MCOUNT_INSN_SIZE is not defined, and this makes the stack tracer fail to compile. Just define it to zero in this case. Link: https://lore.kernel.org/r/202001020219.zvE3vsty%[email protected] Cc: [email protected] Fixes: 4df297129f622 ("tracing: Remove most or all of stack tracer stack size from stack_max_size") Reported-by: kbuild test robot <[email protected]> Signed-off-by: Steven Rostedt (VMware) <[email protected]>
2020-01-02tracing: Define MCOUNT_INSN_SIZE when not defined without direct callsSteven Rostedt (VMware)1-0/+14
In order to handle direct calls along side of function graph tracer, a check is made to see if the address being traced by the function graph tracer is a direct call or not. To get the address used by direct callers, the return address is subtracted by MCOUNT_INSN_SIZE. For some archs with certain configurations, MCOUNT_INSN_SIZE is undefined here. But these should not be using direct calls anyway. Just define MCOUNT_INSN_SIZE to zero in this case. Link: https://lore.kernel.org/r/202001020219.zvE3vsty%[email protected] Reported-by: kbuild test robot <[email protected]> Fixes: ff205766dbbee ("ftrace: Fix function_graph tracer interaction with BPF trampoline") Signed-off-by: Steven Rostedt (VMware) <[email protected]>
2020-01-02net: Update GIT url in maintainers.David S. Miller1-5/+5
Reported-by: Stephen Rothwell <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-01-02Merge tag 'sizeof_field-v5.5-rc5' of ↵Linus Torvalds1-9/+0
git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux Pull final sizeof_field conversion from Kees Cook: "Remove now unused FIELD_SIZEOF() macro (Kees Cook)" * tag 'sizeof_field-v5.5-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux: kernel.h: Remove unused FIELD_SIZEOF()
2020-01-03spi: Document Octal mode as valid SPI bus widthVignesh Raghavendra1-2/+2
SPI core supports Octal SPI controllers which have 8 IO lines. Therefore document 8 as a valid option for spi-tx{rx}-bus-width Signed-off-by: Vignesh Raghavendra <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2020-01-03spi: spi-dw: Add lock protect dw_spi rx/tx to prevent concurrent callswuxu.wu2-3/+13
dw_spi_irq() and dw_spi_transfer_one concurrent calls. I find a panic in dw_writer(): txw = *(u8 *)(dws->tx), when dw->tx==null, dw->len==4, and dw->tx_end==1. When tpm driver's message overtime dw_spi_irq() and dw_spi_transfer_one may concurrent visit dw_spi, so I think dw_spi structure lack of protection. Otherwise dw_spi_transfer_one set dw rx/tx buffer and then open irq, store dw rx/tx instructions and other cores handle irq load dw rx/tx instructions may out of order. [ 1025.321302] Call trace: ... [ 1025.321319] __crash_kexec+0x98/0x148 [ 1025.321323] panic+0x17c/0x314 [ 1025.321329] die+0x29c/0x2e8 [ 1025.321334] die_kernel_fault+0x68/0x78 [ 1025.321337] __do_kernel_fault+0x90/0xb0 [ 1025.321346] do_page_fault+0x88/0x500 [ 1025.321347] do_translation_fault+0xa8/0xb8 [ 1025.321349] do_mem_abort+0x68/0x118 [ 1025.321351] el1_da+0x20/0x8c [ 1025.321362] dw_writer+0xc8/0xd0 [ 1025.321364] interrupt_transfer+0x60/0x110 [ 1025.321365] dw_spi_irq+0x48/0x70 ... Signed-off-by: wuxu.wu <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2020-01-03regulator: bd70528: Remove .set_ramp_delay for bd70528_ldo_opsAxel Lin1-1/+0
The .set_ramp_delay should be for bd70528_buck_ops only. Setting .set_ramp_delay for for bd70528_ldo_ops causes problem because BD70528_MASK_BUCK_RAMP (0x10) overlaps with BD70528_MASK_LDO_VOLT (0x1f). So setting ramp_delay for LDOs may change the voltage output, fix it. Fixes: 99ea37bd1e7d ("regulator: bd70528: Support ROHM BD70528 regulator block") Signed-off-by: Axel Lin <[email protected]> Acked-by: Matti Vaittinen <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2020-01-02Merge tag 'gcc-plugins-v5.5-rc5' of ↵Linus Torvalds1-5/+4
git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux Pull gcc-plugins fix from Kees Cook: "Build flexibility fix: allow builds to disable plugins even when plugins available (Arnd Bergmann)" * tag 'gcc-plugins-v5.5-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux: gcc-plugins: make it possible to disable CONFIG_GCC_PLUGINS again
2020-01-02Merge tag 'seccomp-v5.5-rc5' of ↵Linus Torvalds3-3/+23
git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux Pull seccomp fixes from Kees Cook: "Fixes for seccomp_notify_ioctl uapi sanity from Sargun Dhillon. The bulk of this is fixing the surrounding samples and selftests so that seccomp can correctly validate the seccomp_notify_ioctl buffer as being initially zeroed. Summary: - Fix samples and selftests to zero passed-in buffer - Enforce zeroed buffer checking - Verify buffer sanity check in selftest" * tag 'seccomp-v5.5-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux: selftests/seccomp: Catch garbage on SECCOMP_IOCTL_NOTIF_RECV seccomp: Check that seccomp_notif is zeroed out by the user selftests/seccomp: Zero out seccomp_notif samples/seccomp: Zero out members based on seccomp_notif_sizes
2020-01-02MIPS: Avoid VDSO ABI breakage due to global register variablePaul Burton1-1/+19
Declaring __current_thread_info as a global register variable has the effect of preventing GCC from saving & restoring its value in cases where the ABI would typically do so. To quote GCC documentation: > If the register is a call-saved register, call ABI is affected: the > register will not be restored in function epilogue sequences after the > variable has been assigned. Therefore, functions cannot safely return > to callers that assume standard ABI. When our position independent VDSO is built for the n32 or n64 ABIs all functions it exposes should be preserving the value of $gp/$28 for their caller, but in the presence of the __current_thread_info global register variable GCC stops doing so & simply clobbers $gp/$28 when calculating the address of the GOT. In cases where the VDSO returns success this problem will typically be masked by the caller in libc returning & restoring $gp/$28 itself, but that is by no means guaranteed. In cases where the VDSO returns an error libc will typically contain a fallback path which will now fail (typically with a bad memory access) if it attempts anything which relies upon the value of $gp/$28 - eg. accessing anything via the GOT. One fix for this would be to move the declaration of __current_thread_info inside the current_thread_info() function, demoting it from global register variable to local register variable & avoiding inadvertently creating a non-standard calling ABI for the VDSO. Unfortunately this causes issues for clang, which doesn't support local register variables as pointed out by commit fe92da0f355e ("MIPS: Changed current_thread_info() to an equivalent supported by both clang and GCC") which introduced the global register variable before we had a VDSO to worry about. Instead, fix this by continuing to use the global register variable for the kernel proper but declare __current_thread_info as a simple extern variable when building the VDSO. It should never be referenced, and will cause a link error if it is. This resolves the calling convention issue for the VDSO without having any impact upon the build of the kernel itself for either clang or gcc. Signed-off-by: Paul Burton <[email protected]> Fixes: ebb5e78cc634 ("MIPS: Initial implementation of a VDSO") Reported-by: Jason A. Donenfeld <[email protected]> Reviewed-by: Jason A. Donenfeld <[email protected]> Tested-by: Jason A. Donenfeld <[email protected]> Cc: Arnd Bergmann <[email protected]> Cc: Christian Brauner <[email protected]> Cc: Vincenzo Frascino <[email protected]> Cc: <[email protected]> # v4.4+ Cc: [email protected] Cc: [email protected]
2020-01-02Merge tag 'linux-can-fixes-for-5.5-20200102' of ↵David S. Miller6-25/+101
git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can Marc Kleine-Budde says: ==================== pull-request: can 2020-01-02 this is a pull request of 9 patches for net/master. The first 5 patches target all the tcan4x5x driver. The first 3 patches of them are by Dan Murphy and Sean Nyekjaer and improve the device initialization (power on, reset and get device out of standby before register access). The next patch is by Dan Murphy and disables the INH pin device-state if the GPIO is unavailable. The last patch for the tcan4x5x driver is by Gustavo A. R. Silva and fixes an inconsistent PTR_ERR check in the tcan4x5x_parse_config() function. The next patch is by Oliver Hartkopp and targets the generic CAN device infrastructure. It ensures that an initialized headroom in outgoing CAN sk_buffs (e.g. if injected by AF_PACKET). The last 2 patches are by Johan Hovold and fix the kvaser_usb and gs_usb drivers by always using the current alternate setting not blindly the first one. ==================== Signed-off-by: David S. Miller <[email protected]>
2020-01-02Merge tag 'pstore-v5.5-rc5' of ↵Linus Torvalds1-0/+13
git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux Pull pstore bug fixes from Kees Cook: - always reset circular buffer state when writing new dump (Aleksandr Yashkin) - fix rare error-path memory leak (Kees Cook) * tag 'pstore-v5.5-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux: pstore/ram: Write new dumps to start of recycled zones pstore/ram: Fix error-path memory leak in persistent_ram_new() callers
2020-01-02net: freescale: fec: Fix ethtool -d runtime PMAndrew Lunn1-0/+9
In order to dump the FECs registers the clocks have to be ticking, otherwise a data abort occurs. Add calls to runtime PM so they are enabled and later disabled. Fixes: e8fcfcd5684a ("net: fec: optimize the clock management to save power") Reported-by: Chris Healy <[email protected]> Signed-off-by: Andrew Lunn <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-01-02vxlan: fix tos value before xmitHangbin Liu1-2/+2
Before ip_tunnel_ecn_encap() and udp_tunnel_xmit_skb() we should filter tos value by RT_TOS() instead of using config tos directly. vxlan_get_route() would filter the tos to fl4.flowi4_tos but we didn't return it back, as geneve_get_v4_rt() did. So we have to use RT_TOS() directly in function ip_tunnel_ecn_encap(). Fixes: 206aaafcd279 ("VXLAN: Use IP Tunnels tunnel ENC encap API") Fixes: 1400615d64cf ("vxlan: allow setting ipv6 traffic class") Signed-off-by: Hangbin Liu <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-01-02sch_cake: avoid possible divide by zero in cake_enqueue()Wen Yang1-1/+1
The variables 'window_interval' is u64 and do_div() truncates it to 32 bits, which means it can test non-zero and be truncated to zero for division. The unit of window_interval is nanoseconds, so its lower 32-bit is relatively easy to exceed. Fix this issue by using div64_u64() instead. Fixes: 7298de9cd725 ("sch_cake: Add ingress mode") Signed-off-by: Wen Yang <[email protected]> Cc: Kevin Darbyshire-Bryant <[email protected]> Cc: Toke Høiland-Jørgensen <[email protected]> Cc: David S. Miller <[email protected]> Cc: Cong Wang <[email protected]> Cc: [email protected] Cc: [email protected] Cc: [email protected] Acked-by: Toke Høiland-Jørgensen <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-01-02Revert "fs: remove ksys_dup()"Dominik Brodowski3-21/+13
This reverts commit 8243186f0cc7 ("fs: remove ksys_dup()") and the subsequent fix for it in commit 2d3145f8d280 ("early init: fix error handling when opening /dev/console"). Trying to use filp_open() and f_dupfd() instead of pseudo-syscalls caused more trouble than what is worth it: it requires accessing vfs internals and it turns out there were other bugs in it too. In particular, the file reference counting was wrong - because unlike the original "open+2*dup" sequence it used "filp_open+3*f_dupfd" and thus had an extra leaked file reference. That in turn then caused odd problems with Androidx86 long after boot becaue of how the extra reference to the console kept the session active even after all file descriptors had been closed. Reported-by: youling 257 <[email protected]> Cc: Arvind Sankar <[email protected]> Cc: Al Viro <[email protected]> Signed-off-by: Dominik Brodowski <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2020-01-02net: Correct type of tcp_syncookies sysctl.David S. Miller1-1/+1
It can take on the values of '0', '1', and '2' and thus is not a boolean. Signed-off-by: David S. Miller <[email protected]>
2020-01-02tracing: Initialize val to zero in parse_entry of inject codeSteven Rostedt (VMware)1-1/+1
gcc produces a variable may be uninitialized warning for "val" in parse_entry(). This is really a false positive, but the code is subtle enough to just initialize val to zero and it's not a fast path to worry about it. Marked for stable to remove the warning in the stable trees as well. Cc: [email protected] Fixes: 6c3edaf9fd6a3 ("tracing: Introduce trace event injection") Reported-by: kbuild test robot <[email protected]> Signed-off-by: Steven Rostedt (VMware) <[email protected]>
2020-01-02tcp: fix "old stuff" D-SACK causing SACK to be treated as D-SACKPengcheng Yang1-1/+4
When we receive a D-SACK, where the sequence number satisfies: undo_marker <= start_seq < end_seq <= prior_snd_una we consider this is a valid D-SACK and tcp_is_sackblock_valid() returns true, then this D-SACK is discarded as "old stuff", but the variable first_sack_index is not marked as negative in tcp_sacktag_write_queue(). If this D-SACK also carries a SACK that needs to be processed (for example, the previous SACK segment was lost), this SACK will be treated as a D-SACK in the following processing of tcp_sacktag_write_queue(), which will eventually lead to incorrect updates of undo_retrans and reordering. Fixes: fd6dad616d4f ("[TCP]: Earlier SACK block verification & simplify access to them") Signed-off-by: Pengcheng Yang <[email protected]> Signed-off-by: Eric Dumazet <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-01-02net: dsa: mv88e6xxx: force cmode write on 6141/6341Baruch Siach1-6/+6
mv88e6xxx_port_set_cmode() relies on cmode stored in struct mv88e6xxx_port to skip cmode update when the requested value matches the cached value. It turns out that mv88e6xxx_port_hidden_write() might change the port cmode setting as a side effect, so we can't rely on the cached value to determine that cmode update in not necessary. Force cmode update in mv88e6341_port_set_cmode(), to make serdes configuration work again. Other mv88e6xxx_port_set_cmode() callers keep the current behaviour. This fixes serdes configuration of the 6141 switch on SolidRun Clearfog GT-8K. Fixes: 7a3007d22e8 ("net: dsa: mv88e6xxx: fully support SERDES on Topaz family") Reported-by: Denis Odintsov <[email protected]> Signed-off-by: Baruch Siach <[email protected]> Reviewed-by: Andrew Lunn <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-01-02gcc-plugins: make it possible to disable CONFIG_GCC_PLUGINS againArnd Bergmann1-5/+4
I noticed that randconfig builds with gcc no longer produce a lot of ccache hits, unlike with clang, and traced this back to plugins now being enabled unconditionally if they are supported. I am now working around this by adding export CCACHE_COMPILERCHECK=/usr/bin/size -A %compiler% to my top-level Makefile. This changes the heuristic that ccache uses to determine whether the plugins are the same after a 'make clean'. However, it also seems that being able to just turn off the plugins is generally useful, at least for build testing it adds noticeable overhead but does not find a lot of bugs additional bugs, and may be easier for ccache users than my workaround. Fixes: 9f671e58159a ("security: Create "kernel hardening" config area") Signed-off-by: Arnd Bergmann <[email protected]> Acked-by: Ard Biesheuvel <[email protected]> Reviewed-by: Masahiro Yamada <[email protected]> Link: https://lore.kernel.org/r/[email protected] Cc: [email protected] Signed-off-by: Kees Cook <[email protected]>
2020-01-02selftests/seccomp: Catch garbage on SECCOMP_IOCTL_NOTIF_RECVSargun Dhillon1-1/+12
This adds logic to the user_notification_basic test to set a member of struct seccomp_notif to an invalid value to ensure that the kernel returns EINVAL if any of the struct seccomp_notif members are set to invalid values. Signed-off-by: Sargun Dhillon <[email protected]> Suggested-by: Christian Brauner <[email protected]> Link: https://lore.kernel.org/r/[email protected] Fixes: 6a21cc50f0c7 ("seccomp: add a return code to trap to userspace") Cc: [email protected] Signed-off-by: Kees Cook <[email protected]>
2020-01-02seccomp: Check that seccomp_notif is zeroed out by the userSargun Dhillon1-0/+7
This patch is a small change in enforcement of the uapi for SECCOMP_IOCTL_NOTIF_RECV ioctl. Specifically, the datastructure which is passed (seccomp_notif) must be zeroed out. Previously any of its members could be set to nonsense values, and we would ignore it. This ensures all fields are set to their zero value. Signed-off-by: Sargun Dhillon <[email protected]> Reviewed-by: Christian Brauner <[email protected]> Reviewed-by: Aleksa Sarai <[email protected]> Acked-by: Tycho Andersen <[email protected]> Link: https://lore.kernel.org/r/[email protected] Fixes: 6a21cc50f0c7 ("seccomp: add a return code to trap to userspace") Cc: [email protected] Signed-off-by: Kees Cook <[email protected]>
2020-01-02selftests/seccomp: Zero out seccomp_notifSargun Dhillon1-0/+2
The seccomp_notif structure should be zeroed out prior to calling the SECCOMP_IOCTL_NOTIF_RECV ioctl. Previously, the kernel did not check whether these structures were zeroed out or not, so these worked. This patch zeroes out the seccomp_notif data structure prior to calling the ioctl. Signed-off-by: Sargun Dhillon <[email protected]> Reviewed-by: Tycho Andersen <[email protected]> Reviewed-by: Christian Brauner <[email protected]> Link: https://lore.kernel.org/r/[email protected] Fixes: 6a21cc50f0c7 ("seccomp: add a return code to trap to userspace") Cc: [email protected] Signed-off-by: Kees Cook <[email protected]>
2020-01-02samples/seccomp: Zero out members based on seccomp_notif_sizesSargun Dhillon1-2/+2
The sizes by which seccomp_notif and seccomp_notif_resp are allocated are based on the SECCOMP_GET_NOTIF_SIZES ioctl. This allows for graceful extension of these datastructures. If userspace zeroes out the datastructure based on its version, and it is lagging behind the kernel's version, it will end up sending trailing garbage. On the other hand, if it is ahead of the kernel version, it will write extra zero space, and potentially cause corruption. Signed-off-by: Sargun Dhillon <[email protected]> Suggested-by: Tycho Andersen <[email protected]> Link: https://lore.kernel.org/r/[email protected] Fixes: fec7b6690541 ("samples: add an example of seccomp user trap") Cc: [email protected] Signed-off-by: Kees Cook <[email protected]>
2020-01-02pstore/ram: Write new dumps to start of recycled zonesAleksandr Yashkin1-0/+11
The ram_core.c routines treat przs as circular buffers. When writing a new crash dump, the old buffer needs to be cleared so that the new dump doesn't end up in the wrong place (i.e. at the end). The solution to this problem is to reset the circular buffer state before writing a new Oops dump. Signed-off-by: Aleksandr Yashkin <[email protected]> Signed-off-by: Nikolay Merinov <[email protected]> Signed-off-by: Ariel Gilman <[email protected]> Link: https://lore.kernel.org/r/[email protected] Fixes: 896fc1f0c4c6 ("pstore/ram: Switch to persistent_ram routines") Cc: [email protected] Signed-off-by: Kees Cook <[email protected]>
2020-01-02pstore/ram: Fix error-path memory leak in persistent_ram_new() callersKees Cook1-0/+2
For callers that allocated a label for persistent_ram_new(), if the call fails, they must clean up the allocation. Suggested-by: Navid Emamdoost <[email protected]> Fixes: 1227daa43bce ("pstore/ram: Clarify resource reservation labels") Cc: [email protected] Link: https://lore.kernel.org/lkml/[email protected] Signed-off-by: Kees Cook <[email protected]>
2020-01-02can: mscan: mscan_rx_poll(): fix rx path lockup when returning from polling ↵Florian Faber1-11/+10
to irq mode Under load, the RX side of the mscan driver can get stuck while TX still works. Restarting the interface locks up the system. This behaviour could be reproduced reliably on a MPC5121e based system. The patch fixes the return value of the NAPI polling function (should be the number of processed packets, not constant 1) and the condition under which IRQs are enabled again after polling is finished. With this patch, no more lockups were observed over a test period of ten days. Fixes: afa17a500a36 ("net/can: add driver for mscan family & mpc52xx_mscan") Signed-off-by: Florian Faber <[email protected]> Cc: linux-stable <[email protected]> Signed-off-by: Marc Kleine-Budde <[email protected]>
2020-01-02can: gs_usb: gs_usb_probe(): use descriptors of current altsettingJohan Hovold1-2/+2
Make sure to always use the descriptors of the current alternate setting to avoid future issues when accessing fields that may differ between settings. Signed-off-by: Johan Hovold <[email protected]> Fixes: d08e973a77d1 ("can: gs_usb: Added support for the GS_USB CAN devices") Signed-off-by: Marc Kleine-Budde <[email protected]>
2020-01-02can: kvaser_usb: fix interface sanity checkJohan Hovold2-2/+2
Make sure to use the current alternate setting when verifying the interface descriptors to avoid binding to an invalid interface. Failing to do so could cause the driver to misbehave or trigger a WARN() in usb_submit_urb() that kernels with panic_on_warn set would choke on. Fixes: aec5fb2268b7 ("can: kvaser_usb: Add support for Kvaser USB hydra family") Cc: stable <[email protected]> # 4.19 Cc: Jimmy Assarsson <[email protected]> Cc: Christer Beskow <[email protected]> Cc: Nicklas Johansson <[email protected]> Cc: Martin Henriksson <[email protected]> Signed-off-by: Johan Hovold <[email protected]> Signed-off-by: Marc Kleine-Budde <[email protected]>
2020-01-02can: can_dropped_invalid_skb(): ensure an initialized headroom in outgoing ↵Oliver Hartkopp1-0/+34
CAN sk_buffs KMSAN sysbot detected a read access to an untinitialized value in the headroom of an outgoing CAN related sk_buff. When using CAN sockets this area is filled appropriately - but when using a packet socket this initialization is missing. The problematic read access occurs in the CAN receive path which can only be triggered when the sk_buff is sent through a (virtual) CAN interface. So we check in the sending path whether we need to perform the missing initializations. Fixes: d3b58c47d330d ("can: replace timestamp as unique skb attribute") Reported-by: [email protected] Signed-off-by: Oliver Hartkopp <[email protected]> Tested-by: Oliver Hartkopp <[email protected]> Cc: linux-stable <[email protected]> # >= v4.1 Signed-off-by: Marc Kleine-Budde <[email protected]>
2020-01-02can: tcan4x5x: tcan4x5x_parse_config(): fix inconsistent IS_ERR and PTR_ERRGustavo A. R. Silva1-1/+1
Fix inconsistent IS_ERR and PTR_ERR in tcan4x5x_parse_config(). The proper pointer to be passed as argument is tcan4x5x->device_wake_gpio. This bug was detected with the help of Coccinelle. Fixes: 2de497356955 ("can: tcan45x: Make wake-up GPIO an optional GPIO") Signed-off-by: Gustavo A. R. Silva <[email protected]> Acked-by: Dan Murphy <[email protected]> Signed-off-by: Marc Kleine-Budde <[email protected]>
2020-01-02can: tcan4x5x: tcan4x5x_parse_config(): Disable the INH pin device-state ↵Dan Murphy1-1/+12
GPIO is unavailable If the device state GPIO is not connected to the host then disable the INH output from the TCAN device per section 8.3.5 of the data sheet. Signed-off-by: Dan Murphy <[email protected]> Signed-off-by: Marc Kleine-Budde <[email protected]>
2020-01-02can: tcan4x5x: tcan4x5x_parse_config(): reset device before register accessSean Nyekjaer1-1/+26
It's a good idea to reset a ip-block/spi device before using it, this patch will reset the device. And a generic reset function if needed elsewhere. Signed-off-by: Sean Nyekjaer <[email protected]> Signed-off-by: Marc Kleine-Budde <[email protected]>
2020-01-02can: tcan4x5x: tcan4x5x_can_probe(): turn on the power before parsing the configDan Murphy1-7/+10
The tcan4x5x_parse_config() function now performs action on the device either reading or writing and a reset. If the devive has a switchable power supppy (i.e. regulator is managed) it needs to be turned on. So turn on the regulator if available. If the parsing fails, turn off the regulator. Fixes: 2de497356955 ("can: tcan45x: Make wake-up GPIO an optional GPIO") Signed-off-by: Dan Murphy <[email protected]> Signed-off-by: Marc Kleine-Budde <[email protected]>
2020-01-02can: tcan4x5x: tcan4x5x_can_probe(): get the device out of standby before ↵Sean Nyekjaer1-0/+4
register access The m_can tries to detect if Non ISO Operation is available while in standby mode, this function results in the following error: | tcan4x5x spi2.0 (unnamed net_device) (uninitialized): Failed to init module | tcan4x5x spi2.0: m_can device registered (irq=84, version=32) | tcan4x5x spi2.0 can2: TCAN4X5X successfully initialized. When the tcan device comes out of reset it goes in standby mode. The m_can driver tries to access the control register but fails due to the device being in standby mode. So this patch will put the tcan device in normal mode before the m_can driver does the initialization. Fixes: 5443c226ba91 ("can: tcan4x5x: Add tcan4x5x driver to the kernel") Cc: [email protected] Signed-off-by: Sean Nyekjaer <[email protected]> Acked-by: Dan Murphy <[email protected]> Signed-off-by: Marc Kleine-Budde <[email protected]>
2020-01-02apparmor: only get a label reference if the fast path check failsJohn Johansen1-4/+8
The common fast path check can be done under rcu_read_lock() and doesn't need a reference count on the label. Only take a reference count if entering the slow path. Fixes reported hackbench regression - sha1 79e178a57dae ("Merge tag 'apparmor-pr-2019-12-03' of git://git.kernel.org/pub/scm/linux/kernel/git/jj/linux-apparmor") hackbench -l (256000/#grp) -g #grp 128 groups 19.679 ±0.90% - previous sha1 01d1dff64662 ("Merge tag 's390-5.5-2' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux") hackbench -l (256000/#grp) -g #grp 128 groups 3.1689 ±3.04% Reported-by: Vincent Guittot <[email protected]> Tested-by: Vincent Guittot <[email protected]> Tested-by: Sebastian Andrzej Siewior <[email protected]> Fixes: bce4e7e9c45e ("apparmor: reduce rcu_read_lock scope for aa_file_perm mediation") Signed-off-by: John Johansen <[email protected]>
2020-01-02apparmor: fix bind mounts aborting with -ENOMEMPatrick Steinhardt1-1/+1
With commit df323337e507 ("apparmor: Use a memory pool instead per-CPU caches, 2019-05-03"), AppArmor code was converted to use memory pools. In that conversion, a bug snuck into the code that polices bind mounts that causes all bind mounts to fail with -ENOMEM, as we erroneously error out if `aa_get_buffer` returns a pointer instead of erroring out when it does _not_ return a valid pointer. Fix the issue by correctly checking for valid pointers returned by `aa_get_buffer` to fix bind mounts with AppArmor. Fixes: df323337e507 ("apparmor: Use a memory pool instead per-CPU caches") Signed-off-by: Patrick Steinhardt <[email protected]> Signed-off-by: John Johansen <[email protected]>
2020-01-02Merge tag 'amd-drm-fixes-5.5-2020-01-01' of ↵Dave Airlie9-14/+28
git://people.freedesktop.org/~agd5f/linux into drm-fixes amd-drm-fixes-5.5-2020-01-01: amdgpu: - ATPX regression fix - SMU metrics table locking fixes - gfxoff fix for raven - RLC firmware loading stability fix Signed-off-by: Dave Airlie <[email protected]> From: Alex Deucher <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-01-02Merge tag 'drm-misc-fixes-2019-12-31' of ↵Dave Airlie2-3/+1
git://anongit.freedesktop.org/drm/drm-misc into drm-fixes -sun4i: Fix double-free in connector/encoder cleanup (Stefan) -malidp: Make vtable static (Ben) Cc: Ben Dooks <[email protected]> Cc: Stefan Mavrodiev <[email protected]> Signed-off-by: Dave Airlie <[email protected]> From: Sean Paul <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20191231152503.GA46740@art_vandelay
2020-01-02Merge tag 'mediatek-drm-fixes-5.5' of ↵Dave Airlie2-35/+50
https://github.com/ckhu-mediatek/linux.git-tags into drm-fixes Mediatek DRM fixes for Linux 5.5 Signed-off-by: Dave Airlie <[email protected]> From: CK Hu <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/1577762298.23194.2.camel@mtksdaap41
2020-01-01drm/amdgpu: correct RLC firmwares loading sequenceEvan Quan2-2/+2
Per confirmation with RLC firmware team, the RLC should be unhalted after all RLC related firmwares uploaded. However, in fact the RLC is unhalted immediately after RLCG firmware uploaded. And that may causes unexpected PSP hang on loading the succeeding RLC save restore list related firmwares. So, we correct the firmware loading sequence to load RLC save restore list related firmwares before RLCG ucode. That will help to get around this issue. Signed-off-by: Evan Quan <[email protected]> Reviewed-by: Hawking Zhang <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Cc: [email protected]
2019-12-31Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/netLinus Torvalds80-489/+600
Pull networking fixes from David Miller: 1) Fix big endian overflow in nf_flow_table, from Arnd Bergmann. 2) Fix port selection on big endian in nft_tproxy, from Phil Sutter. 3) Fix precision tracking for unbound scalars in bpf verifier, from Daniel Borkmann. 4) Fix integer overflow in socket rcvbuf check in UDP, from Antonio Messina. 5) Do not perform a neigh confirmation during a pmtu update over a tunnel, from Hangbin Liu. 6) Fix DMA mapping leak in dpaa_eth driver, from Madalin Bucur. 7) Various PTP fixes for sja1105 dsa driver, from Vladimir Oltean. 8) Add missing to dummy definition of of_mdiobus_child_is_phy(), from Geert Uytterhoeven * git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net: (54 commits) hsr: fix slab-out-of-bounds Read in hsr_debugfs_rename() net/sched: add delete_empty() to filters and use it in cls_flower tcp: Fix highest_sack and highest_sack_seq ptp: fix the race between the release of ptp_clock and cdev net: dsa: sja1105: Reconcile the meaning of TPID and TPID2 for E/T and P/Q/R/S Documentation: net: dsa: sja1105: Remove text about taprio base-time limitation net: dsa: sja1105: Remove restriction of zero base-time for taprio offload net: dsa: sja1105: Really make the PTP command read-write net: dsa: sja1105: Take PTP egress timestamp by port, not mgmt slot cxgb4/cxgb4vf: fix flow control display for auto negotiation mlxsw: spectrum: Use dedicated policer for VRRP packets mlxsw: spectrum_router: Skip loopback RIFs during MAC validation net: stmmac: dwmac-meson8b: Fix the RGMII TX delay on Meson8b/8m2 SoCs net/sched: act_mirred: Pull mac prior redir to non mac_header_xmit device net_sched: sch_fq: properly set sk->sk_pacing_status bnx2x: Fix accounting of vlan resources among the PFs bnx2x: Use appropriate define for vlan credit of: mdio: Add missing inline to of_mdiobus_child_is_phy() dummy net: phy: aquantia: add suspend / resume ops for AQR105 dpaa_eth: fix DMA mapping leak ...
2019-12-31Merge tag 'tomoyo-fixes-for-5.5' of ↵Linus Torvalds5-44/+27
git://git.osdn.net/gitroot/tomoyo/tomoyo-test1 Pull tomoyo fixes from Tetsuo Handa: "Two bug fixes: - Suppress RCU warning at list_for_each_entry_rcu() - Don't use fancy names on sockets" * tag 'tomoyo-fixes-for-5.5' of git://git.osdn.net/gitroot/tomoyo/tomoyo-test1: tomoyo: Suppress RCU warning at list_for_each_entry_rcu(). tomoyo: Don't use nifty names on sockets.
2019-12-30hsr: fix slab-out-of-bounds Read in hsr_debugfs_rename()Taehee Yoo1-1/+2
hsr slave interfaces don't have debugfs directory. So, hsr_debugfs_rename() shouldn't be called when hsr slave interface name is changed. Test commands: ip link add dummy0 type dummy ip link add dummy1 type dummy ip link add hsr0 type hsr slave1 dummy0 slave2 dummy1 ip link set dummy0 name ap Splat looks like: [21071.899367][T22666] ap: renamed from dummy0 [21071.914005][T22666] ================================================================== [21071.919008][T22666] BUG: KASAN: slab-out-of-bounds in hsr_debugfs_rename+0xaa/0xb0 [hsr] [21071.923640][T22666] Read of size 8 at addr ffff88805febcd98 by task ip/22666 [21071.926941][T22666] [21071.927750][T22666] CPU: 0 PID: 22666 Comm: ip Not tainted 5.5.0-rc2+ #240 [21071.929919][T22666] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006 [21071.935094][T22666] Call Trace: [21071.935867][T22666] dump_stack+0x96/0xdb [21071.936687][T22666] ? hsr_debugfs_rename+0xaa/0xb0 [hsr] [21071.937774][T22666] print_address_description.constprop.5+0x1be/0x360 [21071.939019][T22666] ? hsr_debugfs_rename+0xaa/0xb0 [hsr] [21071.940081][T22666] ? hsr_debugfs_rename+0xaa/0xb0 [hsr] [21071.940949][T22666] __kasan_report+0x12a/0x16f [21071.941758][T22666] ? hsr_debugfs_rename+0xaa/0xb0 [hsr] [21071.942674][T22666] kasan_report+0xe/0x20 [21071.943325][T22666] hsr_debugfs_rename+0xaa/0xb0 [hsr] [21071.944187][T22666] hsr_netdev_notify+0x1fe/0x9b0 [hsr] [21071.945052][T22666] ? __module_text_address+0x13/0x140 [21071.945897][T22666] notifier_call_chain+0x90/0x160 [21071.946743][T22666] dev_change_name+0x419/0x840 [21071.947496][T22666] ? __read_once_size_nocheck.constprop.6+0x10/0x10 [21071.948600][T22666] ? netdev_adjacent_rename_links+0x280/0x280 [21071.949577][T22666] ? __read_once_size_nocheck.constprop.6+0x10/0x10 [21071.950672][T22666] ? lock_downgrade+0x6e0/0x6e0 [21071.951345][T22666] ? do_setlink+0x811/0x2ef0 [21071.951991][T22666] do_setlink+0x811/0x2ef0 [21071.952613][T22666] ? is_bpf_text_address+0x81/0xe0 [ ... ] Reported-by: [email protected] Fixes: 4c2d5e33dcd3 ("hsr: rename debugfs file when interface name is changed") Signed-off-by: Taehee Yoo <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2019-12-30net/sched: add delete_empty() to filters and use it in cls_flowerDavide Caratti4-51/+22
Revert "net/sched: cls_u32: fix refcount leak in the error path of u32_change()", and fix the u32 refcount leak in a more generic way that preserves the semantic of rule dumping. On tc filters that don't support lockless insertion/removal, there is no need to guard against concurrent insertion when a removal is in progress. Therefore, for most of them we can avoid a full walk() when deleting, and just decrease the refcount, like it was done on older Linux kernels. This fixes situations where walk() was wrongly detecting a non-empty filter, like it happened with cls_u32 in the error path of change(), thus leading to failures in the following tdc selftests: 6aa7: (filter, u32) Add/Replace u32 with source match and invalid indev 6658: (filter, u32) Add/Replace u32 with custom hash table and invalid handle 74c2: (filter, u32) Add/Replace u32 filter with invalid hash table id On cls_flower, and on (future) lockless filters, this check is necessary: move all the check_empty() logic in a callback so that each filter can have its own implementation. For cls_flower, it's sufficient to check if no IDRs have been allocated. This reverts commit 275c44aa194b7159d1191817b20e076f55f0e620. Changes since v1: - document the need for delete_empty() when TCF_PROTO_OPS_DOIT_UNLOCKED is used, thanks to Vlad Buslov - implement delete_empty() without doing fl_walk(), thanks to Vlad Buslov - squash revert and new fix in a single patch, to be nice with bisect tests that run tdc on u32 filter, thanks to Dave Miller Fixes: 275c44aa194b ("net/sched: cls_u32: fix refcount leak in the error path of u32_change()") Fixes: 6676d5e416ee ("net: sched: set dedicated tcf_walker flag when tp is empty") Suggested-by: Jamal Hadi Salim <[email protected]> Suggested-by: Vlad Buslov <[email protected]> Signed-off-by: Davide Caratti <[email protected]> Reviewed-by: Vlad Buslov <[email protected]> Tested-by: Jamal Hadi Salim <[email protected]> Acked-by: Jamal Hadi Salim <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2019-12-30tcp: Fix highest_sack and highest_sack_seqCambda Zhu1-0/+3
>From commit 50895b9de1d3 ("tcp: highest_sack fix"), the logic about setting tp->highest_sack to the head of the send queue was removed. Of course the logic is error prone, but it is logical. Before we remove the pointer to the highest sack skb and use the seq instead, we need to set tp->highest_sack to NULL when there is no skb after the last sack, and then replace NULL with the real skb when new skb inserted into the rtx queue, because the NULL means the highest sack seq is tp->snd_nxt. If tp->highest_sack is NULL and new data sent, the next ACK with sack option will increase tp->reordering unexpectedly. This patch sets tp->highest_sack to the tail of the rtx queue if it's NULL and new data is sent. The patch keeps the rule that the highest_sack can only be maintained by sack processing, except for this only case. Fixes: 50895b9de1d3 ("tcp: highest_sack fix") Signed-off-by: Cambda Zhu <[email protected]> Signed-off-by: Eric Dumazet <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2019-12-30ptp: fix the race between the release of ptp_clock and cdevVladis Dronov4-44/+39
In a case when a ptp chardev (like /dev/ptp0) is open but an underlying device is removed, closing this file leads to a race. This reproduces easily in a kvm virtual machine: ts# cat openptp0.c int main() { ... fp = fopen("/dev/ptp0", "r"); ... sleep(10); } ts# uname -r 5.5.0-rc3-46cf053e ts# cat /proc/cmdline ... slub_debug=FZP ts# modprobe ptp_kvm ts# ./openptp0 & [1] 670 opened /dev/ptp0, sleeping 10s... ts# rmmod ptp_kvm ts# ls /dev/ptp* ls: cannot access '/dev/ptp*': No such file or directory ts# ...woken up [ 48.010809] general protection fault: 0000 [#1] SMP [ 48.012502] CPU: 6 PID: 658 Comm: openptp0 Not tainted 5.5.0-rc3-46cf053e #25 [ 48.014624] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), ... [ 48.016270] RIP: 0010:module_put.part.0+0x7/0x80 [ 48.017939] RSP: 0018:ffffb3850073be00 EFLAGS: 00010202 [ 48.018339] RAX: 000000006b6b6b6b RBX: 6b6b6b6b6b6b6b6b RCX: ffff89a476c00ad0 [ 48.018936] RDX: fffff65a08d3ea08 RSI: 0000000000000247 RDI: 6b6b6b6b6b6b6b6b [ 48.019470] ... ^^^ a slub poison [ 48.023854] Call Trace: [ 48.024050] __fput+0x21f/0x240 [ 48.024288] task_work_run+0x79/0x90 [ 48.024555] do_exit+0x2af/0xab0 [ 48.024799] ? vfs_write+0x16a/0x190 [ 48.025082] do_group_exit+0x35/0x90 [ 48.025387] __x64_sys_exit_group+0xf/0x10 [ 48.025737] do_syscall_64+0x3d/0x130 [ 48.026056] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 48.026479] RIP: 0033:0x7f53b12082f6 [ 48.026792] ... [ 48.030945] Modules linked in: ptp i6300esb watchdog [last unloaded: ptp_kvm] [ 48.045001] Fixing recursive fault but reboot is needed! This happens in: static void __fput(struct file *file) { ... if (file->f_op->release) file->f_op->release(inode, file); <<< cdev is kfree'd here if (unlikely(S_ISCHR(inode->i_mode) && inode->i_cdev != NULL && !(mode & FMODE_PATH))) { cdev_put(inode->i_cdev); <<< cdev fields are accessed here Namely: __fput() posix_clock_release() kref_put(&clk->kref, delete_clock) <<< the last reference delete_clock() delete_ptp_clock() kfree(ptp) <<< cdev is embedded in ptp cdev_put module_put(p->owner) <<< *p is kfree'd, bang! Here cdev is embedded in posix_clock which is embedded in ptp_clock. The race happens because ptp_clock's lifetime is controlled by two refcounts: kref and cdev.kobj in posix_clock. This is wrong. Make ptp_clock's sysfs device a parent of cdev with cdev_device_add() created especially for such cases. This way the parent device with its ptp_clock is not released until all references to the cdev are released. This adds a requirement that an initialized but not exposed struct device should be provided to posix_clock_register() by a caller instead of a simple dev_t. This approach was adopted from the commit 72139dfa2464 ("watchdog: Fix the race between the release of watchdog_core_data and cdev"). See details of the implementation in the commit 233ed09d7fda ("chardev: add helper function to register char devs with a struct device"). Link: https://lore.kernel.org/linux-fsdevel/[email protected]/T/#u Analyzed-by: Stephen Johnston <[email protected]> Analyzed-by: Vern Lovejoy <[email protected]> Signed-off-by: Vladis Dronov <[email protected]> Acked-by: Richard Cochran <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2019-12-30net: dsa: sja1105: Reconcile the meaning of TPID and TPID2 for E/T and P/Q/R/SVladimir Oltean2-6/+9
For first-generation switches (SJA1105E and SJA1105T): - TPID means C-Tag (typically 0x8100) - TPID2 means S-Tag (typically 0x88A8) While for the second generation switches (SJA1105P, SJA1105Q, SJA1105R, SJA1105S) it is the other way around: - TPID means S-Tag (typically 0x88A8) - TPID2 means C-Tag (typically 0x8100) In other words, E/T tags untagged traffic with TPID, and P/Q/R/S with TPID2. So the patch mentioned below fixed VLAN filtering for P/Q/R/S, but broke it for E/T. We strive for a common code path for all switches in the family, so just lie in the static config packing functions that TPID and TPID2 are at swapped bit offsets than they actually are, for P/Q/R/S. This will make both switches understand TPID to be ETH_P_8021Q and TPID2 to be ETH_P_8021AD. The meaning from the original E/T was chosen over P/Q/R/S because E/T is actually the one with public documentation available (UM10944.pdf). Fixes: f9a1a7646c0d ("net: dsa: sja1105: Reverse TPID and TPID2") Signed-off-by: Vladimir Oltean <[email protected]> Signed-off-by: David S. Miller <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.