On 09/15/2016 11:45 PM, Jan Kara wrote:

On Thu 15-09-16 19:20:10, Guenter Roeck wrote:
I see various architectures crashing in -next with the following error.

------------[ cut here ]------------
kernel BUG at fs/notify/notification.c:66!

Thanks for report!


Call Trace:
 [<ffffffff811bd532>] inotify_poll+0x42/0x70
 [<ffffffff811bfeba>] SyS_epoll_ctl+0x84a/0xf60
 [<ffffffff811be4a0>] ? ep_send_events_proc+0x180/0x180
 [<ffffffff8176be98>] entry_SYSCALL_64_fastpath+0x13/0x8f
Code: 90 90 0f 1f 44 00 00 55 b8 01 00 00 00 48 89 e5 0f c1 05 bb e4 d4 00 83 c0 01 
5d c3 66 0f 1f 44 00 00 0f 1f 44 00 00 55 48 89 e5 <0f> 0b 0f 1f 44 00 00 0f 1f 
44 00 00 55 48 89 e5 48 83 ec 10 48
RIP  [<ffffffff811bb399>] fsnotify_notify_queue_is_empty+0x9/0x10
 RSP <ffffc90000253e68>
---[ end trace 7dc4a27003f0b575 ]---

I didn't bisect, but I would guess the culprit is one of the new patches in the
affected file.

22e9cf146d3b fanotify: fix possible false warning when freeing events
ced89591817c fsnotify: convert notification_mutex to a spinlock
f82fa3d0e7f5 fsnotify: drop notification_mutex before destroying event
782fbc7e8685 fanotify: fix list corruption in fanotify_get_response()
56cf1c8a1b35 fsnotify: add a way to stop queueing events on group shutdown

Yes, very likely my patches cause this. But it must be some config issue
because my test machine does not hit this and the code is "obviously
correct" - famous last words ;). I've seen zero-day robot complain as well
so I'll try the config it had sent me and see what's going on (likely
spin_is_locked() does not do what I thought under some configs...).

Your builds are probably all SMP builds. Looks like this happens if SMP is 


Reply via email to