Re: [Intel-gfx] [BUG] completely bonkers use of set_need_resched + VM_FAULT_NOPAGE

On Thu, 12 Sep 2013, Peter Zijlstra wrote: On Thu, Sep 12, 2013 at 05:35:43PM +0100, Chris Wilson wrote: Not quite, as it would be possible for the evil userspace to trigger a GPU hang that would cause the sane userspace to spin indefinitely waiting for the error recovery to kick in.

Re: [Intel-gfx] [BUG] completely bonkers use of set_need_resched + VM_FAULT_NOPAGE

On Thu, 12 Sep 2013, Daniel Vetter wrote: On Thu, Sep 12, 2013 at 10:20 PM, Thomas Gleixner t...@linutronix.de wrote: I think for ttm drivers it's just execbuf being exploitable. But on drm/i915 we've had the same issue with the pwrite/pread ioctls, so a simple glBufferData(glMap) kind

Re: [Intel-gfx] [BUG] completely bonkers use of set_need_resched + VM_FAULT_NOPAGE

On Thu, 12 Sep 2013, Daniel Vetter wrote: On Thu, Sep 12, 2013 at 9:58 PM, Thomas Gleixner t...@linutronix.de wrote: On Thu, Sep 12, 2013 at 6:22 PM, Peter Zijlstra pet...@infradead.org wrote: If 'sane' userspace is never supposed to do this, then only insane userspace is going

Re: [Intel-gfx] [BUG] completely bonkers use of set_need_resched + VM_FAULT_NOPAGE

On Thu, 12 Sep 2013, Daniel Vetter wrote: On Thu, Sep 12, 2013 at 6:22 PM, Peter Zijlstra pet...@infradead.org wrote: If 'sane' userspace is never supposed to do this, then only insane userspace is going to hurt from this and that's a GOOD (tm) thing, right? ;-) Afaik sane userspace

Re: [Intel-gfx] Regression: audit: x86: drop arch from __audit_syscall_entry() interface

On Wed, 22 Oct 2014, Eric Paris wrote: That's really serious. Looking now. Indeed its serious. And it's even more serious as this masterpiece of assembly wreckage was pulled in via your tree w/o having an acked-by one of the x86 maintainers. On Wed, 2014-10-22 at 16:08 -0200, Paulo Zanoni

Re: [Intel-gfx] [PATCH v3] softirq: Prevent looping on disabled tasklets

On Sun, 12 Feb 2017, Chris Wilson wrote: > On Sun, Feb 12, 2017 at 03:46:09PM +, Chris Wilson wrote: > > +void tasklet_enable(struct tasklet_struct *t) > > +{ > > + if (!atomic_dec_and_test(>count)) > > + return; > > + > > + if (test_bit(TASKLET_STATE_SCHED, >state)) > > +

Re: [Intel-gfx] [PATCH 4/6] time: Expose current clocksource in use by timekeeping framework

On Thu, 16 Mar 2017, sourab.gu...@intel.com wrote: Please Cc LKML for patches which touch subsystems managed on LKML. Also CC'ing people on the 0/N letter would be helpful, so we can see what this is about. > For the drivers to be able to use the cross timestamp framework, > they need the

Re: [Intel-gfx] freedesktop bug id: 100548, bisected to sched/clock commit

On Thu, 13 Apr 2017, Peter Zijlstra wrote: > On Thu, Apr 13, 2017 at 03:30:25PM +0300, Martin Peres wrote: > > On 13/04/17 14:48, Peter Zijlstra wrote: > > > On Wed, Apr 12, 2017 at 05:49:53PM +0300, Martin Peres wrote: > > > > > > > Good to know. Is there a way to disable this behaviour, as a

Re: [Intel-gfx] [PATCH] x86/gpu: CNL uses the same GMS values as SKL

.com> > Cc: Ander Conselvan de Oliveira <ander.conselvan.de.olive...@intel.com> > Cc: x...@kernel.org > Signed-off-by: Paulo Zanoni <paulo.r.zan...@intel.com> > Signed-off-by: Rodrigo Vivi <rodrigo.v...@intel.com> Acked-by: Thomas Gleixner <t...@linutronix.de> __

Re: [Intel-gfx] [PATCH] drm/i915: Preallocate mmu notifier to unbreak cpu hotplug deadlock

On Thu, 5 Oct 2017, Daniel Vetter wrote: > On Thu, Oct 05, 2017 at 05:23:20PM +0200, Thomas Gleixner wrote: > > Aside of that, is it really required to use stomp_machine() for this > > synchronization? We certainly have less intrusive mechansisms than that. > > Yeah, the sto

Re: [Intel-gfx] [PATCH] drm/i915: Preallocate mmu notifier to unbreak cpu hotplug deadlock

On Thu, 5 Oct 2017, Daniel Vetter wrote: > 4.14-rc1 gained the fancy new cross-release support in lockdep, which > seems to have uncovered a few more rules about what is allowed and > isn't. > > This one here seems to indicate that allocating a work-queue while > holding mmap_sem is a no-go, so

Re: [Intel-gfx] [PATCH] drm/i915: Preallocate mmu notifier to unbreak cpu hotplug deadlock

On Thu, 5 Oct 2017, Daniel Vetter wrote: > On Thu, Oct 05, 2017 at 06:19:30PM +0200, Thomas Gleixner wrote: > > On Thu, 5 Oct 2017, Daniel Vetter wrote: > > > On Thu, Oct 05, 2017 at 05:23:20PM +0200, Thomas Gleixner wrote: > > > > Aside of that, is it really

Re: [Intel-gfx] [PATCH] drm/i915: Use rcu instead of stop_machine

On Fri, 6 Oct 2017, Daniel Vetter wrote: > On Fri, Oct 6, 2017 at 10:42 AM, Chris Wilson > wrote: > >> > > This patch tries to address the locking snafu from > >> > > >> > There's a locking snafu in the code? The lock problem exists definitely. We did not introduce new

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Use rcu instead of stop_machine in set_wedged

On Fri, 6 Oct 2017, Chris Wilson wrote: > Quoting Daniel Vetter (2017-10-06 10:06:37) > > stop_machine is not really a locking primitive we should use, except > > when the hw folks tell us the hw is broken and that's the only way to > > work around it. > > > > This patch tries to address the

Re: [Intel-gfx] [PATCH V3 03/29] x86/PCI: deprecate pci_get_bus_and_slot()

nction in favor of > pci_get_domain_bus_and_slot(). > > Use domain number of 0 as the domain number is not available in struct > irq_routing_table. > > Signed-off-by: Sinan Kaya <ok...@codeaurora.org> Acked-by: Thomas Gleixner <t...@linutronix.de> > --- > arch/x8

Re: [Intel-gfx] [PATCH 1/9] x86/early-quirks: Extend Intel graphics stolen memory placement to 64bit

On Fri, 24 Nov 2017, Matthew Auld wrote: > From: Joonas Lahtinen <joonas.lahti...@linux.intel.com> Please CC the linux kernel mailinglist on patches related to x86. The MAINTAINERS file says: X86 ARCHITECTURE (32-BIT AND 64-BIT) M: Thomas Gleixner <t...@linutronix.de> M:

Re: [Intel-gfx] [GIT pull] x86 APIC updates for 4.15

; commit fdba46ffb4c203b6e6794163493fd310f98bb4be (HEAD, refs/bisect/bad) > Author: Thomas Gleixner <t...@linutronix.de> > Date: Wed Sep 13 23:29:27 2017 +0200 > > x86/apic: Get rid of multi CPU affinity > < SNIP > > > Could you have a look at it please? I ha

Re: [Intel-gfx] [GIT pull] x86 APIC updates for 4.15

On Thu, 30 Nov 2017, Maarten Lankhorst wrote: > Op 30-11-17 om 10:18 schreef Thomas Gleixner: > # cat /sys/kernel/debug/irq/irqs/28 > handler: handle_edge_irq > device: :00:02.0 > status: 0x > istate: 0x > ddepth: 0 > wdepth:

Re: [Intel-gfx] [PATCH] drm/i915: Remove unused IRQ chip data of HDMI LPE audio

On Wed, 13 Dec 2017, Anand, Jerome wrote: > > -Original Message- > > From: Thomas Gleixner [mailto:t...@linutronix.de] > > Sent: Tuesday, December 12, 2017 10:37 PM > > To: Anand, Jerome <jerome.an...@intel.com> > > Cc: Ville Syrjälä <ville.sy

Re: [Intel-gfx] [PATCH] drm/i915: Remove unused IRQ chip data of HDMI LPE audio

On Mon, 11 Dec 2017, Anand, Jerome wrote: > > On Fri, 8 Dec 2017, Ville Syrjälä wrote: > > > > > On Fri, Dec 08, 2017 at 05:33:23PM +0800, Augustine.Chen wrote: > > > > The chip data of HDMI LPE audio is set to drm_i915_private which is > > > > not consistent with the expectation by x86 APIC

Re: [Intel-gfx] [PATCH] drm/i915: Remove unused IRQ chip data of HDMI LPE audio

On Wed, 13 Dec 2017, Takashi Iwai wrote: > On Wed, 13 Dec 2017 12:35:54 +0100, > Thomas Gleixner wrote: > > > > > > On Mon, 11 Dec 2017, Anand, Jerome wrote: > > > > > > On Fri, 8 Dec 2017, Ville Syrjälä wrote: > > > > > > > >

Re: [Intel-gfx] [PATCH 3/9] x86/early-quirks: reverse the if ladders

On Thu, 7 Dec 2017, Matthew Auld wrote: > Makes things a little easier to follow. I disagree. The comment explains gms (what ever that is) in ascending order and the code has that implemented the same way. Now you change the code to descending order. How is that easier to follow? Not at all.

Re: [Intel-gfx] [PATCH 1/9] x86/early-quirks: Extend Intel graphics stolen memory placement to 64bit

Matthew, On Thu, 7 Dec 2017, Matthew Auld wrote: Can you please add a version number to your patches? Having the same subject line five times is just annoying. > From: Joonas Lahtinen > To give upcoming SKU BIOSes more flexibility in placing the Intel >

Re: [Intel-gfx] [PATCH] drm/i915: Remove unused IRQ chip data of HDMI LPE audio

On Fri, 8 Dec 2017, Ville Syrjälä wrote: > On Fri, Dec 08, 2017 at 05:33:23PM +0800, Augustine.Chen wrote: > > The chip data of HDMI LPE audio is set to drm_i915_private which is not > > consistent with the expectation by x86 APIC driver. > > Hmm. Why is the apic code looking at data for an irq

Re: [Intel-gfx] [GIT pull] x86 APIC updates for 4.15

On Mon, 11 Dec 2017, Thomas Gleixner wrote: > On Mon, 11 Dec 2017, Daniel Vetter wrote: > > Anything else we can do to move this? I just had to resolve a small > > conflict when moving forward to -rc3. Carrying a revert for the entire > > apic pull (too many deps to just reve

Re: [Intel-gfx] [GIT pull] x86 APIC updates for 4.15

On Mon, 11 Dec 2017, Daniel Vetter wrote: > Anything else we can do to move this? I just had to resolve a small > conflict when moving forward to -rc3. Carrying a revert for the entire > apic pull (too many deps to just revert the bisected patch) is a bit > annoying.

Re: [Intel-gfx] [PATCH] RFC: debugobjects: capture stack traces at _init() time

On Tue, 20 Mar 2018, Daniel Vetter wrote: > Sometimes it's really easy to know which object has gone boom and > where the offending code is, and sometimes it's really hard. One case > we're trying to hunt down is when module unload catches a live debug > object, with a module with lots of them. >

Re: [Intel-gfx] [PATCH] drm/i915/fence: Do not use TIMER_IRQSAFE

On Thu, 28 Feb 2019, Chris Wilson wrote: > Quoting Thomas Gleixner (2019-02-28 10:09:26) > > On Thu, 28 Feb 2019, Chris Wilson wrote: > > > It may not be the best of api, but it's the only one available for the > > > driver to use... > > > > The c

Re: [Intel-gfx] [PATCH] drm/i915/fence: Do not use TIMER_IRQSAFE

On Thu, 28 Feb 2019, Chris Wilson wrote: > Quoting Sebastian Andrzej Siewior (2019-02-26 16:00:38) > > On 2019-02-12 17:28:57 [+0100], To linux-ker...@vger.kernel.org wrote: > > > The timer is initialized with TIMER_IRQSAFE flag. It does look like the > > > timer callback requires this flag at

[Intel-gfx] [RFC patch 15/41] drm: Remove the ULONG_MAX stack trace hackery

No architecture terminates the stack trace with ULONG_MAX anymore. Remove the cruft. Signed-off-by: Thomas Gleixner Cc: intel-gfx@lists.freedesktop.org Cc: Joonas Lahtinen Cc: Maarten Lankhorst Cc: dri-de...@lists.freedesktop.org Cc: David Airlie Cc: Jani Nikula Cc: Daniel Vetter Cc

[Intel-gfx] [RFC patch 32/41] drm: Simplify stacktrace handling

pointer in the stack_trace struct so it points to the depot storage. Signed-off-by: Thomas Gleixner Cc: intel-gfx@lists.freedesktop.org Cc: Joonas Lahtinen Cc: Maarten Lankhorst Cc: dri-de...@lists.freedesktop.org Cc: David Airlie Cc: Jani Nikula Cc: Daniel Vetter Cc: Rodrigo Vivi

[Intel-gfx] [patch V2 02/29] stacktrace: Provide helpers for common stack trace operations

use cases a storage array and the number of valid stack trace entries in the array is sufficient. Provide helper functions which avoid the struct stack_trace indirection so the usage sites can be cleaned up. Signed-off-by: Thomas Gleixner --- include/linux/stacktrace.h | 27 +++ kernel

[Intel-gfx] [patch V2 29/29] x86/stacktrace: Use common infrastructure

Replace the stack_trace_save*() functions with the new arch_stack_walk() interfaces. Signed-off-by: Thomas Gleixner Cc: linux-a...@vger.kernel.org --- arch/x86/Kconfig |1 arch/x86/kernel/stacktrace.c | 116 +++ 2 files changed, 20

[Intel-gfx] [patch V2 22/29] tracing: Make ftrace_trace_userstack() static and conditional

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 --- kernel/trace/trace.c | 14 -- kernel/trace/trace.h |8 2 files changed, 8 insertions

[Intel-gfx] [patch V2 28/29] stacktrace: Provide common infrastructure

of duplicated code and allows to implement better filtering than 'skip number of entries' in the future without touching any architecture specific code. Signed-off-by: Thomas Gleixner Cc: linux-a...@vger.kernel.org --- include/linux/stacktrace.h | 38 + kernel/stacktrace.c| 173

[Intel-gfx] [patch V2 19/29] lockdep: Simplify stack trace handling

Replace the indirection through struct stack_trace by using the storage array based interfaces and storing the information is a small lockdep specific data structure. Signed-off-by: Thomas Gleixner --- include/linux/lockdep.h |9 +++-- kernel/locking/lockdep.c | 44

[Intel-gfx] [patch V2 23/29] tracing: Simplify stack trace retrieval

Replace the indirection through struct stack_trace by using the storage array based interfaces. Signed-off-by: Thomas Gleixner Cc: Steven Rostedt --- kernel/trace/trace.c | 40 +--- 1 file changed, 13 insertions(+), 27 deletions(-) --- a/kernel/trace

[Intel-gfx] [patch V2 12/29] dma/debug: Simplify stracktrace retrieval

Replace the indirection through struct stack_trace with an invocation of the storage array based interface. Signed-off-by: Thomas Gleixner Cc: io...@lists.linux-foundation.org Cc: Robin Murphy Cc: Christoph Hellwig Cc: Marek Szyprowski --- kernel/dma/debug.c | 13 + 1 file

[Intel-gfx] [patch V2 26/29] stacktrace: Remove obsolete functions

No more users of the struct stack_trace based interfaces. Remove them. Remove the macro stubs for !CONFIG_STACKTRACE as well as they are pointless because the storage on the call sites is conditional on CONFIG_STACKTRACE already. No point to be 'smart'. Signed-off-by: Thomas Gleixner

[Intel-gfx] [patch V2 01/29] tracing: Cleanup stack trace code

() as it's using the stack_trace_ namespace. Free the name up for stack trace related functions. Signed-off-by: Thomas Gleixner Cc: Steven Rostedt --- V2: Add more cleanups and use print_max_stack() as requested by Steven. --- include/linux/ftrace.h | 18 -- kernel/trace

[Intel-gfx] [patch V2 00/29] stacktrace: Consolidate stack trace usage

This is an update to V1: https://lkml.kernel.org/r/20190410102754.387743...@linutronix.de Struct stack_trace is a sinkhole for input and output parameters which is largely pointless for most usage sites. In fact if embedded into other data structures it creates indirections and extra storage

[Intel-gfx] [patch V2 16/29] drm: Simplify stacktrace handling

pointer in the stack_trace struct so it points to the depot storage. Signed-off-by: Thomas Gleixner Cc: intel-gfx@lists.freedesktop.org Cc: Joonas Lahtinen Cc: Maarten Lankhorst Cc: dri-de...@lists.freedesktop.org Cc: David Airlie Cc: Jani Nikula Cc: Daniel Vetter Cc: Rodrigo Vivi

[Intel-gfx] [patch V2 05/29] proc: Simplify task stack retrieval

Replace the indirection through struct stack_trace with an invocation of the storage array based interface. Signed-off-by: Thomas Gleixner Reviewed-by: Alexey Dobriyan Cc: Andrew Morton --- fs/proc/base.c | 14 +- 1 file changed, 5 insertions(+), 9 deletions(-) --- a/fs/proc

[Intel-gfx] [patch V2 27/29] lib/stackdepot: Remove obsolete functions

No more users of the struct stack_trace based interfaces. Signed-off-by: Thomas Gleixner Acked-by: Alexander Potapenko --- include/linux/stackdepot.h |4 lib/stackdepot.c | 20 2 files changed, 24 deletions(-) --- a/include/linux/stackdepot.h +++ b

[Intel-gfx] [patch V2 13/29] btrfs: ref-verify: Simplify stack trace retrieval

Replace the indirection through struct stack_trace with an invocation of the storage array based interface. Signed-off-by: Thomas Gleixner Reviewed-by: Johannes Thumshirn Acked-by: David Sterba Cc: Chris Mason Cc: Josef Bacik Cc: linux-bt...@vger.kernel.org --- fs/btrfs/ref-verify.c | 15

[Intel-gfx] [patch V2 06/29] latency_top: Simplify stack trace handling

Replace the indirection through struct stack_trace with an invocation of the storage array based interface. Signed-off-by: Thomas Gleixner --- kernel/latencytop.c | 17 ++--- 1 file changed, 2 insertions(+), 15 deletions(-) --- a/kernel/latencytop.c +++ b/kernel/latencytop.c

[Intel-gfx] [patch V2 11/29] fault-inject: Simplify stacktrace retrieval

Replace the indirection through struct stack_trace with an invocation of the storage array based interface. Signed-off-by: Thomas Gleixner Cc: Akinobu Mita --- lib/fault-inject.c | 12 +++- 1 file changed, 3 insertions(+), 9 deletions(-) --- a/lib/fault-inject.c +++ b/lib/fault

[Intel-gfx] [patch V2 24/29] tracing: Remove the last struct stack_trace usage

Simplify the stack retrieval code by using the storage array based interface. Signed-off-by: Thomas Gleixner --- kernel/trace/trace_stack.c | 42 -- 1 file changed, 16 insertions(+), 26 deletions(-) --- a/kernel/trace/trace_stack.c +++ b/kernel/trace

[Intel-gfx] [patch V2 09/29] mm/kasan: Simplify stacktrace handling

Replace the indirection through struct stack_trace by using the storage array based interfaces. Signed-off-by: Thomas Gleixner Acked-by: Dmitry Vyukov Cc: Andrey Ryabinin Cc: Alexander Potapenko Cc: kasan-...@googlegroups.com Cc: linux...@kvack.org --- mm/kasan/common.c | 30

[Intel-gfx] [patch V2 08/29] mm/kmemleak: Simplify stacktrace handling

Replace the indirection through struct stack_trace by using the storage array based interfaces. Signed-off-by: Thomas Gleixner Cc: Catalin Marinas Cc: linux...@kvack.org --- mm/kmemleak.c | 24 +++- 1 file changed, 3 insertions(+), 21 deletions(-) --- a/mm/kmemleak.c

[Intel-gfx] [patch V2 20/29] tracing: Simplify stacktrace retrieval in histograms

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 --- kernel/trace/trace_events_hist.c | 12 +++- 1 file changed, 3 insertions(+), 9 deletions(-) --- a/kernel/trace

[Intel-gfx] [patch V2 14/29] dm bufio: Simplify stack trace retrieval

Replace the indirection through struct stack_trace with an invocation of the storage array based interface. Signed-off-by: Thomas Gleixner Cc: dm-de...@redhat.com Cc: Mike Snitzer Cc: Alasdair Kergon --- drivers/md/dm-bufio.c | 15 ++- 1 file changed, 6 insertions(+), 9

[Intel-gfx] [patch V2 17/29] lockdep: Remove unused trace argument from print_circular_bug()

Signed-off-by: Thomas Gleixner --- kernel/locking/lockdep.c |9 - 1 file changed, 4 insertions(+), 5 deletions(-) --- a/kernel/locking/lockdep.c +++ b/kernel/locking/lockdep.c @@ -1522,10 +1522,9 @@ static inline int class_equal(struct loc } static noinline int

[Intel-gfx] [patch V2 25/29] livepatch: Simplify stack trace retrieval

Replace the indirection through struct stack_trace by using the storage array based interfaces. Signed-off-by: Thomas Gleixner --- kernel/livepatch/transition.c | 22 +- 1 file changed, 9 insertions(+), 13 deletions(-) --- a/kernel/livepatch/transition.c +++ b/kernel

[Intel-gfx] [patch V2 10/29] mm/page_owner: Simplify stack trace handling

pointer in the stack_trace struct so it points to the depot storage. Signed-off-by: Thomas Gleixner Cc: linux...@kvack.org Cc: Mike Rapoport Cc: David Rientjes Cc: Andrew Morton --- mm/page_owner.c | 79 +++- 1 file changed, 28 insertions

[Intel-gfx] [patch V2 07/29] mm/slub: Simplify stack trace retrieval

Replace the indirection through struct stack_trace with an invocation of the storage array based interface. Signed-off-by: Thomas Gleixner Cc: Andrew Morton Cc: Pekka Enberg Cc: linux...@kvack.org Cc: David Rientjes Cc: Christoph Lameter --- mm/slub.c | 12 1 file changed, 4

[Intel-gfx] [patch V2 21/29] tracing: Use percpu stack trace buffer more intelligently

execution pathes. Signed-off-by: Thomas Gleixner Cc: Steven Rostedt --- kernel/trace/trace.c | 77 +-- 1 file changed, 39 insertions(+), 38 deletions(-) --- a/kernel/trace/trace.c +++ b/kernel/trace/trace.c @@ -2749,12 +2749,21 @@ trace_function

[Intel-gfx] [patch V2 04/29] backtrace-test: Simplify stack trace handling

Replace the indirection through struct stack_trace by using the storage array based interfaces. Signed-off-by: Thomas Gleixner --- kernel/backtracetest.c | 11 +++ 1 file changed, 3 insertions(+), 8 deletions(-) --- a/kernel/backtracetest.c +++ b/kernel/backtracetest.c @@ -48,19

[Intel-gfx] [patch V2 15/29] dm persistent data: Simplify stack trace handling

Replace the indirection through struct stack_trace with an invocation of the storage array based interface. This results in less storage space and indirection. Signed-off-by: Thomas Gleixner Cc: dm-de...@redhat.com Cc: Mike Snitzer Cc: Alasdair Kergon --- drivers/md/persistent-data/dm-block

[Intel-gfx] [patch V2 18/29] lockdep: Move stack trace logic into check_prev_add()

. The comment there does not make sense either. It's all leftovers from historical lockdep code (cross release). Move the variable into check_prev_add() itself and cleanup the nonsensical checks and the pointless stack trace recording. Signed-off-by: Thomas Gleixner --- kernel/locking/lockdep.c | 30

[Intel-gfx] [patch V2 03/29] lib/stackdepot: Provide functions which operate on plain storage arrays

The struct stack_trace indirection in the stack depot functions is a truly pointless excercise which requires horrible code at the callsites. Provide interfaces based on plain storage arrays. Signed-off-by: Thomas Gleixner Acked-by: Alexander Potapenko --- include/linux/stackdepot.h |4

Re: [Intel-gfx] [patch V2 09/29] mm/kasan: Simplify stacktrace handling

On Thu, 18 Apr 2019, Andrey Ryabinin wrote: > On 4/18/19 11:41 AM, Thomas Gleixner wrote: > > Replace the indirection through struct stack_trace by using the storage > > array based interfaces. > > > > Signed-off-by: Thomas Gleixner > > Acked-by: Dmitry Vyukov

Re: [Intel-gfx] [patch V2 14/29] dm bufio: Simplify stack trace retrieval

On Thu, 18 Apr 2019, Alexander Potapenko wrote: > On Thu, Apr 18, 2019 at 11:06 AM Thomas Gleixner wrote: > > - save_stack_trace(>stack_trace); > > + b->stack_len = stack_trace_save(b->stack_entries, MAX_STACK, 2); > As noted in one of similar patches be

Re: [Intel-gfx] [patch V2 28/29] stacktrace: Provide common infrastructure

On Thu, 18 Apr 2019, Mike Rapoport wrote: > On Thu, Apr 18, 2019 at 10:41:47AM +0200, Thomas Gleixner wrote: > > +/** > > + * arch_stack_walk - Architecture specific function to walk the stack > > + > > Nit: no '*' at line beginning makes kernel-doc unhappy Oo

Re: [Intel-gfx] [patch V2 03/29] lib/stackdepot: Provide functions which operate on plain storage arrays

On Thu, 18 Apr 2019, Mike Rapoport wrote: > On Thu, Apr 18, 2019 at 10:41:22AM +0200, Thomas Gleixner wrote: > > > > -void depot_fetch_stack(depot_stack_handle_t handle, struct stack_trace > > *trace) > > +/** > > + * stack_depot_fetch - Fetch stack entries from

Re: [Intel-gfx] [patch V2 01/29] tracing: Cleanup stack trace code

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 stores at max array size - 1 entries so there is still >

Re: [Intel-gfx] [patch V2 01/29] tracing: Cleanup stack trace code

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 > >void __user *buffer, size_t *lenp, > >loff_t *ppos) > >

Re: [Intel-gfx] [patch V2 28/29] stacktrace: Provide common infrastructure

On Fri, 19 Apr 2019, Peter Zijlstra wrote: > On Thu, Apr 18, 2019 at 10:41:47AM +0200, Thomas Gleixner wrote: > > > +typedef bool (*stack_trace_consume_fn)(void *cookie, unsigned long addr, > > + bool reliable); > >

Re: [Intel-gfx] [patch V2 28/29] stacktrace: Provide common infrastructure

On Thu, 18 Apr 2019, Josh Poimboeuf wrote: > On Thu, Apr 18, 2019 at 10:41:47AM +0200, Thomas Gleixner wrote: > > All architectures which support stacktrace carry duplicated code and > > do the stack storage and filtering at the architecture side. > > > > Provi

Re: [Intel-gfx] [patch V2 21/29] tracing: Use percpu stack trace buffer more intelligently

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); > > +/* This allows 8 level nesting which is plenty */ > > Can we make this 4 level nesting and increase

Re: [Intel-gfx] [patch V2 18/29] lockdep: Move stack trace logic into check_prev_add()

On Wed, 24 Apr 2019, Peter Zijlstra wrote: > On Thu, Apr 18, 2019 at 10:41:37AM +0200, Thomas Gleixner wrote: > > There is only one caller of check_prev_add() which hands in a zeroed struct > > stack trace and a function pointer to save_stack(). Inside check_prev_add() > > t

[Intel-gfx] [patch V3 29/29] x86/stacktrace: Use common infrastructure

Replace the stack_trace_save*() functions with the new arch_stack_walk() interfaces. Signed-off-by: Thomas Gleixner Cc: linux-a...@vger.kernel.org --- arch/x86/Kconfig |1 arch/x86/kernel/stacktrace.c | 116 +++ 2 files changed, 20

[Intel-gfx] [patch V3 17/29] lockdep: Remove unused trace argument from print_circular_bug()

Signed-off-by: Thomas Gleixner --- kernel/locking/lockdep.c |9 - 1 file changed, 4 insertions(+), 5 deletions(-) --- a/kernel/locking/lockdep.c +++ b/kernel/locking/lockdep.c @@ -1522,10 +1522,9 @@ static inline int class_equal(struct loc } static noinline int

[Intel-gfx] [patch V3 24/29] tracing: Remove the last struct stack_trace usage

Simplify the stack retrieval code by using the storage array based interface. Signed-off-by: Thomas Gleixner Reviewed-by: Steven Rostedt (VMware) --- kernel/trace/trace_stack.c | 37 - 1 file changed, 16 insertions(+), 21 deletions(-) --- a/kernel/trace

[Intel-gfx] [patch V3 04/29] backtrace-test: Simplify stack trace handling

Replace the indirection through struct stack_trace by using the storage array based interfaces. Signed-off-by: Thomas Gleixner --- kernel/backtracetest.c | 11 +++ 1 file changed, 3 insertions(+), 8 deletions(-) --- a/kernel/backtracetest.c +++ b/kernel/backtracetest.c @@ -48,19

[Intel-gfx] [patch V3 28/29] stacktrace: Provide common infrastructure

of duplicated code and allows to implement better filtering than 'skip number of entries' in the future without touching any architecture specific code. Signed-off-by: Thomas Gleixner Cc: linux-a...@vger.kernel.org --- V3: Fix kernel doc --- include/linux/stacktrace.h | 39 ++ kernel

[Intel-gfx] [patch V3 23/29] tracing: Simplify stack trace retrieval

Replace the indirection through struct stack_trace by using the storage array based interfaces. Signed-off-by: Thomas Gleixner Reviewed-by: Steven Rostedt (VMware) --- kernel/trace/trace.c | 40 +--- 1 file changed, 13 insertions(+), 27 deletions

[Intel-gfx] [patch V3 09/29] mm/kasan: Simplify stacktrace handling

Replace the indirection through struct stack_trace by using the storage array based interfaces. Signed-off-by: Thomas Gleixner Acked-by: Dmitry Vyukov Acked-by: Andrey Ryabinin Cc: Alexander Potapenko Cc: kasan-...@googlegroups.com Cc: linux...@kvack.org --- mm/kasan/common.c | 30

[Intel-gfx] [patch V3 20/29] tracing: Simplify stacktrace retrieval in histograms

The indirection through struct stack_trace is not necessary at all. Use the storage array based interface. Signed-off-by: Thomas Gleixner Tested-by: Tom Zanussi Reviewed-by: Tom Zanussi Acked-by: Steven Rostedt (VMware) --- kernel/trace/trace_events_hist.c | 12 +++- 1 file changed

[Intel-gfx] [patch V3 25/29] livepatch: Simplify stack trace retrieval

Replace the indirection through struct stack_trace by using the storage array based interfaces. Signed-off-by: Thomas Gleixner Acked-by: Miroslav Benes --- kernel/livepatch/transition.c | 22 +- 1 file changed, 9 insertions(+), 13 deletions(-) --- a/kernel/livepatch

[Intel-gfx] [patch V3 01/29] tracing: Cleanup stack trace code

which are only used in trace_stack.c static. - Simplify the enable/disable logic. - Rename stack_trace_print() as it's using the stack_trace_ namespace. Free the name up for stack trace related functions. Signed-off-by: Thomas Gleixner Reviewed-by: Steven Rostedt --- V3: Remove the -1 init

[Intel-gfx] [patch V3 10/29] mm/page_owner: Simplify stack trace handling

pointer in the stack_trace struct so it points to the depot storage. Signed-off-by: Thomas Gleixner Cc: linux...@kvack.org Cc: Mike Rapoport Cc: David Rientjes Cc: Andrew Morton --- mm/page_owner.c | 79 +++- 1 file changed, 28 insertions

[Intel-gfx] [patch V3 06/29] latency_top: Simplify stack trace handling

Replace the indirection through struct stack_trace with an invocation of the storage array based interface. Signed-off-by: Thomas Gleixner --- kernel/latencytop.c | 17 ++--- 1 file changed, 2 insertions(+), 15 deletions(-) --- a/kernel/latencytop.c +++ b/kernel/latencytop.c

[Intel-gfx] [patch V3 18/29] lockdep: Remove save argument from check_prev_add()

There is only one caller which hands in save_trace as function pointer. Signed-off-by: Thomas Gleixner --- kernel/locking/lockdep.c | 16 1 file changed, 8 insertions(+), 8 deletions(-) --- a/kernel/locking/lockdep.c +++ b/kernel/locking/lockdep.c @@ -2158,8 +2158,7

[Intel-gfx] [patch V3 15/29] dm persistent data: Simplify stack trace handling

Replace the indirection through struct stack_trace with an invocation of the storage array based interface. This results in less storage space and indirection. Signed-off-by: Thomas Gleixner Cc: dm-de...@redhat.com Cc: Mike Snitzer Cc: Alasdair Kergon --- drivers/md/persistent-data/dm-block

[Intel-gfx] [patch V3 26/29] stacktrace: Remove obsolete functions

No more users of the struct stack_trace based interfaces. Remove them. Remove the macro stubs for !CONFIG_STACKTRACE as well as they are pointless because the storage on the call sites is conditional on CONFIG_STACKTRACE already. No point to be 'smart'. Signed-off-by: Thomas Gleixner

[Intel-gfx] [patch V3 19/29] lockdep: Simplify stack trace handling

Replace the indirection through struct stack_trace by using the storage array based interfaces and storing the information is a small lockdep specific data structure. Signed-off-by: Thomas Gleixner Acked-by: Peter Zijlstra (Intel) --- include/linux/lockdep.h |9 +-- kernel/locking

[Intel-gfx] [patch V3 13/29] btrfs: ref-verify: Simplify stack trace retrieval

Replace the indirection through struct stack_trace with an invocation of the storage array based interface. Signed-off-by: Thomas Gleixner Reviewed-by: Johannes Thumshirn Acked-by: David Sterba Cc: Chris Mason Cc: Josef Bacik Cc: linux-bt...@vger.kernel.org --- fs/btrfs/ref-verify.c | 15

[Intel-gfx] [patch V3 02/29] stacktrace: Provide helpers for common stack trace operations

use cases a storage array and the number of valid stack trace entries in the array is sufficient. Provide helper functions which avoid the struct stack_trace indirection so the usage sites can be cleaned up. Signed-off-by: Thomas Gleixner --- V3: Fix kernel doc. --- include/linux/stacktrace.h

[Intel-gfx] [patch V3 27/29] lib/stackdepot: Remove obsolete functions

No more users of the struct stack_trace based interfaces. Signed-off-by: Thomas Gleixner Acked-by: Alexander Potapenko --- include/linux/stackdepot.h |4 lib/stackdepot.c | 20 2 files changed, 24 deletions(-) --- a/include/linux/stackdepot.h +++ b

[Intel-gfx] [patch V3 16/29] drm: Simplify stacktrace handling

pointer in the stack_trace struct so it points to the depot storage. Signed-off-by: Thomas Gleixner Acked-by: Daniel Vetter Cc: intel-gfx@lists.freedesktop.org Cc: Joonas Lahtinen Cc: Maarten Lankhorst Cc: dri-de...@lists.freedesktop.org Cc: David Airlie Cc: Jani Nikula Cc: Rodrigo Vivi

[Intel-gfx] [patch V3 08/29] mm/kmemleak: Simplify stacktrace handling

Replace the indirection through struct stack_trace by using the storage array based interfaces. Signed-off-by: Thomas Gleixner Acked-by: Catalin Marinas Cc: linux...@kvack.org --- mm/kmemleak.c | 24 +++- 1 file changed, 3 insertions(+), 21 deletions(-) --- a/mm

[Intel-gfx] [patch V3 12/29] dma/debug: Simplify stracktrace retrieval

Replace the indirection through struct stack_trace with an invocation of the storage array based interface. Signed-off-by: Thomas Gleixner Reviewed-by: Christoph Hellwig Cc: io...@lists.linux-foundation.org Cc: Robin Murphy Cc: Marek Szyprowski --- kernel/dma/debug.c | 14 ++ 1

[Intel-gfx] [patch V3 07/29] mm/slub: Simplify stack trace retrieval

Replace the indirection through struct stack_trace with an invocation of the storage array based interface. Signed-off-by: Thomas Gleixner Acked-by: Christoph Lameter Cc: Andrew Morton Cc: Pekka Enberg Cc: linux...@kvack.org Cc: David Rientjes --- mm/slub.c | 12 1 file

[Intel-gfx] [patch V3 05/29] proc: Simplify task stack retrieval

Replace the indirection through struct stack_trace with an invocation of the storage array based interface. Signed-off-by: Thomas Gleixner Reviewed-by: Alexey Dobriyan Cc: Andrew Morton --- fs/proc/base.c | 14 +- 1 file changed, 5 insertions(+), 9 deletions(-) --- a/fs/proc

[Intel-gfx] [patch V3 11/29] fault-inject: Simplify stacktrace retrieval

Replace the indirection through struct stack_trace with an invocation of the storage array based interface. Signed-off-by: Thomas Gleixner Cc: Akinobu Mita --- lib/fault-inject.c | 12 +++- 1 file changed, 3 insertions(+), 9 deletions(-) --- a/lib/fault-inject.c +++ b/lib/fault

[Intel-gfx] [patch V3 03/29] lib/stackdepot: Provide functions which operate on plain storage arrays

The struct stack_trace indirection in the stack depot functions is a truly pointless excercise which requires horrible code at the callsites. Provide interfaces based on plain storage arrays. Signed-off-by: Thomas Gleixner Acked-by: Alexander Potapenko --- V3: Fix kernel-doc --- include/linux

[Intel-gfx] [patch V3 00/29] stacktrace: Consolidate stack trace usage

This is an update to V2 which can be found here: https://lkml.kernel.org/r/20190418084119.056416...@linutronix.de Changes vs. V2: - Fixed the kernel-doc issue pointed out by Mike - Removed the '-1' oddity from the tracer - Restricted the tracer nesting to 4 - Restored the lockdep

[Intel-gfx] [patch V3 14/29] dm bufio: Simplify stack trace retrieval

Replace the indirection through struct stack_trace with an invocation of the storage array based interface. Signed-off-by: Thomas Gleixner Cc: dm-de...@redhat.com Cc: Mike Snitzer Cc: Alasdair Kergon --- drivers/md/dm-bufio.c | 15 ++- 1 file changed, 6 insertions(+), 9

[Intel-gfx] [patch V3 21/29] tracing: Use percpu stack trace buffer more intelligently

with the conditional execution pathes. Signed-off-by: Thomas Gleixner Cc: Steven Rostedt --- V3: Limit to 4 nest levels and increase size per level. --- kernel/trace/trace.c | 77 +-- 1 file changed, 39 insertions(+), 38 deletions(-) --- a/kernel/trace/trace.c

  1   2   3   >