[PATCH] Change SIGPIPE's siginfo.si_code from SI_USER to SI_KERNEL.

[PATCH] Change SIGPIPE's siginfo.si_code from SI_USER to SI_KERNEL.

[Denys Vlasenko]

SI_USER means that this signal is sent by another process
via kill(2) et al.

Other cases when kernel sends signals, such as ^C,
SIGHUP on tty close, SIGXCPU when time limit is up,
SIGALRM from alarm(2) etc, we set si_code to SI_KERNEL.

SIGPIPE seems to be inconsistent here.

Signed-off-by: Denys Vlasenko <dvlasenk@redhat.com>
CC: Oleg Nesterov <oleg@redhat.com>
---
 fs/fuse/dev.c | 2 +-
 fs/pipe.c     | 4 ++--
 fs/splice.c   | 8 ++++----
 3 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/fs/fuse/dev.c b/fs/fuse/dev.c
index 1d55f94..de55774 100644
--- a/fs/fuse/dev.c
+++ b/fs/fuse/dev.c
@@ -1340,7 +1340,7 @@ static ssize_t fuse_dev_splice_read(struct file *in, loff_t *ppos,
 	pipe_lock(pipe);
 
 	if (!pipe->readers) {
-		send_sig(SIGPIPE, current, 0);
+		send_sig(SIGPIPE, current, 1);
 		if (!ret)
 			ret = -EPIPE;
 		goto out_unlock;
diff --git a/fs/pipe.c b/fs/pipe.c
index d2c45e1..ddd777e 100644
--- a/fs/pipe.c
+++ b/fs/pipe.c
@@ -514,7 +514,7 @@ pipe_write(struct kiocb *iocb, const struct iovec *_iov,
 	__pipe_lock(pipe);
 
 	if (!pipe->readers) {
-		send_sig(SIGPIPE, current, 0);
+		send_sig(SIGPIPE, current, 1);
 		ret = -EPIPE;
 		goto out;
 	}
@@ -563,7 +563,7 @@ redo1:
 		int bufs;
 
 		if (!pipe->readers) {
-			send_sig(SIGPIPE, current, 0);
+			send_sig(SIGPIPE, current, 1);
 			if (!ret)
 				ret = -EPIPE;
 			break;
diff --git a/fs/splice.c b/fs/splice.c
index 3b7ee65..1eb18da 100644
--- a/fs/splice.c
+++ b/fs/splice.c
@@ -197,7 +197,7 @@ ssize_t splice_to_pipe(struct pipe_inode_info *pipe,
 
 	for (;;) {
 		if (!pipe->readers) {
-			send_sig(SIGPIPE, current, 0);
+			send_sig(SIGPIPE, current, 1);
 			if (!ret)
 				ret = -EPIPE;
 			break;
@@ -1812,7 +1812,7 @@ static int opipe_prep(struct pipe_inode_info *pipe, unsigned int flags)
 
 	while (pipe->nrbufs >= pipe->buffers) {
 		if (!pipe->readers) {
-			send_sig(SIGPIPE, current, 0);
+			send_sig(SIGPIPE, current, 1);
 			ret = -EPIPE;
 			break;
 		}
@@ -1863,7 +1863,7 @@ retry:
 
 	do {
 		if (!opipe->readers) {
-			send_sig(SIGPIPE, current, 0);
+			send_sig(SIGPIPE, current, 1);
 			if (!ret)
 				ret = -EPIPE;
 			break;
@@ -1967,7 +1967,7 @@ static int link_pipe(struct pipe_inode_info *ipipe,
 
 	do {
 		if (!opipe->readers) {
-			send_sig(SIGPIPE, current, 0);
+			send_sig(SIGPIPE, current, 1);
 			if (!ret)
 				ret = -EPIPE;
 			break;
-- 
1.8.1.4

Re: [PATCH] Change SIGPIPE's siginfo.si_code from SI_USER to SI_KERNEL.

[Oleg Nesterov]

On 07/03, Denys Vlasenko wrote:
>
> @@ -514,7 +514,7 @@ pipe_write(struct kiocb *iocb, const struct iovec *_iov,
>  	__pipe_lock(pipe);
>
>  	if (!pipe->readers) {
> -		send_sig(SIGPIPE, current, 0);
> +		send_sig(SIGPIPE, current, 1);

Honestly, I simply have no idea what makes more sense in this case...
But I am not sure about this user-visible change. It can break
something and for what?

And if you do this then I guess you should also change net/.

Oleg.

Re: [PATCH] Change SIGPIPE's siginfo.si_code from SI_USER to SI_KERNEL.

[Denys Vlasenko]

On 07/03/2013 09:54 PM, Oleg Nesterov wrote:
> On 07/03, Denys Vlasenko wrote:
>>
>> @@ -514,7 +514,7 @@ pipe_write(struct kiocb *iocb, const struct iovec *_iov,
>>  	__pipe_lock(pipe);
>>
>>  	if (!pipe->readers) {
>> -		send_sig(SIGPIPE, current, 0);
>> +		send_sig(SIGPIPE, current, 1);
> 
> Honestly, I simply have no idea what makes more sense in this case...

I guess I should have explained what prompted me to send this patch.

I am coding up a gdb extension which looks at a process which received
a signal and tries some heuristics on it which sya whether the observed
signal is a crash, and if it is, how likely it to be exploitable.
For example, a SIGSEGV due to smashed stack is more likely to be
a result of exploitable bug than a division by zero.

I want to quickly filter out cases where signal is clearly not a result
of program bug. Say, if program dies from SIGSEGV (or SIGBUS,
or SIGSYS...) which was *sent by the user via kill(2)*,
then it is not a bug in the program.

Naively, it looks like "if (siginfo.si_code <= 0) not_a_bug()"
is what would do that. In particular, si_code == 0 (SI_USER)
is set by kill(2).

But then I discovered that SI_USER is also set by signals
from other sources. SIGPIPE from write(2) is one of them.

This basically makes "si_code == SI_USER" condition non-informative:
userspace can't really draw any useful conclusion from seeing that.
"Maybe it was a kill(2), maybe it was from kernel". Not good.

Note that other similar signals, say, a SIGTTIN received
when backgrounded read(2) attempts to read from a tty,
use SI_KERNEL code. There is no consistency already.

-- 
vda