Re: [Xen-devel] [PATCH v2 5/6] tools/dm_depriv: Add first cut RLIMITs

[George Dunlap <george.dunlap@xxxxxxxxxx>]

On 09/24/2018 11:48 AM, Ian Jackson wrote:
>> +        if (rc < 0) {
>> +            char *msg = GCSPRINTF("libxl: Setting rlimit %d to %lld failed 
>> with error %d\n",
>> +                                  rlimits[i].resource,
> 
> If you cared very much about the error handling, you could produce
> names rather than numbers for the rlimit values by wrapping the struct
> rlimit up in a struct of our own with a `const char *name' field, and
> having a macro to generate the table entries.
> 
> But it's probably not worth it.

I think I considered this for a second or two before concluding the same
thing. :-)

> Again, use `r' for syscall returns.  And, again, don't print numerical
> errno values.  use LOGE.
> 
> ...
>> +    if [[ "$input" =~ 
>> ^$limit_string[[:space:]]*([^[:space:]]+)[[:space:]]*([^[:space:]]+)[[:space:]]*[^[:space:]]+
>>  ]] ; then
>> +    if [[ "${BASH_REMATCH[1]}" != $tgt ||
> 
> Cor.  I think I would have reached for Perl by now.  I guess tastes
> differ.

I didn't realize I was going to need regexp until most of the regexp
until the rest of the script was written; at that point,  generating
this rune was certainly a lot less work than re-writing the whole thing
from scratch.  :-)

> I guess you have tested that this does all pass and fail
> appropriately ?

I have run the script on a VM without dm_restrict, and all the tests
come  back FAILED; and run it on a vm with dm_restrict, and all the
tests come back PASSED.

On the other hand, Anthony seems to have found a bug in the part of the
script that checks gid; so it seems there's something fishy.  But it's
my practice to test both, yes.

When we add it to osstest, we probably want to do the same -- make sure
that all the tests fail when dm_restrict=0, as well as pass when
dm_restrict=1.

> About the output format from this checker script.  As it is, osstest
> will have to grow an additional parser to parse this.  I don't mind
> that if it's subunit v1 (or some other plsusible standard).
> 
> But if it's going to be bespoke it would be much more convenient if
> the output was parseable by the same parser as the oiutput from
> depriv-fd-checker.

Does osstest need to actually parse the output at all?  Couldn't it just
capture the output verbatim in a log file, and use the exit code as a
pass/fail (or grep for FAILED)?

I'm happy to use a more standard formatting if you think that would be
useful though.

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel