ger than 20ms and amdgpu in the
> > > > > > backtrace my
> > > > > > educated guess is that we messed up some timeout waiting for the hw.
> > > > > >
> > > > > > We usually do wait a few us, but it can be that somebody is wait
that somebody is waiting for ms
instead.
So there are some todos here as far as I can see and It would be helpful to
get a cleaner backtrace if possible.
Actually CONFIG_ANDROID looks like is going to be removed, so the
CONFIG_RCU_EXP_CPU_STALL_TIMEOUT
will not have any dependencies on the CONFIG_AN
t; > > backtrace my
> > > > educated guess is that we messed up some timeout waiting for the hw.
> > > >
> > > > We usually do wait a few us, but it can be that somebody is waiting for
> > > > ms
> > > > instead.
> > > >
in so later, I was on vacation for a week.
> > >
> > > Well when any RCU period is longer than 20ms and amdgpu in the backtrace
> > > my
> > > educated guess is that we messed up some timeout waiting for the hw.
> > >
> > > We usually do wait a few us, bu
s is that we messed up some timeout waiting for the hw.
> >
> > We usually do wait a few us, but it can be that somebody is waiting for ms
> > instead.
> >
> > So there are some todos here as far as I can see and It would be helpful to
> > get a cleaner backtra
vacation for a week.
>
> Well when any RCU period is longer than 20ms and amdgpu in the backtrace my
> educated guess is that we messed up some timeout waiting for the hw.
>
> We usually do wait a few us, but it can be that somebody is waiting for ms
> instead.
>
> So there are som
Hi guys,
Am 28.06.22 um 22:11 schrieb Uladzislau Rezki:
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
"Jason A. Donenfeld" writes:
> 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 (
when waking up, because one of the objectives is forward
secrecy. See
https://git.zx2c4.com/wireguard-linux/tree/drivers/net/wireguard/device.c#n63
if (IS_ENABLED(CONFIG_PM_AUTOSLEEP) || IS_ENABLED(CONFIG_ANDROID))
return 0;
if (action != PM_HIBERNATION_PREPARE &&
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
e 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
On Thu, Jun 30, 2022 at 5:53 PM tlhackque 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.
Waki
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 tha
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 WireGua
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 e
27;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
On Wed, Jun 29, 2022 at 5:30 PM Jason A. Donenfeld wrote:
>
> Hey again,
>
> On Thu, Jun 30, 2022 at 2:24 AM Jason A. Donenfeld wrote:
> > 1) Introduce a simple CONFIG_PM_CONTINUOUS_AUTOSLEEPING Kconfig thing
> >with lots of discouraging help text.
> >
> > 2) Go with the /sys/power tunable an
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,
> > > > > +
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)
> > > > +{
> > > >
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);
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 bot
Hey again,
On Thu, Jun 30, 2022 at 2:24 AM Jason A. Donenfeld 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 refle
e 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)
`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
>
`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&
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 proce
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
. 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 th
nds from
userspace, as that behavior is still in no way related to
CONFIG_ANDROID.
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 yo
onfig 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 su
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" har
@@ 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
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.
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.
iff 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
On Wed, Jun 29, 2022 at 1:47 PM Jason A. Donenfeld 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 initiatiate
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
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 u
> 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 i
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
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
ack 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?
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_SU
oblem 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
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
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 t
be 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 re
is 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_ANDR
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 goo
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
ymbol, 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
A
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
> va
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 fo
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_ENABL
+ b/drivers/Makefile
> @@ -176,7 +176,7 @@ obj-$(CONFIG_USB4)+= thunderbolt/
> obj-$(CONFIG_CORESIGHT) += hwtracing/coresight/
> obj-y+= hwtracing/intel_th/
> obj-$(CONFIG_STM)+= hwt
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 qu
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 i
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 Androi
d 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.
> >&
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 happ
sing 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
62 matches
Mail list logo
