From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751846AbdK3Vil (ORCPT ); Thu, 30 Nov 2017 16:38:41 -0500 Received: from mx0b-00190b01.pphosted.com ([67.231.157.127]:40652 "EHLO mx0b-00190b01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751055AbdK3Vij (ORCPT ); Thu, 30 Nov 2017 16:38:39 -0500 Subject: Re: waitqueue lockdep annotation To: Andrew Morton , Christoph Hellwig Cc: Ingo Molnar , eter Zijlstra , Al Viro , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org References: <20171130142037.19339-1-hch@lst.de> <20171130125050.1faba3f06fc572846f792f17@linux-foundation.org> From: Jason Baron Message-ID: Date: Thu, 30 Nov 2017 16:38:02 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <20171130125050.1faba3f06fc572846f792f17@linux-foundation.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-11-30_06:,, signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1709140000 definitions=main-1711300276 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-11-30_06:,, signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1709140000 definitions=main-1711300277 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 11/30/2017 03:50 PM, Andrew Morton wrote: > On Thu, 30 Nov 2017 06:20:35 -0800 Christoph Hellwig wrote: > >> Hi all, >> >> this series adds a strategic lockdep_assert_held to __wake_up_common >> to ensure callers really do hold the wait_queue_head lock when calling >> the unlocked wake_up variants. It turns out epoll did not do this >> for a fairly common path (hit all the time by systemd during bootup), >> so the second patch fixed this instance as well. > > What are the runtime effects of the epoll bug? > I don't think there is a bug here. The 'wake_up_locked()' calls in epoll are being protected by the ep->lock, not the wait_queue_head lock. So arguably the 'annotation' is wrong, but I don't think there is a bug beyond that. Thanks, -Jason