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:	Fri, 24 Apr 2015 00:18:00 +0200 (CEST)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Sebastian Andrzej Siewior <bigeasy@...utronix.de>
cc:	Manfred Spraul <manfred@...orfullife.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Peter Zijlstra <peterz@...radead.org>,
	Ingo Molnar <mingo@...hat.com>,
	Darren Hart <darren@...art.com>,
	Steven Rostedt <rostedt@...dmis.org>,
	fredrik.markstrom@...driver.com,
	Davidlohr Bueso <dave@...olabs.net>,
	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
Subject: Re: [PATCH v2] ipc/mqueue: remove STATE_PENDING

On Fri, 10 Apr 2015, Sebastian Andrzej Siewior wrote:
> >And: please test it, too. (patch the kernel so that you can trigger
> >this case).
> 
> Why patch? Isn't this triggered if you have a reader waiting and you
> send a message?

Manfred referred to the exit race. Though you can spare that exercise
as it is safe by definition if you hold a ref on the task.

Can you please convert that over to Peters lockless wake queues so we
do not reimplement the same thing open coded here.

> +static struct task_struct *pipelined_send(struct mqueue_inode_info *info,
>  				  struct msg_msg *message,
>  				  struct ext_wait_queue *receiver)
>  {
> +	struct task_struct *r_task;
> +
>  	receiver->msg = message;
>  	list_del(&receiver->list);
> -	receiver->state = STATE_PENDING;
> -	wake_up_process(receiver->task);
> +	r_task = receiver->task;
> +	get_task_struct(r_task);
>  	smp_wmb();

While we are at it. The barrier here and the one in pipelined_receive
are not documented and they are missing a proper pairing on the read
side. The comment which you removed was pretty vague about the purpose
of the barrier as well.

Thanks,

	tglx











--
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