mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: ebiederm@xmission.com (Eric W. Biederman)
To: Al Viro <viro@ZenIV.linux.org.uk>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	NeilBrown <neilb@suse.de>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	lkml <linux-kernel@vger.kernel.org>
Subject: Re: Is lockref_get_not_zero() really correct in dget_parent()
Date: Tue, 05 Aug 2014 15:58:37 -0700	[thread overview]
Message-ID: <87ha1qwnky.fsf@x220.int.ebiederm.org> (raw)
In-Reply-To: <20140805051439.GQ18016@ZenIV.linux.org.uk> (Al Viro's message of "Tue, 5 Aug 2014 06:14:39 +0100")

Al Viro <viro@ZenIV.linux.org.uk> writes:

> Speaking of bogosities, apparently nobody has noticed that automagical
> turning BSD process accounting off upon r/o remounts of the filesystem
> hosting the log got broken several years ago.  Suppose we find an opened
> log when remounting.  OK, it gets closed, which means filp_close(...).
> Which means that actual closing that sucker will happen just before we
> return to userland.  Return with -EBUSY, since the filesystem still has
> a file opened for write when we get around to checking that...
>
> I have kinda-sorta fixes for that (basically, restoring the situation we
> used to have before delayed fput() and being damn careful about avoiding
> deadlocks), but I would really love to just rip that idiocy out.  IOW,
> just let it fail with -EBUSY in such cases, same as for any other write-opened
> file on that fs.
>
> That, BTW, is the most painful part of the acct series, so being able to
> drop it would be very nice.  Comments?

Long ago in this discucssion someone mentioned that fedora and related
distro's don't have (or at least didn't have) code to close the
accounting files before unmount during shutdown.  I just checked the
debain acct package and it very clearly turns off accounting before
unmount (so debian should not care).

So the practical test is will returning -EBUSY cause fedora based
distro's it fail to unmount filesystems cleanly (looking at the code
and postualting bsd process accounting being left on) I think such
a change will cause such systems to fail to unmount their filesystems
on shutdown/reboot and cause problems because of that.

Eric

      reply	other threads:[~2014-08-05 23:02 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-08-05  3:17 NeilBrown
2014-08-05  4:07 ` Linus Torvalds
2014-08-05  4:54   ` Steven Noonan
2014-08-05  4:56     ` Steven Noonan
2014-08-05 16:53       ` Linus Torvalds
2014-08-05  5:14   ` Al Viro
2014-08-05 22:58     ` Eric W. Biederman [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=87ha1qwnky.fsf@x220.int.ebiederm.org \
    --to=ebiederm@xmission.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=neilb@suse.de \
    --cc=torvalds@linux-foundation.org \
    --cc=viro@ZenIV.linux.org.uk \
    /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

all inboxes | Powered by JetHome®