Re: [PATCH] rust_binder: fix oneway spam detection

[Alice Ryhl <aliceryhl@google.com>]

On Wed, Feb 11, 2026 at 11:41:40PM -0800, Tiffany Yang wrote:
> Alice Ryhl <aliceryhl@google.com> writes:
> 
> > On Tue, Feb 10, 2026 at 11:28:20PM +0000, Carlos Llamas wrote:
> >> The spam detection logic in TreeRange was executed before the current
> >> request was inserted into the tree. So the new request was not being
> >> factored in the spam calculation. Fix this by moving the logic after
> >> the new range has been inserted.
> >> 
> >> Also, the detection logic for ArrayRange was missing altogether which
> >> meant large spamming transactions could get away without being detected.
> >> Fix this by implementing an equivalent low_oneway_space() in ArrayRange.
> >> 
> >> Note that I looked into centralizing this logic in RangeAllocator but
> >> iterating through 'state' and 'size' got a bit too complicated (for me)
> >> and I abandoned this effort.
> >
> > I think current approach is fine.
> >
> 
> Is there a pattern that would allow us to avoid so much duplicate code?
> Or like... a nice way to call into a shared low_oneway_space? It's
> frustrating that the two implementations are basically the same except
> for how they iterate over buffers. I've been thinking of rust binder as
> binder's chance at a fresh start, so I'm reticent to introduce this kind
> of tech debt so early on.
> 
> I don't have a clear idea of what the appropriate fix would be here, but
> I'd be happy to help do some plumbing if it'll make things smoother in
> the long run!

We could potentially have a single low_oneway_space() that takes an
iterator over the ranges. Then each impl can pass an iterator specific
to its own impl.

Alice