defconfig
powerpc randconfig-c003-20221110
i386 debian-10.3-kvm
i386debian-10.3-kunit
i386 debian-10.3-func
clang tested configs:
hexagon randconfig-r041-2022
hexagon
iss_defconfig
powerpc mpc834x_mds_defconfig
arm64allyesconfig
arm defconfig
arm allyesconfig
i386 randconfig-c001
powerpc randconfig-c003-20221110
x86_64
powerpc mpc834x_mds_defconfig
arm64allyesconfig
arm defconfig
arm allyesconfig
i386 randconfig-c001
powerpc randconfig-c003-20221110
x86_64
randconfig-a016
i386 randconfig-c001
powerpc randconfig-c003-20221110
clang tested configs:
x86_64randconfig-a012
x86_64randconfig-a014
x86_64randconfig-a016
i386
rhel-8.3
powerpc randconfig-c003-20221110
x86_64randconfig-a006
x86_64randconfig-a004
x86_64randconfig-a002
x86_64randconfig-a011
x86_64
From: Li Li
An async transaction to a frozen process will still be successfully
put in the queue. But this pending async transaction won't be processed
until the target process is unfrozen at an unspecified time in the
future. Pass this important information back to the user space caller
by retur
From: Li Li
User applications need to know if their binder transactions reach a
frozen process or not. For sync binder calls, Linux kernel already
has a dedicated return value BR_FROZEN_REPLY, indicating this sync
binder transaction will be rejected (similar to BR_DEAD_REPLY) as the
target proces
On Wed, Nov 9, 2022 at 2:43 PM Carlos Llamas wrote:
>
> On Thu, Nov 03, 2022 at 12:05:49PM -0700, Li Li wrote:
> > From: Li Li
> >
> > An async transaction to a frozen process will still be successsfully
>
> nit: sucessfully typo
Nice catch! Will remove the extra 's' in v2.
>
> > put in the que
