linux-kernel - write() on pipe blocking due to in-page fragmentation?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <20110923164226.211a76dc@darkmoor.lan.box>
Date:	Fri, 23 Sep 2011 16:42:26 -0300
From:	Ricardo Nabinger Sanchez <rnsanchez@...hos.com.br>
To:	linux-kernel@...r.kernel.org
Subject: write() on pipe blocking due to in-page fragmentation?

Hello,

The simple program attached allocates a pipe, perform a number of
writes in it in order to fill the pipe, and then reads that data to
empty the pipe.  The argument is used to determine how much data to
write per write iteration.

Values that are power of 2 up to PIPE_BUF work without any issues.
Other values may cause the write() call to block.

For example, on a 32-bit machine:

(gdb) r 3
Starting program: /home/rnsanchez/Taghos/sshfs/pipe-test/single32 3
Pipe: 00000/32
  write: 65520..65523/65536^C
Program received signal SIGINT, Interrupt.
0xb7f2de5e in __write_nocancel () from /lib/libc.so.6
(gdb) bt
#0  0xb7f2de5e in __write_nocancel () from /lib/libc.so.6
#1  0x08048705 in main ()

Similar behavior on a 64-bit machine, different version of both Linux
kernel and glibc.

Intuitively, it seems that pages in the pipe are getting fragmented,
and eventually it will reach the limit of 16 pages and, if the data is
not consumed, will cause writers to block --- even though the data
would fit nicely otherwise.

Is this understanding correct?  If so, is it something that should be
fixed in the Linux kernel?

Or should the application ensure that data written to the pipe will be
done carefully as to not block a writer?

Thank you in advance for your attention.

Regards

-- 
Ricardo Nabinger Sanchez             http://www.taghos.com.br/

View attachment "single.c" of type "text/x-csrc" (1134 bytes)