All of lore.kernel.org
 help / color / mirror / Atom feed
From: Florian Weimer <fw@deneb.enyo.de>
To: ltp@lists.linux.it
Subject: [LTP] [bug?] clone(CLONE_IO) failing after kernel commit commit ef2c41cf38a7
Date: Tue, 05 May 2020 13:08:02 +0200	[thread overview]
Message-ID: <87pnbi3ai5.fsf@mid.deneb.enyo.de> (raw)
In-Reply-To: <20200505095813.z7kakdbiwq7ewnmx@wittgenstein> (Christian Brauner's message of "Tue, 5 May 2020 11:58:13 +0200")

* Christian Brauner:

> On Tue, May 05, 2020 at 11:36:36AM +0200, Florian Weimer wrote:
>> * Christian Brauner:
>> >> Have any flags been added recently?
>> >
>> > /* Flags for the clone3() syscall. */
>> > #define CLONE_CLEAR_SIGHAND 0x100000000ULL /* Clear any signal handler and reset to SIG_DFL. */
>> > #define CLONE_INTO_CGROUP 0x200000000ULL /* Clone into a specific cgroup given the right permissions. */
>> 
>> Are those flags expected to be compatible with the legacy clone
>> interface on 64-bit architectures?
>
> No, they are clone3() only. clone() is deprecated wrt to new features.

But without masking the clone_flags argument, won't it be passed down
to the implementation which is also used to back clone3?

> If I understood the original mail correctly, then the issue is caused by
> an interaction with sign extension and a the new flag value
> CLONE_INTO_CGROUP being defined.

Could be, but for that to happen, the flag would have to be passed
down, no?

> So from what I gather from Jan's initial mail is that when clone() is
> called on ppc64le with the CLONE_IO|SIGCHLD flag:
> clone(do_child, stack+1024*1024, CLONE_IO|SIGCHLD, NULL, NULL, NULL, NULL);
> that the sign extension causes bits to be set that raise the
> CLONE_INTO_CGROUP flag. And since the do_fork() codepath is the same for
> legacy clone() and clone3() the kernel will think that someone requested
> CLONE_INTO_CGROUP but hasn't passed a valid fd to a cgroup. If that is
> the only issue here then couldn't we just do:
>
> clone_flags &= ~CLONE3_ONLY_FLAGS?
>
> and move on, i.e. all future clone3() flags we'll just remove since we
> can assume that they have been accidently set. Even if they have been
> intentionally set we can just ignore them since that's in line with
> legacy clone()'s (questionable) tradition of ignoring unknown flags.
> Thoughts? Or am I missing some subtlety here?

What's the difference between

  clone_flags &= ~CLONE3_ONLY_FLAGS;

and

  clone_flags &= (unsigned) -1;

in this context?

  parent reply	other threads:[~2020-05-05 11:08 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <100149681.11244932.1588661282331.JavaMail.zimbra@redhat.com>
2020-05-05  7:28 ` [LTP] [bug?] clone(CLONE_IO) failing after kernel commit commit ef2c41cf38a7 Jan Stancek
2020-05-05  7:49   ` Florian Weimer
2020-05-05  7:59     ` Christian Brauner
2020-05-05  8:02       ` Christian Brauner
2020-05-05  8:32     ` Christian Brauner
2020-05-05  8:58       ` Jan Stancek
2020-05-05  9:05       ` Florian Weimer
2020-05-05  9:15         ` Christian Brauner
2020-05-05  9:36           ` Florian Weimer
2020-05-05  9:58             ` Christian Brauner
2020-05-05 10:21               ` Christian Brauner
2020-05-05 11:34                 ` Florian Weimer
2020-05-05 11:35                 ` Dmitry V. Levin
2020-05-05 11:43                   ` Christian Brauner
2020-05-05 11:49                     ` Dmitry V. Levin
2020-05-05 11:57                       ` Christian Brauner
2020-05-05 11:08               ` Florian Weimer [this message]
2020-05-05 11:26                 ` Christian Brauner
2020-05-05  7:54   ` Andreas Schwab

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=87pnbi3ai5.fsf@mid.deneb.enyo.de \
    --to=fw@deneb.enyo.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 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.