Change Details

the calibrate_get_time() function used by do_encryption() -> get_standard_s2k_count() among others currently ends up using 100% cpu in what seems as an infinite loop on a system that has a tickless kernel configured like: CONFIG_NO_HZ_COMMON=y # CONFIG_HZ_PERIODIC is not set CONFIG_NO_HZ_IDLE=y # CONFIG_NO_HZ_FULL is not set CONFIG_NO_HZ=y see these two bugs that describe the problem as seen by users: https://bugs.gentoo.org/show_bug.cgi?id=595808 https://bugs.gentoo.org/show_bug.cgi?id=605806 from the kernel docs: CONFIG_NO_HZ_IDLE: This option enables a tickless idle system: timer interrupts will only trigger on an as-needed basis when the system is idle. This is usually interesting for energy saving. Most of the time you want to say Y here. the root problem is that times().tms_utime always returns 0 and thus the calibration keeps incrementing the number of itterations sent to the gcry_kdf_derive() function. tested on a gentoo linux system with gnupg-2.1.21, 4.12.0 vanilla kernel solution: please stop using times() and switch to something like clock_gettime(CLOCK_MONOTONIC_RAW, struct) switching to CONFIG_HZ_PERIODIC=y solves the 100% cpu loop, but it means that gnupg depends on a kernel setup that is not the recommended one.

the calibrate_get_time() function used by do_encryption() -> get_standard_s2k_count() among others currently ends up using 100% cpu in what seems as an infinite loop on a system that has a tickless kernel configured like: CONFIG_NO_HZ_COMMON=y # CONFIG_HZ_PERIODIC is not set CONFIG_NO_HZ_IDLE=y # CONFIG_NO_HZ_FULL is not set CONFIG_NO_HZ=y see these two bugs that describe the problem as seen by users: https://bugs.gentoo.org/show_bug.cgi?id=595808 https://bugs.gentoo.org/show_bug.cgi?id=605806 from the kernel docs: CONFIG_NO_HZ_IDLE: This option enables a tickless idle system: timer interrupts will only trigger on an as-needed basis when the system is idle. This is usually interesting for energy saving. Most of the time you want to say Y here. the root problem is that times().tms_utime always returns 0 and thus the calibration keeps incrementing the number of itterations sent to the gcry_kdf_derive() function. tested on a gentoo linux system with gnupg-2.1.21, 4.12.0 vanilla kernel solution: please stop using times() and switch to something like clock_gettime(CLOCK_MONOTONIC_RAW, struct) switching to CONFIG_HZ_PERIODIC=y solves the 100% cpu loop, but it means that gnupg depends on a kernel setup that is not the recommended one.

the calibrate_get_time() function used by do_encryption() -> get_standard_s2k_count() among others currently ends up using 100% cpu in what seems as an infinite loop on a system that has a tickless kernel configured like: CONFIG_NO_HZ_COMMON=y # CONFIG_HZ_PERIODIC is not set CONFIG_NO_HZ_IDLE=y # CONFIG_NO_HZ_FULL is not set CONFIG_NO_HZ=y see these two bugs that describe the problem as seen by users: https://bugs.gentoo.org/show_bug.cgi?id=595808 https://bugs.gentoo.org/show_bug.cgi?id=605806 from the kernel docs: CONFIG_NO_HZ_IDLE: This option enables a tickless idle system: timer interrupts will only trigger on an as-needed basis when the system is idle. This is usually interesting for energy saving. Most of the time you want to say Y here. the root problem is that times().tms_utime always returns 0 and thus the calibration keeps incrementing the number of itterations sent to the gcry_kdf_derive() function. tested on a gentoo linux system with gnupg-2.1.21, 4.12.0 vanilla kernel solution: please stop using times() and switch to something like clock_gettime(CLOCK_MONOTONIC_RAW, struct) switching to CONFIG_HZ_PERIODIC=y solves the 100% cpu loop, but it means that gnupg depends on a kernel setup that is not the recommended one.