https://github.com/torvalds/linux
- v6.9-rc1
- v6.8-rc7
- v6.8-rc6
- v6.8-rc5
- v6.8-rc4
- v6.8-rc3
- v6.8-rc2
- v6.8-rc1
- v6.8
- v6.7-rc8
- v6.7-rc7
- v6.7-rc6
- v6.7-rc5
- v6.7-rc4
- v6.7-rc3
- v6.7-rc2
- v6.7-rc1
- v6.7
- v6.6-rc7
- v6.6-rc6
- v6.6-rc5
- v6.6-rc4
- v6.6-rc3
- v6.6-rc2
- v6.6-rc1
- v6.6
- v6.5-rc7
- v6.5-rc6
- v6.5-rc5
- v6.5-rc4
- v6.5-rc3
- v6.5-rc2
- v6.5-rc1
- v6.5
- v6.4-rc7
- v6.4-rc6
- v6.4-rc5
- v6.4-rc4
- v6.4-rc3
- v6.4-rc2
- v6.4-rc1
- v6.4
- v6.3-rc7
- v6.3-rc6
- v6.3-rc5
- v6.3-rc4
- v6.3-rc3
- v6.3-rc2
- v6.3-rc1
- v6.3
- v6.2-rc8
- v6.2-rc7
- v6.2-rc6
- v6.2-rc5
- v6.2-rc4
- v6.2-rc3
- v6.2-rc2
- v6.2-rc1
- v6.2
- v6.1-rc8
- v6.1-rc7
- v6.1-rc6
- v6.1-rc5
- v6.1-rc4
- v6.1-rc3
- v6.1-rc2
- v6.1-rc1
- v6.1
- v6.0-rc7
- v6.0-rc6
- v6.0-rc5
- v6.0-rc4
- v6.0-rc3
- v6.0-rc2
- v6.0-rc1
- v6.0
- 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
Take a new snapshot of a software origin
If the archived software origin currently browsed is not synchronized with its upstream version (for instance when new commits have been issued), you can explicitly request Software Heritage to take a new snapshot of it.
Use the form below to proceed. Once a request has been submitted and accepted, it will be processed as soon as possible. You can then check its processing state by visiting this dedicated page.Processing "take a new snapshot" request ...
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 |
---|---|---|---|---|
ebd5749 | Josh Poimboeuf | 23 May 2017, 15:37:29 UTC | Revert "x86/entry: Fix the end of the stack for newly forked tasks" Petr Mladek reported the following warning when loading the livepatch sample module: WARNING: CPU: 1 PID: 3699 at arch/x86/kernel/stacktrace.c:132 save_stack_trace_tsk_reliable+0x133/0x1a0 ... Call Trace: __schedule+0x273/0x820 schedule+0x36/0x80 kthreadd+0x305/0x310 ? kthread_create_on_cpu+0x80/0x80 ? icmp_echo.part.32+0x50/0x50 ret_from_fork+0x2c/0x40 That warning means the end of the stack is no longer recognized as such for newly forked tasks. The problem was introduced with the following commit: ff3f7e2475bb ("x86/entry: Fix the end of the stack for newly forked tasks") ... which was completely misguided. It only partially fixed the reported issue, and it introduced another bug in the process. None of the other entry code saves the frame pointer before calling into C code, so it doesn't make sense for ret_from_fork to do so either. Contrary to what I originally thought, the original issue wasn't related to newly forked tasks. It was actually related to ftrace. When entry code calls into a function which then calls into an ftrace handler, the stack frame looks different than normal. The original issue will be fixed in the unwinder, in a subsequent patch. Reported-by: Petr Mladek <pmladek@suse.com> Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com> Acked-by: Thomas Gleixner <tglx@linutronix.de> Cc: Dave Jones <davej@codemonkey.org.uk> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Steven Rostedt <rostedt@goodmis.org> Cc: live-patching@vger.kernel.org Fixes: ff3f7e2475bb ("x86/entry: Fix the end of the stack for newly forked tasks") Link: http://lkml.kernel.org/r/f350760f7e82f0750c8d1dd093456eb212751caa.1495553739.git.jpoimboe@redhat.com Signed-off-by: Ingo Molnar <mingo@kernel.org> | 24 May 2017, 07:05:16 UTC |
6e30437 | Ingo Molnar | 24 May 2017, 06:57:21 UTC | tools/include: Sync kernel ABI headers with tooling headers Sync (copy) the following v4.12 kernel headers to the tooling headers: arch/x86/include/asm/disabled-features.h: arch/x86/include/uapi/asm/kvm.h: arch/powerpc/include/uapi/asm/kvm.h: arch/s390/include/uapi/asm/kvm.h: arch/arm/include/uapi/asm/kvm.h: arch/arm64/include/uapi/asm/kvm.h: - 'struct kvm_sync_regs' got changed in an ABI-incompatible way, fortunately none of the (in-kernel) tooling relied on it - new KVM_DEV calls added arch/x86/include/asm/required-features.h: - 5-level paging hardware ABI detail added arch/x86/include/asm/cpufeatures.h: - new CPU feature added arch/x86/include/uapi/asm/vmx.h: - new VMX exit conditions None of the changes requires fixes in the tooling source code. This addresses the following warnings: Warning: include/uapi/linux/stat.h differs from kernel Warning: arch/x86/include/asm/disabled-features.h differs from kernel Warning: arch/x86/include/asm/required-features.h differs from kernel Warning: arch/x86/include/asm/cpufeatures.h differs from kernel Warning: arch/x86/include/uapi/asm/kvm.h differs from kernel Warning: arch/x86/include/uapi/asm/vmx.h differs from kernel Warning: arch/powerpc/include/uapi/asm/kvm.h differs from kernel Warning: arch/s390/include/uapi/asm/kvm.h differs from kernel Warning: arch/arm/include/uapi/asm/kvm.h differs from kernel Warning: arch/arm64/include/uapi/asm/kvm.h differs from kernel Cc: Arnaldo Carvalho de Melo <acme@kernel.org> Cc: Arnaldo Carvalho de Melo <acme@redhat.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Milian Wolff <milian.wolff@kdab.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Yao Jin <yao.jin@linux.intel.com> Cc: kernel-team@lge.com Link: http://lkml.kernel.org/r/20170524065721.j2mlch6bgk5klgbc@gmail.com Signed-off-by: Ingo Molnar <mingo@kernel.org> | 24 May 2017, 07:00:21 UTC |
7111fff | Namhyung Kim | 24 May 2017, 06:21:29 UTC | perf tools: Put caller above callee in --children mode The __hpp__sort_acc() sorts entries using callchain depth in order to put callers above in children mode. But it assumed the callchain order was callee-first. Now default (for children) is caller-first so the order of entries is reverted. For example, consider following case: $ perf report --no-children ..l # Overhead Command Shared Object Symbol # ........ ....... ................... .......................... # 99.44% a.out a.out [.] main | ---main __libc_start_main _start Then children mode should show 'start' above '__libc_start_main' since it's the caller (parent) of the __libc_start_main. But it's reversed: # Children Self Command Shared Object Symbol # ........ ........ ....... ............... ..................... # 99.61% 0.00% a.out libc-2.25.so [.] __libc_start_main 99.61% 0.00% a.out a.out [.] _start 99.54% 99.44% a.out a.out [.] main This patch fixes it. # Children Self Command Shared Object Symbol # ........ ........ ....... ............... ..................... # 99.61% 0.00% a.out a.out [.] _start 99.61% 0.00% a.out libc-2.25.so [.] __libc_start_main 99.54% 99.44% a.out a.out [.] main Signed-off-by: Namhyung Kim <namhyung@kernel.org> Acked-by: Jiri Olsa <jolsa@kernel.org> Cc: Arnaldo Carvalho de Melo <acme@kernel.org> Cc: Arnaldo Carvalho de Melo <acme@redhat.com> Cc: Frederic Weisbecker <fweisbec@gmail.com> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Milian Wolff <milian.wolff@kdab.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Yao Jin <yao.jin@linux.intel.com> Cc: kernel-team@lge.com Link: http://lkml.kernel.org/r/20170524062129.32529-8-namhyung@kernel.org Signed-off-by: Ingo Molnar <mingo@kernel.org> | 24 May 2017, 06:41:49 UTC |
4d53b9d | Milian Wolff | 24 May 2017, 06:21:28 UTC | perf report: Do not drop last inlined frame The very last inlined frame, i.e. the one furthest away from the non-inlined frame, was silently dropped. This is apparent when comparing the output of `perf script` and `addr2line`: ~~~~~~ $ perf script --inline ... a.out 26722 80836.309329: 72425 cycles: 21561 __hypot_finite (/usr/lib/libm-2.25.so) ace3 hypot (/usr/lib/libm-2.25.so) a4a main (a.out) std::abs<double> std::_Norm_helper<true>::_S_do_it<double> std::norm<double> main 20510 __libc_start_main (/usr/lib/libc-2.25.so) bd9 _start (a.out) $ addr2line -a -f -i -e /tmp/a.out a4a | c++filt 0x0000000000000a4a std::__complex_abs(doublecomplex ) /usr/include/c++/6.3.1/complex:589 double std::abs<double>(std::complex<double> const&) /usr/include/c++/6.3.1/complex:597 double std::_Norm_helper<true>::_S_do_it<double>(std::complex<double> const&) /usr/include/c++/6.3.1/complex:654 double std::norm<double>(std::complex<double> const&) /usr/include/c++/6.3.1/complex:664 main /tmp/inlining.cpp:14 ~~~~~ Note how `std::__complex_abs` is missing from the `perf script` output. This is similarly showing up in `perf report`. The patch here fixes this issue, and the output becomes: ~~~~~ a.out 26722 80836.309329: 72425 cycles: 21561 __hypot_finite (/usr/lib/libm-2.25.so) ace3 hypot (/usr/lib/libm-2.25.so) a4a main (a.out) std::__complex_abs std::abs<double> std::_Norm_helper<true>::_S_do_it<double> std::norm<double> main 20510 __libc_start_main (/usr/lib/libc-2.25.so) bd9 _start (a.out) ~~~~~ Signed-off-by: Milian Wolff <milian.wolff@kdab.com> Signed-off-by: Namhyung Kim <namhyung@kernel.org> Cc: Arnaldo Carvalho de Melo <acme@kernel.org> Cc: Arnaldo Carvalho de Melo <acme@redhat.com> Cc: David Ahern <dsahern@gmail.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Yao Jin <yao.jin@linux.intel.com> Cc: kernel-team@lge.com Link: http://lkml.kernel.org/r/20170524062129.32529-7-namhyung@kernel.org Signed-off-by: Ingo Molnar <mingo@kernel.org> | 24 May 2017, 06:41:48 UTC |
28071f5 | Milian Wolff | 24 May 2017, 06:21:27 UTC | perf report: Always honor callchain order for inlined nodes So far, the inlined nodes where only reversed when we built perf against libbfd. If that was not available, the addr2line fallback code path was missing the inline_list__reverse call. Now we always add the nodes in the correct order within inline_list__append. This removes the need to reverse the list and also ensures that all callers construct the list in the right order. Signed-off-by: Milian Wolff <milian.wolff@kdab.com> Signed-off-by: Namhyung Kim <namhyung@kernel.org> Cc: Arnaldo Carvalho de Melo <acme@kernel.org> Cc: Arnaldo Carvalho de Melo <acme@redhat.com> Cc: David Ahern <dsahern@gmail.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Yao Jin <yao.jin@linux.intel.com> Cc: kernel-team@lge.com Link: http://lkml.kernel.org/r/20170524062129.32529-6-namhyung@kernel.org Signed-off-by: Ingo Molnar <mingo@kernel.org> | 24 May 2017, 06:41:48 UTC |
325fbff | Namhyung Kim | 24 May 2017, 06:21:26 UTC | perf script: Add --inline option for debugging The --inline option is to show inlined functions in callchains. For example: $ perf script a.out 5644 11611.467597: 309961 cycles:u: 790 main (/home/namhyung/tmp/perf/a.out) 20511 __libc_start_main (/usr/lib/libc-2.25.so) 8ba _start (/home/namhyung/tmp/perf/a.out) ... $ perf script --inline a.out 5644 11611.467597: 309961 cycles:u: 790 main (/home/namhyung/tmp/perf/a.out) std::__detail::_Adaptor<std::linear_congruential_engine<unsigned long, 16807ul, 0ul, 2147483647ul>, double>::operator() std::uniform_real_distribution<double>::operator()<std::linear_congruential_engine<unsigned long, 16807ul, 0ul, 2147483647ul> > std::uniform_real_distribution<double>::operator()<std::linear_congruential_engine<unsigned long, 16807ul, 0ul, 2147483647ul> > main 20511 __libc_start_main (/usr/lib/libc-2.25.so) 8ba _start (/home/namhyung/tmp/perf/a.out) ... Reviewed-and-tested-by: Milian Wolff <milian.wolff@kdab.com> Signed-off-by: Namhyung Kim <namhyung@kernel.org> Cc: Arnaldo Carvalho de Melo <acme@kernel.org> Cc: Arnaldo Carvalho de Melo <acme@redhat.com> Cc: Jin Yao <yao.jin@linux.intel.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Milian Wolff <milian.wolff@kdab.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: kernel-team@lge.com Link: http://lkml.kernel.org/r/20170524062129.32529-5-namhyung@kernel.org Signed-off-by: Ingo Molnar <mingo@kernel.org> | 24 May 2017, 06:41:48 UTC |
1982ad4 | Milian Wolff | 24 May 2017, 06:21:25 UTC | perf report: Fix off-by-one for non-activation frames As the documentation for dwfl_frame_pc says, frames that are no activation frames need to have their program counter decremented by one to properly find the function of the caller. This fixes many cases where perf report currently attributes the cost to the next line. I.e. I have code like this: ~~~~~~~~~~~~~~~ #include <thread> #include <chrono> using namespace std; int main() { this_thread::sleep_for(chrono::milliseconds(1000)); this_thread::sleep_for(chrono::milliseconds(100)); this_thread::sleep_for(chrono::milliseconds(10)); return 0; } ~~~~~~~~~~~~~~~ Now compile and record it: ~~~~~~~~~~~~~~~ g++ -std=c++11 -g -O2 test.cpp echo 1 | sudo tee /proc/sys/kernel/sched_schedstats perf record \ --event sched:sched_stat_sleep \ --event sched:sched_process_exit \ --event sched:sched_switch --call-graph=dwarf \ --output perf.data.raw \ ./a.out echo 0 | sudo tee /proc/sys/kernel/sched_schedstats perf inject --sched-stat --input perf.data.raw --output perf.data ~~~~~~~~~~~~~~~ Before this patch, the report clearly shows the off-by-one issue. Most notably, the last sleep invocation is incorrectly attributed to the "return 0;" line: ~~~~~~~~~~~~~~~ Overhead Source:Line ........ ........... 100.00% core.c:0 | ---__schedule core.c:0 schedule do_nanosleep hrtimer.c:0 hrtimer_nanosleep sys_nanosleep entry_SYSCALL_64_fastpath .tmp_entry_64.o:0 __nanosleep_nocancel .:0 std::this_thread::sleep_for<long, std::ratio<1l, 1000l> > thread:323 | |--90.08%--main test.cpp:9 | __libc_start_main | _start | |--9.01%--main test.cpp:10 | __libc_start_main | _start | --0.91%--main test.cpp:13 __libc_start_main _start ~~~~~~~~~~~~~~~ With this patch here applied, the issue is fixed. The report becomes much more usable: ~~~~~~~~~~~~~~~ Overhead Source:Line ........ ........... 100.00% core.c:0 | ---__schedule core.c:0 schedule do_nanosleep hrtimer.c:0 hrtimer_nanosleep sys_nanosleep entry_SYSCALL_64_fastpath .tmp_entry_64.o:0 __nanosleep_nocancel .:0 std::this_thread::sleep_for<long, std::ratio<1l, 1000l> > thread:323 | |--90.08%--main test.cpp:8 | __libc_start_main | _start | |--9.01%--main test.cpp:9 | __libc_start_main | _start | --0.91%--main test.cpp:10 __libc_start_main _start ~~~~~~~~~~~~~~~ Similarly it works for signal frames: ~~~~~~~~~~~~~~~ __noinline void bar(void) { volatile long cnt = 0; for (cnt = 0; cnt < 100000000; cnt++); } __noinline void foo(void) { bar(); } void sig_handler(int sig) { foo(); } int main(void) { signal(SIGUSR1, sig_handler); raise(SIGUSR1); foo(); return 0; } ~~~~~~~~~~~~~~~~ Before, the report wrongly points to `signal.c:29` after raise(): ~~~~~~~~~~~~~~~~ $ perf report --stdio --no-children -g srcline -s srcline ... 100.00% signal.c:11 | ---bar signal.c:11 | |--50.49%--main signal.c:29 | __libc_start_main | _start | --49.51%--0x33a8f raise .:0 main signal.c:29 __libc_start_main _start ~~~~~~~~~~~~~~~~ With this patch in, the issue is fixed and we instead get: ~~~~~~~~~~~~~~~~ 100.00% signal signal [.] bar | ---bar signal.c:11 | |--50.49%--main signal.c:29 | __libc_start_main | _start | --49.51%--0x33a8f raise .:0 main signal.c:27 __libc_start_main _start ~~~~~~~~~~~~~~~~ Note how this patch fixes this issue for both unwinding methods, i.e. both dwfl and libunwind. The former case is straight-forward thanks to dwfl_frame_pc(). For libunwind, we replace the functionality via unw_is_signal_frame() for any but the very first frame. Signed-off-by: Milian Wolff <milian.wolff@kdab.com> Signed-off-by: Namhyung Kim <namhyung@kernel.org> Cc: Arnaldo Carvalho de Melo <acme@kernel.org> Cc: Arnaldo Carvalho de Melo <acme@redhat.com> Cc: David Ahern <dsahern@gmail.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Yao Jin <yao.jin@linux.intel.com> Cc: kernel-team@lge.com Link: http://lkml.kernel.org/r/20170524062129.32529-4-namhyung@kernel.org Signed-off-by: Ingo Molnar <mingo@kernel.org> | 24 May 2017, 06:41:48 UTC |
b21cc97 | Milian Wolff | 24 May 2017, 06:21:24 UTC | perf report: Fix memory leak in addr2line when called by addr2inlines When a filename was found in addr2line it was duplicated via strdup() but never freed. Now we pass NULL and handle this gracefully in addr2line. Detected by Valgrind: ==16331== 1,680 bytes in 21 blocks are definitely lost in loss record 148 of 220 ==16331== at 0x4C2AF1F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==16331== by 0x672FA69: strdup (in /usr/lib/libc-2.25.so) ==16331== by 0x52769F: addr2line (srcline.c:256) ==16331== by 0x52769F: addr2inlines (srcline.c:294) ==16331== by 0x52769F: dso__parse_addr_inlines (srcline.c:502) ==16331== by 0x574D7A: inline__fprintf (hist.c:41) ==16331== by 0x574D7A: ipchain__fprintf_graph (hist.c:147) ==16331== by 0x57518A: __callchain__fprintf_graph (hist.c:212) ==16331== by 0x5753CF: callchain__fprintf_graph.constprop.6 (hist.c:337) ==16331== by 0x57738E: hist_entry__fprintf (hist.c:628) ==16331== by 0x57738E: hists__fprintf (hist.c:882) ==16331== by 0x44A20F: perf_evlist__tty_browse_hists (builtin-report.c:399) ==16331== by 0x44A20F: report__browse_hists (builtin-report.c:491) ==16331== by 0x44A20F: __cmd_report (builtin-report.c:624) ==16331== by 0x44A20F: cmd_report (builtin-report.c:1054) ==16331== by 0x4A49CE: run_builtin (perf.c:296) ==16331== by 0x4A4CC0: handle_internal_command (perf.c:348) ==16331== by 0x434371: run_argv (perf.c:392) ==16331== by 0x434371: main (perf.c:530) Signed-off-by: Milian Wolff <milian.wolff@kdab.com> Signed-off-by: Namhyung Kim <namhyung@kernel.org> Cc: Arnaldo Carvalho de Melo <acme@kernel.org> Cc: Arnaldo Carvalho de Melo <acme@redhat.com> Cc: David Ahern <dsahern@gmail.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Yao Jin <yao.jin@linux.intel.com> Cc: kernel-team@lge.com Link: http://lkml.kernel.org/r/20170524062129.32529-3-namhyung@kernel.org Signed-off-by: Ingo Molnar <mingo@kernel.org> | 24 May 2017, 06:41:48 UTC |
7d4df08 | Milian Wolff | 24 May 2017, 06:21:23 UTC | perf report: Don't crash on invalid maps in `-g srcline` mode I just hit a segfault when doing `perf report -g srcline`. Valgrind pointed me at this code as the culprit: ==8359== Invalid read of size 8 ==8359== at 0x3096D9: map__rip_2objdump (map.c:430) ==8359== by 0x2FC1A3: match_chain_srcline (callchain.c:645) ==8359== by 0x2FC1A3: match_chain (callchain.c:700) ==8359== by 0x2FC1A3: append_chain (callchain.c:895) ==8359== by 0x2FC1A3: append_chain_children (callchain.c:846) ==8359== by 0x2FF719: callchain_append (callchain.c:944) ==8359== by 0x2FF719: hist_entry__append_callchain (callchain.c:1058) ==8359== by 0x32FA06: iter_add_single_cumulative_entry (hist.c:908) ==8359== by 0x33195C: hist_entry_iter__add (hist.c:1050) ==8359== by 0x258F65: process_sample_event (builtin-report.c:204) ==8359== by 0x30D60C: perf_session__deliver_event (session.c:1310) ==8359== by 0x30D60C: ordered_events__deliver_event (session.c:119) ==8359== by 0x310D12: __ordered_events__flush (ordered-events.c:210) ==8359== by 0x310D12: ordered_events__flush.part.3 (ordered-events.c:277) ==8359== by 0x30DD3C: perf_session__process_user_event (session.c:1349) ==8359== by 0x30DD3C: perf_session__process_event (session.c:1475) ==8359== by 0x30FC3C: __perf_session__process_events (session.c:1867) ==8359== by 0x30FC3C: perf_session__process_events (session.c:1921) ==8359== by 0x25A985: __cmd_report (builtin-report.c:575) ==8359== by 0x25A985: cmd_report (builtin-report.c:1054) ==8359== by 0x2B9A80: run_builtin (perf.c:296) ==8359== Address 0x70 is not stack'd, malloc'd or (recently) free'd This patch fixes the issue. Signed-off-by: Milian Wolff <milian.wolff@kdab.com> [ Remove dependency from another change ] Signed-off-by: Namhyung Kim <namhyung@kernel.org> Cc: Arnaldo Carvalho de Melo <acme@kernel.org> Cc: Arnaldo Carvalho de Melo <acme@redhat.com> Cc: David Ahern <dsahern@gmail.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Yao Jin <yao.jin@linux.intel.com> Cc: kernel-team@lge.com Link: http://lkml.kernel.org/r/20170524062129.32529-2-namhyung@kernel.org Signed-off-by: Ingo Molnar <mingo@kernel.org> | 24 May 2017, 06:41:47 UTC |
a54c518 | Jon Mason | 28 April 2017, 20:11:30 UTC | thermal: broadcom: ns-thermal: default on iProc SoCs Tweak the Kconfig description to mention support for NSP and make the default on for iProc based platforms. Signed-off-by: Jon Mason <jon.mason@broadcom.com> Signed-off-by: Eduardo Valentin <edubezval@gmail.com> | 24 May 2017, 03:09:34 UTC |
8b8656d | Markus Elfring | 26 April 2017, 15:11:28 UTC | ti-soc-thermal: Fix a typo in a comment line Add a missing character in this description for a function. Acked-by: Keerthy <j-keerthy@ti.com> Tested-by: Keerthy <j-keerthy@ti.com> Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> Signed-off-by: Eduardo Valentin <edubezval@gmail.com> | 24 May 2017, 03:07:32 UTC |
57e5211 | Markus Elfring | 26 April 2017, 15:03:07 UTC | ti-soc-thermal: Delete error messages for failed memory allocations in ti_bandgap_build() The script "checkpatch.pl" pointed information out like the following. WARNING: Possible unnecessary 'out of memory' message Thus remove such statements here. Link: http://events.linuxfoundation.org/sites/events/files/slides/LCJ16-Refactor_Strings-WSang_0.pdf Acked-by: Keerthy <j-keerthy@ti.com> Tested-by: Keerthy <j-keerthy@ti.com> Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> Signed-off-by: Eduardo Valentin <edubezval@gmail.com> | 24 May 2017, 03:07:14 UTC |
748c23d | Markus Elfring | 26 April 2017, 14:45:25 UTC | ti-soc-thermal: Use devm_kcalloc() in ti_bandgap_build() A multiplication for the size determination of a memory allocation indicated that an array data structure should be processed. Thus use the corresponding function "devm_kcalloc". This issue was detected by using the Coccinelle software. Acked-by: Keerthy <j-keerthy@ti.com> Tested-by: Keerthy <j-keerthy@ti.com> Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> Signed-off-by: Eduardo Valentin <edubezval@gmail.com> | 24 May 2017, 03:06:56 UTC |
c4b379d | Colin Ian King | 08 May 2017, 10:36:43 UTC | thermal: core: make thermal_emergency_poweroff static Making thermal_emergency_poweroff static fixes sparse warning: drivers/thermal/thermal_core.c:6: warning: symbol 'thermal_emergency_poweroff' was not declared. Should it be static? Fixes: ef1d87e06ab4 ("thermal: core: Add a back up thermal shutdown mechanism") Acked-by: Keerthy <j-keerthy@ti.com> Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Eduardo Valentin <edubezval@gmail.com> | 24 May 2017, 03:03:35 UTC |
0e77488 | Masahiro Yamada | 26 April 2017, 01:50:02 UTC | thermal: qoriq: remove useless call for of_thermal_get_trip_points() Building this driver with W=1 reports: warning: variable 'trip' set but not used [-Wunused-but-set-variable] The call for of_thermal_get_trip_points() is useless. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Eduardo Valentin <edubezval@gmail.com> | 24 May 2017, 03:02:03 UTC |
43fe8b8 | Thomas Gleixner | 23 May 2017, 21:27:38 UTC | posix-timers: Make signal printks conditional A recent commit added extra printks for CPU/RT limits. This can result in excessive spam in dmesg. Make the printks conditional on print_fatal_signals. Fixes: e7ea7c9806a2 ("rlimits: Print more information when CPU/RT limits are exceeded") Reported-by: Dave Jones <davej@codemonkey.org.uk> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Cc: Arun Raghavan <arun@arunraghavan.net> | 23 May 2017, 21:39:57 UTC |
82bc9a4 | Patrik Jakobsson | 18 April 2017, 11:43:32 UTC | drm/gma500/psb: Actually use VBT mode when it is found With LVDS we were incorrectly picking the pre-programmed mode instead of the prefered mode provided by VBT. Make sure we pick the VBT mode if one is provided. It is likely that the mode read-out code is still wrong but this patch fixes the immediate problem on most machines. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=78562 Cc: <stable@vger.kernel.org> Signed-off-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170418114332.12183-1-patrik.r.jakobsson@gmail.com | 23 May 2017, 20:01:07 UTC |
4d071c3 | Imre Deak | 23 May 2017, 19:18:17 UTC | PCI/PM: Add needs_resume flag to avoid suspend complete optimization Some drivers - like i915 - may not support the system suspend direct complete optimization due to differences in their runtime and system suspend sequence. Add a flag that when set resumes the device before calling the driver's system suspend handlers which effectively disables the optimization. Needed by a future patch fixing suspend/resume on i915. Suggested by Rafael. Signed-off-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Cc: stable@vger.kernel.org | 23 May 2017, 19:18:17 UTC |
293dffa | Dan Carpenter | 23 May 2017, 14:25:10 UTC | libceph: NULL deref on crush_decode() error path If there is not enough space then ceph_decode_32_safe() does a goto bad. We need to return an error code in that situation. The current code returns ERR_PTR(0) which is NULL. The callers are not expecting that and it results in a NULL dereference. Fixes: f24e9980eb86 ("ceph: OSD client") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by: Ilya Dryomov <idryomov@gmail.com> Signed-off-by: Ilya Dryomov <idryomov@gmail.com> | 23 May 2017, 18:32:32 UTC |
b51456a | Ilya Dryomov | 19 May 2017, 12:24:36 UTC | libceph: fix error handling in process_one_ticket() Don't leak key internals after new_session_key is populated. Signed-off-by: Ilya Dryomov <idryomov@gmail.com> Reviewed-by: Alex Elder <elder@linaro.org> | 23 May 2017, 18:32:28 UTC |
d18a124 | Ilya Dryomov | 19 May 2017, 10:21:56 UTC | libceph: validate blob_struct_v in process_one_ticket() None of these are validated in userspace, but since we do validate reply_struct_v in ceph_x_proc_ticket_reply(), tkt_struct_v (first) and CephXServiceTicket struct_v (second) in process_one_ticket(), validate CephXTicketBlob struct_v as well. Signed-off-by: Ilya Dryomov <idryomov@gmail.com> Reviewed-by: Alex Elder <elder@linaro.org> | 23 May 2017, 18:32:25 UTC |
f3b4e55 | Ilya Dryomov | 19 May 2017, 09:59:22 UTC | libceph: drop version variable from ceph_monmap_decode() It's set but not used: CEPH_FEATURE_MONNAMES feature bit isn't advertised, which guarantees a v1 MonMap. Signed-off-by: Ilya Dryomov <idryomov@gmail.com> Reviewed-by: Alex Elder <elder@linaro.org> | 23 May 2017, 18:32:22 UTC |
1759f7b | Ilya Dryomov | 19 May 2017, 09:38:17 UTC | libceph: make ceph_msg_data_advance() return void Both callers ignore the returned bool. Signed-off-by: Ilya Dryomov <idryomov@gmail.com> Reviewed-by: Alex Elder <elder@linaro.org> | 23 May 2017, 18:32:20 UTC |
6f4dbd1 | Ilya Dryomov | 19 May 2017, 09:33:16 UTC | libceph: use kbasename() and kill ceph_file_part() Signed-off-by: Ilya Dryomov <idryomov@gmail.com> Reviewed-by: Alex Elder <elder@linaro.org> | 23 May 2017, 18:32:10 UTC |
56fff1b | Linus Torvalds | 23 May 2017, 16:57:39 UTC | Merge branch 'i2c/for-current' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux Pull i2c fixes from Wolfram Sang: "Fix the i2c-designware regression of rc2. Also, a DMA buffer fix for the tiny-usb driver where the USB core now loudly complains about the non DMA-capable buffer" [ I had cherry-picked the designware fix separately because it hit my laptop, but here is the proper sync with the i2c tree - Linus ] * 'i2c/for-current' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux: i2c: designware: Fix bogus sda_hold_time due to uninitialized vars i2c: i2c-tiny-usb: fix buffer not being DMA capable | 23 May 2017, 16:57:39 UTC |
2232203 | Richard | 21 May 2017, 19:27:00 UTC | partitions/msdos: FreeBSD UFS2 file systems are not recognized The code in block/partitions/msdos.c recognizes FreeBSD, OpenBSD and NetBSD partitions and does a reasonable job picking out OpenBSD and NetBSD UFS subpartitions. But for FreeBSD the subpartitions are always "bad". Kernel: <bsd:bad subpartition - ignored Though all 3 of these BSD systems use UFS as a file system, only FreeBSD uses relative start addresses in the subpartition declarations. The following patch fixes this for FreeBSD partitions and leaves the code for OpenBSD and NetBSD intact: Signed-off-by: Richard Narron <comet.berkeley@gmail.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Jens Axboe <axboe@fb.com> | 23 May 2017, 15:16:07 UTC |
12e8b57 | Jesper Dangaard Brouer | 22 May 2017, 18:13:07 UTC | mlx5: fix bug reading rss_hash_type from CQE Masks for extracting part of the Completion Queue Entry (CQE) field rss_hash_type was swapped, namely CQE_RSS_HTYPE_IP and CQE_RSS_HTYPE_L4. The bug resulted in setting skb->l4_hash, even-though the rss_hash_type indicated that hash was NOT computed over the L4 (UDP or TCP) part of the packet. Added comments from the datasheet, to make it more clear what these masks are selecting. Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com> Acked-by: Saeed Mahameed <saeedm@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net> | 23 May 2017, 15:03:31 UTC |
7f65b1f | Oliver Neukum | 22 May 2017, 12:50:30 UTC | cdc-ether: divorce initialisation with a filter reset and a generic method Some devices need their multicast filter reset but others are crashed by that. So the methods need to be separated. Signed-off-by: Oliver Neukum <oneukum@suse.com> Reported-by: "Ridgway, Keith" <kridgway@harris.com> Signed-off-by: David S. Miller <davem@davemloft.net> | 23 May 2017, 15:01:28 UTC |
2f9bfd3 | David S. Miller | 23 May 2017, 14:51:32 UTC | Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsec Steffen Klassert says: ==================== pull request (net): ipsec 2017-05-23 1) Fix wrong header offset for esp4 udpencap packets. 2) Fix a stack access out of bounds when creating a bundle with sub policies. From Sabrina Dubroca. 3) Fix slab-out-of-bounds in pfkey due to an incorrect sadb_x_sec_len calculation. 4) We checked the wrong feature flags when taking down an interface with IPsec offload enabled. Fix from Ilan Tayari. 5) Copy the anti replay sequence numbers when doing a state migration, otherwise we get out of sync with the sequence numbers. Fix from Antony Antony. Please pull or let me know if there are problems. ==================== Signed-off-by: David S. Miller <davem@davemloft.net> | 23 May 2017, 14:51:32 UTC |
7bd897c | Dan Carpenter | 23 May 2017, 14:28:36 UTC | block: fix an error code in add_partition() We don't set an error code on this path. It means that we return NULL instead of an error pointer and the caller does a NULL dereference. Fixes: 6d1d8050b4bc ("block, partition: add partition_meta_info to hd_struct") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Jens Axboe <axboe@fb.com> | 23 May 2017, 14:41:59 UTC |
b665d98 | Tariq Toukan | 18 May 2017, 10:34:43 UTC | net/mlx5: Tolerate irq_set_affinity_hint() failures Add tolerance to failures of irq_set_affinity_hint(). Its role is to give hints that optimizes performance, and should not block the driver load. In non-SMP systems, functionality is not available as there is a single core, and all these calls definitely fail. Hence, do not call the function and avoid the warning prints. Fixes: db058a186f98 ("net/mlx5_core: Set irq affinity hints") Signed-off-by: Tariq Toukan <tariqt@mellanox.com> Cc: kernel-team@fb.com Signed-off-by: Saeed Mahameed <saeedm@mellanox.com> | 23 May 2017, 13:23:32 UTC |
73dd3a4 | Mohamad Haj Yahia | 23 February 2017, 09:19:36 UTC | net/mlx5: Avoid using pending command interface slots Currently when firmware command gets stuck or it takes long time to complete, the driver command will get timeout and the command slot is freed and can be used for new commands, and if the firmware receive new command on the old busy slot its behavior is unexpected and this could be harmful. To fix this when the driver command gets timeout we return failure, but we don't free the command slot and we wait for the firmware to explicitly respond to that command. Once all the entries are busy we will stop processing new firmware commands. Fixes: 9cba4ebcf374 ('net/mlx5: Fix potential deadlock in command mode change') Signed-off-by: Mohamad Haj Yahia <mohamad@mellanox.com> Cc: kernel-team@fb.com Signed-off-by: Saeed Mahameed <saeedm@mellanox.com> | 23 May 2017, 13:23:31 UTC |
b57fe69 | Erez Shitrit | 27 April 2017, 14:59:00 UTC | net/mlx5e: IPoIB, handle RX packet correctly IPoIB packet contains the pseudo header area, we need to pull it prior to reset_mac_header in order to let the GRO work well. In more details: GRO checks the mac address of the new coming packet, it does that by comparing the hard_header_len size of the current packet to the previous one in that session, the comparison is over hard_header_len size. Now, the driver prepares that area in the skb by allocating area from the reserved part and resetting the correct mac header to it. Fixes: 9d6bd752c63c ("net/mlx5e: IPoIB, RX handler") Signed-off-by: Erez Shitrit <erezsh@mellanox.com> Signed-off-by: Saeed Mahameed <saeedm@mellanox.com> | 23 May 2017, 13:23:31 UTC |
e3ca4e0 | Or Gerlitz | 09 May 2017, 10:37:26 UTC | net/mlx5e: Fix warnings around parsing of TC pedit actions The sparse tool emits these correct complaints: drivers/net/ethernet/mellanox/mlx5/core//en_tc.c:1005:25: warning: cast to restricted __be32 drivers/net/ethernet/mellanox/mlx5/core//en_tc.c:1007:25: warning: cast to restricted __be16 The value is provided from user-space in network order, but there's no way for them to realize that, avoid the warnings by casting to the appropriate type. Fixes: d79b6df6b10a ('net/mlx5e: Add parsing of TC pedit actions to HW format') Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com> Reported-by: Leon Romanovsky <leonro@mellanox.com> Reviewed-by: Paul Blakey <paulb@mellanox.com> Signed-off-by: Saeed Mahameed <saeedm@mellanox.com> | 23 May 2017, 13:23:31 UTC |
d824bf3 | Or Gerlitz | 09 May 2017, 16:02:42 UTC | net/mlx5e: Properly enforce disallowing of partial field re-write offload Currently we don't support partial header re-writes through TC pedit action offloading. However, the code that enforces that wasn't err-ing on cases where the first and last bits of the mask are set but there is some zero bit between them, such as in the below example, fix that! tc filter add dev enp1s0 protocol ip parent ffff: prio 10 flower ip_proto udp dst_port 2001 skip_sw action pedit munge ip src set 1.0.0.1 retain 0xff0000ff Fixes: d79b6df6b10a ('net/mlx5e: Add parsing of TC pedit actions to HW format') Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com> Reviewed-by: Paul Blakey <paulb@mellanox.com> Signed-off-by: Saeed Mahameed <saeedm@mellanox.com> | 23 May 2017, 13:23:31 UTC |
26c0274 | Or Gerlitz | 10 May 2017, 10:59:54 UTC | net/mlx5e: Allow TC csum offload if applied together with pedit action When offloading header re-writes, the HW re-calculates the relevant L3/L4 checksums. Hence, when upper layers (as done by OVS) ask for TC checksum action offload together with pedit offload, don't err. This command now works: tc filter add dev ens1f0 protocol ip parent ffff: prio 20 flower skip_sw ip_proto tcp dst_port 9001 action pedit ex munge tcp dport set 0x1234 pipe action csum tcp Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com> Reported-by: Paul Blakey <paulb@mellanox.com> Reviewed-by: Paul Blakey <paulb@mellanox.com> Signed-off-by: Saeed Mahameed <saeedm@mellanox.com> | 23 May 2017, 13:23:31 UTC |
3aa4266 | Or Gerlitz | 10 May 2017, 10:48:41 UTC | net/sched: act_csum: Add accessors for offloading drivers Add the accessors for realizing if this is a csum action, and for which fields checksum is needed. Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com> Reviewed-by: Paul Blakey <paulb@mellanox.com> Signed-off-by: Saeed Mahameed <saeedm@mellanox.com> | 23 May 2017, 13:23:31 UTC |
cdc5a7f | Or Gerlitz | 09 May 2017, 17:45:06 UTC | net/mlx5e: Use the correct delete call on offloaded TC encap entry detach We wrongly direcly invoke hlist_del_rcu() and not hash_del_rcu() which does a slightly different call now and may change later, fix that. Fixes: a54e20b4fcae ('net/mlx5e: Add basic TC tunnel set action for SRIOV offloads') Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com> Reported-by: Paul Blakey <paulb@mellanox.com> Reviewed-by: Paul Blakey <paulb@mellanox.com> Signed-off-by: Saeed Mahameed <saeedm@mellanox.com> | 23 May 2017, 13:23:31 UTC |
c70d9d8 | Eric W. Biederman | 22 May 2017, 20:40:12 UTC | ptrace: Properly initialize ptracer_cred on fork When I introduced ptracer_cred I failed to consider the weirdness of fork where the task_struct copies the old value by default. This winds up leaving ptracer_cred set even when a process forks and the child process does not wind up being ptraced. Because ptracer_cred is not set on non-ptraced processes whose parents were ptraced this has broken the ability of the enlightenment window manager to start setuid children. Fix this by properly initializing ptracer_cred in ptrace_init_task This must be done with a little bit of care to preserve the current value of ptracer_cred when ptrace carries through fork. Re-reading the ptracer_cred from the ptracing process at this point is inconsistent with how PT_PTRACE_CAP has been maintained all of these years. Tested-by: Takashi Iwai <tiwai@suse.de> Fixes: 64b875f7ac8a ("ptrace: Capture the ptracer's creds not PT_PTRACE_CAP") Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com> | 23 May 2017, 12:40:44 UTC |
1b57b62 | Arend Van Spriel | 23 May 2017, 08:58:07 UTC | cfg80211: make cfg80211_sched_scan_results() work from atomic context Drivers should be able to call cfg80211_sched_scan_results() from atomic context. However, with the introduction of multiple scheduled scan feature this requirement was not taken into account resulting in regression shown below. [ 119.021594] BUG: scheduling while atomic: irq/47-iwlwifi/517/0x00000200 [ 119.021604] Modules linked in: [...] [ 119.021759] CPU: 1 PID: 517 Comm: irq/47-iwlwifi Not tainted 4.12.0-rc2-t440s-20170522+ #1 [ 119.021763] Hardware name: LENOVO 20AQS03H00/20AQS03H00, BIOS GJET91WW (2.41 ) 09/21/2016 [ 119.021766] Call Trace: [ 119.021778] ? dump_stack+0x5c/0x84 [ 119.021784] ? __schedule_bug+0x4c/0x70 [ 119.021792] ? __schedule+0x496/0x5c0 [ 119.021798] ? schedule+0x2d/0x80 [ 119.021804] ? schedule_preempt_disabled+0x5/0x10 [ 119.021810] ? __mutex_lock.isra.0+0x18e/0x4c0 [ 119.021817] ? __wake_up+0x2f/0x50 [ 119.021833] ? cfg80211_sched_scan_results+0x19/0x60 [cfg80211] [ 119.021844] ? cfg80211_sched_scan_results+0x19/0x60 [cfg80211] [ 119.021859] ? iwl_mvm_rx_lmac_scan_iter_complete_notif+0x17/0x30 [iwlmvm] [ 119.021869] ? iwl_pcie_rx_handle+0x2a9/0x7e0 [iwlwifi] [ 119.021878] ? iwl_pcie_irq_handler+0x17c/0x730 [iwlwifi] [ 119.021884] ? irq_forced_thread_fn+0x60/0x60 [ 119.021887] ? irq_thread_fn+0x16/0x40 [ 119.021892] ? irq_thread+0x109/0x180 [ 119.021896] ? wake_threads_waitq+0x30/0x30 [ 119.021901] ? kthread+0xf2/0x130 [ 119.021905] ? irq_thread_dtor+0x90/0x90 [ 119.021910] ? kthread_create_on_node+0x40/0x40 [ 119.021915] ? ret_from_fork+0x26/0x40 Fixes: b34939b98369 ("cfg80211: add request id to cfg80211_sched_scan_*() api") Reported-by: Sander Eikelenboom <linux@eikelenboom.it> Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com> | 23 May 2017, 12:36:46 UTC |
ea45267 | Ulf Hansson | 03 May 2017, 14:11:33 UTC | arm64: dts: hikey: Fix WiFi support The description of the connection between the dwmmc (SDIO) controller and the Wifi chip, which is attached to the SDIO bus is wrong. Currently the SDIO card can't be detected and thus the Wifi doesn't work. Let's fix this by assigning the correct vmmc supply, which is the always on regulator VDD_3V3 and remove the WLAN enable regulator altogether. Then to properly deal with the power on/off sequence, add a mmc-pwrseq node to describe the resources needed to detect the SDIO card. Except for the WLAN enable GPIO and its corresponding assert/de-assert delays, the mmc-pwrseq node also contains a handle to a clock provided by the hi655x pmic. This clock is also needed to be able to turn on the WiFi chip. Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Acked-by: Arnd Bergmann <arnd@arndb.de> | 23 May 2017, 12:18:10 UTC |
76f1dfb | Ulf Hansson | 03 May 2017, 12:18:26 UTC | arm64: dts: hi6220: Move board data from the dwmmc nodes to hikey dts Move the board specific descriptions for the dwmmc nodes in the hi6220 SoC dtsi, into the hikey dts as it's there these belongs. While changing this, let's take the opportunity to drop the use of the "ti,non-removable" binding for one of the dwmmc device nodes, as it's not a valid binding and not used. Drop also the unnecessary use of "num-slots = <0x1>" for all of the dwmmc nodes, as there is no need to set this since when default number of slots is one. Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org> Acked-by: Arnd Bergmann <arnd@arndb.de> | 23 May 2017, 12:18:03 UTC |
84f7c60 | Ulf Hansson | 03 May 2017, 11:51:27 UTC | arm64: dts: hikey: Add the SYS_5V and the VDD_3V3 regulators Add these regulators to better describe the HW, but also because those is needed in following changes. Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org> Acked-by: Arnd Bergmann <arnd@arndb.de> | 23 May 2017, 12:17:58 UTC |
1b32a5f | Ulf Hansson | 03 May 2017, 10:46:55 UTC | arm64: dts: hi6220: Move the fixed_5v_hub regulator to the hikey dts The regulator is a part of the hikey board, therefore let's move it from the hi6220 SoC dtsi file into the hikey dts file . Let's also rename the regulator according to the datasheet (5V_HUB) to better reflect the HW. Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org> Acked-by: Arnd Bergmann <arnd@arndb.de> | 23 May 2017, 12:17:53 UTC |
307ded8 | Daniel Lezcano | 24 April 2017, 20:40:22 UTC | arm64: dts: hikey: Add clock for the pmic mfd The hi655x PMIC provides the regulators but also a clock. The latter is missing so let's add it. This clock is used by WiFi/Bluetooth chip, but that connection is done in a separate change on top of this one. Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Acked-by: Rob Herring <robh@kernel.org> Acked-by: Lee Jones <lee.jones@linaro.org> [Ulf: Split patch and updated changelog] Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Acked-by: Arnd Bergmann <arnd@arndb.de> | 23 May 2017, 12:17:48 UTC |
f74ac68 | Daniel Lezcano | 24 April 2017, 20:40:22 UTC | mfd: dts: hi655x: Add clock binding for the pmic The hi655x PMIC provides the regulators but also a clock. The latter is missing in the definition, so extend the documentation to include this as well. Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Acked-by: Rob Herring <robh@kernel.org> Acked-by: Lee Jones <lee.jones@linaro.org> [Ulf: Split patch and updated changelog] Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Acked-by: Arnd Bergmann <arnd@arndb.de> | 23 May 2017, 12:17:42 UTC |
e9256e1 | Ulf Hansson | 06 May 2017, 09:43:05 UTC | mmc: pwrseq_simple: Parse DTS for the power-off-delay-us property If the optional power-off-delay-us property is found, insert the corresponding delay after asserting the GPIO during power off. This enables a graceful shutdown sequence for some devices. Cc: linux-mmc@vger.kernel.org Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Acked-by: Arnd Bergmann <arnd@arndb.de> | 23 May 2017, 12:17:36 UTC |
c477ebe | Ulf Hansson | 06 May 2017, 09:41:30 UTC | mmc: dt: pwrseq-simple: Invent power-off-delay-us During power off, after the GPIO pin has been asserted, some devices like the Wifi chip from TI, Wl18xx, needs a delay before the host continues with clock gating and turning off regulators as to follow a graceful shutdown sequence. Therefore invent an optional power-off-delay-us DT binding for mmc-pwrseq-simple, to allow us to support this constraint. Cc: devicetree@vger.kernel.org Cc: Rob Herring <robh+dt@kernel.org> Cc: linux-mmc@vger.kernel.org Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Acked-by: Arnd Bergmann <arnd@arndb.de> | 23 May 2017, 12:17:10 UTC |
f928543 | Daniel Vetter | 22 May 2017, 13:59:45 UTC | drm: Fix deadlock retry loop in page_flip_ioctl I failed to properly onion-wrap the unwind code: We acquire the vblank reference before we start with the wait-wound locking dance, hence we must make sure we retry before we drop the reference. Oops. v2: The vblank_put must be after the frambuffer_put (Michel). I suck at unwrapping code that doesn't use separate labels for each stage, but checks each pointer first ... While re-reading everything I also realized that we must clean up the fb refcounts, and specifically plane->old_fb before we drop the locks, either in the final unlocking, or in the w/w retry path. Hence the correct fix is to drop the vblank_put to the very bottom. Fixes: 29dc0d1de182 ("drm: Roll out acquire context for the page_flip ioctl") Cc: Harry Wentland <harry.wentland@amd.com> Cc: Daniel Vetter <daniel.vetter@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Sean Paul <seanpaul@chromium.org> Cc: David Airlie <airlied@linux.ie> Cc: dri-devel@lists.freedesktop.org Reported-by: Tommi Rantala <tt.rantala@gmail.com> Cc: Tommi Rantala <tt.rantala@gmail.com> Cc: Michel Dänzer <michel@daenzer.net> Tested-by: Tommi Rantala <tt.rantala@gmail.com> Reviewed-by: Michel Dänzer <michel.daenzer@amd.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170522135945.28831-1-daniel.vetter@ffwll.ch | 23 May 2017, 07:39:14 UTC |
429030b | Gabriel Krisman Bertazi | 19 May 2017, 17:58:19 UTC | drm: qxl: Delay entering atomic context during cursor update qxl_release_map will enter an atomic context, but since we still need to alloc memory for BOs, we better delay that until we have everything we need, in case we need to sleep inside the allocation. This avoids the Sleep in atomic state below, which was reported by Mike. [ 43.910362] BUG: sleeping function called from invalid context at mm/slab.h:432 [ 43.910955] in_atomic(): 1, irqs_disabled(): 0, pid: 2077, name: Xorg [ 43.911472] Preemption disabled at: [ 43.911478] [<ffffffffa02b1c45>] qxl_bo_kmap_atomic_page+0xa5/0x100 [qxl] [ 43.912103] CPU: 0 PID: 2077 Comm: Xorg Tainted: G E 4.12.0-master #38 [ 43.912550] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.8.1-0-g4adadbd-20161202_174313-build11a 04/01/2014 [ 43.913202] Call Trace: [ 43.913371] dump_stack+0x65/0x89 [ 43.913581] ? qxl_bo_kmap_atomic_page+0xa5/0x100 [qxl] [ 43.913876] ___might_sleep+0x11a/0x190 [ 43.914095] __might_sleep+0x4a/0x80 [ 43.914319] ? qxl_bo_create+0x50/0x190 [qxl] [ 43.914565] kmem_cache_alloc_trace+0x46/0x180 [ 43.914836] qxl_bo_create+0x50/0x190 [qxl] [ 43.915082] ? refcount_dec_and_test+0x11/0x20 [ 43.915332] ? ttm_mem_io_reserve+0x41/0xe0 [ttm] [ 43.915595] qxl_alloc_bo_reserved+0x37/0xb0 [qxl] [ 43.915884] qxl_cursor_atomic_update+0x8f/0x260 [qxl] [ 43.916172] ? drm_atomic_helper_update_legacy_modeset_state+0x1d6/0x210 [drm_kms_helper] [ 43.916623] drm_atomic_helper_commit_planes+0xec/0x230 [drm_kms_helper] [ 43.916995] drm_atomic_helper_commit_tail+0x2b/0x60 [drm_kms_helper] [ 43.917398] commit_tail+0x65/0x70 [drm_kms_helper] [ 43.917693] drm_atomic_helper_commit+0xa9/0x100 [drm_kms_helper] [ 43.918039] drm_atomic_commit+0x4b/0x50 [drm] [ 43.918334] drm_atomic_helper_update_plane+0xf1/0x110 [drm_kms_helper] [ 43.918902] __setplane_internal+0x19f/0x280 [drm] [ 43.919240] drm_mode_cursor_universal+0x101/0x1c0 [drm] [ 43.919541] drm_mode_cursor_common+0x15b/0x1d0 [drm] [ 43.919858] drm_mode_cursor2_ioctl+0xe/0x10 [drm] [ 43.920157] drm_ioctl+0x211/0x460 [drm] [ 43.920383] ? drm_mode_cursor_ioctl+0x50/0x50 [drm] [ 43.920664] ? handle_mm_fault+0x93/0x160 [ 43.920893] do_vfs_ioctl+0x96/0x6e0 [ 43.921117] ? __fget+0x73/0xa0 [ 43.921322] SyS_ioctl+0x41/0x70 [ 43.921545] entry_SYSCALL_64_fastpath+0x1a/0xa5 [ 43.922188] RIP: 0033:0x7f1145804bc7 [ 43.922526] RSP: 002b:00007ffcd3e50508 EFLAGS: 00003246 ORIG_RAX: 0000000000000010 [ 43.923367] RAX: ffffffffffffffda RBX: 0000000000000040 RCX: 00007f1145804bc7 [ 43.923852] RDX: 00007ffcd3e50540 RSI: 00000000c02464bb RDI: 000000000000000b [ 43.924299] RBP: 0000000000000040 R08: 0000000000000040 R09: 000000000000000c [ 43.924694] R10: 00007ffcd3e50340 R11: 0000000000003246 R12: 0000000000000018 [ 43.925128] R13: 00000000022bc390 R14: 0000000000000040 R15: 00007ffcd3e5062c Reported-by: Mike Galbraith <efault@gmx.de> Signed-off-by: Gabriel Krisman Bertazi <krisman@collabora.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/20170519175819.15682-1-krisman@collabora.co.uk Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> | 23 May 2017, 07:17:04 UTC |
1fc2e41 | Alexander Tsoy | 22 May 2017, 17:58:11 UTC | ALSA: hda - apply STAC_9200_DELL_M22 quirk for Dell Latitude D430 This model is actually called 92XXM2-8 in Windows driver. But since pin configs for M22 and M28 are identical, just reuse M22 quirk. Fixes external microphone (tested) and probably docking station ports (not tested). Signed-off-by: Alexander Tsoy <alexander@tsoy.me> Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de> | 23 May 2017, 05:54:59 UTC |
fde8e33 | Linus Torvalds | 23 May 2017, 04:30:20 UTC | Merge branch 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6 Pull crypto fix from Herbert Xu: "This fixes a regression in the skcipher interface that allows bogus key parameters to hit underlying implementations which can cause crashes" * 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6: crypto: skcipher - Add missing API setkey checks | 23 May 2017, 04:30:20 UTC |
fadd2ce | Linus Torvalds | 23 May 2017, 02:31:07 UTC | Merge tag 'pstore-v4.12-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux Pull pstore fix from Kees Cook: "Marta noticed another misbehavior in EFI pstore, which this fixes. Hopefully this is the last of the v4.12 fixes for pstore!" * tag 'pstore-v4.12-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux: efi-pstore: Fix write/erase id tracking | 23 May 2017, 02:31:07 UTC |
74a9e7d | Linus Torvalds | 23 May 2017, 02:26:33 UTC | Merge tag 'acpi-4.12-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm Pull ACPI fixes from Rafael Wysocki: "These revert a 4.11 change that turned out to be problematic and add a .gitignore file. Specifics: - Revert a 4.11 commit related to the ACPI-based handling of laptop lids that made changes incompatible with existing user space stacks and broke things there (Lv Zheng). - Add .gitignore to the ACPI tools directory (Prarit Bhargava)" * tag 'acpi-4.12-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: Revert "ACPI / button: Remove lid_init_state=method mode" tools/power/acpi: Add .gitignore file | 23 May 2017, 02:26:33 UTC |
801099b | Linus Torvalds | 23 May 2017, 02:24:32 UTC | Merge tag 'pm-4.12-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm Pull power management fixes from Rafael Wysocki: "These fix RTC wakeup from suspend-to-idle broken recently, fix CPU idleness detection condition in the schedutil cpufreq governor, fix a cpufreq driver build failure, fix an error code path in the power capping framework, clean up the hibernate core and update the intel_pstate documentation. Specifics: - Fix RTC wakeup from suspend-to-idle broken by the recent rework of ACPI wakeup handling (Rafael Wysocki). - Update intel_pstate driver documentation to reflect the current code and explain how it works in more detail (Rafael Wysocki). - Fix an issue related to CPU idleness detection on systems with shared cpufreq policies in the schedutil governor (Juri Lelli). - Fix a possible build issue in the dbx500 cpufreq driver (Arnd Bergmann). - Fix a function in the power capping framework core to return an error code instead of 0 when there's an error (Dan Carpenter). - Clean up variable definition in the hibernation core (Pushkar Jambhlekar)" * tag 'pm-4.12-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: cpufreq: dbx500: add a Kconfig symbol PM / hibernate: Declare variables as static PowerCap: Fix an error code in powercap_register_zone() RTC: rtc-cmos: Fix wakeup from suspend-to-idle PM / wakeup: Fix up wakeup_source_report_event() cpufreq: intel_pstate: Document the current behavior and user interface cpufreq: schedutil: use now as reference when aggregating shared policy requests | 23 May 2017, 02:24:32 UTC |
ad258fb | Jan Kiszka | 22 May 2017, 05:46:55 UTC | i2c: designware: Fix bogus sda_hold_time due to uninitialized vars We need to initializes those variables to 0 for platforms that do not provide ACPI parameters. Otherwise, we set sda_hold_time to random values, breaking e.g. Galileo and IOT2000 boards. Reported-and-tested-by: Linus Torvalds <torvalds@linux-foundation.org> Reported-by: Tobias Klausmann <tobias.johannes.klausmann@mni.thm.de> Fixes: 9d6408433019 ("i2c: designware: don't infer timings described by ACPI from clock rate") Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Acked-by: Jarkko Nikula <jarkko.nikula@linux.intel.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> | 23 May 2017, 02:22:19 UTC |
089b50d | Maxime Roussin-Bélanger | 19 May 2017, 21:59:03 UTC | Input: atmel_mxt_ts - add T100 as a readable object When using the 'object' sysfs attribute, T100 is not displayed in the output. Signed-off-by: Maxime Roussin-Bélanger <maxime.roussinbelanger@gmail.com> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> | 23 May 2017, 00:22:57 UTC |
aa3d440 | Martin Kepplinger | 23 May 2017, 00:19:45 UTC | Input: edt-ft5x06 - increase allowed data range for threshold parameter The datasheet and application note does not mention an allowed range for the M09_REGISTER_THRESHOLD parameter. One of our customers needs to set lower values than 20 and they seem to work just fine on EDT EP0xx0M09 with T5x06 touch. So, lacking a known lower limit, we increase the range for thresholds, and set the lower limit to 0. The documentation is updated accordingly. Signed-off-by: Schoefegger Stefan <stefan.schoefegger@ginzinger.com> Signed-off-by: Manfred Schlaegl <manfred.schlaegl@ginzinger.com> Signed-off-by: Martin Kepplinger <martin.kepplinger@ginzinger.com> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> | 23 May 2017, 00:22:50 UTC |
c10e803 | Kees Cook | 18 May 2017, 20:07:49 UTC | efi-pstore: Fix write/erase id tracking Prior to the pstore interface refactoring, the "id" generated during a backend pstore_write() was only retained by the internal pstore inode tracking list. Additionally the "part" was ignored, so EFI would encode this in the id. This corrects the misunderstandings and correctly sets "id" during pstore_write(), and uses "part" directly during pstore_erase(). Reported-by: Marta Lofstedt <marta.lofstedt@intel.com> Fixes: 76cc9580e3fb ("pstore: Replace arguments for write() API") Fixes: a61072aae693 ("pstore: Replace arguments for erase() API") Signed-off-by: Kees Cook <keescook@chromium.org> Tested-by: Marta Lofstedt <marta.lofstedt@intel.com> | 22 May 2017, 23:53:09 UTC |
415b618 | Lucas Stach | 22 May 2017, 22:06:30 UTC | PCI: imx6: Fix config read timeout handling Commit cc7b0d495589 ("PCI: designware: Update PCI config space remap function") made PCI configuration requests non-posted, which means we now get a synchronous abort when the CFG space read to probe for downstream devices times out. Synchronous aborts need to be handled differently from the async aborts we were getting before, in particular the PC needs to be advanced when resolving the abort. This is mostly a copy of what other PCI drivers do on ARM to handle those aborts. [bhelgaas: changelog, "Fixes"] Fixes: cc7b0d495589 ("PCI: designware: Update PCI config space remap function") Tested-by: Fabio Estevam <fabio.estevam@nxp.com> Tested-by: Peter Senna Tschudin <peter.senna@collabora.com> Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Richard Zhu <hongxing.zhu@nxp.com> | 22 May 2017, 22:06:30 UTC |
9871e9b | Logan Gunthorpe | 22 May 2017, 21:52:30 UTC | switchtec: Fix minor bug with partition ID register When a switch endpoint is configured without NTB, the mmio_ntb registers will read all zeros. However, in corner case configurations where the partition ID is not zero and NTB is not enabled, the code will have the wrong partition ID and this causes the driver to use the wrong set of drivers. To fix this we simply take the partition ID from the system info region. Reported-by: Dingbao Chen <dingbao.chen@microsemi.com> Signed-off-by: Logan Gunthorpe <logang@deltatee.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> | 22 May 2017, 21:52:30 UTC |
e40cf64 | Logan Gunthorpe | 22 May 2017, 21:52:24 UTC | switchtec: Use new cdev_device_add() helper function Convert from "cdev_add() + device_add()" to cdev_device_add(), and from "device_del() + cdev_del()" to cdev_device_del(). [bhelgaas: changelog] Signed-off-by: Logan Gunthorpe <logang@deltatee.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> | 22 May 2017, 21:52:24 UTC |
c849e55 | Geert Uytterhoeven | 16 May 2017, 17:21:08 UTC | PCI: endpoint: Make PCI_ENDPOINT depend on HAS_DMA If NO_DMA=y: drivers/built-in.o: In function `__pci_epc_create': (.text+0xef4e): undefined reference to `bad_dma_ops' drivers/built-in.o: In function `pci_epc_add_epf': (.text+0xf676): undefined reference to `bad_dma_ops' drivers/built-in.o: In function `pci_epf_alloc_space': (.text+0xfa32): undefined reference to `bad_dma_ops' drivers/built-in.o: In function `pci_epf_free_space': (.text+0xfac4): undefined reference to `bad_dma_ops' Add a dependency on HAS_DMA to fix this. Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> | 22 May 2017, 21:23:59 UTC |
b4f428e | Shaohua Li | 17 May 2017, 20:07:27 UTC | blk-throttle: force user to configure all settings for io.low Default value of io.low limit is 0. If user doesn't configure the limit, last patch makes cgroup be throttled to very tiny bps/iops, which could stall the system. A cgroup with default settings of io.low limit really means nothing, so we force user to configure all settings, otherwise io.low limit doesn't take effect. With this stragety, default setting of latency/idle isn't important, so just set them to very conservative and safe value. Signed-off-by: Shaohua Li <shli@fb.com> Acked-by: Tejun Heo <tj@kernel.org> Signed-off-by: Jens Axboe <axboe@fb.com> | 22 May 2017, 20:47:12 UTC |
9bb67ae | Shaohua Li | 17 May 2017, 20:07:26 UTC | blk-throttle: respect 0 bps/iops settings for io.low If a cgroup with low limit 0 for both bps/iops, the cgroup's low limit is ignored and we throttle the cgroup with its max limit. In this way, other cgroups with a low limit will not get protected. To fix this, we don't do the exception any more. cgroup will be throttled to a limit 0 if it uese default setting. To avoid completed stall, we give such cgroup tiny IO resources. Signed-off-by: Shaohua Li <shli@fb.com> Acked-by: Tejun Heo <tj@kernel.org> Signed-off-by: Jens Axboe <axboe@fb.com> | 22 May 2017, 20:47:12 UTC |
4cff729 | Shaohua Li | 17 May 2017, 20:07:25 UTC | blk-throttle: output some debug info in trace These info are important to understand what's happening and help debug. Signed-off-by: Shaohua Li <shli@fb.com> Acked-by: Tejun Heo <tj@kernel.org> Signed-off-by: Jens Axboe <axboe@fb.com> | 22 May 2017, 20:47:12 UTC |
5b81fc3 | Shaohua Li | 17 May 2017, 20:07:24 UTC | blk-throttle: add hierarchy support for latency target and idle time For idle time, children's setting should not be bigger than parent's. For latency target, children's setting should not be smaller than parent's. The leaf nodes will adjust their settings according to the hierarchy and compare their IO with the settings and do upgrade/downgrade. parents nodes don't need to track their IO latency/idle time. Signed-off-by: Shaohua Li <shli@fb.com> Acked-by: Tejun Heo <tj@kernel.org> Signed-off-by: Jens Axboe <axboe@fb.com> | 22 May 2017, 20:47:12 UTC |
4d6501d | Vegard Nossum | 09 May 2017, 07:39:59 UTC | kthread: Fix use-after-free if kthread fork fails If a kthread forks (e.g. usermodehelper since commit 1da5c46fa965) but fails in copy_process() between calling dup_task_struct() and setting p->set_child_tid, then the value of p->set_child_tid will be inherited from the parent and get prematurely freed by free_kthread_struct(). kthread() - worker_thread() - process_one_work() | - call_usermodehelper_exec_work() | - kernel_thread() | - _do_fork() | - copy_process() | - dup_task_struct() | - arch_dup_task_struct() | - tsk->set_child_tid = current->set_child_tid // implied | - ... | - goto bad_fork_* | - ... | - free_task(tsk) | - free_kthread_struct(tsk) | - kfree(tsk->set_child_tid) - ... - schedule() - __schedule() - wq_worker_sleeping() - kthread_data(task)->flags // UAF The problem started showing up with commit 1da5c46fa965 since it reused ->set_child_tid for the kthread worker data. A better long-term solution might be to get rid of the ->set_child_tid abuse. The comment in set_kthread_struct() also looks slightly wrong. Debugged-by: Jamie Iles <jamie.iles@oracle.com> Fixes: 1da5c46fa965 ("kthread: Make struct kthread kmalloc'ed") Signed-off-by: Vegard Nossum <vegard.nossum@oracle.com> Acked-by: Oleg Nesterov <oleg@redhat.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Andy Lutomirski <luto@kernel.org> Cc: Frederic Weisbecker <fweisbec@gmail.com> Cc: Jamie Iles <jamie.iles@oracle.com> Cc: stable@vger.kernel.org Link: http://lkml.kernel.org/r/20170509073959.17858-1-vegard.nossum@oracle.com Signed-off-by: Thomas Gleixner <tglx@linutronix.de> | 22 May 2017, 20:21:16 UTC |
04dc1b2 | Peter Zijlstra | 19 May 2017, 15:48:50 UTC | futex,rt_mutex: Fix rt_mutex_cleanup_proxy_lock() Markus reported that the glibc/nptl/tst-robustpi8 test was failing after commit: cfafcd117da0 ("futex: Rework futex_lock_pi() to use rt_mutex_*_proxy_lock()") The following trace shows the problem: ld-linux-x86-64-2161 [019] .... 410.760971: SyS_futex: 00007ffbeb76b028: 80000875 op=FUTEX_LOCK_PI ld-linux-x86-64-2161 [019] ...1 410.760972: lock_pi_update_atomic: 00007ffbeb76b028: curval=80000875 uval=80000875 newval=80000875 ret=0 ld-linux-x86-64-2165 [011] .... 410.760978: SyS_futex: 00007ffbeb76b028: 80000875 op=FUTEX_UNLOCK_PI ld-linux-x86-64-2165 [011] d..1 410.760979: do_futex: 00007ffbeb76b028: curval=80000875 uval=80000875 newval=80000871 ret=0 ld-linux-x86-64-2165 [011] .... 410.760980: SyS_futex: 00007ffbeb76b028: 80000871 ret=0000 ld-linux-x86-64-2161 [019] .... 410.760980: SyS_futex: 00007ffbeb76b028: 80000871 ret=ETIMEDOUT Task 2165 does an UNLOCK_PI, assigning the lock to the waiter task 2161 which then returns with -ETIMEDOUT. That wrecks the lock state, because now the owner isn't aware it acquired the lock and removes the pending robust list entry. If 2161 is killed, the robust list will not clear out this futex and the subsequent acquire on this futex will then (correctly) result in -ESRCH which is unexpected by glibc, triggers an internal assertion and dies. Task 2161 Task 2165 rt_mutex_wait_proxy_lock() timeout(); /* T2161 is still queued in the waiter list */ return -ETIMEDOUT; futex_unlock_pi() spin_lock(hb->lock); rtmutex_unlock() remove_rtmutex_waiter(T2161); mark_lock_available(); /* Make the next waiter owner of the user space side */ futex_uval = 2161; spin_unlock(hb->lock); spin_lock(hb->lock); rt_mutex_cleanup_proxy_lock() if (rtmutex_owner() !== current) ... return FAIL; .... return -ETIMEOUT; This means that rt_mutex_cleanup_proxy_lock() needs to call try_to_take_rt_mutex() so it can take over the rtmutex correctly which was assigned by the waker. If the rtmutex is owned by some other task then this call is harmless and just confirmes that the waiter is not able to acquire it. While there, fix what looks like a merge error which resulted in rt_mutex_cleanup_proxy_lock() having two calls to fixup_rt_mutex_waiters() and rt_mutex_wait_proxy_lock() not having any. Both should have one, since both potentially touch the waiter list. Fixes: 38d589f2fd08 ("futex,rt_mutex: Restructure rt_mutex_finish_proxy_lock()") Reported-by: Markus Trippelsdorf <markus@trippelsdorf.de> Bug-Spotted-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Cc: Florian Weimer <fweimer@redhat.com> Cc: Darren Hart <dvhart@infradead.org> Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Cc: Markus Trippelsdorf <markus@trippelsdorf.de> Link: http://lkml.kernel.org/r/20170519154850.mlomgdsd26drq5j6@hirez.programming.kicks-ass.net Signed-off-by: Thomas Gleixner <tglx@linutronix.de> | 22 May 2017, 19:57:18 UTC |
86ca984 | Linus Torvalds | 22 May 2017, 19:42:02 UTC | Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net Pull networking fixes from David Miller: "Mostly netfilter bug fixes in here, but we have some bits elsewhere as well. 1) Don't do SNAT replies for non-NATed connections in IPVS, from Julian Anastasov. 2) Don't delete conntrack helpers while they are still in use, from Liping Zhang. 3) Fix zero padding in xtables's xt_data_to_user(), from Willem de Bruijn. 4) Add proper RCU protection to nf_tables_dump_set() because we cannot guarantee that we hold the NFNL_SUBSYS_NFTABLES lock. From Liping Zhang. 5) Initialize rcv_mss in tcp_disconnect(), from Wei Wang. 6) smsc95xx devices can't handle IPV6 checksums fully, so don't advertise support for offloading them. From Nisar Sayed. 7) Fix out-of-bounds access in __ip6_append_data(), from Eric Dumazet. 8) Make atl2_probe() propagate the error code properly on failures, from Alexey Khoroshilov. 9) arp_target[] in bond_check_params() is used uninitialized. This got changes from a global static to a local variable, which is how this mistake happened. Fix from Jarod Wilson. 10) Fix fallout from unnecessary NULL check removal in cls_matchall, from Jiri Pirko. This is definitely brown paper bag territory..." * git://git.kernel.org/pub/scm/linux/kernel/git/davem/net: (26 commits) net: sched: cls_matchall: fix null pointer dereference vsock: use new wait API for vsock_stream_sendmsg() bonding: fix randomly populated arp target array net: Make IP alignment calulations clearer. bonding: fix accounting of active ports in 3ad net: atheros: atl2: don't return zero on failure path in atl2_probe() ipv6: fix out of bound writes in __ip6_append_data() bridge: start hello_timer when enabling KERNEL_STP in br_stp_start smsc95xx: Support only IPv4 TCP/UDP csum offload arp: always override existing neigh entries with gratuitous ARP arp: postpone addr_type calculation to as late as possible arp: decompose is_garp logic into a separate function arp: fixed error in a comment tcp: initialize rcv_mss to TCP_MIN_MSS instead of 0 netfilter: xtables: fix build failure from COMPAT_XT_ALIGN outside CONFIG_COMPAT ebtables: arpreply: Add the standard target sanity check netfilter: nf_tables: revisit chain/object refcounting from elements netfilter: nf_tables: missing sanitization in data from userspace netfilter: nf_tables: can't assume lock is acquired when dumping set elems netfilter: synproxy: fix conntrackd interaction ... | 22 May 2017, 19:42:02 UTC |
aace34c | Tin Huynh | 22 May 2017, 09:19:20 UTC | leds: pca955x: Correct I2C Functionality The driver checks an incorrect flag of functionality of adapter. When a driver requires i2c_smbus_read_byte_data and i2c_smbus_write_byte_data, it should check I2C_FUNC_SMBUS_BYTE_DATA instead I2C_FUNC_I2C. This patch fixes the problem. Signed-off-by: Tin Huynh <tnhuynh@apm.com> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com> | 22 May 2017, 19:12:44 UTC |
2cb657b | James Smart | 16 May 2017, 00:10:22 UTC | nvme_fc: remove extra controller reference taken on reconnect fix extra controller reference taken on reconnect by moving reference to initial controller create Signed-off-by: James Smart <james.smart@broadcom.com> Reviewed-by: Hannes Reinecke <hare@suse.com> Reviewed-by: Johannes Thumshirn <jthumshirn@suse.de> Signed-off-by: Christoph Hellwig <hch@lst.de> | 22 May 2017, 18:55:29 UTC |
e392e1f | James Smart | 16 May 2017, 00:10:24 UTC | nvme_fc: correct nvme status set on abort correct nvme status set on abort. Patch that changed status to being actual nvme status crossed in the night with the patch that added abort values. Signed-off-by: James Smart <james.smart@broadcom.com> Reviewed-by: Hannes Reinecke <hare@suse.com> Reviewed-by: Johannes Thumshirn <jthumshirn@suse.de> Signed-off-by: Christoph Hellwig <hch@lst.de> | 22 May 2017, 18:55:29 UTC |
589ff77 | James Smart | 16 May 2017, 00:10:19 UTC | nvme_fc: set logging level on resets/deletes Per the review by Sagi on: http://lists.infradead.org/pipermail/linux-nvme/2017-April/009261.html Looked at existing warn vs info vs err dev_xxx levels for the messages printed on reconnects and deletes: - Resets due to error and resets transitioned to deletes are dev_warn - Other reset/disconnect messages are dev_info - Removed chatty io queue related messages Signed-off-by: James Smart <james.smart@broadcom.com> Reviewed-by: Hannes Reinecke <hare@suse.com> Reviewed-by: Johannes Thumshirn <jthumshirn@suse.de> Signed-off-by: Christoph Hellwig <hch@lst.de> | 22 May 2017, 18:55:29 UTC |
a5321aa | James Smart | 16 May 2017, 00:10:18 UTC | nvme_fc: revise comment on teardown Per the recommendation by Sagi on: http://lists.infradead.org/pipermail/linux-nvme/2017-April/009261.html An extra reference was pointed out. There's no issue with the references, but rather a literal interpretation of what the comment is saying. Reword the comment to avoid confusion. Signed-off-by: James Smart <james.smart@broadcom.com> Reviewed-by: Johannes Thumshirn <jthumshirn@suse.de> Reviewed-by: Hannes Reinecke <hare@suse.com> Signed-off-by: Christoph Hellwig <hch@lst.de> | 22 May 2017, 18:55:29 UTC |
5bbecdb | James Smart | 16 May 2017, 00:10:16 UTC | nvme_fc: Support ctrl_loss_tmo Sync with Sagi's recent addition of ctrl_loss_tmo in the core fabrics layer. Remove local connect limits and connect_attempts variable. Use fabrics new nr_connects variable and use of nvmf_should_reconnect() Refactor duplicate reconnect failure code. Addresses review comment by Sagi on controller reset support: http://lists.infradead.org/pipermail/linux-nvme/2017-April/009261.html Signed-off-by: James Smart <james.smart@broadcom.com> Reviewed-by: Hannes Reinecke <hare@suse.com> Reviewed-by: Johannes Thumshirn <jthumshirn@suse.de> Signed-off-by: Christoph Hellwig <hch@lst.de> | 22 May 2017, 18:55:29 UTC |
0ce872b | James Smart | 16 May 2017, 00:10:15 UTC | nvme_fc: get rid of local reconnect_delay Remove the local copy of reconnect_delay. Use the value in the controller options directly. Signed-off-by: James Smart <james.smart@broadcom.com> Reviewed-by: Hannes Reinecke <hare@suse.com> Reviewed-by: Johannes Thumshirn <jthumshirn@suse.de> Signed-off-by: Christoph Hellwig <hch@lst.de> | 22 May 2017, 18:55:29 UTC |
2d76b2f | Jiri Pirko | 22 May 2017, 14:46:13 UTC | net: sched: cls_matchall: fix null pointer dereference Since the head is guaranteed by the check above to be null, the call_rcu would explode. Remove the previously logically dead code that was made logically very much alive and kicking. Fixes: 985538eee06f ("net/sched: remove redundant null check on head") Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net> | 22 May 2017, 18:54:16 UTC |
7254a50 | Ming Lei | 22 May 2017, 15:05:05 UTC | blk-mq: remove blk_mq_abort_requeue_list() No one uses it any more, so remove it. Reviewed-by: Keith Busch <keith.busch@intel.com> Reviewed-by: Johannes Thumshirn <jthumshirn@suse.de> Signed-off-by: Ming Lei <ming.lei@redhat.com> Signed-off-by: Christoph Hellwig <hch@lst.de> | 22 May 2017, 18:50:11 UTC |
986f75c | Ming Lei | 22 May 2017, 15:05:04 UTC | nvme: avoid to use blk_mq_abort_requeue_list() NVMe may add request into requeue list simply and not kick off the requeue if hw queues are stopped. Then blk_mq_abort_requeue_list() is called in both nvme_kill_queues() and nvme_ns_remove() for dealing with this issue. Unfortunately blk_mq_abort_requeue_list() is absolutely a race maker, for example, one request may be requeued during the aborting. So this patch just calls blk_mq_kick_requeue_list() in nvme_kill_queues() to handle this issue like what nvme_start_queues() does. Now all requests in requeue list when queues are stopped will be handled by blk_mq_kick_requeue_list() when queues are restarted, either in nvme_start_queues() or in nvme_kill_queues(). Cc: stable@vger.kernel.org Reported-by: Zhang Yi <yizhan@redhat.com> Reviewed-by: Keith Busch <keith.busch@intel.com> Reviewed-by: Johannes Thumshirn <jthumshirn@suse.de> Signed-off-by: Ming Lei <ming.lei@redhat.com> Signed-off-by: Christoph Hellwig <hch@lst.de> | 22 May 2017, 18:50:10 UTC |
806f026 | Ming Lei | 22 May 2017, 15:05:03 UTC | nvme: use blk_mq_start_hw_queues() in nvme_kill_queues() Inside nvme_kill_queues(), we have to start hw queues for draining requests in sw queues, .dispatch list and requeue list, so use blk_mq_start_hw_queues() instead of blk_mq_start_stopped_hw_queues() which only run queues if queues are stopped, but the queues may have been started already, for example nvme_start_queues() is called in reset work function. blk_mq_start_hw_queues() run hw queues in current context, instead of running asynchronously like before. Given nvme_kill_queues() is run from either remove context or reset worker context, both are fine to run hw queue directly. And the mutex of namespaces_mutex isn't a problem too becasue nvme_start_freeze() runs hw queue in this way already. Cc: stable@vger.kernel.org Reported-by: Zhang Yi <yizhan@redhat.com> Reviewed-by: Keith Busch <keith.busch@intel.com> Reviewed-by: Johannes Thumshirn <jthumshirn@suse.de> Signed-off-by: Ming Lei <ming.lei@redhat.com> Signed-off-by: Christoph Hellwig <hch@lst.de> | 22 May 2017, 18:50:09 UTC |
0544f54 | Marta Rybczynska | 10 April 2017, 15:12:34 UTC | nvme-rdma: support devices with queue size < 32 In the case of small NVMe-oF queue size (<32) we may enter a deadlock caused by the fact that the IB completions aren't sent waiting for 32 and the send queue will fill up. The error is seen as (using mlx5): [ 2048.693355] mlx5_0:mlx5_ib_post_send:3765:(pid 7273): [ 2048.693360] nvme nvme1: nvme_rdma_post_send failed with error code -12 This patch changes the way the signaling is done so that it depends on the queue depth now. The magic define has been removed completely. Cc: stable@vger.kernel.org Signed-off-by: Marta Rybczynska <marta.rybczynska@kalray.eu> Signed-off-by: Samuel Jones <sjones@kalray.eu> Acked-by: Sagi Grimberg <sagi@grimberg.me> Signed-off-by: Christoph Hellwig <hch@lst.de> | 22 May 2017, 18:49:49 UTC |
499fde6 | WANG Cong | 19 May 2017, 18:21:59 UTC | vsock: use new wait API for vsock_stream_sendmsg() As reported by Michal, vsock_stream_sendmsg() could still sleep at vsock_stream_has_space() after prepare_to_wait(): vsock_stream_has_space vmci_transport_stream_has_space vmci_qpair_produce_free_space qp_lock qp_acquire_queue_mutex mutex_lock Just switch to the new wait API like we did for commit d9dc8b0f8b4e ("net: fix sleeping for sk_wait_event()"). Reported-by: Michal Kubecek <mkubecek@suse.cz> Cc: Stefan Hajnoczi <stefanha@redhat.com> Cc: Jorgen Hansen <jhansen@vmware.com> Cc: "Michael S. Tsirkin" <mst@redhat.com> Cc: Claudio Imbrenda <imbrenda@linux.vnet.ibm.com> Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net> | 22 May 2017, 18:39:36 UTC |
72ccc47 | Jarod Wilson | 19 May 2017, 18:46:46 UTC | bonding: fix randomly populated arp target array In commit dc9c4d0fe023, the arp_target array moved from a static global to a local variable. By the nature of static globals, the array used to be initialized to all 0. At present, it's full of random data, which that gets interpreted as arp_target values, when none have actually been specified. Systems end up booting with spew along these lines: [ 32.161783] IPv6: ADDRCONF(NETDEV_UP): lacp0: link is not ready [ 32.168475] IPv6: ADDRCONF(NETDEV_UP): lacp0: link is not ready [ 32.175089] 8021q: adding VLAN 0 to HW filter on device lacp0 [ 32.193091] IPv6: ADDRCONF(NETDEV_UP): lacp0: link is not ready [ 32.204892] lacp0: Setting MII monitoring interval to 100 [ 32.211071] lacp0: Removing ARP target 216.124.228.17 [ 32.216824] lacp0: Removing ARP target 218.160.255.255 [ 32.222646] lacp0: Removing ARP target 185.170.136.184 [ 32.228496] lacp0: invalid ARP target 255.255.255.255 specified for removal [ 32.236294] lacp0: option arp_ip_target: invalid value (-255.255.255.255) [ 32.243987] lacp0: Removing ARP target 56.125.228.17 [ 32.249625] lacp0: Removing ARP target 218.160.255.255 [ 32.255432] lacp0: Removing ARP target 15.157.233.184 [ 32.261165] lacp0: invalid ARP target 255.255.255.255 specified for removal [ 32.268939] lacp0: option arp_ip_target: invalid value (-255.255.255.255) [ 32.276632] lacp0: Removing ARP target 16.0.0.0 [ 32.281755] lacp0: Removing ARP target 218.160.255.255 [ 32.287567] lacp0: Removing ARP target 72.125.228.17 [ 32.293165] lacp0: Removing ARP target 218.160.255.255 [ 32.298970] lacp0: Removing ARP target 8.125.228.17 [ 32.304458] lacp0: Removing ARP target 218.160.255.255 None of these were actually specified as ARP targets, and the driver does seem to clean up the mess okay, but it's rather noisy and confusing, leaks values to userspace, and the 255.255.255.255 spew shows up even when debug prints are disabled. The fix: just zero out arp_target at init time. While we're in here, init arp_all_targets_value in the right place. Fixes: dc9c4d0fe023 ("bonding: reduce scope of some global variables") CC: Mahesh Bandewar <maheshb@google.com> CC: Jay Vosburgh <j.vosburgh@gmail.com> CC: Veaceslav Falico <vfalico@gmail.com> CC: Andy Gospodarek <andy@greyhouse.net> CC: netdev@vger.kernel.org CC: stable@vger.kernel.org Signed-off-by: Jarod Wilson <jarod@redhat.com> Acked-by: Andy Gospodarek <andy@greyhouse.net> Signed-off-by: David S. Miller <davem@davemloft.net> | 22 May 2017, 18:38:22 UTC |
bb47e96 | Rafael J. Wysocki | 22 May 2017, 18:32:05 UTC | Merge branches 'pm-sleep' and 'powercap' * pm-sleep: PM / hibernate: Declare variables as static RTC: rtc-cmos: Fix wakeup from suspend-to-idle PM / wakeup: Fix up wakeup_source_report_event() * powercap: PowerCap: Fix an error code in powercap_register_zone() | 22 May 2017, 18:32:05 UTC |
e3170cc | Rafael J. Wysocki | 22 May 2017, 18:29:06 UTC | Merge branches 'acpi-button' and 'acpi-tools' * acpi-button: Revert "ACPI / button: Remove lid_init_state=method mode" * acpi-tools: tools/power/acpi: Add .gitignore file | 22 May 2017, 18:29:06 UTC |
079c181 | Rafael J. Wysocki | 22 May 2017, 18:28:22 UTC | Merge branches 'intel_pstate', 'pm-cpufreq' and 'pm-cpufreq-sched' * intel_pstate: cpufreq: intel_pstate: Document the current behavior and user interface * pm-cpufreq: cpufreq: dbx500: add a Kconfig symbol * pm-cpufreq-sched: cpufreq: schedutil: use now as reference when aggregating shared policy requests | 22 May 2017, 18:28:22 UTC |
e4eda88 | David S. Miller | 22 May 2017, 16:27:07 UTC | net: Make IP alignment calulations clearer. The assignmnet: ip_align = strict ? 2 : NET_IP_ALIGN; in compare_pkt_ptr_alignment() trips up Coverity because we can only get to this code when strict is true, therefore ip_align will always be 2 regardless of NET_IP_ALIGN's value. So just assign directly to '2' and explain the situation in the comment above. Reported-by: "Gustavo A. R. Silva" <garsilva@embeddedor.com> Signed-off-by: David S. Miller <davem@davemloft.net> | 22 May 2017, 16:27:07 UTC |
f5f968f | Srinath Mannam | 18 May 2017, 16:57:40 UTC | mmc: sdhci-iproc: suppress spurious interrupt with Multiblock read The stingray SDHCI hardware supports ACMD12 and automatically issues after multi block transfer completed. If ACMD12 in SDHCI is disabled, spurious tx done interrupts are seen on multi block read command with below error message: Got data interrupt 0x00000002 even though no data operation was in progress. This patch uses SDHCI_QUIRK_MULTIBLOCK_READ_ACMD12 to enable ACM12 support in SDHCI hardware and suppress spurious interrupt. Signed-off-by: Srinath Mannam <srinath.mannam@broadcom.com> Reviewed-by: Ray Jui <ray.jui@broadcom.com> Reviewed-by: Scott Branden <scott.branden@broadcom.com> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Fixes: b580c52d58d9 ("mmc: sdhci-iproc: add IPROC SDHCI driver") Cc: <stable@vger.kernel.org> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> | 22 May 2017, 16:18:04 UTC |
751da2a | Jarod Wilson | 19 May 2017, 23:43:45 UTC | bonding: fix accounting of active ports in 3ad As of 7bb11dc9f59d and 0622cab0341c, bond slaves in a 3ad bond are not removed from the aggregator when they are down, and the active slave count is NOT equal to number of ports in the aggregator, but rather the number of ports in the aggregator that are still enabled. The sysfs spew for bonding_show_ad_num_ports() has a comment that says "Show number of active 802.3ad ports.", but it's currently showing total number of ports, both active and inactive. Remedy it by using the same logic introduced in 0622cab0341c in __bond_3ad_get_active_agg_info(), so sysfs, procfs and netlink all report the number of active ports. Note that this means that IFLA_BOND_AD_INFO_NUM_PORTS really means NUM_ACTIVE_PORTS instead of NUM_PORTS, and thus perhaps should be renamed for clarity. Lightly tested on a dual i40e lacp bond, simulating link downs with an ip link set dev <slave2> down, was able to produce the state where I could see both in the same aggregator, but a number of ports count of 1. MII Status: up Active Aggregator Info: Aggregator ID: 1 Number of ports: 2 <--- Slave Interface: ens10 MII Status: up <--- Aggregator ID: 1 Slave Interface: ens11 MII Status: up Aggregator ID: 1 MII Status: up Active Aggregator Info: Aggregator ID: 1 Number of ports: 1 <--- Slave Interface: ens10 MII Status: down <--- Aggregator ID: 1 Slave Interface: ens11 MII Status: up Aggregator ID: 1 CC: Jay Vosburgh <j.vosburgh@gmail.com> CC: Veaceslav Falico <vfalico@gmail.com> CC: Andy Gospodarek <andy@greyhouse.net> CC: netdev@vger.kernel.org Signed-off-by: Jarod Wilson <jarod@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net> | 22 May 2017, 16:05:39 UTC |
bd703a1 | Alexey Khoroshilov | 19 May 2017, 22:52:11 UTC | net: atheros: atl2: don't return zero on failure path in atl2_probe() If dma mask checks fail in atl2_probe(), it breaks off initialization, deallocates all resources, but returns zero. The patch adds proper error code return value and make error code setup unified. Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by: Alexey Khoroshilov <khoroshilov@ispras.ru> Signed-off-by: David S. Miller <davem@davemloft.net> | 22 May 2017, 16:05:01 UTC |
8fb83b1 | Jan Glauber | 22 May 2017, 11:09:21 UTC | mmc: cavium: Fix probing race with regulator If the regulator probing is not yet finished this driver might catch a -EPROBE_DEFER. Returning after this condition did not remove the created platform device. On a repeated call to the probe function the of_platform_device_create fails. Calling of_platform_device_destroy after EPROBE_DEFER resolves this bug. Signed-off-by: Jan Glauber <jglauber@cavium.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> | 22 May 2017, 16:01:46 UTC |
c2372c2 | Jan Glauber | 22 May 2017, 11:09:20 UTC | of/platform: Make of_platform_device_destroy globally visible of_platform_device_destroy is the counterpart to of_platform_device_create which is a non-static function. After creating a platform device it might be neccessary to destroy it to deal with -EPROBE_DEFER where a repeated of_platform_device_create call would fail otherwise. Therefore also make of_platform_device_destroy globally visible. Signed-off-by: Jan Glauber <jglauber@cavium.com> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> | 22 May 2017, 16:01:46 UTC |
9e7b9a2 | Jan Glauber | 22 May 2017, 11:09:19 UTC | mmc: cavium: Prevent crash with incomplete DT In case the DT specifies neither a regulator nor a gpio for the shared power the driver will crash accessing the regulator. Prevent the crash by checking the regulator before use. Use mmc_regulator_get_supply() instead of open coding the same logic. Signed-off-by: Jan Glauber <jglauber@cavium.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> | 22 May 2017, 16:01:46 UTC |
232cd35 | Eric Dumazet | 19 May 2017, 21:17:48 UTC | ipv6: fix out of bound writes in __ip6_append_data() Andrey Konovalov and idaifish@gmail.com reported crashes caused by one skb shared_info being overwritten from __ip6_append_data() Andrey program lead to following state : copy -4200 datalen 2000 fraglen 2040 maxfraglen 2040 alloclen 2048 transhdrlen 0 offset 0 fraggap 6200 The skb_copy_and_csum_bits(skb_prev, maxfraglen, data + transhdrlen, fraggap, 0); is overwriting skb->head and skb_shared_info Since we apparently detect this rare condition too late, move the code earlier to even avoid allocating skb and risking crashes. Once again, many thanks to Andrey and syzkaller team. Signed-off-by: Eric Dumazet <edumazet@google.com> Reported-by: Andrey Konovalov <andreyknvl@google.com> Tested-by: Andrey Konovalov <andreyknvl@google.com> Reported-by: <idaifish@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net> | 22 May 2017, 15:47:44 UTC |
a79e7df | Takashi Iwai | 22 May 2017, 14:41:24 UTC | ALSA: hda - Update the list of quirk models I've forgotten to sync the documentation with the actually available options for some time. Now all updated. Signed-off-by: Takashi Iwai <tiwai@suse.de> | 22 May 2017, 14:42:02 UTC |
ba90d6a | Takashi Iwai | 22 May 2017, 14:38:47 UTC | ALSA: hda - Provide dual-codecs model option for a few Realtek codecs Recently some laptops and mobos are equipped with the dual Realtek codecs that require special quirks. For making the debugging easier, add the model "dual-codecs" to be passed via module option. Signed-off-by: Takashi Iwai <tiwai@suse.de> | 22 May 2017, 14:38:47 UTC |
6369158 | Takashi Iwai | 22 May 2017, 14:32:46 UTC | ALSA: hda - Apply dual-codec quirk for MSI Z270-Gaming mobo MSI Z270-Gamin mobo has also two ALC1220 codecs like Gigabyte AZ370- Gaming mobo. Apply the same quirk to this one. Signed-off-by: Takashi Iwai <tiwai@suse.de> | 22 May 2017, 14:36:00 UTC |
e2c8249 | Jan Kiszka | 22 May 2017, 05:46:55 UTC | i2c: designware: Fix bogus sda_hold_time due to uninitialized vars We need to initializes those variables to 0 for platforms that do not provide ACPI parameters. Otherwise, we set sda_hold_time to random values, breaking e.g. Galileo and IOT2000 boards. Fixes: 9d6408433019 ("i2c: designware: don't infer timings described by ACPI from clock rate") Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Acked-by: Jarkko Nikula <jarkko.nikula@linux.intel.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de> | 22 May 2017, 08:35:51 UTC |
5165da5 | Sebastian Reichel | 05 May 2017, 09:06:50 UTC | i2c: i2c-tiny-usb: fix buffer not being DMA capable Since v4.9 i2c-tiny-usb generates the below call trace and longer works, since it can't communicate with the USB device. The reason is, that since v4.9 the USB stack checks, that the buffer it should transfer is DMA capable. This was a requirement since v2.2 days, but it usually worked nevertheless. [ 17.504959] ------------[ cut here ]------------ [ 17.505488] WARNING: CPU: 0 PID: 93 at drivers/usb/core/hcd.c:1587 usb_hcd_map_urb_for_dma+0x37c/0x570 [ 17.506545] transfer buffer not dma capable [ 17.507022] Modules linked in: [ 17.507370] CPU: 0 PID: 93 Comm: i2cdetect Not tainted 4.11.0-rc8+ #10 [ 17.508103] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1 04/01/2014 [ 17.509039] Call Trace: [ 17.509320] ? dump_stack+0x5c/0x78 [ 17.509714] ? __warn+0xbe/0xe0 [ 17.510073] ? warn_slowpath_fmt+0x5a/0x80 [ 17.510532] ? nommu_map_sg+0xb0/0xb0 [ 17.510949] ? usb_hcd_map_urb_for_dma+0x37c/0x570 [ 17.511482] ? usb_hcd_submit_urb+0x336/0xab0 [ 17.511976] ? wait_for_completion_timeout+0x12f/0x1a0 [ 17.512549] ? wait_for_completion_timeout+0x65/0x1a0 [ 17.513125] ? usb_start_wait_urb+0x65/0x160 [ 17.513604] ? usb_control_msg+0xdc/0x130 [ 17.514061] ? usb_xfer+0xa4/0x2a0 [ 17.514445] ? __i2c_transfer+0x108/0x3c0 [ 17.514899] ? i2c_transfer+0x57/0xb0 [ 17.515310] ? i2c_smbus_xfer_emulated+0x12f/0x590 [ 17.515851] ? _raw_spin_unlock_irqrestore+0x11/0x20 [ 17.516408] ? i2c_smbus_xfer+0x125/0x330 [ 17.516876] ? i2c_smbus_xfer+0x125/0x330 [ 17.517329] ? i2cdev_ioctl_smbus+0x1c1/0x2b0 [ 17.517824] ? i2cdev_ioctl+0x75/0x1c0 [ 17.518248] ? do_vfs_ioctl+0x9f/0x600 [ 17.518671] ? vfs_write+0x144/0x190 [ 17.519078] ? SyS_ioctl+0x74/0x80 [ 17.519463] ? entry_SYSCALL_64_fastpath+0x1e/0xad [ 17.519959] ---[ end trace d047c04982f5ac50 ]--- Cc: <stable@vger.kernel.org> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Acked-by: Till Harbaum <till@harbaum.org> Signed-off-by: Wolfram Sang <wsa@the-dreams.de> | 22 May 2017, 08:33:42 UTC |