Re: udiskd high CPU usage with 4.0 git
From: NeilBrown
Date: Sun Mar 15 2015 - 19:44:49 EST
On Sat, 14 Mar 2015 21:16:51 +0100 Torsten Kaiser
<just.for.lkml@xxxxxxxxxxxxxx> wrote:
> On Mon, Mar 9, 2015 at 12:30 AM, NeilBrown <neilb@xxxxxxx> wrote:
> > On Sun, 08 Mar 2015 18:14:39 +0100 Prakash Punnoor <prakash@xxxxxxxxxx> 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 for the bisection and analysis! Always easier when someone else does
the hard work :-)
There is a much simpler patch (as you probably suspected). I'll post it in a
moment.
Thank,
NeilBrown
Attachment:
pgpNe5ntcpFjU.pgp
Description: OpenPGP digital signature