[LU-843] Several minor issues

Fri, 24 Feb 2012 01:28:20 +0000

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.

Whamcloud Community JIRA

[LU-843] Several minor issues