writing beyond
> the target struct member.
>
> Cc: Steven Rostedt
> Cc: Ingo Molnar
> Signed-off-by: Kees Cook
> ---
> kernel/trace/trace.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
>
On reboot, one of my test boxes now triggers the following warning:
[ cut here ]
RPM raw-wakeref not held
WARNING: CPU: 4 PID: 1 at drivers/gpu/drm/i915/intel_runtime_pm.h:106
gen6_write32+0x1bc/0x2a0 [i915]
Modules linked in: ebtable_filter ebtables bridge stp llc ip6
[ Forgot to add those on the commit itself ]
-- Steve
On Thu, 14 Jan 2021 16:32:06 -0500
Steven Rostedt wrote:
> On reboot, one of my test boxes now triggers the following warning:
>
> [ cut here ]
> RPM raw-wakeref not held
> WARNING: CPU: 4 PI
On Thu, 14 Jan 2021 21:35:53 +
Chris Wilson wrote:
> Quoting Steven Rostedt (2021-01-14 21:32:06)
> > On reboot, one of my test boxes now triggers the following warning:
>
> 057fe3535eb3 ("drm/i915: Disable RPM wakeref assertions during driver
> shutdown"
On Thu, 14 Jan 2021 20:15:45 -0800
Linus Torvalds wrote:
> On Thu, Jan 14, 2021 at 2:01 PM Steven Rostedt wrote:
> >
> > Thanks, I take it, it will be going into mainline soon.
>
> Just got merged - it might be a good idea to verify that your problem is
> solved
On Fri, 15 Jan 2021 09:50:25 +0200
Jani Nikula wrote:
> >> fe0f1e3bfdfeb53e18f1206aea4f40b9bd1f291c
> >> ("drm/i915: Shut down displays gracefully on reboot")
> >>
> >> Which makes sense, as it happens on shutdown.
>
> Please try this pull, heading to -rc4, which cointains "drm/i915:
> Di
On my test box with latest v5.12-rc1, running with all trace events
enabled, I consistently trigger this warning.
It appears to get triggered by the trace_intel_pipe_disable() code.
-- Steve
[ cut here ]
i915 :00:02.0: drm_WARN_ON_ONCE(drm_drv_uses_atomic_modeset(
On Mon, 1 Mar 2021 19:20:59 +0200
Ville Syrjälä wrote:
> > ilk_crtc_disable+0x85/0x390 [i915]
>
> But this part is confusing me. intel_crtc_get_vblank_counter() is
> only supposed to do drm_crtc_accurate_vblank_count() fallback when
> the hardware lacks a working frame counter, and that sho
On Wed, 30 Jun 2021 04:28:39 -0700
Joe Perches wrote:
> On Sat, 2021-06-12 at 08:42 -0700, Joe Perches wrote:
> > The __assign_str macro has an unusual ending semicolon but the vast
> > majority of uses of the macro already have semicolon termination.
>
> ping?
>
I wasn't sure I was the one
On Wed, 20 Oct 2021 20:10:23 -0700
Gurchetan Singh wrote:
> - drm_gem_private_object_init(..) increases the total memory
> counter.
>
> * All GEM objects (whether allocated or imported) seem to begin
> there.
> * If there's a better place/method, please do let
> me know.
>
> - drm
On Wed, 20 Oct 2021 20:10:24 -0700
Gurchetan Singh wrote:
> @@ -305,6 +306,7 @@ drm_gem_object_release_handle(int id, void *ptr, void
> *data)
> drm_gem_remove_prime_handles(obj, file_priv);
> drm_vma_node_revoke(&obj->vma_node, file_priv);
>
> + drm_gem_trace_gpu_mem_instance(
On Thu, 21 Oct 2021 13:56:38 +0200
Daniel Vetter wrote:
> Yay, that patch is just impressive. Lands a new gpu tracepoints, never
> even showed up on the gpu subsystem discussion list.
I'm guessing there was some confusion. When this was first introduced, I
stated it needs to go into the gpu tree
When I tried to test patches applied to v5.15-rc3, I hit this bug (and
hence can not test my code), on 32 bit x86.
[ cut here ]
kernel BUG at drivers/gpu/drm/i915/i915_sw_fence.c:245!
invalid opcode: [#1] SMP PTI
CPU: 3 PID: 1 Comm: swapper/0 Not tainted 5.14.0-rc1-tes
"__i915_sw_fence_call" I discovered afterwards; and
> ignoring recent discussions of where __attributes ought to appear :-)
>
>
> [PATCH] drm/i915: fix blank screen booting crashes
Thanks, I added it to my "fixes" patch set that I apply before testing.
It looks t
On Wed, 19 Jan 2022 11:15:08 +0200
Andy Shevchenko wrote:
> > +static inline const char *yesno(bool v) { return v ? "yes" : "no"; }
>
>
>
> Perhaps keep it on 4 lines? Yes, yes/no is short, but if we add others
> (enable/disable) it will not be possible to keep on one line. And hence
> style
grant_log ==
TOMOYO_GRANTLOG_YES
is not readable at all. Not compared to
cond->grant_log == TOMOYO_GRANTLOG_YES
I say keep it one line!
Reviewed-by: Steven Rostedt (Google)
-- Steve
>
> Then,
>
> Reviewed-by: Sakari Ailus
On Wed, 19 Jan 2022 21:22:57 +0200
Andy Shevchenko wrote:
> On Wed, Jan 19, 2022 at 04:38:26PM +, David Laight wrote:
> > > > > > +static inline const char *yesno(bool v) { return v ? "yes" : "no";
> > > > > > }
> > >
> > > return "yes\0no" + v * 4;
> > >
> > > :-)
> >
> > except '"
On Wed, 19 Jan 2022 21:25:08 +0200
Andy Shevchenko wrote:
> > I say keep it one line!
> >
> > Reviewed-by: Steven Rostedt (Google)
>
> I believe Sakari strongly follows the 80 rule, which means...
Checkpatch says "100" I think we need to simply update
On Fri, 12 Nov 2021 10:08:41 -0500
Jason Baron wrote:
> > A key difference between that patchset and this patch (besides that
> > small fact that I used +x instead of +T) was that my patchset allowed
> > the dyndbg trace to be emitted to the main buffer and did not force them
> > to be in an inst
On Fri, 12 Nov 2021 12:32:23 -0500
Jason Baron wrote:
> Ok, it looks like Vincent's patch defines a dyndbg event and then uses
> 'trace_dyndbg()' to output to the 'main' log. So all dynamic output to
> the 'main' ftrace buffer goes through that event if I understand it
> correctly. Here's a point
On Fri, 19 Nov 2021 15:46:31 -0700
jim.cro...@gmail.com wrote:
> > So I could see us supporting subsystem specific trace buffer output
> > via dynamic debug here. We could add new dev_debug() variants that
> > allow say a trace buffer to be supplied. So in that way subsystems
> > could 'opt-out'
On Tue, 14 Dec 2021 15:03:00 +0100
Sebastian Andrzej Siewior wrote:
> Luca Abeni reported this:
> | BUG: scheduling while atomic: kworker/u8:2/15203/0x0003
> | CPU: 1 PID: 15203 Comm: kworker/u8:2 Not tainted 4.19.1-rt3 #10
> | Call Trace:
> | rt_spin_lock+0x3f/0x50
> | gen6_read32+0x45/0x1
On Tue, 14 Dec 2021 18:34:50 +0200
Ville Syrjälä wrote:
> Looks lightly tedious. Can't we have "slow" (or whatever) versions of
> the trace macros so we could just declare these the same was as before
> without having to manually write that wrapper for every event?
That would be quite tedious as
On Thu, 17 Dec 2020 11:03:20 +0100
Daniel Vetter wrote:
> I think we're tripping over the might_sleep() all the mutexes have,
> and that's not as good as yours, but good enough to catch a missing
> rcu_read_unlock(). That's kinda why I'm baffled, since like almost
> every 2nd function in the back
From: Steven Rostedt (VMware)
In discussing a build failure on x86_32 due to the use of roundup() on
a 64 bit number, I realized that there's no generic equivalent
roundup_64(). It is implemented in two separate places in the kernel,
but there really should be just one that all ca
On Thu, 23 May 2019 08:10:44 -0700
Linus Torvalds wrote:
> On Thu, May 23, 2019 at 7:00 AM Steven Rostedt wrote:
> >
> > +# define roundup_64(x, y) (\
> > +{ \
> >
On Thu, 23 May 2019 09:51:29 -0700
Linus Torvalds wrote:
> On Thu, May 23, 2019 at 8:27 AM Steven Rostedt wrote:
> >
> > I haven't yet tested this, but what about something like the following:
>
> So that at least handles the constant case that the normal "
On Fri, 24 May 2019 16:11:14 +0100
Roger Willcocks wrote:
> On 23/05/2019 16:27, Steven Rostedt wrote:
> >
> > I haven't yet tested this, but what about something like the following:
> >
> > ...perhaps forget about the constant check, and just
On Fri, 24 May 2019 19:30:45 +0300
Nikolay Borisov wrote:
> > Yes I do. I corrected it in my next email.
> >
> > http://lkml.kernel.org/r/20190523133648.591f9...@gandalf.local.home
>
> Or perhaps just using is_power_of_2 from include/linux/log2.h ?
Even better. Thanks,
-- Steve
On Thu, 18 Apr 2019 14:11:44 +0200
Alexander Potapenko wrote:
> On Thu, Apr 18, 2019 at 1:54 PM Thomas Gleixner wrote:
> >
> > On Thu, 18 Apr 2019, Alexander Potapenko wrote:
> > > On Thu, Apr 18, 2019 at 11:06 AM Thomas Gleixner
> > > wrote:
> > > > - save_stack_trace(&b->stack_trac
[ Added Tom Zanussi ]
On Thu, 18 Apr 2019 10:41:39 +0200
Thomas Gleixner wrote:
> The indirection through struct stack_trace is not necessary at all. Use the
> storage array based interface.
>
> Signed-off-by: Thomas Gleixner
> Cc: Steven Rostedt
Looks fine to me
Acked-by:
e cpu buffer
> for stack retrieval and avoids the fixed length allocation along with the
> conditional execution pathes.
>
> Signed-off-by: Thomas Gleixner
> Cc: Steven Rostedt
> ---
> kernel/trace/trace.c | 77
> +--
&
On Thu, 18 Apr 2019 17:43:59 +0200 (CEST)
Thomas Gleixner wrote:
> On Thu, 18 Apr 2019, Steven Rostedt wrote:
> > On Thu, 18 Apr 2019 10:41:40 +0200
> > Thomas Gleixner wrote:
> > > -static DEFINE_PER_CPU(struct ftrace_stack, ftrace_stack);
> > > +/* Thi
On Thu, 18 Apr 2019 14:58:55 -0500
Tom Zanussi wrote:
> > Tom,
> >
> > Can you review this too?
>
> Looks good to me too!
>
> Acked-by: Tom Zanussi
>
Would you be OK to upgrade this to a Reviewed-by tag?
Thanks!
-- Steve
___
dri-devel mailing
On Thu, 18 Apr 2019 23:14:45 +0200 (CEST)
Thomas Gleixner wrote:
> On Thu, 18 Apr 2019, Josh Poimboeuf wrote:
>
> > On Thu, Apr 18, 2019 at 10:41:20AM +0200, Thomas Gleixner wrote:
> > > - Remove the extra array member of stack_dump_trace[]. It's not required
> > > as
> > > the stack tracer
On Thu, 18 Apr 2019 17:24:43 -0400
Steven Rostedt wrote:
> I believe it was for historical leftovers (there was a time it was
> required), and left there for "paranoid" sake. But let me apply the
> patch and see if it is really needed.
I removed the +1 on the
do it this way to begin with. I think I
copied something else that couldn't do it this way for some reason and
didn't put any brain power behind the copy. :-/ But that was back in
2008 so I blame it on being "young and stupid" ;-)
Other then the above nit and removing the unnee
On Fri, 19 Apr 2019 00:44:17 +0200 (CEST)
Thomas Gleixner wrote:
> On Thu, 18 Apr 2019, Steven Rostedt wrote:
> > On Thu, 18 Apr 2019 10:41:20 +0200
> > Thomas Gleixner wrote:
> >
> > > @@ -412,23 +404,20 @@ stack_trace_sysctl(struct ctl_table *tab
> >
On Thu, 18 Apr 2019 10:41:41 +0200
Thomas Gleixner wrote:
> It's only used in trace.c and there is absolutely no point in compiling it
> in when user space stack traces are not supported.
>
> Signed-off-by: Thomas Gleixner
> Cc: Steven Rostedt
Funny, these were moved out
On Thu, 18 Apr 2019 10:41:43 +0200
Thomas Gleixner wrote:
> Simplify the stack retrieval code by using the storage array based
> interface.
>
> Signed-off-by: Thomas Gleixner
Reviewed-by: Steven Rostedt (VMware)
-- Steve
___
dri-d
On Thu, 18 Apr 2019 10:41:42 +0200
Thomas Gleixner wrote:
> Replace the indirection through struct stack_trace by using the storage
> array based interfaces.
>
> Signed-off-by: Thomas Gleixner
> Cc: Steven Rostedt
Reviewed-by: Steven Rostedt (VMw
On Thu, 28 Mar 2019 19:10:07 +0100
Andrey Konovalov wrote:
> > > Signed-off-by: Andrey Konovalov
> > > ---
> > > ipc/shm.c | 2 ++
> > > mm/madvise.c | 2 ++
> > > mm/mempolicy.c | 5 +
> > > mm/migrate.c | 1 +
> > > mm/mincore.c | 2 ++
> > > mm/mlock.c | 5 +
> > > mm/
I was doing a bit of an audit on trace events and found this:
# cat /debug/tracing/events/i915/intel_disable_plane/format
name: intel_disable_plane
ID: 1358
format:
field:unsigned short common_type; offset:0; size:2;
signed:0;
field:unsigned char common_flags; of
On Wed, 10 Jul 2019 18:45:24 +0300
Ville Syrjälä wrote:
> > TP_printk("pipe %c, plane %s, frame=%u, scanline=%u",
> > pipe_name(__entry->pipe), __entry->name,
> > __entry->frame, __entry->scanline)
> >
> >
> > The issue here is that you record a point
From: "Steven Rostedt (VMware)"
Currently the intel_update_plane and intel_disable_plane tracepoints record
the address of plane->name in the ring buffer, and then when reading the
ring buffer uses %s to get the name. The issue with this, is that those two
events can be minutes,
On Thu, 25 Jul 2019 19:34:01 -0700
syzbot wrote:
> syzbot has bisected this bug to:
>
> commit 04cf31a759ef575f750a63777cee95500e410994
> Author: Michael Ellerman
> Date: Thu Mar 24 11:04:01 2016 +
>
> ftrace: Make ftrace_location_range() global
It's sad that I have yet to find a s
On Wed, 16 Feb 2022 10:09:14 -0800
Linus Torvalds wrote:
> Byungchul, could you fix those two issues? Some of your reports may
> well be entirely valid, but the hard-to-read hex offsets and the
> knowledge that at least some of them are confused about how
> prepare_to_wait -> wait actually works
On Thu, 17 Feb 2022 19:57:38 +0900
Byungchul Park wrote:
> diff --git a/kernel/dependency/Makefile b/kernel/dependency/Makefile
> new file mode 100644
> index 000..9f7778e
> --- /dev/null
> +++ b/kernel/dependency/Makefile
> @@ -0,0 +1,4 @@
> +# SPDX-License-Identifier: GPL-2.0
> +
> +obj-$(C
On Thu, 17 Feb 2022 19:57:46 +0900
Byungchul Park wrote:
> +static int __init dept_proc_init(void)
> +{
> + proc_create_seq("dept_deps", S_IRUSR, NULL, &dept_deps_ops);
> + proc_create_single("dept_stats", S_IRUSR, NULL, dept_stats_show);
> + return 0;
> +}
> +
> +__initcall(dept_proc
On Thu, 17 Feb 2022 10:51:09 -0500
"Theodore Ts'o" wrote:
> I know that you're trying to help us, but this tool needs to be far
> better than Lockdep before we should think about merging it. Even if
> it finds 5% more potential deadlocks, if it creates 95% more false
> positive reports --- and t
On Thu, 17 Feb 2022 19:57:38 +0900
Byungchul Park wrote:
> diff --git a/include/linux/dept.h b/include/linux/dept.h
> new file mode 100644
> index 000..2ac4bca
> --- /dev/null
> +++ b/include/linux/dept.h
> @@ -0,0 +1,480 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * DEPT(DEPendenc
On Mon, 9 May 2022 09:16:37 +0900
Byungchul Park wrote:
> CASE 2.
>
>lock L with depth n
>lock A
>lock_nested L' with depth n + 1
>...
>unlock L'
>unlock A
>unlock L
>
> This case is allowed by Lockdep.
> This case is *NOT* allowed by DEPT cuz it's a *DEADLOCK*.
>
>
On Tue, 10 May 2022 08:38:38 +0900
Byungchul Park wrote:
> Yes, I was talking about A and L'.
>
> > detect that regardless of L. A nested lock associates the the nesting with
>
> When I checked Lockdep code, L' with depth n + 1 and L' with depth n
> have different classes in Lockdep.
If that
Sorry for the late review. I finally got some time to look at this.
On Mon, 16 May 2022 16:56:39 -0600
Jim Cromie wrote:
> diff --git a/include/trace/events/drm.h b/include/trace/events/drm.h
> new file mode 100644
> index ..6de80dd68620
> --- /dev/null
> +++ b/include/trace/event
On Thu, 12 Dec 2019 15:32:35 -0500
Sean Paul wrote:
>
> What about trace_printk()? It doesn't give us the control we get from using
> tracepoints and it's not meant to be left sprinkled around in code.
Not to mention that trace_printk() is not for production use (only for
developers debugging p
On Fri, 13 Dec 2019 13:34:46 +0200
Pekka Paalanen wrote:
> Is there a way to pull out messages
> from /sys/kernel/debug/tracing/trace and filter them on reading instead
> of on writing?
FYI, you can mount the tracing directory without having to mount the
debug directory.
mount -t tracefs nodev
On Fri, 13 Dec 2019 11:47:03 -0500
Sean Paul wrote:
> > Why is there a separate trace event for each of these?
> >
>
> To make it easier on userspace to enable just a single drm category.
>
But trace events can easily be filtered. Say you have a field called
category, you could then just se
On Sun, 6 Oct 2019 10:18:11 -0700
Linus Torvalds wrote:
> On Sun, Oct 6, 2019 at 9:55 AM Theodore Y. Ts'o wrote:
> >
> > Well, one thing we *can* do is if (a) if we can create a kselftest
> > branch which we know is stable and won't change, and (b) we can get
> > assurances that Linus *will* acc
they work and what they are for.
-- Steve
>
> Signed-off-by: Chris Wilson
> Cc: Steven Rostedt (VMware)
> ---
> include/linux/trace.h | 4 ++
> kernel/trace/trace.c | 142 ++
> 2 files changed, 105 insertions(+), 41 deletions(-)
&
On Sun, 01 Mar 2020 22:22:25 +
Chris Wilson wrote:
> > I'm curious to why we need it to be anonymous. Why not allow them to be
> > visible from the tracing directory. This could allow for easier
> > debugging. Note, the trace instances have ref counters thus they can't
> > be removed if somet
On Sun, 01 Mar 2020 22:22:25 +
Chris Wilson wrote:
> Quoting Steven Rostedt (2020-03-01 18:18:16)
> > On Sun, 1 Mar 2020 15:52:47 +
> > Chris Wilson wrote:
> >
> > > To facilitate construction of per-client event ringbuffers, in
> > > part
/?h=ftrace/core&id=13292494379f92f532de71b31a54018336adc589
-- Steve
>
> Cc: Daniel Vetter
> Cc: David Airlie
> Cc: Jani Nikula
> Cc: Joonas Lahtinen
> Cc: Pekka Paalanen
> Cc: Rob Clark
> Cc: Steven Rostedt
> Cc: Thomas Zimmermann
> Cc: Ville Syrjäl
On Thu, 16 Jan 2020 07:27:22 +0100
Daniel Vetter wrote:
> On Tue, Jan 14, 2020 at 12:21:43PM -0500, Sean Paul wrote:
> > From: Sean Paul
> >
> > This patch uses a ring_buffer to keep a "flight recorder" (name credit
> > Weston)
> > of DRM logs for a specified set of debug categories. The user
ntry->static_power,
> + __entry->total_time == 0 ? 0 :
> + (100 * __entry->busy_time) / __entry->total_time,
> __entry->power)
> );
>
Tracing updates look fine to me. Having the division on the output
makes more sense.
Reviewed-by: Steven Rostedt (VMware) # for tracing code
-- Steve
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
On Sat, 12 Jun 2021 08:42:27 -0700
Joe Perches wrote:
> The __assign_str macro has an unusual ending semicolon but the vast
> majority of uses of the macro already have semicolon termination.
>
> $ git grep -P '\b__assign_str\b' | wc -l
> 551
> $ git grep -P '\b__assign_str\b.*;' | wc -l
> 480
>
In a report for a regression in my code, I tried to run v6.3-rc1 through my
tests. It crashed at boot up on my first test (my start up tests do take a
long time, hence the 206 seconds of boot!).
[ 206.238782] [ cut here ]
[ 206.277786] DEBUG_LOCKS_WARN_ON(lock->magic !=
On Tue, 7 Mar 2023 21:22:23 -0500
Steven Rostedt wrote:
> Looks like there was a lock possibly used after free. But as commit
> 9bff18d13473a9fdf81d5158248472a9d8ecf2bd ("drm/ttm: use per BO cleanup
> workers") changed a lot of this code, I figured it may be the culprit.
If
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: "Noralf Trønnes"
Cc: David Airlie
Cc: Daniel Vetter
Cc: Jani Nikula
Cc: Joonas Lahtinen
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: Sumit Semwal
Cc: "Christian König"
Cc: linux-me...@vger.kernel.org
Cc: dri-devel@lists.freedeskt
[
quilt mail --send still can't handle unicode characters.
Here's the patch again
]
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/
[
quilt mail --send still can't handle unicode characters.
Here's the patch again
]
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: "N
From: "Steven Rostedt (Google)"
Before a timer is freed, timer_shutdown_sync() must be called.
Link: https://lore.kernel.org/all/20220407161745.7d675...@gandalf.local.home/
Cc: "Noralf Trønnes"
Cc: David Airlie
Cc: Daniel Vetter
Cc: Jani Nikula
Cc: Joonas Lahtinen
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_
From: "Steven Rostedt (Google)"
Before a timer is freed, timer_shutdown_sync() must be called.
Link: https://lore.kernel.org/all/20220407161745.7d675...@gandalf.local.home/
Cc: Sumit Semwal
Cc: "Christian König"
Cc: linux-me...@vger.kernel.org
Cc: dri-devel@lists.freede
[ Once again, quilt fails the MIME coding ]
From: "Steven Rostedt (Google)"
Before a timer is freed, timer_shutdown_sync() must be called.
Link: https://lore.kernel.org/all/20220407161745.7d675...@gandalf.local.home/
Cc: Sumit Semwal
Cc: "Christian König"
Cc: linux-me..
[ Once again, quilt fails the MIME coding ]
From: "Steven Rostedt (Google)"
Before a timer is freed, timer_shutdown_sync() must be called.
Link: https://lore.kernel.org/all/20220407161745.7d675...@gandalf.local.home/
Cc: "Noralf Trønnes"
Cc: David Airlie
Cc: Daniel Vet
On Fri, 4 Nov 2022 08:15:53 +0100
Christian König wrote:
> > index fb6e0a6ae2c9..5d3e7b503501 100644
> > --- a/drivers/dma-buf/st-dma-fence.c
> > +++ b/drivers/dma-buf/st-dma-fence.c
> > @@ -412,7 +412,7 @@ static int test_wait_timeout(void *arg)
> >
> > err = 0;
> > err_free:
> > - de
On Fri, 4 Nov 2022 08:48:28 +
Tvrtko Ursulin wrote:
> If it stays all DRM drivers in one patch then I guess it needs to go via
> drm-misc, which for i915 would be okay I think in this case since patch
> is extremely unlikely to clash with anything. Or split it up per driver
> and then we c
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 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.
From: "Steven Rostedt (Google)"
Before a timer is freed, timer_shutdown_sync() must be called.
Link: https://lore.kernel.org/all/20221104054053.431922...@goodmis.org/
Cc: "Noralf Trønnes"
Cc: David Airlie
Cc: Daniel Vetter
Cc: Jani Nikula
Cc: Joonas Lahtinen
Cc: Rodr
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
From: "Steven Rostedt (Google)"
Before a timer is released, timer_shutdown_sync() must be called.
Link: https://lore.kernel.org/all/20221104054053.431922...@goodmis.org/
Cc: "Noralf Trønnes"
Cc: David Airlie
Cc: Daniel Vetter
Cc: Jani Nikula
Cc: Joonas Lahtinen
From: "Steven Rostedt (Google)"
Before a timer is released, timer_shutdown_sync() must be called.
Link: https://lore.kernel.org/all/20221104054053.431922...@goodmis.org/
Cc: Sumit Semwal
Cc: "Christian König"
Cc: linux-me...@vger.kernel.org
Cc: dri-devel@lists.freedeskt
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
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 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:
> 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:
> --8<
> @@
> identifier ptr, timer, rfield, slab;
> @@
> (
> - del_timer(&ptr->timer);
> + timer_shutdown(&ptr->timer);
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 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: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
- 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
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
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
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
>
On Wed, 15 Mar 2023 16:25:11 +0100
Christian König wrote:
> >>
> >> Thanks for the notice,
> > I'm still getting this on Linus's latest tree.
>
> This must be some reference counting issue which only happens in your
> particular use case. We have tested this quite extensively and couldn't
>
On Wed, 15 Mar 2023 11:57:12 -0400
Steven Rostedt wrote:
So I'm looking at the backtraces.
> The WARN_ON triggered:
>
> [ 21.481449] mpls_gso: MPLS GSO support
> [ 21.488795] IPI shorthand broadcast: enabled
> [ 21.488873] [ cut here ]
On Wed, 15 Mar 2023 11:57:12 -0400
Steven Rostedt wrote:
> The WARN_ON triggered:
>
> [ 21.481449] mpls_gso: MPLS GSO support
> [ 21.488795] IPI shorthand broadcast: enabled
> [ 21.488873] [ cut here ]
> [ 21.490101]
On Wed, 15 Mar 2023 20:51:49 +0100
Christian König wrote:
> Steven please try the attached patch.
I applied it, but as it's not always reproducible, I'll have to give it
several runs before I give you my "tested-by" tag.
-- Steve
1 - 100 of 243 matches
Mail list logo
