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

Merge pull request #1 from torvalds/master #152

Closed
wants to merge 1 commit into from

Conversation

willemwouters
Copy link

merge

mpe pushed a commit to mpe/linux that referenced this pull request Feb 2, 2015
When unbinding and rebinding the driver on a system with a card in PHB0, this
error condition is reached after a few attempts:

ERROR: Bad of_node_put() on /pciex@3fffe40000000
CPU: 0 PID: 3040 Comm: bash Not tainted 3.18.0-rc3-12545-g3627ffe torvalds#152
Call Trace:
[c000000721acb5c0] [c00000000086ef94] .dump_stack+0x84/0xb0 (unreliable)
[c000000721acb640] [c00000000073a0a8] .of_node_release+0xd8/0xe0
[c000000721acb6d0] [c00000000044bc44] .kobject_release+0x74/0xe0
[c000000721acb760] [c0000000007394fc] .of_node_put+0x1c/0x30
[c000000721acb7d0] [c000000000545cd8] .cxl_probe+0x1a98/0x1d50
[c000000721acb900] [c0000000004845a0] .local_pci_probe+0x40/0xc0
[c000000721acb980] [c000000000484998] .pci_device_probe+0x128/0x170
[c000000721acba30] [c00000000052400c] .driver_probe_device+0xac/0x2a0
[c000000721acbad0] [c000000000522468] .bind_store+0x108/0x160
[c000000721acbb70] [c000000000521448] .drv_attr_store+0x38/0x60
[c000000721acbbe0] [c000000000293840] .sysfs_kf_write+0x60/0xa0
[c000000721acbc50] [c000000000292500] .kernfs_fop_write+0x140/0x1d0
[c000000721acbcf0] [c000000000208648] .vfs_write+0xd8/0x260
[c000000721acbd90] [c000000000208b18] .SyS_write+0x58/0x100
[c000000721acbe30] [c000000000009258] syscall_exit+0x0/0x98

We are missing a call to of_node_get(). pnv_pci_to_phb_node() should
call of_node_get() otherwise np's reference count isn't incremented and
it might go away. Rename pnv_pci_to_phb_node() to pnv_pci_get_phb_node()
so it's clear it calls of_node_get().

Signed-off-by: Ryan Grimm <grimm@linux.vnet.ibm.com>
Acked-by: Ian Munsie <imunsie@au1.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
vineetgarc referenced this pull request in foss-for-synopsys-dwc-arc-processors/linux Mar 26, 2015
commit 6f963ec upstream.

When unbinding and rebinding the driver on a system with a card in PHB0, this
error condition is reached after a few attempts:

ERROR: Bad of_node_put() on /pciex@3fffe40000000
CPU: 0 PID: 3040 Comm: bash Not tainted 3.18.0-rc3-12545-g3627ffe #152
Call Trace:
[c000000721acb5c0] [c00000000086ef94] .dump_stack+0x84/0xb0 (unreliable)
[c000000721acb640] [c00000000073a0a8] .of_node_release+0xd8/0xe0
[c000000721acb6d0] [c00000000044bc44] .kobject_release+0x74/0xe0
[c000000721acb760] [c0000000007394fc] .of_node_put+0x1c/0x30
[c000000721acb7d0] [c000000000545cd8] .cxl_probe+0x1a98/0x1d50
[c000000721acb900] [c0000000004845a0] .local_pci_probe+0x40/0xc0
[c000000721acb980] [c000000000484998] .pci_device_probe+0x128/0x170
[c000000721acba30] [c00000000052400c] .driver_probe_device+0xac/0x2a0
[c000000721acbad0] [c000000000522468] .bind_store+0x108/0x160
[c000000721acbb70] [c000000000521448] .drv_attr_store+0x38/0x60
[c000000721acbbe0] [c000000000293840] .sysfs_kf_write+0x60/0xa0
[c000000721acbc50] [c000000000292500] .kernfs_fop_write+0x140/0x1d0
[c000000721acbcf0] [c000000000208648] .vfs_write+0xd8/0x260
[c000000721acbd90] [c000000000208b18] .SyS_write+0x58/0x100
[c000000721acbe30] [c000000000009258] syscall_exit+0x0/0x98

We are missing a call to of_node_get(). pnv_pci_to_phb_node() should
call of_node_get() otherwise np's reference count isn't incremented and
it might go away. Rename pnv_pci_to_phb_node() to pnv_pci_get_phb_node()
so it's clear it calls of_node_get().

Signed-off-by: Ryan Grimm <grimm@linux.vnet.ibm.com>
Acked-by: Ian Munsie <imunsie@au1.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
pokymobo pushed a commit to pokymobo/linux-yocto-lamobo-r1 that referenced this pull request Mar 26, 2015
commit 6f963ec upstream.

When unbinding and rebinding the driver on a system with a card in PHB0, this
error condition is reached after a few attempts:

ERROR: Bad of_node_put() on /pciex@3fffe40000000
CPU: 0 PID: 3040 Comm: bash Not tainted 3.18.0-rc3-12545-g3627ffe torvalds#152
Call Trace:
[c000000721acb5c0] [c00000000086ef94] .dump_stack+0x84/0xb0 (unreliable)
[c000000721acb640] [c00000000073a0a8] .of_node_release+0xd8/0xe0
[c000000721acb6d0] [c00000000044bc44] .kobject_release+0x74/0xe0
[c000000721acb760] [c0000000007394fc] .of_node_put+0x1c/0x30
[c000000721acb7d0] [c000000000545cd8] .cxl_probe+0x1a98/0x1d50
[c000000721acb900] [c0000000004845a0] .local_pci_probe+0x40/0xc0
[c000000721acb980] [c000000000484998] .pci_device_probe+0x128/0x170
[c000000721acba30] [c00000000052400c] .driver_probe_device+0xac/0x2a0
[c000000721acbad0] [c000000000522468] .bind_store+0x108/0x160
[c000000721acbb70] [c000000000521448] .drv_attr_store+0x38/0x60
[c000000721acbbe0] [c000000000293840] .sysfs_kf_write+0x60/0xa0
[c000000721acbc50] [c000000000292500] .kernfs_fop_write+0x140/0x1d0
[c000000721acbcf0] [c000000000208648] .vfs_write+0xd8/0x260
[c000000721acbd90] [c000000000208b18] .SyS_write+0x58/0x100
[c000000721acbe30] [c000000000009258] syscall_exit+0x0/0x98

We are missing a call to of_node_get(). pnv_pci_to_phb_node() should
call of_node_get() otherwise np's reference count isn't incremented and
it might go away. Rename pnv_pci_to_phb_node() to pnv_pci_get_phb_node()
so it's clear it calls of_node_get().

Signed-off-by: Ryan Grimm <grimm@linux.vnet.ibm.com>
Acked-by: Ian Munsie <imunsie@au1.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
laijs pushed a commit to laijs/linux that referenced this pull request Feb 13, 2017
lkl: Add netperf TCP_RR and TCP_STREAM to make test
fengguang pushed a commit to 0day-ci/linux that referenced this pull request Jan 1, 2018
Currently when user changes link properties, TIPC first checks if
user's command message contains media name or bearer name through
tipc_media_find() or tipc_bearer_find() which is protected by rtnl
lock. But when tipc_nl_compat_link_set() conducts the checking with
the two functions, it doesn't hold rtnl lock at all, as a result,
the following complaints were reported:

audit: type=1400 audit(1514679888.244:9): avc:  denied  { write } for
pid=3194 comm="syzkaller021477" path="socket:[11143]" dev="sockfs"
ino=11143 scontext=unconfined_u:system_r:insmod_t:s0-s0:c0.c1023
tcontext=unconfined_u:system_r:insmod_t:s0-s0:c0.c1023
tclass=netlink_generic_socket permissive=1
=============================
WARNING: suspicious RCU usage
4.15.0-rc5+ torvalds#152 Not tainted
-----------------------------
net/tipc/bearer.c:177 suspicious rcu_dereference_protected() usage!

other info that might help us debug this:

rcu_scheduler_active = 2, debug_locks = 1
2 locks held by syzkaller021477/3194:
  #0:  (cb_lock){++++}, at: [<00000000d20133ea>] genl_rcv+0x19/0x40
net/netlink/genetlink.c:634
  #1:  (genl_mutex){+.+.}, at: [<00000000fcc5d1bc>] genl_lock
net/netlink/genetlink.c:33 [inline]
  #1:  (genl_mutex){+.+.}, at: [<00000000fcc5d1bc>] genl_rcv_msg+0x115/0x140
net/netlink/genetlink.c:622

stack backtrace:
CPU: 1 PID: 3194 Comm: syzkaller021477 Not tainted 4.15.0-rc5+ torvalds#152
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
  __dump_stack lib/dump_stack.c:17 [inline]
  dump_stack+0x194/0x257 lib/dump_stack.c:53
  lockdep_rcu_suspicious+0x123/0x170 kernel/locking/lockdep.c:4585
  tipc_bearer_find+0x2b4/0x3b0 net/tipc/bearer.c:177
  tipc_nl_compat_link_set+0x329/0x9f0 net/tipc/netlink_compat.c:729
  __tipc_nl_compat_doit net/tipc/netlink_compat.c:288 [inline]
  tipc_nl_compat_doit+0x15b/0x660 net/tipc/netlink_compat.c:335
  tipc_nl_compat_handle net/tipc/netlink_compat.c:1119 [inline]
  tipc_nl_compat_recv+0x112f/0x18f0 net/tipc/netlink_compat.c:1201
  genl_family_rcv_msg+0x7b7/0xfb0 net/netlink/genetlink.c:599
  genl_rcv_msg+0xb2/0x140 net/netlink/genetlink.c:624
  netlink_rcv_skb+0x21e/0x460 net/netlink/af_netlink.c:2408
  genl_rcv+0x28/0x40 net/netlink/genetlink.c:635
  netlink_unicast_kernel net/netlink/af_netlink.c:1275 [inline]
  netlink_unicast+0x4e8/0x6f0 net/netlink/af_netlink.c:1301
  netlink_sendmsg+0xa4a/0xe60 net/netlink/af_netlink.c:1864
  sock_sendmsg_nosec net/socket.c:636 [inline]
  sock_sendmsg+0xca/0x110 net/socket.c:646
  sock_write_iter+0x31a/0x5d0 net/socket.c:915
  call_write_iter include/linux/fs.h:1772 [inline]
  new_sync_write fs/read_write.c:469 [inline]
  __vfs_write+0x684/0x970 fs/read_write.c:482
  vfs_write+0x189/0x510 fs/read_write.c:544
  SYSC_write fs/read_write.c:589 [inline]
  SyS_write+0xef/0x220 fs/read_write.c:581
  do_syscall_32_irqs_on arch/x86/entry/common.c:327 [inline]
  do_fast_syscall_32+0x3ee/0xf9d arch/x86/entry/common.c:389
  entry_SYSENTER_compat+0x54/0x63 arch/x86/entry/entry_64_compat.S:129

Signed-off-by: Ying Xue <ying.xue@windriver.com>
Reported-by: syzbot <syzbot+6345fd433db009b29413@syzkaller.appspotmail.com>
fengguang pushed a commit to 0day-ci/linux that referenced this pull request Feb 14, 2018
Currently when user changes link properties, TIPC first checks if
user's command message contains media name or bearer name through
tipc_media_find() or tipc_bearer_find() which is protected by RTNL
lock. But when tipc_nl_compat_link_set() conducts the checking with
the two functions, it doesn't hold RTNL lock at all, as a result,
the following complaints were reported:

audit: type=1400 audit(1514679888.244:9): avc:  denied  { write } for
pid=3194 comm="syzkaller021477" path="socket:[11143]" dev="sockfs"
ino=11143 scontext=unconfined_u:system_r:insmod_t:s0-s0:c0.c1023
tcontext=unconfined_u:system_r:insmod_t:s0-s0:c0.c1023
tclass=netlink_generic_socket permissive=1
=============================
WARNING: suspicious RCU usage
4.15.0-rc5+ torvalds#152 Not tainted
-----------------------------
net/tipc/bearer.c:177 suspicious rcu_dereference_protected() usage!

other info that might help us debug this:

rcu_scheduler_active = 2, debug_locks = 1
2 locks held by syzkaller021477/3194:
  #0:  (cb_lock){++++}, at: [<00000000d20133ea>] genl_rcv+0x19/0x40
net/netlink/genetlink.c:634
  #1:  (genl_mutex){+.+.}, at: [<00000000fcc5d1bc>] genl_lock
net/netlink/genetlink.c:33 [inline]
  #1:  (genl_mutex){+.+.}, at: [<00000000fcc5d1bc>] genl_rcv_msg+0x115/0x140
net/netlink/genetlink.c:622

stack backtrace:
CPU: 1 PID: 3194 Comm: syzkaller021477 Not tainted 4.15.0-rc5+ torvalds#152
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
  __dump_stack lib/dump_stack.c:17 [inline]
  dump_stack+0x194/0x257 lib/dump_stack.c:53
  lockdep_rcu_suspicious+0x123/0x170 kernel/locking/lockdep.c:4585
  tipc_bearer_find+0x2b4/0x3b0 net/tipc/bearer.c:177
  tipc_nl_compat_link_set+0x329/0x9f0 net/tipc/netlink_compat.c:729
  __tipc_nl_compat_doit net/tipc/netlink_compat.c:288 [inline]
  tipc_nl_compat_doit+0x15b/0x660 net/tipc/netlink_compat.c:335
  tipc_nl_compat_handle net/tipc/netlink_compat.c:1119 [inline]
  tipc_nl_compat_recv+0x112f/0x18f0 net/tipc/netlink_compat.c:1201
  genl_family_rcv_msg+0x7b7/0xfb0 net/netlink/genetlink.c:599
  genl_rcv_msg+0xb2/0x140 net/netlink/genetlink.c:624
  netlink_rcv_skb+0x21e/0x460 net/netlink/af_netlink.c:2408
  genl_rcv+0x28/0x40 net/netlink/genetlink.c:635
  netlink_unicast_kernel net/netlink/af_netlink.c:1275 [inline]
  netlink_unicast+0x4e8/0x6f0 net/netlink/af_netlink.c:1301
  netlink_sendmsg+0xa4a/0xe60 net/netlink/af_netlink.c:1864
  sock_sendmsg_nosec net/socket.c:636 [inline]
  sock_sendmsg+0xca/0x110 net/socket.c:646
  sock_write_iter+0x31a/0x5d0 net/socket.c:915
  call_write_iter include/linux/fs.h:1772 [inline]
  new_sync_write fs/read_write.c:469 [inline]
  __vfs_write+0x684/0x970 fs/read_write.c:482
  vfs_write+0x189/0x510 fs/read_write.c:544
  SYSC_write fs/read_write.c:589 [inline]
  SyS_write+0xef/0x220 fs/read_write.c:581
  do_syscall_32_irqs_on arch/x86/entry/common.c:327 [inline]
  do_fast_syscall_32+0x3ee/0xf9d arch/x86/entry/common.c:389
  entry_SYSENTER_compat+0x54/0x63 arch/x86/entry/entry_64_compat.S:129

In order to correct the mistake, __tipc_nl_compat_doit() has been
protected by RTNL lock, which means the whole operation of setting
bearer/media properties is under RTNL protection.

Signed-off-by: Ying Xue <ying.xue@windriver.com>
Reported-by: syzbot <syzbot+6345fd433db009b29413@syzkaller.appspotmail.com>
fengguang pushed a commit to 0day-ci/linux that referenced this pull request Feb 14, 2018
Currently when user changes link properties, TIPC first checks if
user's command message contains media name or bearer name through
tipc_media_find() or tipc_bearer_find() which is protected by RTNL
lock. But when tipc_nl_compat_link_set() conducts the checking with
the two functions, it doesn't hold RTNL lock at all, as a result,
the following complaints were reported:

audit: type=1400 audit(1514679888.244:9): avc:  denied  { write } for
pid=3194 comm="syzkaller021477" path="socket:[11143]" dev="sockfs"
ino=11143 scontext=unconfined_u:system_r:insmod_t:s0-s0:c0.c1023
tcontext=unconfined_u:system_r:insmod_t:s0-s0:c0.c1023
tclass=netlink_generic_socket permissive=1
=============================
WARNING: suspicious RCU usage
4.15.0-rc5+ torvalds#152 Not tainted
-----------------------------
net/tipc/bearer.c:177 suspicious rcu_dereference_protected() usage!

other info that might help us debug this:

rcu_scheduler_active = 2, debug_locks = 1
2 locks held by syzkaller021477/3194:
  #0:  (cb_lock){++++}, at: [<00000000d20133ea>] genl_rcv+0x19/0x40
net/netlink/genetlink.c:634
  #1:  (genl_mutex){+.+.}, at: [<00000000fcc5d1bc>] genl_lock
net/netlink/genetlink.c:33 [inline]
  #1:  (genl_mutex){+.+.}, at: [<00000000fcc5d1bc>] genl_rcv_msg+0x115/0x140
net/netlink/genetlink.c:622

stack backtrace:
CPU: 1 PID: 3194 Comm: syzkaller021477 Not tainted 4.15.0-rc5+ torvalds#152
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
  __dump_stack lib/dump_stack.c:17 [inline]
  dump_stack+0x194/0x257 lib/dump_stack.c:53
  lockdep_rcu_suspicious+0x123/0x170 kernel/locking/lockdep.c:4585
  tipc_bearer_find+0x2b4/0x3b0 net/tipc/bearer.c:177
  tipc_nl_compat_link_set+0x329/0x9f0 net/tipc/netlink_compat.c:729
  __tipc_nl_compat_doit net/tipc/netlink_compat.c:288 [inline]
  tipc_nl_compat_doit+0x15b/0x660 net/tipc/netlink_compat.c:335
  tipc_nl_compat_handle net/tipc/netlink_compat.c:1119 [inline]
  tipc_nl_compat_recv+0x112f/0x18f0 net/tipc/netlink_compat.c:1201
  genl_family_rcv_msg+0x7b7/0xfb0 net/netlink/genetlink.c:599
  genl_rcv_msg+0xb2/0x140 net/netlink/genetlink.c:624
  netlink_rcv_skb+0x21e/0x460 net/netlink/af_netlink.c:2408
  genl_rcv+0x28/0x40 net/netlink/genetlink.c:635
  netlink_unicast_kernel net/netlink/af_netlink.c:1275 [inline]
  netlink_unicast+0x4e8/0x6f0 net/netlink/af_netlink.c:1301
  netlink_sendmsg+0xa4a/0xe60 net/netlink/af_netlink.c:1864
  sock_sendmsg_nosec net/socket.c:636 [inline]
  sock_sendmsg+0xca/0x110 net/socket.c:646
  sock_write_iter+0x31a/0x5d0 net/socket.c:915
  call_write_iter include/linux/fs.h:1772 [inline]
  new_sync_write fs/read_write.c:469 [inline]
  __vfs_write+0x684/0x970 fs/read_write.c:482
  vfs_write+0x189/0x510 fs/read_write.c:544
  SYSC_write fs/read_write.c:589 [inline]
  SyS_write+0xef/0x220 fs/read_write.c:581
  do_syscall_32_irqs_on arch/x86/entry/common.c:327 [inline]
  do_fast_syscall_32+0x3ee/0xf9d arch/x86/entry/common.c:389
  entry_SYSENTER_compat+0x54/0x63 arch/x86/entry/entry_64_compat.S:129

In order to correct the mistake, __tipc_nl_compat_doit() has been
protected by RTNL lock, which means the whole operation of setting
bearer/media properties is under RTNL protection.

Signed-off-by: Ying Xue <ying.xue@windriver.com>
Reported-by: syzbot <syzbot+6345fd433db009b29413@syzkaller.appspotmail.com>
fengguang pushed a commit to 0day-ci/linux that referenced this pull request Feb 22, 2018
GIT af3e79d29555b97dd096e2f8e36a0f50213808a8

commit a988681dbbca01c64d86455c0153899870d7a63c
Author: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Date:   Sun Feb 18 21:11:25 2018 +0100

    MAINTAINERS: Remove Richard Purdie from LED maintainers
    
    Richard has been inactive on the linux-leds list for a long time.
    After email discussion we agreed on removing him from
    the LED maintainers, which will better reflect the actual status.
    
    Acked-by: Richard Purdie <rpurdie@rpsys.net>
    Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>

commit 506b0a395f26e52b3f18827e0de1be051acb77ab
Author: Prashant Sreedharan <prashant.sreedharan@broadcom.com>
Date:   Mon Feb 19 12:27:04 2018 +0530

    tg3: APE heartbeat changes
    
    In ungraceful host shutdown or driver crash case BMC connectivity is
    lost. APE firmware is missing the driver state in this
    case to keep the BMC connectivity alive.
    This patch has below change to address this issue.
    
    Heartbeat mechanism with APE firmware. This heartbeat mechanism
    is needed to notify the APE firmware about driver state.
    
    This patch also has the change in wait time for APE event from
    1ms to 20ms as there can be some delay in getting response.
    
    v2: Drop inline keyword as per David suggestion.
    
    Signed-off-by: Prashant Sreedharan <prashant.sreedharan@broadcom.com>
    Signed-off-by: Satish Baddipadige <satish.baddipadige@broadcom.com>
    Signed-off-by: Siva Reddy Kallam <siva.kallam@broadcom.com>
    Acked-by: Michael Chan <michael.chan@broadcom.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit d1c95af366961101819f07e3c64d44f3be7f0367
Author: Ido Schimmel <idosch@mellanox.com>
Date:   Sat Feb 17 00:30:44 2018 +0100

    mlxsw: spectrum_router: Do not unconditionally clear route offload indication
    
    When mlxsw replaces (or deletes) a route it removes the offload
    indication from the replaced route. This is problematic for IPv4 routes,
    as the offload indication is stored in the fib_info which is usually
    shared between multiple routes.
    
    Instead of unconditionally clearing the offload indication, only clear
    it if no other route is using the fib_info.
    
    Fixes: 3984d1a89fe7 ("mlxsw: spectrum_router: Provide offload indication using nexthop flags")
    Signed-off-by: Ido Schimmel <idosch@mellanox.com>
    Reported-by: Alexander Petrovskiy <alexpe@mellanox.com>
    Tested-by: Alexander Petrovskiy <alexpe@mellanox.com>
    Signed-off-by: Jiri Pirko <jiri@mellanox.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit f57bbaae7271a47dc6486d489c503faeb248b6d5
Author: Subash Abhinov Kasiviswanathan <subashab@codeaurora.org>
Date:   Fri Feb 16 15:56:39 2018 -0700

    net: qualcomm: rmnet: Fix possible null dereference in command processing
    
    If a command packet with invalid mux id is received, the packet would
    not have a valid endpoint. This invalid endpoint maybe dereferenced
    leading to a crash. Identified by manual code inspection.
    
    Fixes: 3352e6c45760 ("net: qualcomm: rmnet: Convert the muxed endpoint to hlist")
    Signed-off-by: Subash Abhinov Kasiviswanathan <subashab@codeaurora.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit 4dba8bbce94541c560940ac65ca9cd563fd43348
Author: Subash Abhinov Kasiviswanathan <subashab@codeaurora.org>
Date:   Fri Feb 16 15:56:38 2018 -0700

    net: qualcomm: rmnet: Fix warning seen with 64 bit stats
    
    With CONFIG_DEBUG_PREEMPT enabled, a warning was seen on device
    creation. This occurs due to the incorrect cpu API usage in
    ndo_get_stats64 handler.
    
    BUG: using smp_processor_id() in preemptible [00000000] code: rmnetcli/5743
    caller is debug_smp_processor_id+0x1c/0x24
    Call trace:
    [<ffffff9d48c8967c>] dump_backtrace+0x0/0x2a8
    [<ffffff9d48c89bbc>] show_stack+0x20/0x28
    [<ffffff9d4901fff8>] dump_stack+0xa8/0xe0
    [<ffffff9d490421e0>] check_preemption_disabled+0x104/0x108
    [<ffffff9d49042200>] debug_smp_processor_id+0x1c/0x24
    [<ffffff9d494a36b0>] rmnet_get_stats64+0x64/0x13c
    [<ffffff9d49b014e0>] dev_get_stats+0x68/0xd8
    [<ffffff9d49d58df8>] rtnl_fill_stats+0x54/0x140
    [<ffffff9d49b1f0b8>] rtnl_fill_ifinfo+0x428/0x9cc
    [<ffffff9d49b23834>] rtmsg_ifinfo_build_skb+0x80/0xf4
    [<ffffff9d49b23930>] rtnetlink_event+0x88/0xb4
    [<ffffff9d48cd21b4>] raw_notifier_call_chain+0x58/0x78
    [<ffffff9d49b028a4>] call_netdevice_notifiers_info+0x48/0x78
    [<ffffff9d49b08bf8>] __netdev_upper_dev_link+0x290/0x5e8
    [<ffffff9d49b08fcc>] netdev_master_upper_dev_link+0x3c/0x48
    [<ffffff9d494a2e74>] rmnet_newlink+0xf0/0x1c8
    [<ffffff9d49b23360>] rtnl_newlink+0x57c/0x6c8
    [<ffffff9d49b2355c>] rtnetlink_rcv_msg+0xb0/0x244
    [<ffffff9d49b5230c>] netlink_rcv_skb+0xb4/0xdc
    [<ffffff9d49b204f4>] rtnetlink_rcv+0x34/0x44
    [<ffffff9d49b51af0>] netlink_unicast+0x1ec/0x294
    [<ffffff9d49b51fdc>] netlink_sendmsg+0x320/0x390
    [<ffffff9d49ae6858>] sock_sendmsg+0x54/0x60
    [<ffffff9d49ae91bc>] SyS_sendto+0x1a0/0x1e4
    [<ffffff9d48c83770>] el0_svc_naked+0x24/0x28
    
    Fixes: 192c4b5d48f2 ("net: qualcomm: rmnet: Add support for 64 bit stats")
    Signed-off-by: Subash Abhinov Kasiviswanathan <subashab@codeaurora.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit b37f78f234bf4fd98979d6c3ccc0f85e508f978f
Author: Subash Abhinov Kasiviswanathan <subashab@codeaurora.org>
Date:   Fri Feb 16 15:56:37 2018 -0700

    net: qualcomm: rmnet: Fix crash on real dev unregistration
    
    With CONFIG_DEBUG_PREEMPT enabled, a crash with the following call
    stack was observed when removing a real dev which had rmnet devices
    attached to it.
    To fix this, remove the netdev_upper link APIs and instead use the
    existing information in rmnet_port and rmnet_priv to get the
    association between real and rmnet devs.
    
    BUG: sleeping function called from invalid context
    in_atomic(): 0, irqs_disabled(): 0, pid: 5762, name: ip
    Preemption disabled at:
    [<ffffff9d49043564>] debug_object_active_state+0xa4/0x16c
    Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
    Modules linked in:
    PC is at ___might_sleep+0x13c/0x180
    LR is at ___might_sleep+0x17c/0x180
    [<ffffff9d48ce0924>] ___might_sleep+0x13c/0x180
    [<ffffff9d48ce09c0>] __might_sleep+0x58/0x8c
    [<ffffff9d49d6253c>] mutex_lock+0x2c/0x48
    [<ffffff9d48ed4840>] kernfs_remove_by_name_ns+0x48/0xa8
    [<ffffff9d48ed6ec8>] sysfs_remove_link+0x30/0x58
    [<ffffff9d49b05840>] __netdev_adjacent_dev_remove+0x14c/0x1e0
    [<ffffff9d49b05914>] __netdev_adjacent_dev_unlink_lists+0x40/0x68
    [<ffffff9d49b08820>] netdev_upper_dev_unlink+0xb4/0x1fc
    [<ffffff9d494a29f0>] rmnet_dev_walk_unreg+0x6c/0xc8
    [<ffffff9d49b00b40>] netdev_walk_all_lower_dev_rcu+0x58/0xb4
    [<ffffff9d494a30fc>] rmnet_config_notify_cb+0xf4/0x134
    [<ffffff9d48cd21b4>] raw_notifier_call_chain+0x58/0x78
    [<ffffff9d49b028a4>] call_netdevice_notifiers_info+0x48/0x78
    [<ffffff9d49b0b568>] rollback_registered_many+0x230/0x3c8
    [<ffffff9d49b0b738>] unregister_netdevice_many+0x38/0x94
    [<ffffff9d49b1e110>] rtnl_delete_link+0x58/0x88
    [<ffffff9d49b201dc>] rtnl_dellink+0xbc/0x1cc
    [<ffffff9d49b2355c>] rtnetlink_rcv_msg+0xb0/0x244
    [<ffffff9d49b5230c>] netlink_rcv_skb+0xb4/0xdc
    [<ffffff9d49b204f4>] rtnetlink_rcv+0x34/0x44
    [<ffffff9d49b51af0>] netlink_unicast+0x1ec/0x294
    [<ffffff9d49b51fdc>] netlink_sendmsg+0x320/0x390
    [<ffffff9d49ae6858>] sock_sendmsg+0x54/0x60
    [<ffffff9d49ae6f94>] ___sys_sendmsg+0x298/0x2b0
    [<ffffff9d49ae98f8>] SyS_sendmsg+0xb4/0xf0
    [<ffffff9d48c83770>] el0_svc_naked+0x24/0x28
    
    Fixes: ceed73a2cf4a ("drivers: net: ethernet: qualcomm: rmnet: Initial implementation")
    Fixes: 60d58f971c10 ("net: qualcomm: rmnet: Implement bridge mode")
    Signed-off-by: Subash Abhinov Kasiviswanathan <subashab@codeaurora.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit 9ab2323ca184168c288f7355fc19ec0838efc20c
Author: Xin Long <lucien.xin@gmail.com>
Date:   Fri Feb 16 17:18:33 2018 +0800

    sctp: remove the left unnecessary check for chunk in sctp_renege_events
    
    Commit fb23403536ea ("sctp: remove the useless check in
    sctp_renege_events") forgot to remove another check for
    chunk in sctp_renege_events.
    
    Dan found this when doing a static check.
    
    This patch is to remove that check, and also to merge
    two checks into one 'if statement'.
    
    Fixes: fb23403536ea ("sctp: remove the useless check in sctp_renege_events")
    Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Xin Long <lucien.xin@gmail.com>
    Acked-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
    Acked-by: Neil Horman <nhorman@tuxdriver.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit a16b8d0cf2ec1e626d24bc2a7b9e64ace6f7501d
Author: David Howells <dhowells@redhat.com>
Date:   Thu Feb 15 22:59:00 2018 +0000

    rxrpc: Work around usercopy check
    
    Due to a check recently added to copy_to_user(), it's now not permitted to
    copy from slab-held data to userspace unless the slab is whitelisted.  This
    affects rxrpc_recvmsg() when it attempts to place an RXRPC_USER_CALL_ID
    control message in the userspace control message buffer.  A warning is
    generated by usercopy_warn() because the source is the copy of the
    user_call_ID retained in the rxrpc_call struct.
    
    Work around the issue by copying the user_call_ID to a variable on the
    stack and passing that to put_cmsg().
    
    The warning generated looks like:
    
            Bad or missing usercopy whitelist? Kernel memory exposure attempt detected from SLUB object 'dmaengine-unmap-128' (offset 680, size 8)!
            WARNING: CPU: 0 PID: 1401 at mm/usercopy.c:81 usercopy_warn+0x7e/0xa0
            ...
            RIP: 0010:usercopy_warn+0x7e/0xa0
            ...
            Call Trace:
             __check_object_size+0x9c/0x1a0
             put_cmsg+0x98/0x120
             rxrpc_recvmsg+0x6fc/0x1010 [rxrpc]
             ? finish_wait+0x80/0x80
             ___sys_recvmsg+0xf8/0x240
             ? __clear_rsb+0x25/0x3d
             ? __clear_rsb+0x15/0x3d
             ? __clear_rsb+0x25/0x3d
             ? __clear_rsb+0x15/0x3d
             ? __clear_rsb+0x25/0x3d
             ? __clear_rsb+0x15/0x3d
             ? __clear_rsb+0x25/0x3d
             ? __clear_rsb+0x15/0x3d
             ? finish_task_switch+0xa6/0x2b0
             ? trace_hardirqs_on_caller+0xed/0x180
             ? _raw_spin_unlock_irq+0x29/0x40
             ? __sys_recvmsg+0x4e/0x90
             __sys_recvmsg+0x4e/0x90
             do_syscall_64+0x7a/0x220
             entry_SYSCALL_64_after_hwframe+0x26/0x9b
    
    Reported-by: Jonathan Billings <jsbillings@jsbillings.org>
    Signed-off-by: David Howells <dhowells@redhat.com>
    Acked-by: Kees Cook <keescook@chromium.org>
    Tested-by: Jonathan Billings <jsbillings@jsbillings.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit 43a08e0f58b3f236165029710a4e3b303815253b
Author: Eric Dumazet <edumazet@google.com>
Date:   Thu Feb 15 14:47:15 2018 -0800

    tun: fix tun_napi_alloc_frags() frag allocator
    
    <Mark Rutland reported>
        While fuzzing arm64 v4.16-rc1 with Syzkaller, I've been hitting a
        misaligned atomic in __skb_clone:
    
            atomic_inc(&(skb_shinfo(skb)->dataref));
    
       where dataref doesn't have the required natural alignment, and the
       atomic operation faults. e.g. i often see it aligned to a single
       byte boundary rather than a four byte boundary.
    
       AFAICT, the skb_shared_info is misaligned at the instant it's
       allocated in __napi_alloc_skb()  __napi_alloc_skb()
    </end of report>
    
    Problem is caused by tun_napi_alloc_frags() using
    napi_alloc_frag() with user provided seg sizes,
    leading to other users of this API getting unaligned
    page fragments.
    
    Since we would like to not necessarily add paddings or alignments to
    the frags that tun_napi_alloc_frags() attaches to the skb, switch to
    another page frag allocator.
    
    As a bonus skb_page_frag_refill() can use GFP_KERNEL allocations,
    meaning that we can not deplete memory reserves as easily.
    
    Fixes: 90e33d459407 ("tun: enable napi_gro_frags() for TUN/TAP driver")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Reported-by: Mark Rutland <mark.rutland@arm.com>
    Tested-by: Mark Rutland <mark.rutland@arm.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit 15f35d49c93f4fa9875235e7bf3e3783d2dd7a1b
Author: Alexey Kodanev <alexey.kodanev@oracle.com>
Date:   Thu Feb 15 20:18:43 2018 +0300

    udplite: fix partial checksum initialization
    
    Since UDP-Lite is always using checksum, the following path is
    triggered when calculating pseudo header for it:
    
      udp4_csum_init() or udp6_csum_init()
        skb_checksum_init_zero_check()
          __skb_checksum_validate_complete()
    
    The problem can appear if skb->len is less than CHECKSUM_BREAK. In
    this particular case __skb_checksum_validate_complete() also invokes
    __skb_checksum_complete(skb). If UDP-Lite is using partial checksum
    that covers only part of a packet, the function will return bad
    checksum and the packet will be dropped.
    
    It can be fixed if we skip skb_checksum_init_zero_check() and only
    set the required pseudo header checksum for UDP-Lite with partial
    checksum before udp4_csum_init()/udp6_csum_init() functions return.
    
    Fixes: ed70fcfcee95 ("net: Call skb_checksum_init in IPv4")
    Fixes: e4f45b7f40bd ("net: Call skb_checksum_init in IPv6")
    Signed-off-by: Alexey Kodanev <alexey.kodanev@oracle.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit da27988766e338e4a4fe198170497c0920395d4c
Author: David S. Miller <davem@davemloft.net>
Date:   Fri Feb 16 15:52:42 2018 -0500

    skbuff: Fix comment mis-spelling.
    
    'peform' --> 'perform'
    
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit dfec091439bb2acf763497cfc58f2bdfc67c56b7
Author: Paolo Abeni <pabeni@redhat.com>
Date:   Thu Feb 15 16:59:49 2018 +0100

    dn_getsockoptdecnet: move nf_{get/set}sockopt outside sock lock
    
    After commit 3f34cfae1238 ("netfilter: on sockopt() acquire sock lock
    only in the required scope"), the caller of nf_{get/set}sockopt() must
    not hold any lock, but, in such changeset, I forgot to cope with DECnet.
    
    This commit addresses the issue moving the nf call outside the lock,
    in the dn_{get,set}sockopt() with the same schema currently used by
    ipv4 and ipv6. Also moves the unhandled sockopts of the end of the main
    switch statements, to improve code readability.
    
    Reported-by: Petr Vandrovec <petr@vandrovec.name>
    BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=198791#c2
    Fixes: 3f34cfae1238 ("netfilter: on sockopt() acquire sock lock only in the required scope")
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit 7dcf688d4c78a18ba9538b2bf1b11dc7a43fe9be
Author: Casey Leedom <leedom@chelsio.com>
Date:   Thu Feb 15 20:03:18 2018 +0530

    PCI/cxgb4: Extend T3 PCI quirk to T4+ devices
    
    We've run into a problem where our device is attached
    to a Virtual Machine and the use of the new pci_set_vpd_size()
    API doesn't help.  The VM kernel has been informed that
    the accesses are okay, but all of the actual VPD Capability
    Accesses are trapped down into the KVM Hypervisor where it
    goes ahead and imposes the silent denials.
    
    The right idea is to follow the kernel.org
    commit 1c7de2b4ff88 ("PCI: Enable access to non-standard VPD for
    Chelsio devices (cxgb3)") which Alexey Kardashevskiy authored
    to establish a PCI Quirk for our T3-based adapters. This commit
    extends that PCI Quirk to cover Chelsio T4 devices and later.
    
    The advantage of this approach is that the VPD Size gets set early
    in the Base OS/Hypervisor Boot and doesn't require that the cxgb4
    driver even be available in the Base OS/Hypervisor.  Thus PF4 can
    be exported to a Virtual Machine and everything should work.
    
    Fixes: 67e658794ca1 ("cxgb4: Set VPD size so we can read both VPD structures")
    Cc: <stable@vger.kernel.org>  # v4.9+
    Signed-off-by: Casey Leedom <leedom@chelsio.com>
    Signed-off-by: Arjun Vynipadath <arjun@chelsio.com>
    Signed-off-by: Ganesh Goudar <ganeshgr@chelsio.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit e6f02a4d57cc438099bc8abfba43ba1400d77b38
Author: Rahul Lakkireddy <rahul.lakkireddy@chelsio.com>
Date:   Thu Feb 15 18:20:01 2018 +0530

    cxgb4: fix trailing zero in CIM LA dump
    
    Set correct size of the CIM LA dump for T6.
    
    Fixes: 27887bc7cb7f ("cxgb4: collect hardware LA dumps")
    Signed-off-by: Rahul Lakkireddy <rahul.lakkireddy@chelsio.com>
    Signed-off-by: Ganesh Goudar <ganeshgr@chelsio.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit c4e43e14cd4617d57babc7a9f251bf3e9ad360a0
Author: Ganesh Goudar <ganeshgr@chelsio.com>
Date:   Thu Feb 15 18:16:57 2018 +0530

    cxgb4: free up resources of pf 0-3
    
    free pf 0-3 resources, commit baf5086840ab ("cxgb4:
    restructure VF mgmt code") erroneously removed the
    code which frees the pf 0-3 resources, causing the
    probe of pf 0-3 to fail in case of driver reload.
    
    Fixes: baf5086840ab ("cxgb4: restructure VF mgmt code")
    Signed-off-by: Ganesh Goudar <ganeshgr@chelsio.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit a8c6db1dfd1b1d18359241372bb204054f2c3174
Author: Stefano Brivio <sbrivio@redhat.com>
Date:   Thu Feb 15 09:46:03 2018 +0100

    fib_semantics: Don't match route with mismatching tclassid
    
    In fib_nh_match(), if output interface or gateway are passed in
    the FIB configuration, we don't have to check next hops of
    multipath routes to conclude whether we have a match or not.
    
    However, we might still have routes with different realms
    matching the same output interface and gateway configuration,
    and this needs to cause the match to fail. Otherwise the first
    route inserted in the FIB will match, regardless of the realms:
    
     # ip route add 1.1.1.1 dev eth0 table 1234 realms 1/2
     # ip route append 1.1.1.1 dev eth0 table 1234 realms 3/4
     # ip route list table 1234
     1.1.1.1 dev eth0 scope link realms 1/2
     1.1.1.1 dev eth0 scope link realms 3/4
     # ip route del 1.1.1.1 dev ens3 table 1234 realms 3/4
     # ip route list table 1234
     1.1.1.1 dev ens3 scope link realms 3/4
    
    whereas route with realms 3/4 should have been deleted instead.
    
    Explicitly check for fc_flow passed in the FIB configuration
    (this comes from RTA_FLOW extracted by rtm_to_fib_config()) and
    fail matching if it differs from nh_tclassid.
    
    The handling of RTA_FLOW for multipath routes later in
    fib_nh_match() is still needed, as we can have multiple RTA_FLOW
    attributes that need to be matched against the tclassid of each
    next hop.
    
    v2: Check that fc_flow is set before discarding the match, so
        that the user can still select the first matching rule by
        not specifying any realm, as suggested by David Ahern.
    
    Reported-by: Jianlin Shi <jishi@redhat.com>
    Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
    Acked-by: David Ahern <dsahern@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit fe9c842695e26d8116b61b80bfb905356f07834b
Author: Kees Cook <keescook@chromium.org>
Date:   Wed Feb 14 15:45:07 2018 -0800

    NFC: llcp: Limit size of SDP URI
    
    The tlv_len is u8, so we need to limit the size of the SDP URI. Enforce
    this both in the NLA policy and in the code that performs the allocation
    and copy, to avoid writing past the end of the allocated buffer.
    
    Fixes: d9b8d8e19b073 ("NFC: llcp: Service Name Lookup netlink interface")
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit c410c1966fe6fcfb23bcac0924aaa6a6e7449829
Author: Boris Pismenny <borisp@mellanox.com>
Date:   Wed Feb 14 10:46:08 2018 +0200

    tls: getsockopt return record sequence number
    
    Return the TLS record sequence number in getsockopt.
    
    Signed-off-by: Boris Pismenny <borisp@mellanox.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit 257082e6ae23e92898440f6bcb2857555bf7957c
Author: Boris Pismenny <borisp@mellanox.com>
Date:   Wed Feb 14 10:46:07 2018 +0200

    tls: reset the crypto info if copy_from_user fails
    
    copy_from_user could copy some partial information, as a result
    TLS_CRYPTO_INFO_READY(crypto_info) could be true while crypto_info is
    using uninitialzed data.
    
    This patch resets crypto_info when copy_from_user fails.
    
    fixes: 3c4d7559159b ("tls: kernel TLS support")
    Signed-off-by: Boris Pismenny <borisp@mellanox.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit a1dfa6812b682eef750412dd5a90e7d38d7af068
Author: Boris Pismenny <borisp@mellanox.com>
Date:   Wed Feb 14 10:46:06 2018 +0200

    tls: retrun the correct IV in getsockopt
    
    Current code returns four bytes of salt followed by four bytes of IV.
    This patch returns all eight bytes of IV.
    
    fixes: 3c4d7559159b ("tls: kernel TLS support")
    Signed-off-by: Boris Pismenny <borisp@mellanox.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit a677088922831d94d292ca3891b148a8ba0b5fa1
Author: Daniel Axtens <dja@axtens.net>
Date:   Wed Feb 14 18:05:33 2018 +1100

    docs: segmentation-offloads.txt: add SCTP info
    
    Most of this is extracted from 90017accff61 ("sctp: Add GSO support"),
    with some extra text about GSO_BY_FRAGS and the need to check for it.
    
    Cc: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
    Signed-off-by: Daniel Axtens <dja@axtens.net>
    Acked-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit bc3c2431d4173816240679a02fd4d74685e94bc8
Author: Daniel Axtens <dja@axtens.net>
Date:   Wed Feb 14 18:05:32 2018 +1100

    docs: segmentation-offloads.txt: Fix ref to SKB_GSO_TUNNEL_REMCSUM
    
    The doc originally called it SKB_GSO_REMCSUM. Fix it.
    
    Fixes: f7a6272bf3cb ("Documentation: Add documentation for TSO and GSO features")
    Signed-off-by: Daniel Axtens <dja@axtens.net>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit a65820e6956782af6c5330749ae37222350d8d3f
Author: Daniel Axtens <dja@axtens.net>
Date:   Wed Feb 14 18:05:31 2018 +1100

    docs: segmentation-offloads.txt: update for UFO depreciation
    
    UFO is deprecated except for tuntap and packet per 0c19f846d582,
    ("net: accept UFO datagrams from tuntap and packet"). Update UFO
    docs to reflect this.
    
    Signed-off-by: Daniel Axtens <dja@axtens.net>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit ed4ffdfec26dfe1bb02435afd1e01f61426f7212
Author: Ying Xue <ying.xue@windriver.com>
Date:   Wed Feb 14 13:38:04 2018 +0800

    tipc: Fix missing RTNL lock protection during setting link properties
    
    Currently when user changes link properties, TIPC first checks if
    user's command message contains media name or bearer name through
    tipc_media_find() or tipc_bearer_find() which is protected by RTNL
    lock. But when tipc_nl_compat_link_set() conducts the checking with
    the two functions, it doesn't hold RTNL lock at all, as a result,
    the following complaints were reported:
    
    audit: type=1400 audit(1514679888.244:9): avc:  denied  { write } for
    pid=3194 comm="syzkaller021477" path="socket:[11143]" dev="sockfs"
    ino=11143 scontext=unconfined_u:system_r:insmod_t:s0-s0:c0.c1023
    tcontext=unconfined_u:system_r:insmod_t:s0-s0:c0.c1023
    tclass=netlink_generic_socket permissive=1
    Reviewed-by: Kirill Tkhai <ktkhai@virtuozzo.com>
    
    =============================
    WARNING: suspicious RCU usage
    4.15.0-rc5+ #152 Not tainted
    -----------------------------
    net/tipc/bearer.c:177 suspicious rcu_dereference_protected() usage!
    
    other info that might help us debug this:
    
    rcu_scheduler_active = 2, debug_locks = 1
    2 locks held by syzkaller021477/3194:
      #0:  (cb_lock){++++}, at: [<00000000d20133ea>] genl_rcv+0x19/0x40
    net/netlink/genetlink.c:634
      #1:  (genl_mutex){+.+.}, at: [<00000000fcc5d1bc>] genl_lock
    net/netlink/genetlink.c:33 [inline]
      #1:  (genl_mutex){+.+.}, at: [<00000000fcc5d1bc>] genl_rcv_msg+0x115/0x140
    net/netlink/genetlink.c:622
    
    stack backtrace:
    CPU: 1 PID: 3194 Comm: syzkaller021477 Not tainted 4.15.0-rc5+ #152
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
    Google 01/01/2011
    Call Trace:
      __dump_stack lib/dump_stack.c:17 [inline]
      dump_stack+0x194/0x257 lib/dump_stack.c:53
      lockdep_rcu_suspicious+0x123/0x170 kernel/locking/lockdep.c:4585
      tipc_bearer_find+0x2b4/0x3b0 net/tipc/bearer.c:177
      tipc_nl_compat_link_set+0x329/0x9f0 net/tipc/netlink_compat.c:729
      __tipc_nl_compat_doit net/tipc/netlink_compat.c:288 [inline]
      tipc_nl_compat_doit+0x15b/0x660 net/tipc/netlink_compat.c:335
      tipc_nl_compat_handle net/tipc/netlink_compat.c:1119 [inline]
      tipc_nl_compat_recv+0x112f/0x18f0 net/tipc/netlink_compat.c:1201
      genl_family_rcv_msg+0x7b7/0xfb0 net/netlink/genetlink.c:599
      genl_rcv_msg+0xb2/0x140 net/netlink/genetlink.c:624
      netlink_rcv_skb+0x21e/0x460 net/netlink/af_netlink.c:2408
      genl_rcv+0x28/0x40 net/netlink/genetlink.c:635
      netlink_unicast_kernel net/netlink/af_netlink.c:1275 [inline]
      netlink_unicast+0x4e8/0x6f0 net/netlink/af_netlink.c:1301
      netlink_sendmsg+0xa4a/0xe60 net/netlink/af_netlink.c:1864
      sock_sendmsg_nosec net/socket.c:636 [inline]
      sock_sendmsg+0xca/0x110 net/socket.c:646
      sock_write_iter+0x31a/0x5d0 net/socket.c:915
      call_write_iter include/linux/fs.h:1772 [inline]
      new_sync_write fs/read_write.c:469 [inline]
      __vfs_write+0x684/0x970 fs/read_write.c:482
      vfs_write+0x189/0x510 fs/read_write.c:544
      SYSC_write fs/read_write.c:589 [inline]
      SyS_write+0xef/0x220 fs/read_write.c:581
      do_syscall_32_irqs_on arch/x86/entry/common.c:327 [inline]
      do_fast_syscall_32+0x3ee/0xf9d arch/x86/entry/common.c:389
      entry_SYSENTER_compat+0x54/0x63 arch/x86/entry/entry_64_compat.S:129
    
    In order to correct the mistake, __tipc_nl_compat_doit() has been
    protected by RTNL lock, which means the whole operation of setting
    bearer/media properties is under RTNL protection.
    
    Signed-off-by: Ying Xue <ying.xue@windriver.com>
    Reported-by: syzbot <syzbot+6345fd433db009b29413@syzkaller.appspotmail.com>
    
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit 5631f65decf390ae480d157838c0c393a991328e
Author: Ying Xue <ying.xue@windriver.com>
Date:   Wed Feb 14 13:38:03 2018 +0800

    tipc: Introduce __tipc_nl_net_set
    
    Introduce __tipc_nl_net_set() which doesn't hold RTNL lock.
    
    Signed-off-by: Ying Xue <ying.xue@windriver.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit 07ffb22357323c7189921935b24d68018e1a2b68
Author: Ying Xue <ying.xue@windriver.com>
Date:   Wed Feb 14 13:38:02 2018 +0800

    tipc: Introduce __tipc_nl_media_set
    
    Introduce __tipc_nl_media_set() which doesn't hold RTNL lock.
    
    Signed-off-by: Ying Xue <ying.xue@windriver.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit 93532bb1d436984dac60c92d1a93eecda4fecb29
Author: Ying Xue <ying.xue@windriver.com>
Date:   Wed Feb 14 13:38:01 2018 +0800

    tipc: Introduce __tipc_nl_bearer_set
    
    Introduce __tipc_nl_bearer_set() which doesn't holding RTNL lock.
    
    Signed-off-by: Ying Xue <ying.xue@windriver.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit 45cf7edfbc07b2208d7b4a79d4a36aeddf16aefd
Author: Ying Xue <ying.xue@windriver.com>
Date:   Wed Feb 14 13:38:00 2018 +0800

    tipc: Introduce __tipc_nl_bearer_enable
    
    Introduce __tipc_nl_bearer_enable() which doesn't hold RTNL lock.
    
    Signed-off-by: Ying Xue <ying.xue@windriver.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit d59d8b77abf4308e9c6809298341e275eac38404
Author: Ying Xue <ying.xue@windriver.com>
Date:   Wed Feb 14 13:37:59 2018 +0800

    tipc: Introduce __tipc_nl_bearer_disable
    
    Introduce __tipc_nl_bearer_disable() which doesn't hold RTNL lock.
    
    Signed-off-by: Ying Xue <ying.xue@windriver.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit e5d1a1eec0f4b51d0a7a6457d0b1b99b34f3e901
Author: Ying Xue <ying.xue@windriver.com>
Date:   Wed Feb 14 13:37:58 2018 +0800

    tipc: Refactor __tipc_nl_compat_doit
    
    As preparation for adding RTNL to make (*cmd->transcode)() and
    (*cmd->transcode)() constantly protected by RTNL lock, we move out of
    memory allocations existing between them as many as possible so that
    the time of holding RTNL can be minimized in __tipc_nl_compat_doit().
    
    Signed-off-by: Ying Xue <ying.xue@windriver.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit d0869c0071e40c4407d1a4d7c9497653cf47253b
Author: Thomas Falcon <tlfalcon@linux.vnet.ibm.com>
Date:   Tue Feb 13 18:23:43 2018 -0600

    ibmvnic: Clean RX pool buffers during device close
    
    During device close or reset, there were some cases of outstanding
    RX socket buffers not being freed. Include a function similar to the
    one that already exists to clean TX socket buffers in this case.
    
    Signed-off-by: Thomas Falcon <tlfalcon@linux.vnet.ibm.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit 4b9b0f01350500173f17e2b2e65beb4df4ef99c7
Author: Thomas Falcon <tlfalcon@linux.vnet.ibm.com>
Date:   Tue Feb 13 18:23:42 2018 -0600

    ibmvnic: Free RX socket buffer in case of adapter error
    
    If a RX buffer is returned to the client driver with an error, free the
    corresponding socket buffer before continuing.
    
    Signed-off-by: Thomas Falcon <tlfalcon@linux.vnet.ibm.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit 6e4842ddfc2b08931ebd6c0bc95322dd56e5232b
Author: Thomas Falcon <tlfalcon@linux.vnet.ibm.com>
Date:   Tue Feb 13 18:23:41 2018 -0600

    ibmvnic: Fix NAPI structures memory leak
    
    This memory is allocated during initialization but never freed,
    so do that now.
    
    Signed-off-by: Thomas Falcon <tlfalcon@linux.vnet.ibm.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit 34f0f4e3f48810b0ba080bf2a65370b0cc179c51
Author: Thomas Falcon <tlfalcon@linux.vnet.ibm.com>
Date:   Tue Feb 13 18:23:40 2018 -0600

    ibmvnic: Fix login buffer memory leaks
    
    During device bringup, the driver exchanges login buffers with
    firmware. These buffers contain information such number of TX
    and RX queues alloted to the device, RX buffer size, etc. These
    buffers weren't being properly freed on device reset or close.
    
    We can free the buffer we send to firmware as soon as we get
    a response. There is information in the response buffer that
    the driver needs for normal operation so retain it until the
    next reset or removal.
    
    Signed-off-by: Thomas Falcon <tlfalcon@linux.vnet.ibm.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit cc85c02edfe48a34865ae00f7d22298a3fdd17aa
Author: Thomas Falcon <tlfalcon@linux.vnet.ibm.com>
Date:   Tue Feb 13 15:32:50 2018 -0600

    ibmvnic: Wait until reset is complete to set carrier on
    
    Pushes back setting the carrier on until the end of the reset
    code. This resolves a bug where a watchdog timer was detecting
    that a TX queue had stalled before the adapter reset was complete.
    
    Signed-off-by: Thomas Falcon <tlfalcon@linux.vnet.ibm.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit e6dbe9397ea754e80f59d852a74fc289fa8b0f3a
Author: Jesper Dangaard Brouer <brouer@redhat.com>
Date:   Tue Feb 13 17:59:22 2018 +0100

    Revert "net: thunderx: Add support for xdp redirect"
    
    This reverts commit aa136d0c82fcd6af14535853c30e219e02b2692d.
    
    As I previously[1] pointed out this implementation of XDP_REDIRECT is
    wrong.  XDP_REDIRECT is a facility that must work between different
    NIC drivers.  Another NIC driver can call ndo_xdp_xmit/nicvf_xdp_xmit,
    but your driver patch assumes payload data (at top of page) will
    contain a queue index and a DMA addr, this is not true and worse will
    likely contain garbage.
    
    Given you have not fixed this in due time (just reached v4.16-rc1),
    the only option I see is a revert.
    
    [1] http://lkml.kernel.org/r/20171211130902.482513d3@redhat.com
    
    Cc: Sunil Goutham <sgoutham@cavium.com>
    Cc: Christina Jacob <cjacob@caviumnetworks.com>
    Cc: Aleksey Makarov <aleksey.makarov@cavium.com>
    Fixes: aa136d0c82fc ("net: thunderx: Add support for xdp redirect")
    Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit fae8b6f4a6be42372f8b7ffda39c3ca2cd951dc1
Author: Xin Long <lucien.xin@gmail.com>
Date:   Tue Feb 13 19:29:13 2018 +0800

    sctp: fix some copy-paste errors for file comments
    
    This patch is to fix the file comments in stream.c and
    stream_interleave.c
    
    v1->v2:
      rephrase the comment for stream.c according to Neil's suggestion.
    
    Fixes: a83863174a61 ("sctp: prepare asoc stream for stream reconf")
    Fixes: 0c3f6f655487 ("sctp: implement make_datafrag for sctp_stream_interleave")
    Signed-off-by: Xin Long <lucien.xin@gmail.com>
    Acked-by: Neil Horman <nhorman@tuxdriver.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit ac5b70198adc25c73fba28de4f78adcee8f6be0b
Author: Jakub Kicinski <jakub.kicinski@netronome.com>
Date:   Mon Feb 12 21:35:31 2018 -0800

    net: fix race on decreasing number of TX queues
    
    netif_set_real_num_tx_queues() can be called when netdev is up.
    That usually happens when user requests change of number of
    channels/rings with ethtool -L.  The procedure for changing
    the number of queues involves resetting the qdiscs and setting
    dev->num_tx_queues to the new value.  When the new value is
    lower than the old one, extra care has to be taken to ensure
    ordering of accesses to the number of queues vs qdisc reset.
    
    Currently the queues are reset before new dev->num_tx_queues
    is assigned, leaving a window of time where packets can be
    enqueued onto the queues going down, leading to a likely
    crash in the drivers, since most drivers don't check if TX
    skbs are assigned to an active queue.
    
    Fixes: e6484930d7c7 ("net: allocate tx queues in register_netdevice")
    Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit d4014d8cc6dfa964e3e66df525de2384e3583018
Author: Sowmini Varadhan <sowmini.varadhan@oracle.com>
Date:   Tue Feb 13 09:46:16 2018 -0800

    rds: do not call ->conn_alloc with GFP_KERNEL
    
    Commit ebeeb1ad9b8a ("rds: tcp: use rds_destroy_pending() to synchronize
    netns/module teardown and rds connection/workq management")
    adds an rcu read critical section to __rd_conn_create. The
    memory allocations in that critcal section need to use
    GFP_ATOMIC to avoid sleeping.
    
    This patch was verified with syzkaller reproducer.
    
    Reported-by: syzbot+a0564419941aaae3fe3c@syzkaller.appspotmail.com
    Fixes: ebeeb1ad9b8a ("rds: tcp: use rds_destroy_pending() to synchronize
           netns/module teardown and rds connection/workq management")
    Signed-off-by: Sowmini Varadhan <sowmini.varadhan@oracle.com>
    Acked-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit 339c21d7c459238135d87da8fefbfd25d98bc375
Author: Jiri Pirko <jiri@mellanox.com>
Date:   Tue Feb 13 12:00:17 2018 +0100

    net: sched: fix tc_u_common lookup
    
    The offending commit wrongly assumes 1:1 mapping between block and q.
    However, there are multiple blocks for a single q for classful qdiscs.
    Since the obscure tc_u_common sharing mechanism expects it to be shared
    among a qdisc, fix it by storing q pointer in case the block is not
    shared.
    
    Reported-by: Paweł Staszewski <pstaszewski@itcare.pl>
    Reported-by: Cong Wang <xiyou.wangcong@gmail.com>
    Fixes: 7fa9d974f3c2 ("net: sched: cls_u32: use block instead of q in tc_u_common")
    Signed-off-by: Jiri Pirko <jiri@mellanox.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit bb047ddd145860ff24820320a21f03cf8c071b22
Author: Jiri Pirko <jiri@mellanox.com>
Date:   Tue Feb 13 12:00:16 2018 +0100

    net: sched: don't set q pointer for shared blocks
    
    It is pointless to set block->q for block which are shared among
    multiple qdiscs. So remove the assignment in that case. Do a bit of code
    reshuffle to make block->index initialized at that point so we can use
    tcf_block_shared() helper.
    
    Reported-by: Cong Wang <xiyou.wangcong@gmail.com>
    Fixes: 4861738775d7 ("net: sched: introduce shared filter blocks infrastructure")
    Signed-off-by: Jiri Pirko <jiri@mellanox.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit 0f2d2b2736b08dafa3bde31d048750fbc8df3a31
Author: Jiri Pirko <jiri@mellanox.com>
Date:   Tue Feb 13 11:22:42 2018 +0100

    mlxsw: spectrum_router: Fix error path in mlxsw_sp_vr_create
    
    Since mlxsw_sp_fib_create() and mlxsw_sp_mr_table_create()
    use ERR_PTR macro to propagate int err through return of a pointer,
    the return value is not NULL in case of failure. So if one
    of the calls fails, one of vr->fib4, vr->fib6 or vr->mr4_table
    is not NULL and mlxsw_sp_vr_is_used wrongly assumes
    that vr is in use which leads to crash like following one:
    
    [ 1293.949291] BUG: unable to handle kernel NULL pointer dereference at 00000000000006c9
    [ 1293.952729] IP: mlxsw_sp_mr_table_flush+0x15/0x70 [mlxsw_spectrum]
    
    Fix this by using local variables to hold the pointers and set vr->*
    only in case everything went fine.
    
    Fixes: 76610ebbde18 ("mlxsw: spectrum_router: Refactor virtual router handling")
    Fixes: a3d9bc506d64 ("mlxsw: spectrum_router: Extend virtual routers with IPv6 support")
    Fixes: d42b0965b1d4 ("mlxsw: spectrum_router: Add multicast routes notification handling functionality")
    Signed-off-by: Jiri Pirko <jiri@mellanox.com>
    Reviewed-by: Ido Schimmel <idosch@mellanox.com>
    Signed-off-by: Jiri Pirko <jiri@mellanox.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit d4e9a408ef5de35dd82c1337b9fe48348b70047c
Author: Tobias Klauser <tklauser@distanz.ch>
Date:   Tue Feb 13 11:11:30 2018 +0100

    net: af_unix: fix typo in UNIX_SKB_FRAGS_SZ comment
    
    Change "minimun" to "minimum".
    
    Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit da360299b6734135a5f66d7db458dcc7801c826a
Author: Hauke Mehrtens <hauke@hauke-m.de>
Date:   Mon Feb 12 23:59:51 2018 +0100

    uapi/if_ether.h: move __UAPI_DEF_ETHHDR libc define
    
    This fixes a compile problem of some user space applications by not
    including linux/libc-compat.h in uapi/if_ether.h.
    
    linux/libc-compat.h checks which "features" the header files, included
    from the libc, provide to make the Linux kernel uapi header files only
    provide no conflicting structures and enums. If a user application mixes
    kernel headers and libc headers it could happen that linux/libc-compat.h
    gets included too early where not all other libc headers are included
    yet. Then the linux/libc-compat.h would not prevent all the
    redefinitions and we run into compile problems.
    This patch removes the include of linux/libc-compat.h from
    uapi/if_ether.h to fix the recently introduced case, but not all as this
    is more or less impossible.
    
    It is no problem to do the check directly in the if_ether.h file and not
    in libc-compat.h as this does not need any fancy glibc header detection
    as glibc never provided struct ethhdr and should define
    __UAPI_DEF_ETHHDR by them self when they will provide this.
    
    The following test program did not compile correctly any more:
    
    #include <linux/if_ether.h>
    #include <netinet/in.h>
    #include <linux/in.h>
    
    int main(void)
    {
            return 0;
    }
    
    Fixes: 6926e041a892 ("uapi/if_ether.h: prevent redefinition of struct ethhdr")
    Reported-by: Guillaume Nault <g.nault@alphalink.fr>
    Cc: <stable@vger.kernel.org> # 4.15
    Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit 07a2e1cf398187814b405665b19d36425ec7a962
Author: Jan Glauber <jglauber@cavium.com>
Date:   Mon Feb 12 18:20:11 2018 +0100

    net: cavium: fix NULL pointer dereference in cavium_ptp_put
    
    Prevent a kernel panic on reboot if ptp_clock is NULL by checking
    the ptp pointer before using it.
    
    Signed-off-by: Jan Glauber <jglauber@cavium.com>
    Fixes: 8c56df372bc1 ("net: add support for Cavium PTP coprocessor")
    Cc: Radoslaw Biernacki <rad@semihalf.com>
    Cc: Aleksey Makarov <aleksey.makarov@cavium.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit 027d351c541744c0c780dd5801c63e4b90750b90
Author: Mika Westerberg <mika.westerberg@linux.intel.com>
Date:   Mon Feb 12 17:10:20 2018 +0300

    net: thunderbolt: Run disconnect flow asynchronously when logout is received
    
    The control channel calls registered callbacks when control messages
    such as XDomain protocol messages are received. The control channel
    handling is done in a worker running on system workqueue which means the
    networking driver can't run tear down flow which includes sending
    disconnect request and waiting for a reply in the same worker. Otherwise
    reply is never received (as the work is already running) and the
    operation times out.
    
    To fix this run disconnect ThunderboltIP flow asynchronously once
    ThunderboltIP logout message is received.
    
    Fixes: e69b6c02b4c3 ("net: Add support for networking over Thunderbolt cable")
    Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit 8e021a14d908475fea89ef85b5421865f7ad650d
Author: Mika Westerberg <mika.westerberg@linux.intel.com>
Date:   Mon Feb 12 17:10:19 2018 +0300

    net: thunderbolt: Tear down connection properly on suspend
    
    When suspending to mem or disk the Thunderbolt controller typically goes
    down as well tearing down the connection automatically. However, when
    suspend to idle is used this does not happen so we need to make sure the
    connection is properly disconnected before it can be re-established
    during resume.
    
    Fixes: e69b6c02b4c3 ("net: Add support for networking over Thunderbolt cable")
    Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit b4580c952e89a332f077038ef19a7582950c082d
Author: Geert Uytterhoeven <geert+renesas@glider.be>
Date:   Mon Feb 12 14:42:36 2018 +0100

    sh_eth: Remove obsolete explicit clock handling for WoL
    
    Currently, if Wake-on-LAN is enabled, the SH-ETH device's module clock
    is manually kept running during system suspend, to make sure the device
    stays active.
    
    Since commits 91c719f5ec6671f7 ("soc: renesas: rcar-sysc: Keep wakeup
    sources active during system suspend") and 744dddcae84441b1 ("clk:
    renesas: mstp: Keep wakeup sources active during system suspend"), this
    workaround is no longer needed.  Hence remove all explicit clock
    handling to keep the device active.
    
    Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
    Reviewed-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit dd62c236c0fe1166d037485494ec5ff6545480eb
Author: Geert Uytterhoeven <geert+renesas@glider.be>
Date:   Mon Feb 12 14:40:00 2018 +0100

    ravb: Remove obsolete explicit clock handling for WoL
    
    Currently, if Wake-on-LAN is enabled, the EtherAVB device's module clock
    is manually kept running during system suspend, to make sure the device
    stays active.
    
    Since commit 91c719f5ec6671f7 ("soc: renesas: rcar-sysc: Keep wakeup
    sources active during system suspend") , this workaround is no longer
    needed.  Hence remove all explicit clock handling to keep the device
    active.
    
    Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
    Reviewed-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit 18a5b052bb1ae77453c5e50fffe3470ced9ed82f
Author: Ingo van Lil <inguin@gmx.de>
Date:   Mon Feb 12 12:02:52 2018 +0100

    net: phy: fix wrong mask to phy_modify()
    
    When forcing a specific link mode, the PHY driver must clear the
    existing speed and duplex bits in BMCR while preserving some other
    control bits. This logic was accidentally inverted with the introduction
    of phy_modify().
    
    Fixes: fea23fb591cc ("net: phy: convert read-modify-write to phy_modify()")
    Signed-off-by: Ingo van Lil <inguin@gmx.de>
    Reviewed-by: Andrew Lunn <andrew@lunn.ch>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit 808cf9e38cd7923036a99f459ccc8cf2955e47af
Author: Ilya Lesokhin <ilyal@mellanox.com>
Date:   Mon Feb 12 12:57:04 2018 +0200

    tcp: Honor the eor bit in tcp_mtu_probe
    
    Avoid SKB coalescing if eor bit is set in one of the relevant
    SKBs.
    
    Fixes: c134ecb87817 ("tcp: Make use of MSG_EOR in tcp_sendmsg")
    Signed-off-by: Ilya Lesokhin <ilyal@mellanox.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit fb23403536eabe81ee90d32cb3051030b871d988
Author: Xin Long <lucien.xin@gmail.com>
Date:   Mon Feb 12 18:31:24 2018 +0800

    sctp: remove the useless check in sctp_renege_events
    
    Remove the 'if (chunk)' check in sctp_renege_events for idata process,
    as all renege commands are generated in sctp_eat_data and it can't be
    NULL.
    
    The same thing we already did for common data in sctp_ulpq_renege.
    
    Fixes: 94014e8d871a ("sctp: implement renege_events for sctp_stream_interleave")
    Signed-off-by: Xin Long <lucien.xin@gmail.com>
    Acked-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
    Acked-by: Neil Horman <nhorman@tuxdriver.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit 947820b9595aa99f73de033ddcfe4c729c903c75
Author: Xin Long <lucien.xin@gmail.com>
Date:   Mon Feb 12 18:29:51 2018 +0800

    sctp: add SCTP_CID_I_DATA and SCTP_CID_I_FWD_TSN conversion in sctp_cname
    
    After the support for SCTP_CID_I_DATA and SCTP_CID_I_FWD_TSN chunks,
    the corresp conversion in sctp_cname should also be added. Otherwise,
    in some places, pr_debug will print them as "unknown chunk".
    
    Signed-off-by: Xin Long <lucien.xin@gmail.com>
    Acked-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
    Acked-by: Neil Horman <nhorman@tuxdriver.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit 27af86bb038d9c8b8066cd17854ddaf2ea92bce1
Author: Xin Long <lucien.xin@gmail.com>
Date:   Mon Feb 12 18:29:06 2018 +0800

    sctp: do not pr_err for the duplicated node in transport rhlist
    
    The pr_err in sctp_hash_transport was supposed to report a sctp bug
    for using rhashtable/rhlist.
    
    The err '-EEXIST' introduced in Commit cd2b70875058 ("sctp: check
    duplicate node before inserting a new transport") doesn't belong
    to that case.
    
    So just return -EEXIST back without pr_err any kmsg.
    
    Fixes: cd2b70875058 ("sctp: check duplicate node before inserting a new transport")
    Reported-by: Wei Chen <weichen@redhat.com>
    Signed-off-by: Xin Long <lucien.xin@gmail.com>
    Acked-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
    Acked-by: Neil Horman <nhorman@tuxdriver.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit 1b12580af1d0677c3c3a19e35bfe5d59b03f737f
Author: Xin Long <lucien.xin@gmail.com>
Date:   Mon Feb 12 17:15:40 2018 +0800

    bridge: check brport attr show in brport_show
    
    Now br_sysfs_if file flush doesn't have attr show. To read it will
    cause kernel panic after users chmod u+r this file.
    
    Xiong found this issue when running the commands:
    
      ip link add br0 type bridge
      ip link add type veth
      ip link set veth0 master br0
      chmod u+r /sys/devices/virtual/net/veth0/brport/flush
      timeout 3 cat /sys/devices/virtual/net/veth0/brport/flush
    
    kernel crashed with NULL a pointer dereference call trace.
    
    This patch is to fix it by return -EINVAL when brport_attr->show
    is null, just the same as the check for brport_attr->store in
    brport_store().
    
    Fixes: 9cf637473c85 ("bridge: add sysfs hook to flush forwarding table")
    Reported-by: Xiong Zhou <xzhou@redhat.com>
    Signed-off-by: Xin Long <lucien.xin@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit 7ac8ff95f48cbfa609a060fd6a1e361dd62feeb3
Author: Mikulas Patocka <mpatocka@redhat.com>
Date:   Sun Feb 11 18:10:28 2018 -0500

    mvpp2: fix multicast address filter
    
    IPv6 doesn't work on the MacchiatoBIN board. It is caused by broken
    multicast address filter in the mvpp2 driver.
    
    The driver loads doesn't load any multicast entries if "allmulti" is not
    set. This condition should be reversed.
    
    The condition !netdev_mc_empty(dev) is useless (because
    netdev_for_each_mc_addr is nop if the list is empty).
    
    This patch also fixes a possible overflow of the multicast list - if
    mvpp2_prs_mac_da_accept fails, we set the allmulti flag and retry.
    
    Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit 54e02162d4454a99227f520948bf4494c3d972d0
Author: Jason Wang <jasowang@redhat.com>
Date:   Sun Feb 11 11:28:12 2018 +0800

    ptr_ring: prevent integer overflow when calculating size
    
    Switch to use dividing to prevent integer overflow when size is too
    big to calculate allocation size properly.
    
    Reported-by: Eric Biggers <ebiggers3@gmail.com>
    Fixes: 6e6e41c31122 ("ptr_ring: fail early if queue occupies more than KMALLOC_MAX_SIZE")
    Signed-off-by: Jason Wang <jasowang@redhat.com>
    Acked-by: Michael S. Tsirkin <mst@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
intel-lab-lkp pushed a commit to intel-lab-lkp/linux that referenced this pull request Mar 20, 2023
WARNING: braces {} are not necessary for single statement blocks
torvalds#152: FILE: mm/page_alloc.c:956:
+	if (!IS_ENABLED(CONFIG_DEBUG_VM) && want_check_pages) {
+		static_branch_enable(&check_pages_enabled);
+	}

total: 3 errors, 2 warnings, 307 lines checked

Cc: Vlastimil Babka <vbabka@suse.cz>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
intel-lab-lkp pushed a commit to intel-lab-lkp/linux that referenced this pull request Mar 21, 2023
WARNING: braces {} are not necessary for single statement blocks
torvalds#152: FILE: mm/page_alloc.c:956:
+	if (!IS_ENABLED(CONFIG_DEBUG_VM) && want_check_pages) {
+		static_branch_enable(&check_pages_enabled);
+	}

total: 3 errors, 2 warnings, 307 lines checked

Cc: Vlastimil Babka <vbabka@suse.cz>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
intel-lab-lkp pushed a commit to intel-lab-lkp/linux that referenced this pull request Mar 22, 2023
WARNING: braces {} are not necessary for single statement blocks
torvalds#152: FILE: mm/page_alloc.c:956:
+	if (!IS_ENABLED(CONFIG_DEBUG_VM) && want_check_pages) {
+		static_branch_enable(&check_pages_enabled);
+	}

total: 3 errors, 2 warnings, 307 lines checked

Cc: Vlastimil Babka <vbabka@suse.cz>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
intel-lab-lkp pushed a commit to intel-lab-lkp/linux that referenced this pull request Mar 23, 2023
WARNING: braces {} are not necessary for single statement blocks
torvalds#152: FILE: mm/page_alloc.c:956:
+	if (!IS_ENABLED(CONFIG_DEBUG_VM) && want_check_pages) {
+		static_branch_enable(&check_pages_enabled);
+	}

total: 3 errors, 2 warnings, 307 lines checked

Cc: Vlastimil Babka <vbabka@suse.cz>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
intel-lab-lkp pushed a commit to intel-lab-lkp/linux that referenced this pull request Mar 23, 2023
WARNING: braces {} are not necessary for single statement blocks
torvalds#152: FILE: mm/page_alloc.c:956:
+	if (!IS_ENABLED(CONFIG_DEBUG_VM) && want_check_pages) {
+		static_branch_enable(&check_pages_enabled);
+	}

total: 3 errors, 2 warnings, 307 lines checked

Cc: Vlastimil Babka <vbabka@suse.cz>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
intel-lab-lkp pushed a commit to intel-lab-lkp/linux that referenced this pull request Mar 25, 2023
WARNING: braces {} are not necessary for single statement blocks
torvalds#152: FILE: mm/page_alloc.c:956:
+	if (!IS_ENABLED(CONFIG_DEBUG_VM) && want_check_pages) {
+		static_branch_enable(&check_pages_enabled);
+	}

total: 3 errors, 2 warnings, 307 lines checked

Cc: Vlastimil Babka <vbabka@suse.cz>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
intel-lab-lkp pushed a commit to intel-lab-lkp/linux that referenced this pull request Mar 26, 2023
WARNING: braces {} are not necessary for single statement blocks
torvalds#152: FILE: mm/page_alloc.c:956:
+	if (!IS_ENABLED(CONFIG_DEBUG_VM) && want_check_pages) {
+		static_branch_enable(&check_pages_enabled);
+	}

total: 3 errors, 2 warnings, 307 lines checked

Cc: Vlastimil Babka <vbabka@suse.cz>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
intel-lab-lkp pushed a commit to intel-lab-lkp/linux that referenced this pull request Mar 28, 2023
WARNING: braces {} are not necessary for single statement blocks
torvalds#152: FILE: mm/page_alloc.c:956:
+	if (!IS_ENABLED(CONFIG_DEBUG_VM) && want_check_pages) {
+		static_branch_enable(&check_pages_enabled);
+	}

total: 3 errors, 2 warnings, 307 lines checked

Cc: Vlastimil Babka <vbabka@suse.cz>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
intel-lab-lkp pushed a commit to intel-lab-lkp/linux that referenced this pull request Mar 28, 2023
WARNING: braces {} are not necessary for single statement blocks
torvalds#152: FILE: mm/page_alloc.c:956:
+	if (!IS_ENABLED(CONFIG_DEBUG_VM) && want_check_pages) {
+		static_branch_enable(&check_pages_enabled);
+	}

total: 3 errors, 2 warnings, 307 lines checked

Cc: Vlastimil Babka <vbabka@suse.cz>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
intel-lab-lkp pushed a commit to intel-lab-lkp/linux that referenced this pull request Jun 21, 2023
Since limited tracking device per condition, this feature is to support
tracking multiple devices concurrently.
When a pattern monitor detects the device, this feature issues an address
monitor for tracking that device. Let pattern monitor can keep monitor
new devices.
This feature adds an address filter when receiving a LE monitor device
event which monitor handle is for a pattern, and the controller started
monitoring the device. And this feature also has cancelled the monitor
advertisement from address filters when receiving a LE monitor device
event when the controller stopped monitoring the device specified by an
address and monitor handle.

Below is an example to know the feature adds the address filter.

//Add MSFT pattern monitor
< HCI Command: Vendor (0x3f|0x00f0) plen 14          torvalds#142 [hci0] 55.552420
        03 b8 a4 03 ff 01 01 06 09 05 5f 52 45 46        .........._REF
> HCI Event: Command Complete (0x0e) plen 6          torvalds#143 [hci0] 55.653960
      Vendor (0x3f|0x00f0) ncmd 2
        Status: Success (0x00)
        03 00

//Got event from the pattern monitor
> HCI Event: Vendor (0xff) plen 18                   torvalds#148 [hci0] 58.384953
        23 79 54 33 77 88 97 68 02 00 fb c1 29 eb 27 b8  #yT3w..h....).'.
        00 01                                            ..

//Add MSFT address monitor (Sample address: B8:27:EB:29:C1:FB)
< HCI Command: Vendor (0x3f|0x00f0) plen 13          torvalds#149 [hci0] 58.385067
        03 b8 a4 03 ff 04 00 fb c1 29 eb 27 b8           .........).'.

//Report to userspace about found device (ADV Monitor Device Found)
@ MGMT Event: Unknown (0x002f) plen 38           {0x0003} [hci0] 58.680042
        01 00 fb c1 29 eb 27 b8 01 ce 00 00 00 00 16 00  ....).'.........
        0a 09 4b 45 59 42 44 5f 52 45 46 02 01 06 03 19  ..KEYBD_REF.....
        c1 03 03 03 12 18                                ......

//Got event from address monitor
> HCI Event: Vendor (0xff) plen 18                   torvalds#152 [hci0] 58.672956
        23 79 54 33 77 88 97 68 02 00 fb c1 29 eb 27 b8  #yT3w..h....).'.
        01 01

Signed-off-by: Alex Lu <alex_lu@realsil.com.cn>
Signed-off-by: Hilda Wu <hildawu@realtek.com>
Reviewed-by: Simon Horman <simon.horman@corigine.com>
staging-kernelci-org pushed a commit to kernelci/linux that referenced this pull request Jun 27, 2023
Since limited tracking device per condition, this feature is to support
tracking multiple devices concurrently.
When a pattern monitor detects the device, this feature issues an address
monitor for tracking that device. Let pattern monitor can keep monitor
new devices.
This feature adds an address filter when receiving a LE monitor device
event which monitor handle is for a pattern, and the controller started
monitoring the device. And this feature also has cancelled the monitor
advertisement from address filters when receiving a LE monitor device
event when the controller stopped monitoring the device specified by an
address and monitor handle.

Below is an example to know the feature adds the address filter.

//Add MSFT pattern monitor
< HCI Command: Vendor (0x3f|0x00f0) plen 14          torvalds#142 [hci0] 55.552420
        03 b8 a4 03 ff 01 01 06 09 05 5f 52 45 46        .........._REF
> HCI Event: Command Complete (0x0e) plen 6          torvalds#143 [hci0] 55.653960
      Vendor (0x3f|0x00f0) ncmd 2
        Status: Success (0x00)
        03 00

//Got event from the pattern monitor
> HCI Event: Vendor (0xff) plen 18                   torvalds#148 [hci0] 58.384953
        23 79 54 33 77 88 97 68 02 00 fb c1 29 eb 27 b8  #yT3w..h....).'.
        00 01                                            ..

//Add MSFT address monitor (Sample address: B8:27:EB:29:C1:FB)
< HCI Command: Vendor (0x3f|0x00f0) plen 13          torvalds#149 [hci0] 58.385067
        03 b8 a4 03 ff 04 00 fb c1 29 eb 27 b8           .........).'.

//Report to userspace about found device (ADV Monitor Device Found)
@ MGMT Event: Unknown (0x002f) plen 38           {0x0003} [hci0] 58.680042
        01 00 fb c1 29 eb 27 b8 01 ce 00 00 00 00 16 00  ....).'.........
        0a 09 4b 45 59 42 44 5f 52 45 46 02 01 06 03 19  ..KEYBD_REF.....
        c1 03 03 03 12 18                                ......

//Got event from address monitor
> HCI Event: Vendor (0xff) plen 18                   torvalds#152 [hci0] 58.672956
        23 79 54 33 77 88 97 68 02 00 fb c1 29 eb 27 b8  #yT3w..h....).'.
        01 01

Signed-off-by: Alex Lu <alex_lu@realsil.com.cn>
Signed-off-by: Hilda Wu <hildawu@realtek.com>
Reviewed-by: Simon Horman <simon.horman@corigine.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
intel-lab-lkp pushed a commit to intel-lab-lkp/linux that referenced this pull request Jun 27, 2023
Since limited tracking device per condition, this feature is to support
tracking multiple devices concurrently.
When a pattern monitor detects the device, this feature issues an address
monitor for tracking that device. Let pattern monitor can keep monitor
new devices.
This feature adds an address filter when receiving a LE monitor device
event which monitor handle is for a pattern, and the controller started
monitoring the device. And this feature also has cancelled the monitor
advertisement from address filters when receiving a LE monitor device
event when the controller stopped monitoring the device specified by an
address and monitor handle.

Below is an example to know the feature adds the address filter.

//Add MSFT pattern monitor
< HCI Command: Vendor (0x3f|0x00f0) plen 14          torvalds#142 [hci0] 55.552420
        03 b8 a4 03 ff 01 01 06 09 05 5f 52 45 46        .........._REF
> HCI Event: Command Complete (0x0e) plen 6          torvalds#143 [hci0] 55.653960
      Vendor (0x3f|0x00f0) ncmd 2
        Status: Success (0x00)
        03 00

//Got event from the pattern monitor
> HCI Event: Vendor (0xff) plen 18                   torvalds#148 [hci0] 58.384953
        23 79 54 33 77 88 97 68 02 00 fb c1 29 eb 27 b8  #yT3w..h....).'.
        00 01                                            ..

//Add MSFT address monitor (Sample address: B8:27:EB:29:C1:FB)
< HCI Command: Vendor (0x3f|0x00f0) plen 13          torvalds#149 [hci0] 58.385067
        03 b8 a4 03 ff 04 00 fb c1 29 eb 27 b8           .........).'.

//Report to userspace about found device (ADV Monitor Device Found)
@ MGMT Event: Unknown (0x002f) plen 38           {0x0003} [hci0] 58.680042
        01 00 fb c1 29 eb 27 b8 01 ce 00 00 00 00 16 00  ....).'.........
        0a 09 4b 45 59 42 44 5f 52 45 46 02 01 06 03 19  ..KEYBD_REF.....
        c1 03 03 03 12 18                                ......

//Got event from address monitor
> HCI Event: Vendor (0xff) plen 18                   torvalds#152 [hci0] 58.672956
        23 79 54 33 77 88 97 68 02 00 fb c1 29 eb 27 b8  #yT3w..h....).'.
        01 01

Signed-off-by: Alex Lu <alex_lu@realsil.com.cn>
Signed-off-by: Hilda Wu <hildawu@realtek.com>
Reviewed-by: Simon Horman <simon.horman@corigine.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
akiyks pushed a commit to akiyks/linux that referenced this pull request Jun 30, 2023
Since limited tracking device per condition, this feature is to support
tracking multiple devices concurrently.
When a pattern monitor detects the device, this feature issues an address
monitor for tracking that device. Let pattern monitor can keep monitor
new devices.
This feature adds an address filter when receiving a LE monitor device
event which monitor handle is for a pattern, and the controller started
monitoring the device. And this feature also has cancelled the monitor
advertisement from address filters when receiving a LE monitor device
event when the controller stopped monitoring the device specified by an
address and monitor handle.

Below is an example to know the feature adds the address filter.

//Add MSFT pattern monitor
< HCI Command: Vendor (0x3f|0x00f0) plen 14          torvalds#142 [hci0] 55.552420
        03 b8 a4 03 ff 01 01 06 09 05 5f 52 45 46        .........._REF
> HCI Event: Command Complete (0x0e) plen 6          torvalds#143 [hci0] 55.653960
      Vendor (0x3f|0x00f0) ncmd 2
        Status: Success (0x00)
        03 00

//Got event from the pattern monitor
> HCI Event: Vendor (0xff) plen 18                   torvalds#148 [hci0] 58.384953
        23 79 54 33 77 88 97 68 02 00 fb c1 29 eb 27 b8  #yT3w..h....).'.
        00 01                                            ..

//Add MSFT address monitor (Sample address: B8:27:EB:29:C1:FB)
< HCI Command: Vendor (0x3f|0x00f0) plen 13          torvalds#149 [hci0] 58.385067
        03 b8 a4 03 ff 04 00 fb c1 29 eb 27 b8           .........).'.

//Report to userspace about found device (ADV Monitor Device Found)
@ MGMT Event: Unknown (0x002f) plen 38           {0x0003} [hci0] 58.680042
        01 00 fb c1 29 eb 27 b8 01 ce 00 00 00 00 16 00  ....).'.........
        0a 09 4b 45 59 42 44 5f 52 45 46 02 01 06 03 19  ..KEYBD_REF.....
        c1 03 03 03 12 18                                ......

//Got event from address monitor
> HCI Event: Vendor (0xff) plen 18                   torvalds#152 [hci0] 58.672956
        23 79 54 33 77 88 97 68 02 00 fb c1 29 eb 27 b8  #yT3w..h....).'.
        01 01

Signed-off-by: Alex Lu <alex_lu@realsil.com.cn>
Signed-off-by: Hilda Wu <hildawu@realtek.com>
Reviewed-by: Simon Horman <simon.horman@corigine.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
akiyks pushed a commit to akiyks/linux that referenced this pull request Jul 7, 2023
Since limited tracking device per condition, this feature is to support
tracking multiple devices concurrently.
When a pattern monitor detects the device, this feature issues an address
monitor for tracking that device. Let pattern monitor can keep monitor
new devices.
This feature adds an address filter when receiving a LE monitor device
event which monitor handle is for a pattern, and the controller started
monitoring the device. And this feature also has cancelled the monitor
advertisement from address filters when receiving a LE monitor device
event when the controller stopped monitoring the device specified by an
address and monitor handle.

Below is an example to know the feature adds the address filter.

//Add MSFT pattern monitor
< HCI Command: Vendor (0x3f|0x00f0) plen 14          torvalds#142 [hci0] 55.552420
        03 b8 a4 03 ff 01 01 06 09 05 5f 52 45 46        .........._REF
> HCI Event: Command Complete (0x0e) plen 6          torvalds#143 [hci0] 55.653960
      Vendor (0x3f|0x00f0) ncmd 2
        Status: Success (0x00)
        03 00

//Got event from the pattern monitor
> HCI Event: Vendor (0xff) plen 18                   torvalds#148 [hci0] 58.384953
        23 79 54 33 77 88 97 68 02 00 fb c1 29 eb 27 b8  #yT3w..h....).'.
        00 01                                            ..

//Add MSFT address monitor (Sample address: B8:27:EB:29:C1:FB)
< HCI Command: Vendor (0x3f|0x00f0) plen 13          torvalds#149 [hci0] 58.385067
        03 b8 a4 03 ff 04 00 fb c1 29 eb 27 b8           .........).'.

//Report to userspace about found device (ADV Monitor Device Found)
@ MGMT Event: Unknown (0x002f) plen 38           {0x0003} [hci0] 58.680042
        01 00 fb c1 29 eb 27 b8 01 ce 00 00 00 00 16 00  ....).'.........
        0a 09 4b 45 59 42 44 5f 52 45 46 02 01 06 03 19  ..KEYBD_REF.....
        c1 03 03 03 12 18                                ......

//Got event from address monitor
> HCI Event: Vendor (0xff) plen 18                   torvalds#152 [hci0] 58.672956
        23 79 54 33 77 88 97 68 02 00 fb c1 29 eb 27 b8  #yT3w..h....).'.
        01 01

Signed-off-by: Alex Lu <alex_lu@realsil.com.cn>
Signed-off-by: Hilda Wu <hildawu@realtek.com>
Reviewed-by: Simon Horman <simon.horman@corigine.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
intel-lab-lkp pushed a commit to intel-lab-lkp/linux that referenced this pull request Jul 24, 2023
Since limited tracking device per condition, this feature is to support
tracking multiple devices concurrently.
When a pattern monitor detects the device, this feature issues an address
monitor for tracking that device. Let pattern monitor can keep monitor
new devices.
This feature adds an address filter when receiving a LE monitor device
event which monitor handle is for a pattern, and the controller started
monitoring the device. And this feature also has cancelled the monitor
advertisement from address filters when receiving a LE monitor device
event when the controller stopped monitoring the device specified by an
address and monitor handle.

Below is an example to know the feature adds the address filter.

//Add MSFT pattern monitor
< HCI Command: Vendor (0x3f|0x00f0) plen 14          torvalds#142 [hci0] 55.552420
        03 b8 a4 03 ff 01 01 06 09 05 5f 52 45 46        .........._REF
> HCI Event: Command Complete (0x0e) plen 6          torvalds#143 [hci0] 55.653960
      Vendor (0x3f|0x00f0) ncmd 2
        Status: Success (0x00)
        03 00

//Got event from the pattern monitor
> HCI Event: Vendor (0xff) plen 18                   torvalds#148 [hci0] 58.384953
        23 79 54 33 77 88 97 68 02 00 fb c1 29 eb 27 b8  #yT3w..h....).'.
        00 01                                            ..

//Add MSFT address monitor (Sample address: B8:27:EB:29:C1:FB)
< HCI Command: Vendor (0x3f|0x00f0) plen 13          torvalds#149 [hci0] 58.385067
        03 b8 a4 03 ff 04 00 fb c1 29 eb 27 b8           .........).'.

//Report to userspace about found device (ADV Monitor Device Found)
@ MGMT Event: Unknown (0x002f) plen 38           {0x0003} [hci0] 58.680042
        01 00 fb c1 29 eb 27 b8 01 ce 00 00 00 00 16 00  ....).'.........
        0a 09 4b 45 59 42 44 5f 52 45 46 02 01 06 03 19  ..KEYBD_REF.....
        c1 03 03 03 12 18                                ......

//Got event from address monitor
> HCI Event: Vendor (0xff) plen 18                   torvalds#152 [hci0] 58.672956
        23 79 54 33 77 88 97 68 02 00 fb c1 29 eb 27 b8  #yT3w..h....).'.
        01 01

Signed-off-by: Alex Lu <alex_lu@realsil.com.cn>
Signed-off-by: Hilda Wu <hildawu@realtek.com>
Reviewed-by: Simon Horman <simon.horman@corigine.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
mj22226 pushed a commit to mj22226/linux that referenced this pull request Jul 30, 2023
Update broadcom drivers from Infineon.

Signed-off-by: Stephen Chen <stephen@radxa.com>
intel-lab-lkp pushed a commit to intel-lab-lkp/linux that referenced this pull request Aug 11, 2023
Since limited tracking device per condition, this feature is to support
tracking multiple devices concurrently.
When a pattern monitor detects the device, this feature issues an address
monitor for tracking that device. Let pattern monitor can keep monitor
new devices.
This feature adds an address filter when receiving a LE monitor device
event which monitor handle is for a pattern, and the controller started
monitoring the device. And this feature also has cancelled the monitor
advertisement from address filters when receiving a LE monitor device
event when the controller stopped monitoring the device specified by an
address and monitor handle.

Below is an example to know the feature adds the address filter.

//Add MSFT pattern monitor
< HCI Command: Vendor (0x3f|0x00f0) plen 14          torvalds#142 [hci0] 55.552420
        03 b8 a4 03 ff 01 01 06 09 05 5f 52 45 46        .........._REF
> HCI Event: Command Complete (0x0e) plen 6          torvalds#143 [hci0] 55.653960
      Vendor (0x3f|0x00f0) ncmd 2
        Status: Success (0x00)
        03 00

//Got event from the pattern monitor
> HCI Event: Vendor (0xff) plen 18                   torvalds#148 [hci0] 58.384953
        23 79 54 33 77 88 97 68 02 00 fb c1 29 eb 27 b8  #yT3w..h....).'.
        00 01                                            ..

//Add MSFT address monitor (Sample address: B8:27:EB:29:C1:FB)
< HCI Command: Vendor (0x3f|0x00f0) plen 13          torvalds#149 [hci0] 58.385067
        03 b8 a4 03 ff 04 00 fb c1 29 eb 27 b8           .........).'.

//Report to userspace about found device (ADV Monitor Device Found)
@ MGMT Event: Unknown (0x002f) plen 38           {0x0003} [hci0] 58.680042
        01 00 fb c1 29 eb 27 b8 01 ce 00 00 00 00 16 00  ....).'.........
        0a 09 4b 45 59 42 44 5f 52 45 46 02 01 06 03 19  ..KEYBD_REF.....
        c1 03 03 03 12 18                                ......

//Got event from address monitor
> HCI Event: Vendor (0xff) plen 18                   torvalds#152 [hci0] 58.672956
        23 79 54 33 77 88 97 68 02 00 fb c1 29 eb 27 b8  #yT3w..h....).'.
        01 01

Signed-off-by: Alex Lu <alex_lu@realsil.com.cn>
Signed-off-by: Hilda Wu <hildawu@realtek.com>
Reviewed-by: Simon Horman <simon.horman@corigine.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Kaz205 pushed a commit to Kaz205/linux that referenced this pull request Sep 11, 2023
[ Upstream commit 9e14606 ]

Since limited tracking device per condition, this feature is to support
tracking multiple devices concurrently.
When a pattern monitor detects the device, this feature issues an address
monitor for tracking that device. Let pattern monitor can keep monitor
new devices.
This feature adds an address filter when receiving a LE monitor device
event which monitor handle is for a pattern, and the controller started
monitoring the device. And this feature also has cancelled the monitor
advertisement from address filters when receiving a LE monitor device
event when the controller stopped monitoring the device specified by an
address and monitor handle.

Below is an example to know the feature adds the address filter.

//Add MSFT pattern monitor
< HCI Command: Vendor (0x3f|0x00f0) plen 14          torvalds#142 [hci0] 55.552420
        03 b8 a4 03 ff 01 01 06 09 05 5f 52 45 46        .........._REF
> HCI Event: Command Complete (0x0e) plen 6          torvalds#143 [hci0] 55.653960
      Vendor (0x3f|0x00f0) ncmd 2
        Status: Success (0x00)
        03 00

//Got event from the pattern monitor
> HCI Event: Vendor (0xff) plen 18                   torvalds#148 [hci0] 58.384953
        23 79 54 33 77 88 97 68 02 00 fb c1 29 eb 27 b8  #yT3w..h....).'.
        00 01                                            ..

//Add MSFT address monitor (Sample address: B8:27:EB:29:C1:FB)
< HCI Command: Vendor (0x3f|0x00f0) plen 13          torvalds#149 [hci0] 58.385067
        03 b8 a4 03 ff 04 00 fb c1 29 eb 27 b8           .........).'.

//Report to userspace about found device (ADV Monitor Device Found)
@ MGMT Event: Unknown (0x002f) plen 38           {0x0003} [hci0] 58.680042
        01 00 fb c1 29 eb 27 b8 01 ce 00 00 00 00 16 00  ....).'.........
        0a 09 4b 45 59 42 44 5f 52 45 46 02 01 06 03 19  ..KEYBD_REF.....
        c1 03 03 03 12 18                                ......

//Got event from address monitor
> HCI Event: Vendor (0xff) plen 18                   torvalds#152 [hci0] 58.672956
        23 79 54 33 77 88 97 68 02 00 fb c1 29 eb 27 b8  #yT3w..h....).'.
        01 01

Signed-off-by: Alex Lu <alex_lu@realsil.com.cn>
Signed-off-by: Hilda Wu <hildawu@realtek.com>
Reviewed-by: Simon Horman <simon.horman@corigine.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Stable-dep-of: 253f339 ("Bluetooth: HCI: Introduce HCI_QUIRK_BROKEN_LE_CODED")
Signed-off-by: Sasha Levin <sashal@kernel.org>
mj22226 pushed a commit to mj22226/linux that referenced this pull request Sep 11, 2023
[ Upstream commit 9e14606 ]

Since limited tracking device per condition, this feature is to support
tracking multiple devices concurrently.
When a pattern monitor detects the device, this feature issues an address
monitor for tracking that device. Let pattern monitor can keep monitor
new devices.
This feature adds an address filter when receiving a LE monitor device
event which monitor handle is for a pattern, and the controller started
monitoring the device. And this feature also has cancelled the monitor
advertisement from address filters when receiving a LE monitor device
event when the controller stopped monitoring the device specified by an
address and monitor handle.

Below is an example to know the feature adds the address filter.

//Add MSFT pattern monitor
< HCI Command: Vendor (0x3f|0x00f0) plen 14          torvalds#142 [hci0] 55.552420
        03 b8 a4 03 ff 01 01 06 09 05 5f 52 45 46        .........._REF
> HCI Event: Command Complete (0x0e) plen 6          torvalds#143 [hci0] 55.653960
      Vendor (0x3f|0x00f0) ncmd 2
        Status: Success (0x00)
        03 00

//Got event from the pattern monitor
> HCI Event: Vendor (0xff) plen 18                   torvalds#148 [hci0] 58.384953
        23 79 54 33 77 88 97 68 02 00 fb c1 29 eb 27 b8  #yT3w..h....).'.
        00 01                                            ..

//Add MSFT address monitor (Sample address: B8:27:EB:29:C1:FB)
< HCI Command: Vendor (0x3f|0x00f0) plen 13          torvalds#149 [hci0] 58.385067
        03 b8 a4 03 ff 04 00 fb c1 29 eb 27 b8           .........).'.

//Report to userspace about found device (ADV Monitor Device Found)
@ MGMT Event: Unknown (0x002f) plen 38           {0x0003} [hci0] 58.680042
        01 00 fb c1 29 eb 27 b8 01 ce 00 00 00 00 16 00  ....).'.........
        0a 09 4b 45 59 42 44 5f 52 45 46 02 01 06 03 19  ..KEYBD_REF.....
        c1 03 03 03 12 18                                ......

//Got event from address monitor
> HCI Event: Vendor (0xff) plen 18                   torvalds#152 [hci0] 58.672956
        23 79 54 33 77 88 97 68 02 00 fb c1 29 eb 27 b8  #yT3w..h....).'.
        01 01

Signed-off-by: Alex Lu <alex_lu@realsil.com.cn>
Signed-off-by: Hilda Wu <hildawu@realtek.com>
Reviewed-by: Simon Horman <simon.horman@corigine.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Stable-dep-of: 253f339 ("Bluetooth: HCI: Introduce HCI_QUIRK_BROKEN_LE_CODED")
Signed-off-by: Sasha Levin <sashal@kernel.org>
intersectRaven pushed a commit to intersectRaven/linux that referenced this pull request Sep 13, 2023
[ Upstream commit 9e14606 ]

Since limited tracking device per condition, this feature is to support
tracking multiple devices concurrently.
When a pattern monitor detects the device, this feature issues an address
monitor for tracking that device. Let pattern monitor can keep monitor
new devices.
This feature adds an address filter when receiving a LE monitor device
event which monitor handle is for a pattern, and the controller started
monitoring the device. And this feature also has cancelled the monitor
advertisement from address filters when receiving a LE monitor device
event when the controller stopped monitoring the device specified by an
address and monitor handle.

Below is an example to know the feature adds the address filter.

//Add MSFT pattern monitor
< HCI Command: Vendor (0x3f|0x00f0) plen 14          torvalds#142 [hci0] 55.552420
        03 b8 a4 03 ff 01 01 06 09 05 5f 52 45 46        .........._REF
> HCI Event: Command Complete (0x0e) plen 6          torvalds#143 [hci0] 55.653960
      Vendor (0x3f|0x00f0) ncmd 2
        Status: Success (0x00)
        03 00

//Got event from the pattern monitor
> HCI Event: Vendor (0xff) plen 18                   torvalds#148 [hci0] 58.384953
        23 79 54 33 77 88 97 68 02 00 fb c1 29 eb 27 b8  #yT3w..h....).'.
        00 01                                            ..

//Add MSFT address monitor (Sample address: B8:27:EB:29:C1:FB)
< HCI Command: Vendor (0x3f|0x00f0) plen 13          torvalds#149 [hci0] 58.385067
        03 b8 a4 03 ff 04 00 fb c1 29 eb 27 b8           .........).'.

//Report to userspace about found device (ADV Monitor Device Found)
@ MGMT Event: Unknown (0x002f) plen 38           {0x0003} [hci0] 58.680042
        01 00 fb c1 29 eb 27 b8 01 ce 00 00 00 00 16 00  ....).'.........
        0a 09 4b 45 59 42 44 5f 52 45 46 02 01 06 03 19  ..KEYBD_REF.....
        c1 03 03 03 12 18                                ......

//Got event from address monitor
> HCI Event: Vendor (0xff) plen 18                   torvalds#152 [hci0] 58.672956
        23 79 54 33 77 88 97 68 02 00 fb c1 29 eb 27 b8  #yT3w..h....).'.
        01 01

Signed-off-by: Alex Lu <alex_lu@realsil.com.cn>
Signed-off-by: Hilda Wu <hildawu@realtek.com>
Reviewed-by: Simon Horman <simon.horman@corigine.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Stable-dep-of: 253f339 ("Bluetooth: HCI: Introduce HCI_QUIRK_BROKEN_LE_CODED")
Signed-off-by: Sasha Levin <sashal@kernel.org>
1054009064 pushed a commit to 1054009064/linux that referenced this pull request Sep 13, 2023
[ Upstream commit 9e14606 ]

Since limited tracking device per condition, this feature is to support
tracking multiple devices concurrently.
When a pattern monitor detects the device, this feature issues an address
monitor for tracking that device. Let pattern monitor can keep monitor
new devices.
This feature adds an address filter when receiving a LE monitor device
event which monitor handle is for a pattern, and the controller started
monitoring the device. And this feature also has cancelled the monitor
advertisement from address filters when receiving a LE monitor device
event when the controller stopped monitoring the device specified by an
address and monitor handle.

Below is an example to know the feature adds the address filter.

//Add MSFT pattern monitor
< HCI Command: Vendor (0x3f|0x00f0) plen 14          torvalds#142 [hci0] 55.552420
        03 b8 a4 03 ff 01 01 06 09 05 5f 52 45 46        .........._REF
> HCI Event: Command Complete (0x0e) plen 6          torvalds#143 [hci0] 55.653960
      Vendor (0x3f|0x00f0) ncmd 2
        Status: Success (0x00)
        03 00

//Got event from the pattern monitor
> HCI Event: Vendor (0xff) plen 18                   torvalds#148 [hci0] 58.384953
        23 79 54 33 77 88 97 68 02 00 fb c1 29 eb 27 b8  #yT3w..h....).'.
        00 01                                            ..

//Add MSFT address monitor (Sample address: B8:27:EB:29:C1:FB)
< HCI Command: Vendor (0x3f|0x00f0) plen 13          torvalds#149 [hci0] 58.385067
        03 b8 a4 03 ff 04 00 fb c1 29 eb 27 b8           .........).'.

//Report to userspace about found device (ADV Monitor Device Found)
@ MGMT Event: Unknown (0x002f) plen 38           {0x0003} [hci0] 58.680042
        01 00 fb c1 29 eb 27 b8 01 ce 00 00 00 00 16 00  ....).'.........
        0a 09 4b 45 59 42 44 5f 52 45 46 02 01 06 03 19  ..KEYBD_REF.....
        c1 03 03 03 12 18                                ......

//Got event from address monitor
> HCI Event: Vendor (0xff) plen 18                   torvalds#152 [hci0] 58.672956
        23 79 54 33 77 88 97 68 02 00 fb c1 29 eb 27 b8  #yT3w..h....).'.
        01 01

Signed-off-by: Alex Lu <alex_lu@realsil.com.cn>
Signed-off-by: Hilda Wu <hildawu@realtek.com>
Reviewed-by: Simon Horman <simon.horman@corigine.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Stable-dep-of: 253f339 ("Bluetooth: HCI: Introduce HCI_QUIRK_BROKEN_LE_CODED")
Signed-off-by: Sasha Levin <sashal@kernel.org>
Joshua-Riek pushed a commit to Joshua-Riek/linux that referenced this pull request Oct 24, 2023
BugLink: https://bugs.launchpad.net/bugs/2035588

[ Upstream commit 9e14606 ]

Since limited tracking device per condition, this feature is to support
tracking multiple devices concurrently.
When a pattern monitor detects the device, this feature issues an address
monitor for tracking that device. Let pattern monitor can keep monitor
new devices.
This feature adds an address filter when receiving a LE monitor device
event which monitor handle is for a pattern, and the controller started
monitoring the device. And this feature also has cancelled the monitor
advertisement from address filters when receiving a LE monitor device
event when the controller stopped monitoring the device specified by an
address and monitor handle.

Below is an example to know the feature adds the address filter.

//Add MSFT pattern monitor
< HCI Command: Vendor (0x3f|0x00f0) plen 14          torvalds#142 [hci0] 55.552420
        03 b8 a4 03 ff 01 01 06 09 05 5f 52 45 46        .........._REF
> HCI Event: Command Complete (0x0e) plen 6          torvalds#143 [hci0] 55.653960
      Vendor (0x3f|0x00f0) ncmd 2
        Status: Success (0x00)
        03 00

//Got event from the pattern monitor
> HCI Event: Vendor (0xff) plen 18                   torvalds#148 [hci0] 58.384953
        23 79 54 33 77 88 97 68 02 00 fb c1 29 eb 27 b8  #yT3w..h....).'.
        00 01                                            ..

//Add MSFT address monitor (Sample address: B8:27:EB:29:C1:FB)
< HCI Command: Vendor (0x3f|0x00f0) plen 13          torvalds#149 [hci0] 58.385067
        03 b8 a4 03 ff 04 00 fb c1 29 eb 27 b8           .........).'.

//Report to userspace about found device (ADV Monitor Device Found)
@ MGMT Event: Unknown (0x002f) plen 38           {0x0003} [hci0] 58.680042
        01 00 fb c1 29 eb 27 b8 01 ce 00 00 00 00 16 00  ....).'.........
        0a 09 4b 45 59 42 44 5f 52 45 46 02 01 06 03 19  ..KEYBD_REF.....
        c1 03 03 03 12 18                                ......

//Got event from address monitor
> HCI Event: Vendor (0xff) plen 18                   torvalds#152 [hci0] 58.672956
        23 79 54 33 77 88 97 68 02 00 fb c1 29 eb 27 b8  #yT3w..h....).'.
        01 01

Signed-off-by: Alex Lu <alex_lu@realsil.com.cn>
Signed-off-by: Hilda Wu <hildawu@realtek.com>
Reviewed-by: Simon Horman <simon.horman@corigine.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Stable-dep-of: 253f339 ("Bluetooth: HCI: Introduce HCI_QUIRK_BROKEN_LE_CODED")
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
intel-lab-lkp pushed a commit to intel-lab-lkp/linux that referenced this pull request Jan 26, 2024
Use drm_edid helpers to fix a null-pointer derefence that happens when
running igt@kms_force_connector_basic in a system with DCN2.1 and HDMI
connector detected as below:

[  +0.178146] BUG: kernel NULL pointer dereference, address: 00000000000004c0
[  +0.000010] #PF: supervisor read access in kernel mode
[  +0.000005] #PF: error_code(0x0000) - not-present page
[  +0.000004] PGD 0 P4D 0
[  +0.000006] Oops: 0000 [#1] PREEMPT SMP NOPTI
[  +0.000006] CPU: 15 PID: 2368 Comm: kms_force_conne Not tainted 6.5.0-asdn+ torvalds#152
[  +0.000005] Hardware name: HP HP ENVY x360 Convertible 13-ay1xxx/8929, BIOS F.01 07/14/2021
[  +0.000004] RIP: 0010:i2c_transfer+0xd/0x100
[  +0.000011] Code: ea fc ff ff 66 0f 1f 84 00 00 00 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 0f 1f 44 00 00 41 54 55 53 <48> 8b 47 10 48 89 fb 48 83 38 00 0f 84 b3 00 00 00 83 3d 2f 80 16
[  +0.000004] RSP: 0018:ffff9c4f89c0fad0 EFLAGS: 00010246
[  +0.000005] RAX: 0000000000000000 RBX: 0000000000000005 RCX: 0000000000000080
[  +0.000003] RDX: 0000000000000002 RSI: ffff9c4f89c0fb20 RDI: 00000000000004b0
[  +0.000003] RBP: ffff9c4f89c0fb80 R08: 0000000000000080 R09: ffff8d8e0b15b980
[  +0.000003] R10: 00000000000380e0 R11: 0000000000000000 R12: 0000000000000080
[  +0.000002] R13: 0000000000000002 R14: ffff9c4f89c0fb0e R15: ffff9c4f89c0fb0f
[  +0.000004] FS:  00007f9ad2176c40(0000) GS:ffff8d90fe9c0000(0000) knlGS:0000000000000000
[  +0.000003] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  +0.000004] CR2: 00000000000004c0 CR3: 0000000121bc4000 CR4: 0000000000750ee0
[  +0.000003] PKRU: 55555554
[  +0.000003] Call Trace:
[  +0.000006]  <TASK>
[  +0.000006]  ? __die+0x23/0x70
[  +0.000011]  ? page_fault_oops+0x17d/0x4c0
[  +0.000008]  ? preempt_count_add+0x6e/0xa0
[  +0.000008]  ? srso_alias_return_thunk+0x5/0x7f
[  +0.000011]  ? exc_page_fault+0x7f/0x180
[  +0.000009]  ? asm_exc_page_fault+0x26/0x30
[  +0.000013]  ? i2c_transfer+0xd/0x100
[  +0.000010]  drm_do_probe_ddc_edid+0xc2/0x140 [drm]
[  +0.000067]  ? srso_alias_return_thunk+0x5/0x7f
[  +0.000006]  ? _drm_do_get_edid+0x97/0x3c0 [drm]
[  +0.000043]  ? __pfx_drm_do_probe_ddc_edid+0x10/0x10 [drm]
[  +0.000042]  edid_block_read+0x3b/0xd0 [drm]
[  +0.000043]  _drm_do_get_edid+0xb6/0x3c0 [drm]
[  +0.000041]  ? __pfx_drm_do_probe_ddc_edid+0x10/0x10 [drm]
[  +0.000043]  drm_edid_read_custom+0x37/0xd0 [drm]
[  +0.000044]  amdgpu_dm_connector_mode_valid+0x129/0x1d0 [amdgpu]
[  +0.000153]  drm_connector_mode_valid+0x3b/0x60 [drm_kms_helper]
[  +0.000000]  __drm_helper_update_and_validate+0xfe/0x3c0 [drm_kms_helper]
[  +0.000000]  ? amdgpu_dm_connector_get_modes+0xb6/0x520 [amdgpu]
[  +0.000000]  ? srso_alias_return_thunk+0x5/0x7f
[  +0.000000]  drm_helper_probe_single_connector_modes+0x2ab/0x540 [drm_kms_helper]
[  +0.000000]  status_store+0xb2/0x1f0 [drm]
[  +0.000000]  kernfs_fop_write_iter+0x136/0x1d0
[  +0.000000]  vfs_write+0x24d/0x440
[  +0.000000]  ksys_write+0x6f/0xf0
[  +0.000000]  do_syscall_64+0x60/0xc0
[  +0.000000]  ? srso_alias_return_thunk+0x5/0x7f
[  +0.000000]  ? syscall_exit_to_user_mode+0x2b/0x40
[  +0.000000]  ? srso_alias_return_thunk+0x5/0x7f
[  +0.000000]  ? do_syscall_64+0x6c/0xc0
[  +0.000000]  ? do_syscall_64+0x6c/0xc0
[  +0.000000]  entry_SYSCALL_64_after_hwframe+0x6e/0xd8
[  +0.000000] RIP: 0033:0x7f9ad46b4b00
[  +0.000000] Code: 40 00 48 8b 15 19 b3 0d 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 00 80 3d e1 3a 0e 00 00 74 17 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 58 c3 0f 1f 80 00 00 00 00 48 83 ec 28 48 89
[  +0.000000] RSP: 002b:00007ffcbd3bd6d8 EFLAGS: 00000202 ORIG_RAX: 0000000000000001
[  +0.000000] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f9ad46b4b00
[  +0.000000] RDX: 0000000000000002 RSI: 00007f9ad48a7417 RDI: 0000000000000009
[  +0.000000] RBP: 0000000000000002 R08: 0000000000000064 R09: 0000000000000000
[  +0.000000] R10: 0000000000000000 R11: 0000000000000202 R12: 00007f9ad48a7417
[  +0.000000] R13: 0000000000000009 R14: 00007ffcbd3bd760 R15: 0000000000000001
[  +0.000000]  </TASK>
[  +0.000000] Modules linked in: ctr ccm rfcomm snd_seq_dummy snd_hrtimer snd_seq snd_seq_device cmac algif_hash algif_skcipher af_alg bnep btusb btrtl btbcm btintel btmtk bluetooth uvcvideo videobuf2_vmalloc sha3_generic videobuf2_memops uvc jitterentropy_rng videobuf2_v4l2 videodev drbg videobuf2_common ansi_cprng mc ecdh_generic ecc qrtr binfmt_misc hid_sensor_accel_3d hid_sensor_magn_3d hid_sensor_gyro_3d hid_sensor_trigger industrialio_triggered_buffer kfifo_buf industrialio snd_ctl_led joydev hid_sensor_iio_common rtw89_8852ae rtw89_8852a rtw89_pci snd_hda_codec_realtek rtw89_core snd_hda_codec_generic intel_rapl_msr ledtrig_audio intel_rapl_common snd_hda_codec_hdmi mac80211 snd_hda_intel snd_intel_dspcfg kvm_amd snd_hda_codec snd_soc_dmic snd_acp3x_rn snd_acp3x_pdm_dma libarc4 snd_hwdep snd_soc_core kvm snd_hda_core cfg80211 snd_pci_acp6x snd_pcm nls_ascii snd_timer hp_wmi snd_pci_acp5x nls_cp437 snd_rn_pci_acp3x ucsi_acpi sparse_keymap ccp snd platform_profile snd_acp_config typec_ucsi irqbypass vfat sp5100_tco
[  +0.000000]  snd_soc_acpi fat rapl pcspkr wmi_bmof roles rfkill rng_core snd_pci_acp3x soundcore k10temp watchdog typec battery ac amd_pmc acpi_tad button hid_sensor_hub hid_multitouch evdev serio_raw msr parport_pc ppdev lp parport fuse loop efi_pstore configfs ip_tables x_tables autofs4 ext4 crc16 mbcache jbd2 btrfs blake2b_generic dm_crypt dm_mod efivarfs raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx libcrc32c crc32c_generic xor raid6_pq raid1 raid0 multipath linear md_mod amdgpu amdxcp i2c_algo_bit drm_ttm_helper ttm crc32_pclmul crc32c_intel drm_exec gpu_sched drm_suballoc_helper nvme ghash_clmulni_intel drm_buddy drm_display_helper sha512_ssse3 nvme_core ahci xhci_pci sha512_generic hid_generic xhci_hcd libahci rtsx_pci_sdmmc t10_pi i2c_hid_acpi drm_kms_helper i2c_hid mmc_core libata aesni_intel crc64_rocksoft_generic crypto_simd amd_sfh crc64_rocksoft scsi_mod usbcore cryptd crc_t10dif cec drm crct10dif_generic hid rtsx_pci crct10dif_pclmul scsi_common rc_core crc64 i2c_piix4
[  +0.000000]  usb_common crct10dif_common video wmi
[  +0.000000] CR2: 00000000000004c0
[  +0.000000] ---[ end trace 0000000000000000 ]---

Fixes: e54ed41 ("drm/amd/display: Remove unwanted drm edid references")
Signed-off-by: Melissa Wen <mwen@igalia.com>
staging-kernelci-org pushed a commit to kernelci/linux that referenced this pull request Feb 23, 2024
Use i2c adapter when there isn't aux_mode in dc_link to fix a
null-pointer derefence that happens when running
igt@kms_force_connector_basic in a system with DCN2.1 and HDMI connector
detected as below:

[  +0.178146] BUG: kernel NULL pointer dereference, address: 00000000000004c0
[  +0.000010] #PF: supervisor read access in kernel mode
[  +0.000005] #PF: error_code(0x0000) - not-present page
[  +0.000004] PGD 0 P4D 0
[  +0.000006] Oops: 0000 [#1] PREEMPT SMP NOPTI
[  +0.000006] CPU: 15 PID: 2368 Comm: kms_force_conne Not tainted 6.5.0-asdn+ torvalds#152
[  +0.000005] Hardware name: HP HP ENVY x360 Convertible 13-ay1xxx/8929, BIOS F.01 07/14/2021
[  +0.000004] RIP: 0010:i2c_transfer+0xd/0x100
[  +0.000011] Code: ea fc ff ff 66 0f 1f 84 00 00 00 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 0f 1f 44 00 00 41 54 55 53 <48> 8b 47 10 48 89 fb 48 83 38 00 0f 84 b3 00 00 00 83 3d 2f 80 16
[  +0.000004] RSP: 0018:ffff9c4f89c0fad0 EFLAGS: 00010246
[  +0.000005] RAX: 0000000000000000 RBX: 0000000000000005 RCX: 0000000000000080
[  +0.000003] RDX: 0000000000000002 RSI: ffff9c4f89c0fb20 RDI: 00000000000004b0
[  +0.000003] RBP: ffff9c4f89c0fb80 R08: 0000000000000080 R09: ffff8d8e0b15b980
[  +0.000003] R10: 00000000000380e0 R11: 0000000000000000 R12: 0000000000000080
[  +0.000002] R13: 0000000000000002 R14: ffff9c4f89c0fb0e R15: ffff9c4f89c0fb0f
[  +0.000004] FS:  00007f9ad2176c40(0000) GS:ffff8d90fe9c0000(0000) knlGS:0000000000000000
[  +0.000003] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  +0.000004] CR2: 00000000000004c0 CR3: 0000000121bc4000 CR4: 0000000000750ee0
[  +0.000003] PKRU: 55555554
[  +0.000003] Call Trace:
[  +0.000006]  <TASK>
[  +0.000006]  ? __die+0x23/0x70
[  +0.000011]  ? page_fault_oops+0x17d/0x4c0
[  +0.000008]  ? preempt_count_add+0x6e/0xa0
[  +0.000008]  ? srso_alias_return_thunk+0x5/0x7f
[  +0.000011]  ? exc_page_fault+0x7f/0x180
[  +0.000009]  ? asm_exc_page_fault+0x26/0x30
[  +0.000013]  ? i2c_transfer+0xd/0x100
[  +0.000010]  drm_do_probe_ddc_edid+0xc2/0x140 [drm]
[  +0.000067]  ? srso_alias_return_thunk+0x5/0x7f
[  +0.000006]  ? _drm_do_get_edid+0x97/0x3c0 [drm]
[  +0.000043]  ? __pfx_drm_do_probe_ddc_edid+0x10/0x10 [drm]
[  +0.000042]  edid_block_read+0x3b/0xd0 [drm]
[  +0.000043]  _drm_do_get_edid+0xb6/0x3c0 [drm]
[  +0.000041]  ? __pfx_drm_do_probe_ddc_edid+0x10/0x10 [drm]
[  +0.000043]  drm_edid_read_custom+0x37/0xd0 [drm]
[  +0.000044]  amdgpu_dm_connector_mode_valid+0x129/0x1d0 [amdgpu]
[  +0.000153]  drm_connector_mode_valid+0x3b/0x60 [drm_kms_helper]
[  +0.000000]  __drm_helper_update_and_validate+0xfe/0x3c0 [drm_kms_helper]
[  +0.000000]  ? amdgpu_dm_connector_get_modes+0xb6/0x520 [amdgpu]
[  +0.000000]  ? srso_alias_return_thunk+0x5/0x7f
[  +0.000000]  drm_helper_probe_single_connector_modes+0x2ab/0x540 [drm_kms_helper]
[  +0.000000]  status_store+0xb2/0x1f0 [drm]
[  +0.000000]  kernfs_fop_write_iter+0x136/0x1d0
[  +0.000000]  vfs_write+0x24d/0x440
[  +0.000000]  ksys_write+0x6f/0xf0
[  +0.000000]  do_syscall_64+0x60/0xc0
[  +0.000000]  ? srso_alias_return_thunk+0x5/0x7f
[  +0.000000]  ? syscall_exit_to_user_mode+0x2b/0x40
[  +0.000000]  ? srso_alias_return_thunk+0x5/0x7f
[  +0.000000]  ? do_syscall_64+0x6c/0xc0
[  +0.000000]  ? do_syscall_64+0x6c/0xc0
[  +0.000000]  entry_SYSCALL_64_after_hwframe+0x6e/0xd8
[  +0.000000] RIP: 0033:0x7f9ad46b4b00
[  +0.000000] Code: 40 00 48 8b 15 19 b3 0d 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 00 80 3d e1 3a 0e 00 00 74 17 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 58 c3 0f 1f 80 00 00 00 00 48 83 ec 28 48 89
[  +0.000000] RSP: 002b:00007ffcbd3bd6d8 EFLAGS: 00000202 ORIG_RAX: 0000000000000001
[  +0.000000] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f9ad46b4b00
[  +0.000000] RDX: 0000000000000002 RSI: 00007f9ad48a7417 RDI: 0000000000000009
[  +0.000000] RBP: 0000000000000002 R08: 0000000000000064 R09: 0000000000000000
[  +0.000000] R10: 0000000000000000 R11: 0000000000000202 R12: 00007f9ad48a7417
[  +0.000000] R13: 0000000000000009 R14: 00007ffcbd3bd760 R15: 0000000000000001
[  +0.000000]  </TASK>
[  +0.000000] Modules linked in: ctr ccm rfcomm snd_seq_dummy snd_hrtimer snd_seq snd_seq_device cmac algif_hash algif_skcipher af_alg bnep btusb btrtl btbcm btintel btmtk bluetooth uvcvideo videobuf2_vmalloc sha3_generic videobuf2_memops uvc jitterentropy_rng videobuf2_v4l2 videodev drbg videobuf2_common ansi_cprng mc ecdh_generic ecc qrtr binfmt_misc hid_sensor_accel_3d hid_sensor_magn_3d hid_sensor_gyro_3d hid_sensor_trigger industrialio_triggered_buffer kfifo_buf industrialio snd_ctl_led joydev hid_sensor_iio_common rtw89_8852ae rtw89_8852a rtw89_pci snd_hda_codec_realtek rtw89_core snd_hda_codec_generic intel_rapl_msr ledtrig_audio intel_rapl_common snd_hda_codec_hdmi mac80211 snd_hda_intel snd_intel_dspcfg kvm_amd snd_hda_codec snd_soc_dmic snd_acp3x_rn snd_acp3x_pdm_dma libarc4 snd_hwdep snd_soc_core kvm snd_hda_core cfg80211 snd_pci_acp6x snd_pcm nls_ascii snd_timer hp_wmi snd_pci_acp5x nls_cp437 snd_rn_pci_acp3x ucsi_acpi sparse_keymap ccp snd platform_profile snd_acp_config typec_ucsi irqbypass vfat sp5100_tco
[  +0.000000]  snd_soc_acpi fat rapl pcspkr wmi_bmof roles rfkill rng_core snd_pci_acp3x soundcore k10temp watchdog typec battery ac amd_pmc acpi_tad button hid_sensor_hub hid_multitouch evdev serio_raw msr parport_pc ppdev lp parport fuse loop efi_pstore configfs ip_tables x_tables autofs4 ext4 crc16 mbcache jbd2 btrfs blake2b_generic dm_crypt dm_mod efivarfs raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx libcrc32c crc32c_generic xor raid6_pq raid1 raid0 multipath linear md_mod amdgpu amdxcp i2c_algo_bit drm_ttm_helper ttm crc32_pclmul crc32c_intel drm_exec gpu_sched drm_suballoc_helper nvme ghash_clmulni_intel drm_buddy drm_display_helper sha512_ssse3 nvme_core ahci xhci_pci sha512_generic hid_generic xhci_hcd libahci rtsx_pci_sdmmc t10_pi i2c_hid_acpi drm_kms_helper i2c_hid mmc_core libata aesni_intel crc64_rocksoft_generic crypto_simd amd_sfh crc64_rocksoft scsi_mod usbcore cryptd crc_t10dif cec drm crct10dif_generic hid rtsx_pci crct10dif_pclmul scsi_common rc_core crc64 i2c_piix4
[  +0.000000]  usb_common crct10dif_common video wmi
[  +0.000000] CR2: 00000000000004c0
[  +0.000000] ---[ end trace 0000000000000000 ]---

Fixes: 0e859fa ("drm/amd/display: Remove unwanted drm edid references")
Signed-off-by: Melissa Wen <mwen@igalia.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
torvalds pushed a commit that referenced this pull request Feb 23, 2024
Use i2c adapter when there isn't aux_mode in dc_link to fix a
null-pointer derefence that happens when running
igt@kms_force_connector_basic in a system with DCN2.1 and HDMI connector
detected as below:

[  +0.178146] BUG: kernel NULL pointer dereference, address: 00000000000004c0
[  +0.000010] #PF: supervisor read access in kernel mode
[  +0.000005] #PF: error_code(0x0000) - not-present page
[  +0.000004] PGD 0 P4D 0
[  +0.000006] Oops: 0000 [#1] PREEMPT SMP NOPTI
[  +0.000006] CPU: 15 PID: 2368 Comm: kms_force_conne Not tainted 6.5.0-asdn+ #152
[  +0.000005] Hardware name: HP HP ENVY x360 Convertible 13-ay1xxx/8929, BIOS F.01 07/14/2021
[  +0.000004] RIP: 0010:i2c_transfer+0xd/0x100
[  +0.000011] Code: ea fc ff ff 66 0f 1f 84 00 00 00 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 0f 1f 44 00 00 41 54 55 53 <48> 8b 47 10 48 89 fb 48 83 38 00 0f 84 b3 00 00 00 83 3d 2f 80 16
[  +0.000004] RSP: 0018:ffff9c4f89c0fad0 EFLAGS: 00010246
[  +0.000005] RAX: 0000000000000000 RBX: 0000000000000005 RCX: 0000000000000080
[  +0.000003] RDX: 0000000000000002 RSI: ffff9c4f89c0fb20 RDI: 00000000000004b0
[  +0.000003] RBP: ffff9c4f89c0fb80 R08: 0000000000000080 R09: ffff8d8e0b15b980
[  +0.000003] R10: 00000000000380e0 R11: 0000000000000000 R12: 0000000000000080
[  +0.000002] R13: 0000000000000002 R14: ffff9c4f89c0fb0e R15: ffff9c4f89c0fb0f
[  +0.000004] FS:  00007f9ad2176c40(0000) GS:ffff8d90fe9c0000(0000) knlGS:0000000000000000
[  +0.000003] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  +0.000004] CR2: 00000000000004c0 CR3: 0000000121bc4000 CR4: 0000000000750ee0
[  +0.000003] PKRU: 55555554
[  +0.000003] Call Trace:
[  +0.000006]  <TASK>
[  +0.000006]  ? __die+0x23/0x70
[  +0.000011]  ? page_fault_oops+0x17d/0x4c0
[  +0.000008]  ? preempt_count_add+0x6e/0xa0
[  +0.000008]  ? srso_alias_return_thunk+0x5/0x7f
[  +0.000011]  ? exc_page_fault+0x7f/0x180
[  +0.000009]  ? asm_exc_page_fault+0x26/0x30
[  +0.000013]  ? i2c_transfer+0xd/0x100
[  +0.000010]  drm_do_probe_ddc_edid+0xc2/0x140 [drm]
[  +0.000067]  ? srso_alias_return_thunk+0x5/0x7f
[  +0.000006]  ? _drm_do_get_edid+0x97/0x3c0 [drm]
[  +0.000043]  ? __pfx_drm_do_probe_ddc_edid+0x10/0x10 [drm]
[  +0.000042]  edid_block_read+0x3b/0xd0 [drm]
[  +0.000043]  _drm_do_get_edid+0xb6/0x3c0 [drm]
[  +0.000041]  ? __pfx_drm_do_probe_ddc_edid+0x10/0x10 [drm]
[  +0.000043]  drm_edid_read_custom+0x37/0xd0 [drm]
[  +0.000044]  amdgpu_dm_connector_mode_valid+0x129/0x1d0 [amdgpu]
[  +0.000153]  drm_connector_mode_valid+0x3b/0x60 [drm_kms_helper]
[  +0.000000]  __drm_helper_update_and_validate+0xfe/0x3c0 [drm_kms_helper]
[  +0.000000]  ? amdgpu_dm_connector_get_modes+0xb6/0x520 [amdgpu]
[  +0.000000]  ? srso_alias_return_thunk+0x5/0x7f
[  +0.000000]  drm_helper_probe_single_connector_modes+0x2ab/0x540 [drm_kms_helper]
[  +0.000000]  status_store+0xb2/0x1f0 [drm]
[  +0.000000]  kernfs_fop_write_iter+0x136/0x1d0
[  +0.000000]  vfs_write+0x24d/0x440
[  +0.000000]  ksys_write+0x6f/0xf0
[  +0.000000]  do_syscall_64+0x60/0xc0
[  +0.000000]  ? srso_alias_return_thunk+0x5/0x7f
[  +0.000000]  ? syscall_exit_to_user_mode+0x2b/0x40
[  +0.000000]  ? srso_alias_return_thunk+0x5/0x7f
[  +0.000000]  ? do_syscall_64+0x6c/0xc0
[  +0.000000]  ? do_syscall_64+0x6c/0xc0
[  +0.000000]  entry_SYSCALL_64_after_hwframe+0x6e/0xd8
[  +0.000000] RIP: 0033:0x7f9ad46b4b00
[  +0.000000] Code: 40 00 48 8b 15 19 b3 0d 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 00 80 3d e1 3a 0e 00 00 74 17 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 58 c3 0f 1f 80 00 00 00 00 48 83 ec 28 48 89
[  +0.000000] RSP: 002b:00007ffcbd3bd6d8 EFLAGS: 00000202 ORIG_RAX: 0000000000000001
[  +0.000000] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f9ad46b4b00
[  +0.000000] RDX: 0000000000000002 RSI: 00007f9ad48a7417 RDI: 0000000000000009
[  +0.000000] RBP: 0000000000000002 R08: 0000000000000064 R09: 0000000000000000
[  +0.000000] R10: 0000000000000000 R11: 0000000000000202 R12: 00007f9ad48a7417
[  +0.000000] R13: 0000000000000009 R14: 00007ffcbd3bd760 R15: 0000000000000001
[  +0.000000]  </TASK>
[  +0.000000] Modules linked in: ctr ccm rfcomm snd_seq_dummy snd_hrtimer snd_seq snd_seq_device cmac algif_hash algif_skcipher af_alg bnep btusb btrtl btbcm btintel btmtk bluetooth uvcvideo videobuf2_vmalloc sha3_generic videobuf2_memops uvc jitterentropy_rng videobuf2_v4l2 videodev drbg videobuf2_common ansi_cprng mc ecdh_generic ecc qrtr binfmt_misc hid_sensor_accel_3d hid_sensor_magn_3d hid_sensor_gyro_3d hid_sensor_trigger industrialio_triggered_buffer kfifo_buf industrialio snd_ctl_led joydev hid_sensor_iio_common rtw89_8852ae rtw89_8852a rtw89_pci snd_hda_codec_realtek rtw89_core snd_hda_codec_generic intel_rapl_msr ledtrig_audio intel_rapl_common snd_hda_codec_hdmi mac80211 snd_hda_intel snd_intel_dspcfg kvm_amd snd_hda_codec snd_soc_dmic snd_acp3x_rn snd_acp3x_pdm_dma libarc4 snd_hwdep snd_soc_core kvm snd_hda_core cfg80211 snd_pci_acp6x snd_pcm nls_ascii snd_timer hp_wmi snd_pci_acp5x nls_cp437 snd_rn_pci_acp3x ucsi_acpi sparse_keymap ccp snd platform_profile snd_acp_config typec_ucsi irqbypass vfat sp5100_tco
[  +0.000000]  snd_soc_acpi fat rapl pcspkr wmi_bmof roles rfkill rng_core snd_pci_acp3x soundcore k10temp watchdog typec battery ac amd_pmc acpi_tad button hid_sensor_hub hid_multitouch evdev serio_raw msr parport_pc ppdev lp parport fuse loop efi_pstore configfs ip_tables x_tables autofs4 ext4 crc16 mbcache jbd2 btrfs blake2b_generic dm_crypt dm_mod efivarfs raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx libcrc32c crc32c_generic xor raid6_pq raid1 raid0 multipath linear md_mod amdgpu amdxcp i2c_algo_bit drm_ttm_helper ttm crc32_pclmul crc32c_intel drm_exec gpu_sched drm_suballoc_helper nvme ghash_clmulni_intel drm_buddy drm_display_helper sha512_ssse3 nvme_core ahci xhci_pci sha512_generic hid_generic xhci_hcd libahci rtsx_pci_sdmmc t10_pi i2c_hid_acpi drm_kms_helper i2c_hid mmc_core libata aesni_intel crc64_rocksoft_generic crypto_simd amd_sfh crc64_rocksoft scsi_mod usbcore cryptd crc_t10dif cec drm crct10dif_generic hid rtsx_pci crct10dif_pclmul scsi_common rc_core crc64 i2c_piix4
[  +0.000000]  usb_common crct10dif_common video wmi
[  +0.000000] CR2: 00000000000004c0
[  +0.000000] ---[ end trace 0000000000000000 ]---

Fixes: 0e859fa ("drm/amd/display: Remove unwanted drm edid references")
Signed-off-by: Melissa Wen <mwen@igalia.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
intersectRaven pushed a commit to intersectRaven/linux that referenced this pull request Mar 1, 2024
[ Upstream commit 9671761 ]

Use i2c adapter when there isn't aux_mode in dc_link to fix a
null-pointer derefence that happens when running
igt@kms_force_connector_basic in a system with DCN2.1 and HDMI connector
detected as below:

[  +0.178146] BUG: kernel NULL pointer dereference, address: 00000000000004c0
[  +0.000010] #PF: supervisor read access in kernel mode
[  +0.000005] #PF: error_code(0x0000) - not-present page
[  +0.000004] PGD 0 P4D 0
[  +0.000006] Oops: 0000 [#1] PREEMPT SMP NOPTI
[  +0.000006] CPU: 15 PID: 2368 Comm: kms_force_conne Not tainted 6.5.0-asdn+ torvalds#152
[  +0.000005] Hardware name: HP HP ENVY x360 Convertible 13-ay1xxx/8929, BIOS F.01 07/14/2021
[  +0.000004] RIP: 0010:i2c_transfer+0xd/0x100
[  +0.000011] Code: ea fc ff ff 66 0f 1f 84 00 00 00 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 0f 1f 44 00 00 41 54 55 53 <48> 8b 47 10 48 89 fb 48 83 38 00 0f 84 b3 00 00 00 83 3d 2f 80 16
[  +0.000004] RSP: 0018:ffff9c4f89c0fad0 EFLAGS: 00010246
[  +0.000005] RAX: 0000000000000000 RBX: 0000000000000005 RCX: 0000000000000080
[  +0.000003] RDX: 0000000000000002 RSI: ffff9c4f89c0fb20 RDI: 00000000000004b0
[  +0.000003] RBP: ffff9c4f89c0fb80 R08: 0000000000000080 R09: ffff8d8e0b15b980
[  +0.000003] R10: 00000000000380e0 R11: 0000000000000000 R12: 0000000000000080
[  +0.000002] R13: 0000000000000002 R14: ffff9c4f89c0fb0e R15: ffff9c4f89c0fb0f
[  +0.000004] FS:  00007f9ad2176c40(0000) GS:ffff8d90fe9c0000(0000) knlGS:0000000000000000
[  +0.000003] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  +0.000004] CR2: 00000000000004c0 CR3: 0000000121bc4000 CR4: 0000000000750ee0
[  +0.000003] PKRU: 55555554
[  +0.000003] Call Trace:
[  +0.000006]  <TASK>
[  +0.000006]  ? __die+0x23/0x70
[  +0.000011]  ? page_fault_oops+0x17d/0x4c0
[  +0.000008]  ? preempt_count_add+0x6e/0xa0
[  +0.000008]  ? srso_alias_return_thunk+0x5/0x7f
[  +0.000011]  ? exc_page_fault+0x7f/0x180
[  +0.000009]  ? asm_exc_page_fault+0x26/0x30
[  +0.000013]  ? i2c_transfer+0xd/0x100
[  +0.000010]  drm_do_probe_ddc_edid+0xc2/0x140 [drm]
[  +0.000067]  ? srso_alias_return_thunk+0x5/0x7f
[  +0.000006]  ? _drm_do_get_edid+0x97/0x3c0 [drm]
[  +0.000043]  ? __pfx_drm_do_probe_ddc_edid+0x10/0x10 [drm]
[  +0.000042]  edid_block_read+0x3b/0xd0 [drm]
[  +0.000043]  _drm_do_get_edid+0xb6/0x3c0 [drm]
[  +0.000041]  ? __pfx_drm_do_probe_ddc_edid+0x10/0x10 [drm]
[  +0.000043]  drm_edid_read_custom+0x37/0xd0 [drm]
[  +0.000044]  amdgpu_dm_connector_mode_valid+0x129/0x1d0 [amdgpu]
[  +0.000153]  drm_connector_mode_valid+0x3b/0x60 [drm_kms_helper]
[  +0.000000]  __drm_helper_update_and_validate+0xfe/0x3c0 [drm_kms_helper]
[  +0.000000]  ? amdgpu_dm_connector_get_modes+0xb6/0x520 [amdgpu]
[  +0.000000]  ? srso_alias_return_thunk+0x5/0x7f
[  +0.000000]  drm_helper_probe_single_connector_modes+0x2ab/0x540 [drm_kms_helper]
[  +0.000000]  status_store+0xb2/0x1f0 [drm]
[  +0.000000]  kernfs_fop_write_iter+0x136/0x1d0
[  +0.000000]  vfs_write+0x24d/0x440
[  +0.000000]  ksys_write+0x6f/0xf0
[  +0.000000]  do_syscall_64+0x60/0xc0
[  +0.000000]  ? srso_alias_return_thunk+0x5/0x7f
[  +0.000000]  ? syscall_exit_to_user_mode+0x2b/0x40
[  +0.000000]  ? srso_alias_return_thunk+0x5/0x7f
[  +0.000000]  ? do_syscall_64+0x6c/0xc0
[  +0.000000]  ? do_syscall_64+0x6c/0xc0
[  +0.000000]  entry_SYSCALL_64_after_hwframe+0x6e/0xd8
[  +0.000000] RIP: 0033:0x7f9ad46b4b00
[  +0.000000] Code: 40 00 48 8b 15 19 b3 0d 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 00 80 3d e1 3a 0e 00 00 74 17 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 58 c3 0f 1f 80 00 00 00 00 48 83 ec 28 48 89
[  +0.000000] RSP: 002b:00007ffcbd3bd6d8 EFLAGS: 00000202 ORIG_RAX: 0000000000000001
[  +0.000000] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f9ad46b4b00
[  +0.000000] RDX: 0000000000000002 RSI: 00007f9ad48a7417 RDI: 0000000000000009
[  +0.000000] RBP: 0000000000000002 R08: 0000000000000064 R09: 0000000000000000
[  +0.000000] R10: 0000000000000000 R11: 0000000000000202 R12: 00007f9ad48a7417
[  +0.000000] R13: 0000000000000009 R14: 00007ffcbd3bd760 R15: 0000000000000001
[  +0.000000]  </TASK>
[  +0.000000] Modules linked in: ctr ccm rfcomm snd_seq_dummy snd_hrtimer snd_seq snd_seq_device cmac algif_hash algif_skcipher af_alg bnep btusb btrtl btbcm btintel btmtk bluetooth uvcvideo videobuf2_vmalloc sha3_generic videobuf2_memops uvc jitterentropy_rng videobuf2_v4l2 videodev drbg videobuf2_common ansi_cprng mc ecdh_generic ecc qrtr binfmt_misc hid_sensor_accel_3d hid_sensor_magn_3d hid_sensor_gyro_3d hid_sensor_trigger industrialio_triggered_buffer kfifo_buf industrialio snd_ctl_led joydev hid_sensor_iio_common rtw89_8852ae rtw89_8852a rtw89_pci snd_hda_codec_realtek rtw89_core snd_hda_codec_generic intel_rapl_msr ledtrig_audio intel_rapl_common snd_hda_codec_hdmi mac80211 snd_hda_intel snd_intel_dspcfg kvm_amd snd_hda_codec snd_soc_dmic snd_acp3x_rn snd_acp3x_pdm_dma libarc4 snd_hwdep snd_soc_core kvm snd_hda_core cfg80211 snd_pci_acp6x snd_pcm nls_ascii snd_timer hp_wmi snd_pci_acp5x nls_cp437 snd_rn_pci_acp3x ucsi_acpi sparse_keymap ccp snd platform_profile snd_acp_config typec_ucsi irqbypass vfat sp5100_tco
[  +0.000000]  snd_soc_acpi fat rapl pcspkr wmi_bmof roles rfkill rng_core snd_pci_acp3x soundcore k10temp watchdog typec battery ac amd_pmc acpi_tad button hid_sensor_hub hid_multitouch evdev serio_raw msr parport_pc ppdev lp parport fuse loop efi_pstore configfs ip_tables x_tables autofs4 ext4 crc16 mbcache jbd2 btrfs blake2b_generic dm_crypt dm_mod efivarfs raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx libcrc32c crc32c_generic xor raid6_pq raid1 raid0 multipath linear md_mod amdgpu amdxcp i2c_algo_bit drm_ttm_helper ttm crc32_pclmul crc32c_intel drm_exec gpu_sched drm_suballoc_helper nvme ghash_clmulni_intel drm_buddy drm_display_helper sha512_ssse3 nvme_core ahci xhci_pci sha512_generic hid_generic xhci_hcd libahci rtsx_pci_sdmmc t10_pi i2c_hid_acpi drm_kms_helper i2c_hid mmc_core libata aesni_intel crc64_rocksoft_generic crypto_simd amd_sfh crc64_rocksoft scsi_mod usbcore cryptd crc_t10dif cec drm crct10dif_generic hid rtsx_pci crct10dif_pclmul scsi_common rc_core crc64 i2c_piix4
[  +0.000000]  usb_common crct10dif_common video wmi
[  +0.000000] CR2: 00000000000004c0
[  +0.000000] ---[ end trace 0000000000000000 ]---

Fixes: 0e859fa ("drm/amd/display: Remove unwanted drm edid references")
Signed-off-by: Melissa Wen <mwen@igalia.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
rpardini pushed a commit to rpardini/linux that referenced this pull request Jul 9, 2024
intel-lab-lkp pushed a commit to intel-lab-lkp/linux that referenced this pull request Aug 19, 2024
The dtl_access_lock needs to be a rw_sempahore, a sleeping lock, because
the code calls kmalloc() while holding it, which can sleep:

  # echo 1 > /proc/powerpc/vcpudispatch_stats
  BUG: sleeping function called from invalid context at include/linux/sched/mm.h:337
  in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 199, name: sh
  preempt_count: 1, expected: 0
  3 locks held by sh/199:
   #0: c00000000a0743f8 (sb_writers#3){.+.+}-{0:0}, at: vfs_write+0x324/0x438
   #1: c0000000028c7058 (dtl_enable_mutex){+.+.}-{3:3}, at: vcpudispatch_stats_write+0xd4/0x5f4
   #2: c0000000028c70b8 (dtl_access_lock){+.+.}-{2:2}, at: vcpudispatch_stats_write+0x220/0x5f4
  CPU: 0 PID: 199 Comm: sh Not tainted 6.10.0-rc4 torvalds#152
  Hardware name: IBM pSeries (emulated by qemu) POWER9 (raw) 0x4e1202 0xf000005 of:SLOF,HEAD hv:linux,kvm pSeries
  Call Trace:
    dump_stack_lvl+0x130/0x148 (unreliable)
    __might_resched+0x174/0x410
    kmem_cache_alloc_noprof+0x340/0x3d0
    alloc_dtl_buffers+0x124/0x1ac
    vcpudispatch_stats_write+0x2a8/0x5f4
    proc_reg_write+0xf4/0x150
    vfs_write+0xfc/0x438
    ksys_write+0x88/0x148
    system_call_exception+0x1c4/0x5a0
    system_call_common+0xf4/0x258

Fixes: 06220d7 ("powerpc/pseries: Introduce rwlock to gatekeep DTLB usage")
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
mpe added a commit to linuxppc/linux that referenced this pull request Aug 30, 2024
The dtl_access_lock needs to be a rw_sempahore, a sleeping lock, because
the code calls kmalloc() while holding it, which can sleep:

  # echo 1 > /proc/powerpc/vcpudispatch_stats
  BUG: sleeping function called from invalid context at include/linux/sched/mm.h:337
  in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 199, name: sh
  preempt_count: 1, expected: 0
  3 locks held by sh/199:
   #0: c00000000a0743f8 (sb_writers#3){.+.+}-{0:0}, at: vfs_write+0x324/0x438
   #1: c0000000028c7058 (dtl_enable_mutex){+.+.}-{3:3}, at: vcpudispatch_stats_write+0xd4/0x5f4
   #2: c0000000028c70b8 (dtl_access_lock){+.+.}-{2:2}, at: vcpudispatch_stats_write+0x220/0x5f4
  CPU: 0 PID: 199 Comm: sh Not tainted 6.10.0-rc4 torvalds#152
  Hardware name: IBM pSeries (emulated by qemu) POWER9 (raw) 0x4e1202 0xf000005 of:SLOF,HEAD hv:linux,kvm pSeries
  Call Trace:
    dump_stack_lvl+0x130/0x148 (unreliable)
    __might_resched+0x174/0x410
    kmem_cache_alloc_noprof+0x340/0x3d0
    alloc_dtl_buffers+0x124/0x1ac
    vcpudispatch_stats_write+0x2a8/0x5f4
    proc_reg_write+0xf4/0x150
    vfs_write+0xfc/0x438
    ksys_write+0x88/0x148
    system_call_exception+0x1c4/0x5a0
    system_call_common+0xf4/0x258

Fixes: 06220d7 ("powerpc/pseries: Introduce rwlock to gatekeep DTLB usage")
Tested-by: Kajol Jain <kjain@linux.ibm.com>
Reviewed-by: Nysal Jan K.A <nysal@linux.ibm.com>
Reviewed-by: Kajol Jain <kjain@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/20240819122401.513203-1-mpe@ellerman.id.au
mpe added a commit to linuxppc/linux that referenced this pull request Oct 29, 2024
The dtl_access_lock needs to be a rw_sempahore, a sleeping lock, because
the code calls kmalloc() while holding it, which can sleep:

  # echo 1 > /proc/powerpc/vcpudispatch_stats
  BUG: sleeping function called from invalid context at include/linux/sched/mm.h:337
  in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 199, name: sh
  preempt_count: 1, expected: 0
  3 locks held by sh/199:
   #0: c00000000a0743f8 (sb_writers#3){.+.+}-{0:0}, at: vfs_write+0x324/0x438
   #1: c0000000028c7058 (dtl_enable_mutex){+.+.}-{3:3}, at: vcpudispatch_stats_write+0xd4/0x5f4
   #2: c0000000028c70b8 (dtl_access_lock){+.+.}-{2:2}, at: vcpudispatch_stats_write+0x220/0x5f4
  CPU: 0 PID: 199 Comm: sh Not tainted 6.10.0-rc4 torvalds#152
  Hardware name: IBM pSeries (emulated by qemu) POWER9 (raw) 0x4e1202 0xf000005 of:SLOF,HEAD hv:linux,kvm pSeries
  Call Trace:
    dump_stack_lvl+0x130/0x148 (unreliable)
    __might_resched+0x174/0x410
    kmem_cache_alloc_noprof+0x340/0x3d0
    alloc_dtl_buffers+0x124/0x1ac
    vcpudispatch_stats_write+0x2a8/0x5f4
    proc_reg_write+0xf4/0x150
    vfs_write+0xfc/0x438
    ksys_write+0x88/0x148
    system_call_exception+0x1c4/0x5a0
    system_call_common+0xf4/0x258

Fixes: 06220d7 ("powerpc/pseries: Introduce rwlock to gatekeep DTLB usage")
Tested-by: Kajol Jain <kjain@linux.ibm.com>
Reviewed-by: Nysal Jan K.A <nysal@linux.ibm.com>
Reviewed-by: Kajol Jain <kjain@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://patch.msgid.link/20240819122401.513203-1-mpe@ellerman.id.au
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.

1 participant