* possible regression on 3.13 when calling flush_dcache_page
@ 2013-12-12 14:31 ` Ludovic Desroches
0 siblings, 0 replies; 45+ messages in thread
From: Ludovic Desroches @ 2013-12-12 14:31 UTC (permalink / raw)
To: linux-mm, linux-kernel, linux-mmc, linux-arm-kernel
Cc: ludovic.desroches, iamjoonsoo.kim
Hi,
With v3.13-rc3 I have an error when the atmel-mci driver calls
flush_dcache_page (log at the end of the message).
Since I didn't have it before, I did a git bisect and the commit introducing
the error is the following one:
106a74e slab: replace free and inuse in struct slab with newly introduced active
I don't know if this commit has introduced a bug or if it has revealed a bug
in the atmel-mci driver.
I'll investigate on atmel-mci driver side but if someone has also this issue or
see what is wrong in the driver, please tell me all about it.
Thanks
Regards
Ludovic
# mmc0: mmc_rescan_try_freq: trying to init card at 400000 Hz
mmc0: queuing unknown CIS tuple 0x01 (3 bytes)
mmc0: queuing unknown CIS tuple 0x1a (5 bytes)
mmc0: queuing unknown CIS tuple 0x1b (8 bytes)
mmc0: queuing unknown CIS tuple 0x14 (0 bytes)
mmc0: queuing unknown CIS tuple 0x80 (1 bytes)
mmc0: queuing unknown CIS tuple 0x81 (1 bytes)
mmc0: queuing unknown CIS tuple 0x82 (1 bytes)
mmc0: new SDIO card at address 0001
Unable to handle kernel paging request at virtual address 0a00000c
pgd = c0004000
[0a00000c] *pgd=00000000
Internal error: Oops: 5 [#1] ARM
Modules linked in:
CPU: 0 PID: 9 Comm: kworker/u2:1 Not tainted 3.11.0+ #68
Workqueue: kmmcd mmc_rescan
task: c384e800 ti: c385e000 task.ti: c385e000
PC is at vma_interval_tree_subtree_search+0x18/0x74
LR is at flush_dcache_page+0x90/0x12c
pc : [<c0064a50>] lr : [<c000f00c>] psr: 20000093
sp : c385fab8 ip : 00000000 fp : c10ca400
r10: c385fc64 r9 : c12f92fc r8 : 00000000
r7 : c2ace640 r6 : c0cc5be0 r5 : c0cd0000 r4 : c1323a00
r3 : 0a000000 r2 : c0cc5be0 r1 : c0cc5be0 r0 : c034ae48
Flags: nzCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment kernel
Control: 0005317f Table: 22b7c000 DAC: 00000017
Process kworker/u2:1 (pid: 9, stack limit = 0xc385e1b8)
Stack: (0xc385fab8 to 0xc3860000)
faa0: c1323a00 c000f00c
fac0: c0cd02d0 c2b0cb40 c385fc30 00000003 00000004 c0281380 44006d72 43495645
fae0: 0000c0ef 00000000 3a6d726f 00000000 30303038 c2b42ec0 c3868b80 0000001e
fb00: 00000000 00000000 c10f26ed 00000200 0008a000 c0049d3c c3868b80 c2b42ec0
fb20: c3868b80 00000000 ffffffff c385fb9c c0cd02d0 1408a004 00000200 c0049ed8
fb40: c3868b80 c004c384 0000001e c0049718 0000001e c0009cc8 c10f2a60 c001d7ec
fb60: 20000013 c000bf20 c10f3900 c2b0cbd8 0000184a a0000013 c2b0cbd8 ffff824a
fb80: c10f30e0 00000000 c0cd02d0 1408a004 00000200 0008a000 ffff814a c385fbb0
fba0: c001d560 c001d7ec 20000013 ffffffff c2b0cbd8 a0000013 f7cedc96 c2b07400
fbc0: c2b0cb40 c385fc40 00000001 c028207c c385fc40 c2b07400 00000004 c0270e28
fbe0: 00000200 000003e8 00000000 61666666 30303038 c2b07400 c385fc50 c385fc40
fc00: 00001000 c027100c c1323a02 00000004 c2b48000 00000001 00001000 c027a06c
fc20: 00000015 c38f2800 c2ace7c0 c002f804 c1323a02 000002d0 00000004 00000000
fc40: 00000000 c385fc94 c385fc64 00000000 00000000 c385fc54 c385fc54 c0270c3c
fc60: 00000000 3b9aca00 00000000 00000004 00000001 ffffff8d 00000200 00000000
fc80: 00000000 c385fc40 00000001 c385fc30 00000000 00000035 1408a004 00000000
fca0: 00000000 00000000 00000000 000001b5 00000000 ffffff8d 00000000 00000000
fcc0: c385fc64 c385fc40 00000007 00000004 c2bfb400 c0cd02d0 00000450 00000001
fce0: 00000000 00000004 000001ff c027af0c 00000001 c0cd02d0 00000000 00000004
fd00: 00000000 00000000 c10cf4f0 00000450 00000004 c2bfb400 c0cd02d0 00000251
fd20: 00000450 c0cd02d0 00000251 c027b010 c0cd02d0 00000004 00000450 c022d0e8
fd40: c0cd02d0 c3859000 00000004 00000251 00000000 c022d6ac 00000004 00000450
fd60: c0cd02c0 c10ce7e8 c0cd02d0 00000004 c385fdb4 c10ce7e8 ffff81c9 c022da4c
fd80: 00000251 c385fdb4 00000004 c385fddc 00000000 c0cd02c0 c03b5ccc 00000001
fda0: 00000000 c2b48008 c2bfb400 c021bb1c c0cd02c0 00000008 c385fd84 c0cd02c0
fdc0: 00000000 00000000 c03b5ccc c022c37c 00000000 c0476909 00000000 00000000
fde0: 00000000 c385fd7c c3859000 c0cd02c0 00000000 c022e010 c022de8c c2bfb400
fe00: 00000000 c10e18f0 c03b5ccc c027a32c c027a2d4 c2bfb408 00000000 c10e18f0
fe20: c01cafc8 c01cadf4 00000000 c385fe38 c2bfb408 c01c966c c38d7a1c c2ad6f34
fe40: c2bfb408 c2bfb408 c2bfb43c c2bfb408 00000000 c01cad10 c2bfb408 c10eb49c
fe60: c2bfb408 c01ca398 c2bfb408 00000000 c2bfb410 c01c898c c2bfb410 00000000
fe80: 00000000 c01818b0 00000001 c2bfb400 c2bfb408 c2bfb400 c2bfb408 00000000
fea0: c2b48000 00000001 00000000 c385fed3 c2bfb400 c027a4c4 c2b48000 c2b07400
fec0: 00000000 c0279b8c 00000000 c385fed3 00000000 10ffff00 00000000 c2b0757c
fee0: c2b07400 00000000 00061a80 c03b9d90 00000000 00000000 00000089 c0272fb8
ff00: c385df60 c2b0757c c3817200 c10f26b5 c3849c00 c00270e0 c385df60 c2b0757c
ff20: 00000081 c385df60 c3817200 c385e000 c10f26b5 c385df78 c3817200 c3817210
ff40: 00000089 c00276d0 c384e800 c384debc 00000000 c385df60 c00274c0 00000000
ff60: 00000000 00000000 00000000 c002c130 00000000 00000000 00000000 c385df60
ff80: 00000000 c385ff84 c385ff84 00000000 c385ff90 c385ff90 c385ffac c384debc
ffa0: c002c090 00000000 00000000 c00094b0 00000000 00000000 00000000 00000000
ffc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
ffe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 00000000
[<c0064a50>] (vma_interval_tree_subtree_search+0x18/0x74) from [<c000f00c>] (flush_dcache_page+0x90/0x12c)
[<c000f00c>] (flush_dcache_page+0x90/0x12c) from [<c0281380>] (atmci_interrupt+0x3cc/0x900)
[<c0281380>] (atmci_interrupt+0x3cc/0x900) from [<c0049d3c>] (handle_irq_event_percpu+0x2c/0x1a0)
[<c0049d3c>] (handle_irq_event_percpu+0x2c/0x1a0) from [<c0049ed8>] (handle_irq_event+0x28/0x38)
[<c0049ed8>] (handle_irq_event+0x28/0x38) from [<c004c384>] (handle_fasteoi_irq+0xa4/0xe4)
[<c004c384>] (handle_fasteoi_irq+0xa4/0xe4) from [<c0049718>] (generic_handle_irq+0x20/0x30)
[<c0049718>] (generic_handle_irq+0x20/0x30) from [<c0009cc8>] (handle_IRQ+0x60/0x84)
[<c0009cc8>] (handle_IRQ+0x60/0x84) from [<c000bf20>] (__irq_svc+0x40/0x4c)
[<c000bf20>] (__irq_svc+0x40/0x4c) from [<c001d7ec>] (mod_timer+0xf8/0x110)
[<c001d7ec>] (mod_timer+0xf8/0x110) from [<c028207c>] (atmci_request+0xd0/0x120)
[<c028207c>] (atmci_request+0xd0/0x120) from [<c0270e28>] (mmc_start_request+0x1e4/0x204)
[<c0270e28>] (mmc_start_request+0x1e4/0x204) from [<c027100c>] (mmc_wait_for_req+0x6c/0x16c)
[<c027100c>] (mmc_wait_for_req+0x6c/0x16c) from [<c027a06c>] (mmc_io_rw_extended+0x214/0x290)
[<c027a06c>] (mmc_io_rw_extended+0x214/0x290) from [<c027af0c>] (sdio_io_rw_ext_helper+0x160/0x1a0)
[<c027af0c>] (sdio_io_rw_ext_helper+0x160/0x1a0) from [<c027b010>] (sdio_memcpy_fromio+0x14/0x18)
[<c027b010>] (sdio_memcpy_fromio+0x14/0x18) from [<c022d0e8>] (ath6kl_sdio_io+0x88/0x9c)
[<c022d0e8>] (ath6kl_sdio_io+0x88/0x9c) from [<c022d6ac>] (ath6kl_sdio_read_write_sync+0xb0/0x100)
[<c022d6ac>] (ath6kl_sdio_read_write_sync+0xb0/0x100) from [<c022da4c>] (ath6kl_sdio_bmi_write+0x54/0xf8)
[<c022da4c>] (ath6kl_sdio_bmi_write+0x54/0xf8) from [<c021bb1c>] (ath6kl_bmi_get_target_info+0x44/0x190)
[<c021bb1c>] (ath6kl_bmi_get_target_info+0x44/0x190) from [<c022c37c>] (ath6kl_core_init+0xa4/0x404)
[<c022c37c>] (ath6kl_core_init+0xa4/0x404) from [<c022e010>] (ath6kl_sdio_probe+0x184/0x1ec)
[<c022e010>] (ath6kl_sdio_probe+0x184/0x1ec) from [<c027a32c>] (sdio_bus_probe+0x58/0x6c)
[<c027a32c>] (sdio_bus_probe+0x58/0x6c) from [<c01cadf4>] (driver_probe_device+0xac/0x1f4)
[<c01cadf4>] (driver_probe_device+0xac/0x1f4) from [<c01c966c>] (bus_for_each_drv+0x48/0x8c)
[<c01c966c>] (bus_for_each_drv+0x48/0x8c) from [<c01cad10>] (device_attach+0x68/0x80)
[<c01cad10>] (device_attach+0x68/0x80) from [<c01ca398>] (bus_probe_device+0x28/0x98)
[<c01ca398>] (bus_probe_device+0x28/0x98) from [<c01c898c>] (device_add+0x424/0x5fc)
[<c01c898c>] (device_add+0x424/0x5fc) from [<c027a4c4>] (sdio_add_func+0x34/0x4c)
[<c027a4c4>] (sdio_add_func+0x34/0x4c) from [<c0279b8c>] (mmc_attach_sdio+0x260/0x314)
[<c0279b8c>] (mmc_attach_sdio+0x260/0x314) from [<c0272fb8>] (mmc_rescan+0x22c/0x2b4)
[<c0272fb8>] (mmc_rescan+0x22c/0x2b4) from [<c00270e0>] (process_one_work+0x1f4/0x348)
[<c00270e0>] (process_one_work+0x1f4/0x348) from [<c00276d0>] (worker_thread+0x210/0x36c)
[<c00276d0>] (worker_thread+0x210/0x36c) from [<c002c130>] (kthread+0xa0/0xb0)
[<c002c130>] (kthread+0xa0/0xb0) from [<c00094b0>] (ret_from_fork+0x14/0x24)
Code: e243002c e5903034 e3530000 0a000002 (e593c00c)
---[ end trace 3f7f9bc3f451e9c9 ]---
Kernel panic - not syncing: Fatal exception in interrupt
^ permalink raw reply [flat|nested] 45+ messages in thread
* possible regression on 3.13 when calling flush_dcache_page
@ 2013-12-12 14:31 ` Ludovic Desroches
0 siblings, 0 replies; 45+ messages in thread
From: Ludovic Desroches @ 2013-12-12 14:31 UTC (permalink / raw)
To: linux-mm, linux-kernel, linux-mmc, linux-arm-kernel
Cc: ludovic.desroches, iamjoonsoo.kim
Hi,
With v3.13-rc3 I have an error when the atmel-mci driver calls
flush_dcache_page (log at the end of the message).
Since I didn't have it before, I did a git bisect and the commit introducing
the error is the following one:
106a74e slab: replace free and inuse in struct slab with newly introduced active
I don't know if this commit has introduced a bug or if it has revealed a bug
in the atmel-mci driver.
I'll investigate on atmel-mci driver side but if someone has also this issue or
see what is wrong in the driver, please tell me all about it.
Thanks
Regards
Ludovic
# mmc0: mmc_rescan_try_freq: trying to init card at 400000 Hz
mmc0: queuing unknown CIS tuple 0x01 (3 bytes)
mmc0: queuing unknown CIS tuple 0x1a (5 bytes)
mmc0: queuing unknown CIS tuple 0x1b (8 bytes)
mmc0: queuing unknown CIS tuple 0x14 (0 bytes)
mmc0: queuing unknown CIS tuple 0x80 (1 bytes)
mmc0: queuing unknown CIS tuple 0x81 (1 bytes)
mmc0: queuing unknown CIS tuple 0x82 (1 bytes)
mmc0: new SDIO card at address 0001
Unable to handle kernel paging request at virtual address 0a00000c
pgd = c0004000
[0a00000c] *pgd=00000000
Internal error: Oops: 5 [#1] ARM
Modules linked in:
CPU: 0 PID: 9 Comm: kworker/u2:1 Not tainted 3.11.0+ #68
Workqueue: kmmcd mmc_rescan
task: c384e800 ti: c385e000 task.ti: c385e000
PC is at vma_interval_tree_subtree_search+0x18/0x74
LR is at flush_dcache_page+0x90/0x12c
pc : [<c0064a50>] lr : [<c000f00c>] psr: 20000093
sp : c385fab8 ip : 00000000 fp : c10ca400
r10: c385fc64 r9 : c12f92fc r8 : 00000000
r7 : c2ace640 r6 : c0cc5be0 r5 : c0cd0000 r4 : c1323a00
r3 : 0a000000 r2 : c0cc5be0 r1 : c0cc5be0 r0 : c034ae48
Flags: nzCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment kernel
Control: 0005317f Table: 22b7c000 DAC: 00000017
Process kworker/u2:1 (pid: 9, stack limit = 0xc385e1b8)
Stack: (0xc385fab8 to 0xc3860000)
faa0: c1323a00 c000f00c
fac0: c0cd02d0 c2b0cb40 c385fc30 00000003 00000004 c0281380 44006d72 43495645
fae0: 0000c0ef 00000000 3a6d726f 00000000 30303038 c2b42ec0 c3868b80 0000001e
fb00: 00000000 00000000 c10f26ed 00000200 0008a000 c0049d3c c3868b80 c2b42ec0
fb20: c3868b80 00000000 ffffffff c385fb9c c0cd02d0 1408a004 00000200 c0049ed8
fb40: c3868b80 c004c384 0000001e c0049718 0000001e c0009cc8 c10f2a60 c001d7ec
fb60: 20000013 c000bf20 c10f3900 c2b0cbd8 0000184a a0000013 c2b0cbd8 ffff824a
fb80: c10f30e0 00000000 c0cd02d0 1408a004 00000200 0008a000 ffff814a c385fbb0
fba0: c001d560 c001d7ec 20000013 ffffffff c2b0cbd8 a0000013 f7cedc96 c2b07400
fbc0: c2b0cb40 c385fc40 00000001 c028207c c385fc40 c2b07400 00000004 c0270e28
fbe0: 00000200 000003e8 00000000 61666666 30303038 c2b07400 c385fc50 c385fc40
fc00: 00001000 c027100c c1323a02 00000004 c2b48000 00000001 00001000 c027a06c
fc20: 00000015 c38f2800 c2ace7c0 c002f804 c1323a02 000002d0 00000004 00000000
fc40: 00000000 c385fc94 c385fc64 00000000 00000000 c385fc54 c385fc54 c0270c3c
fc60: 00000000 3b9aca00 00000000 00000004 00000001 ffffff8d 00000200 00000000
fc80: 00000000 c385fc40 00000001 c385fc30 00000000 00000035 1408a004 00000000
fca0: 00000000 00000000 00000000 000001b5 00000000 ffffff8d 00000000 00000000
fcc0: c385fc64 c385fc40 00000007 00000004 c2bfb400 c0cd02d0 00000450 00000001
fce0: 00000000 00000004 000001ff c027af0c 00000001 c0cd02d0 00000000 00000004
fd00: 00000000 00000000 c10cf4f0 00000450 00000004 c2bfb400 c0cd02d0 00000251
fd20: 00000450 c0cd02d0 00000251 c027b010 c0cd02d0 00000004 00000450 c022d0e8
fd40: c0cd02d0 c3859000 00000004 00000251 00000000 c022d6ac 00000004 00000450
fd60: c0cd02c0 c10ce7e8 c0cd02d0 00000004 c385fdb4 c10ce7e8 ffff81c9 c022da4c
fd80: 00000251 c385fdb4 00000004 c385fddc 00000000 c0cd02c0 c03b5ccc 00000001
fda0: 00000000 c2b48008 c2bfb400 c021bb1c c0cd02c0 00000008 c385fd84 c0cd02c0
fdc0: 00000000 00000000 c03b5ccc c022c37c 00000000 c0476909 00000000 00000000
fde0: 00000000 c385fd7c c3859000 c0cd02c0 00000000 c022e010 c022de8c c2bfb400
fe00: 00000000 c10e18f0 c03b5ccc c027a32c c027a2d4 c2bfb408 00000000 c10e18f0
fe20: c01cafc8 c01cadf4 00000000 c385fe38 c2bfb408 c01c966c c38d7a1c c2ad6f34
fe40: c2bfb408 c2bfb408 c2bfb43c c2bfb408 00000000 c01cad10 c2bfb408 c10eb49c
fe60: c2bfb408 c01ca398 c2bfb408 00000000 c2bfb410 c01c898c c2bfb410 00000000
fe80: 00000000 c01818b0 00000001 c2bfb400 c2bfb408 c2bfb400 c2bfb408 00000000
fea0: c2b48000 00000001 00000000 c385fed3 c2bfb400 c027a4c4 c2b48000 c2b07400
fec0: 00000000 c0279b8c 00000000 c385fed3 00000000 10ffff00 00000000 c2b0757c
fee0: c2b07400 00000000 00061a80 c03b9d90 00000000 00000000 00000089 c0272fb8
ff00: c385df60 c2b0757c c3817200 c10f26b5 c3849c00 c00270e0 c385df60 c2b0757c
ff20: 00000081 c385df60 c3817200 c385e000 c10f26b5 c385df78 c3817200 c3817210
ff40: 00000089 c00276d0 c384e800 c384debc 00000000 c385df60 c00274c0 00000000
ff60: 00000000 00000000 00000000 c002c130 00000000 00000000 00000000 c385df60
ff80: 00000000 c385ff84 c385ff84 00000000 c385ff90 c385ff90 c385ffac c384debc
ffa0: c002c090 00000000 00000000 c00094b0 00000000 00000000 00000000 00000000
ffc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
ffe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 00000000
[<c0064a50>] (vma_interval_tree_subtree_search+0x18/0x74) from [<c000f00c>] (flush_dcache_page+0x90/0x12c)
[<c000f00c>] (flush_dcache_page+0x90/0x12c) from [<c0281380>] (atmci_interrupt+0x3cc/0x900)
[<c0281380>] (atmci_interrupt+0x3cc/0x900) from [<c0049d3c>] (handle_irq_event_percpu+0x2c/0x1a0)
[<c0049d3c>] (handle_irq_event_percpu+0x2c/0x1a0) from [<c0049ed8>] (handle_irq_event+0x28/0x38)
[<c0049ed8>] (handle_irq_event+0x28/0x38) from [<c004c384>] (handle_fasteoi_irq+0xa4/0xe4)
[<c004c384>] (handle_fasteoi_irq+0xa4/0xe4) from [<c0049718>] (generic_handle_irq+0x20/0x30)
[<c0049718>] (generic_handle_irq+0x20/0x30) from [<c0009cc8>] (handle_IRQ+0x60/0x84)
[<c0009cc8>] (handle_IRQ+0x60/0x84) from [<c000bf20>] (__irq_svc+0x40/0x4c)
[<c000bf20>] (__irq_svc+0x40/0x4c) from [<c001d7ec>] (mod_timer+0xf8/0x110)
[<c001d7ec>] (mod_timer+0xf8/0x110) from [<c028207c>] (atmci_request+0xd0/0x120)
[<c028207c>] (atmci_request+0xd0/0x120) from [<c0270e28>] (mmc_start_request+0x1e4/0x204)
[<c0270e28>] (mmc_start_request+0x1e4/0x204) from [<c027100c>] (mmc_wait_for_req+0x6c/0x16c)
[<c027100c>] (mmc_wait_for_req+0x6c/0x16c) from [<c027a06c>] (mmc_io_rw_extended+0x214/0x290)
[<c027a06c>] (mmc_io_rw_extended+0x214/0x290) from [<c027af0c>] (sdio_io_rw_ext_helper+0x160/0x1a0)
[<c027af0c>] (sdio_io_rw_ext_helper+0x160/0x1a0) from [<c027b010>] (sdio_memcpy_fromio+0x14/0x18)
[<c027b010>] (sdio_memcpy_fromio+0x14/0x18) from [<c022d0e8>] (ath6kl_sdio_io+0x88/0x9c)
[<c022d0e8>] (ath6kl_sdio_io+0x88/0x9c) from [<c022d6ac>] (ath6kl_sdio_read_write_sync+0xb0/0x100)
[<c022d6ac>] (ath6kl_sdio_read_write_sync+0xb0/0x100) from [<c022da4c>] (ath6kl_sdio_bmi_write+0x54/0xf8)
[<c022da4c>] (ath6kl_sdio_bmi_write+0x54/0xf8) from [<c021bb1c>] (ath6kl_bmi_get_target_info+0x44/0x190)
[<c021bb1c>] (ath6kl_bmi_get_target_info+0x44/0x190) from [<c022c37c>] (ath6kl_core_init+0xa4/0x404)
[<c022c37c>] (ath6kl_core_init+0xa4/0x404) from [<c022e010>] (ath6kl_sdio_probe+0x184/0x1ec)
[<c022e010>] (ath6kl_sdio_probe+0x184/0x1ec) from [<c027a32c>] (sdio_bus_probe+0x58/0x6c)
[<c027a32c>] (sdio_bus_probe+0x58/0x6c) from [<c01cadf4>] (driver_probe_device+0xac/0x1f4)
[<c01cadf4>] (driver_probe_device+0xac/0x1f4) from [<c01c966c>] (bus_for_each_drv+0x48/0x8c)
[<c01c966c>] (bus_for_each_drv+0x48/0x8c) from [<c01cad10>] (device_attach+0x68/0x80)
[<c01cad10>] (device_attach+0x68/0x80) from [<c01ca398>] (bus_probe_device+0x28/0x98)
[<c01ca398>] (bus_probe_device+0x28/0x98) from [<c01c898c>] (device_add+0x424/0x5fc)
[<c01c898c>] (device_add+0x424/0x5fc) from [<c027a4c4>] (sdio_add_func+0x34/0x4c)
[<c027a4c4>] (sdio_add_func+0x34/0x4c) from [<c0279b8c>] (mmc_attach_sdio+0x260/0x314)
[<c0279b8c>] (mmc_attach_sdio+0x260/0x314) from [<c0272fb8>] (mmc_rescan+0x22c/0x2b4)
[<c0272fb8>] (mmc_rescan+0x22c/0x2b4) from [<c00270e0>] (process_one_work+0x1f4/0x348)
[<c00270e0>] (process_one_work+0x1f4/0x348) from [<c00276d0>] (worker_thread+0x210/0x36c)
[<c00276d0>] (worker_thread+0x210/0x36c) from [<c002c130>] (kthread+0xa0/0xb0)
[<c002c130>] (kthread+0xa0/0xb0) from [<c00094b0>] (ret_from_fork+0x14/0x24)
Code: e243002c e5903034 e3530000 0a000002 (e593c00c)
---[ end trace 3f7f9bc3f451e9c9 ]---
Kernel panic - not syncing: Fatal exception in interrupt
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 45+ messages in thread
* possible regression on 3.13 when calling flush_dcache_page
@ 2013-12-12 14:31 ` Ludovic Desroches
0 siblings, 0 replies; 45+ messages in thread
From: Ludovic Desroches @ 2013-12-12 14:31 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
With v3.13-rc3 I have an error when the atmel-mci driver calls
flush_dcache_page (log at the end of the message).
Since I didn't have it before, I did a git bisect and the commit introducing
the error is the following one:
106a74e slab: replace free and inuse in struct slab with newly introduced active
I don't know if this commit has introduced a bug or if it has revealed a bug
in the atmel-mci driver.
I'll investigate on atmel-mci driver side but if someone has also this issue or
see what is wrong in the driver, please tell me all about it.
Thanks
Regards
Ludovic
# mmc0: mmc_rescan_try_freq: trying to init card at 400000 Hz
mmc0: queuing unknown CIS tuple 0x01 (3 bytes)
mmc0: queuing unknown CIS tuple 0x1a (5 bytes)
mmc0: queuing unknown CIS tuple 0x1b (8 bytes)
mmc0: queuing unknown CIS tuple 0x14 (0 bytes)
mmc0: queuing unknown CIS tuple 0x80 (1 bytes)
mmc0: queuing unknown CIS tuple 0x81 (1 bytes)
mmc0: queuing unknown CIS tuple 0x82 (1 bytes)
mmc0: new SDIO card at address 0001
Unable to handle kernel paging request at virtual address 0a00000c
pgd = c0004000
[0a00000c] *pgd=00000000
Internal error: Oops: 5 [#1] ARM
Modules linked in:
CPU: 0 PID: 9 Comm: kworker/u2:1 Not tainted 3.11.0+ #68
Workqueue: kmmcd mmc_rescan
task: c384e800 ti: c385e000 task.ti: c385e000
PC is at vma_interval_tree_subtree_search+0x18/0x74
LR is at flush_dcache_page+0x90/0x12c
pc : [<c0064a50>] lr : [<c000f00c>] psr: 20000093
sp : c385fab8 ip : 00000000 fp : c10ca400
r10: c385fc64 r9 : c12f92fc r8 : 00000000
r7 : c2ace640 r6 : c0cc5be0 r5 : c0cd0000 r4 : c1323a00
r3 : 0a000000 r2 : c0cc5be0 r1 : c0cc5be0 r0 : c034ae48
Flags: nzCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment kernel
Control: 0005317f Table: 22b7c000 DAC: 00000017
Process kworker/u2:1 (pid: 9, stack limit = 0xc385e1b8)
Stack: (0xc385fab8 to 0xc3860000)
faa0: c1323a00 c000f00c
fac0: c0cd02d0 c2b0cb40 c385fc30 00000003 00000004 c0281380 44006d72 43495645
fae0: 0000c0ef 00000000 3a6d726f 00000000 30303038 c2b42ec0 c3868b80 0000001e
fb00: 00000000 00000000 c10f26ed 00000200 0008a000 c0049d3c c3868b80 c2b42ec0
fb20: c3868b80 00000000 ffffffff c385fb9c c0cd02d0 1408a004 00000200 c0049ed8
fb40: c3868b80 c004c384 0000001e c0049718 0000001e c0009cc8 c10f2a60 c001d7ec
fb60: 20000013 c000bf20 c10f3900 c2b0cbd8 0000184a a0000013 c2b0cbd8 ffff824a
fb80: c10f30e0 00000000 c0cd02d0 1408a004 00000200 0008a000 ffff814a c385fbb0
fba0: c001d560 c001d7ec 20000013 ffffffff c2b0cbd8 a0000013 f7cedc96 c2b07400
fbc0: c2b0cb40 c385fc40 00000001 c028207c c385fc40 c2b07400 00000004 c0270e28
fbe0: 00000200 000003e8 00000000 61666666 30303038 c2b07400 c385fc50 c385fc40
fc00: 00001000 c027100c c1323a02 00000004 c2b48000 00000001 00001000 c027a06c
fc20: 00000015 c38f2800 c2ace7c0 c002f804 c1323a02 000002d0 00000004 00000000
fc40: 00000000 c385fc94 c385fc64 00000000 00000000 c385fc54 c385fc54 c0270c3c
fc60: 00000000 3b9aca00 00000000 00000004 00000001 ffffff8d 00000200 00000000
fc80: 00000000 c385fc40 00000001 c385fc30 00000000 00000035 1408a004 00000000
fca0: 00000000 00000000 00000000 000001b5 00000000 ffffff8d 00000000 00000000
fcc0: c385fc64 c385fc40 00000007 00000004 c2bfb400 c0cd02d0 00000450 00000001
fce0: 00000000 00000004 000001ff c027af0c 00000001 c0cd02d0 00000000 00000004
fd00: 00000000 00000000 c10cf4f0 00000450 00000004 c2bfb400 c0cd02d0 00000251
fd20: 00000450 c0cd02d0 00000251 c027b010 c0cd02d0 00000004 00000450 c022d0e8
fd40: c0cd02d0 c3859000 00000004 00000251 00000000 c022d6ac 00000004 00000450
fd60: c0cd02c0 c10ce7e8 c0cd02d0 00000004 c385fdb4 c10ce7e8 ffff81c9 c022da4c
fd80: 00000251 c385fdb4 00000004 c385fddc 00000000 c0cd02c0 c03b5ccc 00000001
fda0: 00000000 c2b48008 c2bfb400 c021bb1c c0cd02c0 00000008 c385fd84 c0cd02c0
fdc0: 00000000 00000000 c03b5ccc c022c37c 00000000 c0476909 00000000 00000000
fde0: 00000000 c385fd7c c3859000 c0cd02c0 00000000 c022e010 c022de8c c2bfb400
fe00: 00000000 c10e18f0 c03b5ccc c027a32c c027a2d4 c2bfb408 00000000 c10e18f0
fe20: c01cafc8 c01cadf4 00000000 c385fe38 c2bfb408 c01c966c c38d7a1c c2ad6f34
fe40: c2bfb408 c2bfb408 c2bfb43c c2bfb408 00000000 c01cad10 c2bfb408 c10eb49c
fe60: c2bfb408 c01ca398 c2bfb408 00000000 c2bfb410 c01c898c c2bfb410 00000000
fe80: 00000000 c01818b0 00000001 c2bfb400 c2bfb408 c2bfb400 c2bfb408 00000000
fea0: c2b48000 00000001 00000000 c385fed3 c2bfb400 c027a4c4 c2b48000 c2b07400
fec0: 00000000 c0279b8c 00000000 c385fed3 00000000 10ffff00 00000000 c2b0757c
fee0: c2b07400 00000000 00061a80 c03b9d90 00000000 00000000 00000089 c0272fb8
ff00: c385df60 c2b0757c c3817200 c10f26b5 c3849c00 c00270e0 c385df60 c2b0757c
ff20: 00000081 c385df60 c3817200 c385e000 c10f26b5 c385df78 c3817200 c3817210
ff40: 00000089 c00276d0 c384e800 c384debc 00000000 c385df60 c00274c0 00000000
ff60: 00000000 00000000 00000000 c002c130 00000000 00000000 00000000 c385df60
ff80: 00000000 c385ff84 c385ff84 00000000 c385ff90 c385ff90 c385ffac c384debc
ffa0: c002c090 00000000 00000000 c00094b0 00000000 00000000 00000000 00000000
ffc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
ffe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 00000000
[<c0064a50>] (vma_interval_tree_subtree_search+0x18/0x74) from [<c000f00c>] (flush_dcache_page+0x90/0x12c)
[<c000f00c>] (flush_dcache_page+0x90/0x12c) from [<c0281380>] (atmci_interrupt+0x3cc/0x900)
[<c0281380>] (atmci_interrupt+0x3cc/0x900) from [<c0049d3c>] (handle_irq_event_percpu+0x2c/0x1a0)
[<c0049d3c>] (handle_irq_event_percpu+0x2c/0x1a0) from [<c0049ed8>] (handle_irq_event+0x28/0x38)
[<c0049ed8>] (handle_irq_event+0x28/0x38) from [<c004c384>] (handle_fasteoi_irq+0xa4/0xe4)
[<c004c384>] (handle_fasteoi_irq+0xa4/0xe4) from [<c0049718>] (generic_handle_irq+0x20/0x30)
[<c0049718>] (generic_handle_irq+0x20/0x30) from [<c0009cc8>] (handle_IRQ+0x60/0x84)
[<c0009cc8>] (handle_IRQ+0x60/0x84) from [<c000bf20>] (__irq_svc+0x40/0x4c)
[<c000bf20>] (__irq_svc+0x40/0x4c) from [<c001d7ec>] (mod_timer+0xf8/0x110)
[<c001d7ec>] (mod_timer+0xf8/0x110) from [<c028207c>] (atmci_request+0xd0/0x120)
[<c028207c>] (atmci_request+0xd0/0x120) from [<c0270e28>] (mmc_start_request+0x1e4/0x204)
[<c0270e28>] (mmc_start_request+0x1e4/0x204) from [<c027100c>] (mmc_wait_for_req+0x6c/0x16c)
[<c027100c>] (mmc_wait_for_req+0x6c/0x16c) from [<c027a06c>] (mmc_io_rw_extended+0x214/0x290)
[<c027a06c>] (mmc_io_rw_extended+0x214/0x290) from [<c027af0c>] (sdio_io_rw_ext_helper+0x160/0x1a0)
[<c027af0c>] (sdio_io_rw_ext_helper+0x160/0x1a0) from [<c027b010>] (sdio_memcpy_fromio+0x14/0x18)
[<c027b010>] (sdio_memcpy_fromio+0x14/0x18) from [<c022d0e8>] (ath6kl_sdio_io+0x88/0x9c)
[<c022d0e8>] (ath6kl_sdio_io+0x88/0x9c) from [<c022d6ac>] (ath6kl_sdio_read_write_sync+0xb0/0x100)
[<c022d6ac>] (ath6kl_sdio_read_write_sync+0xb0/0x100) from [<c022da4c>] (ath6kl_sdio_bmi_write+0x54/0xf8)
[<c022da4c>] (ath6kl_sdio_bmi_write+0x54/0xf8) from [<c021bb1c>] (ath6kl_bmi_get_target_info+0x44/0x190)
[<c021bb1c>] (ath6kl_bmi_get_target_info+0x44/0x190) from [<c022c37c>] (ath6kl_core_init+0xa4/0x404)
[<c022c37c>] (ath6kl_core_init+0xa4/0x404) from [<c022e010>] (ath6kl_sdio_probe+0x184/0x1ec)
[<c022e010>] (ath6kl_sdio_probe+0x184/0x1ec) from [<c027a32c>] (sdio_bus_probe+0x58/0x6c)
[<c027a32c>] (sdio_bus_probe+0x58/0x6c) from [<c01cadf4>] (driver_probe_device+0xac/0x1f4)
[<c01cadf4>] (driver_probe_device+0xac/0x1f4) from [<c01c966c>] (bus_for_each_drv+0x48/0x8c)
[<c01c966c>] (bus_for_each_drv+0x48/0x8c) from [<c01cad10>] (device_attach+0x68/0x80)
[<c01cad10>] (device_attach+0x68/0x80) from [<c01ca398>] (bus_probe_device+0x28/0x98)
[<c01ca398>] (bus_probe_device+0x28/0x98) from [<c01c898c>] (device_add+0x424/0x5fc)
[<c01c898c>] (device_add+0x424/0x5fc) from [<c027a4c4>] (sdio_add_func+0x34/0x4c)
[<c027a4c4>] (sdio_add_func+0x34/0x4c) from [<c0279b8c>] (mmc_attach_sdio+0x260/0x314)
[<c0279b8c>] (mmc_attach_sdio+0x260/0x314) from [<c0272fb8>] (mmc_rescan+0x22c/0x2b4)
[<c0272fb8>] (mmc_rescan+0x22c/0x2b4) from [<c00270e0>] (process_one_work+0x1f4/0x348)
[<c00270e0>] (process_one_work+0x1f4/0x348) from [<c00276d0>] (worker_thread+0x210/0x36c)
[<c00276d0>] (worker_thread+0x210/0x36c) from [<c002c130>] (kthread+0xa0/0xb0)
[<c002c130>] (kthread+0xa0/0xb0) from [<c00094b0>] (ret_from_fork+0x14/0x24)
Code: e243002c e5903034 e3530000 0a000002 (e593c00c)
---[ end trace 3f7f9bc3f451e9c9 ]---
Kernel panic - not syncing: Fatal exception in interrupt
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: possible regression on 3.13 when calling flush_dcache_page
2013-12-12 14:31 ` Ludovic Desroches
(?)
(?)
@ 2013-12-12 14:36 ` Ludovic Desroches
-1 siblings, 0 replies; 45+ messages in thread
From: Ludovic Desroches @ 2013-12-12 14:36 UTC (permalink / raw)
To: linux-mm, linux-kernel, linux-mmc, linux-arm-kernel, iamjoonsoo.kim
Cc: Ludovic Desroches
fix mmc mailing list address error
On Thu, Dec 12, 2013 at 03:31:50PM +0100, Ludovic Desroches wrote:
> Hi,
>
> With v3.13-rc3 I have an error when the atmel-mci driver calls
> flush_dcache_page (log at the end of the message).
>
> Since I didn't have it before, I did a git bisect and the commit introducing
> the error is the following one:
>
> 106a74e slab: replace free and inuse in struct slab with newly introduced active
>
> I don't know if this commit has introduced a bug or if it has revealed a bug
> in the atmel-mci driver.
>
> I'll investigate on atmel-mci driver side but if someone has also this issue or
> see what is wrong in the driver, please tell me all about it.
>
> Thanks
>
> Regards
>
> Ludovic
>
>
> # mmc0: mmc_rescan_try_freq: trying to init card at 400000 Hz
> mmc0: queuing unknown CIS tuple 0x01 (3 bytes)
> mmc0: queuing unknown CIS tuple 0x1a (5 bytes)
> mmc0: queuing unknown CIS tuple 0x1b (8 bytes)
> mmc0: queuing unknown CIS tuple 0x14 (0 bytes)
> mmc0: queuing unknown CIS tuple 0x80 (1 bytes)
> mmc0: queuing unknown CIS tuple 0x81 (1 bytes)
> mmc0: queuing unknown CIS tuple 0x82 (1 bytes)
> mmc0: new SDIO card at address 0001
> Unable to handle kernel paging request at virtual address 0a00000c
> pgd = c0004000
> [0a00000c] *pgd=00000000
> Internal error: Oops: 5 [#1] ARM
> Modules linked in:
> CPU: 0 PID: 9 Comm: kworker/u2:1 Not tainted 3.11.0+ #68
> Workqueue: kmmcd mmc_rescan
> task: c384e800 ti: c385e000 task.ti: c385e000
> PC is at vma_interval_tree_subtree_search+0x18/0x74
> LR is at flush_dcache_page+0x90/0x12c
> pc : [<c0064a50>] lr : [<c000f00c>] psr: 20000093
> sp : c385fab8 ip : 00000000 fp : c10ca400
> r10: c385fc64 r9 : c12f92fc r8 : 00000000
> r7 : c2ace640 r6 : c0cc5be0 r5 : c0cd0000 r4 : c1323a00
> r3 : 0a000000 r2 : c0cc5be0 r1 : c0cc5be0 r0 : c034ae48
> Flags: nzCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment kernel
> Control: 0005317f Table: 22b7c000 DAC: 00000017
> Process kworker/u2:1 (pid: 9, stack limit = 0xc385e1b8)
> Stack: (0xc385fab8 to 0xc3860000)
> faa0: c1323a00 c000f00c
> fac0: c0cd02d0 c2b0cb40 c385fc30 00000003 00000004 c0281380 44006d72 43495645
> fae0: 0000c0ef 00000000 3a6d726f 00000000 30303038 c2b42ec0 c3868b80 0000001e
> fb00: 00000000 00000000 c10f26ed 00000200 0008a000 c0049d3c c3868b80 c2b42ec0
> fb20: c3868b80 00000000 ffffffff c385fb9c c0cd02d0 1408a004 00000200 c0049ed8
> fb40: c3868b80 c004c384 0000001e c0049718 0000001e c0009cc8 c10f2a60 c001d7ec
> fb60: 20000013 c000bf20 c10f3900 c2b0cbd8 0000184a a0000013 c2b0cbd8 ffff824a
> fb80: c10f30e0 00000000 c0cd02d0 1408a004 00000200 0008a000 ffff814a c385fbb0
> fba0: c001d560 c001d7ec 20000013 ffffffff c2b0cbd8 a0000013 f7cedc96 c2b07400
> fbc0: c2b0cb40 c385fc40 00000001 c028207c c385fc40 c2b07400 00000004 c0270e28
> fbe0: 00000200 000003e8 00000000 61666666 30303038 c2b07400 c385fc50 c385fc40
> fc00: 00001000 c027100c c1323a02 00000004 c2b48000 00000001 00001000 c027a06c
> fc20: 00000015 c38f2800 c2ace7c0 c002f804 c1323a02 000002d0 00000004 00000000
> fc40: 00000000 c385fc94 c385fc64 00000000 00000000 c385fc54 c385fc54 c0270c3c
> fc60: 00000000 3b9aca00 00000000 00000004 00000001 ffffff8d 00000200 00000000
> fc80: 00000000 c385fc40 00000001 c385fc30 00000000 00000035 1408a004 00000000
> fca0: 00000000 00000000 00000000 000001b5 00000000 ffffff8d 00000000 00000000
> fcc0: c385fc64 c385fc40 00000007 00000004 c2bfb400 c0cd02d0 00000450 00000001
> fce0: 00000000 00000004 000001ff c027af0c 00000001 c0cd02d0 00000000 00000004
> fd00: 00000000 00000000 c10cf4f0 00000450 00000004 c2bfb400 c0cd02d0 00000251
> fd20: 00000450 c0cd02d0 00000251 c027b010 c0cd02d0 00000004 00000450 c022d0e8
> fd40: c0cd02d0 c3859000 00000004 00000251 00000000 c022d6ac 00000004 00000450
> fd60: c0cd02c0 c10ce7e8 c0cd02d0 00000004 c385fdb4 c10ce7e8 ffff81c9 c022da4c
> fd80: 00000251 c385fdb4 00000004 c385fddc 00000000 c0cd02c0 c03b5ccc 00000001
> fda0: 00000000 c2b48008 c2bfb400 c021bb1c c0cd02c0 00000008 c385fd84 c0cd02c0
> fdc0: 00000000 00000000 c03b5ccc c022c37c 00000000 c0476909 00000000 00000000
> fde0: 00000000 c385fd7c c3859000 c0cd02c0 00000000 c022e010 c022de8c c2bfb400
> fe00: 00000000 c10e18f0 c03b5ccc c027a32c c027a2d4 c2bfb408 00000000 c10e18f0
> fe20: c01cafc8 c01cadf4 00000000 c385fe38 c2bfb408 c01c966c c38d7a1c c2ad6f34
> fe40: c2bfb408 c2bfb408 c2bfb43c c2bfb408 00000000 c01cad10 c2bfb408 c10eb49c
> fe60: c2bfb408 c01ca398 c2bfb408 00000000 c2bfb410 c01c898c c2bfb410 00000000
> fe80: 00000000 c01818b0 00000001 c2bfb400 c2bfb408 c2bfb400 c2bfb408 00000000
> fea0: c2b48000 00000001 00000000 c385fed3 c2bfb400 c027a4c4 c2b48000 c2b07400
> fec0: 00000000 c0279b8c 00000000 c385fed3 00000000 10ffff00 00000000 c2b0757c
> fee0: c2b07400 00000000 00061a80 c03b9d90 00000000 00000000 00000089 c0272fb8
> ff00: c385df60 c2b0757c c3817200 c10f26b5 c3849c00 c00270e0 c385df60 c2b0757c
> ff20: 00000081 c385df60 c3817200 c385e000 c10f26b5 c385df78 c3817200 c3817210
> ff40: 00000089 c00276d0 c384e800 c384debc 00000000 c385df60 c00274c0 00000000
> ff60: 00000000 00000000 00000000 c002c130 00000000 00000000 00000000 c385df60
> ff80: 00000000 c385ff84 c385ff84 00000000 c385ff90 c385ff90 c385ffac c384debc
> ffa0: c002c090 00000000 00000000 c00094b0 00000000 00000000 00000000 00000000
> ffc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> ffe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 00000000
> [<c0064a50>] (vma_interval_tree_subtree_search+0x18/0x74) from [<c000f00c>] (flush_dcache_page+0x90/0x12c)
> [<c000f00c>] (flush_dcache_page+0x90/0x12c) from [<c0281380>] (atmci_interrupt+0x3cc/0x900)
> [<c0281380>] (atmci_interrupt+0x3cc/0x900) from [<c0049d3c>] (handle_irq_event_percpu+0x2c/0x1a0)
> [<c0049d3c>] (handle_irq_event_percpu+0x2c/0x1a0) from [<c0049ed8>] (handle_irq_event+0x28/0x38)
> [<c0049ed8>] (handle_irq_event+0x28/0x38) from [<c004c384>] (handle_fasteoi_irq+0xa4/0xe4)
> [<c004c384>] (handle_fasteoi_irq+0xa4/0xe4) from [<c0049718>] (generic_handle_irq+0x20/0x30)
> [<c0049718>] (generic_handle_irq+0x20/0x30) from [<c0009cc8>] (handle_IRQ+0x60/0x84)
> [<c0009cc8>] (handle_IRQ+0x60/0x84) from [<c000bf20>] (__irq_svc+0x40/0x4c)
> [<c000bf20>] (__irq_svc+0x40/0x4c) from [<c001d7ec>] (mod_timer+0xf8/0x110)
> [<c001d7ec>] (mod_timer+0xf8/0x110) from [<c028207c>] (atmci_request+0xd0/0x120)
> [<c028207c>] (atmci_request+0xd0/0x120) from [<c0270e28>] (mmc_start_request+0x1e4/0x204)
> [<c0270e28>] (mmc_start_request+0x1e4/0x204) from [<c027100c>] (mmc_wait_for_req+0x6c/0x16c)
> [<c027100c>] (mmc_wait_for_req+0x6c/0x16c) from [<c027a06c>] (mmc_io_rw_extended+0x214/0x290)
> [<c027a06c>] (mmc_io_rw_extended+0x214/0x290) from [<c027af0c>] (sdio_io_rw_ext_helper+0x160/0x1a0)
> [<c027af0c>] (sdio_io_rw_ext_helper+0x160/0x1a0) from [<c027b010>] (sdio_memcpy_fromio+0x14/0x18)
> [<c027b010>] (sdio_memcpy_fromio+0x14/0x18) from [<c022d0e8>] (ath6kl_sdio_io+0x88/0x9c)
> [<c022d0e8>] (ath6kl_sdio_io+0x88/0x9c) from [<c022d6ac>] (ath6kl_sdio_read_write_sync+0xb0/0x100)
> [<c022d6ac>] (ath6kl_sdio_read_write_sync+0xb0/0x100) from [<c022da4c>] (ath6kl_sdio_bmi_write+0x54/0xf8)
> [<c022da4c>] (ath6kl_sdio_bmi_write+0x54/0xf8) from [<c021bb1c>] (ath6kl_bmi_get_target_info+0x44/0x190)
> [<c021bb1c>] (ath6kl_bmi_get_target_info+0x44/0x190) from [<c022c37c>] (ath6kl_core_init+0xa4/0x404)
> [<c022c37c>] (ath6kl_core_init+0xa4/0x404) from [<c022e010>] (ath6kl_sdio_probe+0x184/0x1ec)
> [<c022e010>] (ath6kl_sdio_probe+0x184/0x1ec) from [<c027a32c>] (sdio_bus_probe+0x58/0x6c)
> [<c027a32c>] (sdio_bus_probe+0x58/0x6c) from [<c01cadf4>] (driver_probe_device+0xac/0x1f4)
> [<c01cadf4>] (driver_probe_device+0xac/0x1f4) from [<c01c966c>] (bus_for_each_drv+0x48/0x8c)
> [<c01c966c>] (bus_for_each_drv+0x48/0x8c) from [<c01cad10>] (device_attach+0x68/0x80)
> [<c01cad10>] (device_attach+0x68/0x80) from [<c01ca398>] (bus_probe_device+0x28/0x98)
> [<c01ca398>] (bus_probe_device+0x28/0x98) from [<c01c898c>] (device_add+0x424/0x5fc)
> [<c01c898c>] (device_add+0x424/0x5fc) from [<c027a4c4>] (sdio_add_func+0x34/0x4c)
> [<c027a4c4>] (sdio_add_func+0x34/0x4c) from [<c0279b8c>] (mmc_attach_sdio+0x260/0x314)
> [<c0279b8c>] (mmc_attach_sdio+0x260/0x314) from [<c0272fb8>] (mmc_rescan+0x22c/0x2b4)
> [<c0272fb8>] (mmc_rescan+0x22c/0x2b4) from [<c00270e0>] (process_one_work+0x1f4/0x348)
> [<c00270e0>] (process_one_work+0x1f4/0x348) from [<c00276d0>] (worker_thread+0x210/0x36c)
> [<c00276d0>] (worker_thread+0x210/0x36c) from [<c002c130>] (kthread+0xa0/0xb0)
> [<c002c130>] (kthread+0xa0/0xb0) from [<c00094b0>] (ret_from_fork+0x14/0x24)
> Code: e243002c e5903034 e3530000 0a000002 (e593c00c)
> ---[ end trace 3f7f9bc3f451e9c9 ]---
> Kernel panic - not syncing: Fatal exception in interrupt
>
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: possible regression on 3.13 when calling flush_dcache_page
@ 2013-12-12 14:36 ` Ludovic Desroches
0 siblings, 0 replies; 45+ messages in thread
From: Ludovic Desroches @ 2013-12-12 14:36 UTC (permalink / raw)
To: linux-mm, linux-kernel, linux-mmc, linux-arm-kernel, iamjoonsoo.kim
Cc: Ludovic Desroches
fix mmc mailing list address error
On Thu, Dec 12, 2013 at 03:31:50PM +0100, Ludovic Desroches wrote:
> Hi,
>
> With v3.13-rc3 I have an error when the atmel-mci driver calls
> flush_dcache_page (log at the end of the message).
>
> Since I didn't have it before, I did a git bisect and the commit introducing
> the error is the following one:
>
> 106a74e slab: replace free and inuse in struct slab with newly introduced active
>
> I don't know if this commit has introduced a bug or if it has revealed a bug
> in the atmel-mci driver.
>
> I'll investigate on atmel-mci driver side but if someone has also this issue or
> see what is wrong in the driver, please tell me all about it.
>
> Thanks
>
> Regards
>
> Ludovic
>
>
> # mmc0: mmc_rescan_try_freq: trying to init card at 400000 Hz
> mmc0: queuing unknown CIS tuple 0x01 (3 bytes)
> mmc0: queuing unknown CIS tuple 0x1a (5 bytes)
> mmc0: queuing unknown CIS tuple 0x1b (8 bytes)
> mmc0: queuing unknown CIS tuple 0x14 (0 bytes)
> mmc0: queuing unknown CIS tuple 0x80 (1 bytes)
> mmc0: queuing unknown CIS tuple 0x81 (1 bytes)
> mmc0: queuing unknown CIS tuple 0x82 (1 bytes)
> mmc0: new SDIO card at address 0001
> Unable to handle kernel paging request at virtual address 0a00000c
> pgd = c0004000
> [0a00000c] *pgd=00000000
> Internal error: Oops: 5 [#1] ARM
> Modules linked in:
> CPU: 0 PID: 9 Comm: kworker/u2:1 Not tainted 3.11.0+ #68
> Workqueue: kmmcd mmc_rescan
> task: c384e800 ti: c385e000 task.ti: c385e000
> PC is at vma_interval_tree_subtree_search+0x18/0x74
> LR is at flush_dcache_page+0x90/0x12c
> pc : [<c0064a50>] lr : [<c000f00c>] psr: 20000093
> sp : c385fab8 ip : 00000000 fp : c10ca400
> r10: c385fc64 r9 : c12f92fc r8 : 00000000
> r7 : c2ace640 r6 : c0cc5be0 r5 : c0cd0000 r4 : c1323a00
> r3 : 0a000000 r2 : c0cc5be0 r1 : c0cc5be0 r0 : c034ae48
> Flags: nzCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment kernel
> Control: 0005317f Table: 22b7c000 DAC: 00000017
> Process kworker/u2:1 (pid: 9, stack limit = 0xc385e1b8)
> Stack: (0xc385fab8 to 0xc3860000)
> faa0: c1323a00 c000f00c
> fac0: c0cd02d0 c2b0cb40 c385fc30 00000003 00000004 c0281380 44006d72 43495645
> fae0: 0000c0ef 00000000 3a6d726f 00000000 30303038 c2b42ec0 c3868b80 0000001e
> fb00: 00000000 00000000 c10f26ed 00000200 0008a000 c0049d3c c3868b80 c2b42ec0
> fb20: c3868b80 00000000 ffffffff c385fb9c c0cd02d0 1408a004 00000200 c0049ed8
> fb40: c3868b80 c004c384 0000001e c0049718 0000001e c0009cc8 c10f2a60 c001d7ec
> fb60: 20000013 c000bf20 c10f3900 c2b0cbd8 0000184a a0000013 c2b0cbd8 ffff824a
> fb80: c10f30e0 00000000 c0cd02d0 1408a004 00000200 0008a000 ffff814a c385fbb0
> fba0: c001d560 c001d7ec 20000013 ffffffff c2b0cbd8 a0000013 f7cedc96 c2b07400
> fbc0: c2b0cb40 c385fc40 00000001 c028207c c385fc40 c2b07400 00000004 c0270e28
> fbe0: 00000200 000003e8 00000000 61666666 30303038 c2b07400 c385fc50 c385fc40
> fc00: 00001000 c027100c c1323a02 00000004 c2b48000 00000001 00001000 c027a06c
> fc20: 00000015 c38f2800 c2ace7c0 c002f804 c1323a02 000002d0 00000004 00000000
> fc40: 00000000 c385fc94 c385fc64 00000000 00000000 c385fc54 c385fc54 c0270c3c
> fc60: 00000000 3b9aca00 00000000 00000004 00000001 ffffff8d 00000200 00000000
> fc80: 00000000 c385fc40 00000001 c385fc30 00000000 00000035 1408a004 00000000
> fca0: 00000000 00000000 00000000 000001b5 00000000 ffffff8d 00000000 00000000
> fcc0: c385fc64 c385fc40 00000007 00000004 c2bfb400 c0cd02d0 00000450 00000001
> fce0: 00000000 00000004 000001ff c027af0c 00000001 c0cd02d0 00000000 00000004
> fd00: 00000000 00000000 c10cf4f0 00000450 00000004 c2bfb400 c0cd02d0 00000251
> fd20: 00000450 c0cd02d0 00000251 c027b010 c0cd02d0 00000004 00000450 c022d0e8
> fd40: c0cd02d0 c3859000 00000004 00000251 00000000 c022d6ac 00000004 00000450
> fd60: c0cd02c0 c10ce7e8 c0cd02d0 00000004 c385fdb4 c10ce7e8 ffff81c9 c022da4c
> fd80: 00000251 c385fdb4 00000004 c385fddc 00000000 c0cd02c0 c03b5ccc 00000001
> fda0: 00000000 c2b48008 c2bfb400 c021bb1c c0cd02c0 00000008 c385fd84 c0cd02c0
> fdc0: 00000000 00000000 c03b5ccc c022c37c 00000000 c0476909 00000000 00000000
> fde0: 00000000 c385fd7c c3859000 c0cd02c0 00000000 c022e010 c022de8c c2bfb400
> fe00: 00000000 c10e18f0 c03b5ccc c027a32c c027a2d4 c2bfb408 00000000 c10e18f0
> fe20: c01cafc8 c01cadf4 00000000 c385fe38 c2bfb408 c01c966c c38d7a1c c2ad6f34
> fe40: c2bfb408 c2bfb408 c2bfb43c c2bfb408 00000000 c01cad10 c2bfb408 c10eb49c
> fe60: c2bfb408 c01ca398 c2bfb408 00000000 c2bfb410 c01c898c c2bfb410 00000000
> fe80: 00000000 c01818b0 00000001 c2bfb400 c2bfb408 c2bfb400 c2bfb408 00000000
> fea0: c2b48000 00000001 00000000 c385fed3 c2bfb400 c027a4c4 c2b48000 c2b07400
> fec0: 00000000 c0279b8c 00000000 c385fed3 00000000 10ffff00 00000000 c2b0757c
> fee0: c2b07400 00000000 00061a80 c03b9d90 00000000 00000000 00000089 c0272fb8
> ff00: c385df60 c2b0757c c3817200 c10f26b5 c3849c00 c00270e0 c385df60 c2b0757c
> ff20: 00000081 c385df60 c3817200 c385e000 c10f26b5 c385df78 c3817200 c3817210
> ff40: 00000089 c00276d0 c384e800 c384debc 00000000 c385df60 c00274c0 00000000
> ff60: 00000000 00000000 00000000 c002c130 00000000 00000000 00000000 c385df60
> ff80: 00000000 c385ff84 c385ff84 00000000 c385ff90 c385ff90 c385ffac c384debc
> ffa0: c002c090 00000000 00000000 c00094b0 00000000 00000000 00000000 00000000
> ffc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> ffe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 00000000
> [<c0064a50>] (vma_interval_tree_subtree_search+0x18/0x74) from [<c000f00c>] (flush_dcache_page+0x90/0x12c)
> [<c000f00c>] (flush_dcache_page+0x90/0x12c) from [<c0281380>] (atmci_interrupt+0x3cc/0x900)
> [<c0281380>] (atmci_interrupt+0x3cc/0x900) from [<c0049d3c>] (handle_irq_event_percpu+0x2c/0x1a0)
> [<c0049d3c>] (handle_irq_event_percpu+0x2c/0x1a0) from [<c0049ed8>] (handle_irq_event+0x28/0x38)
> [<c0049ed8>] (handle_irq_event+0x28/0x38) from [<c004c384>] (handle_fasteoi_irq+0xa4/0xe4)
> [<c004c384>] (handle_fasteoi_irq+0xa4/0xe4) from [<c0049718>] (generic_handle_irq+0x20/0x30)
> [<c0049718>] (generic_handle_irq+0x20/0x30) from [<c0009cc8>] (handle_IRQ+0x60/0x84)
> [<c0009cc8>] (handle_IRQ+0x60/0x84) from [<c000bf20>] (__irq_svc+0x40/0x4c)
> [<c000bf20>] (__irq_svc+0x40/0x4c) from [<c001d7ec>] (mod_timer+0xf8/0x110)
> [<c001d7ec>] (mod_timer+0xf8/0x110) from [<c028207c>] (atmci_request+0xd0/0x120)
> [<c028207c>] (atmci_request+0xd0/0x120) from [<c0270e28>] (mmc_start_request+0x1e4/0x204)
> [<c0270e28>] (mmc_start_request+0x1e4/0x204) from [<c027100c>] (mmc_wait_for_req+0x6c/0x16c)
> [<c027100c>] (mmc_wait_for_req+0x6c/0x16c) from [<c027a06c>] (mmc_io_rw_extended+0x214/0x290)
> [<c027a06c>] (mmc_io_rw_extended+0x214/0x290) from [<c027af0c>] (sdio_io_rw_ext_helper+0x160/0x1a0)
> [<c027af0c>] (sdio_io_rw_ext_helper+0x160/0x1a0) from [<c027b010>] (sdio_memcpy_fromio+0x14/0x18)
> [<c027b010>] (sdio_memcpy_fromio+0x14/0x18) from [<c022d0e8>] (ath6kl_sdio_io+0x88/0x9c)
> [<c022d0e8>] (ath6kl_sdio_io+0x88/0x9c) from [<c022d6ac>] (ath6kl_sdio_read_write_sync+0xb0/0x100)
> [<c022d6ac>] (ath6kl_sdio_read_write_sync+0xb0/0x100) from [<c022da4c>] (ath6kl_sdio_bmi_write+0x54/0xf8)
> [<c022da4c>] (ath6kl_sdio_bmi_write+0x54/0xf8) from [<c021bb1c>] (ath6kl_bmi_get_target_info+0x44/0x190)
> [<c021bb1c>] (ath6kl_bmi_get_target_info+0x44/0x190) from [<c022c37c>] (ath6kl_core_init+0xa4/0x404)
> [<c022c37c>] (ath6kl_core_init+0xa4/0x404) from [<c022e010>] (ath6kl_sdio_probe+0x184/0x1ec)
> [<c022e010>] (ath6kl_sdio_probe+0x184/0x1ec) from [<c027a32c>] (sdio_bus_probe+0x58/0x6c)
> [<c027a32c>] (sdio_bus_probe+0x58/0x6c) from [<c01cadf4>] (driver_probe_device+0xac/0x1f4)
> [<c01cadf4>] (driver_probe_device+0xac/0x1f4) from [<c01c966c>] (bus_for_each_drv+0x48/0x8c)
> [<c01c966c>] (bus_for_each_drv+0x48/0x8c) from [<c01cad10>] (device_attach+0x68/0x80)
> [<c01cad10>] (device_attach+0x68/0x80) from [<c01ca398>] (bus_probe_device+0x28/0x98)
> [<c01ca398>] (bus_probe_device+0x28/0x98) from [<c01c898c>] (device_add+0x424/0x5fc)
> [<c01c898c>] (device_add+0x424/0x5fc) from [<c027a4c4>] (sdio_add_func+0x34/0x4c)
> [<c027a4c4>] (sdio_add_func+0x34/0x4c) from [<c0279b8c>] (mmc_attach_sdio+0x260/0x314)
> [<c0279b8c>] (mmc_attach_sdio+0x260/0x314) from [<c0272fb8>] (mmc_rescan+0x22c/0x2b4)
> [<c0272fb8>] (mmc_rescan+0x22c/0x2b4) from [<c00270e0>] (process_one_work+0x1f4/0x348)
> [<c00270e0>] (process_one_work+0x1f4/0x348) from [<c00276d0>] (worker_thread+0x210/0x36c)
> [<c00276d0>] (worker_thread+0x210/0x36c) from [<c002c130>] (kthread+0xa0/0xb0)
> [<c002c130>] (kthread+0xa0/0xb0) from [<c00094b0>] (ret_from_fork+0x14/0x24)
> Code: e243002c e5903034 e3530000 0a000002 (e593c00c)
> ---[ end trace 3f7f9bc3f451e9c9 ]---
> Kernel panic - not syncing: Fatal exception in interrupt
>
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: possible regression on 3.13 when calling flush_dcache_page
@ 2013-12-12 14:36 ` Ludovic Desroches
0 siblings, 0 replies; 45+ messages in thread
From: Ludovic Desroches @ 2013-12-12 14:36 UTC (permalink / raw)
To: linux-mm, linux-kernel, linux-mmc, linux-arm-kernel, iamjoonsoo.kim
Cc: Ludovic Desroches
fix mmc mailing list address error
On Thu, Dec 12, 2013 at 03:31:50PM +0100, Ludovic Desroches wrote:
> Hi,
>
> With v3.13-rc3 I have an error when the atmel-mci driver calls
> flush_dcache_page (log at the end of the message).
>
> Since I didn't have it before, I did a git bisect and the commit introducing
> the error is the following one:
>
> 106a74e slab: replace free and inuse in struct slab with newly introduced active
>
> I don't know if this commit has introduced a bug or if it has revealed a bug
> in the atmel-mci driver.
>
> I'll investigate on atmel-mci driver side but if someone has also this issue or
> see what is wrong in the driver, please tell me all about it.
>
> Thanks
>
> Regards
>
> Ludovic
>
>
> # mmc0: mmc_rescan_try_freq: trying to init card at 400000 Hz
> mmc0: queuing unknown CIS tuple 0x01 (3 bytes)
> mmc0: queuing unknown CIS tuple 0x1a (5 bytes)
> mmc0: queuing unknown CIS tuple 0x1b (8 bytes)
> mmc0: queuing unknown CIS tuple 0x14 (0 bytes)
> mmc0: queuing unknown CIS tuple 0x80 (1 bytes)
> mmc0: queuing unknown CIS tuple 0x81 (1 bytes)
> mmc0: queuing unknown CIS tuple 0x82 (1 bytes)
> mmc0: new SDIO card at address 0001
> Unable to handle kernel paging request at virtual address 0a00000c
> pgd = c0004000
> [0a00000c] *pgd=00000000
> Internal error: Oops: 5 [#1] ARM
> Modules linked in:
> CPU: 0 PID: 9 Comm: kworker/u2:1 Not tainted 3.11.0+ #68
> Workqueue: kmmcd mmc_rescan
> task: c384e800 ti: c385e000 task.ti: c385e000
> PC is at vma_interval_tree_subtree_search+0x18/0x74
> LR is at flush_dcache_page+0x90/0x12c
> pc : [<c0064a50>] lr : [<c000f00c>] psr: 20000093
> sp : c385fab8 ip : 00000000 fp : c10ca400
> r10: c385fc64 r9 : c12f92fc r8 : 00000000
> r7 : c2ace640 r6 : c0cc5be0 r5 : c0cd0000 r4 : c1323a00
> r3 : 0a000000 r2 : c0cc5be0 r1 : c0cc5be0 r0 : c034ae48
> Flags: nzCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment kernel
> Control: 0005317f Table: 22b7c000 DAC: 00000017
> Process kworker/u2:1 (pid: 9, stack limit = 0xc385e1b8)
> Stack: (0xc385fab8 to 0xc3860000)
> faa0: c1323a00 c000f00c
> fac0: c0cd02d0 c2b0cb40 c385fc30 00000003 00000004 c0281380 44006d72 43495645
> fae0: 0000c0ef 00000000 3a6d726f 00000000 30303038 c2b42ec0 c3868b80 0000001e
> fb00: 00000000 00000000 c10f26ed 00000200 0008a000 c0049d3c c3868b80 c2b42ec0
> fb20: c3868b80 00000000 ffffffff c385fb9c c0cd02d0 1408a004 00000200 c0049ed8
> fb40: c3868b80 c004c384 0000001e c0049718 0000001e c0009cc8 c10f2a60 c001d7ec
> fb60: 20000013 c000bf20 c10f3900 c2b0cbd8 0000184a a0000013 c2b0cbd8 ffff824a
> fb80: c10f30e0 00000000 c0cd02d0 1408a004 00000200 0008a000 ffff814a c385fbb0
> fba0: c001d560 c001d7ec 20000013 ffffffff c2b0cbd8 a0000013 f7cedc96 c2b07400
> fbc0: c2b0cb40 c385fc40 00000001 c028207c c385fc40 c2b07400 00000004 c0270e28
> fbe0: 00000200 000003e8 00000000 61666666 30303038 c2b07400 c385fc50 c385fc40
> fc00: 00001000 c027100c c1323a02 00000004 c2b48000 00000001 00001000 c027a06c
> fc20: 00000015 c38f2800 c2ace7c0 c002f804 c1323a02 000002d0 00000004 00000000
> fc40: 00000000 c385fc94 c385fc64 00000000 00000000 c385fc54 c385fc54 c0270c3c
> fc60: 00000000 3b9aca00 00000000 00000004 00000001 ffffff8d 00000200 00000000
> fc80: 00000000 c385fc40 00000001 c385fc30 00000000 00000035 1408a004 00000000
> fca0: 00000000 00000000 00000000 000001b5 00000000 ffffff8d 00000000 00000000
> fcc0: c385fc64 c385fc40 00000007 00000004 c2bfb400 c0cd02d0 00000450 00000001
> fce0: 00000000 00000004 000001ff c027af0c 00000001 c0cd02d0 00000000 00000004
> fd00: 00000000 00000000 c10cf4f0 00000450 00000004 c2bfb400 c0cd02d0 00000251
> fd20: 00000450 c0cd02d0 00000251 c027b010 c0cd02d0 00000004 00000450 c022d0e8
> fd40: c0cd02d0 c3859000 00000004 00000251 00000000 c022d6ac 00000004 00000450
> fd60: c0cd02c0 c10ce7e8 c0cd02d0 00000004 c385fdb4 c10ce7e8 ffff81c9 c022da4c
> fd80: 00000251 c385fdb4 00000004 c385fddc 00000000 c0cd02c0 c03b5ccc 00000001
> fda0: 00000000 c2b48008 c2bfb400 c021bb1c c0cd02c0 00000008 c385fd84 c0cd02c0
> fdc0: 00000000 00000000 c03b5ccc c022c37c 00000000 c0476909 00000000 00000000
> fde0: 00000000 c385fd7c c3859000 c0cd02c0 00000000 c022e010 c022de8c c2bfb400
> fe00: 00000000 c10e18f0 c03b5ccc c027a32c c027a2d4 c2bfb408 00000000 c10e18f0
> fe20: c01cafc8 c01cadf4 00000000 c385fe38 c2bfb408 c01c966c c38d7a1c c2ad6f34
> fe40: c2bfb408 c2bfb408 c2bfb43c c2bfb408 00000000 c01cad10 c2bfb408 c10eb49c
> fe60: c2bfb408 c01ca398 c2bfb408 00000000 c2bfb410 c01c898c c2bfb410 00000000
> fe80: 00000000 c01818b0 00000001 c2bfb400 c2bfb408 c2bfb400 c2bfb408 00000000
> fea0: c2b48000 00000001 00000000 c385fed3 c2bfb400 c027a4c4 c2b48000 c2b07400
> fec0: 00000000 c0279b8c 00000000 c385fed3 00000000 10ffff00 00000000 c2b0757c
> fee0: c2b07400 00000000 00061a80 c03b9d90 00000000 00000000 00000089 c0272fb8
> ff00: c385df60 c2b0757c c3817200 c10f26b5 c3849c00 c00270e0 c385df60 c2b0757c
> ff20: 00000081 c385df60 c3817200 c385e000 c10f26b5 c385df78 c3817200 c3817210
> ff40: 00000089 c00276d0 c384e800 c384debc 00000000 c385df60 c00274c0 00000000
> ff60: 00000000 00000000 00000000 c002c130 00000000 00000000 00000000 c385df60
> ff80: 00000000 c385ff84 c385ff84 00000000 c385ff90 c385ff90 c385ffac c384debc
> ffa0: c002c090 00000000 00000000 c00094b0 00000000 00000000 00000000 00000000
> ffc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> ffe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 00000000
> [<c0064a50>] (vma_interval_tree_subtree_search+0x18/0x74) from [<c000f00c>] (flush_dcache_page+0x90/0x12c)
> [<c000f00c>] (flush_dcache_page+0x90/0x12c) from [<c0281380>] (atmci_interrupt+0x3cc/0x900)
> [<c0281380>] (atmci_interrupt+0x3cc/0x900) from [<c0049d3c>] (handle_irq_event_percpu+0x2c/0x1a0)
> [<c0049d3c>] (handle_irq_event_percpu+0x2c/0x1a0) from [<c0049ed8>] (handle_irq_event+0x28/0x38)
> [<c0049ed8>] (handle_irq_event+0x28/0x38) from [<c004c384>] (handle_fasteoi_irq+0xa4/0xe4)
> [<c004c384>] (handle_fasteoi_irq+0xa4/0xe4) from [<c0049718>] (generic_handle_irq+0x20/0x30)
> [<c0049718>] (generic_handle_irq+0x20/0x30) from [<c0009cc8>] (handle_IRQ+0x60/0x84)
> [<c0009cc8>] (handle_IRQ+0x60/0x84) from [<c000bf20>] (__irq_svc+0x40/0x4c)
> [<c000bf20>] (__irq_svc+0x40/0x4c) from [<c001d7ec>] (mod_timer+0xf8/0x110)
> [<c001d7ec>] (mod_timer+0xf8/0x110) from [<c028207c>] (atmci_request+0xd0/0x120)
> [<c028207c>] (atmci_request+0xd0/0x120) from [<c0270e28>] (mmc_start_request+0x1e4/0x204)
> [<c0270e28>] (mmc_start_request+0x1e4/0x204) from [<c027100c>] (mmc_wait_for_req+0x6c/0x16c)
> [<c027100c>] (mmc_wait_for_req+0x6c/0x16c) from [<c027a06c>] (mmc_io_rw_extended+0x214/0x290)
> [<c027a06c>] (mmc_io_rw_extended+0x214/0x290) from [<c027af0c>] (sdio_io_rw_ext_helper+0x160/0x1a0)
> [<c027af0c>] (sdio_io_rw_ext_helper+0x160/0x1a0) from [<c027b010>] (sdio_memcpy_fromio+0x14/0x18)
> [<c027b010>] (sdio_memcpy_fromio+0x14/0x18) from [<c022d0e8>] (ath6kl_sdio_io+0x88/0x9c)
> [<c022d0e8>] (ath6kl_sdio_io+0x88/0x9c) from [<c022d6ac>] (ath6kl_sdio_read_write_sync+0xb0/0x100)
> [<c022d6ac>] (ath6kl_sdio_read_write_sync+0xb0/0x100) from [<c022da4c>] (ath6kl_sdio_bmi_write+0x54/0xf8)
> [<c022da4c>] (ath6kl_sdio_bmi_write+0x54/0xf8) from [<c021bb1c>] (ath6kl_bmi_get_target_info+0x44/0x190)
> [<c021bb1c>] (ath6kl_bmi_get_target_info+0x44/0x190) from [<c022c37c>] (ath6kl_core_init+0xa4/0x404)
> [<c022c37c>] (ath6kl_core_init+0xa4/0x404) from [<c022e010>] (ath6kl_sdio_probe+0x184/0x1ec)
> [<c022e010>] (ath6kl_sdio_probe+0x184/0x1ec) from [<c027a32c>] (sdio_bus_probe+0x58/0x6c)
> [<c027a32c>] (sdio_bus_probe+0x58/0x6c) from [<c01cadf4>] (driver_probe_device+0xac/0x1f4)
> [<c01cadf4>] (driver_probe_device+0xac/0x1f4) from [<c01c966c>] (bus_for_each_drv+0x48/0x8c)
> [<c01c966c>] (bus_for_each_drv+0x48/0x8c) from [<c01cad10>] (device_attach+0x68/0x80)
> [<c01cad10>] (device_attach+0x68/0x80) from [<c01ca398>] (bus_probe_device+0x28/0x98)
> [<c01ca398>] (bus_probe_device+0x28/0x98) from [<c01c898c>] (device_add+0x424/0x5fc)
> [<c01c898c>] (device_add+0x424/0x5fc) from [<c027a4c4>] (sdio_add_func+0x34/0x4c)
> [<c027a4c4>] (sdio_add_func+0x34/0x4c) from [<c0279b8c>] (mmc_attach_sdio+0x260/0x314)
> [<c0279b8c>] (mmc_attach_sdio+0x260/0x314) from [<c0272fb8>] (mmc_rescan+0x22c/0x2b4)
> [<c0272fb8>] (mmc_rescan+0x22c/0x2b4) from [<c00270e0>] (process_one_work+0x1f4/0x348)
> [<c00270e0>] (process_one_work+0x1f4/0x348) from [<c00276d0>] (worker_thread+0x210/0x36c)
> [<c00276d0>] (worker_thread+0x210/0x36c) from [<c002c130>] (kthread+0xa0/0xb0)
> [<c002c130>] (kthread+0xa0/0xb0) from [<c00094b0>] (ret_from_fork+0x14/0x24)
> Code: e243002c e5903034 e3530000 0a000002 (e593c00c)
> ---[ end trace 3f7f9bc3f451e9c9 ]---
> Kernel panic - not syncing: Fatal exception in interrupt
>
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 45+ messages in thread
* possible regression on 3.13 when calling flush_dcache_page
@ 2013-12-12 14:36 ` Ludovic Desroches
0 siblings, 0 replies; 45+ messages in thread
From: Ludovic Desroches @ 2013-12-12 14:36 UTC (permalink / raw)
To: linux-arm-kernel
fix mmc mailing list address error
On Thu, Dec 12, 2013 at 03:31:50PM +0100, Ludovic Desroches wrote:
> Hi,
>
> With v3.13-rc3 I have an error when the atmel-mci driver calls
> flush_dcache_page (log at the end of the message).
>
> Since I didn't have it before, I did a git bisect and the commit introducing
> the error is the following one:
>
> 106a74e slab: replace free and inuse in struct slab with newly introduced active
>
> I don't know if this commit has introduced a bug or if it has revealed a bug
> in the atmel-mci driver.
>
> I'll investigate on atmel-mci driver side but if someone has also this issue or
> see what is wrong in the driver, please tell me all about it.
>
> Thanks
>
> Regards
>
> Ludovic
>
>
> # mmc0: mmc_rescan_try_freq: trying to init card at 400000 Hz
> mmc0: queuing unknown CIS tuple 0x01 (3 bytes)
> mmc0: queuing unknown CIS tuple 0x1a (5 bytes)
> mmc0: queuing unknown CIS tuple 0x1b (8 bytes)
> mmc0: queuing unknown CIS tuple 0x14 (0 bytes)
> mmc0: queuing unknown CIS tuple 0x80 (1 bytes)
> mmc0: queuing unknown CIS tuple 0x81 (1 bytes)
> mmc0: queuing unknown CIS tuple 0x82 (1 bytes)
> mmc0: new SDIO card at address 0001
> Unable to handle kernel paging request at virtual address 0a00000c
> pgd = c0004000
> [0a00000c] *pgd=00000000
> Internal error: Oops: 5 [#1] ARM
> Modules linked in:
> CPU: 0 PID: 9 Comm: kworker/u2:1 Not tainted 3.11.0+ #68
> Workqueue: kmmcd mmc_rescan
> task: c384e800 ti: c385e000 task.ti: c385e000
> PC is at vma_interval_tree_subtree_search+0x18/0x74
> LR is at flush_dcache_page+0x90/0x12c
> pc : [<c0064a50>] lr : [<c000f00c>] psr: 20000093
> sp : c385fab8 ip : 00000000 fp : c10ca400
> r10: c385fc64 r9 : c12f92fc r8 : 00000000
> r7 : c2ace640 r6 : c0cc5be0 r5 : c0cd0000 r4 : c1323a00
> r3 : 0a000000 r2 : c0cc5be0 r1 : c0cc5be0 r0 : c034ae48
> Flags: nzCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment kernel
> Control: 0005317f Table: 22b7c000 DAC: 00000017
> Process kworker/u2:1 (pid: 9, stack limit = 0xc385e1b8)
> Stack: (0xc385fab8 to 0xc3860000)
> faa0: c1323a00 c000f00c
> fac0: c0cd02d0 c2b0cb40 c385fc30 00000003 00000004 c0281380 44006d72 43495645
> fae0: 0000c0ef 00000000 3a6d726f 00000000 30303038 c2b42ec0 c3868b80 0000001e
> fb00: 00000000 00000000 c10f26ed 00000200 0008a000 c0049d3c c3868b80 c2b42ec0
> fb20: c3868b80 00000000 ffffffff c385fb9c c0cd02d0 1408a004 00000200 c0049ed8
> fb40: c3868b80 c004c384 0000001e c0049718 0000001e c0009cc8 c10f2a60 c001d7ec
> fb60: 20000013 c000bf20 c10f3900 c2b0cbd8 0000184a a0000013 c2b0cbd8 ffff824a
> fb80: c10f30e0 00000000 c0cd02d0 1408a004 00000200 0008a000 ffff814a c385fbb0
> fba0: c001d560 c001d7ec 20000013 ffffffff c2b0cbd8 a0000013 f7cedc96 c2b07400
> fbc0: c2b0cb40 c385fc40 00000001 c028207c c385fc40 c2b07400 00000004 c0270e28
> fbe0: 00000200 000003e8 00000000 61666666 30303038 c2b07400 c385fc50 c385fc40
> fc00: 00001000 c027100c c1323a02 00000004 c2b48000 00000001 00001000 c027a06c
> fc20: 00000015 c38f2800 c2ace7c0 c002f804 c1323a02 000002d0 00000004 00000000
> fc40: 00000000 c385fc94 c385fc64 00000000 00000000 c385fc54 c385fc54 c0270c3c
> fc60: 00000000 3b9aca00 00000000 00000004 00000001 ffffff8d 00000200 00000000
> fc80: 00000000 c385fc40 00000001 c385fc30 00000000 00000035 1408a004 00000000
> fca0: 00000000 00000000 00000000 000001b5 00000000 ffffff8d 00000000 00000000
> fcc0: c385fc64 c385fc40 00000007 00000004 c2bfb400 c0cd02d0 00000450 00000001
> fce0: 00000000 00000004 000001ff c027af0c 00000001 c0cd02d0 00000000 00000004
> fd00: 00000000 00000000 c10cf4f0 00000450 00000004 c2bfb400 c0cd02d0 00000251
> fd20: 00000450 c0cd02d0 00000251 c027b010 c0cd02d0 00000004 00000450 c022d0e8
> fd40: c0cd02d0 c3859000 00000004 00000251 00000000 c022d6ac 00000004 00000450
> fd60: c0cd02c0 c10ce7e8 c0cd02d0 00000004 c385fdb4 c10ce7e8 ffff81c9 c022da4c
> fd80: 00000251 c385fdb4 00000004 c385fddc 00000000 c0cd02c0 c03b5ccc 00000001
> fda0: 00000000 c2b48008 c2bfb400 c021bb1c c0cd02c0 00000008 c385fd84 c0cd02c0
> fdc0: 00000000 00000000 c03b5ccc c022c37c 00000000 c0476909 00000000 00000000
> fde0: 00000000 c385fd7c c3859000 c0cd02c0 00000000 c022e010 c022de8c c2bfb400
> fe00: 00000000 c10e18f0 c03b5ccc c027a32c c027a2d4 c2bfb408 00000000 c10e18f0
> fe20: c01cafc8 c01cadf4 00000000 c385fe38 c2bfb408 c01c966c c38d7a1c c2ad6f34
> fe40: c2bfb408 c2bfb408 c2bfb43c c2bfb408 00000000 c01cad10 c2bfb408 c10eb49c
> fe60: c2bfb408 c01ca398 c2bfb408 00000000 c2bfb410 c01c898c c2bfb410 00000000
> fe80: 00000000 c01818b0 00000001 c2bfb400 c2bfb408 c2bfb400 c2bfb408 00000000
> fea0: c2b48000 00000001 00000000 c385fed3 c2bfb400 c027a4c4 c2b48000 c2b07400
> fec0: 00000000 c0279b8c 00000000 c385fed3 00000000 10ffff00 00000000 c2b0757c
> fee0: c2b07400 00000000 00061a80 c03b9d90 00000000 00000000 00000089 c0272fb8
> ff00: c385df60 c2b0757c c3817200 c10f26b5 c3849c00 c00270e0 c385df60 c2b0757c
> ff20: 00000081 c385df60 c3817200 c385e000 c10f26b5 c385df78 c3817200 c3817210
> ff40: 00000089 c00276d0 c384e800 c384debc 00000000 c385df60 c00274c0 00000000
> ff60: 00000000 00000000 00000000 c002c130 00000000 00000000 00000000 c385df60
> ff80: 00000000 c385ff84 c385ff84 00000000 c385ff90 c385ff90 c385ffac c384debc
> ffa0: c002c090 00000000 00000000 c00094b0 00000000 00000000 00000000 00000000
> ffc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> ffe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 00000000
> [<c0064a50>] (vma_interval_tree_subtree_search+0x18/0x74) from [<c000f00c>] (flush_dcache_page+0x90/0x12c)
> [<c000f00c>] (flush_dcache_page+0x90/0x12c) from [<c0281380>] (atmci_interrupt+0x3cc/0x900)
> [<c0281380>] (atmci_interrupt+0x3cc/0x900) from [<c0049d3c>] (handle_irq_event_percpu+0x2c/0x1a0)
> [<c0049d3c>] (handle_irq_event_percpu+0x2c/0x1a0) from [<c0049ed8>] (handle_irq_event+0x28/0x38)
> [<c0049ed8>] (handle_irq_event+0x28/0x38) from [<c004c384>] (handle_fasteoi_irq+0xa4/0xe4)
> [<c004c384>] (handle_fasteoi_irq+0xa4/0xe4) from [<c0049718>] (generic_handle_irq+0x20/0x30)
> [<c0049718>] (generic_handle_irq+0x20/0x30) from [<c0009cc8>] (handle_IRQ+0x60/0x84)
> [<c0009cc8>] (handle_IRQ+0x60/0x84) from [<c000bf20>] (__irq_svc+0x40/0x4c)
> [<c000bf20>] (__irq_svc+0x40/0x4c) from [<c001d7ec>] (mod_timer+0xf8/0x110)
> [<c001d7ec>] (mod_timer+0xf8/0x110) from [<c028207c>] (atmci_request+0xd0/0x120)
> [<c028207c>] (atmci_request+0xd0/0x120) from [<c0270e28>] (mmc_start_request+0x1e4/0x204)
> [<c0270e28>] (mmc_start_request+0x1e4/0x204) from [<c027100c>] (mmc_wait_for_req+0x6c/0x16c)
> [<c027100c>] (mmc_wait_for_req+0x6c/0x16c) from [<c027a06c>] (mmc_io_rw_extended+0x214/0x290)
> [<c027a06c>] (mmc_io_rw_extended+0x214/0x290) from [<c027af0c>] (sdio_io_rw_ext_helper+0x160/0x1a0)
> [<c027af0c>] (sdio_io_rw_ext_helper+0x160/0x1a0) from [<c027b010>] (sdio_memcpy_fromio+0x14/0x18)
> [<c027b010>] (sdio_memcpy_fromio+0x14/0x18) from [<c022d0e8>] (ath6kl_sdio_io+0x88/0x9c)
> [<c022d0e8>] (ath6kl_sdio_io+0x88/0x9c) from [<c022d6ac>] (ath6kl_sdio_read_write_sync+0xb0/0x100)
> [<c022d6ac>] (ath6kl_sdio_read_write_sync+0xb0/0x100) from [<c022da4c>] (ath6kl_sdio_bmi_write+0x54/0xf8)
> [<c022da4c>] (ath6kl_sdio_bmi_write+0x54/0xf8) from [<c021bb1c>] (ath6kl_bmi_get_target_info+0x44/0x190)
> [<c021bb1c>] (ath6kl_bmi_get_target_info+0x44/0x190) from [<c022c37c>] (ath6kl_core_init+0xa4/0x404)
> [<c022c37c>] (ath6kl_core_init+0xa4/0x404) from [<c022e010>] (ath6kl_sdio_probe+0x184/0x1ec)
> [<c022e010>] (ath6kl_sdio_probe+0x184/0x1ec) from [<c027a32c>] (sdio_bus_probe+0x58/0x6c)
> [<c027a32c>] (sdio_bus_probe+0x58/0x6c) from [<c01cadf4>] (driver_probe_device+0xac/0x1f4)
> [<c01cadf4>] (driver_probe_device+0xac/0x1f4) from [<c01c966c>] (bus_for_each_drv+0x48/0x8c)
> [<c01c966c>] (bus_for_each_drv+0x48/0x8c) from [<c01cad10>] (device_attach+0x68/0x80)
> [<c01cad10>] (device_attach+0x68/0x80) from [<c01ca398>] (bus_probe_device+0x28/0x98)
> [<c01ca398>] (bus_probe_device+0x28/0x98) from [<c01c898c>] (device_add+0x424/0x5fc)
> [<c01c898c>] (device_add+0x424/0x5fc) from [<c027a4c4>] (sdio_add_func+0x34/0x4c)
> [<c027a4c4>] (sdio_add_func+0x34/0x4c) from [<c0279b8c>] (mmc_attach_sdio+0x260/0x314)
> [<c0279b8c>] (mmc_attach_sdio+0x260/0x314) from [<c0272fb8>] (mmc_rescan+0x22c/0x2b4)
> [<c0272fb8>] (mmc_rescan+0x22c/0x2b4) from [<c00270e0>] (process_one_work+0x1f4/0x348)
> [<c00270e0>] (process_one_work+0x1f4/0x348) from [<c00276d0>] (worker_thread+0x210/0x36c)
> [<c00276d0>] (worker_thread+0x210/0x36c) from [<c002c130>] (kthread+0xa0/0xb0)
> [<c002c130>] (kthread+0xa0/0xb0) from [<c00094b0>] (ret_from_fork+0x14/0x24)
> Code: e243002c e5903034 e3530000 0a000002 (e593c00c)
> ---[ end trace 3f7f9bc3f451e9c9 ]---
> Kernel panic - not syncing: Fatal exception in interrupt
>
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: possible regression on 3.13 when calling flush_dcache_page
2013-12-12 14:31 ` Ludovic Desroches
(?)
@ 2013-12-12 17:13 ` Russell King - ARM Linux
-1 siblings, 0 replies; 45+ messages in thread
From: Russell King - ARM Linux @ 2013-12-12 17:13 UTC (permalink / raw)
To: Ludovic Desroches
Cc: linux-mm, linux-kernel, linux-mmc, linux-arm-kernel, iamjoonsoo.kim
On Thu, Dec 12, 2013 at 03:31:50PM +0100, Ludovic Desroches wrote:
> I'll investigate on atmel-mci driver side but if someone has also this
> issue or see what is wrong in the driver, please tell me all about it.
I'm not entirely sure what's causing this, but calling flush_dcache_page()
from an IRQ isn't the best idea, as one of its side effects will be to
unmask IRQs at the CPU.
BTW, the faulting function seems to have been removed in more recent
kernels.
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: possible regression on 3.13 when calling flush_dcache_page
@ 2013-12-12 17:13 ` Russell King - ARM Linux
0 siblings, 0 replies; 45+ messages in thread
From: Russell King - ARM Linux @ 2013-12-12 17:13 UTC (permalink / raw)
To: Ludovic Desroches
Cc: linux-mm, linux-kernel, linux-mmc, linux-arm-kernel, iamjoonsoo.kim
On Thu, Dec 12, 2013 at 03:31:50PM +0100, Ludovic Desroches wrote:
> I'll investigate on atmel-mci driver side but if someone has also this
> issue or see what is wrong in the driver, please tell me all about it.
I'm not entirely sure what's causing this, but calling flush_dcache_page()
from an IRQ isn't the best idea, as one of its side effects will be to
unmask IRQs at the CPU.
BTW, the faulting function seems to have been removed in more recent
kernels.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 45+ messages in thread
* possible regression on 3.13 when calling flush_dcache_page
@ 2013-12-12 17:13 ` Russell King - ARM Linux
0 siblings, 0 replies; 45+ messages in thread
From: Russell King - ARM Linux @ 2013-12-12 17:13 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Dec 12, 2013 at 03:31:50PM +0100, Ludovic Desroches wrote:
> I'll investigate on atmel-mci driver side but if someone has also this
> issue or see what is wrong in the driver, please tell me all about it.
I'm not entirely sure what's causing this, but calling flush_dcache_page()
from an IRQ isn't the best idea, as one of its side effects will be to
unmask IRQs at the CPU.
BTW, the faulting function seems to have been removed in more recent
kernels.
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: possible regression on 3.13 when calling flush_dcache_page
2013-12-12 14:36 ` Ludovic Desroches
(?)
@ 2013-12-13 1:59 ` Joonsoo Kim
-1 siblings, 0 replies; 45+ messages in thread
From: Joonsoo Kim @ 2013-12-13 1:59 UTC (permalink / raw)
To: linux-mm, linux-kernel, linux-mmc, linux-arm-kernel
On Thu, Dec 12, 2013 at 03:36:19PM +0100, Ludovic Desroches wrote:
> fix mmc mailing list address error
>
> On Thu, Dec 12, 2013 at 03:31:50PM +0100, Ludovic Desroches wrote:
> > Hi,
> >
> > With v3.13-rc3 I have an error when the atmel-mci driver calls
> > flush_dcache_page (log at the end of the message).
> >
> > Since I didn't have it before, I did a git bisect and the commit introducing
> > the error is the following one:
> >
> > 106a74e slab: replace free and inuse in struct slab with newly introduced active
> >
> > I don't know if this commit has introduced a bug or if it has revealed a bug
> > in the atmel-mci driver.
Hello,
I think that this commit may not introduce a bug. This patch remove one
variable on slab management structure and replace variable name. So there
is no functional change.
I doubt that side-effect of this patch reveals a bug in other place.
Side-effect is reduced memory usage for slab management structure. It would
makes some slabs have more objects with more density since slab management
structure is sometimes on the page for objects. So if it diminishes, more
objects can be in the page.
Anyway, I will look at it more. If you have any progress, please let me know.
Thanks.
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: possible regression on 3.13 when calling flush_dcache_page
@ 2013-12-13 1:59 ` Joonsoo Kim
0 siblings, 0 replies; 45+ messages in thread
From: Joonsoo Kim @ 2013-12-13 1:59 UTC (permalink / raw)
To: linux-mm, linux-kernel, linux-mmc, linux-arm-kernel
On Thu, Dec 12, 2013 at 03:36:19PM +0100, Ludovic Desroches wrote:
> fix mmc mailing list address error
>
> On Thu, Dec 12, 2013 at 03:31:50PM +0100, Ludovic Desroches wrote:
> > Hi,
> >
> > With v3.13-rc3 I have an error when the atmel-mci driver calls
> > flush_dcache_page (log at the end of the message).
> >
> > Since I didn't have it before, I did a git bisect and the commit introducing
> > the error is the following one:
> >
> > 106a74e slab: replace free and inuse in struct slab with newly introduced active
> >
> > I don't know if this commit has introduced a bug or if it has revealed a bug
> > in the atmel-mci driver.
Hello,
I think that this commit may not introduce a bug. This patch remove one
variable on slab management structure and replace variable name. So there
is no functional change.
I doubt that side-effect of this patch reveals a bug in other place.
Side-effect is reduced memory usage for slab management structure. It would
makes some slabs have more objects with more density since slab management
structure is sometimes on the page for objects. So if it diminishes, more
objects can be in the page.
Anyway, I will look at it more. If you have any progress, please let me know.
Thanks.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 45+ messages in thread
* possible regression on 3.13 when calling flush_dcache_page
@ 2013-12-13 1:59 ` Joonsoo Kim
0 siblings, 0 replies; 45+ messages in thread
From: Joonsoo Kim @ 2013-12-13 1:59 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Dec 12, 2013 at 03:36:19PM +0100, Ludovic Desroches wrote:
> fix mmc mailing list address error
>
> On Thu, Dec 12, 2013 at 03:31:50PM +0100, Ludovic Desroches wrote:
> > Hi,
> >
> > With v3.13-rc3 I have an error when the atmel-mci driver calls
> > flush_dcache_page (log at the end of the message).
> >
> > Since I didn't have it before, I did a git bisect and the commit introducing
> > the error is the following one:
> >
> > 106a74e slab: replace free and inuse in struct slab with newly introduced active
> >
> > I don't know if this commit has introduced a bug or if it has revealed a bug
> > in the atmel-mci driver.
Hello,
I think that this commit may not introduce a bug. This patch remove one
variable on slab management structure and replace variable name. So there
is no functional change.
I doubt that side-effect of this patch reveals a bug in other place.
Side-effect is reduced memory usage for slab management structure. It would
makes some slabs have more objects with more density since slab management
structure is sometimes on the page for objects. So if it diminishes, more
objects can be in the page.
Anyway, I will look at it more. If you have any progress, please let me know.
Thanks.
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: possible regression on 3.13 when calling flush_dcache_page
2013-12-12 17:13 ` Russell King - ARM Linux
(?)
@ 2013-12-16 10:49 ` Ludovic Desroches
-1 siblings, 0 replies; 45+ messages in thread
From: Ludovic Desroches @ 2013-12-16 10:49 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: linux-mm, linux-kernel, linux-mmc, linux-arm-kernel,
iamjoonsoo.kim, Ludovic Desroches
On Thu, Dec 12, 2013 at 05:13:22PM +0000, Russell King - ARM Linux wrote:
> On Thu, Dec 12, 2013 at 03:31:50PM +0100, Ludovic Desroches wrote:
> > I'll investigate on atmel-mci driver side but if someone has also this
> > issue or see what is wrong in the driver, please tell me all about it.
>
> I'm not entirely sure what's causing this, but calling flush_dcache_page()
> from an IRQ isn't the best idea, as one of its side effects will be to
> unmask IRQs at the CPU.
>
Thans for pointing this point. Having a look to other mmc drivers, it
seems flush_dcache_page() is also called from an IRQ. Not sure that
deferring it is the way to go.
What should be the most proper solution?
> BTW, the faulting function seems to have been removed in more recent
> kernels.
Same error with rc4 and linux-next.
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: possible regression on 3.13 when calling flush_dcache_page
@ 2013-12-16 10:49 ` Ludovic Desroches
0 siblings, 0 replies; 45+ messages in thread
From: Ludovic Desroches @ 2013-12-16 10:49 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: linux-mm, linux-kernel, linux-mmc, linux-arm-kernel,
iamjoonsoo.kim, Ludovic Desroches
On Thu, Dec 12, 2013 at 05:13:22PM +0000, Russell King - ARM Linux wrote:
> On Thu, Dec 12, 2013 at 03:31:50PM +0100, Ludovic Desroches wrote:
> > I'll investigate on atmel-mci driver side but if someone has also this
> > issue or see what is wrong in the driver, please tell me all about it.
>
> I'm not entirely sure what's causing this, but calling flush_dcache_page()
> from an IRQ isn't the best idea, as one of its side effects will be to
> unmask IRQs at the CPU.
>
Thans for pointing this point. Having a look to other mmc drivers, it
seems flush_dcache_page() is also called from an IRQ. Not sure that
deferring it is the way to go.
What should be the most proper solution?
> BTW, the faulting function seems to have been removed in more recent
> kernels.
Same error with rc4 and linux-next.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 45+ messages in thread
* possible regression on 3.13 when calling flush_dcache_page
@ 2013-12-16 10:49 ` Ludovic Desroches
0 siblings, 0 replies; 45+ messages in thread
From: Ludovic Desroches @ 2013-12-16 10:49 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Dec 12, 2013 at 05:13:22PM +0000, Russell King - ARM Linux wrote:
> On Thu, Dec 12, 2013 at 03:31:50PM +0100, Ludovic Desroches wrote:
> > I'll investigate on atmel-mci driver side but if someone has also this
> > issue or see what is wrong in the driver, please tell me all about it.
>
> I'm not entirely sure what's causing this, but calling flush_dcache_page()
> from an IRQ isn't the best idea, as one of its side effects will be to
> unmask IRQs at the CPU.
>
Thans for pointing this point. Having a look to other mmc drivers, it
seems flush_dcache_page() is also called from an IRQ. Not sure that
deferring it is the way to go.
What should be the most proper solution?
> BTW, the faulting function seems to have been removed in more recent
> kernels.
Same error with rc4 and linux-next.
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: possible regression on 3.13 when calling flush_dcache_page
2013-12-13 1:59 ` Joonsoo Kim
(?)
@ 2013-12-16 14:43 ` Ludovic Desroches
-1 siblings, 0 replies; 45+ messages in thread
From: Ludovic Desroches @ 2013-12-16 14:43 UTC (permalink / raw)
To: Joonsoo Kim
Cc: linux-mm, linux-kernel, linux-mmc, linux-arm-kernel, Ludovic Desroches
Hello,
On Fri, Dec 13, 2013 at 10:59:09AM +0900, Joonsoo Kim wrote:
> On Thu, Dec 12, 2013 at 03:36:19PM +0100, Ludovic Desroches wrote:
> > fix mmc mailing list address error
> >
> > On Thu, Dec 12, 2013 at 03:31:50PM +0100, Ludovic Desroches wrote:
> > > Hi,
> > >
> > > With v3.13-rc3 I have an error when the atmel-mci driver calls
> > > flush_dcache_page (log at the end of the message).
> > >
> > > Since I didn't have it before, I did a git bisect and the commit introducing
> > > the error is the following one:
> > >
> > > 106a74e slab: replace free and inuse in struct slab with newly introduced active
> > >
> > > I don't know if this commit has introduced a bug or if it has revealed a bug
> > > in the atmel-mci driver.
>
> Hello,
>
> I think that this commit may not introduce a bug. This patch remove one
> variable on slab management structure and replace variable name. So there
> is no functional change.
>
If I have reverted this patch and other ones you did on top of it and
the issue disappear.
> I doubt that side-effect of this patch reveals a bug in other place.
> Side-effect is reduced memory usage for slab management structure. It would
> makes some slabs have more objects with more density since slab management
> structure is sometimes on the page for objects. So if it diminishes, more
> objects can be in the page.
>
> Anyway, I will look at it more. If you have any progress, please let me know.
No progress at the moment.
Regards
Ludovic
>
> Thanks.
>
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majordomo@kvack.org. For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: possible regression on 3.13 when calling flush_dcache_page
@ 2013-12-16 14:43 ` Ludovic Desroches
0 siblings, 0 replies; 45+ messages in thread
From: Ludovic Desroches @ 2013-12-16 14:43 UTC (permalink / raw)
To: Joonsoo Kim
Cc: linux-mm, linux-kernel, linux-mmc, linux-arm-kernel, Ludovic Desroches
Hello,
On Fri, Dec 13, 2013 at 10:59:09AM +0900, Joonsoo Kim wrote:
> On Thu, Dec 12, 2013 at 03:36:19PM +0100, Ludovic Desroches wrote:
> > fix mmc mailing list address error
> >
> > On Thu, Dec 12, 2013 at 03:31:50PM +0100, Ludovic Desroches wrote:
> > > Hi,
> > >
> > > With v3.13-rc3 I have an error when the atmel-mci driver calls
> > > flush_dcache_page (log at the end of the message).
> > >
> > > Since I didn't have it before, I did a git bisect and the commit introducing
> > > the error is the following one:
> > >
> > > 106a74e slab: replace free and inuse in struct slab with newly introduced active
> > >
> > > I don't know if this commit has introduced a bug or if it has revealed a bug
> > > in the atmel-mci driver.
>
> Hello,
>
> I think that this commit may not introduce a bug. This patch remove one
> variable on slab management structure and replace variable name. So there
> is no functional change.
>
If I have reverted this patch and other ones you did on top of it and
the issue disappear.
> I doubt that side-effect of this patch reveals a bug in other place.
> Side-effect is reduced memory usage for slab management structure. It would
> makes some slabs have more objects with more density since slab management
> structure is sometimes on the page for objects. So if it diminishes, more
> objects can be in the page.
>
> Anyway, I will look at it more. If you have any progress, please let me know.
No progress at the moment.
Regards
Ludovic
>
> Thanks.
>
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majordomo@kvack.org. For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 45+ messages in thread
* possible regression on 3.13 when calling flush_dcache_page
@ 2013-12-16 14:43 ` Ludovic Desroches
0 siblings, 0 replies; 45+ messages in thread
From: Ludovic Desroches @ 2013-12-16 14:43 UTC (permalink / raw)
To: linux-arm-kernel
Hello,
On Fri, Dec 13, 2013 at 10:59:09AM +0900, Joonsoo Kim wrote:
> On Thu, Dec 12, 2013 at 03:36:19PM +0100, Ludovic Desroches wrote:
> > fix mmc mailing list address error
> >
> > On Thu, Dec 12, 2013 at 03:31:50PM +0100, Ludovic Desroches wrote:
> > > Hi,
> > >
> > > With v3.13-rc3 I have an error when the atmel-mci driver calls
> > > flush_dcache_page (log at the end of the message).
> > >
> > > Since I didn't have it before, I did a git bisect and the commit introducing
> > > the error is the following one:
> > >
> > > 106a74e slab: replace free and inuse in struct slab with newly introduced active
> > >
> > > I don't know if this commit has introduced a bug or if it has revealed a bug
> > > in the atmel-mci driver.
>
> Hello,
>
> I think that this commit may not introduce a bug. This patch remove one
> variable on slab management structure and replace variable name. So there
> is no functional change.
>
If I have reverted this patch and other ones you did on top of it and
the issue disappear.
> I doubt that side-effect of this patch reveals a bug in other place.
> Side-effect is reduced memory usage for slab management structure. It would
> makes some slabs have more objects with more density since slab management
> structure is sometimes on the page for objects. So if it diminishes, more
> objects can be in the page.
>
> Anyway, I will look at it more. If you have any progress, please let me know.
No progress at the moment.
Regards
Ludovic
>
> Thanks.
>
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majordomo at kvack.org. For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: <a href=mailto:"dont@kvack.org"> email at kvack.org </a>
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: possible regression on 3.13 when calling flush_dcache_page
2013-12-16 14:43 ` Ludovic Desroches
(?)
@ 2013-12-18 7:21 ` Joonsoo Kim
-1 siblings, 0 replies; 45+ messages in thread
From: Joonsoo Kim @ 2013-12-18 7:21 UTC (permalink / raw)
To: linux-mm, linux-kernel, linux-mmc, linux-arm-kernel
On Mon, Dec 16, 2013 at 03:43:43PM +0100, Ludovic Desroches wrote:
> Hello,
>
> On Fri, Dec 13, 2013 at 10:59:09AM +0900, Joonsoo Kim wrote:
> > On Thu, Dec 12, 2013 at 03:36:19PM +0100, Ludovic Desroches wrote:
> > > fix mmc mailing list address error
> > >
> > > On Thu, Dec 12, 2013 at 03:31:50PM +0100, Ludovic Desroches wrote:
> > > > Hi,
> > > >
> > > > With v3.13-rc3 I have an error when the atmel-mci driver calls
> > > > flush_dcache_page (log at the end of the message).
> > > >
> > > > Since I didn't have it before, I did a git bisect and the commit introducing
> > > > the error is the following one:
> > > >
> > > > 106a74e slab: replace free and inuse in struct slab with newly introduced active
> > > >
> > > > I don't know if this commit has introduced a bug or if it has revealed a bug
> > > > in the atmel-mci driver.
> >
> > Hello,
> >
> > I think that this commit may not introduce a bug. This patch remove one
> > variable on slab management structure and replace variable name. So there
> > is no functional change.
> >
>
> If I have reverted this patch and other ones you did on top of it and
> the issue disappear.
Hello,
Could you give me your '/proc/slabinfo' before/after this commit (106a74e)?
And how about testing with artificially increasing size of struct slab on
top of this commit (106a74e)?
I really wonder why the problem happens, because this doesn't cause any
functional change as far as I know. Only side-effect from this patch is
decreasing size of struct slab.
Thanks.
diff --git a/mm/slab.c b/mm/slab.c
index 2ec2336..d2240fd 100644
--- a/mm/slab.c
+++ b/mm/slab.c
@@ -174,6 +174,7 @@ struct slab {
struct {
struct list_head list;
void *s_mem; /* including colour offset */
+ unsigned int x;
unsigned int active; /* num of objs active in slab */
};
};
>
> > I doubt that side-effect of this patch reveals a bug in other place.
> > Side-effect is reduced memory usage for slab management structure. It would
> > makes some slabs have more objects with more density since slab management
> > structure is sometimes on the page for objects. So if it diminishes, more
> > objects can be in the page.
> >
> > Anyway, I will look at it more. If you have any progress, please let me know.
>
> No progress at the moment.
^ permalink raw reply related [flat|nested] 45+ messages in thread
* Re: possible regression on 3.13 when calling flush_dcache_page
@ 2013-12-18 7:21 ` Joonsoo Kim
0 siblings, 0 replies; 45+ messages in thread
From: Joonsoo Kim @ 2013-12-18 7:21 UTC (permalink / raw)
To: linux-mm, linux-kernel, linux-mmc, linux-arm-kernel
On Mon, Dec 16, 2013 at 03:43:43PM +0100, Ludovic Desroches wrote:
> Hello,
>
> On Fri, Dec 13, 2013 at 10:59:09AM +0900, Joonsoo Kim wrote:
> > On Thu, Dec 12, 2013 at 03:36:19PM +0100, Ludovic Desroches wrote:
> > > fix mmc mailing list address error
> > >
> > > On Thu, Dec 12, 2013 at 03:31:50PM +0100, Ludovic Desroches wrote:
> > > > Hi,
> > > >
> > > > With v3.13-rc3 I have an error when the atmel-mci driver calls
> > > > flush_dcache_page (log at the end of the message).
> > > >
> > > > Since I didn't have it before, I did a git bisect and the commit introducing
> > > > the error is the following one:
> > > >
> > > > 106a74e slab: replace free and inuse in struct slab with newly introduced active
> > > >
> > > > I don't know if this commit has introduced a bug or if it has revealed a bug
> > > > in the atmel-mci driver.
> >
> > Hello,
> >
> > I think that this commit may not introduce a bug. This patch remove one
> > variable on slab management structure and replace variable name. So there
> > is no functional change.
> >
>
> If I have reverted this patch and other ones you did on top of it and
> the issue disappear.
Hello,
Could you give me your '/proc/slabinfo' before/after this commit (106a74e)?
And how about testing with artificially increasing size of struct slab on
top of this commit (106a74e)?
I really wonder why the problem happens, because this doesn't cause any
functional change as far as I know. Only side-effect from this patch is
decreasing size of struct slab.
Thanks.
diff --git a/mm/slab.c b/mm/slab.c
index 2ec2336..d2240fd 100644
--- a/mm/slab.c
+++ b/mm/slab.c
@@ -174,6 +174,7 @@ struct slab {
struct {
struct list_head list;
void *s_mem; /* including colour offset */
+ unsigned int x;
unsigned int active; /* num of objs active in slab */
};
};
>
> > I doubt that side-effect of this patch reveals a bug in other place.
> > Side-effect is reduced memory usage for slab management structure. It would
> > makes some slabs have more objects with more density since slab management
> > structure is sometimes on the page for objects. So if it diminishes, more
> > objects can be in the page.
> >
> > Anyway, I will look at it more. If you have any progress, please let me know.
>
> No progress at the moment.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply related [flat|nested] 45+ messages in thread
* possible regression on 3.13 when calling flush_dcache_page
@ 2013-12-18 7:21 ` Joonsoo Kim
0 siblings, 0 replies; 45+ messages in thread
From: Joonsoo Kim @ 2013-12-18 7:21 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, Dec 16, 2013 at 03:43:43PM +0100, Ludovic Desroches wrote:
> Hello,
>
> On Fri, Dec 13, 2013 at 10:59:09AM +0900, Joonsoo Kim wrote:
> > On Thu, Dec 12, 2013 at 03:36:19PM +0100, Ludovic Desroches wrote:
> > > fix mmc mailing list address error
> > >
> > > On Thu, Dec 12, 2013 at 03:31:50PM +0100, Ludovic Desroches wrote:
> > > > Hi,
> > > >
> > > > With v3.13-rc3 I have an error when the atmel-mci driver calls
> > > > flush_dcache_page (log at the end of the message).
> > > >
> > > > Since I didn't have it before, I did a git bisect and the commit introducing
> > > > the error is the following one:
> > > >
> > > > 106a74e slab: replace free and inuse in struct slab with newly introduced active
> > > >
> > > > I don't know if this commit has introduced a bug or if it has revealed a bug
> > > > in the atmel-mci driver.
> >
> > Hello,
> >
> > I think that this commit may not introduce a bug. This patch remove one
> > variable on slab management structure and replace variable name. So there
> > is no functional change.
> >
>
> If I have reverted this patch and other ones you did on top of it and
> the issue disappear.
Hello,
Could you give me your '/proc/slabinfo' before/after this commit (106a74e)?
And how about testing with artificially increasing size of struct slab on
top of this commit (106a74e)?
I really wonder why the problem happens, because this doesn't cause any
functional change as far as I know. Only side-effect from this patch is
decreasing size of struct slab.
Thanks.
diff --git a/mm/slab.c b/mm/slab.c
index 2ec2336..d2240fd 100644
--- a/mm/slab.c
+++ b/mm/slab.c
@@ -174,6 +174,7 @@ struct slab {
struct {
struct list_head list;
void *s_mem; /* including colour offset */
+ unsigned int x;
unsigned int active; /* num of objs active in slab */
};
};
>
> > I doubt that side-effect of this patch reveals a bug in other place.
> > Side-effect is reduced memory usage for slab management structure. It would
> > makes some slabs have more objects with more density since slab management
> > structure is sometimes on the page for objects. So if it diminishes, more
> > objects can be in the page.
> >
> > Anyway, I will look at it more. If you have any progress, please let me know.
>
> No progress at the moment.
^ permalink raw reply related [flat|nested] 45+ messages in thread
* Re: possible regression on 3.13 when calling flush_dcache_page
2013-12-18 7:21 ` Joonsoo Kim
(?)
(?)
@ 2013-12-20 8:08 ` Ludovic Desroches
-1 siblings, 0 replies; 45+ messages in thread
From: Ludovic Desroches @ 2013-12-20 8:08 UTC (permalink / raw)
To: Joonsoo Kim
Cc: linux-mm, linux-kernel, linux-mmc, linux-arm-kernel, Ludovic Desroches
Hello,
On Wed, Dec 18, 2013 at 04:21:17PM +0900, Joonsoo Kim wrote:
> On Mon, Dec 16, 2013 at 03:43:43PM +0100, Ludovic Desroches wrote:
> > Hello,
> >
> > On Fri, Dec 13, 2013 at 10:59:09AM +0900, Joonsoo Kim wrote:
> > > On Thu, Dec 12, 2013 at 03:36:19PM +0100, Ludovic Desroches wrote:
> > > > fix mmc mailing list address error
> > > >
> > > > On Thu, Dec 12, 2013 at 03:31:50PM +0100, Ludovic Desroches wrote:
> > > > > Hi,
> > > > >
> > > > > With v3.13-rc3 I have an error when the atmel-mci driver calls
> > > > > flush_dcache_page (log at the end of the message).
> > > > >
> > > > > Since I didn't have it before, I did a git bisect and the commit introducing
> > > > > the error is the following one:
> > > > >
> > > > > 106a74e slab: replace free and inuse in struct slab with newly introduced active
> > > > >
> > > > > I don't know if this commit has introduced a bug or if it has revealed a bug
> > > > > in the atmel-mci driver.
> > >
> > > Hello,
> > >
> > > I think that this commit may not introduce a bug. This patch remove one
> > > variable on slab management structure and replace variable name. So there
> > > is no functional change.
> > >
> >
> > If I have reverted this patch and other ones you did on top of it and
> > the issue disappear.
>
> Hello,
>
> Could you give me your '/proc/slabinfo' before/after this commit (106a74e)?
>
> And how about testing with artificially increasing size of struct slab on
> top of this commit (106a74e)?
>
> I really wonder why the problem happens, because this doesn't cause any
> functional change as far as I know. Only side-effect from this patch is
> decreasing size of struct slab.
Sorry I am not at the office, I have tried to reproduce it with a
different device and a different sdcard but without success. I'll test
it on Monday.
Regards
Ludovic
>
> Thanks.
>
> diff --git a/mm/slab.c b/mm/slab.c
> index 2ec2336..d2240fd 100644
> --- a/mm/slab.c
> +++ b/mm/slab.c
> @@ -174,6 +174,7 @@ struct slab {
> struct {
> struct list_head list;
> void *s_mem; /* including colour offset */
> + unsigned int x;
> unsigned int active; /* num of objs active in slab */
> };
> };
>
> >
> > > I doubt that side-effect of this patch reveals a bug in other place.
> > > Side-effect is reduced memory usage for slab management structure. It would
> > > makes some slabs have more objects with more density since slab management
> > > structure is sometimes on the page for objects. So if it diminishes, more
> > > objects can be in the page.
> > >
> > > Anyway, I will look at it more. If you have any progress, please let me know.
> >
> > No progress at the moment.
>
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majordomo@kvack.org. For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: possible regression on 3.13 when calling flush_dcache_page
@ 2013-12-20 8:08 ` Ludovic Desroches
0 siblings, 0 replies; 45+ messages in thread
From: Ludovic Desroches @ 2013-12-20 8:08 UTC (permalink / raw)
To: Joonsoo Kim
Cc: linux-mm, linux-kernel, linux-mmc, linux-arm-kernel, Ludovic Desroches
Hello,
On Wed, Dec 18, 2013 at 04:21:17PM +0900, Joonsoo Kim wrote:
> On Mon, Dec 16, 2013 at 03:43:43PM +0100, Ludovic Desroches wrote:
> > Hello,
> >
> > On Fri, Dec 13, 2013 at 10:59:09AM +0900, Joonsoo Kim wrote:
> > > On Thu, Dec 12, 2013 at 03:36:19PM +0100, Ludovic Desroches wrote:
> > > > fix mmc mailing list address error
> > > >
> > > > On Thu, Dec 12, 2013 at 03:31:50PM +0100, Ludovic Desroches wrote:
> > > > > Hi,
> > > > >
> > > > > With v3.13-rc3 I have an error when the atmel-mci driver calls
> > > > > flush_dcache_page (log at the end of the message).
> > > > >
> > > > > Since I didn't have it before, I did a git bisect and the commit introducing
> > > > > the error is the following one:
> > > > >
> > > > > 106a74e slab: replace free and inuse in struct slab with newly introduced active
> > > > >
> > > > > I don't know if this commit has introduced a bug or if it has revealed a bug
> > > > > in the atmel-mci driver.
> > >
> > > Hello,
> > >
> > > I think that this commit may not introduce a bug. This patch remove one
> > > variable on slab management structure and replace variable name. So there
> > > is no functional change.
> > >
> >
> > If I have reverted this patch and other ones you did on top of it and
> > the issue disappear.
>
> Hello,
>
> Could you give me your '/proc/slabinfo' before/after this commit (106a74e)?
>
> And how about testing with artificially increasing size of struct slab on
> top of this commit (106a74e)?
>
> I really wonder why the problem happens, because this doesn't cause any
> functional change as far as I know. Only side-effect from this patch is
> decreasing size of struct slab.
Sorry I am not at the office, I have tried to reproduce it with a
different device and a different sdcard but without success. I'll test
it on Monday.
Regards
Ludovic
>
> Thanks.
>
> diff --git a/mm/slab.c b/mm/slab.c
> index 2ec2336..d2240fd 100644
> --- a/mm/slab.c
> +++ b/mm/slab.c
> @@ -174,6 +174,7 @@ struct slab {
> struct {
> struct list_head list;
> void *s_mem; /* including colour offset */
> + unsigned int x;
> unsigned int active; /* num of objs active in slab */
> };
> };
>
> >
> > > I doubt that side-effect of this patch reveals a bug in other place.
> > > Side-effect is reduced memory usage for slab management structure. It would
> > > makes some slabs have more objects with more density since slab management
> > > structure is sometimes on the page for objects. So if it diminishes, more
> > > objects can be in the page.
> > >
> > > Anyway, I will look at it more. If you have any progress, please let me know.
> >
> > No progress at the moment.
>
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majordomo@kvack.org. For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: possible regression on 3.13 when calling flush_dcache_page
@ 2013-12-20 8:08 ` Ludovic Desroches
0 siblings, 0 replies; 45+ messages in thread
From: Ludovic Desroches @ 2013-12-20 8:08 UTC (permalink / raw)
To: Joonsoo Kim
Cc: linux-mm, linux-kernel, linux-mmc, linux-arm-kernel, Ludovic Desroches
Hello,
On Wed, Dec 18, 2013 at 04:21:17PM +0900, Joonsoo Kim wrote:
> On Mon, Dec 16, 2013 at 03:43:43PM +0100, Ludovic Desroches wrote:
> > Hello,
> >
> > On Fri, Dec 13, 2013 at 10:59:09AM +0900, Joonsoo Kim wrote:
> > > On Thu, Dec 12, 2013 at 03:36:19PM +0100, Ludovic Desroches wrote:
> > > > fix mmc mailing list address error
> > > >
> > > > On Thu, Dec 12, 2013 at 03:31:50PM +0100, Ludovic Desroches wrote:
> > > > > Hi,
> > > > >
> > > > > With v3.13-rc3 I have an error when the atmel-mci driver calls
> > > > > flush_dcache_page (log at the end of the message).
> > > > >
> > > > > Since I didn't have it before, I did a git bisect and the commit introducing
> > > > > the error is the following one:
> > > > >
> > > > > 106a74e slab: replace free and inuse in struct slab with newly introduced active
> > > > >
> > > > > I don't know if this commit has introduced a bug or if it has revealed a bug
> > > > > in the atmel-mci driver.
> > >
> > > Hello,
> > >
> > > I think that this commit may not introduce a bug. This patch remove one
> > > variable on slab management structure and replace variable name. So there
> > > is no functional change.
> > >
> >
> > If I have reverted this patch and other ones you did on top of it and
> > the issue disappear.
>
> Hello,
>
> Could you give me your '/proc/slabinfo' before/after this commit (106a74e)?
>
> And how about testing with artificially increasing size of struct slab on
> top of this commit (106a74e)?
>
> I really wonder why the problem happens, because this doesn't cause any
> functional change as far as I know. Only side-effect from this patch is
> decreasing size of struct slab.
Sorry I am not at the office, I have tried to reproduce it with a
different device and a different sdcard but without success. I'll test
it on Monday.
Regards
Ludovic
>
> Thanks.
>
> diff --git a/mm/slab.c b/mm/slab.c
> index 2ec2336..d2240fd 100644
> --- a/mm/slab.c
> +++ b/mm/slab.c
> @@ -174,6 +174,7 @@ struct slab {
> struct {
> struct list_head list;
> void *s_mem; /* including colour offset */
> + unsigned int x;
> unsigned int active; /* num of objs active in slab */
> };
> };
>
> >
> > > I doubt that side-effect of this patch reveals a bug in other place.
> > > Side-effect is reduced memory usage for slab management structure. It would
> > > makes some slabs have more objects with more density since slab management
> > > structure is sometimes on the page for objects. So if it diminishes, more
> > > objects can be in the page.
> > >
> > > Anyway, I will look at it more. If you have any progress, please let me know.
> >
> > No progress at the moment.
>
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majordomo@kvack.org. For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 45+ messages in thread
* possible regression on 3.13 when calling flush_dcache_page
@ 2013-12-20 8:08 ` Ludovic Desroches
0 siblings, 0 replies; 45+ messages in thread
From: Ludovic Desroches @ 2013-12-20 8:08 UTC (permalink / raw)
To: linux-arm-kernel
Hello,
On Wed, Dec 18, 2013 at 04:21:17PM +0900, Joonsoo Kim wrote:
> On Mon, Dec 16, 2013 at 03:43:43PM +0100, Ludovic Desroches wrote:
> > Hello,
> >
> > On Fri, Dec 13, 2013 at 10:59:09AM +0900, Joonsoo Kim wrote:
> > > On Thu, Dec 12, 2013 at 03:36:19PM +0100, Ludovic Desroches wrote:
> > > > fix mmc mailing list address error
> > > >
> > > > On Thu, Dec 12, 2013 at 03:31:50PM +0100, Ludovic Desroches wrote:
> > > > > Hi,
> > > > >
> > > > > With v3.13-rc3 I have an error when the atmel-mci driver calls
> > > > > flush_dcache_page (log at the end of the message).
> > > > >
> > > > > Since I didn't have it before, I did a git bisect and the commit introducing
> > > > > the error is the following one:
> > > > >
> > > > > 106a74e slab: replace free and inuse in struct slab with newly introduced active
> > > > >
> > > > > I don't know if this commit has introduced a bug or if it has revealed a bug
> > > > > in the atmel-mci driver.
> > >
> > > Hello,
> > >
> > > I think that this commit may not introduce a bug. This patch remove one
> > > variable on slab management structure and replace variable name. So there
> > > is no functional change.
> > >
> >
> > If I have reverted this patch and other ones you did on top of it and
> > the issue disappear.
>
> Hello,
>
> Could you give me your '/proc/slabinfo' before/after this commit (106a74e)?
>
> And how about testing with artificially increasing size of struct slab on
> top of this commit (106a74e)?
>
> I really wonder why the problem happens, because this doesn't cause any
> functional change as far as I know. Only side-effect from this patch is
> decreasing size of struct slab.
Sorry I am not at the office, I have tried to reproduce it with a
different device and a different sdcard but without success. I'll test
it on Monday.
Regards
Ludovic
>
> Thanks.
>
> diff --git a/mm/slab.c b/mm/slab.c
> index 2ec2336..d2240fd 100644
> --- a/mm/slab.c
> +++ b/mm/slab.c
> @@ -174,6 +174,7 @@ struct slab {
> struct {
> struct list_head list;
> void *s_mem; /* including colour offset */
> + unsigned int x;
> unsigned int active; /* num of objs active in slab */
> };
> };
>
> >
> > > I doubt that side-effect of this patch reveals a bug in other place.
> > > Side-effect is reduced memory usage for slab management structure. It would
> > > makes some slabs have more objects with more density since slab management
> > > structure is sometimes on the page for objects. So if it diminishes, more
> > > objects can be in the page.
> > >
> > > Anyway, I will look at it more. If you have any progress, please let me know.
> >
> > No progress at the moment.
>
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majordomo at kvack.org. For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: <a href=mailto:"dont@kvack.org"> email at kvack.org </a>
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: possible regression on 3.13 when calling flush_dcache_page
2013-12-20 8:08 ` Ludovic Desroches
(?)
@ 2013-12-23 22:44 ` Ludovic Desroches
-1 siblings, 0 replies; 45+ messages in thread
From: Ludovic Desroches @ 2013-12-23 22:44 UTC (permalink / raw)
To: Joonsoo Kim, linux-mm, linux-kernel, linux-mmc, linux-arm-kernel
Cc: Ludovic Desroches
On Fri, Dec 20, 2013 at 09:08:51AM +0100, Ludovic Desroches wrote:
> Hello,
>
> On Wed, Dec 18, 2013 at 04:21:17PM +0900, Joonsoo Kim wrote:
> > On Mon, Dec 16, 2013 at 03:43:43PM +0100, Ludovic Desroches wrote:
> > > Hello,
> > >
> > > On Fri, Dec 13, 2013 at 10:59:09AM +0900, Joonsoo Kim wrote:
> > > > On Thu, Dec 12, 2013 at 03:36:19PM +0100, Ludovic Desroches wrote:
> > > > > fix mmc mailing list address error
> > > > >
> > > > > On Thu, Dec 12, 2013 at 03:31:50PM +0100, Ludovic Desroches wrote:
> > > > > > Hi,
> > > > > >
> > > > > > With v3.13-rc3 I have an error when the atmel-mci driver calls
> > > > > > flush_dcache_page (log at the end of the message).
> > > > > >
> > > > > > Since I didn't have it before, I did a git bisect and the commit introducing
> > > > > > the error is the following one:
> > > > > >
> > > > > > 106a74e slab: replace free and inuse in struct slab with newly introduced active
> > > > > >
> > > > > > I don't know if this commit has introduced a bug or if it has revealed a bug
> > > > > > in the atmel-mci driver.
> > > >
> > > > Hello,
> > > >
> > > > I think that this commit may not introduce a bug. This patch remove one
> > > > variable on slab management structure and replace variable name. So there
> > > > is no functional change.
> > > >
> > >
> > > If I have reverted this patch and other ones you did on top of it and
> > > the issue disappear.
> >
> > Hello,
> >
> > Could you give me your '/proc/slabinfo' before/after this commit (106a74e)?
> >
> > And how about testing with artificially increasing size of struct slab on
> > top of this commit (106a74e)?
> >
> > I really wonder why the problem happens, because this doesn't cause any
> > functional change as far as I know. Only side-effect from this patch is
> > decreasing size of struct slab.
>
> Sorry I am not at the office, I have tried to reproduce it with a
> different device and a different sdcard but without success. I'll test
> it on Monday.
I am still not at the office but I get the same device and the same
sdcard and I don't reproduce it. I am not totally in the same
conditions. It seems there is an extra parameter causing this bug but I
don't figure out which one at the moment.
>
> Regards
>
> Ludovic
>
> >
> > Thanks.
> >
> > diff --git a/mm/slab.c b/mm/slab.c
> > index 2ec2336..d2240fd 100644
> > --- a/mm/slab.c
> > +++ b/mm/slab.c
> > @@ -174,6 +174,7 @@ struct slab {
> > struct {
> > struct list_head list;
> > void *s_mem; /* including colour offset */
> > + unsigned int x;
> > unsigned int active; /* num of objs active in slab */
> > };
> > };
> >
> > >
> > > > I doubt that side-effect of this patch reveals a bug in other place.
> > > > Side-effect is reduced memory usage for slab management structure. It would
> > > > makes some slabs have more objects with more density since slab management
> > > > structure is sometimes on the page for objects. So if it diminishes, more
> > > > objects can be in the page.
> > > >
> > > > Anyway, I will look at it more. If you have any progress, please let me know.
> > >
> > > No progress at the moment.
> >
> > --
> > To unsubscribe, send a message with 'unsubscribe linux-mm' in
> > the body to majordomo@kvack.org. For more info on Linux MM,
> > see: http://www.linux-mm.org/ .
> > Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: possible regression on 3.13 when calling flush_dcache_page
@ 2013-12-23 22:44 ` Ludovic Desroches
0 siblings, 0 replies; 45+ messages in thread
From: Ludovic Desroches @ 2013-12-23 22:44 UTC (permalink / raw)
To: Joonsoo Kim, linux-mm, linux-kernel, linux-mmc, linux-arm-kernel
Cc: Ludovic Desroches
On Fri, Dec 20, 2013 at 09:08:51AM +0100, Ludovic Desroches wrote:
> Hello,
>
> On Wed, Dec 18, 2013 at 04:21:17PM +0900, Joonsoo Kim wrote:
> > On Mon, Dec 16, 2013 at 03:43:43PM +0100, Ludovic Desroches wrote:
> > > Hello,
> > >
> > > On Fri, Dec 13, 2013 at 10:59:09AM +0900, Joonsoo Kim wrote:
> > > > On Thu, Dec 12, 2013 at 03:36:19PM +0100, Ludovic Desroches wrote:
> > > > > fix mmc mailing list address error
> > > > >
> > > > > On Thu, Dec 12, 2013 at 03:31:50PM +0100, Ludovic Desroches wrote:
> > > > > > Hi,
> > > > > >
> > > > > > With v3.13-rc3 I have an error when the atmel-mci driver calls
> > > > > > flush_dcache_page (log at the end of the message).
> > > > > >
> > > > > > Since I didn't have it before, I did a git bisect and the commit introducing
> > > > > > the error is the following one:
> > > > > >
> > > > > > 106a74e slab: replace free and inuse in struct slab with newly introduced active
> > > > > >
> > > > > > I don't know if this commit has introduced a bug or if it has revealed a bug
> > > > > > in the atmel-mci driver.
> > > >
> > > > Hello,
> > > >
> > > > I think that this commit may not introduce a bug. This patch remove one
> > > > variable on slab management structure and replace variable name. So there
> > > > is no functional change.
> > > >
> > >
> > > If I have reverted this patch and other ones you did on top of it and
> > > the issue disappear.
> >
> > Hello,
> >
> > Could you give me your '/proc/slabinfo' before/after this commit (106a74e)?
> >
> > And how about testing with artificially increasing size of struct slab on
> > top of this commit (106a74e)?
> >
> > I really wonder why the problem happens, because this doesn't cause any
> > functional change as far as I know. Only side-effect from this patch is
> > decreasing size of struct slab.
>
> Sorry I am not at the office, I have tried to reproduce it with a
> different device and a different sdcard but without success. I'll test
> it on Monday.
I am still not at the office but I get the same device and the same
sdcard and I don't reproduce it. I am not totally in the same
conditions. It seems there is an extra parameter causing this bug but I
don't figure out which one at the moment.
>
> Regards
>
> Ludovic
>
> >
> > Thanks.
> >
> > diff --git a/mm/slab.c b/mm/slab.c
> > index 2ec2336..d2240fd 100644
> > --- a/mm/slab.c
> > +++ b/mm/slab.c
> > @@ -174,6 +174,7 @@ struct slab {
> > struct {
> > struct list_head list;
> > void *s_mem; /* including colour offset */
> > + unsigned int x;
> > unsigned int active; /* num of objs active in slab */
> > };
> > };
> >
> > >
> > > > I doubt that side-effect of this patch reveals a bug in other place.
> > > > Side-effect is reduced memory usage for slab management structure. It would
> > > > makes some slabs have more objects with more density since slab management
> > > > structure is sometimes on the page for objects. So if it diminishes, more
> > > > objects can be in the page.
> > > >
> > > > Anyway, I will look at it more. If you have any progress, please let me know.
> > >
> > > No progress at the moment.
> >
> > --
> > To unsubscribe, send a message with 'unsubscribe linux-mm' in
> > the body to majordomo@kvack.org. For more info on Linux MM,
> > see: http://www.linux-mm.org/ .
> > Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 45+ messages in thread
* possible regression on 3.13 when calling flush_dcache_page
@ 2013-12-23 22:44 ` Ludovic Desroches
0 siblings, 0 replies; 45+ messages in thread
From: Ludovic Desroches @ 2013-12-23 22:44 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, Dec 20, 2013 at 09:08:51AM +0100, Ludovic Desroches wrote:
> Hello,
>
> On Wed, Dec 18, 2013 at 04:21:17PM +0900, Joonsoo Kim wrote:
> > On Mon, Dec 16, 2013 at 03:43:43PM +0100, Ludovic Desroches wrote:
> > > Hello,
> > >
> > > On Fri, Dec 13, 2013 at 10:59:09AM +0900, Joonsoo Kim wrote:
> > > > On Thu, Dec 12, 2013 at 03:36:19PM +0100, Ludovic Desroches wrote:
> > > > > fix mmc mailing list address error
> > > > >
> > > > > On Thu, Dec 12, 2013 at 03:31:50PM +0100, Ludovic Desroches wrote:
> > > > > > Hi,
> > > > > >
> > > > > > With v3.13-rc3 I have an error when the atmel-mci driver calls
> > > > > > flush_dcache_page (log at the end of the message).
> > > > > >
> > > > > > Since I didn't have it before, I did a git bisect and the commit introducing
> > > > > > the error is the following one:
> > > > > >
> > > > > > 106a74e slab: replace free and inuse in struct slab with newly introduced active
> > > > > >
> > > > > > I don't know if this commit has introduced a bug or if it has revealed a bug
> > > > > > in the atmel-mci driver.
> > > >
> > > > Hello,
> > > >
> > > > I think that this commit may not introduce a bug. This patch remove one
> > > > variable on slab management structure and replace variable name. So there
> > > > is no functional change.
> > > >
> > >
> > > If I have reverted this patch and other ones you did on top of it and
> > > the issue disappear.
> >
> > Hello,
> >
> > Could you give me your '/proc/slabinfo' before/after this commit (106a74e)?
> >
> > And how about testing with artificially increasing size of struct slab on
> > top of this commit (106a74e)?
> >
> > I really wonder why the problem happens, because this doesn't cause any
> > functional change as far as I know. Only side-effect from this patch is
> > decreasing size of struct slab.
>
> Sorry I am not at the office, I have tried to reproduce it with a
> different device and a different sdcard but without success. I'll test
> it on Monday.
I am still not at the office but I get the same device and the same
sdcard and I don't reproduce it. I am not totally in the same
conditions. It seems there is an extra parameter causing this bug but I
don't figure out which one at the moment.
>
> Regards
>
> Ludovic
>
> >
> > Thanks.
> >
> > diff --git a/mm/slab.c b/mm/slab.c
> > index 2ec2336..d2240fd 100644
> > --- a/mm/slab.c
> > +++ b/mm/slab.c
> > @@ -174,6 +174,7 @@ struct slab {
> > struct {
> > struct list_head list;
> > void *s_mem; /* including colour offset */
> > + unsigned int x;
> > unsigned int active; /* num of objs active in slab */
> > };
> > };
> >
> > >
> > > > I doubt that side-effect of this patch reveals a bug in other place.
> > > > Side-effect is reduced memory usage for slab management structure. It would
> > > > makes some slabs have more objects with more density since slab management
> > > > structure is sometimes on the page for objects. So if it diminishes, more
> > > > objects can be in the page.
> > > >
> > > > Anyway, I will look at it more. If you have any progress, please let me know.
> > >
> > > No progress at the moment.
> >
> > --
> > To unsubscribe, send a message with 'unsubscribe linux-mm' in
> > the body to majordomo at kvack.org. For more info on Linux MM,
> > see: http://www.linux-mm.org/ .
> > Don't email: <a href=mailto:"dont@kvack.org"> email at kvack.org </a>
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: possible regression on 3.13 when calling flush_dcache_page
2013-12-23 22:44 ` Ludovic Desroches
(?)
@ 2013-12-24 6:38 ` Joonsoo Kim
-1 siblings, 0 replies; 45+ messages in thread
From: Joonsoo Kim @ 2013-12-24 6:38 UTC (permalink / raw)
To: linux-mm, linux-kernel, linux-mmc, linux-arm-kernel
On Mon, Dec 23, 2013 at 11:44:35PM +0100, Ludovic Desroches wrote:
> On Fri, Dec 20, 2013 at 09:08:51AM +0100, Ludovic Desroches wrote:
> > Hello,
> >
> > On Wed, Dec 18, 2013 at 04:21:17PM +0900, Joonsoo Kim wrote:
> > > On Mon, Dec 16, 2013 at 03:43:43PM +0100, Ludovic Desroches wrote:
> > > > Hello,
> > > >
> > > > On Fri, Dec 13, 2013 at 10:59:09AM +0900, Joonsoo Kim wrote:
> > > > > On Thu, Dec 12, 2013 at 03:36:19PM +0100, Ludovic Desroches wrote:
> > > > > > fix mmc mailing list address error
> > > > > >
> > > > > > On Thu, Dec 12, 2013 at 03:31:50PM +0100, Ludovic Desroches wrote:
> > > > > > > Hi,
> > > > > > >
> > > > > > > With v3.13-rc3 I have an error when the atmel-mci driver calls
> > > > > > > flush_dcache_page (log at the end of the message).
> > > > > > >
> > > > > > > Since I didn't have it before, I did a git bisect and the commit introducing
> > > > > > > the error is the following one:
> > > > > > >
> > > > > > > 106a74e slab: replace free and inuse in struct slab with newly introduced active
> > > > > > >
> > > > > > > I don't know if this commit has introduced a bug or if it has revealed a bug
> > > > > > > in the atmel-mci driver.
> > > > >
> > > > > Hello,
> > > > >
> > > > > I think that this commit may not introduce a bug. This patch remove one
> > > > > variable on slab management structure and replace variable name. So there
> > > > > is no functional change.
> > > > >
> > > >
> > > > If I have reverted this patch and other ones you did on top of it and
> > > > the issue disappear.
> > >
> > > Hello,
> > >
> > > Could you give me your '/proc/slabinfo' before/after this commit (106a74e)?
> > >
> > > And how about testing with artificially increasing size of struct slab on
> > > top of this commit (106a74e)?
> > >
> > > I really wonder why the problem happens, because this doesn't cause any
> > > functional change as far as I know. Only side-effect from this patch is
> > > decreasing size of struct slab.
> >
> > Sorry I am not at the office, I have tried to reproduce it with a
> > different device and a different sdcard but without success. I'll test
> > it on Monday.
>
> I am still not at the office but I get the same device and the same
> sdcard and I don't reproduce it. I am not totally in the same
> conditions. It seems there is an extra parameter causing this bug but I
> don't figure out which one at the moment.
Okay. I will wait for you!
Thanks for informing progress.
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: possible regression on 3.13 when calling flush_dcache_page
@ 2013-12-24 6:38 ` Joonsoo Kim
0 siblings, 0 replies; 45+ messages in thread
From: Joonsoo Kim @ 2013-12-24 6:38 UTC (permalink / raw)
To: linux-mm, linux-kernel, linux-mmc, linux-arm-kernel
On Mon, Dec 23, 2013 at 11:44:35PM +0100, Ludovic Desroches wrote:
> On Fri, Dec 20, 2013 at 09:08:51AM +0100, Ludovic Desroches wrote:
> > Hello,
> >
> > On Wed, Dec 18, 2013 at 04:21:17PM +0900, Joonsoo Kim wrote:
> > > On Mon, Dec 16, 2013 at 03:43:43PM +0100, Ludovic Desroches wrote:
> > > > Hello,
> > > >
> > > > On Fri, Dec 13, 2013 at 10:59:09AM +0900, Joonsoo Kim wrote:
> > > > > On Thu, Dec 12, 2013 at 03:36:19PM +0100, Ludovic Desroches wrote:
> > > > > > fix mmc mailing list address error
> > > > > >
> > > > > > On Thu, Dec 12, 2013 at 03:31:50PM +0100, Ludovic Desroches wrote:
> > > > > > > Hi,
> > > > > > >
> > > > > > > With v3.13-rc3 I have an error when the atmel-mci driver calls
> > > > > > > flush_dcache_page (log at the end of the message).
> > > > > > >
> > > > > > > Since I didn't have it before, I did a git bisect and the commit introducing
> > > > > > > the error is the following one:
> > > > > > >
> > > > > > > 106a74e slab: replace free and inuse in struct slab with newly introduced active
> > > > > > >
> > > > > > > I don't know if this commit has introduced a bug or if it has revealed a bug
> > > > > > > in the atmel-mci driver.
> > > > >
> > > > > Hello,
> > > > >
> > > > > I think that this commit may not introduce a bug. This patch remove one
> > > > > variable on slab management structure and replace variable name. So there
> > > > > is no functional change.
> > > > >
> > > >
> > > > If I have reverted this patch and other ones you did on top of it and
> > > > the issue disappear.
> > >
> > > Hello,
> > >
> > > Could you give me your '/proc/slabinfo' before/after this commit (106a74e)?
> > >
> > > And how about testing with artificially increasing size of struct slab on
> > > top of this commit (106a74e)?
> > >
> > > I really wonder why the problem happens, because this doesn't cause any
> > > functional change as far as I know. Only side-effect from this patch is
> > > decreasing size of struct slab.
> >
> > Sorry I am not at the office, I have tried to reproduce it with a
> > different device and a different sdcard but without success. I'll test
> > it on Monday.
>
> I am still not at the office but I get the same device and the same
> sdcard and I don't reproduce it. I am not totally in the same
> conditions. It seems there is an extra parameter causing this bug but I
> don't figure out which one at the moment.
Okay. I will wait for you!
Thanks for informing progress.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 45+ messages in thread
* possible regression on 3.13 when calling flush_dcache_page
@ 2013-12-24 6:38 ` Joonsoo Kim
0 siblings, 0 replies; 45+ messages in thread
From: Joonsoo Kim @ 2013-12-24 6:38 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, Dec 23, 2013 at 11:44:35PM +0100, Ludovic Desroches wrote:
> On Fri, Dec 20, 2013 at 09:08:51AM +0100, Ludovic Desroches wrote:
> > Hello,
> >
> > On Wed, Dec 18, 2013 at 04:21:17PM +0900, Joonsoo Kim wrote:
> > > On Mon, Dec 16, 2013 at 03:43:43PM +0100, Ludovic Desroches wrote:
> > > > Hello,
> > > >
> > > > On Fri, Dec 13, 2013 at 10:59:09AM +0900, Joonsoo Kim wrote:
> > > > > On Thu, Dec 12, 2013 at 03:36:19PM +0100, Ludovic Desroches wrote:
> > > > > > fix mmc mailing list address error
> > > > > >
> > > > > > On Thu, Dec 12, 2013 at 03:31:50PM +0100, Ludovic Desroches wrote:
> > > > > > > Hi,
> > > > > > >
> > > > > > > With v3.13-rc3 I have an error when the atmel-mci driver calls
> > > > > > > flush_dcache_page (log at the end of the message).
> > > > > > >
> > > > > > > Since I didn't have it before, I did a git bisect and the commit introducing
> > > > > > > the error is the following one:
> > > > > > >
> > > > > > > 106a74e slab: replace free and inuse in struct slab with newly introduced active
> > > > > > >
> > > > > > > I don't know if this commit has introduced a bug or if it has revealed a bug
> > > > > > > in the atmel-mci driver.
> > > > >
> > > > > Hello,
> > > > >
> > > > > I think that this commit may not introduce a bug. This patch remove one
> > > > > variable on slab management structure and replace variable name. So there
> > > > > is no functional change.
> > > > >
> > > >
> > > > If I have reverted this patch and other ones you did on top of it and
> > > > the issue disappear.
> > >
> > > Hello,
> > >
> > > Could you give me your '/proc/slabinfo' before/after this commit (106a74e)?
> > >
> > > And how about testing with artificially increasing size of struct slab on
> > > top of this commit (106a74e)?
> > >
> > > I really wonder why the problem happens, because this doesn't cause any
> > > functional change as far as I know. Only side-effect from this patch is
> > > decreasing size of struct slab.
> >
> > Sorry I am not at the office, I have tried to reproduce it with a
> > different device and a different sdcard but without success. I'll test
> > it on Monday.
>
> I am still not at the office but I get the same device and the same
> sdcard and I don't reproduce it. I am not totally in the same
> conditions. It seems there is an extra parameter causing this bug but I
> don't figure out which one at the moment.
Okay. I will wait for you!
Thanks for informing progress.
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: possible regression on 3.13 when calling flush_dcache_page
2013-12-24 6:38 ` Joonsoo Kim
(?)
@ 2014-01-03 14:54 ` Ludovic Desroches
-1 siblings, 0 replies; 45+ messages in thread
From: Ludovic Desroches @ 2014-01-03 14:54 UTC (permalink / raw)
To: Joonsoo Kim
Cc: linux-mm, linux-kernel, linux-mmc, linux-arm-kernel, Ludovic Desroches
[-- Attachment #1: Type: text/plain, Size: 1560 bytes --]
Hi,
On Tue, Dec 24, 2013 at 03:38:37PM +0900, Joonsoo Kim wrote:
[...]
> > > > > > I think that this commit may not introduce a bug. This patch remove one
> > > > > > variable on slab management structure and replace variable name. So there
> > > > > > is no functional change.
You are right, the commit given by git bisect was not the good one...
Since I removed other patches done on top of it, I thought it really was
this one but in fact it is 8456a64.
dd0f774 Fri Jan 3 12:33:55 2014 +0100 Revert "slab: remove useless
statement for checking pfmemalloc" Ludovic Desroches
ff7487d Fri Jan 3 12:32:33 2014 +0100 Revert "slab: rename
slab_bufctl to slab_freelist" Ludovic Desroches
b963564 Fri Jan 3 12:32:13 2014 +0100 Revert "slab: fix to calm down
kmemleak warning" Ludovic Desroches
3fcfe50 Fri Jan 3 12:30:32 2014 +0100 Revert "slab: replace
non-existing 'struct freelist *' with 'void *'" Ludovic Desroches
750a795 Fri Jan 3 12:30:16 2014 +0100 Revert "memcg, kmem: rename
cache_from_memcg to cache_from_memcg_idx" Ludovic Desroches
7e2de8a Fri Jan 3 12:30:10 2014 +0100 mmc: atmel-mci: disable pdc
Ludovic Desroches
In this case I have the kernel oops. If I revert 8456a64 too, it
disappears.
I will try to test it on other devices because I couldn't reproduce it
with newer ones (but it's not the same ARM architecture so I would like
to see if it's also related to the device itself).
In attachment, there are the results of /proc/slabinfo before inserted the
sdio wifi module causing the oops.
Regards
Ludovic
[-- Attachment #2: 8456a64_reverted.log --]
[-- Type: text/plain, Size: 14408 bytes --]
# cat /proc/slabinfo
slabinfo - version: 2.1
# name <active_objs> <num_objs> <objsize> <objperslab> <pagesperslab> : tunables <limit> <batchcount> <sharedfactor> : slabdata <active_sla>
ubi_wl_entry_slab 0 0 24 145 1 : tunables 120 60 0 : slabdata 0 0 0
ubifs_inode_slab 0 0 368 10 1 : tunables 54 27 0 : slabdata 0 0 0
fib6_nodes 1 113 32 113 1 : tunables 120 60 0 : slabdata 1 1 0
ip6_dst_cache 1 17 224 17 1 : tunables 120 60 0 : slabdata 1 1 0
PINGv6 0 0 704 11 2 : tunables 54 27 0 : slabdata 0 0 0
RAWv6 4 11 704 11 2 : tunables 54 27 0 : slabdata 1 1 0
UDPLITEv6 0 0 704 11 2 : tunables 54 27 0 : slabdata 0 0 0
UDPv6 0 0 704 11 2 : tunables 54 27 0 : slabdata 0 0 0
tw_sock_TCPv6 0 0 160 24 1 : tunables 120 60 0 : slabdata 0 0 0
request_sock_TCPv6 0 0 192 20 1 : tunables 120 60 0 : slabdata 0 0 0
TCPv6 0 0 1344 3 1 : tunables 24 12 0 : slabdata 0 0 0
sd_ext_cdb 2 113 32 113 1 : tunables 120 60 0 : slabdata 1 1 0
nfs_direct_cache 0 0 96 40 1 : tunables 120 60 0 : slabdata 0 0 0
nfs_commit_data 4 9 416 9 1 : tunables 54 27 0 : slabdata 1 1 0
nfs_write_data 32 36 608 6 1 : tunables 54 27 0 : slabdata 6 6 0
nfs_read_data 0 0 576 7 1 : tunables 54 27 0 : slabdata 0 0 0
nfs_inode_cache 0 0 536 7 1 : tunables 54 27 0 : slabdata 0 0 0
nfs_page 0 0 64 60 1 : tunables 120 60 0 : slabdata 0 0 0
fat_inode_cache 0 0 360 11 1 : tunables 54 27 0 : slabdata 0 0 0
fat_cache 0 0 24 145 1 : tunables 120 60 0 : slabdata 0 0 0
jbd2_transaction_s 0 0 160 24 1 : tunables 120 60 0 : slabdata 0 0 0
jbd2_inode 0 0 24 145 1 : tunables 120 60 0 : slabdata 0 0 0
jbd2_journal_handle 0 0 32 113 1 : tunables 120 60 0 : slabdata 0 0 0
jbd2_journal_head 0 0 64 60 1 : tunables 120 60 0 : slabdata 0 0 0
jbd2_revoke_table_s 0 0 16 204 1 : tunables 120 60 0 : slabdata 0 0 0
jbd2_revoke_record_s 0 0 32 113 1 : tunables 120 60 0 : slabdata 0 0 0
ext4_inode_cache 0 0 536 7 1 : tunables 54 27 0 : slabdata 0 0 0
ext4_xattr 0 0 48 78 1 : tunables 120 60 0 : slabdata 0 0 0
ext4_free_data 0 0 40 92 1 : tunables 120 60 0 : slabdata 0 0 0
ext4_allocation_context 0 0 112 35 1 : tunables 120 60 0 : slabdata 0 0 0
ext4_prealloc_space 0 0 64 60 1 : tunables 120 60 0 : slabdata 0 0 0
ext4_system_zone 0 0 32 113 1 : tunables 120 60 0 : slabdata 0 0 0
ext4_io_end 0 0 40 92 1 : tunables 120 60 0 : slabdata 0 0 0
ext4_extent_status 0 0 32 113 1 : tunables 120 60 0 : slabdata 0 0 0
configfs_dir_cache 1 68 56 68 1 : tunables 120 60 0 : slabdata 1 1 0
kioctx 0 0 192 20 1 : tunables 120 60 0 : slabdata 0 0 0
kiocb 0 0 64 60 1 : tunables 120 60 0 : slabdata 0 0 0
fanotify_response_event 0 0 16 204 1 : tunables 120 60 0 : slabdata 0 0 0
fsnotify_mark 0 0 64 60 1 : tunables 120 60 0 : slabdata 0 0 0
inotify_event_private_data 0 0 16 204 1 : tunables 120 60 0 : slabdata 0 0 0
inotify_inode_mark 12 60 64 60 1 : tunables 120 60 0 : slabdata 1 1 0
dnotify_mark 0 0 64 60 1 : tunables 120 60 0 : slabdata 0 0 0
dnotify_struct 0 0 24 145 1 : tunables 120 60 0 : slabdata 0 0 0
dio 0 0 328 12 1 : tunables 54 27 0 : slabdata 0 0 0
fasync_cache 0 0 24 145 1 : tunables 120 60 0 : slabdata 0 0 0
posix_timers_cache 0 0 152 26 1 : tunables 120 60 0 : slabdata 0 0 0
uid_cache 0 0 64 60 1 : tunables 120 60 0 : slabdata 0 0 0
rpc_inode_cache 0 0 320 12 1 : tunables 54 27 0 : slabdata 0 0 0
rpc_buffers 8 8 2048 2 1 : tunables 24 12 0 : slabdata 4 4 0
rpc_tasks 8 30 128 30 1 : tunables 120 60 0 : slabdata 1 1 0
UNIX 5 8 480 8 1 : tunables 54 27 0 : slabdata 1 1 0
UDP-Lite 0 0 608 6 1 : tunables 54 27 0 : slabdata 0 0 0
tcp_bind_bucket 0 0 32 113 1 : tunables 120 60 0 : slabdata 0 0 0
inet_peer_cache 0 0 128 30 1 : tunables 120 60 0 : slabdata 0 0 0
ip_fib_trie 3 113 32 113 1 : tunables 120 60 0 : slabdata 1 1 0
ip_fib_alias 4 145 24 145 1 : tunables 120 60 0 : slabdata 1 1 0
ip_dst_cache 0 0 128 30 1 : tunables 120 60 0 : slabdata 0 0 0
PING 0 0 576 7 1 : tunables 54 27 0 : slabdata 0 0 0
RAW 1 7 576 7 1 : tunables 54 27 0 : slabdata 1 1 0
UDP 0 0 608 6 1 : tunables 54 27 0 : slabdata 0 0 0
tw_sock_TCP 0 0 160 24 1 : tunables 120 60 0 : slabdata 0 0 0
request_sock_TCP 0 0 192 20 1 : tunables 120 60 0 : slabdata 0 0 0
TCP 0 0 1216 3 1 : tunables 24 12 0 : slabdata 0 0 0
eventpoll_pwq 9 92 40 92 1 : tunables 120 60 0 : slabdata 1 1 0
eventpoll_epi 9 80 96 40 1 : tunables 120 60 0 : slabdata 2 2 0
sgpool-128 2 2 2048 2 1 : tunables 24 12 0 : slabdata 1 1 0
sgpool-64 2 4 1024 4 1 : tunables 54 27 0 : slabdata 1 1 0
sgpool-32 2 8 512 8 1 : tunables 54 27 0 : slabdata 1 random: nonblocking pool is initialized
1 0
sgpool-16 2 15 256 15 1 : tunables 120 60 0 : slabdata 1 1 0
sgpool-8 2 30 128 30 1 : tunables 120 60 0 : slabdata 1 1 0
scsi_data_buffer 0 0 24 145 1 : tunables 120 60 0 : slabdata 0 0 0
blkdev_queue 14 14 1032 7 2 : tunables 24 12 0 : slabdata 2 2 0
blkdev_requests 8 18 216 18 1 : tunables 120 60 0 : slabdata 1 1 0
blkdev_ioc 0 0 64 60 1 : tunables 120 60 0 : slabdata 0 0 0
fsnotify_event_holder 0 0 16 204 1 : tunables 120 60 0 : slabdata 0 0 0
fsnotify_event 1 60 64 60 1 : tunables 120 60 0 : slabdata 1 1 0
bio-0 2 30 128 30 1 : tunables 120 60 0 : slabdata 1 1 0
biovec-256 2 2 3072 2 2 : tunables 24 12 0 : slabdata 1 1 0
biovec-128 0 0 1536 5 2 : tunables 24 12 0 : slabdata 0 0 0
biovec-64 0 0 768 5 1 : tunables 54 27 0 : slabdata 0 0 0
biovec-16 0 0 192 20 1 : tunables 120 60 0 : slabdata 0 0 0
sock_inode_cache 21 36 320 12 1 : tunables 54 27 0 : slabdata 3 3 0
skbuff_fclone_cache 0 0 352 11 1 : tunables 54 27 0 : slabdata 0 0 0
skbuff_head_cache 4 20 192 20 1 : tunables 120 60 0 : slabdata 1 1 0
file_lock_cache 4 35 112 35 1 : tunables 120 60 0 : slabdata 1 1 0
shmem_inode_cache 394 396 312 12 1 : tunables 54 27 0 : slabdata 33 33 0
pool_workqueue 6 15 256 15 1 : tunables 120 60 0 : slabdata 1 1 0
proc_inode_cache 48 48 312 12 1 : tunables 54 27 0 : slabdata 4 4 0
sigqueue 0 0 144 27 1 : tunables 120 60 0 : slabdata 0 0 0
bdev_cache 13 18 416 9 1 : tunables 54 27 0 : slabdata 2 2 0
sysfs_dir_cache 2926 2940 64 60 1 : tunables 120 60 0 : slabdata 49 49 0
mnt_cache 20 24 160 24 1 : tunables 120 60 0 : slabdata 1 1 0
filp 96 120 160 24 1 : tunables 120 60 0 : slabdata 5 5 0
inode_cache 1563 1568 280 14 1 : tunables 54 27 0 : slabdata 112 112 0
dentry 2030 2030 136 29 1 : tunables 120 60 0 : slabdata 70 70 0
names_cache 1 1 4096 1 1 : tunables 24 12 0 : slabdata 1 1 0
buffer_head 0 0 56 68 1 : tunables 120 60 0 : slabdata 0 0 0
nsproxy 1 145 24 145 1 : tunables 120 60 0 : slabdata 1 1 0
vm_area_struct 215 396 88 44 1 : tunables 120 60 0 : slabdata 9 9 0
mm_struct 20 20 384 10 1 : tunables 54 27 0 : slabdata 2 2 0
fs_cache 11 113 32 113 1 : tunables 120 60 0 : slabdata 1 1 0
files_cache 11 40 192 20 1 : tunables 120 60 0 : slabdata 2 2 0
signal_cache 29 42 512 7 1 : tunables 54 27 0 : slabdata 6 6 0
sighand_cache 33 33 1312 3 1 : tunables 24 12 0 : slabdata 11 11 0
task_struct 29 42 672 6 1 : tunables 54 27 0 : slabdata 7 7 0
cred_jar 40 120 96 40 1 : tunables 120 60 0 : slabdata 3 3 0
anon_vma_chain 254 678 32 113 1 : tunables 120 60 0 : slabdata 6 6 0
anon_vma 193 435 24 145 1 : tunables 120 60 0 : slabdata 3 3 0
pid 33 60 64 60 1 : tunables 120 60 0 : slabdata 1 1 0
radix_tree_node 130 143 296 13 1 : tunables 54 27 0 : slabdata 11 11 0
idr_layer_cache 62 63 1080 7 2 : tunables 24 12 0 : slabdata 9 9 0
kmalloc-4194304 0 0 4194304 1 1024 : tunables 1 1 0 : slabdata 0 0 0
kmalloc-2097152 0 0 2097152 1 512 : tunables 1 1 0 : slabdata 0 0 0
kmalloc-1048576 0 0 1048576 1 256 : tunables 1 1 0 : slabdata 0 0 0
kmalloc-524288 0 0 524288 1 128 : tunables 1 1 0 : slabdata 0 0 0
kmalloc-262144 0 0 262144 1 64 : tunables 1 1 0 : slabdata 0 0 0
kmalloc-131072 0 0 131072 1 32 : tunables 8 4 0 : slabdata 0 0 0
kmalloc-65536 0 0 65536 1 16 : tunables 8 4 0 : slabdata 0 0 0
kmalloc-32768 2 2 32768 1 8 : tunables 8 4 0 : slabdata 2 2 0
kmalloc-16384 1 1 16384 1 4 : tunables 8 4 0 : slabdata 1 1 0
kmalloc-8192 2 2 8192 1 2 : tunables 8 4 0 : slabdata 2 2 0
kmalloc-4096 4 4 4096 1 1 : tunables 24 12 0 : slabdata 4 4 0
kmalloc-2048 28 28 2048 2 1 : tunables 24 12 0 : slabdata 14 14 0
kmalloc-1024 39 44 1024 4 1 : tunables 54 27 0 : slabdata 11 11 0
kmalloc-512 204 208 512 8 1 : tunables 54 27 0 : slabdata 26 26 0
kmalloc-256 183 195 256 15 1 : tunables 120 60 0 : slabdata 13 13 0
kmalloc-192 134 140 192 20 1 : tunables 120 60 0 : slabdata 7 7 0
kmalloc-128 204 210 128 30 1 : tunables 120 60 0 : slabdata 7 7 0
kmalloc-96 1099 1120 96 40 1 : tunables 120 60 0 : slabdata 28 28 0
kmalloc-64 648 720 64 60 1 : tunables 120 60 0 : slabdata 12 12 0
kmalloc-32 3018 3164 32 113 1 : tunables 120 60 0 : slabdata 28 28 0
kmem_cache 131 160 96 40 1 : tunables 120 60 0 : slabdata 4 4 0
[-- Attachment #3: with_8456a64.log --]
[-- Type: text/plain, Size: 14367 bytes --]
# cat /proc/slabinfo
slabinfo - version: 2.1
# name <active_objs> <num_objs> <objsize> <objperslab> <pagesperslab> : tunables <limit> <batchcount> <sharedfactor> : slabdata <active_sla>
ubi_wl_entry_slab 0 0 24 146 1 : tunables 120 60 0 : slabdata 0 0 0
ubifs_inode_slab 0 0 368 11 1 : tunables 54 27 0 : slabdata 0 0 0
fib6_nodes 1 113 32 113 1 : tunables 120 60 0 : slabdata 1 1 0
ip6_dst_cache 1 17 224 17 1 : tunables 120 60 0 : slabdata 1 1 0
PINGv6 0 0 704 11 2 : tunables 54 27 0 : slabdata 0 0 0
RAWv6 4 11 704 11 2 : tunables 54 27 0 : slabdata 1 1 0
UDPLITEv6 0 0 704 11 2 : tunables 54 27 0 : slabdata 0 0 0
UDPv6 0 0 704 11 2 : tunables 54 27 0 : slabdata 0 0 0
tw_sock_TCPv6 0 0 160 24 1 : tunables 120 60 0 : slabdata 0 0 0
request_sock_TCPv6 0 0 192 20 1 : tunables 120 60 0 : slabdata 0 0 0
TCPv6 0 0 1344 3 1 : tunables 24 12 0 : slabdata 0 0 0
sd_ext_cdb 2 113 32 113 1 : tunables 120 60 0 : slabdata 1 1 0
nfs_direct_cache 0 0 96 40 1 : tunables 120 60 0 : slabdata 0 0 0
nfs_commit_data 4 9 416 9 1 : tunables 54 27 0 : slabdata 1 1 0
nfs_write_data 32 36 608 6 1 : tunables 54 27 0 : slabdata 6 6 0
nfs_read_data 0 0 576 7 1 : tunables 54 27 0 : slabdata 0 0 0
nfs_inode_cache 0 0 536 7 1 : tunables 54 27 0 : slabdata 0 0 0
nfs_page 0 0 64 60 1 : tunables 120 60 0 : slabdata 0 0 0
fat_inode_cache 0 0 360 11 1 : tunables 54 27 0 : slabdata 0 0 0
fat_cache 0 0 24 146 1 : tunables 120 60 0 : slabdata 0 0 0
jbd2_transaction_s 0 0 160 24 1 : tunables 120 60 0 : slabdata 0 0 0
jbd2_inode 0 0 24 146 1 : tunables 120 60 0 : slabdata 0 0 0
jbd2_journal_handle 0 0 32 113 1 : tunables 120 60 0 : slabdata 0 0 0
jbd2_journal_head 0 0 64 60 1 : tunables 120 60 0 : slabdata 0 0 0
jbd2_revoke_table_s 0 0 16 204 1 : tunables 120 60 0 : slabdata 0 0 0
jbd2_revoke_record_s 0 0 32 113 1 : tunables 120 60 0 : slabdata 0 0 0
ext4_inode_cache 0 0 536 7 1 : tunables 54 27 0 : slabdata 0 0 0
ext4_xattr 0 0 48 78 1 : tunables 120 60 0 : slabdata 0 0 0
ext4_free_data 0 0 40 93 1 : tunables 120 60 0 : slabdata 0 0 0
ext4_allocation_context 0 0 112 35 1 : tunables 120 60 0 : slabdata 0 0 0
ext4_prealloc_space 0 0 64 60 1 : tunables 120 60 0 : slabdata 0 0 0
ext4_system_zone 0 0 32 113 1 : tunables 120 60 0 : slabdata 0 0 0
ext4_io_end 0 0 40 93 1 : tunables 120 60 0 : slabdata 0 0 0
ext4_extent_status 0 0 32 113 1 : tunables 120 60 0 : slabdata 0 0 0
configfs_dir_cache 1 68 56 68 1 : tunables 120 60 0 : slabdata 1 1 0
kioctx 0 0 192 20 1 : tunables 120 60 0 : slabdata 0 0 0
kiocb 0 0 64 60 1 : tunables 120 60 0 : slabdata 0 0 0
fanotify_response_event 0 0 16 204 1 : tunables 120 60 0 : slabdata 0 0 0
fsnotify_mark 0 0 64 60 1 : tunables 120 60 0 : slabdata 0 0 0
inotify_event_private_data 0 0 16 204 1 : tunables 120 60 0 : slabdata 0 0 0
inotify_inode_mark 12 60 64 60 1 : tunables 120 60 0 : slabdata 1 1 0
dnotify_mark 0 0 64 60 1 : tunables 120 60 0 : slabdata 0 0 0
dnotify_struct 0 0 24 146 1 : tunables 120 60 0 : slabdata 0 0 0
dio 0 0 328 12 1 : tunables 54 27 0 : slabdata 0 0 0
fasync_cache 0 0 24 146 1 : tunables 120 60 0 : slabdata 0 0 0
posix_timers_cache 0 0 152 26 1 : tunables 120 60 0 : slabdata 0 0 0
uid_cache 0 0 64 60 1 : tunables 120 60 0 : slabdata 0 0 0
rpc_inode_cache 0 0 320 12 1 : tunables 54 27 0 : slabdata 0 0 0
rpc_buffers 8 8 2048 2 1 : tunables 24 12 0 : slabdata 4 4 0
rpc_tasks 8 31 128 31 1 : tunables 120 60 0 : slabdata 1 1 0
UNIX 5 8 480 8 1 : tunables 54 27 0 : slabdata 1 1 0
UDP-Lite 0 0 608 6 1 : tunables 54 27 0 : slabdata 0 0 0
tcp_bind_bucket 0 0 32 113 1 : tunables 120 60 0 : slabdata 0 0 0
inet_peer_cache 0 0 128 31 1 : tunables 120 60 0 : slabdata 0 0 0
ip_fib_trie 3 113 32 113 1 : tunables 120 60 0 : slabdata 1 1 0
ip_fib_alias 4 146 24 146 1 : tunables 120 60 0 : slabdata 1 1 0
ip_dst_cache 0 0 128 31 1 : tunables 120 60 0 : slabdata 0 0 0
PING 0 0 576 7 1 : tunables 54 27 0 : slabdata 0 0 0
RAW 1 7 576 7 1 : tunables 54 27 0 : slabdata 1 1 0
UDP 0 0 608 6 1 : tunables 54 27 0 : slabdata 0 0 0
tw_sock_TCP 0 0 160 24 1 : tunables 120 60 0 : slabdata 0 0 0
request_sock_TCP 0 0 192 20 1 : tunables 120 60 0 : slabdata 0 0 0
TCP 0 0 1216 3 1 : tunables 24 12 0 : slabdata 0 0 0
eventpoll_pwq 9 93 40 93 1 : tunables 120 60 0 : slabdata 1 1 0
eventpoll_epi 9 80 96 40 1 : tunables 120 60 0 : slabdata 2 2 0
sgpool-128 2 2 2048 2 1 : tunables 24 12 0 : slabdata 1 1 0
sgpool-64 2 4 1024 4 1 : tunables 54 27 0 : slabdata 1 1 0
sgpool-32 2 8 512 8 1 : tunables 54 27 0 : slabdata 1 1 0
sgpool-16 2 15 256 15 1 : tunables 120 60 0 : slabdata 1 1 0
sgpool-8 2 31 128 31 1 : tunables 120 60 0 : slabdata 1 1 0
scsi_data_buffer 0 0 24 146 1 : tunables 120 60 0 : slabdata 0 0 0
blkdev_queue 14 14 1032 7 2 : tunables 24 12 0 : slabdata 2 2 0
blkdev_requests 8 18 216 18 1 : tunables 120 60 0 : slabdata 1 1 0
blkdev_ioc 0 0 64 60 1 : tunables 120 60 0 : slabdata 0 0 0
fsnotify_event_holder 0 0 16 204 1 : tunables 120 60 0 : slabdata 0 0 0
fsnotify_event 1 60 64 60 1 : tunables 120 60 0 : slabdata 1 1 0
bio-0 2 31 128 31 1 : tunables 120 60 0 : slabdata 1 1 0
biovec-256 2 2 3072 2 2 : tunables 24 12 0 : slabdata 1 1 0
biovec-128 0 0 1536 5 2 : tunables 24 12 0 : slabdata 0 0 0
biovec-64 0 0 768 5 1 : tunables 54 27 0 : slabdata 0 0 0
biovec-16 0 0 192 20 1 : tunables 120 60 0 : slabdata 0 0 0
sock_inode_cache 19 36 320 12 1 : tunables 54 27 0 : slabdata 3 3 0
skbuff_fclone_cache 0 0 352 11 1 : tunables 54 27 0 : slabdata 0 0 0
skbuff_head_cache 0 0 192 20 1 : tunables 120 60 0 : slabdata 0 0 0
file_lock_cache 0 0 112 35 1 : tunables 120 60 0 : slabdata 0 0 0
shmem_inode_cache 394 396 312 12 1 : tunables 54 27 0 : slabdata 33 33 0
pool_workqueue 6 15 256 15 1 : tunables 120 60 0 : slabdata 1 1 0
proc_inode_cache 12 12 312 12 1 : tunables 54 27 0 : slabdata 1 1 0
sigqueue 0 0 144 27 1 : tunables 120 60 0 : slabdata 0 0 0
bdev_cache 13 18 416 9 1 : tunables 54 27 0 : slabdata 2 2 0
sysfs_dir_cache 2926 2940 64 60 1 : tunables 120 60 0 : slabdata 49 49 0
mnt_cache 20 24 160 24 1 : tunables 120 60 0 : slabdata 1 1 0
filp 65 144 160 24 1 : tunables 120 60 0 : slabdata 6 6 0
inode_cache 1564 1568 280 14 1 : tunables 54 27 0 : slabdata 112 112 0
dentry 2001 2059 136 29 1 : tunables 120 60 0 : slabdata 71 71 0
names_cache 1 1 4096 1 1 : tunables 24 12 0 : slabdata 1 1 0
buffer_head 0 0 56 68 1 : tunables 120 60 0 : slabdata 0 0 0
nsproxy 1 146 24 146 1 : tunables 120 60 0 : slabdata 1 1 0
vm_area_struct 267 352 88 44 1 : tunables 120 60 0 : slabdata 8 8 0
mm_struct 20 20 384 10 1 : tunables 54 27 0 : slabdata 2 2 0
fs_cache 23 113 32 113 1 : tunables 120 60 0 : slabdata 1 1 0
files_cache 23 40 192 20 1 : tunables 120 60 0 : slabdata 2 2 0
signal_cache 42 42 512 7 1 : tunables 54 27 0 : slabdata 6 6 0
sighand_cache 33 33 1312 3 1 : tunables 24 12 0 : slabdata 11 11 0
task_struct 44 48 672 6 1 : tunables 54 27 0 : slabdata 8 8 0
cred_jar 53 80 96 40 1 : tunables 120 60 0 : slabdata 2 2 0
anon_vma_chain 304 791 32 113 1 : tunables 120 60 0 : slabdata 7 7 0
anon_vma 146 438 24 146 1 : tunables 120 60 0 : slabdata 3 3 0
pid 45 60 64 60 1 : tunables 120 60 0 : slabdata 1 1 0
radix_tree_node 131 143 296 13 1 : tunables 54 27 0 : slabdata 11 11 0
idr_layer_cache 62 63 1080 7 2 : tunables 24 12 0 : slabdata 9 9 0
kmalloc-4194304 0 0 4194304 1 1024 : tunables 1 1 0 : slabdata 0 0 0
kmalloc-2097152 0 0 2097152 1 512 : tunables 1 1 0 : slabdata 0 0 0
kmalloc-1048576 0 0 1048576 1 256 : tunables 1 1 0 : slabdata 0 0 0
kmalloc-524288 0 0 524288 1 128 : tunables 1 1 0 : slabdata 0 0 0
kmalloc-262144 0 0 262144 1 64 : tunables 1 1 0 : slabdata 0 0 0
kmalloc-131072 0 0 131072 1 32 : tunables 8 4 0 : slabdata 0 0 0
kmalloc-65536 0 0 65536 1 16 : tunables 8 4 0 : slabdata 0 0 0
kmalloc-32768 2 2 32768 1 8 : tunables 8 4 0 : slabdata 2 2 0
kmalloc-16384 1 1 16384 1 4 : tunables 8 4 0 : slabdata 1 1 0
kmalloc-8192 2 2 8192 1 2 : tunables 8 4 0 : slabdata 2 2 0
kmalloc-4096 4 4 4096 1 1 : tunables 24 12 0 : slabdata 4 4 0
kmalloc-2048 28 28 2048 2 1 : tunables 24 12 0 : slabdata 14 14 0
kmalloc-1024 38 40 1024 4 1 : tunables 54 27 0 : slabdata 10 10 0
kmalloc-512 203 208 512 8 1 : tunables 54 27 0 : slabdata 26 26 0
kmalloc-256 195 195 256 15 1 : tunables 120 60 0 : slabdata 13 13 0
kmalloc-192 140 140 192 20 1 : tunables 120 60 0 : slabdata 7 7 0
kmalloc-128 217 217 128 31 1 : tunables 120 60 0 : slabdata 7 7 0
kmalloc-96 1111 1120 96 40 1 : tunables 120 60 0 : slabdata 28 28 0
kmalloc-64 621 660 64 60 1 : tunables 120 60 0 : slabdata 11 11 0
kmalloc-32 3056 3164 32 113 1 : tunables 120 60 0 : slabdata 28 28 0
kmem_cache 131 160 96 40 1 : tunables 120 60 0 : slabdata 4 4 0
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: possible regression on 3.13 when calling flush_dcache_page
@ 2014-01-03 14:54 ` Ludovic Desroches
0 siblings, 0 replies; 45+ messages in thread
From: Ludovic Desroches @ 2014-01-03 14:54 UTC (permalink / raw)
To: Joonsoo Kim
Cc: linux-mm, linux-kernel, linux-mmc, linux-arm-kernel, Ludovic Desroches
[-- Attachment #1: Type: text/plain, Size: 1560 bytes --]
Hi,
On Tue, Dec 24, 2013 at 03:38:37PM +0900, Joonsoo Kim wrote:
[...]
> > > > > > I think that this commit may not introduce a bug. This patch remove one
> > > > > > variable on slab management structure and replace variable name. So there
> > > > > > is no functional change.
You are right, the commit given by git bisect was not the good one...
Since I removed other patches done on top of it, I thought it really was
this one but in fact it is 8456a64.
dd0f774 Fri Jan 3 12:33:55 2014 +0100 Revert "slab: remove useless
statement for checking pfmemalloc" Ludovic Desroches
ff7487d Fri Jan 3 12:32:33 2014 +0100 Revert "slab: rename
slab_bufctl to slab_freelist" Ludovic Desroches
b963564 Fri Jan 3 12:32:13 2014 +0100 Revert "slab: fix to calm down
kmemleak warning" Ludovic Desroches
3fcfe50 Fri Jan 3 12:30:32 2014 +0100 Revert "slab: replace
non-existing 'struct freelist *' with 'void *'" Ludovic Desroches
750a795 Fri Jan 3 12:30:16 2014 +0100 Revert "memcg, kmem: rename
cache_from_memcg to cache_from_memcg_idx" Ludovic Desroches
7e2de8a Fri Jan 3 12:30:10 2014 +0100 mmc: atmel-mci: disable pdc
Ludovic Desroches
In this case I have the kernel oops. If I revert 8456a64 too, it
disappears.
I will try to test it on other devices because I couldn't reproduce it
with newer ones (but it's not the same ARM architecture so I would like
to see if it's also related to the device itself).
In attachment, there are the results of /proc/slabinfo before inserted the
sdio wifi module causing the oops.
Regards
Ludovic
[-- Attachment #2: 8456a64_reverted.log --]
[-- Type: text/plain, Size: 14408 bytes --]
# cat /proc/slabinfo
slabinfo - version: 2.1
# name <active_objs> <num_objs> <objsize> <objperslab> <pagesperslab> : tunables <limit> <batchcount> <sharedfactor> : slabdata <active_sla>
ubi_wl_entry_slab 0 0 24 145 1 : tunables 120 60 0 : slabdata 0 0 0
ubifs_inode_slab 0 0 368 10 1 : tunables 54 27 0 : slabdata 0 0 0
fib6_nodes 1 113 32 113 1 : tunables 120 60 0 : slabdata 1 1 0
ip6_dst_cache 1 17 224 17 1 : tunables 120 60 0 : slabdata 1 1 0
PINGv6 0 0 704 11 2 : tunables 54 27 0 : slabdata 0 0 0
RAWv6 4 11 704 11 2 : tunables 54 27 0 : slabdata 1 1 0
UDPLITEv6 0 0 704 11 2 : tunables 54 27 0 : slabdata 0 0 0
UDPv6 0 0 704 11 2 : tunables 54 27 0 : slabdata 0 0 0
tw_sock_TCPv6 0 0 160 24 1 : tunables 120 60 0 : slabdata 0 0 0
request_sock_TCPv6 0 0 192 20 1 : tunables 120 60 0 : slabdata 0 0 0
TCPv6 0 0 1344 3 1 : tunables 24 12 0 : slabdata 0 0 0
sd_ext_cdb 2 113 32 113 1 : tunables 120 60 0 : slabdata 1 1 0
nfs_direct_cache 0 0 96 40 1 : tunables 120 60 0 : slabdata 0 0 0
nfs_commit_data 4 9 416 9 1 : tunables 54 27 0 : slabdata 1 1 0
nfs_write_data 32 36 608 6 1 : tunables 54 27 0 : slabdata 6 6 0
nfs_read_data 0 0 576 7 1 : tunables 54 27 0 : slabdata 0 0 0
nfs_inode_cache 0 0 536 7 1 : tunables 54 27 0 : slabdata 0 0 0
nfs_page 0 0 64 60 1 : tunables 120 60 0 : slabdata 0 0 0
fat_inode_cache 0 0 360 11 1 : tunables 54 27 0 : slabdata 0 0 0
fat_cache 0 0 24 145 1 : tunables 120 60 0 : slabdata 0 0 0
jbd2_transaction_s 0 0 160 24 1 : tunables 120 60 0 : slabdata 0 0 0
jbd2_inode 0 0 24 145 1 : tunables 120 60 0 : slabdata 0 0 0
jbd2_journal_handle 0 0 32 113 1 : tunables 120 60 0 : slabdata 0 0 0
jbd2_journal_head 0 0 64 60 1 : tunables 120 60 0 : slabdata 0 0 0
jbd2_revoke_table_s 0 0 16 204 1 : tunables 120 60 0 : slabdata 0 0 0
jbd2_revoke_record_s 0 0 32 113 1 : tunables 120 60 0 : slabdata 0 0 0
ext4_inode_cache 0 0 536 7 1 : tunables 54 27 0 : slabdata 0 0 0
ext4_xattr 0 0 48 78 1 : tunables 120 60 0 : slabdata 0 0 0
ext4_free_data 0 0 40 92 1 : tunables 120 60 0 : slabdata 0 0 0
ext4_allocation_context 0 0 112 35 1 : tunables 120 60 0 : slabdata 0 0 0
ext4_prealloc_space 0 0 64 60 1 : tunables 120 60 0 : slabdata 0 0 0
ext4_system_zone 0 0 32 113 1 : tunables 120 60 0 : slabdata 0 0 0
ext4_io_end 0 0 40 92 1 : tunables 120 60 0 : slabdata 0 0 0
ext4_extent_status 0 0 32 113 1 : tunables 120 60 0 : slabdata 0 0 0
configfs_dir_cache 1 68 56 68 1 : tunables 120 60 0 : slabdata 1 1 0
kioctx 0 0 192 20 1 : tunables 120 60 0 : slabdata 0 0 0
kiocb 0 0 64 60 1 : tunables 120 60 0 : slabdata 0 0 0
fanotify_response_event 0 0 16 204 1 : tunables 120 60 0 : slabdata 0 0 0
fsnotify_mark 0 0 64 60 1 : tunables 120 60 0 : slabdata 0 0 0
inotify_event_private_data 0 0 16 204 1 : tunables 120 60 0 : slabdata 0 0 0
inotify_inode_mark 12 60 64 60 1 : tunables 120 60 0 : slabdata 1 1 0
dnotify_mark 0 0 64 60 1 : tunables 120 60 0 : slabdata 0 0 0
dnotify_struct 0 0 24 145 1 : tunables 120 60 0 : slabdata 0 0 0
dio 0 0 328 12 1 : tunables 54 27 0 : slabdata 0 0 0
fasync_cache 0 0 24 145 1 : tunables 120 60 0 : slabdata 0 0 0
posix_timers_cache 0 0 152 26 1 : tunables 120 60 0 : slabdata 0 0 0
uid_cache 0 0 64 60 1 : tunables 120 60 0 : slabdata 0 0 0
rpc_inode_cache 0 0 320 12 1 : tunables 54 27 0 : slabdata 0 0 0
rpc_buffers 8 8 2048 2 1 : tunables 24 12 0 : slabdata 4 4 0
rpc_tasks 8 30 128 30 1 : tunables 120 60 0 : slabdata 1 1 0
UNIX 5 8 480 8 1 : tunables 54 27 0 : slabdata 1 1 0
UDP-Lite 0 0 608 6 1 : tunables 54 27 0 : slabdata 0 0 0
tcp_bind_bucket 0 0 32 113 1 : tunables 120 60 0 : slabdata 0 0 0
inet_peer_cache 0 0 128 30 1 : tunables 120 60 0 : slabdata 0 0 0
ip_fib_trie 3 113 32 113 1 : tunables 120 60 0 : slabdata 1 1 0
ip_fib_alias 4 145 24 145 1 : tunables 120 60 0 : slabdata 1 1 0
ip_dst_cache 0 0 128 30 1 : tunables 120 60 0 : slabdata 0 0 0
PING 0 0 576 7 1 : tunables 54 27 0 : slabdata 0 0 0
RAW 1 7 576 7 1 : tunables 54 27 0 : slabdata 1 1 0
UDP 0 0 608 6 1 : tunables 54 27 0 : slabdata 0 0 0
tw_sock_TCP 0 0 160 24 1 : tunables 120 60 0 : slabdata 0 0 0
request_sock_TCP 0 0 192 20 1 : tunables 120 60 0 : slabdata 0 0 0
TCP 0 0 1216 3 1 : tunables 24 12 0 : slabdata 0 0 0
eventpoll_pwq 9 92 40 92 1 : tunables 120 60 0 : slabdata 1 1 0
eventpoll_epi 9 80 96 40 1 : tunables 120 60 0 : slabdata 2 2 0
sgpool-128 2 2 2048 2 1 : tunables 24 12 0 : slabdata 1 1 0
sgpool-64 2 4 1024 4 1 : tunables 54 27 0 : slabdata 1 1 0
sgpool-32 2 8 512 8 1 : tunables 54 27 0 : slabdata 1 random: nonblocking pool is initialized
1 0
sgpool-16 2 15 256 15 1 : tunables 120 60 0 : slabdata 1 1 0
sgpool-8 2 30 128 30 1 : tunables 120 60 0 : slabdata 1 1 0
scsi_data_buffer 0 0 24 145 1 : tunables 120 60 0 : slabdata 0 0 0
blkdev_queue 14 14 1032 7 2 : tunables 24 12 0 : slabdata 2 2 0
blkdev_requests 8 18 216 18 1 : tunables 120 60 0 : slabdata 1 1 0
blkdev_ioc 0 0 64 60 1 : tunables 120 60 0 : slabdata 0 0 0
fsnotify_event_holder 0 0 16 204 1 : tunables 120 60 0 : slabdata 0 0 0
fsnotify_event 1 60 64 60 1 : tunables 120 60 0 : slabdata 1 1 0
bio-0 2 30 128 30 1 : tunables 120 60 0 : slabdata 1 1 0
biovec-256 2 2 3072 2 2 : tunables 24 12 0 : slabdata 1 1 0
biovec-128 0 0 1536 5 2 : tunables 24 12 0 : slabdata 0 0 0
biovec-64 0 0 768 5 1 : tunables 54 27 0 : slabdata 0 0 0
biovec-16 0 0 192 20 1 : tunables 120 60 0 : slabdata 0 0 0
sock_inode_cache 21 36 320 12 1 : tunables 54 27 0 : slabdata 3 3 0
skbuff_fclone_cache 0 0 352 11 1 : tunables 54 27 0 : slabdata 0 0 0
skbuff_head_cache 4 20 192 20 1 : tunables 120 60 0 : slabdata 1 1 0
file_lock_cache 4 35 112 35 1 : tunables 120 60 0 : slabdata 1 1 0
shmem_inode_cache 394 396 312 12 1 : tunables 54 27 0 : slabdata 33 33 0
pool_workqueue 6 15 256 15 1 : tunables 120 60 0 : slabdata 1 1 0
proc_inode_cache 48 48 312 12 1 : tunables 54 27 0 : slabdata 4 4 0
sigqueue 0 0 144 27 1 : tunables 120 60 0 : slabdata 0 0 0
bdev_cache 13 18 416 9 1 : tunables 54 27 0 : slabdata 2 2 0
sysfs_dir_cache 2926 2940 64 60 1 : tunables 120 60 0 : slabdata 49 49 0
mnt_cache 20 24 160 24 1 : tunables 120 60 0 : slabdata 1 1 0
filp 96 120 160 24 1 : tunables 120 60 0 : slabdata 5 5 0
inode_cache 1563 1568 280 14 1 : tunables 54 27 0 : slabdata 112 112 0
dentry 2030 2030 136 29 1 : tunables 120 60 0 : slabdata 70 70 0
names_cache 1 1 4096 1 1 : tunables 24 12 0 : slabdata 1 1 0
buffer_head 0 0 56 68 1 : tunables 120 60 0 : slabdata 0 0 0
nsproxy 1 145 24 145 1 : tunables 120 60 0 : slabdata 1 1 0
vm_area_struct 215 396 88 44 1 : tunables 120 60 0 : slabdata 9 9 0
mm_struct 20 20 384 10 1 : tunables 54 27 0 : slabdata 2 2 0
fs_cache 11 113 32 113 1 : tunables 120 60 0 : slabdata 1 1 0
files_cache 11 40 192 20 1 : tunables 120 60 0 : slabdata 2 2 0
signal_cache 29 42 512 7 1 : tunables 54 27 0 : slabdata 6 6 0
sighand_cache 33 33 1312 3 1 : tunables 24 12 0 : slabdata 11 11 0
task_struct 29 42 672 6 1 : tunables 54 27 0 : slabdata 7 7 0
cred_jar 40 120 96 40 1 : tunables 120 60 0 : slabdata 3 3 0
anon_vma_chain 254 678 32 113 1 : tunables 120 60 0 : slabdata 6 6 0
anon_vma 193 435 24 145 1 : tunables 120 60 0 : slabdata 3 3 0
pid 33 60 64 60 1 : tunables 120 60 0 : slabdata 1 1 0
radix_tree_node 130 143 296 13 1 : tunables 54 27 0 : slabdata 11 11 0
idr_layer_cache 62 63 1080 7 2 : tunables 24 12 0 : slabdata 9 9 0
kmalloc-4194304 0 0 4194304 1 1024 : tunables 1 1 0 : slabdata 0 0 0
kmalloc-2097152 0 0 2097152 1 512 : tunables 1 1 0 : slabdata 0 0 0
kmalloc-1048576 0 0 1048576 1 256 : tunables 1 1 0 : slabdata 0 0 0
kmalloc-524288 0 0 524288 1 128 : tunables 1 1 0 : slabdata 0 0 0
kmalloc-262144 0 0 262144 1 64 : tunables 1 1 0 : slabdata 0 0 0
kmalloc-131072 0 0 131072 1 32 : tunables 8 4 0 : slabdata 0 0 0
kmalloc-65536 0 0 65536 1 16 : tunables 8 4 0 : slabdata 0 0 0
kmalloc-32768 2 2 32768 1 8 : tunables 8 4 0 : slabdata 2 2 0
kmalloc-16384 1 1 16384 1 4 : tunables 8 4 0 : slabdata 1 1 0
kmalloc-8192 2 2 8192 1 2 : tunables 8 4 0 : slabdata 2 2 0
kmalloc-4096 4 4 4096 1 1 : tunables 24 12 0 : slabdata 4 4 0
kmalloc-2048 28 28 2048 2 1 : tunables 24 12 0 : slabdata 14 14 0
kmalloc-1024 39 44 1024 4 1 : tunables 54 27 0 : slabdata 11 11 0
kmalloc-512 204 208 512 8 1 : tunables 54 27 0 : slabdata 26 26 0
kmalloc-256 183 195 256 15 1 : tunables 120 60 0 : slabdata 13 13 0
kmalloc-192 134 140 192 20 1 : tunables 120 60 0 : slabdata 7 7 0
kmalloc-128 204 210 128 30 1 : tunables 120 60 0 : slabdata 7 7 0
kmalloc-96 1099 1120 96 40 1 : tunables 120 60 0 : slabdata 28 28 0
kmalloc-64 648 720 64 60 1 : tunables 120 60 0 : slabdata 12 12 0
kmalloc-32 3018 3164 32 113 1 : tunables 120 60 0 : slabdata 28 28 0
kmem_cache 131 160 96 40 1 : tunables 120 60 0 : slabdata 4 4 0
[-- Attachment #3: with_8456a64.log --]
[-- Type: text/plain, Size: 14367 bytes --]
# cat /proc/slabinfo
slabinfo - version: 2.1
# name <active_objs> <num_objs> <objsize> <objperslab> <pagesperslab> : tunables <limit> <batchcount> <sharedfactor> : slabdata <active_sla>
ubi_wl_entry_slab 0 0 24 146 1 : tunables 120 60 0 : slabdata 0 0 0
ubifs_inode_slab 0 0 368 11 1 : tunables 54 27 0 : slabdata 0 0 0
fib6_nodes 1 113 32 113 1 : tunables 120 60 0 : slabdata 1 1 0
ip6_dst_cache 1 17 224 17 1 : tunables 120 60 0 : slabdata 1 1 0
PINGv6 0 0 704 11 2 : tunables 54 27 0 : slabdata 0 0 0
RAWv6 4 11 704 11 2 : tunables 54 27 0 : slabdata 1 1 0
UDPLITEv6 0 0 704 11 2 : tunables 54 27 0 : slabdata 0 0 0
UDPv6 0 0 704 11 2 : tunables 54 27 0 : slabdata 0 0 0
tw_sock_TCPv6 0 0 160 24 1 : tunables 120 60 0 : slabdata 0 0 0
request_sock_TCPv6 0 0 192 20 1 : tunables 120 60 0 : slabdata 0 0 0
TCPv6 0 0 1344 3 1 : tunables 24 12 0 : slabdata 0 0 0
sd_ext_cdb 2 113 32 113 1 : tunables 120 60 0 : slabdata 1 1 0
nfs_direct_cache 0 0 96 40 1 : tunables 120 60 0 : slabdata 0 0 0
nfs_commit_data 4 9 416 9 1 : tunables 54 27 0 : slabdata 1 1 0
nfs_write_data 32 36 608 6 1 : tunables 54 27 0 : slabdata 6 6 0
nfs_read_data 0 0 576 7 1 : tunables 54 27 0 : slabdata 0 0 0
nfs_inode_cache 0 0 536 7 1 : tunables 54 27 0 : slabdata 0 0 0
nfs_page 0 0 64 60 1 : tunables 120 60 0 : slabdata 0 0 0
fat_inode_cache 0 0 360 11 1 : tunables 54 27 0 : slabdata 0 0 0
fat_cache 0 0 24 146 1 : tunables 120 60 0 : slabdata 0 0 0
jbd2_transaction_s 0 0 160 24 1 : tunables 120 60 0 : slabdata 0 0 0
jbd2_inode 0 0 24 146 1 : tunables 120 60 0 : slabdata 0 0 0
jbd2_journal_handle 0 0 32 113 1 : tunables 120 60 0 : slabdata 0 0 0
jbd2_journal_head 0 0 64 60 1 : tunables 120 60 0 : slabdata 0 0 0
jbd2_revoke_table_s 0 0 16 204 1 : tunables 120 60 0 : slabdata 0 0 0
jbd2_revoke_record_s 0 0 32 113 1 : tunables 120 60 0 : slabdata 0 0 0
ext4_inode_cache 0 0 536 7 1 : tunables 54 27 0 : slabdata 0 0 0
ext4_xattr 0 0 48 78 1 : tunables 120 60 0 : slabdata 0 0 0
ext4_free_data 0 0 40 93 1 : tunables 120 60 0 : slabdata 0 0 0
ext4_allocation_context 0 0 112 35 1 : tunables 120 60 0 : slabdata 0 0 0
ext4_prealloc_space 0 0 64 60 1 : tunables 120 60 0 : slabdata 0 0 0
ext4_system_zone 0 0 32 113 1 : tunables 120 60 0 : slabdata 0 0 0
ext4_io_end 0 0 40 93 1 : tunables 120 60 0 : slabdata 0 0 0
ext4_extent_status 0 0 32 113 1 : tunables 120 60 0 : slabdata 0 0 0
configfs_dir_cache 1 68 56 68 1 : tunables 120 60 0 : slabdata 1 1 0
kioctx 0 0 192 20 1 : tunables 120 60 0 : slabdata 0 0 0
kiocb 0 0 64 60 1 : tunables 120 60 0 : slabdata 0 0 0
fanotify_response_event 0 0 16 204 1 : tunables 120 60 0 : slabdata 0 0 0
fsnotify_mark 0 0 64 60 1 : tunables 120 60 0 : slabdata 0 0 0
inotify_event_private_data 0 0 16 204 1 : tunables 120 60 0 : slabdata 0 0 0
inotify_inode_mark 12 60 64 60 1 : tunables 120 60 0 : slabdata 1 1 0
dnotify_mark 0 0 64 60 1 : tunables 120 60 0 : slabdata 0 0 0
dnotify_struct 0 0 24 146 1 : tunables 120 60 0 : slabdata 0 0 0
dio 0 0 328 12 1 : tunables 54 27 0 : slabdata 0 0 0
fasync_cache 0 0 24 146 1 : tunables 120 60 0 : slabdata 0 0 0
posix_timers_cache 0 0 152 26 1 : tunables 120 60 0 : slabdata 0 0 0
uid_cache 0 0 64 60 1 : tunables 120 60 0 : slabdata 0 0 0
rpc_inode_cache 0 0 320 12 1 : tunables 54 27 0 : slabdata 0 0 0
rpc_buffers 8 8 2048 2 1 : tunables 24 12 0 : slabdata 4 4 0
rpc_tasks 8 31 128 31 1 : tunables 120 60 0 : slabdata 1 1 0
UNIX 5 8 480 8 1 : tunables 54 27 0 : slabdata 1 1 0
UDP-Lite 0 0 608 6 1 : tunables 54 27 0 : slabdata 0 0 0
tcp_bind_bucket 0 0 32 113 1 : tunables 120 60 0 : slabdata 0 0 0
inet_peer_cache 0 0 128 31 1 : tunables 120 60 0 : slabdata 0 0 0
ip_fib_trie 3 113 32 113 1 : tunables 120 60 0 : slabdata 1 1 0
ip_fib_alias 4 146 24 146 1 : tunables 120 60 0 : slabdata 1 1 0
ip_dst_cache 0 0 128 31 1 : tunables 120 60 0 : slabdata 0 0 0
PING 0 0 576 7 1 : tunables 54 27 0 : slabdata 0 0 0
RAW 1 7 576 7 1 : tunables 54 27 0 : slabdata 1 1 0
UDP 0 0 608 6 1 : tunables 54 27 0 : slabdata 0 0 0
tw_sock_TCP 0 0 160 24 1 : tunables 120 60 0 : slabdata 0 0 0
request_sock_TCP 0 0 192 20 1 : tunables 120 60 0 : slabdata 0 0 0
TCP 0 0 1216 3 1 : tunables 24 12 0 : slabdata 0 0 0
eventpoll_pwq 9 93 40 93 1 : tunables 120 60 0 : slabdata 1 1 0
eventpoll_epi 9 80 96 40 1 : tunables 120 60 0 : slabdata 2 2 0
sgpool-128 2 2 2048 2 1 : tunables 24 12 0 : slabdata 1 1 0
sgpool-64 2 4 1024 4 1 : tunables 54 27 0 : slabdata 1 1 0
sgpool-32 2 8 512 8 1 : tunables 54 27 0 : slabdata 1 1 0
sgpool-16 2 15 256 15 1 : tunables 120 60 0 : slabdata 1 1 0
sgpool-8 2 31 128 31 1 : tunables 120 60 0 : slabdata 1 1 0
scsi_data_buffer 0 0 24 146 1 : tunables 120 60 0 : slabdata 0 0 0
blkdev_queue 14 14 1032 7 2 : tunables 24 12 0 : slabdata 2 2 0
blkdev_requests 8 18 216 18 1 : tunables 120 60 0 : slabdata 1 1 0
blkdev_ioc 0 0 64 60 1 : tunables 120 60 0 : slabdata 0 0 0
fsnotify_event_holder 0 0 16 204 1 : tunables 120 60 0 : slabdata 0 0 0
fsnotify_event 1 60 64 60 1 : tunables 120 60 0 : slabdata 1 1 0
bio-0 2 31 128 31 1 : tunables 120 60 0 : slabdata 1 1 0
biovec-256 2 2 3072 2 2 : tunables 24 12 0 : slabdata 1 1 0
biovec-128 0 0 1536 5 2 : tunables 24 12 0 : slabdata 0 0 0
biovec-64 0 0 768 5 1 : tunables 54 27 0 : slabdata 0 0 0
biovec-16 0 0 192 20 1 : tunables 120 60 0 : slabdata 0 0 0
sock_inode_cache 19 36 320 12 1 : tunables 54 27 0 : slabdata 3 3 0
skbuff_fclone_cache 0 0 352 11 1 : tunables 54 27 0 : slabdata 0 0 0
skbuff_head_cache 0 0 192 20 1 : tunables 120 60 0 : slabdata 0 0 0
file_lock_cache 0 0 112 35 1 : tunables 120 60 0 : slabdata 0 0 0
shmem_inode_cache 394 396 312 12 1 : tunables 54 27 0 : slabdata 33 33 0
pool_workqueue 6 15 256 15 1 : tunables 120 60 0 : slabdata 1 1 0
proc_inode_cache 12 12 312 12 1 : tunables 54 27 0 : slabdata 1 1 0
sigqueue 0 0 144 27 1 : tunables 120 60 0 : slabdata 0 0 0
bdev_cache 13 18 416 9 1 : tunables 54 27 0 : slabdata 2 2 0
sysfs_dir_cache 2926 2940 64 60 1 : tunables 120 60 0 : slabdata 49 49 0
mnt_cache 20 24 160 24 1 : tunables 120 60 0 : slabdata 1 1 0
filp 65 144 160 24 1 : tunables 120 60 0 : slabdata 6 6 0
inode_cache 1564 1568 280 14 1 : tunables 54 27 0 : slabdata 112 112 0
dentry 2001 2059 136 29 1 : tunables 120 60 0 : slabdata 71 71 0
names_cache 1 1 4096 1 1 : tunables 24 12 0 : slabdata 1 1 0
buffer_head 0 0 56 68 1 : tunables 120 60 0 : slabdata 0 0 0
nsproxy 1 146 24 146 1 : tunables 120 60 0 : slabdata 1 1 0
vm_area_struct 267 352 88 44 1 : tunables 120 60 0 : slabdata 8 8 0
mm_struct 20 20 384 10 1 : tunables 54 27 0 : slabdata 2 2 0
fs_cache 23 113 32 113 1 : tunables 120 60 0 : slabdata 1 1 0
files_cache 23 40 192 20 1 : tunables 120 60 0 : slabdata 2 2 0
signal_cache 42 42 512 7 1 : tunables 54 27 0 : slabdata 6 6 0
sighand_cache 33 33 1312 3 1 : tunables 24 12 0 : slabdata 11 11 0
task_struct 44 48 672 6 1 : tunables 54 27 0 : slabdata 8 8 0
cred_jar 53 80 96 40 1 : tunables 120 60 0 : slabdata 2 2 0
anon_vma_chain 304 791 32 113 1 : tunables 120 60 0 : slabdata 7 7 0
anon_vma 146 438 24 146 1 : tunables 120 60 0 : slabdata 3 3 0
pid 45 60 64 60 1 : tunables 120 60 0 : slabdata 1 1 0
radix_tree_node 131 143 296 13 1 : tunables 54 27 0 : slabdata 11 11 0
idr_layer_cache 62 63 1080 7 2 : tunables 24 12 0 : slabdata 9 9 0
kmalloc-4194304 0 0 4194304 1 1024 : tunables 1 1 0 : slabdata 0 0 0
kmalloc-2097152 0 0 2097152 1 512 : tunables 1 1 0 : slabdata 0 0 0
kmalloc-1048576 0 0 1048576 1 256 : tunables 1 1 0 : slabdata 0 0 0
kmalloc-524288 0 0 524288 1 128 : tunables 1 1 0 : slabdata 0 0 0
kmalloc-262144 0 0 262144 1 64 : tunables 1 1 0 : slabdata 0 0 0
kmalloc-131072 0 0 131072 1 32 : tunables 8 4 0 : slabdata 0 0 0
kmalloc-65536 0 0 65536 1 16 : tunables 8 4 0 : slabdata 0 0 0
kmalloc-32768 2 2 32768 1 8 : tunables 8 4 0 : slabdata 2 2 0
kmalloc-16384 1 1 16384 1 4 : tunables 8 4 0 : slabdata 1 1 0
kmalloc-8192 2 2 8192 1 2 : tunables 8 4 0 : slabdata 2 2 0
kmalloc-4096 4 4 4096 1 1 : tunables 24 12 0 : slabdata 4 4 0
kmalloc-2048 28 28 2048 2 1 : tunables 24 12 0 : slabdata 14 14 0
kmalloc-1024 38 40 1024 4 1 : tunables 54 27 0 : slabdata 10 10 0
kmalloc-512 203 208 512 8 1 : tunables 54 27 0 : slabdata 26 26 0
kmalloc-256 195 195 256 15 1 : tunables 120 60 0 : slabdata 13 13 0
kmalloc-192 140 140 192 20 1 : tunables 120 60 0 : slabdata 7 7 0
kmalloc-128 217 217 128 31 1 : tunables 120 60 0 : slabdata 7 7 0
kmalloc-96 1111 1120 96 40 1 : tunables 120 60 0 : slabdata 28 28 0
kmalloc-64 621 660 64 60 1 : tunables 120 60 0 : slabdata 11 11 0
kmalloc-32 3056 3164 32 113 1 : tunables 120 60 0 : slabdata 28 28 0
kmem_cache 131 160 96 40 1 : tunables 120 60 0 : slabdata 4 4 0
^ permalink raw reply [flat|nested] 45+ messages in thread
* possible regression on 3.13 when calling flush_dcache_page
@ 2014-01-03 14:54 ` Ludovic Desroches
0 siblings, 0 replies; 45+ messages in thread
From: Ludovic Desroches @ 2014-01-03 14:54 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
On Tue, Dec 24, 2013 at 03:38:37PM +0900, Joonsoo Kim wrote:
[...]
> > > > > > I think that this commit may not introduce a bug. This patch remove one
> > > > > > variable on slab management structure and replace variable name. So there
> > > > > > is no functional change.
You are right, the commit given by git bisect was not the good one...
Since I removed other patches done on top of it, I thought it really was
this one but in fact it is 8456a64.
dd0f774 Fri Jan 3 12:33:55 2014 +0100 Revert "slab: remove useless
statement for checking pfmemalloc" Ludovic Desroches
ff7487d Fri Jan 3 12:32:33 2014 +0100 Revert "slab: rename
slab_bufctl to slab_freelist" Ludovic Desroches
b963564 Fri Jan 3 12:32:13 2014 +0100 Revert "slab: fix to calm down
kmemleak warning" Ludovic Desroches
3fcfe50 Fri Jan 3 12:30:32 2014 +0100 Revert "slab: replace
non-existing 'struct freelist *' with 'void *'" Ludovic Desroches
750a795 Fri Jan 3 12:30:16 2014 +0100 Revert "memcg, kmem: rename
cache_from_memcg to cache_from_memcg_idx" Ludovic Desroches
7e2de8a Fri Jan 3 12:30:10 2014 +0100 mmc: atmel-mci: disable pdc
Ludovic Desroches
In this case I have the kernel oops. If I revert 8456a64 too, it
disappears.
I will try to test it on other devices because I couldn't reproduce it
with newer ones (but it's not the same ARM architecture so I would like
to see if it's also related to the device itself).
In attachment, there are the results of /proc/slabinfo before inserted the
sdio wifi module causing the oops.
Regards
Ludovic
-------------- next part --------------
# cat /proc/slabinfo
slabinfo - version: 2.1
# name <active_objs> <num_objs> <objsize> <objperslab> <pagesperslab> : tunables <limit> <batchcount> <sharedfactor> : slabdata <active_sla>
ubi_wl_entry_slab 0 0 24 145 1 : tunables 120 60 0 : slabdata 0 0 0
ubifs_inode_slab 0 0 368 10 1 : tunables 54 27 0 : slabdata 0 0 0
fib6_nodes 1 113 32 113 1 : tunables 120 60 0 : slabdata 1 1 0
ip6_dst_cache 1 17 224 17 1 : tunables 120 60 0 : slabdata 1 1 0
PINGv6 0 0 704 11 2 : tunables 54 27 0 : slabdata 0 0 0
RAWv6 4 11 704 11 2 : tunables 54 27 0 : slabdata 1 1 0
UDPLITEv6 0 0 704 11 2 : tunables 54 27 0 : slabdata 0 0 0
UDPv6 0 0 704 11 2 : tunables 54 27 0 : slabdata 0 0 0
tw_sock_TCPv6 0 0 160 24 1 : tunables 120 60 0 : slabdata 0 0 0
request_sock_TCPv6 0 0 192 20 1 : tunables 120 60 0 : slabdata 0 0 0
TCPv6 0 0 1344 3 1 : tunables 24 12 0 : slabdata 0 0 0
sd_ext_cdb 2 113 32 113 1 : tunables 120 60 0 : slabdata 1 1 0
nfs_direct_cache 0 0 96 40 1 : tunables 120 60 0 : slabdata 0 0 0
nfs_commit_data 4 9 416 9 1 : tunables 54 27 0 : slabdata 1 1 0
nfs_write_data 32 36 608 6 1 : tunables 54 27 0 : slabdata 6 6 0
nfs_read_data 0 0 576 7 1 : tunables 54 27 0 : slabdata 0 0 0
nfs_inode_cache 0 0 536 7 1 : tunables 54 27 0 : slabdata 0 0 0
nfs_page 0 0 64 60 1 : tunables 120 60 0 : slabdata 0 0 0
fat_inode_cache 0 0 360 11 1 : tunables 54 27 0 : slabdata 0 0 0
fat_cache 0 0 24 145 1 : tunables 120 60 0 : slabdata 0 0 0
jbd2_transaction_s 0 0 160 24 1 : tunables 120 60 0 : slabdata 0 0 0
jbd2_inode 0 0 24 145 1 : tunables 120 60 0 : slabdata 0 0 0
jbd2_journal_handle 0 0 32 113 1 : tunables 120 60 0 : slabdata 0 0 0
jbd2_journal_head 0 0 64 60 1 : tunables 120 60 0 : slabdata 0 0 0
jbd2_revoke_table_s 0 0 16 204 1 : tunables 120 60 0 : slabdata 0 0 0
jbd2_revoke_record_s 0 0 32 113 1 : tunables 120 60 0 : slabdata 0 0 0
ext4_inode_cache 0 0 536 7 1 : tunables 54 27 0 : slabdata 0 0 0
ext4_xattr 0 0 48 78 1 : tunables 120 60 0 : slabdata 0 0 0
ext4_free_data 0 0 40 92 1 : tunables 120 60 0 : slabdata 0 0 0
ext4_allocation_context 0 0 112 35 1 : tunables 120 60 0 : slabdata 0 0 0
ext4_prealloc_space 0 0 64 60 1 : tunables 120 60 0 : slabdata 0 0 0
ext4_system_zone 0 0 32 113 1 : tunables 120 60 0 : slabdata 0 0 0
ext4_io_end 0 0 40 92 1 : tunables 120 60 0 : slabdata 0 0 0
ext4_extent_status 0 0 32 113 1 : tunables 120 60 0 : slabdata 0 0 0
configfs_dir_cache 1 68 56 68 1 : tunables 120 60 0 : slabdata 1 1 0
kioctx 0 0 192 20 1 : tunables 120 60 0 : slabdata 0 0 0
kiocb 0 0 64 60 1 : tunables 120 60 0 : slabdata 0 0 0
fanotify_response_event 0 0 16 204 1 : tunables 120 60 0 : slabdata 0 0 0
fsnotify_mark 0 0 64 60 1 : tunables 120 60 0 : slabdata 0 0 0
inotify_event_private_data 0 0 16 204 1 : tunables 120 60 0 : slabdata 0 0 0
inotify_inode_mark 12 60 64 60 1 : tunables 120 60 0 : slabdata 1 1 0
dnotify_mark 0 0 64 60 1 : tunables 120 60 0 : slabdata 0 0 0
dnotify_struct 0 0 24 145 1 : tunables 120 60 0 : slabdata 0 0 0
dio 0 0 328 12 1 : tunables 54 27 0 : slabdata 0 0 0
fasync_cache 0 0 24 145 1 : tunables 120 60 0 : slabdata 0 0 0
posix_timers_cache 0 0 152 26 1 : tunables 120 60 0 : slabdata 0 0 0
uid_cache 0 0 64 60 1 : tunables 120 60 0 : slabdata 0 0 0
rpc_inode_cache 0 0 320 12 1 : tunables 54 27 0 : slabdata 0 0 0
rpc_buffers 8 8 2048 2 1 : tunables 24 12 0 : slabdata 4 4 0
rpc_tasks 8 30 128 30 1 : tunables 120 60 0 : slabdata 1 1 0
UNIX 5 8 480 8 1 : tunables 54 27 0 : slabdata 1 1 0
UDP-Lite 0 0 608 6 1 : tunables 54 27 0 : slabdata 0 0 0
tcp_bind_bucket 0 0 32 113 1 : tunables 120 60 0 : slabdata 0 0 0
inet_peer_cache 0 0 128 30 1 : tunables 120 60 0 : slabdata 0 0 0
ip_fib_trie 3 113 32 113 1 : tunables 120 60 0 : slabdata 1 1 0
ip_fib_alias 4 145 24 145 1 : tunables 120 60 0 : slabdata 1 1 0
ip_dst_cache 0 0 128 30 1 : tunables 120 60 0 : slabdata 0 0 0
PING 0 0 576 7 1 : tunables 54 27 0 : slabdata 0 0 0
RAW 1 7 576 7 1 : tunables 54 27 0 : slabdata 1 1 0
UDP 0 0 608 6 1 : tunables 54 27 0 : slabdata 0 0 0
tw_sock_TCP 0 0 160 24 1 : tunables 120 60 0 : slabdata 0 0 0
request_sock_TCP 0 0 192 20 1 : tunables 120 60 0 : slabdata 0 0 0
TCP 0 0 1216 3 1 : tunables 24 12 0 : slabdata 0 0 0
eventpoll_pwq 9 92 40 92 1 : tunables 120 60 0 : slabdata 1 1 0
eventpoll_epi 9 80 96 40 1 : tunables 120 60 0 : slabdata 2 2 0
sgpool-128 2 2 2048 2 1 : tunables 24 12 0 : slabdata 1 1 0
sgpool-64 2 4 1024 4 1 : tunables 54 27 0 : slabdata 1 1 0
sgpool-32 2 8 512 8 1 : tunables 54 27 0 : slabdata 1 random: nonblocking pool is initialized
1 0
sgpool-16 2 15 256 15 1 : tunables 120 60 0 : slabdata 1 1 0
sgpool-8 2 30 128 30 1 : tunables 120 60 0 : slabdata 1 1 0
scsi_data_buffer 0 0 24 145 1 : tunables 120 60 0 : slabdata 0 0 0
blkdev_queue 14 14 1032 7 2 : tunables 24 12 0 : slabdata 2 2 0
blkdev_requests 8 18 216 18 1 : tunables 120 60 0 : slabdata 1 1 0
blkdev_ioc 0 0 64 60 1 : tunables 120 60 0 : slabdata 0 0 0
fsnotify_event_holder 0 0 16 204 1 : tunables 120 60 0 : slabdata 0 0 0
fsnotify_event 1 60 64 60 1 : tunables 120 60 0 : slabdata 1 1 0
bio-0 2 30 128 30 1 : tunables 120 60 0 : slabdata 1 1 0
biovec-256 2 2 3072 2 2 : tunables 24 12 0 : slabdata 1 1 0
biovec-128 0 0 1536 5 2 : tunables 24 12 0 : slabdata 0 0 0
biovec-64 0 0 768 5 1 : tunables 54 27 0 : slabdata 0 0 0
biovec-16 0 0 192 20 1 : tunables 120 60 0 : slabdata 0 0 0
sock_inode_cache 21 36 320 12 1 : tunables 54 27 0 : slabdata 3 3 0
skbuff_fclone_cache 0 0 352 11 1 : tunables 54 27 0 : slabdata 0 0 0
skbuff_head_cache 4 20 192 20 1 : tunables 120 60 0 : slabdata 1 1 0
file_lock_cache 4 35 112 35 1 : tunables 120 60 0 : slabdata 1 1 0
shmem_inode_cache 394 396 312 12 1 : tunables 54 27 0 : slabdata 33 33 0
pool_workqueue 6 15 256 15 1 : tunables 120 60 0 : slabdata 1 1 0
proc_inode_cache 48 48 312 12 1 : tunables 54 27 0 : slabdata 4 4 0
sigqueue 0 0 144 27 1 : tunables 120 60 0 : slabdata 0 0 0
bdev_cache 13 18 416 9 1 : tunables 54 27 0 : slabdata 2 2 0
sysfs_dir_cache 2926 2940 64 60 1 : tunables 120 60 0 : slabdata 49 49 0
mnt_cache 20 24 160 24 1 : tunables 120 60 0 : slabdata 1 1 0
filp 96 120 160 24 1 : tunables 120 60 0 : slabdata 5 5 0
inode_cache 1563 1568 280 14 1 : tunables 54 27 0 : slabdata 112 112 0
dentry 2030 2030 136 29 1 : tunables 120 60 0 : slabdata 70 70 0
names_cache 1 1 4096 1 1 : tunables 24 12 0 : slabdata 1 1 0
buffer_head 0 0 56 68 1 : tunables 120 60 0 : slabdata 0 0 0
nsproxy 1 145 24 145 1 : tunables 120 60 0 : slabdata 1 1 0
vm_area_struct 215 396 88 44 1 : tunables 120 60 0 : slabdata 9 9 0
mm_struct 20 20 384 10 1 : tunables 54 27 0 : slabdata 2 2 0
fs_cache 11 113 32 113 1 : tunables 120 60 0 : slabdata 1 1 0
files_cache 11 40 192 20 1 : tunables 120 60 0 : slabdata 2 2 0
signal_cache 29 42 512 7 1 : tunables 54 27 0 : slabdata 6 6 0
sighand_cache 33 33 1312 3 1 : tunables 24 12 0 : slabdata 11 11 0
task_struct 29 42 672 6 1 : tunables 54 27 0 : slabdata 7 7 0
cred_jar 40 120 96 40 1 : tunables 120 60 0 : slabdata 3 3 0
anon_vma_chain 254 678 32 113 1 : tunables 120 60 0 : slabdata 6 6 0
anon_vma 193 435 24 145 1 : tunables 120 60 0 : slabdata 3 3 0
pid 33 60 64 60 1 : tunables 120 60 0 : slabdata 1 1 0
radix_tree_node 130 143 296 13 1 : tunables 54 27 0 : slabdata 11 11 0
idr_layer_cache 62 63 1080 7 2 : tunables 24 12 0 : slabdata 9 9 0
kmalloc-4194304 0 0 4194304 1 1024 : tunables 1 1 0 : slabdata 0 0 0
kmalloc-2097152 0 0 2097152 1 512 : tunables 1 1 0 : slabdata 0 0 0
kmalloc-1048576 0 0 1048576 1 256 : tunables 1 1 0 : slabdata 0 0 0
kmalloc-524288 0 0 524288 1 128 : tunables 1 1 0 : slabdata 0 0 0
kmalloc-262144 0 0 262144 1 64 : tunables 1 1 0 : slabdata 0 0 0
kmalloc-131072 0 0 131072 1 32 : tunables 8 4 0 : slabdata 0 0 0
kmalloc-65536 0 0 65536 1 16 : tunables 8 4 0 : slabdata 0 0 0
kmalloc-32768 2 2 32768 1 8 : tunables 8 4 0 : slabdata 2 2 0
kmalloc-16384 1 1 16384 1 4 : tunables 8 4 0 : slabdata 1 1 0
kmalloc-8192 2 2 8192 1 2 : tunables 8 4 0 : slabdata 2 2 0
kmalloc-4096 4 4 4096 1 1 : tunables 24 12 0 : slabdata 4 4 0
kmalloc-2048 28 28 2048 2 1 : tunables 24 12 0 : slabdata 14 14 0
kmalloc-1024 39 44 1024 4 1 : tunables 54 27 0 : slabdata 11 11 0
kmalloc-512 204 208 512 8 1 : tunables 54 27 0 : slabdata 26 26 0
kmalloc-256 183 195 256 15 1 : tunables 120 60 0 : slabdata 13 13 0
kmalloc-192 134 140 192 20 1 : tunables 120 60 0 : slabdata 7 7 0
kmalloc-128 204 210 128 30 1 : tunables 120 60 0 : slabdata 7 7 0
kmalloc-96 1099 1120 96 40 1 : tunables 120 60 0 : slabdata 28 28 0
kmalloc-64 648 720 64 60 1 : tunables 120 60 0 : slabdata 12 12 0
kmalloc-32 3018 3164 32 113 1 : tunables 120 60 0 : slabdata 28 28 0
kmem_cache 131 160 96 40 1 : tunables 120 60 0 : slabdata 4 4 0
-------------- next part --------------
# cat /proc/slabinfo
slabinfo - version: 2.1
# name <active_objs> <num_objs> <objsize> <objperslab> <pagesperslab> : tunables <limit> <batchcount> <sharedfactor> : slabdata <active_sla>
ubi_wl_entry_slab 0 0 24 146 1 : tunables 120 60 0 : slabdata 0 0 0
ubifs_inode_slab 0 0 368 11 1 : tunables 54 27 0 : slabdata 0 0 0
fib6_nodes 1 113 32 113 1 : tunables 120 60 0 : slabdata 1 1 0
ip6_dst_cache 1 17 224 17 1 : tunables 120 60 0 : slabdata 1 1 0
PINGv6 0 0 704 11 2 : tunables 54 27 0 : slabdata 0 0 0
RAWv6 4 11 704 11 2 : tunables 54 27 0 : slabdata 1 1 0
UDPLITEv6 0 0 704 11 2 : tunables 54 27 0 : slabdata 0 0 0
UDPv6 0 0 704 11 2 : tunables 54 27 0 : slabdata 0 0 0
tw_sock_TCPv6 0 0 160 24 1 : tunables 120 60 0 : slabdata 0 0 0
request_sock_TCPv6 0 0 192 20 1 : tunables 120 60 0 : slabdata 0 0 0
TCPv6 0 0 1344 3 1 : tunables 24 12 0 : slabdata 0 0 0
sd_ext_cdb 2 113 32 113 1 : tunables 120 60 0 : slabdata 1 1 0
nfs_direct_cache 0 0 96 40 1 : tunables 120 60 0 : slabdata 0 0 0
nfs_commit_data 4 9 416 9 1 : tunables 54 27 0 : slabdata 1 1 0
nfs_write_data 32 36 608 6 1 : tunables 54 27 0 : slabdata 6 6 0
nfs_read_data 0 0 576 7 1 : tunables 54 27 0 : slabdata 0 0 0
nfs_inode_cache 0 0 536 7 1 : tunables 54 27 0 : slabdata 0 0 0
nfs_page 0 0 64 60 1 : tunables 120 60 0 : slabdata 0 0 0
fat_inode_cache 0 0 360 11 1 : tunables 54 27 0 : slabdata 0 0 0
fat_cache 0 0 24 146 1 : tunables 120 60 0 : slabdata 0 0 0
jbd2_transaction_s 0 0 160 24 1 : tunables 120 60 0 : slabdata 0 0 0
jbd2_inode 0 0 24 146 1 : tunables 120 60 0 : slabdata 0 0 0
jbd2_journal_handle 0 0 32 113 1 : tunables 120 60 0 : slabdata 0 0 0
jbd2_journal_head 0 0 64 60 1 : tunables 120 60 0 : slabdata 0 0 0
jbd2_revoke_table_s 0 0 16 204 1 : tunables 120 60 0 : slabdata 0 0 0
jbd2_revoke_record_s 0 0 32 113 1 : tunables 120 60 0 : slabdata 0 0 0
ext4_inode_cache 0 0 536 7 1 : tunables 54 27 0 : slabdata 0 0 0
ext4_xattr 0 0 48 78 1 : tunables 120 60 0 : slabdata 0 0 0
ext4_free_data 0 0 40 93 1 : tunables 120 60 0 : slabdata 0 0 0
ext4_allocation_context 0 0 112 35 1 : tunables 120 60 0 : slabdata 0 0 0
ext4_prealloc_space 0 0 64 60 1 : tunables 120 60 0 : slabdata 0 0 0
ext4_system_zone 0 0 32 113 1 : tunables 120 60 0 : slabdata 0 0 0
ext4_io_end 0 0 40 93 1 : tunables 120 60 0 : slabdata 0 0 0
ext4_extent_status 0 0 32 113 1 : tunables 120 60 0 : slabdata 0 0 0
configfs_dir_cache 1 68 56 68 1 : tunables 120 60 0 : slabdata 1 1 0
kioctx 0 0 192 20 1 : tunables 120 60 0 : slabdata 0 0 0
kiocb 0 0 64 60 1 : tunables 120 60 0 : slabdata 0 0 0
fanotify_response_event 0 0 16 204 1 : tunables 120 60 0 : slabdata 0 0 0
fsnotify_mark 0 0 64 60 1 : tunables 120 60 0 : slabdata 0 0 0
inotify_event_private_data 0 0 16 204 1 : tunables 120 60 0 : slabdata 0 0 0
inotify_inode_mark 12 60 64 60 1 : tunables 120 60 0 : slabdata 1 1 0
dnotify_mark 0 0 64 60 1 : tunables 120 60 0 : slabdata 0 0 0
dnotify_struct 0 0 24 146 1 : tunables 120 60 0 : slabdata 0 0 0
dio 0 0 328 12 1 : tunables 54 27 0 : slabdata 0 0 0
fasync_cache 0 0 24 146 1 : tunables 120 60 0 : slabdata 0 0 0
posix_timers_cache 0 0 152 26 1 : tunables 120 60 0 : slabdata 0 0 0
uid_cache 0 0 64 60 1 : tunables 120 60 0 : slabdata 0 0 0
rpc_inode_cache 0 0 320 12 1 : tunables 54 27 0 : slabdata 0 0 0
rpc_buffers 8 8 2048 2 1 : tunables 24 12 0 : slabdata 4 4 0
rpc_tasks 8 31 128 31 1 : tunables 120 60 0 : slabdata 1 1 0
UNIX 5 8 480 8 1 : tunables 54 27 0 : slabdata 1 1 0
UDP-Lite 0 0 608 6 1 : tunables 54 27 0 : slabdata 0 0 0
tcp_bind_bucket 0 0 32 113 1 : tunables 120 60 0 : slabdata 0 0 0
inet_peer_cache 0 0 128 31 1 : tunables 120 60 0 : slabdata 0 0 0
ip_fib_trie 3 113 32 113 1 : tunables 120 60 0 : slabdata 1 1 0
ip_fib_alias 4 146 24 146 1 : tunables 120 60 0 : slabdata 1 1 0
ip_dst_cache 0 0 128 31 1 : tunables 120 60 0 : slabdata 0 0 0
PING 0 0 576 7 1 : tunables 54 27 0 : slabdata 0 0 0
RAW 1 7 576 7 1 : tunables 54 27 0 : slabdata 1 1 0
UDP 0 0 608 6 1 : tunables 54 27 0 : slabdata 0 0 0
tw_sock_TCP 0 0 160 24 1 : tunables 120 60 0 : slabdata 0 0 0
request_sock_TCP 0 0 192 20 1 : tunables 120 60 0 : slabdata 0 0 0
TCP 0 0 1216 3 1 : tunables 24 12 0 : slabdata 0 0 0
eventpoll_pwq 9 93 40 93 1 : tunables 120 60 0 : slabdata 1 1 0
eventpoll_epi 9 80 96 40 1 : tunables 120 60 0 : slabdata 2 2 0
sgpool-128 2 2 2048 2 1 : tunables 24 12 0 : slabdata 1 1 0
sgpool-64 2 4 1024 4 1 : tunables 54 27 0 : slabdata 1 1 0
sgpool-32 2 8 512 8 1 : tunables 54 27 0 : slabdata 1 1 0
sgpool-16 2 15 256 15 1 : tunables 120 60 0 : slabdata 1 1 0
sgpool-8 2 31 128 31 1 : tunables 120 60 0 : slabdata 1 1 0
scsi_data_buffer 0 0 24 146 1 : tunables 120 60 0 : slabdata 0 0 0
blkdev_queue 14 14 1032 7 2 : tunables 24 12 0 : slabdata 2 2 0
blkdev_requests 8 18 216 18 1 : tunables 120 60 0 : slabdata 1 1 0
blkdev_ioc 0 0 64 60 1 : tunables 120 60 0 : slabdata 0 0 0
fsnotify_event_holder 0 0 16 204 1 : tunables 120 60 0 : slabdata 0 0 0
fsnotify_event 1 60 64 60 1 : tunables 120 60 0 : slabdata 1 1 0
bio-0 2 31 128 31 1 : tunables 120 60 0 : slabdata 1 1 0
biovec-256 2 2 3072 2 2 : tunables 24 12 0 : slabdata 1 1 0
biovec-128 0 0 1536 5 2 : tunables 24 12 0 : slabdata 0 0 0
biovec-64 0 0 768 5 1 : tunables 54 27 0 : slabdata 0 0 0
biovec-16 0 0 192 20 1 : tunables 120 60 0 : slabdata 0 0 0
sock_inode_cache 19 36 320 12 1 : tunables 54 27 0 : slabdata 3 3 0
skbuff_fclone_cache 0 0 352 11 1 : tunables 54 27 0 : slabdata 0 0 0
skbuff_head_cache 0 0 192 20 1 : tunables 120 60 0 : slabdata 0 0 0
file_lock_cache 0 0 112 35 1 : tunables 120 60 0 : slabdata 0 0 0
shmem_inode_cache 394 396 312 12 1 : tunables 54 27 0 : slabdata 33 33 0
pool_workqueue 6 15 256 15 1 : tunables 120 60 0 : slabdata 1 1 0
proc_inode_cache 12 12 312 12 1 : tunables 54 27 0 : slabdata 1 1 0
sigqueue 0 0 144 27 1 : tunables 120 60 0 : slabdata 0 0 0
bdev_cache 13 18 416 9 1 : tunables 54 27 0 : slabdata 2 2 0
sysfs_dir_cache 2926 2940 64 60 1 : tunables 120 60 0 : slabdata 49 49 0
mnt_cache 20 24 160 24 1 : tunables 120 60 0 : slabdata 1 1 0
filp 65 144 160 24 1 : tunables 120 60 0 : slabdata 6 6 0
inode_cache 1564 1568 280 14 1 : tunables 54 27 0 : slabdata 112 112 0
dentry 2001 2059 136 29 1 : tunables 120 60 0 : slabdata 71 71 0
names_cache 1 1 4096 1 1 : tunables 24 12 0 : slabdata 1 1 0
buffer_head 0 0 56 68 1 : tunables 120 60 0 : slabdata 0 0 0
nsproxy 1 146 24 146 1 : tunables 120 60 0 : slabdata 1 1 0
vm_area_struct 267 352 88 44 1 : tunables 120 60 0 : slabdata 8 8 0
mm_struct 20 20 384 10 1 : tunables 54 27 0 : slabdata 2 2 0
fs_cache 23 113 32 113 1 : tunables 120 60 0 : slabdata 1 1 0
files_cache 23 40 192 20 1 : tunables 120 60 0 : slabdata 2 2 0
signal_cache 42 42 512 7 1 : tunables 54 27 0 : slabdata 6 6 0
sighand_cache 33 33 1312 3 1 : tunables 24 12 0 : slabdata 11 11 0
task_struct 44 48 672 6 1 : tunables 54 27 0 : slabdata 8 8 0
cred_jar 53 80 96 40 1 : tunables 120 60 0 : slabdata 2 2 0
anon_vma_chain 304 791 32 113 1 : tunables 120 60 0 : slabdata 7 7 0
anon_vma 146 438 24 146 1 : tunables 120 60 0 : slabdata 3 3 0
pid 45 60 64 60 1 : tunables 120 60 0 : slabdata 1 1 0
radix_tree_node 131 143 296 13 1 : tunables 54 27 0 : slabdata 11 11 0
idr_layer_cache 62 63 1080 7 2 : tunables 24 12 0 : slabdata 9 9 0
kmalloc-4194304 0 0 4194304 1 1024 : tunables 1 1 0 : slabdata 0 0 0
kmalloc-2097152 0 0 2097152 1 512 : tunables 1 1 0 : slabdata 0 0 0
kmalloc-1048576 0 0 1048576 1 256 : tunables 1 1 0 : slabdata 0 0 0
kmalloc-524288 0 0 524288 1 128 : tunables 1 1 0 : slabdata 0 0 0
kmalloc-262144 0 0 262144 1 64 : tunables 1 1 0 : slabdata 0 0 0
kmalloc-131072 0 0 131072 1 32 : tunables 8 4 0 : slabdata 0 0 0
kmalloc-65536 0 0 65536 1 16 : tunables 8 4 0 : slabdata 0 0 0
kmalloc-32768 2 2 32768 1 8 : tunables 8 4 0 : slabdata 2 2 0
kmalloc-16384 1 1 16384 1 4 : tunables 8 4 0 : slabdata 1 1 0
kmalloc-8192 2 2 8192 1 2 : tunables 8 4 0 : slabdata 2 2 0
kmalloc-4096 4 4 4096 1 1 : tunables 24 12 0 : slabdata 4 4 0
kmalloc-2048 28 28 2048 2 1 : tunables 24 12 0 : slabdata 14 14 0
kmalloc-1024 38 40 1024 4 1 : tunables 54 27 0 : slabdata 10 10 0
kmalloc-512 203 208 512 8 1 : tunables 54 27 0 : slabdata 26 26 0
kmalloc-256 195 195 256 15 1 : tunables 120 60 0 : slabdata 13 13 0
kmalloc-192 140 140 192 20 1 : tunables 120 60 0 : slabdata 7 7 0
kmalloc-128 217 217 128 31 1 : tunables 120 60 0 : slabdata 7 7 0
kmalloc-96 1111 1120 96 40 1 : tunables 120 60 0 : slabdata 28 28 0
kmalloc-64 621 660 64 60 1 : tunables 120 60 0 : slabdata 11 11 0
kmalloc-32 3056 3164 32 113 1 : tunables 120 60 0 : slabdata 28 28 0
kmem_cache 131 160 96 40 1 : tunables 120 60 0 : slabdata 4 4 0
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: possible regression on 3.13 when calling flush_dcache_page
2014-01-03 14:54 ` Ludovic Desroches
(?)
@ 2014-01-06 0:26 ` Joonsoo Kim
-1 siblings, 0 replies; 45+ messages in thread
From: Joonsoo Kim @ 2014-01-06 0:26 UTC (permalink / raw)
To: linux-mm, linux-kernel, linux-mmc, linux-arm-kernel
Cc: Christoph Lameter, Pekka Enberg
On Fri, Jan 03, 2014 at 03:54:04PM +0100, Ludovic Desroches wrote:
> Hi,
>
> On Tue, Dec 24, 2013 at 03:38:37PM +0900, Joonsoo Kim wrote:
>
> [...]
>
> > > > > > > I think that this commit may not introduce a bug. This patch remove one
> > > > > > > variable on slab management structure and replace variable name. So there
> > > > > > > is no functional change.
>
> You are right, the commit given by git bisect was not the good one...
> Since I removed other patches done on top of it, I thought it really was
> this one but in fact it is 8456a64.
Okay. It seems more reasonable to me.
I guess that this is the same issue with following link.
http://lkml.org/lkml/2014/1/4/81
And, perhaps, that patch solves your problem. But I'm not sure that it is the
best solution for this problem. I should discuss with slab maintainers.
I will think about this problem more deeply and report the solution to you
as soon as possible.
Thanks.
>
> dd0f774 Fri Jan 3 12:33:55 2014 +0100 Revert "slab: remove useless
> statement for checking pfmemalloc" Ludovic Desroches
> ff7487d Fri Jan 3 12:32:33 2014 +0100 Revert "slab: rename
> slab_bufctl to slab_freelist" Ludovic Desroches
> b963564 Fri Jan 3 12:32:13 2014 +0100 Revert "slab: fix to calm down
> kmemleak warning" Ludovic Desroches
> 3fcfe50 Fri Jan 3 12:30:32 2014 +0100 Revert "slab: replace
> non-existing 'struct freelist *' with 'void *'" Ludovic Desroches
> 750a795 Fri Jan 3 12:30:16 2014 +0100 Revert "memcg, kmem: rename
> cache_from_memcg to cache_from_memcg_idx" Ludovic Desroches
> 7e2de8a Fri Jan 3 12:30:10 2014 +0100 mmc: atmel-mci: disable pdc
> Ludovic Desroches
>
> In this case I have the kernel oops. If I revert 8456a64 too, it
> disappears.
>
> I will try to test it on other devices because I couldn't reproduce it
> with newer ones (but it's not the same ARM architecture so I would like
> to see if it's also related to the device itself).
>
> In attachment, there are the results of /proc/slabinfo before inserted the
> sdio wifi module causing the oops.
>
> Regards
>
> Ludovic
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: possible regression on 3.13 when calling flush_dcache_page
@ 2014-01-06 0:26 ` Joonsoo Kim
0 siblings, 0 replies; 45+ messages in thread
From: Joonsoo Kim @ 2014-01-06 0:26 UTC (permalink / raw)
To: linux-mm, linux-kernel, linux-mmc, linux-arm-kernel
Cc: Christoph Lameter, Pekka Enberg
On Fri, Jan 03, 2014 at 03:54:04PM +0100, Ludovic Desroches wrote:
> Hi,
>
> On Tue, Dec 24, 2013 at 03:38:37PM +0900, Joonsoo Kim wrote:
>
> [...]
>
> > > > > > > I think that this commit may not introduce a bug. This patch remove one
> > > > > > > variable on slab management structure and replace variable name. So there
> > > > > > > is no functional change.
>
> You are right, the commit given by git bisect was not the good one...
> Since I removed other patches done on top of it, I thought it really was
> this one but in fact it is 8456a64.
Okay. It seems more reasonable to me.
I guess that this is the same issue with following link.
http://lkml.org/lkml/2014/1/4/81
And, perhaps, that patch solves your problem. But I'm not sure that it is the
best solution for this problem. I should discuss with slab maintainers.
I will think about this problem more deeply and report the solution to you
as soon as possible.
Thanks.
>
> dd0f774 Fri Jan 3 12:33:55 2014 +0100 Revert "slab: remove useless
> statement for checking pfmemalloc" Ludovic Desroches
> ff7487d Fri Jan 3 12:32:33 2014 +0100 Revert "slab: rename
> slab_bufctl to slab_freelist" Ludovic Desroches
> b963564 Fri Jan 3 12:32:13 2014 +0100 Revert "slab: fix to calm down
> kmemleak warning" Ludovic Desroches
> 3fcfe50 Fri Jan 3 12:30:32 2014 +0100 Revert "slab: replace
> non-existing 'struct freelist *' with 'void *'" Ludovic Desroches
> 750a795 Fri Jan 3 12:30:16 2014 +0100 Revert "memcg, kmem: rename
> cache_from_memcg to cache_from_memcg_idx" Ludovic Desroches
> 7e2de8a Fri Jan 3 12:30:10 2014 +0100 mmc: atmel-mci: disable pdc
> Ludovic Desroches
>
> In this case I have the kernel oops. If I revert 8456a64 too, it
> disappears.
>
> I will try to test it on other devices because I couldn't reproduce it
> with newer ones (but it's not the same ARM architecture so I would like
> to see if it's also related to the device itself).
>
> In attachment, there are the results of /proc/slabinfo before inserted the
> sdio wifi module causing the oops.
>
> Regards
>
> Ludovic
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 45+ messages in thread
* possible regression on 3.13 when calling flush_dcache_page
@ 2014-01-06 0:26 ` Joonsoo Kim
0 siblings, 0 replies; 45+ messages in thread
From: Joonsoo Kim @ 2014-01-06 0:26 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, Jan 03, 2014 at 03:54:04PM +0100, Ludovic Desroches wrote:
> Hi,
>
> On Tue, Dec 24, 2013 at 03:38:37PM +0900, Joonsoo Kim wrote:
>
> [...]
>
> > > > > > > I think that this commit may not introduce a bug. This patch remove one
> > > > > > > variable on slab management structure and replace variable name. So there
> > > > > > > is no functional change.
>
> You are right, the commit given by git bisect was not the good one...
> Since I removed other patches done on top of it, I thought it really was
> this one but in fact it is 8456a64.
Okay. It seems more reasonable to me.
I guess that this is the same issue with following link.
http://lkml.org/lkml/2014/1/4/81
And, perhaps, that patch solves your problem. But I'm not sure that it is the
best solution for this problem. I should discuss with slab maintainers.
I will think about this problem more deeply and report the solution to you
as soon as possible.
Thanks.
>
> dd0f774 Fri Jan 3 12:33:55 2014 +0100 Revert "slab: remove useless
> statement for checking pfmemalloc" Ludovic Desroches
> ff7487d Fri Jan 3 12:32:33 2014 +0100 Revert "slab: rename
> slab_bufctl to slab_freelist" Ludovic Desroches
> b963564 Fri Jan 3 12:32:13 2014 +0100 Revert "slab: fix to calm down
> kmemleak warning" Ludovic Desroches
> 3fcfe50 Fri Jan 3 12:30:32 2014 +0100 Revert "slab: replace
> non-existing 'struct freelist *' with 'void *'" Ludovic Desroches
> 750a795 Fri Jan 3 12:30:16 2014 +0100 Revert "memcg, kmem: rename
> cache_from_memcg to cache_from_memcg_idx" Ludovic Desroches
> 7e2de8a Fri Jan 3 12:30:10 2014 +0100 mmc: atmel-mci: disable pdc
> Ludovic Desroches
>
> In this case I have the kernel oops. If I revert 8456a64 too, it
> disappears.
>
> I will try to test it on other devices because I couldn't reproduce it
> with newer ones (but it's not the same ARM architecture so I would like
> to see if it's also related to the device itself).
>
> In attachment, there are the results of /proc/slabinfo before inserted the
> sdio wifi module causing the oops.
>
> Regards
>
> Ludovic
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: possible regression on 3.13 when calling flush_dcache_page
2014-01-06 0:26 ` Joonsoo Kim
(?)
(?)
@ 2014-01-06 9:34 ` Ludovic Desroches
-1 siblings, 0 replies; 45+ messages in thread
From: Ludovic Desroches @ 2014-01-06 9:34 UTC (permalink / raw)
To: Joonsoo Kim
Cc: linux-mm, linux-kernel, linux-mmc, linux-arm-kernel,
Christoph Lameter, Pekka Enberg, Ludovic Desroches
On Mon, Jan 06, 2014 at 09:26:48AM +0900, Joonsoo Kim wrote:
> On Fri, Jan 03, 2014 at 03:54:04PM +0100, Ludovic Desroches wrote:
> > Hi,
> >
> > On Tue, Dec 24, 2013 at 03:38:37PM +0900, Joonsoo Kim wrote:
> >
> > [...]
> >
> > > > > > > > I think that this commit may not introduce a bug. This patch remove one
> > > > > > > > variable on slab management structure and replace variable name. So there
> > > > > > > > is no functional change.
> >
> > You are right, the commit given by git bisect was not the good one...
> > Since I removed other patches done on top of it, I thought it really was
> > this one but in fact it is 8456a64.
>
> Okay. It seems more reasonable to me.
> I guess that this is the same issue with following link.
> http://lkml.org/lkml/2014/1/4/81
>
> And, perhaps, that patch solves your problem. But I'm not sure that it is the
> best solution for this problem. I should discuss with slab maintainers.
Yes this patch solves my problem.
>
> I will think about this problem more deeply and report the solution to you
> as soon as possible.
Ok thanks.
>
> Thanks.
>
> >
> > dd0f774 Fri Jan 3 12:33:55 2014 +0100 Revert "slab: remove useless
> > statement for checking pfmemalloc" Ludovic Desroches
> > ff7487d Fri Jan 3 12:32:33 2014 +0100 Revert "slab: rename
> > slab_bufctl to slab_freelist" Ludovic Desroches
> > b963564 Fri Jan 3 12:32:13 2014 +0100 Revert "slab: fix to calm down
> > kmemleak warning" Ludovic Desroches
> > 3fcfe50 Fri Jan 3 12:30:32 2014 +0100 Revert "slab: replace
> > non-existing 'struct freelist *' with 'void *'" Ludovic Desroches
> > 750a795 Fri Jan 3 12:30:16 2014 +0100 Revert "memcg, kmem: rename
> > cache_from_memcg to cache_from_memcg_idx" Ludovic Desroches
> > 7e2de8a Fri Jan 3 12:30:10 2014 +0100 mmc: atmel-mci: disable pdc
> > Ludovic Desroches
> >
> > In this case I have the kernel oops. If I revert 8456a64 too, it
> > disappears.
> >
> > I will try to test it on other devices because I couldn't reproduce it
> > with newer ones (but it's not the same ARM architecture so I would like
> > to see if it's also related to the device itself).
> >
> > In attachment, there are the results of /proc/slabinfo before inserted the
> > sdio wifi module causing the oops.
> >
> > Regards
> >
> > Ludovic
>
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majordomo@kvack.org. For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: possible regression on 3.13 when calling flush_dcache_page
@ 2014-01-06 9:34 ` Ludovic Desroches
0 siblings, 0 replies; 45+ messages in thread
From: Ludovic Desroches @ 2014-01-06 9:34 UTC (permalink / raw)
To: Joonsoo Kim
Cc: linux-mm, linux-kernel, linux-mmc, linux-arm-kernel,
Christoph Lameter, Pekka Enberg, Ludovic Desroches
On Mon, Jan 06, 2014 at 09:26:48AM +0900, Joonsoo Kim wrote:
> On Fri, Jan 03, 2014 at 03:54:04PM +0100, Ludovic Desroches wrote:
> > Hi,
> >
> > On Tue, Dec 24, 2013 at 03:38:37PM +0900, Joonsoo Kim wrote:
> >
> > [...]
> >
> > > > > > > > I think that this commit may not introduce a bug. This patch remove one
> > > > > > > > variable on slab management structure and replace variable name. So there
> > > > > > > > is no functional change.
> >
> > You are right, the commit given by git bisect was not the good one...
> > Since I removed other patches done on top of it, I thought it really was
> > this one but in fact it is 8456a64.
>
> Okay. It seems more reasonable to me.
> I guess that this is the same issue with following link.
> http://lkml.org/lkml/2014/1/4/81
>
> And, perhaps, that patch solves your problem. But I'm not sure that it is the
> best solution for this problem. I should discuss with slab maintainers.
Yes this patch solves my problem.
>
> I will think about this problem more deeply and report the solution to you
> as soon as possible.
Ok thanks.
>
> Thanks.
>
> >
> > dd0f774 Fri Jan 3 12:33:55 2014 +0100 Revert "slab: remove useless
> > statement for checking pfmemalloc" Ludovic Desroches
> > ff7487d Fri Jan 3 12:32:33 2014 +0100 Revert "slab: rename
> > slab_bufctl to slab_freelist" Ludovic Desroches
> > b963564 Fri Jan 3 12:32:13 2014 +0100 Revert "slab: fix to calm down
> > kmemleak warning" Ludovic Desroches
> > 3fcfe50 Fri Jan 3 12:30:32 2014 +0100 Revert "slab: replace
> > non-existing 'struct freelist *' with 'void *'" Ludovic Desroches
> > 750a795 Fri Jan 3 12:30:16 2014 +0100 Revert "memcg, kmem: rename
> > cache_from_memcg to cache_from_memcg_idx" Ludovic Desroches
> > 7e2de8a Fri Jan 3 12:30:10 2014 +0100 mmc: atmel-mci: disable pdc
> > Ludovic Desroches
> >
> > In this case I have the kernel oops. If I revert 8456a64 too, it
> > disappears.
> >
> > I will try to test it on other devices because I couldn't reproduce it
> > with newer ones (but it's not the same ARM architecture so I would like
> > to see if it's also related to the device itself).
> >
> > In attachment, there are the results of /proc/slabinfo before inserted the
> > sdio wifi module causing the oops.
> >
> > Regards
> >
> > Ludovic
>
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majordomo@kvack.org. For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: possible regression on 3.13 when calling flush_dcache_page
@ 2014-01-06 9:34 ` Ludovic Desroches
0 siblings, 0 replies; 45+ messages in thread
From: Ludovic Desroches @ 2014-01-06 9:34 UTC (permalink / raw)
To: Joonsoo Kim
Cc: linux-mm, linux-kernel, linux-mmc, linux-arm-kernel,
Christoph Lameter, Pekka Enberg, Ludovic Desroches
On Mon, Jan 06, 2014 at 09:26:48AM +0900, Joonsoo Kim wrote:
> On Fri, Jan 03, 2014 at 03:54:04PM +0100, Ludovic Desroches wrote:
> > Hi,
> >
> > On Tue, Dec 24, 2013 at 03:38:37PM +0900, Joonsoo Kim wrote:
> >
> > [...]
> >
> > > > > > > > I think that this commit may not introduce a bug. This patch remove one
> > > > > > > > variable on slab management structure and replace variable name. So there
> > > > > > > > is no functional change.
> >
> > You are right, the commit given by git bisect was not the good one...
> > Since I removed other patches done on top of it, I thought it really was
> > this one but in fact it is 8456a64.
>
> Okay. It seems more reasonable to me.
> I guess that this is the same issue with following link.
> http://lkml.org/lkml/2014/1/4/81
>
> And, perhaps, that patch solves your problem. But I'm not sure that it is the
> best solution for this problem. I should discuss with slab maintainers.
Yes this patch solves my problem.
>
> I will think about this problem more deeply and report the solution to you
> as soon as possible.
Ok thanks.
>
> Thanks.
>
> >
> > dd0f774 Fri Jan 3 12:33:55 2014 +0100 Revert "slab: remove useless
> > statement for checking pfmemalloc" Ludovic Desroches
> > ff7487d Fri Jan 3 12:32:33 2014 +0100 Revert "slab: rename
> > slab_bufctl to slab_freelist" Ludovic Desroches
> > b963564 Fri Jan 3 12:32:13 2014 +0100 Revert "slab: fix to calm down
> > kmemleak warning" Ludovic Desroches
> > 3fcfe50 Fri Jan 3 12:30:32 2014 +0100 Revert "slab: replace
> > non-existing 'struct freelist *' with 'void *'" Ludovic Desroches
> > 750a795 Fri Jan 3 12:30:16 2014 +0100 Revert "memcg, kmem: rename
> > cache_from_memcg to cache_from_memcg_idx" Ludovic Desroches
> > 7e2de8a Fri Jan 3 12:30:10 2014 +0100 mmc: atmel-mci: disable pdc
> > Ludovic Desroches
> >
> > In this case I have the kernel oops. If I revert 8456a64 too, it
> > disappears.
> >
> > I will try to test it on other devices because I couldn't reproduce it
> > with newer ones (but it's not the same ARM architecture so I would like
> > to see if it's also related to the device itself).
> >
> > In attachment, there are the results of /proc/slabinfo before inserted the
> > sdio wifi module causing the oops.
> >
> > Regards
> >
> > Ludovic
>
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majordomo@kvack.org. For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 45+ messages in thread
* possible regression on 3.13 when calling flush_dcache_page
@ 2014-01-06 9:34 ` Ludovic Desroches
0 siblings, 0 replies; 45+ messages in thread
From: Ludovic Desroches @ 2014-01-06 9:34 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, Jan 06, 2014 at 09:26:48AM +0900, Joonsoo Kim wrote:
> On Fri, Jan 03, 2014 at 03:54:04PM +0100, Ludovic Desroches wrote:
> > Hi,
> >
> > On Tue, Dec 24, 2013 at 03:38:37PM +0900, Joonsoo Kim wrote:
> >
> > [...]
> >
> > > > > > > > I think that this commit may not introduce a bug. This patch remove one
> > > > > > > > variable on slab management structure and replace variable name. So there
> > > > > > > > is no functional change.
> >
> > You are right, the commit given by git bisect was not the good one...
> > Since I removed other patches done on top of it, I thought it really was
> > this one but in fact it is 8456a64.
>
> Okay. It seems more reasonable to me.
> I guess that this is the same issue with following link.
> http://lkml.org/lkml/2014/1/4/81
>
> And, perhaps, that patch solves your problem. But I'm not sure that it is the
> best solution for this problem. I should discuss with slab maintainers.
Yes this patch solves my problem.
>
> I will think about this problem more deeply and report the solution to you
> as soon as possible.
Ok thanks.
>
> Thanks.
>
> >
> > dd0f774 Fri Jan 3 12:33:55 2014 +0100 Revert "slab: remove useless
> > statement for checking pfmemalloc" Ludovic Desroches
> > ff7487d Fri Jan 3 12:32:33 2014 +0100 Revert "slab: rename
> > slab_bufctl to slab_freelist" Ludovic Desroches
> > b963564 Fri Jan 3 12:32:13 2014 +0100 Revert "slab: fix to calm down
> > kmemleak warning" Ludovic Desroches
> > 3fcfe50 Fri Jan 3 12:30:32 2014 +0100 Revert "slab: replace
> > non-existing 'struct freelist *' with 'void *'" Ludovic Desroches
> > 750a795 Fri Jan 3 12:30:16 2014 +0100 Revert "memcg, kmem: rename
> > cache_from_memcg to cache_from_memcg_idx" Ludovic Desroches
> > 7e2de8a Fri Jan 3 12:30:10 2014 +0100 mmc: atmel-mci: disable pdc
> > Ludovic Desroches
> >
> > In this case I have the kernel oops. If I revert 8456a64 too, it
> > disappears.
> >
> > I will try to test it on other devices because I couldn't reproduce it
> > with newer ones (but it's not the same ARM architecture so I would like
> > to see if it's also related to the device itself).
> >
> > In attachment, there are the results of /proc/slabinfo before inserted the
> > sdio wifi module causing the oops.
> >
> > Regards
> >
> > Ludovic
>
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majordomo at kvack.org. For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: <a href=mailto:"dont@kvack.org"> email at kvack.org </a>
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: possible regression on 3.13 when calling flush_dcache_page
2014-01-06 9:34 ` Ludovic Desroches
(?)
@ 2014-01-09 7:16 ` Joonsoo Kim
-1 siblings, 0 replies; 45+ messages in thread
From: Joonsoo Kim @ 2014-01-09 7:16 UTC (permalink / raw)
To: linux-mm, linux-kernel, linux-mmc, linux-arm-kernel,
Christoph Lameter, Pekka Enberg
On Mon, Jan 06, 2014 at 10:34:09AM +0100, Ludovic Desroches wrote:
> On Mon, Jan 06, 2014 at 09:26:48AM +0900, Joonsoo Kim wrote:
> > On Fri, Jan 03, 2014 at 03:54:04PM +0100, Ludovic Desroches wrote:
> > > Hi,
> > >
> > > On Tue, Dec 24, 2013 at 03:38:37PM +0900, Joonsoo Kim wrote:
> > >
> > > [...]
> > >
> > > > > > > > > I think that this commit may not introduce a bug. This patch remove one
> > > > > > > > > variable on slab management structure and replace variable name. So there
> > > > > > > > > is no functional change.
> > >
> > > You are right, the commit given by git bisect was not the good one...
> > > Since I removed other patches done on top of it, I thought it really was
> > > this one but in fact it is 8456a64.
> >
> > Okay. It seems more reasonable to me.
> > I guess that this is the same issue with following link.
> > http://lkml.org/lkml/2014/1/4/81
> >
> > And, perhaps, that patch solves your problem. But I'm not sure that it is the
> > best solution for this problem. I should discuss with slab maintainers.
>
> Yes this patch solves my problem.
>
> >
> > I will think about this problem more deeply and report the solution to you
> > as soon as possible.
>
> Ok thanks.
>
Hello,
That patch will be merged through Andrew's tree.
Use it to fix your problem :)
Thanks.
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: possible regression on 3.13 when calling flush_dcache_page
@ 2014-01-09 7:16 ` Joonsoo Kim
0 siblings, 0 replies; 45+ messages in thread
From: Joonsoo Kim @ 2014-01-09 7:16 UTC (permalink / raw)
To: linux-mm, linux-kernel, linux-mmc, linux-arm-kernel,
Christoph Lameter, Pekka Enberg
On Mon, Jan 06, 2014 at 10:34:09AM +0100, Ludovic Desroches wrote:
> On Mon, Jan 06, 2014 at 09:26:48AM +0900, Joonsoo Kim wrote:
> > On Fri, Jan 03, 2014 at 03:54:04PM +0100, Ludovic Desroches wrote:
> > > Hi,
> > >
> > > On Tue, Dec 24, 2013 at 03:38:37PM +0900, Joonsoo Kim wrote:
> > >
> > > [...]
> > >
> > > > > > > > > I think that this commit may not introduce a bug. This patch remove one
> > > > > > > > > variable on slab management structure and replace variable name. So there
> > > > > > > > > is no functional change.
> > >
> > > You are right, the commit given by git bisect was not the good one...
> > > Since I removed other patches done on top of it, I thought it really was
> > > this one but in fact it is 8456a64.
> >
> > Okay. It seems more reasonable to me.
> > I guess that this is the same issue with following link.
> > http://lkml.org/lkml/2014/1/4/81
> >
> > And, perhaps, that patch solves your problem. But I'm not sure that it is the
> > best solution for this problem. I should discuss with slab maintainers.
>
> Yes this patch solves my problem.
>
> >
> > I will think about this problem more deeply and report the solution to you
> > as soon as possible.
>
> Ok thanks.
>
Hello,
That patch will be merged through Andrew's tree.
Use it to fix your problem :)
Thanks.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 45+ messages in thread
* possible regression on 3.13 when calling flush_dcache_page
@ 2014-01-09 7:16 ` Joonsoo Kim
0 siblings, 0 replies; 45+ messages in thread
From: Joonsoo Kim @ 2014-01-09 7:16 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, Jan 06, 2014 at 10:34:09AM +0100, Ludovic Desroches wrote:
> On Mon, Jan 06, 2014 at 09:26:48AM +0900, Joonsoo Kim wrote:
> > On Fri, Jan 03, 2014 at 03:54:04PM +0100, Ludovic Desroches wrote:
> > > Hi,
> > >
> > > On Tue, Dec 24, 2013 at 03:38:37PM +0900, Joonsoo Kim wrote:
> > >
> > > [...]
> > >
> > > > > > > > > I think that this commit may not introduce a bug. This patch remove one
> > > > > > > > > variable on slab management structure and replace variable name. So there
> > > > > > > > > is no functional change.
> > >
> > > You are right, the commit given by git bisect was not the good one...
> > > Since I removed other patches done on top of it, I thought it really was
> > > this one but in fact it is 8456a64.
> >
> > Okay. It seems more reasonable to me.
> > I guess that this is the same issue with following link.
> > http://lkml.org/lkml/2014/1/4/81
> >
> > And, perhaps, that patch solves your problem. But I'm not sure that it is the
> > best solution for this problem. I should discuss with slab maintainers.
>
> Yes this patch solves my problem.
>
> >
> > I will think about this problem more deeply and report the solution to you
> > as soon as possible.
>
> Ok thanks.
>
Hello,
That patch will be merged through Andrew's tree.
Use it to fix your problem :)
Thanks.
^ permalink raw reply [flat|nested] 45+ messages in thread
end of thread, other threads:[~2014-01-09 7:16 UTC | newest]
Thread overview: 45+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-12-12 14:31 possible regression on 3.13 when calling flush_dcache_page Ludovic Desroches
2013-12-12 14:31 ` Ludovic Desroches
2013-12-12 14:31 ` Ludovic Desroches
2013-12-12 14:36 ` Ludovic Desroches
2013-12-12 14:36 ` Ludovic Desroches
2013-12-12 14:36 ` Ludovic Desroches
2013-12-12 14:36 ` Ludovic Desroches
2013-12-13 1:59 ` Joonsoo Kim
2013-12-13 1:59 ` Joonsoo Kim
2013-12-13 1:59 ` Joonsoo Kim
2013-12-16 14:43 ` Ludovic Desroches
2013-12-16 14:43 ` Ludovic Desroches
2013-12-16 14:43 ` Ludovic Desroches
2013-12-18 7:21 ` Joonsoo Kim
2013-12-18 7:21 ` Joonsoo Kim
2013-12-18 7:21 ` Joonsoo Kim
2013-12-20 8:08 ` Ludovic Desroches
2013-12-20 8:08 ` Ludovic Desroches
2013-12-20 8:08 ` Ludovic Desroches
2013-12-20 8:08 ` Ludovic Desroches
2013-12-23 22:44 ` Ludovic Desroches
2013-12-23 22:44 ` Ludovic Desroches
2013-12-23 22:44 ` Ludovic Desroches
2013-12-24 6:38 ` Joonsoo Kim
2013-12-24 6:38 ` Joonsoo Kim
2013-12-24 6:38 ` Joonsoo Kim
2014-01-03 14:54 ` Ludovic Desroches
2014-01-03 14:54 ` Ludovic Desroches
2014-01-03 14:54 ` Ludovic Desroches
2014-01-06 0:26 ` Joonsoo Kim
2014-01-06 0:26 ` Joonsoo Kim
2014-01-06 0:26 ` Joonsoo Kim
2014-01-06 9:34 ` Ludovic Desroches
2014-01-06 9:34 ` Ludovic Desroches
2014-01-06 9:34 ` Ludovic Desroches
2014-01-06 9:34 ` Ludovic Desroches
2014-01-09 7:16 ` Joonsoo Kim
2014-01-09 7:16 ` Joonsoo Kim
2014-01-09 7:16 ` Joonsoo Kim
2013-12-12 17:13 ` Russell King - ARM Linux
2013-12-12 17:13 ` Russell King - ARM Linux
2013-12-12 17:13 ` Russell King - ARM Linux
2013-12-16 10:49 ` Ludovic Desroches
2013-12-16 10:49 ` Ludovic Desroches
2013-12-16 10:49 ` Ludovic Desroches
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.