All of lore.kernel.org
 help / color / mirror / Atom feed
From: Steffen Persvold <sp@numascale.com>
To: Borislav Petkov <bp@alien8.de>,
	Daniel J Blueman <daniel@numascale-asia.com>,
	Tony Luck <tony.luck@intel.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
	x86@kernel.org, linux-edac@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] x86, amd, mce: Prevent potential cpu-online oops
Date: Tue, 09 Apr 2013 11:25:16 +0200	[thread overview]
Message-ID: <5163DE7C.7060700@numascale.com> (raw)
In-Reply-To: <20130404190731.GG32271@pd.tnic>

On 4/4/2013 9:07 PM, Borislav Petkov wrote:
> On Thu, Apr 04, 2013 at 08:05:46PM +0200, Steffen Persvold wrote:
>> It made more sense (to me) to skip the creation of MC4 all together
>> if you can't find the matching northbridge since you can't reliably
>> do the dec_and_test() reference counting on the shared bank when you
>> don't have the common NB struct for all the shared cores.
>>
>> Or am I just smoking the wrong stuff ?
>
> No, actually *this* explanation should've been in the commit message.
> You numascale people do crazy things with the hardware :) so explaining
> yourself more verbosely is an absolute must if anyone is to understand
> why you're changing the code.
>

Boris,

A question came up. Why have this "shared" bank concept for the kobjects 
at all ? What's the advantage ? Before our patch, when running on our 
architecture but without pci domains for "slave" servers, everything was 
working fine except the de-allocation oops due to the NULL pointer when 
offlining cores.

Why not let all cores just create their individual kobject and skip this 
"shared" nb->bank4 concept ? Any disadvantage to that (apart from the 
obvious storage bloat?).

Cheers,
Steffen



  parent reply	other threads:[~2013-04-09  9:25 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-04-04 15:52 [PATCH] x86, amd, mce: Prevent potential cpu-online oops Daniel J Blueman
2013-04-04 16:04 ` Luck, Tony
2013-04-04 16:13 ` Borislav Petkov
2013-04-04 18:05   ` Steffen Persvold
2013-04-04 19:07     ` Borislav Petkov
2013-04-04 20:01       ` Steffen Persvold
2013-04-09  9:25       ` Steffen Persvold [this message]
2013-04-09  9:38         ` Borislav Petkov
2013-04-09  9:45           ` Steffen Persvold
2013-04-09 10:24             ` Borislav Petkov
2013-04-09 11:34               ` Steffen Persvold

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=5163DE7C.7060700@numascale.com \
    --to=sp@numascale.com \
    --cc=bp@alien8.de \
    --cc=daniel@numascale-asia.com \
    --cc=hpa@zytor.com \
    --cc=linux-edac@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=tglx@linutronix.de \
    --cc=tony.luck@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 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.