<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-size:small"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Apr 23, 2020 at 6:32 PM Yang Xu <<a href="mailto:xuyang2018.jy@cn.fujitsu.com">xuyang2018.jy@cn.fujitsu.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi LI<br>
<br>
> <br>
> <br>
> On Thu, Apr 23, 2020 at 4:45 PM Yang Xu <<a href="mailto:xuyang2018.jy@cn.fujitsu.com" target="_blank">xuyang2018.jy@cn.fujitsu.com</a> <br>
> <mailto:<a href="mailto:xuyang2018.jy@cn.fujitsu.com" target="_blank">xuyang2018.jy@cn.fujitsu.com</a>>> wrote:<br>
> <br>
> ...<br>
> > I got a failure on the ppc64le platform(page size: 65536kB).<br>
> ><br>
> > # ./pipe2_03<br>
> > tst_test.c:1246: INFO: Timeout per run is 0h 05m 00s<br>
> > pipe_size = 1048576<br>
> > PIPE_BUF = 4096<br>
> > packet_num = 256<br>
> > safe_macros.c:457: BROK: pipe2_03.c:58:<br>
> > write(4,0x1001d2b8,18446744073709551615) failed:<br>
> EAGAIN/EWOULDBLOCK (11)<br>
> I think we should remove PIPE_BUF and use page_size because we use a<br>
> page to store data not a fixed size buffer in kernel. as below(also,<br>
> man-pages[1] is need to update):<br>
> <br>
> <br>
> Emm, If PIPE_BUF doesn't work correctly, shouldn't this a kernel pipe <br>
> bug? I think we need to take a close look at what happened there but not <br>
> to replace by using page_size directly.<br>
> -- <br>
It is only defined in limit.h(I only think it is a error in limit.h) and <br>
PIPE_BUF doesn't be used in kernel.<br></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">[PAGE_SIZE or PIPE_BUFF]</div><br></div><div class="gmail_default" style="font-size:small">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. Since PIPE_BUF is defined to 4kB that is equal to PAGE_SIZE on x86_64 so your test gets PASS there. </div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">I feel confused about whether it's a kernel pipe bug or just need to correct the manual page. </div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">@Linus, can you give some advice on this? Thanks!</div><div class="gmail_default" style="font-size:small"></div><div class="gmail_default" style="font-size:small"><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
In kernel code, pipes use struct pipe_buffer to store buffer data and <br>
other info,<br>
struct pipe_buffer {<br>
struct page *page; //alloc page to store data<br>
unsigned int offset, len;<br>
const struct pipe_buf_operations *ops;<br>
unsigned int flags; //<br>
unsigned long private;<br>
};<br>
<br>
as my pipe2_01.c said we only make buf with PIPE_BUF_FLAG_PACKET flag in <br>
write end , and read will check this flag. This unit is a page instead <br>
of this PIPE_BUF macro.<br>
<br>
Best Regards<br>
Yang Xu<br>
> Regards,<br>
> Li Wang<br>
<br>
<br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div>Regards,<br></div><div>Li Wang<br></div></div></div></div>