Received: by 2002:a05:6a10:16a7:0:0:0:0 with SMTP id gp39csp2936235pxb; Mon, 16 Nov 2020 00:52:15 -0800 (PST) X-Google-Smtp-Source: ABdhPJxuVTbtsEnrI1Ecy3+1/9iDhcKeUlcOH+u1vJTogPb+tZvCOHXQy+/M8JVytUeGHP6J8azj X-Received: by 2002:a17:906:3a17:: with SMTP id z23mr5411481eje.332.1605516734882; Mon, 16 Nov 2020 00:52:14 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1605516734; cv=none; d=google.com; s=arc-20160816; b=m36yClPYm3MQpygSna/mTTLQ7m9PC5XgXkaHLbWBeV7tJF0uCNi+xrR1fNLkqISRmw f8OudLFxEz9c1tsvEz5a9qecQ9R3sVWwpUbfgKYQPgNQbqi3dX58ENai0Zf7oj2mZyod LWEdjEp9gXAveU0qfv9eJTPFykcwOiGo6do2iRsig0QntW9r6N6wBzS8pbTUPLdUNC/k ZBrHO3G/6xSNzbKI7lNA0s3cpMB+FUx/VPtAUIsw8GRRPGKlWgnCdfbHVJnP0lKi1C6b IK4DhKPpZj9kUGfeTM7ceVnZsKtOByUsg7phkHrwajWieEO9ED1RuKSTZ975FIB4Wct6 isVg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=BYPNTRLlB4+9fiRplperYzOrm3g5lXgBuKZp4nn0iFE=; b=Z6RBLwtFE6h3e1GZwi7YFOWMz0jYxyw759hWt5EV+9ii5POw+29FIQ7880NtTbhov/ dM8kB9axeE6xHf4SfTB4RWHwiSRFmWPKI4MD3HVq3vnWb7Wz2t/cRcCMjw3q1YzpwMfT JAzqkzwdqcGI41bCQq2W3G5iLCw4S6lpRWFdDEck9Ja/InhfyrjkrVE3ZGtcvnGZHxTi bGkmbqsD/Qe0lQQBhUiPeiNvn4yO6+IuZSyb9TpAwM51LUO8PgmOhMy9Rl0cNpEBtmv2 BtTKxySlvXnVwyvrCOZI5DxCE/j1m355lRtyFQYEmqxqLzSzXbdHQZLnAw7g1WaRNgzJ ZoAw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id s10si11391939edt.506.2020.11.16.00.51.51; Mon, 16 Nov 2020 00:52:14 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728231AbgKPIq4 (ORCPT + 99 others); Mon, 16 Nov 2020 03:46:56 -0500 Received: from lgeamrelo12.lge.com ([156.147.23.52]:43388 "EHLO lgeamrelo11.lge.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726643AbgKPIq4 (ORCPT ); Mon, 16 Nov 2020 03:46:56 -0500 Received: from unknown (HELO lgeamrelo04.lge.com) (156.147.1.127) by 156.147.23.52 with ESMTP; 16 Nov 2020 17:46:53 +0900 X-Original-SENDERIP: 156.147.1.127 X-Original-MAILFROM: byungchul.park@lge.com Received: from unknown (HELO X58A-UD3R) (10.177.222.33) by 156.147.1.127 with ESMTP; 16 Nov 2020 17:46:53 +0900 X-Original-SENDERIP: 10.177.222.33 X-Original-MAILFROM: byungchul.park@lge.com Date: Mon, 16 Nov 2020 17:45:27 +0900 From: Byungchul Park To: Daniel Vetter Cc: Steven Rostedt , Ingo Molnar , Linus Torvalds , Peter Zijlstra , Ingo Molnar , Will Deacon , Linux Kernel Mailing List , Thomas Gleixner , Joel Fernandes , Sasha Levin , "Wilson, Chris" , duyuyang@gmail.com, Johannes Berg , Tejun Heo , Theodore Ts'o , Matthew Wilcox , Dave Chinner , Amir Goldstein , "J. Bruce Fields" , Greg KH , kernel-team@lge.com Subject: Re: [RFC] Are you good with Lockdep? Message-ID: <20201116084527.GA26078@X58A-UD3R> References: <20201111050559.GA24438@X58A-UD3R> <20201111105441.GA78848@gmail.com> <20201111093609.1bd2b637@gandalf.local.home> <20201112103225.GE14554@X58A-UD3R> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Nov 12, 2020 at 02:56:49PM +0100, Daniel Vetter wrote: > > > I think I understand it. For things like completions and other "wait for > > > events" we have lockdep annotation, but it is rather awkward to implement. > > > Having something that says "lockdep_wait_event()" and > > > "lockdep_exec_event()" wrappers would be useful. > > > > Yes. It's a problem of lack of APIs. It can be done by reverting revert > > of cross-release without big change. ;-) > > +1 on lockdep-native support for this. For another use case I've added > annotations for dma_fence_wait, and they're not entirely correct > unfortunately. But the false positives is along the lines of "you I'd like to help you solve the problem you are facing. Let me be back and help you later. I have to all-stop what I'm doing at the moment becasue of a very big personal issue, which is a sad thing. Thank you, Byungchul > really shouldn't do this, even if it's in theory deadlock free". See > > commit 5fbff813a4a328b730cb117027c43a4ae9d8b6c0 > Author: Daniel Vetter > Date: Tue Jul 7 22:12:05 2020 +0200 > > dma-fence: basic lockdep annotations > > for fairly lengthy discussion of the problem and what I ended up with. > > Thanks, Daniel > -- > Daniel Vetter > Software Engineer, Intel Corporation > http://blog.ffwll.ch