Requesting page reqest irq under dmar_global_lock could cause
potential lock race condition (caught by lockdep).
[4.100055] ==
[4.100063] WARNING: possible circular locking dependency detected
[4.100072] 5.1.0-rc4+ #2169 Not tainted
[
On Fri, Apr 19, 2019 at 5:55 AM Bjorn Andersson
wrote:
>
> On Mon 15 Apr 10:37 PDT 2019, Vivek Gautam wrote:
>
> > Bits[15:0] in CBFRSYNRA register contain information about
> > StreamID of the incoming transaction that generated the
> > fault. Dump CBFRSYNRA register to get this info.
> > This is
On Thu, 18 Apr 2019 16:36:02 +0100
Jean-Philippe Brucker wrote:
> On 16/04/2019 00:10, Jacob Pan wrote:[...]
> >> > + /*
> >> > + * Register a custom ASID allocator if we
> >> > are running
> >> > + * in a guest, the purpose is to have a
> >
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
> > > void __user *buffer, size
On Mon 15 Apr 10:37 PDT 2019, Vivek Gautam wrote:
> Bits[15:0] in CBFRSYNRA register contain information about
> StreamID of the incoming transaction that generated the
> fault. Dump CBFRSYNRA register to get this info.
> This is specially useful in a distributed SMMU architecture
> where multiple
On Fri, Apr 12, 2019 at 08:43:33AM +0530, Srinath Mannam wrote:
> Add a dma_ranges field in PCI host bridge structure to hold resource
> entries list of memory regions in sorted order given through dma-ranges
> DT property.
>
> While initializing IOMMU domain of PCI EPs connected to that host brid
[+cc Scott]
On Fri, Apr 12, 2019 at 08:43:32AM +0530, Srinath Mannam wrote:
> Few SOCs have limitation that their PCIe host can't allow few inbound
> address ranges. Allowed inbound address ranges are listed in dma-ranges
> DT property and this address ranges are required to do IOVA mapping.
> Rem
On Tue, Apr 16, 2019 at 05:28:36PM +0530, Srinath Mannam wrote:
> On Sat, Apr 13, 2019 at 4:04 AM Bjorn Helgaas wrote:
> > On Fri, Apr 12, 2019 at 08:43:32AM +0530, Srinath Mannam wrote:
> > > Few SOCs have limitation that their PCIe host can't allow few inbound
> > > address ranges. Allowed inbou
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)
> > {
> > - int ret;
> > + int
Hi Steve,
On Thu, 2019-04-18 at 16:13 -0400, Steven Rostedt wrote:
> 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
On Thu, 2019-04-18 at 09:40 -0400, Steven Rostedt wrote:
> [ 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
Make use of the struct_size() helper instead of an open-coded version
in order to avoid any potential type mistakes, in particular in the
context in which this code is being used.
So, replace code of the following form:
size = sizeof(*info) + level * sizeof(info->path[0]);
with:
size = struct_s
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)
> {
> - int ret;
> + int ret, was_enabled;
One small nit. Could this be:
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 max_entries and set SET_TRACE_ENTRIE
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, 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
> > an empty slot.
>
> What
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
___
iommu mailing list
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
The fallback to the GART driver in the case amd_iommu doesn't work was
executed in a function called free_iommu_resources, which didn't really
make sense. This was even being called twice if amd_iommu=off was
specified on the command line.
The only complication is that it needs to be verified that
Make it safe to call iommu_disable during early init error conditions
before mmio_base is set, but after the struct amd_iommu has been added
to the amd_iommu_list. For example, this happens if firmware fails to
fill in mmio_phys in the ACPI table leading to a NULL pointer
dereference in iommu_featu
When amd_iommu=off was specified on the command line, free_X_resources
functions were called immediately after early_amd_iommu_init. They were
then called again when amd_iommu_init also failed (as expected).
Instead, call them only once: at the end of state_next() whenever
there's an error. These
This series makes error handling more robust in the amd_iommu init
code. It was initially motivated by problematic firmware that does not
set up the physical address of the iommu. This led to a NULL dereference
panic when iommu_disable was called during cleanup.
While the first patch is sufficient
On 18/04/2019 17:35, Christoph Hellwig wrote:
On Thu, Apr 18, 2019 at 04:06:56PM +0100, Robin Murphy wrote:
OK, I'm still looking at mmap and get_sgtable, but for now I've pushed out
a partial branch that consolidates alloc and free in a way which makes
sense to me:
git://linux-arm.org/linux
The functions mbi_compose_m{b, s}i_msg may be called from non-preemptible
context. However, on RT, iommu_dma_map_msi_msg requires to be called
from a preemptible context.
A recent patch split the function iommu_dma_map_msi_msg in 2 functions:
one that should be called in preemptible context, the o
A recent patch introduced two new functions to replace
iommu_dma_map_msi_msg() to avoid executing preemptible code in
non-preemptible context.
All the existings callers are now using the two new functions, so
iommu_dma_map_msi_msg() can be removed.
Signed-off-by: Julien Grall
---
drivers/iommu/
The function gicv2m_compose_msi_msg may be called from non-preemptible
context. However, on RT, iommu_dma_map_msi_msg requires to be called
from a preemptible context.
A recent patch split the function iommu_dma_map_msi_msg in 2 functions:
one that should be called in preemptible context, the othe
On RT, the function iommu_dma_map_msi_msg may be called from
non-preemptible context. This will lead to a splat with
CONFIG_DEBUG_ATOMIC_SLEEP as the function is using spin_lock
(they can sleep on RT).
The function iommu_dma_map_msi_msg is used to map the MSI page in the
IOMMU PT and update the MS
The function its_irq_compose_msi_msg may be called from non-preemptible
context. However, on RT, iommu_dma_map_msi_msg requires to be called
from a preemptible context.
A recent patch split the function iommu_dma_map_msi_msg in 2 functions:
one that should be called in preemptible context, the oth
The function ls_scfg_msi_compose_msg may be called from non-preemptible
context. However, on RT, iommu_dma_map_msi_msg requires to be called
from a preemptible context.
A recent patch split the function iommu_dma_map_msi_msg in 2 functions:
one that should be called in preemptible context, the oth
Hi all,
On RT, the function iommu_dma_map_msi_msg expects to be called from preemptible
context. However, this is not always the case resulting a splat with
!CONFIG_DEBUG_ATOMIC_SLEEP:
[ 48.875777] BUG: sleeping function called from invalid context at
kernel/locking/rtmutex.c:974
[ 48.875779
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 done when composing
the message. However, the composing
On 18/04/2019 17:35, Christoph Hellwig wrote:
On Thu, Apr 18, 2019 at 04:06:56PM +0100, Robin Murphy wrote:
OK, I'm still looking at mmap and get_sgtable, but for now I've pushed out
a partial branch that consolidates alloc and free in a way which makes
sense to me:
git://linux-arm.org/linux
On Thu, Apr 18, 2019 at 04:06:56PM +0100, Robin Murphy wrote:
> OK, I'm still looking at mmap and get_sgtable, but for now I've pushed out
> a partial branch that consolidates alloc and free in a way which makes
> sense to me:
>
> git://linux-arm.org/linux-rm dma/rework
>
> Please let me know
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);
> > > +/* This allows 8 level nesting which is plenty
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 the size? (I can see us
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 consolidated interface with a c
On 16/04/2019 00:10, Jacob Pan wrote:[...]
>> > + /*
>> > + * Register a custom ASID allocator if we
>> > are running
>> > + * in a guest, the purpose is to have a
>> > system wide PASID
>> > + * namespace among all PASID us
On Thu, Apr 18, 2019 at 10:41:27AM +0200, Thomas Gleixner wrote:
> 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
Acked-by: Catalin Marinas
_
On 17/04/2019 07:33, Christoph Hellwig wrote:
On Wed, Apr 10, 2019 at 08:11:57AM +0200, Christoph Hellwig wrote:
On Tue, Apr 09, 2019 at 06:59:32PM +0100, Robin Murphy wrote:
On 27/03/2019 08:04, Christoph Hellwig wrote:
This keeps the code together and will simplify compiling the code
out on
On Thu, 18 Apr 2019 10:41:40 +0200
Thomas Gleixner wrote:
> The per cpu stack trace buffer usage pattern is odd at best. The buffer has
> place for 512 stack trace entries on 64-bit and 1024 on 32-bit. When
> interrupts or exceptions nest after the per cpu buffer was acquired the
> stacktrace len
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 consolidated interface with a callback function for consuming the
> stack entries pro
On 4/17/19 11:41 PM, Kees Cook wrote:
> On Wed, Apr 17, 2019 at 11:41 PM Andy Lutomirski wrote:
>> I don't think this type of NX goof was ever the argument for XPFO.
>> The main argument I've heard is that a malicious user program writes a
>> ROP payload into user memory (regular anonymous user me
First, add build option IOMMU_DEFAULT_{LAZY|STRICT}, so that we have the
opportunity to set {lazy|strict} mode as default at build time. Then put
the three config options in an choice, make people can only choose one of
the three at a time.
The default IOMMU dma modes on each ARCHs have no change.
v5 --> v6:
1. give up adding boot option iommu.dma_mode
v4 --> v5:
As Hanjun and Thomas Gleixner's suggestion:
1. Keep the old ARCH specific boot options no change.
2. Keep build option CONFIG_IOMMU_DEFAULT_PASSTHROUGH no change.
v4:
As Robin Murphy's suggestion:
"It's also not necessarily obviou
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
> an empty slot.
What is the empty slot used for?
--
Josh
_
[ 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: Steven Rostedt
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
On Thu, Apr 18, 2019 at 11:06 AM Thomas Gleixner wrote:
>
> 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-
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
> Cc: Andrey Ryabinin
> Cc: Alexander Potapenko
> Cc: kasan-...@googlegroups.com
> Cc: li
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_trace);
> > > + b->stack_len = stack_trace_save(b->stack_entries, MAX_STACK, 2);
>
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 a depot
> > + *
>
> Nit: kernel-d
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
Oops.
> > + * @consume_entry: Callback
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 patches before, can we have an inline
>
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
> > Cc: Andrey Ryabinin
> > Cc: Al
On Thu, Apr 18, 2019 at 10:41:22AM +0200, Thomas Gleixner wrote:
> 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 Gleixn
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 consolidated interface with a callback function for consuming the
> stack entries pro
On Wed, Apr 17, 2019 at 07:24:42PM +0100, Jean-Philippe Brucker wrote:
> Root complex node in IORT has a bit telling whether it supports ATS or
> not. Store this bit in the IOMMU fwspec when setting up a device, so it
> can be accessed later by an IOMMU driver. In the future we'll probably
> want t
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(+),
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/livep
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
---
includ
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 ---
The per cpu stack trace buffer usage pattern is odd at best. The buffer has
place for 512 stack trace entries on 64-bit and 1024 on 32-bit. When
interrupts or exceptions nest after the per cpu buffer was acquired the
stacktrace length is hardcoded to 8 entries. 512/1024 stack trace entries
in kerne
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 insert
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()
the stack_trace struct is checked for being empty, which is always
true. Based on that one code path stores a stack trace which is unused. The
comm
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 +++
Replace the indirection through struct stack_trace by using the storage
array based interfaces.
The original code in all printing functions is really wrong. It allocates a
storage array on stack which is unused because depot_fetch_stack() does not
store anything in it. It overwrites the entries po
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/inc
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/trace
All architectures which support stacktrace carry duplicated code and
do the stack storage and filtering at the architecture side.
Provide a consolidated interface with a callback function for consuming the
stack entries provided by the architecture specific stack walker. This
removes lots of dupli
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/trace_events
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/tr
On Wed, Apr 17, 2019 at 11:41 PM Andy Lutomirski wrote:
> I don't think this type of NX goof was ever the argument for XPFO.
> The main argument I've heard is that a malicious user program writes a
> ROP payload into user memory (regular anonymous user memory) and then
> gets the kernel to erroneo
Replace the indirection through struct stack_trace by using the storage
array based interfaces.
The original code in all printing functions is really wrong. It allocates a
storage array on stack which is unused because depot_fetch_stack() does not
store anything in it. It overwrites the entries po
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 print_circular_bug
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-ma
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
@@ -1
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 chang
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 i
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-injec
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 +48,1
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 deletions
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/bas
- 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
an empty slot.
- Make variables which are only used in trace_stack.c static.
- Simplify the enable/disable logic.
- Rename stack_trace_print() a
All operations with stack traces are based on struct stack_trace. That's a
horrible construct as the struct is a kitchen sink for input and
output. Quite some usage sites embed it into their own data structures
which creates weird indirections.
There is absolutely no point in doing so. For all use
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 ++
88 matches
Mail list logo
