Re: unaligned accesses in SLAB etc.

From: Meelis Roos
Date: Thu Oct 16 2014 - 03:03:07 EST


> >> > I'd like to know that your another problem is related to commit
> >> > bf0dea23a9c0 ("mm/slab: use percpu allocator for cpu cache"). So,
> >> > if the commit is reverted, your another problem is also gone
> >> > completely?
> >>
> >> The other problem has been present forever.
> >
> > Umm? I am afraid I have been describing it badly. This random
> > SIGBUS+SIGSEGV problem is new - I have not seen it before.
>
> Sorry, I thought it was the same bug that causes git corruptions
> for you. I misunderstood.
>
> > I have been able to do kernel compiles for years on sparc64 (modulo
> > specific bugs in specific configurations) and 3.17 + start/end swap
> > patch seems also stable for most machine. With yesterdays git + align
> > patch, it dies with SIGBUS multiple times during compilation so it's a
> > new regression for me.
> >
> > Will try reverting that commit tomorrow.
>
> If that fails, please try to bisect, it will help us a lot.

Commit bf0dea23a9c0 is working OK with no revert needed (checked out
this revision and it tested OK).

So far I know that the breakage seems to have happened between
cadbb58039f7cab1def9c931012ab04c953a6997 (first sparc commit of
the batch, working OK on V100) and
bdcf81b658ebc4c2640c3c2c55c8b31c601b6996 (last sparc commit before the
merge, breaks on E3500). Will continue bisecting the sparc64 commits.

Also, I noticed that when the problem happens, it's deterministic - with
some kernels, sshd dies reproducibly on login. With most kernels,
building kernel breaks in one specific location, not randomly.

scripts/Makefile.build:352: recipe for target 'sound/modules.order' failed
make[1]: *** [sound/modules.order] Bus error
make[1]: *** Deleting file 'sound/modules.order'
Makefile:929: recipe for target 'sound' failed

Will tell when I get more details.

--
Meelis Roos (mroos@xxxxxxxx)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/