On 30.07.2018 09:17, Qu Wenruo wrote:
> -void btrfs_tree_lock(struct extent_buffer *eb)
> +int btrfs_tree_lock(struct extent_buffer *eb)
> {
> - WARN_ON(eb->lock_owner == current->pid);
> + if (unlikely(eb->lock_owner == current->pid)) {
> + WARN(1,
> +"tree block %llu already locked by current (pid=%llu), refuse to lock",
> + eb->start, current->pid);
> + return -EUCLEAN;
> + }
If this happens it should point to a logical bug in which case we need
to halt the kernel. Furthermore this seems the wrong abstraction level
at which to solve the problem. eb->lock_owner is a runtime
characteristic of the eb, yet when it has an unexpected value you return
EUCLEAN which is an error for an on-disk error.
I don't think it's productive to try and solve every possible
fuzz-inspired corruption. In the worst case this corruption should be
caught a lot earlier rather than when we are locking an in-memory
structure.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
