On Wed, Oct 26, 2016 at 5:51 AM, Andreas Gruenbacher <agrue...@redhat.com> wrote: > Hi, > > CONFIG_VMAP_STACK has broken gfs2 and I'm trying to figure out what's > going on. What I'm seeing is the following: on a fresh gfs2 filesystem > created with: > > mkfs.gfs2 -p lock_nolock $DEVICE > > I get the following BUG with 4.9-rc2, CONFIG_VMAP_STACK and > CONFIG_DEBUG_VIRTUAL turned on: > > kernel BUG at arch/x86/mm/physaddr.c:26! > > Stack of kernel thread: > > __phys_addr(x) > bit_waitqueue(word, bit) > wake_up_bit(word = &gh->gh_iflags, bit = HIF_WAIT) > gfs2_holder_wake(gh)
It's this: const struct zone *zone = page_zone(virt_to_page(word)); If the stack is vmalloced, then you can't find the page's zone like that. We could look it up the slow way (ick!), but maybe another solution would be to do: wait_queue_head_t *wait_table; if (virt_addr_valid(word)) wait_table = page_zone(virt_to_page(word))->wait_table; else wait_table = funny_wait_table; where funny_wait_table is an extra wait table just for funny addresses. This will scale poorly on very large NUMA systems where many zones are simultaneously using on-stack wait_bit bits, but I suspect this is a very rare use case. > > Is accessing a struct on another kernel thread's stack no longer working? That part should be fine.
