Re: [PATCH 2/2] rust_binder: account for deferred work size in Thread::read()

[Chris Wiseman]

On Mon, Nov 09, 2026 at 07:42:02PM +0000, Carlos Llamas wrote:
> ok, so if userspace is setting TF_DEFER_COMPLETE, the read buffer size
> should reflect the possiblity of a BR_TRANSACTION_COMPLETE no? I'm not
> sure this is a driver issue. Maybe I'm missing something?
>
> I guess we are trying to match the behavior we have without the
> TF_DEFER_COMPLETE and using a smaller read buffer e.g. 65-bytes. I
> suppose this makes sense.

Right, the goal is to match non-TF_DEFER_COMPLETE behavior for smaller
read buffers (and when deferred BR_INCREFS/BR_ACQUIRE node items are
queued via push_work_deferred()) so Thread::read() drains the local
deferred items first instead of pulling a new transaction from the
process queue that will not fit behind them.

> It seems sashiko has found a legit issue, see:
> https://sashiko.dev/#/patchset/18e61a85b0d13e9c.3137322e32332e3235332e313736.9c152.0000sendgmr%40google.com

And yes, the Sashiko report is spot on: putting deferred_size in the
while condition caused Thread::read() to skip the loop and return only
BR_NOOP when writer.len() could fit the deferred items on their own
(76 <= writer.len() < 76 + deferred_size).

In v2, I will move the initial BR_NOOP reservation ahead of the queue
check and keep the while condition at 76 bytes.  When
inner.should_use_process_work_queue() is true and writer.len() < 76 +
deferred_size, setting inner.process_work_list =
!inner.work_list.is_empty() switches Thread::read() to
Self::get_work_local so the loop drains the deferred items immediately
without waiting on the process queue or busy-looping on BR_NOOP.

Thanks,
Chris