Qu Wenruo 39f501d68e btrfs: always report error in run_one_delayed_ref()
Currently we have a btrfs_debug() for run_one_delayed_ref() failure, but
if end users hit such problem, there will be no chance that
btrfs_debug() is enabled.  This can lead to very little useful info for
debugging.

This patch will:

- Add extra info for error reporting
  Including:
  * logical bytenr
  * num_bytes
  * type
  * action
  * ref_mod

- Replace the btrfs_debug() with btrfs_err()

- Move the error reporting into run_one_delayed_ref()
  This is to avoid use-after-free, the @node can be freed in the caller.

This error should only be triggered at most once.

As if run_one_delayed_ref() failed, we trigger the error message, then
causing the call chain to error out:

btrfs_run_delayed_refs()
`- btrfs_run_delayed_refs()
   `- btrfs_run_delayed_refs_for_head()
      `- run_one_delayed_ref()

And we will abort the current transaction in btrfs_run_delayed_refs().
If we have to run delayed refs for the abort transaction,
run_one_delayed_ref() will just cleanup the refs and do nothing, thus no
new error messages would be output.

Reviewed-by: Anand Jain <anand.jain@oracle.com>
Signed-off-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
2023-01-03 16:22:10 +01:00
..
2022-07-02 18:52:21 +09:00
2022-10-04 13:38:03 -07:00
2022-11-15 10:30:34 -08:00
2022-10-10 20:13:22 -07:00
2022-05-09 16:21:45 -04:00
2022-08-03 10:35:43 -07:00
2022-09-24 07:00:00 +02:00
2022-11-15 16:56:07 +00:00
2022-11-27 12:40:06 -08:00
2022-10-10 19:45:17 -07:00
2022-10-10 19:45:17 -07:00
2022-05-09 16:21:46 -04:00
2022-09-11 20:26:07 -07:00
2022-10-06 17:36:48 -07:00
2022-11-25 17:01:22 +09:00
2022-09-24 07:00:00 +02:00
2022-08-20 11:34:33 -04:00
2022-10-10 19:45:17 -07:00
2022-10-29 17:49:33 -07:00
2022-10-06 16:49:00 -07:00
2022-04-01 19:35:56 -07:00
2022-10-10 14:21:11 -07:00
2022-08-03 10:35:43 -07:00
2022-10-06 17:13:18 -07:00
2022-06-28 13:58:05 -04:00
2022-05-22 21:03:01 +01:00