linux-kernel - Re: Pipe buffers' limit of 16 * 4K

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-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.LNX.1.10.0805290000400.19264@fbirervta.pbzchgretzou.qr>
Date:	Thu, 29 May 2008 00:05:40 +0200 (CEST)
From:	Jan Engelhardt <jengelh@...ozas.de>
To:	Fausto Richetti Blanco <fausto.blanco@...il.com>
cc:	linux-kernel@...r.kernel.org, riel@...hat.com
Subject: Re: Pipe buffers' limit of 16 * 4K


On Wednesday 2008-05-28 23:22, Fausto Richetti Blanco wrote:
>>
>>    It works very well, except when the input has more than 4K (or 16
>> * 4K in more recent kernels) because the restore_input() blocks at
>> this limit.
>>
>>    I kwow there are other solutions to my problem (e.g: using a
>> thread, moving our decisions to the lib, etc...) by I'm wondering if
>> making the pipe buffers' limit adjustable is not a good idea. Maybe it
>> should be helpful for another things too (like Jan Engelhardt said in
>> his email).
>>
>>    In fact, I didn't find any way of restoring the input (with the
>> input being the 'read side' of a pipe) other than using pipes. That's
>> because I've decided to ask this in the linux-kernel list. Is there a
>> reason for this limit not to be an adjustable parameter ?

You could have a look at the tee(2) system call and see whether it helps
you a bit. Something along the lines of:

	int pfd[2];
	pipe(pfd); /* tee() wants an fd... */
	tee(STDIN_FILENO, pfd[1], len, SPLICE_F_NONBLOCK);
	read(pfd[0], ..., also in nonblock-mode)

Of course this also has a certain drawback, namely that the pipe will
only give you as much bytes as it carries, and no more than that,
because the write side of the pipe at STDIN_FILENO is currently
blocking exactly because the pipe is full.
In other words, at most "4K" to be read with tee().

Alternatively, if you need to consume an unspecified amount, it is
probably best to go the thread way.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/