Received: by 2002:a05:6a10:16a7:0:0:0:0 with SMTP id gp39csp3522471pxb; Mon, 16 Nov 2020 17:43:04 -0800 (PST) X-Google-Smtp-Source: ABdhPJzym/JAmFqcBjxoYRoB3jwCYY0f3usfEG/e6nS/2Xu+/6rtqi2v5fVlT5M616XSAzvsOixP X-Received: by 2002:a17:906:840e:: with SMTP id n14mr17314956ejx.147.1605577384420; Mon, 16 Nov 2020 17:43:04 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1605577384; cv=none; d=google.com; s=arc-20160816; b=HA4J1G8gplyg4zHBK1PmTKUj5WMJWjOP6YIAW8XIoeJyXYO1wDK51+3nXWmPFN1GDW uPt/9/m3734+zwoESFPg1A4CVpB/pP5Hd87mx4IeBSuOSLGyewheKWtxsaz54y/D7pRy 45XKU2gyfkaiTMsg1GrGfFSb47F5GZ/5QWwjbqJ5V9GHoYQPaOQjvILiIA9F5YVcXW7f 5Kw3H9b188gF9upQe/Krw1OPo9zfJM0l8V7aEAN2z79Myg1avycj1JnTpEMSb323IBBK Y1juZRc8MCdVmruDtlZGwNG8z/13GKCTA7felwpdVHSTJrzU945j2s9CFFeZBd0OWC0j oShQ== 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=VoSla+/5hebblOm6QCp1PC/v1zBQye7LKAYXq4Rm7Jk=; b=MPLssxTDXsNFYmo7XLyePoP7shdb3dQmnm5fx9KAjYfY6+teGPoJ9F82tM8HMTNOEi DjpH6vW1DlFmC3D5xG0Fjvu/QM47Hy9Uz26347IrI1nYacgJqHyC3q2px1cFv16vAyCS ZH9WsVkj7reINee6RiSjZ0FwoZWwyLyfS6vy4VYhFM8HXvletQ1sfXIq8ZqntyPIU8UF dhgUtkltJ8eCImQVXPmzbXknySx15637aAkph6p38ZJa+2WXTs5/rOsolqkRh+uX2l9+ HBJmTGc0/9MjEnPPPNRHyvTH0lY8wGc7GED/cHTjFwPJKrLZfzw4YK0u6P9Sk4pcRv6E PabA== 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 hd32si10049367ejc.160.2020.11.16.17.42.42; Mon, 16 Nov 2020 17:43:04 -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 S1728452AbgKPJHP (ORCPT + 99 others); Mon, 16 Nov 2020 04:07:15 -0500 Received: from lgeamrelo13.lge.com ([156.147.23.53]:56124 "EHLO lgeamrelo11.lge.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1728165AbgKPJHP (ORCPT ); Mon, 16 Nov 2020 04:07:15 -0500 Received: from unknown (HELO lgemrelse7q.lge.com) (156.147.1.151) by 156.147.23.53 with ESMTP; 16 Nov 2020 18:07:13 +0900 X-Original-SENDERIP: 156.147.1.151 X-Original-MAILFROM: byungchul.park@lge.com Received: from unknown (HELO X58A-UD3R) (10.177.222.33) by 156.147.1.151 with ESMTP; 16 Nov 2020 18:07:13 +0900 X-Original-SENDERIP: 10.177.222.33 X-Original-MAILFROM: byungchul.park@lge.com Date: Mon, 16 Nov 2020 18:05:47 +0900 From: Byungchul Park To: Byungchul Park Cc: Steven Rostedt , Thomas Gleixner , Ingo Molnar , Linus Torvalds , Peter Zijlstra , mingo@redhat.com, will@kernel.org, LKML , Joel Fernandes , alexander.levin@microsoft.com, Daniel Vetter , Chris Wilson , duyuyang@gmail.com, johannes.berg@intel.com, Tejun Heo , Theodore Ts'o , willy@infradead.org, david@fromorbit.com, Amir Goldstein , bfields@fieldses.org, gregkh@linuxfoundation.org, kernel-team Subject: Re: [RFC] Are you good with Lockdep? Message-ID: <20201116090547.GC26078@X58A-UD3R> References: <20201111050559.GA24438@X58A-UD3R> <20201111105441.GA78848@gmail.com> <20201111093609.1bd2b637@gandalf.local.home> <87d00jo55p.fsf@nanos.tec.linutronix.de> <20201112081030.GB14554@X58A-UD3R> <20201112092612.00a19239@gandalf.local.home> 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 11:58:44PM +0900, Byungchul Park wrote: > > > FYI, roughly Lockdep is doing: > > > > > > 1. Dependency check > > > 2. Lock usage correctness check (including RCU) > > > 3. IRQ related usage correctness check with IRQFLAGS > > > > > > 2 and 3 should be there forever which is subtle and have gotten matured. > > > But 1 is not. I've been talking about 1. But again, it's not about > > > replacing it right away but having both for a while. I'm gonna try my > > > best to make it better. > > > > And I believe lockdep does handle 1. Perhaps show some tangible use case > > that you want to cover that you do not believe that lockdep can handle. If > > lockdep cannot handle it, it will show us where lockdep is lacking. If it > > can handle it, it will educate you on other ways that lockdep can be > > helpful in your development ;-) 1) OK. Lockdep might work with trylock well. 2) Definitely Lockdep cannot do what Cross-release was doing. 3) For readlock handling, let me be back later and give you examples. I need check current Lockdep code first. But I have to all-stop what I'm doing at the moment because of a very big personal issue, which is a sad thing. Sorry for the late response. Thank you, Byungchul > > Yes. That's the best thing I can do for all of us. I will. > > I already did exactly the same thing while I was developing cross-release. > But I'm willing to do it again with the current Lockdep code. > > But not today. It's over mid-night. Good night~ > > -- > Thanks, > Byungchul