1. 15 3月, 2013 3 次提交
  2. 14 3月, 2013 2 次提交
    • P
      skb: Propagate pfmemalloc on skb from head page only · cca7af38
      Pavel Emelyanov 提交于
      Hi.
      
      I'm trying to send big chunks of memory from application address space via
      TCP socket using vmsplice + splice like this
      
         mem = mmap(128Mb);
         vmsplice(pipe[1], mem); /* splice memory into pipe */
         splice(pipe[0], tcp_socket); /* send it into network */
      
      When I'm lucky and a huge page splices into the pipe and then into the socket
      _and_ client and server ends of the TCP connection are on the same host,
      communicating via lo, the whole connection gets stuck! The sending queue
      becomes full and app stops writing/splicing more into it, but the receiving
      queue remains empty, and that's why.
      
      The __skb_fill_page_desc observes a tail page of a huge page and erroneously
      propagates its page->pfmemalloc value onto socket (the pfmemalloc on tail pages
      contain garbage). Then this skb->pfmemalloc leaks through lo and due to the
      
          tcp_v4_rcv
          sk_filter
              if (skb->pfmemalloc && !sock_flag(sk, SOCK_MEMALLOC)) /* true */
                  return -ENOMEM
              goto release_and_discard;
      
      no packets reach the socket. Even TCP re-transmits are dropped by this, as skb
      cloning clones the pfmemalloc flag as well.
      
      That said, here's the proper page->pfmemalloc propagation onto socket: we
      must check the huge-page's head page only, other pages' pfmemalloc and mapping
      values do not contain what is expected in this place. However, I'm not sure
      whether this fix is _complete_, since pfmemalloc propagation via lo also
      oesn't look great.
      
      Both, bit propagation from page to skb and this check in sk_filter, were
      introduced by c48a11c7 (netvm: propagate page->pfmemalloc to skb), in v3.5 so
      Mel and stable@ are in Cc.
      Signed-off-by: NPavel Emelyanov <xemul@parallels.com>
      Acked-by: NEric Dumazet <edumazet@google.com>
      Acked-by: NMel Gorman <mgorman@suse.de>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      cca7af38
    • E
      tcp: fix skb_availroom() · 16fad69c
      Eric Dumazet 提交于
      Chrome OS team reported a crash on a Pixel ChromeBook in TCP stack :
      
      https://code.google.com/p/chromium/issues/detail?id=182056
      
      commit a21d4572 (tcp: avoid order-1 allocations on wifi and tx
      path) did a poor choice adding an 'avail_size' field to skb, while
      what we really needed was a 'reserved_tailroom' one.
      
      It would have avoided commit 22b4a4f2 (tcp: fix retransmit of
      partially acked frames) and this commit.
      
      Crash occurs because skb_split() is not aware of the 'avail_size'
      management (and should not be aware)
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Reported-by: NMukesh Agrawal <quiche@chromium.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      16fad69c
  3. 13 3月, 2013 9 次提交
  4. 12 3月, 2013 8 次提交
  5. 11 3月, 2013 17 次提交
  6. 10 3月, 2013 1 次提交
    • M
      dcbnl: fix various netlink info leaks · 29cd8ae0
      Mathias Krause 提交于
      The dcb netlink interface leaks stack memory in various places:
      * perm_addr[] buffer is only filled at max with 12 of the 32 bytes but
        copied completely,
      * no in-kernel driver fills all fields of an IEEE 802.1Qaz subcommand,
        so we're leaking up to 58 bytes for ieee_ets structs, up to 136 bytes
        for ieee_pfc structs, etc.,
      * the same is true for CEE -- no in-kernel driver fills the whole
        struct,
      
      Prevent all of the above stack info leaks by properly initializing the
      buffers/structures involved.
      Signed-off-by: NMathias Krause <minipli@googlemail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      29cd8ae0