From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1753184AbbBCW4p (ORCPT <rfc822;w@1wt.eu>);
	Tue, 3 Feb 2015 17:56:45 -0500
Received: from 8bytes.org ([81.169.241.247]:54505 "EHLO theia.8bytes.org"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1752915AbbBCW4o (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Tue, 3 Feb 2015 17:56:44 -0500
Date: Tue, 3 Feb 2015 23:56:42 +0100
From: Joerg Roedel <joro@8bytes.org>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>, Benjamin LaHaise <bcrl@kvack.org>,
        linux-aio@kvack.org, Linux Kernel <linux-kernel@vger.kernel.org>,
        Jesse Barnes <jbarnes@virtuousgeek.org>
Subject: Re: [PATCH] iommu/amd: Fix amd_iommu_free_device()
Message-ID: <20150203225642.GK3702@8bytes.org>
References: <20150201144058.GM2974@kvack.org>
 <CA+55aFx+HVnythC+BpmDMa0Oeq1MxnXXOvs771DXpJ=PBjy1Nw@mail.gmail.com>
 <20150201221458.GN2974@kvack.org>
 <CA+55aFzAPms_orX7TY6zGCg=G-yXCrr5z7LMme7xcrXCAk6JAQ@mail.gmail.com>
 <20150202001628.GO2974@kvack.org>
 <CA+55aFy2URGTL_XKQhEO_4dTc3KNJDm9Z0O_1Gqs4G3TvW7APg@mail.gmail.com>
 <20150203112733.GM26304@twins.programming.kicks-ass.net>
 <20150203122551.GJ24151@twins.programming.kicks-ass.net>
 <20150203173413.GI3702@8bytes.org>
 <CA+55aFwHkOo+YGWKYROmce1-H_uG3KfEUmCkJUerTj=ojY2H6Q@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CA+55aFwHkOo+YGWKYROmce1-H_uG3KfEUmCkJUerTj=ojY2H6Q@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

Hi Linus,

On Tue, Feb 03, 2015 at 11:23:44AM -0800, Linus Torvalds wrote:
> The linux wakeup model has always been that there can be multiple
> sources of wakeup events, and the proper way to wait for something is
> generally a variation of
> 
>    prepare_to_wait(..);
>    for (;;) {
>        set_task_state(..);
>        .. test for condition and break out ..
>        schedule()
>    }
>    finish_wait()
> 
> although obviously these days we *heavily* favor the "wait_event()"
> interfaces that encapsulate something that looks like that loop and
> makes for a much simpler programming model. We should basically never
> favor the open-coded version, because it's so easy to get it wrong.

Thanks for your explanations. I was aware that there could be spurious
wakeups for TASK_INTERRUPTIBLE sleeps, but thought that this couldn't
happen for TASK_UNINTERRUPTIBLE. I didn't know about the lockless
wakeups and their implications, but now the Peters patch makes total
sense.

That these spurious wakeup situations are so unlikely also explains why
they were not yet reported to me :)


	Joerg