License cleanup: add SPDX GPL-2.0 license identifier to files with no license
Many source files in the tree are missing licensing information, which
makes it harder for compliance tools to determine the correct license.
By default all files without license information are under the default
license of the kernel, which is GPL version 2.
Update the files which contain no license information with the 'GPL-2.0'
SPDX license identifier. The SPDX identifier is a legally binding
shorthand, which can be used instead of the full boiler plate text.
This patch is based on work done by Thomas Gleixner and Kate Stewart and
Philippe Ombredanne.
How this work was done:
Patches were generated and checked against linux-4.14-rc6 for a subset of
the use cases:
- file had no licensing information it it.
- file was a */uapi/* one with no licensing information in it,
- file was a */uapi/* one with existing licensing information,
Further patches will be generated in subsequent months to fix up cases
where non-standard license headers were used, and references to license
had to be inferred by heuristics based on keywords.
The analysis to determine which SPDX License Identifier to be applied to
a file was done in a spreadsheet of side by side results from of the
output of two independent scanners (ScanCode & Windriver) producing SPDX
tag:value files created by Philippe Ombredanne. Philippe prepared the
base worksheet, and did an initial spot review of a few 1000 files.
The 4.13 kernel was the starting point of the analysis with 60,537 files
assessed. Kate Stewart did a file by file comparison of the scanner
results in the spreadsheet to determine which SPDX license identifier(s)
to be applied to the file. She confirmed any determination that was not
immediately clear with lawyers working with the Linux Foundation.
Criteria used to select files for SPDX license identifier tagging was:
- Files considered eligible had to be source code files.
- Make and config files were included as candidates if they contained >5
lines of source
- File already had some variant of a license header in it (even if <5
lines).
All documentation files were explicitly excluded.
The following heuristics were used to determine which SPDX license
identifiers to apply.
- when both scanners couldn't find any license traces, file was
considered to have no license information in it, and the top level
COPYING file license applied.
For non */uapi/* files that summary was:
SPDX license identifier # files
---------------------------------------------------|-------
GPL-2.0 11139
and resulted in the first patch in this series.
If that file was a */uapi/* path one, it was "GPL-2.0 WITH
Linux-syscall-note" otherwise it was "GPL-2.0". Results of that was:
SPDX license identifier # files
---------------------------------------------------|-------
GPL-2.0 WITH Linux-syscall-note 930
and resulted in the second patch in this series.
- if a file had some form of licensing information in it, and was one
of the */uapi/* ones, it was denoted with the Linux-syscall-note if
any GPL family license was found in the file or had no licensing in
it (per prior point). Results summary:
SPDX license identifier # files
---------------------------------------------------|------
GPL-2.0 WITH Linux-syscall-note 270
GPL-2.0+ WITH Linux-syscall-note 169
((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause) 21
((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause) 17
LGPL-2.1+ WITH Linux-syscall-note 15
GPL-1.0+ WITH Linux-syscall-note 14
((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause) 5
LGPL-2.0+ WITH Linux-syscall-note 4
LGPL-2.1 WITH Linux-syscall-note 3
((GPL-2.0 WITH Linux-syscall-note) OR MIT) 3
((GPL-2.0 WITH Linux-syscall-note) AND MIT) 1
and that resulted in the third patch in this series.
- when the two scanners agreed on the detected license(s), that became
the concluded license(s).
- when there was disagreement between the two scanners (one detected a
license but the other didn't, or they both detected different
licenses) a manual inspection of the file occurred.
- In most cases a manual inspection of the information in the file
resulted in a clear resolution of the license that should apply (and
which scanner probably needed to revisit its heuristics).
- When it was not immediately clear, the license identifier was
confirmed with lawyers working with the Linux Foundation.
- If there was any question as to the appropriate license identifier,
the file was flagged for further research and to be revisited later
in time.
In total, over 70 hours of logged manual review was done on the
spreadsheet to determine the SPDX license identifiers to apply to the
source files by Kate, Philippe, Thomas and, in some cases, confirmation
by lawyers working with the Linux Foundation.
Kate also obtained a third independent scan of the 4.13 code base from
FOSSology, and compared selected files where the other two scanners
disagreed against that SPDX file, to see if there was new insights. The
Windriver scanner is based on an older version of FOSSology in part, so
they are related.
Thomas did random spot checks in about 500 files from the spreadsheets
for the uapi headers and agreed with SPDX license identifier in the
files he inspected. For the non-uapi files Thomas did random spot checks
in about 15000 files.
In initial set of patches against 4.14-rc6, 3 files were found to have
copy/paste license identifier errors, and have been fixed to reflect the
correct identifier.
Additionally Philippe spent 10 hours this week doing a detailed manual
inspection and review of the 12,461 patched files from the initial patch
version early this week with:
- a full scancode scan run, collecting the matched texts, detected
license ids and scores
- reviewing anything where there was a license detected (about 500+
files) to ensure that the applied SPDX license was correct
- reviewing anything where there was no detection but the patch license
was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied
SPDX license was correct
This produced a worksheet with 20 files needing minor correction. This
worksheet was then exported into 3 different .csv files for the
different types of files to be modified.
These .csv files were then reviewed by Greg. Thomas wrote a script to
parse the csv files and add the proper SPDX tag to the file, in the
format that the file expected. This script was further refined by Greg
based on the output to detect more types of files automatically and to
distinguish between header and source .c files (which need different
comment types.) Finally Greg ran the script using the .csv files to
generate the patches.
Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org>
Reviewed-by: Philippe Ombredanne <pombredanne@nexb.com>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-11-01 15:07:57 +01:00
|
|
|
|
2006-10-11 01:20:50 -07:00
|
|
|
|
2006-10-11 01:20:53 -07:00
|
|
|
|
2006-10-11 01:20:50 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-10-11 01:20:53 -07:00
|
|
|
|
2006-10-11 01:20:50 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2026-01-08 12:13:01 -05:00
|
|
|
|
2006-10-11 01:20:50 -07:00
|
|
|
|
2018-01-09 08:21:39 -05:00
|
|
|
|
ext4: Support case-insensitive file name lookups
This patch implements the actual support for case-insensitive file name
lookups in ext4, based on the feature bit and the encoding stored in the
superblock.
A filesystem that has the casefold feature set is able to configure
directories with the +F (EXT4_CASEFOLD_FL) attribute, enabling lookups
to succeed in that directory in a case-insensitive fashion, i.e: match
a directory entry even if the name used by userspace is not a byte per
byte match with the disk name, but is an equivalent case-insensitive
version of the Unicode string. This operation is called a
case-insensitive file name lookup.
The feature is configured as an inode attribute applied to directories
and inherited by its children. This attribute can only be enabled on
empty directories for filesystems that support the encoding feature,
thus preventing collision of file names that only differ by case.
* dcache handling:
For a +F directory, Ext4 only stores the first equivalent name dentry
used in the dcache. This is done to prevent unintentional duplication of
dentries in the dcache, while also allowing the VFS code to quickly find
the right entry in the cache despite which equivalent string was used in
a previous lookup, without having to resort to ->lookup().
d_hash() of casefolded directories is implemented as the hash of the
casefolded string, such that we always have a well-known bucket for all
the equivalencies of the same string. d_compare() uses the
utf8_strncasecmp() infrastructure, which handles the comparison of
equivalent, same case, names as well.
For now, negative lookups are not inserted in the dcache, since they
would need to be invalidated anyway, because we can't trust missing file
dentries. This is bad for performance but requires some leveraging of
the vfs layer to fix. We can live without that for now, and so does
everyone else.
* on-disk data:
Despite using a specific version of the name as the internal
representation within the dcache, the name stored and fetched from the
disk is a byte-per-byte match with what the user requested, making this
implementation 'name-preserving'. i.e. no actual information is lost
when writing to storage.
DX is supported by modifying the hashes used in +F directories to make
them case/encoding-aware. The new disk hashes are calculated as the
hash of the full casefolded string, instead of the string directly.
This allows us to efficiently search for file names in the htree without
requiring the user to provide an exact name.
* Dealing with invalid sequences:
By default, when a invalid UTF-8 sequence is identified, ext4 will treat
it as an opaque byte sequence, ignoring the encoding and reverting to
the old behavior for that unique file. This means that case-insensitive
file name lookup will not work only for that file. An optional bit can
be set in the superblock telling the filesystem code and userspace tools
to enforce the encoding. When that optional bit is set, any attempt to
create a file name using an invalid UTF-8 sequence will fail and return
an error to userspace.
* Normalization algorithm:
The UTF-8 algorithms used to compare strings in ext4 is implemented
lives in fs/unicode, and is based on a previous version developed by
SGI. It implements the Canonical decomposition (NFD) algorithm
described by the Unicode specification 12.1, or higher, combined with
the elimination of ignorable code points (NFDi) and full
case-folding (CF) as documented in fs/unicode/utf8_norm.c.
NFD seems to be the best normalization method for EXT4 because:
- It has a lower cost than NFC/NFKC (which requires
decomposing to NFD as an intermediary step)
- It doesn't eliminate important semantic meaning like
compatibility decompositions.
Although:
- This implementation is not completely linguistic accurate, because
different languages have conflicting rules, which would require the
specialization of the filesystem to a given locale, which brings all
sorts of problems for removable media and for users who use more than
one language.
Signed-off-by: Gabriel Krisman Bertazi <krisman@collabora.co.uk>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2019-04-25 14:12:08 -04:00
|
|
|
|
2008-04-29 18:13:32 -04:00
|
|
|
|
2012-12-10 14:05:59 -05:00
|
|
|
|
2006-10-11 01:20:50 -07:00
|
|
|
|
2013-05-17 16:08:53 -04:00
|
|
|
|
2006-10-11 01:20:50 -07:00
|
|
|
|
2012-03-18 22:44:40 -04:00
|
|
|
|
2019-06-19 16:30:03 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-03-18 22:44:40 -04:00
|
|
|
|
2013-08-28 14:40:12 -04:00
|
|
|
|
2012-03-18 22:44:40 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-10-17 16:18:43 -04:00
|
|
|
|
2012-03-18 22:44:40 -04:00
|
|
|
|
2013-04-19 17:53:09 -04:00
|
|
|
|
|
|
|
|
|
2012-03-18 22:44:40 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-03-19 07:34:13 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-12-19 22:07:02 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-12-10 14:05:59 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-12-19 22:07:02 -05:00
|
|
|
|
2010-07-27 11:54:40 -04:00
|
|
|
|
2011-01-10 12:10:55 -05:00
|
|
|
|
2010-07-27 11:54:40 -04:00
|
|
|
|
2012-12-10 14:05:58 -05:00
|
|
|
|
2010-07-27 11:54:40 -04:00
|
|
|
|
2006-10-11 01:20:50 -07:00
|
|
|
|
2008-09-08 22:25:24 -04:00
|
|
|
|
2009-02-14 23:01:36 -05:00
|
|
|
|
|
|
|
|
|
2019-12-08 19:43:46 -05:00
|
|
|
|
2021-03-19 07:34:13 +00:00
|
|
|
|
2025-02-06 19:13:35 -08:00
|
|
|
|
2006-10-11 01:20:50 -07:00
|
|
|
|
2021-03-19 07:34:13 +00:00
|
|
|
|
2006-10-11 01:20:50 -07:00
|
|
|
|
2010-12-19 22:07:02 -05:00
|
|
|
|
2006-10-11 01:20:50 -07:00
|
|
|
|
2021-03-19 07:34:13 +00:00
|
|
|
|
|
|
|
|
|
2006-10-11 01:20:50 -07:00
|
|
|
|
2019-12-08 19:43:46 -05:00
|
|
|
|
2018-08-27 09:22:45 -04:00
|
|
|
|
2021-03-19 07:34:13 +00:00
|
|
|
|
|
|
|
|
|
2019-12-08 19:43:46 -05:00
|
|
|
|
2019-12-02 18:02:13 +01:00
|
|
|
|
2010-12-19 22:07:02 -05:00
|
|
|
|
|
|
|
|
|
2006-10-11 01:20:50 -07:00
|
|
|
|
2025-03-20 15:46:49 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-12-19 22:07:02 -05:00
|
|
|
|
|
|
|
|
|
2006-10-11 01:20:50 -07:00
|
|
|
|
2011-01-10 12:10:55 -05:00
|
|
|
|
2012-02-20 17:53:05 -05:00
|
|
|
|
2018-08-27 09:22:45 -04:00
|
|
|
|
2021-03-19 07:34:13 +00:00
|
|
|
|
2018-08-27 09:22:45 -04:00
|
|
|
|
2021-03-19 07:34:13 +00:00
|
|
|
|
2011-01-10 12:10:55 -05:00
|
|
|
|
2012-02-20 17:53:05 -05:00
|
|
|
|
2018-08-27 09:22:45 -04:00
|
|
|
|
2021-03-19 07:34:13 +00:00
|
|
|
|
2018-08-27 09:22:45 -04:00
|
|
|
|
2021-03-19 07:34:13 +00:00
|
|
|
|
2011-01-10 12:10:55 -05:00
|
|
|
|
2010-12-19 22:07:02 -05:00
|
|
|
|
2006-10-11 01:20:50 -07:00
|
|
|
|
|
|
|
|
|
2013-05-17 16:08:53 -04:00
|
|
|
|
2006-10-11 01:20:50 -07:00
|
|
|
|
2008-11-05 00:14:04 -05:00
|
|
|
|
2014-05-27 12:48:55 -04:00
|
|
|
|
2006-10-11 01:20:53 -07:00
|
|
|
|
2006-10-11 01:20:50 -07:00
|
|
|
|
2013-05-17 16:08:53 -04:00
|
|
|
|
2012-03-18 22:44:40 -04:00
|
|
|
|
2015-04-12 01:09:05 -04:00
|
|
|
|
2016-07-10 14:01:03 -04:00
|
|
|
|
2024-08-30 15:04:52 +02:00
|
|
|
|
2006-10-11 01:20:50 -07:00
|
|
|
|
2020-12-02 18:20:37 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-02-07 19:35:05 -05:00
|
|
|
|
2012-03-18 22:44:40 -04:00
|
|
|
|
2013-05-17 16:08:53 -04:00
|
|
|
|
2021-03-15 22:29:53 -07:00
|
|
|
|
2013-05-17 16:08:53 -04:00
|
|
|
|
2021-03-15 22:29:53 -07:00
|
|
|
|
2020-02-10 15:43:16 +01:00
|
|
|
|
2025-02-06 19:13:35 -08:00
|
|
|
|
2020-02-10 15:43:16 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-10-11 01:20:50 -07:00
|
|
|
|
2013-04-19 17:53:09 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-04-12 01:09:05 -04:00
|
|
|
|
2013-04-19 17:53:09 -04:00
|
|
|
|
|
|
|
|
|
2015-04-12 01:09:05 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-12-12 15:20:10 +05:30
|
|
|
|
2020-08-10 10:21:39 -04:00
|
|
|
|
ext4 crypto: reorganize how we store keys in the inode
This is a pretty massive patch which does a number of different things:
1) The per-inode encryption information is now stored in an allocated
data structure, ext4_crypt_info, instead of directly in the node.
This reduces the size usage of an in-memory inode when it is not
using encryption.
2) We drop the ext4_fname_crypto_ctx entirely, and use the per-inode
encryption structure instead. This remove an unnecessary memory
allocation and free for the fname_crypto_ctx as well as allowing us
to reuse the ctfm in a directory for multiple lookups and file
creations.
3) We also cache the inode's policy information in the ext4_crypt_info
structure so we don't have to continually read it out of the
extended attributes.
4) We now keep the keyring key in the inode's encryption structure
instead of releasing it after we are done using it to derive the
per-inode key. This allows us to test to see if the key has been
revoked; if it has, we prevent the use of the derived key and free
it.
5) When an inode is released (or when the derived key is freed), we
will use memset_explicit() to zero out the derived key, so it's not
left hanging around in memory. This implies that when a user logs
out, it is important to first revoke the key, and then unlink it,
and then finally, to use "echo 3 > /proc/sys/vm/drop_caches" to
release any decrypted pages and dcache entries from the system
caches.
6) All this, and we also shrink the number of lines of code by around
100. :-)
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2015-05-18 13:17:47 -04:00
|
|
|
|
2015-04-12 01:09:05 -04:00
|
|
|
|
2013-04-19 17:53:09 -04:00
|
|
|
|
|
|
|
|
|
2013-05-17 16:08:53 -04:00
|
|
|
|
2010-05-16 20:00:00 -04:00
|
|
|
|
2006-10-11 01:20:50 -07:00
|
|
|
|
2016-04-23 22:50:07 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-06-20 21:19:02 -04:00
|
|
|
|
2013-05-17 16:08:53 -04:00
|
|
|
|
2010-05-16 20:00:00 -04:00
|
|
|
|
|
|
|
|
|
2019-06-20 21:19:02 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-10-11 01:20:50 -07:00
|
|
|
|
2025-11-21 17:06:38 +08:00
|
|
|
|
|
|
|
|
|
2013-05-17 16:08:53 -04:00
|
|
|
|
2007-07-19 01:48:08 -07:00
|
|
|
|
2024-04-11 15:53:37 +01:00
|
|
|
|
2025-11-21 17:06:38 +08: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
|
|
|
|
2014-08-29 20:52:15 -04:00
|
|
|
|
2016-02-16 00:20:19 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-10-11 01:20:50 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
[PATCH] handle ext4 directory corruption better
I've been using Steve Grubb's purely evil "fsfuzzer" tool, at
http://people.redhat.com/sgrubb/files/fsfuzzer-0.4.tar.gz
Basically it makes a filesystem, splats some random bits over it, then
tries to mount it and do some simple filesystem actions.
At best, the filesystem catches the corruption gracefully. At worst,
things spin out of control.
As you might guess, we found a couple places in ext4 where things spin out
of control :)
First, we had a corrupted directory that was never checked for
consistency... it was corrupt, and pointed to another bad "entry" of
length 0. The for() loop looped forever, since the length of
ext4_next_entry(de) was 0, and we kept looking at the same pointer over and
over and over and over... I modeled this check and subsequent action on
what is done for other directory types in ext4_readdir...
(adding this check adds some computational expense; I am testing a followup
patch to reduce the number of times we check and re-check these directory
entries, in all cases. Thanks for the idea, Andreas).
Next we had a root directory inode which had a corrupted size, claimed to
be > 200M on a 4M filesystem. There was only really 1 block in the
directory, but because the size was so large, readdir kept coming back for
more, spewing thousands of printk's along the way.
Per Andreas' suggestion, if we're in this read error condition and we're
trying to read an offset which is greater than i_blocks worth of bytes,
stop trying, and break out of the loop.
With these two changes fsfuzz test survives quite well on ext4.
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Cc: <linux-ext4@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-12-06 20:36:28 -08:00
|
|
|
|
2013-05-17 16:08:53 -04:00
|
|
|
|
[PATCH] handle ext4 directory corruption better
I've been using Steve Grubb's purely evil "fsfuzzer" tool, at
http://people.redhat.com/sgrubb/files/fsfuzzer-0.4.tar.gz
Basically it makes a filesystem, splats some random bits over it, then
tries to mount it and do some simple filesystem actions.
At best, the filesystem catches the corruption gracefully. At worst,
things spin out of control.
As you might guess, we found a couple places in ext4 where things spin out
of control :)
First, we had a corrupted directory that was never checked for
consistency... it was corrupt, and pointed to another bad "entry" of
length 0. The for() loop looped forever, since the length of
ext4_next_entry(de) was 0, and we kept looking at the same pointer over and
over and over and over... I modeled this check and subsequent action on
what is done for other directory types in ext4_readdir...
(adding this check adds some computational expense; I am testing a followup
patch to reduce the number of times we check and re-check these directory
entries, in all cases. Thanks for the idea, Andreas).
Next we had a root directory inode which had a corrupted size, claimed to
be > 200M on a 4M filesystem. There was only really 1 block in the
directory, but because the size was so large, readdir kept coming back for
more, spewing thousands of printk's along the way.
Per Andreas' suggestion, if we're in this read error condition and we're
trying to read an offset which is greater than i_blocks worth of bytes,
stop trying, and break out of the loop.
With these two changes fsfuzz test survives quite well on ext4.
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Cc: <linux-ext4@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-12-06 20:36:28 -08:00
|
|
|
|
2013-05-17 16:08:53 -04:00
|
|
|
|
2006-10-11 01:20:50 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-04-29 18:41:10 -04:00
|
|
|
|
|
|
|
|
|
2019-06-21 15:49:26 -04:00
|
|
|
|
2013-05-17 16:08:53 -04:00
|
|
|
|
2012-04-29 18:41:10 -04:00
|
|
|
|
2013-05-17 16:08:53 -04:00
|
|
|
|
|
|
|
|
|
2013-01-28 21:23:24 -05:00
|
|
|
|
2015-04-12 01:09:05 -04:00
|
|
|
|
2012-04-29 18:41:10 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-10-11 01:20:50 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-08-30 15:04:52 +02:00
|
|
|
|
2006-10-11 01:20:50 -07:00
|
|
|
|
2006-10-11 01:20:53 -07:00
|
|
|
|
2006-10-11 01:20:50 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-02-14 23:01:36 -05:00
|
|
|
|
2021-03-19 07:34:13 +00:00
|
|
|
|
|
|
|
|
|
2006-10-11 01:20:50 -07:00
|
|
|
|
2009-02-14 23:01:36 -05:00
|
|
|
|
|
|
|
|
|
2006-10-11 01:20:50 -07:00
|
|
|
|
|
|
|
|
|
2013-05-17 16:08:53 -04:00
|
|
|
|
2006-10-11 01:20:50 -07:00
|
|
|
|
2024-08-30 15:04:52 +02:00
|
|
|
|
2006-10-11 01:20:50 -07:00
|
|
|
|
|
|
|
|
|
2013-05-17 16:08:53 -04:00
|
|
|
|
2006-10-11 01:20:50 -07:00
|
|
|
|
2006-10-11 01:20:53 -07:00
|
|
|
|
2013-05-17 16:08:53 -04:00
|
|
|
|
2012-12-10 14:05:58 -05:00
|
|
|
|
|
|
|
|
|
2006-10-11 01:21:24 -07:00
|
|
|
|
2013-05-17 16:08:53 -04:00
|
|
|
|
2006-10-11 01:21:24 -07:00
|
|
|
|
2013-05-17 16:08:53 -04:00
|
|
|
|
2006-10-11 01:20:50 -07:00
|
|
|
|
2013-05-17 16:08:53 -04:00
|
|
|
|
2006-10-11 01:20:50 -07:00
|
|
|
|
2009-02-14 23:01:36 -05:00
|
|
|
|
|
|
|
|
|
2006-10-11 01:20:50 -07:00
|
|
|
|
2018-12-12 15:20:10 +05:30
|
|
|
|
2015-04-12 01:09:05 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-07-10 14:01:03 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-07-01 14:43:39 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-05-18 13:15:47 -04:00
|
|
|
|
2015-04-12 01:09:05 -04:00
|
|
|
|
2016-07-10 14:01:03 -04:00
|
|
|
|
2024-07-01 14:43:39 +08:00
|
|
|
|
2016-09-15 17:25:55 -04:00
|
|
|
|
2016-07-10 14:01:03 -04:00
|
|
|
|
2016-09-15 17:25:55 -04:00
|
|
|
|
2015-04-12 01:09:05 -04:00
|
|
|
|
|
|
|
|
|
2016-09-15 17:25:55 -04:00
|
|
|
|
2015-04-12 01:09:05 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-05-17 16:08:53 -04:00
|
|
|
|
2006-10-11 01:20:50 -07:00
|
|
|
|
2013-05-17 16:08:53 -04:00
|
|
|
|
2009-02-14 23:01:36 -05:00
|
|
|
|
2006-10-11 01:20:50 -07:00
|
|
|
|
2016-05-12 20:36:01 -04:00
|
|
|
|
2015-04-12 01:09:05 -04:00
|
|
|
|
2008-09-08 22:25:24 -04:00
|
|
|
|
2015-04-12 01:09:05 -04:00
|
|
|
|
2006-10-11 01:20:50 -07:00
|
|
|
|
2015-04-12 01:09:05 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-07-10 14:01:03 -04:00
|
|
|
|
2015-04-12 01:09:05 -04:00
|
|
|
|
|
|
|
|
|
2006-10-11 01:20:50 -07:00
|
|
|
|
|
|
|
|
|
2012-03-18 22:44:40 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-03-22 14:25:04 -07:00
|
|
|
|
2012-03-18 22:44:40 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-10-11 01:20:50 -07:00
|
|
|
|
|
|
|
|
|
2012-03-18 22:44:40 -04:00
|
|
|
|
2006-10-11 01:20:50 -07:00
|
|
|
|
2012-03-18 22:44:40 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-10-11 01:20:50 -07:00
|
|
|
|
2012-03-18 22:44:40 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-04-30 13:14:03 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-03-18 22:44:40 -04:00
|
|
|
|
2012-04-30 13:14:03 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-03-18 22:44:40 -04:00
|
|
|
|
2013-03-02 17:24:05 -05:00
|
|
|
|
2012-03-18 22:44:40 -04:00
|
|
|
|
|
|
|
|
|
2024-08-30 15:04:52 +02:00
|
|
|
|
2012-03-18 22:44:40 -04:00
|
|
|
|
2018-04-01 23:21:03 -04:00
|
|
|
|
2012-03-18 22:44:40 -04:00
|
|
|
|
2012-04-30 13:14:03 -05:00
|
|
|
|
2018-04-01 23:21:03 -04:00
|
|
|
|
2012-04-30 13:14:03 -05:00
|
|
|
|
|
|
|
|
|
2018-04-01 23:21:03 -04:00
|
|
|
|
2024-08-30 15:04:52 +02:00
|
|
|
|
2018-04-01 23:21:03 -04:00
|
|
|
|
2012-03-18 22:44:40 -04:00
|
|
|
|
2006-10-11 01:20:50 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-11-05 11:18:14 +01:00
|
|
|
|
2006-10-11 01:20:50 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-04-02 02:07:44 -07:00
|
|
|
|
2006-10-11 01:20:50 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-01-23 15:56:10 -08:00
|
|
|
|
2006-10-11 01:20:50 -07:00
|
|
|
|
2014-01-23 15:56:10 -08:00
|
|
|
|
2006-10-11 01:20:50 -07:00
|
|
|
|
2008-09-08 22:25:24 -04:00
|
|
|
|
2006-10-11 01:20:50 -07:00
|
|
|
|
2008-09-08 22:25:24 -04:00
|
|
|
|
2006-10-11 01:20:50 -07:00
|
|
|
|
2014-01-23 15:56:10 -08:00
|
|
|
|
|
|
|
|
|
2006-10-11 01:20:50 -07:00
|
|
|
|
|
|
|
|
|
2024-08-30 15:04:52 +02:00
|
|
|
|
2006-10-11 01:20:50 -07:00
|
|
|
|
2024-08-30 15:04:52 +02:00
|
|
|
|
2006-10-11 01:20:50 -07:00
|
|
|
|
2024-08-30 15:04:52 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-10-11 01:20:50 -07:00
|
|
|
|
|
|
|
|
|
2006-10-11 01:20:53 -07:00
|
|
|
|
2006-10-11 01:20:50 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-04-12 00:56:26 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-10-11 01:20:50 -07:00
|
|
|
|
2006-10-11 01:20:53 -07:00
|
|
|
|
2006-10-11 01:20:50 -07:00
|
|
|
|
2015-04-12 00:56:26 -04:00
|
|
|
|
2016-07-10 14:01:03 -04:00
|
|
|
|
2006-10-11 01:20:50 -07:00
|
|
|
|
|
|
|
|
|
2008-09-08 22:25:24 -04:00
|
|
|
|
2006-10-11 01:20:50 -07:00
|
|
|
|
|
|
|
|
|
2010-07-27 11:56:04 -04:00
|
|
|
|
2006-10-11 01:20:50 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2026-02-21 17:06:51 -08:00
|
|
|
|
2006-10-11 01:20:50 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-04-12 00:56:26 -04:00
|
|
|
|
2006-10-11 01:20:50 -07:00
|
|
|
|
2015-04-12 00:56:26 -04:00
|
|
|
|
2006-10-11 01:20:50 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-10-11 01:20:53 -07:00
|
|
|
|
2022-04-02 02:07:44 -07:00
|
|
|
|
2006-10-11 01:20:50 -07:00
|
|
|
|
|
|
|
|
|
2013-05-17 16:08:53 -04:00
|
|
|
|
|
|
|
|
|
2006-10-11 01:20:50 -07:00
|
|
|
|
2013-05-17 16:08:53 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-10-11 01:20:50 -07:00
|
|
|
|
|
|
|
|
|
2026-03-04 10:32:42 -05:00
|
|
|
|
2012-03-19 23:41:49 -04:00
|
|
|
|
|
|
|
|
|
2006-10-11 01:20:50 -07:00
|
|
|
|
|
|
|
|
|
2013-05-17 16:08:53 -04:00
|
|
|
|
2006-10-11 01:20:50 -07:00
|
|
|
|
2013-05-17 16:08:53 -04:00
|
|
|
|
|
|
|
|
|
2006-10-11 01:20:50 -07:00
|
|
|
|
2013-05-17 16:08:53 -04:00
|
|
|
|
2008-08-19 21:57:43 -04:00
|
|
|
|
2013-05-17 16:08:53 -04:00
|
|
|
|
2006-10-11 01:20:50 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-05-17 16:08:53 -04:00
|
|
|
|
2006-10-11 01:20:50 -07:00
|
|
|
|
2013-05-17 16:08:53 -04:00
|
|
|
|
|
|
|
|
|
2006-10-11 01:20:50 -07:00
|
|
|
|
ext4: fix potential infinite loop in ext4_dx_readdir()
When ext4_htree_fill_tree() fails, ext4_dx_readdir() can run into an
infinite loop since if info->last_pos != ctx->pos this will reset the
directory scan and reread the failing entry. For example:
1. a dx_dir which has 3 block, block 0 as dx_root block, block 1/2 as
leaf block which own the ext4_dir_entry_2
2. block 1 read ok and call_filldir which will fill the dirent and update
the ctx->pos
3. block 2 read fail, but we has already fill some dirent, so we will
return back to userspace will a positive return val(see ksys_getdents64)
4. the second ext4_dx_readdir will reset the world since info->last_pos
!= ctx->pos, and will also init the curr_hash which pos to block 1
5. So we will read block1 too, and once block2 still read fail, we can
only fill one dirent because the hash of the entry in block1(besides
the last one) won't greater than curr_hash
6. this time, we forget update last_pos too since the read for block2
will fail, and since we has got the one entry, ksys_getdents64 can
return success
7. Latter we will trapped in a loop with step 4~6
Cc: stable@kernel.org
Signed-off-by: yangerkun <yangerkun@huawei.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Link: https://lore.kernel.org/r/20210914111415.3921954-1-yangerkun@huawei.com
2021-09-14 19:14:15 +08:00
|
|
|
|
2006-10-11 01:20:50 -07:00
|
|
|
|
2024-08-30 15:04:52 +02:00
|
|
|
|
2006-10-11 01:20:50 -07:00
|
|
|
|
2013-05-17 16:08:53 -04:00
|
|
|
|
2006-10-11 01:20:50 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-05-17 16:08:53 -04:00
|
|
|
|
2006-10-11 01:20:50 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-05-17 16:08:53 -04:00
|
|
|
|
|
|
|
|
|
2006-10-11 01:20:50 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-08-19 21:57:43 -04:00
|
|
|
|
2013-05-17 16:08:53 -04:00
|
|
|
|
2008-08-19 21:57:43 -04:00
|
|
|
|
|
|
|
|
|
2008-10-25 11:39:08 -04:00
|
|
|
|
2008-08-19 21:57:43 -04:00
|
|
|
|
2006-10-11 01:20:50 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-08-30 15:04:52 +02:00
|
|
|
|
2006-10-11 01:20:50 -07:00
|
|
|
|
|
|
|
|
|
2024-08-30 15:04:52 +02:00
|
|
|
|
2013-05-17 16:08:53 -04:00
|
|
|
|
2006-10-11 01:20:50 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
ext4: fix potential infinite loop in ext4_dx_readdir()
When ext4_htree_fill_tree() fails, ext4_dx_readdir() can run into an
infinite loop since if info->last_pos != ctx->pos this will reset the
directory scan and reread the failing entry. For example:
1. a dx_dir which has 3 block, block 0 as dx_root block, block 1/2 as
leaf block which own the ext4_dir_entry_2
2. block 1 read ok and call_filldir which will fill the dirent and update
the ctx->pos
3. block 2 read fail, but we has already fill some dirent, so we will
return back to userspace will a positive return val(see ksys_getdents64)
4. the second ext4_dx_readdir will reset the world since info->last_pos
!= ctx->pos, and will also init the curr_hash which pos to block 1
5. So we will read block1 too, and once block2 still read fail, we can
only fill one dirent because the hash of the entry in block1(besides
the last one) won't greater than curr_hash
6. this time, we forget update last_pos too since the read for block2
will fail, and since we has got the one entry, ksys_getdents64 can
return success
7. Latter we will trapped in a loop with step 4~6
Cc: stable@kernel.org
Signed-off-by: yangerkun <yangerkun@huawei.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Link: https://lore.kernel.org/r/20210914111415.3921954-1-yangerkun@huawei.com
2021-09-14 19:14:15 +08:00
|
|
|
|
2006-10-11 01:20:50 -07:00
|
|
|
|
2013-05-17 16:08:53 -04:00
|
|
|
|
2006-10-11 01:20:50 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-05-17 16:08:53 -04:00
|
|
|
|
2006-10-11 01:20:50 -07:00
|
|
|
|
2008-10-25 11:39:08 -04:00
|
|
|
|
2006-10-11 01:20:50 -07:00
|
|
|
|
2008-10-25 11:39:08 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-10-11 01:20:50 -07:00
|
|
|
|
2013-05-17 16:08:53 -04:00
|
|
|
|
2006-10-11 01:20:50 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-05-17 16:08:53 -04:00
|
|
|
|
ext4: fix potential infinite loop in ext4_dx_readdir()
When ext4_htree_fill_tree() fails, ext4_dx_readdir() can run into an
infinite loop since if info->last_pos != ctx->pos this will reset the
directory scan and reread the failing entry. For example:
1. a dx_dir which has 3 block, block 0 as dx_root block, block 1/2 as
leaf block which own the ext4_dir_entry_2
2. block 1 read ok and call_filldir which will fill the dirent and update
the ctx->pos
3. block 2 read fail, but we has already fill some dirent, so we will
return back to userspace will a positive return val(see ksys_getdents64)
4. the second ext4_dx_readdir will reset the world since info->last_pos
!= ctx->pos, and will also init the curr_hash which pos to block 1
5. So we will read block1 too, and once block2 still read fail, we can
only fill one dirent because the hash of the entry in block1(besides
the last one) won't greater than curr_hash
6. this time, we forget update last_pos too since the read for block2
will fail, and since we has got the one entry, ksys_getdents64 can
return success
7. Latter we will trapped in a loop with step 4~6
Cc: stable@kernel.org
Signed-off-by: yangerkun <yangerkun@huawei.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Link: https://lore.kernel.org/r/20210914111415.3921954-1-yangerkun@huawei.com
2021-09-14 19:14:15 +08:00
|
|
|
|
2006-10-11 01:20:50 -07:00
|
|
|
|
|
|
|
|
|
2008-09-08 22:25:24 -04:00
|
|
|
|
2006-10-11 01:20:50 -07:00
|
|
|
|
2006-10-11 01:21:24 -07:00
|
|
|
|
2006-10-11 01:20:53 -07:00
|
|
|
|
2006-10-11 01:20:50 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-03-18 22:44:40 -04:00
|
|
|
|
2014-07-28 13:06:26 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-09-30 02:14:56 -04:00
|
|
|
|
2014-07-28 13:06:26 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-04-01 01:13:21 -07:00
|
|
|
|
2014-07-28 13:06:26 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-10-17 16:16:04 -04:00
|
|
|
|
2014-07-28 13:06:26 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-10-17 16:16:04 -04:00
|
|
|
|
2014-07-28 13:06:26 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-08-30 15:04:52 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2026-02-21 16:37:42 -08:00
|
|
|
|
2024-08-30 15:04:52 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-03-18 22:44:40 -04:00
|
|
|
|
2024-08-30 15:04:52 +02:00
|
|
|
|
2012-03-18 22:44:40 -04:00
|
|
|
|
|
|
|
|
|
2016-05-12 20:36:01 -04:00
|
|
|
|
2012-03-18 22:44:40 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2026-01-08 12:13:01 -05:00
|
|
|
|
2012-03-18 22:44:40 -04:00
|
|
|
|
