sort by:
Revision Author Date Message Commit Date
e60bf80 Merge branch 'bgmac' Hauke Mehrtens says: ==================== bgmac: some fixes to napi usage I compared the napi documentation with the bgmac driver and found some problems in that driver. These two patches should fix the problems. ==================== Signed-off-by: David S. Miller <davem@davemloft.net> 19 January 2015, 21:00:02 UTC
43f159c bgmac: activate irqs only if there is nothing to poll IRQs should only get activated when there is nothing to poll in the queue any more and to after every poll. Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> Signed-off-by: David S. Miller <davem@davemloft.net> 19 January 2015, 20:59:57 UTC
6216642 bgmac: register napi before the device napi should get registered before the netdev and not after. Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> Signed-off-by: David S. Miller <davem@davemloft.net> 19 January 2015, 20:59:57 UTC
852c5d9 Merge branch 'sh_eth' Ben Hutchings says: ==================== sh_eth fixes I'm currently looking at Ethernet support on the R-Car H2 chip, reviewing and testing the sh_eth driver. Here are fixes for two fairly obvious bugs in the driver; I will probably have some more later. These are not tested on any of the other supported chips. ==================== Signed-off-by: David S. Miller <davem@davemloft.net> 19 January 2015, 20:37:44 UTC
4f9dce2 sh_eth: Fix ethtool operation crash when net device is down The driver connects and disconnects the PHY device whenever the net device is brought up and down. The ethtool get_settings, set_settings and nway_reset operations will dereference a null or dangling pointer if called while it is down. I think it would be preferable to keep the PHY connected, but there may be good reasons not to. As an immediate fix for this bug: - Set the phydev pointer to NULL after disconnecting the PHY - Change those three operations to return -ENODEV while the PHY is not connected Signed-off-by: Ben Hutchings <ben.hutchings@codethink.co.uk> Signed-off-by: David S. Miller <davem@davemloft.net> 19 January 2015, 20:37:40 UTC
b37feed sh_eth: Fix promiscuous mode on chips without TSU Currently net_device_ops::set_rx_mode is only implemented for chips with a TSU (multiple address table). However we do need to turn the PRM (promiscuous) flag on and off for other chips. - Remove the unlikely() from the TSU functions that we may safely call for chips without a TSU - Make setting of the MCT flag conditional on the tsu capability flag - Rename sh_eth_set_multicast_list() to sh_eth_set_rx_mode() and plumb it into both net_device_ops structures - Remove the previously-unreachable branch in sh_eth_rx_mode() that would otherwise reset the flags to defaults for non-TSU chips Signed-off-by: Ben Hutchings <ben.hutchings@codethink.co.uk> Signed-off-by: David S. Miller <davem@davemloft.net> 19 January 2015, 20:37:40 UTC
9d28971 ipv6: stop sending PTB packets for MTU < 1280 Reduce the attack vector and stop generating IPv6 Fragment Header for paths with an MTU smaller than the minimum required IPv6 MTU size (1280 byte) - called atomic fragments. See IETF I-D "Deprecating the Generation of IPv6 Atomic Fragments" [1] for more information and how this "feature" can be misused. [1] https://tools.ietf.org/html/draft-ietf-6man-deprecate-atomfrag-generation-00 Signed-off-by: Fernando Gont <fgont@si6networks.com> Signed-off-by: Hagen Paul Pfeifer <hagen@jauu.net> Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org> Signed-off-by: David S. Miller <davem@davemloft.net> 19 January 2015, 19:52:07 UTC
ce75145 libata: prevent HSM state change race between ISR and PIO It is possible for ata_sff_flush_pio_task() to set ap->hsm_task_state to HSM_ST_IDLE in between the time __ata_sff_port_intr() checks for HSM_ST_IDLE and before it calls ata_sff_hsm_move() causing ata_sff_hsm_move() to BUG(). This problem is hard to reproduce making this patch hard to verify, but this fix will prevent the race. I have not been able to reproduce the problem, but here is a crash dump from a 2.6.32 kernel. On examining the ata port's state, its hsm_task_state field has a value of HSM_ST_IDLE: crash> struct ata_port.hsm_task_state ffff881c1121c000 hsm_task_state = 0 Normally, this should not be possible as ata_sff_hsm_move() was called from ata_sff_host_intr(), which checks hsm_task_state and won't call ata_sff_hsm_move() if it has a HSM_ST_IDLE value. PID: 11053 TASK: ffff8816e846cae0 CPU: 0 COMMAND: "sshd" #0 [ffff88008ba03960] machine_kexec at ffffffff81038f3b #1 [ffff88008ba039c0] crash_kexec at ffffffff810c5d92 #2 [ffff88008ba03a90] oops_end at ffffffff8152b510 #3 [ffff88008ba03ac0] die at ffffffff81010e0b #4 [ffff88008ba03af0] do_trap at ffffffff8152ad74 #5 [ffff88008ba03b50] do_invalid_op at ffffffff8100cf95 #6 [ffff88008ba03bf0] invalid_op at ffffffff8100bf9b [exception RIP: ata_sff_hsm_move+317] RIP: ffffffff813a77ad RSP: ffff88008ba03ca0 RFLAGS: 00010097 RAX: 0000000000000000 RBX: ffff881c1121dc60 RCX: 0000000000000000 RDX: ffff881c1121dd10 RSI: ffff881c1121dc60 RDI: ffff881c1121c000 RBP: ffff88008ba03d00 R8: 0000000000000000 R9: 000000000000002e R10: 000000000001003f R11: 000000000000009b R12: ffff881c1121c000 R13: 0000000000000000 R14: 0000000000000050 R15: ffff881c1121dd78 ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018 #7 [ffff88008ba03d08] ata_sff_host_intr at ffffffff813a7fbd #8 [ffff88008ba03d38] ata_sff_interrupt at ffffffff813a821e #9 [ffff88008ba03d78] handle_IRQ_event at ffffffff810e6ec0 --- <IRQ stack> --- [exception RIP: pipe_poll+48] RIP: ffffffff81192780 RSP: ffff880f26d459b8 RFLAGS: 00000246 RAX: 0000000000000000 RBX: ffff880f26d459c8 RCX: 0000000000000000 RDX: 0000000000000001 RSI: 0000000000000000 RDI: ffff881a0539fa80 RBP: ffffffff8100bb8e R8: ffff8803b23324a0 R9: 0000000000000000 R10: ffff880f26d45dd0 R11: 0000000000000008 R12: ffffffff8109b646 R13: ffff880f26d45948 R14: 0000000000000246 R15: 0000000000000246 ORIG_RAX: ffffffffffffff10 CS: 0010 SS: 0018 RIP: 00007f26017435c3 RSP: 00007fffe020c420 RFLAGS: 00000206 RAX: 0000000000000017 RBX: ffffffff8100b072 RCX: 00007fffe020c45c RDX: 00007f2604a3f120 RSI: 00007f2604a3f140 RDI: 000000000000000d RBP: 0000000000000000 R8: 00007fffe020e570 R9: 0101010101010101 R10: 0000000000000000 R11: 0000000000000246 R12: 00007fffe020e5f0 R13: 00007fffe020e5f4 R14: 00007f26045f373c R15: 00007fffe020e5e0 ORIG_RAX: 0000000000000017 CS: 0033 SS: 002b Somewhere between the ata_sff_hsm_move() check and the ata_sff_host_intr() check, the value changed. On examining the other cpus to see what else was running, another cpu was running the error handler routines: PID: 326 TASK: ffff881c11014aa0 CPU: 1 COMMAND: "scsi_eh_1" #0 [ffff88008ba27e90] crash_nmi_callback at ffffffff8102fee6 #1 [ffff88008ba27ea0] notifier_call_chain at ffffffff8152d515 #2 [ffff88008ba27ee0] atomic_notifier_call_chain at ffffffff8152d57a #3 [ffff88008ba27ef0] notify_die at ffffffff810a154e #4 [ffff88008ba27f20] do_nmi at ffffffff8152b1db #5 [ffff88008ba27f50] nmi at ffffffff8152aaa0 [exception RIP: _spin_lock_irqsave+47] RIP: ffffffff8152a1ff RSP: ffff881c11a73aa0 RFLAGS: 00000006 RAX: 0000000000000001 RBX: ffff881c1121deb8 RCX: 0000000000000000 RDX: 0000000000000246 RSI: 0000000000000020 RDI: ffff881c122612d8 RBP: ffff881c11a73aa0 R8: ffff881c17083800 R9: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: ffff881c1121c000 R13: 000000000000001f R14: ffff881c1121dd50 R15: ffff881c1121dc60 ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0000 --- <NMI exception stack> --- #6 [ffff881c11a73aa0] _spin_lock_irqsave at ffffffff8152a1ff #7 [ffff881c11a73aa8] ata_exec_internal_sg at ffffffff81396fb5 #8 [ffff881c11a73b58] ata_exec_internal at ffffffff81397109 #9 [ffff881c11a73bd8] atapi_eh_request_sense at ffffffff813a34eb Before it tried to acquire a spinlock, ata_exec_internal_sg() called ata_sff_flush_pio_task(). This function will set ap->hsm_task_state to HSM_ST_IDLE, and has no locking around setting this value. ata_sff_flush_pio_task() can then race with the interrupt handler and potentially set HSM_ST_IDLE at a fatal moment, which will trigger a kernel BUG. v2: Fixup comment in ata_sff_flush_pio_task() tj: Further updated comment. Use ap->lock instead of shost lock and use the [un]lock_irq variant instead of the irqsave/restore one. Signed-off-by: David Milburn <dmilburn@redhat.com> Signed-off-by: Tejun Heo <tj@kernel.org> Cc: stable@vger.kernel.org 19 January 2015, 19:11:23 UTC
1caf6aa scripts/recordmcount.pl: There is no -m32 gcc option on Super-H anymore Compiling SH with gcc-4.8 fails due to the -m32 option not being supported. From http://buildd.debian-ports.org/status/fetch.php?pkg=linux&arch=sh4&ver=3.16.7-ckt4-1&stamp=1421425783 CC init/main.o gcc-4.8: error: unrecognized command line option '-m32' ld: cannot find init/.tmp_mc_main.o: No such file or directory objcopy: 'init/.tmp_mx_main.o': No such file rm: cannot remove 'init/.tmp_mx_main.o': No such file or directory rm: cannot remove 'init/.tmp_mc_main.o': No such file or directory Link: http://lkml.kernel.org/r/1421537778-29001-1-git-send-email-kernel@mkarcher.dialup.fu-berlin.de Link: http://lkml.kernel.org/r/54BCBDD4.10102@physik.fu-berlin.de Cc: stable@vger.kernel.org Cc: Matt Fleming <matt@console-pimps.org> Reported-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> Signed-off-by: Michael Karcher <kernel@mkarcher.dialup.fu-berlin.de> Signed-off-by: Steven Rostedt <rostedt@goodmis.org> 19 January 2015, 17:10:47 UTC
72dd299 libata: allow sata_sil24 to opt-out of tag ordered submission Ronny reports: https://bugzilla.kernel.org/show_bug.cgi?id=87101 "Since commit 8a4aeec8d "libata/ahci: accommodate tag ordered controllers" the access to the harddisk on the first SATA-port is failing on its first access. The access to the harddisk on the second port is working normal. When reverting the above commit, access to both harddisks is working fine again." Maintain tag ordered submission as the default, but allow sata_sil24 to continue with the old behavior. Cc: <stable@vger.kernel.org> Cc: Tejun Heo <tj@kernel.org> Reported-by: Ronny Hegewald <Ronny.Hegewald@online.de> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Tejun Heo <tj@kernel.org> 19 January 2015, 14:10:07 UTC
dbe752a pinctrl: MAINTAINERS: add git tree reference Reference my pinctrl GIT tree @kernel.org Reported-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> 19 January 2015, 10:27:19 UTC
bcd53f8 pinctrl: qcom: Don't iterate past end of function array Timur reports that this code crashes if nfunctions is 0. Fix the loop iteration to only consider valid elements of the functions array. Reported-by: Timur Tabi <timur@codeaurora.org> Cc: Pramod Gurav <pramod.gurav@smartplayin.com> Cc: Bjorn Andersson <bjorn.andersson@sonymobile.com> Cc: Ivan T. Ivanov <iivanov@mm-sol.com> Cc: Andy Gross <agross@codeaurora.org> Fixes: 327455817a92 "pinctrl: qcom: Add support for reset for apq8064" Signed-off-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> 19 January 2015, 10:17:45 UTC
cdef511 KVM: fix sparse warning in include/trace/events/kvm.h sparse complains about include/trace/events/kvm.h:163:1: error: directive in argument list include/trace/events/kvm.h:167:1: error: directive in argument list include/trace/events/kvm.h:169:1: error: directive in argument list and sparse is right. Preprocessing directives in an argument of a macro are undefined behaviour as of C99 6.10.3p11. Lets use an indirection to fix this. Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> 19 January 2015, 10:07:57 UTC
6cdb081 ipr: wait for aborted command responses Fixes a race condition in abort handling that was injected when multiple interrupt support was added. When only a single interrupt is present, the adapter guarantees it will send responses for aborted commands prior to the response for the abort command itself. With multiple interrupts, these responses generally come back on different interrupts, so we need to ensure the abort thread waits until the aborted command is complete so we don't perform a double completion. This race condition was being hit frequently in environments which were triggering command timeouts, which was resulting in a double completion causing a kernel oops. Cc: <stable@vger.kernel.org> Signed-off-by: Brian King <brking@linux.vnet.ibm.com> Reviewed-by: Wendy Xiong <wenxiong@linux.vnet.ibm.com> Tested-by: Wendy Xiong <wenxiong@linux.vnet.ibm.com> Signed-off-by: Christoph Hellwig <hch@lst.de> 19 January 2015, 09:46:20 UTC
378ff1a fix deadlock in cifs_ioctl_clone() It really needs to check that src is non-directory *and* use {un,}lock_two_nodirectories(). As it is, it's trivial to cause double-lock (ioctl(fd, CIFS_IOC_COPYCHUNK_FILE, fd)) and if the last argument is an fd of directory, we are asking for trouble by violating the locking order - all directories go before all non-directories. If the last argument is an fd of parent directory, it has 50% odds of locking child before parent, which will cause AB-BA deadlock if we race with unlink(). Cc: stable@vger.kernel.org @ 3.13+ Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> 19 January 2015, 04:49:26 UTC
f2c3c67 Merge tag 'mvebu-fixes-3.19-3' of git://git.infradead.org/linux-mvebu into fixes Merge " mvebu fixes for 3.19-rc (part #3)" from Andrew Lunn: mvebu: completely disable hardware I/O coherency * tag 'mvebu-fixes-3.19-3' of git://git.infradead.org/linux-mvebu: ARM: mvebu: completely disable hardware I/O coherency Signed-off-by: Olof Johansson <olof@lixom.net> 19 January 2015, 00:46:31 UTC
b62a9c2 Merge tag 'gpio-v3.19-4' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio Pull GPIO fixes from Linus Walleij: "Here is a set of fixes that mainly appeared when Johan Hovold started exercising the removal path of the GPIO library, dealing with hotplugging of GPIO controllers. Details from tag: A slew of fixes dealing with some irritating bugs (non-regressions) that have been around forever in the GPIO subsystem, most of them also tagged for stable: - A large slew of fixes from Johan Hovold who is finally testing and reviewing the removal path of the GPIO drivers. - Fix of_get_named_gpiod_flags() so it works as expected. - Fix an IRQ handling bug in the crystalcove driver" * tag 'gpio-v3.19-4' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio: gpiolib: of: Correct error handling in of_get_named_gpiod_flags gpio: sysfs: fix gpio attribute-creation race gpio: sysfs: fix gpio device-attribute leak gpio: sysfs: fix gpio-chip device-attribute leak gpio: unregister gpiochip device before removing it gpio: fix sleep-while-atomic in gpiochip_remove gpio: fix memory leak and sleep-while-atomic gpio: clean up gpiochip_add error handling gpio: fix gpio-chip list corruption gpio: fix memory and reference leaks in gpiochip_add error path gpio: crystalcove: use handle_nested_irq 18 January 2015, 17:03:13 UTC
6689388 Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input Pull input subsystem fixes from Dmitry Torokhov. * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input: Input: uinput - fix ioctl nr overflow for UI_GET_SYSNAME/VERSION Input: I8042 - add Acer Aspire 7738 to the nomux list Input: elantech - support new ICs types for version 4 Input: i8042 - reset keyboard to fix Elantech touchpad detection MAINTAINERS: remove Dmitry Torokhov's alternate address 18 January 2015, 16:55:23 UTC
6455931 ALSA: usb-audio: Add mic volume fix quirk for Logitech Webcam C210 Signed-off-by: Jason Lee Cragg <jcragg@gmail.com> Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de> 18 January 2015, 09:03:50 UTC
7c4c558 drm/exynos: fix warning of vblank reference count Prevented re-enabling the vblank interrupt by drm_vblank_off and drm_vblank_get from mixer_wait_for_vblank returns error after drm_vblank_off. We get below warnings without this error handling because vblank reference count is mismatched by above sequence. setting mode 1920x1080-60Hz@XR24 on connectors 16, crtc 13 [ 19.900793] ------------[ cut here ]------------ [ 19.903959] WARNING: CPU: 0 PID: 0 at drivers/gpu/drm/drm_irq.c:1072 exynos_drm_crtc_finish_pageflip+0xac/0xdc() [ 19.914076] Modules linked in: [ 19.917116] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.19.0-rc4-00040-g3d729789-dirty #46 [ 19.925342] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree) [ 19.931437] [<c0014430>] (unwind_backtrace) from [<c001158c>] (show_stack+0x10/0x14) [ 19.939131] [<c001158c>] (show_stack) from [<c04cdd50>] (dump_stack+0x84/0xc4) [ 19.946329] [<c04cdd50>] (dump_stack) from [<c00226f4>] (warn_slowpath_common+0x80/0xb0) [ 19.954382] [<c00226f4>] (warn_slowpath_common) from [<c00227c0>] (warn_slowpath_null+0x1c/0x24) [ 19.963132] [<c00227c0>] (warn_slowpath_null) from [<c02c20cc>] (exynos_drm_crtc_finish_pageflip+0xac/0xdc) [ 19.972841] [<c02c20cc>] (exynos_drm_crtc_finish_pageflip) from [<c02cb7ec>] (mixer_irq_handler+0xdc/0x104) [ 19.982546] [<c02cb7ec>] (mixer_irq_handler) from [<c005c904>] (handle_irq_event_percpu+0x78/0x134) [ 19.991555] [<c005c904>] (handle_irq_event_percpu) from [<c005c9fc>] (handle_irq_event+0x3c/0x5c) [ 20.000395] [<c005c9fc>] (handle_irq_event) from [<c005f384>] (handle_fasteoi_irq+0xe0/0x1ac) [ 20.008885] [<c005f384>] (handle_fasteoi_irq) from [<c005bf88>] (generic_handle_irq+0x2c/0x3c) [ 20.017463] [<c005bf88>] (generic_handle_irq) from [<c005c254>] (__handle_domain_irq+0x7c/0xec) [ 20.026128] [<c005c254>] (__handle_domain_irq) from [<c0008698>] (gic_handle_irq+0x30/0x68) [ 20.034449] [<c0008698>] (gic_handle_irq) from [<c00120c0>] (__irq_svc+0x40/0x74) [ 20.041893] Exception stack(0xc06fff68 to 0xc06fffb0) [ 20.046923] ff60: 00000000 00000000 000052f6 c001b460 c06fe000 c07064e8 [ 20.055070] ff80: c04d743c c07392a2 c0739440 c06da340 ef7fca80 00000000 01000000 c06fffb0 [ 20.063212] ffa0: c000f24c c000f250 60000013 ffffffff [ 20.068245] [<c00120c0>] (__irq_svc) from [<c000f250>] (arch_cpu_idle+0x38/0x3c) [ 20.075611] [<c000f250>] (arch_cpu_idle) from [<c0050948>] (cpu_startup_entry+0x108/0x16c) [ 20.083846] [<c0050948>] (cpu_startup_entry) from [<c06aec5c>] (start_kernel+0x3a0/0x3ac) [ 20.091980] ---[ end trace 2c76ee0500489d1b ]--- Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com> Signed-off-by: Inki Dae <inki.dae@samsung.com> 18 January 2015, 08:59:32 UTC
bd50866 drm/exynos: remove unnecessary runtime pm operations In booting, we can see a below message. [ 3.241728] exynos-mixer 14450000.mixer: Unbalanced pm_runtime_enable! Already pm_runtime_enable is called by probe function. Remove pm_runtime_enable/disable from mixer_bind and mixer_unbind. Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com> Signed-off-by: Inki Dae <inki.dae@samsung.com> 18 January 2015, 08:59:31 UTC
265134a drm/exynos: fix reset codes for memory mapped hdmi phy This fixes reset codes to support memory mapped hdmi phy as well as hdmi phy dedicated i2c lines. Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com> Signed-off-by: Inki Dae <inki.dae@samsung.com> 18 January 2015, 08:59:29 UTC
ec6f34e Linux 3.19-rc5 18 January 2015, 06:02:20 UTC
d0ac5d8 Merge tag 'armsoc-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc Pull ARM SoC fixes from Olof Johansson: "We've been sitting on our fixes branch for a while, so this batch is unfortunately on the large side. A lot of these are tweaks and fixes to device trees, fixing various bugs around clocks, reg ranges, etc. There's also a few defconfig updates (which are on the late side, no more of those). All in all the diffstat is bigger than ideal at this time, but nothing in here seems particularly risky" * tag 'armsoc-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: (31 commits) reset: sunxi: fix spinlock initialization ARM: dts: disable CCI on exynos5420 based arndale-octa drivers: bus: check cci device tree node status ARM: rockchip: disable jtag/sdmmc autoswitching on rk3288 ARM: nomadik: fix up leftover device tree pins ARM: at91: board-dt-sama5: add phy_fixup to override NAND_Tree ARM: at91/dt: sam9263: Add missing clocks to lcdc node ARM: at91: sama5d3: dt: correct the sound route ARM: at91/dt: sama5d4: fix the timer reg length ARM: exynos_defconfig: Enable LM90 driver ARM: exynos_defconfig: Enable options for display panel support arm: dts: Use pmu_system_controller phandle for dp phy ARM: shmobile: sh73a0 legacy: Set .control_parent for all irqpin instances ARM: dts: berlin: correct BG2Q's SM GPIO location. ARM: dts: berlin: add broken-cd and set bus width for eMMC in Marvell DMP DT ARM: dts: berlin: fix io clk and add missing core clk for BG2Q sdhci2 host ARM: dts: Revert disabling of smc91x for n900 ARM: dts: imx51-babbage: Fix ULPI PHY reset modelling ARM: dts: dra7-evm: fix qspi device tree partition size ARM: omap2plus_defconfig: use CONFIG_CPUFREQ_DT ... 18 January 2015, 06:00:40 UTC
2061dcd net: sctp: fix race for one-to-many sockets in sendmsg's auto associate I.e. one-to-many sockets in SCTP are not required to explicitly call into connect(2) or sctp_connectx(2) prior to data exchange. Instead, they can directly invoke sendmsg(2) and the SCTP stack will automatically trigger connection establishment through 4WHS via sctp_primitive_ASSOCIATE(). However, this in its current implementation is racy: INIT is being sent out immediately (as it cannot be bundled anyway) and the rest of the DATA chunks are queued up for later xmit when connection is established, meaning sendmsg(2) will return successfully. This behaviour can result in an undesired side-effect that the kernel made the application think the data has already been transmitted, although none of it has actually left the machine, worst case even after close(2)'ing the socket. Instead, when the association from client side has been shut down e.g. first gracefully through SCTP_EOF and then close(2), the client could afterwards still receive the server's INIT_ACK due to a connection with higher latency. This INIT_ACK is then considered out of the blue and hence responded with ABORT as there was no alive assoc found anymore. This can be easily reproduced f.e. with sctp_test application from lksctp. One way to fix this race is to wait for the handshake to actually complete. The fix defers waiting after sctp_primitive_ASSOCIATE() and sctp_primitive_SEND() succeeded, so that DATA chunks cooked up from sctp_sendmsg() have already been placed into the output queue through the side-effect interpreter, and therefore can then be bundeled together with COOKIE_ECHO control chunks. strace from example application (shortened): socket(PF_INET, SOCK_SEQPACKET, IPPROTO_SCTP) = 3 sendmsg(3, {msg_name(28)={sa_family=AF_INET, sin_port=htons(8888), sin_addr=inet_addr("192.168.1.115")}, msg_iov(1)=[{"hello", 5}], msg_controllen=0, msg_flags=0}, 0) = 5 sendmsg(3, {msg_name(28)={sa_family=AF_INET, sin_port=htons(8888), sin_addr=inet_addr("192.168.1.115")}, msg_iov(1)=[{"hello", 5}], msg_controllen=0, msg_flags=0}, 0) = 5 sendmsg(3, {msg_name(28)={sa_family=AF_INET, sin_port=htons(8888), sin_addr=inet_addr("192.168.1.115")}, msg_iov(1)=[{"hello", 5}], msg_controllen=0, msg_flags=0}, 0) = 5 sendmsg(3, {msg_name(28)={sa_family=AF_INET, sin_port=htons(8888), sin_addr=inet_addr("192.168.1.115")}, msg_iov(1)=[{"hello", 5}], msg_controllen=0, msg_flags=0}, 0) = 5 sendmsg(3, {msg_name(28)={sa_family=AF_INET, sin_port=htons(8888), sin_addr=inet_addr("192.168.1.115")}, msg_iov(0)=[], msg_controllen=48, {cmsg_len=48, cmsg_level=0x84 /* SOL_??? */, cmsg_type=, ...}, msg_flags=0}, 0) = 0 // graceful shutdown for SOCK_SEQPACKET via SCTP_EOF close(3) = 0 tcpdump before patch (fooling the application): 22:33:36.306142 IP 192.168.1.114.41462 > 192.168.1.115.8888: sctp (1) [INIT] [init tag: 3879023686] [rwnd: 106496] [OS: 10] [MIS: 65535] [init TSN: 3139201684] 22:33:36.316619 IP 192.168.1.115.8888 > 192.168.1.114.41462: sctp (1) [INIT ACK] [init tag: 3345394793] [rwnd: 106496] [OS: 10] [MIS: 10] [init TSN: 3380109591] 22:33:36.317600 IP 192.168.1.114.41462 > 192.168.1.115.8888: sctp (1) [ABORT] tcpdump after patch: 14:28:58.884116 IP 192.168.1.114.35846 > 192.168.1.115.8888: sctp (1) [INIT] [init tag: 438593213] [rwnd: 106496] [OS: 10] [MIS: 65535] [init TSN: 3092969729] 14:28:58.888414 IP 192.168.1.115.8888 > 192.168.1.114.35846: sctp (1) [INIT ACK] [init tag: 381429855] [rwnd: 106496] [OS: 10] [MIS: 10] [init TSN: 2141904492] 14:28:58.888638 IP 192.168.1.114.35846 > 192.168.1.115.8888: sctp (1) [COOKIE ECHO] , (2) [DATA] (B)(E) [TSN: 3092969729] [...] 14:28:58.893278 IP 192.168.1.115.8888 > 192.168.1.114.35846: sctp (1) [COOKIE ACK] , (2) [SACK] [cum ack 3092969729] [a_rwnd 106491] [#gap acks 0] [#dup tsns 0] 14:28:58.893591 IP 192.168.1.114.35846 > 192.168.1.115.8888: sctp (1) [DATA] (B)(E) [TSN: 3092969730] [...] 14:28:59.096963 IP 192.168.1.115.8888 > 192.168.1.114.35846: sctp (1) [SACK] [cum ack 3092969730] [a_rwnd 106496] [#gap acks 0] [#dup tsns 0] 14:28:59.097086 IP 192.168.1.114.35846 > 192.168.1.115.8888: sctp (1) [DATA] (B)(E) [TSN: 3092969731] [...] , (2) [DATA] (B)(E) [TSN: 3092969732] [...] 14:28:59.103218 IP 192.168.1.115.8888 > 192.168.1.114.35846: sctp (1) [SACK] [cum ack 3092969732] [a_rwnd 106486] [#gap acks 0] [#dup tsns 0] 14:28:59.103330 IP 192.168.1.114.35846 > 192.168.1.115.8888: sctp (1) [SHUTDOWN] 14:28:59.107793 IP 192.168.1.115.8888 > 192.168.1.114.35846: sctp (1) [SHUTDOWN ACK] 14:28:59.107890 IP 192.168.1.114.35846 > 192.168.1.115.8888: sctp (1) [SHUTDOWN COMPLETE] Looks like this bug is from the pre-git history museum. ;) Fixes: 08707d5482df ("lksctp-2_5_31-0_5_1.patch") Signed-off-by: Daniel Borkmann <dborkman@redhat.com> Acked-by: Vlad Yasevich <vyasevich@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net> 18 January 2015, 04:52:20 UTC
12ba857 Merge tag 'clk-fixes-for-linus' of git://git.linaro.org/people/mike.turquette/linux Pull clock driver fixes from Mike Turquette: "Small number of fixes for clock drivers and a single null pointer dereference fix in the framework core code. The driver fixes vary from fixing section mismatch warnings to preventing machines from hanging (and preventing developers from crying)" * tag 'clk-fixes-for-linus' of git://git.linaro.org/people/mike.turquette/linux: clk: fix possible null pointer dereference Revert "clk: ppc-corenet: Fix Section mismatch warning" clk: rockchip: fix deadlock possibility in cpuclk clk: berlin: bg2q: remove non-exist "smemc" gate clock clk: at91: keep slow clk enabled to prevent system hang clk: rockchip: fix rk3288 cpuclk core dividers clk: rockchip: fix rk3066 pll lock bit location clk: rockchip: Fix clock gate for rk3188 hclk_emem_peri clk: rockchip: add CLK_IGNORE_UNUSED flag to fix rk3066/rk3188 USB Host 18 January 2015, 03:29:11 UTC
901b208 Merge tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi Pull SCSI fixes from James Bottomley: "This is one fix for a Multiqueue sleeping in invalid context problem and a MAINTAINER file update for Qlogic" * tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi: scsi: ->queue_rq can't sleep MAINTAINERS: Update maintainer list for qla4xxx 18 January 2015, 03:26:52 UTC
c7662fc clk: fix possible null pointer dereference The commit 646cafc6 (clk: Change clk_ops->determine_rate to return a clk_hw as the best parent) opens a possibility for null pointer dereference, fix this. Signed-off-by: Stanimir Varbanov <svarbanov@mm-sol.com> Reviewed-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Michael Turquette <mturquette@linaro.org> 17 January 2015, 19:33:57 UTC
176a107 Revert "clk: ppc-corenet: Fix Section mismatch warning" This reverts commit da788acb28386aa896224e784954bb73c99ff26c. That commit tried to fix the section mismatch warning by moving the ppc_corenet_clk_driver struct to init section. This is definitely wrong because the kernel would free the memories occupied by this struct after boot while this driver is still registered in the driver core. The kernel would panic when accessing this driver struct. Cc: stable@vger.kernel.org # 3.17 Signed-off-by: Kevin Hao <haokexin@gmail.com> Acked-by: Scott Wood <scottwood@freescale.com> Signed-off-by: Michael Turquette <mturquette@linaro.org> 17 January 2015, 19:27:16 UTC
a5e1baf clk: rockchip: fix deadlock possibility in cpuclk Lockdep reported a possible deadlock between the cpuclk lock and for example the i2c driver. CPU0 CPU1 ---- ---- lock(clk_lock); local_irq_disable(); lock(&(&i2c->lock)->rlock); lock(clk_lock); <Interrupt> lock(&(&i2c->lock)->rlock); *** DEADLOCK *** The generic clock-types of the core ccf already use spin_lock_irqsave when touching clock registers, so do the same for the cpuclk. Signed-off-by: Heiko Stuebner <heiko@sntech.de> Reviewed-by: Doug Anderson <dianders@chromium.org> Signed-off-by: Michael Turquette <mturquette@linaro.org> [mturquette@linaro.org: removed initialization of "flags"] 17 January 2015, 19:22:39 UTC
298e320 Merge branch 'fixes' of git://git.infradead.org/users/vkoul/slave-dma Pull dmaengine fixes from Vinod Koul: "Two patches, the first by Andy to fix dw dmac runtime pm and second one by me to fix the dmaengine headers in MAINTAINERS" * 'fixes' of git://git.infradead.org/users/vkoul/slave-dma: dmaengine: dw: balance PM runtime calls MAINTAINERS: dmaengine: fix the header file for dmaengine 17 January 2015, 18:26:24 UTC
59b2858 Merge branch 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull perf fixes from Ingo Molnar: "Mostly tooling fixes, but also two PMU driver fixes" * 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: perf tools powerpc: Use dwfl_report_elf() instead of offline. perf tools: Fix segfault for symbol annotation on TUI perf test: Fix dwarf unwind using libunwind. perf tools: Avoid build splat for syscall numbers with uclibc perf tools: Elide strlcpy warning with uclibc perf tools: Fix statfs.f_type data type mismatch build error with uclibc tools: Remove bitops/hweight usage of bits in tools/perf perf machine: Fix __machine__findnew_thread() error path perf tools: Fix building error in x86_64 when dwarf unwind is on perf probe: Propagate error code when write(2) failed perf/x86/intel: Fix bug for "cycles:p" and "cycles:pp" on SLM perf/rapl: Fix sysfs_show() initialization for RAPL PMU 17 January 2015, 18:24:30 UTC
8f1e8ee ARM: mvebu: completely disable hardware I/O coherency The current hardware I/O coherency is known to cause problems with DMA coherent buffers, as it still requires explicit I/O synchronization barriers, which is not compatible with the semantics expected by the Linux DMA coherent buffers API. So, in order to have enough time to validate a new solution based on automatic I/O synchronization barriers, this commit disables hardware I/O coherency entirely. Future patches will re-enable it. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: <stable@vger.kernel.org> # v3.8+ Signed-off-by: Andrew Lunn <andrew@lunn.ch> 17 January 2015, 17:46:55 UTC
0fb22a8 ARM: OMAP: Work around hardcoded interrupts Commit 9a1091ef0017 ("irqchip: gic: Support hierarchy irq domain") changed the GIC driver to use a non-legacy IRQ domain on DT platforms. This patch assumes that DT-driven systems are getting all of their interrupts from device tree. Turns out that OMAP has quite a few hidden gems, and still uses hardcoded interrupts despite having fairly complete DTs. This patch attempts to work around these by offering a translation method that can be called directly from the hwmod code, if present. The same hack is sprinkled over PRCM and TWL. It isn't pretty, but it seems to do the job without having to add more hacks to the interrupt controller code. Tested on OMAP4 (Panda-ES) and OMAP5 (UEVM5432). Signed-off-by: Marc Zyngier <marc.zyngier@arm.com> Acked-by: Nishanth Menon <nm@ti.com> [tony@atomide.com: updated to fix make randconfig issue] Signed-off-by: Tony Lindgren <tony@atomide.com> 17 January 2015, 16:56:12 UTC
d01de23 Merge tag 'perf-urgent-for-mingo' of git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/urgent Pull perf/urgent fixes from Arnaldo Carvalho de Melo: - Fix segfault when using both the map symtab viewer and annotation in the TUI (Namhyung Kim). - uClibc build fixes (Alexey Brodkin, Vineet Gupta). - bitops/hweight were moved from tools/perf/ too tools/include, move some leftovers (Arnaldo Carvalho de Melo) - Fix dwarf unwind x86_64 build error (Namhyung Kim) - Fix __machine__findnew_thread() error path (Namhyung Kim) - Propagate error code when write(2) failed in 'perf probe' (Namhyung Kim) - Use dwfl_report_elf() instead of offline in powerpc bits to properly handle non prelinked DSOs (Sukadev Bhattiprolu). - Fix dwarf unwind using libunwind in 'perf test' (Wang Nan) Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com> Signed-off-by: Ingo Molnar <mingo@kernel.org> 17 January 2015, 10:04:35 UTC
966903a Merge tag 'samsung-fixes-3.19' of git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung into fixes Merge "Samsung fixes for v3.19" from Kukjin Kim: Samsung fixes for v3.19 - exynos_defconfig: enable LM90 driver and display panel support - HWMON - SENSORS_LM90 - Direct Rendering Manager (DRM) - DRM bridge registration and lookup framework - Parade ps8622/ps8625 eDP/LVDS bridge - NXP ptn3460 eDP/LVDS bridge - Exynos Fully Interactive Mobile Display controller (FIMD) - Panel registration and lookup framework - Simple panels - Backlight & LCD device support - use pmu_system_controller phandle for dp phy : DP PHY requires pmu_system_controller to handle PMU reg. now * tag 'samsung-fixes-3.19' of git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung: ARM: exynos_defconfig: Enable LM90 driver ARM: exynos_defconfig: Enable options for display panel support arm: dts: Use pmu_system_controller phandle for dp phy Signed-off-by: Olof Johansson <olof@lixom.net> 17 January 2015, 03:11:37 UTC
41544f9 reset: sunxi: fix spinlock initialization Call spin_lock_init() before the spinlocks are used, both in early init and probe functions preventing a lockdep splat. I have been observing lockdep complaining [1] during boot on my a80 optimus [2] when CONFIG_PROVE_LOCKING has been enabled. This patch resolves the splat, and has been tested on a few other sunxi platforms without issue. [1] http://storage.kernelci.org/next/next-20150107/arm-multi_v7_defconfig+CONFIG_PROVE_LOCKING=y/lab-tbaker/boot-sun9i-a80-optimus.html [2] http://kernelci.org/boot/?a80-optimus Signed-off-by: Tyler Baker <tyler.baker@linaro.org> Cc: <stable@vger.kernel.org> Acked-by: Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by: Kevin Hilman <khilman@linaro.org> Signed-off-by: Olof Johansson <olof@lixom.net> 17 January 2015, 03:11:31 UTC
a30e931 Merge tag 'renesas-soc-fixes-for-v3.19' of git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas into fixes Merge "Renesas ARM Based SoC Fixes for v3.19" from Simon Horman: Renesas ARM Based SoC Fixes for v3.19 This pull request is based on the last round of SoC updates for v3.19, Fourth Round of Renesas ARM Based SoC Updates for v3.19, tagged as renesas-soc3-for-v3.19, merged into your next/soc branch and included in v3.19-rc1. - ARM: shmobile: r8a7740: Instantiate GIC from C board code in legacy builds Set .control_parent for all irqpin instances for sh73a0 SoC when booting using legacy C. - ARM: shmobile: r8a7740: Instantiate GIC from C board code in legacy builds This fixes a long standing problem which has been present since the sh73a0 SoC started using the INTC External IRQ pin driver. The patch that introduced the problem is 341eb5465f67437a ("ARM: shmobile: INTC External IRQ pin driver on sh73a0") which was included in v3.10. * tag 'renesas-soc-fixes-for-v3.19' of git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas: ARM: shmobile: sh73a0 legacy: Set .control_parent for all irqpin instances ARM: shmobile: r8a7740: Instantiate GIC from C board code in legacy builds 17 January 2015, 03:10:43 UTC
25217fe ARM: dts: disable CCI on exynos5420 based arndale-octa The arndale-octa board was giving "imprecise external aborts" during boot-up with MCPM enabled. CCI enablement of the boot cluster was found to be the cause of these aborts (possibly because the secure f/w was not allowing it). Hence, disable CCI for the arndale-octa board. Signed-off-by: Abhilash Kesavan <a.kesavan@samsung.com> Tested-by: Krzysztof Kozlowski <k.kozlowski@samsung.com> Tested-by: Kevin Hilman <khilman@linaro.org> Tested-by: Tyler Baker <tyler.baker@linaro.org> Signed-off-by: Olof Johansson <olof@lixom.net> 17 January 2015, 03:10:41 UTC
896ddd6 drivers: bus: check cci device tree node status The arm-cci driver completes the probe sequence even if the cci node is marked as disabled. Add a check in the driver to honour the cci status in the device tree. Signed-off-by: Abhilash Kesavan <a.kesavan@samsung.com> Acked-by: Sudeep Holla <sudeep.holla@arm.com> Acked-by: Nicolas Pitre <nico@linaro.org> Tested-by: Sudeep Holla <sudeep.holla@arm.com> Tested-by: Kevin Hilman <khilman@linaro.org> Signed-off-by: Olof Johansson <olof@lixom.net> 17 January 2015, 03:10:41 UTC
6fda93b Merge tag 'at91-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/nferre/linux-at91 into fixes Merge "at91: fixes for 3.19 #1 (ter)" from Nicolas Ferre: First fixes batch for AT91 on 3.19: - fix some DT entries - correct clock entry for the at91sam9263 LCD - add a phy_fixup for Eth1 on sama5d4 * tag 'at91-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/nferre/linux-at91: ARM: at91: board-dt-sama5: add phy_fixup to override NAND_Tree ARM: at91/dt: sam9263: Add missing clocks to lcdc node ARM: at91: sama5d3: dt: correct the sound route ARM: at91/dt: sama5d4: fix the timer reg length Signed-off-by: Olof Johansson <olof@lixom.net> 17 January 2015, 03:10:40 UTC
c9b75d5 ARM: rockchip: disable jtag/sdmmc autoswitching on rk3288 rk3288 SoCs have a function to automatically switch between jtag/sdmmc pinmux settings depending on the card state. This collides with a lot of assumptions. It only works when using the internal card-detect mechanism and breaks horribly when using either the normal card-detect via the slot-gpio function or via any other pin. Also there is of course no link between the mmc and jtag on the software-side, so the jtag clocks may very well be disabled when the card is ejected and the soc switches back to the jtag pinmux. Leaving the switching function enabled did result in mmc timeouts and rcu stalls thus hanging the system on 3.19-rc1. Therefore disable it in all cases, as we expect the devicetree to explicitly select either mmc or jtag pinmuxes anyway. Signed-off-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Olof Johansson <olof@lixom.net> 17 January 2015, 03:10:39 UTC
1dbb36b Merge tag 'berlin-fixes-for-3.19-1' of git://git.infradead.org/users/hesselba/linux-berlin into fixes Merge "ARM: berlin: Fixes for v3.19 (round 1)" from Sebastian Hesselbarth: Marvell Berlin fixes for v3.19 round 1: - SDHCI DT fixes for BG2Q and BG2Q reference board - BG2Q SM GPIO DT node relocation * tag 'berlin-fixes-for-3.19-1' of git://git.infradead.org/users/hesselba/linux-berlin: ARM: dts: berlin: correct BG2Q's SM GPIO location. ARM: dts: berlin: add broken-cd and set bus width for eMMC in Marvell DMP DT ARM: dts: berlin: fix io clk and add missing core clk for BG2Q sdhci2 host Signed-off-by: Olof Johansson <olof@lixom.net> 17 January 2015, 03:10:39 UTC
259e438 ARM: nomadik: fix up leftover device tree pins We altered the device tree bindings for the Nomadik family of pin controllers to be standard, this file was merged out-of-order so we missed fixing this. Fix it up. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Olof Johansson <olof@lixom.net> 17 January 2015, 03:10:38 UTC
e3db221 Merge tag 'omap-for-v3.19/fixes-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into fixes Merge "omap fixes against v3.19-rc1" from Tony Lindgren: Fixes for omaps mostly to deal with dra7 timer issues and hypervisor mode. The other fixes are minor fixes for various boards. The summary of the fixes is: - Fix real-time counter rate typos for some frequencies - Fix counter frequency drift for am572x - Fix booting of secondary CPU in HYP mode - Fix n900 board name for legacy user space - Fix cpufreq in omap2plus_defconfig after Kconfig change - Fix dra7 qspi partitions And also, let's re-enable smc91x on some n900 boards that we have sitting in a few test boot systems after the boot loader dependencies got fixed. * tag 'omap-for-v3.19/fixes-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap: ARM: dts: Revert disabling of smc91x for n900 ARM: dts: dra7-evm: fix qspi device tree partition size ARM: omap2plus_defconfig: use CONFIG_CPUFREQ_DT ARM: OMAP2+: Fix n900 board name for legacy user space ARM: omap5/dra7xx: Enable booting secondary CPU in HYP mode ARM: dra7xx: Fix counter frequency drift for AM572x errata i856 ARM: omap5/dra7xx: Fix frequency typos Signed-off-by: Olof Johansson <olof@lixom.net> 17 January 2015, 03:10:37 UTC
3be8142 Merge tag 'imx-fixes-3.19' of git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux into fixes Merge "ARM: imx: fixes for 3.19" from Shawn Guo: The i.MX fixes for 3.19: - One fix for incorrect i.MX25 SPI1 clock assignment in device tree, which causes system hang when accessing SPI1. - Correct i.MX6SX QSPI parent clock configuration to fix a kernel Oops. - Fix ULPI PHY reset modelling on imx51-babbage board to remove the dependency on bootloader for USB3317 ULPI PHY reset. - Correct video divider setting on i.MX6Q rev T0 1.0 to fix the issue that HDMI is not working at high resolution on T0 1.0. - One incremental fix for CODA960 VPU enabling in device tree to correct interrupt order. - LS1021A SCFG block works in BE mode, add device tree property big-endian to make it right. * tag 'imx-fixes-3.19' of git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux: ARM: dts: imx51-babbage: Fix ULPI PHY reset modelling ARM: imx6sx: Set PLL2 as parent of QSPI clocks ARM: dts: imx25: Fix the SPI1 clocks ARM: clk-imx6q: fix video divider for rev T0 1.0 ARM: dts: imx6qdl: Fix CODA960 interrupt order ARM: ls1021a: dtsi: add 'big-endian' property for scfg node Signed-off-by: Olof Johansson <olof@lixom.net> 17 January 2015, 03:10:37 UTC
1591dc4 Merge tag 'v3.19-rockchip-dtsfixes1' of git://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip into fixes Merge "ARM: rockchip: dts fix for 3.19" from Heiko Stübner: Increase drive-strength to sdmmc pins on rk3288-evb to fix an issue with the fixed highspeed card detection. * tag 'v3.19-rockchip-dtsfixes1' of git://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip: ARM: dts: rockchip: bump sd card pin drive strength up on rk3288-evb Signed-off-by: Olof Johansson <olof@lixom.net> 17 January 2015, 03:10:36 UTC
f469cde ARM: shmobile: r8a7779: Instantiate GIC from C board code in legacy builds As of commit 9a1091ef0017c40a ("irqchip: gic: Support hierarchy irq domain."), Marzen legacy hangs during boot with: Image Name: 'Linux-3.19.0-rc4' Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 3445880 Bytes = 3.3 MiB Load Address: 60008000 Entry Point: 60008000 Verifying Checksum ... OK Loading Kernel Image ... OK OK Starting kernel ... Enabling DEBUG_LL does not seem to change the situation, however this patch by itself fixes this issue and re-enables normal boot. This issue happens because the IRQ numbers of the GIC are now virtual, and no longer match the hardcoded hardware IRQ numbers in the platform board code. To fix this, instantiate the GIC from platform board code when compiling a legacy kernel, like is done for the sh73a0, r8a7740 and r8a7778 legacy code. Follows same style as the r8a7740 legacy GIC fix by Geert Uytterhoeven, thanks to him for the initial work. Signed-off-by: Magnus Damm <damm+renesas@opensource.se> Acked-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Simon Horman <horms+renesas@verge.net.au> 17 January 2015, 00:28:41 UTC
1fbbc3f ARM: shmobile: r8a7778: Instantiate GIC from C board code in legacy builds As of commit 9a1091ef0017c40a ("irqchip: gic: Support hierarchy irq domain."), Bock-W legacy hangs during boot with: Unable to handle kernel paging request at virtual address cf86a128 pgd = c0004000 [cf86a128] *pgd=6f80041e(bad) Internal error: Oops: 8000000d [#1] SMP ARM CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.19.0-rc4 #1 Hardware name: bockw task: cf823b40 ti: cf824000 task.ti: cf824000 PC is at 0xcf86a128 LR is at request_threaded_irq+0xbc/0x124 This happens because the IRQ numbers of the GIC are now virtual, and no longer match the hardcoded hardware IRQ numbers in the platform board code. To fix this, instantiate the GIC from platform board code when compiling a legacy kernel, like is done for the sh73a0 and r8a7740 legacy code. Follows same style as the r8a7740 legacy GIC fix by Geert Uytterhoeven, thanks to him for the initial work. Signed-off-by: Magnus Damm <damm+renesas@opensource.se> Acked-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Simon Horman <horms+renesas@verge.net.au> 17 January 2015, 00:28:14 UTC
ee1c244 genetlink: synchronize socket closing and family removal In addition to the problem Jeff Layton reported, I looked at the code and reproduced the same warning by subscribing and removing the genl family with a socket still open. This is a fairly tricky race which originates in the fact that generic netlink allows the family to go away while sockets are still open - unlike regular netlink which has a module refcount for every open socket so in general this cannot be triggered. Trying to resolve this issue by the obvious locking isn't possible as it will result in deadlocks between unregistration and group unbind notification (which incidentally lockdep doesn't find due to the home grown locking in the netlink table.) To really resolve this, introduce a "closing socket" reference counter (for generic netlink only, as it's the only affected family) in the core netlink code and use that in generic netlink to wait for all the sockets that are being closed at the same time as a generic netlink family is removed. This fixes the race that when a socket is closed, it will should call the unbind, but if the family is removed at the same time the unbind will not find it, leading to the warning. The real problem though is that in this case the unbind could actually find a new family that is registered to have a multicast group with the same ID, and call its mcast_unbind() leading to confusing. Also remove the warning since it would still trigger, but is now no longer a problem. This also moves the code in af_netlink.c to before unreferencing the module to avoid having the same problem in the normal non-genl case. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net> 16 January 2015, 22:04:25 UTC
5ad6300 genetlink: disallow subscribing to unknown mcast groups Jeff Layton reported that he could trigger the multicast unbind warning in generic netlink using trinity. I originally thought it was a race condition between unregistering the generic netlink family and closing the socket, but there's a far simpler explanation: genetlink currently allows subscribing to groups that don't (yet) exist, and the warning is triggered when unsubscribing again while the group still doesn't exist. Originally, I had a warning in the subscribe case and accepted it out of userspace API concerns, but the warning was of course wrong and removed later. However, I now think that allowing userspace to subscribe to groups that don't exist is wrong and could possibly become a security problem: Consider a (new) genetlink family implementing a permission check in the mcast_bind() function similar to the like the audit code does today; it would be possible to bypass the permission check by guessing the ID and subscribing to the group it exists. This is only possible in case a family like that would be dynamically loaded, but it doesn't seem like a huge stretch, for example wireless may be loaded when you plug in a USB device. To avoid this reject such subscription attempts. If this ends up causing userspace issues we may need to add a workaround in af_netlink to deny such requests but not return an error. Reported-by: Jeff Layton <jeff.layton@primarydata.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net> 16 January 2015, 22:04:24 UTC
f555f3d genetlink: document parallel_ops The kernel-doc for the parallel_ops family struct member is missing, add it. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net> 16 January 2015, 22:04:24 UTC
25ca917 ALSA: firewire-lib: limit the MIDI data rate Do no send MIDI bytes at the full rate at which FireWire packets happen to be sent, but restrict them to the actual rate of a real MIDI port. This is required by the specification, and prevents data loss when the device's buffer overruns. Signed-off-by: Clemens Ladisch <clemens@ladisch.de> Reviewed-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Tested-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de> 16 January 2015, 21:51:23 UTC
5c697e5 ALSA: firewire-lib: remove rx_blocks_for_midi quirk There are several devices that expect to receive MIDI data only in the first eight data blocks of a packet. If the driver restricts the data rate to the allowed rate (as mandated by the specification, but not yet implemented by this driver), this happens naturally. Therefore, there is no reason to ever try to use more data packets with any device. Signed-off-by: Clemens Ladisch <clemens@ladisch.de> Reviewed-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Tested-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de> 16 January 2015, 21:50:45 UTC
fc7f0dd kernel: avoid overflow in cmp_range Avoid overflow possibility. [ The overflow is purely theoretical, since this is used for memory ranges that aren't even close to using the full 64 bits, but this is the right thing to do regardless. - Linus ] Signed-off-by: Louis Langholtz <lou_langholtz@me.com> Cc: Yinghai Lu <yinghai@kernel.org> Cc: Peter Anvin <hpa@linux.intel.com> Cc: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> 16 January 2015, 21:02:23 UTC
6bcf9c1 perf tools powerpc: Use dwfl_report_elf() instead of offline. dwfl_report_offline() works only when libraries are prelinked. Replace dwfl_report_offline() with dwfl_report_elf() so we correctly extract debug info even from libraries that are not prelinked. Reported-by: Jiri Olsa <jolsa@redhat.com> Signed-off-by: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com> Tested-by: Jiri Olsa <jolsa@redhat.com> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Michael Ellerman <mpe@ellerman.id.au> Link: http://lkml.kernel.org/r/20150114221045.GA17703@us.ibm.com Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com> 16 January 2015, 20:49:30 UTC
813ccd1 perf tools: Fix segfault for symbol annotation on TUI Currently the symbol structure is allocated with symbol_conf.priv_size to carry sideband information like annotation, map browser on TUI and sort-by-name tree node. So retrieving these information from symbol needs to care about the details of such placement. However the annotation code just assumes that the symbol is placed after the struct annotation. But actually there's other info between them. So accessing those struct will lead to an undefined behavior (usually a crash) after they write their info to the same location. To reproduce the problem, please follow the steps below: 1. run perf report (TUI of course) with -v option 2. open map browser (by pressing right arrow key for any entry) 3. search any function (by pressing '/' key and input whatever..) 4. return to the hist browser (by pressing 'q' or left arrow key) 5. open annotation window for the same entry (by pressing 'a' key) Signed-off-by: Namhyung Kim <namhyung@kernel.org> Cc: David Ahern <dsahern@gmail.com> Cc: Ingo Molnar <mingo@kernel.org> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Link: http://lkml.kernel.org/r/1421234288-22758-1-git-send-email-namhyung@kernel.org Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com> 16 January 2015, 20:49:29 UTC
b93b096 perf test: Fix dwarf unwind using libunwind. Perf tool fails to unwind user stack if the event raises in a shared object. This patch improves tests/dwarf-unwind.c to demonstrate the problem by utilizing commonly used glibc function "bsearch". If perf is not statically linked, the testcase will try to unwind a mixed call trace. By debugging libunwind I found that there is a bug in unwind-libunwind: it always passes 0 as segbase to libunwind, cause libunwind unable to locate debug_frame entry fir first level ip address (I add some more debugging output into libunwind to make things clear): >_Uarm_dwarf_find_debug_frame: start_ip = 10be98, end_ip = 10c2a4 >_Uarm_dwarf_find_debug_frame: found debug_frame table `/lib/libc-2.18.so': segbase=0x0, len=7, gp=0x0, table_data=0x449388 >_Uarm_dwarf_search_unwind_table: call lookup:ip = b6cd3bcc, segbase = 0, rel_ip = b6cd3bcc >lookup: e->start_ip_offset = bcf18 (rel_ip = b6cd3bcc) >lookup: e->start_ip_offset = 6d314 (rel_ip = b6cd3bcc) >lookup: e->start_ip_offset = 33d0c (rel_ip = b6cd3bcc) ... >lookup: e->start_ip_offset = 15d0c (rel_ip = b6cd3bcc) >lookup: e->start_ip_offset = 15c40 (rel_ip = b6cd3bcc) >_Uarm_dwarf_search_unwind_table: IP b6cd3bcc inside range b6c12000-b6d4c000, but no explicit unwind info found >put_rs_cache: unmasking signals/interrupts and releasing lock >_Uarm_dwarf_step: returning -10 >_Uarm_step: dwarf_step()=-10 This patch passes map->start as segbase to dwarf_find_debug_frame(), so di will be initialized correctly. In addition, dso and executable are different when setting segbase. This patch first check whether the elf is executable, and pass segbase only for shared object. Signed-off-by: Wang Nan <wangnan0@huawei.com> Acked-by: Jiri Olsa <jolsa@kernel.org> Cc: Ingo Molnar <mingo@redhat.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Li Zefan <lizefan@huawei.com> Cc: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Paul Mackerras <paulus@samba.org> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Link: http://lkml.kernel.org/r/1421203007-75799-1-git-send-email-wangnan0@huawei.com Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com> 16 January 2015, 20:49:29 UTC
ea1fe3a perf tools: Avoid build splat for syscall numbers with uclibc This is due to duplicated unistd inclusion (via uClibc headers + kernel headers) Also seen on ARM uClibc based tools ------- ARC build ---------->8------------- CC util/evlist.o In file included from ~/arc/k.org/arch/arc/include/uapi/asm/unistd.h:25:0, from util/../perf-sys.h:10, from util/../perf.h:15, from util/event.h:7, from util/event.c:3: ~/arc/k.org/include/uapi/asm-generic/unistd.h:906:0: warning: "__NR_fcntl64" redefined [enabled by default] #define __NR_fcntl64 __NR3264_fcntl ^ In file included from ~/arc/gnu/INSTALL_1412-arc-2014.12-rc1/arc-snps-linux-uclibc/sysroot/usr/include/sys/syscall.h:24:0, from util/../perf-sys.h:6, ----------------->8------------------- ------- ARM build ---------->8------------- CC FPIC plugin_scsi.o In file included from util/../perf-sys.h:9:0, from util/../perf.h:15, from util/cache.h:7, from perf.c:12: ~/arc/k.org/arch/arm/include/uapi/asm/unistd.h:28:0: warning: "__NR_restart_syscall" redefined [enabled by default] In file included from ~/buildroot/host/usr/arm-buildroot-linux-uclibcgnueabi/sysroot/usr/include/sys/syscall.h:25:0, from util/../perf-sys.h:6, from util/../perf.h:15, from util/cache.h:7, from perf.c:12: ~/buildroot/host/usr/arm-buildroot-linux-uclibcgnueabi/sysroot/usr/include/bits/sysnum.h:17:0: note: this is the location of the previous definition ----------------->8------------------- Signed-off-by: Vineet Gupta <vgupta@synopsys.com> Cc: Alexey Brodkin <Alexey.Brodkin@synopsys.com> Cc: Ingo Molnar <mingo@kernel.org> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Link: http://lkml.kernel.org/r/1421156604-30603-4-git-send-email-vgupta@synopsys.com Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com> 16 January 2015, 20:49:29 UTC
a83d869 perf tools: Elide strlcpy warning with uclibc ----------------->8------------------ CC bench/sched-pipe.o In file included from builtin-annotate.c:13:0: util/cache.h:76:15: warning: redundant redeclaration of 'strlcpy' [-Wredundant-decls] extern size_t strlcpy(char *dest, const char *src, size_t size); ^ In file included from util/util.h:55:0, from builtin.h:4, from builtin-annotate.c:8: ~/vineetg/arc/gnu/INSTALL_1412-arc-2014.12-rc1/arc-snps-linux-uclibc/sysroot/usr/include/string.h:396:15: note: previous declaration of 'strlcpy' was here extern size_t strlcpy(char *__restrict dst, const char *__restrict src, ----------------->8------------------ Signed-off-by: Vineet Gupta <vgupta@synopsys.com> Cc: Alexey Brodkin <Alexey.Brodkin@synopsys.com> Cc: Ingo Molnar <mingo@kernel.org> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Link: http://lkml.kernel.org/r/1421156604-30603-3-git-send-email-vgupta@synopsys.com Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com> 16 January 2015, 20:49:29 UTC
db1806e perf tools: Fix statfs.f_type data type mismatch build error with uclibc ARC Linux uses the no legacy syscalls abi and corresponding uClibc headers statfs defines f_type to be U32 which causes perf build breakage http://git.uclibc.org/uClibc/tree/libc/sysdeps/linux/common-generic/bits/statfs.h ----------->8--------------- CC fs/fs.o fs/fs.c: In function 'fs__valid_mount': fs/fs.c:82:24: error: comparison between signed and unsigned integer expressions [-Werror=sign-compare] else if (st_fs.f_type != magic) ^ cc1: all warnings being treated as errors ----------->8--------------- Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com> Acked-by: Jiri Olsa <jolsa@kernel.org> Cc: Borislav Petkov <bp@suse.de> Cc: Cody P Schafer <dev@codyps.com> Cc: Ingo Molnar <mingo@kernel.org> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Vineet Gupta <Vineet.Gupta1@synopsys.com> Link: http://lkml.kernel.org/r/1420888254-17504-2-git-send-email-vgupta@synopsys.com Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com> 16 January 2015, 20:49:29 UTC
25cd480 tools: Remove bitops/hweight usage of bits in tools/perf We need to use lib/hweight.c for that, just like we do for lib/rbtree.c, so tools need to link hweight.o. For now do it directly, but we need to have a tools/lib/lk.a or .so that collects these goodies... Reported-by: Jan Beulich <JBeulich@suse.com> Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: Borislav Petkov <bp@suse.de> Cc: David Ahern <dsahern@gmail.com> Cc: Don Zickus <dzickus@redhat.com> Cc: Frederic Weisbecker <fweisbec@gmail.com> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Mike Galbraith <efault@gmx.de> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Paul Mackerras <paulus@samba.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Stephane Eranian <eranian@google.com> Link: http://lkml.kernel.org/n/tip-a1e91dx3apzqw5kbdt7ut21s@git.kernel.org Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com> 16 January 2015, 20:49:29 UTC
260d819 perf machine: Fix __machine__findnew_thread() error path When thread__init_map_groups() fails, a new thread should be removed from the rbtree since it's gonna be freed. Also update last match cache only if the function succeeded. Reported-by: David Ahern <dsahern@gmail.com> Signed-off-by: Namhyung Kim <namhyung@kernel.org> Acked-by: Jiri Olsa <jolsa@kernel.org> Cc: David Ahern <dsahern@gmail.com> Cc: Ingo Molnar <mingo@kernel.org> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Link: http://lkml.kernel.org/r/1420763892-15535-1-git-send-email-namhyung@kernel.org Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com> 16 January 2015, 20:49:28 UTC
c6e5e9f perf tools: Fix building error in x86_64 when dwarf unwind is on When build with 'make ARCH=x86' and dwarf unwind is on, there is a compiling error: CC /home/wn/perf/arch/x86/util/unwind-libdw.o CC /home/wn/perf/arch/x86/tests/regs_load.o arch/x86/tests/regs_load.S: Assembler messages: arch/x86/tests/regs_load.S:65: Error: operand type mismatch for `push' arch/x86/tests/regs_load.S:72: Error: operand type mismatch for `pop' make[1]: *** [/home/wn/perf/arch/x86/tests/regs_load.o] Error 1 make[1]: INTERNAL: Exiting with 25 jobserver tokens available; should be 24! make: *** [all] Error 2 ... Which is caused by incorrectly undefine macro HAVE_ARCH_X86_64_SUPPORT. 'config/Makefile.arch' tests __x86_64__ only when 'ARCH=x86_64'. However, when building x86_64 kernel, ARCH=x86 is valid and commonly used. Build systems, such as yocto, uses x86_64 compiler with 'ARCH=x86' to build x86_64 perf, which causes mismatching. As __LP64__ is defined for x86_64 as well, we can consolidate the __x86_64__ check to the __LP64__ check and get rid of the IS_X86_64 IMHO. (This patch is made by Namhyung Kim when replying my v1 patch: https://lkml.org/lkml/2015/1/7/17 I modified the code to remove dependency on RAW_ARCH: https://lkml.org/lkml/2015/1/7/865 Namhyung Kim didn't provide his SOB in his original email. I add mine only for my modification.) Signed-off-by: Namhyung Kim <namhyung@kernel.org> Signed-off-by: Wang Nan <wangnan0@huawei.com> Acked-by: Jiri Olsa <jolsa@kernel.org> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Li Zefan <lizefan@huawei.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: Namhyung Kim <namhyung@kernel.org> Link: http://lkml.kernel.org/r/1421029255-23039-1-git-send-email-wangnan0@huawei.com [ Namhyung provided his S-o-B on a followup to this patch thread on lkml ] Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com> 16 January 2015, 20:49:28 UTC
7949ba1 perf probe: Propagate error code when write(2) failed When it failed to write probe commands to the probe_event file in debugfs, it needs to propagate the error code properly. Current code blindly uses the return value of the write(2) so it always uses -1 (-EPERM) and it might confuse users. Signed-off-by: Namhyung Kim <namhyung@kernel.org> Acked-by: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com> Cc: David Ahern <dsahern@gmail.com> Cc: Ingo Molnar <mingo@kernel.org> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Link: http://lkml.kernel.org/r/1420886028-15135-4-git-send-email-namhyung@kernel.org Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com> 16 January 2015, 20:49:28 UTC
29187a9 workqueue: fix subtle pool management issue which can stall whole worker_pool A worker_pool's forward progress is guaranteed by the fact that the last idle worker assumes the manager role to create more workers and summon the rescuers if creating workers doesn't succeed in timely manner before proceeding to execute work items. This manager role is implemented in manage_workers(), which indicates whether the worker may proceed to work item execution with its return value. This is necessary because multiple workers may contend for the manager role, and, if there already is a manager, others should proceed to work item execution. Unfortunately, the function also indicates that the worker may proceed to work item execution if need_to_create_worker() is false at the head of the function. need_to_create_worker() tests the following conditions. pending work items && !nr_running && !nr_idle The first and third conditions are protected by pool->lock and thus won't change while holding pool->lock; however, nr_running can change asynchronously as other workers block and resume and while it's likely to be zero, as someone woke this worker up in the first place, some other workers could have become runnable inbetween making it non-zero. If this happens, manage_worker() could return false even with zero nr_idle making the worker, the last idle one, proceed to execute work items. If then all workers of the pool end up blocking on a resource which can only be released by a work item which is pending on that pool, the whole pool can deadlock as there's no one to create more workers or summon the rescuers. This patch fixes the problem by removing the early exit condition from maybe_create_worker() and making manage_workers() return false iff there's already another manager, which ensures that the last worker doesn't start executing work items. We can leave the early exit condition alone and just ignore the return value but the only reason it was put there is because the manage_workers() used to perform both creations and destructions of workers and thus the function may be invoked while the pool is trying to reduce the number of workers. Now that manage_workers() is called only when more workers are needed, the only case this early exit condition is triggered is rare race conditions rendering it pointless. Tested with simulated workload and modified workqueue code which trigger the pool deadlock reliably without this patch. Signed-off-by: Tejun Heo <tj@kernel.org> Reported-by: Eric Sandeen <sandeen@sandeen.net> Link: http://lkml.kernel.org/g/54B019F4.8030009@sandeen.net Cc: Dave Chinner <david@fromorbit.com> Cc: Lai Jiangshan <laijs@cn.fujitsu.com> Cc: stable@vger.kernel.org 16 January 2015, 19:21:16 UTC
7ad4b4a Merge tag 'char-misc-3.19-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc Pull char/misc driver fixes from Greg KH: "Here are three small driver fixes for reported issues for 3.19-rc5. All of these have been in linux-next for a while with no reported problems" * tag 'char-misc-3.19-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc: mcb: mcb-pci: Only remap the 1st 0x200 bytes of BAR 0 mei: add ABI documentation for fw_status exported through sysfs mei: clean reset bit before reset 16 January 2015, 19:18:08 UTC
62b1530 Merge tag 'driver-core-3.19-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core Pull driver core fix from Greg KH: "Here is one kernfs fix for a reported issue for 3.19-rc5. It has been in linux-next for a while" * tag 'driver-core-3.19-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core: kernfs: Fix kernfs_name_compare 16 January 2015, 19:16:52 UTC
7b78de8 Merge tag 'tty-3.19-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty Pull tty/serial driver fixes from Greg KH: "Here are some tty and serial driver fixes for 3.19-rc5 that resolve some reported issues, and add a new device id to the 8250 serial port driver. All have been in linux-next with no reported problems" * tag 'tty-3.19-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty: serial: samsung: Add the support for Exynos5433 SoC Revert "tty: Fix pty master poll() after slave closes v2" tty: Prevent hw state corruption in exclusive mode reopen tty: Add support for the WCH384 4S multi-IO card serial: fix parisc boot hang 16 January 2015, 19:15:49 UTC
937102f Merge tag 'staging-3.19-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging Pull staging driver fixes from Greg KH: "Here are 6 staging driver fixes for 3.19-rc5. They fix some reported issues with some IIO drivers, as well as some issues with the vt6655 wireless driver. All have been in linux-next for a while" * tag 'staging-3.19-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging: staging: vt6655: fix sparse warning: argument type staging: vt6655: Fix loss of distant/weak access points on channel change. staging: vt6655: vnt_tx_packet Fix corrupted tx packets. staging: vt6655: fix sparse warnings: incorrect argument type iio: iio: Fix iio_channel_read return if channel havn't info iio: ad799x: Fix ad7991/ad7995/ad7999 config setup 16 January 2015, 19:13:45 UTC
79600d4 Merge tag 'usb-3.19-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb Pull USB fixes from Greg KH: "Here is a bunch of USB fixes for 3.19-rc5. Most of these are gadget driver fixes, along with the xhci driver fix that we both reported having problems with, as well as some new device ids and other tiny fixes. All have been in linux-next with no problems" * tag 'usb-3.19-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb: (43 commits) usb: dwc3: gadget: Stop TRB preparation after limit is reached usb: dwc3: gadget: Fix TRB preparation during SG usb: phy: mv-usb: fix usb_phy build errors usb: serial: handle -ENODEV quietly in generic_submit_read_urb usb: serial: silence all non-critical read errors USB: console: fix potential use after free USB: console: fix uninitialised ldisc semaphore usb: gadget: udc: atmel: fix possible oops when unloading module usb: gadget: gadgetfs: fix an oops in ep_write() usb: phy: Fix deferred probing OHCI: add a quirk for ULi M5237 blocking on reset uas: Add US_FL_NO_ATA_1X for 2 more Seagate disk enclosures uas: Do not blacklist ASM1153 disk enclosures usb: gadget: udc: avoid dereference before NULL check in ep_queue usb: host: ehci-tegra: request deferred probe when failing to get phy uas: disable UAS on Apricorn SATA dongles uas: Add US_FL_NO_REPORT_OPCODES for JMicron JMS566 with usb-id 0bc2:a013 uas: Add US_FL_NO_ATA_1X for Seagate devices with usb-id 0bc2:a013 xhci: Add broken-streams quirk for Fresco Logic FL1000G xhci controllers USB: EHCI: adjust error return code ... 16 January 2015, 19:02:44 UTC
fa818dc Merge tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux Pull arm64 fixes from Will Deacon: - Wire up compat_sys_execveat for compat (AArch32) tasks - Revert 421520ba9829, as this breaks our side of the boot protocol * tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux: arm64: partially revert "ARM: 8167/1: extend the reserved memory for initrd to be page aligned" arm64: compat: wire up compat_sys_execveat 16 January 2015, 19:01:21 UTC
a2a32cd Merge tag 'nfs-for-3.19-2' of git://git.linux-nfs.org/projects/trondmy/linux-nfs Pull NFS client bugfixes from Trond Myklebust: "Highlights include: - Stable fix for a NFSv3/lockd race - Fixes for several NFSv4.1 client id trunking bugs - Remove an incorrect test when checking for delegated opens" * tag 'nfs-for-3.19-2' of git://git.linux-nfs.org/projects/trondmy/linux-nfs: NFSv4: Remove incorrect check in can_open_delegated() NFS: Ignore transport protocol when detecting server trunking NFSv4/v4.1: Verify the client owner id during trunking detection NFSv4: Cache the NFSv4/v4.1 client owner_id in the struct nfs_client NFSv4.1: Fix client id trunking on Linux LOCKD: Fix a race when initialising nlmsvc_timeout 16 January 2015, 18:59:06 UTC
23aa4b4 Merge tag 'trace-fixes-v3.19-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace Pull ftrace fixes from Steven Rostedt: "This holds a few fixes to the ftrace infrastructure as well as the mixture of function graph tracing and kprobes. When jprobes and function graph tracing is enabled at the same time it will crash the system: # modprobe jprobe_example # echo function_graph > /sys/kernel/debug/tracing/current_tracer After the first fork (jprobe_example probes it), the system will crash. This is due to the way jprobes copies the stack frame and does not do a normal function return. This messes up with the function graph tracing accounting which hijacks the return address from the stack and replaces it with a hook function. It saves the return addresses in a separate stack to put back the correct return address when done. But because the jprobe functions do not do a normal return, their stack addresses are not put back until the function they probe is called, which means that the probed function will get the return address of the jprobe handler instead of its own. The simple fix here was to disable function graph tracing while the jprobe handler is being called. While debugging this I found two minor bugs with the function graph tracing. The first was about the function graph tracer sharing its function hash with the function tracer (they both get filtered by the same input). The changing of the set_ftrace_filter would not sync the function recording records after a change if the function tracer was disabled but the function graph tracer was enabled. This was due to the update only checking one of the ops instead of the shared ops to see if they were enabled and should perform the sync. This caused the ftrace accounting to break and a ftrace_bug() would be triggered, disabling ftrace until a reboot. The second was that the check to update records only checked one of the filter hashes. It needs to test both the "filter" and "notrace" hashes. The "filter" hash determines what functions to trace where as the "notrace" hash determines what functions not to trace (trace all but these). Both hashes need to be passed to the update code to find out what change is being done during the update. This also broke the ftrace record accounting and triggered a ftrace_bug(). This patch set also include two more fixes that were reported separately from the kprobe issue. One was that init_ftrace_syscalls() was called twice at boot up. This is not a major bug, but that call performed a rather large kmalloc (NR_syscalls * sizeof(*syscalls_metadata)). The second call made the first one a memory leak, and wastes memory. The other fix is a regression caused by an update in the v3.19 merge window. The moving to enable events early, moved the enabling before PID 1 was created. The syscall events require setting the TIF_SYSCALL_TRACEPOINT for all tasks. But for_each_process_thread() does not include the swapper task (PID 0), and ended up being a nop. A suggested fix was to add the init_task() to have its flag set, but I didn't really want to mess with PID 0 for this minor bug. Instead I disable and re-enable events again at early_initcall() where it use to be enabled. This also handles any other event that might have its own reg function that could break at early boot up" * tag 'trace-fixes-v3.19-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace: tracing: Fix enabling of syscall events on the command line tracing: Remove extra call to init_ftrace_syscalls() ftrace/jprobes/x86: Fix conflict between jprobes and function graph tracing ftrace: Check both notrace and filter for old hash ftrace: Fix updating of filters for shared global_ops filters 16 January 2015, 18:55:52 UTC
d63e2e1 sparc/PCI: Clip bridge windows to fit in upstream windows Every PCI-PCI bridge window should fit inside an upstream bridge window because orphaned address space is unreachable from the primary side of the upstream bridge. If we inherit invalid bridge windows that overlap an upstream window from firmware, clip them to fit and update the bridge accordingly. [bhelgaas: changelog] Link: https://bugzilla.kernel.org/show_bug.cgi?id=85491 Reported-by: Marek Kordik <kordikmarek@gmail.com> Fixes: 5b28541552ef ("PCI: Restrict 64-bit prefetchable bridge windows to 64-bit resources") Signed-off-by: Yinghai Lu <yinghai@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: David S. Miller <davem@davemloft.net> CC: Paul Gortmaker <paul.gortmaker@windriver.com> CC: Yijing Wang <wangyijing@huawei.com> CC: Sam Ravnborg <sam@ravnborg.org> CC: sparclinux@vger.kernel.org 16 January 2015, 16:04:43 UTC
3ebfe46 powerpc/PCI: Clip bridge windows to fit in upstream windows Every PCI-PCI bridge window should fit inside an upstream bridge window because orphaned address space is unreachable from the primary side of the upstream bridge. If we inherit invalid bridge windows that overlap an upstream window from firmware, clip them to fit and update the bridge accordingly. [bhelgaas: changelog] Link: https://bugzilla.kernel.org/show_bug.cgi?id=85491 Reported-by: Marek Kordik <kordikmarek@gmail.com> Fixes: 5b28541552ef ("PCI: Restrict 64-bit prefetchable bridge windows to 64-bit resources") Signed-off-by: Yinghai Lu <yinghai@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> CC: Benjamin Herrenschmidt <benh@kernel.crashing.org> CC: Paul Mackerras <paulus@samba.org> CC: Michael Ellerman <mpe@ellerman.id.au> CC: Gavin Shan <gwshan@linux.vnet.ibm.com> CC: Anton Blanchard <anton@samba.org> CC: Sebastian Ott <sebott@linux.vnet.ibm.com> CC: Wei Yang <weiyang@linux.vnet.ibm.com> CC: Andrew Murray <amurray@embedded-bits.co.uk> CC: linuxppc-dev@lists.ozlabs.org 16 January 2015, 16:04:43 UTC
2e5e804 parisc/PCI: Clip bridge windows to fit in upstream windows Every PCI-PCI bridge window should fit inside an upstream bridge window because orphaned address space is unreachable from the primary side of the upstream bridge. If we inherit invalid bridge windows that overlap an upstream window from firmware, clip them to fit and update the bridge accordingly. [bhelgaas: changelog] Link: https://bugzilla.kernel.org/show_bug.cgi?id=85491 Reported-by: Marek Kordik <kordikmarek@gmail.com> Fixes: 5b28541552ef ("PCI: Restrict 64-bit prefetchable bridge windows to 64-bit resources") Signed-off-by: Yinghai Lu <yinghai@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> CC: "James E.J. Bottomley" <jejb@parisc-linux.org> CC: Helge Deller <deller@gmx.de> CC: linux-parisc@vger.kernel.org 16 January 2015, 16:04:43 UTC
4e348ba mn10300/PCI: Clip bridge windows to fit in upstream windows Every PCI-PCI bridge window should fit inside an upstream bridge window because orphaned address space is unreachable from the primary side of the upstream bridge. If we inherit invalid bridge windows that overlap an upstream window from firmware, clip them to fit and update the bridge accordingly. [bhelgaas: changelog] Link: https://bugzilla.kernel.org/show_bug.cgi?id=85491 Reported-by: Marek Kordik <kordikmarek@gmail.com> Fixes: 5b28541552ef ("PCI: Restrict 64-bit prefetchable bridge windows to 64-bit resources") Signed-off-by: Yinghai Lu <yinghai@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> CC: David Howells <dhowells@redhat.com> CC: Koichi Yasutake <yasutake.koichi@jp.panasonic.com> CC: linux-am33-list@redhat.com 16 January 2015, 16:04:43 UTC
576e438 microblaze/PCI: Clip bridge windows to fit in upstream windows Every PCI-PCI bridge window should fit inside an upstream bridge window because orphaned address space is unreachable from the primary side of the upstream bridge. If we inherit invalid bridge windows that overlap an upstream window from firmware, clip them to fit and update the bridge accordingly. [bhelgaas: changelog] Link: https://bugzilla.kernel.org/show_bug.cgi?id=85491 Reported-by: Marek Kordik <kordikmarek@gmail.com> Fixes: 5b28541552ef ("PCI: Restrict 64-bit prefetchable bridge windows to 64-bit resources") Signed-off-by: Yinghai Lu <yinghai@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> CC: Michal Simek <monstr@monstr.eu> CC: Benjamin Herrenschmidt <benh@kernel.crashing.org> CC: Sebastian Ott <sebott@linux.vnet.ibm.com> 16 January 2015, 16:04:43 UTC
ce821ef ia64/PCI: Clip bridge windows to fit in upstream windows Every PCI-PCI bridge window should fit inside an upstream bridge window because orphaned address space is unreachable from the primary side of the upstream bridge. If we inherit invalid bridge windows that overlap an upstream window from firmware, clip them to fit and update the bridge accordingly. [bhelgaas: changelog] Link: https://bugzilla.kernel.org/show_bug.cgi?id=85491 Reported-by: Marek Kordik <kordikmarek@gmail.com> Fixes: 5b28541552ef ("PCI: Restrict 64-bit prefetchable bridge windows to 64-bit resources") Signed-off-by: Yinghai Lu <yinghai@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> CC: Tony Luck <tony.luck@intel.com> CC: Fenghua Yu <fenghua.yu@intel.com> CC: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com> CC: linux-ia64@vger.kernel.org 16 January 2015, 16:04:42 UTC
b0c568d frv/PCI: Clip bridge windows to fit in upstream windows Every PCI-PCI bridge window should fit inside an upstream bridge window because orphaned address space is unreachable from the primary side of the upstream bridge. If we inherit invalid bridge windows that overlap an upstream window from firmware, clip them to fit and update the bridge accordingly. [bhelgaas: changelog] Link: https://bugzilla.kernel.org/show_bug.cgi?id=85491 Reported-by: Marek Kordik <kordikmarek@gmail.com> Fixes: 5b28541552ef ("PCI: Restrict 64-bit prefetchable bridge windows to 64-bit resources") Signed-off-by: Yinghai Lu <yinghai@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> CC: David Howells <dhowells@redhat.com> CC: Paul Gortmaker <paul.gortmaker@windriver.com> 16 January 2015, 16:04:42 UTC
b3e1182 alpha/PCI: Clip bridge windows to fit in upstream windows Every PCI-PCI bridge window should fit inside an upstream bridge window because orphaned address space is unreachable from the primary side of the upstream bridge. If we inherit invalid bridge windows that overlap an upstream window from firmware, clip them to fit and update the bridge accordingly. [bhelgaas: changelog] Link: https://bugzilla.kernel.org/show_bug.cgi?id=85491 Reported-by: Marek Kordik <kordikmarek@gmail.com> Fixes: 5b28541552ef ("PCI: Restrict 64-bit prefetchable bridge windows to 64-bit resources") Signed-off-by: Yinghai Lu <yinghai@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> CC: Richard Henderson <rth@twiddle.net> CC: Ivan Kokshaysky <ink@jurassic.park.msu.ru> CC: Matt Turner <mattst88@gmail.com> CC: linux-alpha@vger.kernel.org 16 January 2015, 16:04:42 UTC
851b093 x86/PCI: Clip bridge windows to fit in upstream windows Every PCI-PCI bridge window should fit inside an upstream bridge window because orphaned address space is unreachable from the primary side of the upstream bridge. If we inherit invalid bridge windows that overlap an upstream window from firmware, clip them to fit and update the bridge accordingly. [bhelgaas: changelog] Link: https://bugzilla.kernel.org/show_bug.cgi?id=85491 Reported-by: Marek Kordik <kordikmarek@gmail.com> Tested-by: Marek Kordik <kordikmarek@gmail.com> Fixes: 5b28541552ef ("PCI: Restrict 64-bit prefetchable bridge windows to 64-bit resources") Signed-off-by: Yinghai Lu <yinghai@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> CC: Thomas Gleixner <tglx@linutronix.de> CC: Ingo Molnar <mingo@redhat.com> CC: "H. Peter Anvin" <hpa@zytor.com> CC: x86@kernel.org CC: stable@vger.kernel.org # v3.16+ 16 January 2015, 16:04:42 UTC
8505e72 PCI: Add pci_claim_bridge_resource() to clip window if necessary Add pci_claim_bridge_resource() to claim a PCI-PCI bridge window. This is like regular pci_claim_resource(), except that if we fail to claim the window, we check to see if we can reduce the size of the window and try again. This is for scenarios like this: pci_bus 0000:00: root bus resource [mem 0xc0000000-0xffffffff] pci 0000:00:01.0: bridge window [mem 0xbdf00000-0xddefffff 64bit pref] pci 0000:01:00.0: reg 0x10: [mem 0xc0000000-0xcfffffff pref] The 00:01.0 window is illegal: it starts before the host bridge window, so we have to assume the [0xbdf00000-0xbfffffff] region is inaccessible. We can make it legal by clipping it to [mem 0xc0000000-0xddefffff 64bit pref]. Previously we discarded the 00:01.0 window and tried to reassign that part of the hierarchy from scratch. That is a problem because Linux doesn't always assign things optimally. For example, in this case, BIOS put the 01:00.0 device in a prefetchable window below 4GB, but after 5b28541552ef, Linux puts the prefetchable window above 4GB where the 32-bit 01:00.0 device can't use it. Clipping the 00:01.0 window is less intrusive than completely reassigning things and is sufficient to let us use most of the BIOS configuration. Of course, it's possible that devices below 00:01.0 will no longer fit. If that's the case, we'll have to reassign things. But that's a separate problem. [bhelgaas: changelog, split into separate patch] Link: https://bugzilla.kernel.org/show_bug.cgi?id=85491 Reported-by: Marek Kordik <kordikmarek@gmail.com> Fixes: 5b28541552ef ("PCI: Restrict 64-bit prefetchable bridge windows to 64-bit resources") Signed-off-by: Yinghai Lu <yinghai@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> CC: stable@vger.kernel.org # v3.16+ 16 January 2015, 16:04:42 UTC
0f7e7ae PCI: Add pci_bus_clip_resource() to clip to fit upstream window Add pci_bus_clip_resource(). If a PCI-PCI bridge window overlaps an upstream bridge window but is not completely contained by it, this clips the downstream window so it fits inside the upstream one. No functional change (this adds the function but no callers). [bhelgaas: changelog, split into separate patch] Link: https://bugzilla.kernel.org/show_bug.cgi?id=85491 Reported-by: Marek Kordik <kordikmarek@gmail.com> Fixes: 5b28541552ef ("PCI: Restrict 64-bit prefetchable bridge windows to 64-bit resources") Signed-off-by: Yinghai Lu <yinghai@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> CC: stable@vger.kernel.org # v3.16+ 16 January 2015, 16:04:42 UTC
3f2f4dc PCI: Pass bridge device, not bus, when updating bridge windows pci_setup_bridge_io(), pci_setup_bridge_mmio(), and pci_setup_bridge_mmio_pref() program the windows of PCI-PCI bridges. Previously they accepted a pointer to the pci_bus of the secondary bus, then looked up the bridge leading to that bus. Pass the bridge directly, which will make it more convenient for future callers. No functional change. [bhelgaas: changelog, split into separate patch] Link: https://bugzilla.kernel.org/show_bug.cgi?id=85491 Reported-by: Marek Kordik <kordikmarek@gmail.com> Fixes: 5b28541552ef ("PCI: Restrict 64-bit prefetchable bridge windows to 64-bit resources") Signed-off-by: Yinghai Lu <yinghai@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> CC: stable@vger.kernel.org # v3.16+ 16 January 2015, 16:04:42 UTC
c3e59ee PCI: Mark Atheros AR93xx to avoid bus reset Reports against the TL-WDN4800 card indicate that PCI bus reset of this Atheros device cause system lock-ups and resets. I've also been able to confirm this behavior on multiple systems. The device never returns from reset and attempts to access config space of the device after reset result in hangs. Blacklist bus reset for the device to avoid this issue. [bhelgaas: This regression appeared in v3.14. Andreas bisected it to 425c1b223dac ("PCI: Add Virtual Channel to save/restore support"), but we don't understand the mechanism by which that commit affects the reset path.] [bhelgaas: changelog, references] Link: http://lkml.kernel.org/r/20140923210318.498dacbd@dualc.maya.org Reported-by: Andreas Hartmann <andihartmann@freenet.de> Tested-by: Andreas Hartmann <andihartmann@freenet.de> Signed-off-by: Alex Williamson <alex.williamson@redhat.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> CC: stable@vger.kernel.org # v3.14+ 16 January 2015, 16:04:38 UTC
f331a85 PCI: Add flag for devices where we can't use bus reset Enable a mechanism for devices to quirk that they do not behave when doing a PCI bus reset. We require a modest level of spec compliant behavior in order to do a reset, for instance the device should come out of reset without throwing errors and PCI config space should be accessible after reset. This is too much to ask for some devices. Link: http://lkml.kernel.org/r/20140923210318.498dacbd@dualc.maya.org Signed-off-by: Alex Williamson <alex.williamson@redhat.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> CC: stable@vger.kernel.org # v3.14+ 16 January 2015, 16:04:38 UTC
0145058 arm64: partially revert "ARM: 8167/1: extend the reserved memory for initrd to be page aligned" This patch partially reverts commit 421520ba98290a73b35b7644e877a48f18e06004 (only the arm64 part). There is no guarantee that the boot-loader places other images like dtb in a different page than initrd start/end, especially when the kernel is built with 64KB pages. When this happens, such pages must not be freed. The free_reserved_area() already takes care of rounding up "start" and rounding down "end" to avoid freeing partially used pages. Cc: <stable@vger.kernel.org> # 3.17+ Reported-by: Peter Maydell <Peter.Maydell@arm.com> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Will Deacon <will.deacon@arm.com> 16 January 2015, 13:57:33 UTC
3363673 perf/x86/intel: Fix bug for "cycles:p" and "cycles:pp" on SLM cycles:p and cycles:pp do not work on SLM since commit: 86a04461a99f ("perf/x86: Revamp PEBS event selection") UOPS_RETIRED.ALL is not a PEBS capable event, so it should not be used to count cycle number. Actually SLM calls intel_pebs_aliases_core2() which uses INST_RETIRED.ANY_P to count the number of cycles. It's a PEBS capable event. But inv and cmask must be set to count cycles. Considering SLM allows all events as PEBS with no flags, only INST_RETIRED.ANY_P, inv=1, cmask=16 needs to handled specially. Signed-off-by: Kan Liang <kan.liang@intel.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: http://lkml.kernel.org/r/1421084541-31639-1-git-send-email-kan.liang@intel.com Cc: Arnaldo Carvalho de Melo <acme@kernel.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Ingo Molnar <mingo@kernel.org> 16 January 2015, 08:06:59 UTC
433678b perf/rapl: Fix sysfs_show() initialization for RAPL PMU This patch fixes a problem with the initialization of the sysfs_show() routine for the RAPL PMU. The current code was wrongly relying on the EVENT_ATTR_STR() macro which uses the events_sysfs_show() function in the x86 PMU code. That function itself was relying on the x86_pmu data structure. Yet RAPL and the core PMU (x86_pmu) have nothing to do with each other. They should therefore not interact with each other. The x86_pmu structure is initialized at boot time based on the host CPU model. When the host CPU is not supported, the x86_pmu remains uninitialized and some of the callbacks it contains are NULL. The false dependency with x86_pmu could potentially cause crashes in case the x86_pmu is not initialized while the RAPL PMU is. This may, for instance, be the case in virtualized environments. This patch fixes the problem by using a private sysfs_show() routine for exporting the RAPL PMU events. Signed-off-by: Stephane Eranian <eranian@google.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: http://lkml.kernel.org/r/20150113225953.GA21525@thinkpad Cc: vincent.weaver@maine.edu Cc: jolsa@redhat.com Cc: Arnaldo Carvalho de Melo <acme@kernel.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Ingo Molnar <mingo@kernel.org> 16 January 2015, 08:06:58 UTC
ac64da0 net: rps: fix cpu unplug softnet_data.input_pkt_queue is protected by a spinlock that we must hold when transferring packets from victim queue to an active one. This is because other cpus could still be trying to enqueue packets into victim queue. A second problem is that when we transfert the NAPI poll_list from victim to current cpu, we absolutely need to special case the percpu backlog, because we do not want to add complex locking to protect process_queue : Only owner cpu is allowed to manipulate it, unless cpu is offline. Based on initial patch from Prasad Sodagudi & Subash Abhinov Kasiviswanathan. This version is better because we do not slow down packet processing, only make migration safer. Reported-by: Prasad Sodagudi <psodagud@codeaurora.org> Reported-by: Subash Abhinov Kasiviswanathan <subashab@codeaurora.org> Signed-off-by: Eric Dumazet <edumazet@google.com> Cc: Tom Herbert <therbert@google.com> Signed-off-by: David S. Miller <davem@davemloft.net> 16 January 2015, 06:02:42 UTC
57d737c Merge branch 'davinci_emac' Tony Lindgren says: ==================== Fixes for davinci_emac Here's a repost of the fixes for davinci_emac with patches updated for comments and acks collected. ==================== Signed-off-by: David S. Miller <davem@davemloft.net> 16 January 2015, 06:00:17 UTC
de39008 net: davinci_emac: Add support for emac on dm816x On dm816x we have two emac controllers with separate memory areas. Cc: Brian Hutchinson <b.hutchman@gmail.com> Cc: Felipe Balbi <balbi@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: David S. Miller <davem@davemloft.net> 16 January 2015, 06:00:03 UTC
a159432 net: davinci_emac: Fix ioremap for devices with MDIO within the EMAC address space Some devices like dm816x have the MDIO registers within the first EMAC instance address space. Let's fix the issue by allowing to pass an optional second IO range for the EMAC control register area. Cc: Brian Hutchinson <b.hutchman@gmail.com> Cc: Felipe Balbi <balbi@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: David S. Miller <davem@davemloft.net> 16 January 2015, 06:00:03 UTC
1d82ffa net: davinci_emac: Fix incomplete code for getting the phy from device tree Looks like the phy_id is never set up beyond getting the phandle. Note that we can remove the ifdef for phy_node as there is a stub for of_phy_connec() if CONFIG_OF is not set. Cc: Brian Hutchinson <b.hutchman@gmail.com> Cc: Felipe Balbi <balbi@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: David S. Miller <davem@davemloft.net> 16 January 2015, 06:00:03 UTC
0f53727 net: davinci_emac: Free clock after checking the frequency We only use clk_get() to get the frequency, the rest is done by the runtime PM calls. Let's free the clock too. Cc: Brian Hutchinson <b.hutchman@gmail.com> Cc: Felipe Balbi <balbi@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: David S. Miller <davem@davemloft.net> 16 January 2015, 06:00:03 UTC
b5133e7 net: davinci_emac: Fix runtime pm calls for davinci_emac Commit 3ba97381343b ("net: ethernet: davinci_emac: add pm_runtime support") added support for runtime PM, but it causes issues on omap3 related devices that actually gate the clocks: Unhandled fault: external abort on non-linefetch (0x1008) ... [<c04160f0>] (emac_dev_getnetstats) from [<c04d6a3c>] (dev_get_stats+0x78/0xc8) [<c04d6a3c>] (dev_get_stats) from [<c04e9ccc>] (rtnl_fill_ifinfo+0x3b8/0x938) [<c04e9ccc>] (rtnl_fill_ifinfo) from [<c04eade4>] (rtmsg_ifinfo+0x68/0xd8) [<c04eade4>] (rtmsg_ifinfo) from [<c04dd35c>] (register_netdevice+0x3a0/0x4ec) [<c04dd35c>] (register_netdevice) from [<c04dd4bc>] (register_netdev+0x14/0x24) [<c04dd4bc>] (register_netdev) from [<c041755c>] (davinci_emac_probe+0x408/0x5c8) [<c041755c>] (davinci_emac_probe) from [<c0396d78>] (platform_drv_probe+0x48/0xa4) Let's fix it by moving the pm_runtime_get() call earlier, and also add it to the emac_dev_getnetstats(). Also note that we want to use pm_runtime_get_sync() as we don't want to have deferred_resume happen. And let's also check the return value for pm_runtime_get_sync() as noted by Felipe Balbi <balbi@ti.com>. Cc: Brian Hutchinson <b.hutchman@gmail.com> Acked-by: Mark A. Greer <mgreer@animalcreek.com> Reviewed-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: David S. Miller <davem@davemloft.net> 16 January 2015, 06:00:03 UTC
cd2d6d3 net: davinci_emac: Fix hangs with interrupts On davinci_emac, we have pulse interrupts. This means that we need to clear the EOI bits when disabling interrupts as otherwise the interrupts keep happening. And we also need to not clear the EOI bits again when enabling the interrupts as otherwise we will get tons of: unexpected IRQ trap at vector 00 These errors almost certainly mean that the omap-intc.c is signaling a spurious interrupt with the reserved irq 127 as we've seen earlier on omap3. Let's fix the issue by clearing the EOI bits when disabling the interrupts. Let's also keep the comment for "Rx Threshold and Misc interrupts are not enabled" for both enable and disable so people are aware of this when potentially adding more support. Note that eventually we should handle the RX and TX interrupts separately like cpsw is now doing. However, so far I have not seen any issues with this based on my testing, so it seems to behave a little different compared to the cpsw that had a similar issue. Cc: Brian Hutchinson <b.hutchman@gmail.com> Reviewed-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: David S. Miller <davem@davemloft.net> 16 January 2015, 06:00:03 UTC
cb59670 Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/fuse Pull fuse fixes from Miklos Szeredi: "This fixes a regression in the latest fuse update plus a fix for a rather theoretical memory ordering issue" * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/fuse: fuse: add memory barrier to INIT fuse: fix LOOKUP vs INIT compat handling 16 January 2015, 01:58:16 UTC
back to top