linux-kernel - Re: [PATCH 2/3] work_on_cpu: Use our own workqueue.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 2 Feb 2009 20:06:49 -0800
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Rusty Russell <rusty@...tcorp.com.au>
Cc:	travis@....com, mingo@...hat.com, davej@...hat.com,
	cpufreq@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/3] work_on_cpu: Use our own workqueue.

On Mon, 2 Feb 2009 23:05:50 +1030 Rusty Russell <rusty@...tcorp.com.au> wrote:

> +/**
> + * __work_on_cpu - run a function in a workqueue on a particular cpu
> + * @swq: the (singlethreaded) workqueue
> + * @cpu: the cpu to run on
> + * @fn: the function to run
> + * @arg: the function arg
> + *
> + * This will return the value @fn returns.
> + * It is up to the caller to ensure that the cpu doesn't go offline.
> + *
> + * Example:
> + *	int ret;
> + *	struct workqueue_struct *wq = create_singlethread_workqueue("myq");
> + *	if (unlikely(!wq))
> + *		ret = -ENOMEM;
> + *	else {
> + *		ret = __work_on_cpu(wq, cpu, fn, arg);
> + *		destroy_workqueue(wq);
> + *	}
> + */
> +long __work_on_cpu(struct workqueue_struct *swq,
> +		   unsigned int cpu, long (*fn)(void *), void *arg)
> +{
> +	struct work_for_cpu wfc;
> +
> +	INIT_WORK(&wfc.work, do_work_for_cpu);
> +	wfc.fn = fn;
> +	wfc.arg = arg;
> +	wfc.cpu = cpu;
> +	BUG_ON(!swq->singlethread);
> +	queue_work(swq, &wfc.work);
> +	flush_work(&wfc.work);
> +
> +	return wfc.ret;
> +}
> +EXPORT_SYMBOL_GPL(__work_on_cpu);

If we're going to do this then we might as well create the thread right
here, use it once and then let it exit.

That's slower, but I suspect that we could get a lot of that inefficiency
back by coming up with a kernel_thread_on_cpu(), so we don't go and schedule
the function on a random CPU only to immediately switch it over to a different
one, dunno.

But as you say, rdmsr_on_cpu() is easy to do, using
smp_call_function_single().  Then we can easily convert all other
work_on_cpu() callers to smp_call_function_single() and zap
work_on_cpu().  The best outcome, methinks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/