Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 04 12月, 2013 2 次提交
  3. 25 4月, 2013 1 次提交
  5. 08 3月, 2013 1 次提交
    • S
      ktest: Allow tests to use different GRUB_MENUs · 752d9665
      由 Steven Rostedt (Red Hat) 提交于 
      To save connecting and searching for a given grub menu for each test,
ktest.pl will cache the grub number it found. The problem is that
different tests might use a different grub menu, but ktest.pl will
ignore it.

Instead, have ktest.pl check if the grub menu it used to cache the
content is the same as when it grabbed the menu. If not, grab it again,
otherwise just return the cached value.
Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>
      752d9665
  7. 06 3月, 2013 1 次提交
    • M
      efivars: efivarfs_valid_name() should handle pstore syntax · 123abd76
      由 Matt Fleming 提交于 
      Stricter validation was introduced with commit da27a243
("efivarfs: guid part of filenames are case-insensitive") and commit
47f531e8 ("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-<guid>.
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: NJoseph Yasi <joe.yasi@gmail.com>
Tested-by: NJoseph Yasi <joe.yasi@gmail.com>
Reported-by: NLingzhu Xiang <lxiang@redhat.com>
Cc: Josh Boyer <jwboyer@redhat.com>
Cc: Jeremy Kerr <jk@ozlabs.org>
Cc: Matthew Garrett <mjg59@srcf.ucam.org>
Cc: <stable@vger.kernel.org> # v3.8
Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
      123abd76
  9. 28 2月, 2013 5 次提交
  11. 18 2月, 2013 1 次提交
  13. 05 2月, 2013 2 次提交
    • S
      ktest: Ignore warnings during reboot · 4c0b67a2
      由 Steven Rostedt (Red Hat) 提交于 
      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: NSteven Rostedt <rostedt@goodmis.org>
      4c0b67a2
    • S
      ktest: Search for linux banner for successful reboot · d6845536
      由 Steven Rostedt (Red Hat) 提交于 
      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: NSteven Rostedt <rostedt@goodmis.org>
      d6845536
  15. 31 1月, 2013 4 次提交
    • S
      ktest: Add make_warnings_file and process full warnings · 4283b169
      由 Steven Rostedt (Red Hat) 提交于 
      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: NSteven Rostedt <rostedt@goodmis.org>
      4283b169
    • S
      ktest: Allow a test option to use its default option · 04262be3
      由 Steven Rostedt (Red Hat) 提交于 
      Options are allowed to use other options, for example:

  LOG_FILE = ${OUTPUT_DIR}/${MACHINE}.log

where the option LOG_FILE used the options OUTPUT_DIR and MACHINE.

But if a test option were to use a default option, it will not get
substituted:

  OUTPUT_DIR = ${THIS_DIR}/${MACHINE}

  TEST_START
  OUTPUT_DIR = ${OUTPUT_DIR}/t1

For the above test, OUTPUT_DIR will stay literally "${OUTPUT_DIR}/t1"
and not be converted to "${THIS_DIR}/${MACHINE}/t1". When the test runs,
it will pass the ${OUTPUT_DIR} to the shell, which would probaly
interpret it as "", and the output directory will end up as "/t1".

Change the code where if a test option has its own option name in
its defined field, and a default option exists, then substitute the
default option in its place.
Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>
      04262be3
    • S
      ktest: Strip off '\n' when reading which files were modified · 35275685
      由 Steven Rostedt (Red Hat) 提交于 
      The patchcheck test looks at what files are modified for each patch it
checks and makes sure that those files do not produce any warnings.

Unfortunately, when it read the diffstat, the newlines were added on the
files and this made compares miss warnings, and commits that should not
have passed, ktest let pass.

Fix this by using the perl command "chomp" that strips off whitespace at
the end of lines.
Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>
      35275685
    • S
      ktest: Do not require CONSOLE for build or install bisects · 319ab14f
      由 Steven Rostedt (Red Hat) 提交于 
      If the user is doing a build or install bisect, there's no reason to
have them define CONSOLE, as the console does not need to be read. The
console only needs to be read for boot tests.

CONSOLE is not required for normal build or install tests, let's not
require it for bisect tests with BISECT_TYPE of build or install.
Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>
      319ab14f
  17. 05 1月, 2013 1 次提交
  19. 18 12月, 2012 8 次提交
  21. 12 12月, 2012 5 次提交
  23. 14 11月, 2012 1 次提交
    • S
      ktest: Add support for grub2 · a15ba913
      由 Steven Rostedt 提交于 
      As only grub or 'script' is supported for rebooting to a new kernel,
and Fedora 17 has dropped support for grub, I decided to add grub2
support as well (I also plan on adding syslinux/extlinux support too).

The options GRUB_FILE and GRUB_REBOOT were added to allow the user
to specify where to find the grub.cfg and what tool to use to reboot
into the next kernel respectively.
Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>
      a15ba913
  25. 09 11月, 2012 1 次提交
    • A
      revert "epoll: support for disabling items, and a self-test app" · a80a6b85
      由 Andrew Morton 提交于 
      Revert commit 03a7beb5 ("epoll: support for disabling items, and a
self-test app") pending resolution of the issues identified by Michael
Kerrisk, copied below.

We'll revisit this for 3.8.

: I've taken a look at this patch as it currently stands in 3.7-rc1, and
: done a bit of testing. (By the way, the test program
: tools/testing/selftests/epoll/test_epoll.c does not compile...)
:
: There are one or two places where the behavior seems a little strange,
: so I have a question or two at the end of this mail. But other than
: that, I want to check my understanding so that the interface can be
: correctly documented.
:
: Just to go though my understanding, the problem is the following
: scenario in a multithreaded application:
:
: 1. Multiple threads are performing epoll_wait() operations,
:    and maintaining a user-space cache that contains information
:    corresponding to each file descriptor being monitored by
:    epoll_wait().
:
: 2. At some point, a thread wants to delete (EPOLL_CTL_DEL)
:    a file descriptor from the epoll interest list, and
:    delete the corresponding record from the user-space cache.
:
: 3. The problem with (2) is that some other thread may have
:    previously done an epoll_wait() that retrieved information
:    about the fd in question, and may be in the middle of using
:    information in the cache that relates to that fd. Thus,
:    there is a potential race.
:
: 4. The race can't solved purely in user space, because doing
:    so would require applying a mutex across the epoll_wait()
:    call, which would of course blow thread concurrency.
:
: Right?
:
: Your solution is the EPOLL_CTL_DISABLE operation. I want to
: confirm my understanding about how to use this flag, since
: the description that has accompanied the patches so far
: has been a bit sparse
:
: 0. In the scenario you're concerned about, deleting a file
:    descriptor means (safely) doing the following:
:    (a) Deleting the file descriptor from the epoll interest list
:        using EPOLL_CTL_DEL
:    (b) Deleting the corresponding record in the user-space cache
:
: 1. It's only meaningful to use this EPOLL_CTL_DISABLE in
:    conjunction with EPOLLONESHOT.
:
: 2. Using EPOLL_CTL_DISABLE without using EPOLLONESHOT in
:    conjunction is a logical error.
:
: 3. The correct way to code multithreaded applications using
:    EPOLL_CTL_DISABLE and EPOLLONESHOT is as follows:
:
:    a. All EPOLL_CTL_ADD and EPOLL_CTL_MOD operations should
:       should EPOLLONESHOT.
:
:    b. When a thread wants to delete a file descriptor, it
:       should do the following:
:
:       [1] Call epoll_ctl(EPOLL_CTL_DISABLE)
:       [2] If the return status from epoll_ctl(EPOLL_CTL_DISABLE)
:           was zero, then the file descriptor can be safely
:           deleted by the thread that made this call.
:       [3] If the epoll_ctl(EPOLL_CTL_DISABLE) fails with EBUSY,
:           then the descriptor is in use. In this case, the calling
:           thread should set a flag in the user-space cache to
:           indicate that the thread that is using the descriptor
:           should perform the deletion operation.
:
: Is all of the above correct?
:
: The implementation depends on checking on whether
: (events & ~EP_PRIVATE_BITS) == 0
: This replies on the fact that EPOLL_CTL_AD and EPOLL_CTL_MOD always
: set EPOLLHUP and EPOLLERR in the 'events' mask, and EPOLLONESHOT
: causes those flags (as well as all others in ~EP_PRIVATE_BITS) to be
: cleared.
:
: A corollary to the previous paragraph is that using EPOLL_CTL_DISABLE
: is only useful in conjunction with EPOLLONESHOT. However, as things
: stand, one can use EPOLL_CTL_DISABLE on a file descriptor that does
: not have EPOLLONESHOT set in 'events' This results in the following
: (slightly surprising) behavior:
:
: (a) The first call to epoll_ctl(EPOLL_CTL_DISABLE) returns 0
:     (the indicator that the file descriptor can be safely deleted).
: (b) The next call to epoll_ctl(EPOLL_CTL_DISABLE) fails with EBUSY.
:
: This doesn't seem particularly useful, and in fact is probably an
: indication that the user made a logic error: they should only be using
: epoll_ctl(EPOLL_CTL_DISABLE) on a file descriptor for which
: EPOLLONESHOT was set in 'events'. If that is correct, then would it
: not make sense to return an error to user space for this case?

Cc: Michael Kerrisk <mtk.manpages@gmail.com>
Cc: "Paton J. Lewis" <palewis@adobe.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      a80a6b85
  27. 26 10月, 2012 2 次提交
    • S
      ktest: Fix ktest confusion with CONFIG_MODULES_USE_ELF_RELA · 8bc5e4ea
      由 Steven Rostedt 提交于 
      In order to decide if ktest should bother installing modules on the
target box, it checks if the config file has CONFIG_MODULES=y. But it
also checks if the '=y' part exists. It only will install modules if the
config exists and is set with '=y'. But as the regex that was used
tests:

  /^CONFIG_MODULES(=y)?/

this will also match:

  CONFIG_MODULES_USE_ELF_RELA

as the '=y' part was optional and it did not test the rest of the line.
When this happens, ktest will stop checking the rest of the configs but
it will also think that no modules are needed to be installed. What it
should do is only jump out of the loop if it actually found a
CONFIG_MODULES that is set to true.

Otherwise, ktest wont install the necessary modules needed for proper
booting of the test target.
Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>
      8bc5e4ea
    • D
      tools/testing/selftests/epoll/test_epoll.c: fix build · fc314d0a
      由 Daniel Hazelton 提交于 
      Latest Linus head run of "make selftests" in the tools directory failed
with references to undefined variables.  Reference was to
'write_thread_data' which is the name of a struct that is being used, not
the variable itself.  Change reference so it points to the variable.
Signed-off-by: NDaniel Hazelton <dshadowwolf@gmail.com>
Cc: "Paton J. Lewis" <palewis@adobe.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      fc314d0a
  29. 06 10月, 2012 1 次提交
  31. 28 9月, 2012 1 次提交
  33. 27 9月, 2012 1 次提交
    • S
      ktest: Fix ELSE IF statements · 95f57838
      由 Steven Rostedt 提交于 
      The ELSE IF statements do not work as expected if another ELSE statement
follows. This is because the $if_set is not set. If the ELSE IF
condition is true, the following ELSE should be ignored. But because the
$if_set is not set, the following ELSE will also be executed.
Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>
      95f57838
  35. 01 9月, 2012 1 次提交
  37. 01 8月, 2012 1 次提交