Date: Mon, 10 Oct 2016 09:03:15 -0500 (CDT)
From: Christoph Lameter <cl@linux.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
cc: Al Viro <viro@zeniv.linux.org.uk>,
        Andrew Morton <akpm@linux-foundation.org>, Jens Axboe <axboe@fb.com>,
        "Ted Ts'o" <tytso@mit.edu>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        linux-fsdevel <linux-fsdevel@vger.kernel.org>
Subject: Re: [git pull] vfs pile 1 (splice)
In-Reply-To: <CA+55aFxJsPM0OihozMUmCecg0zdG0izVDr_=z55CXkdXU3qT+w@mail.gmail.com>
Message-ID: <alpine.DEB.2.20.1610100858560.27158@east.gentwo.org>
References: <20161007222059.GS19539@ZenIV.linux.org.uk> <CA+55aFzXgWSRYeBX-qSUWPv2uhxEQ+80poQbvwvgCbf=RsKXTg@mail.gmail.com> <CA+55aFxJsPM0OihozMUmCecg0zdG0izVDr_=z55CXkdXU3qT+w@mail.gmail.com>
Content-Type: text/plain; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1763
Lines: 37

On Sun, 9 Oct 2016, Linus Torvalds wrote:

> Hmm. When I enabled SLUB debugging, I also enabled DEBUG_PAGEALLOC,
> because "why not". But it turns out that that may have been a mistake,
> because it changes the very path that failed to no longer do that
> failing access (or rather, it does it as a "probe_kernel_read()",
> which traps and ignores the failure).

DEBUG_PAGEALLOC significantly changes the layout of objects and thus this
may no longer trigger.

> 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.

Debugging options to memory allocation functions can change the memory
layout which may cause the corruption to no longer happen or no longer
happen the same way. Surely wish there would be another way.

> Christoph, the problem is that something is triggering an oops or page
> fault (depending on how bogus the address is) in __kmalloc() when it
> does that get_freepointer_safe() thing without DEBUG_PAGEALLOC. I've
> seen two different cases on two different boots, but they both were on
> that one instruction that did that

Hmm.. Then get_freepointer_safe may not be ok. Should not trigger any
faults.

> Could be elsewhere too. I saw it twice in one day which would *tend*
> to mean that it's recent, but maybe I was just lucky the previous days
> and didn't hit it. I haven't been able to repro it now, but maybe I
> figured out one reason why my reproductions have been failing ;)

Ok reading the rest of the thread it seems that we found the issue but
still this get_freepointer_safe failure is not good. Do you have some more
debugging output that can shed some more light on the failure of
get_freepointer_safe?