A mirror of http://git.infradead.org/mtd-utils.git https://git.infraroot.at/mtd-utils.git/atom?h=v2.0.0-rc2 2016-11-17T10:36:55+00:00 2016-11-17T10:36:55+00:00 David Oberhollenzer david.oberhollenzer@sigma-star.at 2016-09-01T09:20:05+00:00 urn:sha1:3516b8b7558a69dfd06410b0c997d096a78221c9 This patch adds a libmissing library to mtd-utils, containing implementations of functionality found in glibc but typically missing from embedded C libraries such as uclibc ot musl. For now, the library only contains stub implementations of the backtrace*() family of functions. Signed-off-by: David Oberhollenzer <david.oberhollenzer@sigma-star.at> Signed-off-by: Richard Weinberger <richard@nod.at> 2016-11-17T10:36:55+00:00 David Oberhollenzer david.oberhollenzer@sigma-star.at 2016-07-19T13:06:58+00:00 urn:sha1:7dd42c510dc8ab10f52dcc2d20dc8af412be0744 When a program does sophisticated enough command line processing (i.e. getopt), make sure it responds to -V and --version. When a program prints a version string, make sure it uses the common_print_version macro to print out its name, that it is part of mtd-utils and the mtd-utils version from the build system in a fashion similar to common program packages like the GNU coreutils. When a program responds to -V/--version or -h/--help, make sure it reports success exit status. Signed-off-by: David Oberhollenzer <david.oberhollenzer@sigma-star.at> Signed-off-by: Richard Weinberger <richard@nod.at> 2016-11-17T10:36:55+00:00 David Oberhollenzer david.oberhollenzer@sigma-star.at 2016-07-13T14:10:28+00:00 urn:sha1:8a00021b2ab5529640e5acaca30a27cdaca04178 Add automake files for the test binaries. If configured to do so, install the test binaries to libexec/mtd-utils and use autoconf to fix the paths in the test scripts. Signed-off-by: David Oberhollenzer <david.oberhollenzer@sigma-star.at> Signed-off-by: Richard Weinberger <richard@nod.at> 2016-08-25T13:33:09+00:00 Rahul Bedarkar rahul.bedarkar@imgtec.com 2016-08-18T17:41:30+00:00 urn:sha1:fd6fc61227867179c87b6ee5d2199b3976ffef12 In commit ca7a5eda221d("integck.c: Fix buffer overflow in save_file") we started including header <bits/stdio_lim.h>. But with musl C library, we get following build error integck.c:37:28: fatal error: bits/stdio_lim.h: No such file or directory #include <bits/stdio_lim.h> ^ compilation terminated. make[2]: *** [integck] Error 1 Header <bits/stdio_lim.h> is not available in musl C library. However <stdio.h> has all definition that <bits/stdio_lim.h> supposed to be providing. Moreover <bits/stdio_lim.h> shouldn't be included directly instead we should be using <stdio.h>. Since we already include <stdio.h> and in case of uClibc or glibc <bits/stdio_lim.h> gets included internally, we can safely remove it. This build issue is found by Buildroot autobuilder http://autobuild.buildroot.net/results/175/1754861457af520480cc34d7d2d0edff2868ff66/ Fixes: ca7a5eda221d("integck.c: Fix buffer overflow in save_file") Signed-off-by: Rahul Bedarkar <rahul.bedarkar@imgtec.com> Signed-off-by: Richard Weinberger <richard@nod.at> 2015-07-06T21:39:59+00:00 Dongsheng Yang yangds.fnst@cn.fujitsu.com 2015-06-29T08:49:18+00:00 urn:sha1:eb3f8a53e92b250b1086b216da7049eff0bd4589 Test integck requires a parameter but run_all.sh did no pass any to it. Then: integck: error!: test file-system was not specified (use -h for help) Signed-off-by: Dongsheng Yang <yangds.fnst@cn.fujitsu.com> Reviewed-by: Richard Weinberger <richard@nod.at> Signed-off-by: Brian Norris <computersforpeace@gmail.com> 2014-04-15T13:01:12+00:00 Mats Kärrman mats.karrman@tritech.se 2014-04-11T07:38:21+00:00 urn:sha1:7556c09cbac5c9d8a7a6d9c7c4bb736e2c472366 Not using the macros may be a problem when cross-compiling. Signed-off-by: Mats Karrman <mats.karrman@tritech.se> Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com> 2013-03-11T08:44:29+00:00 Artem Bityutskiy artem.bityutskiy@linux.intel.com 2013-03-11T08:44:29+00:00 urn:sha1:c8f34d79c4f5d6f061d744538949167afa803f5f Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com> 2013-03-11T08:40:23+00:00 Elie De Brauwer eliedebrauwer@gmail.com 2013-03-01T18:37:39+00:00 urn:sha1:ca7a5eda221d53aa571836a6186ed117c804d702 In the problem above I've spend several hours waiting for the issue to appear, only to had the 'luck' that it was found in a file whose name was 256 bytes in length, resulting in the write to fail. Closer examination showed that the buffer to store the path was 256 bytes in length, but this buffer also includes /tmp and the read/write suffix and should be able to contain a filename which is up to 255 bytes (NAME_MAX in linux/limits.h) in size which is a bad fit. So that array is modified to FILENAME_MAX (stdio_lim.h) and some checking is added to truncate the filename should it cause an overflow. The following log shows the first patch in action (see the correct seed), and shows why this third patch is needed: <quote> integck:     File Data: integck:         Offset: 0  Size: 1  Seed: 5008310  R.Off: 0 integck:     1 writes integck:     ============================================ integck:     Write Info: integck:         Offset: 0  Size: 1  Seed: 5008310  R.Off: 0 integck:         Offset: 0  Size: 1  Seed: 8246352  R.Off: 0 integck:         Offset: 0  Size: 1  Seed: 5078796  R.Off: 0 integck:         Offset: 0  Size: 1  Seed: 2267087  R.Off: 0 integck:         Offset: 0  Size: 1  Seed: 3602680  R.Off: 0 integck:     5 writes or truncations integck:     ============================================ integck: Saving /tmp/yqcnfygfitaatyeyvffrguegcdttamcnyhowhgieljfuxfipiljsjcbluaeaghwyinkggommsbwnmvekihgnwgiibccpbwfrpxuxwkmnyghnutrudienngxwgorudbskedaaekiuiyqksfazrwzfwbfhzjjqoiulebtlpbfiuffmsnguqkjzqjqizimsmhbqqagaebjdhqwmzdxghiavtcxubegawlgtvstuqurkurpnrckjfkgostdtpg.integ.sav.readn integck: error!: condition 'w_fd != -1' failed in save_file() at integck.c:1445 integck: error 36 (File name too long) </quote> Signed-off-by: Elie De Brauwer <eliedebrauwer@gmail.com> Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com> 2013-03-11T08:36:02+00:00 Elie De Brauwer eliedebrauwer@gmail.com 2013-03-01T18:37:38+00:00 urn:sha1:3ff90433ab22c001215d9a26c65de1b7f448dc79 See my problem description int the previous commit, the point is that integck in file_check_data reads a buffer, and then checks if the data is correct,  it will do a seek(0), and reread from the same fd. The point is that in the scenario I observed integck failed (due to a buffer mismatch) but the it saved (and what was in flash) was actually correct. So I modified this function to dump the buffers to stderr at the moment an error is found. Signed-off-by: Elie De Brauwer <eliedebrauwer@gmail.com> Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com> 2013-03-11T08:33:58+00:00 Elie De Brauwer eliedebrauwer@gmail.com 2013-03-01T18:37:37+00:00 urn:sha1:681d1d6c311ac918986e964f65097d556b2acd78 <quote> integck: File Data: integck: Offset: 0 Size: 196 Seed: 5999877 R.Off: 0 integck: Offset: 196 Size: 33 Seed: 4160795 R.Off: 0 integck: Offset: 229 Size: 1252 Seed: 8070052 R.Off: 0 integck: Offset: 1481 Size: 612 Seed: 4160795 R.Off: 1285 integck: Offset: 2093 Size: 6 Seed: 6946586 R.Off: 0 integck: Offset: 2099 Size: 536 Seed: 4160795 R.Off: 1903 integck: Offset: 2635 Size: 1562 Seed: 9845455 R.Off: 0 integck: Offset: 4197 Size: 80 Seed: 702818 R.Off: 0 integck: Offset: 4277 Size: 115 Seed: 9845455 R.Off: 1642 integck: 9 writes integck: ============================================ integck: Write Info: integck: Offset: 826 Size: 357 Seed: 5908448 R.Off: 0 integck: Offset: 4197 Size: 80 Seed: 702818 R.Off: 0 ... </quote> And I would expect the file data listing to include at offset 826 something with a size of 357 and a seed of 5908448. Clearly it is not there (which is already extremely confusing). The point is that file_write_info first updates the raw_write, then verifies the data (passing the new write) and only after that updates the write structure. But in file_check_data only the newly written data is verified (passed as an argument) whilst the save_file() function to dump the file uses the raw_writes to recreate the written data (while raw_writes is only updated after after this check would have succeeded). Several lines to say that in this patch the verify only gets called _after_ the datastructures are updated. Signed-off-by: Elie De Brauwer <eliedebrauwer@gmail.com> Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>