SRU fix for LP#1807628

Debdiff attached

The attachment "Debdiff" seems to be a debdiff. The ubuntu-sponsors team has been subscribed to the bug report so that they can review and hopefully sponsor the debdiff. If the attachment isn't a patch, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are member of the ~ubuntu-sponsors, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issue please contact him.]

Thanks for the debdiff, Kellen.

I'm assuming you need sponsorship for it, right?

A few more things I think are worth mentioning.

I believe the SRU template could be expanded and improved, especially the Test Plan section. For those who don't know how to setup lxc containers, it'd be great to have a step-by-step procedure outlined. This is what I always do with my SRU templates, and it really pays off when the SRU team member who will review the upload needs more info.

I tried to reproduce the bug locally but failed. Maybe I'm doing something wrong. I set up lxc using https://ubuntu.com/server/docs/containers-lxc as a guide, then started the container and sent a SIGHUP to the lxcfs process. It does fail, but I don't see a segfault:

Jun 08 22:41:26 lxcfs-test systemd[1]: Started FUSE filesystem for LXC.
Jun 08 22:41:26 lxcfs-test lxcfs[487]: mount namespace: 5
Jun 08 22:41:26 lxcfs-test lxcfs[487]: hierarchies:
Jun 08 22:41:26 lxcfs-test lxcfs[487]: 0: fd: 6: hugetlb
Jun 08 22:41:26 lxcfs-test lxcfs[487]: 1: fd: 7: perf_event
Jun 08 22:41:26 lxcfs-test lxcfs[487]: 2: fd: 8: net_cls,net_prio
Jun 08 22:41:26 lxcfs-test lxcfs[487]: 3: fd: 9: devices
Jun 08 22:41:26 lxcfs-test lxcfs[487]: 4: fd: 10: rdma
Jun 08 22:41:26 lxcfs-test lxcfs[487]: 5: fd: 11: blkio
Jun 08 22:41:26 lxcfs-test lxcfs[487]: 6: fd: 12: freezer
Jun 08 22:41:26 lxcfs-test lxcfs[487]: 7: fd: 13: cpu,cpuacct
Jun 08 22:41:26 lxcfs-test lxcfs[487]: 8: fd: 14: memory
Jun 08 22:41:26 lxcfs-test lxcfs[487]: 9: fd: 15: cpuset
Jun 08 22:41:26 lxcfs-test lxcfs[487]: 10: fd: 16: pids
Jun 08 22:41:26 lxcfs-test lxcfs[487]: 11: fd: 17: name=systemd
Jun 08 22:41:26 lxcfs-test lxcfs[487]: 12: fd: 18: unified
Jun 08 22:42:02 lxcfs-test fusermount[904]: /bin/fusermount: failed to unmount /var/lib/lxcfs: Invalid argument

Could you tell me how to reproduce this issue, please?

Thanks.

Ah, something I didn't mention: I'm trying this using a Bionic VM.

Hi Sergio,

Yes, I will need sponsorship. Apologies for the test plan stub, I will make it more robust.

Unfortunately, the issue is difficult to reproduce, since it needs some combination of a HUP (or the signal logrotate is sending) and running containers with changes to the cgroups.

I am working on that, and will update the test plan accordingly.

Updated debdiff, incorporating suggested changes.

I haven't had any luck reproducing the issue. It appears to be a race between the enumeration in lxcfs and the teardown of a cgroup hierarchy.

Was able to successfully reproduce the issue on 3.0.3-0ubuntu1~18.04.2. Updated the Test Plan with the reproduction commands to verify that the issue is fixed.

(gdb) bt full
#0 0x00007f162ca854ea in cg_readdir (path=<optimized out>, buf=0x7f1628004740, filler=0x7f162d4b1d00, offset=<optimized out>,
    fi=<optimized out>) at bindings.c:1800
        d = 0x7f1618001760
        list = 0x0
        i = 0
        ret = <optimized out>
        nextcg = 0x0
        fc = <optimized out>
        clist = 0x0
        __func__ = "cg_readdir"
        initpid = <optimized out>
#1 0x000055a4a90425c3 in ?? ()
No symbol table info available.
#2 0x00007f162d4b7292 in ?? ()
No symbol table info available.
#3 0x00007f1626ffcc00 in ?? ()
No symbol table info available.
#4 0x9cce25ca93392700 in ?? ()
No symbol table info available.
#5 0x00007f161c00a010 in ?? ()
No symbol table info available.
#6 0x9cce25ca93392700 in ?? ()
No symbol table info available.
#7 0x0000000000000000 in ?? ()
No symbol table info available.

[Reproduction]

 * Install lxcfs on an Ubuntu Bionic machine. "sudo apt install lxcfs"
 * Open 3 terminals to the machine, each with a root prompt.
 * Prepare a mount directory in terminal 1:
   mkdir /mnt/lxcfs
 * In terminal 1, execute:
   while true ; do mkdir /sys/fs/cgroup/systemd/test ; rmdir /sys/fs/cgroup/systemd/test ; done
 * In terminal 2, execute:
   lxcfs -p /tmp/lxcfs.pid /mnt/lxcfs
 * In terminal 3, execute:
   while true; do ls /mnt/lxcfs/cgroup/name\=systemd/test > /dev/null ;done
 * Segfault should occur within 1 minute.

[Testing of fix]
 Using package from PPA:
 https://launchpad.net/~krenshaw/+archive/ubuntu/lp1977870-lxcfs

 Created using debdiff from this bug and uploading the .changes file after debuild -S.

 The issue did not recur in several minutes of testing, the unpatched version fails within seconds.

Thanks, Kellen.

I wasn't able to reproduce the issue even when following the new Test Plan. I wonder if it's because I'm running things inside a Bionic VM, but I'd be surprised if that's the real problem.

Either way, I have checked the debdiff again and I'm happy with the changes. I'll let you drive the SRU and reply to any questions the SRU team might have.

Uploaded:

$ dput lxcfs_3.0.3-0ubuntu1~18.04.3_source.changes
Trying to upload package to ubuntu
Checking signature on .changes
gpg: /home/sergio/work/lxcfs/sru-kellen/lxcfs_3.0.3-0ubuntu1~18.04.3_source.changes: Valid signature from 106DA1C8C3CBBF14
Checking signature on .dsc
gpg: /home/sergio/work/lxcfs/sru-kellen/lxcfs_3.0.3-0ubuntu1~18.04.3.dsc: Valid signature from 106DA1C8C3CBBF14
Uploading to ubuntu (via ftp to upload.ubuntu.com):
  Uploading lxcfs_3.0.3-0ubuntu1~18.04.3.dsc: done.
  Uploading lxcfs_3.0.3-0ubuntu1~18.04.3.debian.tar.xz: done.
  Uploading lxcfs_3.0.3-0ubuntu1~18.04.3_source.buildinfo: done.
  Uploading lxcfs_3.0.3-0ubuntu1~18.04.3_source.changes: done.
Successfully uploaded packages.

Why is this a separate bug instead of a Bionic task on bug 1807628? Is there something I'm missing?

It may have just been a misinterpretation of the Sponsorship guidelines. If you want, feel free to reject the upload and I will ask Kellen to create another task on that bug and adjust the d/changelog entry accordingly.

Sorry about that, I wasn't familiar with the "Target Series" button and was reluctant to alter a Fix Committed bug.

If this should be more properly addressed in bug 1807628, I am happy to move it there.

OK. Yes, please could you adjust it? I'm not sure the SRU tooling will work if I just mark this as a dupe, so it's probably easier to resolve this now rather than deal with the confusion it might cause later.

OK, I will update bug 1807628 with the series info and move the template there.

Also, @Sergio, my testing was also in a VM, so I am surprised that it didn't reproduce.

Robie, I'll wait for you to reject the current upload before I upload the new version.

Kellen, yeah, I found it strange that I couldn't reproduce the issue. I'm at a conference right now so don't have too much time to investigate; maybe with a bit more perseverance I'd be able to succeed.

Hell Robie and Sergio,

Is there anything I need to do to get the upload rejected and the one in bug 1807628 moving forward?

I've rejected this for you now. But for the future please note that waiting for a rejection is not required. You can just upload over the top, and this saves one round trip.

I've uploaded the package, so I'm closing this bug as Invalid. Let's continue the discussion on bug #1807628.