Re: [PATCH net-next v5] bridge: multicast to unicast
On 21/01/17 21:01, Linus Lüssing wrote: > From: Felix Fietkau > > Implements an optional, per bridge port flag and feature to deliver > multicast packets to any host on the according port via unicast > individually. This is done by copying the packet per host and > changing the multicast destination MAC to a unicast one accordingly. > > multicast-to-unicast works on top of the multicast snooping feature of > the bridge. Which means unicast copies are only delivered to hosts which > are interested in it and signalized this via IGMP/MLD reports > previously. > > This feature is intended for interface types which have a more reliable > and/or efficient way to deliver unicast packets than broadcast ones > (e.g. wifi). > > However, it should only be enabled on interfaces where no IGMPv2/MLDv1 > report suppression takes place. This feature is disabled by default. > > The initial patch and idea is from Felix Fietkau. > > Signed-off-by: Felix Fietkau > [linus.luess...@c0d3.blue: various bug + style fixes, commit message] > Signed-off-by: Linus Lüssing > > --- > > This feature is used and enabled by default in OpenWRT and LEDE for AP > interfaces for more than a year now to allow both a more robust multicast > delivery and multicast at higher rates (e.g. multicast streaming). > > In OpenWRT/LEDE the IGMP/MLD report suppression issue is overcome by > the network daemon enabling AP isolation and by that separating all STAs. > Delivery of STA-to-STA IP mulitcast is made possible again by > enabling and utilizing the bridge hairpin mode, which considers the > incoming port as a potential outgoing port, too. > > Hairpin-mode is performed after multicast snooping, therefore leading to > only deliver reports to STAs running a multicast router. > > Changes in v5: > * fix a potential pagefault in br_ip6_multicast_mld2_report(): > -> a pskb_may_pull() might reallocate skb->data, therefore perform > the "src = eth_hdr(skb)->h_source" only afterwards > * simplify code by always adding ether source address to a port group > and checking the per-port multicast-to-unicast flag instead of a > per-port-group one (thanks Stephen!) > > Changes in v4: > * readd "From: Felix Fietkau [...]" (missed it again in v3) > > Changes in v3: > * fix an uninitialized variable bug introduced in br_multicast_flood() > in v2, found by kbuild test bot > > Changes in v2: > * netlink support (thanks Nik!) > * fixed switching between multicast_to_unicast on/off > -> even after toggling an already existing entry would > stale in its mode and would never be replaced > -> new extra check in br_port_group_equal) > * reduced checks in br_multicast_flood() from two to one > to address fast-path concerns (thanks Nik!) > * rev-christmas tree ordering (thanks Nik!) > * removed "net_bridge_port_group::unicast", using > ::flags instead (thanks Nik!) > * BR_MULTICAST_TO_UCAST -> BR_MULTICAST_TO_UNICAST > (BR_MULTICAST_FLAST_LEAVE has the same length anyway) > * simplified maybe_deliver_addr() > (no return, no "prev" paramater -> was a NOP anyway) > * added "From: Felix Fietkau [...]" > * added "Signed-off-by: Felix Fietkau [...]" > --- > include/linux/if_bridge.h| 1 + > include/uapi/linux/if_link.h | 1 + > net/bridge/br_forward.c | 39 ++- > net/bridge/br_mdb.c | 2 +- > net/bridge/br_multicast.c| 90 > > net/bridge/br_netlink.c | 5 +++ > net/bridge/br_private.h | 3 +- > net/bridge/br_sysfs_if.c | 2 + > 8 files changed, 114 insertions(+), 29 deletions(-) > Reviewed-by: Nikolay Aleksandrov
[PATCH net-next v5] bridge: multicast to unicast
From: Felix Fietkau
Implements an optional, per bridge port flag and feature to deliver
multicast packets to any host on the according port via unicast
individually. This is done by copying the packet per host and
changing the multicast destination MAC to a unicast one accordingly.
multicast-to-unicast works on top of the multicast snooping feature of
the bridge. Which means unicast copies are only delivered to hosts which
are interested in it and signalized this via IGMP/MLD reports
previously.
This feature is intended for interface types which have a more reliable
and/or efficient way to deliver unicast packets than broadcast ones
(e.g. wifi).
However, it should only be enabled on interfaces where no IGMPv2/MLDv1
report suppression takes place. This feature is disabled by default.
The initial patch and idea is from Felix Fietkau.
Signed-off-by: Felix Fietkau
[linus.luess...@c0d3.blue: various bug + style fixes, commit message]
Signed-off-by: Linus Lüssing
---
This feature is used and enabled by default in OpenWRT and LEDE for AP
interfaces for more than a year now to allow both a more robust multicast
delivery and multicast at higher rates (e.g. multicast streaming).
In OpenWRT/LEDE the IGMP/MLD report suppression issue is overcome by
the network daemon enabling AP isolation and by that separating all STAs.
Delivery of STA-to-STA IP mulitcast is made possible again by
enabling and utilizing the bridge hairpin mode, which considers the
incoming port as a potential outgoing port, too.
Hairpin-mode is performed after multicast snooping, therefore leading to
only deliver reports to STAs running a multicast router.
Changes in v5:
* fix a potential pagefault in br_ip6_multicast_mld2_report():
-> a pskb_may_pull() might reallocate skb->data, therefore perform
the "src = eth_hdr(skb)->h_source" only afterwards
* simplify code by always adding ether source address to a port group
and checking the per-port multicast-to-unicast flag instead of a
per-port-group one (thanks Stephen!)
Changes in v4:
* readd "From: Felix Fietkau [...]" (missed it again in v3)
Changes in v3:
* fix an uninitialized variable bug introduced in br_multicast_flood()
in v2, found by kbuild test bot
Changes in v2:
* netlink support (thanks Nik!)
* fixed switching between multicast_to_unicast on/off
-> even after toggling an already existing entry would
stale in its mode and would never be replaced
-> new extra check in br_port_group_equal)
* reduced checks in br_multicast_flood() from two to one
to address fast-path concerns (thanks Nik!)
* rev-christmas tree ordering (thanks Nik!)
* removed "net_bridge_port_group::unicast", using
::flags instead (thanks Nik!)
* BR_MULTICAST_TO_UCAST -> BR_MULTICAST_TO_UNICAST
(BR_MULTICAST_FLAST_LEAVE has the same length anyway)
* simplified maybe_deliver_addr()
(no return, no "prev" paramater -> was a NOP anyway)
* added "From: Felix Fietkau [...]"
* added "Signed-off-by: Felix Fietkau [...]"
---
include/linux/if_bridge.h| 1 +
include/uapi/linux/if_link.h | 1 +
net/bridge/br_forward.c | 39 ++-
net/bridge/br_mdb.c | 2 +-
net/bridge/br_multicast.c| 90
net/bridge/br_netlink.c | 5 +++
net/bridge/br_private.h | 3 +-
net/bridge/br_sysfs_if.c | 2 +
8 files changed, 114 insertions(+), 29 deletions(-)
diff --git a/include/linux/if_bridge.h b/include/linux/if_bridge.h
index c6587c0..debc9d5 100644
--- a/include/linux/if_bridge.h
+++ b/include/linux/if_bridge.h
@@ -46,6 +46,7 @@ struct br_ip_list {
#define BR_LEARNING_SYNC BIT(9)
#define BR_PROXYARP_WIFI BIT(10)
#define BR_MCAST_FLOOD BIT(11)
+#define BR_MULTICAST_TO_UNICASTBIT(12)
#define BR_DEFAULT_AGEING_TIME (300 * HZ)
diff --git a/include/uapi/linux/if_link.h b/include/uapi/linux/if_link.h
index 6b13e59..4e59565 100644
--- a/include/uapi/linux/if_link.h
+++ b/include/uapi/linux/if_link.h
@@ -321,6 +321,7 @@ enum {
IFLA_BRPORT_MULTICAST_ROUTER,
IFLA_BRPORT_PAD,
IFLA_BRPORT_MCAST_FLOOD,
+ IFLA_BRPORT_MCAST_TO_UCAST,
__IFLA_BRPORT_MAX
};
#define IFLA_BRPORT_MAX (__IFLA_BRPORT_MAX - 1)
diff --git a/net/bridge/br_forward.c b/net/bridge/br_forward.c
index 7cb41ae..a0f9d00 100644
--- a/net/bridge/br_forward.c
+++ b/net/bridge/br_forward.c
@@ -174,6 +174,31 @@ static struct net_bridge_port *maybe_deliver(
return p;
}
+static void maybe_deliver_addr(struct net_bridge_port *p, struct sk_buff *skb,
+ const unsigned char *addr, bool local_orig)
+{
+ struct net_device *dev = BR_INPUT_SKB_CB(skb)->brdev;
+ const unsigned char *src = eth_hdr(skb)->h_source;
+
+ if (!should_deliver(p, skb))
+ return;
+
+ /* Even with hairpin, no soliloquies - prevent breaking IPv6 DAD */
+ if (skb->dev == p->dev && ether_addr_equal(src, addr))
+ return;
+
+ skb =
Hello your urgent response is needed!
Hello, how are you doing? I want to inform you that, we have an inheritance of a deceased client with your surname. Reply via email:andbail11.bai...@yandex.com with your full names for info. Contact Andrew Bailey -- Correo Corporativo Hospital Universitario del Valle E.S.E *** "Estamos re-dimensionandonos para crecer!" **
Re: iwlwifi: fix kernel crash when unregistering thermal zone
Jens Axboe wrote: > A recent firmware change seems to have enabled thermal zones on the > iwlwifi driver. Unfortunately, my device fails when registering the > thermal zone. This doesn't stop the driver from attempting to unregister > the thermal zone at unload time, triggering a NULL pointer deference in > strlen() off the thermal_zone_device_unregister() path. > > Don't unregister if name is NULL, for that case we failed registering. > Do the same for the cooling zone. > > Signed-off-by: Jens Axboe Patch applied to wireless-drivers.git, thanks. 92549cdc288f iwlwifi: fix kernel crash when unregistering thermal zone -- https://patchwork.kernel.org/patch/9522187/ Documentation about submitting wireless patches and checking status from patchwork: https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: iwlwifi: fix kernel crash when unregistering thermal zone
"Coelho, Luciano" writes: > On Jan 21, 2017 09:56, Kalle Valo wrote: > Jens Axboe writes: >> > A recent firmware change seems to have enabled thermal zones on the >> > iwlwifi driver. Unfortunately, my device fails when registering the >> > thermal zone. This doesn't stop the driver from attempting to unregister >> > the thermal zone at unload time, triggering a NULL pointer deference in >> > strlen() off the thermal_zone_device_unregister() path. >> > >> > Don't unregister if name is NULL, for that case we failed registering. >> > Do the same for the cooling zone. >> > >> > Signed-off-by: Jens Axboe >> > >> > --- >> > >> > Would be great if this could go into the current series, as sometimes I >> > have to reload the driver. Right now I can't, since it crashes... >> >> Luca, can I take this directly to wireless-drivers? This is an important >> fix and we should get it to Linus' tree ASAP. > > Yes, please go ahead and take it directly. > > Acked-by: Luca Coelho Thanks, I'll apply it soon. -- Kalle Valo
Re: iwlwifi: fix kernel crash when unregistering thermal zone
(resending, sorry for the HTML version my phone decided to use for this) On Jan 21, 2017 09:56, Kalle Valo wrote: Jens Axboe writes: > > A recent firmware change seems to have enabled thermal zones on the > > iwlwifi driver. Unfortunately, my device fails when registering the > > thermal zone. This doesn't stop the driver from attempting to unregister > > the thermal zone at unload time, triggering a NULL pointer deference in > > strlen() off the thermal_zone_device_unregister() path. > > > > Don't unregister if name is NULL, for that case we failed registering. > > Do the same for the cooling zone. > > > > Signed-off-by: Jens Axboe > > > > --- > > > > Would be great if this could go into the current series, as sometimes I > > have to reload the driver. Right now I can't, since it crashes... > > Luca, can I take this directly to wireless-drivers? This is an important > fix and we should get it to Linus' tree ASAP. Yes, please go ahead and take it directly. Acked-by: Luca Coelho Thanks! -- Cheers, Luca.
