Al Viro <viro@xxxxxxxxxxxxxxxxxx> writes:
> 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 */)
I have a couple of reasons for not wanting to go that way.
- It requires keeping track of the tail of the list which is half of the
error prone complexity.
- I have a fix for a bad interaction between MNT_LOCKED and MNT_DETACH
where I need to leave mounts on the mount hash, until the final
mntput. For that I need not to reuse the the mnt_hash lists.
Patches to follow shortly.
Of course after having gone through this code a time or two and tested
things I am very annoyed by the fact that "hlist_add_before_rcu()" and
"list_move_tail" perform the same operation. That is down right
confusing.
> 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?
Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
