Joe Lawrence writes:
> On Fri, Jan 11, 2019 at 01:00:38AM +0100, Nicolai Stange wrote:
>> Hi Joe,
>>
>> Joe Lawrence writes:
>>
>> > tl;dr: On ppc64le, what is top-most stack frame for scheduled tasks
>> >about?
>>
>> If I'm reading the code in _switch() correctly, the first frame is
Tyrel Datwyler writes:
> On 01/09/2019 04:37 AM, Michael Ellerman wrote:
>> Bjorn Helgaas writes:
>>> I want to update the PCI Kconfig labels so they're more consistent and
>>> useful to users, something like the patch below. IIUC, the items
>>> below are all IBM-related; please correct me if
On Thu, Jan 10, 2019 at 10:17:38AM -0700, Nathan Chancellor wrote:
> Hi Greg and Sasha,
>
> Attached is an mbox with a series of patches to allow building the
> powerpc kernel with Clang. We have been running continuous integration
> that builds and boots the kernel in QEMU for almost two months
Masahiro Yamada writes:
> On Thu, Jan 10, 2019 at 2:44 PM Alexey Kardashevskiy wrote:
...
>> diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
>> index 488c9ed..0492f62 100644
>> --- a/arch/powerpc/Makefile
>> +++ b/arch/powerpc/Makefile
>> @@ -419,7 +419,11 @@ archheaders:
>> ifdef
On Mon, Jan 07, 2019 at 07:43:16PM +0100, Cédric Le Goater wrote:
> The KVM device for the XIVE native exploitation mode will reuse the
> structures of the XICS-over-XIVE glue implementation. Some code will
> also be shared : source block creation and destruction, target
> selection and escalation
On 11/01/2019 14:08, Masahiro Yamada wrote:
> On Thu, Jan 10, 2019 at 2:44 PM Alexey Kardashevskiy wrote:
>>
>> c3ff2a519 "powerpc/32: add stack protector support" addes stack protector
>> support so now powerpc's "prepare" target depends on prepare0 (via
>> stack_protector_prepare target).
>>
The same path -Iarch/$(ARCH) is passed to KBUILD_CPPFLAGS,
KBUILD_AFLAGS, and KBUILD_CFLAGS.
As you see in scripts/Makefile.lib, KBUILD_CPPFLAGS is passed
to c_flags and a_flags as well.
Passing it to KBUILD_CPPFLAGS is enough.
Signed-off-by: Masahiro Yamada
---
arch/powerpc/Makefile | 4
I am trying to get rid of crappy magic from Kbuild core makefiles.
Before that, I want to drop as many useless paths as possible.
Actually, many Makefiles are adding around pointless options.
This series cleans some powerpc Makefiles.
(only compile-tested by 0day bot)
Masahiro Yamada (3):
The header search path -I. in kernel Makefiles is very suspicious;
it allows the compiler to search for headers in the top of $(srctree),
where obviously no header file exists.
Commit 46f43c6ee022 ("KVM: powerpc: convert marker probes to event
trace") first added these options, but they are
The header search path -I. in kernel Makefiles is very suspicious;
it allows the compiler to search for headers in the top of $(srctree),
where obviously no header file exists.
-Iinclude/math-emu seems unnecessary because all files include headers
in the form of #include .
I was able to build
On Thu, Jan 10, 2019 at 2:44 PM Alexey Kardashevskiy wrote:
>
> c3ff2a519 "powerpc/32: add stack protector support" addes stack protector
> support so now powerpc's "prepare" target depends on prepare0 (via
> stack_protector_prepare target).
>
> It works fine until we try build an external module
On Thu, Jan 10, 2019 at 01:43:01PM -0600, Li Yang wrote:
> On Sat, Dec 22, 2018 at 2:02 AM Nicholas Mc Guire wrote:
> >
> > On Fri, Dec 21, 2018 at 08:29:56PM -0600, Scott Wood wrote:
> > > On Fri, 2018-12-07 at 09:22 +0100, Nicholas Mc Guire wrote:
> > > > devm_kstrdup() may return NULL if
On 09/01/2019 22:54, Michael Ellerman wrote:
> Dan Carpenter writes:
>> 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
Next step: 891dcc1072f1fa27a83da920d88daff6ca08fc02 (powerpc/dma: remove
dma_nommu_dma_supported)
git clone git://git.infradead.org/users/hch/misc.git -b powerpc-dma.6 a
git checkout 891dcc1072f1fa27a83da920d88daff6ca08fc02
Output:
Note: checking out
On Fri, Jan 11, 2019 at 01:00:38AM +0100, Nicolai Stange wrote:
> Hi Joe,
>
> Joe Lawrence writes:
>
> > tl;dr: On ppc64le, what is top-most stack frame for scheduled tasks
> >about?
>
> If I'm reading the code in _switch() correctly, the first frame is
> completely uninitialized
Hi Joe,
Joe Lawrence writes:
> tl;dr: On ppc64le, what is top-most stack frame for scheduled tasks
>about?
If I'm reading the code in _switch() correctly, the first frame is
completely uninitialized except for the pointer back to the caller's
stack frame.
For completeness: _switch()
On Thu, Jan 10, 2019 at 11:42:32PM +0100, Arnd Bergmann wrote:
> On Thu, Jan 10, 2019 at 7:10 PM Joseph Myers wrote:
> >
> > On Thu, 10 Jan 2019, Arnd Bergmann wrote:
> >
> > > - Add system calls that have not yet been integrated into all
> > > architectures but that we definitely want there.
>
On 01/10/2019 07:07 AM, Christoph Hellwig wrote:
> On Wed, Jan 09, 2019 at 06:58:56PM -0800, Tyrel Datwyler wrote:
>> While mapping DMA for scatter list when a scsi command is queued the
>> existing call to dma_alloc_coherent() in our map_sg_data() function
>> passes zero for the gfp_flags
On Thu, Jan 10, 2019 at 8:40 PM Paul Burton wrote:
> On Thu, Jan 10, 2019 at 05:24:31PM +0100, Arnd Bergmann wrote:
> > While reading through the sysvipc implementation, I noticed that the n32
> > semctl/shmctl/msgctl system calls behave differently based on whether
> > o32 support is enabled or
On Wed, Jan 09, 2019 at 02:11:25PM +0530, Aneesh Kumar K.V wrote:
> Andrew Morton writes:
>
> > On Tue, 8 Jan 2019 10:21:06 +0530 "Aneesh Kumar K.V"
> > wrote:
> >
> >> ppc64 use CMA area for the allocation of guest page table (hash page
> >> table). We won't
> >> be able to start guest if
On Thu, Jan 10, 2019 at 7:11 PM Geert Uytterhoeven wrote:
> On Thu, Jan 10, 2019 at 6:06 PM Arnd Bergmann wrote:
> > On Thu, Jan 10, 2019 at 5:59 PM Geert Uytterhoeven
> > wrote:
> > > On Thu, Jan 10, 2019 at 5:26 PM Arnd Bergmann wrote:
> > > > The system call tables have diverged a bit over
On Thu, Jan 10, 2019 at 7:10 PM Joseph Myers wrote:
>
> On Thu, 10 Jan 2019, Arnd Bergmann wrote:
>
> > - Add system calls that have not yet been integrated into all
> > architectures but that we definitely want there.
>
> glibc has a note that alpha lacks statfs64, any plans for that?
Good
Hi all,
tl;dr: On ppc64le, what is top-most stack frame for scheduled tasks
about?
I am looking at a bug in which ~10% of livepatch tests on RHEL-7 and
RHEL-8 distro kernels, the ppc64le reliable stack unwinder consistently
reports an unreliable stack for a given task. This condition
[FYI: Please post to linuxppc-dev mailing list when you are ready.
Good luck.]
We have encountered cases where DLPAR CPU 'readd' fails on single
CPU platforms, because the system needs a minimum amount of resources
to keep operating. The current implementation attempts to add, and
remove
On Thu, Jan 10, 2019 at 06:22:12PM +0100, Arnd Bergmann wrote:
> diff --git a/arch/s390/kernel/syscalls/syscall.tbl
> b/arch/s390/kernel/syscalls/syscall.tbl
> index f84ea364a302..b3199a744731 100644
> --- a/arch/s390/kernel/syscalls/syscall.tbl
> +++ b/arch/s390/kernel/syscalls/syscall.tbl
> @@
On 01/09/2019 04:37 AM, Michael Ellerman wrote:
> Hi Bjorn,
>
> Bjorn Helgaas writes:
>> Hi,
>>
>> I want to update the PCI Kconfig labels so they're more consistent and
>> useful to users, something like the patch below. IIUC, the items
>> below are all IBM-related; please correct me if not.
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
On Thu, Jan 10, 2019 at 05:24:34PM +0100, Arnd Bergmann wrote:
> 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 that
Hi Greg and Sasha,
Attached is an mbox with a series of patches to allow building the
powerpc kernel with Clang. We have been running continuous integration
that builds and boots the kernel in QEMU for almost two months now with
no regressions. This is on top of 4.14.92, there should be no
Hi Greg and Sasha,
Attached is an mbox with a series of patches to allow building the
powerpc kernel with Clang. We have been running continuous integration
that builds and boots the kernel in QEMU for almost two months now with
no regressions. This is on top of 4.19.14, there should be no
On 01/10/2019 07:07 AM, Christoph Hellwig wrote:
> On Wed, Jan 09, 2019 at 06:58:56PM -0800, Tyrel Datwyler wrote:
>> While mapping DMA for scatter list when a scsi command is queued the
>> existing call to dma_alloc_coherent() in our map_sg_data() function
>> passes zero for the gfp_flags
On Sat, Dec 22, 2018 at 2:02 AM Nicholas Mc Guire wrote:
>
> On Fri, Dec 21, 2018 at 08:29:56PM -0600, Scott Wood wrote:
> > On Fri, 2018-12-07 at 09:22 +0100, Nicholas Mc Guire wrote:
> > > devm_kstrdup() may return NULL if internal allocation failed, but
> > > as machine is from the device
Hi Arnd,
On Thu, Jan 10, 2019 at 05:24:31PM +0100, Arnd Bergmann wrote:
> While reading through the sysvipc implementation, I noticed that the n32
> semctl/shmctl/msgctl system calls behave differently based on whether
> o32 support is enabled or not: Without o32, the IPC_64 flag passed by
> user
On Thu, 10 Jan 2019, Arnd Bergmann wrote:
> - Add system calls that have not yet been integrated into all
> architectures but that we definitely want there.
glibc has a note that alpha lacks statfs64, any plans for that?
--
Joseph S. Myers
jos...@codesourcery.com
Hi Arnd,
On Thu, Jan 10, 2019 at 6:06 PM Arnd Bergmann wrote:
> On Thu, Jan 10, 2019 at 5:59 PM Geert Uytterhoeven
> wrote:
> > On Thu, Jan 10, 2019 at 5:26 PM Arnd Bergmann wrote:
> > > The system call tables have diverged a bit over the years, and a number
> > > of the recent additions
The time, stime, utime, utimes, and futimesat system calls are only
used on older architectures, and we do not provide y2038 safe variants
of them, as they are replaced by clock_gettime64, clock_settime64,
and utimensat_time64.
However, for consistency it seems better to have the 32-bit
This adds 21 new system calls on each ABI that has 32-bit time_t
today. All of these have the exact same semantics as their existing
counterparts, and the new ones all have macro names that end in 'time64'
for clarification.
This gets us to the point of being able to safely use a C library
that
This series finally gets us to the point of having system calls with
64-bit time_t on all architectures, after a long time of incremental
preparation patches.
There was actually one conversion that I missed during the summer,
i.e. Deepa's timex series, which I now updated based the 5.0-rc1
We now use 64-bit time_t on all architectures, so the __kernel_timex,
__kernel_timeval and __kernel_timespec redirects can be removed
after having served their purpose.
This makes it all much less confusing, as the __kernel_* types
now always refer to the same layout based on 64-bit time_t across
From: Deepa Dinamani
struct timex is not y2038 safe.
Switch all the syscall apis to use y2038 safe __kernel_timex.
Note that sys_adjtimex() does not have a y2038 safe solution. C libraries
can implement it by calling clock_adjtime(CLOCK_REALTIME, ...).
Signed-off-by: Deepa Dinamani
A lot of system calls that pass a time_t somewhere have an implementation
using a COMPAT_SYSCALL_DEFINEx() on 64-bit architectures, and have
been reworked so that this implementation can now be used on 32-bit
architectures as well.
The missing step is to redefine them using the regular
We want to reuse the compat_timex handling on 32-bit architectures the
same way we are using the compat handling for timespec when moving to
64-bit time_t.
Move all definitions related to compat_timex out of the compat code
into the normal timekeeping code, along with a rename to old_timex32,
From: Deepa Dinamani
struct timex is not y2038 safe.
Replace all uses of timex with y2038 safe __kernel_timex.
Note that struct __kernel_timex is an ABI interface definition.
We could define a new structure based on __kernel_timex that
is only available internally instead. Right now, there
This is the big flip, where all 32-bit architectures set COMPAT_32BIT_TIME
abd use the _time32 system calls from the former compat layer instead
of the system calls that take __kernel_timespec and similar arguments.
The temporary redirects for __kernel_timespec, __kernel_itimerspec
and
A small typo has crept into the y2038 conversion of the timer_settime
system call. So far this was completely harmless, but once we start
using the new version, this has to be fixed.
Fixes: 6ff847350702 ("time: Change types to new y2038 safe __kernel_itimerspec")
Signed-off-by: Arnd Bergmann
---
sparc64 is the only architecture on Linux that has a 'timeval'
definition with a 32-bit tv_usec but a 64-bit tv_sec. This causes
problems for sparc32 compat mode when we convert it to use the
new __kernel_timex type that has the same layout as all other
64-bit architectures.
To avoid adding
From: Deepa Dinamani
struct timex uses struct timeval internally.
struct timeval is not y2038 safe.
Introduce a new UAPI type struct __kernel_timex
that is y2038 safe.
struct __kernel_timex uses a timeval type that is
similar to struct __kernel_timespec which preserves the
same structure size
On Thu, Jan 10, 2019 at 5:39 PM Will Deacon wrote:
>
> > diff --git a/arch/arm64/include/asm/unistd32.h
> > b/arch/arm64/include/asm/unistd32.h
> > index 355fe2bc035b..19f3f58b6146 100644
> > --- a/arch/arm64/include/asm/unistd32.h
> > +++ b/arch/arm64/include/asm/unistd32.h
> > @@ -823,6 +823,8
From: Ravi Bangoria
We use syscall.tbl to generate system call table on powerpc.
The unistd.h copy is no longer required now. Remove it.
Signed-off-by: Ravi Bangoria
Cc: Jiri Olsa
Cc: Michael Ellerman
Cc: Namhyung Kim
Cc: linuxppc-dev@lists.ozlabs.org
Link:
On Thu, Jan 10, 2019 at 5:32 PM Will Deacon wrote:
> > diff --git a/arch/arm64/include/asm/unistd32.h
> > b/arch/arm64/include/asm/unistd32.h
> > index 04ee190b90fe..355fe2bc035b 100644
> > --- a/arch/arm64/include/asm/unistd32.h
> > +++ b/arch/arm64/include/asm/unistd32.h
> > @@ -821,6 +821,8
On Thu, Jan 10, 2019 at 5:59 PM Geert Uytterhoeven wrote:
>
> Hi Arnd,
>
> On Thu, Jan 10, 2019 at 5:26 PM Arnd Bergmann wrote:
> > The system call tables have diverged a bit over the years, and a number
> > of the recent additions never made it into all architectures, for one
> > reason or
Hi Arnd,
On Thu, Jan 10, 2019 at 5:26 PM Arnd Bergmann wrote:
> The system call tables have diverged a bit over the years, and a number
> of the recent additions never made it into all architectures, for one
> reason or another.
>
> This is an attempt to clean it up as far as we can without
From: Ravi Bangoria
Commit aff850393200 ("powerpc: add system call table generation
support") changed how systemcall table is generated for powerpc.
Incorporate these changes into perf as well.
Committer testing:
$ podman run --entrypoint=/bin/sh --privileged -v /home/acme/git:/git --rm
-ti
On Thu, Jan 10, 2019 at 05:24:27PM +0100, Arnd Bergmann wrote:
> A couple of architectures including arm64 already implement the
> kexec_file_load system call, on many others we have assigned a system
> call number for it, but not implemented it yet.
>
> Adding the number in arch/arm/ lets us use
__kernel_timespec and timespec are currently the same type, but once
they are different, the type cast has to be changed here.
Signed-off-by: Arnd Bergmann
---
arch/sparc/kernel/sys_sparc_64.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/sparc/kernel/sys_sparc_64.c
The behavior of these system calls is slightly different between
architectures, as determined by the CONFIG_ARCH_WANT_IPC_PARSE_VERSION
symbol. Most architectures that implement the split IPC syscalls don't set
that symbol and only get the modern version, but alpha, arm, microblaze,
mips-n32,
Other architectures commonly use __NR_umount2 for sys_umount,
only ia64 and alpha use __NR_umount here. In order to synchronize
the generated tables, use umount2 like everyone else, and add back
the old name from asm/unistd.h for compatibility.
The __IGNORE_* lines are now all obsolete and can be
The migrate_pages system call has an assigned number on all architectures
except ARM. When it got added initially in commit d80ade7b3231 ("ARM:
Fix warning: #warning syscall migrate_pages not implemented"), it was
intentionally left out based on the observation that there are no 32-bit
ARM NUMA
The io_pgetevents system call was added in linux-4.18 but has
no entry for alpha:
warning: #warning syscall io_pgetevents not implemented [-Wcpp]
Assign a the next system call number here.
Cc: sta...@vger.kernel.org
Signed-off-by: Arnd Bergmann
---
arch/alpha/kernel/syscalls/syscall.tbl | 1 +
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 consistency. If we decide to add them later to one of these, the
system
On Thu, Jan 10, 2019 at 05:24:26PM +0100, Arnd Bergmann wrote:
> The migrate_pages system call has an assigned number on all architectures
> except ARM. When it got added initially in commit d80ade7b3231 ("ARM:
> Fix warning: #warning syscall migrate_pages not implemented"), it was
> intentionally
On Thu, Jan 10, 2019 at 08:10:43AM +0100, Christophe Leroy wrote:
> Le 10/01/2019 à 02:42, Joel Stanley a écrit :
> >From: Daniel Axtens
> >
> >All 64-bit objects need to specify the flag to be compiled correctly, we
> >just don't need it for 32-bit objects. GCC just ignored it, but clang
>
The system call tables have diverged a bit over the years, and a number
of the recent additions never made it into all architectures, for one
reason or another.
This is an attempt to clean it up as far as we can without breaking
compatibility, doing a number of steps:
- Add system calls that
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 that set it implicitly.
For the additon of a y2083 safe semtimedop() system
When I merged this patch, the file was accidentally left intact
instead of being removed, which means any changes to syscall.tbl
have no effect.
Fixes: 2b3c5a99d5f3 ("sh: generate uapi header and syscall table header files")
Signed-off-by: Arnd Bergmann
---
arch/sh/include/uapi/asm/unistd_32.h
statx is available on almost all other architectures but
got missed on sh, so add it now.
Signed-off-by: Arnd Bergmann
---
arch/sh/kernel/syscalls/syscall.tbl | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/sh/kernel/syscalls/syscall.tbl
b/arch/sh/kernel/syscalls/syscall.tbl
index
A couple of architectures including arm64 already implement the
kexec_file_load system call, on many others we have assigned a system
call number for it, but not implemented it yet.
Adding the number in arch/arm/ lets us use the system call on arm64
systems in compat mode, and also reduces the
Most architectures have assigned a numbers for the seccomp syscall
even when they do not implement it.
m68k is an exception here, so for consistency lets add the number.
Unless CONFIG_SECCOMP is implemented, the system call just
returns -ENOSYS.
Signed-off-by: Arnd Bergmann
---
All architectures should implement these two, so assign numbers
and hook them up on ia64.
Signed-off-by: Arnd Bergmann
---
arch/ia64/kernel/syscalls/syscall.tbl | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/ia64/kernel/syscalls/syscall.tbl
b/arch/ia64/kernel/syscalls/syscall.tbl
Other architectures commonly use __NR_umount2 for sys_umount,
only ia64 and alpha use __NR_umount here. In order to synchronize
the generated tables, use umount2 like everyone else, and add back
the old name from asm/unistd.h for compatibility.
For shmat, alpha uses the osf_shmat name, we can do
Most architectures have assigned numbers for both seccomp and
perf_event_open, even when they do not implement either.
ia64 is an exception here, so for consistency lets add numbers for both
of them. Unless CONFIG_PERF_EVENTS and CONFIG_SECCOMP are implemented,
the system calls just return
While reading through the sysvipc implementation, I noticed that the n32
semctl/shmctl/msgctl system calls behave differently based on whether
o32 support is enabled or not: Without o32, the IPC_64 flag passed by
user space is rejected but calls without that flag get IPC_64 behavior.
As far as I
On 8xx, large pages (512kb or 8M) are used to map kernel linear
memory. Aligning to 8M reduces TLB misses as only 8M pages are used
in that case.
This patchs allows the user to do it via Kconfig.
Signed-off-by: Christophe Leroy
---
arch/powerpc/Kconfig | 16 ++--
This patch implements handling of STRICT_KERNEL_RWX with
large TLBs directly in the TLB miss handlers.
To do so, etext and sinittext are aligned on 512kB boundaries
and the miss handlers use 512kB pages instead of 8Mb pages for
addresses close to the boundaries.
It sets RO PP flags for addresses
Depending on the number of available BATs for mapping the different
kernel areas, it might be needed to increase the alignment of _etext
and/or of data areas.
This patchs allows the user to do it via Kconfig.
Signed-off-by: Christophe Leroy
---
arch/powerpc/Kconfig | 32
Today, STRICT_KERNEL_RWX is based on the use of regular pages
to map kernel pages.
On Book3s 32, it has three consequences:
- Using pages instead of BAT for mapping kernel linear memory severely
impacts performance.
- Exec protection is not effective because no-execute cannot be set at
page level
CONFIG_STRICT_KERNEL_RWX requires a special alignment
for DATA for some subarches. Today it is just defined
as an #ifdef in vmlinux.lds.S
In order to get more flexibility, this patch moves the
definition of this alignment in Kconfig
On some subarches, CONFIG_STRICT_KERNEL_RWX will
require a
This patch defined CONFIG_PPC_PAGE_SHIFT in order
to be able to use PAGE_SHIFT value inside Kconfig.
Signed-off-by: Christophe Leroy
---
arch/powerpc/Kconfig| 7 +++
arch/powerpc/include/asm/page.h | 13 ++---
2 files changed, 9 insertions(+), 11 deletions(-)
diff
Add a helper to know whether STRICT_KERNEL_RWX is enabled.
This is based on rodata_enabled flag which is defined only
when CONFIG_STRICT_KERNEL_RWX is selected.
Signed-off-by: Christophe Leroy
---
arch/powerpc/include/asm/mmu.h | 11 +++
arch/powerpc/mm/init_32.c | 4 +---
2
This patch add an helper which wraps 'mtsrin' instruction
to write into segment registers.
Signed-off-by: Christophe Leroy
---
arch/powerpc/include/asm/reg.h | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/powerpc/include/asm/reg.h b/arch/powerpc/include/asm/reg.h
index
setibat() and clearibat() allows to manipulate IBATs independently
of DBATs.
update_bats() allows to update bats after init. This is done
with MMU off.
Signed-off-by: Christophe Leroy
---
arch/powerpc/include/asm/book3s/32/mmu-hash.h | 2 ++
arch/powerpc/kernel/head_32.S | 35
Do not set IBAT when setbat() is called without _PAGE_EXEC
Signed-off-by: Christophe Leroy
---
arch/powerpc/mm/ppc_mmu_32.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/mm/ppc_mmu_32.c b/arch/powerpc/mm/ppc_mmu_32.c
index b8a8d55f51a6..42320688e415
wii_mmu_mapin_mem2() is not used anymore, remove it.
Signed-off-by: Christophe Leroy
---
arch/powerpc/platforms/embedded6xx/wii.c | 24
1 file changed, 24 deletions(-)
diff --git a/arch/powerpc/platforms/embedded6xx/wii.c
b/arch/powerpc/platforms/embedded6xx/wii.c
When CONFIG_BDI_SWITCH is set, the page tables have to be populated
allthough large TLBs are used, because the BDI switch knows nothing
about those large TLBs which are handled directly in TLB miss logic.
Signed-off-by: Christophe Leroy
---
arch/powerpc/mm/pgtable_32.c | 5 -
1 file
Now that mmu_mapin_ram() is able to handle other blocks
than the one starting at 0, the WII can use it for all
its blocks.
Signed-off-by: Christophe Leroy
---
arch/powerpc/mm/pgtable_32.c | 25 +++--
1 file changed, 7 insertions(+), 18 deletions(-)
diff --git
This patch reworks mmu_mapin_ram() to be more generic and map as much
blocks as possible. It now supports blocks not starting at address 0.
It scans DBATs array to find free ones instead of forcing the use of
BAT2 and BAT3.
Signed-off-by: Christophe Leroy
---
arch/powerpc/mm/ppc_mmu_32.c | 61
At the time being, mmu_mapin_ram() always maps RAM from the beginning.
But some platforms like the WII have to map a second block of RAM.
This patch adds to mmu_mapin_ram() the base address of the block.
At the moment, only base address 0 is supported.
Signed-off-by: Christophe Leroy
---
The purpose of this serie is to:
- use BATs with STRICT_KERNEL_RWX on book3s (See patch 12 for details.)
- use LTLBs with STRICT_KERNEL_RWX on 8xx (See patch 14 for a few details.)
v2:
- Fix patch 2 (was patch 3 in v1) based on feedback from Jonathan.
- Added support for 8xx with LTLBs.
- Added
On Wed, Jan 09, 2019 at 06:58:56PM -0800, Tyrel Datwyler wrote:
> While mapping DMA for scatter list when a scsi command is queued the
> existing call to dma_alloc_coherent() in our map_sg_data() function
> passes zero for the gfp_flags parameter. We are most definitly in atomic
> context at this
On 01/09/2019 08:59 PM, Tyrel Datwyler wrote:
> During driver probe we allocate a dma region for our event pool.
> Currently, zero is passed for the gfp_flags parameter. Driver probe
> callbacks run in process context and we hold no locks so we can sleep
> here if necessary.
>
> Fix by passing
On 01/09/2019 08:58 PM, Tyrel Datwyler wrote:
> While mapping DMA for scatter list when a scsi command is queued the
> existing call to dma_alloc_coherent() in our map_sg_data() function
> passes zero for the gfp_flags parameter. We are most definitly in atomic
> context at this point as
This patch replaces most #ifdef mess by IS_ENABLED() in 8xx_mmu.c
This has the advantage of allowing syntax verification at compile
time regardless of selected options.
Signed-off-by: Christophe Leroy
---
arch/powerpc/mm/8xx_mmu.c | 65 +--
1 file
Christophe Leroy writes:
> Le 10/01/2019 à 02:42, Joel Stanley a écrit :
>> From: Daniel Axtens
>>
>> All 64-bit objects need to specify the flag to be compiled correctly, we
>> just don't need it for 32-bit objects. GCC just ignored it, but clang
>> doesn't.
>>
>> Link:
On Tue, Jan 08, 2019 at 06:56:46AM +, Christophe Leroy wrote:
> This patch moves the mapping of IV after the kmalloc(). This
> avoids having to unmap in case kmalloc() fails.
>
> Signed-off-by: Christophe Leroy
> ---
> new in v4
>
> drivers/crypto/talitos.c | 25 +++--
Now that perf_flags is not used we remove it.
Signed-off-by: Andrew Murray
---
include/uapi/linux/perf_event.h | 2 --
tools/include/uapi/linux/perf_event.h | 2 --
2 files changed, 4 deletions(-)
diff --git a/include/uapi/linux/perf_event.h b/include/uapi/linux/perf_event.h
index
For x86 PMUs that do not support context exclusion let's advertise the
PERF_PMU_CAP_NO_EXCLUDE capability. This ensures that perf will
prevent us from handling events where any exclusion flags are set.
Let's also remove the now unnecessary check for exclusion flags.
This change means that
For drivers that do not support context exclusion let's advertise the
PERF_PMU_CAP_NOEXCLUDE capability. This ensures that perf will
prevent us from handling events where any exclusion flags are set.
Let's also remove the now unnecessary check for exclusion flags.
PMU drivers that support at
For PowerPC PMUs that do not support context exclusion let's
advertise the PERF_PMU_CAP_NO_EXCLUDE capability. This ensures that
perf will prevent us from handling events where any exclusion flags
are set. Let's also remove the now unnecessary check for exclusion
flags.
Signed-off-by: Andrew
For drivers that do not support context exclusion let's advertise the
PERF_PMU_CAP_NO_EXCLUDE capability. This ensures that perf will
prevent us from handling events where any exclusion flags are set.
Let's also remove the now unnecessary check for exclusion flags.
This change means that
For drivers that do not support context exclusion let's advertise the
PERF_PMU_CAP_NO_EXCLUDE capability. This ensures that perf will
prevent us from handling events where any exclusion flags are set.
Let's also remove the now unnecessary check for exclusion flags.
Signed-off-by: Andrew Murray
1 - 100 of 127 matches
Mail list logo
