Josef Bacik e7f1326cc2 btrfs: set page extent mapped after read_folio in relocate_one_page
One of the CI runs triggered the following panic

  assertion failed: PagePrivate(page) && page->private, in fs/btrfs/subpage.c:229
  ------------[ cut here ]------------
  kernel BUG at fs/btrfs/subpage.c:229!
  Internal error: Oops - BUG: 00000000f2000800 [#1] SMP
  CPU: 0 PID: 923660 Comm: btrfs Not tainted 6.5.0-rc3+ #1
  pstate: 61400005 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--)
  pc : btrfs_subpage_assert+0xbc/0xf0
  lr : btrfs_subpage_assert+0xbc/0xf0
  sp : ffff800093213720
  x29: ffff800093213720 x28: ffff8000932138b4 x27: 000000000c280000
  x26: 00000001b5d00000 x25: 000000000c281000 x24: 000000000c281fff
  x23: 0000000000001000 x22: 0000000000000000 x21: ffffff42b95bf880
  x20: ffff42b9528e0000 x19: 0000000000001000 x18: ffffffffffffffff
  x17: 667274622f736620 x16: 6e69202c65746176 x15: 0000000000000028
  x14: 0000000000000003 x13: 00000000002672d7 x12: 0000000000000000
  x11: ffffcd3f0ccd9204 x10: ffffcd3f0554ae50 x9 : ffffcd3f0379528c
  x8 : ffff800093213428 x7 : 0000000000000000 x6 : ffffcd3f091771e8
  x5 : ffff42b97f333948 x4 : 0000000000000000 x3 : 0000000000000000
  x2 : 0000000000000000 x1 : ffff42b9556cde80 x0 : 000000000000004f
  Call trace:
   btrfs_subpage_assert+0xbc/0xf0
   btrfs_subpage_set_dirty+0x38/0xa0
   btrfs_page_set_dirty+0x58/0x88
   relocate_one_page+0x204/0x5f0
   relocate_file_extent_cluster+0x11c/0x180
   relocate_data_extent+0xd0/0xf8
   relocate_block_group+0x3d0/0x4e8
   btrfs_relocate_block_group+0x2d8/0x490
   btrfs_relocate_chunk+0x54/0x1a8
   btrfs_balance+0x7f4/0x1150
   btrfs_ioctl+0x10f0/0x20b8
   __arm64_sys_ioctl+0x120/0x11d8
   invoke_syscall.constprop.0+0x80/0xd8
   do_el0_svc+0x6c/0x158
   el0_svc+0x50/0x1b0
   el0t_64_sync_handler+0x120/0x130
   el0t_64_sync+0x194/0x198
  Code: 91098021 b0007fa0 91346000 97e9c6d2 (d4210000)

This is the same problem outlined in 17b17fcd6d44 ("btrfs:
set_page_extent_mapped after read_folio in btrfs_cont_expand") , and the
fix is the same.  I originally looked for the same pattern elsewhere in
our code, but mistakenly skipped over this code because I saw the page
cache readahead before we set_page_extent_mapped, not realizing that
this was only in the !page case, that we can still end up with a
!uptodate page and then do the btrfs_read_folio further down.

The fix here is the same as the above mentioned patch, move the
set_page_extent_mapped call to after the btrfs_read_folio() block to
make sure that we have the subpage blocksize stuff setup properly before
using the page.

CC: stable@vger.kernel.org # 6.1+
Reviewed-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: David Sterba <dsterba@suse.com>
2023-08-21 14:54:47 +02:00
..
2023-06-26 10:14:36 -07:00
2023-06-29 13:27:50 -07:00
\n
2023-06-29 13:39:51 -07:00
2023-07-05 14:14:37 -07:00
2023-07-19 11:00:27 -07:00
2023-08-07 18:42:04 +02:00
2023-06-27 17:10:27 -07:00
2023-06-26 11:52:12 -07:00
2023-07-03 12:56:23 -07:00
2023-07-01 14:38:25 -07:00
2023-07-01 14:38:25 -07:00
2023-08-03 09:26:34 -07:00
2023-07-07 14:59:38 -07:00
2023-06-27 21:21:32 -07:00
2023-03-14 12:56:30 -06:00
2023-06-05 16:50:30 +02:00
2023-08-16 00:26:07 -05:00
2023-06-15 13:37:53 +02:00
2023-06-26 11:52:12 -07:00
\n
2023-06-29 13:39:51 -07:00
2023-08-08 14:59:49 -07:00
2023-03-30 08:51:48 +02:00
2023-06-28 20:35:21 -07:00
\n
2023-06-29 13:39:51 -07:00
2023-06-26 09:50:21 -07:00
2023-05-17 09:16:59 +02:00
2023-06-26 09:50:21 -07:00
\n
2023-06-29 13:31:44 -07:00
2023-02-20 11:53:11 -08:00
2023-08-12 09:18:47 -07:00
2023-06-26 10:14:36 -07:00
2023-06-26 12:47:20 -07:00
2023-01-19 09:24:30 +01:00
2023-07-04 10:20:29 +02:00
2023-06-26 10:27:04 -07:00
2023-05-19 04:30:22 +02:00
2023-05-19 04:30:22 +02:00
2023-03-06 09:59:20 +01:00
2023-02-20 11:53:11 -08:00
\n
2023-06-29 13:39:51 -07:00
2023-02-20 11:53:11 -08:00