Re: [PATCH 4.4 00/47] 4.4.155-stable review
On 8 September 2018 at 02:39, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.4.155 release. > There are 47 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Sun Sep 9 21:08:44 UTC 2018. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.155-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-4.4.y > and the diffstat can be found below. > > thanks, > > greg k-h > > - > Pseudo-Shortlog of commits: > > Jann Horn > userns: move user access out of the mutex Results from Linaro’s test farm. Regressions on arm64, arm, x86_64 and i386. LTP containers tests Test cases: userns02/03/06/07 failed on all devices. LTP: user_namespace2 1 TBROK : safe_macros.c:452: userns02.c:95: write(6,0x7ffc133113d0,18446744073709551615) failed: errno=EFAULT(14): Bad address Other bug from kernel selftests, mount_run_tests.sh bugs needs to be investigated. selftests: mount_run_tests.sh [FAIL] write to /proc/self/uid_map failed: Bad address Summary kernel: 4.4.155-rc1 git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git git branch: linux-4.4.y git commit: 892befb7e4dca0c09750b1fa1a0ce632691730a7 git describe: v4.4.153-129-g892befb7e4dc Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.4-oe/build/v4.4.153-129-g892befb7e4dc Regressions (compared to build v4.4.153-81-gc9eed05cd5dd) i386: juno-r2 - arm64: qemu_arm: qemu_i386: qemu_x86_64: x15 - arm: x86_64: kselftest: * mount_run_tests.sh * test src: https://www.kernel.org/pub/linux/kernel/v4.x/linux-4.18.tar.xz ltp-containers-tests: * runltp_containers * userns02 * userns03 * userns06 * userns07 * test src: git://github.com/linux-test-project/ltp.git -- Linaro QA (BETA) https://qa-reports.linaro.org
Re: [PATCH 4.4 00/47] 4.4.155-stable review
On 8 September 2018 at 02:39, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.4.155 release. > There are 47 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Sun Sep 9 21:08:44 UTC 2018. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.155-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-4.4.y > and the diffstat can be found below. > > thanks, > > greg k-h > > - > Pseudo-Shortlog of commits: > > Jann Horn > userns: move user access out of the mutex Results from Linaro’s test farm. Regressions on arm64, arm, x86_64 and i386. LTP containers tests Test cases: userns02/03/06/07 failed on all devices. LTP: user_namespace2 1 TBROK : safe_macros.c:452: userns02.c:95: write(6,0x7ffc133113d0,18446744073709551615) failed: errno=EFAULT(14): Bad address Other bug from kernel selftests, mount_run_tests.sh bugs needs to be investigated. selftests: mount_run_tests.sh [FAIL] write to /proc/self/uid_map failed: Bad address Summary kernel: 4.4.155-rc1 git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git git branch: linux-4.4.y git commit: 892befb7e4dca0c09750b1fa1a0ce632691730a7 git describe: v4.4.153-129-g892befb7e4dc Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.4-oe/build/v4.4.153-129-g892befb7e4dc Regressions (compared to build v4.4.153-81-gc9eed05cd5dd) i386: juno-r2 - arm64: qemu_arm: qemu_i386: qemu_x86_64: x15 - arm: x86_64: kselftest: * mount_run_tests.sh * test src: https://www.kernel.org/pub/linux/kernel/v4.x/linux-4.18.tar.xz ltp-containers-tests: * runltp_containers * userns02 * userns03 * userns06 * userns07 * test src: git://github.com/linux-test-project/ltp.git -- Linaro QA (BETA) https://qa-reports.linaro.org
Re: [PATCH 4.9 00/63] 4.9.126-stable review
On 8 September 2018 at 02:39, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.9.126 release. > There are 63 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Sun Sep 9 21:09:58 UTC 2018. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.126-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-4.9.y > and the diffstat can be found below. > > thanks, > > greg k-h Results from Linaro’s test farm. No regressions on arm64, arm, x86_64 and i386. Summary kernel: 4.9.126-rc1 git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git git branch: linux-4.9.y git commit: 189fbc4d1993bdac9e743e81f3907d6f16cc1f1b git describe: v4.9.124-172-g189fbc4d1993 Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.9-oe/build/v4.9.124-172-g189fbc4d1993 No regressions (compared to build v4.9.124-108-g31b3687b22c5) Boards, architectures and test suites: - dragonboard-410c - arm64 * boot - pass: 21, * kselftest - pass: 47, skip: 50, fail: 11 * libhugetlbfs - pass: 89, skip: 1, fail: 1 * ltp-cap_bounds-tests - pass: 2, * ltp-containers-tests - pass: 80, skip: 1, * ltp-cve-tests - pass: 26, skip: 9, * ltp-fcntl-locktests-tests - pass: 2, * ltp-filecaps-tests - pass: 2, * ltp-fs-tests - pass: 60, skip: 6, * ltp-fs_bind-tests - pass: 2, * ltp-fs_perms_simple-tests - pass: 19, * ltp-fsx-tests - pass: 2, * ltp-hugetlb-tests - pass: 21, skip: 1, * ltp-io-tests - pass: 3, * ltp-ipc-tests - pass: 9, * ltp-math-tests - pass: 11, * ltp-nptl-tests - pass: 2, * ltp-pty-tests - pass: 4, * ltp-sched-tests - pass: 14, * ltp-securebits-tests - pass: 4, * ltp-syscalls-tests - pass: 1012, skip: 137, * ltp-timers-tests - pass: 13, hi6220-hikey - arm64 * boot - pass: 21, * kselftest - pass: 48, skip: 44, fail: 11 * libhugetlbfs - pass: 89, skip: 1, fail: 1 * ltp-cap_bounds-tests - pass: 2, * ltp-containers-tests - pass: 80, skip: 1, * ltp-cve-tests - pass: 27, skip: 8, * ltp-fcntl-locktests-tests - pass: 2, * ltp-filecaps-tests - pass: 2, * ltp-fs-tests - pass: 60, skip: 6, * ltp-fs_bind-tests - pass: 2, * ltp-fs_perms_simple-tests - pass: 19, * ltp-fsx-tests - pass: 2, * ltp-hugetlb-tests - pass: 21, skip: 1, * ltp-io-tests - pass: 3, * ltp-ipc-tests - pass: 9, * ltp-math-tests - pass: 11, * ltp-nptl-tests - pass: 2, * ltp-pty-tests - pass: 4, * ltp-sched-tests - pass: 10, skip: 4, * ltp-securebits-tests - pass: 4, * ltp-syscalls-tests - pass: 1011, skip: 138, * ltp-timers-tests - pass: 13, i386 * boot - pass: 22, * kselftest - pass: 71, skip: 45, fail: 14 * libhugetlbfs - pass: 1, * ltp-cap_bounds-tests - pass: 2, * ltp-containers-tests - pass: 79, skip: 1, * ltp-cve-tests - pass: 27, skip: 4, fail: 3 * ltp-fcntl-locktests-tests - pass: 2, * ltp-filecaps-tests - pass: 2, * ltp-fs-tests - pass: 60, skip: 6, * ltp-fs_bind-tests - pass: 2, * ltp-fs_perms_simple-tests - pass: 19, * ltp-fsx-tests - pass: 2, * ltp-hugetlb-tests - pass: 20, skip: 1, * ltp-io-tests - pass: 3, * ltp-ipc-tests - pass: 8, * ltp-math-tests - pass: 11, * ltp-nptl-tests - pass: 2, * ltp-open-posix-tests - pass: 1682, skip: 46, fail: 5 * ltp-pty-tests - pass: 4, * ltp-sched-tests - pass: 10, skip: 4, * ltp-securebits-tests - pass: 4, * ltp-syscalls-tests - pass: 1085, skip: 59, fail: 2 * ltp-timers-tests - pass: 13, juno-r2 - arm64 * boot - pass: 22, * kselftest - pass: 51, skip: 46, fail: 12 * libhugetlbfs - pass: 89, skip: 1, fail: 1 * ltp-cap_bounds-tests - pass: 2, * ltp-containers-tests - pass: 80, skip: 1, * ltp-cve-tests - pass: 26, skip: 9, * ltp-fcntl-locktests-tests - pass: 2, * ltp-filecaps-tests - pass: 2, * ltp-fs-tests - pass: 60, skip: 6, * ltp-fs_bind-tests - pass: 2, * ltp-fs_perms_simple-tests - pass: 19, * ltp-fsx-tests - pass: 2, * ltp-hugetlb-tests - pass: 22, * ltp-io-tests - pass: 3, * ltp-ipc-tests - pass: 9, * ltp-math-tests - pass: 11, * ltp-nptl-tests - pass: 2, * ltp-open-posix-tests - pass: 1689, skip: 41, fail: 5 * ltp-pty-tests - pass: 4, * ltp-sched-tests - pass: 10, skip: 4, * ltp-securebits-tests - pass: 4, * ltp-syscalls-tests - pass: 1012, skip: 137, * ltp-timers-tests - pass: 13, qemu_arm * boot - pass: 21, * kselftest - pass: 48, skip: 53, fail: 7 * libhugetlbfs - pass: 86, skip: 1, fail: 1 * ltp-cap_bounds-tests - pass: 2, * ltp-containers-tests - pass: 79, skip: 2, * ltp-cve-tests - pass: 23, skip: 12, * ltp-fcntl-locktests-tests - pass: 2, * ltp-filecaps-tests - pass: 2, * ltp-fs-tests - pass: 61, skip: 5, * ltp-fs_bind-tests - pass: 2, * ltp-fs_perms_simple-tests - pass: 19, * ltp-fsx-tests -
Re: [PATCH 4.9 00/63] 4.9.126-stable review
On 8 September 2018 at 02:39, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.9.126 release. > There are 63 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Sun Sep 9 21:09:58 UTC 2018. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.126-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-4.9.y > and the diffstat can be found below. > > thanks, > > greg k-h Results from Linaro’s test farm. No regressions on arm64, arm, x86_64 and i386. Summary kernel: 4.9.126-rc1 git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git git branch: linux-4.9.y git commit: 189fbc4d1993bdac9e743e81f3907d6f16cc1f1b git describe: v4.9.124-172-g189fbc4d1993 Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.9-oe/build/v4.9.124-172-g189fbc4d1993 No regressions (compared to build v4.9.124-108-g31b3687b22c5) Boards, architectures and test suites: - dragonboard-410c - arm64 * boot - pass: 21, * kselftest - pass: 47, skip: 50, fail: 11 * libhugetlbfs - pass: 89, skip: 1, fail: 1 * ltp-cap_bounds-tests - pass: 2, * ltp-containers-tests - pass: 80, skip: 1, * ltp-cve-tests - pass: 26, skip: 9, * ltp-fcntl-locktests-tests - pass: 2, * ltp-filecaps-tests - pass: 2, * ltp-fs-tests - pass: 60, skip: 6, * ltp-fs_bind-tests - pass: 2, * ltp-fs_perms_simple-tests - pass: 19, * ltp-fsx-tests - pass: 2, * ltp-hugetlb-tests - pass: 21, skip: 1, * ltp-io-tests - pass: 3, * ltp-ipc-tests - pass: 9, * ltp-math-tests - pass: 11, * ltp-nptl-tests - pass: 2, * ltp-pty-tests - pass: 4, * ltp-sched-tests - pass: 14, * ltp-securebits-tests - pass: 4, * ltp-syscalls-tests - pass: 1012, skip: 137, * ltp-timers-tests - pass: 13, hi6220-hikey - arm64 * boot - pass: 21, * kselftest - pass: 48, skip: 44, fail: 11 * libhugetlbfs - pass: 89, skip: 1, fail: 1 * ltp-cap_bounds-tests - pass: 2, * ltp-containers-tests - pass: 80, skip: 1, * ltp-cve-tests - pass: 27, skip: 8, * ltp-fcntl-locktests-tests - pass: 2, * ltp-filecaps-tests - pass: 2, * ltp-fs-tests - pass: 60, skip: 6, * ltp-fs_bind-tests - pass: 2, * ltp-fs_perms_simple-tests - pass: 19, * ltp-fsx-tests - pass: 2, * ltp-hugetlb-tests - pass: 21, skip: 1, * ltp-io-tests - pass: 3, * ltp-ipc-tests - pass: 9, * ltp-math-tests - pass: 11, * ltp-nptl-tests - pass: 2, * ltp-pty-tests - pass: 4, * ltp-sched-tests - pass: 10, skip: 4, * ltp-securebits-tests - pass: 4, * ltp-syscalls-tests - pass: 1011, skip: 138, * ltp-timers-tests - pass: 13, i386 * boot - pass: 22, * kselftest - pass: 71, skip: 45, fail: 14 * libhugetlbfs - pass: 1, * ltp-cap_bounds-tests - pass: 2, * ltp-containers-tests - pass: 79, skip: 1, * ltp-cve-tests - pass: 27, skip: 4, fail: 3 * ltp-fcntl-locktests-tests - pass: 2, * ltp-filecaps-tests - pass: 2, * ltp-fs-tests - pass: 60, skip: 6, * ltp-fs_bind-tests - pass: 2, * ltp-fs_perms_simple-tests - pass: 19, * ltp-fsx-tests - pass: 2, * ltp-hugetlb-tests - pass: 20, skip: 1, * ltp-io-tests - pass: 3, * ltp-ipc-tests - pass: 8, * ltp-math-tests - pass: 11, * ltp-nptl-tests - pass: 2, * ltp-open-posix-tests - pass: 1682, skip: 46, fail: 5 * ltp-pty-tests - pass: 4, * ltp-sched-tests - pass: 10, skip: 4, * ltp-securebits-tests - pass: 4, * ltp-syscalls-tests - pass: 1085, skip: 59, fail: 2 * ltp-timers-tests - pass: 13, juno-r2 - arm64 * boot - pass: 22, * kselftest - pass: 51, skip: 46, fail: 12 * libhugetlbfs - pass: 89, skip: 1, fail: 1 * ltp-cap_bounds-tests - pass: 2, * ltp-containers-tests - pass: 80, skip: 1, * ltp-cve-tests - pass: 26, skip: 9, * ltp-fcntl-locktests-tests - pass: 2, * ltp-filecaps-tests - pass: 2, * ltp-fs-tests - pass: 60, skip: 6, * ltp-fs_bind-tests - pass: 2, * ltp-fs_perms_simple-tests - pass: 19, * ltp-fsx-tests - pass: 2, * ltp-hugetlb-tests - pass: 22, * ltp-io-tests - pass: 3, * ltp-ipc-tests - pass: 9, * ltp-math-tests - pass: 11, * ltp-nptl-tests - pass: 2, * ltp-open-posix-tests - pass: 1689, skip: 41, fail: 5 * ltp-pty-tests - pass: 4, * ltp-sched-tests - pass: 10, skip: 4, * ltp-securebits-tests - pass: 4, * ltp-syscalls-tests - pass: 1012, skip: 137, * ltp-timers-tests - pass: 13, qemu_arm * boot - pass: 21, * kselftest - pass: 48, skip: 53, fail: 7 * libhugetlbfs - pass: 86, skip: 1, fail: 1 * ltp-cap_bounds-tests - pass: 2, * ltp-containers-tests - pass: 79, skip: 2, * ltp-cve-tests - pass: 23, skip: 12, * ltp-fcntl-locktests-tests - pass: 2, * ltp-filecaps-tests - pass: 2, * ltp-fs-tests - pass: 61, skip: 5, * ltp-fs_bind-tests - pass: 2, * ltp-fs_perms_simple-tests - pass: 19, * ltp-fsx-tests -
Re: [PATCH 4.14 00/89] 4.14.69-stable review
On 8 September 2018 at 02:38, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.14.69 release. > There are 89 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Sun Sep 9 21:08:28 UTC 2018. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.69-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-4.14.y > and the diffstat can be found below. > > thanks, > > greg k-h Results from Linaro’s test farm. No regressions on arm64, arm, x86_64 and i386. Summary kernel: 4.14.69-rc1 git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git git branch: linux-4.14.y git commit: c5a43c17e80b7b35788d3df112f959251d7be8fa git describe: v4.14.67-257-gc5a43c17e80b Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.14-oe/build/v4.14.67-257-gc5a43c17e80b No regressions (compared to build v4.14.67-167-ge2d662d77f7a) Boards, architectures and test suites: - dragonboard-410c - arm64 * boot - pass: 17, fail: 4 * ltp-cap_bounds-tests - pass: 2, * ltp-containers-tests - pass: 80, skip: 1, * ltp-cve-tests - pass: 26, skip: 9, * ltp-fcntl-locktests-tests - pass: 2, * ltp-filecaps-tests - pass: 2, * ltp-fs-tests - pass: 60, skip: 6, * ltp-fs_bind-tests - pass: 2, * ltp-fs_perms_simple-tests - pass: 19, * ltp-fsx-tests - pass: 2, * ltp-hugetlb-tests - pass: 21, skip: 1, * ltp-io-tests - pass: 3, * ltp-ipc-tests - pass: 9, * ltp-nptl-tests - pass: 2, * ltp-sched-tests - pass: 14, * ltp-securebits-tests - pass: 4, * ltp-syscalls-tests - pass: 1014, skip: 135, * ltp-timers-tests - pass: 13, hi6220-hikey - arm64 * boot - pass: 21, * kselftest - pass: 58, skip: 43, fail: 9 * libhugetlbfs - pass: 89, skip: 1, fail: 1 * ltp-cap_bounds-tests - pass: 2, * ltp-containers-tests - pass: 80, skip: 1, * ltp-cve-tests - pass: 27, skip: 8, * ltp-fcntl-locktests-tests - pass: 2, * ltp-filecaps-tests - pass: 2, * ltp-fs-tests - pass: 60, skip: 6, * ltp-fs_bind-tests - pass: 2, * ltp-fs_perms_simple-tests - pass: 19, * ltp-fsx-tests - pass: 2, * ltp-hugetlb-tests - pass: 21, skip: 1, * ltp-io-tests - pass: 3, * ltp-ipc-tests - pass: 9, * ltp-math-tests - pass: 11, * ltp-nptl-tests - pass: 2, * ltp-pty-tests - pass: 4, * ltp-sched-tests - pass: 10, skip: 4, * ltp-securebits-tests - pass: 4, * ltp-syscalls-tests - pass: 1013, skip: 136, * ltp-timers-tests - pass: 13, i386 * boot - pass: 22, * kselftest - pass: 75, skip: 45, fail: 12 * libhugetlbfs - pass: 1, * ltp-cap_bounds-tests - pass: 2, * ltp-containers-tests - pass: 80, skip: 1, * ltp-cve-tests - pass: 28, skip: 4, fail: 3 * ltp-fcntl-locktests-tests - pass: 2, * ltp-filecaps-tests - pass: 2, * ltp-fs-tests - pass: 59, skip: 6, * ltp-fs_bind-tests - pass: 2, * ltp-fs_perms_simple-tests - pass: 19, * ltp-fsx-tests - pass: 2, * ltp-hugetlb-tests - pass: 21, skip: 1, * ltp-io-tests - pass: 3, * ltp-ipc-tests - pass: 9, * ltp-math-tests - pass: 10, * ltp-nptl-tests - pass: 2, * ltp-open-posix-tests - pass: 1686, skip: 43, fail: 5 * ltp-pty-tests - pass: 4, * ltp-sched-tests - pass: 10, skip: 4, * ltp-securebits-tests - pass: 4, * ltp-syscalls-tests - pass: 1087, skip: 59, fail: 2 * ltp-timers-tests - pass: 13, juno-r2 - arm64 * boot - pass: 22, * kselftest - pass: 53, skip: 46, fail: 10 * libhugetlbfs - pass: 89, skip: 1, fail: 1 * ltp-cap_bounds-tests - pass: 2, * ltp-containers-tests - pass: 80, skip: 1, * ltp-filecaps-tests - pass: 2, * ltp-fs-tests - pass: 60, skip: 6, * ltp-fs_bind-tests - pass: 2, * ltp-hugetlb-tests - pass: 22, * ltp-ipc-tests - pass: 9, * ltp-math-tests - pass: 11, * ltp-nptl-tests - pass: 2, * ltp-open-posix-tests - pass: 1689, skip: 41, fail: 5 * ltp-pty-tests - pass: 4, * ltp-sched-tests - pass: 10, skip: 4, * ltp-securebits-tests - pass: 4, * ltp-syscalls-tests - pass: 1014, skip: 135, * ltp-timers-tests - pass: 13, qemu_arm * boot - pass: 21, * kselftest - pass: 48, skip: 54, fail: 6 * libhugetlbfs - pass: 86, skip: 1, fail: 1 * ltp-cap_bounds-tests - pass: 2, * ltp-containers-tests - pass: 79, skip: 2, * ltp-cve-tests - pass: 23, skip: 12, * ltp-fcntl-locktests-tests - pass: 2, * ltp-filecaps-tests - pass: 2, * ltp-fs-tests - pass: 61, skip: 5, * ltp-fs_bind-tests - pass: 2, * ltp-fs_perms_simple-tests - pass: 19, * ltp-fsx-tests - pass: 2, * ltp-hugetlb-tests - pass: 21, skip: 1, * ltp-io-tests - pass: 3, * ltp-ipc-tests - pass: 9, * ltp-math-tests - pass: 11, * ltp-nptl-tests - pass: 2, * ltp-pty-tests - pass: 4, * ltp-sched-tests - pass: 8, skip: 6, * ltp-securebits-tests - pass: 4, * ltp-syscalls-tests - pass: 1050, skip:
Re: [PATCH 4.14 00/89] 4.14.69-stable review
On 8 September 2018 at 02:38, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.14.69 release. > There are 89 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Sun Sep 9 21:08:28 UTC 2018. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.69-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-4.14.y > and the diffstat can be found below. > > thanks, > > greg k-h Results from Linaro’s test farm. No regressions on arm64, arm, x86_64 and i386. Summary kernel: 4.14.69-rc1 git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git git branch: linux-4.14.y git commit: c5a43c17e80b7b35788d3df112f959251d7be8fa git describe: v4.14.67-257-gc5a43c17e80b Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.14-oe/build/v4.14.67-257-gc5a43c17e80b No regressions (compared to build v4.14.67-167-ge2d662d77f7a) Boards, architectures and test suites: - dragonboard-410c - arm64 * boot - pass: 17, fail: 4 * ltp-cap_bounds-tests - pass: 2, * ltp-containers-tests - pass: 80, skip: 1, * ltp-cve-tests - pass: 26, skip: 9, * ltp-fcntl-locktests-tests - pass: 2, * ltp-filecaps-tests - pass: 2, * ltp-fs-tests - pass: 60, skip: 6, * ltp-fs_bind-tests - pass: 2, * ltp-fs_perms_simple-tests - pass: 19, * ltp-fsx-tests - pass: 2, * ltp-hugetlb-tests - pass: 21, skip: 1, * ltp-io-tests - pass: 3, * ltp-ipc-tests - pass: 9, * ltp-nptl-tests - pass: 2, * ltp-sched-tests - pass: 14, * ltp-securebits-tests - pass: 4, * ltp-syscalls-tests - pass: 1014, skip: 135, * ltp-timers-tests - pass: 13, hi6220-hikey - arm64 * boot - pass: 21, * kselftest - pass: 58, skip: 43, fail: 9 * libhugetlbfs - pass: 89, skip: 1, fail: 1 * ltp-cap_bounds-tests - pass: 2, * ltp-containers-tests - pass: 80, skip: 1, * ltp-cve-tests - pass: 27, skip: 8, * ltp-fcntl-locktests-tests - pass: 2, * ltp-filecaps-tests - pass: 2, * ltp-fs-tests - pass: 60, skip: 6, * ltp-fs_bind-tests - pass: 2, * ltp-fs_perms_simple-tests - pass: 19, * ltp-fsx-tests - pass: 2, * ltp-hugetlb-tests - pass: 21, skip: 1, * ltp-io-tests - pass: 3, * ltp-ipc-tests - pass: 9, * ltp-math-tests - pass: 11, * ltp-nptl-tests - pass: 2, * ltp-pty-tests - pass: 4, * ltp-sched-tests - pass: 10, skip: 4, * ltp-securebits-tests - pass: 4, * ltp-syscalls-tests - pass: 1013, skip: 136, * ltp-timers-tests - pass: 13, i386 * boot - pass: 22, * kselftest - pass: 75, skip: 45, fail: 12 * libhugetlbfs - pass: 1, * ltp-cap_bounds-tests - pass: 2, * ltp-containers-tests - pass: 80, skip: 1, * ltp-cve-tests - pass: 28, skip: 4, fail: 3 * ltp-fcntl-locktests-tests - pass: 2, * ltp-filecaps-tests - pass: 2, * ltp-fs-tests - pass: 59, skip: 6, * ltp-fs_bind-tests - pass: 2, * ltp-fs_perms_simple-tests - pass: 19, * ltp-fsx-tests - pass: 2, * ltp-hugetlb-tests - pass: 21, skip: 1, * ltp-io-tests - pass: 3, * ltp-ipc-tests - pass: 9, * ltp-math-tests - pass: 10, * ltp-nptl-tests - pass: 2, * ltp-open-posix-tests - pass: 1686, skip: 43, fail: 5 * ltp-pty-tests - pass: 4, * ltp-sched-tests - pass: 10, skip: 4, * ltp-securebits-tests - pass: 4, * ltp-syscalls-tests - pass: 1087, skip: 59, fail: 2 * ltp-timers-tests - pass: 13, juno-r2 - arm64 * boot - pass: 22, * kselftest - pass: 53, skip: 46, fail: 10 * libhugetlbfs - pass: 89, skip: 1, fail: 1 * ltp-cap_bounds-tests - pass: 2, * ltp-containers-tests - pass: 80, skip: 1, * ltp-filecaps-tests - pass: 2, * ltp-fs-tests - pass: 60, skip: 6, * ltp-fs_bind-tests - pass: 2, * ltp-hugetlb-tests - pass: 22, * ltp-ipc-tests - pass: 9, * ltp-math-tests - pass: 11, * ltp-nptl-tests - pass: 2, * ltp-open-posix-tests - pass: 1689, skip: 41, fail: 5 * ltp-pty-tests - pass: 4, * ltp-sched-tests - pass: 10, skip: 4, * ltp-securebits-tests - pass: 4, * ltp-syscalls-tests - pass: 1014, skip: 135, * ltp-timers-tests - pass: 13, qemu_arm * boot - pass: 21, * kselftest - pass: 48, skip: 54, fail: 6 * libhugetlbfs - pass: 86, skip: 1, fail: 1 * ltp-cap_bounds-tests - pass: 2, * ltp-containers-tests - pass: 79, skip: 2, * ltp-cve-tests - pass: 23, skip: 12, * ltp-fcntl-locktests-tests - pass: 2, * ltp-filecaps-tests - pass: 2, * ltp-fs-tests - pass: 61, skip: 5, * ltp-fs_bind-tests - pass: 2, * ltp-fs_perms_simple-tests - pass: 19, * ltp-fsx-tests - pass: 2, * ltp-hugetlb-tests - pass: 21, skip: 1, * ltp-io-tests - pass: 3, * ltp-ipc-tests - pass: 9, * ltp-math-tests - pass: 11, * ltp-nptl-tests - pass: 2, * ltp-pty-tests - pass: 4, * ltp-sched-tests - pass: 8, skip: 6, * ltp-securebits-tests - pass: 4, * ltp-syscalls-tests - pass: 1050, skip:
Re: [PATCH 4.18 000/145] 4.18.7-stable review
On 8 September 2018 at 02:37, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.18.7 release. > There are 145 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Sun Sep 9 21:08:26 UTC 2018. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.18.7-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-4.18.y > and the diffstat can be found below. > > thanks, > > greg k-h Results from Linaro’s test farm. No regressions on arm64, arm, x86_64 and i386. Summary kernel: 4.18.7-rc1 git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git git branch: linux-4.18.y git commit: 778167eee1b92f5bc2405840b2110af2f6bb9723 git describe: v4.18.5-270-g778167eee1b9 Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.18-oe/build/v4.18.5-270-g778167eee1b9 No regressions (compared to build v4.18.5-124-ga6a229cf7e7f) Boards, architectures and test suites: - dragonboard-410c - arm64 * boot - pass: 20, fail: 1 * kselftest - pass: 59, skip: 45, fail: 8 * libhugetlbfs - pass: 88, skip: 1, fail: 2 * ltp-cap_bounds-tests - pass: 2, * ltp-containers-tests - pass: 80, skip: 1, * ltp-cve-tests - pass: 26, skip: 9, * ltp-fcntl-locktests-tests - pass: 2, * ltp-fs-tests - pass: 60, skip: 6, * ltp-fs_bind-tests - pass: 2, * ltp-fs_perms_simple-tests - pass: 19, * ltp-fsx-tests - pass: 2, * ltp-hugetlb-tests - pass: 21, skip: 1, * ltp-io-tests - pass: 3, * ltp-ipc-tests - pass: 9, * ltp-math-tests - pass: 11, * ltp-nptl-tests - pass: 2, * ltp-pty-tests - pass: 4, * ltp-sched-tests - pass: 14, * ltp-securebits-tests - pass: 4, * ltp-syscalls-tests - pass: 1016, skip: 133, * ltp-timers-tests - pass: 13, hi6220-hikey - arm64 * boot - pass: 21, * kselftest - pass: 63, skip: 39, fail: 7 * libhugetlbfs - pass: 89, skip: 1, fail: 1 * ltp-cap_bounds-tests - pass: 2, * ltp-containers-tests - pass: 80, skip: 1, * ltp-cve-tests - pass: 27, skip: 8, * ltp-fcntl-locktests-tests - pass: 2, * ltp-filecaps-tests - pass: 2, * ltp-fs_bind-tests - pass: 2, * ltp-fs_perms_simple-tests - pass: 19, * ltp-fsx-tests - pass: 2, * ltp-hugetlb-tests - pass: 21, skip: 1, * ltp-io-tests - pass: 3, * ltp-ipc-tests - pass: 9, * ltp-math-tests - pass: 11, * ltp-nptl-tests - pass: 2, * ltp-pty-tests - pass: 4, * ltp-sched-tests - pass: 10, skip: 4, * ltp-securebits-tests - pass: 4, * ltp-syscalls-tests - pass: 1015, skip: 134, * ltp-timers-tests - pass: 13, i386 * boot - pass: 22, * kselftest - pass: 82, skip: 40, fail: 5 * libhugetlbfs - pass: 1, * ltp-cap_bounds-tests - pass: 2, * ltp-containers-tests - pass: 80, skip: 1, * ltp-cve-tests - pass: 27, skip: 4, fail: 4 * ltp-fcntl-locktests-tests - pass: 2, * ltp-filecaps-tests - pass: 2, * ltp-fs-tests - pass: 60, skip: 6, * ltp-fs_bind-tests - pass: 2, * ltp-fs_perms_simple-tests - pass: 18, * ltp-fsx-tests - pass: 2, * ltp-hugetlb-tests - pass: 21, skip: 1, * ltp-io-tests - pass: 3, * ltp-ipc-tests - pass: 8, * ltp-math-tests - pass: 11, * ltp-nptl-tests - pass: 2, * ltp-open-posix-tests - pass: 1688, skip: 40, fail: 5 * ltp-pty-tests - pass: 4, * ltp-sched-tests - pass: 10, skip: 4, * ltp-securebits-tests - pass: 4, * ltp-syscalls-tests - pass: 1087, skip: 59, fail: 2 * ltp-timers-tests - pass: 13, juno-r2 - arm64 * boot - pass: 22, * libhugetlbfs - pass: 89, skip: 1, fail: 1 * ltp-containers-tests - pass: 80, skip: 1, * ltp-cve-tests - pass: 26, skip: 9, * ltp-filecaps-tests - pass: 2, * ltp-fsx-tests - pass: 2, * ltp-hugetlb-tests - pass: 22, * ltp-io-tests - pass: 3, * ltp-math-tests - pass: 11, * ltp-open-posix-tests - pass: 1689, skip: 41, fail: 5 * ltp-pty-tests - pass: 4, * ltp-sched-tests - pass: 10, skip: 4, * ltp-securebits-tests - pass: 4, * ltp-timers-tests - pass: 13, qemu_arm * boot - pass: 21, * kselftest - pass: 50, skip: 53, fail: 5 * libhugetlbfs - pass: 86, skip: 1, fail: 1 * ltp-cap_bounds-tests - pass: 2, * ltp-containers-tests - pass: 79, skip: 2, * ltp-cve-tests - pass: 23, skip: 12, * ltp-fcntl-locktests-tests - pass: 2, * ltp-filecaps-tests - pass: 2, * ltp-fs-tests - pass: 61, skip: 5, * ltp-fs_bind-tests - pass: 2, * ltp-fs_perms_simple-tests - pass: 19, * ltp-fsx-tests - pass: 2, * ltp-hugetlb-tests - pass: 21, skip: 1, * ltp-io-tests - pass: 3, * ltp-ipc-tests - pass: 9, * ltp-nptl-tests - pass: 2, * ltp-pty-tests - pass: 4, * ltp-sched-tests - pass: 8, skip: 6, * ltp-securebits-tests - pass: 4, * ltp-syscalls-tests - pass: 1050, skip: 99, * ltp-timers-tests - pass: 13, qemu_arm64 * boot - pass: 21, * kselftest - pass: 57, skip: 47, fail: 8 *
Re: [PATCH 4.18 000/145] 4.18.7-stable review
On 8 September 2018 at 02:37, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.18.7 release. > There are 145 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Sun Sep 9 21:08:26 UTC 2018. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.18.7-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-4.18.y > and the diffstat can be found below. > > thanks, > > greg k-h Results from Linaro’s test farm. No regressions on arm64, arm, x86_64 and i386. Summary kernel: 4.18.7-rc1 git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git git branch: linux-4.18.y git commit: 778167eee1b92f5bc2405840b2110af2f6bb9723 git describe: v4.18.5-270-g778167eee1b9 Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.18-oe/build/v4.18.5-270-g778167eee1b9 No regressions (compared to build v4.18.5-124-ga6a229cf7e7f) Boards, architectures and test suites: - dragonboard-410c - arm64 * boot - pass: 20, fail: 1 * kselftest - pass: 59, skip: 45, fail: 8 * libhugetlbfs - pass: 88, skip: 1, fail: 2 * ltp-cap_bounds-tests - pass: 2, * ltp-containers-tests - pass: 80, skip: 1, * ltp-cve-tests - pass: 26, skip: 9, * ltp-fcntl-locktests-tests - pass: 2, * ltp-fs-tests - pass: 60, skip: 6, * ltp-fs_bind-tests - pass: 2, * ltp-fs_perms_simple-tests - pass: 19, * ltp-fsx-tests - pass: 2, * ltp-hugetlb-tests - pass: 21, skip: 1, * ltp-io-tests - pass: 3, * ltp-ipc-tests - pass: 9, * ltp-math-tests - pass: 11, * ltp-nptl-tests - pass: 2, * ltp-pty-tests - pass: 4, * ltp-sched-tests - pass: 14, * ltp-securebits-tests - pass: 4, * ltp-syscalls-tests - pass: 1016, skip: 133, * ltp-timers-tests - pass: 13, hi6220-hikey - arm64 * boot - pass: 21, * kselftest - pass: 63, skip: 39, fail: 7 * libhugetlbfs - pass: 89, skip: 1, fail: 1 * ltp-cap_bounds-tests - pass: 2, * ltp-containers-tests - pass: 80, skip: 1, * ltp-cve-tests - pass: 27, skip: 8, * ltp-fcntl-locktests-tests - pass: 2, * ltp-filecaps-tests - pass: 2, * ltp-fs_bind-tests - pass: 2, * ltp-fs_perms_simple-tests - pass: 19, * ltp-fsx-tests - pass: 2, * ltp-hugetlb-tests - pass: 21, skip: 1, * ltp-io-tests - pass: 3, * ltp-ipc-tests - pass: 9, * ltp-math-tests - pass: 11, * ltp-nptl-tests - pass: 2, * ltp-pty-tests - pass: 4, * ltp-sched-tests - pass: 10, skip: 4, * ltp-securebits-tests - pass: 4, * ltp-syscalls-tests - pass: 1015, skip: 134, * ltp-timers-tests - pass: 13, i386 * boot - pass: 22, * kselftest - pass: 82, skip: 40, fail: 5 * libhugetlbfs - pass: 1, * ltp-cap_bounds-tests - pass: 2, * ltp-containers-tests - pass: 80, skip: 1, * ltp-cve-tests - pass: 27, skip: 4, fail: 4 * ltp-fcntl-locktests-tests - pass: 2, * ltp-filecaps-tests - pass: 2, * ltp-fs-tests - pass: 60, skip: 6, * ltp-fs_bind-tests - pass: 2, * ltp-fs_perms_simple-tests - pass: 18, * ltp-fsx-tests - pass: 2, * ltp-hugetlb-tests - pass: 21, skip: 1, * ltp-io-tests - pass: 3, * ltp-ipc-tests - pass: 8, * ltp-math-tests - pass: 11, * ltp-nptl-tests - pass: 2, * ltp-open-posix-tests - pass: 1688, skip: 40, fail: 5 * ltp-pty-tests - pass: 4, * ltp-sched-tests - pass: 10, skip: 4, * ltp-securebits-tests - pass: 4, * ltp-syscalls-tests - pass: 1087, skip: 59, fail: 2 * ltp-timers-tests - pass: 13, juno-r2 - arm64 * boot - pass: 22, * libhugetlbfs - pass: 89, skip: 1, fail: 1 * ltp-containers-tests - pass: 80, skip: 1, * ltp-cve-tests - pass: 26, skip: 9, * ltp-filecaps-tests - pass: 2, * ltp-fsx-tests - pass: 2, * ltp-hugetlb-tests - pass: 22, * ltp-io-tests - pass: 3, * ltp-math-tests - pass: 11, * ltp-open-posix-tests - pass: 1689, skip: 41, fail: 5 * ltp-pty-tests - pass: 4, * ltp-sched-tests - pass: 10, skip: 4, * ltp-securebits-tests - pass: 4, * ltp-timers-tests - pass: 13, qemu_arm * boot - pass: 21, * kselftest - pass: 50, skip: 53, fail: 5 * libhugetlbfs - pass: 86, skip: 1, fail: 1 * ltp-cap_bounds-tests - pass: 2, * ltp-containers-tests - pass: 79, skip: 2, * ltp-cve-tests - pass: 23, skip: 12, * ltp-fcntl-locktests-tests - pass: 2, * ltp-filecaps-tests - pass: 2, * ltp-fs-tests - pass: 61, skip: 5, * ltp-fs_bind-tests - pass: 2, * ltp-fs_perms_simple-tests - pass: 19, * ltp-fsx-tests - pass: 2, * ltp-hugetlb-tests - pass: 21, skip: 1, * ltp-io-tests - pass: 3, * ltp-ipc-tests - pass: 9, * ltp-nptl-tests - pass: 2, * ltp-pty-tests - pass: 4, * ltp-sched-tests - pass: 8, skip: 6, * ltp-securebits-tests - pass: 4, * ltp-syscalls-tests - pass: 1050, skip: 99, * ltp-timers-tests - pass: 13, qemu_arm64 * boot - pass: 21, * kselftest - pass: 57, skip: 47, fail: 8 *
Re: [PATCH 03/11] compat_ioctl: remove translation for sound ioctls
On Sat, Sep 08, 2018 at 04:28:09PM +0200, Arnd Bergmann wrote:
> The SNDCTL_* and SOUND_* commands are the old OSS user interface.
>
> I checked all the sound ioctl commands listed in fs/compat_ioctl.c
> to see if we still need the translation handlers. Here is what I
> found:
>
> - sound/oss/ is (almost) gone from the kernel, this is what actually
> needed all the translations
> - The ALSA emulation for OSS correctly handles all compat_ioctl
> commands already.
> - sound/oss/dmasound/ is the last holdout of the original OSS code,
> this is only used on arch/m68k, which has no 64-bit mode and
> hence needs no compat handlers
> - arch/um/drivers/hostaudio_kern.c may run in 64-bit mode with
> 32-bit x86 user space underneath it. This rare corner case is
> the only one that still needs the compat handlers.
>
> By adding a simple redirect of .compat_ioctl to .unlocked_ioctl in the
> UML driver, we can remove all the COMPATIBLE_IOCTL() annotations without
> a change in functionality. For completeness, I'm adding the same thing
> to the dmasound file, knowing that it makes no difference.
> diff --git a/arch/um/drivers/hostaudio_kern.c
> b/arch/um/drivers/hostaudio_kern.c
> index 7f9dbdbc4eb7..0278a642a622 100644
> --- a/arch/um/drivers/hostaudio_kern.c
> +++ b/arch/um/drivers/hostaudio_kern.c
> @@ -298,6 +298,7 @@ static const struct file_operations hostaudio_fops = {
> .write = hostaudio_write,
> .poll = hostaudio_poll,
> .unlocked_ioctl = hostaudio_ioctl,
> + .compat_ioctl = hostaudio_ioctl,
Umm... OK, seeing that it's not going to be used on s390... It's still
not quite right, though, and I'm afraid that places where we have the
same ->unlocked_ioctl and ->compat_ioctl need an audit - there probably
had been other folks who'd stepped into the same.
Re: [PATCH 03/11] compat_ioctl: remove translation for sound ioctls
On Sat, Sep 08, 2018 at 04:28:09PM +0200, Arnd Bergmann wrote:
> The SNDCTL_* and SOUND_* commands are the old OSS user interface.
>
> I checked all the sound ioctl commands listed in fs/compat_ioctl.c
> to see if we still need the translation handlers. Here is what I
> found:
>
> - sound/oss/ is (almost) gone from the kernel, this is what actually
> needed all the translations
> - The ALSA emulation for OSS correctly handles all compat_ioctl
> commands already.
> - sound/oss/dmasound/ is the last holdout of the original OSS code,
> this is only used on arch/m68k, which has no 64-bit mode and
> hence needs no compat handlers
> - arch/um/drivers/hostaudio_kern.c may run in 64-bit mode with
> 32-bit x86 user space underneath it. This rare corner case is
> the only one that still needs the compat handlers.
>
> By adding a simple redirect of .compat_ioctl to .unlocked_ioctl in the
> UML driver, we can remove all the COMPATIBLE_IOCTL() annotations without
> a change in functionality. For completeness, I'm adding the same thing
> to the dmasound file, knowing that it makes no difference.
> diff --git a/arch/um/drivers/hostaudio_kern.c
> b/arch/um/drivers/hostaudio_kern.c
> index 7f9dbdbc4eb7..0278a642a622 100644
> --- a/arch/um/drivers/hostaudio_kern.c
> +++ b/arch/um/drivers/hostaudio_kern.c
> @@ -298,6 +298,7 @@ static const struct file_operations hostaudio_fops = {
> .write = hostaudio_write,
> .poll = hostaudio_poll,
> .unlocked_ioctl = hostaudio_ioctl,
> + .compat_ioctl = hostaudio_ioctl,
Umm... OK, seeing that it's not going to be used on s390... It's still
not quite right, though, and I'm afraid that places where we have the
same ->unlocked_ioctl and ->compat_ioctl need an audit - there probably
had been other folks who'd stepped into the same.
Re: [PATCH 06/11] compat_ioctl: remove /dev/random commands
On Sat, Sep 08, 2018 at 04:28:12PM +0200, Arnd Bergmann wrote:
> These are all handled by the random driver, so instead of listing
> each ioctl, we can just use the same function to deal with both
> native and compat commands.
Umm... I don't think it's right -
> .unlocked_ioctl = random_ioctl,
> + .compat_ioctl = random_ioctl,
->compat_ioctl() gets called in
error = f.file->f_op->compat_ioctl(f.file, cmd, arg);
so you do *NOT* get compat_ptr() for those - they have to do it on their
own. It's not hard to provide a proper compat_ioctl() instance for that
one, but this is not it. What you need in drivers/char/random.c part of
that one is something like
diff --git a/drivers/char/random.c b/drivers/char/random.c
index bf5f99fc36f1..1de75c784cf6 100644
--- a/drivers/char/random.c
+++ b/drivers/char/random.c
@@ -1954,10 +1954,9 @@ static ssize_t random_write(struct file *file, const
char __user *buffer,
return (ssize_t)count;
}
-static long random_ioctl(struct file *f, unsigned int cmd, unsigned long arg)
+static long __random_ioctl(struct file *f, unsigned int cmd, int __user *p)
{
int size, ent_count;
- int __user *p = (int __user *)arg;
int retval;
switch (cmd) {
@@ -2011,6 +2010,18 @@ static long random_ioctl(struct file *f, unsigned int
cmd, unsigned long arg)
}
}
+static long random_ioctl(struct file *f, unsigned int cmd, unsigned long arg)
+{
+ return __random_ioctl(f, cmd, (int __user *)arg);
+}
+
+#ifdef CONFIG_COMPAT
+static long compat_random_ioctl(struct file *f, unsigned int cmd, unsigned
long arg)
+{
+ return __random_ioctl(f, cmd, compat_ptr(arg));
+}
+#endif
+
static int random_fasync(int fd, struct file *filp, int on)
{
return fasync_helper(fd, filp, on, );
@@ -2021,6 +2032,9 @@ const struct file_operations random_fops = {
.write = random_write,
.poll = random_poll,
.unlocked_ioctl = random_ioctl,
+#ifdef CONFIG_COMPAT
+ .compat_ioctl = compat_random_ioctl,
+#endif
.fasync = random_fasync,
.llseek = noop_llseek,
};
Re: [PATCH 06/11] compat_ioctl: remove /dev/random commands
On Sat, Sep 08, 2018 at 04:28:12PM +0200, Arnd Bergmann wrote:
> These are all handled by the random driver, so instead of listing
> each ioctl, we can just use the same function to deal with both
> native and compat commands.
Umm... I don't think it's right -
> .unlocked_ioctl = random_ioctl,
> + .compat_ioctl = random_ioctl,
->compat_ioctl() gets called in
error = f.file->f_op->compat_ioctl(f.file, cmd, arg);
so you do *NOT* get compat_ptr() for those - they have to do it on their
own. It's not hard to provide a proper compat_ioctl() instance for that
one, but this is not it. What you need in drivers/char/random.c part of
that one is something like
diff --git a/drivers/char/random.c b/drivers/char/random.c
index bf5f99fc36f1..1de75c784cf6 100644
--- a/drivers/char/random.c
+++ b/drivers/char/random.c
@@ -1954,10 +1954,9 @@ static ssize_t random_write(struct file *file, const
char __user *buffer,
return (ssize_t)count;
}
-static long random_ioctl(struct file *f, unsigned int cmd, unsigned long arg)
+static long __random_ioctl(struct file *f, unsigned int cmd, int __user *p)
{
int size, ent_count;
- int __user *p = (int __user *)arg;
int retval;
switch (cmd) {
@@ -2011,6 +2010,18 @@ static long random_ioctl(struct file *f, unsigned int
cmd, unsigned long arg)
}
}
+static long random_ioctl(struct file *f, unsigned int cmd, unsigned long arg)
+{
+ return __random_ioctl(f, cmd, (int __user *)arg);
+}
+
+#ifdef CONFIG_COMPAT
+static long compat_random_ioctl(struct file *f, unsigned int cmd, unsigned
long arg)
+{
+ return __random_ioctl(f, cmd, compat_ptr(arg));
+}
+#endif
+
static int random_fasync(int fd, struct file *filp, int on)
{
return fasync_helper(fd, filp, on, );
@@ -2021,6 +2032,9 @@ const struct file_operations random_fops = {
.write = random_write,
.poll = random_poll,
.unlocked_ioctl = random_ioctl,
+#ifdef CONFIG_COMPAT
+ .compat_ioctl = compat_random_ioctl,
+#endif
.fasync = random_fasync,
.llseek = noop_llseek,
};
Re: [PATCH 4.18 000/123] 4.18.6-stable review
On 09/05/2018 10:01 AM, Linus Torvalds wrote: On Wed, Sep 5, 2018 at 8:34 AM Guenter Roeck wrote: On 09/05/2018 02:01 AM, Greg Kroah-Hartman wrote: --- [ 9990.754641] watchdog: BUG: soft lockup - CPU#5 stuck for 22s! [kworker/5:1:155] [ 9990.762601] RIP: 0010:smp_call_function_many+0x208/0x270 [ 9990.762601] Code: e8 0d d1 77 00 3b 05 cb f0 24 01 0f 83 86 fe ff ff 48 63 d0 49 8b 0c 24 48 03 0c d5 00 f7 11 a7 8b 51 18 83 e2 01 74 0a f3 90 <8b> 51 18 83 e2 01 75 f6 eb c7 0f b6 4d d0 4c 89 f2 4c 89 ee 44 89 It's stuck in this loop: loop: pause mov0x18(%rcx),%edx and$0x1,%edx jneloop which is csd_lock_wait(). Judging by the offset in smp_call_function_many(), it's the final one (there's two: the other one is part of "csd_lock()"). But that's just a guess. Anyway, it means that we're waiting for another CPU to finish processing an IPI - either a previous one we sent asynchronously (if it's the earlier csd_lock() case) or the TLB IPI we just sent and we're waiting for completion of. Not tested, but I see it in v4.17.19 and in v4.18.6-rc2. Turns out it is related to heavy load, not to suspend/resume. At this point I suspect that it may be an AMD/Ryzen specific problem - it looks like it disappears if I add "kernel.randomize_va_space = 0" to /etc/sysctl.conf. No idea if it is a CPU bug or some AMD specific code problem. I'll try to analyze it further. Ouch. Some IPI sending/receiving problem would be very very painful to debug if it's hw related. Turns out this is a well known problem with Ryzen CPUs: https://bugzilla.kernel.org/show_bug.cgi?id=196683 Guenter
Re: [PATCH 4.18 000/123] 4.18.6-stable review
On 09/05/2018 10:01 AM, Linus Torvalds wrote: On Wed, Sep 5, 2018 at 8:34 AM Guenter Roeck wrote: On 09/05/2018 02:01 AM, Greg Kroah-Hartman wrote: --- [ 9990.754641] watchdog: BUG: soft lockup - CPU#5 stuck for 22s! [kworker/5:1:155] [ 9990.762601] RIP: 0010:smp_call_function_many+0x208/0x270 [ 9990.762601] Code: e8 0d d1 77 00 3b 05 cb f0 24 01 0f 83 86 fe ff ff 48 63 d0 49 8b 0c 24 48 03 0c d5 00 f7 11 a7 8b 51 18 83 e2 01 74 0a f3 90 <8b> 51 18 83 e2 01 75 f6 eb c7 0f b6 4d d0 4c 89 f2 4c 89 ee 44 89 It's stuck in this loop: loop: pause mov0x18(%rcx),%edx and$0x1,%edx jneloop which is csd_lock_wait(). Judging by the offset in smp_call_function_many(), it's the final one (there's two: the other one is part of "csd_lock()"). But that's just a guess. Anyway, it means that we're waiting for another CPU to finish processing an IPI - either a previous one we sent asynchronously (if it's the earlier csd_lock() case) or the TLB IPI we just sent and we're waiting for completion of. Not tested, but I see it in v4.17.19 and in v4.18.6-rc2. Turns out it is related to heavy load, not to suspend/resume. At this point I suspect that it may be an AMD/Ryzen specific problem - it looks like it disappears if I add "kernel.randomize_va_space = 0" to /etc/sysctl.conf. No idea if it is a CPU bug or some AMD specific code problem. I'll try to analyze it further. Ouch. Some IPI sending/receiving problem would be very very painful to debug if it's hw related. Turns out this is a well known problem with Ryzen CPUs: https://bugzilla.kernel.org/show_bug.cgi?id=196683 Guenter
Re: [PATCH 4.4 34/47] userns: move user access out of the mutex
Greg,
On Fri, Sep 7, 2018 at 6:41 PM Greg Kroah-Hartman
wrote:
>
> 4.4-stable review patch. If anyone has any objections, please let me know.
>
> --
>
> From: Jann Horn
>
> commit 5820f140edef111a9ea2ef414ab2428b8cb805b1 upstream.
>
> The old code would hold the userns_state_mutex indefinitely if
> memdup_user_nul stalled due to e.g. a userfault region. Prevent that by
> moving the memdup_user_nul in front of the mutex_lock().
>
> Note: This changes the error precedence of invalid buf/count/*ppos vs
> map already written / capabilities missing.
>
> Fixes: 22d917d80e84 ("userns: Rework the user_namespace adding uid/gid...")
> Cc: sta...@vger.kernel.org
> Signed-off-by: Jann Horn
> Acked-by: Christian Brauner
> Acked-by: Serge Hallyn
> Signed-off-by: Eric W. Biederman
> Signed-off-by: Greg Kroah-Hartman
>
> ---
> kernel/user_namespace.c | 22 ++
> 1 file changed, 10 insertions(+), 12 deletions(-)
>
> --- a/kernel/user_namespace.c
> +++ b/kernel/user_namespace.c
> @@ -604,7 +604,16 @@ static ssize_t map_write(struct file *fi
> struct uid_gid_extent *extent = NULL;
> unsigned long page = 0;
> char *kbuf, *pos, *next_line;
> - ssize_t ret = -EINVAL;
> + ssize_t ret;
> +
> + /* Only allow < page size writes at the beginning of the file */
> + if ((*ppos != 0) || (count >= PAGE_SIZE))
> + return -EINVAL;
> +
> + /* Slurp in the user data */
> + if (copy_from_user(kbuf, buf, count))
> + return -EFAULT;
> + kbuf[count] = '\0';
Naresh will soon report issues found by LKFT on user_ns for 4.4 kernel
for this review round.
selftests: mount_run_tests.sh [FAIL]
write to /proc/self/uid_map failed: Bad address
LTP: user_namespace2 1 TBROK : safe_macros.c:452: userns02.c:95:
write(6,0x7ffc133113d0,18446744073709551615) failed: errno=EFAULT(14):
Bad address
I believe the EFAULT was caused because when changing code from
"memdup_user_nul" to "copy_from_user", for the older kernels, you
missed allocating the slab object for "kbuf", like memdup_user_nul()
does.
Note: This likely applies to 3.18 as well.
We are finishing functional tests without this patch, but we wanted to
make you aware right away.
Best Regards,
Rafael
Re: [PATCH 4.4 34/47] userns: move user access out of the mutex
Greg,
On Fri, Sep 7, 2018 at 6:41 PM Greg Kroah-Hartman
wrote:
>
> 4.4-stable review patch. If anyone has any objections, please let me know.
>
> --
>
> From: Jann Horn
>
> commit 5820f140edef111a9ea2ef414ab2428b8cb805b1 upstream.
>
> The old code would hold the userns_state_mutex indefinitely if
> memdup_user_nul stalled due to e.g. a userfault region. Prevent that by
> moving the memdup_user_nul in front of the mutex_lock().
>
> Note: This changes the error precedence of invalid buf/count/*ppos vs
> map already written / capabilities missing.
>
> Fixes: 22d917d80e84 ("userns: Rework the user_namespace adding uid/gid...")
> Cc: sta...@vger.kernel.org
> Signed-off-by: Jann Horn
> Acked-by: Christian Brauner
> Acked-by: Serge Hallyn
> Signed-off-by: Eric W. Biederman
> Signed-off-by: Greg Kroah-Hartman
>
> ---
> kernel/user_namespace.c | 22 ++
> 1 file changed, 10 insertions(+), 12 deletions(-)
>
> --- a/kernel/user_namespace.c
> +++ b/kernel/user_namespace.c
> @@ -604,7 +604,16 @@ static ssize_t map_write(struct file *fi
> struct uid_gid_extent *extent = NULL;
> unsigned long page = 0;
> char *kbuf, *pos, *next_line;
> - ssize_t ret = -EINVAL;
> + ssize_t ret;
> +
> + /* Only allow < page size writes at the beginning of the file */
> + if ((*ppos != 0) || (count >= PAGE_SIZE))
> + return -EINVAL;
> +
> + /* Slurp in the user data */
> + if (copy_from_user(kbuf, buf, count))
> + return -EFAULT;
> + kbuf[count] = '\0';
Naresh will soon report issues found by LKFT on user_ns for 4.4 kernel
for this review round.
selftests: mount_run_tests.sh [FAIL]
write to /proc/self/uid_map failed: Bad address
LTP: user_namespace2 1 TBROK : safe_macros.c:452: userns02.c:95:
write(6,0x7ffc133113d0,18446744073709551615) failed: errno=EFAULT(14):
Bad address
I believe the EFAULT was caused because when changing code from
"memdup_user_nul" to "copy_from_user", for the older kernels, you
missed allocating the slab object for "kbuf", like memdup_user_nul()
does.
Note: This likely applies to 3.18 as well.
We are finishing functional tests without this patch, but we wanted to
make you aware right away.
Best Regards,
Rafael
Re: [PATCH v4 08/16] sched/core: uclamp: propagate parent clamps
On Tue, Aug 28, 2018 at 6:53 AM, Patrick Bellasi
wrote:
> In order to properly support hierarchical resources control, the cgroup
> delegation model requires that attribute writes from a child group never
> fail but still are (potentially) constrained based on parent's assigned
> resources. This requires to properly propagate and aggregate parent
> attributes down to its descendants.
>
> Let's implement this mechanism by adding a new "effective" clamp value
> for each task group. The effective clamp value is defined as the smaller
> value between the clamp value of a group and the effective clamp value
> of its parent. This represent also the clamp value which is actually
> used to clamp tasks in each task group.
>
> Since it can be interesting for tasks in a cgroup to know exactly what
> is the currently propagated/enforced configuration, the effective clamp
> values are exposed to user-space by means of a new pair of read-only
> attributes: cpu.util.{min,max}.effective.
>
> Signed-off-by: Patrick Bellasi
> Cc: Ingo Molnar
> Cc: Peter Zijlstra
> Cc: Tejun Heo
> Cc: Rafael J. Wysocki
> Cc: Viresh Kumar
> Cc: Suren Baghdasaryan
> Cc: Todd Kjos
> Cc: Joel Fernandes
> Cc: Juri Lelli
> Cc: Quentin Perret
> Cc: Dietmar Eggemann
> Cc: Morten Rasmussen
> Cc: linux-kernel@vger.kernel.org
> Cc: linux...@vger.kernel.org
>
> ---
> Changes in v4:
> Message-ID: <20180816140731.GD2960@e110439-lin>
> - add ".effective" attributes to the default hierarchy
> Others:
> - small documentation fixes
> - rebased on v4.19-rc1
>
> Changes in v3:
> Message-ID: <20180409222417.gk3126...@devbig577.frc2.facebook.com>
> - new patch in v3, to implement a suggestion from v1 review
> ---
> Documentation/admin-guide/cgroup-v2.rst | 25 +-
> include/linux/sched.h | 8 ++
> kernel/sched/core.c | 112 +++-
> 3 files changed, 139 insertions(+), 6 deletions(-)
>
> diff --git a/Documentation/admin-guide/cgroup-v2.rst
> b/Documentation/admin-guide/cgroup-v2.rst
> index 80ef7bdc517b..72272f58d304 100644
> --- a/Documentation/admin-guide/cgroup-v2.rst
> +++ b/Documentation/admin-guide/cgroup-v2.rst
> @@ -976,22 +976,43 @@ All time durations are in microseconds.
> A read-write single value file which exists on non-root cgroups.
> The default is "0", i.e. no bandwidth boosting.
>
> -The minimum utilization in the range [0, 1023].
> +The requested minimum utilization in the range [0, 1023].
>
> This interface allows reading and setting minimum utilization clamp
> values similar to the sched_setattr(2). This minimum utilization
> value is used to clamp the task specific minimum utilization clamp.
>
> + cpu.util.min.effective
> +A read-only single value file which exists on non-root cgroups and
> +reports minimum utilization clamp value currently enforced on a task
> +group.
> +
> +The actual minimum utilization in the range [0, 1023].
> +
> +This value can be lower then cpu.util.min in case a parent cgroup
> +is enforcing a more restrictive clamping on minimum utilization.
IMHO if cpu.util.min=0 means "no restrictions" on UCLAMP_MIN then
calling parent's lower cpu.util.min value "more restrictive clamping"
is confusing. I would suggest to rephrase this to smth like "...in
case a parent cgroup requires lower cpu.util.min clamping."
> +
>cpu.util.max
> A read-write single value file which exists on non-root cgroups.
> The default is "1023". i.e. no bandwidth clamping
>
> -The maximum utilization in the range [0, 1023].
> +The requested maximum utilization in the range [0, 1023].
>
> This interface allows reading and setting maximum utilization clamp
> values similar to the sched_setattr(2). This maximum utilization
> value is used to clamp the task specific maximum utilization clamp.
>
> + cpu.util.max.effective
> +A read-only single value file which exists on non-root cgroups and
> +reports maximum utilization clamp value currently enforced on a task
> +group.
> +
> +The actual maximum utilization in the range [0, 1023].
> +
> +This value can be lower then cpu.util.max in case a parent cgroup
> +is enforcing a more restrictive clamping on max utilization.
> +
> +
> Memory
> --
>
> diff --git a/include/linux/sched.h b/include/linux/sched.h
> index dc39b67a366a..2da130d17e70 100644
> --- a/include/linux/sched.h
> +++ b/include/linux/sched.h
> @@ -591,6 +591,14 @@ struct sched_dl_entity {
> struct uclamp_se {
> unsigned int value;
> unsigned int group_id;
> + /*
> +* Effective task (group) clamp value.
> +* For task groups is the value (eventually) enforced by a parent task
> +* group.
> +*/
> + struct {
> + unsigned int value;
> + } effective;
> };
>
> union
Re: [PATCH v4 08/16] sched/core: uclamp: propagate parent clamps
On Tue, Aug 28, 2018 at 6:53 AM, Patrick Bellasi
wrote:
> In order to properly support hierarchical resources control, the cgroup
> delegation model requires that attribute writes from a child group never
> fail but still are (potentially) constrained based on parent's assigned
> resources. This requires to properly propagate and aggregate parent
> attributes down to its descendants.
>
> Let's implement this mechanism by adding a new "effective" clamp value
> for each task group. The effective clamp value is defined as the smaller
> value between the clamp value of a group and the effective clamp value
> of its parent. This represent also the clamp value which is actually
> used to clamp tasks in each task group.
>
> Since it can be interesting for tasks in a cgroup to know exactly what
> is the currently propagated/enforced configuration, the effective clamp
> values are exposed to user-space by means of a new pair of read-only
> attributes: cpu.util.{min,max}.effective.
>
> Signed-off-by: Patrick Bellasi
> Cc: Ingo Molnar
> Cc: Peter Zijlstra
> Cc: Tejun Heo
> Cc: Rafael J. Wysocki
> Cc: Viresh Kumar
> Cc: Suren Baghdasaryan
> Cc: Todd Kjos
> Cc: Joel Fernandes
> Cc: Juri Lelli
> Cc: Quentin Perret
> Cc: Dietmar Eggemann
> Cc: Morten Rasmussen
> Cc: linux-kernel@vger.kernel.org
> Cc: linux...@vger.kernel.org
>
> ---
> Changes in v4:
> Message-ID: <20180816140731.GD2960@e110439-lin>
> - add ".effective" attributes to the default hierarchy
> Others:
> - small documentation fixes
> - rebased on v4.19-rc1
>
> Changes in v3:
> Message-ID: <20180409222417.gk3126...@devbig577.frc2.facebook.com>
> - new patch in v3, to implement a suggestion from v1 review
> ---
> Documentation/admin-guide/cgroup-v2.rst | 25 +-
> include/linux/sched.h | 8 ++
> kernel/sched/core.c | 112 +++-
> 3 files changed, 139 insertions(+), 6 deletions(-)
>
> diff --git a/Documentation/admin-guide/cgroup-v2.rst
> b/Documentation/admin-guide/cgroup-v2.rst
> index 80ef7bdc517b..72272f58d304 100644
> --- a/Documentation/admin-guide/cgroup-v2.rst
> +++ b/Documentation/admin-guide/cgroup-v2.rst
> @@ -976,22 +976,43 @@ All time durations are in microseconds.
> A read-write single value file which exists on non-root cgroups.
> The default is "0", i.e. no bandwidth boosting.
>
> -The minimum utilization in the range [0, 1023].
> +The requested minimum utilization in the range [0, 1023].
>
> This interface allows reading and setting minimum utilization clamp
> values similar to the sched_setattr(2). This minimum utilization
> value is used to clamp the task specific minimum utilization clamp.
>
> + cpu.util.min.effective
> +A read-only single value file which exists on non-root cgroups and
> +reports minimum utilization clamp value currently enforced on a task
> +group.
> +
> +The actual minimum utilization in the range [0, 1023].
> +
> +This value can be lower then cpu.util.min in case a parent cgroup
> +is enforcing a more restrictive clamping on minimum utilization.
IMHO if cpu.util.min=0 means "no restrictions" on UCLAMP_MIN then
calling parent's lower cpu.util.min value "more restrictive clamping"
is confusing. I would suggest to rephrase this to smth like "...in
case a parent cgroup requires lower cpu.util.min clamping."
> +
>cpu.util.max
> A read-write single value file which exists on non-root cgroups.
> The default is "1023". i.e. no bandwidth clamping
>
> -The maximum utilization in the range [0, 1023].
> +The requested maximum utilization in the range [0, 1023].
>
> This interface allows reading and setting maximum utilization clamp
> values similar to the sched_setattr(2). This maximum utilization
> value is used to clamp the task specific maximum utilization clamp.
>
> + cpu.util.max.effective
> +A read-only single value file which exists on non-root cgroups and
> +reports maximum utilization clamp value currently enforced on a task
> +group.
> +
> +The actual maximum utilization in the range [0, 1023].
> +
> +This value can be lower then cpu.util.max in case a parent cgroup
> +is enforcing a more restrictive clamping on max utilization.
> +
> +
> Memory
> --
>
> diff --git a/include/linux/sched.h b/include/linux/sched.h
> index dc39b67a366a..2da130d17e70 100644
> --- a/include/linux/sched.h
> +++ b/include/linux/sched.h
> @@ -591,6 +591,14 @@ struct sched_dl_entity {
> struct uclamp_se {
> unsigned int value;
> unsigned int group_id;
> + /*
> +* Effective task (group) clamp value.
> +* For task groups is the value (eventually) enforced by a parent task
> +* group.
> +*/
> + struct {
> + unsigned int value;
> + } effective;
> };
>
> union
Re: [PATCH] ARM: dts: imx6ull: update iomux header
On Thu, Aug 30, 2018 at 01:20:05PM +0800, Anson Huang wrote: > Update i.MX6ULL iomux header according to latest reference > manual Rev.1, 11/2017. > > Signed-off-by: Anson Huang Applied, thanks.
Re: [PATCH] ARM: dts: imx6ull: update iomux header
On Thu, Aug 30, 2018 at 01:20:05PM +0800, Anson Huang wrote: > Update i.MX6ULL iomux header according to latest reference > manual Rev.1, 11/2017. > > Signed-off-by: Anson Huang Applied, thanks.
Re: [PATCH v9 3/6] kernel/reboot.c: export pm_power_off_prepare
On Thu, Sep 06, 2018 at 11:15:17AM +0100, Mark Brown wrote: > On Mon, Aug 27, 2018 at 09:48:16AM +0800, Shawn Guo wrote: > > > Can you ACK on those two regulator patches, so that I can queue this > > series up on IMX tree? > > I was expecting to get a pull request with the precursor patches in it - > the regulator driver seems to get a moderate amount of development so > there's a reasonable risk of conflicts. What about you create a stable topic branch for regulator patches and I pull it into IMX tree? Shawn
Re: [PATCH v9 3/6] kernel/reboot.c: export pm_power_off_prepare
On Thu, Sep 06, 2018 at 11:15:17AM +0100, Mark Brown wrote: > On Mon, Aug 27, 2018 at 09:48:16AM +0800, Shawn Guo wrote: > > > Can you ACK on those two regulator patches, so that I can queue this > > series up on IMX tree? > > I was expecting to get a pull request with the precursor patches in it - > the regulator driver seems to get a moderate amount of development so > there's a reasonable risk of conflicts. What about you create a stable topic branch for regulator patches and I pull it into IMX tree? Shawn
Re: general protection fault in ovl_free_fs
syzbot has found a reproducer for the following crash on: HEAD commit:d7b686ebf704 Merge branch 'i2c/for-current' of git://git.k.. git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=148ac14940 kernel config: https://syzkaller.appspot.com/x/.config?x=8f59875069d721b6 dashboard link: https://syzkaller.appspot.com/bug?extid=c75f181dc8429d2eb887 compiler: gcc (GCC) 8.0.1 20180413 (experimental) syz repro: https://syzkaller.appspot.com/x/repro.syz?x=11553b7a40 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=14b1642140 IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+c75f181dc8429d2eb...@syzkaller.appspotmail.com R10: R11: 0246 R12: R13: 0003 R14: R15: overlayfs: failed to clone upperpath kasan: CONFIG_KASAN_INLINE enabled kasan: GPF could be caused by NULL-ptr deref or user memory access general protection fault: [#1] PREEMPT SMP KASAN CPU: 1 PID: 5473 Comm: syz-executor554 Not tainted 4.19.0-rc2+ #7 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:ovl_free_fs+0x504/0x690 fs/overlayfs/super.c:226 Code: 00 00 00 00 00 fc ff df 48 c1 ea 03 80 3c 02 00 0f 85 78 01 00 00 48 b8 00 00 00 00 00 fc ff df 4c 8b 23 4c 89 e2 48 c1 ea 03 <80> 3c 02 00 0f 85 67 01 00 00 49 8b 3c 24 e8 c9 0a 01 00 e9 0c fc RSP: 0018:8801b3de7798 EFLAGS: 00010246 RAX: dc00 RBX: 8801d87b7800 RCX: 828cacaf RDX: RSI: 828cb065 RDI: 0001 RBP: 8801b3de77f0 R08: 8801c44ba680 R09: ed003b5e4732 R10: ed003b5e4732 R11: 8801daf23993 R12: R13: 8801d87b7820 R14: fff4 R15: 8801d87b7800 FS: 0207a880() GS:8801daf0() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 7f14a574e169 CR3: 0001c5068000 CR4: 001406e0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 Call Trace: ovl_fill_super+0x4f4/0x40a3 fs/overlayfs/super.c:1508 mount_nodev+0x6b/0x110 fs/super.c:1204 ovl_mount+0x2c/0x40 fs/overlayfs/super.c:1516 mount_fs+0xae/0x31d fs/super.c:1261 vfs_kern_mount.part.35+0xdc/0x4f0 fs/namespace.c:961 vfs_kern_mount fs/namespace.c:951 [inline] do_new_mount fs/namespace.c:2457 [inline] do_mount+0x581/0x31f0 fs/namespace.c:2787 ksys_mount+0x12d/0x140 fs/namespace.c:3003 __do_sys_mount fs/namespace.c:3017 [inline] __se_sys_mount fs/namespace.c:3014 [inline] __x64_sys_mount+0xbe/0x150 fs/namespace.c:3014 do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x445119 Code: ad ce fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 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 0f 83 7b ce fb ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:7ffef77a0948 EFLAGS: 0246 ORIG_RAX: 00a5 RAX: ffda RBX: RCX: 00445119 RDX: 20c0 RSI: 2080 RDI: RBP: 7ffef77a0960 R08: 2100 R09: 7ffef77f92f4 R10: R11: 0246 R12: R13: 0003 R14: R15: Modules linked in: Dumping ftrace buffer: (ftrace buffer empty) ---[ end trace 6b50ff34ce671ab8 ]--- RIP: 0010:ovl_free_fs+0x504/0x690 fs/overlayfs/super.c:226 Code: 00 00 00 00 00 fc ff df 48 c1 ea 03 80 3c 02 00 0f 85 78 01 00 00 48 b8 00 00 00 00 00 fc ff df 4c 8b 23 4c 89 e2 48 c1 ea 03 <80> 3c 02 00 0f 85 67 01 00 00 49 8b 3c 24 e8 c9 0a 01 00 e9 0c fc RSP: 0018:8801b3de7798 EFLAGS: 00010246 RAX: dc00 RBX: 8801d87b7800 RCX: 828cacaf RDX: RSI: 828cb065 RDI: 0001 RBP: 8801b3de77f0 R08: 8801c44ba680 R09: ed003b5e4732 R10: ed003b5e4732 R11: 8801daf23993 R12: R13: 8801d87b7820 R14: fff4 R15: 8801d87b7800 FS: 0207a880() GS:8801daf0() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 7f14a574e169 CR3: 0001c5068000 CR4: 001406e0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400
Re: general protection fault in ovl_free_fs
syzbot has found a reproducer for the following crash on: HEAD commit:d7b686ebf704 Merge branch 'i2c/for-current' of git://git.k.. git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=148ac14940 kernel config: https://syzkaller.appspot.com/x/.config?x=8f59875069d721b6 dashboard link: https://syzkaller.appspot.com/bug?extid=c75f181dc8429d2eb887 compiler: gcc (GCC) 8.0.1 20180413 (experimental) syz repro: https://syzkaller.appspot.com/x/repro.syz?x=11553b7a40 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=14b1642140 IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+c75f181dc8429d2eb...@syzkaller.appspotmail.com R10: R11: 0246 R12: R13: 0003 R14: R15: overlayfs: failed to clone upperpath kasan: CONFIG_KASAN_INLINE enabled kasan: GPF could be caused by NULL-ptr deref or user memory access general protection fault: [#1] PREEMPT SMP KASAN CPU: 1 PID: 5473 Comm: syz-executor554 Not tainted 4.19.0-rc2+ #7 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:ovl_free_fs+0x504/0x690 fs/overlayfs/super.c:226 Code: 00 00 00 00 00 fc ff df 48 c1 ea 03 80 3c 02 00 0f 85 78 01 00 00 48 b8 00 00 00 00 00 fc ff df 4c 8b 23 4c 89 e2 48 c1 ea 03 <80> 3c 02 00 0f 85 67 01 00 00 49 8b 3c 24 e8 c9 0a 01 00 e9 0c fc RSP: 0018:8801b3de7798 EFLAGS: 00010246 RAX: dc00 RBX: 8801d87b7800 RCX: 828cacaf RDX: RSI: 828cb065 RDI: 0001 RBP: 8801b3de77f0 R08: 8801c44ba680 R09: ed003b5e4732 R10: ed003b5e4732 R11: 8801daf23993 R12: R13: 8801d87b7820 R14: fff4 R15: 8801d87b7800 FS: 0207a880() GS:8801daf0() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 7f14a574e169 CR3: 0001c5068000 CR4: 001406e0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 Call Trace: ovl_fill_super+0x4f4/0x40a3 fs/overlayfs/super.c:1508 mount_nodev+0x6b/0x110 fs/super.c:1204 ovl_mount+0x2c/0x40 fs/overlayfs/super.c:1516 mount_fs+0xae/0x31d fs/super.c:1261 vfs_kern_mount.part.35+0xdc/0x4f0 fs/namespace.c:961 vfs_kern_mount fs/namespace.c:951 [inline] do_new_mount fs/namespace.c:2457 [inline] do_mount+0x581/0x31f0 fs/namespace.c:2787 ksys_mount+0x12d/0x140 fs/namespace.c:3003 __do_sys_mount fs/namespace.c:3017 [inline] __se_sys_mount fs/namespace.c:3014 [inline] __x64_sys_mount+0xbe/0x150 fs/namespace.c:3014 do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x445119 Code: ad ce fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 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 0f 83 7b ce fb ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:7ffef77a0948 EFLAGS: 0246 ORIG_RAX: 00a5 RAX: ffda RBX: RCX: 00445119 RDX: 20c0 RSI: 2080 RDI: RBP: 7ffef77a0960 R08: 2100 R09: 7ffef77f92f4 R10: R11: 0246 R12: R13: 0003 R14: R15: Modules linked in: Dumping ftrace buffer: (ftrace buffer empty) ---[ end trace 6b50ff34ce671ab8 ]--- RIP: 0010:ovl_free_fs+0x504/0x690 fs/overlayfs/super.c:226 Code: 00 00 00 00 00 fc ff df 48 c1 ea 03 80 3c 02 00 0f 85 78 01 00 00 48 b8 00 00 00 00 00 fc ff df 4c 8b 23 4c 89 e2 48 c1 ea 03 <80> 3c 02 00 0f 85 67 01 00 00 49 8b 3c 24 e8 c9 0a 01 00 e9 0c fc RSP: 0018:8801b3de7798 EFLAGS: 00010246 RAX: dc00 RBX: 8801d87b7800 RCX: 828cacaf RDX: RSI: 828cb065 RDI: 0001 RBP: 8801b3de77f0 R08: 8801c44ba680 R09: ed003b5e4732 R10: ed003b5e4732 R11: 8801daf23993 R12: R13: 8801d87b7820 R14: fff4 R15: 8801d87b7800 FS: 0207a880() GS:8801daf0() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 7f14a574e169 CR3: 0001c5068000 CR4: 001406e0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400
Re: [PATCH v11 03/11] firmware: xilinx: Add zynqmp IOCTL API for device control
Hi, On Fri, Aug 3, 2018 at 10:53 AM, Jolly Shah wrote: > From: Rajan Vaja > > Add ZynqMP firmware IOCTL API to control and configure > devices like PLLs, SD, Gem, etc. > > Signed-off-by: Rajan Vaja > Signed-off-by: Jolly Shah This patch worries me somewhat. It's a transparent pass-through ioctl driver. Is there a spec available for what the implemented IOCTLs are? Should some of them be proper drivers instead of an opaque pass-through like this? Could some of them have stability impact on the platform such that there are security concerns and the list of arguments should somehow be sanitized? What's the intended usecase anyway? Just a debug tool during development, or something that you expect heavy use of by some userspace middleware? -Olof
Re: [PATCH v11 03/11] firmware: xilinx: Add zynqmp IOCTL API for device control
Hi, On Fri, Aug 3, 2018 at 10:53 AM, Jolly Shah wrote: > From: Rajan Vaja > > Add ZynqMP firmware IOCTL API to control and configure > devices like PLLs, SD, Gem, etc. > > Signed-off-by: Rajan Vaja > Signed-off-by: Jolly Shah This patch worries me somewhat. It's a transparent pass-through ioctl driver. Is there a spec available for what the implemented IOCTLs are? Should some of them be proper drivers instead of an opaque pass-through like this? Could some of them have stability impact on the platform such that there are security concerns and the list of arguments should somehow be sanitized? What's the intended usecase anyway? Just a debug tool during development, or something that you expect heavy use of by some userspace middleware? -Olof
Re: [PATCH v11 08/11] firmware: xilinx: Add debugfs for query data API
Hi,
I noticed the below when I was reviewing the code for merge into
arm-soc. Would you mind following up with an incremental patch? I
don't think we need to ask Michal to respin for this:
On Fri, Aug 3, 2018 at 10:53 AM, Jolly Shah wrote:
> From: Rajan Vaja
>
> Add debugfs file to query platform specific data from firmware
> using debugfs interface.
>
> Signed-off-by: Rajan Vaja
> Signed-off-by: Jolly Shah
> ---
> drivers/firmware/xilinx/zynqmp-debug.c | 27 +++
> 1 file changed, 27 insertions(+)
>
> diff --git a/drivers/firmware/xilinx/zynqmp-debug.c
> b/drivers/firmware/xilinx/zynqmp-debug.c
> index fc11db9..4532bd0 100644
> --- a/drivers/firmware/xilinx/zynqmp-debug.c
> +++ b/drivers/firmware/xilinx/zynqmp-debug.c
> @@ -33,6 +33,7 @@ static char debugfs_buf[PAGE_SIZE];
> static struct pm_api_info pm_api_list[] = {
> PM_API(PM_GET_API_VERSION),
> PM_API(PM_IOCTL),
> + PM_API(PM_QUERY_DATA),
> };
>
> /**
> @@ -105,6 +106,32 @@ static int process_api_request(u32 pm_id, u64
> *pm_api_arg, u32 *pm_api_ret)
> sprintf(debugfs_buf, "IOCTL return value: %u\n",
> pm_api_ret[1]);
> break;
> + case PM_QUERY_DATA:
> + {
> + struct zynqmp_pm_query_data qdata = {0};
> +
> + qdata.qid = pm_api_arg[0];
> + qdata.arg1 = pm_api_arg[1];
> + qdata.arg2 = pm_api_arg[2];
> + qdata.arg3 = pm_api_arg[3];
This is usually a pattern we try to avoid (having full code blocks in
a switch statement, and local variables).
Please move the declaration of qdata to the top of the function so you
can drop the braces.
> +
> + ret = eemi_ops->query_data(qdata, pm_api_ret);
> + if (ret)
> + break;
> +
> + if (qdata.qid == PM_QID_CLOCK_GET_NAME)
> + sprintf(debugfs_buf, "Clock name = %s\n",
> + (char *)pm_api_ret);
> + else if (qdata.qid == PM_QID_CLOCK_GET_FIXEDFACTOR_PARAMS)
> + sprintf(debugfs_buf, "Multiplier = %d, Divider =
> %d\n",
> + pm_api_ret[1], pm_api_ret[2]);
> + else
> + sprintf(debugfs_buf,
> + "data[0] = 0x%08x\ndata[1] = 0x%08x\n data[2]
> = 0x%08x\ndata[3] = 0x%08x\n",
> + pm_api_ret[0], pm_api_ret[1],
> + pm_api_ret[2], pm_api_ret[3]);
If you anticipate more qids here later, a switch could be nicer than a
sequence of if/else.
-Olof
Re: [PATCH v11 08/11] firmware: xilinx: Add debugfs for query data API
Hi,
I noticed the below when I was reviewing the code for merge into
arm-soc. Would you mind following up with an incremental patch? I
don't think we need to ask Michal to respin for this:
On Fri, Aug 3, 2018 at 10:53 AM, Jolly Shah wrote:
> From: Rajan Vaja
>
> Add debugfs file to query platform specific data from firmware
> using debugfs interface.
>
> Signed-off-by: Rajan Vaja
> Signed-off-by: Jolly Shah
> ---
> drivers/firmware/xilinx/zynqmp-debug.c | 27 +++
> 1 file changed, 27 insertions(+)
>
> diff --git a/drivers/firmware/xilinx/zynqmp-debug.c
> b/drivers/firmware/xilinx/zynqmp-debug.c
> index fc11db9..4532bd0 100644
> --- a/drivers/firmware/xilinx/zynqmp-debug.c
> +++ b/drivers/firmware/xilinx/zynqmp-debug.c
> @@ -33,6 +33,7 @@ static char debugfs_buf[PAGE_SIZE];
> static struct pm_api_info pm_api_list[] = {
> PM_API(PM_GET_API_VERSION),
> PM_API(PM_IOCTL),
> + PM_API(PM_QUERY_DATA),
> };
>
> /**
> @@ -105,6 +106,32 @@ static int process_api_request(u32 pm_id, u64
> *pm_api_arg, u32 *pm_api_ret)
> sprintf(debugfs_buf, "IOCTL return value: %u\n",
> pm_api_ret[1]);
> break;
> + case PM_QUERY_DATA:
> + {
> + struct zynqmp_pm_query_data qdata = {0};
> +
> + qdata.qid = pm_api_arg[0];
> + qdata.arg1 = pm_api_arg[1];
> + qdata.arg2 = pm_api_arg[2];
> + qdata.arg3 = pm_api_arg[3];
This is usually a pattern we try to avoid (having full code blocks in
a switch statement, and local variables).
Please move the declaration of qdata to the top of the function so you
can drop the braces.
> +
> + ret = eemi_ops->query_data(qdata, pm_api_ret);
> + if (ret)
> + break;
> +
> + if (qdata.qid == PM_QID_CLOCK_GET_NAME)
> + sprintf(debugfs_buf, "Clock name = %s\n",
> + (char *)pm_api_ret);
> + else if (qdata.qid == PM_QID_CLOCK_GET_FIXEDFACTOR_PARAMS)
> + sprintf(debugfs_buf, "Multiplier = %d, Divider =
> %d\n",
> + pm_api_ret[1], pm_api_ret[2]);
> + else
> + sprintf(debugfs_buf,
> + "data[0] = 0x%08x\ndata[1] = 0x%08x\n data[2]
> = 0x%08x\ndata[3] = 0x%08x\n",
> + pm_api_ret[0], pm_api_ret[1],
> + pm_api_ret[2], pm_api_ret[3]);
If you anticipate more qids here later, a switch could be nicer than a
sequence of if/else.
-Olof
Re: [PATCH v4 02/16] sched/core: uclamp: map TASK's clamp values into CPU's clamp groups
Hi Patrick!
On Tue, Aug 28, 2018 at 6:53 AM, Patrick Bellasi
wrote:
> Utilization clamping requires each CPU to know which clamp values are
> assigned to tasks that are currently RUNNABLE on that CPU.
> Multiple tasks can be assigned the same clamp value and tasks with
> different clamp values can be concurrently active on the same CPU.
> Thus, a proper data structure is required to support a fast and
> efficient aggregation of the clamp values required by the currently
> RUNNABLE tasks.
>
> For this purpose we use a per-CPU array of reference counters,
> where each slot is used to account how many tasks require a certain
> clamp value are currently RUNNABLE on each CPU.
> Each clamp value corresponds to a "clamp index" which identifies the
> position within the array of reference counters.
>
> :
>(user-space changes) : (kernel space / scheduler)
> :
> SLOW PATH : FAST PATH
> :
> task_struct::uclamp::value : sched/core::enqueue/dequeue
> : cpufreq_schedutil
> :
> ++++ +---+
> | TASK || CLAMP GROUP| |CPU CLAMPS |
> ++++ +---+
> ||| clamp_{min,max} | | clamp_{min,max} |
> | util_{min,max} || se_count | |tasks count|
> ++++ +---+
> :
>+--> : +--->
> group_id = map(clamp_value) : ref_count(group_id)
> :
> :
>
> Let's introduce the support to map tasks to "clamp groups".
> Specifically we introduce the required functions to translate a
> "clamp value" into a clamp's "group index" (group_id).
>
> Only a limited number of (different) clamp values are supported since:
> 1. there are usually only few classes of workloads for which it makes
>sense to boost/limit to different frequencies,
>e.g. background vs foreground, interactive vs low-priority
> 2. it allows a simpler and more memory/time efficient tracking of
>the per-CPU clamp values in the fast path.
>
> The number of possible different clamp values is currently defined at
> compile time. Thus, setting a new clamp value for a task can result into
> a -ENOSPC error in case this will exceed the number of maximum different
> clamp values supported.
>
> Signed-off-by: Patrick Bellasi
> Cc: Ingo Molnar
> Cc: Peter Zijlstra
> Cc: Paul Turner
> Cc: Suren Baghdasaryan
> Cc: Todd Kjos
> Cc: Joel Fernandes
> Cc: Juri Lelli
> Cc: Quentin Perret
> Cc: Dietmar Eggemann
> Cc: Morten Rasmussen
> Cc: linux-kernel@vger.kernel.org
> Cc: linux...@vger.kernel.org
>
> ---
> Changes in v4:
> Message-ID: <20180814112509.gb2...@codeaurora.org>
> - add uclamp_exit_task() to release clamp refcount from do_exit()
> Message-ID: <20180816133249.GA2964@e110439-lin>
> - keep the WARN but butify a bit that code
> Message-ID: <20180413082648.gp4...@hirez.programming.kicks-ass.net>
> - move uclamp_enabled at the top of sched_class to keep it on the same
>cache line of other main wakeup time callbacks
> Others:
> - init uclamp for the init_task and refcount its clamp groups
> - add uclamp specific fork time code into uclamp_fork
> - add support for SCHED_FLAG_RESET_ON_FORK
>default clamps are now set for init_task and inherited/reset at
>fork time (when then flag is set for the parent)
> - enable uclamp only for FAIR tasks, RT class will be enabled only
>by a following patch which also integrate the class to schedutil
> - define uclamp_maps cacheline_aligned_in_smp
> - in uclamp_group_get() ensure to include uclamp_group_available() and
>uclamp_group_init() into the atomic section defined by:
> uc_map[next_group_id].se_lock
> - do not use mutex_lock(_mutex) in uclamp_exit_task
>which is also not needed since refcounting is already guarded by
>the uc_map[group_id].se_lock spinlock
> - rebased on v4.19-rc1
>
> Changes in v3:
> Message-ID:
>
> - rename UCLAMP_NONE into UCLAMP_NOT_VALID
> - remove not necessary checks in uclamp_group_find()
> - add WARN on unlikely un-referenced decrement in uclamp_group_put()
> - make __setscheduler_uclamp() able to set just one clamp value
> - make __setscheduler_uclamp() failing if both clamps are required but
>there is no clamp groups available for one of them
> - remove uclamp_group_find() from uclamp_group_get() which now takes a
>group_id as a parameter
> Others:
> - rebased on tip/sched/core
> Changes in v2:
> - rabased on v4.18-rc4
> - set UCLAMP_GROUPS_COUNT=2 by default
>which allows to fit all
Re: [PATCH v4 02/16] sched/core: uclamp: map TASK's clamp values into CPU's clamp groups
Hi Patrick!
On Tue, Aug 28, 2018 at 6:53 AM, Patrick Bellasi
wrote:
> Utilization clamping requires each CPU to know which clamp values are
> assigned to tasks that are currently RUNNABLE on that CPU.
> Multiple tasks can be assigned the same clamp value and tasks with
> different clamp values can be concurrently active on the same CPU.
> Thus, a proper data structure is required to support a fast and
> efficient aggregation of the clamp values required by the currently
> RUNNABLE tasks.
>
> For this purpose we use a per-CPU array of reference counters,
> where each slot is used to account how many tasks require a certain
> clamp value are currently RUNNABLE on each CPU.
> Each clamp value corresponds to a "clamp index" which identifies the
> position within the array of reference counters.
>
> :
>(user-space changes) : (kernel space / scheduler)
> :
> SLOW PATH : FAST PATH
> :
> task_struct::uclamp::value : sched/core::enqueue/dequeue
> : cpufreq_schedutil
> :
> ++++ +---+
> | TASK || CLAMP GROUP| |CPU CLAMPS |
> ++++ +---+
> ||| clamp_{min,max} | | clamp_{min,max} |
> | util_{min,max} || se_count | |tasks count|
> ++++ +---+
> :
>+--> : +--->
> group_id = map(clamp_value) : ref_count(group_id)
> :
> :
>
> Let's introduce the support to map tasks to "clamp groups".
> Specifically we introduce the required functions to translate a
> "clamp value" into a clamp's "group index" (group_id).
>
> Only a limited number of (different) clamp values are supported since:
> 1. there are usually only few classes of workloads for which it makes
>sense to boost/limit to different frequencies,
>e.g. background vs foreground, interactive vs low-priority
> 2. it allows a simpler and more memory/time efficient tracking of
>the per-CPU clamp values in the fast path.
>
> The number of possible different clamp values is currently defined at
> compile time. Thus, setting a new clamp value for a task can result into
> a -ENOSPC error in case this will exceed the number of maximum different
> clamp values supported.
>
> Signed-off-by: Patrick Bellasi
> Cc: Ingo Molnar
> Cc: Peter Zijlstra
> Cc: Paul Turner
> Cc: Suren Baghdasaryan
> Cc: Todd Kjos
> Cc: Joel Fernandes
> Cc: Juri Lelli
> Cc: Quentin Perret
> Cc: Dietmar Eggemann
> Cc: Morten Rasmussen
> Cc: linux-kernel@vger.kernel.org
> Cc: linux...@vger.kernel.org
>
> ---
> Changes in v4:
> Message-ID: <20180814112509.gb2...@codeaurora.org>
> - add uclamp_exit_task() to release clamp refcount from do_exit()
> Message-ID: <20180816133249.GA2964@e110439-lin>
> - keep the WARN but butify a bit that code
> Message-ID: <20180413082648.gp4...@hirez.programming.kicks-ass.net>
> - move uclamp_enabled at the top of sched_class to keep it on the same
>cache line of other main wakeup time callbacks
> Others:
> - init uclamp for the init_task and refcount its clamp groups
> - add uclamp specific fork time code into uclamp_fork
> - add support for SCHED_FLAG_RESET_ON_FORK
>default clamps are now set for init_task and inherited/reset at
>fork time (when then flag is set for the parent)
> - enable uclamp only for FAIR tasks, RT class will be enabled only
>by a following patch which also integrate the class to schedutil
> - define uclamp_maps cacheline_aligned_in_smp
> - in uclamp_group_get() ensure to include uclamp_group_available() and
>uclamp_group_init() into the atomic section defined by:
> uc_map[next_group_id].se_lock
> - do not use mutex_lock(_mutex) in uclamp_exit_task
>which is also not needed since refcounting is already guarded by
>the uc_map[group_id].se_lock spinlock
> - rebased on v4.19-rc1
>
> Changes in v3:
> Message-ID:
>
> - rename UCLAMP_NONE into UCLAMP_NOT_VALID
> - remove not necessary checks in uclamp_group_find()
> - add WARN on unlikely un-referenced decrement in uclamp_group_put()
> - make __setscheduler_uclamp() able to set just one clamp value
> - make __setscheduler_uclamp() failing if both clamps are required but
>there is no clamp groups available for one of them
> - remove uclamp_group_find() from uclamp_group_get() which now takes a
>group_id as a parameter
> Others:
> - rebased on tip/sched/core
> Changes in v2:
> - rabased on v4.18-rc4
> - set UCLAMP_GROUPS_COUNT=2 by default
>which allows to fit all
[PATCH] pcmcia: Implement CLKRUN protocol disabling for Ricoh bridges
Currently, "disable_clkrun" yenta_socket module parameter is only
implemented for TI CardBus bridges.
Add also an implementation for Ricoh bridges that have the necessary
setting documented in publicly available datasheets.
Tested on a RL5C476II with a Sunrich C-160 CardBus NIC that doesn't work
correctly unless the CLKRUN protocol is disabled.
Let's also make it clear in its description that the "disable_clkrun"
module parameter only works on these two previously mentioned brands of
CardBus bridges.
Signed-off-by: Maciej S. Szmigiero
---
drivers/pcmcia/ricoh.h| 35 +++
drivers/pcmcia/yenta_socket.c | 3 ++-
2 files changed, 37 insertions(+), 1 deletion(-)
diff --git a/drivers/pcmcia/ricoh.h b/drivers/pcmcia/ricoh.h
index 01098c841f87..8ac7b138c094 100644
--- a/drivers/pcmcia/ricoh.h
+++ b/drivers/pcmcia/ricoh.h
@@ -119,6 +119,10 @@
#define RL5C4XX_MISC_CONTROL 0x2F /* 8 bit */
#define RL5C4XX_ZV_ENABLE 0x08
+/* Misc Control 3 Register */
+#define RL5C4XX_MISC3 0x00A2 /* 16 bit */
+#define RL5C47X_MISC3_CB_CLKRUN_DIS BIT(1)
+
#ifdef __YENTA_H
#define rl_misc(socket)((socket)->private[0])
@@ -156,6 +160,35 @@ static void ricoh_set_zv(struct yenta_socket *socket)
}
}
+static void ricoh_set_clkrun(struct yenta_socket *socket, bool quiet)
+{
+ u16 misc3;
+
+ /*
+* RL5C475II likely has this setting, too, however no datasheet
+* is publicly available for this chip
+*/
+ if (socket->dev->device != PCI_DEVICE_ID_RICOH_RL5C476 &&
+ socket->dev->device != PCI_DEVICE_ID_RICOH_RL5C478)
+ return;
+
+ if (socket->dev->revision < 0x80)
+ return;
+
+ misc3 = config_readw(socket, RL5C4XX_MISC3);
+ if (misc3 & RL5C47X_MISC3_CB_CLKRUN_DIS) {
+ if (!quiet)
+ dev_dbg(>dev->dev,
+ "CLKRUN feature already disabled\n");
+ } else if (disable_clkrun) {
+ if (!quiet)
+ dev_info(>dev->dev,
+"Disabling CLKRUN feature\n");
+ misc3 |= RL5C47X_MISC3_CB_CLKRUN_DIS;
+ config_writew(socket, RL5C4XX_MISC3, misc3);
+ }
+}
+
static void ricoh_save_state(struct yenta_socket *socket)
{
rl_misc(socket) = config_readw(socket, RL5C4XX_MISC);
@@ -172,6 +205,7 @@ static void ricoh_restore_state(struct yenta_socket *socket)
config_writew(socket, RL5C4XX_16BIT_IO_0, rl_io(socket));
config_writew(socket, RL5C4XX_16BIT_MEM_0, rl_mem(socket));
config_writew(socket, RL5C4XX_CONFIG, rl_config(socket));
+ ricoh_set_clkrun(socket, true);
}
@@ -197,6 +231,7 @@ static int ricoh_override(struct yenta_socket *socket)
config_writew(socket, RL5C4XX_CONFIG, config);
ricoh_set_zv(socket);
+ ricoh_set_clkrun(socket, false);
return 0;
}
diff --git a/drivers/pcmcia/yenta_socket.c b/drivers/pcmcia/yenta_socket.c
index ab3da2262f0f..ac6a3f46b1e6 100644
--- a/drivers/pcmcia/yenta_socket.c
+++ b/drivers/pcmcia/yenta_socket.c
@@ -26,7 +26,8 @@
static bool disable_clkrun;
module_param(disable_clkrun, bool, 0444);
-MODULE_PARM_DESC(disable_clkrun, "If PC card doesn't function properly, please
try this option");
+MODULE_PARM_DESC(disable_clkrun,
+"If PC card doesn't function properly, please try this option
(TI and Ricoh bridges only)");
static bool isa_probe = 1;
module_param(isa_probe, bool, 0444);
--
2.17.0
[PATCH] pcmcia: Implement CLKRUN protocol disabling for Ricoh bridges
Currently, "disable_clkrun" yenta_socket module parameter is only
implemented for TI CardBus bridges.
Add also an implementation for Ricoh bridges that have the necessary
setting documented in publicly available datasheets.
Tested on a RL5C476II with a Sunrich C-160 CardBus NIC that doesn't work
correctly unless the CLKRUN protocol is disabled.
Let's also make it clear in its description that the "disable_clkrun"
module parameter only works on these two previously mentioned brands of
CardBus bridges.
Signed-off-by: Maciej S. Szmigiero
---
drivers/pcmcia/ricoh.h| 35 +++
drivers/pcmcia/yenta_socket.c | 3 ++-
2 files changed, 37 insertions(+), 1 deletion(-)
diff --git a/drivers/pcmcia/ricoh.h b/drivers/pcmcia/ricoh.h
index 01098c841f87..8ac7b138c094 100644
--- a/drivers/pcmcia/ricoh.h
+++ b/drivers/pcmcia/ricoh.h
@@ -119,6 +119,10 @@
#define RL5C4XX_MISC_CONTROL 0x2F /* 8 bit */
#define RL5C4XX_ZV_ENABLE 0x08
+/* Misc Control 3 Register */
+#define RL5C4XX_MISC3 0x00A2 /* 16 bit */
+#define RL5C47X_MISC3_CB_CLKRUN_DIS BIT(1)
+
#ifdef __YENTA_H
#define rl_misc(socket)((socket)->private[0])
@@ -156,6 +160,35 @@ static void ricoh_set_zv(struct yenta_socket *socket)
}
}
+static void ricoh_set_clkrun(struct yenta_socket *socket, bool quiet)
+{
+ u16 misc3;
+
+ /*
+* RL5C475II likely has this setting, too, however no datasheet
+* is publicly available for this chip
+*/
+ if (socket->dev->device != PCI_DEVICE_ID_RICOH_RL5C476 &&
+ socket->dev->device != PCI_DEVICE_ID_RICOH_RL5C478)
+ return;
+
+ if (socket->dev->revision < 0x80)
+ return;
+
+ misc3 = config_readw(socket, RL5C4XX_MISC3);
+ if (misc3 & RL5C47X_MISC3_CB_CLKRUN_DIS) {
+ if (!quiet)
+ dev_dbg(>dev->dev,
+ "CLKRUN feature already disabled\n");
+ } else if (disable_clkrun) {
+ if (!quiet)
+ dev_info(>dev->dev,
+"Disabling CLKRUN feature\n");
+ misc3 |= RL5C47X_MISC3_CB_CLKRUN_DIS;
+ config_writew(socket, RL5C4XX_MISC3, misc3);
+ }
+}
+
static void ricoh_save_state(struct yenta_socket *socket)
{
rl_misc(socket) = config_readw(socket, RL5C4XX_MISC);
@@ -172,6 +205,7 @@ static void ricoh_restore_state(struct yenta_socket *socket)
config_writew(socket, RL5C4XX_16BIT_IO_0, rl_io(socket));
config_writew(socket, RL5C4XX_16BIT_MEM_0, rl_mem(socket));
config_writew(socket, RL5C4XX_CONFIG, rl_config(socket));
+ ricoh_set_clkrun(socket, true);
}
@@ -197,6 +231,7 @@ static int ricoh_override(struct yenta_socket *socket)
config_writew(socket, RL5C4XX_CONFIG, config);
ricoh_set_zv(socket);
+ ricoh_set_clkrun(socket, false);
return 0;
}
diff --git a/drivers/pcmcia/yenta_socket.c b/drivers/pcmcia/yenta_socket.c
index ab3da2262f0f..ac6a3f46b1e6 100644
--- a/drivers/pcmcia/yenta_socket.c
+++ b/drivers/pcmcia/yenta_socket.c
@@ -26,7 +26,8 @@
static bool disable_clkrun;
module_param(disable_clkrun, bool, 0444);
-MODULE_PARM_DESC(disable_clkrun, "If PC card doesn't function properly, please
try this option");
+MODULE_PARM_DESC(disable_clkrun,
+"If PC card doesn't function properly, please try this option
(TI and Ricoh bridges only)");
static bool isa_probe = 1;
module_param(isa_probe, bool, 0444);
--
2.17.0
[PATCH v4 05/13] Compiler Attributes: naked was fixed in gcc 4.6
Commit 9c695203a7dd ("compiler-gcc.h: gcc-4.5 needs noclone
and noinline on __naked functions") added noinline and noclone
as a workaround for a gcc 4.5 bug, which was resolved in 4.6.0.
Since now the minimum gcc supported version is 4.6,
we can clean it up.
See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44290
and https://godbolt.org/z/h6NMIL
Cc: Rasmus Villemoes
Cc: Luc Van Oostenryck
Cc: Eli Friedman
Cc: Christopher Li
Cc: Kees Cook
Cc: Ingo Molnar
Cc: Geert Uytterhoeven
Cc: Arnd Bergmann
Cc: Greg Kroah-Hartman
Cc: Masahiro Yamada
Cc: Joe Perches
Cc: Dominique Martinet
Cc: Nick Desaulniers
Cc: Linus Torvalds
Cc: linux-spa...@vger.kernel.org
Signed-off-by: Miguel Ojeda
---
include/linux/compiler-gcc.h | 8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/include/linux/compiler-gcc.h b/include/linux/compiler-gcc.h
index 76f4907ef707..4cd5e9264bce 100644
--- a/include/linux/compiler-gcc.h
+++ b/include/linux/compiler-gcc.h
@@ -77,14 +77,8 @@
* to trace naked functions because then mcount is called without
* stack and frame pointer being set up and there is no chance to
* restore the lr register to the value before mcount was called.
- *
- * The asm() bodies of naked functions often depend on standard calling
- * conventions, therefore they must be noinline and noclone.
- *
- * GCC 4.[56] currently fail to enforce this, so we must do so ourselves.
- * See GCC PR44290.
*/
-#define __naked__attribute__((__naked__)) noinline __noclone
notrace
+#define __naked__attribute__((__naked__)) notrace
#define __UNIQUE_ID(prefix) __PASTE(__PASTE(__UNIQUE_ID_, prefix), __COUNTER__)
--
2.17.1
[PATCH v4 10/13] Compiler Attributes: KENTRY used twice the "used" attribute
Cc: Rasmus Villemoes
Cc: Luc Van Oostenryck
Cc: Eli Friedman
Cc: Christopher Li
Cc: Kees Cook
Cc: Ingo Molnar
Cc: Geert Uytterhoeven
Cc: Arnd Bergmann
Cc: Greg Kroah-Hartman
Cc: Masahiro Yamada
Cc: Joe Perches
Cc: Dominique Martinet
Cc: Linus Torvalds
Cc: linux-spa...@vger.kernel.org
Reviewed-by: Nick Desaulniers
Signed-off-by: Miguel Ojeda
---
include/linux/compiler.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/compiler.h b/include/linux/compiler.h
index 4030a2940d6b..17ee9165ca51 100644
--- a/include/linux/compiler.h
+++ b/include/linux/compiler.h
@@ -146,7 +146,7 @@ void ftrace_likely_update(struct ftrace_likely_data *f, int
val,
extern typeof(sym) sym; \
static const unsigned long __kentry_##sym \
__used \
- __attribute__((__section__("___kentry" "+" #sym ), used)) \
+ __attribute__((__section__("___kentry" "+" #sym ))) \
= (unsigned long)
#endif
--
2.17.1
[PATCH v4 05/13] Compiler Attributes: naked was fixed in gcc 4.6
Commit 9c695203a7dd ("compiler-gcc.h: gcc-4.5 needs noclone
and noinline on __naked functions") added noinline and noclone
as a workaround for a gcc 4.5 bug, which was resolved in 4.6.0.
Since now the minimum gcc supported version is 4.6,
we can clean it up.
See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44290
and https://godbolt.org/z/h6NMIL
Cc: Rasmus Villemoes
Cc: Luc Van Oostenryck
Cc: Eli Friedman
Cc: Christopher Li
Cc: Kees Cook
Cc: Ingo Molnar
Cc: Geert Uytterhoeven
Cc: Arnd Bergmann
Cc: Greg Kroah-Hartman
Cc: Masahiro Yamada
Cc: Joe Perches
Cc: Dominique Martinet
Cc: Nick Desaulniers
Cc: Linus Torvalds
Cc: linux-spa...@vger.kernel.org
Signed-off-by: Miguel Ojeda
---
include/linux/compiler-gcc.h | 8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/include/linux/compiler-gcc.h b/include/linux/compiler-gcc.h
index 76f4907ef707..4cd5e9264bce 100644
--- a/include/linux/compiler-gcc.h
+++ b/include/linux/compiler-gcc.h
@@ -77,14 +77,8 @@
* to trace naked functions because then mcount is called without
* stack and frame pointer being set up and there is no chance to
* restore the lr register to the value before mcount was called.
- *
- * The asm() bodies of naked functions often depend on standard calling
- * conventions, therefore they must be noinline and noclone.
- *
- * GCC 4.[56] currently fail to enforce this, so we must do so ourselves.
- * See GCC PR44290.
*/
-#define __naked__attribute__((__naked__)) noinline __noclone
notrace
+#define __naked__attribute__((__naked__)) notrace
#define __UNIQUE_ID(prefix) __PASTE(__PASTE(__UNIQUE_ID_, prefix), __COUNTER__)
--
2.17.1
[PATCH v4 10/13] Compiler Attributes: KENTRY used twice the "used" attribute
Cc: Rasmus Villemoes
Cc: Luc Van Oostenryck
Cc: Eli Friedman
Cc: Christopher Li
Cc: Kees Cook
Cc: Ingo Molnar
Cc: Geert Uytterhoeven
Cc: Arnd Bergmann
Cc: Greg Kroah-Hartman
Cc: Masahiro Yamada
Cc: Joe Perches
Cc: Dominique Martinet
Cc: Linus Torvalds
Cc: linux-spa...@vger.kernel.org
Reviewed-by: Nick Desaulniers
Signed-off-by: Miguel Ojeda
---
include/linux/compiler.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/compiler.h b/include/linux/compiler.h
index 4030a2940d6b..17ee9165ca51 100644
--- a/include/linux/compiler.h
+++ b/include/linux/compiler.h
@@ -146,7 +146,7 @@ void ftrace_likely_update(struct ftrace_likely_data *f, int
val,
extern typeof(sym) sym; \
static const unsigned long __kentry_##sym \
__used \
- __attribute__((__section__("___kentry" "+" #sym ), used)) \
+ __attribute__((__section__("___kentry" "+" #sym ))) \
= (unsigned long)
#endif
--
2.17.1
[PATCH v4 04/13] Compiler Attributes: homogenize __must_be_array
Different definitions of __must_be_array:
* gcc: disabled for __CHECKER__
* clang: same definition as gcc's, but without __CHECKER__
* intel: the comment claims __builtin_types_compatible_p()
is unsupported; but icc seems to support it since 13.0.1
(released in 2012). See https://godbolt.org/z/S0l6QQ
Therefore, we can remove all of them and have a single definition
in compiler.h
Cc: Rasmus Villemoes
Cc: Luc Van Oostenryck
Cc: Eli Friedman
Cc: Christopher Li
Cc: Kees Cook
Cc: Ingo Molnar
Cc: Geert Uytterhoeven
Cc: Arnd Bergmann
Cc: Greg Kroah-Hartman
Cc: Masahiro Yamada
Cc: Joe Perches
Cc: Dominique Martinet
Cc: Linus Torvalds
Cc: linux-spa...@vger.kernel.org
Reviewed-by: Nick Desaulniers
Signed-off-by: Miguel Ojeda
---
include/linux/compiler-clang.h | 1 -
include/linux/compiler-gcc.h | 7 ---
include/linux/compiler-intel.h | 3 ---
include/linux/compiler.h | 7 +++
4 files changed, 7 insertions(+), 11 deletions(-)
diff --git a/include/linux/compiler-clang.h b/include/linux/compiler-clang.h
index d11cad61ba5c..fa9532f8d885 100644
--- a/include/linux/compiler-clang.h
+++ b/include/linux/compiler-clang.h
@@ -41,6 +41,5 @@
* compilers, like ICC.
*/
#define barrier() __asm__ __volatile__("" : : : "memory")
-#define __must_be_array(a) BUILD_BUG_ON_ZERO(__same_type((a), &(a)[0]))
#define __assume_aligned(a, ...) \
__attribute__((__assume_aligned__(a, ## __VA_ARGS__)))
diff --git a/include/linux/compiler-gcc.h b/include/linux/compiler-gcc.h
index 371b6fa2d074..76f4907ef707 100644
--- a/include/linux/compiler-gcc.h
+++ b/include/linux/compiler-gcc.h
@@ -68,13 +68,6 @@
*/
#define uninitialized_var(x) x = x
-#ifdef __CHECKER__
-#define __must_be_array(a) 0
-#else
-/* [0] degrades to a pointer: a different type from an array */
-#define __must_be_array(a) BUILD_BUG_ON_ZERO(__same_type((a), &(a)[0]))
-#endif
-
#ifdef RETPOLINE
#define __noretpoline __attribute__((__indirect_branch__("keep")))
#endif
diff --git a/include/linux/compiler-intel.h b/include/linux/compiler-intel.h
index fef8bb3e53ef..6004b4588bd4 100644
--- a/include/linux/compiler-intel.h
+++ b/include/linux/compiler-intel.h
@@ -29,9 +29,6 @@
*/
#define OPTIMIZER_HIDE_VAR(var) barrier()
-/* Intel ECC compiler doesn't support __builtin_types_compatible_p() */
-#define __must_be_array(a) 0
-
#endif
/* icc has this, but it's called _bswap16 */
diff --git a/include/linux/compiler.h b/include/linux/compiler.h
index ec4a28bad2c6..165b1d5683ed 100644
--- a/include/linux/compiler.h
+++ b/include/linux/compiler.h
@@ -357,4 +357,11 @@ static inline void *offset_to_ptr(const int *off)
compiletime_assert(__native_word(t),\
"Need native word sized stores/loads for atomicity.")
+#ifdef __CHECKER__
+#define __must_be_array(a) 0
+#else
+/* [0] degrades to a pointer: a different type from an array */
+#define __must_be_array(a) BUILD_BUG_ON_ZERO(__same_type((a), &(a)[0]))
+#endif
+
#endif /* __LINUX_COMPILER_H */
--
2.17.1
[PATCH v4 07/13] Compiler Attributes: remove unneeded sparse (__CHECKER__) tests
Sparse knows about a few more attributes now, so we can remove
the __CHECKER__ conditions from them (which, in turn, allow us
to move some of them later on to compiler_attributes.h).
* assume_aligned: since sparse's commit ffc860b ("sparse:
ignore __assume_aligned__ attribute"), included in 0.5.1
* error: since sparse's commit 0a04210 ("sparse: Add 'error'
to ignored attributes"), included in 0.5.0
* hotpatch: since sparse's commit 6043210 ("sparse/parse.c:
ignore hotpatch attribute"), included in 0.5.1
* warning: since sparse's commit 977365d ("Avoid "attribute
'warning': unknown attribute" warning"), included in 0.4.2
On top of that, __must_be_array does not need it either because:
* Even ancient versions of sparse do not have a problem
* BUILD_BUG_ON_ZERO() is currently disabled for __CHECKER__
Cc: Rasmus Villemoes
Cc: Eli Friedman
Cc: Christopher Li
Cc: Kees Cook
Cc: Ingo Molnar
Cc: Geert Uytterhoeven
Cc: Arnd Bergmann
Cc: Greg Kroah-Hartman
Cc: Masahiro Yamada
Cc: Joe Perches
Cc: Dominique Martinet
Cc: Linus Torvalds
Cc: linux-spa...@vger.kernel.org
Acked-by: Luc Van Oostenryck
Reviewed-by: Nick Desaulniers
Signed-off-by: Miguel Ojeda
---
include/linux/compiler-gcc.h | 6 ++
include/linux/compiler.h | 4
include/linux/compiler_types.h | 2 +-
3 files changed, 3 insertions(+), 9 deletions(-)
diff --git a/include/linux/compiler-gcc.h b/include/linux/compiler-gcc.h
index 3b32bbfa5a49..1ca6a51cfaa9 100644
--- a/include/linux/compiler-gcc.h
+++ b/include/linux/compiler-gcc.h
@@ -76,14 +76,12 @@
#define __compiletime_object_size(obj) __builtin_object_size(obj, 0)
-#ifndef __CHECKER__
#define __compiletime_warning(message) __attribute__((__warning__(message)))
#define __compiletime_error(message) __attribute__((__error__(message)))
-#ifdef LATENT_ENTROPY_PLUGIN
+#if defined(LATENT_ENTROPY_PLUGIN) && !defined(__CHECKER__)
#define __latent_entropy __attribute__((latent_entropy))
#endif
-#endif /* __CHECKER__ */
/*
* calling noreturn functions, __builtin_unreachable() and __builtin_trap()
@@ -131,7 +129,7 @@
/* gcc version specific checks */
-#if GCC_VERSION >= 40900 && !defined(__CHECKER__)
+#if GCC_VERSION >= 40900
/*
* __assume_aligned(n, k): Tell the optimizer that the returned
* pointer can be assumed to be k modulo n. The second argument is
diff --git a/include/linux/compiler.h b/include/linux/compiler.h
index 165b1d5683ed..4030a2940d6b 100644
--- a/include/linux/compiler.h
+++ b/include/linux/compiler.h
@@ -357,11 +357,7 @@ static inline void *offset_to_ptr(const int *off)
compiletime_assert(__native_word(t),\
"Need native word sized stores/loads for atomicity.")
-#ifdef __CHECKER__
-#define __must_be_array(a) 0
-#else
/* [0] degrades to a pointer: a different type from an array */
#define __must_be_array(a) BUILD_BUG_ON_ZERO(__same_type((a), &(a)[0]))
-#endif
#endif /* __LINUX_COMPILER_H */
diff --git a/include/linux/compiler_types.h b/include/linux/compiler_types.h
index 5ff9cda893f4..a3eceb3ad1b3 100644
--- a/include/linux/compiler_types.h
+++ b/include/linux/compiler_types.h
@@ -218,7 +218,7 @@ struct ftrace_likely_data {
#define __must_check
#endif
-#if defined(CC_USING_HOTPATCH) && !defined(__CHECKER__)
+#if defined(CC_USING_HOTPATCH)
#define notrace__attribute__((hotpatch(0, 0)))
#else
#define notrace
__attribute__((__no_instrument_function__))
--
2.17.1
[PATCH v4 03/13] Compiler Attributes: remove unneeded tests
Attributes const and always_inline have tests around them
which are unneeded, since they are supported by gcc >= 4.6,
clang >= 3 and icc >= 13. https://godbolt.org/z/DFPq37
In the case of gnu_inline, we do not need to test for
__GNUC_STDC_INLINE__ because, regardless of the current
inlining behavior, we can simply always force the old
GCC inlining behavior by using the attribute in all cases.
Cc: Rasmus Villemoes
Cc: Luc Van Oostenryck
Cc: Eli Friedman
Cc: Christopher Li
Cc: Kees Cook
Cc: Ingo Molnar
Cc: Geert Uytterhoeven
Cc: Arnd Bergmann
Cc: Greg Kroah-Hartman
Cc: Masahiro Yamada
Cc: Joe Perches
Cc: Dominique Martinet
Cc: Linus Torvalds
Cc: linux-spa...@vger.kernel.org
Reviewed-by: Nick Desaulniers
Signed-off-by: Miguel Ojeda
---
include/linux/compiler_types.h | 23 +++
1 file changed, 3 insertions(+), 20 deletions(-)
diff --git a/include/linux/compiler_types.h b/include/linux/compiler_types.h
index 2bc0f94df38e..83475515bc39 100644
--- a/include/linux/compiler_types.h
+++ b/include/linux/compiler_types.h
@@ -158,10 +158,6 @@ struct ftrace_likely_data {
(sizeof(t) == sizeof(char) || sizeof(t) == sizeof(short) || \
sizeof(t) == sizeof(int) || sizeof(t) == sizeof(long))
-#ifndef __attribute_const__
-#define __attribute_const____attribute__((__const__))
-#endif
-
#ifndef __noclone
#define __noclone
#endif
@@ -196,6 +192,7 @@ struct ftrace_likely_data {
* [...]
*/
#define __pure __attribute__((__pure__))
+#define __attribute_const____attribute__((__const__))
#define __aligned(x) __attribute__((__aligned__(x)))
#define __aligned_largest __attribute__((__aligned__))
#define __printf(a, b) __attribute__((__format__(printf, a, b)))
@@ -211,6 +208,8 @@ struct ftrace_likely_data {
#define __alias(symbol)__attribute__((__alias__(#symbol)))
#define __cold __attribute__((__cold__))
#define __section(S) __attribute__((__section__(#S)))
+#define __always_inlineinline
__attribute__((__always_inline__))
+#define __gnu_inline __attribute__((__gnu_inline__))
#ifdef CONFIG_ENABLE_MUST_CHECK
@@ -227,18 +226,6 @@ struct ftrace_likely_data {
#define __compiler_offsetof(a, b) __builtin_offsetof(a, b)
-/*
- * Feature detection for gnu_inline (gnu89 extern inline semantics). Either
- * __GNUC_STDC_INLINE__ is defined (not using gnu89 extern inline semantics,
- * and we opt in to the gnu89 semantics), or __GNUC_STDC_INLINE__ is not
- * defined so the gnu89 semantics are the default.
- */
-#ifdef __GNUC_STDC_INLINE__
-# define __gnu_inline __attribute__((__gnu_inline__))
-#else
-# define __gnu_inline
-#endif
-
/*
* Force always-inline if the user requests it so via the .config.
* GCC does not warn about unused static inline functions for
@@ -263,10 +250,6 @@ struct ftrace_likely_data {
#define __inline inline
#define noinline __attribute__((__noinline__))
-#ifndef __always_inline
-#define __always_inline inline __attribute__((__always_inline__))
-#endif
-
/*
* Rather then using noinline to prevent stack consumption, use
* noinline_for_stack instead. For documentation reasons.
--
2.17.1
[PATCH v4 04/13] Compiler Attributes: homogenize __must_be_array
Different definitions of __must_be_array:
* gcc: disabled for __CHECKER__
* clang: same definition as gcc's, but without __CHECKER__
* intel: the comment claims __builtin_types_compatible_p()
is unsupported; but icc seems to support it since 13.0.1
(released in 2012). See https://godbolt.org/z/S0l6QQ
Therefore, we can remove all of them and have a single definition
in compiler.h
Cc: Rasmus Villemoes
Cc: Luc Van Oostenryck
Cc: Eli Friedman
Cc: Christopher Li
Cc: Kees Cook
Cc: Ingo Molnar
Cc: Geert Uytterhoeven
Cc: Arnd Bergmann
Cc: Greg Kroah-Hartman
Cc: Masahiro Yamada
Cc: Joe Perches
Cc: Dominique Martinet
Cc: Linus Torvalds
Cc: linux-spa...@vger.kernel.org
Reviewed-by: Nick Desaulniers
Signed-off-by: Miguel Ojeda
---
include/linux/compiler-clang.h | 1 -
include/linux/compiler-gcc.h | 7 ---
include/linux/compiler-intel.h | 3 ---
include/linux/compiler.h | 7 +++
4 files changed, 7 insertions(+), 11 deletions(-)
diff --git a/include/linux/compiler-clang.h b/include/linux/compiler-clang.h
index d11cad61ba5c..fa9532f8d885 100644
--- a/include/linux/compiler-clang.h
+++ b/include/linux/compiler-clang.h
@@ -41,6 +41,5 @@
* compilers, like ICC.
*/
#define barrier() __asm__ __volatile__("" : : : "memory")
-#define __must_be_array(a) BUILD_BUG_ON_ZERO(__same_type((a), &(a)[0]))
#define __assume_aligned(a, ...) \
__attribute__((__assume_aligned__(a, ## __VA_ARGS__)))
diff --git a/include/linux/compiler-gcc.h b/include/linux/compiler-gcc.h
index 371b6fa2d074..76f4907ef707 100644
--- a/include/linux/compiler-gcc.h
+++ b/include/linux/compiler-gcc.h
@@ -68,13 +68,6 @@
*/
#define uninitialized_var(x) x = x
-#ifdef __CHECKER__
-#define __must_be_array(a) 0
-#else
-/* [0] degrades to a pointer: a different type from an array */
-#define __must_be_array(a) BUILD_BUG_ON_ZERO(__same_type((a), &(a)[0]))
-#endif
-
#ifdef RETPOLINE
#define __noretpoline __attribute__((__indirect_branch__("keep")))
#endif
diff --git a/include/linux/compiler-intel.h b/include/linux/compiler-intel.h
index fef8bb3e53ef..6004b4588bd4 100644
--- a/include/linux/compiler-intel.h
+++ b/include/linux/compiler-intel.h
@@ -29,9 +29,6 @@
*/
#define OPTIMIZER_HIDE_VAR(var) barrier()
-/* Intel ECC compiler doesn't support __builtin_types_compatible_p() */
-#define __must_be_array(a) 0
-
#endif
/* icc has this, but it's called _bswap16 */
diff --git a/include/linux/compiler.h b/include/linux/compiler.h
index ec4a28bad2c6..165b1d5683ed 100644
--- a/include/linux/compiler.h
+++ b/include/linux/compiler.h
@@ -357,4 +357,11 @@ static inline void *offset_to_ptr(const int *off)
compiletime_assert(__native_word(t),\
"Need native word sized stores/loads for atomicity.")
+#ifdef __CHECKER__
+#define __must_be_array(a) 0
+#else
+/* [0] degrades to a pointer: a different type from an array */
+#define __must_be_array(a) BUILD_BUG_ON_ZERO(__same_type((a), &(a)[0]))
+#endif
+
#endif /* __LINUX_COMPILER_H */
--
2.17.1
[PATCH v4 07/13] Compiler Attributes: remove unneeded sparse (__CHECKER__) tests
Sparse knows about a few more attributes now, so we can remove
the __CHECKER__ conditions from them (which, in turn, allow us
to move some of them later on to compiler_attributes.h).
* assume_aligned: since sparse's commit ffc860b ("sparse:
ignore __assume_aligned__ attribute"), included in 0.5.1
* error: since sparse's commit 0a04210 ("sparse: Add 'error'
to ignored attributes"), included in 0.5.0
* hotpatch: since sparse's commit 6043210 ("sparse/parse.c:
ignore hotpatch attribute"), included in 0.5.1
* warning: since sparse's commit 977365d ("Avoid "attribute
'warning': unknown attribute" warning"), included in 0.4.2
On top of that, __must_be_array does not need it either because:
* Even ancient versions of sparse do not have a problem
* BUILD_BUG_ON_ZERO() is currently disabled for __CHECKER__
Cc: Rasmus Villemoes
Cc: Eli Friedman
Cc: Christopher Li
Cc: Kees Cook
Cc: Ingo Molnar
Cc: Geert Uytterhoeven
Cc: Arnd Bergmann
Cc: Greg Kroah-Hartman
Cc: Masahiro Yamada
Cc: Joe Perches
Cc: Dominique Martinet
Cc: Linus Torvalds
Cc: linux-spa...@vger.kernel.org
Acked-by: Luc Van Oostenryck
Reviewed-by: Nick Desaulniers
Signed-off-by: Miguel Ojeda
---
include/linux/compiler-gcc.h | 6 ++
include/linux/compiler.h | 4
include/linux/compiler_types.h | 2 +-
3 files changed, 3 insertions(+), 9 deletions(-)
diff --git a/include/linux/compiler-gcc.h b/include/linux/compiler-gcc.h
index 3b32bbfa5a49..1ca6a51cfaa9 100644
--- a/include/linux/compiler-gcc.h
+++ b/include/linux/compiler-gcc.h
@@ -76,14 +76,12 @@
#define __compiletime_object_size(obj) __builtin_object_size(obj, 0)
-#ifndef __CHECKER__
#define __compiletime_warning(message) __attribute__((__warning__(message)))
#define __compiletime_error(message) __attribute__((__error__(message)))
-#ifdef LATENT_ENTROPY_PLUGIN
+#if defined(LATENT_ENTROPY_PLUGIN) && !defined(__CHECKER__)
#define __latent_entropy __attribute__((latent_entropy))
#endif
-#endif /* __CHECKER__ */
/*
* calling noreturn functions, __builtin_unreachable() and __builtin_trap()
@@ -131,7 +129,7 @@
/* gcc version specific checks */
-#if GCC_VERSION >= 40900 && !defined(__CHECKER__)
+#if GCC_VERSION >= 40900
/*
* __assume_aligned(n, k): Tell the optimizer that the returned
* pointer can be assumed to be k modulo n. The second argument is
diff --git a/include/linux/compiler.h b/include/linux/compiler.h
index 165b1d5683ed..4030a2940d6b 100644
--- a/include/linux/compiler.h
+++ b/include/linux/compiler.h
@@ -357,11 +357,7 @@ static inline void *offset_to_ptr(const int *off)
compiletime_assert(__native_word(t),\
"Need native word sized stores/loads for atomicity.")
-#ifdef __CHECKER__
-#define __must_be_array(a) 0
-#else
/* [0] degrades to a pointer: a different type from an array */
#define __must_be_array(a) BUILD_BUG_ON_ZERO(__same_type((a), &(a)[0]))
-#endif
#endif /* __LINUX_COMPILER_H */
diff --git a/include/linux/compiler_types.h b/include/linux/compiler_types.h
index 5ff9cda893f4..a3eceb3ad1b3 100644
--- a/include/linux/compiler_types.h
+++ b/include/linux/compiler_types.h
@@ -218,7 +218,7 @@ struct ftrace_likely_data {
#define __must_check
#endif
-#if defined(CC_USING_HOTPATCH) && !defined(__CHECKER__)
+#if defined(CC_USING_HOTPATCH)
#define notrace__attribute__((hotpatch(0, 0)))
#else
#define notrace
__attribute__((__no_instrument_function__))
--
2.17.1
[PATCH v4 03/13] Compiler Attributes: remove unneeded tests
Attributes const and always_inline have tests around them
which are unneeded, since they are supported by gcc >= 4.6,
clang >= 3 and icc >= 13. https://godbolt.org/z/DFPq37
In the case of gnu_inline, we do not need to test for
__GNUC_STDC_INLINE__ because, regardless of the current
inlining behavior, we can simply always force the old
GCC inlining behavior by using the attribute in all cases.
Cc: Rasmus Villemoes
Cc: Luc Van Oostenryck
Cc: Eli Friedman
Cc: Christopher Li
Cc: Kees Cook
Cc: Ingo Molnar
Cc: Geert Uytterhoeven
Cc: Arnd Bergmann
Cc: Greg Kroah-Hartman
Cc: Masahiro Yamada
Cc: Joe Perches
Cc: Dominique Martinet
Cc: Linus Torvalds
Cc: linux-spa...@vger.kernel.org
Reviewed-by: Nick Desaulniers
Signed-off-by: Miguel Ojeda
---
include/linux/compiler_types.h | 23 +++
1 file changed, 3 insertions(+), 20 deletions(-)
diff --git a/include/linux/compiler_types.h b/include/linux/compiler_types.h
index 2bc0f94df38e..83475515bc39 100644
--- a/include/linux/compiler_types.h
+++ b/include/linux/compiler_types.h
@@ -158,10 +158,6 @@ struct ftrace_likely_data {
(sizeof(t) == sizeof(char) || sizeof(t) == sizeof(short) || \
sizeof(t) == sizeof(int) || sizeof(t) == sizeof(long))
-#ifndef __attribute_const__
-#define __attribute_const____attribute__((__const__))
-#endif
-
#ifndef __noclone
#define __noclone
#endif
@@ -196,6 +192,7 @@ struct ftrace_likely_data {
* [...]
*/
#define __pure __attribute__((__pure__))
+#define __attribute_const____attribute__((__const__))
#define __aligned(x) __attribute__((__aligned__(x)))
#define __aligned_largest __attribute__((__aligned__))
#define __printf(a, b) __attribute__((__format__(printf, a, b)))
@@ -211,6 +208,8 @@ struct ftrace_likely_data {
#define __alias(symbol)__attribute__((__alias__(#symbol)))
#define __cold __attribute__((__cold__))
#define __section(S) __attribute__((__section__(#S)))
+#define __always_inlineinline
__attribute__((__always_inline__))
+#define __gnu_inline __attribute__((__gnu_inline__))
#ifdef CONFIG_ENABLE_MUST_CHECK
@@ -227,18 +226,6 @@ struct ftrace_likely_data {
#define __compiler_offsetof(a, b) __builtin_offsetof(a, b)
-/*
- * Feature detection for gnu_inline (gnu89 extern inline semantics). Either
- * __GNUC_STDC_INLINE__ is defined (not using gnu89 extern inline semantics,
- * and we opt in to the gnu89 semantics), or __GNUC_STDC_INLINE__ is not
- * defined so the gnu89 semantics are the default.
- */
-#ifdef __GNUC_STDC_INLINE__
-# define __gnu_inline __attribute__((__gnu_inline__))
-#else
-# define __gnu_inline
-#endif
-
/*
* Force always-inline if the user requests it so via the .config.
* GCC does not warn about unused static inline functions for
@@ -263,10 +250,6 @@ struct ftrace_likely_data {
#define __inline inline
#define noinline __attribute__((__noinline__))
-#ifndef __always_inline
-#define __always_inline inline __attribute__((__always_inline__))
-#endif
-
/*
* Rather then using noinline to prevent stack consumption, use
* noinline_for_stack instead. For documentation reasons.
--
2.17.1
[PATCH v4 09/13] Compiler Attributes: use feature checks instead of version checks
Instead of using version checks per-compiler to define (or not)
each attribute, use __has_attribute to test for them, following
the cleanup started with commit 815f0ddb346c
("include/linux/compiler*.h: make compiler-*.h mutually exclusive"),
which is supported on gcc >= 5, clang >= 2.9 and icc >= 17.
In the meantime, to support 4.6 <= gcc < 5, we implement
__has_attribute by hand.
All the attributes that can be unconditionally defined and directly
map to compiler attribute(s) (even if optional) have been moved
to a new file include/linux/compiler_attributes.h
In an effort to make the file as regular as possible, comments
stating the purpose of attributes have been removed. Instead,
links to the compiler docs have been added (i.e. to gcc and,
if available, to clang as well). In addition, they have been sorted.
Finally, if an attribute is optional (i.e. if it is guarded
by __has_attribute), the reason has been stated for future reference.
Cc: Rasmus Villemoes
Cc: Eli Friedman
Cc: Christopher Li
Cc: Kees Cook
Cc: Ingo Molnar
Cc: Geert Uytterhoeven
Cc: Arnd Bergmann
Cc: Greg Kroah-Hartman
Cc: Masahiro Yamada
Cc: Joe Perches
Cc: Dominique Martinet
Cc: Nick Desaulniers
Cc: Linus Torvalds
Cc: linux-spa...@vger.kernel.org
Reviewed-by: Luc Van Oostenryck
Signed-off-by: Miguel Ojeda
---
include/linux/compiler-clang.h | 4 -
include/linux/compiler-gcc.h| 51 --
include/linux/compiler-intel.h | 6 -
include/linux/compiler_attributes.h | 244
include/linux/compiler_types.h | 74 ++---
5 files changed, 254 insertions(+), 125 deletions(-)
create mode 100644 include/linux/compiler_attributes.h
diff --git a/include/linux/compiler-clang.h b/include/linux/compiler-clang.h
index fa9532f8d885..3e7dafb3ea80 100644
--- a/include/linux/compiler-clang.h
+++ b/include/linux/compiler-clang.h
@@ -21,8 +21,6 @@
#define __SANITIZE_ADDRESS__
#endif
-#define __no_sanitize_address __attribute__((__no_sanitize__("address")))
-
/*
* Not all versions of clang implement the the type-generic versions
* of the builtin overflow checkers. Fortunately, clang implements
@@ -41,5 +39,3 @@
* compilers, like ICC.
*/
#define barrier() __asm__ __volatile__("" : : : "memory")
-#define __assume_aligned(a, ...) \
- __attribute__((__assume_aligned__(a, ## __VA_ARGS__)))
diff --git a/include/linux/compiler-gcc.h b/include/linux/compiler-gcc.h
index 1ca6a51cfaa9..cfac027e1625 100644
--- a/include/linux/compiler-gcc.h
+++ b/include/linux/compiler-gcc.h
@@ -108,9 +108,6 @@
__builtin_unreachable();\
} while (0)
-/* Mark a function definition as prohibited from being cloned. */
-#define __noclone __attribute__((__noclone__, __optimize__("no-tracer")))
-
#if defined(RANDSTRUCT_PLUGIN) && !defined(__CHECKER__)
#define __randomize_layout __attribute__((randomize_layout))
#define __no_randomize_layout __attribute__((no_randomize_layout))
@@ -119,32 +116,6 @@
#define randomized_struct_fields_end } __randomize_layout;
#endif
-/*
- * When used with Link Time Optimization, gcc can optimize away C functions or
- * variables which are referenced only from assembly code. __visible tells the
- * optimizer that something else uses this function or variable, thus
preventing
- * this.
- */
-#define __visible __attribute__((__externally_visible__))
-
-/* gcc version specific checks */
-
-#if GCC_VERSION >= 40900
-/*
- * __assume_aligned(n, k): Tell the optimizer that the returned
- * pointer can be assumed to be k modulo n. The second argument is
- * optional (default 0), so we use a variadic macro to make the
- * shorthand.
- *
- * Beware: Do not apply this to functions which may return
- * ERR_PTRs. Also, it is probably unwise to apply it to functions
- * returning extra information in the low bits (but in that case the
- * compiler should see some alignment anyway, when the return value is
- * massaged by 'flags = ptr & 3; ptr &= ~3;').
- */
-#define __assume_aligned(a, ...) __attribute__((__assume_aligned__(a, ##
__VA_ARGS__)))
-#endif
-
/*
* GCC 'asm goto' miscompiles certain code sequences:
*
@@ -176,32 +147,10 @@
#define KASAN_ABI_VERSION 3
#endif
-#if GCC_VERSION >= 40902
-/*
- * Tell the compiler that address safety instrumentation (KASAN)
- * should not be applied to that function.
- * Conflicts with inlining: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67368
- */
-#define __no_sanitize_address __attribute__((__no_sanitize_address__))
-#endif
-
#if GCC_VERSION >= 50100
-/*
- * Mark structures as requiring designated initializers.
- * https://gcc.gnu.org/onlinedocs/gcc/Designated-Inits.html
- */
-#define __designated_init __attribute__((__designated_init__))
#define COMPILER_HAS_GENERIC_BUILTIN_OVERFLOW 1
#endif
-#if !defined(__noclone)
-#define __noclone /* not needed */
-#endif
-
-#if !defined(__no_sanitize_address)
-#define __no_sanitize_address
-#endif
-
/*
* Turn individual
[PATCH v4 00/13] Compiler Attributes
The Compiler Attributes series is an effort to disentangle the include/linux/compiler*.h headers and bring them up to date. The main idea behind the series is to use feature checking macros (i.e. __has_attribute) instead of compiler version checks (e.g. GCC_VERSION), which are compiler-agnostic (so they can be shared, reducing the size of compiler-specific headers) and version-agnostic. Other related improvements have been performed in the headers as well, which on top of the use of __has_attribute it has amounted to a significant simplification of these headers (e.g. GCC_VERSION is now only guarding 4 non-attribute macros). This series should also help the efforts to support compiling the kernel with clang and icc. A fair amount of documentation and comments have also been added, clarified or removed; and the headers are now more readable, which should help kernel developers in general. The series was triggered due to the move to gcc >= 4.6. In turn, this series has also triggered Sparse to gain the ability to recognize __has_attribute on its own. You can also fetch it from: https://github.com/ojeda/linux/tree/compiler-attributes-v4 Enjoy! Cheers, Miguel Cc: Jonathan Corbet Cc: Rasmus Villemoes Cc: Luc Van Oostenryck Cc: Eli Friedman Cc: Christopher Li Cc: Kees Cook Cc: Ingo Molnar Cc: Geert Uytterhoeven Cc: Arnd Bergmann Cc: Greg Kroah-Hartman Cc: Masahiro Yamada Cc: Joe Perches Cc: Dominique Martinet Cc: Nick Desaulniers Cc: Linus Torvalds Cc: linux-spa...@vger.kernel.org Cc: linux-...@vger.kernel.org Signed-off-by: Miguel Ojeda v3 -> v4 This time it is an important fix I found while doing randconfigs, plus the documentation sentence that Nick suggested and the MAINTAINERS file. Compile-tested for a while on (x86_64, gcc-7.3) on a few randconfs. New: * Add MAINTAINERS entry for the new file (compiler_attributes.h) so that we try to maintain that one as clean as possible. (if someone else wants to join, feel free!) Modified: * Fix inline macro __always_inline cannot be used in the inline macro, because people marking a function as __always_inline would expand to inline which in turn would expand back to __always_inline (under some configs), which would not be expanded again. Added a comment about this in the inline macro. Also added another comment about __always_inline in compiler_attributes.h to note that users expect to not have to write inline (as well as the attribute). We cannot simply remove "inline" there (which would solve the problem described above) because using the attribute is not enough for gcc. A function marked as always_inline seems to require to be marked as inline itself so that the attribute is applied: "warning: always_inline function might not be inlinable [-Wattributes]" From the gcc docs: "For functions declared inline, this attribute inlines the function independent of any restrictions that otherwise apply to inlining." See https://godbolt.org/z/LpzUPj for an example. From reviews: * Add sentence about feature-detection in Docs (Nick) Miguel Ojeda (13): Compiler Attributes: remove unused attributes Compiler Attributes: always use the extra-underscores syntax Compiler Attributes: remove unneeded tests Compiler Attributes: homogenize __must_be_array Compiler Attributes: naked was fixed in gcc 4.6 Compiler Attributes: naked can be shared Compiler Attributes: remove unneeded sparse (__CHECKER__) tests Compiler Attributes: add missing SPDX ID in compiler_types.h Compiler Attributes: use feature checks instead of version checks Compiler Attributes: KENTRY used twice the "used" attribute Compiler Attributes: remove uses of __attribute__ from compiler.h Compiler Attributes: add Doc/process/programming-language.rst Compiler Attributes: Add MAINTAINERS entry Documentation/process/index.rst | 1 + .../process/programming-language.rst | 45 MAINTAINERS | 5 + include/linux/compiler-clang.h| 5 - include/linux/compiler-gcc.h | 84 +- include/linux/compiler-intel.h| 9 - include/linux/compiler.h | 19 +- include/linux/compiler_attributes.h | 244 ++ include/linux/compiler_types.h| 105 ++-- 9 files changed, 329 insertions(+), 188 deletions(-) create mode 100644 Documentation/process/programming-language.rst create mode 100644 include/linux/compiler_attributes.h -- 2.17.1
[PATCH v4 08/13] Compiler Attributes: add missing SPDX ID in compiler_types.h
Cc: Rasmus Villemoes Cc: Luc Van Oostenryck Cc: Eli Friedman Cc: Christopher Li Cc: Kees Cook Cc: Ingo Molnar Cc: Geert Uytterhoeven Cc: Arnd Bergmann Cc: Greg Kroah-Hartman Cc: Masahiro Yamada Cc: Joe Perches Cc: Dominique Martinet Cc: Nick Desaulniers Cc: Linus Torvalds Cc: linux-spa...@vger.kernel.org Signed-off-by: Miguel Ojeda --- include/linux/compiler_types.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/linux/compiler_types.h b/include/linux/compiler_types.h index a3eceb3ad1b3..ed7c0e4a180e 100644 --- a/include/linux/compiler_types.h +++ b/include/linux/compiler_types.h @@ -1,3 +1,4 @@ +/* SPDX-License-Identifier: GPL-2.0 */ #ifndef __LINUX_COMPILER_TYPES_H #define __LINUX_COMPILER_TYPES_H -- 2.17.1
[PATCH v4 13/13] Compiler Attributes: Add MAINTAINERS entry
Cc: Eli Friedman Cc: Christopher Li Cc: Kees Cook Cc: Ingo Molnar Cc: Geert Uytterhoeven Cc: Arnd Bergmann Cc: Greg Kroah-Hartman Cc: Masahiro Yamada Cc: Joe Perches Cc: Dominique Martinet Cc: Nick Desaulniers Cc: Linus Torvalds Signed-off-by: Miguel Ojeda --- MAINTAINERS | 5 + 1 file changed, 5 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 9ad052aeac39..a7ef76d694d4 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -3721,6 +3721,11 @@ L: platform-driver-...@vger.kernel.org S: Maintained F: drivers/platform/x86/compal-laptop.c +COMPILER ATTRIBUTES +M: Miguel Ojeda +S: Maintained +F: include/linux/compiler_attributes.h + CONEXANT ACCESSRUNNER USB DRIVER L: accessrunner-gene...@lists.sourceforge.net W: http://accessrunner.sourceforge.net/ -- 2.17.1
[PATCH v4 02/13] Compiler Attributes: always use the extra-underscores syntax
The attribute syntax optionally allows to surround attribute names
with "__" in order to avoid collisions with macros of the same name
(see https://gcc.gnu.org/onlinedocs/gcc/Attribute-Syntax.html).
This homogenizes all attributes to use the syntax with underscores.
While there are currently only a handful of cases of some TUs defining
macros like "error" which may collide with the attributes,
this should prevent futures surprises.
This has been done only for "standard" attributes supported by
the major compilers. In other words, those of third-party tools
(e.g. sparse, plugins...) have not been changed for the moment.
Cc: Rasmus Villemoes
Cc: Luc Van Oostenryck
Cc: Eli Friedman
Cc: Christopher Li
Cc: Kees Cook
Cc: Ingo Molnar
Cc: Geert Uytterhoeven
Cc: Arnd Bergmann
Cc: Greg Kroah-Hartman
Cc: Masahiro Yamada
Cc: Joe Perches
Cc: Dominique Martinet
Cc: Linus Torvalds
Cc: linux-spa...@vger.kernel.org
Reviewed-by: Nick Desaulniers
Signed-off-by: Miguel Ojeda
---
include/linux/compiler-clang.h | 2 +-
include/linux/compiler-gcc.h | 14 ++--
include/linux/compiler-intel.h | 2 +-
include/linux/compiler.h | 8 +++
include/linux/compiler_types.h | 40 +-
5 files changed, 33 insertions(+), 33 deletions(-)
diff --git a/include/linux/compiler-clang.h b/include/linux/compiler-clang.h
index b1ce500fe8b3..d11cad61ba5c 100644
--- a/include/linux/compiler-clang.h
+++ b/include/linux/compiler-clang.h
@@ -21,7 +21,7 @@
#define __SANITIZE_ADDRESS__
#endif
-#define __no_sanitize_address __attribute__((no_sanitize("address")))
+#define __no_sanitize_address __attribute__((__no_sanitize__("address")))
/*
* Not all versions of clang implement the the type-generic versions
diff --git a/include/linux/compiler-gcc.h b/include/linux/compiler-gcc.h
index 0a2d06677d83..371b6fa2d074 100644
--- a/include/linux/compiler-gcc.h
+++ b/include/linux/compiler-gcc.h
@@ -76,7 +76,7 @@
#endif
#ifdef RETPOLINE
-#define __noretpoline __attribute__((indirect_branch("keep")))
+#define __noretpoline __attribute__((__indirect_branch__("keep")))
#endif
/*
@@ -91,15 +91,15 @@
* GCC 4.[56] currently fail to enforce this, so we must do so ourselves.
* See GCC PR44290.
*/
-#define __naked__attribute__((naked)) noinline __noclone
notrace
+#define __naked__attribute__((__naked__)) noinline __noclone
notrace
#define __UNIQUE_ID(prefix) __PASTE(__PASTE(__UNIQUE_ID_, prefix), __COUNTER__)
#define __compiletime_object_size(obj) __builtin_object_size(obj, 0)
#ifndef __CHECKER__
-#define __compiletime_warning(message) __attribute__((warning(message)))
-#define __compiletime_error(message) __attribute__((error(message)))
+#define __compiletime_warning(message) __attribute__((__warning__(message)))
+#define __compiletime_error(message) __attribute__((__error__(message)))
#ifdef LATENT_ENTROPY_PLUGIN
#define __latent_entropy __attribute__((latent_entropy))
@@ -148,7 +148,7 @@
* optimizer that something else uses this function or variable, thus
preventing
* this.
*/
-#define __visible __attribute__((externally_visible))
+#define __visible __attribute__((__externally_visible__))
/* gcc version specific checks */
@@ -205,7 +205,7 @@
* should not be applied to that function.
* Conflicts with inlining: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67368
*/
-#define __no_sanitize_address __attribute__((no_sanitize_address))
+#define __no_sanitize_address __attribute__((__no_sanitize_address__))
#endif
#if GCC_VERSION >= 50100
@@ -213,7 +213,7 @@
* Mark structures as requiring designated initializers.
* https://gcc.gnu.org/onlinedocs/gcc/Designated-Inits.html
*/
-#define __designated_init __attribute__((designated_init))
+#define __designated_init __attribute__((__designated_init__))
#define COMPILER_HAS_GENERIC_BUILTIN_OVERFLOW 1
#endif
diff --git a/include/linux/compiler-intel.h b/include/linux/compiler-intel.h
index 4c7f9befa9f6..fef8bb3e53ef 100644
--- a/include/linux/compiler-intel.h
+++ b/include/linux/compiler-intel.h
@@ -42,4 +42,4 @@
* and may be redefined here because they should not be shared with other
* compilers, like clang.
*/
-#define __visible __attribute__((externally_visible))
+#define __visible __attribute__((__externally_visible__))
diff --git a/include/linux/compiler.h b/include/linux/compiler.h
index 7c0157d50964..ec4a28bad2c6 100644
--- a/include/linux/compiler.h
+++ b/include/linux/compiler.h
@@ -24,7 +24,7 @@ void ftrace_likely_update(struct ftrace_likely_data *f, int
val,
long __r; \
static struct ftrace_likely_data\
__attribute__((__aligned__(4))) \
-
__attribute__((section("_ftrace_annotated_branch"))) \
+
[PATCH v4 01/13] Compiler Attributes: remove unused attributes
__optimize and __deprecate_for_modules are unused in
the whole kernel tree. Simply drop them.
Cc: Rasmus Villemoes
Cc: Luc Van Oostenryck
Cc: Eli Friedman
Cc: Christopher Li
Cc: Kees Cook
Cc: Ingo Molnar
Cc: Geert Uytterhoeven
Cc: Arnd Bergmann
Cc: Greg Kroah-Hartman
Cc: Masahiro Yamada
Cc: Joe Perches
Cc: Dominique Martinet
Cc: Linus Torvalds
Cc: linux-spa...@vger.kernel.org
Reviewed-by: Nick Desaulniers
Signed-off-by: Miguel Ojeda
---
include/linux/compiler-gcc.h | 2 --
include/linux/compiler.h | 4
include/linux/compiler_types.h | 1 -
3 files changed, 7 deletions(-)
diff --git a/include/linux/compiler-gcc.h b/include/linux/compiler-gcc.h
index 763bbad1e258..0a2d06677d83 100644
--- a/include/linux/compiler-gcc.h
+++ b/include/linux/compiler-gcc.h
@@ -95,8 +95,6 @@
#define __UNIQUE_ID(prefix) __PASTE(__PASTE(__UNIQUE_ID_, prefix), __COUNTER__)
-#define __optimize(level) __attribute__((__optimize__(level)))
-
#define __compiletime_object_size(obj) __builtin_object_size(obj, 0)
#ifndef __CHECKER__
diff --git a/include/linux/compiler.h b/include/linux/compiler.h
index 681d866efb1e..7c0157d50964 100644
--- a/include/linux/compiler.h
+++ b/include/linux/compiler.h
@@ -301,10 +301,6 @@ static inline void *offset_to_ptr(const int *off)
#endif /* __ASSEMBLY__ */
-#ifndef __optimize
-# define __optimize(level)
-#endif
-
/* Compile time object size, -1 for unknown */
#ifndef __compiletime_object_size
# define __compiletime_object_size(obj) -1
diff --git a/include/linux/compiler_types.h b/include/linux/compiler_types.h
index 3525c179698c..b6534292ea33 100644
--- a/include/linux/compiler_types.h
+++ b/include/linux/compiler_types.h
@@ -108,7 +108,6 @@ struct ftrace_likely_data {
/* Don't. Just don't. */
#define __deprecated
-#define __deprecated_for_modules
#endif /* __KERNEL__ */
--
2.17.1
[PATCH v4 12/13] Compiler Attributes: add Doc/process/programming-language.rst
Cc: Jonathan Corbet Cc: Rasmus Villemoes Cc: Luc Van Oostenryck Cc: Eli Friedman Cc: Christopher Li Cc: Kees Cook Cc: Ingo Molnar Cc: Geert Uytterhoeven Cc: Arnd Bergmann Cc: Greg Kroah-Hartman Cc: Masahiro Yamada Cc: Joe Perches Cc: Dominique Martinet Cc: Nick Desaulniers Cc: Linus Torvalds Cc: linux-spa...@vger.kernel.org Cc: linux-...@vger.kernel.org Signed-off-by: Miguel Ojeda --- Documentation/process/index.rst | 1 + .../process/programming-language.rst | 45 +++ 2 files changed, 46 insertions(+) create mode 100644 Documentation/process/programming-language.rst diff --git a/Documentation/process/index.rst b/Documentation/process/index.rst index 37bd0628b6ee..c56f24a22d2a 100644 --- a/Documentation/process/index.rst +++ b/Documentation/process/index.rst @@ -23,6 +23,7 @@ Below are the essential guides that every developer should read. code-of-conflict development-process submitting-patches + programming-language coding-style maintainer-pgp-guide email-clients diff --git a/Documentation/process/programming-language.rst b/Documentation/process/programming-language.rst new file mode 100644 index ..e5f5f065dc24 --- /dev/null +++ b/Documentation/process/programming-language.rst @@ -0,0 +1,45 @@ +.. _programming_language: + +Programming Language + + +The kernel is written in the C programming language [c-language]_. +More precisely, the kernel is typically compiled with ``gcc`` [gcc]_ +under ``-std=gnu89`` [gcc-c-dialect-options]_: the GNU dialect of ISO C90 +(including some C99 features). + +This dialect contains many extensions to the language [gnu-extensions]_, +and many of them are used within the kernel as a matter of course. + +There is some support for compiling the kernel with ``clang`` [clang]_ +and ``icc`` [icc]_ for several of the architectures, although at the time +of writing it is not completed, requiring third-party patches. + +Attributes +-- + +One of the common extensions used throughout the kernel are attributes +[gcc-attribute-syntax]_. Attributes allow to introduce +implementation-defined semantics to language entities (like variables, +functions or types) without having to make significant syntactic changes +to the language (e.g. adding a new keyword) [n2049]_. + +In some cases, attributes are optional (i.e. a compiler not supporting them +should still produce proper code, even if it is slower or does not perform +as many compile-time checks/diagnostics). + +The kernel defines pseudo-keywords (e.g. ``__pure``) instead of using +directly the GNU attribute syntax (e.g. ``__attribute__((__pure__))``) +in order to feature detect which ones can be used and/or to shorten the code. + +Please refer to ``include/linux/compiler_attributes.h`` for more information. + +.. [c-language] http://www.open-std.org/jtc1/sc22/wg14/www/standards +.. [gcc] https://gcc.gnu.org +.. [clang] https://clang.llvm.org +.. [icc] https://software.intel.com/en-us/c-compilers +.. [gcc-c-dialect-options] https://gcc.gnu.org/onlinedocs/gcc/C-Dialect-Options.html +.. [gnu-extensions] https://gcc.gnu.org/onlinedocs/gcc/C-Extensions.html +.. [gcc-attribute-syntax] https://gcc.gnu.org/onlinedocs/gcc/Attribute-Syntax.html +.. [n2049] http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2049.pdf + -- 2.17.1
[PATCH v4 09/13] Compiler Attributes: use feature checks instead of version checks
Instead of using version checks per-compiler to define (or not)
each attribute, use __has_attribute to test for them, following
the cleanup started with commit 815f0ddb346c
("include/linux/compiler*.h: make compiler-*.h mutually exclusive"),
which is supported on gcc >= 5, clang >= 2.9 and icc >= 17.
In the meantime, to support 4.6 <= gcc < 5, we implement
__has_attribute by hand.
All the attributes that can be unconditionally defined and directly
map to compiler attribute(s) (even if optional) have been moved
to a new file include/linux/compiler_attributes.h
In an effort to make the file as regular as possible, comments
stating the purpose of attributes have been removed. Instead,
links to the compiler docs have been added (i.e. to gcc and,
if available, to clang as well). In addition, they have been sorted.
Finally, if an attribute is optional (i.e. if it is guarded
by __has_attribute), the reason has been stated for future reference.
Cc: Rasmus Villemoes
Cc: Eli Friedman
Cc: Christopher Li
Cc: Kees Cook
Cc: Ingo Molnar
Cc: Geert Uytterhoeven
Cc: Arnd Bergmann
Cc: Greg Kroah-Hartman
Cc: Masahiro Yamada
Cc: Joe Perches
Cc: Dominique Martinet
Cc: Nick Desaulniers
Cc: Linus Torvalds
Cc: linux-spa...@vger.kernel.org
Reviewed-by: Luc Van Oostenryck
Signed-off-by: Miguel Ojeda
---
include/linux/compiler-clang.h | 4 -
include/linux/compiler-gcc.h| 51 --
include/linux/compiler-intel.h | 6 -
include/linux/compiler_attributes.h | 244
include/linux/compiler_types.h | 74 ++---
5 files changed, 254 insertions(+), 125 deletions(-)
create mode 100644 include/linux/compiler_attributes.h
diff --git a/include/linux/compiler-clang.h b/include/linux/compiler-clang.h
index fa9532f8d885..3e7dafb3ea80 100644
--- a/include/linux/compiler-clang.h
+++ b/include/linux/compiler-clang.h
@@ -21,8 +21,6 @@
#define __SANITIZE_ADDRESS__
#endif
-#define __no_sanitize_address __attribute__((__no_sanitize__("address")))
-
/*
* Not all versions of clang implement the the type-generic versions
* of the builtin overflow checkers. Fortunately, clang implements
@@ -41,5 +39,3 @@
* compilers, like ICC.
*/
#define barrier() __asm__ __volatile__("" : : : "memory")
-#define __assume_aligned(a, ...) \
- __attribute__((__assume_aligned__(a, ## __VA_ARGS__)))
diff --git a/include/linux/compiler-gcc.h b/include/linux/compiler-gcc.h
index 1ca6a51cfaa9..cfac027e1625 100644
--- a/include/linux/compiler-gcc.h
+++ b/include/linux/compiler-gcc.h
@@ -108,9 +108,6 @@
__builtin_unreachable();\
} while (0)
-/* Mark a function definition as prohibited from being cloned. */
-#define __noclone __attribute__((__noclone__, __optimize__("no-tracer")))
-
#if defined(RANDSTRUCT_PLUGIN) && !defined(__CHECKER__)
#define __randomize_layout __attribute__((randomize_layout))
#define __no_randomize_layout __attribute__((no_randomize_layout))
@@ -119,32 +116,6 @@
#define randomized_struct_fields_end } __randomize_layout;
#endif
-/*
- * When used with Link Time Optimization, gcc can optimize away C functions or
- * variables which are referenced only from assembly code. __visible tells the
- * optimizer that something else uses this function or variable, thus
preventing
- * this.
- */
-#define __visible __attribute__((__externally_visible__))
-
-/* gcc version specific checks */
-
-#if GCC_VERSION >= 40900
-/*
- * __assume_aligned(n, k): Tell the optimizer that the returned
- * pointer can be assumed to be k modulo n. The second argument is
- * optional (default 0), so we use a variadic macro to make the
- * shorthand.
- *
- * Beware: Do not apply this to functions which may return
- * ERR_PTRs. Also, it is probably unwise to apply it to functions
- * returning extra information in the low bits (but in that case the
- * compiler should see some alignment anyway, when the return value is
- * massaged by 'flags = ptr & 3; ptr &= ~3;').
- */
-#define __assume_aligned(a, ...) __attribute__((__assume_aligned__(a, ##
__VA_ARGS__)))
-#endif
-
/*
* GCC 'asm goto' miscompiles certain code sequences:
*
@@ -176,32 +147,10 @@
#define KASAN_ABI_VERSION 3
#endif
-#if GCC_VERSION >= 40902
-/*
- * Tell the compiler that address safety instrumentation (KASAN)
- * should not be applied to that function.
- * Conflicts with inlining: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67368
- */
-#define __no_sanitize_address __attribute__((__no_sanitize_address__))
-#endif
-
#if GCC_VERSION >= 50100
-/*
- * Mark structures as requiring designated initializers.
- * https://gcc.gnu.org/onlinedocs/gcc/Designated-Inits.html
- */
-#define __designated_init __attribute__((__designated_init__))
#define COMPILER_HAS_GENERIC_BUILTIN_OVERFLOW 1
#endif
-#if !defined(__noclone)
-#define __noclone /* not needed */
-#endif
-
-#if !defined(__no_sanitize_address)
-#define __no_sanitize_address
-#endif
-
/*
* Turn individual
[PATCH v4 00/13] Compiler Attributes
The Compiler Attributes series is an effort to disentangle the include/linux/compiler*.h headers and bring them up to date. The main idea behind the series is to use feature checking macros (i.e. __has_attribute) instead of compiler version checks (e.g. GCC_VERSION), which are compiler-agnostic (so they can be shared, reducing the size of compiler-specific headers) and version-agnostic. Other related improvements have been performed in the headers as well, which on top of the use of __has_attribute it has amounted to a significant simplification of these headers (e.g. GCC_VERSION is now only guarding 4 non-attribute macros). This series should also help the efforts to support compiling the kernel with clang and icc. A fair amount of documentation and comments have also been added, clarified or removed; and the headers are now more readable, which should help kernel developers in general. The series was triggered due to the move to gcc >= 4.6. In turn, this series has also triggered Sparse to gain the ability to recognize __has_attribute on its own. You can also fetch it from: https://github.com/ojeda/linux/tree/compiler-attributes-v4 Enjoy! Cheers, Miguel Cc: Jonathan Corbet Cc: Rasmus Villemoes Cc: Luc Van Oostenryck Cc: Eli Friedman Cc: Christopher Li Cc: Kees Cook Cc: Ingo Molnar Cc: Geert Uytterhoeven Cc: Arnd Bergmann Cc: Greg Kroah-Hartman Cc: Masahiro Yamada Cc: Joe Perches Cc: Dominique Martinet Cc: Nick Desaulniers Cc: Linus Torvalds Cc: linux-spa...@vger.kernel.org Cc: linux-...@vger.kernel.org Signed-off-by: Miguel Ojeda v3 -> v4 This time it is an important fix I found while doing randconfigs, plus the documentation sentence that Nick suggested and the MAINTAINERS file. Compile-tested for a while on (x86_64, gcc-7.3) on a few randconfs. New: * Add MAINTAINERS entry for the new file (compiler_attributes.h) so that we try to maintain that one as clean as possible. (if someone else wants to join, feel free!) Modified: * Fix inline macro __always_inline cannot be used in the inline macro, because people marking a function as __always_inline would expand to inline which in turn would expand back to __always_inline (under some configs), which would not be expanded again. Added a comment about this in the inline macro. Also added another comment about __always_inline in compiler_attributes.h to note that users expect to not have to write inline (as well as the attribute). We cannot simply remove "inline" there (which would solve the problem described above) because using the attribute is not enough for gcc. A function marked as always_inline seems to require to be marked as inline itself so that the attribute is applied: "warning: always_inline function might not be inlinable [-Wattributes]" From the gcc docs: "For functions declared inline, this attribute inlines the function independent of any restrictions that otherwise apply to inlining." See https://godbolt.org/z/LpzUPj for an example. From reviews: * Add sentence about feature-detection in Docs (Nick) Miguel Ojeda (13): Compiler Attributes: remove unused attributes Compiler Attributes: always use the extra-underscores syntax Compiler Attributes: remove unneeded tests Compiler Attributes: homogenize __must_be_array Compiler Attributes: naked was fixed in gcc 4.6 Compiler Attributes: naked can be shared Compiler Attributes: remove unneeded sparse (__CHECKER__) tests Compiler Attributes: add missing SPDX ID in compiler_types.h Compiler Attributes: use feature checks instead of version checks Compiler Attributes: KENTRY used twice the "used" attribute Compiler Attributes: remove uses of __attribute__ from compiler.h Compiler Attributes: add Doc/process/programming-language.rst Compiler Attributes: Add MAINTAINERS entry Documentation/process/index.rst | 1 + .../process/programming-language.rst | 45 MAINTAINERS | 5 + include/linux/compiler-clang.h| 5 - include/linux/compiler-gcc.h | 84 +- include/linux/compiler-intel.h| 9 - include/linux/compiler.h | 19 +- include/linux/compiler_attributes.h | 244 ++ include/linux/compiler_types.h| 105 ++-- 9 files changed, 329 insertions(+), 188 deletions(-) create mode 100644 Documentation/process/programming-language.rst create mode 100644 include/linux/compiler_attributes.h -- 2.17.1
[PATCH v4 08/13] Compiler Attributes: add missing SPDX ID in compiler_types.h
Cc: Rasmus Villemoes Cc: Luc Van Oostenryck Cc: Eli Friedman Cc: Christopher Li Cc: Kees Cook Cc: Ingo Molnar Cc: Geert Uytterhoeven Cc: Arnd Bergmann Cc: Greg Kroah-Hartman Cc: Masahiro Yamada Cc: Joe Perches Cc: Dominique Martinet Cc: Nick Desaulniers Cc: Linus Torvalds Cc: linux-spa...@vger.kernel.org Signed-off-by: Miguel Ojeda --- include/linux/compiler_types.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/linux/compiler_types.h b/include/linux/compiler_types.h index a3eceb3ad1b3..ed7c0e4a180e 100644 --- a/include/linux/compiler_types.h +++ b/include/linux/compiler_types.h @@ -1,3 +1,4 @@ +/* SPDX-License-Identifier: GPL-2.0 */ #ifndef __LINUX_COMPILER_TYPES_H #define __LINUX_COMPILER_TYPES_H -- 2.17.1
[PATCH v4 13/13] Compiler Attributes: Add MAINTAINERS entry
Cc: Eli Friedman Cc: Christopher Li Cc: Kees Cook Cc: Ingo Molnar Cc: Geert Uytterhoeven Cc: Arnd Bergmann Cc: Greg Kroah-Hartman Cc: Masahiro Yamada Cc: Joe Perches Cc: Dominique Martinet Cc: Nick Desaulniers Cc: Linus Torvalds Signed-off-by: Miguel Ojeda --- MAINTAINERS | 5 + 1 file changed, 5 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 9ad052aeac39..a7ef76d694d4 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -3721,6 +3721,11 @@ L: platform-driver-...@vger.kernel.org S: Maintained F: drivers/platform/x86/compal-laptop.c +COMPILER ATTRIBUTES +M: Miguel Ojeda +S: Maintained +F: include/linux/compiler_attributes.h + CONEXANT ACCESSRUNNER USB DRIVER L: accessrunner-gene...@lists.sourceforge.net W: http://accessrunner.sourceforge.net/ -- 2.17.1
[PATCH v4 02/13] Compiler Attributes: always use the extra-underscores syntax
The attribute syntax optionally allows to surround attribute names
with "__" in order to avoid collisions with macros of the same name
(see https://gcc.gnu.org/onlinedocs/gcc/Attribute-Syntax.html).
This homogenizes all attributes to use the syntax with underscores.
While there are currently only a handful of cases of some TUs defining
macros like "error" which may collide with the attributes,
this should prevent futures surprises.
This has been done only for "standard" attributes supported by
the major compilers. In other words, those of third-party tools
(e.g. sparse, plugins...) have not been changed for the moment.
Cc: Rasmus Villemoes
Cc: Luc Van Oostenryck
Cc: Eli Friedman
Cc: Christopher Li
Cc: Kees Cook
Cc: Ingo Molnar
Cc: Geert Uytterhoeven
Cc: Arnd Bergmann
Cc: Greg Kroah-Hartman
Cc: Masahiro Yamada
Cc: Joe Perches
Cc: Dominique Martinet
Cc: Linus Torvalds
Cc: linux-spa...@vger.kernel.org
Reviewed-by: Nick Desaulniers
Signed-off-by: Miguel Ojeda
---
include/linux/compiler-clang.h | 2 +-
include/linux/compiler-gcc.h | 14 ++--
include/linux/compiler-intel.h | 2 +-
include/linux/compiler.h | 8 +++
include/linux/compiler_types.h | 40 +-
5 files changed, 33 insertions(+), 33 deletions(-)
diff --git a/include/linux/compiler-clang.h b/include/linux/compiler-clang.h
index b1ce500fe8b3..d11cad61ba5c 100644
--- a/include/linux/compiler-clang.h
+++ b/include/linux/compiler-clang.h
@@ -21,7 +21,7 @@
#define __SANITIZE_ADDRESS__
#endif
-#define __no_sanitize_address __attribute__((no_sanitize("address")))
+#define __no_sanitize_address __attribute__((__no_sanitize__("address")))
/*
* Not all versions of clang implement the the type-generic versions
diff --git a/include/linux/compiler-gcc.h b/include/linux/compiler-gcc.h
index 0a2d06677d83..371b6fa2d074 100644
--- a/include/linux/compiler-gcc.h
+++ b/include/linux/compiler-gcc.h
@@ -76,7 +76,7 @@
#endif
#ifdef RETPOLINE
-#define __noretpoline __attribute__((indirect_branch("keep")))
+#define __noretpoline __attribute__((__indirect_branch__("keep")))
#endif
/*
@@ -91,15 +91,15 @@
* GCC 4.[56] currently fail to enforce this, so we must do so ourselves.
* See GCC PR44290.
*/
-#define __naked__attribute__((naked)) noinline __noclone
notrace
+#define __naked__attribute__((__naked__)) noinline __noclone
notrace
#define __UNIQUE_ID(prefix) __PASTE(__PASTE(__UNIQUE_ID_, prefix), __COUNTER__)
#define __compiletime_object_size(obj) __builtin_object_size(obj, 0)
#ifndef __CHECKER__
-#define __compiletime_warning(message) __attribute__((warning(message)))
-#define __compiletime_error(message) __attribute__((error(message)))
+#define __compiletime_warning(message) __attribute__((__warning__(message)))
+#define __compiletime_error(message) __attribute__((__error__(message)))
#ifdef LATENT_ENTROPY_PLUGIN
#define __latent_entropy __attribute__((latent_entropy))
@@ -148,7 +148,7 @@
* optimizer that something else uses this function or variable, thus
preventing
* this.
*/
-#define __visible __attribute__((externally_visible))
+#define __visible __attribute__((__externally_visible__))
/* gcc version specific checks */
@@ -205,7 +205,7 @@
* should not be applied to that function.
* Conflicts with inlining: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67368
*/
-#define __no_sanitize_address __attribute__((no_sanitize_address))
+#define __no_sanitize_address __attribute__((__no_sanitize_address__))
#endif
#if GCC_VERSION >= 50100
@@ -213,7 +213,7 @@
* Mark structures as requiring designated initializers.
* https://gcc.gnu.org/onlinedocs/gcc/Designated-Inits.html
*/
-#define __designated_init __attribute__((designated_init))
+#define __designated_init __attribute__((__designated_init__))
#define COMPILER_HAS_GENERIC_BUILTIN_OVERFLOW 1
#endif
diff --git a/include/linux/compiler-intel.h b/include/linux/compiler-intel.h
index 4c7f9befa9f6..fef8bb3e53ef 100644
--- a/include/linux/compiler-intel.h
+++ b/include/linux/compiler-intel.h
@@ -42,4 +42,4 @@
* and may be redefined here because they should not be shared with other
* compilers, like clang.
*/
-#define __visible __attribute__((externally_visible))
+#define __visible __attribute__((__externally_visible__))
diff --git a/include/linux/compiler.h b/include/linux/compiler.h
index 7c0157d50964..ec4a28bad2c6 100644
--- a/include/linux/compiler.h
+++ b/include/linux/compiler.h
@@ -24,7 +24,7 @@ void ftrace_likely_update(struct ftrace_likely_data *f, int
val,
long __r; \
static struct ftrace_likely_data\
__attribute__((__aligned__(4))) \
-
__attribute__((section("_ftrace_annotated_branch"))) \
+
[PATCH v4 01/13] Compiler Attributes: remove unused attributes
__optimize and __deprecate_for_modules are unused in
the whole kernel tree. Simply drop them.
Cc: Rasmus Villemoes
Cc: Luc Van Oostenryck
Cc: Eli Friedman
Cc: Christopher Li
Cc: Kees Cook
Cc: Ingo Molnar
Cc: Geert Uytterhoeven
Cc: Arnd Bergmann
Cc: Greg Kroah-Hartman
Cc: Masahiro Yamada
Cc: Joe Perches
Cc: Dominique Martinet
Cc: Linus Torvalds
Cc: linux-spa...@vger.kernel.org
Reviewed-by: Nick Desaulniers
Signed-off-by: Miguel Ojeda
---
include/linux/compiler-gcc.h | 2 --
include/linux/compiler.h | 4
include/linux/compiler_types.h | 1 -
3 files changed, 7 deletions(-)
diff --git a/include/linux/compiler-gcc.h b/include/linux/compiler-gcc.h
index 763bbad1e258..0a2d06677d83 100644
--- a/include/linux/compiler-gcc.h
+++ b/include/linux/compiler-gcc.h
@@ -95,8 +95,6 @@
#define __UNIQUE_ID(prefix) __PASTE(__PASTE(__UNIQUE_ID_, prefix), __COUNTER__)
-#define __optimize(level) __attribute__((__optimize__(level)))
-
#define __compiletime_object_size(obj) __builtin_object_size(obj, 0)
#ifndef __CHECKER__
diff --git a/include/linux/compiler.h b/include/linux/compiler.h
index 681d866efb1e..7c0157d50964 100644
--- a/include/linux/compiler.h
+++ b/include/linux/compiler.h
@@ -301,10 +301,6 @@ static inline void *offset_to_ptr(const int *off)
#endif /* __ASSEMBLY__ */
-#ifndef __optimize
-# define __optimize(level)
-#endif
-
/* Compile time object size, -1 for unknown */
#ifndef __compiletime_object_size
# define __compiletime_object_size(obj) -1
diff --git a/include/linux/compiler_types.h b/include/linux/compiler_types.h
index 3525c179698c..b6534292ea33 100644
--- a/include/linux/compiler_types.h
+++ b/include/linux/compiler_types.h
@@ -108,7 +108,6 @@ struct ftrace_likely_data {
/* Don't. Just don't. */
#define __deprecated
-#define __deprecated_for_modules
#endif /* __KERNEL__ */
--
2.17.1
[PATCH v4 12/13] Compiler Attributes: add Doc/process/programming-language.rst
Cc: Jonathan Corbet Cc: Rasmus Villemoes Cc: Luc Van Oostenryck Cc: Eli Friedman Cc: Christopher Li Cc: Kees Cook Cc: Ingo Molnar Cc: Geert Uytterhoeven Cc: Arnd Bergmann Cc: Greg Kroah-Hartman Cc: Masahiro Yamada Cc: Joe Perches Cc: Dominique Martinet Cc: Nick Desaulniers Cc: Linus Torvalds Cc: linux-spa...@vger.kernel.org Cc: linux-...@vger.kernel.org Signed-off-by: Miguel Ojeda --- Documentation/process/index.rst | 1 + .../process/programming-language.rst | 45 +++ 2 files changed, 46 insertions(+) create mode 100644 Documentation/process/programming-language.rst diff --git a/Documentation/process/index.rst b/Documentation/process/index.rst index 37bd0628b6ee..c56f24a22d2a 100644 --- a/Documentation/process/index.rst +++ b/Documentation/process/index.rst @@ -23,6 +23,7 @@ Below are the essential guides that every developer should read. code-of-conflict development-process submitting-patches + programming-language coding-style maintainer-pgp-guide email-clients diff --git a/Documentation/process/programming-language.rst b/Documentation/process/programming-language.rst new file mode 100644 index ..e5f5f065dc24 --- /dev/null +++ b/Documentation/process/programming-language.rst @@ -0,0 +1,45 @@ +.. _programming_language: + +Programming Language + + +The kernel is written in the C programming language [c-language]_. +More precisely, the kernel is typically compiled with ``gcc`` [gcc]_ +under ``-std=gnu89`` [gcc-c-dialect-options]_: the GNU dialect of ISO C90 +(including some C99 features). + +This dialect contains many extensions to the language [gnu-extensions]_, +and many of them are used within the kernel as a matter of course. + +There is some support for compiling the kernel with ``clang`` [clang]_ +and ``icc`` [icc]_ for several of the architectures, although at the time +of writing it is not completed, requiring third-party patches. + +Attributes +-- + +One of the common extensions used throughout the kernel are attributes +[gcc-attribute-syntax]_. Attributes allow to introduce +implementation-defined semantics to language entities (like variables, +functions or types) without having to make significant syntactic changes +to the language (e.g. adding a new keyword) [n2049]_. + +In some cases, attributes are optional (i.e. a compiler not supporting them +should still produce proper code, even if it is slower or does not perform +as many compile-time checks/diagnostics). + +The kernel defines pseudo-keywords (e.g. ``__pure``) instead of using +directly the GNU attribute syntax (e.g. ``__attribute__((__pure__))``) +in order to feature detect which ones can be used and/or to shorten the code. + +Please refer to ``include/linux/compiler_attributes.h`` for more information. + +.. [c-language] http://www.open-std.org/jtc1/sc22/wg14/www/standards +.. [gcc] https://gcc.gnu.org +.. [clang] https://clang.llvm.org +.. [icc] https://software.intel.com/en-us/c-compilers +.. [gcc-c-dialect-options] https://gcc.gnu.org/onlinedocs/gcc/C-Dialect-Options.html +.. [gnu-extensions] https://gcc.gnu.org/onlinedocs/gcc/C-Extensions.html +.. [gcc-attribute-syntax] https://gcc.gnu.org/onlinedocs/gcc/Attribute-Syntax.html +.. [n2049] http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2049.pdf + -- 2.17.1
[PATCH v4 11/13] Compiler Attributes: remove uses of __attribute__ from compiler.h
Cc: Rasmus Villemoes
Cc: Luc Van Oostenryck
Cc: Eli Friedman
Cc: Christopher Li
Cc: Kees Cook
Cc: Ingo Molnar
Cc: Geert Uytterhoeven
Cc: Arnd Bergmann
Cc: Greg Kroah-Hartman
Cc: Masahiro Yamada
Cc: Joe Perches
Cc: Dominique Martinet
Cc: Linus Torvalds
Cc: linux-spa...@vger.kernel.org
Suggested-by: Nick Desaulniers
Reviewed-by: Nick Desaulniers
Signed-off-by: Miguel Ojeda
---
include/linux/compiler.h | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/include/linux/compiler.h b/include/linux/compiler.h
index 17ee9165ca51..b5fb034fa6fa 100644
--- a/include/linux/compiler.h
+++ b/include/linux/compiler.h
@@ -23,8 +23,8 @@ void ftrace_likely_update(struct ftrace_likely_data *f, int
val,
#define __branch_check__(x, expect, is_constant) ({\
long __r; \
static struct ftrace_likely_data\
- __attribute__((__aligned__(4))) \
-
__attribute__((__section__("_ftrace_annotated_branch"))) \
+ __aligned(4)\
+ __section("_ftrace_annotated_branch") \
__f = { \
.data.func = __func__, \
.data.file = __FILE__, \
@@ -59,8 +59,8 @@ void ftrace_likely_update(struct ftrace_likely_data *f, int
val,
({ \
int __r;\
static struct ftrace_branch_data\
- __attribute__((__aligned__(4))) \
- __attribute__((__section__("_ftrace_branch"))) \
+ __aligned(4)\
+ __section("_ftrace_branch") \
__f = { \
.func = __func__, \
.file = __FILE__, \
@@ -146,7 +146,7 @@ void ftrace_likely_update(struct ftrace_likely_data *f, int
val,
extern typeof(sym) sym; \
static const unsigned long __kentry_##sym \
__used \
- __attribute__((__section__("___kentry" "+" #sym ))) \
+ __section("___kentry" "+" #sym )\
= (unsigned long)
#endif
@@ -287,7 +287,7 @@ unsigned long read_word_at_a_time(const void *addr)
* visible to the compiler.
*/
#define __ADDRESSABLE(sym) \
- static void * __attribute__((__section__(".discard.addressable"),
used)) \
+ static void * __section(".discard.addressable") __used \
__PASTE(__addressable_##sym, __LINE__) = (void *)
/**
--
2.17.1
[PATCH v4 06/13] Compiler Attributes: naked can be shared
The naked attribute is supported by at least gcc >= 4.6 (for ARM,
which is the only current user), gcc >= 8 (for x86), clang >= 3.1
and icc >= 13. See https://godbolt.org/z/350Dyc
Therefore, move it out of compiler-gcc.h so that the definition
is shared by all compilers.
Cc: Rasmus Villemoes
Cc: Luc Van Oostenryck
Cc: Eli Friedman
Cc: Christopher Li
Cc: Kees Cook
Cc: Ingo Molnar
Cc: Geert Uytterhoeven
Cc: Greg Kroah-Hartman
Cc: Masahiro Yamada
Cc: Joe Perches
Cc: Dominique Martinet
Cc: Nick Desaulniers
Cc: Linus Torvalds
Cc: linux-spa...@vger.kernel.org
Suggested-by: Arnd Bergmann
Signed-off-by: Miguel Ojeda
---
include/linux/compiler-gcc.h | 8
include/linux/compiler_types.h | 8
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/include/linux/compiler-gcc.h b/include/linux/compiler-gcc.h
index 4cd5e9264bce..3b32bbfa5a49 100644
--- a/include/linux/compiler-gcc.h
+++ b/include/linux/compiler-gcc.h
@@ -72,14 +72,6 @@
#define __noretpoline __attribute__((__indirect_branch__("keep")))
#endif
-/*
- * it doesn't make sense on ARM (currently the only user of __naked)
- * to trace naked functions because then mcount is called without
- * stack and frame pointer being set up and there is no chance to
- * restore the lr register to the value before mcount was called.
- */
-#define __naked__attribute__((__naked__)) notrace
-
#define __UNIQUE_ID(prefix) __PASTE(__PASTE(__UNIQUE_ID_, prefix), __COUNTER__)
#define __compiletime_object_size(obj) __builtin_object_size(obj, 0)
diff --git a/include/linux/compiler_types.h b/include/linux/compiler_types.h
index 83475515bc39..5ff9cda893f4 100644
--- a/include/linux/compiler_types.h
+++ b/include/linux/compiler_types.h
@@ -224,6 +224,14 @@ struct ftrace_likely_data {
#define notrace
__attribute__((__no_instrument_function__))
#endif
+/*
+ * it doesn't make sense on ARM (currently the only user of __naked)
+ * to trace naked functions because then mcount is called without
+ * stack and frame pointer being set up and there is no chance to
+ * restore the lr register to the value before mcount was called.
+ */
+#define __naked__attribute__((__naked__)) notrace
+
#define __compiler_offsetof(a, b) __builtin_offsetof(a, b)
/*
--
2.17.1
[PATCH v4 11/13] Compiler Attributes: remove uses of __attribute__ from compiler.h
Cc: Rasmus Villemoes
Cc: Luc Van Oostenryck
Cc: Eli Friedman
Cc: Christopher Li
Cc: Kees Cook
Cc: Ingo Molnar
Cc: Geert Uytterhoeven
Cc: Arnd Bergmann
Cc: Greg Kroah-Hartman
Cc: Masahiro Yamada
Cc: Joe Perches
Cc: Dominique Martinet
Cc: Linus Torvalds
Cc: linux-spa...@vger.kernel.org
Suggested-by: Nick Desaulniers
Reviewed-by: Nick Desaulniers
Signed-off-by: Miguel Ojeda
---
include/linux/compiler.h | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/include/linux/compiler.h b/include/linux/compiler.h
index 17ee9165ca51..b5fb034fa6fa 100644
--- a/include/linux/compiler.h
+++ b/include/linux/compiler.h
@@ -23,8 +23,8 @@ void ftrace_likely_update(struct ftrace_likely_data *f, int
val,
#define __branch_check__(x, expect, is_constant) ({\
long __r; \
static struct ftrace_likely_data\
- __attribute__((__aligned__(4))) \
-
__attribute__((__section__("_ftrace_annotated_branch"))) \
+ __aligned(4)\
+ __section("_ftrace_annotated_branch") \
__f = { \
.data.func = __func__, \
.data.file = __FILE__, \
@@ -59,8 +59,8 @@ void ftrace_likely_update(struct ftrace_likely_data *f, int
val,
({ \
int __r;\
static struct ftrace_branch_data\
- __attribute__((__aligned__(4))) \
- __attribute__((__section__("_ftrace_branch"))) \
+ __aligned(4)\
+ __section("_ftrace_branch") \
__f = { \
.func = __func__, \
.file = __FILE__, \
@@ -146,7 +146,7 @@ void ftrace_likely_update(struct ftrace_likely_data *f, int
val,
extern typeof(sym) sym; \
static const unsigned long __kentry_##sym \
__used \
- __attribute__((__section__("___kentry" "+" #sym ))) \
+ __section("___kentry" "+" #sym )\
= (unsigned long)
#endif
@@ -287,7 +287,7 @@ unsigned long read_word_at_a_time(const void *addr)
* visible to the compiler.
*/
#define __ADDRESSABLE(sym) \
- static void * __attribute__((__section__(".discard.addressable"),
used)) \
+ static void * __section(".discard.addressable") __used \
__PASTE(__addressable_##sym, __LINE__) = (void *)
/**
--
2.17.1
[PATCH v4 06/13] Compiler Attributes: naked can be shared
The naked attribute is supported by at least gcc >= 4.6 (for ARM,
which is the only current user), gcc >= 8 (for x86), clang >= 3.1
and icc >= 13. See https://godbolt.org/z/350Dyc
Therefore, move it out of compiler-gcc.h so that the definition
is shared by all compilers.
Cc: Rasmus Villemoes
Cc: Luc Van Oostenryck
Cc: Eli Friedman
Cc: Christopher Li
Cc: Kees Cook
Cc: Ingo Molnar
Cc: Geert Uytterhoeven
Cc: Greg Kroah-Hartman
Cc: Masahiro Yamada
Cc: Joe Perches
Cc: Dominique Martinet
Cc: Nick Desaulniers
Cc: Linus Torvalds
Cc: linux-spa...@vger.kernel.org
Suggested-by: Arnd Bergmann
Signed-off-by: Miguel Ojeda
---
include/linux/compiler-gcc.h | 8
include/linux/compiler_types.h | 8
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/include/linux/compiler-gcc.h b/include/linux/compiler-gcc.h
index 4cd5e9264bce..3b32bbfa5a49 100644
--- a/include/linux/compiler-gcc.h
+++ b/include/linux/compiler-gcc.h
@@ -72,14 +72,6 @@
#define __noretpoline __attribute__((__indirect_branch__("keep")))
#endif
-/*
- * it doesn't make sense on ARM (currently the only user of __naked)
- * to trace naked functions because then mcount is called without
- * stack and frame pointer being set up and there is no chance to
- * restore the lr register to the value before mcount was called.
- */
-#define __naked__attribute__((__naked__)) notrace
-
#define __UNIQUE_ID(prefix) __PASTE(__PASTE(__UNIQUE_ID_, prefix), __COUNTER__)
#define __compiletime_object_size(obj) __builtin_object_size(obj, 0)
diff --git a/include/linux/compiler_types.h b/include/linux/compiler_types.h
index 83475515bc39..5ff9cda893f4 100644
--- a/include/linux/compiler_types.h
+++ b/include/linux/compiler_types.h
@@ -224,6 +224,14 @@ struct ftrace_likely_data {
#define notrace
__attribute__((__no_instrument_function__))
#endif
+/*
+ * it doesn't make sense on ARM (currently the only user of __naked)
+ * to trace naked functions because then mcount is called without
+ * stack and frame pointer being set up and there is no chance to
+ * restore the lr register to the value before mcount was called.
+ */
+#define __naked__attribute__((__naked__)) notrace
+
#define __compiler_offsetof(a, b) __builtin_offsetof(a, b)
/*
--
2.17.1
Re: [PATCH 4.18 000/145] 4.18.7-stable review
On 09/07/2018 02:07 PM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 4.18.7 release. There are 145 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Sun Sep 9 21:08:26 UTC 2018. Anything received after that time might be too late. Build results: total: 137 pass: 137 fail: 0 Qemu test results: total: 314 pass: 314 fail: 0 Details are available at https://kerneltests.org/builders/. Guenter
Re: [PATCH 4.18 000/145] 4.18.7-stable review
On 09/07/2018 02:07 PM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 4.18.7 release. There are 145 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Sun Sep 9 21:08:26 UTC 2018. Anything received after that time might be too late. Build results: total: 137 pass: 137 fail: 0 Qemu test results: total: 314 pass: 314 fail: 0 Details are available at https://kerneltests.org/builders/. Guenter
Re: [PATCH 4.14 00/89] 4.14.69-stable review
On 09/07/2018 02:08 PM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 4.14.69 release. There are 89 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Sun Sep 9 21:08:28 UTC 2018. Anything received after that time might be too late. Build results: total: 151 pass: 149 fail: 2 Failed builds: powerpc:defconfig powerpc:allmodconfig Qemu test results: total: 311 pass: 293 fail: 18 Failed tests: powerpc:mac99:ppc64_book3s_defconfig:nosmp:initrd powerpc:mac99:ppc64_book3s_defconfig:smp:cpu4:initrd powerpc:mac99:ppc64_book3s_defconfig:smp:cpu4:ide:rootfs powerpc:mac99:ppc64_book3s_defconfig:smp:cpu4:mmc:rootfs powerpc:mac99:ppc64_book3s_defconfig:smp:cpu4:scsi[DC395]:rootfs powerpc:pseries:pseries_defconfig:initrd powerpc:pseries:pseries_defconfig:scsi:rootfs powerpc:pseries:pseries_defconfig:mmc:rootfs powerpc:pseries:pseries_defconfig:nvme:rootfs powerpc:pseries:pseries_defconfig:sata-sii3112:rootfs powerpc:pseries:pseries_defconfig:little:initrd powerpc:pseries:pseries_defconfig:little:scsi:rootfs powerpc:pseries:pseries_defconfig:little:sata-sii3112:rootfs powerpc:pseries:pseries_defconfig:little:scsi[MEGASAS]:rootfs powerpc:pseries:pseries_defconfig:little:scsi[FUSION]:rootfs powerpc:pseries:pseries_defconfig:little:mmc:rootfs powerpc:pseries:pseries_defconfig:little:nvme:rootfs powerpc:powernv:powernv_defconfig:initrd Details are available at https://kerneltests.org/builders/. Guenter
Re: [PATCH 4.14 00/89] 4.14.69-stable review
On 09/07/2018 02:08 PM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 4.14.69 release. There are 89 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Sun Sep 9 21:08:28 UTC 2018. Anything received after that time might be too late. Build results: total: 151 pass: 149 fail: 2 Failed builds: powerpc:defconfig powerpc:allmodconfig Qemu test results: total: 311 pass: 293 fail: 18 Failed tests: powerpc:mac99:ppc64_book3s_defconfig:nosmp:initrd powerpc:mac99:ppc64_book3s_defconfig:smp:cpu4:initrd powerpc:mac99:ppc64_book3s_defconfig:smp:cpu4:ide:rootfs powerpc:mac99:ppc64_book3s_defconfig:smp:cpu4:mmc:rootfs powerpc:mac99:ppc64_book3s_defconfig:smp:cpu4:scsi[DC395]:rootfs powerpc:pseries:pseries_defconfig:initrd powerpc:pseries:pseries_defconfig:scsi:rootfs powerpc:pseries:pseries_defconfig:mmc:rootfs powerpc:pseries:pseries_defconfig:nvme:rootfs powerpc:pseries:pseries_defconfig:sata-sii3112:rootfs powerpc:pseries:pseries_defconfig:little:initrd powerpc:pseries:pseries_defconfig:little:scsi:rootfs powerpc:pseries:pseries_defconfig:little:sata-sii3112:rootfs powerpc:pseries:pseries_defconfig:little:scsi[MEGASAS]:rootfs powerpc:pseries:pseries_defconfig:little:scsi[FUSION]:rootfs powerpc:pseries:pseries_defconfig:little:mmc:rootfs powerpc:pseries:pseries_defconfig:little:nvme:rootfs powerpc:powernv:powernv_defconfig:initrd Details are available at https://kerneltests.org/builders/. Guenter
Re: [PATCH 4.9 00/63] 4.9.126-stable review
On 09/07/2018 02:09 PM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 4.9.126 release. There are 63 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Sun Sep 9 21:09:58 UTC 2018. Anything received after that time might be too late. Build results: total: 151 pass: 149 fail: 2 Failed builds: powerpc:defconfig powerpc:allmodconfig Qemu test results: total: 301 pass: 285 fail: 16 Failed tests: powerpc:mac99:ppc64_book3s_defconfig:nosmp:initrd powerpc:mac99:ppc64_book3s_defconfig:smp:cpu4:initrd powerpc:mac99:ppc64_book3s_defconfig:smp:cpu4:ide:rootfs powerpc:mac99:ppc64_book3s_defconfig:smp:cpu4:mmc:rootfs powerpc:mac99:ppc64_book3s_defconfig:smp:cpu4:scsi[DC395]:rootfs powerpc:pseries:pseries_defconfig:initrd powerpc:pseries:pseries_defconfig:scsi:rootfs powerpc:pseries:pseries_defconfig:mmc:rootfs powerpc:pseries:pseries_defconfig:nvme:rootfs powerpc:pseries:pseries_defconfig:little:initrd powerpc:pseries:pseries_defconfig:little:scsi:rootfs powerpc:pseries:pseries_defconfig:little:scsi[MEGASAS]:rootfs powerpc:pseries:pseries_defconfig:little:scsi[FUSION]:rootfs powerpc:pseries:pseries_defconfig:little:mmc:rootfs powerpc:pseries:pseries_defconfig:little:nvme:rootfs powerpc:powernv:powernv_defconfig:initrd Details are available at https://kerneltests.org/builders/. Guenter
Re: [PATCH 4.9 00/63] 4.9.126-stable review
On 09/07/2018 02:09 PM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 4.9.126 release. There are 63 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Sun Sep 9 21:09:58 UTC 2018. Anything received after that time might be too late. Build results: total: 151 pass: 149 fail: 2 Failed builds: powerpc:defconfig powerpc:allmodconfig Qemu test results: total: 301 pass: 285 fail: 16 Failed tests: powerpc:mac99:ppc64_book3s_defconfig:nosmp:initrd powerpc:mac99:ppc64_book3s_defconfig:smp:cpu4:initrd powerpc:mac99:ppc64_book3s_defconfig:smp:cpu4:ide:rootfs powerpc:mac99:ppc64_book3s_defconfig:smp:cpu4:mmc:rootfs powerpc:mac99:ppc64_book3s_defconfig:smp:cpu4:scsi[DC395]:rootfs powerpc:pseries:pseries_defconfig:initrd powerpc:pseries:pseries_defconfig:scsi:rootfs powerpc:pseries:pseries_defconfig:mmc:rootfs powerpc:pseries:pseries_defconfig:nvme:rootfs powerpc:pseries:pseries_defconfig:little:initrd powerpc:pseries:pseries_defconfig:little:scsi:rootfs powerpc:pseries:pseries_defconfig:little:scsi[MEGASAS]:rootfs powerpc:pseries:pseries_defconfig:little:scsi[FUSION]:rootfs powerpc:pseries:pseries_defconfig:little:mmc:rootfs powerpc:pseries:pseries_defconfig:little:nvme:rootfs powerpc:powernv:powernv_defconfig:initrd Details are available at https://kerneltests.org/builders/. Guenter
Re: [PATCH 4.4 00/47] 4.4.155-stable review
On 09/07/2018 02:09 PM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 4.4.155 release. There are 47 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Sun Sep 9 21:08:44 UTC 2018. Anything received after that time might be too late. Build results: total: 151 pass: 150 fail: 1 Failed builds: powerpc:allmodconfig Qemu test results: total: 281 pass: 281 fail: 0 Details are available at https://kerneltests.org/builders/. Guenter
Re: [PATCH 4.4 00/47] 4.4.155-stable review
On 09/07/2018 02:09 PM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 4.4.155 release. There are 47 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Sun Sep 9 21:08:44 UTC 2018. Anything received after that time might be too late. Build results: total: 151 pass: 150 fail: 1 Failed builds: powerpc:allmodconfig Qemu test results: total: 281 pass: 281 fail: 0 Details are available at https://kerneltests.org/builders/. Guenter
Re: [PATCH 3.18 00/29] 3.18.122-stable review
On 09/07/2018 02:10 PM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 3.18.122 release. There are 29 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Sun Sep 9 21:08:52 UTC 2018. Anything received after that time might be too late. Build results: total: 139 pass: 138 fail: 1 Failed builds: powerpc:allmodconfig Qemu test results: total: 217 pass: 217 fail: 0 Details are available at https://kerneltests.org/builders/. Guenter
Re: [PATCH 3.18 00/29] 3.18.122-stable review
On 09/07/2018 02:10 PM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 3.18.122 release. There are 29 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Sun Sep 9 21:08:52 UTC 2018. Anything received after that time might be too late. Build results: total: 139 pass: 138 fail: 1 Failed builds: powerpc:allmodconfig Qemu test results: total: 217 pass: 217 fail: 0 Details are available at https://kerneltests.org/builders/. Guenter
Re: + mm-slab-shorten-kmalloc-cache-names-for-large-sizes.patch added to -mm tree
On Sat, Sep 08, 2018 at 09:10:46AM -0700, Randy Dunlap wrote: > On 09/08/2018 08:54 AM, Matthew Wilcox wrote: > > On Sat, Sep 08, 2018 at 10:03:06AM -0400, Johannes Weiner wrote: > >> On Fri, Sep 07, 2018 at 10:58:16PM +0300, Alexey Dobriyan wrote: > >>> I'd rather use KB and MB suffixes or at least capital 'K'. > >> I like k and M better. > > k and M work for me too. It we were going to be anal then we should > > go with the IEC standard of KiB and MiB, but we're trying to make > > But ^K and ^M. > > Small 'k' .. I don't know what that is. SI uses 'k' for kilo and 'K' for Kelvin. It's an anomaly because all the other magnifying prefixes use capital letters, but it's km, not Km; kg, kV, kJ, kN, kW and kΩ.
Re: + mm-slab-shorten-kmalloc-cache-names-for-large-sizes.patch added to -mm tree
On Sat, Sep 08, 2018 at 09:10:46AM -0700, Randy Dunlap wrote: > On 09/08/2018 08:54 AM, Matthew Wilcox wrote: > > On Sat, Sep 08, 2018 at 10:03:06AM -0400, Johannes Weiner wrote: > >> On Fri, Sep 07, 2018 at 10:58:16PM +0300, Alexey Dobriyan wrote: > >>> I'd rather use KB and MB suffixes or at least capital 'K'. > >> I like k and M better. > > k and M work for me too. It we were going to be anal then we should > > go with the IEC standard of KiB and MiB, but we're trying to make > > But ^K and ^M. > > Small 'k' .. I don't know what that is. SI uses 'k' for kilo and 'K' for Kelvin. It's an anomaly because all the other magnifying prefixes use capital letters, but it's km, not Km; kg, kV, kJ, kN, kW and kΩ.
Re: [PATCH] leds: pwm: silently error out on EPROBE_DEFER
Hi Jerome,
Thank you for the patch.
On 09/06/2018 03:59 PM, Jerome Brunet wrote:
> When probing, if we fail to get the pwm due to probe deferal, we shouldn't
> print an error message. Just be silent in this case.
>
> Signed-off-by: Jerome Brunet
> ---
> drivers/leds/leds-pwm.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/leds/leds-pwm.c b/drivers/leds/leds-pwm.c
> index df80c89ebe7f..5d3faae51d59 100644
> --- a/drivers/leds/leds-pwm.c
> +++ b/drivers/leds/leds-pwm.c
> @@ -100,8 +100,9 @@ static int led_pwm_add(struct device *dev, struct
> led_pwm_priv *priv,
> led_data->pwm = devm_pwm_get(dev, led->name);
> if (IS_ERR(led_data->pwm)) {
> ret = PTR_ERR(led_data->pwm);
> - dev_err(dev, "unable to request PWM for %s: %d\n",
> - led->name, ret);
> + if (ret != -EPROBE_DEFER)
> + dev_err(dev, "unable to request PWM for %s: %d\n",
> + led->name, ret);
> return ret;
> }
>
>
Applied.
--
Best regards,
Jacek Anaszewski
Re: [PATCH] leds: pwm: silently error out on EPROBE_DEFER
Hi Jerome,
Thank you for the patch.
On 09/06/2018 03:59 PM, Jerome Brunet wrote:
> When probing, if we fail to get the pwm due to probe deferal, we shouldn't
> print an error message. Just be silent in this case.
>
> Signed-off-by: Jerome Brunet
> ---
> drivers/leds/leds-pwm.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/leds/leds-pwm.c b/drivers/leds/leds-pwm.c
> index df80c89ebe7f..5d3faae51d59 100644
> --- a/drivers/leds/leds-pwm.c
> +++ b/drivers/leds/leds-pwm.c
> @@ -100,8 +100,9 @@ static int led_pwm_add(struct device *dev, struct
> led_pwm_priv *priv,
> led_data->pwm = devm_pwm_get(dev, led->name);
> if (IS_ERR(led_data->pwm)) {
> ret = PTR_ERR(led_data->pwm);
> - dev_err(dev, "unable to request PWM for %s: %d\n",
> - led->name, ret);
> + if (ret != -EPROBE_DEFER)
> + dev_err(dev, "unable to request PWM for %s: %d\n",
> + led->name, ret);
> return ret;
> }
>
>
Applied.
--
Best regards,
Jacek Anaszewski
Re: [PATCH v6 1/5] seccomp: add a return code to trap to userspace
On Thu, Sep 06, 2018 at 10:15:12PM +, Tyler Hicks wrote:
> On 2018-09-06 09:28:55, Tycho Andersen wrote:
> > /**
> > * struct seccomp_filter - container for seccomp BPF programs
> > *
> > @@ -66,6 +114,30 @@ struct seccomp_filter {
> > bool log;
> > struct seccomp_filter *prev;
> > struct bpf_prog *prog;
> > +
> > +#ifdef CONFIG_SECCOMP_USER_NOTIFICATION
> > + /*
> > +* A semaphore that users of this notification can wait on for
> > +* changes. Actual reads and writes are still controlled with
> > +* filter->notify_lock.
> > +*/
> > + struct semaphore request;
> > +
> > + /* A lock for all notification-related accesses. */
> > + struct mutex notify_lock;
> > +
> > + /* Is there currently an attached listener? */
> > + bool has_listener;
> > +
> > + /* The id of the next request. */
> > + u64 next_id;
> > +
> > + /* A list of struct seccomp_knotif elements. */
> > + struct list_head notifications;
> > +
> > + /* A wait queue for poll. */
> > + wait_queue_head_t wqh;
> > +#endif
>
> I suspect that these additions would benefit from better struct packing
> since there could be a lot of seccomp_filter structs floating around in
> memory on a system with a large number of running containers or
> otherwise sandboxed processes.
>
> IIRC, there's a 3 byte hole following the log member that could be used
> by has_listener, at least, and I'm not sure how the rest of the new
> members affect things.
So it turns out the additions are fairly major. The previous
sizeof(struct seccomp_filter) == 24 bytes on x86_64, with the three
byte hole you mentioned.
The new members alone actual sizes are:
sizeof(struct sempahore) request == 80
sizeof(struct mutex) notify_lock == 128
sizeof(struct list_head) notifications == 16
sizeof(struct wait_queue_head_t) wqh == 72
+ the base types of next_id, has_listener gives a grand total of 305
additional bytes, assuming it's packed perfectly. That seems like
quite a huge hit for everyone to endure, especially since it won't be
perfectly packed.
Instead, what if we add a struct notification, and a struct
notification* to struct seccomp_filter? Then we can drop the bool
has_listener because we can use a null test, and the 304 bytes are
only paid by people who actually use this feature (as well as the cost
of an additional indirection, but who cares, they're trapping to
userspace anyway). Unless I hear any objections, I'll do this for v7
:)
Tycho
Re: [PATCH v6 1/5] seccomp: add a return code to trap to userspace
On Thu, Sep 06, 2018 at 10:15:12PM +, Tyler Hicks wrote:
> On 2018-09-06 09:28:55, Tycho Andersen wrote:
> > /**
> > * struct seccomp_filter - container for seccomp BPF programs
> > *
> > @@ -66,6 +114,30 @@ struct seccomp_filter {
> > bool log;
> > struct seccomp_filter *prev;
> > struct bpf_prog *prog;
> > +
> > +#ifdef CONFIG_SECCOMP_USER_NOTIFICATION
> > + /*
> > +* A semaphore that users of this notification can wait on for
> > +* changes. Actual reads and writes are still controlled with
> > +* filter->notify_lock.
> > +*/
> > + struct semaphore request;
> > +
> > + /* A lock for all notification-related accesses. */
> > + struct mutex notify_lock;
> > +
> > + /* Is there currently an attached listener? */
> > + bool has_listener;
> > +
> > + /* The id of the next request. */
> > + u64 next_id;
> > +
> > + /* A list of struct seccomp_knotif elements. */
> > + struct list_head notifications;
> > +
> > + /* A wait queue for poll. */
> > + wait_queue_head_t wqh;
> > +#endif
>
> I suspect that these additions would benefit from better struct packing
> since there could be a lot of seccomp_filter structs floating around in
> memory on a system with a large number of running containers or
> otherwise sandboxed processes.
>
> IIRC, there's a 3 byte hole following the log member that could be used
> by has_listener, at least, and I'm not sure how the rest of the new
> members affect things.
So it turns out the additions are fairly major. The previous
sizeof(struct seccomp_filter) == 24 bytes on x86_64, with the three
byte hole you mentioned.
The new members alone actual sizes are:
sizeof(struct sempahore) request == 80
sizeof(struct mutex) notify_lock == 128
sizeof(struct list_head) notifications == 16
sizeof(struct wait_queue_head_t) wqh == 72
+ the base types of next_id, has_listener gives a grand total of 305
additional bytes, assuming it's packed perfectly. That seems like
quite a huge hit for everyone to endure, especially since it won't be
perfectly packed.
Instead, what if we add a struct notification, and a struct
notification* to struct seccomp_filter? Then we can drop the bool
has_listener because we can use a null test, and the 304 bytes are
only paid by people who actually use this feature (as well as the cost
of an additional indirection, but who cares, they're trapping to
userspace anyway). Unless I hear any objections, I'll do this for v7
:)
Tycho
[PATCH 6/6] dynamic_debug: Add flag for dynamic event tracing
Debugging a specific driver or subsystem can be a lot easier
if we can trace events specific to that driver or subsystem.
This type of filtering can be achieved using existing
dynamic debug library which provides a way to filter based
on files, functions and modules.
Using this, provide an additional flag 'e' to filter event
tracing to specified input.
For example, tracing all IO read/write can be overwhelming
and of no use when debugging a specific driver or a subsystem.
So switch to dynamic event tracing for register accesses.
Example for tracing register accesses in drivers/soc/qcom/*
and the pstore output is given below:
# dyndbg="file drivers/soc/qcom/* +e" trace_event=io tp_pstore
# reboot -f
# mount -t pstore pstore /sys/fs/pstore
# cat /sys/fs/pstore/event-ramoops-0
io_write: type=writel cpu=1 ts:1423596253 data=0x0d2065a4
caller=qcom_smsm_probe+0x524/0x670
io_write: type=writel cpu=1 ts:1423945889 data=0x0d206608
caller=qcom_smsm_probe+0x524/0x670
Note: Tracing is activated only when flag is enabled either
through command line or through dynamic debug control file.
Signed-off-by: Sai Prakash Ranjan
---
include/asm-generic/io-instrumented.h | 28 +--
include/linux/dynamic_debug.h | 1 +
lib/dynamic_debug.c | 1 +
3 files changed, 28 insertions(+), 2 deletions(-)
diff --git a/include/asm-generic/io-instrumented.h
b/include/asm-generic/io-instrumented.h
index 7b050e2487ed..023f28571ea3 100644
--- a/include/asm-generic/io-instrumented.h
+++ b/include/asm-generic/io-instrumented.h
@@ -2,6 +2,8 @@
#ifndef _ASM_GENERIC_IO_INSTRUMENTED_H
#define _ASM_GENERIC_IO_INSTRUMENTED_H
+#include
+
#if defined(CONFIG_TRACING_EVENTS_IO)
#include
@@ -19,7 +21,7 @@ static inline void do_trace_io_read(const char *type, void
*addr) {}
#define __raw_write(v, a, _l) ({
\
volatile void __iomem *_a = (a);
\
if (io_tracepoint_active(__tracepoint_io_write))
\
- do_trace_io_write(__stringify(write##_l), (void __force
*)(_a));\
+ dynamic_io_write(__stringify(write##_l), (void __force *)(_a));
\
arch_raw_write##_l((v), _a);
\
})
@@ -32,7 +34,7 @@ static inline void do_trace_io_read(const char *type, void
*addr) {}
_t __a;
\
const volatile void __iomem *_a = (a);
\
if (io_tracepoint_active(__tracepoint_io_read))
\
- do_trace_io_read(__stringify(read##_l), (void __force *)(_a));
\
+ dynamic_io_read(__stringify(read##_l), (void __force *)(_a));
\
__a = arch_raw_read##_l(_a);
\
__a;
\
})
@@ -42,4 +44,26 @@ static inline void do_trace_io_read(const char *type, void
*addr) {}
#define __raw_readl(a) __raw_read((a), l, u32)
#define __raw_readq(a) __raw_read((a), q, u64)
+#if defined(CONFIG_DYNAMIC_DEBUG) && defined(CONFIG_TRACING_EVENTS_IO)
+#define dynamic_io_write(type, addr) \
+do { \
+ DEFINE_DYNAMIC_DEBUG_METADATA(descriptor, type);\
+ if (unlikely(descriptor.flags & _DPRINTK_FLAGS_EVENT)) \
+ do_trace_io_write(type, addr); \
+} while (0)
+
+#define dynamic_io_read(type, addr)\
+do { \
+ DEFINE_DYNAMIC_DEBUG_METADATA(descriptor, type);\
+ if (unlikely(descriptor.flags & _DPRINTK_FLAGS_EVENT)) \
+ do_trace_io_read(type, addr); \
+} while (0)
+#elif defined(CONFIG_TRACING_EVENTS_IO)
+#define dynamic_io_write(type, addr) do_trace_io_write(type, addr)
+#define dynamic_io_read(type, addr)do_trace_io_read(type, addr)
+#else
+#define dynamic_io_write(type, addr)
+#define dynamic_io_read(type, addr)
+#endif /* CONFIG_DYNAMIC_DEBUG && CONFIG_TRACING_EVENTS_IO */
+
#endif /* _ASM_GENERIC_IO_INSTRUMENTED_H */
diff --git a/include/linux/dynamic_debug.h b/include/linux/dynamic_debug.h
index 2fd8006153c3..14e595c51002 100644
--- a/include/linux/dynamic_debug.h
+++ b/include/linux/dynamic_debug.h
@@ -32,6 +32,7 @@ struct _ddebug {
#define _DPRINTK_FLAGS_INCL_FUNCNAME (1<<2)
#define _DPRINTK_FLAGS_INCL_LINENO (1<<3)
#define _DPRINTK_FLAGS_INCL_TID(1<<4)
+#define _DPRINTK_FLAGS_EVENT (1<<5)
#if defined DEBUG
#define _DPRINTK_FLAGS_DEFAULT _DPRINTK_FLAGS_PRINT
#else
diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c
[PATCH 5/6] arm64/io: Add header for instrumentation of io operations
The new asm-generic/io-instrumented.h will keep arch code
clean and separate from instrumented version which traces
io register accesses. This instrumented header can later
be included in arm as well for tracing io register accesses.
Suggested-by: Will Deacon
Signed-off-by: Sai Prakash Ranjan
---
arch/arm64/include/asm/io.h | 25 ++-
include/asm-generic/io-instrumented.h | 45 +++
2 files changed, 54 insertions(+), 16 deletions(-)
create mode 100644 include/asm-generic/io-instrumented.h
diff --git a/arch/arm64/include/asm/io.h b/arch/arm64/include/asm/io.h
index 35b2e50f17fb..768a6a8c5778 100644
--- a/arch/arm64/include/asm/io.h
+++ b/arch/arm64/include/asm/io.h
@@ -36,32 +36,27 @@
/*
* Generic IO read/write. These perform native-endian accesses.
*/
-#define __raw_writeb __raw_writeb
-static inline void __raw_writeb(u8 val, volatile void __iomem *addr)
+static inline void arch_raw_writeb(u8 val, volatile void __iomem *addr)
{
asm volatile("strb %w0, [%1]" : : "rZ" (val), "r" (addr));
}
-#define __raw_writew __raw_writew
-static inline void __raw_writew(u16 val, volatile void __iomem *addr)
+static inline void arch_raw_writew(u16 val, volatile void __iomem *addr)
{
asm volatile("strh %w0, [%1]" : : "rZ" (val), "r" (addr));
}
-#define __raw_writel __raw_writel
-static inline void __raw_writel(u32 val, volatile void __iomem *addr)
+static inline void arch_raw_writel(u32 val, volatile void __iomem *addr)
{
asm volatile("str %w0, [%1]" : : "rZ" (val), "r" (addr));
}
-#define __raw_writeq __raw_writeq
-static inline void __raw_writeq(u64 val, volatile void __iomem *addr)
+static inline void arch_raw_writeq(u64 val, volatile void __iomem *addr)
{
asm volatile("str %x0, [%1]" : : "rZ" (val), "r" (addr));
}
-#define __raw_readb __raw_readb
-static inline u8 __raw_readb(const volatile void __iomem *addr)
+static inline u8 arch_raw_readb(const volatile void __iomem *addr)
{
u8 val;
asm volatile(ALTERNATIVE("ldrb %w0, [%1]",
@@ -71,8 +66,7 @@ static inline u8 __raw_readb(const volatile void __iomem
*addr)
return val;
}
-#define __raw_readw __raw_readw
-static inline u16 __raw_readw(const volatile void __iomem *addr)
+static inline u16 arch_raw_readw(const volatile void __iomem *addr)
{
u16 val;
@@ -83,8 +77,7 @@ static inline u16 __raw_readw(const volatile void __iomem
*addr)
return val;
}
-#define __raw_readl __raw_readl
-static inline u32 __raw_readl(const volatile void __iomem *addr)
+static inline u32 arch_raw_readl(const volatile void __iomem *addr)
{
u32 val;
asm volatile(ALTERNATIVE("ldr %w0, [%1]",
@@ -94,8 +87,7 @@ static inline u32 __raw_readl(const volatile void __iomem
*addr)
return val;
}
-#define __raw_readq __raw_readq
-static inline u64 __raw_readq(const volatile void __iomem *addr)
+static inline u64 arch_raw_readq(const volatile void __iomem *addr)
{
u64 val;
asm volatile(ALTERNATIVE("ldr %0, [%1]",
@@ -193,6 +185,7 @@ extern void __iomem *ioremap_cache(phys_addr_t phys_addr,
size_t size);
#define iowrite32be(v,p) ({ __iowmb(); __raw_writel((__force
__u32)cpu_to_be32(v), p); })
#define iowrite64be(v,p) ({ __iowmb(); __raw_writeq((__force
__u64)cpu_to_be64(v), p); })
+#include
#include
/*
diff --git a/include/asm-generic/io-instrumented.h
b/include/asm-generic/io-instrumented.h
new file mode 100644
index ..7b050e2487ed
--- /dev/null
+++ b/include/asm-generic/io-instrumented.h
@@ -0,0 +1,45 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef _ASM_GENERIC_IO_INSTRUMENTED_H
+#define _ASM_GENERIC_IO_INSTRUMENTED_H
+
+#if defined(CONFIG_TRACING_EVENTS_IO)
+#include
+
+extern struct tracepoint __tracepoint_io_write;
+extern struct tracepoint __tracepoint_io_read;
+#define io_tracepoint_active(t) static_key_false(&(t).key)
+extern void do_trace_io_write(const char *type, void *addr);
+extern void do_trace_io_read(const char *type, void *addr);
+#else
+#define io_tracepoint_active(t) false
+static inline void do_trace_io_write(const char *type, void *addr) {}
+static inline void do_trace_io_read(const char *type, void *addr) {}
+#endif /* CONFIG_TRACING_EVENTS_IO */
+
+#define __raw_write(v, a, _l) ({
\
+ volatile void __iomem *_a = (a);
\
+ if (io_tracepoint_active(__tracepoint_io_write))
\
+ do_trace_io_write(__stringify(write##_l), (void __force
*)(_a));\
+ arch_raw_write##_l((v), _a);
\
+ })
+
+#define __raw_writeb(v, a) __raw_write((v), a, b)
+#define __raw_writew(v, a) __raw_write((v), a, w)
+#define __raw_writel(v, a) __raw_write((v), a, l)
+#define __raw_writeq(v, a) __raw_write((v), a, q)
+
+#define __raw_read(a, _l, _t)({
[PATCH 6/6] dynamic_debug: Add flag for dynamic event tracing
Debugging a specific driver or subsystem can be a lot easier
if we can trace events specific to that driver or subsystem.
This type of filtering can be achieved using existing
dynamic debug library which provides a way to filter based
on files, functions and modules.
Using this, provide an additional flag 'e' to filter event
tracing to specified input.
For example, tracing all IO read/write can be overwhelming
and of no use when debugging a specific driver or a subsystem.
So switch to dynamic event tracing for register accesses.
Example for tracing register accesses in drivers/soc/qcom/*
and the pstore output is given below:
# dyndbg="file drivers/soc/qcom/* +e" trace_event=io tp_pstore
# reboot -f
# mount -t pstore pstore /sys/fs/pstore
# cat /sys/fs/pstore/event-ramoops-0
io_write: type=writel cpu=1 ts:1423596253 data=0x0d2065a4
caller=qcom_smsm_probe+0x524/0x670
io_write: type=writel cpu=1 ts:1423945889 data=0x0d206608
caller=qcom_smsm_probe+0x524/0x670
Note: Tracing is activated only when flag is enabled either
through command line or through dynamic debug control file.
Signed-off-by: Sai Prakash Ranjan
---
include/asm-generic/io-instrumented.h | 28 +--
include/linux/dynamic_debug.h | 1 +
lib/dynamic_debug.c | 1 +
3 files changed, 28 insertions(+), 2 deletions(-)
diff --git a/include/asm-generic/io-instrumented.h
b/include/asm-generic/io-instrumented.h
index 7b050e2487ed..023f28571ea3 100644
--- a/include/asm-generic/io-instrumented.h
+++ b/include/asm-generic/io-instrumented.h
@@ -2,6 +2,8 @@
#ifndef _ASM_GENERIC_IO_INSTRUMENTED_H
#define _ASM_GENERIC_IO_INSTRUMENTED_H
+#include
+
#if defined(CONFIG_TRACING_EVENTS_IO)
#include
@@ -19,7 +21,7 @@ static inline void do_trace_io_read(const char *type, void
*addr) {}
#define __raw_write(v, a, _l) ({
\
volatile void __iomem *_a = (a);
\
if (io_tracepoint_active(__tracepoint_io_write))
\
- do_trace_io_write(__stringify(write##_l), (void __force
*)(_a));\
+ dynamic_io_write(__stringify(write##_l), (void __force *)(_a));
\
arch_raw_write##_l((v), _a);
\
})
@@ -32,7 +34,7 @@ static inline void do_trace_io_read(const char *type, void
*addr) {}
_t __a;
\
const volatile void __iomem *_a = (a);
\
if (io_tracepoint_active(__tracepoint_io_read))
\
- do_trace_io_read(__stringify(read##_l), (void __force *)(_a));
\
+ dynamic_io_read(__stringify(read##_l), (void __force *)(_a));
\
__a = arch_raw_read##_l(_a);
\
__a;
\
})
@@ -42,4 +44,26 @@ static inline void do_trace_io_read(const char *type, void
*addr) {}
#define __raw_readl(a) __raw_read((a), l, u32)
#define __raw_readq(a) __raw_read((a), q, u64)
+#if defined(CONFIG_DYNAMIC_DEBUG) && defined(CONFIG_TRACING_EVENTS_IO)
+#define dynamic_io_write(type, addr) \
+do { \
+ DEFINE_DYNAMIC_DEBUG_METADATA(descriptor, type);\
+ if (unlikely(descriptor.flags & _DPRINTK_FLAGS_EVENT)) \
+ do_trace_io_write(type, addr); \
+} while (0)
+
+#define dynamic_io_read(type, addr)\
+do { \
+ DEFINE_DYNAMIC_DEBUG_METADATA(descriptor, type);\
+ if (unlikely(descriptor.flags & _DPRINTK_FLAGS_EVENT)) \
+ do_trace_io_read(type, addr); \
+} while (0)
+#elif defined(CONFIG_TRACING_EVENTS_IO)
+#define dynamic_io_write(type, addr) do_trace_io_write(type, addr)
+#define dynamic_io_read(type, addr)do_trace_io_read(type, addr)
+#else
+#define dynamic_io_write(type, addr)
+#define dynamic_io_read(type, addr)
+#endif /* CONFIG_DYNAMIC_DEBUG && CONFIG_TRACING_EVENTS_IO */
+
#endif /* _ASM_GENERIC_IO_INSTRUMENTED_H */
diff --git a/include/linux/dynamic_debug.h b/include/linux/dynamic_debug.h
index 2fd8006153c3..14e595c51002 100644
--- a/include/linux/dynamic_debug.h
+++ b/include/linux/dynamic_debug.h
@@ -32,6 +32,7 @@ struct _ddebug {
#define _DPRINTK_FLAGS_INCL_FUNCNAME (1<<2)
#define _DPRINTK_FLAGS_INCL_LINENO (1<<3)
#define _DPRINTK_FLAGS_INCL_TID(1<<4)
+#define _DPRINTK_FLAGS_EVENT (1<<5)
#if defined DEBUG
#define _DPRINTK_FLAGS_DEFAULT _DPRINTK_FLAGS_PRINT
#else
diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c
[PATCH 5/6] arm64/io: Add header for instrumentation of io operations
The new asm-generic/io-instrumented.h will keep arch code
clean and separate from instrumented version which traces
io register accesses. This instrumented header can later
be included in arm as well for tracing io register accesses.
Suggested-by: Will Deacon
Signed-off-by: Sai Prakash Ranjan
---
arch/arm64/include/asm/io.h | 25 ++-
include/asm-generic/io-instrumented.h | 45 +++
2 files changed, 54 insertions(+), 16 deletions(-)
create mode 100644 include/asm-generic/io-instrumented.h
diff --git a/arch/arm64/include/asm/io.h b/arch/arm64/include/asm/io.h
index 35b2e50f17fb..768a6a8c5778 100644
--- a/arch/arm64/include/asm/io.h
+++ b/arch/arm64/include/asm/io.h
@@ -36,32 +36,27 @@
/*
* Generic IO read/write. These perform native-endian accesses.
*/
-#define __raw_writeb __raw_writeb
-static inline void __raw_writeb(u8 val, volatile void __iomem *addr)
+static inline void arch_raw_writeb(u8 val, volatile void __iomem *addr)
{
asm volatile("strb %w0, [%1]" : : "rZ" (val), "r" (addr));
}
-#define __raw_writew __raw_writew
-static inline void __raw_writew(u16 val, volatile void __iomem *addr)
+static inline void arch_raw_writew(u16 val, volatile void __iomem *addr)
{
asm volatile("strh %w0, [%1]" : : "rZ" (val), "r" (addr));
}
-#define __raw_writel __raw_writel
-static inline void __raw_writel(u32 val, volatile void __iomem *addr)
+static inline void arch_raw_writel(u32 val, volatile void __iomem *addr)
{
asm volatile("str %w0, [%1]" : : "rZ" (val), "r" (addr));
}
-#define __raw_writeq __raw_writeq
-static inline void __raw_writeq(u64 val, volatile void __iomem *addr)
+static inline void arch_raw_writeq(u64 val, volatile void __iomem *addr)
{
asm volatile("str %x0, [%1]" : : "rZ" (val), "r" (addr));
}
-#define __raw_readb __raw_readb
-static inline u8 __raw_readb(const volatile void __iomem *addr)
+static inline u8 arch_raw_readb(const volatile void __iomem *addr)
{
u8 val;
asm volatile(ALTERNATIVE("ldrb %w0, [%1]",
@@ -71,8 +66,7 @@ static inline u8 __raw_readb(const volatile void __iomem
*addr)
return val;
}
-#define __raw_readw __raw_readw
-static inline u16 __raw_readw(const volatile void __iomem *addr)
+static inline u16 arch_raw_readw(const volatile void __iomem *addr)
{
u16 val;
@@ -83,8 +77,7 @@ static inline u16 __raw_readw(const volatile void __iomem
*addr)
return val;
}
-#define __raw_readl __raw_readl
-static inline u32 __raw_readl(const volatile void __iomem *addr)
+static inline u32 arch_raw_readl(const volatile void __iomem *addr)
{
u32 val;
asm volatile(ALTERNATIVE("ldr %w0, [%1]",
@@ -94,8 +87,7 @@ static inline u32 __raw_readl(const volatile void __iomem
*addr)
return val;
}
-#define __raw_readq __raw_readq
-static inline u64 __raw_readq(const volatile void __iomem *addr)
+static inline u64 arch_raw_readq(const volatile void __iomem *addr)
{
u64 val;
asm volatile(ALTERNATIVE("ldr %0, [%1]",
@@ -193,6 +185,7 @@ extern void __iomem *ioremap_cache(phys_addr_t phys_addr,
size_t size);
#define iowrite32be(v,p) ({ __iowmb(); __raw_writel((__force
__u32)cpu_to_be32(v), p); })
#define iowrite64be(v,p) ({ __iowmb(); __raw_writeq((__force
__u64)cpu_to_be64(v), p); })
+#include
#include
/*
diff --git a/include/asm-generic/io-instrumented.h
b/include/asm-generic/io-instrumented.h
new file mode 100644
index ..7b050e2487ed
--- /dev/null
+++ b/include/asm-generic/io-instrumented.h
@@ -0,0 +1,45 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef _ASM_GENERIC_IO_INSTRUMENTED_H
+#define _ASM_GENERIC_IO_INSTRUMENTED_H
+
+#if defined(CONFIG_TRACING_EVENTS_IO)
+#include
+
+extern struct tracepoint __tracepoint_io_write;
+extern struct tracepoint __tracepoint_io_read;
+#define io_tracepoint_active(t) static_key_false(&(t).key)
+extern void do_trace_io_write(const char *type, void *addr);
+extern void do_trace_io_read(const char *type, void *addr);
+#else
+#define io_tracepoint_active(t) false
+static inline void do_trace_io_write(const char *type, void *addr) {}
+static inline void do_trace_io_read(const char *type, void *addr) {}
+#endif /* CONFIG_TRACING_EVENTS_IO */
+
+#define __raw_write(v, a, _l) ({
\
+ volatile void __iomem *_a = (a);
\
+ if (io_tracepoint_active(__tracepoint_io_write))
\
+ do_trace_io_write(__stringify(write##_l), (void __force
*)(_a));\
+ arch_raw_write##_l((v), _a);
\
+ })
+
+#define __raw_writeb(v, a) __raw_write((v), a, b)
+#define __raw_writew(v, a) __raw_write((v), a, w)
+#define __raw_writel(v, a) __raw_write((v), a, l)
+#define __raw_writeq(v, a) __raw_write((v), a, q)
+
+#define __raw_read(a, _l, _t)({
[PATCH 2/6] pstore: Add event tracing support
Currently pstore has function trace support which can be
used to get the function call chain with limited data.
Event tracing has extra data which is useful to debug wide
variety of issues and is heavily used across the kernel.
Adding this support to pstore can be very helpful to debug
different subsystems since almost all of them have trace
events already available. And also it is useful to debug
unknown resets or crashes since we can get lot more info
from event tracing by viewing the last occurred events.
High frequency tracepoints such as sched and irq has also
been tested. This implementation is similar to "tp_printk"
command line feature of ftrace by Steven.
For example, sample pstore output of tracing sched events
after reboot:
# mount -t pstore pstore /sys/fs/pstore/
# tail /sys/fs/pstore/event-ramoops-0
sched_switch: prev_comm=swapper/1 prev_pid=0 prev_prio=120 prev_state=S ==>
next_comm=rcu_preempt next_pid=10 next_prio=120
sched_switch: prev_comm=rcu_preempt prev_pid=10 prev_prio=120 prev_state=R+
==> next_comm=swapper/1 next_pid=0 next_prio=120
sched_waking: comm=rcu_sched pid=11 prio=120 target_cpu=002
sched_wakeup: comm=rcu_sched pid=11 prio=120 target_cpu=002
sched_switch: prev_comm=swapper/2 prev_pid=0 prev_prio=120 prev_state=S ==>
next_comm=rcu_sched next_pid=11 next_prio=120
sched_switch: prev_comm=rcu_sched prev_pid=11 prev_prio=120 prev_state=R+ ==>
next_comm=swapper/2 next_pid=0 next_prio=120
sched_waking: comm=reboot pid=1867 prio=120 target_cpu=000
sched_wakeup: comm=reboot pid=1867 prio=120 target_cpu=000
sched_switch: prev_comm=swapper/0 prev_pid=0 prev_prio=120 prev_state=S ==>
next_comm=reboot next_pid=1867 next_prio=120
Signed-off-by: Sai Prakash Ranjan
---
fs/pstore/Kconfig | 2 +-
fs/pstore/ftrace.c | 55 ++
fs/pstore/inode.c | 4 +++
fs/pstore/ram.c| 44 +++---
include/linux/pstore.h | 2 ++
include/linux/pstore_ram.h | 1 +
6 files changed, 104 insertions(+), 4 deletions(-)
diff --git a/fs/pstore/Kconfig b/fs/pstore/Kconfig
index 503086f7f7c1..6fe087b13a51 100644
--- a/fs/pstore/Kconfig
+++ b/fs/pstore/Kconfig
@@ -126,7 +126,7 @@ config PSTORE_PMSG
config PSTORE_FTRACE
bool "Persistent function tracer"
- depends on PSTORE
+ depends on PSTORE && PSTORE!=m
depends on FUNCTION_TRACER
depends on DEBUG_FS
help
diff --git a/fs/pstore/ftrace.c b/fs/pstore/ftrace.c
index 06aab07b6bb7..d47dc93ac098 100644
--- a/fs/pstore/ftrace.c
+++ b/fs/pstore/ftrace.c
@@ -24,6 +24,8 @@
#include
#include
#include
+#include
+#include
#include
#include "internal.h"
@@ -62,6 +64,59 @@ static struct ftrace_ops pstore_ftrace_ops __read_mostly = {
.func = pstore_ftrace_call,
};
+void notrace pstore_event_call(struct trace_event_buffer *fbuffer)
+{
+ struct trace_iterator *iter;
+ struct trace_seq *s;
+ struct trace_event_call *event_call;
+ struct pstore_record record;
+ struct trace_event *event;
+ struct seq_buf *seq;
+ unsigned long flags;
+
+ if (!psinfo)
+ return;
+
+ if (unlikely(oops_in_progress))
+ return;
+
+ pstore_record_init(, psinfo);
+ record.type = PSTORE_TYPE_EVENT;
+
+ iter = kmalloc(sizeof(*iter), GFP_KERNEL);
+ if (!iter)
+ return;
+
+ event_call = fbuffer->trace_file->event_call;
+ if (!event_call || !event_call->event.funcs ||
+ !event_call->event.funcs->trace)
+ goto fail_event;
+
+ event = >trace_file->event_call->event;
+
+ spin_lock_irqsave(>buf_lock, flags);
+
+ trace_seq_init(>seq);
+ iter->ent = fbuffer->entry;
+ event_call->event.funcs->trace(iter, 0, event);
+ trace_seq_putc(>seq, 0);
+
+ if (seq->size > psinfo->bufsize)
+ seq->size = psinfo->bufsize;
+
+ s = >seq;
+ seq = >seq;
+
+ record.buf = (char *)(seq->buffer);
+ record.size = seq->len;
+ psinfo->write();
+
+ spin_unlock_irqrestore(>buf_lock, flags);
+
+fail_event:
+ kfree(iter);
+}
+
static DEFINE_MUTEX(pstore_ftrace_lock);
static bool pstore_ftrace_enabled;
diff --git a/fs/pstore/inode.c b/fs/pstore/inode.c
index 5fcb845b9fec..f099152abbbd 100644
--- a/fs/pstore/inode.c
+++ b/fs/pstore/inode.c
@@ -345,6 +345,10 @@ int pstore_mkfile(struct dentry *root, struct
pstore_record *record)
scnprintf(name, sizeof(name), "console-%s-%llu",
record->psi->name, record->id);
break;
+ case PSTORE_TYPE_EVENT:
+ scnprintf(name, sizeof(name), "event-%s-%llu",
+ record->psi->name, record->id);
+ break;
case PSTORE_TYPE_FTRACE:
scnprintf(name, sizeof(name), "ftrace-%s-%llu",
record->psi->name, record->id);
[PATCH 4/6] arm64/io: Add tracepoint for register accesses
Generic IO read/write i.e., __raw_{read,write}{b,l,w,q} are
typically used to read/write from/to memory mapped registers,
which can cause hangs or some undefined behaviour if access
unclocked. Tracing these register accesses can be very helpful
to debug such issues during initial development stages.
This can be used later for tracing arm IO register accesses.
Sample output format of register access trace is below:
io_write: type=writel cpu=3 ts:1424714326 data=0x0d1065a4
caller=qcom_smsm_probe+0x52c/0x678
io_write: type=writel cpu=3 ts:1424962659 data=0x0d106608
caller=qcom_smsm_probe+0x52c/0x678
Signed-off-by: Sai Prakash Ranjan
---
arch/arm64/kernel/io.c | 22 +++
include/asm-generic/io-trace.h | 70 ++
2 files changed, 92 insertions(+)
create mode 100644 include/asm-generic/io-trace.h
diff --git a/arch/arm64/kernel/io.c b/arch/arm64/kernel/io.c
index 79b17384effa..a9db07f66477 100644
--- a/arch/arm64/kernel/io.c
+++ b/arch/arm64/kernel/io.c
@@ -19,6 +19,10 @@
#include
#include
#include
+#include
+
+#define CREATE_TRACE_POINTS
+#include
/*
* Copy data from IO memory space to "real" memory space.
@@ -106,3 +110,21 @@ void __memset_io(volatile void __iomem *dst, int c, size_t
count)
}
}
EXPORT_SYMBOL(__memset_io);
+
+#if defined(CONFIG_TRACING_EVENTS_IO)
+void do_trace_io_write(const char *type, void *addr)
+{
+ trace_io_write(type, raw_smp_processor_id(), sched_clock(), addr,
+ _RET_IP_);
+}
+EXPORT_SYMBOL(do_trace_io_write);
+EXPORT_TRACEPOINT_SYMBOL(io_write);
+
+void do_trace_io_read(const char *type, void *addr)
+{
+ trace_io_read(type, raw_smp_processor_id(), sched_clock(), addr,
+ _RET_IP_);
+}
+EXPORT_SYMBOL(do_trace_io_read);
+EXPORT_TRACEPOINT_SYMBOL(io_read);
+#endif
diff --git a/include/asm-generic/io-trace.h b/include/asm-generic/io-trace.h
new file mode 100644
index ..e57b52d8976a
--- /dev/null
+++ b/include/asm-generic/io-trace.h
@@ -0,0 +1,70 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#undef TRACE_SYSTEM
+#define TRACE_SYSTEM io
+
+#if !defined(CONFIG_TRACING_EVENTS_IO)
+#define NOTRACE
+#endif
+
+#undef TRACE_INCLUDE_FILE
+#define TRACE_INCLUDE_FILE io-trace
+
+#undef TRACE_INCLUDE_PATH
+#define TRACE_INCLUDE_PATH asm-generic
+
+#if !defined(_TRACE_IO_H) || defined(TRACE_HEADER_MULTI_READ)
+#define _TRACE_IO_H
+
+#include
+
+/*
+ * Tracepoint for generic IO read/write, i.e., __raw_{read,write}{b,l,w,q}()
+ */
+DECLARE_EVENT_CLASS(io_trace_class,
+
+ TP_PROTO(const char *type, int cpu, u64 ts, void *addr,
+unsigned long ret_ip),
+
+ TP_ARGS(type, cpu, ts, addr, ret_ip),
+
+ TP_STRUCT__entry(
+ __string( type, type)
+ __field(int,cpu )
+ __field(u64,ts )
+ __field(void *, addr)
+ __field(unsigned long, ret_ip )
+ ),
+
+ TP_fast_assign(
+ __assign_str(type, type);
+ __entry->cpu= cpu;
+ __entry->ts = ts;
+ __entry->addr = addr;
+ __entry->ret_ip = ret_ip;
+ ),
+
+ TP_printk("type=%s cpu=%d ts:%llu data=0x%lx caller=%pS",
+ __get_str(type), __entry->cpu, __entry->ts,
+ (unsigned long)__entry->addr, (void *)__entry->ret_ip)
+);
+
+DEFINE_EVENT(io_trace_class, io_read,
+
+ TP_PROTO(const char *type, int cpu, u64 ts, void *addr,
+unsigned long ret_ip),
+
+ TP_ARGS(type, cpu, ts, addr, ret_ip)
+);
+
+DEFINE_EVENT(io_trace_class, io_write,
+
+ TP_PROTO(const char *type, int cpu, u64 ts, void *addr,
+unsigned long ret_ip),
+
+ TP_ARGS(type, cpu, ts, addr, ret_ip)
+);
+
+#endif /* _TRACE_IO_H */
+
+/* This part must be outside protection */
+#include
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
[PATCH 2/6] pstore: Add event tracing support
Currently pstore has function trace support which can be
used to get the function call chain with limited data.
Event tracing has extra data which is useful to debug wide
variety of issues and is heavily used across the kernel.
Adding this support to pstore can be very helpful to debug
different subsystems since almost all of them have trace
events already available. And also it is useful to debug
unknown resets or crashes since we can get lot more info
from event tracing by viewing the last occurred events.
High frequency tracepoints such as sched and irq has also
been tested. This implementation is similar to "tp_printk"
command line feature of ftrace by Steven.
For example, sample pstore output of tracing sched events
after reboot:
# mount -t pstore pstore /sys/fs/pstore/
# tail /sys/fs/pstore/event-ramoops-0
sched_switch: prev_comm=swapper/1 prev_pid=0 prev_prio=120 prev_state=S ==>
next_comm=rcu_preempt next_pid=10 next_prio=120
sched_switch: prev_comm=rcu_preempt prev_pid=10 prev_prio=120 prev_state=R+
==> next_comm=swapper/1 next_pid=0 next_prio=120
sched_waking: comm=rcu_sched pid=11 prio=120 target_cpu=002
sched_wakeup: comm=rcu_sched pid=11 prio=120 target_cpu=002
sched_switch: prev_comm=swapper/2 prev_pid=0 prev_prio=120 prev_state=S ==>
next_comm=rcu_sched next_pid=11 next_prio=120
sched_switch: prev_comm=rcu_sched prev_pid=11 prev_prio=120 prev_state=R+ ==>
next_comm=swapper/2 next_pid=0 next_prio=120
sched_waking: comm=reboot pid=1867 prio=120 target_cpu=000
sched_wakeup: comm=reboot pid=1867 prio=120 target_cpu=000
sched_switch: prev_comm=swapper/0 prev_pid=0 prev_prio=120 prev_state=S ==>
next_comm=reboot next_pid=1867 next_prio=120
Signed-off-by: Sai Prakash Ranjan
---
fs/pstore/Kconfig | 2 +-
fs/pstore/ftrace.c | 55 ++
fs/pstore/inode.c | 4 +++
fs/pstore/ram.c| 44 +++---
include/linux/pstore.h | 2 ++
include/linux/pstore_ram.h | 1 +
6 files changed, 104 insertions(+), 4 deletions(-)
diff --git a/fs/pstore/Kconfig b/fs/pstore/Kconfig
index 503086f7f7c1..6fe087b13a51 100644
--- a/fs/pstore/Kconfig
+++ b/fs/pstore/Kconfig
@@ -126,7 +126,7 @@ config PSTORE_PMSG
config PSTORE_FTRACE
bool "Persistent function tracer"
- depends on PSTORE
+ depends on PSTORE && PSTORE!=m
depends on FUNCTION_TRACER
depends on DEBUG_FS
help
diff --git a/fs/pstore/ftrace.c b/fs/pstore/ftrace.c
index 06aab07b6bb7..d47dc93ac098 100644
--- a/fs/pstore/ftrace.c
+++ b/fs/pstore/ftrace.c
@@ -24,6 +24,8 @@
#include
#include
#include
+#include
+#include
#include
#include "internal.h"
@@ -62,6 +64,59 @@ static struct ftrace_ops pstore_ftrace_ops __read_mostly = {
.func = pstore_ftrace_call,
};
+void notrace pstore_event_call(struct trace_event_buffer *fbuffer)
+{
+ struct trace_iterator *iter;
+ struct trace_seq *s;
+ struct trace_event_call *event_call;
+ struct pstore_record record;
+ struct trace_event *event;
+ struct seq_buf *seq;
+ unsigned long flags;
+
+ if (!psinfo)
+ return;
+
+ if (unlikely(oops_in_progress))
+ return;
+
+ pstore_record_init(, psinfo);
+ record.type = PSTORE_TYPE_EVENT;
+
+ iter = kmalloc(sizeof(*iter), GFP_KERNEL);
+ if (!iter)
+ return;
+
+ event_call = fbuffer->trace_file->event_call;
+ if (!event_call || !event_call->event.funcs ||
+ !event_call->event.funcs->trace)
+ goto fail_event;
+
+ event = >trace_file->event_call->event;
+
+ spin_lock_irqsave(>buf_lock, flags);
+
+ trace_seq_init(>seq);
+ iter->ent = fbuffer->entry;
+ event_call->event.funcs->trace(iter, 0, event);
+ trace_seq_putc(>seq, 0);
+
+ if (seq->size > psinfo->bufsize)
+ seq->size = psinfo->bufsize;
+
+ s = >seq;
+ seq = >seq;
+
+ record.buf = (char *)(seq->buffer);
+ record.size = seq->len;
+ psinfo->write();
+
+ spin_unlock_irqrestore(>buf_lock, flags);
+
+fail_event:
+ kfree(iter);
+}
+
static DEFINE_MUTEX(pstore_ftrace_lock);
static bool pstore_ftrace_enabled;
diff --git a/fs/pstore/inode.c b/fs/pstore/inode.c
index 5fcb845b9fec..f099152abbbd 100644
--- a/fs/pstore/inode.c
+++ b/fs/pstore/inode.c
@@ -345,6 +345,10 @@ int pstore_mkfile(struct dentry *root, struct
pstore_record *record)
scnprintf(name, sizeof(name), "console-%s-%llu",
record->psi->name, record->id);
break;
+ case PSTORE_TYPE_EVENT:
+ scnprintf(name, sizeof(name), "event-%s-%llu",
+ record->psi->name, record->id);
+ break;
case PSTORE_TYPE_FTRACE:
scnprintf(name, sizeof(name), "ftrace-%s-%llu",
record->psi->name, record->id);
[PATCH 4/6] arm64/io: Add tracepoint for register accesses
Generic IO read/write i.e., __raw_{read,write}{b,l,w,q} are
typically used to read/write from/to memory mapped registers,
which can cause hangs or some undefined behaviour if access
unclocked. Tracing these register accesses can be very helpful
to debug such issues during initial development stages.
This can be used later for tracing arm IO register accesses.
Sample output format of register access trace is below:
io_write: type=writel cpu=3 ts:1424714326 data=0x0d1065a4
caller=qcom_smsm_probe+0x52c/0x678
io_write: type=writel cpu=3 ts:1424962659 data=0x0d106608
caller=qcom_smsm_probe+0x52c/0x678
Signed-off-by: Sai Prakash Ranjan
---
arch/arm64/kernel/io.c | 22 +++
include/asm-generic/io-trace.h | 70 ++
2 files changed, 92 insertions(+)
create mode 100644 include/asm-generic/io-trace.h
diff --git a/arch/arm64/kernel/io.c b/arch/arm64/kernel/io.c
index 79b17384effa..a9db07f66477 100644
--- a/arch/arm64/kernel/io.c
+++ b/arch/arm64/kernel/io.c
@@ -19,6 +19,10 @@
#include
#include
#include
+#include
+
+#define CREATE_TRACE_POINTS
+#include
/*
* Copy data from IO memory space to "real" memory space.
@@ -106,3 +110,21 @@ void __memset_io(volatile void __iomem *dst, int c, size_t
count)
}
}
EXPORT_SYMBOL(__memset_io);
+
+#if defined(CONFIG_TRACING_EVENTS_IO)
+void do_trace_io_write(const char *type, void *addr)
+{
+ trace_io_write(type, raw_smp_processor_id(), sched_clock(), addr,
+ _RET_IP_);
+}
+EXPORT_SYMBOL(do_trace_io_write);
+EXPORT_TRACEPOINT_SYMBOL(io_write);
+
+void do_trace_io_read(const char *type, void *addr)
+{
+ trace_io_read(type, raw_smp_processor_id(), sched_clock(), addr,
+ _RET_IP_);
+}
+EXPORT_SYMBOL(do_trace_io_read);
+EXPORT_TRACEPOINT_SYMBOL(io_read);
+#endif
diff --git a/include/asm-generic/io-trace.h b/include/asm-generic/io-trace.h
new file mode 100644
index ..e57b52d8976a
--- /dev/null
+++ b/include/asm-generic/io-trace.h
@@ -0,0 +1,70 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#undef TRACE_SYSTEM
+#define TRACE_SYSTEM io
+
+#if !defined(CONFIG_TRACING_EVENTS_IO)
+#define NOTRACE
+#endif
+
+#undef TRACE_INCLUDE_FILE
+#define TRACE_INCLUDE_FILE io-trace
+
+#undef TRACE_INCLUDE_PATH
+#define TRACE_INCLUDE_PATH asm-generic
+
+#if !defined(_TRACE_IO_H) || defined(TRACE_HEADER_MULTI_READ)
+#define _TRACE_IO_H
+
+#include
+
+/*
+ * Tracepoint for generic IO read/write, i.e., __raw_{read,write}{b,l,w,q}()
+ */
+DECLARE_EVENT_CLASS(io_trace_class,
+
+ TP_PROTO(const char *type, int cpu, u64 ts, void *addr,
+unsigned long ret_ip),
+
+ TP_ARGS(type, cpu, ts, addr, ret_ip),
+
+ TP_STRUCT__entry(
+ __string( type, type)
+ __field(int,cpu )
+ __field(u64,ts )
+ __field(void *, addr)
+ __field(unsigned long, ret_ip )
+ ),
+
+ TP_fast_assign(
+ __assign_str(type, type);
+ __entry->cpu= cpu;
+ __entry->ts = ts;
+ __entry->addr = addr;
+ __entry->ret_ip = ret_ip;
+ ),
+
+ TP_printk("type=%s cpu=%d ts:%llu data=0x%lx caller=%pS",
+ __get_str(type), __entry->cpu, __entry->ts,
+ (unsigned long)__entry->addr, (void *)__entry->ret_ip)
+);
+
+DEFINE_EVENT(io_trace_class, io_read,
+
+ TP_PROTO(const char *type, int cpu, u64 ts, void *addr,
+unsigned long ret_ip),
+
+ TP_ARGS(type, cpu, ts, addr, ret_ip)
+);
+
+DEFINE_EVENT(io_trace_class, io_write,
+
+ TP_PROTO(const char *type, int cpu, u64 ts, void *addr,
+unsigned long ret_ip),
+
+ TP_ARGS(type, cpu, ts, addr, ret_ip)
+);
+
+#endif /* _TRACE_IO_H */
+
+/* This part must be outside protection */
+#include
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
[PATCH 1/6] dt-bindings: ramoops: Add event-size property
Add an optional property called event-size to reserve log buffer for trace events. Signed-off-by: Sai Prakash Ranjan --- .../devicetree/bindings/reserved-memory/ramoops.txt| 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/Documentation/devicetree/bindings/reserved-memory/ramoops.txt b/Documentation/devicetree/bindings/reserved-memory/ramoops.txt index 0eba562fe5c6..4f835ef65635 100644 --- a/Documentation/devicetree/bindings/reserved-memory/ramoops.txt +++ b/Documentation/devicetree/bindings/reserved-memory/ramoops.txt @@ -14,8 +14,8 @@ Any remaining space will be used for a circular buffer of oops and panic records. These records have a configurable size, with a size of 0 indicating that they should be disabled. -At least one of "record-size", "console-size", "ftrace-size", or "pmsg-size" -must be set non-zero, but are otherwise optional as listed below. +At least one of "record-size", "console-size", "event-size", "ftrace-size", or +"pmsg-size" must be set non-zero, but are otherwise optional as listed below. Required properties: @@ -36,6 +36,9 @@ Optional properties: - console-size: size in bytes of log buffer reserved for kernel messages (defaults to 0: disabled) +- event-size: size in bytes of log buffer reserved for trace events + (defaults to 0: disabled) + - ftrace-size: size in bytes of log buffer reserved for function tracing and profiling (defaults to 0: disabled) -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
[PATCH 3/6] tracing: Add tp_pstore cmdline to have tracepoints go to pstore
Add the kernel command line tp_pstore option that will have
tracepoints go to persistent ram buffer as well as to the
trace buffer for further debugging. This is similar to tp_printk
cmdline option of ftrace.
Pstore support for event tracing is already added and we enable
logging to pstore only if cmdline is specified.
Passing "tp_pstore" will activate logging to pstore. To turn it
off, the sysctl /proc/sys/kernel/tracepoint_pstore can have '0'
echoed into it. Note, this only works if the cmdline option is
used. Echoing 1 into the sysctl file without the cmdline option
will have no affect.
Signed-off-by: Sai Prakash Ranjan
---
.../admin-guide/kernel-parameters.txt | 21
include/linux/ftrace.h| 6 ++-
kernel/sysctl.c | 7 +++
kernel/trace/Kconfig | 22 +++-
kernel/trace/trace.c | 51 +++
kernel/trace/trace.h | 7 +++
6 files changed, 112 insertions(+), 2 deletions(-)
diff --git a/Documentation/admin-guide/kernel-parameters.txt
b/Documentation/admin-guide/kernel-parameters.txt
index 9871e649ffef..622cf64d4e5b 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -4519,6 +4519,27 @@
frequency tracepoints such as irq or sched, can cause
the system to live lock.
+ tp_pstore[FTRACE]
+ Have the tracepoints sent to persistent ram buffer for
+ debugging. This is useful for debugging early boot up
+ and other kernel issues where the system hangs or
+ reboots due to some unclocked access or some buggy
+ driver. Instead of spamming the console with unwanted
+ logs, we can send the logs to pstore buffer for further
+ debugging.
+
+ Last occurred events in the pstore log will be helpful
+ in identifying the reset cause.
+
+ For example, to trace sched event, add to the command
+ line:
+ trace_event=sched tp_pstore
+
+ To turn off having tracepoints sent to pstore,
+ echo 0 > /proc/sys/kernel/tracepoint_pstore
+ Note, echoing 1 into this file without the
+ tracepoint_pstore kernel cmdline option has no effect.
+
traceoff_on_warning
[FTRACE] enable this option to disable tracing when a
warning is hit. This turns off "tracing_on". Tracing can
diff --git a/include/linux/ftrace.h b/include/linux/ftrace.h
index a397907e8d72..7c3074e7ec6b 100644
--- a/include/linux/ftrace.h
+++ b/include/linux/ftrace.h
@@ -900,6 +900,7 @@ enum ftrace_dump_mode;
extern enum ftrace_dump_mode ftrace_dump_on_oops;
extern int tracepoint_printk;
+extern int tracepoint_pstore;
extern void disable_trace_on_warning(void);
extern int __disable_trace_on_warning;
@@ -907,9 +908,12 @@ extern int __disable_trace_on_warning;
int tracepoint_printk_sysctl(struct ctl_table *table, int write,
void __user *buffer, size_t *lenp,
loff_t *ppos);
+int tracepoint_pstore_sysctl(struct ctl_table *table, int write,
+void __user *buffer, size_t *lenp,
+loff_t *ppos);
#else /* CONFIG_TRACING */
-static inline void disable_trace_on_warning(void) { }
+static inline void disable_trace_on_warning(void) { }
#endif /* CONFIG_TRACING */
#ifdef CONFIG_FTRACE_SYSCALLS
diff --git a/kernel/sysctl.c b/kernel/sysctl.c
index cc02050fd0c4..3cc1223b8955 100644
--- a/kernel/sysctl.c
+++ b/kernel/sysctl.c
@@ -653,6 +653,13 @@ static struct ctl_table kern_table[] = {
.mode = 0644,
.proc_handler = tracepoint_printk_sysctl,
},
+ {
+ .procname = "tracepoint_pstore",
+ .data = _pstore,
+ .maxlen = sizeof(tracepoint_pstore),
+ .mode = 0644,
+ .proc_handler = tracepoint_pstore_sysctl,
+ },
#endif
#ifdef CONFIG_KEXEC_CORE
{
diff --git a/kernel/trace/Kconfig b/kernel/trace/Kconfig
index 5e3de28c7677..d0eed268ee85 100644
--- a/kernel/trace/Kconfig
+++ b/kernel/trace/Kconfig
@@ -774,6 +774,27 @@ config TRACING_EVENTS_GPIO
help
Enable tracing events for gpio subsystem
+config TRACING_EVENTS_IO
+ bool "Trace IO read/write events"
+ help
+ Enable tracing events for IO read/write operations.
+ This is useful for debugging random hangs or resets
+ caused due to unclocked access or some buggy driver.
+
+ Output of this trace event
[PATCH 1/6] dt-bindings: ramoops: Add event-size property
Add an optional property called event-size to reserve log buffer for trace events. Signed-off-by: Sai Prakash Ranjan --- .../devicetree/bindings/reserved-memory/ramoops.txt| 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/Documentation/devicetree/bindings/reserved-memory/ramoops.txt b/Documentation/devicetree/bindings/reserved-memory/ramoops.txt index 0eba562fe5c6..4f835ef65635 100644 --- a/Documentation/devicetree/bindings/reserved-memory/ramoops.txt +++ b/Documentation/devicetree/bindings/reserved-memory/ramoops.txt @@ -14,8 +14,8 @@ Any remaining space will be used for a circular buffer of oops and panic records. These records have a configurable size, with a size of 0 indicating that they should be disabled. -At least one of "record-size", "console-size", "ftrace-size", or "pmsg-size" -must be set non-zero, but are otherwise optional as listed below. +At least one of "record-size", "console-size", "event-size", "ftrace-size", or +"pmsg-size" must be set non-zero, but are otherwise optional as listed below. Required properties: @@ -36,6 +36,9 @@ Optional properties: - console-size: size in bytes of log buffer reserved for kernel messages (defaults to 0: disabled) +- event-size: size in bytes of log buffer reserved for trace events + (defaults to 0: disabled) + - ftrace-size: size in bytes of log buffer reserved for function tracing and profiling (defaults to 0: disabled) -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
[PATCH 3/6] tracing: Add tp_pstore cmdline to have tracepoints go to pstore
Add the kernel command line tp_pstore option that will have
tracepoints go to persistent ram buffer as well as to the
trace buffer for further debugging. This is similar to tp_printk
cmdline option of ftrace.
Pstore support for event tracing is already added and we enable
logging to pstore only if cmdline is specified.
Passing "tp_pstore" will activate logging to pstore. To turn it
off, the sysctl /proc/sys/kernel/tracepoint_pstore can have '0'
echoed into it. Note, this only works if the cmdline option is
used. Echoing 1 into the sysctl file without the cmdline option
will have no affect.
Signed-off-by: Sai Prakash Ranjan
---
.../admin-guide/kernel-parameters.txt | 21
include/linux/ftrace.h| 6 ++-
kernel/sysctl.c | 7 +++
kernel/trace/Kconfig | 22 +++-
kernel/trace/trace.c | 51 +++
kernel/trace/trace.h | 7 +++
6 files changed, 112 insertions(+), 2 deletions(-)
diff --git a/Documentation/admin-guide/kernel-parameters.txt
b/Documentation/admin-guide/kernel-parameters.txt
index 9871e649ffef..622cf64d4e5b 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -4519,6 +4519,27 @@
frequency tracepoints such as irq or sched, can cause
the system to live lock.
+ tp_pstore[FTRACE]
+ Have the tracepoints sent to persistent ram buffer for
+ debugging. This is useful for debugging early boot up
+ and other kernel issues where the system hangs or
+ reboots due to some unclocked access or some buggy
+ driver. Instead of spamming the console with unwanted
+ logs, we can send the logs to pstore buffer for further
+ debugging.
+
+ Last occurred events in the pstore log will be helpful
+ in identifying the reset cause.
+
+ For example, to trace sched event, add to the command
+ line:
+ trace_event=sched tp_pstore
+
+ To turn off having tracepoints sent to pstore,
+ echo 0 > /proc/sys/kernel/tracepoint_pstore
+ Note, echoing 1 into this file without the
+ tracepoint_pstore kernel cmdline option has no effect.
+
traceoff_on_warning
[FTRACE] enable this option to disable tracing when a
warning is hit. This turns off "tracing_on". Tracing can
diff --git a/include/linux/ftrace.h b/include/linux/ftrace.h
index a397907e8d72..7c3074e7ec6b 100644
--- a/include/linux/ftrace.h
+++ b/include/linux/ftrace.h
@@ -900,6 +900,7 @@ enum ftrace_dump_mode;
extern enum ftrace_dump_mode ftrace_dump_on_oops;
extern int tracepoint_printk;
+extern int tracepoint_pstore;
extern void disable_trace_on_warning(void);
extern int __disable_trace_on_warning;
@@ -907,9 +908,12 @@ extern int __disable_trace_on_warning;
int tracepoint_printk_sysctl(struct ctl_table *table, int write,
void __user *buffer, size_t *lenp,
loff_t *ppos);
+int tracepoint_pstore_sysctl(struct ctl_table *table, int write,
+void __user *buffer, size_t *lenp,
+loff_t *ppos);
#else /* CONFIG_TRACING */
-static inline void disable_trace_on_warning(void) { }
+static inline void disable_trace_on_warning(void) { }
#endif /* CONFIG_TRACING */
#ifdef CONFIG_FTRACE_SYSCALLS
diff --git a/kernel/sysctl.c b/kernel/sysctl.c
index cc02050fd0c4..3cc1223b8955 100644
--- a/kernel/sysctl.c
+++ b/kernel/sysctl.c
@@ -653,6 +653,13 @@ static struct ctl_table kern_table[] = {
.mode = 0644,
.proc_handler = tracepoint_printk_sysctl,
},
+ {
+ .procname = "tracepoint_pstore",
+ .data = _pstore,
+ .maxlen = sizeof(tracepoint_pstore),
+ .mode = 0644,
+ .proc_handler = tracepoint_pstore_sysctl,
+ },
#endif
#ifdef CONFIG_KEXEC_CORE
{
diff --git a/kernel/trace/Kconfig b/kernel/trace/Kconfig
index 5e3de28c7677..d0eed268ee85 100644
--- a/kernel/trace/Kconfig
+++ b/kernel/trace/Kconfig
@@ -774,6 +774,27 @@ config TRACING_EVENTS_GPIO
help
Enable tracing events for gpio subsystem
+config TRACING_EVENTS_IO
+ bool "Trace IO read/write events"
+ help
+ Enable tracing events for IO read/write operations.
+ This is useful for debugging random hangs or resets
+ caused due to unclocked access or some buggy driver.
+
+ Output of this trace event
[PATCH 0/6] Tracing register accesses with pstore and dynamic debug
Hi,
This patch series adds Event tracing support to pstore and is continuation
to the RFC patch introduced to add a new tracing facility for register
accesses called Register Trace Buffer(RTB). Since we decided to not introduce
a separate framework to trace register accesses and use existing framework
like tracepoints, I have moved from RFC. Details of the RFC in link below:
Link:
https://lore.kernel.org/lkml/cover.1535119710.git.saiprakash.ran...@codeaurora.org/
MSR tracing example given by Steven was helpful in using tracepoints for
register accesses instead of using separate trace. But just having these
IO traces would not help much unless we could have them in some persistent
ram buffer for debugging unclocked access or some kind of bus hang or an
unexpected reset caused by some buggy driver which happens a lot during
initial development stages. By analyzing the last few entries of this buffer,
we could identify the register access which is causing the issue.
But again, adding pstore support for just one such event would be unacceptable.
Instead, add pstore support for all events since event tracing is widely used
across the kernel to debug variety of issues and adding this support would be
really useful for such purposes.
In addition to this, provide dynamic debug support to filter out unwanted logs
and limit trace to only specific files or directories since there can be
aweful lot of register trace events and we will be interested only in specific
drivers or subsystems which we will be working on. So introduce a new flag "e"
to filter these event tracing to specified input. Currently only register
access trace for arm64 will have this support but this could be expanded later
to other events also if required.
First example below shows the use of tracing events with pstore support. Here
we trace sched events:
# trace_event=sched tp_pstore in command line
# reboot -f
# mount -t pstore pstore /sys/fs/pstore/
# tail /sys/fs/pstore/event-ramoops-0
sched_switch: prev_comm=swapper/1 prev_pid=0 prev_prio=120 prev_state=S ==>
next_comm=rcu_preempt next_pid=10 next_prio=120
sched_switch: prev_comm=rcu_preempt prev_pid=10 prev_prio=120 prev_state=R+
==> next_comm=swapper/1 next_pid=0 next_prio=120
sched_waking: comm=rcu_sched pid=11 prio=120 target_cpu=002
sched_wakeup: comm=rcu_sched pid=11 prio=120 target_cpu=002
sched_switch: prev_comm=swapper/2 prev_pid=0 prev_prio=120 prev_state=S ==>
next_comm=rcu_sched next_pid=11 next_prio=120
sched_switch: prev_comm=rcu_sched prev_pid=11 prev_prio=120 prev_state=R+ ==>
next_comm=swapper/2 next_pid=0 next_prio=120
sched_waking: comm=reboot pid=1867 prio=120 target_cpu=000
sched_wakeup: comm=reboot pid=1867 prio=120 target_cpu=000
sched_switch: prev_comm=swapper/0 prev_pid=0 prev_prio=120 prev_state=S ==>
next_comm=reboot next_pid=1867 next_prio=120
We can get more details for debugging as we can see from the above pstore
output.
Below is the second example for identifying the root cause of bus hang in
qcom mdp tested on db410c. This hang was intentionally introduced just to
show the usecase of tracing with pstore. The module used can be found here:
https://github.com/saiprakash-ranjan/Bus-Hang
This does an unclocked access and will reset db410c and later logs can be
viewed through pstore. Here we manually specify the path to trace in kernel
command line.
Note: For testing purpose, I just copied bus_hang.c to drivers/soc/qcom and
built it.
1) Set command line with dyndbg, trace_event and tp_pstore parameter as below:
# dyndbg="file drivers/soc/qcom/* +e" trace_event=io tp_pstore
2) Bus hang by reading below debugfs entry with bus_hang module.
# cat /sys/kernel/debug/hang/bus_hang
3) After restart, we can find the cause in last entry i.e.
(bus_hang_mdp+0xa4/0xb8)
# cat /sys/fs/pstore/event-ramoops-0
io_write: type=writel cpu=0 ts:1423426774 data=0x0d5065a4
caller=qcom_smsm_probe+0x52c/0x678
io_write: type=writel cpu=0 ts:1423649847 data=0x0d506608
caller=qcom_smsm_probe+0x52c/0x678
io_read: type=readl cpu=1 ts:53095994171 data=0x0a51d040
caller=bus_hang_mdp+0xa4/0xb8
4) Offending register access found as below:
# (gdb)
# (gdb) list *(bus_hang_mdp+0xa4)
# 0x0867cdc8 is in bus_hang_mdp (drivers/soc/qcom/bus_hang.c:10).
# 5 static int bus_hang_mdp(void *data, u64 *val)
# 6 {
# 7 void *p = ioremap(0x01a01000, SZ_4K);
# 8 unsigned int a;
# 9
# 10 a = __raw_readl((void *)((unsigned long)p + 0x40)); <
# 11
# 12 *val = a;
# 13
# 14 return 0;
# (gdb)
Patchwise oneline description is given below:
Patch 1 adds event-size property to dt-bindings of ramoops.
Patch 2 adds generic event tracing support to pstore.
Patch 3 adds tp_pstore cmdline to have tracepoints go to pstore.
Patch 4 adds tracepoint for register accesses, i.e. for (read/write{b,w,l,q}).
[PATCH 0/6] Tracing register accesses with pstore and dynamic debug
Hi,
This patch series adds Event tracing support to pstore and is continuation
to the RFC patch introduced to add a new tracing facility for register
accesses called Register Trace Buffer(RTB). Since we decided to not introduce
a separate framework to trace register accesses and use existing framework
like tracepoints, I have moved from RFC. Details of the RFC in link below:
Link:
https://lore.kernel.org/lkml/cover.1535119710.git.saiprakash.ran...@codeaurora.org/
MSR tracing example given by Steven was helpful in using tracepoints for
register accesses instead of using separate trace. But just having these
IO traces would not help much unless we could have them in some persistent
ram buffer for debugging unclocked access or some kind of bus hang or an
unexpected reset caused by some buggy driver which happens a lot during
initial development stages. By analyzing the last few entries of this buffer,
we could identify the register access which is causing the issue.
But again, adding pstore support for just one such event would be unacceptable.
Instead, add pstore support for all events since event tracing is widely used
across the kernel to debug variety of issues and adding this support would be
really useful for such purposes.
In addition to this, provide dynamic debug support to filter out unwanted logs
and limit trace to only specific files or directories since there can be
aweful lot of register trace events and we will be interested only in specific
drivers or subsystems which we will be working on. So introduce a new flag "e"
to filter these event tracing to specified input. Currently only register
access trace for arm64 will have this support but this could be expanded later
to other events also if required.
First example below shows the use of tracing events with pstore support. Here
we trace sched events:
# trace_event=sched tp_pstore in command line
# reboot -f
# mount -t pstore pstore /sys/fs/pstore/
# tail /sys/fs/pstore/event-ramoops-0
sched_switch: prev_comm=swapper/1 prev_pid=0 prev_prio=120 prev_state=S ==>
next_comm=rcu_preempt next_pid=10 next_prio=120
sched_switch: prev_comm=rcu_preempt prev_pid=10 prev_prio=120 prev_state=R+
==> next_comm=swapper/1 next_pid=0 next_prio=120
sched_waking: comm=rcu_sched pid=11 prio=120 target_cpu=002
sched_wakeup: comm=rcu_sched pid=11 prio=120 target_cpu=002
sched_switch: prev_comm=swapper/2 prev_pid=0 prev_prio=120 prev_state=S ==>
next_comm=rcu_sched next_pid=11 next_prio=120
sched_switch: prev_comm=rcu_sched prev_pid=11 prev_prio=120 prev_state=R+ ==>
next_comm=swapper/2 next_pid=0 next_prio=120
sched_waking: comm=reboot pid=1867 prio=120 target_cpu=000
sched_wakeup: comm=reboot pid=1867 prio=120 target_cpu=000
sched_switch: prev_comm=swapper/0 prev_pid=0 prev_prio=120 prev_state=S ==>
next_comm=reboot next_pid=1867 next_prio=120
We can get more details for debugging as we can see from the above pstore
output.
Below is the second example for identifying the root cause of bus hang in
qcom mdp tested on db410c. This hang was intentionally introduced just to
show the usecase of tracing with pstore. The module used can be found here:
https://github.com/saiprakash-ranjan/Bus-Hang
This does an unclocked access and will reset db410c and later logs can be
viewed through pstore. Here we manually specify the path to trace in kernel
command line.
Note: For testing purpose, I just copied bus_hang.c to drivers/soc/qcom and
built it.
1) Set command line with dyndbg, trace_event and tp_pstore parameter as below:
# dyndbg="file drivers/soc/qcom/* +e" trace_event=io tp_pstore
2) Bus hang by reading below debugfs entry with bus_hang module.
# cat /sys/kernel/debug/hang/bus_hang
3) After restart, we can find the cause in last entry i.e.
(bus_hang_mdp+0xa4/0xb8)
# cat /sys/fs/pstore/event-ramoops-0
io_write: type=writel cpu=0 ts:1423426774 data=0x0d5065a4
caller=qcom_smsm_probe+0x52c/0x678
io_write: type=writel cpu=0 ts:1423649847 data=0x0d506608
caller=qcom_smsm_probe+0x52c/0x678
io_read: type=readl cpu=1 ts:53095994171 data=0x0a51d040
caller=bus_hang_mdp+0xa4/0xb8
4) Offending register access found as below:
# (gdb)
# (gdb) list *(bus_hang_mdp+0xa4)
# 0x0867cdc8 is in bus_hang_mdp (drivers/soc/qcom/bus_hang.c:10).
# 5 static int bus_hang_mdp(void *data, u64 *val)
# 6 {
# 7 void *p = ioremap(0x01a01000, SZ_4K);
# 8 unsigned int a;
# 9
# 10 a = __raw_readl((void *)((unsigned long)p + 0x40)); <
# 11
# 12 *val = a;
# 13
# 14 return 0;
# (gdb)
Patchwise oneline description is given below:
Patch 1 adds event-size property to dt-bindings of ramoops.
Patch 2 adds generic event tracing support to pstore.
Patch 3 adds tp_pstore cmdline to have tracepoints go to pstore.
Patch 4 adds tracepoint for register accesses, i.e. for (read/write{b,w,l,q}).
Re: [PATCH v8 1/2] leds: core: Introduce LED pattern trigger
Hi Bjorn, On 09/08/2018 07:02 AM, Bjorn Andersson wrote: > On Tue 04 Sep 04:01 PDT 2018, Baolin Wang wrote: > >> diff --git a/Documentation/ABI/testing/sysfs-class-led-trigger-pattern >> b/Documentation/ABI/testing/sysfs-class-led-trigger-pattern > [..] >> +What: /sys/class/leds//hw_pattern >> +Date: September 2018 >> +KernelVersion: 4.20 >> +Description: >> +Specify a hardware pattern for the LED, for LED hardware that >> +supports autonomously controlling brightness over time, >> according >> +to some preprogrammed hardware patterns. >> + >> +Since different LED hardware can have different semantics of >> +hardware patterns, each driver is expected to provide its own >> +description for the hardware patterns in their ABI documentation >> +file. >> + > > So, after a full circle we're back at drivers with support for hardware > patterns should have their own ABI for setting that pattern. > > The controls for my hardware is: > * a list of brightness values > * the rate of the pattern > * a flag to indicate that the pattern should be played from start > to end, end to start or start to end to start > * a boolean indicating if the pattern should be played once or repeated > indefinitely. > > Given that the interface now is hw specific, what benefit is there to > attempt to cram these 4 knobs into "hw_pattern"? Or am I allowed to > create additional files for the latter three? So this is an argument corroborating my concerns raised in [0]. I really think that we should allow for custom pattern interfaces defined by LED class drivers. >> +What: /sys/class/leds//repeat >> +Date: September 2018 >> +KernelVersion: 4.20 >> +Description: >> +Specify a pattern repeat number. 0 means repeat indefinitely. >> + >> +This file will always return the originally written repeat >> +number. > > I'm still convinced that this will confuse our users and to me it would > be more logical if this denotes the number of times the pattern should > be repeated, with e.g. negative numbers denoting infinite. Sounds reasonable. Let's change this semantics as you propose. > In particular I expect to have to explain why my driver expects that you > write 0 in the file named "repeat" to make it repeat and 1 to make it > not repeat. [0] https://lkml.org/lkml/2018/9/3/1192 -- Best regards, Jacek Anaszewski
Re: [PATCH v8 1/2] leds: core: Introduce LED pattern trigger
Hi Bjorn, On 09/08/2018 07:02 AM, Bjorn Andersson wrote: > On Tue 04 Sep 04:01 PDT 2018, Baolin Wang wrote: > >> diff --git a/Documentation/ABI/testing/sysfs-class-led-trigger-pattern >> b/Documentation/ABI/testing/sysfs-class-led-trigger-pattern > [..] >> +What: /sys/class/leds//hw_pattern >> +Date: September 2018 >> +KernelVersion: 4.20 >> +Description: >> +Specify a hardware pattern for the LED, for LED hardware that >> +supports autonomously controlling brightness over time, >> according >> +to some preprogrammed hardware patterns. >> + >> +Since different LED hardware can have different semantics of >> +hardware patterns, each driver is expected to provide its own >> +description for the hardware patterns in their ABI documentation >> +file. >> + > > So, after a full circle we're back at drivers with support for hardware > patterns should have their own ABI for setting that pattern. > > The controls for my hardware is: > * a list of brightness values > * the rate of the pattern > * a flag to indicate that the pattern should be played from start > to end, end to start or start to end to start > * a boolean indicating if the pattern should be played once or repeated > indefinitely. > > Given that the interface now is hw specific, what benefit is there to > attempt to cram these 4 knobs into "hw_pattern"? Or am I allowed to > create additional files for the latter three? So this is an argument corroborating my concerns raised in [0]. I really think that we should allow for custom pattern interfaces defined by LED class drivers. >> +What: /sys/class/leds//repeat >> +Date: September 2018 >> +KernelVersion: 4.20 >> +Description: >> +Specify a pattern repeat number. 0 means repeat indefinitely. >> + >> +This file will always return the originally written repeat >> +number. > > I'm still convinced that this will confuse our users and to me it would > be more logical if this denotes the number of times the pattern should > be repeated, with e.g. negative numbers denoting infinite. Sounds reasonable. Let's change this semantics as you propose. > In particular I expect to have to explain why my driver expects that you > write 0 in the file named "repeat" to make it repeat and 1 to make it > not repeat. [0] https://lkml.org/lkml/2018/9/3/1192 -- Best regards, Jacek Anaszewski
Re: [PATCH] sched/fair: fix 1 task per CPU
Hi Vincent,
On 07/09/18 08:40, Vincent Guittot wrote:
> When CPUs have different capacity because of RT/DL tasks or
> micro-architecture or max frequency differences, there are situation where
> the imbalance is not correctly set to migrate waiting task on the idle CPU.
>
This is essentially always for down migrations (high capacity src CPU to lower
capacity dst CPU), right?
For instance, I've often seen that issue on HiKey960 (4x4 big.LITTLE) where
if you spawn 8 CPU-hogs you can end up with 5 on the bigs and 3 on the
LITTLES, but since avg_load scales with the inverse of group_capacity it's
seen as balanced. I don't recall seeing this problem for low capacity ->
big capacity migration, especially with the misfit logic that makes this a
non-problem.
Also, a nit on the commit header: although we've called it "1 task per CPU"
in the past, it might be more explicit to call it "1 long running task per
CPU", if just for the sake of clarity for people not directly involved in
our previous discussions.
> The UC uses the force_balance case :
> if (env->idle != CPU_NOT_IDLE && group_has_capacity(env, local) &&
> busiest->group_no_capacity)
> goto force_balance;
>
> But calculate_imbalance fails to set the right amount of load to migrate
> a task because of the special condition:
> busiest->avg_load <= sds->avg_load || local->avg_load >= sds->avg_load)
>
> Add in fix_small_imbalance, this special case that triggered the force
> balance in order to make sure that the amount of load to migrate will be
> enough.
>
> Signed-off-by: Vincent Guittot
> ---
So we happen to have come up with a (relatively) similar patch for Android
(see [1]) which also stemmed from the 1 always running task per CPU issue. It
only applies to SD_ASYM_CPUCAPACITY sched domains though, and targets
down-migrations (local->group_capacity < busiest->group_capacity).
I'd argue that we should make it so this kind of imbalance gets detected way
before we hit fix_small_imbalance(), but until we get there I think we do want
an extra condition like this.
> kernel/sched/fair.c | 14 ++
> 1 file changed, 14 insertions(+)
>
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index 309c93f..57b4d83 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -8048,6 +8048,20 @@ void fix_small_imbalance(struct lb_env *env, struct
> sd_lb_stats *sds)
> local = >local_stat;
> busiest = >busiest_stat;
>
> + /*
> + * There is available capacity in local group and busiest group is
> + * overloaded but calculate_imbalance can't compute the amount of load
> + * to migrate because they became meaningless because asymetric
What do you mean by 'they'?
Also, s/because/due to/ on the second "because".
> + * capacity between group. In such case, we only want to migrate at
> + * least one tasks of the busiest group and rely of the average load
> + * per task to ensure the migration.
> + */
> + if (env->idle != CPU_NOT_IDLE && group_has_capacity(env, local) &&
> + busiest->group_no_capacity) {
> + env->imbalance = busiest->load_per_task;
> + return;
> + }
> +
The condition is an exact copy of the one in that goto force_balance
path you mention (in find_busiest_group()), is that just a coincidence? If
not you might want to mention it in the comment.
> if (!local->sum_nr_running)
> local->load_per_task = cpu_avg_load_per_task(env->dst_cpu);
> else if (busiest->load_per_task > local->load_per_task)
>
[1]:
https://android.googlesource.com/kernel/common/+/9fae72e924961f3b32816193fcb56d19c1f644c2%5E%21/#F0
Re: [PATCH] sched/fair: fix 1 task per CPU
Hi Vincent,
On 07/09/18 08:40, Vincent Guittot wrote:
> When CPUs have different capacity because of RT/DL tasks or
> micro-architecture or max frequency differences, there are situation where
> the imbalance is not correctly set to migrate waiting task on the idle CPU.
>
This is essentially always for down migrations (high capacity src CPU to lower
capacity dst CPU), right?
For instance, I've often seen that issue on HiKey960 (4x4 big.LITTLE) where
if you spawn 8 CPU-hogs you can end up with 5 on the bigs and 3 on the
LITTLES, but since avg_load scales with the inverse of group_capacity it's
seen as balanced. I don't recall seeing this problem for low capacity ->
big capacity migration, especially with the misfit logic that makes this a
non-problem.
Also, a nit on the commit header: although we've called it "1 task per CPU"
in the past, it might be more explicit to call it "1 long running task per
CPU", if just for the sake of clarity for people not directly involved in
our previous discussions.
> The UC uses the force_balance case :
> if (env->idle != CPU_NOT_IDLE && group_has_capacity(env, local) &&
> busiest->group_no_capacity)
> goto force_balance;
>
> But calculate_imbalance fails to set the right amount of load to migrate
> a task because of the special condition:
> busiest->avg_load <= sds->avg_load || local->avg_load >= sds->avg_load)
>
> Add in fix_small_imbalance, this special case that triggered the force
> balance in order to make sure that the amount of load to migrate will be
> enough.
>
> Signed-off-by: Vincent Guittot
> ---
So we happen to have come up with a (relatively) similar patch for Android
(see [1]) which also stemmed from the 1 always running task per CPU issue. It
only applies to SD_ASYM_CPUCAPACITY sched domains though, and targets
down-migrations (local->group_capacity < busiest->group_capacity).
I'd argue that we should make it so this kind of imbalance gets detected way
before we hit fix_small_imbalance(), but until we get there I think we do want
an extra condition like this.
> kernel/sched/fair.c | 14 ++
> 1 file changed, 14 insertions(+)
>
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index 309c93f..57b4d83 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -8048,6 +8048,20 @@ void fix_small_imbalance(struct lb_env *env, struct
> sd_lb_stats *sds)
> local = >local_stat;
> busiest = >busiest_stat;
>
> + /*
> + * There is available capacity in local group and busiest group is
> + * overloaded but calculate_imbalance can't compute the amount of load
> + * to migrate because they became meaningless because asymetric
What do you mean by 'they'?
Also, s/because/due to/ on the second "because".
> + * capacity between group. In such case, we only want to migrate at
> + * least one tasks of the busiest group and rely of the average load
> + * per task to ensure the migration.
> + */
> + if (env->idle != CPU_NOT_IDLE && group_has_capacity(env, local) &&
> + busiest->group_no_capacity) {
> + env->imbalance = busiest->load_per_task;
> + return;
> + }
> +
The condition is an exact copy of the one in that goto force_balance
path you mention (in find_busiest_group()), is that just a coincidence? If
not you might want to mention it in the comment.
> if (!local->sum_nr_running)
> local->load_per_task = cpu_avg_load_per_task(env->dst_cpu);
> else if (busiest->load_per_task > local->load_per_task)
>
[1]:
https://android.googlesource.com/kernel/common/+/9fae72e924961f3b32816193fcb56d19c1f644c2%5E%21/#F0
Re: [PATCH v6 1/2] dt-bindings: leds: Add bindings for lm3697 driver
Dan, On 09/07/2018 03:52 PM, Dan Murphy wrote: [...] >> >>> And I think Jacek pointed out that the bindings references in this bindings >>> don't even exist. >>> >>> I am thinking we need to deprecate this MFD driver and consolidate these >>> drivers >>> in the LED directory as we indicated before. I did not find any ti-lmu >>> support >>> code. >>> >>> ti-lmu common core code and then the LED children appending the feature >>> differentiation. >> >>> Need some maintainer weigh in here. >> >> Hehe. I'm maintnainer. Fun. > > I know. I want to see if there was any other opinion. Especially for the > LED driver. > [...] I have a question - is this lm3697 LED controller a cell of some MFD device? Or is it a self-contained chip? -- Best regards, Jacek Anaszewski
Re: [PATCH v6 1/2] dt-bindings: leds: Add bindings for lm3697 driver
Dan, On 09/07/2018 03:52 PM, Dan Murphy wrote: [...] >> >>> And I think Jacek pointed out that the bindings references in this bindings >>> don't even exist. >>> >>> I am thinking we need to deprecate this MFD driver and consolidate these >>> drivers >>> in the LED directory as we indicated before. I did not find any ti-lmu >>> support >>> code. >>> >>> ti-lmu common core code and then the LED children appending the feature >>> differentiation. >> >>> Need some maintainer weigh in here. >> >> Hehe. I'm maintnainer. Fun. > > I know. I want to see if there was any other opinion. Especially for the > LED driver. > [...] I have a question - is this lm3697 LED controller a cell of some MFD device? Or is it a self-contained chip? -- Best regards, Jacek Anaszewski
Re: [PATCH 2/5] gpio: davinci: Use dev name for label and automatic base selection
On 09/06/2018 09:16 AM, Keerthy wrote: > > > On Wednesday 05 September 2018 04:07 PM, Linus Walleij wrote: >> On Mon, Sep 3, 2018 at 7:40 AM Keerthy wrote: >>> On Saturday 01 September 2018 12:43 AM, Andrew F. Davis wrote: Use dev_name to get a unique label and use -1 for a base to get our selection automatically. We pull in all GPIOs per chip now so this does not have the effect of out of order labels like before. We do these both together so we can drop all the static data in one patch. This also lets us normalize the return paths as we don't need any cleanup after this change. >>> >>> echo 28 > /sys/class/gpio/export >>> / # echo 28 > /sys/class/gpi[ 12.839205] export_store: invalid GPIO 28 >>> o/export >>> echo 2 > /sys/class/gp[ 22.165728] export_store: invalid GPIO 2 >>> io/export >>> / # echo 1 > /sys/class/gp[ 25.961392] export_store: invalid GPIO 1 >>> io/export >>> / # echo 3 > /sys/class/gp[ 29.981918] export_store: invalid GPIO 3 >>> io/export >>> >>> Export fails with this patch. I am testing this on keystone-k2g-evm. >> >> I think the GPIO got a new number didn't it? >> >> Did you check the gpio file in debugfs to see which number >> it got. > > Okay now its numbered differently: > > cat /sys/class/gpio/gpiochip340/ngpio > 144 > > cat /sys/class/gpio/gpiochip272/ngpio > 68 could you or Andrew provide content of /debug/gpio before/after? And ls /sys/class/gpio/? > > So gpio bank2 and bank1 have different gpio numbers. Is that acceptable? > >> >> This is sadly the global numberspace that we are tying to >> get rid of (new apps/scripts should use the chardev). >> >> Are there applications that rely on the sysfs ABI on DaVinci? >> >> In that case base needs to be prerseved. Not only base, but label also - /sys/class/gpio/gpiochip0/label, as this is the way to find proper GPIO chip in sysfs using legacy GPIO ABI. Linus, this platform is old and most of the users do not use new ABI (chardev), so we could try change this, but need to be prepared for regressions reports. -- regards, -grygorii
Re: [PATCH 2/5] gpio: davinci: Use dev name for label and automatic base selection
On 09/06/2018 09:16 AM, Keerthy wrote: > > > On Wednesday 05 September 2018 04:07 PM, Linus Walleij wrote: >> On Mon, Sep 3, 2018 at 7:40 AM Keerthy wrote: >>> On Saturday 01 September 2018 12:43 AM, Andrew F. Davis wrote: Use dev_name to get a unique label and use -1 for a base to get our selection automatically. We pull in all GPIOs per chip now so this does not have the effect of out of order labels like before. We do these both together so we can drop all the static data in one patch. This also lets us normalize the return paths as we don't need any cleanup after this change. >>> >>> echo 28 > /sys/class/gpio/export >>> / # echo 28 > /sys/class/gpi[ 12.839205] export_store: invalid GPIO 28 >>> o/export >>> echo 2 > /sys/class/gp[ 22.165728] export_store: invalid GPIO 2 >>> io/export >>> / # echo 1 > /sys/class/gp[ 25.961392] export_store: invalid GPIO 1 >>> io/export >>> / # echo 3 > /sys/class/gp[ 29.981918] export_store: invalid GPIO 3 >>> io/export >>> >>> Export fails with this patch. I am testing this on keystone-k2g-evm. >> >> I think the GPIO got a new number didn't it? >> >> Did you check the gpio file in debugfs to see which number >> it got. > > Okay now its numbered differently: > > cat /sys/class/gpio/gpiochip340/ngpio > 144 > > cat /sys/class/gpio/gpiochip272/ngpio > 68 could you or Andrew provide content of /debug/gpio before/after? And ls /sys/class/gpio/? > > So gpio bank2 and bank1 have different gpio numbers. Is that acceptable? > >> >> This is sadly the global numberspace that we are tying to >> get rid of (new apps/scripts should use the chardev). >> >> Are there applications that rely on the sysfs ABI on DaVinci? >> >> In that case base needs to be prerseved. Not only base, but label also - /sys/class/gpio/gpiochip0/label, as this is the way to find proper GPIO chip in sysfs using legacy GPIO ABI. Linus, this platform is old and most of the users do not use new ABI (chardev), so we could try change this, but need to be prepared for regressions reports. -- regards, -grygorii
[PATCH] kernel/sched/core.c: Avoid unused variable on non-SMP configs
On non-SMP configs, when only one of CONFIG_{PARAVIRT,IRQ_TIME}_ACCOUNTING
is defined, we are declaring a variable (irq_delta or steal) which
is not used:
kernel/sched/core.c: In function ‘update_rq_clock_task’:
kernel/sched/core.c:139:17: warning: unused variable ‘irq_delta’
[-Wunused-variable]
s64 steal = 0, irq_delta = 0;
The reason is that CONFIG_SMP guards HAVE_SCHED_AVG_IRQ, which in turn
disables the code guarded by HAVE_SCHED_AVG_IRQ.
Cc: Ingo Molnar
Cc: Peter Zijlstra
Signed-off-by: Miguel Ojeda
---
kernel/sched/core.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 625bc9897f62..d662d1e11843 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -135,8 +135,11 @@ static void update_rq_clock_task(struct rq *rq, s64 delta)
* In theory, the compile should just see 0 here, and optimize out the call
* to sched_rt_avg_update. But I don't trust it...
*/
-#if defined(CONFIG_IRQ_TIME_ACCOUNTING) ||
defined(CONFIG_PARAVIRT_TIME_ACCOUNTING)
- s64 steal = 0, irq_delta = 0;
+#if defined(HAVE_SCHED_AVG_IRQ) || defined(CONFIG_IRQ_TIME_ACCOUNTING)
+ s64 irq_delta = 0;
+#endif
+#if defined(HAVE_SCHED_AVG_IRQ) || defined(CONFIG_PARAVIRT_TIME_ACCOUNTING)
+ s64 steal = 0;
#endif
#ifdef CONFIG_IRQ_TIME_ACCOUNTING
irq_delta = irq_time_read(cpu_of(rq)) - rq->prev_irq_time;
--
2.17.1
[PATCH] kernel/sched/core.c: Avoid unused variable on non-SMP configs
On non-SMP configs, when only one of CONFIG_{PARAVIRT,IRQ_TIME}_ACCOUNTING
is defined, we are declaring a variable (irq_delta or steal) which
is not used:
kernel/sched/core.c: In function ‘update_rq_clock_task’:
kernel/sched/core.c:139:17: warning: unused variable ‘irq_delta’
[-Wunused-variable]
s64 steal = 0, irq_delta = 0;
The reason is that CONFIG_SMP guards HAVE_SCHED_AVG_IRQ, which in turn
disables the code guarded by HAVE_SCHED_AVG_IRQ.
Cc: Ingo Molnar
Cc: Peter Zijlstra
Signed-off-by: Miguel Ojeda
---
kernel/sched/core.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 625bc9897f62..d662d1e11843 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -135,8 +135,11 @@ static void update_rq_clock_task(struct rq *rq, s64 delta)
* In theory, the compile should just see 0 here, and optimize out the call
* to sched_rt_avg_update. But I don't trust it...
*/
-#if defined(CONFIG_IRQ_TIME_ACCOUNTING) ||
defined(CONFIG_PARAVIRT_TIME_ACCOUNTING)
- s64 steal = 0, irq_delta = 0;
+#if defined(HAVE_SCHED_AVG_IRQ) || defined(CONFIG_IRQ_TIME_ACCOUNTING)
+ s64 irq_delta = 0;
+#endif
+#if defined(HAVE_SCHED_AVG_IRQ) || defined(CONFIG_PARAVIRT_TIME_ACCOUNTING)
+ s64 steal = 0;
#endif
#ifdef CONFIG_IRQ_TIME_ACCOUNTING
irq_delta = irq_time_read(cpu_of(rq)) - rq->prev_irq_time;
--
2.17.1
