From: Michal Hocko
Pingfan Liu has reported the following splat
[5.772742] BUG: unable to handle kernel paging request at 2088
[5.773618] PGD 0 P4D 0
[5.773618] Oops: [#1] SMP NOPTI
[5.773618] CPU: 2 PID: 1 Comm: swapper/0 Not tainted 4.20.0-rc1+ #3
[5.773618]
On Fri, Jan 11, 2019 at 06:30:43PM +0100, Arnd Bergmann wrote:
> On Thu, Jan 10, 2019 at 9:36 PM Heiko Carstens
> wrote:
> > On Thu, Jan 10, 2019 at 05:24:35PM +0100, Arnd Bergmann wrote:
>
> > Since you only need/want the system call numbers, could you please
> > change these lines to:
> >
> > >
ppc64 use CMA area for the allocation of guest page table (hash page table). We
won't
be able to start guest if we fail to allocate hash page table. We have observed
hash table allocation failure because we failed to migrate pages out of CMA
region
because they were pinned. This happen when we ar
This patch adds PF_MEMALLOC_NOCMA which make sure any allocation in that context
is marked non-movable and hence cannot be satisfied by CMA region.
This is useful with get_user_pages_longterm where we want to take a page pin by
migrating pages from CMA region. Marking the section PF_MEMALLOC_NOCMA
This patch updates get_user_pages_longterm to migrate pages allocated out
of CMA region. This makes sure that we don't keep non-movable pages (due to page
reference count) in the CMA area.
This will be used by ppc64 in a later patch to avoid pinning pages in the CMA
region. ppc64 uses CMA region f
This patch updates get_user_pages_longterm to migrate pages allocated out
of CMA region. This makes sure that we don't keep non-movable pages (due to page
reference count) in the CMA area.
This will be used by ppc64 in a later patch to avoid pinning pages in the CMA
region. ppc64 uses CMA region f
The current code doesn't do page migration if the page allocated is a compound
page.
With HugeTLB migration support, we can end up allocating hugetlb pages from
CMA region. Also, THP pages can be allocated from CMA region. This patch updates
the code to handle compound pages correctly. The patch a
THP pages can get split during different code paths. An incremented reference
count does imply we will not split the compound page. But the pmd entry can be
converted to level 4 pte entries. Keep the code simpler by allowing large
IOMMU page size only if the guest ram is backed by hugetlb pages.
S
---
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_migrate_cma_pages(unsigned long
start, long nr_pages,
* be
Michael Ellerman writes:
> Hi Arnd,
>
> Arnd Bergmann writes:
>> The IPC system call handling is highly inconsistent across architectures,
>> some use sys_ipc, some use separate calls, and some use both. We also
>> have some architectures that require passing IPC_64 in the flags, and
>> others t
On Sun, 2018-12-09 at 09:25:36 UTC, Madhavan Srinivasan wrote:
> On each sample, Monitor Mode Control Register A (MMCRA) content
> is saved in pt_regs. MMCRA does not have a entry as-is in the pt_regs
> but instead, MMCRA content is saved in the "dsisr" register of pt_regs.
>
> Patch adds another
On Wed, 2019-01-09 at 10:23:29 UTC, Dan Carpenter wrote:
> There is a typo so we accidentally allocate enough memory for a pointer
> when we wanted to allocate enough for a struct.
>
> Fixes: 0bd971676e68 ("powerpc/powernv/npu: Add compound IOMMU groups")
> Signed-off-by: Dan Carpenter
> Reviewed
On Wed, 2019-01-09 at 13:16:45 UTC, Breno Leitao wrote:
> Commit e1c3743e1a20 ("powerpc/tm: Set MSR[TS] just prior to recheckpoint")
> moved a code block around and this block uses a 'msr' variable outside of
> the CONFIG_PPC_TRANSACTIONAL_MEM, however the 'msr' variable is declared
> inside a CONF
On Wed, 2019-01-09 at 15:13:42 UTC, Frederic Barrat wrote:
> With a recent change around IOMMU group, a system with an opencapi
> adapter is no longer booting and we get a kernel oops:
>
> BUG: Kernel NULL pointer dereference at 0x0028
> Faulting instruction address: 0xc00aa38c
> Oops:
On Wed, 2019-01-09 at 20:30:07 UTC, Christophe Leroy wrote:
> Commit 8c8c10b90d88 ("powerpc/8xx: fix handling of early NULL pointer
> dereference") moved the loading of r6 earlier in the code. As some
> functions are called inbetween, r6 needs to be loaded again with the
> address of swapper_pg_dir
Michal Hocko writes:
> From: Michal Hocko
>
> Pingfan Liu has reported the following splat
> [5.772742] BUG: unable to handle kernel paging request at 2088
> [5.773618] PGD 0 P4D 0
> [5.773618] Oops: [#1] SMP NOPTI
> [5.773618] CPU: 2 PID: 1 Comm: swapper/0 Not t
On Fri, Jan 11, 2019 at 05:54:16PM -0200, Mauro Carvalho Chehab wrote:
> Em Fri, 11 Jan 2019 19:17:31 +0100
> Christoph Hellwig escreveu:
>
> > vb2_dc_get_userptr pokes into arm direct mapping details to get the
> > resemblance of a dma address for a a physical address that does is
> > not backed
Segher Boessenkool writes:
> On Fri, Jan 11, 2019 at 05:06:12PM +1100, Michael Ellerman wrote:
>> Tyrel Datwyler writes:
>> > It is basically the predecessor to PAPR "Power Architecture Platform
>> > Reference".
>> > Which the LoPAPR document is available through power.org. Not sure if
>> > th
Em Mon, 14 Jan 2019 11:31:39 +0100
Christoph Hellwig escreveu:
> On Fri, Jan 11, 2019 at 05:54:16PM -0200, Mauro Carvalho Chehab wrote:
> > Em Fri, 11 Jan 2019 19:17:31 +0100
> > Christoph Hellwig escreveu:
> >
> > > vb2_dc_get_userptr pokes into arm direct mapping details to get the
> > > re
On Mon, Jan 14, 2019 at 09:04:56AM -0200, Mauro Carvalho Chehab wrote:
> It would be good if you could later send us a stable branch where
> you merged, in order to allow us to run some tests with the new
> DMA mapping patchset and be sure that it won't cause regressions
> to videobuf2.
I can do t
On Mon, Dec 03, 2018 at 03:31:59PM -0600, Rob Herring wrote:
> Convert Actions Semi SoC bindings to DT schema format using json-schema.
>
Andreas,
Shall I just apply this patch to Actions sub-tree?
Thanks,
Mani
> Cc: "Andreas Färber"
> Cc: Manivannan Sadhasivam
> Cc: Mark Rutland
> Cc: linu
We never pass a value for offset, nor do we need to, so remove the
offset logic.
Signed-off-by: Michael Ellerman
---
arch/powerpc/kernel/syscalls/Makefile | 6 ++
arch/powerpc/kernel/syscalls/syscallhdr.sh | 10 ++
arch/powerpc/kernel/syscalls/syscalltbl.sh | 8 ++--
3 fil
We never pass a prefix so remove the logic for it.
Signed-off-by: Michael Ellerman
---
arch/powerpc/kernel/syscalls/Makefile | 3 +--
arch/powerpc/kernel/syscalls/syscallhdr.sh | 4 +---
2 files changed, 2 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/kernel/syscalls/Makefile
b/
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 pretend that
it does.
It also means we have more duplicated syscall lin
sys_ni_syscall is the "not-implemented" syscall syscall, which just
returns -ENOSYS.
But unless you know that it's not obvious what it does, and even if
you do know what it means it doesn't stand out that well from other
real syscalls.
So teach the scripts to treat "none" as a synonym for
"sys_ni
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 the syscal numbers to line up with
the array entries. If for example w
On Mon 14-01-19 21:26:39, Michael Ellerman wrote:
> Michal Hocko writes:
>
> > From: Michal Hocko
> >
> > Pingfan Liu has reported the following splat
> > [5.772742] BUG: unable to handle kernel paging request at
> > 2088
> > [5.773618] PGD 0 P4D 0
> > [5.773618] Oops: 0
Hi Christoph,
On 2019-01-11 19:17, Christoph Hellwig wrote:
> Hi all,
>
> this series fixes a rather gross layering violation in videobuf2, which
> pokes into arm DMA mapping internals to get a DMA address for memory that
> does not have a page structure, and to do so fixes up the dma_map_resource
Hi Christoph,
On 2019-01-11 19:17, Christoph Hellwig wrote:
> vb2_dc_get_userptr pokes into arm direct mapping details to get the
> resemblance of a dma address for a a physical address that does is
> not backed by a page struct. Not only is this not portable to other
> architectures with dma dir
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 story: it is
difficult and sometimes not really clear if setting/checking for
The l1 GATT page table is kept in a special on-chip page with 64 entries.
We allocate the l2 page table pages via get_zeroed_page() and enter them
into the table. These l2 pages are modified accordingly when
inserting/removing memory via efficeon_insert_memory and
efficeon_remove_memory.
Apart fro
The VDSO is part of the kernel image and therefore the struct pages are
marked as reserved during boot.
As we install a special mapping, the actual struct pages will never be
exposed to MM via the page tables. We can therefore leave the pages
marked as reserved.
Suggested-by: Martin Schwidefsky
The VDSO is part of the kernel image and therefore the struct pages are
marked as reserved during boot.
As we install a special mapping, the actual struct pages will never be
exposed to MM via the page tables. We can therefore leave the pages
marked as reserved.
Cc: Benjamin Herrenschmidt
Cc: Pa
The VDSO is part of the kernel image and therefore the struct pages are
marked as reserved during boot.
As we install a special mapping, the actual struct pages will never be
exposed to MM via the page tables. We can therefore leave the pages
marked as reserved.
Cc: Palmer Dabbelt
Cc: Albert Ou
The PG_reserved flag is cleared from memory that is part of the kernel
image (and therefore marked as PG_reserved). Avoid using PG_reserved
directly.
Cc: Geert Uytterhoeven
Cc: Andrew Morton
Cc: Michal Hocko
Cc: Matthew Wilcox
Signed-off-by: David Hildenbrand
---
arch/m68k/mm/memory.c | 2 +-
This will be done by free_reserved_page().
Cc: Catalin Marinas
Cc: Will Deacon
Cc: Bhupesh Sharma
Cc: James Morse
Cc: Marc Zyngier
Cc: Dave Kleikamp
Cc: Mark Rutland
Cc: Andrew Morton
Cc: Michal Hocko
Cc: Matthew Wilcox
Acked-by: James Morse
Signed-off-by: David Hildenbrand
---
arch/a
The crashkernel is reserved via memblock_reserve(). memblock_free_all()
will call free_low_memory_core_early(), which will go over all reserved
memblocks, marking the pages as PG_reserved.
So manually marking pages as PG_reserved is not necessary, they are
already in the desired state (otherwise t
In the old days, remap_pfn_range() required pages to be marked as
PG_reserved, so they would e.g. never get swapped out. This was required
for special mappings. Nowadays, this is fully handled via the VMA
(VM_IO | VM_PFNMAP | VM_DONTEXPAND | VM_DONTDUMP inside remap_pfn_range()
to be precise). PG_r
The usage of PG_reserved and how PG_reserved pages are to be treated is
buried deep down in different parts of the kernel. Let's shine some light
onto these details by documenting current users and expected
behavior.
Especially, clarify on the "Some of them might not even exist" case.
These are ph
On 11/01/2019 18:17, Christoph Hellwig wrote:
Just returning the physical address when not map_resource method is
present is highly dangerous as it doesn't take any offset in the
direct mapping into account and does the completely wrong thing for
IOMMUs. Instead provide a proper implementation i
On Mon, Jan 14, 2019 at 1:59 PM David Hildenbrand wrote:
> The PG_reserved flag is cleared from memory that is part of the kernel
> image (and therefore marked as PG_reserved). Avoid using PG_reserved
> directly.
>
> Cc: Geert Uytterhoeven
> Cc: Andrew Morton
> Cc: Michal Hocko
> Cc: Matthew Wi
On 11/01/2019 18:17, Christoph Hellwig wrote:
Use WARN_ON_ONCE to print a stack trace and return a proper error
code instead.
I was racking my brain to remember the reasoning behind BUG_ON() being
the only viable way to prevent errors getting through unhandled, but of
course that was before w
Hi David,
Thanks for the patch.
On Mon, Jan 14, 2019 at 6:29 PM David Hildenbrand wrote:
>
> This will be done by free_reserved_page().
>
> Cc: Catalin Marinas
> Cc: Will Deacon
> Cc: Bhupesh Sharma
> Cc: James Morse
> Cc: Marc Zyngier
> Cc: Dave Kleikamp
> Cc: Mark Rutland
> Cc: Andrew M
Hi David,
On Mon, Jan 14, 2019 at 6:30 PM David Hildenbrand wrote:
>
> The crashkernel is reserved via memblock_reserve(). memblock_free_all()
> will call free_low_memory_core_early(), which will go over all reserved
> memblocks, marking the pages as PG_reserved.
>
> So manually marking pages as
On Mon, Jan 14, 2019 at 08:21:40AM +0100, Nicolai Stange wrote:
> Joe Lawrence writes:
>
> > We should be careful when inspecting the bottom-most stack frame (the
> > first to be unwound), particularly for scheduled-out tasks. As Nicolai
> > Stange explains, "If I'm reading the code in _switch()
On Mon, Jan 14, 2019 at 01:12:33PM +, Robin Murphy wrote:
> Ignoring the offset was kind of intentional there, because at the time I
> was primarily thinking about it in terms of the Keystone 2 platform where
> the peripherals are all in the same place (0-2GB) in both the bus and CPU
> physi
On Mon, Jan 14, 2019 at 11:46:59AM -0500, Joe Lawrence wrote:
> @@ -158,11 +158,21 @@ save_stack_trace_tsk_reliable(struct task_struct *tsk,
> return 1; /* invalid backlink, too far up. */
> }
>
> + /* We can only trust the bottom frame's backlink,
On 1/14/19 12:09 PM, Josh Poimboeuf wrote:
On Mon, Jan 14, 2019 at 11:46:59AM -0500, Joe Lawrence wrote:
@@ -158,11 +158,21 @@ save_stack_trace_tsk_reliable(struct task_struct *tsk,
return 1; /* invalid backlink, too far up. */
}
+ /* We can only trust
On 1/9/19 12:08 AM, Gautham R Shenoy wrote:
> I did some testing during the holidays. Here are the observations:
>
> 1) With just your patch (without any additional debug patch), if I run
> DLPAR on /off operations on a system that has SMT=off, I am able to
> see a crash involving RTAS stack corr
Le 13/01/2019 à 22:02, Jonathan Neuschäfer a écrit :
On Sun, Jan 13, 2019 at 08:43:07PM +0100, Christophe Leroy wrote:
Le 13/01/2019 à 19:16, Jonathan Neuschäfer a écrit :
I just tested the whole series on my Wii (I didn't test any intermediate
steps). Without CONFIG_STRICT_KERNEL_RWX, it se
On Sun, Jan 13, 2019 at 11:13 PM Bharat Bhushan wrote:
>
> cpu_possible(cpu) will always return true when cpu parameter
> is from cpumask_next().
> Check for nr_cpu_ids rather than !cpu_possible(cpu).
There is another patch pending merge seems to cover this issue too.
Please let me know if it doe
GCC supports -mcpu=G4
This patch gives the opportunity to select ALTIVEC for this variant.
Signed-off-by: Mathieu Malaterre
---
arch/powerpc/platforms/Kconfig.cputype | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/powerpc/platforms/Kconfig.cputype
b/arch/powerpc/platforms/Kconf
On Fri, Dec 14, 2018 at 02:51:31PM -0600, Michael Bringmann wrote:
> The implementation of the pseries-specific drc info properties
> is currently implemented in pseries-specific and non-pseries-specific
> files. This patch set uses a new implementation of the device-tree
> parsing code for the pr
On Mon, Jan 14, 2019 at 07:23:07PM +0100, Christophe Leroy wrote:
>
>
> Le 13/01/2019 à 22:02, Jonathan Neuschäfer a écrit :
> > On Sun, Jan 13, 2019 at 08:43:07PM +0100, Christophe Leroy wrote:
> > > Le 13/01/2019 à 19:16, Jonathan Neuschäfer a écrit :
> > > > I just tested the whole series on m
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:
powerpc64le-pc-linux-gnu-ld: arch/powerpc/platforms/pseries/pci.o: in function
`p
> -Original Message-
> From: Li Yang
> Sent: Tuesday, January 15, 2019 12:47 AM
> To: Bharat Bhushan
> Cc: Roy Pledge ; linux-ker...@vger.kernel.org;
> linuxppc-dev@lists.ozlabs.org; linux-arm-ker...@lists.infradead.org;
> bharatb.ya...@gmail.com
> Subject: Re: [PATCH] soc: fsl: dpio: f
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 and UBSan instrumentation.
Signed-off-by: Andrew Donnellan
---
kcov looks like it's working okay, b
On powerpc, setting CONFIG_NVRAM=n builds a kernel with no NVRAM support.
Setting CONFIG_NVRAM=m enables the /dev/nvram misc device module without
enabling NVRAM support in drivers. Setting CONFIG_NVRAM=y enables the
misc device (built-in) and also enables NVRAM support in drivers.
m68k shares the
The "generic" NVRAM module, drivers/char/generic_nvram.c, implements a
/dev/nvram misc device. This module is used only by 32-bit PowerPC
platforms.
The RTC "CMOS" NVRAM module, drivers/char/nvram.c, also implements a
/dev/nvram misc device. This module is now used only by x86 and m68k
thanks to c
Also give functions more sensible names: nvram_misc_* for misc device ops,
nvram_proc_* for proc file ops and nvram_module_* for init and exit
functions. This prevents name collisions with nvram.h helper functions
and improves readability.
Signed-off-by: Finn Thain
---
drivers/char/nvram.c | 167
Replace nvram_* functions with static functions in nvram.h. These will
become wrappers for struct nvram_ops method calls.
This patch effectively disables existing NVRAM functionality so as to
allow the rest of the series to be bisected without build failures.
That functionality is gradually re-imp
Move the m68k-specific code out of the driver to make the driver generic.
I've used 'SPDX-License-Identifier: GPL-2.0+' for the new file because the
old file is covered by MODULE_LICENSE("GPL").
Acked-by: Geert Uytterhoeven
Signed-off-by: Finn Thain
---
Changed since v8:
- Fixed an old bug by
By implementing an arch_nvram_ops struct, a platform can re-use the
drivers/char/nvram.c module without needing any arch-specific code
in that module. Atari does so here.
Acked-by: Geert Uytterhoeven
Signed-off-by: Finn Thain
---
Changed since v8:
- Added static inline wrapper functions to nvra
Remove the nvram_read_byte() and nvram_write_byte() declarations in
powerpc/include/asm/nvram.h and use the cross-platform static functions
in linux/nvram.h instead.
Tested-by: Stan Johnson
Signed-off-by: Finn Thain
---
Changed since v8:
- Added nvram_read_byte() and nvram_write_byte() function
NVRAMs on different platforms and architectures have different attributes
and access methods. E.g. some platforms have byte-at-a-time accessor
functions while others have byte-range accessor functions. Some have
checksum functionality while others do not. By calling ops struct methods
via the commo
This is intended to improve code style and not affect code behaviour.
Acked-by: Geert Uytterhoeven
Tested-by: Stan Johnson
Signed-off-by: Finn Thain
---
arch/m68k/mac/misc.c | 59 ++--
1 file changed, 41 insertions(+), 18 deletions(-)
diff --git a/arch/
Atari RTC NVRAM uses a checksum so implement the remaining arch_nvram_ops
methods for the set_checksum and initialize ioctls. Enable
CONFIG_HAVE_ARCH_NVRAM_OPS.
Acked-by: Geert Uytterhoeven
Signed-off-by: Finn Thain
---
Changed since v8:
- Moved the HAVE_ARCH_NVRAM_OPS symbol to common code as
Refactor the RTC "CMOS" NVRAM functions so that they can be used as
arch_nvram_ops methods. Checksumming logic is moved from the misc device
operations to the nvram read/write operations. This makes the misc device
implementation more generic.
This preserves the locking mechanism such that "read i
Adopt the existing *_read_byte and *_write_byte naming convention.
Rename via_pram_readbyte and via_pram_writebyte to avoid confusion.
Adjust calling conventions of mac_pram_* functions to match the
struct nvram_ops methods.
Acked-by: Geert Uytterhoeven
Tested-by: Stan Johnson
Signed-off-by: Fin
Certain Cuda transfers have to be ended by the driver. According
to Apple's open source Cuda driver, as found in mkLinux and XNU, this
applies to any "open ended request such as PRAM read". This fixes an
infinite polling loop in cuda_pram_read_byte().
Tested-by: Stan Johnson
Signed-off-by: Finn T
The drivers/char/nvram.c module has previously supported only RTC "CMOS"
NVRAM, for which it provides appropriate checksum ioctls. Make these
ioctls optional so the module can be re-used with other kinds of NVRAM.
The ops struct methods that implement the ioctls now return error
codes so that a mu
Signed-off-by: Finn Thain
---
drivers/char/nvram.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/char/nvram.c b/drivers/char/nvram.c
index adcc213c331e..c9e295d73dc5 100644
--- a/drivers/char/nvram.c
+++ b/drivers/char/nvram.c
@@ -503,3 +503,4 @@ module_exit(nvram_module_exit);
M
PMU-based m68k Macs pre-date PowerMac-style NVRAM. Use the appropriate
PMU commands. Also implement the missing XPRAM accessors for VIA-based
Macs.
Acked-by: Geert Uytterhoeven
Tested-by: Stan Johnson
Signed-off-by: Finn Thain
---
Changed since v7:
- Revised PMU response decoding due to via-pm
Add the powerpc-specific ioctls to the nvram module. This allows the nvram
module to replace the generic_nvram module.
Tested-by: Stan Johnson
Signed-off-by: Finn Thain
---
On PPC32, the IOC_NVRAM_SYNC ioctl call always returns 0, even for those
platforms that don't implement ppc_md.nvram_sync.
Signed-off-by: Finn Thain
---
drivers/char/Makefile| 6 +-
drivers/char/generic_nvram.c | 160 ---
2 files changed, 1 insertion(+), 165 deletions(-)
delete mode 100644 drivers/char/generic_nvram.c
diff --git a/drivers/char/Makefile b/drivers/char/Makefi
Switch PPC32 kernels from the generic_nvram module to the nvram module.
Also fix a theoretical bug where CHRP omits the chrp_nvram_init() call
when CONFIG_NVRAM_MODULE=m.
Tested-by: Stan Johnson
Signed-off-by: Finn Thain
---
The change in the name of the module is visible to userspace. The modu
Add the nvram_size() function to those PowerPC platforms that don't already
have one: CHRP and PowerMac. This means that the ppc_md.nvram_size()
function can be called by nvram_get_size().
Since we are addressing CHRP inconsistencies here, rename chrp_nvram_read
and chrp_nvram_write, which break t
A multi-platform kernel binary has to decide at run-time how to dispatch
the arch_nvram_ops calls. Add a platform-independent arch_nvram_ops
struct for this, to replace the atari-specific one.
Enable CONFIG_HAVE_ARCH_NVRAM_OPS for Macs.
Acked-by: Geert Uytterhoeven
Tested-by: Stan Johnson
Signe
Adopt nvram module to reduce code duplication. This means CONFIG_NVRAM
becomes available to PPC64 builds. Previously it was only available to
PPC32 builds because it depended on CONFIG_GENERIC_NVRAM.
The IOC_NVRAM_GET_OFFSET ioctl as implemented on PPC64 validates the
offset returned by pmac_get_p
This patch addresses inconsistencies in Mac framebuffer drivers and their
use of Kconfig symbols relating to NVRAM, so PPC64 can use CONFIG_NVRAM.
The defined(CONFIG_NVRAM) condition is replaced with the weaker
IS_REACHABLE(CONFIG_NVRAM) condition, like atari_scsi.
Macintosh framebuffer drivers u
On 15/01/2019 11:47, Jason A. Donenfeld wrote:
> 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:
>
> powerpc64le-pc-linux
[...]
> >
> > I would appreciate a help with those architectures because I couldn't
> > really grasp how the memoryless nodes are really initialized there. E.g.
> > ppc only seem to call setup_node_data for online nodes but I couldn't
> > find any special treatment for nodes without any memory.
>
>
Recently in commit fbf508da7440 ("powerpc: split compat syscall table
out from native table") we changed the layout of the system call
table. Instead of having two entries for each syscall number, one for
the regular entry point and one for the compat entry point, we now
have separate tables for re
We weren't using SYSCALL_DEFINE for sys_switch_endian(), which means
it wasn't able to be traced by CONFIG_FTRACE_SYSCALLS.
By using the macro we create the right metadata and the syscall is
visible. eg:
# cd /sys/kernel/debug/tracing
# echo 1 | tee events/syscalls/sys_*_switch_endian/enable
Michael Bringmann writes:
> [FYI: Please post to linuxppc-dev mailing list when you are ready.
> Good luck.]
???
I guess I'll ignore this and look at the other version you posted? :)
cheers
> We have encountered cases where DLPAR CPU 'readd' fails on single
> CPU platforms, because the s
Le 15/01/2019 à 01:33, Jonathan Neuschäfer a écrit :
On Mon, Jan 14, 2019 at 07:23:07PM +0100, Christophe Leroy wrote:
Le 13/01/2019 à 22:02, Jonathan Neuschäfer a écrit :
On Sun, Jan 13, 2019 at 08:43:07PM +0100, Christophe Leroy wrote:
Le 13/01/2019 à 19:16, Jonathan Neuschäfer a écrit
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 e07db28eea38 ("kbuild: fix single target build for external
mo
[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
> files where we currently disable gcov an
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 allow GCC to replace it with __memcpy() when KASAN is
> selected.
>
> Since commit 400c47d81ca38 ("powerpc32: memset: only use
89 matches
Mail list logo
