- 16 Jan, 2019 40 commits
-
-
Juerg Haefliger authored
In Ubuntu, we have runtime control for enabling/disabling IBRS via the commandline ("noibrs") and through the proc interface /proc/sys/kernel/ibrs_enabled. This commit simplifies the current (probably broken) implementation by merging it with all the IBRS-related upstream changes from previous commits. What we have now is the upstream implementation for detecting the presence of IBRS support. This commit adds a global state variable 'ibrs_enabled' which is set to 1 if the CPU supports IBRS but can be overridden via the commandline "noibrs" switch or by writting 0, 1 or 2 to /proc/sys/kernel/ibrs_enabled at runtime. Note that the runtime controls are disabled if the CPU runs in Enhanced IBRS mode. CVE-2017-5715 Signed-off-by:Juerg Haefliger <juergh@canonical.com> Acked-by:
Stefan Bader <stefan.bader@canonical.com> Acked-by:
Kleber Sacilotto de Souza <kleber.souza@canonical.com> Signed-off-by:
-
Juerg Haefliger authored
In Ubuntu, we have runtime control for enabling/disabling IBPB via the commandline ("noibpb") and through the proc interface /proc/sys/kernel/ibpb_enabled. This commit simplifies the current (broken) implementation by merging it with all the IBPB-related upstream changes from previous commits. What we have now is the upstream implementation for detecting the presence of IBPB support which is used in the alternative MSR write in indirect_branch_prediction_barrier() to enable IBPB. On top of that, this commit adds a global state variable 'ibpb_enabled' which is set to 1 if the CPU supports IBPB but can be overridden via the commandline "noibpb" switch or by writting 0 or 1 to /proc/sys/kernel/ibpb_enabled at runtime. If ibpb_enabled is 0, indirect_branch_prediction_barrier() is turned into a no-op, same as if the platform doesn't support IBPB. CVE-2017-5715 Signed-off-by: -
Greg Kroah-Hartman authored
BugLink: https://bugs.launchpad.net/bugs/1811077Signed-off-by:
-
Emmanuel Grumbach authored
BugLink: https://bugs.launchpad.net/bugs/1811077 commit 990d7184 upstream. NullFunc packets should never be duplicate just like QoS-NullFunc packets. We saw a client that enters / exits power save with NullFunc frames (and not with QoS-NullFunc) despite the fact that the association supports HT. This specific client also re-uses a non-zero sequence number for different NullFunc frames. At some point, the client had to send a retransmission of the NullFunc frame and we dropped it, leading to a misalignment in the power save state. Fix this by never consider a NullFunc frame as duplicate, just like we do for QoS NullFunc frames. This fixes https://bugzilla.kernel.org/show_bug.cgi?id=201449 CC: <stable@vger.kernel.org> Signed-off-by:
Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
-
Felix Fietkau authored
BugLink: https://bugs.launchpad.net/bugs/1811077 commit 9ec1190d upstream. If the buffered broadcast queue contains packets, letting new packets bypass that queue can lead to heavy reordering, since the driver is probably throttling transmission of buffered multicast packets after beacons. Keep buffering packets until the buffer has been cleared (and no client is in powersave mode). Cc: stable@vger.kernel.org Signed-off-by:
Felix Fietkau <nbd@nbd.name> Signed-off-by:
-
Felix Fietkau authored
BugLink: https://bugs.launchpad.net/bugs/1811077 commit a317e65f upstream. Make it behave like regular ieee80211_tx_status calls, except for the lack of filtered frame processing. This fixes spurious low-ack triggered disconnections with powersave clients connected to an AP. Fixes: f027c2ac ("mac80211: add ieee80211_tx_status_noskb") Cc: stable@vger.kernel.org Signed-off-by:
-
Ben Greear authored
BugLink: https://bugs.launchpad.net/bugs/1811077 commit 5c21e810 upstream. This fixes stale beacon-int values that would keep a netdev from going up. To reproduce: Create two VAP on one radio. vap1 has beacon-int 100, start it. vap2 has beacon-int 240, start it (and it will fail because beacon-int mismatch). reconfigure vap2 to have beacon-int 100 and start it. It will fail because the stale beacon-int 240 will be used in the ifup path and hostapd never gets a chance to set the new beacon interval. Cc: stable@vger.kernel.org Signed-off-by:
Ben Greear <greearb@candelatech.com> Signed-off-by:
-
Vasyl Vavrychuk authored
BugLink: https://bugs.launchpad.net/bugs/1811077 commit a1881c9b upstream. Otherwise if network manager starts configuring Wi-Fi interface immidiatelly after getting notification of its creation, we will get NULL pointer dereference: BUG: unable to handle kernel NULL pointer dereference at (null) IP: [<ffffffff95ae94c8>] hrtimer_active+0x28/0x50 ... Call Trace: [<ffffffff95ae9997>] ? hrtimer_try_to_cancel+0x27/0x110 [<ffffffff95ae9a95>] ? hrtimer_cancel+0x15/0x20 [<ffffffffc0803bf0>] ? mac80211_hwsim_config+0x140/0x1c0 [mac80211_hwsim] Cc: stable@vger.kernel.org Signed-off-by:
Vasyl Vavrychuk <vasyl.vavrychuk@globallogic.com> Signed-off-by:
-
Macpaul Lin authored
BugLink: https://bugs.launchpad.net/bugs/1811077 commit dada6a43 upstream. This patch is trying to fix KE issue due to "BUG: KASAN: global-out-of-bounds in param_set_kgdboc_var+0x194/0x198" reported by Syzkaller scan." [26364:syz-executor0][name:report8t]BUG: KASAN: global-out-of-bounds in param_set_kgdboc_var+0x194/0x198 [26364:syz-executor0][name:report&]Read of size 1 at addr ffffff900e44f95f by task syz-executor0/26364 [26364:syz-executor0][name:report&] [26364:syz-executor0]CPU: 7 PID: 26364 Comm: syz-executor0 Tainted: G W 0 [26364:syz-executor0]Call trace: [26364:syz-executor0][<ffffff9008095cf8>] dump_bacIctrace+Ox0/0x470 [26364:syz-executor0][<ffffff9008096de0>] show_stack+0x20/0x30 [26364:syz-executor0][<ffffff90089cc9c8>] dump_stack+Oxd8/0x128 [26364:syz-executor0][<ffffff90084edb38>] print_address_description +0x80/0x4a8 [26364:syz-executor0][<ffffff90084ee270>] kasan_report+Ox178/0x390 [26364:syz-executor0][<ffffff90084ee4a0>] _asan_report_loadi_noabort+Ox18/0x20 [26364:syz-executor0][<ffffff9008b092ac>] param_set_kgdboc_var+Ox194/0x198 [26364:syz-executor0][<ffffff900813af64>] param_attr_store+Ox14c/0x270 [26364:syz-executor0][<ffffff90081394c8>] module_attr_store+0x60/0x90 [26364:syz-executor0][<ffffff90086690c0>] sysfs_kl_write+Ox100/0x158 [26364:syz-executor0][<ffffff9008666d84>] kernfs_fop_write+0x27c/0x3a8 [26364:syz-executor0][<ffffff9008508264>] do_loop_readv_writev+0x114/0x1b0 [26364:syz-executor0][<ffffff9008509ac8>] do_readv_writev+0x4f8/0x5e0 [26364:syz-executor0][<ffffff9008509ce4>] vfs_writev+0x7c/Oxb8 [26364:syz-executor0][<ffffff900850ba64>] SyS_writev+Oxcc/0x208 [26364:syz-executor0][<ffffff90080883f0>] elO_svc_naked +0x24/0x28 [26364:syz-executor0][name:report&] [26364:syz-executor0][name:report&]The buggy address belongs to the variable: [26364:syz-executor0][name:report&] kgdb_tty_line+Ox3f/0x40 [26364:syz-executor0][name:report&] [26364:syz-executor0][name:report&]Memory state around the buggy address: [26364:syz-executor0] ffffff900e44f800: 00 00 00 00 00 04 fa fa fa fa fa fa 00 fa fa fa [26364:syz-executor0] ffffff900e44f880: fa fa fa fa 00 fa fa fa fa fa fa fa 00 fa fa fa [26364:syz-executor0]> ffffff900e44f900: fa fa fa fa 04 fa fa fa fa fa fa fa 00 00 00 00 [26364:syz-executor0][name:report&] ^ [26364:syz-executor0] ffffff900e44f980: 00 fa fa fa fa fa fa fa 04 fa fa fa fa fa fa fa [26364:syz-executor0] ffffff900e44fa00: 04 fa fa fa fa fa fa fa 00 fa fa fa fa fa fa fa [26364:syz-executor0][name:report&] [26364:syz-executor0][name:panic&]Disabling lock debugging due to kernel taint [26364:syz-executor0]------------[cut here]------------ After checking the source code, we've found there might be an out-of-bounds access to "config[len - 1]" array when the variable "len" is zero. Signed-off-by:
Macpaul Lin <macpaul@gmail.com> Acked-by:
Daniel Thompson <daniel.thompson@linaro.org> Cc: stable <stable@vger.kernel.org> Signed-off-by:
-
Peter Shih authored
BugLink: https://bugs.launchpad.net/bugs/1811077 commit 100bc3e2 upstream. serial8250_register_8250_port calls uart_config_port, which calls config_port on the port before it tries to power on the port. So we need the port to be on before calling serial8250_register_8250_port. Change the code to always do a runtime resume in probe before registering port, and always do a runtime suspend in remove. This basically reverts the change in commit 68e5fc4a ("tty: serial: 8250_mtk: use pm_runtime callbacks for enabling"), but still use pm_runtime callbacks. Fixes: 68e5fc4a ("tty: serial: 8250_mtk: use pm_runtime callbacks for enabling") Signed-off-by:
Peter Shih <pihsun@chromium.org> Cc: stable <stable@vger.kernel.org> Signed-off-by:
-
Paulo Alcantara authored
BugLink: https://bugs.launchpad.net/bugs/1811077 commit c988de29 upstream. Make sure to use the CIFS_DIR_SEP(cifs_sb) as path separator for prefixpath too. Fixes a bug with smb1 UNIX extensions. Fixes: a6b5058f ("fs/cifs: make share unaccessible at root level mountable") Signed-off-by:
Paulo Alcantara <palcantara@suse.com> Reviewed-by:
Aurelien Aptel <aaptel@suse.com> Signed-off-by:
Steve French <stfrench@microsoft.com> CC: Stable <stable@vger.kernel.org> Signed-off-by:
-
Greg Kroah-Hartman authored
BugLink: https://bugs.launchpad.net/bugs/1811077 [for older kernels only, lustre has been removed from upstream] When someone writes: strncpy(dest, source, sizeof(source)); they really are just doing the same thing as: strcpy(dest, source); but somehow they feel better because they are now using the "safe" version of the string functions. Cargo-cult programming at its finest... gcc-8 rightfully warns you about doing foolish things like this. Now that the stable kernels are all starting to be built using gcc-8, let's get rid of this warning so that we do not have to gaze at this horror. To dropt the warning, just convert the code to using strcpy() so that if someone really wants to audit this code and find all of the obvious problems, it will be easier to do so. Signed-off-by:
-
Mathias Nyman authored
BugLink: https://bugs.launchpad.net/bugs/1811077 commit 0472bf06 upstream. Don't allow USB3 U1 or U2 if the latency to wake up from the U-state reaches the service interval for a periodic endpoint. This is according to xhci 1.1 specification section 4.23.5.2 extra note: "Software shall ensure that a device is prevented from entering a U-state where its worst case exit latency approaches the ESIT." Allowing too long exit latencies for periodic endpoint confuses xHC internal scheduling, and new devices may fail to enumerate with a "Not enough bandwidth for new device state" error from the host. Cc: <stable@vger.kernel.org> Signed-off-by:
Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by:
-
Chuck Lever authored
BugLink: https://bugs.launchpad.net/bugs/1811077 commit 8dae5398 upstream. call_encode can be invoked more than once per RPC call. Ensure that each call to gss_wrap_req_priv does not overwrite pointers to previously allocated memory. Signed-off-by:
Chuck Lever <chuck.lever@oracle.com> Cc: stable@kernel.org Signed-off-by:
Trond Myklebust <trond.myklebust@hammerspace.com> Signed-off-by:
-
Halil Pasic authored
BugLink: https://bugs.launchpad.net/bugs/1811077 commit 78b1a52e upstream. While ccw_io_helper() seems like intended to be exclusive in a sense that it is supposed to facilitate I/O for at most one thread at any given time, there is actually nothing ensuring that threads won't pile up at vcdev->wait_q. If they do, all threads get woken up and see the status that belongs to some other request than their own. This can lead to bugs. For an example see: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1788432 This race normally does not cause any problems. The operations provided by struct virtio_config_ops are usually invoked in a well defined sequence, normally don't fail, and are normally used quite infrequent too. Yet, if some of the these operations are directly triggered via sysfs attributes, like in the case described by the referenced bug, userspace is given an opportunity to force races by increasing the frequency of the given operations. Let us fix the problem by ensuring, that for each device, we finish processing the previous request before starting with a new one. Signed-off-by:
Halil Pasic <pasic@linux.ibm.com> Reported-by:
Colin Ian King <colin.king@canonical.com> Cc: stable@vger.kernel.org Message-Id: <20180925121309.58524-3-pasic@linux.ibm.com> Signed-off-by:
Cornelia Huck <cohuck@redhat.com> Signed-off-by:
Michael S. Tsirkin <mst@redhat.com> Signed-off-by:
-
Halil Pasic authored
BugLink: https://bugs.launchpad.net/bugs/1811077 commit 2448a299 upstream. Currently we have a race on vcdev->config in virtio_ccw_get_config() and in virtio_ccw_set_config(). This normally does not cause problems, as these are usually infrequent operations. However, for some devices writing to/reading from the config space can be triggered through sysfs attributes. For these, userspace can force the race by increasing the frequency. Signed-off-by:
-
Takashi Iwai authored
BugLink: https://bugs.launchpad.net/bugs/1811077 commit 5363857b upstream. As addressed in alsa-lib (commit b420056604f0), we need to fix the case where the evaluation of PCM interval "(x x+1]" leading to -EINVAL. After applying rules, such an interval may be translated as "(x x+1)". Fixes: ff2d6acd ("ALSA: pcm: Fix snd_interval_refine first/last with open min/max") Cc: <stable@vger.kernel.org> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Takashi Iwai authored
BugLink: https://bugs.launchpad.net/bugs/1811077 commit b51abed8 upstream. Currently the PCM core calls snd_pcm_unlink() always unconditionally at closing a stream. However, since snd_pcm_unlink() invokes the global rwsem down, the lock can be easily contended. More badly, when a thread runs in a high priority RT-FIFO, it may stall at spinning. Basically the call of snd_pcm_unlink() is required only for the linked streams that are already rare occasion. For normal use cases, this code path is fairly superfluous. As an optimization (and also as a workaround for the RT problem above in normal situations without linked streams), this patch adds a check before calling snd_pcm_unlink() and calls it only when needed. Reported-by:
Chanho Min <chanho.min@lge.com> Cc: <stable@vger.kernel.org> Signed-off-by:
-
Chanho Min authored
BugLink: https://bugs.launchpad.net/bugs/1811077 commit b888a5f7 upstream. Commit 67ec1072 ("ALSA: pcm: Fix rwsem deadlock for non-atomic PCM stream") fixes deadlock for non-atomic PCM stream. But, This patch causes antother stuck. If writer is RT thread and reader is a normal thread, the reader thread will be difficult to get scheduled. It may not give chance to release readlocks and writer gets stuck for a long time if they are pinned to single cpu. The deadlock described in the previous commit is because the linux rwsem queues like a FIFO. So, we might need non-FIFO writelock, not non-block one. My suggestion is that the writer gives reader a chance to be scheduled by using the minimum msleep() instaed of spinning without blocking by writer. Also, The *_nonblock may be changed to *_nonfifo appropriately to this concept. In terms of performance, when trylock is failed, this minimum periodic msleep will have the same performance as the tick-based schedule()/wake_up_q(). [ Although this has a fairly high performance penalty, the relevant code path became already rare due to the previous commit ("ALSA: pcm: Call snd_pcm_unlink() conditionally at closing"). That is, now this unconditional msleep appears only when using linked streams, and this must be a rare case. So we accept this as a quick workaround until finding a more suitable one -- tiwai ] Fixes: 67ec1072 ("ALSA: pcm: Fix rwsem deadlock for non-atomic PCM stream") Suggested-by:
Wonmin Jung <wonmin.jung@lge.com> Signed-off-by:
-
Kai-Heng Feng authored
BugLink: https://bugs.launchpad.net/bugs/1811077 commit 3deef52c upstream. It's similar to other AMD audio devices, it also supports D3, which can save some power drain. Signed-off-by:
Kai-Heng Feng <kai.heng.feng@canonical.com> Cc: <stable@vger.kernel.org> Signed-off-by:
-
Hui Peng authored
BugLink: https://bugs.launchpad.net/bugs/1811077 commit 5f8cf712 upstream. If a USB sound card reports 0 interfaces, an error condition is triggered and the function usb_audio_probe errors out. In the error path, there was a use-after-free vulnerability where the memory object of the card was first freed, followed by a decrement of the number of active chips. Moving the decrement above the atomic_dec fixes the UAF. [ The original problem was introduced in 3.1 kernel, while it was developed in a different form. The Fixes tag below indicates the original commit but it doesn't mean that the patch is applicable cleanly. -- tiwai ] Fixes: 362e4e49 ("ALSA: usb-audio - clear chip->probing on error exit") Reported-by:
Hui Peng <benquike@gmail.com> Reported-by:
Mathias Payer <mathias.payer@nebelwelt.net> Signed-off-by:
-
Mathias Payer authored
BugLink: https://bugs.launchpad.net/bugs/1811077 commit 704620af upstream. When reading an extra descriptor, we need to properly check the minimum and maximum size allowed, to prevent from invalid data being sent by a device. Reported-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Alexander Theissen authored
BugLink: https://bugs.launchpad.net/bugs/1811077 commit d7859905 upstream. Add another Apple Cinema Display to the list of supported displays. Signed-off-by:
Alexander Theissen <alex.theissen@me.com> Cc: stable <stable@vger.kernel.org> Signed-off-by:
-
Harry Pan authored
BugLink: https://bugs.launchpad.net/bugs/1811077 commit 2f2dde6b upstream. Some lower volume SanDisk Ultra Flair in 16GB, which the VID:PID is in 0781:5591, will aggressively request LPM of U1/U2 during runtime, when using this thumb drive as the OS installation key we found the device will generate failure during U1 exit path making it dropped from the USB bus, this causes a corrupted installation in system at the end. i.e., [ 166.918296] hub 2-0:1.0: state 7 ports 7 chg 0000 evt 0004 [ 166.918327] usb usb2-port2: link state change [ 166.918337] usb usb2-port2: do warm reset [ 166.970039] usb usb2-port2: not warm reset yet, waiting 50ms [ 167.022040] usb usb2-port2: not warm reset yet, waiting 200ms [ 167.276043] usb usb2-port2: status 02c0, change 0041, 5.0 Gb/s [ 167.276050] usb 2-2: USB disconnect, device number 2 [ 167.276058] usb 2-2: unregistering device [ 167.276060] usb 2-2: unregistering interface 2-2:1.0 [ 167.276170] xhci_hcd 0000:00:15.0: shutdown urb ffffa3c7cc695cc0 ep1in-bulk [ 167.284055] sd 0:0:0:0: [sda] tag#0 FAILED Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK [ 167.284064] sd 0:0:0:0: [sda] tag#0 CDB: Read(10) 28 00 00 33 04 90 00 01 00 00 ... Analyzed the USB trace in the link layer we realized it is because of the 6-ms timer of tRecoveryConfigurationTimeout which documented on the USB 3.2 Revision 1.0, the section 7.5.10.4.2 of "Exit from Recovery.Configuration"; device initiates U1 exit -> Recovery.Active -> Recovery.Configuration, then the host timer timeout makes the link transits to eSS.Inactive -> Rx.Detect follows by a Warm Reset. Interestingly, the other higher volume of SanDisk Ultra Flair sharing the same VID:PID, such as 64GB, would not request LPM during runtime, it sticks at U0 always, thus disabling LPM does not affect those thumb drives at all. The same odd occures in SanDisk Ultra Fit 16GB, VID:PID in 0781:5583. Signed-off-by:
Harry Pan <harry.pan@intel.com> Cc: stable <stable@vger.kernel.org> Signed-off-by:
-
Yangtao Li authored
BugLink: https://bugs.launchpad.net/bugs/1811077 [ Upstream commit c44c749d ] of_find_node_by_path() acquires a reference to the node returned by it and that reference needs to be dropped by its caller. This place doesn't do that, so fix it. 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> Signed-off-by:
-
Pan Bian authored
BugLink: https://bugs.launchpad.net/bugs/1811077 [ Upstream commit 829383e1 ] memunmap() should be used to free the return of memremap(), not iounmap(). Fixes: dfddb969 ('iommu/vt-d: Switch from ioremap_cache to memremap') Signed-off-by:
Pan Bian <bianpan2016@163.com> Signed-off-by:
Joerg Roedel <jroedel@suse.de> Signed-off-by:
-
Vincent Chen authored
BugLink: https://bugs.launchpad.net/bugs/1811077 [ Upstream commit 426a593e ] In the original ftmac100_interrupt(), the interrupts are only disabled when the condition "netif_running(netdev)" is true. However, this condition causes kerenl hang in the following case. When the user requests to disable the network device, kernel will clear the bit __LINK_STATE_START from the dev->state and then call the driver's ndo_stop function. Network device interrupts are not blocked during this process. If an interrupt occurs between clearing __LINK_STATE_START and stopping network device, kernel cannot disable the interrupts due to the condition "netif_running(netdev)" in the ISR. Hence, kernel will hang due to the continuous interruption of the network device. In order to solve the above problem, the interrupts of the network device should always be disabled in the ISR without being restricted by the condition "netif_running(netdev)". [V2] Remove unnecessary curly braces. Signed-off-by:
Vincent Chen <vincentc@andestech.com> Signed-off-by:
-
Aya Levin authored
BugLink: https://bugs.launchpad.net/bugs/1811077 [ Upstream commit a463146e ] UBSAN: Undefined behavior in drivers/net/ethernet/mellanox/mlx4/resource_tracker.c:626:29 signed integer overflow: 1802201963 + 1802201963 cannot be represented in type 'int' The union of res_reserved and res_port_rsvd[MLX4_MAX_PORTS] monitors granting of reserved resources. The grant operation is calculated and protected, thus both members of the union cannot be negative. Changed type of res_reserved and of res_port_rsvd[MLX4_MAX_PORTS] from signed int to unsigned int, allowing large value. Fixes: 5a0d0a61 ("mlx4: Structures and init/teardown for VF resource quotas") Signed-off-by:
Aya Levin <ayal@mellanox.com> Signed-off-by:
Tariq Toukan <tariqt@mellanox.com> Signed-off-by:
-
Tariq Toukan authored
BugLink: https://bugs.launchpad.net/bugs/1811077 [ Upstream commit 3ea7e7ea ] Initialize the uid variable to zero to avoid the compilation warning. Fixes: 7a89399f ("net/mlx4: Add mlx4_bitmap zone allocator") Signed-off-by:
-
Jack Morgenstein authored
BugLink: https://bugs.launchpad.net/bugs/1811077 [ Upstream commit bd85fbc2 ] When re-registering a user mr, the mpt information for the existing mr when running SRIOV is obtained via the QUERY_MPT fw command. The returned information includes the mpt's lkey. This retrieved mpt information is used to move the mpt back to hardware ownership in the rereg flow (via the SW2HW_MPT fw command when running SRIOV). The fw API spec states that for SW2HW_MPT, the lkey field must be zero. Any ConnectX-3 PF driver which checks for strict spec adherence will return failure for SW2HW_MPT if the lkey field is not zero (although the fw in practice ignores this field for SW2HW_MPT). Thus, in order to conform to the fw API spec, set the lkey field to zero before invoking SW2HW_MPT when running SRIOV. Fixes: e630664c ("mlx4_core: Add helper functions to support MR re-registration") Signed-off-by:
Jack Morgenstein <jackm@dev.mellanox.co.il> Signed-off-by:
-
Denis Bolotin authored
BugLink: https://bugs.launchpad.net/bugs/1811077 [ Upstream commit ed4eac20 ] The value of "sb_index" is written by the hardware. Reading its value and writing it to "index" must finish before checking the loop condition. Signed-off-by:
Denis Bolotin <denis.bolotin@cavium.com> Signed-off-by:
Michal Kalderon <michal.kalderon@cavium.com> Signed-off-by:
-
Denis Bolotin authored
BugLink: https://bugs.launchpad.net/bugs/1811077 [ Upstream commit 9aaa4e8b ] Release PTT before entering error flow. Signed-off-by:
-
Sudarsana Reddy Kalluru authored
BugLink: https://bugs.launchpad.net/bugs/1811077 [ Upstream commit 77e461d1 ] Driver assigns DMAE channel 0 for FW as part of START_RAMROD command. FW uses this channel for DMAE operations (e.g., TIME_SYNC implementation). Driver also uses the same channel 0 for DMAE operations for some of the PFs (e.g., PF0 on Port0). This could lead to concurrent access to the DMAE channel by FW and driver which is not legal. Hence need to assign unique DMAE id for FW. Currently following DMAE channels are used by the clients, MFW - OCBB/OCSD functionality uses DMAE channel 14/15 Driver 0-3 and 8-11 (for PF dmae operations) 4 and 12 (for stats requests) Assigning unique dmae_id '13' to the FW. Changes from previous version: ------------------------------ v2: Incorporated the review comments. Signed-off-by:
Sudarsana Reddy Kalluru <Sudarsana.Kalluru@cavium.com> Signed-off-by:
-
Sven Eckelmann authored
BugLink: https://bugs.launchpad.net/bugs/1811077 [ Upstream commit d7d8bbb4 ] The complete size ("total_size") of the fragmented packet is stored in the fragment header and in the size of the fragment chain. When the fragments are ready for merge, the skbuff's tail of the first fragment is expanded to have enough room after the data pointer for at least total_size. This means that it gets expanded by total_size - first_skb->len. But this is ignoring the fact that after expanding the buffer, the fragment header is pulled by from this buffer. Assuming that the tailroom of the buffer was already 0, the buffer after the data pointer of the skbuff is now only total_size - len(fragment_header) large. When the merge function is then processing the remaining fragments, the code to copy the data over to the merged skbuff will cause an skb_over_panic when it tries to actually put enough data to fill the total_size bytes of the packet. The size of the skb_pull must therefore also be taken into account when the buffer's tailroom is expanded. Fixes: 610bfc6b ("batman-adv: Receive fragmented packets and merge") Reported-by:
Martin Weinelt <martin@darmstadt.freifunk.net> Co-authored-by:
Linus Lüssing <linus.luessing@c0d3.blue> Signed-off-by:
Sven Eckelmann <sven@narfation.org> Signed-off-by:
Simon Wunderlich <sw@simonwunderlich.de> Signed-off-by:
-
Fabrizio Castro authored
BugLink: https://bugs.launchpad.net/bugs/1811077 [ Upstream commit 68c8d209 ] Assigning 2 to "renesas,can-clock-select" tricks the driver into registering the CAN interface, even though we don't want that. This patch improves one of the checks to prevent that from happening. Fixes: 862e2b6a ("can: rcar_can: support all input clocks") Signed-off-by:
Fabrizio Castro <fabrizio.castro@bp.renesas.com> Signed-off-by:
Chris Paterson <Chris.Paterson2@renesas.com> Reviewed-by:
Simon Horman <horms+renesas@verge.net.au> Signed-off-by:
Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by:
-
Geert Uytterhoeven authored
BugLink: https://bugs.launchpad.net/bugs/1811077 [ Upstream commit e5b78f2e ] If iommu_ops.add_device() fails, iommu_ops.domain_free() is still called, leading to a crash, as the domain was only partially initialized: ipmmu-vmsa e67b0000.mmu: Cannot accommodate DMA translation for IOMMU page tables sata_rcar ee300000.sata: Unable to initialize IPMMU context iommu: Failed to add device ee300000.sata to group 0: -22 Unable to handle kernel NULL pointer dereference at virtual address 0000000000000038 ... Call trace: ipmmu_domain_free+0x1c/0xa0 iommu_group_release+0x48/0x68 kobject_put+0x74/0xe8 kobject_del.part.0+0x3c/0x50 kobject_put+0x60/0xe8 iommu_group_get_for_dev+0xa8/0x1f0 ipmmu_add_device+0x1c/0x40 of_iommu_configure+0x118/0x190 Fix this by checking if the domain's context already exists, before trying to destroy it. Signed-off-by:
Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by:
Robin Murphy <robin.murphy@arm.com> Fixes: d25a2a16 ('iommu: Add driver for Renesas VMSA-compatible IPMMU') Signed-off-by:
-
Lu Baolu authored
BugLink: https://bugs.launchpad.net/bugs/1811077 [ Upstream commit 19ed3e2d ] When handling page request without pasid event, go to "no_pasid" branch instead of "bad_req". Otherwise, a NULL pointer deference will happen there. Cc: Ashok Raj <ashok.raj@intel.com> Cc: Jacob Pan <jacob.jun.pan@linux.intel.com> Cc: Sohil Mehta <sohil.mehta@intel.com> Signed-off-by:
Lu Baolu <baolu.lu@linux.intel.com> Fixes: a222a7f0 'iommu/vt-d: Implement page request handling' Signed-off-by:
-
Arnd Bergmann authored
BugLink: https://bugs.launchpad.net/bugs/1811077 commit 7661ca09 upstream. gcc-8 points out two comparisons that are clearly bogus and almost certainly not what the author intended to write: drivers/usb/gadget/udc/dummy_hcd.c: In function 'set_link_state_by_speed': drivers/usb/gadget/udc/dummy_hcd.c:379:31: error: bitwise comparison always evaluates to false [-Werror=tautological-compare] USB_PORT_STAT_ENABLE) == 1 && ^~ drivers/usb/gadget/udc/dummy_hcd.c:381:25: error: bitwise comparison always evaluates to false [-Werror=tautological-compare] USB_SS_PORT_LS_U0) == 1 && ^~ I looked at the code for a bit and came up with a change that makes it look like what the author probably meant here. This makes it look reasonable to me and to gcc, shutting up the warning. It does of course change behavior as the two conditions are actually evaluated rather than being hardcoded to false, and I have made no attempt at verifying that the changed logic makes sense in the context of a USB HCD, so that part needs to be reviewed carefully. Fixes: 1cd8fd28 ("usb: gadget: dummy_hcd: add SuperSpeed support") Cc: Tatyana Brokhman <tlinder@codeaurora.org> Cc: Felipe Balbi <balbi@kernel.org> Acked-by:
Alan Stern <stern@rowland.harvard.edu> Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
Felipe Balbi <felipe.balbi@linux.intel.com> Signed-off-by:
-
Pavel Tikhomirov authored
BugLink: https://bugs.launchpad.net/bugs/1811077 commit 6ff38bd4 upstream. If all pages are deleted from the mapping by memory reclaim and also moved to the cleancache: __delete_from_page_cache (no shadow case) unaccount_page_cache_page cleancache_put_page page_cache_delete mapping->nrpages -= nr (nrpages becomes 0) We don't clean the cleancache for an inode after final file truncation (removal). truncate_inode_pages_final check (nrpages || nrexceptional) is false no truncate_inode_pages no cleancache_invalidate_inode(mapping) These way when reading the new file created with same inode we may get these trash leftover pages from cleancache and see wrong data instead of the contents of the new file. Fix it by always doing truncate_inode_pages which is already ready for nrpages == 0 && nrexceptional == 0 case and just invalidates inode. [akpm@linux-foundation.org: add comment, per Jan] Link: http://lkml.kernel.org/r/20181112095734.17979-1-ptikhomirov@virtuozzo.com Fixes: commit 91b0abe3 ("mm + fs: store shadow entries in page cache") Signed-off-by:
Pavel Tikhomirov <ptikhomirov@virtuozzo.com> Reviewed-by:
Vasily Averin <vvs@virtuozzo.com> Reviewed-by:
Andrey Ryabinin <aryabinin@virtuozzo.com> Reviewed-by:
Jan Kara <jack@suse.cz> Cc: Johannes Weiner <hannes@cmpxchg.org> Cc: Mel Gorman <mgorman@techsingularity.net> Cc: Matthew Wilcox <willy@infradead.org> Cc: Andi Kleen <ak@linux.intel.com> Cc: <stable@vger.kernel.org> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
-
Alexey Brodkin authored
BugLink: https://bugs.launchpad.net/bugs/1811077 commit 6b04114f upstream. By default NFSv3 doesn't support ACL (Access Control Lists) which might be quite convenient to have so that mounted NFS behaves exactly as any other local file-system. In particular missing support of ACL makes umask useless. This among other thigs fixes Glibc's "nptl/tst-umask1". Signed-off-by:
Alexey Brodkin <abrodkin@synopsys.com> Cc: Cupertino Miranda <cmiranda@synopsys.com> Cc: stable@vger.kernel.org #4.14+ Signed-off-by:
Vineet Gupta <vgupta@synopsys.com> Signed-off-by:
-
