Currently msr_tm_active() is a wrapper around MSR_TM_ACTIVE() if
CONFIG_PPC_TRANSACTIONAL_MEM is set, or it is just a function that
returns false if CONFIG_PPC_TRANSACTIONAL_MEM is not set.
This function is not necessary, since MSR_TM_ACTIVE() just do the same,
checking for the TS bits and does not require any TM facility.
This patchset remove every instance of msr_tm_active() and replaced it
by MSR_TM_ACTIVE();
Signed-off-by: Breno Leitao <leitao@debian.org>
---
arch/powerpc/kernel/process.c | 18 ++++++------------
1 file changed, 6 insertions(+), 12 deletions(-)
This patch simply fix part of the documentation on the HTM code.
This fixes reference to old fields that were renamed in commit
000ec280e3dd ("powerpc: tm: Rename transct_(*) to ck(\1)_state").
It also documents better the flow after commit eb5c3f1c8647 ("powerpc:
Always save/restore checkpointed regs during treclaim/trecheckpoint"),
where tm_recheckpoint can recheckpoint what is in ck{fp,vr}_state blindly.
Signed-off-by: Breno Leitao <leitao@debian.org>
---
arch/powerpc/kernel/tm.S | 10 +++++-----
arch/powerpc/kernel/traps.c | 15 +++++++++------
2 files changed, 14 insertions(+), 11 deletions(-)
@@ -1719,16 +1719,19 @@ void fp_unavailable_tm(struct pt_regs *regs)*checkpointedFPregistersneedtobeloaded.*/tm_reclaim_current(TM_CAUSE_FAC_UNAV);-/* Reclaim didn't save out any FPRs to transact_fprs. */++/* Reclaim initially saved out bogus (lazy) FPRs to ckfp_state, and+*thenitwasoverwritebythethr->fp_statebytm_reclaim_thread().+*+*Atthispoint,ck{fp,vr}_statecontainstheexactvalueswewantto+*recheckpoint.+*//* Enable FP for the task: */current->thread.load_fp=1;-/* This loads and recheckpoints the FP registers from-*thread.fpr[].Theywillremaininregistersafterthe-*checkpointsowedon'tneedtoreloadthemafter.-*IfVMXisinuse,theVRsnowholdcheckpointedvalues,-*sowedon'twanttoloadtheVRsfromthethread_struct.+/*+*Recheckpointallthecheckpointedckpt,ck{fp,vr}_stateregisters.*/tm_recheckpoint(¤t->thread);}
From: Cyril Bur <redacted>
tm_reclaim_thread() doesn't use the parameter anymore, both callers have
to bother getting it as they have no need for a struct thread_info
either.
It was previously used but became unused in dc3106690b20 ("powerpc: tm:
Always use fp_state and vr_state to store live registers")
Just remove it and adjust the callers.
Signed-off-by: Cyril Bur <redacted>
Signed-off-by: Breno Leitao <leitao@debian.org>
---
arch/powerpc/kernel/process.c | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)
From: kbuild test robot <hidden> Date: 2018-06-15 20:06:45
Hi Breno,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on powerpc/next]
[also build test ERROR on v4.17 next-20180615]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Breno-Leitao/powerpc-tm-Remove-msr_tm_active/20180616-015124
base: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next
config: powerpc-mpc8272_ads_defconfig (attached as .config)
compiler: powerpc-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=7.2.0 make.cross ARCH=powerpc
All error/warnings (new ones prefixed by >>):
In file included from arch/powerpc/include/asm/processor.h:13:0,
from arch/powerpc/include/asm/thread_info.h:26,
from include/linux/thread_info.h:38,
from arch/powerpc/include/asm/ptrace.h:158,
from arch/powerpc/include/asm/hw_irq.h:12,
from arch/powerpc/include/asm/irqflags.h:12,
from include/linux/irqflags.h:16,
from include/asm-generic/cmpxchg-local.h:6,
from arch/powerpc/include/asm/cmpxchg.h:537,
from arch/powerpc/include/asm/atomic.h:11,
from include/linux/atomic.h:5,
from include/linux/rcupdate.h:38,
from include/linux/rculist.h:11,
from include/linux/pid.h:5,
from include/linux/sched.h:14,
from arch/powerpc/kernel/process.c:18:
arch/powerpc/kernel/process.c: In function 'enable_kernel_fp':
quoted
arch/powerpc/include/asm/reg.h:65:23: error: left shift count >= width of type [-Werror=shift-count-overflow]
#define __MASK(X) (1UL<<(X))
^
quoted
arch/powerpc/include/asm/reg.h:117:18: note: in expansion of macro '__MASK'
arch/powerpc/include/asm/reg.h:119:34: note: in expansion of macro 'MSR_TS_MASK'
#define MSR_TM_ACTIVE(x) (((x) & MSR_TS_MASK) != 0) /* Transaction active? */
^~~~~~~~~~~
arch/powerpc/kernel/process.c:527:7: note: in expansion of macro 'MSR_TM_ACTIVE'
if (!MSR_TM_ACTIVE(regs->msr) &&
^~~~~~~~~~~~~
vim +/MSR_TM_ACTIVE +244 arch/powerpc/kernel/process.c
226
227 void enable_kernel_fp(void)
228 {
229 unsigned long cpumsr;
230
231 WARN_ON(preemptible());
232
233 cpumsr = msr_check_and_set(MSR_FP);
234
235 if (current->thread.regs && (current->thread.regs->msr & MSR_FP)) {
236 check_if_tm_restore_required(current);
237 /*
238 * If a thread has already been reclaimed then the
239 * checkpointed registers are on the CPU but have definitely
240 * been saved by the reclaim code. Don't need to and *cannot*
241 * giveup as this would save to the 'live' structure not the
242 * checkpointed structure.
243 */
> 244 if(!MSR_TM_ACTIVE(cpumsr) && MSR_TM_ACTIVE(current->thread.regs->msr))
245 return;
246 __giveup_fpu(current);
247 }
248 }
249 EXPORT_SYMBOL(enable_kernel_fp);
250
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
Currently msr_tm_active() is a wrapper around MSR_TM_ACTIVE() if
CONFIG_PPC_TRANSACTIONAL_MEM is set, or it is just a function that
returns false if CONFIG_PPC_TRANSACTIONAL_MEM is not set.
This function is not necessary, since MSR_TM_ACTIVE() just do the same,
checking for the TS bits and does not require any TM facility.
This patchset remove every instance of msr_tm_active() and replaced it
by MSR_TM_ACTIVE().
Signed-off-by: Breno Leitao <leitao@debian.org>
---
arch/powerpc/kernel/process.c | 34 +++++++++++++++++++++-------------
1 file changed, 21 insertions(+), 13 deletions(-)
This patch simply fix part of the documentation on the HTM code.
This fixes reference to old fields that were renamed in commit
000ec280e3dd ("powerpc: tm: Rename transct_(*) to ck(\1)_state")
It also documents better the flow after commit eb5c3f1c8647 ("powerpc:
Always save/restore checkpointed regs during treclaim/trecheckpoint"),
where tm_recheckpoint can recheckpoint what is in ck{fp,vr}_state blindly.
Signed-off-by: Breno Leitao <leitao@debian.org>
---
arch/powerpc/kernel/tm.S | 10 +++++-----
arch/powerpc/kernel/traps.c | 15 +++++++++------
2 files changed, 14 insertions(+), 11 deletions(-)
@@ -1719,16 +1719,19 @@ void fp_unavailable_tm(struct pt_regs *regs)*checkpointedFPregistersneedtobeloaded.*/tm_reclaim_current(TM_CAUSE_FAC_UNAV);-/* Reclaim didn't save out any FPRs to transact_fprs. */++/* Reclaim initially saved out bogus (lazy) FPRs to ckfp_state, and+*thenitwasoverwritebythethr->fp_statebytm_reclaim_thread().+*+*Atthispoint,ck{fp,vr}_statecontainstheexactvalueswewantto+*recheckpoint.+*//* Enable FP for the task: */current->thread.load_fp=1;-/* This loads and recheckpoints the FP registers from-*thread.fpr[].Theywillremaininregistersafterthe-*checkpointsowedon'tneedtoreloadthemafter.-*IfVMXisinuse,theVRsnowholdcheckpointedvalues,-*sowedon'twanttoloadtheVRsfromthethread_struct.+/*+*Recheckpointallthecheckpointedckpt,ck{fp,vr}_stateregisters.*/tm_recheckpoint(¤t->thread);}
From: Cyril Bur <redacted>
tm_reclaim_thread() doesn't use the parameter anymore, both callers have
to bother getting it as they have no need for a struct thread_info
either.
It was previously used but became unused in commit
dc3106690b20 ("powerpc: tm: Always use fp_state and vr_state to store live
registers")
Just remove it and adjust the callers.
Signed-off-by: Cyril Bur <redacted>
Signed-off-by: Breno Leitao <leitao@debian.org>
---
arch/powerpc/kernel/process.c | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)
If __switch_to() tries to context switch from task A to task B, and task A
had task->thread->regs->msr[TM] enabled, then __switch_to_tm() will call
tm_recheckpoint_new_task(), which will call trecheckpoint, for task B, which
is clearly wrong since task B might not be an active TM user.
This does not cause a lot of damage because tm_recheckpoint() will abort
the call since it realize that the current task does not have msr[TM] bit
set.
Signed-off-by: Breno Leitao <leitao@debian.org>
---
arch/powerpc/kernel/process.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
From: Michael Neuling <hidden> Date: 2018-08-16 11:57:50
On Mon, 2018-06-18 at 19:59 -0300, Breno Leitao wrote:
Currently msr_tm_active() is a wrapper around MSR_TM_ACTIVE() if
CONFIG_PPC_TRANSACTIONAL_MEM is set, or it is just a function that
returns false if CONFIG_PPC_TRANSACTIONAL_MEM is not set.
=20
This function is not necessary, since MSR_TM_ACTIVE() just do the same,
checking for the TS bits and does not require any TM facility.
=20
This patchset remove every instance of msr_tm_active() and replaced it
by MSR_TM_ACTIVE().
=20
Signed-off-by: Breno Leitao <leitao@debian.org>
=20
Patch looks good... one minor nit below...
=20
- if (!msr_tm_active(regs->msr) &&
- !current->thread.load_fp && !loadvec(current->thread))
+ if (!current->thread.load_fp && !loadvec(current->thread)) {
+#ifdef CONFIG_PPC_TRANSACTIONAL_MEM
+ if (!MSR_TM_ACTIVE(regs->msr))
+ return;
Can you make a MSR_TM_ACTIVE() that returns false when
!CONFIG_PPC_TRANSACTIONAL_MEM. Then you don't need this inline #ifdef.
Mikey
From: Michael Neuling <hidden> Date: 2018-08-16 11:57:50
On Mon, 2018-06-18 at 19:59 -0300, Breno Leitao wrote:
From: Cyril Bur <redacted>
=20
tm_reclaim_thread() doesn't use the parameter anymore, both callers have
to bother getting it as they have no need for a struct thread_info
either.
=20
It was previously used but became unused in commit
dc3106690b20 ("powerpc: tm: Always use fp_state and vr_state to store liv=
e
registers")
=20
Just remove it and adjust the callers.
=20
Signed-off-by: Cyril Bur <redacted>
Signed-off-by: Breno Leitao <leitao@debian.org>
From: Michael Neuling <hidden> Date: 2018-08-16 11:57:50
On Mon, 2018-06-18 at 19:59 -0300, Breno Leitao wrote:
If __switch_to() tries to context switch from task A to task B, and task =
A
had task->thread->regs->msr[TM] enabled, then __switch_to_tm() will call
tm_recheckpoint_new_task(), which will call trecheckpoint, for task B, wh=
ich
quoted hunk
is clearly wrong since task B might not be an active TM user.
=20
This does not cause a lot of damage because tm_recheckpoint() will abort
the call since it realize that the current task does not have msr[TM] bit
set.
=20
Signed-off-by: Breno Leitao <leitao@debian.org>
---
arch/powerpc/kernel/process.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
=20
I'm not sure we need this patch as tm_recheckpoint_new_task() does this its=
elf.
---
static inline void tm_recheckpoint_new_task(struct task_struct *new)
{
if (!cpu_has_feature(CPU_FTR_TM))
return;
/* Recheckpoint the registers of the thread we're about to switch to.
*
* If the task was using FP, we non-lazily reload both the original and
* the speculative FP register states. This is because the kernel
* doesn't see if/when a TM rollback occurs, so if we take an FP
* unavailable later, we are unable to determine which set of FP regs
* need to be restored.
*/
if (!tm_enabled(new))
return;
---
Mikey
From: Michael Neuling <hidden> Date: 2018-08-16 11:57:50
On Mon, 2018-06-18 at 19:59 -0300, Breno Leitao wrote:
This patch simply fix part of the documentation on the HTM code.
=20
This fixes reference to old fields that were renamed in commit
000ec280e3dd ("powerpc: tm: Rename transct_(*) to ck(\1)_state")
=20
It also documents better the flow after commit eb5c3f1c8647 ("powerpc:
Always save/restore checkpointed regs during treclaim/trecheckpoint"),
where tm_recheckpoint can recheckpoint what is in ck{fp,vr}_state blindly=
@@ -1719,16 +1719,19 @@ void fp_unavailable_tm(struct pt_regs *regs)*checkpointedFPregistersneedtobeloaded.*/tm_reclaim_current(TM_CAUSE_FAC_UNAV);-/* Reclaim didn't save out any FPRs to transact_fprs. */++/* Reclaim initially saved out bogus (lazy) FPRs to ckfp_state, and+*thenitwasoverwritebythethr->fp_statebytm_reclaim_thread().+*+*Atthispoint,ck{fp,vr}_statecontainstheexactvalueswewantto+*recheckpoint.+*/
=20
/* Enable FP for the task: */
current->thread.load_fp =3D 1;
=20
- /* This loads and recheckpoints the FP registers from
- * thread.fpr[]. They will remain in registers after the
- * checkpoint so we don't need to reload them after.
- * If VMX is in use, the VRs now hold checkpointed values,
- * so we don't want to load the VRs from the thread_struct.
+ /*
+ * Recheckpoint all the checkpointed ckpt, ck{fp, vr}_state registers.
*/
tm_recheckpoint(¤t->thread);
}
Hey Mikey,
Thanks for the review.
On 08/15/2018 08:50 PM, Michael Neuling wrote:
On Mon, 2018-06-18 at 19:59 -0300, Breno Leitao wrote:
quoted
If __switch_to() tries to context switch from task A to task B, and task A
had task->thread->regs->msr[TM] enabled, then __switch_to_tm() will call
tm_recheckpoint_new_task(), which will call trecheckpoint, for task B, which
is clearly wrong since task B might not be an active TM user.
This does not cause a lot of damage because tm_recheckpoint() will abort
the call since it realize that the current task does not have msr[TM] bit
set.
Signed-off-by: Breno Leitao <leitao@debian.org>
---
arch/powerpc/kernel/process.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
I'm not sure we need this patch as tm_recheckpoint_new_task() does this itself.
My plan is to move this check prior to calling these TM functions, doing
early checking and avoiding calling tm_recheckpoint on a non-tm enabled task.
It is very weird when you see, during a tracing, a kernel thread (PF_KTHREAD)
being tm_recheckpointed. :-/
That said, the TM function would do the operation other than "check and do
it" mode.
Ideally I would like to check the thread before calling any TM functions,
and warning (WARN_ON) if we detect, later in the game, that a thread is not
TM enabled.
This helps on two different fronts, in my opinion:
* Code readability
* Understanding tracing (ftrace) outputs.
Currently msr_tm_active() is a wrapper around MSR_TM_ACTIVE() if
CONFIG_PPC_TRANSACTIONAL_MEM is set, or it is just a function that
returns false if CONFIG_PPC_TRANSACTIONAL_MEM is not set.
This function is not necessary, since MSR_TM_ACTIVE() just do the same and
could be used, removing the dualism and simplifying the code.
This patchset remove every instance of msr_tm_active() and replaced it
by MSR_TM_ACTIVE().
Signed-off-by: Breno Leitao <leitao@debian.org>
---
arch/powerpc/include/asm/reg.h | 7 ++++++-
arch/powerpc/kernel/process.c | 21 +++++++++------------
2 files changed, 15 insertions(+), 13 deletions(-)
From: Michael Ellerman <mpe@ellerman.id.au> Date: 2018-08-17 00:49:50
Michael Neuling [off-list ref] writes:
On Mon, 2018-06-18 at 19:59 -0300, Breno Leitao wrote:
quoted
Currently msr_tm_active() is a wrapper around MSR_TM_ACTIVE() if
CONFIG_PPC_TRANSACTIONAL_MEM is set, or it is just a function that
returns false if CONFIG_PPC_TRANSACTIONAL_MEM is not set.
This function is not necessary, since MSR_TM_ACTIVE() just do the same,
checking for the TS bits and does not require any TM facility.
This patchset remove every instance of msr_tm_active() and replaced it
by MSR_TM_ACTIVE().
Signed-off-by: Breno Leitao <leitao@debian.org>
Patch looks good... one minor nit below...
quoted
- if (!msr_tm_active(regs->msr) &&
- !current->thread.load_fp && !loadvec(current->thread))
+ if (!current->thread.load_fp && !loadvec(current->thread)) {
+#ifdef CONFIG_PPC_TRANSACTIONAL_MEM
+ if (!MSR_TM_ACTIVE(regs->msr))
+ return;
Can you make a MSR_TM_ACTIVE() that returns false when
!CONFIG_PPC_TRANSACTIONAL_MEM. Then you don't need this inline #ifdef.
Is that safe?
I see ~50 callers of MSR_TM_ACTIVE(), are they all inside #ifdef TM ?
cheers
Hi Michael,
On 08/16/2018 09:49 PM, Michael Ellerman wrote:
Michael Neuling [off-list ref] writes:
quoted
On Mon, 2018-06-18 at 19:59 -0300, Breno Leitao wrote:
quoted
Currently msr_tm_active() is a wrapper around MSR_TM_ACTIVE() if
CONFIG_PPC_TRANSACTIONAL_MEM is set, or it is just a function that
returns false if CONFIG_PPC_TRANSACTIONAL_MEM is not set.
This function is not necessary, since MSR_TM_ACTIVE() just do the same,
checking for the TS bits and does not require any TM facility.
This patchset remove every instance of msr_tm_active() and replaced it
by MSR_TM_ACTIVE().
Signed-off-by: Breno Leitao <leitao@debian.org>
Patch looks good... one minor nit below...
quoted
- if (!msr_tm_active(regs->msr) &&
- !current->thread.load_fp && !loadvec(current->thread))
+ if (!current->thread.load_fp && !loadvec(current->thread)) {
+#ifdef CONFIG_PPC_TRANSACTIONAL_MEM
+ if (!MSR_TM_ACTIVE(regs->msr))
+ return;
Can you make a MSR_TM_ACTIVE() that returns false when
!CONFIG_PPC_TRANSACTIONAL_MEM. Then you don't need this inline #ifdef.
Is that safe?
I see ~50 callers of MSR_TM_ACTIVE(), are they all inside #ifdef TM ?
I checked all of them, and the only two that are not called inside a #ifdef
are at kvm/book3s_hv_tm.c. They are:
kvm/book3s_hv_tm.c: if (!MSR_TM_ACTIVE(msr)) {
kvm/book3s_hv_tm.c: if (MSR_TM_ACTIVE(msr) || !(vcpu->arch.texasr & TEXASR_FS)) {
All the others are being called inside the #ifdef
Other than that, I do not see why it would be a problem in the way I
implemented it, since it will return false for the two cases above, which
seems correct. Take a look on how the definition became:
#ifdef CONFIG_PPC_TRANSACTIONAL_MEM
#define MSR_TM_ACTIVE(x) (((x) & MSR_TS_MASK) != 0) /* Transaction active? */
#else
#define MSR_TM_ACTIVE(x) 0
#endif
I also tested it with different config files, and I didn't see any complain.
These are the platforms I built for.
* powernv_defconfig
* pseries_le_defconfig
* pseries_defconfig
* ppc64_defconfig
* ppc64e_defconfig
* pmac32_defconfig
* ppc44x_defconfig
* mpc85xx_smp_defconfig
* mpc85xx_defconfig
* ps3_defconfig
Anyway, if you have any other suggestion I can follow in order to guarantee
that I am not causing any regression, I would be happy. Touching these core
kernel macros is scary!
Thanks!
From: Michael Ellerman <mpe@ellerman.id.au> Date: 2018-08-21 06:33:07
Breno Leitao [off-list ref] writes:
On 08/16/2018 09:49 PM, Michael Ellerman wrote:
quoted
Michael Neuling [off-list ref] writes:
quoted
On Mon, 2018-06-18 at 19:59 -0300, Breno Leitao wrote:
quoted
Currently msr_tm_active() is a wrapper around MSR_TM_ACTIVE() if
CONFIG_PPC_TRANSACTIONAL_MEM is set, or it is just a function that
returns false if CONFIG_PPC_TRANSACTIONAL_MEM is not set.
This function is not necessary, since MSR_TM_ACTIVE() just do the same,
checking for the TS bits and does not require any TM facility.
This patchset remove every instance of msr_tm_active() and replaced it
by MSR_TM_ACTIVE().
Signed-off-by: Breno Leitao <leitao@debian.org>
Patch looks good... one minor nit below...
quoted
- if (!msr_tm_active(regs->msr) &&
- !current->thread.load_fp && !loadvec(current->thread))
+ if (!current->thread.load_fp && !loadvec(current->thread)) {
+#ifdef CONFIG_PPC_TRANSACTIONAL_MEM
+ if (!MSR_TM_ACTIVE(regs->msr))
+ return;
Can you make a MSR_TM_ACTIVE() that returns false when
!CONFIG_PPC_TRANSACTIONAL_MEM. Then you don't need this inline #ifdef.
Is that safe?
I see ~50 callers of MSR_TM_ACTIVE(), are they all inside #ifdef TM ?
I checked all of them, and the only two that are not called inside a #ifdef
are at kvm/book3s_hv_tm.c. They are:
kvm/book3s_hv_tm.c: if (!MSR_TM_ACTIVE(msr)) {
kvm/book3s_hv_tm.c: if (MSR_TM_ACTIVE(msr) || !(vcpu->arch.texasr & TEXASR_FS)) {
That whole file is only built if TM=y:
kvm-hv-$(CONFIG_PPC_TRANSACTIONAL_MEM) += \
book3s_hv_tm.o
All the others are being called inside the #ifdef
Other than that, I do not see why it would be a problem in the way I
implemented it, since it will return false for the two cases above, which
seems correct. Take a look on how the definition became:
#ifdef CONFIG_PPC_TRANSACTIONAL_MEM
#define MSR_TM_ACTIVE(x) (((x) & MSR_TS_MASK) != 0) /* Transaction active? */
#else
#define MSR_TM_ACTIVE(x) 0
#endif
Imagine we had some code somewhere that checked for TM being active in a
non-TM aware kernel, that would break with this change, because now the
MSR check does nothing when TM=n.
eg. we might check at boot time that we're not transactional, eg. in
case we came from a kdump kernel that was in a transaction.
So if all the call-sites are already inside an #ifdef I'd be inclined to
not add the #ifdef around the MSR_TM_ACTIVE macro.
That way the macro can always be used to check the MSR value, whether TM
is compiled in or out.
cheers
From: Michael Ellerman <hidden> Date: 2018-09-20 04:20:56
On Mon, 2018-06-18 at 22:59:42 UTC, Breno Leitao wrote:
This patch simply fix part of the documentation on the HTM code.
This fixes reference to old fields that were renamed in commit
000ec280e3dd ("powerpc: tm: Rename transct_(*) to ck(\1)_state")
It also documents better the flow after commit eb5c3f1c8647 ("powerpc:
Always save/restore checkpointed regs during treclaim/trecheckpoint"),
where tm_recheckpoint can recheckpoint what is in ck{fp,vr}_state blindly.
Signed-off-by: Breno Leitao <leitao@debian.org>
Acked-By: Michael Neuling <redacted>
From: Michael Ellerman <hidden> Date: 2018-10-04 06:24:44
On Thu, 2018-08-16 at 17:21:07 UTC, Breno Leitao wrote:
Currently msr_tm_active() is a wrapper around MSR_TM_ACTIVE() if
CONFIG_PPC_TRANSACTIONAL_MEM is set, or it is just a function that
returns false if CONFIG_PPC_TRANSACTIONAL_MEM is not set.
This function is not necessary, since MSR_TM_ACTIVE() just do the same and
could be used, removing the dualism and simplifying the code.
This patchset remove every instance of msr_tm_active() and replaced it
by MSR_TM_ACTIVE().
Signed-off-by: Breno Leitao <leitao@debian.org>