linux-kernel - Re: [BUG] in 2.6.25-rc3 with 64k page size and SLUB_DEBUG

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <84144f020803061327r2310b23ew6211bc09f9ba25a3@mail.gmail.com>
Date:	Thu, 6 Mar 2008 23:27:37 +0200
From:	"Pekka Enberg" <penberg@...helsinki.fi>
To:	"Jens Osterkamp" <Jens.Osterkamp@....de>
Cc:	"Christoph Lameter" <clameter@....com>, linux-mm@...ck.org,
	"Ingo Molnar" <mingo@...e.hu>,
	"Linux kernel mailing list" <linux-kernel@...r.kernel.org>
Subject: Re: [BUG] in 2.6.25-rc3 with 64k page size and SLUB_DEBUG_ON

Hi,

On Thu, Mar 6, 2008 at 3:47 PM, Jens Osterkamp <Jens.Osterkamp@....de> wrote:
>  when booting 2.6.25-rc3 on powerpc64 with SLUB_DEBUG_ON and 64k page size, it drops into xmon
>  during boot with the following :
>
>  Console: colour dummy device 80x25
>  Dentry cache hash table entries: 262144 (order: 5, 2097152 bytes)
>  Inode-cache hash table entries: 131072 (order: 4, 1048576 bytes)
>  freeing bootmem node 0
>  freeing bootmem node 1
>  Memory: 2037184k/2097152k available (4864k kernel code, 59968k reserved, 768k data, 419k bss, 384k init)
>  SLUB: Genslabs=17, HWalign=128, Order=0-2, MinObjects=8, CPUs=4, Nodes=16
>  Mount-cache hash table entries: 4096
>  BUG: scheduling while atomic: kthreadd/2/0x00056ef8
>  Call Trace:
>  [c00000003c187b68] [c00000000000f140] .show_stack+0x70/0x1bc (unreliable)
>  [c00000003c187c18] [c000000000052d0c] .__schedule_bug+0x64/0x80
>  [c00000003c187ca8] [c00000000036fa84] .schedule+0xc4/0x6b0
>  [c00000003c187d98] [c0000000003702d0] .schedule_timeout+0x3c/0xe8
>  [c00000003c187e68] [c00000000036f82c] .wait_for_common+0x150/0x22c
>  [c00000003c187f28] [c000000000074868] .kthreadd+0x12c/0x1f0
>  [c00000003c187fd8] [c000000000024864] .kernel_thread+0x4c/0x68
>  ------------[ cut here ]------------
>  kernel BUG at /home/auto/jens/kernels/linux-2.6.25-rc3/kernel/sched.c:4532!
>  cpu 0x0: Vector: 700 (Program Check) at [c00000003c187bc8]
>     pc: c000000000051f8c: .sched_setscheduler+0x5c/0x48c
>     lr: c0000000000748b0: .kthreadd+0x174/0x1f0
>     sp: c00000003c187e48
>    msr: 9000000000029032
>   current = 0xc00000007e0808a0
>   paca    = 0xc0000000004cf880
>     pid   = 2, comm = kthreadd
>  kernel BUG at /home/auto/jens/kernels/linux-2.6.25-rc3/kernel/sched.c:4532!
>  enter ? for help
>  [c00000003c187f28] c0000000000748b0 .kthreadd+0x174/0x1f0
>  [c00000003c187fd8] c000000000024864 .kernel_thread+0x4c/0x68
>  0:mon>
>
>  In the code this corresponds to
>
>  int sched_setscheduler(struct task_struct *p, int policy,
>                        struct sched_param *param)
>  {
>         int retval, oldprio, oldpolicy = -1, on_rq, running;
>         unsigned long flags;
>         const struct sched_class *prev_class = p->sched_class;
>         struct rq *rq;
>
>         /* may grab non-irq protected spin_locks */
>         BUG_ON(in_interrupt());
>  recheck:
>         /* double check policy once rq lock held */
>         if (policy < 0)
>                 policy = oldpolicy = p->policy;
>         else if (policy != SCHED_FIFO && policy != SCHED_RR &&
>                         policy != SCHED_NORMAL && policy != SCHED_BATCH &&
>                         policy != SCHED_IDLE)
>                 return -EINVAL;
>
>  With slub_debug=- on the kernel command line, the problem is gone.
>  With 4k page size the problem also does not occur.
>
>  Any ideas on why this occurs and how to debug this further ?

There's no SLUB in the stack traces. Ingo, any suggestions how to debug this?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/