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, 30 Jun 2008 15:25:12 +0200
From:	Jarek Poplawski <jarkao2@...il.com>
To:	Oleg Nesterov <oleg@...sign.ru>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Jarek Poplawski <jarkao2@...pl>,
	Max Krasnyansky <maxk@...lcomm.com>,
	Peter Zijlstra <peterz@...radead.org>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/3] workqueues: implement flush_work()

On Sun, Jun 29, 2008 at 06:49:26PM +0400, Oleg Nesterov wrote:
...
> --- 26-rc2/kernel/workqueue.c~WQ_2_FLUSH_WORK	2008-06-12 21:28:13.000000000 +0400
> +++ 26-rc2/kernel/workqueue.c	2008-06-29 18:20:33.000000000 +0400
> @@ -399,6 +399,52 @@ void flush_workqueue(struct workqueue_st
>  }
>  EXPORT_SYMBOL_GPL(flush_workqueue);
>  
> +/**
> + * flush_work - block until a work_struct's callback has terminated
> + * @work: the work which is to be flushed
> + *
> + * It is expected that, prior to calling flush_work(), the caller has
> + * arranged for the work to not be requeued, otherwise it doesn't make
> + * sense to use this function.
> + */

I missed this before, and probably it's not required, but "Returns..."
could be added here.

> +int flush_work(struct work_struct *work)
> +{
> +	struct cpu_workqueue_struct *cwq;
> +	struct list_head *prev;
> +	struct wq_barrier barr;
> +
> +	might_sleep();
> +	cwq = get_wq_data(work);
> +	if (!cwq)
> +		return 0;
> +
> +	prev = NULL;
> +	spin_lock_irq(&cwq->lock);
> +	if (!list_empty(&work->entry)) {
> +		/*
> +		 * See the comment near try_to_grab_pending()->smp_rmb().
> +		 * If it was re-queued under us we are not going to wait.
> +		 */
> +		smp_rmb();
> +		if (unlikely(cwq != get_wq_data(work)))
> +			goto out;
> +		prev = &work->entry;
> +	} else {

Probably it doesn't matter too much, but one little doubt: don't we
need (for consistency) smp_rmb() for this branch as well? It seems
this cwq could be read out of order here too.

> +		if (cwq->current_work != work)
> +			goto out;
> +		prev = &cwq->worklist;
> +	}
> +	insert_wq_barrier(cwq, &barr, prev->next);
> +out:
> +	spin_unlock_irq(&cwq->lock);
> +	if (!prev)
> +		return 0;
> +
> +	wait_for_completion(&barr.done);
> +	return 1;
> +}
> +EXPORT_SYMBOL_GPL(flush_work);
> +
>  /*
>   * Upon a successful return (>= 0), the caller "owns" WORK_STRUCT_PENDING bit,
>   * so this work can't be re-armed in any way.
> 

Otherwise, all looks correct to me as before.

Regards,
Jarek P.
--
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ