- 23 Mar, 2019 37 commits
-
-
Kuninori Morimoto authored
[ Upstream commit d9111d36 ] commit 4d230d12 ("ASoC: rsnd: fixup not to call clk_get/set under non-atomic") added new rsnd_ssi_prepare() and moved rsnd_ssi_master_clk_start() to .prepare. But, ssi user count (= ssi->usrcnt) is incremented at .init (= rsnd_ssi_init()). Because of these timing exchange, ssi->usrcnt check at rsnd_ssi_master_clk_start() should be adjusted. Otherwise, 2nd master clock setup will be no check. This patch fixup this issue. Fixes: commit 4d230d12 ("ASoC: rsnd: fixup not to call clk_get/set under non-atomic") Reported-by:
Yusuke Goda <yusuke.goda.sx@renesas.com> Reported-by:
Valentine Barshak <valentine.barshak@cogentembedded.com> Signed-off-by:
Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Tested-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Pierre-Louis Bossart authored
[ Upstream commit c16e1201 ] KASAN reports and additional traces point to out-of-bounds accesses to the dapm_up_seq and dapm_down_seq lookup tables. The indices used are larger than the array definition. Fix by adding missing entries for the new widget types in these two lookup tables, and align them with PGA values. Also the sequences for the following widgets were not defined. Since their values defaulted to zero, assign them explicitly snd_soc_dapm_input snd_soc_dapm_output snd_soc_dapm_vmid snd_soc_dapm_siggen snd_soc_dapm_sink Fixes: 8a70b454 ('ASoC: dapm: Add new widget type for constructing DAPM graphs on DSPs.'). Signed-off-by:
Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Signed-off-by:
-
Yizhuo authored
[ Upstream commit dc30e703 ] In function omap4_dsi_mux_pads(), local variable "reg" could be uninitialized if function regmap_read() returns -EINVAL. However, it will be used directly in the later context, which is potentially unsafe. Signed-off-by:
Yizhuo <yzhai003@ucr.edu> Signed-off-by:
Tony Lindgren <tony@atomide.com> Signed-off-by:
-
Tony Lindgren authored
[ Upstream commit 0840242e ] Commit 84badc5e ("ARM: dts: omap4: Move l4 child devices to probe them with ti-sysc") moved some omap4 timers to probe with ti-sysc interconnect target module. Turns out this broke pwm-omap-dmtimer for reparenting of the timer clock. With ti-sysc, we can now configure the clock sources in the dts with assigned-clocks and assigned-clock-parents. Fixes: 84badc5e ("ARM: dts: omap4: Move l4 child devices to probe them with ti-sysc") Cc: Bartosz Golaszewski <bgolaszewski@baylibre.com> Cc: Daniel Lezcano <daniel.lezcano@linaro.org> Cc: H. Nikolaus Schaller <hns@goldelico.com> Cc: Keerthy <j-keerthy@ti.com> Cc: Ladislav Michl <ladis@linux-mips.org> Cc: Pavel Machek <pavel@ucw.cz> Cc: Sebastian Reichel <sre@kernel.org> Cc: Tero Kristo <t-kristo@ti.com> Cc: Thierry Reding <thierry.reding@gmail.com> Cc: Thomas Gleixner <tglx@linutronix.de> Reported-by:
H. Nikolaus Schaller <hns@goldelico.com> Signed-off-by:
-
Paweł Chmiel authored
[ Upstream commit 94803aef ] This patch fixes order of disable calls in pwm_vibrator_stop. Currently when starting device, we first enable vcc regulator and then setup and enable pwm. When stopping, we should do this in oposite order, so first disable pwm and then disable regulator. Previously order was the same as in start. Signed-off-by:
Paweł Chmiel <pawel.mikolaj.chmiel@gmail.com> Signed-off-by:
Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by:
-
Jonathan Bakker authored
[ Upstream commit 3ca232df ] pwm_vibrator_stop disables the regulator, but it can be called from multiple places, even when the regulator is already disabled. Fix this by using regulator_is_enabled check when starting and stopping device. Signed-off-by:
Jonathan Bakker <xc-racer2@live.ca> Signed-off-by:
-
Stefan Haberland authored
[ Upstream commit 4a8ef699 ] Dan Carpenter reported the following: The patch 52898025: "[S390] dasd: security and PSF update patch for EMC CKD ioctl" from Mar 8, 2010, leads to the following static checker warning: drivers/s390/block/dasd_eckd.c:4486 dasd_symm_io() error: using offset into zero size array 'psf_data[]' drivers/s390/block/dasd_eckd.c 4458 /* Copy parms from caller */ 4459 rc = -EFAULT; 4460 if (copy_from_user(&usrparm, argp, sizeof(usrparm))) ^^^^^^^ The user can specify any "usrparm.psf_data_len". They choose zero by mistake. 4461 goto out; 4462 if (is_compat_task()) { 4463 /* Make sure pointers are sane even on 31 bit. */ 4464 rc = -EINVAL; 4465 if ((usrparm.psf_data >> 32) != 0) 4466 goto out; 4467 if ((usrparm.rssd_result >> 32) != 0) 4468 goto out; 4469 usrparm.psf_data &= 0x7fffffffULL; 4470 usrparm.rssd_result &= 0x7fffffffULL; 4471 } 4472 /* alloc I/O data area */ 4473 psf_data = kzalloc(usrparm.psf_data_len, GFP_KERNEL | GFP_DMA); 4474 rssd_result = kzalloc(usrparm.rssd_result_len, GFP_KERNEL | GFP_DMA); 4475 if (!psf_data || !rssd_result) { kzalloc() returns a ZERO_SIZE_PTR (0x16). 4476 rc = -ENOMEM; 4477 goto out_free; 4478 } 4479 4480 /* get syscall header from user space */ 4481 rc = -EFAULT; 4482 if (copy_from_user(psf_data, 4483 (void __user *)(unsigned long) usrparm.psf_data, 4484 usrparm.psf_data_len)) That all works great. 4485 goto out_free; 4486 psf0 = psf_data[0]; 4487 psf1 = psf_data[1]; But now we're assuming that "->psf_data_len" was at least 2 bytes. Fix this by checking the user specified length psf_data_len. Fixes: 52898025 ("[S390] dasd: security and PSF update patch for EMC CKD ioctl") Reported-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
Stefan Haberland <sth@linux.ibm.com> Signed-off-by:
Martin Schwidefsky <schwidefsky@de.ibm.com> Signed-off-by:
-
Enric Balletbo i Serra authored
[ Upstream commit 26cd8657 ] Ports are described by child 'port' nodes contained in the device node. 'ports' is optional and is used to group all 'port' nodes which is not the case here. This patch fixes the following warnings: arch/arm64/boot/dts/rockchip/rk3399-gru-bob.dts:25.9-29.5: Warning (graph_port): /edp-panel/ports: graph port node name should be 'port' arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts:46.9-50.5: Warningi (graph_port): /edp-panel/ports: graph port node name should be 'port' arch/arm64/boot/dts/rockchip/rk3399-sapphire-excavator.dts:94.9-98.5: Warning (graph_port): /edp-panel/ports: graph port node name should be 'port' Signed-off-by:
Enric Balletbo i Serra <enric.balletbo@collabora.com> Signed-off-by:
Heiko Stuebner <heiko@sntech.de> Signed-off-by:
-
Julien Thierry authored
[ Upstream commit fc3bc475 ] vgic_dist->lpi_list_lock must always be taken with interrupts disabled as it is used in interrupt context. For configurations such as PREEMPT_RT_FULL, this means that it should be a raw_spinlock since RT spinlocks are interruptible. Signed-off-by:
Julien Thierry <julien.thierry@arm.com> Acked-by:
Christoffer Dall <christoffer.dall@arm.com> Acked-by:
Marc Zyngier <marc.zyngier@arm.com> Signed-off-by:
-
Tony Lindgren authored
[ Upstream commit 983a5a43 ] Commit 84badc5e ("ARM: dts: omap4: Move l4 child devices to probe them with ti-sysc") moved some omap4 timers to probe with ti-sysc interconnect target module. Turns out this broke pwm-omap-dmtimer where we now try to reparent the clock to itself with the following: omap_dm_timer_of_set_source: failed to set parent With ti-sysc, we can now configure the clock sources in the dts with assigned-clocks and assigned-clock-parents. So we should be able to remove omap_dm_timer_of_set_source with clean-up patches later on. But for now, let's just fix it first by checking if parent and fck are the same and bail out of so. Fixes: 84badc5e ("ARM: dts: omap4: Move l4 child devices to probe them with ti-sysc") Cc: Bartosz Golaszewski <bgolaszewski@baylibre.com> Cc: Daniel Lezcano <daniel.lezcano@linaro.org> Cc: H. Nikolaus Schaller <hns@goldelico.com> Cc: Keerthy <j-keerthy@ti.com> Cc: Ladislav Michl <ladis@linux-mips.org> Cc: Pavel Machek <pavel@ucw.cz> Cc: Sebastian Reichel <sre@kernel.org> Cc: Tero Kristo <t-kristo@ti.com> Cc: Thierry Reding <thierry.reding@gmail.com> Cc: Thomas Gleixner <tglx@linutronix.de> Reported-by:
Andreas Kemnade <andreas@kemnade.info> Tested-By:
-
Shuming Fan authored
[ Upstream commit 8077ec01 ] AD/DA ASRC function control two ASRC clock sources separately. Whether AD/DA filter select which clock source, we enable AD/DA ASRC function for all cases. Signed-off-by:
Shuming Fan <shumingf@realtek.com> Signed-off-by:
-
Steve Longerbeam authored
[ Upstream commit bb867d21 ] The CSI offsets are wrong for both CSI0 and CSI1. They are at physical address 0x1e030000 and 0x1e038000 respectively. Fixes: 2ffd48f2 ("gpu: ipu-v3: Add Camera Sensor Interface unit") Signed-off-by:
Steve Longerbeam <slongerbeam@gmail.com> Signed-off-by:
Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by:
-
Julia Lawall authored
[ Upstream commit aa331201 ] The device node iterators perform an of_node_get on each iteration, so a jump out of the loop requires an of_node_put. Move the initialization channel->child = child; down to just before the call to imx_ldb_register so that intervening failures don't need to clear it. Add a label at the end of the function to do all the of_node_puts. The semantic patch that finds part of this problem is as follows (http://coccinelle.lip6.fr): // <smpl> @@ expression root,e; local idexpression child; iterator name for_each_child_of_node; @@ for_each_child_of_node(root, child) { ... when != of_node_put(child) when != e = child ( return child; | * return ...; ) ... } // </smpl> Signed-off-by:
Julia Lawall <Julia.Lawall@lip6.fr> Signed-off-by:
-
Alexander Shiyan authored
[ Upstream commit 2c0408dd ] The CSI0/CSI1 registers offset is at +0xe030000/+0xe038000 relative to the control module registers on IPUv3EX. This patch fixes wrong values for i.MX51 CSI0/CSI1. Fixes: 2ffd48f2 ("gpu: ipu-v3: Add Camera Sensor Interface unit") Signed-off-by:
Alexander Shiyan <shc_work@mail.ru> Signed-off-by:
-
Philipp Zabel authored
[ Upstream commit 4fb873c9 ] This patch fixes backtraces like the following when sending SIGKILL to a process with a currently pending plane update: [drm:ipu_plane_atomic_check] CRTC should be enabled [drm:drm_framebuffer_remove] *ERROR* failed to commit ------------[ cut here ]------------ WARNING: CPU: 3 PID: 63 at drivers/gpu/drm/drm_framebuffer.c:926 drm_framebuffer_remove+0x47c/0x498 atomic remove_fb failed with -22 Signed-off-by:
-
Zhang Zhijie authored
commit c1c214ad upstream. For chain mode in cipher(eg. AES-CBC/DES-CBC), the iv is continuously updated in the operation. The new iv value should be written to device register by software. Reported-by:
Eric Biggers <ebiggers@google.com> Fixes: 433cd2c6 ("crypto: rockchip - add crypto driver for rk3288") Cc: <stable@vger.kernel.org> # v4.5+ Signed-off-by:
Zhang Zhijie <zhangzj@rock-chips.com> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Zhang Zhijie authored
commit 4359669a upstream. In some cases, the nents of src scatterlist is different from dst scatterlist. So two variables are used to handle the nents of src&dst scatterlist. Reported-by:
-
Eric Biggers authored
commit 77568e53 upstream. Hash algorithms with an alignmask set, e.g. "xcbc(aes-aesni)" and "michael_mic", fail the improved hash tests because they sometimes produce the wrong digest. The bug is that in the case where a scatterlist element crosses pages, not all the data is actually hashed because the scatterlist walk terminates too early. This happens because the 'nbytes' variable in crypto_hash_walk_done() is assigned the number of bytes remaining in the page, then later interpreted as the number of bytes remaining in the scatterlist element. Fix it. Fixes: 900a081f ("crypto: ahash - Fix early termination in hash walk") Cc: stable@vger.kernel.org Signed-off-by:
-
Eric Biggers authored
commit 6c2e322b upstream. The memcpy() in crypto_cfb_decrypt_inplace() uses walk->iv as both the source and destination, which has undefined behavior. It is unneeded because walk->iv is already used to hold the previous ciphertext block; thus, walk->iv is already updated to its final value. So, remove it. Also, note that in-place decryption is the only case where the previous ciphertext block is not directly available. Therefore, as a related cleanup I also updated crypto_cfb_encrypt_segment() to directly use the previous ciphertext block rather than save it into walk->iv. This makes it consistent with in-place encryption and out-of-place decryption; now only in-place decryption is different, because it has to be. Fixes: a7d85e06 ("crypto: cfb - add support for Cipher FeedBack mode") Cc: <stable@vger.kernel.org> # v4.17+ Cc: James Bottomley <James.Bottomley@HansenPartnership.com> Signed-off-by:
-
Eric Biggers authored
commit 394a9e04 upstream. Like some other block cipher mode implementations, the CFB implementation assumes that while walking through the scatterlist, a partial block does not occur until the end. But the walk is incorrectly being done with a blocksize of 1, as 'cra_blocksize' is set to 1 (since CFB is a stream cipher) but no 'chunksize' is set. This bug causes incorrect encryption/decryption for some scatterlist layouts. Fix it by setting the 'chunksize'. Also extend the CFB test vectors to cover this bug as well as cases where the message length is not a multiple of the block size. Fixes: a7d85e06 ("crypto: cfb - add support for Cipher FeedBack mode") Cc: <stable@vger.kernel.org> # v4.17+ Cc: James Bottomley <James.Bottomley@HansenPartnership.com> Signed-off-by:
-
Gilad Ben-Yossef authored
commit 2b5ac174 upstream. For decryption in CBC mode we need to save the last ciphertext block for use as the next IV. However, we were trying to do this also with zero sized ciphertext resulting in a panic. Fix this by only doing the copy if the ciphertext length is at least of IV size. Signed-off-by:
Gilad Ben-Yossef <gilad@benyossef.com> Cc: stable@vger.kernel.org Signed-off-by:
-
Gilad Ben-Yossef authored
commit c139c72e upstream. We were copying the last ciphertext block into the IV field for CBC before removing the DMA mapping of the output buffer with the result of the buffer sometime being out-of-sync cache wise and were getting intermittent cases of bad output IV. Fix it by moving the DMA buffer unmapping before the copy. Signed-off-by:
-
Hadar Gat authored
commit a4941195 upstream. In cc_unmap_aead_request(), call dma_pool_free() for mlli buffer only if an item is allocated from the pool and not always if there is a pool allocated. This fixes a kernel panic when trying to free a non-allocated item. Cc: stable@vger.kernel.org Signed-off-by:
Hadar Gat <hadar.gat@arm.com> Signed-off-by:
-
Horia Geantă authored
commit c19650d6 upstream. Roland reports the following issue and provides a root cause analysis: "On a v4.19 i.MX6 system with IMA and CONFIG_DMA_API_DEBUG enabled, a warning is generated when accessing files on a filesystem for which IMA measurement is enabled: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 1 at kernel/dma/debug.c:1181 check_for_stack.part.9+0xd0/0x120 caam_jr 2101000.jr0: DMA-API: device driver maps memory from stack [addr=b668049e] Modules linked in: CPU: 0 PID: 1 Comm: switch_root Not tainted 4.19.0-20181214-1 #2 Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree) Backtrace: [<c010efb8>] (dump_backtrace) from [<c010f2d0>] (show_stack+0x20/0x24) [<c010f2b0>] (show_stack) from [<c08b04f4>] (dump_stack+0xa0/0xcc) [<c08b0454>] (dump_stack) from [<c012b610>] (__warn+0xf0/0x108) [<c012b520>] (__warn) from [<c012b680>] (warn_slowpath_fmt+0x58/0x74) [<c012b62c>] (warn_slowpath_fmt) from [<c0199acc>] (check_for_stack.part.9+0xd0/0x120) [<c01999fc>] (check_for_stack.part.9) from [<c019a040>] (debug_dma_map_page+0x144/0x174) [<c0199efc>] (debug_dma_map_page) from [<c065f7f4>] (ahash_final_ctx+0x5b4/0xcf0) [<c065f240>] (ahash_final_ctx) from [<c065b3c4>] (ahash_final+0x1c/0x20) [<c065b3a8>] (ahash_final) from [<c03fe278>] (crypto_ahash_op+0x38/0x80) [<c03fe240>] (crypto_ahash_op) from [<c03fe2e0>] (crypto_ahash_final+0x20/0x24) [<c03fe2c0>] (crypto_ahash_final) from [<c03f19a8>] (ima_calc_file_hash+0x29c/0xa40) [<c03f170c>] (ima_calc_file_hash) from [<c03f2b24>] (ima_collect_measurement+0x1dc/0x240) [<c03f2948>] (ima_collect_measurement) from [<c03f0a60>] (process_measurement+0x4c4/0x6b8) [<c03f059c>] (process_measurement) from [<c03f0cdc>] (ima_file_check+0x88/0xa4) [<c03f0c54>] (ima_file_check) from [<c02d8adc>] (path_openat+0x5d8/0x1364) [<c02d8504>] (path_openat) from [<c02dad24>] (do_filp_open+0x84/0xf0) [<c02daca0>] (do_filp_open) from [<c02cf50c>] (do_open_execat+0x84/0x1b0) [<c02cf488>] (do_open_execat) from [<c02d1058>] (__do_execve_file+0x43c/0x890) [<c02d0c1c>] (__do_execve_file) from [<c02d1770>] (sys_execve+0x44/0x4c) [<c02d172c>] (sys_execve) from [<c0101000>] (ret_fast_syscall+0x0/0x28) ---[ end trace 3455789a10e3aefd ]--- The cause is that the struct ahash_request *req is created as a stack-local variable up in the stack (presumably somewhere in the IMA implementation), then passed down into the CAAM driver, which tries to dma_single_map the req->result (indirectly via map_seq_out_ptr_result) in order to make that buffer available for the CAAM to store the result of the following hash operation. The calling code doesn't know how req will be used by the CAAM driver, and there could be other such occurrences where stack memory is passed down to the CAAM driver. Therefore we should rather fix this issue in the CAAM driver where the requirements are known." Fix this problem by: -instructing the crypto engine to write the final hash in state->caam_ctx -subsequently memcpy-ing the final hash into req->result Cc: <stable@vger.kernel.org> # v4.19+ Reported-by:
Roland Hieber <rhi@pengutronix.de> Signed-off-by:
Horia Geantă <horia.geanta@nxp.com> Tested-by:
-
Pankaj Gupta authored
commit 42e95d1f upstream. when the source sg contains more than 1 fragment and destination sg contains 1 fragment, the caam driver mishandle the buffers to be sent to caam. Fixes: f2147b88 ("crypto: caam - Convert GCM to new AEAD interface") Cc: <stable@vger.kernel.org> # 4.2+ Signed-off-by:
Pankaj Gupta <pankaj.gupta@nxp.com> Signed-off-by:
Arun Pathak <arun.pathak@nxp.com> Reviewed-by:
-
Gustavo A. R. Silva authored
commit b5be8531 upstream. Add missing break statement in order to prevent the code from falling through to case S_DIN_to_DES. This bug was found thanks to the ongoing efforts to enable -Wimplicit-fallthrough. Fixes: 63ee04c8 ("crypto: ccree - add skcipher support") Cc: stable@vger.kernel.org Signed-off-by:
Gustavo A. R. Silva <gustavo@embeddedor.com> Signed-off-by:
-
Franck LENORMAND authored
commit 65055e21 upstream. When driver started using state->caam_ctxt for storing both running hash and final hash, it was not updated to handle different DMA unmap lengths. Cc: <stable@vger.kernel.org> # v4.19+ Fixes: c19650d6 ("crypto: caam - fix DMA mapping of stack memory") Signed-off-by:
Franck LENORMAND <franck.lenormand@nxp.com> Signed-off-by:
-
Zhi Jin authored
commit a1d75dad upstream. There is a bug in the channel allocation logic that leads to an endless loop when looking for a contiguous range of channels in a range with a mixture of free and occupied channels. For example, opening three consequtive channels, closing the first two and requesting 4 channels in a row will trigger this soft lockup. The bug is that the search loop forgets to skip over the range once it detects that one channel in that range is occupied. Restore the original intent to the logic by fixing the omission. Signed-off-by:
Zhi Jin <zhi.jin@intel.com> Signed-off-by:
Alexander Shishkin <alexander.shishkin@linux.intel.com> Fixes: 7bd1d409 ("stm class: Introduce an abstraction for System Trace Module devices") CC: stable@vger.kernel.org # v4.4+ Signed-off-by:
-
Alexander Usyskin authored
commit b5958faa upstream. Fix unbalanced module reference counting during internal reset, which prevents the drivers unloading. Tracking mei_me/txe modules on mei client bus via mei_cldev_enable/disable is error prone due to possible internal reset flow, where clients are disconnected underneath. Moving reference counting to probe and release of mei bus client driver solves this issue in simplest way, as each client provides only a single connection to a client bus driver. Cc: <stable@vger.kernel.org> Signed-off-by:
Alexander Usyskin <alexander.usyskin@intel.com> Signed-off-by:
Tomas Winkler <tomas.winkler@intel.com> Signed-off-by:
-
Alexander Usyskin authored
commit 37fd0b62 upstream. The list of supported functions can be altered upon link reset, clean the flags to allow correct selections of supported features. Cc: <stable@vger.kernel.org> v4.19+ Signed-off-by:
-
Krzysztof Kozlowski authored
commit 2ea8bab4 upstream. Fix NULL pointer exception on device unbind when device tree does not contain "has-touchscreen" property. In such case the input device is not registered so it should not be unregistered. $ echo "12d10000.adc" > /sys/bus/platform/drivers/exynos-adc/unbind Unable to handle kernel NULL pointer dereference at virtual address 00000474 ... (input_unregister_device) from [<c0772060>] (exynos_adc_remove+0x20/0x80) (exynos_adc_remove) from [<c0587d5c>] (platform_drv_remove+0x20/0x40) (platform_drv_remove) from [<c05860f0>] (device_release_driver_internal+0xdc/0x1ac) (device_release_driver_internal) from [<c0583ecc>] (unbind_store+0x60/0xd4) (unbind_store) from [<c031b89c>] (kernfs_fop_write+0x100/0x1e0) (kernfs_fop_write) from [<c029709c>] (__vfs_write+0x2c/0x17c) (__vfs_write) from [<c0297374>] (vfs_write+0xa4/0x184) (vfs_write) from [<c0297594>] (ksys_write+0x4c/0xac) (ksys_write) from [<c0101000>] (ret_fast_syscall+0x0/0x28) Fixes: 2bb8ad9b ("iio: exynos-adc: add experimental touchscreen support") Cc: <stable@vger.kernel.org> Signed-off-by:
Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by:
Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by:
-
Codrin Ciubotariu authored
commit 05bd7fcd upstream. The ADCs are sleeping when the SLEEP bit is set and running when it's cleared, so the bit should be inverted. Tested on pcm1863. Signed-off-by:
Codrin Ciubotariu <codrin.ciubotariu@microchip.com> Acked-by:
Andrew F. Davis <afd@ti.com> Signed-off-by:
-
Codrin Ciubotariu authored
commit fcf4daab upstream. According to DS, the gain is between -12 dB and 40 dB, with a 0.5 dB step. Tested on pcm1863. Signed-off-by:
-
S.j. Wang authored
commit cc29ea00 upstream. The ESAI_xCR_xWA is xCR's bit, not the xCCR's bit, driver set it to wrong register, correct it. Fixes 43d24e76 ("ASoC: fsl_esai: Add ESAI CPU DAI driver") Cc: <stable@vger.kernel.org> Signed-off-by:
Shengjiu Wang <shengjiu.wang@nxp.com> Reviewed-by:
Fabio Estevam <festevam@gmail.com> Ackedy-by:
Nicolin Chen <nicoleotsuka@gmail.com> Signed-off-by:
-
zhengbin authored
commit bb06c388 upstream. If msize is less than 4096, we should close and put trans, destroy tagpool, not just free client. This patch fixes that. Link: http://lkml.kernel.org/m/1552464097-142659-1-git-send-email-zhengbin13@huawei.com Cc: stable@vger.kernel.org Fixes: 574d356b ("9p/net: put a lower bound on msize") Reported-by:
Hulk Robot <hulkci@huawei.com> Signed-off-by:
zhengbin <zhengbin13@huawei.com> Signed-off-by:
Dominique Martinet <dominique.martinet@cea.fr> Signed-off-by:
-
Hou Tao authored
commit 5e3cc1ee upstream. Use inode->i_lock to protect i_size_write(), else i_size_read() in generic_fillattr() may loop infinitely in read_seqcount_begin() when multiple processes invoke v9fs_vfs_getattr() or v9fs_vfs_getattr_dotl() simultaneously under 32-bit SMP environment, and a soft lockup will be triggered as show below: watchdog: BUG: soft lockup - CPU#5 stuck for 22s! [stat:2217] Modules linked in: CPU: 5 PID: 2217 Comm: stat Not tainted 5.0.0-rc1-00005-g7f702faf5a9e #4 Hardware name: Generic DT based system PC is at generic_fillattr+0x104/0x108 LR is at 0xec497f00 pc : [<802b8898>] lr : [<ec497f00>] psr: 200c0013 sp : ec497e20 ip : ed608030 fp : ec497e3c r10: 00000000 r9 : ec497f00 r8 : ed608030 r7 : ec497ebc r6 : ec497f00 r5 : ee5c1550 r4 : ee005780 r3 : 0000052d r2 : 00000000 r1 : ec497f00 r0 : ed608030 Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none Control: 10c5387d Table: ac48006a DAC: 00000051 CPU: 5 PID: 2217 Comm: stat Not tainted 5.0.0-rc1-00005-g7f702faf5a9e #4 Hardware name: Generic DT based system Backtrace: [<8010d974>] (dump_backtrace) from [<8010dc88>] (show_stack+0x20/0x24) [<8010dc68>] (show_stack) from [<80a1d194>] (dump_stack+0xb0/0xdc) [<80a1d0e4>] (dump_stack) from [<80109f34>] (show_regs+0x1c/0x20) [<80109f18>] (show_regs) from [<801d0a80>] (watchdog_timer_fn+0x280/0x2f8) [<801d0800>] (watchdog_timer_fn) from [<80198658>] (__hrtimer_run_queues+0x18c/0x380) [<801984cc>] (__hrtimer_run_queues) from [<80198e60>] (hrtimer_run_queues+0xb8/0xf0) [<80198da8>] (hrtimer_run_queues) from [<801973e8>] (run_local_timers+0x28/0x64) [<801973c0>] (run_local_timers) from [<80197460>] (update_process_times+0x3c/0x6c) [<80197424>] (update_process_times) from [<801ab2b8>] (tick_nohz_handler+0xe0/0x1bc) [<801ab1d8>] (tick_nohz_handler) from [<80843050>] (arch_timer_handler_virt+0x38/0x48) [<80843018>] (arch_timer_handler_virt) from [<80180a64>] (handle_percpu_devid_irq+0x8c/0x240) [<801809d8>] (handle_percpu_devid_irq) from [<8017ac20>] (generic_handle_irq+0x34/0x44) [<8017abec>] (generic_handle_irq) from [<8017b344>] (__handle_domain_irq+0x6c/0xc4) [<8017b2d8>] (__handle_domain_irq) from [<801022e0>] (gic_handle_irq+0x4c/0x88) [<80102294>] (gic_handle_irq) from [<80101a30>] (__irq_svc+0x70/0x98) [<802b8794>] (generic_fillattr) from [<8056b284>] (v9fs_vfs_getattr_dotl+0x74/0xa4) [<8056b210>] (v9fs_vfs_getattr_dotl) from [<802b8904>] (vfs_getattr_nosec+0x68/0x7c) [<802b889c>] (vfs_getattr_nosec) from [<802b895c>] (vfs_getattr+0x44/0x48) [<802b8918>] (vfs_getattr) from [<802b8a74>] (vfs_statx+0x9c/0xec) [<802b89d8>] (vfs_statx) from [<802b9428>] (sys_lstat64+0x48/0x78) [<802b93e0>] (sys_lstat64) from [<80101000>] (ret_fast_syscall+0x0/0x28) [dominique.martinet@cea.fr: updated comment to not refer to a function in another subsystem] Link: http://lkml.kernel.org/r/20190124063514.8571-2-houtao1@huawei.com Cc: stable@vger.kernel.org Fixes: 7549ae3e ("9p: Use the i_size_[read, write]() macros instead of using inode->i_size directly.") Reported-by:
Xing Gaopeng <xingaopeng@huawei.com> Signed-off-by:
Hou Tao <houtao1@huawei.com> Signed-off-by:
-
Hans Verkuil authored
commit 5e99456c upstream. Userspace shouldn't set bytesused to 0 for output buffers. vb2_warn_zero_bytesused() warns about this (only once!), but it also calls WARN_ON(1), which is confusing since it is not immediately clear that it warns about a 0 value for bytesused. Just drop the WARN_ON as it serves no purpose. Signed-off-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Acked-by:
Ezequiel Garcia <ezequiel@collabora.com> Signed-off-by:
Mauro Carvalho Chehab <mchehab+samsung@kernel.org> Cc: Matthias Maennich <maennich@google.com> Signed-off-by:
-
- 19 Mar, 2019 3 commits
-
-
Greg Kroah-Hartman authored
-
Zha Bin authored
commit 7fbe078c upstream. The vsock core only supports 32bit CID, but the Virtio-vsock spec define CID (dst_cid and src_cid) as u64 and the upper 32bits is reserved as zero. This inconsistency causes one bug in vhost vsock driver. The scenarios is: 0. A hash table (vhost_vsock_hash) is used to map an CID to a vsock object. And hash_min() is used to compute the hash key. hash_min() is defined as: (sizeof(val) <= 4 ? hash_32(val, bits) : hash_long(val, bits)). That means the hash algorithm has dependency on the size of macro argument 'val'. 0. In function vhost_vsock_set_cid(), a 64bit CID is passed to hash_min() to compute the hash key when inserting a vsock object into the hash table. 0. In function vhost_vsock_get(), a 32bit CID is passed to hash_min() to compute the hash key when looking up a vsock for an CID. Because the different size of the CID, hash_min() returns different hash key, thus fails to look up the vsock object for an CID. To fix this bug, we keep CID as u64 in the IOCTLs and virtio message headers, but explicitly convert u64 to u32 when deal with the hash table and vsock core. Fixes: 834e772c ("vhost/vsock: fix use-after-free in network stack callers") Link: https://github.com/stefanha/virtio/blob/vsock/trunk/content.texSigned-off-by:
Zha Bin <zhabin@linux.alibaba.com> Reviewed-by:
Liu Jiang <gerry@linux.alibaba.com> Reviewed-by:
Stefan Hajnoczi <stefanha@redhat.com> Acked-by:
Jason Wang <jasowang@redhat.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Shengjing Zhu <i@zhsj.me> Signed-off-by:
-
Björn Töpel authored
commit cdec2141 upstream. When XDP is enabled, the driver will report incorrect statistics. Received frames will reported as transmitted frames. This commits fixes the i40e implementation of ndo_get_stats64 (struct net_device_ops), so that iproute2 will report correct statistics (e.g. when running "ip -stats link show dev eth0") even when XDP is enabled. Reported-by:
Jesper Dangaard Brouer <brouer@redhat.com> Fixes: 74608d17 ("i40e: add support for XDP_TX action") Signed-off-by:
Björn Töpel <bjorn.topel@intel.com> Tested-by:
Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by:
Jeff Kirsher <jeffrey.t.kirsher@intel.com> Cc: Emeric Brun <ebrun@haproxy.com> Signed-off-by:
-
