On Mon, 10 Oct 2016, Linus Torvalds wrote:
> But the fact that it reacts _so_ badly to double-freeing issues when
> the freelist has become corrupted due to an object being free'd and
> then modified is clearly very fragile and not great.
Yup that is why the debug options move the freepointer aft
On Mon, Oct 10, 2016 at 10:39 PM, Linus Torvalds
wrote:
>
> I guess I will have to double-check that the slub corruption is gone
> still with that fixed.
So I'm not getting any warnings now from SLUB debugging. So the
original bug seems to not have re-surfaced, and the registration bug
is gone, s
On Sun, Oct 9, 2016 at 8:41 PM, Linus Torvalds
wrote:
> This COMPLETELY UNTESTED patch tries to fix the nf_hook_entry code to do this.
>
> I repeat: it's ENTIRELY UNTESTED.
Gaah.
That patch was subtle garbage.
The "add to list" thing did this:
rcu_assign_pointer(entry->next, p);
On Mon, Oct 10, 2016 at 7:03 AM, Christoph Lameter wrote:
>
> Hmm.. Then get_freepointer_safe may not be ok. Should not trigger any
> faults.
So the reason seems to be that SLUB doesn't actually react well to
double-freeing bugs.
I'm not sure how to fix that. I think the optimistic load that SLU
Linus Torvalds writes:
> On Mon, Oct 10, 2016 at 9:28 AM, Linus Torvalds
> wrote:
>>
>> So as I already answered to Dave, I'm not actually sure that this was
>> the buggy code, or that my patch would make any difference at all.
>
> My patch does seem to fix things, and in fact the warning about
On Mon, Oct 10, 2016 at 9:28 AM, Linus Torvalds
wrote:
>
> So as I already answered to Dave, I'm not actually sure that this was
> the buggy code, or that my patch would make any difference at all.
My patch does seem to fix things, and in fact the warning about "hook
not found" now triggers.
So
On Mon, Oct 10, 2016 at 6:49 AM, Aaron Conole wrote:
>
> Okay, I'm looking it over. Sorry for the mess.
So as I already answered to Dave, I'm not actually sure that this was
the buggy code, or that my patch would make any difference at all.
I never got a good reproducer for the bug: I spent muc
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
Linus Torvalds writes:
> On Sun, Oct 9, 2016 at 7:49 PM, Linus Torvalds
> wrote:
>>
>> There is one *correct* way to remove an entry from a singly linked
>> list, and it looks like this:
>>
>> struct entry **pp, *p;
>>
>> pp = &head;
>> while ((p = *pp) != NULL) {
>> if (righ
On Sun, Oct 9, 2016 at 7:49 PM, Linus Torvalds
wrote:
>
> There is one *correct* way to remove an entry from a singly linked
> list, and it looks like this:
>
> struct entry **pp, *p;
>
> pp = &head;
> while ((p = *pp) != NULL) {
> if (right_entry(p)) {
> *pp = p->n
On Sun, Oct 9, 2016 at 6:35 PM, Aaron Conole wrote:
>
> I was just about to build and test something similar:
So I haven't actually tested that one, but looking at the code, it
really looks very bogus. In fact, that code just looks like crap. It
does *not* do a proper "remove singly linked list e
Florian Westphal writes:
> Linus Torvalds wrote:
>> On Sun, Oct 9, 2016 at 12:11 PM, Linus Torvalds
>> wrote:
>> >
>> > 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
>> >
Linus Torvalds wrote:
> On Sun, Oct 9, 2016 at 12:11 PM, Linus Torvalds
> wrote:
> >
> > 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 st
On Sun, Oct 9, 2016 at 12:11 PM, Linus Torvalds
wrote:
>
> 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.
On Sun, Oct 9, 2016 at 11:40 AM, Linus Torvalds
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.
On Sat, Oct 8, 2016 at 11:05 PM, Linus Torvalds
wrote:
>
> Hmm. I've now gotten two oopses today, all at __kmalloc+0xc3/0x1f0,
> which seems to be the
>
> *(void **)(object + s->offset);
>
> in get_freepointer().
Actually, it's in "get_freepointer_safe()", it's just that without
DEBUG_PAGEALLOC
On Fri, Oct 7, 2016 at 3:20 PM, Al Viro wrote:
> splice stuff.
Hmm. I've now gotten two oopses today, all at __kmalloc+0xc3/0x1f0,
which seems to be the
*(void **)(object + s->offset);
in get_freepointer(). Because it started happening today, I'm inclined
to blame mainly stuff I merge
splice stuff. There are conflicts in lustre; proposed resolution
is in #merge-candidate (same as it is in linux-next). There's a bunch of
branches this cycle, both mine and from other folks and I'd rather send
pull requests separately. This one is the conversion of ->splice_read()
to ITE
18 matches
Mail list logo
