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

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

[Mohamed Abuelfotoh, Hazem]

It looks like both 5.15.146 and 5.10.206 are impacted by this regression as they both have the
bad commit 33eae65c6f (smb: client: fix OOB in SMB2_query_info_init()). We tried to
apply the proposed fix eb3e28c1e89b ("smb3: Replace smb2pdu 1-element 
arrays with flex-arrays”) but there are a lot of dependencies required to do the backport.
Is it possible to consider the simple fix that Paulo proposed as a solution for 5.10 and 5.15.
We were lucky with 5.4 as it doesn’t have the bad commit because of merge conflict reported
in https://lore.kernel.org/all/2023122857-doubling-crazed-27f4@gregkh/T/#m3aa009c332999268f71361237ace6ded9110f0d0

diff --git a/fs/smb/client/smb2pdu.c b/fs/smb/client/smb2pdu.c
	index 05ff8a457a3d..aed5067661de 100644
	--- a/fs/smb/client/smb2pdu.c
	+++ b/fs/smb/client/smb2pdu.c
	@@ -3556,7 +3556,7 @@ SMB2_query_info_init(struct cifs_tcon *tcon, struct TCP_Server_Info *server,
	 
	 	iov[0].iov_base = (char *)req;
	 	/* 1 for Buffer */
	-	iov[0].iov_len = len;
	+	iov[0].iov_len = len - 1;
	 	return 0;
	 }

Hazem

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

[Mohamed Abuelfotoh, Hazem]

To be clear here we have already tested 5.10.206 and 5.15.146 with the proposed fix 
and we no longer see the reported CIFS mounting failure.

Hazem

On 15/01/2024, 14:23, "Mohamed Abuelfotoh, Hazem" <abuehaze@amazon.com <mailto:abuehaze@amazon.com>> wrote:


It looks like both 5.15.146 and 5.10.206 are impacted by this regression as they both have the
bad commit 33eae65c6f (smb: client: fix OOB in SMB2_query_info_init()). We tried to
apply the proposed fix eb3e28c1e89b ("smb3: Replace smb2pdu 1-element 
arrays with flex-arrays”) but there are a lot of dependencies required to do the backport.
Is it possible to consider the simple fix that Paulo proposed as a solution for 5.10 and 5.15.
We were lucky with 5.4 as it doesn’t have the bad commit because of merge conflict reported
in https://lore.kernel.org/all/2023122857-doubling-crazed-27f4@gregkh/T/#m3aa009c332999268f71361237ace6ded9110f0d0 <https://lore.kernel.org/all/2023122857-doubling-crazed-27f4@gregkh/T/#m3aa009c332999268f71361237ace6ded9110f0d0>


diff --git a/fs/smb/client/smb2pdu.c b/fs/smb/client/smb2pdu.c
index 05ff8a457a3d..aed5067661de 100644
--- a/fs/smb/client/smb2pdu.c
+++ b/fs/smb/client/smb2pdu.c
@@ -3556,7 +3556,7 @@ SMB2_query_info_init(struct cifs_tcon *tcon, struct TCP_Server_Info *server,


iov[0].iov_base = (char *)req;
/* 1 for Buffer */
- iov[0].iov_len = len;
+ iov[0].iov_len = len - 1;
return 0;
}


Hazem

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

[gregkh]

On Mon, Jan 15, 2024 at 02:28:45PM +0000, Mohamed Abuelfotoh, Hazem wrote:
> To be clear here we have already tested 5.10.206 and 5.15.146 with the proposed fix 
> and we no longer see the reported CIFS mounting failure.

Please don't top-post :(

Anyway, please submit this in a form that it can be applied in, as-is,
there's nothing I can do with this...

thanks,

greg k-h

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

[Mohamed Abuelfotoh, Hazem]

Thanks Greg, I will submit separate patch inclusion requests for 
fixing this on 5.15 and 5.10.

Hazem

On 15/01/2024, 15:17, "gregkh@linuxfoundation.org <mailto:gregkh@linuxfoundation.org>" <gregkh@linuxfoundation.org <mailto:gregkh@linuxfoundation.org>> wrote:


CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.






On Mon, Jan 15, 2024 at 02:28:45PM +0000, Mohamed Abuelfotoh, Hazem wrote:
> To be clear here we have already tested 5.10.206 and 5.15.146 with the proposed fix
> and we no longer see the reported CIFS mounting failure.


Please don't top-post :(


Anyway, please submit this in a form that it can be applied in, as-is,
there's nothing I can do with this...


thanks,


greg k-h

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

[Harshit Mogalapalli]

Hi,

On 15/01/24 7:52 pm, Mohamed Abuelfotoh, Hazem wrote:
> It looks like both 5.15.146 and 5.10.206 are impacted by this regression as they both have the
> bad commit 33eae65c6f (smb: client: fix OOB in SMB2_query_info_init()). We tried to
> apply the proposed fix eb3e28c1e89b ("smb3: Replace smb2pdu 1-element
> arrays with flex-arrays”) but there are a lot of dependencies required to do the backport.
> Is it possible to consider the simple fix that Paulo proposed as a solution for 5.10 and 5.15.
> We were lucky with 5.4 as it doesn’t have the bad commit because of merge conflict reported
> in https://lore.kernel.org/all/2023122857-doubling-crazed-27f4@gregkh/T/#m3aa009c332999268f71361237ace6ded9110f0d0
> 

I think we are also seeing the same error on running xfstests with cifs.

[root@vm xfstests-dev]# ./check -g quick -s smb3
TEST_DEV=//<SERVER_IP>/TEST is mounted but not a type cifs filesystem

This is with 5.15.147 stable kernel.

I started seeing this since 5.15.146 and on bisection it points to the 
same commit:

commit bfd18c0f570e ("smb: client: fix OOB in SMB2_query_info_init()"), 
reverting that commit fixed the issue and also when I applied the below 
diff provided in this thread, the tests run fine.

[root@vm xfstests-dev]# ./check -g quick -s smb3 cifs/001
SECTION       -- smb3
FSTYP         -- cifs
PLATFORM      -- Linux/x86_64 vm 5.15.147-master.el9.v5.x86_64 #1 SMP 
Mon Jan 15 22:39:33 PST 2024
MKFS_OPTIONS  -- //<SERVER_IP>/SCRATCH
MOUNT_OPTIONS -- 
-ousername=root,password=PASSWORD,noperm,mfsymlinks,actimeo=0 
//<SERVER_IP>/SCRATCH /mnt/scratch

cifs/001 1s ...  1s
generic/001 16s ...

Thanks,
Harshit

> diff --git a/fs/smb/client/smb2pdu.c b/fs/smb/client/smb2pdu.c
> 	index 05ff8a457a3d..aed5067661de 100644
> 	--- a/fs/smb/client/smb2pdu.c
> 	+++ b/fs/smb/client/smb2pdu.c
> 	@@ -3556,7 +3556,7 @@ SMB2_query_info_init(struct cifs_tcon *tcon, struct TCP_Server_Info *server,
> 	
> 	 	iov[0].iov_base = (char *)req;
> 	 	/* 1 for Buffer */
> 	-	iov[0].iov_len = len;
> 	+	iov[0].iov_len = len - 1;
> 	 	return 0;
> 	 }
> 
> Hazem

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

[SeongJae Park]

On Mon, 15 Jan 2024 14:22:39 +0000 "Mohamed Abuelfotoh, Hazem" <abuehaze@amazon.com> wrote:

> It looks like both 5.15.146 and 5.10.206 are impacted by this regression as
> they both have the bad commit 33eae65c6f (smb: client: fix OOB in
> SMB2_query_info_init()).

Let me try to tell this to the regression tracking bot, following the doc[1].
This is my first time using #regzbot, so please feel free to correct me if I'm
doing something wrong.

#regzbot introduced: 33eae65c6f

[1] https://docs.kernel.org/admin-guide/reporting-regressions.html#how-do-i-report-a-regression


Thanks,
SJ

[...]

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

[Salvatore Bonaccorso]

Hi,

On Mon, Jan 15, 2024 at 03:30:46PM +0000, Mohamed Abuelfotoh, Hazem wrote:
> Thanks Greg, I will submit separate patch inclusion requests for 
> fixing this on 5.15 and 5.10.

Note, my reply in the secondary thread:
https://lore.kernel.org/stable/Zbl881W5S-nL7iof@eldamar.lan/T/#mb9a9a012adde1c5c6e9d3daa1d8dce2c9b5cc78f

Now
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git/commit?id=a280ecca48beb40ca6c0fc20dd5a7fdd9b3ee0b7
was applied, but equally the backport
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git/commit/?id=06aa6eff7b243891c631b40852a0c453e274955d
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git/commit/?id=ef8316e0e29e98d9cf7e0689ddffa37e79d33736

So I guess
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git/commit?id=a280ecca48beb40ca6c0fc20dd5a7fdd9b3ee0b7
should be dropped again.

Regards,
Salvatore

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

[Paulo Alcantara]

Salvatore Bonaccorso <carnil@debian.org> writes:

> Hi,
>
> On Mon, Jan 15, 2024 at 03:30:46PM +0000, Mohamed Abuelfotoh, Hazem wrote:
>> Thanks Greg, I will submit separate patch inclusion requests for 
>> fixing this on 5.15 and 5.10.
>
> Note, my reply in the secondary thread:
> https://lore.kernel.org/stable/Zbl881W5S-nL7iof@eldamar.lan/T/#mb9a9a012adde1c5c6e9d3daa1d8dce2c9b5cc78f
>
> Now
> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git/commit?id=a280ecca48beb40ca6c0fc20dd5a7fdd9b3ee0b7
> was applied, but equally the backport
> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git/commit/?id=06aa6eff7b243891c631b40852a0c453e274955d
> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git/commit/?id=ef8316e0e29e98d9cf7e0689ddffa37e79d33736
>
> So I guess
> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git/commit?id=a280ecca48beb40ca6c0fc20dd5a7fdd9b3ee0b7
> should be dropped again.

Agreed.

Greg, could you please drop

        b3632baa5045 ("cifs: fix off-by-one in SMB2_query_info_init()")

from v5.10.y as suggested by Salvatore?

Thanks.

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

[Mohamed Abuelfotoh, Hazem]

On 31/01/2024 17:19, Paulo Alcantara wrote:
> Greg, could you please drop
> 
>          b3632baa5045 ("cifs: fix off-by-one in SMB2_query_info_init()")
> 
> from v5.10.y as suggested by Salvatore?
> 
> Thanks.

Are we dropping b3632baa5045 ("cifs: fix off-by-one in 
SMB2_query_info_init()") from v5.10.y while keeping it on v5.15.y? if we 
are dropping it from v5.15.y as well then we should backport 06aa6eff7b 
smb3: Replace smb2pdu 1-element arrays with flex-arrays to v5.15.y I 
remember trying to backport this patch on v5.15.y but there were some 
merge conflicts there.

06aa6eff7b smb3: Replace smb2pdu 1-element arrays with flex-arrays


Thank you.

Hazem

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

[Salvatore Bonaccorso]

Hi,

On Thu, Feb 01, 2024 at 12:58:28PM +0000, Mohamed Abuelfotoh, Hazem wrote:
> 
> On 31/01/2024 17:19, Paulo Alcantara wrote:
> > Greg, could you please drop
> > 
> >          b3632baa5045 ("cifs: fix off-by-one in SMB2_query_info_init()")
> > 
> > from v5.10.y as suggested by Salvatore?
> > 
> > Thanks.
> 
> Are we dropping b3632baa5045 ("cifs: fix off-by-one in
> SMB2_query_info_init()") from v5.10.y while keeping it on v5.15.y? if we are
> dropping it from v5.15.y as well then we should backport 06aa6eff7b smb3:
> Replace smb2pdu 1-element arrays with flex-arrays to v5.15.y I remember
> trying to backport this patch on v5.15.y but there were some merge conflicts
> there.
> 
> 06aa6eff7b smb3: Replace smb2pdu 1-element arrays with flex-arrays

While I'm not eligible to say what should be done, my understading is
that Greg probably would prefer to have the "backport 06aa6eff7b"
version. What we know is that having now both commits in the
stable-rc/linux-5.10.y queue breaks  cifs and the backport variants
seens to work fine (Paulo Alcantara probably though can comment best).

As 06aa6eff7b smb3: Replace smb2pdu 1-element arrays with flex-arrays
was backportable to 5.10.y it should now work as well for the upper
one 5.15.y.

Regards,
Salvatore

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

[Harshit Mogalapalli]

Hi Salvatore,

Adding kovalev here(who backported it to 5.10.y)

On 03/02/24 9:09 pm, Salvatore Bonaccorso wrote:
> Hi,
> 
> On Thu, Feb 01, 2024 at 12:58:28PM +0000, Mohamed Abuelfotoh, Hazem wrote:
>>
>> On 31/01/2024 17:19, Paulo Alcantara wrote:
>>> Greg, could you please drop
>>>
>>>           b3632baa5045 ("cifs: fix off-by-one in SMB2_query_info_init()")
>>>
>>> from v5.10.y as suggested by Salvatore?
>>>
>>> Thanks.
>>
>> Are we dropping b3632baa5045 ("cifs: fix off-by-one in
>> SMB2_query_info_init()") from v5.10.y while keeping it on v5.15.y? if we are
>> dropping it from v5.15.y as well then we should backport 06aa6eff7b smb3:
>> Replace smb2pdu 1-element arrays with flex-arrays to v5.15.y I remember
>> trying to backport this patch on v5.15.y but there were some merge conflicts
>> there.
>>
>> 06aa6eff7b smb3: Replace smb2pdu 1-element arrays with flex-arrays
> 
> While I'm not eligible to say what should be done, my understading is
> that Greg probably would prefer to have the "backport 06aa6eff7b"
> version. What we know is that having now both commits in the
> stable-rc/linux-5.10.y queue breaks  cifs and the backport variants
> seens to work fine (Paulo Alcantara probably though can comment best).
> 
Having both one-liner fix that I have sent and the above commit isn't 
correct.

> As 06aa6eff7b smb3: Replace smb2pdu 1-element arrays with flex-arrays
> was backportable to 5.10.y it should now work as well for the upper
> one 5.15.y.

Correct, I agree. I had to send one-liner fix as we have the 
backport("06aa6eff7b smb3: Replace smb2pdu 1-element arrays with 
flex-arrays") missing in 5.15.y and when I tried backporting it to 
5.15.y I saw many conflicts.

If we have backport for 5.15.y similar to 5.10.y we could ask greg to 
remove one liner fix from both 5.10.y and 5.15.y: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git/tree/queue-5.10/cifs-fix-off-by-one-in-smb2_query_info_init.patch

Thanks,
Harshit


> 
> Regards,
> Salvatore
> 

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

[kovalev]

Hello everyone,

06.02.2024 10:46, Harshit Mogalapalli wrote:
>
> Adding kovalev here(who backported it to 5.10.y)
I adapted the commit "smb3: Replace smb2pdu 1-element arrays with 
flex-arrays" for 5.15.y and sent patch[1].


[1] 
https://lore.kernel.org/lkml/20240206161111.454699-1-kovalev@altlinux.org/T/#u

-- 
Regards,
Vasiliy Kovalev

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

[gregkh]

On Tue, Feb 06, 2024 at 01:16:01PM +0530, Harshit Mogalapalli wrote:
> Hi Salvatore,
> 
> Adding kovalev here(who backported it to 5.10.y)
> 
> On 03/02/24 9:09 pm, Salvatore Bonaccorso wrote:
> > Hi,
> > 
> > On Thu, Feb 01, 2024 at 12:58:28PM +0000, Mohamed Abuelfotoh, Hazem wrote:
> > > 
> > > On 31/01/2024 17:19, Paulo Alcantara wrote:
> > > > Greg, could you please drop
> > > > 
> > > >           b3632baa5045 ("cifs: fix off-by-one in SMB2_query_info_init()")
> > > > 
> > > > from v5.10.y as suggested by Salvatore?
> > > > 
> > > > Thanks.
> > > 
> > > Are we dropping b3632baa5045 ("cifs: fix off-by-one in
> > > SMB2_query_info_init()") from v5.10.y while keeping it on v5.15.y? if we are
> > > dropping it from v5.15.y as well then we should backport 06aa6eff7b smb3:
> > > Replace smb2pdu 1-element arrays with flex-arrays to v5.15.y I remember
> > > trying to backport this patch on v5.15.y but there were some merge conflicts
> > > there.
> > > 
> > > 06aa6eff7b smb3: Replace smb2pdu 1-element arrays with flex-arrays
> > 
> > While I'm not eligible to say what should be done, my understading is
> > that Greg probably would prefer to have the "backport 06aa6eff7b"
> > version. What we know is that having now both commits in the
> > stable-rc/linux-5.10.y queue breaks  cifs and the backport variants
> > seens to work fine (Paulo Alcantara probably though can comment best).
> > 
> Having both one-liner fix that I have sent and the above commit isn't
> correct.
> 
> > As 06aa6eff7b smb3: Replace smb2pdu 1-element arrays with flex-arrays
> > was backportable to 5.10.y it should now work as well for the upper
> > one 5.15.y.
> 
> Correct, I agree. I had to send one-liner fix as we have the
> backport("06aa6eff7b smb3: Replace smb2pdu 1-element arrays with
> flex-arrays") missing in 5.15.y and when I tried backporting it to 5.15.y I
> saw many conflicts.
> 
> If we have backport for 5.15.y similar to 5.10.y we could ask greg to remove
> one liner fix from both 5.10.y and 5.15.y: https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git/tree/queue-5.10/cifs-fix-off-by-one-in-smb2_query_info_init.patch

Someone needs to tell me what to do, as I'm lost.

thanks,

greg k-h

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

[Harshit Mogalapalli]

Hi Greg,

On 21/02/24 01:58, gregkh@linuxfoundation.org wrote:
> On Tue, Feb 06, 2024 at 01:16:01PM +0530, Harshit Mogalapalli wrote:
>> Hi Salvatore,
>>
>> Adding kovalev here(who backported it to 5.10.y)
>>
>> On 03/02/24 9:09 pm, Salvatore Bonaccorso wrote:
>>> Hi,
>>>
>>> On Thu, Feb 01, 2024 at 12:58:28PM +0000, Mohamed Abuelfotoh, Hazem wrote:
>>>>
>>>> On 31/01/2024 17:19, Paulo Alcantara wrote:
>>>>> Greg, could you please drop
>>>>>
>>>>>            b3632baa5045 ("cifs: fix off-by-one in SMB2_query_info_init()")
>>>>>
>>>>> from v5.10.y as suggested by Salvatore?
>>>>>
>>>>> Thanks.
>>>>
>>>> Are we dropping b3632baa5045 ("cifs: fix off-by-one in
>>>> SMB2_query_info_init()") from v5.10.y while keeping it on v5.15.y? if we are
>>>> dropping it from v5.15.y as well then we should backport 06aa6eff7b smb3:
>>>> Replace smb2pdu 1-element arrays with flex-arrays to v5.15.y I remember
>>>> trying to backport this patch on v5.15.y but there were some merge conflicts
>>>> there.
>>>>
>>>> 06aa6eff7b smb3: Replace smb2pdu 1-element arrays with flex-arrays
>>>
>>> While I'm not eligible to say what should be done, my understading is
>>> that Greg probably would prefer to have the "backport 06aa6eff7b"
>>> version. What we know is that having now both commits in the
>>> stable-rc/linux-5.10.y queue breaks  cifs and the backport variants
>>> seens to work fine (Paulo Alcantara probably though can comment best).
>>>
>> Having both one-liner fix that I have sent and the above commit isn't
>> correct.
>>
>>> As 06aa6eff7b smb3: Replace smb2pdu 1-element arrays with flex-arrays
>>> was backportable to 5.10.y it should now work as well for the upper
>>> one 5.15.y.
>>
>> Correct, I agree. I had to send one-liner fix as we have the
>> backport("06aa6eff7b smb3: Replace smb2pdu 1-element arrays with
>> flex-arrays") missing in 5.15.y and when I tried backporting it to 5.15.y I
>> saw many conflicts.
>>
>> If we have backport for 5.15.y similar to 5.10.y we could ask greg to remove
>> one liner fix from both 5.10.y and 5.15.y: https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git/tree/queue-5.10/cifs-fix-off-by-one-in-smb2_query_info_init.patch
> 
> Someone needs to tell me what to do, as I'm lost.
> 

For 5.15.y:

1. Remove this patch from the queue:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git/tree/queue-5.15/cifs-fix-off-by-one-in-smb2_query_info_init.patch
2. Add this patch(kovalev's backport) to queue:
https://lore.kernel.org/lkml/20240206161111.454699-1-kovalev@altlinux.org/T/#u

For 5.10.y:

1. Remove this patch from the queue:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git/tree/queue-5.10/cifs-fix-off-by-one-in-smb2_query_info_init.patch

(kovalev's backport is already in queue[1], so nothing to add here like 
'2' in 5.15.y)



Reason for the above:

For 5.10.y and 5.15.y: I have sent a diverged patch(one liner) which is 
present in the queue now and have to be removed because kovalev sent a 
backport of upstream commit by resolving conflicts. Given that both of 
us were working on same problem there should only be one fix there, so 
we are going with Kovalev's backport and removing my one liner fix. 
Kovalev's backport for 5.10.y was already added to queue but not in 
5.15.y. So remove my one liner fix from both queues and queuing up 
Kovalev's 5.15.y backport will solve the problems. Please let me know if 
any of this is unclear, I can share more details.


Ref:
[1]: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git/tree/queue-5.10/smb3-replace-smb2pdu-1-element-arrays-with-flex-arrays.patch


Thanks,
Harshit
> thanks,
> 
> greg k-h

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

[gregkh]

On Wed, Feb 21, 2024 at 07:56:01AM +0530, Harshit Mogalapalli wrote:
> Hi Greg,
> 
> On 21/02/24 01:58, gregkh@linuxfoundation.org wrote:
> > On Tue, Feb 06, 2024 at 01:16:01PM +0530, Harshit Mogalapalli wrote:
> > > Hi Salvatore,
> > > 
> > > Adding kovalev here(who backported it to 5.10.y)
> > > 
> > > On 03/02/24 9:09 pm, Salvatore Bonaccorso wrote:
> > > > Hi,
> > > > 
> > > > On Thu, Feb 01, 2024 at 12:58:28PM +0000, Mohamed Abuelfotoh, Hazem wrote:
> > > > > 
> > > > > On 31/01/2024 17:19, Paulo Alcantara wrote:
> > > > > > Greg, could you please drop
> > > > > > 
> > > > > >            b3632baa5045 ("cifs: fix off-by-one in SMB2_query_info_init()")
> > > > > > 
> > > > > > from v5.10.y as suggested by Salvatore?
> > > > > > 
> > > > > > Thanks.
> > > > > 
> > > > > Are we dropping b3632baa5045 ("cifs: fix off-by-one in
> > > > > SMB2_query_info_init()") from v5.10.y while keeping it on v5.15.y? if we are
> > > > > dropping it from v5.15.y as well then we should backport 06aa6eff7b smb3:
> > > > > Replace smb2pdu 1-element arrays with flex-arrays to v5.15.y I remember
> > > > > trying to backport this patch on v5.15.y but there were some merge conflicts
> > > > > there.
> > > > > 
> > > > > 06aa6eff7b smb3: Replace smb2pdu 1-element arrays with flex-arrays
> > > > 
> > > > While I'm not eligible to say what should be done, my understading is
> > > > that Greg probably would prefer to have the "backport 06aa6eff7b"
> > > > version. What we know is that having now both commits in the
> > > > stable-rc/linux-5.10.y queue breaks  cifs and the backport variants
> > > > seens to work fine (Paulo Alcantara probably though can comment best).
> > > > 
> > > Having both one-liner fix that I have sent and the above commit isn't
> > > correct.
> > > 
> > > > As 06aa6eff7b smb3: Replace smb2pdu 1-element arrays with flex-arrays
> > > > was backportable to 5.10.y it should now work as well for the upper
> > > > one 5.15.y.
> > > 
> > > Correct, I agree. I had to send one-liner fix as we have the
> > > backport("06aa6eff7b smb3: Replace smb2pdu 1-element arrays with
> > > flex-arrays") missing in 5.15.y and when I tried backporting it to 5.15.y I
> > > saw many conflicts.
> > > 
> > > If we have backport for 5.15.y similar to 5.10.y we could ask greg to remove
> > > one liner fix from both 5.10.y and 5.15.y: https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git/tree/queue-5.10/cifs-fix-off-by-one-in-smb2_query_info_init.patch
> > 
> > Someone needs to tell me what to do, as I'm lost.
> > 
> 
> For 5.15.y:
> 
> 1. Remove this patch from the queue:
> https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git/tree/queue-5.15/cifs-fix-off-by-one-in-smb2_query_info_init.patch
> 2. Add this patch(kovalev's backport) to queue:
> https://lore.kernel.org/lkml/20240206161111.454699-1-kovalev@altlinux.org/T/#u

Now done.

> For 5.10.y:
> 
> 1. Remove this patch from the queue:
> https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git/tree/queue-5.10/cifs-fix-off-by-one-in-smb2_query_info_init.patch
> 
> (kovalev's backport is already in queue[1], so nothing to add here like '2'
> in 5.15.y)

Now done.

Ok, I think we are good.  I'll push out -rc kernels soon for people to
test with.

thanks,

greg k-h

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

[Linux regression tracking #update (Thorsten Leemhuis)]

On 26.01.24 20:13, SeongJae Park wrote:
> On Mon, 15 Jan 2024 14:22:39 +0000 "Mohamed Abuelfotoh, Hazem" <abuehaze@amazon.com> wrote:
> 
>> It looks like both 5.15.146 and 5.10.206 are impacted by this regression as
>> they both have the bad commit 33eae65c6f (smb: client: fix OOB in
>> SMB2_query_info_init()).
> 
> Let me try to tell this to the regression tracking bot, following the doc[1].
> This is my first time using #regzbot, so please feel free to correct me if I'm
> doing something wrong.
> 
> #regzbot introduced: 33eae65c6f

Thx. Took a while (among others because the stable team worked a bit
slower that usual), but from what Paulo Alcantara and Salvatore
Bonaccorso recently said everything is afaics now fixed or on track to
be fixed in all affected stable/longterm branches:
https://lore.kernel.org/all/ZdgyEfNsev8WGIl5@eldamar.lan/

If I got this wrong and that's not the case, please holler.

#regzbot resolve: apparently fixed in all affected stable/longterm
branches with various commits
#regzbot ignore-activity

Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
--
Everything you wanna know about Linux kernel regression tracking:
https://linux-regtracking.leemhuis.info/about/#tldr
That page also explains what to do if mails like this annoy you.

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

[Mohamed Abuelfotoh, Hazem]

On 23/02/2024 06:14, Linux regression tracking #update (Thorsten 
Leemhuis) wrote:
> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.
> 
> 

> Thx. Took a while (among others because the stable team worked a bit
> slower that usual), but from what Paulo Alcantara and Salvatore
> Bonaccorso recently said everything is afaics now fixed or on track to
> be fixed in all affected stable/longterm branches:
> https://lore.kernel.org/all/ZdgyEfNsev8WGIl5@eldamar.lan/
> 
> If I got this wrong and that's not the case, please holler.
> 
> #regzbot resolve: apparently fixed in all affected stable/longterm
> branches with various commits
> #regzbot ignore-activity
> 
> Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
> --
> Everything you wanna know about Linux kernel regression tracking:
> https://linux-regtracking.leemhuis.info/about/#tldr
> That page also explains what to do if mails like this annoy you.
> 
> 

We are seeing CIFS mount failures after upgrading from v5.15.148 to 
v5.15.149, I have reverted eb3e28c1e8 ("smb3: Replace smb2pdu 1-element 
arrays with flex-arrays") and I no longer see the regression. It looks 
like the issue is also impacting v5.10.y as the mentioned reverted patch 
has also been merged to v5.10.210. I am currently running the CIFS mount 
test manually and will update the thread with the exact mount failure 
error. I think we should revert eb3e28c1e8 ("smb3: Replace smb2pdu 
1-element arrays with flex-arrays") from both v5.15.y & v5.10.y until we 
come up with a proper fix on this versions, please note that if we will 
take this path then we will need to re-introduce. b3632baa5045 ("cifs: 
fix off-by-one in SMB2_query_info_init()") which has been removed from 
latest v5.10.y and v5.15.y releases.

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

[Linux regression tracking (Thorsten Leemhuis)]

[CCing a few people that afaics were involved in trying to fix the CIFS
problems on 5.15/5.10 (to be honest I lost a bit track of that
situation; sorry if I added too many people; at the same time I hope I
did not forget anyone...)]

Anyway: it seems 5.15.149 created a new CIFS problem, see the quoted
mail below for details. Ciao, Thorsten

On 26.02.24 15:28, Mohamed Abuelfotoh, Hazem wrote:
> On 23/02/2024 06:14, Linux regression tracking #update (Thorsten
> Leemhuis) wrote:
>
>> Thx. Took a while (among others because the stable team worked a bit
>> slower that usual), but from what Paulo Alcantara and Salvatore
>> Bonaccorso recently said everything is afaics now fixed or on track to
>> be fixed in all affected stable/longterm branches:
>> https://lore.kernel.org/all/ZdgyEfNsev8WGIl5@eldamar.lan/
>>
>> If I got this wrong and that's not the case, please holler.
> 
> We are seeing CIFS mount failures after upgrading from v5.15.148 to
> v5.15.149, I have reverted eb3e28c1e8 ("smb3: Replace smb2pdu 1-element
> arrays with flex-arrays") and I no longer see the regression. It looks
> like the issue is also impacting v5.10.y as the mentioned reverted patch
> has also been merged to v5.10.210. I am currently running the CIFS mount
> test manually and will update the thread with the exact mount failure
> error. I think we should revert eb3e28c1e8 ("smb3: Replace smb2pdu
> 1-element arrays with flex-arrays") from both v5.15.y & v5.10.y until we
> come up with a proper fix on this versions, please note that if we will
> take this path then we will need to re-introduce. b3632baa5045 ("cifs:
> fix off-by-one in SMB2_query_info_init()") which has been removed from
> latest v5.10.y and v5.15.y releases.

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

[gregkh]

On Mon, Feb 26, 2024 at 02:28:41PM +0000, Mohamed Abuelfotoh, Hazem wrote:
> On 23/02/2024 06:14, Linux regression tracking #update (Thorsten Leemhuis)
> wrote:
> > CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.
> > 
> > 
> 
> > Thx. Took a while (among others because the stable team worked a bit
> > slower that usual), but from what Paulo Alcantara and Salvatore
> > Bonaccorso recently said everything is afaics now fixed or on track to
> > be fixed in all affected stable/longterm branches:
> > https://lore.kernel.org/all/ZdgyEfNsev8WGIl5@eldamar.lan/
> > 
> > If I got this wrong and that's not the case, please holler.
> > 
> > #regzbot resolve: apparently fixed in all affected stable/longterm
> > branches with various commits
> > #regzbot ignore-activity
> > 
> > Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
> > --
> > Everything you wanna know about Linux kernel regression tracking:
> > https://linux-regtracking.leemhuis.info/about/#tldr
> > That page also explains what to do if mails like this annoy you.
> > 
> > 
> 
> We are seeing CIFS mount failures after upgrading from v5.15.148 to
> v5.15.149, I have reverted eb3e28c1e8 ("smb3: Replace smb2pdu 1-element
> arrays with flex-arrays") and I no longer see the regression. It looks like
> the issue is also impacting v5.10.y as the mentioned reverted patch has also
> been merged to v5.10.210. I am currently running the CIFS mount test
> manually and will update the thread with the exact mount failure error. I
> think we should revert eb3e28c1e8 ("smb3: Replace smb2pdu 1-element arrays
> with flex-arrays") from both v5.15.y & v5.10.y until we come up with a
> proper fix on this versions, please note that if we will take this path then
> we will need to re-introduce. b3632baa5045 ("cifs: fix off-by-one in
> SMB2_query_info_init()") which has been removed from latest v5.10.y and
> v5.15.y releases.
> 
> 

Please send this as a patch series, in a new thread, so we can properly
track this, we have too many different threads here (and the subject
line is wrong...)

thanks,

greg k-h

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

[Mohamed Abuelfotoh, Hazem]

On 26/02/2024 14:55, gregkh@linuxfoundation.org wrote:

> 
> Please send this as a patch series, in a new thread, so we can properly
> track this, we have too many different threads here (and the subject
> line is wrong...)
> 
> thanks,
> 
> greg k-h

Thanks Greg and apologize for the noise, I figured out that this has 
something to do with our test environment setup. I have redone the test 
manually and a looks good so I'd say we can close this thread for now :)

Hazem

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

[Salvatore Bonaccorso]

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

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

[Paulo Alcantara]

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.

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

[Greg Kroah-Hartman]

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?

thanks,

greg k-h

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

[Salvatore Bonaccorso]

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).

Paulo can you please give Greg an authoratitative set of commits to
keep/apply in the 5.10.y and 5.15.y series.

Regards,
Salvatore

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

[Greg Kroah-Hartman]

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,

greg k-h

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

[Salvatore Bonaccorso]

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

Regards,
Salvatore

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

[Salvatore Bonaccorso]

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?

Regards,
Salvatore

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

[Paulo Alcantara]

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!

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

[Greg Kroah-Hartman]

On Mon, Jan 08, 2024 at 11:52:45AM -0300, Paulo Alcantara wrote:
> Hi Jan,
> 
> Thanks for the report.
> 
> So this bug is related to an off-by-one in smb2_set_next_command() when
> the client attempts to pad SMB2_QUERY_INFO request -- since it isn't 8 byte
> aligned -- even though smb2_query_info_compound() doesn't provide an extra
> iov for such padding.
> 
> v6.1.y doesn't have
> 
>         eb3e28c1e89b ("smb3: Replace smb2pdu 1-element arrays with flex-arrays")
> 
> and the commit does
> 
> 	+	if (unlikely(check_add_overflow(input_len, sizeof(*req), &len) ||
> 	+		     len > CIFSMaxBufSize))
> 	+		return -EINVAL;
> 	+
> 
> so sizeof(*req) will wrongly include the extra byte from
> smb2_query_info_req::Buffer making @len unaligned and therefore causing
> OOB in smb2_set_next_command().
> 
> A simple fix for that would be
> 
> 	diff --git a/fs/smb/client/smb2pdu.c b/fs/smb/client/smb2pdu.c
> 	index 05ff8a457a3d..aed5067661de 100644
> 	--- a/fs/smb/client/smb2pdu.c
> 	+++ b/fs/smb/client/smb2pdu.c
> 	@@ -3556,7 +3556,7 @@ SMB2_query_info_init(struct cifs_tcon *tcon, struct TCP_Server_Info *server,
> 	 
> 	 	iov[0].iov_base = (char *)req;
> 	 	/* 1 for Buffer */
> 	-	iov[0].iov_len = len;
> 	+	iov[0].iov_len = len - 1;
> 	 	return 0;
> 	 }
> 

Why can't we just include eb3e28c1e89b ("smb3: Replace smb2pdu 1-element
arrays with flex-arrays") to resolve this?

I've queued it up now.

thanks,

greg k-h

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

[Paulo Alcantara]

Hi Jan,

Thanks for the report.

So this bug is related to an off-by-one in smb2_set_next_command() when
the client attempts to pad SMB2_QUERY_INFO request -- since it isn't 8 byte
aligned -- even though smb2_query_info_compound() doesn't provide an extra
iov for such padding.

v6.1.y doesn't have

        eb3e28c1e89b ("smb3: Replace smb2pdu 1-element arrays with flex-arrays")

and the commit does

	+	if (unlikely(check_add_overflow(input_len, sizeof(*req), &len) ||
	+		     len > CIFSMaxBufSize))
	+		return -EINVAL;
	+

so sizeof(*req) will wrongly include the extra byte from
smb2_query_info_req::Buffer making @len unaligned and therefore causing
OOB in smb2_set_next_command().

A simple fix for that would be

	diff --git a/fs/smb/client/smb2pdu.c b/fs/smb/client/smb2pdu.c
	index 05ff8a457a3d..aed5067661de 100644
	--- a/fs/smb/client/smb2pdu.c
	+++ b/fs/smb/client/smb2pdu.c
	@@ -3556,7 +3556,7 @@ SMB2_query_info_init(struct cifs_tcon *tcon, struct TCP_Server_Info *server,
	 
	 	iov[0].iov_base = (char *)req;
	 	/* 1 for Buffer */
	-	iov[0].iov_len = len;
	+	iov[0].iov_len = len - 1;
	 	return 0;
	 }

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

[Leonardo Brondani Schenkel]

On 2024-01-08 15:13, Greg KH wrote:
> That's interesting, there's a different cifs report that says a
> different commit was the issue:
> 	https://lore.kernel.org/r/ZZhrpNJ3zxMR8wcU@eldamar.lan
> 
> is that the same as this one?

It looks like a different issue. The linked report claims that the 
problem was introduced in 6.1.69 by a different commit, but both
Jan Čermák and I don't experience anything wrong with 6.1.69. Jan Čermák 
found commit bef4315f19ba6f434054f58b958c0cf058c7a43f via bisection and 
compiled a kernel that reverts it, and the problem stopped manifesting.

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

[Jan Čermák]

Hi Greg

On 08. 01. 24 15:13, Greg KH wrote:
> That's interesting, there's a different cifs report that says a
> different commit was the issue:
> 	https://lore.kernel.org/r/ZZhrpNJ3zxMR8wcU@eldamar.lan
> 
> is that the same as this one?
> 

It seems to be a different issue. The one reported here by Leonardo 
doesn't trigger NULL pointer dereference and seems to be related to stat 
calls only, for which the CIFS client code in kernel just returns EAGAIN 
every time. The only related kernel buffer logs (example taken from the 
GH issue linked in my previous message) are these:

Jan 05 16:50:27 ha-ct kernel: CIFS: VFS: reconnect tcon failed rc = -11
Jan 05 16:50:30 ha-ct kernel: CIFS: VFS: \\192.168.98.2 Send error in 
SessSetup = -11

If I understand it correctly, the issue you linked has both a different 
trigger and outcome.

Cheers,
Jan

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

[Greg KH]

On Mon, Jan 08, 2024 at 12:18:26PM +0100, Jan Čermák wrote:
> Hi,
> 
> I confirm Leonardo's findings about 6.1.70 introducing this regression, this
> issue manifested in Home Assistant OS [1] which was recently bumped to that
> version. I bisected the issue between 6.1.69 and 6.1.70 which pointed me to
> this bad commit:
> 
> ----
> commit bef4315f19ba6f434054f58b958c0cf058c7a43f (refs/bisect/bad)
> Author: Paulo Alcantara <pc@manguebit.com>
> Date:   Wed Dec 13 12:25:57 2023 -0300
> 
>     smb: client: fix OOB in SMB2_query_info_init()
> 
>     commit 33eae65c6f49770fec7a662935d4eb4a6406d24b upstream.
> 
>     A small CIFS buffer (448 bytes) isn't big enough to hold
>     SMB2_QUERY_INFO request along with user's input data from
>     CIFS_QUERY_INFO ioctl.  That is, if the user passed an input buffer >
>     344 bytes, the client will memcpy() off the end of @req->Buffer in
>     SMB2_query_info_init() thus causing the following KASAN splat:
> 
> (snip...)
> ----
> 
> Reverting this change on 6.1.y makes the error go away.

That's interesting, there's a different cifs report that says a
different commit was the issue:
	https://lore.kernel.org/r/ZZhrpNJ3zxMR8wcU@eldamar.lan

is that the same as this one?

thanks,

greg k-h

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

[Jan Čermák]

Hi,

I confirm Leonardo's findings about 6.1.70 introducing this regression, 
this issue manifested in Home Assistant OS [1] which was recently bumped 
to that version. I bisected the issue between 6.1.69 and 6.1.70 which 
pointed me to this bad commit:

----
commit bef4315f19ba6f434054f58b958c0cf058c7a43f (refs/bisect/bad)
Author: Paulo Alcantara <pc@manguebit.com>
Date:   Wed Dec 13 12:25:57 2023 -0300

     smb: client: fix OOB in SMB2_query_info_init()

     commit 33eae65c6f49770fec7a662935d4eb4a6406d24b upstream.

     A small CIFS buffer (448 bytes) isn't big enough to hold
     SMB2_QUERY_INFO request along with user's input data from
     CIFS_QUERY_INFO ioctl.  That is, if the user passed an input buffer >
     344 bytes, the client will memcpy() off the end of @req->Buffer in
     SMB2_query_info_init() thus causing the following KASAN splat:

(snip...)
----

Reverting this change on 6.1.y makes the error go away.

Adding linux-cifs and Paolo to CC.

Cheers,
Jan


[1] https://github.com/home-assistant/operating-system/issues/3041


On 08. 01. 24 11:44, Leonardo Brondani Schenkel wrote:
> I'm new here, first time reporting a regression, apologies in advance if 
> I'm doing something wrong of if this was already reported (I found some 
> CIFS issues but not exactly this one).
> 
> I'm using x86-64 Arch Linux and LTS kernel (6.1.71 as I write this) and 
> I noticed a regression that I could reproduce in other boxes with other 
> architectures as well (aarch64 with 6.1.70).
> 
> # mount.cifs //server/share /mnt
> # mount
> //server/share on /mnt type cifs (rw,relatime,vers=3.1.1...)
> # cd /mnt
> # df .
> df: .: Resource temporarily unavailable
> # ls -al
> ls: .: Resource temporarily unavailable
> ls: file1: Resource temporarily unavailable
> ls: file2: Resource temporarily unavailable
> [...then ls shows the listing...]
> 
> If I use strace with df, the problem is:
> statfs(".", 0x.....) = -1 EAGAIN (Resource temporarily unavailable)
> 
> And with ls:
> listxattr(".", 0x..., 152): -1 EAGAIN (Resource temporarily unavailable)
> listxattr("file1", ..., 152): -1 EAGAIN (same as above)
> ...
> 
> Initially I thought the problem was with the Samba server and/or the 
> client mount flags, but I've spent a day trying a *lot* of different 
> combinations and nothing worked. This happens with any share that I try, 
> and I've tried mounting shares from multiple Linux boxes running 
> different Samba and kernel versions.
> 
> Then I tried changing kernel versions at my client box. I booted latest 
> 6.6.9 and the problem simply disappeared. My Debian server with 6.5.11 
> also doesn't have it. I then started a VM and tried a "bisection" of 
> 6.1.x versions, leading to kernel 6.1.70 when this started to happen.
> 6.1.69 and older look fine.
> 
> I hope that this is enough information to reproduce this issue. I will 
> be glad to provide more info if necessary.
> 
> // Leonardo.
>