From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751330AbdK3WSl (ORCPT ); Thu, 30 Nov 2017 17:18:41 -0500 Received: from mx0b-00190b01.pphosted.com ([67.231.157.127]:45034 "EHLO mx0b-00190b01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750921AbdK3WSk (ORCPT ); Thu, 30 Nov 2017 17:18:40 -0500 Subject: Re: waitqueue lockdep annotation To: Christoph Hellwig Cc: Andrew Morton , Ingo Molnar , Peter 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> <20171130221126.GA31795@lst.de> From: Jason Baron Message-ID: <21c34413-d178-fda0-91b2-6ab02c6d5a06@akamai.com> Date: Thu, 30 Nov 2017 17:18:07 -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: <20171130221126.GA31795@lst.de> 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-1711300285 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=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1709140000 definitions=main-1711300286 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 11/30/2017 05:11 PM, Christoph Hellwig wrote: > On Thu, Nov 30, 2017 at 04:38:02PM -0500, Jason Baron wrote: >> 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. > > They can't be protected by ep->lock. The file might as well be > watched for using poll or select as well, or just using epoll using > another epoll fd. > Yes, but for those cases it uses the ep->poll_wait waitqueue not the ep->wq, which is guarded by the ep->wq->lock. See the comments in 'struct eventpoll': /* Wait queue used by sys_epoll_wait() */ wait_queue_head_t wq; /* Wait queue used by file->poll() */ wait_queue_head_t poll_wait; Thanks, -Jason