- 11 Aug, 2015 5 commits
-
-
LEROY Christophe authored
We are not interested in interrupts for partially transmitted frames, we have to clear BD_ENET_TX_INTR explicitly otherwise it may remain from a previously used descriptor. Signed-off-by:
Christophe Leroy <christophe.leroy@c-s.fr> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Eric Dumazet authored
In commit b357a364 ("inet: fix possible panic in reqsk_queue_unlink()"), I missed fact that tcp_check_req() can return the listener socket in one case, and that we must release the request socket refcount or we leak it. Tested: Following packetdrill test template shows the issue 0 socket(..., SOCK_STREAM, IPPROTO_TCP) = 3 +0 setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0 +0 bind(3, ..., ...) = 0 +0 listen(3, 1) = 0 +0 < S 0:0(0) win 2920 <mss 1460,sackOK,nop,nop> +0 > S. 0:0(0) ack 1 <mss 1460,nop,nop,sackOK> +.002 < . 1:1(0) ack 21 win 2920 +0 > R 21:21(0) Fixes: b357a364 ("inet: fix possible panic in reqsk_queue_unlink()") Signed-off-by:
Eric Dumazet <edumazet@google.com> Signed-off-by:
-
Eric Dumazet authored
reqsk_queue_destroy() and reqsk_queue_unlink() should use del_timer_sync() instead of del_timer() before calling reqsk_put(), otherwise we could free a req still used by another cpu. But before doing so, reqsk_queue_destroy() must release syn_wait_lock spinlock or risk a dead lock, as reqsk_timer_handler() might need to take this same spinlock from reqsk_queue_unlink() (called from inet_csk_reqsk_queue_drop()) Fixes: fa76ce73 ("inet: get rid of central tcp/dccp listener timer") Signed-off-by:
-
Fabio Estevam authored
If register_netdev() fails we are not propagating the error and we return success because ax_open() succeeded previously. Fix this by checking the return value of ax_open() and register_netdev() and propagate the error in case of failure. Reported-by:
RUC_Soft_Sec <zy900702@163.com> Signed-off-by:
Fabio Estevam <fabio.estevam@freescale.com> Signed-off-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nfDavid S. Miller authored
Pablo Neira Ayuso says: ==================== Netfilter fixes for net The following patchset contains five Netfilter fixes for your net tree, they are: 1) Silence a warning on falling back to vmalloc(). Since 88eab472, we can easily hit this warning message, that gets users confused. So let's get rid of it. 2) Recently when porting the template object allocation on top of kmalloc to fix the netns dependencies between x_tables and conntrack, the error checks where left unchanged. Remove IS_ERR() and check for NULL instead. Patch from Dan Carpenter. 3) Don't ignore gfp_flags in the new nf_ct_tmpl_alloc() function, from Joe Stringer. 4) Fix a crash due to NULL pointer dereference in ip6t_SYNPROXY, patch from Phil Sutter. 5) The sequence number of the Syn+ack that is sent from SYNPROXY to clients is not adjusted through our NAT infrastructure, as a result the client may ignore this TCP packet and TCP flow hangs until the client probes us. Also from Phil Sutter. ==================== Signed-off-by:
-
- 10 Aug, 2015 14 commits
-
-
David S. Miller authored
Yuval Mintz says: ==================== bnx2x: small fixes This adds 2 small fixes, one to error flows during memory release and the other to flash writes via ethtool API. ==================== Signed-off-by: -
Yuval Mintz authored
Writing each 4Kb page into flash might take up-to ~100 miliseconds, during which time management firmware cannot acces the nvram for its own uses. Firmware upgrade utility use the ethtool API to burn new flash images for the device via the ethtool API, doing so by writing several page-worth of data on each command. Such action might create problems for the management firmware, as the nvram might not be accessible for a long time. This patch changes the write implementation, releasing the nvram lock on the completion of each page, allowing the management firmware time to claim it and perform its own required actions. Signed-off-by:
Yuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by:
Ariel Elior <Ariel.Elior@qlogic.com> Signed-off-by:
-
Yuval Mintz authored
On error flows its possible to free an SKB even if it was not allocated. Signed-off-by:
-
Dan Carpenter authored
There were missing curly braces so it means we call add_debugfs_mem() unintentionally. Fixes: 3ccc6cf7 ('cxgb4: Adds support for T6 adapter') Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
Benjamin Poirier authored
After "62bccb8c net-timestamp: Make the clone operation stand-alone from phy timestamping" the hwtstamps parameter of skb_complete_tx_timestamp() may no longer be NULL. Signed-off-by:
Benjamin Poirier <bpoirier@suse.com> Cc: Alexander Duyck <alexander.h.duyck@redhat.com> Signed-off-by:
-
Florian Westphal authored
48ed7b26 ("ipv6: reject locally assigned nexthop addresses") is too strict; it rejects following corner-case: ip -6 route add default via fe80::1:2:3 dev eth1 [ where fe80::1:2:3 is assigned to a local interface, but not eth1 ] Fix this by restricting search to given device if nh is linklocal. Joint work with Hannes Frederic Sowa. Fixes: 48ed7b26 ("ipv6: reject locally assigned nexthop addresses") Signed-off-by:
Hannes Frederic Sowa <hannes@stressinduktion.org> Signed-off-by:
Florian Westphal <fw@strlen.de> Signed-off-by:
-
Daniel Borkmann authored
Linus reports the following deadlock on rtnl_mutex; triggered only once so far (extract): [12236.694209] NetworkManager D 0000000000013b80 0 1047 1 0x00000000 [12236.694218] ffff88003f902640 0000000000000000 ffffffff815d15a9 0000000000000018 [12236.694224] ffff880119538000 ffff88003f902640 ffffffff81a8ff84 00000000ffffffff [12236.694230] ffffffff81a8ff88 ffff880119c47f00 ffffffff815d133a ffffffff81a8ff80 [12236.694235] Call Trace: [12236.694250] [<ffffffff815d15a9>] ? schedule_preempt_disabled+0x9/0x10 [12236.694257] [<ffffffff815d133a>] ? schedule+0x2a/0x70 [12236.694263] [<ffffffff815d15a9>] ? schedule_preempt_disabled+0x9/0x10 [12236.694271] [<ffffffff815d2c3f>] ? __mutex_lock_slowpath+0x7f/0xf0 [12236.694280] [<ffffffff815d2cc6>] ? mutex_lock+0x16/0x30 [12236.694291] [<ffffffff814f1f90>] ? rtnetlink_rcv+0x10/0x30 [12236.694299] [<ffffffff8150ce3b>] ? netlink_unicast+0xfb/0x180 [12236.694309] [<ffffffff814f5ad3>] ? rtnl_getlink+0x113/0x190 [12236.694319] [<ffffffff814f202a>] ? rtnetlink_rcv_msg+0x7a/0x210 [12236.694331] [<ffffffff8124565c>] ? sock_has_perm+0x5c/0x70 [12236.694339] [<ffffffff814f1fb0>] ? rtnetlink_rcv+0x30/0x30 [12236.694346] [<ffffffff8150d62c>] ? netlink_rcv_skb+0x9c/0xc0 [12236.694354] [<ffffffff814f1f9f>] ? rtnetlink_rcv+0x1f/0x30 [12236.694360] [<ffffffff8150ce3b>] ? netlink_unicast+0xfb/0x180 [12236.694367] [<ffffffff8150d344>] ? netlink_sendmsg+0x484/0x5d0 [12236.694376] [<ffffffff810a236f>] ? __wake_up+0x2f/0x50 [12236.694387] [<ffffffff814cad23>] ? sock_sendmsg+0x33/0x40 [12236.694396] [<ffffffff814cb05e>] ? ___sys_sendmsg+0x22e/0x240 [12236.694405] [<ffffffff814cab75>] ? ___sys_recvmsg+0x135/0x1a0 [12236.694415] [<ffffffff811a9d12>] ? eventfd_write+0x82/0x210 [12236.694423] [<ffffffff811a0f9e>] ? fsnotify+0x32e/0x4c0 [12236.694429] [<ffffffff8108cb70>] ? wake_up_q+0x60/0x60 [12236.694434] [<ffffffff814cba09>] ? __sys_sendmsg+0x39/0x70 [12236.694440] [<ffffffff815d4797>] ? entry_SYSCALL_64_fastpath+0x12/0x6a It seems so far plausible that the recursive call into rtnetlink_rcv() looks suspicious. One way, where this could trigger is that the senders NETLINK_CB(skb).portid was wrongly 0 (which is rtnetlink socket), so the rtnl_getlink() request's answer would be sent to the kernel instead to the actual user process, thus grabbing rtnl_mutex() twice. One theory would be that netlink_autobind() triggered via netlink_sendmsg() internally overwrites the -EBUSY error to 0, but where it is wrongly originating from __netlink_insert() instead. That would reset the socket's portid to 0, which is then filled into NETLINK_CB(skb).portid later on. As commit d470e3b4 ("[NETLINK]: Fix two socket hashing bugs.") also puts it, -EBUSY should not be propagated from netlink_insert(). It looks like it's very unlikely to reproduce. We need to trigger the rhashtable_insert_rehash() handler under a situation where rehashing currently occurs (one /rare/ way would be to hit ht->elasticity limits while not filled enough to expand the hashtable, but that would rather require a specifically crafted bind() sequence with knowledge about destination slots, seems unlikely). It probably makes sense to guard __netlink_insert() in any case and remap that error. It was suggested that EOVERFLOW might be better than an already overloaded ENOMEM. Reference: http://thread.gmane.org/gmane.linux.network/372676Reported-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
Daniel Borkmann <daniel@iogearbox.net> Acked-by:
Herbert Xu <herbert@gondor.apana.org.au> Acked-by:
Thomas Graf <tgraf@suug.ch> Signed-off-by:
-
Ivan Vecera authored
The commit "e29aa339 bna: Enable Multi Buffer RX" moved packets counter increment from the beginning of the NAPI processing loop after the check for erroneous packets so they are never accounted. This counter is used to inform firmware about number of processed completions (packets). As these packets are never acked the firmware fires IRQs for them again and again. Fixes: e29aa339 ("bna: Enable Multi Buffer RX") Signed-off-by:
Ivan Vecera <ivecera@redhat.com> Acked-by:
Rasesh Mody <rasesh.mody@qlogic.com> Signed-off-by:
-
David S. Miller authored
Marcin Wojtas says: ==================== Fixes for the network driver of Marvell Armada 375 SoC This is a set of three patches that fix long-lasting problems implemented in the initial support for the Armada 375 network controller. Due to an inappropriate concept of handling the per-CPU sent packets' processing on TX path the driver numerous problems occured, such as RCU stalls. Those have been fixed, of which details you can find in the commit logs. The patches were intensively tested on top of v4.2-rc5. I'm looking forward to any comments or remarks. ==================== Signed-off-by: -
Marcin Wojtas authored
The PP2 controller is capable of per-CPU TX processing, which means there are per-CPU banked register sets and queues. Current version of the driver supports TX packet coalescing - once on given CPU sent packets amount reaches a threshold value, an IRQ occurs. However, there is a single interrupt line responsible for CPU0/1 TX and RX events (the latter is not per-CPU, the hardware does not support RSS). When the top-half executes the interrupt cause is not known. This is why in NAPI poll function, along with RX processing, IRQ cause register on both CPU's is accessed in order to determine on which of them the TX coalescing threshold might have been reached. Thus the egress processing and releasing the buffers is able to take place on the corresponding CPU. Hitherto approach lead to an illegal usage of on_each_cpu function in softirq context. The problem is solved by resigning from TX coalescing interrupts and separating egress finalization from NAPI processing. For that purpose a method of using hrtimer is introduced. In main transmit function (mvpp2_tx) buffers are released once a software coalescing threshold is reached. In case not all the data is processed a timer is set on this CPU - in its interrupt context a tasklet is scheduled in which all queues are processed. At once only one timer per-CPU can be running, which is controlled by a dedicated flag. This commit removes TX processing from NAPI polling function, disables hardware coalescing and enables hrtimer with tasklet, using new per-CPU port structure (mvpp2_port_pcpu). Signed-off-by:
Marcin Wojtas <mw@semihalf.com> Signed-off-by:
-
Marcin Wojtas authored
mvpp2 driver allows usage of per-CPU TX processing. Once the packets are prepared independetly on each CPU, the hardware enqueues the descriptors in common TX queue. After they are sent, the buffers and associated sk_buffs should be released on the corresponding CPU. This is why a special index is maintained in order to point to the right data to be released after transmission takes place. Each per-CPU TX queue comprise an array of sent sk_buffs, freed in mvpp2_txq_bufs_free function. However, the index was used there also for obtaining a descriptor (and therefore a buffer to be DMA-unmapped) from common TX queue, which was wrong, because it was not referring to the current CPU. This commit enables proper unmapping of sent data buffers by indexing them in per-CPU queues using a dedicated array for keeping their physical addresses. Signed-off-by:
-
Marcin Wojtas authored
Using spinlocks protection during one-time driver initialization is not necessary. Moreover it resulted in invalid GFP_KERNEL allocation under the lock. This commit removes redundant spinlocks from buffer manager part of mvpp2 initialization. Signed-off-by:
Alexandre Fournier <alexandre.fournier@wisp-e.com> Signed-off-by:
-
Phil Sutter authored
Upon receipt of SYNACK from the server, ipt_SYNPROXY first sends back an ACK to finish the server handshake, then calls nf_ct_seqadj_init() to initiate sequence number adjustment of forwarded packets to the client and finally sends a window update to the client to unblock it's TX queue. Since synproxy_send_client_ack() does not set synproxy_send_tcp()'s nfct parameter, no sequence number adjustment happens and the client receives the window update with incorrect sequence number. Depending on client TCP implementation, this leads to a significant delay (until a window probe is being sent). Signed-off-by:
Phil Sutter <phil@nwl.cc> Signed-off-by:
Pablo Neira Ayuso <pablo@netfilter.org>
-
Phil Sutter authored
This happens when networking namespaces are enabled. Suggested-by:
Patrick McHardy <kaber@trash.net> Signed-off-by:
-
- 07 Aug, 2015 18 commits
-
-
Carol L Soto authored
failed to configure the page size for architectures with page size different than 4K. Fixes: 938fe83c ("net/mlx5_core: New device capabilities handling") Signed-off-by:
Carol L Soto <clsoto@linux.vnet.ibm.com> Acked-by:
Amir Vadai <amirv@mellanox.com> Signed-off-by:
-
git://git.open-mesh.org/linux-mergeDavid S. Miller authored
Antonio Quartulli says: ==================== Included changes: - prevent DAT from replying on behalf of local clients and confuse L2 bridges - fix crash on double list removal of TT objects (tt_local_entry) - fix crash due to missing NULL checks - initialize bw values for new GWs objects to prevent memory leak ==================== Signed-off-by: -
David S. Miller authored
Sathya Perla says: ==================== be2net: patch set This patch set contains 2 driver fixes to a Lancer HW issue and a fix to a double free bug. Pls apply to the "net" tree. Thanks! Patch 1 now enables filters only after creating RXQs. This is done as HW issues were observed on Lancer adapters if filters (flags, mac addrs etc) are enabled *before* creating RXQs. This patch changes the driver design by enabling filters in be_open() -- instead of be_setup() -- after RXQs are created and buffers posted. Patch 2 fixes an RX stall issue that was seen on Lancer adapters when RXQs are destroyed while they are in an "out of buffer" state. This patch fixes this issue by posting 64 buffers to each RXQ before destroying them in the close path. This is done after ensuring that no more new packets are selected for transfer to the RXQs by disabling interface filters. Patch 3 protects eqo->affinity_mask variable from being freed twice and resulting in a crash. It's now freed only when EQs haven't yet been destroyed. ==================== Signed-off-by: -
Kalesh AP authored
There are paths in the driver such as an unrecoverable error (UE) detection followed by a driver unload wherein be_clear() is invoked twice. Individual data structures are reset so that they are not cleaned/freed twice. This patch does the same for eqo->affinity_mask. It is freed only if EQs haven't yet been destroyed. This fixes a possible crash when affinity_mask is freed twice. Signed-off-by:
Kalesh AP <kalesh.purayil@avagotech.com> Signed-off-by:
Sathya Perla <sathya.perla@avagotech.com> Signed-off-by:
-
Kalesh AP authored
An RX stall issue was seen on Lancer adapters, when RXQs are destroyed while they are in an "out of buffer" state. This patch fixes this issue by posting 64 buffers to each RXQ before destroying them in the close path. This is done after ensuring that no more new packets are selected for transfer to the RXQs by disabling interface filters. Signed-off-by:
-
Kalesh AP authored
HW issues were observed on Lancer adapters if IFACE filters (flags, mac addrs etc) are enabled *before* creating RXQs. This patch changes the driver design by enabling filters in be_open() -- instead of be_setup() -- after RXQs are created and buffers posted. Two new wrapper functions, be_enable_if_filters() and be_disable_if_filters() are introduced to enable/disable IFACE filters in be_open()/be_close() respectively. In be_setup() the IFACE is now created only with the RSS flag. Signed-off-by:
-
Jason Wang authored
virtio declares support for NETIF_F_FRAGLIST, but assumes that there are at most MAX_SKB_FRAGS + 2 fragments which isn't always true with a fraglist. A longer fraglist in the skb will make the call to skb_to_sgvec overflow the sg array, leading to memory corruption. Drop NETIF_F_FRAGLIST so we only get what we can handle. Cc: Michael S. Tsirkin <mst@redhat.com> Signed-off-by:
Jason Wang <jasowang@redhat.com> Acked-by:
Michael S. Tsirkin <mst@redhat.com> Signed-off-by:
-
Mathieu Olivari authored
The patch b1c17215: "stmmac: add ipq806x glue layer", leads to the following static checker warning: .../stmmac/dwmac-ipq806x.c:314 ipq806x_gmac_probe() warn: double left shift '1 << (1 << gmac->id)' The NSS_COMMON_CLK_SRC_CTRL_OFFSET macro is used once as an offset, and once as a mask, which is a bug indeed. We'll fix it by defining the offset as the real offset value and computing the mask from it when required. Tested on IPQ806x ref designs AP148 & DB149. Reported-by:
Mathieu Olivari <mathieu@codeaurora.org> Signed-off-by:
-
WingMan Kwok authored
Prior to this patch, rx buffer size for each rx queue of an interface is configurable through dts bindings. But for an interface, the first rx queue's rx buffer size is always the usual MTU size (plus usual overhead) and page size for the remaining rx queues (if they are enabled by specifying a non-zero rx queue depth dts binding of the corresponding interface). This patch removes the rx buffer size configuration capability. Signed-off-by:
WingMan Kwok <w-kwok2@ti.com> Acked-by:
Murali Karicheri <m-karicheri2@ti.com> Signed-off-by:
-
Ian Campbell authored
As well as for kernels built only for ThunderX ARCH_THUNDERX is also enabled for kernels which support multiple platforms (such as distro kernels). Thus "default ARCH_THUNDER" is inappropriate. I believe default m is equally frowned upon, so remove the line completely rather than "default m if ARCH_THUNDER". Signed-off-by:
Ian Campbell <ijc@hellion.org.uk> Cc: Sunil Goutham <sgoutham@cavium.com> Cc: Robert Richter <rric@kernel.org> Cc: Derek Chickles <derek.chickles@caviumnetworks.com> Cc: Satanand Burla <satananda.burla@caviumnetworks.com> Cc: Felix Manlunas <felix.manlunas@caviumnetworks.com> Cc: Raghu Vatsavayi <raghu.vatsavayi@caviumnetworks.com> Cc: Arnd Bergmann <arnd@arndb.de> Cc: linux-arm-kernel@lists.infradead.org Cc: netdev@vger.kernel.org Cc: linux-kernel@vger.kernel.org Signed-off-by:
-
Ivan Vecera authored
Enforcing this flag in RxConfig for the mentioned chips fixes netdev watchdog issues prepended with AMD IOMMU message(s) like: AMD-Vi: Event logged [IO_PAGE_FAULT device=01:00.0 domain=0x001d address=0x0000000000003000 flags=0x0050] Note that this flag is also set in Realtek's own driver for these chips. Signed-off-by:
Alexander Lindqvist <alexander@bitspace.se> Acked-by:
Francois Romieu <romieu@fr.zoreil.com> Signed-off-by:
-
Nikolay Aleksandrov authored
The attribute size wasn't accounted for in the get_slave_size() callback (br_port_get_slave_size) when it was introduced, so fix it now. Also add a policy entry for it in br_port_policy. Signed-off-by:
Nikolay Aleksandrov <nikolay@cumulusnetworks.com> Fixes: 842a9ae0 ("bridge: Extend Proxy ARP design to allow optional rules for Wi-Fi") Signed-off-by:
-
Nikolay Aleksandrov authored
The attribute size wasn't accounted for in the get_slave_size() callback (br_port_get_slave_size) when it was introduced, so fix it now. Also add a policy entry for it in br_port_policy. Signed-off-by:
-
David S. Miller authored
Merge tag 'wireless-drivers-for-davem-2015-08-04' of git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers Kalle Valo says: ==================== iwlwifi: * a fix for the stuck TFD queue mechanism - it was producing noisy false alarms * a fix for the NIC prepare flow that prevented the driver from being able to access the device on certain systems * a fix for the scan prority handling which allows the regular scan to run even if a scheduled scan is already running rsi: * fix firmware load DMA regression b43: * fix extpa_gain check for 2GHz rtlwifi: * fix NULL dereference when PCI driver used as an AP * add missing module parameter declaration for rtl8723be_mod_params.msi_support ==================== Signed-off-by:
-
Oleg Nesterov authored
Commit 1fbe4b46 "net: pktgen: kill the Wait for kthread_stop code in pktgen_thread_worker()" removed (in particular) the final __set_current_state(TASK_RUNNING) and I didn't notice the previous set_current_state(TASK_INTERRUPTIBLE). This triggers the warning in __might_sleep() after return. Afaics, we can simply remove both set_current_state()'s, and we could do this a long ago right after ef87979c "pktgen: better scheduler friendliness" which changed pktgen_thread_worker() to use wait_event_interruptible_timeout(). Reported-by:
Huang Ying <ying.huang@intel.com> Signed-off-by:
Oleg Nesterov <oleg@redhat.com> Signed-off-by:
-
Ross Lagerwall authored
Waking the dealloc thread before decrementing inflight_packets is racy because it means the thread may go to sleep before inflight_packets is decremented. If kthread_stop() has already been called, the dealloc thread may wait forever with nothing to wake it. Instead, wake the thread only after decrementing inflight_packets. Signed-off-by:
Ross Lagerwall <ross.lagerwall@citrix.com> Signed-off-by:
-
Herbert Xu authored
The commit 738ac1eb ("net: Clone skb before setting peeked flag") introduced a use-after-free bug in skb_recv_datagram. This is because skb_set_peeked may create a new skb and free the existing one. As it stands the caller will continue to use the old freed skb. This patch fixes it by making skb_set_peeked return the new skb (or the old one if unchanged). Fixes: 738ac1eb ("net: Clone skb before setting peeked flag") Reported-by:
Brenden Blanco <bblanco@plumgrid.com> Signed-off-by:
Konstantin Khlebnikov <khlebnikov@yandex-team.ru> Signed-off-by:
-
Lucas Stach authored
The clocks are initially active and thus the device is marked active. This still keeps the PM refcount at 0, the pm_runtime_put_autosuspend() call at the end of probe then leaves us with an invalid refcount of -1, which in turn leads to the device staying in suspended state even though netdev open had been called. Fix this by initializing the refcount to be coherent with the initial device status. Fixes: 8fff755e (net: fec: Ensure clocks are enabled while using mdio bus) Signed-off-by:
Lucas Stach <l.stach@pengutronix.de> Tested-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by:
-
- 05 Aug, 2015 1 commit
-
-
Joe Stringer authored
The flags were ignored for this function when it was introduced. Also fix the style problem in kzalloc. Fixes: 0838aa7f (netfilter: fix netns dependencies with conntrack templates) Signed-off-by:
Joe Stringer <joestringer@nicira.com> Signed-off-by:
-
- 04 Aug, 2015 2 commits
-
-
Simon Wunderlich authored
Without this initialization, gateways which actually announce up/down bandwidth of 0/0 could be added. If these nodes get purged via _batadv_purge_orig() later, the gw_node structure does not get removed since batadv_gw_node_delete() updates the gw_node with up/down bandwidth of 0/0, and the updating function then discards the change and does not free gw_node. This results in leaking the gw_node structures, which references other structures: gw_node -> orig_node -> orig_node_ifinfo -> hardif. When removing the interface later, the open reference on the hardif may cause hangs with the infamous "unregister_netdevice: waiting for mesh1 to become free. Usage count = 1" message. Signed-off-by:
Simon Wunderlich <simon@open-mesh.com> Signed-off-by:
Marek Lindner <mareklindner@neomailbox.ch> Signed-off-by:
Antonio Quartulli <antonio@meshcoding.com>
-
Marek Lindner authored
The tt_local_entry deletion performed in batadv_tt_local_remove() was neither protecting against simultaneous deletes nor checking whether the element was still part of the list before calling hlist_del_rcu(). Replacing the hlist_del_rcu() call with batadv_hash_remove() provides adequate protection via hash spinlocks as well as an is-element-still-in-hash check to avoid 'blind' hash removal. Fixes: 068ee6e2 ("batman-adv: roaming handling mechanism redesign") Reported-by: alfonsname@web.de Signed-off-by:
-
