On 2 June 2017 at 07:08, zhong jiang <zhongjiang@xxxxxxxxxx> wrote: > Hi, Ard > > Thank you for reply. > On 2017/6/2 1:40, Ard Biesheuvel wrote: >> Hi all, >> >> On 1 June 2017 at 13:26, zhongjiang <zhongjiang@xxxxxxxxxx> wrote: >>> Recently, xiaojun report the following issue. >>> >>> [ 4544.984139] Unable to handle kernel paging request at virtual address ffff804392800000 >> This is not a vmalloc address ^^^ > The mappings is not at a page granularity. but kernel image maaping use sections. > and this try a bogus walk to the pte level. so it will acess a abnormal address, > not in a vmalloc range. Ah ok. It looks like you are crashing in __memcpy(), but it is actually the __memcpy() call inside vread(), not the one in read_kcore(). I missed that. >> [...] >>> I find the issue is introduced when applying commit f9040773b7bb >>> ("arm64: move kernel image to base of vmalloc area"). This patch >>> make the kernel image overlap with vmalloc area. It will result in >>> vmalloc area have the huge page table. but the vmalloc_to_page is >>> not realize the change. and the function is public to any arch. >>> >>> I fix it by adding the another kernel image condition in vmalloc_to_page >>> to make it keep the accordance with previous vmalloc mapping. >>> >> ... so while I agree that there is probably an issue to be solved >> here, I don't see how this patch fixes the problem. This particular >> crash may be caused by an assumption on the part of the kcore code >> that there are no holes in the linear region. >> >>> Fixes: f9040773b7bb ("arm64: move kernel image to base of vmalloc area") >>> Reported-by: tan xiaojun <tanxiaojun@xxxxxxxxxx> >>> Reviewed-by: Laura Abbott <labbott@xxxxxxxxxx> >>> Signed-off-by: zhongjiang <zhongjiang@xxxxxxxxxx> >> So while I think we all agree that the kcore code is likely to get >> confused due to the overlap between vmlinux and the vmalloc region, I >> would like to better understand how it breaks things, and whether we'd >> be better off simply teaching vread/vwrite how to interpret block >> mappings. > I think the root reason is clear. and I test the patch, after applying the patch, > the issue will go away. >> Could you check whether CONFIG_DEBUG_PAGEALLOC makes the issue go away >> (once you have really managed to reproduce it?) > Today, I enable the config and test it in newest kernel version. the issue still exist. > > [ 396.495450] [<ffff00000839c400>] __memcpy+0x100/0x180 > [ 396.501056] [<ffff00000826ae14>] read_kcore+0x21c/0x3a0 > [ 396.506729] [<ffff00000825d37c>] proc_reg_read+0x64/0x90 > [ 396.512706] [<ffff0000081f668c>] __vfs_read+0x1c/0xf8 > [ 396.518188] [<ffff0000081f792c>] vfs_read+0x84/0x140 > [ 396.523653] [<ffff0000081f8df4>] SyS_read+0x44/0xa0 > [ 396.529205] [<ffff000008082f30>] el0_svc_naked+0x24/0x28 > [ 396.535036] Code: d503201f d503201f d503201f d503201f (a8c12027) > Yeah, another bit of useless advice, sorry. DEBUG_PAGEALLOC does not affect the granularity of the vmlinux segment mappings anymore. Anyway, given that the vmalloc routines already contain partial support for block mappings (i.e., vunmap() supports them), I think it is reasonable to add support for them in vmalloc() as well. I will send out a patch shortly, could you please try it? -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx"> email@xxxxxxxxx </a>