Ubuntu-lts-3.8.0 kernels corrupt ext[234] filesystems with 1k block size in Xen guests

[James Dingwall]

We observed a problem with a Postfix database file created by postmap becoming corrupted in a Xen guest when the file was on an ext4 filesystem with a 1kb block size. This was reported to the linux-ext4 list in http://marc.info/?t=138018028300003&r=1&w=2. The subsequent investigation identified the git commit 7b2b160da7661bb2ade3f924b1bd3e3084e53341 as solving the problem. We have applied this on top of tag Ubuntu-lts-3.8.0-13.22 and confirmed that it resolves the problem we are seeing.
---
AlsaDevices:
 total 0
 crw-rw---T 1 root audio 116, 1 Oct 4 19:28 seq
 crw-rw---T 1 root audio 116, 33 Oct 4 19:28 timer
AplayDevices: Error: [Errno 2] No such file or directory
ApportVersion: 2.9.2-0ubuntu8.3
Architecture: amd64
ArecordDevices: Error: [Errno 2] No such file or directory
AudioDevicesInUse: Error: command ['fuser', '-v', '/dev/snd/seq', '/dev/snd/timer'] failed with exit code 1:
CRDA: Error: [Errno 2] No such file or directory
DistroRelease: Ubuntu 13.04
HibernationDevice: RESUME=UUID=1d79e306-bed4-4cd4-8dbc-24a727ef8db6
IwConfig: Error: [Errno 2] No such file or directory
Lspci:

Lsusb: Error: command ['lsusb'] failed with exit code 1: unable to initialize libusb: -99
MarkForUpload: True
Package: linux (not installed)
PciMultimedia:

ProcEnviron:
 LANGUAGE=en_GB:en
 TERM=screen
 PATH=(custom, no user)
 LANG=en_GB.UTF-8
 SHELL=/bin/bash
ProcFB: 0 xen
ProcKernelCmdLine: root=/dev/mapper/ejbca0_systemvg-rootlv ro rootflags=subvol=@ splash quiet tmem $vt_handoff
ProcVersionSignature: Ubuntu 3.8.0-31.46-generic 3.8.13.8
RelatedPackageVersions:
 linux-restricted-modules-3.8.0-31-generic N/A
 linux-backports-modules-3.8.0-31-generic N/A
 linux-firmware 1.106
RfKill: Error: [Errno 2] No such file or directory
Tags: raring
Uname: Linux 3.8.0-31-generic x86_64
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups:

[Brad Figg (brad-figg)]

This bug is missing log files that will aid in diagnosing the problem. From a terminal window please run:

apport-collect 1234662

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

[James Dingwall (a-james-launchpad)]

apport information

[James Dingwall (a-james-launchpad)]

apport information

[James Dingwall (a-james-launchpad)]

apport information

[James Dingwall (a-james-launchpad)]

apport information

[James Dingwall (a-james-launchpad)]

apport information

[James Dingwall (a-james-launchpad)]

apport information

[James Dingwall (a-james-launchpad)]

apport information

[James Dingwall (a-james-launchpad)]

apport information

[James Dingwall (a-james-launchpad)]

apport information

[James Dingwall (a-james-launchpad)]

I can't install apport on the original system where this problem was observed (Precise + LTS kernel) but I have reproduced it on a Raring install with 3.8.0-31-generic and submitted the apport information from that environment.

[Joseph Salisbury (jsalisbury)]

Did you perform a backport of commit 7b2b160da7661bb2ade3f924b1bd3e3084e53341 ( Upstream commit: b7649158a0d241f8d53d13ff7441858539e16656)?

It seems upstream commit b764915 was cc'd to stable, but was dropped from all but the 3.10 stable tree due to the complexity of the backport.

[James Dingwall (a-james-launchpad)]

The commit 7b2b160da7661bb2ade3f924b1bd3e3084e53341 cherry-picked cleanly on top of the 3.8 LTS tree. I assumed it didn't make the official 3.8 stable branch because it was EOL by the time it was proposed for stable. Since we don't see the problem when we are on the 3.5 LTS kernel we didn't try to merge it to this branch.

[Joseph Salisbury (jsalisbury)]

Do you recall what specific version of 3.8 you used? The current version, 3.8.0-32 does not allow a clean cherry-pick. It was dropped from upstream stable 3.8 because of all the changes required to back port it.

One other note, the 3.8 kernel is not an LTS release. The 3.2 kernel is the last LTS release, which ships with 12.04(Precise).

[James Dingwall (a-james-launchpad)]

We make our kernel tree with:

git clone -n git://kernel.ubuntu.com/ubuntu/ubuntu-precise.git
cd ubuntu-precise
git remote add linux-stable git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
git fetch linux-stable
git checkout -b our-build Ubuntu-lts-3.8.0-13.22
git cherry-pick 7b2b160da7661bb2ade3f924b1bd3e3084e53341

I assume the LTS is in the tag because it is the tag for the 3.8.0 kernel available in Precise. I also preped a tree with the Ubuntu-lts-3.8.0-32.47 tag and that accepted the cherry-pick cleanly too.

[Joseph Salisbury (jsalisbury)]

Ok, I see now. Commit 7b2b160da7661bb2ade3f924b1bd3e3084e53341 in the stable tree was backported from b7649158a0d241f8d53d13ff7441858539e16656.

I'll see if this backport will cherry-pick cleanly into upstream 3.8.

[Joseph Salisbury (jsalisbury)]

Fixed in raring by commit:

commit 3901878b563fbdcbb21ac63cfd096b8d1df0b08b
Author: Roger Pau Monne <email address hidden>
Date: Thu May 2 10:58:50 2013 +0200

    xen-blkfront: use a different scatterlist for each request