From: Borislav Petkov <bp@alien8.de>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: "Ville Syrjälä" <ville.syrjala@linux.intel.com>,
"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
"the arch/x86 maintainers" <x86@kernel.org>,
"Borislav Petkov" <bp@suse.de>, "H . Peter Anvin" <hpa@zytor.com>,
"Andy Lutomirski" <luto@amacapital.net>,
"Brian Gerst" <brgerst@gmail.com>,
"Denys Vlasenko" <dvlasenk@redhat.com>,
"Peter Zijlstra" <peterz@infradead.org>,
"Thomas Gleixner" <tglx@linutronix.de>,
"Ingo Molnar" <mingo@kernel.org>, "Jiri Kosina" <jkosina@suse.cz>
Subject: Re: [PATCH] x86/hweight: Don't clobber %rdi
Date: Mon, 8 Aug 2016 20:37:26 +0200 [thread overview]
Message-ID: <20160808183726.GA22641@nazgul.tnic> (raw)
In-Reply-To: <CA+55aFw8vH5eP8quj=YUXd4YtHXLks2VA18QaveJNVJ1PEsQYg@mail.gmail.com>
On Mon, Aug 08, 2016 at 11:21:20AM -0700, Linus Torvalds wrote:
> ...
> in arch/x86/events/intel/core.c, which then corrupts something related
> to the event constraints, and then you get the oops in
> x86_perf_event_update() later.
Damn.
And I thought that when I hold on to the C ABI and since %rdi is
callee-clobbered, I can simply do "call __sw_hweight64" from within an
asm() statement and it'll all be fine.
Ok, so do you think it would work too if I stated that the input
register gets clobbered:
asm (ALTERNATIVE("call __sw_hweight64", POPCNT64, X86_FEATURE_POPCNT)
: "="REG_OUT (res)
: REG_IN (w)
: REG_IN);
(untested of course).
Because my primitive way of thinking would go like this: well, the input
register is in the list of clobbers and gcc should take care of stashing
it away if it is live across the hweight call. IOW, let gcc do the
push/pop instead of us doing it explicitly.
Or am I missing some aspect?
> The compiler has absolutely nothing to do with this. It's all assembly
> language and an inline asm.
I meant I shouldn't do the compiler's job by coding __sw_hweightXX in
asm. Even though arch/x86/lib/hweight.S is basically copied gcc asm
output, more or less.
But that got us rid of the special calling convention which was a win in
itself.
Thanks.
--
Regards/Gruss,
Boris.
ECO tip #101: Trim your mails when you reply.
--
next prev parent reply other threads:[~2016-08-08 18:37 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-08 17:35 ville.syrjala
2016-08-08 17:58 ` Linus Torvalds
2016-08-08 18:32 ` Peter Zijlstra
2016-08-08 18:53 ` Jiri Kosina
2016-08-08 19:17 ` Borislav Petkov
2016-08-08 18:04 ` Borislav Petkov
2016-08-08 18:21 ` Linus Torvalds
2016-08-08 18:37 ` Borislav Petkov [this message]
2016-08-08 18:45 ` Linus Torvalds
2016-08-08 18:55 ` Borislav Petkov
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=20160808183726.GA22641@nazgul.tnic \
--to=bp@alien8.de \
--cc=bp@suse.de \
--cc=brgerst@gmail.com \
--cc=dvlasenk@redhat.com \
--cc=hpa@zytor.com \
--cc=jkosina@suse.cz \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@amacapital.net \
--cc=mingo@kernel.org \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
--cc=ville.syrjala@linux.intel.com \
--cc=x86@kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®