2011-09-16 04:08:16

by justinmattock

[permalink] [raw]
Subject: [refpolicy] general protection fault: 0000 -#1] SMP





----- Original Message -----
From: Lin Ming <[email protected]>
To: Justin Mattock <[email protected]>
Cc: "refpolicy at oss.tresys.com" <[email protected]>; "selinux at tycho.nsa.gov" <[email protected]>; "linux-kernel at vger.kernel.org" <[email protected]>
Sent: Thursday, September 15, 2011 8:00 PM
Subject: Re: general protection fault: 0000 -#1] SMP

On Thu, Sep 15, 2011 at 11:05 PM, Justin Mattock
<[email protected]> wrote:
>
>
> using the current mainline, I woke the machine up from suspend, then started to relabel the filesystem, using the stable release policy(MCS). then this showed up:
> I only have photos of the crash, due to a total system lock
> http://www.flickr.com/photos/44066293 at N08/6149812345/in/photostream
> http://www.flickr.com/photos/44066293 at N08/6149811913/in/photostream

Is this a regression? Does it happen for 3.0 kernel?

from looking at the archives I dont see this as a regression. last I reported somethig was in 2010
https://lkml.org/lkml/2010/7/3/155
but I could be wrong.


It crashed at __list_del_entry.
Could you enable CONFIG_DEBUG_LIST=y to get more info?

yeah this is set already in my .config. from what I remember this occured two times,
once after S2R wakeup, then on the first initial install of repolicy(tar ball stable) when .autorelabel went into play.
(but could not capture any thing due to the system doing an instant reboot.
I will keep an eye out on this. I have also update the policy to the current git(not sure if it matters or not).

Lin Ming

>
> Note: I subscribed using my yahoo accnt due to changing, but for some reason, am not able to complete the process
> (will try again to see).
>
> if you need more info let me know(I will try and recreate this, and possibly due a bisect on the kernel and/or pull refpolicy git to see)
>
> Justin P. Mattock


Justin P. Mattock