linux-kernel - Re: [BUG] linux-next: Tree for August 26

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] [day] [month] [year] [list]

Message-Id: <200808281714.m7SHEdCX096569@sullivan.realtime.net>
Date:	Thu, 28 Aug 2008 12:14:39 -0500 (CDT)
From:	Milton Miller <miltonm@....com>
To:	David Woodhouse <dwmw2@...radead.org>
Cc:	LKML <linux-kernel@...r.kernel.org>,
	Stephen Rothwell <sfr@...b.auug.org.au>,
	Kamalesh Babulal <kamalesh@...ux.vnet.ibm.com>,
	linuxppc-dev@...abs.org, linux-next@...r.kernel.org, mingo@...e.hu,
	Arjan van de Ven <arjan@...ux.intel.com>
Subject: Re: [BUG] linux-next: Tree for August 26 - Badness at kernel/notifier.c:25 


David Woodhouse dwmw2 at infradead.org
Fri Aug 29 00:55:07 EST 2008

> On Thu, 2008-08-28 at 15:23 +0100, David Woodhouse wrote:
>> On Thu, 2008-08-28 at 00:38 +1000, Stephen Rothwell wrote:
>>> Hi Arjan,
>>> 
>>> On Thu, 28 Aug 2008 00:33:08 +1000 Stephen Rothwell <sfr at canb.auug.org.au> wrote:
>>>>
>>>> The original reported trace was during setup_system which is very early in
>>>> the boot.
>>> 
>>> But, of course, that version didn't have the necessary extra dereference
>>> of the function address ...
>>> 
>>> And the later debug patch did not check the address at register time,
>>> only at notify time.
>>> 
>>> The later trace also looks to be early in the boot.
>> 
>> It's isa_bridge_notify(), which is neither within _[se]text nor
>> _[se]inittext, so the core_kernel_text() function disavows it.
>> 
>> Where are __devinit functions supposed to end up?
> 
> The TEXT_TEXT macro defined in <asm-generic/vmlinux.lds.h> should get
> this right... but we don't use it. Is there any particular reason for
> that, or should we....

gitk -- arch/powerpc/kernel/vmlinux.S

	e95c91821fa56b489d7beb74103a419466c5ec10
	[POWERPC] Fix link errors for allyesconfig
    
    An allyesconfig build creates a .text section that is so big that the
    .text.init.refok and .fixup sections are too far away for the relocations
    to be fixed up correctly. This patch fixes that by linking all the
    relevent text sections for each file together.
    
    Suggested by Paul Mackerras.
    
    Signed-off-by: Stephen Rothwell <sfr@...b.auug.org.au>
    Signed-off-by: Paul Mackerras <paulus@...ba.org>


Although I think its really fac23fe4be23259a8eaa9bad822f5b14dd07d15c 
powerpc: Introduce infrastructure for feature sections with alternatives
that causes the problems.

If the problem is only reaching the branch-out-of-fixup-section, then
we could create a macro that caculates the branch as if it were already
at the destination address (using something like

	b (target-fixup_start)-(current-alternative_start)

and then removing the code that determines the branch target goes beyond
the feature section.

Just a concept, have't tried it yet and don't know if there are other
problems with .text.init.refok.

Or we fix our defintion and put a comment next to TEXT_TEXT that we
don't use it for future editors.

> 
> Signed-off-by: David Woodhouse <David.Woodhouse at intel.com>
> 
> --- linux-2.6.26.ppc64/arch/powerpc/kernel/vmlinux.lds.S~	2008-07-13 22:51:29.000000000 +0100
> +++ linux-2.6.26.ppc64/arch/powerpc/kernel/vmlinux.lds.S	2008-08-28 15:39:14.000000000 +0100
> @@ -35,10 +35,11 @@ SECTIONS
>  		ALIGN_FUNCTION();
>  		*(.text.head)
>  		_text = .;
> -		*(.text .fixup .text.init.refok .exit.text.refok)
> +		TEXT_TEXT
>  		SCHED_TEXT
>  		LOCK_TEXT
>  		KPROBES_TEXT
> +		*(.fixup)
>  
>  #ifdef CONFIG_PPC32
>  		*(.got1)
> 
> -- 
> David Woodhouse                            Open Source Technology Centre
> David.Woodhouse at intel.com                              Intel Corporation
--
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/