I'll run a test on the other series without change first. We'll see what happens. If necessary I'll add [parts of] this patch and re-test, but before doing that I would like to get a sense for the st
I guess. OK. Guenter, I posted a new series, but did not include this change. If you want to test that other series, I would suggest to at least add the first part of this patch, otherwise it will tr
inet_csk_clear_xmit_timers() can be called multiple times during TCP socket lifetime. (See tcp_disconnect(), which can be followed by another connect() ... and loop) Maybe add a second parameter, or
Would something like this be OK? [ Note, talking with Thomas Gleixner, we agreed that we are changing the name to: time_shutdown_sync() and timer_shutdown() (no wait version). I'll be posting new pat
For the records, there are other cases, e.g. after sk_stop_timer() in clear_3rdack_retransmission() (mptcp code) the timer can be-rearmed without re-initializing. I *think* there are more of such use
Sorry too many bugs at once :) FWIW Paolo was saying privately earlier today that he spotted some cases of reuse, he gave an example of ccid2_hc_tx_packet_recv() So we can't convert all cases of sk_s
Could someone from networking confirm (or deny) that the timer being removed in sk_stop_timer() will no longer be used even if del_timer() returns false? net/core/sock.c: void sk_stop_timer(struct so
What about del_timer_try_shutdown(), that if it removes the timer, it sets the function to NULL (making it equivalent to a successful shutdown), otherwise it does nothing. Allowing the the timer to
I think we have our answer from Guenter's report: Linux version 6.1.0-rc2-00138-gced58c742836 (groeck@jupiter) (aarch64-linux-gcc (GCC) 11.3.0, GNU ld (GNU Binutils) 2.39) #1 SMP PREEMPT Thu Oct 27 1
The naming of the functions will depend on this. If the async version always shuts down the timer, then we should have the interface be: del_timer_shutdown() <- async del_timer_shutdown_sync <- sync
Guenter, Can you apply this patch on top of the series, and see if it makes the warning go away? diff --git a/include/linux/timer.h b/include/linux/timer.h index d4d90149d015..e3c5f4bdd526 100644 --
Well, I think this current use case will break if we prevent the timer from being rearmed or run again if it's not found. But as you said, the networking folks need to confirm or deny it. The fact th
Sounds sane to me and should work, but as mentioned, I think the networking people need to say "yeah" too. And maybe that function can also disallow any future re-arming even for the case where the t
OK, so the above is assuming that the timer is always active, and del_timer() returns if it successfully removed it (where it can call sock_put()), but if del_timer() returns 0, that means the timer
So the reason the networking code does this is that it can't just do the old 'sync()' thing, the timers are deleted in contexts where that isn't valid. Which is also afaik why the networking code doe
I think this is indeed an issue, and I'm replying to the net patch as it has the necessary folks Cc'd. The ipv4 tcp code has: void tcp_init_xmit_timers(struct sock *sk) { inet_csk_init_xmit_timers(sk
Before a timer is freed, del_timer_shutdown() must be called. Link: https://lore.kernel.org/all/20220407161745.7d6754b3@xxxxxxxxxxxxxxxxxx/ Cc: Jesse Brandeburg <jesse.brandeburg@xxxxxxxxx> Cc: Tony