)]}' { "commit": "4a683bf94b8a10e2bb0da07aec3ac0a55e5de61f", "tree": "57ef71a93597b284ea90c9ff3436d183ea83675a", "parents": [ "eda1e328556565e211b7450250e40d6de751563a" ], "author": { "name": "Ingo Molnar", "email": "mingo@elte.hu", "time": "Fri Aug 21 12:53:36 2009 +0200" }, "committer": { "name": "Ingo Molnar", "email": "mingo@elte.hu", "time": "Fri Aug 21 13:03:22 2009 +0200" }, "message": "tracing: Fix too large stack usage in do_one_initcall()\n\nOne of my testboxes triggered this nasty stack overflow crash\nduring SCSI probing:\n\n[ 5.874004] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn\u0027t support DPO or FUA\n[ 5.875004] device: \u0027sda\u0027: device_add\n[ 5.878004] BUG: unable to handle kernel NULL pointer dereference at 00000a0c\n[ 5.878004] IP: [\u003cb1008321\u003e] print_context_stack+0x81/0x110\n[ 5.878004] *pde \u003d 00000000\n[ 5.878004] Thread overran stack, or stack corrupted\n[ 5.878004] Oops: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC\n[ 5.878004] last sysfs file:\n[ 5.878004]\n[ 5.878004] Pid: 1, comm: swapper Not tainted (2.6.31-rc6-tip-01272-g9919e28-dirty #5685)\n[ 5.878004] EIP: 0060:[\u003cb1008321\u003e] EFLAGS: 00010083 CPU: 0\n[ 5.878004] EIP is at print_context_stack+0x81/0x110\n[ 5.878004] EAX: cf8a3000 EBX: cf8a3fe4 ECX: 00000049 EDX: 00000000\n[ 5.878004] ESI: b1cfce84 EDI: 00000000 EBP: cf8a3018 ESP: cf8a2ff4\n[ 5.878004] DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068\n[ 5.878004] Process swapper (pid: 1, ti\u003dcf8a2000 task\u003dcf8a8000 task.ti\u003dcf8a3000)\n[ 5.878004] Stack:\n[ 5.878004] b1004867 fffff000 cf8a3ffc\n[ 5.878004] Call Trace:\n[ 5.878004] [\u003cb1004867\u003e] ? kernel_thread_helper+0x7/0x10\n[ 5.878004] BUG: unable to handle kernel NULL pointer dereference at 00000a0c\n[ 5.878004] IP: [\u003cb1008321\u003e] print_context_stack+0x81/0x110\n[ 5.878004] *pde \u003d 00000000\n[ 5.878004] Thread overran stack, or stack corrupted\n[ 5.878004] Oops: 0000 [#2] PREEMPT SMP DEBUG_PAGEALLOC\n\nThe oops did not reveal any more details about the real stack\nthat we have and the system got into an infinite loop of\nrecursive pagefaults.\n\nSo i booted with CONFIG_STACK_TRACER\u003dy and the \u0027stacktrace\u0027 boot\nparameter. The box did not crash (timings/conditions probably\nchanged a tiny bit to trigger the catastrophic crash), but the\n/debug/tracing/stack_trace file was rather revealing:\n\n Depth Size Location (72 entries)\n ----- ---- --------\n 0) 3704 52 __change_page_attr+0xb8/0x290\n 1) 3652 24 __change_page_attr_set_clr+0x43/0x90\n 2) 3628 60 kernel_map_pages+0x108/0x120\n 3) 3568 40 prep_new_page+0x7d/0x130\n 4) 3528 84 get_page_from_freelist+0x106/0x420\n 5) 3444 116 __alloc_pages_nodemask+0xd7/0x550\n 6) 3328 36 allocate_slab+0xb1/0x100\n 7) 3292 36 new_slab+0x1c/0x160\n 8) 3256 36 __slab_alloc+0x133/0x2b0\n 9) 3220 4 kmem_cache_alloc+0x1bb/0x1d0\n 10) 3216 108 create_object+0x28/0x250\n 11) 3108 40 kmemleak_alloc+0x81/0xc0\n 12) 3068 24 kmem_cache_alloc+0x162/0x1d0\n 13) 3044 52 scsi_pool_alloc_command+0x29/0x70\n 14) 2992 20 scsi_host_alloc_command+0x22/0x70\n 15) 2972 24 __scsi_get_command+0x1b/0x90\n 16) 2948 28 scsi_get_command+0x35/0x90\n 17) 2920 24 scsi_setup_blk_pc_cmnd+0xd4/0x100\n 18) 2896 128 sd_prep_fn+0x332/0xa70\n 19) 2768 36 blk_peek_request+0xe7/0x1d0\n 20) 2732 56 scsi_request_fn+0x54/0x520\n 21) 2676 12 __generic_unplug_device+0x2b/0x40\n 22) 2664 24 blk_execute_rq_nowait+0x59/0x80\n 23) 2640 172 blk_execute_rq+0x6b/0xb0\n 24) 2468 32 scsi_execute+0xe0/0x140\n 25) 2436 64 scsi_execute_req+0x152/0x160\n 26) 2372 60 scsi_vpd_inquiry+0x6c/0x90\n 27) 2312 44 scsi_get_vpd_page+0x112/0x160\n 28) 2268 52 sd_revalidate_disk+0x1df/0x320\n 29) 2216 92 rescan_partitions+0x98/0x330\n 30) 2124 52 __blkdev_get+0x309/0x350\n 31) 2072 8 blkdev_get+0xf/0x20\n 32) 2064 44 register_disk+0xff/0x120\n 33) 2020 36 add_disk+0x6e/0xb0\n 34) 1984 44 sd_probe_async+0xfb/0x1d0\n 35) 1940 44 __async_schedule+0xf4/0x1b0\n 36) 1896 8 async_schedule+0x12/0x20\n 37) 1888 60 sd_probe+0x305/0x360\n 38) 1828 44 really_probe+0x63/0x170\n 39) 1784 36 driver_probe_device+0x5d/0x60\n 40) 1748 16 __device_attach+0x49/0x50\n 41) 1732 32 bus_for_each_drv+0x5b/0x80\n 42) 1700 24 device_attach+0x6b/0x70\n 43) 1676 16 bus_attach_device+0x47/0x60\n 44) 1660 76 device_add+0x33d/0x400\n 45) 1584 52 scsi_sysfs_add_sdev+0x6a/0x2c0\n 46) 1532 108 scsi_add_lun+0x44b/0x460\n 47) 1424 116 scsi_probe_and_add_lun+0x182/0x4e0\n 48) 1308 36 __scsi_add_device+0xd9/0xe0\n 49) 1272 44 ata_scsi_scan_host+0x10b/0x190\n 50) 1228 24 async_port_probe+0x96/0xd0\n 51) 1204 44 __async_schedule+0xf4/0x1b0\n 52) 1160 8 async_schedule+0x12/0x20\n 53) 1152 48 ata_host_register+0x171/0x1d0\n 54) 1104 60 ata_pci_sff_activate_host+0xf3/0x230\n 55) 1044 44 ata_pci_sff_init_one+0xea/0x100\n 56) 1000 48 amd_init_one+0xb2/0x190\n 57) 952 8 local_pci_probe+0x13/0x20\n 58) 944 32 pci_device_probe+0x68/0x90\n 59) 912 44 really_probe+0x63/0x170\n 60) 868 36 driver_probe_device+0x5d/0x60\n 61) 832 20 __driver_attach+0x89/0xa0\n 62) 812 32 bus_for_each_dev+0x5b/0x80\n 63) 780 12 driver_attach+0x1e/0x20\n 64) 768 72 bus_add_driver+0x14b/0x2d0\n 65) 696 36 driver_register+0x6e/0x150\n 66) 660 20 __pci_register_driver+0x53/0xc0\n 67) 640 8 amd_init+0x14/0x16\n 68) 632 572 do_one_initcall+0x2b/0x1d0\n 69) 60 12 do_basic_setup+0x56/0x6a\n 70) 48 20 kernel_init+0x84/0xce\n 71) 28 28 kernel_thread_helper+0x7/0x10\n\nThere\u0027s a lot of fat functions on that stack trace, but\nthe largest of all is do_one_initcall(). This is due to\nthe boot trace entry variables being on the stack.\n\nFixing this is relatively easy, initcalls are fundamentally\nserialized, so we can move the local variables to file scope.\n\nNote that this large stack footprint was present for a\ncouple of months already - what pushed my system over\nthe edge was the addition of kmemleak to the call-chain:\n\n 6) 3328 36 allocate_slab+0xb1/0x100\n 7) 3292 36 new_slab+0x1c/0x160\n 8) 3256 36 __slab_alloc+0x133/0x2b0\n 9) 3220 4 kmem_cache_alloc+0x1bb/0x1d0\n 10) 3216 108 create_object+0x28/0x250\n 11) 3108 40 kmemleak_alloc+0x81/0xc0\n 12) 3068 24 kmem_cache_alloc+0x162/0x1d0\n 13) 3044 52 scsi_pool_alloc_command+0x29/0x70\n\nThis pushes the total to ~3800 bytes, only a tiny bit\nmore was needed to corrupt the on-kernel-stack thread_info.\n\nThe fix reduces the stack footprint from 572 bytes\nto 28 bytes.\n\nCc: Peter Zijlstra \u003ca.p.zijlstra@chello.nl\u003e\nCc: Thomas Gleixner \u003ctglx@linutronix.de\u003e\nCc: Frederic Weisbecker \u003cfweisbec@gmail.com\u003e\nCc: Steven Rostedt \u003csrostedt@redhat.com\u003e\nCc: Catalin Marinas \u003ccatalin.marinas@arm.com\u003e\nCc: Jens Axboe \u003cjens.axboe@oracle.com\u003e\nCc: Linus Torvalds \u003ctorvalds@linux-foundation.org\u003e\nCc: \u003cstable@kernel.org\u003e\nLKML-Reference: \u003cnew-submission\u003e\nSigned-off-by: Ingo Molnar \u003cmingo@elte.hu\u003e\n", "tree_diff": [ { "type": "modify", "old_id": "2c5ade79eb81718702dd1fdf44e8b129e69f88a9", "old_mode": 33188, "old_path": "init/main.c", "new_id": "98e679e3494a8f7fc1fd642e41637e3d366b1f2b", "new_mode": 33188, "new_path": "init/main.c" } ] }