[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <200903130942.38568.trenn@suse.de>
Date: Fri, 13 Mar 2009 09:42:37 +0100
From: Thomas Renninger <trenn@...e.de>
To: Ingo Molnar <mingo@...e.hu>
Cc: Andreas Herrmann <andreas.herrmann3@....com>,
Ingo Molnar <mingo@...hat.com>,
Thomas Gleixner <tglx@...utronix.de>,
"H. Peter Anvin" <hpa@...or.com>, linux-kernel@...r.kernel.org,
Yinghai Lu <yinghai@...nel.org>,
"Greg Kroah-Hartman" <gregkh@...ell.com>
Subject: Re: [PATCH v2] x86: mtrr: don't modify RdDram/WrDram bits of fixed MTRRs
On Friday 13 March 2009 02:58:56 Ingo Molnar wrote:
>
> * Andreas Herrmann <andreas.herrmann3@....com> wrote:
>
> > Impact: bug fix + BIOS workaround
>
> > Change to previous version:
> > I slightly modified the log message (e.g. addition of FW_WARN).
> >
> > Please consider to apply this patch for .29.
>
> i've applied it to tip:x86/mtrr, thanks Andreas.
>
> I've add a -stable backport tag - so if it's problem-free it
> should show up in .29.1.
What does -stable backport tag mean?
Is this something tip:x86 or Ingo Molnar specific?
I saw quite some "easy" fixes not being added/submitted to stable
in other subsystems and doing double work going through them,
pick them out and submit them to stable is an unnecessary waste
of time and some fixes will slip through.
Is there a general approach all maintainers should handle this?
If not, maybe you could suggest your way of handling this to others?
Thanks,
Thomas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists