- 14 Feb, 2013 13 commits
-
-
David S. Miller authored
Vlad Yasevich says: ==================== VLAN filtering/VLAN aware bridge Changes since v10 * Updated implemenation of ndo_fdb_del in emulex and qlogic drivers. Changes since v9: * series re-ordering so make functionality more distinct. Basic vlan filtering is patches 1-4. Support for PVID/untagged vlans is patches 5 and 6. VLAN support for FDB/MDB is patches 7-11. Patch 12 is still additional egress policy. * Slight simplification to code that extracts the VID from skb. Since we now depend on the vlan module, at the time of input skb_tci is guaranteed to be set if the packet had 8021q header. We can simply refere to it. * Changed the opaque 'parent' pointer from prior patches to a union so we can be much more explicit in our assignments. * Lots of additional testing with STP turned on. No issues were observed. Changes since v8: * Unified vlans_to_* calls into a single interface * Fixed the rest of the issues report by Michal Miroslaw * Fixed a bug where fdb entries were not created for all added vlans. Changes since v7: * Rebases on the latest net-next and removed the vlan wrapper patch from the series. * Fixed a crash in br_fdb_add/br_fdb_delete. Changes since v6: * VLANs are now stored in a VLAN bitmap per port. This allows for O(1) lookup at ingress and egress. We simply check to see if the bit associated with the vlan id is set in the map. The drawback to this approach is that it wastes some space when there is only a small number of VLANs. * In addition to the build time configuration option, VLAN filtering also has a configuration paramter in sysfs. By default the filtering is turned off and all traffic is permitted. When the filtring is turned on, we do strict matching to the filter configured. Thus, if there is no configuration, all packets are rejected. This was done to make the behavior more streight forward. Without this (and if egress policy patch is rejected), the decision for how to forward untagged traffic that was not filtered at ingress is almost impossible to make. It would not be right to deliver to every port that has PVID set as, each port may have a different PVID. * Separate egress policy bitmap patch has been isolated and is provided last in the series. This has been a more contentious piece of functionality and I wanted to isolate it so that it could easily be dropped and not block the whole series. Changes since v5: - Pulled VLAN filtering into its own file and made it a configuration options. - Made new vlan filtering option dependent on VLAN_8021Q. - Got rid of HW filter inlines and moved then vlan_core.c. (All of the above suggested by Stephen Hemminger) Changes since v4: - Pull per-port vlan data into its own structures and give it to the bridge device thus making bridge device behave like a regular port for vlan configuration. - Add a per-vlan 'untagged' bitmap that determins egress policy. If a port is part of this bitmap, traffic egresses untagged. - PVID is now used for ingress policy only. Incomming frames without VLAN tag are assigned to the PVID vlan. Egress is determined via bitmap memberships. - Allow for incremental config of a vlan. Now, PVID and untagged memberships may be set on existing vlans. They however can NOT be cleared separately. - VLAN deletion is now done via RTM_DELLINK command for PF_BRIDGE family. This cleans up the netlink interface. Changes since v3: - Re-integrated compiler problems that got left out last time. Appologies. - checkpatches.pl errors fixed Changes since v2: - Added inline functiosn to manimulate vlan hw filters and re-use in 8021q and bridge code. - Use rtnl_dereference (Michael Tsirkin) - Remove synchronize_net() call (Eric Dumazet) - Fix NULL ptr deref bug I introduced in br_ifinfo_notify. Changes since v1: - Fixed some forwarding bugs. - Add vlan to local fdb entries. New local entries are created per vlan to facilite correct forwarding to bridge interface. - Allow configuration of vlans directly on the bridge master device in addition to ports. Changes since rfc v2: - Per-port vlan bitmap is gone and is replaced with a vlan list. - Added bridge vlan list, which is referenced by each port. Entries in the birdge vlan list have port bitmap that shows which port are parts of which vlan. - Netlink API changes. - Dropped sysfs support for now. If people think this is really usefull, can add it back. - Support for native/untagged vlans. Changes since rfc v1: - Comments addressed regarding formatting and RCU usage - iocts have been removed and changed over the netlink interface. - Added support of user added ndb entries. - changed sysfs interface to export a bitmap. Also added a write interface. I am not sure how much I like it, but it made my testing easier/faster. I might change the write interface to take text instead of binary. ==================== Signed-off-by:David S. Miller <davem@davemloft.net>
-
Vlad Yasevich authored
Add an ability to configure a separate "untagged" egress policy to the VLAN information of the bridge. This superseeds PVID policy and makes PVID ingress-only. The policy is configured with a new flag and is represented as a port bitmap per vlan. Egress frames with a VLAN id in "untagged" policy bitmap would egress the port without VLAN header. Signed-off-by:
Vlad Yasevich <vyasevic@redhat.com> Signed-off-by:
-
Vlad Yasevich authored
When VLAN is added to the port, a local fdb entry for that port (the entry with the mac address of the port) is added for that VLAN. This way we can correctly determine if the traffic is for the bridge itself. If the address of the port changes, we try to change all the local fdb entries we have for that port. Signed-off-by:
-
Vlad Yasevich authored
When a user adds bridge neighbors, allow him to specify VLAN id. If the VLAN id is not specified, the neighbor will be added for VLANs currently in the ports filter list. If no VLANs are configured on the port, we use vlan 0 and only add 1 entry. Signed-off-by:
Jitendra Kalsaria <jitendra.kalsaria@qlogic.com> Signed-off-by:
-
Vlad Yasevich authored
Add vlan_id to multicasts groups so that we know which vlan each group belongs to and can correctly forward to appropriate vlan. Signed-off-by:
-
Vlad Yasevich authored
This patch adds vlan to unicast fdb entries that are created for learned addresses (not the manually configured ones). It adds vlan id into the hash mix and uses vlan as an addditional parameter for an entry match. Signed-off-by:
-
Vlad Yasevich authored
A user may designate a certain vlan as PVID. This means that any ingress frame that does not contain a vlan tag is assigned to this vlan and any forwarding decisions are made with this vlan in mind. Signed-off-by:
-
Vlad Yasevich authored
At ingress, any untagged traffic is assigned to the PVID. Any tagged traffic is filtered according to membership bitmap. At egress, if the vlan matches the PVID, the frame is sent untagged. Otherwise the frame is sent tagged. Signed-off-by:
-
Vlad Yasevich authored
Using the RTM_GETLINK dump the vlan filter list of a given bridge port. The information depends on setting the filter flag similar to how nic VF info is dumped. Signed-off-by:
-
Vlad Yasevich authored
Add a netlink interface to add and remove vlan configuration on bridge port. The interface uses the RTM_SETLINK message and encodes the vlan configuration inside the IFLA_AF_SPEC. It is possble to include multiple vlans to either add or remove in a single message. Signed-off-by:
-
Vlad Yasevich authored
When bridge forwards a frame, make sure that a frame is allowed to egress on that port. Signed-off-by:
-
Vlad Yasevich authored
When a frame arrives on a port or transmitted by the bridge, if we have VLANs configured, validate that a given VLAN is allowed to enter the bridge. Signed-off-by:
-
Vlad Yasevich authored
Adds an optional infrustructure component to bridge that would allow native vlan filtering in the bridge. Each bridge port (as well as the bridge device) now get a VLAN bitmap. Each bit in the bitmap is associated with a vlan id. This way if the bit corresponding to the vid is set in the bitmap that the packet with vid is allowed to enter and exit the port. Write access the bitmap is protected by RTNL and read access protected by RCU. Vlan functionality is disabled by default. Signed-off-by:
-
- 13 Feb, 2013 15 commits
-
-
Daniel Borkmann authored
In order to avoid any future surprises of kernel panics due to jprobes function mismatches (as e.g. fixed in 4cb9d6ea: sctp: jsctp_sf_eat_sack: fix jprobes function signature mismatch), we should check both function types during build and scream loudly if they do not match. __same_type resolves to __builtin_types_compatible_p, which is 1 in case both types are the same and 0 otherwise, qualifiers are ignored. Tested by myself. Signed-off-by:
Daniel Borkmann <dborkman@redhat.com> Signed-off-by:
-
Daniel Borkmann authored
The function jsctp_sf_eat_sack can be made static, no need to extend its visibility. Signed-off-by:
-
Rafał Miłecki authored
Some callers may want to know if PHY write succeed. Also make PHY functions static, they are not exported anywhere. Signed-off-by:
Rafał Miłecki <zajec5@gmail.com> Signed-off-by:
-
Sathya Perla authored
The current code expects that the last word (with valid bit) of an MCC compl is DMAed in one shot. This may not be the case. Remove this assertion. Signed-off-by:
Sathya Perla <sathya.perla@emulex.com> Signed-off-by:
-
Cyril Roelandt authored
cpdma_chan_destroy() on a NULL pointer is a no-op, so the NULL check in cpdma_ctlr_destroy() can safely be removed. Signed-off-by:
Cyril Roelandt <tipecaml@gmail.com> Signed-off-by:
-
Pravin B Shelar authored
Patch cef401de (net: fix possible wrong checksum generation) fixed wrong checksum calculation but it broke TSO by defining new GSO type but not a netdev feature for that type. net_gso_ok() would not allow hardware checksum/segmentation offload of such packets without the feature. Following patch fixes TSO and wrong checksum. This patch uses same logic that Eric Dumazet used. Patch introduces new flag SKBTX_SHARED_FRAG if at least one frag can be modified by the user. but SKBTX_SHARED_FRAG flag is kept in skb shared info tx_flags rather than gso_type. tx_flags is better compared to gso_type since we can have skb with shared frag without gso packet. It does not link SHARED_FRAG to GSO, So there is no need to define netdev feature for this. Signed-off-by:
Pravin B Shelar <pshelar@nicira.com> Signed-off-by:
-
David S. Miller authored
Andrey Vagin says: ==================== If a TCP socket will get live-migrated from one box to another the timestamps (which are typically ON) will get screwed up -- the new kernel will generate TS values that has nothing to do with what they were on dump. The solution is to yet again fix the kernel and put a "timestamp offset" on a socket. A socket offset is added in places where externally visible tcp timestamp option is parsed/initialized. Connections in the SYN_RECV state are not supported, global tcp_time_stamp is used for them, because repair mode doesn't support this state. In a future it can be implemented by the similar way as for TIME_WAIT sockets. For time-wait sockets offset is inhereted by a proper tcp_sock. A per-socket offset can be set only for sockets in repair mode. ==================== Signed-off-by: -
Andrey Vagin authored
A socket timestamp is a sum of the global tcp_time_stamp and a per-socket offset. A socket offset is added in places where externally visible tcp timestamp option is parsed/initialized. Connections in the SYN_RECV state are not supported, global tcp_time_stamp is used for them, because repair mode doesn't support this state. In a future it can be implemented by the similar way as for TIME_WAIT sockets. Cc: "David S. Miller" <davem@davemloft.net> Cc: Alexey Kuznetsov <kuznet@ms2.inr.ac.ru> Cc: James Morris <jmorris@namei.org> Cc: Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org> Cc: Patrick McHardy <kaber@trash.net> Cc: Eric Dumazet <edumazet@google.com> Cc: Pavel Emelyanov <xemul@parallels.com> Signed-off-by:
Andrey Vagin <avagin@openvz.org> Signed-off-by:
-
Andrey Vagin authored
A timestamp can be set, only if a socket is in the repair mode. This patch adds a new socket option TCP_TIMESTAMP, which allows to get and set current tcp times stamp. Cc: "David S. Miller" <davem@davemloft.net> Cc: Alexey Kuznetsov <kuznet@ms2.inr.ac.ru> Cc: James Morris <jmorris@namei.org> Cc: Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org> Cc: Patrick McHardy <kaber@trash.net> Cc: Eric Dumazet <edumazet@google.com> Cc: Pavel Emelyanov <xemul@parallels.com> Signed-off-by:
-
Andrey Vagin authored
This functionality is used for restoring tcp sockets. A tcp timestamp depends on how long a system has been running, so it's differ for each host. The solution is to set a per-socket offset. A per-socket offset for a TIME_WAIT socket is inherited from a proper tcp socket. tcp_request_sock doesn't have a timestamp offset, because the repair mode for them are not implemented. Cc: "David S. Miller" <davem@davemloft.net> Cc: Alexey Kuznetsov <kuznet@ms2.inr.ac.ru> Cc: James Morris <jmorris@namei.org> Cc: Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org> Cc: Patrick McHardy <kaber@trash.net> Cc: Eric Dumazet <edumazet@google.com> Cc: Pavel Emelyanov <xemul@parallels.com> Signed-off-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linuxDavid S. Miller authored
Paul Gortmaker says: ==================== Eric noticed that the handling of local u64 ethtool counters for this driver commonly found on Freescale ppc-32 boards was racy. However, before converting them over to atomic64_t, I noticed that an internal struct was being used to determine the offsets for exporting this data into the ethtool buffer, and in doing so, it assumed that the counters would always be u64. Rather than keep this implicit assumption, a simple code cleanup gets rid of the struct completely, and leaves less conversion sites. The alternative solution would have been to take advantage of the fact that the counters are all relating to error conditions, and hence make them internally u32. In doing so, we'd be assuming that U32_MAX of any particular error condition is highly unlikely. This might have made sense if any increments were in a hot path. Tested with "ethtool -S eth0" on sbc8548 board. ==================== Signed-off-by: -
Neil Horman authored
Dan Carpenter contacted me with some notes regarding some smatch warnings in the netpoll code, some of which I introduced with my recent netpoll locking fixes, some which were there prior. Specifically they were: net-next/net/core/netpoll.c:243 netpoll_poll_dev() warn: inconsistent returns mutex:&ni->dev_lock: locked (213,217) unlocked (210,243) net-next/net/core/netpoll.c:706 netpoll_neigh_reply() warn: potential pointer math issue ('skb_transport_header(send_skb)' is a 128 bit pointer) This patch corrects the locking imbalance (the first error), and adds some parenthesis to correct the second error. Tested by myself. Applies to net-next Signed-off-by:Neil Horman <nhorman@tuxdriver.com> CC: Dan Carpenter <dan.carpenter@oracle.com> CC: "David S. Miller" <davem@davemloft.net> Signed-off-by:
-
James Hogan authored
I get the following build error on next-20130213 due to the following commit: commit f05de73b ("skbuff: create skb_panic() function and its wrappers"). It adds an argument called panic to a function that uses the BUG() macro which tries to call panic, but the argument masks the panic() function declaration, resulting in the following error (gcc 4.2.4): net/core/skbuff.c In function 'skb_panic': net/core/skbuff.c +126 : error: called object 'panic' is not a function This is fixed by renaming the argument to msg. Signed-off-by:
James Hogan <james.hogan@imgtec.com> Cc: Jean Sacren <sakiwit@gmail.com> Cc: Jiri Pirko <jiri@resnulli.us> Cc: David S. Miller <davem@davemloft.net> Signed-off-by:
-
Paul Gortmaker authored
While looking at some asm dump for an unrelated change, Eric noticed in the following stats count increment code: 50b8: 81 3c 01 f8 lwz r9,504(r28) 50bc: 81 5c 01 fc lwz r10,508(r28) 50c0: 31 4a 00 01 addic r10,r10,1 50c4: 7d 29 01 94 addze r9,r9 50c8: 91 3c 01 f8 stw r9,504(r28) 50cc: 91 5c 01 fc stw r10,508(r28) that a 64 bit counter was used on ppc-32 without sync and hence the "ethtool -S" output was racy. Here we convert all the values to use atomic64_t so that the output will always be consistent. Reported-by:Eric Dumazet <edumazet@google.com> Signed-off-by:
Paul Gortmaker <paul.gortmaker@windriver.com>
-
Paul Gortmaker authored
The gfar_stats struct is only used in copying out data via ethtool. It is declared as the extra stats, followed by the rmon stats. However, the rmon stats are never actually ever used in the driver; instead the rmon data is a u32 register read that is cast directly into the ethtool buf. It seems the only reason rmon is in the struct at all is to give the offset(s) at which it should be exported into the ethtool buffer. But note gfar_stats doesn't contain a gfar_extra_stats as a substruct -- instead it contains a u64 array of equal element count. This implicitly means we have two independent declarations of what gfar_extra_stats really is. Rather than have this duality, we already have defines which give us the offset directly, and hence do not need the struct at all. Further, since we know the extra_stats is unconditionally always present, we can write it out to the ethtool buf 1st, and then optionally write out the rmon data. There is no need for two independent loops, both of which are simply copying out the extra_stats to buf offset zero. This also helps pave the way towards allowing the extra stats fields to be converted to atomic64_t values, without having their types directly influencing the ethtool stats export code (gfar_fill_stats) that expects to deal with u64. Signed-off-by:
-
- 12 Feb, 2013 12 commits
-
-
Jiri Pirko authored
Current act_police uses rate table computed by the "tc" userspace program, which has the following issue: The rate table has 256 entries to map packet lengths to token (time units). With TSO sized packets, the 256 entry granularity leads to loss/gain of rate, making the token bucket inaccurate. Thus, instead of relying on rate table, this patch explicitly computes the time and accounts for packet transmission times with nanosecond granularity. This is a followup to 56b765b7 ("htb: improved accuracy at high rates"). Signed-off-by:
Jiri Pirko <jiri@resnulli.us> Signed-off-by:
-
Jiri Pirko authored
It's not used anywhere else, so move it. Signed-off-by:
Jamal Hadi Salim <jhs@mojatatu.com> Acked-by:
-
Jiri Pirko authored
Current TBF uses rate table computed by the "tc" userspace program, which has the following issue: The rate table has 256 entries to map packet lengths to token (time units). With TSO sized packets, the 256 entry granularity leads to loss/gain of rate, making the token bucket inaccurate. Thus, instead of relying on rate table, this patch explicitly computes the time and accounts for packet transmission times with nanosecond granularity. This is a followup to 56b765b7 ("htb: improved accuracy at high rates"). Signed-off-by:
-
Jiri Pirko authored
tbf will need to schedule watchdog in ns. No need to convert it twice. Signed-off-by:
-
Jiri Pirko authored
As it is going to be used in tbf as well, push these to generic code. Signed-off-by:
-
Jiri Pirko authored
These are in ns so convert from ticks to ns. Signed-off-by:
-
Jiri Pirko authored
These are initialized correctly a couple of lines later in the function. Signed-off-by:
-
Jiri Pirko authored
Signed-off-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/davem/netDavid S. Miller authored
Conflicts: drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c The bnx2x gso_type setting bug fix in 'net' conflicted with changes in 'net-next' that broke the gso_* setting logic out into a seperate function, which also fixes the bug in question. Thus, use the 'net-next' version. Signed-off-by: -
Jiri Pirko authored
in htb_change_class() cl->buffer and cl->buffer are stored in ns. So in dump, convert them back to psched ticks. Note this was introduced by: commit 56b765b7 htb: improved accuracy at high rates Please consider this for -net/-stable. Signed-off-by:
-
Stefan Roese authored
Until now, the MPC5200 FEC ethernet driver relied upon the bootloader (U-Boot) to write the MAC address into the ethernet controller registers. The Linux driver should not rely on such a thing. So lets read the MAC address from the DT as it should be done here. The following priority is now used to read the MAC address: 1) First, try OF node MAC address, if not present or invalid, then: 2) Read from MAC address registers, if invalid, then: 3) Log a warning message, and choose a random MAC address. This fixes a problem with a MPC5200 board that uses the SPL U-Boot version without FEC initialization before Linux booting for boot speedup. Additionally a status line is now be printed upon successful driver probing, also displaying this MAC address. Signed-off-by:
Stefan Roese <sr@denx.de> Cc: Anatolij Gustschin <agust@denx.de> Signed-off-by:
-
Vipul Pandya authored
Signed-off-by:
Santosh Rastapur <santosh@chelsio.com> Signed-off-by:
Vipul Pandya <vipul@chelsio.com> Signed-off-by:
-
