From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751329AbdESIKj (ORCPT ); Fri, 19 May 2017 04:10:39 -0400 Received: from LGEAMRELO11.lge.com ([156.147.23.51]:52791 "EHLO lgeamrelo11.lge.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750731AbdESIKh (ORCPT ); Fri, 19 May 2017 04:10:37 -0400 X-Original-SENDERIP: 156.147.1.126 X-Original-MAILFROM: byungchul.park@lge.com X-Original-SENDERIP: 165.244.249.26 X-Original-MAILFROM: byungchul.park@lge.com X-Original-SENDERIP: 10.177.222.33 X-Original-MAILFROM: byungchul.park@lge.com Date: Fri, 19 May 2017 17:07:08 +0900 From: Byungchul Park To: , CC: , , , , , , , , , , Subject: Re: [PATCH v6 05/15] lockdep: Implement crossrelease feature Message-ID: <20170519080708.GG28017@X58A-UD3R> References: <1489479542-27030-1-git-send-email-byungchul.park@lge.com> <1489479542-27030-6-git-send-email-byungchul.park@lge.com> MIME-Version: 1.0 In-Reply-To: <1489479542-27030-6-git-send-email-byungchul.park@lge.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-MIMETrack: Itemize by SMTP Server on LGEKRMHUB04/LGE/LG Group(Release 8.5.3FP6|November 21, 2013) at 2017/05/19 17:07:21, Serialize by Router on LGEKRMHUB04/LGE/LG Group(Release 8.5.3FP6|November 21, 2013) at 2017/05/19 17:07:21, Serialize complete at 2017/05/19 17:07:21 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Mar 14, 2017 at 05:18:52PM +0900, Byungchul Park wrote: > Lockdep is a runtime locking correctness validator that detects and > reports a deadlock or its possibility by checking dependencies between > locks. It's useful since it does not report just an actual deadlock but > also the possibility of a deadlock that has not actually happened yet. > That enables problems to be fixed before they affect real systems. > > However, this facility is only applicable to typical locks, such as > spinlocks and mutexes, which are normally released within the context in > which they were acquired. However, synchronization primitives like page > locks or completions, which are allowed to be released in any context, > also create dependencies and can cause a deadlock. So lockdep should > track these locks to do a better job. The 'crossrelease' implementation > makes these primitives also be tracked. Excuse me but I have a question... Only for maskable irq, can I assume that hardirq are prevented within hardirq context? I remember that nested interrupts were allowed in the past but not recommanded. But what about now? I'm curious about the overall direction of kernel and current status. It would be very appriciated if you answer it. Thank you. Byungchul