From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.2 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id C6384C55ABD for ; Mon, 16 Nov 2020 09:16:48 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 79C7920A8B for ; Mon, 16 Nov 2020 09:16:48 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728237AbgKPIq4 (ORCPT ); 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