On Fri, 2024-06-21 at 16:27 -0400, Peter Xu wrote:
> On Fri, Jun 21, 2024 at 07:36:30PM +0000, Edgecombe, Rick P wrote:
> > On Fri, 2024-06-21 at 07:51 -0700, Dave Hansen wrote:
> > >
> > > But, still, what if you take a Dirty=1,Write=1 pud and pud_modify() it
>
On Fri, 2024-06-21 at 07:51 -0700, Dave Hansen wrote:
>
> But, still, what if you take a Dirty=1,Write=1 pud and pud_modify() it
> to make it Dirty=1,Write=0? What prevents that from being
> misinterpreted by the hardware as being a valid 1G shadow stack mapping?
Hmm, it looks like we could use
On Wed, 2024-03-13 at 06:44 +, Christophe Leroy wrote:
> I understand from this text that, as agreed, this patch removes the
> pointless/redundant zero-init of individual members. But it is not
> what
> is done, see below ?
Err, right. I think I decided to leave it because it was already ack
On Tue, 2024-03-05 at 11:51 +1100, Michael Ellerman wrote:
> I gave it a quick boot test, all good.
>
> Acked-by: Michael Ellerman (powerpc)
Thanks! Christophe was advocating for slight spin on this (not doing
the member initializing in the declaration, but dropping the
assignments that set 0):
On Mon, 2024-03-04 at 18:00 +, Christophe Leroy wrote:
> > Personally, I think a single patch that sets "= {}" for all of them
> > and
> > drop the all the "= 0" or "= NULL" assignments would be the
> > cleanest way
> > to go.
>
> I agree with Kees, set = {} and drop all the "something = 0;" s
On Wed, 2024-02-28 at 09:21 -0800, Kees Cook wrote:
> I totally understand. If the "uninitialized" warnings were actually
> reliable, I would agree. I look at it this way:
>
> - initializations can be missed either in static initializers or via
> run time initializers. (So the risk of mistake he
On Wed, 2024-02-28 at 13:22 +, Christophe Leroy wrote:
> > Any preference? Or maybe am I missing your point and talking
> > nonsense?
> >
>
> So my preference would go to the addition of:
>
> info.new_field = 0;
>
> But that's very minor and if you think it is easier to manage and
On Tue, 2024-02-27 at 18:16 +, Christophe Leroy wrote:
> > > Why doing a full init of the struct when all fields are re-
> > > written a few
> > > lines after ?
> >
> > It's a nice change for robustness and makes future changes easier.
> > It's
> > not actually wasteful since the compiler will
On Tue, 2024-02-27 at 07:02 +, Christophe Leroy wrote:
> > It could be possible to initialize the new field for each arch to
> > 0, but
> > instead simply inialize the field with a C99 struct inializing
> > syntax.
>
> Why doing a full init of the struct when all fields are re-written a
> few
On Tue, 2023-10-03 at 10:18 -0700, Sohil Mehta wrote:
> > If you like, I can pick this up for 6.7 through the asm-generic
> > tree. If you think this should be part of 6.6, I would suggest
> > to merge it through the tree that originally contained the
> > syscall code.
> >
>
> Dave, Ingo, would y
On Mon, 2023-09-18 at 10:29 +0300, Mike Rapoport wrote:
> +/**
> + * struct execmem_range - definition of a memory range suitable for
> code and
> + * related data allocations
> + * @start: address space start
> + * @end: address space end (inclusive)
> + * @pgprot:
On Thu, 2023-10-05 at 08:26 +0300, Mike Rapoport wrote:
> On Wed, Oct 04, 2023 at 03:39:26PM +0000, Edgecombe, Rick P wrote:
> > On Tue, 2023-10-03 at 17:29 -0700, Rick Edgecombe wrote:
> > > It seems a bit weird to copy all of this. Is it trying to be
> > > fast
On Tue, 2023-10-03 at 17:29 -0700, Rick Edgecombe wrote:
> It seems a bit weird to copy all of this. Is it trying to be faster
> or
> something?
>
> Couldn't it just check r->start in execmem_text/data_alloc() path and
> switch to EXECMEM_DEFAULT if needed then? The execmem_range_is_data()
> part
On Mon, 2023-09-18 at 10:29 +0300, Mike Rapoport wrote:
> +
> +static void execmem_init_missing(struct execmem_params *p)
> +{
> + struct execmem_range *default_range = &p-
> >ranges[EXECMEM_DEFAULT];
> +
> + for (int i = EXECMEM_DEFAULT + 1; i < EXECMEM_TYPE_MAX; i++)
> {
> +
On Mon, 2023-09-18 at 10:29 +0300, Mike Rapoport wrote:
> diff --git a/arch/x86/kernel/module.c b/arch/x86/kernel/module.c
> index 5f71a0cf4399..9d37375e2f05 100644
> --- a/arch/x86/kernel/module.c
> +++ b/arch/x86/kernel/module.c
> @@ -19,6 +19,7 @@
> #include
> #include
> #include
> +#inclu
On Thu, 2023-09-14 at 18:58 +, Sohil Mehta wrote:
> commit c35559f94ebc ("x86/shstk: Introduce map_shadow_stack syscall")
> recently added support for map_shadow_stack() but it is limited to
> x86
> only for now. There is a possibility that other architectures
> (namely,
> arm64 and RISC-V), th
On Wed, 2023-09-13 at 12:18 -0700, Sohil Mehta wrote:
> On 9/11/2023 2:10 PM, Edgecombe, Rick P wrote:
> > On Mon, 2023-09-11 at 18:02 +, Sohil Mehta wrote:
> > > diff --git a/arch/powerpc/kernel/syscalls/syscall.tbl
> > > b/arch/powerpc/kernel/syscalls/syscall.t
On Mon, 2023-09-11 at 18:02 +, Sohil Mehta wrote:
> diff --git a/arch/powerpc/kernel/syscalls/syscall.tbl
> b/arch/powerpc/kernel/syscalls/syscall.tbl
> index 20e50586e8a2..2767b8a42636 100644
> --- a/arch/powerpc/kernel/syscalls/syscall.tbl
> +++ b/arch/powerpc/kernel/syscalls/syscall.tbl
> @@
On Fri, 2023-07-14 at 23:57 +0100, Mark Brown wrote:
> On Mon, Jun 12, 2023 at 05:10:27PM -0700, Rick Edgecombe wrote:
> > The x86 Shadow stack feature includes a new type of memory called
> > shadow
> > stack. This shadow stack memory has some unusual properties, which
> > requires
> > some core m
On Fri, 2023-06-16 at 11:50 +0300, Mike Rapoport wrote:
> From: "Mike Rapoport (IBM)"
>
> Hi,
>
> module_alloc() is used everywhere as a mean to allocate memory for
> code.
>
> Beside being semantically wrong, this unnecessarily ties all
> subsystmes
> that need to allocate code, such as ftrace
On Fri, 2023-06-16 at 11:50 +0300, Mike Rapoport wrote:
> From: "Mike Rapoport (IBM)"
>
> Data related to code allocations, such as module data section, need
> to
> comply with architecture constraints for its placement and its
> allocation right now was done using execmem_text_alloc().
>
> Crea
On Fri, 2023-06-16 at 11:50 +0300, Mike Rapoport wrote:
> -void *module_alloc(unsigned long size)
> -{
> - gfp_t gfp_mask = GFP_KERNEL;
> - void *p;
> -
> - if (PAGE_ALIGN(size) > MODULES_LEN)
> - return NULL;
> +static struct execmem_params execmem_params = {
> +
On Fri, 2023-06-16 at 11:50 +0300, Mike Rapoport wrote:
> void *module_alloc(unsigned long size)
> {
> - if (size == 0)
> - return NULL;
> - return kmalloc(size, GFP_KERNEL);
> -}
> -
> -/* Free memory returned from module_alloc */
> -void module_memfree(void *module_reg
On Tue, 2023-06-13 at 09:19 +0200, Geert Uytterhoeven wrote:
> Acked-by: Geert Uytterhoeven
Thanks!
On Tue, 2023-06-13 at 10:43 +0300, Mike Rapoport wrote:
> On Mon, Jun 12, 2023 at 05:10:27PM -0700, Rick Edgecombe wrote:
> > The x86 Shadow stack feature includes a new type of memory called
> > shadow
> > stack. This shadow stack memory has some unusual properties, which
> > requires
> > some cor
On Tue, 2023-06-13 at 14:26 +0200, David Hildenbrand wrote:
>
> Acked-by: David Hildenbrand
Thanks!
On Mon, 2023-06-05 at 23:42 +0300, Mike Rapoport wrote:
> > I tried this technique previously [0], and I thought it was not too
> > bad. In most of the callers it looks similar to what you have in
> > do_text_poke(). Sometimes less, sometimes more. It might need
> > enlightening of some of the stuf
On Mon, 2023-06-05 at 11:11 +0300, Mike Rapoport wrote:
> On Sun, Jun 04, 2023 at 10:52:44PM -0400, Steven Rostedt wrote:
> > On Thu, 1 Jun 2023 16:54:36 -0700
> > Nadav Amit wrote:
> >
> > > > The way text_poke() is used here, it is creating a new writable
> > > > alias
> > > > and flushing it f
On Thu, 2023-06-01 at 14:38 -0400, Kent Overstreet wrote:
> On Thu, Jun 01, 2023 at 06:13:44PM +0000, Edgecombe, Rick P wrote:
> > > text_poke() _does_ create a separate RW mapping.
> >
> > Sorry, I meant a separate RW allocation.
>
> Ah yes, that makes sense
>
On Thu, 2023-06-01 at 14:00 -0400, Kent Overstreet wrote:
> On Thu, Jun 01, 2023 at 04:54:27PM +0000, Edgecombe, Rick P wrote:
> > It is just a local flush, but I wonder how much text_poke()ing is
> > too
> > much. A lot of the are even inside loops. Can't it do the batc
On Thu, 2023-06-01 at 13:12 +0300, Mike Rapoport wrote:
> /*
> * Are we looking at a near JMP with a 1 or 4-byte displacement.
> @@ -331,7 +344,7 @@ void __init_or_module noinline
> apply_alternatives(struct alt_instr *start,
>
> DUMP_BYTES(insn_buff, insn_buff_sz, "%px: final_
On Mon, 2023-02-20 at 12:23 +0100, David Hildenbrand wrote:
> That looks painful but IMHO worth it :)
>
> Acked-by: David Hildenbrand
Thanks. Yes it was not the most fun, but I agree - worth it.
On Mon, 2023-02-20 at 12:00 +1100, Michael Ellerman wrote:
> Acked-by: Michael Ellerman (powerpc)
Thanks!
����^�lf��"�w(���y���Ȩ��&jw��.���{�f�y�!�隮X�����&nky�Z��&nky�Z��&ޞ
�nk�r��jx$y�����蜢i �w�zɢ��$z�ޕ�&�Wd�x����f���&�x����f���&�f�W��'��(���^�ȟ��f��G���h���G���h�
"�Y �w���0�Ydz�ޖ�*��G���h� ���b���z�ޖ��I�$�w�%�䒈ڮI(�� ��ܢk�+h��zx(�
^r��jh��[ڝ�࢈%y�
On Fri, 2020-12-04 at 18:12 +1000, Nicholas Piggin wrote:
> Excerpts from Edgecombe, Rick P's message of December 1, 2020 6:21
> am:
> > On Sun, 2020-11-29 at 01:25 +1000, Nicholas Piggin wrote:
> > > Support huge page vmalloc mappings. Config option
> > > HAVE_ARCH_HUGE_VMALLOC
> > > enables suppo
On Mon, 2020-11-30 at 12:21 -0800, Rick Edgecombe wrote:
> another option could be to use the changes here:
> https://lore.kernel.org/lkml/20201125092208.12544-4-r...@kernel.org/
> to reset the direct map for a large page range at a time for large
> vmalloc pages.
Oops, sorry. This wouldn't be so
On Sun, 2020-11-29 at 01:25 +1000, Nicholas Piggin wrote:
> Support huge page vmalloc mappings. Config option
> HAVE_ARCH_HUGE_VMALLOC
> enables support on architectures that define HAVE_ARCH_HUGE_VMAP and
> supports PMD sized vmap mappings.
>
> vmalloc will attempt to allocate PMD-sized pages if
On Thu, 2020-10-29 at 10:12 +0200, Mike Rapoport wrote:
> This series goal was primarily to separate dependincies and make it
> clearer what DEBUG_PAGEALLOC and what SET_DIRECT_MAP are. As it
> turned
> out, there is also some lack of consistency between architectures
> that
> implement either of t
On Thu, 2020-10-29 at 09:54 +0200, Mike Rapoport wrote:
> __kernel_map_pages() on arm64 will also bail out if rodata_full is
> false:
> void __kernel_map_pages(struct page *page, int numpages, int enable)
> {
> if (!debug_pagealloc_enabled() && !rodata_full)
> return;
>
>
On Sun, 2020-10-25 at 12:15 +0200, Mike Rapoport wrote:
> + if (IS_ENABLED(CONFIG_ARCH_HAS_SET_DIRECT_MAP)) {
> + unsigned long addr = (unsigned
> long)page_address(page);
> + int ret;
> +
> + if (enable)
> + ret = set_direct_map
On Wed, 2020-10-28 at 13:30 +0200, Mike Rapoport wrote:
> On Wed, Oct 28, 2020 at 11:20:12AM +, Will Deacon wrote:
> > On Tue, Oct 27, 2020 at 10:38:16AM +0200, Mike Rapoport wrote:
> > > On Mon, Oct 26, 2020 at 06:05:30PM +0000, Edgecombe, Rick P
> > > wrote:
>
On Wed, 2020-10-28 at 13:09 +0200, Mike Rapoport wrote:
> On Tue, Oct 27, 2020 at 09:46:35AM +0100, David Hildenbrand wrote:
> > On 27.10.20 09:38, Mike Rapoport wrote:
> > > On Mon, Oct 26, 2020 at 06:05:30PM +0000, Edgecombe, Rick P
> > > wrote:
> > >
> &g
On Tue, 2020-10-27 at 10:49 +0200, Mike Rapoport wrote:
> On Mon, Oct 26, 2020 at 06:57:32PM +0000, Edgecombe, Rick P wrote:
> > On Mon, 2020-10-26 at 11:15 +0200, Mike Rapoport wrote:
> > > On Mon, Oct 26, 2020 at 12:38:32AM +0000, Edgecombe, Rick P
> > > wrote:
>
On Mon, 2020-10-26 at 11:15 +0200, Mike Rapoport wrote:
> The intention of this series is to disallow usage of
> __kernel_map_pages() when DEBUG_PAGEALLOC=n. I'll update this patch
> to
> better handle possible errors, but I still want to keep WARN in the
> caller.
Sorry, I missed this snippet at
On Mon, 2020-10-26 at 11:15 +0200, Mike Rapoport wrote:
> On Mon, Oct 26, 2020 at 12:38:32AM +0000, Edgecombe, Rick P wrote:
> > On Sun, 2020-10-25 at 12:15 +0200, Mike Rapoport wrote:
> > > From: Mike Rapoport
> > >
> > > When DEBUG_PAGEALLOC or ARCH_
On Mon, 2020-10-26 at 11:05 +0200, Mike Rapoport wrote:
> On Mon, Oct 26, 2020 at 01:13:52AM +0000, Edgecombe, Rick P wrote:
> > On Sun, 2020-10-25 at 12:15 +0200, Mike Rapoport wrote:
> > > Indeed, for architectures that define
> > > CONFIG_ARCH_HAS_SET_DIRECT_MAP
>
On Sun, 2020-10-25 at 12:15 +0200, Mike Rapoport wrote:
> Indeed, for architectures that define CONFIG_ARCH_HAS_SET_DIRECT_MAP
> it is
> possible that __kernel_map_pages() would fail, but since this
> function is
> void, the failure will go unnoticed.
Could you elaborate on how this could happen?
On Sun, 2020-10-25 at 12:15 +0200, Mike Rapoport wrote:
> index 7f248fc45317..16f878c26667 100644
> --- a/arch/x86/mm/pat/set_memory.c
> +++ b/arch/x86/mm/pat/set_memory.c
> @@ -2228,7 +2228,6 @@ void __kernel_map_pages(struct page *page, int
> numpages, int enable)
> }
> #endif /* CONFIG_DEBUG_P
On Sun, 2020-10-25 at 12:15 +0200, Mike Rapoport wrote:
> From: Mike Rapoport
>
> When DEBUG_PAGEALLOC or ARCH_HAS_SET_DIRECT_MAP is enabled a page may
> be
> not present in the direct map and has to be explicitly mapped before
> it
> could be copied.
>
> On arm64 it is possible that a page woul
49 matches
Mail list logo
