linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@linux-foundation.org>
To: Al Viro <viro@zeniv.linux.org.uk>,
	Andrew Morton <akpm@linux-foundation.org>,
	Jens Axboe <axboe@fb.com>, "Ted Ts'o" <tytso@mit.edu>,
	Christoph Lameter <cl@linux.com>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>
Subject: Re: [git pull] vfs pile 1 (splice)
Date: Sun, 9 Oct 2016 12:11:58 -0700	[thread overview]
Message-ID: <CA+55aFxFuQxaS4iMsu2x3BC5qWFfDtdSGWmsMQSFt-bAsyZJVg@mail.gmail.com> (raw)
In-Reply-To: <CA+55aFxJsPM0OihozMUmCecg0zdG0izVDr_=z55CXkdXU3qT+w@mail.gmail.com>

On Sun, Oct 9, 2016 at 11:40 AM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> I'll continue with *just* SLUB debugging on, but I thought it was
> interesting how enabling more memory access debugging actually ends up
> changing some really subtle code.

Indeed, now with DEBUG_PAGEALLOC disabled, I got a crash again. It
apparently happened earlier in the call chain (so maybe the slub
debugging found something), which should be good. Except it now
happens in a context where I just see a hung machine, and nothing
makes it onto the screen or into the logs ;(

So this thing is apparently not all that hard to trigger, but it
doesn't exactly seem easy either. It tends to happen fairly soon after
a reboot, which makes me suspect it's some cold-cache issue, but that
doesn't narrow things down as much as you'd think. It could still be
the block layer changes, but it could also equally well be the ext4
changes.

I don't think there's any splice activity anywhere, but who knows. And
the splice changes could have buggered the pipe locking, so..

Anyway, I don't think I can bisect it, but I'll try to narrow it down
a *bit* at least.

Not doing any more pulls on this unstable base, I've been puttering
around in trying to clean up some stupid printk logging issues
instead.

                  Linus

  reply	other threads:[~2016-10-09 19:11 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-10-07 22:20 [git pull] vfs pile 1 (splice) Al Viro
2016-10-09  6:05 ` Linus Torvalds
2016-10-09 18:40   ` Linus Torvalds
2016-10-09 19:11     ` Linus Torvalds [this message]
2016-10-10 14:03     ` Christoph Lameter
2016-10-10 19:56       ` Linus Torvalds
2016-10-12 14:10         ` Christoph Lameter

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=CA+55aFxFuQxaS4iMsu2x3BC5qWFfDtdSGWmsMQSFt-bAsyZJVg@mail.gmail.com \
    --to=torvalds@linux-foundation.org \
    --cc=akpm@linux-foundation.org \
    --cc=axboe@fb.com \
    --cc=cl@linux.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tytso@mit.edu \
    --cc=viro@zeniv.linux.org.uk \
    /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;
as well as URLs for NNTP newsgroup(s).