Skip to content

L
linux
Switch branch/tag
  1. 07 Jun, 2016 17 commits
  3. 06 Jun, 2016 3 commits
  5. 05 Jun, 2016 1 commit
  7. 04 Jun, 2016 1 commit
  9. 03 Jun, 2016 15 commits
  11. 02 Jun, 2016 3 commits
    • Eric Dumazet's avatar
      Possible problem with e6afc8ac ("udp: remove headers from UDP packets before queueing") · ce25d66a
      Eric Dumazet authored 
      Paul Moore tracked a regression caused by a recent commit, which
mistakenly assumed that sk_filter() could be avoided if socket
had no current BPF filter.

The intent was to avoid udp_lib_checksum_complete() overhead.

But sk_filter() also checks skb_pfmemalloc() and
security_sock_rcv_skb(), so better call it.

Fixes: e6afc8ac ("udp: remove headers from UDP packets before queueing")
Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
Reported-by: default avatarPaul Moore <paul@paul-moore.com>
Tested-by: default avatarPaul Moore <paul@paul-moore.com>
Tested-by: default avatarStephen Smalley <sds@tycho.nsa.gov>
Cc: samanthakumar <samanthakumar@google.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ce25d66a
    • Vincent Palatin's avatar
      stmmac: do not sleep in atomic context for mdio_reset · f55d84b0
      Vincent Palatin authored 
      stmmac_mdio_reset() has been updated to use msleep rather udelay
(as some PHY requires a one second delay there).
It called from stmmac_resume() within the spin_lock_irqsave block
atomic context triggering 'scheduling while atomic'.

The stmmac_priv lock usage is not fully documented, but it seems
to protect the access to the MAC registers / DMA structures rather
than the MDIO bus or the PHY (which have separate locking),
so we can push the spin_lock after the stmmac_mdio_reset call.
Signed-off-by: default avatarVincent Palatin <vpalatin@chromium.org>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f55d84b0
    • Arnd Bergmann's avatar
      qed: fix qed_fill_link() error handling · 14b84e86
      Arnd Bergmann authored 
      gcc warns about qed_fill_link possibly accessing uninitialized data:

drivers/net/ethernet/qlogic/qed/qed_main.c: In function 'qed_fill_link':
drivers/net/ethernet/qlogic/qed/qed_main.c:1170:35: error: 'link_caps' may be used uninitialized in this function [-Werror=maybe-uninitialized]

While this warning is only about the specific case of CONFIG_QED_SRIOV
being disabled but the function getting called for a VF (which should
never happen), another possibility is that qed_mcp_get_*() fails without
returning data.

This rearranges the code so we bail out in either of the two cases
and print a warning instead of accessing the uninitialized data.

The qed_link_output structure remains untouched in this case, but
all callers first call memset() on it, so at least we are not leaking
stack data then.

As discussed, we also use a compile-time check to ensure we never
use any of the VF code if CONFIG_QED_SRIOV is disabled, and the
PCI device table is updated to no longer bind to virtual functions
in that configuration.
Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
Acked-by: default avatarYuval Mintz <Yuval.Mintz@qlogic.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      14b84e86
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7