[Kernel-packages] [Bug 1767443] Re: regular hard lockup on bionic kernel

2018-04-27 Thread Tycho Andersen
Here's /var/log/kern.log, just for grins.

** Attachment added: "kern.log"
   
https://bugs.launchpad.net/ubuntu/+source/linux-signed/+bug/1767443/+attachment/5128706/+files/kern.log

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux-signed in Ubuntu.
https://bugs.launchpad.net/bugs/1767443

Title:
  regular hard lockup on bionic kernel

Status in linux-signed package in Ubuntu:
  New

Bug description:
  Hi guys,

  I'm sorry I have no real information to add to this, but Serge
  encouraged me to file a bug to get you guys to help me to debug this,
  so blame him.

  I've been running the bionic kernels on a thinkpad X1 carbon 3rd
  generation for several months, and experiencing 2x hard lockups per
  day. Nothing in /var/log/kern.log looks very obvious to me, and I'm
  not lucky enough to get a stack trace or anything.

  Attached are the `ubuntu-bug linux` things that are uploaded
  automatically, but I'm happy to do whatever science experiments are
  necessary to get further info.

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: linux-image-4.15.0-20-generic 4.15.0-20.21
  ProcVersionSignature: Ubuntu 4.15.0-20.21-generic 4.15.17
  Uname: Linux 4.15.0-20-generic x86_64
  ApportVersion: 2.20.9-0ubuntu7
  Architecture: amd64
  Date: Fri Apr 27 10:45:49 2018
  InstallationDate: Installed on 2017-11-13 (164 days ago)
  InstallationMedia: Ubuntu 17.10 "Artful Aardvark" - Release amd64 (20171018)
  SourcePackage: linux-signed
  UpgradeStatus: Upgraded to bionic on 2018-03-09 (48 days ago)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux-signed/+bug/1767443/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp


[Kernel-packages] [Bug 1767443] [NEW] regular hard lockup on bionic kernel

2018-04-27 Thread Tycho Andersen
Public bug reported:

Hi guys,

I'm sorry I have no real information to add to this, but Serge
encouraged me to file a bug to get you guys to help me to debug this, so
blame him.

I've been running the bionic kernels on a thinkpad X1 carbon 3rd
generation for several months, and experiencing 2x hard lockups per day.
Nothing in /var/log/kern.log looks very obvious to me, and I'm not lucky
enough to get a stack trace or anything.

Attached are the `ubuntu-bug linux` things that are uploaded
automatically, but I'm happy to do whatever science experiments are
necessary to get further info.

ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: linux-image-4.15.0-20-generic 4.15.0-20.21
ProcVersionSignature: Ubuntu 4.15.0-20.21-generic 4.15.17
Uname: Linux 4.15.0-20-generic x86_64
ApportVersion: 2.20.9-0ubuntu7
Architecture: amd64
Date: Fri Apr 27 10:45:49 2018
InstallationDate: Installed on 2017-11-13 (164 days ago)
InstallationMedia: Ubuntu 17.10 "Artful Aardvark" - Release amd64 (20171018)
SourcePackage: linux-signed
UpgradeStatus: Upgraded to bionic on 2018-03-09 (48 days ago)

** Affects: linux-signed (Ubuntu)
 Importance: Undecided
 Status: New


** Tags: amd64 apport-bug bionic

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux-signed in Ubuntu.
https://bugs.launchpad.net/bugs/1767443

Title:
  regular hard lockup on bionic kernel

Status in linux-signed package in Ubuntu:
  New

Bug description:
  Hi guys,

  I'm sorry I have no real information to add to this, but Serge
  encouraged me to file a bug to get you guys to help me to debug this,
  so blame him.

  I've been running the bionic kernels on a thinkpad X1 carbon 3rd
  generation for several months, and experiencing 2x hard lockups per
  day. Nothing in /var/log/kern.log looks very obvious to me, and I'm
  not lucky enough to get a stack trace or anything.

  Attached are the `ubuntu-bug linux` things that are uploaded
  automatically, but I'm happy to do whatever science experiments are
  necessary to get further info.

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: linux-image-4.15.0-20-generic 4.15.0-20.21
  ProcVersionSignature: Ubuntu 4.15.0-20.21-generic 4.15.17
  Uname: Linux 4.15.0-20-generic x86_64
  ApportVersion: 2.20.9-0ubuntu7
  Architecture: amd64
  Date: Fri Apr 27 10:45:49 2018
  InstallationDate: Installed on 2017-11-13 (164 days ago)
  InstallationMedia: Ubuntu 17.10 "Artful Aardvark" - Release amd64 (20171018)
  SourcePackage: linux-signed
  UpgradeStatus: Upgraded to bionic on 2018-03-09 (48 days ago)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux-signed/+bug/1767443/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp


[Kernel-packages] [Bug 1638996] [NEW] apparmor's raw_data file in securityfs is sometimes truncated

2016-11-03 Thread Tycho Andersen
Public bug reported:

Hi,

It looks like sometimes apparmor's securityfs output is sometimes
truncated,

root@zesty:/sys/kernel/security/apparmor/policy/namespaces/lxd-zest_/profiles/usr.lib.snapd.snap-confine.1#
 ls -al
total 0
drwxr-xr-x  3 root root 0 Nov  3 16:45 .
drwxr-xr-x 13 root root 0 Nov  3 16:44 ..
-r--r--r--  1 root root 0 Nov  3 16:45 attach
-r--r--r--  1 root root 0 Nov  3 16:45 mode
-r--r--r--  1 root root 0 Nov  3 16:45 name
drwxr-xr-x  3 root root 0 Nov  3 16:45 profiles
-r--r--r--  1 root root 0 Nov  3 16:45 raw_abi
-r--r--r--  1 root root 46234 Nov  3 16:45 raw_data
-r--r--r--  1 root root 0 Nov  3 16:45 raw_hash
-r--r--r--  1 root root 0 Nov  3 16:45 sha1
root@zesty:/sys/kernel/security/apparmor/policy/namespaces/lxd-zest_/profiles/usr.lib.snapd.snap-confine.1#
 cat raw_data > /tmp/out
root@zesty:/sys/kernel/security/apparmor/policy/namespaces/lxd-zest_/profiles/usr.lib.snapd.snap-confine.1#
 ls -al /tmp/out 
-rw-r--r-- 1 root root 4009 Nov  3 16:55 /tmp/out

and

2016-11-03 10:58:01 tych0 jjohansen: hi, http://paste.ubuntu.com/23421551/
2016-11-03 10:58:18 tych0 it looks like fstat is lying to me about the size of 
the policy
2016-11-03 10:59:20 @jjohansen  tych0: hrmm interesting, can you zip up the 
/tmp/out file so I can see it looks like a complete policy file?
2016-11-03 11:00:03 @jjohansen  something is definitely not right there. hrmmm
2016-11-03 11:00:26 @jjohansen  the size is set by the input buffer size
2016-11-03 11:00:28 tych0 jjohansen: http://files.tycho.ws/tmp/out
2016-11-03 11:00:36 tych0 yeah, i assume
2016-11-03 11:01:15 @jjohansen  my guess is something is messing up in the 
seq_file walk of the policy
2016-11-03 11:02:38 @jjohansen  tych0: yep the file is truncated, can you open 
a bug and I will start looking for it
2016-11-03 11:03:14 tych0 jjohansen: sure, just on linux?
2016-11-03 11:03:35 @jjohansen  tych0: yeah for now, just linux
2016-11-03 11:03:43 @jjohansen  we can add others if needed later
2016-11-03 11:03:44 tych0 jjohansen: FWIW, somehow it seems racy, becasue 
sometimes it works and sometimes it doesn't

** Affects: linux (Ubuntu)
 Importance: Undecided
 Status: New

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1638996

Title:
  apparmor's raw_data file in securityfs is sometimes truncated

Status in linux package in Ubuntu:
  New

Bug description:
  Hi,

  It looks like sometimes apparmor's securityfs output is sometimes
  truncated,

  
root@zesty:/sys/kernel/security/apparmor/policy/namespaces/lxd-zest_/profiles/usr.lib.snapd.snap-confine.1#
 ls -al
  total 0
  drwxr-xr-x  3 root root 0 Nov  3 16:45 .
  drwxr-xr-x 13 root root 0 Nov  3 16:44 ..
  -r--r--r--  1 root root 0 Nov  3 16:45 attach
  -r--r--r--  1 root root 0 Nov  3 16:45 mode
  -r--r--r--  1 root root 0 Nov  3 16:45 name
  drwxr-xr-x  3 root root 0 Nov  3 16:45 profiles
  -r--r--r--  1 root root 0 Nov  3 16:45 raw_abi
  -r--r--r--  1 root root 46234 Nov  3 16:45 raw_data
  -r--r--r--  1 root root 0 Nov  3 16:45 raw_hash
  -r--r--r--  1 root root 0 Nov  3 16:45 sha1
  
root@zesty:/sys/kernel/security/apparmor/policy/namespaces/lxd-zest_/profiles/usr.lib.snapd.snap-confine.1#
 cat raw_data > /tmp/out
  
root@zesty:/sys/kernel/security/apparmor/policy/namespaces/lxd-zest_/profiles/usr.lib.snapd.snap-confine.1#
 ls -al /tmp/out 
  -rw-r--r-- 1 root root 4009 Nov  3 16:55 /tmp/out

  and

  2016-11-03 10:58:01 tych0 jjohansen: hi, http://paste.ubuntu.com/23421551/
  2016-11-03 10:58:18 tych0 it looks like fstat is lying to me about the size 
of the policy
  2016-11-03 10:59:20 @jjohansen  tych0: hrmm interesting, can you zip up the 
/tmp/out file so I can see it looks like a complete policy file?
  2016-11-03 11:00:03 @jjohansen  something is definitely not right there. hrmmm
  2016-11-03 11:00:26 @jjohansen  the size is set by the input buffer size
  2016-11-03 11:00:28 tych0 jjohansen: http://files.tycho.ws/tmp/out
  2016-11-03 11:00:36 tych0 yeah, i assume
  2016-11-03 11:01:15 @jjohansen  my guess is something is messing up in the 
seq_file walk of the policy
  2016-11-03 11:02:38 @jjohansen  tych0: yep the file is truncated, can you 
open a bug and I will start looking for it
  2016-11-03 11:03:14 tych0 jjohansen: sure, just on linux?
  2016-11-03 11:03:35 @jjohansen  tych0: yeah for now, just linux
  2016-11-03 11:03:43 @jjohansen  we can add others if needed later
  2016-11-03 11:03:44 tych0 jjohansen: FWIW, somehow it seems racy, becasue 
sometimes it works and sometimes it doesn't

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1638996/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.laun

[Kernel-packages] [Bug 1590069] Re: vDSO syscalls don't work on yakkety/master-next (and unstable/master)

2016-07-19 Thread Tycho Andersen
I just tested this on:

Linux vdso-test 4.6.0-9-generic #11-Ubuntu SMP Wed Jul 13 22:17:41 UTC
2016 x86_64 x86_64 x86_64 GNU/Linux

and it seems to be fixed, so I'll close this for now.

** Changed in: linux (Ubuntu Yakkety)
   Status: Triaged => Invalid

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1590069

Title:
  vDSO syscalls don't work on yakkety/master-next (and unstable/master)

Status in linux package in Ubuntu:
  Invalid
Status in linux source package in Yakkety:
  Invalid

Bug description:
  Hi guys,

  I'm having a problem where vDSO syscalls don't work on yakkety-next:

  dev:~ uname -a
  Linux dev 4.6.0-8-generic #9 SMP Mon Jun 6 14:21:30 MDT 2016 x86_64 x86_64 
x86_64 GNU/Linux
  dev:~ cat tester.c 
  #include 
  #include 
  #include 

  int main()
  {
struct timeval tv;
struct timezone tz;

while (1) {
sleep(1);
if (gettimeofday(&tv, &tz) < 0) {
perror("gettimeofday");
}
}

return 0;
  }
  dev:~ make tester
  make: 'tester' is up to date.
  dev:~ strace tester
  strace: Can't stat 'tester': No such file or directory
  dev:~ 1 strace ./tester
  execve("./tester", ["./tester"], [/* 35 vars */]) = 0
  brk(NULL)   = 0x19e4000
  access("/etc/ld.so.nohwcap", F_OK)  = -1 ENOENT (No such file or 
directory)
  mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0x7fbca234b000
  access("/etc/ld.so.preload", R_OK)  = -1 ENOENT (No such file or 
directory)
  open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
  fstat(3, {st_mode=S_IFREG|0644, st_size=44113, ...}) = 0
  mmap(NULL, 44113, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7fbca234
  close(3)= 0
  access("/etc/ld.so.nohwcap", F_OK)  = -1 ENOENT (No such file or 
directory)
  open("/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
  read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0P\t\2\0\0\0\0\0"..., 
832) = 832
  fstat(3, {st_mode=S_IFREG|0755, st_size=1864888, ...}) = 0
  mmap(NULL, 3967488, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 
0x7fbca1d5f000
  mprotect(0x7fbca1f1f000, 2093056, PROT_NONE) = 0
  mmap(0x7fbca211e000, 24576, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1bf000) = 0x7fbca211e000
  mmap(0x7fbca2124000, 14848, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7fbca2124000
  close(3)= 0
  mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0x7fbca233f000
  mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0x7fbca233e000
  mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0x7fbca233d000
  arch_prctl(ARCH_SET_FS, 0x7fbca233e700) = 0
  mprotect(0x7fbca211e000, 16384, PROT_READ) = 0
  mprotect(0x60, 4096, PROT_READ) = 0
  mprotect(0x7fbca234d000, 4096, PROT_READ) = 0
  munmap(0x7fbca234, 44113)   = 0
  nanosleep({1, 0}, 0x7fffc8ec71f0)   = 0
  gettimeofday({1465317034, 813437}, {tz_minuteswest=0, tz_dsttime=0}) = 0
  nanosleep({1, 0}, 0x7fffc8ec71f0)   = 0
  gettimeofday({1465317035, 813718}, {tz_minuteswest=0, tz_dsttime=0}) = 0
  nanosleep({1, 0}, 0x7fffc8ec71f0)   = 0
  gettimeofday({1465317036, 814008}, {tz_minuteswest=0, tz_dsttime=0}) = 0
  nanosleep({1, 0}, ^Cstrace: Process 15793 detached
   

  whereas on a normal machine, they do:

  ~ uname -a
  Linux hopstrocity 4.4.0-22-generic #40-Ubuntu SMP Thu May 12 22:03:46 UTC 
2016 x86_64 x86_64 x86_64 GNU/Linux
  ~ cat tester.c 
  #include 
  #include 
  #include 

  int main()
  {
struct timeval tv;
struct timezone tz;

while (1) {
sleep(1);
if (gettimeofday(&tv, &tz) < 0) {
perror("gettimeofday");
}
}

return 0;
  }

  ~ make tester
  make: 'tester' is up to date.
  ~ strace ./tester
  execve("./tester", ["./tester"], [/* 60 vars */]) = 0
  brk(NULL)   = 0x12c7000
  access("/etc/ld.so.nohwcap", F_OK)  = -1 ENOENT (No such file or 
directory)
  mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0x7fb544a9b000
  access("/etc/ld.so.preload", R_OK)  = -1 ENOENT (No such file or 
directory)
  open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
  fstat(3, {st_mode=S_IFREG|0644, st_size=143083, ...}) = 0
  mmap(NULL, 143083, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7fb544a78000
  close(3)= 0
  access("/etc/ld.so.nohwcap", F_OK)  = -1 ENOENT (No such file or 
directory)
  open("/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
  read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0P\t\2\0\0\0\0\0"..., 
832) = 832
  fstat(3, {st_mode=S_IFREG|0755, st_size=1864888, ...

[Kernel-packages] [Bug 1598285] [NEW] possible deadlock while using the cgroup freezer on a container with NFS-based workload

2016-07-01 Thread Tycho Andersen
Public bug reported:

Hi guys,

For background: I'm running a container with an NFS filesystem bind
mounted into it. The workload I'm running is iozone, a filesystem
benchmarking tool. While running this workload, I attempt to freeze the
container, which gets stuck in the FREEZING state. After a while, I get:

Jul  1 01:45:14 juju-19f8e3-15 kernel: [206520.104156] INFO: task iozone:20035 
blocked for more than 120 seconds.
Jul  1 01:45:14 juju-19f8e3-15 kernel: [206520.111056]   Tainted: P 
  O4.4.0-24-generic #43-Ubuntu
Jul  1 01:45:14 juju-19f8e3-15 kernel: [206520.118053] "echo 0 > 
/proc/sys/kernel/hung_task_timeout_secs" disables this message.
Jul  1 01:45:14 juju-19f8e3-15 kernel: [206520.126110] iozone  D 
880015673e18 0 20035  20005 0x0104
Jul  1 01:45:14 juju-19f8e3-15 kernel: [206520.126116]  880015673e18 
8810 880045a21b80 880037776e00
Jul  1 01:45:14 juju-19f8e3-15 kernel: [206520.126118]  880015674000 
8800179d6e54 880037776e00 
Jul  1 01:45:14 juju-19f8e3-15 kernel: [206520.126120]  8800179d6e58 
880015673e30 81821b15 8800179d6e50
Jul  1 01:45:14 juju-19f8e3-15 kernel: [206520.126121] Call Trace:
Jul  1 01:45:14 juju-19f8e3-15 kernel: [206520.126129]  [] 
schedule+0x35/0x80
Jul  1 01:45:14 juju-19f8e3-15 kernel: [206520.126131]  [] 
schedule_preempt_disabled+0xe/0x10
Jul  1 01:45:14 juju-19f8e3-15 kernel: [206520.126134]  [] 
__mutex_lock_slowpath+0xb9/0x130
Jul  1 01:45:14 juju-19f8e3-15 kernel: [206520.126136]  [] 
mutex_lock+0x1f/0x30
Jul  1 01:45:14 juju-19f8e3-15 kernel: [206520.126139]  [] 
do_unlinkat+0x12b/0x2d0
Jul  1 01:45:14 juju-19f8e3-15 kernel: [206520.126142]  [] 
SyS_unlink+0x16/0x20
Jul  1 01:45:14 juju-19f8e3-15 kernel: [206520.126146]  [] 
entry_SYSCALL_64_fastpath+0x16/0x71

It looks like the task is actually stuck in generic fs code, not
anything NFS specific, but perhaps that's a relevant detail. Anyway:

ubuntu@juju-19f8e3-15:~$ sudo cat /proc/20035/stack
[] do_unlinkat+0x12b/0x2d0
[] SyS_unlink+0x16/0x20
[] entry_SYSCALL_64_fastpath+0x16/0x71
[] 0x

The container and host are both xenial:

ubuntu@juju-19f8e3-15:~$ uname -a
Linux juju-19f8e3-15 4.4.0-24-generic #43-Ubuntu SMP Wed Jun 8 19:27:37 UTC 
2016 x86_64 x86_64 x86_64 GNU/Linux

Finally, I don't have a good reproducer for this. It's pretty rare, as
I'm running this benchmark in a loop, and over thousands of runs I've
seen this exactly once.

I'll leave these hosts up for a bit if there's any other interesting
bits of info to collect.

** Affects: linux (Ubuntu)
 Importance: Undecided
 Status: New

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1598285

Title:
  possible deadlock while using the cgroup freezer on a container with
  NFS-based workload

Status in linux package in Ubuntu:
  New

Bug description:
  Hi guys,

  For background: I'm running a container with an NFS filesystem bind
  mounted into it. The workload I'm running is iozone, a filesystem
  benchmarking tool. While running this workload, I attempt to freeze
  the container, which gets stuck in the FREEZING state. After a while,
  I get:

  Jul  1 01:45:14 juju-19f8e3-15 kernel: [206520.104156] INFO: task 
iozone:20035 blocked for more than 120 seconds.
  Jul  1 01:45:14 juju-19f8e3-15 kernel: [206520.111056]   Tainted: P   
O4.4.0-24-generic #43-Ubuntu
  Jul  1 01:45:14 juju-19f8e3-15 kernel: [206520.118053] "echo 0 > 
/proc/sys/kernel/hung_task_timeout_secs" disables this message.
  Jul  1 01:45:14 juju-19f8e3-15 kernel: [206520.126110] iozone  D 
880015673e18 0 20035  20005 0x0104
  Jul  1 01:45:14 juju-19f8e3-15 kernel: [206520.126116]  880015673e18 
8810 880045a21b80 880037776e00
  Jul  1 01:45:14 juju-19f8e3-15 kernel: [206520.126118]  880015674000 
8800179d6e54 880037776e00 
  Jul  1 01:45:14 juju-19f8e3-15 kernel: [206520.126120]  8800179d6e58 
880015673e30 81821b15 8800179d6e50
  Jul  1 01:45:14 juju-19f8e3-15 kernel: [206520.126121] Call Trace:
  Jul  1 01:45:14 juju-19f8e3-15 kernel: [206520.126129]  [] 
schedule+0x35/0x80
  Jul  1 01:45:14 juju-19f8e3-15 kernel: [206520.126131]  [] 
schedule_preempt_disabled+0xe/0x10
  Jul  1 01:45:14 juju-19f8e3-15 kernel: [206520.126134]  [] 
__mutex_lock_slowpath+0xb9/0x130
  Jul  1 01:45:14 juju-19f8e3-15 kernel: [206520.126136]  [] 
mutex_lock+0x1f/0x30
  Jul  1 01:45:14 juju-19f8e3-15 kernel: [206520.126139]  [] 
do_unlinkat+0x12b/0x2d0
  Jul  1 01:45:14 juju-19f8e3-15 kernel: [206520.126142]  [] 
SyS_unlink+0x16/0x20
  Jul  1 01:45:14 juju-19f8e3-15 kernel: [206520.126146]  [] 
entry_SYSCALL_64_fastpath+0x16/0x71

  It looks like the task is actually stuck in generic fs code, not
  anything NFS specific, but perhaps that's a relevant detail. Anyway:

[Kernel-packages] [Bug 1588056] Re: cgroupfs mounts can hang

2016-06-29 Thread Tycho Andersen
** Tags removed: verification-needed-xenial
** Tags added: verification-done-xenial

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1588056

Title:
  cgroupfs mounts can hang

Status in linux package in Ubuntu:
  Confirmed
Status in linux source package in Xenial:
  Fix Committed

Bug description:
  SRU Justification

  Impact: In some circumstances mount(2) of cgroup can endlessly return
  ERESTARTNOINTR, causing mount(8) to endlessly spin in loop.

  Fix: Drop sauce patches for making cgroupfs work with s_user_ns in
  favor of patches from linux-next which do not have this problem.

  Regression potential: The changes go beyond simply fixing the bug in
  order to sync up with upstream, but the upstream patches are by and
  large functionally equivalent. One consequence is that the bpf fs will
  no longer be mountable in a user namespace, but this fs is new in 4.4,
  unused as far as I can tell, and broken for user namespace mounts
  anyway.

  ---

  Consider the following,

  root@dev:/tmp# mkdir foo
  root@dev:/tmp# mount -t cgroup -o none,name=foo none foo
  root@dev:/tmp# mkdir -p foo/bad
  root@dev:/tmp# umount -l foo
  root@dev:/tmp# mount -t cgroup -o none,name=foo none foo # hangs forever
  ^C
  root@dev:/tmp# uname -a
  Linux dev 4.4.0-22-generic #40-Ubuntu SMP Thu May 12 22:03:46 UTC 2016 x86_64 
x86_64 x86_64 GNU/Linux

  When I strace the mount task, I get a whole bunch of,

  mount("none", "/tmp/foo", "cgroup", MS_MGC_VAL, "none,name=foo") = ? 
ERESTARTNOINTR (To be restarted)
  mount("none", "/tmp/foo", "cgroup", MS_MGC_VAL, "none,name=foo") = ? 
ERESTARTNOINTR (To be restarted)
  mount("none", "/tmp/foo", "cgroup", MS_MGC_VAL, "none,name=foo") = ? 
ERESTARTNOINTR (To be restarted)
  mount("none", "/tmp/foo", "cgroup", MS_MGC_VAL, "none,name=foo") = ? 
ERESTARTNOINTR (To be restarted)
  mount("none", "/tmp/foo", "cgroup", MS_MGC_VAL, "none,name=foo") = ? 
ERESTARTNOINTR (To be restarted)
  mount("none", "/tmp/foo", "cgroup", MS_MGC_VAL, "none,name=foo") = ? 
ERESTARTNOINTR (To be restarted)
  mount("none", "/tmp/foo", "cgroup", MS_MGC_VAL, "none,name=foo") = ? 
ERESTARTNOINTR (To be restarted)
  mount("none", "/tmp/foo", "cgroup", MS_MGC_VAL, "none,name=foo") = ? 
ERESTARTNOINTR (To be restarted)
  mount("none", "/tmp/foo", "cgroup", MS_MGC_VAL, "none,name=foo") = ? 
ERESTARTNOINTR (To be restarted)
  mount("none", "/tmp/foo", "cgroup", MS_MGC_VAL, "none,name=foo") = ? 
ERESTARTNOINTR (To be restarted)
  mount("none", "/tmp/foo", "cgroup", MS_MGC_VAL, "none,name=foo") = ? 
ERESTARTNOINTR (To be restarted)
  mount("none", "/tmp/foo", "cgroup", MS_MGC_VAL, "none,name=foo") = ? 
ERESTARTNOINTR (To be restarted)
  mount("none", "/tmp/foo", "cgroup", MS_MGC_VAL, "none,name=foo") = ? 
ERESTARTNOINTR (To be restarted)
  mount("none", "/tmp/foo", "cgroup", MS_MGC_VAL, "none,name=foo") = ? 
ERESTARTNOINTR (To be restarted)
  mount("none", "/tmp/foo", "cgroup", MS_MGC_VAL, "none,name=foo") = ? 
ERESTARTNOINTR (To be restarted)
  mount("none", "/tmp/foo", "cgroup", MS_MGC_VAL, "none,name=foo") = ? 
ERESTARTNOINTR (To be restarted)
  mount("none", "/tmp/foo", "cgroup", MS_MGC_VAL, "none,name=foo") = ? 
ERESTARTNOINTR (To be restarted)

  Which I think means that we're looping on,

  https://github.com/torvalds/linux/blob/master/kernel/cgroup.c#L2137

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1588056/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp


[Kernel-packages] [Bug 1588056] Re: cgroupfs mounts can hang

2016-06-24 Thread Tycho Andersen
+1, these kernels work for me in my original application too, thanks
Seth.

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1588056

Title:
  cgroupfs mounts can hang

Status in linux package in Ubuntu:
  Incomplete

Bug description:
  Consider the following,

  root@dev:/tmp# mkdir foo
  root@dev:/tmp# mount -t cgroup -o none,name=foo none foo
  root@dev:/tmp# mkdir -p foo/bad
  root@dev:/tmp# umount -l foo
  root@dev:/tmp# mount -t cgroup -o none,name=foo none foo # hangs forever
  ^C
  root@dev:/tmp# uname -a
  Linux dev 4.4.0-22-generic #40-Ubuntu SMP Thu May 12 22:03:46 UTC 2016 x86_64 
x86_64 x86_64 GNU/Linux

  When I strace the mount task, I get a whole bunch of,

  mount("none", "/tmp/foo", "cgroup", MS_MGC_VAL, "none,name=foo") = ? 
ERESTARTNOINTR (To be restarted)
  mount("none", "/tmp/foo", "cgroup", MS_MGC_VAL, "none,name=foo") = ? 
ERESTARTNOINTR (To be restarted)
  mount("none", "/tmp/foo", "cgroup", MS_MGC_VAL, "none,name=foo") = ? 
ERESTARTNOINTR (To be restarted)
  mount("none", "/tmp/foo", "cgroup", MS_MGC_VAL, "none,name=foo") = ? 
ERESTARTNOINTR (To be restarted)
  mount("none", "/tmp/foo", "cgroup", MS_MGC_VAL, "none,name=foo") = ? 
ERESTARTNOINTR (To be restarted)
  mount("none", "/tmp/foo", "cgroup", MS_MGC_VAL, "none,name=foo") = ? 
ERESTARTNOINTR (To be restarted)
  mount("none", "/tmp/foo", "cgroup", MS_MGC_VAL, "none,name=foo") = ? 
ERESTARTNOINTR (To be restarted)
  mount("none", "/tmp/foo", "cgroup", MS_MGC_VAL, "none,name=foo") = ? 
ERESTARTNOINTR (To be restarted)
  mount("none", "/tmp/foo", "cgroup", MS_MGC_VAL, "none,name=foo") = ? 
ERESTARTNOINTR (To be restarted)
  mount("none", "/tmp/foo", "cgroup", MS_MGC_VAL, "none,name=foo") = ? 
ERESTARTNOINTR (To be restarted)
  mount("none", "/tmp/foo", "cgroup", MS_MGC_VAL, "none,name=foo") = ? 
ERESTARTNOINTR (To be restarted)
  mount("none", "/tmp/foo", "cgroup", MS_MGC_VAL, "none,name=foo") = ? 
ERESTARTNOINTR (To be restarted)
  mount("none", "/tmp/foo", "cgroup", MS_MGC_VAL, "none,name=foo") = ? 
ERESTARTNOINTR (To be restarted)
  mount("none", "/tmp/foo", "cgroup", MS_MGC_VAL, "none,name=foo") = ? 
ERESTARTNOINTR (To be restarted)
  mount("none", "/tmp/foo", "cgroup", MS_MGC_VAL, "none,name=foo") = ? 
ERESTARTNOINTR (To be restarted)
  mount("none", "/tmp/foo", "cgroup", MS_MGC_VAL, "none,name=foo") = ? 
ERESTARTNOINTR (To be restarted)
  mount("none", "/tmp/foo", "cgroup", MS_MGC_VAL, "none,name=foo") = ? 
ERESTARTNOINTR (To be restarted)

  Which I think means that we're looping on,

  https://github.com/torvalds/linux/blob/master/kernel/cgroup.c#L2137

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1588056/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp


[Kernel-packages] [Bug 1593874] [NEW] warning stack trace while playing with apparmor namespaces

2016-06-17 Thread Tycho Andersen
Public bug reported:

I'm not sure what exactly I was doing when this happened, but something
fairly basic (creating containers, adding/removing profiles). Let me
know if you need more than the trace and I can try and figure out how to
reproduce.

Jun 17 20:20:06 dev kernel: [13314.032676] [ cut here ]
Jun 17 20:20:06 dev kernel: [13314.032689] WARNING: CPU: 3 PID: 8964 at 
/build/linux-oXTOqc/linux-4.4.0/security/apparmor/label.c:82 
__aa_proxy_redirect+0xff/0x130()
Jun 17 20:20:06 dev kernel: [13314.032692] AppArmor WARN __aa_proxy_redirect: 
((!!queued_write_can_lock(&(&(&(&((orig)->vec[0])))[(((orig)->size)) - 
1])->ns))->labels)->lock)->raw_lock))): 
Jun 17 20:20:06 dev kernel: [13314.032693] Modules linked in: binfmt_misc veth 
xt_CHECKSUM iptable_mangle ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat 
nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack xt_tcpudp 
bridge stp llc iptable_filter ip_tables x_tables isofs zfs(PO) zunicode(PO) 
zcommon(PO) znvpair(PO) spl(O) zavl(PO) ppdev kvm_intel kvm joydev serio_raw 
irqbypass parport_pc parport ib_iser rdma_cm iw_cm ib_cm ib_sa ib_mad ib_core 
ib_addr iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi autofs4 btrfs 
raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor 
raid6_pq libcrc32c raid1 raid0 multipath linear psmouse floppy
Jun 17 20:20:06 dev kernel: [13314.032751] CPU: 3 PID: 8964 Comm: lxd Tainted: 
P        W  O    4.4.0-24-generic #43-Ubuntu
Jun 17 20:20:06 dev kernel: [13314.032753] Hardware name: QEMU Standard PC 
(i440FX + PIIX, 1996), BIOS Ubuntu-1.8.2-1ubuntu1 04/01/2014
Jun 17 20:20:06 dev kernel: [13314.032756]  0286 dc104ca4 
880044db3d18 813eab23
Jun 17 20:20:06 dev kernel: [13314.032760]  880044db3d60 81cec7f0 
880044db3d50 810810d2
Jun 17 20:20:06 dev kernel: [13314.032763]  880047f04360 88007a08d360 
88004a551b00 88004a551b38
Jun 17 20:20:06 dev kernel: [13314.032766] Call Trace:
Jun 17 20:20:06 dev kernel: [13314.032773]  [] 
dump_stack+0x63/0x90
Jun 17 20:20:06 dev kernel: [13314.032777]  [] 
warn_slowpath_common+0x82/0xc0
Jun 17 20:20:06 dev kernel: [13314.032780]  [] 
warn_slowpath_fmt+0x5c/0x80
Jun 17 20:20:06 dev kernel: [13314.032784]  [] ? 
__list_remove_profile+0x62/0xe0
Jun 17 20:20:06 dev kernel: [13314.032788]  [] 
__aa_proxy_redirect+0xff/0x130
Jun 17 20:20:06 dev kernel: [13314.032792]  [] 
destroy_ns+0x86/0xa0
Jun 17 20:20:06 dev kernel: [13314.032794]  [] 
__aa_remove_ns+0x2f/0x60
Jun 17 20:20:06 dev kernel: [13314.032798]  [] 
aa_remove_profiles+0x193/0x270
Jun 17 20:20:06 dev kernel: [13314.032800]  [] ? 
__aa_kvmalloc+0x41/0x60
Jun 17 20:20:06 dev kernel: [13314.032803]  [] 
profile_remove+0x9e/0x1f0
Jun 17 20:20:06 dev kernel: [13314.032808]  [] 
__vfs_write+0x18/0x40
Jun 17 20:20:06 dev kernel: [13314.032811]  [] 
vfs_write+0xa9/0x1a0
Jun 17 20:20:06 dev kernel: [13314.032814]  [] ? 
do_sys_open+0x1bf/0x2a0
Jun 17 20:20:06 dev kernel: [13314.032818]  [] 
SyS_write+0x55/0xc0
Jun 17 20:20:06 dev kernel: [13314.032823]  [] 
entry_SYSCALL_64_fastpath+0x16/0x71
Jun 17 20:20:06 dev kernel: [13314.032826] ---[ end trace 2eb06377c45f3d4c ]---

** Affects: linux (Ubuntu)
 Importance: Undecided
 Status: New

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1593874

Title:
  warning stack trace while playing with apparmor namespaces

Status in linux package in Ubuntu:
  New

Bug description:
  I'm not sure what exactly I was doing when this happened, but
  something fairly basic (creating containers, adding/removing
  profiles). Let me know if you need more than the trace and I can try
  and figure out how to reproduce.

  Jun 17 20:20:06 dev kernel: [13314.032676] [ cut here 
]
  Jun 17 20:20:06 dev kernel: [13314.032689] WARNING: CPU: 3 PID: 8964 at 
/build/linux-oXTOqc/linux-4.4.0/security/apparmor/label.c:82 
__aa_proxy_redirect+0xff/0x130()
  Jun 17 20:20:06 dev kernel: [13314.032692] AppArmor WARN __aa_proxy_redirect: 
((!!queued_write_can_lock(&(&(&(&((orig)->vec[0])))[(((orig)->size)) - 
1])->ns))->labels)->lock)->raw_lock))): 
  Jun 17 20:20:06 dev kernel: [13314.032693] Modules linked in: binfmt_misc 
veth xt_CHECKSUM iptable_mangle ipt_MASQUERADE nf_nat_masquerade_ipv4 
iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack 
xt_tcpudp bridge stp llc iptable_filter ip_tables x_tables isofs zfs(PO) 
zunicode(PO) zcommon(PO) znvpair(PO) spl(O) zavl(PO) ppdev kvm_intel kvm joydev 
serio_raw irqbypass parport_pc parport ib_iser rdma_cm iw_cm ib_cm ib_sa ib_mad 
ib_core ib_addr iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi autofs4 
btrfs raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx 
xor raid6_pq libcrc32c raid1 raid0 multipath linear psmouse floppy
  Jun 17 20:20:06 dev k

[Kernel-packages] [Bug 1590069] Re: vDSO syscalls don't work on yakkety/master-next (and unstable/master)

2016-06-14 Thread Tycho Andersen
Hi Tim,

I just tested this in a fresh yakkety VM using the daily cloud images
and the kernel team PPA you mentioned and reproduced it with your
program:

ubuntu@yakkety:~$ strace ./tester
execve("./tester", ["./tester"], [/* 17 vars */]) = 0
brk(NULL)   = 0x55dbbabdf000
access("/etc/ld.so.nohwcap", F_OK)  = -1 ENOENT (No such file or directory)
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0x7f444ba48000
access("/etc/ld.so.preload", R_OK)  = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=23765, ...}) = 0
mmap(NULL, 23765, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f444ba42000
close(3)= 0
access("/etc/ld.so.nohwcap", F_OK)  = -1 ENOENT (No such file or directory)
open("/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0P\t\2\0\0\0\0\0"..., 
832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=1864888, ...}) = 0
mmap(NULL, 3967488, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 
0x7f444b45c000
mprotect(0x7f444b61c000, 2093056, PROT_NONE) = 0
mmap(0x7f444b81b000, 24576, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1bf000) = 0x7f444b81b000
mmap(0x7f444b821000, 14848, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f444b821000
close(3)= 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0x7f444ba41000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0x7f444ba4
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0x7f444ba3f000
arch_prctl(ARCH_SET_FS, 0x7f444ba40700) = 0
mprotect(0x7f444b81b000, 16384, PROT_READ) = 0
mprotect(0x55dbb9616000, 4096, PROT_READ) = 0
mprotect(0x7f444ba4a000, 4096, PROT_READ) = 0
munmap(0x7f444ba42000, 23765)   = 0
nanosleep({1, 0}, 0x7ffd91f7c6c0)   = 0
gettimeofday({1465946468, 561043}, {tz_minuteswest=0, tz_dsttime=0}) = 0
fstat(1, {st_mode=S_IFCHR|0600, st_rdev=makedev(4, 64), ...}) = 0
ioctl(1, TCGETS, {B9600 opost isig icanon echo ...}) = 0
brk(NULL)   = 0x55dbbabdf000
brk(0x55dbbac01000) = 0x55dbbac01000
write(1, "sec 1465946468\n", 15sec 1465946468
)= 15
nanosleep({1, 0}, 0x7ffd91f7c6c0)   = 0
gettimeofday({1465946469, 567377}, {tz_minuteswest=0, tz_dsttime=0}) = 0
write(1, "sec 1465946469\n", 15sec 1465946469
)= 15
nanosleep({1, 0}, 0x7ffd91f7c6c0)   = 0
gettimeofday({1465946470, 570615}, {tz_minuteswest=0, tz_dsttime=0}) = 0
write(1, "sec 1465946470\n", 15sec 1465946470
)= 15
nanosleep({1, 0}, 0x7ffd91f7c6c0)   = 0
gettimeofday({1465946471, 574084}, {tz_minuteswest=0, tz_dsttime=0}) = 0
write(1, "sec 1465946471\n", 15sec 1465946471
)= 15
nanosleep({1, 0}, 0x7ffd91f7c6c0)   = 0
gettimeofday({1465946472, 576646}, {tz_minuteswest=0, tz_dsttime=0}) = 0
write(1, "sec 1465946472\n", 15sec 1465946472
)= 15
nanosleep({1, 0}, ^Cstrace: Process 1490 detached
 
ubuntu@yakkety:~$ uname -a
Linux yakkety 4.6.0-7-generic #8-Ubuntu SMP Fri Jun 3 15:08:18 UTC 2016 x86_64 
x86_64 x86_64 GNU/Linux
ubuntu@yakkety:~$ apt-cache showpkg linux-image-4.6.0-7-generic 
Package: linux-image-4.6.0-7-generic
Versions: 
4.6.0-7.8 
(/var/lib/apt/lists/ppa.launchpad.net_canonical-kernel-team_ppa_ubuntu_dists_yakkety_main_binary-amd64_Packages)
 (/var/lib/dpkg/status)
 Description Language: 
 File: 
/var/lib/apt/lists/ppa.launchpad.net_canonical-kernel-team_ppa_ubuntu_dists_yakkety_main_binary-amd64_Packages
  MD5: eb70ad30d136e11219815e66f14ab797
 Description Language: en
 File: 
/var/lib/apt/lists/ppa.launchpad.net_canonical-kernel-team_ppa_ubuntu_dists_yakkety_main_i18n_Translation-en
  MD5: eb70ad30d136e11219815e66f14ab797


Reverse Depends: 
  linux-image-generic,linux-image-4.6.0-7-generic
  linux-image-extra-4.6.0-7-generic,linux-image-4.6.0-7-generic
  linux-image-virtual,linux-image-4.6.0-7-generic
Dependencies: 
4.6.0-7.8 - initramfs-tools (16 (null)) linux-initramfs-tool (0 (null)) kmod (0 
(null)) grub-pc (16 (null)) grub-efi-amd64 (16 (null)) grub-efi-ia32 (16 
(null)) grub (16 (null)) lilo (0 (null)) fdutils (0 (null)) linux-doc-4.6.0 (16 
(null)) linux-source-4.6.0 (0 (null)) linux-tools (0 (null)) 
linux-headers-4.6.0-7-generic (0 (null)) 
Provides: 
4.6.0-7.8 - zfs-dkms (= ) virtualbox-guest-modules (= ) spl-dkms (= ) 
redhat-cluster-modules (= ) linux-image (= ) kvm-api-4 (= ) ivtv-modules (= ) 
fuse-module (= ) 
Reverse Provides: 
ubuntu@yakkety:~$ 

Here the kernel has a 4.6.0-7 version number, not a 4.6.0-7.8 as you
mentioned. Where do I get that kernel?

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1590069


[Kernel-packages] [Bug 1580355] Re: promote *_diag modules from linux-image-extra to linux-image

2016-06-14 Thread Tycho Andersen
** Tags removed: verification-needed-xenial
** Tags added: verification-done-xenial

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1580355

Title:
  promote *_diag modules from linux-image-extra to linux-image

Status in linux package in Ubuntu:
  Fix Committed
Status in linux source package in Xenial:
  Fix Committed
Status in linux source package in Yakkety:
  Fix Committed

Bug description:
  Hi,

  For checkpoint restore support via CRIU, we need to use the following
  modules:

  udp_diag
  tcp_diag
  inet_diag
  netlink_diag
  af_packet_diag
  unix_diag

  some of which aren't included in linux-image, requiring users to
  install linux-image-extra. It would be handy if these were in the main
  kernel package.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1580355/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp


Re: [Kernel-packages] [Bug 1590069] Re: vDSO syscalls don't work on yakkety/master-next (and unstable/master)

2016-06-07 Thread Tycho Andersen
On Tue, Jun 07, 2016 at 05:23:58PM -, Tim Gardner wrote:
> Tycho - I cannot reproduce this on bare metal running linux 4.6.0-7.8
> from ppa:canonical-kernel-team/ppa using Xenial user space. Lemme try
> Yakkety user space.

The kernel I used had a 4.6.0-8 version number, I assume because I'm
using the -next branch and not what's currently in master. Could that
be the difference?

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1590069

Title:
  vDSO syscalls don't work on yakkety/master-next (and unstable/master)

Status in linux package in Ubuntu:
  Triaged
Status in linux source package in Yakkety:
  Triaged

Bug description:
  Hi guys,

  I'm having a problem where vDSO syscalls don't work on yakkety-next:

  dev:~ uname -a
  Linux dev 4.6.0-8-generic #9 SMP Mon Jun 6 14:21:30 MDT 2016 x86_64 x86_64 
x86_64 GNU/Linux
  dev:~ cat tester.c 
  #include 
  #include 
  #include 

  int main()
  {
struct timeval tv;
struct timezone tz;

while (1) {
sleep(1);
if (gettimeofday(&tv, &tz) < 0) {
perror("gettimeofday");
}
}

return 0;
  }
  dev:~ make tester
  make: 'tester' is up to date.
  dev:~ strace tester
  strace: Can't stat 'tester': No such file or directory
  dev:~ 1 strace ./tester
  execve("./tester", ["./tester"], [/* 35 vars */]) = 0
  brk(NULL)   = 0x19e4000
  access("/etc/ld.so.nohwcap", F_OK)  = -1 ENOENT (No such file or 
directory)
  mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0x7fbca234b000
  access("/etc/ld.so.preload", R_OK)  = -1 ENOENT (No such file or 
directory)
  open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
  fstat(3, {st_mode=S_IFREG|0644, st_size=44113, ...}) = 0
  mmap(NULL, 44113, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7fbca234
  close(3)= 0
  access("/etc/ld.so.nohwcap", F_OK)  = -1 ENOENT (No such file or 
directory)
  open("/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
  read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0P\t\2\0\0\0\0\0"..., 
832) = 832
  fstat(3, {st_mode=S_IFREG|0755, st_size=1864888, ...}) = 0
  mmap(NULL, 3967488, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 
0x7fbca1d5f000
  mprotect(0x7fbca1f1f000, 2093056, PROT_NONE) = 0
  mmap(0x7fbca211e000, 24576, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1bf000) = 0x7fbca211e000
  mmap(0x7fbca2124000, 14848, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7fbca2124000
  close(3)= 0
  mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0x7fbca233f000
  mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0x7fbca233e000
  mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0x7fbca233d000
  arch_prctl(ARCH_SET_FS, 0x7fbca233e700) = 0
  mprotect(0x7fbca211e000, 16384, PROT_READ) = 0
  mprotect(0x60, 4096, PROT_READ) = 0
  mprotect(0x7fbca234d000, 4096, PROT_READ) = 0
  munmap(0x7fbca234, 44113)   = 0
  nanosleep({1, 0}, 0x7fffc8ec71f0)   = 0
  gettimeofday({1465317034, 813437}, {tz_minuteswest=0, tz_dsttime=0}) = 0
  nanosleep({1, 0}, 0x7fffc8ec71f0)   = 0
  gettimeofday({1465317035, 813718}, {tz_minuteswest=0, tz_dsttime=0}) = 0
  nanosleep({1, 0}, 0x7fffc8ec71f0)   = 0
  gettimeofday({1465317036, 814008}, {tz_minuteswest=0, tz_dsttime=0}) = 0
  nanosleep({1, 0}, ^Cstrace: Process 15793 detached
   

  whereas on a normal machine, they do:

  ~ uname -a
  Linux hopstrocity 4.4.0-22-generic #40-Ubuntu SMP Thu May 12 22:03:46 UTC 
2016 x86_64 x86_64 x86_64 GNU/Linux
  ~ cat tester.c 
  #include 
  #include 
  #include 

  int main()
  {
struct timeval tv;
struct timezone tz;

while (1) {
sleep(1);
if (gettimeofday(&tv, &tz) < 0) {
perror("gettimeofday");
}
}

return 0;
  }

  ~ make tester
  make: 'tester' is up to date.
  ~ strace ./tester
  execve("./tester", ["./tester"], [/* 60 vars */]) = 0
  brk(NULL)   = 0x12c7000
  access("/etc/ld.so.nohwcap", F_OK)  = -1 ENOENT (No such file or 
directory)
  mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0x7fb544a9b000
  access("/etc/ld.so.preload", R_OK)  = -1 ENOENT (No such file or 
directory)
  open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
  fstat(3, {st_mode=S_IFREG|0644, st_size=143083, ...}) = 0
  mmap(NULL, 143083, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7fb544a78000
  close(3)= 0
  access("/etc/ld.so.nohwcap", F_OK)  = -1 ENOENT (No such file or 
directory)
  open("/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
  read(3, "\177EL

[Kernel-packages] [Bug 1590069] [NEW] vDSO syscalls don't work on yakkety/master-next (and unstable/master)

2016-06-07 Thread Tycho Andersen
Public bug reported:

Hi guys,

I'm having a problem where vDSO syscalls don't work on yakkety-next:

dev:~ uname -a
Linux dev 4.6.0-8-generic #9 SMP Mon Jun 6 14:21:30 MDT 2016 x86_64 x86_64 
x86_64 GNU/Linux
dev:~ cat tester.c 
#include 
#include 
#include 

int main()
{
struct timeval tv;
struct timezone tz;

while (1) {
sleep(1);
if (gettimeofday(&tv, &tz) < 0) {
perror("gettimeofday");
}
}

return 0;
}
dev:~ make tester
make: 'tester' is up to date.
dev:~ strace tester
strace: Can't stat 'tester': No such file or directory
dev:~ 1 strace ./tester
execve("./tester", ["./tester"], [/* 35 vars */]) = 0
brk(NULL)   = 0x19e4000
access("/etc/ld.so.nohwcap", F_OK)  = -1 ENOENT (No such file or directory)
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0x7fbca234b000
access("/etc/ld.so.preload", R_OK)  = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=44113, ...}) = 0
mmap(NULL, 44113, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7fbca234
close(3)= 0
access("/etc/ld.so.nohwcap", F_OK)  = -1 ENOENT (No such file or directory)
open("/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0P\t\2\0\0\0\0\0"..., 
832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=1864888, ...}) = 0
mmap(NULL, 3967488, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 
0x7fbca1d5f000
mprotect(0x7fbca1f1f000, 2093056, PROT_NONE) = 0
mmap(0x7fbca211e000, 24576, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1bf000) = 0x7fbca211e000
mmap(0x7fbca2124000, 14848, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7fbca2124000
close(3)= 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0x7fbca233f000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0x7fbca233e000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0x7fbca233d000
arch_prctl(ARCH_SET_FS, 0x7fbca233e700) = 0
mprotect(0x7fbca211e000, 16384, PROT_READ) = 0
mprotect(0x60, 4096, PROT_READ) = 0
mprotect(0x7fbca234d000, 4096, PROT_READ) = 0
munmap(0x7fbca234, 44113)   = 0
nanosleep({1, 0}, 0x7fffc8ec71f0)   = 0
gettimeofday({1465317034, 813437}, {tz_minuteswest=0, tz_dsttime=0}) = 0
nanosleep({1, 0}, 0x7fffc8ec71f0)   = 0
gettimeofday({1465317035, 813718}, {tz_minuteswest=0, tz_dsttime=0}) = 0
nanosleep({1, 0}, 0x7fffc8ec71f0)   = 0
gettimeofday({1465317036, 814008}, {tz_minuteswest=0, tz_dsttime=0}) = 0
nanosleep({1, 0}, ^Cstrace: Process 15793 detached
 

whereas on a normal machine, they do:

~ uname -a
Linux hopstrocity 4.4.0-22-generic #40-Ubuntu SMP Thu May 12 22:03:46 UTC 2016 
x86_64 x86_64 x86_64 GNU/Linux
~ cat tester.c 
#include 
#include 
#include 

int main()
{
struct timeval tv;
struct timezone tz;

while (1) {
sleep(1);
if (gettimeofday(&tv, &tz) < 0) {
perror("gettimeofday");
}
}

return 0;
}

~ make tester
make: 'tester' is up to date.
~ strace ./tester
execve("./tester", ["./tester"], [/* 60 vars */]) = 0
brk(NULL)   = 0x12c7000
access("/etc/ld.so.nohwcap", F_OK)  = -1 ENOENT (No such file or directory)
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0x7fb544a9b000
access("/etc/ld.so.preload", R_OK)  = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=143083, ...}) = 0
mmap(NULL, 143083, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7fb544a78000
close(3)= 0
access("/etc/ld.so.nohwcap", F_OK)  = -1 ENOENT (No such file or directory)
open("/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0P\t\2\0\0\0\0\0"..., 
832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=1864888, ...}) = 0
mmap(NULL, 3967488, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 
0x7fb5444af000
mprotect(0x7fb54466f000, 2093056, PROT_NONE) = 0
mmap(0x7fb54486e000, 24576, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1bf000) = 0x7fb54486e000
mmap(0x7fb544874000, 14848, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7fb544874000
close(3)= 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0x7fb544a77000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0x7fb544a76000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0x7fb544a75000
arch_prctl(ARCH_SET_FS, 0x7fb544a76700) = 0
mprotect(0x7fb5448

[Kernel-packages] [Bug 1590069] Re: vDSO syscalls don't work on yakkety/master-next (and unstable/master)

2016-06-07 Thread Tycho Andersen
A nice canary for this is that there's no .dynamic section in vdso.so:

$ readelf --program-headers arch/x86/entry/vdso/vdso64.so

Elf file type is EXEC (Executable file)
Entry point 0x600
There are 4 program headers, starting at offset 64

Program Headers:
  Type   Offset VirtAddr   PhysAddr
 FileSizMemSiz  Flags  Align
  LOAD   0x 0x 0x
 0x0b39 0x0b39  R E1000
  DYNAMIC0x 0x 0x
 0x 0x  R  8
readelf: Error: no .dynamic section in the dynamic segment
  NOTE   0x0460 0x0460 0x0460
 0x003c 0x003c  R  4
  GNU_EH_FRAME   0x049c 0x049c 0x049c
 0x003c 0x003c  R  4

 Section to Segment mapping:
  Segment Sections...
   00 .rodata .note .eh_frame_hdr .eh_frame .text .altinstructions 
.altinstr_replacement 
   01 
   02 .note 
   03 .eh_frame_hdr

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1590069

Title:
  vDSO syscalls don't work on yakkety/master-next (and unstable/master)

Status in linux package in Ubuntu:
  New

Bug description:
  Hi guys,

  I'm having a problem where vDSO syscalls don't work on yakkety-next:

  dev:~ uname -a
  Linux dev 4.6.0-8-generic #9 SMP Mon Jun 6 14:21:30 MDT 2016 x86_64 x86_64 
x86_64 GNU/Linux
  dev:~ cat tester.c 
  #include 
  #include 
  #include 

  int main()
  {
struct timeval tv;
struct timezone tz;

while (1) {
sleep(1);
if (gettimeofday(&tv, &tz) < 0) {
perror("gettimeofday");
}
}

return 0;
  }
  dev:~ make tester
  make: 'tester' is up to date.
  dev:~ strace tester
  strace: Can't stat 'tester': No such file or directory
  dev:~ 1 strace ./tester
  execve("./tester", ["./tester"], [/* 35 vars */]) = 0
  brk(NULL)   = 0x19e4000
  access("/etc/ld.so.nohwcap", F_OK)  = -1 ENOENT (No such file or 
directory)
  mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0x7fbca234b000
  access("/etc/ld.so.preload", R_OK)  = -1 ENOENT (No such file or 
directory)
  open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
  fstat(3, {st_mode=S_IFREG|0644, st_size=44113, ...}) = 0
  mmap(NULL, 44113, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7fbca234
  close(3)= 0
  access("/etc/ld.so.nohwcap", F_OK)  = -1 ENOENT (No such file or 
directory)
  open("/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
  read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0P\t\2\0\0\0\0\0"..., 
832) = 832
  fstat(3, {st_mode=S_IFREG|0755, st_size=1864888, ...}) = 0
  mmap(NULL, 3967488, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 
0x7fbca1d5f000
  mprotect(0x7fbca1f1f000, 2093056, PROT_NONE) = 0
  mmap(0x7fbca211e000, 24576, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1bf000) = 0x7fbca211e000
  mmap(0x7fbca2124000, 14848, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7fbca2124000
  close(3)= 0
  mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0x7fbca233f000
  mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0x7fbca233e000
  mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0x7fbca233d000
  arch_prctl(ARCH_SET_FS, 0x7fbca233e700) = 0
  mprotect(0x7fbca211e000, 16384, PROT_READ) = 0
  mprotect(0x60, 4096, PROT_READ) = 0
  mprotect(0x7fbca234d000, 4096, PROT_READ) = 0
  munmap(0x7fbca234, 44113)   = 0
  nanosleep({1, 0}, 0x7fffc8ec71f0)   = 0
  gettimeofday({1465317034, 813437}, {tz_minuteswest=0, tz_dsttime=0}) = 0
  nanosleep({1, 0}, 0x7fffc8ec71f0)   = 0
  gettimeofday({1465317035, 813718}, {tz_minuteswest=0, tz_dsttime=0}) = 0
  nanosleep({1, 0}, 0x7fffc8ec71f0)   = 0
  gettimeofday({1465317036, 814008}, {tz_minuteswest=0, tz_dsttime=0}) = 0
  nanosleep({1, 0}, ^Cstrace: Process 15793 detached
   

  whereas on a normal machine, they do:

  ~ uname -a
  Linux hopstrocity 4.4.0-22-generic #40-Ubuntu SMP Thu May 12 22:03:46 UTC 
2016 x86_64 x86_64 x86_64 GNU/Linux
  ~ cat tester.c 
  #include 
  #include 
  #include 

  int main()
  {
struct timeval tv;
struct timezone tz;

while (1) {
sleep(1);
if (gettimeofday(&tv, &tz) < 0) {
perror("gettimeofday");
}
}

return 0;
  }

  ~ make tester
  make: 'tester' is up to date.
  ~ strace ./te

[Kernel-packages] [Bug 1588056] Re: cgroupfs mounts can hang

2016-06-02 Thread Tycho Andersen
Yep, this works for me (both checkpoint and restore of containers under
this build, and also the original use case that caused me to find the
bug). Thanks, Seth!

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1588056

Title:
  cgroupfs mounts can hang

Status in linux package in Ubuntu:
  Incomplete

Bug description:
  Consider the following,

  root@dev:/tmp# mkdir foo
  root@dev:/tmp# mount -t cgroup -o none,name=foo none foo
  root@dev:/tmp# mkdir -p foo/bad
  root@dev:/tmp# umount -l foo
  root@dev:/tmp# mount -t cgroup -o none,name=foo none foo # hangs forever
  ^C
  root@dev:/tmp# uname -a
  Linux dev 4.4.0-22-generic #40-Ubuntu SMP Thu May 12 22:03:46 UTC 2016 x86_64 
x86_64 x86_64 GNU/Linux

  When I strace the mount task, I get a whole bunch of,

  mount("none", "/tmp/foo", "cgroup", MS_MGC_VAL, "none,name=foo") = ? 
ERESTARTNOINTR (To be restarted)
  mount("none", "/tmp/foo", "cgroup", MS_MGC_VAL, "none,name=foo") = ? 
ERESTARTNOINTR (To be restarted)
  mount("none", "/tmp/foo", "cgroup", MS_MGC_VAL, "none,name=foo") = ? 
ERESTARTNOINTR (To be restarted)
  mount("none", "/tmp/foo", "cgroup", MS_MGC_VAL, "none,name=foo") = ? 
ERESTARTNOINTR (To be restarted)
  mount("none", "/tmp/foo", "cgroup", MS_MGC_VAL, "none,name=foo") = ? 
ERESTARTNOINTR (To be restarted)
  mount("none", "/tmp/foo", "cgroup", MS_MGC_VAL, "none,name=foo") = ? 
ERESTARTNOINTR (To be restarted)
  mount("none", "/tmp/foo", "cgroup", MS_MGC_VAL, "none,name=foo") = ? 
ERESTARTNOINTR (To be restarted)
  mount("none", "/tmp/foo", "cgroup", MS_MGC_VAL, "none,name=foo") = ? 
ERESTARTNOINTR (To be restarted)
  mount("none", "/tmp/foo", "cgroup", MS_MGC_VAL, "none,name=foo") = ? 
ERESTARTNOINTR (To be restarted)
  mount("none", "/tmp/foo", "cgroup", MS_MGC_VAL, "none,name=foo") = ? 
ERESTARTNOINTR (To be restarted)
  mount("none", "/tmp/foo", "cgroup", MS_MGC_VAL, "none,name=foo") = ? 
ERESTARTNOINTR (To be restarted)
  mount("none", "/tmp/foo", "cgroup", MS_MGC_VAL, "none,name=foo") = ? 
ERESTARTNOINTR (To be restarted)
  mount("none", "/tmp/foo", "cgroup", MS_MGC_VAL, "none,name=foo") = ? 
ERESTARTNOINTR (To be restarted)
  mount("none", "/tmp/foo", "cgroup", MS_MGC_VAL, "none,name=foo") = ? 
ERESTARTNOINTR (To be restarted)
  mount("none", "/tmp/foo", "cgroup", MS_MGC_VAL, "none,name=foo") = ? 
ERESTARTNOINTR (To be restarted)
  mount("none", "/tmp/foo", "cgroup", MS_MGC_VAL, "none,name=foo") = ? 
ERESTARTNOINTR (To be restarted)
  mount("none", "/tmp/foo", "cgroup", MS_MGC_VAL, "none,name=foo") = ? 
ERESTARTNOINTR (To be restarted)

  Which I think means that we're looping on,

  https://github.com/torvalds/linux/blob/master/kernel/cgroup.c#L2137

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1588056/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp


[Kernel-packages] [Bug 1588056] Re: cgroupfs mounts can hang

2016-06-01 Thread Tycho Andersen
Note that this doesn't happen on linux-next, whose HEAD is,

commit e98f2ba41687651055312e0ae617604dd6f7f200
Author: Stephen Rothwell 
Date:   Wed Jun 1 13:08:58 2016 +1000

Add linux-next specific files for 20160601

Signed-off-by: Stephen Rothwell 

right now.

** Changed in: linux (Ubuntu)
   Status: Incomplete => Confirmed

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1588056

Title:
  cgroupfs mounts can hang

Status in linux package in Ubuntu:
  Confirmed

Bug description:
  Consider the following,

  root@dev:/tmp# mkdir foo
  root@dev:/tmp# mount -t cgroup -o none,name=foo none foo
  root@dev:/tmp# mkdir -p foo/bad
  root@dev:/tmp# umount -l foo
  root@dev:/tmp# mount -t cgroup -o none,name=foo none foo # hangs forever
  ^C
  root@dev:/tmp# uname -a
  Linux dev 4.4.0-22-generic #40-Ubuntu SMP Thu May 12 22:03:46 UTC 2016 x86_64 
x86_64 x86_64 GNU/Linux

  When I strace the mount task, I get a whole bunch of,

  mount("none", "/tmp/foo", "cgroup", MS_MGC_VAL, "none,name=foo") = ? 
ERESTARTNOINTR (To be restarted)
  mount("none", "/tmp/foo", "cgroup", MS_MGC_VAL, "none,name=foo") = ? 
ERESTARTNOINTR (To be restarted)
  mount("none", "/tmp/foo", "cgroup", MS_MGC_VAL, "none,name=foo") = ? 
ERESTARTNOINTR (To be restarted)
  mount("none", "/tmp/foo", "cgroup", MS_MGC_VAL, "none,name=foo") = ? 
ERESTARTNOINTR (To be restarted)
  mount("none", "/tmp/foo", "cgroup", MS_MGC_VAL, "none,name=foo") = ? 
ERESTARTNOINTR (To be restarted)
  mount("none", "/tmp/foo", "cgroup", MS_MGC_VAL, "none,name=foo") = ? 
ERESTARTNOINTR (To be restarted)
  mount("none", "/tmp/foo", "cgroup", MS_MGC_VAL, "none,name=foo") = ? 
ERESTARTNOINTR (To be restarted)
  mount("none", "/tmp/foo", "cgroup", MS_MGC_VAL, "none,name=foo") = ? 
ERESTARTNOINTR (To be restarted)
  mount("none", "/tmp/foo", "cgroup", MS_MGC_VAL, "none,name=foo") = ? 
ERESTARTNOINTR (To be restarted)
  mount("none", "/tmp/foo", "cgroup", MS_MGC_VAL, "none,name=foo") = ? 
ERESTARTNOINTR (To be restarted)
  mount("none", "/tmp/foo", "cgroup", MS_MGC_VAL, "none,name=foo") = ? 
ERESTARTNOINTR (To be restarted)
  mount("none", "/tmp/foo", "cgroup", MS_MGC_VAL, "none,name=foo") = ? 
ERESTARTNOINTR (To be restarted)
  mount("none", "/tmp/foo", "cgroup", MS_MGC_VAL, "none,name=foo") = ? 
ERESTARTNOINTR (To be restarted)
  mount("none", "/tmp/foo", "cgroup", MS_MGC_VAL, "none,name=foo") = ? 
ERESTARTNOINTR (To be restarted)
  mount("none", "/tmp/foo", "cgroup", MS_MGC_VAL, "none,name=foo") = ? 
ERESTARTNOINTR (To be restarted)
  mount("none", "/tmp/foo", "cgroup", MS_MGC_VAL, "none,name=foo") = ? 
ERESTARTNOINTR (To be restarted)
  mount("none", "/tmp/foo", "cgroup", MS_MGC_VAL, "none,name=foo") = ? 
ERESTARTNOINTR (To be restarted)

  Which I think means that we're looping on,

  https://github.com/torvalds/linux/blob/master/kernel/cgroup.c#L2137

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1588056/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp


[Kernel-packages] [Bug 1588056] [NEW] cgroupfs mounts can hang

2016-06-01 Thread Tycho Andersen
Public bug reported:

Consider the following,

root@dev:/tmp# mkdir foo
root@dev:/tmp# mount -t cgroup -o none,name=foo none foo
root@dev:/tmp# mkdir -p foo/bad
root@dev:/tmp# umount -l foo
root@dev:/tmp# mount -t cgroup -o none,name=foo none foo # hangs forever
^C
root@dev:/tmp# uname -a
Linux dev 4.4.0-22-generic #40-Ubuntu SMP Thu May 12 22:03:46 UTC 2016 x86_64 
x86_64 x86_64 GNU/Linux

When I strace the mount task, I get a whole bunch of,

mount("none", "/tmp/foo", "cgroup", MS_MGC_VAL, "none,name=foo") = ? 
ERESTARTNOINTR (To be restarted)
mount("none", "/tmp/foo", "cgroup", MS_MGC_VAL, "none,name=foo") = ? 
ERESTARTNOINTR (To be restarted)
mount("none", "/tmp/foo", "cgroup", MS_MGC_VAL, "none,name=foo") = ? 
ERESTARTNOINTR (To be restarted)
mount("none", "/tmp/foo", "cgroup", MS_MGC_VAL, "none,name=foo") = ? 
ERESTARTNOINTR (To be restarted)
mount("none", "/tmp/foo", "cgroup", MS_MGC_VAL, "none,name=foo") = ? 
ERESTARTNOINTR (To be restarted)
mount("none", "/tmp/foo", "cgroup", MS_MGC_VAL, "none,name=foo") = ? 
ERESTARTNOINTR (To be restarted)
mount("none", "/tmp/foo", "cgroup", MS_MGC_VAL, "none,name=foo") = ? 
ERESTARTNOINTR (To be restarted)
mount("none", "/tmp/foo", "cgroup", MS_MGC_VAL, "none,name=foo") = ? 
ERESTARTNOINTR (To be restarted)
mount("none", "/tmp/foo", "cgroup", MS_MGC_VAL, "none,name=foo") = ? 
ERESTARTNOINTR (To be restarted)
mount("none", "/tmp/foo", "cgroup", MS_MGC_VAL, "none,name=foo") = ? 
ERESTARTNOINTR (To be restarted)
mount("none", "/tmp/foo", "cgroup", MS_MGC_VAL, "none,name=foo") = ? 
ERESTARTNOINTR (To be restarted)
mount("none", "/tmp/foo", "cgroup", MS_MGC_VAL, "none,name=foo") = ? 
ERESTARTNOINTR (To be restarted)
mount("none", "/tmp/foo", "cgroup", MS_MGC_VAL, "none,name=foo") = ? 
ERESTARTNOINTR (To be restarted)
mount("none", "/tmp/foo", "cgroup", MS_MGC_VAL, "none,name=foo") = ? 
ERESTARTNOINTR (To be restarted)
mount("none", "/tmp/foo", "cgroup", MS_MGC_VAL, "none,name=foo") = ? 
ERESTARTNOINTR (To be restarted)
mount("none", "/tmp/foo", "cgroup", MS_MGC_VAL, "none,name=foo") = ? 
ERESTARTNOINTR (To be restarted)
mount("none", "/tmp/foo", "cgroup", MS_MGC_VAL, "none,name=foo") = ? 
ERESTARTNOINTR (To be restarted)

Which I think means that we're looping on,

https://github.com/torvalds/linux/blob/master/kernel/cgroup.c#L2137

** Affects: linux (Ubuntu)
 Importance: Undecided
 Status: Incomplete

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1588056

Title:
  cgroupfs mounts can hang

Status in linux package in Ubuntu:
  Incomplete

Bug description:
  Consider the following,

  root@dev:/tmp# mkdir foo
  root@dev:/tmp# mount -t cgroup -o none,name=foo none foo
  root@dev:/tmp# mkdir -p foo/bad
  root@dev:/tmp# umount -l foo
  root@dev:/tmp# mount -t cgroup -o none,name=foo none foo # hangs forever
  ^C
  root@dev:/tmp# uname -a
  Linux dev 4.4.0-22-generic #40-Ubuntu SMP Thu May 12 22:03:46 UTC 2016 x86_64 
x86_64 x86_64 GNU/Linux

  When I strace the mount task, I get a whole bunch of,

  mount("none", "/tmp/foo", "cgroup", MS_MGC_VAL, "none,name=foo") = ? 
ERESTARTNOINTR (To be restarted)
  mount("none", "/tmp/foo", "cgroup", MS_MGC_VAL, "none,name=foo") = ? 
ERESTARTNOINTR (To be restarted)
  mount("none", "/tmp/foo", "cgroup", MS_MGC_VAL, "none,name=foo") = ? 
ERESTARTNOINTR (To be restarted)
  mount("none", "/tmp/foo", "cgroup", MS_MGC_VAL, "none,name=foo") = ? 
ERESTARTNOINTR (To be restarted)
  mount("none", "/tmp/foo", "cgroup", MS_MGC_VAL, "none,name=foo") = ? 
ERESTARTNOINTR (To be restarted)
  mount("none", "/tmp/foo", "cgroup", MS_MGC_VAL, "none,name=foo") = ? 
ERESTARTNOINTR (To be restarted)
  mount("none", "/tmp/foo", "cgroup", MS_MGC_VAL, "none,name=foo") = ? 
ERESTARTNOINTR (To be restarted)
  mount("none", "/tmp/foo", "cgroup", MS_MGC_VAL, "none,name=foo") = ? 
ERESTARTNOINTR (To be restarted)
  mount("none", "/tmp/foo", "cgroup", MS_MGC_VAL, "none,name=foo") = ? 
ERESTARTNOINTR (To be restarted)
  mount("none", "/tmp/foo", "cgroup", MS_MGC_VAL, "none,name=foo") = ? 
ERESTARTNOINTR (To be restarted)
  mount("none", "/tmp/foo", "cgroup", MS_MGC_VAL, "none,name=foo") = ? 
ERESTARTNOINTR (To be restarted)
  mount("none", "/tmp/foo", "cgroup", MS_MGC_VAL, "none,name=foo") = ? 
ERESTARTNOINTR (To be restarted)
  mount("none", "/tmp/foo", "cgroup", MS_MGC_VAL, "none,name=foo") = ? 
ERESTARTNOINTR (To be restarted)
  mount("none", "/tmp/foo", "cgroup", MS_MGC_VAL, "none,name=foo") = ? 
ERESTARTNOINTR (To be restarted)
  mount("none", "/tmp/foo", "cgroup", MS_MGC_VAL, "none,name=foo") = ? 
ERESTARTNOINTR (To be restarted)
  mount("none", "/tmp/foo", "cgroup", MS_MGC_VAL, "none,name=foo") = ? 
ERESTARTNOINTR (To be restarted)
  mount("none", "/tmp/foo", "cgroup", MS_MGC_VAL, "none,name=foo") = ? 
ERESTARTNOINTR (To be restarted)

  Which I think means that we're looping on,

  https://github.com/torvalds/linux/blob/master/kernel/cg

[Kernel-packages] [Bug 1580355] [NEW] promote *_diag modules from linux-image-extra to linux-image

2016-05-10 Thread Tycho Andersen
Public bug reported:

Hi,

For checkpoint restore support via CRIU, we need to use the following
modules:

udp_diag
tcp_diag
inet_diag
netlink_diag
af_packet_diag
unix_diag

some of which aren't included in linux-image, requiring users to install
linux-image-extra. It would be handy if these were in the main kernel
package.

** Affects: linux (Ubuntu)
 Importance: Undecided
 Status: New

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1580355

Title:
  promote *_diag modules from linux-image-extra to linux-image

Status in linux package in Ubuntu:
  New

Bug description:
  Hi,

  For checkpoint restore support via CRIU, we need to use the following
  modules:

  udp_diag
  tcp_diag
  inet_diag
  netlink_diag
  af_packet_diag
  unix_diag

  some of which aren't included in linux-image, requiring users to
  install linux-image-extra. It would be handy if these were in the main
  kernel package.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1580355/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp


[Kernel-packages] [Bug 1572316] [NEW] oops when propagating mounts into containers

2016-04-19 Thread Tycho Andersen
Public bug reported:

If I use LXD on xenial with a configuration that does something like:
(/nfs in my case is an nfs mount, but based on the kernel code in
question anything is probably okay):

devices:
  bind:
type: disk
source: /nfs
path: /nfs
recursive: "true"

and then start the container and on the host, do a new mount:

sudo mount $ipaddr:/some/nfs/path /nfs/newpath

You get the following kernel oops:

Apr 11 21:59:36 stock2 kernel: [ 1648.993034] Oops:  [#1] SMP 
Apr 11 21:59:36 stock2 kernel: [ 1648.993415] Modules linked in: binfmt_misc 
veth rpcsec_gss_krb5 auth_rpcgss nfsv4 nfs lockd grace fscache xt_CHECKSUM 
iptable_mangle xt_tcpudp ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat 
nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack bridge stp llc 
iptable_filter ip_tables x_tables zfs(PO) zunicode(PO) zcommon(PO) znvpair(PO) 
spl(O) zavl(PO) ppdev kvm_intel parport_pc joydev kvm input_leds mac_hid 
irqbypass parport i2c_piix4 8250_fintek serio_raw ib_iser rdma_cm iw_cm ib_cm 
ib_sa ib_mad ib_core ib_addr sunrpc iscsi_tcp libiscsi_tcp libiscsi 
scsi_transport_iscsi autofs4 btrfs raid10 raid456 async_raid6_recov 
async_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c raid1 raid0 
multipath linear cirrus ttm drm_kms_helper syscopyarea sysfillrect sysimgblt 
psmouse fb_sys_fops floppy drm pata_acpi
Apr 11 21:59:36 stock2 kernel: [ 1649.002015] CPU: 2 PID: 9449 Comm: mount.nfs 
Tainted: P   O4.4.0-18-generic #34+tych0201604111025
Apr 11 21:59:36 stock2 kernel: [ 1649.003037] Hardware name: QEMU Standard PC 
(i440FX + PIIX, 1996), BIOS Ubuntu-1.8.2-1ubuntu1 04/01/2014
Apr 11 21:59:36 stock2 kernel: [ 1649.004042] task: 880074c1a580 ti: 
880067d3 task.ti: 880067d3
Apr 11 21:59:36 stock2 kernel: [ 1649.004810] RIP: 0010:[]  
[] propagate_one+0xbe/0x1c0
Apr 11 21:59:36 stock2 kernel: [ 1649.005654] RSP: 0018:880067d33d68  
EFLAGS: 00010297
Apr 11 21:59:36 stock2 kernel: [ 1649.006211] RAX: 88003bb4ca80 RBX: 
880074ad8300 RCX: 880074503500
Apr 11 21:59:36 stock2 kernel: [ 1649.006934] RDX:  RSI: 
019c RDI: 
Apr 11 21:59:36 stock2 kernel: [ 1649.007656] RBP: 880067d33d78 R08: 
8800363bad80 R09: 813eac5c
Apr 11 21:59:36 stock2 kernel: [ 1649.008390] R10: ea2b5800 R11: 
00018711 R12: 8800363ba600
Apr 11 21:59:36 stock2 kernel: [ 1649.009111] R13: 880067d33dc0 R14: 
880074ad8300 R15: 
Apr 11 21:59:36 stock2 kernel: [ 1649.009835] FS:  7f653eac4880() 
GS:88007cd0() knlGS:
Apr 11 21:59:36 stock2 kernel: [ 1649.010642] CS:  0010 DS:  ES:  CR0: 
8005003b
Apr 11 21:59:36 stock2 kernel: [ 1649.011237] CR2: 0010 CR3: 
77a4e000 CR4: 06e0
Apr 11 21:59:36 stock2 kernel: [ 1649.011984] Stack:
Apr 11 21:59:36 stock2 kernel: [ 1649.012255]  880074ad8300 
8800363ba600 880067d33db0 8123d060
Apr 11 21:59:36 stock2 kernel: [ 1649.013070]  88003bb4ca80 
8800363ba600 88000c211980 
Apr 11 21:59:36 stock2 kernel: [ 1649.013892]  880067d33e98 
880067d33df8 8122dd97 88003bb4c900
Apr 11 21:59:36 stock2 kernel: [ 1649.014751] Call Trace:
Apr 11 21:59:36 stock2 kernel: [ 1649.015053]  [] 
propagate_mnt+0x120/0x150
Apr 11 21:59:36 stock2 kernel: [ 1649.015643]  [] 
attach_recursive_mnt+0x147/0x230
Apr 11 21:59:36 stock2 kernel: [ 1649.016286]  [] 
graft_tree+0x58/0x90
Apr 11 21:59:36 stock2 kernel: [ 1649.016809]  [] 
do_add_mount+0x8e/0xd0
Apr 11 21:59:36 stock2 kernel: [ 1649.017342]  [] 
do_mount+0x2c0/0xe00
Apr 11 21:59:36 stock2 kernel: [ 1649.017863]  [] ? 
copy_mount_options+0xb4/0x220
Apr 11 21:59:36 stock2 kernel: [ 1649.018466]  [] 
SyS_mount+0x9f/0x100
Apr 11 21:59:36 stock2 kernel: [ 1649.018996]  [] 
entry_SYSCALL_64_fastpath+0x16/0x71
Apr 11 21:59:36 stock2 kernel: [ 1649.019631] Code: 39 90 d8 00 00 00 75 ec 8b 
b0 10 01 00 00 48 89 3d 80 e1 f8 00 48 89 05 81 e1 f8 00 39 b1 10 01 00 00 74 
19 48 8b bf d8 00 00 00 <48> 8b 47 10 48 89 3d 5f e1 f8 00 48 89 05 60 e1 f8 00 
8b 43 30 
Apr 11 21:59:36 stock2 kernel: [ 1649.022395] RIP  [] 
propagate_one+0xbe/0x1c0
Apr 11 21:59:36 stock2 kernel: [ 1649.022990]  RSP 
Apr 11 21:59:36 stock2 kernel: [ 1649.023362] CR2: 0010
Apr 11 21:59:36 stock2 kernel: [ 1649.027053] ---[ end trace 46ce79a38cba28a5 
]---

** Affects: linux (Ubuntu)
 Importance: High
 Assignee: Seth Forshee (sforshee)
 Status: Confirmed

** Affects: linux (Ubuntu Xenial)
 Importance: High
 Assignee: Seth Forshee (sforshee)
 Status: Confirmed

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1572316

Title:
  oops when propagating mounts into containers

Status in linux package in Ubuntu:
  Confirmed
Status in linux sourc

[Kernel-packages] [Bug 1570906] Re: sysfs mount failure during stateful lxd snapshots

2016-04-15 Thread Tycho Andersen
I can confirm that the kernels at
http://kernel.ubuntu.com/~sforshee/lp1570906/ work for me. Thanks, Seth!

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1570906

Title:
  sysfs mount failure during stateful lxd snapshots

Status in linux package in Ubuntu:
  In Progress
Status in linux source package in Xenial:
  In Progress

Bug description:
  SRU Justification:

  Impact: Stateful lxd container snapshotting fails due to a failure to
  mount the container's sysfs in the host's user namespace. This is a
  regression.

  Fix: Force kernfs to use a new super block for mounts in different
  user namespaces.

  Test Case: "lxc snapshot --stateful " fails in the current
  xenial kernel without the fix. It succeeds with the fix applied.

  ---

  During a stateful lxd snapshot criu tries to mount sysfs for the
  container's network namespace from a different user namespace. This
  fails in xenial because sget() won't allow mounting the same super
  block in different user namespaces.

  With sysfs there's no reason that this needs to use the same super
  block, so kernfs can be updated so that a super block with the same ns
  tag but in a different userns is not matched. The only other kernfs-
  based filesystem mountable from non-init user namespaces is cgroupfs,
  and it's already forcing kernfs to return different super blocks to
  avoid similar problems.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1570906/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp


[Kernel-packages] [Bug 1563921] Re: Unable to migrate container

2016-03-30 Thread Tycho Andersen
** Also affects: linux (Ubuntu)
   Importance: Undecided
   Status: New

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1563921

Title:
  Unable to migrate container

Status in criu package in Ubuntu:
  Fix Released
Status in linux package in Ubuntu:
  New

Bug description:
  When trying to migrate a container to another host i get the following
  error:

  Error (mount.c:740): mnt: 150:./sys/fs/cgroup/cpuset doesn't have a
  proper root mount

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/criu/+bug/1563921/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp


[Kernel-packages] [Bug 1297316] Re: kexec doesn't load multiboot images

2014-03-26 Thread Tycho Andersen
Just to update, it looks like this is failing because booting a non-elf
multiboot image is not yet supported by kexec.

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to kexec-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1297316

Title:
  kexec doesn't load multiboot images

Status in “kexec-tools” package in Ubuntu:
  New

Bug description:
  kexec explictly (in --help and man page) reports to support multiboot
  format images.  That doesn't work for at least some subset of
  seemingly proper multiboot images.  For some context, the goal
  essentially the same as discussed at [1].

  mbchk is from 'multiboot' package (built from source).

  Also note that 'qemu-system-x86_64' loads this multiboot image
  properly with 'qemu-system-x86_64 -kernel'

  $ dpkg-query --show kexec-tools
  kexec-tools 1:2.0.4-1ubuntu1

  $ mbchk /boot/grub/i386-pc/core.img
  /boot/grub/i386-pc/core.img: The Multiboot header is found at the offset 2416.
  /boot/grub/i386-pc/core.img: Page alignment is turned off.
  /boot/grub/i386-pc/core.img: Memory information is turned off.
  /boot/grub/i386-pc/core.img: Address fields is turned on.
  /boot/grub/i386-pc/core.img: All checks passed.

  $ kexec --debug --type multiboot-x86 /boot/grub/i386-pc/core.img
  kernel: 0x1767010 kernel_size: 6315
  MEMORY RANGES
  0100-0009f000 (0)
  0009f000-000a (1)
  000e7000-0010 (1)
  0010-bf76 (0)
  bf76e000-bf77 (1)
  bf77-bf77e000 (2)
  bf77e000-bf7d (3)
  bf7d-bf7e (1)
  bf7ec000-c000 (1)
  e000-f000 (1)
  fee0-fee01000 (1)
  ffc0-0001 (1)
  0001-000c4000 (0)
  Cannot determine the file type of /boot/grub/i386-pc/core.img

  
  --
  [1] http://comments.gmane.org/gmane.linux.ubuntu.devel.discuss/14419

  ProblemType: Bug
  DistroRelease: Ubuntu 14.04
  Package: kexec-tools 1:2.0.4-1ubuntu1
  ProcVersionSignature: User Name 3.13.0-8.27-generic 3.13.2
  Uname: Linux 3.13.0-8-generic x86_64
  ApportVersion: 2.13.2-0ubuntu2
  Architecture: amd64
  Date: Tue Mar 25 14:00:01 2014
  ProcEnviron:
   TERM=screen
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  SourcePackage: kexec-tools
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/kexec-tools/+bug/1297316/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp