- 14 May, 2020 40 commits
-
-
Yotam Gigi authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit 251d41c5 upstream. In order to specify that the mlxsw switchx2 driver needs additional headroom for packets, there have been use of the hard_header_len field of the netdevice struct. This commit changes that to use needed_headroom instead, as this is the correct way to do that. Fixes: 31557f0f ("mlxsw: Introduce Mellanox SwitchX-2 ASIC support") Signed-off-by:
Yotam Gigi <yotamg@mellanox.com> Acked-by:
Ido Schimmel <idosch@mellanox.com> Signed-off-by:
Jiri Pirko <jiri@mellanox.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
Ian May <ian.may@canonical.com> Signed-off-by:
Kleber Sacilotto de Souza <kleber.souza@canonical.com>
-
Moshe Shemesh authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit c9cc599a upstream. Separate QUERY_FUNC_CAP flags0 from QUERY_FUNC_CAP flags, as 'flags' is already used for another set of flags in FUNC CAP, while phv bit should be part of a different set of flags. Remove QUERY_FUNC_CAP port_flags field, as it is not in use. Fixes: 77fc29c4 ('net/mlx4_core: Preparations for 802.1ad VLAN support') Fixes: 5cc914f1 ('mlx4_core: Added FW commands and their wrappers for supporting SRIOV') Signed-off-by:
Moshe Shemesh <moshe@mellanox.com> Signed-off-by:
Tariq Toukan <tariqt@mellanox.com> Signed-off-by:
-
Jack Morgenstein authored
net/mlx4: Fix uninitialized fields in rule when adding promiscuous mode to device managed flow steering BugLink: https://bugs.launchpad.net/bugs/1878232 commit 44b911e7 upstream. In procedure mlx4_flow_steer_promisc_add(), several fields were left uninitialized in the rule structure. Correctly initialize these fields. Fixes: 592e49dd ("net/mlx4: Implement promiscuous mode with device managed flow-steering") Signed-off-by:
Jack Morgenstein <jackm@dev.mellanox.co.il> Signed-off-by:
-
Jack Morgenstein authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit d2582a03 upstream. mlx4_en_DUMP_ETH_STATS took the *counter mutex* and then called the FW command, with WRAPPED attribute. As a result, the fw command is wrapped on the Hypervisor when it calls mlx4_en_DUMP_ETH_STATS. The FW command wrapper flow on the hypervisor takes the *slave_cmd_mutex* during processing. At the same time, a VF could be in the process of coming up, and could call mlx4_QUERY_FUNC_CAP. On the hypervisor, the command flow takes the *slave_cmd_mutex*, then executes mlx4_QUERY_FUNC_CAP_wrapper. mlx4_QUERY_FUNC_CAP wrapper calls mlx4_get_default_counter_index(), which takes the *counter mutex*. DEADLOCK. The fix is that the DUMP_ETH_STATS fw command should be called with the NATIVE attribute, so that on the hypervisor, this command does not enter the wrapper flow. Since the Hypervisor no longer goes through the wrapper code, we also simply return 0 in mlx4_DUMP_ETH_STATS_wrapper (i.e.the function succeeds, but the returned data will be all zeroes). No need to test if it is the Hypervisor going through the wrapper. Fixes: f9baff50 ("mlx4_core: Add "native" argument to mlx4_cmd ...") Signed-off-by:
-
Jack Morgenstein authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit 81d18419 upstream. In the Hypervisor, there are several FW commands which are invoked before the comm channel is initialized (in mlx4_multi_func_init). These include MOD_STAT_CONFIG, QUERY_DEV_CAP, INIT_HCA, and others. If any of these commands fails, say with a timeout, the Hypervisor driver enters the internal error reset flow. In this flow, the driver attempts to notify all slaves via the comm channel that an internal error has occurred. Since the comm channel has not yet been initialized (i.e., mapped via ioremap), this will cause dereferencing a NULL pointer. To fix this, do not access the comm channel in the internal error flow if it has not yet been initialized. Fixes: 55ad3592 ("net/mlx4_core: Enable device recovery flow with SRIOV") Fixes: ab9c17a0 ("mlx4_core: Modify driver initialization flow to accommodate SRIOV for Ethernet") Signed-off-by:
-
Erez Shitrit authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit 8d59de8f upstream. Currently there is a race between incoming traffic and initialization flow. HW is able to receive the packets after INIT_PORT is done and unicast steering is configured. Before we set priv->port_up NAPI is not scheduled and receive queues become full. Therefore we never get new interrupts about the completions. This issue could happen if running heavy traffic during bringing port up. The resolution is to schedule NAPI once port_up is set. If receive queues were full this will process all cqes and release them. Fixes: c27a02cd ("mlx4_en: Add driver for Mellanox ConnectX 10GbE NIC") Signed-off-by:
Erez Shitrit <erezsh@mellanox.com> Signed-off-by:
Eugenia Emantayev <eugenia@mellanox.com> Signed-off-by:
-
Jack Morgenstein authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit aa0c08fe upstream. The resource type enum in the resource tracker was incorrect. RES_EQ was put in the position of RES_NPORT_ID (a FC resource). Since the remaining resources maintain their current values, and RES_EQ is not passed from slaves to the hypervisor in any FW command, this change affects only the hypervisor. Therefore, there is no backwards-compatibility issue. Fixes: 623ed84b ("mlx4_core: initial header-file changes for SRIOV support") Signed-off-by:
-
Alex Vesker authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit 9b022a6e upstream. Verify that the device state is registered before un-registering it. This check is required to prevent an OOPS on flows that do re-registration of the device and its previous state was unregistered. Fixes: 225c7b1f ("IB/mlx4: Add a driver Mellanox ConnectX InfiniBand adapters") Signed-off-by:
Alex Vesker <valex@mellanox.com> Signed-off-by:
-
Kamal Heib authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit 93c098af upstream. Modify mlx4_en_vlan_rx_[add/kill]_vid to return error value in case of failure. Fixes: 8e586137 ('net: make vlan ndo_vlan_rx_[add/kill]_vid return error value') Signed-off-by:
Kamal Heib <kamalh@mellanox.com> Signed-off-by:
-
Tariq Toukan authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit 2bb07e15 upstream. Prevent using uninitialized or negative index when handling steering entries. Fixes: b12d93d6 ('mlx4: Add support for promiscuous mode in the new steering model.') Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
Eran Ben Elisha authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit 6b94bab0 upstream. The error flow in procedure handle_existing_counter() is wrong. The procedure should exit after encountering the error, not continue as if everything is OK. Fixes: 68230242 ('net/mlx4_core: Add port attribute when tracking counters') Signed-off-by:
Eran Ben Elisha <eranbe@mellanox.com> Signed-off-by:
-
Daniel Borkmann authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit 20b2b24f upstream. In map_create(), we first find and create the map, then once that suceeded, we charge it to the user's RLIMIT_MEMLOCK, and then fetch a new anon fd through anon_inode_getfd(). The problem is, once the latter fails f.e. due to RLIMIT_NOFILE limit, then we only destruct the map via map->ops->map_free(), but without uncharging the previously locked memory first. That means that the user_struct allocation is leaked as well as the accounted RLIMIT_MEMLOCK memory not released. Make the label names in the fix consistent with bpf_prog_load(). Fixes: aaac3ba9 ("bpf: charge user for creation of BPF maps and programs") Signed-off-by:
Daniel Borkmann <daniel@iogearbox.net> Acked-by:
Alexei Starovoitov <ast@kernel.org> Signed-off-by:
-
Alexei Starovoitov authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit ad572d17 upstream. similar to bpf_perf_event_output() the bpf_perf_event_read() helper needs to check the type of the perf_event before reading the counter. Fixes: a43eec30 ("bpf: introduce bpf_perf_event_output() helper") Reported-by:
-
Zi Shen Lim authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit 98397fc5 upstream. Original implementation commit e54bcde3 ("arm64: eBPF JIT compiler") had the relevant code paths, but due to an oversight always fail jiting. As a result, we had been falling back to BPF interpreter whenever a BPF program has JMP_JSET_{X,K} instructions. With this fix, we confirm that the corresponding tests in lib/test_bpf continue to pass, and also jited. ... [ 2.784553] test_bpf: #30 JSET jited:1 188 192 197 PASS [ 2.791373] test_bpf: #31 tcpdump port 22 jited:1 325 677 625 PASS [ 2.808800] test_bpf: #32 tcpdump complex jited:1 323 731 991 PASS ... [ 3.190759] test_bpf: #237 JMP_JSET_K: if (0x3 & 0x2) return 1 jited:1 110 PASS [ 3.192524] test_bpf: #238 JMP_JSET_K: if (0x3 & 0xffffffff) return 1 jited:1 98 PASS [ 3.211014] test_bpf: #249 JMP_JSET_X: if (0x3 & 0x2) return 1 jited:1 120 PASS [ 3.212973] test_bpf: #250 JMP_JSET_X: if (0x3 & 0xffffffff) return 1 jited:1 89 PASS ... Fixes: e54bcde3 ("arm64: eBPF JIT compiler") Signed-off-by:
Zi Shen Lim <zlim.lnx@gmail.com> Acked-by:
Will Deacon <will.deacon@arm.com> Acked-by:
Yang Shi <yang.shi@linaro.org> Signed-off-by:
-
Daniel Borkmann authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit 3a461da1 upstream. There are two issues with the current code. First one is that we need to set res->class to 0 in case we use non-default classid matching. This is important for the case where cls_bpf was initially set up with an optional binding to a default class with tcf_bind_filter(), where the underlying qdisc implements bind_tcf() that fills res->class and tests for it later on when doing the classification. Convention for these cases is that after tc_classify() was called, such qdiscs (atm, drr, qfq, cbq, hfsc, htb) first test class, and if 0, then they lookup based on classid. Second, there's a bug with da mode, where res->classid is only assigned a 16 bit minor, but it needs to expand to the full 32 bit major/minor combination instead, therefore we need to expand with the bound major. This is fine as classes belonging to a classful qdisc must share the same major. Fixes: 045efa82 ("cls_bpf: introduce integrated actions") Signed-off-by:
-
Laura Abbott authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit 06b113e9 upstream. ioremaped addresses are not linearly mapped so the physical address can not be figured out via __pa. More generally, there is no guarantee that backing value of an ioremapped address is a physical address at all. The value here is only used for debugging so just drop the call to __pa on the ioremapped address. Fixes: 6ae5fd38 ("clk: xgene: Silence sparse warnings") Signed-off-by:
Laura Abbott <labbott@redhat.com> Acked-by:
Loc Ho <lho@apm.com> Signed-off-by:
Stephen Boyd <sboyd@codeaurora.org> Signed-off-by:
-
Dong Aisheng authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit b3e76bdc upstream. After commit f5394745 ("ARM: clk: imx: update pllv3 to support imx7"), the former used BM_PLL_POWER bit is not correct anymore for IMX7 ENET. Instead, pll->powerdown holds the correct bit, so using powerdown bit in clk_pllv3_{prepare | unprepare} functions. Fixes: f5394745 ("ARM: clk: imx: update pllv3 to support imx7") Signed-off-by:
Dong Aisheng <aisheng.dong@nxp.com> Signed-off-by:
Shawn Guo <shawnguo@kernel.org> Signed-off-by:
-
Maxime Ripard authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit 25f77a3a upstream. In the current multiplier base clock implementation, if the CLK_SET_RATE_PARENT flag isn't set, the code will not make sure that the multiplier computed remains within the boundaries of our clock. This means that if the clock we want to reach is below the parent rate, or if the multiplier is above the maximum that we can reach, we will end up with a completely bogus one that the clock cannot achieve. Fixes: f2e0a532 ("clk: Add a basic multiplier clock") Signed-off-by:
Maxime Ripard <maxime.ripard@free-electrons.com> Signed-off-by:
Michael Turquette <mturquette@baylibre.com> Link: lkml.kernel.org/r/1463402840-17062-3-git-send-email-maxime.ripard@free-electrons.com Signed-off-by:
-
Tero Kristo authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit a0d54c38 upstream. As the code in this file is being executed within irq context in some cases, we must avoid the clk_get_rate which uses mutex internally. Switch the code to use clk_hw_get_rate instead which is non-locking. This fixes an issue where PM runtime will hang the system if enabled with a serial console before a suspend-resume cycle. Signed-off-by:
Tero Kristo <t-kristo@ti.com> Tested-by:
Tony Lindgren <tony@atomide.com> Fixes: a53ad8ef ("clk: ti: Convert to clk_hw based provider APIs") Signed-off-by:
-
Brian Norris authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit 0b2e7886 upstream. We might make bad memory allocations if we get (e.g.) -ENOSYS from of_clk_get_parent_count(). Noticed by Coverity. Fixes: f66541ba ("clk: gpio: Get parent clk names in of_gpio_clk_setup()") Signed-off-by:
Brian Norris <computersforpeace@gmail.com> Cc: Jyri Sarha <jsarha@ti.com> Cc: Sergej Sawazki <ce3a@gmx.de> Cc: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by:
-
Arnd Bergmann authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit 2dd52d7f upstream. quadfs_pll_fs660c32_round_rate prints a few structure members that are never initialized, and also doesn't print the only one it cares about. We get a gcc warning about the ones that are printed: clk/st/clkgen-fsyn.c:560:93: warning: 'params.sdiv' may be used uninitialized in this function clk/st/clkgen-fsyn.c:560:93: warning: 'params.mdiv' may be used uninitialized in this function clk/st/clkgen-fsyn.c:560:93: warning: 'params.pe' may be used uninitialized in this function clk/st/clkgen-fsyn.c:560:93: warning: 'params.nsdiv' may be used uninitialized in this function This changes the code to no longer print uninitialized data, and for good measure it also prints the ndiv member that is being set. Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Fixes: 5f7aa907 ("clk: st: Support for QUADFS inside ClockGenB/C/D/E/F") Acked-by:
Gabriel Fernandez <gabriel.fernandez@linaro.org> Signed-off-by:
-
Pablo Neira authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit 73e2d5e3 upstream. Honor udptable parameter that is passed to __udp*_lib_mcast_deliver(), otherwise udplite broadcast/multicast use the wrong table and it breaks. Fixes: 2dc41cff ("udp: Use hash2 for long hash1 chains in __udp*_lib_mcast_deliver.") Signed-off-by:
Pablo Neira Ayuso <pablo@netfilter.org> Acked-by:
Eric Dumazet <edumazet@google.com> Signed-off-by:
-
Liping Zhang authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit b73b8a1b upstream. The NFTA_DUP_SREG_DEV attribute is not a must option, so we should use it in routing lookup only when the user specify it. Fixes: d877f071 ("netfilter: nf_tables: add nft_dup expression") Signed-off-by:
Liping Zhang <zlpnobody@gmail.com> Signed-off-by:
-
Liping Zhang authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit c17c3cdf upstream. When the memory is exhausted, then we will fail to add the NFT_MSG_NEWSET transaction. In such case, we should destroy the set before we free it. Fixes: 958bee14 ("netfilter: nf_tables: use new transaction infrastructure to handle sets") Signed-off-by:
-
Liping Zhang authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit bb6a6e8e upstream. When CONFIG_NFT_SET_HASH is not enabled and I input the following rule: "nft add rule filter output flow table test {ip daddr counter }", kernel panic happened on my system: BUG: unable to handle kernel NULL pointer dereference at (null) IP: [< (null)>] (null) [...] Call Trace: [<ffffffffa0590466>] ? nft_dynset_eval+0x56/0x100 [nf_tables] [<ffffffffa05851bb>] nft_do_chain+0xfb/0x4e0 [nf_tables] [<ffffffffa0432f01>] ? nf_conntrack_tuple_taken+0x61/0x210 [nf_conntrack] [<ffffffffa0459ea6>] ? get_unique_tuple+0x136/0x560 [nf_nat] [<ffffffffa043bca1>] ? __nf_ct_ext_add_length+0x111/0x130 [nf_conntrack] [<ffffffffa045a357>] ? nf_nat_setup_info+0x87/0x3b0 [nf_nat] [<ffffffff81761e27>] ? ipt_do_table+0x327/0x610 [<ffffffffa045a6d7>] ? __nf_nat_alloc_null_binding+0x57/0x80 [nf_nat] [<ffffffffa059f21f>] nft_ipv4_output+0xaf/0xd0 [nf_tables_ipv4] [<ffffffff81702515>] nf_iterate+0x55/0x60 [<ffffffff81702593>] nf_hook_slow+0x73/0xd0 Because in rbtree type set, ops->update is not implemented. So just keep it simple, in such case, report -EOPNOTSUPP to the user space. Fixes: 22fe54d5 ("netfilter: nf_tables: add support for dynamic set updates") Signed-off-by:
-
Liping Zhang authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit 8fff1722 upstream. nft_genmask_cur has already done left-shift operator on the gencursor, so there's no need to do left-shift operator on it again. Fixes: ea4bd995 ("netfilter: nf_tables: add transaction helper functions") Cc: Patrick McHardy <kaber@trash.net> Signed-off-by:
Liping Zhang <liping.zhang@spreadtrum.com> Signed-off-by:
-
David Ahern authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit 830218c1 upstream. rt6_add_route_info and rt6_add_dflt_router were updated to pull the FIB table from the device index, but the corresponding rt6_get_route_info and rt6_get_dflt_router functions were not leading to the failure to process RA's: ICMPv6: RA: ndisc_router_discovery failed to add default route Fix the 'get' functions by using the table id associated with the device when applicable. Also, now that default routes can be added to tables other than the default table, rt6_purge_dflt_routers needs to be updated as well to look at all tables. To handle that efficiently, add a flag to the table denoting if it is has a default route via RA. Fixes: ca254490 ("net: Add VRF support to IPv6 stack") Signed-off-by:
David Ahern <dsa@cumulusnetworks.com> Signed-off-by:
-
Nicolas Dichtel authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit d26c638c upstream. The 'default' value was not advertised. Fixes: f3a1bfb1 ("rtnl/ipv6: use netconf msg to advertise forwarding status") Signed-off-by:
Nicolas Dichtel <nicolas.dichtel@6wind.com> Signed-off-by:
-
Eric Dumazet authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit 927265bc upstream. All inet6_netconf_notify_devconf() callers are in process context, so we can use GFP_KERNEL allocations if we take care of not holding a rwlock while not needed in ip6mr (we hold RTNL there) Fixes: d67b8c61 ("netconf: advertise mc_forwarding status") Fixes: f3a1bfb1 ("rtnl/ipv6: use netconf msg to advertise forwarding status") Signed-off-by:
-
Hannes Frederic Sowa authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit c148d163 upstream. Cc: Tom Herbert <tom@herbertland.com> Fixes: 4068579e ("net: Implmement RFC 6936 (zero RX csums for UDP/IPv6") Signed-off-by:
Hannes Frederic Sowa <hannes@stressinduktion.org> Signed-off-by:
-
David Ahern authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit 4f7f34ea upstream. ifupdown2 found a kernel bug with IPv6 routes and movement from the main table to the VRF table. Sequence of events: Create the interface and add addresses: ip link add dev eth4.105 link eth4 type vlan id 105 ip addr add dev eth4.105 8.105.105.10/24 ip -6 addr add dev eth4.105 2008:105:105::10/64 At this point IPv6 has inserted a prefix route in the main table even though the interface is 'down'. From there the VRF device is created: ip link add dev vrf105 type vrf table 105 ip addr add dev vrf105 9.9.105.10/32 ip -6 addr add dev vrf105 2000:9:105::10/128 ip link set vrf105 up Then the interface is enslaved, while still in the 'down' state: ip link set dev eth4.105 master vrf105 Since the device is down the VRF driver cycling the device does not send the NETDEV_UP and NETDEV_DOWN but rather the NETDEV_CHANGE event which does not flush the routes inserted prior. When the link is brought up ip link set dev eth4.105 up the prefix route is added in the VRF table, but does not remove the route from the main table. Fix by handling the NETDEV_CHANGEUPPER event similar what was implemented for IPv4 in 7f49e7a3 ("net: Flush local routes when device changes vrf association") Fixes: 35402e31 ("net: Add IPv6 support to VRF device") Signed-off-by:
-
Eric Dumazet authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit e895cdce upstream. In commit f02db315 ("ipv4: IP_TOS and IP_TTL can be specified as ancillary data") Francesco added IP_TOS values specified as integer. However, kernel sends to userspace (at recvmsg() time) an IP_TOS value in a single byte, when IP_RECVTOS is set on the socket. It can be very useful to reflect all ancillary options as given by the kernel in a subsequent sendmsg(), instead of aborting the sendmsg() with EINVAL after Francesco patch. So this patch extends IP_TOS ancillary to accept an u8, so that an UDP server can simply reuse same ancillary block without having to mangle it. Jesper can then augment https://github.com/netoptimizer/network-testing/blob/master/src/udp_example02.c to add TOS reflection ;) Fixes: f02db315 ("ipv4: IP_TOS and IP_TTL can be specified as ancillary data") Signed-off-by:
Jesper Dangaard Brouer <brouer@redhat.com> Signed-off-by:
-
Eric Dumazet authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit fa17806c upstream. inet_forward_change() runs with RTNL held. We are allowed to sleep if required. If we use __in_dev_get_rtnl() instead of __in_dev_get_rcu(), we no longer have to use GFP_ATOMIC allocations in inet_netconf_notify_devconf(), meaning we are less likely to miss notifications under memory pressure, and wont touch precious memory reserves either and risk dropping incoming packets. inet_netconf_get_devconf() can also use GFP_KERNEL allocation. Fixes: edc9e748 ("rtnl/ipv4: use netconf msg to advertise forwarding status") Fixes: 9e551110 ("rtnl/ipv4: add support of RTM_GETNETCONF") Signed-off-by:
-
Hannes Frederic Sowa authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit b46d9f62 upstream. Reported-by:
Cong Wang <xiyou.wangcong@gmail.com> Cc: Cong Wang <xiyou.wangcong@gmail.com> Cc: Tom Herbert <tom@herbertland.com> Fixes: 4068579e ("net: Implmement RFC 6936 (zero RX csums for UDP/IPv6") Signed-off-by:
-
Alexander Duyck authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit 918c023f upstream. This patch corrects the logic for the IPv4 parsing so that it is consistent with how we handle IPv6. Specifically if we do not have the flow key indicating we want the addresses we still may need to take a look at the IP fragmentation bits and to see if we should stop after we have recognized the L3 header. Fixes: 807e165d ("flow_dissector: Add control/reporting of fragmentation") Signed-off-by:
Alexander Duyck <aduyck@mirantis.com> Acked-by:
Tom Herbert <tom@herbertland.com> Signed-off-by:
-
Alexander Duyck authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit 3114cdfe upstream. Fix a small memory leak that can occur where we leak a fib_alias in the event of us not being able to insert it into the local table. Fixes: 0ddcf43d ("ipv4: FIB Local/MAIN table collapse") Reported-by:
Alexander Duyck <alexander.h.duyck@intel.com> Acked-by:
-
Douglas Miller authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit a69bf3c5 upstream. The adapter->pcicfg resource is either mapped via pci_iomap() or derived from adapter->db. During be_remove() this resource was ignored and so could remain mapped after remove. Add a flag to track whether adapter->pcicfg was mapped or not, then use that flag in be_unmap_pci_bars() to unmap if required. Fixes: 25848c90 ("use PCI MMIO read instead of config read for errors") Signed-off-by:
Douglas Miller <dougmill@linux.vnet.ibm.com> Signed-off-by:
-
Stefan Wahren authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit 53653c6b upstream. In case of an invalid pin value bcm2835_pctl_dt_node_to_map() would leak the pull configs of already assigned pins. So avoid this by calling the free map function in error case. Signed-off-by:
Stefan Wahren <stefan.wahren@i2se.com> Fixes: e1b2dc70 ("pinctrl: add bcm2835 driver") Reviewed-by:
Eric Anholt <eric@anholt.net> Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
Vince Hsu authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit e2127ae7 upstream. Tegra124 was accidentally left out when the number of TLB lines was parameterized in commit 11cec15b ("iommu/tegra-smmu: Parameterize number of TLB lines"). Fortunately this doesn't cause any noticeable regressions upstream, presumably because there aren't any use-cases that exercise enough pressure on the SMMU. But it is a regression nonetheless, so let's fix it. Fixes: 11cec15b ("iommu/tegra-smmu: Parameterize number of TLB lines") Signed-off-by:
Vince Hsu <vince.h@nvidia.com> Signed-off-by:
Tomasz Figa <tfiga@chromium.org> [treding@nvidia.com: extract from unrelated patch] Signed-off-by:
Thierry Reding <treding@nvidia.com> Signed-off-by:
-
Bart Van Assche authored
BugLink: https://bugs.launchpad.net/bugs/1878232 commit f0a8afec upstream. strsep() modifies its first argument. Make the pointer passed to kfree() match the return value of kmalloc(). Fixes: 229d4f11 (commit "target_core_alua: Referrals configfs integration") Signed-off-by:
Bart Van Assche <bart.vanassche@sandisk.com> Cc: Hannes Reinecke <hare@suse.com> Cc: Christoph Hellwig <hch@lst.de> Cc: Andy Grover <agrover@redhat.com> Cc: Sagi Grimberg <sagig@mellanox.com> Signed-off-by:
Nicholas Bellinger <nab@linux-iscsi.org> Signed-off-by:
-
