- 29 Jul, 2017 1 commit
-
-
WANG Cong authored
Historically, dev_ifsioc() uses struct sockaddr as mac address definition, this is why dev_set_mac_address() accepts a struct sockaddr pointer as input but now we have various types of mac addresse whose lengths are up to MAX_ADDR_LEN, longer than struct sockaddr, and saved in dev->addr_len. It is too late to fix dev_ifsioc() due to API compatibility, so just reject those larger than sizeof(struct sockaddr), otherwise we would read and use some random bytes from kernel stack. Fortunately, only a few IPv6 tunnel devices have addr_len larger than sizeof(struct sockaddr) and they don't support ndo_set_mac_addr(). But with team driver, in lb mode, they can still be enslaved to a team master and make its mac addr length as the same. Cc: Jiri Pirko <jiri@resnulli.us> Signed-off-by:
Cong Wang <xiyou.wangcong@gmail.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
- 28 Jul, 2017 2 commits
-
-
Arnd Bergmann authored
The driver attempts to 'select MDIO_DEVICE', but the code is actually a loadable module when PHYLIB=m: drivers/phy/broadcom/phy-bcm-ns-usb3.o: In function `bcm_ns_usb3_mdiodev_phy_write': phy-bcm-ns-usb3.c:(.text.bcm_ns_usb3_mdiodev_phy_write+0x28): undefined reference to `mdiobus_write' drivers/phy/broadcom/phy-bcm-ns-usb3.o: In function `bcm_ns_usb3_module_exit': phy-bcm-ns-usb3.c:(.exit.text+0x18): undefined reference to `mdio_driver_unregister' drivers/phy/broadcom/phy-bcm-ns-usb3.o: In function `bcm_ns_usb3_module_init': phy-bcm-ns-usb3.c:(.init.text+0x18): undefined reference to `mdio_driver_register' phy-bcm-ns-usb3.c:(.init.text+0x38): undefined reference to `mdio_driver_unregister' Using 'depends on MDIO_BUS' instead will avoid the link error. Fixes: af850e14 ("phy: bcm-ns-usb3: add MDIO driver using proper bus layer") Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Reviewed-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Arnd Bergmann authored
I still see build errors in randconfig builds and have had this patch for a while to locally work around it: drivers/built-in.o: In function `xgene_mdio_probe': mux-core.c:(.text+0x352154): undefined reference to `of_mdiobus_register' mux-core.c:(.text+0x352168): undefined reference to `mdiobus_free' mux-core.c:(.text+0x3521c0): undefined reference to `mdiobus_alloc_size' The idea is that CONFIG_MDIO_BUS now reflects whether the mdio_bus code is built-in or a module, and other drivers that use the core code can simply depend on that, instead of having a complex dependency line. Fixes: 90eff909 ("net: phy: Allow splitting MDIO bus/device support from PHYs") Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Reviewed-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
- 27 Jul, 2017 6 commits
-
-
Xin Long authored
Commit b1f5bfc2 ("sctp: don't dereference ptr before leaving _sctp_walk_{params, errors}()") tried to fix the issue that it may overstep the chunk end for _sctp_walk_{params, errors} with 'chunk_end > offset(length) + sizeof(length)'. But it introduced a side effect: When processing INIT, it verifies the chunks with 'param.v == chunk_end' after iterating all params by sctp_walk_params(). With the check 'chunk_end > offset(length) + sizeof(length)', it would return when the last param is not yet accessed. Because the last param usually is fwdtsn supported param whose size is 4 and 'chunk_end == offset(length) + sizeof(length)' This is a badly issue even causing sctp couldn't process 4-shakes. Client would always get abort when connecting to server, due to the failure of INIT chunk verification on server. The patch is to use 'chunk_end <= offset(length) + sizeof(length)' instead of 'chunk_end < offset(length) + sizeof(length)' for both _sctp_walk_params and _sctp_walk_errors. Fixes: b1f5bfc2 ("sctp: don't dereference ptr before leaving _sctp_walk_{params, errors}()") Signed-off-by:
Xin Long <lucien.xin@gmail.com> Acked-by:
Neil Horman <nhorman@tuxdriver.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Xin Long authored
In dccp_feat_init, when ccid_get_builtin_ccids failsto alloc memory for rx.val, it should free tx.val before returning an error. Signed-off-by:
Xin Long <lucien.xin@gmail.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Xin Long authored
The patch "dccp: fix a memleak that dccp_ipv6 doesn't put reqsk properly" fixed reqsk refcnt leak for dccp_ipv6. The same issue exists on dccp_ipv4. This patch is to fix it for dccp_ipv4. Signed-off-by:
Xin Long <lucien.xin@gmail.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Xin Long authored
In dccp_v6_conn_request, after reqsk gets alloced and hashed into ehash table, reqsk's refcnt is set 3. one is for req->rsk_timer, one is for hlist, and the other one is for current using. The problem is when dccp_v6_conn_request returns and finishes using reqsk, it doesn't put reqsk. This will cause reqsk refcnt leaks and reqsk obj never gets freed. Jianlin found this issue when running dccp_memleak.c in a loop, the system memory would run out. dccp_memleak.c: int s1 = socket(PF_INET6, 6, IPPROTO_IP); bind(s1, &sa1, 0x20); listen(s1, 0x9); int s2 = socket(PF_INET6, 6, IPPROTO_IP); connect(s2, &sa1, 0x20); close(s1); close(s2); This patch is to put the reqsk before dccp_v6_conn_request returns, just as what tcp_conn_request does. Reported-by:
Jianlin Shi <jishi@redhat.com> Signed-off-by:
Xin Long <lucien.xin@gmail.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Jakub Kicinski authored
The buffer passed to bpf_obj_get_info_by_fd() should be initialized to zeros. Kernel will enforce that to guarantee we can safely extend info structures in the future. Making the bpf_obj_get_info_by_fd() call in libbpf perform the zeroing is problematic, however, since some members of the info structures may need to be initialized by the callers (for instance pointers to buffers to which kernel is to dump translated and jited images). Remove the zeroing and fix up the in-tree callers before any kernel has been released with this code. As Daniel points out this seems to be the intended operation anyway, since commit 95b9afd3 ("bpf: Test for bpf ID") is itself setting the buffer pointers before calling bpf_obj_get_info_by_fd(). Signed-off-by:
Jakub Kicinski <jakub.kicinski@netronome.com> Acked-by:
Daniel Borkmann <daniel@iogearbox.net> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Matthias Kaehlcke authored
Apparently netpoll_setup() assumes that netpoll.dev_name is a pointer when checking if the device name is set: if (np->dev_name) { ... However the field is a character array, therefore the condition always yields true. Check instead whether the first byte of the array has a non-zero value. Signed-off-by:
Matthias Kaehlcke <mka@chromium.org> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
- 26 Jul, 2017 6 commits
-
-
WANG Cong authored
Commit de77ecd4 ("bonding: improve link-status update in mii-monitoring") moves link status commitment into bond_mii_monitor(), but it still relies on the return value of bond_miimon_inspect() as the hint. We need to return non-zero as long as we propose a link status change. Fixes: de77ecd4 ("bonding: improve link-status update in mii-monitoring") Reported-by:
Benjamin Gilbert <benjamin.gilbert@coreos.com> Tested-by:
Benjamin Gilbert <benjamin.gilbert@coreos.com> Cc: Mahesh Bandewar <maheshb@google.com> Signed-off-by:
Cong Wang <xiyou.wangcong@gmail.com> Acked-by:
Mahesh Bandewar <maheshb@google.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Paolo Abeni authored
We must use pre-processor conditional block or suitable accessors to manipulate skb->sp elsewhere builds lacking the CONFIG_XFRM will break. Fixes: dce4551c ("udp: preserve head state for IP_CMSG_PASSSEC") Signed-off-by:
Paolo Abeni <pabeni@redhat.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Marc Gonzalez authored
Before commit bf8f6952 ("Add blurb about RGMII") it was unclear whose responsibility it was to insert the required clock skew, and in hindsight, some PHY drivers got it wrong. The solution forward is to introduce a new property, explicitly requiring skew from the node to which it is attached. In the interim, this driver will handle all 4 RGMII modes identically (no skew). Fixes: 52dfc830 ("net: ethernet: add driver for Aurora VLSI NB8800 Ethernet controller") Signed-off-by:
Marc Gonzalez <marc_gonzalez@sigmadesigns.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
stephen hemminger authored
The logic for computing page buffer scatter does not take into account the impact of compound pages. Therefore the optimization to compute number of slots was incorrect and could cause stack corruption a skb was sent with lots of fragments from huge pages. This reverts commit 60b86665. Fixes: 60b86665 ("netvsc: optimize calculation of number of slots") Signed-off-by:
Stephen Hemminger <sthemmin@microsoft.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Joel Stanley authored
The error paths set err, but it's not returned. I wondered if we should fix all of the callers to check the returned value, but Ben explains why the code is this way: > Most call sites ignore it on purpose. There's nothing we can do if > we fail to get a buffer at interrupt time, so we point the buffer to > the scratch page so the HW doesn't DMA into lalaland and lose the > packet. > > The one call site that tests and can fail is the one used when brining > the interface up. If we fail to allocate at that point, we fail the > ifup. But as you noticed, I do have a bug not returning the error. Acked-by:
Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by:
Joel Stanley <joel@jms.id.au> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Stefano Brivio authored
RFC 2465 defines ipv6IfStatsOutFragFails as: "The number of IPv6 datagrams that have been discarded because they needed to be fragmented at this output interface but could not be." The existing implementation, instead, would increase the counter twice in case we fail to allocate room for single fragments: once for the fragment, once for the datagram. This didn't look intentional though. In one of the two affected affected failure paths, the double increase was simply a result of a new 'goto fail' statement, introduced to avoid a skb leak. The other path appears to be affected since at least 2.6.12-rc2. Reported-by:
Sabrina Dubroca <sdubroca@redhat.com> Fixes: 1d325d21 ("ipv6: ip6_fragment: fix headroom tests and skb leak") Signed-off-by:
Stefano Brivio <sbrivio@redhat.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
- 25 Jul, 2017 7 commits
-
-
Phil Sutter authored
I forgot one spot when introducing struct test_obj_val. Fixes: e859afe1 ("lib: test_rhashtable: fix for large entry counts") Reported by: kernel test robot <fengguang.wu@intel.com> Signed-off-by:
Phil Sutter <phil@nwl.cc> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Marc Gonzalez authored
Commit e5a03bfd ("phy: Add an mdio_device structure") introduced a spurious trailing semicolon. Remove it. Signed-off-by:
Marc Gonzalez <marc_gonzalez@sigmadesigns.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Paolo Abeni authored
Paul Moore reported a SELinux/IP_PASSSEC regression caused by missing skb->sp at recvmsg() time. We need to preserve the skb head state to process the IP_CMSG_PASSSEC cmsg. With this commit we avoid releasing the skb head state in the BH even if a secpath is attached to the current skb, and stores the skb status (with/without head states) in the scratch area, so that we can access it at skb deallocation time, without incurring in cache-miss penalties. This also avoids misusing the skb CB for ipv6 packets, as introduced by the commit 0ddf3fb2 ("udp: preserve skb->dst if required for IP options processing"). Clean a bit the scratch area helpers implementation, to reduce the code differences between 32 and 64 bits build. Reported-by:
Paul Moore <paul@paul-moore.com> Fixes: 0a463c78 ("udp: avoid a cache miss on dequeue") Fixes: 0ddf3fb2 ("udp: preserve skb->dst if required for IP options processing") Signed-off-by:
Paolo Abeni <pabeni@redhat.com> Tested-by:
Paul Moore <paul@paul-moore.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Florian Fainelli authored
The mt7530 driver has its dsa_switch_ops::get_tag_protocol function check ds->cpu_port_mask to issue a warning in case the configured CPU port is not capable of supporting tags. After commit 14be36c2 ("net: dsa: Initialize all CPU and enabled ports masks in dsa_ds_parse()") we slightly re-arranged the initialization such that this was no longer working. Just make sure that ds->cpu_port_mask is set prior to the first call to get_tag_protocol, thus restoring the expected contract. In case of error, the CPU port bit is cleared. Fixes: 14be36c2 ("net: dsa: Initialize all CPU and enabled ports masks in dsa_ds_parse()") Reported-by:
Sean Wang <sean.wang@mediatek.com> Signed-off-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
WANG Cong authored
There are multiple reports showing we have a use-after-free in the timer prb_retire_rx_blk_timer_expired(), where we use struct tpacket_kbdq_core::pkbdq, a pg_vec, after it gets freed by free_pg_vec(). The interesting part is it is not freed via packet_release() but via packet_setsockopt(), which means we are not closing the socket. Looking into the big and fat function packet_set_ring(), this could happen if we satisfy the following conditions: 1. closing == 0, not on packet_release() path 2. req->tp_block_nr == 0, we don't allocate a new pg_vec 3. rx_ring->pg_vec is already set as V3, which means we already called packet_set_ring() wtih req->tp_block_nr > 0 previously 4. req->tp_frame_nr == 0, pass sanity check 5. po->mapped == 0, never called mmap() In this scenario we are clearing the old rx_ring->pg_vec, so we need to free this pg_vec, but we don't stop the timer on this path because of closing==0. The timer has to be stopped as long as we need to free pg_vec, therefore the check on closing!=0 is wrong, we should check pg_vec!=NULL instead. Thanks to liujian for testing different fixes. Reported-by: alexander.levin@verizon.com Reported-by:
Dave Jones <davej@codemonkey.org.uk> Reported-by:
liujian (CE) <liujian56@huawei.com> Tested-by:
liujian (CE) <liujian56@huawei.com> Cc: Ding Tianhong <dingtianhong@huawei.com> Cc: Willem de Bruijn <willemdebruijn.kernel@gmail.com> Signed-off-by:
Cong Wang <xiyou.wangcong@gmail.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Benjamin Herrenschmidt authored
Populate mii_bus->parent with our own platform device before registering, which makes it easier to locate the MDIO bus in sysfs when trying to diagnose problems. Signed-off-by:
Benjamin Herrenschmidt <benh@kernel.crashing.org> Acked-by:
Joel Stanley <joel@jms.id.au> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Benjamin Herrenschmidt authored
We had reports of 50us not being sufficient to reset the MAC, thus hitting the "Hardware reset failed" error bringing the interface up on some AST2400 based machines. This bumps the timeout to 200us. Signed-off-by:
Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
- 24 Jul, 2017 13 commits
-
-
Liping Zhang authored
Before the 'type' is validated, we shouldn't use it to fetch the ovs_ct_attr_lens's minlen and maxlen, else, out of bound access may happen. Fixes: 7f8a436e ("openvswitch: Add conntrack action") Signed-off-by:
Liping Zhang <zlpnobody@gmail.com> Acked-by:
Pravin B Shelar <pshelar@ovn.org> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Thomas Jarosch authored
DMA transfers are not allowed to buffers that are on the stack. Therefore allocate a buffer to store the result of usb_control_message(). Fixes these bugreports: https://bugzilla.kernel.org/show_bug.cgi?id=195217 https://bugzilla.redhat.com/show_bug.cgi?id=1421387 https://bugzilla.redhat.com/show_bug.cgi?id=1427398 Shortened kernel backtrace from 4.11.9-200.fc25.x86_64: kernel: ------------[ cut here ]------------ kernel: WARNING: CPU: 3 PID: 2957 at drivers/usb/core/hcd.c:1587 kernel: transfer buffer not dma capable kernel: Call Trace: kernel: dump_stack+0x63/0x86 kernel: __warn+0xcb/0xf0 kernel: warn_slowpath_fmt+0x5a/0x80 kernel: usb_hcd_map_urb_for_dma+0x37f/0x570 kernel: ? try_to_del_timer_sync+0x53/0x80 kernel: usb_hcd_submit_urb+0x34e/0xb90 kernel: ? schedule_timeout+0x17e/0x300 kernel: ? del_timer_sync+0x50/0x50 kernel: ? __slab_free+0xa9/0x300 kernel: usb_submit_urb+0x2f4/0x560 kernel: ? urb_destroy+0x24/0x30 kernel: usb_start_wait_urb+0x6e/0x170 kernel: usb_control_msg+0xdc/0x120 kernel: mcs_get_reg+0x36/0x40 [mcs7780] kernel: mcs_net_open+0xb5/0x5c0 [mcs7780] ... Regression goes back to 4.9, so it's a good candidate for -stable. Though it's the decision of the maintainer. Thanks to Dan Williams for adding the "transfer buffer not dma capable" warning in the first place. It instantly pointed me in the right direction. Patch has been tested with transferring data from a Polar watch. Signed-off-by:
Thomas Jarosch <thomas.jarosch@intra2net.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Thor Thayer authored
The commit fbf68229 ("net: stmmac: unify registers dumps methods") in the Linux kernel modified the register dump to store the DMA registers at the DMA register offset (0x1000) but ethtool (stmmac.c) looks for the DMA registers after the MAC registers which is offset 55. This patch copies the DMA registers from the higher offset to the offset where ethtool expects them. Signed-off-by:
Thor Thayer <thor.thayer@linux.intel.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Paolo Abeni authored
The commit ffb07550 ("copy_msghdr_from_user(): get rid of field-by-field copyin") introduce a new sparse warning: net/socket.c:1919:27: warning: incorrect type in assignment (different address spaces) net/socket.c:1919:27: expected void *msg_control net/socket.c:1919:27: got void [noderef] <asn:1>*[addressable] msg_control and a line above 80 chars, let's fix them Fixes: ffb07550 ("copy_msghdr_from_user(): get rid of field-by-field copyin") Signed-off-by:
Paolo Abeni <pabeni@redhat.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Merge tag 'wireless-drivers-for-davem-2017-07-21' of git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers Kalle Valo says: ==================== wireless-drivers fixes for 4.13 Important, but small in size, fixes. brcmfmac * fix a regression in SDIO support introduced in v4.13-rc1 rtlwifi * fix a regression in bluetooth coexistance introduced in v4.13-rc1 iwlwifi * a few NULL pointer dereferences in the recovery flow * a small but important fix for IBSS * a one-liner fix for tracing, which was including too much data ==================== Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Ido Schimmel authored
Each FIB node holds a linked list of routes sharing the same prefix and length. In the case of IPv4 it's ordered according to table ID, metric and TOS and only the first route in the list is actually programmed to the device. In case a gatewayed route is added somewhere in the list, then after its nexthop group will be refreshed and become valid (due to the resolution of its gateway), it'll mistakenly overwrite the existing entry. Example: 192.168.200.0/24 dev enp3s0np3 scope link metric 1000 offload 192.168.200.0/24 via 192.168.100.1 dev enp3s0np3 metric 1000 offload Both routes are marked as offloaded despite the fact only the first one should actually be present in the device's table. When refreshing the nexthop group, don't write the route to the device's table unless it's the first in its node. Fixes: 9aecce1c ("mlxsw: spectrum_router: Correctly handle identical routes") Signed-off-by:
Ido Schimmel <idosch@mellanox.com> Signed-off-by:
Jiri Pirko <jiri@mellanox.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Phil Sutter authored
During concurrent access testing, threadfunc() concatenated thread ID and object index to create a unique key like so: | tdata->objs[i].value = (tdata->id << 16) | i; This breaks if a user passes an entries parameter of 64k or higher, since 'i' might use more than 16 bits then. Effectively, this will lead to duplicate keys in the table. Fix the problem by introducing a struct holding object and thread ID and using that as key instead of a single integer type field. Fixes: f4a3e90b ("rhashtable-test: extend to test concurrency") Reported by: Manuel Messner <mm@skelett.io> Signed-off-by:
Phil Sutter <phil@nwl.cc> Acked-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Edward Cree says: ==================== bpf: fix verifier min/max handling in BPF_SUB I managed to come up with a test for the swapped bounds in BPF_SUB, so here it is along with a patch that fixes it, separated out from my 'rewrite everything' series so it can go to -stable. ==================== Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Edward Cree authored
We have to subtract the src max from the dst min, and vice-versa, since (e.g.) the smallest result comes from the largest subtrahend. Fixes: 48461135 ("bpf: allow access into map value arrays") Signed-off-by:
Edward Cree <ecree@solarflare.com> Acked-by:
Daniel Borkmann <daniel@iogearbox.net> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Edward Cree authored
There is a bug in the verifier's handling of BPF_SUB: [a,b] - [c,d] yields was [a-c, b-d] rather than the correct [a-d, b-c]. So here is a test which, with the bogus handling, will produce ranges of [0,0] and thus allowed accesses; whereas the correct handling will give a range of [-255, 255] (and hence the right-shift will give a range of [0, 255]) and the accesses will be rejected. Signed-off-by:
Edward Cree <ecree@solarflare.com> Acked-by:
Daniel Borkmann <daniel@iogearbox.net> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Mark Brown authored
The mediatek ethernet driver uses interrupts but does not explicitly include linux/interrupt.h, relying on implicit includes. Fix this so we don't get build breaks as happened for ARM in next-20170720. Signed-off-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Tonghao Zhang authored
There is some codes of tun/tap module which did not check the return value of register_netdevice_notifier. Add the check now. Signed-off-by:
Tonghao Zhang <xiangxia.m.yue@gmail.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Sean Wang authored
Potential dangerous invalid memory might be accessed if invalid mac value reflected from the forward port field in rxd4 caused by possible potential hardware defects. So added a simple sanity checker to avoid the kind of situation happening. Signed-off-by:
Sean Wang <sean.wang@mediatek.com> Acked-by:
John Crispin <john@phrozen.org> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
- 21 Jul, 2017 5 commits
-
-
Kalle Valo authored
Merge tag 'iwlwifi-for-kalle-2017-07-21' of git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes Some iwlwifi fixes for 4.13: * A few NULL pointer dereferences in the recovery flow; * A small but important fix for IBSS; * A one-liner fix for tracing, which was including too much data; * Some of these are bugzilla bug fixes;
-
Johannes Berg authored
A hardware/firmware error may happen at any point in time. In particular, it might happen while mac80211 is in the middle of a flow. We observed the following situation: * mac80211 is in authentication flow, in ieee80211_prep_connection() * iwlwifi firmware crashes, but no error can be reported at this precise point (mostly because the driver method is void, but even if it wasn't we'd just shift to a race condition) * mac80211 continues the flow, trying to add the AP station * iwlwifi has already set its internal restart flag, and so thinks that adding the station is part of the restart and already set up, so it uses the information that's supposed to already be in the struct This can happen with any flow in mac80211 and with any information we try to preserve across hardware restarts. To fix this, only set a new HW_RESTART_REQUESTED flag and translate that to IN_HW_RESTART once mac80211 actually starts the restart by calling our start() method. As a consequence, any mac80211 flow in progress at the time of the restart will properly finish (certainly with errors), before the restart is attempted. This fixes https://bugzilla.kernel.org/show_bug.cgi?id=195299. Reported-by:
djagoo <dev@djagoo.io> Reported-by:
Łukasz Siudut <lsiudut@gmail.com> Signed-off-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
Luca Coelho <luciano.coelho@intel.com>
-
Luca Coelho authored
When IBSS was implemented for DQA, we missid a few places where it should be handled in the same way as AP. Fixes: ee48b722 ("iwlwifi: mvm: support ibss in dqa mode") Signed-off-by:
Luca Coelho <luciano.coelho@intel.com>
-
Emmanuel Grumbach authored
iwl_trace_data is somewhat confusing. It returns a bool that tells if the payload of the skb should be added to the tx_data event. If it returns false, then the payload of the skb is added to the tx event. The purpose is to be able to start tracing with -e iwlwifi and record non-data packets only which saves bandwidth. Since EAPOLs are important, seldom and not real data packet (despite being WiFi data packets), they are included in tx event and thus iwl_trace_data returns false on those. This last part was buggy, and because of that, all the data packets were included in the tx event. Fix that. Fixes: 0c4cb731 ("iwlwifi: tracing: decouple from mac80211") Signed-off-by:
Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by:
Luca Coelho <luciano.coelho@intel.com>
-
Dan Carpenter authored
We don't set the error code here so we end up returning ERR_PTR(0) which is NULL. The caller doesn't expect that so it results in a NULL dereference. Fixes: 2e5d4a8f ("iwlwifi: pcie: Add new configuration to enable MSIX") Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
Luca Coelho <luciano.coelho@intel.com>
-