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  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:	Fri, 25 Jul 2014 09:08:00 +0200
From:	Peter Zijlstra <peterz@...radead.org>
To:	Tim Chen <tim.c.chen@...ux.intel.com>
Cc:	Herbert Xu <herbert@...dor.apana.org.au>,
	"H. Peter Anvin" <hpa@...or.com>,
	"David S.Miller" <davem@...emloft.net>,
	Ingo Molnar <mingo@...nel.org>,
	Chandramouli Narayanan <mouli@...ux.intel.com>,
	Vinodh Gopal <vinodh.gopal@...el.com>,
	James Guilford <james.guilford@...el.com>,
	Wajdi Feghali <wajdi.k.feghali@...el.com>,
	Jussi Kivilinna <jussi.kivilinna@....fi>,
	Thomas Gleixner <tglx@...utronix.de>,
	Tadeusz Struk <tadeusz.struk@...el.com>, tkhai@...dex.ru,
	linux-crypto@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v5 2/7] crypto: SHA1 multibuffer crypto hash
 infrastructure

On Tue, Jul 22, 2014 at 03:09:32PM -0700, Tim Chen wrote:
> +/* Called in workqueue context, do one real cryption work (via
> + * req->complete) and reschedule itself if there are more work to
> + * do. */

You seem to manage the 'normal' comment style in other places, this one
'special' for a reason?

> +static void mcryptd_queue_worker(struct work_struct *work)
> +{
> +	struct mcryptd_cpu_queue *cpu_queue;
> +	struct crypto_async_request *req, *backlog;
> +	int i;
> +
> +	/*
> +	 * Need to loop through more than once for multi-buffer to
> +	 * be effective.
> +	 */
> +
> +	cpu_queue = container_of(work, struct mcryptd_cpu_queue, work);
> +	i = 0;
> +	while (i < MCRYPTD_BATCH || single_task_running()) {
> +		/*
> +		 * preempt_disable/enable is used to prevent
> +		 * being preempted by mcryptd_enqueue_request()
> +		 */
> +		local_bh_disable();
> +		preempt_disable();
> +		backlog = crypto_get_backlog(&cpu_queue->queue);
> +		req = crypto_dequeue_request(&cpu_queue->queue);
> +		preempt_enable();
> +		local_bh_enable();
> +
> +		if (!req)
> +			return;
> +
> +		if (backlog)
> +			backlog->complete(backlog, -EINPROGRESS);
> +		req->complete(req, 0);
> +		if (!cpu_queue->queue.qlen)
> +			return;
> +		++i;
> +	}
> +	if (cpu_queue->queue.qlen)
> +		queue_work(kcrypto_wq, &cpu_queue->work);
> +}

Right, so I don't think you need that single_task_running() thing for
this. Also its a rather inconclusive test, a task can come in while
processing the request, preempt the processing, complete and by the time
we're back to check if we want to continue the loop its only us again.

So its actually misleading..

You could do that, but then you have to keep preemption disabled across
the entire thing, and break out on need_resched(), that would entirely
obviate the need for single_task_running(), but would increase the
preemption latency by however long the req processing takes, so that's
bad too.

But you can get similar 'fuzzy' semantics as above by using something
like:

static inline bool did_context_switch(unsigned long *nivcs)
{
	if (*nivcs != current->nivcs) {
		*nivcs = current->nivcs;
		return true;
	}
	return false;
}

static void mcryptd_queue_worker()
{
	...
	unsigned long nivcs = current->nivcs;

	...

	while (!did_context_switch(&nivcs) || i < MCRYPTD_BATCH)

	...
}

It'll terminate earlier I suppose, its the inverse test. But I think you
want to terminate early if there's any activity.
--
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/

Powered by blists - more mailing lists