On Mon, Aug 12, 2024 at 10:13 PM Greg KH wrote:
>
> On Mon, Aug 12, 2024 at 02:18:44PM -0700, Li Li wrote:
> > From: Li Li
>
> Sorry, but I can not parse your Subject: line at all. Please use
> vowels, we don't have a lack of them :)
>
> Also look at how other
From: Li Li
Frozen tasks can't process binder transactions, so sync binder
transactions will fail with BR_FROZEN_REPLY and async binder
transactions will be queued in the kernel async binder buffer.
As these queued async transactions accumulates over time, the async
buffer will eventual
On Wed, Nov 23, 2022 at 10:58 AM Carlos Llamas wrote:
>
> This looks good. Could you rename the new op to signify the frozen
> scenario though? We might have some other instances of pending
> transactions in the future so might as well be specific here.
Done [1].
v3: rename BR_TRANSACTION_PENDIN
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 call
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
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 call
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
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 extr
From: Li Li
An async transaction to a frozen process will still be successsfully
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 call
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
On Thu, May 26, 2022 at 10:50 PM Greg KH wrote:
>
> On Thu, May 26, 2022 at 03:00:17PM -0700, Li Li wrote:
> > From: Li Li
> >
> > Resend [Patch v3] with cover letter in case my previous email failed
> > to reach the maillist (no comments for 2 weeks).
> >
From: Li Li
When the target process is busy, incoming oneway transactions are
queued in the async_todo list. If the clients continue sending extra
oneway transactions while the target process is frozen, this queue can
become too large to accommodate new transactions. That's why binder
d
From: Li Li
Resend [Patch v3] with cover letter in case my previous email failed
to reach the maillist (no comments for 2 weeks).
The previous comments of the old patch can be found at the following link:
https://lore.kernel.org/lkml/canbpypjknwso94nug1tkr1dgk2w2kbxijtriyvb7s3czhtz
From: Li Li
When the target process is busy, incoming oneway transactions are
queued in the async_todo list. If the clients continue sending extra
oneway transactions while the target process is frozen, this queue can
become too large to accommodate new transactions. That's why binder
d
From: Li Li
When the target process is busy, incoming oneway transactions are
queued in the async_todo list. If the clients continue sending extra
oneway transactions while the target process is frozen, this queue can
become too large to accommodate new transactions. That's why binder
d
On Thu, May 19, 2022 at 8:50 AM Greg KH wrote:
>
> On Wed, May 18, 2022 at 05:06:23PM -0700, Li Li wrote:
> > From: Li Li
>
> Note, your subject does not say what TF_UPDATE_TXN is, so it's a bit
> hard to determine what is happening here. Can you clean that up a bit
&g
From: Li Li
When the target process is busy, incoming oneway transactions are
queued in the async_todo list. If the clients continue sending extra
oneway transactions while the target process is frozen, this queue can
become too large to accommodate new transactions. That's why binder
d
On Fri, Sep 10, 2021 at 12:15 AM Greg KH wrote:
>
> On Thu, Sep 09, 2021 at 11:17:42PM -0700, Li Li wrote:
> > On Thu, Sep 9, 2021 at 10:38 PM Greg KH wrote:
> > >
> > > On Thu, Sep 09, 2021 at 08:53:16PM -0700, Li Li wrote:
> > > > struct binde
From: Li Li
Currently cgroup freezer is used to freeze the application threads, and
BINDER_FREEZE is used to freeze the corresponding binder interface.
There's already a mechanism in ioctl(BINDER_FREEZE) to wait for any
existing transactions to drain out before actually freezing the b
From: Li Li
As there isn't an atomic operation to freeze the main thread and binder
interface together, it's possible the main thread initiates a new binder
transaction while the binder interfaces are already frozen. This race issue
will result in failed binder transaction and unexpect
On Thu, Sep 9, 2021 at 11:03 PM Dan Carpenter wrote:
>
> On Thu, Sep 09, 2021 at 04:21:41PM -0700, Li Li wrote:
> > @@ -4648,6 +4647,22 @@ static int binder_ioctl_get_node_debug_info(struct
> > binder_proc *proc,
> > return 0;
> > }
> >
> &
On Thu, Sep 9, 2021 at 10:38 PM Greg KH wrote:
>
> On Thu, Sep 09, 2021 at 08:53:16PM -0700, Li Li wrote:
> > struct binder_frozen_status_info {
> > __u32pid;
> > +
> > + /* process received sync transactions since last frozen
> > +
From: Li Li
Currently cgroup freezer is used to freeze the application threads, and
BINDER_FREEZE is used to freeze the corresponding binder interface.
There's already a mechanism in ioctl(BINDER_FREEZE) to wait for any
existing transactions to drain out before actually freezing the b
From: Li Li
As there isn't an atomic operation to freeze the main thread and binder
interface together, it's possible the main thread initiates a new binder
transaction while the binder interfaces are already frozen. This race issue
will result in failed binder transaction and unexpect
Hi Todd,
Thanks for reviewing the patch! Please see my reply below.
And I'll send out v2 soon addressing your concerns.
On Thu, Sep 9, 2021 at 4:54 PM Todd Kjos wrote:
>
> On Thu, Sep 9, 2021 at 4:21 PM Li Li wrote:
> >
> > From: Li Li
> >
> > Currently c
From: Li Li
Currently cgroup freezer is used to freeze the application threads, and
BINDER_FREEZE is used to freeze binder interface. There's already a
mechanism for BINDER_FREEZE to wait for any existing transactions to
drain out before actually freezing the binder interface.
But freezi
From: Li Li
As there isn't an atomic operation to freeze the main thread and binder
interface together, it's possible the main thread initiates a new binder
transaction while the binder interfaces are already frozen. This race issue
will result in failed binder transaction and unexpect
On Thu, Mar 18, 2021 at 9:20 AM Todd Kjos wrote:
>
> On Wed, Mar 17, 2021 at 1:17 PM Jann Horn wrote:
> >
> > On Wed, Mar 17, 2021 at 7:00 PM Christian Brauner
> > wrote:
> > > On Mon, Mar 15, 2021 at 06:16:27PM -0700, Li Li wrote:
> > > > To impro
From: Marco Ballesio
User space needs to know if binder transactions occurred to frozen
processes. Introduce a new BINDER_GET_FROZEN ioctl and keep track of
transactions occurring to frozen proceses.
Signed-off-by: Marco Ballesio
Signed-off-by: Li Li
---
drivers/android/binder.c
EINTR, which is propagated
to user space.
Test: built, booted, interrupted a worker thread within
binder_wait_for_work
Signed-off-by: Marco Ballesio
Signed-off-by: Li Li
---
drivers/android/binder.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/android/binder.c b/dr
or to transactions to
processes marked as frozen.
Signed-off-by: Marco Ballesio
Co-developed-by: Todd Kjos
Signed-off-by: Todd Kjos
Signed-off-by: Li Li
---
drivers/android/binder.c| 139 ++--
drivers/android/binder_internal.h | 12 +++
include/uapi/linux/an
From: Li Li
To improve the user experience when switching between recently used
applications, the background applications which are not currently needed
are cached in the memory. Normally, a well designed application will not
consume valuable CPU resources in the background. However, it&#
On Fri, Mar 12, 2021 at 4:00 PM Todd Kjos wrote:
>
> On Thu, Mar 11, 2021 at 10:46 AM Li Li wrote:
> >
> > From: Marco Ballesio
> >
> > Frozen tasks can't process binder transactions, so a way is required to
> > inform transmitting ends of communicatio
From: Marco Ballesio
User space needs to know if binder transactions occurred to frozen
processes. Introduce a new BINDER_GET_FROZEN ioctl and keep track of
transactions occurring to frozen proceses.
Signed-off-by: Marco Ballesio
Signed-off-by: Li Li
---
drivers/android/binder.c
or to transactions to
processes marked as frozen.
Signed-off-by: Marco Ballesio
Co-developed-by: Todd Kjos
Signed-off-by: Todd Kjos
Signed-off-by: Li Li
---
drivers/android/binder.c| 141 ++--
drivers/android/binder_internal.h | 12 +++
include/uapi/linux/an
EINTR, which is propagated
to user space.
Test: built, booted, interrupted a worker thread within
binder_wait_for_work
Signed-off-by: Marco Ballesio
Signed-off-by: Li Li
---
drivers/android/binder.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/android/binder.c b/dr
From: Li Li
To improve the user experience when switching between recently used
applications, the background applications which are not currently needed
are cached in the memory. Normally, a well designed application will not
consume valuable CPU resources in the background. However, it&#
On Wed, Mar 10, 2021 at 11:33 PM Greg KH wrote:
>
> On Wed, Mar 10, 2021 at 02:52:49PM -0800, Li Li wrote:
> > if (target_proc) {
> > binder_inner_proc_lock(target_proc);
> > + target_proc->outstanding_txns--;
> > + WARN
EINTR, which is propagated
to user space.
Test: built, booted, interrupted a worker thread within
binder_wait_for_work
Signed-off-by: Marco Ballesio
Signed-off-by: Li Li
---
drivers/android/binder.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/android/binder.c b/dr
From: Marco Ballesio
User space needs to know if binder transactions occurred to frozen
processes. Introduce a new BINDER_GET_FROZEN ioctl and keep track of
transactions occurring to frozen proceses.
Signed-off-by: Marco Ballesio
Signed-off-by: Li Li
---
drivers/android/binder.c
or to transactions to
processes marked as frozen.
Signed-off-by: Marco Ballesio
Co-developed-by: Todd Kjos
Signed-off-by: Todd Kjos
Signed-off-by: Li Li
---
drivers/android/binder.c| 137 ++--
drivers/android/binder_internal.h | 12 +++
include/uapi/linux/an
From: Li Li
To improve the user experience when switching between recently used
applications, the background applications which are not currently needed
are cached in the memory. Normally, a well designed application will not
consume valuable CPU resources in the background. However, it&#
42 matches
Mail list logo
