)]}'
{
  "log": [
    {
      "commit": "91d9bdb83deffa675d0d2323433de0748effb581",
      "tree": "93fba966094fe479b9908b7918ca72cc1c72fd50",
      "parents": [
        "e51b89e657af7843d8c7aea3df49fe1f0f1d4ac2"
      ],
      "author": {
        "name": "Carlos Maiolino",
        "email": "cem@kernel.org",
        "time": "Thu Oct 12 13:23:53 2023 +0200"
      },
      "committer": {
        "name": "Carlos Maiolino",
        "email": "cem@kernel.org",
        "time": "Thu Oct 12 13:23:53 2023 +0200"
      },
      "message": "xfsprogs: Release v6.5.0\n\nUpdate all the necessary files for a 6.5.0 release.\n\nSigned-off-by: Carlos Maiolino \u003ccem@kernel.org\u003e\n"
    },
    {
      "commit": "e51b89e657af7843d8c7aea3df49fe1f0f1d4ac2",
      "tree": "15a3f6dc2147d63081006d21bb3f0f215787ef70",
      "parents": [
        "21226bb466c1053c0f9b2e600bbbee2f7a6960a2"
      ],
      "author": {
        "name": "Krzesimir Nowak",
        "email": "qdlacz@gmail.com",
        "time": "Thu Sep 28 13:23:38 2023 +0200"
      },
      "committer": {
        "name": "Carlos Maiolino",
        "email": "cem@kernel.org",
        "time": "Thu Oct 05 14:57:25 2023 +0200"
      },
      "message": "libfrog: drop build host crc32 selftest\n\nCRC selftests running on a build host were useful long time ago, when\nCRC support was added to the on-disk support. Now it\u0027s purpose is\nreplaced by fstests. Also mkfs.xfs and xfs_repair have their own\nselftests.\n\nOn top of that, it adds a dependency on liburcu on the build host for\nno reason - liburcu is not used by the crc32 selftest.\n\nSigned-off-by: Krzesimir Nowak \u003cknowak@microsoft.com\u003e\nReviewed-by: Darrick J. Wong \u003cdjwong@kernel.org\u003e\nSigned-off-by: Carlos Maiolino \u003ccem@kernel.org\u003e\n"
    },
    {
      "commit": "21226bb466c1053c0f9b2e600bbbee2f7a6960a2",
      "tree": "98f14c49fe95b981886a2e517805d5425c35dcf8",
      "parents": [
        "75325b82a66185ae9d0360193a271640e8c9a3ea"
      ],
      "author": {
        "name": "Darrick J. Wong",
        "email": "djwong@kernel.org",
        "time": "Tue Sep 12 12:47:51 2023 -0700"
      },
      "committer": {
        "name": "Carlos Maiolino",
        "email": "cem@kernel.org",
        "time": "Thu Oct 05 14:57:20 2023 +0200"
      },
      "message": "libxfs: fix atomic64_t detection on x86 32-bit architectures\n\nxfsprogs during compilation tries to detect if liburcu supports atomic\n64-bit ops on the platform it is being compiled on, and if not it falls\nback to using pthread mutex locks.\n\nThe detection logic for that fallback relies on _uatomic_link_error()\nwhich is a link-time trick used by liburcu that will cause compilation\nerrors on archs that lack the required support. That only works for the\ngeneric liburcu code though, and it is not implemented for the\nx86-specific code.\n\nIn practice this means that when xfsprogs is compiled on 32-bit x86\narchs will successfully link to liburcu for atomic ops, but liburcu does\nnot support atomic64_t on those archs. It indicates this during runtime\nby generating an illegal instruction that aborts execution, and thus\ncauses various xfsprogs utils to be segfaulting.\n\nFix this by requiring that unsigned longs are at least 64 bits in size,\nwhich /usually/ means that 64-bit atomic counters are supported.  We\ncan\u0027t simply execute the liburcu atomic64_t detection code during\nconfigure instead of only relying on the linker error because that\ndoesn\u0027t work for cross-compiled packages.\n\nFixes: 7448af588a2e (\"libxfs: fix atomic64_t poorly for 32-bit architectures\")\nReported-by: Anthony Iliopoulos \u003cailiop@suse.com\u003e\nSigned-off-by: Darrick J. Wong \u003cdjwong@kernel.org\u003e\nReviewed-by: Carlos Maiolino \u003ccmaiolino@redhat.com\u003e\nReviewed-by: Bill O\u0027Donnell \u003cbodonnel@redhat.com\u003e\nSigned-off-by: Carlos Maiolino \u003ccem@kernel.org\u003e\n"
    },
    {
      "commit": "75325b82a66185ae9d0360193a271640e8c9a3ea",
      "tree": "f14f63e8f6f2f14eb239883eccdd53b39e840a28",
      "parents": [
        "92c1851160c5142d4bd8f4d25c28322024fdf24b"
      ],
      "author": {
        "name": "Darrick J. Wong",
        "email": "djwong@kernel.org",
        "time": "Tue Sep 12 12:40:04 2023 -0700"
      },
      "committer": {
        "name": "Carlos Maiolino",
        "email": "cem@kernel.org",
        "time": "Thu Oct 05 14:57:20 2023 +0200"
      },
      "message": "xfs_repair: set aformat and anextents correctly when clearing the attr fork\n\nEver since commit b42db0860e130 (\"xfs: enhance dinode verifier\"), we\u0027ve\nrequired that inodes with zero di_forkoff must also have di_aformat \u003d\u003d\nEXTENTS and di_naextents \u003d\u003d 0.  clear_dinode_attr actually does this,\nbut then both callers inexplicably set di_format \u003d LOCAL.  That in turn\ncauses a verifier failure the next time the xattrs of that file are\nread by the kernel.  Get rid of the bogus field write.\n\nSigned-off-by: Darrick J. Wong \u003cdjwong@kernel.org\u003e\nReviewed-by: Carlos Maiolino \u003ccmaiolino@redhat.com\u003e\nReviewed-by: Bill O\u0027Donnell \u003cbodonnel@redhat.com\u003e\nSigned-off-by: Carlos Maiolino \u003ccem@kernel.org\u003e\n"
    },
    {
      "commit": "92c1851160c5142d4bd8f4d25c28322024fdf24b",
      "tree": "c1ea0f7ea367dd7858a1d84093ccd52437dee5a0",
      "parents": [
        "7f5bbe286e02b0c7df72aba386b56af92b812dc3"
      ],
      "author": {
        "name": "Darrick J. Wong",
        "email": "djwong@kernel.org",
        "time": "Tue Sep 12 12:39:58 2023 -0700"
      },
      "committer": {
        "name": "Carlos Maiolino",
        "email": "cem@kernel.org",
        "time": "Thu Oct 05 14:57:20 2023 +0200"
      },
      "message": "xfs_scrub: actually return errno from check_xattr_ns_names\n\nActually return the error code when extended attribute checks fail.\n\nSigned-off-by: Darrick J. Wong \u003cdjwong@kernel.org\u003e\nReviewed-by: Carlos Maiolino \u003ccmaiolino@redhat.com\u003e\nSigned-off-by: Carlos Maiolino \u003ccem@kernel.org\u003e\n"
    },
    {
      "commit": "7f5bbe286e02b0c7df72aba386b56af92b812dc3",
      "tree": "cd913ab97e9870b63f9e8db19026c00d773e3fa7",
      "parents": [
        "03582d3f3b45e6a6de5dabc30d7ae42baeea3da8"
      ],
      "author": {
        "name": "Darrick J. Wong",
        "email": "djwong@kernel.org",
        "time": "Tue Sep 12 12:39:52 2023 -0700"
      },
      "committer": {
        "name": "Carlos Maiolino",
        "email": "cem@kernel.org",
        "time": "Thu Oct 05 14:57:20 2023 +0200"
      },
      "message": "libxfs: use XFS_IGET_CREATE when creating new files\n\nUse this flag to check that newly allocated inodes are, in fact,\nunallocated.  This matches the kernel, and prevents userspace programs\nfrom making latent corruptions worse by unintentionally crosslinking\nfiles.\n\nSigned-off-by: Darrick J. Wong \u003cdjwong@kernel.org\u003e\nReviewed-by: Carlos Maiolino \u003ccmaiolino@redhat.com\u003e\nReviewed-by: Bill O\u0027Donnell \u003cbodonnel@redhat.com\u003e\nSigned-off-by: Carlos Maiolino \u003ccem@kernel.org\u003e\n"
    },
    {
      "commit": "03582d3f3b45e6a6de5dabc30d7ae42baeea3da8",
      "tree": "101eec49b32c49557952780f6142e245434c4902",
      "parents": [
        "12838bda12e6693dee72118f9187bf64201aac02"
      ],
      "author": {
        "name": "Darrick J. Wong",
        "email": "djwong@kernel.org",
        "time": "Tue Sep 12 12:39:47 2023 -0700"
      },
      "committer": {
        "name": "Carlos Maiolino",
        "email": "cem@kernel.org",
        "time": "Thu Oct 05 14:57:20 2023 +0200"
      },
      "message": "libfrog: don\u0027t fail on XFS_FSOP_GEOM_FLAGS_NREXT64 in xfrog_bulkstat_single5\n\nThis flag is perfectly acceptable for bulkstatting a single file;\nthere\u0027s no reason not to allow it.\n\nSigned-off-by: Darrick J. Wong \u003cdjwong@kernel.org\u003e\nReviewed-by: Carlos Maiolino \u003ccmaiolino@redhat.com\u003e\nSigned-off-by: Carlos Maiolino \u003ccem@kernel.org\u003e\n"
    },
    {
      "commit": "12838bda12e6693dee72118f9187bf64201aac02",
      "tree": "bfde9197f3a4013e01895180ac586f11e0a035dc",
      "parents": [
        "1bd1a58a723b5995effa6fdca643d16502864eba"
      ],
      "author": {
        "name": "Darrick J. Wong",
        "email": "djwong@kernel.org",
        "time": "Tue Sep 12 12:39:41 2023 -0700"
      },
      "committer": {
        "name": "Carlos Maiolino",
        "email": "cem@kernel.org",
        "time": "Thu Oct 05 14:57:20 2023 +0200"
      },
      "message": "libfrog: fix overly sleep workqueues\n\nI discovered the following bad behavior in the workqueue code when I\nnoticed that xfs_scrub was running single-threaded despite having 4\nvirtual CPUs allocated to the VM.  I observed this sequence:\n\nThread 1\tWQ1\t\tWQ2...N\nworkqueue_create\n\t\t\u003cstart up\u003e\n\t\tpthread_cond_wait\n\t\t\t\t\u003cstart up\u003e\n\t\t\t\tpthread_cond_wait\nworkqueue_add\nnext_item \u003d\u003d NULL\npthread_cond_signal\n\nworkqueue_add\nnext_item !\u003d NULL\n\u003cdo not pthread_cond_signal\u003e\n\n\t\t\u003creceives wakeup\u003e\n\t\t\u003crun first item\u003e\n\nworkqueue_add\nnext_item !\u003d NULL\n\u003cdo not pthread_cond_signal\u003e\n\n\t\t\u003crun second item\u003e\n\t\t\u003crun third item\u003e\n\t\tpthread_cond_wait\n\nworkqueue_terminate\npthread_cond_broadcast\n\t\t\t\t\u003creceives wakeup\u003e\n\t\t\t\t\u003cnothing to do, exits\u003e\n\t\t\u003cwakes up again\u003e\n\t\t\u003cnothing to do, exits\u003e\n\nNotice how threads WQ2...N are completely idle while WQ1 ends up doing\nall the work!  That wasn\u0027t the point of a worker pool!  Observe that\nthread 1 manages to queue two work items before WQ1 pulls the first item\noff the queue.  When thread 1 queues the third item, it sees that\nnext_item is not NULL, so it doesn\u0027t wake a worker.  If thread 1 queues\nall the N work that it has before WQ1 empties the queue, then none of\nthe other thread get woken up.\n\nFix this by maintaining a count of the number of active threads, and\nusing that to wake either the sole idle thread, or all the threads if\nthere are many that are idle.  This dramatically improves startup\nbehavior of the workqueue and eliminates the collapse case.\n\nSigned-off-by: Darrick J. Wong \u003cdjwong@kernel.org\u003e\nReviewed-by: Carlos Maiolino \u003ccmaiolino@redhat.com\u003e\nSigned-off-by: Carlos Maiolino \u003ccem@kernel.org\u003e\n"
    },
    {
      "commit": "1bd1a58a723b5995effa6fdca643d16502864eba",
      "tree": "d6dda96fef26c691d94af5a17b7a10e1039ae777",
      "parents": [
        "244199cd9ae1d136cec985885e4c336145e74a26"
      ],
      "author": {
        "name": "Darrick J. Wong",
        "email": "djwong@kernel.org",
        "time": "Mon Sep 25 14:59:16 2023 -0700"
      },
      "committer": {
        "name": "Carlos Maiolino",
        "email": "cem@kernel.org",
        "time": "Thu Oct 05 14:57:20 2023 +0200"
      },
      "message": "xfs_db: use directio for device access\n\nXFS and tools (mkfs, copy, repair) don\u0027t generally rely on the block\ndevice page cache, preferring instead to use directio.  For whatever\nreason, the debugger was never made to do this, but let\u0027s do that now.\n\nThis should eliminate the weird fstests failures resulting from\nudev/blkid pinning a cache page while the unmounting filesystem writes\nto the superblock such that xfs_db finds the stale pagecache instead of\nthe post-unmount superblock.\n\nSigned-off-by: Darrick J. Wong \u003cdjwong@kernel.org\u003e\nReviewed-by: Carlos Maiolino \u003ccmaiolino@redhat.com\u003e\nSigned-off-by: Carlos Maiolino \u003ccem@kernel.org\u003e\n"
    },
    {
      "commit": "244199cd9ae1d136cec985885e4c336145e74a26",
      "tree": "139790561d9b3f643e9919f819da205baac7ce4f",
      "parents": [
        "1e8897d53374026aa4fc76e7d70d73bac85fe668"
      ],
      "author": {
        "name": "Darrick J. Wong",
        "email": "djwong@kernel.org",
        "time": "Mon Sep 25 14:59:10 2023 -0700"
      },
      "committer": {
        "name": "Carlos Maiolino",
        "email": "cem@kernel.org",
        "time": "Thu Oct 05 14:57:19 2023 +0200"
      },
      "message": "libxfs: make platform_set_blocksize optional with directio\n\nIf we\u0027re accessing the block device with directio (and hence bypassing\nthe page cache), then don\u0027t fail on BLKBSZSET not working.  We don\u0027t\ncare what happens to the pagecache bufferheads.\n\nSigned-off-by: Darrick J. Wong \u003cdjwong@kernel.org\u003e\nReviewed-by: Carlos Maiolino \u003ccmaiolino@redhat.com\u003e\nSigned-off-by: Carlos Maiolino \u003ccem@kernel.org\u003e\n"
    },
    {
      "commit": "1e8897d53374026aa4fc76e7d70d73bac85fe668",
      "tree": "afe9cd7aedb904caebad23b7ab86809062b48355",
      "parents": [
        "bcd5b1b766e62e7ad322cc814c142ebbc889101c"
      ],
      "author": {
        "name": "Darrick J. Wong",
        "email": "djwong@kernel.org",
        "time": "Mon Sep 25 14:59:36 2023 -0700"
      },
      "committer": {
        "name": "Carlos Maiolino",
        "email": "cem@kernel.org",
        "time": "Thu Oct 05 14:57:19 2023 +0200"
      },
      "message": "mkfs: add a config file for 6.6 LTS kernels\n\nEnable 64-bit extent counts and reverse mapping for 6.6.\n\nSigned-off-by: Darrick J. Wong \u003cdjwong@kernel.org\u003e\nReviewed-by: Carlos Maiolino \u003ccmaiolino@redhat.com\u003e\nSigned-off-by: Carlos Maiolino \u003ccem@kernel.org\u003e\n"
    },
    {
      "commit": "bcd5b1b766e62e7ad322cc814c142ebbc889101c",
      "tree": "45ebffd75cdaaea1b9c75d19a40e5f8ee6ae7514",
      "parents": [
        "e5b18d7d1d962e942ce3b0a9ccdb5872074e24df"
      ],
      "author": {
        "name": "Darrick J. Wong",
        "email": "djwong@kernel.org",
        "time": "Mon Sep 25 14:59:30 2023 -0700"
      },
      "committer": {
        "name": "Carlos Maiolino",
        "email": "cem@kernel.org",
        "time": "Thu Oct 05 14:57:19 2023 +0200"
      },
      "message": "mkfs: enable reverse mapping by default\n\nNow that online fsck is feature complete, there\u0027s actually a compelling\nstory for having the reverse mappings enabled.  Turn it on by default.\n\nSigned-off-by: Darrick J. Wong \u003cdjwong@kernel.org\u003e\nReviewed-by: Carlos Maiolino \u003ccmaiolino@redhat.com\u003e\nSigned-off-by: Carlos Maiolino \u003ccem@kernel.org\u003e\n"
    },
    {
      "commit": "e5b18d7d1d962e942ce3b0a9ccdb5872074e24df",
      "tree": "21a78c604b126911fabb145fc31de4315ddd7318",
      "parents": [
        "4a9f92d023934ca6d436c8ca0e7a62702540a4ba"
      ],
      "author": {
        "name": "Darrick J. Wong",
        "email": "djwong@kernel.org",
        "time": "Mon Sep 25 14:59:25 2023 -0700"
      },
      "committer": {
        "name": "Carlos Maiolino",
        "email": "cem@kernel.org",
        "time": "Thu Oct 05 14:57:19 2023 +0200"
      },
      "message": "mkfs: enable large extent counts by default\n\nFormat filesystems with the large extent counter feature turned on.\nWe shall now support 64-bit extent counts for the data fork and 32-bit\nextent counts for the attr fork.\n\nSigned-off-by: Darrick J. Wong \u003cdjwong@kernel.org\u003e\nReviewed-by: Carlos Maiolino \u003ccmaiolino@redhat.com\u003e\nSigned-off-by: Carlos Maiolino \u003ccem@kernel.org\u003e\n"
    },
    {
      "commit": "4a9f92d023934ca6d436c8ca0e7a62702540a4ba",
      "tree": "4a54e30c931998633f58f9f783aa8460c2d30b9f",
      "parents": [
        "69b07d331612421f7e9b3723cc1afa527769f5c0"
      ],
      "author": {
        "name": "Darrick J. Wong",
        "email": "djwong@kernel.org",
        "time": "Mon Sep 25 14:59:51 2023 -0700"
      },
      "committer": {
        "name": "Carlos Maiolino",
        "email": "cem@kernel.org",
        "time": "Thu Oct 05 14:57:19 2023 +0200"
      },
      "message": "xfs_db: create unlinked inodes\n\nCreate an expert-mode debugger command to create unlinked inodes.\nThis will hopefully aid in simulation of leaked unlinked inode handling\nin the kernel and elsewhere.\n\nSigned-off-by: Darrick J. Wong \u003cdjwong@kernel.org\u003e\nReviewed-by: Bill O\u0027Donnell \u003cbodonnel@redhat.com\u003e\nReviewed-by: Carlos Maiolino \u003ccmaiolino@redhat.com\u003e\nSigned-off-by: Carlos Maiolino \u003ccem@kernel.org\u003e\n"
    },
    {
      "commit": "69b07d331612421f7e9b3723cc1afa527769f5c0",
      "tree": "442647d760213ded2182c208a678dbb11ac0d06e",
      "parents": [
        "e17ccef351b424b11ddccc9d228d02a025f9639a"
      ],
      "author": {
        "name": "Darrick J. Wong",
        "email": "djwong@kernel.org",
        "time": "Mon Sep 25 14:59:45 2023 -0700"
      },
      "committer": {
        "name": "Carlos Maiolino",
        "email": "cem@kernel.org",
        "time": "Thu Oct 05 14:56:23 2023 +0200"
      },
      "message": "xfs_db: dump unlinked buckets\n\nCreate a new command to dump the resource usage of files in the unlinked\nbuckets.\n\nSigned-off-by: Darrick J. Wong \u003cdjwong@kernel.org\u003e\nReviewed-by: Bill O\u0027Donnell \u003cbodonnel@redhat.com\u003e\nReviewed-by: Carlos Maiolino \u003ccmaiolino@redhat.com\u003e\nSigned-off-by: Carlos Maiolino \u003ccem@kernel.org\u003e\n"
    },
    {
      "commit": "e17ccef351b424b11ddccc9d228d02a025f9639a",
      "tree": "ca8514ec142320b31e4f0847fa3b69fa9cb9eb78",
      "parents": [
        "39e9f4c2937a881293a1c5554a96197340a31879"
      ],
      "author": {
        "name": "Darrick J. Wong",
        "email": "djwong@kernel.org",
        "time": "Thu Sep 07 11:41:01 2023 +0200"
      },
      "committer": {
        "name": "Carlos Maiolino",
        "email": "cem@kernel.org",
        "time": "Thu Sep 07 11:55:50 2023 +0200"
      },
      "message": "xfs: convert flex-array declarations in xfs attr shortform objects\n\nSource kernel commit: f6250e205691a58c81be041b1809a2e706852641\n\nAs of 6.5-rc1, UBSAN trips over the ondisk extended attribute shortform\ndefinitions using an array length of 1 to pretend to be a flex array.\nKernel compilers have to support unbounded array declarations, so let\u0027s\ncorrect this.\n\nSigned-off-by: Darrick J. Wong \u003cdjwong@kernel.org\u003e\nReviewed-by: Christoph Hellwig \u003chch@lst.de\u003e\nReviewed-by: Kees Cook \u003ckeescook@chromium.org\u003e\nSigned-off-by: Carlos Maiolino \u003ccem@kernel.org\u003e\n"
    },
    {
      "commit": "39e9f4c2937a881293a1c5554a96197340a31879",
      "tree": "92287cec4961f316b6e608a152f88626ea422ab6",
      "parents": [
        "deccac70bd6e2c839c4bb9c6ee0a7241a50d3e42"
      ],
      "author": {
        "name": "Darrick J. Wong",
        "email": "djwong@kernel.org",
        "time": "Thu Sep 07 11:40:40 2023 +0200"
      },
      "committer": {
        "name": "Carlos Maiolino",
        "email": "cem@kernel.org",
        "time": "Thu Sep 07 11:55:50 2023 +0200"
      },
      "message": "xfs: convert flex-array declarations in xfs attr leaf blocks\n\nSource kernel commit: a49bbce58ea90b14d4cb1d00681023a8606955f2\n\nAs of 6.5-rc1, UBSAN trips over the ondisk extended attribute leaf block\ndefinitions using an array length of 1 to pretend to be a flex array.\nKernel compilers have to support unbounded array declarations, so let\u0027s\ncorrect this.\n\n\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\nUBSAN: array-index-out-of-bounds in fs/xfs/libxfs/xfs_attr_leaf.c:2535:24\nindex 2 is out of range for type \u0027__u8 [1]\u0027\nCall Trace:\n\u003cTASK\u003e\ndump_stack_lvl+0x33/0x50\n__ubsan_handle_out_of_bounds+0x9c/0xd0\nxfs_attr3_leaf_getvalue+0x2ce/0x2e0 [xfs 4a986a89a77bb77402ab8a87a37da369ef6a3f09]\nxfs_attr_leaf_get+0x148/0x1c0 [xfs 4a986a89a77bb77402ab8a87a37da369ef6a3f09]\nxfs_attr_get_ilocked+0xae/0x110 [xfs 4a986a89a77bb77402ab8a87a37da369ef6a3f09]\nxfs_attr_get+0xee/0x150 [xfs 4a986a89a77bb77402ab8a87a37da369ef6a3f09]\nxfs_xattr_get+0x7d/0xc0 [xfs 4a986a89a77bb77402ab8a87a37da369ef6a3f09]\n__vfs_getxattr+0xa3/0x100\nvfs_getxattr+0x87/0x1d0\ndo_getxattr+0x17a/0x220\ngetxattr+0x89/0xf0\n\nSigned-off-by: Darrick J. Wong \u003cdjwong@kernel.org\u003e\nReviewed-by: Christoph Hellwig \u003chch@lst.de\u003e\nReviewed-by: Kees Cook \u003ckeescook@chromium.org\u003e\nSigned-off-by: Carlos Maiolino \u003ccem@kernel.org\u003e\n"
    },
    {
      "commit": "deccac70bd6e2c839c4bb9c6ee0a7241a50d3e42",
      "tree": "ddd2d116fa033438c45b67a8497c8f0fb9070cfa",
      "parents": [
        "98572f41fbdf26a63f262be775dce1ade0b91520"
      ],
      "author": {
        "name": "Darrick J. Wong",
        "email": "djwong@kernel.org",
        "time": "Wed Sep 06 13:55:48 2023 +0200"
      },
      "committer": {
        "name": "Carlos Maiolino",
        "email": "cem@kernel.org",
        "time": "Thu Sep 07 11:55:50 2023 +0200"
      },
      "message": "xfs: convert flex-array declarations in struct xfs_attrlist*\n\nSource kernel commit: 371baf5c9750a258fee21d0cb8c8d683bb057429\n\nAs of 6.5-rc1, UBSAN trips over the attrlist ioctl definitions using an\narray length of 1 to pretend to be a flex array.  Kernel compilers have\nto support unbounded array declarations, so let\u0027s correct this.  This\nmay cause friction with userspace header declarations, but suck is life.\n\n\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\nUBSAN: array-index-out-of-bounds in fs/xfs/xfs_ioctl.c:345:18\nindex 1 is out of range for type \u0027__s32 [1]\u0027\nCall Trace:\n\u003cTASK\u003e\ndump_stack_lvl+0x33/0x50\n__ubsan_handle_out_of_bounds+0x9c/0xd0\nxfs_ioc_attr_put_listent+0x413/0x420 [xfs 4a986a89a77bb77402ab8a87a37da369ef6a3f09]\nxfs_attr_list_ilocked+0x170/0x850 [xfs 4a986a89a77bb77402ab8a87a37da369ef6a3f09]\nxfs_attr_list+0xb7/0x120 [xfs 4a986a89a77bb77402ab8a87a37da369ef6a3f09]\nxfs_ioc_attr_list+0x13b/0x2e0 [xfs 4a986a89a77bb77402ab8a87a37da369ef6a3f09]\nxfs_attrlist_by_handle+0xab/0x120 [xfs 4a986a89a77bb77402ab8a87a37da369ef6a3f09]\nxfs_file_ioctl+0x1ff/0x15e0 [xfs 4a986a89a77bb77402ab8a87a37da369ef6a3f09]\nvfs_ioctl+0x1f/0x60\n\nThe kernel and xfsprogs code that uses these structures will not have\nproblems, but the long tail of external user programs might.\n\nSigned-off-by: Darrick J. Wong \u003cdjwong@kernel.org\u003e\nReviewed-by: Christoph Hellwig \u003chch@lst.de\u003e\nReviewed-by: Kees Cook \u003ckeescook@chromium.org\u003e\nSigned-off-by: Carlos Maiolino \u003ccem@kernel.org\u003e\n"
    },
    {
      "commit": "98572f41fbdf26a63f262be775dce1ade0b91520",
      "tree": "ccf0f9047c4e9e3411c8cd35016a54ccb91cc909",
      "parents": [
        "05dcea079c30819909d513b488659a5fe2e876a2"
      ],
      "author": {
        "name": "Darrick J. Wong",
        "email": "djwong@kernel.org",
        "time": "Wed Sep 06 13:54:48 2023 +0200"
      },
      "committer": {
        "name": "Carlos Maiolino",
        "email": "cem@kernel.org",
        "time": "Thu Sep 07 11:55:50 2023 +0200"
      },
      "message": "xfs: AGI length should be bounds checked\n\nSource kernel commit: 2d7d1e7ea321b0b2810eb00183e21332ee9c4b6f\n\nSimilar to the recent patch strengthening the AGF agf_length\nverification, the AGI verifier does not check that the AGI length field\nis within known good bounds.  This isn\u0027t currently checked by runtime\nkernel code, yet we assume in many places that it is correct and verify\nother metadata against it.\n\nAdd length verification to the AGI verifier.  Just like the AGF length\nchecking, the length of the AGI must be equal to the size of the AG\nspecified in the superblock, unless it is the last AG in the filesystem.\nIn that case, it must be less than or equal to sb-\u003esb_agblocks and\ngreater than XFS_MIN_AG_BLOCKS, which is the smallest AG a growfs\noperation will allow to exist.\n\nThere\u0027s only one place in the filesystem that actually uses agi_length,\nbut let\u0027s not leave it vulnerable to the same weird nonsense that\ngenerates syzbot bugs, eh?\n\nSigned-off-by: Darrick J. Wong \u003cdjwong@kernel.org\u003e\nReviewed-by: Dave Chinner \u003cdchinner@redhat.com\u003e\nSigned-off-by: Carlos Maiolino \u003ccem@kernel.org\u003e\n"
    },
    {
      "commit": "05dcea079c30819909d513b488659a5fe2e876a2",
      "tree": "cc1afbccf63840d7c2b957528e5ce90ce559ec7f",
      "parents": [
        "d096b26c33a858ad88db98306057da67e6d18611"
      ],
      "author": {
        "name": "Darrick J. Wong",
        "email": "djwong@kernel.org",
        "time": "Wed Sep 06 13:53:48 2023 +0200"
      },
      "committer": {
        "name": "Carlos Maiolino",
        "email": "cem@kernel.org",
        "time": "Thu Sep 07 11:55:50 2023 +0200"
      },
      "message": "xfs: fix xfs_btree_query_range callers to initialize btree rec fully\n\nSource kernel commit: 75dc0345312221971903b2e28279b7e24b7dbb1b\n\nUse struct initializers to ensure that the xfs_btree_irecs passed into\nthe query_range function are completely initialized.  No functional\nchanges, just closing some sloppy hygiene.\n\nSigned-off-by: Darrick J. Wong \u003cdjwong@kernel.org\u003e\nReviewed-by: Dave Chinner \u003cdchinner@redhat.com\u003e\nSigned-off-by: Carlos Maiolino \u003ccem@kernel.org\u003e\n"
    },
    {
      "commit": "d096b26c33a858ad88db98306057da67e6d18611",
      "tree": "a71c4e83d90646f86ed6fc7cc0c71c54dc28523e",
      "parents": [
        "6ac452dcdd3ebefa34b0601ab5d231339afec8ad"
      ],
      "author": {
        "name": "Dave Chinner",
        "email": "dchinner@redhat.com",
        "time": "Wed Sep 06 13:52:48 2023 +0200"
      },
      "committer": {
        "name": "Carlos Maiolino",
        "email": "cem@kernel.org",
        "time": "Thu Sep 07 11:55:50 2023 +0200"
      },
      "message": "xfs: fix bounds check in xfs_defer_agfl_block()\n\nSource kernel commit: 2bed0d82c2f78b91a0a9a5a73da57ee883a0c070\n\nNeed to happen before we allocate and then leak the xefi. Found by\ncoverity via an xfsprogs libxfs scan.\n\n[djwong: This also fixes the type of the @agbno argument.]\n\nFixes: 7dfee17b13e5 (\"xfs: validate block number being freed before adding to xefi\")\nSigned-off-by: Dave Chinner \u003cdchinner@redhat.com\u003e\nReviewed-by: Christoph Hellwig \u003chch@lst.de\u003e\nReviewed-by: Darrick J. Wong \u003cdjwong@kernel.org\u003e\nSigned-off-by: Darrick J. Wong \u003cdjwong@kernel.org\u003e\nSigned-off-by: Carlos Maiolino \u003ccem@kernel.org\u003e\n"
    },
    {
      "commit": "6ac452dcdd3ebefa34b0601ab5d231339afec8ad",
      "tree": "12976b24cbf8e08336f525a988190bbfc4cc8ed2",
      "parents": [
        "5835a5620a0294f1bd164d897d15f65607ee6291"
      ],
      "author": {
        "name": "Dave Chinner",
        "email": "dchinner@redhat.com",
        "time": "Wed Sep 06 13:51:48 2023 +0200"
      },
      "committer": {
        "name": "Carlos Maiolino",
        "email": "cem@kernel.org",
        "time": "Thu Sep 07 11:55:50 2023 +0200"
      },
      "message": "xfs: AGF length has never been bounds checked\n\nSource kernel commit: edd8276dd70279c29d412d99b99c2c0cac1b2cdd\n\nThe AGF verifier does not check that the AGF length field is within\nknown good bounds. This has never been checked by runtime kernel\ncode (i.e. the lack of verification goes back to 1993) yet we assume\nin many places that it is correct and verify other metdata against\nit.\n\nAdd length verification to the AGF verifier. The length of the AGF\nmust be equal to the size of the AG specified in the superblock,\nunless it is the last AG in the filesystem. In that case, it must be\nless than or equal to sb-\u003esb_agblocks and greater than\nXFS_MIN_AG_BLOCKS, which is the smallest AG a growfs operation will\nallow to exist.\n\nThis requires a bit of rework of the verifier function. We want to\nverify metadata before we use it to verify other metadata. Hence\nwe need to verify the AGF sequence numbers before using them to\nverify the length of the AGF. Then we can verify the AGF length\nbefore we verify AGFL fields. Then we can verifier other fields that\nare bounds limited by the AGF length.\n\nAnd, finally, by calculating agf_length only once into a local\nvariable, we can collapse repeated \"if (xfs_has_foo() \u0026\u0026\"\nconditionaly checks into single checks. This makes the code much\neasier to follow as all the checks for a given feature are obviously\nin the same place.\n\nSigned-off-by: Dave Chinner \u003cdchinner@redhat.com\u003e\nReviewed-by: Christoph Hellwig \u003chch@lst.de\u003e\nReviewed-by: Darrick J. Wong \u003cdjwong@kernel.org\u003e\nSigned-off-by: Darrick J. Wong \u003cdjwong@kernel.org\u003e\nSigned-off-by: Carlos Maiolino \u003ccem@kernel.org\u003e\n"
    },
    {
      "commit": "5835a5620a0294f1bd164d897d15f65607ee6291",
      "tree": "34d988561677b7322714cc052f0b4f120efaa45d",
      "parents": [
        "4127f5dc0488840bd2ab5188b400d21cef22435e"
      ],
      "author": {
        "name": "Dave Chinner",
        "email": "dchinner@redhat.com",
        "time": "Wed Sep 06 13:50:48 2023 +0200"
      },
      "committer": {
        "name": "Carlos Maiolino",
        "email": "cem@kernel.org",
        "time": "Thu Sep 07 11:55:50 2023 +0200"
      },
      "message": "xfs: journal geometry is not properly bounds checked\n\nSource kernel commit: f1e1765aad7de7a8b8102044fc6a44684bc36180\n\nIf the journal geometry results in a sector or log stripe unit\nvalidation problem, it indicates that we cannot set the log up to\nsafely write to the the journal. In these cases, we must abort the\nmount because the corruption needs external intervention to resolve.\nSimilarly, a journal that is too large cannot be written to safely,\neither, so we shouldn\u0027t allow those geometries to mount, either.\n\nIf the log is too small, we risk having transaction reservations\noverruning the available log space and the system hanging waiting\nfor space it can never provide. This is purely a runtime hang issue,\nnot a corruption issue as per the first cases listed above. We abort\nmounts of the log is too small for V5 filesystems, but we must allow\nv4 filesystems to mount because, historically, there was no log size\nvalidity checking and so some systems may still be out there with\nundersized logs.\n\nThe problem is that on V4 filesystems, when we discover a log\ngeometry problem, we skip all the remaining checks and then allow\nthe log to continue mounting. This mean that if one of the log size\nchecks fails, we skip the log stripe unit check. i.e. we allow the\nmount because a \"non-fatal\" geometry is violated, and then fail to\ncheck the hard fail geometries that should fail the mount.\n\nMove all these fatal checks to the superblock verifier, and add a\nnew check for the two log sector size geometry variables having the\nsame values. This will prevent any attempt to mount a log that has\ninvalid or inconsistent geometries long before we attempt to mount\nthe log.\n\nHowever, for the minimum log size checks, we can only do that once\nwe\u0027ve setup up the log and calculated all the iclog sizes and\nroundoffs. Hence this needs to remain in the log mount code after\nthe log has been initialised. It is also the only case where we\nshould allow a v4 filesystem to continue running, so leave that\nhandling in place, too.\n\nSigned-off-by: Dave Chinner \u003cdchinner@redhat.com\u003e\nReviewed-by: Christoph Hellwig \u003chch@lst.de\u003e\nReviewed-by: Darrick J. Wong \u003cdjwong@kernel.org\u003e\nSigned-off-by: Darrick J. Wong \u003cdjwong@kernel.org\u003e\nSigned-off-by: Carlos Maiolino \u003ccem@kernel.org\u003e\n"
    },
    {
      "commit": "4127f5dc0488840bd2ab5188b400d21cef22435e",
      "tree": "a78eb3aa6a307d2ea419530fd48832612c8ba894",
      "parents": [
        "01f05365c9456a598164a7d49eabcac22500fa1f"
      ],
      "author": {
        "name": "Dave Chinner",
        "email": "dchinner@redhat.com",
        "time": "Wed Sep 06 13:50:32 2023 +0200"
      },
      "committer": {
        "name": "Carlos Maiolino",
        "email": "cem@kernel.org",
        "time": "Thu Sep 07 11:55:50 2023 +0200"
      },
      "message": "xfs: don\u0027t block in busy flushing when freeing extents\n\nSource kernel commit: 8ebbf262d4684e035af5e7aa2a71cab636673a9b\n\nIf the current transaction holds a busy extent and we are trying to\nallocate a new extent to fix up the free list, we can deadlock if\nthe AG is entirely empty except for the busy extent held by the\ntransaction.\n\nThis can occur at runtime processing an XEFI with multiple extents\nin this path:\n\n__schedule+0x22f at ffffffff81f75e8f\nschedule+0x46 at ffffffff81f76366\nxfs_extent_busy_flush+0x69 at ffffffff81477d99\nxfs_alloc_ag_vextent_size+0x16a at ffffffff8141711a\nxfs_alloc_ag_vextent+0x19b at ffffffff81417edb\nxfs_alloc_fix_freelist+0x22f at ffffffff8141896f\nxfs_free_extent_fix_freelist+0x6a at ffffffff8141939a\n__xfs_free_extent+0x99 at ffffffff81419499\nxfs_trans_free_extent+0x3e at ffffffff814a6fee\nxfs_extent_free_finish_item+0x24 at ffffffff814a70d4\nxfs_defer_finish_noroll+0x1f7 at ffffffff81441407\nxfs_defer_finish+0x11 at ffffffff814417e1\nxfs_itruncate_extents_flags+0x13d at ffffffff8148b7dd\nxfs_inactive_truncate+0xb9 at ffffffff8148bb89\nxfs_inactive+0x227 at ffffffff8148c4f7\nxfs_fs_destroy_inode+0xb8 at ffffffff81496898\ndestroy_inode+0x3b at ffffffff8127d2ab\ndo_unlinkat+0x1d1 at ffffffff81270df1\ndo_syscall_64+0x40 at ffffffff81f6b5f0\nentry_SYSCALL_64_after_hwframe+0x44 at ffffffff8200007c\n\nThis can also happen in log recovery when processing an EFI\nwith multiple extents through this path:\n\ncontext_switch() kernel/sched/core.c:3881\n__schedule() kernel/sched/core.c:5111\nschedule() kernel/sched/core.c:5186\nxfs_extent_busy_flush() fs/xfs/xfs_extent_busy.c:598\nxfs_alloc_ag_vextent_size() fs/xfs/libxfs/xfs_alloc.c:1641\nxfs_alloc_ag_vextent() fs/xfs/libxfs/xfs_alloc.c:828\nxfs_alloc_fix_freelist() fs/xfs/libxfs/xfs_alloc.c:2362\nxfs_free_extent_fix_freelist() fs/xfs/libxfs/xfs_alloc.c:3029\n__xfs_free_extent() fs/xfs/libxfs/xfs_alloc.c:3067\nxfs_trans_free_extent() fs/xfs/xfs_extfree_item.c:370\nxfs_efi_recover() fs/xfs/xfs_extfree_item.c:626\nxlog_recover_process_efi() fs/xfs/xfs_log_recover.c:4605\nxlog_recover_process_intents() fs/xfs/xfs_log_recover.c:4893\nxlog_recover_finish() fs/xfs/xfs_log_recover.c:5824\nxfs_log_mount_finish() fs/xfs/xfs_log.c:764\nxfs_mountfs() fs/xfs/xfs_mount.c:978\nxfs_fs_fill_super() fs/xfs/xfs_super.c:1908\nmount_bdev() fs/super.c:1417\nxfs_fs_mount() fs/xfs/xfs_super.c:1985\nlegacy_get_tree() fs/fs_context.c:647\nvfs_get_tree() fs/super.c:1547\ndo_new_mount() fs/namespace.c:2843\ndo_mount() fs/namespace.c:3163\nksys_mount() fs/namespace.c:3372\n__do_sys_mount() fs/namespace.c:3386\n__se_sys_mount() fs/namespace.c:3383\n__x64_sys_mount() fs/namespace.c:3383\ndo_syscall_64() arch/x86/entry/common.c:296\nentry_SYSCALL_64() arch/x86/entry/entry_64.S:180\n\nTo avoid this deadlock, we should not block in\nxfs_extent_busy_flush() if we hold a busy extent in the current\ntransaction.\n\nNow that the EFI processing code can handle requeuing a partially\ncompleted EFI, we can detect this situation in\nxfs_extent_busy_flush() and return -EAGAIN rather than going to\nsleep forever. The -EAGAIN get propagated back out to the\nxfs_trans_free_extent() context, where the EFD is populated and the\ntransaction is rolled, thereby moving the busy extents into the CIL.\n\nAt this point, we can retry the extent free operation again with a\nclean transaction. If we hit the same \"all free extents are busy\"\nsituation when trying to fix up the free list, we can safely call\nxfs_extent_busy_flush() and wait for the busy extents to resolve\nand wake us. At this point, the allocation search can make progress\nagain and we can fix up the free list.\n\nThis deadlock was first reported by Chandan in mid-2021, but I\ncouldn\u0027t make myself understood during review, and didn\u0027t have time\nto fix it myself.\n\nIt was reported again in March 2023, and again I have found myself\nunable to explain the complexities of the solution needed during\nreview.\n\nAs such, I don\u0027t have hours more time to waste trying to get the\nfix written the way it needs to be written, so I\u0027m just doing it\nmyself. This patchset is largely based on Wengang Wang\u0027s last patch,\nbut with all the unnecessary stuff removed, split up into multiple\npatches and cleaned up somewhat.\n\nReported-by: Chandan Babu R \u003cchandanrlinux@gmail.com\u003e\nReported-by: Wengang Wang \u003cwen.gang.wang@oracle.com\u003e\nSigned-off-by: Dave Chinner \u003cdchinner@redhat.com\u003e\nReviewed-by: Darrick J. Wong \u003cdjwong@kernel.org\u003e\nSigned-off-by: Darrick J. Wong \u003cdjwong@kernel.org\u003e\nSigned-off-by: Carlos Maiolino \u003ccem@kernel.org\u003e\n"
    },
    {
      "commit": "01f05365c9456a598164a7d49eabcac22500fa1f",
      "tree": "ef0011717f6ed3cc46e3abdb6a43adc2ea53bb85",
      "parents": [
        "ef16737e44b9274fddcc736ec2da5c07d5c4f703"
      ],
      "author": {
        "name": "Dave Chinner",
        "email": "dchinner@redhat.com",
        "time": "Wed Sep 06 13:33:23 2023 +0200"
      },
      "committer": {
        "name": "Carlos Maiolino",
        "email": "cem@kernel.org",
        "time": "Thu Sep 07 11:55:50 2023 +0200"
      },
      "message": "xfs: pass alloc flags through to xfs_extent_busy_flush()\n\nSource kernel commit: 6a2a9d776c4ae24a797e25eed2b9f7f33f756296\n\nTo avoid blocking in xfs_extent_busy_flush() when freeing extents\nand the only busy extents are held by the current transaction, we\nneed to pass the XFS_ALLOC_FLAG_FREEING flag context all the way\ninto xfs_extent_busy_flush().\n\nSigned-off-by: Dave Chinner \u003cdchinner@redhat.com\u003e\nReviewed-by: Darrick J. Wong \u003cdjwong@kernel.org\u003e\nSigned-off-by: Darrick J. Wong \u003cdjwong@kernel.org\u003e\nReviewed-by: Chandan Babu R \u003cchandan.babu@oracle.com\u003e\nSigned-off-by: Carlos Maiolino \u003ccem@kernel.org\u003e\n"
    },
    {
      "commit": "ef16737e44b9274fddcc736ec2da5c07d5c4f703",
      "tree": "c8bd0e35b4c7d4c2609e18d2aeae6d4e513115ec",
      "parents": [
        "d03a3c4b235c6ecdda9b27d5f31115ad710b5912"
      ],
      "author": {
        "name": "Dave Chinner",
        "email": "dchinner@redhat.com",
        "time": "Wed Sep 06 11:21:47 2023 +0200"
      },
      "committer": {
        "name": "Carlos Maiolino",
        "email": "cem@kernel.org",
        "time": "Thu Sep 07 11:55:50 2023 +0200"
      },
      "message": "xfs: use deferred frees for btree block freeing\n\nSource kernel commit: b742d7b4f0e03df25c2a772adcded35044b625ca\n\nBtrees that aren\u0027t freespace management trees use the normal extent\nallocation and freeing routines for their blocks. Hence when a btree\nblock is freed, a direct call to xfs_free_extent() is made and the\nextent is immediately freed. This puts the entire free space\nmanagement btrees under this path, so we are stacking btrees on\nbtrees in the call stack. The inobt, finobt and refcount btrees\nall do this.\n\nHowever, the bmap btree does not do this - it calls\nxfs_free_extent_later() to defer the extent free operation via an\nXEFI and hence it gets processed in deferred operation processing\nduring the commit of the primary transaction (i.e. via intent\nchaining).\n\nWe need to change xfs_free_extent() to behave in a non-blocking\nmanner so that we can avoid deadlocks with busy extents near ENOSPC\nin transactions that free multiple extents. Inserting or removing a\nrecord from a btree can cause a multi-level tree merge operation and\nthat will free multiple blocks from the btree in a single\ntransaction. i.e. we can call xfs_free_extent() multiple times, and\nhence the btree manipulation transaction is vulnerable to this busy\nextent deadlock vector.\n\nTo fix this, convert all the remaining callers of xfs_free_extent()\nto use xfs_free_extent_later() to queue XEFIs and hence defer\nprocessing of the extent frees to a context that can be safely\nrestarted if a deadlock condition is detected.\n\nSigned-off-by: Dave Chinner \u003cdchinner@redhat.com\u003e\nReviewed-by: Darrick J. Wong \u003cdjwong@kernel.org\u003e\nSigned-off-by: Darrick J. Wong \u003cdjwong@kernel.org\u003e\nReviewed-by: Chandan Babu R \u003cchandan.babu@oracle.com\u003e\nSigned-off-by: Carlos Maiolino \u003ccem@kernel.org\u003e\n"
    },
    {
      "commit": "d03a3c4b235c6ecdda9b27d5f31115ad710b5912",
      "tree": "5a99d77838b1693f91f19ead6f71f587b9dc904a",
      "parents": [
        "95957f34cea3e69089c35c27a77d81acd55e5023"
      ],
      "author": {
        "name": "Colin Ian King",
        "email": "colin.i.king@gmail.com",
        "time": "Wed Sep 06 11:20:47 2023 +0200"
      },
      "committer": {
        "name": "Carlos Maiolino",
        "email": "cem@kernel.org",
        "time": "Thu Sep 07 11:55:50 2023 +0200"
      },
      "message": "xfs: remove redundant initializations of pointers drop_leaf and save_leaf\n\nSource kernel commit: 347eb95b27eb97bebdc3ea7de23558216f4e2c90\n\nPointers drop_leaf and save_leaf are initialized with values that are never\nread, they are being re-assigned later on just before they are used. Remove\nthe redundant early initializations and keep the later assignments at the\npoint where they are used. Cleans up two clang scan build warnings:\n\nfs/xfs/libxfs/xfs_attr_leaf.c:2288:29: warning: Value stored to \u0027drop_leaf\u0027\nduring its initialization is never read [deadcode.DeadStores]\nfs/xfs/libxfs/xfs_attr_leaf.c:2289:29: warning: Value stored to \u0027save_leaf\u0027\nduring its initialization is never read [deadcode.DeadStores]\n\nSigned-off-by: Colin Ian King \u003ccolin.i.king@gmail.com\u003e\nReviewed-by: Darrick J. Wong \u003cdjwong@kernel.org\u003e\nSigned-off-by: Darrick J. Wong \u003cdjwong@kernel.org\u003e\nSigned-off-by: Carlos Maiolino \u003ccem@kernel.org\u003e\n"
    },
    {
      "commit": "95957f34cea3e69089c35c27a77d81acd55e5023",
      "tree": "27b8f012a8f3bec0b3c262ff152c7d30279e921a",
      "parents": [
        "0aac3b2b043a050c917d4b2e2124679eee650fae"
      ],
      "author": {
        "name": "Long Li",
        "email": "leo.lilong@huaweicloud.com",
        "time": "Wed Sep 06 11:19:47 2023 +0200"
      },
      "committer": {
        "name": "Carlos Maiolino",
        "email": "cem@kernel.org",
        "time": "Thu Sep 07 11:55:50 2023 +0200"
      },
      "message": "xfs: fix ag count overflow during growfs\n\nSource kernel commit: c3b880acadc95d6e019eae5d669e072afda24f1b\n\nI found a corruption during growfs:\n\nXFS (loop0): Internal error agbno \u003e\u003d mp-\u003em_sb.sb_agblocks at line 3661 of\nfile fs/xfs/libxfs/xfs_alloc.c.  Caller __xfs_free_extent+0x28e/0x3c0\nCPU: 0 PID: 573 Comm: xfs_growfs Not tainted 6.3.0-rc7-next-20230420-00001-gda8c95746257\nCall Trace:\n\u003cTASK\u003e\ndump_stack_lvl+0x50/0x70\nxfs_corruption_error+0x134/0x150\n__xfs_free_extent+0x2c1/0x3c0\nxfs_ag_extend_space+0x291/0x3e0\nxfs_growfs_data+0xd72/0xe90\nxfs_file_ioctl+0x5f9/0x14a0\n__x64_sys_ioctl+0x13e/0x1c0\ndo_syscall_64+0x39/0x80\nentry_SYSCALL_64_after_hwframe+0x63/0xcd\nXFS (loop0): Corruption detected. Unmount and run xfs_repair\nXFS (loop0): Internal error xfs_trans_cancel at line 1097 of file\nfs/xfs/xfs_trans.c.  Caller xfs_growfs_data+0x691/0xe90\nCPU: 0 PID: 573 Comm: xfs_growfs Not tainted 6.3.0-rc7-next-20230420-00001-gda8c95746257\nCall Trace:\n\u003cTASK\u003e\ndump_stack_lvl+0x50/0x70\nxfs_error_report+0x93/0xc0\nxfs_trans_cancel+0x2c0/0x350\nxfs_growfs_data+0x691/0xe90\nxfs_file_ioctl+0x5f9/0x14a0\n__x64_sys_ioctl+0x13e/0x1c0\ndo_syscall_64+0x39/0x80\nentry_SYSCALL_64_after_hwframe+0x63/0xcd\nRIP: 0033:0x7f2d86706577\n\nThe bug can be reproduced with the following sequence:\n\n# truncate -s  1073741824 xfs_test.img\n# mkfs.xfs -f -b size\u003d1024 -d agcount\u003d4 xfs_test.img\n# truncate -s 2305843009213693952  xfs_test.img\n# mount -o loop xfs_test.img /mnt/test\n# xfs_growfs -D  1125899907891200  /mnt/test\n\nThe root cause is that during growfs, user space passed in a large value\nof newblcoks to xfs_growfs_data_private(), due to current sb_agblocks is\ntoo small, new AG count will exceed UINT_MAX. Because of AG number type\nis unsigned int and it would overflow, that caused nagcount much smaller\nthan the actual value. During AG extent space, delta blocks in\nxfs_resizefs_init_new_ags() will much larger than the actual value due to\nincorrect nagcount, even exceed UINT_MAX. This will cause corruption and\nbe detected in __xfs_free_extent. Fix it by growing the filesystem to up\nto the maximally allowed AGs and not return EINVAL when new AG count\noverflow.\n\nSigned-off-by: Long Li \u003cleo.lilong@huawei.com\u003e\nReviewed-by: Darrick J. Wong \u003cdjwong@kernel.org\u003e\nSigned-off-by: Darrick J. Wong \u003cdjwong@kernel.org\u003e\nSigned-off-by: Carlos Maiolino \u003ccem@kernel.org\u003e\n"
    },
    {
      "commit": "0aac3b2b043a050c917d4b2e2124679eee650fae",
      "tree": "8568eb6cd513e004ca8ad8b0e19b4c35aa5b3b99",
      "parents": [
        "8105f53edfe4625f42477f2f7ca3339450227b8a"
      ],
      "author": {
        "name": "Kees Cook",
        "email": "keescook@chromium.org",
        "time": "Wed Sep 06 11:18:47 2023 +0200"
      },
      "committer": {
        "name": "Carlos Maiolino",
        "email": "cem@kernel.org",
        "time": "Thu Sep 07 11:55:50 2023 +0200"
      },
      "message": "overflow: Add struct_size_t() helper\n\nSource kernel commit: d67790ddf0219aa0ad3e13b53ae0a7619b3425a2\n\nWhile struct_size() is normally used in situations where the structure\ntype already has a pointer instance, there are places where no variable\nis available. In the past, this has been worked around by using a typed\nNULL first argument, but this is a bit ugly. Add a helper to do this,\nand replace the handful of instances of the code pattern with it.\n\nInstances were found with this Coccinelle script:\n\n@struct_size_t@\nidentifier STRUCT, MEMBER;\nexpression COUNT;\n@@\n\n-       struct_size((struct STRUCT *)\\(0\\|NULL\\),\n+       struct_size_t(struct STRUCT,\nMEMBER, COUNT)\n\nSuggested-by: Christoph Hellwig \u003chch@infradead.org\u003e\nCc: Jesse Brandeburg \u003cjesse.brandeburg@intel.com\u003e\nCc: Tony Nguyen \u003canthony.l.nguyen@intel.com\u003e\nCc: \"David S. Miller\" \u003cdavem@davemloft.net\u003e\nCc: Eric Dumazet \u003cedumazet@google.com\u003e\nCc: Paolo Abeni \u003cpabeni@redhat.com\u003e\nCc: James Smart \u003cjames.smart@broadcom.com\u003e\nCc: Keith Busch \u003ckbusch@kernel.org\u003e\nCc: Jens Axboe \u003caxboe@kernel.dk\u003e\nCc: Sagi Grimberg \u003csagi@grimberg.me\u003e\nCc: HighPoint Linux Team \u003clinux@highpoint-tech.com\u003e\nCc: \"James E.J. Bottomley\" \u003cjejb@linux.ibm.com\u003e\nCc: \"Martin K. Petersen\" \u003cmartin.petersen@oracle.com\u003e\nCc: Kashyap Desai \u003ckashyap.desai@broadcom.com\u003e\nCc: Sumit Saxena \u003csumit.saxena@broadcom.com\u003e\nCc: Shivasharan S \u003cshivasharan.srikanteshwara@broadcom.com\u003e\nCc: Don Brace \u003cdon.brace@microchip.com\u003e\nCc: \"Darrick J. Wong\" \u003cdjwong@kernel.org\u003e\nCc: Dave Chinner \u003cdchinner@redhat.com\u003e\nCc: Guo Xuenan \u003cguoxuenan@huawei.com\u003e\nCc: Gwan-gyeong Mun \u003cgwan-gyeong.mun@intel.com\u003e\nCc: Nick Desaulniers \u003cndesaulniers@google.com\u003e\nCc: Daniel Latypov \u003cdlatypov@google.com\u003e\nCc: kernel test robot \u003clkp@intel.com\u003e\nCc: intel-wired-lan@lists.osuosl.org\nCc: netdev@vger.kernel.org\nCc: linux-nvme@lists.infradead.org\nCc: linux-scsi@vger.kernel.org\nCc: megaraidlinux.pdl@broadcom.com\nCc: storagedev@microchip.com\nCc: linux-xfs@vger.kernel.org\nCc: linux-hardening@vger.kernel.org\nSigned-off-by: Kees Cook \u003ckeescook@chromium.org\u003e\nAcked-by: Martin K. Petersen \u003cmartin.petersen@oracle.com\u003e\nReviewed-by: Darrick J. Wong \u003cdjwong@kernel.org\u003e\nReviewed-by: Gustavo A. R. Silva \u003cgustavoars@kernel.org\u003e\nReviewed-by: Christoph Hellwig \u003chch@lst.de\u003e\nAcked-by: Jakub Kicinski \u003ckuba@kernel.org\u003e\nReviewed-by: Alexander Lobakin \u003caleksander.lobakin@intel.com\u003e\nLink: https://lore.kernel.org/r/20230522211810.never.421-kees@kernel.org\nSigned-off-by: Carlos Maiolino \u003ccem@kernel.org\u003e\n"
    },
    {
      "commit": "8105f53edfe4625f42477f2f7ca3339450227b8a",
      "tree": "a8a2ad58d56f63d8928d987cad98856115650494",
      "parents": [
        "a86308c98d33e921eb133f47faedf1d9e62f2e77"
      ],
      "author": {
        "name": "Darrick J. Wong",
        "email": "djwong@kernel.org",
        "time": "Thu Aug 24 17:00:55 2023 -0700"
      },
      "committer": {
        "name": "Carlos Maiolino",
        "email": "cem@kernel.org",
        "time": "Fri Aug 25 14:57:44 2023 +0200"
      },
      "message": "xfsprogs: don\u0027t allow udisks to automount XFS filesystems with no prompt\n\nThe unending stream of syzbot bug reports and overwrought filing of CVEs\nfor corner case handling (i.e. things that distract from actual user\ncomplaints) in XFS has generated all sorts of of overheated rhetoric\nabout how every bug is a Serious Security Issue(tm) because anyone can\ncraft a malicious filesystem on a USB stick, insert the stick into a\nvictim machine, and mount will trigger a bug in the kernel driver that\nleads to some compromise or DoS or something.\n\nI thought that nobody would be foolish enough to automount an XFS\nfilesystem.  What a fool I was!  It turns out that udisks can be told\nthat it\u0027s okay to automount things, and then GNOME will do exactly that.\nIncluding mounting mangled XFS filesystems!\n\n\u003cdelete angry rant about poor decisionmaking and armchair fs developers\nblasting us on X while not actually doing any of the work\u003e\n\nTurn off /this/ idiocy by adding a udev rule to tell udisks not to\nautomount XFS filesystems.\n\nThis will not stop a logged in user from unwittingly inserting a\nmalicious storage device and pressing [mount] and getting breached.\nThis is not a substitute for a thorough audit.  This is not a substitute\nfor lklfuse.  This does not solve the general problem of in-kernel fs\ndrivers being a huge attack surface.  I just want a vacation from the\nsh*tstorm of bad ideas and threat models that I never agreed to support.\n\nv2: Add external logs to the list too, and document the var we set\n\nSigned-off-by: Darrick J. Wong \u003cdjwong@kernel.org\u003e\nReviewed-by: Dave Chinner \u003cdchinner@redhat.com\u003e\nReviewed-by: Carlos Maiolino \u003ccmaiolino@redhat.com\u003e\n"
    },
    {
      "commit": "a86308c98d33e921eb133f47faedf1d9e62f2e77",
      "tree": "5c157bef31dd45d255e2241d957c0ad00f9ab304",
      "parents": [
        "780e93c5103d3c19d53c36ab7f4794d14912f3a5"
      ],
      "author": {
        "name": "Wu Guanghao",
        "email": "wuguanghao3@huawei.com",
        "time": "Wed Jul 26 09:43:16 2023 +0800"
      },
      "committer": {
        "name": "Carlos Maiolino",
        "email": "cem@kernel.org",
        "time": "Wed Aug 02 10:59:18 2023 +0200"
      },
      "message": "xfs_repair: fix the problem of repair failure caused by dirty flag being abnormally set on buffer\n\nWe found an issue where repair failed in the fault injection.\n\n$ xfs_repair test.img\n...\nPhase 3 - for each AG...\n        - scan and clear agi unlinked lists...\n        - process known inodes and perform inode discovery...\n        - agno \u003d 0\n        - agno \u003d 1\n        - agno \u003d 2\nMetadata CRC error detected at 0x55a30e420c7d, xfs_bmbt block 0x51d68/0x1000\n        - agno \u003d 3\nMetadata CRC error detected at 0x55a30e420c7d, xfs_bmbt block 0x51d68/0x1000\nbtree block 0/41901 is suspect, error -74\nbad magic # 0x58534c4d in inode 3306572 (data fork) bmbt block 41901\nbad data fork in inode 3306572\ncleared inode 3306572\n...\nPhase 7 - verify and correct link counts...\nMetadata corruption detected at 0x55a30e420b58, xfs_bmbt block 0x51d68/0x1000\nlibxfs_bwrite: write verifier failed on xfs_bmbt bno 0x51d68/0x8\nxfs_repair: Releasing dirty buffer to free list!\nxfs_repair: Refusing to write a corrupt buffer to the data device!\nxfs_repair: Lost a write to the data device!\n\nfatal error -- File system metadata writeout failed, err\u003d117.  Re-run xfs_repair.\n\n\n$ xfs_db test.img\nxfs_db\u003e inode 3306572\nxfs_db\u003e p\ncore.magic \u003d 0x494e\ncore.mode \u003d 0100666\t\t  // regular file\ncore.version \u003d 3\ncore.format \u003d 3 (btree)\t\n...\nu3.bmbt.keys[1] \u003d [startoff]\n1:[6]\nu3.bmbt.ptrs[1] \u003d 41901\t // btree root\n...\n\n$ hexdump -C -n 4096 41901.img\n00000000  58 53 4c 4d 00 00 00 00  00 00 01 e8 d6 f4 03 14  |XSLM............|\n00000010  09 f3 a6 1b 0a 3c 45 5a  96 39 41 ac 09 2f 66 99  |.....\u003cEZ.9A../f.|\n00000020  00 00 00 00 00 05 1f fb  00 00 00 00 00 05 1d 68  |...............h|\n...\n\nThe block data associated with inode 3306572 is abnormal, but check the CRC first\nwhen reading. If the CRC check fails, badcrc will be set. Then the dirty flag\nwill be set on bp when badcrc is set. In the final stage of repair, the dirty bp\nwill be refreshed in batches. When refresh to the disk, the data in bp will be\nverified. At this time, if the data verification fails, resulting in a repair\nerror.\n\nAfter scan_bmapbt returns an error, the inode will be cleaned up. Then bp\ndoesn\u0027t need to set dirty flag, so that it won\u0027t trigger writeback verification\nfailure.\n\nSigned-off-by: Wu Guanghao \u003cwuguanghao3@huawei.com\u003e\nReviewed-by: Darrick J. Wong \u003cdjwong@kernel.org\u003e\n"
    },
    {
      "commit": "780e93c5103d3c19d53c36ab7f4794d14912f3a5",
      "tree": "8681faa925719ddb71c48c53a359df5cee231cc3",
      "parents": [
        "bacc3981d747ee33c13023426c22bdfb72c5a04d"
      ],
      "author": {
        "name": "Bill O\u0027Donnell",
        "email": "bodonnel@redhat.com",
        "time": "Fri Jul 28 17:20:17 2023 -0500"
      },
      "committer": {
        "name": "Carlos Maiolino",
        "email": "cem@kernel.org",
        "time": "Wed Aug 02 10:58:43 2023 +0200"
      },
      "message": "mkfs.xfs.8: correction on mkfs.xfs manpage since reflink and dax are compatible\n\nMerged early in 2023: Commit 480017957d638 xfs: remove restrictions for fsdax\nand reflink. There needs to be a corresponding change to the mkfs.xfs manpage\nto remove the incompatiblity statement.\n\nSigned-off-by: Bill O\u0027Donnell \u003cbodonnel@redhat.com\u003e\nReviewed-by: Darrick J. Wong \u003cdjwong@kernel.org\u003e\nReviewed-by: Carlos Maiolino \u003ccmaiolino@redhat.com\u003e\n"
    },
    {
      "commit": "bacc3981d747ee33c13023426c22bdfb72c5a04d",
      "tree": "0cd121e2d703758067efa4bbf10a236c02032455",
      "parents": [
        "10139046b4b95c53befd409f7ea91e3c7777771e"
      ],
      "author": {
        "name": "Carlos Maiolino",
        "email": "cem@kernel.org",
        "time": "Wed Jul 19 14:01:37 2023 +0200"
      },
      "committer": {
        "name": "Carlos Maiolino",
        "email": "cem@kernel.org",
        "time": "Wed Jul 19 14:01:37 2023 +0200"
      },
      "message": "xfsprogs: Release v6.4.0\n\nUpdate all the necessary files for a 6.4.0 release.\n\nSigned-off-by: Carlos Maiolino \u003ccem@kernel.org\u003e\n"
    },
    {
      "commit": "10139046b4b95c53befd409f7ea91e3c7777771e",
      "tree": "2a022b391adab1154911219a0289b02be6f2264f",
      "parents": [
        "ad662cc1734675623a484e111fa2422a08ee45d6"
      ],
      "author": {
        "name": "Darrick J. Wong",
        "email": "djwong@kernel.org",
        "time": "Mon Jun 05 08:36:23 2023 -0700"
      },
      "committer": {
        "name": "Carlos Maiolino",
        "email": "cem@kernel.org",
        "time": "Wed Jul 12 09:15:19 2023 +0200"
      },
      "message": "xfs_db: expose the unwritten flag in rmapbt keys\n\nTeach the debugger to expose the \"unwritten\" flag in rmapbt keys so that\nwe can simulate an old filesystem writing out bad keys for testing.\n\nSigned-off-by: Darrick J. Wong \u003cdjwong@kernel.org\u003e\nReviewed-by: Carlos Maiolino \u003ccmaiolino@redhat.com\u003e\nSigned-off-by: Carlos Maiolino \u003ccem@kernel.org\u003e\n"
    },
    {
      "commit": "ad662cc1734675623a484e111fa2422a08ee45d6",
      "tree": "81aec812bb2ff5d53b63cc86e5900bfd1bcf3e7d",
      "parents": [
        "4a16ce6837ce6f41f11dc51783470d00400a85bd"
      ],
      "author": {
        "name": "Darrick J. Wong",
        "email": "djwong@kernel.org",
        "time": "Mon Jun 05 08:36:18 2023 -0700"
      },
      "committer": {
        "name": "Carlos Maiolino",
        "email": "cem@kernel.org",
        "time": "Wed Jul 12 09:15:19 2023 +0200"
      },
      "message": "xfs_repair: warn about unwritten bits set in rmap btree keys\n\nNow that we\u0027ve changed libxfs to handle the rmapbt flags correctly when\ncreating and comparing rmapbt keys, teach repair to warn about keys that\nhave the unwritten bit erroneously set.  The old broken behavior never\ncaused any problems, so we only warn once per filesystem and don\u0027t set\nthe exitcode to 1 if we\u0027re running in dry run mode.\n\nSigned-off-by: Darrick J. Wong \u003cdjwong@kernel.org\u003e\nReviewed-by: Carlos Maiolino \u003ccmaiolino@redhat.com\u003e\nSigned-off-by: Carlos Maiolino \u003ccem@kernel.org\u003e\n"
    },
    {
      "commit": "4a16ce6837ce6f41f11dc51783470d00400a85bd",
      "tree": "cadd7ce578642b72ec04328cdc1852f426bfd470",
      "parents": [
        "dafa78c9ad8ce5b7cb836b0fb16d36b63fd6be69"
      ],
      "author": {
        "name": "Darrick J. Wong",
        "email": "djwong@kernel.org",
        "time": "Mon Jun 05 08:36:12 2023 -0700"
      },
      "committer": {
        "name": "Carlos Maiolino",
        "email": "cem@kernel.org",
        "time": "Wed Jul 12 09:15:19 2023 +0200"
      },
      "message": "xfs_repair: check low keys of rmap btrees\n\nFor whatever reason, we only check the high keys in an rmapbt node\nblock.  We should be checking the low keys and the high keys, so fix\nthis gap.\n\nSigned-off-by: Darrick J. Wong \u003cdjwong@kernel.org\u003e\nReviewed-by: Carlos Maiolino \u003ccmaiolino@redhat.com\u003e\nSigned-off-by: Carlos Maiolino \u003ccem@kernel.org\u003e\n"
    },
    {
      "commit": "dafa78c9ad8ce5b7cb836b0fb16d36b63fd6be69",
      "tree": "250545b511878abe1cf42ac9d013874285603f08",
      "parents": [
        "aca02624815ca47c6fd4cafdb0aeaad641ca1915"
      ],
      "author": {
        "name": "Darrick J. Wong",
        "email": "djwong@kernel.org",
        "time": "Mon Jun 05 08:37:30 2023 -0700"
      },
      "committer": {
        "name": "Carlos Maiolino",
        "email": "cem@kernel.org",
        "time": "Wed Jul 12 09:15:18 2023 +0200"
      },
      "message": "xfs_repair: always perform extended xattr checks on uncertain inodes\n\nWhen we\u0027re processing uncertain inodes, we need to perform the extended\nchecks on the xattr structure, because the processing might decide that\nan uncertain inode is in fact a certain inode, and to restore it to the\nfilesystem.  If that\u0027s the case, xfs_repair fails to catch problems in\nthe attr structure.\n\nSigned-off-by: Darrick J. Wong \u003cdjwong@kernel.org\u003e\nReviewed-by: Pavel Reichl \u003cpreichl@redhat.com\u003e\nSigned-off-by: Carlos Maiolino \u003ccem@kernel.org\u003e\n"
    },
    {
      "commit": "aca02624815ca47c6fd4cafdb0aeaad641ca1915",
      "tree": "b8e6538a6f442fd3aaac8e8bd3b3550b9af28cec",
      "parents": [
        "1e12a0751b99efd48cda501258e16f00bef9d13d"
      ],
      "author": {
        "name": "Darrick J. Wong",
        "email": "djwong@kernel.org",
        "time": "Mon Jun 05 08:37:24 2023 -0700"
      },
      "committer": {
        "name": "Carlos Maiolino",
        "email": "cem@kernel.org",
        "time": "Wed Jul 12 09:15:18 2023 +0200"
      },
      "message": "xfs_repair: don\u0027t add junked entries to the rebuilt directory\n\nIf a directory contains multiple entries with the same name, we create\nseparate objects in the directory hashtab for each dirent.  The first\none has p-\u003ejunkit\u003d\u003d0, but the subsequent ones have p-\u003ejunkit\u003d\u003d1.\nBecause these are duplicate names that are not garbage, the first\ncharacter of p-\u003ename.name is not set to a slash.\n\nDon\u0027t add these subsequent hashtab entries to the rebuilt directory.\n\nFound by running xfs/155 with the parent pointers patchset enabled.\n\nFixes: 33165ec3b4b (\"Fix dirv2 rebuild in phase6 Merge of master-melb:xfs-cmds:26664a by kenmcd.\")\nSigned-off-by: Darrick J. Wong \u003cdjwong@kernel.org\u003e\nReviewed-by: Pavel Reichl \u003cpreichl@redhat.com\u003e\nSigned-off-by: Carlos Maiolino \u003ccem@kernel.org\u003e\n"
    },
    {
      "commit": "1e12a0751b99efd48cda501258e16f00bef9d13d",
      "tree": "fa3624f2b4d71368b4e931282ba24ac0bcbf82d3",
      "parents": [
        "beb78d7558ad8cd2eaa0e60dcb42d2de2b90be80"
      ],
      "author": {
        "name": "Darrick J. Wong",
        "email": "djwong@kernel.org",
        "time": "Mon Jun 05 08:38:01 2023 -0700"
      },
      "committer": {
        "name": "Carlos Maiolino",
        "email": "cem@kernel.org",
        "time": "Wed Jul 12 09:15:18 2023 +0200"
      },
      "message": "xfs_repair: fix messaging when fixing imap due to sparse cluster\n\nThis logic is wrong -- if we\u0027re in verbose dry-run mode, we do NOT want\nto say that we\u0027re correcting the imap.  Otherwise, we print things like:\n\nimap claims inode XXX is present, but inode cluster is sparse,\n\nBut then we can erroneously tell the user that we would correct the\nimap when in fact we /are/ correcting it.\n\nFixes: f4ff8086586 (\"xfs_repair: don\u0027t crash on partially sparse inode clusters\")\nSigned-off-by: Darrick J. Wong \u003cdjwong@kernel.org\u003e\nReviewed-by: Carlos Maiolino \u003ccmaiolino@redhat.com\u003e\nSigned-off-by: Carlos Maiolino \u003ccem@kernel.org\u003e\n"
    },
    {
      "commit": "beb78d7558ad8cd2eaa0e60dcb42d2de2b90be80",
      "tree": "6ed8b900bc3979814954826b899eed7c78739b85",
      "parents": [
        "d159552bbb05de6998388b960f50e5e0012828ea"
      ],
      "author": {
        "name": "Darrick J. Wong",
        "email": "djwong@kernel.org",
        "time": "Mon Jun 05 08:37:56 2023 -0700"
      },
      "committer": {
        "name": "Carlos Maiolino",
        "email": "cem@kernel.org",
        "time": "Wed Jul 12 09:15:18 2023 +0200"
      },
      "message": "xfs_repair: fix messaging in longform_dir2_entry_check_data\n\nAlways log when we\u0027re junking a dirent from a non-shortform directory,\nbecause we\u0027re fixing corruptions.  Even if we\u0027re in !verbose repair\nmode.  Otherwise, we print things like:\n\nentry \"FOO\" in dir inode XXX inconsistent with .. value (YYY) in ino ZZZ\n\nWithout telling the user that we\u0027re clearing the entry.\n\nFixes: 6c39a3cbda3 (\"Don\u0027t trash lost+found in phase 4 Merge of master-melb:xfs-cmds:29144a by kenmcd.\")\nSigned-off-by: Darrick J. Wong \u003cdjwong@kernel.org\u003e\nReviewed-by: Carlos Maiolino \u003ccmaiolino@redhat.com\u003e\nSigned-off-by: Carlos Maiolino \u003ccem@kernel.org\u003e\n"
    },
    {
      "commit": "d159552bbb05de6998388b960f50e5e0012828ea",
      "tree": "8d47b5544a74d789c29836f69f08fe6b9a223603",
      "parents": [
        "2618b37ae9db06aecb4db74113d0eed74202370b"
      ],
      "author": {
        "name": "Darrick J. Wong",
        "email": "djwong@kernel.org",
        "time": "Mon Jun 05 08:37:50 2023 -0700"
      },
      "committer": {
        "name": "Carlos Maiolino",
        "email": "cem@kernel.org",
        "time": "Wed Jul 12 09:15:18 2023 +0200"
      },
      "message": "xfs_repair: fix messaging when shortform_dir2_junk is called\n\nThis function is called when we\u0027ve decide to junk a shortform directory\nentry.  This is obviously corruption of some kind, so we should always\nsay something, particularly if we\u0027re in !verbose repair mode.\nOtherwise, if we\u0027re in non-verbose repair mode, we print things like:\n\nentry \"FOO\" in shortform directory XXX references non-existent inode YYY\n\nWithout telling the sysadmin that we\u0027re removing the dirent.\n\nFixes: aaca101b1ae (\"xfs_repair: add support for validating dirent ftype field\")\nSigned-off-by: Darrick J. Wong \u003cdjwong@kernel.org\u003e\nReviewed-by: Carlos Maiolino \u003ccmaiolino@redhat.com\u003e\nSigned-off-by: Carlos Maiolino \u003ccem@kernel.org\u003e\n"
    },
    {
      "commit": "2618b37ae9db06aecb4db74113d0eed74202370b",
      "tree": "64dac221940a056e3e2cc3fd7508a5ca42c88b3e",
      "parents": [
        "67f541056f4dd3ba1ccc5d11464d67afdab0f2a3"
      ],
      "author": {
        "name": "Darrick J. Wong",
        "email": "djwong@kernel.org",
        "time": "Mon Jun 05 08:37:44 2023 -0700"
      },
      "committer": {
        "name": "Carlos Maiolino",
        "email": "cem@kernel.org",
        "time": "Wed Jul 12 09:15:18 2023 +0200"
      },
      "message": "xfs_repair: don\u0027t log inode problems without printing resolution\n\nIf we\u0027re running in repair mode without the verbose flag, I see a bunch\nof stuff like this:\n\nentry \"FOO\" in directory inode XXX points to non-existent inode YYY\n\nThis output is less than helpful, since it doesn\u0027t tell us that repair\nis actually fixing the problem.  We\u0027re fixing a corruption, so we should\nalways say that we\u0027re going to fix it.\n\nFixes: 6c39a3cbda3 (\"Don\u0027t trash lost+found in phase 4 Merge of master-melb:xfs-cmds:29144a by kenmcd.\")\nSigned-off-by: Darrick J. Wong \u003cdjwong@kernel.org\u003e\nReviewed-by: Carlos Maiolino \u003ccmaiolino@redhat.com\u003e\nSigned-off-by: Carlos Maiolino \u003ccem@kernel.org\u003e\n"
    },
    {
      "commit": "67f541056f4dd3ba1ccc5d11464d67afdab0f2a3",
      "tree": "b8cfe648b3d7fc06bd4219c7526c9c04b0e982a4",
      "parents": [
        "965f91091e4442ea74132aa0c3c6795d922bda8c"
      ],
      "author": {
        "name": "Darrick J. Wong",
        "email": "djwong@kernel.org",
        "time": "Mon Jun 05 08:37:39 2023 -0700"
      },
      "committer": {
        "name": "Carlos Maiolino",
        "email": "cem@kernel.org",
        "time": "Wed Jul 12 09:15:18 2023 +0200"
      },
      "message": "xfs_repair: don\u0027t spray correcting imap all by itself\n\nIn xfs/155, I occasionally see this in the xfs_repair output:\n\ncorrecting imap\ncorrecting imap\ncorrecting imap\n...\n\nThis is completely useless, since we don\u0027t actually log which inode\nprompted this message.  This logic has been here for a really long time,\nbut ... I can\u0027t make heads nor tails of it.  If we\u0027re running in verbose\nor dry-run mode, then print the inode number, but not if we\u0027re running\nin fixit mode?\n\nA few lines later, if we\u0027re running in verbose dry-run mode, we print\n\"correcting imap\" even though we\u0027re not going to write anything.\n\nIf we get here, the inode looks like it\u0027s in use, but the inode index\nsays it isn\u0027t.  This is a corruption, so either we fix it or we say that\nwe would fix it.\n\nFixes: 6c39a3cbda3 (\"Don\u0027t trash lost+found in phase 4 Merge of master-melb:xfs-cmds:29144a by kenmcd.\")\nSigned-off-by: Darrick J. Wong \u003cdjwong@kernel.org\u003e\nReviewed-by: Carlos Maiolino \u003ccmaiolino@redhat.com\u003e\nSigned-off-by: Carlos Maiolino \u003ccem@kernel.org\u003e\n"
    },
    {
      "commit": "965f91091e4442ea74132aa0c3c6795d922bda8c",
      "tree": "f8f472ebfd218fecf649e7210356150d158ac794",
      "parents": [
        "0babf94ff560a53b92586a2fcff88380e9d39893"
      ],
      "author": {
        "name": "Pavel Reichl",
        "email": "preichl@redhat.com",
        "time": "Thu Jun 08 11:13:20 2023 +0200"
      },
      "committer": {
        "name": "Carlos Maiolino",
        "email": "cem@kernel.org",
        "time": "Wed Jul 12 09:15:18 2023 +0200"
      },
      "message": "mkfs: fix man\u0027s default value for sparse option\n\nFixes: 9cf846b51 (\"mkfs: enable sparse inodes by default\")\nSuggested-by: Lukas Herbolt \u003clukas@herbolt.com\u003e\nSigned-off-by: Pavel Reichl \u003cpreichl@redhat.com\u003e\nReviewed-by: Darrick J. Wong \u003cdjwong@kernel.org\u003e\nSigned-off-by: Carlos Maiolino \u003ccem@kernel.org\u003e\n"
    },
    {
      "commit": "0babf94ff560a53b92586a2fcff88380e9d39893",
      "tree": "ab5623f222b2b6946e437ebac25fea2d66c8b281",
      "parents": [
        "987373623e127fe476d29c81625d288d7a418f95"
      ],
      "author": {
        "name": "Weifeng Su",
        "email": "suweifeng1@huawei.com",
        "time": "Thu Jun 08 10:51:46 2023 +0800"
      },
      "committer": {
        "name": "Carlos Maiolino",
        "email": "cem@kernel.org",
        "time": "Wed Jul 12 09:15:18 2023 +0200"
      },
      "message": "libxcmd: add return value check for dynamic memory function\n\nThe result check was missed and It cause the coredump like:\n0x00005589f3e358dd in add_command (ci\u003d0x5589f3e3f020 \u003chealth_cmd\u003e) at command.c:37\n0x00005589f3e337d8 in init_commands () at init.c:37\ninit (argc\u003d\u003coptimized out\u003e, argv\u003d0x7ffecfb0cd28) at init.c:102\n0x00005589f3e33399 in main (argc\u003d\u003coptimized out\u003e, argv\u003d\u003coptimized out\u003e) at init.c:112\n\nAdd check for realloc function to ignore this coredump and exit with\nerror output\n\nSigned-off-by: Weifeng Su \u003csuweifeng1@huawei.com\u003e\nReviewed-by: Christoph Hellwig \u003chch@lst.de\u003e\nReviewed-by: Darrick J. Wong \u003cdjwong@kernel.org\u003e\nSigned-off-by: Carlos Maiolino \u003ccem@kernel.org\u003e\n"
    },
    {
      "commit": "987373623e127fe476d29c81625d288d7a418f95",
      "tree": "edf4626a0c10629cec1ad663903cef27a09a4d48",
      "parents": [
        "cd3e5d3cf6cf33cbddbac364183c1aebb1352378"
      ],
      "author": {
        "name": "David Seifert",
        "email": "soap@gentoo.org",
        "time": "Mon Jun 26 10:50:46 2023 +0100"
      },
      "committer": {
        "name": "Carlos Maiolino",
        "email": "cem@kernel.org",
        "time": "Mon Jun 26 13:51:52 2023 +0200"
      },
      "message": "po: Fix invalid .de translation format string\n\n* gettext-0.22 validates format strings now\n  https://savannah.gnu.org/bugs/index.php?64332#comment1\n\nBug: https://bugs.gentoo.org/908864\nSigned-off-by: David Seifert \u003csoap@gentoo.org\u003e\nSigned-off-by: Sam James \u003csam@gentoo.org\u003e\nReviewed-by: Carlos Maiolino \u003ccmaiolino@redhat.com\u003e\nSigned-off-by: Carlos Maiolino \u003ccem@kernel.org\u003e\n"
    },
    {
      "commit": "cd3e5d3cf6cf33cbddbac364183c1aebb1352378",
      "tree": "eb3b862a58c661744b424c4ed874877744b864c1",
      "parents": [
        "629d6b3df786a8a241b2cd72fb5885d66ea143d8"
      ],
      "author": {
        "name": "Dave Chinner",
        "email": "dchinner@redhat.com",
        "time": "Thu Jun 15 18:37:41 2023 -0700"
      },
      "committer": {
        "name": "Carlos Maiolino",
        "email": "cem@kernel.org",
        "time": "Thu Jun 22 14:07:46 2023 +0200"
      },
      "message": "xfs: validate block number being freed before adding to xefi\n\nSource kernel commit: 7dfee17b13e5024c5c0ab1911859ded4182de3e5\n\nBad things happen in defered extent freeing operations if it is\npassed a bad block number in the xefi. This can come from a bogus\nagno/agbno pair from deferred agfl freeing, or just a bad fsbno\nbeing passed to __xfs_free_extent_later(). Either way, it\u0027s very\ndifficult to diagnose where a null perag oops in EFI creation\nis coming from when the operation that queued the xefi has already\nbeen completed and there\u0027s no longer any trace of it around....\n\nSigned-off-by: Dave Chinner \u003cdchinner@redhat.com\u003e\nReviewed-by: Christoph Hellwig \u003chch@lst.de\u003e\nReviewed-by: Darrick J. Wong \u003cdjwong@kernel.org\u003e\nSigned-off-by: Dave Chinner \u003cdavid@fromorbit.com\u003e\nReviewed-by: Christoph Hellwig \u003chch@lst.de\u003e\nSigned-off-by: Carlos Maiolino \u003ccem@kernel.org\u003e\n"
    },
    {
      "commit": "629d6b3df786a8a241b2cd72fb5885d66ea143d8",
      "tree": "941ef695b27a7ab90a910a6b6f64bd6c2a6b8270",
      "parents": [
        "daa2d8205208dfafaa8dc29310f93f6c94803e24"
      ],
      "author": {
        "name": "Dave Chinner",
        "email": "dchinner@redhat.com",
        "time": "Thu Jun 15 18:37:35 2023 -0700"
      },
      "committer": {
        "name": "Carlos Maiolino",
        "email": "cem@kernel.org",
        "time": "Thu Jun 22 14:07:39 2023 +0200"
      },
      "message": "xfs: validity check agbnos on the AGFL\n\nSource kernel commit: 3148ebf2c0782340946732bfaf3073d23ac833fa\n\nIf the agfl or the indexing in the AGF has been corrupted, getting a\nblock form the AGFL could return an invalid block number. If this\nhappens, bad things happen. Check the agbno we pull off the AGFL\nand return -EFSCORRUPTED if we find somethign bad.\n\nSigned-off-by: Dave Chinner \u003cdchinner@redhat.com\u003e\nReviewed-by: Christoph Hellwig \u003chch@lst.de\u003e\nReviewed-by: Darrick J. Wong \u003cdjwong@kernel.org\u003e\nSigned-off-by: Dave Chinner \u003cdavid@fromorbit.com\u003e\nReviewed-by: Christoph Hellwig \u003chch@lst.de\u003e\nSigned-off-by: Carlos Maiolino \u003ccem@kernel.org\u003e\n"
    },
    {
      "commit": "daa2d8205208dfafaa8dc29310f93f6c94803e24",
      "tree": "abebce29fd747f71411852fefb9967a4dca62796",
      "parents": [
        "a565e345614b6b2839fd1088dacf5957309752e2"
      ],
      "author": {
        "name": "Dave Chinner",
        "email": "dchinner@redhat.com",
        "time": "Thu Jun 15 18:37:30 2023 -0700"
      },
      "committer": {
        "name": "Carlos Maiolino",
        "email": "cem@kernel.org",
        "time": "Thu Jun 22 14:07:32 2023 +0200"
      },
      "message": "xfs: fix agf/agfl verification on v4 filesystems\n\nSource kernel commit: e0a8de7da35e5b22b44fa1013ccc0716e17b0c14\n\nWhen a v4 filesystem has fl_last - fl_first !\u003d fl_count, we do not\nnot detect the corruption and allow the AGF to be used as it if was\nfully valid. On V5 filesystems, we reset the AGFL to empty in these\ncases and avoid the corruption at a small cost of leaked blocks.\n\nIf we don\u0027t catch the corruption on V4 filesystems, bad things\nhappen later when an allocation attempts to trim the free list\nand either double-frees stale entries in the AGFl or tries to free\nNULLAGBNO entries.\n\nEither way, this is bad. Prevent this from happening by using the\nAGFL_NEED_RESET logic for v4 filesysetms, too.\n\nSigned-off-by: Dave Chinner \u003cdchinner@redhat.com\u003e\nReviewed-by: Christoph Hellwig \u003chch@lst.de\u003e\nReviewed-by: Darrick J. Wong \u003cdjwong@kernel.org\u003e\nSigned-off-by: Dave Chinner \u003cdavid@fromorbit.com\u003e\nReviewed-by: Christoph Hellwig \u003chch@lst.de\u003e\nSigned-off-by: Carlos Maiolino \u003ccem@kernel.org\u003e\n"
    },
    {
      "commit": "a565e345614b6b2839fd1088dacf5957309752e2",
      "tree": "046c570da8a1b6efd76e6e0d689f4f27a78dd098",
      "parents": [
        "8b2a40fffad68e881398f17dabd2801d8b20fcd0"
      ],
      "author": {
        "name": "Dave Chinner",
        "email": "dchinner@redhat.com",
        "time": "Thu Jun 15 18:37:24 2023 -0700"
      },
      "committer": {
        "name": "Carlos Maiolino",
        "email": "cem@kernel.org",
        "time": "Thu Jun 22 14:07:25 2023 +0200"
      },
      "message": "xfs: fix AGF vs inode cluster buffer deadlock\n\nSource kernel commit: 82842fee6e5979ca7e2bf4d839ef890c22ffb7aa\n\nLock order in XFS is AGI -\u003e AGF, hence for operations involving\ninode unlinked list operations we always lock the AGI first. Inode\nunlinked list operations operate on the inode cluster buffer,\nso the lock order there is AGI -\u003e inode cluster buffer.\n\nFor O_TMPFILE operations, this now means the lock order set down in\nxfs_rename and xfs_link is AGI -\u003e inode cluster buffer -\u003e AGF as the\nunlinked ops are done before the directory modifications that may\nallocate space and lock the AGF.\n\nUnfortunately, we also now lock the inode cluster buffer when\nlogging an inode so that we can attach the inode to the cluster\nbuffer and pin it in memory. This creates a lock order of AGF -\u003e\ninode cluster buffer in directory operations as we have to log the\ninode after we\u0027ve allocated new space for it.\n\nThis creates a lock inversion between the AGF and the inode cluster\nbuffer. Because the inode cluster buffer is shared across multiple\ninodes, the inversion is not specific to individual inodes but can\noccur when inodes in the same cluster buffer are accessed in\ndifferent orders.\n\nTo fix this we need move all the inode log item cluster buffer\ninteractions to the end of the current transaction. Unfortunately,\nxfs_trans_log_inode() calls are littered throughout the transactions\nwith no thought to ordering against other items or locking. This\nmakes it difficult to do anything that involves changing the call\nsites of xfs_trans_log_inode() to change locking orders.\n\nHowever, we do now have a mechanism that allows is to postpone dirty\nitem processing to just before we commit the transaction: the\n-\u003eiop_precommit method. This will be called after all the\nmodifications are done and high level objects like AGI and AGF\nbuffers have been locked and modified, thereby providing a mechanism\nthat guarantees we don\u0027t lock the inode cluster buffer before those\nhigh level objects are locked.\n\nThis change is largely moving the guts of xfs_trans_log_inode() to\nxfs_inode_item_precommit() and providing an extra flag context in\nthe inode log item to track the dirty state of the inode in the\ncurrent transaction. This also means we do a lot less repeated work\nin xfs_trans_log_inode() by only doing it once per transaction when\nall the work is done.\n\nFixes: 298f7bec503f (\"xfs: pin inode backing buffer to the inode log item\")\nSigned-off-by: Dave Chinner \u003cdchinner@redhat.com\u003e\nReviewed-by: Christoph Hellwig \u003chch@lst.de\u003e\nReviewed-by: Darrick J. Wong \u003cdjwong@kernel.org\u003e\nSigned-off-by: Dave Chinner \u003cdavid@fromorbit.com\u003e\nReviewed-by: Christoph Hellwig \u003chch@lst.de\u003e\nSigned-off-by: Carlos Maiolino \u003ccem@kernel.org\u003e\n"
    },
    {
      "commit": "8b2a40fffad68e881398f17dabd2801d8b20fcd0",
      "tree": "750501fb92379e958b9a14e4de3eb0add74d35af",
      "parents": [
        "05a3a3895651153c3123fc28c1f8fd30a9ca9685"
      ],
      "author": {
        "name": "Dave Chinner",
        "email": "dchinner@redhat.com",
        "time": "Thu Jun 15 18:37:18 2023 -0700"
      },
      "committer": {
        "name": "Carlos Maiolino",
        "email": "cem@kernel.org",
        "time": "Thu Jun 22 14:07:14 2023 +0200"
      },
      "message": "xfs: restore allocation trylock iteration\n\nSource kernel commit: 00dcd17cfa7f103f7d640ffd34645a2ddab96330\n\nIt was accidentally dropped when refactoring the allocation code,\nresulting in the AG iteration always doing blocking AG iteration.\nThis results in a small performance regression for a specific fsmark\ntest that runs more user data writer threads than there are AGs.\n\nReported-by: kernel test robot \u003coliver.sang@intel.com\u003e\nFixes: 2edf06a50f5b (\"xfs: factor xfs_alloc_vextent_this_ag() for _iterate_ags()\")\nSigned-off-by: Dave Chinner \u003cdchinner@redhat.com\u003e\nReviewed-by: Darrick J. Wong \u003cdjwong@kernel.org\u003e\nReviewed-by: Christoph Hellwig \u003chch@lst.de\u003e\nSigned-off-by: Dave Chinner \u003cdavid@fromorbit.com\u003e\nReviewed-by: Christoph Hellwig \u003chch@lst.de\u003e\nSigned-off-by: Carlos Maiolino \u003ccem@kernel.org\u003e\n"
    },
    {
      "commit": "05a3a3895651153c3123fc28c1f8fd30a9ca9685",
      "tree": "b56020ec66f034569178c44c634ee2ade47ec687",
      "parents": [
        "c6b593ee4398b747856a1d9d0a2436b34d0d447a"
      ],
      "author": {
        "name": "Darrick J. Wong",
        "email": "djwong@kernel.org",
        "time": "Thu Jun 15 18:37:12 2023 -0700"
      },
      "committer": {
        "name": "Carlos Maiolino",
        "email": "cem@kernel.org",
        "time": "Thu Jun 22 14:07:09 2023 +0200"
      },
      "message": "libxfs: port transaction precommit hooks to userspace\n\nSigned-off-by: Darrick J. Wong \u003cdjwong@kernel.org\u003e\nReviewed-by: Christoph Hellwig \u003chch@lst.de\u003e\nSigned-off-by: Carlos Maiolino \u003ccem@kernel.org\u003e\n"
    },
    {
      "commit": "c6b593ee4398b747856a1d9d0a2436b34d0d447a",
      "tree": "f65e949e8553d0dadd3719dd87706a0fb5b01180",
      "parents": [
        "4d3226b6ec5af8a114280ac9c745c29235928f13"
      ],
      "author": {
        "name": "Darrick J. Wong",
        "email": "djwong@kernel.org",
        "time": "Thu Jun 15 18:37:07 2023 -0700"
      },
      "committer": {
        "name": "Carlos Maiolino",
        "email": "cem@kernel.org",
        "time": "Thu Jun 22 14:07:03 2023 +0200"
      },
      "message": "libxfs: port list_cmp_func_t to userspace\n\nSynchronize our list_sort ABI to match the kernel\u0027s.  This will make it\neasier to port the log item precommit sorting code to userspace as-is in\nthe next patch.\n\nSigned-off-by: Darrick J. Wong \u003cdjwong@kernel.org\u003e\nReviewed-by: Christoph Hellwig \u003chch@lst.de\u003e\nSigned-off-by: Carlos Maiolino \u003ccem@kernel.org\u003e\n"
    },
    {
      "commit": "4d3226b6ec5af8a114280ac9c745c29235928f13",
      "tree": "b3961c4d98f5333711bde25b4fd12ecce42447a7",
      "parents": [
        "47560612f1213c2159bb4bbe4244df4ffef4d1e0"
      ],
      "author": {
        "name": "Darrick J. Wong",
        "email": "djwong@kernel.org",
        "time": "Thu Jun 15 18:37:01 2023 -0700"
      },
      "committer": {
        "name": "Carlos Maiolino",
        "email": "cem@kernel.org",
        "time": "Thu Jun 22 14:06:39 2023 +0200"
      },
      "message": "libxfs: deferred items should call xfs_perag_intent_{get,put}\n\nMake the intent item _get_group and _put_group functions call\nxfs_perag_intent_{get,put} to match the kernel.  In userspace they\u0027re\nthe same thing so this makes no difference.  However, let\u0027s not leave\nunnecessary discrepancies.\n\nFixes: 7cb26322f74 (\"xfs: allow queued AG intents to drain before scrubbing\")\nSigned-off-by: Darrick J. Wong \u003cdjwong@kernel.org\u003e\nReviewed-by: Christoph Hellwig \u003chch@lst.de\u003e\nSigned-off-by: Carlos Maiolino \u003ccem@kernel.org\u003e\n"
    },
    {
      "commit": "47560612f1213c2159bb4bbe4244df4ffef4d1e0",
      "tree": "83ea5be6e32798c306a25ce08a9fe5ddd864f1e8",
      "parents": [
        "c51c8c857999615a23c27a038099070ab2fab7ea"
      ],
      "author": {
        "name": "Darrick J. Wong",
        "email": "djwong@kernel.org",
        "time": "Mon Jun 05 08:37:15 2023 -0700"
      },
      "committer": {
        "name": "Carlos Maiolino",
        "email": "cem@kernel.org",
        "time": "Thu Jun 22 14:04:28 2023 +0200"
      },
      "message": "xfs_db: make the hash command print the dirent hash\n\nIt turns out that the da and dir2 hashname functions are /not/ the same,\nat least not on ascii-ci filesystems.  Enhance this debugger command to\nsupport printing the dir2 hashname.\n\nSigned-off-by: Darrick J. Wong \u003cdjwong@kernel.org\u003e\nReviewed-by: Carlos Maiolino \u003ccmaiolino@redhat.com\u003e\nReviewed-by: Andrey Albershteyn \u003caalbersh@redhat.com\u003e\nSigned-off-by: Carlos Maiolino \u003ccem@kernel.org\u003e\n"
    },
    {
      "commit": "c51c8c857999615a23c27a038099070ab2fab7ea",
      "tree": "c8b9836eee49e9cca39d1d99e8dc7d1b3d60550e",
      "parents": [
        "2b686ab313478f3714bb5be73b636abd01453131"
      ],
      "author": {
        "name": "Darrick J. Wong",
        "email": "djwong@kernel.org",
        "time": "Mon Jun 05 08:37:09 2023 -0700"
      },
      "committer": {
        "name": "Carlos Maiolino",
        "email": "cem@kernel.org",
        "time": "Thu Jun 22 14:04:28 2023 +0200"
      },
      "message": "xfs_db: create dirents and xattrs with colliding names\n\nCreate a new debugger command that will create dirent and xattr names\nthat induce dahash collisions.\n\nSigned-off-by: Darrick J. Wong \u003cdjwong@kernel.org\u003e\nReviewed-by: Carlos Maiolino \u003ccmaiolino@redhat.com\u003e\nReviewed-by: Andrey Albershteyn \u003caalbersh@redhat.com\u003e\nSigned-off-by: Carlos Maiolino \u003ccem@kernel.org\u003e\n"
    },
    {
      "commit": "2b686ab313478f3714bb5be73b636abd01453131",
      "tree": "2aa95d95ba43392dc095a7aeb6ab3b4b5044c78e",
      "parents": [
        "6a5285ec1763e0ee0e04d8c135ac995d96fbe34e"
      ],
      "author": {
        "name": "Darrick J. Wong",
        "email": "djwong@kernel.org",
        "time": "Thu Jun 15 09:12:06 2023 -0700"
      },
      "committer": {
        "name": "Carlos Maiolino",
        "email": "cem@kernel.org",
        "time": "Thu Jun 22 14:04:11 2023 +0200"
      },
      "message": "xfs_db: hoist name obfuscation code out of metadump.c\n\nWe want to create a debugger command that will create obfuscated names\nfor directory and xattr names, so hoist the name obfuscation code into a\nseparate file.\n\nSigned-off-by: Darrick J. Wong \u003cdjwong@kernel.org\u003e\nReviewed-by: Carlos Maiolino \u003ccmaiolino@redhat.com\u003e\nSigned-off-by: Carlos Maiolino \u003ccem@kernel.org\u003e\n"
    },
    {
      "commit": "6a5285ec1763e0ee0e04d8c135ac995d96fbe34e",
      "tree": "11ff92ce5e87b5c38be7e6f485ded3b597a76161",
      "parents": [
        "5309ddc05796df78c8cd96c27232b2b3b1b1fc6a"
      ],
      "author": {
        "name": "Darrick J. Wong",
        "email": "djwong@kernel.org",
        "time": "Mon Jun 05 08:36:55 2023 -0700"
      },
      "committer": {
        "name": "Carlos Maiolino",
        "email": "cem@kernel.org",
        "time": "Thu Jun 22 14:02:33 2023 +0200"
      },
      "message": "mkfs: deprecate the ascii-ci feature\n\nDeprecate this feature, since the feature is broken.\n\nSigned-off-by: Darrick J. Wong \u003cdjwong@kernel.org\u003e\nReviewed-by: Christoph Hellwig \u003chch@lst.de\u003e\nSigned-off-by: Carlos Maiolino \u003ccem@kernel.org\u003e\n"
    },
    {
      "commit": "5309ddc05796df78c8cd96c27232b2b3b1b1fc6a",
      "tree": "436fe78544054da74558e84d64105e584f5d4965",
      "parents": [
        "10a01bcdd748773c185255516a72e75a71295bd4"
      ],
      "author": {
        "name": "Darrick J. Wong",
        "email": "djwong@kernel.org",
        "time": "Mon Jun 05 08:36:49 2023 -0700"
      },
      "committer": {
        "name": "Carlos Maiolino",
        "email": "cem@kernel.org",
        "time": "Thu Jun 22 14:02:33 2023 +0200"
      },
      "message": "mkfs.xfs.8: warn about the version\u003dci feature\n\nDocument the exact byte transformations that happen during directory\nname lookup when the version\u003dci feature is enabled.  Warn that this is\nnot generally compatible, and that people should not use this feature.\n\nSigned-off-by: Darrick J. Wong \u003cdjwong@kernel.org\u003e\nReviewed-by: Christoph Hellwig \u003chch@lst.de\u003e\nSigned-off-by: Carlos Maiolino \u003ccem@kernel.org\u003e\n"
    },
    {
      "commit": "10a01bcdd748773c185255516a72e75a71295bd4",
      "tree": "00dbd5038c4828cef66bb0b03397bc043ea61907",
      "parents": [
        "cb8c70b017e30d4004373300bce488a9687166ac"
      ],
      "author": {
        "name": "Darrick J. Wong",
        "email": "djwong@kernel.org",
        "time": "Thu Jun 15 09:11:04 2023 -0700"
      },
      "committer": {
        "name": "Carlos Maiolino",
        "email": "cem@kernel.org",
        "time": "Thu Jun 22 14:02:02 2023 +0200"
      },
      "message": "xfs_db: fix metadump name obfuscation for ascii-ci filesystems\n\nNow that we\u0027ve stabilized the dirent hash function for ascii-ci\nfilesystems, adapt the metadump name obfuscation code to detect when\nit\u0027s obfuscating a directory entry name on an ascii-ci filesystem and\nspit out names that actually have the same hash.\n\nSigned-off-by: Darrick J. Wong \u003cdjwong@kernel.org\u003e\nReviewed-by: Eric Sandeen \u003csandeen@redhat.com\u003e\nReviewed-by: Carlos Maiolino \u003ccmaiolino@redhat.com\u003e\nSigned-off-by: Carlos Maiolino \u003ccem@kernel.org\u003e\n"
    },
    {
      "commit": "cb8c70b017e30d4004373300bce488a9687166ac",
      "tree": "fdb457aa0e0d63edd1b674d75fecc2621fabea0c",
      "parents": [
        "03f97ae49b9cbeae21d14deabfa88c877d1cfeb8"
      ],
      "author": {
        "name": "Darrick J. Wong",
        "email": "djwong@kernel.org",
        "time": "Mon Jun 05 08:36:38 2023 -0700"
      },
      "committer": {
        "name": "Carlos Maiolino",
        "email": "cem@kernel.org",
        "time": "Wed Jun 14 10:35:07 2023 +0200"
      },
      "message": "xfs_db: move obfuscate_name assertion to callers\n\nCurrently, obfuscate_name asserts that the hash of the new name is the\nsame as the old name.  To enable bug fixes in the next patch, move this\nassertion to the callers.\n\nSigned-off-by: Darrick J. Wong \u003cdjwong@kernel.org\u003e\nReviewed-by: Christoph Hellwig \u003chch@lst.de\u003e\nSigned-off-by: Carlos Maiolino \u003ccem@kernel.org\u003e\n"
    },
    {
      "commit": "03f97ae49b9cbeae21d14deabfa88c877d1cfeb8",
      "tree": "f59475ba960b6f8464d66efbedaf0d3bdface0da",
      "parents": [
        "7901c8c1a501de87c42bb1ed83456f99462538c6"
      ],
      "author": {
        "name": "Darrick J. Wong",
        "email": "djwong@kernel.org",
        "time": "Mon Jun 05 08:36:32 2023 -0700"
      },
      "committer": {
        "name": "Carlos Maiolino",
        "email": "cem@kernel.org",
        "time": "Wed Jun 14 10:35:07 2023 +0200"
      },
      "message": "libxfs: test the ascii case-insensitive hash\n\nNow that we\u0027ve made kernel and userspace use the same tolower code for\ncomputing directory index hashes, add that to the selftest code.\n\nSigned-off-by: Darrick J. Wong \u003cdjwong@kernel.org\u003e\nReviewed-by: Eric Sandeen \u003csandeen@redhat.com\u003e\nReviewed-by: Carlos Maiolino \u003ccmaiolino@redhat.com\u003e\nSigned-off-by: Carlos Maiolino \u003ccem@kernel.org\u003e\n"
    },
    {
      "commit": "7901c8c1a501de87c42bb1ed83456f99462538c6",
      "tree": "14b0caeb168a0987980113d9e940dced9baf6836",
      "parents": [
        "2897a1c2fe39e2f72763eb9a501ec46d64f9f1ec"
      ],
      "author": {
        "name": "Darrick J. Wong",
        "email": "djwong@kernel.org",
        "time": "Thu Jun 01 11:41:10 2023 +0200"
      },
      "committer": {
        "name": "Carlos Maiolino",
        "email": "cem@kernel.org",
        "time": "Fri Jun 09 10:27:51 2023 +0200"
      },
      "message": "xfs: set bnobt/cntbt numrecs correctly when formatting new AGs\n\nSource kernel commit: 8e698ee72c4ecbbf18264568eb310875839fd601\n\nThrough generic/300, I discovered that mkfs.xfs creates corrupt\nfilesystems when given these parameters:\n\n# mkfs.xfs -d size\u003d512M /dev/sda -f -d su\u003d128k,sw\u003d4 --unsupported\nFilesystems formatted with --unsupported are not supported!!\nmeta-data\u003d/dev/sda               isize\u003d512    agcount\u003d8, agsize\u003d16352 blks\n\u003d                       sectsz\u003d512   attr\u003d2, projid32bit\u003d1\n\u003d                       crc\u003d1        finobt\u003d1, sparse\u003d1, rmapbt\u003d1\n\u003d                       reflink\u003d1    bigtime\u003d1 inobtcount\u003d1 nrext64\u003d1\ndata     \u003d                       bsize\u003d4096   blocks\u003d130816, imaxpct\u003d25\n\u003d                       sunit\u003d32     swidth\u003d128 blks\nnaming   \u003dversion 2              bsize\u003d4096   ascii-ci\u003d0, ftype\u003d1\nlog      \u003dinternal log           bsize\u003d4096   blocks\u003d8192, version\u003d2\n\u003d                       sectsz\u003d512   sunit\u003d32 blks, lazy-count\u003d1\nrealtime \u003dnone                   extsz\u003d4096   blocks\u003d0, rtextents\u003d0\n\u003d                       rgcount\u003d0    rgsize\u003d0 blks\nDiscarding blocks...Done.\n# xfs_repair -n /dev/sda\nPhase 1 - find and verify superblock...\n- reporting progress in intervals of 15 minutes\nPhase 2 - using internal log\n- zero log...\n- 16:30:50: zeroing log - 16320 of 16320 blocks done\n- scan filesystem freespace and inode maps...\nagf_freeblks 25, counted 0 in ag 4\nsb_fdblocks 8823, counted 8798\n\nThe root cause of this problem is the numrecs handling in\nxfs_freesp_init_recs, which is used to initialize a new AG.  Prior to\ncalling the function, we set up the new bnobt block with numrecs \u003d\u003d 1\nand rely on _freesp_init_recs to format that new record.  If the last\nrecord created has a blockcount of zero, then it sets numrecs \u003d 0.\n\nThat last bit isn\u0027t correct if the AG contains the log, the start of the\nlog is not immediately after the initial blocks due to stripe alignment,\nand the end of the log is perfectly aligned with the end of the AG.  For\nthis case, we actually formatted a single bnobt record to handle the\nfree space before the start of the (stripe aligned) log, and incremented\narec to try to format a second record.  That second record turned out to\nbe unnecessary, so what we really want is to leave numrecs at 1.\n\nThe numrecs handling itself is overly complicated because a different\nfunction sets numrecs \u003d\u003d 1.  Change the bnobt creation code to start\nwith numrecs set to zero and only increment it after successfully\nformatting a free space extent into the btree block.\n\nFixes: f327a00745ff (\"xfs: account for log space when formatting new AGs\")\nSigned-off-by: Darrick J. Wong \u003cdjwong@kernel.org\u003e\nReviewed-by: Dave Chinner \u003cdchinner@redhat.com\u003e\nSigned-off-by: Dave Chinner \u003cdavid@fromorbit.com\u003e\nSigned-off-by: Carlos Maiolino \u003ccem@kernel.org\u003e\n"
    },
    {
      "commit": "2897a1c2fe39e2f72763eb9a501ec46d64f9f1ec",
      "tree": "ef98cb62fd8d9c5c919330e45ed245f0312dd959",
      "parents": [
        "87ab47e1fa33caa7d70fc9a26424e3e7adf6e3fc"
      ],
      "author": {
        "name": "Darrick J. Wong",
        "email": "djwong@kernel.org",
        "time": "Thu Jun 01 11:40:10 2023 +0200"
      },
      "committer": {
        "name": "Carlos Maiolino",
        "email": "cem@kernel.org",
        "time": "Fri Jun 09 10:27:51 2023 +0200"
      },
      "message": "xfs: don\u0027t unconditionally null args-\u003epag in xfs_bmap_btalloc_at_eof\n\nSource kernel commit: b82a5c42a5fa7e79426ed047ced3f8482bb66fbc\n\nxfs/170 on a filesystem with su\u003d128k,sw\u003d4 produces this splat:\n\nBUG: kernel NULL pointer dereference, address: 0000000000000010\n#PF: supervisor write access in kernel mode\n#PF: error_code(0x0002) - not-present page\nPGD 0 P4D 0\nOops: 0002 [#1] PREEMPT SMP\nCPU: 1 PID: 4022907 Comm: dd Tainted: G        W          6.3.0-xfsx #2 6ebeeffbe9577d32\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ?-20171121_152543-x86-ol7-bu\nRIP: 0010:xfs_perag_rele+0x10/0x70 [xfs]\nRSP: 0018:ffffc90001e43858 EFLAGS: 00010217\nRAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000100\nRDX: ffffffffa054e717 RSI: 0000000000000005 RDI: 0000000000000000\nRBP: ffff888194eea000 R08: 0000000000000000 R09: 0000000000000037\nR10: ffff888100ac1cb0 R11: 0000000000000018 R12: 0000000000000000\nR13: ffffc90001e43a38 R14: ffff888194eea000 R15: ffff888194eea000\nFS:  00007f93d1a0e740(0000) GS:ffff88843fc80000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000000000000010 CR3: 000000018a34f000 CR4: 00000000003506e0\nCall Trace:\n\u003cTASK\u003e\nxfs_bmap_btalloc+0x1a7/0x5d0 [xfs f85291d6841cbb3dc740083f1f331c0327394518]\nxfs_bmapi_allocate+0xee/0x470 [xfs f85291d6841cbb3dc740083f1f331c0327394518]\nxfs_bmapi_write+0x539/0x9e0 [xfs f85291d6841cbb3dc740083f1f331c0327394518]\nxfs_iomap_write_direct+0x1bb/0x2b0 [xfs f85291d6841cbb3dc740083f1f331c0327394518]\nxfs_direct_write_iomap_begin+0x51c/0x710 [xfs f85291d6841cbb3dc740083f1f331c0327394518]\niomap_iter+0x132/0x2f0\n__iomap_dio_rw+0x2f8/0x840\niomap_dio_rw+0xe/0x30\nxfs_file_dio_write_aligned+0xad/0x180 [xfs f85291d6841cbb3dc740083f1f331c0327394518]\nxfs_file_write_iter+0xfb/0x190 [xfs f85291d6841cbb3dc740083f1f331c0327394518]\nvfs_write+0x2eb/0x410\nksys_write+0x65/0xe0\ndo_syscall_64+0x2b/0x80\n\nThis crash occurs under the \"out_low_space\" label.  We grabbed a perag\nreference, passed it via args-\u003epag into xfs_bmap_btalloc_at_eof, and\nafterwards args-\u003epag is NULL.  Fix the second function not to clobber\nargs-\u003epag if the caller had passed one in.\n\nFixes: 85843327094f (\"xfs: factor xfs_bmap_btalloc()\")\nSigned-off-by: Darrick J. Wong \u003cdjwong@kernel.org\u003e\nReviewed-by: Dave Chinner \u003cdchinner@redhat.com\u003e\nSigned-off-by: Dave Chinner \u003cdavid@fromorbit.com\u003e\nSigned-off-by: Carlos Maiolino \u003ccem@kernel.org\u003e\n"
    },
    {
      "commit": "87ab47e1fa33caa7d70fc9a26424e3e7adf6e3fc",
      "tree": "5a60eab54299764b48b5ea15725852302b215dca",
      "parents": [
        "0bf7f8c31f7d065819dabdf7eb9e14b158b85b75"
      ],
      "author": {
        "name": "Dave Chinner",
        "email": "dchinner@redhat.com",
        "time": "Thu Jun 01 11:39:10 2023 +0200"
      },
      "committer": {
        "name": "Carlos Maiolino",
        "email": "cem@kernel.org",
        "time": "Fri Jun 09 10:27:51 2023 +0200"
      },
      "message": "xfs: fix livelock in delayed allocation at ENOSPC\n\nSource kernel commit: 9419092fb2630c30e4ffeb9ef61007ef0c61827a\n\nOn a filesystem with a non-zero stripe unit and a large sequential\nwrite, delayed allocation will set a minimum allocation length of\nthe stripe unit. If allocation fails because there are no extents\nlong enough for an aligned minlen allocation, it is supposed to\nfall back to unaligned allocation which allows single block extents\nto be allocated.\n\nWhen the allocator code was rewritting in the 6.3 cycle, this\nfallback was broken - the old code used args-\u003efsbno as the both the\nallocation target and the allocation result, the new code passes the\ntarget as a separate parameter. The conversion didn\u0027t handle the\naligned-\u003eunaligned fallback path correctly - it reset args-\u003efsbno to\nthe target fsbno on failure which broke allocation failure detection\nin the high level code and so it never fell back to unaligned\nallocations.\n\nThis resulted in a loop in writeback trying to allocate an aligned\nblock, getting a false positive success, trying to insert the result\nin the BMBT. This did nothing because the extent already was in the\nBMBT (merge results in an unchanged extent) and so it returned the\nprior extent to the conversion code as the current iomap.\n\nBecause the iomap returned didn\u0027t cover the offset we tried to map,\nxfs_convert_blocks() then retries the allocation, which fails in the\nsame way and now we have a livelock.\n\nReported-and-tested-by: Brian Foster \u003cbfoster@redhat.com\u003e\nFixes: 85843327094f (\"xfs: factor xfs_bmap_btalloc()\")\nSigned-off-by: Dave Chinner \u003cdchinner@redhat.com\u003e\nReviewed-by: Darrick J. Wong \u003cdjwong@kernel.org\u003e\nSigned-off-by: Carlos Maiolino \u003ccem@kernel.org\u003e\n"
    },
    {
      "commit": "0bf7f8c31f7d065819dabdf7eb9e14b158b85b75",
      "tree": "d355ce4444b7fc67cb5eba9a2d239eb9fbc6416c",
      "parents": [
        "44b2e0dea3c4707902f76955c2625436258dfffb"
      ],
      "author": {
        "name": "Darrick J. Wong",
        "email": "djwong@kernel.org",
        "time": "Thu Jun 01 11:38:10 2023 +0200"
      },
      "committer": {
        "name": "Carlos Maiolino",
        "email": "cem@kernel.org",
        "time": "Fri Jun 09 10:27:50 2023 +0200"
      },
      "message": "xfs: _{attr,data}_map_shared should take ILOCK_EXCL until iread_extents is completely done\n\nSource kernel commit: c95356ca884885db702670e24933ee7f2b9f1754\n\nWhile fuzzing the data fork extent count on a btree-format directory\nwith xfs/375, I observed the following (excerpted) splat:\n\nXFS: Assertion failed: xfs_isilocked(ip, XFS_ILOCK_EXCL), file: fs/xfs/libxfs/xfs_bmap.c, line: 1208\n------------[ cut here ]------------\nWARNING: CPU: 0 PID: 43192 at fs/xfs/xfs_message.c:104 assfail+0x46/0x4a [xfs]\nCall Trace:\n\u003cTASK\u003e\nxfs_iread_extents+0x1af/0x210 [xfs 09f66509ece4938760fac7de64732a0cbd3e39cd]\nxchk_dir_walk+0xb8/0x190 [xfs 09f66509ece4938760fac7de64732a0cbd3e39cd]\nxchk_parent_count_parent_dentries+0x41/0x80 [xfs 09f66509ece4938760fac7de64732a0cbd3e39cd]\nxchk_parent_validate+0x199/0x2e0 [xfs 09f66509ece4938760fac7de64732a0cbd3e39cd]\nxchk_parent+0xdf/0x130 [xfs 09f66509ece4938760fac7de64732a0cbd3e39cd]\nxfs_scrub_metadata+0x2b8/0x730 [xfs 09f66509ece4938760fac7de64732a0cbd3e39cd]\nxfs_scrubv_metadata+0x38b/0x4d0 [xfs 09f66509ece4938760fac7de64732a0cbd3e39cd]\nxfs_ioc_scrubv_metadata+0x111/0x160 [xfs 09f66509ece4938760fac7de64732a0cbd3e39cd]\nxfs_file_ioctl+0x367/0xf50 [xfs 09f66509ece4938760fac7de64732a0cbd3e39cd]\n__x64_sys_ioctl+0x82/0xa0\ndo_syscall_64+0x2b/0x80\nentry_SYSCALL_64_after_hwframe+0x46/0xb0\n\nThe cause of this is a race condition in xfs_ilock_data_map_shared,\nwhich performs an unlocked access to the data fork to guess which lock\nmode it needs:\n\nThread 0                          Thread 1\n\nxfs_need_iread_extents\n\u003cobserve no iext tree\u003e\nxfs_ilock(..., ILOCK_EXCL)\nxfs_iread_extents\n\u003cobserve no iext tree\u003e\n\u003ccheck ILOCK_EXCL\u003e\n\u003cload bmbt extents into iext\u003e\n\u003cnotice iext size doesn\u0027t\nmatch nextents\u003e\nxfs_need_iread_extents\n\u003cobserve iext tree\u003e\nxfs_ilock(..., ILOCK_SHARED)\n\u003ctear down iext tree\u003e\nxfs_iunlock(..., ILOCK_EXCL)\nxfs_iread_extents\n\u003cobserve no iext tree\u003e\n\u003ccheck ILOCK_EXCL\u003e\n*BOOM*\n\nFix this race by adding a flag to the xfs_ifork structure to indicate\nthat we have not yet read in the extent records and changing the\npredicate to look at the flag state, not if_height.  The memory barrier\nensures that the flag will not be set until the very end of the\nfunction.\n\nSigned-off-by: Darrick J. Wong \u003cdjwong@kernel.org\u003e\nReviewed-by: Dave Chinner \u003cdchinner@redhat.com\u003e\nSigned-off-by: Dave Chinner \u003cdavid@fromorbit.com\u003e\nSigned-off-by: Carlos Maiolino \u003ccem@kernel.org\u003e\n"
    },
    {
      "commit": "44b2e0dea3c4707902f76955c2625436258dfffb",
      "tree": "bcf60beb619f32b8fa6fb4b54d5fe7b780b64af5",
      "parents": [
        "bd970a7390d9af5ce859397a6c368d2465368d76"
      ],
      "author": {
        "name": "Dave Chinner",
        "email": "dchinner@redhat.com",
        "time": "Wed May 31 11:14:21 2023 +0200"
      },
      "committer": {
        "name": "Carlos Maiolino",
        "email": "cem@kernel.org",
        "time": "Fri Jun 09 10:27:50 2023 +0200"
      },
      "message": "xfs: don\u0027t consider future format versions valid\n\nSource kernel commit: aa88019851a85df80cb77f143758b13aee09e3d9\n\nIn commit fe08cc504448 we reworked the valid superblock version\nchecks. If it is a V5 filesystem, it is always valid, then we\nchecked if the version was less than V4 (reject) and then checked\nfeature fields in the V4 flags to determine if it was valid.\n\nWhat we missed was that if the version is not V4 at this point,\nwe shoudl reject the fs. i.e. the check current treats V6+\nfilesystems as if it was a v4 filesystem. Fix this.\n\ncc: stable@vger.kernel.org\nFixes: fe08cc504448 (\"xfs: open code sb verifier feature checks\")\nSigned-off-by: Dave Chinner \u003cdchinner@redhat.com\u003e\nReviewed-by: Darrick J. Wong \u003cdjwong@kernel.org\u003e\nSigned-off-by: Dave Chinner \u003cdavid@fromorbit.com\u003e\nSigned-off-by: Carlos Maiolino \u003ccem@kernel.org\u003e\n"
    },
    {
      "commit": "bd970a7390d9af5ce859397a6c368d2465368d76",
      "tree": "d42e56e013840637d61646720248fe18f42e30a8",
      "parents": [
        "898c055189d3e2535cf85b3b338ba5010f45080d"
      ],
      "author": {
        "name": "Darrick J. Wong",
        "email": "djwong@kernel.org",
        "time": "Wed May 31 11:13:21 2023 +0200"
      },
      "committer": {
        "name": "Carlos Maiolino",
        "email": "cem@kernel.org",
        "time": "Fri Jun 09 10:27:50 2023 +0200"
      },
      "message": "xfs: stabilize the dirent name transformation function used for ascii-ci dir hash computation\n\nSource kernel commit: a9248538facc3d9e769489e50a544509c2f9cebe\n\nBack in the old days, the \"ascii-ci\" feature was created to implement\ncase-insensitive directory entry lookups for latin1-encoded names and\nremove the large overhead of Samba\u0027s case-insensitive lookup code.  UTF8\nnames were not allowed, but nobody explicitly wrote in the documentation\nthat this was only expected to work if the system used latin1 names.\nThe kernel tolower function was selected to prepare names for hashed\nlookups.\n\nThere\u0027s a major discrepancy in the function that computes directory entry\nhashes for filesystems that have ASCII case-insensitive lookups enabled.\nThe root of this is that the kernel and glibc\u0027s tolower implementations\nhave differing behavior for extended ASCII accented characters.  I wrote\na program to spit out characters for which the tolower() return value is\ndifferent from the input:\n\nglibc tolower:\n65:A 66:B 67:C 68:D 69:E 70:F 71:G 72:H 73:I 74:J 75:K 76:L 77:M 78:N\n79:O 80:P 81:Q 82:R 83:S 84:T 85:U 86:V 87:W 88:X 89:Y 90:Z\n\nkernel tolower:\n65:A 66:B 67:C 68:D 69:E 70:F 71:G 72:H 73:I 74:J 75:K 76:L 77:M 78:N\n79:O 80:P 81:Q 82:R 83:S 84:T 85:U 86:V 87:W 88:X 89:Y 90:Z 192:À 193:Á\n194:Â 195:Ã 196:Ä 197:Å 198:Æ 199:Ç 200:È 201:É 202:Ê 203:Ë 204:Ì 205:Í\n206:Î 207:Ï 208:Ð 209:Ñ 210:Ò 211:Ó 212:Ô 213:Õ 214:Ö 215:× 216:Ø 217:Ù\n218:Ú 219:Û 220:Ü 221:Ý 222:Þ\n\nWhich means that the kernel and userspace do not agree on the hash value\nfor a directory filename that contains those higher values.  The hash\nvalues are written into the leaf index block of directories that are\nlarger than two blocks in size, which means that xfs_repair will flag\nthese directories as having corrupted hash indexes and rewrite the index\nwith hash values that the kernel now will not recognize.\n\nBecause the ascii-ci feature is not frequently enabled and the kernel\ntouches filesystems far more frequently than xfs_repair does, fix this\nby encoding the kernel\u0027s toupper predicate and tolower functions into\nlibxfs.  Give the new functions less provocative names to make it really\nobvious that this is a pre-hash name preparation function, and nothing\nelse.  This change makes userspace\u0027s behavior consistent with the\nkernel.\n\nFound by auditing obfuscate_name in xfs_metadump as part of working on\nparent pointers, wondering how it could possibly work correctly with ci\nfilesystems, writing a test tool to create a directory with\nhash-colliding names, and watching xfs_repair flag it.\n\nSigned-off-by: Darrick J. Wong \u003cdjwong@kernel.org\u003e\nReviewed-by: Christoph Hellwig \u003chch@lst.de\u003e\nSigned-off-by: Carlos Maiolino \u003ccem@kernel.org\u003e\n"
    },
    {
      "commit": "898c055189d3e2535cf85b3b338ba5010f45080d",
      "tree": "69cdde34c0926ebe40055194befacacb3b56b57c",
      "parents": [
        "fc78c405dbea6604bdce4f45f959f48dc5ef7b0f"
      ],
      "author": {
        "name": "Darrick J. Wong",
        "email": "djwong@kernel.org",
        "time": "Wed May 31 11:12:21 2023 +0200"
      },
      "committer": {
        "name": "Carlos Maiolino",
        "email": "cem@kernel.org",
        "time": "Fri Jun 09 10:27:50 2023 +0200"
      },
      "message": "xfs: accumulate iextent records when checking bmap\n\nSource kernel commit: 634d4a79e76691020ba73f50416da37a30779e9e\n\nCurrently, the bmap scrubber checks file fork mappings individually.  In\nthe case that the file uses multiple mappings to a single contiguous\npiece of space, the scrubber repeatedly locks the AG to check the\nexistence of a reverse mapping that overlaps this file mapping.  If the\nreverse mapping starts before or ends after the mapping we\u0027re checking,\nit will also crawl around in the bmbt checking correspondence for\nadjacent extents.\n\nThis is not very time efficient because it does the crawling while\nholding the AGF buffer, and checks the middle mappings multiple times.\nInstead, create a custom iextent record iterator function that combines\nmultiple adjacent allocated mappings into one large incore bmbt record.\nThis is feasible because the incore bmbt record length is 64-bits wide.\n\nSigned-off-by: Darrick J. Wong \u003cdjwong@kernel.org\u003e\nReviewed-by: Dave Chinner \u003cdchinner@redhat.com\u003e\nSigned-off-by: Carlos Maiolino \u003ccem@kernel.org\u003e\n"
    },
    {
      "commit": "fc78c405dbea6604bdce4f45f959f48dc5ef7b0f",
      "tree": "34fe1aede737b176b2a6e1a8629ab79de6e88870",
      "parents": [
        "54644f25138472d4b8ec26ac80fe47d05ff252ac"
      ],
      "author": {
        "name": "Darrick J. Wong",
        "email": "djwong@kernel.org",
        "time": "Wed May 31 11:11:21 2023 +0200"
      },
      "committer": {
        "name": "Carlos Maiolino",
        "email": "cem@kernel.org",
        "time": "Fri Jun 09 10:27:50 2023 +0200"
      },
      "message": "xfs: convert xfs_ialloc_has_inodes_at_extent to return keyfill scan results\n\nSource kernel commit: efc0845f5d3e253f7f46a60b66a94c3164d76ee3\n\nConvert the xfs_ialloc_has_inodes_at_extent function to return keyfill\nscan results because for a given range of inode numbers, we might have\nno indexed inodes at all; the entire region might be allocated ondisk\ninodes; or there might be a mix of the two.\n\nUnfortunately, sparse inodes adds to the complexity, because each inode\nrecord can have holes, which means that we cannot use the generic btree\n_scan_keyfill function because we must look for holes in individual\nrecords to decide the result.  On the plus side, online fsck can now\ndetect sub-chunk discrepancies in the inobt.\n\nSigned-off-by: Darrick J. Wong \u003cdjwong@kernel.org\u003e\nReviewed-by: Dave Chinner \u003cdchinner@redhat.com\u003e\nSigned-off-by: Carlos Maiolino \u003ccem@kernel.org\u003e\n"
    },
    {
      "commit": "54644f25138472d4b8ec26ac80fe47d05ff252ac",
      "tree": "2c479fde50ec530396d46b42e5c21361bc77f7c7",
      "parents": [
        "725589ab475822f1580f152338a1233eddd6e969"
      ],
      "author": {
        "name": "Darrick J. Wong",
        "email": "djwong@kernel.org",
        "time": "Wed May 31 11:10:21 2023 +0200"
      },
      "committer": {
        "name": "Carlos Maiolino",
        "email": "cem@kernel.org",
        "time": "Fri Jun 09 10:27:50 2023 +0200"
      },
      "message": "xfs: teach scrub to check for sole ownership of metadata objects\n\nSource kernel commit: 69115f775f6e8e972a40aa6aa1523bcb0b252b1c\n\nStrengthen online scrub\u0027s checking even further by enabling us to check\nthat a range of blocks are owned solely by a given owner.\n\nSigned-off-by: Darrick J. Wong \u003cdjwong@kernel.org\u003e\nReviewed-by: Dave Chinner \u003cdchinner@redhat.com\u003e\nSigned-off-by: Carlos Maiolino \u003ccem@kernel.org\u003e\n"
    },
    {
      "commit": "725589ab475822f1580f152338a1233eddd6e969",
      "tree": "e518e67642ecea8b86d14e40f100d66c290e1352",
      "parents": [
        "d99b890096ac527b6545ccf6e9a832c27d851b9d"
      ],
      "author": {
        "name": "Darrick J. Wong",
        "email": "djwong@kernel.org",
        "time": "Wed May 31 11:09:21 2023 +0200"
      },
      "committer": {
        "name": "Carlos Maiolino",
        "email": "cem@kernel.org",
        "time": "Fri Jun 09 10:27:50 2023 +0200"
      },
      "message": "xfs: remove pointless shadow variable from xfs_difree_inobt\n\nSource kernel commit: cc1207662d1a08e253520654e956f5e699826caa\n\nIn xfs_difree_inobt, the pag passed in was previously used to look up\nthe AGI buffer.  There\u0027s no need to extract it again, so remove the\nshadow variable and shut up -Wshadow.\n\nSigned-off-by: Darrick J. Wong \u003cdjwong@kernel.org\u003e\nReviewed-by: Dave Chinner \u003cdchinner@redhat.com\u003e\nSigned-off-by: Carlos Maiolino \u003ccem@kernel.org\u003e\n"
    },
    {
      "commit": "d99b890096ac527b6545ccf6e9a832c27d851b9d",
      "tree": "08c44781bed053211c71996d86e2ca4b282d1f5f",
      "parents": [
        "9ba4dc82877c52e549a1734e8ce73d66028c3dba"
      ],
      "author": {
        "name": "Darrick J. Wong",
        "email": "djwong@kernel.org",
        "time": "Wed May 31 11:08:21 2023 +0200"
      },
      "committer": {
        "name": "Carlos Maiolino",
        "email": "cem@kernel.org",
        "time": "Fri Jun 09 10:27:50 2023 +0200"
      },
      "message": "xfs: implement masked btree key comparisons for _has_records scans\n\nSource kernel commit: 4a200a0978288f919aba3f015f374f6ed279e658\n\nFor keyspace fullness scans, we want to be able to mask off the parts of\nthe key that we don\u0027t care about.  For most btree types we /do/ want the\nfull keyspace, but for checking that a given space usage also has a full\ncomplement of rmapbt records (even if different/multiple owners) we need\nthis masking so that we only track sparseness of rm_startblock, not the\nwhole keyspace (which is extremely sparse).\n\nAugment the -\u003ediff_two_keys and -\u003ekeys_contiguous helpers to take a\nthird union xfs_btree_key argument, and wire up xfs_rmap_has_records to\npass this through.  This third \"mask\" argument should contain a nonzero\nvalue in each structure field that should be used in the key comparisons\ndone during the scan.\n\nSigned-off-by: Darrick J. Wong \u003cdjwong@kernel.org\u003e\nReviewed-by: Dave Chinner \u003cdchinner@redhat.com\u003e\nSigned-off-by: Carlos Maiolino \u003ccem@kernel.org\u003e\n"
    },
    {
      "commit": "9ba4dc82877c52e549a1734e8ce73d66028c3dba",
      "tree": "b9f0132f80c08afcb860553fe8cc9c137a59472f",
      "parents": [
        "e3b15d883cfa1343b1b3ea57ae7dc825947e7172"
      ],
      "author": {
        "name": "Darrick J. Wong",
        "email": "djwong@kernel.org",
        "time": "Wed May 31 11:07:21 2023 +0200"
      },
      "committer": {
        "name": "Carlos Maiolino",
        "email": "cem@kernel.org",
        "time": "Fri Jun 09 10:27:50 2023 +0200"
      },
      "message": "xfs: replace xfs_btree_has_record with a general keyspace scanner\n\nSource kernel commit: 6abc7aef85b1f42cb39a3149f4ab64ca255e41e6\n\nThe current implementation of xfs_btree_has_record returns true if it\nfinds /any/ record within the given range.  Unfortunately, that\u0027s not\nsufficient for scrub.  We want to be able to tell if a range of keyspace\nfor a btree is devoid of records, is totally mapped to records, or is\nsomewhere in between.  By forcing this to be a boolean, we conflated\nsparseness and fullness, which caused scrub to return incorrect results.\nFix the API so that we can tell the caller which of those three is the\ncurrent state.\n\nSigned-off-by: Darrick J. Wong \u003cdjwong@kernel.org\u003e\nReviewed-by: Dave Chinner \u003cdchinner@redhat.com\u003e\nSigned-off-by: Carlos Maiolino \u003ccem@kernel.org\u003e\n"
    },
    {
      "commit": "e3b15d883cfa1343b1b3ea57ae7dc825947e7172",
      "tree": "dde3146e212552e116fd9f185bc281488ec78fe4",
      "parents": [
        "98226d914dcbd529837e1eb1ecc7b4f6bb4963e5"
      ],
      "author": {
        "name": "Darrick J. Wong",
        "email": "djwong@kernel.org",
        "time": "Wed May 31 11:06:21 2023 +0200"
      },
      "committer": {
        "name": "Carlos Maiolino",
        "email": "cem@kernel.org",
        "time": "Fri Jun 09 10:27:50 2023 +0200"
      },
      "message": "xfs: refactor -\u003ediff_two_keys callsites\n\nSource kernel commit: bd7e795108ccd8d0f3dc34e16957cbba7e89f342\n\nCreate wrapper functions around -\u003ediff_two_keys so that we don\u0027t have to\nremember what the return values mean, and adjust some of the code\ncomments to reflect the longtime code behavior.  We\u0027re going to\nintroduce more uses of -\u003ediff_two_keys in the next patch, so reduce the\ncognitive load for readers by doing this refactoring now.\n\nSuggested-by: Dave Chinner \u003cdavid@fromorbit.com\u003e\nSigned-off-by: Darrick J. Wong \u003cdjwong@kernel.org\u003e\nReviewed-by: Dave Chinner \u003cdchinner@redhat.com\u003e\nSigned-off-by: Carlos Maiolino \u003ccem@kernel.org\u003e\n"
    },
    {
      "commit": "98226d914dcbd529837e1eb1ecc7b4f6bb4963e5",
      "tree": "427a79b760e46ebaf619c3fdd7eb9a1cc40bdef3",
      "parents": [
        "c2d2696776f5d134c098b4f4854ba36940a32dcd"
      ],
      "author": {
        "name": "Darrick J. Wong",
        "email": "djwong@kernel.org",
        "time": "Wed May 31 11:05:21 2023 +0200"
      },
      "committer": {
        "name": "Carlos Maiolino",
        "email": "cem@kernel.org",
        "time": "Fri Jun 09 10:27:50 2023 +0200"
      },
      "message": "xfs: refactor converting btree irec to btree key\n\nSource kernel commit: ee5fe8ff6d19b35e7547af789cba877dbf04517b\n\nWe keep doing these conversions to support btree queries, so refactor\nthis into a helper.\n\nSigned-off-by: Darrick J. Wong \u003cdjwong@kernel.org\u003e\nReviewed-by: Dave Chinner \u003cdchinner@redhat.com\u003e\nReviewed-by: Dave Chinner \u003cdchinner@redhat.com\u003e\nSigned-off-by: Carlos Maiolino \u003ccem@kernel.org\u003e\n"
    },
    {
      "commit": "c2d2696776f5d134c098b4f4854ba36940a32dcd",
      "tree": "2ae91540a517b4f443e408bc5f16ffd1a773c8fb",
      "parents": [
        "71ba9fccae27d8ebe3e966fa066ba0fe3c6fc7d0"
      ],
      "author": {
        "name": "Darrick J. Wong",
        "email": "djwong@kernel.org",
        "time": "Wed May 31 11:04:21 2023 +0200"
      },
      "committer": {
        "name": "Carlos Maiolino",
        "email": "cem@kernel.org",
        "time": "Fri Jun 09 10:27:50 2023 +0200"
      },
      "message": "xfs: fix rm_offset flag handling in rmap keys\n\nSource kernel commit: 08c987deca56687c0930f308f5148ef1af38dc14\n\nKeys for extent interval records in the reverse mapping btree are\nsupposed to be computed as follows:\n\n(physical block, owner, fork, is_btree, offset)\n\nThis provides users the ability to look up a reverse mapping from a file\nblock mapping record -- start with the physical block; then if there are\nmultiple records for the same block, move on to the owner; then the\ninode fork type; and so on to the file offset.\n\nUnfortunately, the code that creates rmap lookup keys from rmap records\nforgot to mask off the record attribute flags, leading to ondisk keys\nthat look like this:\n\n(physical block, owner, fork, is_btree, unwritten state, offset)\n\nFortunately, this has all worked ok for the past six years because the\nkey comparison functions incorrectly ignore the fork/bmbt/unwritten\ninformation that\u0027s encoded in the on-disk offset.  This means that\nlookup comparisons are only done with:\n\n(physical block, owner, offset)\n\nQueries can (theoretically) return incorrect results because of this\nomission.  On consistent filesystems this isn\u0027t an issue because xattr\nand bmbt blocks cannot be shared and hence the comparisons succeed\npurely on the contents of the rm_startblock field.  For the one case\nwhere we support sharing (written data fork blocks) all flag bits are\nzero, so the omission in the comparison has no ill effects.\n\nUnfortunately, this bug prevents scrub from detecting incorrect fork and\nbmbt flag bits in the rmap btree, so we really do need to fix the\ncompare code.  Old filesystems with the unwritten bit erroneously set in\nthe rmap key struct will work fine on new kernels since we still ignore\nthe unwritten bit.  New filesystems on older kernels will work fine\nsince the old kernels never paid attention to the unwritten bit.\n\nA previous version of this patch forgot to keep the (un)written state\nflag masked during the comparison and caused a major regression in\n5.9.x since unwritten extent conversion can update an rmap record\nwithout requiring key updates.\n\nNote that blocks cannot go directly from data fork to attr fork without\nbeing deallocated and reallocated, nor can they be added to or removed\nfrom a bmbt without a free/alloc cycle, so this should not cause any\nregressions.\n\nFound by fuzzing keys[1].attrfork \u003d ones on xfs/371.\n\nFixes: 4b8ed67794fe (\"xfs: add rmap btree operations\")\nSigned-off-by: Darrick J. Wong \u003cdjwong@kernel.org\u003e\nReviewed-by: Dave Chinner \u003cdchinner@redhat.com\u003e\nSigned-off-by: Carlos Maiolino \u003ccem@kernel.org\u003e\n"
    },
    {
      "commit": "71ba9fccae27d8ebe3e966fa066ba0fe3c6fc7d0",
      "tree": "5c11ff5c1adebdf1b3a37b6734f993e059fc9f29",
      "parents": [
        "b3c8146ec425df6cc4e072d7cab35e89d9f34467"
      ],
      "author": {
        "name": "Darrick J. Wong",
        "email": "djwong@kernel.org",
        "time": "Wed May 31 11:03:21 2023 +0200"
      },
      "committer": {
        "name": "Carlos Maiolino",
        "email": "cem@kernel.org",
        "time": "Fri Jun 09 10:27:50 2023 +0200"
      },
      "message": "xfs: hoist inode record alignment checks from scrub\n\nSource kernel commit: de1a9ce225e93b22d189f8ffbce20074bc803121\n\nMove the inobt record alignment checks from xchk_iallocbt_rec into\nxfs_inobt_check_irec so that they are applied everywhere.\n\nSigned-off-by: Darrick J. Wong \u003cdjwong@kernel.org\u003e\nReviewed-by: Dave Chinner \u003cdchinner@redhat.com\u003e\nSigned-off-by: Carlos Maiolino \u003ccem@kernel.org\u003e\n"
    },
    {
      "commit": "b3c8146ec425df6cc4e072d7cab35e89d9f34467",
      "tree": "81c6c2d31a9ed2e4f7ccff12b739e8aa7dae48c9",
      "parents": [
        "830c99b1869205e1ca8979fc31d24cff8d56db22"
      ],
      "author": {
        "name": "Darrick J. Wong",
        "email": "djwong@kernel.org",
        "time": "Wed May 31 11:02:21 2023 +0200"
      },
      "committer": {
        "name": "Carlos Maiolino",
        "email": "cem@kernel.org",
        "time": "Fri Jun 09 10:27:50 2023 +0200"
      },
      "message": "xfs: hoist rmap record flag checks from scrub\n\nSource kernel commit: e774b2ea0bb130d00e3cb1c29cd91028d0c0c83d\n\nMove the rmap record flag checks from xchk_rmapbt_rec into\nxfs_rmap_check_irec so that they are applied everywhere.\n\nSigned-off-by: Darrick J. Wong \u003cdjwong@kernel.org\u003e\nReviewed-by: Dave Chinner \u003cdchinner@redhat.com\u003e\nSigned-off-by: Carlos Maiolino \u003ccem@kernel.org\u003e\n"
    },
    {
      "commit": "830c99b1869205e1ca8979fc31d24cff8d56db22",
      "tree": "25ad7aa49084537af54241acbb6c385fae18061a",
      "parents": [
        "7e7856ceee84ea52363416ad7dfa933679c8250f"
      ],
      "author": {
        "name": "Darrick J. Wong",
        "email": "djwong@kernel.org",
        "time": "Wed May 31 11:01:21 2023 +0200"
      },
      "committer": {
        "name": "Carlos Maiolino",
        "email": "cem@kernel.org",
        "time": "Fri Jun 09 10:27:50 2023 +0200"
      },
      "message": "xfs: complain about bad file mapping records in the ondisk bmbt\n\nSource kernel commit: 6a3bd8fcf9afb47c703cb268f30f60aa2e7af86a\n\nSimilar to what we\u0027ve just done for the other btrees, create a function\nto log corrupt bmbt records and call it whenever we encounter a bad\nrecord in the ondisk btree.\n\nSigned-off-by: Darrick J. Wong \u003cdjwong@kernel.org\u003e\nReviewed-by: Dave Chinner \u003cdchinner@redhat.com\u003e\nSigned-off-by: Carlos Maiolino \u003ccem@kernel.org\u003e\n"
    },
    {
      "commit": "7e7856ceee84ea52363416ad7dfa933679c8250f",
      "tree": "0662c9666863f89d6d4bc64a7ba16724db1ee1ae",
      "parents": [
        "e70bf9ba99546b22a362e58d968e838feb886a6a"
      ],
      "author": {
        "name": "Darrick J. Wong",
        "email": "djwong@kernel.org",
        "time": "Wed May 31 11:00:21 2023 +0200"
      },
      "committer": {
        "name": "Carlos Maiolino",
        "email": "cem@kernel.org",
        "time": "Fri Jun 09 10:27:50 2023 +0200"
      },
      "message": "xfs: hoist rmap record flag checks from scrub\n\nSource kernel commit: 7d7d6d2fd0444904f12e70d9c930556c4eb44337\n\nMove the rmap record flag checks from xchk_rmapbt_rec into\nxfs_rmap_check_irec so that they are applied everywhere.\n\nSigned-off-by: Darrick J. Wong \u003cdjwong@kernel.org\u003e\nReviewed-by: Dave Chinner \u003cdchinner@redhat.com\u003e\nSigned-off-by: Carlos Maiolino \u003ccem@kernel.org\u003e\n"
    },
    {
      "commit": "e70bf9ba99546b22a362e58d968e838feb886a6a",
      "tree": "eb82f0f789a9a79830450e58765f842778054527",
      "parents": [
        "fd1d74cd69383ec7baaee7ad2e5dbe47f0061bbf"
      ],
      "author": {
        "name": "Darrick J. Wong",
        "email": "djwong@kernel.org",
        "time": "Wed May 31 10:59:21 2023 +0200"
      },
      "committer": {
        "name": "Carlos Maiolino",
        "email": "cem@kernel.org",
        "time": "Fri Jun 09 10:27:50 2023 +0200"
      },
      "message": "xfs: complain about bad records in query_range helpers\n\nSource kernel commit: ee12eaaa435a7be17152ac50943ee77249de624a\n\nFor every btree type except for the bmbt, refactor the code that\ncomplains about bad records into a helper and make the -\u003equery_range\nhelpers call it so that corruptions found via that avenue are logged.\n\nSigned-off-by: Darrick J. Wong \u003cdjwong@kernel.org\u003e\nReviewed-by: Dave Chinner \u003cdchinner@redhat.com\u003e\nSigned-off-by: Carlos Maiolino \u003ccem@kernel.org\u003e\n"
    },
    {
      "commit": "fd1d74cd69383ec7baaee7ad2e5dbe47f0061bbf",
      "tree": "b57334cdce0cb67943d61267e0ecfa6c978b8174",
      "parents": [
        "8d444a7a7dc866137e574e34c25febbd270121e8"
      ],
      "author": {
        "name": "Darrick J. Wong",
        "email": "djwong@kernel.org",
        "time": "Wed May 31 10:58:21 2023 +0200"
      },
      "committer": {
        "name": "Carlos Maiolino",
        "email": "cem@kernel.org",
        "time": "Fri Jun 09 10:27:50 2023 +0200"
      },
      "message": "xfs: standardize ondisk to incore conversion for rmap btrees\n\nSource kernel commit: c4e34172da26cb57f56c471728853d3a428ec832\n\nCreate a xfs_rmap_check_irec function to detect corruption in btree\nrecords.  Fix all xfs_rmap_btrec_to_irec callsites to call the new\nhelper and bubble up corruption reports.\n\nSigned-off-by: Darrick J. Wong \u003cdjwong@kernel.org\u003e\nReviewed-by: Dave Chinner \u003cdchinner@redhat.com\u003e\nSigned-off-by: Carlos Maiolino \u003ccem@kernel.org\u003e\n"
    },
    {
      "commit": "8d444a7a7dc866137e574e34c25febbd270121e8",
      "tree": "a79e0f148e576e9278b2ce6193f28fa8ba0974c9",
      "parents": [
        "03d1a871946af6c3db5017bedb485e2e7db1f085"
      ],
      "author": {
        "name": "Darrick J. Wong",
        "email": "djwong@kernel.org",
        "time": "Wed May 31 10:58:13 2023 +0200"
      },
      "committer": {
        "name": "Carlos Maiolino",
        "email": "cem@kernel.org",
        "time": "Fri Jun 09 10:27:50 2023 +0200"
      },
      "message": "xfs: return a failure address from xfs_rmap_irec_offset_unpack\n\nSource kernel commit: 39ab26d59f039c6190bbaa8118a8f0ffed84492a\n\nCurrently, xfs_rmap_irec_offset_unpack returns only 0 or -EFSCORRUPTED.\nChange this function to return the code address of a failed conversion\nin preparation for the next patch, which standardizes localized record\nchecking and reporting code.\n\nSigned-off-by: Darrick J. Wong \u003cdjwong@kernel.org\u003e\nReviewed-by: Dave Chinner \u003cdchinner@redhat.com\u003e\nSigned-off-by: Carlos Maiolino \u003ccem@kernel.org\u003e\n"
    },
    {
      "commit": "03d1a871946af6c3db5017bedb485e2e7db1f085",
      "tree": "53a5accccf02eb9d687138d4500bcc9a6293e692",
      "parents": [
        "349aa6876786cbcf9faa3aed3c577f634c03a8b0"
      ],
      "author": {
        "name": "Darrick J. Wong",
        "email": "djwong@kernel.org",
        "time": "Tue May 30 13:14:58 2023 +0200"
      },
      "committer": {
        "name": "Carlos Maiolino",
        "email": "cem@kernel.org",
        "time": "Fri Jun 09 10:27:50 2023 +0200"
      },
      "message": "xfs: standardize ondisk to incore conversion for refcount btrees\n\nSource kernel commit: 2b30cc0bf0589d1ea0506c019b9b81de77535c87\n\nCreate a xfs_refcount_check_irec function to detect corruption in btree\nrecords.  Fix all xfs_refcount_btrec_to_irec callsites to call the new\nhelper and bubble up corruption reports.\n\nSigned-off-by: Darrick J. Wong \u003cdjwong@kernel.org\u003e\nReviewed-by: Dave Chinner \u003cdchinner@redhat.com\u003e\nSigned-off-by: Carlos Maiolino \u003ccem@kernel.org\u003e\n"
    },
    {
      "commit": "349aa6876786cbcf9faa3aed3c577f634c03a8b0",
      "tree": "1a010641f13d864ad9aa88073d51318b072760a5",
      "parents": [
        "c7005aef10dce9d9f237ad3ef73d38224b131c46"
      ],
      "author": {
        "name": "Darrick J. Wong",
        "email": "djwong@kernel.org",
        "time": "Tue May 30 13:13:58 2023 +0200"
      },
      "committer": {
        "name": "Carlos Maiolino",
        "email": "cem@kernel.org",
        "time": "Fri Jun 09 10:27:50 2023 +0200"
      },
      "message": "xfs: standardize ondisk to incore conversion for inode btrees\n\nSource kernel commit: 366a0b8d49c3a7edcb5331f254af195716ba4bdf\n\nCreate a xfs_inobt_check_irec function to detect corruption in btree\nrecords.  Fix all xfs_inobt_btrec_to_irec callsites to call the new\nhelper and bubble up corruption reports.\n\nSigned-off-by: Darrick J. Wong \u003cdjwong@kernel.org\u003e\nReviewed-by: Dave Chinner \u003cdchinner@redhat.com\u003e\nSigned-off-by: Carlos Maiolino \u003ccem@kernel.org\u003e\n"
    },
    {
      "commit": "c7005aef10dce9d9f237ad3ef73d38224b131c46",
      "tree": "bc740a7b054af145f1e88058ddfe9869cb974af9",
      "parents": [
        "7cb26322f749ab93cd20588c58aab22a379d76e0"
      ],
      "author": {
        "name": "Darrick J. Wong",
        "email": "djwong@kernel.org",
        "time": "Tue May 30 13:13:55 2023 +0200"
      },
      "committer": {
        "name": "Carlos Maiolino",
        "email": "cem@kernel.org",
        "time": "Fri Jun 09 10:27:50 2023 +0200"
      },
      "message": "xfs: standardize ondisk to incore conversion for free space btrees\n\nSource kernel commit: 35e3b9a11740b53387e7af151768c13700f80696\n\nCreate a xfs_alloc_btrec_to_irec function to convert an ondisk record to\nan incore record, and a xfs_alloc_check_irec function to detect\ncorruption.  Replace all the open-coded logic with calls to the new\nhelpers and bubble up corruption reports.\n\nSigned-off-by: Darrick J. Wong \u003cdjwong@kernel.org\u003e\nReviewed-by: Dave Chinner \u003cdchinner@redhat.com\u003e\nSigned-off-by: Carlos Maiolino \u003ccem@kernel.org\u003e\n"
    },
    {
      "commit": "7cb26322f749ab93cd20588c58aab22a379d76e0",
      "tree": "af02b3aa0353d600bb27ad6e4ab655d11012b9b6",
      "parents": [
        "11e716f40c71da49b073eb287c14a908c1fbeb01"
      ],
      "author": {
        "name": "Darrick J. Wong",
        "email": "djwong@kernel.org",
        "time": "Tue May 30 11:04:51 2023 +0200"
      },
      "committer": {
        "name": "Carlos Maiolino",
        "email": "cem@kernel.org",
        "time": "Fri Jun 09 10:27:50 2023 +0200"
      },
      "message": "xfs: allow queued AG intents to drain before scrubbing\n\nSource kernel commit: d5c88131dbf01a30a222ad82d58e0c21a15f0d8e\n\nWhen a writer thread executes a chain of log intent items, the AG header\nbuffer locks will cycle during a transaction roll to get from one intent\nitem to the next in a chain.  Although scrub takes all AG header buffer\nlocks, this isn\u0027t sufficient to guard against scrub checking an AG while\nthat writer thread is in the middle of finishing a chain because there\u0027s\nno higher level locking primitive guarding allocation groups.\n\nWhen there\u0027s a collision, cross-referencing between data structures\n(e.g. rmapbt and refcountbt) yields false corruption events; if repair\nis running, this results in incorrect repairs, which is catastrophic.\n\nFix this by adding to the perag structure the count of active intents\nand make scrub wait until it has both AG header buffer locks and the\nintent counter reaches zero.\n\nOne quirk of the drain code is that deferred bmap updates also bump and\ndrop the intent counter.  A fundamental decision made during the design\nphase of the reverse mapping feature is that updates to the rmapbt\nrecords are always made by the same code that updates the primary\nmetadata.  In other words, callers of bmapi functions expect that the\nbmapi functions will queue deferred rmap updates.\n\nSome parts of the reflink code queue deferred refcount (CUI) and bmap\n(BUI) updates in the same head transaction, but the deferred work\nmanager completely finishes the CUI before the BUI work is started.  As\na result, the CUI drops the intent count long before the deferred rmap\n(RUI) update even has a chance to bump the intent count.  The only way\nto keep the intent count elevated between the CUI and RUI is for the BUI\nto bump the counter until the RUI has been created.\n\nA second quirk of the intent drain code is that deferred work items must\nincrement the intent counter as soon as the work item is added to the\ntransaction.  When a BUI completes and queues an RUI, the RUI must\nincrement the counter before the BUI decrements it.  The only way to\naccomplish this is to require that the counter be bumped as soon as the\ndeferred work item is created in memory.\n\nIn the next patches we\u0027ll improve on this facility, but this patch\nprovides the basic functionality.\n\nSigned-off-by: Darrick J. Wong \u003cdjwong@kernel.org\u003e\nReviewed-by: Dave Chinner \u003cdchinner@redhat.com\u003e\nSigned-off-by: Carlos Maiolino \u003ccem@kernel.org\u003e\n"
    },
    {
      "commit": "11e716f40c71da49b073eb287c14a908c1fbeb01",
      "tree": "ec102df0381a747c8fc44f2c77746971bbc0ea9f",
      "parents": [
        "b2c5c83de26cbb7097384ebcdc72b08bcaa3ad13"
      ],
      "author": {
        "name": "Darrick J. Wong",
        "email": "djwong@kernel.org",
        "time": "Tue May 30 10:48:02 2023 +0200"
      },
      "committer": {
        "name": "Carlos Maiolino",
        "email": "cem@kernel.org",
        "time": "Fri Jun 09 10:27:50 2023 +0200"
      },
      "message": "xfs: create traced helper to get extra perag references\n\nSource kernel commit: 9b2e5a234c89f097ec36f922763dfa1465dc06f8\n\nThere are a few places in the XFS codebase where a caller has either an\nactive or a passive reference to a perag structure and wants to give\na passive reference to some other piece of code.  Btree cursor creation\nand inode walks are good examples of this.  Replace the open-coded logic\nwith a helper to do this.\n\nThe new function adds a few safeguards -- it checks that there\u0027s at\nleast one reference to the perag structure passed in, and it records the\nrefcount bump in the ftrace information.  This makes it much easier to\ndebug perag refcounting problems.\n\nSigned-off-by: Darrick J. Wong \u003cdjwong@kernel.org\u003e\nReviewed-by: Dave Chinner \u003cdchinner@redhat.com\u003e\nSigned-off-by: Carlos Maiolino \u003ccem@kernel.org\u003e\n"
    },
    {
      "commit": "b2c5c83de26cbb7097384ebcdc72b08bcaa3ad13",
      "tree": "16a1baca56ed1fea9058f6516c742ea881981e61",
      "parents": [
        "818f0c29db7f166d5e9ba039c6e008d4d3b72f72"
      ],
      "author": {
        "name": "Darrick J. Wong",
        "email": "djwong@kernel.org",
        "time": "Tue May 30 10:44:56 2023 +0200"
      },
      "committer": {
        "name": "Carlos Maiolino",
        "email": "cem@kernel.org",
        "time": "Fri Jun 09 10:27:50 2023 +0200"
      },
      "message": "xfs: give xfs_refcount_intent its own perag reference\n\nSource kernel commit: 00e7b3bac1dc8961bd5aa9d39e79131c6bd81181\n\nGive the xfs_refcount_intent a passive reference to the perag structure\ndata.  This reference will be used to enable scrub intent draining\nfunctionality in subsequent patches.  Any space being modified by a\nrefcount intent is already allocated, so we need to be able to operate\neven if the AG is being shrunk or offlined.\n\nSigned-off-by: Darrick J. Wong \u003cdjwong@kernel.org\u003e\nReviewed-by: Dave Chinner \u003cdchinner@redhat.com\u003e\nSigned-off-by: Carlos Maiolino \u003ccem@kernel.org\u003e\n"
    },
    {
      "commit": "818f0c29db7f166d5e9ba039c6e008d4d3b72f72",
      "tree": "a5172df15cb79cb348715af5f30b9f97236f4e21",
      "parents": [
        "7fef0c11117bfabcbe87288ad4ef611bd62a845c"
      ],
      "author": {
        "name": "Darrick J. Wong",
        "email": "djwong@kernel.org",
        "time": "Mon May 29 10:49:36 2023 +0200"
      },
      "committer": {
        "name": "Carlos Maiolino",
        "email": "cem@kernel.org",
        "time": "Fri Jun 09 10:27:50 2023 +0200"
      },
      "message": "xfs: give xfs_rmap_intent its own perag reference\n\nSource kernel commit: c13418e8eb375872ad297aeec5fa26277febc155\n\nGive the xfs_rmap_intent a passive reference to the perag structure\ndata.  This reference will be used to enable scrub intent draining\nfunctionality in subsequent patches.  The space we\u0027re (reverse) mapping\nis already allocated, so we need to be able to operate even if the AG is\nbeing shrunk or offlined.\n\nSigned-off-by: Darrick J. Wong \u003cdjwong@kernel.org\u003e\nReviewed-by: Dave Chinner \u003cdchinner@redhat.com\u003e\nSigned-off-by: Carlos Maiolino \u003ccem@kernel.org\u003e\n"
    },
    {
      "commit": "7fef0c11117bfabcbe87288ad4ef611bd62a845c",
      "tree": "8543721a27d95afb201a7126f2b70490e9aad0a6",
      "parents": [
        "42c1e5c18e5ee1547aa21eec1caa5371a958d4a7"
      ],
      "author": {
        "name": "Darrick J. Wong",
        "email": "djwong@kernel.org",
        "time": "Fri May 26 16:03:29 2023 +0200"
      },
      "committer": {
        "name": "Carlos Maiolino",
        "email": "cem@kernel.org",
        "time": "Fri Jun 09 10:27:50 2023 +0200"
      },
      "message": "xfs: give xfs_extfree_intent its own perag reference\n\nSource kernel commit: f6b384631e1e3482c24e35b53adbd3da50e47e8f\n\nGive the xfs_extfree_intent an passive reference to the perag structure\ndata.  This reference will be used to enable scrub intent draining\nfunctionality in subsequent patches.  The space being freed must already\nbe allocated, so we need to able to run even if the AG is being offlined\nor shrunk.\n\nSigned-off-by: Darrick J. Wong \u003cdjwong@kernel.org\u003e\nReviewed-by: Dave Chinner \u003cdchinner@redhat.com\u003e\nSigned-off-by: Carlos Maiolino \u003ccem@kernel.org\u003e\n"
    },
    {
      "commit": "42c1e5c18e5ee1547aa21eec1caa5371a958d4a7",
      "tree": "c506df20a5b5c0907a56d7e68ae276c3f22beae6",
      "parents": [
        "32debad7cda40bfa9ecf094cee240f4ec12fb3f2"
      ],
      "author": {
        "name": "Darrick J. Wong",
        "email": "djwong@kernel.org",
        "time": "Fri May 26 15:38:11 2023 +0200"
      },
      "committer": {
        "name": "Carlos Maiolino",
        "email": "cem@kernel.org",
        "time": "Fri Jun 09 10:27:50 2023 +0200"
      },
      "message": "xfs: pass per-ag references to xfs_free_extent\n\nSource kernel commit: b2ccab3199aa7cea9154d80ea2585312c5f6eba0\n\nPass a reference to the per-AG structure to xfs_free_extent.  Most\ncallers already have one, so we can eliminate unnecessary lookups.  The\none exception to this is the EFI code, which the next patch will fix.\n\nSigned-off-by: Darrick J. Wong \u003cdjwong@kernel.org\u003e\nReviewed-by: Dave Chinner \u003cdchinner@redhat.com\u003e\nSigned-off-by: Carlos Maiolino \u003ccem@kernel.org\u003e\n"
    },
    {
      "commit": "32debad7cda40bfa9ecf094cee240f4ec12fb3f2",
      "tree": "deb76b5ac0f02a0ad63e5ecbf1947f456c3258a1",
      "parents": [
        "36100197818eee4e90db5389c3fd12ce63043382"
      ],
      "author": {
        "name": "Darrick J. Wong",
        "email": "djwong@kernel.org",
        "time": "Fri May 26 15:16:03 2023 +0200"
      },
      "committer": {
        "name": "Carlos Maiolino",
        "email": "cem@kernel.org",
        "time": "Fri Jun 09 10:27:28 2023 +0200"
      },
      "message": "xfs: give xfs_bmap_intent its own perag reference\n\nSource kernel commit: 774a99b47b588bf0bd9f65d3b241d5bba0b2fcb0\n\nGive the xfs_bmap_intent an active reference to the perag structure\ndata.  This reference will be used to enable scrub intent draining\nfunctionality in subsequent patches.  Later, shrink will use these\npassive references to know if an AG is quiesced or not.\n\nThe reason why we take a passive ref for a file mapping operation is\nsimple: we\u0027re committing to some sort of action involving space in an\nAG, so we want to indicate our interest in that AG.  The space is\nalready allocated, so we need to be able to operate on AGs that are\noffline or being shrunk.\n\nSigned-off-by: Darrick J. Wong \u003cdjwong@kernel.org\u003e\nReviewed-by: Dave Chinner \u003cdchinner@redhat.com\u003e\nSigned-off-by: Carlos Maiolino \u003ccem@kernel.org\u003e\n"
    },
    {
      "commit": "36100197818eee4e90db5389c3fd12ce63043382",
      "tree": "92626e489eb9afe73efed3053c23807cbf605ec7",
      "parents": [
        "f499ee5cf0aa520ed7489249e2e465587ae19c59"
      ],
      "author": {
        "name": "Carlos Maiolino",
        "email": "cem@kernel.org",
        "time": "Fri May 26 15:13:38 2023 +0200"
      },
      "committer": {
        "name": "Carlos Maiolino",
        "email": "cem@kernel.org",
        "time": "Fri Jun 09 10:26:35 2023 +0200"
      },
      "message": "libxfs: Finish renaming xfs_extent_item variables\n\nFinish renaming xfs_extent_free_item variables to xefi on file\nlibxfs/defer_item.c, because the maintainer overlooked this file while\npulling changes from kernel commit 578c714b215d474c52949e65a914dae67924f0fe.\n\nSigned-off-by: Carlos Maiolino \u003ccem@kernel.org\u003e\nReviewed-by: Darrick J. Wong \u003cdjwong@kernel.org\u003e\n"
    },
    {
      "commit": "f499ee5cf0aa520ed7489249e2e465587ae19c59",
      "tree": "0bc212e3fa168e4634b0fada3212433f173ddbd2",
      "parents": [
        "5fda1858ae6c1fd85f4cd87b7beff4588b39fdea"
      ],
      "author": {
        "name": "Carlos Maiolino",
        "email": "cem@kernel.org",
        "time": "Mon May 22 11:50:36 2023 +0200"
      },
      "committer": {
        "name": "Carlos Maiolino",
        "email": "cem@kernel.org",
        "time": "Mon May 22 11:50:36 2023 +0200"
      },
      "message": "xfsprogs: Release v6.3.0\n\nUpdate all the necessary files for a 6.3.0 release.\n\nSigned-off-by: Carlos Maiolino \u003ccem@kernel.org\u003e\n"
    },
    {
      "commit": "5fda1858ae6c1fd85f4cd87b7beff4588b39fdea",
      "tree": "cb5eb058c00deed789880e6508d0cb29ee2528a2",
      "parents": [
        "7655596449b536f4f1be45bff3c0055eb0955e68"
      ],
      "author": {
        "name": "Darrick J. Wong",
        "email": "djwong@kernel.org",
        "time": "Wed May 03 08:15:15 2023 -0700"
      },
      "committer": {
        "name": "Carlos Maiolino",
        "email": "cem@kernel.org",
        "time": "Wed May 10 15:59:58 2023 +0200"
      },
      "message": "xfs_repair: dont leak buffer when discarding directories\n\nCommit 1f7c7553489c tried to reduce the memory requirements of phase 6\nof repair by redesigning longform_dir2_entry_check without the bplist\narray.  Unfortunately, none of us noticed that the code that rejects a\ndir block with a bad header now leaks the xfs_buf object because we no\nlonger have a bplist to drop the buffer references.  Any time we hold a\nbuffer and decide to move on in the dabno loop, we must release the\nbuffer.\n\nThe immediate result of this error is that dir_binval complains about\nthe recursive lock count of the buffer when we blow out the directory.\nHowever, if the block is reallocated by another thread, repair will\ndeadlock when it tries to get the buffer and cannot take the buffer\nlock.\n\nFound via xfs/113 fuzzing data format directory blocks.  For whatever\nreason this happens much more frequently when su\u003d128k,sw\u003d4, but this\napplies to everyone equally.\n\nWhile we\u0027re at it, make the relse at the bottom of the function run for\nany remaining buffer reference, even if this isn\u0027t a block format\ndirectory to avoid leaving a landmine in case we ever add a \"goto\nfix\" inside the loop for a non-block directory.\n\nFixes: 1f7c7553489 (\"repair: don\u0027t duplicate names in phase 6\")\nSigned-off-by: Darrick J. Wong \u003cdjwong@kernel.org\u003e\nReviewed-by: Carlos Maiolino \u003ccmaiolino@redhat.com\u003e\nSigned-off-by: Carlos Maiolino \u003ccem@kernel.org\u003e\n"
    },
    {
      "commit": "7655596449b536f4f1be45bff3c0055eb0955e68",
      "tree": "2ec0295d3df028f695ef1017039a7373a01f1930",
      "parents": [
        "ffb1fbc8e7be313d384e1f1286acf7aa664b51a8"
      ],
      "author": {
        "name": "Darrick J. Wong",
        "email": "djwong@kernel.org",
        "time": "Thu Apr 27 15:45:21 2023 -0700"
      },
      "committer": {
        "name": "Carlos Maiolino",
        "email": "cem@kernel.org",
        "time": "Wed May 10 15:57:32 2023 +0200"
      },
      "message": "xfs_repair: estimate per-AG btree slack better\n\nThe slack calculation for per-AG btrees is a bit inaccurate because it\nonly disables slack space in the new btrees when the amount of free\nspace in the AG (not counting the btrees) is less than 3/32ths of the\nAG.  In other words, it assumes that the btrees will fit in less than 9\npercent of the space.\n\nHowever, there\u0027s one scenario where this goes wrong -- if the rmapbt\nconsumes a significant portion of the AG space.  Say a filesystem is\nhosting a VM image farm that starts with perfectly shared images.  As\ntime goes by, random writes to those images will slowly cause the rmapbt\nto increase in size as blocks within those images get COWed.\n\nSuppose that the rmapbt now consumes 20% of the space in the AG, that\nthe AG is nearly full, and that the blocks in the old rmapbt are mostly\nfull.  At the start of phase5_func, mk_incore_fstree will return that\nnum_freeblocks is ~20% of the AG size.  Hence the slack calculation will\nconclude that there\u0027s plenty of space in the AG and new btrees will be\nbuilt with 25% slack in the blocks.  If the size of these new expanded\nbtrees is larger than the free space in the AG, repair will fail to\nallocate btree blocks and fail, causing severe filesystem damage.\n\nTo combat this, estimate the worst case size of the AG btrees given the\nnumber of records we intend to put in them, subtract that worst case\nfigure from num_freeblocks, and feed that to bulkload_estimate_ag_slack.\nThis results in tighter packing of new btree blocks when space is dear,\nand hopefully fewer problems.  This /can/ be reproduced with generic/333\nif you hack it to keep COWing blocks until the filesystem is totally\nout of space, even if reflink has long since refused to share more\nblocks.\n\nSigned-off-by: Darrick J. Wong \u003cdjwong@kernel.org\u003e\nReviewed-by: Carlos Maiolino \u003ccmaiolino@redhat.com\u003e\nSigned-off-by: Carlos Maiolino \u003ccem@kernel.org\u003e\n"
    },
    {
      "commit": "ffb1fbc8e7be313d384e1f1286acf7aa664b51a8",
      "tree": "2177af2aa2d3b3af1512093fa636230e267fb65e",
      "parents": [
        "f4e6c2435a673b581a4d1b6fdf12d5fe21a6cd61"
      ],
      "author": {
        "name": "Darrick J. Wong",
        "email": "djwong@kernel.org",
        "time": "Wed May 10 15:15:15 2023 +0200"
      },
      "committer": {
        "name": "Carlos Maiolino",
        "email": "cem@kernel.org",
        "time": "Wed May 10 15:54:40 2023 +0200"
      },
      "message": "mkfs: warning about misaligned AGs and RAID stripes is not an error\n\nI\u0027ve noticed a fair number of fstests failures when we create a scratch\ndevice on a RAID device and the test specifies an explicit AG count or\nAG size:\n\n--- /tmp/fstests/tests/xfs/042.out\t2022-09-01 15:09:11.484679979 -0700\n+++ /var/tmp/fstests/xfs/042.out.bad\t2023-04-25 19:59:04.040000000 -0700\n@@ -1,5 +1,8 @@\n QA output created by 042\n-Make a 96 megabyte filesystem on SCRATCH_DEV and mount... done\n+Make a 96 megabyte filesystem on SCRATCH_DEV and mount... Warning: AG size is a multiple of stripe width.  This can cause performance\n+problems by aligning all AGs on the same disk.  To avoid this, run mkfs with\n+an AG size that is one stripe unit smaller or larger, for example 8160.\n+done\n\nEmitting this warning on stderr is silly -- nothing has failed, and we\naren\u0027t going to abort the format either.  Send the warning to stdout.\n\nSigned-off-by: Darrick J. Wong \u003cdjwong@kernel.org\u003e\nReviewed-by: Carlos Maiolino \u003ccmaiolino@redhat.com\u003e\nSigned-off-by: Carlos Maiolino \u003ccem@kernel.org\u003e\n"
    },
    {
      "commit": "f4e6c2435a673b581a4d1b6fdf12d5fe21a6cd61",
      "tree": "15e1b00ed9703d41daedd68b37533ed332122756",
      "parents": [
        "002b5d96f1d87620db5cc3b7fa7c690a20d5e7f5"
      ],
      "author": {
        "name": "Darrick J. Wong",
        "email": "djwong@kernel.org",
        "time": "Thu Apr 27 12:02:33 2023 -0700"
      },
      "committer": {
        "name": "Carlos Maiolino",
        "email": "cem@kernel.org",
        "time": "Wed May 10 15:13:27 2023 +0200"
      },
      "message": "xfs_db: fix broken logic in error path\n\nsmatch complains proceeding into the if body if leaf is a null pointer:\n\ncheck.c:3614 process_leaf_node_dir_v2_int() warn: variable dereferenced before check \u0027leaf\u0027 (see line 3518)\n\nHowever, the logic here is misleading and broken -- what we\u0027re trying to\ndo is switch between the v4 and v5 variants of the directory check.\nWe\u0027re using @leaf3 being a null pointer (or not) to determine v4 vs. v5,\nso the \"!\" part of the comparison is correct, but the variable used\n(leaf) is not.\n\nSigned-off-by: Darrick J. Wong \u003cdjwong@kernel.org\u003e\nReviewed-by: Carlos Maiolino \u003ccmaiolino@redhat.com\u003e\nSigned-off-by: Carlos Maiolino \u003ccem@kernel.org\u003e\n"
    }
  ],
  "next": "002b5d96f1d87620db5cc3b7fa7c690a20d5e7f5"
}