attr: Fixed custom attrs overflowing rattr.count

Not sure how this was missed. The whole tradeoff of shrinking
rattr.count was that by default lfs3_rattr_t would take up less space,
but user-provided buffers would need an indirect lfs3_data_t to support
arbitrary buffer sizes.

This managed to scrape by with a 16-bit count (15-bit really), but
fortunately failed test_attrs_fattr_resync_receive with an 8-bit count.
And only barely! 256 is the smallest possible custom attr that
overflows.

I guess a point towards making internal limitation as tight as possible
to catch mistakes like these earlier.

---

Added test_attrs_setattr_big and test_attrs_fattr_big to catch this in
the future.

Note that while this added some code, stack is unaffected. This is
because custom attribute handling is off the hot-path, which is why the
lfs3_rattr_t -> lfs3_rattr_t+lfs3_data_t split is worth it:

           code          stack          ctx
  before: 37016           2416          652
  after:  37052 (+0.1%)   2416 (+0.0%)  652 (+0.0%)
This commit is contained in:
Christopher Haster
2025-07-15 14:22:36 -05:00
parent 5b0ec8090a
commit 0364ed5011
2 changed files with 250 additions and 5 deletions
+7 -5
View File
@@ -8313,10 +8313,11 @@ static int lfs3_mdir_commit__(lfs3_t *lfs3, lfs3_mdir_t *mdir_,
? LFS3_RATTR(
LFS3_TAG_RM
| LFS3_TAG_ATTR(attrs_[j].type), 0)
: LFS3_RATTR_BUF(
: LFS3_RATTR_DATA(
LFS3_TAG_ATTR(attrs_[j].type), 0,
attrs_[j].buffer,
lfs3_attr_size(&attrs_[j])));
&LFS3_DATA_BUF(
attrs_[j].buffer,
lfs3_attr_size(&attrs_[j]))));
if (err) {
return err;
}
@@ -11446,9 +11447,10 @@ int lfs3_setattr(lfs3_t *lfs3, const char *path, uint8_t type,
// commit our attr
lfs3_alloc_ckpoint(lfs3);
err = lfs3_mdir_commit(lfs3, &mdir, LFS3_RATTRS(
LFS3_RATTR_BUF(
LFS3_RATTR_DATA(
LFS3_TAG_ATTR(type), 0,
buffer, size)));
&LFS3_DATA_BUF(
buffer, size))));
if (err) {
return err;
}