- 13 Sep, 2015 38 commits
-
-
Guenter Roeck authored
commit 8ef9724b upstream. When inserting a new register into a block, the present bit map size is increased using krealloc. krealloc does not clear the additionally allocated memory, leaving it filled with random values. Result is that some registers are considered cached even though this is not the case. Fix the problem by clearing the additionally allocated memory. Also, if the bitmap size does not increase, do not reallocate the bitmap at all to reduce overhead. Fixes: 3f4ff561 ("regmap: rbtree: Make cache_present bitmap per node") Signed-off-by:
Guenter Roeck <linux@roeck-us.net> Signed-off-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Linus Torvalds authored
commit ed596cde upstream. This reverts commits 9a036b93 ("x86/signal/64: Remove 'fs' and 'gs' from sigcontext") and c6f20629 ("x86/signal/64: Fix SS handling for signals delivered to 64-bit programs"). They were cleanups, but they break dosemu by changing the signal return behavior (and removing 'fs' and 'gs' from the sigcontext struct - while not actually changing any behavior - causes build problems). Reported-and-tested-by:
Stas Sergeev <stsp@list.ru> Acked-by:
Andy Lutomirski <luto@amacapital.net> Cc: Ingo Molnar <mingo@kernel.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Charles Keepax authored
commit 72e43164 upstream. The PM runtime core by default assumes a chip is suspended when runtime PM is enabled. Currently the arizona driver enables runtime PM when the chip is fully active and then disables the DCVDD regulator at the end of arizona_dev_init. This however has several problems, firstly the if we reach the end of arizona_dev_init, we did not properly follow all the proceedures for shutting down the chip, and most notably we never marked the chip as cache only so any writes occurring between then and the next PM runtime resume will be lost. Secondly, if we are already resumed when we reach the end of dev_init, then at best we get unbalanced regulator enable/disables at work we lose DCVDD whilst we need it. Additionally, since the commit 4f0216409f7c ("mfd: arizona: Add better support for system suspend"), the PM runtime operations may disable/enable the IRQ, so the IRQs must now be enabled before we call any PM operations. This patch adds a call to pm_runtime_set_active to inform the PM core that the device is starting up active and moves the PM enabling to around the IRQ initialisation to avoid any PM callbacks happening until the IRQs are initialised. Signed-off-by:
Charles Keepax <ckeepax@opensource.wolfsonmicro.com> Signed-off-by:
Lee Jones <lee.jones@linaro.org> Signed-off-by:
-
Russell King authored
commit bac51ad9 upstream. We must invalidate the L1 cache before enabling coherency, otherwise secondary CPUs can inject invalid cache lines into the coherent CPU cluster, which could then be migrated to other CPUs. This fixes a recent regression with SoCFPGA randomly failing to boot. Fixes: 02b4e275 ("ARM: v7 setup function should invalidate L1 cache") Signed-off-by:
Russell King <rmk+kernel@arm.linux.org.uk> Cc: Alexander Kochetkov <al.kochet@gmail.com> Signed-off-by:
-
Russell King authored
commit 02b4e275 upstream. All ARMv5 and older CPUs invalidate their caches in the early assembly setup function, prior to enabling the MMU. This is because the L1 cache should not contain any data relevant to the execution of the kernel at this point; all data should have been flushed out to memory. This requirement should also be true for ARMv6 and ARMv7 CPUs - indeed, these typically do not search their caches when caching is disabled (as it needs to be when the MMU is disabled) so this change should be safe. ARMv7 allows there to be CPUs which search their caches while caching is disabled, and it's permitted that the cache is uninitialised at boot; for these, the architecture reference manual requires that an implementation specific code sequence is used immediately after reset to ensure that the cache is placed into a sane state. Such functionality is definitely outside the remit of the Linux kernel, and must be done by the SoC's firmware before _any_ CPU gets to the Linux kernel. Changing the data cache clean+invalidate to a mere invalidate allows us to get rid of a lot of platform specific hacks around this issue for their secondary CPU bringup paths - some of which were buggy. Reviewed-by:
Florian Fainelli <f.fainelli@gmail.com> Tested-by:
Heiko Stuebner <heiko@sntech.de> Tested-by:
Dinh Nguyen <dinguyen@opensource.altera.com> Acked-by:
Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com> Tested-by:
Shawn Guo <shawn.guo@linaro.org> Tested-by:
Thierry Reding <treding@nvidia.com> Acked-by:
Geert Uytterhoeven <geert+renesas@glider.be> Tested-by:
Michal Simek <michal.simek@xilinx.com> Tested-by:
Wei Xu <xuwei5@hisilicon.com> Signed-off-by:
-
Nathan Lynch authored
commit d2b30cd4 upstream. When using a toolchain with gold as the default linker, the VDSO build fails: VDSO arch/arm/vdso/vdso.so.raw HOSTCC arch/arm/vdso/vdsomunge MUNGE arch/arm/vdso/vdso.so.dbg OBJCOPY arch/arm/vdso/vdso.so BFD: arch/arm/vdso/vdso.so: Not enough room for program headers, try linking with -N For whatever reason, ld.gold is omitting an exidx program header that ld.bfd emits, and even when I work around that, I don't get a working VDSO. For now, instead of supporting gold (which will fail to link the kernel anyway since it does not implement --pic-veneer), direct the compiler to use the traditional bfd linker. This is accomplished by using -fuse-ld, which is implemented in GCC 4.8 and later. Note: one limitation of this is that if the toolchain is configured to use gold by default, and the bfd linker is not in $PATH, the VDSO build will fail: VDSO arch/arm/vdso/vdso.so.raw collect2: fatal error: cannot find 'ld' This will happen if CROSS_COMPILE begins with a path such as /opt/bin/arm-linux-gnu- but /opt/bin is not in $PATH. This is considered an acceptable corner-case limitation and is easily worked around. Additonal note: we use cc-option instead of cc-ldoption so that -fuse-ld=bfd is placed in the command line if the compiler recognizes the option. Using cc-ldoption results in an attempt to link, which fails in the situation just described, causing -fuse-ld=bfd to be omitted and gold to be used for the VDSO link, which is what we're trying to prevent. Reported-by:
Stefan Agner <stefan@agner.ch> Signed-off-by:
Nathan Lynch <nathan_lynch@mentor.com> Signed-off-by:
-
Nathan Lynch authored
commit d33ce23b upstream. Currently the VDSO's link options are kind of a mess spread between ccflags-y and cmd_vdsold. Collect linker directives into one variable, VDSO_LDFLAGS, and use that in cmd_vdsold. Signed-off-by:
-
Kishon Vijay Abraham I authored
commit 70caac3f upstream. commit <ed8509ed> ("ARM: dts: omap5: add minimal l4 bus layout with control module support") moved pbias_regulator dt node from being a child node of ocp to be the child node of omap5_padconf_global. After this device for pbias_regulator is not created. Fix it by adding "simple-bus" compatible property to omap5_padconf_global dt node. Fixes: ed8509ed ("ARM: dts: omap5: add minimal l4 bus layout with control module support") Signed-off-by:
Kishon Vijay Abraham I <kishon@ti.com> Signed-off-by:
Tony Lindgren <tony@atomide.com> Signed-off-by:
-
Kishon Vijay Abraham I authored
commit 89a898df upstream. commit <7415b0b4> ("ARM: dts: omap4: add minimal l4 bus layout with control module support") moved pbias_regulator dt node from being a child node of ocp to be the child node of omap4_padconf_global. After this device for pbias_regulator is not created. Fix it by adding "simple-bus" compatible property to omap4_padconf_global dt node. Fixes: 7415b0b4 ("ARM: dts: omap4: add minimal l4 bus layout with control module support") Signed-off-by:
-
Kishon Vijay Abraham I authored
commit cd455673 upstream. commit <d919501f> ("ARM: dts: dra7: add minimal l4 bus layout with control module support") moved pbias_regulator dt node from being a child node of ocp to be the child node of scm_conf. After this device for pbias_regulator is not created. Fix it by adding "simple-bus" compatible property to scm_conf dt node. Fixes: d919501f ("ARM: dts: dra7: add minimal l4 bus layout with control module support") Suggested-by:
Tero Kristo <t-kristo@ti.com> Signed-off-by:
Grygorii Strashko <grygorii.strashko@ti.com> Signed-off-by:
-
Kishon Vijay Abraham I authored
commit 4317c8c9 upstream. commit <72b10ac0> ("ARM: dts: omap24xx: add minimal l4 bus layout with control module support") moved pbias_regulator dt node from being a child node of ocp to be the child node of scm_conf. After this device for pbias_regulator is not created. Fix it by adding "simple-bus" compatible property to scm_conf dt node. Fixes: 72b10ac0 ("ARM: dts: omap24xx: add minimal l4 bus layout with control module support") Signed-off-by:
-
Lucas Stach authored
commit 1a9fa190 upstream. The PCIe interrupts are also routed through the GPC. This has been missed from the conversion to stacked IRQ domains as the PCIe controller uses an explicit interrupt map and thus doesn't inherit the SoC global interrupt parent. Signed-off-by:
Lucas Stach <l.stach@pengutronix.de> Signed-off-by:
Shawn Guo <shawnguo@kernel.org> Signed-off-by:
-
Bart Van Assche authored
commit 8f2777f5 upstream. Since fc_fcp_cleanup_cmd() can sleep this function must not be called while holding a spinlock. This patch avoids that fc_fcp_cleanup_each_cmd() triggers the following bug: BUG: scheduling while atomic: sg_reset/1512/0x00000202 1 lock held by sg_reset/1512: #0: (&(&fsp->scsi_pkt_lock)->rlock){+.-...}, at: [<ffffffffc0225cd5>] fc_fcp_cleanup_each_cmd.isra.21+0xa5/0x150 [libfc] Preemption disabled at:[<ffffffffc0225cd5>] fc_fcp_cleanup_each_cmd.isra.21+0xa5/0x150 [libfc] Call Trace: [<ffffffff816c612c>] dump_stack+0x4f/0x7b [<ffffffff810828bc>] __schedule_bug+0x6c/0xd0 [<ffffffff816c87aa>] __schedule+0x71a/0xa10 [<ffffffff816c8ad2>] schedule+0x32/0x80 [<ffffffffc0217eac>] fc_seq_set_resp+0xac/0x100 [libfc] [<ffffffffc0218b11>] fc_exch_done+0x41/0x60 [libfc] [<ffffffffc0225cff>] fc_fcp_cleanup_each_cmd.isra.21+0xcf/0x150 [libfc] [<ffffffffc0225f43>] fc_eh_device_reset+0x1c3/0x270 [libfc] [<ffffffff814a2cc9>] scsi_try_bus_device_reset+0x29/0x60 [<ffffffff814a3908>] scsi_ioctl_reset+0x258/0x2d0 [<ffffffff814a2650>] scsi_ioctl+0x150/0x440 [<ffffffff814b3a9d>] sd_ioctl+0xad/0x120 [<ffffffff8132f266>] blkdev_ioctl+0x1b6/0x810 [<ffffffff811da608>] block_ioctl+0x38/0x40 [<ffffffff811b4e08>] do_vfs_ioctl+0x2f8/0x530 [<ffffffff811b50c1>] SyS_ioctl+0x81/0xa0 [<ffffffff816cf8b2>] system_call_fastpath+0x16/0x7a Signed-off-by:
Bart Van Assche <bart.vanassche@sandisk.com> Signed-off-by:
Vasu Dev <vasu.dev@intel.com> Signed-off-by:
James Bottomley <JBottomley@Odin.com> Signed-off-by:
-
Bart Van Assche authored
commit f6979ade upstream. Due to patch "libfc: Do not invoke the response handler after fc_exch_done()" (commit ID 7030fd62) the lport_recv() call in fc_exch_recv_req() is passed a dangling pointer. Avoid this by moving the fc_frame_free() call from fc_invoke_resp() to its callers. This patch fixes the following crash: general protection fault: 0000 [#3] PREEMPT SMP RIP: fc_lport_recv_req+0x72/0x280 [libfc] Call Trace: fc_exch_recv+0x642/0xde0 [libfc] fcoe_percpu_receive_thread+0x46a/0x5ed [fcoe] kthread+0x10a/0x120 ret_from_fork+0x42/0x70 Signed-off-by:
-
Thomas Hellstrom authored
commit 3e04e2fe upstream. This addresses two issues that cause problems with viewperf maya-03 in situation with memory pressure. The first issue causes attempts to unreserve buffers if batched reservation fails due to, for example, a signal pending. While previously the ttm_eu api was resistant against this type of error, it is no longer and the lockdep code will complain about attempting to unreserve buffers that are not reserved. The issue is resolved by avoid calling ttm_eu_backoff_reservation in the buffer reserve error path. The second issue is that the binding_mutex may be held when user-space fence objects are created and hence during memory reclaims. This may cause recursive attempts to grab the binding mutex. The issue is resolved by not holding the binding mutex across fence creation and submission. Signed-off-by:
Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by:
Sinclair Yeh <syeh@vmware.com> Signed-off-by:
Dave Airlie <airlied@redhat.com> Signed-off-by:
-
Alex Deucher authored
commit e037239e upstream. Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
-
Dan Carpenter authored
commit 4a8e70f5 upstream. The limit should be ARRAY_SIZE(params) (5 elements) here instead of sizeof(params) (20 bytes). Fixes: 08177f40 ('HID: uclogic: merge hid-huion driver in hid-uclogic') Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by:
Nikolai Kondrashov <spbnick@gmail.com> Signed-off-by:
Jiri Kosina <jkosina@suse.com> Signed-off-by:
-
Krzysztof Kozlowski authored
commit 0621809e upstream. During unbinding the driver was dereferencing a pointer to memory already freed by power_supply_unregister(). Driver was freeing its internal description of battery through pointers stored in power_supply structure. However, because the core owns the power supply instance, after calling power_supply_unregister() this memory is freed and the driver cannot access these members. Fix this by storing the pointer to internal description of battery in a local variable before calling power_supply_unregister(), so the pointer remains valid. Signed-off-by:
Krzysztof Kozlowski <k.kozlowski@samsung.com> Reported-by:
H.J. Lu <hjl.tools@gmail.com> Fixes: 297d716f ("power_supply: Change ownership from driver to core") Reviewed-by:
Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by:
-
Michael Walle authored
commit 5c16179b upstream. The commit de3910eb ("edac: change the mem allocation scheme to make Documentation/kobject.txt happy") changed the memory allocation for the csrows member. But ppc4xx_edac was forgotten in the patch. Fix it. Signed-off-by:
Michael Walle <michael@walle.cc> Cc: linux-edac <linux-edac@vger.kernel.org> Cc: Mauro Carvalho Chehab <mchehab@osg.samsung.com> Link: http://lkml.kernel.org/r/1437469253-8611-1-git-send-email-michael@walle.ccSigned-off-by:
Borislav Petkov <bp@suse.de> Signed-off-by:
-
Richard Weinberger authored
commit c0ddc8c7 upstream. In kbuild it is allowed to define objects in files named "Makefile" and "Kbuild". Currently localmodconfig reads objects only from "Makefile"s and misses modules like nouveau. Link: http://lkml.kernel.org/r/1437948415-16290-1-git-send-email-richard@nod.atReported-and-tested-by:
Leonidas Spyropoulos <artafinde@gmail.com> Signed-off-by:
Richard Weinberger <richard@nod.at> Signed-off-by:
Steven Rostedt <rostedt@goodmis.org> Signed-off-by:
-
Joe Thornber authored
commit 7f518ad0 upstream. The device details and mapping trees were just being decremented before. Now btree_del() is called to do a deep delete. Signed-off-by:
Joe Thornber <ejt@redhat.com> Signed-off-by:
Mike Snitzer <snitzer@redhat.com> Signed-off-by:
-
Julien Grall authored
commit c22fe519 upstream. The commit ccc9d90a "xenbus_client: Extend interface to support multi-page ring" removes the call to free_xenballooned_pages() in xenbus_unmap_ring_vfree_hvm(), leaking a page for every shared ring. Only with backends running in HVM domains were affected. Signed-off-by:
Julien Grall <julien.grall@citrix.com> Reviewed-by:
Boris Ostrovsky <boris.ostrovsky@oracle.com> Reviewed-by:
Wei Liu <wei.liu2@citrix.com> Signed-off-by:
David Vrabel <david.vrabel@citrix.com> Signed-off-by:
-
Jason A. Donenfeld authored
commit fc5fee86 upstream. It turns out that a PV domU also requires the "Xen PV" APIC driver. Otherwise, the flat driver is used and we get stuck in busy loops that never exit, such as in this stack trace: (gdb) target remote localhost:9999 Remote debugging using localhost:9999 __xapic_wait_icr_idle () at ./arch/x86/include/asm/ipi.h:56 56 while (native_apic_mem_read(APIC_ICR) & APIC_ICR_BUSY) (gdb) bt #0 __xapic_wait_icr_idle () at ./arch/x86/include/asm/ipi.h:56 #1 __default_send_IPI_shortcut (shortcut=<optimized out>, dest=<optimized out>, vector=<optimized out>) at ./arch/x86/include/asm/ipi.h:75 #2 apic_send_IPI_self (vector=246) at arch/x86/kernel/apic/probe_64.c:54 #3 0xffffffff81011336 in arch_irq_work_raise () at arch/x86/kernel/irq_work.c:47 #4 0xffffffff8114990c in irq_work_queue (work=0xffff88000fc0e400) at kernel/irq_work.c:100 #5 0xffffffff8110c29d in wake_up_klogd () at kernel/printk/printk.c:2633 #6 0xffffffff8110ca60 in vprintk_emit (facility=0, level=<optimized out>, dict=0x0 <irq_stack_union>, dictlen=<optimized out>, fmt=<optimized out>, args=<optimized out>) at kernel/printk/printk.c:1778 #7 0xffffffff816010c8 in printk (fmt=<optimized out>) at kernel/printk/printk.c:1868 #8 0xffffffffc00013ea in ?? () #9 0x0000000000000000 in ?? () Mailing-list-thread: https://lkml.org/lkml/2015/8/4/755Signed-off-by:
Jason A. Donenfeld <Jason@zx2c4.com> Signed-off-by:
-
Luis Felipe Dominguez Vega authored
commit 7c629401 upstream. In commit 33511b15 ("rtlwifi: add support to send beacon frame"), the mechanism for sending beacons was established. That patch works correctly for rtl8192cu, but there is a possibility of getting the following warnings in the PCI drivers: WARNING: CPU: 1 PID: 2439 at net/mac80211/driver-ops.h:12 ieee80211_bss_info_change_notify+0x179/0x1d0 [mac80211]() wlp5s0: Failed check-sdata-in-driver check, flags: 0x0 The warning is followed by a NULL pointer dereference as follows: BUG: unable to handle kernel NULL pointer dereference at 0000000000000006 IP: [<ffffffffc073998e>] rtl_get_tcb_desc+0x5e/0x760 [rtlwifi] This problem was reported at http://thread.gmane.org/gmane.linux.kernel.wireless.general/138645, but no solution was found at that time. The problem was also reported at https://bugzilla.kernel.org/show_bug.cgi?id=9744 and this solution was developed and tested there. The USB driver works with a NULL final argument in the adapter_tx() callback; however, the PCI drivers need a struct rtl_tcb_desc in that position. Fixes: 33511b15 ("rtlwifi: add support to send beacon frame.") Signed-off-by:
Luis Felipe Dominguez Vega <lfdominguez@nauta.cu> Signed-off-by:
Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by:
Kalle Valo <kvalo@codeaurora.org> Signed-off-by:
-
Larry Finger authored
commit 741e3b99 upstream. The driver code allows for the disabling of MSI interrupts; however the module_parm line was missed and the option fails to show with modinfo. Signed-off-by:
-
Emmanuel Grumbach authored
commit c9fdec9f upstream. When the card is not owned by the PCIe bus, we need to acquire ownership first. This flow is implemented in iwl_pcie_prepare_card_hw. Because of a hardware bug, we need to disable link power management before we can request ownership otherwise the other user of the device won't get notified that we are requesting the device which will prevent us from acquire ownership. Same holds for the down flow where we need to make sure that any other potential user is notified that the driver is going down. Signed-off-by:
Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by:
-
Peter Zijlstra authored
commit c7999c6f upstream. I ran the perf fuzzer, which triggered some WARN()s which are due to trying to stop/restart an event on the wrong CPU. Use the normal IPI pattern to ensure we run the code on the correct CPU. Signed-off-by:
Peter Zijlstra (Intel) <peterz@infradead.org> Cc: Vince Weaver <vincent.weaver@maine.edu> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Fixes: bad7192b ("perf: Fix PERF_EVENT_IOC_PERIOD to force-reset the period") Signed-off-by:
Ingo Molnar <mingo@kernel.org> Signed-off-by:
-
Ben Hutchings authored
commit ee9397a6 upstream. If rb->aux_refcount is decremented to zero before rb->refcount, __rb_free_aux() may be called twice resulting in a double free of rb->aux_pages. Fix this by adding a check to __rb_free_aux(). Signed-off-by:
Ben Hutchings <ben@decadent.org.uk> Signed-off-by:
-
Peter Zijlstra authored
commit 00a2916f upstream. A recent fix to the shadow timestamp inadvertly broke the running time accounting. We must not update the running timestamp if we fail to schedule the event, the event will not have ran. This can (and did) result in negative total runtime because the stopped timestamp was before the running timestamp (we 'started' but never stopped the event -- because it never really started we didn't have to stop it either). Reported-and-Tested-by:
Vince Weaver <vincent.weaver@maine.edu> Fixes: 72f669c0 ("perf: Update shadow timestamp before add event") Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
-
Peter Zijlstra authored
commit fed66e2c upstream. Vince reported that the fasync signal stuff doesn't work proper for inherited events. So fix that. Installing fasync allocates memory and sets filp->f_flags |= FASYNC, which upon the demise of the file descriptor ensures the allocation is freed and state is updated. Now for perf, we can have the events stick around for a while after the original FD is dead because of references from child events. So we cannot copy the fasync pointer around. We can however consistently use the parent's fasync, as that will be updated. Reported-and-Tested-by:
-
Mike Looijmans authored
commit 5d5cd85f upstream. Fixes commit eae79b4f ("rsi: fix memory leak in rsi_load_ta_instructions()") which stopped the driver from functioning. Firmware data has been allocated using vmalloc(), resulting in memory that cannot be used for DMA. Hence the firmware was first copied to a buffer allocated with kmalloc() in the original code. This patch reverts the commit and only calls "kfree()" to release the buffer after sending the data. This fixes the memory leak without breaking the driver. Add a comment to the kmemdup() calls to explain why this is done, and abort if memory allocation fails. Tested on a Topic Miami-Florida board which contains the rsi SDIO chip. Also added the same kfree() call to the USB glue driver. This was not tested on actual hardware though, as I only have the SDIO version. Fixes: eae79b4f ("rsi: fix memory leak in rsi_load_ta_instructions()") Signed-off-by:
Mike Looijmans <mike.looijmans@topic.nl> Signed-off-by:
-
Bob Liu authored
commit 53bc7dc0 upstream. The BUG_ON() in purge_persistent_gnt() will be triggered when previous purge work haven't finished. There is a work_pending() before this BUG_ON, but it doesn't account if the work is still currently running. Acked-by:
Roger Pau Monné <roger.pau@citrix.com> Signed-off-by:
Bob Liu <bob.liu@oracle.com> Signed-off-by:
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Signed-off-by:
-
Bob Liu authored
commit 7b076750 upstream. We should consider info->feature_persistent when adding indirect page to list info->indirect_pages, else the BUG_ON() in blkif_free() would be triggered. When we are using persistent grants the indirect_pages list should always be empty because blkfront has pre-allocated enough persistent pages to fill all requests on the ring. Acked-by:
-
Robert Jarzmik authored
commit b93028c9 upstream. Clocks 0 to 31 are on CKENA, and not CKENB. The clock register names were inadequately inverted. As a consequence, all clock operations were happening on CKENB, because almost all but 2 clocks are on CKENA. As the clocks were activated by the bootloader in the former tests, it escaped the testing that the wrong clock gate was manipulated. The error was revealed by changing the pxa3xx-nand driver to a module, where upon unloading, the wrong clock was disabled in CKENB. Fixes: 9bbb8a33 ("clk: pxa: add pxa3xx clock driver") Signed-off-by:
Robert Jarzmik <robert.jarzmik@free.fr> Signed-off-by:
Stephen Boyd <sboyd@codeaurora.org> Signed-off-by:
-
Wanpeng Li authored
commit 03613808 upstream. Hugetlbfs pages will get a refcount in get_any_page() or madvise_hwpoison() if soft offlining through madvise. The refcount which is held by the soft offline path should be released if we fail to isolate hugetlbfs pages. Fix it by reducing the refcount for both isolation success and failure. Signed-off-by:
Wanpeng Li <wanpeng.li@hotmail.com> Acked-by:
Naoya Horiguchi <n-horiguchi@ah.jp.nec.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
-
Wanpeng Li authored
commit 4f32be67 upstream. After trying to drain pages from pagevec/pageset, we try to get reference count of the page again, however, the reference count of the page is not reduced if the page is still not on LRU list. Fix it by adding the put_page() to drop the page reference which is from __get_any_page(). Signed-off-by:
-
Manfred Spraul authored
commit 3ed1f8a9 upstream. sem_lock() did not properly pair memory barriers: !spin_is_locked() and spin_unlock_wait() are both only control barriers. The code needs an acquire barrier, otherwise the cpu might perform read operations before the lock test. As no primitive exists inside <include/spinlock.h> and since it seems noone wants another primitive, the code creates a local primitive within ipc/sem.c. With regards to -stable: The change of sem_wait_array() is a bugfix, the change to sem_lock() is a nop (just a preprocessor redefinition to improve the readability). The bugfix is necessary for all kernels that use sem_wait_array() (i.e.: starting from 3.10). Signed-off-by:
Manfred Spraul <manfred@colorfullife.com> Reported-by:
Oleg Nesterov <oleg@redhat.com> Acked-by:
-
Herton R. Krzesinski authored
commit 602b8593 upstream. The current semaphore code allows a potential use after free: in exit_sem we may free the task's sem_undo_list while there is still another task looping through the same semaphore set and cleaning the sem_undo list at freeary function (the task called IPC_RMID for the same semaphore set). For example, with a test program [1] running which keeps forking a lot of processes (which then do a semop call with SEM_UNDO flag), and with the parent right after removing the semaphore set with IPC_RMID, and a kernel built with CONFIG_SLAB, CONFIG_SLAB_DEBUG and CONFIG_DEBUG_SPINLOCK, you can easily see something like the following in the kernel log: Slab corruption (Not tainted): kmalloc-64 start=ffff88003b45c1c0, len=64 000: 6b 6b 6b 6b 6b 6b 6b 6b 00 6b 6b 6b 6b 6b 6b 6b kkkkkkkk.kkkkkkk 010: ff ff ff ff 6b 6b 6b 6b ff ff ff ff ff ff ff ff ....kkkk........ Prev obj: start=ffff88003b45c180, len=64 000: 00 00 00 00 ad 4e ad de ff ff ff ff 5a 5a 5a 5a .....N......ZZZZ 010: ff ff ff ff ff ff ff ff c0 fb 01 37 00 88 ff ff ...........7.... Next obj: start=ffff88003b45c200, len=64 000: 00 00 00 00 ad 4e ad de ff ff ff ff 5a 5a 5a 5a .....N......ZZZZ 010: ff ff ff ff ff ff ff ff 68 29 a7 3c 00 88 ff ff ........h).<.... BUG: spinlock wrong CPU on CPU#2, test/18028 general protection fault: 0000 [#1] SMP Modules linked in: 8021q mrp garp stp llc nf_conntrack_ipv4 nf_defrag_ipv4 ip6t_REJECT nf_reject_ipv6 nf_conntrack_ipv6 nf_defrag_ipv6 xt_state nf_conntrack ip6table_filter ip6_tables binfmt_misc ppdev input_leds joydev parport_pc parport floppy serio_raw virtio_balloon virtio_rng virtio_console virtio_net iosf_mbi crct10dif_pclmul crc32_pclmul ghash_clmulni_intel pcspkr qxl ttm drm_kms_helper drm snd_hda_codec_generic i2c_piix4 snd_hda_intel snd_hda_codec snd_hda_core snd_hwdep snd_seq snd_seq_device snd_pcm snd_timer snd soundcore crc32c_intel virtio_pci virtio_ring virtio pata_acpi ata_generic [last unloaded: speedstep_lib] CPU: 2 PID: 18028 Comm: test Not tainted 4.2.0-rc5+ #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.8.1-20150318_183358- 04/01/2014 RIP: spin_dump+0x53/0xc0 Call Trace: spin_bug+0x30/0x40 do_raw_spin_unlock+0x71/0xa0 _raw_spin_unlock+0xe/0x10 freeary+0x82/0x2a0 ? _raw_spin_lock+0xe/0x10 semctl_down.clone.0+0xce/0x160 ? __do_page_fault+0x19a/0x430 ? __audit_syscall_entry+0xa8/0x100 SyS_semctl+0x236/0x2c0 ? syscall_trace_leave+0xde/0x130 entry_SYSCALL_64_fastpath+0x12/0x71 Code: 8b 80 88 03 00 00 48 8d 88 60 05 00 00 48 c7 c7 a0 2c a4 81 31 c0 65 8b 15 eb 40 f3 7e e8 08 31 68 00 4d 85 e4 44 8b 4b 08 74 5e <45> 8b 84 24 88 03 00 00 49 8d 8c 24 60 05 00 00 8b 53 04 48 89 RIP [<ffffffff810d6053>] spin_dump+0x53/0xc0 RSP <ffff88003750fd68> ---[ end trace 783ebb76612867a0 ]--- NMI watchdog: BUG: soft lockup - CPU#3 stuck for 22s! [test:18053] Modules linked in: 8021q mrp garp stp llc nf_conntrack_ipv4 nf_defrag_ipv4 ip6t_REJECT nf_reject_ipv6 nf_conntrack_ipv6 nf_defrag_ipv6 xt_state nf_conntrack ip6table_filter ip6_tables binfmt_misc ppdev input_leds joydev parport_pc parport floppy serio_raw virtio_balloon virtio_rng virtio_console virtio_net iosf_mbi crct10dif_pclmul crc32_pclmul ghash_clmulni_intel pcspkr qxl ttm drm_kms_helper drm snd_hda_codec_generic i2c_piix4 snd_hda_intel snd_hda_codec snd_hda_core snd_hwdep snd_seq snd_seq_device snd_pcm snd_timer snd soundcore crc32c_intel virtio_pci virtio_ring virtio pata_acpi ata_generic [last unloaded: speedstep_lib] CPU: 3 PID: 18053 Comm: test Tainted: G D 4.2.0-rc5+ #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.8.1-20150318_183358- 04/01/2014 RIP: native_read_tsc+0x0/0x20 Call Trace: ? delay_tsc+0x40/0x70 __delay+0xf/0x20 do_raw_spin_lock+0x96/0x140 _raw_spin_lock+0xe/0x10 sem_lock_and_putref+0x11/0x70 SYSC_semtimedop+0x7bf/0x960 ? handle_mm_fault+0xbf6/0x1880 ? dequeue_task_fair+0x79/0x4a0 ? __do_page_fault+0x19a/0x430 ? kfree_debugcheck+0x16/0x40 ? __do_page_fault+0x19a/0x430 ? __audit_syscall_entry+0xa8/0x100 ? do_audit_syscall_entry+0x66/0x70 ? syscall_trace_enter_phase1+0x139/0x160 SyS_semtimedop+0xe/0x10 SyS_semop+0x10/0x20 entry_SYSCALL_64_fastpath+0x12/0x71 Code: 47 10 83 e8 01 85 c0 89 47 10 75 08 65 48 89 3d 1f 74 ff 7e c9 c3 0f 1f 44 00 00 55 48 89 e5 e8 87 17 04 00 66 90 c9 c3 0f 1f 00 <55> 48 89 e5 0f 31 89 c1 48 89 d0 48 c1 e0 20 89 c9 48 09 c8 c9 Kernel panic - not syncing: softlockup: hung tasks I wasn't able to trigger any badness on a recent kernel without the proper config debugs enabled, however I have softlockup reports on some kernel versions, in the semaphore code, which are similar as above (the scenario is seen on some servers running IBM DB2 which uses semaphore syscalls). The patch here fixes the race against freeary, by acquiring or waiting on the sem_undo_list lock as necessary (exit_sem can race with freeary, while freeary sets un->semid to -1 and removes the same sem_undo from list_proc or when it removes the last sem_undo). After the patch I'm unable to reproduce the problem using the test case [1]. [1] Test case used below: #include <stdio.h> #include <sys/types.h> #include <sys/ipc.h> #include <sys/sem.h> #include <sys/wait.h> #include <stdlib.h> #include <time.h> #include <unistd.h> #include <errno.h> #define NSEM 1 #define NSET 5 int sid[NSET]; void thread() { struct sembuf op; int s; uid_t pid = getuid(); s = rand() % NSET; op.sem_num = pid % NSEM; op.sem_op = 1; op.sem_flg = SEM_UNDO; semop(sid[s], &op, 1); exit(EXIT_SUCCESS); } void create_set() { int i, j; pid_t p; union { int val; struct semid_ds *buf; unsigned short int *array; struct seminfo *__buf; } un; /* Create and initialize semaphore set */ for (i = 0; i < NSET; i++) { sid[i] = semget(IPC_PRIVATE , NSEM, 0644 | IPC_CREAT); if (sid[i] < 0) { perror("semget"); exit(EXIT_FAILURE); } } un.val = 0; for (i = 0; i < NSET; i++) { for (j = 0; j < NSEM; j++) { if (semctl(sid[i], j, SETVAL, un) < 0) perror("semctl"); } } /* Launch threads that operate on semaphore set */ for (i = 0; i < NSEM * NSET * NSET; i++) { p = fork(); if (p < 0) perror("fork"); if (p == 0) thread(); } /* Free semaphore set */ for (i = 0; i < NSET; i++) { if (semctl(sid[i], NSEM, IPC_RMID)) perror("IPC_RMID"); } /* Wait for forked processes to exit */ while (wait(NULL)) { if (errno == ECHILD) break; }; } int main(int argc, char **argv) { pid_t p; srand(time(NULL)); while (1) { p = fork(); if (p < 0) { perror("fork"); exit(EXIT_FAILURE); } if (p == 0) { create_set(); goto end; } /* Wait for forked processes to exit */ while (wait(NULL)) { if (errno == ECHILD) break; }; } end: return 0; } [akpm@linux-foundation.org: use normal comment layout] Signed-off-by:
Herton R. Krzesinski <herton@redhat.com> Acked-by:
-
- 17 Aug, 2015 2 commits
-
-
Greg Kroah-Hartman authored
-
Jeff Layton authored
commit 8fcd461d upstream. Currently, preprocess_stateid_op calls nfs4_check_olstateid which verifies that the open stateid corresponds to the current filehandle in the call by calling nfs4_check_fh. If the stateid is a NFS4_DELEG_STID however, then no such check is done. This could cause incorrect enforcement of permissions, because the nfsd_permission() call in nfs4_check_file uses current the current filehandle, but any subsequent IO operation will use the file descriptor in the stateid. Move the call to nfs4_check_fh into nfs4_check_file instead so that it can be done for all stateid types. Signed-off-by:
Jeff Layton <jeff.layton@primarydata.com> [bfields: moved fh check to avoid NULL deref in special stateid case] Signed-off-by:
J. Bruce Fields <bfields@redhat.com> Signed-off-by:
-
