public inbox for ltp@lists.linux.it
 help / color / mirror / Atom feed
From: Richard Palethorpe <rpalethorpe@suse.de>
To: ltp@lists.linux.it
Subject: [LTP] [PATCH] thp01: Find largest arguments size
Date: Fri, 01 Sep 2017 11:34:56 +0200	[thread overview]
Message-ID: <87val2bw3j.fsf@our.domain.is.not.set> (raw)
In-Reply-To: <CAEemH2cdcy16cDifgMd=_pk=3z3M79Z=04iA4c0xfktgdONDog@mail.gmail.com>

Hello,

Thanks for the review,

Li Wang writes:

> On Thu, Aug 31, 2017 at 4:34 PM, Richard Palethorpe
> <rpalethorpe@suse.com> wrote:
>> Because of kernel commit da029c11e6b1 the arguments size for exec has been
>> reduced considerably. This causes exec to fail with E2BIG, so we call it
>> repeatedly with a decreasing number of arguments until it is successful.
>>
>> As far as I know, there is no other reliable and easy way to determine the
>> maximum argument length.
>>
>> Signed-off-by: Richard Palethorpe <rpalethorpe@suse.com>
>> ---
>>  testcases/kernel/mem/thp/thp01.c | 83 ++++++++++++++++++++++++----------------
>>  1 file changed, 50 insertions(+), 33 deletions(-)
>>
>> diff --git a/testcases/kernel/mem/thp/thp01.c b/testcases/kernel/mem/thp/thp01.c
>> index 101a9b5c8..b90b9b637 100644
>> --- a/testcases/kernel/mem/thp/thp01.c
>> +++ b/testcases/kernel/mem/thp/thp01.c
>> @@ -30,6 +30,7 @@
>>   * ....
>>   */
>>
>> +#include <errno.h>
>>  #include <sys/types.h>
>>  #include <sys/resource.h>
>>  #include <sys/wait.h>
>> @@ -38,56 +39,72 @@
>>  #include <stdlib.h>
>>  #include <unistd.h>
>>  #include "mem.h"
>> +#include "tst_minmax.h"
>> +#include "tst_safe_sysv_ipc.h"
>>
>> -#define ARRAY_SZ       256
>> +#define ARGS_SZ        256
>>
>> -static int ps;
>> -static long length;
>> -static char *array[ARRAY_SZ];
>> +static int shm_id;
>> +static char *args[ARGS_SZ];
>>  static char *arg;
>> -static struct rlimit rl = {
>> -       .rlim_cur = RLIM_INFINITY,
>> -       .rlim_max = RLIM_INFINITY,
>> -};
>> +static long *arg_count;
>
>
> Two queries:
>
> 1. Can't we declare the arg_count just as a global variable? why
> should we take use of share memory, only for the loop counting?

It forks so that it can call exec without overwriting the test process
image. Global variables are copy-on-write for a child process (unless we
use clone()), so the parent's memory would not be updated by the
child. We need the parent to be updated so that, when the next child is
run, it already has the correct argument count saving a lot of calls to
exec.

>
>
> 2. The kernel patch limit all arg stack usage to at most 75% of _STK_LIM (6MB),
> and here the size of arg_len is 32*PAGE_SIZE.  So it means that there
> almost only have 6MB/(PAGE_SIZE*32) numbers can be accepted in
> args[(*arg_count)], if it is a ppc64 machine(*arg_count == 3) that's
> OK, but if a system PAGE_SIZE > 192KB, then the test will be break and
> your loop is absolutely useless. About that, if we shrink the arg_len
> size, things would be better I guess.

That is true, but even on PPC64 with a default page size of 64Kb, the
default huge page size is 15MB (I think). So, on PPC64, we are only
doing a very basic test of exec on current kernels. Systems with page
sizes over 192KB seem even less likely to have huge pages smaller than
6MB.

However I don't see any harm in reducing the PAGE_SIZE coefficient to 1
and multiplying the ARGS_SZ by 32, this will make the test slower, but
more accurate at finding the maximum argument size while maintaining the
allocation size of the original reproducer.

--
Thank you,
Richard.

  reply	other threads:[~2017-09-01  9:34 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-08-31  8:34 [LTP] [PATCH] thp01: Find largest arguments size Richard Palethorpe
2017-09-01  7:05 ` Li Wang
2017-09-01  9:34   ` Richard Palethorpe [this message]
2017-09-01 10:44     ` Li Wang
2017-09-01 10:03 ` Cyril Hrubis
2017-09-01 14:13   ` [LTP] [PATCH v2] " Richard Palethorpe
2017-09-04 11:29     ` Li Wang
2017-09-11  9:26       ` Richard Palethorpe

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=87val2bw3j.fsf@our.domain.is.not.set \
    --to=rpalethorpe@suse.de \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox