2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-05-20 10:43:18 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2012-03-23 15:01:50 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-03-30 15:15:30 +02:00
|
|
|
|
2007-02-07 01:48:00 -05:00
|
|
|
|
2008-05-06 20:42:38 -07:00
|
|
|
|
2010-05-19 21:03:16 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-03-12 09:58:10 -04:00
|
|
|
|
|
|
|
|
|
2010-05-19 21:03:16 +02:00
|
|
|
|
|
|
|
|
|
2010-06-03 14:54:39 +02:00
|
|
|
|
2010-05-19 21:03:16 +02:00
|
|
|
|
2010-06-03 14:54:39 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-05-19 21:03:16 +02:00
|
|
|
|
2016-01-18 16:36:09 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-04-14 19:48:41 +02:00
|
|
|
|
|
|
|
|
|
2013-03-21 11:01:38 -04:00
|
|
|
|
2013-03-21 02:32:24 -04:00
|
|
|
|
2009-04-14 19:48:41 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-03-21 11:01:38 -04:00
|
|
|
|
2013-03-21 02:32:24 -04:00
|
|
|
|
2009-04-14 19:48:41 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-03-21 12:24:01 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-04-14 19:48:41 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-07-21 10:09:23 +02:00
|
|
|
|
|
|
|
|
|
2009-04-14 19:48:41 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2006-04-10 15:18:35 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-09-10 00:26:12 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-10-15 17:00:13 +02:00
|
|
|
|
2009-04-14 19:48:41 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2006-04-10 15:18:35 +02:00
|
|
|
|
2009-04-14 19:48:41 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2006-04-11 13:57:45 +02:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-03-30 15:15:30 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-04-11 13:57:45 +02:00
|
|
|
|
2006-03-30 15:15:30 +02:00
|
|
|
|
2006-04-11 13:57:45 +02:00
|
|
|
|
2006-04-11 13:53:33 +02:00
|
|
|
|
2006-04-11 13:57:45 +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
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2007-06-12 20:51:32 +02:00
|
|
|
|
2008-02-13 15:03:22 -08:00
|
|
|
|
2007-06-12 20:51:32 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-02-13 15:03:22 -08:00
|
|
|
|
2007-06-12 20:51:32 +02:00
|
|
|
|
|
|
|
|
|
2008-02-13 15:03:22 -08:00
|
|
|
|
2007-06-12 20:51:32 +02:00
|
|
|
|
|
|
|
|
|
2006-05-02 15:29:57 +02:00
|
|
|
|
|
|
|
|
|
2006-03-30 15:16:46 +02:00
|
|
|
|
2006-04-30 16:36:32 +02:00
|
|
|
|
|
|
|
|
|
2007-06-12 20:51:32 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-04-30 16:36:32 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-03-30 15:16:46 +02:00
|
|
|
|
2010-05-26 08:44:22 +02:00
|
|
|
|
2006-03-30 15:16:46 +02:00
|
|
|
|
2007-06-12 20:51:32 +02:00
|
|
|
|
2008-02-13 15:03:22 -08:00
|
|
|
|
2007-06-12 20:51:32 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-04-11 15:51:17 +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-04-11 15:51:17 +02:00
|
|
|
|
2010-05-26 08:44:22 +02:00
|
|
|
|
2006-04-11 15:51:17 +02:00
|
|
|
|
2007-06-12 20:51:32 +02:00
|
|
|
|
|
|
|
|
|
2007-07-27 08:08:51 +02:00
|
|
|
|
2007-06-12 20:51:32 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-06-14 13:10:48 +02:00
|
|
|
|
|
|
|
|
|
2006-05-01 19:59:03 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-05-26 08:44:22 +02:00
|
|
|
|
2006-05-01 19:59:03 +02:00
|
|
|
|
2009-05-07 15:37:36 +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
|
|
|
|
2009-05-07 15:37:36 +02:00
|
|
|
|
2010-05-26 08:44:22 +02:00
|
|
|
|
2009-05-07 15:37:36 +02:00
|
|
|
|
2006-12-13 00:34:04 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2007-06-14 13:10:48 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2006-05-02 15:29:57 +02:00
|
|
|
|
2006-05-01 19:59:03 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
pipes: add a "packetized pipe" mode for writing
The actual internal pipe implementation is already really about
individual packets (called "pipe buffers"), and this simply exposes that
as a special packetized mode.
When we are in the packetized mode (marked by O_DIRECT as suggested by
Alan Cox), a write() on a pipe will not merge the new data with previous
writes, so each write will get a pipe buffer of its own. The pipe
buffer is then marked with the PIPE_BUF_FLAG_PACKET flag, which in turn
will tell the reader side to break the read at that boundary (and throw
away any partial packet contents that do not fit in the read buffer).
End result: as long as you do writes less than PIPE_BUF in size (so that
the pipe doesn't have to split them up), you can now treat the pipe as a
packet interface, where each read() system call will read one packet at
a time. You can just use a sufficiently big read buffer (PIPE_BUF is
sufficient, since bigger than that doesn't guarantee atomicity anyway),
and the return value of the read() will naturally give you the size of
the packet.
NOTE! We do not support zero-sized packets, and zero-sized reads and
writes to a pipe continue to be no-ops. Also note that big packets will
currently be split at write time, but that the size at which that
happens is not really specified (except that it's bigger than PIPE_BUF).
Currently that limit is the system page size, but we might want to
explicitly support bigger packets some day.
The main user for this is going to be the autofs packet interface,
allowing us to stop having to care so deeply about exact packet sizes
(which have had bugs with 32/64-bit compatibility modes). But user
space can create packetized pipes with "pipe2(fd, O_DIRECT)", which will
fail with an EINVAL on kernels that do not support this interface.
Tested-by: Michael Tokarev <mjt@tls.msk.ru>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: David Miller <davem@davemloft.net>
Cc: Ian Kent <raven@themaw.net>
Cc: Thomas Meyer <thomas@m3y3r.de>
Cc: stable@kernel.org # needed for systemd/autofs interaction fix
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2012-04-29 13:12:42 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2014-04-02 19:56:54 -04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2014-04-02 19:56:54 -04:00
|
|
|
|
2006-09-30 23:28:47 -07:00
|
|
|
|
2013-03-21 11:16:56 -04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-03-21 12:24:01 -04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2006-04-11 13:53:33 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2006-04-11 13:53:33 +02:00
|
|
|
|
|
|
|
|
|
2006-12-13 00:34:04 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2014-02-03 19:11:42 -05:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-06-14 13:10:48 +02:00
|
|
|
|
2006-05-01 19:59:03 +02:00
|
|
|
|
2006-03-30 15:15:30 +02:00
|
|
|
|
2010-10-21 14:56:00 +02:00
|
|
|
|
2006-03-30 15:15:30 +02:00
|
|
|
|
|
|
|
|
|
2006-05-01 19:59:03 +02:00
|
|
|
|
2014-04-02 19:56:54 -04:00
|
|
|
|
2014-02-03 19:11:42 -05:00
|
|
|
|
2006-04-11 13:57:45 +02:00
|
|
|
|
2014-02-03 19:11:42 -05:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
pipes: add a "packetized pipe" mode for writing
The actual internal pipe implementation is already really about
individual packets (called "pipe buffers"), and this simply exposes that
as a special packetized mode.
When we are in the packetized mode (marked by O_DIRECT as suggested by
Alan Cox), a write() on a pipe will not merge the new data with previous
writes, so each write will get a pipe buffer of its own. The pipe
buffer is then marked with the PIPE_BUF_FLAG_PACKET flag, which in turn
will tell the reader side to break the read at that boundary (and throw
away any partial packet contents that do not fit in the read buffer).
End result: as long as you do writes less than PIPE_BUF in size (so that
the pipe doesn't have to split them up), you can now treat the pipe as a
packet interface, where each read() system call will read one packet at
a time. You can just use a sufficiently big read buffer (PIPE_BUF is
sufficient, since bigger than that doesn't guarantee atomicity anyway),
and the return value of the read() will naturally give you the size of
the packet.
NOTE! We do not support zero-sized packets, and zero-sized reads and
writes to a pipe continue to be no-ops. Also note that big packets will
currently be split at write time, but that the size at which that
happens is not really specified (except that it's bigger than PIPE_BUF).
Currently that limit is the system page size, but we might want to
explicitly support bigger packets some day.
The main user for this is going to be the autofs packet interface,
allowing us to stop having to care so deeply about exact packet sizes
(which have had bugs with 32/64-bit compatibility modes). But user
space can create packetized pipes with "pipe2(fd, O_DIRECT)", which will
fail with an EINVAL on kernels that do not support this interface.
Tested-by: Michael Tokarev <mjt@tls.msk.ru>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: David Miller <davem@davemloft.net>
Cc: Ian Kent <raven@themaw.net>
Cc: Thomas Meyer <thomas@m3y3r.de>
Cc: stable@kernel.org # needed for systemd/autofs interaction fix
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2012-04-29 13:12:42 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2006-04-11 13:53:33 +02:00
|
|
|
|
2010-05-20 10:43:18 +02:00
|
|
|
|
2006-04-11 13:53:33 +02:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-04-11 13:53:33 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2006-04-11 13:53:33 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-04-11 13:57:45 +02:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-01-20 16:21:59 -08:00
|
|
|
|
2006-04-11 13:53:33 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2006-04-11 13:53:33 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2013-03-21 12:24:01 -04:00
|
|
|
|
2006-04-11 13:57:45 +02:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2011-01-20 16:21:59 -08:00
|
|
|
|
2006-04-11 13:53:33 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
pipes: add a "packetized pipe" mode for writing
The actual internal pipe implementation is already really about
individual packets (called "pipe buffers"), and this simply exposes that
as a special packetized mode.
When we are in the packetized mode (marked by O_DIRECT as suggested by
Alan Cox), a write() on a pipe will not merge the new data with previous
writes, so each write will get a pipe buffer of its own. The pipe
buffer is then marked with the PIPE_BUF_FLAG_PACKET flag, which in turn
will tell the reader side to break the read at that boundary (and throw
away any partial packet contents that do not fit in the read buffer).
End result: as long as you do writes less than PIPE_BUF in size (so that
the pipe doesn't have to split them up), you can now treat the pipe as a
packet interface, where each read() system call will read one packet at
a time. You can just use a sufficiently big read buffer (PIPE_BUF is
sufficient, since bigger than that doesn't guarantee atomicity anyway),
and the return value of the read() will naturally give you the size of
the packet.
NOTE! We do not support zero-sized packets, and zero-sized reads and
writes to a pipe continue to be no-ops. Also note that big packets will
currently be split at write time, but that the size at which that
happens is not really specified (except that it's bigger than PIPE_BUF).
Currently that limit is the system page size, but we might want to
explicitly support bigger packets some day.
The main user for this is going to be the autofs packet interface,
allowing us to stop having to care so deeply about exact packet sizes
(which have had bugs with 32/64-bit compatibility modes). But user
space can create packetized pipes with "pipe2(fd, O_DIRECT)", which will
fail with an EINVAL on kernels that do not support this interface.
Tested-by: Michael Tokarev <mjt@tls.msk.ru>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: David Miller <davem@davemloft.net>
Cc: Ian Kent <raven@themaw.net>
Cc: Thomas Meyer <thomas@m3y3r.de>
Cc: stable@kernel.org # needed for systemd/autofs interaction fix
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2012-04-29 13:12:42 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2014-04-03 15:05:18 -04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2006-09-30 23:28:47 -07:00
|
|
|
|
2013-03-21 11:16:56 -04:00
|
|
|
|
2014-04-03 15:05:18 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-03-21 12:24:01 -04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2006-04-11 13:53:33 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-04-11 13:53:33 +02:00
|
|
|
|
2006-04-11 13:57:45 +02:00
|
|
|
|
2010-05-20 10:43:18 +02:00
|
|
|
|
2006-04-11 13:53:33 +02:00
|
|
|
|
2006-12-13 00:34:04 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2006-04-11 13:57:45 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2015-10-17 16:26:09 -05:00
|
|
|
|
|
|
|
|
|
2006-03-30 15:15:30 +02:00
|
|
|
|
2006-05-01 19:59:03 +02:00
|
|
|
|
2014-04-03 15:05:18 -04:00
|
|
|
|
|
|
|
|
|
2015-10-17 16:26:09 -05:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2006-05-01 20:02:05 +02:00
|
|
|
|
2014-04-03 15:05:18 -04:00
|
|
|
|
2015-10-17 16:26:09 -05:00
|
|
|
|
2014-04-03 15:05:18 -04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-04-11 13:57:45 +02:00
|
|
|
|
2006-04-11 13:53:33 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2006-04-11 13:57:45 +02:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2006-04-11 13:53:33 +02:00
|
|
|
|
2010-05-20 10:43:18 +02:00
|
|
|
|
|
|
|
|
|
2006-04-11 13:53:33 +02:00
|
|
|
|
|
|
|
|
|
2014-04-03 15:05:18 -04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-04-11 13:53:33 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2006-04-11 13:57:45 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-04-03 15:05:18 -04:00
|
|
|
|
|
|
|
|
|
2006-04-11 13:57:45 +02:00
|
|
|
|
2014-04-03 15:05:18 -04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2014-04-03 15:05:18 -04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-04-03 15:05:18 -04:00
|
|
|
|
pipes: add a "packetized pipe" mode for writing
The actual internal pipe implementation is already really about
individual packets (called "pipe buffers"), and this simply exposes that
as a special packetized mode.
When we are in the packetized mode (marked by O_DIRECT as suggested by
Alan Cox), a write() on a pipe will not merge the new data with previous
writes, so each write will get a pipe buffer of its own. The pipe
buffer is then marked with the PIPE_BUF_FLAG_PACKET flag, which in turn
will tell the reader side to break the read at that boundary (and throw
away any partial packet contents that do not fit in the read buffer).
End result: as long as you do writes less than PIPE_BUF in size (so that
the pipe doesn't have to split them up), you can now treat the pipe as a
packet interface, where each read() system call will read one packet at
a time. You can just use a sufficiently big read buffer (PIPE_BUF is
sufficient, since bigger than that doesn't guarantee atomicity anyway),
and the return value of the read() will naturally give you the size of
the packet.
NOTE! We do not support zero-sized packets, and zero-sized reads and
writes to a pipe continue to be no-ops. Also note that big packets will
currently be split at write time, but that the size at which that
happens is not really specified (except that it's bigger than PIPE_BUF).
Currently that limit is the system page size, but we might want to
explicitly support bigger packets some day.
The main user for this is going to be the autofs packet interface,
allowing us to stop having to care so deeply about exact packet sizes
(which have had bugs with 32/64-bit compatibility modes). But user
space can create packetized pipes with "pipe2(fd, O_DIRECT)", which will
fail with an EINVAL on kernels that do not support this interface.
Tested-by: Michael Tokarev <mjt@tls.msk.ru>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: David Miller <davem@davemloft.net>
Cc: Ian Kent <raven@themaw.net>
Cc: Thomas Meyer <thomas@m3y3r.de>
Cc: stable@kernel.org # needed for systemd/autofs interaction fix
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2012-04-29 13:12:42 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-04-11 13:53:33 +02:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2014-04-03 15:05:18 -04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2010-05-20 10:43:18 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2006-04-11 13:57:45 +02:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-04-11 13:57:45 +02:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-01-20 16:21:59 -08:00
|
|
|
|
2006-04-11 13:53:33 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2006-04-11 13:53:33 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2013-03-21 12:24:01 -04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2011-01-20 16:21:59 -08:00
|
|
|
|
2006-04-11 13:53:33 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2014-01-23 15:55:21 -08:00
|
|
|
|
2012-03-26 09:59:21 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-01-23 15:55:21 -08:00
|
|
|
|
2012-03-26 09:59:21 -04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-02-08 04:21:23 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2013-03-21 11:16:56 -04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-03-21 12:24:01 -04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2006-04-11 13:53:33 +02:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2006-04-11 13:53:33 +02:00
|
|
|
|
2010-05-20 10:43:18 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2013-03-21 12:24:01 -04:00
|
|
|
|
2006-04-11 13:53:33 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2012-05-25 11:39:13 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-03-21 11:16:56 -04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2006-04-11 13:53:33 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2006-04-11 13:53:33 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-04-11 13:53:33 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-05-20 10:43:18 +02:00
|
|
|
|
2005-09-06 15:17:48 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-04-11 13:53:33 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
vfs: fix subtle use-after-free of pipe_inode_info
The pipe code was trying (and failing) to be very careful about freeing
the pipe info only after the last access, with a pattern like:
spin_lock(&inode->i_lock);
if (!--pipe->files) {
inode->i_pipe = NULL;
kill = 1;
}
spin_unlock(&inode->i_lock);
__pipe_unlock(pipe);
if (kill)
free_pipe_info(pipe);
where the final freeing is done last.
HOWEVER. The above is actually broken, because while the freeing is
done at the end, if we have two racing processes releasing the pipe
inode info, the one that *doesn't* free it will decrement the ->files
count, and unlock the inode i_lock, but then still use the
"pipe_inode_info" afterwards when it does the "__pipe_unlock(pipe)".
This is *very* hard to trigger in practice, since the race window is
very small, and adding debug options seems to just hide it by slowing
things down.
Simon originally reported this way back in July as an Oops in
kmem_cache_allocate due to a single bit corruption (due to the final
"spin_unlock(pipe->mutex.wait_lock)" incrementing a field in a different
allocation that had re-used the free'd pipe-info), it's taken this long
to figure out.
Since the 'pipe->files' accesses aren't even protected by the pipe lock
(we very much use the inode lock for that), the simple solution is to
just drop the pipe lock early. And since there were two users of this
pattern, create a helper function for it.
Introduced commit ba5bb147330a ("pipe: take allocation and freeing of
pipe_inode_info out of ->i_mutex").
Reported-by: Simon Kirby <sim@hostway.ca>
Reported-by: Ian Applegate <ia@cloudflare.com>
Acked-by: Al Viro <viro@zeniv.linux.org.uk>
Cc: stable@kernel.org # v3.10+
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2013-12-02 09:44:51 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2013-03-12 09:58:10 -04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
vfs: fix subtle use-after-free of pipe_inode_info
The pipe code was trying (and failing) to be very careful about freeing
the pipe info only after the last access, with a pattern like:
spin_lock(&inode->i_lock);
if (!--pipe->files) {
inode->i_pipe = NULL;
kill = 1;
}
spin_unlock(&inode->i_lock);
__pipe_unlock(pipe);
if (kill)
free_pipe_info(pipe);
where the final freeing is done last.
HOWEVER. The above is actually broken, because while the freeing is
done at the end, if we have two racing processes releasing the pipe
inode info, the one that *doesn't* free it will decrement the ->files
count, and unlock the inode i_lock, but then still use the
"pipe_inode_info" afterwards when it does the "__pipe_unlock(pipe)".
This is *very* hard to trigger in practice, since the race window is
very small, and adding debug options seems to just hide it by slowing
things down.
Simon originally reported this way back in July as an Oops in
kmem_cache_allocate due to a single bit corruption (due to the final
"spin_unlock(pipe->mutex.wait_lock)" incrementing a field in a different
allocation that had re-used the free'd pipe-info), it's taken this long
to figure out.
Since the 'pipe->files' accesses aren't even protected by the pipe lock
(we very much use the inode lock for that), the simple solution is to
just drop the pipe lock early. And since there were two users of this
pattern, create a helper function for it.
Introduced commit ba5bb147330a ("pipe: take allocation and freeing of
pipe_inode_info out of ->i_mutex").
Reported-by: Simon Kirby <sim@hostway.ca>
Reported-by: Ian Applegate <ia@cloudflare.com>
Acked-by: Al Viro <viro@zeniv.linux.org.uk>
Cc: stable@kernel.org # v3.10+
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2013-12-02 09:44:51 -08:00
|
|
|
|
2006-04-11 13:53:33 +02:00
|
|
|
|
2013-03-21 12:24:01 -04:00
|
|
|
|
2013-03-12 09:58:10 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-04-11 13:57:45 +02:00
|
|
|
|
2013-03-21 02:21:19 -04:00
|
|
|
|
2011-01-20 16:21:59 -08:00
|
|
|
|
2006-04-11 13:53:33 +02:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2013-03-21 12:24:01 -04:00
|
|
|
|
2013-03-21 02:21:19 -04:00
|
|
|
|
vfs: fix subtle use-after-free of pipe_inode_info
The pipe code was trying (and failing) to be very careful about freeing
the pipe info only after the last access, with a pattern like:
spin_lock(&inode->i_lock);
if (!--pipe->files) {
inode->i_pipe = NULL;
kill = 1;
}
spin_unlock(&inode->i_lock);
__pipe_unlock(pipe);
if (kill)
free_pipe_info(pipe);
where the final freeing is done last.
HOWEVER. The above is actually broken, because while the freeing is
done at the end, if we have two racing processes releasing the pipe
inode info, the one that *doesn't* free it will decrement the ->files
count, and unlock the inode i_lock, but then still use the
"pipe_inode_info" afterwards when it does the "__pipe_unlock(pipe)".
This is *very* hard to trigger in practice, since the race window is
very small, and adding debug options seems to just hide it by slowing
things down.
Simon originally reported this way back in July as an Oops in
kmem_cache_allocate due to a single bit corruption (due to the final
"spin_unlock(pipe->mutex.wait_lock)" incrementing a field in a different
allocation that had re-used the free'd pipe-info), it's taken this long
to figure out.
Since the 'pipe->files' accesses aren't even protected by the pipe lock
(we very much use the inode lock for that), the simple solution is to
just drop the pipe lock early. And since there were two users of this
pattern, create a helper function for it.
Introduced commit ba5bb147330a ("pipe: take allocation and freeing of
pipe_inode_info out of ->i_mutex").
Reported-by: Simon Kirby <sim@hostway.ca>
Reported-by: Ian Applegate <ia@cloudflare.com>
Acked-by: Al Viro <viro@zeniv.linux.org.uk>
Cc: stable@kernel.org # v3.10+
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2013-12-02 09:44:51 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-03-12 09:58:10 -04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2013-03-21 11:16:56 -04:00
|
|
|
|
2013-03-12 09:58:10 -04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2013-03-21 12:24:01 -04:00
|
|
|
|
2013-03-12 09:58:10 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-04-11 13:57:45 +02:00
|
|
|
|
2013-03-12 09:58:10 -04:00
|
|
|
|
|
|
|
|
|
2009-03-12 14:31:28 -07:00
|
|
|
|
|
|
|
|
|
2013-03-21 12:24:01 -04:00
|
|
|
|
2009-02-01 14:52:56 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2016-01-18 16:36:09 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-03-21 11:04:15 -04:00
|
|
|
|
2006-04-10 15:18:35 +02:00
|
|
|
|
2006-04-11 13:53:33 +02:00
|
|
|
|
2006-04-10 15:18:35 +02:00
|
|
|
|
2006-04-11 13:53:33 +02:00
|
|
|
|
|
|
|
|
|
2016-01-18 16:36:09 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-05-20 10:43:18 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-01-18 16:36:09 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-03-21 02:32:24 -04:00
|
|
|
|
2010-05-20 10:43:18 +02:00
|
|
|
|
|
|
|
|
|
2016-01-18 16:36:09 +01:00
|
|
|
|
2010-05-20 10:43:18 +02:00
|
|
|
|
2006-04-10 15:18:35 +02:00
|
|
|
|
|
|
|
|
|
2010-05-20 10:43:18 +02:00
|
|
|
|
2006-04-10 15:18:35 +02:00
|
|
|
|
|
|
|
|
|
2013-03-21 11:06:46 -04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-01-18 16:36:09 +01:00
|
|
|
|
|
|
|
|
|
2010-05-20 10:43:18 +02:00
|
|
|
|
2006-04-11 13:53:33 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2006-04-11 13:53:33 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2006-04-11 13:53:33 +02:00
|
|
|
|
|
|
|
|
|
2010-05-20 10:43:18 +02:00
|
|
|
|
2006-04-11 13:53:33 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2006-03-26 01:37:24 -08:00
|
|
|
|
2006-04-11 13:57:45 +02:00
|
|
|
|
2007-05-08 00:26:18 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-03-17 22:26:12 +00:00
|
|
|
|
2007-05-08 00:26:18 -07:00
|
|
|
|
|
|
|
|
|
2009-02-20 06:02:22 +00:00
|
|
|
|
2007-05-08 00:26:18 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-07-26 11:36:34 +02:00
|
|
|
|
2006-04-11 13:53:33 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-10-23 11:19:54 -04:00
|
|
|
|
|
|
|
|
|
2013-03-21 11:04:15 -04:00
|
|
|
|
2006-04-11 13:53:33 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2006-04-10 15:18:35 +02:00
|
|
|
|
2013-03-21 02:21:19 -04:00
|
|
|
|
|
|
|
|
|
2006-04-11 13:53:33 +02:00
|
|
|
|
2013-03-12 09:58:10 -04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-11-14 10:39:05 +11:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2006-04-11 13:53:33 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-04-11 13:57:45 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-07-21 15:33:25 +04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2006-09-30 23:29:26 -07:00
|
|
|
|
2012-07-21 15:33:25 +04:00
|
|
|
|
2006-09-30 23:29:26 -07:00
|
|
|
|
2009-08-09 00:52:35 +04:00
|
|
|
|
2012-07-21 15:33:25 +04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2012-07-21 15:33:25 +04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2006-09-30 23:29:26 -07:00
|
|
|
|
2011-01-07 17:50:07 +11:00
|
|
|
|
2009-08-09 00:52:35 +04:00
|
|
|
|
2006-09-30 23:29:26 -07:00
|
|
|
|
2009-08-09 00:52:35 +04:00
|
|
|
|
2006-04-11 13:57:45 +02:00
|
|
|
|
2009-08-09 00:52:35 +04:00
|
|
|
|
2008-02-15 14:37:26 -08:00
|
|
|
|
2013-03-12 09:58:10 -04:00
|
|
|
|
fs/pipe.c: preserve alloc_file() error code
If sys_pipe() was unable to allocate a 'struct file', it always failed
with ENFILE, which means "The number of simultaneously open files in the
system would exceed a system-imposed limit." However, alloc_file()
actually returns an ERR_PTR value and might fail with other error codes.
Currently, in addition to ENFILE, it can fail with ENOMEM, potentially
when there are few open files in the system. Update sys_pipe() to
preserve this error code.
In a prior submission of a similar patch (1) some concern was raised
about introducing a new error code for sys_pipe(). However, for most
system calls, programs cannot assume that new error codes will never be
introduced. In addition, ENOMEM was, in fact, already a possible error
code for sys_pipe(), in the case where the file descriptor table could
not be expanded due to insufficient memory.
(1) http://comments.gmane.org/gmane.linux.kernel/1357942
Signed-off-by: Eric Biggers <ebiggers3@gmail.com>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2015-10-17 16:26:08 -05:00
|
|
|
|
|
|
|
|
|
2008-02-15 14:37:26 -08:00
|
|
|
|
fs/pipe.c: preserve alloc_file() error code
If sys_pipe() was unable to allocate a 'struct file', it always failed
with ENFILE, which means "The number of simultaneously open files in the
system would exceed a system-imposed limit." However, alloc_file()
actually returns an ERR_PTR value and might fail with other error codes.
Currently, in addition to ENFILE, it can fail with ENOMEM, potentially
when there are few open files in the system. Update sys_pipe() to
preserve this error code.
In a prior submission of a similar patch (1) some concern was raised
about introducing a new error code for sys_pipe(). However, for most
system calls, programs cannot assume that new error codes will never be
introduced. In addition, ENOMEM was, in fact, already a possible error
code for sys_pipe(), in the case where the file descriptor table could
not be expanded due to insufficient memory.
(1) http://comments.gmane.org/gmane.linux.kernel/1357942
Signed-off-by: Eric Biggers <ebiggers3@gmail.com>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2015-10-17 16:26:08 -05:00
|
|
|
|
2006-04-11 13:57:45 +02:00
|
|
|
|
pipes: add a "packetized pipe" mode for writing
The actual internal pipe implementation is already really about
individual packets (called "pipe buffers"), and this simply exposes that
as a special packetized mode.
When we are in the packetized mode (marked by O_DIRECT as suggested by
Alan Cox), a write() on a pipe will not merge the new data with previous
writes, so each write will get a pipe buffer of its own. The pipe
buffer is then marked with the PIPE_BUF_FLAG_PACKET flag, which in turn
will tell the reader side to break the read at that boundary (and throw
away any partial packet contents that do not fit in the read buffer).
End result: as long as you do writes less than PIPE_BUF in size (so that
the pipe doesn't have to split them up), you can now treat the pipe as a
packet interface, where each read() system call will read one packet at
a time. You can just use a sufficiently big read buffer (PIPE_BUF is
sufficient, since bigger than that doesn't guarantee atomicity anyway),
and the return value of the read() will naturally give you the size of
the packet.
NOTE! We do not support zero-sized packets, and zero-sized reads and
writes to a pipe continue to be no-ops. Also note that big packets will
currently be split at write time, but that the size at which that
happens is not really specified (except that it's bigger than PIPE_BUF).
Currently that limit is the system page size, but we might want to
explicitly support bigger packets some day.
The main user for this is going to be the autofs packet interface,
allowing us to stop having to care so deeply about exact packet sizes
(which have had bugs with 32/64-bit compatibility modes). But user
space can create packetized pipes with "pipe2(fd, O_DIRECT)", which will
fail with an EINVAL on kernels that do not support this interface.
Tested-by: Michael Tokarev <mjt@tls.msk.ru>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: David Miller <davem@davemloft.net>
Cc: Ian Kent <raven@themaw.net>
Cc: Thomas Meyer <thomas@m3y3r.de>
Cc: stable@kernel.org # needed for systemd/autofs interaction fix
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2012-04-29 13:12:42 -07:00
|
|
|
|
2013-03-21 11:16:56 -04:00
|
|
|
|
2006-09-30 23:29:26 -07:00
|
|
|
|
2013-03-12 09:58:10 -04:00
|
|
|
|
fs/pipe.c: preserve alloc_file() error code
If sys_pipe() was unable to allocate a 'struct file', it always failed
with ENFILE, which means "The number of simultaneously open files in the
system would exceed a system-imposed limit." However, alloc_file()
actually returns an ERR_PTR value and might fail with other error codes.
Currently, in addition to ENFILE, it can fail with ENOMEM, potentially
when there are few open files in the system. Update sys_pipe() to
preserve this error code.
In a prior submission of a similar patch (1) some concern was raised
about introducing a new error code for sys_pipe(). However, for most
system calls, programs cannot assume that new error codes will never be
introduced. In addition, ENOMEM was, in fact, already a possible error
code for sys_pipe(), in the case where the file descriptor table could
not be expanded due to insufficient memory.
(1) http://comments.gmane.org/gmane.linux.kernel/1357942
Signed-off-by: Eric Biggers <ebiggers3@gmail.com>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2015-10-17 16:26:08 -05:00
|
|
|
|
|
|
|
|
|
2012-07-21 15:33:25 +04:00
|
|
|
|
fs/pipe.c: preserve alloc_file() error code
If sys_pipe() was unable to allocate a 'struct file', it always failed
with ENFILE, which means "The number of simultaneously open files in the
system would exceed a system-imposed limit." However, alloc_file()
actually returns an ERR_PTR value and might fail with other error codes.
Currently, in addition to ENFILE, it can fail with ENOMEM, potentially
when there are few open files in the system. Update sys_pipe() to
preserve this error code.
In a prior submission of a similar patch (1) some concern was raised
about introducing a new error code for sys_pipe(). However, for most
system calls, programs cannot assume that new error codes will never be
introduced. In addition, ENOMEM was, in fact, already a possible error
code for sys_pipe(), in the case where the file descriptor table could
not be expanded due to insufficient memory.
(1) http://comments.gmane.org/gmane.linux.kernel/1357942
Signed-off-by: Eric Biggers <ebiggers3@gmail.com>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2015-10-17 16:26:08 -05:00
|
|
|
|
2012-07-21 15:33:25 +04:00
|
|
|
|
|
|
|
|
|
2013-03-21 11:16:56 -04:00
|
|
|
|
2012-07-21 15:33:25 +04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2012-07-21 15:33:25 +04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-03-21 11:06:46 -04:00
|
|
|
|
2009-08-09 00:52:35 +04:00
|
|
|
|
2012-07-21 15:33:25 +04:00
|
|
|
|
2008-04-22 19:51:27 -04:00
|
|
|
|
2012-07-21 15:33:25 +04:00
|
|
|
|
2013-03-21 11:06:46 -04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2012-07-21 15:33:25 +04:00
|
|
|
|
2006-09-30 23:29:26 -07:00
|
|
|
|
|
|
|
|
|
2012-08-19 12:17:29 -04:00
|
|
|
|
2006-09-30 23:29:26 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
pipes: add a "packetized pipe" mode for writing
The actual internal pipe implementation is already really about
individual packets (called "pipe buffers"), and this simply exposes that
as a special packetized mode.
When we are in the packetized mode (marked by O_DIRECT as suggested by
Alan Cox), a write() on a pipe will not merge the new data with previous
writes, so each write will get a pipe buffer of its own. The pipe
buffer is then marked with the PIPE_BUF_FLAG_PACKET flag, which in turn
will tell the reader side to break the read at that boundary (and throw
away any partial packet contents that do not fit in the read buffer).
End result: as long as you do writes less than PIPE_BUF in size (so that
the pipe doesn't have to split them up), you can now treat the pipe as a
packet interface, where each read() system call will read one packet at
a time. You can just use a sufficiently big read buffer (PIPE_BUF is
sufficient, since bigger than that doesn't guarantee atomicity anyway),
and the return value of the read() will naturally give you the size of
the packet.
NOTE! We do not support zero-sized packets, and zero-sized reads and
writes to a pipe continue to be no-ops. Also note that big packets will
currently be split at write time, but that the size at which that
happens is not really specified (except that it's bigger than PIPE_BUF).
Currently that limit is the system page size, but we might want to
explicitly support bigger packets some day.
The main user for this is going to be the autofs packet interface,
allowing us to stop having to care so deeply about exact packet sizes
(which have had bugs with 32/64-bit compatibility modes). But user
space can create packetized pipes with "pipe2(fd, O_DIRECT)", which will
fail with an EINVAL on kernels that do not support this interface.
Tested-by: Michael Tokarev <mjt@tls.msk.ru>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: David Miller <davem@davemloft.net>
Cc: Ian Kent <raven@themaw.net>
Cc: Thomas Meyer <thomas@m3y3r.de>
Cc: stable@kernel.org # needed for systemd/autofs interaction fix
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2012-04-29 13:12:42 -07:00
|
|
|
|
2008-07-23 21:29:30 -07:00
|
|
|
|
|
|
|
|
|
2012-07-21 15:33:25 +04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-09-30 23:29:26 -07:00
|
|
|
|
2008-07-23 21:29:30 -07:00
|
|
|
|
2006-09-30 23:29:26 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-07-23 21:29:30 -07:00
|
|
|
|
2006-09-30 23:29:26 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-12-14 04:57:47 -05:00
|
|
|
|
2006-09-30 23:29:26 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-07-21 15:33:25 +04:00
|
|
|
|
|
|
|
|
|
2006-09-30 23:29:26 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2012-08-19 12:17:29 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-05-03 15:10:37 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-01-14 14:14:34 +01:00
|
|
|
|
2008-05-03 15:10:37 -04:00
|
|
|
|
2012-08-19 12:17:29 -04:00
|
|
|
|
2008-05-03 15:10:37 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-08-19 12:17:29 -04:00
|
|
|
|
2008-05-03 15:10:37 -04:00
|
|
|
|
2012-08-19 12:17:29 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-05-03 15:10:37 -04:00
|
|
|
|
2012-08-19 12:17:29 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-05-06 20:42:38 -07:00
|
|
|
|
2008-05-03 15:10:37 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-01-14 14:14:35 +01:00
|
|
|
|
2008-07-23 21:29:30 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-03-21 02:07:59 -04:00
|
|
|
|
2013-03-12 09:46:27 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-03-21 02:07:59 -04:00
|
|
|
|
2013-03-12 09:46:27 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-03-21 02:07:59 -04:00
|
|
|
|
2013-03-12 09:46:27 -04:00
|
|
|
|
2013-03-21 02:07:59 -04:00
|
|
|
|
2013-03-12 09:46:27 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-03-12 09:58:10 -04:00
|
|
|
|
2013-03-12 09:46:27 -04:00
|
|
|
|
|
|
|
|
|
2013-03-21 02:21:19 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-03-21 11:04:15 -04:00
|
|
|
|
2013-03-12 09:46:27 -04:00
|
|
|
|
2013-03-21 02:21:19 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-03-21 11:06:46 -04:00
|
|
|
|
2013-03-21 02:21:19 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-03-12 09:46:27 -04:00
|
|
|
|
2013-03-21 11:16:56 -04:00
|
|
|
|
2013-03-21 02:21:19 -04:00
|
|
|
|
|
|
|
|
|
2013-03-21 12:24:01 -04:00
|
|
|
|
2013-03-12 09:46:27 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-03-21 02:07:59 -04:00
|
|
|
|
2013-03-12 09:46:27 -04:00
|
|
|
|
2013-03-12 09:58:10 -04:00
|
|
|
|
2013-03-12 09:46:27 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-03-21 02:07:59 -04:00
|
|
|
|
2013-03-12 09:46:27 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-03-12 09:58:10 -04:00
|
|
|
|
2013-03-12 09:46:27 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-03-21 02:07:59 -04:00
|
|
|
|
2013-03-12 09:46:27 -04:00
|
|
|
|
2013-03-12 09:58:10 -04:00
|
|
|
|
2013-03-21 02:07:59 -04:00
|
|
|
|
2013-03-12 09:46:27 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-03-21 02:07:59 -04:00
|
|
|
|
2013-03-12 09:46:27 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-03-21 12:24:01 -04:00
|
|
|
|
2013-03-12 09:46:27 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-03-21 12:24:01 -04:00
|
|
|
|
vfs: fix subtle use-after-free of pipe_inode_info
The pipe code was trying (and failing) to be very careful about freeing
the pipe info only after the last access, with a pattern like:
spin_lock(&inode->i_lock);
if (!--pipe->files) {
inode->i_pipe = NULL;
kill = 1;
}
spin_unlock(&inode->i_lock);
__pipe_unlock(pipe);
if (kill)
free_pipe_info(pipe);
where the final freeing is done last.
HOWEVER. The above is actually broken, because while the freeing is
done at the end, if we have two racing processes releasing the pipe
inode info, the one that *doesn't* free it will decrement the ->files
count, and unlock the inode i_lock, but then still use the
"pipe_inode_info" afterwards when it does the "__pipe_unlock(pipe)".
This is *very* hard to trigger in practice, since the race window is
very small, and adding debug options seems to just hide it by slowing
things down.
Simon originally reported this way back in July as an Oops in
kmem_cache_allocate due to a single bit corruption (due to the final
"spin_unlock(pipe->mutex.wait_lock)" incrementing a field in a different
allocation that had re-used the free'd pipe-info), it's taken this long
to figure out.
Since the 'pipe->files' accesses aren't even protected by the pipe lock
(we very much use the inode lock for that), the simple solution is to
just drop the pipe lock early. And since there were two users of this
pattern, create a helper function for it.
Introduced commit ba5bb147330a ("pipe: take allocation and freeing of
pipe_inode_info out of ->i_mutex").
Reported-by: Simon Kirby <sim@hostway.ca>
Reported-by: Ian Applegate <ia@cloudflare.com>
Acked-by: Al Viro <viro@zeniv.linux.org.uk>
Cc: stable@kernel.org # v3.10+
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2013-12-02 09:44:51 -08:00
|
|
|
|
|
|
|
|
|
2013-03-12 09:46:27 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-03-12 09:58:10 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-04-02 19:56:54 -04:00
|
|
|
|
2014-04-03 15:05:18 -04:00
|
|
|
|
2013-03-12 09:58:10 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-03-12 09:46:27 -04:00
|
|
|
|
|
|
|
|
|
2010-05-20 10:43:18 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-05-24 19:34:43 +02:00
|
|
|
|
2010-05-20 10:43:18 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-05-24 19:34:43 +02:00
|
|
|
|
2010-05-20 10:43:18 +02:00
|
|
|
|
|
|
|
|
|
2012-01-12 17:17:40 -08:00
|
|
|
|
2010-05-20 10:43:18 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-06-08 16:28:45 +02:00
|
|
|
|
|
|
|
|
|
2010-05-20 10:43:18 +02:00
|
|
|
|
2010-06-08 16:28:45 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-05-20 10:43:18 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-06-08 16:28:45 +02:00
|
|
|
|
2010-05-20 10:43:18 +02:00
|
|
|
|
|
|
|
|
|
2016-01-18 16:36:09 +01:00
|
|
|
|
2010-05-20 10:43:18 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-05-24 19:34:43 +02:00
|
|
|
|
|
|
|
|
|
2010-05-20 10:43:18 +02:00
|
|
|
|
|
|
|
|
|
2010-06-03 14:54:39 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-11-28 16:27:19 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-03-21 11:16:56 -04:00
|
|
|
|
2010-11-28 16:27:19 -08:00
|
|
|
|
|
|
|
|
|
2010-05-20 10:43:18 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-11-28 14:09:57 -08:00
|
|
|
|
2010-05-20 10:43:18 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-03-21 12:24:01 -04:00
|
|
|
|
2010-05-20 10:43:18 +02:00
|
|
|
|
|
|
|
|
|
2010-05-24 19:34:43 +02:00
|
|
|
|
2010-06-03 14:54:39 +02:00
|
|
|
|
2010-05-24 19:34:43 +02:00
|
|
|
|
2010-06-03 14:54:39 +02:00
|
|
|
|
|
|
|
|
|
2010-05-24 19:34:43 +02:00
|
|
|
|
2010-06-09 09:27:57 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-06-03 14:54:39 +02:00
|
|
|
|
2010-06-01 12:42:12 +02:00
|
|
|
|
2010-05-26 17:54:39 +02:00
|
|
|
|
2016-01-18 16:36:09 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-05-26 17:54:39 +02:00
|
|
|
|
2010-06-03 14:54:39 +02:00
|
|
|
|
2010-05-20 10:43:18 +02:00
|
|
|
|
2010-05-24 19:34:43 +02:00
|
|
|
|
2010-05-20 10:43:18 +02:00
|
|
|
|
2010-05-24 19:34:43 +02:00
|
|
|
|
2010-05-20 10:43:18 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-05-26 17:54:39 +02:00
|
|
|
|
2013-03-21 12:24:01 -04:00
|
|
|
|
2010-05-20 10:43:18 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-01-07 17:49:50 +11:00
|
|
|
|
|
|
|
|
|
2011-10-31 17:10:04 -07:00
|
|
|
|
2011-01-07 17:49:50 +11:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-07-25 23:47:46 +04:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2011-01-12 16:59:34 -05:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-07-25 23:47:46 +04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-04-11 13:57:45 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|