----- Original Message ----- > > > ----- Original Message ----- > > > > This would seem to be a little extreme. If by chance CONFIG_SPARSEMEM > > > is not configured, or for that matter, in old pre-sparsemem kernels, > > > "mem_section" doesn't even exist as a symbol. So there should be an > > > IS_SPARSEMEM() qualifier to prevent the FATAL session-ending > > > error. > > > > > > I'm waiting for an s390x reservation as we speak, and I'll change > > > (and test) the patch to do something like: > > > > > > if (IS_SPARSEMEM() && > > > !set_s390x_max_physmem_bits()) > > > error(FATAL, ... > > > > Actually that won't suffice, because the POST_GDB init call is done > > before vm_init(). I'll add a new POST_VM case label to the s390x_init() > > switch statement, and move the set_s390x_max_physmem_bits() call > > there. > > ... which won't work either, because vm_init() calls sparse_mem_init() > which needs the MAX_PHYSMEM_BITS to be already set. > > I guess we'll have to check for the existence of the mem_section array > and preemptively/redundantly make the STRUCT_SIZE_INIT() call in your > function so that we can still do it all POST_GDB. And complicating matters even further, your patch presumes that the kernel has configured CONFIG_SPARSEMEM_EXTREME in conjunction with CONFIG_SPARSEMEM. Would it be possible for an s390x to be configured with just CONFIG_SPARSEMEM alone? If so, your patch breaks down. Or is there another way you can determine which MAX_PHYSMEM_BITS value is in use? Dave -- Crash-utility mailing list Crash-utility@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/crash-utility
