Skip to main content

Browse the archive

https://github.com/torvalds/linux
05 April 2024, 19:05:47 UTC
sort by:
Revision Author Date Message Commit Date
b201e74 Tomi Valkeinen 31 May 2016, 12:03:15 UTC drm: add missing drm_mode_set_crtcinfo call When setting mode via MODE_ID property, drm_atomic_set_mode_prop_for_crtc() does not call drm_mode_set_crtcinfo() which possibly causes: "[drm:drm_calc_timestamping_constants [drm]] *ERROR* crtc 32: Can't calculate constants, dotclock = 0!" Whether the error is seen depends on the previous data in state->mode, as state->mode is not cleared when setting new mode. This patch adds drm_mode_set_crtcinfo() call to drm_mode_convert_umode(), which is called in both legacy and atomic paths. This should be fine as there's no reason to call drm_mode_convert_umode() without also setting the crtc related fields. drm_mode_set_crtcinfo() is removed from the legacy drm_mode_setcrtc() as that is no longer needed. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: stable@vger.kernel.org Signed-off-by: Dave Airlie <airlied@redhat.com> 01 June 2016, 04:59:39 UTC
7cc8510 Thomas Huth 31 May 2016, 05:51:17 UTC powerpc/pseries: Add POWER8NVL support to ibm,client-architecture-support call If we do not provide the PVR for POWER8NVL, a guest on this system currently ends up in PowerISA 2.06 compatibility mode on KVM, since QEMU does not provide a generic PowerISA 2.07 mode yet. So some new instructions from POWER8 (like "mtvsrd") get disabled for the guest, resulting in crashes when using code compiled explicitly for POWER8 (e.g. with the "-mcpu=power8" option of GCC). Fixes: ddee09c099c3 ("powerpc: Add PVR for POWER8NVL processor") Cc: stable@vger.kernel.org # v4.0+ Signed-off-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> 01 June 2016, 03:47:34 UTC
157d4d0 Aneesh Kumar K.V 31 May 2016, 06:26:31 UTC powerpc/mm/radix: Add missing tlb flush This should not have any impact on hash, because hash does tlb invalidate with every pte update and we don't implement flush_tlb_* functions for hash. With radix we should make an explicit call to flush tlb outside pte update. Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> 01 June 2016, 03:47:34 UTC
dc47c0c Aneesh Kumar K.V 31 May 2016, 06:26:30 UTC powerpc/mm/hash: Fix the reference bit update when handling hash fault When we converted the asm routines to C functions, we missed updating HPTE_R_R based on _PAGE_ACCESSED. ASM code used to copy over the lower bits from pte via. andi. r3,r30,0x1fe /* Get basic set of flags */ We also update the code such that we won't update the Change bit ('C' bit) always. This was added by commit c5cf0e30bf3d8 ("powerpc: Fix buglet with MMU hash management"). With hash64, we need to make sure that hardware doesn't do a pte update directly. This is because we do end up with entries in TLB with no hash page table entry. This happens because when we find a hash bucket full, we "evict" a more/less random entry from it. When we do that we don't invalidate the TLB (hpte_remove) because we assume the old translation is still technically "valid". For more info look at commit 0608d692463("powerpc/mm: Always invalidate tlb on hpte invalidate and update"). Thus it's critical that valid hash PTEs always have reference bit set and writeable ones have change bit set. We do this by hashing a non-dirty linux PTE as read-only and always setting _PAGE_ACCESSED (and thus R) when hashing anything else in. Any attempt by Linux at clearing those bits also removes the corresponding hash entry. Commit 5cf0e30bf3d8 did that for 'C' bit by enabling 'C' bit always. We don't really need to do that because we never map a RW pte entry without setting 'C' bit. On READ fault on a RW pte entry, we still map it READ only, hence a store update in the page will still cause a hash pte fault. This patch reverts the part of commit c5cf0e30bf3d8 ("[PATCH] powerpc: Fix buglet with MMU hash management") and retain the updatepp part. - If we hit the updatepp path on native, the old code without that commit, would fail to set C bcause native_hpte_updatepp() was implemented to filter the same bits as H_PROTECT and not let C through thus we would "upgrade" a RO HPTE to RW without setting C thus causing the bug. So the real fix in that commit was the change to native_hpte_updatepp Fixes: 89ff725051d1 ("powerpc/mm: Convert __hash_page_64K to C") Cc: stable@vger.kernel.org # v4.5+ Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> 01 June 2016, 03:47:34 UTC
d6c8860 Aneesh Kumar K.V 31 May 2016, 06:26:29 UTC powerpc/mm/radix: Update LPCR only if it is powernv LPCR cannot be updated when running in guest mode. Fixes: 2bfd65e45e87 ("powerpc/mm/radix: Add radix callbacks for early init routines") Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> 01 June 2016, 03:47:34 UTC
faf8dcc Jon Cooper 31 May 2016, 18:12:32 UTC sfc: Track RPS flow IDs per channel instead of per function Otherwise we get confused when two flows on different channels get the same flow ID. Signed-off-by: Edward Cree <ecree@solarflare.com> Signed-off-by: David S. Miller <davem@davemloft.net> 01 June 2016, 03:30:25 UTC
ce7585f Alex Williamson 01 June 2016, 03:25:52 UTC vfio/pci: Allow VPD short read The size of the VPD area is not necessarily 4-byte aligned, so a pci_vpd_read() might return less than 4 bytes. Zero our buffer and accept anything other than an error. Intel X710 NICs exercise this. Fixes: 4e1a635552d3 ("vfio/pci: Use kernel VPD access functions") Signed-off-by: Alex Williamson <alex.williamson@redhat.com> 01 June 2016, 03:25:52 UTC
d69d169 Christoph Fritz 26 May 2016, 02:06:47 UTC usbnet: smsc95xx: fix link detection for disabled autonegotiation To detect link status up/down for connections where autonegotiation is explicitly disabled, we don't get an irq but need to poll the status register for link up/down detection. This patch adds a workqueue to poll for link status. Signed-off-by: Christoph Fritz <chf.fritz@googlemail.com> Signed-off-by: David S. Miller <davem@davemloft.net> 31 May 2016, 21:22:23 UTC
f00e35e wangyunjian 31 May 2016, 03:52:43 UTC virtio_net: fix virtnet_open and virtnet_probe competing for try_fill_recv In function virtnet_open() and virtnet_probe(), func try_fill_recv() may be executed at the same time. VQ in virtqueue_add() has not been protected well and BUG_ON will be triggered when virito_net.ko being removed. Signed-off-by: Yunjian Wang <wangyunjian@huawei.com> Acked-by: Jason Wang <jasowang@redhat.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net> 31 May 2016, 21:21:09 UTC
bae5499 Vitaly Kuznetsov 30 May 2016, 13:00:54 UTC bnx2x: avoid leaking memory on bnx2x_init_one() failures bnx2x_init_bp() allocates memory with bnx2x_alloc_mem_bp() so if we fail later in bnx2x_init_one() we need to free this memory with bnx2x_free_mem_bp() to avoid leakages. E.g. I'm observing memory leaks reported by kmemleak when a failure (unrelated) happens in bnx2x_vfpf_acquire(). Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com> Acked-by: Yuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net> 31 May 2016, 21:10:34 UTC
95e4daa Arnd Bergmann 31 May 2016, 20:42:11 UTC fou: fix IPv6 Kconfig options The Kconfig options I added to work around broken compilation ended up screwing up things more, as I used the wrong symbol to control compilation of the file, resulting in IPv6 fou support to never be built into the kernel. Changing CONFIG_NET_FOU_IPV6_TUNNELS to CONFIG_IPV6_FOU fixes that problem, I had renamed the symbol in one location but not the other, and as the file is never being used by other kernel code, this did not lead to a build failure that I would have caught. After that fix, another issue with the same patch becomes obvious, as we 'select INET6_TUNNEL', which is related to IPV6_TUNNEL, but not the same, and this can still cause the original build failure when IPV6_TUNNEL is not built-in but IPV6_FOU is. The fix is equally trivial, we just need to select the right symbol. I have successfully build 350 randconfig kernels with this patch and verified that the driver is now being built. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reported-by: Valentin Rothberg <valentinrothberg@gmail.com> Fixes: fabb13db448e ("fou: add Kconfig options for IPv6 support") Signed-off-by: David S. Miller <davem@davemloft.net> 31 May 2016, 21:07:49 UTC
bc7cc59 Simon Horman 30 May 2016, 05:04:25 UTC openvswitch: update checksum in {push,pop}_mpls In the case of CHECKSUM_COMPLETE the skb checksum should be updated in {push,pop}_mpls() as they the type in the ethernet header. As suggested by Pravin Shelar. Cc: Pravin Shelar <pshelar@nicira.com> Fixes: 25cd9ba0abc0 ("openvswitch: Add basic MPLS support to kernel") Signed-off-by: Simon Horman <simon.horman@netronome.com> Acked-by: Pravin B Shelar <pshelar@ovn.org> Signed-off-by: David S. Miller <davem@davemloft.net> 31 May 2016, 20:51:42 UTC
40eb90e Xin Long 29 May 2016, 09:42:13 UTC sctp: sctp_diag should dump sctp socket type Now we cannot distinguish that one sk is a udp or sctp style when we use ss to dump sctp_info. it's necessary to dump it as well. For sctp_diag, ss support is not officially available, thus there are no official users of this yet, so we can add this field in the middle of sctp_info without breaking user API. v1->v2: - move 'sctpi_s_type' field to the end of struct sctp_info, so that it won't cause incompatibility with applications already built. - add __reserved3 in sctp_info to make sure sctp_info is 8-byte alignment. Signed-off-by: Xin Long <lucien.xin@gmail.com> Acked-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> Acked-by: Neil Horman <nhorman@tuxdriver.com> Signed-off-by: David S. Miller <davem@davemloft.net> 31 May 2016, 18:59:06 UTC
7fafe80 Troy Kisky 27 May 2016, 20:30:40 UTC net: fec: update dirty_tx even if no skb If dirty_tx isn't updated, then dma_unmap_single can be called twice. This fixes a [ 58.420980] ------------[ cut here ]------------ [ 58.425667] WARNING: CPU: 0 PID: 377 at /home/schurig/d/mkarm/linux-4.5/lib/dma-debug.c:1096 check_unmap+0x9d0/0xab8() [ 58.436405] fec 2188000.ethernet: DMA-API: device driver tries to free DMA memory it has not allocated [device address=0x0000000000000000] [size=66 bytes] encountered by Holger Signed-off-by: Troy Kisky <troy.kisky@boundarydevices.com> Tested-by: <holgerschurig@gmail.com> Acked-by: Fugang Duan <fugang.duan@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net> 31 May 2016, 18:57:42 UTC
308453a Mike Manning 27 May 2016, 16:45:07 UTC vlan: Propagate MAC address to VLANs The MAC address of the physical interface is only copied to the VLAN when it is first created, resulting in an inconsistency after MAC address changes of only newly created VLANs having an up-to-date MAC. The VLANs should continue inheriting the MAC address of the physical interface until the VLAN MAC address is explicitly set to any value. This allows IPv6 EUI64 addresses for the VLAN to reflect any changes to the MAC of the physical interface and thus for DAD to behave as expected. Signed-off-by: Mike Manning <mmanning@brocade.com> Signed-off-by: David S. Miller <davem@davemloft.net> 31 May 2016, 18:56:48 UTC
f2633d2 Dan Carpenter 27 May 2016, 10:34:35 UTC atm: iphase: off by one in rx_pkt() The iadev->rx_open[] array holds "iadev->num_vc" pointers (this code assumes that pointers are 32 bits). So the > here should be >= or else we could end up reading a garbage pointer from one element beyond the end of the array. Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: David S. Miller <davem@davemloft.net> 31 May 2016, 18:52:59 UTC
86f0439 Dan Carpenter 27 May 2016, 10:33:50 UTC atm: firestream: add more reserved strings This bug was there when the driver was first added in back in year 2000. It causes a Smatch warning: drivers/atm/firestream.c:849 process_incoming() error: buffer overflow 'res_strings' 60 <= 63 There are supposed to be 64 entries in this array and the missing strings are clearly in the 30 40 range. I added them as reserved 37 to reserved 40. It's possible that strings are really supposed to be added in the middle instead of at the end, but this approach is safe, in that it fixes the bug and doesn't break anything that wasn't already broken. Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: David S. Miller <davem@davemloft.net> 31 May 2016, 18:52:59 UTC
ce57766 Chen Haiquan 27 May 2016, 02:49:11 UTC vxlan: Accept user specified MTU value when create new vxlan link When create a new vxlan link, example: ip link add vtap mtu 1440 type vxlan vni 1 dev eth0 The argument "mtu" has no effect, because it is not set to conf->mtu. The default value is used in vxlan_dev_configure function. This problem was introduced by commit 0dfbdf4102b9 (vxlan: Factor out device configuration). Fixes: 0dfbdf4102b9 (vxlan: Factor out device configuration) Signed-off-by: Chen Haiquan <oc@yunify.com> Acked-by: Cong Wang <xiyou.wangcong@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net> 31 May 2016, 18:46:00 UTC
bcf91bd Guenter Roeck 27 May 2016, 00:21:06 UTC net: pktgen: Call destroy_hrtimer_on_stack() If CONFIG_DEBUG_OBJECTS_TIMERS=y, hrtimer_init_on_stack() requires a matching call to destroy_hrtimer_on_stack() to clean up timer debug objects. Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: David S. Miller <davem@davemloft.net> 31 May 2016, 18:44:08 UTC
c08376a Guenter Roeck 27 May 2016, 00:21:05 UTC timer: Export destroy_hrtimer_on_stack() hrtimer_init_on_stack() needs a matching call to destroy_hrtimer_on_stack(), so both need to be exported. Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: David S. Miller <davem@davemloft.net> 31 May 2016, 18:44:08 UTC
e47b020 Catalin Marinas 31 May 2016, 14:55:03 UTC arm64: Provide "model name" in /proc/cpuinfo for PER_LINUX32 tasks This patch brings the PER_LINUX32 /proc/cpuinfo format more in line with the 32-bit ARM one by providing an additional line: model name : ARMv8 Processor rev X (v8l) Cc: <stable@vger.kernel.org> Acked-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Will Deacon <will.deacon@arm.com> 31 May 2016, 16:50:30 UTC
b02da6f Muhammad Falak R Wani 23 May 2016, 11:38:42 UTC dma-buf: use vma_pages() Replace explicit computation of vma page count by a call to vma_pages(). Also, include <linux/mm.h> Signed-off-by: Muhammad Falak R Wani <falakreyaz@gmail.com> Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com> Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org> 31 May 2016, 16:47:05 UTC
4320c2a Luis de Bethencourt 11 April 2016, 11:48:55 UTC fence: add missing descriptions for fence The members child_list and active_list were added to the fence struct without descriptions for the Documentation. Adding these. Fixes: b55b54b5db33 ("staging/android: remove struct sync_pt") Signed-off-by: Luis de Bethencourt <luisbg@osg.samsung.com> Reviewed-by: Javier Martinez Canillas <javier@osg.samsung.com> Reviewed-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org> 31 May 2016, 16:47:05 UTC
eae1760 Rob Clark 31 March 2016, 20:26:52 UTC doc: update/fixup dma-buf related DocBook Split out dma-buf related parts into their own section, add missing files, and write a bit of overview about how it all fits together. Signed-off-by: Rob Clark <robdclark@gmail.com> Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org> 31 May 2016, 16:46:53 UTC
367d3fd Linus Torvalds 31 May 2016, 16:43:24 UTC Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux Pull s390 fixes from Martin Schwidefsky: "Three bugs fixes and an update for the default configuration" * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux: s390: fix info leak in do_sigsegv s390/config: update default configuration s390/bpf: fix recache skb->data/hlen for skb_vlan_push/pop s390/bpf: reduce maximum program size to 64 KB 31 May 2016, 16:43:24 UTC
dad6c39 Rob Clark 31 March 2016, 20:26:51 UTC reservation: add headerdoc comments Signed-off-by: Rob Clark <robdclark@gmail.com> Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org> 31 May 2016, 16:42:43 UTC
e2082e3 Rob Clark 31 March 2016, 20:26:50 UTC dma-buf: headerdoc fixes Apparently nobody noticed that dma-buf.h wasn't actually pulled into docbook build. And as a result the headerdoc comments bitrot a bit. Add missing params/fields. Signed-off-by: Rob Clark <robdclark@gmail.com> Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org> 31 May 2016, 16:42:43 UTC
5eca831 Linus Torvalds 31 May 2016, 16:27:00 UTC Merge tag 'gpio-v4.7-2' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio Pull GPIO fixes from Linus Walleij: "A bunch of GPIO fixes for the v4.7 series: - Drop the lock before reading out the GPIO direction setting in drivers supporting the .get_direction() callback: some of them may be slowpath. - Flush GPIO direction setting before locking a GPIO as an IRQ: some electronics or other poking around in the registers behind our back may have happened, so flush the direction status before trying to lock the line for use by IRQs. - Bail out silently when asked to perform operations on NULL GPIO descriptors. That is what all the get_*_optional() is about: we get optional GPIO handles, if they are not there, we get NULL. - Handle compatible ioctl() correctly: we need to convert the ioctl() pointer using compat_ptr() here like everyone else. - Disable the broken .to_irq() on the LPC32xx platform. The whole irqchip infrastructure was replaced in the last merge window, and a new implementation will be needed" * tag 'gpio-v4.7-2' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio: gpio: drop lock before reading GPIO direction gpio: bail out silently on NULL descriptors gpio: handle compatible ioctl() pointers gpio: flush direction status in gpiochip_lock_as_irq() gpio: lpc32xx: disable broken to_irq support 31 May 2016, 16:27:00 UTC
c585132 Marc Zyngier 25 May 2016, 14:26:39 UTC arm64: KVM: vgic-v3: Relax synchronization when SRE==1 The GICv3 backend of the vgic is quite barrier heavy, in order to ensure synchronization of the system registers and the memory mapped view for a potential GICv2 guest. But when the guest is using a GICv3 model, there is absolutely no need to execute all these heavy barriers, and it is actually beneficial to avoid them altogether. This patch makes the synchonization conditional, and ensures that we do not change the EL1 SRE settings if we do not need to. Reviewed-by: Christoffer Dall <christoffer.dall@linaro.org> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com> Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org> 31 May 2016, 14:12:17 UTC
a057001 Marc Zyngier 25 May 2016, 14:26:38 UTC arm64: KVM: vgic-v3: Prevent the guest from messing with ICC_SRE_EL1 Both our GIC emulations are "strict", in the sense that we either emulate a GICv2 or a GICv3, and not a GICv3 with GICv2 legacy support. But when running on a GICv3 host, we still allow the guest to tinker with the ICC_SRE_EL1 register during its time slice: it can switch SRE off, observe that it is off, and yet on the next world switch, find the SRE bit to be set again. Not very nice. An obvious solution is to always trap accesses to ICC_SRE_EL1 (by clearing ICC_SRE_EL2.Enable), and to let the handler return the programmed value on a read, or ignore the write. That way, the guest can always observe that our GICv3 is SRE==1 only. Reviewed-by: Christoffer Dall <christoffer.dall@linaro.org> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com> Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org> 31 May 2016, 14:12:17 UTC
b34f2bc Marc Zyngier 25 May 2016, 14:26:37 UTC arm64: KVM: Make ICC_SRE_EL1 access return the configured SRE value When we trap ICC_SRE_EL1, we handle it as RAZ/WI. It would be more correct to actual make it RO, and return the configured value when read. Reviewed-by: Christoffer Dall <christoffer.dall@linaro.org> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com> Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org> 31 May 2016, 14:12:16 UTC
637d122 Marc Zyngier 25 May 2016, 14:26:36 UTC KVM: arm/arm64: vgic-v3: Always resample level interrupts When reading back from the list registers, we need to perform two actions for level interrupts: 1) clear the soft-pending bit if the interrupt is not pending anymore *in the list register* 2) resample the line level and propagate it to the pending state But these two actions shouldn't be linked, and we should *always* resample the line level, no matter what state is in the list register. Otherwise, we may end-up injecting spurious interrupts that have been already retired. Signed-off-by: Marc Zyngier <marc.zyngier@arm.com> Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org> 31 May 2016, 14:12:16 UTC
df7942d Marc Zyngier 25 May 2016, 14:26:35 UTC KVM: arm/arm64: vgic-v2: Always resample level interrupts When reading back from the list registers, we need to perform two actions for level interrupts: 1) clear the soft-pending bit if the interrupt is not pending anymore *in the list register* 2) resample the line level and propagate it to the pending state But these two actions shouldn't be linked, and we should *always* resample the line level, no matter what state is in the list register. Otherwise, we may end-up injecting spurious interrupts that have been already retired. Signed-off-by: Marc Zyngier <marc.zyngier@arm.com> Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org> 31 May 2016, 14:12:15 UTC
fa89c77 Christoffer Dall 25 May 2016, 14:26:34 UTC KVM: arm/arm64: vgic-v3: Clear all dirty LRs When saving the state of the list registers, it is critical to reset them zero, as we could otherwise leave unexpected EOI interrupts pending for virtual level interrupts. Cc: stable@vger.kernel.org # v4.6+ Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com> 31 May 2016, 14:12:09 UTC
4d3afc9 Christoffer Dall 25 May 2016, 14:26:33 UTC KVM: arm/arm64: vgic-v2: Clear all dirty LRs When saving the state of the list registers, it is critical to reset them zero, as we could otherwise leave unexpected EOI interrupts pending for virtual level interrupts. Cc: stable@vger.kernel.org # v4.6+ Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com> 31 May 2016, 14:09:28 UTC
604c8e6 Mark Rutland 13 May 2016, 11:20:36 UTC arm64: enable CONFIG_SET_MODULE_RONX by default The SET_MODULE_RONX protections are effectively the same as the DEBUG_RODATA protections we enabled by default back in commit 57efac2f7108e325 ("arm64: enable CONFIG_DEBUG_RODATA by default"). It seems unusual to have one but not the other. As evidenced by the help text, the rationale appears to be that SET_MODULE_RONX interacts poorly with tracing and patching, but both of these make use of the insn framework, which takes SET_MODULE_RONX into account. Any remaining issues are bugs which should be fixed regardless of the default state of the option. This patch enables DEBUG_SET_MODULE_RONX by default, and replaces the help text with a new wording derived from the DEBUG_RODATA help text, which better describes the functionality. Previously, the DEBUG_RODATA entry was inconsistently indented with spaces, which are replaced with tabs as with the other Kconfig entries. Additionally, the wording of recommended defaults is made consistent for all options. These are placed in a new paragraph, unquoted, as a full sentence (with a period/full stop) as this appears to be the most common form per $(git grep 'in doubt'). Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Laura Abbott <labbott@fedoraproject.org> Acked-by: Kees Cook <keescook@chromium.org> Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Will Deacon <will.deacon@arm.com> 31 May 2016, 13:23:29 UTC
db413b5 Robin Murphy 24 May 2016, 17:55:40 UTC arm64: Remove orphaned __addr_ok() definition Since commit 12a0ef7b0ac3 ("arm64: use generic strnlen_user and strncpy_from_user functions"), the definition of __addr_ok() has been languishing unused; eradicate the sucker. CC: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Robin Murphy <robin.murphy@arm.com> Signed-off-by: Will Deacon <will.deacon@arm.com> 31 May 2016, 12:11:11 UTC
8dd75cc Thomas Huth 12 May 2016, 11:29:11 UTC powerpc: Use privileged SPR number for MMCR2 We are already using the privileged versions of MMCR0, MMCR1 and MMCRA in the kernel, so for MMCR2, we should better use the privileged versions, too, to be consistent. Fixes: 240686c13687 ("powerpc: Initialise PMU related regs on Power8") Cc: stable@vger.kernel.org # v3.10+ Suggested-by: Paul Mackerras <paulus@ozlabs.org> Signed-off-by: Thomas Huth <thuth@redhat.com> Acked-by: Paul Mackerras <paulus@ozlabs.org> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> 31 May 2016, 10:08:32 UTC
d23fac2 Thomas Huth 12 May 2016, 11:26:44 UTC powerpc: Fix definition of SIAR and SDAR registers The SIAR and SDAR registers are available twice, one time as SPRs 780 / 781 (unprivileged, but read-only), and one time as the SPRs 796 / 797 (privileged, but read and write). The Linux kernel code currently uses the unprivileged SPRs - while this is OK for reading, writing to that register of course does not work. Since the KVM code tries to write to this register, too (see the mtspr in book3s_hv_rmhandlers.S), the contents of this register sometimes get lost for the guests, e.g. during migration of a VM. To fix this issue, simply switch to the privileged SPR numbers instead. Cc: stable@vger.kernel.org Signed-off-by: Thomas Huth <thuth@redhat.com> Acked-by: Paul Mackerras <paulus@ozlabs.org> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> 31 May 2016, 10:07:56 UTC
ab2e1b8 Will Deacon 31 May 2016, 10:00:09 UTC Revert "arm64: hugetlb: partial revert of 66b3923a1a0f" This reverts commit ff7925848b50050732ac0401e0acf27e8b241d7b. Now that the contiguous-hint hugetlb regression has been debugged and fixed upstream by 66ee95d16a7f ("mm: exclude HugeTLB pages from THP page_mapped() logic"), we can revert the previous partial revert of this feature. Signed-off-by: Will Deacon <will.deacon@arm.com> 31 May 2016, 10:00:09 UTC
5edf673 hongkun.cao 21 May 2016, 07:23:39 UTC pinctrl: mediatek: fix dual-edge code defect When a dual-edge irq is triggered, an incorrect irq will be reported on condition that the external signal is not stable and this incorrect irq has been registered. Correct the register offset. Cc: stable@vger.kernel.org Signed-off-by: Hongkun Cao <hongkun.cao@mediatek.com> Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> 31 May 2016, 08:13:45 UTC
d0196c8 Arnd Bergmann 11 May 2016, 16:05:39 UTC drm/omap: include gpio/consumer.h where needed A lot of the display drivers for OMAP use the gpio descriptor functions that are only available in linux/gpio.h if GPIOLIB is enabled and otherwise produce a build error: drivers/gpu/drm/omapdrm/displays/encoder-opa362.c: In function 'opa362_enable': drivers/gpu/drm/omapdrm/displays/encoder-opa362.c:101:3: error: implicit declaration of function 'gpiod_set_value_cansleep' [-Werror=implicit-function-declaration] drivers/gpu/drm/omapdrm/displays/panel-dpi.c: In function 'panel_dpi_probe_pdata': drivers/gpu/drm/omapdrm/displays/panel-dpi.c:189:23: error: implicit declaration of function 'gpio_to_desc' [-Werror=implicit-function-declaration] drivers/gpu/drm/omapdrm/displays/panel-sharp-ls037v7dw01.c: In function 'sharp_ls_enable': drivers/gpu/drm/omapdrm/displays/panel-sharp-ls037v7dw01.c:120:3: error: implicit declaration of function 'gpiod_set_value_cansleep' [-Werror=implicit-function-declaration] This replaces the existing linux/gpio.h with linux/gpio/consumer.h where needed. In case of panel-lgphilips-lb035q02.c however, we also have to include linux/gpio.h to get the definition of gpio_is_valid and gpio_set_value_cansleep that are used for the non-DT case. Signed-off-by: Arnd Bergmann <arnd@arndb.de> [tomi.valkeinen@ti.com: resolved conflicts] Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> 31 May 2016, 05:30:14 UTC
2d80245 Arnd Bergmann 11 May 2016, 16:01:45 UTC drm/omap: include linux/seq_file.h where needed The omapdrm driver relies on this header to be included implicitly, but this does not always work, and I get this error in randconfig builds: gpu/drm/omapdrm/dss/hdmi_phy.c: In function 'hdmi_phy_dump': gpu/drm/omapdrm/dss/hdmi_phy.c:34:2: error: implicit declaration of function 'seq_printf' [-Werror=implicit-function-declaration] gpu/drm/omapdrm/dss/hdmi_wp.c: In function 'hdmi_wp_dump': gpu/drm/omapdrm/dss/hdmi_wp.c:26:2: error: implicit declaration of function 'seq_printf' [-Werror=implicit-function-declaration] gpu/drm/omapdrm/dss/hdmi_pll.c: In function 'hdmi_pll_dump': gpu/drm/omapdrm/dss/hdmi_pll.c:30:2: error: implicit declaration of function 'seq_printf' [-Werror=implicit-function-declaration] This adds the #include statements in all files that have a seq_printf statement. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> 31 May 2016, 05:30:14 UTC
62cb075 Peter Ujfalusi 28 April 2016, 12:42:49 UTC Revert "drm/omap: no need to select OMAP2_DSS" This reverts commit 1c278e5e3718d15475ec08ee2135f37a6b13361c. If DRM_OMAP does not select OMAP2_DSS it is possible to build a kernel with DRM_OMAP only and not selecting OMAP2_DSS. Since omapdrm depends on OMAP2_DSS this will result on broken kernel build. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> 31 May 2016, 05:30:14 UTC
973999a Peter Ujfalusi 28 April 2016, 12:42:18 UTC drm/omap: Remove regulator API abuse regulator_can_change_voltage() is deprecated and it's use is not necessary as commit: 6a0028b3dd67b regulator: Deprecate regulator_can_change_voltage() describers it clearly. Also, regulator_set_voltage() is misused in the driver, as it is supposed to be used only in cases where the regulator voltage needs to be changed dynamically at runtime. In DSS's case, we always want a fixed voltage, set in the .dts files. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> 31 May 2016, 05:28:31 UTC
4bafcbc Jim Lodes 21 April 2016, 17:27:49 UTC OMAPDSS: HDMI5: Change DDC timings The DDC scl high and low times were set to the minimum values from the i2c specification, but the i2c specification takes into account the rise time and fall time to calculate the frequency. To pass HDMI certification DDC can not exceed 100kHz therefore in a system where the rise times and fall times are negligible the high and low times for scl need to be 10us. Signed-off-by: Jim Lodes <jim.lodes@garmin.com> Signed-off-by: J.D. Schroeder <jay.schroeder@garmin.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> 31 May 2016, 05:20:43 UTC
08f707a Jim Lodes 21 April 2016, 17:49:00 UTC OMAPDSS: HDMI5: Fix AVI infoframe The AVI infoframe R0-R3 in the 2nd data byte represents the Active Format Aspect Ratio. It is four bits long not two bits. This fixes that mask used to extract the bits before writing the bits to the hardware registers. Signed-off-by: Jim Lodes <jim.lodes@garmin.com> Signed-off-by: J.D. Schroeder <jay.schroeder@garmin.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> 31 May 2016, 05:20:42 UTC
91cd220 Tomi Valkeinen 01 April 2016, 07:29:29 UTC drm/omap: fix OMAP4 hdmi_core_powerdown_disable() hdmi_core_powerdown_disable() is supposed to disable HDMI core's power-down mode. However, the function sets the power-down bit to 0, which means "enable power-down". This hasn't caused any issues as the PD seems to affect only interrupts from HDMI core, and none of those interrupts are used at the moment. CEC functionality requires core interrupts, and the PD mode needs to be fixed. This patch fixes hdmi_core_powerdown_disable() to actually disable the PD mode. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Reported-by: Hans Verkuil <hverkuil@xs4all.nl> 31 May 2016, 05:20:42 UTC
d9e32ec Tomi Valkeinen 18 March 2016, 07:02:18 UTC drm/omap: Fix missing includes With certain kernel config options many omapdrm files fail to compile due to missing include of linux/gpio/consumer.h and linux/of.h. This patch adds those includes. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Reported-by: Dan Murphy <dmurphy@ti.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> 31 May 2016, 05:20:42 UTC
2639d6b Arnd Bergmann 09 May 2016, 21:51:27 UTC drm/omapdrm: include pinctrl/consumer.h where needed In some configurations, we can build the OMAP dss driver without implictly including the pinctrl consumer definitions, causing a build error: gpu/drm/omapdrm/dss/dss.c: In function 'dss_runtime_suspend': gpu/drm/omapdrm/dss/dss.c:1268:2: error: implicit declaration of function 'pinctrl_pm_select_sleep_state' [-Werror=implicit-function-declaration] This adds an explicit #include. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> 31 May 2016, 05:20:42 UTC
b5de8d0 Filipe Manana 27 May 2016, 21:21:27 UTC Btrfs: fix race between device replace and read repair While we are finishing a device replace operation we can have a concurrent task trying to do a read repair operation, in which case it will call btrfs_map_block() to get a struct btrfs_bio which can have a stripe that points to the source device of the device replace operation. This allows for the read repair task to dereference the stripe's device pointer after the device replace operation has freed the source device, resulting in an invalid memory access. This is similar to the problem solved by my previous patch in the same series and named "Btrfs: fix race between device replace and discard". So fix this by surrounding the call to btrfs_map_block() and the code that uses the returned struct btrfs_bio with calls to btrfs_bio_counter_inc_blocked() and btrfs_bio_counter_dec(), giving the proper serialization with the finishing phase of the device replace operation. Signed-off-by: Filipe Manana <fdmanana@suse.com> Reviewed-by: Josef Bacik <jbacik@fb.com> 31 May 2016, 00:00:03 UTC
2999241 Filipe Manana 27 May 2016, 16:42:05 UTC Btrfs: fix race between device replace and discard While we are finishing a device replace operation, we can make a discard operation (fs mounted with -o discard) do an invalid memory access like the one reported by the following trace: [ 3206.384654] general protection fault: 0000 [#1] PREEMPT SMP [ 3206.387520] Modules linked in: dm_mod btrfs crc32c_generic xor raid6_pq acpi_cpufreq tpm_tis psmouse tpm ppdev sg parport_pc evdev i2c_piix4 parport processor serio_raw i2c_core pcspkr button loop autofs4 ext4 crc16 jbd2 mbcache sr_mod cdrom ata_generic sd_mod virtio_scsi ata_piix libata virtio_pci virtio_ring scsi_mod e1000 virtio floppy [last unloaded: btrfs] [ 3206.388595] CPU: 14 PID: 29194 Comm: fsstress Not tainted 4.6.0-rc7-btrfs-next-29+ #1 [ 3206.388595] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS by qemu-project.org 04/01/2014 [ 3206.388595] task: ffff88017ace0100 ti: ffff880171b98000 task.ti: ffff880171b98000 [ 3206.388595] RIP: 0010:[<ffffffff8124d233>] [<ffffffff8124d233>] blkdev_issue_discard+0x5c/0x2a7 [ 3206.388595] RSP: 0018:ffff880171b9bb80 EFLAGS: 00010246 [ 3206.388595] RAX: ffff880171b9bc28 RBX: 000000000090d000 RCX: 0000000000000000 [ 3206.388595] RDX: ffffffff82fa1b48 RSI: ffffffff8179f46c RDI: ffffffff82fa1b48 [ 3206.388595] RBP: ffff880171b9bcc0 R08: 0000000000000000 R09: 0000000000000001 [ 3206.388595] R10: ffff880171b9bce0 R11: 000000000090f000 R12: ffff880171b9bbe8 [ 3206.388595] R13: 0000000000000010 R14: 0000000000004868 R15: 6b6b6b6b6b6b6b6b [ 3206.388595] FS: 00007f6182e4e700(0000) GS:ffff88023fdc0000(0000) knlGS:0000000000000000 [ 3206.388595] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 3206.388595] CR2: 00007f617c2bbb18 CR3: 000000017ad9c000 CR4: 00000000000006e0 [ 3206.388595] Stack: [ 3206.388595] 0000000000004878 0000000000000000 0000000002400040 0000000000000000 [ 3206.388595] 0000000000000000 ffff880171b9bbe8 ffff880171b9bbb0 ffff880171b9bbb0 [ 3206.388595] ffff880171b9bbc0 ffff880171b9bbc0 ffff880171b9bbd0 ffff880171b9bbd0 [ 3206.388595] Call Trace: [ 3206.388595] [<ffffffffa042899e>] btrfs_issue_discard+0x12f/0x143 [btrfs] [ 3206.388595] [<ffffffffa042899e>] ? btrfs_issue_discard+0x12f/0x143 [btrfs] [ 3206.388595] [<ffffffffa042e862>] btrfs_discard_extent+0x87/0xde [btrfs] [ 3206.388595] [<ffffffffa04303b5>] btrfs_finish_extent_commit+0xb2/0x1df [btrfs] [ 3206.388595] [<ffffffff8149c246>] ? __mutex_unlock_slowpath+0x150/0x15b [ 3206.388595] [<ffffffffa04464c4>] btrfs_commit_transaction+0x7fc/0x980 [btrfs] [ 3206.388595] [<ffffffff8149c246>] ? __mutex_unlock_slowpath+0x150/0x15b [ 3206.388595] [<ffffffffa0459af6>] btrfs_sync_file+0x38f/0x428 [btrfs] [ 3206.388595] [<ffffffff811a8292>] vfs_fsync_range+0x8c/0x9e [ 3206.388595] [<ffffffff811a82c0>] vfs_fsync+0x1c/0x1e [ 3206.388595] [<ffffffff811a8417>] do_fsync+0x31/0x4a [ 3206.388595] [<ffffffff811a8637>] SyS_fsync+0x10/0x14 [ 3206.388595] [<ffffffff8149e025>] entry_SYSCALL_64_fastpath+0x18/0xa8 [ 3206.388595] [<ffffffff81100c6b>] ? time_hardirqs_off+0x9/0x14 [ 3206.388595] [<ffffffff8108e87d>] ? trace_hardirqs_off_caller+0x1f/0xaa This happens because when we call btrfs_map_block() from btrfs_discard_extent() to get a btrfs_bio structure, the device replace operation has not finished yet, but before we use the device of one of the stripes from the returned btrfs_bio structure, the device object is freed. This is illustrated by the following diagram. CPU 1 CPU 2 btrfs_dev_replace_start() (...) btrfs_dev_replace_finishing() btrfs_start_transaction() btrfs_commit_transaction() (...) btrfs_sync_file() btrfs_start_transaction() (...) btrfs_commit_transaction() btrfs_finish_extent_commit() btrfs_discard_extent() btrfs_map_block() --> returns a struct btrfs_bio with a stripe that has a device field pointing to source device of the replace operation (the device that is being replaced) mutex_lock(&uuid_mutex) mutex_lock(&fs_info->fs_devices->device_list_mutex) mutex_lock(&fs_info->chunk_mutex) btrfs_dev_replace_update_device_in_mapping_tree() --> iterates the mapping tree and for each extent map that has a stripe pointing to the source device, it updates the stripe to point to the target device instead btrfs_rm_dev_replace_blocked() --> waits for fs_info->bio_counter to go down to 0 btrfs_rm_dev_replace_remove_srcdev() --> removes source device from the list of devices mutex_unlock(&fs_info->chunk_mutex) mutex_unlock(&fs_info->fs_devices->device_list_mutex) mutex_unlock(&uuid_mutex) btrfs_rm_dev_replace_free_srcdev() --> frees the source device --> iterates over all stripes of the returned struct btrfs_bio --> for each stripe it dereferences its device pointer --> it ends up finding a pointer to the device used as the source device for the replace operation and that was already freed So fix this by surrounding the call to btrfs_map_block(), and the code that uses the returned struct btrfs_bio, with calls to btrfs_bio_counter_inc_blocked() and btrfs_bio_counter_dec(), so that the finishing phase of the device replace operation blocks until the the bio counter decreases to zero before it frees the source device. This is the same approach we do at btrfs_map_bio() for example. Signed-off-by: Filipe Manana <fdmanana@suse.com> Reviewed-by: Josef Bacik <jbacik@fb.com> 30 May 2016, 23:59:44 UTC
852f42a Linus Torvalds 30 May 2016, 22:27:07 UTC Merge branch 'uuid' (lib/uuid fixes from Andy) Merge lib/uuid fixes from Andy Shevchenko. * emailed patches from Andy Shevchenko <andriy.shevchenko@linux.intel.com>: lib/uuid.c: use correct offset in uuid parser lib/uuid: add a test module 30 May 2016, 22:27:07 UTC
bc9dc9d Bjørn Mork 30 May 2016, 14:40:42 UTC lib/uuid.c: use correct offset in uuid parser Use '+ 0' and '+ 1' as offsets, like they were intended, instead of adding to the result. Fixes: 2b1b0d66704a ("lib/uuid.c: introduce a few more generic helpers") Signed-off-by: Bjørn Mork <bjorn@mork.no> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> 30 May 2016, 22:26:57 UTC
cfaff0e Andy Shevchenko 30 May 2016, 14:40:41 UTC lib/uuid: add a test module It appears that somehow I missed a test of the latest UUID rework which landed in the kernel. Present a small test module to avoid such cases in the future. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> 30 May 2016, 22:26:57 UTC
4469854 Linus Torvalds 30 May 2016, 22:20:18 UTC Merge branch 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6 Pull crypto fixes from Herbert Xu: "This fixes the following issues: - missing selection in public_key that may result in a build failure - Potential crash in error path in omap-sham - ccp AES XTS bug that affects requests larger than 4096" * 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6: crypto: ccp - Fix AES XTS error for request sizes above 4096 crypto: public_key: select CRYPTO_AKCIPHER crypto: omap-sham - potential Oops on error in probe 30 May 2016, 22:20:18 UTC
4a3262b Ilya Dryomov 30 May 2016, 16:33:32 UTC libceph: use %s instead of %pE in dout()s Commit d30291b985d1 ("libceph: variable-sized ceph_object_id") changed dout()s in what is now encode_request() and ceph_object_locator_to_pg() to use %pE, mostly to document that, although all rbd and cephfs object names are NULL-terminated strings, ceph_object_id will handle any RADOS object name, including the one containing NULs, just fine. However, it turns out that vbin_printf() can't handle anything but ints and %s - all %p suffixes are ignored. The buffer %p** points to isn't recorded, resulting in trash in the messages if the buffer had been reused by the time bstr_printf() got to it. Signed-off-by: Ilya Dryomov <idryomov@gmail.com> 30 May 2016, 21:00:23 UTC
dc045a9 Ilya Dryomov 27 May 2016, 13:18:34 UTC libceph: put request only if it's done in handle_reply() handle_reply() may be called twice on the same request: on ack and then on commit. This occurs on btrfs-formatted OSDs or if cephfs sync write path is triggered - CEPH_OSD_FLAG_ACK | CEPH_OSD_FLAG_ONDISK. handle_reply() handles this with the help of done_request(). Fixes: 5aea3dcd5021 ("libceph: a major OSD client update") Signed-off-by: Ilya Dryomov <idryomov@gmail.com> 30 May 2016, 21:00:23 UTC
b7ec35b Ilya Dryomov 28 April 2016, 14:07:25 UTC libceph: change ceph_osdmap_flag() to take osdc For the benefit of every single caller, take osdc instead of map. Also, now that osdc->osdmap can't ever be NULL, drop the check. Signed-off-by: Ilya Dryomov <idryomov@gmail.com> 30 May 2016, 21:00:22 UTC
545ebd9 Linus Walleij 30 May 2016, 15:11:59 UTC gpio: drop lock before reading GPIO direction When adding the gpiochip, the GPIO HW drivers' callback get_direction() could get called in atomic context. Some of the GPIO HW drivers may sleep when accessing the register. Move the lock before initializing the descriptors. Reported-by: Laxman Dewangan <ldewangan@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> 30 May 2016, 15:11:59 UTC
54d7719 Linus Walleij 30 May 2016, 14:48:39 UTC gpio: bail out silently on NULL descriptors In fdeb8e1547cb9dd39d5d7223b33f3565cf86c28e ("gpio: reflect base and ngpio into gpio_device") assumed that GPIO descriptors are either valid or error pointers, but gpiod_get_[index_]optional() actually return NULL descriptors and then all subsequent calls should just bail out. Cc: stable@vger.kernel.org Cc: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> Cc: Florian Fainelli <f.fainelli@gmail.com> Cc: Andrew Lunn <andrew@lunn.ch> Fixes: fdeb8e1547cb ("gpio: reflect base and ngpio into gpio_device") Reported-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> 30 May 2016, 14:56:41 UTC
8b92e17 Linus Walleij 27 May 2016, 12:24:04 UTC gpio: handle compatible ioctl() pointers If we're using the compatible ioctl() we need to handle the argument pointer in a special way or there will be trouble. Fixes: 3c702e9987e2 ("gpio: add a userspace chardev ABI for GPIOs") Reported-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Reviewed-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> 30 May 2016, 14:00:31 UTC
089f1c6 Alex Williamson 30 May 2016, 13:58:10 UTC vfio/type1: Fix build warning This function cannot actually be called with npage = 0, so in practice this doesn't return an uninitialized value. Signed-off-by: Alex Williamson <alex.williamson@redhat.com> 30 May 2016, 13:58:10 UTC
956b56a Alex Williamson 30 May 2016, 13:50:10 UTC vfio/pci: Fix ordering of eventfd vs virqfd shutdown Both the INTx and MSI/X disable paths do an eventfd_ctx_put() for the trigger eventfd before calling vfio_virqfd_disable() any potential mask and unmask eventfds. This opens a use-after-free race where an inopportune irqfd can reference the freed signalling eventfd. Reorder to avoid this possibility. Signed-off-by: Alex Williamson <alex.williamson@redhat.com> 30 May 2016, 13:50:10 UTC
6cacd11 Srinivas Pandruvada 30 May 2016, 06:31:23 UTC cpufreq: intel_pstate: Downgrade print level for _PPC Downgrade pr_info to pr_debug for the "_PPC limits will be enforced" message. In server systems with many cores this message is annoying. Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> [ rjw: Changelog ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> 30 May 2016, 13:22:02 UTC
22ab04e Filipe Manana 18 May 2016, 19:29:44 UTC Btrfs: fix race between device replace and chunk allocation While iterating and copying extents from the source device, the device replace code keeps adjusting a left cursor that is used to make sure that once we finish processing a device extent, any future writes to extents from the corresponding block group will get into both the source and target devices. This left cursor is also used for resuming the device replace operation at mount time. However using this left cursor to decide whether writes go into both devices or only the source device is not enough to guarantee we don't miss copying extents into the target device. There are two cases where the current approach fails. The first one is related to when there are holes in the device and they get allocated for new block groups while the device replace operation is iterating the device extents (more on this explained below). The second one is that when that loop over the device extents finishes, we start dellaloc, wait for all ordered extents and then commit the current transaction, we might have got new block groups allocated that are now using a device extent that has an offset greater then or equals to the value of the left cursor, in which case writes to extents belonging to these new block groups will get issued only to the source device. For the first case where the current approach of using a left cursor fails, consider the source device currently has the following layout: [ extent bg A ] [ hole, unallocated space ] [extent bg B ] 3Gb 4Gb 5Gb While we are iterating the device extents from the source device using the commit root of the device tree, the following happens: CPU 1 CPU 2 <we are at transaction N> scrub_enumerate_chunks() --> searches the device tree for extents belonging to the source device using the device tree's commit root --> 1st iteration finds extent belonging to block group A --> sets block group A to RO mode (btrfs_inc_block_group_ro) --> sets cursor left to found_key.offset which is 3Gb --> scrub_chunk() starts copies all allocated extents from block group's A stripe at source device into target device btrfs_alloc_chunk() --> allocates device extent in the range [4Gb, 5Gb[ from the source device for a new block group C extent allocated from block group C for a direct IO, buffered write or btree node/leaf extent is written to, perhaps in response to a writepages() call from the VM or directly through direct IO the write is made only against the source device and not against the target device because the extent's offset is in the interval [4Gb, 5Gb[ which is larger then the value of cursor_left (3Gb) --> scrub_chunks() finishes --> updates left cursor from 3Gb to 4Gb --> btrfs_dec_block_group_ro() sets block group A back to RW mode <we are still at transaction N> --> 2nd iteration finds extent belonging to block group B - it did not find the new extent in the range [4Gb, 5Gb[ for block group C because we are using the device tree's commit root or even because the block group's items are not all yet inserted in the respective btrees, that is, the block group is still attached to some transaction handle's new_bgs list and btrfs_create_pending_block_groups() was not called yet against that transaction handle, so the device extent items were not yet inserted into the devices tree <we are still at transaction N> --> so we end not copying anything from the newly allocated device extent from the source device to the target device So fix this by making __btrfs_map_block() always redirect writes to the target device as well, independently of the left cursor's value. With this change the left cursor is now used only for the purpose of tracking progress and allow a mount operation to resume a device replace. Signed-off-by: Filipe Manana <fdmanana@suse.com> Reviewed-by: Josef Bacik <jbacik@fb.com> 30 May 2016, 11:58:26 UTC
1a1a8b7 Filipe Manana 14 May 2016, 18:44:40 UTC Btrfs: fix race setting block group back to RW mode during device replace After it finishes processing a device extent, the device replace code sets back the block group to RW mode and then after that it sets the left cursor to match the logical end address of the block group, so that future writes into extents belonging to the block group go both the source (old) and target (new) devices. However from the moment we turn the block group back to RW mode we have a short time window, that lasts until we update the left cursor's value, where extents can be allocated from the block group and written to, in which case they will not be copied/written to the target (new) device. Fix this by updating the left cursor's value before turning the block group back to RW mode. Signed-off-by: Filipe Manana <fdmanana@suse.com> Reviewed-by: Josef Bacik <jbacik@fb.com> 30 May 2016, 11:58:24 UTC
81e87a7 Filipe Manana 14 May 2016, 15:32:35 UTC Btrfs: fix unprotected assignment of the left cursor for device replace We were assigning new values to fields of the device replace object without holding the respective lock after processing each device extent. This is important for the left cursor field which can be accessed by a concurrent task running __btrfs_map_block (which, correctly, takes the device replace lock). So change these fields while holding the device replace lock. Signed-off-by: Filipe Manana <fdmanana@suse.com> Reviewed-by: Josef Bacik <jbacik@fb.com> 30 May 2016, 11:58:23 UTC
f0e9b7d Filipe Manana 14 May 2016, 08:12:53 UTC Btrfs: fix race setting block group readonly during device replace When we do a device replace, for each device extent we find from the source device, we set the corresponding block group to readonly mode to prevent writes into it from happening while we are copying the device extent from the source to the target device. However just before we set the block group to readonly mode some concurrent task might have already allocated an extent from it or decided it could perform a nocow write into one of its extents, which can make the device replace process to miss copying an extent since it uses the extent tree's commit root to search for extents and only once it finishes searching for all extents belonging to the block group it does set the left cursor to the logical end address of the block group - this is a problem if the respective ordered extents finish while we are searching for extents using the extent tree's commit root and no transaction commit happens while we are iterating the tree, since it's the delayed references created by the ordered extents (when they complete) that insert the extent items into the extent tree (using the non-commit root of course). Example: CPU 1 CPU 2 btrfs_dev_replace_start() btrfs_scrub_dev() scrub_enumerate_chunks() --> finds device extent belonging to block group X <transaction N starts> starts buffered write against some inode writepages is run against that inode forcing dellaloc to run btrfs_writepages() extent_writepages() extent_write_cache_pages() __extent_writepage() writepage_delalloc() run_delalloc_range() cow_file_range() btrfs_reserve_extent() --> allocates an extent from block group X (which is not yet in RO mode) btrfs_add_ordered_extent() --> creates ordered extent Y flush_epd_write_bio() --> bio against the extent from block group X is submitted btrfs_inc_block_group_ro(bg X) --> sets block group X to readonly scrub_chunk(bg X) scrub_stripe(device extent from srcdev) --> keeps searching for extent items belonging to the block group using the extent tree's commit root --> it never blocks due to fs_info->scrub_pause_req as no one tries to commit transaction N --> copies all extents found from the source device into the target device --> finishes search loop bio completes ordered extent Y completes and creates delayed data reference which will add an extent item to the extent tree when run (typically at transaction commit time) --> so the task doing the scrub/device replace at CPU 1 misses this and does not copy this extent into the new/target device btrfs_dec_block_group_ro(bg X) --> turns block group X back to RW mode dev_replace->cursor_left is set to the logical end offset of block group X So fix this by waiting for all cow and nocow writes after setting a block group to readonly mode. Signed-off-by: Filipe Manana <fdmanana@suse.com> Reviewed-by: Josef Bacik <jbacik@fb.com> 30 May 2016, 11:58:21 UTC
57ba4cb Filipe Manana 20 May 2016, 03:34:23 UTC Btrfs: fix race between device replace and block group removal When it's finishing, the device replace code iterates all extent maps representing block group and for each one that has a stripe that refers to the source device, it replaces its device with the target device. However when it replaces the source device with the target device it, the target device still has an ID of 0ULL (BTRFS_DEV_REPLACE_DEVID), only after its ID is changed to match the one from the source device. This leads to races with the chunk removal code that can temporarly see a device with an ID of 0ULL and then attempt to use that ID to remove items from the device tree and fail, causing a transaction abort: [ 9238.594364] BTRFS info (device sdf): dev_replace from /dev/sdf (devid 3) to /dev/sde finished [ 9238.594377] ------------[ cut here ]------------ [ 9238.594402] WARNING: CPU: 14 PID: 21566 at fs/btrfs/volumes.c:2771 btrfs_remove_chunk+0x2e5/0x793 [btrfs] [ 9238.594403] BTRFS: Transaction aborted (error 1) [ 9238.594416] Modules linked in: btrfs crc32c_generic acpi_cpufreq xor tpm_tis tpm raid6_pq ppdev parport_pc processor psmouse parport i2c_piix4 evdev sg i2c_core se rio_raw pcspkr button loop autofs4 ext4 crc16 jbd2 mbcache sr_mod cdrom sd_mod ata_generic virtio_scsi ata_piix virtio_pci libata virtio_ring virtio e1000 scsi_mod fl oppy [last unloaded: btrfs] [ 9238.594418] CPU: 14 PID: 21566 Comm: btrfs-cleaner Not tainted 4.6.0-rc7-btrfs-next-29+ #1 [ 9238.594419] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS by qemu-project.org 04/01/2014 [ 9238.594421] 0000000000000000 ffff88017f1dbc60 ffffffff8126b42c ffff88017f1dbcb0 [ 9238.594422] 0000000000000000 ffff88017f1dbca0 ffffffff81052b14 00000ad37f1dbd18 [ 9238.594423] 0000000000000001 ffff88018068a558 ffff88005c4b9c00 ffff880233f60db0 [ 9238.594424] Call Trace: [ 9238.594428] [<ffffffff8126b42c>] dump_stack+0x67/0x90 [ 9238.594430] [<ffffffff81052b14>] __warn+0xc2/0xdd [ 9238.594432] [<ffffffff81052b7a>] warn_slowpath_fmt+0x4b/0x53 [ 9238.594434] [<ffffffff8116c311>] ? kmem_cache_free+0x128/0x188 [ 9238.594450] [<ffffffffa04d43f5>] btrfs_remove_chunk+0x2e5/0x793 [btrfs] [ 9238.594452] [<ffffffff8108e456>] ? arch_local_irq_save+0x9/0xc [ 9238.594464] [<ffffffffa04a26fa>] btrfs_delete_unused_bgs+0x317/0x382 [btrfs] [ 9238.594476] [<ffffffffa04a961d>] cleaner_kthread+0x1ad/0x1c7 [btrfs] [ 9238.594489] [<ffffffffa04a9470>] ? btree_invalidatepage+0x8e/0x8e [btrfs] [ 9238.594490] [<ffffffff8106f403>] kthread+0xd4/0xdc [ 9238.594494] [<ffffffff8149e242>] ret_from_fork+0x22/0x40 [ 9238.594495] [<ffffffff8106f32f>] ? kthread_stop+0x286/0x286 [ 9238.594496] ---[ end trace 183efbe50275f059 ]--- The sequence of steps leading to this is like the following: CPU 1 CPU 2 btrfs_dev_replace_finishing() at this point dev_replace->tgtdev->devid == BTRFS_DEV_REPLACE_DEVID (0ULL) ... btrfs_start_transaction() btrfs_commit_transaction() btrfs_delete_unused_bgs() btrfs_remove_chunk() looks up for the extent map corresponding to the chunk lock_chunks() (chunk_mutex) check_system_chunk() unlock_chunks() (chunk_mutex) locks fs_info->chunk_mutex btrfs_dev_replace_update_device_in_mapping_tree() --> iterates fs_info->mapping_tree and replaces the device in every extent map's map->stripes[] with dev_replace->tgtdev, which still has an id of 0ULL (BTRFS_DEV_REPLACE_DEVID) iterates over all stripes from the extent map --> calls btrfs_free_dev_extent() passing it the target device that still has an ID of 0ULL --> btrfs_free_dev_extent() fails --> aborts current transaction finishes setting up the target device, namely it sets tgtdev->devid to the value of srcdev->devid (which is necessarily > 0) frees the srcdev unlocks fs_info->chunk_mutex So fix this by taking the device list mutex while processing the stripes for the chunk's extent map. This is similar to the race between device replace and block group creation that was fixed by commit 50460e37186a ("Btrfs: fix race when finishing dev replace leading to transaction abort"). Signed-off-by: Filipe Manana <fdmanana@suse.com> Reviewed-by: Josef Bacik <jbacik@fb.com> 30 May 2016, 11:58:19 UTC
ce7791f Filipe Manana 20 May 2016, 00:57:20 UTC Btrfs: fix race between readahead and device replace/removal The list of devices is protected by the device_list_mutex and the device replace code, in its finishing phase correctly takes that mutex before removing the source device from that list. However the readahead code was iterating that list without acquiring the respective mutex leading to crashes later on due to invalid memory accesses: [125671.831036] general protection fault: 0000 [#1] PREEMPT SMP [125671.832129] Modules linked in: btrfs dm_flakey dm_mod crc32c_generic xor raid6_pq acpi_cpufreq tpm_tis tpm ppdev evdev parport_pc psmouse sg parport processor ser [125671.834973] CPU: 10 PID: 19603 Comm: kworker/u32:19 Tainted: G W 4.6.0-rc7-btrfs-next-29+ #1 [125671.834973] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS by qemu-project.org 04/01/2014 [125671.834973] Workqueue: btrfs-readahead btrfs_readahead_helper [btrfs] [125671.834973] task: ffff8801ac520540 ti: ffff8801ac918000 task.ti: ffff8801ac918000 [125671.834973] RIP: 0010:[<ffffffff81270479>] [<ffffffff81270479>] __radix_tree_lookup+0x6a/0x105 [125671.834973] RSP: 0018:ffff8801ac91bc28 EFLAGS: 00010206 [125671.834973] RAX: 0000000000000000 RBX: 6b6b6b6b6b6b6b6a RCX: 0000000000000000 [125671.834973] RDX: 0000000000000000 RSI: 00000000000c1bff RDI: ffff88002ebd62a8 [125671.834973] RBP: ffff8801ac91bc70 R08: 0000000000000001 R09: 0000000000000000 [125671.834973] R10: ffff8801ac91bc70 R11: 0000000000000000 R12: ffff88002ebd62a8 [125671.834973] R13: 0000000000000000 R14: 0000000000000000 R15: 00000000000c1bff [125671.834973] FS: 0000000000000000(0000) GS:ffff88023fd40000(0000) knlGS:0000000000000000 [125671.834973] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [125671.834973] CR2: 000000000073cae4 CR3: 00000000b7723000 CR4: 00000000000006e0 [125671.834973] Stack: [125671.834973] 0000000000000000 ffff8801422d5600 ffff8802286bbc00 0000000000000000 [125671.834973] 0000000000000001 ffff8802286bbc00 00000000000c1bff 0000000000000000 [125671.834973] ffff88002e639eb8 ffff8801ac91bc80 ffffffff81270541 ffff8801ac91bcb0 [125671.834973] Call Trace: [125671.834973] [<ffffffff81270541>] radix_tree_lookup+0xd/0xf [125671.834973] [<ffffffffa04ae6a6>] reada_peer_zones_set_lock+0x3e/0x60 [btrfs] [125671.834973] [<ffffffffa04ae8b9>] reada_pick_zone+0x29/0x103 [btrfs] [125671.834973] [<ffffffffa04af42f>] reada_start_machine_worker+0x129/0x2d3 [btrfs] [125671.834973] [<ffffffffa04880be>] btrfs_scrubparity_helper+0x185/0x3aa [btrfs] [125671.834973] [<ffffffffa0488341>] btrfs_readahead_helper+0xe/0x10 [btrfs] [125671.834973] [<ffffffff81069691>] process_one_work+0x271/0x4e9 [125671.834973] [<ffffffff81069dda>] worker_thread+0x1eb/0x2c9 [125671.834973] [<ffffffff81069bef>] ? rescuer_thread+0x2b3/0x2b3 [125671.834973] [<ffffffff8106f403>] kthread+0xd4/0xdc [125671.834973] [<ffffffff8149e242>] ret_from_fork+0x22/0x40 [125671.834973] [<ffffffff8106f32f>] ? kthread_stop+0x286/0x286 So fix this by taking the device_list_mutex in the readahead code. We can't use here the lighter approach of using a rcu_read_lock() and rcu_read_unlock() pair together with a list_for_each_entry_rcu() call because we end up doing calls to sleeping functions (kzalloc()) in the respective code path. Signed-off-by: Filipe Manana <fdmanana@suse.com> Reviewed-by: Josef Bacik <jbacik@fb.com> 30 May 2016, 11:58:18 UTC
9f9cd7e Aaron Lu 21 May 2016, 07:30:46 UTC ACPI / Thermal / video: fix max_level incorrect value commit 059500940def (ACPI/video: export acpi_video_get_levels) mistakenly dropped the correct value of max_level and that caused the set_level function following failed and the acpi_video backlight interface didn't get created. Fix this by passing back the correct max_level value. While at it, also fix the param used in acpi_video_device_lcd_query_levels where acpi_handle is expected but acpi_video_device is passed. Fixes: 059500940def (ACPI/video: export acpi_video_get_levels) Reported-and-tested-by: Valdis Kletnieks <valdis.kletnieks@vt.edu> Signed-off-by: Aaron Lu <aaron.lu@intel.com> Acked-by: Zhang Rui <rui.zhang@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> 30 May 2016, 11:53:09 UTC
9feeed9 Geert Uytterhoeven 22 May 2016, 09:06:13 UTC MAINTAINERS: Add file patterns for pinctrl device tree bindings Submitters of device tree binding documentation may forget to CC the subsystem maintainer if this is missing. Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Cc: Linus Walleij <linus.walleij@linaro.org> Cc: linux-gpio@vger.kernel.org Signed-off-by: Linus Walleij <linus.walleij@linaro.org> 30 May 2016, 07:42:37 UTC
6b1a7c9 Linus Walleij 24 May 2016, 12:39:47 UTC pinctrl: nomadik: fix inversion of gpio direction The input/output directions were inversed on the GPIO direction read function. Loose a ! and it is correct. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> 30 May 2016, 07:42:37 UTC
9c10280 Linus Walleij 25 May 2016, 08:56:03 UTC gpio: flush direction status in gpiochip_lock_as_irq() As irqchip and gpiochip functions are orthogonal, the IRQ set-up or something else can have changed the direction of the GPIO line from what the GPIO descriptor knows when we get into gpiochip_lock_as_irq(). Make sure to re-read the direction setting if we have the .get_direction() callback enabled for the chip. Else we get problems like this: iio iio:device2: interrupts on the rising edge gpio gpiochip2: (8012e080.gpio): gpiochip_lock_as_irq: tried to flag a GPIO set as output for IRQ gpio gpiochip2: (8012e080.gpio): unable to lock HW IRQ 0 for IRQ genirq: Failed to request resources for l3g4200d-trigger (irq 111) on irqchip nmk1-32-63 iio iio:device2: failed to request trigger IRQ. st-gyro-i2c: probe of 2-0068 failed with error -22 Fixes: 72d320006177 ("gpio: set up initial state from .get_direction()") Signed-off-by: Linus Walleij <linus.walleij@linaro.org> 30 May 2016, 07:42:03 UTC
320a648 Sylvain Lemieux 11 May 2016, 17:40:00 UTC gpio: lpc32xx: disable broken to_irq support The "to_irq" functionality is broken inside this driver since commit 76ba59f8366f ("genirq: Add irq_domain-aware core IRQ handler"). The addition of the new lpc32xx irqchip driver in 4.7, fixed the lpc32xx platform interrupt issue. When switching to the new lpc32xx irqchip driver, a warning appear in the lpc32xx gpio driver: warning: "NR_IRQS" redefined. To remove this warning (temporary solution), this patch disables the broken "to_irq" mapping functionality support. Signed-off-by: Sylvain Lemieux <slemieux@tycoint.com> Acked-by: Vladimir Zapolskiy <vz@mleia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> 30 May 2016, 07:42:03 UTC
151787b Liu Ying 24 May 2016, 10:10:41 UTC drm/imx: plane: Don't set plane->crtc in ipu_plane_update() Since the drm core sets plane->crtc correctly, we don't need to do that. Signed-off-by: Liu Ying <gnuiyl@gmail.com> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de> 30 May 2016, 07:14:00 UTC
8b3ce87 Liu Ying 24 May 2016, 10:10:40 UTC drm/imx: ipuv3-plane: Constify ipu_plane_funcs Signed-off-by: Liu Ying <gnuiyl@gmail.com> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de> 30 May 2016, 07:14:00 UTC
c82b4d7 Lothar Waßmann 24 May 2016, 06:31:49 UTC drm/imx: imx-ldb: honor 'native-mode' property when selecting video mode from DT This patch allows to select a specific video mode from a list of modes defined in DT by setting the 'native-mode' property appropriately. This change does not affect the behaviour of existing platforms, since they either: - have just one display-timings subnode - have the native-mode property pointing to the first entry - let the bootloader select the appropriate timing Signed-off-by: Lothar Waßmann <LW@KARO-electronics.de> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de> 30 May 2016, 07:14:00 UTC
97a6075 Lothar Waßmann 24 May 2016, 06:31:51 UTC drm/imx: parallel-display: remove dead code The 'mode_valid' flag is never set in this driver. Remove it and the code that depends on it. Signed-off-by: Lothar Waßmann <LW@KARO-electronics.de> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de> 30 May 2016, 07:14:00 UTC
4ed094f Philipp Zabel 09 May 2016, 15:02:13 UTC drm/imx: use bus_flags for pixel clock polarity This patch allows panels to set pixel clock and data enable pin polarity other than the default of driving data at the falling pixel clock edge and active high display enable. Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de> 30 May 2016, 07:14:00 UTC
7932131 Philipp Zabel 12 February 2016, 13:35:55 UTC drm/imx: ipuv3-plane: enable UYVY and VYUY formats Advertise the DRM_FORMAT_UYVY and DRM_FORMAT_VYUY formats to userspace. Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de> 30 May 2016, 07:14:00 UTC
3a1c117 Philipp Zabel 03 May 2016, 12:39:29 UTC drm/imx: parallel-display: use of_graph_get_endpoint_by_regs helper Instead of using of_graph_get_port_by_id() to get the port and then of_get_child_by_name() to get the first endpoint, get to the endpoint in a single step. Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de> 30 May 2016, 07:14:00 UTC
620011e Philipp Zabel 03 May 2016, 12:37:13 UTC drm/imx: imx-ldb: use of_graph_get_endpoint_by_regs helper Instead of using of_graph_get_port_by_id() to get the port and then of_get_child_by_name() to get the first endpoint, get to the endpoint in a single step. Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de> 30 May 2016, 07:14:00 UTC
ee89686 Akshay Bhat 27 April 2016, 20:23:34 UTC dt-bindings: imx: ldb: Add ddc-i2c-bus property Document the ddc-i2c-bus property used by imx-ldb driver to read EDID information via I2C interface. Signed-off-by: Akshay Bhat <akshay.bhat@timesys.com> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de> 30 May 2016, 07:14:00 UTC
a6d206e Steve Longerbeam 27 April 2016, 20:23:33 UTC drm/imx: imx-ldb: Add DDC support Add support for reading EDID over Display Data Channel. If no DDC adapter is available, falls back to hardcoded EDID or display-timings node as before. Signed-off-by: Steve Longerbeam <steve_longerbeam@mentor.com> Signed-off-by: Akshay Bhat <akshay.bhat@timesys.com> Acked-by: Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de> 30 May 2016, 07:14:00 UTC
0e6b525 Shmulik Ladkani 26 May 2016, 17:16:36 UTC net: l2tp: Make l2tp_ip6 namespace aware l2tp_ip6 tunnel and session lookups were still using init_net, although the l2tp core infrastructure already supports lookups keyed by 'net'. As a result, l2tp_ip6_recv discarded packets for tunnels/sessions created in namespaces other than the init_net. Fix, by using dev_net(skb->dev) or sock_net(sk) where appropriate. Signed-off-by: Shmulik Ladkani <shmulik.ladkani@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net> 30 May 2016, 07:03:53 UTC
176b346 Eric Garver 26 May 2016, 16:28:05 UTC Documentation: ip-sysctl.txt: clarify secure_redirects Clarify how secure_redirects works. Mention that RFC1122 always applies. Signed-off-by: Eric Garver <e@erig.me> Signed-off-by: David S. Miller <davem@davemloft.net> 30 May 2016, 05:40:53 UTC
68bb399 Edward Cree 26 May 2016, 20:46:05 UTC sfc: use flow dissector helpers for aRFS Signed-off-by: Edward Cree <ecree@solarflare.com> Signed-off-by: David S. Miller <davem@davemloft.net> 30 May 2016, 05:38:55 UTC
421eeea Baozeng Ding 26 May 2016, 13:07:42 UTC ieee802154: fix logic error in ieee802154_llsec_parse_dev_addr Fix a logic error to avoid potential null pointer dereference. Signed-off-by: Baozeng Ding <sploving1@gmail.com> Reviewed-by: Stefan Schmidt<stefan@osg.samsung.com> Signed-off-by: David S. Miller <davem@davemloft.net> 30 May 2016, 05:36:25 UTC
8665165 Elad Kanfi 26 May 2016, 12:00:06 UTC net: nps_enet: Disable interrupts before napi reschedule Since NAPI works by shutting down event interrupts when theres work and turning them on when theres none, the net driver must make sure that interrupts are disabled when it reschedules polling. By calling napi_reschedule, the driver switches to polling mode, therefor there should be no interrupt interference. Any received packets will be handled in nps_enet_poll by polling the HW indication of received packet until all packets are handled. Signed-off-by: Elad Kanfi <eladkan@mellanox.com> Acked-by: Noam Camus <noamca@mellanox.com> Tested-by: Alexey Brodkin <abrodkin@synopsys.com> Signed-off-by: David S. Miller <davem@davemloft.net> 30 May 2016, 05:35:21 UTC
0d08df6 Andy Shevchenko 26 May 2016, 11:43:52 UTC net/lapb: tuse %*ph to dump buffers Use %*ph specifier to dump small buffers in hex format instead doing this byte-by-byte. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: David S. Miller <davem@davemloft.net> 30 May 2016, 05:33:25 UTC
6756325 Dan Carpenter 26 May 2016, 06:46:22 UTC ptp: oops in ptp_ioctl() If we pass ERR_PTR(-EFAULT) to kfree() then it's going to oops. Fixes: 2ece068e1b1d ('ptp: use memdup_user().') Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Acked-by: Richard Cochran <richardcochran@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net> 30 May 2016, 05:32:27 UTC
fabb13d Arnd Bergmann 25 May 2016, 14:50:46 UTC fou: add Kconfig options for IPv6 support A previous patch added the fou6.ko module, but that failed to link in a couple of configurations: net/built-in.o: In function `ip6_tnl_encap_add_fou_ops': net/ipv6/fou6.c:88: undefined reference to `ip6_tnl_encap_add_ops' net/ipv6/fou6.c:94: undefined reference to `ip6_tnl_encap_add_ops' net/ipv6/fou6.c:97: undefined reference to `ip6_tnl_encap_del_ops' net/built-in.o: In function `ip6_tnl_encap_del_fou_ops': net/ipv6/fou6.c:106: undefined reference to `ip6_tnl_encap_del_ops' net/ipv6/fou6.c:107: undefined reference to `ip6_tnl_encap_del_ops' If CONFIG_IPV6=m, ip6_tnl_encap_add_ops/ip6_tnl_encap_del_ops are in a module, but fou6.c can still be built-in, and that obviously fails to link. Also, if CONFIG_IPV6=y, but CONFIG_IPV6_TUNNEL=m or CONFIG_IPV6_TUNNEL=n, the same problem happens for a different reason. This adds two new silent Kconfig symbols to work around both problems: - CONFIG_IPV6_FOU is now always set to 'm' if either CONFIG_NET_FOU=m or CONFIG_IPV6=m - CONFIG_IPV6_FOU_TUNNEL is set implicitly when IPV6_FOU is enabled and NET_FOU_IP_TUNNELS is also turned out, and it will ensure that CONFIG_IPV6_TUNNEL is also available. The options could be made user-visible as well, to give additional room for configuration, but it seems easier not to bother users with more choice here. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Fixes: aa3463d65e7b ("fou: Add encap ops for IPv6 tunnels") Signed-off-by: David S. Miller <davem@davemloft.net> 30 May 2016, 05:24:21 UTC
9791d8e Arnd Bergmann 25 May 2016, 14:50:45 UTC ipv6: hide ip6_encap_hlen/ip6_tnl_encap definitions A recent cleanup moved MAX_IPTUN_ENCAP_OPS along with some other definitions, but it is now invisible when CONFIG_INET is not defined, but still referenced from ip6_tunnel.h: In file included from net/xfrm/xfrm_input.c:17:0: include/net/ip6_tunnel.h:67:17: error: 'MAX_IPTUN_ENCAP_OPS' undeclared here (not in a function) ip6tun_encaps[MAX_IPTUN_ENCAP_OPS]; ^~~~~~~~~~~~~~~~~~~ This hides the ip6_encap_hlen and ip6_tnl_encap functions inside of CONFIG_INET so we don't run into the the problem. Alternatively we could move the macro out of the #ifdef again to restore the previous behavior Signed-off-by: Arnd Bergmann <arnd@arndb.de> Fixes: 55c2bc143224 ("net: Cleanup encap items in ip_tunnels.h") Signed-off-by: David S. Miller <davem@davemloft.net> 30 May 2016, 05:24:21 UTC
bd000b8 Russell Currey 07 April 2016, 06:28:27 UTC powerpc/pseries/eeh: Refactor the configure_bridge RTAS tokens The RTAS calls "ibm,configure-pe" and "ibm,configure-bridge" perform the same actions, however the former can skip configuration if unnecessary. The existing code treats them as different tokens even though only one will ever be called. Refactor this by making a single token that is assigned during init. Signed-off-by: Russell Currey <ruscur@russell.cc> Acked-by: Gavin Shan <gwshan@linux.vnet.ibm.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> 30 May 2016, 03:50:12 UTC
871e178 Russell Currey 07 April 2016, 06:28:26 UTC powerpc/pseries/eeh: Handle RTAS delay requests in configure_bridge In the "ibm,configure-pe" and "ibm,configure-bridge" RTAS calls, the spec states that values of 9900-9905 can be returned, indicating that software should delay for 10^x (where x is the last digit, i.e. 990x) milliseconds and attempt the call again. Currently, the kernel doesn't know about this, and respecting it fixes some PCI failures when the hypervisor is busy. The delay is capped at 0.2 seconds. Cc: <stable@vger.kernel.org> # 3.10+ Signed-off-by: Russell Currey <ruscur@russell.cc> Acked-by: Gavin Shan <gwshan@linux.vnet.ibm.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> 30 May 2016, 03:50:04 UTC
7cafc0b David S. Miller 29 May 2016, 03:41:12 UTC sparc64: Fix return from trap window fill crashes. We must handle data access exception as well as memory address unaligned exceptions from return from trap window fill faults, not just normal TLB misses. Otherwise we can get an OOPS that looks like this: ld-linux.so.2(36808): Kernel bad sw trap 5 [#1] CPU: 1 PID: 36808 Comm: ld-linux.so.2 Not tainted 4.6.0 #34 task: fff8000303be5c60 ti: fff8000301344000 task.ti: fff8000301344000 TSTATE: 0000004410001601 TPC: 0000000000a1a784 TNPC: 0000000000a1a788 Y: 00000002 Not tainted TPC: <do_sparc64_fault+0x5c4/0x700> g0: fff8000024fc8248 g1: 0000000000db04dc g2: 0000000000000000 g3: 0000000000000001 g4: fff8000303be5c60 g5: fff800030e672000 g6: fff8000301344000 g7: 0000000000000001 o0: 0000000000b95ee8 o1: 000000000000012b o2: 0000000000000000 o3: 0000000200b9b358 o4: 0000000000000000 o5: fff8000301344040 sp: fff80003013475c1 ret_pc: 0000000000a1a77c RPC: <do_sparc64_fault+0x5bc/0x700> l0: 00000000000007ff l1: 0000000000000000 l2: 000000000000005f l3: 0000000000000000 l4: fff8000301347e98 l5: fff8000024ff3060 l6: 0000000000000000 l7: 0000000000000000 i0: fff8000301347f60 i1: 0000000000102400 i2: 0000000000000000 i3: 0000000000000000 i4: 0000000000000000 i5: 0000000000000000 i6: fff80003013476a1 i7: 0000000000404d4c I7: <user_rtt_fill_fixup+0x6c/0x7c> Call Trace: [0000000000404d4c] user_rtt_fill_fixup+0x6c/0x7c The window trap handlers are slightly clever, the trap table entries for them are composed of two pieces of code. First comes the code that actually performs the window fill or spill trap handling, and then there are three instructions at the end which are for exception processing. The userland register window fill handler is: add %sp, STACK_BIAS + 0x00, %g1; \ ldxa [%g1 + %g0] ASI, %l0; \ mov 0x08, %g2; \ mov 0x10, %g3; \ ldxa [%g1 + %g2] ASI, %l1; \ mov 0x18, %g5; \ ldxa [%g1 + %g3] ASI, %l2; \ ldxa [%g1 + %g5] ASI, %l3; \ add %g1, 0x20, %g1; \ ldxa [%g1 + %g0] ASI, %l4; \ ldxa [%g1 + %g2] ASI, %l5; \ ldxa [%g1 + %g3] ASI, %l6; \ ldxa [%g1 + %g5] ASI, %l7; \ add %g1, 0x20, %g1; \ ldxa [%g1 + %g0] ASI, %i0; \ ldxa [%g1 + %g2] ASI, %i1; \ ldxa [%g1 + %g3] ASI, %i2; \ ldxa [%g1 + %g5] ASI, %i3; \ add %g1, 0x20, %g1; \ ldxa [%g1 + %g0] ASI, %i4; \ ldxa [%g1 + %g2] ASI, %i5; \ ldxa [%g1 + %g3] ASI, %i6; \ ldxa [%g1 + %g5] ASI, %i7; \ restored; \ retry; nop; nop; nop; nop; \ b,a,pt %xcc, fill_fixup_dax; \ b,a,pt %xcc, fill_fixup_mna; \ b,a,pt %xcc, fill_fixup; And the way this works is that if any of those memory accesses generate an exception, the exception handler can revector to one of those final three branch instructions depending upon which kind of exception the memory access took. In this way, the fault handler doesn't have to know if it was a spill or a fill that it's handling the fault for. It just always branches to the last instruction in the parent trap's handler. For example, for a regular fault, the code goes: winfix_trampoline: rdpr %tpc, %g3 or %g3, 0x7c, %g3 wrpr %g3, %tnpc done All window trap handlers are 0x80 aligned, so if we "or" 0x7c into the trap time program counter, we'll get that final instruction in the trap handler. On return from trap, we have to pull the register window in but we do this by hand instead of just executing a "restore" instruction for several reasons. The largest being that from Niagara and onward we simply don't have enough levels in the trap stack to fully resolve all possible exception cases of a window fault when we are already at trap level 1 (which we enter to get ready to return from the original trap). This is executed inline via the FILL_*_RTRAP handlers. rtrap_64.S's code branches directly to these to do the window fill by hand if necessary. Now if you look at them, we'll see at the end: ba,a,pt %xcc, user_rtt_fill_fixup; ba,a,pt %xcc, user_rtt_fill_fixup; ba,a,pt %xcc, user_rtt_fill_fixup; And oops, all three cases are handled like a fault. This doesn't work because each of these trap types (data access exception, memory address unaligned, and faults) store their auxiliary info in different registers to pass on to the C handler which does the real work. So in the case where the stack was unaligned, the unaligned trap handler sets up the arg registers one way, and then we branched to the fault handler which expects them setup another way. So the FAULT_TYPE_* value ends up basically being garbage, and randomly would generate the backtrace seen above. Reported-by: Nick Alcock <nix@esperi.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net> 30 May 2016, 01:55:54 UTC
b02b1fb Linus Torvalds 29 May 2016, 20:28:39 UTC Merge tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi Pull SCSI fixes from James Bottomley: "This is a set of four fixes noticed in the merge window. The aacraid one is an optimisation, the mp3sas one fixes a spurious printk, the sd_check_events one fixes a theoretical race and the failed zero length commands fixes a bug in our completion/retry routines that has been causing problems in the field" * tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi: aacraid: do not activate events on non-SRC adapters mpt3sas: add missing curly braces sd: get disk reference in sd_check_events() scsi_lib: correctly retry failed zero length REQ_TYPE_FS commands 29 May 2016, 20:28:39 UTC
d11c2a0 David S. Miller 29 May 2016, 04:21:31 UTC sparc: Harden signal return frame checks. All signal frames must be at least 16-byte aligned, because that is the alignment we explicitly create when we build signal return stack frames. All stack pointers must be at least 8-byte aligned. Signed-off-by: David S. Miller <davem@davemloft.net> 29 May 2016, 18:24:05 UTC
back to top