[PATCH RFC batadv v3 0/6] batman-adv: tt: atomic sashiko fixes
Sven Eckelmann <[email protected]>
| Newsgroups | org.open-mesh.lists.batman |
|---|---|
| Message-ID | <[email protected]> |
There were a couple of sashiko reports regarding the batadv-next-pullrequest-20260728 PR. I went through the TT code and tried to handle them and at the same time already predict what else sashiko might report as next. I needed to change the batadv_tt_local_remove() hash interaction as preparation for the related NEW flag (and counter) handling. And the netdev maintainers rejected this approach (for now). I had to re-add the atomic_t code parts back in this patchset. But since the netdev maintainers didn't like the atomic_t implementation, everything was changed to atomic_t with the help of scoped_guard(). Signed-off-by: Sven Eckelmann <[email protected]> --- Changes in v3: - switched to spinlock_bh due to rejection atomic_t by netdev (and potentially easier code) - switch back to RFC - Link to v2: https://patch.msgid.link/[email protected] Changes in v2: - rebase on main - add "batman-adv: tt: use atomic flag modifications" and "batman-adv: tt: simplify NEW flag transition code" because they are reverted on main - add patch to extract the roam "add" code in a separate function - make the "simplify NEW flag transition code" patch independent of atomic_t code - Link to v1: https://patch.msgid.link/[email protected] --- Sven Eckelmann (6): batman-adv: tt: remove only the entry which was looked up from the hash batman-adv: tt: extract code handling a roam on add batman-adv: tt: simplify NEW flag transition code batman-adv: tt: use atomic flag modifications batman-adv: tt: decrement count for committed client on local_remove batman-adv: tt: don't uncount never committed clients on pending purge net/batman-adv/translation-table.c | 693 +++++++++++++++++++++++-------------- net/batman-adv/types.h | 8 +- 2 files changed, 448 insertions(+), 253 deletions(-) --- base-commit: 46e983472304d8875436a23ccb996ea18856081a change-id: 20260730-tt-fixes-fca2b722ebbd Best regards, -- Sven Eckelmann <[email protected]>