Digging deeper into this it looks like the problem is not the size being bigger than 32K but picking a write size (wsize) that is not a multiple of page size (4096). I was able to reproduce this e.g. with wsize=70000 but not with 69632 (ie a multiple of page size, 17*4096) On Mon, Feb 5, 2024 at 10:05 PM Steve French <smfrench@xxxxxxxxx> wrote: > > In my additional experiments I could reproduce this but only with > wsize < 32768 but it wasn't SMB1 specific - I could reproduce it with > current dialects (smb3.1.1 e.g.) too not just SMB1 - so it is more > about you picking small wsize that found the bug than an SMB1 > specific problem. > > On Mon, Feb 5, 2024 at 7:30 PM Steve French <smfrench@xxxxxxxxx> wrote: > > > > I can reproduce this now with a simple smb1 cp - but only with the small wsize > > ie mount option: wsize=16850. As mentioned earlier the problem is > > that we see a 16K write, then the next write is at the wrong offset > > (leaving a hole) > > > > (it worked for SMB1 with default wsize) > > > > so focus is on these two functions in the call stack: > > > > [19085.611988] cifs_async_writev+0x90/0x380 [cifs] > > [19085.612083] cifs_writepages_region+0xadc/0xbb0 [cifs] > > > > On Mon, Feb 5, 2024 at 3:37 AM R. Diez <rdiez-2006@xxxxxxx> wrote: > > > > > > > > > >> Unlikely as you didn't take them for the last merge window, let alone 6.2. > > > > > > > > That said, you did take my iteratorisation patches in 6.3 - but that shouldn't > > > > affect 6.2 unless someone backported them. > > > > > > Please note that 6.2 is not affected, the breakage occurred afterwards. See the bug report here for more information: > > > > > > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2049634 > > > > > > Regards, > > > rdiez > > > > > > > > > -- > > Thanks, > > > > Steve > > > > -- > Thanks, > > Steve -- Thanks, Steve
