- 24 Mar, 2015 40 commits
-
-
Michal Sekletar authored
If vlan offloading takes place then vlan header is removed from frame and its contents, both vlan_tci and vlan_proto, is available to user space via TPACKET interface. However, only vlan_tci can be used in BPF filters. This commit introduces a new BPF extension. It makes possible to load the value of vlan_proto (vlan TPID) to register A. Support for classic BPF and eBPF is being added, analogous to skb->protocol. Cc: Daniel Borkmann <daniel@iogearbox.net> Cc: Alexei Starovoitov <ast@plumgrid.com> Cc: Jiri Pirko <jpirko@redhat.com> Signed-off-by:
Michal Sekletar <msekleta@redhat.com> Acked-by:
Daniel Borkmann <daniel@iogearbox.net> Acked-by:
Alexei Starovoitov <ast@plumgrid.com> Reviewed-by:
Jiri Pirko <jiri@resnulli.us> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Varun Prakash says: ==================== FCoE support in cxgb4 driver This patch series enables FCoE support in cxgb4 driver, it enables FCOE_CRC and FCOE_MTU net device features. This series is created against net-next tree. ==================== Signed-off-by: -
Varun Prakash authored
Signed-off-by:
Varun Prakash <varun@chelsio.com> Signed-off-by:
-
Varun Prakash authored
This patch adds cxgb4_fcoe.c and enables FCOE_CRC, FCOE_MTU net device features. Signed-off-by:
-
Varun Prakash authored
This patch adds new header file cxgb4_fcoe.h and defines new macros for FCoE support in cxgb4 driver. Signed-off-by:
-
Hannes Frederic Sowa authored
Those warnings reported by sparse endianness check (via kbuild test robot) are harmless, nevertheless fix them up and make the code a little bit easier to read. Reported-by:
kbuild test robot <fengguang.wu@intel.com> Fixes: 622c81d5 ("ipv6: generation of stable privacy addresses for link-local and autoconf") Signed-off-by:
Hannes Frederic Sowa <hannes@stressinduktion.org> Signed-off-by:
-
Ying Xue authored
When IPV6=m and TIPC=y, below error will appear during building kernel image: net/tipc/udp_media.c:196: undefined reference to `ip6_dst_lookup' make: *** [vmlinux] Error 1 As ip6_dst_lookup() is implemented in IPV6 and IPV6 is compiled as module, ip6_dst_lookup() is not built-in core kernel image. As a result, compiler cannot find 'ip6_dst_lookup' reference while compiling TIPC code into core kernel image. But with the method introduced by commit 5f81bd2e ("ipv6: export a stub for IPv6 symbols used by vxlan"), we can avoid the compile error through "ipv6_stub" pointer to access ip6_dst_lookup(). Fixes: d0f91938 ("tipc: add ip/udp media type") Suggested-by:
Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> Signed-off-by:
Ying Xue <ying.xue@windriver.com> Signed-off-by:
-
WANG Cong authored
With dev group, we can change a batch of net devices, so we should allow to delete them together too. Group 0 is not allowed to be deleted since it is the default group. Cc: Stephen Hemminger <stephen@networkplumber.org> Signed-off-by:
Cong Wang <xiyou.wangcong@gmail.com> Signed-off-by:
-
Herbert Xu authored
This patch adds a comment on the choice of the value 16 as the maximum chain length before we force a rehash. Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
-
Wu Fengguang authored
drivers/net/usb/cx82310_eth.c:175:2-3: Unneeded semicolon Removes unneeded semicolon. Generated by: scripts/coccinelle/misc/semicolon.cocci CC: Ondrej Zary <linux@rainbow-software.org> Signed-off-by:
-
Sasha Levin authored
Commit f2f8036e ("tipc: add support for connect() on dgram/rdm sockets") hasn't validated user input length for the sockaddr structure which allows a user to overwrite kernel memory with arbitrary input. Fixes: f2f8036e ("tipc: add support for connect() on dgram/rdm sockets") Signed-off-by:
Sasha Levin <sasha.levin@oracle.com> Acked-by:
-
Hannes Frederic Sowa authored
Cc: John Fastabend <john.r.fastabend@intel.com> Signed-off-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/davem/netDavid S. Miller authored
Conflicts: net/netfilter/nf_tables_core.c The nf_tables_core.c conflict was resolved using a conflict resolution from Stephen Rothwell as a guide. Signed-off-by: -
Herbert Xu authored
The commit 963ecbd4 ("rhashtable: Fix use-after-free in rhashtable_walk_stop") fixed a real bug but created another one because we may end up sleeping inside an RCU critical section. This patch fixes it properly by replacing the mutex with a spin lock that specifically protects the walker lists. Reported-by:
-
David S. Miller authored
Hannes Frederic Sowa says: ==================== ipv6: RFC7217 stable privacy addresses implementation this is an implementation of basic support for RFC7217 stable privacy addresses. Please review and consider for net-next. v2: * Correct references to RFC 7212 -> RFC 7217 in documentation patch (thanks, Eric!) ==================== Signed-off-by: -
Hannes Frederic Sowa authored
Cc: Erik Kline <ek@google.com> Cc: Fernando Gont <fgont@si6networks.com> Cc: Lorenzo Colitti <lorenzo@google.com> Cc: YOSHIFUJI Hideaki/吉藤英明 <hideaki.yoshifuji@miraclelinux.com> Signed-off-by:
-
Hannes Frederic Sowa authored
This is specified by RFC 7217. Cc: Erik Kline <ek@google.com> Cc: Fernando Gont <fgont@si6networks.com> Cc: Lorenzo Colitti <lorenzo@google.com> Cc: YOSHIFUJI Hideaki/吉藤英明 <hideaki.yoshifuji@miraclelinux.com> Signed-off-by:
-
Hannes Frederic Sowa authored
If a DAD conflict is detected, we want to retry privacy stable address generation up to idgen_retries (= 3) times with a delay of idgen_delay (= 1 second). Add the logic to addrconf_dad_failure. By design, we don't clean up dad failed permanent addresses. Cc: Erik Kline <ek@google.com> Cc: Fernando Gont <fgont@si6networks.com> Cc: Lorenzo Colitti <lorenzo@google.com> Cc: YOSHIFUJI Hideaki/吉藤英明 <hideaki.yoshifuji@miraclelinux.com> Signed-off-by:
-
Hannes Frederic Sowa authored
Cc: Erik Kline <ek@google.com> Cc: Fernando Gont <fgont@si6networks.com> Cc: Lorenzo Colitti <lorenzo@google.com> Cc: YOSHIFUJI Hideaki/吉藤英明 <hideaki.yoshifuji@miraclelinux.com> Signed-off-by:
-
Hannes Frederic Sowa authored
We need to mark appropriate addresses so we can do retries in case their DAD failed. Cc: Erik Kline <ek@google.com> Cc: Fernando Gont <fgont@si6networks.com> Cc: Lorenzo Colitti <lorenzo@google.com> Cc: YOSHIFUJI Hideaki/吉藤英明 <hideaki.yoshifuji@miraclelinux.com> Signed-off-by:
-
Hannes Frederic Sowa authored
This patch implements the stable privacy address generation for link-local and autoconf addresses as specified in RFC7217. RID = F(Prefix, Net_Iface, Network_ID, DAD_Counter, secret_key) is the RID (random identifier). As the hash function F we chose one round of sha1. Prefix will be either the link-local prefix or the router advertised one. As Net_Iface we use the MAC address of the device. DAD_Counter and secret_key are implemented as specified. We don't use Network_ID, as it couples the code too closely to other subsystems. It is specified as optional in the RFC. As Net_Iface we only use the MAC address: we simply have no stable identifier in the kernel we could possibly use: because this code might run very early, we cannot depend on names, as they might be changed by user space early on during the boot process. A new address generation mode is introduced, IN6_ADDR_GEN_MODE_STABLE_PRIVACY. With iproute2 one can switch back to none or eui64 address configuration mode although the stable_secret is already set. We refuse writes to ipv6/conf/all/stable_secret but only allow ipv6/conf/default/stable_secret and the interface specific file to be written to. The default stable_secret is used as the parameter for the namespace, the interface specific can overwrite the secret, e.g. when switching a network configuration from one system to another while inheriting the secret. Cc: Erik Kline <ek@google.com> Cc: Fernando Gont <fgont@si6networks.com> Cc: Lorenzo Colitti <lorenzo@google.com> Cc: YOSHIFUJI Hideaki/吉藤英明 <hideaki.yoshifuji@miraclelinux.com> Signed-off-by:
-
Hannes Frederic Sowa authored
This patch implements the procfs logic for the stable_address knob: The secret is formatted as an ipv6 address and will be stored per interface and per namespace. We track initialized flag and return EIO errors until the secret is set. We don't inherit the secret to newly created namespaces. Cc: Erik Kline <ek@google.com> Cc: Fernando Gont <fgont@si6networks.com> Cc: Lorenzo Colitti <lorenzo@google.com> Cc: YOSHIFUJI Hideaki/吉藤英明 <hideaki.yoshifuji@miraclelinux.com> Signed-off-by:
-
Hannes Frederic Sowa authored
We need this symbol later on in ipv6.ko, thus export it via EXPORT_SYMBOL like sha_transform already is. Signed-off-by:
-
David S. Miller authored
Florian Fainelli says: ==================== net: bcmgenet: integrated GPHY power up/down This patch series implements integrated Gigabit PHY power up/down, which allows us to save close to 300mW on some designs when the Gigabit PHY is known to be unused (e.g: during bcmgenet_close or bcmgenet_suspend not doing Wake-on-LAN). Changes in v2: - drop an extra bcmgenet_ext_readl in bcmgenet_phy_power_set ==================== Signed-off-by: -
Florian Fainelli authored
In case the interface is not used, power down the integrated GPHY during suspend. Similarly to bcmgenet_open(), bcmgenet_resume() powers on the GPHY prior to any UniMAC activity. Signed-off-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
-
Florian Fainelli authored
Power up the GPHY while we are bringing-up the network interface, and conversely, upon bring down, power the GPHY down. In order to avoid creating hardware hazards, make sure that the GPHY gets powered on during bcmgenet_open() prior to the UniMAC being reset as the UniMAC may start creating activity towards the GPHY if we reverse the steps. Signed-off-by:
-
Florian Fainelli authored
Implement the GPHY power down sequence by setting all power down bits, putting the GPHY in reset, and finally cutting the 25Mhz reference clock. Signed-off-by:
-
Florian Fainelli authored
We were missing a number of extra steps and delays to power-up the GPHY, update the sequence to reflect the proper procedure here. Signed-off-by:
-
Florian Fainelli authored
In preparation for implementing the power down GPHY sequence, rename bcmgenet_ephy_power_up to illustrate that it is not EPHY specific but PHY agnostic, and add an "enable" argument. Signed-off-by:
-
Florian Fainelli authored
The CK25_DIS bit controls whether a 25Mhz clock is fed to the GPHY or not, in preparation for powering down the integrated GPHY when relevant, make sure we clear that bit. Signed-off-by:
-
Florian Fainelli authored
If bcmgenet_power_down() fails, we would want to propagate a return value from bcmgenet_wol_power_down_cfg() to know about this. Signed-off-by:
-
David S. Miller authored
Herbert Xu says: ==================== rhashtable: Multiple rehashing This series introduces multiple rehashing. Recall that the original implementation in br_multicast used two list pointers per hash node and therefore is limited to at most one rehash at a time since you need one list pointer for the old table and one for the new table. Thanks to Josh Triplett's suggestion of using a single list pointer we're no longer limited by that. So it is perfectly OK to have an arbitrary number of tables in existence at any one time. The reader and removal simply has to walk from the oldest table to the newest table in order not to miss anything. Insertion without lookup are just as easy as we simply go to the last table that we can find and add the entry there. However, insertion with uniqueness lookup is more complicated because we need to ensure that two simultaneous insertions of the same key do not both succeed. To achieve this, all insertions including those without lookups are required to obtain the bucket lock from the oldest hash table that is still alive. This is determined by having the rehasher (there is only one rehashing thread in the system) keep a pointer of where it is up to. If a bucket has already been rehashed then it is dead, i.e., there cannot be any more insertions to it, otherwise it is considered alive. This guarantees that the same key cannot be inserted in two different tables in parallel. Patch 1 is actually a bug fix for the walker. Patch 2-5 eliminates unnecessary out-of-line copies of jhash. Patch 6 makes rhashtable_shrink shrink to fit. Patch 7 introduces multiple rehashing. This means that if we decide to grow then we will grow regardless of whether the previous one has finished. However, this is still asynchronous meaning that if insertions come fast enough we may still end up with a table that is overutilised. Patch 8 adds support for GFP_ATOMIC allocations of struct bucket_table. Finally patch 9 enables immediate rehashing. This is done either when the table reaches 100% utilisation, or when the chain length exceeds 16 (the latter can be disabled on request, e.g., for nft_hash. With these patches the system should no longer have any trouble dealing with fast insertions on a small table. In the worst case you end up with a list of tables that's log N in length while the rehasher catches up. v3 restores rhashtable_shrink and fixes a number of bugs in the multiple rehashing patches (7 and 9). ==================== Signed-off-by: -
Herbert Xu authored
This patch reintroduces immediate rehash during insertion. If we find during insertion that the table is full or the chain length exceeds a set limit (currently 16 but may be disabled with insecure_elasticity) then we will force an immediate rehash. The rehash will contain an expansion if the table utilisation exceeds 75%. If this rehash fails then the insertion will fail. Otherwise the insertion will be reattempted in the new hash table. Signed-off-by:
Thomas Graf <tgraf@suug.ch> Signed-off-by:
-
Herbert Xu authored
This patch adds the ability to allocate bucket table with GFP_ATOMIC instead of GFP_KERNEL. This is needed when we perform an immediate rehash during insertion. Signed-off-by:
-
Herbert Xu authored
This patch adds the missing bits to allow multiple rehashes. The read-side as well as remove already handle this correctly. So it's only the rehasher and insertion that need modification to handle this. Note that this patch doesn't actually enable it so for now rehashing is still only performed by the worker thread. This patch also disables the explicit expand/shrink interface because the table is meant to expand and shrink automatically, and continuing to export these interfaces unnecessarily complicates the life of the rehasher since the rehash process is now composed of two parts. Signed-off-by:
-
Herbert Xu authored
This patch changes rhashtable_shrink to shrink to the smallest size possible rather than halving the table. This is needed because with multiple rehashing we will defer shrinking until all other rehashing is done, meaning that when we do shrink we may be able to shrink a lot. Signed-off-by:
-
Herbert Xu authored
This patch removes the explicit jhash value for the hashfn parameter of rhashtable. The default is now jhash so removing the setting makes no difference apart from making one less copy of jhash in the kernel. Signed-off-by:
-
Herbert Xu authored
This patch removes the explicit jhash value for the hashfn parameter of rhashtable. As the key length is a multiple of 4, this means that we will actually end up using jhash2. Signed-off-by:
-
Herbert Xu authored
Since every current rhashtable user uses jhash as their hash function, the fact that jhash is an inline function causes each user to generate a copy of its code. This function provides a solution to this problem by allowing hashfn to be unset. In which case rhashtable will automatically set it to jhash. Furthermore, if the key length is a multiple of 4, we will switch over to jhash2. Signed-off-by:
-
Herbert Xu authored
When rht_key_hashfn is called from rhashtable itself and params is equal to ht->p, there is no point in checking params.key_len and falling back to ht->p.key_len. For some reason gcc couldn't figure out that params is the same as ht->p. So let's help it by only checking params.key_len when it's a constant. Signed-off-by:
-
