tmpfs memory/node limit enforcement is check-then-act: tm_pages_used ENOSPC test races its atomic_add (and tm_nodes_inuse check races the TMPFS_LOCK'd increment) — concurrent growth can overshoot tmpfs limits

Summary

The swap-backed page budget check 'tm_pages_used + newpages - oldpages > tm_pages_max' (:1007-1008) reads tm_pages_used non-atomically and is not serialized with the atomic_add_long at :1016 - per-node resizes are node-lock serialized, but N threads growing N different tmpfs files all test the same snapshot and each commit, so tm_pages_used can exceed tm_pages_max by up to (concurrency x per-op delta). Same family at the node limit: 'tm_nodes_inuse >= tm_nodes_max' checked at :107 OUTSIDE the TMPFS_LOCK that guards the increment at :182-184 (window spans a sleeping kmalloc_obj), so node count can also overshoot - backstopped by the hard zone cap (kmalloc_obj_raise_limit). Unpriv local users on any tmpfs mount racing concurrent extend-heavy writers can push page usage modestly past the configured limit - bounded transient over-commit; the sums stay exact (both sides of every op use the node-locked tn_aobj_pages) so no permanent drift/leak/double-account. Realistic overshoot a few MB with many threads; hardening not corruption. Cleanly demonstrable only with vfs.usermount=1 (tiny tmpfs); default /tmp limit ~half RAM+swap buries the margin. Fix: TMPFS_LOCK around test+commit in reg_resize + re-test under lock for the node limit.