Skip to content
  1. Nov 22, 2014
  3. Nov 20, 2014
    • 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
    • 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