Age | Commit message (Collapse) | Author |
|
The performance and number of processes for a "depmod -a" with gzipped
modules was abysmal. This patch adds a code path without fork,
benefiting all users of xmalloc_open_zipped_read_close.
"modinfo radeon.ko.gz", a single-file reader, got 30% faster.
"depmod -a", which used to fork over 800 times, got 20% faster.
Heavily based on a patch by Lauri Kasanen <curaga@operamail.com>
function old new delta
setup_transformer_on_fd - 159 +159
transformer_write - 122 +122
fork_transformer - 112 +112
xmalloc_open_zipped_read_close 63 118 +55
read_bunzip 1866 1896 +30
xtransformer_write - 19 +19
unzip_main 2449 2462 +13
bbunpack 755 766 +11
unpack_lzma_stream 2717 2723 +6
unpack_xz_stream 2393 2397 +4
unpack_Z_stream 1173 1175 +2
inflate_unzip 111 105 -6
check_signature16 70 63 -7
unpack_bz2_stream 359 349 -10
unpack_unxz 12 - -12
unpack_unlzma 12 - -12
unpack_uncompress 12 - -12
unpack_gunzip 12 - -12
unpack_bunzip2 12 - -12
open_transformer 106 92 -14
inflate_unzip_internal 1945 1916 -29
unpack_gz_stream 693 655 -38
open_zipped 89 47 -42
setup_unzip_on_fd 142 53 -89
------------------------------------------------------------------------------
(add/remove: 4/5 grow/shrink: 7/8 up/down: 533/-295) Total: 238 bytes
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|
|
No code changes
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|
|
Otherwise, help text is confusing: where do operation modes end
and where options start?
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|
|
See CVE-2014-4607
http://www.openwall.com/lists/oss-security/2014/06/26/20
function old new delta
lzo1x_decompress_safe 1010 1031 +21
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|
|
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|
|
No code changes as verified by objdump
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|
|
function old new delta
buffer_fill_and_print 178 191 +13
varvalue 735 743 +8
bbunpack 747 755 +8
open_zipped 85 89 +4
xmalloc_open_zipped_read_close 61 63 +2
get_addr_1 240 242 +2
fbsplash_main 1228 1230 +2
pstree_main 322 321 -1
builtin_type 121 119 -2
do_load 954 926 -28
------------------------------------------------------------------------------
(add/remove: 0/0 grow/shrink: 7/3 up/down: 39/-31) Total: 8 bytes
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|
|
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|
|
function old new delta
get_header_tar 1785 1795 +10
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|
|
We only need to check for signature-less extensions,
currently only .lzma. The rest can be happily autodetected.
This fixes "zcat FILE_WITHOUT_GZ_EXT" case, among others.
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|
|
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|
|
Signed-off-by: Daniel Borca <dborca@yahoo.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|
|
function old new delta
tar_main 879 895 +16
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|
|
Testcase: tar xvzf EMPTY_FILE
function old new delta
open_transformer 102 106 +4
get_header_tar 1781 1785 +4
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|
|
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|
|
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|
|
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|
|
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|
|
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|
|
stage3-armv7a_hardfp-20130209.tar.bz2, 149189948 bytes long,
md5sum b29ce23312e14eb15a143377d4a38473, was failing to unpack.
It so happened that this file has a run which exactly fills
the 90k buffer. The check was "size >= bufsize", apparently
it has to be ">".
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|
|
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|
|
ar fields are fixed length text strings (padded with spaces). Ensure
bb_strtou doesn't read past the field in case the full width is used.
The fields are only read once, so the simplest/smallest solution to me
seems to be to just pass the length to read_num() and then zero terminate
the string before passing it to bb_strtou. This does mean that the fields
MUST be read in reverse order, so some minor reshuffling was needed.
Bloat-o-meter:
function old new delta
get_header_ar 394 414 +20
read_num 29 36 +7
------------------------------------------------------------------------------
(add/remove: 0/0 grow/shrink: 2/0 up/down: 27/0) Total: 27 bytes
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|
|
This fixes tar to order files in tarball correctly in this case:
$ touch 1 2 3; echo -e '1\n2\n3' | tar -T- -c | tar t
1
2
3
Signed-off-by: SASAKI Suguru <suguru@sonik.org>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|
|
function old new delta
bbunpack 634 731 +97
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|
|
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|
|
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|
|
Signed-off-by: Rich Felker <dalias@aerifal.cx>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|
|
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|
|
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|
|
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
|
|
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|
|
text data bss dec hex filename
1796 0 0 1796 704 decompress_unlzma.o
1801 0 0 1801 709 decompress_unlzma.o
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|
|
It is not slower. In fact it seems a tiny bit faster too.
text data bss dec hex filename
2827 0 0 2827 b0b decompress_unlzma.o
2797 0 0 2797 aed decompress_unlzma.o
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|
|
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|
|
Too much code shuffling.
Reported-by: Mandeep Singh Baines <msb@chromium.org>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
|
|
The -q flag is used in shell scripts for suppressing output.
Have our applets swallow the flag for compatibility.
Reported-by: Mandeep Singh Baines <msb@chromium.org>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
|
|
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|
|
function old new delta
bbunpack 526 622 +96
packed_usage 29335 29341 +6
gunzip_main 64 67 +3
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|
|
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|
|
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|
|
Signed-off-by: Leonid Lisovskiy <lly.dev@gmail.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|
|
function old new delta
xz_dec_reset - 77 +77
unpack_xz_stream 2402 2397 -5
Signed-off-by: Lasse Collin <lasse.collin@tukaani.org>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|
|
Signed-off-by: Lasse Collin <lasse.collin@tukaani.org>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|
|
xz_dec_run() could incorrectly return XZ_BUF_ERROR if
all of the following was true:
- The caller knows how many bytes of output to expect
and only provides that much output space.
- When the last output bytes are decoded, the
caller-provided input buffer ends right before
the LZMA2 end of payload marker. So LZMA2 won't
provide more output anymore, but it won't know it
yet and thus won't return XZ_STREAM_END yet.
- A BCJ filter is in use and it hasn't left any
unfiltered bytes in the temp buffer. This can happen
with any BCJ filter, but in practice it's more likely
with filters other than the x86 BCJ.
This fixes <https://bugzilla.redhat.com/show_bug.cgi?id=735408>
where Squashfs thinks that a valid file system is corrupt.
Thanks to Jindrich Novy for telling me that such a bug report
exists, Phillip Lougher for providing excellent debug info,
and other people on #fedora-ppc.
This also fixes a similar bug in single-call mode where the
uncompressed size of a XZ Block using BCJ + LZMA2 was 0 bytes
and caller provided no output space. Many empty .xz files
don't contain any Blocks and thus don't trigger this bug.
This also tweaks a closely related detail: xz_dec_bcj_run()
could call xz_dec_lzma2_run() to decode into temp buffer when
it was known to be useless. This was harmless although it
wasted a minuscule number of CPU cycles.
Signed-off-by: Lasse Collin <lasse.collin@tukaani.org>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|
|
No .xz encoder creates files with empty LZMA2 streams,
but such files would still be valid and decompressors
must accept them.
Note that empty .xz files are a different thing than
empty LZMA2 streams. This bug didn't affect typical .xz
files that had no uncompressed data.
Signed-off-by: Lasse Collin <lasse.collin@tukaani.org>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|
|
Signed-off-by: Lasse Collin <lasse.collin@tukaani.org>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|
|
Signed-off-by: Lasse Collin <lasse.collin@tukaani.org>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|
|
Signed-off-by: Lasse Collin <lasse.collin@tukaani.org>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|
|
Signed-off-by: Lasse Collin <lasse.collin@tukaani.org>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|
|
Signed-off-by: Lasse Collin <lasse.collin@tukaani.org>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|