linux-kernel - Re: splice blocks indefinitely when len

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

Message-ID: <20061031072722.GU14055@kernel.dk>
Date:	Tue, 31 Oct 2006 08:27:23 +0100
From:	Jens Axboe <jens.axboe@...cle.com>
To:	Stephen Hemminger <shemminger@...l.org>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: splice blocks indefinitely when len > 64k?

On Mon, Oct 30 2006, Stephen Hemminger wrote:
> On Mon, 30 Oct 2006 20:54:27 +0100
> Jens Axboe <jens.axboe@...cle.com> wrote:
> 
> > On Mon, Oct 30 2006, Daniel Drake wrote:
> > > Hi,
> > > 
> > > I'm experimenting with splice and have run into some unusual behaviour.
> > > 
> > > I am using the utilities in git://brick.kernel.dk/data/git/splice.git
> > > 
> > > In splice.h, when changing SPLICE_SIZE from:
> > > 
> > > #define SPLICE_SIZE (64*1024)
> > > 
> > > to
> > > 
> > > #define SPLICE_SIZE ((64*1024)+1)
> > > 
> > > splice-cp hangs indefinitely when copying files sized 65537 bytes or
> > > more. It hangs on the first splice() call.
> > > 
> > > Is this a bug? I'd like to be able to copy much more than 64kb on a
> > > single splice call.
> > 
> > You can't, internally splice is using a pipe which is currently confined
> > to 16 pages. The SPLICE_SIZE define isn't a suggestion in the code, it
> > reflects that. You could fix splice-cp to not stall on changing that,
> > however that still doesn't change the fact that you can only move chunks
> > of 64kb (on your arch) right now.
> > 
> 
> It could accept larger values but only move SPLICE_SIZE, assuming
> caller checked for partial completions.

(one more time, for the list)

The caller has to check for partial completions, it would be like
calling read(2) or write(2) and not checking the return value if you
didn't. SPLICE_SIZE is the _maximum_ amount of data that current fits in
a pipe, there's no way to ensure that you will actually be able to write
that amount - the pipe may not be empty when you begin writing, or
someone else could be filling it as well.

The initial mail said that splice-cp doesn't work when you change the
SPLICE_SIZE define, and I'm not at all surprised that this is the case.
That would be like saying program foo doesn't work when you randomly
change some define or variable in the source.

-- 
Jens Axboe

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