- 09 Nov, 2015 24 commits
-
-
Jan Kara authored
commit 296291cd upstream. Currently a simple program below issues a sendfile(2) system call which takes about 62 days to complete in my test KVM instance. int fd; off_t off = 0; fd = open("file", O_RDWR | O_TRUNC | O_SYNC | O_CREAT, 0644); ftruncate(fd, 2); lseek(fd, 0, SEEK_END); sendfile(fd, fd, &off, 0xfffffff); Now you should not ask kernel to do a stupid stuff like copying 256MB in 2-byte chunks and call fsync(2) after each chunk but if you do, sysadmin should have a way to stop you. We actually do have a check for fatal_signal_pending() in generic_perform_write() which triggers in this path however because we always succeed in writing something before the check is done, we return value > 0 from generic_perform_write() and thus the information about signal gets lost. Fix the problem by doing the signal check before writing anything. That way generic_perform_write() returns -EINTR, the error gets propagated up and the sendfile loop terminates early. Signed-off-by:
Jan Kara <jack@suse.com> Reported-by:
Dmitry Vyukov <dvyukov@google.com> Cc: Al Viro <viro@ZenIV.linux.org.uk> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Kővágó, Zoltán authored
commit 8a53554e upstream. When multiple GOP devices exists, but none of them implements ConOut, the code should just choose the first GOP (according to the comments). But currently 'fb_base' will refer to the last GOP, while other parameters to the first GOP, which will likely result in a garbled display. I can reliably reproduce this bug using my ASRock Z87M Extreme4 motherboard with CSM and integrated GPU disabled, and two PCIe video cards (NVidia GT640 and GTX980), booting from efi-stub (booting from grub works fine). On the primary display the ASRock logo remains and on the secondary screen it is garbled up completely. Signed-off-by:
Kővágó, Zoltán <DirtY.iCE.hu@gmail.com> Signed-off-by:
Matt Fleming <matt.fleming@intel.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Matthew Garrett <mjg59@srcf.ucam.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/1444659236-24837-2-git-send-email-matt@codeblueprint.co.ukSigned-off-by:
Ingo Molnar <mingo@kernel.org> Signed-off-by:
-
Charles Keepax authored
commit 97aff2c0 upstream. There are 24 EQ registers not 25, I suspect this bug came about because the registers start at EQ1 not zero. The bug is relatively harmless as the extra register written is an unused one. Signed-off-by:
Charles Keepax <ckeepax@opensource.wolfsonmicro.com> Signed-off-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
-
Charles Keepax authored
commit 34198710 upstream. SX_TLV controls are intended for situations where the register behind the control has some non-zero value indicating the minimum gain and then gains increasing from there and eventually overflowing through zero. Currently every CODEC implementing these controls specifies the minimum as the non-zero value for the minimum and the maximum as the number of gain settings available. This means when the info callback subtracts the minimum value from the maximum value to calculate the number of gain levels available it is actually under reporting the available levels. This patch fixes this issue by adding a new snd_soc_info_volsw_sx callback that does not subtract the minimum value. Fixes: 1d99f243 ("ASoC: core: Rework SOC_DOUBLE_R_SX_TLV add SOC_SINGLE_SX_TLV") Signed-off-by:
Brian Austin <brian.austin@cirrus.com> Tested-by:
-
Takashi Iwai authored
commit d289619a upstream. The HDA codec driver issues snd_hda_codec_reset() at the error path of PCM build. This was needed in the earlier code base, but the recent rewrite to use the standard bus binding made this a deadlock: modprobe D 0000000000000005 0 720 716 0x00000080 Call Trace: [<ffffffff816a5dbe>] schedule+0x3e/0x90 [<ffffffff816a61a5>] schedule_preempt_disabled+0x15/0x20 [<ffffffff816a7ae5>] __mutex_lock_slowpath+0xb5/0x120 [<ffffffff816a7b6b>] mutex_lock+0x1b/0x30 [<ffffffff8148656b>] device_release_driver+0x1b/0x30 [<ffffffff81485c15>] bus_remove_device+0x105/0x180 [<ffffffff814822b9>] device_del+0x139/0x260 [<ffffffffa05e0ec5>] snd_hdac_device_unregister+0x25/0x30 [snd_hda_core] [<ffffffffa074fa6a>] snd_hda_codec_reset+0x2a/0x70 [snd_hda_codec] [<ffffffffa075007b>] snd_hda_codec_build_pcms+0x18b/0x1b0 [snd_hda_codec] [<ffffffffa074a44e>] hda_codec_driver_probe+0xbe/0x140 [snd_hda_codec] [<ffffffff81486ac4>] driver_probe_device+0x1f4/0x460 [<ffffffff81486dc0>] __driver_attach+0x90/0xa0 [<ffffffff81484844>] bus_for_each_dev+0x64/0xa0 [<ffffffff814862de>] driver_attach+0x1e/0x20 [<ffffffff81485e7b>] bus_add_driver+0x1eb/0x280 [<ffffffff81487680>] driver_register+0x60/0xe0 [<ffffffffa074a0da>] __hda_codec_driver_register+0x5a/0x60 [snd_hda_codec] [<ffffffffa070a01e>] realtek_driver_init+0x1e/0x1000 [snd_hda_codec_realtek] [<ffffffff810002f3>] do_one_initcall+0xb3/0x200 [<ffffffff816a1fc5>] do_init_module+0x60/0x1f8 [<ffffffff810ee5c3>] load_module+0x1653/0x1bd0 [<ffffffff810eed48>] SYSC_finit_module+0x98/0xc0 [<ffffffff810eed8e>] SyS_finit_module+0xe/0x10 [<ffffffff816aa032>] entry_SYSCALL_64_fastpath+0x16/0x75 The simple fix is just to remove this call, since we don't need to think about unbinding at there any longer. Bugzilla: https://bugzilla.suse.com/show_bug.cgi?id=948758Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
David Henningsson authored
commit e8d65a8d upstream. Add the appropriate quirk to indicate the Lenovo G50-80 has a stereo mic input where one channel has reverse polarity. Alsa-info available at: https://launchpadlibrarian.net/220846272/AlsaInfo.txt BugLink: https://bugs.launchpad.net/bugs/1504778Signed-off-by:
David Henningsson <david.henningsson@canonical.com> Signed-off-by:
-
Arnd Bergmann authored
commit 4a5d69b7 upstream. The vgic code on ARM is built for all configurations that enable KVM, but the parent_data field that it references is only present when CONFIG_IRQ_DOMAIN_HIERARCHY is set: virt/kvm/arm/vgic.c: In function 'kvm_vgic_map_phys_irq': virt/kvm/arm/vgic.c:1781:13: error: 'struct irq_data' has no member named 'parent_data' This flag is implied by the GIC driver, and indeed the VGIC code only makes sense if a GIC is present. This changes the CONFIG_KVM symbol to always select GIC, which avoids the issue. Fixes: 662d9715 ("arm/arm64: KVM: Kill CONFIG_KVM_ARM_{VGIC,TIMER}") Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Acked-by:
Marc Zyngier <marc.zyngier@arm.com> Signed-off-by:
Christoffer Dall <christoffer.dall@linaro.org> Signed-off-by:
-
Antti Palosaari authored
commit d18ca5b7 upstream. Add lock to prevent concurrent access for control message as control message function uses shared buffer. Without the lock there may be remote control polling which messes the buffer causing IO errors. Increase buffer size and add check for maximum supported message length. Link: https://bugzilla.kernel.org/show_bug.cgi?id=103391 Fixes: c56222a6 ("[media] rtl28xxu: move usb buffers to state") Signed-off-by:
Antti Palosaari <crope@iki.fi> Signed-off-by:
-
Laura Abbott authored
commit 47810b43 upstream. When reading the firmware and sending commands, the length must be bounds checked to avoid overrunning the size of the command buffer and smashing the stack if the firmware is not in the expected format: si2168 11-0064: found a 'Silicon Labs Si2168-B40' si2168 11-0064: downloading firmware from file 'dvb-demod-si2168-b40-01.fw' si2168 11-0064: firmware download failed -95 Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: ffffffffa085708f Add the proper check. Reported-by:
Stuart Auchterlonie <sauchter@redhat.com> Reviewed-by:
Laura Abbott <labbott@fedoraproject.org> Signed-off-by:
Mauro Carvalho Chehab <mchehab@osg.samsung.com> Signed-off-by:
-
Laura Abbott authored
commit a828d72d upstream. When reading the firmware and sending commands, the length must be bounds checked to avoid overrunning the size of the command buffer and smashing the stack if the firmware is not in the expected format. Add the proper check. Signed-off-by:
-
Adam Richter authored
commit 30730c7f upstream. In Linux 4.3-rc5, there is an error case in drm_dp_get_branch_device that returns without releasing mgr->lock, resulting a spew of kernel messages about a kernel work function possibly having leaked a mutex and presumably more serious adverse consequences later. This patch changes the error to "goto out" to unlock the mutex before returning. [airlied: grabbed from drm-next as it fixes something we've seen] Signed-off-by:
Adam J. Richter <adam_richter2004@yahoo.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
Dave Airlie <airlied@redhat.com> Signed-off-by:
-
Vasant Hegde authored
commit 8832317f upstream. Currently we do not validate rtas.entry before calling enter_rtas(). This leads to a kernel oops when user space calls rtas system call on a powernv platform (see below). This patch adds code to validate rtas.entry before making enter_rtas() call. Oops: Exception in kernel mode, sig: 4 [#1] SMP NR_CPUS=1024 NUMA PowerNV task: c000000004294b80 ti: c0000007e1a78000 task.ti: c0000007e1a78000 NIP: 0000000000000000 LR: 0000000000009c14 CTR: c000000000423140 REGS: c0000007e1a7b920 TRAP: 0e40 Not tainted (3.18.17-340.el7_1.pkvm3_1_0.2400.1.ppc64le) MSR: 1000000000081000 <HV,ME> CR: 00000000 XER: 00000000 CFAR: c000000000009c0c SOFTE: 0 NIP [0000000000000000] (null) LR [0000000000009c14] 0x9c14 Call Trace: [c0000007e1a7bba0] [c00000000041a7f4] avc_has_perm_noaudit+0x54/0x110 (unreliable) [c0000007e1a7bd80] [c00000000002ddc0] ppc_rtas+0x150/0x2d0 [c0000007e1a7be30] [c000000000009358] syscall_exit+0x0/0x98 Fixes: 55190f88 ("powerpc: Add skeleton PowerNV platform") Reported-by:
NAGESWARA R. SASTRY <nasastry@in.ibm.com> Signed-off-by:
Vasant Hegde <hegdevasant@linux.vnet.ibm.com> [mpe: Reword change log, trim oops, and add stable + fixes] Signed-off-by:
Michael Ellerman <mpe@ellerman.id.au> Signed-off-by:
-
Joerg Roedel authored
commit cbf3ccd0 upstream. During device assignment/deassignment the flags in the DTE get lost, which might cause spurious faults, for example when the device tries to access the system management range. Fix this by not clearing the flags with the rest of the DTE. Reported-by:
G. Richard Bellamy <rbellamy@pteradigm.com> Tested-by:
Joerg Roedel <jroedel@suse.de> Signed-off-by:
-
Jay Cornwall authored
commit d14f6fce upstream. handle_mm_fault indirectly triggers a BUG in do_numa_page when given a VMA without read/write/execute access. Check this condition in do_fault. do_fault -> handle_mm_fault -> handle_pte_fault -> do_numa_page mm/memory.c 3147 static int do_numa_page(struct mm_struct *mm, struct vm_area_struct *vma, .... 3159 /* A PROT_NONE fault should not end up here */ 3160 BUG_ON(!(vma->vm_flags & (VM_READ | VM_EXEC | VM_WRITE))); Signed-off-by:
Jay Cornwall <jay@jcornwall.me> Signed-off-by:
-
Christian Zander authored
commit ba2374fd upstream. In preparation for the installation of a large page, any small page tables that may still exist in the target IOV address range are removed. However, if a scatter/gather list entry is large enough to fit more than one large page, the address space for any subsequent large pages is not cleared of conflicting small page tables. This can cause legitimate mapping requests to fail with errors of the form below, potentially followed by a series of IOMMU faults: ERROR: DMA PTE for vPFN 0xfde00 already set (to 7f83a4003 not 7e9e00083) In this example, a 4MiB scatter/gather list entry resulted in the successful installation of a large page @ vPFN 0xfdc00, followed by a failed attempt to install another large page @ vPFN 0xfde00, due to the presence of a pointer to a small page table @ 0x7f83a4000. To address this problem, compute the number of large pages that fit into a given scatter/gather list entry, and use it to derive the last vPFN covered by the large page(s). Signed-off-by:
Christian Zander <christian@nervanasys.com> Signed-off-by:
David Woodhouse <David.Woodhouse@intel.com> Signed-off-by:
-
Luca Coelho authored
commit f08f6258 upstream. Add 3 new subdevice IDs for the 0x095A device ID and 2 for the 0x095B device ID. Reported-by:
Jeremy <jeremy.bomkamp@gmail.com> Signed-off-by:
Luca Coelho <luciano.coelho@intel.com> Signed-off-by:
-
Andrei Otcheretianski authored
commit dbf73d4a upstream. FW dump may be triggered when running init ucode, for example due to a sysassert. In this case fw_dump_wk may run after mvm is freed, resulting in a kernel panic. Fix it by flushing the work. Fixes: 01b988a708af ("iwlwifi: mvm: allow to collect debug data when restart is disabled") Signed-off-by:
Andrei Otcheretianski <andrei.otcheretianski@intel.com> Signed-off-by:
-
Arik Nemtsov authored
commit 1a3fe0b2 upstream. During the CT-kill exit flow, the card is powered up and partially initialized to check if the temperature is already low enough. Unfortunately the init bails early because the CT-kill flag is set. Make the code bail early only for HW RF-kill, as was intended by the author. CT-kill is self-imposed and is not really RF-kill. Fixes: 31b8b343 ("iwlwifi: fix RFkill while calibrating") Signed-off-by:
Arik Nemtsov <arikx.nemtsov@intel.com> Signed-off-by:
-
Johannes Berg authored
commit 2cf5eb3a upstream. The code to send the RX PN data (for each TID) to the firmware has a devastating bug: it overwrites the data for TID 0 with all the TID data, leaving the remaining TIDs zeroed. This will allow replays to actually be accepted by the firmware, which could allow waking up the system. Signed-off-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
-
Avraham Stern authored
commit e9cb0327 upstream. The csa_countdown flag was not cleared when the AP is stopped. As a result, if the AP was stopped after csa_countdown had started, all the folowing channel switch commands would fail. Fix that by clearing the csa_countdown flag when the AP is stopped. Signed-off-by:
Avraham Stern <avraham.stern@intel.com> Signed-off-by:
-
Larry Finger authored
commit 54328e64 upstream. In commit 1277fa2a ("rtlwifi: Remove the clear interrupt routine from all drivers"), the code that cleared all interrupt enable bits before setting them was removed for all PCI drivers. This fixed an issue that caused TX to be blocked for 3-5 seconds. On some RTL8821AE units, this change causes soft lockups to occur on boot. For that reason, the portion of the earlier commit that applied to rtl8821ae is reverted. Kernels 4.1 and newer are affected. See http://marc.info/?l=linux-wireless&m=144373370103285&w=2 and https://bugzilla.opensuse.org/show_bug.cgi?id=944978 for two cases where this regression affected user systems. Note that this bug does not appear on any of the developer's setups. For those users whose systems are affected by the TX blockage, but do not lock up on boot, a module parameter is added to disable the interrupt clear Fixes: 1277fa2a ("rtlwifi: Remove the clear interrupt routine from all drivers") Signed-off-by:
Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by:
Kalle Valo <kvalo@codeaurora.org> Signed-off-by:
-
Johannes Berg authored
commit b5a48134 upstream. The MODULE_FIRMWARE() for 3160 should be using the 7260 version as it's done in the device configuration struct instead of referencing IWL3160_UCODE_API_OK which doesn't even exist. Reported-by:
Hauke Mehrtens <hauke@hauke-m.de> Signed-off-by:
-
Johannes Berg authored
commit 5bd16687 upstream. The code to send the RX PN data (for each TID) to the firmware has a devastating bug: it overwrites the data for TID 0 with all the TID data, leaving the remaining TIDs zeroed. This will allow replays to actually be accepted by the firmware, which could allow waking up the system. Signed-off-by:
-
Felix Fietkau authored
commit 029cd037 upstream. ath9k inserts padding between the 802.11 header and the data area (to align it). Since it didn't declare this extra required headroom, this led to some nasty issues like randomly dropped packets in some setups. Signed-off-by:
Felix Fietkau <nbd@openwrt.org> Signed-off-by:
-
- 27 Oct, 2015 16 commits
-
-
Greg Kroah-Hartman authored
-
Konstantin Khlebnikov authored
commit c56dadf3 upstream. Function should_resched() is equal to (!preempt_count() && need_resched()). In preemptive kernel preempt_count here is non-zero because of vc->lock. Signed-off-by:
Konstantin Khlebnikov <khlebnikov@yandex-team.ru> Signed-off-by:
Peter Zijlstra (Intel) <peterz@infradead.org> Cc: Alexander Graf <agraf@suse.de> Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com> Cc: David Vrabel <david.vrabel@citrix.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Mike Galbraith <efault@gmx.de> Cc: Paul Mackerras <paulus@samba.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/20150715095203.12246.72922.stgit@buzzSigned-off-by:
-
Konstantin Khlebnikov authored
commit 0fa2f5cb upstream. This code is used only when CONFIG_PREEMPT=n and only in non-atomic context: xen_in_preemptible_hcall is set only in privcmd_ioctl_hypercall(). Thus preempt_count is zero and should_resched() is equal to need_resched(). Signed-off-by:
-
Jeff Layton authored
commit 83bfff23 upstream. Now that we have file locking helpers that can deal with an inode instead of a filp, we can change the NFSv4 locking code to use that instead. This should fix the case where we have a filp that is closed while flock or OFD locks are set on it, and the task is signaled so that it doesn't wait for the LOCKU reply to come in before the filp is freed. At that point we can end up with a use-after-free with the current code, which relies on dereferencing the fl_file in the lock request. Signed-off-by:
Jeff Layton <jeff.layton@primarydata.com> Reviewed-by:
"J. Bruce Fields" <bfields@fieldses.org> Tested-by:
-
Jeff Layton authored
commit ee296d7c upstream. They just call file_inode and then the corresponding *_inode_file_wait function. Just make them static inlines instead. Signed-off-by:
-
Jeff Layton authored
commit 29d01b22 upstream. Allow callers to pass in an inode instead of a filp. Signed-off-by:
-
Jeff Layton authored
commit bcd7f78d upstream. ...and rename it to better describe how it works. In order to fix a use-after-free in NFS, we need to be able to remove locks from an inode after the filp associated with them may have already been freed. flock_lock_file already only dereferences the filp to get to the inode, so just change it so the callers do that. All of the callers already pass in a lock request that has the fl_file set properly, so we don't need to pass it in individually. With that change it now only dereferences the filp to get to the inode, so just push that out to the callers. Signed-off-by:
-
Steve Wise authored
commit c91aed98 upstream. The server rdma_read_chunk_lcl() and rdma_read_chunk_frmr() functions were not taking into account the initial page_offset when determining the rdma read length. This resulted in a read who's starting address and length exceeded the base/bounds of the frmr. The server gets an async error from the rdma device and kills the connection, and the client then reconnects and resends. This repeats indefinitely, and the application hangs. Most work loads don't tickle this bug apparently, but one test hit it every time: building the linux kernel on a 16 core node with 'make -j 16 O=/mnt/0' where /mnt/0 is a ramdisk mounted via NFSRDMA. This bug seems to only be tripped with devices having small fastreg page list depths. I didn't see it with mlx4, for instance. Fixes: 0bf48289 ('svcrdma: refactor marshalling logic') Signed-off-by:
Steve Wise <swise@opengridcomputing.com> Tested-by:
Chuck Lever <chuck.lever@oracle.com> Signed-off-by:
J. Bruce Fields <bfields@redhat.com> Signed-off-by:
-
Steve Capper authored
commit 1a541b4e upstream. 6910fa16 ("arm64: enable PTE type bit in the mask for pte_modify") fixes a problem whereby a large block of PROT_NONE mapped memory is incorrectly mapped as block descriptors when mprotect is called. Unfortunately, a subtle bug was introduced by this fix to the THP logic. If one mmaps a large block of memory, then faults it such that it is collapsed into THPs; resulting calls to mprotect on this area of memory will lead to incorrect table descriptors being written instead of block descriptors. This is because pmd_modify calls pte_modify which is now allowed to modify the type of the page table entry. This patch reverts commit 6910fa16, and fixes the problem it was trying to address by adjusting PAGE_NONE to represent a table entry. Thus no change in pte type is required when moving from PROT_NONE to a different protection. Fixes: 6910fa16 ("arm64: enable PTE type bit in the mask for pte_modify") Cc: <stable@vger.kernel.org> # 4.0+ Cc: Feng Kan <fkan@apm.com> Reported-by:
Ganapatrao Kulkarni <Ganapatrao.Kulkarni@caviumnetworks.com> Tested-by:
Ganapatrao Kulkarni <gkulkarni@caviumnetworks.com> Reviewed-by:
Catalin Marinas <catalin.marinas@arm.com> [SteveC: backported 1a541b4e to 4.1 and 4.2 stable. Just one minor fix to second part to allow patch to apply cleanly, no logic changed.] Signed-off-by:
Steve Capper <steve.capper@linaro.org> Signed-off-by:
-
Uwe Kleine-König authored
commit 9911a2d5 upstream. The code in pinctrl-imx.c only works correctly if in the imx_pinctrl_soc_info passed to imx_pinctrl_probe we have: info->pins[i].number = i conf_reg(info->pins[i]) = 4 * i (which conf_reg(pin) being the offset of the pin's configuration register). When the imx25 specific part was introduced in b4a87c9b ("pinctrl: pinctrl-imx: add imx25 pinctrl driver") we had: info->pins[i].number = i + 1 conf_reg(info->pins[i]) = 4 * i . Commit 34027ca2 ("pinctrl: imx25: fix numbering for pins") tried to fix that but made the situation: info->pins[i-1].number = i conf_reg(info->pins[i-1]) = 4 * i which is hardly better but fixed the error seen back then. So insert another reserved entry in the array to finally yield: info->pins[i].number = i conf_reg(info->pins[i]) = 4 * i Fixes: 34027ca2 ("pinctrl: imx25: fix numbering for pins") Signed-off-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
Konstantin Khlebnikov authored
commit fe32d3cd upstream. These functions check should_resched() before unlocking spinlock/bh-enable: preempt_count always non-zero => should_resched() always returns false. cond_resched_lock() worked iff spin_needbreak is set. This patch adds argument "preempt_offset" to should_resched(). preempt_count offset constants for that: PREEMPT_DISABLE_OFFSET - offset after preempt_disable() PREEMPT_LOCK_OFFSET - offset after spin_lock() SOFTIRQ_DISABLE_OFFSET - offset after local_bh_distable() SOFTIRQ_LOCK_OFFSET - offset after spin_lock_bh() Signed-off-by:
Mike Galbraith <efault@gmx.de> Signed-off-by:
-
Frederic Weisbecker authored
commit 90b62b51 upstream. "CHECK" suggests it's only used as a comparison mask. But now it's used further as a config-conditional preempt disabler offset. Lets disambiguate this name. Signed-off-by:
Frederic Weisbecker <fweisbec@gmail.com> Signed-off-by:
-
Ilya Dryomov authored
commit 3ebe138a upstream. If rbd_dev_image_probe() in rbd_dev_probe_parent() fails, header_name is freed twice: once in rbd_dev_probe_parent() and then in its caller rbd_dev_image_probe() (rbd_dev_image_probe() is called recursively to handle parent images). rbd_dev_probe_parent() is responsible for probing the parent, so it shouldn't muck with clone's fields. Signed-off-by:
Ilya Dryomov <idryomov@gmail.com> Reviewed-by:
Alex Elder <elder@linaro.org> Signed-off-by:
-
Mike Snitzer authored
commit ba30670f upstream. Fixes: ac8c3f3d ("dm thin: generate event when metadata threshold passed") Signed-off-by:
Mike Snitzer <snitzer@redhat.com> Signed-off-by:
-
Alex Deucher authored
commit 51a4726b upstream. They were added relatively early in the driver init process which meant that in some cases the driver was not finished initializing before external tools tried to use them which could result in a crash depending on the timing. Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
-
Dave Airlie authored
commit bc8c131c upstream. This allows tiled monitors to work with radeon once mst is enabled. Signed-off-by:
-
