On Thu, Dec 10, 2015 at 06:38:57PM +0100, Paolo Bonzini wrote:
> Invoking tracepoints within kvm_guest_enter/kvm_guest_exit causes a
> lockdep splat.
>
> Cc: stable@vger.kernel.org
> Reported-by: Borislav Petkov <b...@alien8.de>
> Signed-off-by: Paolo Bonzini <pbonz..
On Fri, Nov 06, 2015 at 11:48:30AM -0800, Greg Kroah-Hartman wrote:
> Thanks for letting me know, now dropped from all trees. If it ever gets
> fixed up, please resend the git commit ids to stable@
Ok, you can pick it back up at your earliest convenience. You need to
apply the fix too:
fi: Disable interrupts around EFI
> calls, not in the epilog/prolog calls") interrupts were disabled
> around the prolog and epilog calls, and the functional GDT was
> re-installed before interrupts were re-enabled.
>
> Which explains why no one has hit this issue unti
On Tue, Sep 29, 2015 at 05:56:07PM -0700, H. Peter Anvin wrote:
> On 09/29/2015 07:36 AM, Matt Fleming wrote:
> >
> > That's a pretty good summary for x86. I think specifically the reason
> > we map the EFI memmap entries "backwards" (entry N has higher VA than
> > entry N+1) is because the code
On Tue, Sep 29, 2015 at 05:31:00PM +0800, Dave Young wrote:
> http://permalink.gmane.org/gmane.linux.kernel.efi/822
>
> And more replies here:
> http://comments.gmane.org/gmane.linux.kernel.efi/820
Whatever we did think back then, it all is moot as long as some UEFI
vendors do funky crap or the
On Sun, Sep 27, 2015 at 09:06:44AM +0200, Ingo Molnar wrote:
> Could we please re-list all the arguments pro and contra of 1:1 physical
> mappings,
> in a post that also explains the background so that more people can chime in,
> not
> just people versed in EFI internals? It's very much
On Wed, Sep 16, 2015 at 03:38:45PM +0200, Ard Biesheuvel wrote:
> That is a can of worms I'd rather keep closed, if you don't mind ...
Same here.
> But in general, since we are already violating the PE/COFF spec by
> relocating each runtime image once, then invoke its entry point, then
> fire an
On Wed, Sep 09, 2015 at 12:21:23PM +0100, Matt Fleming wrote:
> On Wed, 09 Sep, at 08:33:07AM, joeyli wrote:
> >
> > Yes, the machine on my hand has EFI_PROPERTIES_TABLE enabled, and it doesn't
> > boot without your patch.
>
> Awesome. Could you test the following patch instead?
>
> ---
>
>
On Wed, Sep 16, 2015 at 01:25:06PM +0200, Ard Biesheuvel wrote:
> ... so even if we wanted to, it would be intractible to find each
> cross-section relative reference and do the fixup.
Hmm, maybe we should go and patch EFI code segments and fixup all
relative references after mapping. I mean, if
in multithreaded
programs, but there shouldn't be any multithreaded programs that
care about modify_ldt's performance in the first place.
Cc: stable@vger.kernel.org
Signed-off-by: Andy Lutomirski l...@kernel.org
I've stared a lot at this one these days, I guess a
Reviewed-by: Borislav Petkov b
On Fri, Jul 24, 2015 at 09:52:01PM -0700, Andy Lutomirski wrote:
I see your wide terminal and raise you a complete rewrite of that
function. Sigh, why did I assume the old code was the right way to do
it?
That's a mostly wrong assumption, as experience proves.
Hah¸ we both missed it. This
in multithreaded
programs, but there shouldn't be any multithreaded programs that
care about modify_ldt's performance in the first place.
Cc: stable@vger.kernel.org
Signed-off-by: Andy Lutomirski l...@kernel.org
Reviewed-by: Borislav Petkov b...@suse.de
--
Regards/Gruss,
Boris.
ECO tip #101
On Wed, Jul 22, 2015 at 12:23:46PM -0700, Andy Lutomirski wrote:
modify_ldt has questionable locking and does not synchronize
threads. Improve it: redesign the locking and synchronize all
threads' LDTs using an IPI on all modifications.
This will dramatically slow down modify_ldt in
On Wed, Jul 22, 2015 at 12:23:46PM -0700, Andy Lutomirski wrote:
modify_ldt has questionable locking and does not synchronize
threads. Improve it: redesign the locking and synchronize all
threads' LDTs using an IPI on all modifications.
This will dramatically slow down modify_ldt in
...@amd.com
Signed-off-by: Borislav Petkov b...@suse.de
Cc: H. Peter Anvin h...@zytor.com
Cc: Thomas Gleixner t...@linutronix.de
Cc: konrad.w...@oracle.com
Fixes: 6e9636693373 (x86, iommu: Update header comments with appropriate
naming)
Link:
http://lkml.kernel.org/r/1428508017-5316-1-git-send
On Thu, Apr 23, 2015 at 05:51:33PM -0700, Andi Kleen wrote:
There were systems in the past that ran TSC at a much slower
frequency, such as the early AMD Barcelona systems.
You mean the eval boxes which were never sold as production systems?
--
Regards/Gruss,
Boris.
ECO tip #101: Trim
Adding Peter.
On Mon, Apr 20, 2015 at 11:21:13AM +0200, Jean Delvare wrote:
Commit 178c2490b99f898efc06d1ad75cadc84f13021a6 (thermal: step_wise:
cdev only needs update on a new target state) broke driver acerhdf.
That driver abused the step_wise thermal governor until the bang_bang
governor
On Sun, Mar 29, 2015 at 02:16:05PM -0700, Andy Lutomirski wrote:
sysexit_from_sys_call:
/*
* Sysretl works even on Intel CPUs. Use it in preference to
sysexit,
* since it avoids a dicey window with interrupts enabled.
Btw, let's agree on the convention to
On Sat, Mar 28, 2015 at 08:17:42AM -0700, Andy Lutomirski wrote:
Agreed. I wish we had a Stable-after-a-long-soak tag.
You can set yourself a reminder for, say 6 months from now and if all is
still kosher with the patch, backport it then yourself and send it to
stable@.
--
Regards/Gruss,
On Wed, Jan 14, 2015 at 10:40:01AM -0500, Steven Rostedt wrote:
From: Steven Rostedt (Red Hat) rost...@goodmis.org
If the function graph tracer traces a jprobe callback, the system will
crash. This can easily be demonstrated by compiling the jprobe
sample module that is in the kernel tree,
Hi Greg,
here are the upstream commits which are needed for the microcode loader
on 3.18-stable. I'm testing on both 32- and 64-bit, AMD and Intel, just
to be sure. This is 3.18-stable only, the others will follow as time
allows.
Here's the patchlist:
1. 2ef84b3bb97f (x86, microcode, AMD: Do
On Mon, Dec 29, 2014 at 09:58:30PM +0100, Moritz Muehlenhoff wrote:
Hi,
3b56496865f9f7d9bcb2f93b44c63f274f08e3b6 wasn't CCed to stable@
but I think it qualifies for stable kernels prior to 3.14?
I don't see anything wrong with picking it up for any kernel, so stable
guys, feel free...
On Sat, Dec 06, 2014 at 04:07:06PM +0100, Jiri Slaby wrote:
From: Andy Lutomirski l...@amacapital.net
3.12-stable review patch. If anyone has any objections, please let me know.
===
commit 6f442be2fb22be02cafa606f1769fa1e6f894441 upstream.
On a 32-bit kernel, this has no
On Wed, Dec 03, 2014 at 02:42:33PM -0800, gre...@linuxfoundation.org wrote:
This is a note to let you know that I've just added the patch titled
x86, microcode: Update BSPs microcode on resume
to the 3.14-stable tree which can be found at:
On Wed, Dec 03, 2014 at 02:42:48PM -0800, gre...@linuxfoundation.org wrote:
This is a note to let you know that I've just added the patch titled
x86, microcode: Update BSPs microcode on resume
to the 3.17-stable tree which can be found at:
On Tue, Dec 02, 2014 at 09:36:40AM -0500, Boris Ostrovsky wrote:
All tests passed.
Thanks!
I wonder whether we should prevent all guests (not just paravirt) from
loading microcode driver (and from doing early microcode loading).
I don't think the unmodified ones need to. At least I haven't
On Tue, Dec 02, 2014 at 11:03:15AM -0800, Kamal Mostafa wrote:
This is a note to let you know that I have just added a patch titled
x86, microcode: Update BSPs microcode on resume
to the linux-3.13.y-queue branch of the 3.13.y-ckt extended stable tree
which can be found at:
On Mon, Dec 01, 2014 at 04:27:44PM -0500, Boris Ostrovsky wrote:
Paravirtual guests are not expected to load microcode into processors
and therefore it is not necessary to initialize microcode loading
logic.
In fact, under certain circumstances initializing this logic may cause
the guest to
On Mon, Dec 01, 2014 at 11:12:38PM +0100, Paolo Bonzini wrote:
We also do not want to load microcode. :) Thanks for the heads-up.
You don't need to :P
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
--
To unsubscribe from this list: send the line
On Mon, Dec 01, 2014 at 05:31:56PM -0500, Boris Ostrovsky wrote:
I think so. The problem we have now is __pa() macro that we only use
on 32-bit. I'll queue this for overnight tests to make sure and if it
indeed works then 3.19 should be fine.
Cool, thanks.
I'd still take your patch for 3.19
On Wed, Nov 26, 2014 at 07:13:02PM -0800, Boris Ostrovsky wrote:
I was confusing you: accessing dis_ucode_ldr by virtual address does
work on PV. But we then fail later, in load_ucode_intel_ap(), because
it also tries to use __pa_nodebug() which can't be used by PV.
So if accessing
On Thu, Nov 27, 2014 at 11:19:27AM +, Luis Henriques wrote:
Thanks Boris, I'll drop it from the 3.16 kernel that is currently
under review.
Ok, thanks.
Just FYI: I'm currently testing a fix which is solely for 3.18 and won't
be tagged for stable so that 3.18 doesn't regress on 32-bit.
On Thu, Nov 27, 2014 at 11:21:19AM -0500, Konrad Rzeszutek Wilk wrote:
Ok, but let's have a clean design: maybe have a weak default stub which
returns false when PARAVIRT is not enabled in the .config and then add
an override in, say, arch/x86/kernel/paravirt.c which returns true when
On Thu, Nov 27, 2014 at 09:14:11AM -0800, Boris Ostrovsky wrote:
The overnight tests passed. This includes baremetal, HVM and PV(H),
32- and 64-bit.
Cool. Want to send a proper patch for 3.18 and CC: stable?
Thanks.
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk.
On Wed, Nov 26, 2014 at 12:00:45AM -0500, Boris Ostrovsky wrote:
Sigh... I take this back. It breaks 32-bit baremetal. I haven't looked any
further but it seems to be dying very early. I suspect cpuid pv_op is not
set up yet. If that's true, perhaps you could check whether it is valid in
On Wed, Nov 26, 2014 at 07:39:26AM -0500, boris ostrovsky wrote:
https://lkml.org/lkml/2014/11/25/973 is all I have right now.
Ok, so the Code: section from this splat says:
25: 55 push %ebp
26: 89 e5 mov%esp,%ebp
28: 83 ec 08
Guys,
please do not pick up this patch for stable because it breaks 32-bit
microcode loading on intel. I'll let you know once I have a fix.
Thanks.
- Forwarded message from tip-bot for Borislav Petkov tip...@zytor.com
-
Date: Tue, 18 Nov 2014 09:40:23 -0800
From: tip-bot for Borislav
On Tue, Nov 25, 2014 at 01:12:10PM -0500, Boris Ostrovsky wrote:
On 11/19/2014 03:52 PM, Greg Kroah-Hartman wrote:
3.17-stable review patch. If anyone has any objections, please let me know.
This breaks PV on Xen.
-boris
--
From: Borislav Petkov b...@suse.de
On Tue, Nov 25, 2014 at 01:43:26PM -0500, Boris Ostrovsky wrote:
I don't think this routine is called on PV.
They're either both called or none is. At least on baremetal, that is.
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
--
To unsubscribe from
On Tue, Nov 25, 2014 at 10:45:01AM -0800, Greg Kroah-Hartman wrote:
Does that mean it is also broken in Linus's tree?
Should be.
If so, please fix it there.
Gladly, if Boris would share some more info as to why it breaks the PV
gunk...
--
Regards/Gruss,
Boris.
Sent from a fat crate
On Tue, Nov 25, 2014 at 01:55:29PM -0500, Boris Ostrovsky wrote:
On 11/25/2014 01:43 PM, Borislav Petkov wrote:
On Tue, Nov 25, 2014 at 01:43:26PM -0500, Boris Ostrovsky wrote:
I don't think this routine is called on PV.
They're either both called or none is. At least on baremetal
On Tue, Nov 25, 2014 at 01:55:29PM -0500, Boris Ostrovsky wrote:
On 11/25/2014 01:43 PM, Borislav Petkov wrote:
On Tue, Nov 25, 2014 at 01:43:26PM -0500, Boris Ostrovsky wrote:
I don't think this routine is called on PV.
They're either both called or none is. At least on baremetal
On Tue, Nov 25, 2014 at 02:28:46PM -0500, Boris Ostrovsky wrote:
You'd have to decide at runtime --- many baremetal systems are
compiled with PARAVIRT.
Right, but the microcode loader is not used at all on PV, right?
If so, I'd like to add a arch_something_blabla_disabled_loader()
function
On Tue, Nov 25, 2014 at 03:36:34PM -0500, Konrad Rzeszutek Wilk wrote:
Is there an use-case for this in virtualization at all?
Not that I know of...
Why not make it in general then? Like:
if (cpu_has_hypervisor)
return;
Ah, good idea. Although we need to do it by-foot because the
Adding x86 people.
On Tue, Nov 25, 2014 at 04:59:34PM -0500, Boris Ostrovsky wrote:
This should be cpuid(0x1, eax, ebx, ecx, edx). Otherwise we are not
getting bits that the hypervisor wants the guest to see (on Xen cpuid()
turns into hypercall, on baremetal it's native).
With that change
.
Cc: stable@vger.kernel.org
Fixes: 719d5a9b2487e0562f178f61e323c3dc18a8b200
Reported-by: Borislav Petkov b...@suse.de
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
Thanks Paolo, the ept=0 case seems to work now. I'll stress it more
later this week.
Tested-by: Borislav Petkov b...@suse.de
On Mon, Oct 06, 2014 at 08:37:36AM -0700, Greg KH wrote:
If you have tagged this with a stable cc:
Yes it is.
then I'll get it automatically when Linus pulls it. And I have to wait
until then before I can apply it anyway...
Ok, thanks.
--
Regards/Gruss,
Boris.
Sent from a fat crate
Hi Greg,
can you please pick this one up for 3.17-stable too?
Upstream commit should be a18c3f16a907b8977ef65fc8dd71ed3f7b751748 after
Linus pulls. But check first whether he has pulled at all...
:-)
Thanks.
- Forwarded message from Borislav Petkov b...@suse.de -
Date: Tue, 30 Sep
On Mon, Jun 23, 2014 at 02:22:15PM -0700, Andy Lutomirski wrote:
The bad syscall nr paths are their own incomprehensible route
through the entry control flow. Rearrange them to work just like
syscalls that return -ENOSYS.
This fixes an OOPS in the audit code when fast-path auditing is
On Tue, Jun 24, 2014 at 01:53:25PM -0700, Andy Lutomirski wrote:
It confirms my sense that no one knows how to test this stuff :-/
It's pretty clear that no one has ever extensively hammered it.
Someone might've known at some point but who knows who knew. :-)
I wonder how much could be
On Wed, May 07, 2014 at 11:18:49AM +0200, Sven Joachim wrote:
I would rather not set up a virtual machine just for wine (I don't
have Windows anymore).
What about reactos? (I'm not saying this shouldn't be addressed,
regardless...)
--
Regards/Gruss,
Boris.
Sent from a fat crate under my
On Mon, Apr 14, 2014 at 09:21:13AM +0200, Ingo Molnar wrote:
Apparently the game in question is Exile: Escape from the pit:
http://osdir.com/ml/wine-bugs/2014-04/msg01159.html
Ah, thanks.
Well, FWIW, you can get the game for free:
http://www.spiderwebsoftware.com/exile/winexile.html
I
On Sat, Apr 12, 2014 at 10:18:25AM -0700, H. Peter Anvin wrote:
So Wine regressed and noone noticed? They doesn't sound like an active
user base.
Btw, wouldn't this obscure use case simply work in a KVM guest with a
kernel = 3.14?
Because if so, we simply cut it at 3.14, everything newer has
On Sat, Apr 12, 2014 at 12:44:42PM -0700, H. Peter Anvin wrote:
Run a 32-bit VM. The 32-bit kernel does this right.
Yes, even better.
I suspect it would also work fine in a Qemu user mode guest (is
this supported by KVM?), in a ReactOS VM, or some other number of
combinations.
Right.
So
On Sat, Apr 12, 2014 at 04:34:14PM -0400, Brian Gerst wrote:
My experience with kvm so far is that is slow and clunky. It may be OK
for a server environment, but interactively it's difficult to use.
Are you saying, you've run your game in a guest and perf. is sucky?
--
Regards/Gruss,
On Sat, Apr 12, 2014 at 05:13:40PM -0400, Brian Gerst wrote:
Performance is bad in general, running a 32-bit Fedora 20 guest.
So this means you haven't tried the game in the guest yet, so that we
can know for sure that a guest doesn't solve your problem or what?
Btw, which game is that and can
...@hp.com
Signed-off-by: Borislav Petkov b...@suse.de
Tested-by: Toshi Kani toshi.k...@hp.com
Signed-off-by: Matt Fleming matt.flem...@intel.com
Signed-off-by: Borislav Petkov b...@suse.de
---
arch/x86/include/asm/efi.h | 3 +-
arch/x86/platform/efi/efi.c| 99
Commit-ID: d5a1c7e3fc38d9c7d629e1e47f32f863acbdec3d
Gitweb: http://git.kernel.org/tip/d5a1c7e3fc38d9c7d629e1e47f32f863acbdec3d
Author: Borislav Petkov b...@alien8.de
AuthorDate: Sat, 20 Jul 2013 19:00:23 +0200
Committer: John Stultz john.stu...@linaro.org
CommitDate: Mon, 23 Dec 2013 12
On Thu, Dec 19, 2013 at 06:40:41AM -0800, H. Peter Anvin wrote:
... or just use static_cpu_has() maybe?
Right, if we can get the compiler to generate the shortest CLFLUSH of 3
bytes with register indirect addressing for the operand, then stomping
over those 3 bytes with the alternatives would be
On Mon, Nov 25, 2013 at 08:50:28PM +0100, Oleg Nesterov wrote:
This won't work if va + len overflows?
Oh, right,
Perhaps we should makes this clear, and we can even check the overflow
in the generic code (iirc Linus suggested to do this).
maybe something like
((va + len - 1) =
On Tue, Nov 12, 2013 at 05:39:43PM +0100, Thomas Renninger wrote:
Do it the same way as done in microcode_intel.c:
use pr_debug for missing firmware files.
There seem to be CPUs out there for which no microcode update has been
submitted to kernel-firmware repo yet resulting in:
microcode:
On Tue, Nov 12, 2013 at 12:00:30PM -0500, Josh Boyer wrote:
Not serious, but from a distro perspective it would really be nice to
have. We get queries on why it's an error and where are the firmware
files for family 16h, etc. Explaining it can get tiring ;).
I know that - that's the reason why
On Tue, Nov 12, 2013 at 09:59:31PM +0100, Ingo Molnar wrote:
* Borislav Petkov b...@suse.de wrote:
On Tue, Nov 12, 2013 at 12:00:30PM -0500, Josh Boyer wrote:
Not serious, but from a distro perspective it would really be nice to
have. We get queries on why it's an error and where
On Tue, Nov 12, 2013 at 10:26:42PM +0100, Ingo Molnar wrote:
Yes, but it's cheaper to pick it one time for the mainline kernel and let
all the dozens of Linux distros have it.
The 'let the distro pick the patch' applies for cases where we _disagree_
with the urgency of the patch, where the
(fixed stable@vger).
On Tue, Nov 12, 2013 at 11:45:11PM +0100, Borislav Petkov wrote:
On Tue, Nov 12, 2013 at 01:58:00PM -0800, tip-bot for Thomas Renninger wrote:
Commit-ID: 11f918d3e2d3861b6931e97b3aa778e4984935aa
Gitweb:
http://git.kernel.org/tip
On Wed, Nov 13, 2013 at 12:05:54AM +0100, Ingo Molnar wrote:
Well, the entry above it already covers this particular case, doesn't
it? It fixes a real bug that clearly bothers people.
Actually, I read the entry above as it really is a bug and not some
hypothetical issue or flags cleanup or
On Wed, Nov 13, 2013 at 12:10:08AM +0100, Ingo Molnar wrote:
Hm, that's really weird, I've been using sta...@kernel.org for years
and the commits do get picked up. I also never saw such a mailer
failure.
In any case I've changed my pre-cooked alias to
stable@vger.kernel.org, but still I'm
On Thu, Oct 31, 2013 at 03:49:04PM +0100, Paolo Bonzini wrote:
Il 31/10/2013 15:34, Gleb Natapov ha scritto:
I haven't checked AMD doc, but if it is documented that lahf/sahf #UDs at 64
bit we should emulate it correctly.
It says The LAHF instruction can only be executed in 64-bit mode if
the pagetables,
but does it without any apparent performance loss versus the current
broken version.
Signed-off-by: Alex Williamson alex.william...@redhat.com
Reviewed-by: Marcelo Tosatti mtosa...@redhat.com
Signed-off-by: Joerg Roedel j...@8bytes.org
Signed-off-by: Borislav Petkov b...@suse.de
@vger.kernel.org # 3.10+
Acked-by: Borislav Petkov b...@suse.de
---
tools/lib/lk/debugfs.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/tools/lib/lk/debugfs.c b/tools/lib/lk/debugfs.c
index 099e7cd..7c43479 100644
--- a/tools/lib/lk/debugfs.c
+++ b/tools/lib/lk/debugfs.c
@@ -5,7 +5,6
On Wed, Aug 21, 2013 at 01:54:01PM -0700, Tony Luck wrote:
On Wed, Aug 21, 2013 at 1:00 PM, Borislav Petkov b...@alien8.de wrote:
We don't want to run daily snapshots of your tree though, right? Only
-rcs because the daily states are kinda arbitrary and they can be broken
in various ways
On Tue, Aug 20, 2013 at 03:40:32PM -0700, Greg KH wrote:
- I will wait for a -rc to come out with the patch in it before putting
it into a stable release, unless:
Question: what's the exact reasoning of that delay? To get more people
who install -rc kernels to smoke-test patches tagged for
On Wed, Aug 21, 2013 at 11:36:05AM -0700, Linus Torvalds wrote:
Will it catch all cases? Hell no. We don't have *that* many people who
run git kernels, and even people who do don't tend to update daily
anyway.
We don't want to run daily snapshots of your tree though, right? Only
-rcs because
On Wed, Aug 21, 2013 at 01:58:16PM -0400, Steven Rostedt wrote:
The point I'm making, we should be more reluctant in pulling patches
into stable as quick as we are. A patch ideally should simmer in
linux-next for a bit, then go into mainline.
Oh, and it is really debatable if the sheer volume
On Wed, Aug 21, 2013 at 01:16:00PM -0700, Greg KH wrote:
And I pushed back on that. Which specific stable patch should _not_
have been included?
Well, here's one for example:
https://git.kernel.org/cgit/linux/kernel/git/tip/tip.git/commit/?id=f0a56c480196a98479760862468cc95879df3de0
On Tue, Aug 20, 2013 at 10:28:58AM +0200, Johannes Berg wrote:
Something like the patch below, perhaps? Completely untested so far.
Yeah, this one seems to fix it here (I was seeing the same lockdep splat
as Hugh).
Thanks.
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk.
On Wed, May 08, 2013 at 12:13:03PM -0400, Konrad Rzeszutek Wilk wrote:
This can easily be triggered if a new CPU is added (via
ACPI hotplug mechanism) and from user-space do:
echo 1 /sys/devices/system/cpu/cpu3/online
(or wait for UDEV to do it) on a newly appeared CPU.
The deadlock is
On Thu, May 02, 2013 at 09:43:05AM +0200, Daniel Vetter wrote:
Since we know that locking is broken in that case and it's more
important to not flood the dmesg with random gunk.
Cc: Dave Airlie airl...@gmail.com
Cc: Borislav Petkov b...@alien8.de
References:
https://groups.google.com
On Thu, Mar 14, 2013 at 05:10:39PM -0400, Boris Ostrovsky wrote:
Boris,
Here is the updated patch for determining number of regiter banks on
AMD plus a patch removing shared_bank array, as you suggested.
Offline/online testing didn't show any issues.
Boris Ostrovsky (2):
On Thu, Mar 14, 2013 at 03:20:05PM -0700, Greg KH wrote:
On Thu, Mar 14, 2013 at 05:10:40PM -0400, Boris Ostrovsky wrote:
Use helper function instead of an array to report whether register
bank is shared. Currently only bank 4 (northbridge) is shared.
Signed-off-by: Boris Ostrovsky
On Wed, Jan 30, 2013 at 07:52:26AM -0800, Joe Perches wrote:
There isn't really any need to add
this to stable. It fixes a cosmetic,
code correctness bug only.
The computed alloc size is the same
regardless of the argument order.
My bad.
Greg, please drop it from the stable queue,
On Wed, Jan 30, 2013 at 05:23:29PM +0100, Greg KH wrote:
How is the size the same both ways? Is the count always somehow the
same value as the size of the structure? How is that possible? Luck?
static inline void *kmalloc_array(size_t n, size_t size, gfp_t flags)
{
if (size != 0 n
@vger.kernel.org # 3.[67]
Cc: Denis Kirjanov kirja...@gmail.com
Cc: Mauro Carvalho Chehab mche...@redhat.com
Link: http://lkml.kernel.org/r/20121214110310.11019.21098.stgit@zurg
[ a partial 3.6.y backport ]
Signed-off-by: Borislav Petkov b...@suse.de
---
drivers/edac/edac_mc_sysfs.c | 2 +-
1 file
@vger.kernel.org # 3.[67]
Cc: Denis Kirjanov kirja...@gmail.com
Cc: Mauro Carvalho Chehab mche...@redhat.com
Link: http://lkml.kernel.org/r/20121214110310.11019.21098.stgit@zurg
[ a partial 3.7.y backport ]
Signed-off-by: Borislav Petkov b...@suse.de
---
drivers/edac/edac_mc_sysfs.c | 2 +-
1 file
sure we stay within scrubrates' array bounds.
Boris: this is a correctness fix only because the loop terminates
earlier due to us capping scrubbing bandwidth to 0.
Signed-off-by: Denis Kirjanov kirja...@gmail.com
Signed-off-by: Borislav Petkov borislav.pet...@amd.com
---
drivers/edac/amd64_edac.c
On Tue, Oct 23, 2012 at 01:37:09PM -0700, Andrew Morton wrote:
This is still strange. What's the point in having the initial loop
even consider the last element in the array if we know we'll be using
it anyway?
You're right, yours is better.
Now you only need to give me a proper patch with
On Tue, Oct 23, 2012 at 02:09:39PM -0700, Andrew Morton wrote:
On Tue, 23 Oct 2012 22:49:26 +0200
Borislav Petkov b...@amd64.org wrote:
Now you only need to give me a proper patch with your S-O-B and we're
ready to go :).
who, me, what?!?! Sounds stressful.
Yeah, this is to show you
On Fri, Oct 19, 2012 at 01:45:27PM +0800, Tang Chen wrote:
cmci_rediscover() is only called by the CPU_POST_DEAD event handler,
which means the corresponding cpu has already dead. As a result, it
won't be accessed in the for_each_online_cpu loop.
So, we could change the if(cpu == dying)
On Fri, Oct 19, 2012 at 01:45:28PM +0800, Tang Chen wrote:
cmci_rediscover() used set_cpus_allowed_ptr() to change the current process's
running cpu, and migrate itself to the dest cpu. But worker processes are not
allowed to be migrated. If current is a worker, the worker will be migrated to
On Thu, Sep 27, 2012 at 01:48:31PM -0700, Greg KH wrote:
On Mon, Aug 06, 2012 at 03:55:54PM +0200, Borislav Petkov wrote:
From: Shuah Khan shuahk...@gmail.com
upstream commit: e826abd523913f63eb03b59746ffb16153c53dc4
Change reload_for_cpu() in kernel/microcode_core.c to call kstrtoul
On Thu, Sep 27, 2012 at 01:49:16PM -0700, Greg KH wrote:
On Mon, Aug 06, 2012 at 03:55:53PM +0200, Borislav Petkov wrote:
Ok,
here are the two patches needed for the correct backport of the third
patch.
The 1st one is needed so that the 3rd one applies
cleanly and the 2nd one
, there
is no _PRx to support ZPODD, we use _PSx.
So instead of printing a useless warning message on AMD's platform,
changing the print level to DEBUG to suppress this message.
Reported-by: Borislav Petkov borislav.pet...@amd.com
Cc: stable@vger.kernel.org 3.5+
Signed-off-by: Aaron Lu aaron
Ok,
here are the two patches needed for the correct backport of the third
patch.
The 1st one is needed so that the 3rd one applies
cleanly and the 2nd one fixes a !SMP build (see:
http://marc.info/?l=linux-kernelm=134398493228757). Also, it is the
backported copy which went into 3.2 collapsing
Persvold s...@numascale.com
Link:
http://lkml.kernel.org/r/1324428742-12498-1-git-send-email-kjwinches...@gmail.com
Signed-off-by: Ingo Molnar mi...@elte.hu
Signed-off-by: Borislav Petkov borislav.pet...@amd.com
Signed-off-by: Ben Hutchings b...@decadent.org.uk
---
arch/x86/include/asm
From: Borislav Petkov borislav.pet...@amd.com
upstream commit: c9fc3f778a6a215ace14ee556067c73982b6d40f
Microcode reloading in a per-core manner is a very bad idea for both
major x86 vendors. And the thing is, we have such interface with which
we can end up with different microcode versions
From: Shuah Khan shuahk...@gmail.com
upstream commit: e826abd523913f63eb03b59746ffb16153c53dc4
Change reload_for_cpu() in kernel/microcode_core.c to call kstrtoul()
instead of calling obsoleted simple_strtoul().
Signed-off-by: Shuah Khan shuahk...@gmail.com
Reviewed-by: Borislav Petkov b
Patches are against 3.4.7 and the 1st is needed for the 2nd to apply
cleanly.
Again, build-tested 32- and 64-bit standard configs (all/no/mod/def).
Thanks.
--
To unsubscribe from this list: send the line unsubscribe stable in
the body of a message to majord...@vger.kernel.org
More majordomo
From: Shuah Khan shuahk...@gmail.com
upstream commit: e826abd523913f63eb03b59746ffb16153c53dc4
Change reload_for_cpu() in kernel/microcode_core.c to call kstrtoul()
instead of calling obsoleted simple_strtoul().
Signed-off-by: Shuah Khan shuahk...@gmail.com
Reviewed-by: Borislav Petkov b
From: Borislav Petkov borislav.pet...@amd.com
upstream commit: c9fc3f778a6a215ace14ee556067c73982b6d40f
Microcode reloading in a per-core manner is a very bad idea for both
major x86 vendors. And the thing is, we have such interface with which
we can end up with different microcode versions
On Sat, Aug 04, 2012 at 06:23:41PM +0100, Ben Hutchings wrote:
[ … ]
Thanks everyone for working this out.
If you combine multiple mainline commits like this, the new commit
message should refer to all of them. I've fixed that up this time.
Thanks.
Ben, the backport is also
1 - 100 of 110 matches
Mail list logo
