Fix iter_blocks on oddly sized or unaligned blocks

[jannic]

If len < GRANULARITY * 2, insert_free_block_ptr doesn't insert another block:

          let len = if let Some(x) = len
              .checked_sub((start as usize).wrapping_sub(unaligned_start as usize))
              .filter(|&x| x >= GRANULARITY * 2)
          {
              // Round down
              x & !(GRANULARITY - 1)
          } else {
              // The block is too small
              return None;
          };

This can happen if the block being added has an odd size (not a multiple of GRANULARITY * 2) or is unaligned.

Therefore, iter_blocks must also skip remaining lengths smaller than this.

I think this is the root cause for a panic we observed in rust-embedded/embedded-alloc#121

[yvt]

The length of the slice passed to iter_blocks must match the size returned by insert_free_block_ptr, which excludes the misaligned tail.

iter_blocks:

rlsf/crates/rlsf/src/tlsf.rs

Lines 1482 to 1485 in 03664d5

	/// passed to [`Self::insert_free_block_ptr`], and its length must be the
	/// sum of the return values of that call to `insert_free_block_ptr` and
	/// all subsequent calls to [`Self::append_free_block_ptr`] that have been
	/// made to expand this memory pool.

insert_free_block_ptr:

rlsf/crates/rlsf/src/tlsf.rs

Lines 431 to 432 in 03664d5

	/// Returns the actual number of bytes (counted from the beginning of
	/// `block`) used to create the memory pool. This value is necessary to

[jannic]

Interesting, seems like I missed that detail (and the author of https://github.com/rust-embedded/embedded-alloc/blob/master/src/tlsf.rs#L82-L83 as well).
So the correct solution would be for embedded-alloc to store the value returned from insert_free_block_ptr and use that when calling iter_blocks.

[yvt]

That is correct.

[jannic]

Thanks, I provided a PR for fixing the bug in embedded-alloc. I no longer think there is a bug in rlsf, so I'll close this ticket.