public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Carlos O'Donell" <carlos@redhat.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>,
	Darren Hart <dvhart@linux.intel.com>,
	LKML <linux-kernel@vger.kernel.org>,
	Dave Jones <davej@redhat.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Darren Hart <darren@dvhart.com>,
	Davidlohr Bueso <davidlohr@hp.com>,
	Ingo Molnar <mingo@kernel.org>,
	Steven Rostedt <rostedt@goodmis.org>,
	Clark Williams <williams@redhat.com>,
	Paul McKenney <paulmck@linux.vnet.ibm.com>,
	Lai Jiangshan <laijs@cn.fujitsu.com>,
	Roland McGrath <roland@hack.frob.com>,
	Jakub Jelinek <jakub@redhat.com>,
	Michael Kerrisk <mtk.manpages@gmail.com>,
	Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Subject: Re: [patch 0/3] futex/rtmutex: Fix issues exposed by trinity
Date: Fri, 16 May 2014 14:21:21 -0400	[thread overview]
Message-ID: <53765721.8090602@redhat.com> (raw)
In-Reply-To: <20140515082507.GC30445@twins.programming.kicks-ass.net>

On 05/15/2014 04:25 AM, Peter Zijlstra wrote:
> On Wed, May 14, 2014 at 04:59:58PM -0400, Carlos O'Donell wrote:
>> I will make my personal opinion clear:
>>
>> - Internal defects should raise immediate assertions.
>>
>> - Real problems like resource availability, deadlocks, and
>>   other recoverable errors should result in the API returning
>>   an appropriate error code that must not diverge from the POSIX
>>   definitions for those codes (when such a definition exists).
>>
>> I'm not a believer in "only the hot path matters", there are such
>> things as robustness and error detection, and they matter.
> 
> Awesome. In case of doubt though, I would prefer a return to an assert,
> just in case userspace actually does know wtf its doing ;-)

No. In that case the person who knows attaches a debugger to determine
why the internal state is inconsistent. That may require kernel or glibc
debugging and asserting as close to the point of corruption is the only
useful behaviour. I know it's painful, but the number of people who know
what they are doing is vanishingly small compared to the other set.

> Granted, that seems to be very rare, but still, its entirely annoying
> for those few people who do care to get dead programs.
> 
> Alternatively, we could have something like you have for the allocator
> (which is, afaik, also considered a hot path) these env variables like
> MALLOC_CHECK_ to influence this edge behaviour.

We are considering a runtime tunnables framework to unify all of these
kinds of tweaks into a stable API. Given that asserting or not asserting
does not impact the standards conformance we could make that a tunnable
with the default being to assert. The tunnables framework is still pie
in the sky because we need a low-overhead framework to check the global
tunnables. However, we need them, as I've mentioned before as an example
we have an ancient 40MB stack cache in glibc for thread stack reuse that
nobody remembers why it was tuned to that value. Magic.

Cheers,
Carlos.


  reply	other threads:[~2014-05-16 18:22 UTC|newest]

Thread overview: 53+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-12 20:45 [patch 0/3] futex/rtmutex: Fix issues exposed by trinity Thomas Gleixner
2014-05-12 20:45 ` [patch 1/3] rtmutex: Add missing deadlock check Thomas Gleixner
2014-05-13  5:51   ` Lai Jiangshan
2014-05-13  8:45     ` Thomas Gleixner
2014-05-13  8:48     ` Peter Zijlstra
2014-05-13 16:12       ` Paul E. McKenney
2014-05-13 19:42       ` Thomas Gleixner
2014-05-13 20:20         ` Steven Rostedt
2014-05-13 20:36           ` Paul E. McKenney
2014-05-13 21:27             ` Thomas Gleixner
2014-05-13 22:00               ` Paul E. McKenney
2014-05-13 22:44                 ` Steven Rostedt
2014-05-13 23:27                   ` Paul E. McKenney
2014-05-13 23:53                     ` Steven Rostedt
2014-05-14  0:12                       ` Paul E. McKenney
2014-05-14  6:54                       ` Thomas Gleixner
     [not found]                         ` <CAGChsmO9GO1Z2VBbw7uLtTXpYowdoUQbK8C3=Dt2jtGAnc6D2A@mail.gmail.com>
2014-05-14 13:33                           ` Thomas Gleixner
2014-05-14  6:42                   ` Thomas Gleixner
2014-05-14 12:59     ` Thomas Gleixner
2014-05-12 20:45 ` [patch 2/3] futex: Add another early deadlock detection check Thomas Gleixner
2014-05-19 12:22   ` [tip:core/urgent] " tip-bot for Thomas Gleixner
2014-05-12 20:45 ` [patch 3/3] futex: Prevent attaching to kernel threads Thomas Gleixner
2014-05-12 20:54   ` Peter Zijlstra
2014-05-12 21:16     ` Thomas Gleixner
2014-05-12 21:59   ` Davidlohr Bueso
2014-05-12 22:18     ` Thomas Gleixner
2014-05-19 12:22   ` [tip:core/urgent] " tip-bot for Thomas Gleixner
2014-05-12 21:37 ` [patch 0/3] futex/rtmutex: Fix issues exposed by trinity Steven Rostedt
2014-05-12 21:52   ` Thomas Gleixner
2014-05-12 22:08     ` Steven Rostedt
2014-05-12 22:37       ` Thomas Gleixner
2014-05-12 23:18         ` Steven Rostedt
2014-05-13  6:37   ` Ingo Molnar
2014-05-13  3:54 ` Darren Hart
2014-05-13  9:08   ` Thomas Gleixner
2014-05-14  7:06     ` Carlos O'Donell
2014-05-14 10:26       ` Thomas Gleixner
2014-05-14 20:59         ` Carlos O'Donell
2014-05-14 22:54           ` Thomas Gleixner
2014-05-15  7:37           ` Peter Zijlstra
2014-05-15  8:25           ` Peter Zijlstra
2014-05-16 18:21             ` Carlos O'Donell [this message]
2014-05-14  6:58   ` Carlos O'Donell
2014-05-14  9:22     ` Peter Zijlstra
2014-05-14 21:17       ` Carlos O'Donell
2014-05-14 23:11         ` Thomas Gleixner
2014-05-16 17:54           ` Carlos O'Donell
2014-05-15  8:07         ` Peter Zijlstra
2014-05-16 18:14           ` Carlos O'Donell
2014-05-14  9:53     ` Thomas Gleixner
2014-05-14 10:07       ` Peter Zijlstra
2014-05-14 10:28         ` Thomas Gleixner
2014-05-16 17:55           ` Carlos O'Donell

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=53765721.8090602@redhat.com \
    --to=carlos@redhat.com \
    --cc=bigeasy@linutronix.de \
    --cc=darren@dvhart.com \
    --cc=davej@redhat.com \
    --cc=davidlohr@hp.com \
    --cc=dvhart@linux.intel.com \
    --cc=jakub@redhat.com \
    --cc=laijs@cn.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=mtk.manpages@gmail.com \
    --cc=paulmck@linux.vnet.ibm.com \
    --cc=peterz@infradead.org \
    --cc=roland@hack.frob.com \
    --cc=rostedt@goodmis.org \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.org \
    --cc=williams@redhat.com \
    /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: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox