From houmie at gmail.com  Wed Jun  1 07:42:44 2022
From: houmie at gmail.com (Houman)
Date: Wed, 1 Jun 2022 08:42:44 +0100
Subject: How to improve Wireguard speed?
Message-ID: <CABBZOs=CRGXaYmajx6GLJMU0sxZbda=qDgKsiB_KM_k3DygCJg@mail.gmail.com>

Hello,

I'm compiling the latest stable Wireguard on Debian 11.

git clone https://git.zx2c4.com/wireguard-tools
make -C wireguard-tools/src -j$(nproc)
sudo make -C wireguard-tools/src install

However the speed is not that impressive.  I have a VPS with 4 vCores
and 8 GB RAM on 1 Gbps network.  The VPS is located in London and so
am I.

With wireguard enabled I get 117 Mbps
Without wireguard I get 506 Mbps

That's a drop of 75%. What are the factors to improve the download rate?

Thank you,

From icepic.dz at gmail.com  Wed Jun  1 08:50:48 2022
From: icepic.dz at gmail.com (Janne Johansson)
Date: Wed, 1 Jun 2022 10:50:48 +0200
Subject: How to improve Wireguard speed?
In-Reply-To: <CABBZOs=CRGXaYmajx6GLJMU0sxZbda=qDgKsiB_KM_k3DygCJg@mail.gmail.com>
References: <CABBZOs=CRGXaYmajx6GLJMU0sxZbda=qDgKsiB_KM_k3DygCJg@mail.gmail.com>
Message-ID: <CAA6-MF84eCwegH3UcQuqrL7YaCQULf5=KafQYZPVJWATEtfL0Q@mail.gmail.com>

Den ons 1 juni 2022 kl 09:49 skrev Houman <houmie at gmail.com>:
> Hello,
> I'm compiling the latest stable Wireguard on Debian 11.
> git clone https://git.zx2c4.com/wireguard-tools
> make -C wireguard-tools/src -j$(nproc)
> sudo make -C wireguard-tools/src install
>
> However the speed is not that impressive.  I have a VPS with 4 vCores
> and 8 GB RAM on 1 Gbps network.  The VPS is located in London and so
> am I.
>
> With wireguard enabled I get 117 Mbps
> Without wireguard I get 506 Mbps
>
> That's a drop of 75%. What are the factors to improve the download rate?

That seems like very poor values, I would make two tests, one local to
the VPS and one test local to the other end (which you left out of the
description) and see which one is the limiting box. People (including
me) have easily gotten speeds at 1-2 gigabit on 10GE networked
computers and VPSes and several gigabits on loopbacks, so the fault is
not simply using wireguard.

If you check the results of the nightly builds for x86_64 at
https://www.wireguard.com/build-status/ you find several iperf3 runs
that end up over 2-3 Gbit/s when a box is talking "to itself" so it's
not the crypto or the tunnel that prevents you from filling up the
gigabit link. Perhaps the VPS isn't giving you a lot of cpu? Perhaps
the test reacts poorly to the lowered MTU for using (any) tunnel in
between?

-- 
May the most significant bit of your life be positive.

From houmie at gmail.com  Wed Jun  1 09:07:31 2022
From: houmie at gmail.com (Houman)
Date: Wed, 1 Jun 2022 10:07:31 +0100
Subject: How to improve Wireguard speed?
In-Reply-To: <CAA6-MF84eCwegH3UcQuqrL7YaCQULf5=KafQYZPVJWATEtfL0Q@mail.gmail.com>
References: <CABBZOs=CRGXaYmajx6GLJMU0sxZbda=qDgKsiB_KM_k3DygCJg@mail.gmail.com>
 <CAA6-MF84eCwegH3UcQuqrL7YaCQULf5=KafQYZPVJWATEtfL0Q@mail.gmail.com>
Message-ID: <CABBZOs=kxe4DwHN=utdb8FzDTt3=TcSo05JVAo=-JCUjC_eEug@mail.gmail.com>

Thanks for your reply.

I have run htop to observe the CPU consumption during this test, and
the CPU(s) go up only to 10-20%. So the CPU doesn't seem to be the
bottleneck.

I didn't change the MTU settings, but I have a suspicion about MTU. I
found this article here that makes some interesting suggestions to set
MTU to 1280: https://keremerkan.net/posts/wireguard-mtu-fixes/

And beyond that iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j
TCPMSS --clamp-mss-to-pmtu





On Wed, 1 Jun 2022 at 09:51, Janne Johansson <icepic.dz at gmail.com> wrote:
>
> Den ons 1 juni 2022 kl 09:49 skrev Houman <houmie at gmail.com>:
> > Hello,
> > I'm compiling the latest stable Wireguard on Debian 11.
> > git clone https://git.zx2c4.com/wireguard-tools
> > make -C wireguard-tools/src -j$(nproc)
> > sudo make -C wireguard-tools/src install
> >
> > However the speed is not that impressive.  I have a VPS with 4 vCores
> > and 8 GB RAM on 1 Gbps network.  The VPS is located in London and so
> > am I.
> >
> > With wireguard enabled I get 117 Mbps
> > Without wireguard I get 506 Mbps
> >
> > That's a drop of 75%. What are the factors to improve the download rate?
>
> That seems like very poor values, I would make two tests, one local to
> the VPS and one test local to the other end (which you left out of the
> description) and see which one is the limiting box. People (including
> me) have easily gotten speeds at 1-2 gigabit on 10GE networked
> computers and VPSes and several gigabits on loopbacks, so the fault is
> not simply using wireguard.
>
> If you check the results of the nightly builds for x86_64 at
> https://www.wireguard.com/build-status/ you find several iperf3 runs
> that end up over 2-3 Gbit/s when a box is talking "to itself" so it's
> not the crypto or the tunnel that prevents you from filling up the
> gigabit link. Perhaps the VPS isn't giving you a lot of cpu? Perhaps
> the test reacts poorly to the lowered MTU for using (any) tunnel in
> between?
>
> --
> May the most significant bit of your life be positive.

From tklauser at distanz.ch  Wed Jun  1 09:33:54 2022
From: tklauser at distanz.ch (Tobias Klauser)
Date: Wed,  1 Jun 2022 11:33:54 +0200
Subject: [PATCH wireguard-go] tun: use ByteSliceToString from
 golang.org/x/sys/unix
Message-ID: <20220601093354.30833-1-tklauser@distanz.ch>

Use unix.ByteSliceToString in (*NativeTun).nameSloce to convert the
TUNGETIFF ioctl result []byte to a string.

Signed-off-by: Tobias Klauser <tklauser at distanz.ch>
---
 tun/tun_linux.go | 7 +------
 1 file changed, 1 insertion(+), 6 deletions(-)

diff --git a/tun/tun_linux.go b/tun/tun_linux.go
index 89b716d9c70b..fbb8585ff449 100644
--- a/tun/tun_linux.go
+++ b/tun/tun_linux.go
@@ -9,7 +9,6 @@ package tun
  */
 
 import (
-	"bytes"
 	"errors"
 	"fmt"
 	"os"
@@ -321,11 +320,7 @@ func (tun *NativeTun) nameSlow() (string, error) {
 	if errno != 0 {
 		return "", fmt.Errorf("failed to get name of TUN device: %w", errno)
 	}
-	name := ifr[:]
-	if i := bytes.IndexByte(name, 0); i != -1 {
-		name = name[:i]
-	}
-	return string(name), nil
+	return unix.ByteSliceToString(ifr[:]), nil
 }
 
 func (tun *NativeTun) Write(buf []byte, offset int) (int, error) {
-- 
2.36.1


From tklauser at distanz.ch  Wed Jun  1 09:36:23 2022
From: tklauser at distanz.ch (Tobias Klauser)
Date: Wed, 1 Jun 2022 11:36:23 +0200
Subject: [PATCH wireguard-go] tun: use ByteSliceToString from
 golang.org/x/sys/unix
In-Reply-To: <20220601093354.30833-1-tklauser@distanz.ch>
References: <20220601093354.30833-1-tklauser@distanz.ch>
Message-ID: <20220601093622.dacco7owtrm6u2y7@distanz.ch>

On 2022-06-01 at 11:33:54 +0200, Tobias Klauser <tklauser at distanz.ch> wrote:
> Use unix.ByteSliceToString in (*NativeTun).nameSloce to convert the
                                             ^- this should say
					     `nameSlow`

I can fix it up in a v2 patch if needed.

From rm at romanrm.net  Wed Jun  1 09:51:43 2022
From: rm at romanrm.net (Roman Mamedov)
Date: Wed, 1 Jun 2022 14:51:43 +0500
Subject: How to improve Wireguard speed?
In-Reply-To: <CABBZOs=kxe4DwHN=utdb8FzDTt3=TcSo05JVAo=-JCUjC_eEug@mail.gmail.com>
References: <CABBZOs=CRGXaYmajx6GLJMU0sxZbda=qDgKsiB_KM_k3DygCJg@mail.gmail.com>
 <CAA6-MF84eCwegH3UcQuqrL7YaCQULf5=KafQYZPVJWATEtfL0Q@mail.gmail.com>
 <CABBZOs=kxe4DwHN=utdb8FzDTt3=TcSo05JVAo=-JCUjC_eEug@mail.gmail.com>
Message-ID: <20220601145143.75234bd8@nvm>

On Wed, 1 Jun 2022 10:07:31 +0100
Houman <houmie at gmail.com> wrote:

> I didn't change the MTU settings, but I have a suspicion about MTU. I
> found this article here that makes some interesting suggestions to set
> MTU to 1280: https://keremerkan.net/posts/wireguard-mtu-fixes/
> 
> And beyond that iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j
> TCPMSS --clamp-mss-to-pmtu

So did you apply both of that, and what was the effect?

What are the other point that you test against, is it another VPS (better if
you could try with that), or your home connection?

It could be your home provider has different speed limits (shaping) in place
for UDP. Should be possible to test this with:

  iperf3 -s                        # on VPS

  iperf3 -u -b 500M -c <VPS IP> -R # on the other side

And then see how many "Lost/Total Datagrams" (xx %) you get. A high percentage
would indicate that the actual top speed for UDP is less than 500Mbit by this
value.

-- 
With respect,
Roman

From houmie at gmail.com  Wed Jun  1 11:40:46 2022
From: houmie at gmail.com (Houman)
Date: Wed, 1 Jun 2022 12:40:46 +0100
Subject: How to improve Wireguard speed?
In-Reply-To: <20220601145143.75234bd8@nvm>
References: <CABBZOs=CRGXaYmajx6GLJMU0sxZbda=qDgKsiB_KM_k3DygCJg@mail.gmail.com>
 <CAA6-MF84eCwegH3UcQuqrL7YaCQULf5=KafQYZPVJWATEtfL0Q@mail.gmail.com>
 <CABBZOs=kxe4DwHN=utdb8FzDTt3=TcSo05JVAo=-JCUjC_eEug@mail.gmail.com>
 <20220601145143.75234bd8@nvm>
Message-ID: <CABBZOsmMSnspA6iTCvv0QZLL9KVtGSvt+KPAMqWecOmKubou4Q@mail.gmail.com>

Thanks Roman.

> So did you apply both of that, and what was the effect?

I will create a new environment this afternoon and test the MTU
changes mentioned earlier and investigate the outcome.

> What are the other point that you test against, is it another VPS (better if
> you could try with that), or your home connection?

The iPhone is connected via Wifi to the home network, which is 500 Mbps / fibre.
I have a code snippet on the iPhone that downloads a 1 GB test file
from my AWS bucket (London) for 10 seconds. Then measures
totalBytesWritten / time elapsed / (1024.0 * 1024.0) * 8.0.
Which is the formula for Mbps as far as I am aware.

Client (iPhone) --> server (VPS) --> S3 (AWS) = 117 Mbps
Client (iPhone) --> S3 (AWS) = 506 Mbps

I run this once the Wireguard connection is established and I get 117
Mbps. Then I disconnect the VPN and run the same code again to fetch
the test file without VPN that comes down to 506 Mbps. Client
(iPhone), server (VPS) and S3 (AWS) are all in located London, UK.

I have run your iperf test.  On the VPS the Lost/Total Datagrams is
0%. On the client (Mac) the Lost/Total Datagrams is 0.13%.  This test
proves that the ISP isn't messing around with UDP.

[  5] local 192.168.1.101 port 62103 connected to xxxxx port 5201
[ ID] Interval           Transfer     Bitrate         Jitter
Lost/Total Datagrams
[  5]   0.00-1.00   sec  59.5 MBytes   499 Mbits/sec  0.034 ms  0/44538 (0%)
[  5]   1.00-2.00   sec  59.7 MBytes   500 Mbits/sec  0.012 ms  0/44677 (0%)
[  5]   2.00-3.00   sec  59.3 MBytes   497 Mbits/sec  0.021 ms
15/44400 (0.034%)
[  5]   3.00-4.00   sec  60.0 MBytes   503 Mbits/sec  0.015 ms  0/44913 (0%)
[  5]   4.00-5.00   sec  59.5 MBytes   499 Mbits/sec  0.020 ms  0/44588 (0%)
[  5]   5.00-6.00   sec  59.3 MBytes   498 Mbits/sec  0.018 ms
219/44662 (0.49%)
[  5]   6.00-7.00   sec  59.6 MBytes   500 Mbits/sec  0.065 ms  0/44633 (0%)
[  5]   7.00-8.00   sec  59.6 MBytes   500 Mbits/sec  0.037 ms  0/44614 (0%)
[  5]   8.00-9.00   sec  59.6 MBytes   500 Mbits/sec  0.024 ms  0/44633 (0%)
[  5]   9.00-10.00  sec  59.2 MBytes   497 Mbits/sec  0.024 ms
339/44686 (0.76%)
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Jitter
Lost/Total Datagrams
[  5]   0.00-10.01  sec   596 MBytes   500 Mbits/sec  0.000 ms
0/446756 (0%)  sender
[SUM]  0.0-10.0 sec  657 datagrams received out-of-order
[  5]   0.00-10.00  sec   595 MBytes   499 Mbits/sec  0.024 ms
573/446344 (0.13%)  receiver


For now I'm out of ideas. I will try to play around with MTUs this
afternoon and see what happens.
Thanks,





> It could be your home provider has different speed limits (shaping) in place
> for UDP. Should be possible to test this with:
>
>   iperf3 -s                        # on VPS
>
>   iperf3 -u -b 500M -c <VPS IP> -R # on the other side
>
> And then see how many "Lost/Total Datagrams" (xx %) you get. A high percentage
> would indicate that the actual top speed for UDP is less than 500Mbit by this
> value.
>
> --
> With respect,
> Roman

From frank at carmickle.com  Wed Jun  1 12:41:05 2022
From: frank at carmickle.com (Frank Carmickle)
Date: Wed, 1 Jun 2022 08:41:05 -0400
Subject: How to improve Wireguard speed?
In-Reply-To: <CABBZOsmMSnspA6iTCvv0QZLL9KVtGSvt+KPAMqWecOmKubou4Q@mail.gmail.com>
References: <CABBZOs=CRGXaYmajx6GLJMU0sxZbda=qDgKsiB_KM_k3DygCJg@mail.gmail.com>
 <CAA6-MF84eCwegH3UcQuqrL7YaCQULf5=KafQYZPVJWATEtfL0Q@mail.gmail.com>
 <CABBZOs=kxe4DwHN=utdb8FzDTt3=TcSo05JVAo=-JCUjC_eEug@mail.gmail.com>
 <20220601145143.75234bd8@nvm>
 <CABBZOsmMSnspA6iTCvv0QZLL9KVtGSvt+KPAMqWecOmKubou4Q@mail.gmail.com>
Message-ID: <E410057D-B5FE-466B-9B0D-E9ADA7B48298@carmickle.com>

It's almost certainly the iPhone that's the slow part. The wireguard implementation on iOS is running in userspace.

--FC

> On Jun 1, 2022, at 7:40 AM, Houman <houmie at gmail.com> wrote:
> 
> Thanks Roman.
> 
>> So did you apply both of that, and what was the effect?
> 
> I will create a new environment this afternoon and test the MTU
> changes mentioned earlier and investigate the outcome.
> 
>> What are the other point that you test against, is it another VPS (better if
>> you could try with that), or your home connection?
> 
> The iPhone is connected via Wifi to the home network, which is 500 Mbps / fibre.
> I have a code snippet on the iPhone that downloads a 1 GB test file
> from my AWS bucket (London) for 10 seconds. Then measures
> totalBytesWritten / time elapsed / (1024.0 * 1024.0) * 8.0.
> Which is the formula for Mbps as far as I am aware.
> 
> Client (iPhone) --> server (VPS) --> S3 (AWS) = 117 Mbps
> Client (iPhone) --> S3 (AWS) = 506 Mbps
> 
> I run this once the Wireguard connection is established and I get 117
> Mbps. Then I disconnect the VPN and run the same code again to fetch
> the test file without VPN that comes down to 506 Mbps. Client
> (iPhone), server (VPS) and S3 (AWS) are all in located London, UK.
> 
> I have run your iperf test.  On the VPS the Lost/Total Datagrams is
> 0%. On the client (Mac) the Lost/Total Datagrams is 0.13%.  This test
> proves that the ISP isn't messing around with UDP.
> 
> [  5] local 192.168.1.101 port 62103 connected to xxxxx port 5201
> [ ID] Interval           Transfer     Bitrate         Jitter
> Lost/Total Datagrams
> [  5]   0.00-1.00   sec  59.5 MBytes   499 Mbits/sec  0.034 ms  0/44538 (0%)
> [  5]   1.00-2.00   sec  59.7 MBytes   500 Mbits/sec  0.012 ms  0/44677 (0%)
> [  5]   2.00-3.00   sec  59.3 MBytes   497 Mbits/sec  0.021 ms
> 15/44400 (0.034%)
> [  5]   3.00-4.00   sec  60.0 MBytes   503 Mbits/sec  0.015 ms  0/44913 (0%)
> [  5]   4.00-5.00   sec  59.5 MBytes   499 Mbits/sec  0.020 ms  0/44588 (0%)
> [  5]   5.00-6.00   sec  59.3 MBytes   498 Mbits/sec  0.018 ms
> 219/44662 (0.49%)
> [  5]   6.00-7.00   sec  59.6 MBytes   500 Mbits/sec  0.065 ms  0/44633 (0%)
> [  5]   7.00-8.00   sec  59.6 MBytes   500 Mbits/sec  0.037 ms  0/44614 (0%)
> [  5]   8.00-9.00   sec  59.6 MBytes   500 Mbits/sec  0.024 ms  0/44633 (0%)
> [  5]   9.00-10.00  sec  59.2 MBytes   497 Mbits/sec  0.024 ms
> 339/44686 (0.76%)
> - - - - - - - - - - - - - - - - - - - - - - - - -
> [ ID] Interval           Transfer     Bitrate         Jitter
> Lost/Total Datagrams
> [  5]   0.00-10.01  sec   596 MBytes   500 Mbits/sec  0.000 ms
> 0/446756 (0%)  sender
> [SUM]  0.0-10.0 sec  657 datagrams received out-of-order
> [  5]   0.00-10.00  sec   595 MBytes   499 Mbits/sec  0.024 ms
> 573/446344 (0.13%)  receiver
> 
> 
> For now I'm out of ideas. I will try to play around with MTUs this
> afternoon and see what happens.
> Thanks,
> 
> 
> 
> 
> 
>> It could be your home provider has different speed limits (shaping) in place
>> for UDP. Should be possible to test this with:
>> 
>>  iperf3 -s                        # on VPS
>> 
>>  iperf3 -u -b 500M -c <VPS IP> -R # on the other side
>> 
>> And then see how many "Lost/Total Datagrams" (xx %) you get. A high percentage
>> would indicate that the actual top speed for UDP is less than 500Mbit by this
>> value.
>> 
>> --
>> With respect,
>> Roman


From Jason at zx2c4.com  Wed Jun  1 13:01:37 2022
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Wed, 1 Jun 2022 15:01:37 +0200
Subject: [PATCH wireguard-go] tun: use ByteSliceToString from
 golang.org/x/sys/unix
In-Reply-To: <20220601093354.30833-1-tklauser@distanz.ch>
References: <20220601093354.30833-1-tklauser@distanz.ch>
Message-ID: <CAHmME9pDtghGf7kynMgQbRCZGXnOtQH2Skd49rH0s19Tdd6KLA@mail.gmail.com>

Applied, thanks.

From simon.karberg at agillic.com  Wed Jun  1 18:45:58 2022
From: simon.karberg at agillic.com (Simon Karberg)
Date: Wed, 1 Jun 2022 20:45:58 +0200
Subject: Multiple search domains settings in MacOS based on config file
Message-ID: <CALDyVtsBytM7kdhKz7-mkSreM1h5LennY0==jeB5Ne63fAE+BQ@mail.gmail.com>

Hi,

I can see in my config file under DNS that I have our primary DNS
server ip address and then added search domains with comma list after.
On linux & Windows it seems to be set correctly but it's not being set
through the MacOS client from the app store.

I have tried to look through the source code to identify if the
settings are there for the app but I'm not sure.

I am on MacOS 12.4 (Monterey) in a M1 Max (arm64).
App version: 1.0.15 (26)
Go backend version: 2ef39d47

From max.schulze at online.de  Sun Jun  5 20:21:24 2022
From: max.schulze at online.de (Max Schulze)
Date: Sun, 5 Jun 2022 22:21:24 +0200
Subject: wireguard-windows: possibly wrong selection of outgoing IP Address?
Message-ID: <4bb8fade-487e-2301-65d0-dea41624682f@online.de>

I am running out of ideas to debug this specific issue.

I am trying to circumvent a double-NAT scenario. I have

wg_serv (10.253.2.9) <->  wg-relais (10.253.2.2) <-> wg_peer ( 10.253.2.3)

wg_serv has an endpoint set for wg-relais, and creates the connection ok (handshake completes, ping works).
wg_peer has an endpoint that points to wg-relais, which should tunnel the connection as-is to wg_serv on the established connection ( iptables SNAT/DNAT ).

If wg_serv is a linux box, with the exact same config file, everything works. if wg_serv is a windows box, it seems that there are no outgoing packets, but incoming is ok.

First, see that the handshake packet is received (via 10.253.2.2:60026):

2022-06-05 20:30:17.140946: [TUN] [wireguard] Keypair 536 created for peer 1

2022-06-05 20:30:22.085949: [TUN] [wireguard] Handshake for peer 1 (10.253.2.2:60026) did not complete after 5 seconds, retrying (try 2)

2022-06-05 20:30:22.265787: [TUN] [wireguard] Receiving handshake initiation from peer 1 (10.253.2.2:60026)

2022-06-05 20:30:22.265787: [TUN] [wireguard] Sending handshake response to peer 1 (10.253.2.2:60026)

2022-06-05 20:30:22.267019: [TUN] [wireguard] Keypair 536 destroyed for peer 1

2022-06-05 20:30:22.267019: [TUN] [wireguard] Keypair 537 created for peer 1

2022-06-05 20:30:27.147962: [TUN] [wireguard] Sending keepalive packet to peer 2 (185.230.xxx.yyy:51849)

2022-06-05 20:30:27.626543: [TUN] [wireguard] Receiving handshake initiation from peer 1 (10.253.2.2:60026)

2022-06-05 20:30:27.626543: [TUN] [wireguard] Sending handshake response to peer 1 (10.253.2.2:60026)




However, it seems that wireguard sends the outgoing packet with the wrong ip (192.168.99.101) instead of 10.253.2.9 to 10.253.2.2:60026 ?



    Protocol    Local Port      Local Address   Remote Port Remote Address      Received Bytes  Sent Bytes  Rec Pkt Sent Packets

wireguard.exe   UDP IPv4    51850   192.168.99.101  51849       185.230.xxx.yyy     81.976          8.584   417     216 

wireguard.exe   UDP IPv4    51850   10.253.2.9      60026       10.253.2.2          55.648                  376     

wireguard.exe   UDP IPv4    51850   192.168.99.101  60026       10.253.2.2                          37.848          398 


What can I do?
Can I make the wireguard log more verbose to show IP Paket src/Destination?

Is it possible to also log the src IP of the "handshake response packet"?

Best,
Max


wg_serv config:

[Interface]

PrivateKey = SFhFHVb__2c=

ListenPort = 51850

Address = 10.253.2.9/24



[Peer]

# wg-vpn-relais

PublicKey = 3A5__wo=

AllowedIPs = 10.253.2.2/30

Endpoint = 185.230.xxx.yyy:51849

PersistentKeepalive = 20



[Peer]

# peer via vpn relais

PublicKey = FTBC__cqghg=

AllowedIPs = 10.253.2.3/32

PersistentKeepalive = 20



wg output:

peer: 3A5__o=

  endpoint: 185.230.xxx.yyy:51849

  allowed ips: 10.253.2.0/30

  latest handshake: 1 minute, 55 seconds ago

  transfer: 145.71 KiB received, 29.74 KiB sent

  persistent keepalive: every 20 seconds



peer: FTB__hg=

  endpoint: 10.253.2.2:60026

  allowed ips: 10.253.2.3/32

  transfer: 89.46 KiB received, 60.67 KiB sent

  persistent keepalive: every 20 seconds

  

  

PS C:\Windows\system32> Get-NetIPInterface | select ifIndex,InterfaceAlias,AddressFamily,ConnectionState,Forwarding,weakhostreceive,weakhostsend | Sort-Object -Property IfIndex | Format-Table

>>



ifIndex InterfaceAlias              AddressFamily ConnectionState Forwarding WeakHostReceive WeakHostSend

------- --------------              ------------- --------------- ---------- --------------- ------------

      1 Loopback Pseudo-Interface 1          IPv4       Connected   Disabled        Disabled     Disabled

      1 Loopback Pseudo-Interface 1          IPv6       Connected   Disabled        Disabled     Disabled

      4 LAN-Verbindung* 11                   IPv6       Connected   Disabled        Disabled     Disabled

      4 LAN-Verbindung* 11                   IPv4       Connected   Disabled        Disabled     Disabled

      8 WLAN                                 IPv4    Disconnected   Disabled        Disabled     Disabled

      8 WLAN                                 IPv6    Disconnected   Disabled        Disabled     Disabled

     12 Ethernet                             IPv6       Connected   Disabled        Disabled     Disabled

     12 Ethernet                             IPv4       Connected   Disabled        Disabled     Disabled

     16 LAN-Verbindung* 2                    IPv6    Disconnected   Disabled        Disabled     Disabled

     16 LAN-Verbindung* 2                    IPv4    Disconnected   Disabled        Disabled     Disabled

     17 LAN-Verbindung* 1                    IPv6    Disconnected   Disabled        Disabled     Disabled

     17 LAN-Verbindung* 1                    IPv4    Disconnected   Disabled        Disabled     Disabled

     53 wireguard                            IPv6       Connected   Disabled        Disabled     Disabled

     53 wireguard                            IPv4       Connected   Disabled        Disabled     Disabled

wg_relais debug state:

wg-vpn-relais # conntrack -L | grep 10.253

udp      17 28 src=178.101.114.260 dst=185.230.xxx.yyy sport=60026 dport=51850 [UNREPLIED] src=10.253.2.9 dst=10.253.2.2 sport=51850 dport=60026 mark=0 use=1


From szymonn841 at gmail.com  Tue Jun  7 07:08:13 2022
From: szymonn841 at gmail.com (Szymon Nowak)
Date: Tue, 7 Jun 2022 09:08:13 +0200
Subject: wireguard-windows: possibly wrong selection of outgoing IP
 Address?
In-Reply-To: <4bb8fade-487e-2301-65d0-dea41624682f@online.de>
References: <4bb8fade-487e-2301-65d0-dea41624682f@online.de>
Message-ID: <CA+hy6duTcA38PMWRj6L2U_jwBDnNkFjojGBL-ot-9oJ-BwiHtw@mail.gmail.com>

Hi To do this on the windows server, you need to run NAT on the WG interface
https://openvpn.net/cloud-docs/enabling-routing-nat-on-windows-server-2016/

On Sun, Jun 5, 2022 at 10:23 PM Max Schulze <max.schulze at online.de> wrote:
>
> I am running out of ideas to debug this specific issue.
>
> I am trying to circumvent a double-NAT scenario. I have
>
> wg_serv (10.253.2.9) <->  wg-relais (10.253.2.2) <-> wg_peer ( 10.253.2.3)
>
> wg_serv has an endpoint set for wg-relais, and creates the connection ok (handshake completes, ping works).
> wg_peer has an endpoint that points to wg-relais, which should tunnel the connection as-is to wg_serv on the established connection ( iptables SNAT/DNAT ).
>
> If wg_serv is a linux box, with the exact same config file, everything works. if wg_serv is a windows box, it seems that there are no outgoing packets, but incoming is ok.
>
> First, see that the handshake packet is received (via 10.253.2.2:60026):
>
> 2022-06-05 20:30:17.140946: [TUN] [wireguard] Keypair 536 created for peer 1
>
> 2022-06-05 20:30:22.085949: [TUN] [wireguard] Handshake for peer 1 (10.253.2.2:60026) did not complete after 5 seconds, retrying (try 2)
>
> 2022-06-05 20:30:22.265787: [TUN] [wireguard] Receiving handshake initiation from peer 1 (10.253.2.2:60026)
>
> 2022-06-05 20:30:22.265787: [TUN] [wireguard] Sending handshake response to peer 1 (10.253.2.2:60026)
>
> 2022-06-05 20:30:22.267019: [TUN] [wireguard] Keypair 536 destroyed for peer 1
>
> 2022-06-05 20:30:22.267019: [TUN] [wireguard] Keypair 537 created for peer 1
>
> 2022-06-05 20:30:27.147962: [TUN] [wireguard] Sending keepalive packet to peer 2 (185.230.xxx.yyy:51849)
>
> 2022-06-05 20:30:27.626543: [TUN] [wireguard] Receiving handshake initiation from peer 1 (10.253.2.2:60026)
>
> 2022-06-05 20:30:27.626543: [TUN] [wireguard] Sending handshake response to peer 1 (10.253.2.2:60026)
>
>
>
>
> However, it seems that wireguard sends the outgoing packet with the wrong ip (192.168.99.101) instead of 10.253.2.9 to 10.253.2.2:60026 ?
>
>
>
>     Protocol    Local Port      Local Address   Remote Port Remote Address      Received Bytes  Sent Bytes  Rec Pkt Sent Packets
>
> wireguard.exe   UDP IPv4    51850   192.168.99.101  51849       185.230.xxx.yyy     81.976          8.584   417     216
>
> wireguard.exe   UDP IPv4    51850   10.253.2.9      60026       10.253.2.2          55.648                  376
>
> wireguard.exe   UDP IPv4    51850   192.168.99.101  60026       10.253.2.2                          37.848          398
>
>
> What can I do?
> Can I make the wireguard log more verbose to show IP Paket src/Destination?
>
> Is it possible to also log the src IP of the "handshake response packet"?
>
> Best,
> Max
>
>
> wg_serv config:
>
> [Interface]
>
> PrivateKey = SFhFHVb__2c=
>
> ListenPort = 51850
>
> Address = 10.253.2.9/24
>
>
>
> [Peer]
>
> # wg-vpn-relais
>
> PublicKey = 3A5__wo=
>
> AllowedIPs = 10.253.2.2/30
>
> Endpoint = 185.230.xxx.yyy:51849
>
> PersistentKeepalive = 20
>
>
>
> [Peer]
>
> # peer via vpn relais
>
> PublicKey = FTBC__cqghg=
>
> AllowedIPs = 10.253.2.3/32
>
> PersistentKeepalive = 20
>
>
>
> wg output:
>
> peer: 3A5__o=
>
>   endpoint: 185.230.xxx.yyy:51849
>
>   allowed ips: 10.253.2.0/30
>
>   latest handshake: 1 minute, 55 seconds ago
>
>   transfer: 145.71 KiB received, 29.74 KiB sent
>
>   persistent keepalive: every 20 seconds
>
>
>
> peer: FTB__hg=
>
>   endpoint: 10.253.2.2:60026
>
>   allowed ips: 10.253.2.3/32
>
>   transfer: 89.46 KiB received, 60.67 KiB sent
>
>   persistent keepalive: every 20 seconds
>
>
>
>
>
> PS C:\Windows\system32> Get-NetIPInterface | select ifIndex,InterfaceAlias,AddressFamily,ConnectionState,Forwarding,weakhostreceive,weakhostsend | Sort-Object -Property IfIndex | Format-Table
>
> >>
>
>
>
> ifIndex InterfaceAlias              AddressFamily ConnectionState Forwarding WeakHostReceive WeakHostSend
>
> ------- --------------              ------------- --------------- ---------- --------------- ------------
>
>       1 Loopback Pseudo-Interface 1          IPv4       Connected   Disabled        Disabled     Disabled
>
>       1 Loopback Pseudo-Interface 1          IPv6       Connected   Disabled        Disabled     Disabled
>
>       4 LAN-Verbindung* 11                   IPv6       Connected   Disabled        Disabled     Disabled
>
>       4 LAN-Verbindung* 11                   IPv4       Connected   Disabled        Disabled     Disabled
>
>       8 WLAN                                 IPv4    Disconnected   Disabled        Disabled     Disabled
>
>       8 WLAN                                 IPv6    Disconnected   Disabled        Disabled     Disabled
>
>      12 Ethernet                             IPv6       Connected   Disabled        Disabled     Disabled
>
>      12 Ethernet                             IPv4       Connected   Disabled        Disabled     Disabled
>
>      16 LAN-Verbindung* 2                    IPv6    Disconnected   Disabled        Disabled     Disabled
>
>      16 LAN-Verbindung* 2                    IPv4    Disconnected   Disabled        Disabled     Disabled
>
>      17 LAN-Verbindung* 1                    IPv6    Disconnected   Disabled        Disabled     Disabled
>
>      17 LAN-Verbindung* 1                    IPv4    Disconnected   Disabled        Disabled     Disabled
>
>      53 wireguard                            IPv6       Connected   Disabled        Disabled     Disabled
>
>      53 wireguard                            IPv4       Connected   Disabled        Disabled     Disabled
>
> wg_relais debug state:
>
> wg-vpn-relais # conntrack -L | grep 10.253
>
> udp      17 28 src=178.101.114.260 dst=185.230.xxx.yyy sport=60026 dport=51850 [UNREPLIED] src=10.253.2.9 dst=10.253.2.2 sport=51850 dport=60026 mark=0 use=1
>

From max.schulze at online.de  Tue Jun  7 08:43:29 2022
From: max.schulze at online.de (Max Schulze)
Date: Tue, 7 Jun 2022 10:43:29 +0200
Subject: wireguard-windows: possibly wrong selection of outgoing IP
 Address?
In-Reply-To: <CA+hy6duTcA38PMWRj6L2U_jwBDnNkFjojGBL-ot-9oJ-BwiHtw@mail.gmail.com>
References: <4bb8fade-487e-2301-65d0-dea41624682f@online.de>
 <CA+hy6duTcA38PMWRj6L2U_jwBDnNkFjojGBL-ot-9oJ-BwiHtw@mail.gmail.com>
Message-ID: <26d9f096-e8a0-2405-b28c-1b25a319e8d6@online.de>

Hallo Szymon,


On 07.06.22 09:08, Szymon Nowak wrote:
> Hi To do this on the windows server, you need to run NAT on the WG interface
> https://openvpn.net/cloud-docs/enabling-routing-nat-on-windows-server-2016/


why should I ? Which interfaces should I bridge? The WG Interface is "stand-alone" and does not to any routing to/from public internet for any clients.

Why are you suggesting NAT, when the log shows that the IP adresses for the *destination* are correct?

Besides, I do not need to do any of this on the linux box, where the connection is successful with the same config.

From Jason at zx2c4.com  Fri Jun 10 17:23:55 2022
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Fri, 10 Jun 2022 19:23:55 +0200
Subject: [ANNOUNCE] wireguard-freebsd snapshot v0.0.20220610 is available
Message-ID: <20220610172402.C3DE7C34114@smtp.kernel.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hi,

An experimental snapshot, v0.0.20220610, of WireGuard for FreeBSD has been
been tagged in the git repository.

At this time this code is new, unvetted, possibly buggy, and should be
considered "experimental". It might contain security issues. We gladly
welcome your testing and bug reports, but do keep in mind that this code
is new, so some caution should be exercised at the moment for using it
in mission critical environments.

== Changes ==

  * if_wg: wg_queue_len: remove locking
  * if_wg: wg_queue_delist_staged: use more standard STAILQ_CONCAT
  * if_wg: wgc_get/set: use M_WAITOK with malloc()
  * if_wg: wg_clone_create: Use M_WAITOK with malloc
  * wg_cookie: ratelimit_init: use callout_init_mtx
  * if_wg: wg_mbuf_reset: don't free send tags
  * if_wg: wg_module_init: clean up more if the self tests fail
  
  Numerous cleanups.
  
  * if_wg: avoid scheduling excessive tasks for encryption/decryption
  
  A nice performance improvement - John reports double on iperf3 TCP throughput.
  
  * crypto: return an error code from mbuf crypt routines
  
  Preparation for the OCF work John's been working on.
  
  * if_wg: account for input function returning a boolean
  * if_wg: account for added argument to sbcreatecontrol
  
  These allow building on recent FreeBSD 14 main.
  
  * if_wg: do not use continue statement on \!VIMAGE
  * build: only include compat.h for if_wg.c and fix build with an obj directory
  
  These allow building in different configurations.

This snapshot contains commits from: John Baldwin and Jason A. Donenfeld.

The source repository is available at the usual location:
  git clone https://git.zx2c4.com/wireguard-freebsd

This snapshot is available in compressed tarball form:
  https://git.zx2c4.com/wireguard-freebsd/snapshot/wireguard-freebsd-0.0.20220610.tar.xz
  SHA2-256: 518779c383e8087a60a7ec7b0969158a48b2f19a34a13b62683c982960295f17

Thank you,
Jason Donenfeld


-----BEGIN PGP SIGNATURE-----

iQJEBAEBCAAuFiEEq5lC5tSkz8NBJiCnSfxwEqXeA64FAmKjfhcQHGphc29uQHp4
MmM0LmNvbQAKCRBJ/HASpd4DrszsD/9rSo3Cqx8AqilVII4dpbxGzHXnkSCetUc8
e0nBLtvSZ0C/MiHSJtOD1iwdz8ndPX57P2VUdBVV/xmSeWzblfWDyB2nOoiLUq4P
EoJaAkMD1isErVdJizlq0QQEq6UFegBcb9ttna33IZJm67uRXICzWq55yl/pJMSV
zhsv2cQOKK8S9dUKgBtY31YKnDMZLvbtJbPP5hiDyCmrSVYrQKFd6owhCubRzGKE
thNP/+rDgitz7vFB8Uu84Ib/dY8dVPjFbK/k3DqTdSKhefI4uc0y1buM8mV96zGi
pXXYqi1qrgnMVpO2plhR04thACbAqT1Gbsx402q48LeJ7cD+oL0WxTJ2H9gEv/tA
lJ4e7YnWt3zyu4SW8CvDPbVfWLVTTHR9jvV+/qJp4SVbFsDkmdHT7mWURRUtwawD
C0p+wPlBcqdENXVtFmvaKeqclxCXFUkIC1SorIStKhYDPsFdRexOsiXAqAVdXmvJ
ZdeX8BJWHXz7cxGNdE96ep6qBMAPJ2+9f3nLIoG/1ca0hWvDpWTGbepoekv0Ab0/
gwXqlxUfOmCjjLBRA4vrp0JJpWJJaWWdQSVKmeDwn/z7h/kASjeL1Z7gDlkEq3yI
hKg47SUqupG2/iSoL8EUglAPi1o498BhZANtf3LgYH3z+fd7GU4k/ugfp2KKjsOq
+dNT9WYX9Q==
=yY95
-----END PGP SIGNATURE-----

From Jason at zx2c4.com  Tue Jun 14 09:21:19 2022
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Tue, 14 Jun 2022 11:21:19 +0200
Subject: [ANNOUNCE] wireguard-freebsd snapshot v0.0.20220614 is available
Message-ID: <20220614092123.14834C341C4@smtp.kernel.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hi,

An experimental snapshot, v0.0.20220614, of WireGuard for FreeBSD has been
been tagged in the git repository.

At this time this code is new, unvetted, possibly buggy, and should be
considered "experimental". It might contain security issues. We gladly
welcome your testing and bug reports, but do keep in mind that this code
is new, so some caution should be exercised at the moment for using it
in mission critical environments.

== Changes ==

  * build: include compat.h for all files
  * compat: fix version stamp
  
  Two lingering compat issues.
  
  * if_wg: wg_peer_alloc and wg_aip_add: Use M_WAITOK with malloc
  
  A small cleanup to memory allocation and error path logic.
  
  * crypto: use OCF to encrypt/decrypt packets when supported
  * crypto: use <crypto/chacha20_poly1305.h> when present
  * crypto: use curve25519 API from the kernel when available
  * crypto: harmonize with compat and clean up
  
  Crypto from OCF and FreeBSD's library code will now be used when available.

This snapshot contains commits from: John Baldwin and Jason A. Donenfeld.

The source repository is available at the usual location:
  git clone https://git.zx2c4.com/wireguard-freebsd

This snapshot is available in compressed tarball form:
  https://git.zx2c4.com/wireguard-freebsd/snapshot/wireguard-freebsd-0.0.20220614.tar.xz
  SHA2-256: b048049561f18fd48ab3fa6455f9e0ecca25c6314880f48e68c56ceacf7f6719

Thank you,
Jason Donenfeld


-----BEGIN PGP SIGNATURE-----

iQJEBAEBCAAuFiEEq5lC5tSkz8NBJiCnSfxwEqXeA64FAmKoUwMQHGphc29uQHp4
MmM0LmNvbQAKCRBJ/HASpd4DrtWQD/9SrtU+zAXlB50zLYO1LhNexPLlgWMcAZsM
qwJaIzxMdsXPCCfqLOfqxUXOAjPf7EWxFE8cj1iV6hLduzl0wnu84OZIxr7yvSFT
qhk6aZxcgiUTpxIHa4WdJkxiqMNRafv6le33F233VWNBbJCn8f9JjxON8Fph0W/N
DZ0X+fGwPJ25bnCWc//Cl7WhQulT7BxNi2jrsgpuJNmCGOeSRyfTh9ygDRX5WLD6
mZiIfqTs4+l9gVjeUcC7b49qbZeRtpsmePfaXp5fN2U6s5cyk76SbarCHD62aFlP
OM4xdl07J+YhsXdfj98whE1RVTS8jFvz3iADKW0MuwDEeEcDCh4vpspiNerYDIvQ
J+aFT8+zexmv9IdNQxYK3u9W1G6COz0wspBWixZGfeqfNZyPpXVOqgdKarsdFLnz
wYFFz8FPdMlB8A8J+aehNqqsrH6rXbE4J2poz3upxrntKMxG+u0YB5pDoxY0JkAQ
uvT3Ij/7CdsXYHnbKwFtiv9dmSzgSpFNOzSbffBWYb24i1UCCAbJqe5Eae9b7MIh
6PuaBp3YzlR3NHsXcliss2SbEMf1nf2WStTtKHDKW5hAyRdg4dqDMZxvPc8OU6vC
BF1gVIEYC9wRLaNfxU/mW5ugdiN0b3u6uT9ELrN/mV56z45xPKmedpDNXKHqz3b2
JF9KsyRjDg==
=xgbb
-----END PGP SIGNATURE-----

From venefax at gmail.com  Fri Jun  3 18:40:47 2022
From: venefax at gmail.com (Saint Michael)
Date: Fri, 3 Jun 2022 14:40:47 -0400
Subject: How to generate the QR Code
In-Reply-To: <CAC9cSOATKiXuaFO8UQZezP7RLebBoo-UWwM-KQJMEwhg_-+VTw@mail.gmail.com>
References: <CAC9cSOATKiXuaFO8UQZezP7RLebBoo-UWwM-KQJMEwhg_-+VTw@mail.gmail.com>
Message-ID: <CAC9cSOBv7Zkj0uPqyaBDKC+aiwOzTrbjNGUP41iyKZb9u2i-Lw@mail.gmail.com>

Dear friends
I have a Mikrotikotic router and configured all that is necessary for
the VPN.  I also configured a windows client for testing. Once it
worked, I downloaded the Wireguard app from the Google Play Store. The
question is, how can I generate the QR Code so all my employees can
use it on their phones?
I could not find the answer.

Philip

From david at bamsoftware.com  Thu Jun  9 22:05:22 2022
From: david at bamsoftware.com (David Fifield)
Date: Thu, 9 Jun 2022 16:05:22 -0600
Subject: WireGuard protocol blocking in China, swgp-go (userspace obfuscation
 proxy)
Message-ID: <20220609220522.kwqa4uvuc3sijlka@bamsoftware.com>

I am forwarding some information about WireGuard blocking and
anti-blocking that was posted to a censorship circumvention forum.

swgp-go is a userspace obfuscation proxy that aims to hide WireGuard's
distinctive protocol fingerprint (message_type and reserved_zero fields,
fixed packet lengths). It super-encrypts part or all of WireGuard
packets using a preshared symmetric key, and optionally adds padding.
The security of the channel relies on the encryption and authentication
of the underlying WireGuard tunnel, which requires less overhead than a
general-purpose circumvention proxy would.

https://github.com/database64128/swgp-go
https://github.com/net4people/bbs/issues/117

There is a past discussion on this mailing list of something similar.
That one was in the kernel; this one is in userspace.
https://lists.zx2c4.com/pipermail/wireguard/2021-September/007142.html
https://github.com/net4people/bbs/issues/88

Separately, the swgp-go announcement post comments on the dynamics of
WireGuard blocking in China:

> The GFW will block the remote peer's UDP port for a few days after
> about a week's continuous usage.
> ...
> ... the GFW only started blocking WireGuard on IPv4 this February.

GFW = Great Firewall, the collective name for various censorship systems
used by the government of China. The pattern of "detect, then block for
a limited time, then unblock" is typical for the GFW, though the time
intervals are usually rather shorter. For example, when the GFW began to
block the use of the ESNI extension in TLS 1.3, it would block the
server endpoint for 120 or 180 seconds:
https://gfw.report/blog/gfw_esni_blocking/en/#residual-censorship

I have not confirmed the reported blocking behavior in China. It's worth
keeping in mind also that blocking in China can differ across networks
and geographic regions. I did find a Reddit post from 3 months ago, from
the Fuzhou region, saying that WireGuard is detected and blocked within
24 hours:
https://www.reddit.com/r/WireGuard/comments/t0bpy3/wireguard_detected_and_blocked_by_gfw/

A past message on this mailing list about temporary problems with the
WireGuard protocol in Russia last year:
https://lists.zx2c4.com/pipermail/wireguard/2021-September/007050.html

From snowstorm3842 at mailbox.org  Tue Jun 14 07:20:12 2022
From: snowstorm3842 at mailbox.org (snowstorm3842 at mailbox.org)
Date: Tue, 14 Jun 2022 15:20:12 +0800
Subject: doas support for wg-quick linux
Message-ID: <20220614072012.jsvrl7buu67c6byy@erhnbox>

This isn't that much of a problem because I and probably many others start the wg-quick script as a system service. But when you run the script as non-root, it asks for sudo with the option "-p".

I have my doas symlinked to sudo so the script actually runs "doas -p prompt" in which the option not exist in doas. I found a the script for openbsd from your repositories, I looked at it and it uses doas. It's not that important but it'll be nice if you could add doas to the linux script.

From endre.szabo at wg-ml-rkaofgr.redir.email  Tue Jun 14 09:51:07 2022
From: endre.szabo at wg-ml-rkaofgr.redir.email (Endre Szabo)
Date: Tue, 14 Jun 2022 09:51:07 +0000
Subject: How to generate the QR Code
In-Reply-To: <CAC9cSOBv7Zkj0uPqyaBDKC+aiwOzTrbjNGUP41iyKZb9u2i-Lw@mail.gmail.com>
References: <CAC9cSOATKiXuaFO8UQZezP7RLebBoo-UWwM-KQJMEwhg_-+VTw@mail.gmail.com>
 <CAC9cSOBv7Zkj0uPqyaBDKC+aiwOzTrbjNGUP41iyKZb9u2i-Lw@mail.gmail.com>
Message-ID: <c0b24e8e56a672859849ebdd1563ba38@wg-ml-rkaofgr.redir.email>

Hi Philip,

While it is not complicated, it is not that simple to generate the QR codes just based on the Mikrotik configs. QR codes are basically encoded config files for the clients. And the added complexity is that they have the private key in them as well, which I'm sure you have on file somewere, as you had to give Mikrotik the public counterpart of that keypair.

What I really miss of the QR code config file is a 'metadata' field that should function as a 'connection name suggestion' the user can accept (or edit as prefilled connetction name field) upon QR code reading. This would be really handly in case of a lot of connections to add to a phone.

--Endre

On Fri, Jun 03, 2022 at 14:40:47-0400, Saint Michael wrote:
> Dear friends
> I have a Mikrotikotic router and configured all that is necessary for
> the VPN.  I also configured a windows client for testing. Once it
> worked, I downloaded the Wireguard app from the Google Play Store. The
> question is, how can I generate the QR Code so all my employees can
> use it on their phones?
> I could not find the answer.
> 
> Philip

From nico.schottelius at ungleich.ch  Tue Jun 14 13:13:11 2022
From: nico.schottelius at ungleich.ch (Nico Schottelius)
Date: Tue, 14 Jun 2022 15:13:11 +0200
Subject: WireGuard protocol blocking in China, swgp-go (userspace
 obfuscation proxy)
In-Reply-To: <20220609220522.kwqa4uvuc3sijlka@bamsoftware.com>
References: <20220609220522.kwqa4uvuc3sijlka@bamsoftware.com>
Message-ID: <87pmjbpele.fsf@ungleich.ch>


David Fifield <david at bamsoftware.com> writes:

> I am forwarding some information about WireGuard blocking and
> anti-blocking that was posted to a censorship circumvention forum.

In regards to this topic I was wondering if it makes sense to have a
more generic obfuscation proxy that can carry tcp/udp payload?

Maybe this already exists, but I would think that something that hops
protocols (IPv6, IPv4 endpoints, tcp/udp encapsolution), changes ports
and uses envelope based tunneling (http, https, smtp, imap - worst case
DNS) would make it easier to sustain communication even in more serious
filtering scenarios.

Given such a "generic obfuscator", it could be combined with "protocol"
modes, i.e. enhancing protocols such as wireguard with the presented
algorithm, making it even harder to predict the content.

I'd assume some performance regressions using such an obfuscator, but
maybe it could even "learn" the proper obfuscation by detecting blocks
on easier to detect obfuscation and then switching to a stronger, but
less efficient obfuscation.

Wondering what your thoughts are on this.

Best regards,

Nico

--
Sustainable and modern Infrastructures by ungleich.ch

From simon at rozman.si  Tue Jun 14 17:02:41 2022
From: simon at rozman.si (Simon Rozman)
Date: Tue, 14 Jun 2022 17:02:41 +0000
Subject: Incompatibility between wintun.dll and go module
In-Reply-To: <CAGyv=Qv7vNrTvMriOxAyEHHUAz6qOOZDtjfj=+ru+yOKAcY8UQ@mail.gmail.com>
References: <CAGyv=Qv7vNrTvMriOxAyEHHUAz6qOOZDtjfj=+ru+yOKAcY8UQ@mail.gmail.com>
Message-ID: <6F224D6F-E5DA-44C9-93AF-83A0B33EFE45@rozman.si>

Hi!

The 0.14+ is not binary compatible with 0.13. The API changed considerably: https://git.zx2c4.com/wintun/diff/api/wintun.h?id=544fdaaf8fb970d9657a59c1fc4c4569de4f2d3e

The wireguard-go repo was adjusted for this API change in https://git.zx2c4.com/wireguard-go/commit/?id=82d2aa87aa623cb5143a41c3345da4fb875ad85d. Wintun adapter pools were completely discontinued; however, your stack trace indicates you are still using an outdated version of wireguard-go calling wintun.(*Pool).OpenAdapter.

Please, update wireguard-go and update.

Regards,
Simon

?-----Original Message-----
From: WireGuard <wireguard-bounces at lists.zx2c4.com> on behalf of Thomas Hallgren <thomas at datawire.io>
Date: Tuesday, 14 June 2022 at 11.32
To: "wireguard at lists.zx2c4.com" <wireguard at lists.zx2c4.com>
Subject: Incompatibility between wintun.dll and go module

    Hi,

    We're using the wintun.dll and the go module
    golang.zx2c4.com/wireguard/windows v0.5.3 in our product. The dll
    initialization fails when upgrading the wintun.dll to version 0.14.1
    (or 0.14, it doesn't matter). 0.13 works fine. Relevant stack trace
    below.

    Thanks for an excellent library. Without it, it would be much harder
    to port our product to Windows.

    unexpected fault address 0xffffffffffffffff
    fatal error: fault
    [signal 0xc0000005 code=0x0 addr=0xffffffffffffffff pc=0xe8b29d]

    goroutine 65 [running, locked to thread]:
    runtime.throw({0x27b93d9?, 0x0?})
    runtime/panic.go:992 +0x76 fp=0xc000a393d8 sp=0xc000a393a8 pc=0xce8996
    runtime.sigpanic()
    runtime/signal_windows.go:261 +0x125 fp=0xc000a39420 sp=0xc000a393d8 pc=0xcfbb05
    golang.org/x/sys/windows.UTF16PtrToString(0x240e6a0?)
    golang.org/x/sys at v0.0.0-20220209214540-3681064d5158/windows/syscall_windows.go:132
    +0x1d fp=0xc000a39468 sp=0xc000a39420 pc=0xe8b29d
    golang.zx2c4.com/wireguard/tun/wintun.setupLogger.func1(0xc000057590?, 0x0?)
    golang.zx2c4.com/wireguard at v0.0.0-20210427022245-097af6e1351b/tun/wintun/wintun_windows.go:53
    +0x1c fp=0xc000a394b0 sp=0xc000a39468 pc=0x1f321bc
    runtime.call16(0x0, 0x28df468, 0xc000a39538, 0x0, 0x0, 0x10, 0xc000a39790)
    runtime/asm_amd64.s:701 +0x50 fp=0xc000a394d0 sp=0xc000a394b0 pc=0xd14530
    runtime.callbackWrap(0x7c95ffebc0)
    runtime/syscall_windows.go:378 +0x134 fp=0xc000a398b0 sp=0xc000a394d0
    pc=0xd04074
    runtime.cgocallbackg1(0xd03f40, 0x0?, 0x0)
    runtime/cgocall.go:314 +0x2ca fp=0xc000a39980 sp=0xc000a398b0 pc=0xcb4b8a
    runtime.cgocallbackg(0xc000583380?, 0x300000002?, 0xc000583380?)
    runtime/cgocall.go:233 +0x106 fp=0xc000a39a18 sp=0xc000a39980 pc=0xcb47c6
    runtime.cgocallbackg(0xd03f40, 0x7c95ffebc0, 0x0)
    <autogenerated>:1 +0x36 fp=0xc000a39a40 sp=0xc000a39a18 pc=0xd18356
    runtime.cgocallback(0xcb464b, 0xd17be0, 0xc0001002c0)
    runtime/asm_amd64.s:971 +0xd7 fp=0xc000a39a68 sp=0xc000a39a40 pc=0xd160f7
    runtime.systemstack_switch()
    runtime/asm_amd64.s:436 fp=0xc000a39a70 sp=0xc000a39a68 pc=0xd13fe0
    runtime.cgocall(0xd17be0, 0xc0001002c0)
    runtime/cgocall.go:167 +0xab fp=0xc000a39aa8 sp=0xc000a39a70 pc=0xcb464b
    syscall.SyscallN(0x7ffc169c3a90?, {0xc000a39b40?, 0x3?, 0x0?})
    runtime/syscall_windows.go:538 +0x109 fp=0xc000a39b20 sp=0xc000a39aa8
    pc=0xd12de9
    syscall.Syscall(0xc000479590?, 0x1a428c8510a?, 0x1a428c8510a?, 0x0?, 0x0?)
    runtime/syscall_windows.go:476 +0x3b fp=0xc000a39b68 sp=0xc000a39b20 pc=0xd129fb
    golang.zx2c4.com/wireguard/tun/wintun.(*Pool).OpenAdapter(0xc000187800,
    {0x27b825c?, 0x1a403910598?})
    golang.zx2c4.com/wireguard at v0.0.0-20210427022245-097af6e1351b/tun/wintun/wintun_windows.go:89
    +0xad fp=0xc000a39bd8 sp=0xc000a39b68 pc=0x1f3256d
    golang.zx2c4.com/wireguard/tun.CreateTUNWithRequestedGUID({0x27b825c,
    0x4}, 0x0?, 0x0)
    golang.zx2c4.com/wireguard at v0.0.0-20210427022245-097af6e1351b/tun/tun_windows.go:75
    +0x4d fp=0xc000a39c50 sp=0xc000a39bd8 pc=0x1f3384d
    golang.zx2c4.com/wireguard/tun.CreateTUN(...)
    golang.zx2c4.com/wireguard at v0.0.0-20210427022245-097af6e1351b/tun/tun_windows.go:63


From jrm at FreeBSD.org  Tue Jun 14 19:15:26 2022
From: jrm at FreeBSD.org (Joseph Mingrone)
Date: Tue, 14 Jun 2022 16:15:26 -0300
Subject: [PATCH] compat: Update version to handle sbcreatecontrol() changes
Message-ID: <20220614191526.70200-1-jrm@FreeBSD.org>

The sockbuf changes to merge two versions of sbcreatecontrol() into one
occurred in b46667c63eb7 in the FreeBSD src repository.  The value of
__FreeBSD_version at the time of that commit was 1400059, so check
for systems with a version stamp less than 1400059.

Ideally __FreeBSD_version would have been bumped in b46667c63eb7,
however it was set to 1400059 53 commits prior in 3a9a9c0ca44e and not
bumped to 1400060 until 374 commits later in 85d7875d4291.  Thus, this
is not a perfect solution because CURRENT systems built from 53 possible
commits that require the adjustment will still fail to build the
wireguard kernel module.  This is better than checking for systems with
__FreeBSD_version < 1400057.  In that case, there are 767 different
commits a CURRENT system may be built from where the module will fail to
build.

Sponsored by:	The FreeBSD Foundation
---
 src/compat.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/compat.h b/src/compat.h
index 8567524..d55c628 100644
--- a/src/compat.h
+++ b/src/compat.h
@@ -24,7 +24,7 @@
 #define COMPAT_NEED_BLAKE2S
 #endif
 
-#if __FreeBSD_version < 1400057
+#if __FreeBSD_version < 1400059
 #include <sys/sockbuf.h>
 #define sbcreatecontrol(a, b, c, d, e) sbcreatecontrol(a, b, c, d)
 #endif
-- 
2.36.1


From Jason at zx2c4.com  Tue Jun 14 19:59:26 2022
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Tue, 14 Jun 2022 21:59:26 +0200
Subject: [PATCH] compat: Update version to handle sbcreatecontrol() changes
In-Reply-To: <20220614191526.70200-1-jrm@FreeBSD.org>
References: <20220614191526.70200-1-jrm@FreeBSD.org>
Message-ID: <YqjonnCu7RV0DC0j@zx2c4.com>

Hi Joesph,

On Tue, Jun 14, 2022 at 04:15:26PM -0300, Joseph Mingrone wrote:
> The sockbuf changes to merge two versions of sbcreatecontrol() into one
> occurred in b46667c63eb7 in the FreeBSD src repository.  The value of
> __FreeBSD_version at the time of that commit was 1400059, so check
> for systems with a version stamp less than 1400059.
> 
> Ideally __FreeBSD_version would have been bumped in b46667c63eb7,
> however it was set to 1400059 53 commits prior in 3a9a9c0ca44e and not
> bumped to 1400060 until 374 commits later in 85d7875d4291.  Thus, this
> is not a perfect solution because CURRENT systems built from 53 possible
> commits that require the adjustment will still fail to build the
> wireguard kernel module.  This is better than checking for systems with
> __FreeBSD_version < 1400057.  In that case, there are 767 different
> commits a CURRENT system may be built from where the module will fail to
> build.

Seems reasonable. Applied, thanks.

Jason

From Jason at zx2c4.com  Wed Jun 15 14:11:35 2022
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Wed, 15 Jun 2022 16:11:35 +0200
Subject: [ANNOUNCE] wireguard-freebsd snapshot v0.0.20220615 is available
Message-ID: <20220615141140.96557C3411C@smtp.kernel.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hi,

An experimental snapshot, v0.0.20220615, of WireGuard for FreeBSD has been
been tagged in the git repository.

At this time this code is new, unvetted, possibly buggy, and should be
considered "experimental". It might contain security issues. We gladly
welcome your testing and bug reports, but do keep in mind that this code
is new, so some caution should be exercised at the moment for using it
in mission critical environments.

== Changes ==

  * ci: add FreeBSD 12.3 and 13.1
  * compat: update version to handle sbcreatecontrol() changes
  
  More fixes to the compat layer.
  
  * wg_noise: import hmac from crypto
  * crypto: inline blake2s convenience function
  
  A few crypto cleanups.

This snapshot contains commits from: Jason A. Donenfeld, Joseph Mingrone, and 
Ed Maste.

The source repository is available at the usual location:
  git clone https://git.zx2c4.com/wireguard-freebsd

This snapshot is available in compressed tarball form:
  https://git.zx2c4.com/wireguard-freebsd/snapshot/wireguard-freebsd-0.0.20220615.tar.xz
  SHA2-256: ad6c42d20a7c0ad2989e729dd41ea5a6a019426b762dfd0c6417e340935cca82

Thank you,
Jason Donenfeld


-----BEGIN PGP SIGNATURE-----

iQJEBAEBCAAuFiEEq5lC5tSkz8NBJiCnSfxwEqXeA64FAmKp6JIQHGphc29uQHp4
MmM0LmNvbQAKCRBJ/HASpd4DrgjTEAC5p4+osYbOTZG0uBlpAQ4ETTmlbJ8yV0av
fZ/P0rLJkL2iYifgynnvO6GyKcRBb9rXa37OKb8+Mt350UU6mgwCB9FaGvWYxEGM
cZYN+BVCN49DdFBtiLeCKnDe8ufeLahs87eSQDI1LDbiX9gYkuWR2cxHfN6b5wZX
r/M80gxbOBR7/pFWm5Hplfj3CRyJkb4i89/BSJ+5Zmbo+qGd2CoKIxHsUXLQeatq
0LhJuFxIrol1Hm/L4pA5k4MTa/UmOVrDkB04cR7eCFp7yxEVKE9aol6tO1uSdD7S
XEdNwsARQ2ehf7DoYdRV+1cl/rTnfaNo7Qp0fAu2+dmd7F0cwRtYCnP45Bcw1F0c
83fImSL4ck0MIFzo9brNK1sa15J+jsYsRsnlqLA0ObPBtOPf+ag/FSp1wfuAwHS6
ugcGNsaX+fOZ9yVf1dxpZHDOiw5TACW221TFb979jaCbHFncf1Ix2GTUeUrEImJa
vuS1uhZOWwJza+ZqdsY2SyNPOewvaaXO5owBPZiD2Qz56Tv7c2v1mdYsT21qldah
+cyffwJKi9if8eGLMH2ao9pfdjZ12Q93GR5nDACqRJtcB4lyMJbX5cMCESmHiCGX
A4C3NUyfiaBxi3Pr4eFWeXuAZLCKmj+/GCoaTdlc34a/LJYuA9GVdR/aIcclRn9e
a6zVVuSnPA==
=Ktyi
-----END PGP SIGNATURE-----

From enlight at riseup.net  Thu Jun  9 21:56:12 2022
From: enlight at riseup.net (enlight)
Date: Thu, 09 Jun 2022 21:56:12 +0000
Subject: [question] wireguard-windows issue
Message-ID: <em8858b9e2-9f1d-410c-84c0-b4ef6f15e771@594329c5.com>

Hello,

when enabling wireguard kill-switch, it creates aggressive wireguard 
firewall rule on windows, it creates rule on windows filtering platform 
(WFP).  The rule is to block all inbound/outbound traffic not for or 
from wireguard interface.

i want to modify current wireguard wfp rule to premit inbound/outbout 
traffic to additional interfaces,  like vmware interface. There are 
several network interfaces in my system active, like "Yggdrasil" -> 
adapter name in Network and sharing center (it uses wintun driver to 
create).

I tried to modify "wireguard-windows/tunnel/firewall/blocker.go"  inside 
EnableFirewall( ) to add:
```
var adapter *driver.Adapter
var luid2 winipcfg.LUID

adapter, err = driver.OpenAdapter("Yggdrasil")  -> gives error here
luid2 = adapter.LUID()
err = permitTunInterface(session, baseObjects, 12, uint64(luid2))
```

the error is: ```Failed to find matching adapter name: Element not 
found. (Code 0x00000490)
Unable to enable firewall rules: Firewall error at 
golang.zx2c4.com/wireguard/windows/tunnel/firewall/blocker.go:148: 
Element not found.```

how can i solve the issue ?


From enlight at riseup.net  Sun Jun 12 21:34:08 2022
From: enlight at riseup.net (enlight)
Date: Sun, 12 Jun 2022 21:34:08 +0000
Subject: [question] wireguard-windows wfp issue
Message-ID: <em1e5036cb-2ace-44db-80c1-23772d981c13@8507782e.com>

Hello,

when enabling wireguard kill-switch, it creates aggressive wireguard 
firewall rule on windows, it creates rule on windows filtering platform 
(WFP).  The rule is to block all inbound/outbound traffic not for or 
from wireguard interface.

i want to modify current wireguard wfp rule to premit inbound/outbout 
traffic to additional interfaces,  like vmware interface. There are 
several network interfaces in my system active, like "Yggdrasil" -> 
adapter name in Network and sharing center (it uses wintun driver to 
create).

I tried to modify "wireguard-windows/tunnel/firewall/blocker.go"  inside 
EnableFirewall( ) to add:
```
var adapter *driver.Adapter
var luid2 winipcfg.LUID

adapter, err = driver.OpenAdapter("Yggdrasil")  -> gives error here
luid2 = adapter.LUID()
err = permitTunInterface(session, baseObjects, 12, uint64(luid2))
```

the error is: ```Failed to find matching adapter name: Element not 
found. (Code 0x00000490)
Unable to enable firewall rules: Firewall error at 
golang.zx2c4.com/wireguard/windows/tunnel/firewall/blocker.go:148: 
Element not found.```

how can i solve the issue ?


From epicstyt at gmail.com  Tue Jun 14 13:52:39 2022
From: epicstyt at gmail.com (Stepan Rabotkin)
Date: Tue, 14 Jun 2022 16:52:39 +0300
Subject: [PATCH] feat: add search to app list
Message-ID: <20220614135239.1034-1-epicstyt@gmail.com>

---
 .../android/fragment/AppListDialogFragment.kt | 39 +++++++++++++------
 .../res/layout/app_list_dialog_fragment.xml   | 15 +++++++
 ui/src/main/res/values/strings.xml            |  1 +
 3 files changed, 44 insertions(+), 11 deletions(-)

diff --git a/ui/src/main/java/com/wireguard/android/fragment/AppListDialogFragment.kt b/ui/src/main/java/com/wireguard/android/fragment/AppListDialogFragment.kt
index 1a40a1c..e9b4cf6 100644
--- a/ui/src/main/java/com/wireguard/android/fragment/AppListDialogFragment.kt
+++ b/ui/src/main/java/com/wireguard/android/fragment/AppListDialogFragment.kt
@@ -11,6 +11,7 @@ import android.widget.Button
 import android.widget.Toast
 import androidx.appcompat.app.AlertDialog
 import androidx.core.os.bundleOf
+import androidx.core.widget.doAfterTextChanged
 import androidx.databinding.Observable
 import androidx.fragment.app.DialogFragment
 import androidx.fragment.app.setFragmentResult
@@ -28,7 +29,8 @@ import kotlinx.coroutines.launch
 import kotlinx.coroutines.withContext
 
 class AppListDialogFragment : DialogFragment() {
-    private val appData = ObservableKeyedArrayList<String, ApplicationData>()
+    private val appList: MutableList<ApplicationData> = ArrayList()
+    private val appListFiltered = ObservableKeyedArrayList<String, ApplicationData>()
     private var currentlySelectedApps = emptyList<String>()
     private var initiallyExcluded = false
     private var button: Button? = null
@@ -39,14 +41,13 @@ class AppListDialogFragment : DialogFragment() {
         val pm = activity.packageManager
         lifecycleScope.launch(Dispatchers.Default) {
             try {
-                val applicationData: MutableList<ApplicationData> = ArrayList()
                 withContext(Dispatchers.IO) {
                     val packageInfos = pm.getPackagesHoldingPermissions(arrayOf(Manifest.permission.INTERNET), 0)
                     packageInfos.forEach {
                         val packageName = it.packageName
                         val appInfo = it.applicationInfo
                         val appData = ApplicationData(appInfo.loadIcon(pm), appInfo.loadLabel(pm).toString(), packageName, currentlySelectedApps.contains(packageName))
-                        applicationData.add(appData)
+                        appList.add(appData)
                         appData.addOnPropertyChangedCallback(object : Observable.OnPropertyChangedCallback() {
                             override fun onPropertyChanged(sender: Observable?, propertyId: Int) {
                                 if (propertyId == BR.selected)
@@ -55,10 +56,10 @@ class AppListDialogFragment : DialogFragment() {
                         })
                     }
                 }
-                applicationData.sortWith(compareBy(String.CASE_INSENSITIVE_ORDER) { it.name })
+                appList.sortWith(compareBy(String.CASE_INSENSITIVE_ORDER) { it.name })
                 withContext(Dispatchers.Main.immediate) {
-                    appData.clear()
-                    appData.addAll(applicationData)
+                    appListFiltered.clear()
+                    appListFiltered.addAll(appList)
                 }
             } catch (e: Throwable) {
                 withContext(Dispatchers.Main.immediate) {
@@ -78,7 +79,7 @@ class AppListDialogFragment : DialogFragment() {
     }
 
     private fun setButtonText() {
-        val numSelected = appData.count { it.isSelected }
+        val numSelected = appList.count { it.isSelected }
         button?.text = if (numSelected == 0)
             getString(R.string.use_all_applications)
         else when (tabs?.selectedTabPosition) {
@@ -106,15 +107,19 @@ class AppListDialogFragment : DialogFragment() {
         alertDialogBuilder.setNegativeButton(R.string.cancel) { dialog, _ -> dialog.dismiss() }
         alertDialogBuilder.setNeutralButton(R.string.toggle_all) { _, _ -> }
         binding.fragment = this
-        binding.appData = appData
+        binding.appData = appListFiltered
         loadData()
+        binding.appSearchText.doAfterTextChanged {
+            appListFiltered.clear()
+            appListFiltered.addAll(filter(it.toString()))
+        }
         val dialog = alertDialogBuilder.create()
         dialog.setOnShowListener {
             button = dialog.getButton(AlertDialog.BUTTON_POSITIVE)
             setButtonText()
             dialog.getButton(AlertDialog.BUTTON_NEUTRAL).setOnClickListener { _ ->
-                val selectAll = appData.none { it.isSelected }
-                appData.forEach {
+                val selectAll = appList.none { it.isSelected }
+                appList.forEach {
                     it.isSelected = selectAll
                 }
             }
@@ -122,9 +127,21 @@ class AppListDialogFragment : DialogFragment() {
         return dialog
     }
 
+    private fun filter(s: String): MutableList<ApplicationData> {
+        val resultData: MutableList<ApplicationData> = ArrayList()
+
+        for (app in appList) {
+            if (app.name.lowercase().contains(s)) {
+                resultData.add(app)
+            }
+        }
+
+        return resultData
+    }
+
     private fun setSelectionAndDismiss() {
         val selectedApps: MutableList<String> = ArrayList()
-        for (data in appData) {
+        for (data in appList) {
             if (data.isSelected) {
                 selectedApps.add(data.packageName)
             }
diff --git a/ui/src/main/res/layout/app_list_dialog_fragment.xml b/ui/src/main/res/layout/app_list_dialog_fragment.xml
index 4503de1..572996d 100644
--- a/ui/src/main/res/layout/app_list_dialog_fragment.xml
+++ b/ui/src/main/res/layout/app_list_dialog_fragment.xml
@@ -40,6 +40,21 @@
                 android:text="@string/include_in_tunnel" />
         </com.google.android.material.tabs.TabLayout>
 
+        <com.google.android.material.textfield.TextInputLayout
+            android:id="@+id/app_search_layout"
+            android:layout_width="match_parent"
+            android:layout_height="wrap_content"
+            android:padding="10dp">
+
+            <com.google.android.material.textfield.TextInputEditText
+                android:id="@+id/app_search_text"
+                android:layout_width="match_parent"
+                android:layout_height="wrap_content"
+                android:hint="@string/search"
+                android:imeOptions="actionDone" />
+
+        </com.google.android.material.textfield.TextInputLayout>
+
         <FrameLayout
             android:layout_width="match_parent"
             android:layout_height="match_parent"
diff --git a/ui/src/main/res/values/strings.xml b/ui/src/main/res/values/strings.xml
index 6c09019..80967ad 100644
--- a/ui/src/main/res/values/strings.xml
+++ b/ui/src/main/res/values/strings.xml
@@ -237,4 +237,5 @@
     <string name="biometric_prompt_private_key_title">Authenticate to view private key</string>
     <string name="biometric_auth_error">Authentication failure</string>
     <string name="biometric_auth_error_reason">Authentication failure: %s</string>
+    <string name="search">Search</string>
 </resources>
-- 
2.32.0.windows.2


From wireguard at centromere.net  Tue Jun 14 14:15:58 2022
From: wireguard at centromere.net (Alex)
Date: Tue, 14 Jun 2022 10:15:58 -0400
Subject: WireGuard protocol blocking in China, swgp-go (userspace
 obfuscation proxy)
In-Reply-To: <20220609220522.kwqa4uvuc3sijlka@bamsoftware.com>
References: <20220609220522.kwqa4uvuc3sijlka@bamsoftware.com>
Message-ID: <20220614101558.31c1dc0b@centromere.net>

On Thu, 9 Jun 2022 16:05:22 -0600
David Fifield <david at bamsoftware.com> wrote:

> I am forwarding some information about WireGuard blocking and
> anti-blocking that was posted to a censorship circumvention forum.
> 

You may find this information[0] relevant and helpful.

Regards,
Alex

[0] https://realworldcrypto.files.wordpress.com/2013/06/shrimpton.pdf
-------------- next part --------------
A non-text attachment was scrubbed...
Name: shrimpton.pdf
Type: application/pdf
Size: 2486747 bytes
Desc: not available
URL: <http://lists.zx2c4.com/pipermail/wireguard/attachments/20220614/1c0e9fe0/attachment.pdf>

From epicstyt at gmail.com  Wed Jun 15 16:07:05 2022
From: epicstyt at gmail.com (Stepan Rabotkin)
Date: Wed, 15 Jun 2022 19:07:05 +0300
Subject: [PATCH] feat: add search to app list
Message-ID: <20220615160705.898-1-epicstyt@gmail.com>

---
 .../android/fragment/AppListDialogFragment.kt | 39 +++++++++++++------
 .../res/layout/app_list_dialog_fragment.xml   | 15 +++++++
 ui/src/main/res/values/strings.xml            |  1 +
 3 files changed, 44 insertions(+), 11 deletions(-)

diff --git a/ui/src/main/java/com/wireguard/android/fragment/AppListDialogFragment.kt b/ui/src/main/java/com/wireguard/android/fragment/AppListDialogFragment.kt
index 1a40a1c..e9b4cf6 100644
--- a/ui/src/main/java/com/wireguard/android/fragment/AppListDialogFragment.kt
+++ b/ui/src/main/java/com/wireguard/android/fragment/AppListDialogFragment.kt
@@ -11,6 +11,7 @@ import android.widget.Button
 import android.widget.Toast
 import androidx.appcompat.app.AlertDialog
 import androidx.core.os.bundleOf
+import androidx.core.widget.doAfterTextChanged
 import androidx.databinding.Observable
 import androidx.fragment.app.DialogFragment
 import androidx.fragment.app.setFragmentResult
@@ -28,7 +29,8 @@ import kotlinx.coroutines.launch
 import kotlinx.coroutines.withContext
 
 class AppListDialogFragment : DialogFragment() {
-    private val appData = ObservableKeyedArrayList<String, ApplicationData>()
+    private val appList: MutableList<ApplicationData> = ArrayList()
+    private val appListFiltered = ObservableKeyedArrayList<String, ApplicationData>()
     private var currentlySelectedApps = emptyList<String>()
     private var initiallyExcluded = false
     private var button: Button? = null
@@ -39,14 +41,13 @@ class AppListDialogFragment : DialogFragment() {
         val pm = activity.packageManager
         lifecycleScope.launch(Dispatchers.Default) {
             try {
-                val applicationData: MutableList<ApplicationData> = ArrayList()
                 withContext(Dispatchers.IO) {
                     val packageInfos = pm.getPackagesHoldingPermissions(arrayOf(Manifest.permission.INTERNET), 0)
                     packageInfos.forEach {
                         val packageName = it.packageName
                         val appInfo = it.applicationInfo
                         val appData = ApplicationData(appInfo.loadIcon(pm), appInfo.loadLabel(pm).toString(), packageName, currentlySelectedApps.contains(packageName))
-                        applicationData.add(appData)
+                        appList.add(appData)
                         appData.addOnPropertyChangedCallback(object : Observable.OnPropertyChangedCallback() {
                             override fun onPropertyChanged(sender: Observable?, propertyId: Int) {
                                 if (propertyId == BR.selected)
@@ -55,10 +56,10 @@ class AppListDialogFragment : DialogFragment() {
                         })
                     }
                 }
-                applicationData.sortWith(compareBy(String.CASE_INSENSITIVE_ORDER) { it.name })
+                appList.sortWith(compareBy(String.CASE_INSENSITIVE_ORDER) { it.name })
                 withContext(Dispatchers.Main.immediate) {
-                    appData.clear()
-                    appData.addAll(applicationData)
+                    appListFiltered.clear()
+                    appListFiltered.addAll(appList)
                 }
             } catch (e: Throwable) {
                 withContext(Dispatchers.Main.immediate) {
@@ -78,7 +79,7 @@ class AppListDialogFragment : DialogFragment() {
     }
 
     private fun setButtonText() {
-        val numSelected = appData.count { it.isSelected }
+        val numSelected = appList.count { it.isSelected }
         button?.text = if (numSelected == 0)
             getString(R.string.use_all_applications)
         else when (tabs?.selectedTabPosition) {
@@ -106,15 +107,19 @@ class AppListDialogFragment : DialogFragment() {
         alertDialogBuilder.setNegativeButton(R.string.cancel) { dialog, _ -> dialog.dismiss() }
         alertDialogBuilder.setNeutralButton(R.string.toggle_all) { _, _ -> }
         binding.fragment = this
-        binding.appData = appData
+        binding.appData = appListFiltered
         loadData()
+        binding.appSearchText.doAfterTextChanged {
+            appListFiltered.clear()
+            appListFiltered.addAll(filter(it.toString()))
+        }
         val dialog = alertDialogBuilder.create()
         dialog.setOnShowListener {
             button = dialog.getButton(AlertDialog.BUTTON_POSITIVE)
             setButtonText()
             dialog.getButton(AlertDialog.BUTTON_NEUTRAL).setOnClickListener { _ ->
-                val selectAll = appData.none { it.isSelected }
-                appData.forEach {
+                val selectAll = appList.none { it.isSelected }
+                appList.forEach {
                     it.isSelected = selectAll
                 }
             }
@@ -122,9 +127,21 @@ class AppListDialogFragment : DialogFragment() {
         return dialog
     }
 
+    private fun filter(s: String): MutableList<ApplicationData> {
+        val resultData: MutableList<ApplicationData> = ArrayList()
+
+        for (app in appList) {
+            if (app.name.lowercase().contains(s)) {
+                resultData.add(app)
+            }
+        }
+
+        return resultData
+    }
+
     private fun setSelectionAndDismiss() {
         val selectedApps: MutableList<String> = ArrayList()
-        for (data in appData) {
+        for (data in appList) {
             if (data.isSelected) {
                 selectedApps.add(data.packageName)
             }
diff --git a/ui/src/main/res/layout/app_list_dialog_fragment.xml b/ui/src/main/res/layout/app_list_dialog_fragment.xml
index 4503de1..572996d 100644
--- a/ui/src/main/res/layout/app_list_dialog_fragment.xml
+++ b/ui/src/main/res/layout/app_list_dialog_fragment.xml
@@ -40,6 +40,21 @@
                 android:text="@string/include_in_tunnel" />
         </com.google.android.material.tabs.TabLayout>
 
+        <com.google.android.material.textfield.TextInputLayout
+            android:id="@+id/app_search_layout"
+            android:layout_width="match_parent"
+            android:layout_height="wrap_content"
+            android:padding="10dp">
+
+            <com.google.android.material.textfield.TextInputEditText
+                android:id="@+id/app_search_text"
+                android:layout_width="match_parent"
+                android:layout_height="wrap_content"
+                android:hint="@string/search"
+                android:imeOptions="actionDone" />
+
+        </com.google.android.material.textfield.TextInputLayout>
+
         <FrameLayout
             android:layout_width="match_parent"
             android:layout_height="match_parent"
diff --git a/ui/src/main/res/values/strings.xml b/ui/src/main/res/values/strings.xml
index 6c09019..80967ad 100644
--- a/ui/src/main/res/values/strings.xml
+++ b/ui/src/main/res/values/strings.xml
@@ -237,4 +237,5 @@
     <string name="biometric_prompt_private_key_title">Authenticate to view private key</string>
     <string name="biometric_auth_error">Authentication failure</string>
     <string name="biometric_auth_error_reason">Authentication failure: %s</string>
+    <string name="search">Search</string>
 </resources>
-- 
2.32.0.windows.2


From programmerjake at gmail.com  Thu Jun 16 01:48:08 2022
From: programmerjake at gmail.com (Jacob Lifshay)
Date: Wed, 15 Jun 2022 18:48:08 -0700
Subject: why not use ktime_get_clocktai_ts64
Message-ID: <CAC2bXD6FKSk1EEcw4QtqxengUvyCN2bfwzG5jFUvAPAsg2kxBA@mail.gmail.com>

I was reading in noise.c and noticed you use ktime_get_real_ts64 and
do manual adjustments (the current code is broken if/when there's
another leap second) rather than using ktime_get_clocktai_ts64 which
already handles compensation for leap seconds.

https://git.zx2c4.com/wireguard-linux/tree/drivers/net/wireguard/noise.c?id=7fae4596a269d2f9a6a7d1a8695c3a68ab34f7be#n501

Is there a reason for that?

Jacob

From tom.ty89 at gmail.com  Fri Jun 17 11:34:19 2022
From: tom.ty89 at gmail.com (Tom Yan)
Date: Fri, 17 Jun 2022 19:34:19 +0800
Subject: [PATCH] wg-quick: avoid traffics from momentarily leaking into the
 tunnel
Message-ID: <20220617113419.17329-1-tom.ty89@gmail.com>

The wireguard route table ip rule should stay as a NOP until the
`suppress_prefixlength 0 table main` rule is in effect. Therefore,
add the wireguard default route to its route table after the latter
rule is added.

Signed-off-by: Tom Yan <tom.ty89 at gmail.com>
---
 src/wg-quick/linux.bash | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/wg-quick/linux.bash b/src/wg-quick/linux.bash
index e4d4c4f..69e5bef 100755
--- a/src/wg-quick/linux.bash
+++ b/src/wg-quick/linux.bash
@@ -220,9 +220,9 @@ add_default() {
 	fi
 	local proto=-4 iptables=iptables pf=ip
 	[[ $1 == *:* ]] && proto=-6 iptables=ip6tables pf=ip6
-	cmd ip $proto route add "$1" dev "$INTERFACE" table $table
 	cmd ip $proto rule add not fwmark $table table $table
 	cmd ip $proto rule add table main suppress_prefixlength 0
+	cmd ip $proto route add "$1" dev "$INTERFACE" table $table
 
 	local marker="-m comment --comment \"wg-quick(8) rule for $INTERFACE\"" restore=$'*raw\n' nftable="wg-quick-$INTERFACE" nftcmd 
 	printf -v nftcmd '%sadd table %s %s\n' "$nftcmd" "$pf" "$nftable"
-- 
2.36.1


From Jason at zx2c4.com  Fri Jun 17 11:53:09 2022
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Fri, 17 Jun 2022 13:53:09 +0200
Subject: [PATCH] wg-quick: avoid traffics from momentarily leaking into
 the tunnel
In-Reply-To: <20220617113419.17329-1-tom.ty89@gmail.com>
References: <20220617113419.17329-1-tom.ty89@gmail.com>
Message-ID: <YqxrJRfTG+7WL16u@zx2c4.com>

On Fri, Jun 17, 2022 at 07:34:19PM +0800, Tom Yan wrote:
> The wireguard route table ip rule should stay as a NOP until the
> `suppress_prefixlength 0 table main` rule is in effect. Therefore,
> add the wireguard default route to its route table after the latter
> rule is added.
> 
> Signed-off-by: Tom Yan <tom.ty89 at gmail.com>

Applied, thanks.

> ---
>  src/wg-quick/linux.bash | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/src/wg-quick/linux.bash b/src/wg-quick/linux.bash
> index e4d4c4f..69e5bef 100755
> --- a/src/wg-quick/linux.bash
> +++ b/src/wg-quick/linux.bash
> @@ -220,9 +220,9 @@ add_default() {
>  	fi
>  	local proto=-4 iptables=iptables pf=ip
>  	[[ $1 == *:* ]] && proto=-6 iptables=ip6tables pf=ip6
> -	cmd ip $proto route add "$1" dev "$INTERFACE" table $table
>  	cmd ip $proto rule add not fwmark $table table $table
>  	cmd ip $proto rule add table main suppress_prefixlength 0
> +	cmd ip $proto route add "$1" dev "$INTERFACE" table $table
>  
>  	local marker="-m comment --comment \"wg-quick(8) rule for $INTERFACE\"" restore=$'*raw\n' nftable="wg-quick-$INTERFACE" nftcmd 
>  	printf -v nftcmd '%sadd table %s %s\n' "$nftcmd" "$pf" "$nftable"
> -- 
> 2.36.1
> 

From Jason at zx2c4.com  Fri Jun 17 11:56:23 2022
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Fri, 17 Jun 2022 13:56:23 +0200
Subject: why not use ktime_get_clocktai_ts64
In-Reply-To: <CAC2bXD6FKSk1EEcw4QtqxengUvyCN2bfwzG5jFUvAPAsg2kxBA@mail.gmail.com>
References: <CAC2bXD6FKSk1EEcw4QtqxengUvyCN2bfwzG5jFUvAPAsg2kxBA@mail.gmail.com>
Message-ID: <Yqxr57xeYHYI3F22@zx2c4.com>

Hi Jacob,

On Wed, Jun 15, 2022 at 06:48:08PM -0700, Jacob Lifshay wrote:
> I was reading in noise.c and noticed you use ktime_get_real_ts64 and
> do manual adjustments (the current code is broken if/when there's
> another leap second) rather than using ktime_get_clocktai_ts64 which
> already handles compensation for leap seconds.
> 
> https://git.zx2c4.com/wireguard-linux/tree/drivers/net/wireguard/noise.c?id=7fae4596a269d2f9a6a7d1a8695c3a68ab34f7be#n501
> 
> Is there a reason for that?

Not really I guess. The only requirement, though, is that the timestamps
are monotonic with respect to the particular localprivate-remotepublic
pairing of peers. So I'm not sure it matters?

Jason

From Jason at zx2c4.com  Fri Jun 17 13:52:21 2022
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Fri, 17 Jun 2022 15:52:21 +0200
Subject: [PATCH] feat: add search to app list
In-Reply-To: <20220615160705.898-1-epicstyt@gmail.com>
References: <20220615160705.898-1-epicstyt@gmail.com>
Message-ID: <CAHmME9okL1s6+EqxrO-qA18ci6G0G3v72=ks13tZj5C=T5Qacw@mail.gmail.com>

Please resubmit this with a proper commit subject, commit message, and
signed-off-by line.

From tom.ty89 at gmail.com  Fri Jun 17 16:13:25 2022
From: tom.ty89 at gmail.com (Tom Yan)
Date: Sat, 18 Jun 2022 00:13:25 +0800
Subject: Regarding the firewall rules added by wg-quick (on Linux)
Message-ID: <CAGnHSEmuBdNSXLjWxoakyO4PVgXQ9YF6R0WZgMEQD-Nv2=y4Hw@mail.gmail.com>

Hi all

I have a few doubts on the firewall rules added by wg-quick.

First of all, is there a reason that the fwmark-restoring rule is
unconditional? Shouldn't it consist of a connmark match (like the
fwmark-saving rule does on the fwmark)?

The next one is, what is the remaining rule intended to prevent
exactly? From the commit message the purpose seems to be "bogus
injected packets". I mean, was that referring to the fact that Linux
does not have a strong address/interface binding concept, that
normally / by default you can reach a host using IP assigned on any of
its interfaces, regardless of whether the interface is the one
connecting it the source host? And if so, is there wireguard-specific
security implication in it that has led to the introduction of the
rule?

Although I'm not entirely clear on its purpose yet, allow me to also
suggest in this email that perhaps we can use something like this
instead for nft:

ip daddr $WG_ADDRESS iifname != { "lo", "$WG_INTERFACE" } drop

Alternatively, if it is desired that the rules used for nft and
iptables should be more "coherent" to each other, allow me to also
suggest something like this:

-d $WG_ADDRESS ! -i lo -m addrtype ! --dst-type LOCAL --limit-iface-in -j DROP

which should be equivalent, AFAICT, to this in nft:

ip daddr $WG_ADDRESS iifname != "lo" fib daddr . iif type != local drop

Although it's very unlikely that it can be an issue in reality, it at
least seems to me that --src-type LOCAL does not necessarily imply -i
lo. I mean like while the replies could hardly go back to the
"original" / initiating host, but some host could actually send
packets with a source address that is a LOCAL address of this host,
and I don't suppose ! --src-type LOCAL will help filter those.

Sorry if this is all a bit too much of a "niche".

Regards,
Tom

From programmerjake at gmail.com  Sun Jun 19 06:16:46 2022
From: programmerjake at gmail.com (Jacob Lifshay)
Date: Sat, 18 Jun 2022 23:16:46 -0700
Subject: why not use ktime_get_clocktai_ts64
In-Reply-To: <Yqxr57xeYHYI3F22@zx2c4.com>
References: <CAC2bXD6FKSk1EEcw4QtqxengUvyCN2bfwzG5jFUvAPAsg2kxBA@mail.gmail.com>
 <Yqxr57xeYHYI3F22@zx2c4.com>
Message-ID: <CAC2bXD7g8QsFi_Cw5rpiPRBz_vEPa4SJQF7f7COyfMJq6kVq=g@mail.gmail.com>

On Fri, Jun 17, 2022, 04:56 Jason A. Donenfeld <Jason at zx2c4.com> wrote:
>
> Hi Jacob,
>
> On Wed, Jun 15, 2022 at 06:48:08PM -0700, Jacob Lifshay wrote:
> > I was reading in noise.c and noticed you use ktime_get_real_ts64 and
> > do manual adjustments (the current code is broken if/when there's
> > another leap second) rather than using ktime_get_clocktai_ts64 which
> > already handles compensation for leap seconds.
> >
> > https://git.zx2c4.com/wireguard-linux/tree/drivers/net/wireguard/noise.c?id=7fae4596a269d2f9a6a7d1a8695c3a68ab34f7be#n501
> >
> > Is there a reason for that?
>
> Not really I guess. The only requirement, though, is that the timestamps
> are monotonic with respect to the particular localprivate-remotepublic
> pairing of peers. So I'm not sure it matters?


ok. Apparently linux's TAI clock offset is often not set on linux
systems, so that's a good reason not to use it.

Do note that 10s is the wrong offset, the correct value is 37s iirc.

see also (related issue on tai64 crate -- also uses the wrong offset):
https://github.com/RustCrypto/formats/issues/675

Jacob

From alessio.nossa+list at gmail.com  Mon Jun 20 20:51:54 2022
From: alessio.nossa+list at gmail.com (Alessio Nossa)
Date: Mon, 20 Jun 2022 22:51:54 +0200
Subject: Bug restarting WireGuard using launchd on macOS
Message-ID: <CAMTfdYoJfHEWXBO2L5L4NrwutgjFo5egqmfQj0dCPz7=Kib80w@mail.gmail.com>

Hello,
I am running WireGuard (installed with wireguard-tools, using
HomeBrew) on macOS 12.4, launched using launchd. All works fine until
I try to restart it, always with launchd.
When WireGuard interface is restarted, it looks like it crashes/gets
deactivated immediately: if I run 'wg show' nothing is displayed, but
on the "server" peer I can see that the "Latest handshake" report the
time elapsed since last "com.example.wg.restartWg.plist" execution.
The launchd configurations, that I saved at "/Library/LaunchDaemons/"
are available at
https://gist.github.com/alessionossa/78f69b9451a130240e2057acbd4eb7f8

The log at "/tmp/com.example.wg.restartWg.err" of is
    06/20/22 21:51:18
    [+] Interface for wg1 is utun0
    [#] rm -f /var/run/wireguard/utun0.sock
    [#] rm -f /var/run/wireguard/wg1.name
    --- Restarting... ---
    [#] wireguard-go utun
    [+] Interface for wg1 is utun0
    [#] wg setconf utun0 /dev/fd/63
    [#] ifconfig utun0 inet 10.181.0.5/32 10.181.0.5 alias
    [#] ifconfig utun0 up
    [#] route -q -n add -inet 10.181.0.3/32 -interface utun0
    [#] route -q -n add -inet 10.181.0.254/32 -interface utun0
    [#] route -q -n add -inet 10.181.0.11/32 -interface utun0
    [+] Backgrounding route monitor
    --- Restarted! ---
    06/20/22 21:56:20
    wg-quick: `wg1' is not a WireGuard interface
    --- Restarting... ---
    [#] wireguard-go utun
    [+] Interface for wg1 is utun0
    [#] wg setconf utun0 /dev/fd/63
    [#] ifconfig utun0 inet 10.181.0.5/32 10.181.0.5 alias
    [#] ifconfig utun0 up
    [#] route -q -n add -inet 10.181.0.3/32 -interface utun0
    [#] route -q -n add -inet 10.181.0.254/32 -interface utun0
    [#] route -q -n add -inet 10.181.0.11/32 -interface utun0
    [+] Backgrounding route monitor


If some more Information is needed to debug the issue, I am available.

Best regards,
Alessio Nossa

From frank at deze.org  Sun Jun 26 17:51:44 2022
From: frank at deze.org (Frank Volf)
Date: Sun, 26 Jun 2022 19:51:44 +0200
Subject: [ANNOUNCE] wireguard-freebsd snapshot v0.0.20220615 is available
In-Reply-To: <20220615141140.96557C3411C@smtp.kernel.org>
References: <20220615141140.96557C3411C@smtp.kernel.org>
Message-ID: <672909d9-560f-3e83-3c9b-e3d69e8e70fa@deze.org>


Hi,

I tested this snapshot on my setup for 10 days now and it works 
perfectly without any problems.

My setup is fairly simple: central VPN server (FreeBSD 13.1), two 
servers on branch sites (each behind NAT) and a mobile Android client.
VPN's are used for management type activities, so no high bandwidth or 
low latency requirements needed.
So not sure if this setup is representative enough, but I'm happy with 
how it behaves.

There is one small feature that I would like to see: My central server 
has multiple public IP addresses and sometimes Wireguard needs to 
initiate a connection to one of the branch servers. Unfortunately, there 
is no way to specify which source address to use for that. Currently it 
appears to use a random IP address from the outgoing interface (mostly 
the first IP address configured on the external interface).
I would like to see the option to specify the IP address to be used for 
outgoing connections, that would be? much more convenient when you have 
to deal with upstream firewalls.
Not sure if this is a difficult thing to implement, but I would love to 
have it.

Anyway, thanks for all the work you guys did on this great product!!!

Kind regards,

Frank


Op 15-6-2022 om 16:11 schreef Jason A. Donenfeld:
> Hi,
>
> An experimental snapshot, v0.0.20220615, of WireGuard for FreeBSD has been
> been tagged in the git repository.
>
> At this time this code is new, unvetted, possibly buggy, and should be
> considered "experimental". It might contain security issues. We gladly
> welcome your testing and bug reports, but do keep in mind that this code
> is new, so some caution should be exercised at the moment for using it
> in mission critical environments.
>
> == Changes ==
>
> ? * ci: add FreeBSD 12.3 and 13.1
> ? * compat: update version to handle sbcreatecontrol() changes
>
> ? More fixes to the compat layer.
>
> ? * wg_noise: import hmac from crypto
> ? * crypto: inline blake2s convenience function
>
> ? A few crypto cleanups.
>
> This snapshot contains commits from: Jason A. Donenfeld, Joseph 
> Mingrone, and
> Ed Maste.
>
> The source repository is available at the usual location:
> ? git clone https://git.zx2c4.com/wireguard-freebsd
>
> This snapshot is available in compressed tarball form:
> https://git.zx2c4.com/wireguard-freebsd/snapshot/wireguard-freebsd-0.0.20220615.tar.xz
> ? SHA2-256: 
> ad6c42d20a7c0ad2989e729dd41ea5a6a019426b762dfd0c6417e340935cca82
>
> Thank you,
> Jason Donenfeld
>
>
 >



From Jason at zx2c4.com  Mon Jun 27 10:59:34 2022
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Mon, 27 Jun 2022 12:59:34 +0200
Subject: [ANNOUNCE] wireguard-linux-compat v1.0.20220627 released
Message-ID: <20220627105937.BCD68C3411D@smtp.kernel.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hello,

A new version, v1.0.20220627, of the backported WireGuard kernel module for
3.10 <= Linux <= 5.5.y has been tagged in the git repository.

== Changes ==

  * compat: drop Ubuntu 14.04
  
  We announced it was going to be EOL a long time ago, and now it finally is.
  
  * qemu: give up on RHEL8 in CI
  
  RHEL8 makes CI impossible and their kernel team doesn't accept patches to fix
  it. So just drop it from CI. This means that likely CentOS 8 "Stream" support
  will falter. If you're interested in having RHEL8 support up to date, please
  get in touch.
  
  * crypto: curve25519-x86_64: use in/out register constraints more precisely
  * queueing: use CFI-safe ptr_ring cleanup function
  * qemu: simplify RNG seeding
  * socket: free skb in send6 when ipv6 is disabled
  * socket: ignore v6 endpoints when ipv6 is disabled
  * qemu: enable ACPI for SMP
  * device: check for metadata_dst with skb_valid_dst()
  * netns: make routing loop test non-fatal
  * netns: limit parallelism to $(nproc) tests at once
  * qemu: use vports on arm
  * qemu: set panic_on_warn=1 from cmdline
  
  Various fixes from upstream, now backported.
  
  * compat: handle backported rng and blake2s
  
  Recent kernels did large backports of the RNG code and BLAKE2s, which the
  compat layer previously had various stubs for. Now the compat layer uses the
  properly backported code instead.

This release contains commits from: Jason A. Donenfeld, Wang Hai, and Nikolay 
Aleksandrov.

As always, the source is available at https://git.zx2c4.com/wireguard-linux-compat/
and information about the project is available at https://www.wireguard.com/ .

This version is available in compressed tarball form here:
  https://git.zx2c4.com/wireguard-linux-compat/snapshot/wireguard-linux-compat-1.0.20220627.tar.xz
  SHA2-256: 362d412693c8fe82de00283435818d5c5def7f15e2433a07a9fe99d0518f63c0

A PGP signature of that file decompressed is available here:
  https://git.zx2c4.com/wireguard-linux-compat/snapshot/wireguard-linux-compat-1.0.20220627.tar.asc
  Signing key: AB9942E6D4A4CFC3412620A749FC7012A5DE03AE
  Remember to unxz the tarball before verifying the signature.

If you're a package maintainer, please bump your package version. If you're a
user, the WireGuard team welcomes any and all feedback on this latest version.

Finally, WireGuard development thrives on donations. By popular demand, we
have a webpage for this: https://www.wireguard.com/donations/

Thank you,
Jason Donenfeld


-----BEGIN PGP SIGNATURE-----

iQJEBAEBCAAuFiEEq5lC5tSkz8NBJiCnSfxwEqXeA64FAmK5jY0QHGphc29uQHp4
MmM0LmNvbQAKCRBJ/HASpd4DroByD/44LVUG2mmvrbBWFuJ30gXeT7P4m8uNJJwB
Ykup/HcA/CSaKvhCqIFE+Vc2BqY/Ns8Tp3qucVwZ6EF80w42AICFwD8S+c8X88er
9LSbGvXiW3Pjvs2oXtiDnhgNZt/msM7EtLODkH3SuVoTaYcsecG5K42k+IcKrteR
Du5XfN4nuMGV4CSYoTQlyId9VLigEasb3CfA6yTV3VA7Ry4V+LTeE/Ngy1S5FNxj
UENZ5sptzA7OEwdgkb7gHw00MrHW3ptd5UUEQAai1rVWRl4pHNq2HC1VMsdkTbQ0
nWXEZWNcZT2dJWzxrsbtvGAzEQ/UoTyzzjckpTk5xHE4GAuG0tEIhMoFaD+knqDQ
gornocfeOjyZD5Tk86MM4rmGkICW3YGpqoEQrxrhzuUwZfytf1cl5Deock8ODjNF
PGfMEWmibVfW+/RHwIi/6niH644mdUlBEU+ilXstBXDSVpf4QhKzQYdqdV8v9xVh
OulrmVRikX8tMQ0b2hHbC5yh7u0K0QRJGqnRl36OrYNhF2Ny/zKcp5ASjDCNFDW4
o8++eQzzMqzLknmmWyrG9aeQeVvx6gOmqozItUz0uV4CGegq9m2CdXhsQyySpkqk
tWCWOaDrYjHHdV2YHVT3JlcS8/CTLI1nMIY2D+T8RTIeHb6546OyBUNG/zwUliVh
cAdOuxrEag==
=Jp6L
-----END PGP SIGNATURE-----

From wireguard at abstractbinary.org  Mon Jun  6 13:32:33 2022
From: wireguard at abstractbinary.org (Alexandru Scvortov)
Date: Mon, 06 Jun 2022 13:32:33 -0000
Subject: What's the purpose of the wg-quick firewall rules?
Message-ID: <fedd0d21-a55c-4e17-8dcf-dd348e157aee@www.fastmail.com>

Hi,

I'm trying to understand what the firewall rules that wg-quick adds do.

I see these rules being added:

```
table ip raw {
	chain PREROUTING {
		type filter hook prerouting priority raw; policy accept;
		iifname != "wg0" ip daddr 10.10.1.2 fib saddr type != local  counter drop
		iifname != "wg0" ip daddr 10.10.0.2 fib saddr type != local  counter drop
	}
}
table ip mangle {
	chain POSTROUTING {
		type filter hook postrouting priority mangle; policy accept;
		meta l4proto udp mark 0xca6c  counter ct mark set mark
	}

	chain PREROUTING {
		type filter hook prerouting priority mangle; policy accept;
		meta l4proto udp  counter meta mark set ct mark
	}
}
```

The `raw` rules seem fine, but I can't figure out what the `mangle` rules are for. They're added in `add_default`, so they have something to do with the "route all traffic through Wireguard" functionality, but removing them doesn't seem to break anything on my laptop.

I think the first iteration of these were added in commit ebcf1ef8b1ad in wireguard-tools, but the commit message is "wg-quick: linux: filter bogus injected packets and don't disable rpfilter", and that doesn't make it any clearer to me.

What breaks if these rules aren't present?

Thank you.

Cheers,
Alex

From yegorov.p at gmail.com  Tue Jun 21 14:20:09 2022
From: yegorov.p at gmail.com (Pavel Yegorov)
Date: Tue, 21 Jun 2022 17:20:09 +0300
Subject: Wireguard is loosing connection for no reason
Message-ID: <CADuzeTx8_ODe2gF_hN6nhVFh5j+pEYXZB6fpVcC23pD2LLwCsw@mail.gmail.com>

Hey folks!

I really need some advice, cause I just don't know how to deal with my problem.

So, I have a WG "server" on ubuntu 18.04.6 LTS, hosted in the oracle
free tier. I've installed wireguard using well-known
https://github.com/angristan/wireguard-install script. Then I've
generated several configs for my desktops, phones, etc. It connects
and runs perfectly, but sometimes it just freezes for no reason.
There's no connectivity issues or something like that. Logs on client
side says something like that:

2022-06-21 03:01:01.845: [TUN] [win] Keypair 17 created for peer 1
2022-06-21 03:01:01.846: [TUN] [win] Sending keepalive packet to peer
1 (SERVER_IP:SERVER_PORT)
2022-06-21 03:03:01.822: [TUN] [win] Sending handshake initiation to
peer 1 (SERVER_IP:SERVER_PORT)
2022-06-21 03:03:01.884: [TUN] [win] Receiving handshake response from
peer 1 (SERVER_IP:SERVER_PORT)
2022-06-21 03:03:01.884: [TUN] [win] Keypair 16 destroyed for peer 1
2022-06-21 03:03:01.884: [TUN] [win] Keypair 18 created for peer 1
2022-06-21 03:03:01.884: [TUN] [win] Sending keepalive packet to peer
1 (SERVER_IP:SERVER_PORT)
2022-06-21 03:05:02.058: [TUN] [win] Sending handshake initiation to
peer 1 (SERVER_IP:SERVER_PORT)
2022-06-21 03:05:02.106: [TUN] [win] Receiving handshake response from
peer 1 (SERVER_IP:SERVER_PORT)
2022-06-21 03:05:02.106: [TUN] [win] Keypair 17 destroyed for peer 1
2022-06-21 03:05:02.106: [TUN] [win] Keypair 19 created for peer 1
2022-06-21 03:05:02.106: [TUN] [win] Sending keepalive packet to peer
1 (SERVER_IP:SERVER_PORT)
2022-06-21 03:06:21.302: [TUN] [win] Retrying handshake with peer 1
(SERVER_IP:SERVER_PORT) because we stopped hearing back after 15
seconds
2022-06-21 03:06:21.302: [TUN] [win] Sending handshake initiation to
peer 1 (SERVER_IP:SERVER_PORT)
2022-06-21 03:06:26.423: [TUN] [win] Handshake for peer 1
(SERVER_IP:SERVER_PORT) did not complete after 5 seconds, retrying
(try 2)
2022-06-21 03:06:26.423: [TUN] [win] Sending handshake initiation to
peer 1 (SERVER_IP:SERVER_PORT)
2022-06-21 03:06:31.471: [TUN] [win] Handshake for peer 1
(SERVER_IP:SERVER_PORT) did not complete after 5 seconds, retrying
(try 3)
2022-06-21 03:06:31.473: [TUN] [win] Sending handshake initiation to
peer 1 (SERVER_IP:SERVER_PORT)
2022-06-21 03:06:36.517: [TUN] [win] Handshake for peer 1
(SERVER_IP:SERVER_PORT) did not complete after 5 seconds, retrying
(try 4)

If I reconnect WG client, it immediately connects and everything is ok.

Any advices? I tried to experiment with PersistentKeepAlive param (on
both sides!) that doesn't change anything.

My server cfg:

[Interface]
Address = 10.66.66.1/24,fd42:42:42::1/64
ListenPort = SERVER_PORT
PrivateKey = M?????Uyg4r3mo=

PostUp = iptables -I FORWARD -i ens3 -o wg0 -j ACCEPT; iptables -I
FORWARD -i wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -o ens3 -j
MASQUERADE; ip6tables -A FORWARD -i wg0 -j ACCEPT; ip6tables -t nat -A
POSTROUTING -o ens3 -j MASQUERADE; sudo iptables -I INPUT -i ens3 -p
udp --dport SERVER_PORT -m state --state NEW,ESTABLISHED -j ACCEPT
PostDown = iptables -D FORWARD -i ens3 -o wg0 -j ACCEPT; iptables -D
FORWARD -i wg0 -j ACCEPT; iptables -t nat -D POSTROUTING -o ens3 -j
MASQUERADE; ip6tables -D FORWARD -i wg0 -j ACCEPT; ip6tables -t nat -D
POSTROUTING -o ens3 -j MASQUERADE; sudo iptables -D INPUT -i ens3 -p
udp --dport SERVER_PORT -m state --state NEW,ESTABLISHED -j ACCEPT

### Client iphone
[Peer]
PublicKey = 0+V???????4HnM=
PresharedKey = s???????amJCxJyqcE=
AllowedIPs = 10.66.66.2/32,fd42:42:42::2/128

### Client mac
[Peer]
PublicKey = Tet4??????mI=
PresharedKey = Ld???r8=
AllowedIPs = 10.66.66.3/32,fd42:42:42::3/128

My client cfg

[Interface]
PrivateKey = 4Bp????=
Address = 10.66.66.2/32,fd42:42:42::2/128
DNS = 8.8.8.8,1.1.1.1

[Peer]
PublicKey = 5R?????c=
PresharedKey = sY????E=
Endpoint = SERVER_IP:SERVER_PORT
AllowedIPs = 0.0.0.0/0,::/0

some stats

root at oraclevpn:~# wg show all
interface: wg0
  public key: 5R?????c=
  private key: (hidden)
  listening port: SERVER_PORT

peer: 0+?????nM=
  preshared key: (hidden)
  endpoint: 666.666.666.666:11111
  allowed ips: 10.66.66.2/32, fd42:42:42::2/128
  latest handshake: 2 minutes, 2 seconds ago
  transfer: 533.52 MiB received, 5.18 GiB sent


-- 
Pavel Yegorov

From alan at meshify.app  Mon Jun 27 21:40:36 2022
From: alan at meshify.app (Alan Graham)
Date: Mon, 27 Jun 2022 14:40:36 -0700
Subject: Wireguard is loosing connection for no reason
In-Reply-To: <CADuzeTx8_ODe2gF_hN6nhVFh5j+pEYXZB6fpVcC23pD2LLwCsw@mail.gmail.com>
References: <CADuzeTx8_ODe2gF_hN6nhVFh5j+pEYXZB6fpVcC23pD2LLwCsw@mail.gmail.com>
Message-ID: <CAMeHLtxurTwgOOuHQg-xALwahH7yGcTrtCmEk6TU6krpN-fSTw@mail.gmail.com>

Hi Pavel,

I also have a VM in OCI, albeit with Oracle Linux and not Ubuntu.
It's working without issues.  Your PresharedKeys could be at fault
based on how you obfuscated them.  However, I would look at all the
other iptables rules that Oracle made in the VM.  They are long and
complicated and I believe at some point I just nuked them all.

You might also want to install Wireshark on the client and make a
capture when you're having the problem.  You can also remove the
fd42:42:42:2/128 references and see if that solves the problem.  I can
imagine switching from ipv4 to ipv6 could cause such a hiccup and I
don't actually have ipv6 setup in my config.  I'd also ensure you're
not using Oracle's NAT feature for your VM as theirs is not a NAT you
can run Wireguard behind.  Hopefully one of these suggestions will
help!

Best regards,
Alan



On Mon, Jun 27, 2022 at 4:07 AM Pavel Yegorov <yegorov.p at gmail.com> wrote:
>
> Hey folks!
>
> I really need some advice, cause I just don't know how to deal with my problem.
>
> So, I have a WG "server" on ubuntu 18.04.6 LTS, hosted in the oracle
> free tier. I've installed wireguard using well-known
> https://github.com/angristan/wireguard-install script. Then I've
> generated several configs for my desktops, phones, etc. It connects
> and runs perfectly, but sometimes it just freezes for no reason.
> There's no connectivity issues or something like that. Logs on client
> side says something like that:
>
> 2022-06-21 03:01:01.845: [TUN] [win] Keypair 17 created for peer 1
> 2022-06-21 03:01:01.846: [TUN] [win] Sending keepalive packet to peer
> 1 (SERVER_IP:SERVER_PORT)
> 2022-06-21 03:03:01.822: [TUN] [win] Sending handshake initiation to
> peer 1 (SERVER_IP:SERVER_PORT)
> 2022-06-21 03:03:01.884: [TUN] [win] Receiving handshake response from
> peer 1 (SERVER_IP:SERVER_PORT)
> 2022-06-21 03:03:01.884: [TUN] [win] Keypair 16 destroyed for peer 1
> 2022-06-21 03:03:01.884: [TUN] [win] Keypair 18 created for peer 1
> 2022-06-21 03:03:01.884: [TUN] [win] Sending keepalive packet to peer
> 1 (SERVER_IP:SERVER_PORT)
> 2022-06-21 03:05:02.058: [TUN] [win] Sending handshake initiation to
> peer 1 (SERVER_IP:SERVER_PORT)
> 2022-06-21 03:05:02.106: [TUN] [win] Receiving handshake response from
> peer 1 (SERVER_IP:SERVER_PORT)
> 2022-06-21 03:05:02.106: [TUN] [win] Keypair 17 destroyed for peer 1
> 2022-06-21 03:05:02.106: [TUN] [win] Keypair 19 created for peer 1
> 2022-06-21 03:05:02.106: [TUN] [win] Sending keepalive packet to peer
> 1 (SERVER_IP:SERVER_PORT)
> 2022-06-21 03:06:21.302: [TUN] [win] Retrying handshake with peer 1
> (SERVER_IP:SERVER_PORT) because we stopped hearing back after 15
> seconds
> 2022-06-21 03:06:21.302: [TUN] [win] Sending handshake initiation to
> peer 1 (SERVER_IP:SERVER_PORT)
> 2022-06-21 03:06:26.423: [TUN] [win] Handshake for peer 1
> (SERVER_IP:SERVER_PORT) did not complete after 5 seconds, retrying
> (try 2)
> 2022-06-21 03:06:26.423: [TUN] [win] Sending handshake initiation to
> peer 1 (SERVER_IP:SERVER_PORT)
> 2022-06-21 03:06:31.471: [TUN] [win] Handshake for peer 1
> (SERVER_IP:SERVER_PORT) did not complete after 5 seconds, retrying
> (try 3)
> 2022-06-21 03:06:31.473: [TUN] [win] Sending handshake initiation to
> peer 1 (SERVER_IP:SERVER_PORT)
> 2022-06-21 03:06:36.517: [TUN] [win] Handshake for peer 1
> (SERVER_IP:SERVER_PORT) did not complete after 5 seconds, retrying
> (try 4)
>
> If I reconnect WG client, it immediately connects and everything is ok.
>
> Any advices? I tried to experiment with PersistentKeepAlive param (on
> both sides!) that doesn't change anything.
>
> My server cfg:
>
> [Interface]
> Address = 10.66.66.1/24,fd42:42:42::1/64
> ListenPort = SERVER_PORT
> PrivateKey = M?????Uyg4r3mo=
>
> PostUp = iptables -I FORWARD -i ens3 -o wg0 -j ACCEPT; iptables -I
> FORWARD -i wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -o ens3 -j
> MASQUERADE; ip6tables -A FORWARD -i wg0 -j ACCEPT; ip6tables -t nat -A
> POSTROUTING -o ens3 -j MASQUERADE; sudo iptables -I INPUT -i ens3 -p
> udp --dport SERVER_PORT -m state --state NEW,ESTABLISHED -j ACCEPT
> PostDown = iptables -D FORWARD -i ens3 -o wg0 -j ACCEPT; iptables -D
> FORWARD -i wg0 -j ACCEPT; iptables -t nat -D POSTROUTING -o ens3 -j
> MASQUERADE; ip6tables -D FORWARD -i wg0 -j ACCEPT; ip6tables -t nat -D
> POSTROUTING -o ens3 -j MASQUERADE; sudo iptables -D INPUT -i ens3 -p
> udp --dport SERVER_PORT -m state --state NEW,ESTABLISHED -j ACCEPT
>
> ### Client iphone
> [Peer]
> PublicKey = 0+V???????4HnM=
> PresharedKey = s???????amJCxJyqcE=
> AllowedIPs = 10.66.66.2/32,fd42:42:42::2/128
>
> ### Client mac
> [Peer]
> PublicKey = Tet4??????mI=
> PresharedKey = Ld???r8=
> AllowedIPs = 10.66.66.3/32,fd42:42:42::3/128
>
> My client cfg
>
> [Interface]
> PrivateKey = 4Bp????=
> Address = 10.66.66.2/32,fd42:42:42::2/128
> DNS = 8.8.8.8,1.1.1.1
>
> [Peer]
> PublicKey = 5R?????c=
> PresharedKey = sY????E=
> Endpoint = SERVER_IP:SERVER_PORT
> AllowedIPs = 0.0.0.0/0,::/0
>
> some stats
>
> root at oraclevpn:~# wg show all
> interface: wg0
>   public key: 5R?????c=
>   private key: (hidden)
>   listening port: SERVER_PORT
>
> peer: 0+?????nM=
>   preshared key: (hidden)
>   endpoint: 666.666.666.666:11111
>   allowed ips: 10.66.66.2/32, fd42:42:42::2/128
>   latest handshake: 2 minutes, 2 seconds ago
>   transfer: 533.52 MiB received, 5.18 GiB sent
>
>
> --
> Pavel Yegorov

From Jason at zx2c4.com  Tue Jun 28 11:44:20 2022
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Tue, 28 Jun 2022 13:44:20 +0200
Subject: The Future of RHEL7,8 Support in WireGuard
Message-ID: <YrrplG8DswM0zxQO@zx2c4.com>

Hi folks,

I'm confronted with a few hard facts, the first of which is good and
exciting, and the rest are kind of disappointing:

  1) RHEL9 has WireGuard baked into it by default, so there's no
     required compatibility backporting for it. If you use RHEL9, you
     can use WireGuard easily.

  2) The RHEL7 and RHEL8 kernels have build errors due to trivially dumb
     mismerges, if you try to build them using nearly anything other
     than the RHEL-supplied .config files. I've reported these bugs to
     Red Hat and I've sent series fixing these bugs (see this git repo,
     for example: https://git.zx2c4.com/rhel7-kernel-misery/log/ ), but
     Red Hat's perspective is that these are non-bugs that they won't
     fix, since the only purpose of the kernel for them is their own
     configs.

  3) Those build errors make it difficult to run WireGuard's CI on them
     without having to apply lots of extra patches. While RHEL7 is
     mostly set in stone now, the C8S kernel changes frequently.
     Recently I dropped RHEL from the CI, as C8S hadn't been building
     for some time. So now I have no way of ensuring that it continues
     to work.
 
  4) RHEL7 and RHEL8 is a behind-closed-door process, which makes
     tracking down new breakage and dealing with anything produced by it
     an exercise in pain.

  5) No companies who are using RHEL7 or RHEL8 with WireGuard have
     reached out to me about trying to fund this work. (And in general,
     now that WireGuard isn't a hip new marketing thing for VPN
     providers and whomever, funding has significantly dropped off.)

Given all this, I wonder whether the RHEL7 and RHEL8 backports have a
future, and if they do, what that future looks like.

Note, this isn't just a matter of "backporting is hard work that nobody
likes to do, but you do it anyway because that's what you gotta do."
Because in contrast, I'm quite content doing backports for the
kernel.org stable kernels that Greg and Sasha release. The process is
open and transparent, Greg and Sasha are nice to work with, the goals
are clear, the outcomes are dependable. It is still always work, but
developing for kernel.org stable kernels is reasonable engineering work,
as opposed to RHEL backporting, which is fighting uphill against
byzantine bureaucratic processes that aren't very welcoming of my
objectives.

And to be clear, it's not as though Red Hat is somehow evil here. Their
goals simply aren't aligned. The kernel.org stable releases are meant to
be general kernels that you can do things with, developed as part of an
open source project. The RHEL kernel, by contrast, is part of a
commercial product with a very specific single goal in mind. That's
fine, and there's nothing inherently wrong with that.

So when Red Hat tells me, "sorry, why should we care about this? RHEL7
and 8 don't support WireGuard. Tell people to use RHEL9 for that. We're
not going to make your life easier in RHEL7 and 8. It's not supported,"
I sigh exasperated, because as frustrating as their position is, it's
also an entirely reasonable position for them to have, based on what
their goals are and what they're doing.

That all is a very long way of saying that continuing to backport
WireGuard to RHEL7 and 8 kernels in the normal way with WireGuard's CI
as it currently exists is an uphill battle, just due to the nature of
the thing. It's constant struggle to put the square peg in the round
hole.

So what are our options here moving forward?

  A) I rip out RHEL7 and RHEL8 support completely, and expect people to
     just use RHEL9.

  B) Somebody extremely motivated and associated with Alma Linux or
     Rocky Linux or Oracle sets up a dedicated CI server using the
     official kernel builds and kernel headers, and runs `make test` on
     every commit to either the kernels or to wireguard-linux-compat,
     and then either:

      i) has the CI automatically send me an email notification on
         breakage so I can fix it like usual; or
     ii) fixes it and sends a proper patch to the mailing list in the
         correct style and format.
     
     Either one of those would work. (ii) would be nice, but there
     aren't tons of people who like both CI devops and kernel
     development, so I'd be fine with (i) too, which is more or less the
     status quo but with functional CI.

     Note, though, that this option (B) would have to be done well and
     reliably. Were it organizationally flaky, I'd prefer to do (A), as
     half-baked approaches tend to be worse than nothing.

     If this interests any readers with the backing of large
     RHEL-derivative projects, please get in touch.

  C) Several companies who are using WireGuard with RHEL7 and RHEL8
     provide significant project funding, and then I take care of
     setting up dedicated and reliable RHEL CI for the project, using
     official kernel builds and kernel headers. I could do this quite
     well, but it doesn't seem right to do that without real funding for
     it.

     If this interests any corporate readers, please get in touch.

  D) Other ideas the mailing list might have.

So that's about where my thinking is at the moment. As usual, I'm not
going to rush into any decision, and I'll do my best to keep RHEL
support as afloat as I can until a careful decision in one of these
directions has been made. None of this email is written with any real
sense of urgency. But still, I'd like to at some point choose a
direction and commit to it.

Let me know what you think.

Regards,
Jason

From alex_y_xu at yahoo.ca  Tue Jun 28 15:02:40 2022
From: alex_y_xu at yahoo.ca (Alex Xu (Hello71))
Date: Tue, 28 Jun 2022 11:02:40 -0400
Subject: CONFIG_ANDROID (was: rcu_sched detected expedited stalls in amdgpu
 after suspend)
In-Reply-To: <20220628041252.GV1790663@paulmck-ThinkPad-P17-Gen-1>
References: <1656357116.rhe0mufk6a.none.ref@localhost>
 <1656357116.rhe0mufk6a.none@localhost>
 <20220627204139.GL1790663@paulmck-ThinkPad-P17-Gen-1>
 <1656379893.q9yb069erk.none@localhost>
 <20220628041252.GV1790663@paulmck-ThinkPad-P17-Gen-1>
Message-ID: <1656421946.ic03168yc3.none@localhost>

Excerpts from Paul E. McKenney's message of June 28, 2022 12:12 am:
> On Mon, Jun 27, 2022 at 09:50:53PM -0400, Alex Xu (Hello71) wrote:
>> Ah, I see. I have selected the default value for 
>> CONFIG_RCU_EXP_CPU_STALL_TIMEOUT, but that is 20 if ANDROID. I am not 
>> using Android; I'm not sure there exist Android devices with AMD GPUs. 
>> However, I have set CONFIG_ANDROID=y in order to use 
>> ANDROID_BINDER_IPC=m for emulation.
>> 
>> In general, I think CONFIG_ANDROID is not a reliable method for 
>> detecting if the kernel is for an Android device; for example, Fedora 
>> sets CONFIG_ANDROID, but (AFAIK) its kernel is not intended for use with 
>> Android userspace.
>> 
>> On the other hand, it's not clear to me why the value 20 should be for 
>> Android only anyways. If, as you say in 
>> https://lore.kernel.org/lkml/20220216195508.GM4285 at paulmck-ThinkPad-P17-Gen-1/,
>> it is related to the size of the system, perhaps some other heuristic 
>> would be more appropriate.
> 
> It is related to the fact that quite a few Android guys want these
> 20-millisecond short-timeout expedited RCU CPU stall warnings, but no one
> else does.  Not yet anyway.
> 
> And let's face it, the intent and purpose of CONFIG_ANDROID=y is extremely
> straightforward and unmistakeable.  So perhaps people not running Android
> devices but wanting a little bit of the Android functionality should do
> something other than setting CONFIG_ANDROID=y in their .config files.  Me,
> I am surprised that it took this long for something like this to bite you.
> 
> But just out of curiosity, what would you suggest instead?

Both Debian and Fedora set CONFIG_ANDROID, specifically for binder. If 
major distro vendors are consistently making this "mistake", then 
perhaps the problem is elsewhere.

In my own opinion, assuming that binderfs means Android vendor is not a 
good assumption. The ANDROID help says:

> Enable support for various drivers needed on the Android platform

It doesn't say "Enable only if building an Android device", or "Enable 
only if you are Google". Isn't the traditional Linux philosophy a 
collection of pieces to be assembled, without gratuitous hidden 
dependencies? For example, [0] removes the unnecessary Android 
dependency, it doesn't block the whole thing with "depends on ANDROID".

It seems to me that the proper way to set some configuration for Android 
kernels is or should be to ask the Android kernel config maintainers, 
not to set it based on an upstream kernel option. There is, after all, 
no CONFIG_FEDORA or CONFIG_UBUNTU or CONFIG_HANNAH_MONTANA.

WireGuard and random also use CONFIG_ANDROID in a similar "proxy" way as 
rcu, there to see if suspends are "frequent". This seems dubious for the 
same reasons.

I wonder if it might be time to retire CONFIG_ANDROID: the only 
remaining driver covered is binder, which originates from Android but 
is no longer used exclusively on Android systems. Like ufs-qcom, binder 
is no longer used exclusively on Android devices; it is also used for 
Android device emulators, which might be used on Android-like mobile 
devices, or might not.

My understanding is that both Android and upstream kernel developers 
intend to add no more Android-specific drivers, so binder should be the 
only one covered for the foreseeable future.

> For that matter, why the private reply?

Mail client issues, not intentional. Lists re-added, plus Android, 
WireGuard, and random.

Thanks,
Alex.

[0] https://lore.kernel.org/all/20220321151853.24138-1-krzk at kernel.org/

From Jason at zx2c4.com  Tue Jun 28 15:13:24 2022
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Tue, 28 Jun 2022 17:13:24 +0200
Subject: CONFIG_ANDROID (was: rcu_sched detected expedited stalls in
 amdgpu after suspend)
In-Reply-To: <1656421946.ic03168yc3.none@localhost>
References: <1656357116.rhe0mufk6a.none.ref@localhost>
 <1656357116.rhe0mufk6a.none@localhost>
 <20220627204139.GL1790663@paulmck-ThinkPad-P17-Gen-1>
 <1656379893.q9yb069erk.none@localhost>
 <20220628041252.GV1790663@paulmck-ThinkPad-P17-Gen-1>
 <1656421946.ic03168yc3.none@localhost>
Message-ID: <YrsalGetwIfl8Wkw@zx2c4.com>

Hi Alex,

On Tue, Jun 28, 2022 at 11:02:40AM -0400, Alex Xu (Hello71) wrote:
> WireGuard and random also use CONFIG_ANDROID in a similar "proxy" way as 
> rcu, there to see if suspends are "frequent". This seems dubious for the 
> same reasons.

I'd be happy to take a patch in WireGuard and random.c to get rid of the
CONFIG_ANDROID usage, if you can conduct an analysis and conclude this
won't break anything inadvertently.

Jason

From clint at openziti.org  Tue Jun 28 17:28:59 2022
From: clint at openziti.org (Clint Dovholuk)
Date: Tue, 28 Jun 2022 13:28:59 -0400
Subject: seems that https://www.wintun.net/ down?
In-Reply-To: 12712d56014ffcc92045c59c79c49a64@mail.gmail.com
References: 12712d56014ffcc92045c59c79c49a64@mail.gmail.com
Message-ID: <1559d27e5d07780e786f5095afae9077@mail.gmail.com>

Is this expected? We grab the distributions of wintun to use in our builds
but are having trouble getting them now. Should we be caching these on our
own servers to avoid the bandwidth costs to wintun?

Thanks
-Clint

From Jason at zx2c4.com  Tue Jun 28 17:59:44 2022
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Tue, 28 Jun 2022 19:59:44 +0200
Subject: seems that https://www.wintun.net/ down?
In-Reply-To: <1559d27e5d07780e786f5095afae9077@mail.gmail.com>
References: <1559d27e5d07780e786f5095afae9077@mail.gmail.com>
Message-ID: <CAHmME9r0Ak-pr748Z9BHj7c3AKo8EkCDG5TYLG8DmPKXja8LRA@mail.gmail.com>

Equinix Metal had a network connectivity incident and during the
resolution apparently unplugged a server. Things are back up now. They
told me the hardware I'm using is deprecated anyway, so I'll be
migrating to a more reliable machine in the next few days.

Jason

From paulmck at kernel.org  Tue Jun 28 18:54:37 2022
From: paulmck at kernel.org (Paul E. McKenney)
Date: Tue, 28 Jun 2022 11:54:37 -0700
Subject: CONFIG_ANDROID (was: rcu_sched detected expedited stalls in
 amdgpu after suspend)
In-Reply-To: <1656421946.ic03168yc3.none@localhost>
References: <1656357116.rhe0mufk6a.none.ref@localhost>
 <1656357116.rhe0mufk6a.none@localhost>
 <20220627204139.GL1790663@paulmck-ThinkPad-P17-Gen-1>
 <1656379893.q9yb069erk.none@localhost>
 <20220628041252.GV1790663@paulmck-ThinkPad-P17-Gen-1>
 <1656421946.ic03168yc3.none@localhost>
Message-ID: <20220628185437.GA1790663@paulmck-ThinkPad-P17-Gen-1>

On Tue, Jun 28, 2022 at 11:02:40AM -0400, Alex Xu (Hello71) wrote:
> Excerpts from Paul E. McKenney's message of June 28, 2022 12:12 am:
> > On Mon, Jun 27, 2022 at 09:50:53PM -0400, Alex Xu (Hello71) wrote:
> >> Ah, I see. I have selected the default value for 
> >> CONFIG_RCU_EXP_CPU_STALL_TIMEOUT, but that is 20 if ANDROID. I am not 
> >> using Android; I'm not sure there exist Android devices with AMD GPUs. 
> >> However, I have set CONFIG_ANDROID=y in order to use 
> >> ANDROID_BINDER_IPC=m for emulation.
> >> 
> >> In general, I think CONFIG_ANDROID is not a reliable method for 
> >> detecting if the kernel is for an Android device; for example, Fedora 
> >> sets CONFIG_ANDROID, but (AFAIK) its kernel is not intended for use with 
> >> Android userspace.
> >> 
> >> On the other hand, it's not clear to me why the value 20 should be for 
> >> Android only anyways. If, as you say in 
> >> https://lore.kernel.org/lkml/20220216195508.GM4285 at paulmck-ThinkPad-P17-Gen-1/,
> >> it is related to the size of the system, perhaps some other heuristic 
> >> would be more appropriate.
> > 
> > It is related to the fact that quite a few Android guys want these
> > 20-millisecond short-timeout expedited RCU CPU stall warnings, but no one
> > else does.  Not yet anyway.
> > 
> > And let's face it, the intent and purpose of CONFIG_ANDROID=y is extremely
> > straightforward and unmistakeable.  So perhaps people not running Android
> > devices but wanting a little bit of the Android functionality should do
> > something other than setting CONFIG_ANDROID=y in their .config files.  Me,
> > I am surprised that it took this long for something like this to bite you.
> > 
> > But just out of curiosity, what would you suggest instead?
> 
> Both Debian and Fedora set CONFIG_ANDROID, specifically for binder. If 
> major distro vendors are consistently making this "mistake", then 
> perhaps the problem is elsewhere.
> 
> In my own opinion, assuming that binderfs means Android vendor is not a 
> good assumption. The ANDROID help says:
> 
> > Enable support for various drivers needed on the Android platform
> 
> It doesn't say "Enable only if building an Android device", or "Enable 
> only if you are Google". Isn't the traditional Linux philosophy a 
> collection of pieces to be assembled, without gratuitous hidden 
> dependencies? For example, [0] removes the unnecessary Android 
> dependency, it doesn't block the whole thing with "depends on ANDROID".
> 
> It seems to me that the proper way to set some configuration for Android 
> kernels is or should be to ask the Android kernel config maintainers, 
> not to set it based on an upstream kernel option. There is, after all, 
> no CONFIG_FEDORA or CONFIG_UBUNTU or CONFIG_HANNAH_MONTANA.
> 
> WireGuard and random also use CONFIG_ANDROID in a similar "proxy" way as 
> rcu, there to see if suspends are "frequent". This seems dubious for the 
> same reasons.
> 
> I wonder if it might be time to retire CONFIG_ANDROID: the only 
> remaining driver covered is binder, which originates from Android but 
> is no longer used exclusively on Android systems. Like ufs-qcom, binder 
> is no longer used exclusively on Android devices; it is also used for 
> Android device emulators, which might be used on Android-like mobile 
> devices, or might not.
> 
> My understanding is that both Android and upstream kernel developers 
> intend to add no more Android-specific drivers, so binder should be the 
> only one covered for the foreseeable future.

Thank you for the perspective, but you never did suggest an alternative.

So here is is what I suggest given the current setup:

config RCU_EXP_CPU_STALL_TIMEOUT
	int "Expedited RCU CPU stall timeout in milliseconds"
	depends on RCU_STALL_COMMON
	range 0 21000
	default 20 if ANDROID
	default 0 if !ANDROID
	help
	  If a given expedited RCU grace period extends more than the
	  specified number of milliseconds, a CPU stall warning is printed.
	  If the RCU grace period persists, additional CPU stall warnings
	  are printed at more widely spaced intervals.  A value of zero
	  says to use the RCU_CPU_STALL_TIMEOUT value converted from
	  seconds to milliseconds.

The default, and only the default, is controlled by ANDROID.

All you need to do to get the previous behavior is to add something like
this to your defconfig file:

CONFIG_RCU_EXP_CPU_STALL_TIMEOUT=21000

Any reason why this will not work for you?

> > For that matter, why the private reply?
> 
> Mail client issues, not intentional. Lists re-added, plus Android, 
> WireGuard, and random.

Thank you!

							Thanx, Paul

> Thanks,
> Alex.
> 
> [0] https://lore.kernel.org/all/20220321151853.24138-1-krzk at kernel.org/

From alex_y_xu at yahoo.ca  Tue Jun 28 19:28:26 2022
From: alex_y_xu at yahoo.ca (Alex Xu (Hello71))
Date: Tue, 28 Jun 2022 15:28:26 -0400
Subject: CONFIG_ANDROID (was: rcu_sched detected expedited stalls in
 amdgpu after suspend)
In-Reply-To: <20220628185437.GA1790663@paulmck-ThinkPad-P17-Gen-1>
References: <1656357116.rhe0mufk6a.none.ref@localhost>
 <1656357116.rhe0mufk6a.none@localhost>
 <20220627204139.GL1790663@paulmck-ThinkPad-P17-Gen-1>
 <1656379893.q9yb069erk.none@localhost>
 <20220628041252.GV1790663@paulmck-ThinkPad-P17-Gen-1>
 <1656421946.ic03168yc3.none@localhost>
 <20220628185437.GA1790663@paulmck-ThinkPad-P17-Gen-1>
Message-ID: <1656443915.mdjoauhqe0.none@localhost>

Excerpts from Paul E. McKenney's message of June 28, 2022 2:54 pm:
> All you need to do to get the previous behavior is to add something like
> this to your defconfig file:
> 
> CONFIG_RCU_EXP_CPU_STALL_TIMEOUT=21000
> 
> Any reason why this will not work for you?

As far as I know, I do not require any particular RCU debugging features 
intended for developers; as an individual user and distro maintainer, I 
would like to select the option corresponding to "emit errors for 
unexpected conditions which should be reported upstream", not "emit 
debugging information for development purposes".

Therefore, I think 0 is a suitable setting for me and most ordinary 
(not tightly controlled) distributions. My concern is that other users 
and distro maintainers will also have confusion about what value to set 
and whether the warnings are important, since the help text does not say 
anything about Android, and "make oldconfig" does not indicate that the 
default value is different for Android.

My suggestion is that the default be set to 0, and if a non-zero value 
is appropriate for Android, that should be communicated to the Android 
developers, not made conditional on CONFIG_ANDROID.

Thanks,
Alex.

From peljasz at yahoo.co.uk  Wed Jun 29 12:13:55 2022
From: peljasz at yahoo.co.uk (lejeczek)
Date: Wed, 29 Jun 2022 13:13:55 +0100
Subject: package from fedorainfracloud for centOS 8 does not build
References: <b05c9019-5165-84f0-b3f1-a0eeb30faad1.ref@yahoo.co.uk>
Message-ID: <b05c9019-5165-84f0-b3f1-a0eeb30faad1@yahoo.co.uk>

Hi guys.

In case somebody here looks after 
'copr:copr.fedorainfracloud.org:jdoss:wireguard' then

wireguard-dkms-1.0.20220627-1.el8.noarch for 4.18.0-394.el8.x86_64 fails 
to build

many thanks, L.


From urezki at gmail.com  Tue Jun 28 20:11:37 2022
From: urezki at gmail.com (Uladzislau Rezki)
Date: Tue, 28 Jun 2022 22:11:37 +0200
Subject: CONFIG_ANDROID (was: rcu_sched detected expedited stalls in
 amdgpu after suspend)
In-Reply-To: <1656443915.mdjoauhqe0.none@localhost>
References: <1656357116.rhe0mufk6a.none.ref@localhost>
 <1656357116.rhe0mufk6a.none@localhost>
 <20220627204139.GL1790663@paulmck-ThinkPad-P17-Gen-1>
 <1656379893.q9yb069erk.none@localhost>
 <20220628041252.GV1790663@paulmck-ThinkPad-P17-Gen-1>
 <1656421946.ic03168yc3.none@localhost>
 <20220628185437.GA1790663@paulmck-ThinkPad-P17-Gen-1>
 <1656443915.mdjoauhqe0.none@localhost>
Message-ID: <YrtgeSmwLmpzN/zw@pc638>

> Excerpts from Paul E. McKenney's message of June 28, 2022 2:54 pm:
> > All you need to do to get the previous behavior is to add something like
> > this to your defconfig file:
> > 
> > CONFIG_RCU_EXP_CPU_STALL_TIMEOUT=21000
> > 
> > Any reason why this will not work for you?
> 
> As far as I know, I do not require any particular RCU debugging features 
> intended for developers; as an individual user and distro maintainer, I 
> would like to select the option corresponding to "emit errors for 
> unexpected conditions which should be reported upstream", not "emit 
> debugging information for development purposes".
> 
Sorry but we need to apply some assumption, i.e. to me the CONFIG_ANDROID
indicates that a kernel runs on the Android wise device. When you enable
this option on you specific box it is supposed that some Android related
code are activated also on your device which may lead to some side effect.

>
> Therefore, I think 0 is a suitable setting for me and most ordinary 
> (not tightly controlled) distributions. My concern is that other users 
> and distro maintainers will also have confusion about what value to set 
> and whether the warnings are important, since the help text does not say 
> anything about Android, and "make oldconfig" does not indicate that the 
> default value is different for Android.
> 
<snip>
diff --git a/kernel/rcu/Kconfig.debug b/kernel/rcu/Kconfig.debug
index 9b64e55d4f61..ced0d1f7c675 100644
--- a/kernel/rcu/Kconfig.debug
+++ b/kernel/rcu/Kconfig.debug
@@ -94,7 +94,8 @@ config RCU_EXP_CPU_STALL_TIMEOUT
          If the RCU grace period persists, additional CPU stall warnings
          are printed at more widely spaced intervals.  A value of zero
          says to use the RCU_CPU_STALL_TIMEOUT value converted from
-         seconds to milliseconds.
+         seconds to milliseconds. If CONFIG_ANDROID is set for non-Android
+         platform and you unsure, set the RCU_EXP_CPU_STALL_TIMEOUT to zero.

 config RCU_TRACE
        bool "Enable tracing for RCU"
<snip>

Will it work for you?

--
Uladzislau Rezki

From Jason at zx2c4.com  Wed Jun 29 12:27:30 2022
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Wed, 29 Jun 2022 14:27:30 +0200
Subject: package from fedorainfracloud for centOS 8 does not build
In-Reply-To: <b05c9019-5165-84f0-b3f1-a0eeb30faad1@yahoo.co.uk>
References: <b05c9019-5165-84f0-b3f1-a0eeb30faad1.ref@yahoo.co.uk>
 <b05c9019-5165-84f0-b3f1-a0eeb30faad1@yahoo.co.uk>
Message-ID: <CAHmME9o5Qpg_oHjWFBa6zoVZd4ALOpBnjj7Y-y_ipgtZ4+o_qQ@mail.gmail.com>

On Wed, Jun 29, 2022 at 2:17 PM lejeczek <peljasz at yahoo.co.uk> wrote:
>
> Hi guys.
>
> In case somebody here looks after
> 'copr:copr.fedorainfracloud.org:jdoss:wireguard' then
>
> wireguard-dkms-1.0.20220627-1.el8.noarch for 4.18.0-394.el8.x86_64 fails
> to build
>
> many thanks, L.

https://lists.zx2c4.com/pipermail/wireguard/2022-June/007664.html

From gregkh at linuxfoundation.org  Wed Jun 29 15:27:21 2022
From: gregkh at linuxfoundation.org (Greg Kroah-Hartman)
Date: Wed, 29 Jun 2022 17:27:21 +0200
Subject: [PATCH] remove CONFIG_ANDROID
In-Reply-To: <20220629150102.1582425-2-hch@lst.de>
References: <20220629150102.1582425-1-hch@lst.de>
 <20220629150102.1582425-2-hch@lst.de>
Message-ID: <YrxvWT/aeQnwEv52@kroah.com>

On Wed, Jun 29, 2022 at 05:01:02PM +0200, Christoph Hellwig wrote:
> The ANDROID config symbol is only used to guard the binder config
> symbol and to inject completely random config changes.  Remove it
> as it is obviously a bad idea.

Ick, rcu and random driver changes?  That's not ok, I'll go queue this
up, if Android devices need to make these core changes, they can do that
in their kernel or submit a patch that makes sense for everyone.

Also, one meta-comment:

>  kernel/configs/android-base.config                  | 1 -

This whole file can be deleted now, with the way Android kernels are now
being managed it makes no sense anymore.  I'll write up a patch to do
that later tonight.

thanks,

greg k-h

From paulmck at kernel.org  Wed Jun 29 16:07:52 2022
From: paulmck at kernel.org (Paul E. McKenney)
Date: Wed, 29 Jun 2022 09:07:52 -0700
Subject: [PATCH] remove CONFIG_ANDROID
In-Reply-To: <20220629150102.1582425-2-hch@lst.de>
References: <20220629150102.1582425-1-hch@lst.de>
 <20220629150102.1582425-2-hch@lst.de>
Message-ID: <20220629160752.GE1790663@paulmck-ThinkPad-P17-Gen-1>

On Wed, Jun 29, 2022 at 05:01:02PM +0200, Christoph Hellwig wrote:
> The ANDROID config symbol is only used to guard the binder config
> symbol and to inject completely random config changes.  Remove it
> as it is obviously a bad idea.
> 
> Signed-off-by: Christoph Hellwig <hch at lst.de>

And I got confirmation from the Android folks that they have other ways
of getting their 20-millisecond expedited RCU CPU stall warnings, so:

Acked-by: Paul E. McKenney <paulmck at kernel.org>

> ---
>  drivers/Makefile                                    | 2 +-
>  drivers/android/Kconfig                             | 9 ---------
>  drivers/char/random.c                               | 3 +--
>  drivers/net/wireguard/device.c                      | 2 +-
>  kernel/configs/android-base.config                  | 1 -
>  kernel/rcu/Kconfig.debug                            | 3 +--
>  tools/testing/selftests/filesystems/binderfs/config | 1 -
>  tools/testing/selftests/sync/config                 | 1 -
>  8 files changed, 4 insertions(+), 18 deletions(-)
> 
> diff --git a/drivers/Makefile b/drivers/Makefile
> index 9a30842b22c54..123dce2867583 100644
> --- a/drivers/Makefile
> +++ b/drivers/Makefile
> @@ -176,7 +176,7 @@ obj-$(CONFIG_USB4)		+= thunderbolt/
>  obj-$(CONFIG_CORESIGHT)		+= hwtracing/coresight/
>  obj-y				+= hwtracing/intel_th/
>  obj-$(CONFIG_STM)		+= hwtracing/stm/
> -obj-$(CONFIG_ANDROID)		+= android/
> +obj-y				+= android/
>  obj-$(CONFIG_NVMEM)		+= nvmem/
>  obj-$(CONFIG_FPGA)		+= fpga/
>  obj-$(CONFIG_FSI)		+= fsi/
> diff --git a/drivers/android/Kconfig b/drivers/android/Kconfig
> index 53b22e26266c3..07aa8ae0a058c 100644
> --- a/drivers/android/Kconfig
> +++ b/drivers/android/Kconfig
> @@ -1,13 +1,6 @@
>  # SPDX-License-Identifier: GPL-2.0
>  menu "Android"
>  
> -config ANDROID
> -	bool "Android Drivers"
> -	help
> -	  Enable support for various drivers needed on the Android platform
> -
> -if ANDROID
> -
>  config ANDROID_BINDER_IPC
>  	bool "Android Binder IPC Driver"
>  	depends on MMU
> @@ -54,6 +47,4 @@ config ANDROID_BINDER_IPC_SELFTEST
>  	  exhaustively with combinations of various buffer sizes and
>  	  alignments.
>  
> -endif # if ANDROID
> -
>  endmenu
> diff --git a/drivers/char/random.c b/drivers/char/random.c
> index e3dd1dd3dd226..f35ad1a9dff3e 100644
> --- a/drivers/char/random.c
> +++ b/drivers/char/random.c
> @@ -755,8 +755,7 @@ static int random_pm_notification(struct notifier_block *nb, unsigned long actio
>  	spin_unlock_irqrestore(&input_pool.lock, flags);
>  
>  	if (crng_ready() && (action == PM_RESTORE_PREPARE ||
> -	    (action == PM_POST_SUSPEND &&
> -	     !IS_ENABLED(CONFIG_PM_AUTOSLEEP) && !IS_ENABLED(CONFIG_ANDROID)))) {
> +	    (action == PM_POST_SUSPEND && !IS_ENABLED(CONFIG_PM_AUTOSLEEP)))) {
>  		crng_reseed();
>  		pr_notice("crng reseeded on system resumption\n");
>  	}
> diff --git a/drivers/net/wireguard/device.c b/drivers/net/wireguard/device.c
> index aa9a7a5970fda..de1cc03f7ee86 100644
> --- a/drivers/net/wireguard/device.c
> +++ b/drivers/net/wireguard/device.c
> @@ -69,7 +69,7 @@ static int wg_pm_notification(struct notifier_block *nb, unsigned long action, v
>  	 * its normal operation rather than as a somewhat rare event, then we
>  	 * don't actually want to clear keys.
>  	 */
> -	if (IS_ENABLED(CONFIG_PM_AUTOSLEEP) || IS_ENABLED(CONFIG_ANDROID))
> +	if (IS_ENABLED(CONFIG_PM_AUTOSLEEP))
>  		return 0;
>  
>  	if (action != PM_HIBERNATION_PREPARE && action != PM_SUSPEND_PREPARE)
> diff --git a/kernel/configs/android-base.config b/kernel/configs/android-base.config
> index eb701b2ac72ff..44b0f0146a3fc 100644
> --- a/kernel/configs/android-base.config
> +++ b/kernel/configs/android-base.config
> @@ -7,7 +7,6 @@
>  # CONFIG_OABI_COMPAT is not set
>  # CONFIG_SYSVIPC is not set
>  # CONFIG_USELIB is not set
> -CONFIG_ANDROID=y
>  CONFIG_ANDROID_BINDER_IPC=y
>  CONFIG_ANDROID_BINDER_DEVICES=binder,hwbinder,vndbinder
>  CONFIG_ANDROID_LOW_MEMORY_KILLER=y
> diff --git a/kernel/rcu/Kconfig.debug b/kernel/rcu/Kconfig.debug
> index 9b64e55d4f615..e875f4f889656 100644
> --- a/kernel/rcu/Kconfig.debug
> +++ b/kernel/rcu/Kconfig.debug
> @@ -86,8 +86,7 @@ config RCU_EXP_CPU_STALL_TIMEOUT
>  	int "Expedited RCU CPU stall timeout in milliseconds"
>  	depends on RCU_STALL_COMMON
>  	range 0 21000
> -	default 20 if ANDROID
> -	default 0 if !ANDROID
> +	default 0
>  	help
>  	  If a given expedited RCU grace period extends more than the
>  	  specified number of milliseconds, a CPU stall warning is printed.
> diff --git a/tools/testing/selftests/filesystems/binderfs/config b/tools/testing/selftests/filesystems/binderfs/config
> index 02dd6cc9cf992..7b4fc6ee62057 100644
> --- a/tools/testing/selftests/filesystems/binderfs/config
> +++ b/tools/testing/selftests/filesystems/binderfs/config
> @@ -1,3 +1,2 @@
> -CONFIG_ANDROID=y
>  CONFIG_ANDROID_BINDERFS=y
>  CONFIG_ANDROID_BINDER_IPC=y
> diff --git a/tools/testing/selftests/sync/config b/tools/testing/selftests/sync/config
> index 47ff5afc37271..64c60f38b4464 100644
> --- a/tools/testing/selftests/sync/config
> +++ b/tools/testing/selftests/sync/config
> @@ -1,3 +1,2 @@
>  CONFIG_STAGING=y
> -CONFIG_ANDROID=y
>  CONFIG_SW_SYNC=y
> -- 
> 2.30.2
> 

From Jason at zx2c4.com  Wed Jun 29 16:09:18 2022
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Wed, 29 Jun 2022 18:09:18 +0200
Subject: [PATCH] remove CONFIG_ANDROID
In-Reply-To: <20220629150102.1582425-2-hch@lst.de>
References: <20220629150102.1582425-1-hch@lst.de>
 <20220629150102.1582425-2-hch@lst.de>
Message-ID: <Yrx5Lt7jrk5BiHXx@zx2c4.com>

Hi Christoph,

On Wed, Jun 29, 2022 at 05:01:02PM +0200, Christoph Hellwig wrote:
> diff --git a/drivers/char/random.c b/drivers/char/random.c
> index e3dd1dd3dd226..f35ad1a9dff3e 100644
> --- a/drivers/char/random.c
> +++ b/drivers/char/random.c
> @@ -755,8 +755,7 @@ static int random_pm_notification(struct notifier_block *nb, unsigned long actio
>  	spin_unlock_irqrestore(&input_pool.lock, flags);
>  
>  	if (crng_ready() && (action == PM_RESTORE_PREPARE ||
> -	    (action == PM_POST_SUSPEND &&
> -	     !IS_ENABLED(CONFIG_PM_AUTOSLEEP) && !IS_ENABLED(CONFIG_ANDROID)))) {
> +	    (action == PM_POST_SUSPEND && !IS_ENABLED(CONFIG_PM_AUTOSLEEP)))) {
>  		crng_reseed();
>  		pr_notice("crng reseeded on system resumption\n");
>  	}
> diff --git a/drivers/net/wireguard/device.c b/drivers/net/wireguard/device.c
> index aa9a7a5970fda..de1cc03f7ee86 100644
> --- a/drivers/net/wireguard/device.c
> +++ b/drivers/net/wireguard/device.c
> @@ -69,7 +69,7 @@ static int wg_pm_notification(struct notifier_block *nb, unsigned long action, v
>  	 * its normal operation rather than as a somewhat rare event, then we
>  	 * don't actually want to clear keys.
>  	 */
> -	if (IS_ENABLED(CONFIG_PM_AUTOSLEEP) || IS_ENABLED(CONFIG_ANDROID))
> +	if (IS_ENABLED(CONFIG_PM_AUTOSLEEP))
>  		return 0;
>  
>  	if (action != PM_HIBERNATION_PREPARE && action != PM_SUSPEND_PREPARE)
 
CONFIG_ANDROID is used here for a reason. As somebody suggested in
another thread of which you were a participant, it acts as a proxy for
"probably running on Android hardware", which in turn is a proxy for,
"suspend happens all the time on this machine, so don't do fancy key
clearing stuff every time the user clicks the power button."

You can see the history of that in these two commits here:
https://git.zx2c4.com/wireguard-linux-compat/commit/?id=36f81c83674e0fd7c18e5b15499d1a275b6d4d7f
https://git.zx2c4.com/wireguard-linux-compat/commit/?id=a89d53098dbde43f56e4d1e16ba5e24ef807c03b

The former commit was done when I first got this running on an Android
device (a Oneplus 3T, IIRC) and I encountered this problem. The latter
was a refinement after suggestions on LKML during WireGuard's
upstreaming.

So there *is* a reason to have that kind of conditionalization in the
code. The question is: does CONFIG_ANDROID actually represent something
interesting here? Is this already taken care of by CONFIG_PM_AUTOSLEEP
on all CONFIG_ANDROID devices? That is, do the base Android configs set
CONFIG_PM_AUTOSLEEP already so this isn't necessary? Or is there some
*other* proxy config value that should be used? Or is there a different
solution entirely that should be considered?

I don't know the answers to these questions, because I haven't done a
recent analysis. Obviously at one point in time I did, and that's why
the code is how it is. It sounds like you'd now like to revisit that
original decision. That's fine with me. But you need to conduct a new
analysis and write down your findings inside of a commit message. I must
see that you've at least thought about the problem and looked into it
substantially enough that making this change is safe. Your "let's delete
it; it's not doing much" alone seems more expedient than thorough.

Jason

From Jason at zx2c4.com  Wed Jun 29 16:13:05 2022
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Wed, 29 Jun 2022 18:13:05 +0200
Subject: [PATCH] remove CONFIG_ANDROID
In-Reply-To: <20220629161020.GA24891@lst.de>
References: <20220629150102.1582425-1-hch@lst.de>
 <20220629150102.1582425-2-hch@lst.de> <Yrx5Lt7jrk5BiHXx@zx2c4.com>
 <20220629161020.GA24891@lst.de>
Message-ID: <Yrx6EVHtroXeEZGp@zx2c4.com>

On Wed, Jun 29, 2022 at 06:10:20PM +0200, Christoph Hellwig wrote:
> On Wed, Jun 29, 2022 at 06:09:18PM +0200, Jason A. Donenfeld wrote:
> > CONFIG_ANDROID is used here for a reason. As somebody suggested in
> > another thread of which you were a participant, it acts as a proxy for
> > "probably running on Android hardware",
> 
> No, it does not in any way.

Good! It sounds like you're starting to develop opinions on the matter.
Please weave these into some analysis of the issue and put this in your
v2 patch. To be clear, the thing I care about is that this won't make
the behavior worse for any kernels. If you feel like you've got that
covered, say why in your patch, and then it's fine by me.

Jason

From Jason at zx2c4.com  Wed Jun 29 16:25:32 2022
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Wed, 29 Jun 2022 18:25:32 +0200
Subject: [PATCH] remove CONFIG_ANDROID
In-Reply-To: <20220629161527.GA24978@lst.de>
References: <20220629150102.1582425-1-hch@lst.de>
 <20220629150102.1582425-2-hch@lst.de> <Yrx5Lt7jrk5BiHXx@zx2c4.com>
 <20220629161020.GA24891@lst.de> <Yrx6EVHtroXeEZGp@zx2c4.com>
 <20220629161527.GA24978@lst.de>
Message-ID: <Yrx8/Fyx15CTi2zq@zx2c4.com>

On Wed, Jun 29, 2022 at 06:15:27PM +0200, Christoph Hellwig wrote:
> On Wed, Jun 29, 2022 at 06:13:05PM +0200, Jason A. Donenfeld wrote:
> > Good! It sounds like you're starting to develop opinions on the matter.
> 
> No, I provide facts.

Lol.

> Look at both the definition of the symbol, and
> various distribution kernel that enabled it and think hard if they run
> on "Android" hardware.  Not just primarily, but at all.

There are two failure modes:

1) Key clearing code is skipped when it shouldn't be.
2) Key clearing code is run when it shouldn't be.

You've identified (well, Alex in the other thread I think?) a case of
(1). I was sort of thinking the fix to that would be that distros
shouldn't enable that option, but it doesn't really matter to me.

However, what I'm pointing out is the potential for (2). A (2)-style
regression means that WireGuard basically doesn't work, because, for
example, qcacld's packet-triggered wakeups tend to be too short to
renegotiate a handshake.

Anyway, instead of the slow drip of "facts" and ?three sentence emails,
can you just write up a paragraph that indicates this is safe to do (for
both (1) and (2)) in your v+1?

I don't really want to argue about it, because I don't have anything to
argue about. Your change is probably fine. I'd just like it to be
spelled out why this is safe to do from somebody who has looked into it.
I have not looked into it, but it sounds like you have or are in the
process of doing so. Just write down what you find, please.

Jason

From max.schulze at online.de  Wed Jun 29 16:29:10 2022
From: max.schulze at online.de (Max Schulze)
Date: Wed, 29 Jun 2022 16:29:10 +0000
Subject: Wireguard-android: consider displaying last handshake ?
Message-ID: <75C09BF0-72BB-46C6-90CC-61683021617A@online.de>

I find it very hard to debug wireguard connections on mobile.

I think it might be great if the last handshake would be displayed, just like on the desktop implementations (win, Linux).

This would really make life easier. It does not need to be the second -counting counter, a timestamp would be great. This way, all platforms would be equivalent, I.e. you could always ask "is there a handshake time displayed"?

It looks like there is a pull request at?https://github.com/WireGuard/wireguard-android/pull/30/commits?but I cannot judge the quality.

M

From paulmck at kernel.org  Wed Jun 29 16:34:44 2022
From: paulmck at kernel.org (Paul E. McKenney)
Date: Wed, 29 Jun 2022 09:34:44 -0700
Subject: [PATCH] remove CONFIG_ANDROID
In-Reply-To: <20220629161527.GA24978@lst.de>
References: <20220629150102.1582425-1-hch@lst.de>
 <20220629150102.1582425-2-hch@lst.de> <Yrx5Lt7jrk5BiHXx@zx2c4.com>
 <20220629161020.GA24891@lst.de> <Yrx6EVHtroXeEZGp@zx2c4.com>
 <20220629161527.GA24978@lst.de>
Message-ID: <20220629163444.GG1790663@paulmck-ThinkPad-P17-Gen-1>

On Wed, Jun 29, 2022 at 06:15:27PM +0200, Christoph Hellwig wrote:
> On Wed, Jun 29, 2022 at 06:13:05PM +0200, Jason A. Donenfeld wrote:
> > Good! It sounds like you're starting to develop opinions on the matter.
> 
> No, I provide facts.  Look at both the definition of the symbol, and
> various distribution kernel that enabled it and think hard if they run
> on "Android" hardware.  Not just primarily, but at all.

So you are OK if your patch is accepted, and then CONFIG_ANDROID is
re-introduced but used only for building kernels intended to run on
Android systems?

Asking for a friend.  ;-)

							Thanx, Paul

From Jason at zx2c4.com  Wed Jun 29 16:38:09 2022
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Wed, 29 Jun 2022 18:38:09 +0200
Subject: [PATCH] remove CONFIG_ANDROID
In-Reply-To: <20220629163007.GA25279@lst.de>
References: <20220629150102.1582425-1-hch@lst.de>
 <20220629150102.1582425-2-hch@lst.de> <Yrx5Lt7jrk5BiHXx@zx2c4.com>
 <20220629161020.GA24891@lst.de> <Yrx6EVHtroXeEZGp@zx2c4.com>
 <20220629161527.GA24978@lst.de> <Yrx8/Fyx15CTi2zq@zx2c4.com>
 <20220629163007.GA25279@lst.de>
Message-ID: <Yrx/8UOY+J8Ao3Bd@zx2c4.com>

On Wed, Jun 29, 2022 at 06:30:07PM +0200, Christoph Hellwig wrote:
> On Wed, Jun 29, 2022 at 06:25:32PM +0200, Jason A. Donenfeld wrote:
> > Anyway, instead of the slow drip of "facts" and ?three sentence emails,
> > can you just write up a paragraph that indicates this is safe to do (for
> > both (1) and (2)) in your v+1?
> 
> Why would I care?  If your config wakeups up so often that you need
> special casing find a way to deal with it. 

You should care, because the change you're suggesting might break code
that I maintain. If you don't care about breaking my code with your
change, than just have my "nack", and it'll be up to Greg to decide
whether he wants to apply this despite the nack for two separate
affected code spots.

On the technical topic, an Android developer friend following this
thread just pointed out to me that Android doesn't use PM_AUTOSLEEP and
just has userspace causing suspend frequently. So by his rough
estimation your patch actually *will* break Android devices. Zoinks.
Maybe he's right, maybe he's not -- I don't know -- but you should
probably look into this if you want this patch to land without breakage.

Jason

From Jason at zx2c4.com  Wed Jun 29 16:45:48 2022
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Wed, 29 Jun 2022 18:45:48 +0200
Subject: [PATCH] remove CONFIG_ANDROID
In-Reply-To: <20220629163701.GA25519@lst.de>
References: <20220629150102.1582425-1-hch@lst.de>
 <20220629150102.1582425-2-hch@lst.de> <Yrx5Lt7jrk5BiHXx@zx2c4.com>
 <20220629161020.GA24891@lst.de> <Yrx6EVHtroXeEZGp@zx2c4.com>
 <20220629161527.GA24978@lst.de>
 <20220629163444.GG1790663@paulmck-ThinkPad-P17-Gen-1>
 <20220629163701.GA25519@lst.de>
Message-ID: <YryBvAvhnyZ4mZKD@zx2c4.com>

On Wed, Jun 29, 2022 at 06:37:01PM +0200, Christoph Hellwig wrote:
> be a policy set somewhere either in the kernel or fed into the kernel
> by userspace.  Then we can key it off that, and I suspect it is
> probably going to be a runtime variable and not a config option.

Right, this would be a good way of addressing it.

Maybe some Android people on the list have a good idea off hand of what
Android uses at runtime to control this, and how it'd be accessible in
the kernel?

Jason

From Jason at zx2c4.com  Wed Jun 29 16:52:08 2022
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Wed, 29 Jun 2022 18:52:08 +0200
Subject: [PATCH] remove CONFIG_ANDROID
In-Reply-To: <20220629164543.GA25672@lst.de>
References: <20220629150102.1582425-1-hch@lst.de>
 <20220629150102.1582425-2-hch@lst.de>
 <Yrx5Lt7jrk5BiHXx@zx2c4.com> <20220629161020.GA24891@lst.de>
 <Yrx6EVHtroXeEZGp@zx2c4.com> <20220629161527.GA24978@lst.de>
 <Yrx8/Fyx15CTi2zq@zx2c4.com> <20220629163007.GA25279@lst.de>
 <Yrx/8UOY+J8Ao3Bd@zx2c4.com> <20220629164543.GA25672@lst.de>
Message-ID: <CAHmME9rwKmEQcn84GfTrCPzaK3g6vh6rpQ=YcgyTo_PWpJ5VcA@mail.gmail.com>

On Wed, Jun 29, 2022 at 6:45 PM Christoph Hellwig <hch at lst.de> wrote:
>
> On Wed, Jun 29, 2022 at 06:38:09PM +0200, Jason A. Donenfeld wrote:
> > On the technical topic, an Android developer friend following this
> > thread just pointed out to me that Android doesn't use PM_AUTOSLEEP and
> > just has userspace causing suspend frequently. So by his rough
> > estimation your patch actually *will* break Android devices. Zoinks.
> > Maybe he's right, maybe he's not -- I don't know -- but you should
> > probably look into this if you want this patch to land without breakage.
>
> And it will also "break" anyone else doing frequent suspends from
> userspace, as that behavior is still in no way related to
> CONFIG_ANDROID.

I don't know of any actual systems that do this for which
CONFIG_PM_AUTOSLEEP and CONFIG_ANDROID are both disabled. At least
that was what I concluded back in 2017-2018 when I looked at this
last. And so far, no other-handset-users have reported bugs.

But of course I agree that this all could be improved with something
more granular somehow, somewhere. I don't really have any developed
opinions on what that looks like or what form that should take.

However, the thing I do have a strong opinion on is that the change
you're proposing shouldn't break things. And that's what your patch
currently might do (or not!).

In other words, instead of making the current situation worse,
justified by your observation that in theory the current mechanism is
imperfect, please make the situation better. Or conclude that it
doesn't make the situation worse, and put the reason why inside your
commit message, which is the first thing I asked.

Jason

From gregkh at linuxfoundation.org  Wed Jun 29 17:00:25 2022
From: gregkh at linuxfoundation.org (Greg Kroah-Hartman)
Date: Wed, 29 Jun 2022 19:00:25 +0200
Subject: [PATCH] remove CONFIG_ANDROID
In-Reply-To: <CAHmME9rwKmEQcn84GfTrCPzaK3g6vh6rpQ=YcgyTo_PWpJ5VcA@mail.gmail.com>
References: <20220629150102.1582425-2-hch@lst.de> <Yrx5Lt7jrk5BiHXx@zx2c4.com>
 <20220629161020.GA24891@lst.de> <Yrx6EVHtroXeEZGp@zx2c4.com>
 <20220629161527.GA24978@lst.de> <Yrx8/Fyx15CTi2zq@zx2c4.com>
 <20220629163007.GA25279@lst.de> <Yrx/8UOY+J8Ao3Bd@zx2c4.com>
 <20220629164543.GA25672@lst.de>
 <CAHmME9rwKmEQcn84GfTrCPzaK3g6vh6rpQ=YcgyTo_PWpJ5VcA@mail.gmail.com>
Message-ID: <YryFKXsx/Bgv/oBE@kroah.com>

On Wed, Jun 29, 2022 at 06:52:08PM +0200, Jason A. Donenfeld wrote:
> On Wed, Jun 29, 2022 at 6:45 PM Christoph Hellwig <hch at lst.de> wrote:
> >
> > On Wed, Jun 29, 2022 at 06:38:09PM +0200, Jason A. Donenfeld wrote:
> > > On the technical topic, an Android developer friend following this
> > > thread just pointed out to me that Android doesn't use PM_AUTOSLEEP and
> > > just has userspace causing suspend frequently. So by his rough
> > > estimation your patch actually *will* break Android devices. Zoinks.
> > > Maybe he's right, maybe he's not -- I don't know -- but you should
> > > probably look into this if you want this patch to land without breakage.
> >
> > And it will also "break" anyone else doing frequent suspends from
> > userspace, as that behavior is still in no way related to
> > CONFIG_ANDROID.
> 
> I don't know of any actual systems that do this for which
> CONFIG_PM_AUTOSLEEP and CONFIG_ANDROID are both disabled. At least
> that was what I concluded back in 2017-2018 when I looked at this
> last. And so far, no other-handset-users have reported bugs.
> 
> But of course I agree that this all could be improved with something
> more granular somehow, somewhere. I don't really have any developed
> opinions on what that looks like or what form that should take.
> 
> However, the thing I do have a strong opinion on is that the change
> you're proposing shouldn't break things. And that's what your patch
> currently might do (or not!).

I think that by the time the next kernel release comes out, and
percolates to a real Android device, the years gone by will have caused
those who care about this to fix it.

In the meantime, this might actually fix issues in desktop distros that
were enabling this option, thinking it only affected the building of a
driver, not core power management functionality.

So it's nothing to worry about now, I agree with Christoph, this config
option should not be used for power management policy decisions like
this.  This should be controlled by userspace properly in the Android
userspace framework, like all other Linux distros/systems do this.

And worst case, Android kernels sometimes _do_ have a not-upstream
config option that you can use to trigger off of horrible hacks like
this.  I'll leave the answer to what that is as an exercise for the
reader :)

thanks,

greg k-h

From paulmck at kernel.org  Wed Jun 29 17:04:02 2022
From: paulmck at kernel.org (Paul E. McKenney)
Date: Wed, 29 Jun 2022 10:04:02 -0700
Subject: [PATCH] remove CONFIG_ANDROID
In-Reply-To: <YryBvAvhnyZ4mZKD@zx2c4.com>
References: <20220629150102.1582425-1-hch@lst.de>
 <20220629150102.1582425-2-hch@lst.de> <Yrx5Lt7jrk5BiHXx@zx2c4.com>
 <20220629161020.GA24891@lst.de> <Yrx6EVHtroXeEZGp@zx2c4.com>
 <20220629161527.GA24978@lst.de>
 <20220629163444.GG1790663@paulmck-ThinkPad-P17-Gen-1>
 <20220629163701.GA25519@lst.de> <YryBvAvhnyZ4mZKD@zx2c4.com>
Message-ID: <20220629170402.GJ1790663@paulmck-ThinkPad-P17-Gen-1>

On Wed, Jun 29, 2022 at 06:45:48PM +0200, Jason A. Donenfeld wrote:
> On Wed, Jun 29, 2022 at 06:37:01PM +0200, Christoph Hellwig wrote:
> > be a policy set somewhere either in the kernel or fed into the kernel
> > by userspace.  Then we can key it off that, and I suspect it is
> > probably going to be a runtime variable and not a config option.
> 
> Right, this would be a good way of addressing it.
> 
> Maybe some Android people on the list have a good idea off hand of what
> Android uses at runtime to control this, and how it'd be accessible in
> the kernel?

In case it helps, in the case of CONFIG_RCU_EXP_CPU_STALL_TIMEOUT,
the Android guys can use things like defconfig at kernel-build time or
the rcu_exp_cpu_stall_timeout kernel-boot/sysfs parameter at boot time
or runtime.

							Thanx, Paul

From Jason at zx2c4.com  Wed Jun 29 17:10:43 2022
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Wed, 29 Jun 2022 19:10:43 +0200
Subject: [PATCH] remove CONFIG_ANDROID
In-Reply-To: <YryFKXsx/Bgv/oBE@kroah.com>
References: <Yrx5Lt7jrk5BiHXx@zx2c4.com> <20220629161020.GA24891@lst.de>
 <Yrx6EVHtroXeEZGp@zx2c4.com> <20220629161527.GA24978@lst.de>
 <Yrx8/Fyx15CTi2zq@zx2c4.com> <20220629163007.GA25279@lst.de>
 <Yrx/8UOY+J8Ao3Bd@zx2c4.com> <20220629164543.GA25672@lst.de>
 <CAHmME9rwKmEQcn84GfTrCPzaK3g6vh6rpQ=YcgyTo_PWpJ5VcA@mail.gmail.com>
 <YryFKXsx/Bgv/oBE@kroah.com>
Message-ID: <YryHk06Ye/12dMEN@zx2c4.com>

On Wed, Jun 29, 2022 at 07:00:25PM +0200, Greg Kroah-Hartman wrote:
> I think that by the time the next kernel release comes out, and
> percolates to a real Android device, the years gone by will have caused
> those who care about this to fix it.

You assume that there aren't Android devices using kernels outside of
the ones you're referring to. That's a rather Google-centric
perspective. It's still breakage, even if Google has the ability to fix
it locally after "years gone by". If you want Android things to be
upstream, this is the way you must think about it; otherwise, what's the
point? By your logic, upstream should probably remove the Android code
everywhere and let Google handle it downstream. Except nobody wants
that; we want Android upstream. So let's keep it working upstream, not
intentionally break it.

> In the meantime, this might actually fix issues in desktop distros that
> were enabling this option, thinking it only affected the building of a
> driver

That sounds like a false dichotomy. It's not about "fix Android" vs "fix
distros". What I'm suggesting is fixing Android AND fixing distros, by
looking at the problem holistically. Trading a bad problem on Android
(wg connections are broken) for a manageable problem on distros (something
something theoretical warm boot attack something) doesn't sound like a
nice trade off. Let's instead get this all fixed at the same time.

> So it's nothing to worry about now, I agree with Christoph, this config
> option should not be used for power management policy decisions like
> this.  This should be controlled by userspace properly in the Android
> userspace framework, like all other Linux distros/systems do this.

Except right now it is. So if it's going to be removed, the code that
was depending on it will need to be updated coherently.

Jason

From Jason at zx2c4.com  Wed Jun 29 17:19:30 2022
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Wed, 29 Jun 2022 19:19:30 +0200
Subject: [PATCH] remove CONFIG_ANDROID
In-Reply-To: <20220629125643.393df70d@gandalf.local.home>
References: <20220629150102.1582425-2-hch@lst.de> <Yrx5Lt7jrk5BiHXx@zx2c4.com>
 <20220629161020.GA24891@lst.de> <Yrx6EVHtroXeEZGp@zx2c4.com>
 <20220629161527.GA24978@lst.de> <Yrx8/Fyx15CTi2zq@zx2c4.com>
 <20220629163007.GA25279@lst.de> <Yrx/8UOY+J8Ao3Bd@zx2c4.com>
 <20220629164543.GA25672@lst.de>
 <20220629125643.393df70d@gandalf.local.home>
Message-ID: <YryJotKWelr5KFPO@zx2c4.com>

On Wed, Jun 29, 2022 at 12:56:43PM -0400, Steven Rostedt wrote:
> > And it will also "break" anyone else doing frequent suspends from
> > userspace, as that behavior is still in no way related to
> > CONFIG_ANDROID.
> 
> Should there then be a CONFIG_FREQUENT_SUSPENDS ?

That'd be fine by me. It could be selected by PM_AUTOSLEEP as well.

[ Bikeshed: maybe CONFIG_PM_CONTINUOUS_SUSPENDS would make more sense,
  to really drive home how often these suspends are to make the option a
  reasonable thing to turn on. ]

I think Christoph had in mind a runtime switch instead (like a sysctl or
something), but it doesn't make a difference to me whether it's runtime
or compile time. If CONFIG_ANDROID is to go away, the code using it now
needs *some* replacement that's taken up by the Android people. So
whatever they agree to works for me, for what my concerns are.

Maybe v2 of this patchset can propose such an option and the right
Android people can be CC'd on it. (Who are they, by the way? There's no
android-kernel at vger mailing list, right?)

Jason

From gregkh at linuxfoundation.org  Wed Jun 29 17:19:36 2022
From: gregkh at linuxfoundation.org (Greg Kroah-Hartman)
Date: Wed, 29 Jun 2022 19:19:36 +0200
Subject: [PATCH] remove CONFIG_ANDROID
In-Reply-To: <YryHk06Ye/12dMEN@zx2c4.com>
References: <20220629161020.GA24891@lst.de> <Yrx6EVHtroXeEZGp@zx2c4.com>
 <20220629161527.GA24978@lst.de> <Yrx8/Fyx15CTi2zq@zx2c4.com>
 <20220629163007.GA25279@lst.de> <Yrx/8UOY+J8Ao3Bd@zx2c4.com>
 <20220629164543.GA25672@lst.de>
 <CAHmME9rwKmEQcn84GfTrCPzaK3g6vh6rpQ=YcgyTo_PWpJ5VcA@mail.gmail.com>
 <YryFKXsx/Bgv/oBE@kroah.com> <YryHk06Ye/12dMEN@zx2c4.com>
Message-ID: <YryJqI/ppVfMhRhI@kroah.com>

On Wed, Jun 29, 2022 at 07:10:43PM +0200, Jason A. Donenfeld wrote:
> On Wed, Jun 29, 2022 at 07:00:25PM +0200, Greg Kroah-Hartman wrote:
> > I think that by the time the next kernel release comes out, and
> > percolates to a real Android device, the years gone by will have caused
> > those who care about this to fix it.
> 
> You assume that there aren't Android devices using kernels outside of
> the ones you're referring to. That's a rather Google-centric
> perspective. It's still breakage, even if Google has the ability to fix
> it locally after "years gone by". If you want Android things to be
> upstream, this is the way you must think about it; otherwise, what's the
> point? By your logic, upstream should probably remove the Android code
> everywhere and let Google handle it downstream. Except nobody wants
> that; we want Android upstream. So let's keep it working upstream, not
> intentionally break it.

I would be totally and completly amazed if there are any Android kernels
in real devices in the world that are not at the very least, based on
LTS releases.  But maybe there is, this patch series isn't going to land
until 5.20, and by then, I think the "define behavior, not hardware" fix
for random and wg will be properly resolved :)

> > In the meantime, this might actually fix issues in desktop distros that
> > were enabling this option, thinking it only affected the building of a
> > driver
> 
> That sounds like a false dichotomy. It's not about "fix Android" vs "fix
> distros". What I'm suggesting is fixing Android AND fixing distros, by
> looking at the problem holistically. Trading a bad problem on Android
> (wg connections are broken) for a manageable problem on distros (something
> something theoretical warm boot attack something) doesn't sound like a
> nice trade off. Let's instead get this all fixed at the same time.

Agreed, so what should we use instead in the wg code?  What userspace
functionality are you trying to trigger off of here in the current
CONFIG_ANDROID check?

The RCU stuff is already handled as Paul has stated, so that's not an
issue.

thanks,

greg k-h

From Jason at zx2c4.com  Wed Jun 29 17:30:35 2022
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Wed, 29 Jun 2022 19:30:35 +0200
Subject: [PATCH] remove CONFIG_ANDROID
In-Reply-To: <YryJqI/ppVfMhRhI@kroah.com>
References: <Yrx6EVHtroXeEZGp@zx2c4.com> <20220629161527.GA24978@lst.de>
 <Yrx8/Fyx15CTi2zq@zx2c4.com> <20220629163007.GA25279@lst.de>
 <Yrx/8UOY+J8Ao3Bd@zx2c4.com> <20220629164543.GA25672@lst.de>
 <CAHmME9rwKmEQcn84GfTrCPzaK3g6vh6rpQ=YcgyTo_PWpJ5VcA@mail.gmail.com>
 <YryFKXsx/Bgv/oBE@kroah.com> <YryHk06Ye/12dMEN@zx2c4.com>
 <YryJqI/ppVfMhRhI@kroah.com>
Message-ID: <YryMO6PX+G9owRGz@zx2c4.com>

On Wed, Jun 29, 2022 at 07:19:36PM +0200, Greg Kroah-Hartman wrote:
> I would be totally and completly amazed if there are any Android kernels
> in real devices in the world that are not at the very least, based on
> LTS releases.  But maybe there is, this patch series isn't going to land
> until 5.20, and by then, I think the "define behavior, not hardware" fix
> for random and wg will be properly resolved :)

Properly resolved by whom? It sounds like you're up for intentionally
allowing a userspace regression, and also volunteering other people's
time into fixing that regression? The way I understand the kernel
development process is that the person proposing a change is responsible
for not intentionally causing regressions, and if one is pointed out, a
v+1 of that patch is provided that doesn't cause the regression.

> 
> > > In the meantime, this might actually fix issues in desktop distros that
> > > were enabling this option, thinking it only affected the building of a
> > > driver
> > 
> > That sounds like a false dichotomy. It's not about "fix Android" vs "fix
> > distros". What I'm suggesting is fixing Android AND fixing distros, by
> > looking at the problem holistically. Trading a bad problem on Android
> > (wg connections are broken) for a manageable problem on distros (something
> > something theoretical warm boot attack something) doesn't sound like a
> > nice trade off. Let's instead get this all fixed at the same time.
> 
> Agreed, so what should we use instead in the wg code?  What userspace
> functionality are you trying to trigger off of here in the current
> CONFIG_ANDROID check?

It's systems that go to sleep all the time, nonstop, like Android
handsets do. I'm fine with a compile time constant for this, or some
runtime sysctl, or whatever else. It doesn't really matter to me. The
only concern is that the Android people are okay with it and enable it
(and that the distros don't enable it, I guess). So whatever they want
is fine.  Or maybe such a runtime indicator already exists. I'm not
sure. But I think a v+1 of this patchset needs to work that out in one
direction or another.

To put it simply,

    - I highly suspect that this patch will cause a regression.
    - I don't have a ready-made solution offhand to fix said regression.
    - The submitter of the patch, now aware of regression potential,
      should look into not causing that regression.

That seems pretty clear cut: you're welcome to improve it, but please
don't *intentionally* break my code.

Jason

From Jason at zx2c4.com  Wed Jun 29 17:34:58 2022
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Wed, 29 Jun 2022 19:34:58 +0200
Subject: [PATCH] remove CONFIG_ANDROID
In-Reply-To: <Yrx/8UOY+J8Ao3Bd@zx2c4.com>
References: <20220629150102.1582425-1-hch@lst.de>
 <20220629150102.1582425-2-hch@lst.de> <Yrx5Lt7jrk5BiHXx@zx2c4.com>
 <20220629161020.GA24891@lst.de> <Yrx6EVHtroXeEZGp@zx2c4.com>
 <20220629161527.GA24978@lst.de> <Yrx8/Fyx15CTi2zq@zx2c4.com>
 <20220629163007.GA25279@lst.de> <Yrx/8UOY+J8Ao3Bd@zx2c4.com>
Message-ID: <YryNQvWGVwCjJYmB@zx2c4.com>

On Wed, Jun 29, 2022 at 06:38:09PM +0200, Jason A. Donenfeld wrote:
> On the technical topic, an Android developer friend following this
> thread just pointed out to me that Android doesn't use PM_AUTOSLEEP and
> just has userspace causing suspend frequently. So by his rough
> estimation your patch actually *will* break Android devices. Zoinks.
> Maybe he's right, maybe he's not -- I don't know -- but you should
> probably look into this if you want this patch to land without breakage.

More details: https://cs.android.com/android/platform/superproject/+/master:system/core/libsuspend/autosuspend_wakeup_count.cpp;bpv=1;bpt=1;l=52?q=%22%2Fsys%2Fpower%2Fstate%22&start=51&gsn=sys_power_state&gs=kythe%3A%2F%2Fandroid.googlesource.com%2Fplatform%2Fsuperproject%3Flang%3Dc%252B%252B%3Fpath%3Dsystem%2Fcore%2Flibsuspend%2Fautosuspend_wakeup_count.cpp%23ftWlDJuOhS_2fn3Ri7rClxA30blj_idGgT12aoUHd1o

So indeed it looks like it's userspace controlled. If you want this to
be a runtime, rather than a compiletime, switch, maybe
autosuspend_init() of that file could write to a sysctl.

Who at Google "owns" that code? Can somebody CC them in?

Jason

From Jason at zx2c4.com  Wed Jun 29 17:42:28 2022
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Wed, 29 Jun 2022 19:42:28 +0200
Subject: [PATCH] remove CONFIG_ANDROID
In-Reply-To: <20220629173545.GA26648@lst.de>
References: <Yrx8/Fyx15CTi2zq@zx2c4.com> <20220629163007.GA25279@lst.de>
 <Yrx/8UOY+J8Ao3Bd@zx2c4.com> <20220629164543.GA25672@lst.de>
 <CAHmME9rwKmEQcn84GfTrCPzaK3g6vh6rpQ=YcgyTo_PWpJ5VcA@mail.gmail.com>
 <YryFKXsx/Bgv/oBE@kroah.com> <YryHk06Ye/12dMEN@zx2c4.com>
 <YryJqI/ppVfMhRhI@kroah.com> <YryMO6PX+G9owRGz@zx2c4.com>
 <20220629173545.GA26648@lst.de>
Message-ID: <YryPBDQEV/Z2g0GT@zx2c4.com>

On Wed, Jun 29, 2022 at 07:35:45PM +0200, Christoph Hellwig wrote:
> On Wed, Jun 29, 2022 at 07:30:35PM +0200, Jason A. Donenfeld wrote:
> > Properly resolved by whom? It sounds like you're up for intentionally
> > allowing a userspace regression, and also volunteering other people's
> > time into fixing that regression? The way I understand the kernel
> > development process is that the person proposing a change is responsible
> > for not intentionally causing regressions, and if one is pointed out, a
> > v+1 of that patch is provided that doesn't cause the regression.
> 
> If you think the code does not work when the system frequently suspends
> and resumes, then well it is broken already, as that can happen just
> as much on non-Android systems.

I don't know how you arrived at that sentence or conclusion. The
regression I'm referring to in that paragraph is the one that *your*
patch would introduce were it to be applied.

The code currently does work well on Android devices. These very
messages are transiting through it, even.

Jason

From paulmck at kernel.org  Wed Jun 29 18:59:03 2022
From: paulmck at kernel.org (Paul E. McKenney)
Date: Wed, 29 Jun 2022 11:59:03 -0700
Subject: [PATCH] remove CONFIG_ANDROID
In-Reply-To: <YryJqI/ppVfMhRhI@kroah.com>
References: <Yrx6EVHtroXeEZGp@zx2c4.com> <20220629161527.GA24978@lst.de>
 <Yrx8/Fyx15CTi2zq@zx2c4.com> <20220629163007.GA25279@lst.de>
 <Yrx/8UOY+J8Ao3Bd@zx2c4.com> <20220629164543.GA25672@lst.de>
 <CAHmME9rwKmEQcn84GfTrCPzaK3g6vh6rpQ=YcgyTo_PWpJ5VcA@mail.gmail.com>
 <YryFKXsx/Bgv/oBE@kroah.com> <YryHk06Ye/12dMEN@zx2c4.com>
 <YryJqI/ppVfMhRhI@kroah.com>
Message-ID: <20220629185903.GL1790663@paulmck-ThinkPad-P17-Gen-1>

On Wed, Jun 29, 2022 at 07:19:36PM +0200, Greg Kroah-Hartman wrote:
> On Wed, Jun 29, 2022 at 07:10:43PM +0200, Jason A. Donenfeld wrote:
> > On Wed, Jun 29, 2022 at 07:00:25PM +0200, Greg Kroah-Hartman wrote:

[ . . . ]

> > That sounds like a false dichotomy. It's not about "fix Android" vs "fix
> > distros". What I'm suggesting is fixing Android AND fixing distros, by
> > looking at the problem holistically. Trading a bad problem on Android
> > (wg connections are broken) for a manageable problem on distros (something
> > something theoretical warm boot attack something) doesn't sound like a
> > nice trade off. Let's instead get this all fixed at the same time.
> 
> Agreed, so what should we use instead in the wg code?  What userspace
> functionality are you trying to trigger off of here in the current
> CONFIG_ANDROID check?
> 
> The RCU stuff is already handled as Paul has stated, so that's not an
> issue.

To be fair, one advantage that the RCU stuff has is that it only very
recently hit mainline, so people are only just now starting to make use
of it.  Jason's code has been in for some time, so he has more existing
practice to deal with.

							Thanx, Paul

From kaleshsingh at google.com  Wed Jun 29 19:05:23 2022
From: kaleshsingh at google.com (Kalesh Singh)
Date: Wed, 29 Jun 2022 12:05:23 -0700
Subject: [PATCH] remove CONFIG_ANDROID
In-Reply-To: <YryNQvWGVwCjJYmB@zx2c4.com>
References: <20220629150102.1582425-1-hch@lst.de>
 <20220629150102.1582425-2-hch@lst.de> <Yrx5Lt7jrk5BiHXx@zx2c4.com>
 <20220629161020.GA24891@lst.de> <Yrx6EVHtroXeEZGp@zx2c4.com>
 <20220629161527.GA24978@lst.de> <Yrx8/Fyx15CTi2zq@zx2c4.com>
 <20220629163007.GA25279@lst.de> <Yrx/8UOY+J8Ao3Bd@zx2c4.com>
 <YryNQvWGVwCjJYmB@zx2c4.com>
Message-ID: <Yryic4YG9X2/DJiX@google.com>

On Wed, Jun 29, 2022 at 07:34:58PM +0200, Jason A. Donenfeld wrote:
> On Wed, Jun 29, 2022 at 06:38:09PM +0200, Jason A. Donenfeld wrote:
> > On the technical topic, an Android developer friend following this
> > thread just pointed out to me that Android doesn't use PM_AUTOSLEEP and
> > just has userspace causing suspend frequently. So by his rough
> > estimation your patch actually *will* break Android devices. Zoinks.
> > Maybe he's right, maybe he's not -- I don't know -- but you should
> > probably look into this if you want this patch to land without breakage.
> 
> More details: https://cs.android.com/android/platform/superproject/+/master:system/core/libsuspend/autosuspend_wakeup_count.cpp;bpv=1;bpt=1;l=52?q=%22%2Fsys%2Fpower%2Fstate%22&start=51&gsn=sys_power_state&gs=kythe%3A%2F%2Fandroid.googlesource.com%2Fplatform%2Fsuperproject%3Flang%3Dc%252B%252B%3Fpath%3Dsystem%2Fcore%2Flibsuspend%2Fautosuspend_wakeup_count.cpp%23ftWlDJuOhS_2fn3Ri7rClxA30blj_idGgT12aoUHd1o
> 
> So indeed it looks like it's userspace controlled. If you want this to
> be a runtime, rather than a compiletime, switch, maybe
> autosuspend_init() of that file could write to a sysctl.
> 
> Who at Google "owns" that code? Can somebody CC them in?

Hi Jason,

Thanks for raising this.

Android no longer uses PM_AUTOSLEEP, is correct. libsuspend is
also now deprecated. Android autosuspend is initiatiated from the
userspace system suspend service [1].

A runtime config sounds more reasonable since in the !PM_AUTOSLEEP
case, it is userspace which decides the suspend policy.

[1] https://cs.android.com/android/platform/superproject/+/bf3906ecb33c98ff8edd96c852b884dbccb73295:system/hardware/interfaces/suspend/1.0/default/SystemSuspend.cpp;l=265

--Kalesh

> 
> Jason
> 

From Jason at zx2c4.com  Wed Jun 29 20:47:26 2022
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Wed, 29 Jun 2022 22:47:26 +0200
Subject: [PATCH] remove CONFIG_ANDROID
In-Reply-To: <Yryic4YG9X2/DJiX@google.com>
References: <20220629150102.1582425-2-hch@lst.de> <Yrx5Lt7jrk5BiHXx@zx2c4.com>
 <20220629161020.GA24891@lst.de> <Yrx6EVHtroXeEZGp@zx2c4.com>
 <20220629161527.GA24978@lst.de> <Yrx8/Fyx15CTi2zq@zx2c4.com>
 <20220629163007.GA25279@lst.de> <Yrx/8UOY+J8Ao3Bd@zx2c4.com>
 <YryNQvWGVwCjJYmB@zx2c4.com> <Yryic4YG9X2/DJiX@google.com>
Message-ID: <Yry6XvOGge2xKx/n@zx2c4.com>

Hi Kalesh,

On Wed, Jun 29, 2022 at 12:05:23PM -0700, Kalesh Singh wrote:
> Thanks for raising this.
> 
> Android no longer uses PM_AUTOSLEEP, is correct. libsuspend is
> also now deprecated. Android autosuspend is initiatiated from the
> userspace system suspend service [1].
> 
> A runtime config sounds more reasonable since in the !PM_AUTOSLEEP
> case, it is userspace which decides the suspend policy.
> 
> [1] https://cs.android.com/android/platform/superproject/+/bf3906ecb33c98ff8edd96c852b884dbccb73295:system/hardware/interfaces/suspend/1.0/default/SystemSuspend.cpp;l=265

Bingo, thanks for the pointer. So looking at this, I'm trying to tease
out some heuristic that wouldn't require any changes, but I don't really
see anything _too_ perfect. One fragment of an idea would be that the
kernel treats things in autosuspending mode if anybody is holding open a
fd to /sys/power/state. But I worry this would interact with
non-autosuspending userspaces that also hold open the file. So barring
that, I'm not quite sure.

If you also can't think of something, maybe we should talk about adding
something that requires code changes. In that line of thinking, how
would you feel about opening /sys/power/userspace_autosuspender and
keeping that fd open. Then the kernel API would have
`bool pm_has_userspace_autosuspender(void)` that code could check.
Alternatively, if you don't want refcounting fd semantics for that, just
writing a "1" into a similar file seems fine?

Any strong opinions about it? Personally it doesn't make much of a
difference to me. The important thing is just that it'd be something
you're willing to implement in that SystemSuspend.cpp file.

Jason

From kaleshsingh at google.com  Wed Jun 29 22:26:33 2022
From: kaleshsingh at google.com (Kalesh Singh)
Date: Wed, 29 Jun 2022 15:26:33 -0700
Subject: [PATCH] remove CONFIG_ANDROID
In-Reply-To: <Yry6XvOGge2xKx/n@zx2c4.com>
References: <20220629150102.1582425-2-hch@lst.de> <Yrx5Lt7jrk5BiHXx@zx2c4.com>
 <20220629161020.GA24891@lst.de> <Yrx6EVHtroXeEZGp@zx2c4.com>
 <20220629161527.GA24978@lst.de> <Yrx8/Fyx15CTi2zq@zx2c4.com>
 <20220629163007.GA25279@lst.de> <Yrx/8UOY+J8Ao3Bd@zx2c4.com>
 <YryNQvWGVwCjJYmB@zx2c4.com> <Yryic4YG9X2/DJiX@google.com>
 <Yry6XvOGge2xKx/n@zx2c4.com>
Message-ID: <CAC_TJve_Jk0+XD7VeSJVvJq4D9ZofnH69B4QZv2LPT4X3KNfeg@mail.gmail.com>

On Wed, Jun 29, 2022 at 1:47 PM Jason A. Donenfeld <Jason at zx2c4.com> wrote:
>
> Hi Kalesh,
>
> On Wed, Jun 29, 2022 at 12:05:23PM -0700, Kalesh Singh wrote:
> > Thanks for raising this.
> >
> > Android no longer uses PM_AUTOSLEEP, is correct. libsuspend is
> > also now deprecated. Android autosuspend is initiatiated from the
> > userspace system suspend service [1].
> >
> > A runtime config sounds more reasonable since in the !PM_AUTOSLEEP
> > case, it is userspace which decides the suspend policy.
> >
> > [1] https://cs.android.com/android/platform/superproject/+/bf3906ecb33c98ff8edd96c852b884dbccb73295:system/hardware/interfaces/suspend/1.0/default/SystemSuspend.cpp;l=265
>
> Bingo, thanks for the pointer. So looking at this, I'm trying to tease
> out some heuristic that wouldn't require any changes, but I don't really
> see anything _too_ perfect. One fragment of an idea would be that the
> kernel treats things in autosuspending mode if anybody is holding open a
> fd to /sys/power/state. But I worry this would interact with
> non-autosuspending userspaces that also hold open the file. So barring
> that, I'm not quite sure.
>
> If you also can't think of something, maybe we should talk about adding
> something that requires code changes. In that line of thinking, how
> would you feel about opening /sys/power/userspace_autosuspender and
> keeping that fd open. Then the kernel API would have
> `bool pm_has_userspace_autosuspender(void)` that code could check.
> Alternatively, if you don't want refcounting fd semantics for that, just
> writing a "1" into a similar file seems fine?
>
> Any strong opinions about it? Personally it doesn't make much of a
> difference to me. The important thing is just that it'd be something
> you're willing to implement in that SystemSuspend.cpp file.

Hi Jason,

Thanks for taking a look. I'm concerned holding the sys/power/state
open would have unintentional side effects. Adding the
/sys/power/userspace_autosuspender seems more appropriate. We don't
have a use case for the refcounting, so would prefer the simpler
writing '0' / '1' to toggle semantics.

Thanks,
Kalesh

>
> Jason

From Jason at zx2c4.com  Wed Jun 29 23:02:33 2022
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Thu, 30 Jun 2022 01:02:33 +0200
Subject: [PATCH] remove CONFIG_ANDROID
In-Reply-To: <CAC_TJve_Jk0+XD7VeSJVvJq4D9ZofnH69B4QZv2LPT4X3KNfeg@mail.gmail.com>
References: <20220629161020.GA24891@lst.de> <Yrx6EVHtroXeEZGp@zx2c4.com>
 <20220629161527.GA24978@lst.de> <Yrx8/Fyx15CTi2zq@zx2c4.com>
 <20220629163007.GA25279@lst.de> <Yrx/8UOY+J8Ao3Bd@zx2c4.com>
 <YryNQvWGVwCjJYmB@zx2c4.com> <Yryic4YG9X2/DJiX@google.com>
 <Yry6XvOGge2xKx/n@zx2c4.com>
 <CAC_TJve_Jk0+XD7VeSJVvJq4D9ZofnH69B4QZv2LPT4X3KNfeg@mail.gmail.com>
Message-ID: <YrzaCRl9rwy9DgOC@zx2c4.com>

Hi Kalesh,

On Wed, Jun 29, 2022 at 03:26:33PM -0700, Kalesh Singh wrote:
> Thanks for taking a look. I'm concerned holding the sys/power/state
> open would have unintentional side effects. Adding the
> /sys/power/userspace_autosuspender seems more appropriate. We don't
> have a use case for the refcounting, so would prefer the simpler
> writing '0' / '1' to toggle semantics.

Alright. So I've cooked you up some code that you can submit, since I
assume based on Christoph's bristliness that he won't do so. The below
adds /sys/power/pm_userspace_autosleeper, which you can write a 0 or a 1
into, and fixes up wireguard and random.c to use it. The code is
untested, but should generally be the correct thing, I think.

So in order of operations:

1. You write a patch for SystemSuspend.cpp and post it on Gerrit.

2. You take the diff below, clean it up or bikeshed the naming a bit or
   do whatever there, and submit it to Rafael's PM tree, including as a
   `Link: ...` this thread and the Gerrit link.

3. When/if Rafael accepts the patch, you submit the Gerrit CL.

4. When both have landed, Christoph moves forward with his
   CONFIG_ANDROID removal.

Does that seem like a reasonable way forward?

Jason

diff --git a/drivers/char/random.c b/drivers/char/random.c
index e3dd1dd3dd22..c25e3be10d9c 100644
--- a/drivers/char/random.c
+++ b/drivers/char/random.c
@@ -756,7 +756,7 @@ static int random_pm_notification(struct notifier_block *nb, unsigned long actio
 
 	if (crng_ready() && (action == PM_RESTORE_PREPARE ||
 	    (action == PM_POST_SUSPEND &&
-	     !IS_ENABLED(CONFIG_PM_AUTOSLEEP) && !IS_ENABLED(CONFIG_ANDROID)))) {
+	     !IS_ENABLED(CONFIG_PM_AUTOSLEEP) && !pm_userspace_autosleeper_enabled))) {
 		crng_reseed();
 		pr_notice("crng reseeded on system resumption\n");
 	}
diff --git a/drivers/net/wireguard/device.c b/drivers/net/wireguard/device.c
index aa9a7a5970fd..1983e0fadb6e 100644
--- a/drivers/net/wireguard/device.c
+++ b/drivers/net/wireguard/device.c
@@ -69,7 +69,7 @@ static int wg_pm_notification(struct notifier_block *nb, unsigned long action, v
 	 * its normal operation rather than as a somewhat rare event, then we
 	 * don't actually want to clear keys.
 	 */
-	if (IS_ENABLED(CONFIG_PM_AUTOSLEEP) || IS_ENABLED(CONFIG_ANDROID))
+	if (IS_ENABLED(CONFIG_PM_AUTOSLEEP) || pm_userspace_autosleeper_enabled)
 		return 0;
 
 	if (action != PM_HIBERNATION_PREPARE && action != PM_SUSPEND_PREPARE)
diff --git a/include/linux/suspend.h b/include/linux/suspend.h
index 70f2921e2e70..0acff26f87b4 100644
--- a/include/linux/suspend.h
+++ b/include/linux/suspend.h
@@ -498,6 +498,7 @@ extern void ksys_sync_helper(void);
 /* drivers/base/power/wakeup.c */
 extern bool events_check_enabled;
 extern suspend_state_t pm_suspend_target_state;
+extern bool pm_userspace_autosleeper_enabled;
 
 extern bool pm_wakeup_pending(void);
 extern void pm_system_wakeup(void);
@@ -537,6 +538,8 @@ static inline void pm_system_irq_wakeup(unsigned int irq_number) {}
 static inline void lock_system_sleep(void) {}
 static inline void unlock_system_sleep(void) {}
 
+#define pm_userspace_autosleeper_enabled (false)
+
 #endif /* !CONFIG_PM_SLEEP */
 
 #ifdef CONFIG_PM_SLEEP_DEBUG
diff --git a/kernel/power/main.c b/kernel/power/main.c
index e3694034b753..08f32a281010 100644
--- a/kernel/power/main.c
+++ b/kernel/power/main.c
@@ -120,6 +120,23 @@ static ssize_t pm_async_store(struct kobject *kobj, struct kobj_attribute *attr,
 
 power_attr(pm_async);
 
+bool pm_userspace_autosleeper_enabled;
+
+static ssize_t pm_userspace_autosleeper_show(struct kobject *kobj,
+				struct kobj_attribute *attr, char *buf)
+{
+	return sprintf(buf, "%d\n", pm_userspace_autosleeper_enabled);
+}
+
+static ssize_t pm_userspace_autosleeper_store(struct kobject *kobj,
+				    struct kobj_attribute *attr,
+				    const char *buf, size_t n)
+{
+	return kstrtobool(buf, &pm_userspace_autosleeper_enabled);
+}
+
+power_attr(pm_userspace_autosleeper);
+
 #ifdef CONFIG_SUSPEND
 static ssize_t mem_sleep_show(struct kobject *kobj, struct kobj_attribute *attr,
 			      char *buf)
@@ -869,6 +886,7 @@ static struct attribute * g[] = {
 #ifdef CONFIG_PM_SLEEP
 	&pm_async_attr.attr,
 	&wakeup_count_attr.attr,
+	&pm_userspace_autosleeper.attr,
 #ifdef CONFIG_SUSPEND
 	&mem_sleep_attr.attr,
 	&sync_on_suspend_attr.attr,


From hch at lst.de  Wed Jun 29 15:01:01 2022
From: hch at lst.de (Christoph Hellwig)
Date: Wed, 29 Jun 2022 17:01:01 +0200
Subject: remove CONFIG_ANDROID
Message-ID: <20220629150102.1582425-1-hch@lst.de>

Hi Greg,

this series removes the CONFIG_ANDROID.  It just guards the Kconfig
option for binder and then changes a bunch of random defaults and
settings, which makes no sense whatsoever and none of those changes
had any good justifcation in their commit logs either.


From hch at lst.de  Wed Jun 29 15:01:02 2022
From: hch at lst.de (Christoph Hellwig)
Date: Wed, 29 Jun 2022 17:01:02 +0200
Subject: [PATCH] remove CONFIG_ANDROID
In-Reply-To: <20220629150102.1582425-1-hch@lst.de>
References: <20220629150102.1582425-1-hch@lst.de>
Message-ID: <20220629150102.1582425-2-hch@lst.de>

The ANDROID config symbol is only used to guard the binder config
symbol and to inject completely random config changes.  Remove it
as it is obviously a bad idea.

Signed-off-by: Christoph Hellwig <hch at lst.de>
---
 drivers/Makefile                                    | 2 +-
 drivers/android/Kconfig                             | 9 ---------
 drivers/char/random.c                               | 3 +--
 drivers/net/wireguard/device.c                      | 2 +-
 kernel/configs/android-base.config                  | 1 -
 kernel/rcu/Kconfig.debug                            | 3 +--
 tools/testing/selftests/filesystems/binderfs/config | 1 -
 tools/testing/selftests/sync/config                 | 1 -
 8 files changed, 4 insertions(+), 18 deletions(-)

diff --git a/drivers/Makefile b/drivers/Makefile
index 9a30842b22c54..123dce2867583 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -176,7 +176,7 @@ obj-$(CONFIG_USB4)		+= thunderbolt/
 obj-$(CONFIG_CORESIGHT)		+= hwtracing/coresight/
 obj-y				+= hwtracing/intel_th/
 obj-$(CONFIG_STM)		+= hwtracing/stm/
-obj-$(CONFIG_ANDROID)		+= android/
+obj-y				+= android/
 obj-$(CONFIG_NVMEM)		+= nvmem/
 obj-$(CONFIG_FPGA)		+= fpga/
 obj-$(CONFIG_FSI)		+= fsi/
diff --git a/drivers/android/Kconfig b/drivers/android/Kconfig
index 53b22e26266c3..07aa8ae0a058c 100644
--- a/drivers/android/Kconfig
+++ b/drivers/android/Kconfig
@@ -1,13 +1,6 @@
 # SPDX-License-Identifier: GPL-2.0
 menu "Android"
 
-config ANDROID
-	bool "Android Drivers"
-	help
-	  Enable support for various drivers needed on the Android platform
-
-if ANDROID
-
 config ANDROID_BINDER_IPC
 	bool "Android Binder IPC Driver"
 	depends on MMU
@@ -54,6 +47,4 @@ config ANDROID_BINDER_IPC_SELFTEST
 	  exhaustively with combinations of various buffer sizes and
 	  alignments.
 
-endif # if ANDROID
-
 endmenu
diff --git a/drivers/char/random.c b/drivers/char/random.c
index e3dd1dd3dd226..f35ad1a9dff3e 100644
--- a/drivers/char/random.c
+++ b/drivers/char/random.c
@@ -755,8 +755,7 @@ static int random_pm_notification(struct notifier_block *nb, unsigned long actio
 	spin_unlock_irqrestore(&input_pool.lock, flags);
 
 	if (crng_ready() && (action == PM_RESTORE_PREPARE ||
-	    (action == PM_POST_SUSPEND &&
-	     !IS_ENABLED(CONFIG_PM_AUTOSLEEP) && !IS_ENABLED(CONFIG_ANDROID)))) {
+	    (action == PM_POST_SUSPEND && !IS_ENABLED(CONFIG_PM_AUTOSLEEP)))) {
 		crng_reseed();
 		pr_notice("crng reseeded on system resumption\n");
 	}
diff --git a/drivers/net/wireguard/device.c b/drivers/net/wireguard/device.c
index aa9a7a5970fda..de1cc03f7ee86 100644
--- a/drivers/net/wireguard/device.c
+++ b/drivers/net/wireguard/device.c
@@ -69,7 +69,7 @@ static int wg_pm_notification(struct notifier_block *nb, unsigned long action, v
 	 * its normal operation rather than as a somewhat rare event, then we
 	 * don't actually want to clear keys.
 	 */
-	if (IS_ENABLED(CONFIG_PM_AUTOSLEEP) || IS_ENABLED(CONFIG_ANDROID))
+	if (IS_ENABLED(CONFIG_PM_AUTOSLEEP))
 		return 0;
 
 	if (action != PM_HIBERNATION_PREPARE && action != PM_SUSPEND_PREPARE)
diff --git a/kernel/configs/android-base.config b/kernel/configs/android-base.config
index eb701b2ac72ff..44b0f0146a3fc 100644
--- a/kernel/configs/android-base.config
+++ b/kernel/configs/android-base.config
@@ -7,7 +7,6 @@
 # CONFIG_OABI_COMPAT is not set
 # CONFIG_SYSVIPC is not set
 # CONFIG_USELIB is not set
-CONFIG_ANDROID=y
 CONFIG_ANDROID_BINDER_IPC=y
 CONFIG_ANDROID_BINDER_DEVICES=binder,hwbinder,vndbinder
 CONFIG_ANDROID_LOW_MEMORY_KILLER=y
diff --git a/kernel/rcu/Kconfig.debug b/kernel/rcu/Kconfig.debug
index 9b64e55d4f615..e875f4f889656 100644
--- a/kernel/rcu/Kconfig.debug
+++ b/kernel/rcu/Kconfig.debug
@@ -86,8 +86,7 @@ config RCU_EXP_CPU_STALL_TIMEOUT
 	int "Expedited RCU CPU stall timeout in milliseconds"
 	depends on RCU_STALL_COMMON
 	range 0 21000
-	default 20 if ANDROID
-	default 0 if !ANDROID
+	default 0
 	help
 	  If a given expedited RCU grace period extends more than the
 	  specified number of milliseconds, a CPU stall warning is printed.
diff --git a/tools/testing/selftests/filesystems/binderfs/config b/tools/testing/selftests/filesystems/binderfs/config
index 02dd6cc9cf992..7b4fc6ee62057 100644
--- a/tools/testing/selftests/filesystems/binderfs/config
+++ b/tools/testing/selftests/filesystems/binderfs/config
@@ -1,3 +1,2 @@
-CONFIG_ANDROID=y
 CONFIG_ANDROID_BINDERFS=y
 CONFIG_ANDROID_BINDER_IPC=y
diff --git a/tools/testing/selftests/sync/config b/tools/testing/selftests/sync/config
index 47ff5afc37271..64c60f38b4464 100644
--- a/tools/testing/selftests/sync/config
+++ b/tools/testing/selftests/sync/config
@@ -1,3 +1,2 @@
 CONFIG_STAGING=y
-CONFIG_ANDROID=y
 CONFIG_SW_SYNC=y
-- 
2.30.2


From hch at lst.de  Wed Jun 29 16:10:20 2022
From: hch at lst.de (Christoph Hellwig)
Date: Wed, 29 Jun 2022 18:10:20 +0200
Subject: [PATCH] remove CONFIG_ANDROID
In-Reply-To: <Yrx5Lt7jrk5BiHXx@zx2c4.com>
References: <20220629150102.1582425-1-hch@lst.de>
 <20220629150102.1582425-2-hch@lst.de> <Yrx5Lt7jrk5BiHXx@zx2c4.com>
Message-ID: <20220629161020.GA24891@lst.de>

On Wed, Jun 29, 2022 at 06:09:18PM +0200, Jason A. Donenfeld wrote:
> CONFIG_ANDROID is used here for a reason. As somebody suggested in
> another thread of which you were a participant, it acts as a proxy for
> "probably running on Android hardware",

No, it does not in any way.

From hch at lst.de  Wed Jun 29 16:15:27 2022
From: hch at lst.de (Christoph Hellwig)
Date: Wed, 29 Jun 2022 18:15:27 +0200
Subject: [PATCH] remove CONFIG_ANDROID
In-Reply-To: <Yrx6EVHtroXeEZGp@zx2c4.com>
References: <20220629150102.1582425-1-hch@lst.de>
 <20220629150102.1582425-2-hch@lst.de> <Yrx5Lt7jrk5BiHXx@zx2c4.com>
 <20220629161020.GA24891@lst.de> <Yrx6EVHtroXeEZGp@zx2c4.com>
Message-ID: <20220629161527.GA24978@lst.de>

On Wed, Jun 29, 2022 at 06:13:05PM +0200, Jason A. Donenfeld wrote:
> Good! It sounds like you're starting to develop opinions on the matter.

No, I provide facts.  Look at both the definition of the symbol, and
various distribution kernel that enabled it and think hard if they run
on "Android" hardware.  Not just primarily, but at all.

From hch at lst.de  Wed Jun 29 16:30:07 2022
From: hch at lst.de (Christoph Hellwig)
Date: Wed, 29 Jun 2022 18:30:07 +0200
Subject: [PATCH] remove CONFIG_ANDROID
In-Reply-To: <Yrx8/Fyx15CTi2zq@zx2c4.com>
References: <20220629150102.1582425-1-hch@lst.de>
 <20220629150102.1582425-2-hch@lst.de> <Yrx5Lt7jrk5BiHXx@zx2c4.com>
 <20220629161020.GA24891@lst.de> <Yrx6EVHtroXeEZGp@zx2c4.com>
 <20220629161527.GA24978@lst.de> <Yrx8/Fyx15CTi2zq@zx2c4.com>
Message-ID: <20220629163007.GA25279@lst.de>

On Wed, Jun 29, 2022 at 06:25:32PM +0200, Jason A. Donenfeld wrote:
> Anyway, instead of the slow drip of "facts" and ?three sentence emails,
> can you just write up a paragraph that indicates this is safe to do (for
> both (1) and (2)) in your v+1?

Why would I care?  If your config wakeups up so often that you need
special casing find a way to deal with it.  In the upstream kernel
CONFIG_ANDROID is a very strong indicator for a desktop kernel as
that is much more common than someone actually running upstream Linux
on one of the very few Android devices actually fully supported by
upstream Linux.

From hch at lst.de  Wed Jun 29 16:37:01 2022
From: hch at lst.de (Christoph Hellwig)
Date: Wed, 29 Jun 2022 18:37:01 +0200
Subject: [PATCH] remove CONFIG_ANDROID
In-Reply-To: <20220629163444.GG1790663@paulmck-ThinkPad-P17-Gen-1>
References: <20220629150102.1582425-1-hch@lst.de>
 <20220629150102.1582425-2-hch@lst.de> <Yrx5Lt7jrk5BiHXx@zx2c4.com>
 <20220629161020.GA24891@lst.de> <Yrx6EVHtroXeEZGp@zx2c4.com>
 <20220629161527.GA24978@lst.de>
 <20220629163444.GG1790663@paulmck-ThinkPad-P17-Gen-1>
Message-ID: <20220629163701.GA25519@lst.de>

On Wed, Jun 29, 2022 at 09:34:44AM -0700, Paul E. McKenney wrote:
> So you are OK if your patch is accepted, and then CONFIG_ANDROID is
> re-introduced but used only for building kernels intended to run on
> Android systems?

I don't think that is a good config.  In general you want APIs
to express behavior, and in that case that is goes to sleep and
wakes all the time.  So we need go figure out what causes this in
Android systems - I don't think it can be the hardware, so it must
be a policy set somewhere either in the kernel or fed into the kernel
by userspace.  Then we can key it off that, and I suspect it is
probably going to be a runtime variable and not a config option.

From hch at lst.de  Wed Jun 29 16:45:43 2022
From: hch at lst.de (Christoph Hellwig)
Date: Wed, 29 Jun 2022 18:45:43 +0200
Subject: [PATCH] remove CONFIG_ANDROID
In-Reply-To: <Yrx/8UOY+J8Ao3Bd@zx2c4.com>
References: <20220629150102.1582425-1-hch@lst.de>
 <20220629150102.1582425-2-hch@lst.de> <Yrx5Lt7jrk5BiHXx@zx2c4.com>
 <20220629161020.GA24891@lst.de> <Yrx6EVHtroXeEZGp@zx2c4.com>
 <20220629161527.GA24978@lst.de> <Yrx8/Fyx15CTi2zq@zx2c4.com>
 <20220629163007.GA25279@lst.de> <Yrx/8UOY+J8Ao3Bd@zx2c4.com>
Message-ID: <20220629164543.GA25672@lst.de>

On Wed, Jun 29, 2022 at 06:38:09PM +0200, Jason A. Donenfeld wrote:
> On the technical topic, an Android developer friend following this
> thread just pointed out to me that Android doesn't use PM_AUTOSLEEP and
> just has userspace causing suspend frequently. So by his rough
> estimation your patch actually *will* break Android devices. Zoinks.
> Maybe he's right, maybe he's not -- I don't know -- but you should
> probably look into this if you want this patch to land without breakage.

And it will also "break" anyone else doing frequent suspends from
userspace, as that behavior is still in no way related to
CONFIG_ANDROID.

From rostedt at goodmis.org  Wed Jun 29 16:56:43 2022
From: rostedt at goodmis.org (Steven Rostedt)
Date: Wed, 29 Jun 2022 12:56:43 -0400
Subject: [PATCH] remove CONFIG_ANDROID
In-Reply-To: <20220629164543.GA25672@lst.de>
References: <20220629150102.1582425-1-hch@lst.de>
 <20220629150102.1582425-2-hch@lst.de> <Yrx5Lt7jrk5BiHXx@zx2c4.com>
 <20220629161020.GA24891@lst.de> <Yrx6EVHtroXeEZGp@zx2c4.com>
 <20220629161527.GA24978@lst.de> <Yrx8/Fyx15CTi2zq@zx2c4.com>
 <20220629163007.GA25279@lst.de> <Yrx/8UOY+J8Ao3Bd@zx2c4.com>
 <20220629164543.GA25672@lst.de>
Message-ID: <20220629125643.393df70d@gandalf.local.home>


[ Note, I'm not on the Android team and my response has nothing to do with
  my employer. I would say the same thing with my previous employer. ]

On Wed, 29 Jun 2022 18:45:43 +0200
Christoph Hellwig <hch at lst.de> wrote:

> On Wed, Jun 29, 2022 at 06:38:09PM +0200, Jason A. Donenfeld wrote:
> > On the technical topic, an Android developer friend following this
> > thread just pointed out to me that Android doesn't use PM_AUTOSLEEP and
> > just has userspace causing suspend frequently. So by his rough
> > estimation your patch actually *will* break Android devices. Zoinks.
> > Maybe he's right, maybe he's not -- I don't know -- but you should
> > probably look into this if you want this patch to land without breakage.  
> 
> And it will also "break" anyone else doing frequent suspends from
> userspace, as that behavior is still in no way related to
> CONFIG_ANDROID.

Should there then be a CONFIG_FREQUENT_SUSPENDS ?

That is, if you have system where you know that there will be a lot of
frequent suspends coming from user space, then you would enable it.

I agree, calling this ANDROID is not related to the functionality change.
But if there was a config that was related, would that be acceptable?

Then it would not just be Android that could enabled this change, but any
other system that is doing frequent suspends?

-- Steve

From hch at lst.de  Wed Jun 29 17:35:45 2022
From: hch at lst.de (Christoph Hellwig)
Date: Wed, 29 Jun 2022 19:35:45 +0200
Subject: [PATCH] remove CONFIG_ANDROID
In-Reply-To: <YryMO6PX+G9owRGz@zx2c4.com>
References: <20220629161527.GA24978@lst.de> <Yrx8/Fyx15CTi2zq@zx2c4.com>
 <20220629163007.GA25279@lst.de> <Yrx/8UOY+J8Ao3Bd@zx2c4.com>
 <20220629164543.GA25672@lst.de>
 <CAHmME9rwKmEQcn84GfTrCPzaK3g6vh6rpQ=YcgyTo_PWpJ5VcA@mail.gmail.com>
 <YryFKXsx/Bgv/oBE@kroah.com> <YryHk06Ye/12dMEN@zx2c4.com>
 <YryJqI/ppVfMhRhI@kroah.com> <YryMO6PX+G9owRGz@zx2c4.com>
Message-ID: <20220629173545.GA26648@lst.de>

On Wed, Jun 29, 2022 at 07:30:35PM +0200, Jason A. Donenfeld wrote:
> Properly resolved by whom? It sounds like you're up for intentionally
> allowing a userspace regression, and also volunteering other people's
> time into fixing that regression? The way I understand the kernel
> development process is that the person proposing a change is responsible
> for not intentionally causing regressions, and if one is pointed out, a
> v+1 of that patch is provided that doesn't cause the regression.

If you think the code does not work when the system frequently suspends
and resumes, then well it is broken already, as that can happen just
as much on non-Android systems.  So maybe we should just remove it if
it is so broken that you fear about regressions on the 3 and a half
Android systems in the world running an upstream kernel?

From tytso at mit.edu  Wed Jun 29 19:41:00 2022
From: tytso at mit.edu (Theodore Ts'o)
Date: Wed, 29 Jun 2022 15:41:00 -0400
Subject: [PATCH] remove CONFIG_ANDROID
In-Reply-To: <Yryic4YG9X2/DJiX@google.com>
References: <20220629150102.1582425-2-hch@lst.de> <Yrx5Lt7jrk5BiHXx@zx2c4.com>
 <20220629161020.GA24891@lst.de> <Yrx6EVHtroXeEZGp@zx2c4.com>
 <20220629161527.GA24978@lst.de> <Yrx8/Fyx15CTi2zq@zx2c4.com>
 <20220629163007.GA25279@lst.de> <Yrx/8UOY+J8Ao3Bd@zx2c4.com>
 <YryNQvWGVwCjJYmB@zx2c4.com> <Yryic4YG9X2/DJiX@google.com>
Message-ID: <YryqzCNqVcMtKROJ@mit.edu>

On Wed, Jun 29, 2022 at 12:05:23PM -0700, Kalesh Singh wrote:
> 
> Android no longer uses PM_AUTOSLEEP, is correct. libsuspend is
> also now deprecated. Android autosuspend is initiatiated from the
> userspace system suspend service [1].

Is anything still using CONFIG_PM_AUTOSLEEP?  Is it perhaps time to
consider deprecating it?

						- Ted

From kaleshsingh at google.com  Wed Jun 29 23:19:52 2022
From: kaleshsingh at google.com (Kalesh Singh)
Date: Wed, 29 Jun 2022 16:19:52 -0700
Subject: [PATCH] remove CONFIG_ANDROID
In-Reply-To: <YrzaCRl9rwy9DgOC@zx2c4.com>
References: <20220629161020.GA24891@lst.de> <Yrx6EVHtroXeEZGp@zx2c4.com>
 <20220629161527.GA24978@lst.de> <Yrx8/Fyx15CTi2zq@zx2c4.com>
 <20220629163007.GA25279@lst.de> <Yrx/8UOY+J8Ao3Bd@zx2c4.com>
 <YryNQvWGVwCjJYmB@zx2c4.com> <Yryic4YG9X2/DJiX@google.com>
 <Yry6XvOGge2xKx/n@zx2c4.com>
 <CAC_TJve_Jk0+XD7VeSJVvJq4D9ZofnH69B4QZv2LPT4X3KNfeg@mail.gmail.com>
 <YrzaCRl9rwy9DgOC@zx2c4.com>
Message-ID: <CAC_TJvcEzp+zQp50wtj4=7b6vEObpJCQYLaTLhHJCxFdk3TgPg@mail.gmail.com>

On Wed, Jun 29, 2022 at 4:02 PM Jason A. Donenfeld <Jason at zx2c4.com> wrote:
>
> Hi Kalesh,
>
> On Wed, Jun 29, 2022 at 03:26:33PM -0700, Kalesh Singh wrote:
> > Thanks for taking a look. I'm concerned holding the sys/power/state
> > open would have unintentional side effects. Adding the
> > /sys/power/userspace_autosuspender seems more appropriate. We don't
> > have a use case for the refcounting, so would prefer the simpler
> > writing '0' / '1' to toggle semantics.
>
> Alright. So I've cooked you up some code that you can submit, since I
> assume based on Christoph's bristliness that he won't do so. The below
> adds /sys/power/pm_userspace_autosleeper, which you can write a 0 or a 1
> into, and fixes up wireguard and random.c to use it. The code is
> untested, but should generally be the correct thing, I think.
>
> So in order of operations:
>
> 1. You write a patch for SystemSuspend.cpp and post it on Gerrit.
>
> 2. You take the diff below, clean it up or bikeshed the naming a bit or
>    do whatever there, and submit it to Rafael's PM tree, including as a
>    `Link: ...` this thread and the Gerrit link.
>
> 3. When/if Rafael accepts the patch, you submit the Gerrit CL.
>
> 4. When both have landed, Christoph moves forward with his
>    CONFIG_ANDROID removal.
>
> Does that seem like a reasonable way forward?

Sounds like a plan. I'll clean up and repost your patch once the
Gerrit change is ready.

Thanks,
Kalesh
>
> Jason
>
> diff --git a/drivers/char/random.c b/drivers/char/random.c
> index e3dd1dd3dd22..c25e3be10d9c 100644
> --- a/drivers/char/random.c
> +++ b/drivers/char/random.c
> @@ -756,7 +756,7 @@ static int random_pm_notification(struct notifier_block *nb, unsigned long actio
>
>         if (crng_ready() && (action == PM_RESTORE_PREPARE ||
>             (action == PM_POST_SUSPEND &&
> -            !IS_ENABLED(CONFIG_PM_AUTOSLEEP) && !IS_ENABLED(CONFIG_ANDROID)))) {
> +            !IS_ENABLED(CONFIG_PM_AUTOSLEEP) && !pm_userspace_autosleeper_enabled))) {
>                 crng_reseed();
>                 pr_notice("crng reseeded on system resumption\n");
>         }
> diff --git a/drivers/net/wireguard/device.c b/drivers/net/wireguard/device.c
> index aa9a7a5970fd..1983e0fadb6e 100644
> --- a/drivers/net/wireguard/device.c
> +++ b/drivers/net/wireguard/device.c
> @@ -69,7 +69,7 @@ static int wg_pm_notification(struct notifier_block *nb, unsigned long action, v
>          * its normal operation rather than as a somewhat rare event, then we
>          * don't actually want to clear keys.
>          */
> -       if (IS_ENABLED(CONFIG_PM_AUTOSLEEP) || IS_ENABLED(CONFIG_ANDROID))
> +       if (IS_ENABLED(CONFIG_PM_AUTOSLEEP) || pm_userspace_autosleeper_enabled)
>                 return 0;
>
>         if (action != PM_HIBERNATION_PREPARE && action != PM_SUSPEND_PREPARE)
> diff --git a/include/linux/suspend.h b/include/linux/suspend.h
> index 70f2921e2e70..0acff26f87b4 100644
> --- a/include/linux/suspend.h
> +++ b/include/linux/suspend.h
> @@ -498,6 +498,7 @@ extern void ksys_sync_helper(void);
>  /* drivers/base/power/wakeup.c */
>  extern bool events_check_enabled;
>  extern suspend_state_t pm_suspend_target_state;
> +extern bool pm_userspace_autosleeper_enabled;
>
>  extern bool pm_wakeup_pending(void);
>  extern void pm_system_wakeup(void);
> @@ -537,6 +538,8 @@ static inline void pm_system_irq_wakeup(unsigned int irq_number) {}
>  static inline void lock_system_sleep(void) {}
>  static inline void unlock_system_sleep(void) {}
>
> +#define pm_userspace_autosleeper_enabled (false)
> +
>  #endif /* !CONFIG_PM_SLEEP */
>
>  #ifdef CONFIG_PM_SLEEP_DEBUG
> diff --git a/kernel/power/main.c b/kernel/power/main.c
> index e3694034b753..08f32a281010 100644
> --- a/kernel/power/main.c
> +++ b/kernel/power/main.c
> @@ -120,6 +120,23 @@ static ssize_t pm_async_store(struct kobject *kobj, struct kobj_attribute *attr,
>
>  power_attr(pm_async);
>
> +bool pm_userspace_autosleeper_enabled;
> +
> +static ssize_t pm_userspace_autosleeper_show(struct kobject *kobj,
> +                               struct kobj_attribute *attr, char *buf)
> +{
> +       return sprintf(buf, "%d\n", pm_userspace_autosleeper_enabled);
> +}
> +
> +static ssize_t pm_userspace_autosleeper_store(struct kobject *kobj,
> +                                   struct kobj_attribute *attr,
> +                                   const char *buf, size_t n)
> +{
> +       return kstrtobool(buf, &pm_userspace_autosleeper_enabled);
> +}
> +
> +power_attr(pm_userspace_autosleeper);
> +
>  #ifdef CONFIG_SUSPEND
>  static ssize_t mem_sleep_show(struct kobject *kobj, struct kobj_attribute *attr,
>                               char *buf)
> @@ -869,6 +886,7 @@ static struct attribute * g[] = {
>  #ifdef CONFIG_PM_SLEEP
>         &pm_async_attr.attr,
>         &wakeup_count_attr.attr,
> +       &pm_userspace_autosleeper.attr,
>  #ifdef CONFIG_SUSPEND
>         &mem_sleep_attr.attr,
>         &sync_on_suspend_attr.attr,
>

From jstultz at google.com  Wed Jun 29 23:52:05 2022
From: jstultz at google.com (John Stultz)
Date: Wed, 29 Jun 2022 16:52:05 -0700
Subject: [PATCH] remove CONFIG_ANDROID
In-Reply-To: <YrzaCRl9rwy9DgOC@zx2c4.com>
References: <20220629161020.GA24891@lst.de> <Yrx6EVHtroXeEZGp@zx2c4.com>
 <20220629161527.GA24978@lst.de> <Yrx8/Fyx15CTi2zq@zx2c4.com>
 <20220629163007.GA25279@lst.de> <Yrx/8UOY+J8Ao3Bd@zx2c4.com>
 <YryNQvWGVwCjJYmB@zx2c4.com> <Yryic4YG9X2/DJiX@google.com>
 <Yry6XvOGge2xKx/n@zx2c4.com>
 <CAC_TJve_Jk0+XD7VeSJVvJq4D9ZofnH69B4QZv2LPT4X3KNfeg@mail.gmail.com>
 <YrzaCRl9rwy9DgOC@zx2c4.com>
Message-ID: <CANDhNCpRzzULaGmEGCbbJgVinA0pJJB-gOP9AY0Hy488n9ZStA@mail.gmail.com>

On Wed, Jun 29, 2022 at 4:02 PM Jason A. Donenfeld <Jason at zx2c4.com> wrote:
>
> Hi Kalesh,
>
> On Wed, Jun 29, 2022 at 03:26:33PM -0700, Kalesh Singh wrote:
> > Thanks for taking a look. I'm concerned holding the sys/power/state
> > open would have unintentional side effects. Adding the
> > /sys/power/userspace_autosuspender seems more appropriate. We don't
> > have a use case for the refcounting, so would prefer the simpler
> > writing '0' / '1' to toggle semantics.
>
> Alright. So I've cooked you up some code that you can submit, since I
> assume based on Christoph's bristliness that he won't do so. The below
> adds /sys/power/pm_userspace_autosleeper, which you can write a 0 or a 1
> into, and fixes up wireguard and random.c to use it. The code is
> untested, but should generally be the correct thing, I think.
>
> So in order of operations:
>
> 1. You write a patch for SystemSuspend.cpp and post it on Gerrit.
>
> 2. You take the diff below, clean it up or bikeshed the naming a bit or
>    do whatever there, and submit it to Rafael's PM tree, including as a
>    `Link: ...` this thread and the Gerrit link.
>
> 3. When/if Rafael accepts the patch, you submit the Gerrit CL.
>
> 4. When both have landed, Christoph moves forward with his
>    CONFIG_ANDROID removal.
>
> Does that seem like a reasonable way forward?
>
> Jason
>
> diff --git a/drivers/char/random.c b/drivers/char/random.c
> index e3dd1dd3dd22..c25e3be10d9c 100644
> --- a/drivers/char/random.c
> +++ b/drivers/char/random.c
> @@ -756,7 +756,7 @@ static int random_pm_notification(struct notifier_block *nb, unsigned long actio
>
>         if (crng_ready() && (action == PM_RESTORE_PREPARE ||
>             (action == PM_POST_SUSPEND &&
> -            !IS_ENABLED(CONFIG_PM_AUTOSLEEP) && !IS_ENABLED(CONFIG_ANDROID)))) {
> +            !IS_ENABLED(CONFIG_PM_AUTOSLEEP) && !pm_userspace_autosleeper_enabled))) {
>                 crng_reseed();
>                 pr_notice("crng reseeded on system resumption\n");
>         }
> diff --git a/drivers/net/wireguard/device.c b/drivers/net/wireguard/device.c
> index aa9a7a5970fd..1983e0fadb6e 100644
> --- a/drivers/net/wireguard/device.c
> +++ b/drivers/net/wireguard/device.c
> @@ -69,7 +69,7 @@ static int wg_pm_notification(struct notifier_block *nb, unsigned long action, v
>          * its normal operation rather than as a somewhat rare event, then we
>          * don't actually want to clear keys.
>          */
> -       if (IS_ENABLED(CONFIG_PM_AUTOSLEEP) || IS_ENABLED(CONFIG_ANDROID))
> +       if (IS_ENABLED(CONFIG_PM_AUTOSLEEP) || pm_userspace_autosleeper_enabled)
>                 return 0;
>
>         if (action != PM_HIBERNATION_PREPARE && action != PM_SUSPEND_PREPARE)
> diff --git a/include/linux/suspend.h b/include/linux/suspend.h
> index 70f2921e2e70..0acff26f87b4 100644
> --- a/include/linux/suspend.h
> +++ b/include/linux/suspend.h
> @@ -498,6 +498,7 @@ extern void ksys_sync_helper(void);
>  /* drivers/base/power/wakeup.c */
>  extern bool events_check_enabled;
>  extern suspend_state_t pm_suspend_target_state;
> +extern bool pm_userspace_autosleeper_enabled;
>
>  extern bool pm_wakeup_pending(void);
>  extern void pm_system_wakeup(void);
> @@ -537,6 +538,8 @@ static inline void pm_system_irq_wakeup(unsigned int irq_number) {}
>  static inline void lock_system_sleep(void) {}
>  static inline void unlock_system_sleep(void) {}
>
> +#define pm_userspace_autosleeper_enabled (false)
> +
>  #endif /* !CONFIG_PM_SLEEP */
>
>  #ifdef CONFIG_PM_SLEEP_DEBUG
> diff --git a/kernel/power/main.c b/kernel/power/main.c
> index e3694034b753..08f32a281010 100644
> --- a/kernel/power/main.c
> +++ b/kernel/power/main.c
> @@ -120,6 +120,23 @@ static ssize_t pm_async_store(struct kobject *kobj, struct kobj_attribute *attr,
>
>  power_attr(pm_async);
>
> +bool pm_userspace_autosleeper_enabled;
> +
> +static ssize_t pm_userspace_autosleeper_show(struct kobject *kobj,
> +                               struct kobj_attribute *attr, char *buf)
> +{
> +       return sprintf(buf, "%d\n", pm_userspace_autosleeper_enabled);
> +}
> +
> +static ssize_t pm_userspace_autosleeper_store(struct kobject *kobj,
> +                                   struct kobj_attribute *attr,
> +                                   const char *buf, size_t n)
> +{
> +       return kstrtobool(buf, &pm_userspace_autosleeper_enabled);
> +}
> +
> +power_attr(pm_userspace_autosleeper);
> +

Jason: Thanks for raising this issue and sharing this patch to avoid
breakage! I really appreciate it.

My only concern with this change introducting a userspace knob set at
runtime, vs a (hopefully more specific than _ANDROID) kernel config is
that it's not exactly clear what the flag really means (which is the
same issue CONFIG_ANDROID has). And more problematic, with this it
would be an ABI.

So for this we probably need to have a very clear description of what
userland is telling the kernel. Because I'm sure userlands behavior
will drift and shift and we'll end up litigating what kind of behavior
is really userspace_autosleeping vs userspace_sortof_autosleeping. :)

Alternatively, maybe we should switch it to describe what behavior
change we are wanting the kernel take (instead of it hinting to the
kernel what to expect from userland's behavior)? That way it might be
more specific.

Again, really appreciate your efforts here!

thanks
-john

From Jason at zx2c4.com  Thu Jun 30 00:24:26 2022
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Thu, 30 Jun 2022 02:24:26 +0200
Subject: [PATCH] remove CONFIG_ANDROID
In-Reply-To: <CANDhNCpRzzULaGmEGCbbJgVinA0pJJB-gOP9AY0Hy488n9ZStA@mail.gmail.com>
References: <20220629161527.GA24978@lst.de> <Yrx8/Fyx15CTi2zq@zx2c4.com>
 <20220629163007.GA25279@lst.de> <Yrx/8UOY+J8Ao3Bd@zx2c4.com>
 <YryNQvWGVwCjJYmB@zx2c4.com> <Yryic4YG9X2/DJiX@google.com>
 <Yry6XvOGge2xKx/n@zx2c4.com>
 <CAC_TJve_Jk0+XD7VeSJVvJq4D9ZofnH69B4QZv2LPT4X3KNfeg@mail.gmail.com>
 <YrzaCRl9rwy9DgOC@zx2c4.com>
 <CANDhNCpRzzULaGmEGCbbJgVinA0pJJB-gOP9AY0Hy488n9ZStA@mail.gmail.com>
Message-ID: <YrztOqBBll66C2/n@zx2c4.com>

Hi John,

On Wed, Jun 29, 2022 at 04:52:05PM -0700, John Stultz wrote:
> Jason: Thanks for raising this issue and sharing this patch to avoid
> breakage! I really appreciate it.
> 
> My only concern with this change introducting a userspace knob set at
> runtime, vs a (hopefully more specific than _ANDROID) kernel config is

I'd also be okay with a compile-time knob. The details make no
difference to me, so long as there's just *something* there.

> that it's not exactly clear what the flag really means (which is the
> same issue CONFIG_ANDROID has). And more problematic, with this it
> would be an ABI.
> 
> So for this we probably need to have a very clear description of what
> userland is telling the kernel. Because I'm sure userlands behavior
> will drift and shift and we'll end up litigating what kind of behavior
> is really userspace_autosleeping vs userspace_sortof_autosleeping. :)

I guess what I have in mind is the answer to these being "yes":
- "Is it very common to be asleep for only 2 seconds before being woken?"
- "Is it very common to be awake for only 2 seconds before sleeping?"

I think it'd be easiest to have a knob somewhere (compiletime,
runtime, wherever) that describes a device that exhibits those
properties. Then wireguard and other things will make a decision on how
to handle the crypto during relevant events.

> Alternatively, maybe we should switch it to describe what behavior
> change we are wanting the kernel take (instead of it hinting to the
> kernel what to expect from userland's behavior)? That way it might be
> more specific.

As a general rule, I don't expose knobs like that in wireguard /itself/,
but wireguard has no problem with adapting to whatever machine properties
it finds itself on. And besides, this *is* a very definite device
property, something really particular and peculiar about the machine
the kernel is running on. It's a concrete thing that the kernel should
know about. So let's go with your "very clear description idea", above,
instead.

So taken together, I guess there are two approaches to this:

1) Introduce a simple CONFIG_PM_CONTINUOUS_AUTOSLEEPING Kconfig thing
   with lots of discouraging help text.

2) Go with the /sys/power tunable and bikeshed the naming of that a bit
   to get it to something that reflects this better, and document it as
   being undesirable except for Android phones.

It seems like in both cases, the key will be getting the naming right.

Jason

From Jason at zx2c4.com  Thu Jun 30 00:30:05 2022
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Thu, 30 Jun 2022 02:30:05 +0200
Subject: [PATCH] remove CONFIG_ANDROID
In-Reply-To: <YrztOqBBll66C2/n@zx2c4.com>
References: <Yrx8/Fyx15CTi2zq@zx2c4.com> <20220629163007.GA25279@lst.de>
 <Yrx/8UOY+J8Ao3Bd@zx2c4.com> <YryNQvWGVwCjJYmB@zx2c4.com>
 <Yryic4YG9X2/DJiX@google.com> <Yry6XvOGge2xKx/n@zx2c4.com>
 <CAC_TJve_Jk0+XD7VeSJVvJq4D9ZofnH69B4QZv2LPT4X3KNfeg@mail.gmail.com>
 <YrzaCRl9rwy9DgOC@zx2c4.com>
 <CANDhNCpRzzULaGmEGCbbJgVinA0pJJB-gOP9AY0Hy488n9ZStA@mail.gmail.com>
 <YrztOqBBll66C2/n@zx2c4.com>
Message-ID: <YrzujZuJyfymC0LP@zx2c4.com>

Hey again,

On Thu, Jun 30, 2022 at 2:24 AM Jason A. Donenfeld <Jason at zx2c4.com> wrote:
> 1) Introduce a simple CONFIG_PM_CONTINUOUS_AUTOSLEEPING Kconfig thing
>    with lots of discouraging help text.
>
> 2) Go with the /sys/power tunable and bikeshed the naming of that a bit
>    to get it to something that reflects this better, and document it as
>    being undesirable except for Android phones.

One other quick thought, which I had mentioned earlier to Kalesh:

3) Make the semantics a process holding open a file descriptor, rather
   than writing 0/1 into a file. It'd be called /sys/power/
   userspace_autosleep_ctrl, or something, and it'd enable this behavior
   while it's opened. And maybe down the line somebody will want to add
   ioctls to it for a different purpose. This way it's less of a tunable
   and more of an indication that there's a userspace app doing/controlling
   something.

This idea (3) may be a lot of added complexity for basically nothing,
but it might fit the usage semantics concerns a bit better than (2). But
anyway, just an idea. Any one of those three are fine with me.

Jason

From joe at perches.com  Thu Jun 30 00:36:57 2022
From: joe at perches.com (Joe Perches)
Date: Wed, 29 Jun 2022 17:36:57 -0700
Subject: [PATCH] remove CONFIG_ANDROID
In-Reply-To: <CAC_TJvcEzp+zQp50wtj4=7b6vEObpJCQYLaTLhHJCxFdk3TgPg@mail.gmail.com>
References: <20220629161020.GA24891@lst.de> <Yrx6EVHtroXeEZGp@zx2c4.com>
 <20220629161527.GA24978@lst.de> <Yrx8/Fyx15CTi2zq@zx2c4.com>
 <20220629163007.GA25279@lst.de> <Yrx/8UOY+J8Ao3Bd@zx2c4.com>
 <YryNQvWGVwCjJYmB@zx2c4.com> <Yryic4YG9X2/DJiX@google.com>
 <Yry6XvOGge2xKx/n@zx2c4.com>
 <CAC_TJve_Jk0+XD7VeSJVvJq4D9ZofnH69B4QZv2LPT4X3KNfeg@mail.gmail.com>
 <YrzaCRl9rwy9DgOC@zx2c4.com>
 <CAC_TJvcEzp+zQp50wtj4=7b6vEObpJCQYLaTLhHJCxFdk3TgPg@mail.gmail.com>
Message-ID: <306dacfb29c2e38312943fa70d419f0a8d5ffe82.camel@perches.com>

On Wed, 2022-06-29 at 16:19 -0700, Kalesh Singh wrote:
> On Wed, Jun 29, 2022 at 4:02 PM Jason A. Donenfeld <Jason at zx2c4.com> wrote:
> > On Wed, Jun 29, 2022 at 03:26:33PM -0700, Kalesh Singh wrote:
> > > Thanks for taking a look. I'm concerned holding the sys/power/state
> > > open would have unintentional side effects. Adding the
> > > /sys/power/userspace_autosuspender seems more appropriate. We don't
> > > have a use case for the refcounting, so would prefer the simpler
> > > writing '0' / '1' to toggle semantics.
> > 
> > Alright. So I've cooked you up some code that you can submit, since I
> > assume based on Christoph's bristliness that he won't do so. The below
> > adds /sys/power/pm_userspace_autosleeper, which you can write a 0 or a 1
> > into, and fixes up wireguard and random.c to use it. The code is
> > untested, but should generally be the correct thing, I think.
> > 
> > So in order of operations:
> > 
> > 1. You write a patch for SystemSuspend.cpp and post it on Gerrit.
> > 
> > 2. You take the diff below, clean it up or bikeshed the naming a bit or
> >    do whatever there, and submit it to Rafael's PM tree, including as a
> >    `Link: ...` this thread and the Gerrit link.
> > 
> > 3. When/if Rafael accepts the patch, you submit the Gerrit CL.
> > 
> > 4. When both have landed, Christoph moves forward with his
> >    CONFIG_ANDROID removal.
> > 
> > Does that seem like a reasonable way forward?
> 
> Sounds like a plan. I'll clean up and repost your patch once the
> Gerrit change is ready.

trivial note:

> > diff --git a/kernel/power/main.c b/kernel/power/main.c
[]
> > @@ -120,6 +120,23 @@ static ssize_t pm_async_store(struct kobject *kobj, struct kobj_attribute *attr,
> > 
> >  power_attr(pm_async);
> > 
> > +bool pm_userspace_autosleeper_enabled;
> > +
> > +static ssize_t pm_userspace_autosleeper_show(struct kobject *kobj,
> > +                               struct kobj_attribute *attr, char *buf)
> > +{
> > +       return sprintf(buf, "%d\n", pm_userspace_autosleeper_enabled);

This should use sysfs_emit no?


From Jason at zx2c4.com  Thu Jun 30 00:50:34 2022
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Thu, 30 Jun 2022 02:50:34 +0200
Subject: [PATCH] remove CONFIG_ANDROID
In-Reply-To: <306dacfb29c2e38312943fa70d419f0a8d5ffe82.camel@perches.com>
References: <Yrx8/Fyx15CTi2zq@zx2c4.com> <20220629163007.GA25279@lst.de>
 <Yrx/8UOY+J8Ao3Bd@zx2c4.com> <YryNQvWGVwCjJYmB@zx2c4.com>
 <Yryic4YG9X2/DJiX@google.com> <Yry6XvOGge2xKx/n@zx2c4.com>
 <CAC_TJve_Jk0+XD7VeSJVvJq4D9ZofnH69B4QZv2LPT4X3KNfeg@mail.gmail.com>
 <YrzaCRl9rwy9DgOC@zx2c4.com>
 <CAC_TJvcEzp+zQp50wtj4=7b6vEObpJCQYLaTLhHJCxFdk3TgPg@mail.gmail.com>
 <306dacfb29c2e38312943fa70d419f0a8d5ffe82.camel@perches.com>
Message-ID: <YrzzWmQ9+uDRlO5K@zx2c4.com>

On Wed, Jun 29, 2022 at 05:36:57PM -0700, Joe Perches wrote:
> > > +static ssize_t pm_userspace_autosleeper_show(struct kobject *kobj,
> > > +                               struct kobj_attribute *attr, char *buf)
> > > +{
> > > +       return sprintf(buf, "%d\n", pm_userspace_autosleeper_enabled);
> 
> This should use sysfs_emit no?

Probably, yea. Note that I just copy and pasted a nearby function,
pm_async_show, `:%s/`d the variable name, and then promptly `git diff |
clip`d it and plonked it into my email. Looking at the file, it uses
sprintf all over the place in this fashion. So you may want to submit a
cleanup to Rafael on this if you're right about sysfs_emit() being
universally preferred.

Jason

From joe at perches.com  Thu Jun 30 01:44:14 2022
From: joe at perches.com (Joe Perches)
Date: Wed, 29 Jun 2022 18:44:14 -0700
Subject: [PATCH] remove CONFIG_ANDROID
In-Reply-To: <YrzzWmQ9+uDRlO5K@zx2c4.com>
References: <Yrx8/Fyx15CTi2zq@zx2c4.com> <20220629163007.GA25279@lst.de>
 <Yrx/8UOY+J8Ao3Bd@zx2c4.com> <YryNQvWGVwCjJYmB@zx2c4.com>
 <Yryic4YG9X2/DJiX@google.com> <Yry6XvOGge2xKx/n@zx2c4.com>
 <CAC_TJve_Jk0+XD7VeSJVvJq4D9ZofnH69B4QZv2LPT4X3KNfeg@mail.gmail.com>
 <YrzaCRl9rwy9DgOC@zx2c4.com>
 <CAC_TJvcEzp+zQp50wtj4=7b6vEObpJCQYLaTLhHJCxFdk3TgPg@mail.gmail.com>
 <306dacfb29c2e38312943fa70d419f0a8d5ffe82.camel@perches.com>
 <YrzzWmQ9+uDRlO5K@zx2c4.com>
Message-ID: <1a1f24707a03c2363e29ef91905e9f206fb6a0b5.camel@perches.com>

On Thu, 2022-06-30 at 02:50 +0200, Jason A. Donenfeld wrote:
> On Wed, Jun 29, 2022 at 05:36:57PM -0700, Joe Perches wrote:
> > > > +static ssize_t pm_userspace_autosleeper_show(struct kobject *kobj,
> > > > +                               struct kobj_attribute *attr, char *buf)
> > > > +{
> > > > +       return sprintf(buf, "%d\n", pm_userspace_autosleeper_enabled);
> > 
> > This should use sysfs_emit no?
> 
> Probably, yea. Note that I just copy and pasted a nearby function,
> pm_async_show, `:%s/`d the variable name, and then promptly `git diff |
> clip`d it and plonked it into my email. Looking at the file, it uses
> sprintf all over the place in this fashion. So you may want to submit a
> cleanup to Rafael on this if you're right about sysfs_emit() being
> universally preferred.

Perhaps:

(trivial refactored and added a missing newline in autosleep_show)

---
 kernel/power/main.c | 102 ++++++++++++++++++++++++++--------------------------
 1 file changed, 52 insertions(+), 50 deletions(-)

diff --git a/kernel/power/main.c b/kernel/power/main.c
index e3694034b7536..c8a030319b15c 100644
--- a/kernel/power/main.c
+++ b/kernel/power/main.c
@@ -100,7 +100,7 @@ int pm_async_enabled = 1;
 static ssize_t pm_async_show(struct kobject *kobj, struct kobj_attribute *attr,
 			     char *buf)
 {
-	return sprintf(buf, "%d\n", pm_async_enabled);
+	return sysfs_emit(buf, "%d\n", pm_async_enabled);
 }
 
 static ssize_t pm_async_store(struct kobject *kobj, struct kobj_attribute *attr,
@@ -124,27 +124,25 @@ power_attr(pm_async);
 static ssize_t mem_sleep_show(struct kobject *kobj, struct kobj_attribute *attr,
 			      char *buf)
 {
-	char *s = buf;
+	int len = 0;
 	suspend_state_t i;
 
 	for (i = PM_SUSPEND_MIN; i < PM_SUSPEND_MAX; i++) {
 		if (i >= PM_SUSPEND_MEM && cxl_mem_active())
 			continue;
-		if (mem_sleep_states[i]) {
-			const char *label = mem_sleep_states[i];
+		if (!mem_sleep_states[i])
+			continue;
 
-			if (mem_sleep_current == i)
-				s += sprintf(s, "[%s] ", label);
-			else
-				s += sprintf(s, "%s ", label);
-		}
+		len += sysfs_emit_at(buf, len,
+				     mem_sleep_current == i ? "[%s] " : "%s ",
+				     mem_sleep_states[i]);
 	}
 
-	/* Convert the last space to a newline if needed. */
-	if (s != buf)
-		*(s-1) = '\n';
+	/* Convert the last space to a newline if needed */
+	if (len)
+		sysfs_emit_at(buf, len - 1, "\n");
 
-	return (s - buf);
+	return len;
 }
 
 static suspend_state_t decode_suspend_state(const char *buf, size_t n)
@@ -205,7 +203,7 @@ bool sync_on_suspend_enabled = !IS_ENABLED(CONFIG_SUSPEND_SKIP_SYNC);
 static ssize_t sync_on_suspend_show(struct kobject *kobj,
 				   struct kobj_attribute *attr, char *buf)
 {
-	return sprintf(buf, "%d\n", sync_on_suspend_enabled);
+	return sysfs_emit(buf, "%d\n", sync_on_suspend_enabled);
 }
 
 static ssize_t sync_on_suspend_store(struct kobject *kobj,
@@ -242,22 +240,22 @@ static const char * const pm_tests[__TEST_AFTER_LAST] = {
 static ssize_t pm_test_show(struct kobject *kobj, struct kobj_attribute *attr,
 				char *buf)
 {
-	char *s = buf;
+	int len = 0;
 	int level;
 
-	for (level = TEST_FIRST; level <= TEST_MAX; level++)
-		if (pm_tests[level]) {
-			if (level == pm_test_level)
-				s += sprintf(s, "[%s] ", pm_tests[level]);
-			else
-				s += sprintf(s, "%s ", pm_tests[level]);
-		}
+	for (level = TEST_FIRST; level <= TEST_MAX; level++) {
+		if (!pm_tests[level])
+			continue;
+		len += sysfs_emit_at(buf, len,
+				     level == pm_test_level ? "[%s] " : "%s ",
+				     pm_tests[level]);
+	}
 
-	if (s != buf)
-		/* convert the last space to a newline */
-		*(s-1) = '\n';
+	/* convert the last space to a newline if needed */
+	if (len)
+		sysfs_emit_at(buf, len - 1, "\n");
 
-	return (s - buf);
+	return len;
 }
 
 static ssize_t pm_test_store(struct kobject *kobj, struct kobj_attribute *attr,
@@ -314,7 +312,7 @@ static char *suspend_step_name(enum suspend_stat_step step)
 static ssize_t _name##_show(struct kobject *kobj,		\
 		struct kobj_attribute *attr, char *buf)		\
 {								\
-	return sprintf(buf, "%d\n", suspend_stats._name);	\
+	return sysfs_emit(buf, "%d\n", suspend_stats._name);	\
 }								\
 static struct kobj_attribute _name = __ATTR_RO(_name)
 
@@ -339,7 +337,7 @@ static ssize_t last_failed_dev_show(struct kobject *kobj,
 	index %= REC_FAILED_NUM;
 	last_failed_dev = suspend_stats.failed_devs[index];
 
-	return sprintf(buf, "%s\n", last_failed_dev);
+	return sysfs_emit(buf, "%s\n", last_failed_dev);
 }
 static struct kobj_attribute last_failed_dev = __ATTR_RO(last_failed_dev);
 
@@ -353,7 +351,7 @@ static ssize_t last_failed_errno_show(struct kobject *kobj,
 	index %= REC_FAILED_NUM;
 	last_failed_errno = suspend_stats.errno[index];
 
-	return sprintf(buf, "%d\n", last_failed_errno);
+	return sysfs_emit(buf, "%d\n", last_failed_errno);
 }
 static struct kobj_attribute last_failed_errno = __ATTR_RO(last_failed_errno);
 
@@ -369,7 +367,7 @@ static ssize_t last_failed_step_show(struct kobject *kobj,
 	step = suspend_stats.failed_steps[index];
 	last_failed_step = suspend_step_name(step);
 
-	return sprintf(buf, "%s\n", last_failed_step);
+	return sysfs_emit(buf, "%s\n", last_failed_step);
 }
 static struct kobj_attribute last_failed_step = __ATTR_RO(last_failed_step);
 
@@ -477,7 +475,7 @@ bool pm_print_times_enabled;
 static ssize_t pm_print_times_show(struct kobject *kobj,
 				   struct kobj_attribute *attr, char *buf)
 {
-	return sprintf(buf, "%d\n", pm_print_times_enabled);
+	return sysfs_emit(buf, "%d\n", pm_print_times_enabled);
 }
 
 static ssize_t pm_print_times_store(struct kobject *kobj,
@@ -510,7 +508,7 @@ static ssize_t pm_wakeup_irq_show(struct kobject *kobj,
 	if (!pm_wakeup_irq())
 		return -ENODATA;
 
-	return sprintf(buf, "%u\n", pm_wakeup_irq());
+	return sysfs_emit(buf, "%u\n", pm_wakeup_irq());
 }
 
 power_attr_ro(pm_wakeup_irq);
@@ -520,7 +518,7 @@ bool pm_debug_messages_on __read_mostly;
 static ssize_t pm_debug_messages_show(struct kobject *kobj,
 				      struct kobj_attribute *attr, char *buf)
 {
-	return sprintf(buf, "%d\n", pm_debug_messages_on);
+	return sysfs_emit(buf, "%d\n", pm_debug_messages_on);
 }
 
 static ssize_t pm_debug_messages_store(struct kobject *kobj,
@@ -568,21 +566,24 @@ struct kobject *power_kobj;
 static ssize_t state_show(struct kobject *kobj, struct kobj_attribute *attr,
 			  char *buf)
 {
-	char *s = buf;
+	int len = 0;
 #ifdef CONFIG_SUSPEND
 	suspend_state_t i;
 
-	for (i = PM_SUSPEND_MIN; i < PM_SUSPEND_MAX; i++)
+	for (i = PM_SUSPEND_MIN; i < PM_SUSPEND_MAX; i++) {
 		if (pm_states[i])
-			s += sprintf(s,"%s ", pm_states[i]);
+			len += sysfs_emit_at(buf, len, "%s ", pm_states[i]);
+	}
 
 #endif
 	if (hibernation_available())
-		s += sprintf(s, "disk ");
-	if (s != buf)
-		/* convert the last space to a newline */
-		*(s-1) = '\n';
-	return (s - buf);
+		len += sysfs_emit_at(buf, len, "disk ");
+
+	/* convert the last space to a newline if needed */
+	if (len)
+		sysfs_emit_at(buf, len - 1, "\n");
+
+	return len;
 }
 
 static suspend_state_t decode_state(const char *buf, size_t n)
@@ -681,8 +682,10 @@ static ssize_t wakeup_count_show(struct kobject *kobj,
 {
 	unsigned int val;
 
-	return pm_get_wakeup_count(&val, true) ?
-		sprintf(buf, "%u\n", val) : -EINTR;
+	if (!pm_get_wakeup_count(&val, true))
+		return -EINTR;
+
+	return sysfs_emit(buf, "%u\n", val);
 }
 
 static ssize_t wakeup_count_store(struct kobject *kobj,
@@ -724,17 +727,16 @@ static ssize_t autosleep_show(struct kobject *kobj,
 	suspend_state_t state = pm_autosleep_state();
 
 	if (state == PM_SUSPEND_ON)
-		return sprintf(buf, "off\n");
+		return sysfs_emit(buf, "off\n");
 
 #ifdef CONFIG_SUSPEND
 	if (state < PM_SUSPEND_MAX)
-		return sprintf(buf, "%s\n", pm_states[state] ?
-					pm_states[state] : "error");
+		return sysfs_emit(buf, "%s\n", pm_states[state] ?: "error");
 #endif
 #ifdef CONFIG_HIBERNATION
-	return sprintf(buf, "disk\n");
+	return sysfs_emit(buf, "disk\n");
 #else
-	return sprintf(buf, "error");
+	return sysfs_emit(buf, "error\n");
 #endif
 }
 
@@ -803,7 +805,7 @@ int pm_trace_enabled;
 static ssize_t pm_trace_show(struct kobject *kobj, struct kobj_attribute *attr,
 			     char *buf)
 {
-	return sprintf(buf, "%d\n", pm_trace_enabled);
+	return sysfs_emit(buf, "%d\n", pm_trace_enabled);
 }
 
 static ssize_t
@@ -840,7 +842,7 @@ power_attr_ro(pm_trace_dev_match);
 static ssize_t pm_freeze_timeout_show(struct kobject *kobj,
 				      struct kobj_attribute *attr, char *buf)
 {
-	return sprintf(buf, "%u\n", freeze_timeout_msecs);
+	return sysfs_emit(buf, "%u\n", freeze_timeout_msecs);
 }
 
 static ssize_t pm_freeze_timeout_store(struct kobject *kobj,


From Jason at zx2c4.com  Thu Jun 30 03:02:19 2022
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Thu, 30 Jun 2022 05:02:19 +0200
Subject: [PATCH] remove CONFIG_ANDROID
In-Reply-To: <1a1f24707a03c2363e29ef91905e9f206fb6a0b5.camel@perches.com>
References: <Yrx/8UOY+J8Ao3Bd@zx2c4.com> <YryNQvWGVwCjJYmB@zx2c4.com>
 <Yryic4YG9X2/DJiX@google.com> <Yry6XvOGge2xKx/n@zx2c4.com>
 <CAC_TJve_Jk0+XD7VeSJVvJq4D9ZofnH69B4QZv2LPT4X3KNfeg@mail.gmail.com>
 <YrzaCRl9rwy9DgOC@zx2c4.com>
 <CAC_TJvcEzp+zQp50wtj4=7b6vEObpJCQYLaTLhHJCxFdk3TgPg@mail.gmail.com>
 <306dacfb29c2e38312943fa70d419f0a8d5ffe82.camel@perches.com>
 <YrzzWmQ9+uDRlO5K@zx2c4.com>
 <1a1f24707a03c2363e29ef91905e9f206fb6a0b5.camel@perches.com>
Message-ID: <Yr0SO0Ubi3Js7ciP@zx2c4.com>

On Wed, Jun 29, 2022 at 06:44:14PM -0700, Joe Perches wrote:
> On Thu, 2022-06-30 at 02:50 +0200, Jason A. Donenfeld wrote:
> > On Wed, Jun 29, 2022 at 05:36:57PM -0700, Joe Perches wrote:
> > > > > +static ssize_t pm_userspace_autosleeper_show(struct kobject *kobj,
> > > > > +                               struct kobj_attribute *attr, char *buf)
> > > > > +{
> > > > > +       return sprintf(buf, "%d\n", pm_userspace_autosleeper_enabled);
> > > 
> > > This should use sysfs_emit no?
> > 
> > Probably, yea. Note that I just copy and pasted a nearby function,
> > pm_async_show, `:%s/`d the variable name, and then promptly `git diff |
> > clip`d it and plonked it into my email. Looking at the file, it uses
> > sprintf all over the place in this fashion. So you may want to submit a
> > cleanup to Rafael on this if you're right about sysfs_emit() being
> > universally preferred.
> 
> Perhaps:
> 
> (trivial refactored and added a missing newline in autosleep_show)
> 
> ---
>  kernel/power/main.c | 102 ++++++++++++++++++++++++++--------------------------
>  1 file changed, 52 insertions(+), 50 deletions(-)

You should probably post a proper patch to the PM people. At least I'm
not going to look at that here, as it's not really relevant at all to
this discussion.

Jason

From kaleshsingh at google.com  Thu Jun 30 04:25:32 2022
From: kaleshsingh at google.com (Kalesh Singh)
Date: Wed, 29 Jun 2022 21:25:32 -0700
Subject: [PATCH] remove CONFIG_ANDROID
In-Reply-To: <YrzujZuJyfymC0LP@zx2c4.com>
References: <Yrx8/Fyx15CTi2zq@zx2c4.com> <20220629163007.GA25279@lst.de>
 <Yrx/8UOY+J8Ao3Bd@zx2c4.com> <YryNQvWGVwCjJYmB@zx2c4.com>
 <Yryic4YG9X2/DJiX@google.com> <Yry6XvOGge2xKx/n@zx2c4.com>
 <CAC_TJve_Jk0+XD7VeSJVvJq4D9ZofnH69B4QZv2LPT4X3KNfeg@mail.gmail.com>
 <YrzaCRl9rwy9DgOC@zx2c4.com>
 <CANDhNCpRzzULaGmEGCbbJgVinA0pJJB-gOP9AY0Hy488n9ZStA@mail.gmail.com>
 <YrztOqBBll66C2/n@zx2c4.com> <YrzujZuJyfymC0LP@zx2c4.com>
Message-ID: <CAC_TJvcNOx1C5csdkMCAPVmX4gLcRWkxKO8Vm=isgjgM-MowwA@mail.gmail.com>

On Wed, Jun 29, 2022 at 5:30 PM Jason A. Donenfeld <Jason at zx2c4.com> wrote:
>
> Hey again,
>
> On Thu, Jun 30, 2022 at 2:24 AM Jason A. Donenfeld <Jason at zx2c4.com> wrote:
> > 1) Introduce a simple CONFIG_PM_CONTINUOUS_AUTOSLEEPING Kconfig thing
> >    with lots of discouraging help text.
> >
> > 2) Go with the /sys/power tunable and bikeshed the naming of that a bit
> >    to get it to something that reflects this better, and document it as
> >    being undesirable except for Android phones.
>
> One other quick thought, which I had mentioned earlier to Kalesh:
>
> 3) Make the semantics a process holding open a file descriptor, rather
>    than writing 0/1 into a file. It'd be called /sys/power/
>    userspace_autosleep_ctrl, or something, and it'd enable this behavior
>    while it's opened. And maybe down the line somebody will want to add
>    ioctls to it for a different purpose. This way it's less of a tunable
>    and more of an indication that there's a userspace app doing/controlling
>    something.
>
> This idea (3) may be a lot of added complexity for basically nothing,
> but it might fit the usage semantics concerns a bit better than (2). But
> anyway, just an idea. Any one of those three are fine with me.

Two concerns John raised:
  1) Adding new ABI we need to maintain
  2) Having unclear config options

Another idea, I think, is to add the Kconfig option as
CONFIG_SUSPEND_SKIP_RNG_RESEED? Similar to existing
CONFIG_SUSPEND_SKIP_SYNC and I think it would address those concerns.

--Kalesh

> Jason

From peljasz at yahoo.co.uk  Thu Jun 30 06:53:28 2022
From: peljasz at yahoo.co.uk (lejeczek)
Date: Thu, 30 Jun 2022 07:53:28 +0100
Subject: package from fedorainfracloud for centOS 8 does not build
In-Reply-To: <CAHmME9o5Qpg_oHjWFBa6zoVZd4ALOpBnjj7Y-y_ipgtZ4+o_qQ@mail.gmail.com>
References: <b05c9019-5165-84f0-b3f1-a0eeb30faad1.ref@yahoo.co.uk>
 <b05c9019-5165-84f0-b3f1-a0eeb30faad1@yahoo.co.uk>
 <CAHmME9o5Qpg_oHjWFBa6zoVZd4ALOpBnjj7Y-y_ipgtZ4+o_qQ@mail.gmail.com>
Message-ID: <c1ecbad3-8b01-6caa-8fb0-68b59ef62fc5@yahoo.co.uk>



On 29/06/2022 13:27, Jason A. Donenfeld wrote:
> On Wed, Jun 29, 2022 at 2:17 PM lejeczek <peljasz at yahoo.co.uk> wrote:
>> Hi guys.
>>
>> In case somebody here looks after
>> 'copr:copr.fedorainfracloud.org:jdoss:wireguard' then
>>
>> wireguard-dkms-1.0.20220627-1.el8.noarch for 4.18.0-394.el8.x86_64 fails
>> to build
>>
>> many thanks, L.
> https://lists.zx2c4.com/pipermail/wireguard/2022-June/007664.html
is there a reason for which you do not keep multiple 
versions in the repo - so to "downgrade" people would have 
as an option?
thanks, L.

From Jason at zx2c4.com  Thu Jun 30 10:05:50 2022
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Thu, 30 Jun 2022 12:05:50 +0200
Subject: [PATCH] remove CONFIG_ANDROID
In-Reply-To: <CAC_TJvcNOx1C5csdkMCAPVmX4gLcRWkxKO8Vm=isgjgM-MowwA@mail.gmail.com>
References: <Yrx/8UOY+J8Ao3Bd@zx2c4.com> <YryNQvWGVwCjJYmB@zx2c4.com>
 <Yryic4YG9X2/DJiX@google.com> <Yry6XvOGge2xKx/n@zx2c4.com>
 <CAC_TJve_Jk0+XD7VeSJVvJq4D9ZofnH69B4QZv2LPT4X3KNfeg@mail.gmail.com>
 <YrzaCRl9rwy9DgOC@zx2c4.com>
 <CANDhNCpRzzULaGmEGCbbJgVinA0pJJB-gOP9AY0Hy488n9ZStA@mail.gmail.com>
 <YrztOqBBll66C2/n@zx2c4.com> <YrzujZuJyfymC0LP@zx2c4.com>
 <CAC_TJvcNOx1C5csdkMCAPVmX4gLcRWkxKO8Vm=isgjgM-MowwA@mail.gmail.com>
Message-ID: <Yr11fp13yMRiEphS@zx2c4.com>

Hi Kalesh,

On Wed, Jun 29, 2022 at 09:25:32PM -0700, Kalesh Singh wrote:
> On Wed, Jun 29, 2022 at 5:30 PM Jason A. Donenfeld <Jason at zx2c4.com> wrote:
> >
> > Hey again,
> >
> > On Thu, Jun 30, 2022 at 2:24 AM Jason A. Donenfeld <Jason at zx2c4.com> wrote:
> > > 1) Introduce a simple CONFIG_PM_CONTINUOUS_AUTOSLEEPING Kconfig thing
> > >    with lots of discouraging help text.
> > >
> > > 2) Go with the /sys/power tunable and bikeshed the naming of that a bit
> > >    to get it to something that reflects this better, and document it as
> > >    being undesirable except for Android phones.
> >
> > One other quick thought, which I had mentioned earlier to Kalesh:
> >
> > 3) Make the semantics a process holding open a file descriptor, rather
> >    than writing 0/1 into a file. It'd be called /sys/power/
> >    userspace_autosleep_ctrl, or something, and it'd enable this behavior
> >    while it's opened. And maybe down the line somebody will want to add
> >    ioctls to it for a different purpose. This way it's less of a tunable
> >    and more of an indication that there's a userspace app doing/controlling
> >    something.
> >
> > This idea (3) may be a lot of added complexity for basically nothing,
> > but it might fit the usage semantics concerns a bit better than (2). But
> > anyway, just an idea. Any one of those three are fine with me.
> 
> Two concerns John raised:
>   1) Adding new ABI we need to maintain
>   2) Having unclear config options
> 
> Another idea, I think, is to add the Kconfig option as
> CONFIG_SUSPEND_SKIP_RNG_RESEED? Similar to existing
> CONFIG_SUSPEND_SKIP_SYNC and I think it would address those concerns.

I mentioned in my reply to him that this doesn't really work for me:

| As a general rule, I don't expose knobs like that in wireguard /itself/,
| but wireguard has no problem with adapting to whatever machine properties
| it finds itself on. And besides, this *is* a very definite device
| property, something really particular and peculiar about the machine
| the kernel is running on. It's a concrete thing that the kernel should
| know about. So let's go with your "very clear description idea", above,
| instead.

IOW, we're not going to add a tunable on every possible place this is
used.

Anyway if you don't want a runtime switch, make a compiletime switch
called CONFIG_PM_CONTINUOUS_RAPID_AUTOSLEEPING or whatever, write some
very discouraging help text, and call it a day. And this way you don't
have to worry about ABI and we can change this later on and do the whole
thing as a no-big-deal change that somebody can tweak later without
issue.

The below diff is some boiler plate to help you get started with that
direction. Similar order of operations for this one:

1. You write a patch for Android's base config to enable this option and
   post it on Gerrit.

2. You take the diff below, clean it up or bikeshed the naming a bit or
   do whatever there, and submit it to the kernel, including as a `Link:
   ...` this thread and the Gerrit link.

3. When the patch lands, you submit the Gerrit CL.

4. When both have landed, Christoph moves forward with his
   CONFIG_ANDROID removal.

So really, just pick an option here -- the runtime switch or the
compiletime switch or the crazy fd thing I mentioned -- and run with it.

Jason

diff --git a/drivers/char/random.c b/drivers/char/random.c
index e3dd1dd3dd22..5332236cb1ad 100644
--- a/drivers/char/random.c
+++ b/drivers/char/random.c
@@ -756,7 +756,7 @@ static int random_pm_notification(struct notifier_block *nb, unsigned long actio

 	if (crng_ready() && (action == PM_RESTORE_PREPARE ||
 	    (action == PM_POST_SUSPEND &&
-	     !IS_ENABLED(CONFIG_PM_AUTOSLEEP) && !IS_ENABLED(CONFIG_ANDROID)))) {
+	     !IS_ENABLED(CONFIG_PM_AUTOSLEEP) && !IS_ENABLED(CONFIG_PM_RAPID_USERSPACE_AUTOSLEEP)))) {
 		crng_reseed();
 		pr_notice("crng reseeded on system resumption\n");
 	}
diff --git a/drivers/net/wireguard/device.c b/drivers/net/wireguard/device.c
index aa9a7a5970fd..b93171f2e6c9 100644
--- a/drivers/net/wireguard/device.c
+++ b/drivers/net/wireguard/device.c
@@ -69,7 +69,7 @@ static int wg_pm_notification(struct notifier_block *nb, unsigned long action, v
 	 * its normal operation rather than as a somewhat rare event, then we
 	 * don't actually want to clear keys.
 	 */
-	if (IS_ENABLED(CONFIG_PM_AUTOSLEEP) || IS_ENABLED(CONFIG_ANDROID))
+	if (IS_ENABLED(CONFIG_PM_AUTOSLEEP) || IS_ENABLED(CONFIG_PM_RAPID_USERSPACE_AUTOSLEEP))
 		return 0;

 	if (action != PM_HIBERNATION_PREPARE && action != PM_SUSPEND_PREPARE)
diff --git a/kernel/power/Kconfig b/kernel/power/Kconfig
index a12779650f15..bcbfbeb39d4f 100644
--- a/kernel/power/Kconfig
+++ b/kernel/power/Kconfig
@@ -150,6 +150,25 @@ config PM_WAKELOCKS
 	Allow user space to create, activate and deactivate wakeup source
 	objects with the help of a sysfs-based interface.

+config PM_RAPID_USERSPACE_AUTOSLEEP
+	bool "Tune for rapid and consistent userspace calls to sleep"
+	depends on PM_SLEEP
+	help
+	Change the behavior of various sleep-sensitive code to deal with
+	userspace autosuspend daemons that put the machine to sleep and wake it
+	up extremely often and for short periods of time.
+
+	This option mostly disables code paths that most users really should
+	keep enabled. In particular, only enable this if:
+
+	- It is very common to be asleep for only 2 seconds before being woken;	and
+	- It is very common to be awake for only 2 seconds before sleeping.
+
+	This likely only applies to Android devices, and not other machines.
+	Therefore, you should say N here, unless you're extremely certain that
+	this is what you want. The option otherwise has bad, undesirable
+	effects, and should not be enabled just for fun.
+
 config PM_WAKELOCKS_LIMIT
 	int "Maximum number of user space wakeup sources (0 = no limit)"
 	range 0 100000


From tlhackque at yahoo.com  Thu Jun 30 10:47:38 2022
From: tlhackque at yahoo.com (tlhackque)
Date: Thu, 30 Jun 2022 06:47:38 -0400
Subject: CONFIG_ANDROID
References: <23929467-11c2-cdf2-3841-2a837ba58b51.ref@yahoo.com>
Message-ID: <23929467-11c2-cdf2-3841-2a837ba58b51@yahoo.com>

FWIW: Having watched the discussion about CONFIG_ANDROID, it occurs to 
me that there's an alternative for WireGuard that sidesteps the issue.

 From the last patcheset, it seems that the only use in WireGuard is to 
avoid clearing keys on every wake-up.

So: Why not timestamp key-clear events, and establish a minimum interval?

It seems to me that this would make WireGuard tolerant of the peculiar 
behavior of the Android (handheld) platforms, and expresses what 
WireGuard needs - a minimum time between key clearing events.? It's also 
completely under WireGuard's control, is platform agnostic, and avoids 
an inevitable discussion about whether 2 seconds between wakeups is 
immutable and satisfies everyone.? (If you wait long enough, every 
constant eventually becomes a variable...)

Then WireGuard can watch the duststorm over CONFIG_ANDROID's fate settle 
out at leisure.

I have no dog in this fight - just an observer.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <http://lists.zx2c4.com/pipermail/wireguard/attachments/20220630/ea3764e4/attachment.sig>

From Jason at zx2c4.com  Thu Jun 30 11:41:43 2022
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Thu, 30 Jun 2022 13:41:43 +0200
Subject: CONFIG_ANDROID
In-Reply-To: <23929467-11c2-cdf2-3841-2a837ba58b51@yahoo.com>
References: <23929467-11c2-cdf2-3841-2a837ba58b51.ref@yahoo.com>
 <23929467-11c2-cdf2-3841-2a837ba58b51@yahoo.com>
Message-ID: <Yr2L9759Ek63KV1F@zx2c4.com>

On Thu, Jun 30, 2022 at 06:47:38AM -0400, tlhackque wrote:
> FWIW: Having watched the discussion about CONFIG_ANDROID, it occurs to 
> me that there's an alternative for WireGuard that sidesteps the issue.
> 
>  From the last patcheset, it seems that the only use in WireGuard is to 
> avoid clearing keys on every wake-up.

No, it clears keys before sleeping.

> 
> So: Why not timestamp key-clear events, and establish a minimum interval?

Because we don't know when we're going to wake up again, and the
objective is to maintain forward secrecy.

Jason

From tlhackque at yahoo.com  Thu Jun 30 15:50:59 2022
From: tlhackque at yahoo.com (tlhackque)
Date: Thu, 30 Jun 2022 11:50:59 -0400
Subject: CONFIG_ANDROID
In-Reply-To: <Yr2L9759Ek63KV1F@zx2c4.com>
References: <23929467-11c2-cdf2-3841-2a837ba58b51.ref@yahoo.com>
 <23929467-11c2-cdf2-3841-2a837ba58b51@yahoo.com> <Yr2L9759Ek63KV1F@zx2c4.com>
Message-ID: <dd586079-c81b-4715-e818-4cf7f0ddf4d8@yahoo.com>

On 30-Jun-22 07:41, Jason A. Donenfeld wrote:
> On Thu, Jun 30, 2022 at 06:47:38AM -0400, tlhackque wrote:
>> FWIW: Having watched the discussion about CONFIG_ANDROID, it occurs to
>> me that there's an alternative for WireGuard that sidesteps the issue.
>>
>>   From the last patcheset, it seems that the only use in WireGuard is to
>> avoid clearing keys on every wake-up.
> No, it clears keys before sleeping.
>
>> So: Why not timestamp key-clear events, and establish a minimum interval?
> Because we don't know when we're going to wake up again, and the
> objective is to maintain forward secrecy.
>
> Jason

Thanks for the explanation.? One more attempt.

If I understand what's happening:

You're really trying to establish a maximum key lifetime - sleep being a 
proxy for "too long to keep using".? On conventional platforms, that's 
been good enough.? On these Android platforms, it's not.

You're clearing the key before sleeping so that after a presumably 
longish time, you'll negotiate a new one.? But on some platforms, the 
sleeps are so frequent that "longish" is inconveniently short.? And the 
renegotiations are expensive.? On those platforms, you don't clear the 
key to avoid the frequent renegotiations.? This keeps the old key in use 
across the sleeps.

Alternatively, why not make the maximum key lifetime explicit.? E.g. On 
all platforms you could set a renegotiate time when a key is 
established, and if it has expired on wake (or on use) trigger 
renegotiation.? This guarantees a maximum key lifetime, independent of 
the frequency or duration of sleeps.? And you don't need to know when 
you'll wake.

If you also want to make sure that the key isn't in memory longer than 
that time (e.g. to avoid capture on a dump or device loss), you could 
also set a timer (of the sort that wakes the CPU from sleep) that clears 
the key at that time.

There are obvious optimizations if necessary.

The point I'm trying to make is that rather than thinking about the 
annoying platform behavior's effect on the implementation, it's probably 
better to think about what WireGuard is really trying to do and express 
it in the implementation.

I hope this perspective helps.? I'll step out of your way now.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <http://lists.zx2c4.com/pipermail/wireguard/attachments/20220630/f3bf8d73/attachment.sig>

From Jason at zx2c4.com  Thu Jun 30 15:56:37 2022
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Thu, 30 Jun 2022 17:56:37 +0200
Subject: CONFIG_ANDROID
In-Reply-To: <dd586079-c81b-4715-e818-4cf7f0ddf4d8@yahoo.com>
References: <23929467-11c2-cdf2-3841-2a837ba58b51.ref@yahoo.com>
 <23929467-11c2-cdf2-3841-2a837ba58b51@yahoo.com> <Yr2L9759Ek63KV1F@zx2c4.com>
 <dd586079-c81b-4715-e818-4cf7f0ddf4d8@yahoo.com>
Message-ID: <CAHmME9p2OYSTX2C5M0faKtw2N8jiyohvRqnAPKa=e7BWynF7fQ@mail.gmail.com>

On Thu, Jun 30, 2022 at 5:53 PM tlhackque <tlhackque at yahoo.com> wrote:
> If you also want to make sure that the key isn't in memory longer than
> that time (e.g. to avoid capture on a dump or device loss), you could
> also set a timer (of the sort that wakes the CPU from sleep) that clears
> the key at that time.

Waking up the CPU some time later to clear a key sounds like a bad
waste of power. And such wakeup timers aren't universally available
and dependable. Plus, the last thing people want is having WireGuard
wake up your laptop from sleep while it's in your bag. You're now
proposing all sorts of terrible complexity, instead of the much more
simple and covers-all-real-practical-cases of "is it android or is it
not?" KISS.

Jason

From jstultz at google.com  Thu Jun 30 17:12:30 2022
From: jstultz at google.com (John Stultz)
Date: Thu, 30 Jun 2022 10:12:30 -0700
Subject: [PATCH] remove CONFIG_ANDROID
In-Reply-To: <Yr11fp13yMRiEphS@zx2c4.com>
References: <Yrx/8UOY+J8Ao3Bd@zx2c4.com> <YryNQvWGVwCjJYmB@zx2c4.com>
 <Yryic4YG9X2/DJiX@google.com> <Yry6XvOGge2xKx/n@zx2c4.com>
 <CAC_TJve_Jk0+XD7VeSJVvJq4D9ZofnH69B4QZv2LPT4X3KNfeg@mail.gmail.com>
 <YrzaCRl9rwy9DgOC@zx2c4.com>
 <CANDhNCpRzzULaGmEGCbbJgVinA0pJJB-gOP9AY0Hy488n9ZStA@mail.gmail.com>
 <YrztOqBBll66C2/n@zx2c4.com> <YrzujZuJyfymC0LP@zx2c4.com>
 <CAC_TJvcNOx1C5csdkMCAPVmX4gLcRWkxKO8Vm=isgjgM-MowwA@mail.gmail.com>
 <Yr11fp13yMRiEphS@zx2c4.com>
Message-ID: <CANDhNCrcEBUUNevNyZp2qttqWssWBEcXMZ5nPO0Ntk7Vszd3bQ@mail.gmail.com>

On Thu, Jun 30, 2022 at 3:06 AM Jason A. Donenfeld <Jason at zx2c4.com> wrote:
> On Wed, Jun 29, 2022 at 09:25:32PM -0700, Kalesh Singh wrote:
> > Two concerns John raised:
> >   1) Adding new ABI we need to maintain
> >   2) Having unclear config options
> >
> > Another idea, I think, is to add the Kconfig option as
> > CONFIG_SUSPEND_SKIP_RNG_RESEED? Similar to existing
> > CONFIG_SUSPEND_SKIP_SYNC and I think it would address those concerns.
>
> I mentioned in my reply to him that this doesn't really work for me:
>
> | As a general rule, I don't expose knobs like that in wireguard /itself/,
> | but wireguard has no problem with adapting to whatever machine properties
> | it finds itself on. And besides, this *is* a very definite device
> | property, something really particular and peculiar about the machine
> | the kernel is running on. It's a concrete thing that the kernel should
> | know about. So let's go with your "very clear description idea", above,
> | instead.
>
> IOW, we're not going to add a tunable on every possible place this is
> used.

Hrm. Can you explain a bit more on why you're particularly adamant
against scoping the config to describe the behavior we want from the
kernel rather than describing a "machine property"?  As personally, I
greatly prefer Kalesh's suggestion (as it avoids the same critique one
could make of the CONFIG_ANDROID "flag"), but admittedly this is
bikeshed territory.

Does this preference come out of the too-many-options-in-gpg
antipattern? Or is there something else?


> Anyway if you don't want a runtime switch, make a compiletime switch
> called CONFIG_PM_CONTINUOUS_RAPID_AUTOSLEEPING or whatever, write some
> very discouraging help text, and call it a day. And this way you don't
> have to worry about ABI and we can change this later on and do the whole
> thing as a no-big-deal change that somebody can tweak later without
> issue.

Yeah, this is ok with me, as I don't see much benefit to creating a
userland ABI, as I don't think at this point we expect the behavior to
shift or oscillate at runtime.

thanks
-john

From Jason at zx2c4.com  Thu Jun 30 17:24:04 2022
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Thu, 30 Jun 2022 19:24:04 +0200
Subject: [PATCH] remove CONFIG_ANDROID
In-Reply-To: <CANDhNCrcEBUUNevNyZp2qttqWssWBEcXMZ5nPO0Ntk7Vszd3bQ@mail.gmail.com>
References: <Yryic4YG9X2/DJiX@google.com> <Yry6XvOGge2xKx/n@zx2c4.com>
 <CAC_TJve_Jk0+XD7VeSJVvJq4D9ZofnH69B4QZv2LPT4X3KNfeg@mail.gmail.com>
 <YrzaCRl9rwy9DgOC@zx2c4.com>
 <CANDhNCpRzzULaGmEGCbbJgVinA0pJJB-gOP9AY0Hy488n9ZStA@mail.gmail.com>
 <YrztOqBBll66C2/n@zx2c4.com> <YrzujZuJyfymC0LP@zx2c4.com>
 <CAC_TJvcNOx1C5csdkMCAPVmX4gLcRWkxKO8Vm=isgjgM-MowwA@mail.gmail.com>
 <Yr11fp13yMRiEphS@zx2c4.com>
 <CANDhNCrcEBUUNevNyZp2qttqWssWBEcXMZ5nPO0Ntk7Vszd3bQ@mail.gmail.com>
Message-ID: <Yr3cNF+A5xIRiiCQ@zx2c4.com>

Hi John,

On Thu, Jun 30, 2022 at 10:12:30AM -0700, John Stultz wrote:
> Does this preference come out of the too-many-options-in-gpg
> antipattern? Or is there something else?

There are numerous presentations and threads galore on why WireGuard
doesn't do knobs. Not worth rehashing here; it's not a bikeshed I really
want to have yet again, and I'd appreciate you respecting my time by not
going down that route. Sorry.

> > Anyway if you don't want a runtime switch, make a compiletime switch
> > called CONFIG_PM_CONTINUOUS_RAPID_AUTOSLEEPING or whatever, write some
> > very discouraging help text, and call it a day. And this way you don't
> > have to worry about ABI and we can change this later on and do the whole
> > thing as a no-big-deal change that somebody can tweak later without
> > issue.
> 
> Yeah, this is ok with me, as I don't see much benefit to creating a
> userland ABI, as I don't think at this point we expect the behavior to
> shift or oscillate at runtime.

Okay, fine by me. You have my sample patch for this. Feel free to CC me
on Gerrit and on the cleaned up patch and I'll offer my acks there.

No need to keep this mega thread going longer here. I'll keep my eyes
open for Gerrit notifications and such though.

Jason

From kaleshsingh at google.com  Thu Jun 30 19:12:29 2022
From: kaleshsingh at google.com (Kalesh Singh)
Date: Thu, 30 Jun 2022 19:12:29 +0000
Subject: [PATCH] pm/sleep: Add PM_USERSPACE_AUTOSLEEP Kconfig
Message-ID: <20220630191230.235306-1-kaleshsingh@google.com>

Systems that initiate frequent suspend/resume from userspace
can make the kernel aware by enabling PM_USERSPACE_AUTOSLEEP
config.

This allows for certain sleep-sensitive code (wireguard/rng) to
decide on what preparatory work should be performed (or not) in
their pm_notification callbacks.

This patch was prompted by the discussion at [1] which attempts
to remove CONFIG_ANDROID that currently guards these code paths.

[1] https://lore.kernel.org/r/20220629150102.1582425-1-hch at lst.de/

Suggested-by: Jason A. Donenfeld <Jason at zx2c4.com>
Signed-off-by: Kalesh Singh <kaleshsingh at google.com>
---
 drivers/char/random.c          |  4 ++--
 drivers/net/wireguard/device.c |  3 ++-
 kernel/power/Kconfig           | 20 ++++++++++++++++++++
 3 files changed, 24 insertions(+), 3 deletions(-)

diff --git a/drivers/char/random.c b/drivers/char/random.c
index e3dd1dd3dd22..8c90f535d149 100644
--- a/drivers/char/random.c
+++ b/drivers/char/random.c
@@ -755,8 +755,8 @@ static int random_pm_notification(struct notifier_block *nb, unsigned long actio
 	spin_unlock_irqrestore(&input_pool.lock, flags);
 
 	if (crng_ready() && (action == PM_RESTORE_PREPARE ||
-	    (action == PM_POST_SUSPEND &&
-	     !IS_ENABLED(CONFIG_PM_AUTOSLEEP) && !IS_ENABLED(CONFIG_ANDROID)))) {
+	    (action == PM_POST_SUSPEND && !IS_ENABLED(CONFIG_PM_AUTOSLEEP) &&
+	     !IS_ENABLED(CONFIG_PM_USERSPACE_AUTOSLEEP)))) {
 		crng_reseed();
 		pr_notice("crng reseeded on system resumption\n");
 	}
diff --git a/drivers/net/wireguard/device.c b/drivers/net/wireguard/device.c
index aa9a7a5970fd..d58e9f818d3b 100644
--- a/drivers/net/wireguard/device.c
+++ b/drivers/net/wireguard/device.c
@@ -69,7 +69,8 @@ static int wg_pm_notification(struct notifier_block *nb, unsigned long action, v
 	 * its normal operation rather than as a somewhat rare event, then we
 	 * don't actually want to clear keys.
 	 */
-	if (IS_ENABLED(CONFIG_PM_AUTOSLEEP) || IS_ENABLED(CONFIG_ANDROID))
+	if (IS_ENABLED(CONFIG_PM_AUTOSLEEP) ||
+	    IS_ENABLED(CONFIG_PM_USERSPACE_AUTOSLEEP))
 		return 0;
 
 	if (action != PM_HIBERNATION_PREPARE && action != PM_SUSPEND_PREPARE)
diff --git a/kernel/power/Kconfig b/kernel/power/Kconfig
index a12779650f15..60a1d3051cc7 100644
--- a/kernel/power/Kconfig
+++ b/kernel/power/Kconfig
@@ -143,6 +143,26 @@ config PM_AUTOSLEEP
 	Allow the kernel to trigger a system transition into a global sleep
 	state automatically whenever there are no active wakeup sources.
 
+config PM_USERSPACE_AUTOSLEEP
+	bool "Userspace opportunistic sleep"
+	depends on PM_SLEEP
+	help
+	Notify kernel of aggressive userspace autosleep power management policy.
+
+	This option changes the behavior of various sleep-sensitive code to deal
+	with frequent userspace-initiated transitions into a global sleep state.
+
+	Saying Y here, disables code paths that most users really should keep
+	enabled. In particular, only enable this if it is very common to be
+	asleep/awake for very short periods of time (<= 2 seconds).
+
+	Only platforms, such as Android, that implement opportunistic sleep from
+	a userspace power manager service should enable this option; and not
+	other machines. Therefore, you should say N here, unless you are
+	extremely certain that this is what you want. The option otherwise has
+	bad, undesirable effects, and should not be enabled just for fun.
+
+
 config PM_WAKELOCKS
 	bool "User space wakeup sources interface"
 	depends on PM_SLEEP

base-commit: 03c765b0e3b4cb5063276b086c76f7a612856a9a
-- 
2.37.0.rc0.161.g10f37bed90-goog


From Jason at zx2c4.com  Thu Jun 30 19:49:24 2022
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Thu, 30 Jun 2022 21:49:24 +0200
Subject: [PATCH] pm/sleep: Add PM_USERSPACE_AUTOSLEEP Kconfig
In-Reply-To: <20220630191230.235306-1-kaleshsingh@google.com>
References: <20220630191230.235306-1-kaleshsingh@google.com>
Message-ID: <Yr3+RLhpp3g9A7vb@zx2c4.com>

Hi Kalesh,

On Thu, Jun 30, 2022 at 07:12:29PM +0000, Kalesh Singh wrote:
> Systems that initiate frequent suspend/resume from userspace
> can make the kernel aware by enabling PM_USERSPACE_AUTOSLEEP
> config.
> 
> This allows for certain sleep-sensitive code (wireguard/rng) to
> decide on what preparatory work should be performed (or not) in
> their pm_notification callbacks.
> 
> This patch was prompted by the discussion at [1] which attempts
> to remove CONFIG_ANDROID that currently guards these code paths.
> 
> [1] https://lore.kernel.org/r/20220629150102.1582425-1-hch at lst.de/
> 
> Suggested-by: Jason A. Donenfeld <Jason at zx2c4.com>
> Signed-off-by: Kalesh Singh <kaleshsingh at google.com>

Thanks, looks good to me. Do you have a corresponding Gerrit link to the
change adding this to the base Android kernel config? If so, have my
Ack:

    Acked-by: Jason A. Donenfeld <Jason at zx2c4.com>

Jason

From kaleshsingh at google.com  Thu Jun 30 20:41:40 2022
From: kaleshsingh at google.com (Kalesh Singh)
Date: Thu, 30 Jun 2022 13:41:40 -0700
Subject: [PATCH] pm/sleep: Add PM_USERSPACE_AUTOSLEEP Kconfig
In-Reply-To: <Yr3+RLhpp3g9A7vb@zx2c4.com>
References: <20220630191230.235306-1-kaleshsingh@google.com>
 <Yr3+RLhpp3g9A7vb@zx2c4.com>
Message-ID: <CAC_TJvdV9bU2xWpbgrQuyrr6ens9gzDnZT2UzAY6Q6ZN9p7aEw@mail.gmail.com>

On Thu, Jun 30, 2022 at 12:49 PM Jason A. Donenfeld <Jason at zx2c4.com> wrote:
>
> Hi Kalesh,
>
> On Thu, Jun 30, 2022 at 07:12:29PM +0000, Kalesh Singh wrote:
> > Systems that initiate frequent suspend/resume from userspace
> > can make the kernel aware by enabling PM_USERSPACE_AUTOSLEEP
> > config.
> >
> > This allows for certain sleep-sensitive code (wireguard/rng) to
> > decide on what preparatory work should be performed (or not) in
> > their pm_notification callbacks.
> >
> > This patch was prompted by the discussion at [1] which attempts
> > to remove CONFIG_ANDROID that currently guards these code paths.
> >
> > [1] https://lore.kernel.org/r/20220629150102.1582425-1-hch at lst.de/
> >
> > Suggested-by: Jason A. Donenfeld <Jason at zx2c4.com>
> > Signed-off-by: Kalesh Singh <kaleshsingh at google.com>
>
> Thanks, looks good to me. Do you have a corresponding Gerrit link to the
> change adding this to the base Android kernel config? If so, have my
> Ack:
>
>     Acked-by: Jason A. Donenfeld <Jason at zx2c4.com>

Hi Jason,

Our latest supported kernels in Android are based on 5.15 so the
config change isn't yet needed. Once there are newer versions with the
CONFIG_ANDROID removed I will add this to the defconfig.

Thanks,
Kalesh

>
> Jason
>
> --
> To unsubscribe from this group and stop receiving emails from it, send an email to kernel-team+unsubscribe at android.com.
>

From Jason at zx2c4.com  Thu Jun 30 21:14:41 2022
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Thu, 30 Jun 2022 23:14:41 +0200
Subject: [PATCH] pm/sleep: Add PM_USERSPACE_AUTOSLEEP Kconfig
In-Reply-To: <CAC_TJvdV9bU2xWpbgrQuyrr6ens9gzDnZT2UzAY6Q6ZN9p7aEw@mail.gmail.com>
References: <20220630191230.235306-1-kaleshsingh@google.com>
 <Yr3+RLhpp3g9A7vb@zx2c4.com>
 <CAC_TJvdV9bU2xWpbgrQuyrr6ens9gzDnZT2UzAY6Q6ZN9p7aEw@mail.gmail.com>
Message-ID: <Yr4SQVjBCilyV1na@zx2c4.com>

On Thu, Jun 30, 2022 at 01:41:40PM -0700, Kalesh Singh wrote:
> Our latest supported kernels in Android are based on 5.15 so the
> config change isn't yet needed. Once there are newer versions with the
> CONFIG_ANDROID removed I will add this to the defconfig.

Okay. It might be still worth getting something uploaded to gerrit so
that it's easy to remember and submit whenever the time comes.

Also, what about android running on mainline? Where does that base
config live?

Jason

From kaleshsingh at google.com  Thu Jun 30 22:02:46 2022
From: kaleshsingh at google.com (Kalesh Singh)
Date: Thu, 30 Jun 2022 15:02:46 -0700
Subject: [PATCH] pm/sleep: Add PM_USERSPACE_AUTOSLEEP Kconfig
In-Reply-To: <Yr4SQVjBCilyV1na@zx2c4.com>
References: <20220630191230.235306-1-kaleshsingh@google.com>
 <Yr3+RLhpp3g9A7vb@zx2c4.com>
 <CAC_TJvdV9bU2xWpbgrQuyrr6ens9gzDnZT2UzAY6Q6ZN9p7aEw@mail.gmail.com>
 <Yr4SQVjBCilyV1na@zx2c4.com>
Message-ID: <CAC_TJvdZMr7KyUe7ro7jmFT1z5Gs3YbM9dhbL5Yp-weLvd0T3g@mail.gmail.com>

On Thu, Jun 30, 2022 at 2:14 PM Jason A. Donenfeld <Jason at zx2c4.com> wrote:
>
> On Thu, Jun 30, 2022 at 01:41:40PM -0700, Kalesh Singh wrote:
> > Our latest supported kernels in Android are based on 5.15 so the
> > config change isn't yet needed. Once there are newer versions with the
> > CONFIG_ANDROID removed I will add this to the defconfig.
>
> Okay. It might be still worth getting something uploaded to gerrit so
> that it's easy to remember and submit whenever the time comes.
>
> Also, what about android running on mainline? Where does that base
> config live?

I've uploaded the changes on android-mainline [1]. We'll submit there
once the upstream changes are finalized.

[1] https://android-review.googlesource.com/c/kernel/common/+/2142693/1

Thanks,
Kalesh
>
> Jason

From Jason at zx2c4.com  Thu Jun 30 22:08:16 2022
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Fri, 1 Jul 2022 00:08:16 +0200
Subject: [PATCH] pm/sleep: Add PM_USERSPACE_AUTOSLEEP Kconfig
In-Reply-To: <CAC_TJvdZMr7KyUe7ro7jmFT1z5Gs3YbM9dhbL5Yp-weLvd0T3g@mail.gmail.com>
References: <20220630191230.235306-1-kaleshsingh@google.com>
 <Yr3+RLhpp3g9A7vb@zx2c4.com>
 <CAC_TJvdV9bU2xWpbgrQuyrr6ens9gzDnZT2UzAY6Q6ZN9p7aEw@mail.gmail.com>
 <Yr4SQVjBCilyV1na@zx2c4.com>
 <CAC_TJvdZMr7KyUe7ro7jmFT1z5Gs3YbM9dhbL5Yp-weLvd0T3g@mail.gmail.com>
Message-ID: <Yr4e0FCo1l3Db4Gi@zx2c4.com>

Hi Kalesh,

On Thu, Jun 30, 2022 at 03:02:46PM -0700, Kalesh Singh wrote:
> I've uploaded the changes on android-mainline [1]. We'll submit there
> once the upstream changes are finalized.
> 
> [1] https://android-review.googlesource.com/c/kernel/common/+/2142693/1

Excellent. I think everything is all set then, at least from my
perspective. There's a viable replacement for this usage of
CONFIG_ANDROID, there are patches ready to go both in the kernel and on
Android's configs, and now all we do is wait for Rafael. Great!

Maybe people will have opinions on the naming
(CONFIG_PM_RAPID_USERSPACE_AUTOSLEEP vs
CONFIG_PM_ANDROID_USERAPCE_AUTO_SLEEP vs what you have vs something else
vs who knows), but whatever is chosen seems probably fine, as this is a
pretty low key change since it can always be tweaked further later (it's
not ABI).

Jason