Two of my machines couldn't boot mmotm with fanotify enabled:
0x40000020 was being or'ed into a group's notification_waitq next
pointer, with sad results. It comes from an over-simplification in
fanotify_merge(): test_event isn't NULL when the loop finds no merge.
Signed-off-by: Hugh Dickins <hu...@google.com>
---
Fixes fsnotify-do-not-share-events-between-notification-groups.patch
fs/notify/fanotify/fanotify.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
--- mmotm/fs/notify/fanotify/fanotify.c 2014-01-10 18:25:01.700448941 -0800
+++ linux/fs/notify/fanotify/fanotify.c 2014-01-11 22:15:31.580961010 -0800
@@ -37,16 +37,19 @@ static bool should_merge(struct fsnotify
static struct fsnotify_event *fanotify_merge(struct list_head *list,
struct fsnotify_event *event)
{
- struct fsnotify_event *test_event = NULL;
+ struct fsnotify_event *test_event;
+ bool do_merge = false;
pr_debug("%s: list=%p event=%p\n", __func__, list, event);
list_for_each_entry_reverse(test_event, list, list) {
- if (should_merge(test_event, event))
+ if (should_merge(test_event, event)) {
+ do_merge = true;
break;
+ }
}
- if (!test_event)
+ if (!do_merge)
return NULL;
test_event->mask |= event->mask;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
