From patchwork Thu Jul 12 03:27:57 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: NeilBrown X-Patchwork-Id: 1186501 Return-Path: X-Original-To: patchwork-linux-nfs@patchwork.kernel.org Delivered-To: patchwork-process-083081@patchwork2.kernel.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by patchwork2.kernel.org (Postfix) with ESMTP id 7BD0FDF25A for ; Thu, 12 Jul 2012 03:28:06 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756800Ab2GLD2F (ORCPT ); Wed, 11 Jul 2012 23:28:05 -0400 Received: from cantor2.suse.de ([195.135.220.15]:60931 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753738Ab2GLD2E (ORCPT ); Wed, 11 Jul 2012 23:28:04 -0400 Received: from relay2.suse.de (unknown [195.135.220.254]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx2.suse.de (Postfix) with ESMTP id 637E9A45FA; Thu, 12 Jul 2012 05:28:02 +0200 (CEST) Date: Thu, 12 Jul 2012 13:27:57 +1000 From: NeilBrown To: Steve Dickson Cc: NFS Subject: [PATCH] umount.nfs: restore correct error status when umount fails. Message-ID: <20120712132757.7f86b86b@notabene.brown> X-Mailer: Claws Mail 3.7.10 (GTK+ 2.24.7; x86_64-suse-linux-gnu) Mime-Version: 1.0 Sender: linux-nfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-nfs@vger.kernel.org If nfs-utils is built without --enable-libmount-mount, then an unmount that failed due to the filesystem being busy will exit with '16' - EX_FILEIO. Autofs apparently relies on this. When built with --enable-libmount-mount, the same case will exit with '32' - EX_FAIL. Normally this is reserved for internal errors. This patch restores the use of EX_FILEIO for errors from umount. Signed-off-by: NeilBrown --- I confess that I haven't done a complete case analysis to see that we are always using the correct error code, but this looks OK and handles the case I care about. There is a case that I know it doesn't handle. If you ask umount.nfs to unmount a filesystem that is not nfs or nfs4, then the old code will refuse umount.nfs: /dev/sda7 on /mnt2 is not an NFS filesystem and exit with status '1'. The new libmount code will just think that it couldn't find anything in fstab and will try to do an nfs23 unmount. This is clearly different behaviour, I'm not sure that anyone would care though. NeilBrown diff --git a/utils/mount/mount_libmount.c b/utils/mount/mount_libmount.c index e8f17a9..5c1116a 100644 --- a/utils/mount/mount_libmount.c +++ b/utils/mount/mount_libmount.c @@ -173,6 +173,7 @@ static int umount_main(struct libmnt_context *cxt, int argc, char **argv) { int rc, c; char *spec = NULL, *opts = NULL; + int ret = EX_FAIL; static const struct option longopts[] = { { "force", 0, 0, 'f' }, @@ -243,7 +244,7 @@ static int umount_main(struct libmnt_context *cxt, int argc, char **argv) /* strange, no entry in mtab or /proc not mounted */ nfs_umount23(spec, "tcp,v3"); } - + ret = EX_FILEIO; rc = mnt_context_do_umount(cxt); /* call umount(2) syscall */ mnt_context_finalize_mount(cxt); /* mtab update */ @@ -252,12 +253,10 @@ static int umount_main(struct libmnt_context *cxt, int argc, char **argv) umount_error(rc, spec); goto err; } - - free(opts); - return EX_SUCCESS; + ret = EX_SUCCESS; err: free(opts); - return EX_FAIL; + return ret; } static int mount_main(struct libmnt_context *cxt, int argc, char **argv)