summaryrefslogtreecommitdiff
tag namefix-log-recovery-misuse-6.1_2022-10-31 (40a459ebe3bcea29c80190a0ea984c8a628eadea)
tag date2022-10-31 08:58:49 -0700
tagged byDarrick J. Wong <djwong@kernel.org>
tagged objectcommit 950f0d50ee...
xfs: fix various problems with log intent item recovery
Starting with 6.1-rc1, CONFIG_FORTIFY_SOURCE checks became smart enough to detect memcpy() callers that copy beyond what seems to be the end of a struct. Unfortunately, gcc has a bug wherein it cannot reliably compute the size of a struct containing another struct containing a flex array at the end. This is the case with the xfs log item format structures, which means that -rc1 starts complaining all over the place. Fix these problems by memcpying the struct head and the flex arrays separately. Although it's tempting to use the FLEX_ARRAY macros, the structs involved are part of the ondisk log format. Some day we're going to want to make the ondisk log contents endian-safe, which means that we will have to stop using memcpy entirely. While we're at it, fix some deficiencies in the validation of recovered log intent items -- if the size of the recovery buffer is not even large enough to cover the flex array record count in the head, we should abort the recovery of that item immediately. The last patch of this series changes the EFI/EFD sizeof functions names and behaviors to be consistent with the similarly named sizeof helpers for other log intent items. v2: fix more inadequate log intent done recovery validation and dump corrupt recovered items Signed-off-by: Darrick J. Wong <djwong@kernel.org> -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEUzaAxoMeQq6m2jMV+H93GTRKtOsFAmNf8LkACgkQ+H93GTRK tOt3QQ//SuyxzE4i2Vr8o7dwFQ6qtQeSt9RixtgKUG3ay+eZLCgpA7KS8po0Dv7W /8aAY6K712Mp2IzmdJUIHb/Pch5UbRSN5rw0169CsNDOmU/R9njqfeMWMfDr9ixS HAWfo13yh/QSmBTyioijZhP08N0TpyNVFsM9s5/4hKU7UGV4h5g2kz+hyDHrsSmB KXAM7FAh6SX8eBjxpj3iKLgsdEW7mcsDYurSVOnfmgWkXvgZXoLOvPt84e09A+s3 tLq5AEiLr261o45VbfExrjqn0qvwE7HdMdLPJrTa/tp6ztfsU2SJ6AxmG/XTTlBj jnIcYL9unu8JOndmJjLZxuhXmXXwZ3eFfsUgn0/tluSeR/nMMc3CCItZ58Ox5zk7 kUpN0JnY1+ecYmDw1Qz8LhhSIReOiA5Rw2SwVQ8wB3Oit9/cBQsxtM9YxxOne3MN od2096CiyvCYjpm6EGTRCkxQuz2nleJ5LajXb7dmkw91IiPdvoWbTPT+trtjO/63 gYbD0A4Qko9iDW0bWCCvWPD6vBZhN1q6r1j1lu77Az+z/45W47ut6MGokK4NHzo3 fTarDMqbVDxyeSrhW713iQO7PypLoOv7b72HD1+SvSkHzKwdi42kIlWe8e5B8Rew GkH2ycfQtaq+UR2fT4rSs4wWWuxoZLyo9Utdh0DA0ZF5QZfAqFo= =wP07 -----END PGP SIGNATURE-----