Uploaded image for project: 'Lustre'
  1. Lustre
  2. LU-843

Several minor issues

    XMLWordPrintable

Details

    • Bug
    • Resolution: Fixed
    • Minor
    • Lustre 2.2.0, Lustre 2.1.1
    • Lustre 2.1.0, Lustre 1.8.x (1.8.0 - 1.8.5)
    • None
    • Linux x86-64 and likely all others
    • 3
    • 4801

    Description

      shmem_bump() modifies bumped_running without lock

      {en,dis}able-ext4 config option is not correctly handled
      Redirecting stdin in a while loop can trigger subshell.
      get_ec_devno() in libecho mishandles results

      Detailed commit messages to private repository:

      shmem_bump() modifies bumped_running without lock

      Each of several threads could sleep after the shmem_unlock call
      allowing following threads to see bumped_running set to false. It
      should be set to true inside the guarded "then" clause still under the
      shmem_lock() protection. A side effect is that it will only ever be
      set to true once.

      ====

      correctly handle –{en,dis}

      able-ext4 config option

      Some configurations require ext4 use, some prohibit it, and some
      can use either. This rewrite enforces constraints and allows
      enabling and disabling when either is possible.

      Remove dead stores to unused "ldiskfs_is_ext4" variable.

      ====

      Redirecting stdin in a while loop can trigger subshell.

      That causes variables changed in the loop to loose their changes.
      (POSIX does not require "while" loops in shell scripts to be performed
      in the same environment when stdin is redirected. "bash" does not
      commit to maintaining current behavior.) Therefore, read input from
      fd 3. Also:

      • Eliminate unnecessary fork/exec calls since the analysis
        can readily be done in the same shell process.
      • Ensure that all error paths do emit ERROR to stdout.
      • Ensure "libecho" comes from obdfilter-survey dir.
      • Ignore files created by "patch" program.

      ====

      get_ec_devno() in libecho mishandles results

      The results from this function are returned by echoing them to stdout. This
      needs to be done more safely because other functions that it invokes
      (e.g. "remote_shell") can drop detritus into stdout (viz., a terminal control
      escape sequence) that mutilates results.

      The fundamental bug is that readline(3GNU) should never emit terminal
      control sequences to stdout. It should be stderr, especially when stdin is
      not a terminal. We won't be fixing the readline function, but we can mitigate
      the bug by dumping unneeded stdout output to stderr or /dev/null.

      So, the solution is to clone stdout fd, redirect stdout to an alternate fd
      (stderr) and echo results to the cloned fd.

      Since this works only as a code fragment with redirected stdout, it must,
      perforce, be running in a subshell. The "return" statements need to be "exit"
      statements, with the proper success/fail indication. This is not currently
      used, but should be more reliable than checking the result count.

      Attachments

        Issue Links

          Activity

            People

              mdiep Minh Diep
              bkorb Bruce Korb (Inactive)
              Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: