1. 08 Apr, 2017 10 commits
    • Steffen Klassert's avatar
      skbuff: Extend gso_type to unsigned int. · 7f564528
      Steffen Klassert authored
      All available gso_type flags are currently in use, so
      extend gso_type from 'unsigned short' to 'unsigned int'
      to be able to add further flags.
      
      We reorder the struct skb_shared_info to use
      two bytes of the four byte hole before dataref.
      All fields before dataref are cleared, i.e.
      four bytes more than before the change.
      
      The remaining two byte hole is moved to the
      beginning of the structure, this protects us
      from immediate overwites on out of bound writes
      to the sk_buff head.
      
      Structure layout on x86-64 before the change:
      
      struct skb_shared_info {
      	unsigned char              nr_frags;             /*     0     1 */
      	__u8                       tx_flags;             /*     1     1 */
      	short unsigned int         gso_size;             /*     2     2 */
      	short unsigned int         gso_segs;             /*     4     2 */
      	short unsigned int         gso_type;             /*     6     2 */
      	struct sk_buff *           frag_list;            /*     8     8 */
      	struct skb_shared_hwtstamps hwtstamps;           /*    16     8 */
      	u32                        tskey;                /*    24     4 */
      	__be32                     ip6_frag_id;          /*    28     4 */
      	atomic_t                   dataref;              /*    32     4 */
      
      	/* XXX 4 bytes hole, try to pack */
      
      	void *                     destructor_arg;       /*    40     8 */
      	skb_frag_t                 frags[17];            /*    48   272 */
      	/* --- cacheline 5 boundary (320 bytes) --- */
      
      	/* size: 320, cachelines: 5, members: 12 */
      	/* sum members: 316, holes: 1, sum holes: 4 */
      };
      
      Structure layout on x86-64 after the change:
      
      struct skb_shared_info {
      	short unsigned int         _unused;              /*     0     2 */
      	unsigned char              nr_frags;             /*     2     1 */
      	__u8                       tx_flags;             /*     3     1 */
      	short unsigned int         gso_size;             /*     4     2 */
      	short unsigned int         gso_segs;             /*     6     2 */
      	struct sk_buff *           frag_list;            /*     8     8 */
      	struct skb_shared_hwtstamps hwtstamps;           /*    16     8 */
      	unsigned int               gso_type;             /*    24     4 */
      	u32                        tskey;                /*    28     4 */
      	__be32                     ip6_frag_id;          /*    32     4 */
      	atomic_t                   dataref;              /*    36     4 */
      	void *                     destructor_arg;       /*    40     8 */
      	skb_frag_t                 frags[17];            /*    48   272 */
      	/* --- cacheline 5 boundary (320 bytes) --- */
      
      	/* size: 320, cachelines: 5, members: 13 */
      };
      Signed-off-by: default avatarSteffen Klassert <steffen.klassert@secunet.com>
      Acked-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      7f564528
    • Felix Manlunas's avatar
      liquidio: fix VF incorrectly indicating that it successfully set its VLAN · 0c264588
      Felix Manlunas authored
      For security reasons, NIC firmware does not allow VF to set its VLAN if PF
      set it already.  Firmware allows VF to set its VLAN if PF did not set it.
      After the VF instructs the firmware to set the VLAN, VF always indicates
      (via return 0) that the operation is successful--even for the times when it
      isn't.
      
      Put in a mechanism for the VF's set VLAN function to receive the firmware
      response code, then make that function return -EPERM if the firmware
      forbids the operation.
      
      Make that mechanism available for other functions that may, in the future,
      be interested in receiving the response code from the firmware.  That
      mechanism involves adding new fields to struct octnic_ctrl_pkt, so make all
      users of struct octnic_ctrl_pkt initialize the struct to zero before using
      it; otherwise, the mechanism might act on uninitialized garbage.
      Signed-off-by: default avatarFelix Manlunas <felix.manlunas@cavium.com>
      Signed-off-by: default avatarDerek Chickles <derek.chickles@cavium.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      0c264588
    • K. Y. Srinivasan's avatar
      netvsc: Initialize all channel related state prior to opening the channel · bffb1842
      K. Y. Srinivasan authored
      Prior to opening the channel we should have all the state setup to handle
      interrupts. The current code does not do that; fix the bug. This bug
      can result in faults in the interrupt path.
      Signed-off-by: default avatarK. Y. Srinivasan <kys@microsoft.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      bffb1842
    • Florian Fainelli's avatar
      net: dsa: mv88e6xxx: Make SMI c22/c45 read/write functions static · 54a88e4c
      Florian Fainelli authored
      The SMI clause 22 & 45 read/write operations are local to the global2.c file,
      so make them static. This eliminates the following warning:
      
      drivers/net/dsa/mv88e6xxx/global2.c:571:5: warning: no previous prototype for 'mv88e6xxx_g2_smi_phy_read_c45' [-Wmissing-prototypes]
       int mv88e6xxx_g2_smi_phy_read_c45(struct mv88e6xxx_chip *chip, int addr,
           ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      drivers/net/dsa/mv88e6xxx/global2.c:602:5: warning: no previous prototype for 'mv88e6xxx_g2_smi_phy_read_c22' [-Wmissing-prototypes]
       int mv88e6xxx_g2_smi_phy_read_c22(struct mv88e6xxx_chip *chip, int addr,
           ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      drivers/net/dsa/mv88e6xxx/global2.c:635:5: warning: no previous prototype for 'mv88e6xxx_g2_smi_phy_write_c45' [-Wmissing-prototypes]
       int mv88e6xxx_g2_smi_phy_write_c45(struct mv88e6xxx_chip *chip, int addr,
           ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      drivers/net/dsa/mv88e6xxx/global2.c:664:5: warning: no previous prototype for 'mv88e6xxx_g2_smi_phy_write_c22' [-Wmissing-prototypes]
       int mv88e6xxx_g2_smi_phy_write_c22(struct mv88e6xxx_chip *chip, int addr,
           ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      Suggested-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Reviewed-by: default avatarVivien Didelot <vivien.didelot@savoirfairelinux.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      54a88e4c
    • Johannes Berg's avatar
      netlink: uapi: use hex numbers for NLM_F_* flags · 261a0a54
      Johannes Berg authored
      It's rather confusing that the netlink message flags are
      numbered 1, 2, 4, 8, 16, 32, <unused>, 0x100. Make that
      more understandable by numbering the lower ones with hex
      constants as well.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      261a0a54
    • Colin Ian King's avatar
      nfp: don't dereference a null nn->eth_port to print a warning · 1f1120a5
      Colin Ian King authored
      On the case where nn->eth_port is null the warning message
      is printing the port by dereferencing this null pointer.
      Remove the deference to avoid a crash when printing the
      warning message.
      
      Detected by CoverityScan, CID#1426198 ("Dereference after null check")
      
      Fixes: ce22f5a2 ("nfp: separate high level and low level NSP headers")
      Signed-off-by: default avatarColin Ian King <colin.king@canonical.com>
      Acked-by: default avatarJakub Kicinski <jakub.kicinski@netronome.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      1f1120a5
    • David S. Miller's avatar
      Merge branch 'net-SO_COOKIE' · 7cb164ef
      David S. Miller authored
      Chenbo Feng says:
      
      ====================
      New getsockopt option to retrieve socket cookie
      
      In the current kernel socket cookie implementation, there is no simple
      and direct way to retrieve the socket cookie based on file descriptor. A
      process mat need to get it from sock fd if it want to correlate with
      sock_diag output or use a bpf map with new socket cookie function.
      
      If userspace wants to receive the socket cookie for a given socket fd,
      it must send a SOCK_DIAG_BY_FAMILY dump request and look for the 5-tuple.
      This is slow and can be ambiguous in the case of sockets that have the
      same 5-tuple (e.g., tproxy / transparent sockets, SO_REUSEPORT sockets,
      etc.).
      
      As shown in the example program. The xt_eBPF program is using socket cookie
      to record the network traffics statistics and with the socket cookie
      retrieved by getsockopt. The program can directly access to a specific
      socket data without scanning the whole bpf map.
      ====================
      Acked-by: default avatarAlexei Starovoitov <ast@kernel.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      7cb164ef
    • Chenbo Feng's avatar
      Sample program using SO_COOKIE · 00f660ea
      Chenbo Feng authored
      Added a per socket traffic monitoring option to illustrate the usage
      of new getsockopt SO_COOKIE. The program is based on the socket traffic
      monitoring program using xt_eBPF and in the new option the data entry
      can be directly accessed using socket cookie. The cookie retrieved
      allow us to lookup an element in the eBPF for a specific socket.
      Signed-off-by: default avatarChenbo Feng <fengc@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      00f660ea
    • Chenbo Feng's avatar
      New getsockopt option to get socket cookie · 5daab9db
      Chenbo Feng authored
      Introduce a new getsockopt operation to retrieve the socket cookie
      for a specific socket based on the socket fd.  It returns a unique
      non-decreasing cookie for each socket.
      Tested: https://android-review.googlesource.com/#/c/358163/Acked-by: default avatarWillem de Bruijn <willemb@google.com>
      Signed-off-by: default avatarChenbo Feng <fengc@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      5daab9db
    • David S. Miller's avatar
      Merge tag 'mlx5-updates-2017-04-16' of git://git.kernel.org/pub/scm/linux/kernel/git/saeed/linux · c42cb98c
      David S. Miller authored
      Saeed Mahameed says:
      
      ====================
      mlx5-updates-2017-04-16
      
      This patchset provides some updates for the mlx5 drivers.
      
      From Majd,
      1st patch, Adds ConnectX-6 and ConnectX-6 VF PCI IDs support.
      
      From Guy,
      2nd patch, Adds RXFCS scatter support.
      3rd patch, Small cleanup to make a function static.
      
      From Eran,
      4th patch, Adds 4 zeros padding to ethtool FW version.
      6th patch, Trevial code reuse cleanup
      
      From Inbar,
      5th patch, Show board id in ethtool driver information
      
      From Saeed,
      7th patch, Set default RX moderation parameters on driver load
      as a small fix for the latest fail-safe config feature.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c42cb98c
  2. 07 Apr, 2017 30 commits