user/sven/linux.git, branch v4.4.293

Linux 4.4.293

2021-11-26T10:58:45Z

Link: https://lore.kernel.org/r/20211124115658.328640564@linuxfoundation.org Tested-by: Jon Hunter Link: https://lore.kernel.org/r/20211125131156.607226770@linuxfoundation.org Link: https://lore.kernel.org/r/20211125160503.347646915@linuxfoundation.org Tested-by: Jon Hunter Tested-by: Guenter Roeck Tested-by: Pavel Machek (CIP) Signed-off-by: Greg Kroah-Hartman

usb: max-3421: Use driver data instead of maintaining a list of bound devices

2021-11-26T10:58:45Z

commit fc153aba3ef371d0d76eb88230ed4e0dee5b38f2 upstream. Instead of maintaining a single-linked list of devices that must be searched linearly in .remove() just use spi_set_drvdata() to remember the link between the spi device and the driver struct. Then the global list and the next member can be dropped. This simplifies the driver, reduces the memory footprint and the time to search the list. Also it makes obvious that there is always a corresponding driver struct for a given device in .remove(), so the error path for !max3421_hcd can be dropped, too. As a side effect this fixes a data inconsistency when .probe() races with itself for a second max3421 device in manipulating max3421_hcd_list. A similar race is fixed in .remove(), too. Fixes: 2d53139f3162 ("Add support for using a MAX3421E chip as a host driver.") Signed-off-by: Uwe Kleine-König Link: https://lore.kernel.org/r/20211018204028.2914597-1-u.kleine-koenig@pengutronix.de Signed-off-by: Greg Kroah-Hartman

ASoC: DAPM: Cover regression by kctl change notification fix

2021-11-26T10:58:45Z

commit 827b0913a9d9d07a0c3e559dbb20ca4d6d285a54 upstream. The recent fix for DAPM to correct the kctl change notification by the commit 5af82c81b2c4 ("ASoC: DAPM: Fix missing kctl change notifications") caused other regressions since it changed the behavior of snd_soc_dapm_set_pin() that is called from several API functions. Formerly it returned always 0 for success, but now it returns 0 or 1. This patch addresses it, restoring the old behavior of snd_soc_dapm_set_pin() while keeping the fix in snd_soc_dapm_put_pin_switch(). Fixes: 5af82c81b2c4 ("ASoC: DAPM: Fix missing kctl change notifications") Reported-by: Yu-Hsuan Hsu Cc: Signed-off-by: Takashi Iwai Link: https://lore.kernel.org/r/20211105090925.20575-1-tiwai@suse.de Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman

batman-adv: Avoid WARN_ON timing related checks

2021-11-26T10:58:45Z

commit 9f460ae31c4435fd022c443a6029352217a16ac1 upstream. The soft/batadv interface for a queued OGM can be changed during the time the OGM was queued for transmission and when the OGM is actually transmitted by the worker. But WARN_ON must be used to denote kernel bugs and not to print simple warnings. A warning can simply be printed using pr_warn. Reported-by: Tetsuo Handa Reported-by: syzbot+c0b807de416427ff3dd1@syzkaller.appspotmail.com Fixes: ef0a937f7a14 ("batman-adv: consider outgoing interface in OGM sending") Signed-off-by: Sven Eckelmann Signed-off-by: Simon Wunderlich [ bp: 4.4 backported: adjust context. ] Signed-off-by: Sven Eckelmann Signed-off-by: Greg Kroah-Hartman

batman-adv: Don't always reallocate the fragmentation skb head

2021-11-26T10:58:45Z

commit 992b03b88e36254e26e9a4977ab948683e21bd9f upstream. When a packet is fragmented by batman-adv, the original batman-adv header is not modified. Only a new fragmentation is inserted between the original one and the ethernet header. The code must therefore make sure that it has a writable region of this size in the skbuff head. But it is not useful to always reallocate the skbuff by this size even when there would be more than enough headroom still in the skb. The reallocation is just to costly during in this codepath. Fixes: ee75ed88879a ("batman-adv: Fragment and send skbs larger than mtu") Signed-off-by: Sven Eckelmann Signed-off-by: Simon Wunderlich [ bp: 4.4 backported: adjust context, switch back to old return type + labels ] Signed-off-by: Sven Eckelmann Signed-off-by: Greg Kroah-Hartman

batman-adv: Reserve needed_*room for fragments

2021-11-26T10:58:45Z

commit c5cbfc87558168ef4c3c27ce36eba6b83391db19 upstream. The batadv net_device is trying to propagate the needed_headroom and needed_tailroom from the lower devices. This is needed to avoid cost intensive reallocations using pskb_expand_head during the transmission. But the fragmentation code split the skb's without adding extra room at the end/beginning of the various fragments. This reduced the performance of transmissions over complex scenarios (batadv on vxlan on wireguard) because the lower devices had to perform the reallocations at least once. Fixes: ee75ed88879a ("batman-adv: Fragment and send skbs larger than mtu") Signed-off-by: Sven Eckelmann Signed-off-by: Simon Wunderlich [ bp: 4.4 backported: adjust context. ] Signed-off-by: Sven Eckelmann Signed-off-by: Greg Kroah-Hartman

batman-adv: Consider fragmentation for needed_headroom

2021-11-26T10:58:45Z

commit 4ca23e2c2074465bff55ea14221175fecdf63c5f upstream. If a batman-adv packets has to be fragmented, then the original batman-adv packet header is not stripped away. Instead, only a new header is added in front of the packet after it was split. This size must be considered to avoid cost intensive reallocations during the transmission through the various device layers. Fixes: 7bca68c7844b ("batman-adv: Add lower layer needed_(head|tail)room to own ones") Reported-by: Linus Lüssing Signed-off-by: Simon Wunderlich Signed-off-by: Sven Eckelmann Signed-off-by: Greg Kroah-Hartman

batman-adv: set .owner to THIS_MODULE

2021-11-26T10:58:45Z

commit 14a2e551faea53d45bc11629a9dac88f88950ca7 upstream. If THIS_MODULE is not set, the module would be removed while debugfs is being used. It eventually makes kernel panic. Fixes: c6c8fea29769 ("net: Add batman-adv meshing protocol") Signed-off-by: Taehee Yoo Signed-off-by: Simon Wunderlich [ bp: 4.4 backported: switch to old filename. ] Signed-off-by: Sven Eckelmann Signed-off-by: Greg Kroah-Hartman

batman-adv: mcast: fix duplicate mcast packets from BLA backbone to mesh

2021-11-26T10:58:45Z

commit 2369e827046920ef0599e6a36b975ac5c0a359c2 upstream. Scenario: * Multicast frame send from BLA backbone gateways (multiple nodes with their bat0 bridged together, with BLA enabled) sharing the same LAN to nodes in the mesh Issue: * Nodes receive the frame multiple times on bat0 from the mesh, once from each foreign BLA backbone gateway which shares the same LAN with another For multicast frames via batman-adv broadcast packets coming from the same BLA backbone but from different backbone gateways duplicates are currently detected via a CRC history of previously received packets. However this CRC so far was not performed for multicast frames received via batman-adv unicast packets. Fixing this by appyling the same check for such packets, too. Room for improvements in the future: Ideally we would introduce the possibility to not only claim a client, but a complete originator, too. This would allow us to only send a multicast-in-unicast packet from a BLA backbone gateway claiming the node and by that avoid potential redundant transmissions in the first place. Fixes: fe2da6ff27c7 ("batman-adv: add broadcast duplicate check") Signed-off-by: Linus Lüssing Signed-off-by: Simon Wunderlich [ bp: 4.4 backported: adjust context, correct fixes line, switch back to int return type ] Signed-off-by: Sven Eckelmann Signed-off-by: Greg Kroah-Hartman

batman-adv: mcast: fix duplicate mcast packets in BLA backbone from mesh

2021-11-26T10:58:45Z

commit 74c09b7275126da1b642b90c9cdc3ae8b729ad4b upstream Scenario: * Multicast frame send from mesh to a BLA backbone (multiple nodes with their bat0 bridged together, with BLA enabled) Issue: * BLA backbone nodes receive the frame multiple times on bat0, once from mesh->bat0 and once from each backbone_gw from LAN For unicast, a node will send only to the best backbone gateway according to the TQ. However for multicast we currently cannot determine if multiple destination nodes share the same backbone if they don't share the same backbone with us. So we need to keep sending the unicasts to all backbone gateways and let the backbone gateways decide which one will forward the frame. We can use the CLAIM mechanism to make this decision. One catch: The batman-adv gateway feature for DHCP packets potentially sends multicast packets in the same batman-adv unicast header as the multicast optimizations code. And we are not allowed to drop those even if we did not claim the source address of the sender, as for such packets there is only this one multicast-in-unicast packet. How can we distinguish the two cases? The gateway feature uses a batman-adv unicast 4 address header. While the multicast-to-unicasts feature uses a simple, 3 address batman-adv unicast header. So let's use this to distinguish. Fixes: 2d3f6ccc4ea5 ("batman-adv: check incoming packet type for bla") Signed-off-by: Linus Lüssing Acked-by: Simon Wunderlich [ bp: 4.4 backported: adjust context, correct fixes line ] Signed-off-by: Sven Eckelmann Signed-off-by: Greg Kroah-Hartman