linux/tools/testing, branch v3.9

efivars: efivarfs_valid_name() should handle pstore syntax

2013-03-06T14:46:04Z

Stricter validation was introduced with commit da27a24383b2b ("efivarfs: guid part of filenames are case-insensitive") and commit 47f531e8ba3b ("efivarfs: Validate filenames much more aggressively"), which is necessary for the guid portion of efivarfs filenames, but we don't need to be so strict with the first part, the variable name. The UEFI specification doesn't impose any constraints on variable names other than they be a NULL-terminated string. The above commits caused a regression that resulted in users seeing the following message, $ sudo mount -v /sys/firmware/efi/efivars mount: Cannot allocate memory whenever pstore EFI variables were present in the variable store, since their variable names failed to pass the following check, /* GUID should be right after the first '-' */ if (s - 1 != strchr(str, '-')) as a typical pstore filename is of the form, dump-type0-10-1-. The fix is trivial since the guid portion of the filename is GUID_LEN bytes, we can use (len - GUID_LEN) to ensure the '-' character is where we expect it to be. (The bogus ENOMEM error value will be fixed in a separate patch.) Reported-by: Joseph Yasi Tested-by: Joseph Yasi Reported-by: Lingzhu Xiang Cc: Josh Boyer Cc: Jeremy Kerr Cc: Matthew Garrett Cc: # v3.8 Signed-off-by: Matt Fleming

selftests: add a simple doc

2013-02-28T03:10:24Z

This change adds a little documentation to the tests under tools/testing/selftests/, based on akpm's explanation. [akpm@linux-foundation.org: move from Documentation to tools/testing/selftests/README.txt] Signed-off-by: Jeremy Kerr Cc: Dave Young Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

tools/testing/selftests/Makefile: rearrange targets

2013-02-28T03:10:24Z

Do it one-per-line to reduce patch conflict pain. Cc: Dave Young Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

selftests/efivarfs: add create-read test

2013-02-28T03:10:24Z

Test that reads from a newly-created efivarfs file (with no data written) will return EOF. Signed-off-by: Jeremy Kerr Cc: Matt Fleming Cc: Lingzhu Xiang Cc: Dave Young Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

selftests/efivarfs: add empty file creation test

2013-02-28T03:10:24Z

Signed-off-by: Jeremy Kerr Cc: Matt Fleming Cc: Lingzhu Xiang Cc: Dave Young Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

selftests: add tests for efivarfs

2013-02-28T03:10:24Z

This change adds a few initial efivarfs tests to the tools/testing/selftests directory. The open-unlink test is based on code from Lingzhu Xiang. Signed-off-by: Jeremy Kerr Cc: Matt Fleming Cc: Lingzhu Xiang Cc: Dave Young Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

ktest: Remove indexes from warnings check

2013-02-18T14:35:49Z

The index of a line where a warning is tested can be returned differently on different versions of gcc (or same version compiled differently). That is, a tab + space can give different results. This causes the warning check to produce a false positive. Removing the index from the check fixes this issue. Signed-off-by: Steven Rostedt

ktest: Ignore warnings during reboot

2013-02-05T15:02:37Z

The reboot just wants to get to the next kernel. But if a warning (Call Trace) appears, the monitor will report an error, and the reboot will think something went wrong and power cycle the box, even though we successfully made it to the next kernel. Ignore warnings during the reboot until we get to the next kernel. It will still timeout if we never get to the next kernel and then a power cycle will happen. That's what we want it to do. Signed-off-by: Steven Rostedt

ktest: Search for linux banner for successful reboot

2013-02-05T15:00:20Z

Sometimes when a test kernel passed fine, but on reboot it crashed, ktest could get stuck and not proceed. This would be frustrating if you let a test run overnight to find out the next morning that it was stuck on the first test. To fix this, I made reboot check for the REBOOT_SUCCESS_LINE. If the line was not detected, then it would power cycle the box. What it didn't cover was if the REBOOT_SUCCESS_LINE wasn't defined or if a 'good' kernel did not display the line. Instead have it search for the Linux banner "Linux version". The reboot just needs to get to the start of the next kernel, it does not need to test if the next kernel makes it to a boot prompt. After we find the next kernel has booted, then we just wait for either the REBOOT_SUCCESS_LINE to appear or the timeout. Signed-off-by: Steven Rostedt

ktest: Add make_warnings_file and process full warnings

2013-01-31T15:24:56Z

Although the patchcheck test checks for warnings in the files that were changed, this check does not catch warnings that were caused by header file changes and the warnings appear in C files not touched by the commit. Add a new option called WARNINGS_FILE. If this option is set, then the file it points to is read before bulid, and the file should contain a list of known warnings. If a warning appears in the build, this file is checked, and if the warning does not exist in this file, then it fails the build showing the new warning. If the WARNINGS_FILE points to a file that does not exist, this will cause any warning in the build to fail. A new test is also added called "make_warnings_file". This test will create do a build and record any warnings it finds into the WARNINGS_FILE. This test is something that can be run before other tests to build a warnings file of "known warnings", ie, warnings that were there before your changes. Signed-off-by: Steven Rostedt