linux-kernel - Re: [xen] double fault: 0000 [#1] PREEMPT SMP 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-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 8 Oct 2013 23:14:17 +0100
From:	Russell King - ARM Linux <linux@....linux.org.uk>
To:	Fengguang Wu <fengguang.wu@...el.com>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	xen-devel@...ts.xenproject.org,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Subject: Re: [xen] double fault: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC

On Tue, Oct 08, 2013 at 08:17:42PM +0800, Fengguang Wu wrote:
> I find the above debug messages very helpful in locating the buggy
> driver. How about enabling it whenever CONFIG_DEBUG_KOBJECT_RELEASE is
> enabled? Something like
> 
>  #ifdef CONFIG_DEBUG_KOBJECT_RELEASE
> -       pr_debug("kobject: '%s' (%p): %s, parent %p (delayed)\n",
> +       printk(KERN_INFO "kobject: '%s' (%p): %s, parent %p (delayed)\n",
>                  kobject_name(kobj), kobj, __func__, kobj->parent);
> 
> pr_debug() won't be displayed by default, and it depends on
> CONFIG_DYNAMIC_DEBUG.

Please consider using pr_info() instead of printk(KERN_INFO - it's
slightly less typing.

I can see that being a useful change while we have these problematical
instances to track down, but I do wonder whether it'll make the thing
too noisy.  Does anyone have other opinions on this point?  Linus?
Greg?
--
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/