Skip to content
Snippets Groups Projects
  1. Sep 05, 2019
  2. Sep 03, 2019
  3. Sep 02, 2019
  4. Sep 01, 2019
  5. Aug 31, 2019
  6. Aug 29, 2019
    • Gustavo A. R. Silva's avatar
      nds32: Mark expected switch fall-throughs · 7c9eb2db
      Gustavo A. R. Silva authored
      
      Mark switch cases where we are expecting to fall through.
      
      This patch fixes the following warnings (Building: allmodconfig nds32):
      
      include/math-emu/soft-fp.h:124:8: warning: this statement may fall through [-Wimplicit-fallthrough=]
      arch/nds32/kernel/signal.c:362:20: warning: this statement may fall through [-Wimplicit-fallthrough=]
      arch/nds32/kernel/signal.c:315:7: warning: this statement may fall through [-Wimplicit-fallthrough=]
      include/math-emu/op-common.h:417:11: warning: this statement may fall through [-Wimplicit-fallthrough=]
      include/math-emu/op-common.h:430:11: warning: this statement may fall through [-Wimplicit-fallthrough=]
      include/math-emu/op-common.h:310:11: warning: this statement may fall through [-Wimplicit-fallthrough=]
      include/math-emu/op-common.h:320:11: warning: this statement may fall through [-Wimplicit-fallthrough=]
      include/math-emu/op-common.h:310:11: warning: this statement may fall through [-Wimplicit-fallthrough=]
      include/math-emu/op-common.h:320:11: warning: this statement may fall through [-Wimplicit-fallthrough=]
      include/math-emu/soft-fp.h:124:8: warning: this statement may fall through [-Wimplicit-fallthrough=]
      include/math-emu/op-common.h:417:11: warning: this statement may fall through [-Wimplicit-fallthrough=]
      include/math-emu/op-common.h:430:11: warning: this statement may fall through [-Wimplicit-fallthrough=]
      include/math-emu/op-common.h:310:11: warning: this statement may fall through [-Wimplicit-fallthrough=]
      include/math-emu/op-common.h:320:11: warning: this statement may fall through [-Wimplicit-fallthrough=]
      include/math-emu/op-common.h:310:11: warning: this statement may fall through [-Wimplicit-fallthrough=]
      include/math-emu/op-common.h:320:11: warning: this statement may fall through [-Wimplicit-fallthrough=]
      
      Reported-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: default avatarGustavo A. R. Silva <gustavo@embeddedor.com>
      7c9eb2db
  7. Aug 28, 2019
  8. Aug 27, 2019
    • Cong Wang's avatar
      net_sched: fix a NULL pointer deref in ipt action · 981471bd
      Cong Wang authored
      
      The net pointer in struct xt_tgdtor_param is not explicitly
      initialized therefore is still NULL when dereferencing it.
      So we have to find a way to pass the correct net pointer to
      ipt_destroy_target().
      
      The best way I find is just saving the net pointer inside the per
      netns struct tcf_idrinfo, which could make this patch smaller.
      
      Fixes: 0c66dc1e ("netfilter: conntrack: register hooks in netns when needed by ruleset")
      Reported-and-tested-by: default avatar <itugrok@yahoo.com>
      Cc: Jamal Hadi Salim <jhs@mojatatu.com>
      Cc: Jiri Pirko <jiri@resnulli.us>
      Signed-off-by: default avatarCong Wang <xiyou.wangcong@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      981471bd
    • David Howells's avatar
      rxrpc: Use skb_unshare() rather than skb_cow_data() · d0d5c0cd
      David Howells authored
      
      The in-place decryption routines in AF_RXRPC's rxkad security module
      currently call skb_cow_data() to make sure the data isn't shared and that
      the skb can be written over.  This has a problem, however, as the softirq
      handler may be still holding a ref or the Rx ring may be holding multiple
      refs when skb_cow_data() is called in rxkad_verify_packet() - and so
      skb_shared() returns true and __pskb_pull_tail() dislikes that.  If this
      occurs, something like the following report will be generated.
      
      	kernel BUG at net/core/skbuff.c:1463!
      	...
      	RIP: 0010:pskb_expand_head+0x253/0x2b0
      	...
      	Call Trace:
      	 __pskb_pull_tail+0x49/0x460
      	 skb_cow_data+0x6f/0x300
      	 rxkad_verify_packet+0x18b/0xb10 [rxrpc]
      	 rxrpc_recvmsg_data.isra.11+0x4a8/0xa10 [rxrpc]
      	 rxrpc_kernel_recv_data+0x126/0x240 [rxrpc]
      	 afs_extract_data+0x51/0x2d0 [kafs]
      	 afs_deliver_fs_fetch_data+0x188/0x400 [kafs]
      	 afs_deliver_to_call+0xac/0x430 [kafs]
      	 afs_wait_for_call_to_complete+0x22f/0x3d0 [kafs]
      	 afs_make_call+0x282/0x3f0 [kafs]
      	 afs_fs_fetch_data+0x164/0x300 [kafs]
      	 afs_fetch_data+0x54/0x130 [kafs]
      	 afs_readpages+0x20d/0x340 [kafs]
      	 read_pages+0x66/0x180
      	 __do_page_cache_readahead+0x188/0x1a0
      	 ondemand_readahead+0x17d/0x2e0
      	 generic_file_read_iter+0x740/0xc10
      	 __vfs_read+0x145/0x1a0
      	 vfs_read+0x8c/0x140
      	 ksys_read+0x4a/0xb0
      	 do_syscall_64+0x43/0xf0
      	 entry_SYSCALL_64_after_hwframe+0x44/0xa9
      
      Fix this by using skb_unshare() instead in the input path for DATA packets
      that have a security index != 0.  Non-DATA packets don't need in-place
      encryption and neither do unencrypted DATA packets.
      
      Fixes: 248f219c ("rxrpc: Rewrite the data and ack handling code")
      Reported-by: default avatarJulian Wollrath <jwollrath@web.de>
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      d0d5c0cd
    • David Howells's avatar
      rxrpc: Use the tx-phase skb flag to simplify tracing · 987db9f7
      David Howells authored
      
      Use the previously-added transmit-phase skbuff private flag to simplify the
      socket buffer tracing a bit.  Which phase the skbuff comes from can now be
      divined from the skb rather than having to be guessed from the call state.
      
      We can also reduce the number of rxrpc_skb_trace values by eliminating the
      difference between Tx and Rx in the symbols.
      
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      987db9f7
  9. Aug 26, 2019
  10. Aug 25, 2019
    • David Ahern's avatar
      nexthop: Fix nexthop_num_path for blackhole nexthops · 9b5f6841
      David Ahern authored
      
      Donald reported this sequence:
        ip next add id 1 blackhole
        ip next add id 2 blackhole
        ip ro add 1.1.1.1/32 nhid 1
        ip ro add 1.1.1.2/32 nhid 2
      
      would cause a crash. Backtrace is:
      
      [  151.302790] general protection fault: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN PTI
      [  151.304043] CPU: 1 PID: 277 Comm: ip Not tainted 5.3.0-rc5+ #37
      [  151.305078] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.1-1 04/01/2014
      [  151.306526] RIP: 0010:fib_add_nexthop+0x8b/0x2aa
      [  151.307343] Code: 35 f7 81 48 8d 14 01 c7 02 f1 f1 f1 f1 c7 42 04 01 f4 f4 f4 48 89 f2 48 c1 ea 03 65 48 8b 0c 25 28 00 00 00 48 89 4d d0 31 c9 <80> 3c 02 00 74 08 48 89 f7 e8 1a e8 53 ff be 08 00 00 00 4c 89 e7
      [  151.310549] RSP: 0018:ffff888116c27340 EFLAGS: 00010246
      [  151.311469] RAX: dffffc0000000000 RBX: ffff8881154ece00 RCX: 0000000000000000
      [  151.312713] RDX: 0000000000000004 RSI: 0000000000000020 RDI: ffff888115649b40
      [  151.313968] RBP: ffff888116c273d8 R08: ffffed10221e3757 R09: ffff888110f1bab8
      [  151.315212] R10: 0000000000000001 R11: ffff888110f1bab3 R12: ffff888115649b40
      [  151.316456] R13: 0000000000000020 R14: ffff888116c273b0 R15: ffff888115649b40
      [  151.317707] FS:  00007f60b4d8d800(0000) GS:ffff88811ac00000(0000) knlGS:0000000000000000
      [  151.319113] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [  151.320119] CR2: 0000555671ffdc00 CR3: 00000001136ba005 CR4: 0000000000020ee0
      [  151.321367] Call Trace:
      [  151.321820]  ? fib_nexthop_info+0x635/0x635
      [  151.322572]  fib_dump_info+0xaa4/0xde0
      [  151.323247]  ? fib_create_info+0x2431/0x2431
      [  151.324008]  ? napi_alloc_frag+0x2a/0x2a
      [  151.324711]  rtmsg_fib+0x2c4/0x3be
      [  151.325339]  fib_table_insert+0xe2f/0xeee
      ...
      
      fib_dump_info incorrectly has nhs = 0 for blackhole nexthops, so it
      believes the nexthop object is a multipath group (nhs != 1) and ends
      up down the nexthop_mpath_fill_node() path which is wrong for a
      blackhole.
      
      The blackhole check in nexthop_num_path is leftover from early days
      of the blackhole implementation which did not initialize the device.
      In the end the design was simpler (fewer special case checks) to set
      the device to loopback in nh_info, so the check in nexthop_num_path
      should have been removed.
      
      Fixes: 430a0491 ("nexthop: Add support for nexthop groups")
      Reported-by: default avatarDonald Sharp <sharpd@cumulusnetworks.com>
      Signed-off-by: default avatarDavid Ahern <dsahern@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      9b5f6841
  11. Aug 24, 2019
    • Zhu Yanjun's avatar
      net: rds: add service level support in rds-info · e0e6d062
      Zhu Yanjun authored
      
      >From IB specific 7.6.5 SERVICE LEVEL, Service Level (SL)
      is used to identify different flows within an IBA subnet.
      It is carried in the local route header of the packet.
      
      Before this commit, run "rds-info -I". The outputs are as
      below:
      "
      RDS IB Connections:
       LocalAddr  RemoteAddr Tos SL  LocalDev               RemoteDev
      192.2.95.3  192.2.95.1  2   0  fe80::21:28:1a:39  fe80::21:28:10:b9
      192.2.95.3  192.2.95.1  1   0  fe80::21:28:1a:39  fe80::21:28:10:b9
      192.2.95.3  192.2.95.1  0   0  fe80::21:28:1a:39  fe80::21:28:10:b9
      "
      After this commit, the output is as below:
      "
      RDS IB Connections:
       LocalAddr  RemoteAddr Tos SL  LocalDev               RemoteDev
      192.2.95.3  192.2.95.1  2   2  fe80::21:28:1a:39  fe80::21:28:10:b9
      192.2.95.3  192.2.95.1  1   1  fe80::21:28:1a:39  fe80::21:28:10:b9
      192.2.95.3  192.2.95.1  0   0  fe80::21:28:1a:39  fe80::21:28:10:b9
      "
      
      The commit fe3475af ("net: rds: add per rds connection cache
      statistics") adds cache_allocs in struct rds_info_rdma_connection
      as below:
      struct rds_info_rdma_connection {
      ...
              __u32           rdma_mr_max;
              __u32           rdma_mr_size;
              __u8            tos;
              __u32           cache_allocs;
       };
      The peer struct in rds-tools of struct rds_info_rdma_connection is as
      below:
      struct rds_info_rdma_connection {
      ...
              uint32_t        rdma_mr_max;
              uint32_t        rdma_mr_size;
              uint8_t         tos;
              uint8_t         sl;
              uint32_t        cache_allocs;
      };
      The difference between userspace and kernel is the member variable sl.
      In the kernel struct, the member variable sl is missing. This will
      introduce risks. So it is necessary to use this commit to avoid this risk.
      
      Fixes: fe3475af ("net: rds: add per rds connection cache statistics")
      CC: Joe Jin <joe.jin@oracle.com>
      CC: JUNXIAO_BI <junxiao.bi@oracle.com>
      Suggested-by: default avatarGerd Rausch <gerd.rausch@oracle.com>
      Signed-off-by: default avatarZhu Yanjun <yanjun.zhu@oracle.com>
      Acked-by: default avatarSantosh Shilimkar <santosh.shilimkar@oracle.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e0e6d062
    • John Fastabend's avatar
      net: route dump netlink NLM_F_MULTI flag missing · e93fb3e9
      John Fastabend authored
      An excerpt from netlink(7) man page,
      
        In multipart messages (multiple nlmsghdr headers with associated payload
        in one byte stream) the first and all following headers have the
        NLM_F_MULTI flag set, except for the last  header  which  has the type
        NLMSG_DONE.
      
      but, after (ee28906f) there is a missing NLM_F_MULTI flag in the middle of a
      FIB dump. The result is user space applications following above man page
      excerpt may get confused and may stop parsing msg believing something went
      wrong.
      
      In the golang netlink lib [0] the library logic stops parsing believing the
      message is not a multipart message. Found this running Cilium[1] against
      net-next while adding a feature to auto-detect routes. I noticed with
      multiple route tables we no longer could detect the default routes on net
      tree kernels because the library logic was not returning them.
      
      Fix this by handling the fib_dump_info_fnhe() case the same way the
      fib_dump_info() handles it by passing the flags argument through the
      call chain and adding a flags argument to rt_fill_info().
      
      Tested with Cilium stack and auto-detection of routes works again. Also
      annotated libs to dump netlink msgs and inspected NLM_F_MULTI and
      NLMSG_DONE flags look correct after this.
      
      Note: In inet_rtm_getroute() pass rt_fill_info() '0' for flags the same
      as is done for fib_dump_info() so this looks correct to me.
      
      [0] https://github.com/vishvananda/netlink/
      [1] https://github.com/cilium/
      
      
      
      Fixes: ee28906f ("ipv4: Dump route exceptions if requested")
      Signed-off-by: default avatarJohn Fastabend <john.fastabend@gmail.com>
      Reviewed-by: default avatarStefano Brivio <sbrivio@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e93fb3e9
    • xiaolinkui's avatar
      net: use unlikely for dql_avail case · f3acd33d
      xiaolinkui authored
      
      This is an unlikely case, use unlikely() on it seems logical.
      
      Signed-off-by: default avatarxiaolinkui <xiaolinkui@kylinos.cn>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f3acd33d
Loading