David Howells: > Now, looking at __sb_start_write(), I'm not entirely sure how the deadlock > might operate, so it's possible that this is a false alarm. Maybe Jan Kara can > illuminate further, so I've added him to the cc list. It is related to the design of UnionMount, isn't it? UnionMount is not a filesystem and doen't have its own superblock. If it was a fs, then - vfs_truncate() acquires sb_writers for the unioning-fs. - the unioning-fs may call vfs_truncate() again for the underlying fs. - this time, sb_writers is for the underlying fs which is a different sb_writers object from the already acquired one. So there would be no deadlock. Still lockdep will produce the message since sb_writers doesn't have the lockdep class. Of course, we can introduce the lock class for it, or call lockdep_off()/on() simply in order to stop the message. But, as long as the unioning feature is not implemented as a fs, the solution will not be so easy. I am afraid UnionMount will need to introduce a new counter (or a new flag) to indicate the task entered the union, and adjust the lock class or decide to call lockdep_off() for sb_writers. I don't think it is a good idea. J. R. Okajima -- 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
