linux-kernel - Re: udiskd high CPU usage with 4.0 git

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: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 16 Mar 2015 10:43:31 +1100
From:	NeilBrown <neilb@...e.de>
To:	Prakash Punnoor <prakash@...noor.de>
Cc:	LKML <linux-kernel@...r.kernel.org>
Subject: Re: udiskd high CPU usage with 4.0 git

On Mon, 09 Mar 2015 16:46:41 +0100 Prakash Punnoor <prakash@...noor.de> wrote:

> On 09.03.2015 00:30, NeilBrown wrote:
> > On Sun, 08 Mar 2015 18:14:39 +0100 Prakash Punnoor <prakash@...noor.de> 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
> >>
> >> And reverting it from current master (at
> >> 2cf3afcd4cbe0e32b8722fc291e9255de1b4d6c6) fixes my problem indeed.
> >>
> >> I attached dmesg and config from
> >> 2cf3afcd4cbe0e32b8722fc291e9255de1b4d6c6 with
> >> 750f199ee8b578062341e6ddfe36c59ac8ff2dcb reverted. Any more infos
> >> needed? I am actually using a raid5 array, if that matters:
> >>
> >> Personalities : [raid6] [raid5] [raid4]
> >> md127 : active raid5 sdd1[1] sdb1[3] sdc1[0]
> >>       3907023872 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/3]
> >> [UUU]
> >>
> >> unused devices: <none>
> >>
> >>
> >> The array uses systemd automount feature (x-systemd.automount).
> >>
> >> Please CC me, as I am not subscribed.
> >>
> >>
> >> Regards,
> >>
> >> Prakash
> > 
> > Thanks for the report.
> > I can't reproduce this, or see what would cause it.
> > 
> > Can you please reproduce the problem and then run
> > 
> >   strace -o /tmp/udisks.trace -f -p `pidof udisksd`
> > 
> > for a few seconds, then interrupt and post the resulting '/tmp/udisks.trace'.
> 
> Hi, attached the trace.
> 
>

Thanks. 
The significant part is:

329   poll([{fd=4, events=POLLIN}, {fd=8, events=0}, {fd=9, events=0}, {fd=11, events=POLLIN}, {fd=13, events=0}, {fd=12, events=0}], 6, 513377) = 2 ([{fd=4, revents=POLLIN}, {fd=12, revents=POLLERR}])

repeating frequently, so fd4 and fd12 are always ready.
I don't know about fd4, but fd12 is:

329   read(12, "idle\n", 1024)          = 5


so that is .../md/sync_action
It is simply always readable.  I thought I had checked that, but it seems not.

Anyway I have a fix which I will post shortly.

thanks again,
NeilBrown

Content of type "application/pgp-signature" skipped