2006-03-30 15:15:30 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-04-11 13:56:34 +02:00
|
|
|
|
|
|
|
|
|
2006-03-30 15:15:30 +02:00
|
|
|
|
2006-09-04 15:41:16 +02:00
|
|
|
|
2006-04-11 13:56:34 +02:00
|
|
|
|
|
|
|
|
|
2006-03-30 15:15:30 +02:00
|
|
|
|
|
|
|
|
|
2016-11-01 07:40:16 -06:00
|
|
|
|
2006-03-30 15:15:30 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-06-04 09:59:47 +02:00
|
|
|
|
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-07 18:08:01 -08:00
|
|
|
|
2006-03-30 15:15:30 +02:00
|
|
|
|
2006-03-30 15:16:46 +02:00
|
|
|
|
2006-04-02 23:04:46 +02:00
|
|
|
|
2011-11-16 23:57:37 -05:00
|
|
|
|
2006-04-02 23:04:46 +02:00
|
|
|
|
2006-04-26 10:59:21 +02:00
|
|
|
|
2007-07-13 11:44:32 +02:00
|
|
|
|
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 17:04:11 +09:00
|
|
|
|
2012-04-05 03:05:35 +00:00
|
|
|
|
2013-03-02 10:19:56 -05:00
|
|
|
|
2017-02-02 19:15:33 +01:00
|
|
|
|
|
|
|
|
|
2013-03-20 13:19:30 -04:00
|
|
|
|
2006-03-30 15:15:30 +02:00
|
|
|
|
2006-04-02 23:05:09 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-05-03 10:41:33 +02:00
|
|
|
|
2006-03-30 15:16:46 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-06-20 15:01:12 +02:00
|
|
|
|
2006-03-30 15:16:46 +02:00
|
|
|
|
2006-04-19 15:57:31 +02:00
|
|
|
|
|
|
|
|
|
2006-06-20 15:01:12 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-03-30 15:16:46 +02:00
|
|
|
|
2006-06-20 15:01:12 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-04-02 23:10:32 +02:00
|
|
|
|
2009-04-03 16:42:36 +01:00
|
|
|
|
|
|
|
|
|
2008-05-20 21:27:41 +02:00
|
|
|
|
2006-04-02 23:04:46 +02:00
|
|
|
|
2006-06-20 15:01:12 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-04-19 15:57:31 +02:00
|
|
|
|
2006-03-30 15:16:46 +02:00
|
|
|
|
2006-06-20 15:01:12 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-05-20 21:27:41 +02:00
|
|
|
|
2006-06-20 15:01:12 +02:00
|
|
|
|
|
|
|
|
|
2006-03-30 15:16:46 +02:00
|
|
|
|
|
|
|
|
|
2006-05-03 10:41:33 +02:00
|
|
|
|
2006-03-30 15:15:30 +02:00
|
|
|
|
|
|
|
|
|
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
|
|
|
|
2006-05-03 10:35:26 +02:00
|
|
|
|
2006-03-30 15:15:30 +02:00
|
|
|
|
|
|
|
|
|
2007-06-12 20:51:32 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-06-14 13:10:48 +02:00
|
|
|
|
|
|
|
|
|
2006-03-30 15:15:30 +02:00
|
|
|
|
|
|
|
|
|
2006-04-10 09:04:41 +02:00
|
|
|
|
2006-03-30 15:15:30 +02:00
|
|
|
|
|
|
|
|
|
2006-04-10 09:04:41 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-04-11 13:57:21 +02:00
|
|
|
|
2006-04-10 09:04:41 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-03-30 15:15:30 +02:00
|
|
|
|
2006-04-10 09:04:41 +02:00
|
|
|
|
2006-04-11 13:57:21 +02:00
|
|
|
|
2006-04-10 09:04:41 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-05-01 19:59:03 +02:00
|
|
|
|
2006-04-10 09:04:41 +02:00
|
|
|
|
2006-03-30 15:15:30 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-05-01 19:59:03 +02:00
|
|
|
|
2006-04-10 09:04:41 +02:00
|
|
|
|
|
|
|
|
|
2006-05-01 19:59:03 +02:00
|
|
|
|
2006-04-11 15:51:17 +02:00
|
|
|
|
|
|
|
|
|
2011-07-25 17:12:32 -07:00
|
|
|
|
2006-03-30 15:15:30 +02:00
|
|
|
|
2007-06-14 13:10:48 +02:00
|
|
|
|
2006-03-30 15:15:30 +02:00
|
|
|
|
2006-03-30 15:16:46 +02:00
|
|
|
|
2006-05-01 19:59:03 +02:00
|
|
|
|
2006-03-30 15:15:30 +02:00
|
|
|
|
|
|
|
|
|
2006-04-26 10:59:21 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-05-01 20:02:33 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-05-03 10:35:26 +02:00
|
|
|
|
2006-05-02 15:29:57 +02:00
|
|
|
|
2006-04-26 10:59:21 +02:00
|
|
|
|
|
|
|
|
|
2006-12-13 00:34:04 -08:00
|
|
|
|
2006-04-26 10:59:21 +02:00
|
|
|
|
2007-06-14 13:10:48 +02:00
|
|
|
|
2006-04-26 10:59:21 +02:00
|
|
|
|
|
|
|
|
|
2006-05-01 19:59:03 +02:00
|
|
|
|
2006-04-26 10:59:21 +02:00
|
|
|
|
|
|
|
|
|
2011-05-23 19:58:53 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-06-21 13:10:21 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-07-27 08:08:51 +02:00
|
|
|
|
2007-06-21 13:10:21 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-04-02 23:05:09 +02:00
|
|
|
|
2007-06-04 09:59:47 +02:00
|
|
|
|
|
|
|
|
|
2006-03-30 15:15:30 +02:00
|
|
|
|
2007-06-15 13:14:22 +02:00
|
|
|
|
2016-09-17 20:44:45 -04:00
|
|
|
|
2006-03-30 15:15:30 +02:00
|
|
|
|
2016-03-10 21:19:06 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-09-17 20:44:45 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-03-30 15:15:30 +02:00
|
|
|
|
2016-09-17 20:44:45 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-03-30 15:15:30 +02:00
|
|
|
|
2016-09-17 20:44:45 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-02-16 17:49:02 +01:00
|
|
|
|
2006-03-30 15:15:30 +02:00
|
|
|
|
2016-09-17 20:44:45 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-04-02 12:46:35 -07:00
|
|
|
|
2016-09-17 20:44:45 -04:00
|
|
|
|
2006-03-30 15:15:30 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-09-17 20:44:45 -04:00
|
|
|
|
|
|
|
|
|
2006-03-30 15:15:30 +02:00
|
|
|
|
2016-09-17 20:44:45 -04:00
|
|
|
|
2007-06-15 13:14:22 +02:00
|
|
|
|
2007-11-06 23:29:47 -08:00
|
|
|
|
2006-03-30 15:15:30 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-05-21 17:00:01 +02:00
|
|
|
|
2006-03-30 15:15:30 +02:00
|
|
|
|
2016-09-17 22:38:20 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-09-27 10:45:12 +02:00
|
|
|
|
2016-09-17 22:38:20 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-05-20 10:43:18 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-06-12 15:24:40 +02:00
|
|
|
|
2010-05-20 10:43:18 +02:00
|
|
|
|
locking/atomics: COCCINELLE/treewide: Convert trivial ACCESS_ONCE() patterns to READ_ONCE()/WRITE_ONCE()
Please do not apply this to mainline directly, instead please re-run the
coccinelle script shown below and apply its output.
For several reasons, it is desirable to use {READ,WRITE}_ONCE() in
preference to ACCESS_ONCE(), and new code is expected to use one of the
former. So far, there's been no reason to change most existing uses of
ACCESS_ONCE(), as these aren't harmful, and changing them results in
churn.
However, for some features, the read/write distinction is critical to
correct operation. To distinguish these cases, separate read/write
accessors must be used. This patch migrates (most) remaining
ACCESS_ONCE() instances to {READ,WRITE}_ONCE(), using the following
coccinelle script:
----
// Convert trivial ACCESS_ONCE() uses to equivalent READ_ONCE() and
// WRITE_ONCE()
// $ make coccicheck COCCI=/home/mark/once.cocci SPFLAGS="--include-headers" MODE=patch
virtual patch
@ depends on patch @
expression E1, E2;
@@
- ACCESS_ONCE(E1) = E2
+ WRITE_ONCE(E1, E2)
@ depends on patch @
expression E;
@@
- ACCESS_ONCE(E)
+ READ_ONCE(E)
----
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: davem@davemloft.net
Cc: linux-arch@vger.kernel.org
Cc: mpe@ellerman.id.au
Cc: shuah@kernel.org
Cc: snitzer@redhat.com
Cc: thor.thayer@linux.intel.com
Cc: tj@kernel.org
Cc: viro@zeniv.linux.org.uk
Cc: will.deacon@arm.com
Link: http://lkml.kernel.org/r/1508792849-3115-19-git-send-email-paulmck@linux.vnet.ibm.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-10-23 14:07:29 -07:00
|
|
|
|
2012-06-12 15:24:40 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-05-20 10:43:18 +02:00
|
|
|
|
|
|
|
|
|
2012-06-12 15:24:40 +02:00
|
|
|
|
|
|
|
|
|
2010-05-20 10:43:18 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-06-12 15:24:40 +02:00
|
|
|
|
2010-05-20 10:43:18 +02:00
|
|
|
|
2012-06-12 15:24:40 +02:00
|
|
|
|
2010-05-20 10:43:18 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-04-02 23:05:09 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-06-21 13:10:21 +02:00
|
|
|
|
2006-04-02 23:05:09 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-06-21 13:10:21 +02:00
|
|
|
|
|
|
|
|
|
2016-09-22 23:35:42 -04:00
|
|
|
|
2007-06-21 13:10:21 +02:00
|
|
|
|
2006-04-02 23:05:09 +02:00
|
|
|
|
2006-04-11 14:57:50 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-03-30 15:15:30 +02:00
|
|
|
|
2016-09-22 23:35:42 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-04-15 16:15:17 -07:00
|
|
|
|
2016-09-22 23:35:42 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-02-20 16:51:23 +01:00
|
|
|
|
2009-08-15 08:43:22 +02:00
|
|
|
|
2016-09-22 23:35:42 -04:00
|
|
|
|
2009-08-15 08:43:22 +02:00
|
|
|
|
2016-09-22 23:35:42 -04:00
|
|
|
|
2016-10-10 13:26:27 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-09-22 23:35:42 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-08-15 08:43:22 +02:00
|
|
|
|
2006-03-30 15:15:30 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-04-02 23:06:05 +02:00
|
|
|
|
|
|
|
|
|
2016-09-22 16:33:12 -04:00
|
|
|
|
2009-05-07 15:37:36 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-01-22 19:36:57 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-09-23 15:34:57 -04:00
|
|
|
|
2009-05-07 15:37:36 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-03-03 16:03:58 +01:00
|
|
|
|
2009-05-07 15:37:36 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-09-22 23:35:42 -04:00
|
|
|
|
2009-05-07 15:37:36 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-09-23 15:34:57 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-05-07 15:37:36 +02:00
|
|
|
|
2016-12-10 13:20:53 -05:00
|
|
|
|
2009-05-07 15:37:36 +02:00
|
|
|
|
|
|
|
|
|
2010-05-20 10:43:18 +02:00
|
|
|
|
2016-09-23 15:34:57 -04:00
|
|
|
|
|
|
|
|
|
2010-05-20 10:43:18 +02:00
|
|
|
|
2016-09-23 15:34:57 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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
|
|
|
|
2009-05-07 15:37:36 +02:00
|
|
|
|
2016-09-23 15:34:57 -04:00
|
|
|
|
2009-05-07 15:37:36 +02:00
|
|
|
|
2016-12-10 13:20:53 -05:00
|
|
|
|
2016-09-23 15:34:57 -04:00
|
|
|
|
|
|
|
|
|
2009-05-07 15:37:36 +02:00
|
|
|
|
2016-12-10 13:20:53 -05:00
|
|
|
|
2009-05-07 15:37:36 +02:00
|
|
|
|
2016-09-23 15:34:57 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-05-14 09:49:44 +02:00
|
|
|
|
2009-05-07 15:37:36 +02:00
|
|
|
|
2016-09-23 15:34:57 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-05-07 15:37:36 +02:00
|
|
|
|
|
|
|
|
|
2016-09-23 15:34:57 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-05-07 15:37:36 +02:00
|
|
|
|
2016-09-23 15:34:57 -04:00
|
|
|
|
2009-05-07 15:37:36 +02:00
|
|
|
|
2010-05-20 10:43:18 +02:00
|
|
|
|
|
|
|
|
|
2016-09-23 15:34:57 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-05-07 15:37:36 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-03-30 15:15:30 +02:00
|
|
|
|
2006-04-02 23:04:46 +02:00
|
|
|
|
2006-04-25 15:42:00 +02:00
|
|
|
|
2006-03-30 15:15:30 +02:00
|
|
|
|
2006-05-03 10:41:33 +02:00
|
|
|
|
2006-03-30 15:15:30 +02:00
|
|
|
|
|
|
|
|
|
2007-06-14 13:08:55 +02:00
|
|
|
|
2006-03-30 15:15:30 +02:00
|
|
|
|
2010-12-17 08:56:44 +01:00
|
|
|
|
2006-03-30 15:15:30 +02:00
|
|
|
|
2013-09-22 16:27:52 -04:00
|
|
|
|
2010-12-17 08:56:44 +01:00
|
|
|
|
|
|
|
|
|
2012-04-05 03:05:35 +00:00
|
|
|
|
2013-01-06 18:21:49 +00:00
|
|
|
|
|
|
|
|
|
2012-04-05 03:05:35 +00:00
|
|
|
|
2013-01-06 18:21:49 +00:00
|
|
|
|
2010-12-17 08:56:44 +01:00
|
|
|
|
|
|
|
|
|
2006-03-30 15:15:30 +02:00
|
|
|
|
|
|
|
|
|
2009-04-14 19:48:36 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-06-21 13:10:21 +02:00
|
|
|
|
2009-04-14 19:48:36 +02:00
|
|
|
|
2007-06-21 13:10:21 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-04-14 19:48:36 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-06-21 13:10:21 +02:00
|
|
|
|
2009-04-14 19:48:36 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-04-02 23:05:09 +02:00
|
|
|
|
2014-04-05 04:35:49 -04:00
|
|
|
|
2009-04-14 19:48:36 +02:00
|
|
|
|
2006-03-30 15:15:30 +02:00
|
|
|
|
2009-04-14 19:48:36 +02:00
|
|
|
|
2006-03-30 15:15:30 +02:00
|
|
|
|
2009-04-14 19:48:36 +02:00
|
|
|
|
|
|
|
|
|
2006-03-30 15:15:30 +02:00
|
|
|
|
2009-04-14 19:48:36 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-03-30 15:15:30 +02:00
|
|
|
|
2016-09-27 10:45:12 +02:00
|
|
|
|
2010-12-17 08:56:44 +01:00
|
|
|
|
2009-04-14 19:48:36 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-12-17 08:56:44 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-04-14 19:48:36 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-09-27 10:45:12 +02:00
|
|
|
|
2010-05-20 10:43:18 +02:00
|
|
|
|
2009-04-14 19:48:36 +02:00
|
|
|
|
2013-03-21 11:01:38 -04:00
|
|
|
|
2009-04-14 19:48:36 +02:00
|
|
|
|
|
|
|
|
|
2006-03-30 15:15:30 +02:00
|
|
|
|
2009-04-14 19:48:36 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-03-30 15:15:30 +02:00
|
|
|
|
2009-04-14 19:48:36 +02:00
|
|
|
|
|
|
|
|
|
2006-03-30 15:15:30 +02:00
|
|
|
|
2009-04-14 19:48:36 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-04-05 04:35:49 -04:00
|
|
|
|
2009-04-14 19:48:36 +02:00
|
|
|
|
2015-11-23 13:09:50 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-04-14 19:48:36 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-04-25 15:42:00 +02:00
|
|
|
|
2009-04-14 19:48:36 +02:00
|
|
|
|
|
|
|
|
|
2006-04-11 13:57:21 +02:00
|
|
|
|
2009-04-14 19:48:36 +02:00
|
|
|
|
|
|
|
|
|
2006-03-30 15:15:30 +02:00
|
|
|
|
2009-04-14 19:48:36 +02:00
|
|
|
|
|
|
|
|
|
2006-03-30 15:15:30 +02:00
|
|
|
|
2009-04-14 19:48:36 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-03-30 15:15:30 +02:00
|
|
|
|
|
|
|
|
|
2009-04-14 19:48:36 +02:00
|
|
|
|
|
|
|
|
|
2006-04-02 12:46:35 -07:00
|
|
|
|
2009-04-14 19:48:36 +02:00
|
|
|
|
|
|
|
|
|
2006-03-30 15:15:30 +02:00
|
|
|
|
2009-04-14 19:48:36 +02:00
|
|
|
|
|
|
|
|
|
2009-04-16 19:09:55 -07:00
|
|
|
|
2009-04-14 19:48:36 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-04-05 04:35:49 -04:00
|
|
|
|
2009-04-14 19:48:36 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-03-30 15:15:30 +02:00
|
|
|
|
2009-04-14 19:48:36 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-04-05 04:35:49 -04:00
|
|
|
|
2009-04-14 19:48:36 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-03-30 15:15:30 +02:00
|
|
|
|
2009-04-14 19:48:36 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-03-30 15:15:30 +02:00
|
|
|
|
2009-04-14 19:48:36 +02:00
|
|
|
|
|
|
|
|
|
2015-11-23 13:09:51 +01:00
|
|
|
|
2009-04-14 19:48:36 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-03-30 15:15:30 +02:00
|
|
|
|
2007-03-21 13:11:02 +01:00
|
|
|
|
2006-03-30 15:15:30 +02:00
|
|
|
|
2007-06-21 13:10:21 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-04-14 19:48:37 +02:00
|
|
|
|
2007-06-21 13:10:21 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-10-17 18:43:07 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-06-12 21:17:17 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-06-14 13:08:55 +02:00
|
|
|
|
2007-06-12 21:17:17 +02:00
|
|
|
|
2006-10-17 18:43:07 +02:00
|
|
|
|
2009-04-14 19:48:41 +02:00
|
|
|
|
2007-06-12 21:17:17 +02:00
|
|
|
|
2009-04-14 19:48:41 +02:00
|
|
|
|
2006-10-17 18:43:07 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-04-05 04:27:08 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-09-27 10:45:12 +02:00
|
|
|
|
2014-04-05 04:27:08 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-01-23 01:08:07 -05:00
|
|
|
|
|
|
|
|
|
2017-05-27 11:16:52 +03:00
|
|
|
|
2014-04-05 04:27:08 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-01-25 21:11:59 +01:00
|
|
|
|
2014-04-05 04:27:08 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-09-27 10:45:12 +02:00
|
|
|
|
2014-04-05 04:27:08 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-05-19 11:37:46 +02:00
|
|
|
|
|
|
|
|
|
2009-05-07 15:37:37 +02:00
|
|
|
|
2009-05-19 11:37:46 +02:00
|
|
|
|
|
|
|
|
|
2013-03-20 13:19:30 -04:00
|
|
|
|
2009-05-19 11:37:46 +02:00
|
|
|
|
2014-02-02 21:09:54 -05:00
|
|
|
|
2013-03-20 13:19:30 -04:00
|
|
|
|
2014-02-02 21:09:54 -05:00
|
|
|
|
2009-05-19 11:37:46 +02:00
|
|
|
|
|
|
|
|
|
2009-05-07 15:37:37 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-05-19 11:37:46 +02:00
|
|
|
|
2009-05-07 15:37:37 +02:00
|
|
|
|
2009-05-19 11:37:46 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-05-07 15:37:37 +02:00
|
|
|
|
2009-05-19 11:37:46 +02:00
|
|
|
|
2009-05-07 15:37:37 +02:00
|
|
|
|
|
|
|
|
|
2006-04-02 23:05:09 +02:00
|
|
|
|
|
|
|
|
|
2007-06-21 13:10:21 +02:00
|
|
|
|
2006-04-02 23:05:09 +02:00
|
|
|
|
2007-06-21 13:10:21 +02:00
|
|
|
|
2006-04-02 23:05:09 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-06-21 13:10:21 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-04-02 23:05:09 +02:00
|
|
|
|
|
|
|
|
|
2006-04-10 15:18:35 +02:00
|
|
|
|
2006-04-11 14:57:50 +02:00
|
|
|
|
2006-03-30 15:15:30 +02:00
|
|
|
|
2006-04-26 14:39:29 +02:00
|
|
|
|
2006-03-30 15:15:30 +02:00
|
|
|
|
|
|
|
|
|
2006-04-02 23:06:05 +02:00
|
|
|
|
2006-03-30 23:06:13 -05:00
|
|
|
|
2006-04-02 23:05:09 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-04-10 15:18:35 +02:00
|
|
|
|
2006-04-11 14:57:50 +02:00
|
|
|
|
2006-03-30 15:15:30 +02:00
|
|
|
|
2009-05-07 15:37:37 +02:00
|
|
|
|
|
|
|
|
|
2006-03-30 15:15:30 +02:00
|
|
|
|
2013-09-22 16:27:52 -04:00
|
|
|
|
2009-11-04 09:09:52 +01:00
|
|
|
|
|
|
|
|
|
2009-05-07 15:37:37 +02:00
|
|
|
|
|
|
|
|
|
2013-05-23 20:07:11 -04:00
|
|
|
|
2006-03-30 15:15:30 +02:00
|
|
|
|
|
|
|
|
|
2006-04-02 23:05:09 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-04-11 14:57:50 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-03-30 15:15:30 +02:00
|
|
|
|
2009-05-07 15:37:36 +02:00
|
|
|
|
|
|
|
|
|
2006-03-30 15:15:30 +02:00
|
|
|
|
|
|
|
|
|
2006-04-11 13:56:09 +02:00
|
|
|
|
2006-03-30 15:15:30 +02:00
|
|
|
|
|
|
|
|
|
2006-04-11 14:57:50 +02:00
|
|
|
|
2006-03-30 15:15:30 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-04-02 14:56:58 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-09-22 16:27:52 -04:00
|
|
|
|
2009-11-04 09:09:52 +01:00
|
|
|
|
|
|
|
|
|
2009-05-07 15:37:36 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-03-30 15:15:30 +02:00
|
|
|
|
|
|
|
|
|
2007-06-21 13:10:21 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-07-27 08:08:51 +02:00
|
|
|
|
2007-06-21 13:10:21 +02:00
|
|
|
|
|
|
|
|
|
2007-06-12 21:17:17 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-04-11 13:52:07 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-06-12 21:17:17 +02: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 17:26:47 +02:00
|
|
|
|
2006-04-11 13:52:07 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-01-23 17:07:38 -05:00
|
|
|
|
2006-04-11 13:52:07 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-04-11 13:56:09 +02:00
|
|
|
|
2013-03-21 11:04:15 -04:00
|
|
|
|
2006-04-11 13:52:07 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-04-26 14:39:29 +02:00
|
|
|
|
2006-04-11 13:52:07 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-04-11 13:57:21 +02:00
|
|
|
|
2006-04-11 13:52:07 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-06-12 21:17:17 +02: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 17:26:47 +02:00
|
|
|
|
2006-04-11 13:52:07 +02:00
|
|
|
|
|
|
|
|
|
2007-07-13 14:11:43 +02:00
|
|
|
|
2008-05-09 13:28:36 +02:00
|
|
|
|
2006-04-11 13:52:07 +02:00
|
|
|
|
2007-07-16 14:41:49 +02:00
|
|
|
|
2007-07-13 14:11:43 +02:00
|
|
|
|
2006-04-11 13:52:07 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-06-12 21:17:17 +02:00
|
|
|
|
2006-04-11 13:52:07 +02: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 17:26:47 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-04-11 13:52:07 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-06-12 21:17:17 +02:00
|
|
|
|
2008-05-09 13:28:36 +02:00
|
|
|
|
|
|
|
|
|
2006-04-11 13:52:07 +02:00
|
|
|
|
2008-05-09 13:28:36 +02:00
|
|
|
|
2006-04-11 13:52:07 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-07-16 14:41:49 +02:00
|
|
|
|
2006-04-11 13:52:07 +02:00
|
|
|
|
2008-05-09 13:28:36 +02:00
|
|
|
|
|
|
|
|
|
2007-07-13 14:11:43 +02:00
|
|
|
|
2008-05-09 13:28:36 +02:00
|
|
|
|
2006-04-11 13:52:07 +02:00
|
|
|
|
|
|
|
|
|
2008-01-29 21:05:57 +01:00
|
|
|
|
2006-04-11 13:52:07 +02:00
|
|
|
|
2008-01-30 12:24:48 +01:00
|
|
|
|
2006-04-11 13:52:07 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-05-20 10:43:18 +02:00
|
|
|
|
2006-04-11 13:52:07 +02:00
|
|
|
|
|
|
|
|
|
2016-09-27 10:45:12 +02:00
|
|
|
|
|
|
|
|
|
2006-04-11 13:52:07 +02:00
|
|
|
|
|
|
|
|
|
2008-01-29 21:05:57 +01:00
|
|
|
|
|
|
|
|
|
2007-06-12 21:17:17 +02:00
|
|
|
|
2008-01-29 21:05:57 +01:00
|
|
|
|
2007-06-12 21:17:17 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-06-14 13:08:55 +02:00
|
|
|
|
2007-06-12 21:17:17 +02:00
|
|
|
|
2013-06-20 18:58:36 +04:00
|
|
|
|
2010-06-29 13:09:18 +02:00
|
|
|
|
2007-06-12 21:17:17 +02:00
|
|
|
|
|
|
|
|
|
2007-06-21 13:10:21 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-06-22 19:44:08 -07:00
|
|
|
|
2007-06-21 13:10:21 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-06-12 21:17:17 +02:00
|
|
|
|
2013-06-20 18:58:36 +04:00
|
|
|
|
2007-06-12 21:17:17 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-06-14 13:08:55 +02:00
|
|
|
|
2013-06-20 18:58:36 +04:00
|
|
|
|
2007-06-12 21:17:17 +02:00
|
|
|
|
2007-07-13 14:11:43 +02:00
|
|
|
|
2007-06-12 21:17:17 +02:00
|
|
|
|
2013-06-19 15:41:54 +04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-06-12 21:17:17 +02:00
|
|
|
|
2007-07-13 14:11:43 +02:00
|
|
|
|
2008-05-09 13:28:36 +02:00
|
|
|
|
2007-07-13 14:11:43 +02:00
|
|
|
|
2007-06-12 21:17:17 +02:00
|
|
|
|
2006-04-11 13:52:07 +02:00
|
|
|
|
2014-10-24 00:14:35 +02:00
|
|
|
|
2006-04-11 13:52:07 +02:00
|
|
|
|
2016-09-17 20:44:45 -04:00
|
|
|
|
|
|
|
|
|
2016-12-21 10:59:34 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-09-17 20:44:45 -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 15:37:35 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-11-04 12:49:32 +01:00
|
|
|
|
2006-04-02 23:05:09 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-04-10 15:18:58 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-03-30 15:15:30 +02: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 15:37:35 +02:00
|
|
|
|
|
|
|
|
|
2013-06-20 18:58:36 +04:00
|
|
|
|
2006-04-19 15:57:05 +02:00
|
|
|
|
2006-03-30 15:15:30 +02:00
|
|
|
|
2010-11-28 13:56:09 -08: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 15:37:35 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-04-10 15:18:58 +02:00
|
|
|
|
|
|
|
|
|
2006-04-11 13:52:07 +02:00
|
|
|
|
2010-06-29 13:10:36 +02:00
|
|
|
|
2006-04-11 13:52:07 +02:00
|
|
|
|
2006-04-11 14:57:50 +02:00
|
|
|
|
2006-04-11 13:52:07 +02:00
|
|
|
|
2013-06-20 18:58:36 +04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-04-10 15:18:58 +02:00
|
|
|
|
2013-06-19 15:41:54 +04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-05-23 20:07:11 -04:00
|
|
|
|
2013-06-20 18:58:36 +04:00
|
|
|
|
2013-05-23 20:07:11 -04:00
|
|
|
|
2006-04-19 15:57:05 +02:00
|
|
|
|
2013-06-20 18:58:36 +04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-04-19 15:57:05 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-04-10 15:18:58 +02:00
|
|
|
|
2006-03-30 15:15:30 +02: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 15:37:35 +02:00
|
|
|
|
2006-04-10 15:18:58 +02:00
|
|
|
|
|
|
|
|
|
2006-04-11 13:52:07 +02:00
|
|
|
|
2010-06-29 13:10:36 +02:00
|
|
|
|
2006-04-11 13:52:07 +02:00
|
|
|
|
2006-04-11 14:57:50 +02:00
|
|
|
|
2006-04-11 13:52:07 +02:00
|
|
|
|
2013-06-20 18:58:36 +04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-04-10 15:18:58 +02:00
|
|
|
|
2016-09-17 20:44:45 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-06-20 18:58:36 +04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-04-19 15:57:05 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-04-10 15:18:58 +02:00
|
|
|
|
2006-03-30 15:15:30 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-09-17 22:38:20 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-04-26 10:59:21 +02:00
|
|
|
|
2016-09-17 22:38:20 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-09-17 20:25:06 -04:00
|
|
|
|
|
|
|
|
|
2016-09-17 22:38:20 -04:00
|
|
|
|
2016-09-17 20:25:06 -04:00
|
|
|
|
2016-09-17 22:38:20 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-09-17 20:25:06 -04:00
|
|
|
|
2016-09-17 22:38:20 -04:00
|
|
|
|
2016-09-17 20:25:06 -04:00
|
|
|
|
2016-09-17 22:38:20 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-09-17 20:25:06 -04:00
|
|
|
|
2006-04-26 10:59:21 +02:00
|
|
|
|
|
|
|
|
|
2016-09-17 22:38:20 -04:00
|
|
|
|
2006-04-26 10:59:21 +02:00
|
|
|
|
|
|
|
|
|
2007-06-14 13:08:55 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-02-03 18:19:51 -05:00
|
|
|
|
|
|
|
|
|
2007-06-14 13:08:55 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-02-03 18:19:51 -05:00
|
|
|
|
2007-06-14 13:08:55 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-02-03 18:19:51 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-06-14 13:08:55 +02:00
|
|
|
|
2010-11-28 13:56:09 -08:00
|
|
|
|
2007-06-14 13:08:55 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-03-21 19:17:55 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-06-14 13:08:55 +02:00
|
|
|
|
2015-03-21 19:17:55 -04:00
|
|
|
|
2014-02-03 18:19:51 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-06-14 13:08:55 +02:00
|
|
|
|
2015-03-21 19:17:55 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-06-14 13:08:55 +02:00
|
|
|
|
2015-03-21 19:17:55 -04:00
|
|
|
|
2007-06-14 13:08:55 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-04-26 10:59:21 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-09-17 20:25:06 -04:00
|
|
|
|
2007-06-14 13:08:55 +02:00
|
|
|
|
2006-04-26 10:59:21 +02:00
|
|
|
|
2006-11-04 12:49:32 +01:00
|
|
|
|
2016-09-17 20:25:06 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-05-20 10:43:18 +02:00
|
|
|
|
2016-09-17 22:38:20 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-04-26 10:59:21 +02:00
|
|
|
|
2010-11-28 13:56:09 -08:00
|
|
|
|
2006-11-04 12:49:32 +01:00
|
|
|
|
2006-04-26 10:59:21 +02:00
|
|
|
|
|
|
|
|
|
2016-09-17 20:25:06 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-09-17 20:44:45 -04:00
|
|
|
|
|
|
|
|
|
2016-09-17 22:38:20 -04:00
|
|
|
|
|
|
|
|
|
2016-09-17 20:44:45 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-09-17 20:25:06 -04:00
|
|
|
|
2010-05-20 10:43:18 +02:00
|
|
|
|
2006-04-26 10:59:21 +02:00
|
|
|
|
|
|
|
|
|
2007-06-14 13:08:55 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-01-14 14:14:33 +01:00
|
|
|
|
|
|
|
|
|
2006-04-26 10:59:21 +02:00
|
|
|
|
2012-08-28 12:52:22 -04:00
|
|
|
|
2006-04-26 10:59:21 +02:00
|
|
|
|
|
|
|
|
|
2016-12-10 13:17:32 -05:00
|
|
|
|
|
|
|
|
|
2007-06-14 13:08:55 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-04-26 10:59:21 +02:00
|
|
|
|
2012-08-28 12:52:22 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-04-26 10:59:21 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-03-02 10:19:56 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-01-14 14:14:33 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-03-30 15:15:30 +02:00
|
|
|
|
2012-08-28 12:52:22 -04:00
|
|
|
|
2006-03-30 15:15:30 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-12-10 13:17:32 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-03-30 15:15:30 +02:00
|
|
|
|
2012-08-28 12:52:22 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-04-10 15:18:58 +02:00
|
|
|
|
2012-08-28 12:52:22 -04:00
|
|
|
|
2006-03-30 15:15:30 +02:00
|
|
|
|
|
|
|
|
|
2012-08-28 12:52:22 -04:00
|
|
|
|
2006-03-30 15:15:30 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-04-11 15:51:17 +02:00
|
|
|
|
2006-07-10 11:00:01 +02: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 15:37:35 +02:00
|
|
|
|
2006-07-10 11:00:01 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-04-14 19:48:41 +02:00
|
|
|
|
2006-07-10 11:00:01 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-04-14 19:48:41 +02:00
|
|
|
|
2006-07-10 11:00:01 +02: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 15:37:35 +02:00
|
|
|
|
2006-07-10 11:00:01 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-05-20 10:43:18 +02:00
|
|
|
|
2006-07-10 11:00:01 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-04-14 19:48:41 +02:00
|
|
|
|
2006-07-10 11:00:01 +02:00
|
|
|
|
2010-05-20 10:43:18 +02:00
|
|
|
|
2006-07-10 11:00:01 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-04-14 19:48:41 +02:00
|
|
|
|
2006-07-10 11:00:01 +02: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 15:37:35 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-05-20 10:43:18 +02: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 15:37:35 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-05-20 10:43:18 +02: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 15:37:35 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-05-20 10:43:18 +02: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 15:37:35 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-09-27 10:45:12 +02: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 15:37:35 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-05-23 19:58:53 +02: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 15:37:35 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-04-11 15:51:17 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-07-10 11:00:01 +02:00
|
|
|
|
2006-04-11 15:51:17 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-04-14 19:48:41 +02:00
|
|
|
|
2006-04-11 15:51:17 +02:00
|
|
|
|
|
|
|
|
|
2009-04-14 19:48:41 +02:00
|
|
|
|
2006-04-11 15:51:17 +02:00
|
|
|
|
2006-07-10 11:00:01 +02:00
|
|
|
|
2006-04-11 15:51:17 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-07-10 11:00:01 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-05-20 10:43:18 +02:00
|
|
|
|
2006-07-10 11:00:01 +02:00
|
|
|
|
2006-04-11 15:51:17 +02:00
|
|
|
|
2010-05-20 10:43:18 +02:00
|
|
|
|
|
|
|
|
|
2006-04-11 15:51:17 +02:00
|
|
|
|
|
|
|
|
|
2006-07-10 11:00:01 +02:00
|
|
|
|
|
|
|
|
|
2006-04-11 15:51:17 +02:00
|
|
|
|
2016-09-27 10:45:12 +02:00
|
|
|
|
2006-07-10 11:00:01 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-04-19 15:56:40 +02:00
|
|
|
|
2006-07-10 11:00:01 +02:00
|
|
|
|
|
|
|
|
|
2006-04-19 15:56:40 +02:00
|
|
|
|
2006-07-10 11:00:01 +02:00
|
|
|
|
2006-04-11 15:51:17 +02:00
|
|
|
|
2006-07-10 11:00:01 +02:00
|
|
|
|
|
|
|
|
|
2006-04-11 15:51:17 +02:00
|
|
|
|
2006-07-10 11:00:01 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-04-11 15:51:17 +02:00
|
|
|
|
2008-02-20 10:34:51 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-04-14 19:48:41 +02:00
|
|
|
|
|
|
|
|
|
2006-04-11 15:51:17 +02:00
|
|
|
|
2006-07-10 11:00:01 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-05-23 19:58:53 +02:00
|
|
|
|
|
|
|
|
|
2006-04-11 15:51:17 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-11-28 13:56:09 -08:00
|
|
|
|
|
|
|
|
|
2006-07-10 11:00:01 +02:00
|
|
|
|
2006-04-11 15:51:17 +02:00
|
|
|
|
|
|
|
|
|
2006-07-10 11:00:01 +02:00
|
|
|
|
|
|
|
|
|
2006-04-11 15:51:17 +02:00
|
|
|
|
2006-07-10 11:00:01 +02: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 15:37:35 +02:00
|
|
|
|
2006-07-10 11:00:01 +02: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 15:37:35 +02:00
|
|
|
|
2008-02-20 10:34:51 +01:00
|
|
|
|
2006-07-10 11:00:01 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-04-11 15:51:17 +02:00
|
|
|
|
2006-07-10 11:00:01 +02:00
|
|
|
|
2006-04-11 15:51:17 +02:00
|
|
|
|
|
|
|
|
|
2009-01-14 14:14:33 +01:00
|
|
|
|
2006-04-11 15:51:17 +02:00
|
|
|
|
2012-08-28 12:52:22 -04:00
|
|
|
|
|
|
|
|
|
2006-04-11 15:51:17 +02:00
|
|
|
|
2016-12-10 13:17:32 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-04-11 15:51:17 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-08-28 12:52:22 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-04-11 15:51:17 +02:00
|
|
|
|
|
|
|
|
|
2012-08-28 12:52:22 -04:00
|
|
|
|
2006-04-11 15:51:17 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|