1. 08 Dec, 2016 32 commits
  2. 07 Dec, 2016 8 commits
    • Zhang Shengju's avatar
      dummy: expend mtu range for dummy device · 25e3e84b
      Zhang Shengju authored
      After commit 61e84623 ("net: centralize net_device min/max MTU checking"),
      the mtu range for dummy device becomes [68, 1500].
      
      This patch extends it to [0, 65535].
      Signed-off-by: default avatarZhang Shengju <zhangshengju@cmss.chinamobile.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      25e3e84b
    • Zhang Shengju's avatar
      nlmon: use core MTU range checking in nlmon driver · e82621e3
      Zhang Shengju authored
      Since commit 61e84623 ("net: centralize net_device min/max MTU checking"),
      mtu range is checked at dev_set_mtu().
      
      This patch adds min_mtu for nlmon device and remove unnecessary
      ndo_change_mtu() function.
      Signed-off-by: default avatarZhang Shengju <zhangshengju@cmss.chinamobile.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e82621e3
    • Gao Feng's avatar
      driver: macvlan: Remove the rcu member of macvlan_port · a1f5315c
      Gao Feng authored
      When free macvlan_port in macvlan_port_destroy, it is safe to free
      directly because netdev_rx_handler_unregister could enforce one
      grace period.
      So it is unnecessary to use kfree_rcu for macvlan_port.
      Signed-off-by: default avatarGao Feng <fgao@ikuai8.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a1f5315c
    • Gao Feng's avatar
      driver: ipvlan: Free ipvl_port directly with kfree instead of kfree_rcu · 48140a21
      Gao Feng authored
      There are two functions which would free the ipvl_port now. The first
      is ipvlan_port_create. It frees the ipvl_port in the error handler,
      so it could kfree it directly. The second is ipvlan_port_destroy. It
      invokes netdev_rx_handler_unregister which enforces one grace period
      by synchronize_net firstly, so it also could kfree the ipvl_port
      directly and safely.
      
      So it is unnecessary to use kfree_rcu to free ipvl_port.
      Signed-off-by: default avatarGao Feng <fgao@ikuai8.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      48140a21
    • Daniel Borkmann's avatar
      bpf: fix loading of BPF_MAXINSNS sized programs · ef0915ca
      Daniel Borkmann authored
      General assumption is that single program can hold up to BPF_MAXINSNS,
      that is, 4096 number of instructions. It is the case with cBPF and
      that limit was carried over to eBPF. When recently testing digest, I
      noticed that it's actually not possible to feed 4096 instructions
      via bpf(2).
      
      The check for > BPF_MAXINSNS was added back then to bpf_check() in
      cbd35700 ("bpf: verifier (add ability to receive verification log)").
      However, 09756af4 ("bpf: expand BPF syscall with program load/unload")
      added yet another check that comes before that into bpf_prog_load(),
      but this time bails out already in case of >= BPF_MAXINSNS.
      
      Fix it up and perform the check early in bpf_prog_load(), so we can drop
      the second one in bpf_check(). It makes sense, because also a 0 insn
      program is useless and we don't want to waste any resources doing work
      up to bpf_check() point. The existing bpf(2) man page documents E2BIG
      as the official error for such cases, so just stick with it as well.
      
      Fixes: 09756af4 ("bpf: expand BPF syscall with program load/unload")
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Acked-by: default avatarAlexei Starovoitov <ast@kernel.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ef0915ca
    • Niklas Cassel's avatar
      net: stmmac: do not call phy_ethtool_ksettings_set from atomic context · 90364fea
      Niklas Cassel authored
      >From what I can tell, spin_lock(&priv->lock) is not needed, since the
      phy_ethtool_ksettings_set call is not given the priv struct.
      
      phy_start_aneg takes the phydev->lock. Calls to phy_adjust_link
      from phy_state_machine also takes the phydev->lock.
      
      [   13.718319] BUG: sleeping function called from invalid context at kernel/locking/mutex.c:97
      [   13.726717] in_atomic(): 1, irqs_disabled(): 0, pid: 1307, name: ethtool
      [   13.742115] Hardware name: Axis ARTPEC-6 Platform
      [   13.746829] [<80110568>] (unwind_backtrace) from [<8010c2bc>] (show_stack+0x18/0x1c)
      [   13.754575] [<8010c2bc>] (show_stack) from [<80433484>] (dump_stack+0x80/0xa0)
      [   13.761801] [<80433484>] (dump_stack) from [<80145428>] (___might_sleep+0x108/0x170)
      [   13.769554] [<80145428>] (___might_sleep) from [<806c9b50>] (mutex_lock+0x24/0x44)
      [   13.777128] [<806c9b50>] (mutex_lock) from [<8050cbc0>] (phy_start_aneg+0x1c/0x13c)
      [   13.784783] [<8050cbc0>] (phy_start_aneg) from [<8050d338>] (phy_ethtool_ksettings_set+0x98/0xd0)
      [   13.793656] [<8050d338>] (phy_ethtool_ksettings_set) from [<80517adc>] (stmmac_ethtool_set_link_ksettings+0xa0/0xb4)
      [   13.804184] [<80517adc>] (stmmac_ethtool_set_link_ksettings) from [<805c5138>] (ethtool_set_settings+0xd4/0x13c)
      [   13.814358] [<805c5138>] (ethtool_set_settings) from [<805c9718>] (dev_ethtool+0x13c4/0x211c)
      [   13.822882] [<805c9718>] (dev_ethtool) from [<805dc7c0>] (dev_ioctl+0x480/0x8e0)
      [   13.830291] [<805dc7c0>] (dev_ioctl) from [<80260e34>] (do_vfs_ioctl+0x94/0xa00)
      [   13.837699] [<80260e34>] (do_vfs_ioctl) from [<802617dc>] (SyS_ioctl+0x3c/0x60)
      [   13.845011] [<802617dc>] (SyS_ioctl) from [<801088bc>] (__sys_trace_return+0x0/0x10)
      Signed-off-by: default avatarNiklas Cassel <niklas.cassel@axis.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      90364fea
    • David S. Miller's avatar
      Merge branch 'ti-cpts-update-and-fixes' · 64e8de58
      David S. Miller authored
      Grygorii Strashko says:
      
      ====================
      net: ethernet: ti: cpts: update and fixes
      
      It is preparation series intended to clean up and optimize TI CPTS driver to
      facilitate further integration with other TI's SoCs like Keystone 2.
      
      Changes in v5:
      - fixed copy paste error in cpts_release
      - reworked cc.mult/shift and cc_mult initialization
      
      Changes in v4:
      - fixed build error in patch
        "net: ethernet: ti: cpts: clean up event list if event pool is empty"
      - rebased on top of net-next
      
      Changes in v3:
      - patches reordered: fixes and small updates moved first
      - added comments in code about cpts->cc_mult
      - conversation range (maxsec) limited to 10sec
      
      Changes in v2:
      - patch "net: ethernet: ti: cpts: rework initialization/deinitialization"
        was split on 4 patches
      - applied comments from Richard Cochran
      - dropped patch
        "net: ethernet: ti: cpts: add return value to tx and rx timestamp funcitons"
      - new patches added:
        "net: ethernet: ti: cpts: drop excessive writes to CTRL and INT_EN regs"
        and "clocksource: export the clocks_calc_mult_shift to use by timestamp code"
      
      Links on prev versions:
      v4: https://lkml.org/lkml/2016/12/6/496
      v3: https://www.spinics.net/lists/devicetree/msg153474.html
      v2: http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1282034.html
      v1: http://www.spinics.net/lists/linux-omap/msg131925.html
      ====================
      Acked-by: default avatarRichard Cochran <richardcochran@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      64e8de58
    • Grygorii Strashko's avatar
      net: ethernet: ti: cpts: fix overflow check period · 20138cf9
      Grygorii Strashko authored
      The CPTS drivers uses 8sec period for overflow checking with
      assumption that CPTS retclk will not exceed 500MHz. But that's not
      true on some TI platforms (Kesytone 2). As result, it is possible that
      CPTS counter will overflow more than once between two readings.
      
      Hence, fix it by selecting overflow check period dynamically as
      max_sec_before_overflow/2, where
       max_sec_before_overflow = max_counter_val / rftclk_freq.
      
      Cc: John Stultz <john.stultz@linaro.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarGrygorii Strashko <grygorii.strashko@ti.com>
      Acked-by: default avatarRichard Cochran <richardcochran@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      20138cf9