Hello,
I noticed a strange behavior involving the tee() system call. Here's a sample
program:
#define _GNU_SOURCE
#include <assert.h>
#include <fcntl.h>
#include <stdio.h>
#include <string.h>
#include <unistd.h>
int main()
{
int pipe_A[2];
int pipe_B[2];
char buffer[2] = { 0 };
pipe(pipe_A);
pipe(pipe_B);
write(pipe_A[1], "AA", 2);
tee(pipe_A[0], pipe_B[1], 1, 0);
write(pipe_B[1], "B", 1);
read(pipe_A[0], buffer, 2);
printf("%.*s\n", 2, buffer);
assert(!memcmp(buffer, "AA", 2));
return 0;
}
It creates two pipes A and B, then writes two bytes "AA" to pipe A, then tee()s
one byte from pipe A to pipe B, then writes one byte "B" to pipe B.
At that point, I expected pipe A to still contain the bytes "AA", because tee()
does not consume the source data, nor was any data written to pipe A; nor should
it be possible to modify data already in a pipe (unless it was put there by
splice() or vmsplice()).
However, the actual behavior is that pipe A contains the bytes "AB". This
happens because the second byte was overwritten by the write to pipe B, as the
data in both pipes are backed by the same page, and the pipe is using
anon_pipe_buf_ops which has .can_merge = 1, so the backing page can be written
to by pipe_write().
Is this a bug? It certainly seems like it; you should *not* be able to modify
data in a pipe, given only the read end.
- Eric
