From: Ralf Baechle <ralf@linux-mips.org>
To: James Cowgill <James.Cowgill@imgtec.com>
Cc: linux-mips@linux-mips.org
Subject: Re: [PATCH] MIPS: avoid BUG warning in arch_check_elf
Date: Wed, 12 Apr 2017 16:16:52 +0200 [thread overview]
Message-ID: <20170412141652.GA24957@linux-mips.org> (raw)
In-Reply-To: <20170411125108.30107-1-James.Cowgill@imgtec.com>
On Tue, Apr 11, 2017 at 01:51:07PM +0100, James Cowgill wrote:
> arch_check_elf contains a usage of current_cpu_data that will call
> smp_processor_id() with preemption enabled and therefore triggers a
> "BUG: using smp_processor_id() in preemptible" warning when an fpxx
> executable is loaded.
>
> As a follow-up to commit b244614a60ab ("MIPS: Avoid a BUG warning during
> prctl(PR_SET_FP_MODE, ...)"), apply the same fix to arch_check_elf by
> using raw_current_cpu_data instead. The rationale quoted from the previous
> commit:
>
> "It is assumed throughout the kernel that if any CPU has an FPU, then
> all CPUs would have an FPU as well, so it is safe to perform the check
> with preemption enabled - change the code to use raw_ variant of the
> check to avoid the warning."
Which really is a bug though. Multiprocessor systems with discrete CPUs
may use a mix of CPU versions and sometimes the associated FPUs were so
broken the kernel can't use them. On MT with MIPS_MT_FPAFF there's only a
single FPU which stays associated with CPU 0 and we try to do terribly
clever games to force floating point intensive jobs to be scheduled to CPU 0
and use emulation on all other CPUs.
Ralf
prev parent reply other threads:[~2017-04-12 14:17 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-11 12:51 [PATCH] MIPS: avoid BUG warning in arch_check_elf James Cowgill
2017-04-11 12:51 ` James Cowgill
2017-04-12 14:16 ` Ralf Baechle [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=20170412141652.GA24957@linux-mips.org \
--to=ralf@linux-mips.org \
--cc=James.Cowgill@imgtec.com \
--cc=linux-mips@linux-mips.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.