On Mon, Feb 19, 2024 at 10:57 AM Valentin Schneider [off-list ref] wrote:

The TCP timewait timer is proving to be problematic for setups where scheduler
CPU isolation is achieved at runtime via cpusets (as opposed to statically via
isolcpus=domains).

...

 void inet_twsk_deschedule_put(struct inet_timewait_sock *tw)
 {
+       /* This can race with tcp_time_wait() and dccp_time_wait(), as the timer
+        * is armed /after/ adding it to the hashtables.
+        *
+        * If this is interleaved between inet_twsk_hashdance() and inet_twsk_put(),
+        * then this is a no-op: the timer will still end up armed.
+        *
+        * Conversely, if this successfully deletes the timer, then we know we
+        * have already gone through {tcp,dcpp}_time_wait(), and we can safely
+        * call inet_twsk_kill().
+        */
        if (del_timer_sync(&tw->tw_timer))
                inet_twsk_kill(tw);

I really do not think adding a comment will prevent races at netns dismantle.

We need to make sure the timer is not rearmed, we want to be absolutely
sure that after inet_twsk_purge() we have no pending timewait sockets,
otherwise UAF will happen on the netns structures.

I _think_ that you need timer_shutdown_sync() here, instead of del_timer_sync()