All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bill Davidsen <davidsen@tmr.com>
To: Jens Axboe <axboe@kernel.dk>
Cc: Christoph Hellwig <hch@infradead.org>,
	Ingo Molnar <mingo@elte.hu>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Andrew Morton <akpm@linux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	"Rafael J. Wysocki" <rjw@sisk.pl>
Subject: Re: [regression] Crash in wb_clear_pending()
Date: Mon, 05 Jul 2010 17:19:52 -0400	[thread overview]
Message-ID: <4C324C78.5090805@tmr.com> (raw)
In-Reply-To: <4C323177.3070606@kernel.dk>

Jens Axboe wrote:
> On 05/07/10 20.20, Christoph Hellwig wrote:
>> On Mon, Jul 05, 2010 at 07:14:20PM +0200, Ingo Molnar wrote:
>>> Nor does it apply to v2.6.35-rc4:
>> It's indeed missing the two previous patches to the writeback code that
>> I thought Jens sent to Linus aswell [1].  The race was initially found using
>> a distro kernel with the patches backported, and in the meantime we've
>> done a lot of testing with this patch (and the two previous that also
>> were backported).  I'd prefer to get this full stack that's been in
>> -next for a while and got large machine testing, but if Jens prefers it
>> I can aim for a smaller variant.  Jens, what version do you prefer?
> 
> The oops itself looks like a recurrence of the missing RCU grace or
> too early stack wakeup, which should be a 1-2 liner once it's found.
> So I think such a patch would be greatly preferable to doing this
> much churn this late in the cycle.
> 
Absent a small fix, and given that the big fix has a lot more testing than any 
new patch might, in this case the quickie might be undesirable. Particularly 
since posters here seem sure that code will be replaced in the next version 
anyway, and lightly tested patch to obsolete code is actually less conservative.

I can't reproduce the bug, so take that as an opinion based on Christoph's 
comment on the use of a tested full change.

> Christoph, do you have time to look into that? We can always punt to
> the larger version in a few days if unsuccessful, which gets rid of
> the problem by simply deleting the troublesome and complex
> clear/wakeup logic.
> 


-- 
Bill Davidsen <davidsen@tmr.com>
   "We have more to fear from the bungling of the incompetent than from
the machinations of the wicked."  - from Slashdot

  parent reply	other threads:[~2010-07-05 21:21 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-07-05  3:44 Linux 2.6.35-rc4 Linus Torvalds
2010-07-05  8:55 ` [regression] Crash in wb_clear_pending() (was: Linux 2.6.35-rc4) Ingo Molnar
2010-07-05 16:40   ` Christoph Hellwig
2010-07-05 17:11     ` Ingo Molnar
2010-07-05 17:14       ` Ingo Molnar
2010-07-05 18:20         ` Christoph Hellwig
2010-07-05 19:24           ` [regression] Crash in wb_clear_pending() Jens Axboe
2010-07-05 19:32             ` Christoph Hellwig
2010-07-05 19:45               ` Jens Axboe
2010-07-05 21:19             ` Bill Davidsen [this message]
2010-07-05 23:34               ` Linus Torvalds
2010-07-06  6:25                 ` Jens Axboe
2010-07-06  6:49                   ` Ingo Molnar
2010-07-06  6:47                 ` Ingo Molnar
2010-07-06  6:50                   ` Jens Axboe
2010-07-06  6:56                     ` Ingo Molnar
2010-07-07  1:47                   ` Christoph Hellwig
2010-07-05 10:22 ` Linux 2.6.35-rc4 Xiaotian Feng
2010-07-09 21:43   ` Linus Torvalds
2010-07-05 21:25 ` Linux 2.6.35-rc4 - CONFIG_LOCALVERSION ignored? Rafael J. Wysocki
2010-07-05  0:39   ` linux-next: build failure after merge of the kbuild-current tree Stephen Rothwell
2010-07-05 21:43     ` Linux 2.6.35-rc4 - CONFIG_LOCALVERSION ignored? Michal Marek
2010-07-06 18:29       ` Rafael J. Wysocki
2010-07-07  1:32         ` Stephen Rothwell
2010-07-12 16:58   ` Benny Halevy
2010-07-12 17:20     ` Linus Torvalds
2010-07-12 17:34       ` Benny Halevy
2010-07-09 14:21 ` Yet another 2.6.35 regression (AGP)? Woody Suwalski
2010-07-09 15:58   ` Jesse Barnes
2010-07-09 16:27     ` Woody Suwalski
2010-07-09 17:49       ` Jesse Barnes
2010-07-12 15:28   ` Maciej Rutecki

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=4C324C78.5090805@tmr.com \
    --to=davidsen@tmr.com \
    --cc=a.p.zijlstra@chello.nl \
    --cc=akpm@linux-foundation.org \
    --cc=axboe@kernel.dk \
    --cc=hch@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=rjw@sisk.pl \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.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: link
Be 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.