On Thu, 13 Jun 2019, Ricardo Neri wrote:
> On Tue, Jun 11, 2019 at 09:54:25PM +0200, Thomas Gleixner wrote:
> > On Thu, 23 May 2019, Ricardo Neri wrote:
> >
> > > HPET timer 2 will be used to drive the HPET-based hardlockup detector.
> > > Reserve such timer to
On Fri, 14 Jun 2019, Thomas Gleixner wrote:
> On Thu, 23 May 2019, Ricardo Neri wrote:
> > int hpet_alloc(struct hpet_data *hdp)
> > {
> > u64 cap, mcfg;
> > @@ -844,7 +867,6 @@ int hpet_alloc(struct hpet_data *hdp)
> > struct hpets *hpetp;
On Thu, 23 May 2019, Ricardo Neri wrote:
>
> +u64 hpet_get_ticks_per_sec(u64 hpet_caps)
> +{
> + u64 ticks_per_sec, period;
> +
> + period = (hpet_caps & HPET_COUNTER_CLK_PERIOD_MASK) >>
> + HPET_COUNTER_CLK_PERIOD_SHIFT; /* fs, 10^-15 */
> +
> + /*
> + * The frequen
On Thu, 23 May 2019, Ricardo Neri wrote:
> @@ -52,10 +59,10 @@ static void kick_timer(struct hpet_hld_data *hdata, bool
> force)
> return;
>
> if (hdata->has_periodic)
> - period = watchdog_thresh * hdata->ticks_per_second;
> + period = watchdog_thresh
On Thu, 23 May 2019, Ricardo Neri wrote:
> HPET timer 2 will be used to drive the HPET-based hardlockup detector.
> Reserve such timer to ensure it cannot be used by user space programs or
> for clock events.
>
> When looking for MSI-capable timers for clock events, skip timer 2 if
> the HPET har
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(-)
--- a
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
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
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
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
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: Thoma
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
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
pointer in the stack_trace
struct so it points to the depot storage.
Signed-off-by: Thomas Gleixner
Acked-by: Daniel Vetter
Cc: intel-...@lists.freedesktop.org
Cc: Joonas Lahtinen
Cc: Maarten Lankhorst
Cc: dri-de...@lists.freedesktop.org
Cc: David Airlie
Cc: Jani Nikula
Cc: Rodrigo Vivi
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 ini
r all 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/stacktr
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
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
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
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
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
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
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
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
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
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
Reviewed-by: Steven Rostedt
---
kernel/trace/trace.c | 14 --
kernel/trace/trace.h |8
2 files chang
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
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
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
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
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: iommu@lists.linux-foundation.org
Cc: Robin Murphy
Cc: Marek Szyprowski
---
kernel/dma/debug.c | 14 ++
1
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
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
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
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 ma
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
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);
>
>
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)
> >
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
On Thu, 18 Apr 2019, Julien Grall wrote:
> When an MSI doorbell is located downstream of an IOMMU, it is required
> to swizzle the physical address with an appropriately-mapped IOVA for any
> device attached to one of our DMA ops domain.
>
> At the moment, the allocation of the mapping may be don
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
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.
> >
> > Provide a co
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
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 u
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_trace);
> > + b->stack_len = stack_trace_save(b->stack_entries, MAX_STACK, 2);
> As noted in one of similar patche
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
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 inser
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
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: Thoma
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
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
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
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
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 |
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
pointer in the stack_trace
struct so it points to the depot storage.
Signed-off-by: Thomas Gleixner
Cc: intel-...@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
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
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
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
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
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
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
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
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
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
Replace the indirection through struct stack_trace with an invocation of
the storage array based interface.
Signed-off-by: Thomas Gleixner
Cc: iommu@lists.linux-foundation.org
Cc: Robin Murphy
Cc: Christoph Hellwig
Cc: Marek Szyprowski
---
kernel/dma/debug.c | 13 +
1 file
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
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
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
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 ove
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
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
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
print() 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 --
ke
r all 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 +++
k
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
On Wed, 17 Apr 2019, Linus Torvalds wrote:
> On Wed, Apr 17, 2019 at 4:42 PM Thomas Gleixner wrote:
> > On Wed, 17 Apr 2019, Linus Torvalds wrote:
> > > With SMEP, user space pages are always NX.
> >
> > We talk past each other. The user space page in the ring3 v
On Wed, 17 Apr 2019, Linus Torvalds wrote:
> On Wed, Apr 17, 2019, 14:20 Thomas Gleixner wrote:
>
> >
> > It's not necessarily a W+X issue. The user space text is mapped in the
> > kernel as well and even if it is mapped RX then this can happen. So any
> >
On Wed, 17 Apr 2019, Nadav Amit wrote:
> > On Apr 17, 2019, at 10:26 AM, Ingo Molnar wrote:
> >> As I was curious, I looked at the paper. Here is a quote from it:
> >>
> >> "In x86-64, however, the permissions of physmap are not in sane state.
> >> Kernels up to v3.8.13 violate the W^X property b
On Wed, 10 Apr 2019, Christoph Hellwig wrote:
> On Wed, Apr 10, 2019 at 12:28:22PM +0200, Thomas Gleixner wrote:
> > Replace the indirection through struct stack_trace with an invocation of
> > the storage array based interface.
>
> This seems to be missing s
Replace the indirection through struct stack_trace with an invocation of
the storage array based interface.
Signed-off-by: Thomas Gleixner
Cc: iommu@lists.linux-foundation.org
Cc: Robin Murphy
Cc: Christoph Hellwig
Cc: Marek Szyprowski
---
kernel/dma/debug.c | 13 +
1 file
On Mon, 8 Apr 2019, Leizhen (ThunderTown) wrote:
> >
> > This will break systems using boot options as now, and I think
> > this is unacceptable. If you want to do so, just introduce iommu.dma_mode
> > on top of those iommu boot options with dma mode boot options unchanged,
> > and iommu.dma_mode
On Thu, 4 Apr 2019, Khalid Aziz wrote:
> When xpfo unmaps a page from physmap only (after mapping the page in
> userspace in response to an allocation request from userspace) on one
> processor, there is a small window of opportunity for ret2dir attack on
> other cpus until the TLB entry in physmap
On Thu, 4 Apr 2019, Tycho Andersen wrote:
> leaq-PTREGS_SIZE(%rax), %rsp
> UNWIND_HINT_FUNC sp_offset=PTREGS_SIZE
>
> + /*
> + * If we oopsed in an interrupt handler, interrupts may be off. Let's
> turn
> + * them back on before going back to "normal" code.
> +
your DMA tree.
Reviewed-by: Thomas Gleixner
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
O-APIC irqs have
> 8-bit APIC id.
This looks good now. Can that be applied independent of the IOMMU stuff or
should this go together. If the latter:
Reviewed-by: Thomas Gleixner
If not, I just queue if for 5.1. Let me know,
Thanks,
tglx
___
#x27;iommu=leak' parameter, which controlled nothing except whether
> dma_debug_resize_entries() was called or not.
>
> CC: Thomas Gleixner
> CC: Ingo Molnar
> CC: Borislav Petkov
> CC: "H. Peter Anvin"
> CC: x...@kernel.
On Tue, 16 Oct 2018, tedheadster wrote:
> On Sun, Oct 14, 2018 at 3:52 AM Christoph Hellwig wrote:
> >
> > We already build the swiotlb code for 32b-t kernels with PAE support,
> > but the code to actually use swiotlb has only been enabled for 64-bit
> > kernel for an unknown reason.
> >
> > Befor
On Sun, 14 Oct 2018, Christoph Hellwig wrote:
> On Sun, Oct 14, 2018 at 10:13:31AM +0200, Thomas Gleixner wrote:
> > On Sun, 14 Oct 2018, Christoph Hellwig wrote:
> >
> > > We already build the swiotlb code for 32b-t kernels with PAE support,
> > > but the code
On Sun, 14 Oct 2018, Christoph Hellwig wrote:
> We already build the swiotlb code for 32b-t kernels with PAE support,
> but the code to actually use swiotlb has only been enabled for 64-bit
> kernel for an unknown reason.
>
> Before Linux 4.18 we papers over this fact because the networking code,
On Mon, 30 Jul 2018, Christoph Hellwig wrote:
> There is nothing arch specific about PCI or dma-debug, so move this
> call to common code just after registering the bus type.
>
> Signed-off-by: Christoph Hellwig
Acked-by: Thomas Gleixner
_
On Tue, 19 Jun 2018, Ricardo Neri wrote:
> On Sat, Jun 16, 2018 at 03:24:49PM +0200, Thomas Gleixner wrote:
> > The status register is useless in case of MSI. MSI is edge triggered
> >
> > The only register which gives you proper information is the counter
> > re
On Fri, 15 Jun 2018, Ricardo Neri wrote:
> On Fri, Jun 15, 2018 at 09:01:02AM +0100, Julien Thierry wrote:
> > In my patches, I'm not sure there is much to adapt to your work as most of
> > it is arch specific (although I wont say no to another pair of eyes looking
> > at them). From what I've seen
On Fri, 15 Jun 2018, Ricardo Neri wrote:
> On Fri, Jun 15, 2018 at 12:29:06PM +0200, Thomas Gleixner wrote:
> > You have to consider two cases:
> >
> > 1) !remapped mode:
> >
> > That's reasonably simple because you just have to deal with the HPET
>
On Fri, 15 Jun 2018, Ricardo Neri wrote:
> On Fri, Jun 15, 2018 at 11:19:09AM +0200, Thomas Gleixner wrote:
> > On Thu, 14 Jun 2018, Ricardo Neri wrote:
> > > Alternatively, there could be a counter that skips reading the HPET status
> > > register (and the detection
On Thu, 14 Jun 2018, Ricardo Neri wrote:
> On Wed, Jun 13, 2018 at 11:48:09AM +0200, Thomas Gleixner wrote:
> > On Tue, 12 Jun 2018, Ricardo Neri wrote:
> > > + /* There are no CPUs to monitor. */
> > > + if (!cpumask_weight(&hdata->monitored_mask))
On Thu, 14 Jun 2018, Ricardo Neri wrote:
> On Wed, Jun 13, 2018 at 11:40:00AM +0200, Thomas Gleixner wrote:
> > On Tue, 12 Jun 2018, Ricardo Neri wrote:
> > > @@ -183,6 +184,8 @@ static irqreturn_t
> > > hardlockup_detector_irq_handler(int irq, void *data)
On Thu, 14 Jun 2018, Nicholas Piggin wrote:
> On Wed, 13 Jun 2018 18:31:17 -0700
> > I could look into creating the library for
> > common code and relocate the hpet watchdog into arch/x86 for the hpet-
> > specific parts.
>
> If you can investigate that approach, that would be appreciated. I hope
On Wed, 13 Jun 2018, Julien Thierry wrote:
> On 13/06/18 10:20, Thomas Gleixner wrote:
> > Adding NMI delivery support at low level architecture irq chip level is
> > perfectly fine, but the exposure of that needs to be restricted very
> > much. Adding it to the gene
On Tue, 12 Jun 2018, Ricardo Neri wrote:
> + /* There are no CPUs to monitor. */
> + if (!cpumask_weight(&hdata->monitored_mask))
> + return NMI_HANDLED;
> +
> inspect_for_hardlockups(regs);
>
> + /*
> + * Target a new CPU. Keep trying until we find a monitored
401 - 500 of 584 matches
Mail list logo
