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: <4D074D87.4010208@redhat.com>
Date:	Tue, 14 Dec 2010 12:57:11 +0200
From:	Avi Kivity <avi@...hat.com>
To:	Paul Gortmaker <paul.gortmaker@...driver.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 12/13/2010 07:36 PM, Paul Gortmaker wrote:
> >>  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.

Luckily no 33-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.

Something's got to give.  Either you burden the subsystem maintainers 
with maintaining lots of longterm kernels, or you cherry pick the 
patches yourself, and risk regressions in a stable series.  I don't 
think this is viable.

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

I think Greg's confusing cause and effect.

-- 
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/