aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2020-05-23sh: include linux/time_types.h for sockiosArnd Bergmann1-0/+2
Using the socket ioctls on arch/sh (and only there) causes build time problems when __kernel_old_timeval/__kernel_old_timespec are not already visible to the compiler. Add an explict include line for the header that defines these structures. Fixes: 8c709f9a0693 ("y2038: sh: remove timeval/timespec usage from headers") Fixes: 0768e17073dc ("net: socket: implement 64-bit timestamps") Reported-by: John Paul Adrian Glaubitz <[email protected]> Signed-off-by: Arnd Bergmann <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Tested-by: John Paul Adrian Glaubitz <[email protected]> Cc: Yoshinori Sato <[email protected]> Cc: Rich Felker <[email protected]> Cc: "David S. Miller" <[email protected]> Cc: John Paul Adrian Glaubitz <[email protected]> Cc: <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Linus Torvalds <[email protected]>
2020-05-23kasan: disable branch tracing for core runtimeMarco Elver3-10/+8
During early boot, while KASAN is not yet initialized, it is possible to enter reporting code-path and end up in kasan_report(). While uninitialized, the branch there prevents generating any reports, however, under certain circumstances when branches are being traced (TRACE_BRANCH_PROFILING), we may recurse deep enough to cause kernel reboots without warning. To prevent similar issues in future, we should disable branch tracing for the core runtime. [[email protected]: remove duplicate DISABLE_BRANCH_PROFILING, per Qian Cai] Link: https://lore.kernel.org/lkml/20200517011732.GE24705@shao2-debian/ Link: http://lkml.kernel.org/r/[email protected] Reported-by: kernel test robot <[email protected]> Signed-off-by: Marco Elver <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Reviewed-by: Andrey Konovalov <[email protected]> Cc: Dmitry Vyukov <[email protected]> Cc: Alexander Potapenko <[email protected]> Cc: Andrey Ryabinin <[email protected]> Cc: Qian Cai <[email protected]> Cc: <[email protected]> Link: http://lkml.kernel.org/r//20200517011732.GE24705@shao2-debian/ Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Linus Torvalds <[email protected]>
2020-05-23selftests/vm/write_to_hugetlbfs.c: fix unused variable warningJohn Hubbard1-2/+0
Remove unused variable "i", which was triggering a compiler warning. Fixes: 29750f71a9b4 ("hugetlb_cgroup: add hugetlb_cgroup reservation tests") Signed-off-by: John Hubbard <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Reviewed-By: Mina Almasry <[email protected]> Cc: Brian Geffon <[email protected]> Cc: "Kirill A . Shutemov" <[email protected]> Cc: Shuah Khan <[email protected]> Cc: Ralph Campbell <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Linus Torvalds <[email protected]>
2020-05-23selftests/vm/.gitignore: add mremap_dontunmapJohn Hubbard1-0/+1
Add mremap_dontunmap to .gitignore. Fixes: 0c28759ee3c9 ("selftests: add MREMAP_DONTUNMAP selftest") Signed-off-by: John Hubbard <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Cc: Kirill A. Shutemov <[email protected]> Cc: Brian Geffon <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Linus Torvalds <[email protected]>
2020-05-23rapidio: fix an error in get_user_pages_fast() error handlingJohn Hubbard1-0/+5
In the case of get_user_pages_fast() returning fewer pages than requested, rio_dma_transfer() does not quite do the right thing. It attempts to release all the pages that were requested, rather than just the pages that were pinned. Fix the error handling so that only the pages that were successfully pinned are released. Fixes: e8de370188d0 ("rapidio: add mport char device driver") Signed-off-by: John Hubbard <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Reviewed-by: Andrew Morton <[email protected]> Cc: Matt Porter <[email protected]> Cc: Alexandre Bounine <[email protected]> Cc: Sumit Semwal <[email protected]> Cc: Dan Carpenter <[email protected]> Cc: <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Linus Torvalds <[email protected]>
2020-05-23x86: bitops: fix build regressionNick Desaulniers1-6/+6
This is easily reproducible via CC=clang + CONFIG_STAGING=y + CONFIG_VT6656=m. It turns out that if your config tickles __builtin_constant_p via differences in choices to inline or not, these statements produce invalid assembly: $ cat foo.c long a(long b, long c) { asm("orb %1, %0" : "+q"(c): "r"(b)); return c; } $ gcc foo.c foo.c: Assembler messages: foo.c:2: Error: `%rax' not allowed with `orb' Use the `%b` "x86 Operand Modifier" to instead force register allocation to select a lower-8-bit GPR operand. The "q" constraint only has meaning on -m32 otherwise is treated as "r". Not all GPRs have low-8-bit aliases for -m32. Fixes: 1651e700664b4 ("x86: Fix bitops.h warning with a moved cast") Reported-by: kernelci.org bot <[email protected]> Suggested-by: Andy Shevchenko <[email protected]> Suggested-by: Brian Gerst <[email protected]> Suggested-by: H. Peter Anvin <[email protected]> Suggested-by: Ilie Halip <[email protected]> Signed-off-by: Nick Desaulniers <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Tested-by: Sedat Dilek <[email protected]> Tested-by: Nathan Chancellor <[email protected]> [build, clang-11] Reviewed-by: Nathan Chancellor <[email protected]> Reviewed-By: Brian Gerst <[email protected]> Reviewed-by: Jesse Brandeburg <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: Borislav Petkov <[email protected]> Cc: Marco Elver <[email protected]> Cc: "Paul E. McKenney" <[email protected]> Cc: Andrey Ryabinin <[email protected]> Cc: Luc Van Oostenryck <[email protected]> Cc: Masahiro Yamada <[email protected]> Cc: Daniel Axtens <[email protected]> Cc: "Peter Zijlstra (Intel)" <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Link: https://github.com/ClangBuiltLinux/linux/issues/961 Link: https://lore.kernel.org/lkml/[email protected]/ Link: https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html#x86Operandmodifiers Signed-off-by: Linus Torvalds <[email protected]>
2020-05-23device-dax: don't leak kernel memory to user space after unloading kmemDavid Hildenbrand1-3/+11
Assume we have kmem configured and loaded: [root@localhost ~]# cat /proc/iomem ... 140000000-33fffffff : Persistent Memory$ 140000000-1481fffff : namespace0.0 150000000-33fffffff : dax0.0 150000000-33fffffff : System RAM Assume we try to unload kmem. This force-unloading will work, even if memory cannot get removed from the system. [root@localhost ~]# rmmod kmem [ 86.380228] removing memory fails, because memory [0x0000000150000000-0x0000000157ffffff] is onlined ... [ 86.431225] kmem dax0.0: DAX region [mem 0x150000000-0x33fffffff] cannot be hotremoved until the next reboot Now, we can reconfigure the namespace: [root@localhost ~]# ndctl create-namespace --force --reconfig=namespace0.0 --mode=devdax [ 131.409351] nd_pmem namespace0.0: could not reserve region [mem 0x140000000-0x33fffffff]dax [ 131.410147] nd_pmem: probe of namespace0.0 failed with error -16namespace0.0 --mode=devdax ... This fails as expected due to the busy memory resource, and the memory cannot be used. However, the dax0.0 device is removed, and along its name. The name of the memory resource now points at freed memory (name of the device): [root@localhost ~]# cat /proc/iomem ... 140000000-33fffffff : Persistent Memory 140000000-1481fffff : namespace0.0 150000000-33fffffff : �_�^7_��/_��wR��WQ���^��� ... 150000000-33fffffff : System RAM We have to make sure to duplicate the string. While at it, remove the superfluous setting of the name and fixup a stale comment. Fixes: 9f960da72b25 ("device-dax: "Hotremove" persistent memory that is used like normal RAM") Signed-off-by: David Hildenbrand <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Cc: Dan Williams <[email protected]> Cc: Vishal Verma <[email protected]> Cc: Dave Jiang <[email protected]> Cc: Pavel Tatashin <[email protected]> Cc: Andrew Morton <[email protected]> Cc: <[email protected]> [5.3] Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Linus Torvalds <[email protected]>
2020-05-23Revert "kobject: Make sure the parent does not get released before its children"Greg Kroah-Hartman1-20/+10
This reverts commit 4ef12f7198023c09ad6d25b652bd8748c965c7fa. Guenter reports: All my arm64be (arm64 big endian) boot tests crash with this patch applied. Reverting it fixes the problem. Crash log and bisect results (from pending-fixes branch) below. And also: arm64 images don't crash but report lots of "poison overwritten" backtraces like the one below. On arm, I see "refcount_t: underflow", also attached. I didn't bisect those, but given the context I would suspect the same culprit. Reported-by: Guenter Roeck <[email protected]> Link: https://lore.kernel.org/r/[email protected] Cc: Naresh Kamboju <[email protected]> Cc: kernel test robot <[email protected]> Cc: "Rafael J. Wysocki" <[email protected]> Cc: Heikki Krogerus <[email protected]> Cc: Brendan Higgins <[email protected]> Cc: Randy Dunlap <[email protected]> Cc: stable <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-05-22Merge tag 'scsi-fixes' of ↵Linus Torvalds3-5/+9
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi Pull SCSI fixes from James Bottomley: "Three minor fixes, two in drivers, one to fix a hang after reset with iSCSI, and one to avoid a spurious log message; and the final core one to correct a suspend/resume miscount with quiesced devices" * tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi: scsi: target: Put lun_ref at end of tmr processing scsi: pm: Balance pm_only counter of request queue during system resume scsi: qla2xxx: Do not log message when reading port speed via sysfs
2020-05-22Merge tag 'drm-fixes-2020-05-23' of git://anongit.freedesktop.org/drm/drmLinus Torvalds25-103/+137
Pull drm fixes from Dave Airlie: "Things seemed to have quieten down, though no i915 pull (I even gave them an extra 12 hours in case they were late). The amdgpu floating point fix is probably the largest, but it just moves some code around to it doesn't do fpu stuff outside the fpu boundaries. Otherwise it's just a couple of vmwgfx fixes (maintainer change) and two etnaviv fixes. vmwgfx: - change maintainers - fix redundant assignment - fix parameter name - fix return value etnaviv: - memory leak fix when userspace passes a invalid softpin address - off-by-one crashing the kernel in the perfmon domain iteration when the GPU core has both 2D and 3D capabilities amdgpu: - DP fix - Floating point fix - Fix cursor stutter issue" * tag 'drm-fixes-2020-05-23' of git://anongit.freedesktop.org/drm/drm: drm/amd/display: Defer cursor lock until after VUPDATE drm/amd/display: Remove dml_common_def file drm/amd/display: DP training to set properly SCRAMBLING_DISABLE drm/edid: Add Oculus Rift S to non-desktop list drm/etnaviv: Fix a leak in submit_pin_objects() drm/etnaviv: fix perfmon domain interation drm/vmwgfx: Return true in function vmw_fence_obj_signaled() drm/vmwgfx: remove redundant assignment to variable ret drm/vmwgfx: Fix parameter name in vmw_bo_init drm/vmwgfx: update MAINTAINERS entry
2020-05-22net/mlx5: Fix error flow in case of function_setup failureShay Drory1-1/+2
Currently, if an error occurred during mlx5_function_setup(), we keep dev->state as DEVICE_STATE_UP. Fixing it by adding a goto label. Fixes: e161105e58da ("net/mlx5: Function setup/teardown procedures") Signed-off-by: Shay Drory <[email protected]> Reviewed-by: Moshe Shemesh <[email protected]> Signed-off-by: Saeed Mahameed <[email protected]>
2020-05-22net/mlx5e: CT: Correctly get flow ruleRoi Dayan2-3/+6
The correct way is to us the flow_cls_offload_flow_rule() wrapper instead of f->rule directly. Fixes: 4c3844d9e97e ("net/mlx5e: CT: Introduce connection tracking") Signed-off-by: Roi Dayan <[email protected]> Reviewed-by: Oz Shlomo <[email protected]> Signed-off-by: Saeed Mahameed <[email protected]>
2020-05-22net/mlx5e: Update netdev txq on completions during closureMoshe Shemesh1-3/+6
On sq closure when we free its descriptors, we should also update netdev txq on completions which would not arrive. Otherwise if we reopen sqs and attach them back, for example on fw fatal recovery flow, we may get tx timeout. Fixes: 29429f3300a3 ("net/mlx5e: Timeout if SQ doesn't flush during close") Signed-off-by: Moshe Shemesh <[email protected]> Reviewed-by: Tariq Toukan <[email protected]> Signed-off-by: Saeed Mahameed <[email protected]>
2020-05-22net/mlx5: Annotate mutex destroy for root nsRoi Dayan1-0/+6
Invoke mutex_destroy() to catch any errors. Fixes: 2cc43b494a6c ("net/mlx5_core: Managing root flow table") Signed-off-by: Roi Dayan <[email protected]> Reviewed-by: Mark Bloch <[email protected]> Signed-off-by: Saeed Mahameed <[email protected]>
2020-05-22net/mlx5: Don't maintain a case of del_sw_func being nullRoi Dayan1-8/+9
Add del_sw_func cb for root ns. Now there is no need to maintain a case of del_sw_func being null when freeing the node. Fixes: 2cc43b494a6c ("net/mlx5_core: Managing root flow table") Signed-off-by: Roi Dayan <[email protected]> Reviewed-by: Mark Bloch <[email protected]> Reviewed-by: Paul Blakey <[email protected]> Signed-off-by: Saeed Mahameed <[email protected]>
2020-05-22net/mlx5: Fix cleaning unmanaged flow tablesRoi Dayan1-5/+6
Unmanaged flow tables doesn't have a parent and tree_put_node() assume there is always a parent if cleaning is needed. fix that. Fixes: 5281a0c90919 ("net/mlx5: fs_core: Introduce unmanaged flow tables") Signed-off-by: Roi Dayan <[email protected]> Reviewed-by: Mark Bloch <[email protected]> Reviewed-by: Paul Blakey <[email protected]> Signed-off-by: Saeed Mahameed <[email protected]>
2020-05-22net/mlx5: Fix memory leak in mlx5_events_initMoshe Shemesh1-1/+3
Fix memory leak in mlx5_events_init(), in case create_single_thread_workqueue() fails, events struct should be freed. Fixes: 5d3c537f9070 ("net/mlx5: Handle event of power detection in the PCIE slot") Signed-off-by: Moshe Shemesh <[email protected]> Reviewed-by: Tariq Toukan <[email protected]> Signed-off-by: Saeed Mahameed <[email protected]>
2020-05-22net/mlx5e: Fix inner tirs handlingRoi Dayan4-10/+12
In the cited commit inner_tirs argument was added to create and destroy inner tirs, and no indication was added to mlx5e_modify_tirs_hash() function. In order to have a consistent handling, use inner_indir_tir[0].tirn in tirs destroy/modify function as an indication to whether inner tirs are created. Inner tirs are not created for representors and before this commit, a call to mlx5e_modify_tirs_hash() was sending HW commands to modify non-existent inner tirs. Fixes: 46dc933cee82 ("net/mlx5e: Provide explicit directive if to create inner indirect tirs") Signed-off-by: Roi Dayan <[email protected]> Reviewed-by: Vlad Buslov <[email protected]> Signed-off-by: Saeed Mahameed <[email protected]>
2020-05-22net/mlx5e: kTLS, Destroy key object after destroying the TISTariq Toukan1-1/+1
The TLS TIS object contains the dek/key ID. By destroying the key first, the TIS would contain an invalid non-existing key ID. Reverse the destroy order, this also acheives the desired assymetry between the destroy and the create flows. Fixes: d2ead1f360e8 ("net/mlx5e: Add kTLS TX HW offload support") Signed-off-by: Tariq Toukan <[email protected]> Reviewed-by: Boris Pismenny <[email protected]> Signed-off-by: Saeed Mahameed <[email protected]>
2020-05-22net/mlx5e: Fix allowed tc redirect merged eswitch offload casesMaor Dickman3-14/+41
After changing the parent_id to be the same for both NICs of same The cited commit wrongly allow offload of tc redirect flows from VF to uplink and vice versa when devcies are on different eswitch, these cases aren't supported by HW. Disallow the above offloads when devcies are on different eswitch and VF LAG is not configured. Fixes: f6dc1264f1c0 ("net/mlx5e: Disallow tc redirect offload cases we don't support") Signed-off-by: Maor Dickman <[email protected]> Reviewed-by: Roi Dayan <[email protected]> Signed-off-by: Saeed Mahameed <[email protected]>
2020-05-22net/mlx5: Avoid processing commands before cmdif is readyEran Ben Elisha3-0/+23
When driver is reloading during recovery flow, it can't get new commands till command interface is up again. Otherwise we may get to null pointer trying to access non initialized command structures. Add cmdif state to avoid processing commands while cmdif is not ready. Fixes: e126ba97dba9 ("mlx5: Add driver for Mellanox Connect-IB adapters") Signed-off-by: Eran Ben Elisha <[email protected]> Signed-off-by: Moshe Shemesh <[email protected]> Signed-off-by: Saeed Mahameed <[email protected]>
2020-05-22net/mlx5: Fix a race when moving command interface to events modeEran Ben Elisha3-4/+40
After driver creates (via FW command) an EQ for commands, the driver will be informed on new commands completion by EQE. However, due to a race in driver's internal command mode metadata update, some new commands will still be miss-handled by driver as if we are in polling mode. Such commands can get two non forced completion, leading to already freed command entry access. CREATE_EQ command, that maps EQ to the command queue must be posted to the command queue while it is empty and no other command should be posted. Add SW mechanism that once the CREATE_EQ command is about to be executed, all other commands will return error without being sent to the FW. Allow sending other commands only after successfully changing the driver's internal command mode metadata. We can safely return error to all other commands while creating the command EQ, as all other commands might be sent from the user/application during driver load. Application can rerun them later after driver's load was finished. Fixes: e126ba97dba9 ("mlx5: Add driver for Mellanox Connect-IB adapters") Signed-off-by: Eran Ben Elisha <[email protected]> Signed-off-by: Moshe Shemesh <[email protected]> Signed-off-by: Saeed Mahameed <[email protected]>
2020-05-22net/mlx5: Add command entry handling completionMoshe Shemesh2-0/+15
When FW response to commands is very slow and all command entries in use are waiting for completion we can have a race where commands can get timeout before they get out of the queue and handled. Timeout completion on uninitialized command will cause releasing command's buffers before accessing it for initialization and then we will get NULL pointer exception while trying access it. It may also cause releasing buffers of another command since we may have timeout completion before even allocating entry index for this command. Add entry handling completion to avoid this race. Fixes: e126ba97dba9 ("mlx5: Add driver for Mellanox Connect-IB adapters") Signed-off-by: Moshe Shemesh <[email protected]> Signed-off-by: Eran Ben Elisha <[email protected]> Signed-off-by: Saeed Mahameed <[email protected]>
2020-05-22Merge tag 'rxrpc-fixes-20200523-v2' of ↵David S. Miller2-3/+2
git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs David Howells says: ==================== rxrpc: Fix a warning and a leak [ver #2] Here are a couple of fixes for AF_RXRPC: (1) Fix an uninitialised variable warning. (2) Fix a leak of the ticket on error in rxkad. ==================== Signed-off-by: David S. Miller <[email protected]>
2020-05-23rxrpc: Fix a memory leak in rxkad_verify_response()Qiushi Wu1-2/+1
A ticket was not released after a call of the function "rxkad_decrypt_ticket" failed. Thus replace the jump target "temporary_error_free_resp" by "temporary_error_free_ticket". Fixes: 8c2f826dc3631 ("rxrpc: Don't put crypto buffers on the stack") Signed-off-by: Qiushi Wu <[email protected]> Signed-off-by: David Howells <[email protected]> cc: Markus Elfring <[email protected]>
2020-05-23rxrpc: Fix a warningDavid Howells1-1/+1
Fix a warning due to an uninitialised variable. le included from ../fs/afs/fs_probe.c:11: ../fs/afs/fs_probe.c: In function 'afs_fileserver_probe_result': ../fs/afs/internal.h:1453:2: warning: 'rtt_us' may be used uninitialized in this function [-Wmaybe-uninitialized] 1453 | printk("[%-6.6s] "FMT"\n", current->comm ,##__VA_ARGS__) | ^~~~~~ ../fs/afs/fs_probe.c:35:15: note: 'rtt_us' was declared here Signed-off-by: David Howells <[email protected]>
2020-05-22net: sun: fix missing release regions in cas_init_one().Qiushi Wu1-2/+1
In cas_init_one(), "pdev" is requested by "pci_request_regions", but it was not released after a call of the function “pci_write_config_byte” failed. Thus replace the jump target “err_write_cacheline” by "err_out_free_res". Fixes: 1f26dac32057 ("[NET]: Add Sun Cassini driver.") Signed-off-by: Qiushi Wu <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-05-22net: mscc: ocelot: fix address ageing time (again)Vladimir Oltean1-1/+1
ocelot_set_ageing_time has 2 callers: - felix_set_ageing_time: from drivers/net/dsa/ocelot/felix.c - ocelot_port_attr_ageing_set: from drivers/net/ethernet/mscc/ocelot.c The issue described in the fixed commit below actually happened for the felix_set_ageing_time code path only, since ocelot_port_attr_ageing_set was already dividing by 1000. So to make both paths symmetrical (and to fix addresses getting aged way too fast on Ocelot), stop dividing by 1000 at caller side altogether. Fixes: c0d7eccbc761 ("net: mscc: ocelot: ANA_AUTOAGE_AGE_PERIOD holds a value in seconds, not ms") Signed-off-by: Vladimir Oltean <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-05-22r8169: fix OCP access on RTL8117Heiner Kallweit1-2/+15
According to r8168 vendor driver DASHv3 chips like RTL8168fp/RTL8117 need a special addressing for OCP access. Fix is compile-tested only due to missing test hardware. Fixes: 1287723aa139 ("r8169: add support for RTL8117") Signed-off-by: Heiner Kallweit <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-05-22Merge branch 'mlxsw-Various-fixes'David S. Miller3-3/+21
Ido Schimmel says: ==================== mlxsw: Various fixes Patch #1 from Jiri fixes a use-after-free discovered while fuzzing mlxsw / devlink with syzkaller. Patch #2 from Amit works around a limitation in new versions of arping, which is used in several selftests. ==================== Signed-off-by: David S. Miller <[email protected]>
2020-05-22selftests: mlxsw: qos_mc_aware: Specify arping timeout as an integerAmit Cohen1-1/+1
Starting from iputils s20190709 (used in Fedora 31), arping does not support timeout being specified as a decimal: $ arping -c 1 -I swp1 -b 192.0.2.66 -q -w 0.1 arping: invalid argument: '0.1' Previously, such timeouts were rounded to an integer. Fix this by specifying the timeout as an integer. Fixes: a5ee171d087e ("selftests: mlxsw: qos_mc_aware: Add a test for UC awareness") Signed-off-by: Amit Cohen <[email protected]> Reviewed-by: Petr Machata <[email protected]> Signed-off-by: Ido Schimmel <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-05-22mlxsw: spectrum: Fix use-after-free of split/unsplit/type_set in case reload ↵Jiri Pirko2-2/+20
fails In case of reload fail, the mlxsw_sp->ports contains a pointer to a freed memory (either by reload_down() or reload_up() error path). Fix this by initializing the pointer to NULL and checking it before dereferencing in split/unsplit/type_set callpaths. Fixes: 24cc68ad6c46 ("mlxsw: core: Add support for reload") Reported-by: Danielle Ratson <[email protected]> Signed-off-by: Jiri Pirko <[email protected]> Signed-off-by: Ido Schimmel <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-05-22net: ethernet: stmmac: Enable interface clocks on probe for IPQ806xJonathan McDowell1-0/+13
The ipq806x_gmac_probe() function enables the PTP clock but not the appropriate interface clocks. This means that if the bootloader hasn't done so attempting to bring up the interface will fail with an error like: [ 59.028131] ipq806x-gmac-dwmac 37600000.ethernet: Failed to reset the dma [ 59.028196] ipq806x-gmac-dwmac 37600000.ethernet eth1: stmmac_hw_setup: DMA engine initialization failed [ 59.034056] ipq806x-gmac-dwmac 37600000.ethernet eth1: stmmac_open: Hw setup failed This patch, a slightly cleaned up version of one posted by Sergey Sergeev in: https://forum.openwrt.org/t/support-for-mikrotik-rb3011uias-rm/4064/257 correctly enables the clock; we have already configured the source just before this. Tested on a MikroTik RB3011. Signed-off-by: Jonathan McDowell <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-05-22Merge branch 'netdevsim-Two-small-fixes'David S. Miller2-2/+5
Ido Schimmel says: ==================== netdevsim: Two small fixes Fix two bugs observed while analyzing regression failures. Patch #1 fixes a bug where sometimes the drop counter of a packet trap policer would not increase. Patch #2 adds a missing initialization of a variable in a related selftest. ==================== Signed-off-by: David S. Miller <[email protected]>
2020-05-22selftests: netdevsim: Always initialize 'RET' variableIdo Schimmel1-0/+4
The variable is used by log_test() to check if the test case completely successfully or not. In case it is not initialized at the start of a test case, it is possible for the test case to fail despite not encountering any errors. Example: ``` ... TEST: Trap group statistics [ OK ] TEST: Trap policer [FAIL] Policer drop counter was not incremented TEST: Trap policer binding [FAIL] Policer drop counter was not incremented ``` Failure of trap_policer_test() caused trap_policer_bind_test() to fail as well. Fix by adding missing initialization of the variable. Fixes: 5fbff58e27a1 ("selftests: netdevsim: Add test cases for devlink-trap policers") Signed-off-by: Ido Schimmel <[email protected]> Reviewed-by: Jiri Pirko <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-05-22netdevsim: Ensure policer drop counter always increasesIdo Schimmel1-2/+1
In case the policer drop counter is retrieved when the jiffies value is a multiple of 64, the counter will not be incremented. This randomly breaks a selftest [1] the reads the counter twice and checks that it was incremented: ``` TEST: Trap policer [FAIL] Policer drop counter was not incremented ``` Fix by always incrementing the counter by 1. [1] tools/testing/selftests/drivers/net/netdevsim/devlink_trap.sh Fixes: ad188458d012 ("netdevsim: Add devlink-trap policer support") Signed-off-by: Ido Schimmel <[email protected]> Reviewed-by: Jiri Pirko <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-05-22Merge tag 'rxrpc-fixes-20200520' of ↵David S. Miller17-159/+335
git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs David Howells says: ==================== rxrpc: Fix retransmission timeout and ACK discard Here are a couple of fixes and an extra tracepoint for AF_RXRPC: (1) Calculate the RTO pretty much as TCP does, rather than making something up, including an initial 4s timeout (which causes return probes from the fileserver to fail if a packet goes missing), and add backoff. (2) Fix the discarding of out-of-order received ACKs. We mustn't let the hard-ACK point regress, nor do we want to do unnecessary retransmission because the soft-ACK list regresses. This is not trivial, however, due to some loose wording in various old protocol specs, the ACK field that should be used for this sometimes has the wrong information in it. (3) Add a tracepoint to log a discarded ACK. ==================== Signed-off-by: David S. Miller <[email protected]>
2020-05-22net/ethernet/freescale: rework quiesce/activate for ucc_gethValentin Longchamp1-6/+7
ugeth_quiesce/activate are used to halt the controller when there is a link change that requires to reconfigure the mac. The previous implementation called netif_device_detach(). This however causes the initial activation of the netdevice to fail precisely because it's detached. For details, see [1]. A possible workaround was the revert of commit net: linkwatch: add check for netdevice being present to linkwatch_do_dev However, the check introduced in the above commit is correct and shall be kept. The netif_device_detach() is thus replaced with netif_tx_stop_all_queues() that prevents any tranmission. This allows to perform mac config change required by the link change, without detaching the corresponding netdevice and thus not preventing its initial activation. [1] https://lists.openwall.net/netdev/2020/01/08/201 Signed-off-by: Valentin Longchamp <[email protected]> Acked-by: Matteo Ghidoni <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-05-22sctp: Start shutdown on association restart if in SHUTDOWN-SENT state and ↵Jere Leppänen1-4/+5
socket is closed Commit bdf6fa52f01b ("sctp: handle association restarts when the socket is closed.") starts shutdown when an association is restarted, if in SHUTDOWN-PENDING state and the socket is closed. However, the rationale stated in that commit applies also when in SHUTDOWN-SENT state - we don't want to move an association to ESTABLISHED state when the socket has been closed, because that results in an association that is unreachable from user space. The problem scenario: 1. Client crashes and/or restarts. 2. Server (using one-to-one socket) calls close(). SHUTDOWN is lost. 3. Client reconnects using the same addresses and ports. 4. Server's association is restarted. The association and the socket move to ESTABLISHED state, even though the server process has closed its descriptor. Also, after step 4 when the server process exits, some resources are leaked in an attempt to release the underlying inet sock structure in ESTABLISHED state: IPv4: Attempt to release TCP socket in state 1 00000000377288c7 Fix by acting the same way as in SHUTDOWN-PENDING state. That is, if an association is restarted in SHUTDOWN-SENT state and the socket is closed, then start shutdown and don't move the association or the socket to ESTABLISHED state. Fixes: bdf6fa52f01b ("sctp: handle association restarts when the socket is closed.") Signed-off-by: Jere Leppänen <[email protected]> Acked-by: Marcelo Ricardo Leitner <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-05-22tipc: block BH before using dst_cacheEric Dumazet1-1/+5
dst_cache_get() documents it must be used with BH disabled. sysbot reported : BUG: using smp_processor_id() in preemptible [00000000] code: /21697 caller is dst_cache_get+0x3a/0xb0 net/core/dst_cache.c:68 CPU: 0 PID: 21697 Comm: Not tainted 5.7.0-rc6-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x188/0x20d lib/dump_stack.c:118 check_preemption_disabled lib/smp_processor_id.c:47 [inline] debug_smp_processor_id.cold+0x88/0x9b lib/smp_processor_id.c:57 dst_cache_get+0x3a/0xb0 net/core/dst_cache.c:68 tipc_udp_xmit.isra.0+0xb9/0xad0 net/tipc/udp_media.c:164 tipc_udp_send_msg+0x3e6/0x490 net/tipc/udp_media.c:244 tipc_bearer_xmit_skb+0x1de/0x3f0 net/tipc/bearer.c:526 tipc_enable_bearer+0xb2f/0xd60 net/tipc/bearer.c:331 __tipc_nl_bearer_enable+0x2bf/0x390 net/tipc/bearer.c:995 tipc_nl_bearer_enable+0x1e/0x30 net/tipc/bearer.c:1003 genl_family_rcv_msg_doit net/netlink/genetlink.c:673 [inline] genl_family_rcv_msg net/netlink/genetlink.c:718 [inline] genl_rcv_msg+0x627/0xdf0 net/netlink/genetlink.c:735 netlink_rcv_skb+0x15a/0x410 net/netlink/af_netlink.c:2469 genl_rcv+0x24/0x40 net/netlink/genetlink.c:746 netlink_unicast_kernel net/netlink/af_netlink.c:1303 [inline] netlink_unicast+0x537/0x740 net/netlink/af_netlink.c:1329 netlink_sendmsg+0x882/0xe10 net/netlink/af_netlink.c:1918 sock_sendmsg_nosec net/socket.c:652 [inline] sock_sendmsg+0xcf/0x120 net/socket.c:672 ____sys_sendmsg+0x6bf/0x7e0 net/socket.c:2362 ___sys_sendmsg+0x100/0x170 net/socket.c:2416 __sys_sendmsg+0xec/0x1b0 net/socket.c:2449 do_syscall_64+0xf6/0x7d0 arch/x86/entry/common.c:295 entry_SYSCALL_64_after_hwframe+0x49/0xb3 RIP: 0033:0x45ca29 Fixes: e9c1a793210f ("tipc: add dst_cache support for udp media") Cc: Xin Long <[email protected]> Cc: Jon Maloy <[email protected]> Signed-off-by: Eric Dumazet <[email protected]> Reported-by: syzbot <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-05-22net: mvpp2: fix RX hashing for non-10G portsRussell King1-1/+1
When rxhash is enabled on any ethernet port except the first in each CP block, traffic flow is prevented. The analysis is below: I've been investigating this afternoon, and what I've found, comparing a kernel without 895586d5dc32 and with 895586d5dc32 applied is: - The table programmed into the hardware via mvpp22_rss_fill_table() appears to be identical with or without the commit. - When rxhash is enabled on eth2, mvpp2_rss_port_c2_enable() reports that c2.attr[0] and c2.attr[2] are written back containing: - with 895586d5dc32, failing: 00200000 40000000 - without 895586d5dc32, working: 04000000 40000000 - When disabling rxhash, c2.attr[0] and c2.attr[2] are written back as: 04000000 00000000 The second value represents the MVPP22_CLS_C2_ATTR2_RSS_EN bit, the first value is the queue number, which comprises two fields. The high 5 bits are 24:29 and the low three are 21:23 inclusive. This comes from: c2.attr[0] = MVPP22_CLS_C2_ATTR0_QHIGH(qh) | MVPP22_CLS_C2_ATTR0_QLOW(ql); So, the working case gives eth2 a queue id of 4.0, or 32 as per port->first_rxq, and the non-working case a queue id of 0.1, or 1. The allocation of queue IDs seems to be in mvpp2_port_probe(): if (priv->hw_version == MVPP21) port->first_rxq = port->id * port->nrxqs; else port->first_rxq = port->id * priv->max_port_rxqs; Where: if (priv->hw_version == MVPP21) priv->max_port_rxqs = 8; else priv->max_port_rxqs = 32; Making the port 0 (eth0 / eth1) have port->first_rxq = 0, and port 1 (eth2) be 32. It seems the idea is that the first 32 queues belong to port 0, the second 32 queues belong to port 1, etc. mvpp2_rss_port_c2_enable() gets the queue number from it's parameter, 'ctx', which comes from mvpp22_rss_ctx(port, 0). This returns port->rss_ctx[0]. mvpp22_rss_context_create() is responsible for allocating that, which it does by looking for an unallocated priv->rss_tables[] pointer. This table is shared amongst all ports on the CP silicon. When we write the tables in mvpp22_rss_fill_table(), the RSS table entry is defined by: u32 sel = MVPP22_RSS_INDEX_TABLE(rss_ctx) | MVPP22_RSS_INDEX_TABLE_ENTRY(i); where rss_ctx is the context ID (queue number) and i is the index in the table. If we look at what is written: - The first table to be written has "sel" values of 00000000..0000001f, containing values 0..3. This appears to be for eth1. This is table 0, RX queue number 0. - The second table has "sel" values of 00000100..0000011f, and appears to be for eth2. These contain values 0x20..0x23. This is table 1, RX queue number 0. - The third table has "sel" values of 00000200..0000021f, and appears to be for eth3. These contain values 0x40..0x43. This is table 2, RX queue number 0. How do queue numbers translate to the RSS table? There is another table - the RXQ2RSS table, indexed by the MVPP22_RSS_INDEX_QUEUE field of MVPP22_RSS_INDEX and accessed through the MVPP22_RXQ2RSS_TABLE register. Before 895586d5dc32, it was: mvpp2_write(priv, MVPP22_RSS_INDEX, MVPP22_RSS_INDEX_QUEUE(port->first_rxq)); mvpp2_write(priv, MVPP22_RXQ2RSS_TABLE, MVPP22_RSS_TABLE_POINTER(port->id)); and after: mvpp2_write(priv, MVPP22_RSS_INDEX, MVPP22_RSS_INDEX_QUEUE(ctx)); mvpp2_write(priv, MVPP22_RXQ2RSS_TABLE, MVPP22_RSS_TABLE_POINTER(ctx)); Before the commit, for eth2, that would've contained '32' for the index and '1' for the table pointer - mapping queue 32 to table 1. Remember that this is queue-high.queue-low of 4.0. After the commit, we appear to map queue 1 to table 1. That again looks fine on the face of it. Section 9.3.1 of the A8040 manual seems indicate the reason that the queue number is separated. queue-low seems to always come from the classifier, whereas queue-high can be from the ingress physical port number or the classifier depending on the MVPP2_CLS_SWFWD_PCTRL_REG. We set the port bit in MVPP2_CLS_SWFWD_PCTRL_REG, meaning that queue-high comes from the MVPP2_CLS_SWFWD_P2HQ_REG() register... and this seems to be where our bug comes from. mvpp2_cls_oversize_rxq_set() sets this up as: mvpp2_write(port->priv, MVPP2_CLS_SWFWD_P2HQ_REG(port->id), (port->first_rxq >> MVPP2_CLS_OVERSIZE_RXQ_LOW_BITS)); val = mvpp2_read(port->priv, MVPP2_CLS_SWFWD_PCTRL_REG); val |= MVPP2_CLS_SWFWD_PCTRL_MASK(port->id); mvpp2_write(port->priv, MVPP2_CLS_SWFWD_PCTRL_REG, val); Setting the MVPP2_CLS_SWFWD_PCTRL_MASK bit means that the queue-high for eth2 is _always_ 4, so only queues 32 through 39 inclusive are available to eth2. Yet, we're trying to tell the classifier to set queue-high, which will be ignored, to zero. Hence, the queue-high field (MVPP22_CLS_C2_ATTR0_QHIGH()) from the classifier will be ignored. This means we end up directing traffic from eth2 not to queue 1, but to queue 33, and then we tell it to look up queue 33 in the RSS table. However, RSS table has not been programmed for queue 33, and so it ends up (presumably) dropping the packets. It seems that mvpp22_rss_context_create() doesn't take account of the fact that the upper 5 bits of the queue ID can't actually be changed due to the settings in mvpp2_cls_oversize_rxq_set(), _or_ it seems that mvpp2_cls_oversize_rxq_set() has been missed in this commit. Either way, these two functions mutually disagree with what queue number should be used. Looking deeper into what mvpp2_cls_oversize_rxq_set() and the MTU validation is doing, it seems that MVPP2_CLS_SWFWD_P2HQ_REG() is used for over-sized packets attempting to egress through this port. With the classifier having had RSS enabled and directing eth2 traffic to queue 1, we may still have packets appearing on queue 32 for this port. However, the only way we may end up with over-sized packets attempting to egress through eth2 - is if the A8040 forwards frames between its ports. From what I can see, we don't support that feature, and the kernel restricts the egress packet size to the MTU. In any case, if we were to attempt to transmit an oversized packet, we have no support in the kernel to deal with that appearing in the port's receive queue. So, this patch attempts to solve the issue by clearing the MVPP2_CLS_SWFWD_PCTRL_MASK() bit, allowing MVPP22_CLS_C2_ATTR0_QHIGH() from the classifier to define the queue-high field of the queue number. My testing seems to confirm my findings above - clearing this bit means that if I enable rxhash on eth2, the interface can then pass traffic, as we are now directing traffic to RX queue 1 rather than queue 33. Traffic still seems to work with rxhash off as well. Reported-by: Matteo Croce <[email protected]> Tested-by: Matteo Croce <[email protected]> Fixes: 895586d5dc32 ("net: mvpp2: cls: Use RSS contexts to handle RSS tables") Signed-off-by: Russell King <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-05-22Merge git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpfDavid S. Miller5-11/+69
Daniel Borkmann says: ==================== pull-request: bpf 2020-05-22 The following pull-request contains BPF updates for your *net* tree. We've added 3 non-merge commits during the last 3 day(s) which contain a total of 5 files changed, 69 insertions(+), 11 deletions(-). The main changes are: 1) Fix to reject mmap()'ing read-only array maps as writable since BPF verifier relies on such map content to be frozen, from Andrii Nakryiko. 2) Fix breaking audit from secid_to_secctx() LSM hook by avoiding to use call_int_hook() since this hook is not stackable, from KP Singh. 3) Fix BPF flow dissector program ref leak on netns cleanup, from Jakub Sitnicki. ==================== Signed-off-by: David S. Miller <[email protected]>
2020-05-22felix: Fix initialization of ioremap resourcesClaudiu Manoil3-27/+24
The caller of devm_ioremap_resource(), either accidentally or by wrong assumption, is writing back derived resource data to global static resource initialization tables that should have been constant. Meaning that after it computes the final physical start address it saves the address for no reason in the static tables. This doesn't affect the first driver probing after reboot, but it breaks consecutive driver reloads (i.e. driver unbind & bind) because the initialization tables no longer have the correct initial values. So the next probe() will map the device registers to wrong physical addresses, causing ARM SError async exceptions. This patch fixes all of the above. Fixes: 56051948773e ("net: dsa: ocelot: add driver for Felix switch family") Signed-off-by: Claudiu Manoil <[email protected]> Reviewed-by: Vladimir Oltean <[email protected]> Tested-by: Vladimir Oltean <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-05-22mptcp: use untruncated hash in ADD_ADDR HMACTodd Malsbary4-25/+24
There is some ambiguity in the RFC as to whether the ADD_ADDR HMAC is the rightmost 64 bits of the entire hash or of the leftmost 160 bits of the hash. The intention, as clarified with the author of the RFC, is the entire hash. This change returns the entire hash from mptcp_crypto_hmac_sha (instead of only the first 160 bits), and moves any truncation/selection operation on the hash to the caller. Fixes: 12555a2d97e5 ("mptcp: use rightmost 64 bits in ADD_ADDR HMAC") Reviewed-by: Christoph Paasch <[email protected]> Reviewed-by: Mat Martineau <[email protected]> Signed-off-by: Todd Malsbary <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-05-22Merge tag 'io_uring-5.7-2020-05-22' of git://git.kernel.dk/linux-blockLinus Torvalds1-26/+34
Pull io_uring fixes from Jens Axboe: "A small collection of small fixes that should go into this release: - Two fixes for async request preparation (Pavel) - Busy clear fix for SQPOLL (Xiaoguang) - Don't use kiocb->private for O_DIRECT buf index, some file systems use it (Bijan) - Kill dead check in io_splice() - Ensure sqo_wait is initialized early - Cancel task_work if we fail adding to original process - Only add (IO)pollable requests to iopoll list, fixing a regression in this merge window" * tag 'io_uring-5.7-2020-05-22' of git://git.kernel.dk/linux-block: io_uring: reset -EBUSY error when io sq thread is waken up io_uring: don't add non-IO requests to iopoll pending list io_uring: don't use kiocb.private to store buf_index io_uring: cancel work if task_work_add() fails io_uring: remove dead check in io_splice() io_uring: fix FORCE_ASYNC req preparation io_uring: don't prepare DRAIN reqs twice io_uring: initialize ctx->sqo_wait earlier
2020-05-22Merge tag 'block-5.7-2020-05-22' of git://git.kernel.dk/linux-blockLinus Torvalds2-0/+11
Pull block fixes from Jens Axboe: "Two fixes for null_blk zone mode" * tag 'block-5.7-2020-05-22' of git://git.kernel.dk/linux-block: null_blk: don't allow discard for zoned mode null_blk: return error for invalid zone size
2020-05-22Merge tag 'riscv-for-linus-5.7-rc7' of ↵Linus Torvalds2-2/+2
git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux Pull RISC-V fixes from Palmer Dabbelt: "Two fixes: - Another !MMU build fix that was a straggler from last week - A fix to use the "register" keyword for the GP global register variable" * tag 'riscv-for-linus-5.7-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux: RISC-V: gp_in_global needs register keyword riscv: Fix print_vm_layout build error if NOMMU
2020-05-22Merge tag 'efi-fixes-for-v5.7-rc6' of ↵Borislav Petkov12-39/+124
git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi into efi/urgent Pull EFI fixes from Ard Biesheuvel: "- fix EFI framebuffer earlycon for wide fonts - avoid filling screen_info with garbage if the EFI framebuffer is not available - fix a potential host tool build error due to a symbol clash on x86 - work around a EFI firmware bug regarding the binary format of the TPM final events table - fix a missing memory free by reworking the E820 table sizing routine to not do the allocation in the first place - add CPER parsing for firmware errors"
2020-05-22x86/unwind/orc: Fix unwind_get_return_address_ptr() for inactive tasksJosh Poimboeuf1-0/+7
Normally, show_trace_log_lvl() scans the stack, looking for text addresses to print. In parallel, it unwinds the stack with unwind_next_frame(). If the stack address matches the pointer returned by unwind_get_return_address_ptr() for the current frame, the text address is printed normally without a question mark. Otherwise it's considered a breadcrumb (potentially from a previous call path) and it's printed with a question mark to indicate that the address is unreliable and typically can be ignored. Since the following commit: f1d9a2abff66 ("x86/unwind/orc: Don't skip the first frame for inactive tasks") ... for inactive tasks, show_trace_log_lvl() prints *only* unreliable addresses (prepended with '?'). That happens because, for the first frame of an inactive task, unwind_get_return_address_ptr() returns the wrong return address pointer: one word *below* the task stack pointer. show_trace_log_lvl() starts scanning at the stack pointer itself, so it never finds the first 'reliable' address, causing only guesses to being printed. The first frame of an inactive task isn't a normal stack frame. It's actually just an instance of 'struct inactive_task_frame' which is left behind by __switch_to_asm(). Now that this inactive frame is actually exposed to callers, fix unwind_get_return_address_ptr() to interpret it properly. Fixes: f1d9a2abff66 ("x86/unwind/orc: Don't skip the first frame for inactive tasks") Reported-by: Tetsuo Handa <[email protected]> Signed-off-by: Josh Poimboeuf <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Link: https://lkml.kernel.org/r/20200522135435.vbxs7umku5pyrdbk@treble
2020-05-22Merge tag 'arm64-fixes' of ↵Linus Torvalds2-4/+5
git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux Pull arm64 fixes from Catalin Marinas: - Bring the PTRACE_SYSEMU semantics in line with the man page. - Annotate variable assignment in get_user() with the type to avoid sparse warnings. * tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux: arm64: Add get_user() type annotation on the !access_ok() path arm64: Fix PTRACE_SYSEMU semantics