From: Steve Dickson <SteveD@redhat.com>
To: Steve Dickson <steved@redhat.com>
Cc: Linux NFS Mailing list <linux-nfs@vger.kernel.org>
Subject: Re: [PATCH 1/1] mount.nfs: mtab corruption when RLIMIT_FSIZE causes a partial write
Date: Wed, 19 Oct 2011 15:44:28 -0400 [thread overview]
Message-ID: <4E9F289C.2070003@RedHat.com> (raw)
In-Reply-To: <1319038470-17750-1-git-send-email-steved@redhat.com>
It turns out this is only a RHEL6 bug. I (stupidly) made the assumption that
since the RHEL6 patch cleanly applied to upstream, both streams worked
in the same way... which is not the case.
With upstream, this mtab code is not even compiled when the libmount
code is enabled. Secondly, with later systems /etc/mtab is symbolically
linked to /proc/mounts, making the file read-only. Finally when
/etc/mtabs is a regular file and is writeable, the SIGXFSZ
signal is handled properly in lock_mtab() so there is no corruption.
Sorry for the noise.
steved.
On 10/19/2011 11:34 AM, Steve Dickson wrote:
> This patch is a following on to commit 7a802337. Using the
> tool in https://bugzilla.redhat.com/show_bug.cgi?id=695916
> caused the fflush() and fclose() to fail in turn causing
> corruption in the mtab.
>
> The failures were in the internals of both calls. Switch those
> calls with the actual system calls eliminated the failures.
>
> Signed-off-by: Steve Dickson <steved@redhat.com>
> ---
> support/nfs/nfs_mntent.c | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/support/nfs/nfs_mntent.c b/support/nfs/nfs_mntent.c
> index a2118a2..b80f270 100644
> --- a/support/nfs/nfs_mntent.c
> +++ b/support/nfs/nfs_mntent.c
> @@ -117,7 +117,7 @@ void
> nfs_endmntent (mntFILE *mfp) {
> if (mfp) {
> if (mfp->mntent_fp)
> - fclose(mfp->mntent_fp);
> + close(fileno(mfp->mntent_fp));
> if (mfp->mntent_file)
> free(mfp->mntent_file);
> free(mfp);
> @@ -147,7 +147,7 @@ nfs_addmntent (mntFILE *mfp, struct mntent *mnt) {
> free(m3);
> free(m4);
> if (res >= 0) {
> - res = fflush(mfp->mntent_fp);
> + res = fsync(fileno(mfp->mntent_fp));
> if (res < 0)
> /* Avoid leaving a corrupt mtab file */
> ftruncate(fileno(mfp->mntent_fp), length);
prev parent reply other threads:[~2011-10-19 19:44 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-10-19 15:34 [PATCH 1/1] mount.nfs: mtab corruption when RLIMIT_FSIZE causes a partial write Steve Dickson
2011-10-19 16:36 ` Jeff Layton
2011-10-19 17:10 ` Steve Dickson
2011-10-19 17:22 ` Jeff Layton
2011-10-19 17:30 ` Steve Dickson
2011-10-19 17:36 ` J. Bruce Fields
2011-10-19 18:38 ` Steve Dickson
2011-10-19 19:55 ` J. Bruce Fields
2011-10-19 20:00 ` Steve Dickson
2011-10-19 20:01 ` J. Bruce Fields
2011-10-19 17:40 ` Jeff Layton
2011-10-19 18:00 ` Steve Dickson
2011-10-19 17:28 ` J. Bruce Fields
2011-10-19 17:32 ` Steve Dickson
2011-10-19 17:39 ` J. Bruce Fields
2011-10-19 19:44 ` Steve Dickson [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4E9F289C.2070003@RedHat.com \
--to=steved@redhat.com \
--cc=linux-nfs@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).