- 05 Oct, 2014 40 commits
-
-
Robin Murphy authored
commit 5ca918e5 upstream. The alignment fixup incorrectly decodes faulting ARM VLDn/VSTn instructions (where the optional alignment hint is given but incorrect) as LDR/STR, leading to register corruption. Detect these and correctly treat them as unhandled, so that userspace gets the fault it expects. Reported-by:
Simon Hosie <simon.hosie@arm.com> Signed-off-by:
Robin Murphy <robin.murphy@arm.com> Signed-off-by:
Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Shawn Guo authored
commit 9e1ac462 upstream. Commit 63288b72 ("ARM: imx: fix shared gate clock") attempted to fix an issue with particular enable/disable sequence from two shared gate clocks. But unfortunately, while it partially fixed the issue, it also did something wrong in .is_enabled() function hook. In case of shared gate, the function shouldn't really query the hardware state via share_count, because the function is trying to query the enabling state of the clock in question, not the hardware state which is shared by multiple clocks. Fix the issue by returning the enable_count of the clock itself which is maintained by clock core, in case it's a clock sharing hardware gate with others. As the result, the initialization of share_count per hardware state is not needed now. So remove it. Reported-by:
Fabio Estevam <fabio.estevam@freescale.com> Fixes: 63288b72 ("ARM: imx: fix shared gate clock") Signed-off-by:
Shawn Guo <shawn.guo@freescale.com> Tested-by:
Olof Johansson <olof@lixom.net> Signed-off-by:
-
Markus Niebel authored
commit 1b134c9c upstream. using LVDS channel 1 on an i.MX53 leads to following error: imx-ldb 53fa8008.ldb: unable to set di0 parent clock to ldb_di1 This comes from imx_ldb_set_clock with mux = 0. Mux parameter must be "1" for reparenting di1 clock to ldb_di1. The value of the mux param comes from device tree port settings. On i.MX5, the internal two-input-multiplexer is used. Due to hardware limitations, only one port (port@[0,1]) can be used for each channel (lvds-channel@[0,1], respectively) Documentation update suggested by Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by:
Markus Niebel <Markus.Niebel@tq-group.com> Fixes: e05c8c9a ("ARM: dts: imx53: Add IPU DI ports and endpoints, move imx-drm node to dtsi") Acked-by:
Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
-
Roger Quadros authored
commit 5990047c upstream. The nand timings were scaled down by 2 to account for the 2x rate returned by clk_get_rate(gpmc_fclk). As the clock data got fixed by [1], revert back to actual timings (i.e. scale them up by 2). Without this NAND doesn't work on dra7-evm. [1] - commit dd94324b ARM: dts: dra7xx-clocks: Fix the l3 and l4 clock rates Fixes: ff66a3c8 ("ARM: dts: dra7: add support for parallel NAND flash") Signed-off-by:
Roger Quadros <rogerq@ti.com> Signed-off-by:
Tony Lindgren <tony@atomide.com> Signed-off-by:
-
Stephen Boyd authored
commit 505013bc upstream. Rob Clark reports a sleeping while atomic bug when using perf. BUG: sleeping function called from invalid context at ../kernel/locking/mutex.c:583 in_atomic(): 1, irqs_disabled(): 128, pid: 0, name: swapper/0 ------------[ cut here ]------------ WARNING: CPU: 2 PID: 4828 at ../kernel/locking/mutex.c:479 mutex_lock_nested+0x3a0/0x3e8() DEBUG_LOCKS_WARN_ON(in_interrupt()) Modules linked in: CPU: 2 PID: 4828 Comm: Xorg.bin Tainted: G W 3.17.0-rc3-00234-gd535c45-dirty #819 [<c0216690>] (unwind_backtrace) from [<c0212174>] (show_stack+0x10/0x14) [<c0212174>] (show_stack) from [<c0867cc0>] (dump_stack+0x98/0xb8) [<c0867cc0>] (dump_stack) from [<c02492a4>] (warn_slowpath_common+0x70/0x8c) [<c02492a4>] (warn_slowpath_common) from [<c02492f0>] (warn_slowpath_fmt+0x30/0x40) [<c02492f0>] (warn_slowpath_fmt) from [<c086a3f8>] (mutex_lock_nested+0x3a0/0x3e8) [<c086a3f8>] (mutex_lock_nested) from [<c0294d08>] (irq_find_host+0x20/0x9c) [<c0294d08>] (irq_find_host) from [<c0769d50>] (of_irq_get+0x28/0x48) [<c0769d50>] (of_irq_get) from [<c057d104>] (platform_get_irq+0x1c/0x8c) [<c057d104>] (platform_get_irq) from [<c021a06c>] (cpu_pmu_enable_percpu_irq+0x14/0x38) [<c021a06c>] (cpu_pmu_enable_percpu_irq) from [<c02b1634>] (flush_smp_call_function_queue+0x88/0x178) [<c02b1634>] (flush_smp_call_function_queue) from [<c0214dc0>] (handle_IPI+0x88/0x160) [<c0214dc0>] (handle_IPI) from [<c0208930>] (gic_handle_irq+0x64/0x68) [<c0208930>] (gic_handle_irq) from [<c0212d04>] (__irq_svc+0x44/0x5c) Exception stack(0xe63ddea0 to 0xe63ddee8) dea0: 00000001 00000001 00000000 c2f3b200 c16db380 c032d4a0 e63ddf40 60010013 dec0: 00000000 001fbfd4 00000100 00000000 00000001 e63ddee8 c0284770 c02a2e30 dee0: 20010013 ffffffff [<c0212d04>] (__irq_svc) from [<c02a2e30>] (ktime_get_ts64+0x1c8/0x200) [<c02a2e30>] (ktime_get_ts64) from [<c032d4a0>] (poll_select_set_timeout+0x60/0xa8) [<c032d4a0>] (poll_select_set_timeout) from [<c032df64>] (SyS_select+0xa8/0x118) [<c032df64>] (SyS_select) from [<c020e8e0>] (ret_fast_syscall+0x0/0x48) ---[ end trace 0bb583b46342da6f ]--- INFO: lockdep is turned off. We don't really need to get the platform irq again when we're enabling or disabling the per-cpu irq. Furthermore, we don't really need to set and clear bits in the active_irqs bitmask because that's only used in the non-percpu irq case to figure out when the last CPU PMU has been disabled. Just pass the irq directly to the enable/disable functions to clean all this up. This should be slightly more efficient and also fix the scheduling while atomic bug. Fixes: bbd64559 "ARM: perf: support percpu irqs for the CPU PMU" Reported-by:
Rob Clark <robdclark@gmail.com> Acked-by:
Will Deacon <will.deacon@arm.com> Signed-off-by:
Stephen Boyd <sboyd@codeaurora.org> Signed-off-by:
-
Nathan Lynch authored
commit fbfb872f upstream. The TPIDRURO and TPIDRURW registers need to be flushed during exec; otherwise TLS information is potentially leaked. TPIDRURO in particular needs careful treatment. Since flush_thread basically needs the same code used to set the TLS in arm_syscall, pull that into a common set_tls helper in tls.h and use it in both places. Similarly, TEEHBR needs to be cleared during exec as well. Clearing its save slot in thread_info isn't right as there is no guarantee that a thread switch will occur before the new program runs. Just setting the register directly is sufficient. Signed-off-by:
Nathan Lynch <nathan_lynch@mentor.com> Acked-by:
-
Sudeep Holla authored
commit a040803a upstream. Since commit 1dbfa187 ("ARM: irq migration: force migration off CPU going down") the ARM interrupt migration code on cpu offline calls irqchip.irq_set_affinity() with the argument force=true. At the point of this change the argument had no effect because it was not used by any interrupt chip driver and there was no semantics defined. This changed with commit 01f8fa4f ("genirq: Allow forcing cpu affinity of interrupts") which made the force argument useful to route interrupts to not yet online cpus without checking the target cpu against the cpu online mask. The following commit ffde1de6 ("irqchip: gic: Support forced affinity setting") implemented this for the GIC interrupt controller. As a consequence the ARM cpu offline irq migration fails if CPU0 is offlined, because CPU0 is still set in the affinity mask and the validataion against cpu online mask is skipped to the force argument being true. The following first_cpu(mask) selection always selects CPU0 as the target. Solve the issue by calling irq_set_affinity() with force=false from the CPU offline irq migration code so the GIC driver validates the affinity mask against CPU online mask and therefore removes CPU0 from the possible target candidates. Tested on TC2 hotpluging CPU0 in and out. Without this patch the system locks up as the IRQs are not migrated away from CPU0. Signed-off-by:
Sudeep Holla <sudeep.holla@arm.com> Acked-by:
Thomas Gleixner <tglx@linutronix.de> Acked-by:
Mark Rutland <mark.rutland@arm.com> Signed-off-by:
-
Nishanth Menon authored
commit 68e4d9e5 upstream. While auditing the various pin ctrl configurations using the following command: grep PIN_ arch/arm/boot/dts/dra7-evm.dts|(while read line; do v=`echo "$line" | sed -e "s/\s\s*/|/g" | cut -d '|' -f1 | cut -d 'x' -f2|tr [a-z] [A-Z]`; HEX=`echo "obase=16;ibase=16;4A003400+$v"| bc`; echo "$HEX ===> $line"; done) against DRA75x/74x NDA TRM revision S(SPRUHI2S August 2014), documentation errors were found for spi1 pinctrl. Fix the same. Fixes: 6e58b8f1 ("ARM: dts: DRA7: Add the dts files for dra7 SoC and dra7-evm board") Signed-off-by:
Nishanth Menon <nm@ti.com> Signed-off-by:
-
Peter Ujfalusi authored
commit 929a015b upstream. The edma_setup_from_hw() should know about the CC number when parsing the CCCFG register - when it reads the register to be precise. The base addresses for CCs stored in an array and we need to provide the correct id to edma_read() in order to read the correct register. Signed-off-by:
Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by:
Sekhar Nori <nsekhar@ti.com> Signed-off-by:
-
Nishanth Menon authored
commit e49d519c upstream. GPIO modules are also interrupt sources. However, they require both the GPIO number and IRQ type to function properly. By declaring that GPIO uses interrupt-cells=<1>, we essentially do not allow users of the nodes to use the interrupt property appropritely. With this change, the following now works: interrupt-parent = <&gpio6>; interrupts = <5 IRQ_TYPE_LEVEL_LOW>; Fixes: 6e58b8f1 ('ARM: dts: DRA7: Add the dts files for dra7 SoC and dra7-evm board') Signed-off-by:
-
Rajendra Nayak authored
commit f7f7a29b upstream. To deal with IPs which are specific to dra74x and dra72x, maintain seperate ocp interface lists, while keeping the common list for all common IPs. Move USB OTG SS4 to dra74x only list since its unavailable in dra72x and is giving an abort during boot. The dra72x only list is empty for now and a placeholder for future hwmod additions which are specific to dra72x. Fixes: d904b38d ("ARM: DRA7: hwmod: Add SYSCONFIG for usb_otg_ss") Reported-by:
Keerthy <j-keerthy@ti.com> Signed-off-by:
Rajendra Nayak <rnayak@ti.com> Signed-off-by:
Lokesh Vutla <lokeshvutla@ti.com> Tested-by:
Paul Walmsley <paul@pwsan.com> Signed-off-by:
-
Fabio Estevam authored
commit 090727b8 upstream. The following error is seen after a suspend/resume cycle on a mx53qsb with a MC34708 PMIC: root@freescale /$ echo mem > /sys/power/state [ 32.630592] PM: Syncing filesystems ... done. [ 32.643924] Freezing user space processes ... (elapsed 0.001 seconds) done. [ 32.652384] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done. [ 32.679156] PM: suspend of devices complete after 13.113 msecs [ 32.685128] PM: suspend devices took 0.030 seconds [ 32.696109] PM: late suspend of devices complete after 6.133 msecs [ 33.313032] mc13xxx 0-0008: Failed to read IRQ status: -110 [ 33.322009] PM: noirq suspend of devices complete after 619.667 msecs [ 33.328544] Disabling non-boot CPUs ... [ 33.335031] PM: noirq resume of devices complete after 2.352 msecs [ 33.842940] mc13xxx 0-0008: Failed to read IRQ status: -110 [ 33.976095] [sched_delayed] sched: RT throttling activated [ 33.984804] PM: early resume of devices complete after 642.642 msecs [ 34.352954] mc13xxx 0-0008: Failed to read IRQ status: -110 [ 34.862910] mc13xxx 0-0008: Failed to read IRQ status: -110 [ 34.996595] PM: resume of devices complete after 1005.367 msecs [ 35.372925] mc13xxx 0-0008: Failed to read IRQ status: -110 [ 35.882911] mc13xxx 0-0008: Failed to read IRQ status: -110 [ 35.955707] PM: resume devices took 1.970 seconds [ 35.960445] Restarting tasks ... done. [ 35.993386] fec 63fec000.ethernet eth0: Link is Down [ 36.392980] mc13xxx 0-0008: Failed to read IRQ status: -110 [ 36.902908] mc13xxx 0-0008: Failed to read IRQ status: -110 [ 36.953036] ata1: SATA link down (SStatus 0 SControl 300) [ 37.412922] mc13xxx 0-0008: Failed to read IRQ status: -110 [ 37.922906] mc13xxx 0-0008: Failed to read IRQ status: -110 [ 37.993379] fec 63fec000.ethernet eth0: Link is Up - 100Mbps/Full - flow control rx/tx [ 38.432938] mc13xxx 0-0008: Failed to read IRQ status: -110 [ 38.942920] mc13xxx 0-0008: Failed to read IRQ status: -110 [ 39.452933] mc13xxx 0-0008: Failed to read IRQ status: -110 (flood of this error message continues forever) Commit 5169df8b ("ARM: dts: i.MX53: add support for MCIMX53-START-R") missed to configure the IOMUX for the PMIC IRQ pin. Configure the PMIC IRQ pin so that the suspend/resume sequence behaves cleanly as expected. Signed-off-by:
-
Mark Rutland authored
commit 2c32c65e upstream. On revisions of Cortex-A15 prior to r3p3, a CLREX instruction at PL1 may falsely trigger a watchpoint exception, leading to potential data aborts during exception return and/or livelock. This patch resolves the issue in the following ways: - Replacing our uses of CLREX with a dummy STREX sequence instead (as we did for v6 CPUs). - Removing the clrex code from v7_exit_coherency_flush and derivatives, since this only exists as a minor performance improvement when non-cached exclusives are in use (Linux doesn't use these). Benchmarking on a variety of ARM cores revealed no measurable performance difference with this change applied, so the change is performed unconditionally and no new Kconfig entry is added. Signed-off-by:
-
Mark Rutland authored
commit 85868313 upstream. The ARMv6 and ARMv7 early abort handlers clear the exclusive monitors upon entry to the kernel, but this is redundant: - We clear the monitors on every exception return since commit 200b812d ("Clear the exclusive monitor when returning from an exception"), so this is not necessary to ensure the monitors are cleared before returning from a fault handler. - Any dummy STREX will target a temporary scratch area in memory, and may succeed or fail without corrupting useful data. Its status value will not be used. - Any other STREX in the kernel must be preceded by an LDREX, which will initialise the monitors consistently and will not depend on the earlier state of the monitors. Therefore we have no reason to care about the initial state of the exclusive monitors when a data abort is taken, and clearing the monitors prior to exception return (as we already do) is sufficient. This patch removes the redundant clearing of the exclusive monitors from the early abort handlers. Signed-off-by:
-
Andy Shevchenko authored
commit c9d5d6fe upstream. The commit 04f421e7 "spi: dw: use managed resources" changes drivers to use managed functions, but seems wasn't properly tested in PCI case. The regs field of struct dw_spi left uninitialized. Thus, kernel crashes when tries to access to the SPI controller registers. This patch fixes the issue. Fixes: 04f421e7 (spi: dw: use managed resources) Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by:
Mark Brown <broonie@linaro.org> Signed-off-by:
-
Andy Shevchenko authored
commit 08a707b8 upstream. The obvious fix after the commit d9c73bb8 "spi: dw: add support for gpio controlled chip select". This patch fixes the issue by using locally defined temporary variable. Fixes: d9c73bb8 (spi: dw: add support for gpio controlled chip select) Signed-off-by:
-
Jorge A. Ventura authored
commit 3d0763c0 upstream. The spi hangs waiting the completion of omap2_mcspi_rx_callback. Signed-off-by:
Jorge A. Ventura <jorge.araujo.ventura@gmail.com> Signed-off-by:
-
Weston Andros Adamson authored
commit 78270e8f upstream. Commit 6094f838 "nfs: allow coalescing of subpage requests" got rid of the requirement that requests cover whole pages, but it made some incorrect assumptions. It turns out that callers of this interface can map adjacent requests (by file position as seen by req_offset + req->wb_bytes) to different pages, even when they could share a page. An example is the direct I/O interface - iov_iter_get_pages_alloc may return one segment with a partial page filled and the next segment (which is adjacent in the file position) starts with a new page. Reported-by:
Toralf Förster <toralf.foerster@gmx.de> Signed-off-by:
Weston Andros Adamson <dros@primarydata.com> Signed-off-by:
Trond Myklebust <trond.myklebust@primarydata.com> Signed-off-by:
-
Weston Andros Adamson authored
commit bba5c188 upstream. Adjacent requests that share the same page are allowed, but should only use one entry in the page vector. This avoids overruning the page vector - it is sized based on how many bytes there are, not by request count. This fixes issues that manifest as "Redzone overwritten" bugs (the vector overrun) and hangs waiting on page read / write, as it waits on the same page more than once. This also adds bounds checking to the page vector with a graceful failure (WARN_ON_ONCE and pgio error returned to application). Reported-by:
-
Weston Andros Adamson authored
commit 7c3af975 upstream. This handles the 'nonblock=false' case in nfs_lock_and_join_requests. If the group is already locked and blocking is allowed, drop the inode lock and wait for the group lock to be cleared before trying it all again. This should fix warnings found in peterz's tree (sched/wait branch), where might_sleep() checks are added to wait.[ch]. Reported-by:
Fengguang Wu <fengguang.wu@intel.com> Signed-off-by:
Peng Tao <tao.peng@primarydata.com> Signed-off-by:
-
Weston Andros Adamson authored
commit 94970014 upstream. This fixes handling of errors from nfs_page_group_lock in nfs_lock_and_join_requests. It now releases the inode lock and the reference to the head request. Reported-by:
-
Weston Andros Adamson authored
commit bfd484a5 upstream. __nfs_pageio_add_request was calling nfs_page_group_lock nonblocking, but this can return -EAGAIN which would end up passing -EIO to the application. There is no reason not to block in this path, so change the two calls to do so. Also, there is no need to check the return value of nfs_page_group_lock when nonblock=false, so remove the error handling code. Signed-off-by:
-
Weston Andros Adamson authored
commit bc8a309e upstream. nfs_page_group_lock was calling wait_on_bit_lock even when told not to block. Fix by first trying test_and_set_bit, followed by wait_on_bit_lock if and only if blocking is allowed. Return -EAGAIN if nonblocking and the test_and_set of the bit was already locked. Signed-off-by:
-
Weston Andros Adamson authored
commit fd2f3a06 upstream. Flip the meaning of the second argument from 'wait' to 'nonblock' to match related functions. Update all five calls to reflect this change. Signed-off-by:
-
Weston Andros Adamson authored
commit 411a99ad upstream. Signed-off-by:
-
Weston Andros Adamson authored
commit e6cf82d1 upstream. This is useful when lsegs need to be released while holding locks. Signed-off-by:
-
Weston Andros Adamson authored
commit e7029206 upstream. Return errors from wait_on_bit_lock from nfs_page_group_lock. Add a bool argument @wait to nfs_page_group_lock. If true, loop over wait_on_bit_lock until it returns cleanly. If false, return the error from wait_on_bit_lock. Signed-off-by:
-
Weston Andros Adamson authored
commit 4714fb51 upstream. The refcounting on nfs_pgio_header was related to there being (possibly) more than one nfs_pgio_data. Now that nfs_pgio_data has been merged into nfs_pgio_header, there is no reason to do this ref counting. Just call the completion callback on nfs_pgio_release/nfs_pgio_error. Signed-off-by:
-
Weston Andros Adamson authored
commit d45f60c6 upstream. struct nfs_pgio_data only exists as a member of nfs_pgio_header, but is passed around everywhere, because there used to be multiple _data structs per _header. Many of these functions then use the _data to find a pointer to the _header. This patch cleans this up by merging the nfs_pgio_data structure into nfs_pgio_header and passing nfs_pgio_header around instead. Reviewed-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
-
Weston Andros Adamson authored
commit 823b0c9d upstream. Rename "verf" to "writeverf" and "pages" to "page_array" to prepare for merge of nfs_pgio_data and nfs_pgio_header. Reviewed-by:
-
Weston Andros Adamson authored
commit 1e7f3a48 upstream. nfs_rw_header was used to allocate an nfs_pgio_header along with an nfs_pgio_data, because a _header would need at least one _data. Now there is only ever one nfs_pgio_data for each nfs_pgio_header -- move it to nfs_pgio_header and get rid of nfs_rw_header. Reviewed-by:
-
J. Bruce Fields authored
commit 15b23ef5 upstream. The calculation of page_ptr here is wrong in the case the read doesn't start at an offset that is a multiple of a page. The result is that nfs4svc_encode_compoundres sets rq_next_page to a value one too small, and then the loop in svc_free_res_pages may incorrectly fail to clear a page pointer in rq_respages[]. Pages left in rq_respages[] are available for the next rpc request to use, so xdr data may be written to that page, which may hold data still waiting to be transmitted to the client or data in the page cache. The observed result was silent data corruption seen on an NFSv4 client. We tag this as "fixing" 05638dc7 because that commit exposed this bug, though the incorrect calculation predates it. Particular thanks to Andrea Arcangeli and David Gilbert for analysis and testing. Fixes: 05638dc7 "nfsd4: simplify server xdr->next_page use" Reported-by:
Andrea Arcangeli <aarcange@redhat.com> Tested-by:
"Dr. David Alan Gilbert" <dgilbert@redhat.com> Signed-off-by:
J. Bruce Fields <bfields@redhat.com> Signed-off-by:
-
Trond Myklebust authored
commit cd9288ff upstream. James Drew reports another bug whereby the NFS client is now sending an OPEN_DOWNGRADE in a situation where it should really have sent a CLOSE: the client is opening the file for O_RDWR, but then trying to do a downgrade to O_RDONLY, which is not allowed by the NFSv4 spec. Reported-by:
James Drews <drews@engr.wisc.edu> Link: http://lkml.kernel.org/r/541AD7E5.8020409@engr.wisc.edu Fixes: aee7af35 (NFSv4: Fix problems with close in the presence...) Signed-off-by:
-
Steve Dickson authored
commit 080af20c upstream. There is a race between nfs4_state_manager() and nfs_server_remove_lists() that happens during a nfsv3 mount. The v3 mount notices there is already a supper block so nfs_server_remove_lists() called which uses the nfs_client_lock spin lock to synchronize access to the client list. At the same time nfs4_state_manager() is running through the client list looking for work to do, using the same lock. When nfs4_state_manager() wins the race to the list, a v3 client pointer is found and not ignored properly which causes the panic. Moving some protocol checks before the state checking avoids the panic. Signed-off-by:
Steve Dickson <steved@redhat.com> Signed-off-by:
-
Li Zefan authored
commit aa32362f upstream. When cgroup_kn_lock_live() is called through some kernfs operation and another thread is calling cgroup_rmdir(), we'll trigger the warning in cgroup_get(). ------------[ cut here ]------------ WARNING: CPU: 1 PID: 1228 at kernel/cgroup.c:1034 cgroup_get+0x89/0xa0() ... Call Trace: [<c16ee73d>] dump_stack+0x41/0x52 [<c10468ef>] warn_slowpath_common+0x7f/0xa0 [<c104692d>] warn_slowpath_null+0x1d/0x20 [<c10bb999>] cgroup_get+0x89/0xa0 [<c10bbe58>] cgroup_kn_lock_live+0x28/0x70 [<c10be3c1>] __cgroup_procs_write.isra.26+0x51/0x230 [<c10be5b2>] cgroup_tasks_write+0x12/0x20 [<c10bb7b0>] cgroup_file_write+0x40/0x130 [<c11aee71>] kernfs_fop_write+0xd1/0x160 [<c1148e58>] vfs_write+0x98/0x1e0 [<c114934d>] SyS_write+0x4d/0xa0 [<c16f656b>] sysenter_do_call+0x12/0x12 ---[ end trace 6f2e0c38c2108a74 ]--- Fix this by calling css_tryget() instead of cgroup_get(). v2: - move cgroup_tryget() right below cgroup_get() definition. (Tejun) Reported-by:
Zefan Li <lizefan@huawei.com> Signed-off-by:
Tejun Heo <tj@kernel.org> Signed-off-by:
-
J. Bruce Fields authored
commit aee37764 upstream. Commit 3b299709 "nfsd4: enforce rd_dircount" totally misunderstood rd_dircount; it refers to total non-attribute bytes returned, not number of directory entries returned. Bring the code into agreement with RFC 3530 section 14.2.24. Fixes: 3b299709 "nfsd4: enforce rd_dircount" Signed-off-by:
-
Olav Haugan authored
commit 1fc870c7 upstream. Stage-1 context banks do not have the SMMU_CBn_TCR[SL0] field since it is only applicable to stage-2 context banks. This patch ensures that we don't set the reserved TCR bits for stage-1 translations. Signed-off-by:
Olav Haugan <ohaugan@codeaurora.org> Signed-off-by:
-
Varun Sethi authored
commit 5a9137a6 upstream. iommu_group_get_for_dev determines the iommu group for the PCI device and adds the device to the group. In the PAMU driver we were again adding the device to the same group without checking if the device already had an iommu group. This resulted in the following warning. sysfs: cannot create duplicate filename '/devices/ffe200000.pcie/pci0000:00/0000:00:00.0/iommu_group' ------------[ cut here ]------------ WARNING: at fs/sysfs/dir.c:31 Modules linked in: CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.17.0-rc3-00002-g7505ceaf-dirty #126 task: c0000001fe0a0000 ti: c0000001fe044000 task.ti: c0000001fe044000 NIP: c00000000018879c LR: c000000000188798 CTR: c00000000001ea50 REGS: c0000001fe047040 TRAP: 0700 Not tainted (3.17.0-rc3-00002-g7505ceaf-dirty) MSR: 0000000080029000 <CE,EE,ME> CR: 24ad8e22 XER: 20000000 SOFTE: 1 GPR00: c000000000188798 c0000001fe0472c0 c0000000009a52e0 0000000000000065 GPR04: 0000000000000001 0000000000000000 3a30303a00000000 0000000027000000 GPR08: 2f696f6d00000000 c0000000008d3830 c0000000009b3938 c0000000009bb3d0 GPR12: 0000000028ad8e24 c00000000fff4000 c00000000000205c 0000000000000000 GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 GPR20: 0000000000000000 0000000000000000 0000000000000000 c0000000008a4c70 GPR24: c0000000007e9010 c0000001fe0140a8 ffffffffffffffef 0000000000000001 GPR28: c0000001fe22ebb8 c0000000007e9010 c00000000090bf10 c0000001fe220000 NIP [c00000000018879c] .sysfs_warn_dup+0x74/0xa4 LR [c000000000188798] .sysfs_warn_dup+0x70/0xa4 Call Trace: [c0000001fe0472c0] [c000000000188798] .sysfs_warn_dup+0x70/0xa4 (unreliable) [c0000001fe047350] [c000000000188d34] .sysfs_do_create_link_sd.clone.2+0x168/0x174 [c0000001fe047400] [c0000000004b3cf8] .iommu_group_add_device+0x78/0x244 [c0000001fe0474b0] [c0000000004b6964] .fsl_pamu_add_device+0x88/0x1a8 [c0000001fe047570] [c0000000004b3960] .iommu_bus_notifier+0xdc/0x15c [c0000001fe047600] [c000000000059848] .notifier_call_chain+0x8c/0xe8 [c0000001fe0476a0] [c000000000059d04] .__blocking_notifier_call_chain+0x58/0x84 [c0000001fe047750] [c00000000036619c] .device_add+0x464/0x5c8 [c0000001fe047820] [c000000000300ebc] .pci_device_add+0x14c/0x17c [c0000001fe0478c0] [c000000000300fbc] .pci_scan_single_device+0xd0/0xf4 [c0000001fe047970] [c00000000030104c] .pci_scan_slot+0x6c/0x18c [c0000001fe047a10] [c00000000030226c] .pci_scan_child_bus+0x40/0x114 [c0000001fe047ac0] [c000000000021974] .pcibios_scan_phb+0x240/0x2c8 [c0000001fe047b70] [c00000000085a970] .pcibios_init+0x64/0xc8 [c0000001fe047c00] [c000000000001884] .do_one_initcall+0xbc/0x224 [c0000001fe047d00] [c000000000852d50] .kernel_init_freeable+0x14c/0x21c [c0000001fe047db0] [c000000000002078] .kernel_init+0x1c/0xfa4 [c0000001fe047e30] [c000000000000884] .ret_from_kernel_thread+0x58/0xd4 Instruction dump: 7c7f1b79 4182001c 7fe4fb78 7f83e378 38a01000 4bffc905 60000000 7c641b78 e87e8008 7fa5eb78 48482ff5 60000000 <0fe00000> 7fe3fb78 4bf7bd39 60000000 Signed-off-by:
Varun Sethi <Varun.Sethi@freescale.com> Signed-off-by:
Joerg Roedel <jroedel@suse.de> Signed-off-by:
-
Joerg Roedel authored
commit c0df975f upstream. Checking adev == NULL is not sufficient as acpi_bus_get_device() might not touch the value of this parameter in an error case, so check the return value directly. Fixes: ed40356b Cc: David Woodhouse <dwmw2@infradead.org> Signed-off-by:
Alex Williamson <alex.williamson@redhat.com> Signed-off-by:
-
Bjørn Mork authored
commit 508b3c67 upstream. This reverts commit 232de514 ("ACPI / battery: fix wrong value of capacity_now reported when fully charged") There is nothing wrong or unexpected about 'capacity_now' increasing above the last 'full_charge_capacity' value. Different charging cycles will cause 'full_charge_capacity' to vary, both up and down. Good battery firmwares will update 'full_charge_capacity' when the current charging cycle is complete, increasing it if necessary. It might even go above 'design_capacity' on a fresh and healthy battery. Capping 'capacity_now' to 'full_charge_capacity' is plain wrong, and printing a warning if this doesn't happen to match the 'design_capacity' is both annoying and terribly wrong. This results in bogus warnings on perfectly working systems/firmwares: [Firmware Bug]: battery: reported current charge level (39800) is higher than reported maximum charge level (39800). and wrong values being reported for 'capacity_now' and 'full_charge_capacity' after the warning has been triggered. Fixes: 232de514 ("ACPI / battery: fix wrong value of capacity_now reported when fully charged") Signed-off-by:
Bjørn Mork <bjorn@mork.no> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by:
-
