Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756950AbYJJJqf (ORCPT ); Fri, 10 Oct 2008 05:46:35 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752718AbYJJJqX (ORCPT ); Fri, 10 Oct 2008 05:46:23 -0400 Received: from fxip-0047f.externet.hu ([88.209.222.127]:37342 "EHLO pomaz-ex.szeredi.hu" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752714AbYJJJqW (ORCPT ); Fri, 10 Oct 2008 05:46:22 -0400 To: torvalds@linux-foundation.org CC: stable@kernel.org, miklos@szeredi.hu, jens.axboe@oracle.com, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org In-reply-to: (message from Linus Torvalds on Thu, 9 Oct 2008 14:14:19 -0700 (PDT)) Subject: Re: splice vs O_APPEND References: Message-Id: From: Miklos Szeredi Date: Fri, 10 Oct 2008 11:46:00 +0200 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2764 Lines: 67 On Thu, 9 Oct 2008, Linus Torvalds wrote: > On Thu, 9 Oct 2008, Miklos Szeredi wrote: > > > > The thing is, the append-only attribute is absolutely useless without > > being able to depend on it. So in that sense I think the IS_APPEND > > issue is important, and I'm fine with your original proposal for that > > (except we don't need the IS_IMMUTABLE check). > > Heh. In the meantime, I had grown to hate that more complex patch. > > So because I do see your point with IS_APPEND (being different from > O_APPEND), but because I also think that O_APPEND itself is a gray and > murky area, I just committed the following. I doubt anybody will ever even > notice it, but while I think it's all debatable, we might as well debate > it with this in place. I do agree that it's "safer" behaviour. Thanks. I suspect this qualifies for stable kernels too. Stable team, can you please add this to your queue? The final commit is: commit efc968d450e013049a662d22727cf132618dcb2f Author: Linus Torvalds Date: Thu Oct 9 14:04:54 2008 -0700 Don't allow splice() to files opened with O_APPEND This is debatable, but while we're debating it, let's disallow the combination of splice and an O_APPEND destination. It's not entirely clear what the semantics of O_APPEND should be, and POSIX apparently expects pwrite() to ignore O_APPEND, for example. So we could make up any semantics we want, including the old ones. But Miklos convinced me that we should at least give it some thought, and that accepting writes at arbitrary offsets is wrong at least for IS_APPEND() files (which always have O_APPEND set, even if the reverse isn't true: you can obviously have O_APPEND set on a regular file). So disallow O_APPEND entirely for now. I doubt anybody cares, and this way we have one less gray area to worry about. Reported-and-argued-for-by: Miklos Szeredi Acked-by: Jens Axboe Signed-off-by: Linus Torvalds diff --git a/fs/splice.c b/fs/splice.c index 1bbc6f4..a1e701c 100644 --- a/fs/splice.c +++ b/fs/splice.c @@ -898,6 +898,9 @@ static long do_splice_from(struct pipe_inode_info *pipe, struct file *out, if (unlikely(!(out->f_mode & FMODE_WRITE))) return -EBADF; + if (unlikely(out->f_flags & O_APPEND)) + return -EINVAL; + ret = rw_verify_area(WRITE, out, ppos, len); if (unlikely(ret < 0)) return ret; -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/