1. 18 3月, 2018 1 次提交
  2. 17 3月, 2018 8 次提交
  3. 16 3月, 2018 6 次提交
    • D
      net/ipv6: Add l3mdev check to ipv6_chk_addr_and_flags · 1893ff20
      David Ahern 提交于
      Lookup the L3 master device for the passed in device. Only consider
      addresses on netdev's with the same master device. If the device is
      not enslaved or is NULL, then the l3mdev is NULL which means only
      devices not enslaved (ie, in the default domain) are considered.
      Signed-off-by: NDavid Ahern <dsahern@gmail.com>
      Reviewed-by: NIdo Schimmel <idosch@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1893ff20
    • D
      net/ipv6: Change address check to always take a device argument · 232378e8
      David Ahern 提交于
      ipv6_chk_addr_and_flags determines if an address is a local address and
      optionally if it is an address on a specific device. For example, it is
      called by ip6_route_info_create to determine if a given gateway address
      is a local address. The address check currently does not consider L3
      domains and as a result does not allow a route to be added in one VRF
      if the nexthop points to an address in a second VRF. e.g.,
      
          $ ip route add 2001:db8:1::/64 vrf r2 via 2001:db8:102::23
          Error: Invalid gateway address.
      
      where 2001:db8:102::23 is an address on an interface in vrf r1.
      
      ipv6_chk_addr_and_flags needs to allow callers to always pass in a device
      with a separate argument to not limit the address to the specific device.
      The device is used used to determine the L3 domain of interest.
      
      To that end add an argument to skip the device check and update callers
      to always pass a device where possible and use the new argument to mean
      any address in the domain.
      
      Update a handful of users of ipv6_chk_addr with a NULL dev argument. This
      patch handles the change to these callers without adding the domain check.
      
      ip6_validate_gw needs to handle 2 cases - one where the device is given
      as part of the nexthop spec and the other where the device is resolved.
      There is at least 1 VRF case where deferring the check to only after
      the route lookup has resolved the device fails with an unintuitive error
      "RTNETLINK answers: No route to host" as opposed to the preferred
      "Error: Gateway can not be a local address." The 'no route to host'
      error is because of the fallback to a full lookup. The check is done
      twice to avoid this error.
      Signed-off-by: NDavid Ahern <dsahern@gmail.com>
      Reviewed-by: NIdo Schimmel <idosch@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      232378e8
    • D
      net/ipv6: Refactor gateway validation on route add · 9fbb704c
      David Ahern 提交于
      Move gateway validation code from ip6_route_info_create into
      ip6_validate_gw. Code move plus adjustments to handle the potential
      reset of dev and idev and to make checkpatch happy.
      Signed-off-by: NDavid Ahern <dsahern@gmail.com>
      Reviewed-by: NIdo Schimmel <idosch@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      9fbb704c
    • C
      rxrpc: remove redundant initialization of variable 'len' · 650b4eca
      Colin Ian King 提交于
      The variable 'len' is being initialized with a value that is never
      read and it is re-assigned later, hence the initialization is redundant
      and can be removed.
      
      Cleans up clang warning:
      net/rxrpc/recvmsg.c:275:15: warning: Value stored to 'len' during its
      initialization is never read
      Signed-off-by: NColin Ian King <colin.king@canonical.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      650b4eca
    • N
      sctp: Fix double free in sctp_sendmsg_to_asoc · 0aee4c25
      Neil Horman 提交于
      syzbot/kasan detected a double free in sctp_sendmsg_to_asoc:
      BUG: KASAN: use-after-free in sctp_association_free+0x7b7/0x930
      net/sctp/associola.c:332
      Read of size 8 at addr ffff8801d8006ae0 by task syzkaller914861/4202
      
      CPU: 1 PID: 4202 Comm: syzkaller914861 Not tainted 4.16.0-rc4+ #258
      Hardware name: Google Google Compute Engine/Google Compute Engine
      01/01/2011
      Call Trace:
       __dump_stack lib/dump_stack.c:17 [inline]
       dump_stack+0x194/0x24d lib/dump_stack.c:53
       print_address_description+0x73/0x250 mm/kasan/report.c:256
       kasan_report_error mm/kasan/report.c:354 [inline]
       kasan_report+0x23c/0x360 mm/kasan/report.c:412
       __asan_report_load8_noabort+0x14/0x20 mm/kasan/report.c:433
       sctp_association_free+0x7b7/0x930 net/sctp/associola.c:332
       sctp_sendmsg+0xc67/0x1a80 net/sctp/socket.c:2075
       inet_sendmsg+0x11f/0x5e0 net/ipv4/af_inet.c:763
       sock_sendmsg_nosec net/socket.c:629 [inline]
       sock_sendmsg+0xca/0x110 net/socket.c:639
       SYSC_sendto+0x361/0x5c0 net/socket.c:1748
       SyS_sendto+0x40/0x50 net/socket.c:1716
       do_syscall_64+0x281/0x940 arch/x86/entry/common.c:287
       entry_SYSCALL_64_after_hwframe+0x42/0xb7
      
      This was introduced by commit:
      f84af331 sctp: factor out sctp_sendmsg_to_asoc from sctp_sendmsg
      
      As the newly refactored function moved the wait_for_sndbuf call to a
      point after the association was connected, allowing for peeloff events
      to occur, which in turn caused wait_for_sndbuf to return -EPIPE which
      was not caught by the logic that determines if an association should be
      freed or not.
      
      Fix it the easy way by returning the ordering of
      sctp_primitive_ASSOCIATE and sctp_wait_for_sndbuf to the old order, to
      ensure that EPIPE will not happen.
      
      Tested by myself using the syzbot reproducers with positive results
      Signed-off-by: NNeil Horman <nhorman@tuxdriver.com>
      CC: davem@davemloft.net
      CC: Xin Long <lucien.xin@gmail.com>
      Reported-by: syzbot+a4e4112c3aff00c8cfd8@syzkaller.appspotmail.com
      Reviewed-by: NXin Long <lucien.xin@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0aee4c25
    • J
      net: drivers/net: Remove unnecessary skb_copy_expand OOM messages · 0c3d5a96
      Joe Perches 提交于
      skb_copy_expand without __GFP_NOWARN already does a dump_stack
      on OOM so these messages are redundant.
      Signed-off-by: NJoe Perches <joe@perches.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0c3d5a96
  4. 15 3月, 2018 9 次提交
    • X
      sctp: add SCTP_AUTH_NO_AUTH type for AUTHENTICATION_EVENT · 30f6ebf6
      Xin Long 提交于
      This patch is to add SCTP_AUTH_NO_AUTH type for AUTHENTICATION_EVENT,
      as described in section 6.1.8 of RFC6458.
      
            SCTP_AUTH_NO_AUTH:  This report indicates that the peer does not
               support SCTP authentication as defined in [RFC4895].
      
      Note that the implementation is quite similar as that of
      SCTP_ADAPTATION_INDICATION.
      Signed-off-by: NXin Long <lucien.xin@gmail.com>
      Acked-by: NMarcelo Ricardo Leitner <marcelo.leitner@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      30f6ebf6
    • X
      sctp: add SCTP_AUTH_FREE_KEY type for AUTHENTICATION_EVENT · ec2e506c
      Xin Long 提交于
      This patch is to add SCTP_AUTH_FREE_KEY type for AUTHENTICATION_EVENT,
      as described in section 6.1.8 of RFC6458.
      
            SCTP_AUTH_FREE_KEY:  This report indicates that the SCTP
               implementation will no longer use the key identifier specified
               in auth_keynumber.
      
      After deactivating a key, it would never be used again, which means
      it's refcnt can't be held/increased by new chunks. But there may be
      some chunks in out queue still using it. So only when refcnt is 1,
      which means no chunk in outqueue is using/holding this key either,
      this EVENT would be sent.
      
      When users receive this notification, they could do DEL_KEY sockopt to
      remove this shkey, and also tell the peer that this key won't be used
      in any chunk thoroughly from now on, then the peer can remove it as
      well safely.
      Signed-off-by: NXin Long <lucien.xin@gmail.com>
      Acked-by: NMarcelo Ricardo Leitner <marcelo.leitner@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ec2e506c
    • X
      sctp: add sockopt SCTP_AUTH_DEACTIVATE_KEY · 601590ec
      Xin Long 提交于
      This patch is to add sockopt SCTP_AUTH_DEACTIVATE_KEY, as described in
      section 8.3.4 of RFC6458.
      
      This set option indicates that the application will no longer send user
      messages using the indicated key identifier.
      
      Note that RFC requires that only deactivated keys that are no longer used
      by an association can be deleted, but for the backward compatibility, it
      is not to check deactivated when deleting or replacing one sh_key.
      Signed-off-by: NXin Long <lucien.xin@gmail.com>
      Acked-by: NMarcelo Ricardo Leitner <marcelo.leitner@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      601590ec
    • X
      sctp: add support for SCTP AUTH Information for sendmsg · 3ff547c0
      Xin Long 提交于
      This patch is to add support for SCTP AUTH Information for sendmsg,
      as described in section 5.3.8 of RFC6458.
      
      With this option, you can provide shared key identifier used for
      sending the user message.
      
      It's also a necessary send info for sctp_sendv.
      
      Note that it reuses sinfo->sinfo_tsn to indicate if this option is
      set and sinfo->sinfo_ssn to save the shkey ID which can be 0.
      Signed-off-by: NXin Long <lucien.xin@gmail.com>
      Acked-by: NMarcelo Ricardo Leitner <marcelo.leitner@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3ff547c0
    • X
      sctp: add refcnt support for sh_key · 1b1e0bc9
      Xin Long 提交于
      With refcnt support for sh_key, chunks auth sh_keys can be decided
      before enqueuing it. Changing the active key later will not affect
      the chunks already enqueued.
      
      Furthermore, this is necessary when adding the support for authinfo
      for sendmsg in next patch.
      
      Note that struct sctp_chunk can't be grown due to that performance
      drop issue on slow cpu, so it just reuses head_skb memory for shkey
      in sctp_chunk.
      Signed-off-by: NXin Long <lucien.xin@gmail.com>
      Acked-by: NMarcelo Ricardo Leitner <marcelo.leitner@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1b1e0bc9
    • K
      net/smc: schedule free_work when link group is terminated · 97cdbc42
      Karsten Graul 提交于
      The free_work worker must be scheduled when the link group is
      abnormally terminated.
      Signed-off-by: NKarsten Graul <kgraul@linux.vnet.ibm.com>
      Signed-off-by: NUrsula Braun <ubraun@linux.vnet.ibm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      97cdbc42
    • U
      net/smc: free link group without pending free_work only · 268ffcc4
      Ursula Braun 提交于
      Make sure there is no pending or running free_work worker for the link
      group when freeing the link group.
      Signed-off-by: NUrsula Braun <ubraun@linux.vnet.ibm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      268ffcc4
    • U
      net/smc: pay attention to MAX_ORDER for CQ entries · c9f4c6cf
      Ursula Braun 提交于
      smc allocates a certain number of CQ entries for used RoCE devices. For
      mlx5 devices the chosen constant number results in a large allocation
      causing this warning:
      
      [13355.124656] WARNING: CPU: 3 PID: 16535 at mm/page_alloc.c:3883 __alloc_pages_nodemask+0x2be/0x10c0
      [13355.124657] Modules linked in: smc_diag(O) smc(O) xt_CHECKSUM iptable_mangle ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_nat_ipv4 nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack ipt_REJECT nf_reject_ipv4 xt_tcpudp bridge stp llc ip6table_filter ip6_tables iptable_filter mlx5_ib ib_core sunrpc mlx5_core s390_trng rng_core ghash_s390 prng aes_s390 des_s390 des_generic sha512_s390 sha256_s390 sha1_s390 sha_common ptp pps_core eadm_sch dm_multipath dm_mod vhost_net tun vhost tap sch_fq_codel kvm ip_tables x_tables autofs4 [last unloaded: smc]
      [13355.124672] CPU: 3 PID: 16535 Comm: kworker/3:0 Tainted: G           O    4.14.0uschi #1
      [13355.124673] Hardware name: IBM 3906 M04 704 (LPAR)
      [13355.124675] Workqueue: events smc_listen_work [smc]
      [13355.124677] task: 00000000e2f22100 task.stack: 0000000084720000
      [13355.124678] Krnl PSW : 0704c00180000000 000000000029da76 (__alloc_pages_nodemask+0x2be/0x10c0)
      [13355.124681]            R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:0 PM:0 RI:0 EA:3
      [13355.124682] Krnl GPRS: 0000000000000000 00550e00014080c0 0000000000000000 0000000000000001
      [13355.124684]            000000000029d8b6 00000000f3bfd710 0000000000000000 00000000014080c0
      [13355.124685]            0000000000000009 00000000ec277a00 0000000000200000 0000000000000000
      [13355.124686]            0000000000000000 00000000000001ff 000000000029d8b6 0000000084723720
      [13355.124708] Krnl Code: 000000000029da6a: a7110200		tmll	%r1,512
                                000000000029da6e: a774ff29		brc	7,29d8c0
                               #000000000029da72: a7f40001		brc	15,29da74
                               >000000000029da76: a7f4ff25		brc	15,29d8c0
                                000000000029da7a: a7380000		lhi	%r3,0
                                000000000029da7e: a7f4fef1		brc	15,29d860
                                000000000029da82: 5820f0c4		l	%r2,196(%r15)
                                000000000029da86: a53e0048		llilh	%r3,72
      [13355.124720] Call Trace:
      [13355.124722] ([<000000000029d8b6>] __alloc_pages_nodemask+0xfe/0x10c0)
      [13355.124724]  [<000000000013bd1e>] s390_dma_alloc+0x6e/0x148
      [13355.124733]  [<000003ff802eeba6>] mlx5_dma_zalloc_coherent_node+0x8e/0xe0 [mlx5_core]
      [13355.124740]  [<000003ff802eee18>] mlx5_buf_alloc_node+0x70/0x108 [mlx5_core]
      [13355.124744]  [<000003ff804eb410>] mlx5_ib_create_cq+0x558/0x898 [mlx5_ib]
      [13355.124749]  [<000003ff80407d40>] ib_create_cq+0x48/0x88 [ib_core]
      [13355.124751]  [<000003ff80109fba>] smc_ib_setup_per_ibdev+0x52/0x118 [smc]
      [13355.124753]  [<000003ff8010bcb6>] smc_conn_create+0x65e/0x728 [smc]
      [13355.124755]  [<000003ff801081a2>] smc_listen_work+0x2d2/0x540 [smc]
      [13355.124756]  [<0000000000162c66>] process_one_work+0x1be/0x440
      [13355.124758]  [<0000000000162f40>] worker_thread+0x58/0x458
      [13355.124759]  [<0000000000169e7e>] kthread+0x14e/0x168
      [13355.124760]  [<00000000009ce8be>] kernel_thread_starter+0x6/0xc
      [13355.124762]  [<00000000009ce8b8>] kernel_thread_starter+0x0/0xc
      [13355.124762] Last Breaking-Event-Address:
      [13355.124764]  [<000000000029da72>] __alloc_pages_nodemask+0x2ba/0x10c0
      [13355.124764] ---[ end trace 34be38b581c0b585 ]---
      
      This patch reduces the smc constant for the maximum number of allocated
      completion queue entries SMC_MAX_CQE by 2 to avoid high round up values
      in the mlx5 code, and reduces the number of allocated completion queue
      entries even more, if the final allocation for an mlx5 device hits the
      MAX_ORDER limit.
      Reported-by: NIhnken Menssen <menssen@de.ibm.com>
      Signed-off-by: NUrsula Braun <ubraun@linux.vnet.ibm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c9f4c6cf
    • W
      sock: remove zerocopy sockopt restriction on closed tcp state · ced68234
      Willem de Bruijn 提交于
      Socket option SO_ZEROCOPY determines whether the kernel ignores or
      processes flag MSG_ZEROCOPY on subsequent send calls. This to avoid
      changing behavior for legacy processes.
      
      Limiting the state change to closed sockets is annoying with passive
      sockets and not necessary for correctness. Once created, zerocopy skbs
      are processed based on their private state, not this socket flag.
      
      Remove the constraint.
      Signed-off-by: NWillem de Bruijn <willemb@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ced68234
  5. 14 3月, 2018 2 次提交
  6. 13 3月, 2018 7 次提交
  7. 12 3月, 2018 4 次提交
  8. 10 3月, 2018 3 次提交