[LTP] [PATCH v4 3/3] syscalls/pipe2_03: Add new test for pipe2 O_DIRECT flag

From: Li Wang <liwang@redhat.com>
To: ltp@lists.linux.it
Subject: [LTP] [PATCH v4 3/3] syscalls/pipe2_03: Add new test for pipe2 O_DIRECT flag
Date: Thu, 30 Apr 2020 14:57:35 +0800	[thread overview]
Message-ID: <CAEemH2d-puNst+Mro8oSCiobw2dhHcQVaS=6YoBX=v2+hVMqzQ@mail.gmail.com> (raw)
In-Reply-To: <36bd1e20-414b-ec24-f7e3-16ef7e2395d9@cn.fujitsu.com>

Hi Xu,

Yang Xu <xuyang2018.jy@cn.fujitsu.com> wrote:

Hi Linus
>
>
> > On Sun, Apr 26, 2020 at 4:59 AM Li Wang <liwang@redhat.com> wrote:
> >>
> >>  From kernel code seems you are right. The pipe indeed takes use of
> PAGE_SIZE(ppc64le: 64kB) to split the writes data in the packetized mode
> (marked by O_DIRECT). But in the manual page, O_DIRECT indicates us the
> PIPE_BUF is the correct atomic unit.
>

> >
> > The manual is correct.
> >
> > PIPE_BUF is the size we _guarantee_ can be used atomically.
> >
> > The fact that in practice we do have bigger buffers on some platforms
> > is an implementation detail.
> >
> > Yes, that implementation detail can be visible, but basically any test
> > code that tries to test for "what if we use a bigger bug that
> > PIPE_BUF" is buggy. It's simply not guaranteed to work any more.
> >
> > O_DIRECT is kind of immaterial, except it's just one of those things
> > where the atomic size is slightly more visible. But basically,
> > packetized pipes with bigger packets than PIPE_BUF is random behavior.
> > It may work. It may not.
>

> Thanks for your explanation. I am more curious about the user scene of
> this flag.
>
>

> @Li, so how to design this test? In this test, we don't have complex
> scene to test this automic unit.
>

As Linus pointed out that "packetized pipes with bigger packets than
PIPE_BUF is random behavior", it looks the way in your test is not
guaranteed to work correctly, so I would drop the pipe2_03.c patch.
But according to the pipe(7) manual page, we could try to verify writing
data less than PIPE_BUF is atomic, and the pipe read end also should
provide us correct data in one packet at a time.

"
PIPE_BUF
  POSIX.1 says that write(2)s of less than PIPE_BUF bytes must be
  atomic: the output data is written to the pipe as a contiguous sequence
  ...
  POSIX.1 requires PIPE_BUF to be at least 512 bytes. (On Linux, PIPE_BUF
is 4096 bytes.)
  ...

  O_NONBLOCK disabled, n <= PIPE_BUF ...

  O_NONBLOCK enabled, n <= PIPE_BUF ...
"
http://man7.org/linux/man-pages/man7/pipe.7.html

-- 
Regards,
Li Wang
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linux.it/pipermail/ltp/attachments/20200430/854ddcf7/attachment.htm>