Re: [RFC v2 13/13] keys/mktme: Support CPU Hotplug for MKTME keys
From: Alison Schofield <alison.schofield@intel.com>
Date: 2018-12-05 05:33:42
Also in:
keyrings, linux-mm
From: Alison Schofield <alison.schofield@intel.com>
Date: 2018-12-05 05:33:42
Also in:
keyrings, linux-mm
On Tue, Dec 04, 2018 at 10:31:16AM +0100, Peter Zijlstra wrote:
On Mon, Dec 03, 2018 at 11:40:00PM -0800, Alison Schofield wrote:quoted
static int mktme_program_system(struct mktme_key_program *key_program, - cpumask_var_t mktme_cpumask) + cpumask_var_t mktme_cpumask, int hotplug) { struct mktme_hw_program_info info = { .key_program = key_program, .status = MKTME_PROG_SUCCESS, }; - get_online_cpus(); - on_each_cpu_mask(mktme_cpumask, mktme_program_package, &info, 1); - put_online_cpus(); + + if (!hotplug) { + get_online_cpus(); + on_each_cpu_mask(mktme_cpumask, mktme_program_package, + &info, 1); + put_online_cpus(); + } else { + on_each_cpu_mask(mktme_cpumask, mktme_program_package, + &info, 1); + } return info.status; }That is pretty horrible; and I think easily avoided.
Agree it's ugly. Not sure we share the same reasoning. I realize that the hotplug case is on the current cpu and so that whole one_each_cpu_mask() call is not needed. mktme_program_package() can just be called on the current cpu. The ugliness that haunts me is that I wanted to reuse this code path, and so I passed that 'hotplug' parameter along as a differentiator between hotplug & 'typical' key programming. I'll rework this.