Linux-Next Archive on lore.kernel.org
 help / color / Atom feed
From: Christophe Leroy <christophe.leroy@csgroup.eu>
To: Stephen Rothwell <sfr@canb.auug.org.au>,
	Andrew Morton <akpm@linux-foundation.org>,
	Michael Ellerman <mpe@ellerman.id.au>,
	PowerPC <linuxppc-dev@lists.ozlabs.org>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Linux Next Mailing List <linux-next@vger.kernel.org>,
	Nicholas Piggin <npiggin@gmail.com>
Subject: Re: linux-next: manual merge of the akpm-current tree with the powerpc tree
Date: Thu, 15 Apr 2021 12:07:01 +0200
Message-ID: <9bc1b8fd-8051-54ed-b9d8-198fe1f4c348@csgroup.eu> (raw)
In-Reply-To: <20210415195814.0dc4ced9@canb.auug.org.au>



Le 15/04/2021 à 11:58, Stephen Rothwell a écrit :
> Hi all,
> 
> On Thu, 15 Apr 2021 19:44:17 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>>
>> Today's linux-next merge of the akpm-current tree got a conflict in:
>>
>>    arch/powerpc/kernel/module.c
>>
>> between commit:
>>
>>    2ec13df16704 ("powerpc/modules: Load modules closer to kernel text")
>>
>> from the powerpc tree and commit:
>>
>>    4930ba789f8d ("powerpc/64s/radix: enable huge vmalloc mappings")
>>
>> from the akpm-current tree.
>>
>> I fixed it up (I think - see below) and can carry the fix as
>> necessary. This is now fixed as far as linux-next is concerned, but any
>> non trivial conflicts should be mentioned to your upstream maintainer
>> when your tree is submitted for merging.  You may also want to consider
>> cooperating with the maintainer of the conflicting tree to minimise any
>> particularly complex conflicts.
>>
>> -- 
>> Cheers,
>> Stephen Rothwell
>>
>> diff --cc arch/powerpc/kernel/module.c
>> index fab84024650c,cdb2d88c54e7..000000000000
>> --- a/arch/powerpc/kernel/module.c
>> +++ b/arch/powerpc/kernel/module.c
>> @@@ -88,29 -88,26 +89,42 @@@ int module_finalize(const Elf_Ehdr *hdr
>>    	return 0;
>>    }
>>    
>> - #ifdef MODULES_VADDR
>>   -void *module_alloc(unsigned long size)
>>   +static __always_inline void *
>>   +__module_alloc(unsigned long size, unsigned long start, unsigned long end)
>>    {
>>   -	unsigned long start = VMALLOC_START;
>>   -	unsigned long end = VMALLOC_END;
>>   -
>>   -#ifdef MODULES_VADDR
>>   -	BUILD_BUG_ON(TASK_SIZE > MODULES_VADDR);
>>   -	start = MODULES_VADDR;
>>   -	end = MODULES_END;
>>   -#endif
>>   -
>> + 	/*
>> + 	 * Don't do huge page allocations for modules yet until more testing
>> + 	 * is done. STRICT_MODULE_RWX may require extra work to support this
>> + 	 * too.
>> + 	 */
>> +
>>    	return __vmalloc_node_range(size, 1, start, end, GFP_KERNEL,
>> - 				    PAGE_KERNEL_EXEC, VM_FLUSH_RESET_PERMS, NUMA_NO_NODE,
>> + 				    PAGE_KERNEL_EXEC,
>> + 				    VM_NO_HUGE_VMAP | VM_FLUSH_RESET_PERMS,
>> + 				    NUMA_NO_NODE,
>>    				    __builtin_return_address(0));
>>    }
>>   +
>> ++
>>   +void *module_alloc(unsigned long size)
>>   +{
>> ++	unsigned long start = VMALLOC_START;
>> ++	unsigned long end = VMALLOC_END;
>>   +	unsigned long limit = (unsigned long)_etext - SZ_32M;
>>   +	void *ptr = NULL;
>>   +
>> ++#ifdef MODULES_VADDR
>>   +	BUILD_BUG_ON(TASK_SIZE > MODULES_VADDR);
>> ++	start = MODULES_VADDR;
>> ++	end = MODULES_END;

The #endif should be here.


>>   +
>>   +	/* First try within 32M limit from _etext to avoid branch trampolines */
>>   +	if (MODULES_VADDR < PAGE_OFFSET && MODULES_END > limit)
>> - 		ptr = __module_alloc(size, limit, MODULES_END);
>> ++		ptr = __module_alloc(size, limit, end);
>>   +
>>   +	if (!ptr)
>> - 		ptr = __module_alloc(size, MODULES_VADDR, MODULES_END);
>> ++#endif
>> ++		ptr = __module_alloc(size, start, end);
>>   +
>>   +	return ptr;
>>   +}
>> - #endif
> 
> Unfortunately, it also needs this:

Before the #endif is too far.

> 
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Thu, 15 Apr 2021 19:53:58 +1000
> Subject: [PATCH] merge fix up for powerpc merge fix
> 
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
>   arch/powerpc/kernel/module.c | 2 ++
>   1 file changed, 2 insertions(+)
> 
> diff --git a/arch/powerpc/kernel/module.c b/arch/powerpc/kernel/module.c
> index d8ab1ad2eb05..c060f99afd4d 100644
> --- a/arch/powerpc/kernel/module.c
> +++ b/arch/powerpc/kernel/module.c
> @@ -110,7 +110,9 @@ void *module_alloc(unsigned long size)
>   {
>   	unsigned long start = VMALLOC_START;
>   	unsigned long end = VMALLOC_END;
> +#ifdef MODULES_VADDR
>   	unsigned long limit = (unsigned long)_etext - SZ_32M;
> +#endif
>   	void *ptr = NULL;
>   
>   #ifdef MODULES_VADDR
> 

  reply index

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-15  9:44 Stephen Rothwell
2021-04-15  9:58 ` Stephen Rothwell
2021-04-15 10:07   ` Christophe Leroy [this message]
2021-04-15 10:08     ` Christophe Leroy
2021-04-15 10:15       ` Christophe Leroy
  -- strict thread matches above, loose matches on Subject: below --
2021-06-18  9:44 Stephen Rothwell
2021-06-19  2:54 ` Nicholas Piggin
2021-05-05  1:39 Stephen Rothwell
2021-05-05  4:57 ` Michael Ellerman
2021-05-05  5:46   ` Stephen Rothwell
2021-05-05 23:43 ` Stephen Rothwell
2020-12-08  9:40 Stephen Rothwell
2020-12-17  0:48 ` Stephen Rothwell
2020-09-17  8:57 Stephen Rothwell
2020-06-03  8:50 Stephen Rothwell
2019-07-08 11:43 Stephen Rothwell
2019-04-23  8:57 Stephen Rothwell
2019-02-25  6:42 Stephen Rothwell
2019-02-25  6:44 ` Stephen Rothwell
2019-02-25  6:16 Stephen Rothwell
2018-12-06  6:44 Stephen Rothwell
2018-12-07  1:40 ` Joel Fernandes
2016-05-02  7:20 Stephen Rothwell
2016-05-02 11:17 ` Aneesh Kumar K.V
2016-03-04  7:49 Stephen Rothwell
2015-12-18  5:33 Stephen Rothwell
2016-01-07  9:15 ` Stephen Rothwell
2016-01-07 17:15   ` Aneesh Kumar K.V
2016-01-07 20:03     ` Stephen Rothwell
2015-12-15  5:53 Stephen Rothwell
2015-12-15  6:44 ` Stephen Rothwell
2015-12-15  9:37 ` Aneesh Kumar K.V

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=9bc1b8fd-8051-54ed-b9d8-198fe1f4c348@csgroup.eu \
    --to=christophe.leroy@csgroup.eu \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-next@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=mpe@ellerman.id.au \
    --cc=npiggin@gmail.com \
    --cc=sfr@canb.auug.org.au \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Linux-Next Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-next/0 linux-next/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-next linux-next/ https://lore.kernel.org/linux-next \
		linux-next@vger.kernel.org
	public-inbox-index linux-next

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-next


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git