00:00:00:00:00 vid 0
>dev v2 af 2 src :::0.0.0.0 grp
> :::239.1.1.112/00:00:00:00:00:00 vid 10
>dev v2 af 10 src 2001:db8:1::1 grp ff0e::1/00:00:00:00:00:00 vid 10
>dev v2 af 2 src :::192.0.2.1 grp
> :::239.1.1.1/00:00:00:00:00:00 vid 10
>
&
On Mon, 30 Jan 2023 16:50:32 +0100
Petr Machata wrote:
> Steven Rostedt writes:
>
> > On Thu, 26 Jan 2023 18:01:14 +0100
> > Petr Machata wrote:
> >
> >> + TP_printk("dev %s af %u src %pI4/%pI6c grp %pI4/%pI6c/%pM vid %u",
> >> +
.0.0/ff0e::1/00:00:00:00:00:00 vid 0
>dev v2 af 2 src 192.0.2.1/:: grp 239.1.1.1/::/00:00:00:00:00:00 vid 10
>dev v2 af 10 src 0.0.0.0/2001:db8:1::1 grp
> 0.0.0.0/ff0e::1/00:00:00:00:00:00 vid 10
>
> CC: Steven Rostedt
> CC: linux-trace-ker...@vger
On Tue, 20 Dec 2022 13:45:19 -0500
Steven Rostedt wrote:
> [
> Linus,
>
> I ran the script against your latest master branch:
> commit b6bb9676f2165d518b35ba3bea5f1fcfc0d969bf
>
> As the timer_shutdown*() code is now in your tree, I figured
>
applied at the end of the
merge window, to avoid conflicts with linux-next during the
development cycle. I can wait to Friday to run it again, and
resubmit.
What is the best way to handle this?
]
From: "Steven Rostedt (Google)"
Due to several bugs caused by timers bein
Tag SHA1: 7685328352dfd2908e23048f563e328dbd3526e9
Head SHA1: 870556da63870e01ade9bb8418ac5a21862f2f10
Steven Rostedt (Google) (5):
ARM: spear: Do not use timer namespace for timer_shutdown() function
clocksource/drivers/arm_arch_timer: Do not use timer namespace for
timer_shutdown() function
clocksour
- Updated the script to make ptr and slab into expressions instead of
using identifiers (Julia Lawall and Linus Torvalds)
Steven Rostedt (Google) (5):
ARM: spear: Do not use timer namespace for timer_shutdown() function
clocksource/drivers/arm_arch_timer: Do not use time
On Sat, 5 Nov 2022 14:13:14 -0700
Linus Torvalds wrote:
> (Comparing output is also fun because the ordering of the patches is
> random, so consecutive runs with the same rule will give different
> patches. I assume that it's just because it's done in parallel, but it
> doesn't help the "try to s
On Sat, 5 Nov 2022 14:13:14 -0700
Linus Torvalds wrote:
> And trying "when != ptr->timer" actually does the right thing in that
> it gets rid of the case where the timer is modified outside of the
> del_timer() case, *but* it also causes odd other changes to the
> output.
>
> Look at what it gen
On Sat, 5 Nov 2022 14:03:56 -0400
Steven Rostedt wrote:
> --- a/drivers/isdn/hardware/mISDN/hfcmulti.c
> +++ b/drivers/isdn/hardware/mISDN/hfcmulti.c
> @@ -4544,7 +4544,7 @@ release_port(struct hfc_multi *hc, struct dchannel *dch)
> spin_lock_irqsave(&hc->lock, flags);
On Sat, 5 Nov 2022 12:36:42 -0400
Steven Rostedt wrote:
> --8<
> @@
> identifier ptr, timer, rfield, slab;
> @@
> (
> - del_timer(&ptr->timer);
> + timer_shutdown(&ptr->timer);
On Sat, 5 Nov 2022 08:59:36 -0700
Linus Torvalds wrote:
> Others in the series were *definitely* not scripted, doing clearly
> manual cleanups:
>
> -if (dch->timer.function) {
> -del_timer(&dch->timer);
> -dch->timer.function = NULL;
> -}
> +timer_shutdown(&dch->timer
On Sat, 5 Nov 2022 12:36:42 -0400
Steven Rostedt wrote:
> On Sat, 5 Nov 2022 08:59:36 -0700
> Linus Torvalds wrote:
>
> > On Fri, Nov 4, 2022 at 11:01 PM Steven Rostedt wrote:
> >
> > >
> > > Patch 1 fixes an issue with sunrpc/xprt where it incorrect
On Sat, 5 Nov 2022 08:59:36 -0700
Linus Torvalds wrote:
> On Fri, Nov 4, 2022 at 11:01 PM Steven Rostedt wrote:
> >
> > Patch 1 fixes an issue with sunrpc/xprt where it incorrectly uses
> > del_singleshot_timer_sync() for something that is not a oneshot timer. As
> >
On Sat, 5 Nov 2022 07:18:17 -0700
Guenter Roeck wrote:
> Just in case you didn't notice:
>
> Looking through the resulting code, I think some of the remaining
> calls to del_singleshot_timer_sync() can be converted as well.
>
> The calls in drivers/staging/wlan-ng/prism2usb.c:prism2sta_disconne
From: "Steven Rostedt (Google)"
Before a timer is freed, timer_shutdown_sync() must be called.
And if synchronization is already done, then at least timer_shutdown()
needs to be called.
Link: https://lore.kernel.org/all/20221104054053.431922...@goodmis.org/
Cc: Jesse Brandeburg
stly believe that they are all safe, but that's
just my own opinion.
This series is here:
git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace.git
timers-start
Head SHA1: f58b516a65bac76f1bfa00126856d6c6c3d24a40
Steven Rostedt (Google) (38):
SUNRPC/xprt: Use del_time
On Fri, 4 Nov 2022 15:42:09 -0400
Steven Rostedt wrote:
> $ git grep '\btimer_shutdown'
> arch/arm/mach-spear/time.c:static inline void timer_shutdown(struct
> clock_event_device *evt)
> arch/arm/mach-spear/time.c: timer_shutdown(evt);
> arch/arm/mach-spear/time.
On Fri, 4 Nov 2022 12:22:32 -0700
Guenter Roeck wrote:
> Unfortunately the renaming caused some symbol conflicts.
>
> Global definition: timer_shutdown
>
> File Line
> 0 time.c93 static inline void timer_shutdown(struct
> clock_event_device *evt)
> 1 arm_arch_timer.c
On Thu, 3 Nov 2022 17:00:20 -0700
Eric Dumazet wrote:
> 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 add a new
> inet_csk_shutd
From: "Steven Rostedt (Google)"
Before a timer is freed, timer_shutdown_sync() must be called.
And if synchronization is already done, then at least timer_shutdown()
needs to be called.
Link: https://lore.kernel.org/all/20220407161745.7d675...@gandalf.local.home/
Cc: Jesse Bran
c() but deactivates the timer.
- Added a few more locations that got converted.
git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace.git
trace/timers
Head SHA1: 25106f0bb7968b3e8c746a7853f44b51840746c3
Steven Rostedt (Google) (33):
timers: Add timer_shutdown_sync() and timer_
On Sun, 30 Oct 2022 18:22:03 +0100
Paolo Abeni wrote:
> On the positive side, I think converting the sk_stop_timer in
> inet_csk_clear_xmit_timers() should be safe and should cover the issue
> reported by Guenter
Would something like this be OK?
[ Note, talking with Thomas Gleixner, we agreed
On Thu, 27 Oct 2022 17:07:20 -0400
Steven Rostedt wrote:
> > And maybe that function can also disallow any future re-arming even
> > for the case where the timer couldn't be actively removed.
The naming of the functions will depend on this.
If the async version always shu
On Thu, 27 Oct 2022 13:48:54 -0700
Linus Torvalds wrote:
> On Thu, Oct 27, 2022 at 1:34 PM Steven Rostedt wrote:
> >
> > 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),
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 sock *sk, struct timer_list* timer)
{
if (del_timer(timer))
__sock_put(sk)
On Thu, 27 Oct 2022 17:07:20 -0400
Steven Rostedt wrote:
> 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 that
On Thu, 27 Oct 2022 16:34:53 -0400
Steven Rostedt wrote:
> 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 be rearmed.
>
> I t
On Thu, 27 Oct 2022 13:15:23 -0700
Linus Torvalds wrote:
> On Thu, Oct 27, 2022 at 12:55 PM Steven Rostedt wrote:
> >
> > I think we need to update this code to squeeze in a del_timer_shutdown() to
> > make sure that the timers are never restarted.
>
> So the reas
From: "Steven Rostedt (Google)"
Before a timer is freed, del_timer_shutdown() must be called.
Link: https://lore.kernel.org/all/20220407161745.7d675...@gandalf.local.home/
Cc: Jesse Brandeburg
Cc: Tony Nguyen
Cc: "David S. Miller"
Cc: Eric Dumazet
Cc: Jakub Kicinski
On Thu, 27 Oct 2022 12:38:16 -0700
Guenter Roeck wrote:
> On 10/27/22 12:27, Steven Rostedt wrote:
> > On Thu, 27 Oct 2022 15:20:58 -0400
> > Steven Rostedt wrote:
> >
> >>> (many more of those)
> >>> ...
> >>> [ 16.329989] timer_
31 matches
Mail list logo
