-
Notifications
You must be signed in to change notification settings - Fork 270
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[vimrc]: cscope: implement cnext/cprev shortcuts #78
Conversation
Use task_stack_page instead of p->stack to get stack. Follow the coding convention style. Also for init_stack, the same with other archs. Signed-off-by: Guo Ren <[email protected]>
Some user space drivers need accessing IO address and IO remap need SO(strong order) page-attribute to make IO operation correct. So we need add SO-page-attr for all non-memory address. Signed-off-by: Guo Ren <[email protected]> Reported-by: Fan Xiaodong <[email protected]>
When STACKTRACE is enabled, we must pass fp as stack for unwind, otherwise random value in stack will casue a dead loop. Signed-off-by: Guo Ren <[email protected]> Reported-by: Lu Baoquan <[email protected]>
…linux into drm-fixes drm/imx: plane, ldb, and ipu-v3 fixes - Fix CSI register offsets for i.MX51 and i.MX53. - Fix delayed page flip completion events on i.MX6QP due to unexpected behaviour of the PRE when issuing NOP buffer updates to the same buffer address. - Stop throwing errors for plane updates on disabled CRTCs when a userspace process is killed while a plane update is pending. - Add missing of_node_put cleanup in imx_ldb_bind. Signed-off-by: Dave Airlie <[email protected]> From: Philipp Zabel <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
The problem is that the default for MQ is not to gather entropy, whereas the default for the legacy queue was always to gather it. The original attempt to fix entropy gathering for rotational disks under MQ added an else branch in sd_read_block_characteristics(). Unfortunately, the entire check isn't reached if the device has no characteristics VPD page. Since this page was only introduced in SBC-3 and its optional anyway, most less expensive rotational disks don't have one, meaning they all stopped gathering entropy when we made MQ the default. In a wholly unrelated change, openssl and openssh won't function until the random number generator is initialised, meaning lots of people have been seeing large delays before they could log into systems with default MQ kernels due to this lack of entropy, because it now can take tens of minutes to initialise the kernel random number generator. The fix is to set the non-rotational and add-randomness flags unconditionally early on in the disk initialization path, so they can be reset only if the device actually reports being non-rotational via the VPD page. Reported-by: Mikael Pettersson <[email protected]> Fixes: 83e32a5 ("scsi: sd: Contribute to randomness when running rotational device") Cc: [email protected] Signed-off-by: James Bottomley <[email protected]> Reviewed-by: Jens Axboe <[email protected]> Reviewed-by: Xuewei Zhang <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]>
In qla2x00_async_tm_cmd, we reference off sp after it has been freed. This caused a panic on a system running a slub debug kernel. Since fcport is passed in anyways, just use that instead. Signed-off-by: Bill Kuzeja <[email protected]> Acked-by: Giridhar Malavali <[email protected]> Acked-by: Himanshu Madhani <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]>
The following commit: 9dff0aa ("perf/core: Don't WARN() for impossible ring-buffer sizes") results in perf recording failures with larger mmap areas: root@skl:/tmp# perf record -g -a failed to mmap with 12 (Cannot allocate memory) The root cause is that the following condition is buggy: if (order_base_2(size) >= MAX_ORDER) goto fail; The problem is that @SiZe is in bytes and MAX_ORDER is in pages, so the right test is: if (order_base_2(size) >= PAGE_SHIFT+MAX_ORDER) goto fail; Fix it. Reported-by: "Jin, Yao" <[email protected]> Bisected-by: Borislav Petkov <[email protected]> Analyzed-by: Peter Zijlstra <[email protected]> Cc: Julien Thierry <[email protected]> Cc: Mark Rutland <[email protected]> Cc: Alexander Shishkin <[email protected]> Cc: Arnaldo Carvalho de Melo <[email protected]> Cc: Jiri Olsa <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Namhyung Kim <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: Greg Kroah-Hartman <[email protected]> Cc: <[email protected]> Fixes: 9dff0aa ("perf/core: Don't WARN() for impossible ring-buffer sizes") Signed-off-by: Ingo Molnar <[email protected]>
Commit bb36489 ("mmc: meson-gx: Free irq in release() callback") changed the _probe code to use request_threaded_irq() instead of devm_request_threaded_irq(). Unfortunately this removes a fallback for the interrupt name: devm_request_threaded_irq() uses the device name as fallback if the given IRQ name is NULL. request_threaded_irq() has no such fallback, thus /proc/interrupts shows "(null)" instead. Explicitly pass the dev_name() so we get the IRQ name shown in /proc/interrupts again. While here, also fix the indentation of the request_threaded_irq() parameter list. Fixes: bb36489 ("mmc: meson-gx: Free irq in release() callback") Signed-off-by: Martin Blumenstingl <[email protected]> Signed-off-by: Ulf Hansson <[email protected]>
dump_thread32() in aout_core_dump() does not clear the user32 structure allocated on the stack as the first thing on function entry. As a result, the dump.u_comm, dump.u_ar0 and dump.signal which get assigned before the clearing, get overwritten. Rename that function to fill_dump() to make it clear what it does and call it first thing. This was caught while staring at a patch by Derek Robson <[email protected]>. Signed-off-by: Borislav Petkov <[email protected]> Cc: Derek Robson <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Michael Matz <[email protected]> Cc: [email protected] Cc: <[email protected]> Link: https://lkml.kernel.org/r/[email protected]
With this patch, we use the mtd->name instead of concatenating the name with '0'. Fixes: c4dfa25 ("mtd: add support for reading MTD devices via the nvmem API") Signed-off-by: Aneesh Kumar K.V <[email protected]> Signed-off-by: Boris Brezillon <[email protected]>
This change helps me to get multiple mtd device registered. Without this I get sysfs: cannot create duplicate filename '/bus/nvmem/devices/flash0' CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.0.0-rc2-00557-g1ef20ef21f22 #13 Call Trace: [c0000000b38e3220] [c000000000b58fe4] dump_stack+0xe8/0x164 (unreliable) [c0000000b38e3270] [c0000000004cf074] sysfs_warn_dup+0x84/0xb0 [c0000000b38e32f0] [c0000000004cf6c4] sysfs_do_create_link_sd.isra.0+0x114/0x150 [c0000000b38e3340] [c000000000726a84] bus_add_device+0x94/0x1e0 [c0000000b38e33c0] [c0000000007218f0] device_add+0x4d0/0x830 [c0000000b38e3480] [c0000000009d54a8] nvmem_register.part.2+0x1c8/0xb30 [c0000000b38e3560] [c000000000834530] mtd_nvmem_add+0x90/0x120 [c0000000b38e3650] [c000000000835bc8] add_mtd_device+0x198/0x4e0 [c0000000b38e36f0] [c00000000083619c] mtd_device_parse_register+0x11c/0x280 [c0000000b38e3780] [c000000000840830] powernv_flash_probe+0x180/0x250 [c0000000b38e3820] [c00000000072c120] platform_drv_probe+0x60/0xf0 [c0000000b38e38a0] [c0000000007283c8] really_probe+0x138/0x4d0 [c0000000b38e3930] [c000000000728acc] driver_probe_device+0x13c/0x1b0 [c0000000b38e39b0] [c000000000728c7c] __driver_attach+0x13c/0x1c0 [c0000000b38e3a30] [c000000000725130] bus_for_each_dev+0xa0/0x120 [c0000000b38e3a90] [c000000000727b2c] driver_attach+0x2c/0x40 [c0000000b38e3ab0] [c0000000007270f8] bus_add_driver+0x228/0x360 [c0000000b38e3b40] [c00000000072a2e0] driver_register+0x90/0x1a0 [c0000000b38e3bb0] [c00000000072c020] __platform_driver_register+0x50/0x70 [c0000000b38e3bd0] [c00000000105c984] powernv_flash_driver_init+0x24/0x38 [c0000000b38e3bf0] [c000000000010904] do_one_initcall+0x84/0x464 [c0000000b38e3cd0] [c000000001004548] kernel_init_freeable+0x530/0x634 [c0000000b38e3db0] [c000000000011154] kernel_init+0x1c/0x168 [c0000000b38e3e20] [c00000000000bed4] ret_from_kernel_thread+0x5c/0x68 mtd mtd1: Failed to register NVMEM device With the change we now have root@(none):/sys/bus/nvmem/devices# ls -al total 0 drwxr-xr-x 2 root root 0 Feb 6 20:49 . drwxr-xr-x 4 root root 0 Feb 6 20:49 .. lrwxrwxrwx 1 root root 0 Feb 6 20:49 flash@0 -> ../../../devices/platform/ibm,opal:flash@0/mtd/mtd0/flash@0 lrwxrwxrwx 1 root root 0 Feb 6 20:49 flash@1 -> ../../../devices/platform/ibm,opal:flash@1/mtd/mtd1/flash@1 Fixes: 1cbb4a1 ("mtd: powernv: Add powernv flash MTD abstraction driver") Signed-off-by: Aneesh Kumar K.V <[email protected]> Signed-off-by: Boris Brezillon <[email protected]>
I fixed a similar build error in commit 1b1e4ee ("sh: fix build error for empty CONFIG_BUILTIN_DTB_SOURCE"), but it came back again. Since commit 37c8a5f ("kbuild: consolidate Devicetree dtb build rules"), the combination of CONFIG_OF_EARLY_FLATTREE=y and CONFIG_USE_BUILTIN_DTB=n results in the following build error: make[1]: *** No rule to make target 'arch/sh/boot/dts/.dtb.o', needed by 'arch/sh/boot/dts/built-in.a'. Stop. Prior to that commit, there was only one path to descend into arch/sh/boot/dts/, and arch/sh/Makefile correctly guards it with CONFIG_USE_BUILTIN_DTB: core-$(CONFIG_USE_BUILTIN_DTB) += arch/sh/boot/dts/ Now, there is another path to descend there from the top Makefile when CONFIG_OF_EARLY_FLATTREE=y. If CONFIG_USE_BUILTIN_DTB is disabled, CONFIG_BUILTIN_DTB_SOURCE is invisible instead of defined as "". Add obj-$(CONFIG_USE_BUILTIN_DTB) guard to avoid the attempt to build the non-existing file. Fixes: 37c8a5f ("kbuild: consolidate Devicetree dtb build rules") Reported-by: kbuild test robot <[email protected]> Signed-off-by: Masahiro Yamada <[email protected]>
In the middle of do_exit() there is there is a call "ptrace_event(PTRACE_EVENT_EXIT, code);" That call places the process in TACKED_TRACED aka "(TASK_WAKEKILL | __TASK_TRACED)" and waits for for the debugger to release the task or SIGKILL to be delivered. Skipping past dequeue_signal when we know a fatal signal has already been delivered resulted in SIGKILL remaining pending and TIF_SIGPENDING remaining set. This in turn caused the scheduler to not sleep in PTACE_EVENT_EXIT as it figured a fatal signal was pending. This also caused ptrace_freeze_traced in ptrace_check_attach to fail because it left a per thread SIGKILL pending which is what fatal_signal_pending tests for. This difference in signal state caused strace to report strace: Exit of unknown pid NNNNN ignored Therefore update the signal handling state like dequeue_signal would when removing a per thread SIGKILL, by removing SIGKILL from the per thread signal mask and clearing TIF_SIGPENDING. Acked-by: Oleg Nesterov <[email protected]> Reported-by: Oleg Nesterov <[email protected]> Reported-by: Ivan Delalande <[email protected]> Cc: [email protected] Fixes: 35634ff ("signal: Always notice exiting tasks") Signed-off-by: "Eric W. Biederman" <[email protected]>
Pull single NVMe fix from Christoph * 'nvme-5.0' of git://git.infradead.org/nvme: nvme-pci: add missing unlock for reset error
Don't warn or fail if it's missing. v2: handle xgmi case more gracefully. v3: handle older kernels properly Reviewed-by: Hawking Zhang <[email protected]> Tested-by: James Zhu <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
…/linux/kernel/git/sunxi/linux into clk-fixes Pull Allwinner clock fixes from Maxime Ripard: Two fixes for clock indices, one for the A31 and one for the V3s. * tag 'sunxi-clk-fixes-for-5.0' of https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux: clk: sunxi: A31: Fix wrong AHB gate number clk: sunxi-ng: v3s: Fix TCON reset de-assert bit
Fetch pointer to module before target object is released. Fixes: 29e3880 ("netfilter: nf_tables: fix use-after-free when deleting compat expressions") Fixes: 0ca743a ("netfilter: nf_tables: add compatibility layer for x_tables") Signed-off-by: Pablo Neira Ayuso <[email protected]>
…el/git/rostedt/linux-trace Pull tracing fix from Steven Rostedt: "This fixes kprobes/uprobes dynamic processing of strings, where it processes the args but does not update the remaining length of the buffer that the string arguments will be placed in. It constantly passes in the total size of buffer used instead of passing in the remaining size of the buffer used. This could cause issues if the strings are larger than the max size of an event which could cause the strings to be written beyond what was reserved on the buffer" * tag 'trace-v5.0-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace: tracing: probeevent: Correctly update remaining space in dynamic area
A recently added preemption timer consistency check was unintentionally dropped when the consistency checks were being reorganized to match the SDM's ordering. Fixes: 461b4ba ("KVM: nVMX: Move the checks for VM-Execution Control Fields to a separate helper function") Cc: Krish Sadhukhan <[email protected]> Signed-off-by: Sean Christopherson <[email protected]> Signed-off-by: Paolo Bonzini <[email protected]>
…ux/kernel/git/kvmarm/kvmarm into kvm-master KVM/ARM fixes for 5.0: - Fix the way we reset vcpus, plugging the race that could happen on VHE - Fix potentially inconsistent group setting for private interrupts - Don't generate UNDEF when LORegion feature is present - Relax the restriction on using stage2 PUD huge mapping - Turn some spinlocks into raw_spinlocks to help RT compliance
New channels are applied to the priv channels only after they are successfully opened. Then, the indirection table should be built according to the new number of channels. Currently, such build is preformed independently of whether the channels opening is successful, and is not reverted on failure. The bug is caused due to removal of rss params from channels struct and moving it to priv struct. That change cause to independency between channels and rss params. This causes a crash on a later point, when accessing rqn of a non existing channel. This patch fixes it by moving the indirection table build right before switching the priv channels to new channels struct, after the new set of channels was successfully opened. Fixes: bbeb53b ("net/mlx5e: Move RSS params to a dedicated struct") Signed-off-by: Maria Pasechnik <[email protected]> Reviewed-by: Tariq Toukan <[email protected]> Signed-off-by: Saeed Mahameed <[email protected]>
When EEH is injected and PCI bus stalls, mlx5's pci error detect function is called to deactivate the command interface and tear down the device. The issue is that there can be a thread that already passed MLX5_DEVICE_STATE_INTERNAL_ERROR check, it will send the command and stuck in the wait_func. Solution: Add function mlx5_cmd_flush to disable command interface and clear all the pending commands. When device state is set to MLX5_DEVICE_STATE_INTERNAL_ERROR, call mlx5_cmd_flush to ensure all pending threads waiting for firmware commands completion are terminated. Fixes: c1d4d2e ("net/mlx5: Avoid calling sleeping function by the health poll thread") Signed-off-by: Huy Nguyen <[email protected]> Reviewed-by: Daniel Jurgens <[email protected]> Signed-off-by: Saeed Mahameed <[email protected]>
Eliminate the following compilation warning: drivers/net/ethernet/mellanox/mlx5/core/events.c: warning: 'error_str' may be used uninitialized in this function [-Wuninitialized]: => 238:3 Fixes: c2fb3db ("net/mlx5: Rework handling of port module events") Signed-off-by: Tariq Toukan <[email protected]> Reviewed-by: Mikhael Goikhman <[email protected]> Signed-off-by: Saeed Mahameed <[email protected]>
Currently mlx5 driver creates xdp redirect hw queues unconditionally on netdevice open, This is great until someone starts redirecting XDP traffic via ndo_xdp_xmit on mlx5 device and changes the device configuration at the same time, this might cause crashes, since the other device's napi is not aware of the mlx5 state change (resources un-availability). To fix this we must synchronize with other devices napi's on the system. Added a new flag under mlx5e_priv to determine XDP TX resources are available, set/clear it up when necessary and use synchronize_rcu() when the flag is turned off, so other napi's are in-sync with it, before we actually cleanup the hw resources. The flag is tested prior to committing to transmit on mlx5e_xdp_xmit, and it is sufficient to determine if it safe to transmit or not. The other two internal flags (MLX5E_STATE_OPENED and MLX5E_SQ_STATE_ENABLED) become unnecessary. Thus, they are removed from data path. Fixes: 58b99ee ("net/mlx5e: Add support for XDP_REDIRECT in device-out side") Reported-by: Toke Høiland-Jørgensen <[email protected]> Reviewed-by: Tariq Toukan <[email protected]> Signed-off-by: Saeed Mahameed <[email protected]>
…ux/kernel/git/saeed/linux Saeed Mahameed says: ==================== Mellanox, mlx5 fixes 2019-02-13 This series introduces some fixes to mlx5 driver. For more information please see tag log below. ==================== Signed-off-by: David S. Miller <[email protected]>
Pablo Neira Ayuso says: ==================== Netfilter/IPVS fixes for net The following patchset contains Netfilter/IPVS fixes for net: 1) Missing structure initialization in ebtables causes splat with 32-bit user level on a 64-bit kernel, from Francesco Ruggeri. 2) Missing dependency on nf_defrag in IPVS IPv6 codebase, from Andrea Claudi. 3) Fix possible use-after-free from release path of target extensions. ==================== Signed-off-by: David S. Miller <[email protected]>
…ment Jianlin reported a panic when running sctp gso over gre over vlan device: [ 84.772930] RIP: 0010:do_csum+0x6d/0x170 [ 84.790605] Call Trace: [ 84.791054] csum_partial+0xd/0x20 [ 84.791657] gre_gso_segment+0x2c3/0x390 [ 84.792364] inet_gso_segment+0x161/0x3e0 [ 84.793071] skb_mac_gso_segment+0xb8/0x120 [ 84.793846] __skb_gso_segment+0x7e/0x180 [ 84.794581] validate_xmit_skb+0x141/0x2e0 [ 84.795297] __dev_queue_xmit+0x258/0x8f0 [ 84.795949] ? eth_header+0x26/0xc0 [ 84.796581] ip_finish_output2+0x196/0x430 [ 84.797295] ? skb_gso_validate_network_len+0x11/0x80 [ 84.798183] ? ip_finish_output+0x169/0x270 [ 84.798875] ip_output+0x6c/0xe0 [ 84.799413] ? ip_append_data.part.50+0xc0/0xc0 [ 84.800145] iptunnel_xmit+0x144/0x1c0 [ 84.800814] ip_tunnel_xmit+0x62d/0x930 [ip_tunnel] [ 84.801699] gre_tap_xmit+0xac/0xf0 [ip_gre] [ 84.802395] dev_hard_start_xmit+0xa5/0x210 [ 84.803086] sch_direct_xmit+0x14f/0x340 [ 84.803733] __dev_queue_xmit+0x799/0x8f0 [ 84.804472] ip_finish_output2+0x2e0/0x430 [ 84.805255] ? skb_gso_validate_network_len+0x11/0x80 [ 84.806154] ip_output+0x6c/0xe0 [ 84.806721] ? ip_append_data.part.50+0xc0/0xc0 [ 84.807516] sctp_packet_transmit+0x716/0xa10 [sctp] [ 84.808337] sctp_outq_flush+0xd7/0x880 [sctp] It was caused by SKB_GSO_CB(skb)->csum_start not set in sctp_gso_segment. sctp_gso_segment() calls skb_segment() with 'feature | NETIF_F_HW_CSUM', which causes SKB_GSO_CB(skb)->csum_start not to be set in skb_segment(). For TCP/UDP, when feature supports HW_CSUM, CHECKSUM_PARTIAL will be set and gso_reset_checksum will be called to set SKB_GSO_CB(skb)->csum_start. So SCTP should do the same as TCP/UDP, to call gso_reset_checksum() when computing checksum in sctp_gso_segment. Reported-by: Jianlin Shi <[email protected]> Signed-off-by: Xin Long <[email protected]> Acked-by: Neil Horman <[email protected]> Acked-by: Marcelo Ricardo Leitner <[email protected]> Signed-off-by: David S. Miller <[email protected]>
…rate In sctp_stream_init(), after sctp_stream_outq_migrate() freed the surplus streams' ext, but sctp_stream_alloc_out() returns -ENOMEM, stream->outcnt will not be set to 'outcnt'. With the bigger value on stream->outcnt, when closing the assoc and freeing its streams, the ext of those surplus streams will be freed again since those stream exts were not set to NULL after freeing in sctp_stream_outq_migrate(). Then the invalid-free issue reported by syzbot would be triggered. We fix it by simply setting them to NULL after freeing. Fixes: 5bbbbe3 ("sctp: introduce stream scheduler foundations") Reported-by: [email protected] Signed-off-by: Xin Long <[email protected]> Acked-by: Neil Horman <[email protected]> Acked-by: Marcelo Ricardo Leitner <[email protected]> Signed-off-by: David S. Miller <[email protected]>
phylib enables interrupts before phy_start() has been called, and if we receive an interrupt in a non-started state, the interrupt handler returns IRQ_NONE. This causes problems with at least one Marvell chip as reported by Andrew. Fix this by handling interrupts the same as in phy_mac_interrupt(), basically always running the phylib state machine. It knows when it has to do something and when not. This change allows to handle interrupts gracefully even if they occur in a non-started state. Fixes: 2b3e88e ("net: phy: improve phy state checking") Reported-by: Andrew Lunn <[email protected]> Signed-off-by: Heiner Kallweit <[email protected]> Reviewed-by: Andrew Lunn <[email protected]> Reviewed-by: Florian Fainelli <[email protected]> Signed-off-by: David S. Miller <[email protected]>
The GPIO interrupt controller on the espressobin board only supports edge interrupts. If one enables the use of hardware interrupts in the device tree for the 88E6341, it is possible to miss an edge. When this happens, the INTn pin on the Marvell switch is stuck low and no further interrupts occur. I found after adding debug statements to mv88e6xxx_g1_irq_thread_work() that there is a race in handling device interrupts (e.g. PHY link interrupts). Some interrupts are directly cleared by reading the Global 1 status register. However, the device interrupt flag, for example, is not cleared until all the unmasked SERDES and PHY ports are serviced. This is done by reading the relevant SERDES and PHY status register. The code only services interrupts whose status bit is set at the time of reading its status register. If an interrupt event occurs after its status is read and before all interrupts are serviced, then this event will not be serviced and the INTn output pin will remain low. This is not a problem with polling or level interrupts since the handler will be called again to process the event. However, it's a big problem when using level interrupts. The fix presented here is to add a loop around the code servicing switch interrupts. If any pending interrupts remain after the current set has been handled, we loop and process the new set. If there are no pending interrupts after servicing, we are sure that INTn has gone high and we will get an edge when a new event occurs. Tested on espressobin board. Fixes: dc30c35 ("net: dsa: mv88e6xxx: Implement interrupt support.") Signed-off-by: John David Anglin <[email protected]> Tested-by: Andrew Lunn <[email protected]> Signed-off-by: David S. Miller <[email protected]>
Fix reversed logic while actionpoints configuration (full/min) detection. Fixies: 7dd380c ("ARC: boot log: print Action point details") Signed-off-by: Eugeniy Paltsev <[email protected]> Signed-off-by: Vineet Gupta <[email protected]>
Newer ARC gcc handles lp_start, lp_end in a different way and doesn't like them in the clobber list. Signed-off-by: Vineet Gupta <[email protected]>
There's a hardware bug which affects the HSDK platform, triggered by micro-ops for auto-saving regfile on taken interrupt. The workaround is to inhibit autosave. Signed-off-by: Vineet Gupta <[email protected]>
Handle U-boot arguments paranoidly: * don't allow to pass unknown tag. * try to use external device tree blob only if corresponding tag (TAG_DTB) is set. * don't check uboot_tag if kernel build with no ARC_UBOOT_SUPPORT. NOTE: If U-boot args are invalid we skip them and try to use embedded device tree blob. We can't panic on invalid U-boot args as we really pass invalid args due to bug in U-boot code. This happens if we don't provide external DTB to U-boot and don't set 'bootargs' U-boot environment variable (which is default case at least for HSDK board) In that case we will pass {r0 = 1 (bootargs in r2); r1 = 0; r2 = 0;} to linux which is invalid. While I'm at it refactor U-boot arguments handling code. Cc: [email protected] Tested-by: Corentin LABBE <[email protected]> Signed-off-by: Eugeniy Paltsev <[email protected]> Signed-off-by: Vineet Gupta <[email protected]>
After reworking U-boot args handling code and adding paranoid arguments check we can eliminate CONFIG_ARC_UBOOT_SUPPORT and enable uboot support unconditionally. For JTAG case we can assume that core registers will come up reset value of 0 or in worst case we rely on user passing '-on=clear_regs' to Metaware debugger. Cc: [email protected] Tested-by: Corentin LABBE <[email protected]> Signed-off-by: Eugeniy Paltsev <[email protected]> Signed-off-by: Vineet Gupta <[email protected]>
The default value of ARCH_SLAB_MINALIGN in "include/linux/slab.h" is "__alignof__(unsigned long long)" which for ARC unexpectedly turns out to be 4. This is not a compiler bug, but as defined by ARC ABI [1] Thus slab allocator would allocate a struct which is 32-bit aligned, which is generally OK even if struct has long long members. There was however potetial problem when it had any atomic64_t which use LLOCKD/SCONDD instructions which are required by ISA to take 64-bit addresses. This is the problem we ran into [ 4.015732] EXT4-fs (mmcblk0p2): re-mounted. Opts: (null) [ 4.167881] Misaligned Access [ 4.172356] Path: /bin/busybox.nosuid [ 4.176004] CPU: 2 PID: 171 Comm: rm Not tainted 4.19.14-yocto-standard #1 [ 4.182851] [ 4.182851] [ECR ]: 0x000d0000 => Check Programmer's Manual [ 4.190061] [EFA ]: 0xbeaec3fc [ 4.190061] [BLINK ]: ext4_delete_entry+0x210/0x234 [ 4.190061] [ERET ]: ext4_delete_entry+0x13e/0x234 [ 4.202985] [STAT32]: 0x80080002 : IE K [ 4.207236] BTA: 0x9009329c SP: 0xbe5b1ec4 FP: 0x00000000 [ 4.212790] LPS: 0x9074b118 LPE: 0x9074b120 LPC: 0x00000000 [ 4.218348] r00: 0x00000040 r01: 0x00000021 r02: 0x00000001 ... ... [ 4.270510] Stack Trace: [ 4.274510] ext4_delete_entry+0x13e/0x234 [ 4.278695] ext4_rmdir+0xe0/0x238 [ 4.282187] vfs_rmdir+0x50/0xf0 [ 4.285492] do_rmdir+0x9e/0x154 [ 4.288802] EV_Trap+0x110/0x114 The fix is to make sure slab allocations are 64-bit aligned. Do note that atomic64_t is __attribute__((aligned(8)) which means gcc does generate 64-bit aligned references, relative to beginning of container struct. However the issue is if the container itself is not 64-bit aligned, atomic64_t ends up unaligned which is what this patch ensures. [1] https://github.com/foss-for-synopsys-dwc-arc-processors/toolchain/wiki/files/ARCv2_ABI.pdf Signed-off-by: Alexey Brodkin <[email protected]> Cc: <[email protected]> # 4.8+ Signed-off-by: Vineet Gupta <[email protected]> [vgupta: reworked changelog, added dependency on LL64+LLSC]
Commit 910cd32 ("parisc: Fix and enable seccomp filter support") introduced a regression in ptrace-based syscall tampering: when tracer changes syscall number to -1, the kernel fails to initialize %r28 with -ENOSYS and subsequently fails to return the error code of the failed syscall to userspace. This erroneous behaviour could be observed with a simple strace syscall fault injection command which is expected to print something like this: $ strace -a0 -ewrite -einject=write:error=enospc echo hello write(1, "hello\n", 6) = -1 ENOSPC (No space left on device) (INJECTED) write(2, "echo: ", 6) = -1 ENOSPC (No space left on device) (INJECTED) write(2, "write error", 11) = -1 ENOSPC (No space left on device) (INJECTED) write(2, "\n", 1) = -1 ENOSPC (No space left on device) (INJECTED) +++ exited with 1 +++ After commit 910cd32 it loops printing something like this instead: write(1, "hello\n", 6../strace: Failed to tamper with process 12345: unexpectedly got no error (return value 0, error 0) ) = 0 (INJECTED) This bug was found by strace test suite. Fixes: 910cd32 ("parisc: Fix and enable seccomp filter support") Cc: [email protected] # v4.5+ Signed-off-by: Dmitry V. Levin <[email protected]> Tested-by: Helge Deller <[email protected]> Signed-off-by: Helge Deller <[email protected]>
Retire the parisc-linux.org email domain and provide alternative email addresses for the remaining users, as agreed upon with them. Signed-off-by: Helge Deller <[email protected]>
The first release of core4 (0x54) was dual issue only (HS4x). Newer releases allow hardware to be configured as single issue (HS3x) or dual issue. Prevent accessing a HS4x only aux register in HS3x, which otherwise leads to illegal instruction exceptions Signed-off-by: Vineet Gupta <[email protected]>
…inux into drm-fixes A bit bigger than normal for this week due to fixes for some long standing display issues that are bound for stable. These changes would be going to stable anyway, so I figured it was better via 5.0 than 5.1. - Several display fixes - Fix PX systems due to core changes in runtime pm - Disable bulk moves. They are fixed in 5.1, but fix is too invasive for 5.0 Signed-off-by: Dave Airlie <[email protected]> From: Alex Deucher <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
* pm-cpufreq-fixes: cpufreq: scmi: Fix use-after-free in scmi_cpufreq_exit()
…b/scm/linux/kernel/git/tmlind/linux-omap into arm/fixes Two am335x ethernet phy mode fixes for v5.0-rc cycle Recent changes with commit cd28d1d: ("net: phy: at803x: Disable phy delay for RGMII mode") broke Ethernet on am335x-evmsk, and turns out some device driver fixes are needed. Even without the driver fixes, am335x needs to run in rgmii-id mode instead rgmii-txid mode. Things have been working based on luck as the broken driver has been configuring rgmii-id mode. Let's fix that as that way things work as they're supposed to work from hardware wiring point of view. * tag 'omap-for-v5.0/fixes-rc7-signed' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap: ARM: dts: am335x-evm: Fix PHY mode for ethernet ARM: dts: am335x-evmsk: Fix PHY mode for ethernet Signed-off-by: Arnd Bergmann <[email protected]>
…into arm/fixes mvebu fixes for 5.0 (part 2) Fix PHY reset signal on clearfog gt 8K (Armada 8040 based) Fix NAND description on Armada XP boards which was broken since a few release * tag 'mvebu-fixes-5.0-2' of git://git.infradead.org/linux-mvebu: arm64: dts: clearfog-gt-8k: fix SGMII PHY reset signal ARM: dts: armada-xp: fix Armada XP boards NAND description Signed-off-by: Arnd Bergmann <[email protected]>
…/kernel/git/clk/linux Pull clk fixes from Stephen Boyd: "A few more fixes for clk drivers causing regressions this release. Two Allwinner index fixes for A31 and V3 and two Microchip AT91 fixes for an incorrect clk parent linkage and a miscalculated number of clks" * tag 'clk-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux: clk: at91: fix masterck name clk: at91: fix at91sam9x5 peripheral clock number clk: sunxi: A31: Fix wrong AHB gate number clk: sunxi-ng: v3s: Fix TCON reset de-assert bit
Align the payload of "user" and "logon" keys so that users of the keyrings service can access it as a struct that requires more than 2-byte alignment. fscrypt currently does this which results in the read of fscrypt_key::size being misaligned as it needs 4-byte alignment. Align to __alignof__(u64) rather than __alignof__(long) since in the future it's conceivable that people would use structs beginning with u64, which on some platforms would require more than 'long' alignment. Reported-by: Aaro Koskinen <[email protected]> Fixes: 2aa349f ("[PATCH] Keys: Export user-defined keyring operations") Fixes: 88bd6cc ("ext4 crypto: add encryption key management facilities") Cc: [email protected] Signed-off-by: Eric Biggers <[email protected]> Tested-by: Aaro Koskinen <[email protected]> Signed-off-by: David Howells <[email protected]> Signed-off-by: James Morris <[email protected]>
syzbot hit the 'BUG_ON(index_key->desc_len == 0);' in __key_link_begin() called from construct_alloc_key() during sys_request_key(), because the length of the key description was never calculated. The problem is that we rely on ->desc_len being initialized by search_process_keyrings(), specifically by search_nested_keyrings(). But, if the process isn't subscribed to any keyrings that never happens. Fix it by always initializing keyring_index_key::desc_len as soon as the description is set, like we already do in some places. The following program reproduces the BUG_ON() when it's run as root and no session keyring has been installed. If it doesn't work, try removing pam_keyinit.so from /etc/pam.d/login and rebooting. #include <stdlib.h> #include <unistd.h> #include <keyutils.h> int main(void) { int id = add_key("keyring", "syz", NULL, 0, KEY_SPEC_USER_KEYRING); keyctl_setperm(id, KEY_OTH_WRITE); setreuid(5000, 5000); request_key("user", "desc", "", id); } Reported-by: [email protected] Fixes: b2a4df2 ("KEYS: Expand the capacity of a keyring") Signed-off-by: Eric Biggers <[email protected]> Signed-off-by: David Howells <[email protected]> Cc: [email protected] Signed-off-by: James Morris <[email protected]>
…t/rdma/rdma Pull rdma fixes from Jason Gunthorpe: "Small set of three regression fixing patches, things are looking pretty good here. - Fix cxgb4 to work again with non-4k page sizes - NULL pointer oops in SRP during sg_reset" * tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma: iw_cxgb4: cq/qp mask depends on bar2 pages in a host page cxgb4: Export sge_host_page_size to ulds RDMA/srp: Rework SCSI device reset handling
…/drm Pull drm fixes from Dave Airlie: "This contains a single i915 tiled display fix, and a set of amdgpu/radeon fixes. i915: - tiled display fix amdgpu/radeon: - runtime PM fix - bulk moves disable (fix is too large for 5.0) - a set of display fixes that are all cc'ed stable so we didn't want to leave them until -next" * tag 'drm-fixes-2019-02-22' of git://anongit.freedesktop.org/drm/drm: drm/amdgpu: disable bulk moves for now drm/amd/display: set clocks to 0 on suspend on dce80 drm/amd/display: fix optimize_bandwidth func pointer for dce80 drm/amd/display: Fix negative cursor pos programming drm/i915/fbdev: Actually configure untiled displays drm/amd/display: Raise dispclk value for dce11 drm/amd/display: Fix MST reboot/poweroff sequence drm/amdgpu: Update sdma golden setting for vega20 drm/amdgpu: Set DPM_FLAG_NEVER_SKIP when enabling PM-runtime gpu: drm: radeon: Set DPM_FLAG_NEVER_SKIP when enabling PM-runtime
…/kernel/git/masahiroy/linux-kbuild Pull more Kbuild fixes from Masahiro Yamada: - fix scripts/kallsyms.c to correctly check too long symbol names - fix sh build error for the combination of CONFIG_OF_EARLY_FLATTREE=y and CONFIG_USE_BUILTIN_DTB=n * tag 'kbuild-fixes-v5.0-2' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild: sh: fix build error for invisible CONFIG_BUILTIN_DTB_SOURCE kallsyms: Handle too long symbols in kallsyms.c
…nel/git/deller/parisc-linux Pull parisc fixes from Helge Deller: "Fix ptrace syscall number modification which has been broken since kernel v4.5 and provide alternative email addresses for the remaining users of the retired parisc-linux.org email domain" * 'parisc-5.0-1' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux: CREDITS/MAINTAINERS: Retire parisc-linux.org email domain parisc: Fix ptrace syscall number modification
…l/git/vgupta/arc Pull ARC fixes from Vineet Gupta: "Fixes for ARC for 5.0, bunch of those are stable fodder anyways so sooner the better. - Fix memcpy to prevent prefetchw beyond end of buffer [Eugeniy] - Enable unaligned access early to prevent exceptions given newer gcc code gen [Eugeniy] - Tighten up uboot arg checking to prevent false negatives and also allow both jtag and bootloading to coexist w/o config option as needed by kernelCi folks [Eugeniy] - Set slab alignment to 8 for ARC to avoid the atomic64_t unalign [Alexey] - Disable regfile auto save on interrupts on HSDK platform due to a silicon issue [Vineet] - Avoid HS38x boot printing crash by not reading HS48x only reg [Vineet]" * tag 'arc-5.0-final' of git://git.kernel.org/pub/scm/linux/kernel/git/vgupta/arc: ARCv2: don't assume core 0x54 has dual issue ARC: define ARCH_SLAB_MINALIGN = 8 ARC: enable uboot support unconditionally ARC: U-boot: check arguments paranoidly ARCv2: support manual regfile save on interrupts ARC: uacces: remove lp_start, lp_end from clobber list ARC: fix actionpoints configuration detection ARCv2: lib: memcpy: fix doing prefetchw outside of buffer ARCv2: Enable unaligned access in early ASM code
…/git/soc/soc Pull ARM SoC fixes from Arnd Bergmann: "Only a handful of device tree fixes, all simple enough: NVIDIA Tegra: - Fix a regression for booting on chromebooks TI OMAP: - Two fixes PHY mode on am335x reference boards Marvell mvebu: - A regression fix for Armada XP NAND flash controllers - An incorrect reset signal on the clearfog board" * tag 'armsoc-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: ARM: tegra: Restore DT ABI on Tegra124 Chromebooks ARM: dts: am335x-evm: Fix PHY mode for ethernet ARM: dts: am335x-evmsk: Fix PHY mode for ethernet arm64: dts: clearfog-gt-8k: fix SGMII PHY reset signal ARM: dts: armada-xp: fix Armada XP boards NAND description
…afael/linux-pm Pull power management fixes from Rafael Wysocki: "These fix a regression in the PM-runtime framework introduced by the recent switch-over of it to using hrtimers and a use-after-free introduced by one of the recent changes in the scmi-cpufreq driver. Specifics: - Use hrtimer_try_to_cancel() instead of hrtimer_cancel() in the PM-runtime framework to avoid a possible timer-related deadlock introduced recently (Vincent Guittot). - Reorder the scmi-cpufreq driver code to avoid accessing memory that has just been freed (Yangtao Li)" * tag 'pm-5.0' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: PM-runtime: Fix deadlock when canceling hrtimer cpufreq: scmi: Fix use-after-free in scmi_cpufreq_exit()
…ernel/git/jmorris/linux-security Pull keys fixes from James Morris: "Two fixes from Eric Biggers" * 'fixes-v5.0-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security: KEYS: always initialize keyring_index_key::desc_len KEYS: user: Align the payload buffer
…it/jejb/scsi Pull SCSI fixes from James Bottomley: "Four small fixes: three in drivers and one in the core. The core fix is also minor in scope since the bug it fixes is only known to affect systems using SCSI reservations. Of the driver bugs, the libsas one is the most major because it can lead to multiple disks on the same expander not being exposed" * tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi: scsi: core: reset host byte in DID_NEXUS_FAILURE case scsi: libsas: Fix rphy phy_identifier for PHYs with end devices attached scsi: sd_zbc: Fix sd_zbc_report_zones() buffer allocation scsi: libiscsi: Fix race between iscsi_xmit_task and iscsi_complete_task
…l/git/powerpc/linux Pull powerpc fix from Michael Ellerman: "One fix for an oops when using SRIOV, introduced by the recent changes to support compound IOMMU groups. Thanks to Alexey Kardashevskiy" * tag 'powerpc-5.0-6' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux: powerpc/powernv/sriov: Register IOMMU groups for VFs
@LazarRazvan patch looks good. But you need to base your patch on linux-kernel-lab/master tree. I think you based it on Linus tree instead. So, if this is right it means that your remote is set to Linus instead of linux-kernel-labs. Just do this: $ git remote add so2 https://github.com/linux-kernel-labs/linux.git Then create the pull request again. |
…_domain_lock" This reverts commit 7560cc3. With 5.2.0-rc5 I can easily trigger this with lockdep and iommu=pt: ====================================================== WARNING: possible circular locking dependency detected 5.2.0-rc5 linux-kernel-labs#78 Not tainted ------------------------------------------------------ swapper/0/1 is trying to acquire lock: 00000000ea2b3beb (&(&iommu->lock)->rlock){+.+.}, at: domain_context_mapping_one+0xa5/0x4e0 but task is already holding lock: 00000000a681907b (device_domain_lock){....}, at: domain_context_mapping_one+0x8d/0x4e0 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (device_domain_lock){....}: _raw_spin_lock_irqsave+0x3c/0x50 dmar_insert_one_dev_info+0xbb/0x510 domain_add_dev_info+0x50/0x90 dev_prepare_static_identity_mapping+0x30/0x68 intel_iommu_init+0xddd/0x1422 pci_iommu_init+0x16/0x3f do_one_initcall+0x5d/0x2b4 kernel_init_freeable+0x218/0x2c1 kernel_init+0xa/0x100 ret_from_fork+0x3a/0x50 -> #0 (&(&iommu->lock)->rlock){+.+.}: lock_acquire+0x9e/0x170 _raw_spin_lock+0x25/0x30 domain_context_mapping_one+0xa5/0x4e0 pci_for_each_dma_alias+0x30/0x140 dmar_insert_one_dev_info+0x3b2/0x510 domain_add_dev_info+0x50/0x90 dev_prepare_static_identity_mapping+0x30/0x68 intel_iommu_init+0xddd/0x1422 pci_iommu_init+0x16/0x3f do_one_initcall+0x5d/0x2b4 kernel_init_freeable+0x218/0x2c1 kernel_init+0xa/0x100 ret_from_fork+0x3a/0x50 other info that might help us debug this: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(device_domain_lock); lock(&(&iommu->lock)->rlock); lock(device_domain_lock); lock(&(&iommu->lock)->rlock); *** DEADLOCK *** 2 locks held by swapper/0/1: #0: 00000000033eb13d (dmar_global_lock){++++}, at: intel_iommu_init+0x1e0/0x1422 #1: 00000000a681907b (device_domain_lock){....}, at: domain_context_mapping_one+0x8d/0x4e0 stack backtrace: CPU: 2 PID: 1 Comm: swapper/0 Not tainted 5.2.0-rc5 linux-kernel-labs#78 Hardware name: LENOVO 20KGS35G01/20KGS35G01, BIOS N23ET50W (1.25 ) 06/25/2018 Call Trace: dump_stack+0x85/0xc0 print_circular_bug.cold.57+0x15c/0x195 __lock_acquire+0x152a/0x1710 lock_acquire+0x9e/0x170 ? domain_context_mapping_one+0xa5/0x4e0 _raw_spin_lock+0x25/0x30 ? domain_context_mapping_one+0xa5/0x4e0 domain_context_mapping_one+0xa5/0x4e0 ? domain_context_mapping_one+0x4e0/0x4e0 pci_for_each_dma_alias+0x30/0x140 dmar_insert_one_dev_info+0x3b2/0x510 domain_add_dev_info+0x50/0x90 dev_prepare_static_identity_mapping+0x30/0x68 intel_iommu_init+0xddd/0x1422 ? printk+0x58/0x6f ? lockdep_hardirqs_on+0xf0/0x180 ? do_early_param+0x8e/0x8e ? e820__memblock_setup+0x63/0x63 pci_iommu_init+0x16/0x3f do_one_initcall+0x5d/0x2b4 ? do_early_param+0x8e/0x8e ? rcu_read_lock_sched_held+0x55/0x60 ? do_early_param+0x8e/0x8e kernel_init_freeable+0x218/0x2c1 ? rest_init+0x230/0x230 kernel_init+0xa/0x100 ret_from_fork+0x3a/0x50 domain_context_mapping_one() is taking device_domain_lock first then iommu lock, while dmar_insert_one_dev_info() is doing the reverse. That should be introduced by commit: 7560cc3 ("iommu/vt-d: Fix lock inversion between iommu->lock and device_domain_lock", 2019-05-27) So far I still cannot figure out how the previous deadlock was triggered (I cannot find iommu lock taken before calling of iommu_flush_dev_iotlb()), however I'm pretty sure that that change should be incomplete at least because it does not fix all the places so we're still taking the locks in different orders, while reverting that commit is very clean to me so far that we should always take device_domain_lock first then the iommu lock. We can continue to try to find the real culprit mentioned in 7560cc3, but for now I think we should revert it to fix current breakage. CC: Joerg Roedel <[email protected]> CC: Lu Baolu <[email protected]> CC: [email protected] Signed-off-by: Peter Xu <[email protected]> Tested-by: Chris Wilson <[email protected]> Signed-off-by: Joerg Roedel <[email protected]>
…ation After allowing parallel tuple insertion, we get the following trace: [ 5505.142249] ------------[ cut here ]------------ [ 5505.148155] WARNING: CPU: 21 PID: 13313 at lib/radix-tree.c:581 delete_node+0x16c/0x180 [ 5505.295553] CPU: 21 PID: 13313 Comm: kworker/u50:22 Tainted: G OE 5.6.0+ linux-kernel-labs#78 [ 5505.304824] Hardware name: Supermicro Super Server/X10DRT-P, BIOS 2.0b 03/30/2017 [ 5505.313740] Workqueue: nf_flow_table_offload flow_offload_work_handler [nf_flow_table] [ 5505.323257] RIP: 0010:delete_node+0x16c/0x180 [ 5505.349862] RSP: 0018:ffffb19184eb7b30 EFLAGS: 00010282 [ 5505.356785] RAX: 0000000000000000 RBX: ffff904ac95b86d8 RCX: ffff904b6f938838 [ 5505.365190] RDX: 0000000000000000 RSI: ffff904ac954b908 RDI: ffff904ac954b920 [ 5505.373628] RBP: ffff904b4ac13060 R08: 0000000000000001 R09: 0000000000000000 [ 5505.382155] R10: 0000000000000000 R11: 0000000000000040 R12: 0000000000000000 [ 5505.390527] R13: ffffb19184eb7bfc R14: ffff904b6bef5800 R15: ffff90482c1203c0 [ 5505.399246] FS: 0000000000000000(0000) GS:ffff904c2fc80000(0000) knlGS:0000000000000000 [ 5505.408621] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 5505.415739] CR2: 00007f5d27006010 CR3: 0000000058c10006 CR4: 00000000001626e0 [ 5505.424547] Call Trace: [ 5505.428429] idr_alloc_u32+0x7b/0xc0 [ 5505.433803] mlx5_tc_ct_entry_add_rule+0xbf/0x950 [mlx5_core] [ 5505.441354] ? mlx5_fc_create+0x23c/0x370 [mlx5_core] [ 5505.448225] mlx5_tc_ct_block_flow_offload+0x874/0x10b0 [mlx5_core] [ 5505.456278] ? mlx5_tc_ct_block_flow_offload+0x63d/0x10b0 [mlx5_core] [ 5505.464532] nf_flow_offload_tuple.isra.21+0xc5/0x140 [nf_flow_table] [ 5505.472286] ? __kmalloc+0x217/0x2f0 [ 5505.477093] ? flow_rule_alloc+0x1c/0x30 [ 5505.482117] flow_offload_work_handler+0x1d0/0x290 [nf_flow_table] [ 5505.489674] ? process_one_work+0x17c/0x580 [ 5505.494922] process_one_work+0x202/0x580 [ 5505.500082] ? process_one_work+0x17c/0x580 [ 5505.505696] worker_thread+0x4c/0x3f0 [ 5505.510458] kthread+0x103/0x140 [ 5505.514989] ? process_one_work+0x580/0x580 [ 5505.520616] ? kthread_bind+0x10/0x10 [ 5505.525837] ret_from_fork+0x3a/0x50 [ 5505.570841] ---[ end trace 07995de9c56d6831 ]--- This happens from parallel deletes/adds to idr, as idr isn't protected. Fix that by using xarray as the tuple_ids allocator instead of idr. Fixes: 7da182a ("netfilter: flowtable: Use work entry per offload command") Reviewed-by: Roi Dayan <[email protected]> Signed-off-by: Paul Blakey <[email protected]> Reviewed-by: Oz Shlomo <[email protected]> Signed-off-by: Saeed Mahameed <[email protected]>
Course presents F5/F6 keys as shortcuts to move between multiple
results but they are not implemented (not working).
"If there are more than one results (usually there are) you can
move between them using F6 and F5"
cscope_shortcuts.zip