On Mon, May 27, 2019 at 09:20:01AM +0200, Michal Hocko wrote:

On Wed 22-05-19 17:42:13, Mark Rutland wrote:

quoted

On Thu, May 16, 2019 at 01:05:29PM +0200, Michal Hocko wrote:

quoted

On Thu 16-05-19 11:23:54, Mark Rutland wrote:

quoted

On Wed, May 15, 2019 at 06:58:47PM +0200, Michal Hocko wrote:

quoted

On Tue 14-05-19 14:30:05, Anshuman Khandual wrote:

quoted

I don't think that it's reasonable for this code to bring down the
kernel unless the kernel page tables are already corrupt. I agree we
should minimize the impact on other code, and I'm happy to penalize
ptdump so long as it's functional and safe.

I would like it to be possible to use the ptdump code to debug
hot-remove, so I'd rather not make the two mutually exclusive. I'd also
like it to be possible to use this in-the-field, and for that asking an
admin to potentially crash their system isn't likely to fly.

OK, fair enough.

quoted

quoted

quoted

quoted

I am asking because I would really love to make mem hotplug locking less
scattered outside of the core MM than more. Most users simply shouldn't
care. Pfn walkers should rely on pfn_to_online_page.

Jut to check, is your plan to limit access to the hotplug lock, or to
redesign the locking scheme?

To change the locking to lock hotpluged ranges rather than having a
global lock as the operation is inherently pfn range scoped.

Ok. That sounds like something we could adapt the ptdump code to handle
without too much pain (modulo how much of that you want to expose
outside of the core mm code).

quoted

quoted

quoted

I'm not sure if that would help us here; IIUC pfn_to_online_page() alone
doesn't ensure that the page remains online. Is there a way to achieve
that other than get_online_mems()?

You have to pin the page to make sure the hotplug is not going to
offline it.

I'm not exactly sure how pinning works -- is there a particular set of
functions I should look at for that?

Pinning (get_page) on any page of the range will deffer the hotremove
operation and therefore the page tables cannot go away as well.

That being said, I thought the API is mostly for debugging and "you
should better know what you are doing" kinda thing (based on debugfs
being used here). If this is really useful in its current form and
should be used also while the hotremove is in progress then ok.
Once we actually get to rework the locking then we will have another
spot to handle but that's the life.

Great.

FWIW, I'm happy to rework the ptdump code to help with that.

Thanks,
Mark.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel