All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Stancek <jstancek@redhat.com>
To: ltp@lists.linux.it
Subject: [LTP] Question about perf_event_open/Cap_bounds/su01 test cases
Date: Mon, 14 Mar 2016 08:10:39 -0400 (EDT)	[thread overview]
Message-ID: <1284145136.9339833.1457957439775.JavaMail.zimbra@redhat.com> (raw)
In-Reply-To: <AF04265A3FC2B144B9892F621A394E13EA3E5105@tethys>



----- Original Message -----
> From: "Julio Cruz Barroso" <julio.cruz@smartmatic.com>
> To: "Jan Stancek" <jstancek@redhat.com>
> Cc: "Cyril Hrubis" <chrubis@suse.cz>, ltp@lists.linux.it
> Sent: Sunday, 13 March, 2016 12:39:35 PM
> Subject: RE: [LTP] Question about perf_event_open/Cap_bounds/su01 test cases
> The following test cases were fixed (attached patches for revision):

Hi,

Please post each patch separately. You're missing Signed-off-by in each
and some introduce white-space errors. You can check your patches
with ./scripts/checkpatch.pl in linux kernel tree. Also description
could be a bit more verbose to explain "why" a patch is proposed.

> 
> - Cap_bounds: Change test to go only up to min(CAP_LAST_CAP,
> /proc/sys/kernel/cap_last_cap)

I made some tweaks here, fixed white-space errors, added check
for proc file (older kernels don't have it), fixed an error,
where CAP_LAST_CAP was used outside "#ifdef HAVE_LIBCAP"
and pushed.

> - getrusage03: Check available memory to run grandchild_maxrss, zombie and
> sig_ign

"unsigned long availMem" should be fine if you first divide pagesize by 1024.
The "100" you picked as a threshold should be a define. Also it would be better
if you moved it to other side of comparison. If someone has less than 100MB
available memory then subtraction will underflow unsigned long.

> - mtest06_2: The default test case want to use 1G or more. Change GB to MB
> for embedded devices (in mmap2.c).

This needs an explanation and also to answer if this
testcase will still be valid for non-embedded devices.

Regards,
Jan

  reply	other threads:[~2016-03-14 12:10 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-09 10:40 [LTP] Question about perf_event_open/Cap_bounds/su01 test cases Julio Cruz Barroso
2016-03-09 12:08 ` Jan Stancek
2016-03-09 13:52   ` Cyril Hrubis
2016-03-09 14:08 ` Cyril Hrubis
2016-03-11 13:35   ` Julio Cruz Barroso
2016-03-11 15:35     ` Jan Stancek
2016-03-12 12:01       ` Julio Cruz Barroso
2016-03-12 13:45         ` Jan Stancek
2016-03-13 11:39           ` Julio Cruz Barroso
2016-03-14 12:10             ` Jan Stancek [this message]
2016-03-15 10:35               ` Julio Cruz Barroso
2016-03-14 18:18     ` Cyril Hrubis
2016-03-15 15:07       ` Cyril Hrubis

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1284145136.9339833.1457957439775.JavaMail.zimbra@redhat.com \
    --to=jstancek@redhat.com \
    --cc=ltp@lists.linux.it \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.