Description of problem: https://lkml.org/lkml/2015/3/14/163 From Torsten Kaiser <> On Mon, Mar 9, 2015 at 12:30 AM, NeilBrown <neilb> wrote: > On Sun, 08 Mar 2015 18:14:39 +0100 Prakash Punnoor <prakash> wrote: > >> Hi, >> >> I noticed the udisks daemon (version 2.1.4) suddenly started using high >> cpu (one core at 100%) with linux 4.0 git kernel. I bisected it to: >> >> 750f199ee8b578062341e6ddfe36c59ac8ff2dcb I had the same problem upgrading from 4.0-rc1 to 4.0-rc3. I have just finished bisecting and "fixing" it. My bisect points to the same commit. Looking at udisksd with strace sees a loop of polling and then accessing several md related sysfs files. The only file that udisksd monitors and was changes by that commit was "sync_action". If I revert this part of the commit, my system works normal again: static struct md_sysfs_entry md_scan_mode = - __ATTR_PREALLOC(sync_action, S_IRUGO|S_IWUSR, action_show, action_store); + __ATTR(sync_action, S_IRUGO|S_IWUSR, action_show, action_store); It seems that polling is broken for peralloc files. The cause seems to be that kernfs_seq_show() updates ->event, while the new sysfs_kf_read() does not. So the polling will always trigger and udisksd goes into an inifinite loop looking for changes that are not there. I fixed my local system by copying the line "of->event = atomic_read(&of->kn->attr.open->event);" from kernfs_seq_show() into sysfs_kf_read(). (I also needed to move the definition of struct kernfs_open_node from kernfs/file.c to kefs-internal.h) udisksd now again behaves normal, but I'm not sending this change as a patch, because I do not know about the locking and livetime of these objects to evaluate, if that is really the correct fix. Thanks, Torsten --------- [root@localhost ~]# uname -a Linux mujpc 4.0.0-0.rc3.git0.1.fc22.x86_64 #1 SMP Mon Mar 9 13:36:59 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux [root@localhost ~]# top top - 14:18:29 up 8 min, 2 users, load average: 1.11, 0.91, 0.48 Tasks: 215 total, 2 running, 213 sleeping, 0 stopped, 0 zombie %Cpu(s): 10.3 us, 15.3 sy, 0.0 ni, 74.4 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st KiB Mem : 16362728 total, 14351344 free, 1204720 used, 806664 buff/cache KiB Swap: 18890748 total, 18890748 free, 0 used. 14890228 avail Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 1623 root 20 0 371856 8272 6624 R 100.0 0.1 8:24.98 udisksd
There's a pending patch upstream that fixes this. https://lkml.org/lkml/2015/3/15/173
Yep, we know. It should land in rawhide via the normal upstream paths.
Upstream seems to be taking their time. I added it in Fedora git. It will be in the next build.
*** Bug 1200124 has been marked as a duplicate of this bug. ***
*** Bug 1204053 has been marked as a duplicate of this bug. ***
Seems fixed in 4.0.0-0.rc4.git1.3.fc23.x86_64
kernel-4.0.0-0.rc5.git1.3.fc22 has been submitted as an update for Fedora 22. https://admin.fedoraproject.org/updates/kernel-4.0.0-0.rc5.git1.3.fc22
It does not seem fixed for me with latest kernel uname -a Linux mujpc 4.0.0-0.rc4.git0.1.fc22.x86_64 #1 SMP Mon Mar 16 14:36:23 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux top -b -n 1 | head top - 10:31:33 up 1:10, 2 users, load average: 1.08, 1.08, 1.07 Tasks: 236 total, 2 running, 234 sleeping, 0 stopped, 0 zombie %Cpu(s): 11.7 us, 15.4 sy, 0.1 ni, 72.8 id, 0.1 wa, 0.0 hi, 0.0 si, 0.0 st KiB Mem : 16362724 total, 12651696 free, 1810728 used, 1900300 buff/cache KiB Swap: 18890748 total, 18890748 free, 0 used. 14203704 avail Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 2227 root 20 0 372768 9208 6508 R 106.2 0.1 70:42.99 udisksd
4.0.0-0.rc4.git0.1 is not expected to be fixed. The fix is in later kernels.
Package kernel-4.0.0-0.rc5.git1.3.fc22: * should fix your issue, * was pushed to the Fedora 22 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing kernel-4.0.0-0.rc5.git1.3.fc22' as soon as you are able to, then reboot. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2015-4839/kernel-4.0.0-0.rc5.git1.3.fc22 then log in and leave karma (feedback).
seems fine to me now ... # uname -r 4.0.0-0.rc5.git1.3.fc22.x86_64 thanks :)
This is fixed in the 4.0.0-0.rc5.git4.1.fc22 update.