All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
To: Anshuman Khandual <khandual@linux.vnet.ibm.com>, linuxppc-dev@ozlabs.org
Cc: mikey@neuling.org
Subject: Re: [PATCH] powerpc, mm: Fix build failure due to CONFIG_PPC_TRANSACTIONAL_MEM
Date: Tue, 21 Apr 2015 20:09:32 +0530	[thread overview]
Message-ID: <87mw21ilzv.fsf@linux.vnet.ibm.com> (raw)
In-Reply-To: <1429614284-16528-1-git-send-email-khandual@linux.vnet.ibm.com>

Anshuman Khandual <khandual@linux.vnet.ibm.com> writes:

> The function flush_hash_page fails to compile when the transaction memory
> config option is turned off because there is a label at end of compound
> statement. This patch moves the code block into a function tm_abort_tlbi
> and calls it after the label thus fixing the build problem.
>
> Signed-off-by: Anshuman Khandual <khandual@linux.vnet.ibm.com>
> ---
> arch/powerpc/mm/hash_utils_64.c: In function =E2=80=98flush_hash_hugepage=
=E2=80=99:
> arch/powerpc/mm/hash_utils_64.c:1381:1: error: label at end of compound s=
tatement
>  tm_abort:
>  ^
> make[1]: *** [arch/powerpc/mm/hash_utils_64.o] Error 1
> make: *** [arch/powerpc/mm] Error 2
>
>  arch/powerpc/mm/hash_utils_64.c | 35 ++++++++++++++++++++---------------
>  1 file changed, 20 insertions(+), 15 deletions(-)
>
> diff --git a/arch/powerpc/mm/hash_utils_64.c b/arch/powerpc/mm/hash_utils=
_64.c
> index 2c2022d..b30b2b5 100644
> --- a/arch/powerpc/mm/hash_utils_64.c
> +++ b/arch/powerpc/mm/hash_utils_64.c
> @@ -1326,6 +1326,25 @@ void flush_hash_page(unsigned long vpn, real_pte_t=
 pte, int psize, int ssize,
>  }
>
>  #ifdef CONFIG_TRANSPARENT_HUGEPAGE
> +static void tm_abort_tlbi(int local)
> +{
> +#ifdef CONFIG_PPC_TRANSACTIONAL_MEM
> +	/* Transactions are not aborted by tlbiel, only tlbie.
> +	 * Without, syncing a page back to a block device w/ PIO could pick up
> +	 * transactional data (bad!) so we force an abort here.  Before the
> +	 * sync the page will be made read-only, which will flush_hash_page.
> +	 * BIG ISSUE here: if the kernel uses a page from userspace without
> +	 * unmapping it first, it may see the speculated version.
> +	 */
> +	if (local && cpu_has_feature(CPU_FTR_TM) &&
> +	    current->thread.regs &&
> +	    MSR_TM_ACTIVE(current->thread.regs->msr)) {
> +		tm_enable();
> +		tm_abort(TM_CAUSE_TLBI);
> +	}
> +#endif
> +}
> +
>  void flush_hash_hugepage(unsigned long vsid, unsigned long addr,
>  			 pmd_t *pmdp, unsigned int psize, int ssize,
>  			 unsigned long flags)
> @@ -1379,21 +1398,7 @@ void flush_hash_hugepage(unsigned long vsid, unsig=
ned long addr,
>  				       MMU_PAGE_16M, ssize, local);
>  	}
>  tm_abort:
> -#ifdef CONFIG_PPC_TRANSACTIONAL_MEM
> -	/* Transactions are not aborted by tlbiel, only tlbie.
> -	 * Without, syncing a page back to a block device w/ PIO could pick up
> -	 * transactional data (bad!) so we force an abort here.  Before the
> -	 * sync the page will be made read-only, which will flush_hash_page.
> -	 * BIG ISSUE here: if the kernel uses a page from userspace without
> -	 * unmapping it first, it may see the speculated version.
> -	 */
> -	if (local && cpu_has_feature(CPU_FTR_TM) &&
> -	    current->thread.regs &&
> -	    MSR_TM_ACTIVE(current->thread.regs->msr)) {
> -		tm_enable();
> -		tm_abort(TM_CAUSE_TLBI);
> -	}
> -#endif
> +	tm_abort_tlbi(local);
>  }
>  #endif /* CONFIG_TRANSPARENT_HUGEPAGE */
>
> --=20

Why not just do ?. I will send a seperate patch=20


commit 52b6dcc8fe34b9d05b8a0f14d45fcdc3bef6c84f
Author: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Date:   Tue Apr 21 19:51:10 2015 +0530

    powerpc/mm: Fix build error with CONFIG_PPC_TRANSACTIONAL_MEM disabled
=20=20=20=20
    This fix the below build error
=20=20=20=20
    arch/powerpc/mm/hash_utils_64.c: In function =E2=80=98flush_hash_hugepa=
ge=E2=80=99:
    arch/powerpc/mm/hash_utils_64.c:1381:1: error: label at end of compound=
 statement
     tm_abort:
     ^
    make[1]: *** [arch/powerpc/mm/hash_utils_64.o] Error 1
=20=20=20=20
    Reported-by: Anshuman Khandual <khandual@linux.vnet.ibm.com>
    Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>

diff --git a/arch/powerpc/mm/hash_utils_64.c b/arch/powerpc/mm/hash_utils_6=
4.c
index 2c2022d16059..ac5c4373cd8b 100644
--- a/arch/powerpc/mm/hash_utils_64.c
+++ b/arch/powerpc/mm/hash_utils_64.c
@@ -1394,6 +1394,7 @@ tm_abort:
 		tm_abort(TM_CAUSE_TLBI);
 	}
 #endif
+	return;
 }
 #endif /* CONFIG_TRANSPARENT_HUGEPAGE */
=20

      reply	other threads:[~2015-04-21 14:39 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-21 11:04 [PATCH] powerpc, mm: Fix build failure due to CONFIG_PPC_TRANSACTIONAL_MEM Anshuman Khandual
2015-04-21 14:39 ` Aneesh Kumar K.V [this message]

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=87mw21ilzv.fsf@linux.vnet.ibm.com \
    --to=aneesh.kumar@linux.vnet.ibm.com \
    --cc=khandual@linux.vnet.ibm.com \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=mikey@neuling.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.