Bug 524752 - udevd keeps CPU at 50% once running
Summary: udevd keeps CPU at 50% once running
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: udev
Version: rawhide
Hardware: s390
OS: Linux
high
medium
Target Milestone: ---
Assignee: Harald Hoyer
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: 525574
TreeView+ depends on / blocked
 
Reported: 2009-09-22 03:41 UTC by David Cantrell
Modified: 2009-09-25 17:11 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 525574 (view as bug list)
Environment:
Last Closed: 2009-09-25 17:11:35 UTC


Attachments (Terms of Use)
udevd.strace.xz (559.11 KB, application/octet-stream)
2009-09-23 21:21 UTC, David Cantrell
no flags Details

Description David Cantrell 2009-09-22 03:41:02 UTC
On s390x, I'm seeing udevd stay at 50% of the CPU and continually spew the following message to the console:

udevd: error getting buffer for inotify

I am not sure what's going on, but if you want help debugging this, let me know.

Comment 1 Harald Hoyer 2009-09-23 20:17:25 UTC
this is a kernel bug, IIRC.. is this an old kernel?

Comment 2 Harald Hoyer 2009-09-23 20:28:15 UTC
can you strace udevd?

might be related to bug #499907

Eric, what do you think?

Comment 3 Denise Dumas 2009-09-23 20:33:04 UTC
btw, this is a HUGE problem for S390 debug effort - which is currently blocking rhel6 alpha2.  Help appreciated.

Comment 4 Eric Paris 2009-09-23 20:42:38 UTC
Let me see the strace of udevd and we'll see what's going on....

Comment 5 Eric Paris 2009-09-23 20:44:49 UTC
also let me know what the kernel is in question and i'll make sure that kernel doesn't have any of the obvious problems....

Comment 6 David Cantrell 2009-09-23 21:21:51 UTC
Created attachment 362355 [details]
udevd.strace.xz

Command used:
strace -f -F -v -o /udevd.strace udevd --debug --debug-trace

Comment 7 David Cantrell 2009-09-23 21:24:48 UTC
Kernel is 2.6.31-0.174.rc7.git2.fc12.s390x

Comment 8 Eric Paris 2009-09-23 21:44:50 UTC
Not the same problem....

389   ioctl(6, FIONREAD, [224])         = 0
389   mmap(NULL, 962072678400, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = -1 ENOMEM (Cannot allocate memory)

Looks like the ioctl gave something reasonable.  But udev is trying to allocate a buffer WAY WAY WAY to big....

Comment 9 Harald Hoyer 2009-09-23 22:04:19 UTC
This is the code in question:


        ssize_t nbytes;

        if ((ioctl(pfd[FD_INOTIFY].fd, FIONREAD, &nbytes) < 0) || (nbytes <= 0))
                return 0;

        buf = malloc(nbytes);

Comment 10 Eric Paris 2009-09-23 22:13:42 UTC
the kernel calls it a size_t rather than ssize_t

no idea how that could cause the problem in question.  But i'll check to see if this is a change.

If not, I think we need to find a libc person....

Comment 11 Eric Paris 2009-09-23 22:26:51 UTC
RHEL5 kernel called this as an unsigned int....

962072678400    = 0x000000E000001000
1168231108608   = 0x0000011000001000

So it looks like some of the higher bits of the nbytes is non-zero.

I admit I'm confused, I could see that happening on the old setup...

Comment 12 Eric Paris 2009-09-23 22:45:13 UTC
ok, I'm back.  RHEL5

struct inotify_device {
[snip]
        unsigned int            queue_size;     /* size of the queue (bytes) */
[snip]
};

ret = put_user(dev->queue_size, (int __user *) p);


upstream/RHEL6

size_t send_len = 0;

ret = put_user(send_len, (int __user *) p);

In both cases though we should only be writing an int's worth of data.  I believe that on s390, and x86_64 even:
size_t = long
ssize_t = unsigned long

but I'm only writing an int back from the kernel.  My guess is that those high bits are just stack leftovers.  I'm assuming that udev has just always gotten lucky and had 0 there and now we've hit a system where you don't.   I'd say either use an int, or explicitly 0 it out.....

-Eric

Comment 14 Harald Hoyer 2009-09-25 17:11:35 UTC
should be fixed in udev-145-9.fc12 
http://koji.fedoraproject.org/koji/taskinfo?taskID=1707372


Note You need to log in before you can comment on or make changes to this bug.