| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <q2t28c262361004020022v8eda0491t61e510a1caa0ef@mail.gmail.com> Date: Fri, 2 Apr 2010 16:22:56 +0900 From: Minchan Kim <minchan.kim@...il.com> To: TAO HU <tghk48@...orola.com> Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>, TAO HU <taohu@...orola.com>, linux-mm@...ck.org, linux-kernel@...r.kernel.org, "Ye Yuan.Bo-A22116" <yuan-bo.ye@...orola.com>, Chang Qing-A21550 <Qing.Chang@...orola.com>, linux-arm-kernel@...ts.infradead.org Subject: Re: [Question] race condition in mm/page_alloc.c regarding page->lru? On Fri, Apr 2, 2010 at 4:00 PM, TAO HU <tghk48@...orola.com> wrote: > Hi, kamezawa hiroyu > > Thanks for the hint! > > Hi, Minchan Kim > > Sorry. Not exactly sure your idea about <grep "page handling">. > Below is a result of $ grep -n -r "list_del(&page->lru)" * in our src tree It's not enough. Maybe you have to review your's patches based on mainline. > > arch/s390/mm/pgtable.c:83: list_del(&page->lru); > arch/s390/mm/pgtable.c:226: list_del(&page->lru); > arch/x86/mm/pgtable.c:60: list_del(&page->lru); > drivers/xen/balloon.c:154: list_del(&page->lru); > drivers/virtio/virtio_balloon.c:143: list_del(&page->lru); > fs/cifs/file.c:1780: list_del(&page->lru); > fs/btrfs/extent_io.c:2584: list_del(&page->lru); > fs/mpage.c:388: list_del(&page->lru); > include/linux/mm_inline.h:37: list_del(&page->lru); > include/linux/mm_inline.h:47: list_del(&page->lru); > kernel/kexec.c:391: list_del(&page->lru); > kernel/kexec.c:711: list_del(&page->lru); > mm/migrate.c:69: list_del(&page->lru); > mm/migrate.c:695: list_del(&page->lru); > mm/hugetlb.c:467: list_del(&page->lru); > mm/hugetlb.c:509: list_del(&page->lru); > mm/hugetlb.c:836: list_del(&page->lru); > mm/hugetlb.c:844: list_del(&page->lru); > mm/hugetlb.c:900: list_del(&page->lru); > mm/hugetlb.c:1130: list_del(&page->lru); > mm/hugetlb.c:1809: list_del(&page->lru); > mm/vmscan.c:597: list_del(&page->lru); > mm/vmscan.c:1148: list_del(&page->lru); > mm/vmscan.c:1246: list_del(&page->lru); > mm/slub.c:827: list_del(&page->lru); > mm/slub.c:1249: list_del(&page->lru); > mm/slub.c:1263: list_del(&page->lru); > mm/slub.c:2419: list_del(&page->lru); > mm/slub.c:2809: list_del(&page->lru); > mm/readahead.c:65: list_del(&page->lru); > mm/readahead.c:100: list_del(&page->lru); > mm/page_alloc.c:532: list_del(&page->lru); > mm/page_alloc.c:679: list_del(&page->lru); > mm/page_alloc.c:741: list_del(&page->lru); > mm/page_alloc.c:820: list_del(&page->lru); > mm/page_alloc.c:1107: list_del(&page->lru); > mm/page_alloc.c:4784: list_del(&page->lru); > There are normal caller. I expected some bogus driver of out-of-mainline uses page directly without enough review. Is your kernel working well except this bug? Do you see same oops call trace(about page-allocator) whenever kernel panic happens? I mean if something not page-allocadtor breaks memory, you can see other symptoms. so we can doubt others(H/W, other subsystem). -- Kind regards, Minchan Kim -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists