Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752670AbbGIPIC (ORCPT ); Thu, 9 Jul 2015 11:08:02 -0400 Received: from www.linutronix.de ([62.245.132.108]:42620 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750998AbbGIPH4 (ORCPT ); Thu, 9 Jul 2015 11:07:56 -0400 Date: Thu, 9 Jul 2015 17:07:42 +0200 (CEST) From: Thomas Gleixner To: Sebastian Andrzej Siewior cc: Johannes Weiner , Clark Williams , Andrew Morton , Thomas Gleixner , linux-mm@kvack.org, RT , Fernando Lopez-Lezcano , Steven Rostedt , LKML , Peter Zijlstra , "Paul E. McKenney" Subject: Re: [RFC][PATCH] mm: ifdef out VM_BUG_ON check on PREEMPT_RT_FULL In-Reply-To: <20150708154432.GA31345@linutronix.de> Message-ID: References: <20150529104815.2d2e880c@sluggy> <20150529142614.37792b9ff867626dcf5e0f08@linux-foundation.org> <20150601131452.3e04f10a@sluggy> <20150601190047.GA5879@cmpxchg.org> <20150611114042.GC16115@linutronix.de> <20150619180002.GB11492@cmpxchg.org> <20150708154432.GA31345@linutronix.de> User-Agent: Alpine 2.11 (DEB 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Linutronix-Spam-Score: -1.0 X-Linutronix-Spam-Level: - X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required, ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3406 Lines: 75 On Wed, 8 Jul 2015, Sebastian Andrzej Siewior wrote: > * Johannes Weiner | 2015-06-19 14:00:02 [-0400]: > > >> This depends on the point of view. You expect interrupts to be disabled > >> while taking a lock. This is not how the function is defined. > >> The function ensures that the lock can be taken from process context while > >> it may also be taken by another caller from interrupt context. The fact > >> that it disables interrupts on vanilla to achieve its goal is an > >> implementation detail. Same goes for spin_lock_bh() btw. Based on this > >> semantic it works on vanilla and -RT. It does not disable interrupts on > >> -RT because there is no need for it: the interrupt handler runs in thread > >> context. The function delivers what it is expected to deliver from API > >> point of view: "take the lock from process context which can also be > >> taken in interrupt context". > > > >Uhm, that's really distorting reality to fit your requirements. This > >helper has been defined to mean local_irq_disable() + spin_lock() for > >ages, it's been documented in books on Linux programming. And people > >expect it to prevent interrupt handlers from executing, which it does. > > After all it documents the current implementation and the semantic > requirement. Actually its worse. Most books describe the implementation and pretend that the implementation defines the semantics, which is the fundamentally wrong approach. The sad news is, that a lot of kernel developers tend to believe that as well. The result is, that local_irq_disable / preempt_disable have become per CPU BKLs. And they have the same problem as the BKL: The protection scope of these constructs is global and completely non-obvious. So its really hard to figure out what is protected against what. Like the old BKL its an all or nothing approach. And we all know, or should know, how well that worked. This all or nothing protection is a real show stopper for RT, so we try to identify what needs protection against what and then we annotate those sections with proper scope markers, which turn into RT friendly constructs at compile time. The name of the marker in question (event_lock) might not be the best choice, but that does not invalidate the general usefulness of fine granular protection scope markers. We certainly need to revisit the names which we slapped on the particular bits and pieces, and discuss with the subsystem experts the correctness of the scope markers, but that's a completely different story. > > Seriously, just fix irqs_disabled() to mean "interrupt > > handlers can't run", which is the expectation in pretty much all > > callsites that currently use it, except for maybe irq code itself. And that solves the RT problem in which way? NOT AT ALL. It just preserves the BKL nature of irq_disable. Great solution, NOT. Why? Because it just preserves the status quo of mainline and exposes everything to the same latency behaviour which mainline has. So we add lots of mechanisms to avoid that behaviour just to bring it back by switching the irq disabled BKL on again, which means we are back to square one. Thanks, tglx -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/