mtd-utils.git/tests, branch v1.5.1

integck: fix identation a bit

2013-03-11T08:44:29+00:00

Signed-off-by: Artem Bityutskiy

integck.c: Fix buffer overflow in save_file

2013-03-11T08:40:23+00:00

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: 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) Signed-off-by: Elie De Brauwer Signed-off-by: Artem Bityutskiy

integck.c: rework file_check_data to immediately dump the buffer containing the errors

2013-03-11T08:36:02+00:00

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 Signed-off-by: Artem Bityutskiy

integck.c: Only verify the operation after all datastructures have been updated

2013-03-11T08:33:58+00:00

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 ... 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 Signed-off-by: Artem Bityutskiy

ubi-tests: fix pthreads linking

2012-12-03T13:16:55+00:00

Technically, '-l' linker options should be included only after the objects which must link to the library. So when we include '-lpthread' in the LDFLAGS variable, it gets placed too early (i.e., before the io_paral.o object), and so the pthread linkage never occurs. The following error probably only shows up with linkers that don't link pthreads by default. $ make tests V=1 ... gcc -I../../ubi-utils//include -I ../../include -lpthread -Wall -Wextra -Wwrite-strings -Wno-sign-compare -ffunction-sections -fdata-sections -Wl,--gc-sections -g -o /home/norris/git/mtd-utils/tests/ubi-tests/io_paral /home/norris/git/mtd-utils/tests/ubi-tests/io_paral.o /home/norris/git/mtd-utils/tests/ubi-tests/helpers.o libubi.a /home/norris/git/mtd-utils/tests/ubi-tests/io_paral.o: In function `main': /home/norris/git/mtd-utils/tests/ubi-tests/io_paral.c:287: undefined reference to `pthread_create' /home/norris/git/mtd-utils/tests/ubi-tests/io_paral.c:295: undefined reference to `pthread_create' /home/norris/git/mtd-utils/tests/ubi-tests/io_paral.c:303: undefined reference to `pthread_join' collect2: ld returned 1 exit status make[2]: *** [/home/norris/git/mtd-utils/tests/ubi-tests/io_paral] Error 1 ... $ ld --version GNU ld (GNU Binutils for Ubuntu) 2.22 ... $ gcc --version gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3 ... Signed-off-by: Brian Norris Signed-off-by: Artem Bityutskiy

ubi-tests: switch to using common.h from the top level

2012-11-16T08:09:54+00:00

Sorry, the commit is huge, I just did not have time to split it. Signed-off-by: Artem Bityutskiy

ubi-tests: rename common.[ch] to helpers.[ch]

2012-11-16T07:52:21+00:00

... to avoid confusion when the local common.h shadows the top-level common.h. Signed-off-by: Artem Bityutskiy

ubi-tests: ubi_leb_change_start() no longer uses 'dtype'.

2012-11-16T07:35:25+00:00

This will not compile for me (due to bit rot?). Maybe the program is never used? Signed-off-by: Bill Pringlemeir Signed-off-by: Artem Bityutskiy

consistency between u_int32_t / off_t / off64_t

2012-09-25T15:06:50+00:00

We should use the off_t type instead of off64_t or u_int32_t as its length is controlled by the WITHOUT_LARGEFILE flag. Signed-off-by: Richard Genoud Signed-off-by: Artem Bityutskiy

tests: io_update correct lseek parameters order

2012-09-25T14:04:41+00:00

There's a typo in lseek parameters order. But, due to the value of SEEK_SET, this commit doesn't introduce a change. Signed-off-by: Richard Genoud Signed-off-by: Artem Bityutskiy