- May 10, 2020
-
-
Matt Roper authored
commit 1e1a139d upstream. WaDisableDARBFClkGating, now known as Wa_14010480278, has been added to the workaround tables for ICL, EHL, and TGL so we need to extend our platform test accordingly. Bspec: 33450 Bspec: 33451 Bspec: 52890 Cc: stable@kernel.vger.org Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Matt Atwood <matthew.s.atwood@intel.com> Cc: Radhakrishna Sripada <radhakrishna.sripada@intel.com> Signed-off-by:
Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191224012026.3157766-2-matthew.d.roper@intel.com Reviewed-by:
Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Doug Berger authored
[ Upstream commit 3554e54a ] The driver is designed to drop Rx packets and reclaim the buffers when an allocation fails, and the network interface needs to safely handle this packet loss. Therefore, an allocation failure of Rx SKBs is relatively benign. However, the output of the warning message occurs with a high scheduling priority that can cause excessive jitter/latency for other high priority processing. This commit suppresses the warning messages to prevent scheduling problems while retaining the failure count in the statistics of the network interface. Signed-off-by:
Doug Berger <opendmb@gmail.com> Acked-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Doug Berger authored
[ Upstream commit ecaeceb8 ] The driver is designed to drop Rx packets and reclaim the buffers when an allocation fails, and the network interface needs to safely handle this packet loss. Therefore, an allocation failure of Rx SKBs is relatively benign. However, the output of the warning message occurs with a high scheduling priority that can cause excessive jitter/latency for other high priority processing. This commit suppresses the warning messages to prevent scheduling problems while retaining the failure count in the statistics of the network interface. Signed-off-by:
-
Madhuparna Bhowmik authored
[ Upstream commit 8ca47eb9 ] The function sta_info_get_by_idx() uses RCU list primitive. It is called with local->sta_mtx held from mac80211/cfg.c. Add lockdep expression to avoid any false positive RCU list warnings. Signed-off-by:
Madhuparna Bhowmik <madhuparnabhowmik10@gmail.com> Link: https://lore.kernel.org/r/20200409082906.27427-1-madhuparnabhowmik10@gmail.com Signed-off-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
-
Nathan Chancellor authored
[ Upstream commit 5990cdee ] 0day reports over and over on an powerpc randconfig with clang: lib/mpi/generic_mpih-mul1.c:37:13: error: invalid use of a cast in a inline asm context requiring an l-value: remove the cast or build with -fheinous-gnu-extensions Remove the superfluous casts, which have been done previously for x86 and arm32 in commit dea632ca ("lib/mpi: fix build with clang") and commit 7b7c1df2 ("lib/mpi/longlong.h: fix building with 32-bit x86"). Reported-by:
kbuild test robot <lkp@intel.com> Signed-off-by:
Nathan Chancellor <natechancellor@gmail.com> Acked-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
Michael Ellerman <mpe@ellerman.id.au> Link: https://github.com/ClangBuiltLinux/linux/issues/991 Link: https://lore.kernel.org/r/20200413195041.24064-1-natechancellor@gmail.com Signed-off-by:
-
Vamshi K Sthambamkadi authored
[ Upstream commit 9da73974 ] kmemleak report 1: [<9092c50b>] kmem_cache_alloc_trace+0x138/0x270 [<05a2c9ed>] create_field_var+0xcf/0x180 [<528a2d68>] action_create+0xe2/0xc80 [<63f50b61>] event_hist_trigger_func+0x15b5/0x1920 [<28ea5d3d>] trigger_process_regex+0x7b/0xc0 [<3138e86f>] event_trigger_write+0x4d/0xb0 [<ffd66c19>] __vfs_write+0x30/0x200 [<4f424a0d>] vfs_write+0x96/0x1b0 [<da59a290>] ksys_write+0x53/0xc0 [<3717101a>] __ia32_sys_write+0x15/0x20 [<c5f23497>] do_fast_syscall_32+0x70/0x250 [<46e2629c>] entry_SYSENTER_32+0xaf/0x102 This is because save_vars[] of struct hist_trigger_data are not destroyed kmemleak report 2: [<9092c50b>] kmem_cache_alloc_trace+0x138/0x270 [<6e5e97c5>] create_var+0x3c/0x110 [<de82f1b9>] create_field_var+0xaf/0x180 [<528a2d68>] action_create+0xe2/0xc80 [<63f50b61>] event_hist_trigger_func+0x15b5/0x1920 [<28ea5d3d>] trigger_process_regex+0x7b/0xc0 [<3138e86f>] event_trigger_write+0x4d/0xb0 [<ffd66c19>] __vfs_write+0x30/0x200 [<4f424a0d>] vfs_write+0x96/0x1b0 [<da59a290>] ksys_write+0x53/0xc0 [<3717101a>] __ia32_sys_write+0x15/0x20 [<c5f23497>] do_fast_syscall_32+0x70/0x250 [<46e2629c>] entry_SYSENTER_32+0xaf/0x102 struct hist_field allocated through create_var() do not initialize "ref" field to 1. The code in __destroy_hist_field() does not destroy object if "ref" is initialized to zero, the condition if (--hist_field->ref > 1) always passes since unsigned int wraps. kmemleak report 3: [<f8666fcc>] __kmalloc_track_caller+0x139/0x2b0 [<bb7f80a5>] kstrdup+0x27/0x50 [<39d70006>] init_var_ref+0x58/0xd0 [<8ca76370>] create_var_ref+0x89/0xe0 [<f045fc39>] action_create+0x38f/0xc80 [<7c146821>] event_hist_trigger_func+0x15b5/0x1920 [<07de3f61>] trigger_process_regex+0x7b/0xc0 [<e87daf8f>] event_trigger_write+0x4d/0xb0 [<19bf1512>] __vfs_write+0x30/0x200 [<64ce4d27>] vfs_write+0x96/0x1b0 [<a6f34170>] ksys_write+0x53/0xc0 [<7d4230cd>] __ia32_sys_write+0x15/0x20 [<8eadca00>] do_fast_syscall_32+0x70/0x250 [<235cf985>] entry_SYSENTER_32+0xaf/0x102 hist_fields (system & event_name) are not freed Link: http://lkml.kernel.org/r/20200422061503.GA5151@cosmos Signed-off-by:
Vamshi K Sthambamkadi <vamshi.k.sthambamkadi@gmail.com> Signed-off-by:
Steven Rostedt (VMware) <rostedt@goodmis.org> Signed-off-by:
-
Paulo Alcantara authored
[ Upstream commit 65303de8 ] This disables tcon re-use for DFS shares. tcon->dfs_path stores the path that the tcon should connect to when doing failing over. If that tcon is used multiple times e.g. 2 mounts using it with different prefixpath, each will need a different dfs_path but there is only one tcon. The other solution would be to split the tcon in 2 tcons during failover but that is much harder. tcons could not be shared with DFS in cifs.ko because in a DFS namespace like: //domain/dfsroot -> /serverA/dfsroot, /serverB/dfsroot //serverA/dfsroot/link -> /serverA/target1/aa/bb //serverA/dfsroot/link2 -> /serverA/target1/cc/dd you can see that link and link2 are two DFS links that both resolve to the same target share (/serverA/target1), so cifs.ko will only contain a single tcon for both link and link2. The problem with that is, if we (auto)mount "link" and "link2", cifs.ko will only contain a single tcon for both DFS links so we couldn't perform failover or refresh the DFS cache for both links because tcon->dfs_path was set to either "link" or "link2", but not both -- which is wrong. Signed-off-by:
Paulo Alcantara (SUSE) <pc@cjr.nz> Reviewed-by:
Aurelien Aptel <aaptel@suse.com> Reviewed-by:
Ronnie Sahlberg <lsahlber@redhat.com> Signed-off-by:
Steve French <stfrench@microsoft.com> Signed-off-by:
-
Jeremie Francois (on alpha) authored
[ Upstream commit e461bc9f ] Sed broke on some strings as it used colon as a separator. I made it more robust by using \001, which is legit POSIX AFAIK. E.g. ./config --set-str CONFIG_USBNET_DEVADDR "de:ad:be:ef:00:01" failed with: sed: -e expression #1, char 55: unknown option to `s' Signed-off-by:
Jeremie Francois (on alpha) <jeremie.francois@gmail.com> Signed-off-by:
Masahiro Yamada <masahiroy@kernel.org> Signed-off-by:
-
Ronnie Sahlberg authored
[ Upstream commit fada37f6 ] We use a spinlock while we are reading and accessing the destination address for a server. We need to also use this spinlock to protect when we are modifying this address from reconn_set_ipaddr(). Signed-off-by:
Jeff Layton <jlayton@kernel.org> Signed-off-by:
-
Matthias Blankertz authored
[ Upstream commit 54cb6221 ] Fix the rsnd_ssi_stop function to skip disabling the individual SSIs of a multi-SSI setup, as the actual stop is performed by rsnd_ssiu_stop_gen2 - the same logic as in rsnd_ssi_start. The attempt to disable these SSIs was harmless, but caused a "status check failed" message to be printed for every SSI in the multi-SSI setup. The disabling of interrupts is still performed, as they are enabled for all SSIs in rsnd_ssi_init, but care is taken to not accidentally set the EN bit for an SSI where it was not set by rsnd_ssi_start. Signed-off-by:
Matthias Blankertz <matthias.blankertz@cetitec.com> Acked-by:
Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Link: https://lore.kernel.org/r/20200417153017.1744454-3-matthias.blankertz@cetitec.com Signed-off-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
-
Matthias Blankertz authored
[ Upstream commit 0c258657 ] The master SSI of a multi-SSI setup was attached both to the RSND_MOD_SSI slot and the RSND_MOD_SSIP slot of the rsnd_dai_stream. This is not correct wrt. the meaning of being "parent" in the rest of the SSI code, where it seems to indicate an SSI that provides clock and word sync but is not transmitting/receiving audio data. Not treating the multi-SSI master as parent allows removal of various special cases to the rsnd_ssi_is_parent conditions introduced in commit a09fb3f2 ("ASoC: rsnd: Fix parent SSI start/stop in multi-SSI mode"). It also fixes the issue that operations performed via rsnd_dai_call() were performed twice for the master SSI. This caused some "status check failed" spam when stopping a multi-SSI stream as the driver attempted to stop the master SSI twice. Signed-off-by:
-
Julien Beraud authored
[ Upstream commit 91a2559c ] In fine adjustement mode, which is the current default, the sub-second increment register is the number of nanoseconds that will be added to the clock when the accumulator overflows. At each clock cycle, the value of the addend register is added to the accumulator. Currently, we use 20ns = 1e09ns / 50MHz as this value whatever the frequency of the ptp clock actually is. The adjustment is then done on the addend register, only incrementing every X clock cycles X being the ratio between 50MHz and ptp_clock_rate (addend = 2^32 * 50MHz/ptp_clock_rate). This causes the following issues : - In case the frequency of the ptp clock is inferior or equal to 50MHz, the addend value calculation will overflow and the default addend value will be set to 0, causing the clock to not work at all. (For instance, for ptp_clock_rate = 50MHz, addend = 2^32). - The resolution of the timestamping clock is limited to 20ns while it is not needed, thus limiting the accuracy of the timestamping to 20ns. Fix this by setting sub-second increment to 2e09ns / ptp_clock_rate. It will allow to reach the minimum possible frequency for ptp_clk_ref, which is 5MHz for GMII 1000Mps Full-Duplex by setting the sub-second-increment to a higher value. For instance, for 25MHz, it gives ssinc = 80ns and default_addend = 2^31. It will also allow to use a lower value for sub-second-increment, thus improving the timestamping accuracy with frequencies higher than 100MHz, for instance, for 200MHz, ssinc = 10ns and default_addend = 2^31. v1->v2: - Remove modifications to the calculation of default addend, which broke compatibility with clock frequencies for which 2000000000 / ptp_clk_freq is not an integer. - Modify description according to discussions. Signed-off-by:
Julien Beraud <julien.beraud@orolia.com> Signed-off-by:
-
Julien Beraud authored
[ Upstream commit 15ce3060 ] There are 2 registers to write to enable a ptp ref clock coming from the fpga. One that enables the usage of the clock from the fpga for emac0 and emac1 as a ptp ref clock, and the other to allow signals from the fpga to reach emac0 and emac1. Currently, if the dwmac-socfpga has phymode set to PHY_INTERFACE_MODE_MII, PHY_INTERFACE_MODE_GMII, or PHY_INTERFACE_MODE_SGMII, both registers will be written and the ptp ref clock will be set as coming from the fpga. Separate the 2 register writes to only enable signals from the fpga to reach emac0 or emac1 when ptp ref clock is not coming from the fpga. Signed-off-by:
-
Xiyu Yang authored
[ Upstream commit 7717cbec ] i2400mu_bus_bm_wait_for_ack() invokes usb_get_urb(), which increases the refcount of the "notif_urb". When i2400mu_bus_bm_wait_for_ack() returns, local variable "notif_urb" becomes invalid, so the refcount should be decreased to keep refcount balanced. The issue happens in all paths of i2400mu_bus_bm_wait_for_ack(), which forget to decrease the refcnt increased by usb_get_urb(), causing a refcnt leak. Fix this issue by calling usb_put_urb() before the i2400mu_bus_bm_wait_for_ack() returns. Signed-off-by:
Xiyu Yang <xiyuyang19@fudan.edu.cn> Signed-off-by:
Xin Tan <tanxin.ctf@gmail.com> Signed-off-by:
-
Sandeep Raghuraman authored
[ Upstream commit bbc25dad ] Initialize thermal controller fields in the PowerPlay table for Hawaii GPUs, so that fan speeds are reported. Signed-off-by:
Sandeep Raghuraman <sandy.8925@gmail.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
-
Alex Elder authored
[ Upstream commit 13c060b5 ] If looking up the DT "firmware-name" property fails in q6v6_probe(), the function returns without freeing the remoteproc structure that has been allocated. Fix this by jumping to the free_rproc label, which takes care of this. Signed-off-by:
Alex Elder <elder@linaro.org> Link: https://lore.kernel.org/r/20200403175005.17130-3-elder@linaro.org Signed-off-by:
Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by:
-
Amadeusz Sławiński authored
[ Upstream commit 326b5092 ] If we don't find any pcm, pcm will point at address at an offset from the the list head and not a meaningful structure. Fix this by returning correct pcm if found and NULL if not. Found with coccinelle. Signed-off-by:
Amadeusz Sławiński <amadeuszx.slawinski@linux.intel.com> Link: https://lore.kernel.org/r/20200415162849.308-1-amadeuszx.slawinski@linux.intel.com Signed-off-by:
-
Matthias Blankertz authored
[ Upstream commit b94e1647 ] The HDMI?_SEL register maps up to four stereo SSI data lanes onto the sdata[0..3] inputs of the HDMI output block. The upper half of the register contains four blocks of 4 bits, with the most significant controlling the sdata3 line and the least significant the sdata0 line. The shift calculation has an off-by-one error, causing the parent SSI to be mapped to sdata3, the first multi-SSI child to sdata0 and so forth. As the parent SSI transmits the stereo L/R channels, and the HDMI core expects it on the sdata0 line, this causes no audio to be output when playing stereo audio on a multichannel capable HDMI out, and multichannel audio has permutated channels. Fix the shift calculation to map the parent SSI to sdata0, the first child to sdata1 etc. Signed-off-by:
-
Matthias Blankertz authored
[ Upstream commit a09fb3f2 ] The parent SSI of a multi-SSI setup must be fully setup, started and stopped since it is also part of the playback/capture setup. So only skip the SSI (as per commit 203cdf51 ("ASoC: rsnd: SSI parent cares SWSP bit") and commit 597b046f ("ASoC: rsnd: control SSICR::EN correctly")) if the SSI is parent outside of a multi-SSI setup. Signed-off-by:
-
Thinh Nguyen authored
[ Upstream commit d94ea531 ] Currently the calculation of max packet size limit for IN endpoints is too restrictive. This prevents a matching of a capable hardware endpoint during configuration. Below is the minimum recommended HW configuration to support a particular endpoint setup from the databook: For OUT endpoints, the databook recommended the minimum RxFIFO size to be at least 3x MaxPacketSize + 3x setup packets size (8 bytes each) + clock crossing margin (16 bytes). For IN endpoints, the databook recommended the minimum TxFIFO size to be at least 3x MaxPacketSize for endpoints that support burst. If the endpoint doesn't support burst or when the device is operating in USB 2.0 mode, a minimum TxFIFO size of 2x MaxPacketSize is recommended. Base on these recommendations, we can calculate the MaxPacketSize limit of each endpoint. This patch revises the IN endpoint MaxPacketSize limit and also sets the MaxPacketSize limit for OUT endpoints. Reference: Databook 3.30a section 3.2.2 and 3.2.3 Signed-off-by:
Thinh Nguyen <thinhn@synopsys.com> Signed-off-by:
Felipe Balbi <balbi@kernel.org> Signed-off-by:
-
Amadeusz Sławiński authored
[ Upstream commit 26d87881 ] As done in already existing cases, we should use le32_to_cpu macro while accessing hdr->magic. Found with sparse. Signed-off-by:
-
Sebastian Reichel authored
[ Upstream commit aa781273 ] As mentioned slightly out of patch context in the code, there is no reset routine for the chip. On boards where the chip is supplied by a fixed regulator, it might not even be resetted during (e.g. watchdog) reboot and can be in any state. If the device is probed with VAG enabled, the driver's probe routine will generate a loud pop sound when ANA_POWER is being programmed. Avoid this by properly disabling just the VAG bit and waiting the required power down time. Signed-off-by:
Sebastian Reichel <sebastian.reichel@collabora.com> Reviewed-by:
Fabio Estevam <festivem@gmail.com> Link: https://lore.kernel.org/r/20200414181140.145825-1-sebastian.reichel@collabora.com Signed-off-by:
-
Tyler Hicks authored
[ Upstream commit b87080ea ] After successfully running the IPC msgque test once, subsequent runs result in a test failure: $ sudo ./run_kselftest.sh TAP version 13 1..1 # selftests: ipc: msgque # Failed to get stats for IPC queue with id 0 # Failed to dump queue: -22 # Bail out! # # Pass 0 Fail 0 Xfail 0 Xpass 0 Skip 0 Error 0 not ok 1 selftests: ipc: msgque # exit=1 The dump_queue() function loops through the possible message queue index values using calls to msgctl(kern_id, MSG_STAT, ...) where kern_id represents the index value. The first time the test is ran, the initial index value of 0 is valid and the test is able to complete. The index value of 0 is not valid in subsequent test runs and the loop attempts to try index values of 1, 2, 3, and so on until a valid index value is found that corresponds to the message queue created earlier in the test. The msgctl() syscall returns -1 and sets errno to EINVAL when invalid index values are used. The test failure is caused by incorrectly comparing errno to -EINVAL when cycling through possible index values. Fix invalid test failures on subsequent runs of the msgque test by correctly comparing errno values to a non-negated EINVAL. Fixes: 3a665531 ("selftests: IPC message queue copy feature test") Signed-off-by:
Tyler Hicks <tyhicks@linux.microsoft.com> Signed-off-by:
Shuah Khan <skhan@linuxfoundation.org> Signed-off-by:
-
Amadeusz Sławiński authored
[ Upstream commit dd8e871d ] Function soc_tplg_dai_config can fail, check for and handle possible failure. Signed-off-by:
Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Reviewed-by:
Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20200327204729.397-7-amadeuszx.slawinski@linux.intel.com Signed-off-by:
-
Amadeusz Sławiński authored
[ Upstream commit b3677fc3 ] Function pcm_new_ver can fail, so we should check it's return value and handle possible error. Signed-off-by:
-
Amadeusz Sławiński authored
[ Upstream commit 6856e887 ] Function soc_tplg_add_route can propagate error code from callback, we should check its return value and handle fail in correct way. Signed-off-by:
-
Amadeusz Sławiński authored
[ Upstream commit 2ae548f3 ] Functions soc_tplg_denum_create, soc_tplg_dmixer_create, soc_tplg_dbytes_create can fail, so their return values should be checked and error should be propagated. Signed-off-by:
-
Amadeusz Sławiński authored
[ Upstream commit 482db55a ] Function soc_tplg_create_tlv can fail, so we should check if it succeded or not and proceed appropriately. Signed-off-by:
-
Marek Szyprowski authored
[ Upstream commit 83a19677 ] Analogix_dp driver acquires all its resources in the ->bind() callback, what is a bit against the component driver based approach, where the driver initialization is split into a probe(), where all resources are gathered, and a bind(), where all objects are created and a compound driver is initialized. Extract all the resource related operations to analogix_dp_probe() and analogix_dp_remove(), then call them before/after registration of the device components from the main Exynos DP and Rockchip DP drivers. Also move the plat_data initialization to the probe() to make it available for the analogix_dp_probe() function. This fixes the multiple calls to the bind() of the DRM compound driver when the DP PHY driver is not yet loaded/probed: [drm] Exynos DRM: using 14400000.fimd device for DMA mapping operations exynos-drm exynos-drm: bound 14400000.fimd (ops fimd_component_ops [exynosdrm]) exynos-drm exynos-drm: bound 14450000.mixer (ops mixer_component_ops [exynosdrm]) exynos-dp 145b0000.dp-controller: no DP phy configured exynos-drm exynos-drm: failed to bind 145b0000.dp-controller (ops exynos_dp_ops [exynosdrm]): -517 exynos-drm exynos-drm: master bind failed: -517 ... [drm] Exynos DRM: using 14400000.fimd device for DMA mapping operations exynos-drm exynos-drm: bound 14400000.fimd (ops hdmi_enable [exynosdrm]) exynos-drm exynos-drm: bound 14450000.mixer (ops hdmi_enable [exynosdrm]) exynos-drm exynos-drm: bound 145b0000.dp-controller (ops hdmi_enable [exynosdrm]) exynos-drm exynos-drm: bound 14530000.hdmi (ops hdmi_enable [exynosdrm]) [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). Console: switching to colour frame buffer device 170x48 exynos-drm exynos-drm: fb0: exynosdrmfb frame buffer device [drm] Initialized exynos 1.1.0 20180330 for exynos-drm on minor 1 ... Signed-off-by:
Marek Szyprowski <m.szyprowski@samsung.com> Acked-by:
Andy Yan <andy.yan@rock-chips.com> Reviewed-by:
Andrzej Hajda <a.hajda@samsung.com> Signed-off-by:
-
Jia He authored
commit 0b841030 upstream. Ning Bo reported an abnormal 2-second gap when booting Kata container [1]. The unconditional timeout was caused by VSOCK_DEFAULT_CONNECT_TIMEOUT of connecting from the client side. The vhost vsock client tries to connect an initializing virtio vsock server. The abnormal flow looks like: host-userspace vhost vsock guest vsock ============== =========== ============ connect() --------> vhost_transport_send_pkt_work() initializing | vq->private_data==NULL | will not be queued V schedule_timeout(2s) vhost_vsock_start() <--------- device ready set vq->private_data wait for 2s and failed connect() again vq->private_data!=NULL recv connecting pkt Details: 1. Host userspace sends a connect pkt, at that time, guest vsock is under initializing, hence the vhost_vsock_start has not been called. So vq->private_data==NULL, and the pkt is not been queued to send to guest 2. Then it sleeps for 2s 3. After guest vsock finishes initializing, vq->private_data is set 4. When host userspace wakes up after 2s, send connecting pkt again, everything is fine. As suggested by Stefano Garzarella, this fixes it by additional kicking the send_pkt worker in vhost_vsock_start once the virtio device is started. This makes the pending pkt sent again. After this patch, kata-runtime (with vsock enabled) boot time is reduced from 3s to 1s on a ThunderX2 arm64 server. [1] https://github.com/kata-containers/runtime/issues/1917 Reported-by:
Ning Bo <n.b@live.com> Suggested-by:
Stefano Garzarella <sgarzare@redhat.com> Signed-off-by:
Jia He <justin.he@arm.com> Link: https://lore.kernel.org/r/20200501043840.186557-1-justin.he@arm.com Signed-off-by:
Michael S. Tsirkin <mst@redhat.com> Reviewed-by:
-
- May 06, 2020
-
-
Greg Kroah-Hartman authored
-
Paul Moore authored
commit fb739741 upstream. Fix the SELinux netlink_send hook to properly handle multiple netlink messages in a single sk_buff; each message is parsed and subject to SELinux access control. Prior to this patch, SELinux only inspected the first message in the sk_buff. Cc: stable@vger.kernel.org Reported-by:
Dmitry Vyukov <dvyukov@google.com> Reviewed-by:
Stephen Smalley <stephen.smalley.work@gmail.com> Signed-off-by:
Paul Moore <paul@paul-moore.com> Signed-off-by:
-
Vincenzo Frascino authored
commit 1578e5d0 upstream. On arm64 linux gcc uses -fasynchronous-unwind-tables -funwind-tables by default since gcc-8, so now the de facto platform ABI is to allow unwinding from async signal handlers. However on bare metal targets (aarch64-none-elf), and on old gcc, async and sync unwind tables are not enabled by default to avoid runtime memory costs. This means if linux is built with a baremetal toolchain the vdso.so may not have unwind tables which breaks the gcc platform ABI guarantee in userspace. Add -fasynchronous-unwind-tables explicitly to the vgettimeofday.o cflags to address the ABI change. Fixes: 28b1a824 ("arm64: vdso: Substitute gettimeofday() with C implementation") Cc: Will Deacon <will@kernel.org> Reported-by:
Szabolcs Nagy <szabolcs.nagy@arm.com> Signed-off-by:
Vincenzo Frascino <vincenzo.frascino@arm.com> Signed-off-by:
Catalin Marinas <catalin.marinas@arm.com> Signed-off-by:
-
Andy Shevchenko authored
commit aa72f1d2 upstream. If we do % echo 1 > /sys/module/dmatest/parameters/run [ 115.851124] dmatest: Could not start test, no channels configured % echo dma8chan7 > /sys/module/dmatest/parameters/channel [ 127.563872] dmatest: Added 1 threads using dma8chan7 % cat /sys/module/dmatest/parameters/wait ... !!! HANG !!! ... The culprit is the commit 6138f967 ("dmaengine: dmatest: Use fixed point div to calculate iops") which makes threads not to run, but pending and being kicked off by writing to the 'run' node. However, it forgot to consider 'wait' routine to avoid above mentioned case. In order to fix this, check for really running threads, i.e. with pending and done flags unset. It's pity the culprit commit hadn't updated documentation and tested all possible scenarios. Fixes: 6138f967 ("dmaengine: dmatest: Use fixed point div to calculate iops") Cc: Seraj Alijan <seraj.alijan@sondrel.com> Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20200428113518.70620-1-andriy.shevchenko@linux.intel.com Signed-off-by:
Vinod Koul <vkoul@kernel.org> Signed-off-by:
-
Andy Shevchenko authored
commit b9f96020 upstream. Under some circumstances, i.e. when test is still running and about to time out and user runs, for example, grep -H . /sys/module/dmatest/parameters/* the iterations parameter is not respected and test is going on and on until user gives echo 0 > /sys/module/dmatest/parameters/run This is not what expected. The history of this bug is interesting. I though that the commit 2d88ce76 ("dmatest: add a 'wait' parameter") is a culprit, but looking closer to the code I think it simple revealed the broken logic from the day one, i.e. in the commit 0a2ff57d ("dmaengine: dmatest: add a maximum number of test iterations") which adds iterations parameter. So, to the point, the conditional of checking the thread to be stopped being first part of conjunction logic prevents to check iterations. Thus, we have to always check both conditions to be able to stop after given iterations. Since it wasn't visible before second commit appeared, I add a respective Fixes tag. Fixes: 2d88ce76 ("dmatest: add a 'wait' parameter") Cc: Dan Williams <dan.j.williams@intel.com> Cc: Nicolas Ferre <nicolas.ferre@microchip.com> Signed-off-by:
Nicolas Ferre <nicolas.ferre@microchip.com> Link: https://lore.kernel.org/r/20200424161147.16895-1-andriy.shevchenko@linux.intel.com Signed-off-by:
-
Andreas Gruenbacher authored
commit 7648f939 upstream. nfs3_set_acl keeps track of the acl it allocated locally to determine if an acl needs to be released at the end. This results in a memory leak when the function allocates an acl as well as a default acl. Fix by releasing acls that differ from the acl originally passed into nfs3_set_acl. Fixes: b7fa0554 ("[PATCH] NFS: Add support for NFSv3 ACLs") Reported-by:
Andreas Gruenbacher <agruenba@redhat.com> Signed-off-by:
Trond Myklebust <trond.myklebust@hammerspace.com> Signed-off-by:
-
Niklas Cassel authored
commit 132be623 upstream. When jumping to the out_put_disk label, we will call put_disk(), which will trigger a call to disk_release(), which calls blk_put_queue(). Later in the cleanup code, we do blk_cleanup_queue(), which will also call blk_put_queue(). Putting the queue twice is incorrect, and will generate a KASAN splat. Set the disk->queue pointer to NULL, before calling put_disk(), so that the first call to blk_put_queue() will not free the queue. The second call to blk_put_queue() uses another pointer to the same queue, so this call will still free the queue. Fixes: 85136c01 ("lightnvm: simplify geometry enumeration") Signed-off-by:
Niklas Cassel <niklas.cassel@wdc.com> Signed-off-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
-
David Howells authored
commit dd7bc815 upstream. Commit 6fcf0c72, a fix to get_tree_bdev() put a missing blkdev_put() in the wrong place, before a warnf() that displays the bdev under consideration rather after it. This results in a silent lockup in printk("%pg") called via warnf() from get_tree_bdev() under some circumstances when there's a race with the blockdev being frozen. This can be caused by xfstests/tests/generic/085 in combination with Lukas Czerner's ext4 mount API conversion patchset. It looks like it ought to occur with other users of get_tree_bdev() such as XFS, but apparently doesn't. Fix this by switching the order of the lines. Fixes: 6fcf0c72 ("vfs: add missing blkdev_put() in get_tree_bdev()") Reported-by:
Lukas Czerner <lczerner@redhat.com> Signed-off-by:
David Howells <dhowells@redhat.com> cc: Ian Kent <raven@themaw.net> cc: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Arnd Bergmann authored
commit 5ce00760 upstream. gcc-10 points out a few instances of suspicious integer arithmetic leading to value truncation: sound/isa/opti9xx/opti92x-ad1848.c: In function 'snd_opti9xx_configure': sound/isa/opti9xx/opti92x-ad1848.c:322:43: error: overflow in conversion from 'int' to 'unsigned char' changes value from '(int)snd_opti9xx_read(chip, 3) & -256 | 240' to '240' [-Werror=overflow] 322 | (snd_opti9xx_read(chip, reg) & ~(mask)) | ((value) & (mask))) | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~ sound/isa/opti9xx/opti92x-ad1848.c:351:3: note: in expansion of macro 'snd_opti9xx_write_mask' 351 | snd_opti9xx_write_mask(chip, OPTi9XX_MC_REG(3), 0xf0, 0xff); | ^~~~~~~~~~~~~~~~~~~~~~ sound/isa/opti9xx/miro.c: In function 'snd_miro_configure': sound/isa/opti9xx/miro.c:873:40: error: overflow in conversion from 'int' to 'unsigned char' changes value from '(int)snd_miro_read(chip, 3) & -256 | 240' to '240' [-Werror=overflow] 873 | (snd_miro_read(chip, reg) & ~(mask)) | ((value) & (mask))) | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~ sound/isa/opti9xx/miro.c:1010:3: note: in expansion of macro 'snd_miro_write_mask' 1010 | snd_miro_write_mask(chip, OPTi9XX_MC_REG(3), 0xf0, 0xff); | ^~~~~~~~~~~~~~~~~~~ These are all harmless here as only the low 8 bit are passed down anyway. Change the macros to inline functions to make the code more readable and also avoid the warning. Strictly speaking those functions also need locking to make the read/write pair atomic, but it seems unlikely that anyone would still run into that issue. Fixes: 1841f613 ("[ALSA] Add snd-miro driver") Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Link: https://lore.kernel.org/r/20200429190216.85919-1-arnd@arndb.de Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
ryan_chen authored
commit c926c87b upstream. In AST2600 there have a slow peripheral bus between CPU and i2c controller. Therefore GIC i2c interrupt status clear have delay timing, when CPU issue write clear i2c controller interrupt status. To avoid this issue, the driver need have read after write clear at i2c ISR. Fixes: f327c686 ("i2c: aspeed: added driver for Aspeed I2C") Signed-off-by:
ryan_chen <ryan_chen@aspeedtech.com> Acked-by:
Benjamin Herrenschmidt <benh@kernel.crashing.org> [wsa: added Fixes tag] Signed-off-by:
Wolfram Sang <wsa@the-dreams.de> Signed-off-by:
-
