On 15/1/19 5:40 pm, Dmitry Vyukov wrote:
On Tue, Jan 15, 2019 at 5:20 AM Andrew Donnellan
wrote:
kcov provides kernel coverage data that's useful for fuzzing tools like
syzkaller.
Wire up kcov support on powerpc. Disable kcov instrumentation on the same
files where we currently disable gcov a
On Tue, 15 Jan 2019 at 08:20, Masahiro Yamada
wrote:
>
> Commit c3ff2a5193fa ("powerpc/32: add stack protector support")
> caused kernel panic on PowerPC if an external module is used with
> CONFIG_STACKPROTECTOR because the 'prepare' target was not executed
> for the external module build.
>
> Co
Next step: 240d7ecd7f6fa62e074e8a835e620047954f0b28 (powerpc/dma: use
the dma-direct allocator for coherent platforms)
git clone git://git.infradead.org/users/hch/misc.git -b powerpc-dma.6 a
git checkout 240d7ecd7f6fa62e074e8a835e620047954f0b28
Link to the Git:
http://git.infradead.org/users/
On 15/1/19 6:26 pm, Mathieu Malaterre wrote:
[Sorry to hijack this thread. ]
On Tue, Jan 15, 2019 at 5:22 AM Andrew Donnellan
wrote:
kcov provides kernel coverage data that's useful for fuzzing tools like
syzkaller.
Wire up kcov support on powerpc. Disable kcov instrumentation on the same
fi
Next step: 63a6e350e037a21e9a88c8b710129bea7049a80f (powerpc/dma: use
the dma_direct mapping routines)
git clone git://git.infradead.org/users/hch/misc.git -b powerpc-dma.6 a
git checkout 63a6e350e037a21e9a88c8b710129bea7049a80f
Error message:
arch/powerpc/kernel/dma.o:(.data.rel.ro+0x0): und
Christophe Leroy writes:
> Le 15/01/2019 à 01:33, Jonathan Neuschäfer a écrit :
...
>>
>> - patches 7 to 11 fail to build with this error (really a warning, but
>>arch/powerpc doesn't allow warnings by default):
>>
>>CC arch/powerpc/mm/ppc_mmu_32.o
>> ../arch/powerpc/mm/ppc
Hi Jason,
Thanks for the patch.
"Jason A. Donenfeld" writes:
> Commit 0e759bd75285 moved around the declaration of pnv_npu2_init, but
> did not conditionalize it inside of the PCI pSeries driver. This meant
> that CONFIG_PCI && CONFIG_PPC_PSERIES && !CONFIG_PPC_POWERNV resulted
> in:
>
> powerpc
On Tue, Jan 15, 2019 at 8:22 AM Masahiro Yamada
wrote:
>
> Commit c3ff2a5193fa ("powerpc/32: add stack protector support")
> caused kernel panic on PowerPC if an external module is used with
> CONFIG_STACKPROTECTOR because the 'prepare' target was not executed
> for the external module build.
>
>
On 15/01/2019 18:19, Masahiro Yamada wrote:
> Commit c3ff2a5193fa ("powerpc/32: add stack protector support")
> caused kernel panic on PowerPC if an external module is used with
> CONFIG_STACKPROTECTOR because the 'prepare' target was not executed
> for the external module build.
>
> Commit e07
Next step: 21074ef03c0816ae158721a78cabe9035938 (powerpc/dma: use
the generic direct mapping bypass)
git clone git://git.infradead.org/users/hch/misc.git -b powerpc-dma.6 a
git checkout 21074ef03c0816ae158721a78cabe9035938
I was able to compile the kernel for the AmigaOne X1000 (Nemo b
Le 15/01/2019 à 11:22, Michael Ellerman a écrit :
Christophe Leroy writes:
Le 15/01/2019 à 01:33, Jonathan Neuschäfer a écrit :
...
- patches 7 to 11 fail to build with this error (really a warning, but
arch/powerpc doesn't allow warnings by default):
CC arch/powerpc/m
You can ignore this one.
On 1/14/19 3:24 PM, Aneesh Kumar K.V wrote:
---
mm/gup.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/mm/gup.c b/mm/gup.c
index 6e8152594e83..91849c39931a 100644
--- a/mm/gup.c
+++ b/mm/gup.c
@@ -1226,7 +1226,7 @@ static long check_and_mig
On Thu, Jan 10, 2019 at 05:24:35PM +0100, Arnd Bergmann wrote:
> Most architectures define system call numbers for the rseq and pkey system
> calls, even when they don't support the features, and perhaps never will.
>
> Only a few architectures are missing these, so just define them anyway
> for c
On Tue, Jan 15, 2019 at 11:55:25AM +0100, Christian Zigotzky wrote:
> Next step: 21074ef03c0816ae158721a78cabe9035938 (powerpc/dma: use the
> generic direct mapping bypass)
>
> git clone git://git.infradead.org/users/hch/misc.git -b powerpc-dma.6 a
>
> git checkout 21074ef03c0816ae158721a78cab
On 15 January 2019 at 2:35PM, Christoph Hellwig wrote:
On Tue, Jan 15, 2019 at 11:55:25AM +0100, Christian Zigotzky wrote:
Next step: 21074ef03c0816ae158721a78cabe9035938 (powerpc/dma: use the
generic direct mapping bypass)
git clone git://git.infradead.org/users/hch/misc.git -b powerpc-dma
On 01/14/2019 12:31 PM, Michal Hocko wrote:
> On Mon 14-01-19 09:30:55, Anshuman Khandual wrote:
>>
>>
>> On 01/13/2019 11:05 PM, Michal Hocko wrote:
>>> On Sat 12-01-19 15:56:38, Anshuman Khandual wrote:
All architectures have been defining their own PGALLOC_GFP as (GFP_KERNEL |
__GFP
On Tue, Jan 15, 2019 at 12:52 PM Russell King - ARM Linux admin
wrote:
>
> On Thu, Jan 10, 2019 at 05:24:35PM +0100, Arnd Bergmann wrote:
> > Most architectures define system call numbers for the rseq and pkey system
> > calls, even when they don't support the features, and perhaps never will.
> >
On Tue, Jan 15, 2019 at 7:35 PM Mathieu Malaterre wrote:
>
> On Tue, Jan 15, 2019 at 8:22 AM Masahiro Yamada
> wrote:
> >
> > Commit c3ff2a5193fa ("powerpc/32: add stack protector support")
> > caused kernel panic on PowerPC if an external module is used with
> > CONFIG_STACKPROTECTOR because the
On Mon, Jan 14, 2019 at 4:59 AM Michael Ellerman wrote:
> Arnd Bergmann writes:
> > arch/m68k/kernel/syscalls/syscall.tbl | 11 +++
> > arch/mips/kernel/syscalls/syscall_o32.tbl | 11 +++
> > arch/powerpc/kernel/syscalls/syscall.tbl | 12
>
> I have some changes
On Tue, Jan 15, 2019 at 7:45 PM Alexey Kardashevskiy wrote:
>
>
>
> On 15/01/2019 18:19, Masahiro Yamada wrote:
> > Commit c3ff2a5193fa ("powerpc/32: add stack protector support")
> > caused kernel panic on PowerPC if an external module is used with
> > CONFIG_STACKPROTECTOR because the 'prepare'
On Tue, Jan 15, 2019 at 02:56:34PM +0100, Christian Zigotzky wrote:
> On 15 January 2019 at 2:35PM, Christoph Hellwig wrote:
>> On Tue, Jan 15, 2019 at 11:55:25AM +0100, Christian Zigotzky wrote:
>>> Next step: 21074ef03c0816ae158721a78cabe9035938 (powerpc/dma: use the
>>> generic direct mappin
On Tue, Jan 15, 2019 at 4:01 PM Arnd Bergmann wrote:
>
> On Mon, Jan 14, 2019 at 4:59 AM Michael Ellerman wrote:
> > Arnd Bergmann writes:
> > > arch/m68k/kernel/syscalls/syscall.tbl | 11 +++
> > > arch/mips/kernel/syscalls/syscall_o32.tbl | 11 +++
> > > arch/powerpc/kerne
Looks good,
Reviewed-by: Christoph Hellwig
On Mon, Jan 14, 2019 at 01:58:54PM +0100, David Hildenbrand wrote:
> Nothing major changed since the last version. I would be happy about
> additional ACKs. If there are no further comments, can this go via the
> mm-tree in one chunk?
>
> I was recently going over all users of PG_reserved. Short s
On 15.01.19 16:38, Christoph Hellwig wrote:
> On Mon, Jan 14, 2019 at 01:58:54PM +0100, David Hildenbrand wrote:
>> Nothing major changed since the last version. I would be happy about
>> additional ACKs. If there are no further comments, can this go via the
>> mm-tree in one chunk?
>>
>> I was rec
On Mon, Jan 14, 2019 at 12:36 PM Michael Ellerman wrote:
>
> Currently the macro that inserts entries into the SPU syscall table
> doesn't actually use the "nr" (syscall number) parameter.
>
> This does work, but it relies on the exact right number of syscall
> entries being emitted in order for t
On Mon, Jan 14, 2019 at 12:36 PM Michael Ellerman wrote:
>
> We never pass a value for offset, nor do we need to, so remove the
> offset logic.
>
> Signed-off-by: Michael Ellerman
This change and the next three defeat the idea of having a shared script across
all architectures. Firoz has already
On Mon, Jan 14, 2019 at 12:36 PM Michael Ellerman wrote:
>
> Using the ABI field to encode whether a syscall is usable by SPU
> programs or not is a bit of kludge.
>
> The ABI of the syscall doesn't change depending on the SPU-ness, but
> in order to make the syscall generation work we have to pre
Hi Arnd,
On Tue, Jan 15, 2019 at 4:19 PM Arnd Bergmann wrote:
> On Tue, Jan 15, 2019 at 4:01 PM Arnd Bergmann wrote:
> > On Mon, Jan 14, 2019 at 4:59 AM Michael Ellerman
> > wrote:
> > > Arnd Bergmann writes:
> > > > arch/m68k/kernel/syscalls/syscall.tbl | 11 +++
> > > > arch/mi
'nobats' kernel parameter or some options like CONFIG_DEBUG_PAGEALLOC
deny the use of BATS for mapping memory.
This patch makes sure that the specific wii RAM mapping function
takes it into account as well.
Fixes: de32400dd26e ("wii: use both mem1 and mem2 as ram")
Cc: sta...@vger.kernel.org
Sign
On Tue, Jan 15, 2019 at 6:06 PM Andrey Ryabinin wrote:
>
>
>
> On 1/15/19 2:14 PM, Dmitry Vyukov wrote:
> > On Tue, Jan 15, 2019 at 8:27 AM Christophe Leroy
> > wrote:
> >> On 01/14/2019 09:34 AM, Dmitry Vyukov wrote:
> >>> On Sat, Jan 12, 2019 at 12:16 PM Christophe Leroy
> >>> wrote:
> >>> >
>
On 1/12/19 2:16 PM, Christophe Leroy wrote:
> +KASAN_SANITIZE_early_32.o := n
> +KASAN_SANITIZE_cputable.o := n
> +KASAN_SANITIZE_prom_init.o := n
> +
Usually it's also good idea to disable branch profiling - define
DISABLE_BRANCH_PROFILING
either in top of these files or via Makefile. Branch
Le 15/01/2019 à 18:10, Dmitry Vyukov a écrit :
On Tue, Jan 15, 2019 at 6:06 PM Andrey Ryabinin wrote:
On 1/15/19 2:14 PM, Dmitry Vyukov wrote:
On Tue, Jan 15, 2019 at 8:27 AM Christophe Leroy
wrote:
On 01/14/2019 09:34 AM, Dmitry Vyukov wrote:
On Sat, Jan 12, 2019 at 12:16 PM Christop
On 1/15/19 2:14 PM, Dmitry Vyukov wrote:
> On Tue, Jan 15, 2019 at 8:27 AM Christophe Leroy
> wrote:
>> On 01/14/2019 09:34 AM, Dmitry Vyukov wrote:
>>> On Sat, Jan 12, 2019 at 12:16 PM Christophe Leroy
>>> wrote:
>>> >
>>> > In kernel/cputable.c, explicitly use memcpy() in order
>>> > to allo
On Tue, 8 Jan 2019 13:05:47 +, Viorel Suman wrote:
> Add the DT binding documentation for NXP Audio Mixer
> CPU DAI driver.
>
> Signed-off-by: Viorel Suman
> ---
> .../devicetree/bindings/sound/fsl,audmix.txt | 44
> ++
> 1 file changed, 44 insertions(+)
> create
On Tue, Jan 08, 2019 at 01:05:51PM +, Viorel Suman wrote:
> Add the DT binding documentation for Audio Mixer
> machine driver.
>
> Signed-off-by: Viorel Suman
> ---
> .../devicetree/bindings/sound/imx-audmix.txt | 24
> ++
> 1 file changed, 24 insertions(+)
> crea
On Tue, Jan 15, 2019 at 5:36 PM Geert Uytterhoeven wrote:
> On Tue, Jan 15, 2019 at 4:19 PM Arnd Bergmann wrote:
> > On Tue, Jan 15, 2019 at 4:01 PM Arnd Bergmann wrote:
> > > On Mon, Jan 14, 2019 at 4:59 AM Michael Ellerman
> > > wrote:
> > > > Arnd Bergmann writes:
> > > > > arch/m68k/kern
Le 15/01/2019 à 08:26, Mathieu Malaterre a écrit :
[Sorry to hijack this thread. ]
On Tue, Jan 15, 2019 at 5:22 AM Andrew Donnellan
wrote:
kcov provides kernel coverage data that's useful for fuzzing tools like
syzkaller.
Wire up kcov support on powerpc. Disable kcov instrumentation on th
Hi,
both the latest stable 4.20.2 and 5.0 rc2+ hang early on the G5 Quad.
Surely I'm not the first to run into this, but I couldn't find any
discussion or bug report. Sorry if you're already aware.
You can see it hang here (5.0 rc2+, 4.20.2 is nearly identical) until
the watchdog triggers a rebo
Arnd Bergmann writes:
> On Tue, Jan 15, 2019 at 4:01 PM Arnd Bergmann wrote:
>>
>> On Mon, Jan 14, 2019 at 4:59 AM Michael Ellerman wrote:
>> > Arnd Bergmann writes:
>> > > arch/m68k/kernel/syscalls/syscall.tbl | 11 +++
>> > > arch/mips/kernel/syscalls/syscall_o32.tbl | 11 ++
Arnd Bergmann writes:
> On Mon, Jan 14, 2019 at 4:59 AM Michael Ellerman wrote:
>> Arnd Bergmann writes:
>> > arch/m68k/kernel/syscalls/syscall.tbl | 11 +++
>> > arch/mips/kernel/syscalls/syscall_o32.tbl | 11 +++
>> > arch/powerpc/kernel/syscalls/syscall.tbl | 12
Arnd Bergmann writes:
> On Mon, Jan 14, 2019 at 12:36 PM Michael Ellerman wrote:
>>
>> We never pass a value for offset, nor do we need to, so remove the
>> offset logic.
>>
>> Signed-off-by: Michael Ellerman
>
> This change and the next three defeat the idea of having a shared script
> across
On Tue, Jan 15, 2019 at 07:51:01AM +0100, Christophe Leroy wrote:
> Le 15/01/2019 à 01:33, Jonathan Neuschäfer a écrit :
[...]
> > I've checked it patch-by-patch now (with STRICT_KERNEL_RWX):
> >
> > - patches 1 and 2 build and boot fine
> > - patches 3 to 6 build, but fail to boot with this error
On Tue, 2019-01-15 at 23:49 +0100, Tobias Ulmer wrote:
> Hi,
>
> both the latest stable 4.20.2 and 5.0 rc2+ hang early on the G5 Quad.
>
> Surely I'm not the first to run into this, but I couldn't find any
> discussion or bug report. Sorry if you're already aware.
>
> You can see it hang here (5
Hi Michael,
Thanks for your email.
On Mon, 14 Jan 2019 at 17:06, Michael Ellerman wrote:
> nxt=0
> while read nr abi name entry compat ; do
> - printf "#define __NR_%s%s\t%s\n" \
> - "${prefix}" "${name}" "${nr}"
> + printf "#defi
-Original Message-
From: Rob Herring
Sent: 2019年1月11日 22:31
To: Xiaowei Bao
Cc: bhelg...@google.com; robh...@kernel.org; mark.rutl...@arm.com;
shawn...@kernel.org; Leo Li ; kis...@ti.com;
lorenzo.pieral...@arm.com; a...@arndb.de; gre...@linuxfoundation.org; M.h. Lian
; Mingkai Hu ;
Christophe Leroy writes:
> Le 15/01/2019 à 08:26, Mathieu Malaterre a écrit :
...
>>
>> I did check that `custom_defconfig` is the minimal defconfig generated
>> by `savedefconfig` in both cases.
>>
>> Hints or comments welcome, thanks much.
>
> I think you should do:
>
> make ARCH=powerpc CROSS
All architectures have been defining their own PGALLOC_GFP as (GFP_KERNEL |
__GFP_ZERO) and using it for allocating page table pages. This causes some
code duplication which can be easily avoided. GFP_KERNEL allocated and
cleared out pages (__GFP_ZERO) are required for page tables on any given
arch
Le 16/01/2019 à 01:35, Jonathan Neuschäfer a écrit :
On Tue, Jan 15, 2019 at 07:51:01AM +0100, Christophe Leroy wrote:
Le 15/01/2019 à 01:33, Jonathan Neuschäfer a écrit :
[...]
I've checked it patch-by-patch now (with STRICT_KERNEL_RWX):
- patches 1 and 2 build and boot fine
- patches 3 t
On Wed, Jan 16, 2019 at 11:51:32AM +0530, Anshuman Khandual wrote:
> All architectures have been defining their own PGALLOC_GFP as (GFP_KERNEL |
> __GFP_ZERO) and using it for allocating page table pages. This causes some
> code duplication which can be easily avoided. GFP_KERNEL allocated and
> cl
Tobias Ulmer writes:
> Hi,
>
> both the latest stable 4.20.2 and 5.0 rc2+ hang early on the G5 Quad.
>
> Surely I'm not the first to run into this, but I couldn't find any
> discussion or bug report. Sorry if you're already aware.
Actually you're probably the first to hit it :)
I have a quad but
On Wed 16-01-19 11:51:32, Anshuman Khandual wrote:
> All architectures have been defining their own PGALLOC_GFP as (GFP_KERNEL |
> __GFP_ZERO) and using it for allocating page table pages. This causes some
> code duplication which can be easily avoided. GFP_KERNEL allocated and
> cleared out pages
Le 16/01/2019 à 07:21, Anshuman Khandual a écrit :
All architectures have been defining their own PGALLOC_GFP as (GFP_KERNEL |
__GFP_ZERO) and using it for allocating page table pages. This causes some
code duplication which can be easily avoided. GFP_KERNEL allocated and
cleared out pages (__
On Wed, Jan 16, 2019 at 6:09 AM Michael Ellerman wrote:
>
> Christophe Leroy writes:
> > Le 15/01/2019 à 08:26, Mathieu Malaterre a écrit :
> ...
> >>
> >> I did check that `custom_defconfig` is the minimal defconfig generated
> >> by `savedefconfig` in both cases.
> >>
> >> Hints or comments wel
54 matches
Mail list logo
