All of lore.kernel.org
 help / color / mirror / Atom feed
From: "José Pekkarinen" <jose.pekkarinen@unikie.com>
To: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Cc: buildroot <buildroot@buildroot.org>
Subject: Re: [Buildroot] [PATCH 2/7] package/minijail: new package
Date: Wed, 12 Jan 2022 17:08:26 +0200	[thread overview]
Message-ID: <CAJPV9MpjN_fPn04Z6crTsogUL2-UWjgBr2P-A9Uz-QYqYd_aGw@mail.gmail.com> (raw)
In-Reply-To: <20220112155103.7e6c11c0@windsurf>

On Wed, Jan 12, 2022 at 4:51 PM Thomas Petazzoni
<thomas.petazzoni@bootlin.com> wrote:
>
> Hello,
>
> On Wed, 12 Jan 2022 16:15:16 +0200
> José Pekkarinen <jose.pekkarinen@unikie.com> wrote:
>
> > > What are you "fixing"? You're replacing a prlimit() call by by
> > > setrlimit(), but why? What problem does it solve? Why is it correct to
> > > do that?
> >
> >     The problem is shown from as this:
> >
> > /home/pekkari/br-test-pkg/bootlin-armv5-uclibc/build/minijail-linux-v17/libminijail.c:
> > In function ‘set_rlimits_or_die’:
> > /home/pekkari/br-test-pkg/bootlin-armv5-uclibc/build/minijail-linux-v17/libminijail.c:1911:7:
> > error: implicit declaration of function ‘prlimit’; did you mean
> > ‘setrlimit’? [-Werror=implicit-function-declaration]
> > 1911 |   if (prlimit(j->initpid, j->rlimits[i].type, &limit, NULL))
> >      |       ^~~~~~~
> >      |       setrlimit
> >
> >     So I followed the suggestion, no more, no less.
>
> You shouldn't blindly follow compiler suggestions :-)
>
> prlimit() exists in musl. Was <sys/resource.h> included, as suggested
> by the prlimit() man page ?

    It is:

$ cat libminijail.c
[...]
#include <sys/resource.h>
[...]

> > > > +-static_assert(FD_SETSIZE >= MAX_PRESERVED_FDS * 2 - 1,
> > > > +-          "If true, ensure_no_fd_conflict will always find an unused fd.");
> > >
> > > You're not fixing the static_assert() here but simply dropping it. Why?
> > > When does it fail? What is the problem with it? Why is it safe to drop
> > > it?
> >
> >     It fails like this:
> >
> > /home/pekkari/br-test-pkg/bootlin-armv5-uclibc/build/minijail-linux-v17/libminijail.c:2623:15:
> > error: expected declaration specifiers or ‘...’ before numeric
> > constant
> > 2623 | static_assert(FD_SETSIZE >= MAX_PRESERVED_FDS * 2 - 1,
> >      |               ^~~~~~~~~~
> > /home/pekkari/br-test-pkg/bootlin-armv5-uclibc/build/minijail-linux-v17/libminijail.c:2624:8:
> > error: expected declaration specifiers or ‘...’ before string constant
> > 2624 |        "If true, ensure_no_fd_conflict will always find an unused fd.");
> >      |        ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >
> >     So my understanding is that this platform may
> > define static_assert in a different manner, and I
> > find no traces of the purpose of that isolated assert,
> > so the easier way to get around this was removing it.
>
> Well, the assert is there for a reason, so we need to understand what
> it is verifying, and whether it is safe to drop it.
>
> After checking, FD_SETSIZE seems to be defined to 1024 by glibc, musl
> and uclibc-ng, and MAX_PRESERVED_FDS is defined as 128 by the minijail
> code.
>
> Can you try using _Static_assert() instead, which is part of the C11
> standard?

    I'll do.

    Thanks!

    José.
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

  reply	other threads:[~2022-01-12 15:09 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-10 14:12 [Buildroot] [PATCH 1/7] package/opensc: new package José Pekkarinen
2021-12-10 14:12 ` [Buildroot] [PATCH 2/7] package/minijail: " José Pekkarinen
2021-12-10 14:48   ` Giulio Benetti
2021-12-10 18:15     ` Arnout Vandecappelle
2021-12-10 20:26       ` Giulio Benetti
2021-12-11  8:30         ` Arnout Vandecappelle
2021-12-11 11:53           ` Giulio Benetti
2021-12-10 19:57   ` Yann E. MORIN
2022-01-05 20:41   ` Thomas Petazzoni
2022-01-12 14:15     ` José Pekkarinen
2022-01-12 14:51       ` Thomas Petazzoni
2022-01-12 15:08         ` José Pekkarinen [this message]
2022-01-12 16:00           ` Thomas Petazzoni
2022-01-13  5:12             ` José Pekkarinen
2021-12-10 14:12 ` [Buildroot] [PATCH 3/7] package/bmx7: " José Pekkarinen
2021-12-10 14:52   ` Giulio Benetti
2021-12-10 20:07   ` Yann E. MORIN
2022-01-05 22:23   ` Thomas Petazzoni
2022-01-10  5:36     ` José Pekkarinen
2021-12-10 14:12 ` [Buildroot] [PATCH 4/7] package/alfred: " José Pekkarinen
2021-12-10 14:54   ` Giulio Benetti
2022-01-05 22:43   ` Thomas Petazzoni
2021-12-10 14:12 ` [Buildroot] [PATCH 5/7] package/aexpect: " José Pekkarinen
2021-12-10 14:56   ` Giulio Benetti
2021-12-10 20:11   ` Yann E. MORIN
2021-12-11  8:43     ` Arnout Vandecappelle
2021-12-11  9:17       ` Yann E. MORIN
2022-01-06  8:40   ` Thomas Petazzoni
2021-12-10 14:12 ` [Buildroot] [PATCH 6/7] package/avocado: " José Pekkarinen
2021-12-10 14:57   ` Giulio Benetti
2022-07-26  8:13   ` Thomas Petazzoni via buildroot
2021-12-10 14:12 ` [Buildroot] [PATCH 7/7] package/avocado-vt: " José Pekkarinen
2021-12-10 15:00   ` Giulio Benetti
2022-07-26  8:21   ` Thomas Petazzoni via buildroot
2022-07-28  6:07     ` José Pekkarinen via buildroot
2021-12-10 14:32 ` [Buildroot] [PATCH 1/7] package/opensc: " Giulio Benetti
2021-12-10 17:34   ` Yann E. MORIN
2021-12-10 14:49 ` Giulio Benetti
2021-12-10 17:06   ` Yann E. MORIN

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=CAJPV9MpjN_fPn04Z6crTsogUL2-UWjgBr2P-A9Uz-QYqYd_aGw@mail.gmail.com \
    --to=jose.pekkarinen@unikie.com \
    --cc=buildroot@buildroot.org \
    --cc=thomas.petazzoni@bootlin.com \
    /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.