Skip to content
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

Closed
wants to merge 10,000 commits into from
Closed

[vimrc]: cscope: implement cnext/cprev shortcuts #78

wants to merge 10,000 commits into from

Conversation

LazarRazvan
Copy link

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

guoren83 and others added 30 commits February 13, 2019 09:48
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]>
Eugeniy Paltsev and others added 26 commits February 21, 2019 11:03
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
@dbaluta
Copy link
Member

dbaluta commented Feb 24, 2019

@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
$ git fetch so2
$ git checkout -b so2/master so2/master2
Now add your patch and submit this into your repo
$ git push -u <your_github_remote_name>

Then create the pull request again.

@dbaluta dbaluta closed this Feb 28, 2019
dbaluta pushed a commit to dbaluta/linux that referenced this pull request Jul 8, 2019
…_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]>
dbaluta pushed a commit to dbaluta/linux that referenced this pull request May 11, 2020
…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]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.