From: Byungchul Park <max.byungchul.park@gmail.com> To: Bart Van Assche <Bart.VanAssche@wdc.com> Cc: "tglx@linutronix.de" <tglx@linutronix.de>, "mingo@kernel.org" <mingo@kernel.org>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, "peterz@infradead.org" <peterz@infradead.org>, "hch@infradead.org" <hch@infradead.org>, "amir73il@gmail.com" <amir73il@gmail.com>, "linux-xfs@vger.kernel.org" <linux-xfs@vger.kernel.org>, "linux-mm@kvack.org" <linux-mm@kvack.org>, "linux-block@vger.kernel.org" <linux-block@vger.kernel.org>, "oleg@redhat.com" <oleg@redhat.com>, "darrick.wong@oracle.com" <darrick.wong@oracle.com>, "johannes.berg@intel.com" <johannes.berg@intel.com>, "byungchul.park@lge.com" <byungchul.park@lge.com>, "linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>, "idryomov@gmail.com" <idryomov@gmail.com>, "tj@kernel.org" <tj@kernel.org>, "kernel-team@lge.com" <kernel-team@lge.com>, "david@fromorbit.com" <david@fromorbit.com> Subject: Re: [RESEND PATCH 1/3] completion: Add support for initializing completion with lockdep_map Date: Sat, 21 Oct 2017 11:23:58 +0900 [thread overview] Message-ID: <CANrsvRNnOp_rgEWG2FGg7qaEQi=yEyhiZkpWSW62w21BvJ9Shg@mail.gmail.com> (raw) In-Reply-To: <1508529532.3029.15.camel@wdc.com> On Sat, Oct 21, 2017 at 4:58 AM, Bart Van Assche <Bart.VanAssche@wdc.com> wrote: > Sorry but I'm not sure that's the best possible answer. In my opinion > avoiding that completion objects have dependencies on other lock objects, > e.g. by avoiding to wait on a completion object while holding a mutex, is a > far superior strategy over adding cross-release checking to completion > objects. The former strategy namely makes it unnecessary to add > cross-release checking to completion objects because that strategy ensures > that these completion objects cannot get involved in a deadlock. The latter It's true if we force it. But do you think it's possible? > strategy can lead to false positive deadlock reports by the lockdep code, What do you think false positives come from? It comes from assigning lock classes falsely where we should more care, rather than lockdep code itself. The same is applicable to cross-release. > something none of us wants. > > A possible alternative strategy could be to enable cross-release checking > only for those completion objects for which waiting occurs inside a critical > section. Of course, it already did. Cross-release doesn't consider any waiting outside of critical sections at all, and it should do. > As explained in another e-mail thread, unlike the lock inversion checking > performed by the <= v4.13 lockdep code, cross-release checking is a heuristic > that does not have a sound theoretical basis. The lock validator is an It's not heuristic but based on the same theoretical basis as <=4.13 lockdep. I mean, the key basis is: 1) What causes deadlock 2) What is a dependency 3) Build a dependency when identified > important tool for kernel developers. It is important that it produces as few > false positives as possible. Since the cross-release checks are enabled > automatically when enabling lockdep, I think it is normal that I, as a kernel > developer, care that the cross-release checks produce as few false positives > as possible. No doubt. That's why I proposed these patches.
WARNING: multiple messages have this Message-ID (diff)
From: Byungchul Park <max.byungchul.park@gmail.com> To: Bart Van Assche <Bart.VanAssche@wdc.com> Cc: "tglx@linutronix.de" <tglx@linutronix.de>, "mingo@kernel.org" <mingo@kernel.org>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, "peterz@infradead.org" <peterz@infradead.org>, "hch@infradead.org" <hch@infradead.org>, "amir73il@gmail.com" <amir73il@gmail.com>, "linux-xfs@vger.kernel.org" <linux-xfs@vger.kernel.org>, "linux-mm@kvack.org" <linux-mm@kvack.org>, "linux-block@vger.kernel.org" <linux-block@vger.kernel.org>, "oleg@redhat.com" <oleg@redhat.com>, "darrick.wong@oracle.com" <darrick.wong@oracle.com>, "johannes.berg@intel.com" <johannes.berg@intel.com>, "byungchul.park@lge.com" <byungchul.park@lge.com>, "linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>, "idryomov@gmail.com" <idryomov@gmail.com>, "tj@kernel.org" <tj@kernel.org>, "kernel-team@lge.com" <kernel-team@lge.com>, "david@fromorbit.com" <david@fromorbit.com> Subject: Re: [RESEND PATCH 1/3] completion: Add support for initializing completion with lockdep_map Date: Sat, 21 Oct 2017 11:23:58 +0900 [thread overview] Message-ID: <CANrsvRNnOp_rgEWG2FGg7qaEQi=yEyhiZkpWSW62w21BvJ9Shg@mail.gmail.com> (raw) In-Reply-To: <1508529532.3029.15.camel@wdc.com> On Sat, Oct 21, 2017 at 4:58 AM, Bart Van Assche <Bart.VanAssche@wdc.com> wrote: > Sorry but I'm not sure that's the best possible answer. In my opinion > avoiding that completion objects have dependencies on other lock objects, > e.g. by avoiding to wait on a completion object while holding a mutex, is a > far superior strategy over adding cross-release checking to completion > objects. The former strategy namely makes it unnecessary to add > cross-release checking to completion objects because that strategy ensures > that these completion objects cannot get involved in a deadlock. The latter It's true if we force it. But do you think it's possible? > strategy can lead to false positive deadlock reports by the lockdep code, What do you think false positives come from? It comes from assigning lock classes falsely where we should more care, rather than lockdep code itself. The same is applicable to cross-release. > something none of us wants. > > A possible alternative strategy could be to enable cross-release checking > only for those completion objects for which waiting occurs inside a critical > section. Of course, it already did. Cross-release doesn't consider any waiting outside of critical sections at all, and it should do. > As explained in another e-mail thread, unlike the lock inversion checking > performed by the <= v4.13 lockdep code, cross-release checking is a heuristic > that does not have a sound theoretical basis. The lock validator is an It's not heuristic but based on the same theoretical basis as <=4.13 lockdep. I mean, the key basis is: 1) What causes deadlock 2) What is a dependency 3) Build a dependency when identified > important tool for kernel developers. It is important that it produces as few > false positives as possible. Since the cross-release checks are enabled > automatically when enabling lockdep, I think it is normal that I, as a kernel > developer, care that the cross-release checks produce as few false positives > as possible. No doubt. That's why I proposed these patches. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2017-10-21 2:24 UTC|newest] Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top 2017-10-18 9:38 Fix false positive by LOCKDEP_CROSSRELEASE Byungchul Park 2017-10-18 9:38 ` Byungchul Park 2017-10-18 9:38 ` [RESEND PATCH 1/3] completion: Add support for initializing completion with lockdep_map Byungchul Park 2017-10-18 9:38 ` Byungchul Park 2017-10-19 23:24 ` Bart Van Assche 2017-10-19 23:24 ` Bart Van Assche 2017-10-20 6:14 ` Byungchul Park 2017-10-20 6:14 ` Byungchul Park 2017-10-20 6:34 ` Thomas Gleixner 2017-10-20 6:34 ` Thomas Gleixner 2017-10-20 19:58 ` Bart Van Assche 2017-10-20 19:58 ` Bart Van Assche 2017-10-20 19:58 ` Bart Van Assche 2017-10-21 2:23 ` Byungchul Park [this message] 2017-10-21 2:23 ` Byungchul Park 2017-10-22 14:34 ` Bart Van Assche 2017-10-22 14:34 ` Bart Van Assche 2017-10-23 2:08 ` Byungchul Park 2017-10-23 2:08 ` Byungchul Park 2017-10-25 7:07 ` Bart Van Assche 2017-10-25 7:07 ` Bart Van Assche 2017-10-25 11:49 ` Byungchul Park 2017-10-25 11:49 ` Byungchul Park 2017-10-18 9:38 ` [RESEND PATCH 2/3] lockdep: Remove unnecessary acquisitions wrt workqueue flush Byungchul Park 2017-10-18 9:38 ` Byungchul Park 2017-10-18 9:38 ` [RESEND PATCH 3/3] lockdep: Assign a lock_class per gendisk used for wait_for_completion() Byungchul Park 2017-10-18 9:38 ` Byungchul Park 2017-10-18 9:59 ` Ingo Molnar 2017-10-18 9:59 ` Ingo Molnar 2017-10-19 1:57 ` Byungchul Park 2017-10-19 1:57 ` Byungchul Park 2017-10-18 14:29 ` Fix false positive by LOCKDEP_CROSSRELEASE Bart Van Assche 2017-10-18 14:29 ` Bart Van Assche 2017-10-19 1:57 ` Byungchul Park 2017-10-19 1:57 ` Byungchul Park 2017-10-19 14:52 ` Bart Van Assche 2017-10-19 14:52 ` Bart Van Assche 2017-10-19 14:52 ` Bart Van Assche
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to='CANrsvRNnOp_rgEWG2FGg7qaEQi=yEyhiZkpWSW62w21BvJ9Shg@mail.gmail.com' \ --to=max.byungchul.park@gmail.com \ --cc=Bart.VanAssche@wdc.com \ --cc=amir73il@gmail.com \ --cc=byungchul.park@lge.com \ --cc=darrick.wong@oracle.com \ --cc=david@fromorbit.com \ --cc=hch@infradead.org \ --cc=idryomov@gmail.com \ --cc=johannes.berg@intel.com \ --cc=kernel-team@lge.com \ --cc=linux-block@vger.kernel.org \ --cc=linux-fsdevel@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=linux-xfs@vger.kernel.org \ --cc=mingo@kernel.org \ --cc=oleg@redhat.com \ --cc=peterz@infradead.org \ --cc=tglx@linutronix.de \ --cc=tj@kernel.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.