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
---
On 2019/8/7 21:04, Michael Ellerman wrote:
Jason Yan writes:
This patch add support to boot kernel from places other than KERNELBASE.
Since CONFIG_RELOCATABLE has already supported, what we need to do is
map or copy kernel to a proper place and relocate. Freescale Book-E
parts expect lowmem
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
>
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
[ deliberately broke threading so this doesn't get buried ]
Christophe Leroy writes:
> diff --git a/arch/powerpc/kernel/misc_64.S b/arch/powerpc/kernel/misc_64.S
> index a4fd536efb44..1b0a42c50ef1 100644
> --- a/arch/powerpc/kernel/misc_64.S
> +++ b/arch/powerpc/kernel/misc_64.S
> @@ -115,35
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 @@
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
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
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
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.
> >
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
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
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
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
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
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
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
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
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
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
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.
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
---
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
https://bugzilla.kernel.org/show_bug.cgi?id=204479
Erhard F. (erhar...@mailbox.org) changed:
What|Removed |Added
Attachment #284177|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 #284175|0 |1
is obsolete|
https://bugzilla.kernel.org/show_bug.cgi?id=204375
Erhard F. (erhar...@mailbox.org) changed:
What|Removed |Added
Status|NEW |RESOLVED
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(+),
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:
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
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: ##
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
>> +++
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 ?
--
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
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
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
https://bugzilla.kernel.org/show_bug.cgi?id=204371
David Sterba (dste...@suse.com) changed:
What|Removed |Added
CC||dste...@suse.com
---
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
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.
---
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
40 matches
Mail list logo
