Re: 5.15.0-rc1 armv7hl Workqueue: btrfs-delalloc btrfs_work_helper PC is at mmiocpy LR is at ZSTD_compressStream

[David Sterba <dsterba@suse.cz>]

On Mon, Oct 04, 2021 at 07:57:25PM +0800, Su Yue wrote:
> 
> On Tue 21 Sep 2021 at 21:56, David Sterba <dsterba@suse.cz> wrote:
> 
> > On Mon, Sep 20, 2021 at 06:13:07PM -0600, Chris Murphy wrote:
> >> https://kojipkgs.fedoraproject.org//work/tasks/8820/75928820/oz-armhfp.log
> >
> >> 00:09:50,679 EMERG kernel:[<c08bd768>] (mmiocpy) from 
> >> [<c089c314>]
> >> (ZSTD_compressStream+0x184/0x294)
> >
> > The last function to fail is inside ZSTD implementation in 
> > kernel.
> > If btrfs passes wrong data to zstd we'd see that also on non-arm 
> > builds,
> > so guessing by mmiocpy as a copy-something function it could be 
> > some
> > sort of alignment problem that works on x86_64 but throws an 
> > exception
> > on arm as it's stricter about alignment.
> 
> It's about 32bits platforms. There is another report about x86 
> cpu.
> And it's reproduciable by running btrfs/004 (lzo and zstd)in x86 
> VM.
> In my arm64, all things are fine.
> And the bisection result is the highmem related patchset
> '[PATCH 0/6] Remove highmem allocations, kmap/kunmap'.

I must be missing something then, if the pages are not allocated from
HIGHMEM we don't need kmap. If the pages come from outside and are
potentially allocated from HIGHMEM kmap is used, that's for all the
file/inode pages.