On Tue 31-01-23 16:01:16, Suren Baghdasaryan wrote:
> Provide vm_flags_reset_once() and replace the vm_flags updates which used
> WRITE_ONCE() to prevent compiler optimizations.
>
> Fixes: 0cce31a0aa0e ("mm: replace vma->vm_flags direct modifications with
> modifier calls")
> Reported-by:
Extend PowerPC arch crash hotplug handler to support memory hotplug
events. Since elfcorehdr is used to exchange the memory info between the
kernels hence it needs to be recreated to reflect the changes due to
memory hotplug events.
The way memory hotplug events are handled on PowerPC and the
Introduce powerpc crash hotplug handler to update the necessary kexec
segments on CPU/Memory hotplug events. A common crash hotplug handler is
triggered from generic infrastructure for both CPU/Memory hot un/plugged
events but in this patch, only CPU hot un/plugged events are introduced.
The
The way memory hot remove is handled on PowerPC, it is hard to update
the elfcorehdr without memory_notify args.
On PowePC memblock data structure is used to prepare elfcorehdr for kdump.
Since the notifier used for memory hotplug crash handler get initiated
before the memblock data structure
On PowerPC, the crash update action for CPU and Memory hotplug events
is not the same. Since arch_crash_handle_hotplug_event is a common
crash hotplug handler for both CPU and Memory hot un/plug events,
it is hard to differentiate which hotplug event triggered the arch
crash hotplug handler and
Move update_cpus_node and get_crash_memory_ranges functions from
kexec/file_load.c to kexec/core_64.c to make these functions usable
by other kexec compoenets.
Later in the series, both functions are used for in-kernel updates to
kexec segments in the event of CPU/Memory hotplug for both
On architectures like PowerPC the crash notes are available for all
possible CPUs. So let's populate the elfcorehdr for all possible
CPUs having crash notes to avoid updating elfcorehdr during in-kernel
crash update on CPU hotplug events.
The similar technique is used in kexec-tool for kexec_load
Add a new member "fdt_index" to kimage_arch struct to hold the index of
the FDT (Flattened Device Tree) segment in the kexec segment array.
Having direct access to FDT segment will help arch crash hotplug handler
to avoid looping kexec segment array to identify the FDT segment index
for every FDT
The config option CRASH_HOTPLUG enables in kernel update to kexec
segments due to CPU/Memory hotplug events. By default it is disabled.
Signed-off-by: Sourabh Jain
---
arch/powerpc/Kconfig | 12
1 file changed, 12 insertions(+)
diff --git a/arch/powerpc/Kconfig
The Problem:
Post hotplug/DLPAR events the capture kernel holds stale information about the
system. Dump collection with stale capture kernel might end up in dump capture
failure or an inaccurate dump collection.
Existing solution:
==
The existing solution to keep the
The Problem:
Post hotplug/DLPAR events the capture kernel holds stale information about the
system. Dump collection with stale capture kernel might end up in dump capture
failure or an inaccurate dump collection.
Existing solution:
==
The existing solution to keep the
Move update_cpus_node and get_crash_memory_ranges functions from
kexec/file_load.c to kexec/core_64.c to make these functions usable
by other kexec compoenets.
Later in the series, both functions are used for in-kernel updates to
kexec segments in the event of CPU/Memory hotplug for both
On Tue, 2023-01-31 at 12:11 -0500, Stefan Berger wrote:
> > +static int plpks_get_variable(const char *key, u64 key_len, u8
> > *data,
> > + u64 *data_size)
> > +{
> > + struct plpks_var var = {0};
> > + int rc = 0;
> > +
> > + // We subtract 1 from
The only place on kexec/kdump path where we don't print
reason for FDT operation failure. This patch fix that.
Will this be a good candidate for next rc?
Thanks,
Sourabh
On 16/12/22 17:57, Sourabh Jain wrote:
Print the FDT error description along with the error message if failed
to set the
Enable HAVE_ARCH_KCSAN on all powerpc platforms, permitting use of the
kernel concurrency sanitiser through the CONFIG_KCSAN_* kconfig options.
See documentation in Documentation/dev-tools/kcsan.rst for more
information.
Signed-off-by: Rohan McLure
---
arch/powerpc/Kconfig | 1 +
1 file
Instrumented memory accesses provided by KCSAN will access core-local
memories (which will save and restore IRQs) as well as restoring IRQs
directly. Avoid recursive instrumentation by applying __no_kcsan
annotation to IRQ restore routines.
Signed-off-by: Rohan McLure
---
Annotate memory barriers *mb() with calls to kcsan_mb(), signaling to
compilers supporting KCSAN that the respective memory barrier has been
issued. Rename memory barrier *mb() to __*mb() to opt in for
asm-generic/barrier.h to generate the respective *mb() macro.
Signed-off-by: Rohan McLure
---
In order for KCSAN to increase its likelihood of observing a data race,
it sets a watchpoint on memory accesses and stalls, allowing for
detection of conflicting accesses by other kernel threads or interrupts.
Stalls are implemented by injecting a call to udelay in instrumented code.
To prevent
Exclude various incompatible compilation units from KCSAN
instrumentation.
Signed-off-by: Rohan McLure
---
arch/powerpc/kernel/Makefile | 10 ++
arch/powerpc/kernel/trace/Makefile | 1 +
arch/powerpc/kernel/vdso/Makefile | 1 +
arch/powerpc/lib/Makefile | 2 ++
Add Kernel Concurrency Sanitiser support for powerpc. Doing so involves
exclusion of a number of compilation units from instrumentation, as was
done with KASAN.
KCSAN uses watchpoints on memory accesses to enforce the semantics of
the Linux kernel memory model, notifying the user of observed data
On 01/02/23 07:25, Michael Ellerman wrote:
Sourabh Jain writes:
On 30/01/23 07:17, Michael Ellerman wrote:
In kexec_extra_fdt_size_ppc64() there's logic to estimate how much
extra space will be needed in the device tree for some memory related
properties.
That logic uses the size of RAM
On Tue, 2023-01-31 at 18:55 +1000, Nicholas Piggin wrote:
> > > > + var.datalen = 1;
> > > > + var.data = kzalloc(1, GFP_KERNEL);
> > >
> > > This could just point to a u8 on stack I think?
> >
> > Until we get VMAP_STACK and we'll have to switch back.
>
> AFAIKS plpks_read_var does
Sourabh Jain writes:
> On 30/01/23 07:17, Michael Ellerman wrote:
>> In kexec_extra_fdt_size_ppc64() there's logic to estimate how much
>> extra space will be needed in the device tree for some memory related
>> properties.
>>
>> That logic uses the size of RAM divided by drmem_lmb_size() to do
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git
fixes
branch HEAD: 111bcb37385353f0510e5847d5abcd1c613dba23 powerpc/64s/radix: Fix
RWX mapping with relocated kernel
elapsed time: 745m
configs tested: 61
configs skipped: 101
The following configs have been built
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git
next-test
branch HEAD: 5746ca131e2496ccd5bb4d7a0244d6c38070cbf5 powerpc/64: Don't
recurse irq replay
elapsed time: 720m
configs tested: 2
configs skipped: 115
The following configs have been built successfully.
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git
fixes-test
branch HEAD: 37e5bf9657c8af85b91dda79c14eee5b7e0406d7 powerpc/64s: Reconnect
tlb_flush() to hash__tlb_flush()
elapsed time: 745m
configs tested: 69
configs skipped: 106
The following configs have been
Add Kernel Concurrency Sanitiser support for powerpc. Doing so involves
exclusion of a number of compilation units from instrumentation, as was
done with KASAN.
KCSAN uses watchpoints on memory accesses to enforce the semantics of
the Linux kernel memory model, notifying the user of observed data
On Tue, Jan 31, 2023 at 3:12 PM Andrew Morton wrote:
>
> On Tue, 31 Jan 2023 13:08:19 -0800 Suren Baghdasaryan
> wrote:
>
> > On Tue, Jan 31, 2023 at 12:54 PM Andrew Morton
> > wrote:
> > >
> > > On Tue, 31 Jan 2023 10:54:22 -0800 Suren Baghdasaryan
> > > wrote:
> > >
> > > > > > -
Provide vm_flags_reset_once() and replace the vm_flags updates which used
WRITE_ONCE() to prevent compiler optimizations.
Fixes: 0cce31a0aa0e ("mm: replace vma->vm_flags direct modifications with
modifier calls")
Reported-by: Hyeonggon Yoo <42.hye...@gmail.com>
Signed-off-by: Suren Baghdasaryan
Enable HAVE_ARCH_KCSAN on all powerpc platforms, permitting use of the
kernel concurrency sanitiser through the CONFIG_KCSAN_* kconfig options.
See documentation in Documentation/dev-tools/kcsan.rst for more
information.
Signed-off-by: Rohan McLure
---
arch/powerpc/Kconfig | 1 +
1 file
Instrumented memory accesses provided by KCSAN will access core-local
memories (which will save and restore IRQs) as well as restoring IRQs
directly. Avoid recursive instrumentation by applying __no_kcsan
annotation to IRQ restore routines.
Signed-off-by: Rohan McLure
---
Annotate memory barriers *mb() with calls to kcsan_mb(), signaling to
compilers supporting KCSAN that the respective memory barrier has been
issued. Rename memory barrier *mb() to __*mb() to opt in for
asm-generic/barrier.h to generate the respective *mb() macro.
Signed-off-by: Rohan McLure
---
In order for KCSAN to increase its likelihood of observing a data race,
it sets a watchpoint on memory accesses and stalls, allowing for
detection of conflicting accesses by other kernel threads or interrupts.
Stalls are implemented by injecting a call to udelay in instrumented code.
To prevent
Exclude various incompatible compilation units from KCSAN
instrumentation.
Signed-off-by: Rohan McLure
---
arch/powerpc/kernel/Makefile | 10 ++
arch/powerpc/kernel/trace/Makefile | 1 +
arch/powerpc/kernel/vdso/Makefile | 1 +
arch/powerpc/lib/Makefile | 2 ++
On Tue, 31 Jan 2023 13:08:19 -0800 Suren Baghdasaryan wrote:
> On Tue, Jan 31, 2023 at 12:54 PM Andrew Morton
> wrote:
> >
> > On Tue, 31 Jan 2023 10:54:22 -0800 Suren Baghdasaryan
> > wrote:
> >
> > > > > - vma->vm_flags &= ~VM_MAYWRITE;
> > > > > +
On Tue, 2023-01-31 at 06:33 +, Christophe Leroy wrote:
> I still think it is not the correct fix. You are putting the problem
> under the carpet instead of fixing it. There are many other places
> where
> radix_enabled() or other mmu_has_feature() are used with the
> expectation
> that one
On Thu, 26 Jan 2023 22:39:30 -0800, Randy Dunlap wrote:
> Correct many spelling errors in Documentation/ as reported by codespell.
>
> Maintainers of specific kernel subsystems are only Cc-ed on their
> respective patches, not the entire series. [if all goes well]
>
> These patches are based on
On Tue, Jan 31, 2023 at 12:54 PM Andrew Morton
wrote:
>
> On Tue, 31 Jan 2023 10:54:22 -0800 Suren Baghdasaryan
> wrote:
>
> > > > - vma->vm_flags &= ~VM_MAYWRITE;
> > > > + vm_flags_clear(vma, VM_MAYSHARE);
> > > > }
> > >
> > > I think it should be:
> > >
On Tue, 31 Jan 2023 10:54:22 -0800 Suren Baghdasaryan wrote:
> > > - vma->vm_flags &= ~VM_MAYWRITE;
> > > + vm_flags_clear(vma, VM_MAYSHARE);
> > > }
> >
> > I think it should be:
> > s/VM_MAYSHARE/VM_MAYWRITE/
>
I added the fixup. Much better than
Hi Mike,
On Tue, Jan 31, 2023 at 08:41:49PM +0200, Mike Rapoport wrote:
> On Tue, Jan 31, 2023 at 05:47:24PM +, Conor Dooley wrote:
> > On Sun, Jan 29, 2023 at 02:42:35PM +0200, Mike Rapoport wrote:
> > > From: "Mike Rapoport (IBM)"
> > >
> > > Every architecture that supports FLATMEM
On Tue, Jan 31, 2023 at 12:32 AM Hyeonggon Yoo <42.hye...@gmail.com> wrote:
>
> On Thu, Jan 26, 2023 at 11:37:49AM -0800, Suren Baghdasaryan wrote:
> > Replace direct modifications to vma->vm_flags with calls to modifier
> > functions to be able to track flag changes and to keep vma locking
> >
Commit ec3eb9d941a9 ("powerpc/perf: Use PVR rather than
oprofile field to determine CPU version") added usage
of pvr value instead of oprofile field to determine the
platform. In hv-24x7 pmu driver code, pvr check uses PVR_POWER8
when assigning the interface version for power8 platform.
But power8
Hi Conor,
On Tue, Jan 31, 2023 at 05:47:24PM +, Conor Dooley wrote:
> Hey Mike,
>
> On Sun, Jan 29, 2023 at 02:42:35PM +0200, Mike Rapoport wrote:
> > From: "Mike Rapoport (IBM)"
> >
> > Every architecture that supports FLATMEM memory model defines its own
> > version of pfn_valid() that
Hey Mike,
On Sun, Jan 29, 2023 at 02:42:35PM +0200, Mike Rapoport wrote:
> From: "Mike Rapoport (IBM)"
>
> Every architecture that supports FLATMEM memory model defines its own
> version of pfn_valid() that essentially compares a pfn to max_mapnr.
>
> Use mips/powerpc version implemented as
On 1/31/23 01:39, Andrew Donnellan wrote:
From: Russell Currey
Add support for loading keys from the PLPKS on pseries machines, with the
"ibm,plpks-sb-v1" format.
The object format is expected to be the same, so there shouldn't be any
functional differences between objects retrieved on
On 1/31/23 01:39, Andrew Donnellan wrote:
From: Russell Currey
The pseries platform can support dynamic secure boot (i.e. secure boot
using user-defined keys) using variables contained with the PowerVM LPAR
Platform KeyStore (PLPKS). Using the powerpc secvar API, expose the
relevant
syscalls do not set the PPR field in their interrupt frame and return
from syscall always sets the default PPR for userspace, so setting the
value in the ret_from_fork frame is not necessary and mildly
inconsistent. Remove it.
Signed-off-by: Nicholas Piggin
---
arch/powerpc/kernel/process.c | 5
In the kernel user thread path, don't set _TIF_RESTOREALL because the
thread is required to call kernel_execve() before it returns, which will
set _TIF_RESTOREALL if necessary via start_thread().
Signed-off-by: Nicholas Piggin
---
arch/powerpc/kernel/interrupt_64.S | 5 +
Kernel created user threads start similarly to kernel threads in that
they call a kernel function after first returning from _switch, so they
share ret_from_kernel_thread for this. Kernel threads never return from
that function though, whereas user threads often do (although some
don't, e.g., IO
When copy_thread is given a kernel function to run in arg->fn, this does
not necessarily mean it is a kernel thread. User threads can be created
this way (e.g., kernel_init, see also x86's copy_thread). These user
threads run a kernel function which may kernel_execve and return, which
then returns
If the system call return path always restores NVGPRs then there is no
need for ret_from_fork to do it. The HANDLER_RESTORE_NVGPRS does the
right thing for this.
Signed-off-by: Nicholas Piggin
---
arch/powerpc/kernel/interrupt_64.S | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff
The kernel thread path in copy_thread creates a user interrupt frame on
stack and stores the function and arg parameters there, and
ret_from_kernel_thread loads them. This is a slightly confusing way to
overload that frame. Non-volatile registers are loaded from the switch
frame, so the parameters
The ret_from_fork code for 64e and 32-bit set r3 for
syscall_exit_prepare the same way that 64s does, so there should be no
need to special-case them in copy_thread.
Signed-off-by: Nicholas Piggin
---
arch/powerpc/kernel/entry_32.S | 2 +-
arch/powerpc/kernel/process.c | 3 ---
2 files
The pkey registers (AMR, IAMR) do not get loaded from the switch frame
so it is pointless to save anything there. Remove the dead code.
Signed-off-by: Nicholas Piggin
---
arch/powerpc/kernel/process.c | 12 +---
1 file changed, 1 insertion(+), 11 deletions(-)
diff --git
The way copy_thread works, particularly with kernel threads and kernel
created user threads is a bit muddled and confusing. This series tries
to straighten things out a bit.
Thanks,
Nick
Nicholas Piggin (8):
powerpc: copy_thread remove unused pkey code
powerpc: copy_thread make ret_from_fork
On 1/31/23 01:39, Andrew Donnellan wrote:
From: Russell Currey
Before interacting with the PLPKS, we ask the hypervisor to generate a
password for the current boot, which is then required for most further
PLPKS operations.
If we kexec into a new kernel, the new kernel will try and fail to
On 1/31/23 01:39, Andrew Donnellan wrote:
From: Russell Currey
Add helper function to get the PLPKS password length. This will be used
in a later patch to support passing the password between kernels over
kexec.
Signed-off-by: Russell Currey
Signed-off-by: Andrew Donnellan
Reviewed-by:
On 1/31/23 01:39, Andrew Donnellan wrote:
It seems a bit unnecessary for the PLPKS code to have a user-visible
config option when it doesn't do anything on its own, and there's existing
options for enabling Secure Boot-related features.
It should be enabled by PPC_SECURE_BOOT, which will
On 1/31/23 01:39, Andrew Donnellan wrote:
Currently, plpks_read_var() allocates a buffer to pass to the
H_PKS_READ_OBJECT hcall, then allocates another buffer, of the caller's
-> buffer of the (no comma)
preferred size if necessary, into which the data is copied, and returns
that buffer
On 1/31/23 01:39, Andrew Donnellan wrote:
From: Russell Currey
The plpks code converts hypervisor return codes into their Linux
equivalents so that users can understand them. Having access to the
original return codes is really useful for debugging, so add a
pr_debug() so we don't lose
On 1/31/23 01:39, Andrew Donnellan wrote:
From: Nayna Jain
The Platform Keystore provides a signed update interface which can be used
to create, replace or append to certain variables in the PKS in a secure
fashion, with the hypervisor requiring that the update be signed using the
Platform
On 1/31/23 01:39, Andrew Donnellan wrote:
From: Nayna Jain
The plpks driver uses the H_PKS_GET_CONFIG hcall to retrieve configuration
and status information about the PKS from the hypervisor.
Update _plpks_get_config() to handle some additional fields. Add getter
functions to allow the PKS
On 1/31/23 01:39, Andrew Donnellan wrote:
From: Russell Currey
Move the constants defined in plpks.c to plpks.h, and standardise their
naming, so that PLPKS consumers can make use of them later on.
Signed-off-by: Russell Currey
Co-developed-by: Andrew Donnellan
Signed-off-by: Andrew
On 1/31/23 01:39, Andrew Donnellan wrote:
From: Russell Currey
Move plpks.h from platforms/pseries/ to include/asm/. This is necessary
for later patches to make use of the PLPKS from code in other subsystems.
Signed-off-by: Russell Currey
Signed-off-by: Andrew Donnellan
---
v3: New
On 1/31/23 01:39, Andrew Donnellan wrote:
If attempting to read the size or data attributes of a non-existent
variable (which will be possible after a later patch to expose the PLPKS
via the secvar interface), don't spam the kernel log with error messages.
Only print errors for return codes
On 1/31/23 01:39, Andrew Donnellan wrote:
Due to sysfs constraints, when writing to a variable, we can only handle
writes of up to PAGE_SIZE.
It's possible that the maximum object size is larger than PAGE_SIZE, in
which case, print a warning on boot so that the user is aware.
Signed-off-by:
On 1/31/23 01:39, Andrew Donnellan wrote:
Currently, the list of variables is populated by calling
secvar_ops->get_next() repeatedly, which is explicitly modelled on the
OPAL API (including the keylen parameter).
For the upcoming PLPKS backend, we have a static list of variable names.
It is
On 1/31/23 01:39, Andrew Donnellan wrote:
From: Russell Currey
The forthcoming pseries consumer of the secvar API wants to expose a
number of config variables. Allowing secvar implementations to provide
their own sysfs attributes makes it easy for consumers to expose what
they need to.
On 1/31/23 01:39, Andrew Donnellan wrote:
Remove unnecessary prefixes from error messages in secvar_sysfs_init()
(the file defines pr_fmt, so putting "secvar:" in every message is
unnecessary). Make capitalisation and punctuation more consistent.
Signed-off-by: Andrew Donnellan
On 1/31/23 01:39, Andrew Donnellan wrote:
From: Russell Currey
Currently the max object size is handled in the core secvar code with an
entirely OPAL-specific implementation, so create a new max_size() op and
move the existing implementation into the powernv platform. Should be
no
On 1/31/23 01:39, Andrew Donnellan wrote:
From: Russell Currey
The code that handles the format string in secvar-sysfs.c is entirely
OPAL specific, so create a new "format" op in secvar_operations to make
the secvar code more generic. No functional change.
Signed-off-by: Russell Currey
On 1/31/23 01:39, Andrew Donnellan wrote:
From: Russell Currey
The secvar format string and object size sysfs files are both ASCII
text, and should use sysfs_emit(). No functional change.
Suggested-by: Greg Kroah-Hartman
Signed-off-by: Russell Currey
Signed-off-by: Andrew Donnellan
On 1/31/23 01:39, Andrew Donnellan wrote:
From: Russell Currey
secvar_ops->get_next() returns -ENOENT when there are no more variables
to return, which is expected behaviour.
Fix this by returning 0 if get_next() returns -ENOENT.
This fixes an issue introduced in commit bd5d9c743d38
On 1/31/23 01:39, Andrew Donnellan wrote:
From: Russell Currey
The secvar code only supports one consumer at a time.
Multiple consumers aren't possible at this point in time, but we'd want
it to be obvious if it ever could happen.
Signed-off-by: Russell Currey
Co-developed-by: Andrew
On 24.01.23 06:42, Alistair Popple wrote:
Kernel drivers that pin pages should account these pages against
either user->locked_vm or mm->pinned_vm and fail the pinning if
RLIMIT_MEMLOCK is exceeded and CAP_IPC_LOCK isn't held.
Currently drivers open-code this accounting and use various methods
"bpf" tests fails in environment with missing libtraceevent
support as below:
# ./perf test 36
36: BPF filter :
36.1: Basic BPF filtering : FAILED!
36.2: BPF pinning
While parsing the tracepoint events in parse_events_add_tracepoint()
function, code checks for HAVE_LIBTRACEEVENT support. This is needed
since libtraceevent is necessary for tracepoint. But while adding
probe points, check for LIBTRACEEVENT is not done in case of perf probe.
Hence, in environment
Ganesh Goudar writes:
> For all unrecoverable errors we are missing to log the
> error, Since machine_check_log_err() is not getting called
> for unrecoverable errors.
>
> Raise irq work in save_mce_event() for unrecoverable errors,
> So that we log the error from MCE event handling block in
>
Commit baf1ed24b27d ("powerpc/mm: Remove empty hash__ functions")
removed some empty hash MMU flushing routines, but got a bit overeager
and also removed the call to hash__tlb_flush() from tlb_flush().
In regular use this doesn't lead to any noticable breakage, which is a
little concerning.
Le 10/01/2023 à 09:44, Naveen N. Rao a écrit :
> Christophe Leroy wrote:
>>
>>
>> Le 13/12/2022 à 11:23, Naveen N. Rao a écrit :
>>> Christophe Leroy wrote:
BPF core calls the jit compiler again for an extra pass in order
to properly set subprog addresses.
Unlike other
Hello Michael,
On 30/01/23 07:17, Michael Ellerman wrote:
In kexec_extra_fdt_size_ppc64() there's logic to estimate how much
extra space will be needed in the device tree for some memory related
properties.
That logic uses the size of RAM divided by drmem_lmb_size() to do the
estimation.
On Tue Jan 31, 2023 at 12:54 PM AEST, Andrew Donnellan wrote:
> On Tue, 2023-01-24 at 15:17 +1000, Nicholas Piggin wrote:
> > > +static const char * const plpks_var_names[] = {
> > > + "PK",
> > > + "KEK",
> > > + "db",
> > > + "dbx",
> > > + "grubdb",
> > > +
On Thu, Jan 26, 2023 at 11:37:49AM -0800, Suren Baghdasaryan wrote:
> Replace direct modifications to vma->vm_flags with calls to modifier
> functions to be able to track flag changes and to keep vma locking
> correctness.
>
> Signed-off-by: Suren Baghdasaryan
> Acked-by: Michal Hocko
>
Nicholas Miehlbradt writes:
> Walks the stack when copy_{to,from}_user address is in the stack to
> ensure that the object being copied is entirely within a single stack
> frame.
... and that it exists above the parameter save area, so is not pointing
at any stack metadata right?
> Substatially
84 matches
Mail list logo
