Message-ID: <5715380C.5050608@hpe.com>
Date: Mon, 18 Apr 2016 15:39:56 -0400
From: Waiman Long <waiman.long@hpe.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.12) Gecko/20130109 Thunderbird/10.0.12
MIME-Version: 1.0
To: Davidlohr Bueso <dave@stgolabs.net>
CC: <mingo@kernel.org>, <peterz@infradead.org>, <linux-kernel@vger.kernel.org>,
        Davidlohr Bueso <dbueso@suse.de>
Subject: Re: [PATCH -tip 2/3] locking/pvqspinlock: Avoid double resetting
 of stats
References: <1460961103-24953-1-git-send-email-dave@stgolabs.net> <1460961103-24953-2-git-send-email-dave@stgolabs.net>
In-Reply-To: <1460961103-24953-2-git-send-email-dave@stgolabs.net>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
SpamDiagnosticOutput: 1:23
SpamDiagnosticMetadata: NSPM
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Apr 2016 19:40:03.1846 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AT5PR84MB0308
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
Content-Length: 1235
Lines: 35

On 04/18/2016 02:31 AM, Davidlohr Bueso wrote:
> ... remove the redundant second iteration, this is most
> likely a copy/past buglet.
>
> Signed-off-by: Davidlohr Bueso<dbueso@suse.de>
> ---
>   kernel/locking/qspinlock_stat.h | 2 --
>   1 file changed, 2 deletions(-)
>
> diff --git a/kernel/locking/qspinlock_stat.h b/kernel/locking/qspinlock_stat.h
> index d734b7502001..72722334237a 100644
> --- a/kernel/locking/qspinlock_stat.h
> +++ b/kernel/locking/qspinlock_stat.h
> @@ -191,8 +191,6 @@ static ssize_t qstat_write(struct file *file, const char __user *user_buf,
>
>   		for (i = 0 ; i<  qstat_num; i++)
>   			WRITE_ONCE(ptr[i], 0);
> -		for (i = 0 ; i<  qstat_num; i++)
> -			WRITE_ONCE(ptr[i], 0);
>   	}
>   	return count;
>   }

The double write is done on purpose. As the statistics count update 
isn't atomic, there is a very small chance (p) that clearing the count 
may happen in the middle of read-modify-write bus transaction. Doing a 
double write will reduce the chance further to p^2. This isn't failsafe, 
but I think is good enough.

However, I don't mind eliminate the double write either as we can always 
view the statistics count after a reset to make sure that they are 
properly cleared.

Cheers,
Longman