- 20 Aug, 2016 40 commits
-
-
Jia He authored
commit 649920c6 upstream. In powerpc servers with large memory(32TB), we watched several soft lockups for hugepage under stress tests. The call traces are as follows: 1. get_page_from_freelist+0x2d8/0xd50 __alloc_pages_nodemask+0x180/0xc20 alloc_fresh_huge_page+0xb0/0x190 set_max_huge_pages+0x164/0x3b0 2. prep_new_huge_page+0x5c/0x100 alloc_fresh_huge_page+0xc8/0x190 set_max_huge_pages+0x164/0x3b0 This patch fixes such soft lockups. It is safe to call cond_resched() there because it is out of spin_lock/unlock section. Link: http://lkml.kernel.org/r/1469674442-14848-1-git-send-email-hejianet@gmail.comSigned-off-by:
Jia He <hejianet@gmail.com> Reviewed-by:
Naoya Horiguchi <n-horiguchi@ah.jp.nec.com> Acked-by:
Michal Hocko <mhocko@suse.com> Acked-by:
Dave Hansen <dave.hansen@linux.intel.com> Cc: Mike Kravetz <mike.kravetz@oracle.com> Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com> Cc: Paul Gortmaker <paul.gortmaker@windriver.com> 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>
-
Hector Palacios authored
commit 144f4c98 upstream. nand_do_write_ops() determines if it is writing a partial page with the formula: part_pagewr = (column || writelen < (mtd->writesize - 1)) When 'writelen' is exactly 1 byte less than the NAND page size the formula equates to zero, so the code doesn't process it as a partial write, although it should. As a consequence the function remains in the while(1) loop with 'writelen' becoming 0xffffffff and iterating endlessly. The bug may not be easy to reproduce in Linux since user space tools usually force the padding or round-up the write size to a page-size multiple. This was discovered in U-Boot where the issue can be reproduced by writing any size that is 1 byte less than a page-size multiple. For example, on a NAND with 2K page (0x800): => nand erase.part <partition> => nand write $loadaddr <partition> 7ff [Editor's note: the bug was added in commit 29072b96, but moved around in commit 66507c7b ("mtd: nand: Add support to use nand_base poi databuf as bounce buffer")] Fixes: 29072b96 ("[MTD] NAND: add subpage write support") Signed-off-by:
Hector Palacios <hector.palacios@digi.com> Acked-by:
Boris Brezillon <boris.brezillon@free-electrons.com> Signed-off-by:
Brian Norris <computersforpeace@gmail.com> Signed-off-by:
-
Jiri Kosina authored
commit ff06db1e upstream. Commit 09954bad ("floppy: refactor open() flags handling"), as a side-effect, causes open(/dev/fdX, O_ACCMODE) to fail. It turns out that this is being used setfdprm userspace for ioctl-only open(). Reintroduce back the original behavior wrt !(FMODE_READ|FMODE_WRITE) modes, while still keeping the original O_NDELAY bug fixed. Reported-by:
Wim Osterholt <wim@djo.tudelft.nl> Tested-by:
Jiri Kosina <jkosina@suse.cz> Signed-off-by:
Jens Axboe <axboe@fb.com> Signed-off-by:
-
Dan Williams authored
commit df08c32c upstream. The name for a bdi of a gendisk is derived from the gendisk's devt. However, since the gendisk is destroyed before the bdi it leaves a window where a new gendisk could dynamically reuse the same devt while a bdi with the same name is still live. Arrange for the bdi to hold a reference against its "owner" disk device while it is registered. Otherwise we can hit sysfs duplicate name collisions like the following: WARNING: CPU: 10 PID: 2078 at fs/sysfs/dir.c:31 sysfs_warn_dup+0x64/0x80 sysfs: cannot create duplicate filename '/devices/virtual/bdi/259:1' Hardware name: HP ProLiant DL580 Gen8, BIOS P79 05/06/2015 0000000000000286 0000000002c04ad5 ffff88006f24f970 ffffffff8134caec ffff88006f24f9c0 0000000000000000 ffff88006f24f9b0 ffffffff8108c351 0000001f0000000c ffff88105d236000 ffff88105d1031e0 ffff8800357427f8 Call Trace: [<ffffffff8134caec>] dump_stack+0x63/0x87 [<ffffffff8108c351>] __warn+0xd1/0xf0 [<ffffffff8108c3cf>] warn_slowpath_fmt+0x5f/0x80 [<ffffffff812a0d34>] sysfs_warn_dup+0x64/0x80 [<ffffffff812a0e1e>] sysfs_create_dir_ns+0x7e/0x90 [<ffffffff8134faaa>] kobject_add_internal+0xaa/0x320 [<ffffffff81358d4e>] ? vsnprintf+0x34e/0x4d0 [<ffffffff8134ff55>] kobject_add+0x75/0xd0 [<ffffffff816e66b2>] ? mutex_lock+0x12/0x2f [<ffffffff8148b0a5>] device_add+0x125/0x610 [<ffffffff8148b788>] device_create_groups_vargs+0xd8/0x100 [<ffffffff8148b7cc>] device_create_vargs+0x1c/0x20 [<ffffffff811b775c>] bdi_register+0x8c/0x180 [<ffffffff811b7877>] bdi_register_dev+0x27/0x30 [<ffffffff813317f5>] add_disk+0x175/0x4a0 Reported-by:
Yi Zhang <yizhan@redhat.com> Tested-by:
Dan Williams <dan.j.williams@intel.com> Signed-off-by:
-
Paolo Valente authored
commit 20bd723e upstream. When a bio is cloned, the newly created bio must be associated with the same blkcg as the original bio (if BLK_CGROUP is enabled). If this operation is not performed, then the new bio is not associated with any group, and the group of the current task is returned when the group of the bio is requested. Depending on the cloning frequency, this may cause a large percentage of the bios belonging to a given group to be treated as if belonging to other groups (in most cases as if belonging to the root group). The expected group isolation may thereby be broken. This commit adds the missing association in bio-cloning functions. Fixes: da2f0f74 ("Btrfs: add support for blkio controllers") Signed-off-by:
Paolo Valente <paolo.valente@linaro.org> Reviewed-by:
Nikolay Borisov <kernel@kyup.com> Reviewed-by:
Jeff Moyer <jmoyer@redhat.com> Acked-by:
Tejun Heo <tj@kernel.org> Signed-off-by:
-
James Hogan authored
commit 6154c187 upstream. The LNKGET based atomic sequence in __cmpxchg_u32 has slightly incorrect constraints for the return value which under certain circumstances can allow an address unit register to be used as the first operand of a CMP instruction. This isn't a valid instruction however as the encodings only allow a data unit to be specified. This would result in an assembler error like the following: Error: failed to assemble instruction: "CMP A0.2,D0Ar6" Fix by changing the constraint from "=&da" (assigned, early clobbered, data or address unit register) to "=&d" (data unit register only). The constraint for the second operand, "bd" (an op2 register where op1 is a data unit register and the instruction supports O2R) is already correct assuming the first operand is a data unit register. Other cases of CMP in inline asm have had their constraints checked, and appear to all be fine. Fixes: 6006c0d8 ("metag: Atomics, locks and bitops") Signed-off-by:
James Hogan <james.hogan@imgtec.com> Cc: linux-metag@vger.kernel.org Signed-off-by:
-
Laura Abbott authored
commit b2e1c26f upstream. glibc recently did a sync up (94e73c95d9b5 "elf.h: Sync with the gabi webpage") that added a #define for EM_METAG but did not add relocations This triggers build errors: scripts/recordmcount.c: In function 'do_file': scripts/recordmcount.c:466:28: error: 'R_METAG_ADDR32' undeclared (first use in this function) case EM_METAG: reltype = R_METAG_ADDR32; ^~~~~~~~~~~~~~ scripts/recordmcount.c:466:28: note: each undeclared identifier is reported only once for each function it appears in scripts/recordmcount.c:468:20: error: 'R_METAG_NONE' undeclared (first use in this function) rel_type_nop = R_METAG_NONE; ^~~~~~~~~~~~ Work around this change with some more #ifdefery for the relocations. Fedora Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1354034 Link: http://lkml.kernel.org/r/1468005530-14757-1-git-send-email-labbott@redhat.com Cc: James Hogan <james.hogan@imgtec.com> Fixes: 00512bdd ("metag: ftrace support") Reported-by:
Ross Burton <ross.burton@intel.com> Signed-off-by:
Laura Abbott <labbott@redhat.com> Signed-off-by:
Steven Rostedt <rostedt@goodmis.org> Signed-off-by:
-
Konstantin Neumoin authored
commit 37cf99e0 upstream. The balloon has a special mechanism that is subscribed to the oom notification which leads to deflation for a fixed number of pages. The number is always fixed even when the balloon is fully deflated. But leak_balloon did not expect that the pages to deflate will be more than taken, and raise a "BUG" in balloon_page_dequeue when page list will be empty. So, the simplest solution would be to check that the number of releases pages is less or equal to the number taken pages. Signed-off-by:
Konstantin Neumoin <kneumoin@virtuozzo.com> Signed-off-by:
Denis V. Lunev <den@openvz.org> CC: Michael S. Tsirkin <mst@redhat.com> Signed-off-by:
Michael S. Tsirkin <mst@redhat.com> Signed-off-by:
-
Mario Kleiner authored
commit 196f954e upstream. This reverts commit 013dd9e0 ("drm/i915/dp: fall back to 18 bpp when sink capability is unknown") This commit introduced a regression into stable kernels, as it reduces output color depth to 6 bpc for any video sink connected to a Displayport connector if that sink doesn't report a specific color depth via EDID, or if our EDID parser doesn't actually recognize the proper bpc from EDID. Affected are active DisplayPort->VGA converters and active DisplayPort->DVI converters. Both should be able to handle 8 bpc, but are degraded to 6 bpc with this patch. The reverted commit was meant to fix Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=105331 A followup patch implements a fix for that specific bug, which is caused by a faulty EDID of the affected DP panel by adding a new EDID quirk for that panel. DP 18 bpp fallback handling and other improvements to DP sink bpc detection will be handled for future kernels in a separate series of patches. Please backport to stable. Signed-off-by:
Mario Kleiner <mario.kleiner.de@gmail.com> Acked-by:
Jani Nikula <jani.nikula@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
Dave Airlie <airlied@redhat.com> Signed-off-by:
-
Ville Syrjälä authored
commit a7b4667a upstream. SNB (and IVB too I suppose) starts to misbehave if the GPU gets stuck in an infinite batch buffer loop. The GPU apparently hogs something critical and CPUs start to lose interrupts and whatnot. We can keep the system limping along by unmasking some interrupts in GEN6_PMINTRMSK. The EI up interrupt has been previously chosen for that task, so let's never mask it. v2: s/gen6_rps_pm_mask/gen6_sanitize_rps_pm_mask/ (Chris) Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93122Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
-
Mario Kleiner authored
commit e10aec65 upstream. Bugzilla https://bugzilla.kernel.org/show_bug.cgi?id=105331 reports that the "AEO model 0" display is driven with 8 bpc without dithering by default, which looks bad because that panel is apparently a 6 bpc DP panel with faulty EDID. A fix for this was made by commit 013dd9e0 ("drm/i915/dp: fall back to 18 bpp when sink capability is unknown"). That commit triggers new regressions in precision for DP->DVI and DP->VGA displays. A patch is out to revert that commit, but it will revert video output for the AEO model 0 panel to 8 bpc without dithering. The EDID 1.3 of that panel, as decoded from the xrandr output attached to that bugzilla bug report, is somewhat faulty, and beyond other problems also sets the "DFP 1.x compliant TMDS" bit, which according to DFP spec means to drive the panel with 8 bpc and no dithering in absence of other colorimetry information. Try to make the original bug reporter happy despite the faulty EDID by adding a quirk to mark that panel as 6 bpc, so 6 bpc output with dithering creates a nice picture. Tested by injecting the edid from the fdo bug into a DP connector via drm_kms_helper.edid_firmware and verifying the 6 bpc + dithering is selected. This patch should be backported to stable. Signed-off-by:
-
Ville Syrjälä authored
commit a1f5524a upstream. Restore the correct behaviour (as in check msg.reply) when aux ->transfer() returns 0. It got removed in commit 82922da3 ("drm/dp_helper: Retry aux transactions on all errors") Now I can actually dump the "entire" DPCD on a Dell UP2314Q with ddrescue. It has some offsets in the DPCD that can't be read for some resaon, all you get is defers. Previously ddrescue would just give up at the first unredable offset on account of read() returning 0 means EOF. Here's the ddrescue log for the interested: 0x00000000 0x00001400 + 0x00001400 0x00000030 - 0x00001430 0x000001D0 + 0x00001600 0x00000030 - 0x00001630 0x0001F9D0 + 0x00021000 0x00000001 - 0x00021001 0x000DEFFF + Cc: Lyude <cpaul@redhat.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch Fixes: 82922da3 ("drm/dp_helper: Retry aux transactions on all errors") Signed-off-by:
-
Mika Kuoppala authored
commit f15f6ca1 upstream. Add this workaround to prevent hang when in place compression is used. References: HSD#2135774 Signed-off-by:
Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by:
Arun Siluvery <arun.siluvery@linux.intel.com> Signed-off-by:
Joonas Lahtinen <joonas.lahtinen@linux.intel.com> (cherry picked from commit 4ba9c1f7) Signed-off-by:
-
John Keeping authored
commit dc0b408f upstream. Because we are using a custom crtc_state structure, we must override the reset helper to allocate the correct amount of memory. Fixes: 4e257d9e ("drm/rockchip: get rid of rockchip_drm_crtc_mode_config") Signed-off-by:
John Keeping <john@metanate.com> Signed-off-by:
Mark Yao <mark.yao@rock-chips.com> Reviewed-by:
Sean Paul <seanpaul@chromium.org> Signed-off-by:
-
Huang Rui authored
commit bec5f70d upstream. The return value 0 (false) means fail to find GPIO in atomctrl_get_pp_assign_pin. "-1" returns true as bool actually. Signed-off-by:
Huang Rui <ray.huang@amd.com> Reviewed-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
-
Ville Syrjälä authored
commit 7f1052a8 upstream. Update CDCLK_FREQ on BDW after changing the cdclk frequency. Not sure if this is a late addition to the spec, or if I simply overlooked this step when writing the original code. This is what Bspec has to say about CDCLK_FREQ: "Program this field to the CD clock frequency minus one. This is used to generate a divided down clock for miscellaneous timers in display." And the "Broadwell Sequences for Changing CD Clock Frequency" section clarifies this further: "For CD clock 337.5 MHz, program 337 decimal. For CD clock 450 MHz, program 449 decimal. For CD clock 540 MHz, program 539 decimal. For CD clock 675 MHz, program 674 decimal." Cc: Mika Kahola <mika.kahola@intel.com> Fixes: b432e5cf ("drm/i915: BDW clock change support") Signed-off-by:
Mika Kahola <mika.kahola@intel.com> Signed-off-by:
-
Chris Wilson authored
commit 396f5d62 upstream. This effectively reverts commit afcd950c Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Wed Jun 10 15:58:01 2015 +0100 drm: Avoid the double clflush on the last cache line in drm_clflush_virt_range() as we have observed issues with serialisation of the clflush operations on Baytrail+ Atoms with partial updates. Applying the double flush on the last cacheline forces that clflush to be ordered with respect to the previous clflush, and the mfence then protects against prefetches crossing the clflush boundary. The same issue can be demonstrated in userspace with igt/gem_exec_flush. Fixes: afcd950c (drm: Avoid the double clflush on the last cache...) Testcase: igt/gem_concurrent_blit Testcase: igt/gem_partial_pread_pwrite Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92845Signed-off-by:
-
Mikulas Patocka authored
commit 28668f43 upstream. The patch f045f459 ("drm/nouveau/fbcon: fix out-of-bounds memory accesses") tries to fix some out of memory accesses. Unfortunatelly, the patch breaks the display when using fonts with width that is not divisiable by 8. The monochrome bitmap for each character is stored in memory by lines from top to bottom. Each line is padded to a full byte. For example, for 22x11 font, each line is padded to 16 bits, so each character is consuming 44 bytes total, that is 11 32-bit words. The patch f045f459 changed the logic to "dsize = ALIGN(image->width * image->height, 32) >> 5", that is just 8 words - this is incorrect and it causes display corruption. This patch adds the necesary padding of lines to 8 bytes. This patch should be backported to stable kernels where f045f459 was backported. Signed-off-by:
Mikulas Patocka <mpatocka@redhat.com> Fixes: f045f459 ("drm/nouveau/fbcon: fix out-of-bounds memory accesses") Signed-off-by:
Ben Skeggs <bskeggs@redhat.com> Signed-off-by:
-
Ilia Mirkin authored
commit d0e62ef6 upstream. This should fix some unaligned access warnings. This is also likely to fix non-descript issues on nv30/nv34 as a result of incorrect channel setup. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96836Signed-off-by:
Ilia Mirkin <imirkin@alum.mit.edu> Signed-off-by:
-
Ben Skeggs authored
commit 0e67bed2 upstream. Signed-off-by:
-
Alex Deucher authored
commit d3200be6 upstream. Same interface as other UNIPHY blocks Signed-off-by:
-
Alex Deucher authored
commit 3edc38a0 upstream. Some of the checks didn't handle frev 2 tables properly. Signed-off-by:
-
Lyude authored
commit 14ff8d48 upstream. DRM_CONNECTOR_POLL_CONNECT only enables polling for connections, not disconnections. Because of this, we end up losing hotplug polling for analog connectors once they get connected. Easy way to reproduce: - Grab a machine with a radeon GPU and a VGA port - Plug a monitor into the VGA port, wait for it to update the connector from disconnected to connected - Disconnect the monitor on VGA, a hotplug event is never sent for the removal of the connector. Originally, only using DRM_CONNECTOR_POLL_CONNECT might have been a good idea since doing VGA polling can sometimes result in having to mess with the DAC voltages to figure out whether or not there's actually something there since VGA doesn't have HPD. Doing this would have the potential of showing visible artifacts on the screen every time we ran a poll while a VGA display was connected. Luckily, radeon_vga_detect() only resorts to this sort of polling if the poll is forced, and DRM's polling helper doesn't force it's polls. Additionally, this removes some assignments to connector->polled that weren't actually doing anything. Signed-off-by:
Lyude <cpaul@redhat.com> Signed-off-by:
-
Alex Deucher authored
commit d814b24f upstream. ATPX dGPU power control requires a 200ms delay between power off and on. This should fix dGPU failures on resume from power off. Reviewed-by:
Hawking Zhang <Hawking.Zhang@amd.com> Acked-by:
Christian König <christian.koenig@amd.com> Signed-off-by:
-
Alex Deucher authored
commit 7f555c8e upstream. Looks like this got missed when we ported the code from radeon. Reviewed-by:
Edward O'Callaghan <funfunctor@folklore1984.net> Signed-off-by:
-
Alex Deucher authored
commit a8a04c99 upstream. Some of the checks didn't handle frev 2 tables properly. amdgpu doesn't support any tables pre-frev 2, so drop the checks. Signed-off-by:
-
Lyude authored
commit 23a1a9e5 upstream. Just about all of amdgpu's connector probing functions try to acquire runtime PM refs. If we try to do this in the context of amdgpu_resume_kms by calling drm_helper_hpd_irq_event(), we end up deadlocking the system. Since we're guaranteed to be holding the spinlock for RPM in amdgpu_resume_kms, and we already know the GPU is in working order, we need to prevent the RPM helpers from trying to run during the initial connector reprobe on resume. There's a couple of solutions I've explored for fixing this, but this one by far seems to be the simplest and most reliable (plus I'm pretty sure that's what disable_depth is there for anyway). Reproduction recipe: - Get any laptop dual GPUs using PRIME - Make sure runtime PM is enabled for amdgpu - Boot the machine - If the machine managed to boot without hanging, switch out of X to another VT. This should definitely cause X to hang infinitely. Changes since v1: - add appropriate #ifdef checks for CONFIG_PM. This is not very useful, but it appears some kernel test suites test compiling amdgpu with CONFIG_PM disabled, which results in this patch breaking the builds if we don't include this #ifdef Cc: Alex Deucher <alexdeucher@gmail.com> Reviewed-by:
-
Alex Deucher authored
commit dba6c4fa upstream. Same interface as other UNIPHY blocks Signed-off-by:
-
Lyude authored
commit b636a1b3 upstream. DRM_CONNECTOR_POLL_CONNECT only enables polling for connections, not disconnections. Because of this, we end up losing hotplug polling for analog connectors once they get connected. Easy way to reproduce: - Grab a machine with an AMD GPU and a VGA port - Plug a monitor into the VGA port, wait for it to update the connector from disconnected to connected - Disconnect the monitor on VGA, a hotplug event is never sent for the removal of the connector. Originally, only using DRM_CONNECTOR_POLL_CONNECT might have been a good idea since doing VGA polling can sometimes result in having to mess with the DAC voltages to figure out whether or not there's actually something there since VGA doesn't have HPD. Doing this would have the potential of showing visible artifacts on the screen every time we ran a poll while a VGA display was connected. Luckily, amdgpu_vga_detect() only resorts to this sort of polling if the poll is forced, and DRM's polling helper doesn't force it's polls. Additionally, this removes some assignments to connector->polled that weren't actually doing anything. Signed-off-by:
-
Alex Deucher authored
commit f81eb1a3 upstream. ATPX dGPU power control requires a 200ms delay between power off and on. This should fix dGPU failures on resume from power off. Reviewed-by:
-
H. Nikolaus Schaller authored
commit ecfaf0c4 upstream. Commit e93762bb ("w1: masters: omap_hdq: add support for 1-wire mode") added a statement to clear the hdq_irqstatus flags in hdq_read_byte(). If the hdq reading process is scheduled slowly or interrupts are disabled for a while the hardware read activity might already be finished on entry of hdq_read_byte(). And hdq_isr() already has set the hdq_irqstatus to 0x6 (can be seen in debug mode) denoting that both, the TXCOMPLETE and RXCOMPLETE interrupts occurred in parallel. This means there is no need to wait and the hdq_read_byte() can just read the byte from the hdq controller. By resetting hdq_irqstatus to 0 the read process is forced to be always waiting again (because the if statement always succeeds) but the hardware will not issue another RXCOMPLETE interrupt. This results in a false timeout. After such a situation the hdq bus hangs. Link: http://lkml.kernel.org/r/b724765f87ad276a69625bc19806c8c8844c4590.1469513669.git.hns@goldelico.comSigned-off-by:
H. Nikolaus Schaller <hns@goldelico.com> Cc: Evgeniy Polyakov <zbr@ioremap.net> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
-
Paul Moore authored
commit 0e0e3677 upstream. It seems risky to always rely on the caller to ensure the socket's address family is correct before passing it to the NetLabel kAPI, especially since we see at least one LSM which didn't. Add address family checks to the *_delattr() functions to help prevent future problems. Reported-by:
Maninder Singh <maninder1.s@samsung.com> Signed-off-by:
Paul Moore <paul@paul-moore.com> Signed-off-by:
-
Bjorn Andersson authored
commit 63af8e44 upstream. The valid_entries index should not be incremented until after we have acquired the pointer to the value, or we will read and write data one item off. Fixes: 50e99641 ("soc: qcom: smp2p: Qualcomm Shared Memory Point to Point") Signed-off-by:
Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by:
Andy Gross <andy.gross@linaro.org> Signed-off-by:
-
Xing Zheng authored
commit 3770821f upstream. The CLKSEL_CON32 bit_0 is controlled for spdif_8ch, not spdif_rec_dptx, it should be bit_8, let's fix it. Fixes: 11551005 ("clk: rockchip: add clock controller for the RK3399") Reported-by:
Chris Zhong <zyw@rock-chips.com> Tested-by:
Xing Zheng <zhengxing@rock-chips.com> Signed-off-by:
Heiko Stuebner <heiko@sntech.de> Signed-off-by:
-
Jarkko Sakkinen authored
commit f786b752 upstream. When running make C=2 M=drivers/char/tpm/ CHECK drivers/char/tpm//tpm_crb.c drivers/char/tpm//tpm_crb.c:248:31: warning: incorrect type in return expression (different address spaces) drivers/char/tpm//tpm_crb.c:248:31: expected void [noderef] <asn:2>* drivers/char/tpm//tpm_crb.c:248:31: got void * Fixes: 1bd047be ("tpm_crb: Use devm_ioremap_resource") Signed-off-by:
Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> Tested-by:
Stefan Berger <stefanb@linux.vnet.ibm.com> Signed-off-by:
-
Eric W. Biederman authored
commit 726a4994 upstream. Unprivileged users can't use hierarchies if they create them as they do not have privilieges to the root directory. Which means the only thing a hiearchy created by an unprivileged user is good for is expanding the number of cgroup links in every css_set, which is a DOS attack. We could allow hierarchies to be created in namespaces in the initial user namespace. Unfortunately there is only a single namespace for the names of heirarchies, so that is likely to create more confusion than not. So do the simple thing and restrict hiearchy creation to the initial cgroup namespace. Fixes: a79a908f ("cgroup: introduce cgroup namespaces") Signed-off-by:
"Eric W. Biederman" <ebiederm@xmission.com> Signed-off-by:
-
Eric W. Biederman authored
commit eedd0f4c upstream. In most code paths involving cgroup migration cgroup_threadgroup_rwsem is taken. There are two exceptions: - remove_tasks_in_empty_cpuset calls cgroup_transfer_tasks - vhost_attach_cgroups_work calls cgroup_attach_task_all With cgroup_threadgroup_rwsem held it is guaranteed that cgroup_post_fork and copy_cgroup_ns will reference the same css_set from the process calling fork. Without such an interlock there process after fork could reference one css_set from it's new cgroup namespace and another css_set from task->cgroups, which semantically is nonsensical. Fixes: a79a908f ("cgroup: introduce cgroup namespaces") Signed-off-by:
-
Eric W. Biederman authored
commit 7bd88308 upstream. If "clone(CLONE_NEWCGROUP...)" is called it results in a nice lockdep valid splat. In __cgroup_proc_write the lock ordering is: cgroup_mutex -- through cgroup_kn_lock_live cgroup_threadgroup_rwsem In copy_process the guts of clone the lock ordering is: cgroup_threadgroup_rwsem -- through threadgroup_change_begin cgroup_mutex -- through copy_namespaces -- copy_cgroup_ns lockdep reports some a different call chains for the first ordering of cgroup_mutex and cgroup_threadgroup_rwsem but it is harder to trace. This is most definitely deadlock potential under the right circumstances. Fix this by by skipping the cgroup_mutex and making the locking in copy_cgroup_ns mirror the locking in cgroup_post_fork which also runs during fork under the cgroup_threadgroup_rwsem. Fixes: a79a908f ("cgroup: introduce cgroup namespaces") Signed-off-by:
-
Arnd Bergmann authored
commit 7a376ac1 upstream. The patch that this was preparing for made it into neither v4.7 nor v4.8, so we should back this out as well to avoid the opposite warning: arch/arm/configs/aspeed_g5_defconfig:62:warning: symbol value '1' invalid for PRINTK_TIME arch/arm/configs/aspeed_g4_defconfig:61:warning: symbol value '1' invalid for PRINTK_TIME Sorry for not catching this earlier. Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Fixes: 0ef659a3 ("ARM: aspeed: adapt defconfigs for new CONFIG_PRINTK_TIME") Signed-off-by:
-
Ralf Ramsauer authored
commit b5c86b74 upstream. c90bb7b9 enabled the high speed UARTs of the Jetson TK1. Due to a merge quirk, wrong addresses were introduced. Fix it and use the correct addresses. Thierry let me know, that there is another patch (b5896f67 in linux-next) in preparation which removes all the '0,' prefixes of unit addresses on Tegra124 and is planned to go upstream in 4.8, so this patch will get reverted then. But for the moment, this patch is necessary to fix current misbehaviour. Fixes: c90bb7b9 ("ARM: tegra: Add high speed UARTs to Jetson TK1 device tree") Signed-off-by:
Ralf Ramsauer <ralf@ramses-pyramidenbau.de> Acked-by:
Thierry Reding <thierry.reding@gmail.com> Cc: linux-tegra@vger.kernel.org Signed-off-by:
-
