Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
GIT fba69f042ad99f68c0268ef1c012f3199f898fac commit f5c16f29bf5e57ba4051fc7785ba7f035f798c71 Author: Tejun Heo <[email protected]> Date: Mon May 19 15:52:10 2014 -0400 sysfs: make sure read buffer is zeroed 13c589d5b0ac ("sysfs: use seq_file when reading regular files") switched sysfs from custom read implementation to seq_file to enable later transition to kernfs. After the change, the buffer passed to ->show() is acquired through seq_get_buf(); unfortunately, this introduces a subtle behavior change. Before the commit, the buffer passed to ->show() was always zero as it was allocated using get_zeroed_page(). Because seq_file doesn't clear buffers on allocation and neither does seq_get_buf(), after the commit, depending on the behavior of ->show(), we may end up exposing uninitialized data to userland thus possibly altering userland visible behavior and leaking information. Fix it by explicitly clearing the buffer. Signed-off-by: Tejun Heo <[email protected]> Reported-by: Ron <[email protected]> Fixes: 13c589d5b0ac ("sysfs: use seq_file when reading regular files") Cc: stable <[email protected]> # 3.13+ Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 3685f2516116c5f3b9d498d531955ad70216ad84 Author: Shawn Guo <[email protected]> Date: Sat May 17 20:46:01 2014 +0800 ahci: imx: PLL clock needs 100us to settle down The commit e783c51 (ahci: imx: software workaround for phy reset issue in resume) calls imx_sata_phy_reset() to reset phy immediately after SATA MPLL is enabled. It seems working fine mostly, but fails in some case as below. ... ahci-imx 2200000.sata: failed to reset phy: -110 ahci-imx: probe of 2200000.sata failed with error -110 After talking to the designer, we learnt that when enabling i.MX6Q SATA MPLL, we need to wait 100us for it to settle down for safety. Add this required delay to fix above failure. Signed-off-by: Shawn Guo <[email protected]> Tested-by: Fabio Estevam <[email protected]> Signed-off-by: Tejun Heo <[email protected]> commit d0b4cc4e32705ff00d90d32da7783c266c702c04 Author: Gavin Shan <[email protected]> Date: Mon May 19 13:06:46 2014 +1000 PCI: Wrong register used to check pending traffic The incorrect register offset is passed to pci_wait_for_pending(), which is caused by commit 157e876ffe ("PCI: Add pci_wait_for_pending() (refactor pci_wait_for_pending_transaction())"). Fixes: 157e876ffe ("PCI: Add pci_wait_for_pending() (refactor pci_wait_for_pending_transaction()) Signed-off-by: Gavin Shan <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Acked-by: Alex Williamson <[email protected]> CC: [email protected] # v3.14+ commit 1e1110c43b1cda9fe77fc4a04835e460550e6b3c Author: Mikulas Patocka <[email protected]> Date: Sat May 17 06:49:22 2014 -0400 target: fix memory leak on XCOPY On each processed XCOPY command, two "kmalloc-512" memory objects are leaked. These represent two allocations of struct xcopy_pt_cmd in target_core_xcopy.c. The reason for the memory leak is that the cmd_kref field is not initialized (thus, it is zero because the allocations were done with kzalloc). When we decrement zero kref in target_put_sess_cmd, the result is not zero, thus target_release_cmd_kref is not called. This patch fixes the bug by moving kref initialization from target_get_sess_cmd to transport_init_se_cmd (this function is called from target_core_xcopy.c, so it will correctly initialize cmd_kref). It can be easily verified that all code that calls target_get_sess_cmd also calls transport_init_se_cmd earlier, thus moving kref_init shouldn't introduce any new problems. Signed-off-by: Mikulas Patocka <[email protected]> Cc: [email protected] # 3.12+ Signed-off-by: Nicholas Bellinger <[email protected]> commit f9c6d4987b23e0a514464bae6771933a48e4cd01 Author: Theodore Ts'o <[email protected]> Date: Fri May 16 21:40:41 2014 -0400 random: fix BUG_ON caused by accounting simplification Commit ee1de406ba6eb1 ("random: simplify accounting logic") simplified things too much, in that it allows the following to trigger an overflow that results in a BUG_ON crash: dd if=/dev/urandom of=/dev/zero bs=67108707 count=1 Thanks to Peter Zihlstra for discovering the crash, and Hannes Frederic for analyizing the root cause. Signed-off-by: "Theodore Ts'o" <[email protected]> Reported-by: Peter Zijlstra <[email protected]> Reported-by: Hannes Frederic Sowa <[email protected]> Cc: Greg Price <[email protected]> commit d2c834abe2b39a2d5a6c38ef44de87c97cbb34b4 Author: Tuomas Tynkkynen <[email protected]> Date: Fri May 16 16:50:20 2014 +0300 clk: tegra: Fix wrong value written to PLLE_AUX The value written to PLLE_AUX was incorrect due to a wrong variable being used. Without this fix SATA does not work. Cc: [email protected] Signed-off-by: Tuomas Tynkkynen <[email protected]> Tested-by: Mikko Perttunen <[email protected]> Reviewed-by: Thierry Reding <[email protected]> Tested-by: Thierry Reding <[email protected]> Acked-by: Thierry Reding <[email protected]> Signed-off-by: Mike Turquette <[email protected]> [[email protected]: improved changelog] commit bb4e506565cfc0a2f534dfda1fb7ca5c26f7a604 Author: Jes Sorensen <[email protected]> Date: Fri May 16 22:59:18 2014 +0200 staging: rtl8723au: Do not reset wdev->iftype in netdev_close() wdev->ifdev should be set by .change_virtual_intf(). This solves the problem of WARN() messages on module unload. Signed-off-by: Jes Sorensen <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 07d1d29ee1e194b932328ad2dc1d40297062ab7f Author: Hans de Goede <[email protected]> Date: Fri May 16 21:10:41 2014 +0200 ACPI / video: Revert native brightness quirk for ThinkPad T530 Seems it helps some users, but causes issues for other users: https://bugzilla.redhat.com/show_bug.cgi?id=1089545 So lets drop it for now until we've figured out a better fix. Fixes: 43d949024425 (ACPI / video: Add use_native_backlight quirks for more systems) References: https://bugzilla.redhat.com/show_bug.cgi?id=1089545 Cc: All applicable <[email protected]> Signed-off-by: Hans de Goede <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]> commit be02f259fda66bcfc60ecd78a819e1ce28c8bfb9 Author: Jes Sorensen <[email protected]> Date: Fri May 16 10:05:04 2014 +0200 staging: rtl8723au: Use correct pipe type for USB interrupts Use a correct pipe type when filling un interrupt urbs. This should finally take care of the WARN() messages on the console when USB urbs are submitted. Signed-off-by: Jes Sorensen <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 4797ec2dc83a43be35bad56037d1b53db9e2b5d5 Author: Mark Salter <[email protected]> Date: Thu May 15 15:19:22 2014 +0100 arm64: fix pud_huge() for 2-level pagetables The following happens when trying to run a kvm guest on a kernel configured for 64k pages. This doesn't happen with 4k pages: BUG: failure at include/linux/mm.h:297/put_page_testzero()! Kernel panic - not syncing: BUG! CPU: 2 PID: 4228 Comm: qemu-system-aar Tainted: GF 3.13.0-0.rc7.31.sa2.k32v1.aarch64.debug #1 Call trace: [<fffffe0000096034>] dump_backtrace+0x0/0x16c [<fffffe00000961b4>] show_stack+0x14/0x1c [<fffffe000066e648>] dump_stack+0x84/0xb0 [<fffffe0000668678>] panic+0xf4/0x220 [<fffffe000018ec78>] free_reserved_area+0x0/0x110 [<fffffe000018edd8>] free_pages+0x50/0x88 [<fffffe00000a759c>] kvm_free_stage2_pgd+0x30/0x40 [<fffffe00000a5354>] kvm_arch_destroy_vm+0x18/0x44 [<fffffe00000a1854>] kvm_put_kvm+0xf0/0x184 [<fffffe00000a1938>] kvm_vm_release+0x10/0x1c [<fffffe00001edc1c>] __fput+0xb0/0x288 [<fffffe00001ede4c>] ____fput+0xc/0x14 [<fffffe00000d5a2c>] task_work_run+0xa8/0x11c [<fffffe0000095c14>] do_notify_resume+0x54/0x58 In arch/arm/kvm/mmu.c:unmap_range(), we end up doing an extra put_page() on the stage2 pgd which leads to the BUG in put_page_testzero(). This happens because a pud_huge() test in unmap_range() returns true when it should always be false with 2-level pages tables used by 64k pages. This patch removes support for huge puds if 2-level pagetables are being used. Signed-off-by: Mark Salter <[email protected]> [[email protected]: removed #ifndef around PUD_SIZE check] Signed-off-by: Catalin Marinas <[email protected]> Cc: <[email protected]> # v3.11+ commit dfc44f8030653b345fc6fb337558c3a07536823f Author: Leif Lindholm <[email protected]> Date: Thu Apr 17 18:42:00 2014 +0100 mips: dts: Fix missing device_type="memory" property in memory nodes A few platforms lack a 'device_type = "memory"' for their memory nodes, relying on an old ppc quirk in order to discover its memory. Add the missing data so that all parsing code can find memory nodes correctly. Signed-off-by: Leif Lindholm <[email protected]> Cc: [email protected] Cc: [email protected] Cc: Mark Rutland <[email protected]> Cc: <[email protected]> Acked-by: John Crispin <[email protected]> Signed-off-by: Grant Likely <[email protected]> commit bfaed5abad998bfc88a66e6e71c7b08dcf82f04e Author: Leif Lindholm <[email protected]> Date: Thu Apr 17 18:41:59 2014 +0100 arm: dts: Fix missing device_type="memory" for ste-ccu8540 The current .dts for ste-ccu8540 lacks a 'device_type = "memory"' for its memory node, relying on an old ppc quirk in order to discover its memory. Fix the data so that all parsing code can handle it correctly. Signed-off-by: Leif Lindholm <[email protected]> Acked-by: Lee Jones <[email protected]> Acked-by: Linus Walleij <[email protected]> Cc: [email protected] Cc: [email protected] Cc: Mark Rutland <[email protected]> Cc: <[email protected]> Signed-off-by: Grant Likely <[email protected]> commit 07b8dae38b09bcfede7e726f172e39b5ce8390d9 Author: Andy Grover <[email protected]> Date: Wed May 14 15:48:06 2014 -0700 target: Don't allow setting WC emulation if device doesn't support Just like for pSCSI, if the transport sets get_write_cache, then it is not valid to enable write cache emulation for it. Return an error. see https://bugzilla.redhat.com/show_bug.cgi?id=1082675 Reviewed-by: Chris Leech <[email protected]> Signed-off-by: Andy Grover <[email protected]> Cc: [email protected] # 3.10+ Signed-off-by: Nicholas Bellinger <[email protected]> commit 52d0aa7980cfee85c831b2969e659055395386d4 Author: Nicholas Bellinger <[email protected]> Date: Wed May 14 20:54:26 2014 +0000 iscsi-target: Disable Immediate + Unsolicited Data with ISER Protection This patch explicitly disables Immediate + Unsolicited Data for ISER connections during login in iscsi_login_zero_tsih_s2() when protection has been enabled for the session by the underlying hardware. This is currently required because protection / signature memory regions (MRs) expect T10 PI to occur on RDMA READs + RDMA WRITEs transfers, and not on a immediate data payload associated with ISCSI_OP_SCSI_CMD, or unsolicited data-out associated with a ISCSI_OP_SCSI_DATA_OUT. v2 changes: - Add TARGET_PROT_DOUT_INSERT check (Sagi) - Add pr_debug noisemaker (Sagi) - Add goto to avoid early return from MRDSL check (nab) Cc: Sagi Grimberg <[email protected]> Cc: Or Gerlitz <[email protected]> Signed-off-by: Nicholas Bellinger <[email protected]> commit ed8ec8f707ed4760c124d47b27c93df8ec5b1eba Author: Nicholas Bellinger <[email protected]> Date: Mon May 12 12:18:32 2014 -0700 tcm_fc: Fix free-after-use regression in ft_free_cmd This patch fixes a free-after-use regression in ft_free_cmd(), where ft_sess_put() is called with cmd->sess after percpu_ida_free() has already released the tag. Fix this bug by saving the ft_sess pointer ahead of percpu_ida_free(), and pass it directly to ft_sess_put(). The regression was originally introduced in v3.13-rc1 commit: commit 5f544cfac956971099e906f94568bc3fd1a7108a Author: Nicholas Bellinger <[email protected]> Date: Mon Sep 23 12:12:42 2013 -0700 tcm_fc: Convert to per-cpu command map pre-allocation of ft_cmd Reported-by: Jun Wu <[email protected]> Cc: Mark Rustad <[email protected]> Cc: Robert Love <[email protected]> Cc: <[email protected]> #3.13+ Signed-off-by: Nicholas Bellinger <[email protected]> commit 7cbfcc953789ff864c2bf8365a82a3fba4869649 Author: Nicholas Bellinger <[email protected]> Date: Thu May 1 13:44:56 2014 -0700 iscsi-target: Change BUG_ON to REJECT in iscsit_process_nop_out This patch changes an incorrect use of BUG_ON to instead generate a REJECT + PROTOCOL_ERROR in iscsit_process_nop_out() code. This case can occur with traditional TCP where a flood of zeros in the data stream can reach this block for what is presumed to be a NOP-OUT with a solicited reply, but without a valid iscsi_cmd pointer. This incorrect BUG_ON was introduced during the v3.11-rc timeframe with the following commit: commit 778de368964c5b7e8100cde9f549992d521e9c89 Author: Nicholas Bellinger <[email protected]> Date: Fri Jun 14 16:07:47 2013 -0700 iscsi/isert-target: Refactor ISCSI_OP_NOOP RX handling Reported-by: Arshad Hussain <[email protected]> Cc: [email protected] # 3.11+ Signed-off-by: Nicholas Bellinger <[email protected]> commit 14f4b54fe38f3a8f8392a50b951c8aa43b63687a Author: Sagi Grimberg <[email protected]> Date: Tue Apr 29 13:13:47 2014 +0300 Target/iscsi,iser: Avoid accepting transport connections during stop stage When the target is in stop stage, iSER transport initiates RDMA disconnects. The iSER initiator may wish to establish a new connection over the still existing network portal. In this case iSER transport should not accept and resume new RDMA connections. In order to learn that, iscsi_np is added with enabled flag so the iSER transport can check when deciding weather to accept and resume a new connection request. The iscsi_np is enabled after successful transport setup, and disabled before iscsi_np login threads are cleaned up. Signed-off-by: Sagi Grimberg <[email protected]> Cc: [email protected] # 3.10+ Signed-off-by: Nicholas Bellinger <[email protected]> commit 531b7bf4bd795d9a09eac92504322a472c010bc8 Author: Sagi Grimberg <[email protected]> Date: Tue Apr 29 13:13:45 2014 +0300 Target/iser: Fix iscsit_accept_np and rdma_cm racy flow RDMA CM and iSCSI target flows are asynchronous and completely uncorrelated. Relying on the fact that iscsi_accept_np will be called after CM connection request event and will wait for it is a mistake. When attempting to login to a few targets this flow is racy and unpredictable, but for parallel login to dozens of targets will race and hang every time. The correct synchronizing mechanism in this case is pending on a semaphore rather than a wait_for_event. We keep the pending interruptible for iscsi_np cleanup stage. (Squash patch to remove dead code into parent - nab) Reported-by: Slava Shwartsman <[email protected]> Signed-off-by: Sagi Grimberg <[email protected]> Cc: [email protected] # 3.10+ Signed-off-by: Nicholas Bellinger <[email protected]> commit 9fe63c88b1d59f1ce054d6948ccd3096496ecedb Author: Sagi Grimberg <[email protected]> Date: Tue Apr 29 13:13:44 2014 +0300 Target/iser: Fix wrong connection requests list addition Should be adding list_add_tail($new, $head) and not the other way around. Signed-off-by: Sagi Grimberg <[email protected]> Cc: [email protected] # 3.10+ Signed-off-by: Nicholas Bellinger <[email protected]> commit 448ba904160f9d8f69217c28a1692cee5afbff88 Author: Andy Grover <[email protected]> Date: Tue Apr 15 14:13:12 2014 -0700 target: Allow non-supporting backends to set pi_prot_type to 0 Userspace tools assume if a value is read from configfs, it is valid and will not cause an error if the same value is written back. The only valid value for pi_prot_type for backends not supporting DIF is 0, so allow this particular value to be set without returning an error. Reported-by: Krzysztof Chojnowski <[email protected]> Signed-off-by: Andy Grover <[email protected]> Reviewed-by: Sagi Grimberg <[email protected]> Cc: [email protected] # 3.14+ Signed-off-by: Nicholas Bellinger <[email protected]> commit c776cd89fc705fc8b5c2e5ad906bf5d791620fed Author: John David Anglin <[email protected]> Date: Sun May 11 18:40:50 2014 -0400 parisc: Improve LWS-CAS performance The attached change significantly improves the performance of the LWS-CAS code in syscall.S. This allows a number of packages to build (e.g., zeromq3, gtest and libxs) that previously failed because slow LWS-CAS performance under contention. In particular, interrupts taken while the lock was taken degraded performance significantly. The change does the following: 1) Disables interrupts around the CAS operation, and 2) Changes the loads and stores to use the ordered completer, "o", on PA 2.0. "o" and "ma" with a zero offset are equivalent. The latter is accepted on both PA 1.X and 2.0. The use of ordered loads and stores probably makes no difference on all existing hardware, but it seemed pedantically correct. In particular, the CAS operation must complete before LDCW lock is released. As written before, a processor could reorder the operations. I don't believe the period interrupts are disabled is long enough to significantly increase interrupt latency. For example, the TLB insert code is longer. Worst case is a memory fault in the CAS operation. Signed-off-by: John David Anglin <[email protected]> Cc: [email protected] # 3.13+ Signed-off-by: Helge Deller <[email protected]> commit fef47e2a2e1e75fe50a10f634a80f16808348cc6 Author: Helge Deller <[email protected]> Date: Mon May 5 18:07:12 2014 +0200 parisc: ratelimit userspace segfault printing Ratelimit printing of userspace segfaults and make it runtime configurable via the /proc/sys/debug/exception-trace variable. This should resolve syslog from growing way too fast and thus prevents possible system service attacks. Signed-off-by: Helge Deller <[email protected]> Cc: [email protected] # 3.13+ commit 93fa9d32670f5592c8e56abc9928fc194e1e72fc Author: Marcel Apfelbaum <[email protected]> Date: Thu May 15 12:42:49 2014 -0600 PCI: shpchp: Check bridge's secondary (not primary) bus speed When a new device is added below a hotplug bridge, the bridge's secondary bus speed and the device's bus speed must match. The shpchp driver previously checked the bridge's *primary* bus speed, not the secondary bus speed. This caused hot-add errors like: shpchp 0000:00:03.0: Speed of bus ff and adapter 0 mismatch Check the secondary bus speed instead. [bhelgaas: changelog] Link: https://bugzilla.kernel.org/show_bug.cgi?id=75251 Fixes: 3749c51ac6c1 ("PCI: Make current and maximum bus speeds part of the PCI core") Signed-off-by: Marcel Apfelbaum <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Acked-by: Michael S. Tsirkin <[email protected]> CC: [email protected] # v2.6.34+ commit 4c358e15553ed88bf2ddae422624624e1dd663d1 Author: Stephen Rothwell <[email protected]> Date: Thu May 15 14:44:30 2014 +1000 of: fix CONFIG_OF=n prototype of of_node_full_name() Make the CONFIG_OF=n prototpe of of_node_full_name() mateh the CONFIG_OF=y version. Fixes compile warnings like this: sound/soc/soc-core.c: In function 'soc_check_aux_dev': sound/soc/soc-core.c:1667:3: warning: passing argument 1 of 'of_node_full_name' discards 'const' qualifier from pointer target type [enabled by default] codecname = of_node_full_name(aux_dev->codec_of_node); when CONFIG_OF is not defined. Signed-off-by: Stephen Rothwell <[email protected]> Signed-off-by: Grant Likely <[email protected]> commit e95a2f7509f5219177d6821a0a8754f93892ca56 Author: Ville Syrjälä <[email protected]> Date: Thu May 8 15:09:19 2014 +0300 drm/i915: Increase WM memory latency values on SNB On SNB the BIOS provided WM memory latency values seem insufficient to handle high resolution displays. In this particular case the display mode was a 2560x1440@60Hz, which makes the pixel clock 241.5 MHz. It was empirically found that a memory latency value if 1.2 usec is enough to avoid underruns, whereas the BIOS provided value of 0.7 usec was clearly too low. Incidentally 1.2 usec is what the typical BIOS provided values are on IVB systems. Increase the WM memory latency values to at least 1.2 usec on SNB. Hopefully this won't have a significant effect on power consumption. v2: Increase the latency values regardless of the pixel clock Cc: Robert N <[email protected]> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=70254 Tested-by: Robert Navarro <[email protected]> Tested-by: Vitaly Minko <[email protected]> Cc: [email protected] Signed-off-by: Ville Syrjälä <[email protected]> Signed-off-by: Jani Nikula <[email protected]> commit 721e82c08c1afd6b47367b0e0c4a62140b0667f3 Author: Aaron Lu <[email protected]> Date: Mon May 12 16:55:45 2014 +0800 drm/i915: restore backlight precision when converting from ACPI When we set backlight on behalf of ACPI opregion, we will convert the backlight value in the 0-255 range defined in opregion to the actual hardware level. Commit 22505b82a2 (drm/i915: avoid brightness overflow when doing scale) is meant to fix the overflow problem when doing the conversion, but it also caused a problem that the converted hardware level doesn't quite represent the intended value: say user wants maximum backlight level(255 in opregion's range), then we will calculate the actual hardware level to be: level = freq / max * level, where freq is the hardware's max backlight level(937 on an user's box), and max and level are all 255. The converted value should be 937 but the above calculation will yield 765. To fix this issue, just use 64 bits to do the calculation to keep the precision and avoid overflow at the same time. Buglink: https://bugzilla.kernel.org/show_bug.cgi?id=72491 Reported-by: Nico Schottelius <[email protected]> Reviewed-by: Chris Wilson <[email protected]> Cc: [email protected] Signed-off-by: Aaron Lu <[email protected]> Signed-off-by: Jani Nikula <[email protected]> commit afba0b5a221c0dacbbdf3a778d539fbc90fc6191 Author: Chris Wilson <[email protected]> Date: Tue May 13 16:07:37 2014 +0100 drm/i915: Use the first mode if there is no preferred mode in the EDID This matches the algorithm used by earlier kernels when selecting the mode for the fbcon. And only if there is no modes at all, do we fall back to using the BIOS configuration. Seamless transition is still preserved (from the BIOS configuration to ours) so long as the BIOS has also chosen what we hope is the native configuration. Reported-by: Knut Petersen <[email protected]> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=78655 Reviewed-by: Jesse Barnes <[email protected]> Tested-by: Knut Petersen <[email protected]> Signed-off-by: Chris Wilson <[email protected]> [Jani: applied Chris' "Please imagine that I wrote this correctly."] Signed-off-by: Jani Nikula <[email protected]> commit f4cdbc21444a45d207a8dc175f44d2facfbd0845 Author: Jani Nikula <[email protected]> Date: Wed May 14 13:02:19 2014 +0300 drm/i915/dp: force eDP lane count to max available lanes on BDW There are certain BDW high res eDP machines that regressed due to commit 38aecea0ccbb909d635619cba22f1891e589b434 Author: Daniel Vetter <[email protected]> Date: Mon Mar 3 11:18:10 2014 +0100 drm/i915: reverse dp link param selection, prefer fast over wide again The commit lead to 2 lanes at 5.4 Gbps being used instead of 4 lanes at 2.7 Gbps on the affected machines. Link training succeeded for both, but the screen remained blank with the former config. Further investigation showed that 4 lanes at 5.4 Gbps worked also. The root cause for the blank screen using 2 lanes remains unknown, but apparently the driver for a certain other operating system by default uses the max available lanes. Follow suit on Broadwell eDP, for at least until we figure out what is going on. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76711 Reviewed-by: Daniel Vetter <[email protected]> Reviewed-by: Rodrigo Vivi <[email protected]> Tested-by: Rodrigo Vivi <[email protected]> Signed-off-by: Jani Nikula <[email protected]> commit fa81511bb0bbb2b1aace3695ce869da9762624ff Author: Linus Torvalds <[email protected]> Date: Wed May 14 16:33:54 2014 -0700 x86-64, modify_ldt: Make support for 16-bit segments a runtime option Checkin: b3b42ac2cbae x86-64, modify_ldt: Ban 16-bit segments on 64-bit kernels disabled 16-bit segments on 64-bit kernels due to an information leak. However, it does seem that people are genuinely using Wine to run old 16-bit Windows programs on Linux. A proper fix for this ("espfix64") is coming in the upcoming merge window, but as a temporary fix, create a sysctl to allow the administrator to re-enable support for 16-bit segments. It adds a "/proc/sys/abi/ldt16" sysctl that defaults to zero (off). If you hit this issue and care about your old Windows program more than you care about a kernel stack address information leak, you can do echo 1 > /proc/sys/abi/ldt16 as root (add it to your startup scripts), and you should be ok. The sysctl table is only added if you have COMPAT support enabled on x86-64, but I assume anybody who runs old windows binaries very much does that ;) Signed-off-by: H. Peter Anvin <[email protected]> Link: http://lkml.kernel.org/r/CA%2B55aFw9BPoD10U1LfHbOMpHWZkvJTkMcfCs9s3urPr1YyWBxw@mail.gmail.com Cc: <[email protected]> commit ffe6902b66aaa4ca6694bc19639259c16d84ddb1 Author: James Hogan <[email protected]> Date: Thu May 1 15:05:07 2014 +0100 asm-generic: remove _STK_LIM_MAX _STK_LIM_MAX could be used to override the RLIMIT_STACK hard limit from an arch's include/uapi/asm-generic/resource.h file, but is no longer used since both parisc and metag removed the override. Therefore remove it entirely, setting the hard RLIMIT_STACK limit to RLIM_INFINITY directly in include/asm-generic/resource.h. Signed-off-by: James Hogan <[email protected]> Cc: Arnd Bergmann <[email protected]> Cc: [email protected] Cc: Helge Deller <[email protected]> Cc: John David Anglin <[email protected]> commit c70458f50cd4271410aa75011f56ffabc0e2d34a Author: James Hogan <[email protected]> Date: Thu May 1 12:31:14 2014 +0100 metag: Remove _STK_LIM_MAX override Meta overrode _STK_LIM_MAX (the default RLIMIT_STACK hard limit) to 256MB, apparently in an attempt to prevent setup_arg_pages's STACK_GROWSUP code from choosing the maximum stack size of 1GB, which is far too large for Meta's limited virtual address space and hits a BUG_ON (stack_top is usually 0x3ffff000). However the commit "metag: Reduce maximum stack size to 256MB" reduces the absolute stack size limit to a safe value for metag. This allows the default _STK_LIM_MAX override to be removed, bringing the default behaviour in line with all other architectures. Parisc in particular recently removed their override of _STK_LIMT_MAX in commit e0d8898d76a7 (parisc: remove _STK_LIM_MAX override) since it subtly affects stack allocation semantics in userland. Meta's uapi/asm/resource.h can now be removed and switch to using generic-y. Suggested-by: Helge Deller <[email protected]> Signed-off-by: James Hogan <[email protected]> Cc: [email protected] Cc: John David Anglin <[email protected]> commit 042d27acb64924a0e8a43e972485913a32407beb Author: Helge Deller <[email protected]> Date: Wed Apr 30 23:26:02 2014 +0200 parisc,metag: Do not hardcode maximum userspace stack size This patch affects only architectures where the stack grows upwards (currently parisc and metag only). On those do not hardcode the maximum initial stack size to 1GB for 32-bit processes, but make it configurable via a config option. The main problem with the hardcoded stack size is, that we have two memory regions which grow upwards: stack and heap. To keep most of the memory available for heap in a flexmap memory layout, it makes no sense to hard allocate up to 1GB of the memory for stack which can't be used as heap then. This patch makes the stack size for 32-bit processes configurable and uses 80MB as default value which has been in use during the last few years on parisc and which hasn't showed any problems yet. Signed-off-by: Helge Deller <[email protected]> Signed-off-by: James Hogan <[email protected]> Cc: "James E.J. Bottomley" <[email protected]> Cc: [email protected] Cc: [email protected] Cc: John David Anglin <[email protected]> commit d71f290b4e98a39f49f2595a13be3b4d5ce8e1f1 Author: James Hogan <[email protected]> Date: Tue May 13 23:58:24 2014 +0100 metag: Reduce maximum stack size to 256MB Specify the maximum stack size for arches where the stack grows upward (parisc and metag) in asm/processor.h rather than hard coding in fs/exec.c so that metag can specify a smaller value of 256MB rather than 1GB. This fixes a BUG on metag if the RLIMIT_STACK hard limit is increased beyond a safe value by root. E.g. when starting a process after running "ulimit -H -s unlimited" it will then attempt to use a stack size of the maximum 1GB which is far too big for metag's limited user virtual address space (stack_top is usually 0x3ffff000): BUG: failure at fs/exec.c:589/shift_arg_pages()! Signed-off-by: James Hogan <[email protected]> Cc: Helge Deller <[email protected]> Cc: "James E.J. Bottomley" <[email protected]> Cc: [email protected] Cc: [email protected] Cc: John David Anglin <[email protected]> Cc: [email protected] # only needed for >= v3.9 (arch/metag) commit 2425ce84026c385b73ae72039f90d042d49e0394 Author: Mikulas Patocka <[email protected]> Date: Thu May 8 15:51:37 2014 -0400 metag: fix memory barriers Volatile access doesn't really imply the compiler barrier. Volatile access is only ordered with respect to other volatile accesses, it isn't ordered with respect to general memory accesses. Gcc may reorder memory accesses around volatile access, as we can see in this simple example (if we compile it with optimization, both increments of *b will be collapsed to just one): void fn(volatile int *a, long *b) { (*b)++; *a = 10; (*b)++; } Consequently, we need the compiler barrier after a write to the volatile variable, to make sure that the compiler doesn't reorder the volatile write with something else. Signed-off-by: Mikulas Patocka <[email protected]> Cc: [email protected] Acked-by: Peter Zijlstra <[email protected]> Signed-off-by: James Hogan <[email protected]> commit 4cdd2ad78098244c1bc9ec4374ea1c225fd1cd6f Author: Mike Snitzer <[email protected]> Date: Tue May 13 13:49:39 2014 -0400 dm mpath: fix lock order inconsistency in multipath_ioctl Commit 3e9f1be1b40 ("dm mpath: remove process_queued_ios()") did not consistently take the multipath device's spinlock (m->lock) before calling dm_table_run_md_queue_async() -- which takes the q->queue_lock. Found with code inspection using hint from reported lockdep warning. Reported-by: Bart Van Assche <[email protected]> Signed-off-by: Mike Snitzer <[email protected]> commit 85ad643b7e7e52d37620fb272a9fd577a8095647 Author: Joe Thornber <[email protected]> Date: Fri May 9 15:59:38 2014 +0100 dm thin: add timeout to stop out-of-data-space mode holding IO forever If the pool runs out of data space, dm-thin can be configured to either error IOs that would trigger provisioning, or hold those IOs until the pool is resized. Unfortunately, holding IOs until the pool is resized can result in a cascade of tasks hitting the hung_task_timeout, which may render the system unavailable. Add a fixed timeout so IOs can only be held for a maximum of 60 seconds. If LVM is going to resize a thin-pool that is out of data space it needs to be prompt about it. Signed-off-by: Joe Thornber <[email protected]> Signed-off-by: Mike Snitzer <[email protected]> Cc: [email protected] # 3.14+ commit 8d07e8a5f5bc7b90f755d9b427ea930024f4c986 Author: Joe Thornber <[email protected]> Date: Tue May 6 16:28:14 2014 +0100 dm thin: allow metadata commit if pool is in PM_OUT_OF_DATA_SPACE mode Commit 3e1a0699 ("dm thin: fix out of data space handling") introduced a regression in the metadata commit() method by returning an error if the pool is in PM_OUT_OF_DATA_SPACE mode. This oversight caused a thin device to return errors even if the default queue_if_no_space ENOSPC handling mode is used. Fix commit() to only fail if pool is in PM_READ_ONLY or PM_FAIL mode. Reported-by: [email protected] Signed-off-by: Joe Thornber <[email protected]> Signed-off-by: Mike Snitzer <[email protected]> Cc: [email protected] # 3.14+ commit 610f2de3559c383caf8fbbf91e9968102dff7ca0 Author: Mikulas Patocka <[email protected]> Date: Thu Feb 20 18:01:01 2014 -0500 dm crypt: fix cpu hotplug crash by removing per-cpu structure The DM crypt target used per-cpu structures to hold pointers to a ablkcipher_request structure. The code assumed that the work item keeps executing on a single CPU, so it didn't use synchronization when accessing this structure. If a CPU is disabled by writing 0 to /sys/devices/system/cpu/cpu*/online, the work item could be moved to another CPU. This causes dm-crypt crashes, like the following, because the code starts using an incorrect ablkcipher_request: smpboot: CPU 7 is now offline BUG: unable to handle kernel NULL pointer dereference at 0000000000000130 IP: [<ffffffffa1862b3d>] crypt_convert+0x12d/0x3c0 [dm_crypt] ... Call Trace: [<ffffffffa1864415>] ? kcryptd_crypt+0x305/0x470 [dm_crypt] [<ffffffff81062060>] ? finish_task_switch+0x40/0xc0 [<ffffffff81052a28>] ? process_one_work+0x168/0x470 [<ffffffff8105366b>] ? worker_thread+0x10b/0x390 [<ffffffff81053560>] ? manage_workers.isra.26+0x290/0x290 [<ffffffff81058d9f>] ? kthread+0xaf/0xc0 [<ffffffff81058cf0>] ? kthread_create_on_node+0x120/0x120 [<ffffffff813464ac>] ? ret_from_fork+0x7c/0xb0 [<ffffffff81058cf0>] ? kthread_create_on_node+0x120/0x120 Fix this bug by removing the per-cpu definition. The structure ablkcipher_request is accessed via a pointer from convert_context. Consequently, if the work item is rescheduled to a different CPU, the thread still uses the same ablkcipher_request. This change may undermine performance improvements intended by commit c0297721 ("dm crypt: scale to multiple cpus") on select hardware. In practice no performance difference was observed on recent hardware. But regardless, correctness is more important than performance. Signed-off-by: Mikulas Patocka <[email protected]> Signed-off-by: Mike Snitzer <[email protected]> Cc: [email protected] commit d7653964c590ba846aa11a8f6edf409773cbc492 Author: Wolfram Sang <[email protected]> Date: Mon May 5 18:36:21 2014 +0200 i2c: rcar: bail out on zero length transfers This hardware does not support zero length transfers. Instead, the driver does one (random) byte transfers currently with undefined results for the slaves. We now bail out. Signed-off-by: Wolfram Sang <[email protected]> Signed-off-by: Wolfram Sang <[email protected]> Cc: [email protected] commit fa01d096bfcfd89398b1f3a3f91805dab76f7fe5 Author: Andy Gross <[email protected]> Date: Fri May 2 20:54:29 2014 -0500 i2c: qup: Fix pm_runtime_get_sync usage This patch corrects the error check on the call to pm_runtime_get_sync. Signed-off-by: Andy Gross <[email protected]> Reviewed-by: Ivan T. Ivanov <[email protected]> Acked-by: Bjorn Andersson <[email protected]> Signed-off-by: Wolfram Sang <[email protected]> commit ce78cc071f5f541480e381cc0241d37590041a9d Author: Olof Johansson <[email protected]> Date: Fri Apr 11 15:19:41 2014 -0700 i2c: s3c2410: resume race fix Don't unmark the device as suspended until after it's been re-setup. The main race would be w.r.t. an i2c driver that gets resumed at the same time (asyncronously), that is allowed to do a transfer since suspended is set to 0 before reinit, but really should have seen the -EIO return instead. Signed-off-by: Olof Johansson <[email protected]> Signed-off-by: Doug Anderson <[email protected]> Acked-by: Kukjin Kim <[email protected]> Signed-off-by: Wolfram Sang <[email protected]> Cc: [email protected] commit 37e5eb0bae7bb4d98c2153c3c3400b5c00c3cad1 Author: Ulf Hansson <[email protected]> Date: Thu Apr 10 16:19:29 2014 +0200 i2c: nomadik: Don't use IS_ERR for devm_ioremap devm_ioremap() returns NULL on error, not an error. Signed-off-by: Ulf Hansson <[email protected]> Acked-by: Linus Walleij <[email protected]> Signed-off-by: Wolfram Sang <[email protected]> Cc: [email protected] commit 47bb27e78867997040a228328f2a631c3c7f2c82 Author: Du, Wenkai <[email protected]> Date: Thu Apr 10 23:03:19 2014 +0000 i2c: designware: Mask all interrupts during i2c controller enable There have been "i2c_designware 80860F41:00: controller timed out" errors on a number of Baytrail platforms. The issue is caused by incorrect value in Interrupt Mask Register (DW_IC_INTR_MASK) when i2c core is being enabled. This causes call to __i2c_dw_enable() to immediately start the transfer which leads to timeout. There are 3 failure modes observed: 1. Failure in S0 to S3 resume path The default value after reset for DW_IC_INTR_MASK is 0x8ff. When we start the first transaction after resuming from system sleep, TX_EMPTY interrupt is already unmasked because of the hardware default. 2. Failure in normal operational path This failure happens rarely and is hard to reproduce. Debug trace showed that DW_IC_INTR_MASK had value of 0x254 when failure occurred, which meant TX_EMPTY was unmasked. 3. Failure in S3 to S0 suspend path This failure also happens rarely and is hard to reproduce. Adding debug trace that read DW_IC_INTR_MASK made this failure not reproducible. But from ISR call trace we could conclude TX_EMPTY was unmasked when problem occurred. The patch masks all interrupts before the controller is enabled to resolve the faulty DW_IC_INTR_MASK conditions. Signed-off-by: Wenkai Du <[email protected]> Acked-by: Mika Westerberg <[email protected]> [wsa: improved the comment and removed typo in commit msg] Signed-off-by: Wolfram Sang <[email protected]> Cc: [email protected] commit 7bb394094080a26de06efcd6a870cb2ba21cfb16 Author: Steven J. Hill <[email protected]> Date: Thu Apr 10 14:06:17 2014 -0500 MIPS: mm: Fix broken microMIPS kernel regression. Commit f4ae17aa0f2122b52f642985b46210a1f2eceb0a [MIPS: mm: Use scratch for PGD when !CONFIG_MIPS_PGD_C0_CONTEXT] broke microMIPS kernel builds. This patch refactors that code similar to what was done for the 'clear_page' and 'copy_page' functions. Signed-off-by: Steven J. Hill <[email protected]> Cc: [email protected] Patchwork: https://patchwork.linux-mips.org/patch/6744/ Signed-off-by: Ralf Baechle <[email protected]> commit 665ebe926e7b714369b5329d48745bfef17db512 Author: Dan Carpenter <[email protected]> Date: Wed May 14 16:32:21 2014 +0300 ALSA: sb_mixer: missing return statement The if condition here was supposed to return on error but the return statement is missing. The effect is that the ->mixername is set to "???" instead of "DT019X". Signed-off-by: Dan Carpenter <[email protected]> Signed-off-by: Takashi Iwai <[email protected]> commit 582da6527da30f6e21a95c9f3f2810d46a8f406e Author: Thomas Petazzoni <[email protected]> Date: Wed May 14 13:36:36 2014 +0200 of: make of_update_property() usable earlier in the boot process Commit 75b57ecf9d1d1e17d099ab13b8f48e6e038676be ('of: Make device nodes kobjects so they show up in sysfs') has turned Device Tree nodes in kobjects and added a sysfs based representation for Device Tree nodes. Since the sysfs logic is only available after the execution of a core_initcall(), the patch took precautions in of_add_property() and of_remove_property() to not do any sysfs related manipulation early in the boot process. However, it forgot to do the same for of_update_property(), which if used early in the boot process (before core_initcalls have been called), tries to call sysfs_remove_bin_file(), and crashes: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 0 at /home/thomas/projets/linux-2.6/fs/kernfs/dir.c:1216 kernfs_remove_by_name_ns+0x80/0x88() kernfs: can not remove '(null)', no directory Modules linked in: CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.15.0-rc1-00127-g1d7e7b2-dirty #423 [<c0014910>] (unwind_backtrace) from [<c00110ec>] (show_stack+0x10/0x14) [<c00110ec>] (show_stack) from [<c04c84b8>] (dump_stack+0x84/0x94) [<c04c84b8>] (dump_stack) from [<c001d8c0>] (warn_slowpath_common+0x6c/0x88) [<c001d8c0>] (warn_slowpath_common) from [<c001d90c>] (warn_slowpath_fmt+0x30/0x40) [<c001d90c>] (warn_slowpath_fmt) from [<c0104468>] (kernfs_remove_by_name_ns+0x80/0x88) [<c0104468>] (kernfs_remove_by_name_ns) from [<c0394d98>] (of_update_property+0xc0/0xf0) [<c0394d98>] (of_update_property) from [<c0647248>] (mvebu_timer_and_clk_init+0xfc/0x194) [<c0647248>] (mvebu_timer_and_clk_init) from [<c0640934>] (start_kernel+0x218/0x350) [<c0640934>] (start_kernel) from [<00008070>] (0x8070) ---[ end trace 3406ff24bd97382e ]--- Unable to handle kernel NULL pointer dereference at virtual address 0000003c pgd = c0004000 [0000003c] *pgd=00000000 Internal error: Oops: 5 [#1] SMP ARM Modules linked in: CPU: 0 PID: 0 Comm: swapper/0 Tainted: G W 3.15.0-rc1-00127-g1d7e7b2-dirty #423 task: c10ad4d8 ti: c10a2000 task.ti: c10a2000 PC is at kernfs_find_ns+0x8/0xf0 LR is at kernfs_find_and_get_ns+0x30/0x48 pc : [<c0103834>] lr : [<c010394c>] psr: 600001d3 sp : c10a3f34 ip : 00000073 fp : 00000000 r10: 00000000 r9 : cfffc240 r8 : cfdf2980 r7 : cf812c00 r6 : 00000000 r5 : 00000000 r4 : c10b45e0 r3 : c10ad4d8 r2 : 00000000 r1 : cf812c00 r0 : 00000000 Flags: nZCv IRQs off FIQs off Mode SVC_32 ISA ARM Segment kernel Control: 10c53c7d Table: 0000404a DAC: 00000015 Process swapper/0 (pid: 0, stack limit = 0xc10a2240) Stack: (0xc10a3f34 to 0xc10a4000) 3f20: c10b45e0 00000000 00000000 3f40: cf812c00 c010394c 00000063 cf812c00 00000001 cf812c00 cfdf29ac c03932cc 3f60: 00000063 cf812bc0 cfdf29ac cf812c00 ffffffff c03943f8 cfdf2980 c0104468 3f80: cfdf2a04 cfdf2980 cf812bc0 c06634b0 c10aa3c0 c0394da4 c10f74dc cfdf2980 3fa0: cf812bc0 c0647248 c10aa3c0 ffffffff c10de940 c10aa3c0 ffffffff c0640934 3fc0: ffffffff ffffffff c06404ec 00000000 00000000 c06634b0 00000000 10c53c7d 3fe0: c10aa434 c06634ac c10ae4c8 0000406a 414fc091 00008070 00000000 00000000 [<c0103834>] (kernfs_find_ns) from [<00000001>] (0x1) Code: e5c89001 eaffffcf e92d40f0 e1a06002 (e1d023bc) ---[ end trace 3406ff24bd97382f ]--- Kernel panic - not syncing: Attempted to kill the idle task! ---[ end Kernel panic - not syncing: Attempted to kill the idle task! To fix this problem, we simply skip the sysfs related calls in of_update_property(), and rely on of_init() to fix up things when it will be called, exactly as is done in of_add_property() and of_remove_property(). Signed-off-by: Thomas Petazzoni <[email protected]> Fixes: 75b57ecf9d1d ("of: Make device nodes kobjects so they show up in sysfs") Signed-off-by: Grant Likely <[email protected]> commit f2d0801f00b7aff0ac6b3666cbcdab499267418a Author: Markos Chandras <[email protected]> Date: Tue Apr 22 15:40:36 2014 +0100 MIPS: Add new AUDIT_ARCH token for the N32 ABI on MIPS64 A MIPS64 kernel may support ELF files for all 3 MIPS ABIs (O32, N32, N64). Furthermore, the AUDIT_ARCH_MIPS{,EL}64 token does not provide enough information about the ABI for the 64-bit process. As a result of which, userland needs to use complex seccomp filters to decide whether a syscall belongs to the o32 or n32 or n64 ABI. Therefore, a new arch token for MIPS64/n32 is added so it can be used by seccomp to explicitely set syscall filters for this ABI. Signed-off-by: Markos Chandras <[email protected]> Acked-by: Eric Paris <[email protected]> Acked-by: Paul Moore <[email protected]> Cc: Andy Lutomirski <[email protected]> Cc: Ralf Baechle <[email protected]> Cc: Andy Lutomirski <[email protected]> Cc: [email protected] Link: http://sourceforge.net/p/libseccomp/mailman/message/32239040/ Patchwork: https://patchwork.linux-mips.org/patch/6818/ Signed-off-by: Ralf Baechle <[email protected]> commit 9844f5462392b53824e8b86726e7c33b5ecbb676 Author: Anthony Iliopoulos <[email protected]> Date: Wed May 14 11:29:48 2014 +0200 x86, mm, hugetlb: Add missing TLB page invalidation for hugetlb_cow() The invalidation is required in order to maintain proper semantics under CoW conditions. In scenarios where a process clones several threads, a thread operating on a core whose DTLB entry for a particular hugepage has not been invalidated, will be reading from the hugepage that belongs to the forked child process, even after hugetlb_cow(). The thread will not see the updated page as long as the stale DTLB entry remains cached, the thread attempts to write into the page, the child process exits, or the thread gets migrated to a different processor. Signed-off-by: Anthony Iliopoulos <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Suggested-by: Shay Goikhman <[email protected]> Acked-by: Dave Hansen <[email protected]> Signed-off-by: H. Peter Anvin <[email protected]> Cc: <[email protected]> # v2.6.16+ (!) commit 97d9d23dda6f37d90aefeec4ed619d52df525382 Author: Guennadi Liakhovetski <[email protected]> Date: Sat Apr 26 12:51:31 2014 -0300 [media] V4L2: fix VIDIOC_CREATE_BUFS in 64- / 32-bit compatibility mode If a struct contains 64-bit fields, it is aligned on 64-bit boundaries within containing structs in 64-bit compilations. This is the case with struct v4l2_window, which contains pointers and is embedded into struct v4l2_format, and that one is embedded into struct v4l2_create_buffers. Unlike some other structs, used as a part of the kernel ABI as ioctl() arguments, that are packed, these structs aren't packed. This isn't a problem per se, but the ioctl-compat code for VIDIOC_CREATE_BUFS contains a bug, that triggers in such 64-bit builds. That code wrongly assumes, that in struct v4l2_create_buffers, struct v4l2_format immediately follows the __u32 memory field, which in fact isn't the case. This bug wasn't visible until now, because until recently hardly any applications used this ioctl() and mostly embedded 32-bit only drivers implemented it. This is changing now with addition of this ioctl() to some USB drivers, e.g. UVC. This patch fixes the bug by copying parts of struct v4l2_create_buffers separately. Signed-off-by: Guennadi Liakhovetski <[email protected]> Acked-by: Laurent Pinchart <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]> Cc: [email protected] commit cfece5857ca51d1dcdb157017aba226f594e9dcf Author: Guennadi Liakhovetski <[email protected]> Date: Mon Apr 14 10:49:34 2014 -0300 [media] V4L2: ov7670: fix a wrong index, potentially Oopsing the kernel from user-space Commit 75e2bdad8901a0b599e01a96229be922eef1e488 "ov7670: allow configuration of image size, clock speed, and I/O method" uses a wrong index to iterate an array. Apart from being wrong, it also uses an unchecked value from user-space, which can cause access to unmapped memory in the kernel, triggered by a normal desktop user with rights to use V4L2 devices. Signed-off-by: Guennadi Liakhovetski <[email protected]> Acked-by: Jonathan Corbet <[email protected]> Cc: [email protected] Signed-off-by: Mauro Carvalho Chehab <[email protected]> commit 2ed9fd28c2884e9f41c133f86a7e377d7c0a96bf Author: Jason Cooper <[email protected]> Date: Tue May 13 18:47:01 2014 +0000 MAINTAINERS: Add co-maintainer for drivers/irqchip Thomas Gleixner has asked me to assist with the review and merging of patches for the irqchip subsystem. Signed-off-by: Jason Cooper <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Thomas Gleixner <[email protected]> commit 44330ab516c15dda8a1e660eeaf0003f84e43e3f Author: Charles Keepax <[email protected]> Date: Tue May 13 13:45:15 2014 +0100 ASoC: wm8962: Update register CLASS_D_CONTROL_1 to be non-volatile The register CLASS_D_CONTROL_1 is marked as volatile because it contains a bit, DAC_MUTE, which is also mirrored in the ADC_DAC_CONTROL_1 register. This causes problems for the "Speaker Switch" control, which will report an error if the CODEC is suspended because it relies on a volatile register. To resolve this issue mark CLASS_D_CONTROL_1 as non-volatile and manually keep the register cache in sync by updating both bits when changing the mute status. Reported-by: Shawn Guo <[email protected]> Signed-off-by: Charles Keepax <[email protected]> Tested-by: Shawn Guo <[email protected]> Signed-off-by: Mark Brown <[email protected]> Cc: [email protected] commit cffd6665f57ed18f4be9185c4330c8c98c22e201 Author: Jarkko Nikula <[email protected]> Date: Tue May 13 15:46:06 2014 +0300 ASoC: Intel: Fix Baytrail SST DSP firmware loading Commit 10df350977b1 ("ASoC: Intel: Fix Audio DSP usage when IOMMU is enabled.") caused following regression in Baytrail SST: baytrail-pcm-audio baytrail-pcm-audio: error: DMA alloc failed baytrail-pcm-audio baytrail-pcm-audio: error: failed to load firmware Fix this by calling dma_coerce_mask_and_coherent() in sst_byt_init() with the same dma_dev device what is now used in sst_fw_new() when allocating the DMA buffer. Signed-off-by: Jarkko Nikula <[email protected]> Signed-off-by: Mark Brown <[email protected]> commit 367f0b50e502d2c384277ba2ed43b04add2b8b6f Author: Ralf Baechle <[email protected]> Date: Tue May 13 17:56:41 2014 +0200 MIPS: Wire up renameat2 syscall. Signed-off-by: Ralf Baechle <[email protected]> commit d40a63c45b506b0681918d7c62a15cc9d48c8681 Author: Dirk Brandewie <[email protected]> Date: Thu May 8 12:57:24 2014 -0700 intel_pstate: remove setting P state to MAX on init Setting the P state of the core to max at init time is a hold over from early implementation of intel_pstate where intel_pstate disabled cpufreq and loaded VERY early in the boot sequence. This was to ensure that intel_pstate did not affect boot time. This in not needed now that intel_pstate is a cpufreq driver. Removing this covers the case where a CPU has gone through a manual CPU offline/online cycle and the P state is set to MAX on init and the CPU immediately goes idle. Due to HW coordination the P state request on the idle CPU will drag all cores to MAX P state until the load is reevaluated when to core goes non-idle. Reported-by: Patrick Marlier <[email protected]> Signed-off-by: Dirk Brandewie <[email protected]> Cc: 3.14+ <[email protected]> # 3.14+ Signed-off-by: Rafael J. Wysocki <[email protected]> commit 36e9d2ebcc15d029b33f42a36146ab5a5bcfcfe7 Author: Tejun Heo <[email protected]> Date: Tue May 13 11:28:30 2014 -0400 cgroup: fix rcu_read_lock() leak in update_if_frozen() While updating cgroup_freezer locking, 68fafb77d827 ("cgroup_freezer: replace freezer->lock with freezer_mutex") introduced a bug in update_if_frozen() where it returns with rcu_read_lock() held. Fix it by adding rcu_read_unlock() before returning. Signed-off-by: Tejun Heo <[email protected]> Reported-by: kbuild test robot <[email protected]> commit e5ced8ebb10c20a3b349bd798b69ccabd3b25d21 Author: Tejun Heo <[email protected]> Date: Wed May 7 21:31:17 2014 -0400 cgroup_freezer: replace freezer->lock with freezer_mutex After 96d365e0b86e ("cgroup: make css_set_lock a rwsem and rename it to css_set_rwsem"), css task iterators requires sleepable context as it may block on css_set_rwsem. I missed that cgroup_freezer was iterating tasks under IRQ-safe spinlock freezer->lock. This leads to errors like the following on freezer state reads and transitions. BUG: sleeping function called from invalid context at /work /os/work/kernel/locking/rwsem.c:20 in_atomic(): 0, irqs_disabled(): 0, pid: 462, name: bash 5 locks held by bash/462: #0: (sb_writers#7){.+.+.+}, at: [<ffffffff811f0843>] vfs_write+0x1a3/0x1c0 #1: (&of->mutex){+.+.+.}, at: [<ffffffff8126d78b>] kernfs_fop_write+0xbb/0x170 #2: (s_active#70){.+.+.+}, at: [<ffffffff8126d793>] kernfs_fop_write+0xc3/0x170 #3: (freezer_mutex){+.+...}, at: [<ffffffff81135981>] freezer_write+0x61/0x1e0 #4: (rcu_read_lock){......}, at: [<ffffffff81135973>] freezer_write+0x53/0x1e0 Preemption disabled at:[<ffffffff81104404>] console_unlock+0x1e4/0x460 CPU: 3 PID: 462 Comm: bash Not tainted 3.15.0-rc1-work+ #10 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 ffff88000916a6d0 ffff88000e0a3da0 ffffffff81cf8c96 0000000000000000 ffff88000e0a3dc8 ffffffff810cf4f2 ffffffff82388040 ffff880013aaf740 0000000000000002 ffff88000e0a3de8 ffffffff81d05974 0000000000000246 Call Trace: [<ffffffff81cf8c96>] dump_stack+0x4e/0x7a [<ffffffff810cf4f2>] __might_sleep+0x162/0x260 [<ffffffff81d05974>] down_read+0x24/0x60 [<ffffffff81133e87>] css_task_iter_start+0x27/0x70 [<ffffffff8113584d>] freezer_apply_state+0x5d/0x130 [<ffffffff81135a16>] freezer_write+0xf6/0x1e0 [<ffffffff8112eb88>] cgroup_file_write+0xd8/0x230 [<ffffffff8126d7b7>] kernfs_fop_write+0xe7/0x170 [<ffffffff811f0756>] vfs_write+0xb6/0x1c0 [<ffffffff811f121d>] SyS_write+0x4d/0xc0 [<ffffffff81d08292>] system_call_fastpath+0x16/0x1b freezer->lock used to be used in hot paths but that time is long gone and there's no reason for the lock to be IRQ-safe spinlock or even per-cgroup. In fact, given the fact that a cgroup may contain large number of tasks, it's not a good idea to iterate over them while holding IRQ-safe spinlock. Let's simplify locking by replacing per-cgroup freezer->lock with global freezer_mutex. This also makes the comments explaining the intricacies of policy inheritance and the locking around it as the states are protected by a common mutex. The conversion is mostly straight-forward. The followings are worth mentioning. * freezer_css_online() no longer needs double locking. * freezer_attach() now performs propagation simply while holding freezer_mutex. update_if_frozen() race no longer exists and the comment is removed. * freezer_fork() now tests whether the task is in root cgroup using the new task_css_is_root() without doing rcu_read_lock/unlock(). If not, it grabs freezer_mutex and performs the operation. * freezer_read() and freezer_change_state() grab freezer_mutex across the whole operation and pin the css while iterating so that each descendant processing happens in sleepable context. Fixes: 96d365e0b86e ("cgroup: make css_set_lock a rwsem and rename it to css_set_rwsem") Signed-off-by: Tejun Heo <[email protected]> Acked-by: Li Zefan <[email protected]> commit 5024ae29cd285ce9e736776414da645d3a91828c Author: Tejun Heo <[email protected]> Date: Wed May 7 21:31:17 2014 -0400 cgroup: introduce task_css_is_root() Determining the css of a task usually requires RCU read lock as that's the only thing which keeps the returned css accessible till its reference is acquired; however, testing whether a task belongs to the root can be performed without dereferencing the returned css by comparing the returned pointer against the root one in init_css_set[] which never changes. Implement task_css_is_root() which can be invoked in any context. This will be used by the scheduled cgroup_freezer change. v2: cgroup no longer supports modular controllers. No need to export init_css_set. Pointed out by Li. Signed-off-by: Tejun Heo <[email protected]> Acked-by: Li Zefan <[email protected]> commit 85dbd5801f62b66e2aa7826aaefcaebead44c8a6 Author: Lv Zheng <[email protected]> Date: Tue May 13 16:50:30 2014 +0800 ACPICA: Tables: Restore old behavor to favor 32-bit FADT addresses. We need to find a smarter way to switch to 64-bit FADT addresses according to the bug report. This patch reverts Linux to the original behavior. Fixes: 0249ed2444d6 (ACPICA: Add option to favor 32-bit FADT addresses.) References: https://bugzilla.kernel.org/show_bug.cgi?id=74021 Reported-and-tested-by: Oswald Buddenhagen <[email protected]> Signed-off-by: Lv Zheng <[email protected]> Cc: 3.14+ <[email protected]> # 3.14+ Signed-off-by: Rafael J. Wysocki <[email protected]> commit 5ff365fb6aed4c7ee5aae7b0239ce0b514aefabc Author: Aaron Lu <[email protected]> Date: Tue May 13 09:51:50 2014 +0800 ACPI / video: correct DMI tag for Dell Inspiron 7520 The DMI tag used to identify Dell Inspiron 7520 should be product name instead of product version. Fixes: 0e9f81d3b7cd (ACPI / video: Add systems that should favour native backlight interface) Reported-and-tested-by: Téo Mazars <[email protected]> References: https://bugzilla.redhat.com/show_bug.cgi?id=909552 Cc: All applicable <[email protected]> Signed-off-by: Aaron Lu <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]> commit 555724a831b4a146e7bdf16ecc989cda032b076d Author: Tejun Heo <[email protected]> Date: Mon May 12 13:56:27 2014 -0400 kernfs, sysfs, cgroup: restrict extra perm check on open to sysfs The kernfs open method - kernfs_fop_open() - inherited extra permission checks from sysfs. While the vfs layer allows ignoring the read/write permissions checks if the issuer has CAP_DAC_OVERRIDE, sysfs explicitly denied open regardless of the cap if the file doesn't have any of the UGO perms of the requested access or doesn't implement the requested operation. It can be debated whether this was a good idea or not but the behavior is too subtle and dangerous to change at this point. After cgroup got converted to kernfs, this extra perm check also got applied to cgroup breaking libcgroup which opens write-only files with O_RDWR as root. This patch gates the extra open permission check with a new flag KERNFS_ROOT_EXTRA_OPEN_PERM_CHECK and enables it for sysfs. For sysfs, nothing changes. For cgroup, root now can perform any operation regardless of the permissions as it was before kernfs conversion. Note that kernfs still fails unimplemented operations with -EINVAL. While at it, add comments explaining KERNFS_ROOT flags. Signed-off-by: Tejun Heo <[email protected]> Reported-by: Andrey Wagin <[email protected]> Tested-by: Andrey Wagin <[email protected]> Cc: Li Zefan <[email protected]> References: http://lkml.kernel.org/g/CANaxB-xUm3rJ-Cbp72q-rQJO5mZe1qK6qXsQM=vh0U8upJ44+A@mail.gmail.com Fixes: 2bd59d48ebfb ("cgroup: convert to kernfs") Signed-off-by: Greg Kroah-Hartman <[email protected]> commit 7189eb9b8f7962474956196c301676470542f253 Author: Mengdong Lin <[email protected]> Date: Tue May 13 16:57:08 2014 +0800 ALSA: hda - mask buggy stream DMA0 for Broadwell display controller Broadwell display controller has 3 stream DMA engines. DMA0 cannot update DMA postion buffer properly while DMA1 and DMA2 can work well. So this patch masks the buggy DMA0 by keeping it as opened. This is a tentative workaround, so keep the change small as Takashi suggested. Signed-off-by: Mengdong Lin <[email protected]> Signed-off-by: Takashi Iwai <[email protected]> commit ec5fe98886b686f065ef29d8dee1b3ca66f5fd48 Author: Aaron Plattner <[email protected]> Date: Mon May 12 20:05:02 2014 -0700 ALSA: hda - Add new GPU codec ID to snd-hda Vendor ID 0x10de0071 is used by a yet-to-be-named GPU chip. Signed-off-by: Aaron Plattner <[email protected]> Signed-off-by: Takashi Iwai <[email protected]> commit 8e33f91a0b84ae1964bef77cb92f5d41d97530c8 Author: Ben Dooks <[email protected]> Date: Tue Apr 15 17:06:34 2014 +0100 clk: shmobile: clk-mstp: change to using clock-indices With the addition of clock-indices, we need to change the renesas clock implementation to use these instead of the local definition of "renesas,clock-indices". Since this will break booting with older device trees, we add a simple auto-detection of which properties are present. Signed-off-by: Ben Dooks <ben.dooks@codethin…
- Loading branch information
