Bug 720080

That's quite brief.

I suppose this is the same thing as bug 701943.  Could you confirm that?

I installed systemtap on rawhide LiveCD but it is not possible to install kernel-debuginfo there. I got only errors in timeout.stp output.
As I said problem with high CPU consuming by lldpad I noticed on rawhide LiveCD but no such problem on F15 LiveCD.

I can't reproduce that with those versions on my production F15 (x86_64) desktop.  Can you point me to the Rawhide LiveCD you've used?  All desktop Koji LiveCD tasks in past weeks seem to be unsuccessful...

I used this CD
http://kojipkgs.fedoraproject.org/work/tasks/8309/3188309/Fedora-16-Nightly-20110709.07-i686-Live-kde.iso
http://kojipkgs.fedoraproject.org/work/tasks/8312/3188312/Fedora-16-Nightly-20110709.07-x86_64-Live-kde.iso

Created attachment 512738 [details]
selinux alert

And I tested with selinux=0 because there is lldpad related selinux alert if selinux enabled.

SELinux is preventing lldpad from sendto access on the unix_dgram_socket @00005.

*****  Plugin catchall (100. confidence) suggests  ***************************

If you believe that lldpad should be allowed sendto access on the @00005 unix_dgram_socket by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# grep lldpad /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp

Additional Information:
Source Context                system_u:system_r:lldpad_t:s0
Target Context                system_u:system_r:initrc_t:s0
Target Objects                @00005 [ unix_dgram_socket ]
Source                        lldpad
Source Path                   lldpad
Port                          <Unknown>
Host                          localhost.localdomain
Source RPM Packages           
Target RPM Packages           
Policy RPM                    selinux-policy-3.10.0-2.fc16
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name                     localhost.localdomain
Platform                      Linux localhost.localdomain
                              3.0-0.rc6.git0.1.fc16.x86_64 #1 SMP Tue Jul 5
                              00:39:12 UTC 2011 x86_64 x86_64
Alert Count                   4
First Seen                    Wed Jul 13 19:36:18 2011
Last Seen                     Wed Jul 13 19:37:48 2011
Local ID                      2b86a37a-5160-4a95-8fbf-84064c495ee7

Raw Audit Messages
type=AVC msg=audit(1310600268.176:59): avc:  denied  { sendto } for  pid=657 comm="lldpad" path=003030303035 scontext=system_u:system_r:lldpad_t:s0 tcontext=system_u:system_r:initrc_t:s0 tclass=unix_dgram_socket


Hash: lldpad,lldpad_t,initrc_t,unix_dgram_socket,sendto

audit2allow

#============= lldpad_t ==============
allow lldpad_t initrc_t:unix_dgram_socket sendto;

audit2allow -R

#============= lldpad_t ==============
allow lldpad_t initrc_t:unix_dgram_socket sendto;

If selinux enabled then no high CPU useg by lldpad.

Created attachment 520429 [details]
Strace output

I see high CPU usage by lldpad, about 15-30% constantly on Fedora 16 Alpha.
SELinux is enabled, but I don't see any SELinux AVCs.  The attached strace output shows rapidly repeating socket/ioctl/close/select calls.  A tcpdump doesn't show any LLDP packets being sent or received.

The AVC messages were a selinux-policy problem, if I understand it correctly.  lldpad was blocked, therefore didn't consume any resources.

Thanks for the new test with Alpha.  I've just made a new scratch build [1].  This one contains a huge amount of bugfixes, including one [2] supposedly fixing the issue.

Please, let me know if it fixes it for you. 

[1] http://koji.fedoraproject.org/koji/taskinfo?taskID=3311037
[2] http://www.open-fcoe.org/patchwork/patch/2174/

petr: is this a dupe of 701943?

(In reply to comment #10)
> petr: is this a dupe of 701943?

Yes, I believe so.

Both contain reasonable amount of information now and the cause of this is not absolutely clear.  I believe the last fixes it though and plan to close both bugs after somebody confirms it.

Or I'm just going to close this one to avoid confusion...

*** This bug has been marked as a duplicate of bug 701943 ***