lts-backport-vivid and lts-backport-wily branches broken in ubuntu-trusty repo?

[Andy Whitcroft]

On Fri, Nov 20, 2015 at 02:28:52PM -0500, Brian Daniels wrote:
> TL;DR the branches mentioned in the subject contain changes to the
> debian.<release> directories but seem to be missing the kernel.org patches
> mentioned in the changelog.
> 
> Hi,
> 
> I've been tracking the Ubuntu 14.04 LTS kernel at git://
> kernel.ubuntu.com/ubuntu/ubuntu-trusty.git without problems since its
> release. I now need support for devices introduced in 3.17 kernels and
> later. Instead of moving the whole project to a new release like 15.04 or
> 15.10 to pick up the kernel support needed I was intending to use the
> trusty lts-backport kernels to accomplish my goal. I ported my patches to
> the lts-backport-vivid and lts-backport-wily branches of the ubuntu-trusty
> repository. In doing so I noticed that there were changes pushed to the
> debian.vivid and debian.wily directories but the kernel.org patches
> mentioned in the changelog seem to be missing. To verify the content wasn't
> what was released I compared the output of the source package (ie. apt-get
> source linux-image-4.2.0-18-generic) with the git branch content and they
> are quite different.

It is helpful when reporting such things to report the exact versions
you are referring to to ensure we are checking the right ones.  Also it
would be helpful to know a specific fix you think is missing.

> Am I looking in the wrong place for the released kernel source for the
> backported kernels?

The lts-backport-<series> branches and specifically their associated
Ubuntu-lts-<version> tags should be the _exact_ tip from which the
source package was built for upload.

To test this I picked the linux-lts-wily_4.2.0-18.22~14.04.1 for
comparison.  Because I am on xenial I downloaded the source package
using pull-lp-source as below:

    pull-lp-source linux-lts-wily 4.2.0-18.22~14.04.1

I then checked out the matching tag from the ubuntu-trusty git
repository:

    git checkout -b lts Ubuntu-lts-4.2.0-18.22_14.04.1

I then compared the resulting directories and they are indeed identicle
if we ignore the files which are generated at clean time.  So the source
and git repository branches seem to match.

> Are the branches indeed missing the backported patches?

Looking at the changelog in the package now, I picked a couple of fixes,
the one from that specific upload and one from an older one:

 linux-lts-wily (4.2.0-18.22~14.04.1) trusty; urgency=low

  [ Upstream Kernel Changes ]

  * KVM: x86: vmx: avoid guest->host DOS by intercepting #AC
    - LP: #1513540
    - CVE-2015-5307
 [...]
 linux (4.2.0-17.20) wily; urgency=low
 [...]
  [ Upstream Kernel Changes ]

  * HID: lenovo: Use constants for axes names
    - LP: #1508178
 [...]

Looking at the git log I find both of these:

  commit 5b9be8d31bb4ec13ce0c0808ee4201d7786f6698
  Author: Eric Northup <digitaleric at google.com>
  Date:   Thu Sep 10 11:36:28 2015 -0700

    KVM: x86: vmx: avoid guest->host DOS by intercepting #AC

and:

  commit e77552f5724c3155b50da3e7ceaa06d126ca3b41
  Author: Jamie Lentin <jm at lentin.co.uk>
  Date:   Wed Oct 21 11:36:54 2015 -0400

    HID: lenovo: Use constants for axes names

Taking the first one, its most distinctive feature is that it introduces
a new function, ac_interception():

  static int ac_interception(struct vcpu_svm *svm)
  +{
  +       kvm_queue_exception_e(&svm->vcpu, AC_VECTOR, 0);
  +       return 1;
  +}

Looking at the source extracted from the upload source package, we can
see that change is present:

  $ rgrep ac_interception
  arch/x86/kvm/svm.c:static int ac_interception(struct vcpu_svm *svm)

Taking the second one we see that it switches out a constant:

  -             hid_map_usage(hi, usage, bit, max, EV_REL, 0x06);
  +             hid_map_usage(hi, usage, bit, max, EV_REL, REL_HWHEEL);

Again looking at the affected lines in the source package we see these
changes reflected:

  case 0x0000:
	  hid_map_usage(hi, usage, bit, max, EV_REL, REL_HWHEEL);

So spot checking those two utterly at random I find the changes applied.

Could you be more specific as to a change you have confirmed is missing,
and include a transcript of how you are determining it.

Thanks.

-apw