- 08 Nov, 2016 40 commits
-
-
Tony Luck authored
BugLink: http://bugs.launchpad.net/bugs/1638267 commit 548acf19 upstream. Huge amounts of help from Andy Lutomirski and Borislav Petkov to produce this. Andy provided the inspiration to add classes to the exception table with a clever bit-squeezing trick, Boris pointed out how much cleaner it would all be if we just had a new field. Linus Torvalds blessed the expansion with: ' I'd rather not be clever in order to save just a tiny amount of space in the exception table, which isn't really criticial for anybody. ' The third field is another relative function pointer, this one to a handler that executes the actions. We start out with three handlers: 1: Legacy - just jumps the to fixup IP 2: Fault - provide the trap number in %ax to the fixup code 3: Cleaned up legacy for the uaccess error hack Signed-off-by:
Tony Luck <tony.luck@intel.com> Reviewed-by:
Borislav Petkov <bp@suse.de> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/f6af78fcbd348cf4939875cfda9c19689b5e50b8.1455732970.git.tony.luck@intel.comSigned-off-by:
Ingo Molnar <mingo@kernel.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
Tim Gardner <tim.gardner@canonical.com>
-
Arnd Bergmann authored
BugLink: http://bugs.launchpad.net/bugs/1638267 commit 86c7e683 upstream. A workaround for a warning introduced a use of the NO_IRQ macro that should have been gone for a long time. It is clear from the code that the value cannot actually be used, but apparently there was a configuration at some point that caused a warning, so instead of just reverting that patch, this rearranges the code in a way that the warning cannot reappear. Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Fixes: 6ef41cf6 ("dmaengine :ipu: change ipu_irq_handler() to remove compile warning") Signed-off-by:
Vinod Koul <vinod.koul@intel.com> Signed-off-by:
-
Georges Savoundararadj authored
BugLink: http://bugs.launchpad.net/bugs/1638267 commit 06107359 upstream. bq->charger is initialized in bq24257_power_supply_init. Therefore, bq24257_power_supply_init should be called before the registration of the IRQ handler bq24257_irq_handler_thread that calls power_supply_changed(bq->charger). Signed-off-by:
Georges Savoundararadj <savoundg@gmail.com> Cc: Aurelien Chanot <chanot.a@gmail.com> Cc: Andreas Dannenberg <dannenberg@ti.com> Cc: Sebastian Reichel <sre@kernel.org> Cc: David Woodhouse <dwmw2@infradead.org> Fixes: 2219a935 ("power_supply: Add TI BQ24257 charger driver") Signed-off-by:
Sebastian Reichel <sre@kernel.org> Signed-off-by:
-
Larry Finger authored
BugLink: http://bugs.launchpad.net/bugs/1638267 commit 1335a951 upstream. Commit fadbe0cd ("staging: rtl8188eu: Remove rtw_zmalloc(), wrapper for kzalloc()") changed all allocation calls to be GFP_KERNEL even though the original wrapper was testing to determine if the caller was in atomic mode. Most of the mistakes were corrected with commit 33dc85c3 ("staging: r8188eu: Fix scheduling while atomic error introduced in commit fadbe0cd"); however, two kzalloc calls were missed as the call only happens when the driver is shutting down. Fixes: fadbe0cd ("staging: rtl8188eu: Remove rtw_zmalloc(), wrapper for kzalloc()") Signed-off-by:
Larry Finger <Larry.Finger@lwfinger.net> Cc: navin patidar <navin.patidar@gmail.com> Signed-off-by:
-
Chen-Yu Tsai authored
BugLink: http://bugs.launchpad.net/bugs/1638267 commit a3930ed0 upstream. Commit d88429a6 ("ASoC: dapm: Add output driver widget") added the snd_soc_dapm_out_drv ID for the output driver widget, which is the same as the PGA widget, with a later power sequence number. Commit 19a2557b ("ASoC: dapm: Add kcontrol support for PGAs") then added kcontrol support for PGA widgets, but failed to account for output driver widgets. Attempts to use kcontrols with output driver widgets result in silent failures, with the developer having little idea about what went on. Add snd_soc_dapm_out_drv to the switch/case block under snd_soc_dapm_pga in dapm_create_or_share_kcontrol, since they are essentially the same. Fixes: 19a2557b (ASoC: dapm: Add kcontrol support for PGAs) Signed-off-by:
Chen-Yu Tsai <wens@csie.org> Signed-off-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
-
Chen-Yu Tsai authored
BugLink: http://bugs.launchpad.net/bugs/1638267 commit 071133a2 upstream. The value for the second channel in _ENUM_DOUBLE (double channel) MUXs is not correctly updated, due to using the wrong bit shift. Use the correct bit shift, so both channels toggle together. Fixes: 3727b496 (ASoC: dapm: Consolidate MUXs and value MUXs) Signed-off-by:
Charles Keepax <ckeepax@opensource.wolfsonmicro.com> Signed-off-by:
-
Chen-Yu Tsai authored
BugLink: http://bugs.launchpad.net/bugs/1638267 commit 01ad5e7d upstream. If soc_dapm_read() fails, val will be uninitialized, and bogus values will be written later: ret = soc_dapm_read(dapm, reg, &val); val = (val >> shift) & mask; However, the compiler does not give a warning. Return on error before val is really used to avoid this. This is similar to the commit 69128316 ("ASoC: dapm: Fix uninitialized variable in snd_soc_dapm_get_enum_double()") Fixes: ce0fc93a (ASoC: Add DAPM support at the component level) Signed-off-by:
-
Wei Yongjun authored
BugLink: http://bugs.launchpad.net/bugs/1638267 commit 8ae3ea48 upstream. Fix to return error code -ENOMEM instead of 0 when failed to create widget, as done elsewhere in this function. Fixes: 8a978234 ("ASoC: topology: Add topology core") Signed-off-by:
Wei Yongjun <weiyj.lk@gmail.com> Signed-off-by:
-
Dave Gerlach authored
BugLink: http://bugs.launchpad.net/bugs/1638267 commit ad8529fd upstream. Currently omap-rng checks the return value of pm_runtime_get_sync and reports failure if anything is returned, however it should be checking if ret < 0 as pm_runtime_get_sync return 0 on success but also can return 1 if the device was already active which is not a failure case. Only values < 0 are actual failures. Fixes: 61dc0a44 ("hwrng: omap - Fix assumption that runtime_get_sync will always succeed") Signed-off-by:
Dave Gerlach <d-gerlach@ti.com> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
-
Ard Biesheuvel authored
BugLink: http://bugs.launchpad.net/bugs/1638267 commit ed4767d6 upstream. Since commit 8996eafd ("crypto: ahash - ensure statesize is non-zero"), all ahash drivers are required to implement import()/export(), and must have a non-zero statesize. Fix this for the ARM Crypto Extensions GHASH implementation. Fixes: 8996eafd ("crypto: ahash - ensure statesize is non-zero") Signed-off-by:
Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by:
-
Ondrej Mosnáček authored
BugLink: http://bugs.launchpad.net/bugs/1638267 commit 50d2e6dc upstream. The cipher block size for GCM is 16 bytes, and thus the CTR transform used in crypto_gcm_setkey() will also expect a 16-byte IV. However, the code currently reserves only 8 bytes for the IV, causing an out-of-bounds access in the CTR transform. This patch fixes the issue by setting the size of the IV buffer to 16 bytes. Fixes: 84c91152 ("[CRYPTO] gcm: Add support for async ciphers") Signed-off-by:
Ondrej Mosnacek <omosnacek@gmail.com> Signed-off-by:
-
Xinming Hu authored
BugLink: http://bugs.launchpad.net/bugs/1638267 commit b64db1b2 upstream. AID gets updated during TDLS setup, but modified value isn't reflected in "priv->assoc_rsp_buf". This causes TDLS setup failure. The problem is fixed here. Fixes: 4aff53ef ("mwifiex: parsing aid while receiving..") Signed-off-by:
Xinming Hu <huxm@marvell.com> Signed-off-by:
Amitkumar Karwar <akarwar@marvell.com> Signed-off-by:
Kalle Valo <kvalo@codeaurora.org> Signed-off-by:
-
Wei Yongjun authored
BugLink: http://bugs.launchpad.net/bugs/1638267 commit 6999aeab upstream. The call sequence spi_alloc_master/spi_register_master/spi_unregister_master is complete; it reduces the device reference count to zero, which and results in device memory being freed. The subsequent call to spi_master_put is unnecessary and results in an access to free memory. Drop it. Fixes: 9298bc72 ("spi: spi-fsl-dspi: Remove spi-bitbang") Signed-off-by:
-
Uwe Kleine-König authored
BugLink: http://bugs.launchpad.net/bugs/1638267 commit fcff0381 upstream. This fixes [ 0.000000] i.MX clk 82: register failed with -17 because the name is duplicated. Signed-off-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Fixes: 3713e3f5 ("clk: imx35: define two clocks for rtc") Acked-by:
Shawn Guo <shawnguo@kernel.org> Signed-off-by:
Stephen Boyd <sboyd@codeaurora.org> Signed-off-by:
-
Jan Viktorin authored
BugLink: http://bugs.launchpad.net/bugs/1638267 commit 4d31a258 upstream. The variable i contains a total number of resources (including IORESOURCE_IRQ). However, we want the dmem_region_start to point after the last resource of type IORESOURCE_MEM. The original behaviour leads (very likely) to skipping several UIO mapping regions and makes them useless. Fix this by computing dmem_region_start from the uiomem which points to the last used UIO mapping. Fixes: 0a0c3b5a ("Add new uio device for dynamic memory allocation") Signed-off-by:
Jan Viktorin <viktorin@rehivetech.com> Signed-off-by:
-
Sebastian Frias authored
BugLink: http://bugs.launchpad.net/bugs/1638267 commit ee26c013 upstream. Without this patch irq_domain_disassociate() cannot properly release the interrupt. In fact, irq_map_generic_chip() checks a bit on 'gc->installed' but said bit is never cleared, only set. Commit 088f40b7 ("genirq: Generic chip: Add linear irq domain support") added irq_map_generic_chip() function and also stated "This lacks a removal function for now". This commit provides an implementation of an unmap function that can be called by irq_domain_disassociate(). [ tglx: Made the function static and removed the export as we have neither a prototype nor a modular user. ] Fixes: 088f40b7 ("genirq: Generic chip: Add linear irq domain support") Signed-off-by:
Sebastian Frias <sf84@laposte.net> Cc: Marc Zyngier <marc.zyngier@arm.com> Cc: Mason <slash.tmp@free.fr> Cc: Jason Cooper <jason@lakedaemon.net> Link: http://lkml.kernel.org/r/579F5C5A.2070507@laposte.netSigned-off-by:
Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
-
Jiri Olsa authored
BugLink: http://bugs.launchpad.net/bugs/1638267 commit 51fd2df1 upstream. We broke interval data displays with commit: 3f416f22 ("perf stat: Do not clean event's private stats") This commit removed stats cleaning, which is important for '-r' option to carry counters data over the whole run. But it's necessary to clean it for interval mode, otherwise the displayed value is avg of all previous values. Before: $ perf stat -e cycles -a -I 1000 record # time counts unit events 1.000240796 75,216,287 cycles 2.000512791 107,823,524 cycles $ perf stat report # time counts unit events 1.000240796 75,216,287 cycles 2.000512791 91,519,906 cycles Now: $ perf stat report # time counts unit events 1.000240796 75,216,287 cycles 2.000512791 107,823,524 cycles Notice the second value being bigger (91,.. < 107,..). This could be easily verified by using perf script which displays raw stat data: $ perf script CPU THREAD VAL ENA RUN TIME EVENT 0 -1 23855779 1000209530 1000209530 1000240796 cycles 1 -1 33340397 1000224964 1000224964 1000240796 cycles 2 -1 15835415 1000226695 1000226695 1000240796 cycles 3 -1 2184696 1000228245 1000228245 1000240796 cycles 0 -1 97014312 2000514533 2000514533 2000512791 cycles 1 -1 46121497 2000543795 2000543795 2000512791 cycles 2 -1 32269530 2000543566 2000543566 2000512791 cycles 3 -1 7634472 2000544108 2000544108 2000512791 cycles The sum of the first 4 values is the first interval aggregated value: 23855779 + 33340397 + 15835415 + 2184696 = 75,216,287 The sum of the second 4 values minus first value is the second interval aggregated value: 97014312 + 46121497 + 32269530 + 7634472 - 75216287 = 107,823,524 Signed-off-by:
Jiri Olsa <jolsa@kernel.org> Cc: Andi Kleen <ak@linux.intel.com> Cc: David Ahern <dsahern@gmail.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: Stephane Eranian <eranian@google.com> Link: http://lkml.kernel.org/r/1454485436-20639-1-git-send-email-jolsa@kernel.orgSigned-off-by:
Arnaldo Carvalho de Melo <acme@redhat.com> Cc: Jeremy Linton <jeremy.linton@arm.com> Signed-off-by:
-
Russell Currey authored
BugLink: http://bugs.launchpad.net/bugs/1638267 commit 04fec21c upstream. eeh_pe_bus_get() can return NULL if a PCI bus isn't found for a given PE. Some callers don't check this, and can cause a null pointer dereference under certain circumstances. Fix this by checking NULL everywhere eeh_pe_bus_get() is called. Fixes: 8a6b1bc7 ("powerpc/eeh: EEH core to handle special event") Cc: stable@vger.kernel.org # v3.11+ Signed-off-by:
Russell Currey <ruscur@russell.cc> Reviewed-by:
Andrew Donnellan <andrew.donnellan@au1.ibm.com> Signed-off-by:
Michael Ellerman <mpe@ellerman.id.au> Signed-off-by:
-
Jesse Gross authored
BugLink: http://bugs.launchpad.net/bugs/1638267 commit b8cba75b upstream. ipip encapsulated packets can be merged together by GRO but the result does not have the proper GSO type set or even marked as being encapsulated at all. Later retransmission of these packets will likely fail if the device does not support ipip offloads. This is similar to the issue resolved in IPv6 sit in feec0cb3 ("ipv6: gro: support sit protocol"). Reported-by:
Patrick Boutilier <boutilpj@ednet.ns.ca> Fixes: 9667e9bb ("ipip: Add gro callbacks to ipip offload") Tested-by:
Eric Dumazet <edumazet@google.com> Signed-off-by:
Jesse Gross <jesse@kernel.org> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Juerg Haefliger <juerg.haefliger@hpe.com> Signed-off-by:
-
Jan Kara authored
BugLink: http://bugs.launchpad.net/bugs/1638267 commit 07393101 upstream. When file permissions are modified via chmod(2) and the user is not in the owning group or capable of CAP_FSETID, the setgid bit is cleared in inode_change_ok(). Setting a POSIX ACL via setxattr(2) sets the file permissions as well as the new ACL, but doesn't clear the setgid bit in a similar way; this allows to bypass the check in chmod(2). Fix that. References: CVE-2016-7097 Reviewed-by:
Christoph Hellwig <hch@lst.de> Reviewed-by:
Jeff Layton <jlayton@redhat.com> Signed-off-by:
Jan Kara <jack@suse.cz> Signed-off-by:
Andreas Gruenbacher <agruenba@redhat.com> Signed-off-by:
-
Gerald Schaefer authored
BugLink: http://bugs.launchpad.net/bugs/1638267 commit 2247bb33 upstream. Patch series "mm/hugetlb: memory offline issues with hugepages", v4. This addresses several issues with hugepages and memory offline. While the first patch fixes a panic, and is therefore rather important, the last patch is just a performance optimization. The second patch fixes a theoretical issue with reserved hugepages, while still leaving some ugly usability issue, see description. This patch (of 3): dissolve_free_huge_pages() will either run into the VM_BUG_ON() or a list corruption and addressing exception when trying to set a memory block offline that is part (but not the first part) of a "gigantic" hugetlb page with a size > memory block size. When no other smaller hugetlb page sizes are present, the VM_BUG_ON() will trigger directly. In the other case we will run into an addressing exception later, because dissolve_free_huge_page() will not work on the head page of the compound hugetlb page which will result in a NULL hstate from page_hstate(). To fix this, first remove the VM_BUG_ON() because it is wrong, and then use the compound head page in dissolve_free_huge_page(). This means that an unused pre-allocated gigantic page that has any part of itself inside the memory block that is going offline will be dissolved completely. Losing an unused gigantic hugepage is preferable to failing the memory offline, for example in the situation where a (possibly faulty) memory DIMM needs to go offline. Changes for v4.4 stable: - make it apply w/o commit c1470b33 "mm/hugetlb: fix incorrect hugepages count during mem hotplug" Fixes: c8721bbb ("mm: memory-hotplug: enable memory hotplug to handle hugepage") Link: http://lkml.kernel.org/r/20160926172811.94033-2-gerald.schaefer@de.ibm.comSigned-off-by:
Gerald Schaefer <gerald.schaefer@de.ibm.com> Acked-by:
Michal Hocko <mhocko@suse.com> Acked-by:
Naoya Horiguchi <n-horiguchi@ah.jp.nec.com> Cc: "Kirill A . Shutemov" <kirill.shutemov@linux.intel.com> Cc: Vlastimil Babka <vbabka@suse.cz> Cc: Mike Kravetz <mike.kravetz@oracle.com> Cc: "Aneesh Kumar K . V" <aneesh.kumar@linux.vnet.ibm.com> Cc: Martin Schwidefsky <schwidefsky@de.ibm.com> Cc: Heiko Carstens <heiko.carstens@de.ibm.com> Cc: Rui Teng <rui.teng@linux.vnet.ibm.com> Cc: Dave Hansen <dave.hansen@linux.intel.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:
-
Chris Wilson authored
BugLink: http://bugs.launchpad.net/bugs/1638267 commit ca5732c5 upstream. We use obj->phys_handle to choose the pread/pwrite path, but as obj->phys_handle is a union with obj->userptr, we then mistakenly use the phys_handle path for userptr objects within pread/pwrite. Testcase: igt/gem_userptr_blits/forbidden-operations Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97519Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20161003124516.12388-2-chris@chris-wilson.co.uk (cherry picked from commit 5f12b80a) Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Signed-off-by:
-
Ville Syrjälä authored
BugLink: http://bugs.launchpad.net/bugs/1638267 commit d721b02f upstream. Looks like the TSEG lives just above TOUD, stolen comes after TSEG. The spec seems somewhat self-contradictory in places, in the ESMRAMC register desctription it says: TSEG Size: 10=(TOUD + 512 KB) to TOUD 11 =(TOUD + 1 MB) to TOUD so that agrees with TSEG being at TOUD. But the example given elsehwere in the spec says: TOUD equals 62.5 MB = 03E7FFFFh TSEG selected as 512 KB in size, Graphics local memory selected as 1 MB in size General System RAM available in system = 62.5 MB General system RAM range00000000h to 03E7FFFFh TSEG address range03F80000h to 03FFFFFFh TSEG pre-allocated from03F80000h to 03FFFFFFh Graphics local memory pre-allocated from03E80000h to 03F7FFFFh so here we have TSEG above stolen. Real world evidence agrees with the TOUD->TSEG->stolen order however, so let's fix up the code to account for the TSEG size. Cc: Taketo Kabe <fdporg@vega.pgw.jp> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@redhat.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: x86@kernel.org Fixes: 0ad98c74 ("drm/i915: Determine the stolen memory base address on gen2") Fixes: a4dff769 ("x86/gpu: Add Intel graphics stolen memory quirk for gen2 platforms") Reported-by:
Taketo Kabe <fdporg@vega.pgw.jp> Tested-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1470653919-27251-1-git-send-email-ville.syrjala@linux.intel.com Link: http://download.intel.com/design/chipsets/datashts/25251405.pdfReviewed-by:
-
David Weinehall authored
BugLink: http://bugs.launchpad.net/bugs/1638267 commit 23f889bd upstream. This reverts commit 237ed86c. Our current implementation of live status check (repeat 9 times with 10ms delays between each attempt as a workaround for buggy displays) imposes a rather serious penalty, time wise, on intel_hdmi_detect(). Since we we already skip live status checks on platforms before gen 7, and since we seem to have coped quite well before the live status check was introduced for newer platforms too, the previous behaviour is probably preferable, at least unless someone can point to a use-case that the live status check improves (apart from "Bspec says so".) Signed-off-by:
David Weinehall <david.weinehall@linux.intel.com> Fixes: 237ed86c ("drm/i915: Check live status before reading edid") Fixes: f8d03ea0 ("drm/i915: increase the tries for HDMI hotplug live status checking") Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97139 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94014Acked-by:
-
Paulo Zanoni authored
BugLink: http://bugs.launchpad.net/bugs/1638267 commit 4e4d3814 upstream. Bspec says: "The mailbox response data may not account for memory read latency. If the mailbox response data for level 0 is 0us, add 2 microseconds to the result for each valid level." This means we should only do the +2 in case wm[0] == 0, not always. So split the sanitizing implementation from the WA implementation and fix the WA implementation. v2: Add Fixes tag (Maarten). Fixes: 367294be ("drm/i915/gen9: Add 2us read latency to WM level") Cc: Vandana Kannan <vandana.kannan@intel.com> Reviewed-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by:
Paulo Zanoni <paulo.r.zanoni@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1474578035-424-5-git-send-email-paulo.r.zanoni@intel.com (cherry picked from commit 0727e40a) Signed-off-by:
-
Thomas Hellstrom authored
BugLink: http://bugs.launchpad.net/bugs/1638267 commit 51ab70be upstream. With older hardware versions, the user could specify arbitrarily large command buffer sizes, causing a vmalloc / vmap space exhaustion. Signed-off-by:
Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by:
Brian Paul <brianp@vmware.com> Reviewed-by:
Sinclair Yeh <syeh@vmware.com> Signed-off-by:
-
Alex Deucher authored
BugLink: http://bugs.launchpad.net/bugs/1638267 commit 02cfb5fc upstream. Ported from Rex's amdgpu change. Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
-
Alex Deucher authored
BugLink: http://bugs.launchpad.net/bugs/1638267 commit 42792029 upstream. Used the wrong index to setup the phase shedding mask. Signed-off-by:
-
Alex Deucher authored
BugLink: http://bugs.launchpad.net/bugs/1638267 commit 884031f0 upstream. Only needed on CIK+ due to the way pci reset is handled by the GPU. Signed-off-by:
-
Rex Zhu authored
BugLink: http://bugs.launchpad.net/bugs/1638267 commit dc8184aa upstream. Signed-off-by:
Rex Zhu <Rex.Zhu@amd.com> Reviewed-by:
-
Grazvydas Ignotas authored
BugLink: http://bugs.launchpad.net/bugs/1638267 commit 140c94da upstream. All other amdgpu/dce_v* files have this call, it's only mysteriously missing from dce_v11_0.c since the file was added and causes leaks. Fixes: aaa36a97 ("drm/amdgpu: Add initial VI support") Signed-off-by:
Grazvydas Ignotas <notasas@gmail.com> Signed-off-by:
-
Alex Deucher authored
BugLink: http://bugs.launchpad.net/bugs/1638267 commit 3a9d993e upstream. Otherwise we can get a hotplug interrupt storm when we turn the panel off if hpd interrupts were enabled by the bios. bug: https://bugs.freedesktop.org/show_bug.cgi?id=97471Signed-off-by:
-
Alex Deucher authored
BugLink: http://bugs.launchpad.net/bugs/1638267 commit 32408258 upstream. Otherwise we can get a hotplug interrupt storm when we turn the panel off if hpd interrupts were enabled by the bios. bug: https://bugs.freedesktop.org/show_bug.cgi?id=97471Signed-off-by:
-
Alex Deucher authored
BugLink: http://bugs.launchpad.net/bugs/1638267 commit e96ec90f upstream. Otherwise we can get a hotplug interrupt storm when we turn the panel off if hpd interrupts were enabled by the bios. bug: https://bugs.freedesktop.org/show_bug.cgi?id=97471Signed-off-by:
-
Alex Deucher authored
BugLink: http://bugs.launchpad.net/bugs/1638267 commit c4795ca6 upstream. According to the hw team, it should be 16, not 8. Cc: Peter Fang <peter.fang@amd.com> Signed-off-by:
-
Chris Wilson authored
BugLink: http://bugs.launchpad.net/bugs/1638267 commit 56a76c01 upstream. dma_buf_export() adds a reference to the owning module to the dmabuf (to prevent the driver from being unloaded whilst a third party still refers to the dmabuf). However, drm_gem_prime_export() was passing its own THIS_MODULE (i.e. drm.ko) rather than the driver. Extract the right owner from the device->fops instead. v2: Use C99 initializers to zero out unset elements of dma_buf_export_info v3: Extract the right module from dev->fops. Testcase: igt/vgem_basic/unload Reported-by:
Petri Latvala <petri.latvala@intel.com> Signed-off-by:
Christian König <christian.koenig@amd.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20161005122145.1507-1-chris@chris-wilson.co.ukSigned-off-by:
-
Balbir Singh authored
BugLink: http://bugs.launchpad.net/bugs/1632045 When PCI Device pass-through is enabled via VFIO, KVM-PPC will pin pages using get_user_pages_fast(). One of the downsides of the pinning is that the page could be in CMA region. The CMA region is used for other allocations like the hash page table. Ideally we want the pinned pages to be from non CMA region. This patch (currently only for KVM PPC with VFIO) forcefully migrates the pages out (huge pages are omitted for the moment). There are more efficient ways of doing this, but that might be elaborate and might impact a larger audience beyond just the kvm ppc implementation. The magic is in new_iommu_non_cma_page() which allocates the new page from a non CMA region. I've tested the patches lightly at my end. The full solution requires migration of THP pages in the CMA region. That work will be done incrementally on top of this. Signed-off-by:
Balbir Singh <bsingharora@gmail.com> Acked-by:
Alexey Kardashevskiy <aik@ozlabs.ru> [mpe: Merged via powerpc tree as that's where the changes are] Signed-off-by:
Brad Figg <brad.figg@canonical.com> Acked-by:
Seth Forshee <seth.forshee@canonical.com>
-
Greg Kroah-Hartman authored
BugLink: http://bugs.launchpad.net/bugs/1637510Signed-off-by:
-
Dinesh Israni authored
BugLink: http://bugs.launchpad.net/bugs/1637510 commit 926317de upstream. This patch addresses a bug where a local EXTENDED_COPY WRITE or READ backend I/O request would always return SAM_STAT_CHECK_CONDITION, even if underlying xcopy_pt_cmd->se_cmd generated a different SCSI status code. ESX host environments expect to hit SAM_STAT_RESERVATION_CONFLICT for certain scenarios, and SAM_STAT_CHECK_CONDITION results in non-retriable status for these cases. Tested on v4.1.y with ESX v5.5u2+ with local IBLOCK backend copy. Reported-by:
Nixon Vincent <nixon.vincent@calsoftinc.com> Tested-by:
Dinesh Israni <ddi@datera.io> Signed-off-by:
Nicholas Bellinger <nab@linux-iscsi.org> Signed-off-by:
-
Nicholas Bellinger authored
BugLink: http://bugs.launchpad.net/bugs/1637510 commit 449a1378 upstream. This patch addresses a bug where EXTENDED_COPY across multiple LUNs results in a CHECK_CONDITION when the source + destination are not located on the same physical node. ESX Host environments expect sense COPY_ABORTED w/ COPY TARGET DEVICE NOT REACHABLE to be returned when this occurs, in order to signal fallback to local copy method. As described in section 6.3.3 of spc4r22: "If it is not possible to complete processing of a segment because the copy manager is unable to establish communications with a copy target device, because the copy target device does not respond to INQUIRY, or because the data returned in response to INQUIRY indicates an unsupported logical unit, then the EXTENDED COPY command shall be terminated with CHECK CONDITION status, with the sense key set to COPY ABORTED, and the additional sense code set to COPY TARGET DEVICE NOT REACHABLE." Tested on v4.1.y with ESX v5.5u2+ with BlockCopy across multiple nodes. Reported-by:
-
