Home
last modified time | relevance | path

Searched hist:"38129 a13e6e71f666e0468e99fdd932a687b4d7e" (Results 1 – 4 of 4) sorted by relevance

/linux/fs/
H A Dpnode.h38129a13e6e71f666e0468e99fdd932a687b4d7e Fri Mar 21 01:10:51 UTC 2014 Al Viro <viro@zeniv.linux.org.uk> switch mnt_hash to hlist

fixes RCU bug - walking through hlist is safe in face of element moves,
since it's self-terminating. Cyclic lists are not - if we end up jumping
to another hash chain, we'll loop infinitely without ever hitting the
original list head.

[fix for dumb braino folded]

Spotted by: Max Kellermann <mk@cm4all.com>
Cc: stable@vger.kernel.org
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
H A Dmount.h38129a13e6e71f666e0468e99fdd932a687b4d7e Fri Mar 21 01:10:51 UTC 2014 Al Viro <viro@zeniv.linux.org.uk> switch mnt_hash to hlist

fixes RCU bug - walking through hlist is safe in face of element moves,
since it's self-terminating. Cyclic lists are not - if we end up jumping
to another hash chain, we'll loop infinitely without ever hitting the
original list head.

[fix for dumb braino folded]

Spotted by: Max Kellermann <mk@cm4all.com>
Cc: stable@vger.kernel.org
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
H A Dpnode.c38129a13e6e71f666e0468e99fdd932a687b4d7e Fri Mar 21 01:10:51 UTC 2014 Al Viro <viro@zeniv.linux.org.uk> switch mnt_hash to hlist

fixes RCU bug - walking through hlist is safe in face of element moves,
since it's self-terminating. Cyclic lists are not - if we end up jumping
to another hash chain, we'll loop infinitely without ever hitting the
original list head.

[fix for dumb braino folded]

Spotted by: Max Kellermann <mk@cm4all.com>
Cc: stable@vger.kernel.org
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
H A Dnamespace.cc297abfdf15b4480704d6b566ca5ca9438b12456 Thu Dec 18 16:57:19 UTC 2014 Eric W. Biederman <ebiederm@xmission.com> mnt: Fix a memory stomp in umount

While reviewing the code of umount_tree I realized that when we append
to a preexisting unmounted list we do not change pprev of the former
first item in the list.

Which means later in namespace_unlock hlist_del_init(&mnt->mnt_hash) on
the former first item of the list will stomp unmounted.first leaving
it set to some random mount point which we are likely to free soon.

This isn't likely to hit, but if it does I don't know how anyone could
track it down.

[ This happened because we don't have all the same operations for
hlist's as we do for normal doubly-linked lists. In particular,
list_splice() is easy on our standard doubly-linked lists, while
hlist_splice() doesn't exist and needs both start/end entries of the
hlist. And commit 38129a13e6e7 incorrectly open-coded that missing
hlist_splice().

We should think about making these kinds of "mindless" conversions
easier to get right by adding the missing hlist helpers - Linus ]

Fixes: 38129a13e6e71f666e0468e99fdd932a687b4d7e switch mnt_hash to hlist
Cc: stable@vger.kernel.org
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
38129a13e6e71f666e0468e99fdd932a687b4d7e Fri Mar 21 01:10:51 UTC 2014 Al Viro <viro@zeniv.linux.org.uk> switch mnt_hash to hlist

fixes RCU bug - walking through hlist is safe in face of element moves,
since it's self-terminating. Cyclic lists are not - if we end up jumping
to another hash chain, we'll loop infinitely without ever hitting the
original list head.

[fix for dumb braino folded]

Spotted by: Max Kellermann <mk@cm4all.com>
Cc: stable@vger.kernel.org
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>