1. 30 Mar, 2015 27 commits
  2. 24 Mar, 2015 10 commits
    • Eric Dumazet's avatar
      tcp: make connect() mem charging friendly · bea5f6ef
      Eric Dumazet authored
      commit 355a901e upstream.
      
      While working on sk_forward_alloc problems reported by Denys
      Fedoryshchenko, we found that tcp connect() (and fastopen) do not call
      sk_wmem_schedule() for SYN packet (and/or SYN/DATA packet), so
      sk_forward_alloc is negative while connect is in progress.
      
      We can fix this by calling regular sk_stream_alloc_skb() both for the
      SYN packet (in tcp_connect()) and the syn_data packet in
      tcp_send_syn_data()
      
      Then, tcp_send_syn_data() can avoid copying syn_data as we simply
      can manipulate syn_data->cb[] to remove SYN flag (and increment seq)
      
      Instead of open coding memcpy_fromiovecend(), simply use this helper.
      
      This leaves in socket write queue clean fast clone skbs.
      
      This was tested against our fastopen packetdrill tests.
      Reported-by: default avatarDenys Fedoryshchenko <nuclearcat@nuclearcat.com>
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Acked-by: default avatarYuchung Cheng <ycheng@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      bea5f6ef
    • Catalin Marinas's avatar
      net: compat: Update get_compat_msghdr() to match copy_msghdr_from_user() behaviour · f5b93a1a
      Catalin Marinas authored
      commit 91edd096 upstream.
      
      Commit db31c55a (net: clamp ->msg_namelen instead of returning an
      error) introduced the clamping of msg_namelen when the unsigned value
      was larger than sizeof(struct sockaddr_storage). This caused a
      msg_namelen of -1 to be valid. The native code was subsequently fixed by
      commit dbb490b9 (net: socket: error on a negative msg_namelen).
      
      In addition, the native code sets msg_namelen to 0 when msg_name is
      NULL. This was done in commit (6a2a2b3a net:socket: set msg_namelen
      to 0 if msg_name is passed as NULL in msghdr struct from userland) and
      subsequently updated by 08adb7da (fold verify_iovec() into
      copy_msghdr_from_user()).
      
      This patch brings the get_compat_msghdr() in line with
      copy_msghdr_from_user().
      
      Fixes: db31c55a (net: clamp ->msg_namelen instead of returning an error)
      Cc: David S. Miller <davem@davemloft.net>
      Cc: Dan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      [ luis: backported to 3.16: used davem's backport to 3.14 ]
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      f5b93a1a
    • Josh Hunt's avatar
      tcp: fix tcp fin memory accounting · 421960be
      Josh Hunt authored
      commit d22e1537 upstream.
      
      tcp_send_fin() does not account for the memory it allocates properly, so
      sk_forward_alloc can be negative in cases where we've sent a FIN:
      
      ss example output (ss -amn | grep -B1 f4294):
      tcp    FIN-WAIT-1 0      1            192.168.0.1:45520         192.0.2.1:8080
      	skmem:(r0,rb87380,t0,tb87380,f4294966016,w1280,o0,bl0)
      Acked-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      421960be
    • Steven Barth's avatar
      ipv6: fix backtracking for throw routes · 0b925a51
      Steven Barth authored
      commit 73ba57bf upstream.
      
      for throw routes to trigger evaluation of other policy rules
      EAGAIN needs to be propagated up to fib_rules_lookup
      similar to how its done for IPv4
      
      A simple testcase for verification is:
      
      ip -6 rule add lookup 33333 priority 33333
      ip -6 route add throw 2001:db8::1
      ip -6 route add 2001:db8::1 via fe80::1 dev wlan0 table 33333
      ip route get 2001:db8::1
      Signed-off-by: default avatarSteven Barth <cyrus@openwrt.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      0b925a51
    • Ondrej Zary's avatar
      Revert "net: cx82310_eth: use common match macro" · 00f0defe
      Ondrej Zary authored
      commit 8d006e01 upstream.
      
      This reverts commit 11ad714b because
      it breaks cx82310_eth.
      
      The custom USB_DEVICE_CLASS macro matches
      bDeviceClass, bDeviceSubClass and bDeviceProtocol
      but the common USB_DEVICE_AND_INTERFACE_INFO matches
      bInterfaceClass, bInterfaceSubClass and bInterfaceProtocol instead, which are
      not specified.
      Signed-off-by: default avatarOndrej Zary <linux@rainbow-software.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      00f0defe
    • Al Viro's avatar
      rxrpc: bogus MSG_PEEK test in rxrpc_recvmsg() · 20187f9a
      Al Viro authored
      commit 7d985ed1 upstream.
      
      [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: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      20187f9a
    • Al Viro's avatar
      caif: fix MSG_OOB test in caif_seqpkt_recvmsg() · d4f6eec0
      Al Viro authored
      commit 3eeff778 upstream.
      
      It should be checking flags, not msg->msg_flags.  It's ->sendmsg()
      instances that need to look for that in ->msg_flags, ->recvmsg() ones
      (including the other ->recvmsg() instance in that file, as well as
      unix_dgram_recvmsg() this one claims to be imitating) check in flags.
      Braino had been introduced in commit dcda13 ("caif: Bugfix - use MSG_TRUNC
      in receive") back in 2010, so it goes quite a while back.
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      d4f6eec0
    • Eric Dumazet's avatar
      inet_diag: fix possible overflow in inet_diag_dump_one_icsk() · 1bfe6c38
      Eric Dumazet authored
      commit c8e2c80d upstream.
      
      inet_diag_dump_one_icsk() allocates too small skb.
      
      Add inet_sk_attr_size() helper right before inet_sk_diag_fill()
      so that it can be updated if/when new attributes are added.
      
      iproute2/ss currently does not use this dump_one() interface,
      this might explain nobody noticed this problem yet.
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      1bfe6c38
    • Arnd Bergmann's avatar
      rds: avoid potential stack overflow · c3d353a4
      Arnd Bergmann authored
      commit f862e07c upstream.
      
      The rds_iw_update_cm_id function stores a large 'struct rds_sock' object
      on the stack in order to pass a pair of addresses. This happens to just
      fit withint the 1024 byte stack size warning limit on x86, but just
      exceed that limit on ARM, which gives us this warning:
      
      net/rds/iw_rdma.c:200:1: warning: the frame size of 1056 bytes is larger than 1024 bytes [-Wframe-larger-than=]
      
      As the use of this large variable is basically bogus, we can rearrange
      the code to not do that. Instead of passing an rds socket into
      rds_iw_get_device, we now just pass the two addresses that we have
      available in rds_iw_update_cm_id, and we change rds_iw_get_mr accordingly,
      to create two address structures on the stack there.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Acked-by: default avatarSowmini Varadhan <sowmini.varadhan@oracle.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      c3d353a4
    • Alexey Kodanev's avatar
      net: sysctl_net_core: check SNDBUF and RCVBUF for min length · a7da750a
      Alexey Kodanev authored
      commit b1cb59cf upstream.
      
      sysctl has sysctl.net.core.rmem_*/wmem_* parameters which can be
      set to incorrect values. Given that 'struct sk_buff' allocates from
      rcvbuf, incorrectly set buffer length could result to memory
      allocation failures. For example, set them as follows:
      
          # sysctl net.core.rmem_default=64
            net.core.wmem_default = 64
          # sysctl net.core.wmem_default=64
            net.core.wmem_default = 64
          # ping localhost -s 1024 -i 0 > /dev/null
      
      This could result to the following failure:
      
      skbuff: skb_over_panic: text:ffffffff81628db4 len:-32 put:-32
      head:ffff88003a1cc200 data:ffff88003a1cc200 tail:0xffffffe0 end:0xc0 dev:<NULL>
      kernel BUG at net/core/skbuff.c:102!
      invalid opcode: 0000 [#1] SMP
      ...
      task: ffff88003b7f5550 ti: ffff88003ae88000 task.ti: ffff88003ae88000
      RIP: 0010:[<ffffffff8155fbd1>]  [<ffffffff8155fbd1>] skb_put+0xa1/0xb0
      RSP: 0018:ffff88003ae8bc68  EFLAGS: 00010296
      RAX: 000000000000008d RBX: 00000000ffffffe0 RCX: 0000000000000000
      RDX: ffff88003fdcf598 RSI: ffff88003fdcd9c8 RDI: ffff88003fdcd9c8
      RBP: ffff88003ae8bc88 R08: 0000000000000001 R09: 0000000000000000
      R10: 0000000000000001 R11: 00000000000002b2 R12: 0000000000000000
      R13: 0000000000000000 R14: ffff88003d3f7300 R15: ffff88000012a900
      FS:  00007fa0e2b4a840(0000) GS:ffff88003fc00000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 0000000000d0f7e0 CR3: 000000003b8fb000 CR4: 00000000000006f0
      Stack:
       ffff88003a1cc200 00000000ffffffe0 00000000000000c0 ffffffff818cab1d
       ffff88003ae8bd68 ffffffff81628db4 ffff88003ae8bd48 ffff88003b7f5550
       ffff880031a09408 ffff88003b7f5550 ffff88000012aa48 ffff88000012ab00
      Call Trace:
       [<ffffffff81628db4>] unix_stream_sendmsg+0x2c4/0x470
       [<ffffffff81556f56>] sock_write_iter+0x146/0x160
       [<ffffffff811d9612>] new_sync_write+0x92/0xd0
       [<ffffffff811d9cd6>] vfs_write+0xd6/0x180
       [<ffffffff811da499>] SyS_write+0x59/0xd0
       [<ffffffff81651532>] system_call_fastpath+0x12/0x17
      Code: 00 00 48 89 44 24 10 8b 87 c8 00 00 00 48 89 44 24 08 48 8b 87 d8 00
            00 00 48 c7 c7 30 db 91 81 48 89 04 24 31 c0 e8 4f a8 0e 00 <0f> 0b
            eb fe 66 66 2e 0f 1f 84 00 00 00 00 00 55 48 89 e5 48 83
      RIP  [<ffffffff8155fbd1>] skb_put+0xa1/0xb0
      RSP <ffff88003ae8bc68>
      Kernel panic - not syncing: Fatal exception
      
      Moreover, the possible minimum is 1, so we can get another kernel panic:
      ...
      BUG: unable to handle kernel paging request at ffff88013caee5c0
      IP: [<ffffffff815604cf>] __alloc_skb+0x12f/0x1f0
      ...
      Signed-off-by: default avatarAlexey Kodanev <alexey.kodanev@oracle.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      a7da750a
  3. 23 Mar, 2015 3 commits
    • David S. Miller's avatar
      sparc64: Fix several bugs in memmove(). · f27d9c41
      David S. Miller authored
      commit 2077cef4 upstream.
      
      Firstly, handle zero length calls properly.  Believe it or not there
      are a few of these happening during early boot.
      
      Next, we can't just drop to a memcpy() call in the forward copy case
      where dst <= src.  The reason is that the cache initializing stores
      used in the Niagara memcpy() implementations can end up clearing out
      cache lines before we've sourced their original contents completely.
      
      For example, considering NG4memcpy, the main unrolled loop begins like
      this:
      
           load   src + 0x00
           load   src + 0x08
           load   src + 0x10
           load   src + 0x18
           load   src + 0x20
           store  dst + 0x00
      
      Assume dst is 64 byte aligned and let's say that dst is src - 8 for
      this memcpy() call.  That store at the end there is the one to the
      first line in the cache line, thus clearing the whole line, which thus
      clobbers "src + 0x28" before it even gets loaded.
      
      To avoid this, just fall through to a simple copy only mildly
      optimized for the case where src and dst are 8 byte aligned and the
      length is a multiple of 8 as well.  We could get fancy and call
      GENmemcpy() but this is good enough for how this thing is actually
      used.
      Reported-by: default avatarDavid Ahern <david.ahern@oracle.com>
      Reported-by: default avatarBob Picco <bpicco@meloft.net>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      f27d9c41
    • David Ahern's avatar
      sparc: Touch NMI watchdog when walking cpus and calling printk · 1d1d2f24
      David Ahern authored
      commit 31aaa98c upstream.
      
      With the increase in number of CPUs calls to functions that dump
      output to console (e.g., arch_trigger_all_cpu_backtrace) can take
      a long time to complete. If IRQs are disabled eventually the NMI
      watchdog kicks in and creates more havoc. Avoid by telling the NMI
      watchdog everything is ok.
      Signed-off-by: default avatarDavid Ahern <david.ahern@oracle.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      1d1d2f24
    • David Ahern's avatar
      sparc: perf: Make counting mode actually work · e13a39a8
      David Ahern authored
      commit d51291cb upstream.
      
      Currently perf-stat (aka, counting mode) does not work:
      
      $ perf stat ls
      ...
       Performance counter stats for 'ls':
      
                1.585665      task-clock (msec)         #    0.580 CPUs utilized
                      24      context-switches          #    0.015 M/sec
                       0      cpu-migrations            #    0.000 K/sec
                      86      page-faults               #    0.054 M/sec
         <not supported>      cycles
         <not supported>      stalled-cycles-frontend
         <not supported>      stalled-cycles-backend
         <not supported>      instructions
         <not supported>      branches
         <not supported>      branch-misses
      
             0.002735100 seconds time elapsed
      
      The reason is that state is never reset (stays with PERF_HES_UPTODATE set).
      Add a call to sparc_pmu_enable_event during the added_event handling.
      Clean up the encoding since pmu_start calls sparc_pmu_enable_event which
      does the same. Passing PERF_EF_RELOAD to sparc_pmu_start means the call
      to sparc_perf_event_set_period can be removed as well.
      
      With this patch:
      
      $ perf stat ls
      ...
       Performance counter stats for 'ls':
      
                1.552890      task-clock (msec)         #    0.552 CPUs utilized
                      24      context-switches          #    0.015 M/sec
                       0      cpu-migrations            #    0.000 K/sec
                      86      page-faults               #    0.055 M/sec
               5,748,997      cycles                    #    3.702 GHz
         <not supported>      stalled-cycles-frontend:HG
         <not supported>      stalled-cycles-backend:HG
               1,684,362      instructions:HG           #    0.29  insns per cycle
                 295,133      branches:HG               #  190.054 M/sec
                  28,007      branch-misses:HG          #    9.49% of all branches
      
             0.002815665 seconds time elapsed
      Signed-off-by: default avatarDavid Ahern <david.ahern@oracle.com>
      Acked-by: default avatarBob Picco <bob.picco@oracle.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      e13a39a8