1. 30 Nov, 2017 1 commit
  2. 29 Nov, 2017 1 commit
  3. 28 Nov, 2017 9 commits
    • Jiri Pirko's avatar
      net: sched: cbq: create block for q->link.block · d51aae68
      Jiri Pirko authored
      q->link.block is not initialized, that leads to EINVAL when one tries to
      add filter there. So initialize it properly.
      
      This can be reproduced by:
      $ tc qdisc add dev eth0 root handle 1: cbq avpkt 1000 rate 1000Mbit bandwidth 1000Mbit
      $ tc filter add dev eth0 parent 1: protocol ip prio 100 u32 match ip protocol 0 0x00 flowid 1:1
      Reported-by: 's avatarJaroslav Aster <jaster@redhat.com>
      Reported-by: 's avatarIvan Vecera <ivecera@redhat.com>
      Fixes: 6529eaba ("net: sched: introduce tcf block infractructure")
      Signed-off-by: 's avatarJiri Pirko <jiri@mellanox.com>
      Acked-by: 's avatarEelco Chaudron <echaudro@redhat.com>
      Reviewed-by: 's avatarIvan Vecera <ivecera@redhat.com>
      Signed-off-by: 's avatarDavid S. Miller <davem@davemloft.net>
      d51aae68
    • Jorgen Hansen's avatar
      VSOCK: Don't set sk_state to TCP_CLOSE before testing it · 4a5def7f
      Jorgen Hansen authored
      A recent commit (3b4477d2) converted the sk_state to use
      TCP constants. In that change, vmci_transport_handle_detach
      was changed such that sk->sk_state was set to TCP_CLOSE before
      we test whether it is TCP_SYN_SENT. This change moves the
      sk_state change back to the original locations in that function.
      Signed-off-by: 's avatarJorgen Hansen <jhansen@vmware.com>
      Reviewed-by: 's avatarStefan Hajnoczi <stefanha@redhat.com>
      Signed-off-by: 's avatarDavid S. Miller <davem@davemloft.net>
      4a5def7f
    • Xin Long's avatar
      sctp: use right member as the param of list_for_each_entry · a8dd3979
      Xin Long authored
      Commit d04adf1b ("sctp: reset owner sk for data chunks on out queues
      when migrating a sock") made a mistake that using 'list' as the param of
      list_for_each_entry to traverse the retransmit, sacked and abandoned
      queues, while chunks are using 'transmitted_list' to link into these
      queues.
      
      It could cause NULL dereference panic if there are chunks in any of these
      queues when peeling off one asoc.
      
      So use the chunk member 'transmitted_list' instead in this patch.
      
      Fixes: d04adf1b ("sctp: reset owner sk for data chunks on out queues when migrating a sock")
      Signed-off-by: 's avatarXin Long <lucien.xin@gmail.com>
      Acked-by: 's avatarMarcelo Ricardo Leitner <marcelo.leitner@gmail.com>
      Acked-by: 's avatarNeil Horman <nhorman@tuxdriver.com>
      Signed-off-by: 's avatarDavid S. Miller <davem@davemloft.net>
      a8dd3979
    • Paolo Abeni's avatar
      sch_sfq: fix null pointer dereference at timer expiration · f85729d0
      Paolo Abeni authored
      While converting sch_sfq to use timer_setup(), the commit cdeabbb8
      ("net: sched: Convert timers to use timer_setup()") forgot to
      initialize the 'sch' field. As a result, the timer callback tries to
      dereference a NULL pointer, and the kernel does oops.
      
      Fix it initializing such field at qdisc creation time.
      
      Fixes: cdeabbb8 ("net: sched: Convert timers to use timer_setup()")
      Signed-off-by: 's avatarPaolo Abeni <pabeni@redhat.com>
      Acked-by: 's avatarCong Wang <xiyou.wangcong@gmail.com>
      Acked-by: 's avatarKees Cook <keescook@chromium.org>
      Signed-off-by: 's avatarDavid S. Miller <davem@davemloft.net>
      f85729d0
    • Jakub Kicinski's avatar
      cls_bpf: don't decrement net's refcount when offload fails · 25415cec
      Jakub Kicinski authored
      When cls_bpf offload was added it seemed like a good idea to
      call cls_bpf_delete_prog() instead of extending the error
      handling path, since the software state is fully initialized
      at that point.  This handling of errors without jumping to
      the end of the function is error prone, as proven by later
      commit missing that extra call to __cls_bpf_delete_prog().
      
      __cls_bpf_delete_prog() is now expected to be invoked with
      a reference on exts->net or the field zeroed out.  The call
      on the offload's error patch does not fullfil this requirement,
      leading to each error stealing a reference on net namespace.
      
      Create a function undoing what cls_bpf_set_parms() did and
      use it from __cls_bpf_delete_prog() and the error path.
      
      Fixes: aae2c35e ("cls_bpf: use tcf_exts_get_net() before call_rcu()")
      Signed-off-by: 's avatarJakub Kicinski <jakub.kicinski@netronome.com>
      Reviewed-by: 's avatarSimon Horman <simon.horman@netronome.com>
      Acked-by: 's avatarDaniel Borkmann <daniel@iogearbox.net>
      Acked-by: 's avatarCong Wang <xiyou.wangcong@gmail.com>
      Signed-off-by: 's avatarDavid S. Miller <davem@davemloft.net>
      25415cec
    • Eric Dumazet's avatar
      net/packet: fix a race in packet_bind() and packet_notifier() · 15fe076e
      Eric Dumazet authored
      syzbot reported crashes [1] and provided a C repro easing bug hunting.
      
      When/if packet_do_bind() calls __unregister_prot_hook() and releases
      po->bind_lock, another thread can run packet_notifier() and process an
      NETDEV_UP event.
      
      This calls register_prot_hook() and hooks again the socket right before
      first thread is able to grab again po->bind_lock.
      
      Fixes this issue by temporarily setting po->num to 0, as suggested by
      David Miller.
      
      [1]
      dev_remove_pack: ffff8801bf16fa80 not found
      ------------[ cut here ]------------
      kernel BUG at net/core/dev.c:7945!  ( BUG_ON(!list_empty(&dev->ptype_all)); )
      invalid opcode: 0000 [#1] SMP KASAN
      Dumping ftrace buffer:
         (ftrace buffer empty)
      Modules linked in:
      device syz0 entered promiscuous mode
      CPU: 0 PID: 3161 Comm: syzkaller404108 Not tainted 4.14.0+ #190
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
      task: ffff8801cc57a500 task.stack: ffff8801cc588000
      RIP: 0010:netdev_run_todo+0x772/0xae0 net/core/dev.c:7945
      RSP: 0018:ffff8801cc58f598 EFLAGS: 00010293
      RAX: ffff8801cc57a500 RBX: dffffc0000000000 RCX: ffffffff841f75b2
      RDX: 0000000000000000 RSI: 1ffff100398b1ede RDI: ffff8801bf1f8810
      device syz0 entered promiscuous mode
      RBP: ffff8801cc58f898 R08: 0000000000000001 R09: 0000000000000000
      R10: 0000000000000000 R11: 0000000000000000 R12: ffff8801bf1f8cd8
      R13: ffff8801cc58f870 R14: ffff8801bf1f8780 R15: ffff8801cc58f7f0
      FS:  0000000001716880(0000) GS:ffff8801db400000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 0000000020b13000 CR3: 0000000005e25000 CR4: 00000000001406f0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      Call Trace:
       rtnl_unlock+0xe/0x10 net/core/rtnetlink.c:106
       tun_detach drivers/net/tun.c:670 [inline]
       tun_chr_close+0x49/0x60 drivers/net/tun.c:2845
       __fput+0x333/0x7f0 fs/file_table.c:210
       ____fput+0x15/0x20 fs/file_table.c:244
       task_work_run+0x199/0x270 kernel/task_work.c:113
       exit_task_work include/linux/task_work.h:22 [inline]
       do_exit+0x9bb/0x1ae0 kernel/exit.c:865
       do_group_exit+0x149/0x400 kernel/exit.c:968
       SYSC_exit_group kernel/exit.c:979 [inline]
       SyS_exit_group+0x1d/0x20 kernel/exit.c:977
       entry_SYSCALL_64_fastpath+0x1f/0x96
      RIP: 0033:0x44ad19
      
      Fixes: 30f7ea1c ("packet: race condition in packet_bind")
      Signed-off-by: 's avatarEric Dumazet <edumazet@google.com>
      Reported-by: 's avatarsyzbot <syzkaller@googlegroups.com>
      Cc: Francesco Ruggeri <fruggeri@aristanetworks.com>
      Signed-off-by: 's avatarDavid S. Miller <davem@davemloft.net>
      15fe076e
    • Mike Maloney's avatar
      packet: fix crash in fanout_demux_rollover() · 57f015f5
      Mike Maloney authored
      syzkaller found a race condition fanout_demux_rollover() while removing
      a packet socket from a fanout group.
      
      po->rollover is read and operated on during packet_rcv_fanout(), via
      fanout_demux_rollover(), but the pointer is currently cleared before the
      synchronization in packet_release().   It is safer to delay the cleanup
      until after synchronize_net() has been called, ensuring all calls to
      packet_rcv_fanout() for this socket have finished.
      
      To further simplify synchronization around the rollover structure, set
      po->rollover in fanout_add() only if there are no errors.  This removes
      the need for rcu in the struct and in the call to
      packet_getsockopt(..., PACKET_ROLLOVER_STATS, ...).
      
      Crashing stack trace:
       fanout_demux_rollover+0xb6/0x4d0 net/packet/af_packet.c:1392
       packet_rcv_fanout+0x649/0x7c8 net/packet/af_packet.c:1487
       dev_queue_xmit_nit+0x835/0xc10 net/core/dev.c:1953
       xmit_one net/core/dev.c:2975 [inline]
       dev_hard_start_xmit+0x16b/0xac0 net/core/dev.c:2995
       __dev_queue_xmit+0x17a4/0x2050 net/core/dev.c:3476
       dev_queue_xmit+0x17/0x20 net/core/dev.c:3509
       neigh_connected_output+0x489/0x720 net/core/neighbour.c:1379
       neigh_output include/net/neighbour.h:482 [inline]
       ip6_finish_output2+0xad1/0x22a0 net/ipv6/ip6_output.c:120
       ip6_finish_output+0x2f9/0x920 net/ipv6/ip6_output.c:146
       NF_HOOK_COND include/linux/netfilter.h:239 [inline]
       ip6_output+0x1f4/0x850 net/ipv6/ip6_output.c:163
       dst_output include/net/dst.h:459 [inline]
       NF_HOOK.constprop.35+0xff/0x630 include/linux/netfilter.h:250
       mld_sendpack+0x6a8/0xcc0 net/ipv6/mcast.c:1660
       mld_send_initial_cr.part.24+0x103/0x150 net/ipv6/mcast.c:2072
       mld_send_initial_cr net/ipv6/mcast.c:2056 [inline]
       ipv6_mc_dad_complete+0x99/0x130 net/ipv6/mcast.c:2079
       addrconf_dad_completed+0x595/0x970 net/ipv6/addrconf.c:4039
       addrconf_dad_work+0xac9/0x1160 net/ipv6/addrconf.c:3971
       process_one_work+0xbf0/0x1bc0 kernel/workqueue.c:2113
       worker_thread+0x223/0x1990 kernel/workqueue.c:2247
       kthread+0x35e/0x430 kernel/kthread.c:231
       ret_from_fork+0x2a/0x40 arch/x86/entry/entry_64.S:432
      
      Fixes: 0648ab70 ("packet: rollover prepare: per-socket state")
      Fixes: 509c7a1e ("packet: avoid panic in packet_getsockopt()")
      Reported-by: 's avatarsyzbot <syzkaller@googlegroups.com>
      Signed-off-by: 's avatarMike Maloney <maloney@google.com>
      Reviewed-by: 's avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: 's avatarDavid S. Miller <davem@davemloft.net>
      57f015f5
    • Xin Long's avatar
      sctp: remove extern from stream sched · 1ba896f6
      Xin Long authored
      Now each stream sched ops is defined in different .c file and
      added into the global ops in another .c file, it uses extern
      to make this work.
      
      However extern is not good coding style to get them in and
      even make C=2 reports errors for this.
      
      This patch adds sctp_sched_ops_xxx_init for each stream sched
      ops in their .c file, then get them into the global ops by
      calling them when initializing sctp module.
      
      Fixes: 637784ad ("sctp: introduce priority based stream scheduler")
      Fixes: ac1ed8b8 ("sctp: introduce round robin stream scheduler")
      Signed-off-by: 's avatarXin Long <lucien.xin@gmail.com>
      Acked-by: 's avatarMarcelo Ricardo Leitner <marcelo.leitner@gmail.com>
      Signed-off-by: 's avatarDavid S. Miller <davem@davemloft.net>
      1ba896f6
    • Xin Long's avatar
      sctp: force SCTP_ERROR_INV_STRM with __u32 when calling sctp_chunk_fail · 08f46070
      Xin Long authored
      This patch is to force SCTP_ERROR_INV_STRM with right type to
      fit in sctp_chunk_fail to avoid the sparse error.
      Signed-off-by: 's avatarXin Long <lucien.xin@gmail.com>
      Acked-by: 's avatarMarcelo Ricardo Leitner <marcelo.leitner@gmail.com>
      Signed-off-by: 's avatarDavid S. Miller <davem@davemloft.net>
      08f46070
  4. 27 Nov, 2017 11 commits
  5. 26 Nov, 2017 2 commits
    • zhangliping's avatar
      openvswitch: fix the incorrect flow action alloc size · 67c8d22a
      zhangliping authored
      If we want to add a datapath flow, which has more than 500 vxlan outputs'
      action, we will get the following error reports:
        openvswitch: netlink: Flow action size 32832 bytes exceeds max
        openvswitch: netlink: Flow action size 32832 bytes exceeds max
        openvswitch: netlink: Actions may not be safe on all matching packets
        ... ...
      
      It seems that we can simply enlarge the MAX_ACTIONS_BUFSIZE to fix it, but
      this is not the root cause. For example, for a vxlan output action, we need
      about 60 bytes for the nlattr, but after it is converted to the flow
      action, it only occupies 24 bytes. This means that we can still support
      more than 1000 vxlan output actions for a single datapath flow under the
      the current 32k max limitation.
      
      So even if the nla_len(attr) is larger than MAX_ACTIONS_BUFSIZE, we
      shouldn't report EINVAL and keep it move on, as the judgement can be
      done by the reserve_sfa_size.
      Signed-off-by: 's avatarzhangliping <zhangliping02@baidu.com>
      Acked-by: 's avatarPravin B Shelar <pshelar@ovn.org>
      Signed-off-by: 's avatarDavid S. Miller <davem@davemloft.net>
      67c8d22a
    • Gustavo A. R. Silva's avatar
      net: openvswitch: datapath: fix data type in queue_gso_packets · 2734166e
      Gustavo A. R. Silva authored
      gso_type is being used in binary AND operations together with SKB_GSO_UDP.
      The issue is that variable gso_type is of type unsigned short and
      SKB_GSO_UDP expands to more than 16 bits:
      
      SKB_GSO_UDP = 1 << 16
      
      this makes any binary AND operation between gso_type and SKB_GSO_UDP to
      be always zero, hence making some code unreachable and likely causing
      undesired behavior.
      
      Fix this by changing the data type of variable gso_type to unsigned int.
      
      Addresses-Coverity-ID: 1462223
      Fixes: 0c19f846 ("net: accept UFO datagrams from tuntap and packet")
      Signed-off-by: 's avatarGustavo A. R. Silva <garsilva@embeddedor.com>
      Acked-by: 's avatarWillem de Bruijn <willemb@google.com>
      Signed-off-by: 's avatarDavid S. Miller <davem@davemloft.net>
      2734166e
  6. 25 Nov, 2017 3 commits
  7. 24 Nov, 2017 13 commits
    • Johannes Berg's avatar
      cfg80211: select CRYPTO_SHA256 if needed · 01a95b21
      Johannes Berg authored
      When regulatory database certificates are built-in, they're
      currently using the SHA256 digest algorithm, so add that to
      the build in that case.
      
      Also add a note that for custom certificates, one may need
      to add the right algorithms.
      Reported-by: 's avatarFlorian Fainelli <f.fainelli@gmail.com>
      Tested-by: 's avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: 's avatarJohannes Berg <johannes.berg@intel.com>
      01a95b21
    • David Howells's avatar
      rxrpc: Fix conn expiry timers · 3d18cbb7
      David Howells authored
      Fix the rxrpc connection expiry timers so that connections for closed
      AF_RXRPC sockets get deleted in a more timely fashion, freeing up the
      transport UDP port much more quickly.
      
       (1) Replace the delayed work items with work items plus timers so that
           timer_reduce() can be used to shorten them and so that the timer
           doesn't requeue the work item if the net namespace is dead.
      
       (2) Don't use queue_delayed_work() as that won't alter the timeout if the
           timer is already running.
      
       (3) Don't rearm the timers if the network namespace is dead.
      Signed-off-by: 's avatarDavid Howells <dhowells@redhat.com>
      3d18cbb7
    • David Howells's avatar
      rxrpc: Fix service endpoint expiry · f859ab61
      David Howells authored
      RxRPC service endpoints expire like they're supposed to by the following
      means:
      
       (1) Mark dead rxrpc_net structs (with ->live) rather than twiddling the
           global service conn timeout, otherwise the first rxrpc_net struct to
           die will cause connections on all others to expire immediately from
           then on.
      
       (2) Mark local service endpoints for which the socket has been closed
           (->service_closed) so that the expiration timeout can be much
           shortened for service and client connections going through that
           endpoint.
      
       (3) rxrpc_put_service_conn() needs to schedule the reaper when the usage
           count reaches 1, not 0, as idle conns have a 1 count.
      
       (4) The accumulator for the earliest time we might want to schedule for
           should be initialised to jiffies + MAX_JIFFY_OFFSET, not ULONG_MAX as
           the comparison functions use signed arithmetic.
      
       (5) Simplify the expiration handling, adding the expiration value to the
           idle timestamp each time rather than keeping track of the time in the
           past before which the idle timestamp must go to be expired.  This is
           much easier to read.
      
       (6) Ignore the timeouts if the net namespace is dead.
      
       (7) Restart the service reaper work item rather the client reaper.
      Signed-off-by: 's avatarDavid Howells <dhowells@redhat.com>
      f859ab61
    • David Howells's avatar
      rxrpc: Add keepalive for a call · 415f44e4
      David Howells authored
      We need to transmit a packet every so often to act as a keepalive for the
      peer (which has a timeout from the last time it received a packet) and also
      to prevent any intervening firewalls from closing the route.
      
      Do this by resetting a timer every time we transmit a packet.  If the timer
      ever expires, we transmit a PING ACK packet and thereby also elicit a PING
      RESPONSE ACK from the other side - which prevents our last-rx timeout from
      expiring.
      
      The timer is set to 1/6 of the last-rx timeout so that we can detect the
      other side going away if it misses 6 replies in a row.
      
      This is particularly necessary for servers where the processing of the
      service function may take a significant amount of time.
      Signed-off-by: 's avatarDavid Howells <dhowells@redhat.com>
      415f44e4
    • David Howells's avatar
      rxrpc: Add a timeout for detecting lost ACKs/lost DATA · bd1fdf8c
      David Howells authored
      Add an extra timeout that is set/updated when we send a DATA packet that
      has the request-ack flag set.  This allows us to detect if we don't get an
      ACK in response to the latest flagged packet.
      
      The ACK packet is adjudged to have been lost if it doesn't turn up within
      2*RTT of the transmission.
      
      If the timeout occurs, we schedule the sending of a PING ACK to find out
      the state of the other side.  If a new DATA packet is ready to go sooner,
      we cancel the sending of the ping and set the request-ack flag on that
      instead.
      
      If we get back a PING-RESPONSE ACK that indicates a lower tx_top than what
      we had at the time of the ping transmission, we adjudge all the DATA
      packets sent between the response tx_top and the ping-time tx_top to have
      been lost and retransmit immediately.
      
      Rather than sending a PING ACK, we could just pick a DATA packet and
      speculatively retransmit that with request-ack set.  It should result in
      either a REQUESTED ACK or a DUPLICATE ACK which we can then use in lieu the
      a PING-RESPONSE ACK mentioned above.
      Signed-off-by: 's avatarDavid Howells <dhowells@redhat.com>
      bd1fdf8c
    • David Howells's avatar
      rxrpc: Express protocol timeouts in terms of RTT · beb8e5e4
      David Howells authored
      Express protocol timeouts for data retransmission and deferred ack
      generation in terms on RTT rather than specified timeouts once we have
      sufficient RTT samples.
      
      For the moment, this requires just one RTT sample to be able to use this
      for ack deferral and two for data retransmission.
      
      The data retransmission timeout is set at RTT*1.5 and the ACK deferral
      timeout is set at RTT.
      
      Note that the calculated timeout is limited to a minimum of 4ns to make
      sure it doesn't happen too quickly.
      Signed-off-by: 's avatarDavid Howells <dhowells@redhat.com>
      beb8e5e4
    • David Howells's avatar
      rxrpc: Don't transmit DELAY ACKs immediately on proposal · 8637abaa
      David Howells authored
      Don't transmit a DELAY ACK immediately on proposal when the Rx window is
      rotated, but rather defer it to the work function.  This means that we have
      a chance to queue/consume more received packets before we actually send the
      DELAY ACK, or even cancel it entirely, thereby reducing the number of
      packets transmitted.
      
      We do, however, want to continue sending other types of packet immediately,
      particularly REQUESTED ACKs, as they may be used for RTT calculation by the
      other side.
      Signed-off-by: 's avatarDavid Howells <dhowells@redhat.com>
      8637abaa
    • David Howells's avatar
      rxrpc: Fix call timeouts · a158bdd3
      David Howells authored
      Fix the rxrpc call expiration timeouts and make them settable from
      userspace.  By analogy with other rx implementations, there should be three
      timeouts:
      
       (1) "Normal timeout"
      
           This is set for all calls and is triggered if we haven't received any
           packets from the peer in a while.  It is measured from the last time
           we received any packet on that call.  This is not reset by any
           connection packets (such as CHALLENGE/RESPONSE packets).
      
           If a service operation takes a long time, the server should generate
           PING ACKs at a duration that's substantially less than the normal
           timeout so is to keep both sides alive.  This is set at 1/6 of normal
           timeout.
      
       (2) "Idle timeout"
      
           This is set only for a service call and is triggered if we stop
           receiving the DATA packets that comprise the request data.  It is
           measured from the last time we received a DATA packet.
      
       (3) "Hard timeout"
      
           This can be set for a call and specified the maximum lifetime of that
           call.  It should not be specified by default.  Some operations (such
           as volume transfer) take a long time.
      
      Allow userspace to set/change the timeouts on a call with sendmsg, using a
      control message:
      
      	RXRPC_SET_CALL_TIMEOUTS
      
      The data to the message is a number of 32-bit words, not all of which need
      be given:
      
      	u32 hard_timeout;	/* sec from first packet */
      	u32 idle_timeout;	/* msec from packet Rx */
      	u32 normal_timeout;	/* msec from data Rx */
      
      This can be set in combination with any other sendmsg() that affects a
      call.
      Signed-off-by: 's avatarDavid Howells <dhowells@redhat.com>
      a158bdd3
    • David Howells's avatar
      rxrpc: Split the call params from the operation params · 48124178
      David Howells authored
      When rxrpc_sendmsg() parses the control message buffer, it places the
      parameters extracted into a structure, but lumps together call parameters
      (such as user call ID) with operation parameters (such as whether to send
      data, send an abort or accept a call).
      
      Split the call parameters out into their own structure, a copy of which is
      then embedded in the operation parameters struct.
      
      The call parameters struct is then passed down into the places that need it
      instead of passing the individual parameters.  This allows for extra call
      parameters to be added.
      Signed-off-by: 's avatarDavid Howells <dhowells@redhat.com>
      48124178
    • David Howells's avatar
      rxrpc: Delay terminal ACK transmission on a client call · 3136ef49
      David Howells authored
      Delay terminal ACK transmission on a client call by deferring it to the
      connection processor.  This allows it to be skipped if we can send the next
      call instead, the first DATA packet of which will implicitly ack this call.
      Signed-off-by: 's avatarDavid Howells <dhowells@redhat.com>
      3136ef49
    • David Howells's avatar
      rxrpc: Provide a different lockdep key for call->user_mutex for kernel calls · 9faaff59
      David Howells authored
      Provide a different lockdep key for rxrpc_call::user_mutex when the call is
      made on a kernel socket, such as by the AFS filesystem.
      
      The problem is that lockdep registers a false positive between userspace
      calling the sendmsg syscall on a user socket where call->user_mutex is held
      whilst userspace memory is accessed whereas the AFS filesystem may perform
      operations with mmap_sem held by the caller.
      
      In such a case, the following warning is produced.
      
      ======================================================
      WARNING: possible circular locking dependency detected
      4.14.0-fscache+ #243 Tainted: G            E
      ------------------------------------------------------
      modpost/16701 is trying to acquire lock:
       (&vnode->io_lock){+.+.}, at: [<ffffffffa000fc40>] afs_begin_vnode_operation+0x33/0x77 [kafs]
      
      but task is already holding lock:
       (&mm->mmap_sem){++++}, at: [<ffffffff8104376a>] __do_page_fault+0x1ef/0x486
      
      which lock already depends on the new lock.
      
      the existing dependency chain (in reverse order) is:
      
      -> #3 (&mm->mmap_sem){++++}:
             __might_fault+0x61/0x89
             _copy_from_iter_full+0x40/0x1fa
             rxrpc_send_data+0x8dc/0xff3
             rxrpc_do_sendmsg+0x62f/0x6a1
             rxrpc_sendmsg+0x166/0x1b7
             sock_sendmsg+0x2d/0x39
             ___sys_sendmsg+0x1ad/0x22b
             __sys_sendmsg+0x41/0x62
             do_syscall_64+0x89/0x1be
             return_from_SYSCALL_64+0x0/0x75
      
      -> #2 (&call->user_mutex){+.+.}:
             __mutex_lock+0x86/0x7d2
             rxrpc_new_client_call+0x378/0x80e
             rxrpc_kernel_begin_call+0xf3/0x154
             afs_make_call+0x195/0x454 [kafs]
             afs_vl_get_capabilities+0x193/0x198 [kafs]
             afs_vl_lookup_vldb+0x5f/0x151 [kafs]
             afs_create_volume+0x2e/0x2f4 [kafs]
             afs_mount+0x56a/0x8d7 [kafs]
             mount_fs+0x6a/0x109
             vfs_kern_mount+0x67/0x135
             do_mount+0x90b/0xb57
             SyS_mount+0x72/0x98
             do_syscall_64+0x89/0x1be
             return_from_SYSCALL_64+0x0/0x75
      
      -> #1 (k-sk_lock-AF_RXRPC){+.+.}:
             lock_sock_nested+0x74/0x8a
             rxrpc_kernel_begin_call+0x8a/0x154
             afs_make_call+0x195/0x454 [kafs]
             afs_fs_get_capabilities+0x17a/0x17f [kafs]
             afs_probe_fileserver+0xf7/0x2f0 [kafs]
             afs_select_fileserver+0x83f/0x903 [kafs]
             afs_fetch_status+0x89/0x11d [kafs]
             afs_iget+0x16f/0x4f8 [kafs]
             afs_mount+0x6c6/0x8d7 [kafs]
             mount_fs+0x6a/0x109
             vfs_kern_mount+0x67/0x135
             do_mount+0x90b/0xb57
             SyS_mount+0x72/0x98
             do_syscall_64+0x89/0x1be
             return_from_SYSCALL_64+0x0/0x75
      
      -> #0 (&vnode->io_lock){+.+.}:
             lock_acquire+0x174/0x19f
             __mutex_lock+0x86/0x7d2
             afs_begin_vnode_operation+0x33/0x77 [kafs]
             afs_fetch_data+0x80/0x12a [kafs]
             afs_readpages+0x314/0x405 [kafs]
             __do_page_cache_readahead+0x203/0x2ba
             filemap_fault+0x179/0x54d
             __do_fault+0x17/0x60
             __handle_mm_fault+0x6d7/0x95c
             handle_mm_fault+0x24e/0x2a3
             __do_page_fault+0x301/0x486
             do_page_fault+0x236/0x259
             page_fault+0x22/0x30
             __clear_user+0x3d/0x60
             padzero+0x1c/0x2b
             load_elf_binary+0x785/0xdc7
             search_binary_handler+0x81/0x1ff
             do_execveat_common.isra.14+0x600/0x888
             do_execve+0x1f/0x21
             SyS_execve+0x28/0x2f
             do_syscall_64+0x89/0x1be
             return_from_SYSCALL_64+0x0/0x75
      
      other info that might help us debug this:
      
      Chain exists of:
        &vnode->io_lock --> &call->user_mutex --> &mm->mmap_sem
      
       Possible unsafe locking scenario:
      
             CPU0                    CPU1
             ----                    ----
        lock(&mm->mmap_sem);
                                     lock(&call->user_mutex);
                                     lock(&mm->mmap_sem);
        lock(&vnode->io_lock);
      
       *** DEADLOCK ***
      
      1 lock held by modpost/16701:
       #0:  (&mm->mmap_sem){++++}, at: [<ffffffff8104376a>] __do_page_fault+0x1ef/0x486
      
      stack backtrace:
      CPU: 0 PID: 16701 Comm: modpost Tainted: G            E   4.14.0-fscache+ #243
      Hardware name: ASUS All Series/H97-PLUS, BIOS 2306 10/09/2014
      Call Trace:
       dump_stack+0x67/0x8e
       print_circular_bug+0x341/0x34f
       check_prev_add+0x11f/0x5d4
       ? add_lock_to_list.isra.12+0x8b/0x8b
       ? add_lock_to_list.isra.12+0x8b/0x8b
       ? __lock_acquire+0xf77/0x10b4
       __lock_acquire+0xf77/0x10b4
       lock_acquire+0x174/0x19f
       ? afs_begin_vnode_operation+0x33/0x77 [kafs]
       __mutex_lock+0x86/0x7d2
       ? afs_begin_vnode_operation+0x33/0x77 [kafs]
       ? afs_begin_vnode_operation+0x33/0x77 [kafs]
       ? afs_begin_vnode_operation+0x33/0x77 [kafs]
       afs_begin_vnode_operation+0x33/0x77 [kafs]
       afs_fetch_data+0x80/0x12a [kafs]
       afs_readpages+0x314/0x405 [kafs]
       __do_page_cache_readahead+0x203/0x2ba
       ? filemap_fault+0x179/0x54d
       filemap_fault+0x179/0x54d
       __do_fault+0x17/0x60
       __handle_mm_fault+0x6d7/0x95c
       handle_mm_fault+0x24e/0x2a3
       __do_page_fault+0x301/0x486
       do_page_fault+0x236/0x259
       page_fault+0x22/0x30
      RIP: 0010:__clear_user+0x3d/0x60
      RSP: 0018:ffff880071e93da0 EFLAGS: 00010202
      RAX: 0000000000000000 RBX: 000000000000011c RCX: 000000000000011c
      RDX: 0000000000000000 RSI: 0000000000000008 RDI: 000000000060f720
      RBP: 000000000060f720 R08: 0000000000000001 R09: 0000000000000000
      R10: 0000000000000001 R11: ffff8800b5459b68 R12: ffff8800ce150e00
      R13: 000000000060f720 R14: 00000000006127a8 R15: 0000000000000000
       padzero+0x1c/0x2b
       load_elf_binary+0x785/0xdc7
       search_binary_handler+0x81/0x1ff
       do_execveat_common.isra.14+0x600/0x888
       do_execve+0x1f/0x21
       SyS_execve+0x28/0x2f
       do_syscall_64+0x89/0x1be
       entry_SYSCALL64_slow_path+0x25/0x25
      RIP: 0033:0x7fdb6009ee07
      RSP: 002b:00007fff566d9728 EFLAGS: 00000246 ORIG_RAX: 000000000000003b
      RAX: ffffffffffffffda RBX: 000055ba57280900 RCX: 00007fdb6009ee07
      RDX: 000055ba5727f270 RSI: 000055ba5727cac0 RDI: 000055ba57280900
      RBP: 000055ba57280900 R08: 00007fff566d9700 R09: 0000000000000000
      R10: 000055ba5727cac0 R11: 0000000000000246 R12: 0000000000000000
      R13: 000055ba5727cac0 R14: 000055ba5727f270 R15: 0000000000000000
      Signed-off-by: 's avatarDavid Howells <dhowells@redhat.com>
      9faaff59
    • David Howells's avatar
      rxrpc: Don't set upgrade by default in sendmsg() · 48ca2463
      David Howells authored
      Don't set upgrade by default when creating a call from sendmsg().  This is
      a holdover from when I was testing the code.
      Signed-off-by: 's avatarDavid Howells <dhowells@redhat.com>
      48ca2463
    • David Howells's avatar
      rxrpc: The mutex lock returned by rxrpc_accept_call() needs releasing · 03a6c822
      David Howells authored
      The caller of rxrpc_accept_call() must release the lock on call->user_mutex
      returned by that function.
      Signed-off-by: 's avatarDavid Howells <dhowells@redhat.com>
      03a6c822