Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1751922AbdI2IAI (ORCPT <rfc822;w@1wt.eu>);
        Fri, 29 Sep 2017 04:00:08 -0400
Received: from Galois.linutronix.de ([146.0.238.70]:59892 "EHLO
        Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1751037AbdI2IAH (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Fri, 29 Sep 2017 04:00:07 -0400
Date: Fri, 29 Sep 2017 09:59:55 +0200 (CEST)
From: Thomas Gleixner <tglx@linutronix.de>
To: Junaid Shahid <junaids@google.com>
cc: Peter Zijlstra <peterz@infradead.org>, linux-kernel@vger.kernel.org,
        Andres Lagar-Cavilla <andreslc@google.com>,
        Greg Thelen <gthelen@google.com>,
        Rusty Russell <rusty@rustcorp.com.au>
Subject: Re: [PATCH] kthread: Fix race condition between kthread_parkme()
 and kthread_unpark()
In-Reply-To: <CAL-GctE0BLVk=ps09dnir8pcpnfzg88jMK4CKkRVmY7-ho87nQ@mail.gmail.com>
Message-ID: <alpine.DEB.2.20.1709290958450.1890@nanos>
References: <20170429023236.60452-1-junaids@google.com> <20170927121706.g5qydxv3v2usmdd5@hirez.programming.kicks-ass.net> <CAL-GctE0BLVk=ps09dnir8pcpnfzg88jMK4CKkRVmY7-ho87nQ@mail.gmail.com>
User-Agent: Alpine 2.20 (DEB 67 2015-01-07)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
X-Linutronix-Spam-Score: -1.0
X-Linutronix-Spam-Level: -
X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required,  ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
Content-Length: 655
Lines: 18

On Thu, 28 Sep 2017, Junaid Shahid wrote:

> Hi Peter,
> 
> It looks like try_cmpxchg is not available on non-x86 archs, but other than
> that the version that you proposed looks good.
> 
> One thing that I am a bit curious about is that the original code, before
> either patch, had a test_and_set_bit for KTHREAD_IS_PARKED rather than just
> a set_bit. I can't think of any reason why that was needed, since it
> doesn't look like TASK_PARKED tasks are susceptible to spurious wakeups. Do
> you by any chance happen to know if there was any specific reason for it?

Everything is susceptible to spurious wakeups and has to deal with it.

Thanks,

	tglx