swh:1:snp:c3bf2749e3476071fa748f67b0ffa2fdc5fe49d9
- v6.0-rc5
- v6.0-rc4
- v6.0-rc3
- v6.0-rc2
- v6.0-rc1
- v5.9-rc8
- v5.9-rc7
- v5.9-rc6
- v5.9-rc5
- v5.9-rc4
- v5.9-rc3
- v5.9-rc2
- v5.9-rc1
- v5.9
- v5.8-rc7
- v5.8-rc6
- v5.8-rc5
- v5.8-rc4
- v5.8-rc3
- v5.8-rc2
- v5.8-rc1
- v5.8
- v5.7-rc7
- v5.7-rc6
- v5.7-rc5
- v5.7-rc4
- v5.7-rc3
- v5.7-rc2
- v5.7-rc1
- v5.7
- v5.6-rc7
- v5.6-rc6
- v5.6-rc5
- v5.6-rc4
- v5.6-rc3
- v5.6-rc2
- v5.6-rc1
- v5.6
- v5.5-rc7
- v5.5-rc6
- v5.5-rc5
- v5.5-rc4
- v5.5-rc3
- v5.5-rc2
- v5.5-rc1
- v5.5
- v5.4-rc8
- v5.4-rc7
- v5.4-rc6
- v5.4-rc5
- v5.4-rc4
- v5.4-rc3
- v5.4-rc2
- v5.4-rc1
- v5.4
- v5.3-rc8
- v5.3-rc7
- v5.3-rc6
- v5.3-rc5
- v5.3-rc4
- v5.3-rc3
- v5.3-rc2
- v5.3-rc1
- v5.3
- v5.2-rc7
- v5.2-rc6
- v5.2-rc5
- v5.2-rc4
- v5.2-rc3
- v5.2-rc2
- v5.2-rc1
- v5.2
- v5.19-rc8
- v5.19-rc7
- v5.19-rc6
- v5.19-rc5
- v5.19-rc4
- v5.19-rc3
- v5.19-rc2
- v5.19-rc1
- v5.19
- v5.18-rc7
- v5.18-rc6
- v5.18-rc5
- v5.18-rc4
- v5.18-rc3
- v5.18-rc2
- v5.18-rc1
- v5.18
- v5.17-rc8
- v5.17-rc7
- v5.17-rc6
- v5.17-rc5
- v5.17-rc4
- v5.17-rc3
- v5.17-rc2
- v5.17-rc1
- v5.17
- v5.16-rc8
- v5.16-rc7
- v5.16-rc6
- v5.16-rc5
- v5.16-rc4
- v5.16-rc3
- v5.16-rc2
- v5.16-rc1
- v5.16
- v5.15-rc7
- v5.15-rc6
- v5.15-rc5
- v5.15-rc4
- v5.15-rc3
- v5.15-rc2
- v5.15-rc1
- v5.15
- v5.14-rc7
- v5.14-rc6
- v5.14-rc5
- v5.14-rc4
- v5.14-rc3
- v5.14-rc2
- v5.14-rc1
- v5.14
- v5.13-rc7
- v5.13-rc6
- v5.13-rc5
- v5.13-rc4
- v5.13-rc3
- v5.13-rc2
- v5.13-rc1
- v5.13
- v5.12-rc8
- v5.12-rc7
- v5.12-rc6
- v5.12-rc5
- v5.12-rc4
- v5.12-rc3
- v5.12-rc2
- v5.12-rc1
- v5.12
- v5.11-rc7
- v5.11-rc6
- v5.11-rc5
- v5.11-rc4
- v5.11-rc3
- v5.11-rc2
- v5.11-rc1
- v5.11
- v5.10-rc7
- v5.10-rc6
- v5.10-rc5
- v5.10-rc4
- v5.10-rc3
- v5.10-rc2
- v5.10-rc1
- v5.10
- v5.1-rc7
- v5.1-rc6
- v5.1-rc5
- v5.1-rc4
- v5.1-rc3
- v5.1-rc2
- v5.1-rc1
- v5.1
- v5.0-rc8
- v5.0-rc7
- v5.0-rc6
- v5.0-rc5
- v5.0-rc4
- v5.0-rc3
- v5.0-rc2
- v5.0-rc1
- v5.0
- v4.9-rc8
- v4.9-rc7
- v4.9-rc6
- v4.9-rc5
- v4.9-rc4
- v4.9-rc3
- v4.9-rc2
- v4.9-rc1
- v4.9
- v4.8-rc8
- v4.8-rc7
- v4.8-rc6
- v4.8-rc5
- v4.8-rc4
- v4.8-rc3
- v4.8-rc2
- v4.8-rc1
- v4.8
- v4.7-rc7
- v4.7-rc6
- v4.7-rc5
- v4.7-rc4
- v4.7-rc3
- v4.7-rc2
- v4.7-rc1
- v4.7
- v4.6-rc7
- v4.6-rc6
- v4.6-rc5
- v4.6-rc4
- v4.6-rc3
- v4.6-rc2
- v4.6-rc1
- v4.6
- v4.5-rc7
- v4.5-rc6
- v4.5-rc5
- v4.5-rc4
- v4.5-rc3
- v4.5-rc2
- v4.5-rc1
- v4.5
- v4.4-rc8
- v4.4-rc7
- v4.4-rc6
- v4.4-rc5
- v4.4-rc4
- v4.4-rc3
- v4.4-rc2
- v4.4-rc1
- v4.4
- v4.3-rc7
- v4.3-rc6
- v4.3-rc5
- v4.3-rc4
- v4.3-rc3
- v4.3-rc2
- v4.3-rc1
- v4.3
- v4.20-rc7
- v4.20-rc6
- v4.20-rc5
- v4.20-rc4
- v4.20-rc3
- v4.20-rc2
- v4.20-rc1
- v4.20
- v4.2-rc8
- v4.2-rc7
- v4.2-rc6
- v4.2-rc5
- v4.2-rc4
- v4.2-rc3
- v4.2-rc2
- v4.2-rc1
- v4.2
- v4.19-rc8
- v4.19-rc7
- v4.19-rc6
- v4.19-rc5
- v4.19-rc4
- v4.19-rc3
- v4.19-rc2
- v4.19-rc1
- v4.19
- v4.18-rc8
- v4.18-rc7
- v4.18-rc6
- v4.18-rc5
- v4.18-rc4
- v4.18-rc3
- v4.18-rc2
- v4.18-rc1
- v4.18
- v4.17-rc7
- v4.17-rc6
- v4.17-rc5
- v4.17-rc4
- v4.17-rc3
- v4.17-rc2
- v4.17-rc1
- v4.17
- v4.16-rc7
- v4.16-rc6
- v4.16-rc5
- v4.16-rc4
- v4.16-rc3
- v4.16-rc2
- v4.16-rc1
- v4.16
- v4.15-rc9
- v4.15-rc8
- v4.15-rc7
- v4.15-rc6
- v4.15-rc5
- v4.15-rc4
- v4.15-rc3
- v4.15-rc2
- v4.15-rc1
- v4.15
- v4.14-rc8
- v4.14-rc7
- v4.14-rc6
- v4.14-rc5
- v4.14-rc4
- v4.14-rc3
- v4.14-rc2
- v4.14-rc1
- v4.14
- v4.13-rc7
- v4.13-rc6
- v4.13-rc5
- v4.13-rc4
- v4.13-rc3
- v4.13-rc2
- v4.13-rc1
- v4.13
- v4.12-rc7
- v4.12-rc6
- v4.12-rc5
- v4.12-rc4
- v4.12-rc3
- v4.12-rc2
- v4.12-rc1
- v4.12
- v4.11-rc8
- v4.11-rc7
- v4.11-rc6
- v4.11-rc5
- v4.11-rc4
- v4.11-rc3
- v4.11-rc2
- v4.11-rc1
- v4.11
- v4.10-rc8
- v4.10-rc7
- v4.10-rc6
- v4.10-rc5
- v4.10-rc4
- v4.10-rc3
- v4.10-rc2
- v4.10-rc1
- v4.10
- v4.1-rc8
- v4.1-rc7
- v4.1-rc6
- v4.1-rc5
- v4.1-rc4
- v4.1-rc3
- v4.1-rc2
- v4.1-rc1
- v4.1
- v4.0-rc7
- v4.0-rc6
- v4.0-rc5
- v4.0-rc4
- v4.0-rc3
- v4.0-rc2
- v4.0-rc1
- v4.0
- v3.9-rc8
- v3.9-rc7
- v3.9-rc6
- v3.9-rc5
- v3.9-rc4
- v3.9-rc3
- v3.9-rc2
- v3.9-rc1
- v3.9
- v3.8-rc7
- v3.8-rc6
- v3.8-rc5
- v3.8-rc4
- v3.8-rc3
- v3.8-rc2
- v3.8-rc1
- v3.8
- v3.7-rc8
- v3.7-rc7
- v3.7-rc6
- v3.7-rc5
- v3.7-rc4
- v3.7-rc3
- v3.7-rc2
- v3.7-rc1
- v3.7
- v3.6-rc7
- v3.6-rc6
- v3.6-rc5
- v3.6-rc4
- v3.6-rc3
- v3.6-rc2
- v3.6-rc1
- v3.6
- v3.5-rc7
- v3.5-rc6
- v3.5-rc5
- v3.5-rc4
- v3.5-rc3
- v3.5-rc2
- v3.5-rc1
- v3.5
- v3.4-rc7
- v3.4-rc6
- v3.4-rc5
- v3.4-rc4
- v3.4-rc3
- v3.4-rc2
- v3.4-rc1
- v3.4
- v3.3-rc7
- v3.3-rc6
- v3.3-rc5
- v3.3-rc4
- v3.3-rc3
- v3.3-rc2
- v3.3-rc1
- v3.3
- v3.2-rc7
- v3.2-rc6
- v3.2-rc5
- v3.2-rc4
- v3.2-rc3
- v3.2-rc2
- v3.2-rc1
- v3.2
- v3.19-rc7
- v3.19-rc6
- v3.19-rc5
- v3.19-rc4
- v3.19-rc3
- v3.19-rc2
- v3.19-rc1
- v3.19
- v3.18-rc7
- v3.18-rc6
- v3.18-rc5
- v3.18-rc4
- v3.18-rc3
- v3.18-rc2
- v3.18-rc1
- v3.18
- v3.17-rc7
- v3.17-rc6
- v3.17-rc5
- v3.17-rc4
- v3.17-rc3
- v3.17-rc2
- v3.17-rc1
- v3.17
- v3.16-rc7
- v3.16-rc6
- v3.16-rc5
- v3.16-rc4
- v3.16-rc3
- v3.16-rc2
- v3.16-rc1
- v3.16
- v3.15-rc8
- v3.15-rc7
- v3.15-rc6
- v3.15-rc5
- v3.15-rc4
- v3.15-rc3
- v3.15-rc2
- v3.15-rc1
- v3.15
- v3.14-rc8
- v3.14-rc7
- v3.14-rc6
- v3.14-rc5
- v3.14-rc4
- v3.14-rc3
- v3.14-rc2
- v3.14-rc1
- v3.14
- v3.13-rc8
- v3.13-rc7
- v3.13-rc6
- v3.13-rc5
- v3.13-rc4
- v3.13-rc3
- v3.13-rc2
- v3.13-rc1
- v3.13
- v3.12-rc7
- v3.12-rc6
- v3.12-rc5
- v3.12-rc4
- v3.12-rc3
- v3.12-rc2
- v3.12-rc1
- v3.12
- v3.11-rc7
- v3.11-rc6
- v3.11-rc5
- v3.11-rc4
- v3.11-rc3
- v3.11-rc2
- v3.11-rc1
- v3.11
- v3.10-rc7
- v3.10-rc6
- v3.10-rc5
- v3.10-rc4
- v3.10-rc3
- v3.10-rc2
- v3.10-rc1
- v3.10
- v3.1-rc9
- v3.1-rc8
- v3.1-rc7
- v3.1-rc6
- v3.1-rc5
- v3.1-rc4
- v3.1-rc3
- v3.1-rc2
- v3.1-rc10
- v3.1-rc1
- v3.1
- v3.0-rc7
- v3.0-rc6
- v3.0-rc5
- v3.0-rc4
- v3.0-rc3
- v3.0-rc2
- v3.0-rc1
- v3.0
- v2.6.39-rc7
- v2.6.39-rc6
- v2.6.39-rc5
- v2.6.39-rc4
- v2.6.39-rc3
- v2.6.39-rc2
- v2.6.39-rc1
- v2.6.39
- v2.6.38-rc8
- v2.6.38-rc7
- v2.6.38-rc6
- v2.6.38-rc5
- v2.6.38-rc4
- v2.6.38-rc3
- v2.6.38-rc2
- v2.6.38-rc1
- v2.6.38
- v2.6.37-rc8
- v2.6.37-rc7
- v2.6.37-rc6
- v2.6.37-rc5
- v2.6.37-rc4
- v2.6.37-rc3
- v2.6.37-rc2
- v2.6.37-rc1
- v2.6.37
- v2.6.36-rc8
- v2.6.36-rc7
- v2.6.36-rc6
- v2.6.36-rc5
- v2.6.36-rc4
- v2.6.36-rc3
- v2.6.36-rc2
- v2.6.36-rc1
- v2.6.36
- v2.6.35-rc6
- v2.6.35-rc5
- v2.6.35-rc4
- v2.6.35-rc3
- v2.6.35-rc2
- v2.6.35-rc1
- v2.6.35
- v2.6.34-rc7
- v2.6.34-rc6
- v2.6.34-rc5
- v2.6.34-rc4
- v2.6.34-rc3
- v2.6.34-rc2
- v2.6.34-rc1
- v2.6.34
- v2.6.33-rc8
- v2.6.33-rc7
- v2.6.33-rc6
- v2.6.33-rc5
- v2.6.33-rc4
- v2.6.33-rc3
- v2.6.33-rc2
- v2.6.33-rc1
- v2.6.33
- v2.6.32-rc8
- v2.6.32-rc7
- v2.6.32-rc6
- v2.6.32-rc5
- v2.6.32-rc4
- v2.6.32-rc3
- v2.6.32-rc1
- v2.6.32
- v2.6.31-rc9
- v2.6.31-rc8
- v2.6.31-rc7
- v2.6.31-rc6
- v2.6.31-rc5
- v2.6.31-rc4
- v2.6.31-rc3
- v2.6.31-rc2
- v2.6.31-rc1
- v2.6.31
- v2.6.30-rc8
- v2.6.30-rc7
- v2.6.30-rc6
- v2.6.30-rc5
- v2.6.30-rc4
- v2.6.30-rc3
- v2.6.30-rc2
- v2.6.30-rc1
- v2.6.30
- v2.6.29-rc8
- v2.6.29-rc7
- v2.6.29-rc6
- v2.6.29-rc5
- v2.6.29-rc4
- v2.6.29-rc3
- v2.6.29-rc2
- v2.6.29-rc1
- v2.6.29
- v2.6.28-rc9
- v2.6.28-rc8
- v2.6.28-rc7
- v2.6.28-rc6
- v2.6.28-rc5
- v2.6.28-rc4
- v2.6.28-rc3
- v2.6.28-rc2
- v2.6.28-rc1
- v2.6.28
- v2.6.27-rc9
- v2.6.27-rc8
- v2.6.27-rc7
- v2.6.27-rc6
- v2.6.27-rc5
- v2.6.27-rc4
- v2.6.27-rc3
- v2.6.27-rc2
- v2.6.27-rc1
- v2.6.27
- v2.6.26-rc9
- v2.6.26-rc8
- v2.6.26-rc7
- v2.6.26-rc6
- v2.6.26-rc5
- v2.6.26-rc4
- v2.6.26-rc3
- v2.6.26-rc2
- v2.6.26-rc1
- v2.6.26
- v2.6.25-rc9
- v2.6.25-rc8
- v2.6.25-rc7
- v2.6.25-rc6
- v2.6.25-rc5
- v2.6.25-rc4
- v2.6.25-rc3
- v2.6.25-rc2
- v2.6.25-rc1
- v2.6.25
- v2.6.24-rc8
- v2.6.24-rc7
- v2.6.24-rc6
- v2.6.24-rc5
- v2.6.24-rc4
- v2.6.24-rc3
- v2.6.24-rc2
- v2.6.24-rc1
- v2.6.24
- v2.6.23-rc9
- v2.6.23-rc8
- v2.6.23-rc7
- v2.6.23-rc6
- v2.6.23-rc5
- v2.6.23-rc4
- v2.6.23-rc3
- v2.6.23-rc2
- v2.6.23-rc1
- v2.6.23
- v2.6.22-rc7
- v2.6.22-rc6
- v2.6.22-rc5
- v2.6.22-rc4
- v2.6.22-rc3
- v2.6.22-rc2
- v2.6.22-rc1
- v2.6.22
- v2.6.21-rc7
- v2.6.21-rc6
- v2.6.21-rc5
- v2.6.21-rc4
- v2.6.21-rc3
- v2.6.21-rc2
- v2.6.21-rc1
- v2.6.21
- v2.6.20-rc7
- v2.6.20-rc6
- v2.6.20-rc5
- v2.6.20-rc4
- v2.6.20-rc3
- v2.6.20-rc2
- v2.6.20-rc1
- v2.6.20
- v2.6.19-rc6
- v2.6.19-rc5
- v2.6.19-rc4
- v2.6.19-rc3
- v2.6.19-rc2
- v2.6.19-rc1
- v2.6.19
- v2.6.18-rc7
- v2.6.18-rc6
- v2.6.18-rc5
- v2.6.18-rc4
- v2.6.18-rc3
- v2.6.18-rc2
- v2.6.18-rc1
- v2.6.18
- v2.6.17-rc6
- v2.6.17-rc5
- v2.6.17-rc4
- v2.6.17-rc3
- v2.6.17-rc2
- v2.6.17-rc1
- v2.6.17
- v2.6.16-rc6
- v2.6.16-rc5
- v2.6.16-rc4
- v2.6.16-rc3
- v2.6.16-rc2
- v2.6.16-rc1
- v2.6.16
- v2.6.15-rc7
- v2.6.15-rc6
- v2.6.15-rc5
- v2.6.15-rc4
- v2.6.15-rc3
- v2.6.15-rc2
- v2.6.15-rc1
- v2.6.15
- v2.6.14-rc5
- v2.6.14-rc4
- v2.6.14-rc3
- v2.6.14-rc2
- v2.6.14-rc1
- v2.6.14
- v2.6.13-rc7
- v2.6.13-rc6
- v2.6.13-rc5
- v2.6.13-rc4
- v2.6.13-rc3
- v2.6.13-rc2
- v2.6.13-rc1
- v2.6.13
- v2.6.12-rc6
- v2.6.12-rc5
- v2.6.12-rc4
- v2.6.12-rc3
- v2.6.12-rc2
- v2.6.12
- v2.6.11-tree
Permalinks
To reference or cite the objects present in the Software Heritage archive, permalinks based on SoftWare Hash IDentifiers (SWHIDs) must be used.
Select below a type of object currently browsed in order to display its associated SWHID and permalink.
Revision | Author | Date | Message | Commit Date |
---|---|---|---|---|
bf30824 | Andre Przywara | 11 May 2018, 14:20:14 UTC | KVM: arm/arm64: VGIC/ITS: protect kvm_read_guest() calls with SRCU lock kvm_read_guest() will eventually look up in kvm_memslots(), which requires either to hold the kvm->slots_lock or to be inside a kvm->srcu critical section. In contrast to x86 and s390 we don't take the SRCU lock on every guest exit, so we have to do it individually for each kvm_read_guest() call. Provide a wrapper which does that and use that everywhere. Note that ending the SRCU critical section before returning from the kvm_read_guest() wrapper is safe, because the data has been *copied*, so we don't need to rely on valid references to the memslot anymore. Cc: Stable <stable@vger.kernel.org> # 4.8+ Reported-by: Jan Glauber <jan.glauber@caviumnetworks.com> Signed-off-by: Andre Przywara <andre.przywara@arm.com> Acked-by: Christoffer Dall <christoffer.dall@arm.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> | 15 May 2018, 11:36:49 UTC |
9c41887 | Andre Przywara | 11 May 2018, 14:20:13 UTC | KVM: arm/arm64: VGIC/ITS: Promote irq_lock() in update_affinity Apparently the development of update_affinity() overlapped with the promotion of irq_lock to be _irqsave, so the patch didn't convert this lock over. This will make lockdep complain. Fix this by disabling IRQs around the lock. Cc: stable@vger.kernel.org Fixes: 08c9fd042117 ("KVM: arm/arm64: vITS: Add a helper to update the affinity of an LPI") Reported-by: Jan Glauber <jan.glauber@caviumnetworks.com> Signed-off-by: Andre Przywara <andre.przywara@arm.com> Acked-by: Christoffer Dall <christoffer.dall@arm.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> | 15 May 2018, 11:36:44 UTC |
388d435 | Andre Przywara | 11 May 2018, 14:20:12 UTC | KVM: arm/arm64: Properly protect VGIC locks from IRQs As Jan reported [1], lockdep complains about the VGIC not being bullet proof. This seems to be due to two issues: - When commit 006df0f34930 ("KVM: arm/arm64: Support calling vgic_update_irq_pending from irq context") promoted irq_lock and ap_list_lock to _irqsave, we forgot two instances of irq_lock. lockdeps seems to pick those up. - If a lock is _irqsave, any other locks we take inside them should be _irqsafe as well. So the lpi_list_lock needs to be promoted also. This fixes both issues by simply making the remaining instances of those locks _irqsave. One irq_lock is addressed in a separate patch, to simplify backporting. [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2018-May/575718.html Cc: stable@vger.kernel.org Fixes: 006df0f34930 ("KVM: arm/arm64: Support calling vgic_update_irq_pending from irq context") Reported-by: Jan Glauber <jan.glauber@caviumnetworks.com> Acked-by: Christoffer Dall <christoffer.dall@arm.com> Signed-off-by: Andre Przywara <andre.przywara@arm.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> | 15 May 2018, 11:36:27 UTC |
497a079 | Philippe Bergheaud | 14 May 2018, 08:27:36 UTC | cxl: Report the tunneled operations status Failure to synchronize the tunneled operations does not prevent the initialization of the cxl card. This patch reports the tunneled operations status via /sys. Signed-off-by: Philippe Bergheaud <felix@linux.ibm.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> | 15 May 2018, 11:30:01 UTC |
401dca8 | Philippe Bergheaud | 14 May 2018, 08:27:35 UTC | cxl: Set the PBCQ Tunnel BAR register when enabling capi mode Skiboot used to set the default Tunnel BAR register value when capi mode was enabled. This approach was ok for the cxl driver, but prevented other drivers from choosing different values. Skiboot versions > 5.11 will not set the default value any longer. This patch modifies the cxl driver to set/reset the Tunnel BAR register when entering/exiting the cxl mode, with pnv_pci_set_tunnel_bar(). That should work with old skiboot (since we are re-writing the value already set) and new skiboot. mpe: The tunnel support was only merged into Linux recently, in commit d6a90bb83b50 ("powerpc/powernv: Enable tunneled operations") (v4.17-rc1), so with new skiboot kernels between that commit and this will not work correctly. Fixes: d6a90bb83b50 ("powerpc/powernv: Enable tunneled operations") Signed-off-by: Philippe Bergheaud <felix@linux.ibm.com> Reviewed-by: Christophe Lombard <clombard@linux.vnet.ibm.com> Acked-by: Frederic Barrat <fbarrat@linux.vnet.ibm.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> | 15 May 2018, 11:29:53 UTC |
72cb0d8 | Eric Anholt | 09 April 2018, 20:58:13 UTC | drm/vc4: Fix leak of the file_priv that stored the perfmon. Signed-off-by: Eric Anholt <eric@anholt.net> Fixes: 65101d8c9108 ("drm/vc4: Expose performance counters to userspace") Link: https://patchwork.freedesktop.org/patch/msgid/20180409205813.7077-1-eric@anholt.net Reviewed-by: Boris Brezillon <boris.brezillon@bootlin.com> Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> | 15 May 2018, 11:25:33 UTC |
4c27625 | Wanpeng Li | 05 May 2018, 11:02:32 UTC | KVM: X86: Lower the default timer frequency limit to 200us Anthoine reported: The period used by Windows change over time but it can be 1 milliseconds or less. I saw the limit_periodic_timer_frequency print so 500 microseconds is sometimes reached. As suggested by Paolo, lower the default timer frequency limit to a smaller interval of 200 us (5000 Hz) to leave some headroom. This is required due to Windows 10 changing the scheduler tick limit from 1024 Hz to 2048 Hz. Reported-by: Anthoine Bourgeois <anthoine.bourgeois@blade-group.com> Suggested-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Darren Kenny <darren.kenny@oracle.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Radim Krčmář <rkrcmar@redhat.com> Cc: Anthoine Bourgeois <anthoine.bourgeois@blade-group.com> Cc: Darren Kenny <darren.kenny@oracle.com> Cc: Jan Kiszka <jan.kiszka@web.de> Signed-off-by: Wanpeng Li <wanpengli@tencent.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> | 15 May 2018, 09:56:21 UTC |
bb7298a | Sekhar Nori | 11 May 2018, 15:21:36 UTC | ARM: davinci: board-dm646x-evm: set VPIF capture card name VPIF capture driver expects card name to be set since it uses it without checking for NULL. The commit which introduced VPIF display and capture support added card name only for display, not for capture. Set it in platform data to probe driver successfully. While at it, also fix the display card name to something more appropriate. Fixes: 85609c1ccda6 ("DaVinci: DM646x - platform changes for vpif capture and display drivers") Signed-off-by: Sekhar Nori <nsekhar@ti.com> | 15 May 2018, 09:01:12 UTC |
7d46899 | Sekhar Nori | 11 May 2018, 15:21:35 UTC | ARM: davinci: board-dm646x-evm: pass correct I2C adapter id for VPIF commit a16cb91ad9c4 ("[media] media: vpif: use a configurable i2c_adapter_id for vpif display") removed hardcoded I2C adaptor setting in VPIF driver, but missed updating platform data passed from DM646x board. Fix it. Fixes: a16cb91ad9c4 ("[media] media: vpif: use a configurable i2c_adapter_id for vpif display") Signed-off-by: Sekhar Nori <nsekhar@ti.com> | 15 May 2018, 09:00:34 UTC |
73d4337 | Sekhar Nori | 11 May 2018, 15:21:34 UTC | ARM: davinci: dm646x: fix timer interrupt generation commit b38434145b34 ("ARM: davinci: irqs: Correct McASP1 TX interrupt definition for DM646x") inadvertently removed priority setting for timer0_12 (bottom half of timer0). This timer is used as clockevent. When INTPRIn register setting for an interrupt is left at 0, it is mapped to FIQ by the AINTC causing the timer interrupt to not get generated. Fix it by including an entry for timer0_12 in interrupt priority map array. While at it, move the clockevent comment to the right place. Fixes: b38434145b34 ("ARM: davinci: irqs: Correct McASP1 TX interrupt definition for DM646x") Signed-off-by: Sekhar Nori <nsekhar@ti.com> | 15 May 2018, 08:59:34 UTC |
2207655 | Shuah Khan (Samsung OSG) | 15 May 2018, 02:49:58 UTC | usbip: usbip_host: fix NULL-ptr deref and use-after-free errors usbip_host updates device status without holding lock from stub probe, disconnect and rebind code paths. When multiple requests to import a device are received, these unprotected code paths step all over each other and drive fails with NULL-ptr deref and use-after-free errors. The driver uses a table lock to protect the busid array for adding and deleting busids to the table. However, the probe, disconnect and rebind paths get the busid table entry and update the status without holding the busid table lock. Add a new finer grain lock to protect the busid entry. This new lock will be held to search and update the busid entry fields from get_busid_idx(), add_match_busid() and del_match_busid(). match_busid_show() does the same to access the busid entry fields. get_busid_priv() changed to return the pointer to the busid entry holding the busid lock. stub_probe(), stub_disconnect() and stub_device_rebind() call put_busid_priv() to release the busid lock before returning. This changes fixes the unprotected code paths eliminating the race conditions in updating the busid entries. Reported-by: Jakub Jirasek Signed-off-by: Shuah Khan (Samsung OSG) <shuah@kernel.org> Cc: stable <stable@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> | 15 May 2018, 07:52:02 UTC |
7510df3 | Shuah Khan (Samsung OSG) | 30 April 2018, 22:17:20 UTC | usbip: usbip_host: run rebind from exit when module is removed After removing usbip_host module, devices it releases are left without a driver. For example, when a keyboard or a mass storage device are bound to usbip_host when it is removed, these devices are no longer bound to any driver. Fix it to run device_attach() from the module exit routine to restore the devices to their original drivers. This includes cleanup changes and moving device_attach() code to a common routine to be called from rebind_store() and usbip_host_exit(). Signed-off-by: Shuah Khan (Samsung OSG) <shuah@kernel.org> Cc: stable <stable@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> | 15 May 2018, 07:47:52 UTC |
1e180f1 | Shuah Khan (Samsung OSG) | 30 April 2018, 22:17:19 UTC | usbip: usbip_host: delete device from busid_table after rebind Device is left in the busid_table after unbind and rebind. Rebind initiates usb bus scan and the original driver claims the device. After rescan the device should be deleted from the busid_table as it no longer belongs to usbip_host. Fix it to delete the device after device_attach() succeeds. Signed-off-by: Shuah Khan (Samsung OSG) <shuah@kernel.org> Cc: stable <stable@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> | 15 May 2018, 07:47:47 UTC |
28b68ac | Shuah Khan | 12 April 2018, 00:13:30 UTC | usbip: usbip_host: refine probe and disconnect debug msgs to be useful Refine probe and disconnect debug msgs to be useful and say what is in progress. Signed-off-by: Shuah Khan <shuahkh@osg.samsung.com> Cc: stable <stable@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> | 15 May 2018, 07:47:41 UTC |
35cd67a | Peter Rosin | 09 May 2018, 19:47:48 UTC | i2c: viperboard: return message count on master_xfer success Returning zero is wrong in this case. Signed-off-by: Peter Rosin <peda@axentia.se> Signed-off-by: Wolfram Sang <wsa@the-dreams.de> Fixes: 174a13aa8669 ("i2c: Add viperboard i2c master driver") | 15 May 2018, 07:31:26 UTC |
12d9bbc | Peter Rosin | 09 May 2018, 19:46:30 UTC | i2c: pmcmsp: fix error return from master_xfer Returning -1 (-EPERM) is not appropriate here, go with -EIO. Signed-off-by: Peter Rosin <peda@axentia.se> Signed-off-by: Wolfram Sang <wsa@the-dreams.de> Fixes: 1b144df1d7d6 ("i2c: New PMC MSP71xx TWI bus driver") | 15 May 2018, 07:31:19 UTC |
de9a863 | Peter Rosin | 09 May 2018, 19:46:29 UTC | i2c: pmcmsp: return message count on master_xfer success Returning zero is wrong in this case. Signed-off-by: Peter Rosin <peda@axentia.se> Signed-off-by: Wolfram Sang <wsa@the-dreams.de> Fixes: 1b144df1d7d6 ("i2c: New PMC MSP71xx TWI bus driver") | 15 May 2018, 07:30:34 UTC |
f3903c9 | Ingo Molnar | 15 May 2018, 06:20:45 UTC | Merge tag 'perf-urgent-for-mingo-4.17-20180514' of git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/urgent Pull perf/urgent fixes from Arnaldo Carvalho de Melo: - Fix segfault when processing unknown threads in cs-etm (Leo Yan) - Fix "perf test inet_pton" on s390 failing due to missing inline (Thomas Richter) - Display all available events on 'perf annotate --stdio' (Jin Yao) - Add missing newline when parsing empty BPF proggie (Arnaldo Carvalho de Melo) Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com> Signed-off-by: Ingo Molnar <mingo@kernel.org> | 15 May 2018, 06:20:45 UTC |
2e68adc | Julian Wiedmann | 02 May 2018, 06:28:34 UTC | s390/qdio: don't release memory in qdio_setup_irq() Calling qdio_release_memory() on error is just plain wrong. It frees the main qdio_irq struct, when following code still uses it. Also, no other error path in qdio_establish() does this. So trust callers to clean up via qdio_free() if some step of the QDIO initialization fails. Fixes: 779e6e1c724d ("[S390] qdio: new qdio driver.") Cc: <stable@vger.kernel.org> #v2.6.27+ Signed-off-by: Julian Wiedmann <jwi@linux.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com> | 15 May 2018, 05:40:38 UTC |
e521813 | Julian Wiedmann | 02 May 2018, 06:48:43 UTC | s390/qdio: fix access to uninitialized qdio_q fields Ever since CQ/QAOB support was added, calling qdio_free() straight after qdio_alloc() results in qdio_release_memory() accessing uninitialized memory (ie. q->u.out.use_cq and q->u.out.aobs). Followed by a kmem_cache_free() on the random AOB addresses. For older kernels that don't have 6e30c549f6ca, the same applies if qdio_establish() fails in the DEV_STATE_ONLINE check. While initializing q->u.out.use_cq would be enough to fix this particular bug, the more future-proof change is to just zero-alloc the whole struct. Fixes: 104ea556ee7f ("qdio: support asynchronous delivery of storage blocks") Cc: <stable@vger.kernel.org> #v3.2+ Signed-off-by: Julian Wiedmann <jwi@linux.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com> | 15 May 2018, 05:40:36 UTC |
6f5ec29 | Josh Poimboeuf | 14 May 2018, 13:53:24 UTC | objtool: Detect RIP-relative switch table references Typically a switch table can be found by detecting a .rodata access followed an indirect jump: 1969: 4a 8b 0c e5 00 00 00 mov 0x0(,%r12,8),%rcx 1970: 00 196d: R_X86_64_32S .rodata+0x438 1971: e9 00 00 00 00 jmpq 1976 <dispc_runtime_suspend+0xb6a> 1972: R_X86_64_PC32 __x86_indirect_thunk_rcx-0x4 Randy Dunlap reported a case (seen with GCC 4.8) where the .rodata access uses RIP-relative addressing: 19bd: 48 8b 3d 00 00 00 00 mov 0x0(%rip),%rdi # 19c4 <dispc_runtime_suspend+0xbb8> 19c0: R_X86_64_PC32 .rodata+0x45c 19c4: e9 00 00 00 00 jmpq 19c9 <dispc_runtime_suspend+0xbbd> 19c5: R_X86_64_PC32 __x86_indirect_thunk_rdi-0x4 In this case the relocation addend needs to be adjusted accordingly in order to find the location of the switch table. The fix is for case 3 (as described in the comments), but also make the existing case 1 & 2 checks more precise by only adjusting the addend for R_X86_64_PC32 relocations. This fixes the following warnings: drivers/video/fbdev/omap2/omapfb/dss/dispc.o: warning: objtool: dispc_runtime_suspend()+0xbb8: sibling call from callable instruction with modified stack frame drivers/video/fbdev/omap2/omapfb/dss/dispc.o: warning: objtool: dispc_runtime_resume()+0xcc5: sibling call from callable instruction with modified stack frame Reported-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/b6098294fd67afb69af8c47c9883d7a68bf0f8ea.1526305958.git.jpoimboe@redhat.com Signed-off-by: Ingo Molnar <mingo@kernel.org> | 15 May 2018, 05:30:59 UTC |
c99f080 | Jorge Sanjuan | 11 May 2018, 15:25:35 UTC | ALSA: usb-audio: Use Class Specific EP for UAC3 devices. bmAtributes offset doesn't exist in the UAC3 CS_EP descriptor. Hence, checking for pitch control as if it was UAC2 doesn't make any sense. Use the defined UAC3 offsets instead. Fixes: 9a2fe9b801f5 ("ALSA: usb: initial USB Audio Device Class 3.0 support") Signed-off-by: Jorge Sanjuan <jorge.sanjuan@codethink.co.uk> Reviewed-by: Ruslan Bilovol <ruslan.bilovol@gmail.com> Signed-off-by: Takashi Iwai <tiwai@suse.de> | 15 May 2018, 05:29:10 UTC |
76ef6b2 | Dave Airlie | 15 May 2018, 03:38:15 UTC | drm: set FMODE_UNSIGNED_OFFSET for drm files Since we have the ttm and gem vma managers using a subset of the file address space for objects, and these start at 0x100000000 they will overflow the new mmap checks. I've checked all the mmap routines I could see for any bad behaviour but overall most people use GEM/TTM VMA managers even the legacy drivers have a hashtable. Reported-and-Tested-by: Arthur Marsh (amarsh04 on #radeon) Fixes: be83bbf8068 (mmap: introduce sane default mmap limits) Signed-off-by: Dave Airlie <airlied@redhat.com> | 15 May 2018, 04:46:04 UTC |
45dd9b0 | Steven Rostedt (VMware) | 09 May 2018, 18:36:09 UTC | tracing/x86/xen: Remove zero data size trace events trace_xen_mmu_flush_tlb{_all} Doing an audit of trace events, I discovered two trace events in the xen subsystem that use a hack to create zero data size trace events. This is not what trace events are for. Trace events add memory footprint overhead, and if all you need to do is see if a function is hit or not, simply make that function noinline and use function tracer filtering. Worse yet, the hack used was: __array(char, x, 0) Which creates a static string of zero in length. There's assumptions about such constructs in ftrace that this is a dynamic string that is nul terminated. This is not the case with these tracepoints and can cause problems in various parts of ftrace. Nuke the trace events! Link: http://lkml.kernel.org/r/20180509144605.5a220327@gandalf.local.home Cc: stable@vger.kernel.org Fixes: 95a7d76897c1e ("xen/mmu: Use Xen specific TLB flush instead of the generic one.") Reviewed-by: Juergen Gross <jgross@suse.com> Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org> | 14 May 2018, 21:02:30 UTC |
0cf442c | Miquel Raynal | 24 April 2018, 15:45:06 UTC | cpufreq: armada-37xx: driver relies on cpufreq-dt Armada-37xx driver registers a cpufreq-dt driver. Not having CONFIG_CPUFREQ_DT selected leads to a silent abort during the probe. Prevent that situation by having the former depending on the latter. Fixes: 92ce45fb875d7 (cpufreq: Add DVFS support for Armada 37xx) Cc: 4.16+ <stable@vger.kernel.org> # 4.16+ Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> | 14 May 2018, 20:25:56 UTC |
7b34c0f | Bob Moore | 08 May 2018, 21:06:15 UTC | ACPICA: Add deferred package support for the Load and loadTable operators Completes the support and fixes a regression introduced in version 20180209. The regression caused package objects that were loaded by the Load and loadTable operators. This created an error message like the following: [ 0.251922] ACPI Error: No pointer back to namespace node in package 00000000fd2a44cd (20180313/dsargs-303) Link: https://bugzilla.kernel.org/show_bug.cgi?id=199413 Fixes: 5a8361f7ecce (ACPICA: Integrate package handling with module-level code) Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Erik Schmauss <erik.schmauss@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> | 14 May 2018, 20:25:45 UTC |
4152dc9 | Alexey Kodanev | 11 May 2018, 17:15:13 UTC | selinux: correctly handle sa_family cases in selinux_sctp_bind_connect() Allow to pass the socket address structure with AF_UNSPEC family for compatibility purposes. selinux_socket_bind() will further check it for INADDR_ANY and selinux_socket_connect_helper() should return EINVAL. For a bad address family return EINVAL instead of AFNOSUPPORT error, i.e. what is expected from SCTP protocol in such case. Fixes: d452930fd3b9 ("selinux: Add SCTP support") Suggested-by: Paul Moore <paul@paul-moore.com> Signed-off-by: Alexey Kodanev <alexey.kodanev@oracle.com> Signed-off-by: Paul Moore <paul@paul-moore.com> | 14 May 2018, 19:20:59 UTC |
88b7d37 | Alexey Kodanev | 11 May 2018, 17:15:12 UTC | selinux: fix address family in bind() and connect() to match address/port Since sctp_bindx() and sctp_connectx() can have multiple addresses, sk_family can differ from sa_family. Therefore, selinux_socket_bind() and selinux_socket_connect_helper(), which process sockaddr structure (address and port), should use the address family from that structure too, and not from the socket one. The initialization of the data for the audit record is moved above, in selinux_socket_bind(), so that there is no duplicate changes and code. Fixes: d452930fd3b9 ("selinux: Add SCTP support") Suggested-by: Paul Moore <paul@paul-moore.com> Signed-off-by: Alexey Kodanev <alexey.kodanev@oracle.com> Signed-off-by: Paul Moore <paul@paul-moore.com> | 14 May 2018, 19:19:25 UTC |
0f8db8c | Alexey Kodanev | 11 May 2018, 17:15:11 UTC | selinux: add AF_UNSPEC and INADDR_ANY checks to selinux_socket_bind() Commit d452930fd3b9 ("selinux: Add SCTP support") breaks compatibility with the old programs that can pass sockaddr_in structure with AF_UNSPEC and INADDR_ANY to bind(). As a result, bind() returns EAFNOSUPPORT error. This was found with LTP/asapi_01 test. Similar to commit 29c486df6a20 ("net: ipv4: relax AF_INET check in bind()"), which relaxed AF_INET check for compatibility, add AF_UNSPEC case to AF_INET and make sure that the address is INADDR_ANY. Fixes: d452930fd3b9 ("selinux: Add SCTP support") Signed-off-by: Alexey Kodanev <alexey.kodanev@oracle.com> Signed-off-by: Paul Moore <paul@paul-moore.com> | 14 May 2018, 19:17:02 UTC |
ae93870 | Olof Johansson | 14 May 2018, 16:27:33 UTC | Merge tag 'reset-fixes-for-4.17' of git://git.pengutronix.de/pza/linux into fixes Reset controller fixes for v4.17 Fix the USB3 reset (offset 0x200c, bit 5) on Uniphier LD20. It was incorrectly labeled as GIO reset. This reset line is not yet used in uniphier-ld20.dtsi. * tag 'reset-fixes-for-4.17' of git://git.pengutronix.de/pza/linux: reset: uniphier: fix USB clock line for LD20 Signed-off-by: Olof Johansson <olof@lixom.net> | 14 May 2018, 16:27:33 UTC |
99ffa8b | Olof Johansson | 14 May 2018, 16:25:14 UTC | Merge tag 'mvebu-fixes-4.17-1' of git://git.infradead.org/linux-mvebu into fixes mvebu fixes for 4.17 (part 1) Declare missing clocks needed for network on Armada 8040 base boards (such as the McBin) * tag 'mvebu-fixes-4.17-1' of git://git.infradead.org/linux-mvebu: ARM64: dts: marvell: armada-cp110: Add mg_core_clk for ethernet node ARM64: dts: marvell: armada-cp110: Add clocks for the xmdio node Signed-off-by: Olof Johansson <olof@lixom.net> | 14 May 2018, 16:25:14 UTC |
9954b80 | Russell King | 10 May 2018, 13:24:20 UTC | ARM: keystone: fix platform_domain_notifier array overrun platform_domain_notifier contains a variable sized array, which the pm_clk_notify() notifier treats as a NULL terminated array: for (con_id = clknb->con_ids; *con_id; con_id++) pm_clk_add(dev, *con_id); Omitting the initialiser for con_ids means that the array is zero sized, and there is no NULL terminator. This leads to pm_clk_notify() overrunning into what ever structure follows, which may not be NULL. This leads to an oops: Unable to handle kernel NULL pointer dereference at virtual address 0000008c pgd = c0003000 [0000008c] *pgd=80000800004003c, *pmd=00000000c Internal error: Oops: 206 [#1] PREEMPT SMP ARM Modules linked in:c CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.16.0+ #9 Hardware name: Keystone PC is at strlen+0x0/0x34 LR is at kstrdup+0x18/0x54 pc : [<c0623340>] lr : [<c0111d6c>] psr: 20000013 sp : eec73dc0 ip : eed780c0 fp : 00000001 r10: 00000000 r9 : 00000000 r8 : eed71e10 r7 : 0000008c r6 : 0000008c r5 : 014000c0 r4 : c03a6ff4 r3 : c09445d0 r2 : 00000000 r1 : 014000c0 r0 : 0000008c Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user Control: 30c5387d Table: 00003000 DAC: fffffffd Process swapper/0 (pid: 1, stack limit = 0xeec72210) Stack: (0xeec73dc0 to 0xeec74000) ... [<c0623340>] (strlen) from [<c0111d6c>] (kstrdup+0x18/0x54) [<c0111d6c>] (kstrdup) from [<c03a6ff4>] (__pm_clk_add+0x58/0x120) [<c03a6ff4>] (__pm_clk_add) from [<c03a731c>] (pm_clk_notify+0x64/0xa8) [<c03a731c>] (pm_clk_notify) from [<c004614c>] (notifier_call_chain+0x44/0x84) [<c004614c>] (notifier_call_chain) from [<c0046320>] (__blocking_notifier_call_chain+0x48/0x60) [<c0046320>] (__blocking_notifier_call_chain) from [<c0046350>] (blocking_notifier_call_chain+0x18/0x20) [<c0046350>] (blocking_notifier_call_chain) from [<c0390234>] (device_add+0x36c/0x534) [<c0390234>] (device_add) from [<c047fc00>] (of_platform_device_create_pdata+0x70/0xa4) [<c047fc00>] (of_platform_device_create_pdata) from [<c047fea0>] (of_platform_bus_create+0xf0/0x1ec) [<c047fea0>] (of_platform_bus_create) from [<c047fff8>] (of_platform_populate+0x5c/0xac) [<c047fff8>] (of_platform_populate) from [<c08b1f04>] (of_platform_default_populate_init+0x8c/0xa8) [<c08b1f04>] (of_platform_default_populate_init) from [<c000a78c>] (do_one_initcall+0x3c/0x164) [<c000a78c>] (do_one_initcall) from [<c087bd9c>] (kernel_init_freeable+0x10c/0x1d0) [<c087bd9c>] (kernel_init_freeable) from [<c0628db0>] (kernel_init+0x8/0xf0) [<c0628db0>] (kernel_init) from [<c00090d8>] (ret_from_fork+0x14/0x3c) Exception stack(0xeec73fb0 to 0xeec73ff8) 3fa0: 00000000 00000000 00000000 00000000 3fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 3fe0: 00000000 00000000 00000000 00000000 00000013 00000000 Code: e3520000 1afffff7 e12fff1e c0801730 (e5d02000) ---[ end trace cafa8f148e262e80 ]--- Fix this by adding the necessary initialiser. Fixes: fc20ffe1213b ("ARM: keystone: add PM domain support for clock management") Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Acked-by: Santosh Shilimkar <ssantosh@kernel.org> Signed-off-by: Olof Johansson <olof@lixom.net> | 14 May 2018, 16:24:29 UTC |
ebc3dd6 | Daniel Glöckner | 14 May 2018, 14:40:05 UTC | usb: musb: fix remote wakeup racing with suspend It has been observed that writing 0xF2 to the power register while it reads as 0xF4 results in the register having the value 0xF0, i.e. clearing RESUME and setting SUSPENDM in one go does not work. It might also violate the USB spec to transition directly from resume to suspend, especially when not taking T_DRSMDN into account. But this is what happens when a remote wakeup occurs between SetPortFeature USB_PORT_FEAT_SUSPEND on the root hub and musb_bus_suspend being called. This commit returns -EBUSY when musb_bus_suspend is called while remote wakeup is signalled and thus avoids to reset the RESUME bit. Ignoring this error when musb_port_suspend is called from musb_hub_control is ok. Signed-off-by: Daniel Glöckner <dg@emlix.com> Signed-off-by: Bin Liu <b-liu@ti.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> | 14 May 2018, 15:04:06 UTC |
9a8fca6 | Filipe Manana | 11 May 2018, 15:42:42 UTC | Btrfs: fix xattr loss after power failure If a file has xattrs, we fsync it, to ensure we clear the flags BTRFS_INODE_NEEDS_FULL_SYNC and BTRFS_INODE_COPY_EVERYTHING from its inode, the current transaction commits and then we fsync it (without either of those bits being set in its inode), we end up not logging all its xattrs. This results in deleting all xattrs when replying the log after a power failure. Trivial reproducer $ mkfs.btrfs -f /dev/sdb $ mount /dev/sdb /mnt $ touch /mnt/foobar $ setfattr -n user.xa -v qwerty /mnt/foobar $ xfs_io -c "fsync" /mnt/foobar $ sync $ xfs_io -c "pwrite -S 0xab 0 64K" /mnt/foobar $ xfs_io -c "fsync" /mnt/foobar <power failure> $ mount /dev/sdb /mnt $ getfattr --absolute-names --dump /mnt/foobar <empty output> $ So fix this by making sure all xattrs are logged if we log a file's inode item and neither the flags BTRFS_INODE_NEEDS_FULL_SYNC nor BTRFS_INODE_COPY_EVERYTHING were set in the inode. Fixes: 36283bf777d9 ("Btrfs: fix fsync xattr loss in the fast fsync path") Cc: <stable@vger.kernel.org> # 4.2+ Signed-off-by: Filipe Manana <fdmanana@suse.com> Signed-off-by: David Sterba <dsterba@suse.com> | 14 May 2018, 14:42:43 UTC |
6f2f0b3 | Robbie Ko | 14 May 2018, 02:51:34 UTC | Btrfs: send, fix invalid access to commit roots due to concurrent snapshotting [BUG] btrfs incremental send BUG happens when creating a snapshot of snapshot that is being used by send. [REASON] The problem can happen if while we are doing a send one of the snapshots used (parent or send) is snapshotted, because snapshoting implies COWing the root of the source subvolume/snapshot. 1. When doing an incremental send, the send process will get the commit roots from the parent and send snapshots, and add references to them through extent_buffer_get(). 2. When a snapshot/subvolume is snapshotted, its root node is COWed (transaction.c:create_pending_snapshot()). 3. COWing releases the space used by the node immediately, through: __btrfs_cow_block() --btrfs_free_tree_block() ----btrfs_add_free_space(bytenr of node) 4. Because send doesn't hold a transaction open, it's possible that the transaction used to create the snapshot commits, switches the commit root and the old space used by the previous root node gets assigned to some other node allocation. Allocation of a new node will use the existing extent buffer found in memory, which we previously got a reference through extent_buffer_get(), and allow the extent buffer's content (pages) to be modified: btrfs_alloc_tree_block --btrfs_reserve_extent ----find_free_extent (get bytenr of old node) --btrfs_init_new_buffer (use bytenr of old node) ----btrfs_find_create_tree_block ------alloc_extent_buffer --------find_extent_buffer (get old node) 5. So send can access invalid memory content and have unpredictable behaviour. [FIX] So we fix the problem by copying the commit roots of the send and parent snapshots and use those copies. CallTrace looks like this: ------------[ cut here ]------------ kernel BUG at fs/btrfs/ctree.c:1861! invalid opcode: 0000 [#1] SMP CPU: 6 PID: 24235 Comm: btrfs Tainted: P O 3.10.105 #23721 ffff88046652d680 ti: ffff88041b720000 task.ti: ffff88041b720000 RIP: 0010:[<ffffffffa08dd0e8>] read_node_slot+0x108/0x110 [btrfs] RSP: 0018:ffff88041b723b68 EFLAGS: 00010246 RAX: ffff88043ca6b000 RBX: ffff88041b723c50 RCX: ffff880000000000 RDX: 000000000000004c RSI: ffff880314b133f8 RDI: ffff880458b24000 RBP: 0000000000000000 R08: 0000000000000001 R09: ffff88041b723c66 R10: 0000000000000001 R11: 0000000000001000 R12: ffff8803f3e48890 R13: ffff8803f3e48880 R14: ffff880466351800 R15: 0000000000000001 FS: 00007f8c321dc8c0(0000) GS:ffff88047fcc0000(0000) CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 R2: 00007efd1006d000 CR3: 0000000213a24000 CR4: 00000000003407e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Stack: ffff88041b723c50 ffff8803f3e48880 ffff8803f3e48890 ffff8803f3e48880 ffff880466351800 0000000000000001 ffffffffa08dd9d7 ffff88041b723c50 ffff8803f3e48880 ffff88041b723c66 ffffffffa08dde85 a9ff88042d2c4400 Call Trace: [<ffffffffa08dd9d7>] ? tree_move_down.isra.33+0x27/0x50 [btrfs] [<ffffffffa08dde85>] ? tree_advance+0xb5/0xc0 [btrfs] [<ffffffffa08e83d4>] ? btrfs_compare_trees+0x2d4/0x760 [btrfs] [<ffffffffa0982050>] ? finish_inode_if_needed+0x870/0x870 [btrfs] [<ffffffffa09841ea>] ? btrfs_ioctl_send+0xeda/0x1050 [btrfs] [<ffffffffa094bd3d>] ? btrfs_ioctl+0x1e3d/0x33f0 [btrfs] [<ffffffff81111133>] ? handle_pte_fault+0x373/0x990 [<ffffffff8153a096>] ? atomic_notifier_call_chain+0x16/0x20 [<ffffffff81063256>] ? set_task_cpu+0xb6/0x1d0 [<ffffffff811122c3>] ? handle_mm_fault+0x143/0x2a0 [<ffffffff81539cc0>] ? __do_page_fault+0x1d0/0x500 [<ffffffff81062f07>] ? check_preempt_curr+0x57/0x90 [<ffffffff8115075a>] ? do_vfs_ioctl+0x4aa/0x990 [<ffffffff81034f83>] ? do_fork+0x113/0x3b0 [<ffffffff812dd7d7>] ? trace_hardirqs_off_thunk+0x3a/0x6c [<ffffffff81150cc8>] ? SyS_ioctl+0x88/0xa0 [<ffffffff8153e422>] ? system_call_fastpath+0x16/0x1b ---[ end trace 29576629ee80b2e1 ]--- Fixes: 7069830a9e38 ("Btrfs: add btrfs_compare_trees function") CC: stable@vger.kernel.org # 3.6+ Signed-off-by: Robbie Ko <robbieko@synology.com> Reviewed-by: Filipe Manana <fdmanana@suse.com> Signed-off-by: David Sterba <dsterba@suse.com> | 14 May 2018, 14:42:34 UTC |
4776cab | David Howells | 10 May 2018, 22:10:40 UTC | afs: Fix the non-encryption of calls Some AFS servers refuse to accept unencrypted traffic, so can't be accessed with kAFS. Set the AF_RXRPC security level to encrypt client calls to deal with this. Note that incoming service calls are set by the remote client and so aren't affected by this. This requires an AF_RXRPC patch to pass the value set by setsockopt to calls begun by the kernel. Signed-off-by: David Howells <dhowells@redhat.com> | 14 May 2018, 14:15:19 UTC |
428edad | David Howells | 11 May 2018, 23:28:58 UTC | afs: Fix CB.CallBack handling The handling of CB.CallBack messages sent by the fileserver to the client is broken in that they are currently being processed after the reply has been transmitted. This is not what the fileserver expects, however. It holds up change visibility until the reply comes so as to maintain cache coherency, and so expects the client to have to refetch the state on the affected files. Fix CB.CallBack handling to perform the callback break before sending the reply. The fileserver is free to hold up status fetches issued by other threads on the same client that occur in reponse to the callback until any pending changes have been committed. Fixes: d001648ec7cf ("rxrpc: Don't expose skbs to in-kernel users [ver #2]") Signed-off-by: David Howells <dhowells@redhat.com> | 14 May 2018, 14:15:19 UTC |
68251f0 | David Howells | 12 May 2018, 21:31:33 UTC | afs: Fix whole-volume callback handling It's possible for an AFS file server to issue a whole-volume notification that callbacks on all the vnodes in the file have been broken. This is done for R/O and backup volumes (which don't have per-file callbacks) and for things like a volume being taken offline. Fix callback handling to detect whole-volume notifications, to track it across operations and to check it during inode validation. Fixes: c435ee34551e ("afs: Overhaul the callback handling") Signed-off-by: David Howells <dhowells@redhat.com> | 14 May 2018, 14:15:18 UTC |
f9c1bba | Marc Dionne | 12 May 2018, 00:35:06 UTC | afs: Fix afs_find_server search loop The code that looks up servers by addresses makes the assumption that the list of addresses for a server is sorted. It exits the loop if it finds that the target address is larger than the current candidate. As the list is not currently sorted, this can lead to a failure to find a matching server, which can cause callbacks from that server to be ignored. Remove the early exit case so that the complete list is searched. Fixes: d2ddc776a458 ("afs: Overhaul volume and server record caching and fileserver rotation") Signed-off-by: Marc Dionne <marc.dionne@auristor.com> Signed-off-by: David Howells <dhowells@redhat.com> | 14 May 2018, 14:15:18 UTC |
a86b06d | David Howells | 11 May 2018, 22:45:40 UTC | afs: Fix the handling of an unfound server in CM operations If the client cache manager operations that need the server record (CB.Callback, CB.InitCallBackState, and CB.InitCallBackState3) can't find the server record, they abort the call from the file server with RX_CALL_DEAD when they should return okay. Fixes: c35eccb1f614 ("[AFS]: Implement the CB.InitCallBackState3 operation.") Signed-off-by: David Howells <dhowells@redhat.com> | 14 May 2018, 14:15:18 UTC |
3709a39 | David Howells | 11 May 2018, 21:59:42 UTC | afs: Add a tracepoint to record callbacks from unlisted servers Add a tracepoint to record callbacks from servers for which we don't have a record. Signed-off-by: David Howells <dhowells@redhat.com> | 14 May 2018, 14:15:18 UTC |
001ab5a | David Howells | 11 May 2018, 22:21:35 UTC | afs: Fix the handling of CB.InitCallBackState3 to find the server by UUID Fix the handling of the CB.InitCallBackState3 service call to find the record of a server that we're using by looking it up by the UUID passed as the parameter rather than by its address (of which it might have many, and which may change). Fixes: c35eccb1f614 ("[AFS]: Implement the CB.InitCallBackState3 operation.") Signed-off-by: David Howells <dhowells@redhat.com> | 14 May 2018, 14:15:18 UTC |
3d9fa91 | David Howells | 11 May 2018, 21:55:59 UTC | afs: Fix VNOVOL handling in address rotation If a volume location record lists multiple file servers for a volume, then it's possible that due to a misconfiguration or a changing configuration that one of the file servers doesn't know about it yet and will abort VNOVOL. Currently, the rotation algorithm will stop with EREMOTEIO. Fix this by moving on to try the next server if VNOVOL is returned. Once all the servers have been tried and the record rechecked, the algorithm will stop with EREMOTEIO or ENOMEDIUM. Fixes: d2ddc776a458 ("afs: Overhaul volume and server record caching and fileserver rotation") Reported-by: Marc Dionne <marc.dionne@auristor.com> Signed-off-by: David Howells <dhowells@redhat.com> | 14 May 2018, 14:15:18 UTC |
684b0f6 | David Howells | 10 May 2018, 20:51:47 UTC | afs: Fix AFSFetchStatus decoder to provide OpenAFS compatibility The OpenAFS server's RXAFS_InlineBulkStatus implementation has a bug whereby if an error occurs on one of the vnodes being queried, then the errorCode field is set correctly in the corresponding status, but the interfaceVersion field is left unset. Fix kAFS to deal with this by evaluating the AFSFetchStatus blob against the following cases when called from FS.InlineBulkStatus delivery: (1) If InterfaceVersion == 0 then: (a) If errorCode != 0 then it indicates the abort code for the corresponding vnode. (b) If errorCode == 0 then the status record is invalid. (2) If InterfaceVersion == 1 then: (a) If errorCode != 0 then it indicates the abort code for the corresponding vnode. (b) If errorCode == 0 then the status record is valid and can be parsed. (3) If InterfaceVersion is anything else then the status record is invalid. Fixes: dd9fbcb8e103 ("afs: Rearrange status mapping") Reported-by: Jeffrey Altman <jaltman@auristor.com> Signed-off-by: David Howells <dhowells@redhat.com> | 14 May 2018, 14:15:18 UTC |
90d6176 | Boris Brezillon | 09 May 2018, 07:13:58 UTC | mtd: rawnand: marvell: Fix read logic for layouts with ->nchunks > 2 The code is doing monolithic reads for all chunks except the last one which is wrong since a monolithic read will issue the READ0+ADDRS+READ_START sequence. It not only takes longer because it forces the NAND chip to reload the page content into its internal cache, but by doing that we also reset the column pointer to 0, which means we'll always read the first chunk instead of moving to the next one. Rework the code to do a monolithic read only for the first chunk, then switch to naked reads for all intermediate chunks and finally issue a last naked read for the last chunk. Fixes: 02f26ecf8c77 mtd: nand: add reworked Marvell NAND controller driver Cc: stable@vger.kernel.org Reported-by: Chris Packham <chris.packham@alliedtelesis.co.nz> Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com> Tested-by: Chris Packham <chris.packham@alliedtelesis.co.nz> Acked-by: Miquel Raynal <miquel.raynal@bootlin.com> | 14 May 2018, 12:46:20 UTC |
ea739a2 | Ben Hutchings | 10 May 2018, 18:20:54 UTC | mtd: Fix comparison in map_word_andequal() Commit 9e343e87d2c4 ("mtd: cfi: convert inline functions to macros") changed map_word_andequal() into a macro, but also changed the right hand side of the comparison from val3 to val2. Change it back to use val3 on the right hand side. Thankfully this did not cause a regression because all callers currently pass the same argument for val2 and val3. Fixes: 9e343e87d2c4 ("mtd: cfi: convert inline functions to macros") Signed-off-by: Ben Hutchings <ben@decadent.org.uk> Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com> | 14 May 2018, 12:46:20 UTC |
ec5a3b4 | David Howells | 10 May 2018, 13:22:38 UTC | afs: Fix server rotation's handling of fileserver probe failure The server rotation algorithm just gives up if it fails to probe a fileserver. Fix this by rotating to the next fileserver instead. Fixes: d2ddc776a458 ("afs: Overhaul volume and server record caching and fileserver rotation") Signed-off-by: David Howells <dhowells@redhat.com> | 14 May 2018, 12:26:44 UTC |
d4a96be | David Howells | 10 May 2018, 07:43:04 UTC | afs: Fix refcounting in callback registration The refcounting on afs_cb_interest struct objects in afs_register_server_cb_interest() is wrong as it uses the server list entry's call back interest pointer without regard for the fact that it might be replaced at any time and the object thrown away. Fix this by: (1) Put a lock on the afs_server_list struct that can be used to mediate access to the callback interest pointers in the servers array. (2) Keep a ref on the callback interest that we get from the entry. (3) Dropping the old reference held by vnode->cb_interest if we replace the pointer. Fixes: c435ee34551e ("afs: Overhaul the callback handling") Signed-off-by: David Howells <dhowells@redhat.com> | 14 May 2018, 12:17:35 UTC |
f2686b0 | David Howells | 10 May 2018, 13:12:50 UTC | afs: Fix giving up callbacks on server destruction When a server record is destroyed, we want to send a message to the server telling it that we're giving up all the callbacks it has promised us. Apply two fixes to this: (1) Only send the FS.GiveUpAllCallBacks message if we actually got a callback from that server. We assume this to be the case if we performed at least one successful FS operation on that server. (2) Send it to the address last used for that server rather than always picking the first address in the list (which might be unreachable). Fixes: d2ddc776a458 ("afs: Overhaul volume and server record caching and fileserver rotation") Signed-off-by: David Howells <dhowells@redhat.com> | 14 May 2018, 12:17:35 UTC |
01fd79e | David Howells | 09 May 2018, 21:03:18 UTC | afs: Fix address list parsing The parsing of port specifiers in the address list obtained from the DNS resolution upcall doesn't work as in4_pton() and in6_pton() will fail on encountering an unexpected delimiter (in this case, the '+' marking the port number). However, in*_pton() can't be given multiple specifiers. Fix this by finding the delimiter in advance and not relying on in*_pton() to find the end of the address for us. Fixes: 8b2a464ced77 ("afs: Add an address list concept") Signed-off-by: David Howells <dhowells@redhat.com> | 14 May 2018, 12:17:35 UTC |
b61f7dc | David Howells | 27 April 2018, 19:46:22 UTC | afs: Fix directory page locking The afs directory loading code (primarily afs_read_dir()) locks all the pages that hold a directory's content blob to defend against getdents/getdents races and getdents/lookup races where the competitors issue conflicting reads on the same data. As the reads will complete consecutively, they may retrieve different versions of the data and one may overwrite the data that the other is busy parsing. Fix this by not locking the pages at all, but rather by turning the validation lock into an rwsem and getting an exclusive lock on it whilst reading the data or validating the attributes and a shared lock whilst parsing the data. Sharing the attribute validation lock should be fine as the data fetch will retrieve the attributes also. The individual page locks aren't needed at all as the only place they're being used is to serialise data loading. Without this patch, the: if (!test_bit(AFS_VNODE_DIR_VALID, &dvnode->flags)) { ... } part of afs_read_dir() may be skipped, leaving the pages unlocked when we hit the success: clause - in which case we try to unlock the not-locked pages, leading to the following oops: page:ffffe38b405b4300 count:3 mapcount:0 mapping:ffff98156c83a978 index:0x0 flags: 0xfffe000001004(referenced|private) raw: 000fffe000001004 ffff98156c83a978 0000000000000000 00000003ffffffff raw: dead000000000100 dead000000000200 0000000000000001 ffff98156b27c000 page dumped because: VM_BUG_ON_PAGE(!PageLocked(page)) page->mem_cgroup:ffff98156b27c000 ------------[ cut here ]------------ kernel BUG at mm/filemap.c:1205! ... RIP: 0010:unlock_page+0x43/0x50 ... Call Trace: afs_dir_iterate+0x789/0x8f0 [kafs] ? _cond_resched+0x15/0x30 ? kmem_cache_alloc_trace+0x166/0x1d0 ? afs_do_lookup+0x69/0x490 [kafs] ? afs_do_lookup+0x101/0x490 [kafs] ? key_default_cmp+0x20/0x20 ? request_key+0x3c/0x80 ? afs_lookup+0xf1/0x340 [kafs] ? __lookup_slow+0x97/0x150 ? lookup_slow+0x35/0x50 ? walk_component+0x1bf/0x490 ? path_lookupat.isra.52+0x75/0x200 ? filename_lookup.part.66+0xa0/0x170 ? afs_end_vnode_operation+0x41/0x60 [kafs] ? __check_object_size+0x9c/0x171 ? strncpy_from_user+0x4a/0x170 ? vfs_statx+0x73/0xe0 ? __do_sys_newlstat+0x39/0x70 ? __x64_sys_getdents+0xc9/0x140 ? __x64_sys_getdents+0x140/0x140 ? do_syscall_64+0x5b/0x160 ? entry_SYSCALL_64_after_hwframe+0x44/0xa9 Fixes: f3ddee8dc4e2 ("afs: Fix directory handling") Reported-by: Marc Dionne <marc.dionne@auristor.com> Signed-off-by: David Howells <dhowells@redhat.com> | 14 May 2018, 12:17:35 UTC |
cd078bf | Chris Wilson | 11 May 2018, 12:11:45 UTC | drm/i915/execlists: Use rmb() to order CSB reads We assume that the CSB is written using the normal ringbuffer coherency protocols, as outlined in kernel/events/ring_buffer.c: * (HW) (DRIVER) * * if (LOAD ->data_tail) { LOAD ->data_head * (A) smp_rmb() (C) * STORE $data LOAD $data * smp_wmb() (B) smp_mb() (D) * STORE ->data_head STORE ->data_tail * } So we assume that the HW fulfils its ordering requirements (B), and so we should use a complimentary rmb (C) to ensure that our read of its WRITE pointer is completed before we start accessing the data. The final mb (D) is implied by the uncached mmio we perform to inform the HW of our READ pointer. References: https://bugs.freedesktop.org/show_bug.cgi?id=105064 References: https://bugs.freedesktop.org/show_bug.cgi?id=105888 References: https://bugs.freedesktop.org/show_bug.cgi?id=106185 Fixes: 767a983ab255 ("drm/i915/execlists: Read the context-status HEAD from the HWSP") References: 61bf9719fa17 ("drm/i915/cnl: Use mmio access to context status buffer") Suggested-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Michał Winiarski <michal.winiarski@intel.com> Cc: Rafael Antognolli <rafael.antognolli@intel.com> Cc: Michel Thierry <michel.thierry@intel.com> Cc: Timo Aaltonen <tjaalton@ubuntu.com> Tested-by: Timo Aaltonen <tjaalton@ubuntu.com> Acked-by: Michel Thierry <michel.thierry@intel.com> Acked-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180511121147.31915-1-chris@chris-wilson.co.uk (cherry picked from commit 77dfedb5be03779f9a5d83e323a1b36e32090105) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> | 14 May 2018, 12:09:04 UTC |
20943f9 | Matthew Auld | 02 May 2018, 19:50:21 UTC | drm/i915/userptr: reject zero user_size Operating on a zero sized GEM userptr object will lead to explosions. Fixes: 5cc9ed4b9a7a ("drm/i915: Introduce mapping of user pages into video memory (userptr) ioctl") Testcase: igt/gem_userptr_blits/input-checking Signed-off-by: Matthew Auld <matthew.auld@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20180502195021.30900-1-matthew.auld@intel.com (cherry picked from commit c11c7bfd213495784b22ef82a69b6489f8d0092f) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> | 14 May 2018, 12:09:03 UTC |
2fa9d1c | Dave Hansen | 09 May 2018, 17:13:58 UTC | x86/pkeys: Do not special case protection key 0 mm_pkey_is_allocated() treats pkey 0 as unallocated. That is inconsistent with the manpages, and also inconsistent with mm->context.pkey_allocation_map. Stop special casing it and only disallow values that are actually bad (< 0). The end-user visible effect of this is that you can now use mprotect_pkey() to set pkey=0. This is a bit nicer than what Ram proposed[1] because it is simpler and removes special-casing for pkey 0. On the other hand, it does allow applications to pkey_free() pkey-0, but that's just a silly thing to do, so we are not going to protect against it. The scenario that could happen is similar to what happens if you free any other pkey that is in use: it might get reallocated later and used to protect some other data. The most likely scenario is that pkey-0 comes back from pkey_alloc(), an access-disable or write-disable bit is set in PKRU for it, and the next stack access will SIGSEGV. It's not horribly different from if you mprotect()'d your stack or heap to be unreadable or unwritable, which is generally very foolish, but also not explicitly prevented by the kernel. 1. http://lkml.kernel.org/r/1522112702-27853-1-git-send-email-linuxram@us.ibm.com Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com> Cc: Andrew Morton <akpm@linux-foundation.org>p Cc: Dave Hansen <dave.hansen@intel.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Michael Ellermen <mpe@ellerman.id.au> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Ram Pai <linuxram@us.ibm.com> Cc: Shuah Khan <shuah@kernel.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-mm@kvack.org Cc: stable@vger.kernel.org Fixes: 58ab9a088dda ("x86/pkeys: Check against max pkey to avoid overflows") Link: http://lkml.kernel.org/r/20180509171358.47FD785E@viggo.jf.intel.com Signed-off-by: Ingo Molnar <mingo@kernel.org> | 14 May 2018, 09:14:45 UTC |
3488a60 | Dave Hansen | 09 May 2018, 17:13:56 UTC | x86/pkeys/selftests: Add a test for pkey 0 Protection key 0 is the default key for all memory and will not normally come back from pkey_alloc(). But, you might still want pass it to mprotect_pkey(). This check ensures that you can use pkey 0. Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Dave Hansen <dave.hansen@intel.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Michael Ellermen <mpe@ellerman.id.au> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Ram Pai <linuxram@us.ibm.com> Cc: Shuah Khan <shuah@kernel.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-mm@kvack.org Link: http://lkml.kernel.org/r/20180509171356.9E40B254@viggo.jf.intel.com Signed-off-by: Ingo Molnar <mingo@kernel.org> | 14 May 2018, 09:14:45 UTC |
acb25d7 | Dave Hansen | 09 May 2018, 17:13:54 UTC | x86/pkeys/selftests: Save off 'prot' for allocations This makes it possible to to tell what 'prot' a given allocation is supposed to have. That way, if we want to change just the pkey, we know what 'prot' to pass to mprotect_pkey(). Also, keep a record of the most recent allocation so the tests can easily find it. Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Dave Hansen <dave.hansen@intel.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Michael Ellermen <mpe@ellerman.id.au> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Ram Pai <linuxram@us.ibm.com> Cc: Shuah Khan <shuah@kernel.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-mm@kvack.org Link: http://lkml.kernel.org/r/20180509171354.AA23E228@viggo.jf.intel.com Signed-off-by: Ingo Molnar <mingo@kernel.org> | 14 May 2018, 09:14:45 UTC |
3d64f4e | Dave Hansen | 09 May 2018, 17:13:52 UTC | x86/pkeys/selftests: Fix pointer math We dump out the entire area of the siginfo where the si_pkey_ptr is supposed to be. But, we do some math on the poitner, which is a u32. We intended to do byte math, not u32 math on the pointer. Cast it over to a u8* so it works. Also, move this block of code to below th si_code check. It doesn't hurt anything, but the si_pkey field is gibberish for other signal types. Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Dave Hansen <dave.hansen@intel.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Michael Ellermen <mpe@ellerman.id.au> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Ram Pai <linuxram@us.ibm.com> Cc: Shuah Khan <shuah@kernel.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-mm@kvack.org Link: http://lkml.kernel.org/r/20180509171352.9BE09819@viggo.jf.intel.com Signed-off-by: Ingo Molnar <mingo@kernel.org> | 14 May 2018, 09:14:45 UTC |
0a0b152 | Dave Hansen | 09 May 2018, 17:13:51 UTC | x86/pkeys: Override pkey when moving away from PROT_EXEC I got a bug report that the following code (roughly) was causing a SIGSEGV: mprotect(ptr, size, PROT_EXEC); mprotect(ptr, size, PROT_NONE); mprotect(ptr, size, PROT_READ); *ptr = 100; The problem is hit when the mprotect(PROT_EXEC) is implicitly assigned a protection key to the VMA, and made that key ACCESS_DENY|WRITE_DENY. The PROT_NONE mprotect() failed to remove the protection key, and the PROT_NONE-> PROT_READ left the PTE usable, but the pkey still in place and left the memory inaccessible. To fix this, we ensure that we always "override" the pkee at mprotect() if the VMA does not have execute-only permissions, but the VMA has the execute-only pkey. We had a check for PROT_READ/WRITE, but it did not work for PROT_NONE. This entirely removes the PROT_* checks, which ensures that PROT_NONE now works. Reported-by: Shakeel Butt <shakeelb@google.com> Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Dave Hansen <dave.hansen@intel.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Michael Ellermen <mpe@ellerman.id.au> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Ram Pai <linuxram@us.ibm.com> Cc: Shuah Khan <shuah@kernel.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-mm@kvack.org Cc: stable@vger.kernel.org Fixes: 62b5f7d013f ("mm/core, x86/mm/pkeys: Add execute-only protection keys support") Link: http://lkml.kernel.org/r/20180509171351.084C5A71@viggo.jf.intel.com Signed-off-by: Ingo Molnar <mingo@kernel.org> | 14 May 2018, 09:14:45 UTC |
f50b487 | Dave Hansen | 09 May 2018, 17:13:50 UTC | x86/pkeys/selftests: Fix pkey exhaustion test off-by-one In our "exhaust all pkeys" test, we make sure that there is the expected number available. Turns out that the test did not cover the execute-only key, but discussed it anyway. It did *not* discuss the test-allocated key. Now that we have a test for the mprotect(PROT_EXEC) case, this off-by-one issue showed itself. Correct the off-by- one and add the explanation for the case we missed. Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Dave Hansen <dave.hansen@intel.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Michael Ellermen <mpe@ellerman.id.au> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Ram Pai <linuxram@us.ibm.com> Cc: Shuah Khan <shuah@kernel.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-mm@kvack.org Link: http://lkml.kernel.org/r/20180509171350.E1656B95@viggo.jf.intel.com Signed-off-by: Ingo Molnar <mingo@kernel.org> | 14 May 2018, 09:14:45 UTC |
6af17cf | Dave Hansen | 09 May 2018, 17:13:48 UTC | x86/pkeys/selftests: Add PROT_EXEC test Under the covers, implement executable-only memory with protection keys when userspace calls mprotect(PROT_EXEC). But, we did not have a selftest for that. Now we do. Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Dave Hansen <dave.hansen@intel.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Michael Ellermen <mpe@ellerman.id.au> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Ram Pai <linuxram@us.ibm.com> Cc: Shuah Khan <shuah@kernel.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-mm@kvack.org Link: http://lkml.kernel.org/r/20180509171348.9EEE4BEF@viggo.jf.intel.com Signed-off-by: Ingo Molnar <mingo@kernel.org> | 14 May 2018, 09:14:45 UTC |
3fcd2b2 | Dave Hansen | 09 May 2018, 17:13:47 UTC | x86/pkeys/selftests: Factor out "instruction page" We currently have an execute-only test, but it is for the explicit mprotect_pkey() interface. We will soon add a test for the implicit mprotect(PROT_EXEC) enterface. We need this code in both tests. Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Dave Hansen <dave.hansen@intel.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Michael Ellermen <mpe@ellerman.id.au> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Ram Pai <linuxram@us.ibm.com> Cc: Shuah Khan <shuah@kernel.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-mm@kvack.org Link: http://lkml.kernel.org/r/20180509171347.C64AB733@viggo.jf.intel.com Signed-off-by: Ingo Molnar <mingo@kernel.org> | 14 May 2018, 09:14:45 UTC |
7e7fd67 | Dave Hansen | 09 May 2018, 17:13:46 UTC | x86/pkeys/selftests: Allow faults on unknown keys The exec-only pkey is allocated inside the kernel and userspace is not told what it is. So, allow PK faults to occur that have an unknown key. Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Dave Hansen <dave.hansen@intel.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Michael Ellermen <mpe@ellerman.id.au> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Ram Pai <linuxram@us.ibm.com> Cc: Shuah Khan <shuah@kernel.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-mm@kvack.org Link: http://lkml.kernel.org/r/20180509171345.7FC7DA00@viggo.jf.intel.com Signed-off-by: Ingo Molnar <mingo@kernel.org> | 14 May 2018, 09:14:45 UTC |
caf9eb6 | Dave Hansen | 09 May 2018, 17:13:44 UTC | x86/pkeys/selftests: Avoid printf-in-signal deadlocks printf() and friends are unusable in signal handlers. They deadlock. The pkey selftest does not do any normal printing in signal handlers, only extra debugging. So, just print the format string so we get *some* output when debugging. Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Dave Hansen <dave.hansen@intel.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Michael Ellermen <mpe@ellerman.id.au> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Ram Pai <linuxram@us.ibm.com> Cc: Shuah Khan <shuah@kernel.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-mm@kvack.org Link: http://lkml.kernel.org/r/20180509171344.C53FD2F3@viggo.jf.intel.com Signed-off-by: Ingo Molnar <mingo@kernel.org> | 14 May 2018, 09:14:45 UTC |
a50093d | Dave Hansen | 09 May 2018, 17:13:42 UTC | x86/pkeys/selftests: Remove dead debugging code, fix dprint_in_signal There is some noisy debug code at the end of the signal handler. It was disabled by an early, unconditional "return". However, that return also hid a dprint_in_signal=0, which kept dprint_in_signal=1 and effectively locked us into permanent dprint_in_signal=1 behavior. Remove the return and the dead code, fixing dprint_in_signal. Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Dave Hansen <dave.hansen@intel.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Michael Ellermen <mpe@ellerman.id.au> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Ram Pai <linuxram@us.ibm.com> Cc: Shuah Khan <shuah@kernel.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-mm@kvack.org Link: http://lkml.kernel.org/r/20180509171342.846B9B2E@viggo.jf.intel.com Signed-off-by: Ingo Molnar <mingo@kernel.org> | 14 May 2018, 09:14:45 UTC |
86b9eea | Dave Hansen | 09 May 2018, 17:13:40 UTC | x86/pkeys/selftests: Stop using assert() If we use assert(), the program "crashes". That can be scary to users, so stop doing it. Just exit with a >0 exit code instead. Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Dave Hansen <dave.hansen@intel.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Michael Ellermen <mpe@ellerman.id.au> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Ram Pai <linuxram@us.ibm.com> Cc: Shuah Khan <shuah@kernel.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-mm@kvack.org Link: http://lkml.kernel.org/r/20180509171340.E63EF7DA@viggo.jf.intel.com Signed-off-by: Ingo Molnar <mingo@kernel.org> | 14 May 2018, 09:14:45 UTC |
55556b0 | Dave Hansen | 09 May 2018, 17:13:38 UTC | x86/pkeys/selftests: Give better unexpected fault error messages do_not_expect_pk_fault() is a helper that we call when we do not expect a PK fault to have occurred. But, it is a function, which means that it obscures the line numbers from pkey_assert(). It also gives no details. Replace it with an implementation that gives nice line numbers and also lets callers pass in a more descriptive message about what happened that caused the unexpected fault. Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Dave Hansen <dave.hansen@intel.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Michael Ellermen <mpe@ellerman.id.au> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Ram Pai <linuxram@us.ibm.com> Cc: Shuah Khan <shuah@kernel.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-mm@kvack.org Link: http://lkml.kernel.org/r/20180509171338.55D13B64@viggo.jf.intel.com Signed-off-by: Ingo Molnar <mingo@kernel.org> | 14 May 2018, 09:14:45 UTC |
59c2a72 | Andy Lutomirski | 08 May 2018, 17:28:35 UTC | x86/selftests: Add mov_to_ss test This exercises a nasty corner case of the x86 ISA. Signed-off-by: Andy Lutomirski <luto@kernel.org> Cc: Borislav Petkov <bp@alien8.de> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/67e08b69817171da8026e0eb3af0214b06b4d74f.1525800455.git.luto@kernel.org Signed-off-by: Ingo Molnar <mingo@kernel.org> | 14 May 2018, 09:14:45 UTC |
73bb4d6 | Ingo Molnar | 14 May 2018, 08:59:08 UTC | x86/mpx/selftests: Adjust the self-test to fresh distros that export the MPX ABI Fix this warning: mpx-mini-test.c:422:0: warning: "SEGV_BNDERR" redefined Cc: Dave Hansen <dave.hansen@linux.intel.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: akpm@linux-foundation.org Cc: dave.hansen@intel.com Cc: linux-mm@kvack.org Cc: linuxram@us.ibm.com Cc: mpe@ellerman.id.au Cc: shakeelb@google.com Cc: shuah@kernel.org Link: http://lkml.kernel.org/r/20180514085908.GA12798@gmail.com Signed-off-by: Ingo Molnar <mingo@kernel.org> | 14 May 2018, 09:14:45 UTC |
0fb9662 | Ingo Molnar | 14 May 2018, 08:56:23 UTC | x86/pkeys/selftests: Adjust the self-test to fresh distros that export the pkeys ABI Ubuntu 18.04 started exporting pkeys details in header files, resulting in build failures and warnings in the pkeys self-tests: protection_keys.c:232:0: warning: "SEGV_BNDERR" redefined protection_keys.c:387:5: error: conflicting types for ‘pkey_get’ protection_keys.c:409:5: error: conflicting types for ‘pkey_set’ ... Fix these namespace conflicts and double definitions, plus also clean up the ABI definitions to make it all a bit more readable ... Cc: Dave Hansen <dave.hansen@linux.intel.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: akpm@linux-foundation.org Cc: dave.hansen@intel.com Cc: linux-mm@kvack.org Cc: linuxram@us.ibm.com Cc: mpe@ellerman.id.au Cc: shakeelb@google.com Cc: shuah@kernel.org Link: http://lkml.kernel.org/r/20180514085623.GB7094@gmail.com Signed-off-by: Ingo Molnar <mingo@kernel.org> | 14 May 2018, 09:14:45 UTC |
4a09f02 | Alexander Potapenko | 09 May 2018, 09:18:22 UTC | x86/boot/64/clang: Use fixup_pointer() to access '__supported_pte_mask' Clang builds with defconfig started crashing after the following commit: fb43d6cb91ef ("x86/mm: Do not auto-massage page protections") This was caused by introducing a new global access in __startup_64(). Code in __startup_64() can be relocated during execution, but the compiler doesn't have to generate PC-relative relocations when accessing globals from that function. Clang actually does not generate them, which leads to boot-time crashes. To work around this problem, every global pointer must be adjusted using fixup_pointer(). Signed-off-by: Alexander Potapenko <glider@google.com> Reviewed-by: Dave Hansen <dave.hansen@intel.com> Acked-by: Thomas Gleixner <tglx@linutronix.de> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: dvyukov@google.com Cc: kirill.shutemov@linux.intel.com Cc: linux-mm@kvack.org Cc: md@google.com Cc: mka@chromium.org Fixes: fb43d6cb91ef ("x86/mm: Do not auto-massage page protections") Link: http://lkml.kernel.org/r/20180509091822.191810-1-glider@google.com Signed-off-by: Ingo Molnar <mingo@kernel.org> | 14 May 2018, 09:14:30 UTC |
2278446 | Mathias Nyman | 14 May 2018, 08:57:23 UTC | xhci: Fix USB3 NULL pointer dereference at logical disconnect. Hub driver will try to disable a USB3 device twice at logical disconnect, racing with xhci_free_dev() callback from the first port disable. This can be triggered with "udisksctl power-off --block-device <disk>" or by writing "1" to the "remove" sysfs file for a USB3 device in 4.17-rc4. USB3 devices don't have a similar disabled link state as USB2 devices, and use a U3 suspended link state instead. In this state the port is still enabled and connected. hub_port_connect() first disconnects the device, then later it notices that device is still enabled (due to U3 states) it will try to disable the port again (set to U3). The xhci_free_dev() called during device disable is async, so checking for existing xhci->devs[i] when setting link state to U3 the second time was successful, even if device was being freed. The regression was caused by, and whole thing revealed by, Commit 44a182b9d177 ("xhci: Fix use-after-free in xhci_free_virt_device") which sets xhci->devs[i]->udev to NULL before xhci_virt_dev() returned. and causes a NULL pointer dereference the second time we try to set U3. Fix this by checking xhci->devs[i]->udev exists before setting link state. The original patch went to stable so this fix needs to be applied there as well. Fixes: 44a182b9d177 ("xhci: Fix use-after-free in xhci_free_virt_device") Cc: <stable@vger.kernel.org> Reported-by: Jordan Glover <Golden_Miller83@protonmail.ch> Tested-by: Jordan Glover <Golden_Miller83@protonmail.ch> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> | 14 May 2018, 09:05:53 UTC |
fd35c88 | Josh Poimboeuf | 10 May 2018, 22:48:49 UTC | objtool: Support GCC 8 switch tables With GCC 8, some issues were found with the objtool switch table detection. 1) In the .rodata section, immediately after the switch table, there can be another object which contains a pointer to the function which had the switch statement. In this case objtool wrongly considers the function pointer to be part of the switch table. Fix it by: a) making sure there are no pointers to the beginning of the function; and b) making sure there are no gaps in the switch table. Only the former was needed, the latter adds additional protection for future optimizations. 2) In find_switch_table(), case 1 and case 2 are missing the check to ensure that the .rodata switch table data is anonymous, i.e. that it isn't already associated with an ELF symbol. Fix it by adding the same find_symbol_containing() check which is used for case 3. This fixes the following warnings with GCC 8: drivers/block/virtio_blk.o: warning: objtool: virtio_queue_rq()+0x0: stack state mismatch: cfa1=7+8 cfa2=7+72 net/ipv6/icmp.o: warning: objtool: icmpv6_rcv()+0x0: stack state mismatch: cfa1=7+8 cfa2=7+64 drivers/usb/core/quirks.o: warning: objtool: quirks_param_set()+0x0: stack state mismatch: cfa1=7+8 cfa2=7+48 drivers/mtd/nand/raw/nand_hynix.o: warning: objtool: hynix_nand_decode_id()+0x0: stack state mismatch: cfa1=7+8 cfa2=7+24 drivers/mtd/nand/raw/nand_samsung.o: warning: objtool: samsung_nand_decode_id()+0x0: stack state mismatch: cfa1=7+8 cfa2=7+32 drivers/gpu/drm/nouveau/nvkm/subdev/top/gk104.o: warning: objtool: gk104_top_oneinit()+0x0: stack state mismatch: cfa1=7+8 cfa2=7+64 Reported-by: Arnd Bergmann <arnd@arndb.de> Reported-by: kbuild test robot <lkp@intel.com> Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com> Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org> Cc: David Laight <David.Laight@ACULAB.COM> Cc: Greg KH <gregkh@linuxfoundation.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Randy Dunlap <rdunlap@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: damian <damian.tometzki@icloud.com> Link: http://lkml.kernel.org/r/20180510224849.xwi34d6tzheb5wgw@treble Signed-off-by: Ingo Molnar <mingo@kernel.org> | 14 May 2018, 08:20:54 UTC |
1381043 | Josh Poimboeuf | 10 May 2018, 03:39:15 UTC | objtool: Support GCC 8's cold subfunctions GCC 8 moves a lot of unlikely code out of line to "cold" subfunctions in .text.unlikely. Properly detect the new subfunctions and treat them as extensions of the original functions. This fixes a bunch of warnings like: kernel/cgroup/cgroup.o: warning: objtool: parse_cgroup_root_flags()+0x33: sibling call from callable instruction with modified stack frame kernel/cgroup/cgroup.o: warning: objtool: cgroup_addrm_files()+0x290: sibling call from callable instruction with modified stack frame kernel/cgroup/cgroup.o: warning: objtool: cgroup_apply_control_enable()+0x25b: sibling call from callable instruction with modified stack frame kernel/cgroup/cgroup.o: warning: objtool: rebind_subsystems()+0x325: sibling call from callable instruction with modified stack frame Reported-and-tested-by: damian <damian.tometzki@icloud.com> Reported-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com> Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org> Cc: David Laight <David.Laight@ACULAB.COM> Cc: Greg KH <gregkh@linuxfoundation.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Randy Dunlap <rdunlap@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/0965e7fcfc5f31a276f0c7f298ff770c19b68706.1525923412.git.jpoimboe@redhat.com Signed-off-by: Ingo Molnar <mingo@kernel.org> | 14 May 2018, 08:20:53 UTC |
0afd0d9 | Josh Poimboeuf | 10 May 2018, 03:39:14 UTC | objtool: Fix "noreturn" detection for recursive sibling calls Objtool has some crude logic for detecting static "noreturn" functions (aka "dead ends"). This is necessary for being able to correctly follow GCC code flow when such functions are called. It's remotely possible for two functions to call each other via sibling calls. If they don't have RET instructions, objtool's noreturn detection logic goes into a recursive loop: drivers/char/ipmi/ipmi_ssif.o: warning: objtool: return_hosed_msg()+0x0: infinite recursion (objtool bug!) drivers/char/ipmi/ipmi_ssif.o: warning: objtool: deliver_recv_msg()+0x0: infinite recursion (objtool bug!) Instead of reporting an error in this case, consider the functions to be non-dead-ends. Reported-and-tested-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com> Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org> Cc: Arnd Bergmann <arnd@arndb.de> Cc: David Laight <David.Laight@ACULAB.COM> Cc: Greg KH <gregkh@linuxfoundation.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: damian <damian.tometzki@icloud.com> Link: http://lkml.kernel.org/r/7cc156408c5781a1f62085d352ced1fe39fe2f91.1525923412.git.jpoimboe@redhat.com Signed-off-by: Ingo Molnar <mingo@kernel.org> | 14 May 2018, 08:20:53 UTC |
4fe875e | Ingo Molnar | 14 May 2018, 08:15:54 UTC | objtool, kprobes/x86: Sync the latest <asm/insn.h> header with tools/objtool/arch/x86/include/asm/insn.h The following commit: ee6a7354a362: kprobes/x86: Prohibit probing on exception masking instructions Modified <asm/insn.h>, adding the insn_masking_exception() function. Sync the tooling version of the header to it, to fix this warning: Warning: synced file at 'tools/objtool/arch/x86/include/asm/insn.h' differs from latest kernel version at 'arch/x86/include/asm/insn.h' Cc: Peter Zijlstra <peterz@infradead.org> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Masami Hiramatsu <mhiramat@kernel.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ricardo Neri <ricardo.neri-calderon@linux.intel.com> Cc: Francis Deslauriers <francis.deslauriers@efficios.com> Cc: Oleg Nesterov <oleg@redhat.com> Cc: Alexei Starovoitov <ast@kernel.org> Cc: Steven Rostedt <rostedt@goodmis.org> Cc: Andy Lutomirski <luto@kernel.org> Cc: "H . Peter Anvin" <hpa@zytor.com> Cc: Yonghong Song <yhs@fb.com> Cc: Borislav Petkov <bp@suse.de> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: "David S . Miller" <davem@davemloft.net> Signed-off-by: Ingo Molnar <mingo@kernel.org> | 14 May 2018, 08:15:54 UTC |
115c93e | Olof Johansson | 14 May 2018, 08:05:30 UTC | Merge tag 'imx-fixes-4.17' of git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux into fixes i.MX fixes for 4.17: - Add missing 'fsl,sec-era' property for i.MX7S device tree CAAM node, as the era information is used in various places inside CAAM driver. - There are a few errors in imx51-zii-rdu1 device tree touchscreen node. Fix them to get touchscreen actually work. * tag 'imx-fixes-4.17' of git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux: ARM: dts: imx51-zii-rdu1: fix touchscreen bindings ARM: dts: imx7s: Pass the 'fsl,sec-era' property Signed-off-by: Olof Johansson <olof@lixom.net> | 14 May 2018, 08:05:30 UTC |
16145ff | Olof Johansson | 14 May 2018, 08:05:00 UTC | Merge tag 'scmi-fixes-4.17' of git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux into fixes SCMI fix for v4.17 A single patch to ensure that the scmi device is not used for setting up scmi handle after it's freed(fixes use after free). * tag 'scmi-fixes-4.17' of git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux: firmware: arm_scmi: Use after free in scmi_create_protocol_device() Signed-off-by: Olof Johansson <olof@lixom.net> | 14 May 2018, 08:05:00 UTC |
602a424 | Olof Johansson | 14 May 2018, 08:03:47 UTC | Merge tag 'omap-for-v17/fixes-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into fixes Fixes for omap variants for v4.17 This series of patches contains one BUG fix for trace if CONFIG_DEBUG_PREEMPT is enabled and a regression fix for omap1 FIQ handling on ams-delta. Then there's a dts fix for missing SoC compatible on ti81xx board dts files that did matter until we added the clkctrl clocks and without that some clocks are now not found. Then there are two logicpd-som-lv specific dts fixes that fix misconfigured pins for WLAN and audio. Turns out we had to revert the third one because it caused another regression for USB. * tag 'omap-for-v17/fixes-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap: Revert "ARM: dts: logicpd-som-lv: Fix pinmux controller references" ARM: dts: correct missing "compatible" entry for ti81xx SoCs ARM: OMAP1: ams-delta: fix deferred_fiq handler ARM: dts: logicpd-som-lv: Fix pinmux controller references ARM: dts: logicpd-som-lv: Fix Audio Mute ARM: dts: logicpd-som-lv: Fix WL127x Startup Issues ARM: OMAP2+: powerdomain: use raw_smp_processor_id() for trace Signed-off-by: Olof Johansson <olof@lixom.net> | 14 May 2018, 08:03:47 UTC |
51dff16 | Olof Johansson | 14 May 2018, 08:03:01 UTC | Merge tag 'arm-soc/for-4.17/devicetree-fixes' of https://github.com/Broadcom/stblinux into fixes This pull request contains Broadcom ARM-basec SoCs Device Tree fixes for 4.17, please pull the following: - Clement fixes in an incorrect trigger type for the ARM global timers on the Cygnus platforms * tag 'arm-soc/for-4.17/devicetree-fixes' of https://github.com/Broadcom/stblinux: ARM: dts: cygnus: fix irq type for arm global timer Signed-off-by: Olof Johansson <olof@lixom.net> | 14 May 2018, 08:03:01 UTC |
c1c6fe6 | Olof Johansson | 14 May 2018, 08:02:11 UTC | Merge tag 'tee-drv-fixes-for-4.17' of git://git.linaro.org/people/jens.wiklander/linux-tee into fixes Small fixes for tee subsystem * Fixes for use-after-free via temporarily dropped reference * Checks that passed shm references are consistent in offset/size with regards to the shm object * tag 'tee-drv-fixes-for-4.17' of git://git.linaro.org/people/jens.wiklander/linux-tee: tee: check shm references are consistent in offset/size tee: shm: fix use-after-free via temporarily dropped reference Signed-off-by: Olof Johansson <olof@lixom.net> | 14 May 2018, 08:02:11 UTC |
0d463d8 | Marek Szyprowski | 06 May 2018, 14:55:24 UTC | arm64: dts: exynos: Fix interrupt type for I2S1 device on Exynos5433 All interrupts from SoC internal modules are level triggered, so fix incorrect trigger type for I2S1 device on Exynos5433 SoCs. This fixes following kernel warning: WARNING: CPU: 2 PID: 1 at drivers/irqchip/irq-gic.c:1016 gic_irq_domain_translate+0xb0/0xb8 Modules linked in: CPU: 2 PID: 1 Comm: swapper/0 Not tainted 4.16.0-rc7-next-20180329 #646 Hardware name: Samsung TM2 board (DT) pstate: 20000005 (nzCv daif -PAN -UAO) pc : gic_irq_domain_translate+0xb0/0xb8 lr : irq_create_fwspec_mapping+0x64/0x328 sp : ffff0000098b38d0 ... Call trace: gic_irq_domain_translate+0xb0/0xb8 irq_create_of_mapping+0x78/0xa0 of_irq_get+0x6c/0xa0 of_irq_to_resource+0x38/0x108 of_irq_to_resource_table+0x50/0x78 of_device_alloc+0x118/0x1b8 of_platform_device_create_pdata+0x54/0xe0 of_platform_bus_create+0x118/0x340 of_platform_bus_create+0x17c/0x340 of_platform_populate+0x74/0xd8 of_platform_default_populate_init+0xb0/0xcc do_one_initcall+0x50/0x158 kernel_init_freeable+0x184/0x22c kernel_init+0x10/0x108 ret_from_fork+0x10/0x18 ---[ end trace 6decb2b3078d73f0 ]--- Fixes: d8d579c316e8 ("ARM: dts: exynos: Add I2S1 device node to exynos5433") Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by: Olof Johansson <olof@lixom.net> | 14 May 2018, 08:01:28 UTC |
0e68f92 | Olof Johansson | 14 May 2018, 08:00:17 UTC | Merge tag 'tegra-for-4.17-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux into fixes ARM: tegra: Device tree fixes for v4.17 This contains a single revert for a patch that was merged in v4.17-rc1 and that turns out to cause a regression on some boards. Further, the original issue that the patch was supposed to fix seems to have disappeared. * tag 'tegra-for-4.17-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux: ARM: dts: tegra20: Revert "Fix ULPI regression on Tegra20" Signed-off-by: Olof Johansson <olof@lixom.net> | 14 May 2018, 08:00:17 UTC |
8ee7424 | Olof Johansson | 14 May 2018, 07:59:02 UTC | Merge tag 'davinci-fixes-for-v4.17' of git://git.kernel.org/pub/scm/linux/kernel/git/nsekhar/linux-davinci into fixes DaVinci fixes for v4.17 * W=1 warning fixes in device-tree files * GPIO look-up fixes for legacy boot on several platforms * tag 'davinci-fixes-for-v4.17' of git://git.kernel.org/pub/scm/linux/kernel/git/nsekhar/linux-davinci: ARM: davinci: fix GPIO lookup for I2C ARM: davinci: board-dm355-evm: fix broken networking ARM: davinci: board-omapl138-hawk: fix GPIO numbers for MMC/SD lookup ARM: davinci: board-da850-evm: fix GPIO lookup for MMC/SD ARM: davinci: board-da830-evm: fix GPIO lookup for MMC/SD ARM: dts: da850: fix W=1 warnings with pinmux node ARM: dts: da850-lcdk: add unit name for memory node ARM: dts: da850: get rid of skeleton.dtsi Signed-off-by: Olof Johansson <olof@lixom.net> | 14 May 2018, 07:59:02 UTC |
1e61f54 | Olof Johansson | 14 May 2018, 07:58:07 UTC | Merge tag 'renesas-fixes-for-v4.17' of https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas into fixes Renesas ARM Based SoC Fixes for v4.17 Fix LVDS output on Gen2 boards Laurent Pincart says "This patch series fixes LVDS output support on the Lager, Koelsh, Porter and Gose boards that broke in v4.17-rc1 due to the combination of the R-Car DU LVDS driver rework and the DT move of all on-SoC peripherals to a /soc node. We could handle the problem in the R-Car DU LVDS DT backward compatibility code, but that fix would only be used for v4.17 as in v4.18 the Gen2 DT will move to the new LVDS DT bindings. I thus propose merging these three patches in v4.17 already to fix the problem as this is the simplest solution." * tag 'renesas-fixes-for-v4.17' of https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas: ARM: dts: r8a7793: Convert to new LVDS DT bindings ARM: dts: r8a7791: Convert to new LVDS DT bindings ARM: dts: r8a7790: Convert to new LVDS DT bindings Signed-off-by: Olof Johansson <olof@lixom.net> | 14 May 2018, 07:58:07 UTC |
bd37d15 | Olof Johansson | 14 May 2018, 07:57:39 UTC | Merge tag 'uniphier-fixes-v4.17' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-uniphier into fixes UniPhier ARM SoC fixes for v4.17 - Fix input delay parameter of eMMC PHY - Weaken drive-strength of ethernet PHY pins of LD20 reference board * tag 'uniphier-fixes-v4.17' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-uniphier: arm64: dts: uniphier: stabilize ethernet of LD20 reference board arm64: dts: uniphier: fix input delay value for legacy mode of eMMC Signed-off-by: Olof Johansson <olof@lixom.net> | 14 May 2018, 07:57:39 UTC |
0b3225a | Ard Biesheuvel | 04 May 2018, 05:59:58 UTC | efi: Avoid potential crashes, fix the 'struct efi_pci_io_protocol_32' definition for mixed mode Mixed mode allows a kernel built for x86_64 to interact with 32-bit EFI firmware, but requires us to define all struct definitions carefully when it comes to pointer sizes. 'struct efi_pci_io_protocol_32' currently uses a 'void *' for the 'romimage' field, which will be interpreted as a 64-bit field on such kernels, potentially resulting in bogus memory references and subsequent crashes. Tested-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: <stable@vger.kernel.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Matt Fleming <matt@codeblueprint.co.uk> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-efi@vger.kernel.org Link: http://lkml.kernel.org/r/20180504060003.19618-13-ard.biesheuvel@linaro.org Signed-off-by: Ingo Molnar <mingo@kernel.org> | 14 May 2018, 06:56:29 UTC |
67b8d5c | Linus Torvalds | 13 May 2018, 23:15:17 UTC | Linux 4.17-rc5 | 13 May 2018, 23:15:17 UTC |
b1ae32d | Alexei Starovoitov | 13 May 2018, 19:32:22 UTC | x86/cpufeature: Guard asm_volatile_goto usage for BPF compilation Workaround for the sake of BPF compilation which utilizes kernel headers, but clang does not support ASM GOTO and fails the build. Fixes: d0266046ad54 ("x86: Remove FAST_FEATURE_TESTS") Suggested-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Alexei Starovoitov <ast@kernel.org> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Cc: daniel@iogearbox.net Cc: peterz@infradead.org Cc: netdev@vger.kernel.org Cc: bp@alien8.de Cc: yhs@fb.com Cc: kernel-team@fb.com Cc: torvalds@linux-foundation.org Cc: davem@davemloft.net Link: https://lkml.kernel.org/r/20180513193222.1997938-1-ast@kernel.org | 13 May 2018, 19:49:14 UTC |
66e1c94 | Linus Torvalds | 13 May 2018, 17:53:08 UTC | Merge branch 'x86-pti-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull x86/pti updates from Thomas Gleixner: "A mixed bag of fixes and updates for the ghosts which are hunting us. The scheduler fixes have been pulled into that branch to avoid conflicts. - A set of fixes to address a khread_parkme() race which caused lost wakeups and loss of state. - A deadlock fix for stop_machine() solved by moving the wakeups outside of the stopper_lock held region. - A set of Spectre V1 array access restrictions. The possible problematic spots were discuvered by Dan Carpenters new checks in smatch. - Removal of an unused file which was forgotten when the rest of that functionality was removed" * 'x86-pti-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: x86/vdso: Remove unused file perf/x86/cstate: Fix possible Spectre-v1 indexing for pkg_msr perf/x86/msr: Fix possible Spectre-v1 indexing in the MSR driver perf/x86: Fix possible Spectre-v1 indexing for x86_pmu::event_map() perf/x86: Fix possible Spectre-v1 indexing for hw_perf_event cache_* perf/core: Fix possible Spectre-v1 indexing for ->aux_pages[] sched/autogroup: Fix possible Spectre-v1 indexing for sched_prio_to_weight[] sched/core: Fix possible Spectre-v1 indexing for sched_prio_to_weight[] sched/core: Introduce set_special_state() kthread, sched/wait: Fix kthread_parkme() completion issue kthread, sched/wait: Fix kthread_parkme() wait-loop sched/fair: Fix the update of blocked load when newly idle stop_machine, sched: Fix migrate_swap() vs. active_balance() deadlock | 13 May 2018, 17:53:08 UTC |
13ebe18 | Masami Hiramatsu | 09 May 2018, 12:58:45 UTC | uprobes/x86: Prohibit probing on MOV SS instruction Since MOV SS and POP SS instructions will delay the exceptions until the next instruction is executed, single-stepping on it by uprobes must be prohibited. uprobe already rejects probing on POP SS (0x1f), but allows probing on MOV SS (0x8e and reg == 2). This checks the target instruction and if it is MOV SS or POP SS, returns -ENOTSUPP to reject probing. Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: Oleg Nesterov <oleg@redhat.com> Cc: Ricardo Neri <ricardo.neri-calderon@linux.intel.com> Cc: Francis Deslauriers <francis.deslauriers@efficios.com> Cc: Alexei Starovoitov <ast@kernel.org> Cc: Steven Rostedt <rostedt@goodmis.org> Cc: Andy Lutomirski <luto@kernel.org> Cc: "H . Peter Anvin" <hpa@zytor.com> Cc: Yonghong Song <yhs@fb.com> Cc: Borislav Petkov <bp@suse.de> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: "David S . Miller" <davem@davemloft.net> Link: https://lkml.kernel.org/r/152587072544.17316.5950935243917346341.stgit@devbox | 13 May 2018, 17:52:56 UTC |
ee6a735 | Masami Hiramatsu | 09 May 2018, 12:58:15 UTC | kprobes/x86: Prohibit probing on exception masking instructions Since MOV SS and POP SS instructions will delay the exceptions until the next instruction is executed, single-stepping on it by kprobes must be prohibited. However, kprobes usually executes those instructions directly on trampoline buffer (a.k.a. kprobe-booster), except for the kprobes which has post_handler. Thus if kprobe user probes MOV SS with post_handler, it will do single-stepping on the MOV SS. This means it is safe that if it is used via ftrace or perf/bpf since those don't use the post_handler. Anyway, since the stack switching is a rare case, it is safer just rejecting kprobes on such instructions. Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Cc: Ricardo Neri <ricardo.neri-calderon@linux.intel.com> Cc: Francis Deslauriers <francis.deslauriers@efficios.com> Cc: Oleg Nesterov <oleg@redhat.com> Cc: Alexei Starovoitov <ast@kernel.org> Cc: Steven Rostedt <rostedt@goodmis.org> Cc: Andy Lutomirski <luto@kernel.org> Cc: "H . Peter Anvin" <hpa@zytor.com> Cc: Yonghong Song <yhs@fb.com> Cc: Borislav Petkov <bp@suse.de> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: "David S . Miller" <davem@davemloft.net> Link: https://lkml.kernel.org/r/152587069574.17316.3311695234863248641.stgit@devbox | 13 May 2018, 17:52:55 UTC |
a466ef7 | Tetsuo Handa | 09 May 2018, 10:42:20 UTC | x86/kexec: Avoid double free_page() upon do_kexec_load() failure >From ff82bedd3e12f0d3353282054ae48c3bd8c72012 Mon Sep 17 00:00:00 2001 From: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Date: Wed, 9 May 2018 12:12:39 +0900 Subject: [PATCH v3] x86/kexec: avoid double free_page() upon do_kexec_load() failure. syzbot is reporting crashes after memory allocation failure inside do_kexec_load() [1]. This is because free_transition_pgtable() is called by both init_transition_pgtable() and machine_kexec_cleanup() when memory allocation failed inside init_transition_pgtable(). Regarding 32bit code, machine_kexec_free_page_tables() is called by both machine_kexec_alloc_page_tables() and machine_kexec_cleanup() when memory allocation failed inside machine_kexec_alloc_page_tables(). Fix this by leaving the error handling to machine_kexec_cleanup() (and optionally setting NULL after free_page()). [1] https://syzkaller.appspot.com/bug?id=91e52396168cf2bdd572fe1e1bc0bc645c1c6b40 Fixes: f5deb79679af6eb4 ("x86: kexec: Use one page table in x86_64 machine_kexec") Fixes: 92be3d6bdf2cb349 ("kexec/i386: allocate page table pages dynamically") Reported-by: syzbot <syzbot+d96f60296ef613fe1d69@syzkaller.appspotmail.com> Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: Baoquan He <bhe@redhat.com> Cc: thomas.lendacky@amd.com Cc: prudo@linux.vnet.ibm.com Cc: Huang Ying <ying.huang@intel.com> Cc: syzkaller-bugs@googlegroups.com Cc: takahiro.akashi@linaro.org Cc: H. Peter Anvin <hpa@zytor.com> Cc: akpm@linux-foundation.org Cc: dyoung@redhat.com Cc: kirill.shutemov@linux.intel.com Link: https://lkml.kernel.org/r/201805091942.DGG12448.tMFVFSJFQOOLHO@I-love.SAKURA.ne.jp | 13 May 2018, 17:50:06 UTC |
86a4ac4 | Linus Torvalds | 13 May 2018, 17:46:53 UTC | Merge branch 'sched-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull scheduler fix from Thomas Gleixner: "Revert the new NUMA aware placement approach which turned out to create more problems than it solved" * 'sched-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: Revert "sched/numa: Delay retrying placement for automatic NUMA balance after wake_affine()" | 13 May 2018, 17:46:53 UTC |
baeda71 | Linus Torvalds | 13 May 2018, 17:44:32 UTC | Merge branch 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull perf tooling fixes from Thomas Gleixner: "Another small set of perf tooling fixes and updates: - Revert "perf pmu: Fix pmu events parsing rule", as it broke Intel PT event description parsing (Arnaldo Carvalho de Melo) - Sync x86's cpufeatures.h and kvm UAPI headers with the kernel sources, suppressing the ABI drift warnings (Arnaldo Carvalho de Melo) - Remove duplicated entry for westmereep-dp in Intel's mapfile.csv (William Cohen) - Fix typo in 'perf bench numa' options description (Yisheng Xie)" * 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: Revert "perf pmu: Fix pmu events parsing rule" tools headers kvm: Sync ARM UAPI headers with the kernel sources tools headers kvm: Sync uapi/linux/kvm.h with the kernel sources tools headers: Sync x86 cpufeatures.h with the kernel sources perf vendor events intel: Remove duplicated entry for westmereep-dp in mapfile.csv perf bench numa: Fix typo in options | 13 May 2018, 17:44:32 UTC |
0503fd6 | Linus Torvalds | 13 May 2018, 17:28:53 UTC | Merge tag 'dma-mapping-4.17-5' of git://git.infradead.org/users/hch/dma-mapping Pull dma-mapping fix from Christoph Hellwig: "Just one little fix from Jean to avoid a harmless but very annoying warning, especially for the drm code" * tag 'dma-mapping-4.17-5' of git://git.infradead.org/users/hch/dma-mapping: swiotlb: silent unwanted warning "buffer is full" | 13 May 2018, 17:28:53 UTC |
2f0d520 | Jeremy Soller | 07 May 2018, 15:28:45 UTC | ALSA: hda/realtek - Clevo P950ER ALC1220 Fixup This adds support for the P950ER, which has the same required fixup as the P950HR, but has a different PCI ID. Signed-off-by: Jeremy Soller <jeremy@system76.com> Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de> | 13 May 2018, 16:55:46 UTC |
2149331 | Federico Cuello | 08 May 2018, 22:13:38 UTC | ALSA: usb: mixer: volume quirk for CM102-A+/102S+ Currently it's not possible to set volume lower than 26% (it just mutes). Also fixes this warning: Warning! Unlikely big volume range (=9472), cval->res is probably wrong. [13] FU [PCM Playback Volume] ch = 2, val = -9473/-1/1 , and volume works fine for full range. Signed-off-by: Federico Cuello <fedux@fedux.com.ar> Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de> | 13 May 2018, 16:53:53 UTC |
3b03162 | Guenter Roeck | 04 May 2018, 20:01:33 UTC | hwmon: (k10temp) Use API function to access System Management Network The SMN (System Management Network) on Family 17h AMD CPUs is also accessed from other drivers, specifically EDAC. Accessing it directly is racy. On top of that, accessing the SMN through root bridge 00:00 is wrong on multi-die CPUs and may result in reading the temperature from the wrong die. Use available API functions to fix the problem. For this to work, add dependency on AMD_NB. Also change the Raven Ridge PCI device ID to point to Data Fabric Function 3, since this ID is used by the API functions to find the CPU node. Cc: stable@vger.kernel.org # v4.16+ Tested-by: Gabriel Craciunescu <nix.or.die@gmail.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net> | 13 May 2018, 16:00:49 UTC |
f9bc6b2 | Guenter Roeck | 04 May 2018, 20:01:32 UTC | x86/amd_nb: Add support for Raven Ridge CPUs Add Raven Ridge root bridge and data fabric PCI IDs. This is required for amd_pci_dev_to_node_id() and amd_smn_read(). Cc: stable@vger.kernel.org # v4.16+ Tested-by: Gabriel Craciunescu <nix.or.die@gmail.com> Acked-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Guenter Roeck <linux@roeck-us.net> | 13 May 2018, 16:00:27 UTC |
c8beccc | Hans de Goede | 08 May 2018, 07:27:46 UTC | ALSA: hda: Add Lenovo C50 All in one to the power_save blacklist Power-saving is causing loud plops on the Lenovo C50 All in one, add it to the blacklist. BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1572975 Signed-off-by: Hans de Goede <hdegoede@redhat.com> Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de> | 13 May 2018, 14:44:35 UTC |