- 13 Jan, 2019 40 commits
-
-
Thomas Gleixner authored
commit 0211e12d upstream. When the allocation of node_to_possible_cpumask fails, then irq_create_affinity_masks() returns with a pointer to the empty affinity masks array, which will cause malfunction. Reorder the allocations so the masks array allocation comes last and every failure path returns NULL. Fixes: 9a0ef98e ("genirq/affinity: Assign vectors to all present CPUs") Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Cc: Christoph Hellwig <hch@infradead.org> Cc: Ming Lei <ming.lei@redhat.com> Cc: Mihai Carabas <mihai.carabas@oracle.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Ewan D. Milne authored
commit 4e87eb2f upstream. Certain older adapters such as the OneConnect OCe10100 may not have a valid wqpcnt value. In this case, do not set queue->page_count to 0 in lpfc_sli4_queue_alloc() as this will prevent the driver from initializing. Fixes: 895427bd ("scsi: lpfc: NVME Initiator: Base modifications") Cc: stable@vger.kernel.org # 4.11+ Signed-off-by:
Ewan D. Milne <emilne@redhat.com> Reviewed-by:
Laurence Oberman <loberman@redhat.com> Tested-by:
Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by:
-
Steffen Maier authored
commit 60a161b7 upstream. Suppose adapter (open) recovery is between opened QDIO queues and before (the end of) initial posting of status read buffers (SRBs). This time window can be seconds long due to FSF_PROT_HOST_CONNECTION_INITIALIZING causing by design looping with exponential increase sleeps in the function performing exchange config data during recovery [zfcp_erp_adapter_strat_fsf_xconf()]. Recovery triggered by local link up. Suppose an event occurs for which the FCP channel would send an unsolicited notification to zfcp by means of a previously posted SRB. We saw it with local cable pull (link down) in multi-initiator zoning with multiple NPIV-enabled subchannels of the same shared FCP channel. As soon as zfcp_erp_adapter_strategy_open_fsf() starts posting the initial status read buffers from within the adapter's ERP thread, the channel does send an unsolicited notification. Since v2.6.27 commit d26ab06e ("[SCSI] zfcp: receiving an unsolicted status can lead to I/O stall"), zfcp_fsf_status_read_handler() schedules adapter->stat_work to re-fill the just consumed SRB from a work item. Now the ERP thread and the work item post SRBs in parallel. Both contexts call the helper function zfcp_status_read_refill(). The tracking of missing (to be posted / re-filled) SRBs is not thread-safe due to separate atomic_read() and atomic_dec(), in order to depend on posting success. Hence, both contexts can see atomic_read(&adapter->stat_miss) == 1. One of the two contexts posts one too many SRB. Zfcp gets QDIO_ERROR_SLSB_STATE on the output queue (trace tag "qdireq1") leading to zfcp_erp_adapter_shutdown() in zfcp_qdio_handler_error(). An obvious and seemingly clean fix would be to schedule stat_work from the ERP thread and wait for it to finish. This would serialize all SRB re-fills. However, we already have another work item wait on the ERP thread: adapter->scan_work runs zfcp_fc_scan_ports() which calls zfcp_fc_eval_gpn_ft(). The latter calls zfcp_erp_wait() to wait for all the open port recoveries during zfcp auto port scan, but in fact it waits for any pending recovery including an adapter recovery. This approach leads to a deadlock. [see also v3.19 commit 18f87a67 ("zfcp: auto port scan resiliency"); v2.6.37 commit d3e1088d ("[SCSI] zfcp: No ERP escalation on gpn_ft eval"); v2.6.28 commit fca55b6f ("[SCSI] zfcp: fix deadlock between wq triggered port scan and ERP") fixing v2.6.27 commit c57a39a4 ("[SCSI] zfcp: wait until adapter is finished with ERP during auto-port"); v2.6.27 commit cc8c2829 ("[SCSI] zfcp: Automatically attach remote ports")] Instead make the accounting of missing SRBs atomic for parallel execution in both the ERP thread and adapter->stat_work. Signed-off-by:
Steffen Maier <maier@linux.ibm.com> Fixes: d26ab06e ("[SCSI] zfcp: receiving an unsolicted status can lead to I/O stall") Cc: <stable@vger.kernel.org> #2.6.27+ Reviewed-by:
Jens Remus <jremus@linux.ibm.com> Signed-off-by:
-
Yangtao Li authored
[ Upstream commit d430aff8 ] The function of_find_node_by_path() acquires a reference to the node returned by it and that reference needs to be dropped by its caller. su_get_type() doesn't do that. The match node are used as an identifier to compare against the current node, so we can directly drop the refcount after getting the node from the path as it is not used as pointer. Fix this by use a single variable and drop the refcount right after of_find_node_by_path(). Signed-off-by:
Yangtao Li <tiny.windzz@gmail.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Daniele Palmas authored
[ Upstream commit d667044f ] This patch fixes qmap header retrieval when modem is configured for dl data aggregation. Signed-off-by:
Daniele Palmas <dnlplm@gmail.com> Signed-off-by:
-
Kangjie Lu authored
[ Upstream commit d134e486 ] When netxen_rom_fast_read() fails, "bios" is left uninitialized and may contain random value, thus should not be used. The fix ensures that if netxen_rom_fast_read() fails, we return "-EIO". Signed-off-by:
Kangjie Lu <kjlu@umn.edu> Signed-off-by:
-
Mantas Mikulėnas authored
[ Upstream commit 7a717122 ] dmesg reports that "Your touchpad (PNP: SYN3052 SYN0100 SYN0002 PNP0f13) says it can support a different bus." I've tested the offered psmouse.synaptics_intertouch=1 with 4.18.x and 4.19.x and it seems to work well. No problems seen with suspend/resume. Also, it appears that RMI/SMBus mode is actually required for 3-4 finger multitouch gestures to work -- otherwise they are not reported at all. Information from dmesg in both modes: psmouse serio3: synaptics: Touchpad model: 1, fw: 8.2, id: 0x1e2b1, caps: 0xf00123/0x840300/0x2e800/0x0, board id: 3139, fw id: 2000742 psmouse serio3: synaptics: Trying to set up SMBus access rmi4_smbus 6-002c: registering SMbus-connected sensor rmi4_f01 rmi4-00.fn01: found RMI device, manufacturer: Synaptics, product: TM3139-001, fw id: 2000742 Signed-off-by:
Mantas Mikulėnas <grawity@gmail.com> Reviewed-by:
Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by:
Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by:
-
Uwe Kleine-König authored
[ Upstream commit c8da642d ] The gpio IP on Armada 370 at offset 0x18180 has neither a clk nor pwm registers. So there is no need for a clk as the pwm isn't used anyhow. So only check for the clk in the presence of the pwm registers. This fixes a failure to probe the gpio driver for the above mentioned gpio device. Fixes: 757642f9 ("gpio: mvebu: Add limited PWM support") Signed-off-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reviewed-by:
Gregory CLEMENT <gregory.clement@bootlin.com> Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
Michael S. Tsirkin authored
[ Upstream commit c5c08bed ] Fixes: d3849953 ("fs: decouple READ and WRITE from the block layer ops") Signed-off-by:
Michael S. Tsirkin <mst@redhat.com> Signed-off-by:
-
Masahiro Yamada authored
[ Upstream commit ef7cfd00 ] For the same reason as commit 25896d07 ("x86/build: Fix compiler support check for CONFIG_RETPOLINE"), you cannot put this $(error ...) into the parse stage of the top Makefile. Perhaps I'd propose a more sophisticated solution later, but this is the best I can do for now. Link: https://lkml.org/lkml/2017/12/25/211Reported-by:
Paul Gortmaker <paul.gortmaker@windriver.com> Reported-by:
Bernd Edlinger <bernd.edlinger@hotmail.de> Reported-by:
Qian Cai <cai@lca.pw> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Signed-off-by:
Masahiro Yamada <yamada.masahiro@socionext.com> Tested-by:
-
Sara Sharon authored
[ Upstream commit 34b1e0e9 ] mac80211 uses the frag list to build AMSDU. When freeing the skb, it may not be really freed, since someone is still holding a reference to it. In that case, when TCP skb is being retransmitted, the pointer to the frag list is being reused, while the data in there is no longer valid. Since we will never get frag list from the network stack, as mac80211 doesn't advertise the capability, we can safely free and nullify it before releasing the SKB. Signed-off-by:
Sara Sharon <sara.sharon@intel.com> Signed-off-by:
Luca Coelho <luciano.coelho@intel.com> Signed-off-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
-
Colin Ian King authored
[ Upstream commit f7db2beb ] Currently variable data0 is not being initialized so a garbage value is being passed to vxge_hw_vpath_fw_api and this value is being written to the rts_access_steer_data0 register. There are other occurrances where data0 is being initialized to zero (e.g. in function vxge_hw_upgrade_read_version) so I think it makes sense to ensure data0 is initialized likewise to 0. Detected by CoverityScan, CID#140696 ("Uninitialized scalar variable") Fixes: 8424e00d ("vxge: serialize access to steering control register") Signed-off-by:
Colin Ian King <colin.king@canonical.com> Signed-off-by:
-
Jason Martinsen authored
[ Upstream commit 15515aaa ] Current state for the lan78xx driver does not allow for changing the MAC address of the interface, without either removing the module (if you compiled it that way) or rebooting the machine. If you attempt to change the MAC address, ifconfig will show the new address, however, the system/interface will not respond to any traffic using that configuration. A few short-term options to work around this are to unload the module and reload it with the new MAC address, change the interface to "promisc", or reboot with the correct configuration to change the MAC. This patch enables the ability to change the MAC address via fairly normal means... ifdown <interface> modify entry in /etc/network/interfaces OR a similar method ifup <interface> Then test via any network communication, such as ICMP requests to gateway. My only test platform for this patch has been a raspberry pi model 3b+. Signed-off-by:
Jason Martinsen <jasonmartinsen@msn.com> ----- Signed-off-by:
-
Anssi Hannula authored
[ Upstream commit 8159ecab ] Bit RX_USED set to 0 in the address field allows the controller to write data to the receive buffer descriptor. The driver does not ensure the ctrl field is ready (cleared) when the controller sees the RX_USED=0 written by the driver. The ctrl field might only be cleared after the controller has already updated it according to a newly received frame, causing the frame to be discarded in gem_rx() due to unexpected ctrl field contents. A message is logged when the above scenario occurs: macb ff0b0000.ethernet eth0: not whole frame pointed by descriptor Fix the issue by ensuring that when the controller sees RX_USED=0 the ctrl field is already cleared. This issue was observed on a ZynqMP based system. Fixes: 4df95131 ("net/macb: change RX path for GEM") Signed-off-by:
Anssi Hannula <anssi.hannula@bitwise.fi> Tested-by:
Claudiu Beznea <claudiu.beznea@microchip.com> Cc: Nicolas Ferre <nicolas.ferre@microchip.com> Signed-off-by:
-
Anssi Hannula authored
[ Upstream commit e100a897 ] 64-bit DMA addresses are split in upper and lower halves that are written in separate fields on GEM. For RX, bit 0 of the address is used as the ownership bit (RX_USED). When the RX_USED bit is unset the controller is allowed to write data to the buffer. The driver does not guarantee that the controller already sees the upper half when the RX_USED bit is cleared, possibly resulting in the controller writing an incoming frame to an address with an incorrect upper half and therefore possibly corrupting unrelated system memory. Fix that by adding the necessary DMA memory barrier between the writes. This corruption was observed on a ZynqMP based system. Fixes: fff8019a ("net: macb: Add 64 bit addressing support for GEM") Signed-off-by:
Harini Katakam <harini.katakam@xilinx.com> Tested-by:
-
Dan Carpenter authored
[ Upstream commit f07d4276 ] We accidentally deleted the code to set "rc = -ENOMEM;" and this patch adds it back. Fixes: d2201a21 ("qed: No need for LL2 frags indication") Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
Trond Myklebust authored
[ Upstream commit cf76785d ] Ensure that we clear XPRT_CONNECTING before releasing the XPRT_LOCK so that we don't have races between the (asynchronous) socket setup code and tasks in xprt_connect(). Signed-off-by:
Trond Myklebust <trond.myklebust@hammerspace.com> Tested-by:
Chuck Lever <chuck.lever@oracle.com> Signed-off-by:
-
Yonglong Liu authored
[ Upstream commit 6adafc35 ] Create a net bridge, add eth and vnet to the bridge. The vnet is used by a virtual machine. When ping the virtual machine from the outside host and the virtual machine send multicast at the same time, the ping package will lost. The multicast package send to the eth, eth will send it to the bridge too, and the bridge learn the mac of eth. When outside host ping the virtual mechine, it will match the promisc entry of the eth which is not expected, and the bridge send it to eth not to vnet, cause ping lost. So this patch change promisc tcam entry position to the END of 512 tcam entries, which indicate lower priority. And separate one promisc entry to two: mc & uc, to avoid package match the wrong tcam entry. Signed-off-by:
Yonglong Liu <liuyonglong@huawei.com> Signed-off-by:
Peng Li <lipeng321@huawei.com> Signed-off-by:
-
Yonglong Liu authored
[ Upstream commit 726ae5c9 ] In some case, when mac enable|disable and adjust link, may cause hard to link(or abnormal) between mac and phy. This patch adds the code for rx PCS to avoid this bug. Disable the rx PCS when driver disable the gmac, and enable the rx PCS when driver enable the mac. Signed-off-by:
-
Yonglong Liu authored
[ Upstream commit 7e74a19c ] The ntuple-filters features is forced on by chip. But it shows "ntuple-filters: off [fixed]" when use ethtool. This patch make it correct with "ntuple-filters: on [fixed]". Signed-off-by:
-
Yonglong Liu authored
[ Upstream commit a57275d3 ] There will be a large number of MAC pause frames on the net, which caused tx timeout of net device. And then the net device was reset to try to recover it. So that is not useful, and will cause some other problems. So need doubled ndev->watchdog_timeo if device watchdog occurred until watchdog_timeo up to 40s and then try resetting to recover it. When collecting dfx information such as hardware registers when tx timeout. Some registers for count were cleared when read. So need move this task before update net state which also read the count registers. Signed-off-by:
-
Yonglong Liu authored
[ Upstream commit c82bd077 ] 1.In "hns_nic_init_irq", if request irq fail at index i, the function return directly without releasing irq resources that already requested. 2.In "hns_nic_net_up" after "hns_nic_init_irq", if exceptional branch occurs, irqs that already requested are not release. Signed-off-by:
-
Yonglong Liu authored
[ Upstream commit 31f6b61d ] If there are packets in hardware when changing the speed or duplex, it may cause hardware hang up. This patch adds the code to wait rx fbd clean up when ae stopped. Signed-off-by:
-
Yonglong Liu authored
[ Upstream commit 5778b13b ] After resetting dsaf to try to repair chip error such as ecc error, the net device will be open if net interface is up. But at this time if there is the users set the net device up with the command ifconfig, the net device will be opened twice consecutively. Function napi_enable was called when open device. And Kernel panic will be occurred if it was called twice consecutively. Such as follow: static inline void napi_enable(struct napi_struct *n) { BUG_ON(!test_bit(NAPI_STATE_SCHED, &n->state)); smp_mb__before_clear_bit(); clear_bit(NAPI_STATE_SCHED, &n->state); } [37255.571996] Kernel panic - not syncing: BUG! [37255.595234] Call trace: [37255.597694] [<ffff80000008ab48>] dump_backtrace+0x0/0x1a0 [37255.603114] [<ffff80000008ad08>] show_stack+0x20/0x28 [37255.608187] [<ffff8000009c4944>] dump_stack+0x98/0xb8 [37255.613258] [<ffff8000009c149c>] panic+0x10c/0x26c [37255.618070] [<ffff80000070f134>] hns_nic_net_up+0x30c/0x4e0 [37255.623664] [<ffff80000070f39c>] hns_nic_net_open+0x94/0x12c [37255.629346] [<ffff80000084be78>] __dev_open+0xf4/0x168 [37255.634504] [<ffff80000084c1ac>] __dev_change_flags+0x98/0x15c [37255.640359] [<ffff80000084c29c>] dev_change_flags+0x2c/0x68 [37255.769580] [<ffff8000008dc400>] devinet_ioctl+0x650/0x704 [37255.775086] [<ffff8000008ddc38>] inet_ioctl+0x98/0xb4 [37255.780159] [<ffff800000827b7c>] sock_do_ioctl+0x44/0x84 [37255.785490] [<ffff800000828e04>] sock_ioctl+0x248/0x30c [37255.790737] [<ffff80000026dc6c>] do_vfs_ioctl+0x480/0x618 [37255.796156] [<ffff80000026de94>] SyS_ioctl+0x90/0xa4 [37255.801139] SMP: stopping secondary CPUs [37255.805079] kbox: catch panic event. [37255.809586] collected_len = 128928, LOG_BUF_LEN_LOCAL = 131072 [37255.816103] flush cache 0xffff80003f000000 size 0x800000 [37255.822192] flush cache 0xffff80003f000000 size 0x800000 [37255.828289] flush cache 0xffff80003f000000 size 0x800000 [37255.834378] kbox: no notify die func register. no need to notify [37255.840413] ---[ end Kernel panic - not syncing: BUG! This patchset fix this bug according to the flag NIC_STATE_DOWN. Signed-off-by:
-
Yonglong Liu authored
[ Upstream commit 4ad26f11 ] According to the hip06 datasheet: 1.Six registers use wrong address: RCB_COM_SF_CFG_INTMASK_RING RCB_COM_SF_CFG_RING_STS RCB_COM_SF_CFG_RING RCB_COM_SF_CFG_INTMASK_BD RCB_COM_SF_CFG_BD_RINT_STS DSAF_INODE_VC1_IN_PKT_NUM_0_REG 2.The offset of DSAF_INODE_VC1_IN_PKT_NUM_0_REG should be 0x103C + 0x80 * all_chn_num 3.The offset to show the value of DSAF_INODE_IN_DATA_STP_DISC_0_REG is wrong, so the value of DSAF_INODE_SW_VLAN_TAG_DISC_0_REG will be overwrite These registers are only used in "ethtool -d", so that did not cause ndev to misfunction. Signed-off-by:
-
Yonglong Liu authored
[ Upstream commit 308c6caf ] There are two test cases: 1. Remove the 4 modules:hns_enet_drv/hns_dsaf/hnae/hns_mdio, and install them again, must use "ifconfig down/ifconfig up" command pair to bring port to work. This patch calls phy_stop function when init phy to fix this bug. 2. Remove the 2 modules:hns_enet_drv/hns_dsaf, and install them again, all ports can not use anymore, because of the phy devices register failed(phy devices already exists). Phy devices are registered when hns_dsaf installed, this patch removes them when hns_dsaf removed. The two cases are sometimes related, fixing the second case also requires fixing the first case, so fix them together. Signed-off-by:
-
Yonglong Liu authored
[ Upstream commit 4e1d4be6 ] According to the hip06 Datasheet: 1. The offset of INGRESS_SW_VLAN_TAG_DISC should be 0x1A00+4*all_chn_num 2. The offset of INGRESS_IN_DATA_STP_DISC should be 0x1A50+4*all_chn_num Signed-off-by:
-
Arnd Bergmann authored
[ Upstream commit 51367e42 ] The get_mac_address() function is normally inline, but when it is not, we get a warning that this configuration is broken: WARNING: vmlinux.o(.text+0x4aff00): Section mismatch in reference from the function w90p910_ether_setup() to the function .init.text:get_mac_address() The function w90p910_ether_setup() references the function __init get_mac_address(). This is often because w90p910_ether_setup lacks a __init Remove the __init to make it always do the right thing. Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
-
Nathan Chancellor authored
[ Upstream commit 2ab4c342 ] Clang warns: drivers/net/ethernet/apm/xgene/xgene_enet_main.c:33:36: warning: tentative array definition assumed to have one element static const struct acpi_device_id xgene_enet_acpi_match[]; ^ 1 warning generated. Both xgene_enet_acpi_match and xgene_enet_of_match are defined before their uses at the bottom of the file so this is unnecessary. When CONFIG_ACPI is disabled, ACPI_PTR becomes NULL so xgene_enet_acpi_match doesn't need to be defined. Signed-off-by:
Nathan Chancellor <natechancellor@gmail.com> Signed-off-by:
-
Sinan Kaya authored
[ Upstream commit c629421a ] Need to be able to boot without PCI devices present. Signed-off-by:
Sinan Kaya <okaya@kernel.org> Signed-off-by:
-
Varun Prakash authored
[ Upstream commit 9e6371d3 ] Add missing spin_lock_init() for cdev->np_lock. Signed-off-by:
Varun Prakash <varun@chelsio.com> Signed-off-by:
-
Varun Prakash authored
[ Upstream commit 801df68d ] csk leak can happen if a new TCP connection gets established after cxgbit_accept_np() returns, to fix this leak free remaining csk in cxgbit_free_np(). Signed-off-by:
-
Sudarsana Reddy Kalluru authored
[ Upstream commit 9061193c ] Driver sends update-SVID ramrod in the MFW notification path. If there is a pending ramrod, driver doesn't retry the command and storm firmware will never be updated with the SVID value. The patch adds changes to send update-svid ramrod in process context with retry/poll flags set. Signed-off-by:
Sudarsana Reddy Kalluru <Sudarsana.Kalluru@cavium.com> Signed-off-by:
Ariel Elior <ariel.elior@cavium.com> Signed-off-by:
-
Sudarsana Reddy Kalluru authored
[ Upstream commit 04f05230 ] Vlans are not getting removed when drivers are unloaded. The recent storm firmware versions had added safeguards against re-configuring an already configured vlan. As a result, PF inner reload flows (e.g., mtu change) might trigger an assertion. This change is going to remove vlans (same as we do for MACs) when doing a chip cleanup during unload. Signed-off-by:
-
Sudarsana Reddy Kalluru authored
[ Upstream commit bbf666c1 ] On some customer setups it was observed that shmem contains a non-zero fip MAC for 57711 which would lead to enabling of SW FCoE. Add a software workaround to clear the bad fip mac address if no FCoE connections are supported. Signed-off-by:
-
Florian Westphal authored
[ Upstream commit 542fbda0 ] The dst entry might already have a zero refcount, waiting on rcu list to be free'd. Using dst_hold() transitions its reference count to 1, and next dst release will try to free it again -- resulting in a double free: WARNING: CPU: 1 PID: 0 at include/net/dst.h:239 nf_xfrm_me_harder+0xe7/0x130 [nf_nat] RIP: 0010:nf_xfrm_me_harder+0xe7/0x130 [nf_nat] Code: 48 8b 5c 24 60 65 48 33 1c 25 28 00 00 00 75 53 48 83 c4 68 5b 5d 41 5c c3 85 c0 74 0d 8d 48 01 f0 0f b1 0a 74 86 85 c0 75 f3 <0f> 0b e9 7b ff ff ff 29 c6 31 d2 b9 20 00 48 00 4c 89 e7 e8 31 27 Call Trace: nf_nat_ipv4_out+0x78/0x90 [nf_nat_ipv4] nf_hook_slow+0x36/0xd0 ip_output+0x9f/0xd0 ip_forward+0x328/0x440 ip_rcv+0x8a/0xb0 Use dst_hold_safe instead and bail out if we cannot take a reference. Fixes: a4c2fd7f ("net: remove DST_NOCACHE flag") Reported-by:
Martin Zaharinov <micron10@gmail.com> Signed-off-by:
Florian Westphal <fw@strlen.de> Signed-off-by:
Pablo Neira Ayuso <pablo@netfilter.org> Signed-off-by:
-
Pan Bian authored
[ Upstream commit 708abf74 ] In the error handling block, nla_nest_cancel(skb, atd) is called to cancel the nest operation. But then, ipset_nest_end(skb, atd) is unexpected called to end the nest operation. This patch calls the ipset_nest_end only on the branch that nla_nest_cancel is not called. Fixes: 45040978 ("netfilter: ipset: Fix set:list type crash when flush/dump set in parallel") Signed-off-by:
Pan Bian <bianpan2016@163.com> Signed-off-by:
Jozsef Kadlecsik <kadlec@blackhole.kfki.hu> Signed-off-by:
-
Stefan Assmann authored
[ Upstream commit 158daed1 ] A previous commit moved the ether_addr_copy() in i40e_set_mac() before the mac filter del/add to avoid a race. However it wasn't taken into account that this alters the mac address being handed to i40e_del_mac_filter(). Also changed i40e_add_mac_filter() to operate on netdev->dev_addr, hopefully that makes the code easier to read. Fixes: 458867b2 ("i40e: don't remove netdev->dev_addr when syncing uc list") Signed-off-by:
Stefan Assmann <sassmann@kpanic.de> Tested-by:
Andrew Bowers <andrewx.bowers@intel.com> Acked-by:
Jacob Keller <jacob.e.keller@intel.com> Signed-off-by:
Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by:
-
Kirill A. Shutemov authored
[ Upstream commit 254eb550 ] The LDT remap placement has been changed. It's now placed before the direct mapping in the kernel virtual address space for both paging modes. Change address markers order accordingly. Fixes: d52888aa ("x86/mm: Move LDT remap out of KASLR region on 5-level paging") Signed-off-by:
Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Signed-off-by:
-
Kirill A. Shutemov authored
[ Upstream commit 16877a55 ] There is a guard hole at the beginning of the kernel address space, also used by hypervisors. It occupies 16 PGD entries. This reserved range is not defined explicitely, it is calculated relative to other entities: direct mapping and user space ranges. The calculation got broken by recent changes of the kernel memory layout: LDT remap range is now mapped before direct mapping and makes the calculation invalid. The breakage leads to crash on Xen dom0 boot[1]. Define the reserved range explicitely. It's part of kernel ABI (hypervisors expect it to be stable) and must not depend on changes in the rest of kernel memory layout. [1] https://lists.xenproject.org/archives/html/xen-devel/2018-11/msg03313.html Fixes: d52888aa ("x86/mm: Move LDT remap out of KASLR region on 5-level paging") Reported-by:
Hans van Kranenburg <hans.van.kranenburg@mendix.com> Signed-off-by:
Juergen Gross <jgross@suse.com> Cc: bp@alien8.de Cc: hpa@zytor.com Cc: dave.hansen@linux.intel.com Cc: luto@kernel.org Cc: peterz@infradead.org Cc: boris.ostrovsky@oracle.com Cc: bhe@redhat.com Cc: linux-mm@kvack.org Cc: xen-devel@lists.xenproject.org Link: https://lkml.kernel.org/r/20181130202328.65359-2-kirill.shutemov@linux.intel.comSigned-off-by:
-
