public inbox for linux-fsdevel@vger.kernel.org
 help / color / mirror / Atom feed
From: Al Viro <viro@ZenIV.linux.org.uk>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>
Subject: Re: [PATCH] mnt: Fix a memory stomp in umount
Date: Fri, 19 Dec 2014 00:02:15 +0000	[thread overview]
Message-ID: <20141219000215.GR22149@ZenIV.linux.org.uk> (raw)
In-Reply-To: <87d27ghd1i.fsf@x220.int.ebiederm.org>

On Thu, Dec 18, 2014 at 03:18:49PM -0600, Eric W. Biederman wrote:

> We might have wanted to because before your change to an hlist that is
> what the code did.
> 
> Having read through the code of propagate_next it does look like it
> iterates through the entire propagation hierarchy so there shouldn't be
> a need to visit mounts that we have placed on the propagation list.
> 
> Any thoughts on using mnt_list instead of mnt_hash to allow the use of
> list_splice and list_move?

Frankly, I don't see much benefit in that.  What's wrong with actually
adding
__hlist_splice(struct hlist_node *head,
	       struct hlist_node *tail,
	       struct hlist_node **where)
{
	next = *where;
	*where = head;
	head->pprev = where;
	if (next) {
		tail->next = next;
		next->pprev = tail;
	}
}

and use it as
	__hlist_splice(tmp_list.first, &last->mnt_hash, &unmounted.first);
(and I'd start with if (unlikely(!mnt)) return; /* idiot caller */)

Another primitive would be something like
hlist_transplant(struct hlist_head **from, struct hlist_head **to)
{
	*to = *from;
	if (!hlist_empty(*to)) {
		to->first->pprev = to;
		INIT_HLIST_HEAD(from);
	}
}

with namespace_unlock() starting with
	hlist_transplant(&head, &unmounted);
	if (likely(hlist_empty(&head))) {
                up_write(&namespace_sem);
                return;
	}
        /* undo decrements we'd done in umount_tree() */
	...

Linus, would that work for you, or would you prefer something more fancy?

  reply	other threads:[~2014-12-19  0:02 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-12-18 16:57 [PATCH] mnt: Fix a memory stomp in umount Eric W. Biederman
     [not found] ` <CA+55aFz6grtss0SXqOizXMOOF4sxT3FC4GC4NCiMF2Huy1vE4A@mail.gmail.com>
2014-12-18 18:41   ` Linus Torvalds
2014-12-18 19:24     ` Eric W. Biederman
2014-12-18 19:34       ` Linus Torvalds
2014-12-18 21:05       ` Al Viro
2014-12-18 21:18         ` Eric W. Biederman
2014-12-19  0:02           ` Al Viro [this message]
2014-12-19  0:03             ` Al Viro
2015-01-02 21:06             ` Eric W. Biederman
2015-01-02 21:13               ` Al Viro
2015-01-02 21:56                 ` Eric W. Biederman
2014-12-18 20:01 ` Al Viro
2014-12-18 20:15   ` Al Viro
2014-12-18 20:40     ` Eric W. Biederman

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=20141219000215.GR22149@ZenIV.linux.org.uk \
    --to=viro@zeniv.linux.org.uk \
    --cc=ebiederm@xmission.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=torvalds@linux-foundation.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