1. 11 5月, 2015 2 次提交
  2. 12 4月, 2015 1 次提交
  3. 01 4月, 2015 4 次提交
  4. 16 3月, 2015 1 次提交
    • A
      rxrpc: bogus MSG_PEEK test in rxrpc_recvmsg() · 7d985ed1
      Al Viro 提交于
      [I would really like an ACK on that one from dhowells; it appears to be
      quite straightforward, but...]
      
      MSG_PEEK isn't passed to ->recvmsg() via msg->msg_flags; as the matter of
      fact, neither the kernel users of rxrpc, nor the syscalls ever set that bit
      in there.  It gets passed via flags; in fact, another such check in the same
      function is done correctly - as flags & MSG_PEEK.
      
      It had been that way (effectively disabled) for 8 years, though, so the patch
      needs beating up - that case had never been tested.  If it is correct, it's
      -stable fodder.
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7d985ed1
  5. 09 3月, 2015 1 次提交
    • W
      ip: fix error queue empty skb handling · c247f053
      Willem de Bruijn 提交于
      When reading from the error queue, msg_name and msg_control are only
      populated for some errors. A new exception for empty timestamp skbs
      added a false positive on icmp errors without payload.
      
      `traceroute -M udpconn` only displayed gateways that return payload
      with the icmp error: the embedded network headers are pulled before
      sock_queue_err_skb, leaving an skb with skb->len == 0 otherwise.
      
      Fix this regression by refining when msg_name and msg_control
      branches are taken. The solutions for the two fields are independent.
      
      msg_name only makes sense for errors that configure serr->port and
      serr->addr_offset. Test the first instead of skb->len. This also fixes
      another issue. saddr could hold the wrong data, as serr->addr_offset
      is not initialized  in some code paths, pointing to the start of the
      network header. It is only valid when serr->port is set (non-zero).
      
      msg_control support differs between IPv4 and IPv6. IPv4 only honors
      requests for ICMP and timestamps with SOF_TIMESTAMPING_OPT_CMSG. The
      skb->len test can simply be removed, because skb->dev is also tested
      and never true for empty skbs. IPv6 honors requests for all errors
      aside from local errors and timestamps on empty skbs.
      
      In both cases, make the policy more explicit by moving this logic to
      a new function that decides whether to process msg_control and that
      optionally prepares the necessary fields in skb->cb[]. After this
      change, the IPv4 and IPv6 paths are more similar.
      
      The last case is rxrpc. Here, simply refine to only match timestamps.
      
      Fixes: 49ca0d8b ("net-timestamp: no-payload option")
      Reported-by: NJan Niehusmann <jan@gondor.com>
      Signed-off-by: NWillem de Bruijn <willemb@google.com>
      
      ----
      
      Changes
        v1->v2
        - fix local origin test inversion in ip6_datagram_support_cmsg
        - make v4 and v6 code paths more similar by introducing analogous
          ipv4_datagram_support_cmsg
        - fix compile bug in rxrpc
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c247f053
  6. 03 3月, 2015 1 次提交
  7. 02 3月, 2015 3 次提交
  8. 04 2月, 2015 2 次提交
  9. 03 2月, 2015 1 次提交
    • W
      net-timestamp: no-payload option · 49ca0d8b
      Willem de Bruijn 提交于
      Add timestamping option SOF_TIMESTAMPING_OPT_TSONLY. For transmit
      timestamps, this loops timestamps on top of empty packets.
      
      Doing so reduces the pressure on SO_RCVBUF. Payload inspection and
      cmsg reception (aside from timestamps) are no longer possible. This
      works together with a follow on patch that allows administrators to
      only allow tx timestamping if it does not loop payload or metadata.
      Signed-off-by: NWillem de Bruijn <willemb@google.com>
      
      ----
      
      Changes (rfc -> v1)
        - add documentation
        - remove unnecessary skb->len test (thanks to Richard Cochran)
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      49ca0d8b
  10. 11 12月, 2014 1 次提交
  11. 10 12月, 2014 1 次提交
  12. 06 11月, 2014 1 次提交
    • D
      net: Add and use skb_copy_datagram_msg() helper. · 51f3d02b
      David S. Miller 提交于
      This encapsulates all of the skb_copy_datagram_iovec() callers
      with call argument signature "skb, offset, msghdr->msg_iov, length".
      
      When we move to iov_iters in the networking, the iov_iter object will
      sit in the msghdr.
      
      Having a helper like this means there will be less places to touch
      during that transformation.
      
      Based upon descriptions and patch from Al Viro.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      51f3d02b
  13. 17 9月, 2014 1 次提交
  14. 10 9月, 2014 1 次提交
  15. 02 9月, 2014 1 次提交
    • W
      sock: deduplicate errqueue dequeue · 364a9e93
      Willem de Bruijn 提交于
      sk->sk_error_queue is dequeued in four locations. All share the
      exact same logic. Deduplicate.
      
      Also collapse the two critical sections for dequeue (at the top of
      the recv handler) and signal (at the bottom).
      
      This moves signal generation for the next packet forward, which should
      be harmless.
      
      It also changes the behavior if the recv handler exits early with an
      error. Previously, a signal for follow-up packets on the errqueue
      would then not be scheduled. The new behavior, to always signal, is
      arguably a bug fix.
      
      For rxrpc, the change causes the same function to be called repeatedly
      for each queued packet (because the recv handler == sk_error_report).
      It is likely that all packets will fail for the same reason (e.g.,
      memory exhaustion).
      
      This code runs without sk_lock held, so it is not safe to trust that
      sk->sk_err is immutable inbetween releasing q->lock and the subsequent
      test. Introduce int err just to avoid this potential race.
      Signed-off-by: NWillem de Bruijn <willemb@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      364a9e93
  16. 23 8月, 2014 1 次提交
  17. 23 7月, 2014 1 次提交
  18. 21 7月, 2014 1 次提交
  19. 17 5月, 2014 1 次提交
  20. 12 4月, 2014 1 次提交
    • D
      net: Fix use after free by removing length arg from sk_data_ready callbacks. · 676d2369
      David S. Miller 提交于
      Several spots in the kernel perform a sequence like:
      
      	skb_queue_tail(&sk->s_receive_queue, skb);
      	sk->sk_data_ready(sk, skb->len);
      
      But at the moment we place the SKB onto the socket receive queue it
      can be consumed and freed up.  So this skb->len access is potentially
      to freed up memory.
      
      Furthermore, the skb->len can be modified by the consumer so it is
      possible that the value isn't accurate.
      
      And finally, no actual implementation of this callback actually uses
      the length argument.  And since nobody actually cared about it's
      value, lots of call sites pass arbitrary values in such as '0' and
      even '1'.
      
      So just remove the length argument from the callback, that way there
      is no confusion whatsoever and all of these use-after-free cases get
      fixed as a side effect.
      
      Based upon a patch by Eric Dumazet and his suggestion to audit this
      issue tree-wide.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      676d2369
  21. 04 3月, 2014 1 次提交
  22. 27 2月, 2014 5 次提交
    • D
      af_rxrpc: Request an ACK for every alternate DATA packet · e8388eb1
      David Howells 提交于
      Set the RxRPC header flag to request an ACK packet for every odd-numbered DATA
      packet unless it's the last one (which implicitly requests an ACK anyway).
      This is similar to how librx appears to work.
      
      If we don't do this, we'll send out a full window of packets and then just sit
      there until the other side gets bored and sends an ACK to indicate that it's
      been idle for a while and has received no new packets.
      
      Requesting a lot of ACKs shouldn't be a problem as ACKs should be merged when
      possible.
      
      As AF_RXRPC currently works, it will schedule an ACK to be generated upon
      receipt of a DATA packet with the ACK-request packet set - and in the time
      taken to schedule this in a work queue, several other packets are likely to
      arrive and then all get ACK'd together.
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      e8388eb1
    • D
      af_rxrpc: Expose more RxRPC parameters via sysctls · 817913d8
      David Howells 提交于
      Expose RxRPC parameters via sysctls to control the Rx window size, the Rx MTU
      maximum size and the number of packets that can be glued into a jumbo packet.
      
      More info added to Documentation/networking/rxrpc.txt.
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      817913d8
    • D
      af_rxrpc: Improve ACK production · 9823f39a
      David Howells 提交于
      Improve ACK production by the following means:
      
       (1) Don't send an ACK_REQUESTED ack immediately even if the RXRPC_MORE_PACKETS
           flag isn't set on a data packet that has also has RXRPC_REQUEST_ACK set.
      
           MORE_PACKETS just means that the sender just emptied its Tx data buffer.
           More data will be forthcoming unless RXRPC_LAST_PACKET is also flagged.
      
           It is possible to see runs of DATA packets with MORE_PACKETS unset that
           aren't waiting for an ACK.
      
           It is therefore better to wait a small instant to see if we can combine an
           ACK for several packets.
      
       (2) Don't send an ACK_IDLE ack immediately unless we're responding to the
           terminal data packet of a call.
      
           Whilst sending an ACK_IDLE mid-call serves to let the other side know
           that we won't be asking it to resend certain Tx buffers and that it can
           discard them, spamming it with loads of acks just because we've
           temporarily run out of data just distracts it.
      
       (3) Put the ACK_IDLE ack generation timeout up to half a second rather than a
           single jiffy.  Just because we haven't been given more data immediately
           doesn't mean that more isn't forthcoming.  The other side may be busily
           finding the data to send to us.
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      9823f39a
    • D
      af_rxrpc: Add sysctls for configuring RxRPC parameters · 5873c083
      David Howells 提交于
      Add sysctls for configuring RxRPC protocol handling, specifically controls on
      delays before ack generation, the delay before resending a packet, the maximum
      lifetime of a call and the expiration times of calls, connections and
      transports that haven't been recently used.
      
      More info added in Documentation/networking/rxrpc.txt.
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      5873c083
    • D
      af_rxrpc: Fix UDP MTU calculation from ICMP_FRAG_NEEDED · 6c9a2d32
      David Howells 提交于
      AF_RXRPC sends UDP packets with the "Don't Fragment" bit set in an attempt to
      determine the maximum packet size between the local socket and the peer by
      invoking the generation of ICMP_FRAG_NEEDED packets.
      
      Once a packet is sent with the "Don't Fragment" bit set, it is then
      inconvenient to break it up as that requires recalculating all the rxrpc serial
      and sequence numbers and reencrypting all the fragments, so we switch off the
      "Don't Fragment" service temporarily and send the bounced packet again.  Future
      packets then use the new MTU.
      
      That's all fine.  The problem lies in rxrpc_UDP_error_report() where the code
      that deals with ICMP_FRAG_NEEDED packets lives.  Packets of this type have a
      field (ee_info) to indicate the maximum packet size at the reporting node - but
      sometimes ee_info isn't filled in and is just left as 0 and the code must allow
      for this.
      
      When ee_info is 0, the code should take the MTU size we're currently using and
      reduce it for the next packet we want to send.  However, it takes ee_info
      (which is known to be 0) and tries to reduce that instead.
      
      This was discovered by Coverity.
      Reported-by: NDave Jones <davej@redhat.com>
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      6c9a2d32
  23. 08 2月, 2014 2 次提交
  24. 26 1月, 2014 3 次提交
    • T
      af_rxrpc: Handle frames delivered from another VM · 1ea42735
      Tim Smith 提交于
      On input, CHECKSUM_PARTIAL should be treated the same way as
      CHECKSUM_UNNECESSARY. See include/linux/skbuff.h
      Signed-off-by: NTim Smith <tim@electronghost.co.uk>
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      1ea42735
    • T
      af_rxrpc: Avoid setting up double-free on checksum error · 24a9981e
      Tim Smith 提交于
      skb_kill_datagram() does not dequeue the skb when MSG_PEEK is unset.
      This leaves a free'd skb on the queue, resulting a double-free later.
      
      Without this, the following oops can occur:
      
      BUG: unable to handle kernel NULL pointer dereference at 0000000000000008
      IP: [<ffffffff8154fcf7>] skb_dequeue+0x47/0x70
      PGD 0
      Oops: 0002 [#1] SMP
      Modules linked in: af_rxrpc ...
      CPU: 0 PID: 1191 Comm: listen Not tainted 3.12.0+ #4
      Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
      task: ffff8801183536b0 ti: ffff880035c92000 task.ti: ffff880035c92000
      RIP: 0010:[<ffffffff8154fcf7>] skb_dequeue+0x47/0x70
      RSP: 0018:ffff880035c93db8  EFLAGS: 00010097
      RAX: 0000000000000246 RBX: ffff8800d2754b00 RCX: 0000000000000000
      RDX: 0000000000000000 RSI: 0000000000000202 RDI: ffff8800d254c084
      RBP: ffff880035c93dd0 R08: ffff880035c93cf0 R09: ffff8800d968f270
      R10: 0000000000000000 R11: 0000000000000293 R12: ffff8800d254c070
      R13: ffff8800d254c084 R14: ffff8800cd861240 R15: ffff880119b39720
      FS:  00007f37a969d740(0000) GS:ffff88011fc00000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
      CR2: 0000000000000008 CR3: 00000000d4413000 CR4: 00000000000006f0
      Stack:
       ffff8800d254c000 ffff8800d254c070 ffff8800d254c2c0 ffff880035c93df8
       ffffffffa041a5b8 ffff8800cd844c80 ffffffffa04385a0 ffff8800cd844cb0
       ffff880035c93e18 ffffffff81546cef ffff8800d45fea00 0000000000000008
      Call Trace:
       [<ffffffffa041a5b8>] rxrpc_release+0x128/0x2e0 [af_rxrpc]
       [<ffffffff81546cef>] sock_release+0x1f/0x80
       [<ffffffff81546d62>] sock_close+0x12/0x20
       [<ffffffff811aaba1>] __fput+0xe1/0x230
       [<ffffffff811aad3e>] ____fput+0xe/0x10
       [<ffffffff810862cc>] task_work_run+0xbc/0xe0
       [<ffffffff8106a3be>] do_exit+0x2be/0xa10
       [<ffffffff8116dc47>] ? do_munmap+0x297/0x3b0
       [<ffffffff8106ab8f>] do_group_exit+0x3f/0xa0
       [<ffffffff8106ac04>] SyS_exit_group+0x14/0x20
       [<ffffffff8166b069>] system_call_fastpath+0x16/0x1b
      Signed-off-by: NTim Smith <tim@electronghost.co.uk>
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      24a9981e
    • A
      RxRPC: do not unlock unheld spinlock in rxrpc_connect_exclusive() · 8f22ba61
      Alexey Khoroshilov 提交于
      If rx->conn is not NULL, rxrpc_connect_exclusive() does not
      acquire the transport's client lock, but it still releases it.
      
      The patch adds locking of the spinlock to this path.
      
      Found by Linux Driver Verification project (linuxtesting.org).
      Signed-off-by: NAlexey Khoroshilov <khoroshilov@ispras.ru>
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      8f22ba61
  25. 22 1月, 2014 1 次提交
  26. 19 1月, 2014 1 次提交
反馈
建议
客服 返回
顶部