Received-SPF: pass (google.com: domain of linux-kernel+bounces-120040-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) client-ip=2604:1380:40f1:3f00::1;
Date: Tue, 26 Mar 2024 23:21:34 +0100
From: Borislav Petkov <bp@alien8.de>
To: a-development@posteo.de
Cc: x86@kernel.org, linux-kernel@vger.kernel.org, peterz@infradead.org,
	David.Kaplan@amd.com, Andrew.Cooper3@citrix.com,
	jpoimboe@kernel.org, gregkh@linuxfoundation.org
Subject: Re: [RFC][PATCH 00/17] Fix up the recent SRSO patches
Message-ID: <20240326222134.GNZgNKbgdBUsAU98RV@fat_crate.local>
References: <cbad6acb30e33e8dd387080e5936cc38@posteo.net>
 <20240127191942.GEZbVXTtDNzLB9hTpr@fat_crate.local>
 <181005cf4a78a4c3c5e1de77498f6c23@posteo.net>
 <20240127194139.GFZbVcc2RxhNtO3ZHD@fat_crate.local>
 <6170a3f60cd1ca68bca5829db4a8568a@posteo.net>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <6170a3f60cd1ca68bca5829db4a8568a@posteo.net>

Whoops, 

this fell through the cracks. Sorry about that.

On Mon, Jan 29, 2024 at 06:18:00PM +0000, a-development@posteo.de wrote:
> I have the feeling that something else is amiss.
> Currently under 6.7.2-2-cachyos with srso=off.
> https://0x0.st/HDqP.txt

Yah, your tasks refuse to freeze on suspend and they have this fuse
stuff in the stacktrace:

[ 6346.492593] task:btop            state:D stack:0     pid:279617 tgid:1548  ppid:1531   flags:0x00004006
[ 6346.492600] Call Trace:
[ 6346.492602]  <TASK>
[ 6346.492607]  __schedule+0xd44/0x1af0
[ 6346.492614]  ? srso_alias_return_thunk+0x5/0xfbef5
[ 6346.492617]  ? __wake_up+0x9d/0xc0
[ 6346.492622]  schedule+0x32/0xd0
[ 6346.492627]  request_wait_answer+0xd0/0x2a0 [fuse db37c699d94393e946cf93306449ea0f307959a1]
[ 6346.492638]  ? __pfx_autoremove_wake_function+0x10/0x10
[ 6346.492643]  fuse_simple_request+0x21c/0x390 [fuse db37c699d94393e946cf93306449ea0f307959a1]
[ 6346.492653]  fuse_statfs+0xf2/0x160 [fuse db37c699d94393e946cf93306449ea0f307959a1]
[ 6346.492667]  statfs_by_dentry+0x67/0x90

> 
> Now I feel, further communication is rather selfish, as a clean environment
> is hard to provide.
> In any case, my FUSE arguments are sshfs -o kernel_cache -o auto_cache -o
> reconnect \
>                -o compression=yes -o cache_timeout=600 -o
> ServerAliveInterval=30 \
>                "$source" "$target" -o idmap=user
> 
> With this line, I somehow managed to have the FUSE mount infinitely mounted,
> even if the device was offline for couple of days.
> A followed suspend would fail to freeze.
> srso=off would reproducibly work.

Not in your example above. It would fail after a couple of suspend
cycles.

And looking at your splats

[ 6366.524953]  ? switch_fpu_return+0x50/0xe0
[ 6366.524956]  ? srso_alias_return_thunk+0x5/0xfbef5
		  ^^^^^^^^^^^^^^^^^^^^^^^^
[ 6366.524958]  ? exit_to_user_mode_prepare+0x132/0x1f

the right cmdline option to disable it is:

spec_rstack_overflow=off

not

srso=off

:-)

> Please provide me a specific version of a kernel I should try in my
> configuration to try and reproduce.
> I'd prefer a pre-compiled one; if not tell me...
> I use archlinux.

Just build the latest released kernel, which is 6.8 now. Take your
config and use it to build it. The net is full of tutorials how to do
so.

And then try with spec_rstack_overflow=off and let's see what that does.

> Please give me a reason to not feel bad about myself.

Don't worry - it's just a machine. :)

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette