On Mon, 2008-05-12 at 14:13 -0500, Serge E. Hallyn wrote:
> Quoting Subrata Modak ([EMAIL PROTECTED]):
> > On Fri, 2008-05-09 at 09:32 -0500, Serge E. Hallyn wrote:
> > > Quoting Matt Helsley ([EMAIL PROTECTED]):
> > > > Hi All,
> > > >
> > > > This patch adds a few tests for a variety of bind mounts. More
> > > > than
> > > > just shared subtrees are involved as plain --bind and plain --move are
> > > > used. Read-only bind mounts are not covered by these tests however.
> > > >
> > > > Avantika Mathur originally wrote the tests. I've ported them to
> > > > use LTP
> > > > APIs and conventions. I've also modified Avantika's scripts to try and
> > > > robustly cleanup after broken tests so that leftover mounts and failures
> > > > at any point in a test are cleaned up thoroughly. I've made what efforts
> > > > I can to follow the conventions I found in LTP FAQs and the source
> > > > however there's alot here so I may have missed something.
> > > >
> > > > Shared bind mounts were introduced in 2.6.15. Because of this
> > > > we need a
> > > > tst_kvercmp command which can be invoked from a script. I've added this
> > > > to ltpapicmd.c
> > > >
> > > > This patch applies to the April release of LTP. I'll also be
> > > > posting
> > > > results for x86, x86_64, and ppc64 on a variety of kernels. In order to
> > > > highlight the results contributed by this patch I've only run this
> > > > portion of the patched LTP.
> > > >
> > > > Comments welcome.
> > >
> > > Excellent! Thanks for sending these. I'll take a detailed look over
> > > the next week.
> >
> > Thanks Sergei for offering to review. Will wait for your review comments
> > before i merge them.
>
>
> Subrata, please do not hold off on merging these tests until I've
> reviewed them. That would take way too long and it'll be useful to
> have people reporting failures in the meantime, as they'll either
> be correct feedback about kernel bugs, or useful feedback about
> bugs in the tests.
>
> Matt/Avantika, here are a few notes to start with.
>
> For namespace tests, I'd recomment just using unshare(CLONE_NEWNS).
> clone() can be fickle based on arch+distro+moonphase, and proper
> behavior of clone+unshare belongs in namespace tests, so here just
> using unshare is sufficient and easier.
The clone tests didn't work to well. Hopefully this suggestion will fix
them..
NOTE: The cloneNS tests aren't currently enabled in the patch. See the
README and testscripts/test_fs_bind.sh
> bind/OO_: duplicate descriptions per file, that'll be painful to maintain.
I agree. These description files are here because they are an LTP
pattern/convention I was asked to follow. Subrata, any chance this
convention will change?
> Tools are a bit of a mess...
> smount.c is included, BUT
> makedir expects uptodate 'mount' with --make-X support, PLUS
Hmm, I don't think that's true. makedir falls back to using smount if
--make-X options fail since it joins the two commands with ||.
However, mount support of --bind and --move is required. That's why the
primary test script (test_fs_bind.sh) tests for those as "prereqs".
Did I miss some other spot where it expects --make-X support?
> bin/makedir uses confusing terminology
> (share->rshared, nshare->shared, unclone->runbindable)
Good point.
> But changing that now would obviously be unrealistic.
Not entirely. For the reasons you suggested above I'd rather get these
tests into LTP than delay until I have more time to work on something
like this.
> If you're going to have 20 tests per feature anyway, I'd prefer to
> see the tests be less baroque, with each piece tested exactly once.
I'm not 100% certain that I know what you mean by testing each piece
exactly once. When I consider that, it seems like the test program would
be much more complex. Taken to the extreme suggested by your choice of
words ("exactly"), I think it would postpone testing simple teardown
paths in favor of more complex constructions and would therefore report
the complex bugs first.
The goal with this patch is to test the small stuff first, tear it
down, and then rebuild it with something one "step" more complex. This
way I think we get the benefit of finding the simplest test case which
triggers a bug -- whether the bug is in building the mount trees or
tearing them down. I also hope this means the tests can be used when
analyzing bugs. The disadvantage is the same bug can break multiple
tests and "flood" the logs -- potentially exaagerating a single
regression/bug.
> I.e. in bind/test13, share1, share2, and parent1/child1/x seem like pure
> noise. Since you're not doing rbind here at all you could just do:
>
> makedir unclone parent1
> makedir share parent2
> mount --bind parent1 parent2 2> /dev/null || result =$? # mount should
> fail
>
> (I suppose you're trying to check whether having shared mounts in parent
> and child directories of child1 messes up the unbindable semantics for
> child1?)
Yup.
> So far I haven't seen anything that looked wrong, though. I'll keep
> looking, but in the meantime I maintain that putting this in the ltp
> tree now will be valuable.
Thanks for your initial review.
Cheers,
-Matt Helsley
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list
