linux-kernel - Re: [patch v3] splice: fix race with page invalidation

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]

Date:	Wed, 30 Jul 2008 22:45:34 +0200
From:	Miklos Szeredi <miklos@...redi.hu>
To:	torvalds@...ux-foundation.org
CC:	miklos@...redi.hu, jens.axboe@...cle.com,
	akpm@...ux-foundation.org, nickpiggin@...oo.com.au,
	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-mm@...ck.org
Subject: Re: [patch v3] splice: fix race with page invalidation

On Wed, 30 Jul 2008, Linus Torvalds wrote:
> On Wed, 30 Jul 2008, Miklos Szeredi wrote:
> > 
> > Take this patch as a bugfix.  It's not in any way showing the way
> > forward: as soon as you have the time, you can revert it and start
> > from the current state.
> > 
> > Hmm?
> 
> I dislike that mentality.
> 
> The fact is, it's not a bug-fix, it's just papering over the real problem.

It _is_ a bug fix.  See here, from man 2 splice:

RETURN VALUE
       Upon successful  completion,  splice()  returns  the  number  of  bytes
       spliced  to or from the pipe.  A return value of 0 means that there was
       no data to transfer, and it would not  make  sense  to  block,  because
       there are no writers connected to the write end of the pipe referred to
       by fd_in.

Currently splice on NFS, FUSE and a few other filesystems don't
conform to that clause: splice can return zero even if there's still
data to be read, just because the data happened to be invalidated
during the splicing.  That's a plain and clear bug, which has
absolutely nothing to do with NFS _exporting_.

> And by papering it over, it then just makes people less likely to bother 
> with the real issue.

I think you are talking about a totally separate issue: that NFSD's
use of splice can result in strange things if the file is truncated
while being read.  But this is an NFSD issue and I don't see that it
has _anything_ to do with the above bug in splice.  I think you are
just confusing the two things.

Miklos
--
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/