- 13 Mar, 2020 40 commits
-
-
Andy Shevchenko authored
BugLink: https://bugs.launchpad.net/bugs/1864773 [ Upstream commit e7b8514e ] There is a possibility to have registered ACPI DMA controller while it has been gone already. To avoid the potential crash, move to non-managed acpi_dma_controller_register(). Fixes: 42c91ee7 ("dw_dmac: add ACPI support") Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20190820131546.75744-8-andriy.shevchenko@linux.intel.comSigned-off-by:
Vinod Koul <vkoul@kernel.org> Signed-off-by:
Sasha Levin <sashal@kernel.org> Signed-off-by:
Khalid Elmously <khalid.elmously@canonical.com> Signed-off-by:
Kleber Sacilotto de Souza <kleber.souza@canonical.com>
-
Eric W. Biederman authored
BugLink: https://bugs.launchpad.net/bugs/1864773 [ Upstream commit 33da8e7c ] My recent to change to only use force_sig for a synchronous events wound up breaking signal reception cifs and drbd. I had overlooked the fact that by default kthreads start out with all signals set to SIG_IGN. So a change I thought was safe turned out to have made it impossible for those kernel thread to catch their signals. Reverting the work on force_sig is a bad idea because what the code was doing was very much a misuse of force_sig. As the way force_sig ultimately allowed the signal to happen was to change the signal handler to SIG_DFL. Which after the first signal will allow userspace to send signals to these kernel threads. At least for wake_ack_receiver in drbd that does not appear actively wrong. So correct this problem by adding allow_kernel_signal that will allow signals whose siginfo reports they were sent by the kernel through, but will not allow userspace generated signals, and update cifs and drbd to call allow_kernel_signal in an appropriate place so that their thread can receive this signal. Fixing things this way ensures that userspace won't be able to send signals and cause problems, that it is clear which signals the threads are expecting to receive, and it guarantees that nothing else in the system will be affected. This change was partly inspired by similar cifs and drbd patches that added allow_signal. Reported-by:
ronnie sahlberg <ronniesahlberg@gmail.com> Reported-by:
Christoph Böhmwalder <christoph.boehmwalder@linbit.com> Tested-by:
"Eric W. Biederman" <ebiederm@xmission.com> Signed-off-by:
-
YueHaibing authored
BugLink: https://bugs.launchpad.net/bugs/1864773 [ Upstream commit 554b75bd ] sound/soc/codecs/wm8737.c:112:29: warning: high_3d defined but not used [-Wunused-const-variable=] 'high_3d' should be used for 3D High Cut-off. Reported-by:
Hulk Robot <hulkci@huawei.com> Fixes: 2a9ae13a ("ASoC: Add initial WM8737 driver") Signed-off-by:
YueHaibing <yuehaibing@huawei.com> Acked-by:
Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://lore.kernel.org/r/20190815091920.64480-1-yuehaibing@huawei.comSigned-off-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
-
YueHaibing authored
BugLink: https://bugs.launchpad.net/bugs/1864773 [ Upstream commit 9b4275c4 ] sound/soc/codecs/cs4349.c:358:32: warning: cs4349_runtime_pm defined but not used [-Wunused-const-variable=] cs4349_runtime_pm ops already defined, it seems we should enable it. Reported-by:
-
YueHaibing authored
BugLink: https://bugs.launchpad.net/bugs/1864773 [ Upstream commit 630742c2 ] It seems 'es8328_rline_enum' should be used in es8328_right_line_controls Fixes: 567e4f98 ("ASoC: add es8328 codec driver") Signed-off-by:
-
Colin Ian King authored
BugLink: https://bugs.launchpad.net/bugs/1864773 [ Upstream commit 7a14826e ] Currently when the call to ext4_htree_store_dirent fails the error return variable 'ret' is is not being set to the error code and variable count is instead, hence the error code is not being returned. Fix this by assigning ret to the error return code. Addresses-Coverity: ("Unused value") Fixes: 8af0f082 ("ext4: fix readdir error in the case of inline_data+dir_index") Signed-off-by:
Colin Ian King <colin.king@canonical.com> Signed-off-by:
Theodore Ts'o <tytso@mit.edu> Signed-off-by:
-
Iuliana Prodan authored
BugLink: https://bugs.launchpad.net/bugs/1864773 [ Upstream commit c59a1d41 ] Check the return value of the hardware registration for caam_rng and free resources in case of failure. Fixes: e24f7c9e ("crypto: caam - hwrng support") Signed-off-by:
Iuliana Prodan <iuliana.prodan@nxp.com> Reviewed-by:
Horia Geanta <horia.geanta@nxp.com> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
-
Steve French authored
BugLink: https://bugs.launchpad.net/bugs/1864773 [ Upstream commit 247bc947 ] Fixes: 72abe3bc ("signal/cifs: Fix cifs_put_tcp_session to call send_sig instead of force_sig") The global change from force_sig caused module unloading of cifs.ko to fail (since the cifsd process could not be killed, "rmmod cifs" now would always fail) Signed-off-by:
Steve French <stfrench@microsoft.com> Reviewed-by:
Ronnie Sahlberg <lsahlber@redhat.com> CC: Eric W. Biederman <ebiederm@xmission.com> Signed-off-by:
-
Johannes Berg authored
BugLink: https://bugs.launchpad.net/bugs/1864773 [ Upstream commit f474808a ] A lot of places in the driver use onyx_read_register() without checking the return value, and it's been working OK for ~10 years or so, so probably never fails ... Rather than trying to check the return value everywhere, which would be relatively intrusive, at least make sure we don't use an uninitialized value. Fixes: f3d9478b ("[ALSA] snd-aoa: add snd-aoa") Reported-by:
Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by:
Johannes Berg <johannes@sipsolutions.net> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Thomas Gleixner authored
BugLink: https://bugs.launchpad.net/bugs/1864773 [ Upstream commit 2591bc4e ] apic->send_IPI_allbutself() takes a vector number as argument. APIC_DM_NMI is clearly not a vector number. It's defined to 0x400 which is outside the vector space. Use NMI_VECTOR instead as that's what it is intended to be. Fixes: 82da3ff8 ("x86: kgdb support") Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Acked-by:
Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://lkml.kernel.org/r/20190722105218.855189979@linutronix.deSigned-off-by:
-
Arnd Bergmann authored
BugLink: https://bugs.launchpad.net/bugs/1864773 [ Upstream commit bc83f79b ] Generally, declaring a platform device as a static variable is a bad idea and can cause all kinds of problems, in particular with the DMA configuration and lifetime rules. A specific problem we hit here is from a bug in clang that warns about certain (otherwise valid) macros when used in static variables: drivers/misc/mic/card/mic_x100.c:285:27: warning: shift count >= width of type [-Wshift-count-overflow] static u64 mic_dma_mask = DMA_BIT_MASK(64); ^~~~~~~~~~~~~~~~ include/linux/dma-mapping.h:141:54: note: expanded from macro 'DMA_BIT_MASK' #define DMA_BIT_MASK(n) (((n) == 64) ? ~0ULL : ((1ULL<<(n))-1)) ^ ~~~ A slightly better way here is to create the platform device dynamically and set the dma mask in the probe function. This avoids the warning and some other problems, but is still not ideal because the device creation should really be separated from the driver, and the fact that the device has no parent means we have to force the dma mask rather than having it set up from the bus that the device is actually on. Fixes: dd8d8d44 ("misc: mic: MIC card driver specific changes to enable SCIF") Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Link: https://lore.kernel.org/r/20190712092426.872625-1-arnd@arndb.deSigned-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
-
Ruslan Bilovol authored
BugLink: https://bugs.launchpad.net/bugs/1864773 [ Upstream commit 6269e4c7 ] Don't do extra cpu_to_le32 conversion for put_unaligned_le32 because it is already implemented in this function. Fixes sparse error: xhci-hub.c:1152:44: warning: incorrect type in argument 1 (different base types) xhci-hub.c:1152:44: expected unsigned int [usertype] val xhci-hub.c:1152:44: got restricted __le32 [usertype] Fixes: 395f5409 "xhci: support new USB 3.1 hub request to get extended port status" Cc: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by:
Ruslan Bilovol <ruslan.bilovol@gmail.com> Link: https://lore.kernel.org/r/1562501839-26522-1-git-send-email-ruslan.bilovol@gmail.comSigned-off-by:
-
YueHaibing authored
BugLink: https://bugs.launchpad.net/bugs/1864773 [ Upstream commit 2ec4ad49 ] It seems we should use 'range' instead of 'priv->range' in lbtf_geo_init(), because 'range' is the corret one related to current regioncode. Reported-by:
Kalle Valo <kvalo@codeaurora.org> Signed-off-by:
-
Colin Ian King authored
BugLink: https://bugs.launchpad.net/bugs/1864773 [ Upstream commit 41a6bf65 ] Currently if lport is null then the null lport pointer is dereference when printing out debug via the FC_LPORT_DB macro. Fix this by using the more generic FC_LIBFC_DBG debug macro instead that does not use lport. Addresses-Coverity: ("Dereference after null check") Fixes: 7414705e ("libfc: Add runtime debugging with debug_logging module parameter") Signed-off-by:
Hannes Reinecke <hare@suse.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by:
-
Wen Yang authored
BugLink: https://bugs.launchpad.net/bugs/1864773 [ Upstream commit faf5577f ] The phy_dn variable is still being used in of_phy_connect() after the of_node_put() call, which may result in use-after-free. Fixes: 1dd2d06c ("net: Rework pasemi_mac driver to use of_mdio infrastructure") Signed-off-by:
Wen Yang <wen.yang99@zte.com.cn> Cc: "David S. Miller" <davem@davemloft.net> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Luis Chamberlain <mcgrof@kernel.org> Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: netdev@vger.kernel.org Cc: linux-kernel@vger.kernel.org Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Arnd Bergmann authored
BugLink: https://bugs.launchpad.net/bugs/1864773 [ Upstream commit 9dea44c9 ] devm_ioremap_resource() does not currently take 'const' arguments, which results in a warning from the first driver trying to do it anyway: drivers/gpio/gpio-amd-fch.c: In function 'amd_fch_gpio_probe': drivers/gpio/gpio-amd-fch.c:171:49: error: passing argument 2 of 'devm_ioremap_resource' discards 'const' qualifier from pointer target type [-Werror=discarded-qualifiers] priv->base = devm_ioremap_resource(&pdev->dev, &amd_fch_gpio_iores); ^~~~~~~~~~~~~~~~~~~ Change the prototype to allow it, as there is no real reason not to. Fixes: 9bb2e0452508 ("gpio: amd: Make resource struct const") Signed-off-by:
Enrico Weigelt <info@metux.net> Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
Andy Shevchenko authored
BugLink: https://bugs.launchpad.net/bugs/1864773 [ Upstream commit 02f36911 ] ida instances allocate some internal memory for ->free_bitmap in addition to the base 'struct ida'. Use ida_destroy() to release that memory at module_exit(). Fixes: 4b45efe8 ("mfd: Add support for Intel Sunrisepoint LPSS devices") Signed-off-by:
Lee Jones <lee.jones@linaro.org> Signed-off-by:
-
Kevin Mitchell authored
BugLink: https://bugs.launchpad.net/bugs/1864773 [ Upstream commit 3ddbe913 ] Make it safe to call iommu_disable during early init error conditions before mmio_base is set, but after the struct amd_iommu has been added to the amd_iommu_list. For example, this happens if firmware fails to fill in mmio_phys in the ACPI table leading to a NULL pointer dereference in iommu_feature_disable. Fixes: 2c0ae172 ('iommu/amd: Convert iommu initialization to state machine') Signed-off-by:
Kevin Mitchell <kevmitch@arista.com> Signed-off-by:
Joerg Roedel <jroedel@suse.de> Signed-off-by:
-
Rob Clark authored
BugLink: https://bugs.launchpad.net/bugs/1864773 [ Upstream commit f47bee2b ] These regs are write-only, and the hw throws a hissy-fit (ie. reboots) when we try to read them for GPU state snapshot, in response to a GPU hang. It is rather impolite when GPU recovery triggers an insta- reboot, so lets remove the TPL1 registers from the snapshot. Fixes: 7198e6b0 drm/msm: add a3xx gpu support Signed-off-by:
Rob Clark <robdclark@chromium.org> Reviewed-by:
Jordan Crouse <jcrouse@codeaurora.org> Signed-off-by:
-
Chen-Yu Tsai authored
BugLink: https://bugs.launchpad.net/bugs/1864773 [ Upstream commit 3572e8ae ] Besides the alarm, the PCF8563 also has a timer triggered interrupt. In cases where the previous system left the timer and interrupts on, or somehow the bits got enabled, the interrupt would keep triggering as the kernel doesn't know about it. Clear both the alarm and timer event flags, and disable the interrupts, before requesting the interrupt line. Fixes: ede3e9d4 ("drivers/rtc/rtc-pcf8563.c: add alarm support") Fixes: a45d528a ("rtc: pcf8563: clear expired alarm at boot time") Signed-off-by:
Chen-Yu Tsai <wens@csie.org> Signed-off-by:
Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by:
-
Peter Ujfalusi authored
BugLink: https://bugs.launchpad.net/bugs/1864773 [ Upstream commit fd14f443 ] If multiple serializers are connected in the system and the number of channels will need to use more than one serializer the mask to enable the serializers were left to 0 if tdm_mask is provided Fixes: dd55ff83 ("ASoC: davinci-mcasp: Add set_tdm_slots() support") Signed-off-by:
Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by:
-
Julian Wiedmann authored
BugLink: https://bugs.launchpad.net/bugs/1864773 [ Upstream commit 06996c1d ] Even when running as VM guest (ie pr_iucv != NULL), af_iucv can still open HiperTransport-based connections. For robust operation these connections require the af_iucv_netdev_notifier, so register it unconditionally. Also handle any error that register_netdevice_notifier() returns. Fixes: 9fbd87d4 ("af_iucv: handle netdev events") Signed-off-by:
Julian Wiedmann <jwi@linux.ibm.com> Reviewed-by:
Ursula Braun <ubraun@linux.ibm.com> Signed-off-by:
-
Jeffrey Hugo authored
BugLink: https://bugs.launchpad.net/bugs/1864773 [ Upstream commit fc19cbb7 ] If mdp5_cfg_init fails because of an unknown major version, a null pointer dereference occurs. This is because the caller of init expects error pointers, but init returns NULL on error. Fix this by returning the expected values on error. Fixes: 2e362e17 (drm/msm/mdp5: introduce mdp5_cfg module) Signed-off-by:
Jeffrey Hugo <jeffrey.l.hugo@gmail.com> Reviewed-by:
Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by:
-
Nathan Lynch authored
BugLink: https://bugs.launchpad.net/bugs/1864773 [ Upstream commit d4aa219a ] Allow external callers to force the cacheinfo code to release all its references to cache nodes, e.g. before processing device tree updates post-migration, and to rebuild the hierarchy afterward. CPU online/offline must be blocked by callers; enforce this. Fixes: 410bccf9 ("powerpc/pseries: Partition migration in the kernel") Signed-off-by:
Nathan Lynch <nathanl@linux.ibm.com> Reviewed-by:
Gautham R. Shenoy <ego@linux.vnet.ibm.com> Signed-off-by:
Michael Ellerman <mpe@ellerman.id.au> Signed-off-by:
-
Colin Ian King authored
BugLink: https://bugs.launchpad.net/bugs/1864773 [ Upstream commit d4ec9550 ] The assigment of FB_VMODE_NONINTERLACE to var->vmode should be a bit-wise or of FB_VMODE_NONINTERLACE instead of an assignment, otherwise the previous clearing of the FB_VMODE_MASK bits of var->vmode makes no sense and is redundant. Addresses-Coverity: ("Unused value") Fixes: ad4e02d5 ("[media] vivid: add a simple framebuffer device for overlay testing") Signed-off-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by:
Mauro Carvalho Chehab <mchehab+samsung@kernel.org> Signed-off-by:
-
Eric Dumazet authored
BugLink: https://bugs.launchpad.net/bugs/1864773 [ Upstream commit ae7352d3 ] Both IPv6 and 6lowpan are calling inet_frags_fini() too soon. inet_frags_fini() is dismantling a kmem_cache, that might be needed later when unregister_pernet_subsys() eventually has to remove frags queues from hash tables and free them. This fixes potential use-after-free, and is a prereq for the following patch. Fixes: d4ad4d22 ("inet: frags: use kmem_cache for inet_frag_queue") Signed-off-by:
Eric Dumazet <edumazet@google.com> Signed-off-by:
-
Eric W. Biederman authored
BugLink: https://bugs.launchpad.net/bugs/1864773 [ Upstream commit 72abe3bc ] The locking in force_sig_info is not prepared to deal with a task that exits or execs (as sighand may change). The is not a locking problem in force_sig as force_sig is only built to handle synchronous exceptions. Further the function force_sig_info changes the signal state if the signal is ignored, or blocked or if SIGNAL_UNKILLABLE will prevent the delivery of the signal. The signal SIGKILL can not be ignored and can not be blocked and SIGNAL_UNKILLABLE won't prevent it from being delivered. So using force_sig rather than send_sig for SIGKILL is confusing and pointless. Because it won't impact the sending of the signal and and because using force_sig is wrong, replace force_sig with send_sig. Cc: Namjae Jeon <namjae.jeon@samsung.com> Cc: Jeff Layton <jlayton@primarydata.com> Cc: Steve French <smfrench@gmail.com> Fixes: a5c3e1c7 ("Revert "cifs: No need to send SIGKILL to demux_thread during umount"") Fixes: e7ddee90 ("cifs: disable sharing session and tcon and add new TCP sharing code") Signed-off-by:
-
Lu Baolu authored
BugLink: https://bugs.launchpad.net/bugs/1864773 [ Upstream commit 57274ea2 ] The iommu_group_get_for_dev() will allocate a group for a device if it isn't in any group. This isn't the use case in iommu_request_dm_for_dev(). Let's use iommu_group_get() instead. Fixes: d290f1e7 ("iommu: Introduce iommu_request_dm_for_dev()") Signed-off-by:
Lu Baolu <baolu.lu@linux.intel.com> Signed-off-by:
-
Nathan Chancellor authored
BugLink: https://bugs.launchpad.net/bugs/1864773 [ Upstream commit b0576f9e ] Clang warns: drivers/misc/sgi-xp/xpc_partition.c:73:14: warning: variable 'buf' is uninitialized when used within its own initialization [-Wuninitialized] void *buf = buf; ~~~ ^~~ 1 warning generated. Arnd's explanation during review: /* * Returns the physical address of the partition's reserved page through * an iterative number of calls. * * On first call, 'cookie' and 'len' should be set to 0, and 'addr' * set to the nasid of the partition whose reserved page's address is * being sought. * On subsequent calls, pass the values, that were passed back on the * previous call. * * While the return status equals SALRET_MORE_PASSES, keep calling * this function after first copying 'len' bytes starting at 'addr' * into 'buf'. Once the return status equals SALRET_OK, 'addr' will * be the physical address of the partition's reserved page. If the * return status equals neither of these, an error as occurred. */ static inline s64 sn_partition_reserved_page_pa(u64 buf, u64 *cookie, u64 *addr, u64 *len) so *len is set to zero on the first call and tells the bios how many bytes are accessible at 'buf', and it does get updated by the BIOS to tell us how many bytes it needs, and then we allocate that and try again. Fixes: 27929029 ("[IA64-SGI] cleanup the way XPC locates the reserved page") Link: https://github.com/ClangBuiltLinux/linux/issues/466Suggested-by:
Stephen Hines <srhines@google.com> Reviewed-by:
Nick Desaulniers <ndesaulniers@google.com> Signed-off-by:
Nathan Chancellor <natechancellor@gmail.com> Signed-off-by:
-
Christophe Leroy authored
BugLink: https://bugs.launchpad.net/bugs/1864773 [ Upstream commit 44a04218 ] spi_finalize_current_message() shall be called once all actions are finished, otherwise the last actions might step over a newly started transfer. Fixes: c592becb ("spi: fsl-(e)spi: migrate to generic master queueing") Signed-off-by:
Christophe Leroy <christophe.leroy@c-s.fr> Signed-off-by:
-
Matthias Kaehlcke authored
BugLink: https://bugs.launchpad.net/bugs/1864773 [ Upstream commit bf45ac18 ] The CPU load values passed to the thermal_power_cpu_get_power tracepoint are zero for all CPUs, unless, unless the thermal_power_cpu_limit tracepoint is enabled too: irq/41-rockchip-98 [000] .... 290.972410: thermal_power_cpu_get_power: cpus=0000000f freq=1800000 load={{0x0,0x0,0x0,0x0}} dynamic_power=4815 vs irq/41-rockchip-96 [000] .... 95.773585: thermal_power_cpu_get_power: cpus=0000000f freq=1800000 load={{0x56,0x64,0x64,0x5e}} dynamic_power=4959 irq/41-rockchip-96 [000] .... 95.773596: thermal_power_cpu_limit: cpus=0000000f freq=408000 cdev_state=10 power=416 There seems to be no good reason for omitting the CPU load information depending on another tracepoint. My guess is that the intention was to check whether thermal_power_cpu_get_power is (still) enabled, however 'load_cpu != NULL' already indicates that it was at least enabled when cpufreq_get_requested_power() was entered, there seems little gain from omitting the assignment if the tracepoint was just disabled, so just remove the check. Fixes: 6828a471 ("thermal: add trace events to the power allocator governor") Signed-off-by:
Matthias Kaehlcke <mka@chromium.org> Reviewed-by:
Daniel Lezcano <daniel.lezcano@linaro.org> Acked-by:
Javi Merino <javi.merino@kernel.org> Acked-by:
Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by:
Eduardo Valentin <edubezval@gmail.com> Signed-off-by:
-
Brian Masney authored
BugLink: https://bugs.launchpad.net/bugs/1864773 [ Upstream commit d3f48ec0 ] lm3630a_bank_a_update_status() and lm3630a_bank_b_update_status() both return the brightness value if the brightness was successfully updated. Writing to these attributes via sysfs would cause a 'Bad address' error to be returned. These functions should return 0 on success, so let's change it to correct that error. Fixes: 28e64a68 ("backlight: lm3630: apply chip revision") Signed-off-by:
Brian Masney <masneyb@onstation.org> Acked-by:
Pavel Machek <pavel@ucw.cz> Acked-by:
Daniel Thompson <daniel.thompson@linaro.org> Signed-off-by:
-
Dan Carpenter authored
BugLink: https://bugs.launchpad.net/bugs/1864773 [ Upstream commit b586627e ] The "whichcpu" comes from argv[3]. The cpu_online() macro looks up the cpu in a bitmap of online cpus, but if the value is too high then it could read beyond the end of the bitmap and possibly Oops. Fixes: 5d5314d6 ("kdb: core for kgdb back end (1 of 2)") Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by:
Douglas Anderson <dianders@chromium.org> Signed-off-by:
-
Russell King authored
BugLink: https://bugs.launchpad.net/bugs/1864773 [ Upstream commit 63a0666b ] Fix lack of keyboard interrupts for RiscPC due to incorrect conversion. Fixes: e8d36d5d ("ARM: kill off set_irq_flags usage") Signed-off-by:
Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by:
-
Florian Westphal authored
BugLink: https://bugs.launchpad.net/bugs/1864773 [ Upstream commit 680f6af5 ] If userspace provides a rule blob with trailing data after last target, we trigger a splat, then convert ruleset to 64bit format (with trailing data), then pass that to do_replace_finish() which then returns -EINVAL. Erroring out right away avoids the splat plus unneeded translation and error unwind. Fixes: 81e675c2 ("netfilter: ebtables: add CONFIG_COMPAT support") Reported-by:
Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp> Signed-off-by:
Florian Westphal <fw@strlen.de> Signed-off-by:
Pablo Neira Ayuso <pablo@netfilter.org> Signed-off-by:
-
Dan Carpenter authored
BugLink: https://bugs.launchpad.net/bugs/1864773 [ Upstream commit 6d1f8b3d ] The "out_data" variable is uninitialized at the point. Originally, this used to print "status" instead and that seems like the correct thing to print. Fixes: bc2ef884 ("alienware-wmi: For WMAX HDMI method, introduce a way to query HDMI cable status") Signed-off-by:
Mario Limonciello <mario.limonciello@dell.com> Signed-off-by:
-
Dan Carpenter authored
BugLink: https://bugs.launchpad.net/bugs/1864773 [ Upstream commit b72845ee ] In vpbe_enum_outputs() we check if (temp_index >= cfg->num_outputs) but the problem is that "temp_index" can be negative. This patch changes the types to unsigned to address this array underflow bug. Fixes: 66715cdc ("[media] davinci vpbe: VPBE display driver") Signed-off-by:
"Lad, Prabhakar" <prabhakar.csengg@gmail.com> Signed-off-by:
-
Dan Carpenter authored
BugLink: https://bugs.launchpad.net/bugs/1864773 [ Upstream commit dd6e2a98 ] The "b->index" is a u32 the comes from the user in the ioctl. It hasn't been checked. We aren't supposed to use it but we're instead supposed to use the value that gets written to it when we call videobuf_dqbuf(). The videobuf_dqbuf() first memsets it to zero and then re-initializes it inside the videobuf_status() function. It's this final value which we want. Hans Verkuil pointed out that we need to check the return from videobuf_dqbuf(). I ended up doing a little cleanup related to that as well. Fixes: 72915e85 ("[media] V4L2: OMAP: VOUT: dma map and unmap v4l2 buffers in qbuf and dqbuf") Signed-off-by:
-
Lu Baolu authored
BugLink: https://bugs.launchpad.net/bugs/1864773 [ Upstream commit 5daab580 ] The kernel parameter igfx_off is used by users to disable DMA remapping for the Intel integrated graphic device. It was designed for bare metal cases where a dedicated IOMMU is used for graphic. This doesn't apply to virtual IOMMU case where an include-all IOMMU is used. This makes the kernel parameter work with virtual IOMMU as well. Cc: Ashok Raj <ashok.raj@intel.com> Cc: Jacob Pan <jacob.jun.pan@linux.intel.com> Suggested-by:
Kevin Tian <kevin.tian@intel.com> Fixes: c0771df8 ("intel-iommu: Export a flag indicating that the IOMMU is used for iGFX.") Signed-off-by:
Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by:
-
Jack Morgenstein authored
BugLink: https://bugs.launchpad.net/bugs/1864773 [ Upstream commit 8f4426aa ] The QP transition optional parameters for the various transition for XRC QPs are identical to those for RC QPs. Many of the XRC QP transition optional parameter bits are missing from the QP optional mask table. These omissions caused failures when doing XRC QP state transitions. For example, when trying to change the response timer of an XRC receive QP via the RTS2RTS transition, the new timer value was ignored because MLX5_QP_OPTPAR_RNR_TIMEOUT bit was missing from the optional params mask for XRC qps for the RTS2RTS transition. Fix this by adding the missing XRC optional parameters for all QP transitions to the opt_mask table. Fixes: e126ba97 ("mlx5: Add driver for Mellanox Connect-IB adapters") Fixes: a4774e90 ("IB/mlx5: Fix opt param mask according to firmware spec") Signed-off-by:
Jack Morgenstein <jackm@dev.mellanox.co.il> Signed-off-by:
Leon Romanovsky <leonro@mellanox.com> Signed-off-by:
Jason Gunthorpe <jgg@mellanox.com> Signed-off-by:
-
