Changes in Makefile

ec7328b5 - net: bridge: mst: Multiple Spanning Tree (MST) mode

Wed, 16 Mar 2022 15:08:43 +0000

net: bridge: mst: Multiple Spanning Tree (MST) modeAllow the user to switch from the current per-VLAN STP mode to an MSTmode.Up to this point, per-VLAN STP states where always isolated from eachother. This is in contrast to the MSTP standard (802.1Q-2018, Clause13.5), where VLANs are grouped into MST instances (MSTIs), and thestate is managed on a per-MSTI level, rather that at the per-VLANlevel.Perhaps due to the prevalence of the standard, many switching ASICsare built after the same model. Therefore, add a corresponding MSTmode to the bridge, which we can later add offloading support for in astraight-forward way.For now, all VLANs are fixed to MSTI 0, also called the CommonSpanning Tree (CST). That is, all VLANs will follow the port-globalstate.Upcoming changes will make this actually useful by allowing VLANs tobe mapped to arbitrary MSTIs and allow individual MSTI states to bechanged.Signed-off-by: Tobias Waldekranz Acked-by: Nikolay Aleksandrov Signed-off-by: Jakub Kicinski List of files: /linux-6.15/net/bridge/Makefile

5b163288 - net: bridge: multicast: add EHT host handling functions

Wed, 20 Jan 2021 14:51:55 +0000

net: bridge: multicast: add EHT host handling functionsAdd functions to create, destroy and lookup an EHT host. These areper-host entries contained in the eht_host_tree in net_bridge_port_groupwhich are used to store a list of all sources (S,G) entries joined for thatgroup by each host, the host's current filter mode and total number ofjoined entries.No functional changes yet, these would be used in later patches.Signed-off-by: Nikolay Aleksandrov Signed-off-by: Jakub Kicinski List of files: /linux-6.15/net/bridge/Makefile

2be665c3 - bridge: cfm: Netlink SET configuration Interface.

Tue, 27 Oct 2020 10:02:48 +0000

bridge: cfm: Netlink SET configuration Interface.This is the implementation of CFM netlink configurationset information interface.Add new nested netlink attributes. These attributes are used by theuser space to create/delete/configure CFM instances.SETLINK: IFLA_BRIDGE_CFM: Indicate that the following attributes are CFM. IFLA_BRIDGE_CFM_MEP_CREATE: This indicate that a MEP instance must be created. IFLA_BRIDGE_CFM_MEP_DELETE: This indicate that a MEP instance must be deleted. IFLA_BRIDGE_CFM_MEP_CONFIG: This indicate that a MEP instance must be configured. IFLA_BRIDGE_CFM_CC_CONFIG: This indicate that a MEP instance Continuity Check (CC) functionality must be configured. IFLA_BRIDGE_CFM_CC_PEER_MEP_ADD: This indicate that a CC Peer MEP must be added. IFLA_BRIDGE_CFM_CC_PEER_MEP_REMOVE: This indicate that a CC Peer MEP must be removed. IFLA_BRIDGE_CFM_CC_CCM_TX: This indicate that the CC transmitted CCM PDU must be configured. IFLA_BRIDGE_CFM_CC_RDI: This indicate that the CC transmitted CCM PDU RDI must be configured.CFM nested attribute has the following attributes in next level.SETLINK RTEXT_FILTER_CFM_CONFIG: IFLA_BRIDGE_CFM_MEP_CREATE_INSTANCE: The created MEP instance number. The type is u32. IFLA_BRIDGE_CFM_MEP_CREATE_DOMAIN: The created MEP domain. The type is u32 (br_cfm_domain). It must be BR_CFM_PORT. This means that CFM frames are transmitted and received directly on the port - untagged. Not in a VLAN. IFLA_BRIDGE_CFM_MEP_CREATE_DIRECTION: The created MEP direction. The type is u32 (br_cfm_mep_direction). It must be BR_CFM_MEP_DIRECTION_DOWN. This means that CFM frames are transmitted and received on the port. Not in the bridge. IFLA_BRIDGE_CFM_MEP_CREATE_IFINDEX: The created MEP residence port ifindex. The type is u32 (ifindex). IFLA_BRIDGE_CFM_MEP_DELETE_INSTANCE: The deleted MEP instance number. The type is u32. IFLA_BRIDGE_CFM_MEP_CONFIG_INSTANCE: The configured MEP instance number. The type is u32. IFLA_BRIDGE_CFM_MEP_CONFIG_UNICAST_MAC: The configured MEP unicast MAC address. The type is 6*u8 (array). This is used as SMAC in all transmitted CFM frames. IFLA_BRIDGE_CFM_MEP_CONFIG_MDLEVEL: The configured MEP unicast MD level. The type is u32. It must be in the range 1-7. No CFM frames are passing through this MEP on lower levels. IFLA_BRIDGE_CFM_MEP_CONFIG_MEPID: The configured MEP ID. The type is u32. It must be in the range 0-0x1FFF. This MEP ID is inserted in any transmitted CCM frame. IFLA_BRIDGE_CFM_CC_CONFIG_INSTANCE: The configured MEP instance number. The type is u32. IFLA_BRIDGE_CFM_CC_CONFIG_ENABLE: The Continuity Check (CC) functionality is enabled or disabled. The type is u32 (bool). IFLA_BRIDGE_CFM_CC_CONFIG_EXP_INTERVAL: The CC expected receive interval of CCM frames. The type is u32 (br_cfm_ccm_interval). This is also the transmission interval of CCM frames when enabled. IFLA_BRIDGE_CFM_CC_CONFIG_EXP_MAID: The CC expected receive MAID in CCM frames. The type is CFM_MAID_LENGTH*u8. This is MAID is also inserted in transmitted CCM frames. IFLA_BRIDGE_CFM_CC_PEER_MEP_INSTANCE: The configured MEP instance number. The type is u32. IFLA_BRIDGE_CFM_CC_PEER_MEPID: The CC Peer MEP ID added. The type is u32. When a Peer MEP ID is added and CC is enabled it is expected to receive CCM frames from that Peer MEP. IFLA_BRIDGE_CFM_CC_RDI_INSTANCE: The configured MEP instance number. The type is u32. IFLA_BRIDGE_CFM_CC_RDI_RDI: The RDI that is inserted in transmitted CCM PDU. The type is u32 (bool). IFLA_BRIDGE_CFM_CC_CCM_TX_INSTANCE: The configured MEP instance number. The type is u32. IFLA_BRIDGE_CFM_CC_CCM_TX_DMAC: The transmitted CCM frame destination MAC address. The type is 6*u8 (array). This is used as DMAC in all transmitted CFM frames. IFLA_BRIDGE_CFM_CC_CCM_TX_SEQ_NO_UPDATE: The transmitted CCM frame update (increment) of sequence number is enabled or disabled. The type is u32 (bool). IFLA_BRIDGE_CFM_CC_CCM_TX_PERIOD: The period of time where CCM frame are transmitted. The type is u32. The time is given in seconds. SETLINK IFLA_BRIDGE_CFM_CC_CCM_TX must be done before timeout to keep transmission alive. When period is zero any ongoing CCM frame transmission will be stopped. IFLA_BRIDGE_CFM_CC_CCM_TX_IF_TLV: The transmitted CCM frame update with Interface Status TLV is enabled or disabled. The type is u32 (bool). IFLA_BRIDGE_CFM_CC_CCM_TX_IF_TLV_VALUE: The transmitted Interface Status TLV value field. The type is u8. IFLA_BRIDGE_CFM_CC_CCM_TX_PORT_TLV: The transmitted CCM frame update with Port Status TLV is enabled or disabled. The type is u32 (bool). IFLA_BRIDGE_CFM_CC_CCM_TX_PORT_TLV_VALUE: The transmitted Port Status TLV value field. The type is u8.Signed-off-by: Henrik Bjoernlund Reviewed-by: Horatiu Vultur Acked-by: Nikolay Aleksandrov Signed-off-by: Jakub Kicinski List of files: /linux-6.15/net/bridge/Makefile

86a14b79 - bridge: cfm: Kernel space implementation of CFM. MEP create/delete.

Tue, 27 Oct 2020 10:02:45 +0000

bridge: cfm: Kernel space implementation of CFM. MEP create/delete.This is the first commit of the implementation of the CFM protocolaccording to 802.1Q section 12.14.It contains MEP instance create, delete and configuration.Connectivity Fault Management (CFM) comprises capabilities fordetecting, verifying, and isolating connectivity failures inVirtual Bridged Networks. These capabilities can be used innetworks operated by multiple independent organizations, eachwith restricted management access to each others equipment.CFM functions are partitioned as follows: - Path discovery - Fault detection - Fault verification and isolation - Fault notification - Fault recoveryInterface consists of these functions:br_cfm_mep_create()br_cfm_mep_delete()br_cfm_mep_config_set()br_cfm_cc_config_set()br_cfm_cc_peer_mep_add()br_cfm_cc_peer_mep_remove()A MEP instance is created by br_cfm_mep_create() -It is the Maintenance association End Point described in 802.1Q section 19.2. -It is created on a specific level (1-7) and is assuring that no CFM frames are passing through this MEP on lower levels. -It initiates and validates CFM frames on its level. -It can only exist on a port that is related to a bridge. -Attributes given cannot be changed until the instance is deleted.A MEP instance can be deleted by br_cfm_mep_delete().A created MEP instance has attributes that can beconfigured by br_cfm_mep_config_set().A MEP Continuity Check feature can be configured bybr_cfm_cc_config_set() The Continuity Check Receiver state machine can be enabled and disabled. According to 802.1Q section 19.2.8A MEP can have Peer MEPs added and removed bybr_cfm_cc_peer_mep_add() and br_cfm_cc_peer_mep_remove() The Continuity Check feature can maintain connectivity status on each added Peer MEP.Signed-off-by: Henrik Bjoernlund Reviewed-by: Horatiu Vultur Acked-by: Nikolay Aleksandrov Signed-off-by: Jakub Kicinski List of files: /linux-6.15/net/bridge/Makefile

9a9f26e8 - bridge: mrp: Connect MRP API with the switchdev API

Sun, 26 Apr 2020 13:22:05 +0000

bridge: mrp: Connect MRP API with the switchdev APIImplement the MRP API.In case the HW can't generate MRP Test frames then the SW will try to generatethe frames. In case that also the SW will fail in generating the frames then aerror is return to the userspace. The userspace is responsible to generate allthe other MRP frames regardless if the test frames are generated by HW or SW.The forwarding/termination of MRP frames is happening in the kernel and is doneby the MRP instance. The userspace application doesn't do the forwarding.Signed-off-by: Horatiu Vultur Signed-off-by: David S. Miller List of files: /linux-6.15/net/bridge/Makefile

fadd4091 - bridge: switchdev: mrp: Implement MRP API for switchdev

Sun, 26 Apr 2020 13:22:04 +0000

bridge: switchdev: mrp: Implement MRP API for switchdevImplement the MRP api for switchdev.These functions will just eventually call the switchdev functions:switchdev_port_obj_add/del and switchdev_port_attr_set.Signed-off-by: Horatiu Vultur Signed-off-by: David S. Miller List of files: /linux-6.15/net/bridge/Makefile

7a53e718 - net: bridge: vlan: add basic option dumping support

Fri, 24 Jan 2020 11:40:20 +0000

net: bridge: vlan: add basic option dumping supportWe'll be dumping the options for the whole range if they're equal. Thefirst range vlan will be used to extract the options. The commit doesn'tchange anything yet it just adds the skeleton for the support. The dumpwill happen when the first option is added.Signed-off-by: Nikolay Aleksandrov Signed-off-by: David S. Miller List of files: /linux-6.15/net/bridge/Makefile

b2441318 - License cleanup: add SPDX GPL-2.0 license identifier to files with no license

Wed, 01 Nov 2017 14:07:57 +0000

License cleanup: add SPDX GPL-2.0 license identifier to files with no licenseMany source files in the tree are missing licensing information, whichmakes it harder for compliance tools to determine the correct license.By default all files without license information are under the defaultlicense of the kernel, which is GPL version 2.Update the files which contain no license information with the 'GPL-2.0'SPDX license identifier. The SPDX identifier is a legally bindingshorthand, which can be used instead of the full boiler plate text.This patch is based on work done by Thomas Gleixner and Kate Stewart andPhilippe Ombredanne.How this work was done:Patches were generated and checked against linux-4.14-rc6 for a subset ofthe use cases: - file had no licensing information it it. - file was a */uapi/* one with no licensing information in it, - file was a */uapi/* one with existing licensing information,Further patches will be generated in subsequent months to fix up caseswhere non-standard license headers were used, and references to licensehad to be inferred by heuristics based on keywords.The analysis to determine which SPDX License Identifier to be applied toa file was done in a spreadsheet of side by side results from of theoutput of two independent scanners (ScanCode & Windriver) producing SPDXtag:value files created by Philippe Ombredanne. Philippe prepared thebase worksheet, and did an initial spot review of a few 1000 files.The 4.13 kernel was the starting point of the analysis with 60,537 filesassessed. Kate Stewart did a file by file comparison of the scannerresults in the spreadsheet to determine which SPDX license identifier(s)to be applied to the file. She confirmed any determination that was notimmediately clear with lawyers working with the Linux Foundation.Criteria used to select files for SPDX license identifier tagging was: - Files considered eligible had to be source code files. - Make and config files were included as candidates if they contained >5 lines of source - File already had some variant of a license header in it (even if <5 lines).All documentation files were explicitly excluded.The following heuristics were used to determine which SPDX licenseidentifiers to apply. - when both scanners couldn't find any license traces, file was considered to have no license information in it, and the top level COPYING file license applied. For non */uapi/* files that summary was: SPDX license identifier # files ---------------------------------------------------|------- GPL-2.0 11139 and resulted in the first patch in this series. If that file was a */uapi/* path one, it was "GPL-2.0 WITH Linux-syscall-note" otherwise it was "GPL-2.0". Results of that was: SPDX license identifier # files ---------------------------------------------------|------- GPL-2.0 WITH Linux-syscall-note 930 and resulted in the second patch in this series. - if a file had some form of licensing information in it, and was one of the */uapi/* ones, it was denoted with the Linux-syscall-note if any GPL family license was found in the file or had no licensing in it (per prior point). Results summary: SPDX license identifier # files ---------------------------------------------------|------ GPL-2.0 WITH Linux-syscall-note 270 GPL-2.0+ WITH Linux-syscall-note 169 ((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause) 21 ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause) 17 LGPL-2.1+ WITH Linux-syscall-note 15 GPL-1.0+ WITH Linux-syscall-note 14 ((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause) 5 LGPL-2.0+ WITH Linux-syscall-note 4 LGPL-2.1 WITH Linux-syscall-note 3 ((GPL-2.0 WITH Linux-syscall-note) OR MIT) 3 ((GPL-2.0 WITH Linux-syscall-note) AND MIT) 1 and that resulted in the third patch in this series. - when the two scanners agreed on the detected license(s), that became the concluded license(s). - when there was disagreement between the two scanners (one detected a license but the other didn't, or they both detected different licenses) a manual inspection of the file occurred. - In most cases a manual inspection of the information in the file resulted in a clear resolution of the license that should apply (and which scanner probably needed to revisit its heuristics). - When it was not immediately clear, the license identifier was confirmed with lawyers working with the Linux Foundation. - If there was any question as to the appropriate license identifier, the file was flagged for further research and to be revisited later in time.In total, over 70 hours of logged manual review was done on thespreadsheet to determine the SPDX license identifiers to apply to thesource files by Kate, Philippe, Thomas and, in some cases, confirmationby lawyers working with the Linux Foundation.Kate also obtained a third independent scan of the 4.13 code base fromFOSSology, and compared selected files where the other two scannersdisagreed against that SPDX file, to see if there was new insights. TheWindriver scanner is based on an older version of FOSSology in part, sothey are related.Thomas did random spot checks in about 500 files from the spreadsheetsfor the uapi headers and agreed with SPDX license identifier in thefiles he inspected. For the non-uapi files Thomas did random spot checksin about 15000 files.In initial set of patches against 4.14-rc6, 3 files were found to havecopy/paste license identifier errors, and have been fixed to reflect thecorrect identifier.Additionally Philippe spent 10 hours this week doing a detailed manualinspection and review of the 12,461 patched files from the initial patchversion early this week with: - a full scancode scan run, collecting the matched texts, detected license ids and scores - reviewing anything where there was a license detected (about 500+ files) to ensure that the applied SPDX license was correct - reviewing anything where there was no detection but the patch license was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied SPDX license was correctThis produced a worksheet with 20 files needing minor correction. Thisworksheet was then exported into 3 different .csv files for thedifferent types of files to be modified.These .csv files were then reviewed by Greg. Thomas wrote a script toparse the csv files and add the proper SPDX tag to the file, in theformat that the file expected. This script was further refined by Gregbased on the output to detect more types of files automatically and todistinguish between header and source .c files (which need differentcomment types.) Finally Greg ran the script using the .csv files togenerate the patches.Reviewed-by: Kate Stewart Reviewed-by: Philippe Ombredanne Reviewed-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman List of files: /linux-6.15/net/bridge/Makefile

821f1b21 - bridge: add new BR_NEIGH_SUPPRESS port flag to suppress arp and nd flood

Sat, 07 Oct 2017 05:12:37 +0000

bridge: add new BR_NEIGH_SUPPRESS port flag to suppress arp and nd floodThis patch adds a new bridge port flag BR_NEIGH_SUPPRESS tosuppress arp and nd flood on bridge ports. It implementsrfc7432, section 10.https://tools.ietf.org/html/rfc7432#section-10for ethernet VPN deployments. It is similar to the existingBR_PROXYARP* flags but has a few semantic differences to conformto EVPN standard. Unlike the existing flags, this new flag suppressesflood of all neigh discovery packets (arp and nd) to tunnel ports.Supports both vlan filtering and non-vlan filtering bridges.In case of EVPN, it is mainly used to avoid floodingof arp and nd packets to tunnel ports like vxlan.This patch adds netlink and sysfs support to set this bridge portflag.Signed-off-by: Roopa Prabhu Signed-off-by: David S. Miller List of files: /linux-6.15/net/bridge/Makefile

efa5356b - bridge: per vlan dst_metadata netlink support

Wed, 01 Feb 2017 06:59:54 +0000

bridge: per vlan dst_metadata netlink supportThis patch adds support to attach per vlan tunnel info dstmetadata. This enables bridge driver to map vlan to tunnel_infoat ingress and egress. It uses the kernel dst_metadata infrastructure.The initial use case is vlan to vni bridging, but the api is genericto extend to any tunnel_info in the future: - Uapi to configure/unconfigure/dump per vlan tunnel data - netlink functions to configure vlan and tunnel_info mapping - Introduces bridge port flag BR_LWT_VLAN to enable attach/detach dst_metadata to bridged packets on ports. off by default. - changes to existing code is mainly refactor some existing vlan handling netlink code + hooks for new vlan tunnel code - I have kept the vlan tunnel code isolated in separate files. - most of the netlink vlan tunnel code is handling of vlan-tunid ranges (follows the vlan range handling code). To conserve space vlan-tunid by default are always dumped in ranges if applicable.Use case:example use for this is a vxlan bridging gateway or vtepwhich maps vlans to vn-segments (or vnis).iproute2 example (patched and pruned iproute2 output to just showrelevant fdb entries):example shows same host mac learnt on two vni's andvlan 100 maps to vni 1000, vlan 101 maps to vni 1001before (netdev per vni):$bridge fdb show | grep "00:02:00:00:00:03"00:02:00:00:00:03 dev vxlan1001 vlan 101 master bridge00:02:00:00:00:03 dev vxlan1001 dst 12.0.0.8 self00:02:00:00:00:03 dev vxlan1000 vlan 100 master bridge00:02:00:00:00:03 dev vxlan1000 dst 12.0.0.8 selfafter this patch with collect metdata in bridged mode (single netdev):$bridge fdb show | grep "00:02:00:00:00:03"00:02:00:00:00:03 dev vxlan0 vlan 101 master bridge00:02:00:00:00:03 dev vxlan0 src_vni 1001 dst 12.0.0.8 self00:02:00:00:00:03 dev vxlan0 vlan 100 master bridge00:02:00:00:00:03 dev vxlan0 src_vni 1000 dst 12.0.0.8 selfCC: Nikolay Aleksandrov Signed-off-by: Roopa Prabhu Signed-off-by: David S. Miller List of files: /linux-6.15/net/bridge/Makefile

6bc506b4 - bridge: switchdev: Add forward mark support for stacked devices

Thu, 25 Aug 2016 16:42:37 +0000

bridge: switchdev: Add forward mark support for stacked devicesswitchdev_port_fwd_mark_set() is used to set the 'offload_fwd_mark' ofport netdevs so that packets being flooded by the device won't beflooded twice.It works by assigning a unique identifier (the ifindex of the firstbridge port) to bridge ports sharing the same parent ID. This preventspackets from being flooded twice by the same switch, but will floodpackets through bridge ports belonging to a different switch.This method is problematic when stacked devices are taken into account,such as VLANs. In such cases, a physical port netdev can have upperdevices being members in two different bridges, thus requiring twodifferent 'offload_fwd_mark's to be configured on the port netdev, whichis impossible.The main problem is that packet and netdev marking is performed at thephysical netdev level, whereas flooding occurs between bridge ports,which are not necessarily port netdevs.Instead, packet and netdev marking should really be done in the bridgedriver with the switch driver only telling it which packets it alreadyforwarded. The bridge driver will mark such packets using the markassigned to the ingress bridge port and will prevent the packet frombeing forwarded through any bridge port sharing the same mark (i.e.having the same parent ID).Remove the current switchdev 'offload_fwd_mark' implementation andinstead implement the proposed method. In addition, make rocker - thesole user of the mark - use the proposed method.Signed-off-by: Ido Schimmel Signed-off-by: Jiri Pirko Signed-off-by: David S. Miller List of files: /linux-6.15/net/bridge/Makefile

230ac490 - netfilter: bridge: split ipv6 code into separated file

Tue, 16 Jun 2015 12:07:03 +0000

netfilter: bridge: split ipv6 code into separated fileResolve compilation breakage when CONFIG_IPV6 is not set by moving the IPv6code into a separated br_netfilter_ipv6.c file.Fixes: efb6de9b4ba0 ("netfilter: bridge: forward IPv6 fragmented packets")Reported-by: kbuild test robot Signed-off-by: Pablo Neira Ayuso List of files: /linux-6.15/net/bridge/Makefile

c4e70a87 - netfilter: bridge: rename br_netfilter.c to br_netfilter_hooks.c

Tue, 16 Jun 2015 11:38:26 +0000

netfilter: bridge: rename br_netfilter.c to br_netfilter_hooks.cTo prepare separation of the IPv6 code into different file.Signed-off-by: Pablo Neira Ayuso List of files: /linux-6.15/net/bridge/Makefile

57f5877c - netfilter: bridge: build br_nf_core only if required

Tue, 30 Sep 2014 08:59:18 +0000

netfilter: bridge: build br_nf_core only if requiredEric reports build failure withCONFIG_BRIDGE_NETFILTER=nWe insist to build br_nf_core.o unconditionally, but we must only do soif br_netfilter was enabled, else it fails to build due tofunctions being defined to empty stubs (and some structure membersbeing defined out).Also, BRIDGE_NETFILTER=y|m makes no sense when BRIDGE=n.Fixes: 34666d467 (netfilter: bridge: move br_netfilter out of the core)Reported-by: Eric Dumazet Signed-off-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Signed-off-by: David S. Miller List of files: /linux-6.15/net/bridge/Makefile

34666d46 - netfilter: bridge: move br_netfilter out of the core

Thu, 18 Sep 2014 09:29:03 +0000

netfilter: bridge: move br_netfilter out of the coreJesper reported that br_netfilter always registers the hooks sincethis is part of the bridge core. This harms performance for people thatdon't need this.This patch modularizes br_netfilter so it can be rmmod'ed, thus,the hooks can be unregistered. I think the bridge netfilter should havebeen a separated module since the beginning, Patrick agreed on that.Note that this is breaking compatibility for users that expect thatbridge netfilter is going to be available after explicitly 'modprobebridge' or via automatic load through brctl.However, the damage can be easily undone by modprobing br_netfilter.The bridge core also spots a message to provide a clue to people thatdidn't notice that this has been deprecated.On top of that, the plan is that nftables will not rely on this softwarelayer, but integrate the connection tracking into the bridge layer toenable stateful filtering and NAT, which is was bridge netfilter usersseem to require.This patch still keeps the fake_dst_ops in the bridge core, since thisis required by when the bridge port is initialized. So we can safelymodprobe/rmmod br_netfilter anytime.Signed-off-by: Pablo Neira Ayuso Acked-by: Florian Westphal List of files: /linux-6.15/net/bridge/Makefile

1708803e - netfilter: bridge: fix Kconfig unmet dependencies

Sun, 25 May 2014 12:48:33 +0000

netfilter: bridge: fix Kconfig unmet dependenciesBefore f5efc69 ("netfilter: nf_tables: Add meta expression key forbridge interface name"), the entire net/bridge/netfilter/ directorydepended on BRIDGE_NF_EBTABLES, ie. on ebtables. However, thatdirectory already contained the nf_tables bridge extension thatwe should allow to compile separately. In f5efc69, we tried togeneralize this by using CONFIG_BRIDGE_NETFILTER which was not a goodidea since this option already existed and it is dedicated to enablethe Netfilter bridge IP/ARP filtering.Let's try to fix this mess by:1) making net/bridge/netfilter/ dependent on the toplevel CONFIG_NETFILTER option, just like we do with the net/netfilter and net/ipv{4,6}/netfilter/ directories.2) Changing 'selects' to 'depends on' NETFILTER_XTABLES for BRIDGE_NF_EBTABLES. I believe this problem was already before f5efc69:warning: (BRIDGE_NF_EBTABLES) selects NETFILTER_XTABLES which hasunmet direct dependencies (NET && INET && NETFILTER)3) Fix ebtables/nf_tables bridge dependencies by making NF_TABLES_BRIDGE and BRIDGE_NF_EBTABLES dependent on BRIDGE and NETFILTER:warning: (NF_TABLES_BRIDGE && BRIDGE_NF_EBTABLES) selectsBRIDGE_NETFILTER which has unmet direct dependencies (NET && BRIDGE &&NETFILTER && INET && NETFILTER_ADVANCED)net/built-in.o: In function `br_parse_ip_options':br_netfilter.c:(.text+0x4a5ba): undefined reference to `ip_options_compile'br_netfilter.c:(.text+0x4a5ed): undefined reference to `ip_options_rcv_srr'net/built-in.o: In function `br_nf_pre_routing_finish':br_netfilter.c:(.text+0x4a8a4): undefined reference to `ip_route_input_noref'br_netfilter.c:(.text+0x4a987): undefined reference to `ip_route_output_flow'make: *** [vmlinux] Error 1Reported-by: Jim Davis Signed-off-by: Pablo Neira Ayuso Signed-off-by: David S. Miller List of files: /linux-6.15/net/bridge/Makefile

b1282726 - bridge: make br_device_notifier static

Wed, 21 May 2014 00:30:00 +0000

bridge: make br_device_notifier staticMerge net/bridge/br_notify.c into net/bridge/br.c,since it has only br_device_event() and br.c is small.Cc: Stephen Hemminger Cc: David S. Miller Signed-off-by: Cong Wang Signed-off-by: David S. Miller List of files: /linux-6.15/net/bridge/Makefile

f5efc696 - netfilter: nf_tables: Add meta expression key for bridge interface name

Mon, 14 Apr 2014 12:41:28 +0000

netfilter: nf_tables: Add meta expression key for bridge interface nameNFT_META_BRI_IIFNAME to get packet input bridge interface nameNFT_META_BRI_OIFNAME to get packet output bridge interface nameSuch meta key are accessible only through NFPROTO_BRIDGE family, on adedicated nft meta module: nft_meta_bridge.Suggested-by: Pablo Neira Ayuso Signed-off-by: Tomasz Bursztyka Signed-off-by: Pablo Neira Ayuso List of files: /linux-6.15/net/bridge/Makefile

243a2e63 - bridge: Add vlan filtering infrastructure

Wed, 13 Feb 2013 12:00:09 +0000

bridge: Add vlan filtering infrastructureAdds an optional infrustructure component to bridge that would allownative vlan filtering in the bridge. Each bridge port (as wellas the bridge device) now get a VLAN bitmap. Each bit in the bitmapis associated with a vlan id. This way if the bit corresponding tothe vid is set in the bitmap that the packet with vid is allowed toenter and exit the port.Write access the bitmap is protected by RTNL and read accessprotected by RCU.Vlan functionality is disabled by default.Signed-off-by: Vlad Yasevich Signed-off-by: David S. Miller List of files: /linux-6.15/net/bridge/Makefile

ee07c6e7 - bridge: export multicast database via netlink

Fri, 07 Dec 2012 00:04:48 +0000

bridge: export multicast database via netlinkV5: fix two bugs pointed out by Thomas remove seq check for now, mark it as TODOV4: remove some useless #include some coding style fixV3: drop debugging printk's update selinux perm table as wellV2: drop patch 1/2, export ifindex directly Redesign netlink attributes Improve netlink seq check Handle IPv6 addr as wellThis patch exports bridge multicast database via netlinkmessage type RTM_GETMDB. Similar to fdb, but currently bridge-specific.We may need to support modify multicast database too (RTM_{ADD,DEL}MDB).(Thanks to Thomas for patient reviews)Cc: Herbert Xu Cc: Stephen Hemminger Cc: "David S. Miller" Cc: Thomas Graf Cc: Jesper Dangaard Brouer Signed-off-by: Cong Wang Acked-by: Thomas Graf Signed-off-by: David S. Miller List of files: /linux-6.15/net/bridge/Makefile