On Sun, Oct 30, 2011 at 03:50:25PM +0800, Tao Ma wrote: > sorry, but I thought I had considered this case. > There are 2 callers. One is ext4_end_io_work(which has the bug I pointed > out), the other is ext4_flush_complete_IO which has already done the > check before calling ext4_end_io_nolock. And that's the reason why I > move the check from ext4_end_io_nolock to ext4_end_io_work. So for the > ext4_flush_complete_IO case, your new patch will spin_lock twice for the > checking. Do I miss something here? Ah, you're right; my mistake. When I looked closely, though, I found that ext4_flush_completed_IO() had a call to list_empty() without taking the spinlock, which would also be problematic. When I looked more closely, I found more ways to optimize things, which also close up a few potential (I think theoretical) race conditions. Let me know what you think.... - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
