{"payload":{"feedbackUrl":"https://github.com/orgs/community/discussions/53140","repo":{"id":27630107,"defaultBranch":"master","name":"linux","ownerLogin":"osandov","currentUserCanPush":false,"isFork":true,"isEmpty":false,"createdAt":"2014-12-06T10:01:26.000Z","ownerAvatar":"https://avatars.githubusercontent.com/u/3682206?v=4","public":true,"private":false,"isOrgOwned":false},"refInfo":{"name":"","listCacheKey":"v0:1716484692.0","currentOid":""},"activityList":{"items":[{"before":"101430650a35b55b7a32d895fd292226d13346eb","after":"29a4df3b9a36eb17a958e92e375e03daf9312fa5","ref":"refs/heads/btrfs-fsync-crash","pushedAt":"2024-05-24T16:46:03.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"osandov","name":"Omar Sandoval","path":"/osandov","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/3682206?s=80&v=4"},"commit":{"message":"btrfs: fix crash on racing fsync and size-extending write into prealloc\n\nWe have been seeing crashes on duplicate keys in\nbtrfs_set_item_key_safe():\n\n  BTRFS critical (device vdb): slot 4 key (450 108 8192) new key (450 108 8192)\n  ------------[ cut here ]------------\n  kernel BUG at fs/btrfs/ctree.c:2620!\n  invalid opcode: 0000 [#1] PREEMPT SMP PTI\n  CPU: 0 PID: 3139 Comm: xfs_io Kdump: loaded Not tainted 6.9.0 #6\n  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014\n  RIP: 0010:btrfs_set_item_key_safe+0x11f/0x290 [btrfs]\n\nWith the following stack trace:\n\n  #0  btrfs_set_item_key_safe (fs/btrfs/ctree.c:2620:4)\n  #1  btrfs_drop_extents (fs/btrfs/file.c:411:4)\n  #2  log_one_extent (fs/btrfs/tree-log.c:4732:9)\n  #3  btrfs_log_changed_extents (fs/btrfs/tree-log.c:4955:9)\n  #4  btrfs_log_inode (fs/btrfs/tree-log.c:6626:9)\n  #5  btrfs_log_inode_parent (fs/btrfs/tree-log.c:7070:8)\n  #6  btrfs_log_dentry_safe (fs/btrfs/tree-log.c:7171:8)\n  #7  btrfs_sync_file (fs/btrfs/file.c:1933:8)\n  #8  vfs_fsync_range (fs/sync.c:188:9)\n  #9  vfs_fsync (fs/sync.c:202:9)\n  #10 do_fsync (fs/sync.c:212:9)\n  #11 __do_sys_fdatasync (fs/sync.c:225:9)\n  #12 __se_sys_fdatasync (fs/sync.c:223:1)\n  #13 __x64_sys_fdatasync (fs/sync.c:223:1)\n  #14 do_syscall_x64 (arch/x86/entry/common.c:52:14)\n  #15 do_syscall_64 (arch/x86/entry/common.c:83:7)\n  #16 entry_SYSCALL_64+0xaf/0x14c (arch/x86/entry/entry_64.S:121)\n\nSo we're logging a changed extent from fsync, which is splitting an\nextent in the log tree. But this split part already exists in the tree,\ntriggering the BUG().\n\nThis is the state of the log tree at the time of the crash, dumped with\ndrgn (https://github.com/osandov/drgn/blob/main/contrib/btrfs_tree.py)\nto get more details than btrfs_print_leaf() gives us:\n\n  >>> print_extent_buffer(prog.crashed_thread().stack_trace()[0][\"eb\"])\n  leaf 33439744 level 0 items 72 generation 9 owner 18446744073709551610\n  leaf 33439744 flags 0x100000000000000\n  fs uuid e5bd3946-400c-4223-8923-190ef1f18677\n  chunk uuid d58cb17e-6d02-494a-829a-18b7d8a399da\n          item 0 key (450 INODE_ITEM 0) itemoff 16123 itemsize 160\n                  generation 7 transid 9 size 8192 nbytes 8473563889606862198\n                  block group 0 mode 100600 links 1 uid 0 gid 0 rdev 0\n                  sequence 204 flags 0x10(PREALLOC)\n                  atime 1716417703.220000000 (2024-05-22 15:41:43)\n                  ctime 1716417704.983333333 (2024-05-22 15:41:44)\n                  mtime 1716417704.983333333 (2024-05-22 15:41:44)\n                  otime 17592186044416.000000000 (559444-03-08 01:40:16)\n          item 1 key (450 INODE_REF 256) itemoff 16110 itemsize 13\n                  index 195 namelen 3 name: 193\n          item 2 key (450 XATTR_ITEM 1640047104) itemoff 16073 itemsize 37\n                  location key (0 UNKNOWN.0 0) type XATTR\n                  transid 7 data_len 1 name_len 6\n                  name: user.a\n                  data a\n          item 3 key (450 EXTENT_DATA 0) itemoff 16020 itemsize 53\n                  generation 9 type 1 (regular)\n                  extent data disk byte 303144960 nr 12288\n                  extent data offset 0 nr 4096 ram 12288\n                  extent compression 0 (none)\n          item 4 key (450 EXTENT_DATA 4096) itemoff 15967 itemsize 53\n                  generation 9 type 2 (prealloc)\n                  prealloc data disk byte 303144960 nr 12288\n                  prealloc data offset 4096 nr 8192\n          item 5 key (450 EXTENT_DATA 8192) itemoff 15914 itemsize 53\n                  generation 9 type 2 (prealloc)\n                  prealloc data disk byte 303144960 nr 12288\n                  prealloc data offset 8192 nr 4096\n  ...\n\nSo the real problem happened earlier: notice that items 4 (4k-12k) and 5\n(8k-12k) overlap. Both are prealloc extents. Item 4 straddles i_size and\nitem 5 starts at i_size.\n\nHere is the state of the filesystem tree at the time of the crash:\n\n  >>> root = prog.crashed_thread().stack_trace()[2][\"inode\"].root\n  >>> ret, nodes, slots = btrfs_search_slot(root, BtrfsKey(450, 0, 0))\n  >>> print_extent_buffer(nodes[0])\n  leaf 30425088 level 0 items 184 generation 9 owner 5\n  leaf 30425088 flags 0x100000000000000\n  fs uuid e5bd3946-400c-4223-8923-190ef1f18677\n  chunk uuid d58cb17e-6d02-494a-829a-18b7d8a399da\n  \t...\n          item 179 key (450 INODE_ITEM 0) itemoff 4907 itemsize 160\n                  generation 7 transid 7 size 4096 nbytes 12288\n                  block group 0 mode 100600 links 1 uid 0 gid 0 rdev 0\n                  sequence 6 flags 0x10(PREALLOC)\n                  atime 1716417703.220000000 (2024-05-22 15:41:43)\n                  ctime 1716417703.220000000 (2024-05-22 15:41:43)\n                  mtime 1716417703.220000000 (2024-05-22 15:41:43)\n                  otime 1716417703.220000000 (2024-05-22 15:41:43)\n          item 180 key (450 INODE_REF 256) itemoff 4894 itemsize 13\n                  index 195 namelen 3 name: 193\n          item 181 key (450 XATTR_ITEM 1640047104) itemoff 4857 itemsize 37\n                  location key (0 UNKNOWN.0 0) type XATTR\n                  transid 7 data_len 1 name_len 6\n                  name: user.a\n                  data a\n          item 182 key (450 EXTENT_DATA 0) itemoff 4804 itemsize 53\n                  generation 9 type 1 (regular)\n                  extent data disk byte 303144960 nr 12288\n                  extent data offset 0 nr 8192 ram 12288\n                  extent compression 0 (none)\n          item 183 key (450 EXTENT_DATA 8192) itemoff 4751 itemsize 53\n                  generation 9 type 2 (prealloc)\n                  prealloc data disk byte 303144960 nr 12288\n                  prealloc data offset 8192 nr 4096\n\nItem 5 in the log tree corresponds to item 183 in the filesystem tree,\nbut nothing matches item 4. Furthermore, item 183 is the last item in\nthe leaf.\n\nbtrfs_log_prealloc_extents() is responsible for logging prealloc extents\nbeyond i_size. It first truncates any previously logged prealloc extents\nthat start beyond i_size. Then, it walks the filesystem tree and copies\nthe prealloc extent items to the log tree.\n\nIf it hits the end of a leaf, then it calls btrfs_next_leaf(), which\nunlocks the tree and does another search. However, while the filesystem\ntree is unlocked, an ordered extent completion may modify the tree. In\nparticular, it may insert an extent item that overlaps with an extent\nitem that was already copied to the log tree.\n\nThis may manifest in several ways depending on the exact scenario,\nincluding an EEXIST error that is silently translated to a full sync,\noverlapping items in the log tree, or this crash. This particular crash\nis triggered by the following sequence of events:\n\n- Initially, the file has i_size=4k, a regular extent from 0-4k, and a\n  prealloc extent beyond i_size from 4k-12k. The prealloc extent item is\n  the last item in its B-tree leaf.\n- The file is fsync'd, which copies its inode item and both extent items\n  to the log tree.\n- An xattr is set on the file, which sets the\n  BTRFS_INODE_COPY_EVERYTHING flag.\n- The range 4k-8k in the file is written using direct I/O. i_size is\n  extended to 8k, but the ordered extent is still in flight.\n- The file is fsync'd. Since BTRFS_INODE_COPY_EVERYTHING is set, this\n  calls copy_inode_items_to_log(), which calls\n  btrfs_log_prealloc_extents().\n- btrfs_log_prealloc_extents() finds the 4k-12k prealloc extent in the\n  filesystem tree. Since it starts before i_size, it skips it. Since it\n  is the last item in its B-tree leaf, it calls btrfs_next_leaf().\n- btrfs_next_leaf() unlocks the path.\n- The ordered extent completion runs, which converts the 4k-8k part of\n  the prealloc extent to written and inserts the remaining prealloc part\n  from 8k-12k.\n- btrfs_next_leaf() does a search and finds the new prealloc extent\n  8k-12k.\n- btrfs_log_prealloc_extents() copies the 8k-12k prealloc extent into\n  the log tree. Note that it overlaps with the 4k-12k prealloc extent\n  that was copied to the log tree by the first fsync.\n- fsync calls btrfs_log_changed_extents(), which tries to log the 4k-8k\n  extent that was written.\n- This tries to drop the range 4k-8k in the log tree, which requires\n  adjusting the start of the 4k-12k prealloc extent in the log tree to\n  8k.\n- btrfs_set_item_key_safe() sees that there is already an extent\n  starting at 8k in the log tree and calls BUG().\n\nFix this by detecting when we're about to insert an overlapping file\nextent item in the log tree and truncating the part that would overlap.\n\nSigned-off-by: Omar Sandoval <osandov@fb.com>","shortMessageHtmlLink":"btrfs: fix crash on racing fsync and size-extending write into prealloc"}},{"before":null,"after":"101430650a35b55b7a32d895fd292226d13346eb","ref":"refs/heads/btrfs-fsync-crash","pushedAt":"2024-05-23T17:18:12.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"osandov","name":"Omar Sandoval","path":"/osandov","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/3682206?s=80&v=4"},"commit":{"message":"btrfs: fix crash on racing fsync and size-extending direct I/O into prealloc\n\nWe have been seeing crashes on duplicate keys in\nbtrfs_set_item_key_safe():\n\n  BTRFS critical (device vdb): slot 4 key (450 108 8192) new key (450 108 8192)\n  ------------[ cut here ]------------\n  kernel BUG at fs/btrfs/ctree.c:2620!\n  invalid opcode: 0000 [#1] PREEMPT SMP PTI\n  CPU: 0 PID: 3139 Comm: xfs_io Kdump: loaded Not tainted 6.9.0 #6\n  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014\n  RIP: 0010:btrfs_set_item_key_safe+0x11f/0x290 [btrfs]\n\nWith the following stack trace:\n\n  #0  btrfs_set_item_key_safe (fs/btrfs/ctree.c:2620:4)\n  #1  btrfs_drop_extents (fs/btrfs/file.c:411:4)\n  #2  log_one_extent (fs/btrfs/tree-log.c:4732:9)\n  #3  btrfs_log_changed_extents (fs/btrfs/tree-log.c:4955:9)\n  #4  btrfs_log_inode (fs/btrfs/tree-log.c:6626:9)\n  #5  btrfs_log_inode_parent (fs/btrfs/tree-log.c:7070:8)\n  #6  btrfs_log_dentry_safe (fs/btrfs/tree-log.c:7171:8)\n  #7  btrfs_sync_file (fs/btrfs/file.c:1933:8)\n  #8  vfs_fsync_range (fs/sync.c:188:9)\n  #9  vfs_fsync (fs/sync.c:202:9)\n  #10 do_fsync (fs/sync.c:212:9)\n  #11 __do_sys_fdatasync (fs/sync.c:225:9)\n  #12 __se_sys_fdatasync (fs/sync.c:223:1)\n  #13 __x64_sys_fdatasync (fs/sync.c:223:1)\n  #14 do_syscall_x64 (arch/x86/entry/common.c:52:14)\n  #15 do_syscall_64 (arch/x86/entry/common.c:83:7)\n  #16 entry_SYSCALL_64+0xaf/0x14c (arch/x86/entry/entry_64.S:121)\n\nSo we're logging a changed extent from fsync, which is splitting an\nextent in the log tree. But this split part already exists in the tree,\ntriggering the BUG().\n\nThis is the state of the log tree at the time of the crash, dumped with\ndrgn (https://github.com/osandov/drgn/blob/main/contrib/btrfs_tree.py)\nto get more details than btrfs_print_leaf() gives us:\n\n  >>> print_extent_buffer(prog.crashed_thread().stack_trace()[0][\"eb\"])\n  leaf 33439744 level 0 items 72 generation 9 owner 18446744073709551610\n  leaf 33439744 flags 0x100000000000000\n  fs uuid e5bd3946-400c-4223-8923-190ef1f18677\n  chunk uuid d58cb17e-6d02-494a-829a-18b7d8a399da\n          item 0 key (450 INODE_ITEM 0) itemoff 16123 itemsize 160\n                  generation 7 transid 9 size 8192 nbytes 8473563889606862198\n                  block group 0 mode 100600 links 1 uid 0 gid 0 rdev 0\n                  sequence 204 flags 0x10(PREALLOC)\n                  atime 1716417703.220000000 (2024-05-22 15:41:43)\n                  ctime 1716417704.983333333 (2024-05-22 15:41:44)\n                  mtime 1716417704.983333333 (2024-05-22 15:41:44)\n                  otime 17592186044416.000000000 (559444-03-08 01:40:16)\n          item 1 key (450 INODE_REF 256) itemoff 16110 itemsize 13\n                  index 195 namelen 3 name: 193\n          item 2 key (450 XATTR_ITEM 1640047104) itemoff 16073 itemsize 37\n                  location key (0 UNKNOWN.0 0) type XATTR\n                  transid 7 data_len 1 name_len 6\n                  name: user.a\n                  data a\n          item 3 key (450 EXTENT_DATA 0) itemoff 16020 itemsize 53\n                  generation 9 type 1 (regular)\n                  extent data disk byte 303144960 nr 12288\n                  extent data offset 0 nr 4096 ram 12288\n                  extent compression 0 (none)\n          item 4 key (450 EXTENT_DATA 4096) itemoff 15967 itemsize 53\n                  generation 9 type 2 (prealloc)\n                  prealloc data disk byte 303144960 nr 12288\n                  prealloc data offset 4096 nr 8192\n          item 5 key (450 EXTENT_DATA 8192) itemoff 15914 itemsize 53\n                  generation 9 type 2 (prealloc)\n                  prealloc data disk byte 303144960 nr 12288\n                  prealloc data offset 8192 nr 4096\n  ...\n\nSo the real problem happened earlier: notice that items 4 (4k-12k) and 5\n(8k-12k) overlap. Both are prealloc extents. Item 4 straddles i_size and\nitem 5 starts at i_size.\n\nHere is the state of the filesystem tree at the time of the crash:\n\n  >>> root = prog.crashed_thread().stack_trace()[2][\"inode\"].root\n  >>> ret, nodes, slots = btrfs_search_slot(root, BtrfsKey(450, 0, 0))\n  >>> print_extent_buffer(nodes[0])\n  leaf 30425088 level 0 items 184 generation 9 owner 5\n  leaf 30425088 flags 0x100000000000000\n  fs uuid e5bd3946-400c-4223-8923-190ef1f18677\n  chunk uuid d58cb17e-6d02-494a-829a-18b7d8a399da\n  \t...\n          item 179 key (450 INODE_ITEM 0) itemoff 4907 itemsize 160\n                  generation 7 transid 7 size 4096 nbytes 12288\n                  block group 0 mode 100600 links 1 uid 0 gid 0 rdev 0\n                  sequence 6 flags 0x10(PREALLOC)\n                  atime 1716417703.220000000 (2024-05-22 15:41:43)\n                  ctime 1716417703.220000000 (2024-05-22 15:41:43)\n                  mtime 1716417703.220000000 (2024-05-22 15:41:43)\n                  otime 1716417703.220000000 (2024-05-22 15:41:43)\n          item 180 key (450 INODE_REF 256) itemoff 4894 itemsize 13\n                  index 195 namelen 3 name: 193\n          item 181 key (450 XATTR_ITEM 1640047104) itemoff 4857 itemsize 37\n                  location key (0 UNKNOWN.0 0) type XATTR\n                  transid 7 data_len 1 name_len 6\n                  name: user.a\n                  data a\n          item 182 key (450 EXTENT_DATA 0) itemoff 4804 itemsize 53\n                  generation 9 type 1 (regular)\n                  extent data disk byte 303144960 nr 12288\n                  extent data offset 0 nr 8192 ram 12288\n                  extent compression 0 (none)\n          item 183 key (450 EXTENT_DATA 8192) itemoff 4751 itemsize 53\n                  generation 9 type 2 (prealloc)\n                  prealloc data disk byte 303144960 nr 12288\n                  prealloc data offset 8192 nr 4096\n\nItem 5 in the log tree corresponds to item 183 in the filesystem tree,\nbut nothing matches item 4. Furthermore, item 183 is the last item in\nthe leaf.\n\nbtrfs_log_prealloc_extents() is responsible for logging prealloc extents\nbeyond i_size. It first truncates any previously logged prealloc extents\nthat start beyond i_size. Then, it walks the filesystem tree and copies\nthe prealloc extent items to the log tree.\n\nIf it hits the end of a leaf, then it calls btrfs_next_leaf(), which\nunlocks the tree and does another search. However, while the filesystem\ntree is unlocked, an ordered extent completion may modify the tree. In\nparticular, it may insert an extent item that overlaps with an extent\nitem that was already copied to the log tree.\n\nThis may manifest in several ways depending on the exact scenario,\nincluding an EEXIST error that is silently translated to a full sync,\noverlapping items in the log tree, or this crash. This particular crash\nis triggered by the following sequence of events:\n\n- Initially, the file has i_size=4k, a regular extent from 0-4k, and a\n  prealloc extent beyond i_size from 4k-12k. The prealloc extent item is\n  the last item in its B-tree leaf.\n- The file is fsync'd, which copies its inode item and both extent items\n  to the log tree.\n- An xattr is set on the file, which sets the\n  BTRFS_INODE_COPY_EVERYTHING flag.\n- The range 4k-8k in the file is written using direct I/O. i_size is\n  extended to 8k, but the ordered extent is still in flight.\n- The file is fsync'd. Since BTRFS_INODE_COPY_EVERYTHING is set, this\n  calls copy_inode_items_to_log(), which calls\n  btrfs_log_prealloc_extents().\n- btrfs_log_prealloc_extents() finds the 4k-12k prealloc extent in the\n  filesystem tree. Since it starts before i_size, it skips it. Since it\n  is the last item in its B-tree leaf, it calls btrfs_next_leaf().\n- btrfs_next_leaf() unlocks the path.\n- The ordered extent completion runs, which converts the 4k-8k part of\n  the prealloc extent to written and inserts the remaining prealloc part\n  from 8k-12k.\n- btrfs_next_leaf() does a search and finds the new prealloc extent\n  8k-12k.\n- btrfs_log_prealloc_extents() copies the 8k-12k prealloc extent into\n  the log tree. Note that it overlaps with the 4k-12k prealloc extent\n  that was copied to the log tree by the first fsync.\n- fsync calls btrfs_log_changed_extents(), which tries to log the 4k-8k\n  extent that was written.\n- This tries to drop the range 4k-8k in the log tree, which requires\n  adjusting the start of the 4k-12k prealloc extent in the log tree to\n  8k.\n- btrfs_set_item_key_safe() sees that there is already an extent\n  starting at 8k in the log tree and calls BUG().\n\nFix this by detecting when we're about to insert an overlapping file\nextent item in the log tree and truncating the part that would overlap.\n\nSigned-off-by: Omar Sandoval <osandov@fb.com>","shortMessageHtmlLink":"btrfs: fix crash on racing fsync and size-extending direct I/O into p…"}},{"before":"068014bd3e90668525c295660862db2932e25087","after":"eb4387abc3e524b054bce9e3ce318f26838b9179","ref":"refs/heads/btrfs-snapshot-deleted","pushedAt":"2024-01-04T19:43:37.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"osandov","name":"Omar Sandoval","path":"/osandov","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/3682206?s=80&v=4"},"commit":{"message":"btrfs: avoid copying BTRFS_ROOT_SUBVOL_DEAD flag to snapshot of subvolume being deleted\n\nSweet Tea spotted a race between subvolume deletion and snapshotting\nthat can result in the root item for the snapshot having the\nBTRFS_ROOT_SUBVOL_DEAD flag set. The race is:\n\nThread 1                                      | Thread 2\n----------------------------------------------|----------\nbtrfs_delete_subvolume                        |\n  btrfs_set_root_flags(BTRFS_ROOT_SUBVOL_DEAD)|\n                                              |btrfs_mksubvol\n                                              |  down_read(subvol_sem)\n                                              |  create_snapshot\n                                              |    ...\n                                              |    create_pending_snapshot\n                                              |      copy root item from source\n  down_write(subvol_sem)                      |\n\nThis flag is only checked in send and swap activate, which this would\ncause to fail mysteriously.\n\ncreate_snapshot() now checks the root refs to reject a deleted\nsubvolume, so we can fix this by locking subvol_sem earlier so that the\nBTRFS_ROOT_SUBVOL_DEAD flag and the root refs are updated atomically.\n\nReported-by: Sweet Tea Dorminy <sweettea-kernel@dorminy.me>\nSigned-off-by: Omar Sandoval <osandov@fb.com>","shortMessageHtmlLink":"btrfs: avoid copying BTRFS_ROOT_SUBVOL_DEAD flag to snapshot of subvo…"}},{"before":"b6dad5178ceaf23f369c3711062ce1f2afc33644","after":"2cf4f94d8e8646803f8fb0facf134b0cd7fb691a","ref":"refs/heads/master","pushedAt":"2023-12-19T19:30:54.000Z","pushType":"push","commitsCount":10000,"pusher":{"login":"osandov","name":"Omar Sandoval","path":"/osandov","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/3682206?s=80&v=4"},"commit":{"message":"Merge tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi\n\nPull SCSI fixes from James Bottomley:\n \"Two medium sized fixes, both in drivers.\n\n  The UFS one adds parsing of clock info structures, which is required\n  by some host drivers and the aacraid one reverts the IRQ affinity\n  mapping patch which has been causing regressions noted in kernel\n  bugzilla 217599\"\n\n* tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi:\n  scsi: ufs: core: Store min and max clk freq from OPP table\n  Revert \"scsi: aacraid: Reply queue mapping to CPUs based on IRQ affinity\"","shortMessageHtmlLink":"Merge tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/g…"}},{"before":null,"after":"068014bd3e90668525c295660862db2932e25087","ref":"refs/heads/btrfs-snapshot-deleted","pushedAt":"2023-12-19T19:27:53.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"osandov","name":"Omar Sandoval","path":"/osandov","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/3682206?s=80&v=4"},"commit":{"message":"btrfs: don't abort filesystem when attempting to snapshot deleted subvolume\n\nIf the source file descriptor to the snapshot ioctl refers to a deleted\nsubvolume, we get the following abort:\n\n  ------------[ cut here ]------------\n  BTRFS: Transaction aborted (error -2)\n  WARNING: CPU: 0 PID: 833 at fs/btrfs/transaction.c:1875 create_pending_snapshot+0x1040/0x1190 [btrfs]\n  Modules linked in: pata_acpi btrfs ata_piix libata scsi_mod virtio_net blake2b_generic xor net_failover virtio_rng failover scsi_common rng_core raid6_pq libcrc32c\n  CPU: 0 PID: 833 Comm: t_snapshot_dele Not tainted 6.7.0-rc6 #2\n  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-1.fc39 04/01/2014\n  RIP: 0010:create_pending_snapshot+0x1040/0x1190 [btrfs]\n  Code: e9 44 fe ff ff 44 89 e6 48 c7 c7 f8 59 7b c0 e8 d6 f4 a3 f7 0f 0b e9 4c fa ff ff 44 89 e6 48 c7 c7 f8 59 7b c0 e8 c0 f4 a3 f7 <0f> 0b e9 ef fe ff ff 44 89 e6 48 c7 c7 f8 59 7b c0 e8 aa f4 a3 f7\n  RSP: 0018:ffffa09c01337af8 EFLAGS: 00010282\n  RAX: 0000000000000000 RBX: ffff9982053e7c78 RCX: 0000000000000027\n  RDX: ffff99827dc20848 RSI: 0000000000000001 RDI: ffff99827dc20840\n  RBP: ffffa09c01337c00 R08: 0000000000000000 R09: ffffa09c01337998\n  R10: 0000000000000003 R11: ffffffffb96da248 R12: fffffffffffffffe\n  R13: ffff99820535bb28 R14: ffff99820b7bd000 R15: ffff99820381ea80\n  FS:  00007fe20aadabc0(0000) GS:ffff99827dc00000(0000) knlGS:0000000000000000\n  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n  CR2: 0000559a120b502f CR3: 00000000055b6000 CR4: 00000000000006f0\n  Call Trace:\n   <TASK>\n   ? create_pending_snapshot+0x1040/0x1190 [btrfs]\n   ? __warn+0x81/0x130\n   ? create_pending_snapshot+0x1040/0x1190 [btrfs]\n   ? report_bug+0x171/0x1a0\n   ? handle_bug+0x3a/0x70\n   ? exc_invalid_op+0x17/0x70\n   ? asm_exc_invalid_op+0x1a/0x20\n   ? create_pending_snapshot+0x1040/0x1190 [btrfs]\n   ? create_pending_snapshot+0x1040/0x1190 [btrfs]\n   create_pending_snapshots+0x92/0xc0 [btrfs]\n   btrfs_commit_transaction+0x66b/0xf40 [btrfs]\n   btrfs_mksubvol+0x301/0x4d0 [btrfs]\n   btrfs_mksnapshot+0x80/0xb0 [btrfs]\n   __btrfs_ioctl_snap_create+0x1c2/0x1d0 [btrfs]\n   btrfs_ioctl_snap_create_v2+0xc4/0x150 [btrfs]\n   btrfs_ioctl+0x8a6/0x2650 [btrfs]\n   ? kmem_cache_free+0x22/0x340\n   ? do_sys_openat2+0x97/0xe0\n   __x64_sys_ioctl+0x97/0xd0\n   do_syscall_64+0x46/0xf0\n   entry_SYSCALL_64_after_hwframe+0x6e/0x76\n  RIP: 0033:0x7fe20abe83af\n  Code: 00 48 89 44 24 18 31 c0 48 8d 44 24 60 c7 04 24 10 00 00 00 48 89 44 24 08 48 8d 44 24 20 48 89 44 24 10 b8 10 00 00 00 0f 05 <89> c2 3d 00 f0 ff ff 77 18 48 8b 44 24 18 64 48 2b 04 25 28 00 00\n  RSP: 002b:00007ffe6eff1360 EFLAGS: 00000246 ORIG_RAX: 0000000000000010\n  RAX: ffffffffffffffda RBX: 0000000000000004 RCX: 00007fe20abe83af\n  RDX: 00007ffe6eff23c0 RSI: 0000000050009417 RDI: 0000000000000003\n  RBP: 0000000000000003 R08: 0000000000000000 R09: 00007fe20ad16cd0\n  R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000\n  R13: 00007ffe6eff13c0 R14: 00007fe20ad45000 R15: 0000559a120b6d58\n   </TASK>\n  ---[ end trace 0000000000000000 ]---\n  BTRFS: error (device vdc: state A) in create_pending_snapshot:1875: errno=-2 No such entry\n  BTRFS info (device vdc: state EA): forced readonly\n  BTRFS warning (device vdc: state EA): Skipping commit of aborted transaction.\n  BTRFS: error (device vdc: state EA) in cleanup_transaction:2055: errno=-2 No such entry\n\nThis happens because create_pending_snapshot() initializes the new root\nitem as a copy of the source root item. This includes the refs field,\nwhich is 0 for a deleted subvolume. The call to btrfs_insert_root()\ntherefore inserts a root with refs == 0. btrfs_get_new_fs_root() then\nfinds the root and returns -ENOENT if refs == 0, which causes\ncreate_pending_snapshot() to abort.\n\nFix it by checking the source root's refs before attempting the snapshot\n(but after locking subvol_sem to avoid racing with deletion).\n\nSigned-off-by: Omar Sandoval <osandov@fb.com>","shortMessageHtmlLink":"btrfs: don't abort filesystem when attempting to snapshot deleted sub…"}},{"before":"2c6911abc8be0c434b7ae3e33048efbae7110094","after":"554f3ce85edca54d14cc1e1b22c4207a3e8f36a7","ref":"refs/heads/xfs-realtime-optimizations","pushedAt":"2023-06-20T21:30:57.780Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"osandov","name":"Omar Sandoval","path":"/osandov","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/3682206?s=80&v=4"},"commit":{"message":"xfs: don't look for end of extent further than necessary in xfs_rtallocate_extent_near()\n\nAs explained in the previous commit, xfs_rtallocate_extent_near() looks\nfor the end of a free extent when searching backwards from the target\nbitmap block. Since the previous commit, it searches from the last\nbitmap block it checked to the bitmap block containing the start of the\nextent.\n\nThis may still be more than necessary, since the free extent may not be\nthat long. We know the maximum size of the free extent from the realtime\nsummary. Use that to compute how many bitmap blocks we actually need to\ncheck.\n\nSigned-off-by: Omar Sandoval <osandov@fb.com>","shortMessageHtmlLink":"xfs: don't look for end of extent further than necessary in xfs_rtall…"}},{"before":"2bbe8c2b11b88cecace8d991d59812f506a1f34f","after":"2c6911abc8be0c434b7ae3e33048efbae7110094","ref":"refs/heads/xfs-realtime-optimizations","pushedAt":"2023-06-20T18:35:08.672Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"osandov","name":"Omar Sandoval","path":"/osandov","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/3682206?s=80&v=4"},"commit":{"message":"xfs: don't look for end of extent further than necessary in xfs_rtallocate_extent_near()\n\nAs explained in the previous commit, xfs_rtallocate_extent_near() looks\nfor the end of a free extent when searching backwards from the target\nbitmap block. Since the previous commit, it searches from the last\nbitmap block it checked to the bitmap block containing the start of the\nextent.\n\nThis may still be more than necessary, since the free extent may not be\nthat long. We know the maximum size of the free extent from the realtime\nsummary. Use that to compute how many bitmap blocks we actually need to\ncheck.\n\nSigned-off-by: Omar Sandoval <osandov@fb.com>","shortMessageHtmlLink":"xfs: don't look for end of extent further than necessary in xfs_rtall…"}},{"before":"5ba181479ccf1893587b681617fbeadd7ef8d5df","after":"2bbe8c2b11b88cecace8d991d59812f506a1f34f","ref":"refs/heads/xfs-realtime-optimizations","pushedAt":"2023-06-15T22:58:20.260Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"osandov","name":"Omar Sandoval","path":"/osandov","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/3682206?s=80&v=4"},"commit":{"message":"xfs: don't look for end of extent further than necessary in xfs_rtallocate_extent_near()\n\nAs explained in the previous commit, xfs_rtallocate_extent_near() looks\nfor the end of a free extent when searching backwards from the target\nbitmap block. Since the previous commit, it searches from the last\nbitmap block it checked to the bitmap block containing the start of the\nextent.\n\nThis may still be more than necessary, since the free extent may not be\nthat long. We know the maximum size of the free extent from the realtime\nsummary. Use that to compute how many bitmap blocks we actually need to\ncheck.\n\nSigned-off-by: Omar Sandoval <osandov@fb.com>","shortMessageHtmlLink":"xfs: don't look for end of extent further than necessary in xfs_rtall…"}},{"before":"0a5beea7d4da72c307bcf1e5a605c41cfd5b76c4","after":null,"ref":"refs/heads/btrfs-space-cache-fix","pushedAt":"2023-06-14T23:01:56.437Z","pushType":"branch_deletion","commitsCount":0,"pusher":{"login":"osandov","name":"Omar Sandoval","path":"/osandov","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/3682206?s=80&v=4"}},{"before":"ef1302160bfb19f804451d0e919266703501c875","after":"b6dad5178ceaf23f369c3711062ce1f2afc33644","ref":"refs/heads/master","pushedAt":"2023-06-14T23:00:31.545Z","pushType":"push","commitsCount":10000,"pusher":{"login":"osandov","name":"Omar Sandoval","path":"/osandov","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/3682206?s=80&v=4"},"commit":{"message":"Merge tag 'nios2_fix_v6.4' of git://git.kernel.org/pub/scm/linux/kernel/git/dinguyen/linux\n\nPull NIOS2 dts fix from Dinh Nguyen:\n\n - Fix tse_mac \"max-frame-size\" property\n\n* tag 'nios2_fix_v6.4' of git://git.kernel.org/pub/scm/linux/kernel/git/dinguyen/linux:\n  nios2: dts: Fix tse_mac \"max-frame-size\" property","shortMessageHtmlLink":"Merge tag 'nios2_fix_v6.4' of git://git.kernel.org/pub/scm/linux/kern…"}},{"before":"836f1fbe6112ab89c6f592faaaea0dddb24fb8fe","after":null,"ref":"refs/heads/btrfs-send-encoded-v2","pushedAt":"2023-06-14T22:55:25.450Z","pushType":"branch_deletion","commitsCount":0,"pusher":{"login":"osandov","name":"Omar Sandoval","path":"/osandov","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/3682206?s=80&v=4"}},{"before":"b34b944803961595435a34f3c09912830f194e00","after":null,"ref":"refs/heads/btrfs-send-encoded-v1","pushedAt":"2023-06-14T22:55:25.450Z","pushType":"branch_deletion","commitsCount":0,"pusher":{"login":"osandov","name":"Omar Sandoval","path":"/osandov","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/3682206?s=80&v=4"}},{"before":"0ee5b87f9ee41b8061a07bc5b2a433123ddf2c0c","after":null,"ref":"refs/heads/btrfs-send-encoded","pushedAt":"2023-06-14T22:55:25.450Z","pushType":"branch_deletion","commitsCount":0,"pusher":{"login":"osandov","name":"Omar Sandoval","path":"/osandov","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/3682206?s=80&v=4"}},{"before":"456320cb2c350a123c43f0815950c7dcb50423d4","after":null,"ref":"refs/heads/btrfs-send-encoded-v4-rwf-encoded-v9","pushedAt":"2023-06-14T22:55:05.333Z","pushType":"branch_deletion","commitsCount":0,"pusher":{"login":"osandov","name":"Omar Sandoval","path":"/osandov","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/3682206?s=80&v=4"}},{"before":"e0cd3910d8cb650fed229e4df7eca97d29c95639","after":null,"ref":"refs/heads/btrfs-send-encoded-v4","pushedAt":"2023-06-14T22:55:05.333Z","pushType":"branch_deletion","commitsCount":0,"pusher":{"login":"osandov","name":"Omar Sandoval","path":"/osandov","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/3682206?s=80&v=4"}},{"before":"d8e787b3ee721d404ac56ed2af65a6bbe06b14c4","after":null,"ref":"refs/heads/btrfs-send-encoded-v3","pushedAt":"2023-06-14T22:55:05.333Z","pushType":"branch_deletion","commitsCount":0,"pusher":{"login":"osandov","name":"Omar Sandoval","path":"/osandov","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/3682206?s=80&v=4"}},{"before":"0ee5b87f9ee41b8061a07bc5b2a433123ddf2c0c","after":null,"ref":"refs/heads/btrfs-send-encoded-v15","pushedAt":"2023-06-14T22:55:05.333Z","pushType":"branch_deletion","commitsCount":0,"pusher":{"login":"osandov","name":"Omar Sandoval","path":"/osandov","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/3682206?s=80&v=4"}},{"before":"71ec89beca3ab00460b345e58d031680e61d22d2","after":null,"ref":"refs/heads/btrfs-send-encoded-v13","pushedAt":"2023-06-14T22:55:05.333Z","pushType":"branch_deletion","commitsCount":0,"pusher":{"login":"osandov","name":"Omar Sandoval","path":"/osandov","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/3682206?s=80&v=4"}},{"before":"a5811f269abad35318ef8c2867566bab66860fe1","after":null,"ref":"refs/heads/btrfs-send-encoded-v12","pushedAt":"2023-06-14T22:55:05.333Z","pushType":"branch_deletion","commitsCount":0,"pusher":{"login":"osandov","name":"Omar Sandoval","path":"/osandov","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/3682206?s=80&v=4"}},{"before":"61a4a5b6bf694c7441b2ba04b724d012997fa3f7","after":null,"ref":"refs/heads/btrfs-send-encoded-v11","pushedAt":"2023-06-14T22:55:05.333Z","pushType":"branch_deletion","commitsCount":0,"pusher":{"login":"osandov","name":"Omar Sandoval","path":"/osandov","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/3682206?s=80&v=4"}},{"before":"a87f8dd5b9e777c136ab986baa9b751f9c1909a6","after":null,"ref":"refs/heads/btrfs-send-encoded-v10","pushedAt":"2023-06-14T22:55:05.333Z","pushType":"branch_deletion","commitsCount":0,"pusher":{"login":"osandov","name":"Omar Sandoval","path":"/osandov","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/3682206?s=80&v=4"}},{"before":null,"after":"5ba181479ccf1893587b681617fbeadd7ef8d5df","ref":"refs/heads/xfs-realtime-optimizations","pushedAt":"2023-06-14T22:50:23.492Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"osandov","name":"Omar Sandoval","path":"/osandov","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/3682206?s=80&v=4"},"commit":{"message":"xfs: don't look for end of extent further than necessary in xfs_rtallocate_extent_near()\n\nAs explained in the previous commit, xfs_rtallocate_extent_near() looks\nfor the end of a free extent when searching backwards from the target\nbitmap block. Since the previous commit, it searches from the last\nbitmap block it checked to the bitmap block containing the start of the\nextent.\n\nThis may still be more than necessary, since the free extent may not be\nthat long. We know the maximum size of the free extent from the realtime\nsummary. Use that to compute how many bitmap blocks we actually need to\ncheck.\n\nSigned-off-by: Omar Sandoval <osandov@fb.com>","shortMessageHtmlLink":"xfs: don't look for end of extent further than necessary in xfs_rtall…"}}],"hasNextPage":false,"hasPreviousPage":false,"activityType":"all","actor":null,"timePeriod":"all","sort":"DESC","perPage":30,"cursor":"djE6ks8AAAAEUz3K5QA","startCursor":null,"endCursor":null}},"title":"Activity · osandov/linux"}