From: Paul Burton <paul.burton@imgtec.com>
To: Huacai Chen <chenhc@lemote.com>
Cc: "Chen Jie" <chenj@lemote.com>,
"Linux MIPS Mailing List" <linux-mips@linux-mips.org>,
"Ralf Baechle" <ralf@linux-mips.org>, 王锐 <wangr@lemote.com>
Subject: Re: [PATCH] Not preempt in CP1 exception handling
Date: Sat, 12 Jul 2014 10:30:03 +0100 [thread overview]
Message-ID: <20140712093003.GF8187@pburton-laptop> (raw)
In-Reply-To: <CAAhV-H5z1Xu5Mg0X68Yf_mpi8ZBg96TEYLkk4_2_Grb8=ET05Q@mail.gmail.com>
On Sat, Jul 12, 2014 at 05:10:35PM +0800, Huacai Chen wrote:
> Hi, Paul,
>
> You means my patch (http://patchwork.linux-mips.org/patch/7297/) is
> the correct way?
I believe you patch will fix the problem, but I think it would be better
to remove the check for !preemptible() & the BUG_ON entirely.
> Another question: Your patch
> (http://patchwork.linux-mips.org/patch/7307/) remove
> preempt_disable()/preempt_enable() in init_fpu(). It will cause
> problems if there is another function call init_fpu() because it is
> previously preempt-safe. Maybe introduce a new function (e.g.
> __init_fpu()) is a better way?
It may cause a problem if there were other callers, but there is only
one caller of init_fpu (enable_restore_fp_context) and it needs to
disable preemption for longer than the init_fpu function anyway. I see
no value in keeping init_fpu as a wrapper that disables preemption
when there would be nothing calling it.
Thanks,
Paul
> Huacai
>
> On Sat, Jul 12, 2014 at 7:28 AM, Chen Jie <chenj@lemote.com> wrote:
> > 2014-07-11 23:56 GMT+08:00 Paul Burton <paul.burton@imgtec.com>:
> >> On Fri, Jul 11, 2014 at 11:14:13AM +0800, chenj wrote:
> >>> do_ade may be invoked with preempt enabled. do_cpu will be invoked with
> >>> preempt enabled. When it's preempted(in do_ade/do_cpu), TIF_USEDFPU will be
> >>> cleared, when it returns to do_ade/do_cpu, the fpu is actually disabled.
> >>>
> >>> e.g.
> >>> In do_ade()
> >>> emulate_load_store_insn():
> >>> BUG_ON(!is_fpu_owner()); <-- This assertion may be breaked.
> >>>
> >>> In do_cpu()
> >>> enable_restore_fp_context():
> >>> was_fpu_owner = is_fpu_owner();
> >>
> >> Preemption should indeed be disabled around the assignment & use of the
> >> was_fpu_owner variable, but note that you can only hit the problem if
> >> using MSA. One of the MSA fixes I just submitted also fixes this along
> >> with another instance of the problem:
> >>
> >> http://patchwork.linux-mips.org/patch/7307/
> >>
> >> I prefer my patch to this since it disables preemption for less time,
> >> in addition to fixing the !used_math() case.
> >>
> >> In emulate_load_store_insn I believe the correct fix is simply to remove
> >> that BUG_ON. The code is about to give up FPU ownership anyway, so it's
> >> not like there is any requirement being violated if it was already lost.
> > Yes, you're right.
> >
> > """ /* arch/mips/kernel/unaligned.c */
> > lose_fpu(1); /* Save FPU state for the emulator. */
> > res = fpu_emulator_cop1Handler(regs, ¤t->thread.fpu, 1, &fault_addr);
> > own_fpu(1); /* Restore FPU state. */
> > """
> >
> > Going deep into the code, I find lost_fpu(1) will save fpu context if
> > owns fpu (otherwise, if preempted, the fpu context will be saved in
> > process switch), then fpu_emulator_cop1Handler manipulates the saved
> > fpu context, own_fpu(1) restores it.
> >
> > So, remove "BUG_ON(!is_fpu_owner())" is OK.
> >
next prev parent reply other threads:[~2014-07-12 9:30 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-11 3:06 [PATCH] MIPS: Don't BUG_ON(!is_fpu_owner()) in do_ade() when preemptible Huacai Chen
2014-07-11 3:14 ` [PATCH] Not preempt in CP1 exception handling chenj
2014-07-11 3:13 ` Chen Jie
2014-07-11 15:56 ` Paul Burton
2014-07-11 15:56 ` Paul Burton
2014-07-11 23:28 ` Chen Jie
2014-07-12 9:10 ` Huacai Chen
2014-07-12 9:30 ` Paul Burton [this message]
2014-07-14 2:22 ` Huacai Chen
2014-08-01 16:48 ` Ralf Baechle
2014-08-19 15:56 ` Chen Jie
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=20140712093003.GF8187@pburton-laptop \
--to=paul.burton@imgtec.com \
--cc=chenhc@lemote.com \
--cc=chenj@lemote.com \
--cc=linux-mips@linux-mips.org \
--cc=ralf@linux-mips.org \
--cc=wangr@lemote.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