I'm not exactly sure this is the safest thing to do since you can pass -oremount on the first mount and skip option validation. Maybe someone with better insight into the mount paths could comment. Does mount need some refactoring? Its logic seems arcane.. and I think there is a lot of dead code. This is very quick attempt to fix https://bugzilla.redhat.com/show_bug.cgi?id=1313550 8<------------------------------------------------------------------------- A remount might fail if name resolution returns a different server address for the mount. Since we've already validated the options the first time, skip validation if remounting. Signed-off-by: Benjamin Coddington <bcodding@xxxxxxxxxx> --- utils/mount/stropts.c | 6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/utils/mount/stropts.c b/utils/mount/stropts.c index 86829a9..9383bb4 100644 --- a/utils/mount/stropts.c +++ b/utils/mount/stropts.c @@ -1090,15 +1090,15 @@ static const char *nfs_background_opttbl[] = { static int nfsmount_start(struct nfsmount_info *mi) { - if (!nfs_validate_options(mi)) - return EX_FAIL; - /* * Avoid retry and negotiation logic when remounting */ if (mi->flags & MS_REMOUNT) return nfs_remount(mi); + if (!nfs_validate_options(mi)) + return EX_FAIL; + if (po_rightmost(mi->options, nfs_background_opttbl) == 0) return nfsmount_bg(mi); else -- 1.7.1 -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
