Hi Mark, Arnd,
We've stumbled onto a statx/ext2-related kernel bug.
The bug itself isn't that interesting, but we were confused why we only saw it on arm64 (arm32, x86, x86_64 did not see it).
It turns out, the bug is in EXT2 (not in the EXT4 compatibility implementation, but actual EXT2) as a result of arm64 defconfig including EXT2_FS, which isn't included in arm multi_v7_defconfig nor x86's defconfigs.
This surprised us a bit, and so we're wondering if EXT2_FS should be removed from arm64 defconfig?
See https://bugs.linaro.org/show_bug.cgi?id=4012 for details.
Dan
On Wed, 9 Jan 2019 at 21:17, Dan Rue dan.rue@linaro.org wrote:
Hi Mark, Arnd,
We've stumbled onto a statx/ext2-related kernel bug.
The bug itself isn't that interesting, but we were confused why we only saw it on arm64 (arm32, x86, x86_64 did not see it).
It turns out, the bug is in EXT2 (not in the EXT4 compatibility implementation, but actual EXT2) as a result of arm64 defconfig including EXT2_FS, which isn't included in arm multi_v7_defconfig nor x86's defconfigs.
This surprised us a bit, and so we're wondering if EXT2_FS should be removed from arm64 defconfig?
For test purposes there's also an argument for adding the option of real ext2 for the other architectures as they're missing test coverage here... you really want to test both real and simulated ext2 support so long as they both exist (and similarly for ext3). That said since the goal is generally for defconfig to be more like a distro config or starting point for development my sense is that you probably want to bring arm64 in line with the rest and then extend your test config to get the coverage.
I would also suggest that it'd be useful to split this architecture neutral configuration out into a shared architecture neutral defconfig but that needs a bit more surgery than is entirely relevant here (MIPS has an implementation of this idea which could be used as a starting point).