[LU-3023] Fix fuzzy logic in get_root_path()

Wed, 26 Mar 2014 13:38:30 +0000

While analyzing the Lustre code with Coverity, we found an incorrect logic in the get_root_path() function.

Here is Andreas' comment from http://review.whamcloud.com/#patch,sidebyside,5271,5,lustre/utils/liblustreapi.c:
"In that case, why have the "if (!ptr" check above? Probably Coverity is confused that ptr is checked against NULL above, but can fall through in the "len != 0" case and dereference the NULL ptr.

I suspect the reader and coverity would be happier if there was "LASSERT(ptr != NULL)" after strrchr(), though definitely your comment clearly explains why this LASSERT() would be true, and it should be kept.

Code style says this should have been "if (ptr == NULL && len == 0)". This makes me wonder about the above check as well. Why should the scanning be aborted if (len == 0) (i.e. no other mountpoint is found)? Since IMHO it should just continue on, and ptr is never NULL, I think the above check and -EINVAL could just be removed, perhaps in a separate patch."

I will propose a patch to address remark from Andreas.

Whamcloud Community JIRA

[LU-3023] Fix fuzzy logic in get_root_path()