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 |
---|---|---|---|---|
81f70ba | Linus Torvalds | 20 February 2016, 21:39:35 UTC | Linux 4.5-rc5 | 20 February 2016, 21:39:35 UTC |
0389075 | Linus Torvalds | 20 February 2016, 17:32:40 UTC | Merge branch 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull x86 fixes from Ingo Molnar: "This is unusually large, partly due to the EFI fixes that prevent accidental deletion of EFI variables through efivarfs that may brick machines. These fixes are somewhat involved to maintain compatibility with existing install methods and other usage modes, while trying to turn off the 'rm -rf' bricking vector. Other fixes are for large page ioremap()s and for non-temporal user-memcpy()s" * 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: x86/mm: Fix vmalloc_fault() to handle large pages properly hpet: Drop stale URLs x86/uaccess/64: Handle the caching of 4-byte nocache copies properly in __copy_user_nocache() x86/uaccess/64: Make the __copy_user_nocache() assembly code more readable lib/ucs2_string: Correct ucs2 -> utf8 conversion efi: Add pstore variables to the deletion whitelist efi: Make efivarfs entries immutable by default efi: Make our variable validation list include the guid efi: Do variable name validation tests in utf8 efi: Use ucs2_as_utf8 in efivarfs instead of open coding a bad version lib/ucs2_string: Add ucs2 -> utf8 helper functions | 20 February 2016, 17:32:40 UTC |
06b74c6 | Linus Torvalds | 20 February 2016, 17:30:42 UTC | Merge branch 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull perf fixes from Ingo Molnar: "A handful of CPU hotplug related fixes" * 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: perf/core: Plug potential memory leak in CPU_UP_PREPARE perf/core: Remove the bogus and dangerous CPU_DOWN_FAILED hotplug state perf/core: Remove bogus UP_CANCELED hotplug state perf/x86/amd/uncore: Plug reference leak | 20 February 2016, 17:30:42 UTC |
e6a1c1e | Linus Torvalds | 20 February 2016, 17:22:11 UTC | Merge tag 'powerpc-4.5-3' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux Pull powerpc fixes from Michael Ellerman: - Fix build error on 32-bit with checkpoint restart from Aneesh Kumar - Fix dedotify for binutils >= 2.26 from Andreas Schwab - Don't trace hcalls on offline CPUs from Denis Kirjanov - eeh: Fix stale cached primary bus from Gavin Shan - eeh: Fix stale PE primary bus from Gavin Shan - mm: Fix Multi hit ERAT cause by recent THP update from Aneesh Kumar K.V - ioda: Set "read" permission when "write" is set from Alexey Kardashevskiy * tag 'powerpc-4.5-3' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux: powerpc/ioda: Set "read" permission when "write" is set powerpc/mm: Fix Multi hit ERAT cause by recent THP update powerpc/powernv: Fix stale PE primary bus powerpc/eeh: Fix stale cached primary bus powerpc/pseries: Don't trace hcalls on offline CPUs powerpc: Fix dedotify for binutils >= 2.26 powerpc/book3s_32: Fix build error with checkpoint restart | 20 February 2016, 17:22:11 UTC |
da6b736 | Linus Torvalds | 20 February 2016, 17:19:56 UTC | Merge tag 'dmaengine-fix-4.5-rc5' of git://git.infradead.org/users/vkoul/slave-dma Pull dmaengine fixes from Vinod Koul: "A few fixes for drivers, nothing major here. Fixes are: iotdma fix to restart channels, new ID for wildcat PCH, residue fix for edma, disable irq for non-cyclic in dw" * tag 'dmaengine-fix-4.5-rc5' of git://git.infradead.org/users/vkoul/slave-dma: dmaengine: dw: disable BLOCK IRQs for non-cyclic xfer dmaengine: edma: fix residue race for cyclic dmaengine: dw: pci: add ID for WildcatPoint PCH dmaengine: IOATDMA: fix timer code that continues to restart channels during idle | 20 February 2016, 17:19:56 UTC |
37aa4da | Linus Torvalds | 20 February 2016, 17:16:51 UTC | Merge tag 'clk-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux Pull clk driver fixes from Stephen Boyd: "An assortment of vendor specific clk drivers fixes, most notably fallout from adding Tegra210 and rockchip rk3036/rk3368 drivers this cycle. There's also the random smattering of sparse/checker fixes, a build "fix" to get the Tango clk driver to compile because the Kconfig symbol was renamed after the fact, and a clk gpio fix for a patch mismerge" * tag 'clk-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux: (28 commits) clk: gpio: Really allow an optional clock= DT property Revert "clk: qcom: Specify LE device endianness" clk: versatile: mask VCO bits before writing clk: tegra: super: Fix sparse warnings for functions not declared as static clk: tegra: Fix sparse warnings for functions not declared as static clk: tegra: Fix sparse warning for pll_m clk: tegra: Use definition for pll_u override bit clk: tegra: Fix warning caused by pll_u failing to lock clk: tegra: Fix clock sources for Tegra210 EMC clk: tegra: Add the APB2APE audio clock on Tegra210 clk: tegra: Add missing of_node_put() clk: tegra: Fix PLLE SS coefficients clk: tegra: Fix typos around clearing PLLE bits during enable clk: tegra: Do not disable PLLE when under hardware control clk: tegra: Fix pllx dyn step calculation clk: tegra: pll: Fix potential sleeping-while-atomic clk: tegra: Fix the misnaming of nvenc from msenc clk: tegra: Fix naming of MISC registers clk: tango4: rename ARCH_TANGOX to ARCH_TANGO clk: scpi: Fix checking return value of platform_device_register_simple() ... | 20 February 2016, 17:16:51 UTC |
a703f42 | Linus Torvalds | 20 February 2016, 17:13:18 UTC | Merge branch 'drm-fixes' of git://people.freedesktop.org/~airlied/linux Pull more drm fixes from Dave Airlie: "Some more fixes trickled in: A bunch of VC4 ones since it's a pretty new driver not much chance of regressions, and it fixes GPU resets. Also one atomic fix, one set of fixes for a common bug in TTM cleanup, and one i915 hotplug fix" * 'drm-fixes' of git://people.freedesktop.org/~airlied/linux: drm/nouveau: use post-decrement in error handling drm/atomic: Allow for holes in connector state, v2. drm/i915: Fix hpd live status bits for g4x drm/vc4: Use runtime PM to power cycle the device when the GPU hangs. drm/vc4: Enable runtime PM. drm/vc4: Fix spurious GPU resets due to BO reuse. drm/vc4: Drop error message on seqno wait timeouts. drm/vc4: Fix -ERESTARTSYS error return from BO waits. drm/vc4: Return an ERR_PTR from BO creation instead of NULL. drm/vc4: Fix the clear color for the first tile rendered. drm/vc4: Validate that WAIT_BO padding is cleared. drm/radeon: use post-decrement in error handling drm/amdgpu: use post-decrement in error handling | 20 February 2016, 17:13:18 UTC |
59ceeaa | Simon Guinot | 09 September 2015, 22:15:18 UTC | kernel/resource.c: fix muxed resource handling in __request_region() In __request_region, if a conflict with a BUSY and MUXED resource is detected, then the caller goes to sleep and waits for the resource to be released. A pointer on the conflicting resource is kept. At wake-up this pointer is used as a parent to retry to request the region. A first problem is that this pointer might well be invalid (if for example the conflicting resource have already been freed). Another problem is that the next call to __request_region() fails to detect a remaining conflict. The previously conflicting resource is passed as a parameter and __request_region() will look for a conflict among the children of this resource and not at the resource itself. It is likely to succeed anyway, even if there is still a conflict. Instead, the parent of the conflicting resource should be passed to __request_region(). As a fix, this patch doesn't update the parent resource pointer in the case we have to wait for a muxed region right after. Reported-and-tested-by: Vincent Pelletier <plr.vincent@gmail.com> Signed-off-by: Simon Guinot <simon.guinot@sequanux.org> Tested-by: Vincent Donnefort <vdonnefort@gmail.com> Cc: stable@kernel.org Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> | 20 February 2016, 16:57:52 UTC |
020ecbb | Linus Torvalds | 19 February 2016, 21:44:12 UTC | Merge tag 'ext4_for_linus_stable' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4 Pull ext4 bugfixes from Ted Ts'o: "Miscellaneous ext4 bug fixes for v4.5" * tag 'ext4_for_linus_stable' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4: ext4: fix crashes in dioread_nolock mode ext4: fix bh->b_state corruption ext4: fix memleak in ext4_readdir() ext4: remove unused parameter "newblock" in convert_initialized_extent() ext4: don't read blocks from disk after extents being swapped ext4: fix potential integer overflow ext4: add a line break for proc mb_groups display ext4: ioctl: fix erroneous return value ext4: fix scheduling in atomic on group checksum failure ext4 crypto: move context consistency check to ext4_file_open() ext4 crypto: revalidate dentry after adding or removing the key | 19 February 2016, 21:44:12 UTC |
ce6b714 | Linus Torvalds | 19 February 2016, 21:40:42 UTC | Merge branch 'for-linus-4.5' of git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs Pull btrfs fix from Chris Mason: "My for-linus-4.5 branch has a btrfs DIO error passing fix. I know how much you love DIO, so I'm going to suggest against reading it. We'll follow up with a patch to drop the error arg from dio_end_io in the next merge window." * 'for-linus-4.5' of git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs: Btrfs: fix direct IO requests not reporting IO error to user space | 19 February 2016, 21:40:42 UTC |
87d9ac7 | Linus Torvalds | 19 February 2016, 21:36:00 UTC | Merge branch 'akpm' (patches from Andrew) Merge fixes from Andrew Morton: "10 fixes" * emailed patches from Andrew Morton <akpm@linux-foundation.org>: mm: slab: free kmem_cache_node after destroy sysfs file ipc/shm: handle removed segments gracefully in shm_mmap() MAINTAINERS: update Kselftest Framework mailing list devm_memremap_release(): fix memremap'd addr handling mm/hugetlb.c: fix incorrect proc nr_hugepages value mm, x86: fix pte_page() crash in gup_pte_range() fsnotify: turn fsnotify reaper thread into a workqueue job Revert "fsnotify: destroy marks with call_srcu instead of dedicated thread" mm: fix regression in remap_file_pages() emulation thp, dax: do not try to withdraw pgtable from non-anon VMA | 19 February 2016, 21:36:00 UTC |
23300f6 | Linus Torvalds | 19 February 2016, 16:40:05 UTC | Merge tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux Pull arm64 fixes from Will Deacon: "Here are some more arm64 fixes for 4.5. This has mostly come from Yang Shi, who saw some issues under -rt that also affect mainline. The rest of it is pretty small, but still worth having. We've got an old issue outstanding with valid_user_regs which will likely wait until 4.6 (since it would really benefit from some time in -next) and another issue with kasan and idle which should be fixed next week. Apart from that, pretty quiet here (and still no sign of the THP issue reported on s390...) Summary: - Allow EFI stub to use strnlen(), which is required by recent libfdt - Avoid smp_processor_id() in preempt context during unwinding - Avoid false Kasan warnings during unwinding - Ensure early devices are picked up by the IOMMU DMA ops - Avoid rebuilding the kernel for the 'install' target - Run fixup handlers for alignment faults on userspace access" * tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux: arm64: mm: allow the kernel to handle alignment faults on user accesses arm64: kbuild: make "make install" not depend on vmlinux arm64: dma-mapping: fix handling of devices registered before arch_initcall arm64/efi: Make strnlen() available to the EFI namespace arm/arm64: crypto: assure that ECB modes don't require an IV arm64: make irq_stack_ptr more robust arm64: debug: re-enable irqs before sending breakpoint SIGTRAP arm64: disable kasan when accessing frame->fp in unwind_frame | 19 February 2016, 16:40:05 UTC |
ff5f168 | Linus Torvalds | 19 February 2016, 16:33:12 UTC | Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux Pull s390 fixes from Martin Schwidefsky: "Several bug fixes: - There are four different stack tracers, and three of them have bugs. For 4.5 the bugs are fixed and we prepare a cleanup patch for the next merge window. - Three bug fixes for the dasd driver in regard to parallel access volumes and the new max_dev_sectors block device queue limit - The irq restore optimization needs a fixup for memcpy_real - The diagnose trace code has a conflict with lockdep" * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux: s390/dasd: fix performance drop s390/maccess: reduce stnsm instructions s390/diag: avoid lockdep recursion s390/dasd: fix refcount for PAV reassignment s390/dasd: prevent incorrect length error under z/VM after PAV changes s390: fix DAT off memory access, e.g. on kdump s390/oprofile: fix address range for asynchronous stack s390/perf_event: fix address range for asynchronous stack s390/stacktrace: add save_stack_trace_regs() s390/stacktrace: save full stack traces s390/stacktrace: add missing end marker s390/stacktrace: fix address ranges for asynchronous and panic stack s390/stacktrace: fix save_stack_trace_tsk() for current task | 19 February 2016, 16:33:12 UTC |
409ee13 | Linus Torvalds | 19 February 2016, 16:25:40 UTC | Merge tag 'pinctrl-v4.5-2' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl Pull Pin control fixes from Linus Walleij: "Pin control fixes for the v4.5 series, all are individual driver fixes: - Fix the PXA2xx driver to export its init function so we do not break modular compiles. - Hide unused functions in the Nomadik driver. - Fix up direction control in the Mediatek driver. - Toggle the sunxi GPIO lines to input when you read them on the H3 GPIO controller, lest you only get garbage. - Fix up the number of settings in the MVEBU driver. - Fix a serious SMP race condition in the Samsung driver" * tag 'pinctrl-v4.5-2' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl: pinctrl: samsung: fix SMP race condition pinctrl: mvebu: fix num_settings in mpp group assignment pinctrl: sunxi: H3 requires irq_read_needs_mux pinctrl: mediatek: fix direction control issue pinctrl: nomadik: hide unused functions pinctrl: pxa: export pxa2xx_pinctrl_init() | 19 February 2016, 16:25:40 UTC |
9001b8e | Linus Torvalds | 19 February 2016, 16:01:41 UTC | Merge tag 'sound-4.5-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound Pull sound fixes from Takashi Iwai: "This update contains again a few more fixes for ALSA core stuff although it's no longer high flux: two race fixes in sequencer and one PCM race fix for non-atomic PCM ops. In addition, HD-audio gained a similar fix for race at reloading the driver" * tag 'sound-4.5-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound: ALSA: pcm: Fix rwsem deadlock for non-atomic PCM stream ALSA: seq: Fix double port list deletion ALSA: hda - Cancel probe work instead of flush at remove ALSA: seq: Fix leak of pool buffer at concurrent writes | 19 February 2016, 16:01:41 UTC |
52d7523 | EunTaik Lee | 16 February 2016, 04:44:35 UTC | arm64: mm: allow the kernel to handle alignment faults on user accesses Although we don't expect to take alignment faults on access to normal memory, misbehaving (i.e. buggy) user code can pass MMIO pointers into system calls, leading to things like get_user accessing device memory. Rather than OOPS the kernel, allow any exception fixups to run and return something like -EFAULT back to userspace. This makes the behaviour more consistent with userspace, even though applications with access to device mappings can easily cause other issues if they try hard enough. Acked-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Eun Taik Lee <eun.taik.lee@samsung.com> [will: dropped __kprobes annotation and rewrote commit mesage] Signed-off-by: Will Deacon <will.deacon@arm.com> | 19 February 2016, 12:20:37 UTC |
8684fa3 | Masahiro Yamada | 19 February 2016, 06:05:50 UTC | arm64: kbuild: make "make install" not depend on vmlinux For the same reason as commit 19514fc665ff ("arm, kbuild: make "make install" not depend on vmlinux"), the install targets should never trigger the rebuild of the kernel. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Will Deacon <will.deacon@arm.com> | 19 February 2016, 10:33:35 UTC |
74dae42 | Jan Kara | 19 February 2016, 05:33:21 UTC | ext4: fix crashes in dioread_nolock mode Competing overwrite DIO in dioread_nolock mode will just overwrite pointer to io_end in the inode. This may result in data corruption or extent conversion happening from IO completion interrupt because we don't properly set buffer_defer_completion() when unlocked DIO races with locked DIO to unwritten extent. Since unlocked DIO doesn't need io_end for anything, just avoid allocating it and corrupting pointer from inode for locked DIO. A cleaner fix would be to avoid these games with io_end pointer from the inode but that requires more intrusive changes so we leave that for later. Cc: stable@vger.kernel.org Signed-off-by: Jan Kara <jack@suse.cz> Signed-off-by: Theodore Ts'o <tytso@mit.edu> | 19 February 2016, 05:33:21 UTC |
ed8ad83 | Jan Kara | 19 February 2016, 05:18:25 UTC | ext4: fix bh->b_state corruption ext4 can update bh->b_state non-atomically in _ext4_get_block() and ext4_da_get_block_prep(). Usually this is fine since bh is just a temporary storage for mapping information on stack but in some cases it can be fully living bh attached to a page. In such case non-atomic update of bh->b_state can race with an atomic update which then gets lost. Usually when we are mapping bh and thus updating bh->b_state non-atomically, nobody else touches the bh and so things work out fine but there is one case to especially worry about: ext4_finish_bio() uses BH_Uptodate_Lock on the first bh in the page to synchronize handling of PageWriteback state. So when blocksize < pagesize, we can be atomically modifying bh->b_state of a buffer that actually isn't under IO and thus can race e.g. with delalloc trying to map that buffer. The result is that we can mistakenly set / clear BH_Uptodate_Lock bit resulting in the corruption of PageWriteback state or missed unlock of BH_Uptodate_Lock. Fix the problem by always updating bh->b_state bits atomically. CC: stable@vger.kernel.org Reported-by: Nikolay Borisov <kernel@kyup.com> Signed-off-by: Jan Kara <jack@suse.cz> Signed-off-by: Theodore Ts'o <tytso@mit.edu> | 19 February 2016, 05:18:25 UTC |
4fbbed4 | Rasmus Villemoes | 15 February 2016, 18:41:46 UTC | drm/nouveau: use post-decrement in error handling We need to use post-decrement to get the dma_map_page undone also for i==0, and to avoid some very unpleasant behaviour if dma_map_page failed already at i==0. Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk> Reviewed-by: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com> | 19 February 2016, 03:36:05 UTC |
5fff80b | Maarten Lankhorst | 17 February 2016, 07:32:05 UTC | drm/atomic: Allow for holes in connector state, v2. Because we record connector_mask using 1 << drm_connector_index now the connector_mask should stay the same even when other connectors are removed. This was not the case with MST, in that case when removing a connector all other connectors may change their index. This is fixed by waiting until the first get_connector_state to allocate connector_state, and force reallocation when state is too small. As a side effect connector arrays no longer have to be preallocated, and can be allocated on first use which means a less allocations in the page flip only path. Changes since v1: - Whitespace. (Ville) - Call ida_remove when destroying the connector. (Ville) - u32 alloc -> int. (Ville) Fixes: 14de6c44d149 ("drm/atomic: Remove drm_atomic_connectors_for_crtc.") Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Lyude <cpaul@redhat.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Dave Airlie <airlied@redhat.com> | 19 February 2016, 03:24:03 UTC |
4462b4b | Stephen Boyd | 19 February 2016, 03:07:44 UTC | clk: gpio: Really allow an optional clock= DT property We mis-merged the original patch from Russell here and so the patch went almost all the way, except that we still failed to probe when there wasn't a clocks property in the DT node. Allow that case by making a negative value from of_clk_get_parent_count() into "no parents", like the original patch did. Fixes: 7ed88aa2efa5 ("clk: fix clk-gpio.c with optional clock= DT property") Cc: Russell King <rmk+kernel@arm.linux.org.uk> Cc: Michael Turquette <mturquette@baylibre.com> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org> | 19 February 2016, 03:10:22 UTC |
5441ea1 | Dave Airlie | 19 February 2016, 02:50:00 UTC | Merge tag 'drm-vc4-fixes-2016-02-17' of github.com:anholt/linux into drm-fixes This pull request fixes GPU reset (which was disabled shortly after V3D integration due to build breakage) and waits for idle in the presence of signals (which X likes to do a lot). * tag 'drm-vc4-fixes-2016-02-17' of github.com:anholt/linux: drm/vc4: Use runtime PM to power cycle the device when the GPU hangs. drm/vc4: Enable runtime PM. drm/vc4: Fix spurious GPU resets due to BO reuse. drm/vc4: Drop error message on seqno wait timeouts. drm/vc4: Fix -ERESTARTSYS error return from BO waits. drm/vc4: Return an ERR_PTR from BO creation instead of NULL. drm/vc4: Fix the clear color for the first tile rendered. drm/vc4: Validate that WAIT_BO padding is cleared. | 19 February 2016, 02:50:00 UTC |
aaa7dd2 | Dave Airlie | 19 February 2016, 02:49:03 UTC | Merge branch 'drm-fixes-4.5' of git://people.freedesktop.org/~agd5f/linux into drm-fixes Just two small fixes in the ttm_tt_populate error handling; one for radeon, one for amdgpu. * 'drm-fixes-4.5' of git://people.freedesktop.org/~agd5f/linux: drm/radeon: use post-decrement in error handling drm/amdgpu: use post-decrement in error handling | 19 February 2016, 02:49:03 UTC |
42412b1 | Dave Airlie | 19 February 2016, 02:43:03 UTC | Merge tag 'drm-intel-fixes-2016-02-18' of git://anongit.freedesktop.org/drm-intel into drm-fixes single g4x hpd fix. * tag 'drm-intel-fixes-2016-02-18' of git://anongit.freedesktop.org/drm-intel: drm/i915: Fix hpd live status bits for g4x | 19 February 2016, 02:43:03 UTC |
705d43d | Linus Torvalds | 19 February 2016, 00:34:15 UTC | Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/livepatching Pull livepatching fixes from Jiri Kosina: - regression (from 4.4) fix for ordering issue, introduced by an earlier ftrace change, that broke live patching of modules. The fix replaces the ftrace module notifier by direct call in order to make the ordering guaranteed and well-defined. The patch, from Jessica Yu, has been acked both by Steven and Rusty - error message fix from Miroslav Benes * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/livepatching: ftrace/module: remove ftrace module notifier livepatch: change the error message in asm/livepatch.h header files | 19 February 2016, 00:34:15 UTC |
dd8fc10 | Linus Torvalds | 19 February 2016, 00:24:48 UTC | Merge tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi Pull SCSI fixes from James Bottomley: "Two simple fixes. One prevents a soft lockup on some target removal scenarios and the other prevents us trying to probe the marvell console device, which causes it to time out and need the bus resetting" * tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi: scsi: fix soft lockup in scsi_remove_target() on module removal SCSI: Add Marvell configuration device to VPD blacklist | 19 February 2016, 00:24:48 UTC |
52b4b95 | Dmitry Safonov | 17 February 2016, 21:11:37 UTC | mm: slab: free kmem_cache_node after destroy sysfs file When slub_debug alloc_calls_show is enabled we will try to track location and user of slab object on each online node, kmem_cache_node structure and cpu_cache/cpu_slub shouldn't be freed till there is the last reference to sysfs file. This fixes the following panic: BUG: unable to handle kernel NULL pointer dereference at 0000000000000020 IP: list_locations+0x169/0x4e0 PGD 257304067 PUD 438456067 PMD 0 Oops: 0000 [#1] SMP CPU: 3 PID: 973074 Comm: cat ve: 0 Not tainted 3.10.0-229.7.2.ovz.9.30-00007-japdoll-dirty #2 9.30 Hardware name: DEPO Computers To Be Filled By O.E.M./H67DE3, BIOS L1.60c 07/14/2011 task: ffff88042a5dc5b0 ti: ffff88037f8d8000 task.ti: ffff88037f8d8000 RIP: list_locations+0x169/0x4e0 Call Trace: alloc_calls_show+0x1d/0x30 slab_attr_show+0x1b/0x30 sysfs_read_file+0x9a/0x1a0 vfs_read+0x9c/0x170 SyS_read+0x58/0xb0 system_call_fastpath+0x16/0x1b Code: 5e 07 12 00 b9 00 04 00 00 3d 00 04 00 00 0f 4f c1 3d 00 04 00 00 89 45 b0 0f 84 c3 00 00 00 48 63 45 b0 49 8b 9c c4 f8 00 00 00 <48> 8b 43 20 48 85 c0 74 b6 48 89 df e8 46 37 44 00 48 8b 53 10 CR2: 0000000000000020 Separated __kmem_cache_release from __kmem_cache_shutdown which now called on slab_kmem_cache_release (after the last reference to sysfs file object has dropped). Reintroduced locking in free_partial as sysfs file might access cache's partial list after shutdowning - partial revert of the commit 69cb8e6b7c29 ("slub: free slabs without holding locks"). Zap __remove_partial and use remove_partial (w/o underscores) as free_partial now takes list_lock which s partial revert for commit 1e4dd9461fab ("slub: do not assert not having lock in removing freed partial") Signed-off-by: Dmitry Safonov <dsafonov@virtuozzo.com> Suggested-by: Vladimir Davydov <vdavydov@virtuozzo.com> Acked-by: Vladimir Davydov <vdavydov@virtuozzo.com> Cc: Christoph Lameter <cl@linux.com> Cc: Pekka Enberg <penberg@kernel.org> Cc: David Rientjes <rientjes@google.com> Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> | 19 February 2016, 00:23:24 UTC |
1ac0b6d | Kirill A. Shutemov | 17 February 2016, 21:11:35 UTC | ipc/shm: handle removed segments gracefully in shm_mmap() remap_file_pages(2) emulation can reach file which represents removed IPC ID as long as a memory segment is mapped. It breaks expectations of IPC subsystem. Test case (rewritten to be more human readable, originally autogenerated by syzkaller[1]): #define _GNU_SOURCE #include <stdlib.h> #include <sys/ipc.h> #include <sys/mman.h> #include <sys/shm.h> #define PAGE_SIZE 4096 int main() { int id; void *p; id = shmget(IPC_PRIVATE, 3 * PAGE_SIZE, 0); p = shmat(id, NULL, 0); shmctl(id, IPC_RMID, NULL); remap_file_pages(p, 3 * PAGE_SIZE, 0, 7, 0); return 0; } The patch changes shm_mmap() and code around shm_lock() to propagate locking error back to caller of shm_mmap(). [1] http://github.com/google/syzkaller Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Reported-by: Dmitry Vyukov <dvyukov@google.com> Cc: Davidlohr Bueso <dave@stgolabs.net> Cc: Manfred Spraul <manfred@colorfullife.com> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> | 19 February 2016, 00:23:24 UTC |
64f0085 | Shuah Khan | 17 February 2016, 21:11:32 UTC | MAINTAINERS: update Kselftest Framework mailing list Kselftest Framework now has a dedicated mailing list linux-kselftest. Update the entry in MAINTAINERS file. Signed-off-by: Shuah Khan <shuahkh@osg.samsung.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> | 19 February 2016, 00:23:24 UTC |
9273a8b | Toshi Kani | 17 February 2016, 21:11:29 UTC | devm_memremap_release(): fix memremap'd addr handling The pmem driver calls devm_memremap() to map a persistent memory range. When the pmem driver is unloaded, this memremap'd range is not released so the kernel will leak a vma. Fix devm_memremap_release() to handle a given memremap'd address properly. Signed-off-by: Toshi Kani <toshi.kani@hpe.com> Acked-by: Dan Williams <dan.j.williams@intel.com> Cc: Christoph Hellwig <hch@lst.de> Cc: Ross Zwisler <ross.zwisler@linux.intel.com> Cc: Matthew Wilcox <willy@linux.intel.com> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> | 19 February 2016, 00:23:24 UTC |
f8b7481 | Vaishali Thakkar | 17 February 2016, 21:11:26 UTC | mm/hugetlb.c: fix incorrect proc nr_hugepages value Currently incorrect default hugepage pool size is reported by proc nr_hugepages when number of pages for the default huge page size is specified twice. When multiple huge page sizes are supported, /proc/sys/vm/nr_hugepages indicates the current number of pre-allocated huge pages of the default size. Basically /proc/sys/vm/nr_hugepages displays default_hstate-> max_huge_pages and after boot time pre-allocation, max_huge_pages should equal the number of pre-allocated pages (nr_hugepages). Test case: Note that this is specific to x86 architecture. Boot the kernel with command line option 'default_hugepagesz=1G hugepages=X hugepagesz=2M hugepages=Y hugepagesz=1G hugepages=Z'. After boot, 'cat /proc/sys/vm/nr_hugepages' and 'sysctl -a | grep hugepages' returns the value X. However, dmesg output shows that Z huge pages were pre-allocated. So, the root cause of the problem here is that the global variable default_hstate_max_huge_pages is set if a default huge page size is specified (directly or indirectly) on the command line. After the command line processing in hugetlb_init, if default_hstate_max_huge_pages is set, the value is assigned to default_hstae.max_huge_pages. However, default_hstate.max_huge_pages may have already been set based on the number of pre-allocated huge pages of default_hstate size. The solution to this problem is if hstate->max_huge_pages is already set then it should not set as a result of global max_huge_pages value. Basically if the value of the variable hugepages is set multiple times on a command line for a specific supported hugepagesize then proc layer should consider the last specified value. Signed-off-by: Vaishali Thakkar <vaishali.thakkar@oracle.com> Reviewed-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com> Cc: Mike Kravetz <mike.kravetz@oracle.com> Cc: Hillf Danton <hillf.zj@alibaba-inc.com> Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Cc: Dave Hansen <dave.hansen@linux.intel.com> Cc: Paul Gortmaker <paul.gortmaker@windriver.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> | 19 February 2016, 00:23:24 UTC |
457a98b | Hugh Dickins | 17 February 2016, 21:11:23 UTC | mm, x86: fix pte_page() crash in gup_pte_range() Commit 3565fce3a659 ("mm, x86: get_user_pages() for dax mappings") has moved up the pte_page(pte) in x86's fast gup_pte_range(), for no discernible reason: put it back where it belongs, after the pte_flags check and the pfn_valid cross-check. That may be the cause of the NULL pointer dereference in gup_pte_range(), seen when vfio called vaddr_get_pfn() when starting a qemu-kvm based VM. Signed-off-by: Hugh Dickins <hughd@google.com> Reported-by: Michael Long <Harn-Solo@gmx.de> Tested-by: Michael Long <Harn-Solo@gmx.de> Acked-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> | 19 February 2016, 00:23:24 UTC |
0918f1c | Jeff Layton | 17 February 2016, 21:11:21 UTC | fsnotify: turn fsnotify reaper thread into a workqueue job We don't require a dedicated thread for fsnotify cleanup. Switch it over to a workqueue job instead that runs on the system_unbound_wq. In the interest of not thrashing the queued job too often when there are a lot of marks being removed, we delay the reaper job slightly when queueing it, to allow several to gather on the list. Signed-off-by: Jeff Layton <jeff.layton@primarydata.com> Tested-by: Eryu Guan <guaneryu@gmail.com> Reviewed-by: Jan Kara <jack@suse.cz> Cc: Eric Paris <eparis@parisplace.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> | 19 February 2016, 00:23:24 UTC |
13d34ac | Jeff Layton | 17 February 2016, 21:11:18 UTC | Revert "fsnotify: destroy marks with call_srcu instead of dedicated thread" This reverts commit c510eff6beba ("fsnotify: destroy marks with call_srcu instead of dedicated thread"). Eryu reported that he was seeing some OOM kills kick in when running a testcase that adds and removes inotify marks on a file in a tight loop. The above commit changed the code to use call_srcu to clean up the marks. While that does (in principle) work, the srcu callback job is limited to cleaning up entries in small batches and only once per jiffy. It's easily possible to overwhelm that machinery with too many call_srcu callbacks, and Eryu's reproduer did just that. There's also another potential problem with using call_srcu here. While you can obviously sleep while holding the srcu_read_lock, the callbacks run under local_bh_disable, so you can't sleep there. It's possible when putting the last reference to the fsnotify_mark that we'll end up putting a chain of references including the fsnotify_group, uid, and associated keys. While I don't see any obvious ways that that could occurs, it's probably still best to avoid using call_srcu here after all. This patch reverts the above patch. A later patch will take a different approach to eliminated the dedicated thread here. Signed-off-by: Jeff Layton <jeff.layton@primarydata.com> Reported-by: Eryu Guan <guaneryu@gmail.com> Tested-by: Eryu Guan <guaneryu@gmail.com> Cc: Jan Kara <jack@suse.com> Cc: Eric Paris <eparis@parisplace.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> | 19 February 2016, 00:23:24 UTC |
48f7df3 | Kirill A. Shutemov | 17 February 2016, 21:11:15 UTC | mm: fix regression in remap_file_pages() emulation Grazvydas Ignotas has reported a regression in remap_file_pages() emulation. Testcase: #define _GNU_SOURCE #include <assert.h> #include <stdlib.h> #include <stdio.h> #include <sys/mman.h> #define SIZE (4096 * 3) int main(int argc, char **argv) { unsigned long *p; long i; p = mmap(NULL, SIZE, PROT_READ | PROT_WRITE, MAP_SHARED | MAP_ANONYMOUS, -1, 0); if (p == MAP_FAILED) { perror("mmap"); return -1; } for (i = 0; i < SIZE / 4096; i++) p[i * 4096 / sizeof(*p)] = i; if (remap_file_pages(p, 4096, 0, 1, 0)) { perror("remap_file_pages"); return -1; } if (remap_file_pages(p, 4096 * 2, 0, 1, 0)) { perror("remap_file_pages"); return -1; } assert(p[0] == 1); munmap(p, SIZE); return 0; } The second remap_file_pages() fails with -EINVAL. The reason is that remap_file_pages() emulation assumes that the target vma covers whole area we want to over map. That assumption is broken by first remap_file_pages() call: it split the area into two vma. The solution is to check next adjacent vmas, if they map the same file with the same flags. Fixes: c8d78c1823f4 ("mm: replace remap_file_pages() syscall with emulation") Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Reported-by: Grazvydas Ignotas <notasas@gmail.com> Tested-by: Grazvydas Ignotas <notasas@gmail.com> Cc: <stable@vger.kernel.org> [4.0+] Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> | 19 February 2016, 00:23:24 UTC |
69a8ec2 | Kirill A. Shutemov | 17 February 2016, 21:11:12 UTC | thp, dax: do not try to withdraw pgtable from non-anon VMA DAX doesn't deposit pgtables when it maps huge pages: nothing to withdraw. It can lead to crash. Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Cc: Dan Williams <dan.j.williams@intel.com> Cc: Matthew Wilcox <willy@linux.intel.com> Cc: Andrea Arcangeli <aarcange@redhat.com> Cc: Ross Zwisler <ross.zwisler@linux.intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> | 19 February 2016, 00:23:24 UTC |
67ec107 | Takashi Iwai | 17 February 2016, 13:30:26 UTC | ALSA: pcm: Fix rwsem deadlock for non-atomic PCM stream A non-atomic PCM stream may take snd_pcm_link_rwsem rw semaphore twice in the same code path, e.g. one in snd_pcm_action_nonatomic() and another in snd_pcm_stream_lock(). Usually this is OK, but when a write lock is issued between these two read locks, the problem happens: the write lock is blocked due to the first reade lock, and the second read lock is also blocked by the write lock. This eventually deadlocks. The reason is the way rwsem manages waiters; it's queued like FIFO, so even if the writer itself doesn't take the lock yet, it blocks all the waiters (including reads) queued after it. As a workaround, in this patch, we replace the standard down_write() with an spinning loop. This is far from optimal, but it's good enough, as the spinning time is supposed to be relatively short for normal PCM operations, and the code paths requiring the write lock aren't called so often. Reported-by: Vinod Koul <vinod.koul@intel.com> Tested-by: Ramesh Babu <ramesh.babu@intel.com> Cc: <stable@vger.kernel.org> # v3.18+ Signed-off-by: Takashi Iwai <tiwai@suse.de> | 18 February 2016, 10:27:52 UTC |
f4eafd8 | Toshi Kani | 18 February 2016, 01:16:54 UTC | x86/mm: Fix vmalloc_fault() to handle large pages properly A kernel page fault oops with the callstack below was observed when a read syscall was made to a pmem device after a huge amount (>512GB) of vmalloc ranges was allocated by ioremap() on a x86_64 system: BUG: unable to handle kernel paging request at ffff880840000ff8 IP: vmalloc_fault+0x1be/0x300 PGD c7f03a067 PUD 0 Oops: 0000 [#1] SM Call Trace: __do_page_fault+0x285/0x3e0 do_page_fault+0x2f/0x80 ? put_prev_entity+0x35/0x7a0 page_fault+0x28/0x30 ? memcpy_erms+0x6/0x10 ? schedule+0x35/0x80 ? pmem_rw_bytes+0x6a/0x190 [nd_pmem] ? schedule_timeout+0x183/0x240 btt_log_read+0x63/0x140 [nd_btt] : ? __symbol_put+0x60/0x60 ? kernel_read+0x50/0x80 SyS_finit_module+0xb9/0xf0 entry_SYSCALL_64_fastpath+0x1a/0xa4 Since v4.1, ioremap() supports large page (pud/pmd) mappings in x86_64 and PAE. vmalloc_fault() however assumes that the vmalloc range is limited to pte mappings. vmalloc faults do not normally happen in ioremap'd ranges since ioremap() sets up the kernel page tables, which are shared by user processes. pgd_ctor() sets the kernel's PGD entries to user's during fork(). When allocation of the vmalloc ranges crosses a 512GB boundary, ioremap() allocates a new pud table and updates the kernel PGD entry to point it. If user process's PGD entry does not have this update yet, a read/write syscall to the range will cause a vmalloc fault, which hits the Oops above as it does not handle a large page properly. Following changes are made to vmalloc_fault(). 64-bit: - No change for the PGD sync operation as it handles large pages already. - Add pud_huge() and pmd_huge() to the validation code to handle large pages. - Change pud_page_vaddr() to pud_pfn() since an ioremap range is not directly mapped (while the if-statement still works with a bogus addr). - Change pmd_page() to pmd_pfn() since an ioremap range is not backed by struct page (while the if-statement still works with a bogus addr). 32-bit: - No change for the sync operation since the index3 PGD entry covers the entire vmalloc range, which is always valid. (A separate change to sync PGD entry is necessary if this memory layout is changed regardless of the page size.) - Add pmd_huge() to the validation code to handle large pages. This is for completeness since vmalloc_fault() won't happen in ioremap'd ranges as its PGD entry is always valid. Reported-by: Henning Schild <henning.schild@siemens.com> Signed-off-by: Toshi Kani <toshi.kani@hpe.com> Acked-by: Borislav Petkov <bp@alien8.de> Cc: <stable@vger.kernel.org> # 4.1+ Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Andy Lutomirski <luto@amacapital.net> Cc: Brian Gerst <brgerst@gmail.com> Cc: Denys Vlasenko <dvlasenk@redhat.com> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Luis R. Rodriguez <mcgrof@suse.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Toshi Kani <toshi.kani@hp.com> Cc: linux-mm@kvack.org Cc: linux-nvdimm@lists.01.org Link: http://lkml.kernel.org/r/1455758214-24623-1-git-send-email-toshi.kani@hpe.com Signed-off-by: Ingo Molnar <mingo@kernel.org> | 18 February 2016, 08:02:59 UTC |
7dcd182 | Jessica Yu | 16 February 2016, 22:32:33 UTC | ftrace/module: remove ftrace module notifier Remove the ftrace module notifier in favor of directly calling ftrace_module_enable() and ftrace_release_mod() in the module loader. Hard-coding the function calls directly in the module loader removes dependence on the module notifier call chain and provides better visibility and control over what gets called when, which is important to kernel utilities such as livepatch. This fixes a notifier ordering issue in which the ftrace module notifier (and hence ftrace_module_enable()) for coming modules was being called after klp_module_notify(), which caused livepatch modules to initialize incorrectly. This patch removes dependence on the module notifier call chain in favor of hard coding the corresponding function calls in the module loader. This ensures that ftrace and livepatch code get called in the correct order on patch module load and unload. Fixes: 5156dca34a3e ("ftrace: Fix the race between ftrace and insmod") Signed-off-by: Jessica Yu <jeyu@redhat.com> Reviewed-by: Steven Rostedt <rostedt@goodmis.org> Reviewed-by: Petr Mladek <pmladek@suse.cz> Acked-by: Rusty Russell <rusty@rustcorp.com.au> Reviewed-by: Josh Poimboeuf <jpoimboe@redhat.com> Reviewed-by: Miroslav Benes <mbenes@suse.cz> Signed-off-by: Jiri Kosina <jkosina@suse.cz> | 17 February 2016, 21:14:06 UTC |
2850713 | Linus Torvalds | 17 February 2016, 19:59:23 UTC | Merge branch 'for-linus' of git://git.kernel.dk/linux-block Pull block fixes from Jens Axboe: "A collection of fixes from the past few weeks that should go into 4.5. This contains: - Overflow fix for sysfs discard show function from Alan. - A stacking limit init fix for max_dev_sectors, so we don't end up artificially capping some use cases. From Keith. - Have blk-mq proper end unstarted requests on a dying queue, instead of pushing that to the driver. From Keith. - NVMe: - Update to Kconfig description for NVME_SCSI, since it was vague and having it on is important for some SUSE distros. From Christoph. - Set of fixes from Keith, around surprise removal. Also kills the no-merge flag, so it supports merging. - Set of fixes for lightnvm from Matias, Javier, and Wenwei. - Fix null_blk oops when asked for lightnvm, but not available. From Matias. - Copy-to-user EINTR fix from Hannes, fixing a case where SG_IO fails if interrupted by a signal. - Two floppy fixes from Jiri, fixing signal handling and blocking open. - A use-after-free fix for O_DIRECT, from Mike Krinkin. - A block module ref count fix from Roman Pen. - An fs IO wait accounting fix for O_DSYNC from Stephane Gasparini. - Smaller reallo fix for xen-blkfront from Bob Liu. - Removal of an unused struct member in the deadline IO scheduler, from Tahsin. - Also from Tahsin, properly initialize inode struct members associated with cgroup writeback, if enabled. - From Tejun, ensure that we keep the superblock pinned during cgroup writeback" * 'for-linus' of git://git.kernel.dk/linux-block: (25 commits) blk: fix overflow in queue_discard_max_hw_show writeback: initialize inode members that track writeback history writeback: keep superblock pinned during cgroup writeback association switches bio: return EINTR if copying to user space got interrupted NVMe: Rate limit nvme IO warnings NVMe: Poll device while still active during remove NVMe: Requeue requests on suspended queues NVMe: Allow request merges NVMe: Fix io incapable return values blk-mq: End unstarted requests on dying queue block: Initialize max_dev_sectors to 0 null_blk: oops when initializing without lightnvm block: fix module reference leak on put_disk() call for cgroups throttle nvme: fix Kconfig description for BLK_DEV_NVME_SCSI kernel/fs: fix I/O wait not accounted for RW O_DSYNC floppy: refactor open() flags handling lightnvm: allow to force mm initialization lightnvm: check overflow and correct mlc pairs lightnvm: fix request intersection locking in rrpc lightnvm: warn if irqs are disabled in lock laddr ... | 17 February 2016, 19:59:23 UTC |
c28b947 | Linus Torvalds | 17 February 2016, 19:50:53 UTC | Merge tag 'devicetree-fixes-for-4.5-2' of git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux Pull DeviceTree fixes from Rob Herring: - Fix irq msi-map calculation for nonzero rid-base. - Binding doc updates for GICv3, fsl-imx-uart, and S3C RTC. * tag 'devicetree-fixes-for-4.5-2' of git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux: rtc: s3c: Document required clocks in the DT binding serial: fsl-imx-uart: Fix typo in fsl,dte-mode description dt-bindings: arm, gic-v3: require that reserved cells are always 0 of/irq: Fix msi-map calculation for nonzero rid-base | 17 February 2016, 19:50:53 UTC |
35683dd | Linus Torvalds | 17 February 2016, 19:45:10 UTC | Merge branch 'drm-fixes' of git://people.freedesktop.org/~airlied/linux Pull drm fixes from Dave Airlie: "This has two main sets of fixes: - A bunch of Exynos fixes, mainly for their MIC component. - vblank regression fixes from Mario, apparantly some changes in 4.4 caused some vblank breakage on radeon/nouveau, this set fixes all the issues seen. There is also a revert of one of the MST changse, that I was overzealous in including, that broke 30" MST monitors, and two qxl fixes" * 'drm-fixes' of git://people.freedesktop.org/~airlied/linux: drm/qxl: fix erroneous return value drm/nouveau/display: Enable vblank irqs after display engine is on again. drm/radeon/pm: Handle failure of drm_vblank_get. drm: Fix treatment of drm_vblank_offdelay in drm_vblank_on() (v2) drm: Fix drm_vblank_pre/post_modeset regression from Linux 4.4 drm: Prevent vblank counter bumps > 1 with active vblank clients. (v2) drm: No-Op redundant calls to drm_vblank_off() (v2) drm/qxl: use kmalloc_array to alloc reloc_info in qxl_process_single_command Revert "drm/dp/mst: change MST detection scheme" drm/exynos/decon: fix disable clocks order drm/exynos: fix incorrect cpu address for dma_mmap_attrs() drm/exynos: exynos5433_decon: fix wrong state in decon_vblank_enable drm/exynos: exynos5433_decon: fix wrong state assignment in decon_enable drm/exynos: dsi: restore support for drm bridge drm/exynos: mic: make all functions static drm/exynos: mic: convert to component framework drm/exynos: mic: use devm_clk interface drm/exynos: fix types for compilation on 64bit architectures drm/exynos: ipp: fix incorrect format specifiers in debug messages drm/exynos: depend on ARCH_EXYNOS for DRM_EXYNOS | 17 February 2016, 19:45:10 UTC |
a9f70bd | Linus Torvalds | 17 February 2016, 19:35:41 UTC | Merge tag 'trace-fixes-v4.5-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace Pull tracing fixes from Steven Rostedt: "This includes two fixes. The first is something that has come up a few times and has been worked out individually, but it's come up now enough that the problem should be generic. Tracepoints are protected by RCU sched. There are several tracepoints within core infrastructure like kfree(). If a tracepoint is called when the CPU is going down, or when it's coming up but has yet to be recognized by RCU, a RCU warning is triggered. This is a true bug as that tracepoint is not protected by RCU. Usually, this is taken care of by testing for cpu online as a tracepoint condition. But as this is happening more often, moving it from a individual tracepoint to a check in the tracepoint infrastructure is more robust. Note, there is now a duplicate of a cpu online test, because this update does not remove the individual checks. But the overhead is small enough that the removal can be done in another release. The second change is strange linker breakage due to the branch tracer's builtin_constant_p() check failing, and treating the condition as a variable instead of a constant. Arnd Bergmann found that this can be fixed by testing !!(cond) instead of just (cond)" * tag 'trace-fixes-v4.5-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace: tracing: Fix freak link error caused by branch tracer tracepoints: Do not trace when cpu is offline | 17 February 2016, 19:35:41 UTC |
18f922d | Alan | 17 February 2016, 14:15:30 UTC | blk: fix overflow in queue_discard_max_hw_show We get this right for queue_discard_max_show but not max_hw_show. Follow the same pattern as queue_discard_max_show instead so that we don't truncate. Signed-off-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Jens Axboe <axboe@fb.com> | 17 February 2016, 17:20:42 UTC |
6ecad91 | Alexey Kardashevskiy | 17 February 2016, 07:26:31 UTC | powerpc/ioda: Set "read" permission when "write" is set Quite often drivers set only "write" permission assuming that this includes "read" permission as well and this works on plenty of platforms. However IODA2 is strict about this and produces an EEH when "read" permission is not set and reading happens. This adds a workaround in the IODA code to always add the "read" bit when the "write" bit is set. Fixes: 10b35b2b7485 ("powerpc/powernv: Do not set "read" flag if direction==DMA_NONE") Cc: stable@vger.kernel.org # 4.2+ Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru> Tested-by: Douglas Miller <dougmill@linux.vnet.ibm.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> | 17 February 2016, 12:52:17 UTC |
722ec35 | Marek Szyprowski | 16 February 2016, 14:14:44 UTC | arm64: dma-mapping: fix handling of devices registered before arch_initcall This patch ensures that devices, which got registered before arch_initcall will be handled correctly by IOMMU-based DMA-mapping code. Cc: <stable@vger.kernel.org> Fixes: 13b8629f6511 ("arm64: Add IOMMU dma_ops") Acked-by: Robin Murphy <robin.murphy@arm.com> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Will Deacon <will.deacon@arm.com> | 17 February 2016, 11:48:01 UTC |
8d409cb | Ville Syrjälä | 10 February 2016, 17:59:05 UTC | drm/i915: Fix hpd live status bits for g4x Looks like g4x hpd live status bits actually agree with the spec. At least they do on the machine I have, and apparently on Nick Bowler's g4x as well. So gm45 may be the only platform where they don't agree. At least that seems to be the case based on the (somewhat incomplete) logs/dumps in [1], and Daniel has also tested this on his gm45 sometime in the past. So let's change the bits to match the spec on g4x. That actually makes the g4x bits identical to vlv/chv so we can just share the code between those platforms, leaving gm45 as the special case. [1] https://bugzilla.kernel.org/show_bug.cgi?id=52361 Cc: Shashank Sharma <shashank.sharma@intel.com> Cc: Sonika Jindal <sonika.jindal@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Nick Bowler <nbowler@draconx.ca> References: https://lists.freedesktop.org/archives/dri-devel/2016-February/100382.html Reported-by: Nick Bowler <nbowler@draconx.ca> Cc: stable@vger.kernel.org Fixes: 237ed86c693d ("drm/i915: Check live status before reading edid") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1455127145-20087-1-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> (cherry picked from commit 0780cd36c7af70c55981ee624084f0f48cae9b95) Signed-off-by: Jani Nikula <jani.nikula@intel.com> | 17 February 2016, 09:52:54 UTC |
059fcd8 | Thomas Gleixner | 09 February 2016, 20:11:34 UTC | perf/core: Plug potential memory leak in CPU_UP_PREPARE If CPU_UP_PREPARE is called it is not guaranteed, that a previously allocated and assigned hash has been freed already, but perf_event_init_cpu() unconditionally allocates and assignes a new hash if the swhash is referenced. By overwriting the pointer the existing hash is not longer accessible. Verify that there is no hash assigned on this cpu before allocating and assigning a new one. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Cc: Arnaldo Carvalho de Melo <acme@redhat.com> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Stephane Eranian <eranian@google.com> Cc: Vince Weaver <vincent.weaver@maine.edu> Link: http://lkml.kernel.org/r/20160209201007.843269966@linutronix.de Signed-off-by: Ingo Molnar <mingo@kernel.org> | 17 February 2016, 09:37:30 UTC |
27ca923 | Thomas Gleixner | 09 February 2016, 20:11:26 UTC | perf/core: Remove the bogus and dangerous CPU_DOWN_FAILED hotplug state If CPU_DOWN_PREPARE fails the perf hotplug notifier is called for CPU_DOWN_FAILED and calls perf_event_init_cpu(), which checks whether the swhash is referenced. If yes it allocates a new hash and stores the pointer in the per cpu data structure. But at this point the cpu is still online, so there must be a valid hash already. By overwriting the pointer the existing hash is not longer accessible. Remove the CPU_DOWN_FAILED state, as there is nothing to (re)allocate. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Cc: Arnaldo Carvalho de Melo <acme@redhat.com> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Stephane Eranian <eranian@google.com> Cc: Vince Weaver <vincent.weaver@maine.edu> Link: http://lkml.kernel.org/r/20160209201007.763417379@linutronix.de Signed-off-by: Ingo Molnar <mingo@kernel.org> | 17 February 2016, 09:37:29 UTC |
b4f75d4 | Thomas Gleixner | 09 February 2016, 20:11:20 UTC | perf/core: Remove bogus UP_CANCELED hotplug state If CPU_UP_PREPARE fails the perf hotplug code calls perf_event_exit_cpu(), which is a pointless exercise. The cpu is not online, so the smp function calls return -ENXIO. So the result is a list walk to call noops. Remove it. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Cc: Arnaldo Carvalho de Melo <acme@redhat.com> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Stephane Eranian <eranian@google.com> Cc: Vince Weaver <vincent.weaver@maine.edu> Link: http://lkml.kernel.org/r/20160209201007.682184765@linutronix.de Signed-off-by: Ingo Molnar <mingo@kernel.org> | 17 February 2016, 09:37:28 UTC |
4e7f9df | Michael S. Tsirkin | 10 February 2016, 23:05:01 UTC | hpet: Drop stale URLs Looks like the HPET spec at intel.com got moved. It isn't hard to find so drop the link, just mention the revision assumed. Suggested-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Clemens Ladisch <clemens@ladisch.de> Cc: Jonathan Corbet <corbet@lwn.net> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: linux-doc@vger.kernel.org Link: http://lkml.kernel.org/r/1455145462-3877-1-git-send-email-mst@redhat.com Signed-off-by: Ingo Molnar <mingo@kernel.org> | 17 February 2016, 08:39:56 UTC |
12d319b | Stefan Haberland | 12 February 2016, 13:50:52 UTC | s390/dasd: fix performance drop Commit ca369d51b ("sd: Fix device-imposed transfer length limits") introduced a new queue limit max_dev_sectors which limits the maximum sectors for requests. The default value leads to small dasd requests and therefor to a performance drop. Set the max_dev_sectors value to the same value as the max_hw_sectors to use the maximum available request size for DASD devices. Signed-off-by: Stefan Haberland <sth@linux.vnet.ibm.com> Cc: stable@vger.kernel.org # 4.4+ Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com> | 17 February 2016, 08:24:07 UTC |
a82eee7 | Toshi Kani | 11 February 2016, 21:24:17 UTC | x86/uaccess/64: Handle the caching of 4-byte nocache copies properly in __copy_user_nocache() Data corruption issues were observed in tests which initiated a system crash/reset while accessing BTT devices. This problem is reproducible. The BTT driver calls pmem_rw_bytes() to update data in pmem devices. This interface calls __copy_user_nocache(), which uses non-temporal stores so that the stores to pmem are persistent. __copy_user_nocache() uses non-temporal stores when a request size is 8 bytes or larger (and is aligned by 8 bytes). The BTT driver updates the BTT map table, which entry size is 4 bytes. Therefore, updates to the map table entries remain cached, and are not written to pmem after a crash. Change __copy_user_nocache() to use non-temporal store when a request size is 4 bytes. The change extends the current byte-copy path for a less-than-8-bytes request, and does not add any overhead to the regular path. Reported-and-tested-by: Micah Parrish <micah.parrish@hpe.com> Reported-and-tested-by: Brian Boylston <brian.boylston@hpe.com> Signed-off-by: Toshi Kani <toshi.kani@hpe.com> Cc: <stable@vger.kernel.org> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Andy Lutomirski <luto@amacapital.net> Cc: Borislav Petkov <bp@alien8.de> Cc: Borislav Petkov <bp@suse.de> Cc: Brian Gerst <brgerst@gmail.com> Cc: Dan Williams <dan.j.williams@intel.com> Cc: Denys Vlasenko <dvlasenk@redhat.com> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Luis R. Rodriguez <mcgrof@suse.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Ross Zwisler <ross.zwisler@linux.intel.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Toshi Kani <toshi.kani@hp.com> Cc: Vishal Verma <vishal.l.verma@intel.com> Cc: linux-nvdimm@lists.01.org Link: http://lkml.kernel.org/r/1455225857-12039-3-git-send-email-toshi.kani@hpe.com [ Small readability edits. ] Signed-off-by: Ingo Molnar <mingo@kernel.org> | 17 February 2016, 08:10:23 UTC |
ee9737c | Toshi Kani | 11 February 2016, 21:24:16 UTC | x86/uaccess/64: Make the __copy_user_nocache() assembly code more readable Add comments to __copy_user_nocache() to clarify its procedures and alignment requirements. Also change numeric branch target labels to named local labels. No code changed: arch/x86/lib/copy_user_64.o: text data bss dec hex filename 1239 0 0 1239 4d7 copy_user_64.o.before 1239 0 0 1239 4d7 copy_user_64.o.after md5: 58bed94c2db98c1ca9a2d46d0680aaae copy_user_64.o.before.asm 58bed94c2db98c1ca9a2d46d0680aaae copy_user_64.o.after.asm Signed-off-by: Toshi Kani <toshi.kani@hpe.com> Cc: <stable@vger.kernel.org> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Andy Lutomirski <luto@amacapital.net> Cc: Borislav Petkov <bp@alien8.de> Cc: Borislav Petkov <bp@suse.de> Cc: Brian Gerst <brgerst@gmail.com> Cc: Denys Vlasenko <dvlasenk@redhat.com> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Luis R. Rodriguez <mcgrof@suse.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Toshi Kani <toshi.kani@hp.com> Cc: brian.boylston@hpe.com Cc: dan.j.williams@intel.com Cc: linux-nvdimm@lists.01.org Cc: micah.parrish@hpe.com Cc: ross.zwisler@linux.intel.com Cc: vishal.l.verma@intel.com Link: http://lkml.kernel.org/r/1455225857-12039-2-git-send-email-toshi.kani@hpe.com [ Small readability edits and added object file comparison. ] Signed-off-by: Ingo Molnar <mingo@kernel.org> | 17 February 2016, 08:10:22 UTC |
52499d9 | Heiko Carstens | 12 February 2016, 11:40:31 UTC | s390/maccess: reduce stnsm instructions When fixing the DAT off bug ("s390: fix DAT off memory access, e.g. on kdump") both Christian and I missed that we can save an additional stnsm instruction. This saves us a couple of cycles which could improve the speed of memcpy_real. Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com> | 17 February 2016, 08:05:04 UTC |
8bc9162 | Thomas Gleixner | 16 February 2016, 22:04:41 UTC | perf/x86/amd/uncore: Plug reference leak In the error path of amd_uncore_cpu_up_prepare() the newly allocated uncore struct is freed, but the percpu pointer still references it. Set it to NULL. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Cc: Arnaldo Carvalho de Melo <acme@redhat.com> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Stephane Eranian <eranian@google.com> Cc: Vince Weaver <vincent.weaver@maine.edu> Link: http://lkml.kernel.org/r/alpine.DEB.2.11.1602162302170.19512@nanos Signed-off-by: Ingo Molnar <mingo@kernel.org> | 17 February 2016, 07:36:09 UTC |
dada168 | Anton Protopopov | 07 February 2016, 04:25:28 UTC | drm/qxl: fix erroneous return value The qxl_gem_prime_mmap() function returns ENOSYS instead of -ENOSYS Signed-off-by: Anton Protopopov <a.s.protopopov@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com> | 17 February 2016, 05:39:35 UTC |
ff683df | Mario Kleiner | 12 February 2016, 19:30:32 UTC | drm/nouveau/display: Enable vblank irqs after display engine is on again. In the display resume path, move the calls to drm_vblank_on() after the point when the display engine is running again. Since changes were made to drm_update_vblank_count() in Linux 4.4+ to emulate hw vblank counters via vblank timestamping, the function drm_vblank_on() now needs working high precision vblank timestamping and therefore working scanout position queries at time of call. These don't work before the display engine gets restarted, causing miscalculation of vblank counter increments and thereby large forward jumps in vblank count at display resume. These jumps can cause client hangs on resume, or desktop hangs in the case of composited desktops. Fix this Linux 4.4 regression by reordering calls accordingly. Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com> Cc: <stable@vger.kernel.org> # 4.4+ Cc: Ben Skeggs <bskeggs@redhat.com> Cc: ville.syrjala@linux.intel.com Cc: daniel.vetter@ffwll.ch Cc: dri-devel@lists.freedesktop.org Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com> | 17 February 2016, 04:19:06 UTC |
e0b34e3 | Mario Kleiner | 12 February 2016, 19:30:31 UTC | drm/radeon/pm: Handle failure of drm_vblank_get. Make sure that drm_vblank_get/put() stay balanced in case drm_vblank_get fails, by skipping the corresponding put. Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: michel@daenzer.net Cc: dri-devel@lists.freedesktop.org Cc: alexander.deucher@amd.com Cc: christian.koenig@amd.com Signed-off-by: Dave Airlie <airlied@redhat.com> | 17 February 2016, 04:19:03 UTC |
bb74fc1 | Mario Kleiner | 12 February 2016, 19:30:30 UTC | drm: Fix treatment of drm_vblank_offdelay in drm_vblank_on() (v2) drm_vblank_offdelay can have three different types of values: < 0 is to be always treated the same as dev->vblank_disable_immediate = 0 is to be treated as "never disable vblanks" > 0 is to be treated as disable immediate if kms driver wants it that way via dev->vblank_disable_immediate. Otherwise it is a disable timeout in msecs. This got broken in Linux 3.18+ for the implementation of drm_vblank_on. If the user specified a value of zero which should always reenable vblank irqs in this function, a kms driver could override the users choice by setting vblank_disable_immediate to true. This patch fixes the regression and keeps the user in control. v2: Only reenable vblank if there are clients left or the user requested to "never disable vblanks" via offdelay 0. Enabling vblanks even in the "delayed disable" case (offdelay > 0) was specifically added by Ville in commit cd19e52aee922 ("drm: Kick start vblank interrupts at drm_vblank_on()"), but after discussion it turns out that this was done by accident. Citing Ville: "I think it just ended up as a mess due to changing some of the semantics of offdelay<0 vs. offdelay==0 vs. disable_immediate during the review of the series. So yeah, given how drm_vblank_put() works now, I'd just make this check for offdelay==0." Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: <stable@vger.kernel.org> # 3.18+ Cc: michel@daenzer.net Cc: vbabka@suse.cz Cc: ville.syrjala@linux.intel.com Cc: daniel.vetter@ffwll.ch Cc: dri-devel@lists.freedesktop.org Cc: alexander.deucher@amd.com Cc: christian.koenig@amd.com Signed-off-by: Dave Airlie <airlied@redhat.com> | 17 February 2016, 04:19:00 UTC |
c61934e | Mario Kleiner | 12 February 2016, 19:30:29 UTC | drm: Fix drm_vblank_pre/post_modeset regression from Linux 4.4 Changes to drm_update_vblank_count() in Linux 4.4 broke the behaviour of the pre/post modeset functions as the new update code doesn't deal with hw vblank counter resets inbetween calls to drm_vblank_pre_modeset an drm_vblank_post_modeset, as it should. This causes mistreatment of such hw counter resets as counter wraparound, and thereby large forward jumps of the software vblank counter which in turn cause vblank event dispatching and vblank waits to fail/hang --> userspace clients hang. This symptom was reported on radeon-kms to cause a infinite hang of KDE Plasma 5 shell's login procedure, preventing users from logging in. Fix this by detecting when drm_update_vblank_count() is called inside a pre->post modeset interval. If so, clamp valid vblank increments to the safe values 0 and 1, pretty much restoring the update behavior of the old update code of Linux 4.3 and earlier. Also reset the last recorded hw vblank count at call to drm_vblank_post_modeset() to be safe against hw that after modesetting, dpms on etc. only fires its first vblank irq after drm_vblank_post_modeset() was already called. Reported-by: Vlastimil Babka <vbabka@suse.cz> Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Tested-by: Vlastimil Babka <vbabka@suse.cz> Cc: <stable@vger.kernel.org> # 4.4+ Cc: michel@daenzer.net Cc: vbabka@suse.cz Cc: ville.syrjala@linux.intel.com Cc: daniel.vetter@ffwll.ch Cc: dri-devel@lists.freedesktop.org Cc: alexander.deucher@amd.com Cc: christian.koenig@amd.com Signed-off-by: Dave Airlie <airlied@redhat.com> | 17 February 2016, 04:18:59 UTC |
99b8e71 | Mario Kleiner | 12 February 2016, 19:30:28 UTC | drm: Prevent vblank counter bumps > 1 with active vblank clients. (v2) This fixes a regression introduced by the new drm_update_vblank_count() implementation in Linux 4.4: Restrict the bump of the software vblank counter in drm_update_vblank_count() to a safe maximum value of +1 whenever there is the possibility that concurrent readers of vblank timestamps could be active at the moment, as the current implementation of the timestamp caching and updating is not safe against concurrent readers for calls to store_vblank() with a bump of anything but +1. A bump != 1 would very likely return corrupted timestamps to userspace, because the same slot in the cache could be concurrently written by store_vblank() and read by one of those readers in a non-atomic fashion and without the read-retry logic detecting this collision. Concurrent readers can exist while drm_update_vblank_count() is called from the drm_vblank_off() or drm_vblank_on() functions or other non-vblank- irq callers. However, all those calls are happening with the vbl_lock locked thereby preventing a drm_vblank_get(), so the vblank refcount can't increase while drm_update_vblank_count() is executing. Therefore a zero vblank refcount during execution of that function signals that is safe for arbitrary counter bumps if called from outside vblank irq, whereas a non-zero count is not safe. Whenever the function is called from vblank irq, we have to assume concurrent readers could show up any time during its execution, even if the refcount is currently zero, as vblank irqs are usually only enabled due to the presence of readers, and because when it is called from vblank irq it can't hold the vbl_lock to protect it from sudden bumps in vblank refcount. Therefore also restrict bumps to +1 when the function is called from vblank irq. Such bumps of more than +1 can happen at other times than reenabling vblank irqs, e.g., when regular vblank interrupts get delayed by more than 1 frame due to long held locks, long irq off periods, realtime preemption on RT kernels, or system management interrupts. A better solution would be to rewrite the timestamp caching to use full seqlocks to allow concurrent writes and reads for arbitrary vblank counter increments. v2: Add code comment that this is essentially a hack and should be replaced by a full seqlock implementation for caching of timestamps. Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: <stable@vger.kernel.org> # 4.4+ Cc: michel@daenzer.net Cc: vbabka@suse.cz Cc: ville.syrjala@linux.intel.com Cc: daniel.vetter@ffwll.ch Cc: dri-devel@lists.freedesktop.org Cc: alexander.deucher@amd.com Cc: christian.koenig@amd.com Signed-off-by: Dave Airlie <airlied@redhat.com> | 17 February 2016, 04:18:59 UTC |
e823589 | Mario Kleiner | 12 February 2016, 19:30:27 UTC | drm: No-Op redundant calls to drm_vblank_off() (v2) Otherwise if a kms driver calls into drm_vblank_off() more than once before calling drm_vblank_on() again, the redundant calls to vblank_disable_and_save() will call drm_update_vblank_count() while hw vblank counters and vblank timestamping are in a undefined state during modesets, dpms off etc. At least with the legacy drm helpers it is not unusual to get multiple calls to drm_vblank_off and drm_vblank_on, e.g., half a dozen calls to drm_vblank_off and two calls to drm_vblank_on were observed on radeon-kms during dpms-off -> dpms-on transition. We don't no-op calls from atomic modesetting drivers, as they should do a proper job of tracking hw state. Fixes large jumps of the software maintained vblank counter due to the hardware vblank counter resetting to zero during dpms off or modeset, e.g., if radeon-kms is modified to use drm_vblank_off/on instead of drm_vblank_pre/post_modeset(). This fixes a regression caused by the changes made to drm_update_vblank_count() in Linux 4.4. v2: Don't no-op on atomic modesetting drivers, per suggestion of Daniel Vetter. Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: <stable@vger.kernel.org> # 4.4+ Cc: michel@daenzer.net Cc: vbabka@suse.cz Cc: ville.syrjala@linux.intel.com Cc: alexander.deucher@amd.com Cc: christian.koenig@amd.com Signed-off-by: Dave Airlie <airlied@redhat.com> | 17 February 2016, 04:18:57 UTC |
3485570 | Gerd Hoffmann | 16 February 2016, 13:25:00 UTC | drm/qxl: use kmalloc_array to alloc reloc_info in qxl_process_single_command This avoids integer overflows on 32bit machines when calculating reloc_info size, as reported by Alan Cox. Cc: stable@vger.kernel.org Cc: gnomes@lxorguk.ukuu.org.uk Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com> | 17 February 2016, 04:16:06 UTC |
e8f051e | Dave Airlie | 17 February 2016, 04:14:22 UTC | Merge branch 'exynos-drm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos into drm-fixes Summary: - fix compilation warnings on ARM64bit. - fix mic driver initialization. . MIC is a part of KMS so it converts it to use component framework like other KMS drivers did. - fix wrong driver state and disable clock order on DECON driver. - fix incorrect use of dma_mmap_attrs function. * 'exynos-drm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos: drm/exynos/decon: fix disable clocks order drm/exynos: fix incorrect cpu address for dma_mmap_attrs() drm/exynos: exynos5433_decon: fix wrong state in decon_vblank_enable drm/exynos: exynos5433_decon: fix wrong state assignment in decon_enable drm/exynos: dsi: restore support for drm bridge drm/exynos: mic: make all functions static drm/exynos: mic: convert to component framework drm/exynos: mic: use devm_clk interface drm/exynos: fix types for compilation on 64bit architectures drm/exynos: ipp: fix incorrect format specifiers in debug messages drm/exynos: depend on ARCH_EXYNOS for DRM_EXYNOS | 17 February 2016, 04:14:22 UTC |
8ae22cb | Dave Airlie | 17 February 2016, 01:36:38 UTC | Revert "drm/dp/mst: change MST detection scheme" This reverts commit cfcfa086d43ced33e1099b9befb12f17fca102e1. This causes the tiling properties to break in some unexpected ways, Revert it for now. Cc: stable@vger.kernel.org Signed-off-by: Dave Airlie <airlied@redhat.com> | 17 February 2016, 04:07:48 UTC |
413eddc | Chris Mason | 17 February 2016, 00:52:10 UTC | Merge branch 'for-chris-4.5' of git://git.kernel.org/pub/scm/linux/kernel/git/fdmanana/linux into for-linus-4.5 | 17 February 2016, 00:52:10 UTC |
3d65ae4 | Tahsin Erdogan | 16 February 2016, 21:34:39 UTC | writeback: initialize inode members that track writeback history inode struct members that track cgroup writeback information should be reinitialized when inode gets allocated from kmem_cache. Otherwise, their values remain and get used by the new inode. Signed-off-by: Tahsin Erdogan <tahsin@google.com> Acked-by: Tejun Heo <tj@kernel.org> Fixes: d10c80955265 ("writeback: implement foreign cgroup inode bdi_writeback switching") Signed-off-by: Jens Axboe <axboe@fb.com> | 16 February 2016, 21:57:21 UTC |
36cb625 | Eric Anholt | 08 February 2016, 20:59:02 UTC | drm/vc4: Use runtime PM to power cycle the device when the GPU hangs. This gets us functional GPU reset again, like we had until a refactor at merge time. Tested with a little patch to stuff in a broken binner job every 100 frames. Signed-off-by: Eric Anholt <eric@anholt.net> | 16 February 2016, 20:21:01 UTC |
001bdb5 | Eric Anholt | 06 February 2016, 01:41:49 UTC | drm/vc4: Enable runtime PM. This may actually get us a feature that the closed driver didn't have: turning off the GPU in between rendering jobs, while the V3D device is still opened by the client. There may be some tuning to be applied here to use autosuspend so that we don't bounce the device's power so much, but in steady-state GPU-bound rendering we keep the power on (since we keep multiple jobs outstanding) and even if we power cycle on every job we can still manage at least 680 fps. More importantly, though, runtime PM will allow us to power off the device to do a GPU reset. v2: Switch #ifdef to CONFIG_PM not CONFIG_PM_SLEEP (caught by kbuild test robot) Signed-off-by: Eric Anholt <eric@anholt.net> | 16 February 2016, 20:21:00 UTC |
c4ce60d | Eric Anholt | 08 February 2016, 19:19:14 UTC | drm/vc4: Fix spurious GPU resets due to BO reuse. We were tracking the "where are the head pointers pointing" globally, so if another job reused the same BOs and execution was at the same point as last time we checked, we'd stop and trigger a reset even though the GPU had made progress. Signed-off-by: Eric Anholt <eric@anholt.net> | 16 February 2016, 20:21:00 UTC |
2ee9465 | Eric Anholt | 25 January 2016, 22:33:50 UTC | drm/vc4: Drop error message on seqno wait timeouts. These ioctls end up getting exposed to fairly directly to GL users, and having normal user operations print DRM errors is obviously wrong. The message was originally to give us some idea of what happened when a hang occurred, but we have a DRM_INFO from reset for that. Signed-off-by: Eric Anholt <eric@anholt.net> | 16 February 2016, 20:20:59 UTC |
13cf890 | Eric Anholt | 25 January 2016, 22:32:41 UTC | drm/vc4: Fix -ERESTARTSYS error return from BO waits. This caused the wait ioctls to claim that waiting had completed when we actually got interrupted by a signal before it was done. Fixes broken rendering throttling that produced serious lag in X window dragging. Signed-off-by: Eric Anholt <eric@anholt.net> | 16 February 2016, 20:20:59 UTC |
2c68f1f | Eric Anholt | 25 January 2016, 22:13:12 UTC | drm/vc4: Return an ERR_PTR from BO creation instead of NULL. Fixes igt vc4_create_bo/create-bo-0 by returning -EINVAL from the ioctl instead of -ENOMEM. Signed-off-by: Eric Anholt <eric@anholt.net> | 16 February 2016, 20:20:58 UTC |
54aec44 | Eric Anholt | 25 January 2016, 21:52:41 UTC | drm/vc4: Fix the clear color for the first tile rendered. Apparently in hardware (as opposed to simulation), the clear colors need to be uploaded before the render config, otherwise they won't take effect. Fixes igt's vc4_wait_bo/used-bo-* subtests. Signed-off-by: Eric Anholt <eric@anholt.net> | 16 February 2016, 20:20:58 UTC |
e001523 | Eric Anholt | 25 January 2016, 21:05:00 UTC | drm/vc4: Validate that WAIT_BO padding is cleared. This is ABI future-proofing if we ever want to extend the pad to mean something. Signed-off-by: Eric Anholt <eric@anholt.net> | 16 February 2016, 20:20:57 UTC |
65c23c6 | Linus Torvalds | 16 February 2016, 18:52:59 UTC | Merge branch 'for-next' of git://git.samba.org/sfrench/cifs-2.6 Pull cifs fixes from Steve French: "A small set of cifs fixes. I am still reviewing some more, recently submitted SMB3 fixes, but these three are small and safe and ready now" * 'for-next' of git://git.samba.org/sfrench/cifs-2.6: cifs: fix erroneous return value cifs: fix potential overflow in cifs_compose_mount_options cifs: remove redundant check for null string pointer | 16 February 2016, 18:52:59 UTC |
d82834e | Linus Torvalds | 16 February 2016, 18:50:46 UTC | Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm Pull ARM KVM fixes from Paolo Bonzini: - Fix for an unpleasant crash when the VM is created without a timer - Allow HYP mode to access the full PA space, and not only 40bit * tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm: arm64: KVM: Configure TCR_EL2.PS at runtime KVM: arm/arm64: Fix reference to uninitialised VGIC | 16 February 2016, 18:50:46 UTC |
5ff8eaa | Tejun Heo | 16 February 2016, 18:34:07 UTC | writeback: keep superblock pinned during cgroup writeback association switches If cgroup writeback is in use, an inode is associated with a cgroup for writeback. If the inode's main dirtier changes to another cgroup, the association gets updated asynchronously. Nothing was pinning the superblock while such switches are in progress and superblock could go away while async switching is pending or in progress leading to crashes like the following. kernel BUG at fs/jbd2/transaction.c:319! invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC CPU: 1 PID: 29158 Comm: kworker/1:10 Not tainted 4.5.0-rc3 #51 Hardware name: Google Google, BIOS Google 01/01/2011 Workqueue: events inode_switch_wbs_work_fn task: ffff880213dbbd40 ti: ffff880209264000 task.ti: ffff880209264000 RIP: 0010:[<ffffffff803e6922>] [<ffffffff803e6922>] start_this_handle+0x382/0x3e0 RSP: 0018:ffff880209267c30 EFLAGS: 00010202 ... Call Trace: [<ffffffff803e6be4>] jbd2__journal_start+0xf4/0x190 [<ffffffff803cfc7e>] __ext4_journal_start_sb+0x4e/0x70 [<ffffffff803b31ec>] ext4_evict_inode+0x12c/0x3d0 [<ffffffff8035338b>] evict+0xbb/0x190 [<ffffffff80354190>] iput+0x130/0x190 [<ffffffff80360223>] inode_switch_wbs_work_fn+0x343/0x4c0 [<ffffffff80279819>] process_one_work+0x129/0x300 [<ffffffff80279b16>] worker_thread+0x126/0x480 [<ffffffff8027ed14>] kthread+0xc4/0xe0 [<ffffffff809771df>] ret_from_fork+0x3f/0x70 Fix it by bumping s_active while cgroup association switching is in flight. Signed-off-by: Tejun Heo <tj@kernel.org> Reported-and-tested-by: Tahsin Erdogan <tahsin@google.com> Link: http://lkml.kernel.org/g/CAAeU0aNCq7LGODvVGRU-oU_o-6enii5ey0p1c26D1ZzYwkDc5A@mail.gmail.com Fixes: d10c80955265 ("writeback: implement foreign cgroup inode bdi_writeback switching") Cc: stable@vger.kernel.org #v4.5+ Signed-off-by: Jens Axboe <axboe@fb.com> | 16 February 2016, 18:34:07 UTC |
c53d7a8 | Paolo Bonzini | 16 February 2016, 17:51:55 UTC | Merge tag 'kvm-arm-for-4.5-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm into kvm-master KVM/ARM fixes for 4.5-rc4 - Fix for an unpleasant crash when the VM is created without a timer - Allow HYP mode to access the full PA space, and not only 40bit | 16 February 2016, 17:51:55 UTC |
87bbcfd | Linus Torvalds | 16 February 2016, 16:04:06 UTC | Merge tag 'for-linus-20160216' of git://git.infradead.org/intel-iommu Pull IOMMU SVM fixes from David Woodhouse: "Minor register size and interrupt acknowledgement fixes which only showed up in testing on newer hardware, but mostly a fix to the MM refcount handling to prevent a recursive refcount issue when mmap() is used on the file descriptor associated with a bound PASID" * tag 'for-linus-20160216' of git://git.infradead.org/intel-iommu: iommu/vt-d: Clear PPR bit to ensure we get more page request interrupts iommu/vt-d: Fix 64-bit accesses to 32-bit DMAR_GSTS_REG iommu/vt-d: Fix mm refcounting to hold mm_count not mm_users | 16 February 2016, 16:04:06 UTC |
02a5f76 | Ingo Molnar | 16 February 2016, 15:46:40 UTC | Merge tag 'efi-urgent' of git://git.kernel.org/pub/scm/linux/kernel/git/mfleming/efi into x86/urgent Pull EFI bug fixes from Matt Fleming: * Fix bugs in our code that converts ucs2 strings to utf8 where we unintentionally drop bits from the original string (Jason Andryuk) * Add the efi-pstore variables to the variable whitelist so that users can continue to delete them via efivarfs without needing to manipulate the immutable flag (Matt Fleming) Signed-off-by: Ingo Molnar <mingo@kernel.org> | 16 February 2016, 15:46:40 UTC |
e5310a1 | Linus Torvalds | 16 February 2016, 15:15:20 UTC | Merge tag 'spi-fix-v4.5-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi Pull spi fixes from Mark Brown: "A small clutch of driver specific fixes. The OMAP one is a bit worrying since it seems to be triggered by some changes in the runtime PM core code and I suspect there's other drivers across that are going to be using the same pattern outside of OMAP but nothing seems to be coming up in the testing people are doing" * tag 'spi-fix-v4.5-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi: spi: omap2-mcspi: Fix PM regression with deferred probe for pm_runtime_reinit spi: bcm2835aux: fix bitmask defines spi: atmel: fix gpio chip-select in case of non-DT platform spi/fsl-espi: Correct the maximum transaction length spi: imx: fix spi resource leak with dma transfer spi: fix counting in spi-loopback-test code | 16 February 2016, 15:15:20 UTC |
2a4be2c | Linus Torvalds | 16 February 2016, 15:13:53 UTC | Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/geert/linux-m68k Pull m68k fixes from Geert Uytterhoeven: "Summary: - Wire up new copy_file_range syscall - Update defconfigs" * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/geert/linux-m68k: m68k/defconfig: Update defconfigs for v4.5-rc1 m68k: Wire up copy_file_range | 16 February 2016, 15:13:53 UTC |
bc3f5d8 | Rasmus Villemoes | 15 February 2016, 18:41:47 UTC | drm/radeon: use post-decrement in error handling We need to use post-decrement to get the pci_map_page undone also for i==0, and to avoid some very unpleasant behaviour if pci_map_page failed already at i==0. Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org | 16 February 2016, 15:05:50 UTC |
09ccbb7 | Rasmus Villemoes | 15 February 2016, 18:41:45 UTC | drm/amdgpu: use post-decrement in error handling We need to use post-decrement to get the pci_map_page undone also for i==0, and to avoid some very unpleasant behaviour if pci_map_page failed already at i==0. Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org | 16 February 2016, 15:05:38 UTC |
13d5e5d | Takashi Iwai | 16 February 2016, 13:15:59 UTC | ALSA: seq: Fix double port list deletion The commit [7f0973e973cd: ALSA: seq: Fix lockdep warnings due to double mutex locks] split the management of two linked lists (source and destination) into two individual calls for avoiding the AB/BA deadlock. However, this may leave the possible double deletion of one of two lists when the counterpart is being deleted concurrently. It ends up with a list corruption, as revealed by syzkaller fuzzer. This patch fixes it by checking the list emptiness and skipping the deletion and the following process. BugLink: http://lkml.kernel.org/r/CACT4Y+bay9qsrz6dQu31EcGaH9XwfW7o3oBzSQUG9fMszoh=Sg@mail.gmail.com Fixes: 7f0973e973cd ('ALSA: seq: Fix lockdep warnings due to 'double mutex locks) Reported-by: Dmitry Vyukov <dvyukov@google.com> Tested-by: Dmitry Vyukov <dvyukov@google.com> Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de> | 16 February 2016, 13:37:19 UTC |
a680759 | Jason Andryuk | 12 February 2016, 23:13:33 UTC | lib/ucs2_string: Correct ucs2 -> utf8 conversion The comparisons should be >= since 0x800 and 0x80 require an additional bit to store. For the 3 byte case, the existing shift would drop off 2 more bits than intended. For the 2 byte case, there should be 5 bits bits in byte 1, and 6 bits in byte 2. Signed-off-by: Jason Andryuk <jandryuk@gmail.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Cc: Peter Jones <pjones@redhat.com> Cc: Matthew Garrett <mjg59@coreos.com> Cc: "Lee, Chun-Yi" <jlee@suse.com> Signed-off-by: Matt Fleming <matt@codeblueprint.co.uk> | 16 February 2016, 12:49:05 UTC |
e246eb5 | Matt Fleming | 15 February 2016, 10:34:05 UTC | efi: Add pstore variables to the deletion whitelist Laszlo explains why this is a good idea, 'This is because the pstore filesystem can be backed by UEFI variables, and (for example) a crash might dump the last kilobytes of the dmesg into a number of pstore entries, each entry backed by a separate UEFI variable in the above GUID namespace, and with a variable name according to the above pattern. Please see "drivers/firmware/efi/efi-pstore.c". While this patch series will not prevent the user from deleting those UEFI variables via the pstore filesystem (i.e., deleting a pstore fs entry will continue to delete the backing UEFI variable), I think it would be nice to preserve the possibility for the sysadmin to delete Linux-created UEFI variables that carry portions of the crash log, *without* having to mount the pstore filesystem.' There's also no chance of causing machines to become bricked by deleting these variables, which is the whole purpose of excluding things from the whitelist. Use the LINUX_EFI_CRASH_GUID guid and a wildcard '*' for the match so that we don't have to update the string in the future if new variable name formats are created for crash dump variables. Reported-by: Laszlo Ersek <lersek@redhat.com> Acked-by: Peter Jones <pjones@redhat.com> Tested-by: Peter Jones <pjones@redhat.com> Cc: Matthew Garrett <mjg59@srcf.ucam.org> Cc: "Lee, Chun-Yi" <jlee@suse.com> Signed-off-by: Matt Fleming <matt@codeblueprint.co.uk> | 16 February 2016, 12:48:18 UTC |
4682c21 | Ingo Molnar | 16 February 2016, 12:14:57 UTC | Merge tag 'efi-urgent' of git://git.kernel.org/pub/scm/linux/kernel/git/mfleming/efi into x86/urgent Pull EFI fixes from Matt Fleming: * Prevent accidental deletion of EFI variables through efivarfs that may brick machines. We use a whitelist of known-safe variables to allow things like installing distributions to work out of the box, and instead restrict vendor-specific variable deletion by making non-whitelist variables immutable (Peter Jones) Signed-off-by: Ingo Molnar <mingo@kernel.org> | 16 February 2016, 12:14:57 UTC |
7f4e346 | Thierry Reding | 16 February 2016, 10:16:31 UTC | arm64/efi: Make strnlen() available to the EFI namespace Changes introduced in the upstream version of libfdt pulled in by commit 91feabc2e224 ("scripts/dtc: Update to upstream commit b06e55c88b9b") use the strnlen() function, which isn't currently available to the EFI name- space. Add it to the EFI namespace to avoid a linker error. Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Rob Herring <robh@kernel.org> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Will Deacon <will.deacon@arm.com> | 16 February 2016, 10:32:10 UTC |
c906f38 | Kirill Tkhai | 16 February 2016, 05:20:19 UTC | ext4: fix memleak in ext4_readdir() When ext4_bread() fails, fname_crypto_str remains allocated after return. Fix that. Signed-off-by: Kirill Tkhai <ktkhai@virtuozzo.com> Signed-off-by: Theodore Ts'o <tytso@mit.edu> CC: Dmitry Monakhov <dmonakhov@virtuozzo.com> | 16 February 2016, 05:20:19 UTC |
1636d1d | Filipe Manana | 15 February 2016, 16:20:26 UTC | Btrfs: fix direct IO requests not reporting IO error to user space If a bio for a direct IO request fails, we were not setting the error in the parent bio (the main DIO bio), making us not return the error to user space in btrfs_direct_IO(), that is, it made __blockdev_direct_IO() return the number of bytes issued for IO and not the error a bio created and submitted by btrfs_submit_direct() got from the block layer. This essentially happens because when we call: dio_end_io(dio_bio, bio->bi_error); It does not set dio_bio->bi_error to the value of the second argument. So just add this missing assignment in endio callbacks, just as we do in the error path at btrfs_submit_direct() when we fail to clone the dio bio or allocate its private object. This follows the convention of what is done with other similar APIs such as bio_endio() where the caller is responsible for setting the bi_error field in the bio it passes as an argument to bio_endio(). This was detected by the new generic test cases in xfstests: 271, 272, 276 and 278. Which essentially setup a dm error target, then load the error table, do a direct IO write and unload the error table. They expect the write to fail with -EIO, which was not getting reported when testing against btrfs. Cc: stable@vger.kernel.org # 4.3+ Fixes: 4246a0b63bd8 ("block: add a bi_error field to struct bio") Signed-off-by: Filipe Manana <fdmanana@suse.com> | 16 February 2016, 03:41:26 UTC |
d9ff0eb | Youngmin Nam | 08 February 2016, 15:49:28 UTC | pinctrl: samsung: fix SMP race condition Previously, samsung_gpio_drection_in/output function were not covered with a spinlock. For example, samsung_gpio_direction_output function consists of two functions. 1. samsung_gpio_set 2. samsung_gpio_set_direction When 2 CPUs try to control the same gpio pin heavily, (situation like i2c control with gpio emulation) This situation can cause below problem. CPU 0 | CPU1 | samsung_gpio_direction_output | samsung_gpio_set(pin A as 1) | samsung_gpio_direction_output | samsung_gpio_set(pin A as 0) samsung_gpio_set_direction | | samsung_gpio_set_direction The initial value of pin A will be set as 0 while we wanted to set pin A as 1. This patch modifies samsung_gpio_direction_in/output function to be done in one spinlock to fix race condition. Additionally, the new samsung_gpio_set_value was added to implement gpio set callback(samsung_gpio_set) with spinlock using this function. Cc: stable@vger.kernel.org Signed-off-by: Youngmin Nam <ym0914@gmail.com> Acked-by: Tomasz Figa <tomasz.figa@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> | 15 February 2016, 19:45:50 UTC |
b33c8ff | Arnd Bergmann | 12 February 2016, 21:26:42 UTC | tracing: Fix freak link error caused by branch tracer In my randconfig tests, I came across a bug that involves several components: * gcc-4.9 through at least 5.3 * CONFIG_GCOV_PROFILE_ALL enabling -fprofile-arcs for all files * CONFIG_PROFILE_ALL_BRANCHES overriding every if() * The optimized implementation of do_div() that tries to replace a library call with an division by multiplication * code in drivers/media/dvb-frontends/zl10353.c doing u32 adc_clock = 450560; /* 45.056 MHz */ if (state->config.adc_clock) adc_clock = state->config.adc_clock; do_div(value, adc_clock); In this case, gcc fails to determine whether the divisor in do_div() is __builtin_constant_p(). In particular, it concludes that __builtin_constant_p(adc_clock) is false, while __builtin_constant_p(!!adc_clock) is true. That in turn throws off the logic in do_div() that also uses __builtin_constant_p(), and instead of picking either the constant- optimized division, and the code in ilog2() that uses __builtin_constant_p() to figure out whether it knows the answer at compile time. The result is a link error from failing to find multiple symbols that should never have been called based on the __builtin_constant_p(): dvb-frontends/zl10353.c:138: undefined reference to `____ilog2_NaN' dvb-frontends/zl10353.c:138: undefined reference to `__aeabi_uldivmod' ERROR: "____ilog2_NaN" [drivers/media/dvb-frontends/zl10353.ko] undefined! ERROR: "__aeabi_uldivmod" [drivers/media/dvb-frontends/zl10353.ko] undefined! This patch avoids the problem by changing __trace_if() to check whether the condition is known at compile-time to be nonzero, rather than checking whether it is actually a constant. I see this one link error in roughly one out of 1600 randconfig builds on ARM, and the patch fixes all known instances. Link: http://lkml.kernel.org/r/1455312410-1058841-1-git-send-email-arnd@arndb.de Acked-by: Nicolas Pitre <nico@linaro.org> Fixes: ab3c9c686e22 ("branch tracer, intel-iommu: fix build with CONFIG_BRANCH_TRACER=y") Cc: stable@vger.kernel.org # v2.6.30+ Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Steven Rostedt <rostedt@goodmis.org> | 15 February 2016, 18:06:00 UTC |
f377554 | Steven Rostedt (Red Hat) | 15 February 2016, 17:36:14 UTC | tracepoints: Do not trace when cpu is offline The tracepoint infrastructure uses RCU sched protection to enable and disable tracepoints safely. There are some instances where tracepoints are used in infrastructure code (like kfree()) that get called after a CPU is going offline, and perhaps when it is coming back online but hasn't been registered yet. This can probuce the following warning: [ INFO: suspicious RCU usage. ] 4.4.0-00006-g0fe53e8-dirty #34 Tainted: G S ------------------------------- include/trace/events/kmem.h:141 suspicious rcu_dereference_check() usage! other info that might help us debug this: RCU used illegally from offline CPU! rcu_scheduler_active = 1, debug_locks = 1 no locks held by swapper/8/0. stack backtrace: CPU: 8 PID: 0 Comm: swapper/8 Tainted: G S 4.4.0-00006-g0fe53e8-dirty #34 Call Trace: [c0000005b76c78d0] [c0000000008b9540] .dump_stack+0x98/0xd4 (unreliable) [c0000005b76c7950] [c00000000010c898] .lockdep_rcu_suspicious+0x108/0x170 [c0000005b76c79e0] [c00000000029adc0] .kfree+0x390/0x440 [c0000005b76c7a80] [c000000000055f74] .destroy_context+0x44/0x100 [c0000005b76c7b00] [c0000000000934a0] .__mmdrop+0x60/0x150 [c0000005b76c7b90] [c0000000000e3ff0] .idle_task_exit+0x130/0x140 [c0000005b76c7c20] [c000000000075804] .pseries_mach_cpu_die+0x64/0x310 [c0000005b76c7cd0] [c000000000043e7c] .cpu_die+0x3c/0x60 [c0000005b76c7d40] [c0000000000188d8] .arch_cpu_idle_dead+0x28/0x40 [c0000005b76c7db0] [c000000000101e6c] .cpu_startup_entry+0x50c/0x560 [c0000005b76c7ed0] [c000000000043bd8] .start_secondary+0x328/0x360 [c0000005b76c7f90] [c000000000008a6c] start_secondary_prolog+0x10/0x14 This warning is not a false positive either. RCU is not protecting code that is being executed while the CPU is offline. Instead of playing "whack-a-mole(TM)" and adding conditional statements to the tracepoints we find that are used in this instance, simply add a cpu_online() test to the tracepoint code where the tracepoint will be ignored if the CPU is offline. Use of raw_smp_processor_id() is fine, as there should never be a case where the tracepoint code goes from running on a CPU that is online and suddenly gets migrated to a CPU that is offline. Link: http://lkml.kernel.org/r/1455387773-4245-1-git-send-email-kda@linux-powerpc.org Reported-by: Denis Kirjanov <kda@linux-powerpc.org> Fixes: 97e1c18e8d17b ("tracing: Kernel Tracepoints") Cc: stable@vger.kernel.org # v2.6.28+ Signed-off-by: Steven Rostedt <rostedt@goodmis.org> | 15 February 2016, 18:04:46 UTC |
ee1cdcd | Andy Shevchenko | 10 February 2016, 13:59:42 UTC | dmaengine: dw: disable BLOCK IRQs for non-cyclic xfer The commit 2895b2cad6e7 ("dmaengine: dw: fix cyclic transfer callbacks") re-enabled BLOCK interrupts with regard to make cyclic transfers work. However, this change becomes a regression for non-cyclic transfers as interrupt counters under stress test had been grown enormously (approximately per 4-5 bytes in the UART loop back test). Taking into consideration above enable BLOCK interrupts if and only if channel is programmed to perform cyclic transfer. Fixes: 2895b2cad6e7 ("dmaengine: dw: fix cyclic transfer callbacks") Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Mans Rullgard <mans@mansr.com> Tested-by: Mans Rullgard <mans@mansr.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Cc: <stable@vger.kernel.org> Signed-off-by: Vinod Koul <vinod.koul@intel.com> | 15 February 2016, 16:49:32 UTC |
bee038a | Jeremy Linton | 12 February 2016, 15:47:52 UTC | arm/arm64: crypto: assure that ECB modes don't require an IV ECB modes don't use an initialization vector. The kernel /proc/crypto interface doesn't reflect this properly. Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Jeremy Linton <jeremy.linton@arm.com> Signed-off-by: Will Deacon <will.deacon@arm.com> | 15 February 2016, 15:48:29 UTC |
0b8c821 | Takashi Iwai | 15 February 2016, 15:37:24 UTC | ALSA: hda - Cancel probe work instead of flush at remove The commit [991f86d7ae4e: ALSA: hda - Flush the pending probe work at remove] introduced the sync of async probe work at remove for fixing the race. However, this may lead to another hangup when the module removal is performed quickly before starting the probe work, because it issues flush_work() and it's blocked forever. The workaround is to use cancel_work_sync() instead of flush_work() there. Fixes: 991f86d7ae4e ('ALSA: hda - Flush the pending probe work at remove') Cc: <stable@vger.kernel.org> # v3.17+ Signed-off-by: Takashi Iwai <tiwai@suse.de> | 15 February 2016, 15:37:24 UTC |