public inbox for ltp@lists.linux.it
 help / color / mirror / Atom feed
From: Cyril Hrubis <chrubis@suse.cz>
To: ltp@lists.linux.it
Subject: [LTP] [PATCH 1/2] fork07: Rewrite the test to a proper synchronization
Date: Fri, 2 Jul 2021 13:28:44 +0200	[thread overview]
Message-ID: <YN74bEchlEFD1nDN@yuki> (raw)
In-Reply-To: <20210701032931.132468-2-xieziyao@huawei.com>

Hi!
The more I look at the test to more I realize how broken it is.

It starts with a wrong premise that file offset changes, as a
consequences of read(), are not propagated between the child and parent
process for a file descriptor that has been opened by parent and
propagated to a child on a fork(). This is not true at all as internally
in kernel the child and parent file descriptor will refer to the same
open file structure. And the test avoids failures by reading a byte from
a libc FILE in the parent, which of course caches data in the FILE
buffer so the first read() in libc reads the whole buffer. After that
each forked child will get the exact FILE structure in it's userspace
memory with the buffered data.

In conclusion this test has to be deleted and we should write a new one
from a scratch.

When we are asked to check if file descriptors are passed down correctly
between forks it makes much more sense to do it as follows:

* Parent writes N bytes (for example 'a') to a file in setup()
* Parent opens a file descriptor for reading pointing to that file
* Parent forks N children
  - each child reads a byte from the file
    checks that the byte is 'a' then exits
* Parent waits the all the children
* Parent checks that the end of file is reached
  for example by checking that read() from the
  file descriptor returns 0


And the other way around would be:

* Parent opens a file descriptor for writing pointing to an empty file
  (the file should be unlinked() before the open with O_CREAT)
* Parent forks N children
  - each child writes a sequence of bytes 'test' or something like this
* Parent waits the all the children
* Parent checks that the file is filled with N string 'test' that are
  not interleaved

-- 
Cyril Hrubis
chrubis@suse.cz

  reply	other threads:[~2021-07-02 11:28 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-01  3:29 [LTP] [PATCH 0/2] syscalls/fork: Rewrite fork{07, 08} to a proper synchronization Xie Ziyao
2021-07-01  3:29 ` [LTP] [PATCH 1/2] fork07: Rewrite the test " Xie Ziyao
2021-07-02 11:28   ` Cyril Hrubis [this message]
2021-07-01  3:29 ` [LTP] [PATCH 2/2] fork08: " Xie Ziyao
2021-07-02 12:42   ` 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=YN74bEchlEFD1nDN@yuki \
    --to=chrubis@suse.cz \
    --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