https://bugzilla.kernel.org/show_bug.cgi?id=204479
--- Comment #9 from Christophe Leroy (christophe.le...@c-s.fr) ---
The module loads seems to be nested. It might then be an SMP issue,
kasan_init_region() is most likely not SMP safe.
Could you test without CONFIG_SMP or with only one CPU ?
--
https://bugzilla.kernel.org/show_bug.cgi?id=204479
--- Comment #8 from Christophe Leroy (christophe.le...@c-s.fr) ---
List of allocated areas with associated kasan shadow area in [ ], together with
the addresses when shadow initialisation fails:
Aug 08 23:39:58 T600 kernel: ## module_alloc(c7
On 8/7/19 10:42 PM, Michael Ellerman wrote:
> Hi John,
>
> john.hubb...@gmail.com writes:
>> diff --git a/arch/powerpc/mm/book3s64/iommu_api.c
>> b/arch/powerpc/mm/book3s64/iommu_api.c
>> index b056cae3388b..e126193ba295 100644
>> --- a/arch/powerpc/mm/book3s64/iommu_api.c
>> +++ b/arch/powerpc/m
From: Alastair D'Silva
Similar to commit 22e9c88d486a
("powerpc/64: reuse PPC32 static inline flush_dcache_range()")
this patch converts flush_icache_range to C.
This was done as we discovered a long-standing bug where the
length of the range was truncated due to using a 32 bit shift
instead of
From: Alastair D'Silva
When calling flush_icache_range with a size >4GB, we were masking
off the upper 32 bits, so we would incorrectly flush a range smaller
than intended.
This patch replaces the 32 bit shifts with 64 bit ones, so that
the full size is accounted for.
Heads-up for backporters:
https://bugzilla.kernel.org/show_bug.cgi?id=204375
Erhard F. (erhar...@mailbox.org) changed:
What|Removed |Added
Status|NEW |RESOLVED
Resol
https://bugzilla.kernel.org/show_bug.cgi?id=204479
Erhard F. (erhar...@mailbox.org) changed:
What|Removed |Added
Attachment #284175|0 |1
is obsolete|
https://bugzilla.kernel.org/show_bug.cgi?id=204479
--- Comment #6 from Erhard F. (erhar...@mailbox.org) ---
(In reply to Christophe Leroy from comment #4)
> We need to identify if the allocation of KASAN shadow area at module
> allocation fails, or if kasan accesses outside of the allocated area.
https://bugzilla.kernel.org/show_bug.cgi?id=204479
Erhard F. (erhar...@mailbox.org) changed:
What|Removed |Added
Attachment #284177|0 |1
is obsolete|
The QBMan frame descriptor enqueuing is changed from array
mode (a single frame enqueue at a time) to bulk ring mode.
This new mode allows the enqueuing of multiple frames in one operation.
The original interface is kept but use the bulk enqueue of one frame
Signed-off-by: Youri Querry
---
dri
Hi Christophe,
On Thu, 2019-08-08 at 12:48 +, Christophe Leroy wrote:
> Santa commit ebb9d30a6a74 ("powerpc/mm: any thread in one core can be
> the first to setup TLB1") removed the need to know the cpu_id in
> early_init_this_mmu(), but the call to smp_processor_id() which was
> marked __mayb
Le mar. 30 juil. 2019 à 11:44, Madalin-cristian Bucur
a écrit :
>
> > -Original Message-
> >
> > > Le dim. 14 juil. 2019 à 22:05, Valentin Longchamp
> > > a écrit :
> > > >
> > > > Change all phy-connection-type properties to phy-mode that are better
> > > > supported by the fman driver.
CONFIG_ARCH_NO_COHERENT_DMA_MMAP is now functionally identical to
!CONFIG_MMU, so remove the separate symbol. The only difference is that
arm did not set it for !CONFIG_MMU, but arm uses a separate dma mapping
implementation including its own mmap method, which is handled by moving
the CONFIG_MMU
parisc is the only architecture that sets ARCH_NO_COHERENT_DMA_MMAP
when an MMU is enabled. AFAIK this is because parisc CPUs use VIVT
caches, which means exporting normally cachable memory to userspace is
relatively dangrous due to cache aliasing.
But normally cachable memory is only allocated b
Ther is no need to go through dma_common_mmap for the arm-nommu
dma mmap implementation as the only possible memory not handled above
could be that from the per-device coherent pool.
Signed-off-by: Christoph Hellwig
---
arch/arm/mm/dma-mapping-nommu.c | 5 +++--
1 file changed, 3 insertions(+),
Replace the local hack with the dma_can_mmap helper to check if
a given device supports mapping DMA allocations to userspace.
Signed-off-by: Christoph Hellwig
Reviewed-by: Takashi Iwai
---
sound/core/pcm_native.c | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/
Add a helper to check if DMA allocations for a specific device can be
mapped to userspace using dma_mmap_*.
Signed-off-by: Christoph Hellwig
---
include/linux/dma-mapping.h | 5 +
kernel/dma/mapping.c| 23 +++
2 files changed, 28 insertions(+)
diff --git a/inclu
While the default ->mmap and ->get_sgtable implementations work for the
majority of our dma_map_ops impementations they are inherently safe
for others that don't use the page allocator or CMA and/or use their
own way of remapping not covered by the common code. So remove the
defaults if these meth
The comments are spot on and should be near the central API, not just
near a single implementation.
Signed-off-by: Christoph Hellwig
---
arch/arm/mm/dma-mapping.c | 11 ---
kernel/dma/mapping.c | 11 +++
2 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/arch/a
Hi all,
we have a few places where the DMA mapping layer has non-trivial default
actions that are questionable and/or dangerous.
This series instead wires up the mmap, get_sgtable and get_required_mask
methods explicitly and cleans up some surrounding areas. This also means
we could get rid of t
Most dma_map_ops instances are IOMMUs that work perfectly fine in 32-bits
of IOVA space, and the generic direct mapping code already provides its
own routines that is intelligent based on the amount of memory actually
present. Wire up the dma-direct routine for the ARM direct mapping code
as well,
On Thu, 08 Aug 2019 20:45:04 +0530
"Naveen N. Rao" wrote:
> Naveen N. Rao wrote:
> > Two patches addressing bugs in ftrace function probe handling. The first
> > patch addresses a NULL pointer dereference reported by LTP tests, while
> > the second one is a trivial patch to address a missing ch
Naveen N. Rao wrote:
Two patches addressing bugs in ftrace function probe handling. The first
patch addresses a NULL pointer dereference reported by LTP tests, while
the second one is a trivial patch to address a missing check for return
value, found by code inspection.
Steven,
Can you please
https://bugzilla.kernel.org/show_bug.cgi?id=204479
--- Comment #4 from Christophe Leroy (christophe.le...@c-s.fr) ---
We need to identify if the allocation of KASAN shadow area at module allocation
fails, or if kasan accesses outside of the allocated area.
Could you please run again with the belo
Le 08/08/2019 à 10:46, Christophe Leroy a écrit :
Le 07/08/2019 à 03:24, Chris Packham a écrit :
On Wed, 2019-08-07 at 11:13 +1000, Michael Ellerman wrote:
Chris Packham writes:
On Tue, 2019-08-06 at 21:32 +1000, Michael Ellerman wrote:
The difference between a working and non working d
Santa commit ebb9d30a6a74 ("powerpc/mm: any thread in one core can be
the first to setup TLB1") removed the need to know the cpu_id in
early_init_this_mmu(), but the call to smp_processor_id() which was
marked __maybe_used remained.
Since commit ed1cd6deb013 ("powerpc: Activate
CONFIG_THREAD_INFO_
https://bugzilla.kernel.org/show_bug.cgi?id=204371
--- Comment #10 from David Sterba (dste...@suse.com) ---
In my case it happened on 5.3-rc3, with a strestest. The same machine has been
running fstests periodically, with slab debug on, but there are no slab reports
like that.
[ 8516.870046] BUG
On 08/08/19 3:38 PM, Sourabh Jain wrote:
> Add a sys interface to allow querying the memory reserved by
> fadump for saving the crash dump.
>
> Add an ABI doc entry for new sysfs interface.
>- /sys/kernel/fadump_mem_reserved
>
> Signed-off-by: Sourabh Jain
> ---
> v1 -> v2:
> - Added AB
https://bugzilla.kernel.org/show_bug.cgi?id=204371
David Sterba (dste...@suse.com) changed:
What|Removed |Added
CC||dste...@suse.com
--- Co
Add a sys interface to allow querying the memory reserved by
fadump for saving the crash dump.
Add an ABI doc entry for new sysfs interface.
- /sys/kernel/fadump_mem_reserved
Signed-off-by: Sourabh Jain
---
v1 -> v2:
- Added ABI doc for new sysfs interface.
---
Documentation/ABI/testing/s
On Wed, Aug 07, 2019 at 05:07:03PM +0100, Will Deacon wrote:
> On Tue, Aug 06, 2019 at 06:00:12PM +0800, Leo Yan wrote:
> > This small patch set is to add support for function error injection;
> > this can be used to eanble more advanced debugging feature, e.g.
> > CONFIG_BPF_KPROBE_OVERRIDE.
> >
On Thu, Aug 8, 2019 at 5:05 PM Jordan Niethe wrote:
>
> On Wed, 2019-08-07 at 13:44 +1000, Sam Bobroff wrote:
> > From: Oliver O'Halloran
> >
> > Preparation for removing pci_dn from the powernv EEH code. The only
> > thing we really use pci_dn for is to get the bdfn of the device for
> > config
Le 07/08/2019 à 03:24, Chris Packham a écrit :
On Wed, 2019-08-07 at 11:13 +1000, Michael Ellerman wrote:
Chris Packham writes:
On Tue, 2019-08-06 at 21:32 +1000, Michael Ellerman wrote:
The difference between a working and non working defconfig is
CONFIG_PREEMPT specifically CONFIG_PREEMP
On 2019/8/7 21:03, Michael Ellerman wrote:
Jason Yan writes:
When kaslr is enabled, the kernel offset is different for every boot.
This brings some difficult to debug the kernel. Dump out the kernel
offset when panic so that we can easily debug the kernel.
Some of this is taken from the ar
On 2019/8/7 21:03, Michael Ellerman wrote:
Jason Yan writes:
diff --git a/arch/powerpc/kernel/kaslr_booke.c
b/arch/powerpc/kernel/kaslr_booke.c
index c6b326424b54..436f9a03f385 100644
--- a/arch/powerpc/kernel/kaslr_booke.c
+++ b/arch/powerpc/kernel/kaslr_booke.c
@@ -361,6 +361,18 @@ static
Reference counters are preferred to use refcount_t instead of
atomic_t.
This is because the implementation of refcount_t can prevent
overflows and detect possible use-after-free.
So convert atomic_t ref counters to refcount_t.
Signed-off-by: Chuhong Yuan
---
arch/powerpc/mm/book3s64/mmu_context.
On 2019/8/7 21:03, Michael Ellerman wrote:
Jason Yan writes:
After we have the basic support of relocate the kernel in some
appropriate place, we can start to randomize the offset now.
Entropy is derived from the banner and timer, which will change every
build and boot. This not so much saf
On Wed, 2019-08-07 at 13:44 +1000, Sam Bobroff wrote:
> From: Oliver O'Halloran
>
> Preparation for removing pci_dn from the powernv EEH code. The only
> thing we really use pci_dn for is to get the bdfn of the device for
> config space accesses, so adding that information to eeh_dev reduces
> th
38 matches
Mail list logo
