linux-kernel - RE: [PATCH] drivers: hv: switch to use mb() instead of smp

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] [day] [month] [year] [list]

Message-ID: <572dfd2a52484936b598e50f29e99beb@SN2PR03MB061.namprd03.prod.outlook.com>
Date:	Tue, 18 Jun 2013 12:58:08 +0000
From:	KY Srinivasan <kys@...rosoft.com>
To:	Jason Wang <jasowang@...hat.com>,
	Haiyang Zhang <haiyangz@...rosoft.com>,
	"devel@...uxdriverproject.org" <devel@...uxdriverproject.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"Greg KH (gregkh@...uxfoundation.org)" <gregkh@...uxfoundation.org>
CC:	"stable@...r.kernel.org" <stable@...r.kernel.org>
Subject: RE: [PATCH] drivers: hv: switch to use mb() instead of smp_mb()



> -----Original Message-----
> From: Jason Wang [mailto:jasowang@...hat.com]
> Sent: Tuesday, June 18, 2013 1:04 AM
> To: KY Srinivasan; Haiyang Zhang; devel@...uxdriverproject.org; linux-
> kernel@...r.kernel.org
> Cc: Jason Wang; stable@...r.kernel.org
> Subject: [PATCH] drivers: hv: switch to use mb() instead of smp_mb()
> 
> Even if guest were compiled without SMP support, it could not assume that host
> wasn't. So switch to use mb() instead of smp_mb() to force memory barriers for
> UP guest.
> 
> Cc: K. Y. Srinivasan <kys@...rosoft.com>
> Cc: Haiyang Zhang <haiyangz@...rosoft.com>
> Cc: stable@...r.kernel.org
> Signed-off-by: Jason Wang <jasowang@...hat.com>
Signed-off-by: K. Y. Srinivasan <kys@...rosoft.com>

> ---
>  drivers/hv/ring_buffer.c |   10 +++++-----
>  drivers/hv/vmbus_drv.c   |    2 +-
>  2 files changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/hv/ring_buffer.c b/drivers/hv/ring_buffer.c
> index d6fbb57..791f45d 100644
> --- a/drivers/hv/ring_buffer.c
> +++ b/drivers/hv/ring_buffer.c
> @@ -32,7 +32,7 @@
>  void hv_begin_read(struct hv_ring_buffer_info *rbi)
>  {
>  	rbi->ring_buffer->interrupt_mask = 1;
> -	smp_mb();
> +	mb();
>  }
> 
>  u32 hv_end_read(struct hv_ring_buffer_info *rbi)
> @@ -41,7 +41,7 @@ u32 hv_end_read(struct hv_ring_buffer_info *rbi)
>  	u32 write;
> 
>  	rbi->ring_buffer->interrupt_mask = 0;
> -	smp_mb();
> +	mb();
> 
>  	/*
>  	 * Now check to see if the ring buffer is still empty.
> @@ -71,7 +71,7 @@ u32 hv_end_read(struct hv_ring_buffer_info *rbi)
> 
>  static bool hv_need_to_signal(u32 old_write, struct hv_ring_buffer_info *rbi)
>  {
> -	smp_mb();
> +	mb();
>  	if (rbi->ring_buffer->interrupt_mask)
>  		return false;
> 
> @@ -442,7 +442,7 @@ int hv_ringbuffer_write(struct hv_ring_buffer_info
> *outring_info,
>  					     sizeof(u64));
> 
>  	/* Issue a full memory barrier before updating the write index */
> -	smp_mb();
> +	mb();
> 
>  	/* Now, update the write location */
>  	hv_set_next_write_location(outring_info, next_write_location);
> @@ -549,7 +549,7 @@ int hv_ringbuffer_read(struct hv_ring_buffer_info
> *inring_info, void *buffer,
>  	/* Make sure all reads are done before we update the read index since
> */
>  	/* the writer may start writing to the read area once the read index */
>  	/*is updated */
> -	smp_mb();
> +	mb();
> 
>  	/* Update the read index */
>  	hv_set_next_read_location(inring_info, next_read_location);
> diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c
> index bf421e0..4004e54 100644
> --- a/drivers/hv/vmbus_drv.c
> +++ b/drivers/hv/vmbus_drv.c
> @@ -434,7 +434,7 @@ static void vmbus_on_msg_dpc(unsigned long data)
>  		 * will not deliver any more messages since there is
>  		 * no empty slot
>  		 */
> -		smp_mb();
> +		mb();
> 
>  		if (msg->header.message_flags.msg_pending) {
>  			/*
> --
> 1.7.1
> 
> 


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