linux-kernel - Re: [PATCH] [104/223] KVM: Write protect memory after slot swap

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <AANLkTikNp=mOBK9JNiNj2BC6eg=X13N-85+VWL-wiWh4@mail.gmail.com>
Date:	Mon, 13 Dec 2010 12:36:13 -0500
From:	Paul Gortmaker <paul.gortmaker@...driver.com>
To:	Avi Kivity <avi@...hat.com>
Cc:	Andi Kleen <andi@...stfloor.org>, mst@...hat.com, gregkh@...e.de,
	ak@...ux.intel.com, linux-kernel@...r.kernel.org, stable@...nel.org
Subject: Re: [PATCH] [104/223] KVM: Write protect memory after slot swap

On Mon, Dec 13, 2010 at 12:08 PM, Avi Kivity <avi@...hat.com> wrote:
> On 12/13/2010 06:56 PM, Paul Gortmaker wrote:
>>
>> On Mon, Dec 13, 2010 at 4:16 AM, Avi Kivity<avi@...hat.com>  wrote:
>> >  On 12/13/2010 11:12 AM, Andi Kleen wrote:
>> >>
>> >>  >    - Greg rejects kvm patches (but not virtio etc) pointing
>> >> submitters
>> >>  >    to the kvm maintainers
>> >>  >    - The kvm maintainers collect stable kvm patches and autotest
>> >> them
>> >>
>> >>  As I understand this patch came in this way for .36
>> >>  (I took it from .36-stable)
>> >
>> >  The patch was autotested for .36-stable, it wasn't autotested for
>> >  .35-stable.  It will very likely work (this isn't code that changes a
>> > lot),
>> >  but still.
>> >
>> >>  >    - They then submit the patches to stable@
>> >>
>> >>  Do you want to do the autotest explicitely for .35 too and no
>> >> automatic
>> >>  backports and do the same procedure as for newer kernels?
>> >>
>> >>  I can do that, but you would need to do it for a long time.
>> >
>> >  Yes.  In fact it gets more important as time goes by, since as time
>> > goes by
>> >  patches are more likely to cause regressions due to changes in the code
>> >  base.
>>
>> My workflow is largely the same as Andi's -- in that I'm using patches
>> that
>> have already been nominated for other stable releases and putting them
>> on the 34-lt (longterm) as appropriate.  Are you interested in also doing
>> the
>> same thing for 34-lt (i.e. you generating a 34 specific, pre-tested
>> patchset
>> instead of me doing the backports from other stable trees?)
>
> Wait, there's a 34-lt too?

There is also a 32-lt.

>
> I'd like to have all stable kvms pass some minimum acceptance test, but
> that's quiet a lot of trees to maintain.  Why do we have to have both 34-lt
> and 35-lt?

Well, ideally we'd all be aligned on one release, but that requires that it be
chosen somewhat in advance and communicated well, so that people have
time to align to it.  Without getting into details, different people had already
based projects and products off of 34, many months ago, at a point where
35 was not yet even being considered for extended maintenance.

Or you can go with Greg's shorter justification.  It is harder to
argue against. :)

P.

>
> --
> error compiling committee.c: too many arguments to function
>
> --
> 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/
>
--
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/