1. 21 Nov, 2014 32 commits
  2. 20 Nov, 2014 3 commits
    • David S. Miller's avatar
      Merge branch 'bonding_4ad' · abd40774
      David S. Miller authored
      Xie Jianhua says:
      
      ====================
      bonding: Introduce 4 AD link speed
      
      The speed field of AD Port Key was based on bitmask, it supported 5
      kinds of link speed at most, as there were only 5 bits in the speed
      field of the AD Port Key.  This patches series change the speed type
      (AD_LINK_SPEED_BITMASK) from bitmask to enum type in order to enhance
      speed type from 5 to 32, and then introduce 4 AD link speed to fix
      agg_bandwidth.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      abd40774
    • Jianhua Xie's avatar
      bonding: Introduce 4 AD link speed to fix agg_bandwidth · 424c3232
      Jianhua Xie authored
      This patch adds [2.5|20|40|56] Gbps enum definition, and fixes
      aggregated bandwidth calculation based on above slave links.
      
      CC: Jay Vosburgh <j.vosburgh@gmail.com>
      CC: Veaceslav Falico <vfalico@gmail.com>
      CC: Andy Gospodarek <andy@greyhouse.net>
      CC: David S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarJianhua Xie <jianhua.xie@freescale.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      424c3232
    • Jianhua Xie's avatar
      bonding: change AD_LINK_SPEED_BITMASK to enum to suport more speed · cb8dda90
      Jianhua Xie authored
      Port Key was determined as 16 bits according to the link speed,
      duplex and user key (which is yet not supported).  In the old
      speed field, 5 bits are for speed [1|10|100|1000|10000]Mbps as
      below:
      --------------------------------------------------------------
      Port key :| User key        | Speed         |       Duplex|
      --------------------------------------------------------------
          16                  6               1               0
      This patch keeps the old layout, but changes AD_LINK_SPEED_BITMASK
      from bit type to an enum type.  In this way, the speed field can
      expand speed type from 5 to 32.
      
      CC: Jay Vosburgh <j.vosburgh@gmail.com>
      CC: Veaceslav Falico <vfalico@gmail.com>
      CC: Andy Gospodarek <andy@greyhouse.net>
      CC: David S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarJianhua Xie <jianhua.xie@freescale.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      cb8dda90
  3. 19 Nov, 2014 5 commits
    • Al Viro's avatar
      bury skb_copy_to_page() · 232365f6
      Al Viro authored
      no callers since 3.0
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      232365f6
    • Al Viro's avatar
      fold verify_iovec() into copy_msghdr_from_user() · 08adb7da
      Al Viro authored
      ... and do the same on the compat side of things.
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      08adb7da
    • Al Viro's avatar
      {compat_,}verify_iovec(): switch to generic copying of iovecs · 08449320
      Al Viro authored
      use {compat_,}rw_copy_check_uvector().  As the result, we are
      guaranteed that all iovecs seen in ->msg_iov by ->sendmsg()
      and ->recvmsg() will pass access_ok().
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      08449320
    • Al Viro's avatar
      separate kernel- and userland-side msghdr · 666547ff
      Al Viro authored
      Kernel-side struct msghdr is (currently) using the same layout as
      userland one, but it's not a one-to-one copy - even without considering
      32bit compat issues, we have msg_iov, msg_name and msg_control copied
      to kernel[1].  It's fairly localized, so we get away with a few functions
      where that knowledge is needed (and we could shrink that set even
      more).  Pretty much everything deals with the kernel-side variant and
      the few places that want userland one just use a bunch of force-casts
      to paper over the differences.
      
      The thing is, kernel-side definition of struct msghdr is *not* exposed
      in include/uapi - libc doesn't see it, etc.  So we can add struct user_msghdr,
      with proper annotations and let the few places that ever deal with those
      beasts use it for userland pointers.  Saner typechecking aside, that will
      allow to change the layout of kernel-side msghdr - e.g. replace
      msg_iov/msg_iovlen there with struct iov_iter, getting rid of the need
      to modify the iovec as we copy data to/from it, etc.
      
      We could introduce kernel_msghdr instead, but that would create much more
      noise - the absolute majority of the instances would need to have the
      type switched to kernel_msghdr and definition of struct msghdr in
      include/linux/socket.h is not going to be seen by userland anyway.
      
      This commit just introduces user_msghdr and switches the few places that
      are dealing with userland-side msghdr to it.
      
      [1] actually, it's even trickier than that - we copy msg_control for
      sendmsg, but keep the userland address on recvmsg.
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      666547ff
    • Alexei Starovoitov's avatar
      bpf: fix arraymap NULL deref and missing overflow and zero size checks · daaf427c
      Alexei Starovoitov authored
      - fix NULL pointer dereference:
      kernel/bpf/arraymap.c:41 array_map_alloc() error: potential null dereference 'array'.  (kzalloc returns null)
      kernel/bpf/arraymap.c:41 array_map_alloc() error: we previously assumed 'array' could be null (see line 40)
      
      - integer overflow check was missing in arraymap
      (hashmap checks for overflow via kmalloc_array())
      
      - arraymap can round_up(value_size, 8) to zero. check was missing.
      
      - hashmap was missing zero size check as well, since roundup_pow_of_two() can
      truncate into zero
      
      - found a typo in the arraymap comment and unnecessary empty line
      
      Fix all of these issues and make both overflow checks explicit U32 in size.
      Reported-by: default avatarkbuild test robot <fengguang.wu@intel.com>
      Signed-off-by: default avatarAlexei Starovoitov <ast@plumgrid.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      daaf427c