https://github.com/torvalds/linux
- HEAD
- refs/heads/arm64-uaccess
- refs/heads/dependabot/pip/drivers/gpu/drm/ci/xfails/certifi-2024.7.4
- refs/heads/dependabot/pip/drivers/gpu/drm/ci/xfails/idna-3.7
- refs/heads/dependabot/pip/drivers/gpu/drm/ci/xfails/requests-2.32.2
- refs/heads/dependabot/pip/drivers/gpu/drm/ci/xfails/setuptools-70.0.0
- refs/heads/dependabot/pip/drivers/gpu/drm/ci/xfails/urllib3-2.2.2
- refs/heads/master
- 09162bc32c880a791c6c0668ce0745cf7958f576
- v6.9-rc7
- v6.9-rc6
- v6.9-rc5
- v6.9-rc4
- v6.9-rc3
- v6.9-rc2
- v6.9-rc1
- v6.9
- 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.11-rc3
- v6.11-rc2
- v6.11-rc1
- v6.10-rc7
- v6.10-rc6
- v6.10-rc5
- v6.10-rc4
- v6.10-rc3
- v6.10-rc2
- v6.10-rc1
- v6.10
- 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.![swh spinner](/static/img/swh-spinner.gif)
Processing "take a new snapshot" request ...
Revision | Author | Date | Message | Commit Date |
---|---|---|---|---|
09162bc | Linus Torvalds | 16 November 2020, 00:44:31 UTC | Linux 5.10-rc4 | 16 November 2020, 00:44:31 UTC |
a6af871 | Linus Torvalds | 15 November 2020, 21:07:36 UTC | Merge tag 'drm-fixes-2020-11-16' of git://anongit.freedesktop.org/drm/drm Pull drm fixes from Dave Airlie: "Nouveau fixes: - atomic modesetting regression fix - ttm pre-nv50 fix - connector NULL ptr deref fix" * tag 'drm-fixes-2020-11-16' of git://anongit.freedesktop.org/drm/drm: drm/nouveau/kms/nv50-: Use atomic encoder callbacks everywhere drm/nouveau/ttm: avoid using nouveau_drm.ttm.type_vram prior to nv50 drm/nouveau/kms: Fix NULL pointer dereference in nouveau_connector_detect_depth | 15 November 2020, 21:07:36 UTC |
8f598d1 | Dave Airlie | 15 November 2020, 20:36:23 UTC | Merge branch 'linux-5.10' of git://github.com/skeggsb/linux into drm-fixes - atomic modesetting regression fix - ttm pre-nv50 fix - connector NULL ptr deref fix Signed-off-by: Dave Airlie <airlied@redhat.com> From: Ben Skeggs <skeggsb@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/CACAvsv5D9p78MNN0OxVeRZxN8LDqcadJEGUEFCgWJQ6+_rjPuw@mail.gmail.com | 15 November 2020, 20:36:31 UTC |
9cfd9c4 | Linus Torvalds | 15 November 2020, 18:15:17 UTC | Merge tag 'char-misc-5.10-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc Pull char/misc driver fixes from Greg KH: "Here are some small char/misc/whatever driver fixes for 5.10-rc4. Nothing huge, lots of small fixes for reported issues: - habanalabs driver fixes - speakup driver fixes - uio driver fixes - virtio driver fix - other tiny driver fixes Full details are in the shortlog. All of these have been in linux-next for a full week with no reported issues" * tag 'char-misc-5.10-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc: uio: Fix use-after-free in uio_unregister_device() firmware: xilinx: fix out-of-bounds access nitro_enclaves: Fixup type and simplify logic of the poll mask setup speakup ttyio: Do not schedule() in ttyio_in_nowait speakup: Fix clearing selection in safe context speakup: Fix var_id_t values and thus keymap virtio: virtio_console: fix DMA memory allocation for rproc serial habanalabs/gaudi: mask WDT error in QMAN habanalabs/gaudi: move coresight mmu config habanalabs: fix kernel pointer type mei: protect mei_cl_mtu from null dereference | 15 November 2020, 18:15:17 UTC |
281b3ec | Linus Torvalds | 15 November 2020, 18:02:41 UTC | Merge tag 'usb-5.10-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb Pull USB and Thunderbolt fixes from Greg KH: "Here are some small Thunderbolt and USB driver fixes for 5.10-rc4 to solve some reported issues. Nothing huge in here, just small things: - thunderbolt memory leaks fixed and new device ids added - revert of problem patch for the musb driver - new quirks added for USB devices - typec power supply fixes to resolve much reported problems about charging notifications not working anymore All except the cdc-acm driver quirk addition have been in linux-next with no reported issues (the quirk patch was applied on Friday, and is self-contained)" * tag 'usb-5.10-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb: usb: cdc-acm: Add DISABLE_ECHO for Renesas USB Download mode MAINTAINERS: add usb raw gadget entry usb: typec: ucsi: Report power supply changes xhci: hisilicon: fix refercence leak in xhci_histb_probe Revert "usb: musb: convert to devm_platform_ioremap_resource_byname" thunderbolt: Add support for Intel Tiger Lake-H thunderbolt: Only configure USB4 wake for lane 0 adapters thunderbolt: Add uaccess dependency to debugfs interface thunderbolt: Fix memory leak if ida_simple_get() fails in enumerate_services() thunderbolt: Add the missed ida_simple_remove() in ring_request_msix() | 15 November 2020, 18:02:41 UTC |
0062442 | Linus Torvalds | 15 November 2020, 17:57:58 UTC | Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm Pull kvm fixes from Paolo Bonzini: "Fixes for ARM and x86, the latter especially for old processors without two-dimensional paging (EPT/NPT)" * tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm: kvm: mmu: fix is_tdp_mmu_check when the TDP MMU is not in use KVM: SVM: Update cr3_lm_rsvd_bits for AMD SEV guests KVM: x86: Introduce cr3_lm_rsvd_bits in kvm_vcpu_arch KVM: x86: clflushopt should be treated as a no-op by emulation KVM: arm64: Handle SCXTNUM_ELx traps KVM: arm64: Unify trap handlers injecting an UNDEF KVM: arm64: Allow setting of ID_AA64PFR0_EL1.CSV2 from userspace | 15 November 2020, 17:57:58 UTC |
326fd6d | Linus Torvalds | 15 November 2020, 17:49:56 UTC | Merge tag 'x86-urgent-2020-11-15' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull x86 fixes from Thomas Gleixner: "A small set of fixes for x86: - Cure the fallout from the MSI irqdomain overhaul which missed that the Intel IOMMU does not register virtual function devices and therefore never reaches the point where the MSI interrupt domain is assigned. This made the VF devices use the non-remapped MSI domain which is trapped by the IOMMU/remap unit - Remove an extra space in the SGI_UV architecture type procfs output for UV5 - Remove a unused function which was missed when removing the UV BAU TLB shootdown handler" * tag 'x86-urgent-2020-11-15' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: iommu/vt-d: Cure VF irqdomain hickup x86/platform/uv: Fix copied UV5 output archtype x86/platform/uv: Drop last traces of uv_flush_tlb_others | 15 November 2020, 17:49:56 UTC |
64b609d | Linus Torvalds | 15 November 2020, 17:46:36 UTC | Merge tag 'perf-urgent-2020-11-15' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull perf fixes from Thomas Gleixner: "A set of fixes for perf: - A set of commits which reduce the stack usage of various perf event handling functions which allocated large data structs on stack causing stack overflows in the worst case - Use the proper mechanism for detecting soft interrupts in the recursion protection - Make the resursion protection simpler and more robust - Simplify the scheduling of event groups to make the code more robust and prepare for fixing the issues vs. scheduling of exclusive event groups - Prevent event multiplexing and rotation for exclusive event groups - Correct the perf event attribute exclusive semantics to take pinned events, e.g. the PMU watchdog, into account - Make the anythread filtering conditional for Intel's generic PMU counters as it is not longer guaranteed to be supported on newer CPUs. Check the corresponding CPUID leaf to make sure - Fixup a duplicate initialization in an array which was probably caused by the usual 'copy & paste - forgot to edit' mishap" * tag 'perf-urgent-2020-11-15' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: perf/x86/intel/uncore: Fix Add BW copypasta perf/x86/intel: Make anythread filter support conditional perf: Tweak perf_event_attr::exclusive semantics perf: Fix event multiplexing for exclusive groups perf: Simplify group_sched_in() perf: Simplify group_sched_out() perf/x86: Make dummy_iregs static perf/arch: Remove perf_sample_data::regs_user_copy perf: Optimize get_recursion_context() perf: Fix get_recursion_context() perf/x86: Reduce stack usage for x86_pmu::drain_pebs() perf: Reduce stack usage of perf_output_begin() | 15 November 2020, 17:46:36 UTC |
d0a37fd | Linus Torvalds | 15 November 2020, 17:39:35 UTC | Merge tag 'sched-urgent-2020-11-15' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull scheduler fixes from Thomas Gleixner: "A set of scheduler fixes: - Address a load balancer regression by making the load balancer use the same logic as the wakeup path to spread tasks in the LLC domain - Prefer the CPU on which a task run last over the local CPU in the fast wakeup path for asymmetric CPU capacity systems to align with the symmetric case. This ensures more locality and prevents massive migration overhead on those asymetric systems - Fix a memory corruption bug in the scheduler debug code caused by handing a modified buffer pointer to kfree()" * tag 'sched-urgent-2020-11-15' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: sched/debug: Fix memory corruption caused by multiple small reads of flags sched/fair: Prefer prev cpu in asymmetric wakeup path sched/fair: Ensure tasks spreading in LLC during LB | 15 November 2020, 17:39:35 UTC |
259c2fb | Linus Torvalds | 15 November 2020, 17:25:43 UTC | Merge tag 'locking-urgent-2020-11-15' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull locking fixes from Thomas Gleixner: "Two fixes for the locking subsystem: - Prevent an unconditional interrupt enable in a futex helper function which can be called from contexts which expect interrupts to stay disabled across the call - Don't modify lockdep chain keys in the validation process as that causes chain inconsistency" * tag 'locking-urgent-2020-11-15' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: lockdep: Avoid to modify chain keys in validate_chain() futex: Don't enable IRQs unconditionally in put_pi_state() | 15 November 2020, 17:25:43 UTC |
a50cf15 | Linus Torvalds | 15 November 2020, 16:57:19 UTC | Merge branch 'for-5.10-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/dennis/percpu Pull percpu fix and cleanup from Dennis Zhou: "A fix for a Wshadow warning in the asm-generic percpu macros came in and then I tacked on the removal of flexible array initializers in the percpu allocator" * 'for-5.10-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/dennis/percpu: percpu: convert flexible array initializers to use struct_size() asm-generic: percpu: avoid Wshadow warning | 15 November 2020, 16:57:19 UTC |
c887c9b | Paolo Bonzini | 15 November 2020, 13:55:43 UTC | kvm: mmu: fix is_tdp_mmu_check when the TDP MMU is not in use In some cases where shadow paging is in use, the root page will be either mmu->pae_root or vcpu->arch.mmu->lm_root. Then it will not have an associated struct kvm_mmu_page, because it is allocated with alloc_page instead of kvm_mmu_alloc_page. Just return false quickly from is_tdp_mmu_root if the TDP MMU is not in use, which also includes the case where shadow paging is enabled. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> | 15 November 2020, 13:55:43 UTC |
e28c0d7 | Linus Torvalds | 14 November 2020, 20:35:11 UTC | Merge branch 'akpm' (patches from Andrew) Merge fixes from Andrew Morton: "14 patches. Subsystems affected by this patch series: mm (migration, vmscan, slub, gup, memcg, hugetlbfs), mailmap, kbuild, reboot, watchdog, panic, and ocfs2" * emailed patches from Andrew Morton <akpm@linux-foundation.org>: ocfs2: initialize ip_next_orphan panic: don't dump stack twice on warn hugetlbfs: fix anon huge page migration race mm: memcontrol: fix missing wakeup polling thread kernel/watchdog: fix watchdog_allowed_mask not used warning reboot: fix overflow parsing reboot cpu number Revert "kernel/reboot.c: convert simple_strtoul to kstrtoint" compiler.h: fix barrier_data() on clang mm/gup: use unpin_user_pages() in __gup_longterm_locked() mm/slub: fix panic in slab_alloc_node() mailmap: fix entry for Dmitry Baryshkov/Eremin-Solenikov mm/vmscan: fix NR_ISOLATED_FILE corruption on 64-bit mm/compaction: stop isolation if too many pages are isolated and we have pages to migrate mm/compaction: count pages and stop correctly during page isolation | 14 November 2020, 20:35:11 UTC |
31908a6 | Linus Torvalds | 14 November 2020, 20:30:18 UTC | Merge tag 'clk-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux Pull clk fixes from Stephen Boyd: "Two small clk driver fixes: - Make to_clk_regmap() inline to avoid compiler annoyance - Fix critical clks on i.MX imx8m SoCs" * tag 'clk-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux: clk: imx8m: fix bus critical clk registration clk: define to_clk_regmap() as inline function | 14 November 2020, 20:30:18 UTC |
7e908b7 | Linus Torvalds | 14 November 2020, 20:25:39 UTC | Merge tag 'hwmon-for-v5.10-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging Pull hwmon fixes from Guenter Roeck: - Fix potential bufer overflow in pmbus/max20730 driver - Fix locking issue in pmbus core - Fix regression causing timeouts in applesmc driver - Fix RPM calculation in pwm-fan driver - Restrict counter visibility in amd_energy driver * tag 'hwmon-for-v5.10-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging: hwmon: (amd_energy) modify the visibility of the counters hwmon: (applesmc) Re-work SMC comms hwmon: (pwm-fan) Fix RPM calculation hwmon: (pmbus) Add mutex locking for sysfs reads hwmon: (pmbus/max20730) use scnprintf() instead of snprintf() | 14 November 2020, 20:25:39 UTC |
0c04511 | Linus Torvalds | 14 November 2020, 20:19:21 UTC | Merge tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi Pull SCSI fixes from James Bottomley: "Three small fixes, all in the embedded ufs driver subsystem" * tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi: scsi: ufshcd: Fix missing destroy_workqueue() scsi: ufs: Try to save power mode change and UIC cmd completion timeout scsi: ufs: Fix unbalanced scsi_block_reqs_cnt caused by ufshcd_hold() | 14 November 2020, 20:19:21 UTC |
30636a5 | Linus Torvalds | 14 November 2020, 20:04:02 UTC | Merge tag 'selinux-pr-20201113' of git://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/selinux Pull selinux fix from Paul Moore: "One small SELinux patch to make sure we return an error code when an allocation fails. It passes all of our tests, but given the nature of the patch that isn't surprising" * tag 'selinux-pr-20201113' of git://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/selinux: selinux: Fix error return code in sel_ib_pkey_sid_slow() | 14 November 2020, 20:04:02 UTC |
4aea779 | Linus Torvalds | 14 November 2020, 19:56:59 UTC | Merge tag 'for-linus-5.10-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/rw/uml Pull uml fix from Richard Weinberger: "Call PMD destructor in __pmd_free_tlb()" * tag 'for-linus-5.10-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/rw/uml: um: Call pgtable_pmd_page_dtor() in __pmd_free_tlb() | 14 November 2020, 19:56:59 UTC |
3ad216e | David Howells | 14 November 2020, 17:27:57 UTC | afs: Fix afs_write_end() when called with copied == 0 [ver #3] When afs_write_end() is called with copied == 0, it tries to set the dirty region, but there's no way to actually encode a 0-length region in the encoding in page->private. "0,0", for example, indicates a 1-byte region at offset 0. The maths miscalculates this and sets it incorrectly. Fix it to just do nothing but unlock and put the page in this case. We don't actually need to mark the page dirty as nothing presumably changed. Fixes: 65dd2d6072d3 ("afs: Alter dirty range encoding in page->private") Signed-off-by: David Howells <dhowells@redhat.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> | 14 November 2020, 19:51:18 UTC |
f578528 | Wengang Wang | 14 November 2020, 06:52:23 UTC | ocfs2: initialize ip_next_orphan Though problem if found on a lower 4.1.12 kernel, I think upstream has same issue. In one node in the cluster, there is the following callback trace: # cat /proc/21473/stack __ocfs2_cluster_lock.isra.36+0x336/0x9e0 [ocfs2] ocfs2_inode_lock_full_nested+0x121/0x520 [ocfs2] ocfs2_evict_inode+0x152/0x820 [ocfs2] evict+0xae/0x1a0 iput+0x1c6/0x230 ocfs2_orphan_filldir+0x5d/0x100 [ocfs2] ocfs2_dir_foreach_blk+0x490/0x4f0 [ocfs2] ocfs2_dir_foreach+0x29/0x30 [ocfs2] ocfs2_recover_orphans+0x1b6/0x9a0 [ocfs2] ocfs2_complete_recovery+0x1de/0x5c0 [ocfs2] process_one_work+0x169/0x4a0 worker_thread+0x5b/0x560 kthread+0xcb/0xf0 ret_from_fork+0x61/0x90 The above stack is not reasonable, the final iput shouldn't happen in ocfs2_orphan_filldir() function. Looking at the code, 2067 /* Skip inodes which are already added to recover list, since dio may 2068 * happen concurrently with unlink/rename */ 2069 if (OCFS2_I(iter)->ip_next_orphan) { 2070 iput(iter); 2071 return 0; 2072 } 2073 The logic thinks the inode is already in recover list on seeing ip_next_orphan is non-NULL, so it skip this inode after dropping a reference which incremented in ocfs2_iget(). While, if the inode is already in recover list, it should have another reference and the iput() at line 2070 should not be the final iput (dropping the last reference). So I don't think the inode is really in the recover list (no vmcore to confirm). Note that ocfs2_queue_orphans(), though not shown up in the call back trace, is holding cluster lock on the orphan directory when looking up for unlinked inodes. The on disk inode eviction could involve a lot of IOs which may need long time to finish. That means this node could hold the cluster lock for very long time, that can lead to the lock requests (from other nodes) to the orhpan directory hang for long time. Looking at more on ip_next_orphan, I found it's not initialized when allocating a new ocfs2_inode_info structure. This causes te reflink operations from some nodes hang for very long time waiting for the cluster lock on the orphan directory. Fix: initialize ip_next_orphan as NULL. Signed-off-by: Wengang Wang <wen.gang.wang@oracle.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Reviewed-by: Joseph Qi <joseph.qi@linux.alibaba.com> Cc: Mark Fasheh <mark@fasheh.com> Cc: Joel Becker <jlbec@evilplan.org> Cc: Junxiao Bi <junxiao.bi@oracle.com> Cc: Changwei Ge <gechangwei@live.cn> Cc: Gang He <ghe@suse.com> Cc: Jun Piao <piaojun@huawei.com> Cc: <stable@vger.kernel.org> Link: https://lkml.kernel.org/r/20201109171746.27884-1-wen.gang.wang@oracle.com Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> | 14 November 2020, 19:26:04 UTC |
2f31ad6 | Christophe Leroy | 14 November 2020, 06:52:20 UTC | panic: don't dump stack twice on warn Before commit 3f388f28639f ("panic: dump registers on panic_on_warn"), __warn() was calling show_regs() when regs was not NULL, and show_stack() otherwise. After that commit, show_stack() is called regardless of whether show_regs() has been called or not, leading to duplicated Call Trace: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 1 at arch/powerpc/mm/nohash/8xx.c:186 mmu_mark_initmem_nx+0x24/0x94 CPU: 0 PID: 1 Comm: swapper Not tainted 5.10.0-rc2-s3k-dev-01375-gf46ec0d3ecbd-dirty #4092 NIP: c00128b4 LR: c0010228 CTR: 00000000 REGS: c9023e40 TRAP: 0700 Not tainted (5.10.0-rc2-s3k-dev-01375-gf46ec0d3ecbd-dirty) MSR: 00029032 <EE,ME,IR,DR,RI> CR: 24000424 XER: 00000000 GPR00: c0010228 c9023ef8 c2100000 0074c000 ffffffff 00000000 c2151000 c07b3880 GPR08: ff000900 0074c000 c8000000 c33b53a8 24000822 00000000 c0003a20 00000000 GPR16: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 GPR24: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00800000 NIP [c00128b4] mmu_mark_initmem_nx+0x24/0x94 LR [c0010228] free_initmem+0x20/0x58 Call Trace: free_initmem+0x20/0x58 kernel_init+0x1c/0x114 ret_from_kernel_thread+0x14/0x1c Instruction dump: 7d291850 7d234b78 4e800020 9421ffe0 7c0802a6 bfc10018 3fe0c060 3bff0000 3fff4080 3bffffff 90010024 57ff0010 <0fe00000> 392001cd 7c3e0b78 953e0008 CPU: 0 PID: 1 Comm: swapper Not tainted 5.10.0-rc2-s3k-dev-01375-gf46ec0d3ecbd-dirty #4092 Call Trace: __warn+0x8c/0xd8 (unreliable) report_bug+0x11c/0x154 program_check_exception+0x1dc/0x6e0 ret_from_except_full+0x0/0x4 --- interrupt: 700 at mmu_mark_initmem_nx+0x24/0x94 LR = free_initmem+0x20/0x58 free_initmem+0x20/0x58 kernel_init+0x1c/0x114 ret_from_kernel_thread+0x14/0x1c ---[ end trace 31702cd2a9570752 ]--- Only call show_stack() when regs is NULL. Fixes: 3f388f28639f ("panic: dump registers on panic_on_warn") Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Cc: Alexey Kardashevskiy <aik@ozlabs.ru> Cc: Kefeng Wang <wangkefeng.wang@huawei.com> Link: https://lkml.kernel.org/r/e8c055458b080707f1bc1a98ff8bea79d0cec445.1604748361.git.christophe.leroy@csgroup.eu Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> | 14 November 2020, 19:26:04 UTC |
336bf30 | Mike Kravetz | 14 November 2020, 06:52:16 UTC | hugetlbfs: fix anon huge page migration race Qian Cai reported the following BUG in [1] LTP: starting move_pages12 BUG: unable to handle page fault for address: ffffffffffffffe0 ... RIP: 0010:anon_vma_interval_tree_iter_first+0xa2/0x170 avc_start_pgoff at mm/interval_tree.c:63 Call Trace: rmap_walk_anon+0x141/0xa30 rmap_walk_anon at mm/rmap.c:1864 try_to_unmap+0x209/0x2d0 try_to_unmap at mm/rmap.c:1763 migrate_pages+0x1005/0x1fb0 move_pages_and_store_status.isra.47+0xd7/0x1a0 __x64_sys_move_pages+0xa5c/0x1100 do_syscall_64+0x5f/0x310 entry_SYSCALL_64_after_hwframe+0x44/0xa9 Hugh Dickins diagnosed this as a migration bug caused by code introduced to use i_mmap_rwsem for pmd sharing synchronization. Specifically, the routine unmap_and_move_huge_page() is always passing the TTU_RMAP_LOCKED flag to try_to_unmap() while holding i_mmap_rwsem. This is wrong for anon pages as the anon_vma_lock should be held in this case. Further analysis suggested that i_mmap_rwsem was not required to he held at all when calling try_to_unmap for anon pages as an anon page could never be part of a shared pmd mapping. Discussion also revealed that the hack in hugetlb_page_mapping_lock_write to drop page lock and acquire i_mmap_rwsem is wrong. There is no way to keep mapping valid while dropping page lock. This patch does the following: - Do not take i_mmap_rwsem and set TTU_RMAP_LOCKED for anon pages when calling try_to_unmap. - Remove the hacky code in hugetlb_page_mapping_lock_write. The routine will now simply do a 'trylock' while still holding the page lock. If the trylock fails, it will return NULL. This could impact the callers: - migration calling code will receive -EAGAIN and retry up to the hard coded limit (10). - memory error code will treat the page as BUSY. This will force killing (SIGKILL) instead of SIGBUS any mapping tasks. Do note that this change in behavior only happens when there is a race. None of the standard kernel testing suites actually hit this race, but it is possible. [1] https://lore.kernel.org/lkml/20200708012044.GC992@lca.pw/ [2] https://lore.kernel.org/linux-mm/alpine.LSU.2.11.2010071833100.2214@eggly.anvils/ Fixes: c0d0381ade79 ("hugetlbfs: use i_mmap_rwsem for more pmd sharing synchronization") Reported-by: Qian Cai <cai@lca.pw> Suggested-by: Hugh Dickins <hughd@google.com> Signed-off-by: Mike Kravetz <mike.kravetz@oracle.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Acked-by: Naoya Horiguchi <naoya.horiguchi@nec.com> Cc: <stable@vger.kernel.org> Link: https://lkml.kernel.org/r/20201105195058.78401-1-mike.kravetz@oracle.com Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> | 14 November 2020, 19:26:04 UTC |
8b21ca0 | Muchun Song | 14 November 2020, 06:52:13 UTC | mm: memcontrol: fix missing wakeup polling thread When we poll the swap.events, we can miss being woken up when the swap event occurs. Because we didn't notify. Fixes: f3a53a3a1e5b ("mm, memcontrol: implement memory.swap.events") Signed-off-by: Muchun Song <songmuchun@bytedance.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Reviewed-by: Shakeel Butt <shakeelb@google.com> Acked-by: Johannes Weiner <hannes@cmpxchg.org> Cc: Roman Gushchin <guro@fb.com> Cc: Michal Hocko <mhocko@suse.com> Cc: Yafang Shao <laoar.shao@gmail.com> Cc: Chris Down <chris@chrisdown.name> Cc: Tejun Heo <tj@kernel.org> Link: https://lkml.kernel.org/r/20201105161936.98312-1-songmuchun@bytedance.com Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> | 14 November 2020, 19:26:04 UTC |
e7e0461 | Santosh Sivaraj | 14 November 2020, 06:52:10 UTC | kernel/watchdog: fix watchdog_allowed_mask not used warning Define watchdog_allowed_mask only when SOFTLOCKUP_DETECTOR is enabled. Fixes: 7feeb9cd4f5b ("watchdog/sysctl: Clean up sysctl variable name space") Signed-off-by: Santosh Sivaraj <santosh@fossix.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Reviewed-by: Petr Mladek <pmladek@suse.com> Cc: Thomas Gleixner <tglx@linutronix.de> Link: https://lkml.kernel.org/r/20201106015025.1281561-1-santosh@fossix.org Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> | 14 November 2020, 19:26:03 UTC |
df5b0ab | Matteo Croce | 14 November 2020, 06:52:07 UTC | reboot: fix overflow parsing reboot cpu number Limit the CPU number to num_possible_cpus(), because setting it to a value lower than INT_MAX but higher than NR_CPUS produces the following error on reboot and shutdown: BUG: unable to handle page fault for address: ffffffff90ab1bb0 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 1c09067 P4D 1c09067 PUD 1c0a063 PMD 0 Oops: 0000 [#1] SMP CPU: 1 PID: 1 Comm: systemd-shutdow Not tainted 5.9.0-rc8-kvm #110 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.13.0-2.fc32 04/01/2014 RIP: 0010:migrate_to_reboot_cpu+0xe/0x60 Code: ea ea 00 48 89 fa 48 c7 c7 30 57 f1 81 e9 fa ef ff ff 66 2e 0f 1f 84 00 00 00 00 00 53 8b 1d d5 ea ea 00 e8 14 33 fe ff 89 da <48> 0f a3 15 ea fc bd 00 48 89 d0 73 29 89 c2 c1 e8 06 65 48 8b 3c RSP: 0018:ffffc90000013e08 EFLAGS: 00010246 RAX: ffff88801f0a0000 RBX: 0000000077359400 RCX: 0000000000000000 RDX: 0000000077359400 RSI: 0000000000000002 RDI: ffffffff81c199e0 RBP: ffffffff81c1e3c0 R08: ffff88801f41f000 R09: ffffffff81c1e348 R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000 R13: 00007f32bedf8830 R14: 00000000fee1dead R15: 0000000000000000 FS: 00007f32bedf8980(0000) GS:ffff88801f480000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffffff90ab1bb0 CR3: 000000001d057000 CR4: 00000000000006a0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: __do_sys_reboot.cold+0x34/0x5b do_syscall_64+0x2d/0x40 Fixes: 1b3a5d02ee07 ("reboot: move arch/x86 reboot= handling to generic kernel") Signed-off-by: Matteo Croce <mcroce@microsoft.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Fabian Frederick <fabf@skynet.be> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Guenter Roeck <linux@roeck-us.net> Cc: Kees Cook <keescook@chromium.org> Cc: Mike Rapoport <rppt@kernel.org> Cc: Pavel Tatashin <pasha.tatashin@soleen.com> Cc: Petr Mladek <pmladek@suse.com> Cc: Robin Holt <robinmholt@gmail.com> Cc: <stable@vger.kernel.org> Link: https://lkml.kernel.org/r/20201103214025.116799-3-mcroce@linux.microsoft.com Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> | 14 November 2020, 19:26:03 UTC |
8b92c4f | Matteo Croce | 14 November 2020, 06:52:02 UTC | Revert "kernel/reboot.c: convert simple_strtoul to kstrtoint" Patch series "fix parsing of reboot= cmdline", v3. The parsing of the reboot= cmdline has two major errors: - a missing bound check can crash the system on reboot - parsing of the cpu number only works if specified last Fix both. This patch (of 2): This reverts commit 616feab753972b97. kstrtoint() and simple_strtoul() have a subtle difference which makes them non interchangeable: if a non digit character is found amid the parsing, the former will return an error, while the latter will just stop parsing, e.g. simple_strtoul("123xyx") = 123. The kernel cmdline reboot= argument allows to specify the CPU used for rebooting, with the syntax `s####` among the other flags, e.g. "reboot=warm,s31,force", so if this flag is not the last given, it's silently ignored as well as the subsequent ones. Fixes: 616feab75397 ("kernel/reboot.c: convert simple_strtoul to kstrtoint") Signed-off-by: Matteo Croce <mcroce@microsoft.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Cc: Guenter Roeck <linux@roeck-us.net> Cc: Petr Mladek <pmladek@suse.com> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Mike Rapoport <rppt@kernel.org> Cc: Kees Cook <keescook@chromium.org> Cc: Pavel Tatashin <pasha.tatashin@soleen.com> Cc: Robin Holt <robinmholt@gmail.com> Cc: Fabian Frederick <fabf@skynet.be> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: <stable@vger.kernel.org> Link: https://lkml.kernel.org/r/20201103214025.116799-2-mcroce@linux.microsoft.com Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> | 14 November 2020, 19:26:03 UTC |
3347acc | Arvind Sankar | 14 November 2020, 06:51:59 UTC | compiler.h: fix barrier_data() on clang Commit 815f0ddb346c ("include/linux/compiler*.h: make compiler-*.h mutually exclusive") neglected to copy barrier_data() from compiler-gcc.h into compiler-clang.h. The definition in compiler-gcc.h was really to work around clang's more aggressive optimization, so this broke barrier_data() on clang, and consequently memzero_explicit() as well. For example, this results in at least the memzero_explicit() call in lib/crypto/sha256.c:sha256_transform() being optimized away by clang. Fix this by moving the definition of barrier_data() into compiler.h. Also move the gcc/clang definition of barrier() into compiler.h, __memory_barrier() is icc-specific (and barrier() is already defined using it in compiler-intel.h) and doesn't belong in compiler.h. [rdunlap@infradead.org: fix ALPHA builds when SMP is not enabled] Link: https://lkml.kernel.org/r/20201101231835.4589-1-rdunlap@infradead.org Fixes: 815f0ddb346c ("include/linux/compiler*.h: make compiler-*.h mutually exclusive") Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu> Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Tested-by: Nick Desaulniers <ndesaulniers@google.com> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Reviewed-by: Kees Cook <keescook@chromium.org> Cc: <stable@vger.kernel.org> Link: https://lkml.kernel.org/r/20201014212631.207844-1-nivedita@alum.mit.edu Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> | 14 November 2020, 19:26:03 UTC |
96e1fac | Jason Gunthorpe | 14 November 2020, 06:51:56 UTC | mm/gup: use unpin_user_pages() in __gup_longterm_locked() When FOLL_PIN is passed to __get_user_pages() the page list must be put back using unpin_user_pages() otherwise the page pin reference persists in a corrupted state. There are two places in the unwind of __gup_longterm_locked() that put the pages back without checking. Normally on error this function would return the partial page list making this the caller's responsibility, but in these two cases the caller is not allowed to see these pages at all. Fixes: 3faa52c03f44 ("mm/gup: track FOLL_PIN pages") Reported-by: Ira Weiny <ira.weiny@intel.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Reviewed-by: Ira Weiny <ira.weiny@intel.com> Reviewed-by: John Hubbard <jhubbard@nvidia.com> Cc: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com> Cc: Dan Williams <dan.j.williams@intel.com> Cc: <stable@vger.kernel.org> Link: https://lkml.kernel.org/r/0-v2-3ae7d9d162e2+2a7-gup_cma_fix_jgg@nvidia.com Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> | 14 November 2020, 19:26:03 UTC |
22e4663 | Laurent Dufour | 14 November 2020, 06:51:53 UTC | mm/slub: fix panic in slab_alloc_node() While doing memory hot-unplug operation on a PowerPC VM running 1024 CPUs with 11TB of ram, I hit the following panic: BUG: Kernel NULL pointer dereference on read at 0x00000007 Faulting instruction address: 0xc000000000456048 Oops: Kernel access of bad area, sig: 11 [#2] LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS= 2048 NUMA pSeries Modules linked in: rpadlpar_io rpaphp CPU: 160 PID: 1 Comm: systemd Tainted: G D 5.9.0 #1 NIP: c000000000456048 LR: c000000000455fd4 CTR: c00000000047b350 REGS: c00006028d1b77a0 TRAP: 0300 Tainted: G D (5.9.0) MSR: 8000000000009033 <SF,EE,ME,IR,DR,RI,LE> CR: 24004228 XER: 00000000 CFAR: c00000000000f1b0 DAR: 0000000000000007 DSISR: 40000000 IRQMASK: 0 GPR00: c000000000455fd4 c00006028d1b7a30 c000000001bec800 0000000000000000 GPR04: 0000000000000dc0 0000000000000000 00000000000374ef c00007c53df99320 GPR08: 000007c53c980000 0000000000000000 000007c53c980000 0000000000000000 GPR12: 0000000000004400 c00000001e8e4400 0000000000000000 0000000000000f6a GPR16: 0000000000000000 c000000001c25930 c000000001d62528 00000000000000c1 GPR20: c000000001d62538 c00006be469e9000 0000000fffffffe0 c0000000003c0ff8 GPR24: 0000000000000018 0000000000000000 0000000000000dc0 0000000000000000 GPR28: c00007c513755700 c000000001c236a4 c00007bc4001f800 0000000000000001 NIP [c000000000456048] __kmalloc_node+0x108/0x790 LR [c000000000455fd4] __kmalloc_node+0x94/0x790 Call Trace: kvmalloc_node+0x58/0x110 mem_cgroup_css_online+0x10c/0x270 online_css+0x48/0xd0 cgroup_apply_control_enable+0x2c4/0x470 cgroup_mkdir+0x408/0x5f0 kernfs_iop_mkdir+0x90/0x100 vfs_mkdir+0x138/0x250 do_mkdirat+0x154/0x1c0 system_call_exception+0xf8/0x200 system_call_common+0xf0/0x27c Instruction dump: e93e0000 e90d0030 39290008 7cc9402a e94d0030 e93e0000 7ce95214 7f89502a 2fbc0000 419e0018 41920230 e9270010 <89290007> 7f994800 419e0220 7ee6bb78 This pointing to the following code: mm/slub.c:2851 if (unlikely(!object || !node_match(page, node))) { c000000000456038: 00 00 bc 2f cmpdi cr7,r28,0 c00000000045603c: 18 00 9e 41 beq cr7,c000000000456054 <__kmalloc_node+0x114> node_match(): mm/slub.c:2491 if (node != NUMA_NO_NODE && page_to_nid(page) != node) c000000000456040: 30 02 92 41 beq cr4,c000000000456270 <__kmalloc_node+0x330> page_to_nid(): include/linux/mm.h:1294 c000000000456044: 10 00 27 e9 ld r9,16(r7) c000000000456048: 07 00 29 89 lbz r9,7(r9) <<<< r9 = NULL node_match(): mm/slub.c:2491 c00000000045604c: 00 48 99 7f cmpw cr7,r25,r9 c000000000456050: 20 02 9e 41 beq cr7,c000000000456270 <__kmalloc_node+0x330> The panic occurred in slab_alloc_node() when checking for the page's node: object = c->freelist; page = c->page; if (unlikely(!object || !node_match(page, node))) { object = __slab_alloc(s, gfpflags, node, addr, c); stat(s, ALLOC_SLOWPATH); The issue is that object is not NULL while page is NULL which is odd but may happen if the cache flush happened after loading object but before loading page. Thus checking for the page pointer is required too. The cache flush is done through an inter processor interrupt when a piece of memory is off-lined. That interrupt is triggered when a memory hot-unplug operation is initiated and offline_pages() is calling the slub's MEM_GOING_OFFLINE callback slab_mem_going_offline_callback() which is calling flush_cpu_slab(). If that interrupt is caught between the reading of c->freelist and the reading of c->page, this could lead to such a situation. That situation is expected and the later call to this_cpu_cmpxchg_double() will detect the change to c->freelist and redo the whole operation. In commit 6159d0f5c03e ("mm/slub.c: page is always non-NULL in node_match()") check on the page pointer has been removed assuming that page is always valid when it is called. It happens that this is not true in that particular case, so check for page before calling node_match() here. Fixes: 6159d0f5c03e ("mm/slub.c: page is always non-NULL in node_match()") Signed-off-by: Laurent Dufour <ldufour@linux.ibm.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Acked-by: Vlastimil Babka <vbabka@suse.cz> Acked-by: Christoph Lameter <cl@linux.com> Cc: Wei Yang <richard.weiyang@gmail.com> Cc: Pekka Enberg <penberg@kernel.org> Cc: David Rientjes <rientjes@google.com> Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com> Cc: Nathan Lynch <nathanl@linux.ibm.com> Cc: Scott Cheloha <cheloha@linux.ibm.com> Cc: Michal Hocko <mhocko@suse.com> Cc: <stable@vger.kernel.org> Link: https://lkml.kernel.org/r/20201027190406.33283-1-ldufour@linux.ibm.com Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> | 14 November 2020, 19:26:03 UTC |
044747e | Dmitry Baryshkov | 14 November 2020, 06:51:49 UTC | mailmap: fix entry for Dmitry Baryshkov/Eremin-Solenikov Change back surname to new (old) one. Dmitry Baryshkov -> Dmitry Eremin-Solenikov -> Dmitry Baryshkov. Map several odd entries to main identity. Signed-off-by: Dmitry Baryshkov <dbaryshkov@gmail.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Link: https://lkml.kernel.org/r/20201103005158.1181426-1-dmitry.baryshkov@linaro.org Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> | 14 November 2020, 19:26:03 UTC |
2da9f63 | Nicholas Piggin | 14 November 2020, 06:51:46 UTC | mm/vmscan: fix NR_ISOLATED_FILE corruption on 64-bit Previously the negated unsigned long would be cast back to signed long which would have the correct negative value. After commit 730ec8c01a2b ("mm/vmscan.c: change prototype for shrink_page_list"), the large unsigned int converts to a large positive signed long. Symptoms include CMA allocations hanging forever holding the cma_mutex due to alloc_contig_range->...->isolate_migratepages_block waiting forever in "while (unlikely(too_many_isolated(pgdat)))". [akpm@linux-foundation.org: fix -stat.nr_lazyfree_fail as well, per Michal] Fixes: 730ec8c01a2b ("mm/vmscan.c: change prototype for shrink_page_list") Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Acked-by: Michal Hocko <mhocko@suse.com> Cc: Vaneet Narang <v.narang@samsung.com> Cc: Maninder Singh <maninder1.s@samsung.com> Cc: Amit Sahrawat <a.sahrawat@samsung.com> Cc: Mel Gorman <mgorman@suse.de> Cc: Vlastimil Babka <vbabka@suse.cz> Cc: <stable@vger.kernel.org> Link: https://lkml.kernel.org/r/20201029032320.1448441-1-npiggin@gmail.com Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> | 14 November 2020, 19:26:03 UTC |
d20bdd5 | Zi Yan | 14 November 2020, 06:51:43 UTC | mm/compaction: stop isolation if too many pages are isolated and we have pages to migrate In isolate_migratepages_block, if we have too many isolated pages and nr_migratepages is not zero, we should try to migrate what we have without wasting time on isolating. In theory it's possible that multiple parallel compactions will cause too_many_isolated() to become true even if each has isolated less than COMPACT_CLUSTER_MAX, and loop forever in the while loop. Bailing immediately prevents that. [vbabka@suse.cz: changelog addition] Fixes: 1da2f328fa64 (“mm,thp,compaction,cma: allow THP migration for CMA allocations”) Suggested-by: Vlastimil Babka <vbabka@suse.cz> Signed-off-by: Zi Yan <ziy@nvidia.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Cc: <stable@vger.kernel.org> Cc: Mel Gorman <mgorman@techsingularity.net> Cc: Michal Hocko <mhocko@kernel.org> Cc: Rik van Riel <riel@surriel.com> Cc: Yang Shi <shy828301@gmail.com> Link: https://lkml.kernel.org/r/20201030183809.3616803-2-zi.yan@sent.com Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> | 14 November 2020, 19:26:03 UTC |
3893586 | Zi Yan | 14 November 2020, 06:51:40 UTC | mm/compaction: count pages and stop correctly during page isolation In isolate_migratepages_block, when cc->alloc_contig is true, we are able to isolate compound pages. But nr_migratepages and nr_isolated did not count compound pages correctly, causing us to isolate more pages than we thought. So count compound pages as the number of base pages they contain. Otherwise, we might be trapped in too_many_isolated while loop, since the actual isolated pages can go up to COMPACT_CLUSTER_MAX*512=16384, where COMPACT_CLUSTER_MAX is 32, since we stop isolation after cc->nr_migratepages reaches to COMPACT_CLUSTER_MAX. In addition, after we fix the issue above, cc->nr_migratepages could never be equal to COMPACT_CLUSTER_MAX if compound pages are isolated, thus page isolation could not stop as we intended. Change the isolation stop condition to '>='. The issue can be triggered as follows: In a system with 16GB memory and an 8GB CMA region reserved by hugetlb_cma, if we first allocate 10GB THPs and mlock them (so some THPs are allocated in the CMA region and mlocked), reserving 6 1GB hugetlb pages via /sys/kernel/mm/hugepages/hugepages-1048576kB/nr_hugepages will get stuck (looping in too_many_isolated function) until we kill either task. With the patch applied, oom will kill the application with 10GB THPs and let hugetlb page reservation finish. [ziy@nvidia.com: v3] Link: https://lkml.kernel.org/r/20201030183809.3616803-1-zi.yan@sent.com Fixes: 1da2f328fa64 ("cmm,thp,compaction,cma: allow THP migration for CMA allocations") Signed-off-by: Zi Yan <ziy@nvidia.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Reviewed-by: Yang Shi <shy828301@gmail.com> Acked-by: Vlastimil Babka <vbabka@suse.cz> Cc: Rik van Riel <riel@surriel.com> Cc: Michal Hocko <mhocko@kernel.org> Cc: Mel Gorman <mgorman@techsingularity.net> Cc: <stable@vger.kernel.org> Link: https://lkml.kernel.org/r/20201029200435.3386066-1-zi.yan@sent.com Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> | 14 November 2020, 19:26:03 UTC |
5c6fb4b | Lyude Paul | 14 November 2020, 00:14:10 UTC | drm/nouveau/kms/nv50-: Use atomic encoder callbacks everywhere It turns out that I forgot to go through and make sure that I converted all encoder callbacks to use atomic_enable/atomic_disable(), so let's go and actually do that. Signed-off-by: Lyude Paul <lyude@redhat.com> Cc: Kirill A. Shutemov <kirill@shutemov.name> Fixes: 09838c4efe9a ("drm/nouveau/kms: Search for encoders' connectors properly") Signed-off-by: Ben Skeggs <bskeggs@redhat.com> | 14 November 2020, 04:19:18 UTC |
6c27ffa | Ben Skeggs | 14 November 2020, 03:50:44 UTC | drm/nouveau/ttm: avoid using nouveau_drm.ttm.type_vram prior to nv50 Pre-NV50 chipsets don't currently use the MMU subsystem that later chipsets use, and type_vram is negative here, leading to an OOB memory access. This was previously guarded by a chipset check, restore that. Reported-by: Thomas Zimmermann <tzimmermann@suse.de> Fixes: 5839172f0980 ("drm/nouveau: explicitly specify caching to use") Signed-off-by: Ben Skeggs <bskeggs@redhat.com> | 14 November 2020, 04:19:17 UTC |
630f512 | Alexander Kapshuk | 13 October 2020, 12:47:25 UTC | drm/nouveau/kms: Fix NULL pointer dereference in nouveau_connector_detect_depth This oops manifests itself on the following hardware: 01:00.0 VGA compatible controller: NVIDIA Corporation G98M [GeForce G 103M] (rev a1) Oct 09 14:17:46 lp-sasha kernel: BUG: kernel NULL pointer dereference, address: 0000000000000000 Oct 09 14:17:46 lp-sasha kernel: #PF: supervisor read access in kernel mode Oct 09 14:17:46 lp-sasha kernel: #PF: error_code(0x0000) - not-present page Oct 09 14:17:46 lp-sasha kernel: PGD 0 P4D 0 Oct 09 14:17:46 lp-sasha kernel: Oops: 0000 [#1] SMP PTI Oct 09 14:17:46 lp-sasha kernel: CPU: 1 PID: 191 Comm: systemd-udevd Not tainted 5.9.0-rc8-next-20201009 #38 Oct 09 14:17:46 lp-sasha kernel: Hardware name: Hewlett-Packard Compaq Presario CQ61 Notebook PC/306A, BIOS F.03 03/23/2009 Oct 09 14:17:46 lp-sasha kernel: RIP: 0010:nouveau_connector_detect_depth+0x71/0xc0 [nouveau] Oct 09 14:17:46 lp-sasha kernel: Code: 0a 00 00 48 8b 49 48 c7 87 b8 00 00 00 06 00 00 00 80 b9 4d 0a 00 00 00 75 1e 83 fa 41 75 05 48 85 c0 75 29 8b 81 10 0d 00 00 <39> 06 7c 25 f6 81 14 0d 00 00 02 75 b7 c3 80 b9 0c 0d 00 00 00 75 Oct 09 14:17:46 lp-sasha kernel: RSP: 0018:ffffc9000028f8c0 EFLAGS: 00010297 Oct 09 14:17:46 lp-sasha kernel: RAX: 0000000000014c08 RBX: ffff8880369d4000 RCX: ffff8880369d3000 Oct 09 14:17:46 lp-sasha kernel: RDX: 0000000000000040 RSI: 0000000000000000 RDI: ffff8880369d4000 Oct 09 14:17:46 lp-sasha kernel: RBP: ffff88800601cc00 R08: ffff8880051da298 R09: ffffffff8226201a Oct 09 14:17:46 lp-sasha kernel: R10: ffff88800469aa80 R11: ffff888004c84ff8 R12: 0000000000000000 Oct 09 14:17:46 lp-sasha kernel: R13: ffff8880051da000 R14: 0000000000002000 R15: 0000000000000003 Oct 09 14:17:46 lp-sasha kernel: FS: 00007fd0192b3440(0000) GS:ffff8880bc900000(0000) knlGS:0000000000000000 Oct 09 14:17:46 lp-sasha kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 Oct 09 14:17:46 lp-sasha kernel: CR2: 0000000000000000 CR3: 0000000004976000 CR4: 00000000000006e0 Oct 09 14:17:46 lp-sasha kernel: Call Trace: Oct 09 14:17:46 lp-sasha kernel: nouveau_connector_get_modes+0x1e6/0x240 [nouveau] Oct 09 14:17:46 lp-sasha kernel: ? kfree+0xb9/0x240 Oct 09 14:17:46 lp-sasha kernel: ? drm_connector_list_iter_next+0x7c/0xa0 Oct 09 14:17:46 lp-sasha kernel: drm_helper_probe_single_connector_modes+0x1ba/0x7c0 Oct 09 14:17:46 lp-sasha kernel: drm_client_modeset_probe+0x27e/0x1360 Oct 09 14:17:46 lp-sasha kernel: ? nvif_object_sclass_put+0xc/0x20 [nouveau] Oct 09 14:17:46 lp-sasha kernel: ? nouveau_cli_init+0x3cc/0x440 [nouveau] Oct 09 14:17:46 lp-sasha kernel: ? ktime_get_mono_fast_ns+0x49/0xa0 Oct 09 14:17:46 lp-sasha kernel: ? nouveau_drm_open+0x4e/0x180 [nouveau] Oct 09 14:17:46 lp-sasha kernel: __drm_fb_helper_initial_config_and_unlock+0x3f/0x4a0 Oct 09 14:17:46 lp-sasha kernel: ? drm_file_alloc+0x18f/0x260 Oct 09 14:17:46 lp-sasha kernel: ? mutex_lock+0x9/0x40 Oct 09 14:17:46 lp-sasha kernel: ? drm_client_init+0x110/0x160 Oct 09 14:17:46 lp-sasha kernel: nouveau_fbcon_init+0x14d/0x1c0 [nouveau] Oct 09 14:17:46 lp-sasha kernel: nouveau_drm_device_init+0x1c0/0x880 [nouveau] Oct 09 14:17:46 lp-sasha kernel: nouveau_drm_probe+0x11a/0x1e0 [nouveau] Oct 09 14:17:46 lp-sasha kernel: pci_device_probe+0xcd/0x140 Oct 09 14:17:46 lp-sasha kernel: really_probe+0xd8/0x400 Oct 09 14:17:46 lp-sasha kernel: driver_probe_device+0x4a/0xa0 Oct 09 14:17:46 lp-sasha kernel: device_driver_attach+0x9c/0xc0 Oct 09 14:17:46 lp-sasha kernel: __driver_attach+0x6f/0x100 Oct 09 14:17:46 lp-sasha kernel: ? device_driver_attach+0xc0/0xc0 Oct 09 14:17:46 lp-sasha kernel: bus_for_each_dev+0x75/0xc0 Oct 09 14:17:46 lp-sasha kernel: bus_add_driver+0x106/0x1c0 Oct 09 14:17:46 lp-sasha kernel: driver_register+0x86/0xe0 Oct 09 14:17:46 lp-sasha kernel: ? 0xffffffffa044e000 Oct 09 14:17:46 lp-sasha kernel: do_one_initcall+0x48/0x1e0 Oct 09 14:17:46 lp-sasha kernel: ? _cond_resched+0x11/0x60 Oct 09 14:17:46 lp-sasha kernel: ? kmem_cache_alloc_trace+0x19c/0x1e0 Oct 09 14:17:46 lp-sasha kernel: do_init_module+0x57/0x220 Oct 09 14:17:46 lp-sasha kernel: __do_sys_finit_module+0xa0/0xe0 Oct 09 14:17:46 lp-sasha kernel: do_syscall_64+0x33/0x40 Oct 09 14:17:46 lp-sasha kernel: entry_SYSCALL_64_after_hwframe+0x44/0xa9 Oct 09 14:17:46 lp-sasha kernel: RIP: 0033:0x7fd01a060d5d Oct 09 14:17:46 lp-sasha kernel: Code: 00 c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d e3 70 0c 00 f7 d8 64 89 01 48 Oct 09 14:17:46 lp-sasha kernel: RSP: 002b:00007ffc8ad38a98 EFLAGS: 00000246 ORIG_RAX: 0000000000000139 Oct 09 14:17:46 lp-sasha kernel: RAX: ffffffffffffffda RBX: 0000563f6e7fd530 RCX: 00007fd01a060d5d Oct 09 14:17:46 lp-sasha kernel: RDX: 0000000000000000 RSI: 00007fd01a19f95d RDI: 000000000000000f Oct 09 14:17:46 lp-sasha kernel: RBP: 0000000000020000 R08: 0000000000000000 R09: 0000000000000007 Oct 09 14:17:46 lp-sasha kernel: R10: 000000000000000f R11: 0000000000000246 R12: 00007fd01a19f95d Oct 09 14:17:46 lp-sasha kernel: R13: 0000000000000000 R14: 0000563f6e7fbc10 R15: 0000563f6e7fd530 Oct 09 14:17:46 lp-sasha kernel: Modules linked in: nouveau(+) ttm xt_string xt_mark xt_LOG vgem v4l2_dv_timings uvcvideo ulpi udf ts_kmp ts_fsm ts_bm snd_aloop sil164 qat_dh895xccvf nf_nat_sip nf_nat_irc nf_nat_ftp nf_nat nf_log_ipv6 nf_log_ipv4 nf_log_common ltc2990 lcd intel_qat input_leds i2c_mux gspca_main videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_common videodev mc drivetemp cuse fuse crc_itu_t coretemp ch7006 ath5k ath algif_hash Oct 09 14:17:46 lp-sasha kernel: CR2: 0000000000000000 Oct 09 14:17:46 lp-sasha kernel: ---[ end trace 0ddafe218ad30017 ]--- Oct 09 14:17:46 lp-sasha kernel: RIP: 0010:nouveau_connector_detect_depth+0x71/0xc0 [nouveau] Oct 09 14:17:46 lp-sasha kernel: Code: 0a 00 00 48 8b 49 48 c7 87 b8 00 00 00 06 00 00 00 80 b9 4d 0a 00 00 00 75 1e 83 fa 41 75 05 48 85 c0 75 29 8b 81 10 0d 00 00 <39> 06 7c 25 f6 81 14 0d 00 00 02 75 b7 c3 80 b9 0c 0d 00 00 00 75 Oct 09 14:17:46 lp-sasha kernel: RSP: 0018:ffffc9000028f8c0 EFLAGS: 00010297 Oct 09 14:17:46 lp-sasha kernel: RAX: 0000000000014c08 RBX: ffff8880369d4000 RCX: ffff8880369d3000 Oct 09 14:17:46 lp-sasha kernel: RDX: 0000000000000040 RSI: 0000000000000000 RDI: ffff8880369d4000 Oct 09 14:17:46 lp-sasha kernel: RBP: ffff88800601cc00 R08: ffff8880051da298 R09: ffffffff8226201a Oct 09 14:17:46 lp-sasha kernel: R10: ffff88800469aa80 R11: ffff888004c84ff8 R12: 0000000000000000 Oct 09 14:17:46 lp-sasha kernel: R13: ffff8880051da000 R14: 0000000000002000 R15: 0000000000000003 Oct 09 14:17:46 lp-sasha kernel: FS: 00007fd0192b3440(0000) GS:ffff8880bc900000(0000) knlGS:0000000000000000 Oct 09 14:17:46 lp-sasha kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 Oct 09 14:17:46 lp-sasha kernel: CR2: 0000000000000000 CR3: 0000000004976000 CR4: 00000000000006e0 The disassembly: Code: 0a 00 00 48 8b 49 48 c7 87 b8 00 00 00 06 00 00 00 80 b9 4d 0a 00 00 00 75 1e 83 fa 41 75 05 48 85 c0 75 29 8b 81 10 0d 00 00 <39> 06 7c 25 f6 81 14 0d 00 00 02 75 b7 c3 80 b9 0c 0d 00 00 00 75 All code ======== 0: 0a 00 or (%rax),%al 2: 00 48 8b add %cl,-0x75(%rax) 5: 49 rex.WB 6: 48 c7 87 b8 00 00 00 movq $0x6,0xb8(%rdi) d: 06 00 00 00 11: 80 b9 4d 0a 00 00 00 cmpb $0x0,0xa4d(%rcx) 18: 75 1e jne 0x38 1a: 83 fa 41 cmp $0x41,%edx 1d: 75 05 jne 0x24 1f: 48 85 c0 test %rax,%rax 22: 75 29 jne 0x4d 24: 8b 81 10 0d 00 00 mov 0xd10(%rcx),%eax 2a:* 39 06 cmp %eax,(%rsi) <-- trapping instruction 2c: 7c 25 jl 0x53 2e: f6 81 14 0d 00 00 02 testb $0x2,0xd14(%rcx) 35: 75 b7 jne 0xffffffffffffffee 37: c3 retq 38: 80 b9 0c 0d 00 00 00 cmpb $0x0,0xd0c(%rcx) 3f: 75 .byte 0x75 Code starting with the faulting instruction =========================================== 0: 39 06 cmp %eax,(%rsi) 2: 7c 25 jl 0x29 4: f6 81 14 0d 00 00 02 testb $0x2,0xd14(%rcx) b: 75 b7 jne 0xffffffffffffffc4 d: c3 retq e: 80 b9 0c 0d 00 00 00 cmpb $0x0,0xd0c(%rcx) 15: 75 .byte 0x75 objdump -SF --disassemble=nouveau_connector_detect_depth [...] if (nv_connector->edid && c85e1: 83 fa 41 cmp $0x41,%edx c85e4: 75 05 jne c85eb <nouveau_connector_detect_depth+0x6b> (File Offset: 0xc866b) c85e6: 48 85 c0 test %rax,%rax c85e9: 75 29 jne c8614 <nouveau_connector_detect_depth+0x94> (File Offset: 0xc8694) nv_connector->type == DCB_CONNECTOR_LVDS_SPWG) duallink = ((u8 *)nv_connector->edid)[121] == 2; else duallink = mode->clock >= bios->fp.duallink_transition_clk; if ((!duallink && (bios->fp.strapless_is_24bit & 1)) || c85eb: 8b 81 10 0d 00 00 mov 0xd10(%rcx),%eax c85f1: 39 06 cmp %eax,(%rsi) c85f3: 7c 25 jl c861a <nouveau_connector_detect_depth+0x9a> (File Offset: 0xc869a) ( duallink && (bios->fp.strapless_is_24bit & 2))) c85f5: f6 81 14 0d 00 00 02 testb $0x2,0xd14(%rcx) c85fc: 75 b7 jne c85b5 <nouveau_connector_detect_depth+0x35> (File Offset: 0xc8635) connector->display_info.bpc = 8; [...] % scripts/faddr2line /lib/modules/5.9.0-rc8-next-20201009/kernel/drivers/gpu/drm/nouveau/nouveau.ko nouveau_connector_detect_depth+0x71/0xc0 nouveau_connector_detect_depth+0x71/0xc0: nouveau_connector_detect_depth at /home/sasha/linux-next/drivers/gpu/drm/nouveau/nouveau_connector.c:891 It is actually line 889. See the disassembly below. 889 duallink = mode->clock >= bios->fp.duallink_transition_clk; The NULL pointer being dereferenced is mode. Git bisect has identified the following commit as bad: f28e32d3906e drm/nouveau/kms: Don't change EDID when it hasn't actually changed Here is the chain of events that causes the oops. On entry to nouveau_connector_detect_lvds, edid is set to NULL. The call to nouveau_connector_detect sets nv_connector->edid to valid memory, with status set to connector_status_connected and the flow of execution branching to the out label. The subsequent call to nouveau_connector_set_edid erronously clears nv_connector->edid, via the local edid pointer which remains set to NULL. Fix this by setting edid to the value of the just acquired nv_connector->edid and executing the body of nouveau_connector_set_edid only if nv_connector->edid and edid point to different memory addresses thus preventing nv_connector->edid from being turned into a dangling pointer. Fixes: f28e32d3906e ("drm/nouveau/kms: Don't change EDID when it hasn't actually changed") Signed-off-by: Alexander Kapshuk <alexander.kapshuk@gmail.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com> | 14 November 2020, 04:19:17 UTC |
f01c30d | Linus Torvalds | 14 November 2020, 00:07:53 UTC | Merge tag 'vfs-5.10-fixes-2' of git://git.kernel.org/pub/scm/fs/xfs/xfs-linux Pull fs freeze fix and cleanups from Darrick Wong: "A single vfs fix for 5.10, along with two subsequent cleanups. A very long time ago, a hack was added to the vfs fs freeze protection code to work around lockdep complaints about XFS, which would try to run a transaction (which requires intwrite protection) to finalize an xfs freeze (by which time the vfs had already taken intwrite). Fast forward a few years, and XFS fixed the recursive intwrite problem on its own, and the hack became unnecessary. Fast forward almost a decade, and latent bugs in the code converting this hack from freeze flags to freeze locks combine with lockdep bugs to make this reproduce frequently enough to notice page faults racing with freeze. Since the hack is unnecessary and causes thread race errors, just get rid of it completely. Making this kind of vfs change midway through a cycle makes me nervous, but a large enough number of the usual VFS/ext4/XFS/btrfs suspects have said this looks good and solves a real problem vector. And once that removal is done, __sb_start_write is now simple enough that it becomes possible to refactor the function into smaller, simpler static inline helpers in linux/fs.h. The cleanup is straightforward. Summary: - Finally remove the "convert to trylock" weirdness in the fs freezer code. It was necessary 10 years ago to deal with nested transactions in XFS, but we've long since removed that; and now this is causing subtle race conditions when lockdep goes offline and sb_start_* aren't prepared to retry a trylock failure. - Minor cleanups of the sb_start_* fs freeze helpers" * tag 'vfs-5.10-fixes-2' of git://git.kernel.org/pub/scm/fs/xfs/xfs-linux: vfs: move __sb_{start,end}_write* to fs.h vfs: separate __sb_start_write into blocking and non-blocking helpers vfs: remove lockdep bogosity in __sb_start_write | 14 November 2020, 00:07:53 UTC |
d9315f5 | Linus Torvalds | 14 November 2020, 00:01:44 UTC | Merge tag 'xfs-5.10-fixes-5' of git://git.kernel.org/pub/scm/fs/xfs/xfs-linux Pull xfs fixes from Darrick Wong: - Fix a fairly serious problem where the reverse mapping btree key comparison functions were silently ignoring parts of the keyspace when doing comparisons - Fix a thinko in the online refcount scrubber - Fix a missing unlock in the pnfs code * tag 'xfs-5.10-fixes-5' of git://git.kernel.org/pub/scm/fs/xfs/xfs-linux: xfs: fix a missing unlock on error in xfs_fs_map_blocks xfs: fix brainos in the refcount scrubber's rmap fragment processor xfs: fix rmap key and record comparison functions xfs: set the unwritten bit in rmap lookup flags in xchk_bmap_get_rmapextents xfs: fix flags argument to rmap lookup when converting shared file rmaps | 14 November 2020, 00:01:44 UTC |
b5dea9c | Linus Torvalds | 13 November 2020, 23:09:52 UTC | Merge tag 'block-5.10-2020-11-13' of git://git.kernel.dk/linux-block Pull block fixes from Jens Axboe: "A few small fixes: - NVMe pull request from Christoph: - don't clear the read-only bit on a revalidate (Sagi Grimberg) - nbd error case refcount leak (Christoph) - loop/generic uevent fix (Christoph, Petr)" * tag 'block-5.10-2020-11-13' of git://git.kernel.dk/linux-block: loop: Fix occasional uevent drop block: add a return value to set_capacity_revalidate_and_notify nbd: fix a block_device refcount leak in nbd_release nvme: fix incorrect behavior when BLKROSET is called by the user | 13 November 2020, 23:09:52 UTC |
1b1e926 | Linus Torvalds | 13 November 2020, 23:05:19 UTC | Merge tag 'io_uring-5.10-2020-11-13' of git://git.kernel.dk/linux-block Pull io_uring fix from Jens Axboe: "A single fix in here, for a missed rounding case at setup time, which caused an otherwise legitimate setup case to return -EINVAL if used with unaligned ring size values" * tag 'io_uring-5.10-2020-11-13' of git://git.kernel.dk/linux-block: io_uring: round-up cq size before comparing with rounded sq size | 13 November 2020, 23:05:19 UTC |
9e6a39e | Linus Torvalds | 13 November 2020, 20:47:02 UTC | Merge tag 'devicetree-fixes-for-5.10-2' of git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux Pull devicetree fixes from Rob Herring: - fix Flexcan binding schema errors introduced in rc3 - fix an of_node ref counting error in of_dma_is_coherent * tag 'devicetree-fixes-for-5.10-2' of git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux: dt-bindings: clock: imx5: fix example dt-bindings: can: fsl,flexcan.yaml: fix compatible for i.MX35 and i.MX53 dt-bindings: can: fsl,flexcan.yaml: fix fsl,stop-mode of/address: Fix of_node memory leak in of_dma_is_coherent | 13 November 2020, 20:47:02 UTC |
4de010e | Linus Torvalds | 13 November 2020, 19:04:25 UTC | Merge tag 'pinctrl-v5.10-2' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl Pull pin control fixes from Linus Walleij: "A bunch of pin control fixes for the v5.10 kernel series. Nothing in particular to say about it, because they are all driver fixes. I'm happy that some AMD driver fixes are appearing, it's been an undermaintained driver, and laptops have suffered. Summary: - Two fixes to the Intel pin controller drivers: fixing pull resistance bias. - Fix some invalid SSI pins on the Ingenic pin controller. - Make sure the clock is enabled when requesting interrupts from the Rockchip GPIO controller. - Make sure IRQs are mapped when looking up the IRQ for a GPIO line on the Rockchip GPIO Write. - Two regmap initialization fixes for the MCP23s08. - Fix a GPI-only prefix function problem on the Aspeed pin controller. - Disable the debounce filter correctly on the AMD pin controller. - Correct the timer clock setting for the AMD debounce timer. - Make the Qualcomm pin controller more cautious around the handling of PDC-related GPIO interrupts. - Fix the interrupt map in the Qualcomm SM8250 pin controller" * tag 'pinctrl-v5.10-2' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl: pinctrl: qcom: sm8250: Specify PDC map pinctrl: qcom: Move clearing pending IRQ to .irq_request_resources callback pinctrl: amd: use higher precision for 512 RtcClk pinctrl: amd: fix incorrect way to disable debounce filter pinctrl: aspeed: Fix GPI only function problem. pinctrl: mcp23s08: Print error message when regmap init fails pinctrl: mcp23s08: Use full chunk of memory for regmap configuration pinctrl: rockchip: create irq mapping in gpio_to_irq pinctrl: rockchip: enable gpio pclk for rockchip_gpio_to_irq pinctrl: ingenic: Fix invalid SSI pins pinctrl: intel: Set default bias in case no particular value given pinctrl: intel: Fix 2 kOhm bias which is 833 Ohm | 13 November 2020, 19:04:25 UTC |
29eb6b7 | Linus Torvalds | 13 November 2020, 18:55:50 UTC | Merge tag 'gpio-v5.10-2' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio Pull GPIO fixes from Linus Walleij: "Some GPIO fixes I've collected with the help of Bartosz. Nothing special about them: all are driver and kbuild fixes + some documentation fixes: - Tidy up a missed function call in the designware driver when converting to gpiolib irqchip - Fix some bitmasks in the Aspeed driver - Fix some kerneldoc warnings and minor bugs in the improved userspace API documentation - Revert the revert of the OMAP fix for lost edge wakeup interrupts: the fix needs to stay in - Fix a compile error when deselecting the character device - A bunch of IRQ fixes on the idio GPIO drivers - Fix an off-by-one error in the SiFive GPIO driver" * tag 'gpio-v5.10-2' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio: gpio: sifive: Fix SiFive gpio probe gpio: pcie-idio-24: Enable PEX8311 interrupts gpio: pcie-idio-24: Fix IRQ Enable Register value gpio: pcie-idio-24: Fix irq mask when masking gpiolib: fix sysfs when cdev is not selected Revert "Revert "gpio: omap: Fix lost edge wake-up interrupts"" gpio: uapi: clarify the meaning of 'empty' char arrays gpio: uapi: remove whitespace gpio: uapi: kernel-doc formatting improvements gpio: uapi: comment consistency gpio: uapi: fix kernel-doc warnings gpio: aspeed: fix ast2600 bank properties gpio: dwapb: Fix missing conversion to GPIO-lib-based IRQ-chip | 13 November 2020, 18:55:50 UTC |
673cb93 | Linus Torvalds | 13 November 2020, 18:09:40 UTC | Merge tag 'mmc-v5.10-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc Pull MMC fixes from Ulf Hansson: - tmio: Fixup support for reset - sdhci-of-esdhc: Extend erratum for pulse width to more broken HWs - renesas_sdhi: Fix re-binding of drivers * tag 'mmc-v5.10-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc: Revert "mmc: renesas_sdhi: workaround a regression when reinserting SD cards" mmc: tmio: bring tuning HW to a sane state with MMC_POWER_OFF mmc: tmio: when resetting, reset DMA controller, too mmc: sdhci-of-esdhc: Handle pulse width detection erratum for more SoCs mmc: renesas_sdhi_core: Add missing tmio_mmc_host_free() at remove | 13 November 2020, 18:09:40 UTC |
e627c25 | Linus Torvalds | 13 November 2020, 17:53:53 UTC | Merge tag 'drm-fixes-2020-11-13' of git://anongit.freedesktop.org/drm/drm Pull drm fixes from Dave Airlie: "Nearly didn't send you a PR this week at all, but a few things trickled in over the day, not a huge amount here, some i915, amdgpu and a bunch of misc fixes. I have a couple of nouveau fixes outstanding due to the PR having the wrong base, I'll figure it out next week. amdgpu: - Pageflip fix for DCN3 - Declare TA firmware for green sardine - Headless navi fix i915: - Pull phys pread/pwrite implementations to the backend - Correctly set SFC capability for video engines bridge: - cdns Kconfig fix hyperv_fb: - fix missing include gma500: - oob access fix mcde: - unbalanced regulator fix" * tag 'drm-fixes-2020-11-13' of git://anongit.freedesktop.org/drm/drm: drm/amdgpu: enable DCN for navi10 headless SKU drm/amdgpu: add ta firmware load for green-sardine drm/i915: Correctly set SFC capability for video engines drm/i915/gem: Pull phys pread/pwrite implementations to the backend drm/i915/gem: Allow backends to override pread implementation drm/mcde: Fix unbalanced regulator drm/gma500: Fix out-of-bounds access to struct drm_device.vblank[] video: hyperv_fb: include vmalloc.h drm: bridge: cdns: Kconfig: Switch over dependency to ARCH_K3 drm/amd/display: Add missing pflip irq | 13 November 2020, 17:53:53 UTC |
6186313 | Linus Torvalds | 13 November 2020, 17:36:10 UTC | Merge tag 'trace-v5.10-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace Pull bootconfig fix from Steven Rostedt: "Fix alignment of bootconfig GRUB may align the init ramdisk size to 4 bytes, the magic number at the end of the init ramdisk that denotes bootconfig is attached may not be at the exact end of the ramdisk. The kernel needs to check back at least 4 bytes" * tag 'trace-v5.10-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace: bootconfig: Extend the magic check range to the preceding 3 bytes | 13 November 2020, 17:36:10 UTC |
e45f90f | Linus Torvalds | 13 November 2020, 17:31:20 UTC | Merge tag 'for-linus' of git://git.armlinux.org.uk/~rmk/linux-arm Pull ARM fix from Russell King: "Just one bug fix: avoid a fortify panic when copying optprobe template" * tag 'for-linus' of git://git.armlinux.org.uk/~rmk/linux-arm: ARM: 9019/1: kprobes: Avoid fortify_panic() when copying optprobe template | 13 November 2020, 17:31:20 UTC |
88b31f0 | Linus Torvalds | 13 November 2020, 17:23:10 UTC | Merge tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux Pull arm64 fixes from Will Deacon: - Spectre/Meltdown safelisting for some Qualcomm KRYO cores - Fix RCU splat when failing to online a CPU due to a feature mismatch - Fix a recently introduced sparse warning in kexec() - Fix handling of CPU erratum 1418040 for late CPUs - Ensure hot-added memory falls within linear-mapped region * tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux: arm64: cpu_errata: Apply Erratum 845719 to KRYO2XX Silver arm64: proton-pack: Add KRYO2XX silver CPUs to spectre-v2 safe-list arm64: kpti: Add KRYO2XX gold/silver CPU cores to kpti safelist arm64: Add MIDR value for KRYO2XX gold/silver CPU cores arm64/mm: Validate hotplug range before creating linear mapping arm64: smp: Tell RCU about CPUs that fail to come online arm64: psci: Avoid printing in cpu_psci_cpu_die() arm64: kexec_file: Fix sparse warning arm64: errata: Fix handling of 1418040 with late CPU onlining | 13 November 2020, 17:23:10 UTC |
d3ba7af | Linus Torvalds | 13 November 2020, 17:05:33 UTC | Merge tag 'ext4_for_linus_bugfixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4 Pull ext4 fixes from Ted Ts'o: "Two ext4 bug fixes, one being a revert of a commit sent during the merge window" * tag 'ext4_for_linus_bugfixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4: Revert "ext4: fix superblock checksum calculation race" ext4: handle dax mount option collision | 13 November 2020, 17:05:33 UTC |
bdac39a | Marc Kleine-Budde | 11 November 2020, 21:35:48 UTC | dt-bindings: clock: imx5: fix example Since commit: 0e030a373df3 ("can: flexcan: fix endianess detection") the fsl,imx53-flexcan isn't compatible with the fsl,p1010-flexcan any more. As the former accesses the IP core in Little Endian mode and the latter uses Big Endian mode. With the conversion of the flexcan DT bindings to yaml, the dt_binding_check this throws the following error: Documentation/devicetree/bindings/clock/imx5-clock.example.dt.yaml: can@53fc8000: compatible: 'oneOf' conditional failed, one must be fixed: ['fsl,imx53-flexcan', 'fsl,p1010-flexcan'] is too long Additional items are not allowed ('fsl,p1010-flexcan' was unexpected) 'fsl,imx53-flexcan' is not one of ['fsl,imx7d-flexcan', 'fsl,imx6ul-flexcan', 'fsl,imx6sx-flexcan'] 'fsl,imx53-flexcan' is not one of ['fsl,ls1028ar1-flexcan'] 'fsl,imx6q-flexcan' was expected 'fsl,lx2160ar1-flexcan' was expected From schema: /builds/robherring/linux-dt-bindings/Documentation/devicetree/bindings/net/can/fsl,flexcan.yaml The error is fixed by replacing the "fsl,p1010-flexcan" compatible (which turned out the be incompatible) with "fsl,imx25-flexcan" in the binding example. Reported-by: Rob Herring <robh+dt@kernel.org> Cc: Fabio Estevam <fabio.estevam@nxp.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de> Link: https://lore.kernel.org/r/20201111213548.1621094-1-mkl@pengutronix.de [robh: Add "fsl,imx25-flexcan" as fallback] Signed-off-by: Rob Herring <robh@kernel.org> | 13 November 2020, 14:49:59 UTC |
3bbb73f | Marc Kleine-Budde | 11 November 2020, 13:05:06 UTC | dt-bindings: can: fsl,flexcan.yaml: fix compatible for i.MX35 and i.MX53 As both the i.MX35 and i.MX53 flexcan IP cores are compatible to the i.MX25, they are listed as: compatible = "fsl,imx35-flexcan", "fsl,imx25-flexcan"; and: compatible = "fsl,imx53-flexcan", "fsl,imx25-flexcan"; in the SoC device trees. This patch fixes the following errors, which shows up during a dtbs_check: arch/arm/boot/dts/imx53-ard.dt.yaml: can@53fc8000: compatible: 'oneOf' conditional failed, one must be fixed: ['fsl,imx53-flexcan', 'fsl,imx25-flexcan'] is too long Additional items are not allowed ('fsl,imx25-flexcan' was unexpected) 'fsl,imx53-flexcan' is not one of ['fsl,imx7d-flexcan', 'fsl,imx6ul-flexcan', 'fsl,imx6sx-flexcan'] 'fsl,imx53-flexcan' is not one of ['fsl,ls1028ar1-flexcan'] 'fsl,imx6q-flexcan' was expected 'fsl,lx2160ar1-flexcan' was expected From schema: Documentation/devicetree/bindings/net/can/fsl,flexcan.yaml Fixes: e5ab9aa7e49b ("dt-bindings: can: flexcan: convert fsl,*flexcan bindings to yaml") Reported-by: Rob Herring <robh+dt@kernel.org> Cc: Oleksij Rempel <o.rempel@pengutronix.de> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de> Link: https://lore.kernel.org/r/20201111130507.1560881-4-mkl@pengutronix.de [robh: drop singular fsl,imx53-flexcan and fsl,imx35-flexcan] Signed-off-by: Rob Herring <robh@kernel.org> | 13 November 2020, 14:46:57 UTC |
60268b0 | Naveen Krishna Chatradhi | 12 November 2020, 17:21:59 UTC | hwmon: (amd_energy) modify the visibility of the counters This patch limits the visibility to owner and groups only for the energy counters exposed through the hwmon based amd_energy driver. Cc: stable@vger.kernel.org Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Naveen Krishna Chatradhi <nchatrad@amd.com> Link: https://lore.kernel.org/r/20201112172159.8781-1-nchatrad@amd.com Signed-off-by: Guenter Roeck <linux@roeck-us.net> | 13 November 2020, 14:46:20 UTC |
6d853c9 | Chris Brandt | 11 November 2020, 13:12:09 UTC | usb: cdc-acm: Add DISABLE_ECHO for Renesas USB Download mode Renesas R-Car and RZ/G SoCs have a firmware download mode over USB. However, on reset a banner string is transmitted out which is not expected to be echoed back and will corrupt the protocol. Cc: stable <stable@vger.kernel.org> Acked-by: Oliver Neukum <oneukum@suse.com> Signed-off-by: Chris Brandt <chris.brandt@renesas.com> Link: https://lore.kernel.org/r/20201111131209.3977903-1-chris.brandt@renesas.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> | 13 November 2020, 14:26:49 UTC |
4df694a | Andrey Konovalov | 11 November 2020, 02:17:55 UTC | MAINTAINERS: add usb raw gadget entry Add myself (using the personal email address) as a reviewer for the USB Raw Gadget driver. Acked-by: Andrey Konovalov <andreyknvl@gmail.com> Signed-off-by: Andrey Konovalov <andreyknvl@google.com> Link: https://lore.kernel.org/r/245047b3fffaf5c0b791ed226d1ea272b2aef031.1605060950.git.andreyknvl@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> | 13 November 2020, 14:26:09 UTC |
0e6371f | Heikki Krogerus | 10 November 2020, 12:05:47 UTC | usb: typec: ucsi: Report power supply changes When the ucsi power supply goes online/offline, and when the power levels change, the power supply class needs to be notified so it can inform the user space. Fixes: 992a60ed0d5e ("usb: typec: ucsi: register with power_supply class") Cc: stable@vger.kernel.org Reported-and-tested-by: Vladimir Yerilov <openmindead@gmail.com> Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/20201110120547.67922-1-heikki.krogerus@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> | 13 November 2020, 14:25:02 UTC |
7625547 | Zhang Qilong | 06 November 2020, 12:22:21 UTC | xhci: hisilicon: fix refercence leak in xhci_histb_probe pm_runtime_get_sync() will increment pm usage at first and it will resume the device later. We should decrease the usage count whetever it succeeded or failed(maybe runtime of the device has error, or device is in inaccessible state, or other error state). If we do not call put operation to decrease the reference, it will result in reference leak in xhci_histb_probe. Moreover, this device cannot enter the idle state and always stay busy or other non-idle state later. So we fixed it by jumping to error handling branch. Fixes: c508f41da0788 ("xhci: hisilicon: support HiSilicon STB xHCI host controller") Signed-off-by: Zhang Qilong <zhangqilong3@huawei.com> Link: https://lore.kernel.org/r/20201106122221.2304528-1-zhangqilong3@huawei.com Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> | 13 November 2020, 13:32:43 UTC |
ffa13d2 | Geert Uytterhoeven | 12 November 2020, 13:59:00 UTC | Revert "usb: musb: convert to devm_platform_ioremap_resource_byname" This reverts commit 2d30e408a2a6b3443d3232593e3d472584a3e9f8. On Beaglebone Black, where each interface has 2 children: musb-dsps 47401c00.usb: can't request region for resource [mem 0x47401800-0x474019ff] musb-hdrc musb-hdrc.1: musb_init_controller failed with status -16 musb-hdrc: probe of musb-hdrc.1 failed with error -16 musb-dsps 47401400.usb: can't request region for resource [mem 0x47401000-0x474011ff] musb-hdrc musb-hdrc.0: musb_init_controller failed with status -16 musb-hdrc: probe of musb-hdrc.0 failed with error -16 Before, devm_ioremap_resource() was called on "dev" ("musb-hdrc.0" or "musb-hdrc.1"), after it is called on "&pdev->dev" ("47401400.usb" or "47401c00.usb"), leading to a duplicate region request, which fails. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Fixes: 2d30e408a2a6 ("usb: musb: convert to devm_platform_ioremap_resource_byname") Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20201112135900.3822599-1-geert+renesas@glider.be Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> | 13 November 2020, 13:30:23 UTC |
96308b0 | Babu Moger | 12 November 2020, 22:18:03 UTC | KVM: SVM: Update cr3_lm_rsvd_bits for AMD SEV guests For AMD SEV guests, update the cr3_lm_rsvd_bits to mask the memory encryption bit in reserved bits. Signed-off-by: Babu Moger <babu.moger@amd.com> Message-Id: <160521948301.32054.5783800787423231162.stgit@bmoger-ubuntu> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> | 13 November 2020, 11:31:14 UTC |
0107973 | Babu Moger | 12 November 2020, 22:17:56 UTC | KVM: x86: Introduce cr3_lm_rsvd_bits in kvm_vcpu_arch SEV guests fail to boot on a system that supports the PCID feature. While emulating the RSM instruction, KVM reads the guest CR3 and calls kvm_set_cr3(). If the vCPU is in the long mode, kvm_set_cr3() does a sanity check for the CR3 value. In this case, it validates whether the value has any reserved bits set. The reserved bit range is 63:cpuid_maxphysaddr(). When AMD memory encryption is enabled, the memory encryption bit is set in the CR3 value. The memory encryption bit may fall within the KVM reserved bit range, causing the KVM emulation failure. Introduce a new field cr3_lm_rsvd_bits in kvm_vcpu_arch which will cache the reserved bits in the CR3 value. This will be initialized to rsvd_bits(cpuid_maxphyaddr(vcpu), 63). If the architecture has any special bits(like AMD SEV encryption bit) that needs to be masked from the reserved bits, should be cleared in vendor specific kvm_x86_ops.vcpu_after_set_cpuid handler. Fixes: a780a3ea628268b2 ("KVM: X86: Fix reserved bits check for MOV to CR3") Signed-off-by: Babu Moger <babu.moger@amd.com> Message-Id: <160521947657.32054.3264016688005356563.stgit@bmoger-ubuntu> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> | 13 November 2020, 11:28:37 UTC |
51b958e | David Edmondson | 03 November 2020, 12:04:00 UTC | KVM: x86: clflushopt should be treated as a no-op by emulation The instruction emulator ignores clflush instructions, yet fails to support clflushopt. Treat both similarly. Fixes: 13e457e0eebf ("KVM: x86: Emulator does not decode clflush well") Signed-off-by: David Edmondson <david.edmondson@oracle.com> Message-Id: <20201103120400.240882-1-david.edmondson@oracle.com> Reviewed-by: Joao Martins <joao.m.martins@oracle.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> | 13 November 2020, 11:28:33 UTC |
2c38234 | Paolo Bonzini | 13 November 2020, 11:28:23 UTC | Merge tag 'kvmarm-fixes-5.10-3' of git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm into HEAD KVM/arm64 fixes for v5.10, take #3 - Allow userspace to downgrade ID_AA64PFR0_EL1.CSV2 - Inject UNDEF on SCXTNUM_ELx access | 13 November 2020, 11:28:23 UTC |
ff82872 | Thomas Gleixner | 12 November 2020, 19:14:16 UTC | iommu/vt-d: Cure VF irqdomain hickup The recent changes to store the MSI irqdomain pointer in struct device missed that Intel DMAR does not register virtual function devices. Due to that a VF device gets the plain PCI-MSI domain assigned and then issues compat MSI messages which get caught by the interrupt remapping unit. Cure that by inheriting the irq domain from the physical function device. Ideally the irqdomain would be associated to the bus, but DMAR can have multiple units and therefore irqdomains on a single bus. The VF 'bus' could of course inherit the domain from the PF, but that'd be yet another x86 oddity. Fixes: 85a8dfc57a0b ("iommm/vt-d: Store irq domain in struct device") Reported-by: Jason Gunthorpe <jgg@nvidia.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: Lu Baolu <baolu.lu@linux.intel.com> Cc: Joerg Roedel <joro@8bytes.org> Cc: Bjorn Helgaas <bhelgaas@google.com> Cc: Marc Zyngier <maz@kernel.org> Cc: David Woodhouse <dwmw2@infradead.org> Link: https://lore.kernel.org/r/draft-87eekymlpz.fsf@nanos.tec.linutronix.de | 13 November 2020, 11:00:40 UTC |
23c2164 | Konrad Dybcio | 04 November 2020, 23:22:13 UTC | arm64: cpu_errata: Apply Erratum 845719 to KRYO2XX Silver QCOM KRYO2XX Silver cores are Cortex-A53 based and are susceptible to the 845719 erratum. Add them to the lookup list to apply the erratum. Signed-off-by: Konrad Dybcio <konrad.dybcio@somainline.org> Link: https://lore.kernel.org/r/20201104232218.198800-5-konrad.dybcio@somainline.org Signed-off-by: Will Deacon <will@kernel.org> | 13 November 2020, 09:47:08 UTC |
38328d4 | Konrad Dybcio | 04 November 2020, 23:22:12 UTC | arm64: proton-pack: Add KRYO2XX silver CPUs to spectre-v2 safe-list KRYO2XX silver (LITTLE) CPUs are based on Cortex-A53 and they are not affected by spectre-v2. Signed-off-by: Konrad Dybcio <konrad.dybcio@somainline.org> Link: https://lore.kernel.org/r/20201104232218.198800-4-konrad.dybcio@somainline.org Signed-off-by: Will Deacon <will@kernel.org> | 13 November 2020, 09:47:08 UTC |
e3dd11a | Konrad Dybcio | 04 November 2020, 23:22:11 UTC | arm64: kpti: Add KRYO2XX gold/silver CPU cores to kpti safelist QCOM KRYO2XX gold (big) silver (LITTLE) CPU cores are based on Cortex-A73 and Cortex-A53 respectively and are meltdown safe, hence add them to kpti_safe_list[]. Signed-off-by: Konrad Dybcio <konrad.dybcio@somainline.org> Link: https://lore.kernel.org/r/20201104232218.198800-3-konrad.dybcio@somainline.org Signed-off-by: Will Deacon <will@kernel.org> | 13 November 2020, 09:47:08 UTC |
77473cf | Konrad Dybcio | 04 November 2020, 23:22:10 UTC | arm64: Add MIDR value for KRYO2XX gold/silver CPU cores Add MIDR value for KRYO2XX gold (big) and silver (LITTLE) CPU cores which are used in Qualcomm Technologies, Inc. SoCs. This will be used to identify and apply errata which are applicable for these CPU cores. Signed-off-by: Konrad Dybcio <konrad.dybcio@somainline.org> Link: https://lore.kernel.org/r/20201104232218.198800-2-konrad.dybcio@somainline.org Signed-off-by: Will Deacon <will@kernel.org> | 13 November 2020, 09:47:08 UTC |
58284a9 | Anshuman Khandual | 13 November 2020, 07:30:14 UTC | arm64/mm: Validate hotplug range before creating linear mapping During memory hotplug process, the linear mapping should not be created for a given memory range if that would fall outside the maximum allowed linear range. Else it might cause memory corruption in the kernel virtual space. Maximum linear mapping region is [PAGE_OFFSET..(PAGE_END -1)] accommodating both its ends but excluding PAGE_END. Max physical range that can be mapped inside this linear mapping range, must also be derived from its end points. This ensures that arch_add_memory() validates memory hot add range for its potential linear mapping requirements, before creating it with __create_pgd_mapping(). Fixes: 4ab215061554 ("arm64: Add memory hotplug support") Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com> Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Will Deacon <will@kernel.org> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Ard Biesheuvel <ardb@kernel.org> Cc: Steven Price <steven.price@arm.com> Cc: Robin Murphy <robin.murphy@arm.com> Cc: David Hildenbrand <david@redhat.com> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: linux-arm-kernel@lists.infradead.org Cc: linux-kernel@vger.kernel.org Link: https://lore.kernel.org/r/1605252614-761-1-git-send-email-anshuman.khandual@arm.com Signed-off-by: Will Deacon <will@kernel.org> | 13 November 2020, 09:45:08 UTC |
41f3ed2 | Dave Airlie | 13 November 2020, 06:05:30 UTC | Merge tag 'amd-drm-fixes-5.10-2020-11-12' of git://people.freedesktop.org/~agd5f/linux into drm-fixes amd-drm-fixes-5.10-2020-11-12: amdgpu: - Pageflip fix for DCN3 - Declare TA firmware for green sardine - Headless navi fix Signed-off-by: Dave Airlie <airlied@redhat.com> From: Alex Deucher <alexdeucher@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201113055512.3963-1-alexander.deucher@amd.com | 13 November 2020, 06:05:31 UTC |
858fbdb | Dave Airlie | 13 November 2020, 06:01:35 UTC | Merge tag 'drm-intel-fixes-2020-11-13' of git://anongit.freedesktop.org/drm/drm-intel into drm-fixes - Pull phys pread/pwrite implementations to the backend (Chris) - Correctly set SFC capability for video engines (Venkata) Signed-off-by: Dave Airlie <airlied@redhat.com> From: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201113052551.GA1319429@intel.com | 13 November 2020, 06:01:41 UTC |
38a2509 | Tianci.Yin | 06 November 2020, 06:56:35 UTC | drm/amdgpu: enable DCN for navi10 headless SKU There is a NULL pointer crash when DCN disabled on headless SKU. On normal SKU, the variable adev->ddev.mode_config.funcs is initialized in dm_hw_init(), and it is fine to access it in amdgpu_device_resume(). But on headless SKU, DCN is disabled, the funcs variable is not initialized, then crash arises. Enable DCN to fix this issue. Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Guchun Chen <guchun.chen@amd.com> Signed-off-by: Tianci.Yin <tianci.yin@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> | 13 November 2020, 05:30:05 UTC |
2664219 | Roman Li | 26 October 2020, 21:12:34 UTC | drm/amdgpu: add ta firmware load for green-sardine [Why] In preparation to enabling hdcp on green sardine. [How] Add green-sardine ta f/w loading in psp_v12 Signed-off-by: Roman Li <roman.li@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> | 13 November 2020, 05:29:26 UTC |
59f7dcd | Dave Airlie | 13 November 2020, 05:01:03 UTC | Merge tag 'drm-misc-fixes-2020-11-12' of git://anongit.freedesktop.org/drm/drm-misc into drm-fixes One Kconfig fix for bridge/cdns, a missing include for hypervb_fb, an out-of-bound access fix for gma500 and a unbalanced regulator fix for mcde. Signed-off-by: Dave Airlie <airlied@redhat.com> From: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20201112130726.qwtryqvgspmljkax@gilmour.lan | 13 November 2020, 05:01:14 UTC |
50b8a74 | Masami Hiramatsu | 12 November 2020, 17:27:31 UTC | bootconfig: Extend the magic check range to the preceding 3 bytes Since Grub may align the size of initrd to 4 if user pass initrd from cpio, we have to check the preceding 3 bytes as well. Link: https://lkml.kernel.org/r/160520205132.303174.4876760192433315429.stgit@devnote2 Cc: stable@vger.kernel.org Fixes: 85c46b78da58 ("bootconfig: Add bootconfig magic word for indicating bootconfig explicitly") Reported-by: Chen Yu <yu.chen.surf@gmail.com> Tested-by: Chen Yu <yu.chen.surf@gmail.com> Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org> Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org> | 13 November 2020, 01:36:52 UTC |
c350f8b | Chen Zhou | 12 November 2020, 13:53:32 UTC | selinux: Fix error return code in sel_ib_pkey_sid_slow() Fix to return a negative error code from the error handling case instead of 0 in function sel_ib_pkey_sid_slow(), as done elsewhere in this function. Cc: stable@vger.kernel.org Fixes: 409dcf31538a ("selinux: Add a cache for quicker retreival of PKey SIDs") Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Chen Zhou <chenzhou10@huawei.com> Signed-off-by: Paul Moore <paul@paul-moore.com> | 13 November 2020, 01:16:09 UTC |
5ce6861 | Venkata Sandeep Dhanalakota | 06 November 2020, 01:18:42 UTC | drm/i915: Correctly set SFC capability for video engines SFC capability of video engines is not set correctly because i915 is testing for incorrect bits. Fixes: c5d3e39caa45 ("drm/i915: Engine discovery query") Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by: Venkata Sandeep Dhanalakota <venkata.s.dhanalakota@intel.com> Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: <stable@vger.kernel.org> # v5.3+ Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20201106011842.36203-1-daniele.ceraolospurio@intel.com (cherry picked from commit ad18fa0f5f052046cad96fee762b5c64f42dd86a) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> | 13 November 2020, 00:47:30 UTC |
0eb0feb | Chris Wilson | 05 November 2020, 15:49:34 UTC | drm/i915/gem: Pull phys pread/pwrite implementations to the backend Move the specialised interactions with the physical GEM object from the pread/pwrite ioctl handler into the phys backend. Currently, if one is able to exhaust the entire aperture and then try to pwrite into an object not backed by struct page, we accidentally invoked the phys pwrite handler on a non-phys object; calamitous. Fixes: c6790dc22312 ("drm/i915: Wean off drm_pci_alloc/drm_pci_free") Testcase: igt/gem_pwrite/exhaustion Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Cc: stable@vger.kernel.org Link: https://patchwork.freedesktop.org/patch/msgid/20201105154934.16022-2-chris@chris-wilson.co.uk (cherry picked from commit 852e1b3644817f071427b83859b889c788a0cf69) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> | 13 November 2020, 00:47:30 UTC |
0a1db6f | Matthew Auld | 05 November 2020, 15:49:33 UTC | drm/i915/gem: Allow backends to override pread implementation As there are more and more complicated interactions between the different backing stores and userspace, push the control into the backends rather than accumulate them all inside the ioctl handlers. Signed-off-by: Matthew Auld <matthew.auld@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20201105154934.16022-1-chris@chris-wilson.co.uk (cherry picked from commit 0049b688459b846f819b6e51c24cd0781fcfde41) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> | 13 November 2020, 00:47:30 UTC |
585e5b1 | Linus Torvalds | 13 November 2020, 00:39:58 UTC | Merge tag 'fscrypt-for-linus' of git://git.kernel.org/pub/scm/fs/fscrypt/fscrypt Pull fscrypt fix from Eric Biggers: "Fix a regression where new files weren't using inline encryption when they should be" * tag 'fscrypt-for-linus' of git://git.kernel.org/pub/scm/fs/fscrypt/fscrypt: fscrypt: fix inline encryption not used on new files | 13 November 2020, 00:39:58 UTC |
20ca21d | Linus Torvalds | 13 November 2020, 00:37:14 UTC | Merge tag 'gfs2-v5.10-rc3-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/gfs2/linux-gfs2 Pull gfs2 fixes from Andreas Gruenbacher: "Fix jdata data corruption and glock reference leak" * tag 'gfs2-v5.10-rc3-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/gfs2/linux-gfs2: gfs2: Fix case in which ail writes are done to jdata holes Revert "gfs2: Ignore journal log writes for jdata holes" gfs2: fix possible reference leak in gfs2_check_blk_type | 13 November 2020, 00:37:14 UTC |
77c7e1b | Mike Travis | 11 November 2020, 01:04:18 UTC | x86/platform/uv: Fix copied UV5 output archtype A test shows that the output contains a space: # cat /proc/sgi_uv/archtype NSGI4 U/UVX Remove that embedded space by copying the "trimmed" buffer instead of the untrimmed input character list. Use sizeof to remove size dependency on copy out length. Increase output buffer size by one character just in case BIOS sends an 8 character string for archtype. Fixes: 1e61f5a95f19 ("Add and decode Arch Type in UVsystab") Signed-off-by: Mike Travis <mike.travis@hpe.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Steve Wahl <steve.wahl@hpe.com> Link: https://lore.kernel.org/r/20201111010418.82133-1-mike.travis@hpe.com | 12 November 2020, 23:00:31 UTC |
db7c953 | Linus Torvalds | 12 November 2020, 22:02:04 UTC | Merge tag 'net-5.10-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net Pull networking fixes from Jakub Kicinski: "Current release - regressions: - arm64: dts: fsl-ls1028a-kontron-sl28: specify in-band mode for ENETC Current release - bugs in new features: - mptcp: provide rmem[0] limit offset to fix oops Previous release - regressions: - IPv6: Set SIT tunnel hard_header_len to zero to fix path MTU calculations - lan743x: correctly handle chips with internal PHY - bpf: Don't rely on GCC __attribute__((optimize)) to disable GCSE - mlx5e: Fix VXLAN port table synchronization after function reload Previous release - always broken: - bpf: Zero-fill re-used per-cpu map element - fix out-of-order UDP packets when forwarding with UDP GSO fraglists turned on: - fix UDP header access on Fast/frag0 UDP GRO - fix IP header access and skb lookup on Fast/frag0 UDP GRO - ethtool: netlink: add missing netdev_features_change() call - net: Update window_clamp if SOCK_RCVBUF is set - igc: Fix returning wrong statistics - ch_ktls: fix multiple leaks and corner cases in Chelsio TLS offload - tunnels: Fix off-by-one in lower MTU bounds for ICMP/ICMPv6 replies - r8169: disable hw csum for short packets on all chip versions - vrf: Fix fast path output packet handling with async Netfilter rules" * tag 'net-5.10-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net: (65 commits) lan743x: fix use of uninitialized variable net: udp: fix IP header access and skb lookup on Fast/frag0 UDP GRO net: udp: fix UDP header access on Fast/frag0 UDP GRO devlink: Avoid overwriting port attributes of registered port vrf: Fix fast path output packet handling with async Netfilter rules cosa: Add missing kfree in error path of cosa_write net: switch to the kernel.org patchwork instance ch_ktls: stop the txq if reaches threshold ch_ktls: tcb update fails sometimes ch_ktls/cxgb4: handle partial tag alone SKBs ch_ktls: don't free skb before sending FIN ch_ktls: packet handling prior to start marker ch_ktls: Correction in middle record handling ch_ktls: missing handling of header alone ch_ktls: Correction in trimmed_len calculation cxgb4/ch_ktls: creating skbs causes panic ch_ktls: Update cheksum information ch_ktls: Correction in finding correct length cxgb4/ch_ktls: decrypted bit is not enough net/x25: Fix null-ptr-deref in x25_connect ... | 12 November 2020, 22:02:04 UTC |
200f9d2 | Linus Torvalds | 12 November 2020, 21:49:12 UTC | Merge tag 'nfs-for-5.10-2' of git://git.linux-nfs.org/projects/anna/linux-nfs Pull NFS client bugfixes from Anna Schumaker: "Stable fixes: - Fix failure to unregister shrinker Other fixes: - Fix unnecessary locking to clear up some contention - Fix listxattr receive buffer size - Fix default mount options for nfsroot" * tag 'nfs-for-5.10-2' of git://git.linux-nfs.org/projects/anna/linux-nfs: NFS: Remove unnecessary inode lock in nfs_fsync_dir() NFS: Remove unnecessary inode locking in nfs_llseek_dir() NFS: Fix listxattr receive buffer size NFSv4.2: fix failure to unregister shrinker nfsroot: Default mount option should ask for built-in NFS version | 12 November 2020, 21:49:12 UTC |
ed4ffaf | Marc Zyngier | 10 November 2020, 14:13:08 UTC | KVM: arm64: Handle SCXTNUM_ELx traps As the kernel never sets HCR_EL2.EnSCXT, accesses to SCXTNUM_ELx will trap to EL2. Let's handle that as gracefully as possible by injecting an UNDEF exception into the guest. This is consistent with the guest's view of ID_AA64PFR0_EL1.CSV2 being at most 1. Signed-off-by: Marc Zyngier <maz@kernel.org> Acked-by: Will Deacon <will@kernel.org> Link: https://lore.kernel.org/r/20201110141308.451654-4-maz@kernel.org | 12 November 2020, 21:22:46 UTC |
338b179 | Marc Zyngier | 10 November 2020, 14:13:07 UTC | KVM: arm64: Unify trap handlers injecting an UNDEF A large number of system register trap handlers only inject an UNDEF exeption, and yet each class of sysreg seems to provide its own, identical function. Let's unify them all, saving us introducing yet another one later. Signed-off-by: Marc Zyngier <maz@kernel.org> Acked-by: Will Deacon <will@kernel.org> Link: https://lore.kernel.org/r/20201110141308.451654-3-maz@kernel.org | 12 November 2020, 21:22:45 UTC |
23711a5 | Marc Zyngier | 10 November 2020, 14:13:06 UTC | KVM: arm64: Allow setting of ID_AA64PFR0_EL1.CSV2 from userspace We now expose ID_AA64PFR0_EL1.CSV2=1 to guests running on hosts that are immune to Spectre-v2, but that don't have this field set, most likely because they predate the specification. However, this prevents the migration of guests that have started on a host the doesn't fake this CSV2 setting to one that does, as KVM rejects the write to ID_AA64PFR0_EL2 on the grounds that it isn't what is already there. In order to fix this, allow userspace to set this field as long as this doesn't result in a promising more than what is already there (setting CSV2 to 0 is acceptable, but setting it to 1 when it is already set to 0 isn't). Fixes: e1026237f9067 ("KVM: arm64: Set CSV2 for guests on hardware unaffected by Spectre-v2") Reported-by: Peng Liang <liangpeng10@huawei.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Acked-by: Will Deacon <will@kernel.org> Link: https://lore.kernel.org/r/20201110141308.451654-2-maz@kernel.org | 12 November 2020, 21:22:22 UTC |
4f6b838 | Marc Zyngier | 12 November 2020, 21:20:43 UTC | Merge tag 'v5.10-rc1' into kvmarm-master/next Linux 5.10-rc1 Signed-off-by: Marc Zyngier <maz@kernel.org> | 12 November 2020, 21:20:43 UTC |
c01a21b | Petr Vorel | 12 November 2020, 16:50:05 UTC | loop: Fix occasional uevent drop Commit 716ad0986cbd ("loop: Switch to set_capacity_revalidate_and_notify") causes an occasional drop of loop device uevent, which are no longer triggered in loop_set_size() but in a different part of code. Bug is reproducible with LTP test uevent01 [1]: i=0; while true; do i=$((i+1)); echo "== $i ==" lsmod |grep -q loop && rmmod -f loop ./uevent01 || break done Put back triggering through code called in loop_set_size(). Fix required to add yet another parameter to set_capacity_revalidate_and_notify(). [1] https://github.com/linux-test-project/ltp/blob/master/testcases/kernel/uevents/uevent01.c [hch: rebased on a different change to the prototype of set_capacity_revalidate_and_notify] Cc: stable@vger.kernel.org # v5.9 Fixes: 716ad0986cbd ("loop: Switch to set_capacity_revalidate_and_notify") Reported-by: <ltp@lists.linux.it> Signed-off-by: Petr Vorel <pvorel@suse.cz> Signed-off-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Jens Axboe <axboe@kernel.dk> | 12 November 2020, 20:59:04 UTC |
7e890c3 | Christoph Hellwig | 12 November 2020, 16:50:04 UTC | block: add a return value to set_capacity_revalidate_and_notify Return if the function ended up sending an uevent or not. Cc: stable@vger.kernel.org # v5.9 Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Petr Vorel <pvorel@suse.cz> Signed-off-by: Jens Axboe <axboe@kernel.dk> | 12 November 2020, 20:59:04 UTC |
af5043c | Linus Torvalds | 12 November 2020, 19:06:53 UTC | Merge tag 'acpi-5.10-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm Pull ACPI fixes from Rafael Wysocki: "These are mostly docmentation fixes and janitorial changes plus some new device IDs and a new quirk. Specifics: - Fix documentation regarding GPIO properties (Andy Shevchenko) - Fix spelling mistakes in ACPI documentation (Flavio Suligoi) - Fix white space inconsistencies in ACPI code (Maximilian Luz) - Fix string formatting in the ACPI Generic Event Device (GED) driver (Nick Desaulniers) - Add Intel Alder Lake device IDs to the ACPI drivers used by the Dynamic Platform and Thermal Framework (Srinivas Pandruvada) - Add lid-related DMI quirk for Medion Akoya E2228T to the ACPI button driver (Hans de Goede)" * tag 'acpi-5.10-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: ACPI: DPTF: Support Alder Lake Documentation: ACPI: fix spelling mistakes ACPI: button: Add DMI quirk for Medion Akoya E2228T ACPI: GED: fix -Wformat ACPI: Fix whitespace inconsistencies ACPI: scan: Fix acpi_dma_configure_id() kerneldoc name Documentation: firmware-guide: gpio-properties: Clarify initial output state Documentation: firmware-guide: gpio-properties: active_low only for GpioIo() Documentation: firmware-guide: gpio-properties: Fix factual mistakes | 12 November 2020, 19:06:53 UTC |
fcfb679 | Linus Torvalds | 12 November 2020, 19:03:38 UTC | Merge tag 'pm-5.10-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm Pull power management fixes from Rafael Wysocki: "Make the intel_pstate driver behave as expected when it operates in the passive mode with HWP enabled and the 'powersave' governor on top of it" * tag 'pm-5.10-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: cpufreq: intel_pstate: Take CPUFREQ_GOV_STRICT_TARGET into account cpufreq: Add strict_target to struct cpufreq_policy cpufreq: Introduce CPUFREQ_GOV_STRICT_TARGET cpufreq: Introduce governor flags | 12 November 2020, 19:03:38 UTC |
edbc211 | Sven Van Asbroeck | 12 November 2020, 15:25:13 UTC | lan743x: fix use of uninitialized variable When no devicetree is present, the driver will use an uninitialized variable. Fix by initializing this variable. Fixes: 902a66e08cea ("lan743x: correctly handle chips with internal PHY") Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Sven Van Asbroeck <thesven73@gmail.com> Link: https://lore.kernel.org/r/20201112152513.1941-1-TheSven73@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> | 12 November 2020, 18:03:16 UTC |
5861c8c | Jakub Kicinski | 12 November 2020, 17:55:58 UTC | Merge branch 'net-udp-fix-fast-frag0-udp-gro' Alexander Lobakin says: ==================== net: udp: fix Fast/frag0 UDP GRO While testing UDP GSO fraglists forwarding through driver that uses Fast GRO (via napi_gro_frags()), I was observing lots of out-of-order iperf packets: [ ID] Interval Transfer Bitrate Jitter [SUM] 0.0-40.0 sec 12106 datagrams received out-of-order Simple switch to napi_gro_receive() or any other method without frag0 shortcut completely resolved them. I've found two incorrect header accesses in GRO receive callback(s): - udp_hdr() (instead of udp_gro_udphdr()) that always points to junk in "fast" mode and could probably do this in "regular". This was the actual bug that caused all out-of-order delivers; - udp{4,6}_lib_lookup_skb() -> ip{,v6}_hdr() (instead of skb_gro_network_header()) that potentionally might return odd pointers in both modes. Each patch addresses one of these two issues. This doesn't cover a support for nested tunnels as it's out of the subject and requires more invasive changes. It will be handled separately in net-next series. Credits: Cc: Eric Dumazet <edumazet@google.com> Cc: Jakub Kicinski <kuba@kernel.org> Cc: Willem de Bruijn <willemb@google.com> Since v4 [0]: - split the fix into two logical ones (Willem); - replace ternaries with plain ifs to beautify the code (Jakub); - drop p->data part to reintroduce it later in abovementioned set. Since v3 [1]: - restore the original {,__}udp{4,6}_lib_lookup_skb() and use private versions of them inside GRO code (Willem). Since v2 [2]: - dropped redundant check introduced in v2 as it's performed right before (thanks to Eric); - udp_hdr() switched to data + off for skbs from list (also Eric); - fixed possible malfunction of {,__}udp{4,6}_lib_lookup_skb() with Fast/frag0 due to ip{,v6}_hdr() usage (Willem). Since v1 [3]: - added a NULL pointer check for "uh" as suggested by Willem. [0] https://lore.kernel.org/netdev/Ha2hou5eJPcblo4abjAqxZRzIl1RaLs2Hy0oOAgFs@cp4-web-036.plabs.ch [1] https://lore.kernel.org/netdev/MgZce9htmEtCtHg7pmWxXXfdhmQ6AHrnltXC41zOoo@cp7-web-042.plabs.ch [2] https://lore.kernel.org/netdev/0eaG8xtbtKY1dEKCTKUBubGiC9QawGgB3tVZtNqVdY@cp4-web-030.plabs.ch [3] https://lore.kernel.org/netdev/YazU6GEzBdpyZMDMwJirxDX7B4sualpDG68ADZYvJI@cp4-web-034.plabs.ch ==================== Link: https://lore.kernel.org/r/hjGOh0iCOYyo1FPiZh6TMXcx3YCgNs1T1eGKLrDz8@cp4-web-037.plabs.ch Signed-off-by: Jakub Kicinski <kuba@kernel.org> | 12 November 2020, 17:55:59 UTC |
55e7298 | Alexander Lobakin | 11 November 2020, 20:45:38 UTC | net: udp: fix IP header access and skb lookup on Fast/frag0 UDP GRO udp{4,6}_lib_lookup_skb() use ip{,v6}_hdr() to get IP header of the packet. While it's probably OK for non-frag0 paths, this helpers will also point to junk on Fast/frag0 GRO when all headers are located in frags. As a result, sk/skb lookup may fail or give wrong results. To support both GRO modes, skb_gro_network_header() might be used. To not modify original functions, add private versions of udp{4,6}_lib_lookup_skb() only to perform correct sk lookups on GRO. Present since the introduction of "application-level" UDP GRO in 4.7-rc1. Misc: replace totally unneeded ternaries with plain ifs. Fixes: a6024562ffd7 ("udp: Add GRO functions to UDP socket") Suggested-by: Willem de Bruijn <willemb@google.com> Cc: Eric Dumazet <edumazet@google.com> Signed-off-by: Alexander Lobakin <alobakin@pm.me> Acked-by: Willem de Bruijn <willemb@google.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org> | 12 November 2020, 17:55:51 UTC |
4b1a862 | Alexander Lobakin | 11 November 2020, 20:45:25 UTC | net: udp: fix UDP header access on Fast/frag0 UDP GRO UDP GRO uses udp_hdr(skb) in its .gro_receive() callback. While it's probably OK for non-frag0 paths (when all headers or even the entire frame are already in skb head), this inline points to junk when using Fast GRO (napi_gro_frags() or napi_gro_receive() with only Ethernet header in skb head and all the rest in the frags) and breaks GRO packet compilation and the packet flow itself. To support both modes, skb_gro_header_fast() + skb_gro_header_slow() are typically used. UDP even has an inline helper that makes use of them, udp_gro_udphdr(). Use that instead of troublemaking udp_hdr() to get rid of the out-of-order delivers. Present since the introduction of plain UDP GRO in 5.0-rc1. Fixes: e20cf8d3f1f7 ("udp: implement GRO for plain UDP sockets.") Cc: Eric Dumazet <edumazet@google.com> Signed-off-by: Alexander Lobakin <alobakin@pm.me> Acked-by: Willem de Bruijn <willemb@google.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org> | 12 November 2020, 17:55:43 UTC |
4e79e3f | Bob Peterson | 12 November 2020, 16:02:48 UTC | gfs2: Fix case in which ail writes are done to jdata holes Patch b2a846dbef4e ("gfs2: Ignore journal log writes for jdata holes") tried (unsuccessfully) to fix a case in which writes were done to jdata blocks, the blocks are sent to the ail list, then a punch_hole or truncate operation caused the blocks to be freed. In other words, the ail items are for jdata holes. Before b2a846dbef4e, the jdata hole caused function gfs2_block_map to return -EIO, which was eventually interpreted as an IO error to the journal, and then withdraw. This patch changes function gfs2_get_block_noalloc, which is only used for jdata writes, so it returns -ENODATA rather than -EIO, and when -ENODATA is returned to gfs2_ail1_start_one, the error is ignored. We can safely ignore it because gfs2_ail1_start_one is only called when the jdata pages have already been written and truncated, so the ail1 content no longer applies. Signed-off-by: Bob Peterson <rpeterso@redhat.com> Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com> | 12 November 2020, 17:55:20 UTC |
d3039c0 | Bob Peterson | 11 November 2020, 17:09:55 UTC | Revert "gfs2: Ignore journal log writes for jdata holes" This reverts commit b2a846dbef4ef54ef032f0f5ee188c609a0278a7. That commit changed the behavior of function gfs2_block_map to return -ENODATA in cases where a hole (IOMAP_HOLE) is encountered and create is false. While that fixed the intended problem for jdata, it also broke other callers of gfs2_block_map such as some jdata block reads. Before the patch, an encountered hole would be skipped and the buffer seen as unmapped by the caller. The patch changed the behavior to return -ENODATA, which is interpreted as an error by the caller. The -ENODATA return code should be restricted to the specific case where jdata holes are encountered during ail1 writes. That will be done in a later patch. Signed-off-by: Bob Peterson <rpeterso@redhat.com> Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com> | 12 November 2020, 17:41:57 UTC |
8a5c290 | Jakub Kicinski | 12 November 2020, 16:47:22 UTC | Merge branch '40GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/net-queue Tony Nguyen says: ==================== Intel Wired LAN Driver Updates 2020-11-10 This series contains updates to i40e and igc drivers and the MAINTAINERS file. Slawomir fixes updating VF MAC addresses to fix various issues related to reporting and setting of these addresses for i40e. Dan Carpenter fixes a possible used before being initialized issue for i40e. Vinicius fixes reporting of netdev stats for igc. Tony updates repositories for Intel Ethernet Drivers. * '40GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/net-queue: MAINTAINERS: Update repositories for Intel Ethernet Drivers igc: Fix returning wrong statistics i40e, xsk: uninitialized variable in i40e_clean_rx_irq_zc() i40e: Fix MAC address setting for a VF via Host/VM ==================== Link: https://lore.kernel.org/r/20201111001955.533210-1-anthony.l.nguyen@intel.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> | 12 November 2020, 16:47:23 UTC |
9f73bd1 | Parav Pandit | 11 November 2020, 03:47:44 UTC | devlink: Avoid overwriting port attributes of registered port Cited commit in fixes tag overwrites the port attributes for the registered port. Avoid such error by checking registered flag before setting attributes. Fixes: 71ad8d55f8e5 ("devlink: Replace devlink_port_attrs_set parameters with a struct") Signed-off-by: Parav Pandit <parav@nvidia.com> Reviewed-by: Jiri Pirko <jiri@nvidia.com> Link: https://lore.kernel.org/r/20201111034744.35554-1-parav@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> | 12 November 2020, 16:06:57 UTC |
9e2b7fa | Martin Willi | 06 November 2020, 07:30:30 UTC | vrf: Fix fast path output packet handling with async Netfilter rules VRF devices use an optimized direct path on output if a default qdisc is involved, calling Netfilter hooks directly. This path, however, does not consider Netfilter rules completing asynchronously, such as with NFQUEUE. The Netfilter okfn() is called for asynchronously accepted packets, but the VRF never passes that packet down the stack to send it out over the slave device. Using the slower redirect path for this seems not feasible, as we do not know beforehand if a Netfilter hook has asynchronously completing rules. Fix the use of asynchronously completing Netfilter rules in OUTPUT and POSTROUTING by using a special completion function that additionally calls dst_output() to pass the packet down the stack. Also, slightly adjust the use of nf_reset_ct() so that is called in the asynchronous case, too. Fixes: dcdd43c41e60 ("net: vrf: performance improvements for IPv4") Fixes: a9ec54d1b0cd ("net: vrf: performance improvements for IPv6") Signed-off-by: Martin Willi <martin@strongswan.org> Link: https://lore.kernel.org/r/20201106073030.3974927-1-martin@strongswan.org Signed-off-by: Jakub Kicinski <kuba@kernel.org> | 12 November 2020, 15:47:06 UTC |
11decaf | Trond Myklebust | 30 October 2020, 21:57:30 UTC | NFS: Remove unnecessary inode lock in nfs_fsync_dir() nfs_inc_stats() is already thread-safe, and there are no other reasons to hold the inode lock here. Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com> Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com> | 12 November 2020, 15:41:26 UTC |