On 11/25/24 17:22, Darrick J. Wong wrote:
On Mon, Nov 25, 2024 at 02:26:18PM -0800, Florian Fainelli wrote:__kernel_rwf_t was defined with upstream Linux commit ddef7ed2b5cbafae692d1d580bb5a07808926a9c ("annotate RWF_... flags") which has been included in Linux v4.14 and newer. When building xfsprogs/methinks you should upgrade your kernel, 4.14 is quite dead now, and you're not even running something /that/ new.
No disagreement here, we provide a toolchain whose kernel headers are intentional set to 4.9.x to maximize the compatibility with what our customers would be using at the time and that is how we caught that build failure. In general though, we should not be intentionally breaking the build against older kernel headers IMHO, especially when it is possible to do so.
The intent in the commit in the Fixes tag clearly had taken into account that RWF_ATOMIC might not have been defined.
against older kernel headers, this type is not defined, leading to the following build error: pwrite.c: In function 'pwrite_f': ../include/xfs/linux.h:236:22: error: '__kernel_rwf_t' undeclared (first use in this function); did you mean '__kernel_off_t'? #define RWF_ATOMIC ((__kernel_rwf_t)0x00000040) ^~~~~~~~~~~~~~ pwrite.c:329:22: note: in expansion of macro 'RWF_ATOMIC' pwritev2_flags |= RWF_ATOMIC; Fixes: ee6c5941352a ("xfs_io: add RWF_ATOMIC support to pwrite") Signed-off-by: Florian Fainelli <florian.fainelli@xxxxxxxxxxxx>That said, if this doesn't break anything with a ~2020s distro then I don't have any objections to this, so: Reviewed-by: "Darrick J. Wong" <djwong@xxxxxxxxxx>
Thanks, any chance this can be applied? -- Florian
