lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CANaxB-x9BL=RTPTFQCohZf4JLywC97wcqxrPk=aCTJpTWVnTOw@mail.gmail.com>
Date:	Wed, 17 Aug 2016 12:22:20 -0700
From:	Andrei Vagin <avagin@...il.com>
To:	Thomas Gleixner <tglx@...utronix.de>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: setitimer() doesn't work properly starting with 4.8-rc1

On Wed, Aug 17, 2016 at 12:01 PM, Andrei Vagin <avagin@...il.com> wrote:
> Hello,
>
> I found that setitimer() doesn't work properly on out test AMD fitlet.
> It works correctly in the 4.7 kernel and doesn't work in 4.8-rc1.
>
> A small test is attached to this message.
>
> [root@...-LAN-dhcp-38 ~]# uname -a
> Linux usr-LAN-dhcp-38.99.sw.ru 4.8.0-0.rc2.git1.1.fc25.x86_64 #1 SMP
> Tue Aug 16 22:08:16 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
> [root@...-LAN-dhcp-38 ~]# strace ./test-timers
> ...
> rt_sigaction(SIGVTALRM, {0x400606, [VTALRM], SA_RESTORER|SA_RESTART,
> 0x7f51e0d67770}, {SIG_DFL, [], 0}, 8) = 0
> setitimer(ITIMER_VIRTUAL, {it_interval={0, 100000}, it_value={0,
> 100}}, NULL) = 0
> exit_group(0)                           = ?
> +++ exited with 0 +++

One more interesting thing is how cpu time is accounted. The test is
running in a busy loop for 10 seconds, but the user time is zero and
everything is accounted to the system time.

[root@...-LAN-dhcp-38 ~]# time ./test-timers

real 0m10.959s
user 0m0.000s
sys 0m10.682s


>
> We can see that a test didn't get any signals. When timers works, this
> output looks like this:
> rt_sigaction(SIGALRM, {0x400606, [ALRM], SA_RESTORER|SA_RESTART,
> 0x7f9e21b1b770}, {SIG_DFL, [], 0}, 8) = 0
> setitimer(ITIMER_REAL, {it_interval={0, 100000}, it_value={0, 100}}, NULL) = 0
> --- SIGALRM {si_signo=SIGALRM, si_code=SI_KERNEL} ---
> rt_sigreturn({mask=[]})                 = 6295208
> --- SIGALRM {si_signo=SIGALRM, si_code=SI_KERNEL} ---
> rt_sigreturn({mask=[]})                 = 0
> --- SIGALRM {si_signo=SIGALRM, si_code=SI_KERNEL} ---
> rt_sigreturn({mask=[]})                 = 1
> --- SIGALRM {si_signo=SIGALRM, si_code=SI_KERNEL} ---
> rt_sigreturn({mask=[]})                 = 1
> --- SIGALRM {si_signo=SIGALRM, si_code=SI_KERNEL} ---
> rt_sigreturn({mask=[]})                 = 1471459909
> --- SIGALRM {si_signo=SIGALRM, si_code=SI_KERNEL} ---
> rt_sigreturn({mask=[]})                 = 1
> --- SIGALRM {si_signo=SIGALRM, si_code=SI_KERNEL} ---
>
>
> Only ITIMER_PROF and ITIMER_VIRTUAL doesn't work properly. ITIMER_REAL
> works as expected.
>
> [root@...-LAN-dhcp-38 ~]# cat /proc/cpuinfo
> processor : 0
> vendor_id : AuthenticAMD
> cpu family : 22
> model : 48
> model name : AMD A10 Micro-6700T APU+AMD Radeon R6 Graphics
> stepping : 1
> microcode : 0x7030105
> cpu MHz : 1000.000
> cache size : 2048 KB
> physical id : 0
> siblings : 4
> core id : 0
> cpu cores : 4
> apicid : 0
> initial apicid : 0
> fpu : yes
> fpu_exception : yes
> cpuid level : 13
> wp : yes
> flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
> pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt
> pdpe1gb rdtscp lm constant_tsc rep_good acc_power nopl nonstop_tsc
> extd_apicid aperfmperf eagerfpu pni pclmulqdq monitor ssse3 cx16
> sse4_1 sse4_2 movbe popcnt aes xsave avx f16c rdrand lahf_lm
> cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch
> osvw ibs skinit wdt topoext perfctr_nb bpext ptsc perfctr_l2 cpb
> hw_pstate vmmcall bmi1 xsaveopt arat npt lbrv svm_lock nrip_save
> tsc_scale flushbyasid decodeassists pausefilter pfthreshold
> overflow_recov
> bugs : fxsave_leak sysret_ss_attrs null_seg
> bogomips : 2395.40
> TLB size : 1024 4K pages
> clflush size : 64
> cache_alignment : 64
> address sizes : 40 bits physical, 48 bits virtual
> power management: ts ttp tm 100mhzsteps hwpstate cpb acc_power [13]
>
> This problem was caught by criu tests:
> https://github.com/xemul/criu/issues/200
>
> Thanks,
> Andrei

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ