Hi,
--- On Fri, 1/23/09, Serge E. Hallyn <se...@us.ibm.com> wrote: > From: Serge E. Hallyn <se...@us.ibm.com> > Subject: Re: [LTP] proc01 failures with selinux disabled > To: "CAI Qian" <caiq...@cclom.cn> > Cc: ltp-l...@lists.sf.net > Date: Friday, January 23, 2009, 12:00 AM > Quoting CAI Qian (caiq...@cclom.cn): > > Hi, > > > > > > --- On Thu, 1/22/09, Subrata Modak > <subr...@linux.vnet.ibm.com> wrote: > > > > This approach will skip the failures that > those > > > entries return EINVAL > > > > while SELinux is enable. You can check if > SELinux is > > > enable or not, and > > > > then add then to something like > > > known_issue_without_selinux table. > > > > > > > > I'd suggest to add some comments or > TINFO at the > > > beginning of it to > > > > state that the test should be run with > SELinux enable. > > > > > > If the test cannot run with Selinux Enabled, then > exit with > > > TCONF and > > > proper message. > > > Report appropriate info post testing when Selinux > is > > > actually enabled. > > > > > > > Actually, it is not that it cannot be run with SELinux > disabled. It > > can, and there is no enforcement. I don't want to > block the test to > > run if SELinux is disabled if anybody want to have a > try. > > > > However, those EINVAL failures are unclear to me that > if they are > > kernel bugs or not, > > No if there is no LSM then the /proc/$$/attr/ files will > return > -EINVAL, that's correct behavior. Now it's not > just SELinux - > Smack and AppArmor (and probably tomoyo too) will define > some > or all of the hooks to write data to those files. > > So for /proc/$$/attr/* it's perhaps best to have > generic ltp > ignore them, and have the lsm-specific tests test their > behavior. Or, detect if no lsm is loaded (somehow) and, > only in that case, make sure that -EINVAL IS in fact > returned, > else there might be a problem. > Those are all sound good for me. If go for the later, I am not sure if the test with Smack or AppArmor enabled will return the same result as SELinux. > The other files (i.e. /proc/$$/tasks/pid/mem) I'm not > so sure > about. At least, that is how it behaves for RHEL4, RHEL5, and upstream kernels. In the past, there was a small bug which changed the behaviour from -EIO to -EINVAL for RHEL4 kernel, which caused gcore command have a significant performance drop for certain multi-thread programs. The original bug is private due to customer information there, but there is a duplicated public bug for it which contains a little bit history, https://bugzilla.redhat.com/show_bug.cgi?id=460106 CAI Qian > > > so if you want to get away with those errors when > > SELinux is disabled, you can probably fix the kernel > bugs, ignore them > > or put them to the SELinux off known issue list, as I > mentioned before. > > > > Because everybody in Red Hat is trained that any test > should be run > > with SELinux enabled, it is off my interest to make > that change. ------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword _______________________________________________ Ltp-list mailing list Ltp-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ltp-list
