Le 09/08/2022 à 04:44, Russell Currey a écrit :
> The Hash MMU already supports XOM (i.e. mmap with PROT_EXEC only)
> through the execute-only pkey. A PROT_EXEC-only mapping will actually
> map to RX, and then the pkey will be applied on top of it.
I don't think XOM is a commonly understood
clang 14 won't build because ret is uninitialised and can be returned if
both prop and fdtprop are NULL.
Fixes: b1fc44eaa9ba ("pseries/iommu/ddw: Fix kdump to work in absence of
ibm,dma-window")
Signed-off-by: Russell Currey
---
Not sure what should be returned here, EINVAL seemed reasonable
Le 09/08/2022 à 02:55, Russell Currey a écrit :
> On Mon, 2022-08-08 at 14:32 +, Christophe Leroy wrote:
>>
>>
>> Le 08/08/2022 à 15:01, Russell Currey a écrit :
>>> protection_map is about to be __ro_after_init instead of const, so
>>> move
>>> the only non-local function that consumes it
On 08/08/2022 18:16, Sean Anderson wrote:
>
>> This entry here is not
>> parsed for any tools and only sometimes people look at it. The questions
>> are directed via entry in maintainers file or via git history, so you
>> can put company email just there.
>
> As I understand it, the email is
The Hash MMU already supports XOM (i.e. mmap with PROT_EXEC only)
through the execute-only pkey. A PROT_EXEC-only mapping will actually
map to RX, and then the pkey will be applied on top of it.
Radix doesn't have pkeys, but it does have execute permissions built-in
to the MMU, so all we have to
On Mon, 2022-08-08 at 18:54 +0530, Aneesh Kumar K V wrote:
> On 8/8/22 6:31 PM, Russell Currey wrote:
> > The Hash MMU already supports XOM (i.e. mmap with PROT_EXEC only)
> > through the execute-only pkey. A PROT_EXEC-only mapping will
> > actually
> > map to RX, and then the pkey will be
On Mon, 2022-08-08 at 18:28 +0530, Aneesh Kumar K V wrote:
> On 8/8/22 5:28 PM, Russell Currey wrote:
> > The Hash MMU already supports XOM (i.e. mmap with PROT_EXEC only)
> > through the execute-only pkey. A PROT_ONLY mapping will actually
> > map to
> > RX, and then the pkey will be applied on
On Mon, 2022-08-08 at 14:32 +, Christophe Leroy wrote:
>
>
> Le 08/08/2022 à 15:01, Russell Currey a écrit :
> > protection_map is about to be __ro_after_init instead of const, so
> > move
> > the only non-local function that consumes it to the same file so it
> > can
> > at least be static.
> Well, of course we need the patch build, so SYSCALL_DEFINE and
> COMPAT_SYSCALL_DEFINE have to go with the name changes, that's obvious.
>
> My comment was more related to changes like the renaming of
> ppc64_personality() to do_ppc64_personality() and the creation of
>
On Friday 10 June 2022 00:24:20 Pali Rohár wrote:
> On Friday 20 May 2022 14:30:02 Pali Rohár wrote:
> > + linux-mm
> >
> > Do you know what are requirements for kernel to support non-contiguous
> > memory support and what is needed to enable it for 32-bit powerpc?
>
> Any hints?
PING?
> >
Hi Alexey,
This change is now in mainline as commit b1fc44eaa9ba
("pseries/iommu/ddw: Fix kdump to work in absence of ibm,dma-window").
> diff --git a/arch/powerpc/kexec/file_load_64.c
> b/arch/powerpc/kexec/file_load_64.c
> index b4981b651d9a..5d2c22aa34fb 100644
> ---
On Mon, Aug 08, 2022 at 04:31:06PM +, Christophe Leroy wrote:
>
>
> Le 08/08/2022 à 17:43, gjo...@linux.vnet.ibm.com a écrit :
> > From: Greg Joyce
> >
> > Generic kernel subsystems may rely on platform specific persistent
> > KeyStore to store objects containing sensitive key material. In
Le 08/08/2022 à 17:43, gjo...@linux.vnet.ibm.com a écrit :
> From: Greg Joyce
>
> Self Encrypting Drives(SED) make use of POWER LPAR Platform KeyStore
> for storing its variables. Thus the block subsystem needs to access
> PowerPC specific functions to read/write objects in PLPKS.
>
>
Le 08/08/2022 à 17:43, gjo...@linux.vnet.ibm.com a écrit :
> From: Greg Joyce
>
> Generic kernel subsystems may rely on platform specific persistent
> KeyStore to store objects containing sensitive key material. In such case,
> they need to access architecture specific functions to perform
From: Greg Joyce
Generic kernel subsystems may rely on platform specific persistent
KeyStore to store objects containing sensitive key material. In such case,
they need to access architecture specific functions to perform read/write
operations on these variables.
Define the generic variable
From: Greg Joyce
Self Encrypting Drives(SED) make use of POWER LPAR Platform KeyStore
for storing its variables. Thus the block subsystem needs to access
PowerPC specific functions to read/write objects in PLPKS.
Override the default implementations in lib/arch_vars.c file with
PowerPC specific
From: Greg Joyce
Changelog v3a:
- No code changes, but per reviewer requests, adding additional
mailing lists(keyring, EFI) for wider review.
Architectural neutral functions have been defined for accessing
architecture specific variable store. The neutral functions are
defined
On 8/8/22 1:46 AM, Krzysztof Kozlowski wrote:
> On 05/08/2022 17:17, Sean Anderson wrote:
>>
>>
>> On 8/5/22 2:53 AM, Krzysztof Kozlowski wrote:
>>> On 05/08/2022 00:05, Sean Anderson wrote:
This adds ids for the Lynx 10g SerDes's internal PLLs. These may be used
witn
Le 08/08/2022 à 15:01, Russell Currey a écrit :
> protection_map is about to be __ro_after_init instead of const, so move
> the only non-local function that consumes it to the same file so it can
> at least be static.
What's the advantage of doing that ? Why does it need to be static ?
On 8/8/22 6:31 PM, Russell Currey wrote:
> The Hash MMU already supports XOM (i.e. mmap with PROT_EXEC only)
> through the execute-only pkey. A PROT_EXEC-only mapping will actually
> map to RX, and then the pkey will be applied on top of it.
>
> Radix doesn't have pkeys, but it does have execute
Add a new function get_task_cmdline_kernel() which reads the command
line of a process into a kernel buffer. This command line can then be
dumped by arch code to give additional debug info via the parameters
with which a faulting process was started.
The new function re-uses the existing code
This patch series dumps the command line (including the program parameters) of
a faulting process to the syslog.
The motivation for this patch is that it's sometimes quite hard to find out and
annoying to not know which program *exactly* faulted when looking at the syslog.
For example, a dump on
Add the function dump_stack_print_cmdline() which can be used by arch
code to print the command line of the current processs. This function
is useful in arch code when dumping information for a faulting process.
Wire this function up in the dump_stack_print_info() function to include
the dumping
If a process segfaults, include the command line of the faulting process
in the syslog.
In the example below, the "crash" program (which simply writes zero to address
0)
was called with the parameters "this is a test":
crash[2326]: segfault at 0 ip 561a7969c12e sp 7ffe97a05630 error 6
The process program name and command line is now shown in generic code
in dump_stack_print_info(), so drop the arc-specific implementation.
Signed-off-by: Helge Deller
---
arch/arc/kernel/troubleshoot.c | 24
1 file changed, 24 deletions(-)
diff --git
The Hash MMU already supports XOM (i.e. mmap with PROT_EXEC only)
through the execute-only pkey. A PROT_EXEC-only mapping will actually
map to RX, and then the pkey will be applied on top of it.
Radix doesn't have pkeys, but it does have execute permissions built-in
to the MMU, so all we have to
protection_map is about to be __ro_after_init instead of const, so move
the only non-local function that consumes it to the same file so it can
at least be static.
Signed-off-by: Russell Currey
---
v2: new
arch/powerpc/mm/book3s64/pgtable.c | 16
arch/powerpc/mm/pgtable.c
On 8/8/22 5:28 PM, Russell Currey wrote:
> The Hash MMU already supports XOM (i.e. mmap with PROT_EXEC only)
> through the execute-only pkey. A PROT_ONLY mapping will actually map to
> RX, and then the pkey will be applied on top of it.
>
> Radix doesn't have pkeys, but it does have execute
Do not run objtool on VDSO files, by using
OBJECT_FILES_NON_STANDARD
Suggested-by: Christophe Leroy
Signed-off-by: Sathvika Vasireddy
---
arch/powerpc/kernel/vdso/Makefile | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/powerpc/kernel/vdso/Makefile
The Hash MMU already supports XOM (i.e. mmap with PROT_EXEC only)
through the execute-only pkey. A PROT_ONLY mapping will actually map to
RX, and then the pkey will be applied on top of it.
Radix doesn't have pkeys, but it does have execute permissions built-in
to the MMU, so all we have to do
This patch enables objtool --mcount on powerpc, and
adds implementation specific to powerpc.
Signed-off-by: Sathvika Vasireddy
---
arch/powerpc/Kconfig | 1 +
tools/objtool/arch/powerpc/decode.c | 22 +++
This patch adds [stub] implementations for required
functions, inorder to enable objtool build on powerpc.
Signed-off-by: Sathvika Vasireddy
[Christophe Leroy: powerpc: Add missing asm/asm.h for objtool]
Signed-off-by: Christophe Leroy
---
arch/powerpc/Kconfig | 1 +
Add architecture specific function to look for
relocation records pointing to arch specific
symbols.
Suggested-by: Christophe Leroy
Signed-off-by: Sathvika Vasireddy
---
tools/objtool/arch/x86/decode.c | 8
tools/objtool/check.c| 2 +-
Make relocation types architecture specific.
Signed-off-by: Sathvika Vasireddy
---
tools/objtool/arch/x86/include/arch/elf.h | 2 ++
tools/objtool/check.c | 2 +-
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/tools/objtool/arch/x86/include/arch/elf.h
This patch reads special sections which have alternate
instructions, only when stackval or orc or uaccess or
noinstr options are passed to objtool.
Signed-off-by: Sathvika Vasireddy
---
tools/objtool/check.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git
Architectures can select HAVE_NOP_MCOUNT if they choose
to nop out mcount call sites. If that config option is
selected, then --mnop is passed as an option to objtool,
along with --mcount.
Also, make sure that --mnop can be passed as an option
to objtool only when --mcount is passed.
From: Christophe Leroy
In order to allow using objtool on cross-built kernels,
determine size of long from elf data instead of using
sizeof(long) at build time.
For the time being this covers only mcount.
Signed-off-by: Christophe Leroy
---
tools/objtool/check.c | 16
From: Christophe Leroy
Some architectures like powerpc support both endianness, it's
therefore not possible to fix the endianness via arch/endianness.h
because there is no easy way to get the target endianness at
build time.
Use the endianness recorded in the file objtool is working on.
From: Christophe Leroy
find_insn() will return NULL in case of failure. Check insn in order
to avoid a kernel Oops for NULL pointer dereference.
Signed-off-by: Christophe Leroy
---
tools/objtool/check.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/objtool/check.c
From: Christophe Leroy
Fix several annotations in assembly files on PPC32.
Signed-off-by: Christophe Leroy
[Sathvika Vasireddy: Changed subject line from objtool/powerpc: Activate
objtool on PPC32
to powerpc: Fix objtool unannotated intra-function call warnings on PPC32, and
removed
Kconfig
With objtool enabled, below warnings are seen when trying to build:
drivers/crypto/vmx/aesp8-ppc.o: warning: objtool: aes_p8_set_encrypt_key+0x44:
unannotated intra-function call
drivers/crypto/vmx/aesp8-ppc.o: warning: objtool: .text+0x2448: unannotated
intra-function call
objtool throws unannotated intra-function call warnings
in the following assembly files.
arch/powerpc/kernel/vector.o: warning: objtool: .text+0x53c: unannotated
intra-function call
arch/powerpc/kvm/book3s_hv_rmhandlers.o: warning: objtool: .text+0x60:
unannotated intra-function call
objtool throws the following unannotated intra-function call
warnings:
arch/powerpc/kernel/entry_64.o: warning: objtool: .text+0x4: unannotated
intra-function call
arch/powerpc/kvm/book3s_hv_rmhandlers.o: warning: objtool: .text+0xe64:
unannotated intra-function call
Since we need an alignment of 4 bytes, override
__ALIGN() and __ALIGN_STR() accordingly.
Signed-off-by: Sathvika Vasireddy
---
arch/powerpc/include/asm/linkage.h | 4
1 file changed, 4 insertions(+)
diff --git a/arch/powerpc/include/asm/linkage.h
b/arch/powerpc/include/asm/linkage.h
objtool is throwing *unannotated intra-function call*
warnings with a few instructions that are marked
unreachable. Replace unreachable() with __builtin_unreachable()
to fix these warnings, as the codegen remains same
with unreachable() and __builtin_unreachable().
Signed-off-by: Sathvika
This patchset enables and implements objtool --mcount
option on powerpc. This applies atop powerpc/merge branch.
Christophe Leroy (4):
objtool: Fix SEGFAULT
objtool: Use target file endianness instead of a compiled constant
objtool: Use target file class size instead of a compiled constant
Le 25/07/2022 à 08:31, Rohan McLure a écrit :
> Interrupt handlers on 64s systems will often need to save register state
> from the interrupted process to make space for loading special purpose
> registers or for internal state.
>
> Fix a comment documenting a common code path macro in the
Le 25/07/2022 à 08:31, Rohan McLure a écrit :
> Use the convenience macros for saving/clearing/restoring gprs in keeping
> with syscall calling conventions. The plural variants of these macros
> can store a range of registers for concision.
>
> This works well when the save-to-stack logic is
Le 08/08/2022 à 09:42, Andrew Donnellan a écrit :
> On Mon, 2022-07-25 at 16:29 +1000, Rohan McLure wrote:
>> Macros for restoring and saving registers to and from the stack
>> exist.
>> Provide macros with the same interface for clearing a range of gprs
>> by
>> setting each register's value in
Le 25/07/2022 à 08:26, Rohan McLure a écrit :
> Syscall #82 has been implemented for 32-bit platforms in a unique way on
> powerpc systems. This hack will in effect guess whether the caller is
> expecting new select semantics or old select semantics. It does so via a
> guess, based off the first
Le 25/07/2022 à 08:27, Rohan McLure a écrit :
> Forward declare all syscall handler prototypes where a generic prototype
> is not provided in either linux/syscalls.h or linux/compat.h in
> asm/syscalls.h. This is required for compile-time type-checking for
> syscall handlers, which is
Le 25/07/2022 à 08:25, Rohan McLure a écrit :
> Syscall handlers should not be invoked internally by their symbol names,
> as these symbols defined by the architecture-defined SYSCALL_DEFINE
> macro. Move the compatibility syscall definition for mmap2 to
> syscalls.c, so that all mmap
Le 08/08/2022 à 08:04, Rohan McLure a écrit :
> Thanks for reviewing my patches.
>
>> I think this patch should be split in two patches. One where you just
>> change to using SYSCALL_DEFINE and COMPAT_SYSCALL_DEFINE, and a second
>> patch for everything else.
>>
>> The first patch could then be
On Mon, 2022-07-25 at 16:31 +1000, Rohan McLure wrote:
> Use the convenience macros for saving/clearing/restoring gprs in
> keeping
> with syscall calling conventions. The plural variants of these macros
> can store a range of registers for concision.
>
> This works well when the save-to-stack
Le 25/07/2022 à 08:30, Rohan McLure a écrit :
> Implement syscall wrapper as per s390, x86, arm64. When enabled
> cause handlers to accept parameters from a stack frame rather than
> from user scratch register state. This allows for user registers to be
> safely cleared in order to reduce caller
On Mon, 2022-07-25 at 16:29 +1000, Rohan McLure wrote:
> Macros for restoring and saving registers to and from the stack
> exist.
> Provide macros with the same interface for clearing a range of gprs
> by
> setting each register's value in that range to zero.
>
> The resulting macros are called
On Mon, 2022-07-25 at 16:28 +1000, Rohan McLure wrote:
> Cause syscall handlers to be typed as follows when called indirectly
> throughout the kernel.
>
> typedef long (*syscall_fn)(unsigned long, unsigned long, unsigned
> long,
> unsigned long, unsigned long, unsigned
>> --- a/arch/powerpc/kernel/asm-offsets.c
>> +++ b/arch/powerpc/kernel/asm-offsets.c
>> @@ -9,6 +9,7 @@
>> * #defines from the assembly-language output.
>> */
>>
>> +#include
>
> What's this for?
Good spot.
Thanks for reviewing my patches.
> I think this patch should be split in two patches. One where you just
> change to using SYSCALL_DEFINE and COMPAT_SYSCALL_DEFINE, and a second
> patch for everything else.
>
> The first patch could then be linked to
>
59 matches
Mail list logo
