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 |
---|---|---|---|---|
9f9499a | Linus Torvalds | 14 December 2015, 01:42:58 UTC | Linux 4.4-rc5 | 14 December 2015, 01:42:58 UTC |
dfd01f0 | Peter Zijlstra | 13 December 2015, 21:11:16 UTC | sched/wait: Fix the signal handling fix Jan Stancek reported that I wrecked things for him by fixing things for Vladimir :/ His report was due to an UNINTERRUPTIBLE wait getting -EINTR, which should not be possible, however my previous patch made this possible by unconditionally checking signal_pending(). We cannot use current->state as was done previously, because the instruction after the store to that variable it can be changed. We must instead pass the initial state along and use that. Fixes: 68985633bccb ("sched/wait: Fix signal handling in bit wait helpers") Reported-by: Jan Stancek <jstancek@redhat.com> Reported-by: Chris Mason <clm@fb.com> Tested-by: Jan Stancek <jstancek@redhat.com> Tested-by: Vladimir Murzin <vladimir.murzin@arm.com> Tested-by: Chris Mason <clm@fb.com> Reviewed-by: Paul Turner <pjt@google.com> Cc: Ingo Molnar <mingo@kernel.org> Cc: tglx@linutronix.de Cc: Oleg Nesterov <oleg@redhat.com> Cc: hpa@zytor.com Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> | 13 December 2015, 22:30:59 UTC |
fc89182 | Linus Torvalds | 13 December 2015, 20:46:04 UTC | Merge tag 'nfs-for-4.4-3' of git://git.linux-nfs.org/projects/trondmy/linux-nfs Pull NFS client bugfix from Trond Myklebust: "SUNRPC: Fix a NFSv4.1 callback channel regression" * tag 'nfs-for-4.4-3' of git://git.linux-nfs.org/projects/trondmy/linux-nfs: SUNRPC: Fix callback channel | 13 December 2015, 20:46:04 UTC |
dec9cbf | Linus Torvalds | 13 December 2015, 20:41:10 UTC | Merge branch 'irq-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull timer fixlets from Thomas Gleixner: "Two trivial fixes which add missing header fileas and forward declarations so the code will compile even when the magic include chains are different" * 'irq-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: irqchip/gic-v3: Add missing include for barrier.h irqchip/gic-v3: Add missing struct device_node declaration | 13 December 2015, 20:41:10 UTC |
43afc99 | Linus Torvalds | 13 December 2015, 20:36:23 UTC | Merge branch 'timers-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull timer fix from Thomas Gleixner: "A single fix to unbreak a clocksource driver which has more than 32bit counter width" * 'timers-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: clocksource: Mmio: remove artificial 32bit limitation | 13 December 2015, 20:36:23 UTC |
f17ef49 | Linus Torvalds | 13 December 2015, 20:29:22 UTC | Merge tag 'char-misc-4.4-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc Pull fpga driver fixes from Greg KH: "Only two small fpga driver fixes here, both have been in linux-next for a while, and resolve some reported issues" * tag 'char-misc-4.4-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc: fpga manager: Fix firmware resource leak on error fpga manager: remove label | 13 December 2015, 20:29:22 UTC |
b24f74e | Linus Torvalds | 13 December 2015, 20:24:39 UTC | Merge tag 'staging-4.4-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging Pull staging driver fixes from Greg KH: "Here are a few staging and IIO driver fixes for 4.4-rc5. All of them resolve reported problems and have been in linux-next for a while. Nothing major here, just small fixes where needed" * tag 'staging-4.4-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging: staging: lustre: echo_copy.._lsm() dereferences userland pointers directly iio: adc: spmi-vadc: add missing of_node_put iio: fix some warning messages iio: light: apds9960: correct ->last_busy count iio: lidar: return -EINVAL on invalid signal staging: iio: dummy: complete IIO events delivery to userspace | 13 December 2015, 20:24:39 UTC |
c474009 | Linus Torvalds | 13 December 2015, 19:58:18 UTC | Merge tag 'usb-4.4-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb Pull USB driver fixes from Greg KH: "Here are a number of small USB fixes for 4.4-rc5. All of them have been in linux-next. The majority are gadget and phy issues, with a few new quirks and device ids added as well" * tag 'usb-4.4-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb: (32 commits) USB: add quirk for devices with broken LPM xhci: fix usb2 resume timing and races. usb: musb: fail with error when no DMA controller set usb: gadget: uvc: fix permissions of configfs attributes usb: musb: core: Fix pm runtime for deferred probe usb: phy: msm: fix a possible NULL dereference USB: host: ohci-at91: fix a crash in ohci_hcd_at91_overcurrent_irq usb: Quiet down false peer failure messages usb: xhci: fix config fail of FS hub behind a HS hub with MTT xhci: Fix memory leak in xhci_pme_acpi_rtd3_enable() usb: Use the USB_SS_MULT() macro to decode burst multiplier for log message USB: whci-hcd: add check for dma mapping error usb: core : hub: Fix BOS 'NULL pointer' kernel panic USB: quirks: Apply ALWAYS_POLL to all ELAN devices usb-storage: Fix scsi-sd failure "Invalid field in cdb" for USB adapter JMicron USB: quirks: Fix another ELAN touchscreen usb: dwc3: gadget: don't prestart interrupt endpoints USB: serial: Another Infineon flash loader USB ID USB: cdc_acm: Ignore Infineon Flash Loader utility USB: cp210x: Remove CP2110 ID from compatibility list ... | 13 December 2015, 19:58:18 UTC |
097b285 | Linus Torvalds | 13 December 2015, 00:43:44 UTC | Merge tag 'fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc Pull ARM SoC fixes from Arnd Bergmann: "Here are a bunch of small bug fixes for various ARM platforms, nothing really sticks out this week, most of either fixes bugs in code that was just added in 4.4, or that has been broken for many years without anyone noticing. at91/sama5d2: - fix sama5de hardware setup of sd/mmc interface - proper selection of pinctrl drivers. PIO4 is necessary for sama5d2 berlin: - fix incorrect clock input for SDIO exynos: - Fix potential NULL pointer dereference in Exynos PMU driver. imx: - Fix vf610 SAI clock configuration bug which is discovered by the newly added master mode support in SAI audio driver. - Fix buggy L2 cache latency values in vf610 device trees, which may cause system hang when cpu runs at a higher frequency. ixp4xx: - fix prototypes for readl/writel functions ls2080a: - use little-endian register access for GPIO and SDHCI omap: - Fix clock source for ARM TWD and global timers on am437x - Always select REGULATOR_FIXED_VOLTAGE for omap2+ instead of when MACH_OMAP3_PANDORA is selected - Fix SPI DMA handles for dm816x as only some were mapped - Fix up mbox cells for dm816x to make mailbox usable pxa: - use PWM lookup table for all ezx machines s3c24xx: - Remove incorrect __init annotation from s3c24xx cpufreq driver structures. versatile: - fix PCI IRQ mapping on Versatile PB" * tag 'fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: ls2080a/dts: Add little endian property for GPIO IP block dt-bindings: define little-endian property for QorIQ GPIO ARM64: dts: ls2080a: fix eSDHC endianness ARM: dts: vf610: use reset values for L2 cache latencies ARM: pxa: use PWM lookup table for all machines ARM: dts: berlin: add 2nd clock for BG2Q sdhci0 and sdhci1 ARM: dts: berlin: correct BG2Q's sdhci2 2nd clock ARM: dts: am4372: fix clock source for arm twd and global timers ARM: at91: fix pinctrl driver selection ARM: at91/dt: add always-on to 1.8V regulator ARM: dts: vf610: fix clock definition for SAI2 ARM: imx: clk-vf610: fix SAI clock tree ARM: ixp4xx: fix read{b,w,l} return types irqchip/versatile-fpga: Fix PCI IRQ mapping on Versatile PB ARM: OMAP2+: enable REGULATOR_FIXED_VOLTAGE ARM: dts: add dm816x missing spi DT dma handles ARM: dts: add dm816x missing #mbox-cells cpufreq: s3c24xx: Do not mark s3c2410_plls_add as __init ARM: EXYNOS: Fix potential NULL pointer access in exynos_sys_powerdown_conf | 13 December 2015, 00:43:44 UTC |
79dbdda | Linus Torvalds | 12 December 2015, 21:39:59 UTC | Merge tag 'powerpc-4.4-4' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux Pull powerpc fixes from Michael Ellerman: - opal-irqchip: Fix double endian conversion from Alistair Popple - cxl: Set endianess of kernel contexts from Frederic Barrat - sbc8641: drop bogus PHY IRQ entries from DTS file from Paul Gortmaker - Revert "powerpc/eeh: Don't unfreeze PHB PE after reset" from Andrew Donnellan * tag 'powerpc-4.4-4' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux: Revert "powerpc/eeh: Don't unfreeze PHB PE after reset" powerpc/sbc8641: drop bogus PHY IRQ entries from DTS file cxl: Set endianess of kernel contexts powerpc/opal-irqchip: Fix double endian conversion | 12 December 2015, 21:39:59 UTC |
800f1ac | Linus Torvalds | 12 December 2015, 18:44:49 UTC | Merge branch 'akpm' (patches from Andrew) Merge misc fixes from Andrew Morton: "17 fixes" * emailed patches from Andrew Morton <akpm@linux-foundation.org>: MIPS: fix DMA contiguous allocation sh64: fix __NR_fgetxattr ocfs2: fix SGID not inherited issue mm/oom_kill.c: avoid attempting to kill init sharing same memory drivers/base/memory.c: prohibit offlining of memory blocks with missing sections tmpfs: fix shmem_evict_inode() warnings on i_blocks mm/hugetlb.c: fix resv map memory leak for placeholder entries mm: hugetlb: call huge_pte_alloc() only if ptep is null kernel: remove stop_machine() Kconfig dependency mm: kmemleak: mark kmemleak_init prototype as __init mm: fix kerneldoc on mem_cgroup_replace_page osd fs: __r4w_get_page rely on PageUptodate for uptodate MAINTAINERS: make Vladimir co-maintainer of the memory controller mm, vmstat: allow WQ concurrency to discover memory reclaim doesn't make any progress mm: fix swapped Movable and Reclaimable in /proc/pagetypeinfo memcg: fix memory.high target mm: hugetlb: fix hugepage memory leak caused by wrong reserve count | 12 December 2015, 18:44:49 UTC |
a971526 | Linus Torvalds | 12 December 2015, 18:34:20 UTC | Merge branch 'parisc-4.4-3' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux Pull parisc fixes from Helge Deller: "Fix the boot crash on Mako machines with Huge Pages, prevent a panic with SATA controllers (and others) by correctly calculating the IOMMU space, hook up the mlock2 syscall and drop unneeded code in the parisc pci code" * 'parisc-4.4-3' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux: parisc: Disable huge pages on Mako machines parisc: Wire up mlock2 syscall parisc: Remove unused pcibios_init_bus() parisc iommu: fix panic due to trying to allocate too large region | 12 December 2015, 18:34:20 UTC |
7807563 | Linus Torvalds | 12 December 2015, 18:24:00 UTC | Merge branch 'for-linus' of git://git.kernel.dk/linux-block Pull block layer fixes from Jens Axboe: "A set of fixes for the current series. This contains: - A bunch of fixes for lightnvm, should be the last round for this series. From Matias and Wenwei. - A writeback detach inode fix from Ilya, also marked for stable. - A block (though it says SCSI) fix for an OOPS in SCSI runtime power management. - Module init error path fixes for null_blk from Minfei" * 'for-linus' of git://git.kernel.dk/linux-block: null_blk: Fix error path in module initialization lightnvm: do not compile in debugging by default lightnvm: prevent gennvm module unload on use lightnvm: fix media mgr registration lightnvm: replace req queue with nvmdev for lld lightnvm: comments on constants lightnvm: check mm before use lightnvm: refactor spin_unlock in gennvm_get_blk lightnvm: put blks when luns configure failed lightnvm: use flags in rrpc_get_blk block: detach bdev inode from its wb in __blkdev_put() SCSI: Fix NULL pointer dereference in runtime PM | 12 December 2015, 18:24:00 UTC |
6539756 | Linus Torvalds | 12 December 2015, 18:16:26 UTC | Merge tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux Pull arm64 fixes from Catalin Marinas: - Update the linker script to use L1_CACHE_BYTES instead of hard-coded 64. We recently changed L1_CACHE_BYTES to 128 - Improve race condition reporting on set_pte_at() and change the BUG to WARN_ONCE. With hardware update of the accessed/dirty state, we need to ensure that set_pte_at() does not inadvertently override hardware updated state. The patch also makes the checks ignore !pte_valid() new entries * tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux: arm64: Improve error reporting on set_pte_at() checks arm64: update linker script to increased L1_CACHE_BYTES value | 12 December 2015, 18:16:26 UTC |
9530d0f | Qais Yousef | 11 December 2015, 21:41:09 UTC | MIPS: fix DMA contiguous allocation Recent changes to how GFP_ATOMIC is defined seems to have broken the condition to use mips_alloc_from_contiguous() in mips_dma_alloc_coherent(). I couldn't bottom out the exact change but I think it's this commit d0164adc89f6 ("mm, page_alloc: distinguish between being unable to sleep, unwilling to sleep and avoiding waking kswapd"). GFP_ATOMIC has multiple bits set and the check for !(gfp & GFP_ATOMIC) isn't enough. The reason behind this condition is to check whether we can potentially do a sleeping memory allocation. Use gfpflags_allow_blocking() instead which should be more robust. Signed-off-by: Qais Yousef <qais.yousef@imgtec.com> Acked-by: Mel Gorman <mgorman@techsingularity.net> Cc: Ralf Baechle <ralf@linux-mips.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> | 12 December 2015, 18:15:34 UTC |
2d33fa1 | Dmitry V. Levin | 11 December 2015, 21:41:06 UTC | sh64: fix __NR_fgetxattr According to arch/sh/kernel/syscalls_64.S and common sense, __NR_fgetxattr has to be defined to 259, but it doesn't. Instead, it's defined to 269, which is of course used by another syscall, __NR_sched_setaffinity in this case. This bug was found by strace test suite. Signed-off-by: Dmitry V. Levin <ldv@altlinux.org> Acked-by: Geert Uytterhoeven <geert+renesas@glider.be> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> | 12 December 2015, 18:15:34 UTC |
854ee2e | Junxiao Bi | 11 December 2015, 21:41:03 UTC | ocfs2: fix SGID not inherited issue Commit 8f1eb48758aa ("ocfs2: fix umask ignored issue") introduced an issue, SGID of sub dir was not inherited from its parents dir. It is because SGID is set into "inode->i_mode" in ocfs2_get_init_inode(), but is overwritten by "mode" which don't have SGID set later. Fixes: 8f1eb48758aa ("ocfs2: fix umask ignored issue") Signed-off-by: Junxiao Bi <junxiao.bi@oracle.com> Cc: Mark Fasheh <mfasheh@suse.de> Cc: Joel Becker <jlbec@evilplan.org> Acked-by: Srinivas Eeda <srinivas.eeda@oracle.com> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> | 12 December 2015, 18:15:34 UTC |
a2b829d | Chen Jie | 11 December 2015, 21:41:00 UTC | mm/oom_kill.c: avoid attempting to kill init sharing same memory It's possible that an oom killed victim shares an ->mm with the init process and thus oom_kill_process() would end up trying to kill init as well. This has been shown in practice: Out of memory: Kill process 9134 (init) score 3 or sacrifice child Killed process 9134 (init) total-vm:1868kB, anon-rss:84kB, file-rss:572kB Kill process 1 (init) sharing same memory ... Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000009 And this will result in a kernel panic. If a process is forked by init and selected for oom kill while still sharing init_mm, then it's likely this system is in a recoverable state. However, it's better not to try to kill init and allow the machine to panic due to unkillable processes. [rientjes@google.com: rewrote changelog] [akpm@linux-foundation.org: fix inverted test, per Ben] Signed-off-by: Chen Jie <chenjie6@huawei.com> Signed-off-by: David Rientjes <rientjes@google.com> Acked-by: Michal Hocko <mhocko@suse.com> Acked-by: Hillf Danton <hillf.zj@alibaba-inc.com> Cc: Ben Hutchings <ben@decadent.org.uk> Cc: Li Zefan <lizefan@huawei.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> | 12 December 2015, 18:15:34 UTC |
26bbe7e | Seth Jennings | 11 December 2015, 21:40:57 UTC | drivers/base/memory.c: prohibit offlining of memory blocks with missing sections Commit bdee237c0343 ("x86: mm: Use 2GB memory block size on large-memory x86-64 systems") and 982792c782ef ("x86, mm: probe memory block size for generic x86 64bit") introduced large block sizes for x86. This made it possible to have multiple sections per memory block where previously, there was a only every one section per block. Since blocks consist of contiguous ranges of section, there can be holes in the blocks where sections are not present. If one attempts to offline such a block, a crash occurs since the code is not designed to deal with this. This patch is a quick fix to gaurd against the crash by not allowing blocks with non-present sections to be offlined. Addresses https://bugzilla.kernel.org/show_bug.cgi?id=107781 Signed-off-by: Seth Jennings <sjennings@variantweb.net> Reported-by: Andrew Banman <abanman@sgi.com> Cc: Daniel J Blueman <daniel@numascale.com> Cc: Yinghai Lu <yinghai@kernel.org> Cc: Greg KH <greg@kroah.com> Cc: Russ Anderson <rja@sgi.com> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> | 12 December 2015, 18:15:34 UTC |
267a4c7 | Hugh Dickins | 11 December 2015, 21:40:55 UTC | tmpfs: fix shmem_evict_inode() warnings on i_blocks Dmitry Vyukov provides a little program, autogenerated by syzkaller, which races a fault on a mapping of a sparse memfd object, against truncation of that object below the fault address: run repeatedly for a few minutes, it reliably generates shmem_evict_inode()'s WARN_ON(inode->i_blocks). (But there's nothing specific to memfd here, nor to the fstat which it happened to use to generate the fault: though that looked suspicious, since a shmem_recalc_inode() had been added there recently. The same problem can be reproduced with open+unlink in place of memfd_create, and with fstatfs in place of fstat.) v3.7 commit 0f3c42f522dc ("tmpfs: change final i_blocks BUG to WARNING") explains one cause of such a warning (a race with shmem_writepage to swap), and possible solutions; but we never took it further, and this syzkaller incident turns out to have a different cause. shmem_getpage_gfp()'s error recovery, when a freshly allocated page is then found to be beyond eof, looks plausible - decrementing the alloced count that was just before incremented - but in fact can go wrong, if a racing thread (the truncator, for example) gets its shmem_recalc_inode() in just after our delete_from_page_cache(). delete_from_page_cache() decrements nrpages, that shmem_recalc_inode() will balance the books by decrementing alloced itself, then our decrement of alloced take it one too low: leading to the WARNING when the object is finally evicted. Once the new page has been exposed in the page cache, shmem_getpage_gfp() must leave it to shmem_recalc_inode() itself to get the accounting right in all cases (and not fall through from "trunc:" to "decused:"). Adjust that error recovery block; and the reinitialization of info and sbinfo can be removed too. While we're here, fix shmem_writepage() to avoid the original issue: it will be safe against a racing shmem_recalc_inode(), if it merely increments swapped before the shmem_delete_from_page_cache() which decrements nrpages (but it must then do its own shmem_recalc_inode() before that, while still in balance, instead of after). (Aside: why do we shmem_recalc_inode() here in the swap path? Because its raison d'etre is to cope with clean sparse shmem pages being reclaimed behind our back: so here when swapping is a good place to look for that case.) But I've not now managed to reproduce this bug, even without the patch. I don't see why I didn't do that earlier: perhaps inhibited by the preference to eliminate shmem_recalc_inode() altogether. Driven by this incident, I do now have a patch to do so at last; but still want to sit on it for a bit, there's a couple of questions yet to be resolved. Signed-off-by: Hugh Dickins <hughd@google.com> Reported-by: Dmitry Vyukov <dvyukov@google.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> | 12 December 2015, 18:15:34 UTC |
dbe409e | Mike Kravetz | 11 December 2015, 21:40:52 UTC | mm/hugetlb.c: fix resv map memory leak for placeholder entries Dmitry Vyukov reported the following memory leak unreferenced object 0xffff88002eaafd88 (size 32): comm "a.out", pid 5063, jiffies 4295774645 (age 15.810s) hex dump (first 32 bytes): 28 e9 4e 63 00 88 ff ff 28 e9 4e 63 00 88 ff ff (.Nc....(.Nc.... 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: kmalloc include/linux/slab.h:458 region_chg+0x2d4/0x6b0 mm/hugetlb.c:398 __vma_reservation_common+0x2c3/0x390 mm/hugetlb.c:1791 vma_needs_reservation mm/hugetlb.c:1813 alloc_huge_page+0x19e/0xc70 mm/hugetlb.c:1845 hugetlb_no_page mm/hugetlb.c:3543 hugetlb_fault+0x7a1/0x1250 mm/hugetlb.c:3717 follow_hugetlb_page+0x339/0xc70 mm/hugetlb.c:3880 __get_user_pages+0x542/0xf30 mm/gup.c:497 populate_vma_page_range+0xde/0x110 mm/gup.c:919 __mm_populate+0x1c7/0x310 mm/gup.c:969 do_mlock+0x291/0x360 mm/mlock.c:637 SYSC_mlock2 mm/mlock.c:658 SyS_mlock2+0x4b/0x70 mm/mlock.c:648 Dmitry identified a potential memory leak in the routine region_chg, where a region descriptor is not free'ed on an error path. However, the root cause for the above memory leak resides in region_del. In this specific case, a "placeholder" entry is created in region_chg. The associated page allocation fails, and the placeholder entry is left in the reserve map. This is "by design" as the entry should be deleted when the map is released. The bug is in the region_del routine which is used to delete entries within a specific range (and when the map is released). region_del did not handle the case where a placeholder entry exactly matched the start of the range range to be deleted. In this case, the entry would not be deleted and leaked. The fix is to take these special placeholder entries into account in region_del. The region_chg error path leak is also fixed. Fixes: feba16e25a57 ("mm/hugetlb: add region_del() to delete a specific range of entries") Signed-off-by: Mike Kravetz <mike.kravetz@oracle.com> Reported-by: Dmitry Vyukov <dvyukov@google.com> Acked-by: Hillf Danton <hillf.zj@alibaba-inc.com> Cc: <stable@vger.kernel.org> [4.3+] Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> | 12 December 2015, 18:15:34 UTC |
0d777df | Naoya Horiguchi | 11 December 2015, 21:40:49 UTC | mm: hugetlb: call huge_pte_alloc() only if ptep is null Currently at the beginning of hugetlb_fault(), we call huge_pte_offset() and check whether the obtained *ptep is a migration/hwpoison entry or not. And if not, then we get to call huge_pte_alloc(). This is racy because the *ptep could turn into migration/hwpoison entry after the huge_pte_offset() check. This race results in BUG_ON in huge_pte_alloc(). We don't have to call huge_pte_alloc() when the huge_pte_offset() returns non-NULL, so let's fix this bug with moving the code into else block. Note that the *ptep could turn into a migration/hwpoison entry after this block, but that's not a problem because we have another !pte_present check later (we never go into hugetlb_no_page() in that case.) Fixes: 290408d4a250 ("hugetlb: hugepage migration core") Signed-off-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com> Acked-by: Hillf Danton <hillf.zj@alibaba-inc.com> Acked-by: David Rientjes <rientjes@google.com> Cc: Hugh Dickins <hughd@google.com> Cc: Dave Hansen <dave.hansen@intel.com> Cc: Mel Gorman <mgorman@suse.de> Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com> Cc: Mike Kravetz <mike.kravetz@oracle.com> Cc: <stable@vger.kernel.org> [2.6.36+] Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> | 12 December 2015, 18:15:34 UTC |
86fffe4 | Chris Wilson | 11 December 2015, 21:40:46 UTC | kernel: remove stop_machine() Kconfig dependency Currently the full stop_machine() routine is only enabled on SMP if module unloading is enabled, or if the CPUs are hotpluggable. This leads to configurations where stop_machine() is broken as it will then only run the callback on the local CPU with irqs disabled, and not stop the other CPUs or run the callback on them. For example, this breaks MTRR setup on x86 in certain configs since ea8596bb2d8d379 ("kprobes/x86: Remove unused text_poke_smp() and text_poke_smp_batch() functions") as the MTRR is only established on the boot CPU. This patch removes the Kconfig option for STOP_MACHINE and uses the SMP and HOTPLUG_CPU config options to compile the correct stop_machine() for the architecture, removing the false dependency on MODULE_UNLOAD in the process. Link: https://lkml.org/lkml/2014/10/8/124 References: https://bugs.freedesktop.org/show_bug.cgi?id=84794 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Ingo Molnar <mingo@kernel.org> Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> Cc: Pranith Kumar <bobby.prani@gmail.com> Cc: Michal Hocko <mhocko@suse.cz> Cc: Vladimir Davydov <vdavydov@parallels.com> Cc: Johannes Weiner <hannes@cmpxchg.org> Cc: H. Peter Anvin <hpa@linux.intel.com> Cc: Tejun Heo <tj@kernel.org> Cc: Iulia Manda <iulia.manda21@gmail.com> Cc: Andy Lutomirski <luto@amacapital.net> Cc: Rusty Russell <rusty@rustcorp.com.au> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Chuck Ebbert <cebbert.lkml@gmail.com> Cc: Oleg Nesterov <oleg@redhat.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> | 12 December 2015, 18:15:34 UTC |
98e89cf | Nicolas Iooss | 11 December 2015, 21:40:43 UTC | mm: kmemleak: mark kmemleak_init prototype as __init The kmemleak_init() definition in mm/kmemleak.c is marked __init but its prototype in include/linux/kmemleak.h is marked __ref since commit a6186d89c913 ("kmemleak: Mark the early log buffer as __initdata"). This causes a section mismatch which is reported as a warning when building with clang -Wsection, because kmemleak_init() is declared in section .ref.text but defined in .init.text. Fix this by marking kmemleak_init() prototype __init. Signed-off-by: Nicolas Iooss <nicolas.iooss_linux@m4x.org> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> | 12 December 2015, 18:15:34 UTC |
25be6a6 | Hugh Dickins | 11 December 2015, 21:40:40 UTC | mm: fix kerneldoc on mem_cgroup_replace_page Whoops, I missed removing the kerneldoc comment of the lrucare arg removed from mem_cgroup_replace_page; but it's a good comment, keep it. Signed-off-by: Hugh Dickins <hughd@google.com> Acked-by: Michal Hocko <mhocko@suse.com> Acked-by: Johannes Weiner <hannes@cmpxchg.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> | 12 December 2015, 18:15:34 UTC |
3066a96 | Hugh Dickins | 11 December 2015, 21:40:38 UTC | osd fs: __r4w_get_page rely on PageUptodate for uptodate Commit 42cb14b110a5 ("mm: migrate dirty page without clear_page_dirty_for_io etc") simplified the migration of a PageDirty pagecache page: one stat needs moving from zone to zone and that's about all. It's convenient and safest for it to shift the PageDirty bit from old page to new, just before updating the zone stats: before copying data and marking the new PageUptodate. This is all done while both pages are isolated and locked, just as before; and just as before, there's a moment when the new page is visible in the radix_tree, but not yet PageUptodate. What's new is that it may now be briefly visible as PageDirty before it is PageUptodate. When I scoured the tree to see if this could cause a problem anywhere, the only places I found were in two similar functions __r4w_get_page(): which look up a page with find_get_page() (not using page lock), then claim it's uptodate if it's PageDirty or PageWriteback or PageUptodate. I'm not sure whether that was right before, but now it might be wrong (on rare occasions): only claim the page is uptodate if PageUptodate. Or perhaps the page in question could never be migratable anyway? Signed-off-by: Hugh Dickins <hughd@google.com> Tested-by: Boaz Harrosh <ooo@electrozaur.com> Cc: Benny Halevy <bhalevy@panasas.com> Cc: Trond Myklebust <trond.myklebust@primarydata.com> Cc: Christoph Lameter <cl@linux.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> | 12 December 2015, 18:15:34 UTC |
ed0f1e2 | Johannes Weiner | 11 December 2015, 21:40:35 UTC | MAINTAINERS: make Vladimir co-maintainer of the memory controller Vladimir architected and authored much of the current state of the memcg's slab memory accounting and tracking. Make sure he gets CC'd on bug reports ;-) Signed-off-by: Johannes Weiner <hannes@cmpxchg.org> Acked-by: Vladimir Davydov <vdavydov@virtuozzo.com> Acked-by: Michal Hocko <mhocko@suse.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> | 12 December 2015, 18:15:34 UTC |
373ccbe | Michal Hocko | 11 December 2015, 21:40:32 UTC | mm, vmstat: allow WQ concurrency to discover memory reclaim doesn't make any progress Tetsuo Handa has reported that the system might basically livelock in OOM condition without triggering the OOM killer. The issue is caused by internal dependency of the direct reclaim on vmstat counter updates (via zone_reclaimable) which are performed from the workqueue context. If all the current workers get assigned to an allocation request, though, they will be looping inside the allocator trying to reclaim memory but zone_reclaimable can see stalled numbers so it will consider a zone reclaimable even though it has been scanned way too much. WQ concurrency logic will not consider this situation as a congested workqueue because it relies that worker would have to sleep in such a situation. This also means that it doesn't try to spawn new workers or invoke the rescuer thread if the one is assigned to the queue. In order to fix this issue we need to do two things. First we have to let wq concurrency code know that we are in trouble so we have to do a short sleep. In order to prevent from issues handled by 0e093d99763e ("writeback: do not sleep on the congestion queue if there are no congested BDIs or if significant congestion is not being encountered in the current zone") we limit the sleep only to worker threads which are the ones of the interest anyway. The second thing to do is to create a dedicated workqueue for vmstat and mark it WQ_MEM_RECLAIM to note it participates in the reclaim and to have a spare worker thread for it. Signed-off-by: Michal Hocko <mhocko@suse.com> Reported-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Cc: Tejun Heo <tj@kernel.org> Cc: Cristopher Lameter <clameter@sgi.com> Cc: Joonsoo Kim <js1304@gmail.com> Cc: Arkadiusz Miskiewicz <arekm@maven.pl> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> | 12 December 2015, 18:15:34 UTC |
475a2f9 | Vlastimil Babka | 11 December 2015, 21:40:29 UTC | mm: fix swapped Movable and Reclaimable in /proc/pagetypeinfo Commit 016c13daa5c9 ("mm, page_alloc: use masks and shifts when converting GFP flags to migrate types") has swapped MIGRATE_MOVABLE and MIGRATE_RECLAIMABLE in the enum definition. However, migratetype_names wasn't updated to reflect that. As a result, the file /proc/pagetypeinfo shows the counts for Movable as Reclaimable and vice versa. Additionally, commit 0aaa29a56e4f ("mm, page_alloc: reserve pageblocks for high-order atomic allocations on demand") introduced MIGRATE_HIGHATOMIC, but did not add a letter to distinguish it into show_migration_types(), so it doesn't appear in the listing of free areas during page alloc failures or oom kills. This patch fixes both problems. The atomic reserves will show with a letter 'H' in the free areas listings. Fixes: 016c13daa5c9 ("mm, page_alloc: use masks and shifts when converting GFP flags to migrate types") Fixes: 0aaa29a56e4f ("mm, page_alloc: reserve pageblocks for high-order atomic allocations on demand") Signed-off-by: Vlastimil Babka <vbabka@suse.cz> Acked-by: Mel Gorman <mgorman@suse.de> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> | 12 December 2015, 18:15:34 UTC |
9516a18 | Vladimir Davydov | 11 December 2015, 21:40:24 UTC | memcg: fix memory.high target When the memory.high threshold is exceeded, try_charge() schedules a task_work to reclaim the excess. The reclaim target is set to the number of pages requested by try_charge(). This is wrong, because try_charge() usually charges more pages than requested (batch > nr_pages) in order to refill per cpu stocks. As a result, a process in a cgroup can easily exceed memory.high significantly when doing a lot of charges w/o returning to userspace (e.g. reading a file in big chunks). Fix this issue by assuring that when exceeding memory.high a process reclaims as many pages as were actually charged (i.e. batch). Signed-off-by: Vladimir Davydov <vdavydov@virtuozzo.com> Acked-by: Johannes Weiner <hannes@cmpxchg.org> Acked-by: Michal Hocko <mhocko@suse.com> Cc: Tejun Heo <tj@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> | 12 December 2015, 18:15:34 UTC |
a88c769 | Naoya Horiguchi | 11 December 2015, 21:40:24 UTC | mm: hugetlb: fix hugepage memory leak caused by wrong reserve count When dequeue_huge_page_vma() in alloc_huge_page() fails, we fall back on alloc_buddy_huge_page() to directly create a hugepage from the buddy allocator. In that case, however, if alloc_buddy_huge_page() succeeds we don't decrement h->resv_huge_pages, which means that successful hugetlb_fault() returns without releasing the reserve count. As a result, subsequent hugetlb_fault() might fail despite that there are still free hugepages. This patch simply adds decrementing code on that code path. I reproduced this problem when testing v4.3 kernel in the following situation: - the test machine/VM is a NUMA system, - hugepage overcommiting is enabled, - most of hugepages are allocated and there's only one free hugepage which is on node 0 (for example), - another program, which calls set_mempolicy(MPOL_BIND) to bind itself to node 1, tries to allocate a hugepage, - the allocation should fail but the reserve count is still hold. Signed-off-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com> Cc: David Rientjes <rientjes@google.com> Cc: Dave Hansen <dave.hansen@intel.com> Cc: Mel Gorman <mgorman@suse.de> Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com> Cc: Hillf Danton <hillf.zj@alibaba-inc.com> Cc: Mike Kravetz <mike.kravetz@oracle.com> Cc: <stable@vger.kernel.org> [3.16+] Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> | 12 December 2015, 18:15:34 UTC |
78c0cbf | Helge Deller | 06 December 2015, 20:25:20 UTC | parisc: Disable huge pages on Mako machines Mako-based machines (PA8800 and PA8900 CPUs) don't allow aliasing on non-equaivalent addresses. Signed-off-by: Helge Deller <deller@gmx.de> | 12 December 2015, 15:45:23 UTC |
5c477b4 | Helge Deller | 06 December 2015, 20:56:26 UTC | parisc: Wire up mlock2 syscall Signed-off-by: Helge Deller <deller@gmx.de> | 12 December 2015, 15:07:44 UTC |
5f0e9b4 | Bjorn Helgaas | 01 December 2015, 16:41:47 UTC | parisc: Remove unused pcibios_init_bus() There are no callers of pcibios_init_bus(), so remove it. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Helge Deller <deller@gmx.de> | 12 December 2015, 15:07:35 UTC |
e46e31a | Mikulas Patocka | 30 November 2015, 19:47:46 UTC | parisc iommu: fix panic due to trying to allocate too large region When using the Promise TX2+ SATA controller on PA-RISC, the system often crashes with kernel panic, for example just writing data with the dd utility will make it crash. Kernel panic - not syncing: drivers/parisc/sba_iommu.c: I/O MMU @ 000000000000a000 is out of mapping resources CPU: 0 PID: 18442 Comm: mkspadfs Not tainted 4.4.0-rc2 #2 Backtrace: [<000000004021497c>] show_stack+0x14/0x20 [<0000000040410bf0>] dump_stack+0x88/0x100 [<000000004023978c>] panic+0x124/0x360 [<0000000040452c18>] sba_alloc_range+0x698/0x6a0 [<0000000040453150>] sba_map_sg+0x260/0x5b8 [<000000000c18dbb4>] ata_qc_issue+0x264/0x4a8 [libata] [<000000000c19535c>] ata_scsi_translate+0xe4/0x220 [libata] [<000000000c19a93c>] ata_scsi_queuecmd+0xbc/0x320 [libata] [<0000000040499bbc>] scsi_dispatch_cmd+0xfc/0x130 [<000000004049da34>] scsi_request_fn+0x6e4/0x970 [<00000000403e95a8>] __blk_run_queue+0x40/0x60 [<00000000403e9d8c>] blk_run_queue+0x3c/0x68 [<000000004049a534>] scsi_run_queue+0x2a4/0x360 [<000000004049be68>] scsi_end_request+0x1a8/0x238 [<000000004049de84>] scsi_io_completion+0xfc/0x688 [<0000000040493c74>] scsi_finish_command+0x17c/0x1d0 The cause of the crash is not exhaustion of the IOMMU space, there is plenty of free pages. The function sba_alloc_range is called with size 0x11000, thus the pages_needed variable is 0x11. The function sba_search_bitmap is called with bits_wanted 0x11 and boundary size is 0x10 (because dma_get_seg_boundary(dev) returns 0xffff). The function sba_search_bitmap attempts to allocate 17 pages that must not cross 16-page boundary - it can't satisfy this requirement (iommu_is_span_boundary always returns true) and fails even if there are many free entries in the IOMMU space. How did it happen that we try to allocate 17 pages that don't cross 16-page boundary? The cause is in the function iommu_coalesce_chunks. This function tries to coalesce adjacent entries in the scatterlist. The function does several checks if it may coalesce one entry with the next, one of those checks is this: if (startsg->length + dma_len > max_seg_size) break; When it finishes coalescing adjacent entries, it allocates the mapping: sg_dma_len(contig_sg) = dma_len; dma_len = ALIGN(dma_len + dma_offset, IOVP_SIZE); sg_dma_address(contig_sg) = PIDE_FLAG | (iommu_alloc_range(ioc, dev, dma_len) << IOVP_SHIFT) | dma_offset; It is possible that (startsg->length + dma_len > max_seg_size) is false (we are just near the 0x10000 max_seg_size boundary), so the funcion decides to coalesce this entry with the next entry. When the coalescing succeeds, the function performs dma_len = ALIGN(dma_len + dma_offset, IOVP_SIZE); And now, because of non-zero dma_offset, dma_len is greater than 0x10000. iommu_alloc_range (a pointer to sba_alloc_range) is called and it attempts to allocate 17 pages for a device that must not cross 16-page boundary. To fix the bug, we must make sure that dma_len after addition of dma_offset and alignment doesn't cross the segment boundary. I.e. change if (startsg->length + dma_len > max_seg_size) break; to if (ALIGN(dma_len + dma_offset + startsg->length, IOVP_SIZE) > max_seg_size) break; This patch makes this change (it precalculates max_seg_boundary at the beginning of the function iommu_coalesce_chunks). I also added a check that the mapping length doesn't exceed dma_get_seg_boundary(dev) (it is not needed for Promise TX2+ SATA, but it may be needed for other devices that have dma_get_seg_boundary lower than dma_get_max_seg_size). Signed-off-by: Mikulas Patocka <mpatocka@redhat.com> Cc: stable@vger.kernel.org Signed-off-by: Helge Deller <deller@gmx.de> | 12 December 2015, 15:07:25 UTC |
7f4c977 | Kevin Hilman | 12 December 2015, 00:14:34 UTC | Merge tag 'imx-fixes-4.4-2' of git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux into fixes Merge "ARM: imx: fixes for 4.4, 2nd round" from Shawn Guo: The i.MX fixes for 4.4, 2nd round: - Fix vf610 SAI clock configuration bug which is discovered by the newly added master mode support in SAI audio driver. - Fix buggy L2 cache latency values in vf610 device trees, which may cause system hang when cpu runs at a higher frequency. * tag 'imx-fixes-4.4-2' of git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux: ARM: dts: vf610: use reset values for L2 cache latencies ARM: dts: vf610: fix clock definition for SAI2 ARM: imx: clk-vf610: fix SAI clock tree | 12 December 2015, 00:14:34 UTC |
6534778 | Liu Gang | 04 December 2015, 22:55:05 UTC | ls2080a/dts: Add little endian property for GPIO IP block The GPIO block for ls2080a platform has little endian registers, the GPIO driver needs this property to read/write registers by right interface. Signed-off-by: Liu Gang <Gang.Liu@freescale.com> Signed-off-by: Li Yang <leoli@freescale.com> Signed-off-by: Kevin Hilman <khilman@linaro.org> | 12 December 2015, 00:13:03 UTC |
edb70e2 | Li Yang | 04 December 2015, 22:55:04 UTC | dt-bindings: define little-endian property for QorIQ GPIO The GPIO block on different QorIQ chips could have registers in different endianess. Define the property to specify which endian is used by the hardware. Signed-off-by: Liu Gang <Gang.Liu@freescale.com> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Li Yang <leoli@freescale.com> Signed-off-by: Kevin Hilman <khilman@linaro.org> | 12 December 2015, 00:13:02 UTC |
2dd2e4d | yangbo lu | 04 December 2015, 22:55:03 UTC | ARM64: dts: ls2080a: fix eSDHC endianness Add the "little-endian" property to fix the issue that eSDHC is not working and dumping out "mmc0: Controller never released inhibit bit(s)." error messages constantly. Fixes: 5461597f6ce0 ("dts/ls2080a: Update DTSI to add support of various peripherals") Signed-off-by: Yangbo Lu <yangbo.lu@freescale.com> Signed-off-by: Li Yang <leoli@freescale.com> Signed-off-by: Kevin Hilman <khilman@linaro.org> | 12 December 2015, 00:13:02 UTC |
ad87e03 | Alan Stern | 10 December 2015, 20:27:21 UTC | USB: add quirk for devices with broken LPM Some USB device / host controller combinations seem to have problems with Link Power Management. For example, Steinar found that his xHCI controller wouldn't handle bandwidth calculations correctly for two video cards simultaneously when LPM was enabled, even though the bus had plenty of bandwidth available. This patch introduces a new quirk flag for devices that should remain disabled for LPM, and creates quirk entries for Steinar's devices. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Reported-by: Steinar H. Gunderson <sgunderson@bigfoot.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> | 11 December 2015, 23:40:51 UTC |
f69115f | Mathias Nyman | 11 December 2015, 12:38:06 UTC | xhci: fix usb2 resume timing and races. According to USB 2 specs ports need to signal resume for at least 20ms, in practice even longer, before moving to U0 state. Both host and devices can initiate resume. On device initiated resume, a port status interrupt with the port in resume state in issued. The interrupt handler tags a resume_done[port] timestamp with current time + USB_RESUME_TIMEOUT, and kick roothub timer. Root hub timer requests for port status, finds the port in resume state, checks if resume_done[port] timestamp passed, and set port to U0 state. On host initiated resume, current code sets the port to resume state, sleep 20ms, and finally sets the port to U0 state. This should also be changed to work in a similar way as the device initiated resume, with timestamp tagging, but that is not yet tested and will be a separate fix later. There are a few issues with this approach 1. A host initiated resume will also generate a resume event. The event handler will find the port in resume state, believe it's a device initiated resume, and act accordingly. 2. A port status request might cut the resume signalling short if a get_port_status request is handled during the host resume signalling. The port will be found in resume state. The timestamp is not set leading to time_after_eq(jiffies, timestamp) returning true, as timestamp = 0. get_port_status will proceed with moving the port to U0. 3. If an error, or anything else happens to the port during device initiated resume signalling it will leave all the device resume parameters hanging uncleared, preventing further suspend, returning -EBUSY, and cause the pm thread to busyloop trying to enter suspend. Fix this by using the existing resuming_ports bitfield to indicate that resume signalling timing is taken care of. Check if the resume_done[port] is set before using it for timestamp comparison, and also clear out any resume signalling related variables if port is not in U0 or Resume state This issue was discovered when a PM thread busylooped, trying to runtime suspend the xhci USB 2 roothub on a Dell XPS Cc: stable <stable@vger.kernel.org> Reported-by: Daniel J Blueman <daniel@quora.org> Tested-by: Daniel J Blueman <daniel@quora.org> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> | 11 December 2015, 23:40:51 UTC |
b9d8545 | Linus Torvalds | 11 December 2015, 19:00:30 UTC | Merge tag 'dm-4.4-fixes-2' of git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm Pull device mapper fixes from Mike Snitzer: "Five stable fixes: - Two DM btree bufio buffer leak fixes that resolve reported BUG_ONs during DM thinp metadata close's dm_bufio_client_destroy(). - A DM thinp range discard fix to handle discarding a partially mapped range. - A DM thinp metadata snapshot fix to make sure the btree roots saved in the metadata snapshot are the most current. - A DM space map metadata refcounting fix that improves both DM thinp and DM cache metadata" * tag 'dm-4.4-fixes-2' of git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm: dm btree: fix bufio buffer leaks in dm_btree_del() error path dm space map metadata: fix ref counting bug when bootstrapping a new space map dm thin metadata: fix bug when taking a metadata snapshot dm thin metadata: fix bug in dm_thin_remove_range() dm btree: fix leak of bufio-backed block in btree_split_sibling error path | 11 December 2015, 19:00:30 UTC |
732c4a9 | Linus Torvalds | 11 December 2015, 18:56:41 UTC | Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/fuse Pull fuse fixes from Miklos Szeredi: "Two bugfixes, both bound for -stable" * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/fuse: fuse: break infinite loop in fuse_fill_write_pages() cuse: fix memory leak | 11 December 2015, 18:56:41 UTC |
4be460d | Linus Torvalds | 11 December 2015, 18:51:02 UTC | Merge branch 'drm-fixes' of git://people.freedesktop.org/~airlied/linux Pull drm fixes from Dave Airlie: "Not too much this time. - One nouveau workaround extended to a few more GPUs - Some amdgpu big endian fixes, and a regression fixer - Some vmwgfx fixes - One ttm locking fix - One vgaarb fix" * 'drm-fixes' of git://people.freedesktop.org/~airlied/linux: vgaarb: fix signal handling in vga_get() radeon: Fix VCE IB test on Big-Endian systems radeon: Fix VCE ring test for Big-Endian systems radeon/cik: Fix GFX IB test on Big-Endian drm/amdgpu: fix the lost duplicates checking drm/nouveau/pmu: remove whitelist for PGOB-exit WAR, enable by default drm/vmwgfx: Implement the cursor_set2 callback v2 drm/vmwgfx: fix a warning message drm/ttm: Fixed a read/write lock imbalance | 11 December 2015, 18:51:02 UTC |
82d3400 | Catalin Marinas | 08 December 2015, 17:39:15 UTC | arm64: Improve error reporting on set_pte_at() checks Currently the BUG_ON() checks do not give enough information about the PTEs being set. This patch changes BUG_ON to WARN_ONCE and dumps the values of the old and new PTEs. In addition, the checks are only made if the new PTE entry is valid. Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Reported-by: Ming Lei <tom.leiming@gmail.com> Cc: Will Deacon <will.deacon@arm.com> | 11 December 2015, 15:44:24 UTC |
9c17190 | Stefan Agner | 01 December 2015, 01:59:26 UTC | ARM: dts: vf610: use reset values for L2 cache latencies Linux on Vybrid used several different L2 latencies so far, none of them seem to be the right ones. According to the application note AN4947 ("Understanding Vybrid Architecture"), the tag portion runs on CPU clock and is inside the L2 cache controller, whereas the data portion is stored in the external SRAM running on platform clock. Hence it is likely that the correct value requires a higher data latency then tag latency. These are the values which have been used so far: - The mainline values: arm,data-latency = <1 1 1>; arm,tag-latency = <2 2 2>; Those values have lead to problems on higher clocks. They look like a poor translation from the reset values (missing +1 offset and a mix up between tag/latency values). - The Linux 3.0 (SoC vendor BSP) values (converted to DT notation): arm,data-latency = <4 2 3> arm,tag-latency = <4 2 3> The cache initialization function along with the value matches the i.MX6 code from the same kernel, so it seems that those values have just been copied. - The Colibri values: arm,data-latency = <2 1 2>; arm,tag-latency = <3 2 3>; Those were a mix between the values of the Linux 3.0 based BSP and the mainline values above. - The SoC Reset values (converted to DT notation): arm,data-latency = <3 3 3>; arm,tag-latency = <2 2 2>; So far there is no official statement on what the correct values are. See also the related Freescale community thread: https://community.freescale.com/message/579785#579785 For now, the reset values seem to be the best bet. Remove all other "bogus" values and use the reset value on vf610.dtsi level. Signed-off-by: Stefan Agner <stefan@agner.ch> Cc: <stable@vger.kernel.org> Signed-off-by: Shawn Guo <shawnguo@kernel.org> | 11 December 2015, 13:32:47 UTC |
9f5bd30 | Kirill A. Shutemov | 30 November 2015, 02:17:31 UTC | vgaarb: fix signal handling in vga_get() There are few defects in vga_get() related to signal hadning: - we shouldn't check for pending signals for TASK_UNINTERRUPTIBLE case; - if we found pending signal we must remove ourself from wait queue and change task state back to running; - -ERESTARTSYS is more appropriate, I guess. Signed-off-by: Kirill A. Shutemov <kirill@shutemov.name> Cc: stable@vger.kernel.org Reviewed-by: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com> | 11 December 2015, 04:04:44 UTC |
49307da | Dave Airlie | 11 December 2015, 04:04:09 UTC | Merge branch 'drm-fixes-4.4' of git://people.freedesktop.org/~agd5f/linux into drm-fixes some big endian fixes and one regression fix. * 'drm-fixes-4.4' of git://people.freedesktop.org/~agd5f/linux: radeon: Fix VCE IB test on Big-Endian systems radeon: Fix VCE ring test for Big-Endian systems radeon/cik: Fix GFX IB test on Big-Endian drm/amdgpu: fix the lost duplicates checking | 11 December 2015, 04:04:09 UTC |
dde8fdc | Arnd Bergmann | 10 December 2015, 23:42:22 UTC | Merge tag 'omap-for-v4.4/fixes-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into fixes Merge "omap fixes against v4.4-rc4" from Tony Lindgren Few fixes for omaps for v4.4-rc cycle: - Fix clock source for ARM TWD and global timers on am437x - Always select REGULATOR_FIXED_VOLTAGE for omap2+ instead of when MACH_OMAP3_PANDORA is selected - Fix SPI DMA handles for dm816x as only some were mapped - Fix up mbox cells for dm816x to make mailbox usable * tag 'omap-for-v4.4/fixes-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap: ARM: dts: am4372: fix clock source for arm twd and global timers ARM: OMAP2+: enable REGULATOR_FIXED_VOLTAGE ARM: dts: add dm816x missing spi DT dma handles ARM: dts: add dm816x missing #mbox-cells | 10 December 2015, 23:42:38 UTC |
ddd47fb | Arnd Bergmann | 09 December 2015, 14:11:12 UTC | ARM: pxa: use PWM lookup table for all machines The recent change to use a pwm lookup table for the ezx machines was incomplete and only changed the a780 model, but not the other ones in the same file. This adds the missing calls to pwm_add_table(). Signed-off-by: Arnd Bergmann <arnd@arndb.de> Fixes: c3322022897c ("ARM: pxa: ezx: Use PWM lookup table") Acked-by: Thierry Reding <thierry.reding@gmail.com> Acked-by: Robert Jarzmik <robert.jarzmik@free.fr> | 10 December 2015, 23:27:58 UTC |
e229213 | Arnd Bergmann | 10 December 2015, 23:24:38 UTC | Merge tag 'berlin-fixes-for-4.4-rc1-1' of git://git.infradead.org/users/hesselba/linux-berlin into fixes Merge "Marvell Berlin fixes for 4.4-rc1 (round 1)" from Sebastian Hesselbarth: - fix wrong SDIO DT clocks on BG2Q * tag 'berlin-fixes-for-4.4-rc1-1' of git://git.infradead.org/users/hesselba/linux-berlin: ARM: dts: berlin: add 2nd clock for BG2Q sdhci0 and sdhci1 ARM: dts: berlin: correct BG2Q's sdhci2 2nd clock | 10 December 2015, 23:24:38 UTC |
9421a14 | Arnd Bergmann | 10 December 2015, 23:22:11 UTC | Merge tag 'at91-4.4-fixes-2' of git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux into fixes Merge "Second fixes for 4.4" from Alexandre Belloni: - fix of a hardware setup that prevents the sd/mmc interface to show up on sama5d2. - proper selection of pinctrl drivers. PIO4 is necessary for the sama5d2 to boot. * tag 'at91-4.4-fixes-2' of git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux: ARM: at91: fix pinctrl driver selection ARM: at91/dt: add always-on to 1.8V regulator | 10 December 2015, 23:22:11 UTC |
789d73b | Arnd Bergmann | 10 December 2015, 23:19:37 UTC | Merge tag 'samsung-fixes-4.4' of https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux into fixes Merge "Fixes for Exynos" from Krzysztof Kozlowski: 1. Fix potential NULL pointer dereference in Exynos PMU driver. 2. Remove incorrect __init annotation from s3c24xx cpufreq driver structures. * tag 'samsung-fixes-4.4' of https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux: cpufreq: s3c24xx: Do not mark s3c2410_plls_add as __init ARM: EXYNOS: Fix potential NULL pointer access in exynos_sys_powerdown_conf | 10 December 2015, 23:19:37 UTC |
0bd0f1e | Linus Torvalds | 10 December 2015, 22:42:22 UTC | Merge tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dledford/rdma Pull rdma fixes from Doug Ledford: "Most are minor to important fixes. There is one performance enhancement that I took on the grounds that failing to check if other processes can run before running what's intended to be a background, idle-time task is a bug, even though the primary effect of the fix is to improve performance (and it was a very simple patch)" * tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dledford/rdma: IB/mlx5: Postpone remove_keys under knowledge of coming preemption IB/mlx4: Use vmalloc for WR buffers when needed IB/mlx4: Use correct order of variables in log message iser-target: Remove explicit mlx4 work-around mlx4: Expose correct max_sge_rd limit IB/mad: Require CM send method for everything except ClassPortInfo IB/cma: Add a missing rcu_read_unlock() IB core: Fix ib_sg_to_pages() IB/srp: Fix srp_map_sg_fr() IB/srp: Fix indirect data buffer rkey endianness IB/srp: Initialize dma_length in srp_map_idb IB/srp: Fix possible send queue overflow IB/srp: Fix a memory leak IB/sa: Put netlink request into the request list before sending IB/iser: use sector_div instead of do_div IB/core: use RCU for uverbs id lookup IB/qib: Minor fixes to qib per SFF 8636 IB/core: Fix user mode post wr corruption IB/qib: Fix qib_mr structure | 10 December 2015, 22:42:22 UTC |
b5010d2 | Jisheng Zhang | 07 December 2015, 13:09:25 UTC | ARM: dts: berlin: add 2nd clock for BG2Q sdhci0 and sdhci1 We removed CLK_IGNORE_UNUSED from CLKID_SDIO's flag, so the sdhci0 and sdhci1 don't work. We fix this by adding the optional 2nd clock for BG2Q's sdhci0 and sdhci1. This patch brings another benefit: the 2nd clock can be disabled during runtime pm, so saves power a bit. Signed-off-by: Jisheng Zhang <jszhang@marvell.com> Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com> | 10 December 2015, 20:00:24 UTC |
5d75614 | Jisheng Zhang | 07 December 2015, 13:09:24 UTC | ARM: dts: berlin: correct BG2Q's sdhci2 2nd clock The optional 2nd clock is CLKID_SDIO. We removed CLK_IGNORE_UNUSED from CLKID_SDIO's flag, so the sdhci2 doesn't work. This patch fixes this issue by correcting the sdhci2's 2nd clock. Signed-off-by: Jisheng Zhang <jszhang@marvell.com> Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com> | 10 December 2015, 20:00:16 UTC |
a80c47d | Linus Torvalds | 10 December 2015, 18:44:32 UTC | Merge tag 'sound-4.4-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound Pull sound fixes from Takashi Iwai: "Again less intensive changes in this rc: you can find only a few HD-audio fixes (noise fixes for Intel Broxton chip and a few Thinkpad models, quirks for Alienware 17 and Packard Bell DOTS) in addition to a long-standing rme96 bug fix" * tag 'sound-4.4-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound: ALSA: hda/ca0132 - quirk for Alienware 17 2015 ALSA: hda - Fix noise problems on Thinkpad T440s ALSA: hda - Fixing speaker noise on the two latest thinkpad models ALSA: hda - Add inverted dmic for Packard Bell DOTS ALSA: hda - Fix playback noise with 24/32 bit sample size on BXT ALSA: rme96: Fix unexpected volume reset after rate changes | 10 December 2015, 18:44:32 UTC |
e2bf3e6 | Linus Walleij | 10 December 2015, 17:21:41 UTC | clocksource: Mmio: remove artificial 32bit limitation The EP93xx is registering a clocksource of 40 bits with clocksource_mmio_init() but this is not working because of this artificial limitation. It works fine to lift the uppe limit to 64 bits, and since cycle_t is u64, it should intuitively have been like that from the beginning. Fixes: 000bc17817bf "ARM: ep93xx: switch to GENERIC_CLOCKEVENTS" Reported-by: Alexander Sverdlin <alexander.sverdlin@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Cc: Daniel Lezcano <daniel.lezcano@linaro.org> Link: http://lkml.kernel.org/r/1449768101-6879-1-git-send-email-linus.walleij@linaro.org Signed-off-by: Thomas Gleixner <tglx@linutronix.de> | 10 December 2015, 18:37:18 UTC |
8e31ed9 | Marc Zyngier | 07 December 2015, 10:11:12 UTC | irqchip/gic-v3: Add missing include for barrier.h Both the 32bit and 64bit versions of the GICv3 header file are using barriers, but neglect to include barrier.h, leading to an interesting splat in some circumstances. Signed-off-by: Marc Zyngier <marc.zyngier@arm.com> Cc: <linux-arm-kernel@lists.infradead.org> Cc: Jason Cooper <jason@lakedaemon.net> Link: http://lkml.kernel.org/r/1449483072-17694-3-git-send-email-marc.zyngier@arm.com Signed-off-by: Thomas Gleixner <tglx@linutronix.de> | 10 December 2015, 18:13:26 UTC |
059393c | Marc Zyngier | 07 December 2015, 10:11:11 UTC | irqchip/gic-v3: Add missing struct device_node declaration When the GICv3 header file is used in a C file that doesn't include any of the OF stuff, we end up with a bunch of ugly warnings. Let's keep GCC quiet by adding a forward declaration. Signed-off-by: Marc Zyngier <marc.zyngier@arm.com> Cc: <linux-arm-kernel@lists.infradead.org> Cc: Jason Cooper <jason@lakedaemon.net> Link: http://lkml.kernel.org/r/1449483072-17694-2-git-send-email-marc.zyngier@arm.com Signed-off-by: Thomas Gleixner <tglx@linutronix.de> | 10 December 2015, 18:13:26 UTC |
ed8b45a | Joe Thornber | 10 December 2015, 14:37:53 UTC | dm btree: fix bufio buffer leaks in dm_btree_del() error path If dm_btree_del()'s call to push_frame() fails, e.g. due to btree_node_validator finding invalid metadata, the dm_btree_del() error path must unlock all frames (which have active dm-bufio buffers) that were pushed onto the del_stack. Otherwise, dm_bufio_client_destroy() will BUG_ON() because dm-bufio buffers have leaked, e.g.: device-mapper: bufio: leaked buffer 3, hold count 1, list 0 Signed-off-by: Joe Thornber <ejt@redhat.com> Signed-off-by: Mike Snitzer <snitzer@redhat.com> Cc: stable@vger.kernel.org | 10 December 2015, 15:30:18 UTC |
6764e5e | Linus Torvalds | 10 December 2015, 00:52:12 UTC | Merge tag 'vfio-v4.4-rc5' of git://github.com/awilliam/linux-vfio Pull VFIO fixes from Alex Williamson: - Various fixes for removing redundancy, const'ifying structs, avoiding stack usage, fixing WARN usage (Krzysztof Kozlowski, Julia Lawall, Kees Cook, Dan Carpenter) - Revert No-IOMMU mode as the intended user has not emerged (Alex Williamson) * tag 'vfio-v4.4-rc5' of git://github.com/awilliam/linux-vfio: Revert: "vfio: Include No-IOMMU mode" vfio: fix a warning message vfio: platform: remove needless stack usage vfio-pci: constify pci_error_handlers structures vfio: Drop owner assignment from platform_driver | 10 December 2015, 00:52:12 UTC |
14054fb | Grygorii Strashko | 30 November 2015, 15:56:38 UTC | ARM: dts: am4372: fix clock source for arm twd and global timers ARM TWD and Global timer are clocked by PERIPHCLK which is MPU_CLK/2. But now they are clocked by dpll_mpu_m2_ck == MPU_CLK and, as result. Timekeeping core misbehaves. For example, execution of command "sleep 5" will take 10 sec instead of 5. Hence, fix it by adding mpu_periphclk ("fixed-factor-clock") and use it for clocking ARM TWD and Global timer (same way as on OMAP4). Cc: Tony Lindgren <tony@atomide.com> Cc: Felipe Balbi <balbi@ti.com> Cc: Tero Kristo <t-kristo@ti.com> Fixes:commit 8cbd4c2f6a99 ("arm: boot: dts: am4372: add ARM timers and SCU nodes") Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com> Reviewed-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com> | 10 December 2015, 00:46:25 UTC |
eef121f | Linus Torvalds | 10 December 2015, 00:44:07 UTC | Merge tag 'devicetree-fixes-for-4.4-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux Pull DT fixes from Rob Herring: "I think this should be all for 4.4: - Fix incorrect warning about overlapping memory regions - Export of_irq_find_parent again which was made static in 4.4, but has users pending for 4.5. - Fix of_msi_map_rid declaration location - Fix re-entrancy for of_fdt_unflatten_tree - Clean-up of phys_addr_t printks" * tag 'devicetree-fixes-for-4.4-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux: of/irq: move of_msi_map_rid declaration to the correct ifdef section of/irq: Export of_irq_find_parent again of/fdt: Add mutex protection for calls to __unflatten_device_tree() of/address: fix typo in comment block of of_translate_one() of: do not use 0x in front of %pa of: Fix comparison of reserved memory regions | 10 December 2015, 00:44:07 UTC |
abb7e2b | Linus Torvalds | 10 December 2015, 00:36:29 UTC | Merge tag 'clk-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux Pull clk fixes from Stephen Boyd: "One small build fix, a couple do_div() fixes, and a fix for the gpio basic clock type are the major changes here. There's also a couple fixes for the TI, sunxi, and scpi clock drivers" * tag 'clk-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux: clk: sunxi: pll2: Fix clock running too fast clk: scpi: add missing of_node_put clk: qoriq: fix memory leak imx/clk-pllv2: fix wrong do_div() usage imx/clk-pllv1: fix wrong do_div() usage clk: mmp: add linux/clk.h includes clk: ti: drop locking code from mux/divider drivers clk: ti816x: Add missing dmtimer clkdev entries clk: ti: fapll: fix wrong do_div() usage clk: ti: clkt_dpll: fix wrong do_div() usage clk: gpio: Get parent clk names in of_gpio_clk_setup() | 10 December 2015, 00:36:29 UTC |
9a0f76f | Linus Torvalds | 09 December 2015, 19:57:10 UTC | Merge tag 'for-linus-4.4-1' of git://git.code.sf.net/p/openipmi/linux-ipmi Pull IPMI fix from Corey Minyard: "Fix an Oops if an interrupt occurs at startup. This can happen on some hardware" * tag 'for-linus-4.4-1' of git://git.code.sf.net/p/openipmi/linux-ipmi: ipmi: move timer init to before irq is setup | 09 December 2015, 19:57:10 UTC |
27f972d | Jan Stancek | 08 December 2015, 18:57:51 UTC | ipmi: move timer init to before irq is setup We encountered a panic on boot in ipmi_si on a dell per320 due to an uninitialized timer as follows. static int smi_start_processing(void *send_info, ipmi_smi_t intf) { /* Try to claim any interrupts. */ if (new_smi->irq_setup) new_smi->irq_setup(new_smi); --> IRQ arrives here and irq handler tries to modify uninitialized timer which triggers BUG_ON(!timer->function) in __mod_timer(). Call Trace: <IRQ> [<ffffffffa0532617>] start_new_msg+0x47/0x80 [ipmi_si] [<ffffffffa053269e>] start_check_enables+0x4e/0x60 [ipmi_si] [<ffffffffa0532bd8>] smi_event_handler+0x1e8/0x640 [ipmi_si] [<ffffffff810f5584>] ? __rcu_process_callbacks+0x54/0x350 [<ffffffffa053327c>] si_irq_handler+0x3c/0x60 [ipmi_si] [<ffffffff810efaf0>] handle_IRQ_event+0x60/0x170 [<ffffffff810f245e>] handle_edge_irq+0xde/0x180 [<ffffffff8100fc59>] handle_irq+0x49/0xa0 [<ffffffff8154643c>] do_IRQ+0x6c/0xf0 [<ffffffff8100ba53>] ret_from_intr+0x0/0x11 /* Set up the timer that drives the interface. */ setup_timer(&new_smi->si_timer, smi_timeout, (long)new_smi); The following patch fixes the problem. To: Openipmi-developer@lists.sourceforge.net To: Corey Minyard <minyard@acm.org> CC: linux-kernel@vger.kernel.org Signed-off-by: Jan Stancek <jstancek@redhat.com> Signed-off-by: Tony Camuso <tcamuso@redhat.com> Signed-off-by: Corey Minyard <cminyard@mvista.com> Cc: stable@vger.kernel.org # Applies cleanly to 3.10-, needs small rework before | 09 December 2015, 19:13:06 UTC |
d7e35df | Sasha Levin | 04 December 2015, 03:04:01 UTC | bitops.h: correctly handle rol32 with 0 byte shift ROL on a 32 bit integer with a shift of 32 or more is undefined and the result is arch-dependent. Avoid this by handling the trivial case of roling by 0 correctly. The trivial solution of checking if shift is 0 breaks gcc's detection of this code as a ROL instruction, which is unacceptable. This bug was reported and fixed in GCC (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57157): The standard rotate idiom, (x << n) | (x >> (32 - n)) is recognized by gcc (for concreteness, I discuss only the case that x is an uint32_t here). However, this is portable C only for n in the range 0 < n < 32. For n == 0, we get x >> 32 which gives undefined behaviour according to the C standard (6.5.7, Bitwise shift operators). To portably support n == 0, one has to write the rotate as something like (x << n) | (x >> ((-n) & 31)) And this is apparently not recognized by gcc. Note that this is broken on older GCCs and will result in slower ROL. Acked-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> | 09 December 2015, 18:35:16 UTC |
50dd842 | Joe Thornber | 09 December 2015, 16:38:12 UTC | dm space map metadata: fix ref counting bug when bootstrapping a new space map When applying block operations (BOPs) do not remove them from the uncommitted BOP ring-buffer until after they've been applied -- in case we recurse. Also, perform BOP_INC operation, in dm_sm_metadata_create() and sm_metadata_extend(), in terms of the uncommitted BOP ring-buffer rather than using direct calls to sm_ll_inc(). Signed-off-by: Joe Thornber <ejt@redhat.com> Signed-off-by: Mike Snitzer <snitzer@redhat.com> Cc: stable@vger.kernel.org | 09 December 2015, 18:27:25 UTC |
49e99fc | Joe Thornber | 09 December 2015, 16:23:24 UTC | dm thin metadata: fix bug when taking a metadata snapshot When you take a metadata snapshot the btree roots for the mapping and details tree need to have their reference counts incremented so they persist for the lifetime of the metadata snap. The roots being incremented were those currently written in the superblock, which could possibly be out of date if concurrent IO is triggering new mappings, breaking of sharing, etc. Fix this by performing a commit with the metadata lock held while taking a metadata snapshot. Signed-off-by: Joe Thornber <ejt@redhat.com> Signed-off-by: Mike Snitzer <snitzer@redhat.com> Cc: stable@vger.kernel.org | 09 December 2015, 18:18:12 UTC |
73b39bb | Greg Kroah-Hartman | 09 December 2015, 18:15:30 UTC | Merge tag 'fixes-for-v4.4-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb into usb-linus Felipe writes: usb: fixes for-v4.4-rc5 Hopefully final set of fixes for v4.4 release cycle. There's a fix for a regression on dwc3 caused by recent changes to how transfers are started. We're not pre-starting interrupt endpoints anymore. A NULL pointer dereference fix for the MSM phy driver. The UVC gadget got a minor fix for permissions to its configfs attributes and, finally, two fixes for MUSB. A fix for PM runtime when MUSB returns EPROBE_DEFER and a fix to actually return an error in case we can't initialize a DMA engine. Signed-off-by: Felipe Balbi <balbi@ti.com> | 09 December 2015, 18:15:30 UTC |
626d114 | Linus Torvalds | 09 December 2015, 17:34:26 UTC | Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs Pull vfs fixes from Al Viro: "A couple of fixes, both -stable fodder (9p one all way back to 2.6.32, dio - to all branches where "Fix negative return from dio read beyond eof" will end up it; it's a fixup to commit marked for -stable)" * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs: fix the regression from "direct-io: Fix negative return from dio read beyond eof" 9p: ->evict_inode() should kick out ->i_data, not ->i_mapping | 09 December 2015, 17:34:26 UTC |
978d6a9 | Linus Torvalds | 09 December 2015, 17:26:06 UTC | Merge tag 'pci-v4.4-fixes-2' of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci Pull PCI fixes from Bjorn Helgaas: "These are more fixes I'd like to have in v4.4. Several for the Altera driver added for v4.4, and one for an MSI domain problem that affects several arm64 platforms: MSI: - Only use the generic MSI layer when domain is hierarchical (Marc Zyngier) Altera host bridge driver: - Fix loop in tlp_read_packet() (Dan Carpenter) - Fix Requester ID for config accesses (Ley Foon Tan) - Check TLP completion status (Ley Foon Tan) - Fix error when INTx is 4 (Ley Foon Tan)" * tag 'pci-v4.4-fixes-2' of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci: PCI: altera: Fix error when INTx is 4 PCI: altera: Check TLP completion status PCI: altera: Fix Requester ID for config accesses PCI: altera: Fix loop in tlp_read_packet() PCI/MSI: Only use the generic MSI layer when domain is hierarchical | 09 December 2015, 17:26:06 UTC |
5328e1e | Gabriele Martino | 09 December 2015, 16:05:58 UTC | ALSA: hda/ca0132 - quirk for Alienware 17 2015 The Alienware 17 (2015) has the same card and pin configuration of the Alienware 15, so the same quirks must be applied. Signed-off-by: Gabriele Martino <g.martino@gmx.com> Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de> | 09 December 2015, 16:06:07 UTC |
7d32cde | Aaro Koskinen | 23 November 2015, 19:50:11 UTC | usb: musb: fail with error when no DMA controller set Fail with error when no DMA controller is set. Signed-off-by: Aaro Koskinen <aaro.koskinen@iki.fi> Signed-off-by: Felipe Balbi <balbi@ti.com> | 09 December 2015, 15:36:03 UTC |
eaddb57 | Rob Herring | 09 December 2015, 15:11:10 UTC | of/irq: move of_msi_map_rid declaration to the correct ifdef section In checking fixes for of_irq_find_parent declaration location, I found that of_msi_map_rid is also wrong. of_msi_map_rid is not implemented for Sparc, so it should not be in the Sparc specific section of the header. Move it to just depend on OF_IRQ. Cc: Frank Rowand <frowand.list@gmail.com> Signed-off-by: Rob Herring <robh@kernel.org> | 09 December 2015, 15:23:28 UTC |
4c3141e | Carlo Caione | 01 December 2015, 16:24:17 UTC | of/irq: Export of_irq_find_parent again of_irq_find_parent was made static since it had no users outside of of_irq.c. Export it again since we are going to use it again. Signed-off-by: Carlo Caione <carlo@endlessm.com> [robh: move of_irq_find_parent to correct ifdef section] Signed-off-by: Rob Herring <robh@kernel.org> | 09 December 2015, 15:08:36 UTC |
9a81123 | Takashi Iwai | 09 December 2015, 14:17:43 UTC | ALSA: hda - Fix noise problems on Thinkpad T440s Lenovo Thinkpad T440s suffers from constant background noises, and it seems to be a generic hardware issue on this model: https://forums.lenovo.com/t5/ThinkPad-T400-T500-and-newer-T/T440s-speaker-noise/td-p/1339883 As the noise comes from the analog loopback path, disabling the path is the easy workaround. Also, the machine gives significant cracking noises at PM suspend. A workaround found by trial-and-error is to disable the shutup callback currently used for ALC269-variant. This patch addresses these noise issues by introducing a new fixup chain. Although the same workaround might be applicable to other Thinkpad models, it's applied only to T440s (17aa:220c) in this patch, so far, just to be safe (you chicken!). As a compromise, a new model option string "tp440" is provided now, though, so that owners of other Thinkpad models can test it more easily. Bugzilla: https://bugzilla.opensuse.org/show_bug.cgi?id=958504 Reported-and-tested-by: Tim Hardeck <thardeck@suse.de> Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de> | 09 December 2015, 14:31:21 UTC |
361c32d | Oded Gabbay | 04 December 2015, 21:09:05 UTC | radeon: Fix VCE IB test on Big-Endian systems This patch makes the VCE IB test pass on Big-Endian systems. It converts to little-endian the contents of the VCE message. Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Oded Gabbay <oded.gabbay@gmail.com> Cc: stable@vger.kernel.org Signed-off-by: Alex Deucher <alexander.deucher@amd.com> | 09 December 2015, 05:23:56 UTC |
687f4b9 | Oded Gabbay | 04 December 2015, 21:09:04 UTC | radeon: Fix VCE ring test for Big-Endian systems This patch fixes the VCE ring test when running on Big-Endian machines. Every write to the ring needs to be translated to little-endian. Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Oded Gabbay <oded.gabbay@gmail.com> Cc: stable@vger.kernel.org Signed-off-by: Alex Deucher <alexander.deucher@amd.com> | 09 December 2015, 05:22:44 UTC |
5f3e226 | Oded Gabbay | 04 December 2015, 21:09:03 UTC | radeon/cik: Fix GFX IB test on Big-Endian This patch makes the IB test on the GFX ring pass for CI-based cards installed in Big-Endian machines. Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Oded Gabbay <oded.gabbay@gmail.com> Cc: stable@vger.kernel.org Signed-off-by: Alex Deucher <alexander.deucher@amd.com> | 09 December 2015, 05:20:45 UTC |
e410b5c | Chunming Zhou | 07 December 2015, 07:02:52 UTC | drm/amdgpu: fix the lost duplicates checking Signed-off-by: Chunming Zhou <David1.Zhou@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Reviewed-by: Jammy Zhou <Jammy.Zhou@amd.com> Cc: stable@vger.kernel.org | 09 December 2015, 05:18:33 UTC |
1a6e760 | Dave Airlie | 09 December 2015, 04:16:53 UTC | Merge tag 'vmwgfx-fixes-4.4-151208' of git://people.freedesktop.org/~thomash/linux into drm-fixes Pull request of 2015-12-08 A couple of fixes for vmwgfx. A WARN() fix by Dan Carpenter, a TTM read/write lock imbalance causing occasional hangs with Wayland and an implementation of cursor_set2 to fix incorrectly offset Wayland cursors. * tag 'vmwgfx-fixes-4.4-151208' of git://people.freedesktop.org/~thomash/linux: drm/vmwgfx: Implement the cursor_set2 callback v2 drm/vmwgfx: fix a warning message drm/ttm: Fixed a read/write lock imbalance | 09 December 2015, 04:16:53 UTC |
ff6e0fd | Dave Airlie | 09 December 2015, 04:15:58 UTC | Merge branch 'linux-4.4' of https://github.com/skeggsb/linux into drm-fixes Just the one commit I mentioned earlier, making the PGOB workaround the default. * 'linux-4.4' of https://github.com/skeggsb/linux: drm/nouveau/pmu: remove whitelist for PGOB-exit WAR, enable by default | 09 December 2015, 04:15:58 UTC |
dc9c41b | Andrew Donnellan | 08 December 2015, 05:59:25 UTC | Revert "powerpc/eeh: Don't unfreeze PHB PE after reset" This reverts commit 527d10ef3a315d3cb9dc098dacd61889a6c26439. The reverted commit breaks cxlflash devices following an EEH reset (and possibly other cxl devices, however this has not been tested). The reverted commit changed the behaviour of eeh_reset_device() so that PHB PEs are not unfrozen following the completion of the reset. This should not be problematic, as no device resources should have been associated with the PHB PE. However, when attempting to load the cxlflash driver after a reset, the driver attempts to read Vital Product Data through a call to pci_read_vpd() (which is called on the physical cxl device, not on the virtual AFU device). pci_read_vpd() in turn attempts to read from the cxl device's config space. This fails, as the PE it's trying to read from is still frozen. In turn, the driver gets an -ENODEV and fails to initialise. It appears this issue only affects some parts of the VPD area, as "lspci -vvv", which only reads a subset of the VPD bytes, is not broken by the original patch. At this stage, we don't fully understand why we're trying to read a frozen PE, and we don't know how this affects other cxl devices. It is possible that there is an underlying bug in the cxl driver or the powerpc CAPI support code, or alternatively a bug in the PCI resource allocation/mapping code that is incorrectly mapping resources to PE#0. As such, this fix is incomplete, however it is necessary to prevent a serious regression in CAPI support. In the meantime, revert the commit, especially as it was intended to be a non-functional change. Cc: Gavin Shan <gwshan@linux.vnet.ibm.com> Cc: Ian Munsie <imunsie@au1.ibm.com> Cc: Daniel Axtens <dja@axtens.net> Signed-off-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> | 09 December 2015, 03:05:10 UTC |
5b01310 | Paul Gortmaker | 08 December 2015, 22:44:02 UTC | powerpc/sbc8641: drop bogus PHY IRQ entries from DTS file This file was originally cloned off of the MPC8641D-HPCN reference platform, which actually had a PHY IRQ line connected. However this board does not. The bogus entry was largely inert and went undetected until commit 321beec5047af83db90c88114b7e664b156f49fe ("net: phy: Use interrupts when available in NOLINK state") was added to the tree. With the above commit, the board fails to NFS boot since it sits waiting for a PHY IRQ event that of course never arrives. Removing the bogus entries from the DTS file fixes the issue. Cc: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> | 09 December 2015, 03:00:39 UTC |
aa53685 | Linus Torvalds | 09 December 2015, 01:22:45 UTC | Merge branch 'for-linus-4.4-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/rw/uml Pull uml fixes from Richard Weinberger: "This contains various bug fixes, most of them are fall out from the merge window" * 'for-linus-4.4-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/rw/uml: um: fix returns without va_end um: Fix fpstate handling arch: um: fix error when linking vmlinux. um: Fix get_signal() usage | 09 December 2015, 01:22:45 UTC |
714a98f | Ben Skeggs | 09 December 2015, 00:06:05 UTC | drm/nouveau/pmu: remove whitelist for PGOB-exit WAR, enable by default NVIDIA have indicated that the workaround is required on all GK10[467] boards that have the PGOB fuse set. I've left the commandline option in place for now, as paranoia. Signed-off-by: Ben Skeggs <bskeggs@redhat.com> | 09 December 2015, 00:33:47 UTC |
ab5cdc3 | Leon Romanovsky | 21 October 2015, 06:21:17 UTC | IB/mlx5: Postpone remove_keys under knowledge of coming preemption The remove_keys() logic is performed as garbage collection task. Such task is intended to be run when no other active processes are running. The need_resched() will return TRUE if there are user tasks to be activated in near future. In such case, we don't execute remove_keys() and postpone the garbage collection work to try to run in next cycle, in order to free CPU resources to other tasks. The possible pseudo-code to trigger such scenario: 1. Allocate a lot of MR to fill the cache above the limit. 2. Wait a small amount of time "to calm" the system. 3. Start CPU extensive operations on multi-node cluster. 4. Expect performance degradation during MR cache shrink operation. Signed-off-by: Leon Romanovsky <leonro@mellanox.com> Signed-off-by: Eli Cohen <eli@mellanox.com> Signed-off-by: Doug Ledford <dledford@redhat.com> | 08 December 2015, 21:55:31 UTC |
0ef2f05 | Wengang Wang | 08 October 2015, 05:27:04 UTC | IB/mlx4: Use vmalloc for WR buffers when needed There are several hits that WR buffer allocation(kmalloc) failed. It failed at order 3 and/or 4 contigous pages allocation. At the same time there are actually 100MB+ free memory but well fragmented. So try vmalloc when kmalloc failed. Signed-off-by: Wengang Wang <wen.gang.wang@oracle.com> Acked-by: Or Gerlitz <ogerlitz@mellanox.com> Signed-off-by: Doug Ledford <dledford@redhat.com> | 08 December 2015, 21:48:10 UTC |
73d4da7 | Wengang Wang | 08 October 2015, 05:21:33 UTC | IB/mlx4: Use correct order of variables in log message There is a mis-order in mlx4 log. Fix it. Signed-off-by: Wengang Wang <wen.gang.wang@oracle.com> Acked-by: Or Gerlitz <ogerlitz@mellanox.com> Signed-off-by: Doug Ledford <dledford@redhat.com> | 08 December 2015, 21:45:51 UTC |
5406812 | Linus Torvalds | 08 December 2015, 21:35:52 UTC | Merge branch 'for-4.4-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup Pull cgroup fixes from Tejun Heo: "More change than I'd have liked at this stage. The pids controller and the changes made to cgroup core to support it introduced and revealed several important issues. - Assigning membership to a newly created task and migrating it can race leading to incorrect accounting. Oleg fixed it by widening threadgroup synchronization. It looks like we'll be able to merge it with a different percpu rwsem which is used in fork path making things simpler and cheaper. - The recent change to extend cgroup membership to zombies (so that pid accounting can extend till the pid is actually released) missed pinning the underlying data structures leading to use-after-free. Fixed. - v2 hierarchy was calling subsystem callbacks with the wrong target cgroup_subsys_state based on the incorrect assumption that they share the same target. pids is the first controller affected by this. Subsys callbacks updated so that they can deal with multi-target migrations" * 'for-4.4-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup: cgroup_pids: don't account for the root cgroup cgroup: fix handling of multi-destination migration from subtree_control enabling cgroup_freezer: simplify propagation of CGROUP_FROZEN clearing in freezer_attach() cgroup: pids: kill pids_fork(), simplify pids_can_fork() and pids_cancel_fork() cgroup: pids: fix race between cgroup_post_fork() and cgroup_migrate() cgroup: make css_set pin its css's to avoid use-afer-free cgroup: fix cftype->file_offset handling | 08 December 2015, 21:35:52 UTC |
633bb73 | Linus Torvalds | 08 December 2015, 21:29:18 UTC | Merge branch 'for-4.4-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/libata Pull libata fixes from Tejun Heo: "Nothing too interesting. All are device specific additions and workarounds" * 'for-4.4-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/libata: ata/sata_fsl.c: add ATA_FLAG_NO_LOG_PAGE to blacklist the controller for log page reads libata-eh.c: Introduce new ata port flag for controller which lockup on read log page sata_sil: disable trim AHCI: Fix softreset failed issue of Port Multiplier sata/mvebu: use #ifdef around suspend/resume code ahci: Order SATA device IDs for codename Lewisburg ahci: Add Device ID for Intel Sunrise Point PCH | 08 December 2015, 21:29:18 UTC |
887a985 | Geyslan G. Bem | 01 December 2015, 20:18:55 UTC | um: fix returns without va_end When using va_list ensure that va_start will be followed by va_end. Signed-off-by: Geyslan G. Bem <geyslan@gmail.com> Signed-off-by: Richard Weinberger <richard@nod.at> | 08 December 2015, 21:26:00 UTC |
8090bfd | Richard Weinberger | 29 November 2015, 20:13:50 UTC | um: Fix fpstate handling The x86 FPU cleanup changed fpstate to a plain integer. UML on x86 has to deal with that too. Signed-off-by: Richard Weinberger <richard@nod.at> | 08 December 2015, 21:25:40 UTC |
fb1770a | Lorenzo Colitti | 18 November 2015, 14:12:09 UTC | arch: um: fix error when linking vmlinux. On gcc Ubuntu 4.8.4-2ubuntu1~14.04, linking vmlinux fails with: arch/um/os-Linux/built-in.o: In function `os_timer_create': /android/kernel/android/arch/um/os-Linux/time.c:51: undefined reference to `timer_create' arch/um/os-Linux/built-in.o: In function `os_timer_set_interval': /android/kernel/android/arch/um/os-Linux/time.c:84: undefined reference to `timer_settime' arch/um/os-Linux/built-in.o: In function `os_timer_remain': /android/kernel/android/arch/um/os-Linux/time.c:109: undefined reference to `timer_gettime' arch/um/os-Linux/built-in.o: In function `os_timer_one_shot': /android/kernel/android/arch/um/os-Linux/time.c:132: undefined reference to `timer_settime' arch/um/os-Linux/built-in.o: In function `os_timer_disable': /android/kernel/android/arch/um/os-Linux/time.c:145: undefined reference to `timer_settime' This is because -lrt appears in the generated link commandline after arch/um/os-Linux/built-in.o. Fix this by removing -lrt from arch/um/Makefile and adding it to the UM-specific section of scripts/link-vmlinux.sh. Signed-off-by: Lorenzo Colitti <lorenzo@google.com> Signed-off-by: Richard Weinberger <richard@nod.at> | 08 December 2015, 21:25:13 UTC |
db2f24d | Richard Weinberger | 18 November 2015, 08:37:15 UTC | um: Fix get_signal() usage If get_signal() returns us a signal to post we must not call it again, otherwise the already posted signal will be overridden. Before commit a610d6e672d this was the case as we stopped the while after a successful handle_signal(). Cc: <stable@vger.kernel.org> # 3.10- Fixes: a610d6e672d ("pull clearing RESTORE_SIGMASK into block_sigmask()") Signed-off-by: Richard Weinberger <richard@nod.at> | 08 December 2015, 21:23:30 UTC |
51825c8 | Linus Torvalds | 08 December 2015, 21:01:23 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: "This tree includes four core perf fixes for misc bugs, three fixes to x86 PMU drivers, and two updates to old email addresses" * 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: perf: Do not send exit event twice perf/x86/intel: Fix INTEL_FLAGS_UEVENT_CONSTRAINT_DATALA_NA macro perf/x86/intel: Make L1D_PEND_MISS.FB_FULL not constrained on Haswell perf: Fix PERF_EVENT_IOC_PERIOD deadlock treewide: Remove old email address perf/x86: Fix LBR call stack save/restore perf: Update email address in MAINTAINERS perf/core: Robustify the perf_cgroup_from_task() RCU checks perf/core: Fix RCU problem with cgroup context switching code | 08 December 2015, 21:01:23 UTC |
af096e2 | Minfei Huang | 08 December 2015, 20:47:34 UTC | null_blk: Fix error path in module initialization Module couldn't release resource properly during the initialization. To fix this issue, we will clean up the proper resource before returning. Signed-off-by: Minfei Huang <mnfhuang@gmail.com> Signed-off-by: Jens Axboe <axboe@fb.com> | 08 December 2015, 20:47:34 UTC |
2d4594a | Al Viro | 08 December 2015, 17:22:47 UTC | fix the regression from "direct-io: Fix negative return from dio read beyond eof" Sure, it's better to bail out of past-the-eof read and return 0 than return a bogus negative value on such. Only we'd better make sure we are bailing out with 0 and not -ENOMEM... Cc: stable@vger.kernel.org Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> | 08 December 2015, 20:02:42 UTC |