Re: [REGRESSION 6.1.70] system calls with CIFS mounts failing with "Resource temporarily unavailable"

[Salvatore Bonaccorso <carnil@debian.org>]

Hi Paulo,

On Thu, Feb 22, 2024 at 08:00:58PM -0300, Paulo Alcantara wrote:
> Greg Kroah-Hartman <gregkh@linuxfoundation.org> writes:
> 
> > On Tue, Feb 20, 2024 at 10:25:16PM +0100, Salvatore Bonaccorso wrote:
> >> Hi Greg,
> >> 
> >> On Tue, Feb 20, 2024 at 09:27:49PM +0100, Greg Kroah-Hartman wrote:
> >> > On Tue, Jan 30, 2024 at 11:49:23PM +0100, Salvatore Bonaccorso wrote:
> >> > > Hi Paulo, hi Greg,
> >> > > 
> >> > > On Tue, Jan 30, 2024 at 11:43:52PM +0100, Salvatore Bonaccorso wrote:
> >> > > > Hi Paulo, hi Greg,
> >> > > > 
> >> > > > Note this is about the 5.10.y backports of the cifs issue, were system
> >> > > > calls fail with "Resource temporarily unavailable".
> >> > > > 
> >> > > > On Mon, Jan 08, 2024 at 12:58:49PM -0300, Paulo Alcantara wrote:
> >> > > > > Greg Kroah-Hartman <gregkh@linuxfoundation.org> writes:
> >> > > > > 
> >> > > > > > Why can't we just include eb3e28c1e89b ("smb3: Replace smb2pdu 1-element
> >> > > > > > arrays with flex-arrays") to resolve this?
> >> > > > > 
> >> > > > > Yep, this is the right way to go.
> >> > > > > 
> >> > > > > > I've queued it up now.
> >> > > > > 
> >> > > > > Thanks!
> >> > > > 
> >> > > > Is the underlying issue by picking the three commits:
> >> > > > 
> >> > > > 3080ea5553cc ("stddef: Introduce DECLARE_FLEX_ARRAY() helper")
> >> > > > eb3e28c1e89b ("smb3: Replace smb2pdu 1-element arrays with flex-arrays")
> >> > > > 
> >> > > > and the last commit in linux-stable-rc for 5.10.y:
> >> > > > 
> >> > > > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git/commit?id=a280ecca48beb40ca6c0fc20dd5a7fdd9b3ee0b7
> >> > > > 
> >> > > > really fixing the issue?
> >> > > > 
> >> > > > Since we need to release a new update in Debian, I picked those three
> >> > > > for testing on top of the 5.10.209-1 and while testing explicitly a
> >> > > > cifs mount, I still get:
> >> > > > 
> >> > > > statfs(".", 0x7ffd809d5a70)             = -1 EAGAIN (Resource temporarily unavailable)
> >> > > > 
> >> > > > The same happens if I build
> >> > > > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git/commit?id=a280ecca48beb40ca6c0fc20dd5a7fdd9b3ee0b7
> >> > > > (knowing that it is not yet ready for review).
> >> > > > 
> >> > > > I'm slight confused as a280ecca48be ("cifs: fix off-by-one in
> >> > > > SMB2_query_info_init()") says in the commit message:
> >> > > > 
> >> > > > [...]
> >> > > > 	v5.10.y doesn't have
> >> > > > 
> >> > > >         eb3e28c1e89b ("smb3: Replace smb2pdu 1-element arrays with flex-arrays")
> >> > > > 
> >> > > > 	and the commit does
> >> > > > [...]
> >> > > > 
> >> > > > and in meanwhile though the eb3e28c1e89b was picked (in a backported
> >> > > > version). As 6.1.75-rc2 itself does not show the same problem, might
> >> > > > there be a prerequisite missing in the backports for 5.10.y or a
> >> > > > backport being wrong?
> >> > > 
> >> > > The problem seems to be that we are picking the backport for
> >> > > eb3e28c1e89b, but then still applying 
> >> > > 
> >> > > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git/commit?id=a280ecca48beb40ca6c0fc20dd5
> >> > > 
> >> > > which was made for the case in 5.10.y where eb3e28c1e89b is not
> >> > > present.
> >> > > 
> >> > > I reverted a280ecca48beb40ca6c0fc20dd5 and now:
> >> > > 
> >> > > statfs(".", {f_type=SMB2_MAGIC_NUMBER, f_bsize=4096, f_blocks=2189197, f_bfree=593878, f_bavail=593878, f_files=0, f_ffree=0, f_fsid={val=[2004816114, 0]}, f_namelen=255, f_frsize=4096, f_flags=ST_VALID|ST_RELATIME}) = 0
> >> > 
> >> > So this works?  Would that just be easier to do overall?  I feel like
> >> > that might be best here.
> >> > 
> >> > Again, a set of simple "do this and this and this" would be nice to
> >> > have, as there are too many threads here, some incomplete and missing
> >> > commits on my end.
> >> > 
> >> > confused,
> >> 
> >> It is quite chaotic, since I believe multiple people worked on trying
> >> to resolve the issue, and then for the 5.10.y and 5.15.y branches
> >> different initial commits were applied. 
> >> 
> >> For 5.10.y it's the case: Keep the backport of eb3e28c1e89b and drop
> >> a280ecca48be (as it is not true that v5.10.y does not have
> >> eb3e28c1e89b, as it is actually in the current 5.10.y queue).
> >
> > I think we are good now.
> >
> >> Paulo can you please give Greg an authoratitative set of commits to
> >> keep/apply in the 5.10.y and 5.15.y series.
> >
> > Yes, anything I missed?
> 
> The one-liner fix (a280ecca48be) provided by Harshit was only required
> if not backporting eb3e28c1e89b.  As both 5.10.y and 5.15.y now have
> eb3e28c1e89b queued up, LGTM.
> 
> Salvatore, please let us know if you can still hit the issue with
> eb3e28c1e89b applied.

Correct, I cannot reproduce anymore the issue with 5.10.210-rc1.

Regards,
Salvatore