Re: [REGRESSION] Corruption on cifs / smb write on ARM, kernels 6.3-6.9

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On request:
* adding another cc for Steven
* I tested 6.6.52, without any extra commits: it was bad.

-James

On Mon, Sep 23, 2024 at 12:36 PM james young <pronoiac@xxxxxxxxx> wrote:
>
> Hey there -
>
> On Sun, Sep 22, 2024 at 4:55 PM Wang Yugui <wangyugui@xxxxxxxxxxxx> wrote:
> >
> > Hi,
> >
> > > I was benchmarking some compressors, piping to and from a network share on a NAS, and some consistently wrote corrupted data.
>
> > > Important commits:
> > > It looked like both the breakage and the fix came in during rc1 releases.
> > >
> > > Breakage, v6.3-rc1:
> > > I manually bisected commits in fs/smb* and fs/cifs.
> > >
> > > 3d78fe73fa12 cifs: Build the RDMA SGE list directly from an iterator
> > > > lzop and pigz worked. last working. test in progress: pbzip2
>
> This is a first for me: lzop was fine, but pbzip2 still had issues,
> roughly a clock hour into compression. (When lzop has issues, it's
> usually within a minute or two.)
>
>
> > > 607aea3cc2a8 cifs: Remove unused code
> > > > lzop didn't work. first broken
> > >
> > >
> > > Fix, v6.10-rc1:
> > > I manually bisected commits in fs/smb.
> > >
> > > 69c3c023af25 cifs: Implement netfslib hooks
> > > > lzop didn't work. last broken one
> > >
> > > 3ee1a1fc3981 cifs: Cut over to using netfslib
> > > > lzop, pigz, pbzip2, all worked. first fixed one
>
> > I checked 607aea3cc2a8, it just removed some code in #if 0 ... #endif.
> > so this regression is not introduced in 607aea3cc2a8,  but the reproduce
> > frequency is changed here.
>
> I agree. The pbzip2 results above, regarding the break bisection I
> landed on: they mark when it became more of an issue, but not when it
> started.
>
> I could re-run tests and dig into possible false negatives. It'll be
> slower going, though.
>
>
> > Another issue in 6.6.y maybe related
> > https://lore.kernel.org/linux-fsdevel/9e8f8872-f51b-4a09-a92c-49218748dd62@xxxxxxxx/T/
>
> In comparison: I'm relieved that my issue is something that can be
> tested within hours, on one device.
>
>
> > Do this regression still happen after the following patches are applied?
> >
> > a60cc288a1a2 :Luis Chamberlain: test_xarray: add tests for advanced multi-index use
> > a08c7193e4f1 :Sidhartha Kumar: mm/filemap: remove hugetlb special casing in filemap.c
> > 6212eb4d7a63 :Hongbo Li: mm/filemap: avoid type conversion
> >
> > de60fd8ddeda :Kairui Song: mm/filemap: return early if failed to allocate memory for split
> > b2ebcf9d3d5a :Kairui Song: mm/filemap: clean up hugetlb exclusion code
> > a4864671ca0b :Kairui Song: lib/xarray: introduce a new helper xas_get_order
> > 6758c1128ceb :Kairui Song: mm/filemap: optimize filemap folio adding
>
> No luck: I cherry-picked those commits into 6.6.52, and upon testing
> lzop, the file didn't match the stream, and decompression failed.
>
> Thank you for investigating, and giving me something to try!
>
> -James





[Index of Archives]     [Linux Kernel]     [Kernel Development Newbies]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Hiking]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux