kernel-testers.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jeremy Fitzhardinge <jeremy@goop.org>
To: Kamalesh Babulal <kamalesh@linux.vnet.ibm.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	linux-kernel@vger.kernel.org, kernel-testers@vger.kernel.org,
	apw@shadowen.org, Heiko Carstens <heiko.carstens@de.ibm.com>,
	Martin Schwidefsky <schwidefsky@de.ibm.com>
Subject: Re: [BUILD-FAILURE] 2.6.26-rc8-mm1 - x86 - __ptep_modify_prot_start() missing
Date: Thu, 03 Jul 2008 11:00:35 -0700	[thread overview]
Message-ID: <486D13C3.3000409@goop.org> (raw)
In-Reply-To: <20080703104643.04ea2acb.akpm@linux-foundation.org>

Andrew Morton wrote:
> On Thu, 3 Jul 2008 17:59:43 +0530 Kamalesh Babulal <kamalesh@linux.vnet.ibm.com> wrote:
>
>   
>> Hi Andrew,
>>
>> 2.6.26-rc8-mm1 kernel build fails on the x86
>>
>>   CC      arch/x86/kernel/paravirt.o
>> arch/x86/kernel/paravirt.c:383: error: _____ptep_modify_prot_start___ undeclared here (not in a function)
>>     

Where did all those _____underlines___ come from?

>> make[1]: *** [arch/x86/kernel/paravirt.o] Error 1
>> make: *** [arch/x86/kernel] Error 2
>>
>> linux-next patches has the changes to the adds the function
>> __ptep_modify_prot_start as inline, the patch s390-build-fixes.patch
>> is coverting it into macro. Reverting the s390-build-fixes.patch
>> fixes the build failure.
>>     
>
> grump.  Who did all this stuff?
>
> I dunno.  I'll drop s390-build-fixes.patch, add some ccs and stomp off.
>
>
> From: Andrew Morton <akpm@linux-foundation.org>
>
> In file included from include/asm/pgtable.h:1087,
>                  from include/linux/mm.h:39,
>                  from arch/s390/mm/hugetlbpage.c:8:
> include/asm-generic/pgtable.h: In function '__ptep_modify_prot_start':
> include/asm-generic/pgtable.h:209: error: dereferencing pointer to incomplete type
>   

We can't turn them into macros because we're expecting to be able to 
take the address of __ptep_modify_prot_start/commit.  What type is not 
defined on s390 at that point?  Would simply adding an extra include to 
arch/s390/mm/hugetlbpage.c fix the problem?

In the worst case we could push __ptep_modify_proc_start/commit out of 
line somewhere appropriate, but that's a bit sad given how simple they are.

    J

> Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
> Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
> ---
>
>  include/asm-generic/pgtable.h |   26 +++++++++-----------------
>  1 file changed, 9 insertions(+), 17 deletions(-)
>
> diff -puN include/asm-generic/pgtable.h~s390-build-fixes include/asm-generic/pgtable.h
> --- a/include/asm-generic/pgtable.h~s390-build-fixes
> +++ a/include/asm-generic/pgtable.h
> @@ -197,17 +197,13 @@ static inline int pmd_none_or_clear_bad(
>  }
>  #endif /* CONFIG_MMU */
>  
> -static inline pte_t __ptep_modify_prot_start(struct mm_struct *mm,
> -					     unsigned long addr,
> -					     pte_t *ptep)
> -{
> -	/*
> -	 * Get the current pte state, but zero it out to make it
> -	 * non-present, preventing the hardware from asynchronously
> -	 * updating it.
> -	 */
> -	return ptep_get_and_clear(mm, addr, ptep);
> -}
> +/*
> + * Get the current pte state, but zero it out to make it
> + * non-present, preventing the hardware from asynchronously
> + * updating it.
> + */
> +#define __ptep_modify_prot_start(mm, addr, ptep)	\
> +	ptep_get_and_clear(mm, addr, ptep)
>  
>  static inline void __ptep_modify_prot_commit(struct mm_struct *mm,
>  					     unsigned long addr,
> @@ -235,12 +231,8 @@ static inline void __ptep_modify_prot_co
>   * queue the update to be done at some later time.  The update must be
>   * actually committed before the pte lock is released, however.
>   */
> -static inline pte_t ptep_modify_prot_start(struct mm_struct *mm,
> -					   unsigned long addr,
> -					   pte_t *ptep)
> -{
> -	return __ptep_modify_prot_start(mm, addr, ptep);
> -}
> +#define ptep_modify_prot_start(mm, addr, ptep)		\
> +	__ptep_modify_prot_start(mm, addr, ptep)
>  
>  /*
>   * Commit an update to a pte, leaving any hardware-controlled bits in
> _
>
>
>   

  reply	other threads:[~2008-07-03 18:00 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-07-03  9:02 2.6.26-rc8-mm1 Andrew Morton
2008-07-03 11:22 ` [BUILD-FAILURE] 2.6.26-rc8-mm1 - build failure at drivers/char/hvc_rtas.c Kamalesh Babulal
     [not found] ` <20080703020236.adaa51fa.akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>
2008-07-03 12:29   ` [BUILD-FAILURE] 2.6.26-rc8-mm1 - x86 - __ptep_modify_prot_start() missing Kamalesh Babulal
     [not found]     ` <20080703122943.GB6451-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
2008-07-03 17:46       ` Andrew Morton
2008-07-03 18:00         ` Jeremy Fitzhardinge [this message]
     [not found]           ` <486D13C3.3000409-TSDbQ3PG+2Y@public.gmane.org>
2008-07-03 18:14             ` Andrew Morton
     [not found]               ` <20080703111418.19f568ca.akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>
2008-07-03 19:03                 ` Heiko Carstens
2008-07-04 22:49   ` 2.6.26-rc8-mm1: unable to mount nfs shares Mariusz Kozlowski
     [not found]     ` <200807050049.33287.m.kozlowski-NWF1p15JEu3VItvQsEIGlw@public.gmane.org>
2008-07-04 23:07       ` Andrew Morton
2008-07-08 14:42   ` [BUG] 2.6.26-rc8-mm1 - sleeping function called from invalid context at include/linux/pagemap.h:291 Kamalesh Babulal
     [not found]     ` <48737CBE.4010301-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
2008-07-12  7:15       ` KOSAKI Motohiro

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=486D13C3.3000409@goop.org \
    --to=jeremy@goop.org \
    --cc=akpm@linux-foundation.org \
    --cc=apw@shadowen.org \
    --cc=heiko.carstens@de.ibm.com \
    --cc=kamalesh@linux.vnet.ibm.com \
    --cc=kernel-testers@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=schwidefsky@de.ibm.com \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).