[PATCH AUTOSEL 5.15 10/39] net/smc: Transfer remaining wait queue entries during fallback

[PATCH AUTOSEL 5.15 10/39] net/smc: Transfer remaining wait queue entries during fallback

[Sasha Levin]

From: Wen Gu <guwen@linux.alibaba.com>

[ Upstream commit 2153bd1e3d3dbf6a3403572084ef6ed31c53c5f0 ]

The SMC fallback is incomplete currently. There may be some
wait queue entries remaining in smc socket->wq, which should
be removed to clcsocket->wq during the fallback.

For example, in nginx/wrk benchmark, this issue causes an
all-zeros test result:

server: nginx -g 'daemon off;'
client: smc_run wrk -c 1 -t 1 -d 5 http://11.200.15.93/index.html

  Running 5s test @ http://11.200.15.93/index.html
     1 threads and 1 connections
     Thread Stats   Avg      Stdev     Max   ± Stdev
     	Latency     0.00us    0.00us   0.00us    -nan%
	Req/Sec     0.00      0.00     0.00      -nan%
	0 requests in 5.00s, 0.00B read
     Requests/sec:      0.00
     Transfer/sec:       0.00B

The reason for this all-zeros result is that when wrk used SMC
to replace TCP, it added an eppoll_entry into smc socket->wq
and expected to be notified if epoll events like EPOLL_IN/
EPOLL_OUT occurred on the smc socket.

However, once a fallback occurred, wrk switches to use clcsocket.
Now it is clcsocket->wq instead of smc socket->wq which will
be woken up. The eppoll_entry remaining in smc socket->wq does
not work anymore and wrk stops the test.

This patch fixes this issue by removing remaining wait queue
entries from smc socket->wq to clcsocket->wq during the fallback.

Link: https://www.spinics.net/lists/netdev/msg779769.html
Signed-off-by: Wen Gu <guwen@linux.alibaba.com>
Reviewed-by: Tony Lu <tonylu@linux.alibaba.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
 net/smc/af_smc.c | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/net/smc/af_smc.c b/net/smc/af_smc.c
index 32c1c7ce856d3..c6df2245c9a40 100644
--- a/net/smc/af_smc.c
+++ b/net/smc/af_smc.c
@@ -548,6 +548,10 @@ static void smc_stat_fallback(struct smc_sock *smc)
 
 static void smc_switch_to_fallback(struct smc_sock *smc, int reason_code)
 {
+	wait_queue_head_t *smc_wait = sk_sleep(&smc->sk);
+	wait_queue_head_t *clc_wait = sk_sleep(smc->clcsock->sk);
+	unsigned long flags;
+
 	smc->use_fallback = true;
 	smc->fallback_rsn = reason_code;
 	smc_stat_fallback(smc);
@@ -556,6 +560,16 @@ static void smc_switch_to_fallback(struct smc_sock *smc, int reason_code)
 		smc->clcsock->file->private_data = smc->clcsock;
 		smc->clcsock->wq.fasync_list =
 			smc->sk.sk_socket->wq.fasync_list;
+
+		/* There may be some entries remaining in
+		 * smc socket->wq, which should be removed
+		 * to clcsocket->wq during the fallback.
+		 */
+		spin_lock_irqsave(&smc_wait->lock, flags);
+		spin_lock(&clc_wait->lock);
+		list_splice_init(&smc_wait->head, &clc_wait->head);
+		spin_unlock(&clc_wait->lock);
+		spin_unlock_irqrestore(&smc_wait->lock, flags);
 	}
 }
 
-- 
2.33.0

[PATCH AUTOSEL 5.15 18/39] s390/setup: avoid using memblock_enforce_memory_limit

[Sasha Levin]

From: Vasily Gorbik <gor@linux.ibm.com>

[ Upstream commit 5dbc4cb4667457b0c53bcd7bff11500b3c362975 ]

There is a difference in how architectures treat "mem=" option. For some
that is an amount of online memory, for s390 and x86 this is the limiting
max address. Some memblock api like memblock_enforce_memory_limit()
take limit argument and explicitly treat it as the size of online memory,
and use __find_max_addr to convert it to an actual max address. Current
s390 usage:

memblock_enforce_memory_limit(memblock_end_of_DRAM());

yields different results depending on presence of memory holes (offline
memory blocks in between online memory). If there are no memory holes
limit == max_addr in memblock_enforce_memory_limit() and it does trim
online memory and reserved memory regions. With memory holes present it
actually does nothing.

Since we already use memblock_remove() explicitly to trim online memory
regions to potential limit (think mem=, kdump, addressing limits, etc.)
drop the usage of memblock_enforce_memory_limit() altogether. Trimming
reserved regions should not be required, since we now use
memblock_set_current_limit() to limit allocations and any explicit memory
reservations above the limit is an actual problem we should not hide.

Reviewed-by: Heiko Carstens <hca@linux.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
 arch/s390/kernel/setup.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/arch/s390/kernel/setup.c b/arch/s390/kernel/setup.c
index 67e5fff96ee06..c4d813ae51a8f 100644
--- a/arch/s390/kernel/setup.c
+++ b/arch/s390/kernel/setup.c
@@ -824,9 +824,6 @@ static void __init setup_memory(void)
 		storage_key_init_range(start, end);
 
 	psw_set_key(PAGE_DEFAULT_KEY);
-
-	/* Only cosmetics */
-	memblock_enforce_memory_limit(memblock_end_of_DRAM());
 }
 
 static void __init relocate_amode31_section(void)
-- 
2.33.0

Re: [PATCH AUTOSEL 5.15 10/39] net/smc: Transfer remaining wait queue entries during fallback

[Jakub Kicinski]

On Thu, 25 Nov 2021 21:31:27 -0500 Sasha Levin wrote:
> From: Wen Gu <guwen@linux.alibaba.com>
> 
> [ Upstream commit 2153bd1e3d3dbf6a3403572084ef6ed31c53c5f0 ]
> 
> The SMC fallback is incomplete currently. There may be some
> wait queue entries remaining in smc socket->wq, which should
> be removed to clcsocket->wq during the fallback.
> 
> For example, in nginx/wrk benchmark, this issue causes an
> all-zeros test result:

Hold this one, please, there is a fix coming: 7a61432dc813 ("net/smc:
Avoid warning of possible recursive locking").

Re: [PATCH AUTOSEL 5.15 10/39] net/smc: Transfer remaining wait queue entries during fallback

[Sasha Levin]

On Thu, Nov 25, 2021 at 06:51:39PM -0800, Jakub Kicinski wrote:
>On Thu, 25 Nov 2021 21:31:27 -0500 Sasha Levin wrote:
>> From: Wen Gu <guwen@linux.alibaba.com>
>>
>> [ Upstream commit 2153bd1e3d3dbf6a3403572084ef6ed31c53c5f0 ]
>>
>> The SMC fallback is incomplete currently. There may be some
>> wait queue entries remaining in smc socket->wq, which should
>> be removed to clcsocket->wq during the fallback.
>>
>> For example, in nginx/wrk benchmark, this issue causes an
>> all-zeros test result:
>
>Hold this one, please, there is a fix coming: 7a61432dc813 ("net/smc:
>Avoid warning of possible recursive locking").

I'll grab that one too, thanks!

-- 
Thanks,
Sasha