Data Corruption bug with Samba's vfs_iouring and Linux 5.6.7/5.7rc3

[Anoop C S]

On Mon, 2020-05-11 at 21:54 +0200, Stefan Metzmacher via samba-
technical wrote:
> Am 09.05.20 um 04:50 schrieb Jeremy Allison via samba-technical:
> > On Sat, May 09, 2020 at 12:04:55AM +0200, Stefan Metzmacher via
> > samba-technical wrote:
> > > Am 08.05.20 um 23:50 schrieb Jeremy Allison:
> > > > RB+ from me if you add a comment header above the function
> > > > as well as in the commit so it explains what it's doing.
> > > > 
> > > > Feel free to crib my ascii art to explain in the header
> > > > comment too :-).
> > > > 
> > > > Thanks for the cleanup !
> > > 
> > > I'll do that on Monday.
> > 
> > Here's an updated version with added
> > comments inside
> > 
> > [PATCH 20/29] vfs_io_uring: avoid stack recursion of
> > vfs_io_uring_queue_run()
> > 
> > so I could actually (hopefully) understand
> > it if I have to go back and look at it in 5 years time :-).
> 
> Thanks! I've done some experiments with offset < 0 and it's not
> allowed
> for SMB2 read nor write.
> 
> I'll post the updated patchset to the merge request shortly.
> 
> It would be great if someone could verify it with a 5.6 kernel.

Latest patch set[1] could successfully copy from and to vfs_io_uring
enabled ext4 share using Windows explorer against Samba server with
kernel v5.6.10.	SHA256 checksum of copied files matches original value.

[1] https://attachments.samba.org/attachment.cgi?id=15971