Quoting CAI Qian ([email protected]): > Hi, > > > to me the test here has a different testing focus -- try to read every > > > entry in /proc > > > filesystem. Those entries belong to this filesystem, so we'll read them > > > the same > > > way. Who knows if those entries will not give us a hang or panic or > > > behaving > > > badly with certain read buffers? SELinux test suite may or may not catch > > > those > > > kind of bugs. > > > > Then add tests in there... > > > > No, they do not belong there, because we are focus on testing of proc > filesystem here. The test case here should not care about the content it > read, but rather what the kernel behaves when to read those files.
Then the dummy lsm I suggested is the only way to really test what you want :) > > In fact, the logical course given your concern would be to write a > > kernel module defining an LSM allowing random long write to and reads > > from /proc/$$/attr/ so you can test the procfs bits of that API (if > > you could still write an LSM as a module :). It should be doable to > > push a 'debug' LSM into the upstream kernel which just serves to > > facilitate such testing. > > > > Anyway I've made my own position clear, and I think Kamalesh's patch > > implements precisely what Stephen suggested. > > > > Stephen's suggestion is something we should take. I agree Kamalesh's > patch has included his suggestion. Unfortunately, there are other issues > with Kamalesh's patch that have been pointed out in the last email. Sorry, I've looked back through the thread, but don't see the other issues you're talking about. -serge ------------------------------------------------------------------------------ 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 [email protected] https://lists.sourceforge.net/lists/listinfo/ltp-list
