Ubuntu
linux package

clone() hang when creating new network namespace (dmesg show unregister_netdevice: waiting for lo to become free. Usage count = 2)

Bug #1021471 reported by Iain Lane on 2012年07月05日

This bug affects 12 people

Affects		Status	Importance	Assigned to
Linux	Confirmed	High	linux-kernel-bugs #47181
linux (Ubuntu)	Fix Released	High	Stefan Bader	Ubuntu ubuntu-12.10
Precise	Fix Released	Medium	Chris J Arges
Quantal	Fix Released	High	Stefan Bader	Ubuntu ubuntu-12.10

Bug Description

SRU Justification:

Impact:
When creating new network namespace dmesg can show the following
unregister_netdevice: waiting for lo to become free. Usage count = 1

Fix:
Stefan Bader's SAUCE patch has fixed this for Quantal:
UBUNTU: SAUCE: net/ipv4: Always flush route cache on unregister batch call

Testcase:
The sourcecode found here:
https://lists.debian.org/debian-kernel/2012/05/msg00494.html
can be compiled and run as follows:

sudo ./reproducer
#ctrl+c
sudo ./reproducer
#wait for a while
dmesg | grep unregister

I'm not sure how I triggered this. I've been moving around between networks and suspending/resuming all day.

Earlier in this boot I successfully used a container (start, networking and stop). I came to start the same one later and noticed that it didn't come up. Trying to attach to the console with lxc-console informed me that it wasn't running. I then saw suspicious content in dmesg:

[25800.412234] INFO: task lxc-start:25817 blocked for more than 120 seconds.
[25800.412243] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[25800.412254] lxc-start D ffff88013fd13980 0 25817 1 0x00000000
[25800.412266] ffff880007b43cc0 0000000000000086 ffff88003ba4c500 ffff880007b43fd8
[25800.412275] ffff880007b43fd8 ffff880007b43fd8 ffff880134c65c00 ffff88003ba4c500
[25800.412284] 000080d0ffffffff ffffffff81ca7c00 ffff88003ba4c500 ffffffff81ca7c04
[25800.412288] Call Trace:
[25800.412306] [<ffffffff81673759>] schedule+0x29/0x70
[25800.412313] [<ffffffff81673a1e>] schedule_preempt_disabled+0xe/0x10
[25800.412323] [<ffffffff81672537>] __mutex_lock_slowpath+0xd7/0x150
[25800.412331] [<ffffffff8167200a>] mutex_lock+0x2a/0x50
[25800.412340] [<ffffffff8155ede1>] copy_net_ns+0x71/0x100
[25800.412350] [<ffffffff8107adfb>] create_new_namespaces+0xdb/0x190
[25800.412357] [<ffffffff8107afec>] copy_namespaces+0x8c/0xd0
[25800.412367] [<ffffffff81050142>] copy_process.part.22+0x902/0x1520
[25800.412375] [<ffffffff81050ee5>] do_fork+0x135/0x390
[25800.412385] [<ffffffff8116db40>] ? kmem_cache_free+0x20/0x100
[25800.412395] [<ffffffff8118c6b3>] ? putname+0x33/0x50
[25800.412402] [<ffffffff811811cc>] ? do_sys_open+0x16c/0x200
[25800.412410] [<ffffffff8101c238>] sys_clone+0x28/0x30
[25800.412418] [<ffffffff8167cbf3>] stub_clone+0x13/0x20
[25800.412424] [<ffffffff8167c8e9>] ? system_call_fastpath+0x16/0x1b
[25806.312385] unregister_netdevice: waiting for lo to become free. Usage count = 1

ProblemType: Bug
DistroRelease: Ubuntu 12.10
Package: linux-image-generic 3.5.0.3.3
ProcVersionSignature: Ubuntu 3.5.0-2.2-generic 3.5.0-rc4
Uname: Linux 3.5.0-2-generic x86_64
NonfreeKernelModules: nvidia wl
AlsaVersion: Advanced Linux Sound Architecture Driver Version 1.0.25.
ApportVersion: 2.2.5-0ubuntu2
Architecture: amd64
ArecordDevices:
**** List of CAPTURE Hardware Devices ****
card 0: NVidia [HDA NVidia], device 0: Cirrus Analog [Cirrus Analog]
Subdevices: 1/1
Subdevice #0: subdevice #0
AudioDevicesInUse:
USER PID ACCESS COMMAND
/dev/snd/controlC0: laney 2787 F.... pulseaudio
CRDA: Error: command ['iw', 'reg', 'get'] failed with exit code 1: nl80211 not found.
Card0.Amixer.info:
Card hw:0 'NVidia'/'HDA NVidia at 0xd3480000 irq 22'
Mixer name : 'Nvidia MCP89 HDMI'
Components : 'HDA:10134206,106b0d00,00100301 HDA:10de000c,10de0101,00100200'
Controls : 37
Simple ctrls : 13
Date: Thu Jul 5 21:26:08 2012
HibernationDevice: RESUME=UUID=1c5b3f2c-2c89-4fa1-9ed8-0e238de8fe47
InstallationMedia: Ubuntu 10.04.1 LTS "Lucid Lynx" - Release amd64 (20100729)
MachineType: Apple Inc. MacBookPro7,1
ProcFB: 0 VESA VGA
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.5.0-2-generic root=UUID=2228fdfe-3834-40b2-b7b4-efea7463e3c1 ro quiet splash reboot=pci vt.handoff=7
RelatedPackageVersions:
linux-restricted-modules-3.5.0-2-generic N/A
linux-backports-modules-3.5.0-2-generic N/A
linux-firmware 1.82
SourcePackage: linux
UpgradeStatus: Upgraded to quantal on 2012年01月13日 (173 days ago)
dmi.bios.date: 03/25/10
dmi.bios.vendor: Apple Inc.
dmi.bios.version: MBP71.88Z.0039.B05.1003251322
dmi.board.name: Mac-F222BEC8
dmi.board.vendor: Apple Inc.
dmi.chassis.type: 10
dmi.chassis.vendor: Apple Inc.
dmi.chassis.version: Mac-F222BEC8
dmi.modalias: dmi:bvnAppleInc.:bvrMBP71.88Z.0039.B05.1003251322:bd03/25/10:svnAppleInc.:pnMacBookPro7,1:pvr1.0:rvnAppleInc.:rnMac-F222BEC8:rvr:cvnAppleInc.:ct10:cvrMac-F222BEC8:
dmi.product.name: MacBookPro7,1
dmi.product.version: 1.0
dmi.sys.vendor: Apple Inc.

See original description

Tags:

Related branches

lp:ubuntu/quantal-proposed/linux-lowlatency

lp:ubuntu/quantal-proposed/linux-ti-omap4

lp:ubuntu/precise-proposed/linux-lts-quantal

CVE References

Revision history for this message

Iain Lane (laney) wrote on 2012年07月05日: #1

AcpiTables.txt Edit (135.5 KiB, text/plain; charset="utf-8")
AlsaDevices.txt Edit (761 bytes, text/plain; charset="utf-8")
AplayDevices.txt Edit (583 bytes, text/plain; charset="utf-8")
BootDmesg.txt Edit (59.0 KiB, text/plain; charset="utf-8")
Card0.Amixer.values.txt Edit (2.4 KiB, text/plain; charset="utf-8")
Card0.Codecs.codec.0.txt Edit (8.8 KiB, text/plain; charset="utf-8")
Card0.Codecs.codec.3.txt Edit (1.2 KiB, text/plain; charset="utf-8")
Card0.Codecs.codec.4.txt Edit (1.2 KiB, text/plain; charset="utf-8")
Card0.Codecs.codec.5.txt Edit (1.2 KiB, text/plain; charset="utf-8")
CurrentDmesg.txt Edit (107.0 KiB, text/plain; charset="utf-8")
Dependencies.txt Edit (2.0 KiB, text/plain; charset="utf-8")
IwConfig.txt Edit (638 bytes, text/plain; charset="utf-8")
Lspci.txt Edit (13.9 KiB, text/plain; charset="utf-8")
Lsusb.txt Edit (674 bytes, text/plain; charset="utf-8")
PciMultimedia.txt Edit (589 bytes, text/plain; charset="utf-8")
ProcCpuinfo.txt Edit (1.5 KiB, text/plain; charset="utf-8")
ProcEnviron.txt Edit (297 bytes, text/plain; charset="utf-8")
ProcInterrupts.txt Edit (1.6 KiB, text/plain; charset="utf-8")
ProcModules.txt Edit (5.3 KiB, text/plain; charset="utf-8")
PulseList.txt Edit (23.1 KiB, text/plain; charset="utf-8")
RfKill.txt Edit (117 bytes, text/plain; charset="utf-8")
UdevDb.txt Edit (141.2 KiB, text/plain; charset="utf-8")
UdevLog.txt Edit (325.6 KiB, text/plain; charset="utf-8")
WifiSyslog.txt Edit (307.4 KiB, text/plain; charset="utf-8")

summary: - lxc-start no longer starts containers
+ lxc-start sometimes stops starting containers

Iain Lane (laney) on 2012年07月05日

summary: - lxc-start sometimes stops starting containers
+ 'stuck on mutex_lock creating a new network namespace when starting a
+ container

summary: - 'stuck on mutex_lock creating a new network namespace when starting a
+ stuck on mutex_lock creating a new network namespace when starting a
container

Brad Figg (brad-figg) on 2012年07月05日

Changed in linux (Ubuntu):

status: New → Confirmed

Revision history for this message

Bryan Wu (cooloney) wrote on 2012年07月06日: Re: stuck on mutex_lock creating a new network namespace when starting a container #2

Can you tell us how to reproduce this issue?

From the dmesg kernel warning opps, I think it is not lxc/cgroups specific issue. Looks like lxc-start was blocked by some stuff for a long time. Is there any heavy workload on your system?

Thanks,
-Bryan

Changed in linux (Ubuntu):

importance: Undecided → Medium

assignee: nobody → Bryan Wu (cooloney)

Revision history for this message

Iain Lane (laney) wrote on 2012年07月06日: #3

Sorry, I don't yet have a recipe for reproducing it.

I did manage to get the system into the broken state again after I filed this bug report by suspending/resuming and starting/stopping/using containers as usual, but I can't trigger it on demand.

As for heavy load: not at the point it breaks. The main container I use is one I'm working on some Launchpad changes in. I often run the test suite inside it, and I guess that is rather heavy.

Revision history for this message

Bryan Wu (cooloney) wrote on 2012年07月10日: #4

hmmm, that's very hard for us to analyze. We did meet a similar oops before because of the heavy workload and CFQ block IO scheduler. Could you a test for us? change your default Block IO scheduler from CFQ to deadline and run LXC as usual to verify this issue is gone. I'm just guess and hope this can do some help.

-Bryan

Changed in linux (Ubuntu):

status: Confirmed → Incomplete

Revision history for this message

Stéphane Graber (stgraber) wrote on 2012年07月19日: #5

Download full text (6.6 KiB)

Not much luck reproducing at the moment with an up to date quantal, though running using the deadline scheduler with two containers rebooting in a loop, I eventually hit that:

Jul 19 07:22:34 lantea kernel: [46965.795778] ---[ end trace c212400a9b13d700 ]---
Jul 19 07:22:35 lantea kernel: [46965.809353] general protection fault: 0000 [#2] SMP
Jul 19 07:22:35 lantea kernel: [46965.812019] Modules linked in: veth ipt_MASQUERADE iptable_nat nf_nat nf_conntrack_ipv4 nf_conntrack nf_defrag_ipv4 ip_tables x_tables 8021q garp bridge stp llc snd_hda_codec_realtek snd_hda_intel snd_hda_codec snd_hwdep snd_pcm coretemp microcode snd_seq_midi snd_rawmidi psmouse serio_raw snd_seq_midi_event lpc_ich snd_seq snd_timer snd_seq_device i915 bonding rfcomm bnep bluetooth parport_pc ppdev mac_hid snd drm_kms_helper drm i2c_algo_bit soundcore snd_page_alloc video lp parport hid_generic usbhid hid r8169 floppy
Jul 19 07:22:35 lantea kernel: [46965.812019]
Jul 19 07:22:35 lantea kernel: [46965.812019] Pid: 11839, comm: initctl Tainted: G D 3.5.0-5-generic #5-Ubuntu /945GSE
Jul 19 07:22:35 lantea kernel: [46965.812019] EIP: 0060:[<c154bdf3>] EFLAGS: 00010286 CPU: 0
Jul 19 07:22:35 lantea kernel: [46965.812019] EIP is at unix_destruct_scm+0x53/0x90
Jul 19 07:22:35 lantea kernel: [46965.812019] EAX: 00000000 EBX: f71740c0 ECX: ffffffff EDX: 00000000
Jul 19 07:22:35 lantea kernel: [46965.812019] ESI: e0a828c8 EDI: f71740c0 EBP: e0a89adc ESP: e0a89abc
Jul 19 07:22:35 lantea kernel: [46965.812019] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
Jul 19 07:22:35 lantea kernel: [46965.812019] CR0: 80050033 CR2: b7606fb8 CR3: 01968000 CR4: 000007e0
Jul 19 07:22:35 lantea kernel: [46965.812019] DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
Jul 19 07:22:35 lantea kernel: [46965.812019] DR6: ffff0ff0 DR7: 00000400
Jul 19 07:22:35 lantea kernel: [46965.812019] Process initctl (pid: 11839, ti=e0a88000 task=f34e6580 task.ti=e0a88000)
Jul 19 07:22:35 lantea kernel: [46965.812019] Stack:
Jul 19 07:22:35 lantea kernel: [46965.812019] 00000000 ffffffff 00000000 00000000 00000000 00000000 00000000 f71740c0
Jul 19 07:22:35 lantea kernel: [46965.812019] e0a89ae8 c14c45d3 f71740c0 e0a89af4 c14c43d0 00000001 e0a89b0c c14c4486
Jul 19 07:22:35 lantea kernel: [46965.812019] c154bc6f 00000001 e0a828c8 f71740c0 e0a89b38 c154bc6f 00000000 e0a80ae0
Jul 19 07:22:35 lantea kernel: [46965.812019] Call Trace:
Jul 19 07:22:35 lantea kernel: [46965.812019] [<c14c45d3>] skb_release_head_state+0x43/0xc0
Jul 19 07:22:35 lantea kernel: [46965.812019] [<c14c43d0>] __kfree_skb+0x10/0x90
Jul 19 07:22:35 lantea kernel: [46965.812019] [<c14c4486>] kfree_skb+0x36/0x80
Jul 19 07:22:35 lantea kernel: [46965.812019] [<c154bc6f>] ? unix_release_sock+0x13f/0x240
Jul 19 07:22:35 lantea kernel: [46965.812019] [<c154bc6f>] unix_release_sock+0x13f/0x240
Jul 19 07:22:35 lantea kernel: [46965.812019] [<c154bd8f>] unix_release+0x1f/0x30
Jul 19 07:22:35 lantea kernel: [46965.812019] [<c14bc4e0>] sock_release+0x20/0x70
Jul 19 07:22:35 lantea kernel: [46965.812019] [<c14bc547>] sock_close+0x17/0x30
Jul 19 07:22:35 lantea kernel: [46965.812019] [<c114ff76>] fput+0xe6/0x210
Jul 19 07:22:35 lan...

Not much luck reproducing at the moment with an up to date quantal, though running using the deadline scheduler with two containers rebooting in a loop, I eventually hit that:
Jul 19 07:22:34 lantea kernel: [46965.795778] ---[ end trace c212400a9b13d700 ]---
Jul 19 07:22:35 lantea kernel: [46965.809353] general protection fault: 0000 [#2] SMP
Jul 19 07:22:35 lantea kernel: [46965.812019] Modules linked in: veth ipt_MASQUERADE iptable_nat nf_nat nf_conntrack_ipv4 nf_conntrack nf_defrag_ipv4 ip_tables x_tables 8021q garp bridge stp llc snd_hda_codec_realtek snd_hda_intel snd_hda_codec snd_hwdep snd_pcm coretemp microcode snd_seq_midi snd_rawmidi psmouse serio_raw snd_seq_midi_event lpc_ich snd_seq snd_timer snd_seq_device i915 bonding rfcomm bnep bluetooth parport_pc ppdev mac_hid snd drm_kms_helper drm i2c_algo_bit soundcore snd_page_alloc video lp parport hid_generic usbhid hid r8169 floppy
Jul 19 07:22:35 lantea kernel: [46965.812019]
Jul 19 07:22:35 lantea kernel: [46965.812019] Pid: 11839, comm: initctl Tainted: G D 3.5.0-5-generic #5-Ubuntu /945GSE
Jul 19 07:22:35 lantea kernel: [46965.812019] EIP: 0060:[<c154bdf3>] EFLAGS: 00010286 CPU: 0
Jul 19 07:22:35 lantea kernel: [46965.812019] EIP is at unix_destruct_scm+0x53/0x90
Jul 19 07:22:35 lantea kernel: [46965.812019] EAX: 00000000 EBX: f71740c0 ECX: ffffffff EDX: 00000000
Jul 19 07:22:35 lantea kernel: [46965.812019] ESI: e0a828c8 EDI: f71740c0 EBP: e0a89adc ESP: e0a89abc
Jul 19 07:22:35 lantea kernel: [46965.812019] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
Jul 19 07:22:35 lantea kernel: [46965.812019] CR0: 80050033 CR2: b7606fb8 CR3: 01968000 CR4: 000007e0
Jul 19 07:22:35 lantea kernel: [46965.812019] DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
Jul 19 07:22:35 lantea kernel: [46965.812019] DR6: ffff0ff0 DR7: 00000400
Jul 19 07:22:35 lantea kernel: [46965.812019] Process initctl (pid: 11839, ti=e0a88000 task=f34e6580 task.ti=e0a88000)
Jul 19 07:22:35 lantea kernel: [46965.812019] Stack:
Jul 19 07:22:35 lantea kernel: [46965.812019] 00000000 ffffffff 00000000 00000000 00000000 00000000 00000000 f71740c0
Jul 19 07:22:35 lantea kernel: [46965.812019] e0a89ae8 c14c45d3 f71740c0 e0a89af4 c14c43d0 00000001 e0a89b0c c14c4486
Jul 19 07:22:35 lantea kernel: [46965.812019] c154bc6f 00000001 e0a828c8 f71740c0 e0a89b38 c154bc6f 00000000 e0a80ae0
Jul 19 07:22:35 lantea kernel: [46965.812019] Call Trace:
Jul 19 07:22:35 lantea kernel: [46965.812019] [<c14c45d3>] skb_release_head_state+0x43/0xc0
Jul 19 07:22:35 lantea kernel: [46965.812019] [<c14c43d0>] __kfree_skb+0x10/0x90
Jul 19 07:22:35 lantea kernel: [46965.812019] [<c14c4486>] kfree_skb+0x36/0x80
Jul 19 07:22:35 lantea kernel: [46965.812019] [<c154bc6f>] ? unix_release_sock+0x13f/0x240
Jul 19 07:22:35 lantea kernel: [46965.812019] [<c154bc6f>] unix_release_sock+0x13f/0x240
Jul 19 07:22:35 lantea kernel: [46965.812019] [<c154bd8f>] unix_release+0x1f/0x30
Jul 19 07:22:35 lantea kernel: [46965.812019] [<c14bc4e0>] sock_release+0x20/0x70
Jul 19 07:22:35 lantea kernel: [46965.812019] [<c14bc547>] sock_close+0x17/0x30
Jul 19 07:22:35 lantea kernel: [46965.812019] [<c114ff76>] fput+0xe6/0x210
Jul 19 07:22:35 lantea kernel: [46965.812019] [<c114c674>] filp_close+0x54/0x80
Jul 19 07:22:35 lantea kernel: [46965.812019] [<c1049ae5>] put_files_struct+0x75/0xc0
Jul 19 07:22:35 lantea kernel: [46965.812019] [<c1049bd6>] exit_files+0x46/0x60
Jul 19 07:22:35 lantea kernel: [46965.812019] [<c104a01a>] do_exit+0x14a/0x7a0
Jul 19 07:22:35 lantea kernel: [46965.812019] [<c104473f>] ? print_oops_end_marker+0x2f/0x40
Jul 19 07:22:35 lantea kernel: [46965.812019] [<c15c09dd>] oops_end+0x8d/0xd0
Jul 19 07:22:35 lantea kernel: [46965.812019] [<c10138d4>] die+0x54/0x80
Jul 19 07:22:35 lantea kernel: [46965.812019] [<c15c05d2>] do_general_protection+0x102/0x180
Jul 19 07:22:35 lantea kernel: [46965.812019] [<c1075f10>] ? default_wake_function+0x10/0x20
Jul 19 07:22:35 lantea kernel: [46965.812019] [<c115f822>] ? pollwake+0x62/0x70
Jul 19 07:22:35 lantea kernel: [46965.812019] [<c15c04d0>] ? do_trap+0xd0/0xd0
Jul 19 07:22:35 lantea kernel: [46965.812019] [<c15c0233>] error_code+0x67/0x6c
Jul 19 07:22:35 lantea kernel: [46965.812019] [<c154d2fb>] ? unix_stream_recvmsg+0x4eb/0x680
Jul 19 07:22:35 lantea kernel: [46965.812019] [<c1289713>] ? aa_revalidate_sk+0x83/0x90
Jul 19 07:22:35 lantea kernel: [46965.812019] [<c14bd54c>] sock_recvmsg+0xcc/0x100
Jul 19 07:22:35 lantea kernel: [46965.812019] [<c12c97b1>] ? _copy_from_user+0x41/0x60
Jul 19 07:22:35 lantea kernel: [46965.812019] [<c14c79cf>] ? verify_iovec+0x3f/0xb0
Jul 19 07:22:35 lantea kernel: [46965.812019] [<c14bd480>] ? sock_sendmsg_nosec+0xf0/0xf0
Jul 19 07:22:35 lantea kernel: [46965.812019] [<c14bcc70>] __sys_recvmsg+0x110/0x1d0
Jul 19 07:22:35 lantea kernel: [46965.812019] [<c14bd480>] ? sock_sendmsg_nosec+0xf0/0xf0
Jul 19 07:22:35 lantea kernel: [46965.812019] [<c107d7cf>] ? trigger_load_balance+0x4f/0x1c0
Jul 19 07:22:35 lantea kernel: [46965.812019] [<c10786c5>] ? __dequeue_entity+0x25/0x40
Jul 19 07:22:35 lantea kernel: [46965.812019] [<c101004c>] ? __switch_to+0xbc/0x260
Jul 19 07:22:35 lantea kernel: [46965.812019] [<c1072051>] ? finish_task_switch+0x41/0xc0
Jul 19 07:22:35 lantea kernel: [46965.812019] [<c14be93b>] sys_recvmsg+0x3b/0x60
Jul 19 07:22:35 lantea kernel: [46965.812019] [<c14bee3b>] sys_socketcall+0x28b/0x2d0
Jul 19 07:22:35 lantea kernel: [46965.812019] [<c15c675f>] sysenter_do_call+0x12/0x28
Jul 19 07:22:35 lantea kernel: [46965.812019] Code: e4 8b 53 20 89 45 e0 85 d2 74 0d 8d 45 e8 89 da e8 d3 ed ff ff 8b 45 e0 e8 bb 5d b1 ff 8b 4d e4 c7 45 e0 00 00 00 00 85 c9 74 11 <f0> ff 09 0f 94 c0 84 c0 74 07 89 c8 e8 0c fc b1 ff 8b 45 e8 c7 
Jul 19 07:22:35 lantea kernel: [46965.812019] EIP: [<c154bdf3>] unix_destruct_scm+0x53/0x90 SS:ESP 0068:e0a89abc
Jul 19 07:22:35 lantea kernel: [46966.536717] ---[ end trace c212400a9b13d701 ]---
Jul 19 07:22:35 lantea kernel: [46966.553450] Fixing recursive fault but reboot is needed!
Since then, "initctl" in the p1 container has been stuck in I/O wait (for 5 hours), only way to unblock it will be a reboot.
To reproduce I use two basic containers:
lxc-create -n p1 -t ubuntu
lxc-create -n p2 -t ubuntu
then used the following script as "/etc/init/test.conf" in both of them:
start on stopped rc RUNLEVEL=[2345]
exec reboot
Finally, I started them both in a screen session:
lxc-start -n p1
lxc-start -n p2
And let that run for the night, this morning I noticed that one of the two was stuck, because of that kernel oops.
On the same system I've been able to reproduce exactly the issue described by Iain, though not at the moment... I'll try with the default scheduler, see if that helps reproducing Iain's symptoms.

Revision history for this message

Stéphane Graber (stgraber) wrote on 2012年07月20日: #6

Download full text (7.1 KiB)

Restarted the same test with the default I/O scheduler and after a few hours, got the same crash again:

Jul 19 16:58:20 lantea kernel: [14707.004394] general protection fault: 0000 [#1] SMP
Jul 19 16:58:20 lantea kernel: [14707.008026]
Jul 19 16:58:20 lantea kernel: [14707.008026] Pid: 20505, comm: dbus-daemon Not tainted 3.5.0-5-generic #5-Ubuntu /945GSE
Jul 19 16:58:20 lantea kernel: [14707.008026] EIP: 0060:[<c154d2fb>] EFLAGS: 00010286 CPU: 0
Jul 19 16:58:20 lantea kernel: [14707.008026] EIP is at unix_stream_recvmsg+0x4eb/0x680
Jul 19 16:58:20 lantea kernel: [14707.008026] EAX: 00000000 EBX: f28cc180 ECX: f18f1d40 EDX: ffffffff
Jul 19 16:58:20 lantea kernel: [14707.008026] ESI: 00000000 EDI: edd6c240 EBP: f18f1d68 ESP: f18f1ccc
Jul 19 16:58:20 lantea kernel: [14707.008026] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
Jul 19 16:58:20 lantea kernel: [14707.008026] CR0: 80050033 CR2: b7702130 CR3: 318d6000 CR4: 000007e0
Jul 19 16:58:20 lantea kernel: [14707.008026] DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
Jul 19 16:58:20 lantea kernel: [14707.008026] DR6: ffff0ff0 DR7: 00000400
Jul 19 16:58:20 lantea kernel: [14707.008026] Process dbus-daemon (pid: 20505, ti=f18f0000 task=f48dd8d0 task.ti=f18f0000)
Jul 19 16:58:20 lantea kernel: [14707.008026] Stack:
Jul 19 16:58:20 lantea kernel: [14707.008026] c15bfa3d f18f1cdc ffffffff edd6e688 f18f1d40 c14c419c f48dd8d0 f48dd8d0
Jul 19 16:58:20 lantea kernel: [14707.008026] 00000000 00000000 edd6c3f8 00000000 00000001 00000000 f18f1d7c edd6c288
Jul 19 16:58:20 lantea kernel: [14707.008026] 00000000 00000000 ec7ff500 f18f1f4c 00000000 edd6c420 00000000 f4acd400
Jul 19 16:58:20 lantea kernel: [14707.008026] Call Trace:
Jul 19 16:58:20 lantea kernel: [14707.008026] [<c15bfa3d>] ? _raw_spin_lock_irqsave+0x2d/0x40
Jul 19 16:58:20 lantea kernel: [14707.008026] [<c14c419c>] ? skb_queue_tail+0x3c/0x50
Jul 19 16:58:20 lantea kernel: [14707.008026] [<c1289713>] ? aa_revalidate_sk+0x83/0x90
Jul 19 16:58:20 lantea kernel: [14707.008026] [<c14bd54c>] sock_recvmsg+0xcc/0x100
Jul 19 16:58:20 lantea kernel: [14707.008026] [<c115f7c0>] ? __pollwait+0xd0/0xd0
Jul 19 16:58:20 lantea kernel: [14707.008026] [<c12c97b1>] ? _copy_from_user+0x41/0x60
Jul 19 16:58:20 lantea kernel: [14707.008026] [<c14c79cf>] ? verify_iovec+0x3f/0xb0
Jul 19 16:58:20 lantea kernel: [14707.008026] [<c14bd480>] ? sock_sendmsg_nosec+0xf0/0xf0
Jul 19 16:58:20 lantea kernel: [14707.008026] [<c14bcc70>] __sys_recvmsg+0x110/0x1d0
Jul 19 16:58:20 lantea kernel: [14707.008026] [<c14bd480>] ? sock_sendmsg_nosec+0xf0/0xf0
Jul 19 16:58:20 lantea kernel: [14707.008026] [<c107d7cf>] ? trigger_load_balance+0x4f/0x1c0
Jul 19 16:58:20 lantea kernel: [14707.008026] [<c1074d7a>] ? scheduler_tick+0xda/0x100
Jul 19 16:58:20 lantea kernel: [14707.008026] [<c12c5038>] ? timerqueue_add+0x58/0xb0
Jul 19 16:58:20 lantea kernel: [14707.008026] [<c1090255>] ? ktime_get+0x65/0xf0
Jul 19 16:58:20 lantea kernel: [14707.008026] [<c102cbab>] ? lapic_next_event+0x1b/0x20
Jul 19 16:58:20 lantea kernel: [14707.008026] [<c14be93b>] sys_recvmsg+0x3b/0x60
Jul 19 16:58:20 lantea kernel: [14707.008026] [<c14bee3b>] sys_socketcall+0x28b/0x2d0
Ju...

Restarted the same test with the default I/O scheduler and after a few hours, got the same crash again:
Jul 19 16:58:20 lantea kernel: [14707.004394] general protection fault: 0000 [#1] SMP 
Jul 19 16:58:20 lantea kernel: [14707.008026] 
Jul 19 16:58:20 lantea kernel: [14707.008026] Pid: 20505, comm: dbus-daemon Not tainted 3.5.0-5-generic #5-Ubuntu /945GSE
Jul 19 16:58:20 lantea kernel: [14707.008026] EIP: 0060:[<c154d2fb>] EFLAGS: 00010286 CPU: 0
Jul 19 16:58:20 lantea kernel: [14707.008026] EIP is at unix_stream_recvmsg+0x4eb/0x680
Jul 19 16:58:20 lantea kernel: [14707.008026] EAX: 00000000 EBX: f28cc180 ECX: f18f1d40 EDX: ffffffff
Jul 19 16:58:20 lantea kernel: [14707.008026] ESI: 00000000 EDI: edd6c240 EBP: f18f1d68 ESP: f18f1ccc
Jul 19 16:58:20 lantea kernel: [14707.008026] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
Jul 19 16:58:20 lantea kernel: [14707.008026] CR0: 80050033 CR2: b7702130 CR3: 318d6000 CR4: 000007e0
Jul 19 16:58:20 lantea kernel: [14707.008026] DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
Jul 19 16:58:20 lantea kernel: [14707.008026] DR6: ffff0ff0 DR7: 00000400
Jul 19 16:58:20 lantea kernel: [14707.008026] Process dbus-daemon (pid: 20505, ti=f18f0000 task=f48dd8d0 task.ti=f18f0000)
Jul 19 16:58:20 lantea kernel: [14707.008026] Stack:
Jul 19 16:58:20 lantea kernel: [14707.008026] c15bfa3d f18f1cdc ffffffff edd6e688 f18f1d40 c14c419c f48dd8d0 f48dd8d0
Jul 19 16:58:20 lantea kernel: [14707.008026] 00000000 00000000 edd6c3f8 00000000 00000001 00000000 f18f1d7c edd6c288
Jul 19 16:58:20 lantea kernel: [14707.008026] 00000000 00000000 ec7ff500 f18f1f4c 00000000 edd6c420 00000000 f4acd400
Jul 19 16:58:20 lantea kernel: [14707.008026] Call Trace:
Jul 19 16:58:20 lantea kernel: [14707.008026] [<c15bfa3d>] ? _raw_spin_lock_irqsave+0x2d/0x40
Jul 19 16:58:20 lantea kernel: [14707.008026] [<c14c419c>] ? skb_queue_tail+0x3c/0x50
Jul 19 16:58:20 lantea kernel: [14707.008026] [<c1289713>] ? aa_revalidate_sk+0x83/0x90
Jul 19 16:58:20 lantea kernel: [14707.008026] [<c14bd54c>] sock_recvmsg+0xcc/0x100
Jul 19 16:58:20 lantea kernel: [14707.008026] [<c115f7c0>] ? __pollwait+0xd0/0xd0
Jul 19 16:58:20 lantea kernel: [14707.008026] [<c12c97b1>] ? _copy_from_user+0x41/0x60
Jul 19 16:58:20 lantea kernel: [14707.008026] [<c14c79cf>] ? verify_iovec+0x3f/0xb0
Jul 19 16:58:20 lantea kernel: [14707.008026] [<c14bd480>] ? sock_sendmsg_nosec+0xf0/0xf0
Jul 19 16:58:20 lantea kernel: [14707.008026] [<c14bcc70>] __sys_recvmsg+0x110/0x1d0
Jul 19 16:58:20 lantea kernel: [14707.008026] [<c14bd480>] ? sock_sendmsg_nosec+0xf0/0xf0
Jul 19 16:58:20 lantea kernel: [14707.008026] [<c107d7cf>] ? trigger_load_balance+0x4f/0x1c0
Jul 19 16:58:20 lantea kernel: [14707.008026] [<c1074d7a>] ? scheduler_tick+0xda/0x100
Jul 19 16:58:20 lantea kernel: [14707.008026] [<c12c5038>] ? timerqueue_add+0x58/0xb0
Jul 19 16:58:20 lantea kernel: [14707.008026] [<c1090255>] ? ktime_get+0x65/0xf0
Jul 19 16:58:20 lantea kernel: [14707.008026] [<c102cbab>] ? lapic_next_event+0x1b/0x20
Jul 19 16:58:20 lantea kernel: [14707.008026] [<c14be93b>] sys_recvmsg+0x3b/0x60
Jul 19 16:58:20 lantea kernel: [14707.008026] [<c14bee3b>] sys_socketcall+0x28b/0x2d0
Jul 19 16:58:20 lantea kernel: [14707.008026] [<c15c6f6e>] ? smp_apic_timer_interrupt+0x5e/0x8d
Jul 19 16:58:20 lantea kernel: [14707.008026] [<c1064a28>] ? sys_clock_gettime+0x48/0x70
Jul 19 16:58:20 lantea kernel: [14707.008026] [<c15c675f>] sysenter_do_call+0x12/0x28
Jul 19 16:58:20 lantea kernel: [14707.008026] Code: 6c ff ff ff 89 8d 74 ff ff ff 74 03 f0 ff 00 8b 95 74 ff ff ff 89 02 8b 95 6c ff ff ff 85 d2 0f 84 2d 01 00 00 8b 95 6c ff ff ff <f0> ff 02 89 55 84 8b 55 84 8b 8d 74 ff ff ff 89 51 04 8b 95 6c 
Jul 19 16:58:20 lantea kernel: [14707.008026] EIP: [<c154d2fb>] unix_stream_recvmsg+0x4eb/0x680 SS:ESP 0068:f18f1ccc
Jul 19 16:58:20 lantea kernel: [14707.537680] ---[ end trace 8455671fd435d7f5 ]---
Jul 19 16:58:21 lantea kernel: [14707.548025] [<c1049ae5>] put_files_struct+0x75/0xc0
Jul 19 16:58:21 lantea kernel: [14707.548025] [<c1049bd6>] exit_files+0x46/0x60
Jul 19 16:58:21 lantea kernel: [14707.548025] [<c104a01a>] do_exit+0x14a/0x7a0
Jul 19 16:58:21 lantea kernel: [14707.548025] [<c104473f>] ? print_oops_end_marker+0x2f/0x40
Jul 19 16:58:21 lantea kernel: [14707.548025] [<c15c09dd>] oops_end+0x8d/0xd0
Jul 19 16:58:21 lantea kernel: [14707.548025] [<c10138d4>] die+0x54/0x80
Jul 19 16:58:21 lantea kernel: [14707.548025] [<c15c05d2>] do_general_protection+0x102/0x180
Jul 19 16:58:21 lantea kernel: [14707.548025] [<c113e61c>] ? kfree+0xcc/0xf0
Jul 19 16:58:21 lantea kernel: [14707.548025] [<c14c3135>] ? skb_free_head+0x45/0x50
Jul 19 16:58:21 lantea kernel: [14707.548025] [<c15c04d0>] ? do_trap+0xd0/0xd0
Jul 19 16:58:21 lantea kernel: [14707.548025] [<c15c0233>] error_code+0x67/0x6c
Jul 19 16:58:21 lantea kernel: [14707.548025] [<c14c007b>] ? proto_register+0x19b/0x210
Jul 19 16:58:21 lantea kernel: [14707.548025] [<c154d2fb>] ? unix_stream_recvmsg+0x4eb/0x680
Jul 19 16:58:21 lantea kernel: [14707.548025] [<c15bfa3d>] ? _raw_spin_lock_irqsave+0x2d/0x40
Jul 19 16:58:21 lantea kernel: [14707.548025] [<c14c419c>] ? skb_queue_tail+0x3c/0x50
Jul 19 16:58:21 lantea kernel: [14707.548025] [<c1289713>] ? aa_revalidate_sk+0x83/0x90
Jul 19 16:58:21 lantea kernel: [14707.548025] [<c14bd54c>] sock_recvmsg+0xcc/0x100
Jul 19 16:58:21 lantea kernel: [14707.548025] [<c115f7c0>] ? __pollwait+0xd0/0xd0
Jul 19 16:58:21 lantea kernel: [14707.548025] [<c12c97b1>] ? _copy_from_user+0x41/0x60
Jul 19 16:58:21 lantea kernel: [14707.548025] [<c14c79cf>] ? verify_iovec+0x3f/0xb0
Jul 19 16:58:21 lantea kernel: [14707.548025] [<c14bd480>] ? sock_sendmsg_nosec+0xf0/0xf0
Jul 19 16:58:21 lantea kernel: [14707.548025] [<c14bcc70>] __sys_recvmsg+0x110/0x1d0
Jul 19 16:58:21 lantea kernel: [14707.548025] [<c14bd480>] ? sock_sendmsg_nosec+0xf0/0xf0
Jul 19 16:58:21 lantea kernel: [14707.548025] [<c107d7cf>] ? trigger_load_balance+0x4f/0x1c0
Jul 19 16:58:21 lantea kernel: [14707.548025] [<c1074d7a>] ? scheduler_tick+0xda/0x100
Jul 19 16:58:21 lantea kernel: [14707.548025] [<c12c5038>] ? timerqueue_add+0x58/0xb0
Jul 19 16:58:21 lantea kernel: [14707.548025] [<c1090255>] ? ktime_get+0x65/0xf0
Jul 19 16:58:21 lantea kernel: [14707.548025] [<c102cbab>] ? lapic_next_event+0x1b/0x20
Jul 19 16:58:21 lantea kernel: [14707.548025] [<c14be93b>] sys_recvmsg+0x3b/0x60
Jul 19 16:58:21 lantea kernel: [14707.548025] [<c14bee3b>] sys_socketcall+0x28b/0x2d0
Jul 19 16:58:21 lantea kernel: [14707.548025] [<c15c6f6e>] ? smp_apic_timer_interrupt+0x5e/0x8d
Jul 19 16:58:21 lantea kernel: [14707.548025] [<c1064a28>] ? sys_clock_gettime+0x48/0x70
Jul 19 16:58:21 lantea kernel: [14707.548025] [<c15c675f>] sysenter_do_call+0x12/0x28
Jul 19 16:58:21 lantea kernel: [14707.548025] Code: e4 8b 53 20 89 45 e0 85 d2 74 0d 8d 45 e8 89 da e8 d3 ed ff ff 8b 45 e0 e8 bb 5d b1 ff 8b 4d e4 c7 45 e0 00 00 00 00 85 c9 74 11 <f0> ff 09 0f 94 c0 84 c0 74 07 89 c8 e8 0c fc b1 ff 8b 45 e8 c7 
Jul 19 16:58:21 lantea kernel: [14707.548025] EIP: [<c154bdf3>] unix_destruct_scm+0x53/0x90 SS:ESP 0068:f18f1abc
Jul 19 16:58:21 lantea kernel: [14708.492593] ---[ end trace 8455671fd435d7f6 ]---
Jul 19 16:58:21 lantea kernel: [14708.492613] Fixing recursive fault but reboot is needed!

Revision history for this message

Stéphane Graber (stgraber) wrote on 2012年07月20日: #7

I'm quite surprised that with all of these tests I haven't got the mutex_lock bug again though, it was definitely happening on that machine... maybe some other fixes fixed it or I'm just not exercising the exact code path that's triggering it.

Revision history for this message

Clint Byrum (clint-fewbar) wrote on 2012年08月16日: #8

Download full text (4.8 KiB)

On my somewhat lagged quantal, I have been seeing similar issues:

Linux clint-MacBookPro 3.5.0-8-generic #8-Ubuntu SMP Sat Aug 4 04:42:28 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux

[194038.144050] unregister_netdevice: waiting for lo to become free. Usage count = 1
[194040.576173] INFO: task lxc-start:23872 blocked for more than 120 seconds.
[194040.576178] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[194040.576180] lxc-start D ffff88014fd13980 0 23872 1 0x00000000
[194040.576186] ffff880116909cc0 0000000000000086 ffff880090ad2e00 ffff880116909fd8
[194040.576192] ffff880116909fd8 ffff880116909fd8 ffff880144830000 ffff880090ad2e00
[194040.576197] ffff880116909cc0 ffffffff81ca91a0 ffff880090ad2e00 ffffffff81ca91a4
[194040.576202] Call Trace:
[194040.576212] [<ffffffff8167f519>] schedule+0x29/0x70
[194040.576217] [<ffffffff8167f7de>] schedule_preempt_disabled+0xe/0x10
[194040.576221] [<ffffffff8167e2f7>] __mutex_lock_slowpath+0xd7/0x150
[194040.576225] [<ffffffff8167ddca>] mutex_lock+0x2a/0x50
[194040.576230] [<ffffffff8156ab01>] copy_net_ns+0x71/0x100
[194040.576236] [<ffffffff8107b39b>] create_new_namespaces+0xdb/0x190
[194040.576239] [<ffffffff8107b58c>] copy_namespaces+0x8c/0xd0
[194040.576245] [<ffffffff81050112>] copy_process.part.22+0x902/0x1520
[194040.576249] [<ffffffff81050eb5>] do_fork+0x135/0x390
[194040.576254] [<ffffffff811820d5>] ? vfs_write+0x105/0x180
[194040.576258] [<ffffffff8101c2e8>] sys_clone+0x28/0x30
[194040.576263] [<ffffffff816889b3>] stub_clone+0x13/0x20
[194040.576267] [<ffffffff816886a9>] ? system_call_fastpath+0x16/0x1b
[194048.384149] unregister_netdevice: waiting for lo to become free. Usage count = 1
[194058.624071] unregister_netdevice: waiting for lo to become free. Usage count = 1
[194068.864079] unregister_netdevice: waiting for lo to become free. Usage count = 1
[194079.104158] unregister_netdevice: waiting for lo to become free. Usage count = 1
[194089.344152] unregister_netdevice: waiting for lo to become free. Usage count = 1
[194099.584105] unregister_netdevice: waiting for lo to become free. Usage count = 1
[194109.824044] unregister_netdevice: waiting for lo to become free. Usage count = 1
[194120.064158] unregister_netdevice: waiting for lo to become free. Usage count = 1
[194130.304148] unregister_netdevice: waiting for lo to become free. Usage count = 1
[194140.544146] unregister_netdevice: waiting for lo to become free. Usage count = 1
[194150.784065] unregister_netdevice: waiting for lo to become free. Usage count = 1
[194160.576246] INFO: task lxc-start:23872 blocked for more than 120 seconds.
[194160.576251] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[194160.576253] lxc-start D ffff88014fd13980 0 23872 1 0x00000000
[194160.576259] ffff880116909cc0 0000000000000086 ffff880090ad2e00 ffff880116909fd8
[194160.576265] ffff880116909fd8 ffff880116909fd8 ffff880144830000 ffff880090ad2e00
[194160.576270] ffff880116909cc0 ffffffff81ca91a0 ffff880090ad2e00 ffffffff81ca91a4
[194160.576275] Call Trace:
[194160.576286] [<ffffffff8167f519>] schedule+0x29/0x70
[194160.576290] [<ffffffff8167f7de>] sched...

On my somewhat lagged quantal, I have been seeing similar issues:
Linux clint-MacBookPro 3.5.0-8-generic #8-Ubuntu SMP Sat Aug 4 04:42:28 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
[194038.144050] unregister_netdevice: waiting for lo to become free. Usage count = 1
[194040.576173] INFO: task lxc-start:23872 blocked for more than 120 seconds.
[194040.576178] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[194040.576180] lxc-start D ffff88014fd13980 0 23872 1 0x00000000
[194040.576186] ffff880116909cc0 0000000000000086 ffff880090ad2e00 ffff880116909fd8
[194040.576192] ffff880116909fd8 ffff880116909fd8 ffff880144830000 ffff880090ad2e00
[194040.576197] ffff880116909cc0 ffffffff81ca91a0 ffff880090ad2e00 ffffffff81ca91a4
[194040.576202] Call Trace:
[194040.576212] [<ffffffff8167f519>] schedule+0x29/0x70
[194040.576217] [<ffffffff8167f7de>] schedule_preempt_disabled+0xe/0x10
[194040.576221] [<ffffffff8167e2f7>] __mutex_lock_slowpath+0xd7/0x150
[194040.576225] [<ffffffff8167ddca>] mutex_lock+0x2a/0x50
[194040.576230] [<ffffffff8156ab01>] copy_net_ns+0x71/0x100
[194040.576236] [<ffffffff8107b39b>] create_new_namespaces+0xdb/0x190
[194040.576239] [<ffffffff8107b58c>] copy_namespaces+0x8c/0xd0
[194040.576245] [<ffffffff81050112>] copy_process.part.22+0x902/0x1520
[194040.576249] [<ffffffff81050eb5>] do_fork+0x135/0x390
[194040.576254] [<ffffffff811820d5>] ? vfs_write+0x105/0x180
[194040.576258] [<ffffffff8101c2e8>] sys_clone+0x28/0x30
[194040.576263] [<ffffffff816889b3>] stub_clone+0x13/0x20
[194040.576267] [<ffffffff816886a9>] ? system_call_fastpath+0x16/0x1b
[194048.384149] unregister_netdevice: waiting for lo to become free. Usage count = 1
[194058.624071] unregister_netdevice: waiting for lo to become free. Usage count = 1
[194068.864079] unregister_netdevice: waiting for lo to become free. Usage count = 1
[194079.104158] unregister_netdevice: waiting for lo to become free. Usage count = 1
[194089.344152] unregister_netdevice: waiting for lo to become free. Usage count = 1
[194099.584105] unregister_netdevice: waiting for lo to become free. Usage count = 1
[194109.824044] unregister_netdevice: waiting for lo to become free. Usage count = 1
[194120.064158] unregister_netdevice: waiting for lo to become free. Usage count = 1
[194130.304148] unregister_netdevice: waiting for lo to become free. Usage count = 1
[194140.544146] unregister_netdevice: waiting for lo to become free. Usage count = 1
[194150.784065] unregister_netdevice: waiting for lo to become free. Usage count = 1
[194160.576246] INFO: task lxc-start:23872 blocked for more than 120 seconds.
[194160.576251] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[194160.576253] lxc-start D ffff88014fd13980 0 23872 1 0x00000000
[194160.576259] ffff880116909cc0 0000000000000086 ffff880090ad2e00 ffff880116909fd8
[194160.576265] ffff880116909fd8 ffff880116909fd8 ffff880144830000 ffff880090ad2e00
[194160.576270] ffff880116909cc0 ffffffff81ca91a0 ffff880090ad2e00 ffffffff81ca91a4
[194160.576275] Call Trace:
[194160.576286] [<ffffffff8167f519>] schedule+0x29/0x70
[194160.576290] [<ffffffff8167f7de>] schedule_preempt_disabled+0xe/0x10
[194160.576294] [<ffffffff8167e2f7>] __mutex_lock_slowpath+0xd7/0x150
[194160.576299] [<ffffffff8167ddca>] mutex_lock+0x2a/0x50
[194160.576304] [<ffffffff8156ab01>] copy_net_ns+0x71/0x100
[194160.576309] [<ffffffff8107b39b>] create_new_namespaces+0xdb/0x190
[194160.576313] [<ffffffff8107b58c>] copy_namespaces+0x8c/0xd0
[194160.576318] [<ffffffff81050112>] copy_process.part.22+0x902/0x1520
[194160.576322] [<ffffffff81050eb5>] do_fork+0x135/0x390
[194160.576327] [<ffffffff811820d5>] ? vfs_write+0x105/0x180
[194160.576332] [<ffffffff8101c2e8>] sys_clone+0x28/0x30
[194160.576337] [<ffffffff816889b3>] stub_clone+0x13/0x20
[194160.576341] [<ffffffff816886a9>] ? system_call_fastpath+0x16/0x1b
[194161.024151] unregister_netdevice: waiting for lo to become free. Usage count = 1
I've been creating/destroying a lot of LXC containers, so its possible the veth's created for them are causing some issues. I also have a ton of network-interface-security jobs running suggesting that they're being added but not removed:
network-interface-security (network-interface/vethx3SWbR) start/running
network-interface-security (network-interface/vethWUOSpt) start/running
network-interface-security (network-interface/veth90RDZM) start/running
network-interface-security (network-interface/vethCdnGSx) start/running
network-interface-security (network-interface/vetha8REFc) start/running
network-interface-security (network-interface/veth8yrXSC) start/running
network-interface-security (network-interface/vethvtEy9P) start/running
These issues are blocking some LXC work I'm doing, so I'm going to try upgrading which may take me out of the 'affected' category, so I've apt-cloned so we can get back to this state if need be:

Changed in linux (Ubuntu):

status: Incomplete → Confirmed

Revision history for this message

Jean-Baptiste Lallement (jibel) wrote on 2012年08月20日: #9

I can reproduce it very reliably on my system after shutting down an LXC container with poweroff from inside the container.
I'm setting to High because then the container cannot be started again without restarting the host system, and the host system won't shutdown waiting forever for lo to become free. Only SysRq helps in that case.

Changed in linux (Ubuntu):

importance: Medium → High

tags: added: rls-q-incoming

Revision history for this message

Stéphane Graber (stgraber) wrote on 2012年09月03日: #10

Looking around for this bug, after getting it myself a few more times... I found http://lists.debian.org/debian-kernel/2012/05/msg00494.html which mentions a similar behaviour.

I extracted the C example and built it: http://paste.ubuntu.com/1182799/

Running it, indeed triggered the issue here, any subsequent call to lxc-start will just hang.
When running lxc-start under strace, I'm getting:
stat("/home/stgraber/data/vm/lxc/lib/precise-gui-i386/rootfs", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
open("/home/stgraber/data/vm/lxc/lib/precise-gui-i386/rootfs.hold", O_RDWR|O_CREAT, 0600) = 17
clone(

So it looks like, whatever the issue is, it's triggering when trying to clone(CLONE_NEWNET).

Hope that helps point towards the right direction.

Changed in linux (Ubuntu):

status: Confirmed → Triaged

Revision history for this message

Stéphane Graber (stgraber) wrote on 2012年09月03日: #11

The last time I saw this happening was 5 minutes ago on a Lenovo x230 (no legacy BIOS), running:
Linux castiana 3.5.0-13-generic #14-Ubuntu SMP Wed Aug 29 16:48:44 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux

As Jean-Baptiste says, this bug is extremely annoying as anyone using LXC and hitting this bug (that part seems quite random) won't be able to work until they power cycle the system, would appreciate if someone could actually look at this.

Revision history for this message

Serge Hallyn (serge-hallyn) wrote on 2012年09月04日: Re: [Bug 1021471] Re: stuck on mutex_lock creating a new network namespace when starting a container #12

For some reason I've still never seen this.

Do you have a recipe by which, after a reboot, can you 100% reproduce
this?

Revision history for this message

Stéphane Graber (stgraber) wrote on 2012年09月04日: Re: stuck on mutex_lock creating a new network namespace when starting a container #13

The following seems pretty reliable to me:
- gcc reproducer.c -o reproducer (using the paste.ubuntu.com code above)
- sudo ./reproducer
- ctrl+c
- lxc-start -n <some-container>
- dmesg | grep unregister

It appears that reproducing it that way is very reliable here, though the result is slightly different. Using this reproducer, the container will usually hang at startup for a few minutes, then eventually succeed to boot.
When getting the bug without that reproducer, it'd usually hang indefinitely (where indefinitely > 10 minutes).

Joseph Salisbury (jsalisbury) on 2012年09月04日

tags: added: kernel-da-key kernel-key

Revision history for this message

Serge Hallyn (serge-hallyn) wrote on 2012年09月04日: #14

I have finally been able to reproduce this, but it takes me much longer than it does Stephane.

Revision history for this message

Dan Kegel (dank) wrote on 2012年09月04日: #15

I reproduced this on the first run of my lxc-ized buildbot setup script on a quantal host, so it's likely to hit real users.

Revision history for this message

Bryan Wu (cooloney) wrote on 2012年09月05日: #16

I can reproduce this as Stephane's mentioned, but I only got message like "unregister_netdevice: waiting for lo to become free. Usage count = 2". There is no other oops messages like mutex_lock() and I think the oops is because lxc-start was blocked for too long.

So probably the subject of this bug should be changed.

Revision history for this message

Bryan Wu (cooloney) wrote on 2012年09月05日: #17

After some testing, I think this is not a LXC specific issue. It's probably related to kernel CLONE_NEWNET code. Since if we run testing like this:
- sudo ./reproducer
- ctrl+c
- sudo ./reproducer
wait for a while
- dmesg | grep unregister

we can still get the same error message.

looks like the first try reproducer didn't release loopback device.

Revision history for this message

Stéphane Graber (stgraber) wrote on 2012年09月05日: #18

I update the bug title to better match what we're seeing.
The oops from the description is indeed just a timeout from some user space task that's stuck on clone().

So it looks like there's something wrong either in the cleanup code when flushing a network namespace (when the last process in the namespace dies) or something wrong with the refcount.

summary: - stuck on mutex_lock creating a new network namespace when starting a
- container
+ clone() hang when creating new network namespace (dmesg show
+ unregister_netdevice: waiting for lo to become free. Usage count = 2)

Revision history for this message

Bryan Wu (cooloney) wrote on 2012年09月07日: #19

I filed an upstream kernel bug: https://bugzilla.kernel.org/show_bug.cgi?id=47181

Leann Ogasawara (leannogasawara) on 2012年09月10日

Changed in linux (Ubuntu Quantal):

milestone: none → ubuntu-12.10-beta-2

tags: removed: rls-q-incoming

Revision history for this message

Bryan Wu (cooloney) wrote on 2012年09月10日: #20

As Eric W. Biederman said in the bugzilla, 3.6-rc1 mainline version works. I've testing our Ubuntu mainline build like 3.6-rc1 and 3.6-rc5, which all work fine. But for 3.5.3 mainline build, this test failed. Our latest Quantal kernel is based on 3.5.3 kernel.

So obviously this issue was fixed during 3.6-rc1, I'm going to do some investigation and backport those fixing patches.

-Bryan

Revision history for this message

Bryan Wu (cooloney) wrote on 2012年09月11日: #21

From Eric's reply, I found this issue is a little bit complex to backport some patches from 3.6-rc1, because from 3.5 to 3.6-rc1 some fundamental stuffs were changed.

--
As I recall the routing cache was removed between 3.5 and 3.6-rc1 so there are
some significant changes to the fundamentals.

What to look for failure of dev_hold and dev_put to pair.

The kernel configuration may play a role. I remember times when there was a
small bug in ipv6 multicast routing with respect to this. So a more minimal
configuration may not reproduce the problem.

I would also assume that the different reproducers exercise different code
paths
so you are probably dealing with more than one bug, between the ubuntu and the
debian bug trackers.

I hope those hints help.
--

But we won't use 3.6 kernel for our Quantal release.

Revision history for this message

Clint Byrum (clint-fewbar) wrote on 2012年09月25日: #22

I run into this bug daily, it severely cripples the juju local provider on quantal.

Revision history for this message

Tim Gardner (timg-tpi) wrote on 2012年09月26日: #23

Reassigning to Stefan.

Changed in linux (Ubuntu Quantal):

assignee: Bryan Wu (cooloney) → Stefan Bader (stefan-bader-canonical)

Revision history for this message

Stefan Bader (smb) wrote on 2012年09月26日: #24

Repeating the comment in the upstream bug I just made:

I added debugging to dev_hold and dev_put as Eric suggested and used the reproducer attached to this bug. What I saw was creation and destruction would be balanced. However on the connect call, there were another two dev_hold() calls that seem to be exactly those references not been returned.

system_call_fastpath+0x1a/0x1f
sys_connect+0xeb/0x110
inet_stream_connect+0x11c/0x310
tcp_v4_connect+0x13c/0x510
ip_route_connect+???/???
__ip_route_output_key+0x39a/0xb10
ip_route_output_slow
__mkroute_output
rt_dst_alloc+0x3e/0x40
dst_alloc+0xc5/0x1c0
+1 = 8
rt_set_nexthop.isra.45+0x131/0x2d0 ?
rt_intern_hash+0x133/0x670
rt_bind_neighbour+0x1d/0x40
ipv4_neigh_lookup+0xe7/0x120
neigh_create+0x1bd/0x5d0
+9

Unfortunately the stack traces miss the details about going into ip_route_connect, but with more printks I know that ip_route_output_flow() is the one failing with -EINVAL.
Comparing functions between 3.5 and current linux-HEAD I was not very successful in spotting the important difference.

Repeating the comment in the upstream bug I just made:
I added debugging to dev_hold and dev_put as Eric suggested and used the reproducer attached to this bug. What I saw was creation and destruction would be balanced. However on the connect call, there were another two dev_hold() calls that seem to be exactly those references not been returned.
system_call_fastpath+0x1a/0x1f
 sys_connect+0xeb/0x110
 inet_stream_connect+0x11c/0x310
 tcp_v4_connect+0x13c/0x510
 ip_route_connect+???/???
 __ip_route_output_key+0x39a/0xb10
 ip_route_output_slow
 __mkroute_output
 rt_dst_alloc+0x3e/0x40
 dst_alloc+0xc5/0x1c0
 +1 = 8
 rt_set_nexthop.isra.45+0x131/0x2d0 ?
 rt_intern_hash+0x133/0x670
 rt_bind_neighbour+0x1d/0x40
 ipv4_neigh_lookup+0xe7/0x120
 neigh_create+0x1bd/0x5d0
 +9
Unfortunately the stack traces miss the details about going into ip_route_connect, but with more printks I know that ip_route_output_flow() is the one failing with -EINVAL.
Comparing functions between 3.5 and current linux-HEAD I was not very successful in spotting the important difference.

Revision history for this message

Stefan Bader (smb) wrote on 2012年09月28日: #25

I guess I am at the limits of my knowledge. So far it looks like ip_connect_route initially calls __ip_route_output_key to fill in source and destination address. And this seems to cause a routing cache entry to be created with source and destination address 0.
It could be wrong to cache that or to create it with 0 addresses or both... I added all that info to the upstream bug in the hope of someone there knows details...

Revision history for this message

Stefan Bader (smb) wrote on 2012年10月01日: #26

0001-UBUNTU-net-ipv4-Do-not-create-routes-with-daddr-sadd.patch Edit (2.1 KiB, text/plain)

This is an experimental change that at least avoids the problem when running the test case. But while I saw no immediate problem, it isn't guaranteed to have no side effects and neither I can be sure there is not another case (only either source address or destination address not set) that would still suffer from the problem.
I added the same patch to the upstream bug report in the hope that this causes someone there to help with some information.

Ubuntu Foundations Team Bug Bot (crichton) on 2012年10月01日

tags: added: patch

Revision history for this message

Stefan Bader (smb) wrote on 2012年10月02日: #27

One observation I made while fiddling around with this a bit more. Running the test program, then abort it with ctrl-c starts the messages about lo having a refcount of 2. Trying to start the same test will hang on the first listen. That would indicate that something that still hold some required lock or mutex is still running (the tear down has not finished). This will end after a longer time (I have not measured but process blocked is triggered at least once). And after that time the test programs connect will work again. That could mean two things:
1. Cleanup did finally succeed
2. Cleanup was aborted, we leak the bits in the route cache but at least new net namespaces are possible.

As testing with lxc containers showed, the clever idea does not work there because that is a case where there is at least one of the addresses (actually it seems both) is set. So it more and more looks like the real problem is that whenever the namespace is to be torn down, there is nothing enforcing to immediately evicting and releasing elements in the route cache that belong to the interfaces in that namespace.
One observation I made while fiddling around with this a bit more. Running the test program, then abort it with ctrl-c starts the messages about lo having a refcount of 2. Trying to start the same test will hang on the first listen. That would indicate that something that still hold some required lock or mutex is still running (the tear down has not finished). This will end after a longer time (I have not measured but process blocked is triggered at least once). And after that time the test programs connect will work again. That could mean two things:
1. Cleanup did finally succeed
2. Cleanup was aborted, we leak the bits in the route cache but at least new net namespaces are possible.

Revision history for this message

Stefan Bader (smb) wrote on 2012年10月02日: #28

It seems that after about 5 minutes the references really get cleaned up without any change (so the question would be why that takes so long...

[ 44.099279] lo(ffff88003cc3c000)[0]+= 1
[ 44.099337] lo(ffff88003cc3c000)[0]+= 2
[ 44.099344] lo(ffff88003cc3c000)[0]+= 3
[ 44.099358] lo(ffff88003cc3c000)[0]+= 4
[ 44.099364] lo(ffff88003cc3c000)[0]+= 5
[ 44.099416] lo(ffff88003cc3c000)[0]+= 6
[ 44.099422] lo(ffff88003cc3c000)[0]+= 7
[ 44.099580] lo(ffff88003cc3c000)[0]+= 8
[ 44.099596] lo(ffff88003cc3c000)[0]+= 9
[ 46.728441] lo(ffff88003cc3c000)[1] -= -1
[ 46.728556] lo(ffff88003cc3c000)[1] -= -2
[ 46.728565] lo(ffff88003cc3c000)[1] -= -3
[ 46.729266] lo(ffff88003cc3c000)[1] -= -4
[ 46.729313] lo(ffff88003cc3c000)[1] -= -5
[ 46.729975] lo(ffff88003cc3c000)[1] -= -6
[ 46.732279] lo(ffff88003cc3c000)[1] -= -7
[ 338.896671] lo(ffff88003cc3c000)[0] -= 8
[ 338.896677] lo(ffff88003cc3c000)[0] -= 7

Revision history for this message

Stefan Bader (smb) wrote on 2012年10月02日: #29

This second attempt goes the path of forcing the route cache to be cleaned of entries belonging to a net device that is torn down.

Revision history for this message

Stefan Bader (smb) wrote on 2012年10月02日: #30

0001-UBUNTU-SAUCE-net-flush-rt-cache-on-unregister.patch Edit (1.4 KiB, text/plain)

When looking at the patch uploaded I realized something went wrong on the update. Re-attaching.

Revision history for this message

Stefan Bader (smb) wrote on 2012年10月04日: #31

Iteration step 3 Edit (1.9 KiB, text/plain)

Another step towards solving this. After it turned out in the upstream discussions that actually the route cache should be flushed when unregistering by doing the NETDEV_UNREGISTER_BATCH notify call, I could check to find out that this fails because the notify handler checks for dereferenced pointer that is not only not set but also not really necessary. Moving the handler around a bit should actually fix this.

Bug Watch Updater (bug-watch-updater) on 2012年10月04日

Changed in linux:

importance: Unknown → High

status: Unknown → Confirmed

Revision history for this message

Clint Byrum (clint-fewbar) wrote on 2012年10月04日: #32

syslog-with-#26-smb1.txt.gz Edit (284.2 KiB, text/plain)

Here is a syslog of the latest failure with the "#26+smb1" kernel showing refcount only stuck at 1, instead of 2

Leann Ogasawara (leannogasawara) on 2012年10月04日

Changed in linux (Ubuntu Quantal):

milestone: ubuntu-12.10-beta-2 → ubuntu-12.10

Revision history for this message

Stefan Bader (smb) wrote on 2012年10月05日: #33

Clint, could you please write down exactly which steps you do to reproduce the issue that leads to the single reference remaining? Which arguments to lxc-create/-start/-stop? Any special network setup?

I think that with the last patch I made we fixed one issue, though that (while easier to reproduce) is not the same as the case which leaves one reference and does not resolve itself over time. Now the other question is whether it will be possible to fix the other issue in time and on the other side whether adding the fix we already have on last minute, even though it does not completely fix things.

Revision history for this message

Clint Byrum (clint-fewbar) wrote on 2012年10月05日: #34

syslog-17.26+smb2.log.gz Edit (432.9 KiB, application/octet-stream)

Attaching syslog for latest fail.

BTW, the way I'm reproducing this is with a branch of juju that I've been working on:

You'll need this in ~/.juju/environments.yaml:

local:
type: local
control-bucket: puppies-kittens-goblins
admin-secret: abcdefghijklmnop0987654321
data-dir: /tmp/juju-data
default-series: precise
juju-origin: lp:~clint-fewbar/juju/local-cloud-img

mkdir /tmp/juju-data
bzr branch lp:~clint-fewbar/juju/local-cloud-img
cd local-cloud-img
export PYTHONPATH=$PWD
export PATH=$PWD/bin:$PATH
juju bootstrap -e local
juju deploy wordpress -e local
# wait for the wordpress service to have 'agent-state: started'
watch juju status
juju destroy-environment -e local
# unregister_netdevice messages now start spitting out on dmesg

Revision history for this message

Clint Byrum (clint-fewbar) wrote on 2012年10月05日: #35

The full environments.yaml, btw, should be

environments:
local:
type: local
control-bucket: puppies-kittens-goblins
admin-secret: abcdefghijklmnop0987654321
data-dir: /tmp/juju-data
default-series: precise
juju-origin: lp:~clint-fewbar/juju/local-cloud-img

Revision history for this message

Stefan Bader (smb) wrote on 2012年10月05日: #36

Certainly something is very wrong with the numbers. Looking at the numbers reported we get 5/13/-17/0 which sums up to 1 which is exactly the refcount complained about. But looking at the individual numbers, the counter for CPU#0 starts with 5 not 0.
And just adding up the dev_hold and dev_put calls I underrun down to -4. So it looks a bit like some magic suddenly warps the counter and we release more often than we appear to take the reference and still end up one too high.
It is a bit too late to think about it but maybe loopback gets assigned elements from another interface and that count is off by one.

Revision history for this message

Clint Byrum (clint-fewbar) wrote on 2012年10月05日: #37

repro.sh Edit (1.9 KiB, text/x-sh)

ok I can reproduce with just this shell script. The weird thing is, it only reproduces if I watch the log and kill the container after it fully boots.

cloud init will report that it is done booting like this:

cloud-init boot finished at 2012年10月05日 20:15:32 +0000. Up 200.15 seconds

if you run the script, and wait until you see that message, then press enter, which triggers stop/destroy, the bug will reproduce on 3.6.0 upstream kernel [1] as well as quantal's

[1] http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.6-quantal/

Revision history for this message

Clint Byrum (clint-fewbar) wrote on 2012年10月05日: #38

Ok, I think I'm ready to say that there are really just two bugs. One is about the route cache, and is addressed by smb's most recent patch. The other one seems only to affect my macbookair. I have not been able to get the repro.sh script to reproduce the problem on any other machines with that kernel or a 3.6 kernel installed.

Revision history for this message

Clint Byrum (clint-fewbar) wrote on 2012年10月05日: #39

Further information, this appears to be related to the wl proprietary drivers.

When I tried on my MacBookPro with wired network, the problem did not surface, but upon switching to wireless, the problem did surface.

This suggests that the real problem lies somewhere in the wl driver.

Tim Gardner (timg-tpi) on 2012年10月08日

Changed in linux (Ubuntu Quantal):

status: Triaged → Fix Committed

Revision history for this message

Stefan Bader (smb) wrote on 2012年10月08日: #40

Ok, it is probably obvious that we went ahead and applied at least the patch to the first half. Clint, probably we/you should open a second report for the remaining issue to have things cleanly separated.

Joseph Salisbury (jsalisbury) on 2012年10月09日

tags: removed: kernel-key

Revision history for this message

Launchpad Janitor (janitor) wrote on 2012年10月10日: #41

This bug was fixed in the package linux - 3.5.0-17.28

---------------
linux (3.5.0-17.28) quantal-proposed; urgency=low

[ Andy Whitcroft ]

* [packaging] we already have a valid src_pkg_name
* [packaging] allow us to select which builds have uefi signed versions

[ James M Leddy ]

* SAUCE: input: fix weird issue of synaptics psmouse sync lost after
resume
- LP: #717970

[ Paolo Pisati ]

* SAUCE: omap3 clocks .dev_id = NULL
- LP: #1061599
* [Config] omap: disable USB_[EHCI|OHCI]_HCD_PLATFORM
- LP: #1061599
* [Config] omap: enforce USB_[EHCI|OHCI]_HCD_PLATFORM=n
- LP: #1061599

[ Stefan Bader ]

* SAUCE: net/ipv4: Always flush route cache on unregister batch call
- LP: #1021471

[ Upstream Kernel Changes ]

* Bluetooth: Add USB_VENDOR_AND_INTERFACE_INFO() for Broadcom/Foxconn
- LP: #1030233

[ Wen-chien Jesse Sung ]

* SAUCE: Bluetooth: Remove rules for matching Broadcom vendor specific
IDs
- LP: #1030233
-- Leann Ogasawara <email address hidden> 2012年10月09日 11:23:41 -0700

This bug was fixed in the package linux - 3.5.0-17.28
---------------
linux (3.5.0-17.28) quantal-proposed; urgency=low
 [ Andy Whitcroft ]
 * [packaging] we already have a valid src_pkg_name
 * [packaging] allow us to select which builds have uefi signed versions
 [ James M Leddy ]
 * SAUCE: input: fix weird issue of synaptics psmouse sync lost after
 resume
 - LP: #717970
 [ Paolo Pisati ]
 * SAUCE: omap3 clocks .dev_id = NULL
 - LP: #1061599
 * [Config] omap: disable USB_[EHCI|OHCI]_HCD_PLATFORM
 - LP: #1061599
 * [Config] omap: enforce USB_[EHCI|OHCI]_HCD_PLATFORM=n
 - LP: #1061599
 [ Stefan Bader ]
 * SAUCE: net/ipv4: Always flush route cache on unregister batch call
 - LP: #1021471
 [ Upstream Kernel Changes ]
 * Bluetooth: Add USB_VENDOR_AND_INTERFACE_INFO() for Broadcom/Foxconn
 - LP: #1030233
 [ Wen-chien Jesse Sung ]
 * SAUCE: Bluetooth: Remove rules for matching Broadcom vendor specific
 IDs
 - LP: #1030233
 -- Leann Ogasawara <leann.ogasawara@canonical.com> 2012年10月09日 11:23:41 -0700

Changed in linux (Ubuntu Quantal):

status: Fix Committed → Fix Released

Revision history for this message

Norberto Bensa (nbensa) wrote on 2012年11月19日: #42

I'm running 3.5.0-19-generic (3.5.0-19.30) and I still get this bug.

Am I missing something?

zoolook@venkman:~$ apt-cache policy linux-image-extra-3.5.0-19-generic
linux-image-extra-3.5.0-19-generic:
Instalados: 3.5.0-19.30
Candidato: 3.5.0-19.30
Tabla de versión:
*** 3.5.0-19.30 0
500 http://archive.ubuntu.com/ubuntu/ quantal-proposed/main amd64 Packages
100 /var/lib/dpkg/status

Revision history for this message

Stefan Bader (smb) wrote on 2012年11月20日: #43

I guess, yes: the other bug causing refcount leaks: bug #1065434.

Revision history for this message

Adam Conrad (adconrad) wrote on 2013年05月24日: Update Released #44

The verification of this Stable Release Update has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regresssions.

Chris J Arges (arges) on 2014年05月01日

Changed in linux (Ubuntu Precise):

assignee: nobody → Chris J Arges (arges)

importance: Undecided → Medium

status: New → In Progress

Chris J Arges (arges) on 2014年05月02日

description: updated

Tim Gardner (timg-tpi) on 2014年05月02日

Changed in linux (Ubuntu Precise):

status: In Progress → Fix Committed

Revision history for this message

Brad Figg (brad-figg) wrote on 2014年05月13日: #45

This bug is awaiting verification that the kernel in -proposed solves the problem. Please test the kernel and update this bug with the results. If the problem is solved, change the tag 'verification-needed-precise' to 'verification-done-precise'.

If verification is not done by 5 working days from today, this fix will be dropped from the source code, and this bug will be closed.

See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you!

tags: added: verification-needed-precise

Revision history for this message

Chris J Arges (arges) wrote on 2014年05月13日: #46

Verified on 3.2.0-63-virtual.

tags: added: verification-done-precise
removed: verification-needed-precise

Revision history for this message

Launchpad Janitor (janitor) wrote on 2014年05月26日: #47

Download full text (17.7 KiB)

This bug was fixed in the package linux - 3.2.0-63.95

---------------
linux (3.2.0-63.95) precise; urgency=low

[ Kamal Mostafa ]

* Revert "rtlwifi: Set the link state"
- LP: #1319735
* Release Tracking Bug
- re-used previous tracking bug

linux (3.2.0-63.94) precise; urgency=low

[ Kamal Mostafa ]

* Merged back Ubuntu-3.2.0-61.93 security release
* Revert "n_tty: Fix n_tty_write crash when echoing in raw mode"
- LP: #1314762
* Release Tracking Bug
- LP: #1316703

[ Stefan Bader ]

* SAUCE: net/ipv4: Always flush route cache on unregister batch call
- LP: #1021471

[ Upstream Kernel Changes ]

* ipv6: don't set DST_NOCOUNT for remotely added routes
- LP: #1293726
- CVE-2014-2309
* vhost: fix total length when packets are too short
- LP: #1312984
- CVE-2014-0077
* n_tty: Fix n_tty_write crash when echoing in raw mode
- LP: #1314762
- CVE-2014-0196
* floppy: ignore kernel-only members in FDRAWCMD ioctl input
- LP: #1316729
- CVE-2014-1737
* floppy: don't write kernel-only members to FDRAWCMD ioctl output
- LP: #1316735
- CVE-2014-1738

linux (3.2.0-62.93) precise; urgency=low

[ Joseph Salisbury ]

* Release Tracking Bug
- LP: #1313807

[ Joseph Salisbury ]

* [Config] updateconfigs after Linux v3.2.57 update

[ Upstream Kernel Changes ]

* rds: prevent dereference of a NULL device in rds_iw_laddr_check
- LP: #1302222
- CVE-2014-2678
* rtlwifi: Set the link state
- LP: #1310763
* rtlwifi: rtl8192cu: Fix some code in RF handling
- LP: #1310763
* NFSv4: OPEN must handle the NFS4ERR_IO return code correctly
- LP: #1310763
* selinux: process labeled IPsec TCP SYN-ACK packets properly in
selinux_ip_postroute()
- LP: #1310763
* parport: parport_pc: remove double PCI ID for NetMos
- LP: #1310763
* staging: vt6656: [BUG] BBvUpdatePreEDThreshold Always set sensitivity
on bScanning
- LP: #1310763
* bfa: Chinook quad port 16G FC HBA claim issue
- LP: #1310763
* usb: option: add new zte 3g modem pids to option driver
- LP: #1310763
* dib8000: make 32 bits read atomic
- LP: #1310763
* serial: add support for 400 and 800 v3 series Titan cards
- LP: #1310763
* serial: add support for 200 v3 series Titan card
- LP: #1310763
* x86/efi: Fix off-by-one bug in EFI Boot Services reservation
- LP: #1310763
* rtc-cmos: Add an alarm disable quirk
- LP: #1310763
* slub: Fix calculation of cpu slabs
- LP: #1310763
* mtd: mxc_nand: remove duplicated ecc_stats counting
- LP: #1310763
* USB: pl2303: fix data corruption on termios updates
- LP: #1310763
* USB: serial: add support for iBall 3.5G connect usb modem
- LP: #1310763
* USB: Nokia 502 is an unusual device
- LP: #1310763
* USB: cypress_m8: fix ring-indicator detection and reporting
- LP: #1310763
* ALSA: rme9652: fix a missing comma in channel_map_9636_ds[]
- LP: #1310763
* sunrpc: Fix infinite loop in RPC state machine
- LP: #1310763
* SELinux: Fix memory leak upon loading policy
- LP: #1310763
* drm/radeon: warn users when hw_i2c is enabled (v2)
- LP: #131...

This bug was fixed in the package linux - 3.2.0-63.95
---------------
linux (3.2.0-63.95) precise; urgency=low
 [ Kamal Mostafa ]
 * Revert "rtlwifi: Set the link state"
 - LP: #1319735
 * Release Tracking Bug
 - re-used previous tracking bug
linux (3.2.0-63.94) precise; urgency=low
 [ Kamal Mostafa ]
 * Merged back Ubuntu-3.2.0-61.93 security release
 * Revert "n_tty: Fix n_tty_write crash when echoing in raw mode"
 - LP: #1314762
 * Release Tracking Bug
 - LP: #1316703
 [ Stefan Bader ]
 * SAUCE: net/ipv4: Always flush route cache on unregister batch call
 - LP: #1021471
 [ Upstream Kernel Changes ]
 * ipv6: don't set DST_NOCOUNT for remotely added routes
 - LP: #1293726
 - CVE-2014-2309
 * vhost: fix total length when packets are too short
 - LP: #1312984
 - CVE-2014-0077
 * n_tty: Fix n_tty_write crash when echoing in raw mode
 - LP: #1314762
 - CVE-2014-0196
 * floppy: ignore kernel-only members in FDRAWCMD ioctl input
 - LP: #1316729
 - CVE-2014-1737
 * floppy: don't write kernel-only members to FDRAWCMD ioctl output
 - LP: #1316735
 - CVE-2014-1738
linux (3.2.0-62.93) precise; urgency=low
 [ Joseph Salisbury ]
 * Release Tracking Bug
 - LP: #1313807
 [ Joseph Salisbury ]
 * [Config] updateconfigs after Linux v3.2.57 update
 [ Upstream Kernel Changes ]
 * rds: prevent dereference of a NULL device in rds_iw_laddr_check
 - LP: #1302222
 - CVE-2014-2678
 * rtlwifi: Set the link state
 - LP: #1310763
 * rtlwifi: rtl8192cu: Fix some code in RF handling
 - LP: #1310763
 * NFSv4: OPEN must handle the NFS4ERR_IO return code correctly
 - LP: #1310763
 * selinux: process labeled IPsec TCP SYN-ACK packets properly in
 selinux_ip_postroute()
 - LP: #1310763
 * parport: parport_pc: remove double PCI ID for NetMos
 - LP: #1310763
 * staging: vt6656: [BUG] BBvUpdatePreEDThreshold Always set sensitivity
 on bScanning
 - LP: #1310763
 * bfa: Chinook quad port 16G FC HBA claim issue
 - LP: #1310763
 * usb: option: add new zte 3g modem pids to option driver
 - LP: #1310763
 * dib8000: make 32 bits read atomic
 - LP: #1310763
 * serial: add support for 400 and 800 v3 series Titan cards
 - LP: #1310763
 * serial: add support for 200 v3 series Titan card
 - LP: #1310763
 * x86/efi: Fix off-by-one bug in EFI Boot Services reservation
 - LP: #1310763
 * rtc-cmos: Add an alarm disable quirk
 - LP: #1310763
 * slub: Fix calculation of cpu slabs
 - LP: #1310763
 * mtd: mxc_nand: remove duplicated ecc_stats counting
 - LP: #1310763
 * USB: pl2303: fix data corruption on termios updates
 - LP: #1310763
 * USB: serial: add support for iBall 3.5G connect usb modem
 - LP: #1310763
 * USB: Nokia 502 is an unusual device
 - LP: #1310763
 * USB: cypress_m8: fix ring-indicator detection and reporting
 - LP: #1310763
 * ALSA: rme9652: fix a missing comma in channel_map_9636_ds[]
 - LP: #1310763
 * sunrpc: Fix infinite loop in RPC state machine
 - LP: #1310763
 * SELinux: Fix memory leak upon loading policy
 - LP: #1310763
 * drm/radeon: warn users when hw_i2c is enabled (v2)
 - LP: #1310763
 * USB: ftdi_sio: added CS5 quirk for broken smartcard readers
 - LP: #1310763
 * serial: 8250: enable UART_BUG_NOMSR for Tegra
 - LP: #1310763
 * dm: wait until embedded kobject is released before destroying a device
 - LP: #1310763
 * dm space map common: make sure new space is used during extend
 - LP: #1310763
 * ASoC: adau1701: Fix ADAU1701_SEROCTL_WORD_LEN_16 constant
 - LP: #1310763
 * radeon/pm: Guard access to rdev->pm.power_state array
 - LP: #1310763
 * staging: r8712u: Set device type to wlan
 - LP: #1310763
 * ALSA: Enable CONFIG_ZONE_DMA for smaller PCI DMA masks
 - LP: #1310763
 * staging:iio:ad799x fix error_free_irq which was freeing an irq that may
 not have been requested
 - LP: #1310763
 * mmc: atmel-mci: fix timeout errors in SDIO mode when using DMA
 - LP: #1310763
 * ftrace: Use schedule_on_each_cpu() as a heavy synchronize_sched()
 - LP: #1310763
 * ftrace: Fix synchronization location disabling and freeing ftrace_ops
 - LP: #1310763
 * rtlwifi: rtl8192cu: Add new device ID
 - LP: #1310763
 * nfs4.1: properly handle ENOTSUP in SECINFO_NO_NAME
 - LP: #1310763
 * usb: ehci: add freescale imx28 special write register method
 - LP: #1310763
 * dm sysfs: fix a module unload race
 - LP: #1310763
 * KVM: x86: limit PIT timer frequency
 - LP: #1310763
 * md/raid5: fix long-standing problem with bitmap handling on write
 failure.
 - LP: #1310763
 * x86: Add check for number of available vectors before CPU down
 - LP: #1310763
 * libata: disable LPM for some WD SATA-I devices
 - LP: #1310763
 * mmc: sdhci: fix lockdep error in tuning routine
 - LP: #1310763
 * turbostat: Use GCC's CPUID functions to support PIC
 - LP: #1310763
 * drm/radeon: disable ss on DP for DCE3.x
 - LP: #1310763
 * drm/radeon: set the full cache bit for fences on r7xx+
 - LP: #1310763
 * hp_accel: Add a new PnP ID HPQ6007 for new HP laptops
 - LP: #1310763
 * intel-iommu: fix off-by-one in pagetable freeing
 - LP: #1310763
 * fuse: fix pipe_buf_operations
 - LP: #1310763
 * IB/qib: Fix QP check when looping back to/from QP1
 - LP: #1310763
 * ore: Fix wrong math in allocation of per device BIO
 - LP: #1310763
 * b43: fix the wrong assignment of status.freq in b43_rx()
 - LP: #1310763
 * i2c: piix4: Add support for AMD ML and CZ SMBus changes
 - LP: #1310763
 * KVM: PPC: e500: Fix bad address type in deliver_tlb_misss()
 - LP: #1310763
 * Btrfs: handle EAGAIN case properly in btrfs_drop_snapshot()
 - LP: #1310763
 * btrfs: restrict snapshotting to own subvolumes
 - LP: #1310763
 * ACPI / init: Flag use of ACPI and ACPI idioms for power supplies to
 regulator API
 - LP: #1310763
 * powerpc: Make sure "cache" directory is removed when offlining cpu
 - LP: #1310763
 * Btrfs: setup inode location during btrfs_init_inode_locked
 - LP: #1310763
 * drm/radeon/DCE4+: clear bios scratch dpms bit (v2)
 - LP: #1310763
 * KVM: return an error code in kvm_vm_ioctl_register_coalesced_mmio()
 - LP: #1310763
 * target/iscsi: Fix network portal creation race
 - LP: #1310763
 * s390/crypto: Don't panic after crypto instruction failures
 - LP: #1310763
 * crypto: s390 - fix concurrency issue in aes-ctr mode
 - LP: #1310763
 * crypto: s390 - fix des and des3_ede cbc concurrency issue
 - LP: #1310763
 * crypto: s390 - fix des and des3_ede ctr concurrency issue
 - LP: #1310763
 * mm, oom: base root bonus on current usage
 - LP: #1310763
 * ata: enable quirk from jmicron JMB350 for JMB394
 - LP: #1310763
 * alpha: fix broken network checksum
 - LP: #1310763
 * power: max17040: Fix NULL pointer dereference when there is no
 platform_data
 - LP: #1310763
 * sata_sil: apply MOD15WRITE quirk to TOSHIBA MK2561GSYN
 - LP: #1310763
 * mxl111sf: Fix compile when CONFIG_DVB_USB_MXL111SF is unset
 - LP: #1310763
 * s390/dump: Fix dump memory detection
 - LP: #1310763
 * ath9k_htc: Do not support PowerSave by default
 - LP: #1310763
 * ath9k: Do not support PowerSave by default
 - LP: #1310763
 * usb: ftdi_sio: add Mindstorms EV3 console adapter
 - LP: #1310763
 * usb-storage: restrict bcdDevice range for Super Top in Cypress ATACB
 - LP: #1310763
 * usb-storage: add unusual-devs entry for BlackBerry 9000
 - LP: #1310763
 * usb-storage: enable multi-LUN scanning when needed
 - LP: #1310763
 * ALSA: hda/realtek - Avoid invalid COEFs for ALC271X
 - LP: #1310763
 * of: Fix address decoding on Bimini and js2x machines
 - LP: #1310763
 * of: fix PCI bus match for PCIe slots
 - LP: #1310763
 * USB: ftdi_sio: add Tagsys RFID Reader IDs
 - LP: #1310763
 * mac80211: fix fragmentation code, particularly for encryption
 - LP: #1310763
 * time: Fix overflow when HZ is smaller than 60
 - LP: #1310763
 * x86, hweight: Fix BUG when booting with CONFIG_GCOV_PROFILE_ALL=y
 - LP: #1310763
 * mm/swap: fix race on swap_info reuse between swapoff and swapon
 - LP: #1310763
 * mm: __set_page_dirty_nobuffers() uses spin_lock_irqsave() instead of
 spin_lock_irq()
 - LP: #1310763
 * mm: __set_page_dirty uses spin_lock_irqsave instead of spin_lock_irq
 - LP: #1310763
 * Drivers: hv: vmbus: Don't timeout during the initial connection with
 host
 - LP: #1310763
 * raw: test against runtime value of max_raw_minors
 - LP: #1310763
 * tty: n_gsm: Fix for modems with brk in modem status control
 - LP: #1310763
 * staging: comedi: adv_pci1710: fix analog output readback value
 - LP: #1310763
 * xen-blkfront: handle backend CLOSED without CLOSING
 - LP: #1310763
 * Modpost: fixed USB alias generation for ranges including 0x9 and 0xA
 - LP: #1310763
 * ARM: 7953/1: mm: ensure TLB invalidation is complete before enabling
 MMU
 - LP: #1310763
 * ARM: 7955/1: spinlock: ensure we have a compiler barrier before sev
 - LP: #1310763
 * fs/file.c:fdtable: avoid triggering OOMs from alloc_fdmem
 - LP: #1310763
 * SUNRPC: Fix races in xs_nospace()
 - LP: #1310763
 * xen: install xen/gntdev.h and xen/gntalloc.h
 - LP: #1310763
 * ring-buffer: Fix first commit on sub-buffer having non-zero delta
 - LP: #1310763
 * drm/i915: Add intel_ring_cachline_align()
 - LP: #1310763
 * drm/i915: Prevent MI_DISPLAY_FLIP straddling two cachelines on IVB
 - LP: #1310763
 * usb: option: blacklist ZTE MF667 net interface
 - LP: #1310763
 * block: add cond_resched() to potentially long running ioctl discard
 loop
 - LP: #1310763
 * md/raid5: Fix CPU hotplug callback registration
 - LP: #1310763
 * compiler/gcc4: Make quirk for asm_volatile_goto() unconditional
 - LP: #1310763
 * drm/i915/dp: increase native aux defer retry timeout
 - LP: #1310763
 * drm/i915/dp: add native aux defer retry limit
 - LP: #1310763
 * lockd: send correct lock when granting a delayed lock.
 - LP: #1310763
 * rtlwifi: rtl8192ce: Fix too long disable of IRQs
 - LP: #1310763
 * MIPS: Fix potencial corruption
 - LP: #1310763
 * rtl8187: fix regression on MIPS without coherent DMA
 - LP: #1310763
 * IB/qib: Add missing serdes init sequence
 - LP: #1310763
 * EDAC: Correct workqueue setup path
 - LP: #1310763
 * PCI: Enable INTx if BIOS left them disabled
 - LP: #1310763
 * ext4: don't leave i_crtime.tv_sec uninitialized
 - LP: #1310763
 * dma: ste_dma40: don't dereference free:d descriptor
 - LP: #1310763
 * ALSA: usb-audio: work around KEF X300A firmware bug
 - LP: #1310763
 * avr32: fix missing module.h causing build failure in mimc200/fram.c
 - LP: #1310763
 * avr32: Makefile: add '-D__linux__' flag for gcc-4.4.7 use
 - LP: #1310763
 * ARM: 7957/1: add DSB after icache flush in __flush_icache_all()
 - LP: #1310763
 * ahci: disable NCQ on Samsung pci-e SSDs on macbooks
 - LP: #1310763
 * USB: EHCI: add delay during suspend to prevent erroneous wakeups
 - LP: #1310763
 * USB: serial: option: blacklist interface 4 for Cinterion PHS8 and PXS8
 - LP: #1310763
 * workqueue: ensure @task is valid across kthread_stop()
 - LP: #1310763
 * cgroup: update cgroup_enable_task_cg_lists() to grab siglock
 - LP: #1310763
 * hwmon: (max1668) Fix writing the minimum temperature
 - LP: #1310763
 * ASoC: sta32x: Fix array access overflow
 - LP: #1310763
 * ACPI / video: Filter the _BCL table for duplicate brightness values
 - LP: #1310763
 * ASoC: wm8770: Fix wrong number of enum items
 - LP: #1310763
 * mac80211: fix AP powersave TX vs. wakeup race
 - LP: #1310763
 * SELinux: bigendian problems with filename trans rules
 - LP: #1310763
 * ath9k: protect tid->sched check
 - LP: #1310763
 * ath9k: Fix ETSI compliance for AR9462 2.0
 - LP: #1310763
 * quota: Fix race between dqput() and dquot_scan_active()
 - LP: #1310763
 * i7core_edac: Fix PCI device reference count
 - LP: #1310763
 * i7300_edac: Fix device reference count
 - LP: #1310763
 * ACPI / processor: Rework processor throttling with work_on_cpu()
 - LP: #1310763
 * USB: serial: ftdi_sio: add id for Z3X Box device
 - LP: #1310763
 * USB: ftdi_sio: add Cressi Leonardo PID
 - LP: #1310763
 * usb: ehci: fix deadlock when threadirqs option is used
 - LP: #1310763
 * ASoC: sta32x: Fix wrong enum for limiter2 release rate
 - LP: #1310763
 * iwlwifi: fix TX status for aggregated packets
 - LP: #1310763
 * genirq: Remove racy waitqueue_active check
 - LP: #1310763
 * sched: Fix double normalization of vruntime
 - LP: #1310763
 * perf/x86: Fix event scheduling
 - LP: #1310763
 * perf: Fix hotplug splat
 - LP: #1310763
 * cpuset: fix a race condition in __cpuset_node_allowed_softwall()
 - LP: #1310763
 * powerpc/crashdump : Fix page frame number check in copy_oldmem_page
 - LP: #1310763
 * can: flexcan: fix shutdown: first disable chip, then all interrupts
 - LP: #1310763
 * can: flexcan: flexcan_open(): fix error path if flexcan_chip_start()
 fails
 - LP: #1310763
 * can: flexcan: flexcan_remove(): add missing netif_napi_del()
 - LP: #1310763
 * tracing: Do not add event files for modules that fail tracepoints
 - LP: #1310763
 * ocfs2: fix quota file corruption
 - LP: #1310763
 * ALSA: usb-audio: Add quirk for Logitech Webcam C500
 - LP: #1310763
 * mac80211: clear sequence/fragment number in QoS-null frames
 - LP: #1310763
 * mwifiex: copy AP's HT capability info correctly
 - LP: #1310763
 * net: unix socket code abuses csum_partial
 - LP: #1310763
 * powerpc: Align p_dyn, p_rela and p_st symbols
 - LP: #1310763
 * libata: add ATA_HORKAGE_BROKEN_FPDMA_AA quirk for Seagate Momentus
 SpinPoint M8 (2BA30001)
 - LP: #1310763
 * usb: Add device quirk for Logitech HD Pro Webcams C920 and C930e
 - LP: #1310763
 * usb: Make DELAY_INIT quirk wait 100ms between Get Configuration
 requests
 - LP: #1310763
 * isci: fix reset timeout handling
 - LP: #1310763
 * isci: correct erroneous for_each_isci_host macro
 - LP: #1310763
 * qla2xxx: Poll during initialization for ISP25xx and ISP83xx
 - LP: #1310763
 * ocfs2 syncs the wrong range...
 - LP: #1310763
 * vmxnet3: fix netpoll race condition
 - LP: #1310763
 * KVM: SVM: fix cr8 intercept window
 - LP: #1310763
 * vmxnet3: fix building without CONFIG_PCI_MSI
 - LP: #1310763
 * x86/amd/numa: Fix northbridge quirk to assign correct NUMA node
 - LP: #1310763
 * staging: comedi: ssv_dnp: correct insn_bits result
 - LP: #1310763
 * staging: comedi: pcmuio: fix possible NULL deref on detach
 - LP: #1310763
 * nfs: fix do_div() warning by instead using sector_div()
 - LP: #1310763
 * mm/hugetlb: check for pte NULL pointer in __page_check_address()
 - LP: #1310763
 * TTY: pmac_zilog, check existence of ports in pmz_console_init()
 - LP: #1310763
 * hpfs: remember free space
 - LP: #1310763
 * hpfs: deadlock and race in directory lseek()
 - LP: #1310763
 * ftrace: Have function graph only trace based on global_ops filters
 - LP: #1310763
 * timekeeping: fix 32-bit overflow in get_monotonic_boottime
 - LP: #1310763
 * printk: Fix scheduling-while-atomic problem in console_cpu_notify()
 - LP: #1310763
 * net: fix 'ip rule' iif/oif device rename
 - LP: #1310763
 * tg3: Fix deadlock in tg3_change_mtu()
 - LP: #1310763
 * usbnet: remove generic hard_header_len check
 - LP: #1310763
 * bonding: 802.3ad: make aggregator_identifier bond-private
 - LP: #1310763
 * net: sctp: fix sctp_connectx abi for ia32 emulation/compat mode
 - LP: #1310763
 * saa7134: Fix unlocked snd_pcm_stop() call
 - LP: #1310763
 * ALSA: oxygen: Xonar DG(X): capture from I2S channel 1, not 2
 - LP: #1310763
 * ALSA: oxygen: Xonar DG(X): modify DAC routing
 - LP: #1310763
 * jiffies: Avoid undefined behavior from signed overflow
 - LP: #1310763
 * virtio-net: alloc big buffers also when guest can receive UFO
 - LP: #1310763
 * tg3: Don't check undefined error bits in RXBD
 - LP: #1310763
 * net: sctp: fix sctp_sf_do_5_1D_ce to verify if we/peer is AUTH capable
 - LP: #1310763
 * intel_idle: Check cpu_idle_get_driver() for NULL before dereferencing
 it.
 - LP: #1310763
 * PCI: Enable INTx in pci_reenable_device() only when MSI/MSI-X not
 enabled
 - LP: #1310763
 * Linux 3.2.56
 - LP: #1310763
 * Input: synaptics - add manual min/max quirk
 - LP: #1310763
 * Input: synaptics - add manual min/max quirk for ThinkPad X240
 - LP: #1310763
 * staging: speakup: Prefix set_mask_bits() symbol
 - LP: #1310763
 * ext4: atomically set inode->i_flags in ext4_set_inode_flags()
 - LP: #1310763
 * netfilter: nf_conntrack_dccp: fix skb_header_pointer API usages
 - LP: #1310763
 * ipc/msg: fix race around refcount
 - LP: #1310763
 * net: add and use skb_gso_transport_seglen()
 - LP: #1310763
 * net: ip, ipv6: handle gso skbs in forwarding path
 - LP: #1310763
 * deb-pkg: use KCONFIG_CONFIG instead of .config file directly
 - LP: #1310763
 * deb-pkg: Fix building for MIPS big-endian or ARM OABI
 - LP: #1310763
 * deb-pkg: Fix cross-building linux-headers package
 - LP: #1310763
 * net: asix: handle packets crossing URB boundaries
 - LP: #1310763
 * net: asix: add missing flag to struct driver_info
 - LP: #1310763
 * KVM: MMU: handle invalid root_hpa at __direct_map
 - LP: #1310763
 * KVM: VMX: fix use after free of vmx->loaded_vmcs
 - LP: #1310763
 * cifs: ensure that uncached writes handle unmapped areas correctly
 - LP: #1310763
 * s390: fix kernel crash due to linkage stack instructions
 - LP: #1310763
 * Linux 3.2.57
 - LP: #1310763
 * net: ipv4: current group_info should be put after using.
 - CVE-2014-2851
 -- Kamal Mostafa <kamal@canonical.com> 2014年5月15日 15:30:37 -0700

Changed in linux (Ubuntu Precise):

status: Fix Committed → Fix Released

Revision history for this message

Alessandro Moscatelli (alessandro-moscatelli) wrote on 2014年06月12日: #49

screenshot Edit (208.0 KiB, image/png)

It looks I have this problem with Ubuntu Raring
kernel version : 3.8.13

I attached a screenshot with dmesg after I tried to start again my containers.

Should I open a new bug ?

Thank you in advance

Revision history for this message

Clint Byrum (clint-fewbar) wrote on 2014年06月13日: Re: [Bug 1021471] Re: clone() hang when creating new network namespace (dmesg show unregister_netdevice: waiting for lo to become free. Usage count = 2) #50

Download full text (6.0 KiB)

Raring is EOL since January 27:

https://wiki.ubuntu.com/Releases

Excerpts from Alessandro Moscatelli's message of 2014年06月12日 22:23:52 UTC:
> It looks I have this problem with Ubuntu Raring
> kernel version : 3.8.13
>
> I attached a screenshot with dmesg after I tried to start again my
> containers.
>
> Should I open a new bug ?
>
> Thank you in advance
>
>
> ** Attachment added: "screenshot"
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1021471/+attachment/4130637/+files/5.png
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1021471
>
> Title:
> clone() hang when creating new network namespace (dmesg show
> unregister_netdevice: waiting for lo to become free. Usage count = 2)
>
> Status in The Linux Kernel:
> Confirmed
> Status in "linux" package in Ubuntu:
> Fix Released
> Status in "linux" source package in Precise:
> Fix Released
> Status in "linux" source package in Quantal:
> Fix Released
>
> Bug description:
> SRU Justification:
>
> Impact:
> When creating new network namespace dmesg can show the following
> unregister_netdevice: waiting for lo to become free. Usage count = 1
>
> Fix:
> Stefan Bader's SAUCE patch has fixed this for Quantal:
> UBUNTU: SAUCE: net/ipv4: Always flush route cache on unregister batch call
>
> Testcase:
> The sourcecode found here:
> https://lists.debian.org/debian-kernel/2012/05/msg00494.html
> can be compiled and run as follows:
>
> sudo ./reproducer
> #ctrl+c
> sudo ./reproducer
> #wait for a while
> dmesg | grep unregister
>
>
> --
>
> I'm not sure how I triggered this. I've been moving around between
> networks and suspending/resuming all day.
>
> Earlier in this boot I successfully used a container (start,
> networking and stop). I came to start the same one later and noticed
> that it didn't come up. Trying to attach to the console with lxc-
> console informed me that it wasn't running. I then saw suspicious
> content in dmesg:
>
> [25800.412234] INFO: task lxc-start:25817 blocked for more than 120 seconds.
> [25800.412243] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> [25800.412254] lxc-start D ffff88013fd13980 0 25817 1 0x00000000
> [25800.412266] ffff880007b43cc0 0000000000000086 ffff88003ba4c500 ffff880007b43fd8
> [25800.412275] ffff880007b43fd8 ffff880007b43fd8 ffff880134c65c00 ffff88003ba4c500
> [25800.412284] 000080d0ffffffff ffffffff81ca7c00 ffff88003ba4c500 ffffffff81ca7c04
> [25800.412288] Call Trace:
> [25800.412306] [<ffffffff81673759>] schedule+0x29/0x70
> [25800.412313] [<ffffffff81673a1e>] schedule_preempt_disabled+0xe/0x10
> [25800.412323] [<ffffffff81672537>] __mutex_lock_slowpath+0xd7/0x150
> [25800.412331] [<ffffffff8167200a>] mutex_lock+0x2a/0x50
> [25800.412340] [<ffffffff8155ede1>] copy_net_ns+0x71/0x100
> [25800.412350] [<ffffffff8107adfb>] create_new_namespaces+0xdb/0x190
> [25800.412357] [<ffffffff8107afec>] copy_namespaces+0x8c/0xd0
> [25800.412367] [<ffffffff81050142>] copy_pr...

Raring is EOL since January 27:
https://wiki.ubuntu.com/Releases
Excerpts from Alessandro Moscatelli's message of 2014年06月12日 22:23:52 UTC:
> It looks I have this problem with Ubuntu Raring
> kernel version : 3.8.13
> 
> I attached a screenshot with dmesg after I tried to start again my
> containers.
> 
> Should I open a new bug ?
> 
> Thank you in advance
> 
> 
> ** Attachment added: "screenshot"
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1021471/+attachment/4130637/+files/5.png
> 
> -- 
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1021471
> 
> Title:
> clone() hang when creating new network namespace (dmesg show
> unregister_netdevice: waiting for lo to become free. Usage count = 2)
> 
> Status in The Linux Kernel:
> Confirmed
> Status in "linux" package in Ubuntu:
> Fix Released
> Status in "linux" source package in Precise:
> Fix Released
> Status in "linux" source package in Quantal:
> Fix Released
> 
> Bug description:
> SRU Justification:
> 
> Impact:
> When creating new network namespace dmesg can show the following
> unregister_netdevice: waiting for lo to become free. Usage count = 1
> 
> Fix:
> Stefan Bader's SAUCE patch has fixed this for Quantal:
> UBUNTU: SAUCE: net/ipv4: Always flush route cache on unregister batch call
> 
> Testcase:
> The sourcecode found here:
> https://lists.debian.org/debian-kernel/2012/05/msg00494.html
> can be compiled and run as follows:
> 
> sudo ./reproducer
> #ctrl+c
> sudo ./reproducer
> #wait for a while
> dmesg | grep unregister
> 
> 
> --
> 
> I'm not sure how I triggered this. I've been moving around between
> networks and suspending/resuming all day.
> 
> Earlier in this boot I successfully used a container (start,
> networking and stop). I came to start the same one later and noticed
> that it didn't come up. Trying to attach to the console with lxc-
> console informed me that it wasn't running. I then saw suspicious
> content in dmesg:
> 
> [25800.412234] INFO: task lxc-start:25817 blocked for more than 120 seconds.
> [25800.412243] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> [25800.412254] lxc-start D ffff88013fd13980 0 25817 1 0x00000000
> [25800.412266] ffff880007b43cc0 0000000000000086 ffff88003ba4c500 ffff880007b43fd8
> [25800.412275] ffff880007b43fd8 ffff880007b43fd8 ffff880134c65c00 ffff88003ba4c500
> [25800.412284] 000080d0ffffffff ffffffff81ca7c00 ffff88003ba4c500 ffffffff81ca7c04
> [25800.412288] Call Trace:
> [25800.412306] [<ffffffff81673759>] schedule+0x29/0x70
> [25800.412313] [<ffffffff81673a1e>] schedule_preempt_disabled+0xe/0x10
> [25800.412323] [<ffffffff81672537>] __mutex_lock_slowpath+0xd7/0x150
> [25800.412331] [<ffffffff8167200a>] mutex_lock+0x2a/0x50
> [25800.412340] [<ffffffff8155ede1>] copy_net_ns+0x71/0x100
> [25800.412350] [<ffffffff8107adfb>] create_new_namespaces+0xdb/0x190
> [25800.412357] [<ffffffff8107afec>] copy_namespaces+0x8c/0xd0
> [25800.412367] [<ffffffff81050142>] copy_process.part.22+0x902/0x1520
> [25800.412375] [<ffffffff81050ee5>] do_fork+0x135/0x390
> [25800.412385] [<ffffffff8116db40>] ? kmem_cache_free+0x20/0x100
> [25800.412395] [<ffffffff8118c6b3>] ? putname+0x33/0x50
> [25800.412402] [<ffffffff811811cc>] ? do_sys_open+0x16c/0x200
> [25800.412410] [<ffffffff8101c238>] sys_clone+0x28/0x30
> [25800.412418] [<ffffffff8167cbf3>] stub_clone+0x13/0x20
> [25800.412424] [<ffffffff8167c8e9>] ? system_call_fastpath+0x16/0x1b
> [25806.312385] unregister_netdevice: waiting for lo to become free. Usage count = 1
> 
> ProblemType: Bug
> DistroRelease: Ubuntu 12.10
> Package: linux-image-generic 3.5.0.3.3
> ProcVersionSignature: Ubuntu 3.5.0-2.2-generic 3.5.0-rc4
> Uname: Linux 3.5.0-2-generic x86_64
> NonfreeKernelModules: nvidia wl
> AlsaVersion: Advanced Linux Sound Architecture Driver Version 1.0.25.
> ApportVersion: 2.2.5-0ubuntu2
> Architecture: amd64
> ArecordDevices:
> **** List of CAPTURE Hardware Devices ****
> card 0: NVidia [HDA NVidia], device 0: Cirrus Analog [Cirrus Analog]
>  Subdevices: 1/1
>  Subdevice #0: subdevice #0
> AudioDevicesInUse:
> USER PID ACCESS COMMAND
> /dev/snd/controlC0: laney 2787 F.... pulseaudio
> CRDA: Error: command ['iw', 'reg', 'get'] failed with exit code 1: nl80211 not found.
> Card0.Amixer.info:
> Card hw:0 'NVidia'/'HDA NVidia at 0xd3480000 irq 22'
>  Mixer name : 'Nvidia MCP89 HDMI'
>  Components : 'HDA:10134206,106b0d00,00100301 HDA:10de000c,10de0101,00100200'
>  Controls : 37
>  Simple ctrls : 13
> Date: Thu Jul 5 21:26:08 2012
> HibernationDevice: RESUME=UUID=1c5b3f2c-2c89-4fa1-9ed8-0e238de8fe47
> InstallationMedia: Ubuntu 10.04.1 LTS "Lucid Lynx" - Release amd64 (20100729)
> MachineType: Apple Inc. MacBookPro7,1
> ProcFB: 0 VESA VGA
> ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.5.0-2-generic root=UUID=2228fdfe-3834-40b2-b7b4-efea7463e3c1 ro quiet splash reboot=pci vt.handoff=7
> RelatedPackageVersions:
> linux-restricted-modules-3.5.0-2-generic N/A
> linux-backports-modules-3.5.0-2-generic N/A
> linux-firmware 1.82
> SourcePackage: linux
> UpgradeStatus: Upgraded to quantal on 2012年01月13日 (173 days ago)
> dmi.bios.date: 03/25/10
> dmi.bios.vendor: Apple Inc.
> dmi.bios.version: MBP71.88Z.0039.B05.1003251322
> dmi.board.name: Mac-F222BEC8
> dmi.board.vendor: Apple Inc.
> dmi.chassis.type: 10
> dmi.chassis.vendor: Apple Inc.
> dmi.chassis.version: Mac-F222BEC8
> dmi.modalias: dmi:bvnAppleInc.:bvrMBP71.88Z.0039.B05.1003251322:bd03/25/10:svnAppleInc.:pnMacBookPro7,1:pvr1.0:rvnAppleInc.:rnMac-F222BEC8:rvr:cvnAppleInc.:ct10:cvrMac-F222BEC8:
> dmi.product.name: MacBookPro7,1
> dmi.product.version: 1.0
> dmi.sys.vendor: Apple Inc.
> 
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/linux/+bug/1021471/+subscriptions

Juerg Haefliger (juergh) on 2025年04月18日

tags: added: kernel-daily-bug

See full activity log