- 01 Dec, 2019 40 commits
-
-
Duncan Laurie authored
[ Upstream commit 655603de ] The sysfs handler should return the number of bytes consumed, which in the case of a successful write is the entire buffer. Also fix a bug where param.data_len was being set to (count - (2 * sizeof(u32))) instead of just (count - sizeof(u32)). The latter is correct because we skip over the leading u32 which is our param.type, but we were also incorrectly subtracting sizeof(u32) on the line where we were actually setting param.data_len: param.data_len = count - sizeof(u32); This meant that for our example event.kernel_software_watchdog with total length 10 bytes, param.data_len was just 2 prior to this change. To test, successfully append an event to the log with gsmi sysfs. This sample event is for a "Kernel Software Watchdog" > xxd -g 1 event.kernel_software_watchdog 0000000: 01 00 00 00 ad de 06 00 00 00 > cat event.kernel_software_watchdog > /sys/firmware/gsmi/append_to_eventlog > mosys eventlog list | tail -1 14 | 2012-06-25 10:14:14 | Kernl Event | Software Watchdog Signed-off-by:
Duncan Laurie <dlaurie@chromium.org> Reviewed-by:
Vadim Bendebury <vbendeb@chromium.org> Reviewed-by:
Stefan Reinauer <reinauer@chromium.org> Signed-off-by:
Furquan Shaikh <furquan@google.com> Tested-by:
Furquan Shaikh <furquan@chromium.org> Reviewed-by:
Aaron Durbin <adurbin@chromium.org> Reviewed-by:
Justin TerAvest <teravest@chromium.org> [zwisler: updated changelog for 2nd bug fix and upstream] Signed-off-by:
Ross Zwisler <zwisler@google.com> Reviewed-by:
Guenter Roeck <groeck@chromium.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Nikolay Borisov authored
[ Upstream commit 315bed43 ] In btrfs_search_old_slot get_old_root is always used with the assumption it cannot fail. However, this is not true in rare circumstance it can fail and return null. This will lead to null point dereference when the header is read. Fix this by checking the return value and properly handling NULL by setting ret to -EIO and returning gracefully. Coverity-id: 1087503 Signed-off-by:
Nikolay Borisov <nborisov@suse.com> Reviewed-by:
Lu Fengqi <lufq.fnst@cn.fujitsu.com> Reviewed-by:
David Sterba <dsterba@suse.com> Signed-off-by:
-
Su Yue authored
[ Upstream commit 28c4a3e2 ] Since commit 8b62f87b ("Btrfs: rework outstanding_extents"), manual operations of outstanding_extent in btrfs_inode are replaced by btrfs_mod_outstanding_extents(). The one in cluster_pages_for_defrag seems to be lost, so replace it of btrfs_mod_outstanding_extents(). Fixes: 8b62f87b ("Btrfs: rework outstanding_extents") Signed-off-by:
Su Yue <suy.fnst@cn.fujitsu.com> Reviewed-by:
-
Honghui Zhang authored
[ Upstream commit a7f172ab ] commit 101c92dc ("PCI: mediatek: Set up vendor ID and class type for MT7622") erroneously set the class type for MT7622 to PCI_CLASS_BRIDGE_HOST. The PCIe controller of MT7622 integrates a Root Port that has type 1 configuration space header and related bridge windows. The HW default value of this bridge's class type is invalid. Fix its class type and set it to PCI_CLASS_BRIDGE_PCI to match the hardware implementation. Fixes: 101c92dc ("PCI: mediatek: Set up vendor ID and class type for MT7622") Signed-off-by:
Honghui Zhang <honghui.zhang@mediatek.com> [lorenzo.pieralisi@arm.com: reworked the commit log] Signed-off-by:
Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Acked-by:
Ryder Lee <ryder.lee@mediatek.com> Signed-off-by:
-
Chaotian Jing authored
[ Upstream commit f38a9774 ] when msdc_cmd_is_ready return fail, the req_timeout work has not been inited and cancel_delayed_work() will return false, then, the request return directly and never call mmc_request_done(). so need call mod_delayed_work() before msdc_cmd_is_ready() Signed-off-by:
Chaotian Jing <chaotian.jing@mediatek.com> Signed-off-by:
Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by:
-
Chaotian Jing authored
[ Upstream commit 56f6cbbe ] as the mmc core layer has the mmc->actual_clock, so fill it and drop msdc_host->sclk. Signed-off-by:
-
Sergei Shtylyov authored
[ Upstream commit f34c6e62 ] Since commit 9ec36caf ("of/irq: do irq resolution in platform_get_irq") platform_get_irq() can return -EPROBE_DEFER. However, the driver overrides an error returned by that function with -ENOENT which breaks the deferred probing. Propagate upstream an error code returned by platform_get_irq() and remove the bogus "platform" from the error message, while at it... Fixes: 9ec36caf ("of/irq: do irq resolution in platform_get_irq") Signed-off-by:
Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> Signed-off-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
-
Jens Axboe authored
[ Upstream commit 8f94004e ] We can't modify cdo->capability as it is defined as a const. Change the modification hack to just WARN_ON_ONCE() if we hit any of the invalid combinations. This fixes a regression for pcd, which doesn't work after the constify patch. Fixes: 853fe1bf ("cdrom: Make device operations read-only") Tested-by:
Ondrej Zary <linux@rainbow-software.org> Signed-off-by:
Jens Axboe <axboe@kernel.dk> Signed-off-by:
-
Jens Axboe authored
[ Upstream commit 6d1f9dfd ] We need to be using the mq variant of request requeue here. Fixes: ca33dd92 ("skd: Convert to blk-mq") Signed-off-by:
-
Carl Huang authored
[ Upstream commit 0738b499 ] ath10k_pci_diag_write_mem may allocate big size of the dma memory based on the parameter nbytes. Take firmware diag download as example, the biggest size is about 500K. In some systems, the allocation is likely to fail because it can't acquire such a large contiguous dma memory. The fix is to allocate a small size dma memory. In the loop, driver copies the data to the allocated dma memory and writes to the destination until all the data is written. Tested with QCA6174 PCI with firmware-6.bin_WLAN.RM.4.4.1-00119-QCARMSWP-1, this also affects QCA9377 PCI. Signed-off-by:
Carl Huang <cjhuang@codeaurora.org> Reviewed-by:
Brian Norris <briannorris@chomium.org> Signed-off-by:
Kalle Valo <kvalo@codeaurora.org> Signed-off-by:
-
Rakesh Pillai authored
[ Upstream commit f1157695 ] Currently the wmi command for setting probe request oui, needed for mac randomization, is sent during the mac register. At this time, during the driver init the wmi has already been detached. This can cause unexpected behavior since the firmware is already down and the wmi has been detached. Send the wmi command for setting probe request oui during the driver start. This will make sure that the firmware is started and wmi is initialized before we send this command. Tested HW: WCN3990 Tested FW: WLAN.HL.2.0-01188-QCAHLSWMTPLZ-1 Fixes: 60e1d0fbSigned-off-by:
Rakesh Pillai <pillair@codeaurora.org> Signed-off-by:
-
Ali MJ Al-Nasrawy authored
[ Upstream commit 2258ee58 ] Beacons are not updated to reflect TIM changes. This is not compliant with power-saving client stations as the beacons do not have valid TIM and can cause the network to stall at random occasions and to have highly variable latencies. Fix it by updating beacon templates on mac80211 set_tim callback. Addresses an issue described in: https://marc.info/?i=20180911163534.21312d08%20()%20manjaroSigned-off-by:
Ali MJ Al-Nasrawy <alimjalnasrawy@gmail.com> Signed-off-by:
-
Lorenzo Bianconi authored
[ Upstream commit 4df94273 ] Fix restore value configured in MT_BBP(IBI, 9) register in mt76x0_phy_recalibrate_after_assoc routine. Fixes: 10de7a8b ("mt76x0: phy files") Signed-off-by:
Lorenzo Bianconi <lorenzo.bianconi@redhat.com> Signed-off-by:
Felix Fietkau <nbd@nbd.name> Signed-off-by:
-
Felix Fietkau authored
[ Upstream commit 5155938d ] Fixes a rare corner case where a BlockAckReq might get the wrong sequence number. Signed-off-by:
-
Dan Carpenter authored
[ Upstream commit d8c27ba8 ] Fix memory leak in L2c threaded interrupt handler. [ bp: Rewrite commit message. ] Fixes: 41003396 ("EDAC, thunderx: Add Cavium ThunderX EDAC driver") Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
Borislav Petkov <bp@suse.de> CC: David Daney <david.daney@cavium.com> CC: Jan Glauber <jglauber@cavium.com> CC: Mauro Carvalho Chehab <mchehab@kernel.org> CC: Sergey Temerkhanov <s.temerkhanov@gmail.com> CC: linux-edac <linux-edac@vger.kernel.org> Link: http://lkml.kernel.org/r/20181013102843.GG16086@mwandaSigned-off-by:
-
Sam Bobroff authored
[ Upstream commit 473af09b ] eeh_add_to_parent_pe() sometimes removes the EEH_PE_KEEP flag, but it incorrectly removes it from pe->type, instead of pe->state. However, rather than clearing it from the correct field, remove it. Inspection of the code shows that it can't ever have had any effect (even if it had been cleared from the correct field), because the field is never tested after it is cleared by the statement in question. The clear statement was added by commit 807a827d ("powerpc/eeh: Keep PE during hotplug"), but it didn't explain why it was necessary. Signed-off-by:
Sam Bobroff <sbobroff@linux.ibm.com> Signed-off-by:
Michael Ellerman <mpe@ellerman.id.au> Signed-off-by:
-
Sam Bobroff authored
[ Upstream commit bcbe3730 ] If a device is removed during EEH processing (either by a driver's handler or as part of recovery), it can lead to a null dereference in eeh_pe_report_edev(). To handle this, skip devices that have been removed. Signed-off-by:
-
Joel Stanley authored
[ Upstream commit e8e132e6 ] This will avoid auto-vectorisation when building with higher optimisation levels. We don't know if the machine can support VSX and even if it's present it's probably not going to be enabled at this point in boot. These flag were both added prior to GCC 4.6 which is the minimum compiler version supported by upstream, thanks to Segher for the details. Signed-off-by:
Joel Stanley <joel@jms.id.au> Signed-off-by:
-
Joel Stanley authored
[ Upstream commit 1a855eac ] As of commit 10c77dba ("powerpc/boot: Fix build failure in 32-bit boot wrapper") the opal code is hidden behind CONFIG_PPC64_BOOT_WRAPPER, but the boot wrapper avoids include/linux, so it does not get the normal Kconfig flags. We can drop the guard entirely as in commit f8e8e69c ("powerpc/boot: Only build OPAL code when necessary") the makefile only includes opal.c in the build if CONFIG_PPC64_BOOT_WRAPPER is set. Fixes: 10c77dba ("powerpc/boot: Fix build failure in 32-bit boot wrapper") Signed-off-by:
-
Dan Carpenter authored
[ Upstream commit 014704e6 ] The "count < sizeof(struct os_area_db)" comparison is type promoted to size_t so negative values of "count" are treated as very high values and we accidentally return success instead of a negative error code. This doesn't really change runtime much but it fixes a static checker warning. Signed-off-by:
Geoff Levand <geoff@infradead.org> Signed-off-by:
-
Al Viro authored
[ Upstream commit 27230e51 ] compat_ptr() for pointer-taking ones... Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
-
Al Viro authored
[ Upstream commit 50f45326 ] pointer-taking ones need compat_ptr(); int-taking one doesn't. Signed-off-by:
-
Andreas Gruenbacher authored
[ Upstream commit ec23df2b ] Reservations in gfs can span multiple gfs2_bitmaps (but they won't span multiple resource groups). When removing a reservation, we want to clear the GBF_FULL flags of all involved gfs2_bitmaps, not just that of the first bitmap. Signed-off-by:
Andreas Gruenbacher <agruenba@redhat.com> Signed-off-by:
Bob Peterson <rpeterso@redhat.com> Reviewed-by:
Steven Whitehouse <swhiteho@redhat.com> Signed-off-by:
-
Alan Douglas authored
[ Upstream commit e81e36a9 ] According to the PCIe specification, although the MSI data is only 16bits, the upper 16bits should be written as 0. Use writel instead of writew when writing the MSI data to the host. Fixes: 37dddf14 ("PCI: cadence: Add EndPoint Controller driver for Cadence PCIe controller") Signed-off-by:
Alan Douglas <adouglas@cadence.com> Signed-off-by:
-
Gustavo A. R. Silva authored
[ Upstream commit 4fe81669 ] There is a potential execution path in which variable *ret* is checked in an IF statement, and then its value is used to report an error at line 659 without being properly initialized previously: 659 if (ret) 660 dev_err(priv->dev, "Failed to write to 0x%x (%d)\n", reg, ret); Fix this by initializing variable *ret* to 0 in order to avoid unpredictable or unintended results. Addresses-Coverity-ID: 1471969 ("Uninitialized scalar variable") Fixes: 218d72a7 ("pinctrl: madera: Add driver for Cirrus Logic Madera codecs") Signed-off-by:
Gustavo A. R. Silva <gustavo@embeddedor.com> Acked-by:
Charles Keepax <ckeepax@opensource.cirrus.com> Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
Sergey Senozhatsky authored
[ Upstream commit d2130e82 ] The way we calculate logbuf free space percentage overflows signed integer: int free; free = __LOG_BUF_LEN - log_next_idx; pr_info("early log buf free: %u(%u%%)\n", free, (free * 100) / __LOG_BUF_LEN); We support LOG_BUF_LEN of up to 1<<25 bytes. Since setup_log_buf() is called during early init, logbuf is mostly empty, so __LOG_BUF_LEN - log_next_idx is close to 1<<25. Thus when we multiply it by 100, we overflow signed integer value range: 100 is 2^6 + 2^5 + 2^2. Example, booting with LOG_BUF_LEN 1<<25 and log_buf_len=2G boot param: [ 0.075317] log_buf_len: -2147483648 bytes [ 0.075319] early log buf free: 33549896(-28%) Make "free" unsigned integer and use appropriate printk() specifier. Link: http://lkml.kernel.org/r/20181010113308.9337-1-sergey.senozhatsky@gmail.com To: Steven Rostedt <rostedt@goodmis.org> Cc: linux-kernel@vger.kernel.org Cc: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> Signed-off-by:
Sergey Senozhatsky <sergey.senozhatsky@gmail.com> Signed-off-by:
Petr Mladek <pmladek@suse.com> Signed-off-by:
-
Sergey Senozhatsky authored
[ Upstream commit 3ac37a93 ] Prior to commit 5c2992ee ("printk: remove console flushing special cases for partial buffered lines") we would do console_cont_flush() for each pr_cont() to print cont fragments, so console_unlock() would actually print data: pr_cont(); console_lock(); console_unlock() console_cont_flush(); // print cont fragment ... pr_cont(); console_lock(); console_unlock() console_cont_flush(); // print cont fragment We don't do console_cont_flush() anymore, so when we do pr_cont() console_unlock() does nothing (unless we flushed the cont buffer): pr_cont(); console_lock(); console_unlock(); // noop ... pr_cont(); console_lock(); console_unlock(); // noop ... pr_cont(); cont_flush(); console_lock(); console_unlock(); // print data We also wakeup klogd purposelessly for pr_cont() output - un-flushed cont buffer is not stored in log_buf; there is nothing to pull. Thus we can console_lock()/console_unlock()/wake_up_klogd() only when we know that we log_store()-ed a message and there is something to print to the consoles/syslog. Link: http://lkml.kernel.org/r/20181002023836.4487-3-sergey.senozhatsky@gmail.com To: Steven Rostedt <rostedt@goodmis.org> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Dmitriy Vyukov <dvyukov@google.com> Cc: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp> Cc: Tejun Heo <tj@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: LKML <linux-kernel@vger.kernel.org> Cc: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> Signed-off-by:
-
Michael Schupikov authored
[ Upstream commit 22a8118d ] After allocation, output and decomp_output both point to memory chunks of size COMP_BUF_SIZE. Then, only the first bytes are zeroed out using sizeof(COMP_BUF_SIZE) as parameter to memset(), because sizeof(COMP_BUF_SIZE) provides the size of the constant and not the size of allocated memory. Instead, the whole allocated memory is meant to be zeroed out. Use COMP_BUF_SIZE as parameter to memset() directly in order to accomplish this. Fixes: 33607384 ("crypto: testmgr - Allow different compression results") Signed-off-by:
Michael Schupikov <michael@schupikov.de> Reviewed-by:
Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
-
Takashi Sakamoto authored
[ Upstream commit 51e68fb0 ] In some error paths, reference count of firewire unit is not decreased. This commit fixes the bug. Fixes: 5b14ec25('ALSA: firewire: release reference count of firewire unit in .remove callback of bus driver') Signed-off-by:
Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Adrian Bunk authored
[ Upstream commit 65a576e2 ] NL80211_TX_POWER_LIMITED was treated as NL80211_TX_POWER_AUTOMATIC, which is the opposite of what should happen and can cause nasty regulatory problems. if/else converted to a switch without default to make gcc warn on unhandled enum values. Signed-off-by:
Adrian Bunk <bunk@kernel.org> Signed-off-by:
-
Chris Wilson authored
commit 2d691aec upstream. set_page_dirty says: For pages with a mapping this should be done under the page lock for the benefit of asynchronous memory errors who prefer a consistent dirty state. This rule can be broken in some special cases, but should be better not to. Under those rules, it is only safe for us to use the plain set_page_dirty calls for shmemfs/anonymous memory. Userptr may be used with real mappings and so needs to use the locked version (set_page_dirty_lock). However, following a try_to_unmap() we may want to remove the userptr and so call put_pages(). However, try_to_unmap() acquires the page lock and so we must avoid recursively locking the pages ourselves -- which means that we cannot safely acquire the lock around set_page_dirty(). Since we can't be sure of the lock, we have to risk skip dirtying the page, or else risk calling set_page_dirty() without a lock and so risk fs corruption. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=203317 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=112012 Fixes: 5cc9ed4b ("drm/i915: Introduce mapping of user pages into video memory (userptr) ioctl") References: cb6d7c7d ("drm/i915/userptr: Acquire the page lock around set_page_dirty()") References: 505a8ec7 ("Revert "drm/i915/userptr: Acquire the page lock around set_page_dirty()"") References: 6dcc693b ("ext4: warn when page is dirtied without buffers") Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: stable@vger.kernel.org Reviewed-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191111133205.11590-1-chris@chris-wilson.co.uk (cherry picked from commit 0d4bbe3d) Signed-off-by:
Joonas Lahtinen <joonas.lahtinen@linux.intel.com> (cherry picked from commit cee7fb43) Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
-
Chris Wilson authored
commit add3eeed upstream. We report "frequencies" (actual-frequency, requested-frequency) as the number of accumulated cycles so that the average frequency over that period may be determined by the user. This means the units we report to the user are Mcycles (or just M), not MHz. Signed-off-by:
-
Evan Quan authored
commit 355d991c upstream. Otherwise, the error message prompted will confuse user. Signed-off-by:
Evan Quan <evan.quan@amd.com> Acked-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
-
Andrey Ryabinin authored
commit 9a63236f upstream. It's possible to hit the WARN_ON_ONCE(page_mapped(page)) in remove_stable_node() when it races with __mmput() and squeezes in between ksm_exit() and exit_mmap(). WARNING: CPU: 0 PID: 3295 at mm/ksm.c:888 remove_stable_node+0x10c/0x150 Call Trace: remove_all_stable_nodes+0x12b/0x330 run_store+0x4ef/0x7b0 kernfs_fop_write+0x200/0x420 vfs_write+0x154/0x450 ksys_write+0xf9/0x1d0 do_syscall_64+0x99/0x510 entry_SYSCALL_64_after_hwframe+0x49/0xbe Remove the warning as there is nothing scary going on. Link: http://lkml.kernel.org/r/20191119131850.5675-1-aryabinin@virtuozzo.com Fixes: cbf86cfe ("ksm: remove old stable nodes more thoroughly") Signed-off-by:
Andrey Ryabinin <aryabinin@virtuozzo.com> Acked-by:
Hugh Dickins <hughd@google.com> Cc: Andrea Arcangeli <aarcange@redhat.com> Cc: <stable@vger.kernel.org> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Joseph Qi authored
commit 94b07b6f upstream. This reverts commit 56e94ea1. Commit 56e94ea1 ("fs: ocfs2: fix possible null-pointer dereferences in ocfs2_xa_prepare_entry()") introduces a regression that fail to create directory with mount option user_xattr and acl. Actually the reported NULL pointer dereference case can be correctly handled by loc->xl_ops->xlo_add_entry(), so revert it. Link: http://lkml.kernel.org/r/1573624916-83825-1-git-send-email-joseph.qi@linux.alibaba.com Fixes: 56e94ea1 ("fs: ocfs2: fix possible null-pointer dereferences in ocfs2_xa_prepare_entry()") Signed-off-by:
Joseph Qi <joseph.qi@linux.alibaba.com> Reported-by:
Thomas Voegtle <tv@lio96.de> Acked-by:
Changwei Ge <gechangwei@live.cn> Cc: Jia-Ju Bai <baijiaju1990@gmail.com> Cc: Mark Fasheh <mark@fasheh.com> Cc: Joel Becker <jlbec@evilplan.org> Cc: Junxiao Bi <junxiao.bi@oracle.com> Cc: Gang He <ghe@suse.com> Cc: Jun Piao <piaojun@huawei.com> Cc: <stable@vger.kernel.org> Signed-off-by:
-
Laurent Vivier authored
commit d791cfcb upstream. When we hot unplug a virtserialport and then try to hot plug again, it fails: (qemu) chardev-add socket,id=serial0,path=/tmp/serial0,server,nowait (qemu) device_add virtserialport,bus=virtio-serial0.0,nr=2,\ chardev=serial0,id=serial0,name=serial0 (qemu) device_del serial0 (qemu) device_add virtserialport,bus=virtio-serial0.0,nr=2,\ chardev=serial0,id=serial0,name=serial0 kernel error: virtio-ports vport2p2: Error allocating inbufs qemu error: virtio-serial-bus: Guest failure in adding port 2 for device \ virtio-serial0.0 This happens because buffers for the in_vq are allocated when the port is added but are not released when the port is unplugged. They are only released when virtconsole is removed (see a7a69ec0) To avoid the problem and to be symmetric, we could allocate all the buffers in init_vqs() as they are released in remove_vqs(), but it sounds like a waste of memory. Rather than that, this patch changes add_port() logic to ignore ENOSPC error in fill_queue(), which means queue has already been filled. Fixes: a7a69ec0 ("virtio_console: free buffers after reset") Cc: mst@redhat.com Cc: stable@vger.kernel.org Signed-off-by:
Laurent Vivier <lvivier@redhat.com> Signed-off-by:
Michael S. Tsirkin <mst@redhat.com> Signed-off-by:
-
Sun Ke authored
commit dff10bbe upstream. Before returning NULL, put the sock first. Cc: stable@vger.kernel.org Fixes: cf1b2326 ("nbd: verify socket is supported during setup") Reviewed-by:
Josef Bacik <josef@toxicpanda.com> Reviewed-by:
Mike Christie <mchristi@redhat.com> Signed-off-by:
Sun Ke <sunke32@huawei.com> Signed-off-by:
-
Laura Abbott authored
commit 0161a94e upstream. gpio tools fail to build correctly with make parallelization: $ make -s -j24 ld: gpio-utils.o: file not recognized: file truncated make[1]: *** [/home/labbott/linux_upstream/tools/build/Makefile.build:145: lsgpio-in.o] Error 1 make: *** [Makefile:43: lsgpio-in.o] Error 2 make: *** Waiting for unfinished jobs.... This is because gpio-utils.o is used across multiple targets. Fix this by making gpio-utios.o a proper dependency. Cc: <stable@vger.kernel.org> Signed-off-by:
Laura Abbott <labbott@redhat.com> Signed-off-by:
Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by:
-
Thierry Reding authored
commit b0391479 upstream. When converting milliseconds to microseconds in commit fffa6af9 ("gpio: max77620: Use correct unit for debounce times") some ~1 ms gaps were introduced between the various ranges supported by the controller. Fix this by changing the start of each range to the value immediately following the end of the previous range. This way a debounce time of, say 8250 us will translate into 16 ms instead of returning an -EINVAL error. Typically the debounce delay is only ever set through device tree and specified in milliseconds, so we can never really hit this issue because debounce times are always a multiple of 1000 us. The only notable exception for this is drivers/mmc/host/mmc-spi.c where the CD GPIO is requested, which passes a 1 us debounce time. According to a comment preceeding that code this should actually be 1 ms (i.e. 1000 us). Reported-by:
Pavel Machek <pavel@denx.de> Signed-off-by:
Thierry Reding <treding@nvidia.com> Acked-by:
-
Stefano Garzarella authored
commit 6dbd3e66 upstream. If the packets to sent to the guest are bigger than the buffer available, we can split them, using multiple buffers and fixing the length in the packet header. This is safe since virtio-vsock supports only stream sockets. Signed-off-by:
Stefano Garzarella <sgarzare@redhat.com> Reviewed-by:
Stefan Hajnoczi <stefanha@redhat.com> Acked-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
