2019-05-19 15:08:55 +03:00
// SPDX-License-Identifier: GPL-2.0-only
2006-03-30 17:15:30 +04:00
/*
* " splice " : joining two ropes together by interweaving their strands .
*
* This is the " extended pipe " functionality , where a pipe is used as
* an arbitrary in - memory buffer . Think of a pipe as a small kernel
* buffer that you can use to transfer data from one end to the other .
*
* The traditional unix read / write is extended with a " splice() " operation
* that transfers data buffers to or from a pipe buffer .
*
* Named by Larry McVoy , original implementation from Linus , extended by
2006-04-11 15:56:34 +04:00
* Jens to support splicing to files , network , direct splicing , etc and
* fixing lots of bugs .
2006-03-30 17:15:30 +04:00
*
2006-09-04 17:41:16 +04:00
* Copyright ( C ) 2005 - 2006 Jens Axboe < axboe @ kernel . dk >
2006-04-11 15:56:34 +04:00
* Copyright ( C ) 2005 - 2006 Linus Torvalds < torvalds @ osdl . org >
* Copyright ( C ) 2006 Ingo Molnar < mingo @ elte . hu >
2006-03-30 17:15:30 +04:00
*
*/
2016-11-01 16:40:16 +03:00
# include <linux/bvec.h>
2006-03-30 17:15:30 +04:00
# include <linux/fs.h>
# include <linux/file.h>
# include <linux/pagemap.h>
2007-06-04 11:59:47 +04:00
# include <linux/splice.h>
memcg: synchronized LRU
A big patch for changing memcg's LRU semantics.
Now,
- page_cgroup is linked to mem_cgroup's its own LRU (per zone).
- LRU of page_cgroup is not synchronous with global LRU.
- page and page_cgroup is one-to-one and statically allocated.
- To find page_cgroup is on what LRU, you have to check pc->mem_cgroup as
- lru = page_cgroup_zoneinfo(pc, nid_of_pc, zid_of_pc);
- SwapCache is handled.
And, when we handle LRU list of page_cgroup, we do following.
pc = lookup_page_cgroup(page);
lock_page_cgroup(pc); .....................(1)
mz = page_cgroup_zoneinfo(pc);
spin_lock(&mz->lru_lock);
.....add to LRU
spin_unlock(&mz->lru_lock);
unlock_page_cgroup(pc);
But (1) is spin_lock and we have to be afraid of dead-lock with zone->lru_lock.
So, trylock() is used at (1), now. Without (1), we can't trust "mz" is correct.
This is a trial to remove this dirty nesting of locks.
This patch changes mz->lru_lock to be zone->lru_lock.
Then, above sequence will be written as
spin_lock(&zone->lru_lock); # in vmscan.c or swap.c via global LRU
mem_cgroup_add/remove/etc_lru() {
pc = lookup_page_cgroup(page);
mz = page_cgroup_zoneinfo(pc);
if (PageCgroupUsed(pc)) {
....add to LRU
}
spin_lock(&zone->lru_lock); # in vmscan.c or swap.c via global LRU
This is much simpler.
(*) We're safe even if we don't take lock_page_cgroup(pc). Because..
1. When pc->mem_cgroup can be modified.
- at charge.
- at account_move().
2. at charge
the PCG_USED bit is not set before pc->mem_cgroup is fixed.
3. at account_move()
the page is isolated and not on LRU.
Pros.
- easy for maintenance.
- memcg can make use of laziness of pagevec.
- we don't have to duplicated LRU/Active/Unevictable bit in page_cgroup.
- LRU status of memcg will be synchronized with global LRU's one.
- # of locks are reduced.
- account_move() is simplified very much.
Cons.
- may increase cost of LRU rotation.
(no impact if memcg is not configured.)
Signed-off-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: Li Zefan <lizf@cn.fujitsu.com>
Cc: Balbir Singh <balbir@in.ibm.com>
Cc: Pavel Emelyanov <xemul@openvz.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-01-08 05:08:01 +03:00
# include <linux/memcontrol.h>
2006-03-30 17:15:30 +04:00
# include <linux/mm_inline.h>
2006-03-30 17:16:46 +04:00
# include <linux/swap.h>
2006-04-03 01:04:46 +04:00
# include <linux/writeback.h>
2011-11-17 08:57:37 +04:00
# include <linux/export.h>
2006-04-03 01:04:46 +04:00
# include <linux/syscalls.h>
2006-04-26 12:59:21 +04:00
# include <linux/uio.h>
2007-07-13 13:44:32 +04:00
# include <linux/security.h>
include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h
percpu.h is included by sched.h and module.h and thus ends up being
included when building most .c files. percpu.h includes slab.h which
in turn includes gfp.h making everything defined by the two files
universally available and complicating inclusion dependencies.
percpu.h -> slab.h dependency is about to be removed. Prepare for
this change by updating users of gfp and slab facilities include those
headers directly instead of assuming availability. As this conversion
needs to touch large number of source files, the following script is
used as the basis of conversion.
http://userweb.kernel.org/~tj/misc/slabh-sweep.py
The script does the followings.
* Scan files for gfp and slab usages and update includes such that
only the necessary includes are there. ie. if only gfp is used,
gfp.h, if slab is used, slab.h.
* When the script inserts a new include, it looks at the include
blocks and try to put the new include such that its order conforms
to its surrounding. It's put in the include block which contains
core kernel includes, in the same order that the rest are ordered -
alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
doesn't seem to be any matching order.
* If the script can't find a place to put a new include (mostly
because the file doesn't have fitting include block), it prints out
an error message indicating which .h file needs to be added to the
file.
The conversion was done in the following steps.
1. The initial automatic conversion of all .c files updated slightly
over 4000 files, deleting around 700 includes and adding ~480 gfp.h
and ~3000 slab.h inclusions. The script emitted errors for ~400
files.
2. Each error was manually checked. Some didn't need the inclusion,
some needed manual addition while adding it to implementation .h or
embedding .c file was more appropriate for others. This step added
inclusions to around 150 files.
3. The script was run again and the output was compared to the edits
from #2 to make sure no file was left behind.
4. Several build tests were done and a couple of problems were fixed.
e.g. lib/decompress_*.c used malloc/free() wrappers around slab
APIs requiring slab.h to be added manually.
5. The script was run on all .h files but without automatically
editing them as sprinkling gfp.h and slab.h inclusions around .h
files could easily lead to inclusion dependency hell. Most gfp.h
inclusion directives were ignored as stuff from gfp.h was usually
wildly available and often used in preprocessor macros. Each
slab.h inclusion directive was examined and added manually as
necessary.
6. percpu.h was updated not to include slab.h.
7. Build test were done on the following configurations and failures
were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my
distributed build env didn't work with gcov compiles) and a few
more options had to be turned off depending on archs to make things
build (like ipr on powerpc/64 which failed due to missing writeq).
* x86 and x86_64 UP and SMP allmodconfig and a custom test config.
* powerpc and powerpc64 SMP allmodconfig
* sparc and sparc64 SMP allmodconfig
* ia64 SMP allmodconfig
* s390 SMP allmodconfig
* alpha SMP allmodconfig
* um on x86_64 SMP allmodconfig
8. percpu.h modifications were reverted so that it could be applied as
a separate patch and serve as bisection point.
Given the fact that I had only a couple of failures from tests on step
6, I'm fairly confident about the coverage of this conversion patch.
If there is a breakage, it's likely to be something in one of the arch
headers which should be easily discoverable easily on most builds of
the specific arch.
Signed-off-by: Tejun Heo <tj@kernel.org>
Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
2010-03-24 11:04:11 +03:00
# include <linux/gfp.h>
2012-04-05 07:05:35 +04:00
# include <linux/socket.h>
2017-02-02 21:15:33 +03:00
# include <linux/sched/signal.h>
2013-03-20 21:19:30 +04:00
# include "internal.h"
2006-03-30 17:15:30 +04:00
2006-04-03 01:05:09 +04:00
/*
* Attempt to steal a page from a pipe buffer . This should perhaps go into
* a vm helper function , it ' s already simplified quite a bit by the
* addition of remove_mapping ( ) . If success is returned , the caller may
* attempt to reuse this page for another destination .
*/
2020-05-20 18:58:16 +03:00
static bool page_cache_pipe_buf_try_steal ( struct pipe_inode_info * pipe ,
struct pipe_buffer * buf )
2006-03-30 17:16:46 +04:00
{
struct page * page = buf - > page ;
2006-06-20 17:01:12 +04:00
struct address_space * mapping ;
2006-03-30 17:16:46 +04:00
2006-04-19 17:57:31 +04:00
lock_page ( page ) ;
2006-06-20 17:01:12 +04:00
mapping = page_mapping ( page ) ;
if ( mapping ) {
WARN_ON ( ! PageUptodate ( page ) ) ;
2006-03-30 17:16:46 +04:00
2006-06-20 17:01:12 +04:00
/*
* At least for ext2 with nobh option , we need to wait on
* writeback completing on this page , since we ' ll remove it
* from the pagecache . Otherwise truncate wont wait on the
* page , allowing the disk blocks to be reused by someone else
* before we actually wrote our data to them . fs corruption
* ensues .
*/
wait_on_page_writeback ( page ) ;
2006-04-03 01:10:32 +04:00
2009-04-03 19:42:36 +04:00
if ( page_has_private ( page ) & &
! try_to_release_page ( page , GFP_KERNEL ) )
2008-05-20 23:27:41 +04:00
goto out_unlock ;
2006-04-03 01:04:46 +04:00
2006-06-20 17:01:12 +04:00
/*
* If we succeeded in removing the mapping , set LRU flag
* and return good .
*/
if ( remove_mapping ( mapping , page ) ) {
buf - > flags | = PIPE_BUF_FLAG_LRU ;
2020-05-20 18:58:16 +03:00
return true ;
2006-06-20 17:01:12 +04:00
}
2006-04-19 17:57:31 +04:00
}
2006-03-30 17:16:46 +04:00
2006-06-20 17:01:12 +04:00
/*
* Raced with truncate or failed to remove page from current
* address space , unlock and return failure .
*/
2008-05-20 23:27:41 +04:00
out_unlock :
2006-06-20 17:01:12 +04:00
unlock_page ( page ) ;
2020-05-20 18:58:16 +03:00
return false ;
2006-03-30 17:16:46 +04:00
}
2006-05-03 12:41:33 +04:00
static void page_cache_pipe_buf_release ( struct pipe_inode_info * pipe ,
2006-03-30 17:15:30 +04:00
struct pipe_buffer * buf )
{
mm, fs: get rid of PAGE_CACHE_* and page_cache_{get,release} macros
PAGE_CACHE_{SIZE,SHIFT,MASK,ALIGN} macros were introduced *long* time
ago with promise that one day it will be possible to implement page
cache with bigger chunks than PAGE_SIZE.
This promise never materialized. And unlikely will.
We have many places where PAGE_CACHE_SIZE assumed to be equal to
PAGE_SIZE. And it's constant source of confusion on whether
PAGE_CACHE_* or PAGE_* constant should be used in a particular case,
especially on the border between fs and mm.
Global switching to PAGE_CACHE_SIZE != PAGE_SIZE would cause to much
breakage to be doable.
Let's stop pretending that pages in page cache are special. They are
not.
The changes are pretty straight-forward:
- <foo> << (PAGE_CACHE_SHIFT - PAGE_SHIFT) -> <foo>;
- <foo> >> (PAGE_CACHE_SHIFT - PAGE_SHIFT) -> <foo>;
- PAGE_CACHE_{SIZE,SHIFT,MASK,ALIGN} -> PAGE_{SIZE,SHIFT,MASK,ALIGN};
- page_cache_get() -> get_page();
- page_cache_release() -> put_page();
This patch contains automated changes generated with coccinelle using
script below. For some reason, coccinelle doesn't patch header files.
I've called spatch for them manually.
The only adjustment after coccinelle is revert of changes to
PAGE_CAHCE_ALIGN definition: we are going to drop it later.
There are few places in the code where coccinelle didn't reach. I'll
fix them manually in a separate patch. Comments and documentation also
will be addressed with the separate patch.
virtual patch
@@
expression E;
@@
- E << (PAGE_CACHE_SHIFT - PAGE_SHIFT)
+ E
@@
expression E;
@@
- E >> (PAGE_CACHE_SHIFT - PAGE_SHIFT)
+ E
@@
@@
- PAGE_CACHE_SHIFT
+ PAGE_SHIFT
@@
@@
- PAGE_CACHE_SIZE
+ PAGE_SIZE
@@
@@
- PAGE_CACHE_MASK
+ PAGE_MASK
@@
expression E;
@@
- PAGE_CACHE_ALIGN(E)
+ PAGE_ALIGN(E)
@@
expression E;
@@
- page_cache_get(E)
+ get_page(E)
@@
expression E;
@@
- page_cache_release(E)
+ put_page(E)
Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Acked-by: Michal Hocko <mhocko@suse.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2016-04-01 15:29:47 +03:00
put_page ( buf - > page ) ;
2006-05-03 12:35:26 +04:00
buf - > flags & = ~ PIPE_BUF_FLAG_LRU ;
2006-03-30 17:15:30 +04:00
}
2007-06-12 22:51:32 +04:00
/*
* Check whether the contents of buf is OK to access . Since the content
* is a page cache page , IO may be in flight .
*/
2007-06-14 15:10:48 +04:00
static int page_cache_pipe_buf_confirm ( struct pipe_inode_info * pipe ,
struct pipe_buffer * buf )
2006-03-30 17:15:30 +04:00
{
struct page * page = buf - > page ;
2006-04-10 11:04:41 +04:00
int err ;
2006-03-30 17:15:30 +04:00
if ( ! PageUptodate ( page ) ) {
2006-04-10 11:04:41 +04:00
lock_page ( page ) ;
/*
* Page got truncated / unhashed . This will cause a 0 - byte
2006-04-11 15:57:21 +04:00
* splice , if this is the first page .
2006-04-10 11:04:41 +04:00
*/
if ( ! page - > mapping ) {
err = - ENODATA ;
goto error ;
}
2006-03-30 17:15:30 +04:00
2006-04-10 11:04:41 +04:00
/*
2006-04-11 15:57:21 +04:00
* Uh oh , read - error from disk .
2006-04-10 11:04:41 +04:00
*/
if ( ! PageUptodate ( page ) ) {
err = - EIO ;
goto error ;
}
/*
2006-05-01 21:59:03 +04:00
* Page is ok afterall , we are done .
2006-04-10 11:04:41 +04:00
*/
2006-03-30 17:15:30 +04:00
unlock_page ( page ) ;
}
2006-05-01 21:59:03 +04:00
return 0 ;
2006-04-10 11:04:41 +04:00
error :
unlock_page ( page ) ;
2006-05-01 21:59:03 +04:00
return err ;
2006-04-11 17:51:17 +04:00
}
2011-07-26 04:12:32 +04:00
const struct pipe_buf_operations page_cache_pipe_buf_ops = {
2020-05-20 18:58:16 +03:00
. confirm = page_cache_pipe_buf_confirm ,
. release = page_cache_pipe_buf_release ,
. try_steal = page_cache_pipe_buf_try_steal ,
. get = generic_pipe_buf_get ,
2006-03-30 17:15:30 +04:00
} ;
2020-05-20 18:58:16 +03:00
static bool user_page_pipe_buf_try_steal ( struct pipe_inode_info * pipe ,
struct pipe_buffer * buf )
2006-04-26 12:59:21 +04:00
{
2006-05-01 22:02:33 +04:00
if ( ! ( buf - > flags & PIPE_BUF_FLAG_GIFT ) )
2020-05-20 18:58:16 +03:00
return false ;
2006-05-01 22:02:33 +04:00
2006-05-03 12:35:26 +04:00
buf - > flags | = PIPE_BUF_FLAG_LRU ;
2020-05-20 18:58:16 +03:00
return generic_pipe_buf_try_steal ( pipe , buf ) ;
2006-04-26 12:59:21 +04:00
}
2006-12-13 11:34:04 +03:00
static const struct pipe_buf_operations user_page_pipe_buf_ops = {
2020-05-20 18:58:16 +03:00
. release = page_cache_pipe_buf_release ,
. try_steal = user_page_pipe_buf_try_steal ,
. get = generic_pipe_buf_get ,
2006-04-26 12:59:21 +04:00
} ;
2011-05-23 21:58:53 +04:00
static void wakeup_pipe_readers ( struct pipe_inode_info * pipe )
{
smp_mb ( ) ;
pipe: use exclusive waits when reading or writing
This makes the pipe code use separate wait-queues and exclusive waiting
for readers and writers, avoiding a nasty thundering herd problem when
there are lots of readers waiting for data on a pipe (or, less commonly,
lots of writers waiting for a pipe to have space).
While this isn't a common occurrence in the traditional "use a pipe as a
data transport" case, where you typically only have a single reader and
a single writer process, there is one common special case: using a pipe
as a source of "locking tokens" rather than for data communication.
In particular, the GNU make jobserver code ends up using a pipe as a way
to limit parallelism, where each job consumes a token by reading a byte
from the jobserver pipe, and releases the token by writing a byte back
to the pipe.
This pattern is fairly traditional on Unix, and works very well, but
will waste a lot of time waking up a lot of processes when only a single
reader needs to be woken up when a writer releases a new token.
A simplified test-case of just this pipe interaction is to create 64
processes, and then pass a single token around between them (this
test-case also intentionally passes another token that gets ignored to
test the "wake up next" logic too, in case anybody wonders about it):
#include <unistd.h>
int main(int argc, char **argv)
{
int fd[2], counters[2];
pipe(fd);
counters[0] = 0;
counters[1] = -1;
write(fd[1], counters, sizeof(counters));
/* 64 processes */
fork(); fork(); fork(); fork(); fork(); fork();
do {
int i;
read(fd[0], &i, sizeof(i));
if (i < 0)
continue;
counters[0] = i+1;
write(fd[1], counters, (1+(i & 1)) *sizeof(int));
} while (counters[0] < 1000000);
return 0;
}
and in a perfect world, passing that token around should only cause one
context switch per transfer, when the writer of a token causes a
directed wakeup of just a single reader.
But with the "writer wakes all readers" model we traditionally had, on
my test box the above case causes more than an order of magnitude more
scheduling: instead of the expected ~1M context switches, "perf stat"
shows
231,852.37 msec task-clock # 15.857 CPUs utilized
11,250,961 context-switches # 0.049 M/sec
616,304 cpu-migrations # 0.003 M/sec
1,648 page-faults # 0.007 K/sec
1,097,903,998,514 cycles # 4.735 GHz
120,781,778,352 instructions # 0.11 insn per cycle
27,997,056,043 branches # 120.754 M/sec
283,581,233 branch-misses # 1.01% of all branches
14.621273891 seconds time elapsed
0.018243000 seconds user
3.611468000 seconds sys
before this commit.
After this commit, I get
5,229.55 msec task-clock # 3.072 CPUs utilized
1,212,233 context-switches # 0.232 M/sec
103,951 cpu-migrations # 0.020 M/sec
1,328 page-faults # 0.254 K/sec
21,307,456,166 cycles # 4.074 GHz
12,947,819,999 instructions # 0.61 insn per cycle
2,881,985,678 branches # 551.096 M/sec
64,267,015 branch-misses # 2.23% of all branches
1.702148350 seconds time elapsed
0.004868000 seconds user
0.110786000 seconds sys
instead. Much better.
[ Note! This kernel improvement seems to be very good at triggering a
race condition in the make jobserver (in GNU make 4.2.1) for me. It's
a long known bug that was fixed back in June 2017 by GNU make commit
b552b0525198 ("[SV 51159] Use a non-blocking read with pselect to
avoid hangs.").
But there wasn't a new release of GNU make until 4.3 on Jan 19 2020,
so a number of distributions may still have the buggy version. Some
have backported the fix to their 4.2.1 release, though, and even
without the fix it's quite timing-dependent whether the bug actually
is hit. ]
Josh Triplett says:
"I've been hammering on your pipe fix patch (switching to exclusive
wait queues) for a month or so, on several different systems, and I've
run into no issues with it. The patch *substantially* improves
parallel build times on large (~100 CPU) systems, both with parallel
make and with other things that use make's pipe-based jobserver.
All current distributions (including stable and long-term stable
distributions) have versions of GNU make that no longer have the
jobserver bug"
Tested-by: Josh Triplett <josh@joshtriplett.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2019-12-09 20:48:27 +03:00
if ( waitqueue_active ( & pipe - > rd_wait ) )
wake_up_interruptible ( & pipe - > rd_wait ) ;
2011-05-23 21:58:53 +04:00
kill_fasync ( & pipe - > fasync_readers , SIGIO , POLL_IN ) ;
}
2007-06-21 15:10:21 +04:00
/**
* splice_to_pipe - fill passed data into a pipe
* @ pipe : pipe to fill
* @ spd : data to fill
*
* Description :
2007-07-27 10:08:51 +04:00
* @ spd contains a map of pages and len / offset tuples , along with
2007-06-21 15:10:21 +04:00
* the struct pipe_buf_operations associated with these pages . This
* function will link that data to the pipe .
*
2006-04-03 01:05:09 +04:00
*/
2007-06-04 11:59:47 +04:00
ssize_t splice_to_pipe ( struct pipe_inode_info * pipe ,
struct splice_pipe_desc * spd )
2006-03-30 17:15:30 +04:00
{
2007-06-15 15:14:22 +04:00
unsigned int spd_pages = spd - > nr_pages ;
2019-11-15 16:30:32 +03:00
unsigned int tail = pipe - > tail ;
unsigned int head = pipe - > head ;
unsigned int mask = pipe - > ring_size - 1 ;
2016-09-18 03:44:45 +03:00
int ret = 0 , page_nr = 0 ;
2006-03-30 17:15:30 +04:00
2016-03-10 23:19:06 +03:00
if ( ! spd_pages )
return 0 ;
2016-09-18 03:44:45 +03:00
if ( unlikely ( ! pipe - > readers ) ) {
send_sig ( SIGPIPE , current , 0 ) ;
ret = - EPIPE ;
goto out ;
}
2006-03-30 17:15:30 +04:00
2019-10-16 18:47:32 +03:00
while ( ! pipe_full ( head , tail , pipe - > max_usage ) ) {
2019-11-15 16:30:32 +03:00
struct pipe_buffer * buf = & pipe - > bufs [ head & mask ] ;
2006-03-30 17:15:30 +04:00
2016-09-18 03:44:45 +03:00
buf - > page = spd - > pages [ page_nr ] ;
buf - > offset = spd - > partial [ page_nr ] . offset ;
buf - > len = spd - > partial [ page_nr ] . len ;
buf - > private = spd - > partial [ page_nr ] . private ;
buf - > ops = spd - > ops ;
2017-02-16 19:49:02 +03:00
buf - > flags = 0 ;
2006-03-30 17:15:30 +04:00
2019-11-15 16:30:32 +03:00
head + + ;
pipe - > head = head ;
2016-09-18 03:44:45 +03:00
page_nr + + ;
ret + = buf - > len ;
2006-04-02 23:46:35 +04:00
2016-09-18 03:44:45 +03:00
if ( ! - - spd - > nr_pages )
2006-03-30 17:15:30 +04:00
break ;
}
2016-09-18 03:44:45 +03:00
if ( ! ret )
ret = - EAGAIN ;
2006-03-30 17:15:30 +04:00
2016-09-18 03:44:45 +03:00
out :
2007-06-15 15:14:22 +04:00
while ( page_nr < spd_pages )
2007-11-07 10:29:47 +03:00
spd - > spd_release ( spd , page_nr + + ) ;
2006-03-30 17:15:30 +04:00
return ret ;
}
2015-05-21 18:00:01 +03:00
EXPORT_SYMBOL_GPL ( splice_to_pipe ) ;
2006-03-30 17:15:30 +04:00
2016-09-18 05:38:20 +03:00
ssize_t add_to_pipe ( struct pipe_inode_info * pipe , struct pipe_buffer * buf )
{
2019-11-15 16:30:32 +03:00
unsigned int head = pipe - > head ;
unsigned int tail = pipe - > tail ;
unsigned int mask = pipe - > ring_size - 1 ;
2016-09-18 05:38:20 +03:00
int ret ;
if ( unlikely ( ! pipe - > readers ) ) {
send_sig ( SIGPIPE , current , 0 ) ;
ret = - EPIPE ;
2019-10-16 18:47:32 +03:00
} else if ( pipe_full ( head , tail , pipe - > max_usage ) ) {
2016-09-18 05:38:20 +03:00
ret = - EAGAIN ;
} else {
2019-11-15 16:30:32 +03:00
pipe - > bufs [ head & mask ] = * buf ;
pipe - > head = head + 1 ;
2016-09-18 05:38:20 +03:00
return buf - > len ;
}
2016-09-27 11:45:12 +03:00
pipe_buf_release ( pipe , buf ) ;
2016-09-18 05:38:20 +03:00
return ret ;
}
EXPORT_SYMBOL ( add_to_pipe ) ;
2010-05-20 12:43:18 +04:00
/*
* Check if we need to grow the arrays holding pages and partial page
* descriptions .
*/
2012-06-12 17:24:40 +04:00
int splice_grow_spd ( const struct pipe_inode_info * pipe , struct splice_pipe_desc * spd )
2010-05-20 12:43:18 +04:00
{
2019-10-16 18:47:32 +03:00
unsigned int max_usage = READ_ONCE ( pipe - > max_usage ) ;
2012-06-12 17:24:40 +04:00
2019-11-15 16:30:32 +03:00
spd - > nr_pages_max = max_usage ;
if ( max_usage < = PIPE_DEF_BUFFERS )
2010-05-20 12:43:18 +04:00
return 0 ;
2019-11-15 16:30:32 +03:00
spd - > pages = kmalloc_array ( max_usage , sizeof ( struct page * ) , GFP_KERNEL ) ;
spd - > partial = kmalloc_array ( max_usage , sizeof ( struct partial_page ) ,
treewide: kmalloc() -> kmalloc_array()
The kmalloc() function has a 2-factor argument form, kmalloc_array(). This
patch replaces cases of:
kmalloc(a * b, gfp)
with:
kmalloc_array(a * b, gfp)
as well as handling cases of:
kmalloc(a * b * c, gfp)
with:
kmalloc(array3_size(a, b, c), gfp)
as it's slightly less ugly than:
kmalloc_array(array_size(a, b), c, gfp)
This does, however, attempt to ignore constant size factors like:
kmalloc(4 * 1024, gfp)
though any constants defined via macros get caught up in the conversion.
Any factors with a sizeof() of "unsigned char", "char", and "u8" were
dropped, since they're redundant.
The tools/ directory was manually excluded, since it has its own
implementation of kmalloc().
The Coccinelle script used for this was:
// Fix redundant parens around sizeof().
@@
type TYPE;
expression THING, E;
@@
(
kmalloc(
- (sizeof(TYPE)) * E
+ sizeof(TYPE) * E
, ...)
|
kmalloc(
- (sizeof(THING)) * E
+ sizeof(THING) * E
, ...)
)
// Drop single-byte sizes and redundant parens.
@@
expression COUNT;
typedef u8;
typedef __u8;
@@
(
kmalloc(
- sizeof(u8) * (COUNT)
+ COUNT
, ...)
|
kmalloc(
- sizeof(__u8) * (COUNT)
+ COUNT
, ...)
|
kmalloc(
- sizeof(char) * (COUNT)
+ COUNT
, ...)
|
kmalloc(
- sizeof(unsigned char) * (COUNT)
+ COUNT
, ...)
|
kmalloc(
- sizeof(u8) * COUNT
+ COUNT
, ...)
|
kmalloc(
- sizeof(__u8) * COUNT
+ COUNT
, ...)
|
kmalloc(
- sizeof(char) * COUNT
+ COUNT
, ...)
|
kmalloc(
- sizeof(unsigned char) * COUNT
+ COUNT
, ...)
)
// 2-factor product with sizeof(type/expression) and identifier or constant.
@@
type TYPE;
expression THING;
identifier COUNT_ID;
constant COUNT_CONST;
@@
(
- kmalloc
+ kmalloc_array
(
- sizeof(TYPE) * (COUNT_ID)
+ COUNT_ID, sizeof(TYPE)
, ...)
|
- kmalloc
+ kmalloc_array
(
- sizeof(TYPE) * COUNT_ID
+ COUNT_ID, sizeof(TYPE)
, ...)
|
- kmalloc
+ kmalloc_array
(
- sizeof(TYPE) * (COUNT_CONST)
+ COUNT_CONST, sizeof(TYPE)
, ...)
|
- kmalloc
+ kmalloc_array
(
- sizeof(TYPE) * COUNT_CONST
+ COUNT_CONST, sizeof(TYPE)
, ...)
|
- kmalloc
+ kmalloc_array
(
- sizeof(THING) * (COUNT_ID)
+ COUNT_ID, sizeof(THING)
, ...)
|
- kmalloc
+ kmalloc_array
(
- sizeof(THING) * COUNT_ID
+ COUNT_ID, sizeof(THING)
, ...)
|
- kmalloc
+ kmalloc_array
(
- sizeof(THING) * (COUNT_CONST)
+ COUNT_CONST, sizeof(THING)
, ...)
|
- kmalloc
+ kmalloc_array
(
- sizeof(THING) * COUNT_CONST
+ COUNT_CONST, sizeof(THING)
, ...)
)
// 2-factor product, only identifiers.
@@
identifier SIZE, COUNT;
@@
- kmalloc
+ kmalloc_array
(
- SIZE * COUNT
+ COUNT, SIZE
, ...)
// 3-factor product with 1 sizeof(type) or sizeof(expression), with
// redundant parens removed.
@@
expression THING;
identifier STRIDE, COUNT;
type TYPE;
@@
(
kmalloc(
- sizeof(TYPE) * (COUNT) * (STRIDE)
+ array3_size(COUNT, STRIDE, sizeof(TYPE))
, ...)
|
kmalloc(
- sizeof(TYPE) * (COUNT) * STRIDE
+ array3_size(COUNT, STRIDE, sizeof(TYPE))
, ...)
|
kmalloc(
- sizeof(TYPE) * COUNT * (STRIDE)
+ array3_size(COUNT, STRIDE, sizeof(TYPE))
, ...)
|
kmalloc(
- sizeof(TYPE) * COUNT * STRIDE
+ array3_size(COUNT, STRIDE, sizeof(TYPE))
, ...)
|
kmalloc(
- sizeof(THING) * (COUNT) * (STRIDE)
+ array3_size(COUNT, STRIDE, sizeof(THING))
, ...)
|
kmalloc(
- sizeof(THING) * (COUNT) * STRIDE
+ array3_size(COUNT, STRIDE, sizeof(THING))
, ...)
|
kmalloc(
- sizeof(THING) * COUNT * (STRIDE)
+ array3_size(COUNT, STRIDE, sizeof(THING))
, ...)
|
kmalloc(
- sizeof(THING) * COUNT * STRIDE
+ array3_size(COUNT, STRIDE, sizeof(THING))
, ...)
)
// 3-factor product with 2 sizeof(variable), with redundant parens removed.
@@
expression THING1, THING2;
identifier COUNT;
type TYPE1, TYPE2;
@@
(
kmalloc(
- sizeof(TYPE1) * sizeof(TYPE2) * COUNT
+ array3_size(COUNT, sizeof(TYPE1), sizeof(TYPE2))
, ...)
|
kmalloc(
- sizeof(TYPE1) * sizeof(THING2) * (COUNT)
+ array3_size(COUNT, sizeof(TYPE1), sizeof(TYPE2))
, ...)
|
kmalloc(
- sizeof(THING1) * sizeof(THING2) * COUNT
+ array3_size(COUNT, sizeof(THING1), sizeof(THING2))
, ...)
|
kmalloc(
- sizeof(THING1) * sizeof(THING2) * (COUNT)
+ array3_size(COUNT, sizeof(THING1), sizeof(THING2))
, ...)
|
kmalloc(
- sizeof(TYPE1) * sizeof(THING2) * COUNT
+ array3_size(COUNT, sizeof(TYPE1), sizeof(THING2))
, ...)
|
kmalloc(
- sizeof(TYPE1) * sizeof(THING2) * (COUNT)
+ array3_size(COUNT, sizeof(TYPE1), sizeof(THING2))
, ...)
)
// 3-factor product, only identifiers, with redundant parens removed.
@@
identifier STRIDE, SIZE, COUNT;
@@
(
kmalloc(
- (COUNT) * STRIDE * SIZE
+ array3_size(COUNT, STRIDE, SIZE)
, ...)
|
kmalloc(
- COUNT * (STRIDE) * SIZE
+ array3_size(COUNT, STRIDE, SIZE)
, ...)
|
kmalloc(
- COUNT * STRIDE * (SIZE)
+ array3_size(COUNT, STRIDE, SIZE)
, ...)
|
kmalloc(
- (COUNT) * (STRIDE) * SIZE
+ array3_size(COUNT, STRIDE, SIZE)
, ...)
|
kmalloc(
- COUNT * (STRIDE) * (SIZE)
+ array3_size(COUNT, STRIDE, SIZE)
, ...)
|
kmalloc(
- (COUNT) * STRIDE * (SIZE)
+ array3_size(COUNT, STRIDE, SIZE)
, ...)
|
kmalloc(
- (COUNT) * (STRIDE) * (SIZE)
+ array3_size(COUNT, STRIDE, SIZE)
, ...)
|
kmalloc(
- COUNT * STRIDE * SIZE
+ array3_size(COUNT, STRIDE, SIZE)
, ...)
)
// Any remaining multi-factor products, first at least 3-factor products,
// when they're not all constants...
@@
expression E1, E2, E3;
constant C1, C2, C3;
@@
(
kmalloc(C1 * C2 * C3, ...)
|
kmalloc(
- (E1) * E2 * E3
+ array3_size(E1, E2, E3)
, ...)
|
kmalloc(
- (E1) * (E2) * E3
+ array3_size(E1, E2, E3)
, ...)
|
kmalloc(
- (E1) * (E2) * (E3)
+ array3_size(E1, E2, E3)
, ...)
|
kmalloc(
- E1 * E2 * E3
+ array3_size(E1, E2, E3)
, ...)
)
// And then all remaining 2 factors products when they're not all constants,
// keeping sizeof() as the second factor argument.
@@
expression THING, E1, E2;
type TYPE;
constant C1, C2, C3;
@@
(
kmalloc(sizeof(THING) * C2, ...)
|
kmalloc(sizeof(TYPE) * C2, ...)
|
kmalloc(C1 * C2 * C3, ...)
|
kmalloc(C1 * C2, ...)
|
- kmalloc
+ kmalloc_array
(
- sizeof(TYPE) * (E2)
+ E2, sizeof(TYPE)
, ...)
|
- kmalloc
+ kmalloc_array
(
- sizeof(TYPE) * E2
+ E2, sizeof(TYPE)
, ...)
|
- kmalloc
+ kmalloc_array
(
- sizeof(THING) * (E2)
+ E2, sizeof(THING)
, ...)
|
- kmalloc
+ kmalloc_array
(
- sizeof(THING) * E2
+ E2, sizeof(THING)
, ...)
|
- kmalloc
+ kmalloc_array
(
- (E1) * E2
+ E1, E2
, ...)
|
- kmalloc
+ kmalloc_array
(
- (E1) * (E2)
+ E1, E2
, ...)
|
- kmalloc
+ kmalloc_array
(
- E1 * E2
+ E1, E2
, ...)
)
Signed-off-by: Kees Cook <keescook@chromium.org>
2018-06-12 23:55:00 +03:00
GFP_KERNEL ) ;
2010-05-20 12:43:18 +04:00
if ( spd - > pages & & spd - > partial )
return 0 ;
kfree ( spd - > pages ) ;
kfree ( spd - > partial ) ;
return - ENOMEM ;
}
2012-06-12 17:24:40 +04:00
void splice_shrink_spd ( struct splice_pipe_desc * spd )
2010-05-20 12:43:18 +04:00
{
2012-06-12 17:24:40 +04:00
if ( spd - > nr_pages_max < = PIPE_DEF_BUFFERS )
2010-05-20 12:43:18 +04:00
return ;
kfree ( spd - > pages ) ;
kfree ( spd - > partial ) ;
}
2006-04-03 01:05:09 +04:00
/**
* generic_file_splice_read - splice data from file to a pipe
* @ in : file to splice from
2007-06-21 15:10:21 +04:00
* @ ppos : position in @ in
2006-04-03 01:05:09 +04:00
* @ pipe : pipe to splice to
* @ len : number of bytes to splice
* @ flags : splice modifier flags
*
2007-06-21 15:10:21 +04:00
* Description :
* Will read pages from given file and fill them into a pipe . Can be
2016-09-23 06:35:42 +03:00
* used as long as it has more or less sane - > read_iter ( ) .
2007-06-21 15:10:21 +04:00
*
2006-04-03 01:05:09 +04:00
*/
2006-04-11 16:57:50 +04:00
ssize_t generic_file_splice_read ( struct file * in , loff_t * ppos ,
struct pipe_inode_info * pipe , size_t len ,
unsigned int flags )
2006-03-30 17:15:30 +04:00
{
2016-09-23 06:35:42 +03:00
struct iov_iter to ;
struct kiocb kiocb ;
2019-11-15 16:30:32 +03:00
unsigned int i_head ;
int ret ;
2015-04-16 02:15:17 +03:00
2018-10-20 02:57:56 +03:00
iov_iter_pipe ( & to , READ , pipe , len ) ;
2019-11-15 16:30:32 +03:00
i_head = to . head ;
2016-09-23 06:35:42 +03:00
init_sync_kiocb ( & kiocb , in ) ;
kiocb . ki_pos = * ppos ;
2017-02-20 18:51:23 +03:00
ret = call_read_iter ( in , & kiocb , & to ) ;
2009-08-15 10:43:22 +04:00
if ( ret > 0 ) {
2016-09-23 06:35:42 +03:00
* ppos = kiocb . ki_pos ;
2009-08-15 10:43:22 +04:00
file_accessed ( in ) ;
2016-09-23 06:35:42 +03:00
} else if ( ret < 0 ) {
2019-11-15 16:30:32 +03:00
to . head = i_head ;
2016-10-10 20:26:27 +03:00
to . iov_offset = 0 ;
iov_iter_advance ( & to , 0 ) ; /* to free what was emitted */
2016-09-23 06:35:42 +03:00
/*
* callers of - > splice_read ( ) expect - EAGAIN on
* " can't put anything in there " , rather than - EFAULT .
*/
if ( ret = = - EFAULT )
ret = - EAGAIN ;
2009-08-15 10:43:22 +04:00
}
2006-03-30 17:15:30 +04:00
return ret ;
}
2006-04-03 01:06:05 +04:00
EXPORT_SYMBOL ( generic_file_splice_read ) ;
2016-09-22 23:33:12 +03:00
const struct pipe_buf_operations default_pipe_buf_ops = {
2020-05-20 18:58:16 +03:00
. release = generic_pipe_buf_release ,
. try_steal = generic_pipe_buf_try_steal ,
. get = generic_pipe_buf_get ,
2009-05-07 17:37:36 +04:00
} ;
2014-01-22 22:36:57 +04:00
/* Pipe buffer operations for a socket and similar. */
const struct pipe_buf_operations nosteal_pipe_buf_ops = {
2020-05-20 18:58:16 +03:00
. release = generic_pipe_buf_release ,
. get = generic_pipe_buf_get ,
2014-01-22 22:36:57 +04:00
} ;
EXPORT_SYMBOL ( nosteal_pipe_buf_ops ) ;
2006-03-30 17:15:30 +04:00
/*
2006-04-03 01:04:46 +04:00
* Send ' sd - > len ' bytes to socket from ' sd - > file ' at position ' sd - > pos '
2006-04-25 17:42:00 +04:00
* using sendpage ( ) . Return the number of bytes sent .
2006-03-30 17:15:30 +04:00
*/
2006-05-03 12:41:33 +04:00
static int pipe_to_sendpage ( struct pipe_inode_info * pipe ,
2006-03-30 17:15:30 +04:00
struct pipe_buffer * buf , struct splice_desc * sd )
{
2007-06-14 15:08:55 +04:00
struct file * file = sd - > u . file ;
2006-03-30 17:15:30 +04:00
loff_t pos = sd - > pos ;
2010-12-17 10:56:44 +03:00
int more ;
2006-03-30 17:15:30 +04:00
2013-09-23 00:27:52 +04:00
if ( ! likely ( file - > f_op - > sendpage ) )
2010-12-17 10:56:44 +03:00
return - EINVAL ;
2012-04-05 07:05:35 +04:00
more = ( sd - > flags & SPLICE_F_MORE ) ? MSG_MORE : 0 ;
2013-01-06 22:21:49 +04:00
2019-11-15 16:30:32 +03:00
if ( sd - > len < sd - > total_len & &
pipe_occupancy ( pipe - > head , pipe - > tail ) > 1 )
2012-04-05 07:05:35 +04:00
more | = MSG_SENDPAGE_NOTLAST ;
2013-01-06 22:21:49 +04:00
2010-12-17 10:56:44 +03:00
return file - > f_op - > sendpage ( file , buf - > page , buf - > offset ,
sd - > len , & pos , more ) ;
2006-03-30 17:15:30 +04:00
}
2009-04-14 21:48:36 +04:00
static void wakeup_pipe_writers ( struct pipe_inode_info * pipe )
{
smp_mb ( ) ;
pipe: use exclusive waits when reading or writing
This makes the pipe code use separate wait-queues and exclusive waiting
for readers and writers, avoiding a nasty thundering herd problem when
there are lots of readers waiting for data on a pipe (or, less commonly,
lots of writers waiting for a pipe to have space).
While this isn't a common occurrence in the traditional "use a pipe as a
data transport" case, where you typically only have a single reader and
a single writer process, there is one common special case: using a pipe
as a source of "locking tokens" rather than for data communication.
In particular, the GNU make jobserver code ends up using a pipe as a way
to limit parallelism, where each job consumes a token by reading a byte
from the jobserver pipe, and releases the token by writing a byte back
to the pipe.
This pattern is fairly traditional on Unix, and works very well, but
will waste a lot of time waking up a lot of processes when only a single
reader needs to be woken up when a writer releases a new token.
A simplified test-case of just this pipe interaction is to create 64
processes, and then pass a single token around between them (this
test-case also intentionally passes another token that gets ignored to
test the "wake up next" logic too, in case anybody wonders about it):
#include <unistd.h>
int main(int argc, char **argv)
{
int fd[2], counters[2];
pipe(fd);
counters[0] = 0;
counters[1] = -1;
write(fd[1], counters, sizeof(counters));
/* 64 processes */
fork(); fork(); fork(); fork(); fork(); fork();
do {
int i;
read(fd[0], &i, sizeof(i));
if (i < 0)
continue;
counters[0] = i+1;
write(fd[1], counters, (1+(i & 1)) *sizeof(int));
} while (counters[0] < 1000000);
return 0;
}
and in a perfect world, passing that token around should only cause one
context switch per transfer, when the writer of a token causes a
directed wakeup of just a single reader.
But with the "writer wakes all readers" model we traditionally had, on
my test box the above case causes more than an order of magnitude more
scheduling: instead of the expected ~1M context switches, "perf stat"
shows
231,852.37 msec task-clock # 15.857 CPUs utilized
11,250,961 context-switches # 0.049 M/sec
616,304 cpu-migrations # 0.003 M/sec
1,648 page-faults # 0.007 K/sec
1,097,903,998,514 cycles # 4.735 GHz
120,781,778,352 instructions # 0.11 insn per cycle
27,997,056,043 branches # 120.754 M/sec
283,581,233 branch-misses # 1.01% of all branches
14.621273891 seconds time elapsed
0.018243000 seconds user
3.611468000 seconds sys
before this commit.
After this commit, I get
5,229.55 msec task-clock # 3.072 CPUs utilized
1,212,233 context-switches # 0.232 M/sec
103,951 cpu-migrations # 0.020 M/sec
1,328 page-faults # 0.254 K/sec
21,307,456,166 cycles # 4.074 GHz
12,947,819,999 instructions # 0.61 insn per cycle
2,881,985,678 branches # 551.096 M/sec
64,267,015 branch-misses # 2.23% of all branches
1.702148350 seconds time elapsed
0.004868000 seconds user
0.110786000 seconds sys
instead. Much better.
[ Note! This kernel improvement seems to be very good at triggering a
race condition in the make jobserver (in GNU make 4.2.1) for me. It's
a long known bug that was fixed back in June 2017 by GNU make commit
b552b0525198 ("[SV 51159] Use a non-blocking read with pselect to
avoid hangs.").
But there wasn't a new release of GNU make until 4.3 on Jan 19 2020,
so a number of distributions may still have the buggy version. Some
have backported the fix to their 4.2.1 release, though, and even
without the fix it's quite timing-dependent whether the bug actually
is hit. ]
Josh Triplett says:
"I've been hammering on your pipe fix patch (switching to exclusive
wait queues) for a month or so, on several different systems, and I've
run into no issues with it. The patch *substantially* improves
parallel build times on large (~100 CPU) systems, both with parallel
make and with other things that use make's pipe-based jobserver.
All current distributions (including stable and long-term stable
distributions) have versions of GNU make that no longer have the
jobserver bug"
Tested-by: Josh Triplett <josh@joshtriplett.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2019-12-09 20:48:27 +03:00
if ( waitqueue_active ( & pipe - > wr_wait ) )
wake_up_interruptible ( & pipe - > wr_wait ) ;
2009-04-14 21:48:36 +04:00
kill_fasync ( & pipe - > fasync_writers , SIGIO , POLL_OUT ) ;
}
2007-06-21 15:10:21 +04:00
/**
2009-04-14 21:48:36 +04:00
* splice_from_pipe_feed - feed available data from a pipe to a file
2007-06-21 15:10:21 +04:00
* @ pipe : pipe to splice from
* @ sd : information to @ actor
* @ actor : handler that splices the data
*
* Description :
2009-04-14 21:48:36 +04:00
* This function loops over the pipe and calls @ actor to do the
* actual moving of a single struct pipe_buffer to the desired
* destination . It returns when there ' s no more buffers left in
* the pipe or if the requested number of bytes ( @ sd - > total_len )
* have been copied . It returns a positive number ( one ) if the
* pipe needs to be filled with more data , zero if the required
* number of bytes have been copied and - errno on error .
2007-06-21 15:10:21 +04:00
*
2009-04-14 21:48:36 +04:00
* This , together with splice_from_pipe_ { begin , end , next } , may be
* used to implement the functionality of __splice_from_pipe ( ) when
* locking is required around copying the pipe buffers to the
* destination .
2006-04-03 01:05:09 +04:00
*/
2014-04-05 12:35:49 +04:00
static int splice_from_pipe_feed ( struct pipe_inode_info * pipe , struct splice_desc * sd ,
2009-04-14 21:48:36 +04:00
splice_actor * actor )
2006-03-30 17:15:30 +04:00
{
2019-11-15 16:30:32 +03:00
unsigned int head = pipe - > head ;
unsigned int tail = pipe - > tail ;
unsigned int mask = pipe - > ring_size - 1 ;
2009-04-14 21:48:36 +04:00
int ret ;
2006-03-30 17:15:30 +04:00
2019-12-06 23:40:35 +03:00
while ( ! pipe_empty ( head , tail ) ) {
2019-11-15 16:30:32 +03:00
struct pipe_buffer * buf = & pipe - > bufs [ tail & mask ] ;
2006-03-30 17:15:30 +04:00
2009-04-14 21:48:36 +04:00
sd - > len = buf - > len ;
if ( sd - > len > sd - > total_len )
sd - > len = sd - > total_len ;
2006-03-30 17:15:30 +04:00
2016-09-27 11:45:12 +03:00
ret = pipe_buf_confirm ( pipe , buf ) ;
2010-12-17 10:56:44 +03:00
if ( unlikely ( ret ) ) {
2009-04-14 21:48:36 +04:00
if ( ret = = - ENODATA )
ret = 0 ;
return ret ;
}
2010-12-17 10:56:44 +03:00
ret = actor ( pipe , buf , sd ) ;
if ( ret < = 0 )
return ret ;
2009-04-14 21:48:36 +04:00
buf - > offset + = ret ;
buf - > len - = ret ;
sd - > num_spliced + = ret ;
sd - > len - = ret ;
sd - > pos + = ret ;
sd - > total_len - = ret ;
if ( ! buf - > len ) {
2016-09-27 11:45:12 +03:00
pipe_buf_release ( pipe , buf ) ;
2019-11-15 16:30:32 +03:00
tail + + ;
pipe - > tail = tail ;
2013-03-21 19:01:38 +04:00
if ( pipe - > files )
2009-04-14 21:48:36 +04:00
sd - > need_wakeup = true ;
}
2006-03-30 17:15:30 +04:00
2009-04-14 21:48:36 +04:00
if ( ! sd - > total_len )
return 0 ;
}
2006-03-30 17:15:30 +04:00
2009-04-14 21:48:36 +04:00
return 1 ;
}
2006-03-30 17:15:30 +04:00
splice: teach splice pipe reading about empty pipe buffers
Tetsuo Handa reports that splice() can return 0 before the real EOF, if
the data in the splice source pipe is an empty pipe buffer. That empty
pipe buffer case doesn't happen in any normal situation, but you can
trigger it by doing a write to a pipe that fails due to a page fault.
Tetsuo has a test-case to show the behavior:
#define _GNU_SOURCE
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <unistd.h>
int main(int argc, char *argv[])
{
const int fd = open("/tmp/testfile", O_WRONLY | O_CREAT, 0600);
int pipe_fd[2] = { -1, -1 };
pipe(pipe_fd);
write(pipe_fd[1], NULL, 4096);
/* This splice() should wait unless interrupted. */
return !splice(pipe_fd[0], NULL, fd, NULL, 65536, 0);
}
which results in
write(5, NULL, 4096) = -1 EFAULT (Bad address)
splice(4, NULL, 3, NULL, 65536, 0) = 0
and this can confuse splice() users into believing they have hit EOF
prematurely.
The issue was introduced when the pipe write code started pre-allocating
the pipe buffers before copying data from user space.
This is modified verion of Tetsuo's original patch.
Fixes: a194dfe6e6f6 ("pipe: Rearrange sequence in pipe_write() to preallocate slot")
Link:https://lore.kernel.org/linux-fsdevel/20201005121339.4063-1-penguin-kernel@I-love.SAKURA.ne.jp/
Reported-by: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
Acked-by: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2020-10-05 21:26:27 +03:00
/* We know we have a pipe buffer, but maybe it's empty? */
static inline bool eat_empty_buffer ( struct pipe_inode_info * pipe )
{
unsigned int tail = pipe - > tail ;
unsigned int mask = pipe - > ring_size - 1 ;
struct pipe_buffer * buf = & pipe - > bufs [ tail & mask ] ;
if ( unlikely ( ! buf - > len ) ) {
pipe_buf_release ( pipe , buf ) ;
pipe - > tail = tail + 1 ;
return true ;
}
return false ;
}
2009-04-14 21:48:36 +04:00
/**
* splice_from_pipe_next - wait for some data to splice from
* @ pipe : pipe to splice from
* @ sd : information about the splice operation
*
* Description :
* This function will wait for some data and return a positive
* value ( one ) if pipe buffers are available . It will return zero
* or - errno if no more data needs to be spliced .
*/
2014-04-05 12:35:49 +04:00
static int splice_from_pipe_next ( struct pipe_inode_info * pipe , struct splice_desc * sd )
2009-04-14 21:48:36 +04:00
{
2015-11-23 15:09:50 +03:00
/*
* Check for signal early to make process killable when there are
* always buffers available
*/
if ( signal_pending ( current ) )
return - ERESTARTSYS ;
splice: teach splice pipe reading about empty pipe buffers
Tetsuo Handa reports that splice() can return 0 before the real EOF, if
the data in the splice source pipe is an empty pipe buffer. That empty
pipe buffer case doesn't happen in any normal situation, but you can
trigger it by doing a write to a pipe that fails due to a page fault.
Tetsuo has a test-case to show the behavior:
#define _GNU_SOURCE
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <unistd.h>
int main(int argc, char *argv[])
{
const int fd = open("/tmp/testfile", O_WRONLY | O_CREAT, 0600);
int pipe_fd[2] = { -1, -1 };
pipe(pipe_fd);
write(pipe_fd[1], NULL, 4096);
/* This splice() should wait unless interrupted. */
return !splice(pipe_fd[0], NULL, fd, NULL, 65536, 0);
}
which results in
write(5, NULL, 4096) = -1 EFAULT (Bad address)
splice(4, NULL, 3, NULL, 65536, 0) = 0
and this can confuse splice() users into believing they have hit EOF
prematurely.
The issue was introduced when the pipe write code started pre-allocating
the pipe buffers before copying data from user space.
This is modified verion of Tetsuo's original patch.
Fixes: a194dfe6e6f6 ("pipe: Rearrange sequence in pipe_write() to preallocate slot")
Link:https://lore.kernel.org/linux-fsdevel/20201005121339.4063-1-penguin-kernel@I-love.SAKURA.ne.jp/
Reported-by: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
Acked-by: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2020-10-05 21:26:27 +03:00
repeat :
2019-11-15 16:30:32 +03:00
while ( pipe_empty ( pipe - > head , pipe - > tail ) ) {
2009-04-14 21:48:36 +04:00
if ( ! pipe - > writers )
return 0 ;
2006-04-25 17:42:00 +04:00
pipe: remove 'waiting_writers' merging logic
This code is ancient, and goes back to when we only had a single page
for the pipe buffers. The exact history is hidden in the mists of time
(ie "before git", and in fact predates the BK repository too).
At that long-ago point in time, it actually helped to try to merge big
back-and-forth pipe reads and writes, and not limit pipe reads to the
single pipe buffer in length just because that was all we had at a time.
However, since then we've expanded the pipe buffers to multiple pages,
and this logic really doesn't seem to make sense. And a lot of it is
somewhat questionable (ie "hmm, the user asked for a non-blocking read,
but we see that there's a writer pending, so let's wait anyway to get
the extra data that the writer will have").
But more importantly, it makes the "go to sleep" logic much less
obvious, and considering the wakeup issues we've had, I want to make for
less of those kinds of things.
Cc: David Howells <dhowells@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2019-12-08 00:21:01 +03:00
if ( sd - > num_spliced )
2009-04-14 21:48:36 +04:00
return 0 ;
2006-04-11 15:57:21 +04:00
2009-04-14 21:48:36 +04:00
if ( sd - > flags & SPLICE_F_NONBLOCK )
return - EAGAIN ;
2006-03-30 17:15:30 +04:00
2009-04-14 21:48:36 +04:00
if ( signal_pending ( current ) )
return - ERESTARTSYS ;
2006-03-30 17:15:30 +04:00
2009-04-14 21:48:36 +04:00
if ( sd - > need_wakeup ) {
wakeup_pipe_writers ( pipe ) ;
sd - > need_wakeup = false ;
2006-03-30 17:15:30 +04:00
}
pipe: remove pipe_wait() and fix wakeup race with splice
The pipe splice code still used the old model of waiting for pipe IO by
using a non-specific "pipe_wait()" that waited for any pipe event to
happen, which depended on all pipe IO being entirely serialized by the
pipe lock. So by checking the state you were waiting for, and then
adding yourself to the wait queue before dropping the lock, you were
guaranteed to see all the wakeups.
Strictly speaking, the actual wakeups were not done under the lock, but
the pipe_wait() model still worked, because since the waiter held the
lock when checking whether it should sleep, it would always see the
current state, and the wakeup was always done after updating the state.
However, commit 0ddad21d3e99 ("pipe: use exclusive waits when reading or
writing") split the single wait-queue into two, and in the process also
made the "wait for event" code wait for _two_ wait queues, and that then
showed a race with the wakers that were not serialized by the pipe lock.
It's only splice that used that "pipe_wait()" model, so the problem
wasn't obvious, but Josef Bacik reports:
"I hit a hang with fstest btrfs/187, which does a btrfs send into
/dev/null. This works by creating a pipe, the write side is given to
the kernel to write into, and the read side is handed to a thread that
splices into a file, in this case /dev/null.
The box that was hung had the write side stuck here [pipe_write] and
the read side stuck here [splice_from_pipe_next -> pipe_wait].
[ more details about pipe_wait() scenario ]
The problem is we're doing the prepare_to_wait, which sets our state
each time, however we can be woken up either with reads or writes. In
the case above we race with the WRITER waking us up, and re-set our
state to INTERRUPTIBLE, and thus never break out of schedule"
Josef had a patch that avoided the issue in pipe_wait() by just making
it set the state only once, but the deeper problem is that pipe_wait()
depends on a level of synchonization by the pipe mutex that it really
shouldn't. And the whole "wait for any pipe state change" model really
isn't very good to begin with.
So rather than trying to work around things in pipe_wait(), remove that
legacy model of "wait for arbitrary pipe event" entirely, and actually
create functions that wait for the pipe actually being readable or
writable, and can do so without depending on the pipe lock serializing
everything.
Fixes: 0ddad21d3e99 ("pipe: use exclusive waits when reading or writing")
Link: https://lore.kernel.org/linux-fsdevel/bfa88b5ad6f069b2b679316b9e495a970130416c.1601567868.git.josef@toxicpanda.com/
Reported-by: Josef Bacik <josef@toxicpanda.com>
Reviewed-and-tested-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2020-10-02 05:14:36 +03:00
pipe_wait_readable ( pipe ) ;
2009-04-14 21:48:36 +04:00
}
2006-04-02 23:46:35 +04:00
splice: teach splice pipe reading about empty pipe buffers
Tetsuo Handa reports that splice() can return 0 before the real EOF, if
the data in the splice source pipe is an empty pipe buffer. That empty
pipe buffer case doesn't happen in any normal situation, but you can
trigger it by doing a write to a pipe that fails due to a page fault.
Tetsuo has a test-case to show the behavior:
#define _GNU_SOURCE
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <unistd.h>
int main(int argc, char *argv[])
{
const int fd = open("/tmp/testfile", O_WRONLY | O_CREAT, 0600);
int pipe_fd[2] = { -1, -1 };
pipe(pipe_fd);
write(pipe_fd[1], NULL, 4096);
/* This splice() should wait unless interrupted. */
return !splice(pipe_fd[0], NULL, fd, NULL, 65536, 0);
}
which results in
write(5, NULL, 4096) = -1 EFAULT (Bad address)
splice(4, NULL, 3, NULL, 65536, 0) = 0
and this can confuse splice() users into believing they have hit EOF
prematurely.
The issue was introduced when the pipe write code started pre-allocating
the pipe buffers before copying data from user space.
This is modified verion of Tetsuo's original patch.
Fixes: a194dfe6e6f6 ("pipe: Rearrange sequence in pipe_write() to preallocate slot")
Link:https://lore.kernel.org/linux-fsdevel/20201005121339.4063-1-penguin-kernel@I-love.SAKURA.ne.jp/
Reported-by: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
Acked-by: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2020-10-05 21:26:27 +03:00
if ( eat_empty_buffer ( pipe ) )
goto repeat ;
2009-04-14 21:48:36 +04:00
return 1 ;
}
2006-03-30 17:15:30 +04:00
2009-04-14 21:48:36 +04:00
/**
* splice_from_pipe_begin - start splicing from pipe
2009-04-17 06:09:55 +04:00
* @ sd : information about the splice operation
2009-04-14 21:48:36 +04:00
*
* Description :
* This function should be called before a loop containing
* splice_from_pipe_next ( ) and splice_from_pipe_feed ( ) to
* initialize the necessary fields of @ sd .
*/
2014-04-05 12:35:49 +04:00
static void splice_from_pipe_begin ( struct splice_desc * sd )
2009-04-14 21:48:36 +04:00
{
sd - > num_spliced = 0 ;
sd - > need_wakeup = false ;
}
2006-03-30 17:15:30 +04:00
2009-04-14 21:48:36 +04:00
/**
* splice_from_pipe_end - finish splicing from pipe
* @ pipe : pipe to splice from
* @ sd : information about the splice operation
*
* Description :
* This function will wake up pipe writers if necessary . It should
* be called after a loop containing splice_from_pipe_next ( ) and
* splice_from_pipe_feed ( ) .
*/
2014-04-05 12:35:49 +04:00
static void splice_from_pipe_end ( struct pipe_inode_info * pipe , struct splice_desc * sd )
2009-04-14 21:48:36 +04:00
{
if ( sd - > need_wakeup )
wakeup_pipe_writers ( pipe ) ;
}
2006-03-30 17:15:30 +04:00
2009-04-14 21:48:36 +04:00
/**
* __splice_from_pipe - splice data from a pipe to given actor
* @ pipe : pipe to splice from
* @ sd : information to @ actor
* @ actor : handler that splices the data
*
* Description :
* This function does little more than loop over the pipe and call
* @ actor to do the actual moving of a single struct pipe_buffer to
* the desired destination . See pipe_to_file , pipe_to_sendpage , or
* pipe_to_user .
*
*/
ssize_t __splice_from_pipe ( struct pipe_inode_info * pipe , struct splice_desc * sd ,
splice_actor * actor )
{
int ret ;
2006-03-30 17:15:30 +04:00
2009-04-14 21:48:36 +04:00
splice_from_pipe_begin ( sd ) ;
do {
2015-11-23 15:09:51 +03:00
cond_resched ( ) ;
2009-04-14 21:48:36 +04:00
ret = splice_from_pipe_next ( pipe , sd ) ;
if ( ret > 0 )
ret = splice_from_pipe_feed ( pipe , sd , actor ) ;
} while ( ret > 0 ) ;
splice_from_pipe_end ( pipe , sd ) ;
return sd - > num_spliced ? sd - > num_spliced : ret ;
2006-03-30 17:15:30 +04:00
}
2007-03-21 15:11:02 +03:00
EXPORT_SYMBOL ( __splice_from_pipe ) ;
2006-03-30 17:15:30 +04:00
2007-06-21 15:10:21 +04:00
/**
* splice_from_pipe - splice data from a pipe to a file
* @ pipe : pipe to splice from
* @ out : file to splice to
* @ ppos : position in @ out
* @ len : how many bytes to splice
* @ flags : splice modifier flags
* @ actor : handler that splices the data
*
* Description :
2009-04-14 21:48:37 +04:00
* See __splice_from_pipe . This function locks the pipe inode ,
2007-06-21 15:10:21 +04:00
* otherwise it ' s identical to __splice_from_pipe ( ) .
*
*/
2006-10-17 20:43:07 +04:00
ssize_t splice_from_pipe ( struct pipe_inode_info * pipe , struct file * out ,
loff_t * ppos , size_t len , unsigned int flags ,
splice_actor * actor )
{
ssize_t ret ;
2007-06-12 23:17:17 +04:00
struct splice_desc sd = {
. total_len = len ,
. flags = flags ,
. pos = * ppos ,
2007-06-14 15:08:55 +04:00
. u . file = out ,
2007-06-12 23:17:17 +04:00
} ;
2006-10-17 20:43:07 +04:00
2009-04-14 21:48:41 +04:00
pipe_lock ( pipe ) ;
2007-06-12 23:17:17 +04:00
ret = __splice_from_pipe ( pipe , & sd , actor ) ;
2009-04-14 21:48:41 +04:00
pipe_unlock ( pipe ) ;
2006-10-17 20:43:07 +04:00
return ret ;
}
2014-04-05 12:27:08 +04:00
/**
* iter_file_splice_write - splice data from a pipe to a file
* @ pipe : pipe info
* @ out : file to write to
* @ ppos : position in @ out
* @ len : number of bytes to splice
* @ flags : splice modifier flags
*
* Description :
* Will either move or copy pages ( determined by @ flags options ) from
* the given pipe inode to the given file .
* This one is - > write_iter - based .
*
*/
ssize_t
iter_file_splice_write ( struct pipe_inode_info * pipe , struct file * out ,
loff_t * ppos , size_t len , unsigned int flags )
{
struct splice_desc sd = {
. total_len = len ,
. flags = flags ,
. pos = * ppos ,
. u . file = out ,
} ;
2019-10-16 18:47:32 +03:00
int nbufs = pipe - > max_usage ;
2014-04-05 12:27:08 +04:00
struct bio_vec * array = kcalloc ( nbufs , sizeof ( struct bio_vec ) ,
GFP_KERNEL ) ;
ssize_t ret ;
if ( unlikely ( ! array ) )
return - ENOMEM ;
pipe_lock ( pipe ) ;
splice_from_pipe_begin ( & sd ) ;
while ( sd . total_len ) {
struct iov_iter from ;
2019-12-06 23:40:35 +03:00
unsigned int head , tail , mask ;
2014-04-05 12:27:08 +04:00
size_t left ;
2019-11-15 16:30:32 +03:00
int n ;
2014-04-05 12:27:08 +04:00
ret = splice_from_pipe_next ( pipe , & sd ) ;
if ( ret < = 0 )
break ;
2019-10-16 18:47:32 +03:00
if ( unlikely ( nbufs < pipe - > max_usage ) ) {
2014-04-05 12:27:08 +04:00
kfree ( array ) ;
2019-10-16 18:47:32 +03:00
nbufs = pipe - > max_usage ;
2014-04-05 12:27:08 +04:00
array = kcalloc ( nbufs , sizeof ( struct bio_vec ) ,
GFP_KERNEL ) ;
if ( ! array ) {
ret = - ENOMEM ;
break ;
}
}
2019-12-06 23:40:35 +03:00
head = pipe - > head ;
tail = pipe - > tail ;
mask = pipe - > ring_size - 1 ;
2014-04-05 12:27:08 +04:00
/* build the vector */
left = sd . total_len ;
2021-01-09 19:02:57 +03:00
for ( n = 0 ; ! pipe_empty ( head , tail ) & & left & & n < nbufs ; tail + + ) {
2019-11-15 16:30:32 +03:00
struct pipe_buffer * buf = & pipe - > bufs [ tail & mask ] ;
2014-04-05 12:27:08 +04:00
size_t this_len = buf - > len ;
2021-01-09 19:02:57 +03:00
/* zero-length bvecs are not supported, skip them */
if ( ! this_len )
continue ;
this_len = min ( this_len , left ) ;
2014-04-05 12:27:08 +04:00
2016-09-27 11:45:12 +03:00
ret = pipe_buf_confirm ( pipe , buf ) ;
2014-04-05 12:27:08 +04:00
if ( unlikely ( ret ) ) {
if ( ret = = - ENODATA )
ret = 0 ;
goto done ;
}
array [ n ] . bv_page = buf - > page ;
array [ n ] . bv_len = this_len ;
array [ n ] . bv_offset = buf - > offset ;
left - = this_len ;
2021-01-09 19:02:57 +03:00
n + + ;
2014-04-05 12:27:08 +04:00
}
2018-10-20 02:57:56 +03:00
iov_iter_bvec ( & from , WRITE , array , n , sd . total_len - left ) ;
2017-05-27 11:16:52 +03:00
ret = vfs_iter_write ( out , & from , & sd . pos , 0 ) ;
2014-04-05 12:27:08 +04:00
if ( ret < = 0 )
break ;
sd . num_spliced + = ret ;
sd . total_len - = ret ;
2015-01-25 23:11:59 +03:00
* ppos = sd . pos ;
2014-04-05 12:27:08 +04:00
/* dismiss the fully eaten buffers, adjust the partial one */
2019-11-15 16:30:32 +03:00
tail = pipe - > tail ;
2014-04-05 12:27:08 +04:00
while ( ret ) {
2019-11-15 16:30:32 +03:00
struct pipe_buffer * buf = & pipe - > bufs [ tail & mask ] ;
2014-04-05 12:27:08 +04:00
if ( ret > = buf - > len ) {
ret - = buf - > len ;
buf - > len = 0 ;
2016-09-27 11:45:12 +03:00
pipe_buf_release ( pipe , buf ) ;
2019-11-15 16:30:32 +03:00
tail + + ;
pipe - > tail = tail ;
2014-04-05 12:27:08 +04:00
if ( pipe - > files )
sd . need_wakeup = true ;
} else {
buf - > offset + = ret ;
buf - > len - = ret ;
ret = 0 ;
}
}
}
done :
kfree ( array ) ;
splice_from_pipe_end ( pipe , & sd ) ;
pipe_unlock ( pipe ) ;
if ( sd . num_spliced )
ret = sd . num_spliced ;
return ret ;
}
EXPORT_SYMBOL ( iter_file_splice_write ) ;
2006-04-03 01:05:09 +04:00
/**
* generic_splice_sendpage - splice data from a pipe to a socket
2007-06-21 15:10:21 +04:00
* @ pipe : pipe to splice from
2006-04-03 01:05:09 +04:00
* @ out : socket to write to
2007-06-21 15:10:21 +04:00
* @ ppos : position in @ out
2006-04-03 01:05:09 +04:00
* @ len : number of bytes to splice
* @ flags : splice modifier flags
*
2007-06-21 15:10:21 +04:00
* Description :
* Will send @ len bytes from the pipe to a network socket . No data copying
* is involved .
2006-04-03 01:05:09 +04:00
*
*/
2006-04-10 17:18:35 +04:00
ssize_t generic_splice_sendpage ( struct pipe_inode_info * pipe , struct file * out ,
2006-04-11 16:57:50 +04:00
loff_t * ppos , size_t len , unsigned int flags )
2006-03-30 17:15:30 +04:00
{
2006-04-26 16:39:29 +04:00
return splice_from_pipe ( pipe , out , ppos , len , flags , pipe_to_sendpage ) ;
2006-03-30 17:15:30 +04:00
}
2006-04-03 01:06:05 +04:00
EXPORT_SYMBOL ( generic_splice_sendpage ) ;
2006-03-31 08:06:13 +04:00
2020-09-03 17:22:34 +03:00
static int warn_unsupported ( struct file * file , const char * op )
{
pr_debug_ratelimited (
" splice %s not supported for file %pD4 (pid: %d comm: %.20s) \n " ,
op , file , current - > pid , current - > comm ) ;
return - EINVAL ;
}
2006-04-03 01:05:09 +04:00
/*
* Attempt to initiate a splice from pipe to file .
*/
2006-04-10 17:18:35 +04:00
static long do_splice_from ( struct pipe_inode_info * pipe , struct file * out ,
2006-04-11 16:57:50 +04:00
loff_t * ppos , size_t len , unsigned int flags )
2006-03-30 17:15:30 +04:00
{
2020-09-03 17:22:34 +03:00
if ( unlikely ( ! out - > f_op - > splice_write ) )
return warn_unsupported ( out , " write " ) ;
return out - > f_op - > splice_write ( pipe , out , ppos , len , flags ) ;
2006-03-30 17:15:30 +04:00
}
2006-04-03 01:05:09 +04:00
/*
* Attempt to initiate a splice from a file to a pipe .
*/
2006-04-11 16:57:50 +04:00
static long do_splice_to ( struct file * in , loff_t * ppos ,
struct pipe_inode_info * pipe , size_t len ,
unsigned int flags )
2006-03-30 17:15:30 +04:00
{
2021-01-25 07:49:04 +03:00
unsigned int p_space ;
2006-03-30 17:15:30 +04:00
int ret ;
2006-04-11 15:56:09 +04:00
if ( unlikely ( ! ( in - > f_mode & FMODE_READ ) ) )
2006-03-30 17:15:30 +04:00
return - EBADF ;
2021-01-25 07:49:04 +03:00
/* Don't try to read more the pipe has space for. */
p_space = pipe - > max_usage - pipe_occupancy ( pipe - > head , pipe - > tail ) ;
len = min_t ( size_t , len , p_space < < PAGE_SHIFT ) ;
2006-04-11 16:57:50 +04:00
ret = rw_verify_area ( READ , in , ppos , len ) ;
2006-03-30 17:15:30 +04:00
if ( unlikely ( ret < 0 ) )
return ret ;
2016-04-02 21:56:58 +03:00
if ( unlikely ( len > MAX_RW_COUNT ) )
len = MAX_RW_COUNT ;
2020-09-03 17:22:34 +03:00
if ( unlikely ( ! in - > f_op - > splice_read ) )
return warn_unsupported ( in , " read " ) ;
return in - > f_op - > splice_read ( in , ppos , pipe , len , flags ) ;
2006-03-30 17:15:30 +04:00
}
2007-06-21 15:10:21 +04:00
/**
* splice_direct_to_actor - splices data directly between two non - pipes
* @ in : file to splice from
* @ sd : actor information on where to splice to
* @ actor : handles the data splicing
*
* Description :
* This is a special case helper to splice directly between two
* points , without requiring an explicit pipe . Internally an allocated
2007-07-27 10:08:51 +04:00
* pipe is cached in the process , and reused during the lifetime of
2007-06-21 15:10:21 +04:00
* that process .
*
2007-06-12 23:17:17 +04:00
*/
ssize_t splice_direct_to_actor ( struct file * in , struct splice_desc * sd ,
splice_direct_actor * actor )
2006-04-11 15:52:07 +04:00
{
struct pipe_inode_info * pipe ;
long ret , bytes ;
umode_t i_mode ;
2007-06-12 23:17:17 +04:00
size_t len ;
splice: sendfile() at once fails for big files
Using sendfile with below small program to get MD5 sums of some files,
it appear that big files (over 64kbytes with 4k pages system) get a
wrong MD5 sum while small files get the correct sum.
This program uses sendfile() to send a file to an AF_ALG socket
for hashing.
/* md5sum2.c */
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <string.h>
#include <fcntl.h>
#include <sys/socket.h>
#include <sys/stat.h>
#include <sys/types.h>
#include <linux/if_alg.h>
int main(int argc, char **argv)
{
int sk = socket(AF_ALG, SOCK_SEQPACKET, 0);
struct stat st;
struct sockaddr_alg sa = {
.salg_family = AF_ALG,
.salg_type = "hash",
.salg_name = "md5",
};
int n;
bind(sk, (struct sockaddr*)&sa, sizeof(sa));
for (n = 1; n < argc; n++) {
int size;
int offset = 0;
char buf[4096];
int fd;
int sko;
int i;
fd = open(argv[n], O_RDONLY);
sko = accept(sk, NULL, 0);
fstat(fd, &st);
size = st.st_size;
sendfile(sko, fd, &offset, size);
size = read(sko, buf, sizeof(buf));
for (i = 0; i < size; i++)
printf("%2.2x", buf[i]);
printf(" %s\n", argv[n]);
close(fd);
close(sko);
}
exit(0);
}
Test below is done using official linux patch files. First result is
with a software based md5sum. Second result is with the program above.
root@vgoip:~# ls -l patch-3.6.*
-rw-r--r-- 1 root root 64011 Aug 24 12:01 patch-3.6.2.gz
-rw-r--r-- 1 root root 94131 Aug 24 12:01 patch-3.6.3.gz
root@vgoip:~# md5sum patch-3.6.*
b3ffb9848196846f31b2ff133d2d6443 patch-3.6.2.gz
c5e8f687878457db77cb7158c38a7e43 patch-3.6.3.gz
root@vgoip:~# ./md5sum2 patch-3.6.*
b3ffb9848196846f31b2ff133d2d6443 patch-3.6.2.gz
5fd77b24e68bb24dcc72d6e57c64790e patch-3.6.3.gz
After investivation, it appears that sendfile() sends the files by blocks
of 64kbytes (16 times PAGE_SIZE). The problem is that at the end of each
block, the SPLICE_F_MORE flag is missing, therefore the hashing operation
is reset as if it was the end of the file.
This patch adds SPLICE_F_MORE to the flags when more data is pending.
With the patch applied, we get the correct sums:
root@vgoip:~# md5sum patch-3.6.*
b3ffb9848196846f31b2ff133d2d6443 patch-3.6.2.gz
c5e8f687878457db77cb7158c38a7e43 patch-3.6.3.gz
root@vgoip:~# ./md5sum2 patch-3.6.*
b3ffb9848196846f31b2ff133d2d6443 patch-3.6.2.gz
c5e8f687878457db77cb7158c38a7e43 patch-3.6.3.gz
Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
Signed-off-by: Jens Axboe <axboe@fb.com>
2015-05-06 18:26:47 +03:00
int i , flags , more ;
2006-04-11 15:52:07 +04:00
/*
* We require the input being a regular file , as we don ' t want to
* randomly drop data for eg socket - > socket splicing . Use the
* piped splicing for that !
*/
2013-01-24 02:07:38 +04:00
i_mode = file_inode ( in ) - > i_mode ;
2006-04-11 15:52:07 +04:00
if ( unlikely ( ! S_ISREG ( i_mode ) & & ! S_ISBLK ( i_mode ) ) )
return - EINVAL ;
/*
* neither in nor out is a pipe , setup an internal pipe attached to
* ' out ' and transfer the wanted data from ' in ' to ' out ' through that
*/
pipe = current - > splice_pipe ;
2006-04-11 15:56:09 +04:00
if ( unlikely ( ! pipe ) ) {
2013-03-21 19:04:15 +04:00
pipe = alloc_pipe_info ( ) ;
2006-04-11 15:52:07 +04:00
if ( ! pipe )
return - ENOMEM ;
/*
* We don ' t have an immediate reader , but we ' ll read the stuff
2006-04-26 16:39:29 +04:00
* out of the pipe right after the splice_to_pipe ( ) . So set
2006-04-11 15:52:07 +04:00
* PIPE_READERS appropriately .
*/
pipe - > readers = 1 ;
current - > splice_pipe = pipe ;
}
/*
2006-04-11 15:57:21 +04:00
* Do the splice .
2006-04-11 15:52:07 +04:00
*/
ret = 0 ;
bytes = 0 ;
2007-06-12 23:17:17 +04:00
len = sd - > total_len ;
flags = sd - > flags ;
/*
* Don ' t block on output , we have to drain the direct pipe .
*/
sd - > flags & = ~ SPLICE_F_NONBLOCK ;
splice: sendfile() at once fails for big files
Using sendfile with below small program to get MD5 sums of some files,
it appear that big files (over 64kbytes with 4k pages system) get a
wrong MD5 sum while small files get the correct sum.
This program uses sendfile() to send a file to an AF_ALG socket
for hashing.
/* md5sum2.c */
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <string.h>
#include <fcntl.h>
#include <sys/socket.h>
#include <sys/stat.h>
#include <sys/types.h>
#include <linux/if_alg.h>
int main(int argc, char **argv)
{
int sk = socket(AF_ALG, SOCK_SEQPACKET, 0);
struct stat st;
struct sockaddr_alg sa = {
.salg_family = AF_ALG,
.salg_type = "hash",
.salg_name = "md5",
};
int n;
bind(sk, (struct sockaddr*)&sa, sizeof(sa));
for (n = 1; n < argc; n++) {
int size;
int offset = 0;
char buf[4096];
int fd;
int sko;
int i;
fd = open(argv[n], O_RDONLY);
sko = accept(sk, NULL, 0);
fstat(fd, &st);
size = st.st_size;
sendfile(sko, fd, &offset, size);
size = read(sko, buf, sizeof(buf));
for (i = 0; i < size; i++)
printf("%2.2x", buf[i]);
printf(" %s\n", argv[n]);
close(fd);
close(sko);
}
exit(0);
}
Test below is done using official linux patch files. First result is
with a software based md5sum. Second result is with the program above.
root@vgoip:~# ls -l patch-3.6.*
-rw-r--r-- 1 root root 64011 Aug 24 12:01 patch-3.6.2.gz
-rw-r--r-- 1 root root 94131 Aug 24 12:01 patch-3.6.3.gz
root@vgoip:~# md5sum patch-3.6.*
b3ffb9848196846f31b2ff133d2d6443 patch-3.6.2.gz
c5e8f687878457db77cb7158c38a7e43 patch-3.6.3.gz
root@vgoip:~# ./md5sum2 patch-3.6.*
b3ffb9848196846f31b2ff133d2d6443 patch-3.6.2.gz
5fd77b24e68bb24dcc72d6e57c64790e patch-3.6.3.gz
After investivation, it appears that sendfile() sends the files by blocks
of 64kbytes (16 times PAGE_SIZE). The problem is that at the end of each
block, the SPLICE_F_MORE flag is missing, therefore the hashing operation
is reset as if it was the end of the file.
This patch adds SPLICE_F_MORE to the flags when more data is pending.
With the patch applied, we get the correct sums:
root@vgoip:~# md5sum patch-3.6.*
b3ffb9848196846f31b2ff133d2d6443 patch-3.6.2.gz
c5e8f687878457db77cb7158c38a7e43 patch-3.6.3.gz
root@vgoip:~# ./md5sum2 patch-3.6.*
b3ffb9848196846f31b2ff133d2d6443 patch-3.6.2.gz
c5e8f687878457db77cb7158c38a7e43 patch-3.6.3.gz
Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
Signed-off-by: Jens Axboe <axboe@fb.com>
2015-05-06 18:26:47 +03:00
more = sd - > flags & SPLICE_F_MORE ;
2006-04-11 15:52:07 +04:00
2019-11-15 16:30:32 +03:00
WARN_ON_ONCE ( ! pipe_empty ( pipe - > head , pipe - > tail ) ) ;
2018-11-30 21:37:49 +03:00
2006-04-11 15:52:07 +04:00
while ( len ) {
2007-07-13 16:11:43 +04:00
size_t read_len ;
2008-05-09 15:28:36 +04:00
loff_t pos = sd - > pos , prev_pos = pos ;
2006-04-11 15:52:07 +04:00
2021-01-25 07:49:04 +03:00
ret = do_splice_to ( in , & pos , pipe , len , flags ) ;
2007-07-13 16:11:43 +04:00
if ( unlikely ( ret < = 0 ) )
2006-04-11 15:52:07 +04:00
goto out_release ;
read_len = ret ;
2007-06-12 23:17:17 +04:00
sd - > total_len = read_len ;
2006-04-11 15:52:07 +04:00
splice: sendfile() at once fails for big files
Using sendfile with below small program to get MD5 sums of some files,
it appear that big files (over 64kbytes with 4k pages system) get a
wrong MD5 sum while small files get the correct sum.
This program uses sendfile() to send a file to an AF_ALG socket
for hashing.
/* md5sum2.c */
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <string.h>
#include <fcntl.h>
#include <sys/socket.h>
#include <sys/stat.h>
#include <sys/types.h>
#include <linux/if_alg.h>
int main(int argc, char **argv)
{
int sk = socket(AF_ALG, SOCK_SEQPACKET, 0);
struct stat st;
struct sockaddr_alg sa = {
.salg_family = AF_ALG,
.salg_type = "hash",
.salg_name = "md5",
};
int n;
bind(sk, (struct sockaddr*)&sa, sizeof(sa));
for (n = 1; n < argc; n++) {
int size;
int offset = 0;
char buf[4096];
int fd;
int sko;
int i;
fd = open(argv[n], O_RDONLY);
sko = accept(sk, NULL, 0);
fstat(fd, &st);
size = st.st_size;
sendfile(sko, fd, &offset, size);
size = read(sko, buf, sizeof(buf));
for (i = 0; i < size; i++)
printf("%2.2x", buf[i]);
printf(" %s\n", argv[n]);
close(fd);
close(sko);
}
exit(0);
}
Test below is done using official linux patch files. First result is
with a software based md5sum. Second result is with the program above.
root@vgoip:~# ls -l patch-3.6.*
-rw-r--r-- 1 root root 64011 Aug 24 12:01 patch-3.6.2.gz
-rw-r--r-- 1 root root 94131 Aug 24 12:01 patch-3.6.3.gz
root@vgoip:~# md5sum patch-3.6.*
b3ffb9848196846f31b2ff133d2d6443 patch-3.6.2.gz
c5e8f687878457db77cb7158c38a7e43 patch-3.6.3.gz
root@vgoip:~# ./md5sum2 patch-3.6.*
b3ffb9848196846f31b2ff133d2d6443 patch-3.6.2.gz
5fd77b24e68bb24dcc72d6e57c64790e patch-3.6.3.gz
After investivation, it appears that sendfile() sends the files by blocks
of 64kbytes (16 times PAGE_SIZE). The problem is that at the end of each
block, the SPLICE_F_MORE flag is missing, therefore the hashing operation
is reset as if it was the end of the file.
This patch adds SPLICE_F_MORE to the flags when more data is pending.
With the patch applied, we get the correct sums:
root@vgoip:~# md5sum patch-3.6.*
b3ffb9848196846f31b2ff133d2d6443 patch-3.6.2.gz
c5e8f687878457db77cb7158c38a7e43 patch-3.6.3.gz
root@vgoip:~# ./md5sum2 patch-3.6.*
b3ffb9848196846f31b2ff133d2d6443 patch-3.6.2.gz
c5e8f687878457db77cb7158c38a7e43 patch-3.6.3.gz
Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
Signed-off-by: Jens Axboe <axboe@fb.com>
2015-05-06 18:26:47 +03:00
/*
* If more data is pending , set SPLICE_F_MORE
* If this is the last data and SPLICE_F_MORE was not set
* initially , clears it .
*/
if ( read_len < len )
sd - > flags | = SPLICE_F_MORE ;
else if ( ! more )
sd - > flags & = ~ SPLICE_F_MORE ;
2006-04-11 15:52:07 +04:00
/*
* NOTE : nonblocking mode only applies to the input . We
* must not do the output in nonblocking mode as then we
* could get stuck data in the internal pipe :
*/
2007-06-12 23:17:17 +04:00
ret = actor ( pipe , sd ) ;
2008-05-09 15:28:36 +04:00
if ( unlikely ( ret < = 0 ) ) {
sd - > pos = prev_pos ;
2006-04-11 15:52:07 +04:00
goto out_release ;
2008-05-09 15:28:36 +04:00
}
2006-04-11 15:52:07 +04:00
bytes + = ret ;
len - = ret ;
2007-07-16 16:41:49 +04:00
sd - > pos = pos ;
2006-04-11 15:52:07 +04:00
2008-05-09 15:28:36 +04:00
if ( ret < read_len ) {
sd - > pos = prev_pos + ret ;
2007-07-13 16:11:43 +04:00
goto out_release ;
2008-05-09 15:28:36 +04:00
}
2006-04-11 15:52:07 +04:00
}
2008-01-29 23:05:57 +03:00
done :
2019-11-15 16:30:32 +03:00
pipe - > tail = pipe - > head = 0 ;
2008-01-30 14:24:48 +03:00
file_accessed ( in ) ;
2006-04-11 15:52:07 +04:00
return bytes ;
out_release :
/*
* If we did an incomplete transfer we must release
* the pipe buffers in question :
*/
2019-11-15 16:30:32 +03:00
for ( i = 0 ; i < pipe - > ring_size ; i + + ) {
struct pipe_buffer * buf = & pipe - > bufs [ i ] ;
2006-04-11 15:52:07 +04:00
2016-09-27 11:45:12 +03:00
if ( buf - > ops )
pipe_buf_release ( pipe , buf ) ;
2006-04-11 15:52:07 +04:00
}
2008-01-29 23:05:57 +03:00
if ( ! bytes )
bytes = ret ;
2007-06-12 23:17:17 +04:00
2008-01-29 23:05:57 +03:00
goto done ;
2007-06-12 23:17:17 +04:00
}
EXPORT_SYMBOL ( splice_direct_to_actor ) ;
static int direct_splice_actor ( struct pipe_inode_info * pipe ,
struct splice_desc * sd )
{
2007-06-14 15:08:55 +04:00
struct file * file = sd - > u . file ;
2007-06-12 23:17:17 +04:00
2013-06-20 18:58:36 +04:00
return do_splice_from ( pipe , file , sd - > opos , sd - > total_len ,
2010-06-29 15:09:18 +04:00
sd - > flags ) ;
2007-06-12 23:17:17 +04:00
}
2007-06-21 15:10:21 +04:00
/**
* do_splice_direct - splices data directly between two files
* @ in : file to splice from
* @ ppos : input file offset
* @ out : file to splice to
2013-06-23 06:44:08 +04:00
* @ opos : output file offset
2007-06-21 15:10:21 +04:00
* @ len : number of bytes to splice
* @ flags : splice modifier flags
*
* Description :
* For use by do_sendfile ( ) . splice can easily emulate sendfile , but
* doing it in the application would incur an extra system call
* ( splice in + splice out , as compared to just sendfile ( ) ) . So this helper
* can splice directly through a process - private pipe .
*
*/
2007-06-12 23:17:17 +04:00
long do_splice_direct ( struct file * in , loff_t * ppos , struct file * out ,
2013-06-20 18:58:36 +04:00
loff_t * opos , size_t len , unsigned int flags )
2007-06-12 23:17:17 +04:00
{
struct splice_desc sd = {
. len = len ,
. total_len = len ,
. flags = flags ,
. pos = * ppos ,
2007-06-14 15:08:55 +04:00
. u . file = out ,
2013-06-20 18:58:36 +04:00
. opos = opos ,
2007-06-12 23:17:17 +04:00
} ;
2007-07-13 16:11:43 +04:00
long ret ;
2007-06-12 23:17:17 +04:00
2013-06-19 15:41:54 +04:00
if ( unlikely ( ! ( out - > f_mode & FMODE_WRITE ) ) )
return - EBADF ;
if ( unlikely ( out - > f_flags & O_APPEND ) )
return - EINVAL ;
ret = rw_verify_area ( WRITE , out , opos , len ) ;
if ( unlikely ( ret < 0 ) )
return ret ;
2007-06-12 23:17:17 +04:00
ret = splice_direct_to_actor ( in , & sd , direct_splice_actor ) ;
2007-07-13 16:11:43 +04:00
if ( ret > 0 )
2008-05-09 15:28:36 +04:00
* ppos = sd . pos ;
2007-07-13 16:11:43 +04:00
2007-06-12 23:17:17 +04:00
return ret ;
2006-04-11 15:52:07 +04:00
}
2014-10-24 02:14:35 +04:00
EXPORT_SYMBOL ( do_splice_direct ) ;
2006-04-11 15:52:07 +04:00
2016-09-18 03:44:45 +03:00
static int wait_for_space ( struct pipe_inode_info * pipe , unsigned flags )
{
2016-12-21 21:59:34 +03:00
for ( ; ; ) {
if ( unlikely ( ! pipe - > readers ) ) {
send_sig ( SIGPIPE , current , 0 ) ;
return - EPIPE ;
}
2019-10-16 18:47:32 +03:00
if ( ! pipe_full ( pipe - > head , pipe - > tail , pipe - > max_usage ) )
2016-12-21 21:59:34 +03:00
return 0 ;
2016-09-18 03:44:45 +03:00
if ( flags & SPLICE_F_NONBLOCK )
return - EAGAIN ;
if ( signal_pending ( current ) )
return - ERESTARTSYS ;
pipe: remove pipe_wait() and fix wakeup race with splice
The pipe splice code still used the old model of waiting for pipe IO by
using a non-specific "pipe_wait()" that waited for any pipe event to
happen, which depended on all pipe IO being entirely serialized by the
pipe lock. So by checking the state you were waiting for, and then
adding yourself to the wait queue before dropping the lock, you were
guaranteed to see all the wakeups.
Strictly speaking, the actual wakeups were not done under the lock, but
the pipe_wait() model still worked, because since the waiter held the
lock when checking whether it should sleep, it would always see the
current state, and the wakeup was always done after updating the state.
However, commit 0ddad21d3e99 ("pipe: use exclusive waits when reading or
writing") split the single wait-queue into two, and in the process also
made the "wait for event" code wait for _two_ wait queues, and that then
showed a race with the wakers that were not serialized by the pipe lock.
It's only splice that used that "pipe_wait()" model, so the problem
wasn't obvious, but Josef Bacik reports:
"I hit a hang with fstest btrfs/187, which does a btrfs send into
/dev/null. This works by creating a pipe, the write side is given to
the kernel to write into, and the read side is handed to a thread that
splices into a file, in this case /dev/null.
The box that was hung had the write side stuck here [pipe_write] and
the read side stuck here [splice_from_pipe_next -> pipe_wait].
[ more details about pipe_wait() scenario ]
The problem is we're doing the prepare_to_wait, which sets our state
each time, however we can be woken up either with reads or writes. In
the case above we race with the WRITER waking us up, and re-set our
state to INTERRUPTIBLE, and thus never break out of schedule"
Josef had a patch that avoided the issue in pipe_wait() by just making
it set the state only once, but the deeper problem is that pipe_wait()
depends on a level of synchonization by the pipe mutex that it really
shouldn't. And the whole "wait for any pipe state change" model really
isn't very good to begin with.
So rather than trying to work around things in pipe_wait(), remove that
legacy model of "wait for arbitrary pipe event" entirely, and actually
create functions that wait for the pipe actually being readable or
writable, and can do so without depending on the pipe lock serializing
everything.
Fixes: 0ddad21d3e99 ("pipe: use exclusive waits when reading or writing")
Link: https://lore.kernel.org/linux-fsdevel/bfa88b5ad6f069b2b679316b9e495a970130416c.1601567868.git.josef@toxicpanda.com/
Reported-by: Josef Bacik <josef@toxicpanda.com>
Reviewed-and-tested-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2020-10-02 05:14:36 +03:00
pipe_wait_writable ( pipe ) ;
2016-09-18 03:44:45 +03:00
}
}
splice: implement pipe to pipe splicing
Allow splice(2) to work when both the input and the output is a pipe.
Based on the impementation of the tee(2) syscall, but instead of
duplicating the buffer references move the buffers from the input pipe
to the output pipe.
Moving the whole buffer only succeeds if the full length of the buffer
is spliced. Otherwise duplicate the buffer, just like tee(2), set the
length of the output buffer and advance the offset on the input
buffer.
Since splice is operating on two pipes, special care needs to be taken
with locking to prevent AN ABBA deadlock. Again this is done
similarly to the tee(2) syscall, first preparing the input and output
pipes so there's data to consume and space for that data, and then
doing the move operation while holding both locks.
If other processes are doing I/O on the same pipes parallel to the
splice, then by the time both inodes are locked there might be no
buffers left to move, or no space to move them to. In this case retry
the whole operation, including the preparation phase. This could lead
to starvation, but I'm not sure if that's serious enough to worry
about.
Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
2009-05-07 17:37:35 +04:00
static int splice_pipe_to_pipe ( struct pipe_inode_info * ipipe ,
struct pipe_inode_info * opipe ,
size_t len , unsigned int flags ) ;
2006-11-04 14:49:32 +03:00
2021-01-26 06:24:28 +03:00
long splice_file_to_pipe ( struct file * in ,
2021-01-26 06:23:03 +03:00
struct pipe_inode_info * opipe ,
loff_t * offset ,
size_t len , unsigned int flags )
{
long ret ;
pipe_lock ( opipe ) ;
ret = wait_for_space ( opipe , flags ) ;
if ( ! ret )
ret = do_splice_to ( in , offset , opipe , len , flags ) ;
pipe_unlock ( opipe ) ;
if ( ret > 0 )
wakeup_pipe_readers ( opipe ) ;
return ret ;
}
2006-04-03 01:05:09 +04:00
/*
* Determine where to splice to / from .
*/
2020-10-22 23:15:51 +03:00
long do_splice ( struct file * in , loff_t * off_in , struct file * out ,
loff_t * off_out , size_t len , unsigned int flags )
2006-03-30 17:15:30 +04:00
{
splice: implement pipe to pipe splicing
Allow splice(2) to work when both the input and the output is a pipe.
Based on the impementation of the tee(2) syscall, but instead of
duplicating the buffer references move the buffers from the input pipe
to the output pipe.
Moving the whole buffer only succeeds if the full length of the buffer
is spliced. Otherwise duplicate the buffer, just like tee(2), set the
length of the output buffer and advance the offset on the input
buffer.
Since splice is operating on two pipes, special care needs to be taken
with locking to prevent AN ABBA deadlock. Again this is done
similarly to the tee(2) syscall, first preparing the input and output
pipes so there's data to consume and space for that data, and then
doing the move operation while holding both locks.
If other processes are doing I/O on the same pipes parallel to the
splice, then by the time both inodes are locked there might be no
buffers left to move, or no space to move them to. In this case retry
the whole operation, including the preparation phase. This could lead
to starvation, but I'm not sure if that's serious enough to worry
about.
Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
2009-05-07 17:37:35 +04:00
struct pipe_inode_info * ipipe ;
struct pipe_inode_info * opipe ;
2013-06-20 18:58:36 +04:00
loff_t offset ;
2006-04-19 17:57:05 +04:00
long ret ;
2006-03-30 17:15:30 +04:00
2020-05-04 22:39:35 +03:00
if ( unlikely ( ! ( in - > f_mode & FMODE_READ ) | |
! ( out - > f_mode & FMODE_WRITE ) ) )
return - EBADF ;
pipe: Add general notification queue support
Make it possible to have a general notification queue built on top of a
standard pipe. Notifications are 'spliced' into the pipe and then read
out. splice(), vmsplice() and sendfile() are forbidden on pipes used for
notifications as post_one_notification() cannot take pipe->mutex. This
means that notifications could be posted in between individual pipe
buffers, making iov_iter_revert() difficult to effect.
The way the notification queue is used is:
(1) An application opens a pipe with a special flag and indicates the
number of messages it wishes to be able to queue at once (this can
only be set once):
pipe2(fds, O_NOTIFICATION_PIPE);
ioctl(fds[0], IOC_WATCH_QUEUE_SET_SIZE, queue_depth);
(2) The application then uses poll() and read() as normal to extract data
from the pipe. read() will return multiple notifications if the
buffer is big enough, but it will not split a notification across
buffers - rather it will return a short read or EMSGSIZE.
Notification messages include a length in the header so that the
caller can split them up.
Each message has a header that describes it:
struct watch_notification {
__u32 type:24;
__u32 subtype:8;
__u32 info;
};
The type indicates the source (eg. mount tree changes, superblock events,
keyring changes, block layer events) and the subtype indicates the event
type (eg. mount, unmount; EIO, EDQUOT; link, unlink). The info field
indicates a number of things, including the entry length, an ID assigned to
a watchpoint contributing to this buffer and type-specific flags.
Supplementary data, such as the key ID that generated an event, can be
attached in additional slots. The maximum message size is 127 bytes.
Messages may not be padded or aligned, so there is no guarantee, for
example, that the notification type will be on a 4-byte bounary.
Signed-off-by: David Howells <dhowells@redhat.com>
2020-01-14 20:07:11 +03:00
ipipe = get_pipe_info ( in , true ) ;
opipe = get_pipe_info ( out , true ) ;
splice: implement pipe to pipe splicing
Allow splice(2) to work when both the input and the output is a pipe.
Based on the impementation of the tee(2) syscall, but instead of
duplicating the buffer references move the buffers from the input pipe
to the output pipe.
Moving the whole buffer only succeeds if the full length of the buffer
is spliced. Otherwise duplicate the buffer, just like tee(2), set the
length of the output buffer and advance the offset on the input
buffer.
Since splice is operating on two pipes, special care needs to be taken
with locking to prevent AN ABBA deadlock. Again this is done
similarly to the tee(2) syscall, first preparing the input and output
pipes so there's data to consume and space for that data, and then
doing the move operation while holding both locks.
If other processes are doing I/O on the same pipes parallel to the
splice, then by the time both inodes are locked there might be no
buffers left to move, or no space to move them to. In this case retry
the whole operation, including the preparation phase. This could lead
to starvation, but I'm not sure if that's serious enough to worry
about.
Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
2009-05-07 17:37:35 +04:00
if ( ipipe & & opipe ) {
if ( off_in | | off_out )
return - ESPIPE ;
/* Splicing to self would be fun, but... */
if ( ipipe = = opipe )
return - EINVAL ;
2019-02-07 18:45:19 +03:00
if ( ( in - > f_flags | out - > f_flags ) & O_NONBLOCK )
flags | = SPLICE_F_NONBLOCK ;
splice: implement pipe to pipe splicing
Allow splice(2) to work when both the input and the output is a pipe.
Based on the impementation of the tee(2) syscall, but instead of
duplicating the buffer references move the buffers from the input pipe
to the output pipe.
Moving the whole buffer only succeeds if the full length of the buffer
is spliced. Otherwise duplicate the buffer, just like tee(2), set the
length of the output buffer and advance the offset on the input
buffer.
Since splice is operating on two pipes, special care needs to be taken
with locking to prevent AN ABBA deadlock. Again this is done
similarly to the tee(2) syscall, first preparing the input and output
pipes so there's data to consume and space for that data, and then
doing the move operation while holding both locks.
If other processes are doing I/O on the same pipes parallel to the
splice, then by the time both inodes are locked there might be no
buffers left to move, or no space to move them to. In this case retry
the whole operation, including the preparation phase. This could lead
to starvation, but I'm not sure if that's serious enough to worry
about.
Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
2009-05-07 17:37:35 +04:00
return splice_pipe_to_pipe ( ipipe , opipe , len , flags ) ;
}
if ( ipipe ) {
2006-04-10 17:18:58 +04:00
if ( off_in )
return - ESPIPE ;
2006-04-11 15:52:07 +04:00
if ( off_out ) {
2010-06-29 15:10:36 +04:00
if ( ! ( out - > f_mode & FMODE_PWRITE ) )
2006-04-11 15:52:07 +04:00
return - EINVAL ;
2020-10-22 23:15:51 +03:00
offset = * off_out ;
2013-06-20 18:58:36 +04:00
} else {
offset = out - > f_pos ;
}
2006-04-10 17:18:58 +04:00
2013-06-19 15:41:54 +04:00
if ( unlikely ( out - > f_flags & O_APPEND ) )
return - EINVAL ;
ret = rw_verify_area ( WRITE , out , & offset , len ) ;
if ( unlikely ( ret < 0 ) )
return ret ;
2019-02-07 18:45:19 +03:00
if ( in - > f_flags & O_NONBLOCK )
flags | = SPLICE_F_NONBLOCK ;
2013-05-24 04:07:11 +04:00
file_start_write ( out ) ;
2013-06-20 18:58:36 +04:00
ret = do_splice_from ( ipipe , out , & offset , len , flags ) ;
2013-05-24 04:07:11 +04:00
file_end_write ( out ) ;
2006-04-19 17:57:05 +04:00
2013-06-20 18:58:36 +04:00
if ( ! off_out )
out - > f_pos = offset ;
2020-10-22 23:15:51 +03:00
else
* off_out = offset ;
2006-04-19 17:57:05 +04:00
return ret ;
2006-04-10 17:18:58 +04:00
}
2006-03-30 17:15:30 +04:00
splice: implement pipe to pipe splicing
Allow splice(2) to work when both the input and the output is a pipe.
Based on the impementation of the tee(2) syscall, but instead of
duplicating the buffer references move the buffers from the input pipe
to the output pipe.
Moving the whole buffer only succeeds if the full length of the buffer
is spliced. Otherwise duplicate the buffer, just like tee(2), set the
length of the output buffer and advance the offset on the input
buffer.
Since splice is operating on two pipes, special care needs to be taken
with locking to prevent AN ABBA deadlock. Again this is done
similarly to the tee(2) syscall, first preparing the input and output
pipes so there's data to consume and space for that data, and then
doing the move operation while holding both locks.
If other processes are doing I/O on the same pipes parallel to the
splice, then by the time both inodes are locked there might be no
buffers left to move, or no space to move them to. In this case retry
the whole operation, including the preparation phase. This could lead
to starvation, but I'm not sure if that's serious enough to worry
about.
Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
2009-05-07 17:37:35 +04:00
if ( opipe ) {
2006-04-10 17:18:58 +04:00
if ( off_out )
return - ESPIPE ;
2006-04-11 15:52:07 +04:00
if ( off_in ) {
2010-06-29 15:10:36 +04:00
if ( ! ( in - > f_mode & FMODE_PREAD ) )
2006-04-11 15:52:07 +04:00
return - EINVAL ;
2020-10-22 23:15:51 +03:00
offset = * off_in ;
2013-06-20 18:58:36 +04:00
} else {
offset = in - > f_pos ;
}
2006-04-10 17:18:58 +04:00
2019-02-07 18:45:19 +03:00
if ( out - > f_flags & O_NONBLOCK )
flags | = SPLICE_F_NONBLOCK ;
2021-01-26 06:23:03 +03:00
ret = splice_file_to_pipe ( in , opipe , & offset , len , flags ) ;
2013-06-20 18:58:36 +04:00
if ( ! off_in )
in - > f_pos = offset ;
2020-10-22 23:15:51 +03:00
else
* off_in = offset ;
2006-04-19 17:57:05 +04:00
return ret ;
2006-04-10 17:18:58 +04:00
}
2006-03-30 17:15:30 +04:00
return - EINVAL ;
}
2020-10-22 23:15:51 +03:00
static long __do_splice ( struct file * in , loff_t __user * off_in ,
struct file * out , loff_t __user * off_out ,
size_t len , unsigned int flags )
{
struct pipe_inode_info * ipipe ;
struct pipe_inode_info * opipe ;
loff_t offset , * __off_in = NULL , * __off_out = NULL ;
long ret ;
ipipe = get_pipe_info ( in , true ) ;
opipe = get_pipe_info ( out , true ) ;
if ( ipipe & & off_in )
return - ESPIPE ;
if ( opipe & & off_out )
return - ESPIPE ;
if ( off_out ) {
if ( copy_from_user ( & offset , off_out , sizeof ( loff_t ) ) )
return - EFAULT ;
__off_out = & offset ;
}
if ( off_in ) {
if ( copy_from_user ( & offset , off_in , sizeof ( loff_t ) ) )
return - EFAULT ;
__off_in = & offset ;
}
ret = do_splice ( in , __off_in , out , __off_out , len , flags ) ;
if ( ret < 0 )
return ret ;
if ( __off_out & & copy_to_user ( off_out , __off_out , sizeof ( loff_t ) ) )
return - EFAULT ;
if ( __off_in & & copy_to_user ( off_in , __off_in , sizeof ( loff_t ) ) )
return - EFAULT ;
return ret ;
}
2016-09-18 05:38:20 +03:00
static int iter_to_pipe ( struct iov_iter * from ,
struct pipe_inode_info * pipe ,
unsigned flags )
2006-04-26 12:59:21 +04:00
{
2016-09-18 05:38:20 +03:00
struct pipe_buffer buf = {
. ops = & user_page_pipe_buf_ops ,
. flags = flags
} ;
size_t total = 0 ;
int ret = 0 ;
bool failed = false ;
while ( iov_iter_count ( from ) & & ! failed ) {
struct page * pages [ 16 ] ;
2016-09-18 03:25:06 +03:00
ssize_t copied ;
size_t start ;
2016-09-18 05:38:20 +03:00
int n ;
2016-09-18 03:25:06 +03:00
2016-09-18 05:38:20 +03:00
copied = iov_iter_get_pages ( from , pages , ~ 0UL , 16 , & start ) ;
if ( copied < = 0 ) {
ret = copied ;
break ;
}
2016-09-18 03:25:06 +03:00
2016-09-18 05:38:20 +03:00
for ( n = 0 ; copied ; n + + , start = 0 ) {
2016-09-18 03:25:06 +03:00
int size = min_t ( int , copied , PAGE_SIZE - start ) ;
2016-09-18 05:38:20 +03:00
if ( ! failed ) {
buf . page = pages [ n ] ;
buf . offset = start ;
buf . len = size ;
ret = add_to_pipe ( pipe , & buf ) ;
if ( unlikely ( ret < 0 ) ) {
failed = true ;
} else {
iov_iter_advance ( from , ret ) ;
total + = ret ;
}
} else {
put_page ( pages [ n ] ) ;
}
2016-09-18 03:25:06 +03:00
copied - = size ;
2006-04-26 12:59:21 +04:00
}
}
2016-09-18 05:38:20 +03:00
return total ? total : ret ;
2006-04-26 12:59:21 +04:00
}
2007-06-14 15:08:55 +04:00
static int pipe_to_user ( struct pipe_inode_info * pipe , struct pipe_buffer * buf ,
struct splice_desc * sd )
{
2014-02-04 03:19:51 +04:00
int n = copy_page_to_iter ( buf - > page , buf - > offset , sd - > len , sd - > u . data ) ;
return n = = sd - > len ? n : - EFAULT ;
2007-06-14 15:08:55 +04:00
}
/*
* For lack of a better implementation , implement vmsplice ( ) to userspace
* as a simple copy of the pipes pages to the user iov .
*/
2018-05-27 04:39:52 +03:00
static long vmsplice_to_user ( struct file * file , struct iov_iter * iter ,
unsigned int flags )
2007-06-14 15:08:55 +04:00
{
pipe: Add general notification queue support
Make it possible to have a general notification queue built on top of a
standard pipe. Notifications are 'spliced' into the pipe and then read
out. splice(), vmsplice() and sendfile() are forbidden on pipes used for
notifications as post_one_notification() cannot take pipe->mutex. This
means that notifications could be posted in between individual pipe
buffers, making iov_iter_revert() difficult to effect.
The way the notification queue is used is:
(1) An application opens a pipe with a special flag and indicates the
number of messages it wishes to be able to queue at once (this can
only be set once):
pipe2(fds, O_NOTIFICATION_PIPE);
ioctl(fds[0], IOC_WATCH_QUEUE_SET_SIZE, queue_depth);
(2) The application then uses poll() and read() as normal to extract data
from the pipe. read() will return multiple notifications if the
buffer is big enough, but it will not split a notification across
buffers - rather it will return a short read or EMSGSIZE.
Notification messages include a length in the header so that the
caller can split them up.
Each message has a header that describes it:
struct watch_notification {
__u32 type:24;
__u32 subtype:8;
__u32 info;
};
The type indicates the source (eg. mount tree changes, superblock events,
keyring changes, block layer events) and the subtype indicates the event
type (eg. mount, unmount; EIO, EDQUOT; link, unlink). The info field
indicates a number of things, including the entry length, an ID assigned to
a watchpoint contributing to this buffer and type-specific flags.
Supplementary data, such as the key ID that generated an event, can be
attached in additional slots. The maximum message size is 127 bytes.
Messages may not be padded or aligned, so there is no guarantee, for
example, that the notification type will be on a 4-byte bounary.
Signed-off-by: David Howells <dhowells@redhat.com>
2020-01-14 20:07:11 +03:00
struct pipe_inode_info * pipe = get_pipe_info ( file , true ) ;
2018-05-27 04:39:52 +03:00
struct splice_desc sd = {
. total_len = iov_iter_count ( iter ) ,
. flags = flags ,
. u . data = iter
} ;
long ret = 0 ;
2007-06-14 15:08:55 +04:00
if ( ! pipe )
return - EBADF ;
2015-03-22 02:17:55 +03:00
if ( sd . total_len ) {
pipe_lock ( pipe ) ;
ret = __splice_from_pipe ( pipe , & sd , pipe_to_user ) ;
pipe_unlock ( pipe ) ;
}
2007-06-14 15:08:55 +04:00
return ret ;
}
2006-04-26 12:59:21 +04:00
/*
* vmsplice splices a user address range into a pipe . It can be thought of
* as splice - from - memory , where the regular splice is splice - from - file ( or
* to file ) . In both cases the output is a pipe , naturally .
*/
2018-05-27 04:39:52 +03:00
static long vmsplice_to_pipe ( struct file * file , struct iov_iter * iter ,
unsigned int flags )
2006-04-26 12:59:21 +04:00
{
2006-11-04 14:49:32 +03:00
struct pipe_inode_info * pipe ;
2018-05-27 04:39:52 +03:00
long ret = 0 ;
2016-09-18 05:38:20 +03:00
unsigned buf_flag = 0 ;
if ( flags & SPLICE_F_GIFT )
buf_flag = PIPE_BUF_FLAG_GIFT ;
2006-04-26 12:59:21 +04:00
pipe: Add general notification queue support
Make it possible to have a general notification queue built on top of a
standard pipe. Notifications are 'spliced' into the pipe and then read
out. splice(), vmsplice() and sendfile() are forbidden on pipes used for
notifications as post_one_notification() cannot take pipe->mutex. This
means that notifications could be posted in between individual pipe
buffers, making iov_iter_revert() difficult to effect.
The way the notification queue is used is:
(1) An application opens a pipe with a special flag and indicates the
number of messages it wishes to be able to queue at once (this can
only be set once):
pipe2(fds, O_NOTIFICATION_PIPE);
ioctl(fds[0], IOC_WATCH_QUEUE_SET_SIZE, queue_depth);
(2) The application then uses poll() and read() as normal to extract data
from the pipe. read() will return multiple notifications if the
buffer is big enough, but it will not split a notification across
buffers - rather it will return a short read or EMSGSIZE.
Notification messages include a length in the header so that the
caller can split them up.
Each message has a header that describes it:
struct watch_notification {
__u32 type:24;
__u32 subtype:8;
__u32 info;
};
The type indicates the source (eg. mount tree changes, superblock events,
keyring changes, block layer events) and the subtype indicates the event
type (eg. mount, unmount; EIO, EDQUOT; link, unlink). The info field
indicates a number of things, including the entry length, an ID assigned to
a watchpoint contributing to this buffer and type-specific flags.
Supplementary data, such as the key ID that generated an event, can be
attached in additional slots. The maximum message size is 127 bytes.
Messages may not be padded or aligned, so there is no guarantee, for
example, that the notification type will be on a 4-byte bounary.
Signed-off-by: David Howells <dhowells@redhat.com>
2020-01-14 20:07:11 +03:00
pipe = get_pipe_info ( file , true ) ;
2006-11-04 14:49:32 +03:00
if ( ! pipe )
2006-04-26 12:59:21 +04:00
return - EBADF ;
2016-09-18 03:44:45 +03:00
pipe_lock ( pipe ) ;
ret = wait_for_space ( pipe , flags ) ;
2016-09-18 05:38:20 +03:00
if ( ! ret )
2018-05-27 04:39:52 +03:00
ret = iter_to_pipe ( iter , pipe , buf_flag ) ;
2016-09-18 03:44:45 +03:00
pipe_unlock ( pipe ) ;
if ( ret > 0 )
wakeup_pipe_readers ( pipe ) ;
2010-05-20 12:43:18 +04:00
return ret ;
2006-04-26 12:59:21 +04:00
}
2018-05-27 04:39:52 +03:00
static int vmsplice_type ( struct fd f , int * type )
{
if ( ! f . file )
return - EBADF ;
if ( f . file - > f_mode & FMODE_WRITE ) {
* type = WRITE ;
} else if ( f . file - > f_mode & FMODE_READ ) {
* type = READ ;
} else {
fdput ( f ) ;
return - EBADF ;
}
return 0 ;
}
2007-06-14 15:08:55 +04:00
/*
* Note that vmsplice only really supports true splicing _from_ user memory
* to a pipe , not the other way around . Splicing from user memory is a simple
* operation that can be supported without any funky alignment restrictions
* or nasty vm tricks . We simply map in the user memory and fill them into
* a pipe . The reverse isn ' t quite as easy , though . There are two possible
* solutions for that :
*
* - memcpy ( ) the data internally , at which point we might as well just
* do a regular read ( ) on the buffer anyway .
* - Lots of nasty vm tricks , that are neither fast nor flexible ( it
* has restriction limitations on both ends of the pipe ) .
*
* Currently we punt and implement it as a normal copy , see pipe_to_user ( ) .
*
*/
2018-05-27 04:39:52 +03:00
SYSCALL_DEFINE4 ( vmsplice , int , fd , const struct iovec __user * , uiov ,
2018-03-17 17:00:24 +03:00
unsigned long , nr_segs , unsigned int , flags )
{
2018-05-27 04:39:52 +03:00
struct iovec iovstack [ UIO_FASTIOV ] ;
struct iovec * iov = iovstack ;
struct iov_iter iter ;
2019-05-15 01:02:22 +03:00
ssize_t error ;
2018-05-27 04:39:52 +03:00
struct fd f ;
int type ;
2020-09-25 07:51:44 +03:00
if ( unlikely ( flags & ~ SPLICE_F_ALL ) )
return - EINVAL ;
2018-05-27 04:39:52 +03:00
f = fdget ( fd ) ;
error = vmsplice_type ( f , & type ) ;
if ( error )
return error ;
error = import_iovec ( type , uiov , nr_segs ,
ARRAY_SIZE ( iovstack ) , & iov , & iter ) ;
2020-09-25 07:51:44 +03:00
if ( error < 0 )
goto out_fdput ;
2018-03-17 17:00:24 +03:00
2020-09-25 07:51:44 +03:00
if ( ! iov_iter_count ( & iter ) )
error = 0 ;
else if ( iov_iter_rw ( & iter ) = = WRITE )
error = vmsplice_to_pipe ( f . file , & iter , flags ) ;
else
error = vmsplice_to_user ( f . file , & iter , flags ) ;
2018-05-27 04:39:52 +03:00
2020-09-25 07:51:44 +03:00
kfree ( iov ) ;
out_fdput :
2018-05-27 04:39:52 +03:00
fdput ( f ) ;
return error ;
2013-03-02 19:19:56 +04:00
}
2009-01-14 16:14:33 +03:00
SYSCALL_DEFINE6 ( splice , int , fd_in , loff_t __user * , off_in ,
int , fd_out , loff_t __user * , off_out ,
size_t , len , unsigned int , flags )
2006-03-30 17:15:30 +04:00
{
2012-08-28 20:52:22 +04:00
struct fd in , out ;
2006-03-30 17:15:30 +04:00
long error ;
if ( unlikely ( ! len ) )
return 0 ;
2016-12-10 21:17:32 +03:00
if ( unlikely ( flags & ~ SPLICE_F_ALL ) )
return - EINVAL ;
2006-03-30 17:15:30 +04:00
error = - EBADF ;
2012-08-28 20:52:22 +04:00
in = fdget ( fd_in ) ;
if ( in . file ) {
2020-05-04 22:39:35 +03:00
out = fdget ( fd_out ) ;
if ( out . file ) {
2020-10-22 23:15:51 +03:00
error = __do_splice ( in . file , off_in , out . file , off_out ,
len , flags ) ;
2020-05-04 22:39:35 +03:00
fdput ( out ) ;
2006-03-30 17:15:30 +04:00
}
2012-08-28 20:52:22 +04:00
fdput ( in ) ;
2006-03-30 17:15:30 +04:00
}
return error ;
}
2006-04-11 17:51:17 +04:00
2006-07-10 13:00:01 +04:00
/*
* Make sure there ' s data to read . Wait for input if we can , otherwise
* return an appropriate error .
*/
splice: implement pipe to pipe splicing
Allow splice(2) to work when both the input and the output is a pipe.
Based on the impementation of the tee(2) syscall, but instead of
duplicating the buffer references move the buffers from the input pipe
to the output pipe.
Moving the whole buffer only succeeds if the full length of the buffer
is spliced. Otherwise duplicate the buffer, just like tee(2), set the
length of the output buffer and advance the offset on the input
buffer.
Since splice is operating on two pipes, special care needs to be taken
with locking to prevent AN ABBA deadlock. Again this is done
similarly to the tee(2) syscall, first preparing the input and output
pipes so there's data to consume and space for that data, and then
doing the move operation while holding both locks.
If other processes are doing I/O on the same pipes parallel to the
splice, then by the time both inodes are locked there might be no
buffers left to move, or no space to move them to. In this case retry
the whole operation, including the preparation phase. This could lead
to starvation, but I'm not sure if that's serious enough to worry
about.
Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
2009-05-07 17:37:35 +04:00
static int ipipe_prep ( struct pipe_inode_info * pipe , unsigned int flags )
2006-07-10 13:00:01 +04:00
{
int ret ;
/*
2019-11-15 16:30:32 +03:00
* Check the pipe occupancy without the inode lock first . This function
2006-07-10 13:00:01 +04:00
* is speculative anyways , so missing one is ok .
*/
2019-11-15 16:30:32 +03:00
if ( ! pipe_empty ( pipe - > head , pipe - > tail ) )
2006-07-10 13:00:01 +04:00
return 0 ;
ret = 0 ;
2009-04-14 21:48:41 +04:00
pipe_lock ( pipe ) ;
2006-07-10 13:00:01 +04:00
2019-11-15 16:30:32 +03:00
while ( pipe_empty ( pipe - > head , pipe - > tail ) ) {
2006-07-10 13:00:01 +04:00
if ( signal_pending ( current ) ) {
ret = - ERESTARTSYS ;
break ;
}
if ( ! pipe - > writers )
break ;
pipe: remove 'waiting_writers' merging logic
This code is ancient, and goes back to when we only had a single page
for the pipe buffers. The exact history is hidden in the mists of time
(ie "before git", and in fact predates the BK repository too).
At that long-ago point in time, it actually helped to try to merge big
back-and-forth pipe reads and writes, and not limit pipe reads to the
single pipe buffer in length just because that was all we had at a time.
However, since then we've expanded the pipe buffers to multiple pages,
and this logic really doesn't seem to make sense. And a lot of it is
somewhat questionable (ie "hmm, the user asked for a non-blocking read,
but we see that there's a writer pending, so let's wait anyway to get
the extra data that the writer will have").
But more importantly, it makes the "go to sleep" logic much less
obvious, and considering the wakeup issues we've had, I want to make for
less of those kinds of things.
Cc: David Howells <dhowells@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2019-12-08 00:21:01 +03:00
if ( flags & SPLICE_F_NONBLOCK ) {
ret = - EAGAIN ;
break ;
2006-07-10 13:00:01 +04:00
}
pipe: remove pipe_wait() and fix wakeup race with splice
The pipe splice code still used the old model of waiting for pipe IO by
using a non-specific "pipe_wait()" that waited for any pipe event to
happen, which depended on all pipe IO being entirely serialized by the
pipe lock. So by checking the state you were waiting for, and then
adding yourself to the wait queue before dropping the lock, you were
guaranteed to see all the wakeups.
Strictly speaking, the actual wakeups were not done under the lock, but
the pipe_wait() model still worked, because since the waiter held the
lock when checking whether it should sleep, it would always see the
current state, and the wakeup was always done after updating the state.
However, commit 0ddad21d3e99 ("pipe: use exclusive waits when reading or
writing") split the single wait-queue into two, and in the process also
made the "wait for event" code wait for _two_ wait queues, and that then
showed a race with the wakers that were not serialized by the pipe lock.
It's only splice that used that "pipe_wait()" model, so the problem
wasn't obvious, but Josef Bacik reports:
"I hit a hang with fstest btrfs/187, which does a btrfs send into
/dev/null. This works by creating a pipe, the write side is given to
the kernel to write into, and the read side is handed to a thread that
splices into a file, in this case /dev/null.
The box that was hung had the write side stuck here [pipe_write] and
the read side stuck here [splice_from_pipe_next -> pipe_wait].
[ more details about pipe_wait() scenario ]
The problem is we're doing the prepare_to_wait, which sets our state
each time, however we can be woken up either with reads or writes. In
the case above we race with the WRITER waking us up, and re-set our
state to INTERRUPTIBLE, and thus never break out of schedule"
Josef had a patch that avoided the issue in pipe_wait() by just making
it set the state only once, but the deeper problem is that pipe_wait()
depends on a level of synchonization by the pipe mutex that it really
shouldn't. And the whole "wait for any pipe state change" model really
isn't very good to begin with.
So rather than trying to work around things in pipe_wait(), remove that
legacy model of "wait for arbitrary pipe event" entirely, and actually
create functions that wait for the pipe actually being readable or
writable, and can do so without depending on the pipe lock serializing
everything.
Fixes: 0ddad21d3e99 ("pipe: use exclusive waits when reading or writing")
Link: https://lore.kernel.org/linux-fsdevel/bfa88b5ad6f069b2b679316b9e495a970130416c.1601567868.git.josef@toxicpanda.com/
Reported-by: Josef Bacik <josef@toxicpanda.com>
Reviewed-and-tested-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2020-10-02 05:14:36 +03:00
pipe_wait_readable ( pipe ) ;
2006-07-10 13:00:01 +04:00
}
2009-04-14 21:48:41 +04:00
pipe_unlock ( pipe ) ;
2006-07-10 13:00:01 +04:00
return ret ;
}
/*
* Make sure there ' s writeable room . Wait for room if we can , otherwise
* return an appropriate error .
*/
splice: implement pipe to pipe splicing
Allow splice(2) to work when both the input and the output is a pipe.
Based on the impementation of the tee(2) syscall, but instead of
duplicating the buffer references move the buffers from the input pipe
to the output pipe.
Moving the whole buffer only succeeds if the full length of the buffer
is spliced. Otherwise duplicate the buffer, just like tee(2), set the
length of the output buffer and advance the offset on the input
buffer.
Since splice is operating on two pipes, special care needs to be taken
with locking to prevent AN ABBA deadlock. Again this is done
similarly to the tee(2) syscall, first preparing the input and output
pipes so there's data to consume and space for that data, and then
doing the move operation while holding both locks.
If other processes are doing I/O on the same pipes parallel to the
splice, then by the time both inodes are locked there might be no
buffers left to move, or no space to move them to. In this case retry
the whole operation, including the preparation phase. This could lead
to starvation, but I'm not sure if that's serious enough to worry
about.
Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
2009-05-07 17:37:35 +04:00
static int opipe_prep ( struct pipe_inode_info * pipe , unsigned int flags )
2006-07-10 13:00:01 +04:00
{
int ret ;
/*
2019-11-15 16:30:32 +03:00
* Check pipe occupancy without the inode lock first . This function
2006-07-10 13:00:01 +04:00
* is speculative anyways , so missing one is ok .
*/
2020-05-20 02:51:59 +03:00
if ( ! pipe_full ( pipe - > head , pipe - > tail , pipe - > max_usage ) )
2006-07-10 13:00:01 +04:00
return 0 ;
ret = 0 ;
2009-04-14 21:48:41 +04:00
pipe_lock ( pipe ) ;
2006-07-10 13:00:01 +04:00
2019-10-16 18:47:32 +03:00
while ( pipe_full ( pipe - > head , pipe - > tail , pipe - > max_usage ) ) {
2006-07-10 13:00:01 +04:00
if ( ! pipe - > readers ) {
send_sig ( SIGPIPE , current , 0 ) ;
ret = - EPIPE ;
break ;
}
if ( flags & SPLICE_F_NONBLOCK ) {
ret = - EAGAIN ;
break ;
}
if ( signal_pending ( current ) ) {
ret = - ERESTARTSYS ;
break ;
}
pipe: remove pipe_wait() and fix wakeup race with splice
The pipe splice code still used the old model of waiting for pipe IO by
using a non-specific "pipe_wait()" that waited for any pipe event to
happen, which depended on all pipe IO being entirely serialized by the
pipe lock. So by checking the state you were waiting for, and then
adding yourself to the wait queue before dropping the lock, you were
guaranteed to see all the wakeups.
Strictly speaking, the actual wakeups were not done under the lock, but
the pipe_wait() model still worked, because since the waiter held the
lock when checking whether it should sleep, it would always see the
current state, and the wakeup was always done after updating the state.
However, commit 0ddad21d3e99 ("pipe: use exclusive waits when reading or
writing") split the single wait-queue into two, and in the process also
made the "wait for event" code wait for _two_ wait queues, and that then
showed a race with the wakers that were not serialized by the pipe lock.
It's only splice that used that "pipe_wait()" model, so the problem
wasn't obvious, but Josef Bacik reports:
"I hit a hang with fstest btrfs/187, which does a btrfs send into
/dev/null. This works by creating a pipe, the write side is given to
the kernel to write into, and the read side is handed to a thread that
splices into a file, in this case /dev/null.
The box that was hung had the write side stuck here [pipe_write] and
the read side stuck here [splice_from_pipe_next -> pipe_wait].
[ more details about pipe_wait() scenario ]
The problem is we're doing the prepare_to_wait, which sets our state
each time, however we can be woken up either with reads or writes. In
the case above we race with the WRITER waking us up, and re-set our
state to INTERRUPTIBLE, and thus never break out of schedule"
Josef had a patch that avoided the issue in pipe_wait() by just making
it set the state only once, but the deeper problem is that pipe_wait()
depends on a level of synchonization by the pipe mutex that it really
shouldn't. And the whole "wait for any pipe state change" model really
isn't very good to begin with.
So rather than trying to work around things in pipe_wait(), remove that
legacy model of "wait for arbitrary pipe event" entirely, and actually
create functions that wait for the pipe actually being readable or
writable, and can do so without depending on the pipe lock serializing
everything.
Fixes: 0ddad21d3e99 ("pipe: use exclusive waits when reading or writing")
Link: https://lore.kernel.org/linux-fsdevel/bfa88b5ad6f069b2b679316b9e495a970130416c.1601567868.git.josef@toxicpanda.com/
Reported-by: Josef Bacik <josef@toxicpanda.com>
Reviewed-and-tested-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2020-10-02 05:14:36 +03:00
pipe_wait_writable ( pipe ) ;
2006-07-10 13:00:01 +04:00
}
2009-04-14 21:48:41 +04:00
pipe_unlock ( pipe ) ;
2006-07-10 13:00:01 +04:00
return ret ;
}
splice: implement pipe to pipe splicing
Allow splice(2) to work when both the input and the output is a pipe.
Based on the impementation of the tee(2) syscall, but instead of
duplicating the buffer references move the buffers from the input pipe
to the output pipe.
Moving the whole buffer only succeeds if the full length of the buffer
is spliced. Otherwise duplicate the buffer, just like tee(2), set the
length of the output buffer and advance the offset on the input
buffer.
Since splice is operating on two pipes, special care needs to be taken
with locking to prevent AN ABBA deadlock. Again this is done
similarly to the tee(2) syscall, first preparing the input and output
pipes so there's data to consume and space for that data, and then
doing the move operation while holding both locks.
If other processes are doing I/O on the same pipes parallel to the
splice, then by the time both inodes are locked there might be no
buffers left to move, or no space to move them to. In this case retry
the whole operation, including the preparation phase. This could lead
to starvation, but I'm not sure if that's serious enough to worry
about.
Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
2009-05-07 17:37:35 +04:00
/*
* Splice contents of ipipe to opipe .
*/
static int splice_pipe_to_pipe ( struct pipe_inode_info * ipipe ,
struct pipe_inode_info * opipe ,
size_t len , unsigned int flags )
{
struct pipe_buffer * ibuf , * obuf ;
2019-11-15 16:30:32 +03:00
unsigned int i_head , o_head ;
unsigned int i_tail , o_tail ;
unsigned int i_mask , o_mask ;
int ret = 0 ;
splice: implement pipe to pipe splicing
Allow splice(2) to work when both the input and the output is a pipe.
Based on the impementation of the tee(2) syscall, but instead of
duplicating the buffer references move the buffers from the input pipe
to the output pipe.
Moving the whole buffer only succeeds if the full length of the buffer
is spliced. Otherwise duplicate the buffer, just like tee(2), set the
length of the output buffer and advance the offset on the input
buffer.
Since splice is operating on two pipes, special care needs to be taken
with locking to prevent AN ABBA deadlock. Again this is done
similarly to the tee(2) syscall, first preparing the input and output
pipes so there's data to consume and space for that data, and then
doing the move operation while holding both locks.
If other processes are doing I/O on the same pipes parallel to the
splice, then by the time both inodes are locked there might be no
buffers left to move, or no space to move them to. In this case retry
the whole operation, including the preparation phase. This could lead
to starvation, but I'm not sure if that's serious enough to worry
about.
Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
2009-05-07 17:37:35 +04:00
bool input_wakeup = false ;
retry :
ret = ipipe_prep ( ipipe , flags ) ;
if ( ret )
return ret ;
ret = opipe_prep ( opipe , flags ) ;
if ( ret )
return ret ;
/*
* Potential ABBA deadlock , work around it by ordering lock
* grabbing by pipe info address . Otherwise two different processes
* could deadlock ( one doing tee from A - > B , the other from B - > A ) .
*/
pipe_double_lock ( ipipe , opipe ) ;
2019-11-15 16:30:32 +03:00
i_tail = ipipe - > tail ;
i_mask = ipipe - > ring_size - 1 ;
o_head = opipe - > head ;
o_mask = opipe - > ring_size - 1 ;
splice: implement pipe to pipe splicing
Allow splice(2) to work when both the input and the output is a pipe.
Based on the impementation of the tee(2) syscall, but instead of
duplicating the buffer references move the buffers from the input pipe
to the output pipe.
Moving the whole buffer only succeeds if the full length of the buffer
is spliced. Otherwise duplicate the buffer, just like tee(2), set the
length of the output buffer and advance the offset on the input
buffer.
Since splice is operating on two pipes, special care needs to be taken
with locking to prevent AN ABBA deadlock. Again this is done
similarly to the tee(2) syscall, first preparing the input and output
pipes so there's data to consume and space for that data, and then
doing the move operation while holding both locks.
If other processes are doing I/O on the same pipes parallel to the
splice, then by the time both inodes are locked there might be no
buffers left to move, or no space to move them to. In this case retry
the whole operation, including the preparation phase. This could lead
to starvation, but I'm not sure if that's serious enough to worry
about.
Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
2009-05-07 17:37:35 +04:00
do {
2019-11-15 16:30:32 +03:00
size_t o_len ;
splice: implement pipe to pipe splicing
Allow splice(2) to work when both the input and the output is a pipe.
Based on the impementation of the tee(2) syscall, but instead of
duplicating the buffer references move the buffers from the input pipe
to the output pipe.
Moving the whole buffer only succeeds if the full length of the buffer
is spliced. Otherwise duplicate the buffer, just like tee(2), set the
length of the output buffer and advance the offset on the input
buffer.
Since splice is operating on two pipes, special care needs to be taken
with locking to prevent AN ABBA deadlock. Again this is done
similarly to the tee(2) syscall, first preparing the input and output
pipes so there's data to consume and space for that data, and then
doing the move operation while holding both locks.
If other processes are doing I/O on the same pipes parallel to the
splice, then by the time both inodes are locked there might be no
buffers left to move, or no space to move them to. In this case retry
the whole operation, including the preparation phase. This could lead
to starvation, but I'm not sure if that's serious enough to worry
about.
Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
2009-05-07 17:37:35 +04:00
if ( ! opipe - > readers ) {
send_sig ( SIGPIPE , current , 0 ) ;
if ( ! ret )
ret = - EPIPE ;
break ;
}
2019-11-15 16:30:32 +03:00
i_head = ipipe - > head ;
o_tail = opipe - > tail ;
if ( pipe_empty ( i_head , i_tail ) & & ! ipipe - > writers )
splice: implement pipe to pipe splicing
Allow splice(2) to work when both the input and the output is a pipe.
Based on the impementation of the tee(2) syscall, but instead of
duplicating the buffer references move the buffers from the input pipe
to the output pipe.
Moving the whole buffer only succeeds if the full length of the buffer
is spliced. Otherwise duplicate the buffer, just like tee(2), set the
length of the output buffer and advance the offset on the input
buffer.
Since splice is operating on two pipes, special care needs to be taken
with locking to prevent AN ABBA deadlock. Again this is done
similarly to the tee(2) syscall, first preparing the input and output
pipes so there's data to consume and space for that data, and then
doing the move operation while holding both locks.
If other processes are doing I/O on the same pipes parallel to the
splice, then by the time both inodes are locked there might be no
buffers left to move, or no space to move them to. In this case retry
the whole operation, including the preparation phase. This could lead
to starvation, but I'm not sure if that's serious enough to worry
about.
Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
2009-05-07 17:37:35 +04:00
break ;
/*
* Cannot make any progress , because either the input
* pipe is empty or the output pipe is full .
*/
2019-11-15 16:30:32 +03:00
if ( pipe_empty ( i_head , i_tail ) | |
2019-10-16 18:47:32 +03:00
pipe_full ( o_head , o_tail , opipe - > max_usage ) ) {
splice: implement pipe to pipe splicing
Allow splice(2) to work when both the input and the output is a pipe.
Based on the impementation of the tee(2) syscall, but instead of
duplicating the buffer references move the buffers from the input pipe
to the output pipe.
Moving the whole buffer only succeeds if the full length of the buffer
is spliced. Otherwise duplicate the buffer, just like tee(2), set the
length of the output buffer and advance the offset on the input
buffer.
Since splice is operating on two pipes, special care needs to be taken
with locking to prevent AN ABBA deadlock. Again this is done
similarly to the tee(2) syscall, first preparing the input and output
pipes so there's data to consume and space for that data, and then
doing the move operation while holding both locks.
If other processes are doing I/O on the same pipes parallel to the
splice, then by the time both inodes are locked there might be no
buffers left to move, or no space to move them to. In this case retry
the whole operation, including the preparation phase. This could lead
to starvation, but I'm not sure if that's serious enough to worry
about.
Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
2009-05-07 17:37:35 +04:00
/* Already processed some buffers, break */
if ( ret )
break ;
if ( flags & SPLICE_F_NONBLOCK ) {
ret = - EAGAIN ;
break ;
}
/*
* We raced with another reader / writer and haven ' t
* managed to process any buffers . A zero return
* value means EOF , so retry instead .
*/
pipe_unlock ( ipipe ) ;
pipe_unlock ( opipe ) ;
goto retry ;
}
2019-11-15 16:30:32 +03:00
ibuf = & ipipe - > bufs [ i_tail & i_mask ] ;
obuf = & opipe - > bufs [ o_head & o_mask ] ;
splice: implement pipe to pipe splicing
Allow splice(2) to work when both the input and the output is a pipe.
Based on the impementation of the tee(2) syscall, but instead of
duplicating the buffer references move the buffers from the input pipe
to the output pipe.
Moving the whole buffer only succeeds if the full length of the buffer
is spliced. Otherwise duplicate the buffer, just like tee(2), set the
length of the output buffer and advance the offset on the input
buffer.
Since splice is operating on two pipes, special care needs to be taken
with locking to prevent AN ABBA deadlock. Again this is done
similarly to the tee(2) syscall, first preparing the input and output
pipes so there's data to consume and space for that data, and then
doing the move operation while holding both locks.
If other processes are doing I/O on the same pipes parallel to the
splice, then by the time both inodes are locked there might be no
buffers left to move, or no space to move them to. In this case retry
the whole operation, including the preparation phase. This could lead
to starvation, but I'm not sure if that's serious enough to worry
about.
Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
2009-05-07 17:37:35 +04:00
if ( len > = ibuf - > len ) {
/*
* Simply move the whole buffer from ipipe to opipe
*/
* obuf = * ibuf ;
ibuf - > ops = NULL ;
2019-11-15 16:30:32 +03:00
i_tail + + ;
ipipe - > tail = i_tail ;
splice: implement pipe to pipe splicing
Allow splice(2) to work when both the input and the output is a pipe.
Based on the impementation of the tee(2) syscall, but instead of
duplicating the buffer references move the buffers from the input pipe
to the output pipe.
Moving the whole buffer only succeeds if the full length of the buffer
is spliced. Otherwise duplicate the buffer, just like tee(2), set the
length of the output buffer and advance the offset on the input
buffer.
Since splice is operating on two pipes, special care needs to be taken
with locking to prevent AN ABBA deadlock. Again this is done
similarly to the tee(2) syscall, first preparing the input and output
pipes so there's data to consume and space for that data, and then
doing the move operation while holding both locks.
If other processes are doing I/O on the same pipes parallel to the
splice, then by the time both inodes are locked there might be no
buffers left to move, or no space to move them to. In this case retry
the whole operation, including the preparation phase. This could lead
to starvation, but I'm not sure if that's serious enough to worry
about.
Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
2009-05-07 17:37:35 +04:00
input_wakeup = true ;
2019-11-15 16:30:32 +03:00
o_len = obuf - > len ;
o_head + + ;
opipe - > head = o_head ;
splice: implement pipe to pipe splicing
Allow splice(2) to work when both the input and the output is a pipe.
Based on the impementation of the tee(2) syscall, but instead of
duplicating the buffer references move the buffers from the input pipe
to the output pipe.
Moving the whole buffer only succeeds if the full length of the buffer
is spliced. Otherwise duplicate the buffer, just like tee(2), set the
length of the output buffer and advance the offset on the input
buffer.
Since splice is operating on two pipes, special care needs to be taken
with locking to prevent AN ABBA deadlock. Again this is done
similarly to the tee(2) syscall, first preparing the input and output
pipes so there's data to consume and space for that data, and then
doing the move operation while holding both locks.
If other processes are doing I/O on the same pipes parallel to the
splice, then by the time both inodes are locked there might be no
buffers left to move, or no space to move them to. In this case retry
the whole operation, including the preparation phase. This could lead
to starvation, but I'm not sure if that's serious enough to worry
about.
Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
2009-05-07 17:37:35 +04:00
} else {
/*
* Get a reference to this pipe buffer ,
* so we can copy the contents over .
*/
2019-04-06 00:02:10 +03:00
if ( ! pipe_buf_get ( ipipe , ibuf ) ) {
if ( ret = = 0 )
ret = - EFAULT ;
break ;
}
splice: implement pipe to pipe splicing
Allow splice(2) to work when both the input and the output is a pipe.
Based on the impementation of the tee(2) syscall, but instead of
duplicating the buffer references move the buffers from the input pipe
to the output pipe.
Moving the whole buffer only succeeds if the full length of the buffer
is spliced. Otherwise duplicate the buffer, just like tee(2), set the
length of the output buffer and advance the offset on the input
buffer.
Since splice is operating on two pipes, special care needs to be taken
with locking to prevent AN ABBA deadlock. Again this is done
similarly to the tee(2) syscall, first preparing the input and output
pipes so there's data to consume and space for that data, and then
doing the move operation while holding both locks.
If other processes are doing I/O on the same pipes parallel to the
splice, then by the time both inodes are locked there might be no
buffers left to move, or no space to move them to. In this case retry
the whole operation, including the preparation phase. This could lead
to starvation, but I'm not sure if that's serious enough to worry
about.
Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
2009-05-07 17:37:35 +04:00
* obuf = * ibuf ;
/*
2020-05-20 18:58:12 +03:00
* Don ' t inherit the gift and merge flags , we need to
splice: implement pipe to pipe splicing
Allow splice(2) to work when both the input and the output is a pipe.
Based on the impementation of the tee(2) syscall, but instead of
duplicating the buffer references move the buffers from the input pipe
to the output pipe.
Moving the whole buffer only succeeds if the full length of the buffer
is spliced. Otherwise duplicate the buffer, just like tee(2), set the
length of the output buffer and advance the offset on the input
buffer.
Since splice is operating on two pipes, special care needs to be taken
with locking to prevent AN ABBA deadlock. Again this is done
similarly to the tee(2) syscall, first preparing the input and output
pipes so there's data to consume and space for that data, and then
doing the move operation while holding both locks.
If other processes are doing I/O on the same pipes parallel to the
splice, then by the time both inodes are locked there might be no
buffers left to move, or no space to move them to. In this case retry
the whole operation, including the preparation phase. This could lead
to starvation, but I'm not sure if that's serious enough to worry
about.
Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
2009-05-07 17:37:35 +04:00
* prevent multiple steals of this page .
*/
obuf - > flags & = ~ PIPE_BUF_FLAG_GIFT ;
2020-05-20 18:58:12 +03:00
obuf - > flags & = ~ PIPE_BUF_FLAG_CAN_MERGE ;
splice: don't merge into linked buffers
Before this patch, it was possible for two pipes to affect each other after
data had been transferred between them with tee():
============
$ cat tee_test.c
int main(void) {
int pipe_a[2];
if (pipe(pipe_a)) err(1, "pipe");
int pipe_b[2];
if (pipe(pipe_b)) err(1, "pipe");
if (write(pipe_a[1], "abcd", 4) != 4) err(1, "write");
if (tee(pipe_a[0], pipe_b[1], 2, 0) != 2) err(1, "tee");
if (write(pipe_b[1], "xx", 2) != 2) err(1, "write");
char buf[5];
if (read(pipe_a[0], buf, 4) != 4) err(1, "read");
buf[4] = 0;
printf("got back: '%s'\n", buf);
}
$ gcc -o tee_test tee_test.c
$ ./tee_test
got back: 'abxx'
$
============
As suggested by Al Viro, fix it by creating a separate type for
non-mergeable pipe buffers, then changing the types of buffers in
splice_pipe_to_pipe() and link_pipe().
Cc: <stable@vger.kernel.org>
Fixes: 7c77f0b3f920 ("splice: implement pipe to pipe splicing")
Fixes: 70524490ee2e ("[PATCH] splice: add support for sys_tee()")
Suggested-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Jann Horn <jannh@google.com>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2019-01-23 17:19:17 +03:00
splice: implement pipe to pipe splicing
Allow splice(2) to work when both the input and the output is a pipe.
Based on the impementation of the tee(2) syscall, but instead of
duplicating the buffer references move the buffers from the input pipe
to the output pipe.
Moving the whole buffer only succeeds if the full length of the buffer
is spliced. Otherwise duplicate the buffer, just like tee(2), set the
length of the output buffer and advance the offset on the input
buffer.
Since splice is operating on two pipes, special care needs to be taken
with locking to prevent AN ABBA deadlock. Again this is done
similarly to the tee(2) syscall, first preparing the input and output
pipes so there's data to consume and space for that data, and then
doing the move operation while holding both locks.
If other processes are doing I/O on the same pipes parallel to the
splice, then by the time both inodes are locked there might be no
buffers left to move, or no space to move them to. In this case retry
the whole operation, including the preparation phase. This could lead
to starvation, but I'm not sure if that's serious enough to worry
about.
Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
2009-05-07 17:37:35 +04:00
obuf - > len = len ;
2019-11-15 16:30:32 +03:00
ibuf - > offset + = len ;
ibuf - > len - = len ;
o_len = len ;
o_head + + ;
opipe - > head = o_head ;
splice: implement pipe to pipe splicing
Allow splice(2) to work when both the input and the output is a pipe.
Based on the impementation of the tee(2) syscall, but instead of
duplicating the buffer references move the buffers from the input pipe
to the output pipe.
Moving the whole buffer only succeeds if the full length of the buffer
is spliced. Otherwise duplicate the buffer, just like tee(2), set the
length of the output buffer and advance the offset on the input
buffer.
Since splice is operating on two pipes, special care needs to be taken
with locking to prevent AN ABBA deadlock. Again this is done
similarly to the tee(2) syscall, first preparing the input and output
pipes so there's data to consume and space for that data, and then
doing the move operation while holding both locks.
If other processes are doing I/O on the same pipes parallel to the
splice, then by the time both inodes are locked there might be no
buffers left to move, or no space to move them to. In this case retry
the whole operation, including the preparation phase. This could lead
to starvation, but I'm not sure if that's serious enough to worry
about.
Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
2009-05-07 17:37:35 +04:00
}
2019-11-15 16:30:32 +03:00
ret + = o_len ;
len - = o_len ;
splice: implement pipe to pipe splicing
Allow splice(2) to work when both the input and the output is a pipe.
Based on the impementation of the tee(2) syscall, but instead of
duplicating the buffer references move the buffers from the input pipe
to the output pipe.
Moving the whole buffer only succeeds if the full length of the buffer
is spliced. Otherwise duplicate the buffer, just like tee(2), set the
length of the output buffer and advance the offset on the input
buffer.
Since splice is operating on two pipes, special care needs to be taken
with locking to prevent AN ABBA deadlock. Again this is done
similarly to the tee(2) syscall, first preparing the input and output
pipes so there's data to consume and space for that data, and then
doing the move operation while holding both locks.
If other processes are doing I/O on the same pipes parallel to the
splice, then by the time both inodes are locked there might be no
buffers left to move, or no space to move them to. In this case retry
the whole operation, including the preparation phase. This could lead
to starvation, but I'm not sure if that's serious enough to worry
about.
Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
2009-05-07 17:37:35 +04:00
} while ( len ) ;
pipe_unlock ( ipipe ) ;
pipe_unlock ( opipe ) ;
/*
* If we put data in the output pipe , wakeup any potential readers .
*/
2011-05-23 21:58:53 +04:00
if ( ret > 0 )
wakeup_pipe_readers ( opipe ) ;
splice: implement pipe to pipe splicing
Allow splice(2) to work when both the input and the output is a pipe.
Based on the impementation of the tee(2) syscall, but instead of
duplicating the buffer references move the buffers from the input pipe
to the output pipe.
Moving the whole buffer only succeeds if the full length of the buffer
is spliced. Otherwise duplicate the buffer, just like tee(2), set the
length of the output buffer and advance the offset on the input
buffer.
Since splice is operating on two pipes, special care needs to be taken
with locking to prevent AN ABBA deadlock. Again this is done
similarly to the tee(2) syscall, first preparing the input and output
pipes so there's data to consume and space for that data, and then
doing the move operation while holding both locks.
If other processes are doing I/O on the same pipes parallel to the
splice, then by the time both inodes are locked there might be no
buffers left to move, or no space to move them to. In this case retry
the whole operation, including the preparation phase. This could lead
to starvation, but I'm not sure if that's serious enough to worry
about.
Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
2009-05-07 17:37:35 +04:00
if ( input_wakeup )
wakeup_pipe_writers ( ipipe ) ;
return ret ;
}
2006-04-11 17:51:17 +04:00
/*
* Link contents of ipipe to opipe .
*/
static int link_pipe ( struct pipe_inode_info * ipipe ,
struct pipe_inode_info * opipe ,
size_t len , unsigned int flags )
{
struct pipe_buffer * ibuf , * obuf ;
2019-11-15 16:30:32 +03:00
unsigned int i_head , o_head ;
unsigned int i_tail , o_tail ;
unsigned int i_mask , o_mask ;
int ret = 0 ;
2006-04-11 17:51:17 +04:00
/*
* Potential ABBA deadlock , work around it by ordering lock
2009-04-14 21:48:41 +04:00
* grabbing by pipe info address . Otherwise two different processes
2006-04-11 17:51:17 +04:00
* could deadlock ( one doing tee from A - > B , the other from B - > A ) .
*/
2009-04-14 21:48:41 +04:00
pipe_double_lock ( ipipe , opipe ) ;
2006-04-11 17:51:17 +04:00
2019-11-15 16:30:32 +03:00
i_tail = ipipe - > tail ;
i_mask = ipipe - > ring_size - 1 ;
o_head = opipe - > head ;
o_mask = opipe - > ring_size - 1 ;
2006-07-10 13:00:01 +04:00
do {
2006-04-11 17:51:17 +04:00
if ( ! opipe - > readers ) {
send_sig ( SIGPIPE , current , 0 ) ;
if ( ! ret )
ret = - EPIPE ;
break ;
}
2019-11-15 16:30:32 +03:00
i_head = ipipe - > head ;
o_tail = opipe - > tail ;
2006-07-10 13:00:01 +04:00
/*
2019-11-15 16:30:32 +03:00
* If we have iterated all input buffers or run out of
2006-07-10 13:00:01 +04:00
* output room , break .
*/
2019-11-15 16:30:32 +03:00
if ( pipe_empty ( i_head , i_tail ) | |
2019-10-16 18:47:32 +03:00
pipe_full ( o_head , o_tail , opipe - > max_usage ) )
2006-07-10 13:00:01 +04:00
break ;
2006-04-11 17:51:17 +04:00
2019-11-15 16:30:32 +03:00
ibuf = & ipipe - > bufs [ i_tail & i_mask ] ;
obuf = & opipe - > bufs [ o_head & o_mask ] ;
2006-04-11 17:51:17 +04:00
/*
2006-07-10 13:00:01 +04:00
* Get a reference to this pipe buffer ,
* so we can copy the contents over .
2006-04-11 17:51:17 +04:00
*/
2019-04-06 00:02:10 +03:00
if ( ! pipe_buf_get ( ipipe , ibuf ) ) {
if ( ret = = 0 )
ret = - EFAULT ;
break ;
}
2006-07-10 13:00:01 +04:00
* obuf = * ibuf ;
2006-04-19 17:56:40 +04:00
/*
2020-05-20 18:58:12 +03:00
* Don ' t inherit the gift and merge flag , we need to prevent
* multiple steals of this page .
2006-04-19 17:56:40 +04:00
*/
2006-07-10 13:00:01 +04:00
obuf - > flags & = ~ PIPE_BUF_FLAG_GIFT ;
2020-05-20 18:58:12 +03:00
obuf - > flags & = ~ PIPE_BUF_FLAG_CAN_MERGE ;
splice: don't merge into linked buffers
Before this patch, it was possible for two pipes to affect each other after
data had been transferred between them with tee():
============
$ cat tee_test.c
int main(void) {
int pipe_a[2];
if (pipe(pipe_a)) err(1, "pipe");
int pipe_b[2];
if (pipe(pipe_b)) err(1, "pipe");
if (write(pipe_a[1], "abcd", 4) != 4) err(1, "write");
if (tee(pipe_a[0], pipe_b[1], 2, 0) != 2) err(1, "tee");
if (write(pipe_b[1], "xx", 2) != 2) err(1, "write");
char buf[5];
if (read(pipe_a[0], buf, 4) != 4) err(1, "read");
buf[4] = 0;
printf("got back: '%s'\n", buf);
}
$ gcc -o tee_test tee_test.c
$ ./tee_test
got back: 'abxx'
$
============
As suggested by Al Viro, fix it by creating a separate type for
non-mergeable pipe buffers, then changing the types of buffers in
splice_pipe_to_pipe() and link_pipe().
Cc: <stable@vger.kernel.org>
Fixes: 7c77f0b3f920 ("splice: implement pipe to pipe splicing")
Fixes: 70524490ee2e ("[PATCH] splice: add support for sys_tee()")
Suggested-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Jann Horn <jannh@google.com>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2019-01-23 17:19:17 +03:00
2006-07-10 13:00:01 +04:00
if ( obuf - > len > len )
obuf - > len = len ;
ret + = obuf - > len ;
len - = obuf - > len ;
2019-11-15 16:30:32 +03:00
o_head + + ;
opipe - > head = o_head ;
i_tail + + ;
2006-07-10 13:00:01 +04:00
} while ( len ) ;
2006-04-11 17:51:17 +04:00
2009-04-14 21:48:41 +04:00
pipe_unlock ( ipipe ) ;
pipe_unlock ( opipe ) ;
2006-04-11 17:51:17 +04:00
2006-07-10 13:00:01 +04:00
/*
* If we put data in the output pipe , wakeup any potential readers .
*/
2011-05-23 21:58:53 +04:00
if ( ret > 0 )
wakeup_pipe_readers ( opipe ) ;
2006-04-11 17:51:17 +04:00
return ret ;
}
/*
* This is a tee ( 1 ) implementation that works on pipes . It doesn ' t copy
* any data , it simply references the ' in ' pages on the ' out ' pipe .
* The ' flags ' used are the SPLICE_F_ * variants , currently the only
* applicable one is SPLICE_F_NONBLOCK .
*/
2020-05-17 14:18:05 +03:00
long do_tee ( struct file * in , struct file * out , size_t len , unsigned int flags )
2006-04-11 17:51:17 +04:00
{
pipe: Add general notification queue support
Make it possible to have a general notification queue built on top of a
standard pipe. Notifications are 'spliced' into the pipe and then read
out. splice(), vmsplice() and sendfile() are forbidden on pipes used for
notifications as post_one_notification() cannot take pipe->mutex. This
means that notifications could be posted in between individual pipe
buffers, making iov_iter_revert() difficult to effect.
The way the notification queue is used is:
(1) An application opens a pipe with a special flag and indicates the
number of messages it wishes to be able to queue at once (this can
only be set once):
pipe2(fds, O_NOTIFICATION_PIPE);
ioctl(fds[0], IOC_WATCH_QUEUE_SET_SIZE, queue_depth);
(2) The application then uses poll() and read() as normal to extract data
from the pipe. read() will return multiple notifications if the
buffer is big enough, but it will not split a notification across
buffers - rather it will return a short read or EMSGSIZE.
Notification messages include a length in the header so that the
caller can split them up.
Each message has a header that describes it:
struct watch_notification {
__u32 type:24;
__u32 subtype:8;
__u32 info;
};
The type indicates the source (eg. mount tree changes, superblock events,
keyring changes, block layer events) and the subtype indicates the event
type (eg. mount, unmount; EIO, EDQUOT; link, unlink). The info field
indicates a number of things, including the entry length, an ID assigned to
a watchpoint contributing to this buffer and type-specific flags.
Supplementary data, such as the key ID that generated an event, can be
attached in additional slots. The maximum message size is 127 bytes.
Messages may not be padded or aligned, so there is no guarantee, for
example, that the notification type will be on a 4-byte bounary.
Signed-off-by: David Howells <dhowells@redhat.com>
2020-01-14 20:07:11 +03:00
struct pipe_inode_info * ipipe = get_pipe_info ( in , true ) ;
struct pipe_inode_info * opipe = get_pipe_info ( out , true ) ;
2006-07-10 13:00:01 +04:00
int ret = - EINVAL ;
2006-04-11 17:51:17 +04:00
2020-05-04 22:39:35 +03:00
if ( unlikely ( ! ( in - > f_mode & FMODE_READ ) | |
! ( out - > f_mode & FMODE_WRITE ) ) )
return - EBADF ;
2006-04-11 17:51:17 +04:00
/*
2006-07-10 13:00:01 +04:00
* Duplicate the contents of ipipe to opipe without actually
* copying the data .
2006-04-11 17:51:17 +04:00
*/
2006-07-10 13:00:01 +04:00
if ( ipipe & & opipe & & ipipe ! = opipe ) {
2019-02-07 18:45:19 +03:00
if ( ( in - > f_flags | out - > f_flags ) & O_NONBLOCK )
flags | = SPLICE_F_NONBLOCK ;
2006-07-10 13:00:01 +04:00
/*
* Keep going , unless we encounter an error . The ipipe / opipe
* ordering doesn ' t really matter .
*/
splice: implement pipe to pipe splicing
Allow splice(2) to work when both the input and the output is a pipe.
Based on the impementation of the tee(2) syscall, but instead of
duplicating the buffer references move the buffers from the input pipe
to the output pipe.
Moving the whole buffer only succeeds if the full length of the buffer
is spliced. Otherwise duplicate the buffer, just like tee(2), set the
length of the output buffer and advance the offset on the input
buffer.
Since splice is operating on two pipes, special care needs to be taken
with locking to prevent AN ABBA deadlock. Again this is done
similarly to the tee(2) syscall, first preparing the input and output
pipes so there's data to consume and space for that data, and then
doing the move operation while holding both locks.
If other processes are doing I/O on the same pipes parallel to the
splice, then by the time both inodes are locked there might be no
buffers left to move, or no space to move them to. In this case retry
the whole operation, including the preparation phase. This could lead
to starvation, but I'm not sure if that's serious enough to worry
about.
Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
2009-05-07 17:37:35 +04:00
ret = ipipe_prep ( ipipe , flags ) ;
2006-07-10 13:00:01 +04:00
if ( ! ret ) {
splice: implement pipe to pipe splicing
Allow splice(2) to work when both the input and the output is a pipe.
Based on the impementation of the tee(2) syscall, but instead of
duplicating the buffer references move the buffers from the input pipe
to the output pipe.
Moving the whole buffer only succeeds if the full length of the buffer
is spliced. Otherwise duplicate the buffer, just like tee(2), set the
length of the output buffer and advance the offset on the input
buffer.
Since splice is operating on two pipes, special care needs to be taken
with locking to prevent AN ABBA deadlock. Again this is done
similarly to the tee(2) syscall, first preparing the input and output
pipes so there's data to consume and space for that data, and then
doing the move operation while holding both locks.
If other processes are doing I/O on the same pipes parallel to the
splice, then by the time both inodes are locked there might be no
buffers left to move, or no space to move them to. In this case retry
the whole operation, including the preparation phase. This could lead
to starvation, but I'm not sure if that's serious enough to worry
about.
Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
2009-05-07 17:37:35 +04:00
ret = opipe_prep ( opipe , flags ) ;
2008-02-20 12:34:51 +03:00
if ( ! ret )
2006-07-10 13:00:01 +04:00
ret = link_pipe ( ipipe , opipe , len , flags ) ;
}
}
2006-04-11 17:51:17 +04:00
2006-07-10 13:00:01 +04:00
return ret ;
2006-04-11 17:51:17 +04:00
}
2009-01-14 16:14:33 +03:00
SYSCALL_DEFINE4 ( tee , int , fdin , int , fdout , size_t , len , unsigned int , flags )
2006-04-11 17:51:17 +04:00
{
2020-05-04 22:39:35 +03:00
struct fd in , out ;
2012-08-28 20:52:22 +04:00
int error ;
2006-04-11 17:51:17 +04:00
2016-12-10 21:17:32 +03:00
if ( unlikely ( flags & ~ SPLICE_F_ALL ) )
return - EINVAL ;
2006-04-11 17:51:17 +04:00
if ( unlikely ( ! len ) )
return 0 ;
error = - EBADF ;
2012-08-28 20:52:22 +04:00
in = fdget ( fdin ) ;
if ( in . file ) {
2020-05-04 22:39:35 +03:00
out = fdget ( fdout ) ;
if ( out . file ) {
error = do_tee ( in . file , out . file , len , flags ) ;
fdput ( out ) ;
2006-04-11 17:51:17 +04:00
}
2012-08-28 20:52:22 +04:00
fdput ( in ) ;
2006-04-11 17:51:17 +04:00
}
return error ;
}