First looking at the following patch (forwarded from Kernel-testers): From: KAMEZAWA Hiroyuki <kamezawa.hiroyu@xxxxxxxxxxxxxx> Subject: Re: [Bad page] trying to free locked page? (Re: [PATCH][RFC] fix kernel BUG at mm/migrate.c:719! in 2.6.26-rc5-mm3) > > I got bad_page after hundreds times of page migration. > It seems that a locked page is being freed. > Good catch, and I think your investigation in the last e-mail was correct. I'd like to dig this...but it seems some kind of big fix is necessary. Did this happen under page-migraion by cpuset-task-move test ? > > Call Trace: > [<ffffffff802747b0>] bad_page+0x97/0x131 > [<ffffffff80275ae6>] free_hot_cold_page+0xd4/0x19c > [<ffffffff8027a5c3>] putback_lru_page+0xf4/0xfb > [<ffffffff8029b210>] putback_lru_pages+0x46/0x74 > [<ffffffff8029bc5b>] migrate_pages+0x3f4/0x468 > [<ffffffff80290797>] new_node_page+0x0/0x2f > [<ffffffff80291631>] do_migrate_pages+0x19b/0x1e7 > [<ffffffff8025c827>] cpuset_migrate_mm+0x58/0x8f > [<ffffffff8025d0fd>] cpuset_attach+0x8b/0x9e > [<ffffffff8032ffdc>] sscanf+0x49/0x51 > [<ffffffff8025a3e1>] cgroup_attach_task+0x3a3/0x3f5 > [<ffffffff80489a90>] __mutex_lock_slowpath+0x64/0x93 > [<ffffffff8025af06>] cgroup_common_file_write+0x150/0x1dd > [<ffffffff8025aaf4>] cgroup_file_write+0x54/0x150 > [<ffffffff8029f855>] vfs_write+0xad/0x136 > [<ffffffff8029fd92>] sys_write+0x45/0x6e > [<ffffffff8020bef2>] tracesys+0xd5/0xda > I am interested in this: why do u do page migration? who triggered memory migration? why? how large is the memory and any size in in pattern? -- Regards, Peter Teoh -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx Please read the FAQ at http://kernelnewbies.org/FAQ
