All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stefan Bader <stefan.bader@canonical.com>
To: "H. Peter Anvin" <hpa@zytor.com>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Avi Kivity <avi@redhat.com>, Cong Wang <xiyou.wangcong@gmail.com>,
	Ingo Molnar <mingo@elte.hu>, Yinghai Lu <yinghai@kernel.org>,
	Tejun Heo <tj@kernel.org>,
	Konrad Rezeszutek Wilk <konrad.wilk@oracle.com>,
	Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH] x86/mm: Limit 2/4M size calculation to x86_32
Date: Fri, 31 Aug 2012 09:56:53 -0700	[thread overview]
Message-ID: <5040ECD5.8010305@canonical.com> (raw)
In-Reply-To: <a6b71e0f-d2d3-44b5-a939-f909ea3fdccc@email.android.com>

On 08/31/2012 09:41 AM, H. Peter Anvin wrote:
> I'm not saying we shouldn't patch the regression, but this house of cards
> *needs* to be replaced with something robust and correct by construction.

Then I did misunderstand/-interpret you about the former part and we actually 
are agreeing on the whole topic. Sorry about that. So the re-post just should 
serve as a reminder as the last comment here was quite a while ago.

>
> Stefan Bader <stefan.bader@canonical.com> wrote:
>
>> Avi wrote:
>>> The fact that the check is only done on i386 and not on x86_64 may come
>>> from one of
>>>
>>> - an oversight - by the time x86_64 processors came along, the problem
>>> with conflicting sizes was resolved - the whole thing is bogus
>>>
>>> Copying hpa who may be in a position to find out which.
>>
>> Talking to hpa it is more of the last. For more than just this reason.
>> Since the whole area of initial page tables seems to be rather sensitive
>> and easy to break there have been discussions and plans to come up with a
>> rewrite to improve on all those shortcomings.
>>
>> The detail I am not agreeing with hpa is the fixup for the immediate
>> breakage at head. IMO right now the code just has regressed and that should
>> be fixed as soon as possible. Plus doing a specific and small fix allows
>> that to be applicable to stable (which again still depends on things being
>> upstream).
>>
>> Hence the re-send in the hope that on the larger scale the may be agreement
>> on the immediate fix. I am not doubting the usefulness or need of a better
>> solution, but I think that having a remedy of the current situation just
>> until then has enough benefit to be considered.
>>
>> -Stefan


  reply	other threads:[~2012-08-31 16:57 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-07-13 13:41 x86/mm: Limit 2/4M size calculation to x86_32 Stefan Bader
2012-07-13 18:12 ` Yinghai Lu
2012-07-15 19:09   ` Stefan Bader
2012-07-19 16:28 ` Stefan Bader
2012-07-24 15:52 ` Cong Wang
2012-07-25 10:44   ` Avi Kivity
2012-07-25 11:14     ` Stefan Bader
2012-07-25 12:32       ` Avi Kivity
2012-07-25 13:24         ` Stefan Bader
2012-07-25 13:40           ` Avi Kivity
2012-07-31  9:48             ` Stefan Bader
2012-07-31 10:07               ` Avi Kivity
2012-08-31 16:31                 ` [PATCH] " Stefan Bader
2012-08-31 16:41                   ` H. Peter Anvin
2012-08-31 16:56                     ` Stefan Bader [this message]
2012-09-07 11:12                     ` Stefan Bader

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=5040ECD5.8010305@canonical.com \
    --to=stefan.bader@canonical.com \
    --cc=akpm@linux-foundation.org \
    --cc=avi@redhat.com \
    --cc=hpa@zytor.com \
    --cc=konrad.wilk@oracle.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=tj@kernel.org \
    --cc=xiyou.wangcong@gmail.com \
    --cc=yinghai@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.