1. 17 Dec, 2014 5 commits
  2. 15 Dec, 2014 2 commits
  3. 12 Dec, 2014 4 commits
  4. 10 Dec, 2014 12 commits
    • Alexei Starovoitov's avatar
      net: sock: fix access via invalid file descriptor · 198bf1b0
      Alexei Starovoitov authored
      
      
      0day robot reported the following crash:
      [   21.233581] BUG: unable to handle kernel NULL pointer dereference at 0000000000000007
      [   21.234709] IP: [<ffffffff8156ebda>] sk_attach_bpf+0x39/0xc2
      
      It's due to bpf_prog_get() returning ERR_PTR.
      Check it properly.
      Reported-by: default avatarFengguang Wu <fengguang.wu@intel.com>
      Fixes: 89aa0758
      
       ("net: sock: allow eBPF programs to be attached to sockets")
      Signed-off-by: default avatarAlexei Starovoitov <ast@plumgrid.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      198bf1b0
    • Gu Zheng's avatar
      net: introduce helper macro for_each_cmsghdr · f95b414e
      Gu Zheng authored
      
      
      Introduce helper macro for_each_cmsghdr as a wrapper of the enumerating
      cmsghdr from msghdr, just cleanup.
      Signed-off-by: default avatarGu Zheng <guz.fnst@cn.fujitsu.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f95b414e
    • Johannes Weiner's avatar
      mm: memcontrol: lockless page counters · 3e32cb2e
      Johannes Weiner authored
      
      
      Memory is internally accounted in bytes, using spinlock-protected 64-bit
      counters, even though the smallest accounting delta is a page.  The
      counter interface is also convoluted and does too many things.
      
      Introduce a new lockless word-sized page counter API, then change all
      memory accounting over to it.  The translation from and to bytes then only
      happens when interfacing with userspace.
      
      The removed locking overhead is noticable when scaling beyond the per-cpu
      charge caches - on a 4-socket machine with 144-threads, the following test
      shows the performance differences of 288 memcgs concurrently running a
      page fault benchmark:
      
      vanilla:
      
         18631648.500498      task-clock (msec)         #  140.643 CPUs utilized            ( +-  0.33% )
               1,380,638      context-switches          #    0.074 K/sec                    ( +-  0.75% )
                  24,390      cpu-migrations            #    0.001 K/sec                    ( +-  8.44% )
           1,843,305,768      page-faults               #    0.099 M/sec                    ( +-  0.00% )
      50,134,994,088,218      cycles                    #    2.691 GHz                      ( +-  0.33% )
         <not supported>      stalled-cycles-frontend
         <not supported>      stalled-cycles-backend
       8,049,712,224,651      instructions              #    0.16  insns per cycle          ( +-  0.04% )
       1,586,970,584,979      branches                  #   85.176 M/sec                    ( +-  0.05% )
           1,724,989,949      branch-misses             #    0.11% of all branches          ( +-  0.48% )
      
           132.474343877 seconds time elapsed                                          ( +-  0.21% )
      
      lockless:
      
         12195979.037525      task-clock (msec)         #  133.480 CPUs utilized            ( +-  0.18% )
                 832,850      context-switches          #    0.068 K/sec                    ( +-  0.54% )
                  15,624      cpu-migrations            #    0.001 K/sec                    ( +- 10.17% )
           1,843,304,774      page-faults               #    0.151 M/sec                    ( +-  0.00% )
      32,811,216,801,141      cycles                    #    2.690 GHz                      ( +-  0.18% )
         <not supported>      stalled-cycles-frontend
         <not supported>      stalled-cycles-backend
       9,999,265,091,727      instructions              #    0.30  insns per cycle          ( +-  0.10% )
       2,076,759,325,203      branches                  #  170.282 M/sec                    ( +-  0.12% )
           1,656,917,214      branch-misses             #    0.08% of all branches          ( +-  0.55% )
      
            91.369330729 seconds time elapsed                                          ( +-  0.45% )
      
      On top of improved scalability, this also gets rid of the icky long long
      types in the very heart of memcg, which is great for 32 bit and also makes
      the code a lot more readable.
      
      Notable differences between the old and new API:
      
      - res_counter_charge() and res_counter_charge_nofail() become
        page_counter_try_charge() and page_counter_charge() resp. to match
        the more common kernel naming scheme of try_do()/do()
      
      - res_counter_uncharge_until() is only ever used to cancel a local
        counter and never to uncharge bigger segments of a hierarchy, so
        it's replaced by the simpler page_counter_cancel()
      
      - res_counter_set_limit() is replaced by page_counter_limit(), which
        expects its callers to serialize against themselves
      
      - res_counter_memparse_write_strategy() is replaced by
        page_counter_limit(), which rounds down to the nearest page size -
        rather than up.  This is more reasonable for explicitely requested
        hard upper limits.
      
      - to keep charging light-weight, page_counter_try_charge() charges
        speculatively, only to roll back if the result exceeds the limit.
        Because of this, a failing bigger charge can temporarily lock out
        smaller charges that would otherwise succeed.  The error is bounded
        to the difference between the smallest and the biggest possible
        charge size, so for memcg, this means that a failing THP charge can
        send base page charges into reclaim upto 2MB (4MB) before the limit
        would have been reached.  This should be acceptable.
      
      [akpm@linux-foundation.org: add includes for WARN_ON_ONCE and memparse]
      [akpm@linux-foundation.org: add includes for WARN_ON_ONCE, memparse, strncmp, and PAGE_SIZE]
      Signed-off-by: default avatarJohannes Weiner <hannes@cmpxchg.org>
      Acked-by: default avatarMichal Hocko <mhocko@suse.cz>
      Acked-by: default avatarVladimir Davydov <vdavydov@parallels.com>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: David Rientjes <rientjes@google.com>
      Cc: Stephen Rothwell <sfr@canb.auug.org.au>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      3e32cb2e
    • Joe Perches's avatar
      irda: Convert function pointer arrays and uses to const · 785c20a0
      Joe Perches authored
      
      
      Making things const is a good thing.
      
      (x86-64 defconfig with all irda)
      $ size net/irda/built-in.o*
         text	   data	    bss	    dec	    hex	filename
       109276	   1868	    244	 111388	  1b31c	net/irda/built-in.o.new
       108828	   2316	    244	 111388	  1b31c	net/irda/built-in.o.old
      Signed-off-by: default avatarJoe Perches <joe@perches.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      785c20a0
    • Joe Perches's avatar
      llc: Make llc_sap_action_t function pointer arrays const · 22bbf5f3
      Joe Perches authored
      
      
      It's better when function pointer arrays aren't modifiable.
      
      Net change:
      
      $ size net/llc/built-in.o.*
         text	   data	    bss	    dec	    hex	filename
        61193	  12758	   1344	  75295	  1261f	net/llc/built-in.o.new
        47113	  27030	   1344	  75487	  126df	net/llc/built-in.o.old
      Signed-off-by: default avatarJoe Perches <joe@perches.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      22bbf5f3
    • Joe Perches's avatar
      llc: Make llc_conn_ev_qfyr_t function pointer arrays const · 9b373069
      Joe Perches authored
      
      
      It's better when function pointer arrays aren't modifiable.
      
      Net change from original:
      
      $ size net/llc/built-in.o.*
         text	   data	    bss	    dec	    hex	filename
        61065	  12886	   1344	  75295	  1261f	net/llc/built-in.o.new
        47113	  27030	   1344	  75487	  126df	net/llc/built-in.o.old
      Signed-off-by: default avatarJoe Perches <joe@perches.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      9b373069
    • Joe Perches's avatar
      llc: Make function pointer arrays const · 14b7d95f
      Joe Perches authored
      
      
      It's better when function pointer arrays aren't modifiable.
      Signed-off-by: default avatarJoe Perches <joe@perches.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      14b7d95f
    • Daniel Borkmann's avatar
      net: replace remaining users of arch_fast_hash with jhash · 87545899
      Daniel Borkmann authored
      This patch effectively reverts commit 500f8087 ("net: ovs: use CRC32
      accelerated flow hash if available"), and other remaining arch_fast_hash()
      users such as from nfsd via commit 6282cd56 ("NFSD: Don't hand out
      delegations for 30 seconds after recalling them.") where it has been used
      as a hash function for bloom filtering.
      
      While we think that these users are actually not much of concern, it has
      been requested to remove the arch_fast_hash() library bits that arose
      from [1] entirely as per recent discussion [2]. The main argument is that
      using it as a hash may introduce bias due to its linearity (see avalanche
      criterion) and thus makes it less clear (though we tried to document that)
      when this security/performance trade-off is actually acceptable for a
      general purpose library function.
      
      Lets therefore avoid any further confusion on this matter and remove it to
      prevent any future accidental misuse of it. For the time being, this is
      going to make hashing of flow keys a bit more expensive in the ovs case,
      but future work could reevaluate a different hashing discipline.
      
        [1] https://patchwork.ozlabs.org/patch/299369/
        [2] https://patchwork.ozlabs.org/patch/418756/
      
      
      
      Cc: Neil Brown <neilb@suse.de>
      Cc: Francesco Fusco <fusco@ntop.org>
      Cc: Jesse Gross <jesse@nicira.com>
      Cc: Thomas Graf <tgraf@suug.ch>
      Signed-off-by: default avatarDaniel Borkmann <dborkman@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      87545899
    • Daniel Borkmann's avatar
      netlink: use jhash as hashfn for rhashtable · 7f19fc5e
      Daniel Borkmann authored
      For netlink, we shouldn't be using arch_fast_hash() as a hashing
      discipline, but rather jhash() instead.
      
      Since netlink sockets can be opened by any user, a local attacker
      would be able to easily create collisions with the DPDK-derived
      arch_fast_hash(), which trades off performance for security by
      using crc32 CPU instructions on x86_64.
      
      While it might have a legimite use case in other places, it should
      be avoided in netlink context, though. As rhashtable's API is very
      flexible, we could later on still decide on other hashing disciplines,
      if legitimate.
      
      Reference: http://thread.gmane.org/gmane.linux.kernel/1844123
      Fixes: e341694e
      
       ("netlink: Convert netlink_lookup() to use RCU protected hash table")
      Cc: Herbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarDaniel Borkmann <dborkman@redhat.com>
      Acked-by: default avatarThomas Graf <tgraf@suug.ch>
      Acked-by: default avatarHannes Frederic Sowa <hannes@stressinduktion.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      7f19fc5e
    • Richard Alpe's avatar
      tipc: fix broadcast wakeup contention after congestion · 340b6e59
      Richard Alpe authored
      commit 908344cd
      
       ("tipc: fix bug in multicast congestion handling")
      introduced a race in the broadcast link wakeup functionality.
      
      This patch eliminates this broadcast link wakeup race caused by
      operation on the wakeup list without proper locking. If this race
      hit and corrupted the list all subsequent wakeup messages would be
      lost, resulting in a considerable memory leak.
      Signed-off-by: default avatarRichard Alpe <richard.alpe@ericsson.com>
      Signed-off-by: default avatarErik Hugne <erik.hugne@ericsson.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      340b6e59
    • Alexander Duyck's avatar
      net: Pull out core bits of __netdev_alloc_skb and add __napi_alloc_skb · fd11a83d
      Alexander Duyck authored
      
      
      This change pulls the core functionality out of __netdev_alloc_skb and
      places them in a new function named __alloc_rx_skb.  The reason for doing
      this is to make these bits accessible to a new function __napi_alloc_skb.
      In addition __alloc_rx_skb now has a new flags value that is used to
      determine which page frag pool to allocate from.  If the SKB_ALLOC_NAPI
      flag is set then the NAPI pool is used.  The advantage of this is that we
      do not have to use local_irq_save/restore when accessing the NAPI pool from
      NAPI context.
      
      In my test setup I saw at least 11ns of savings using the napi_alloc_skb
      function versus the netdev_alloc_skb function, most of this being due to
      the fact that we didn't have to call local_irq_save/restore.
      
      The main use case for napi_alloc_skb would be for things such as copybreak
      or page fragment based receive paths where an skb is allocated after the
      data has been received instead of before.
      Signed-off-by: default avatarAlexander Duyck <alexander.h.duyck@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      fd11a83d
    • Alexander Duyck's avatar
      net: Split netdev_alloc_frag into __alloc_page_frag and add __napi_alloc_frag · ffde7328
      Alexander Duyck authored
      This patch splits the netdev_alloc_frag function up so that it can be used
      on one of two page frag pools instead of being fixed on the
      netdev_alloc_cache.  By doing this we can add a NAPI specific function
      __napi_alloc_frag that accesses a pool that is only used from softirq
      context.  The advantage to this is that we do not need to call
      local_irq_save/restore which can be a significant savings.
      
      I also took the opportunity to refactor the core bits that were placed in
      __alloc_page_frag.  First I updated the allocation to do either a 32K
      allocation or an order 0 page.  This is based on the changes in commmit
      d9b2938a
      
       where it was found that latencies could be reduced in case of
      failures.  Then I also rewrote the logic to work from the end of the page to
      the start.  By doing this the size value doesn't have to be used unless we
      have run out of space for page fragments.  Finally I cleaned up the atomic
      bits so that we just do an atomic_sub_and_test and if that returns true then
      we set the page->_count via an atomic_set.  This way we can remove the extra
      conditional for the atomic_read since it would have led to an atomic_inc in
      the case of success anyway.
      Signed-off-by: default avatarAlexander Duyck <alexander.h.duyck@redhat.com>
      Acked-by: default avatarAlexei Starovoitov <ast@plumgrid.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ffde7328
  5. 09 Dec, 2014 17 commits