Skip to contentSkip to conversation

linux-next: Tree for April 9

PATCH In review Stephen Rothwell 7 participants 28 messages Apr 9, 2008 – Apr 11, 2008 1 message not in the archive

Subsystems (3)
Documentation Library code Firewire
lore
Share & tools
lore

Stephen Rothwell

author
#0 lore raw

Hi all,

I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/sfr/linux-next.git
(tar balls at
http://www.kernel.org/pub/linux/kernel/people/sfr/linux-next/).

You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc and an allmodconfig for x86_64.

There were a few merge conflicts (fairly trivial) and couple of build failures (notified). There is a know build failure with powerpc allyesconfig. Below is a summary of the state of the merge.

We are up to 55 trees, more are welcome (even if they are currently empty). Thanks to those who have contributed, and to those who haven't, please do.

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next. If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds.

Thanks to Jan Dittmer for adding the linux-next tree to his build tests at http://l4x.org/k/ and the guys at http://test.kernel.org/.

Signature · 94 lines
Cheers,
Stephen Rothwell                    [email protected]

Merging origin/master
Merging x86-fixes/for-linus
Merging sched-fixes/for-linus
Merging powerpc-merge/merge
Merging scsi-rc-fixes/master
Merging quilt/driver-core
Merging quilt/pci
Merging quilt/usb
Merging x86/for-akpm
Created commit 11876f8: Revert "x86: phase out forced inlining"
Merging sched/for-akpm
Merging quilt/device-mapper
Merging hid/mm
Merging quilt/i2c
Merging quilt/kernel-doc
Merging avr32/avr32-arch
Merging v4l-dvb/stable
Merging s390/features
Merging sh/master
Merging jfs/next
Merging kbuild/master
Merging quilt/ide
CONFLICT (content): Merge conflict in Documentation/ide/ide.txt
CONFLICT (content): Merge conflict in Documentation/kernel-parameters.txt
CONFLICT (content): Merge conflict in drivers/ide/ide.c
CONFLICT (content): Merge conflict in include/asm-x86/ide.h
CONFLICT (content): Merge conflict in include/linux/Kbuild
Merging libata/NEXT
Applying libata-fix-1.patch
Merging nfs/linux-next
Merging xfs/master
Merging infiniband/for-next
CONFLICT (content): Merge conflict in drivers/infiniband/hw/amso1100/c2_provider.c
CONFLICT (content): Merge conflict in drivers/infiniband/hw/cxgb3/iwch_provider.c
CONFLICT (content): Merge conflict in drivers/infiniband/hw/nes/nes_verbs.c
Applying infiniband-fix-2
Merging acpi/test
CONFLICT (content): Merge conflict in arch/x86/kernel/setup_64.c
CONFLICT (delete/modify): arch/x86/kernel/smpboot_64.c deleted in HEAD and modified in acpi/test. Version acpi/test of arch/x86/kernel/smpboot_64.c left in tree.
CONFLICT (delete/modify): include/asm-x86/smp_64.h deleted in HEAD and modified in acpi/test. Version acpi/test of include/asm-x86/smp_64.h left in tree.
$ git rm arch/x86/kernel/smpboot_64.c include/asm-x86/smp_64.h
Applying acpi-fix-1.patch
Applying acpi-fix-2.patch
Merging blackfin/for-linus
Merging nfsd/nfsd-next
Merging ieee1394/for-next
CONFLICT (content): Merge conflict in lib/Kconfig.debug
Merging hwmon/testing
Merging ubi/master
Merging kvm/master
CONFLICT (add/add): Merge conflict in include/asm-s390/sysinfo.h
CONFLICT (content): Merge conflict in include/asm-x86/kvm_host.h
Merging dlm/next
Merging scsi/master
Merging ia64/test
CONFLICT (content): Merge conflict in arch/ia64/mm/tlb.c
Merging tests/master
CONFLICT (content): Merge conflict in lib/Kconfig.debug
Merging ocfs2/linux-next
Merging selinux/for-akpm
Merging quilt/m68k
Merging powerpc/powerpc-next
Merging hrt/mm
Merging lblnet/master
Merging ext4/next
CONFLICT (content): Merge conflict in fs/jbd2/journal.c
CONFLICT (content): Merge conflict in fs/jbd2/revoke.c
Merging 4xx/next
Merging async_tx/next
Merging udf/for_next
Merging security-testing/next
Merging net/master
CONFLICT (content): Merge conflict in Documentation/feature-removal-schedule.txt
CONFLICT (content): Merge conflict in MAINTAINERS
Merging galak/powerpc-next
Merging mtd/master
Merging wireless/master
Merging crypto/master
Merging vfs/vfs-2.6.25
CONFLICT (content): Merge conflict in fs/xfs/linux-2.6/xfs_ioctl.c
CONFLICT (content): Merge conflict in fs/xfs/xfs_ialloc.c
CONFLICT (content): Merge conflict in fs/xfs/xfs_sb.h
Merging semaphore/semaphore
CONFLICT (delete/modify): include/asm-x86/semaphore_32.h deleted in semaphore/semaphore and modified in HEAD. Version HEAD of include/asm-x86/semaphore_32.h left in tree.
CONFLICT (delete/modify): include/asm-x86/semaphore_64.h deleted in semaphore/semaphore and modified in HEAD. Version HEAD of include/asm-x86/semaphore_64.h left in tree.
$ git rm include/asm-x86/semaphore_32.h include/asm-x86/semaphore_64.h
Merging quilt/ldp
Created commit 1d2b198: Revert "wusb: add the wireless usb stack to Linux"
Applying parport_pc: wrap PNP probe code in #ifdef CONFIG_PNP
Applying nsc-ircc: wrap PNP probe code in #ifdef CONFIG_PNP
Applying smsc-ircc2: wrap PNP probe code in #ifdef CONFIG_PNP

A message that is not in the archive (sent off-list or not yet received): [email protected]

author
#2 lore raw

Hi Jacek,

Quoted 17 lines · On Wed, 9 Apr 2008 13:00:37 +0200 "Jacek Luczak" <[email protected]>…

this tree fails to compile on my box with message:
CC init/version.o
arch/x86/kernel/traps_32.c: In function 'do_general_protection':
arch/x86/kernel/traps_32.c:647: error: 'VM_MASK' undeclared (first use in this function)
arch/x86/kernel/traps_32.c:647: error: (Each undeclared identifier is reported only once
arch/x86/kernel/traps_32.c:647: error: for each function it appears in.) arch/x86/kernel/traps_32.c: In function 'do_debug':
arch/x86/kernel/traps_32.c:926: error: 'VM_MASK' undeclared (first use in this function)
arch/x86/kernel/traps_32.c: In function 'do_simd_coprocessor_error':
arch/x86/kernel/traps_32.c:1098: error: 'VM_MASK' undeclared (first use in this function)

GCC version:

Quoted 11 lines
$ gcc -v
Reading specs from /usr/lib/gcc/i686-slackware-linux/4.2.2/specs
Target: i686-slackware-linux
Configured with: ../gcc-4.2.2/configure --prefix=/usr --enable-shared
--enable-threads=posix --enable-__cxa_atexit --disable-checking
--with-gnu-ld --enable-languages=c,c++ --enable-clocale=gnu --verbose
--disable-multilib --with-tune=prescott --disable-libstdcxx-pch
--disable-bootstrap --target=i686-slackware-linux
--host=i686-slackware-linux
Thread model: posix
gcc version 4.2.2

Thanks for the report, can you please send us your .config, please?

Signature · 3 lines
Cheers,
Stephen Rothwell                    [email protected]
http://www.canb.auug.org.au/~sfr/
author
#3 lore raw

Hi Jacek,

Quoted 2 lines · On Wed, 9 Apr 2008 21:09:36 +1000 Stephen Rothwell <[email protected]> wrote:

Thanks for the report, can you please send us your .config, please?

Don't worry about it, I found the problem.

It seems that commit 883a9fc4e5d9b0701f15d4e5a23608f942104721 ("x86:
cleanup - rename VM_MASK to X86_VM_MASK") from the x86 tree seems to have missed some places.

Signature · 3 lines
Cheers,
Stephen Rothwell                    [email protected]
http://www.canb.auug.org.au/~sfr/
#4 lore raw

Stephen Rothwell pisze:

Quoted 11 lines

Hi Jacek,

Quoted 1 line · On Wed, 9 Apr 2008 21:09:36 +1000 Stephen Rothwell <[email protected]> wrote:

Thanks for the report, can you please send us your .config, please?

Don't worry about it, I found the problem.

It seems that commit 883a9fc4e5d9b0701f15d4e5a23608f942104721 ("x86:
cleanup - rename VM_MASK to X86_VM_MASK") from the x86 tree seems to have missed some places.

Yep, I did the same. You can find patch, which renames changes VM_MASK to X86_VM_MASK across all files in arch/x86/kernel, here: http://pin.if.uz.zgora.pl/~difrost/linux-next/09042008/

-Jacek

#5 lore raw
Quoted 9 lines · Jacek Luczak
Quoted 5 lines

Don't worry about it, I found the problem.

It seems that commit 883a9fc4e5d9b0701f15d4e5a23608f942104721 ("x86:
cleanup - rename VM_MASK to X86_VM_MASK") from the x86 tree seems to have missed some places.

Yep, I did the same. You can find patch, which renames changes VM_MASK to X86_VM_MASK across all files in arch/x86/kernel, here:
http://pin.if.uz.zgora.pl/~difrost/linux-next/09042008/

ah, that again comes from x86/for-akpm missing a patch that comes later in x86/latest. I'll resort it.

Ingo

#6 lore raw

Ingo Molnar pisze:

Quoted 8 lines · Jacek Luczak
Quoted 5 lines
Quoted 4 lines

Don't worry about it, I found the problem.

It seems that commit 883a9fc4e5d9b0701f15d4e5a23608f942104721 ("x86: cleanup - rename VM_MASK to X86_VM_MASK") from the x86 tree seems to have missed some places.

Yep, I did the same. You can find patch, which renames changes VM_MASK to X86_VM_MASK across all files in arch/x86/kernel, here: http://pin.if.uz.zgora.pl/~difrost/linux-next/09042008/

ah, that again comes from x86/for-akpm missing a patch that comes later in x86/latest. I'll resort it.

X86_VM_MASK was already changed in one place in kernel/traps_32.c:
arch/x86/kernel/traps_32.c:502: if (regs->flags & X86_VM_MASK) {
and in mm/fault.c:
if (regs->flags & (X86_EFLAGS_IF | X86_VM_MASK))

-Jacek

#8 lore raw
In reply to Stephen Rothwell
Quoted 11 lines · Stephen Rothwell

Hi Jacek,

Quoted 2 lines · On Wed, 9 Apr 2008 21:09:36 +1000 Stephen Rothwell <[email protected]> wrote:

Thanks for the report, can you please send us your .config, please?

Don't worry about it, I found the problem.

It seems that commit 883a9fc4e5d9b0701f15d4e5a23608f942104721 ("x86:
cleanup - rename VM_MASK to X86_VM_MASK") from the x86 tree seems to have missed some places.

i think what happened is that some changes came in from other trees that reintroduced the old symbols?

if that's the case i'll add back the old symbol names to make the transition and integration easier.

Ingo

#9 lore raw

[Ingo Molnar - Wed, Apr 09, 2008 at 01:31:09PM +0200]

| 
| * Stephen Rothwell <[email protected]> wrote:
| 
| > Hi Jacek,
| > 
| > On Wed, 9 Apr 2008 21:09:36 +1000 Stephen Rothwell <[email protected]> wrote:
| > >
| > > Thanks for the report, can you please send us your .config, please?
| > 
| > Don't worry about it, I found the problem.
| > 
| > It seems that commit 883a9fc4e5d9b0701f15d4e5a23608f942104721 ("x86: 
| > cleanup - rename VM_MASK to X86_VM_MASK") from the x86 tree seems to 
| > have missed some places.
| 
| i think what happened is that some changes came in from other trees that 
| reintroduced the old symbols?

actually, that is the only explanation I could find. The last time I sent you patches to fixup *all* VM_MASK (wich were grep'ed on *latest branch over *all* sources inside x86). So this all were settled down by a few of my patches and /for shame on me/ yours fixups. So these fixups were missed on merging.

| 
| if that's the case i'll add back the old symbol names to make the 
| transition and integration easier.
| 
| 	Ingo
|

- Cyrill -

#10 lore raw
Quoted 7 lines · Cyrill Gorcunov
| > It seems that commit 883a9fc4e5d9b0701f15d4e5a23608f942104721 
| > ("x86: cleanup - rename VM_MASK to X86_VM_MASK") from the x86 tree 
| > seems to have missed some places.
| 
| i think what happened is that some changes came in from other trees 
| that reintroduced the old symbols?
Quoted 5 lines

actually, that is the only explanation I could find. The last time I sent you patches to fixup *all* VM_MASK (wich were grep'ed on *latest branch over *all* sources inside x86). So this all were settled down by a few of my patches and /for shame on me/ yours fixups. So these fixups were missed on merging.

no, the problem turned out to be that i kept those fixes too spread out, and part of them went into the x86/for-akpm portion of the tree, part of it went into x86/testing. Since all x86 developers work against x86/testing this was never a problem - only now did it become one when i shuffled patches and branch boundaries around. Such problems will go away once linux-next starts using x86/testing as well. In any case i moved your fixes together and fixed up the patch ordering as well.

Ingo

#11 lore raw

[Ingo Molnar - Wed, Apr 09, 2008 at 05:03:33PM +0200]

| 
| * Cyrill Gorcunov <[email protected]> wrote:
| 
| > | > It seems that commit 883a9fc4e5d9b0701f15d4e5a23608f942104721 
| > | > ("x86: cleanup - rename VM_MASK to X86_VM_MASK") from the x86 tree 
| > | > seems to have missed some places.
| > | 
| > | i think what happened is that some changes came in from other trees 
| > | that reintroduced the old symbols?
| > 
| > actually, that is the only explanation I could find. The last time I 
| > sent you patches to fixup *all* VM_MASK (wich were grep'ed on *latest 
| > branch over *all* sources inside x86). So this all were settled down 
| > by a few of my patches and /for shame on me/ yours fixups. So these 
| > fixups were missed on merging.
| 
| no, the problem turned out to be that i kept those fixes too spread out, 
| and part of them went into the x86/for-akpm portion of the tree, part of 
| it went into x86/testing. Since all x86 developers work against 
| x86/testing this was never a problem - only now did it become one when i 
| shuffled patches and branch boundaries around. Such problems will go 
| away once linux-next starts using x86/testing as well. In any case i 
| moved your fixes together and fixed up the patch ordering as well.
| 
| 	Ingo
|

ok, i see, thanks

- Cyrill -

#12 lore raw
In reply to Stephen Rothwell
Quoted 3 lines · Stephen Rothwell

There were a few merge conflicts (fairly trivial) and couple of build failures (notified). There is a know build failure with powerpc allyesconfig. Below is a summary of the state of the merge.

...

Quoted 2 lines

Merging ieee1394/for-next
CONFLICT (content): Merge conflict in lib/Kconfig.debug

Would it be safe for me (and preferred by you) to merge sched/for-akpm into ieee1394/for-next to resolve this conflict until next mainline merge?

Signature · 3 lines
Stefan Richter
-=====-==--- -=-- -=--=
http://arcgraph.de/sr/
author
#13 lore raw

Hi Stefan,

Quoted 11 lines · On Wed, 09 Apr 2008 18:55:42 +0200 Stefan Richter <[email protected]>…
Quoted 3 lines · Stephen Rothwell

There were a few merge conflicts (fairly trivial) and couple of build failures (notified). There is a know build failure with powerpc allyesconfig. Below is a summary of the state of the merge.

...

Quoted 2 lines

Merging ieee1394/for-next
CONFLICT (content): Merge conflict in lib/Kconfig.debug

Would it be safe for me (and preferred by you) to merge sched/for-akpm into ieee1394/for-next to resolve this conflict until next mainline merge?

Actually, no, as sched/for-akpm gets rebased sometimes. I only have to fix these trivial conflicts once as "git rerere" remembers the fix for me and they are so trivial that Linus will probably fix them the same way when he finally merges your tree. Also, there is the possibility that he will merge your tree before sched/for-akpm ...

Signature · 3 lines
Cheers,
Stephen Rothwell                    [email protected]
http://www.canb.auug.org.au/~sfr/
#14 lore raw
In reply to Stefan Richter
Quoted 11 lines · Stefan Richter
Quoted 3 lines · Stephen Rothwell

There were a few merge conflicts (fairly trivial) and couple of build failures (notified). There is a know build failure with powerpc allyesconfig. Below is a summary of the state of the merge.

...

Quoted 2 lines

Merging ieee1394/for-next
CONFLICT (content): Merge conflict in lib/Kconfig.debug

Would it be safe for me (and preferred by you) to merge sched/for-akpm into ieee1394/for-next to resolve this conflict until next mainline merge?

what type of conflict do you have there? If it's a new entry then you might be able to fix it by moving the new entry elsewhere in the file. Or if i introduced a new entry close to an existing entry you modify then i could move my new entry elsewhere.

Ingo

author
#15 lore raw
Quoted 5 lines · On Thu, 10 Apr 2008 08:52:27 +0200 Ingo Molnar <[email protected]> wrote:

what type of conflict do you have there? If it's a new entry then you might be able to fix it by moving the new entry elsewhere in the file. Or if i introduced a new entry close to an existing entry you modify then i could move my new entry elsewhere.

Commit 523a65f1a7a339e528ca6d6d808516fe195fde03 ("firewire: fw-ohci: add option for remote debugging") in the ieee1394 tree adds a new entry just where the sched tree adds

source kernel/trace/Kconfig

Signature · 3 lines
Cheers,
Stephen Rothwell                    [email protected]
http://www.canb.auug.org.au/~sfr/
#16 lore raw

debug Kconfig option (was Re: linux-next: Tree for April 9)

Quoted 7 lines · Stephen Rothwell
Quoted 5 lines · On Thu, 10 Apr 2008 08:52:27 +0200 Ingo Molnar <[email protected]> wrote:

what type of conflict do you have there? If it's a new entry then you might be able to fix it by moving the new entry elsewhere in the file. Or if i introduced a new entry close to an existing entry you modify then i could move my new entry elsewhere.

Quoted 6 lines

Commit 523a65f1a7a339e528ca6d6d808516fe195fde03 ("firewire: fw-ohci: add option for remote debugging") in the ieee1394 tree adds a new entry just where the sched tree adds

source kernel/trace/Kconfig

I grab this opportunity to ask the list: Would you prefer the remote debugging option in the kernel hacking menu (as in the commit), or rather in the respective driver submenu?

For reference:

Date: Thu, 28 Feb 2008 20:54:43 +0100 (CET)
From: Stefan Richter <[email protected]>
Subject: firewire: fw-ohci: add option for remote debugging

This way firewire-ohci can be used for remote debugging like ohci1394.

Signed-off-by Stefan Richter <[email protected]>
---
 Documentation/debugging-via-ohci1394.txt |   13 ++++++++-----
 drivers/firewire/fw-ohci.c               |    9 +++++++++
 lib/Kconfig.debug                        |   10 ++++++++++
 3 files changed, 27 insertions(+), 5 deletions(-)
Documentation/debugging-via-ohci1394.txt +8 -5
Index: linux/Documentation/debugging-via-ohci1394.txt
===================================================================
@@ -41,11 +41,14 @@ to a working state and enables physical 
 This can be turned off by ohci1394's module parameter phys_dma=0.
 
 The alternative firewire-ohci driver in drivers/firewire uses filtered physical
-DMA, hence is not yet suitable for remote debugging.
-
-Because ohci1394 depends on the PCI enumeration to be completed, an
-initialization routine which runs pretty early (long before console_init()
-which makes the printk buffer appear on the console can be called) was written.
+DMA by default, which is more secure but not suitable for remote debugging.
+Compile the driver with CONFIG_FIREWIRE_OHCI_REMOTE_DMA to get unfiltered
+physical DMA.
+
+Because ohci1394 and firewire-ohci depend on the PCI enumeration to be
+completed, an initialization routine which runs pretty early has been
+implemented for x86.  This routine runs long before console_init() can be
+called, i.e. before the printk buffer appears on the console.
 
 To activate it, enable CONFIG_PROVIDE_OHCI1394_DMA_INIT (Kernel hacking menu:
 Provide code for enabling DMA over FireWire early on boot) and pass the
drivers/firewire/fw-ohci.c +9 -0
Index: linux/drivers/firewire/fw-ohci.c
===================================================================
@@ -1097,6 +1097,11 @@ static void bus_reset_tasklet(unsigned l
 		reg_write(ohci, OHCI1394_ConfigROMhdr, ohci->next_header);
 	}
 
+#ifdef CONFIG_FIREWIRE_OHCI_REMOTE_DMA
+	reg_write(ohci, OHCI1394_PhyReqFilterHiSet, ~0);
+	reg_write(ohci, OHCI1394_PhyReqFilterLoSet, ~0);
+#endif
+
 	spin_unlock_irqrestore(&ohci->lock, flags);
 
 	if (free_rom)

@@ -1435,6 +1440,9 @@ static int ohci_cancel_packet(struct fw_
 static int
 ohci_enable_phys_dma(struct fw_card *card, int node_id, int generation)
 {
+#ifdef CONFIG_FIREWIRE_OHCI_REMOTE_DMA
+	return 0;
+#else
 	struct fw_ohci *ohci = fw_ohci(card);
 	unsigned long flags;
 	int n, retval = 0;

@@ -1466,6 +1474,7 @@ ohci_enable_phys_dma(struct fw_card *car
  out:
 	spin_unlock_irqrestore(&ohci->lock, flags);
 	return retval;
+#endif /* CONFIG_FIREWIRE_OHCI_REMOTE_DMA */
 }
 
 static u64
lib/Kconfig.debug +10 -0
Index: linux/lib/Kconfig.debug
===================================================================
@@ -592,6 +592,16 @@ config LATENCYTOP
 	  Enable this option if you want to use the LatencyTOP tool
 	  to find out which userspace is blocking on what kernel operations.
 
+config FIREWIRE_OHCI_REMOTE_DMA
+	bool "Remote debugging via firewire-ohci"
+	depends on FIREWIRE_OHCI
+	help
+	  This option lets you use the FireWire bus for remote debugging.
+	  It enables unfiltered remote DMA in the firewire-ohci driver.
+	  See Documentation/debugging-via-ohci1394.txt for more information.
+
+	  If unsure, say N.
+
 config PROVIDE_OHCI1394_DMA_INIT
 	bool "Provide code for enabling DMA over FireWire early on boot"
 	depends on PCI && X86
Signature · 3 lines
Stefan Richter
-=====-==--- -=-- -=-=-
http://arcgraph.de/sr/
#17 lore raw

Re: debug Kconfig option (was Re: linux-next: Tree for April 9)

Quoted 9 lines · Stefan Richter
Quoted 5 lines

Commit 523a65f1a7a339e528ca6d6d808516fe195fde03 ("firewire: fw-ohci:
add option for remote debugging") in the ieee1394 tree adds a new entry just where the sched tree adds

source kernel/trace/Kconfig

I grab this opportunity to ask the list: Would you prefer the remote debugging option in the kernel hacking menu (as in the commit), or rather in the respective driver submenu?

it's great stuff! I very much think it's fine in lib/Kconfig.debug - we need prominence of debugging options. (they are used way too infrequently)

My only suggestion would be to move the new entry below the existing firewire entry (PROVIDE_OHCI1394_DMA_INIT) there - which also happens to avoid this particular merge conflict.

Ingo

#18 lore raw

PATCH 1/1 firewire: fw-ohci: add option for remote debugging - amendment

Some afterthoughts:

- Tell where the Kconfig prompt is in debugging-via-ohci1394.txt.

- Open the physical DMA filter in the top half of the IRQ handler and flush the necessary MMIO writes. This is to open the filter as soon as possible after bus reset.

- Move the Kconfig prompt below the existing early debugging option. Seems more logical after all, because that one is for early use and this one for subsequent use.

- Reword the existing early debugging option to state what it is for rather than how it works internally.

Signed-off-by Stefan Richter <[email protected]>

---

This could be merged into patch "firewire: fw-ohci: add option for remote debugging" before it is submitted to mainline.

 Documentation/debugging-via-ohci1394.txt |    9 +++++----
 drivers/firewire/fw-ohci.c               |   13 +++++++------
 lib/Kconfig.debug                        |   23 ++++++++++++-----------
 3 files changed, 24 insertions(+), 21 deletions(-)
Documentation/debugging-via-ohci1394.txt +5 -4
Index: linux/Documentation/debugging-via-ohci1394.txt
===================================================================
@@ -42,8 +42,9 @@ This can be turned off by ohci1394's mod
 
 The alternative firewire-ohci driver in drivers/firewire uses filtered physical
 DMA by default, which is more secure but not suitable for remote debugging.
-Compile the driver with CONFIG_FIREWIRE_OHCI_REMOTE_DMA to get unfiltered
-physical DMA.
+Compile the driver with CONFIG_FIREWIRE_OHCI_REMOTE_DMA (Kernel hacking menu:
+Remote debugging over FireWire with firewire-ohci) to get unfiltered physical
+DMA.
 
 Because ohci1394 and firewire-ohci depend on the PCI enumeration to be
 completed, an initialization routine which runs pretty early has been

@@ -51,8 +52,8 @@ implemented for x86.  This routine runs 
 called, i.e. before the printk buffer appears on the console.
 
 To activate it, enable CONFIG_PROVIDE_OHCI1394_DMA_INIT (Kernel hacking menu:
-Provide code for enabling DMA over FireWire early on boot) and pass the
-parameter "ohci1394_dma=early" to the recompiled kernel on boot.
+Remote debugging over FireWire early on boot) and pass the parameter
+"ohci1394_dma=early" to the recompiled kernel on boot.
 
 Tools
 -----
drivers/firewire/fw-ohci.c +7 -6
Index: linux/drivers/firewire/fw-ohci.c
===================================================================
@@ -1309,11 +1309,6 @@ static void bus_reset_tasklet(unsigned l
 		reg_write(ohci, OHCI1394_ConfigROMhdr, ohci->next_header);
 	}
 
-#ifdef CONFIG_FIREWIRE_OHCI_REMOTE_DMA
-	reg_write(ohci, OHCI1394_PhyReqFilterHiSet, ~0);
-	reg_write(ohci, OHCI1394_PhyReqFilterLoSet, ~0);
-#endif
-
 	spin_unlock_irqrestore(&ohci->lock, flags);
 
 	if (free_rom)

@@ -1341,8 +1336,14 @@ static irqreturn_t irq_handler(int irq, 
 	reg_write(ohci, OHCI1394_IntEventClear, event & ~OHCI1394_busReset);
 	log_irqs(event);
 
-	if (event & OHCI1394_selfIDComplete)
+	if (event & OHCI1394_selfIDComplete) {
+#ifdef CONFIG_FIREWIRE_OHCI_REMOTE_DMA
+		reg_write(ohci, OHCI1394_PhyReqFilterHiSet, ~0);
+		reg_write(ohci, OHCI1394_PhyReqFilterLoSet, ~0);
+		flush_writes(ohci);
+#endif
 		tasklet_schedule(&ohci->bus_reset_tasklet);
+	}
 
 	if (event & OHCI1394_RQPkt)
 		tasklet_schedule(&ohci->ar_request_ctx.tasklet);
lib/Kconfig.debug +12 -11
Index: linux/lib/Kconfig.debug
===================================================================
@@ -592,18 +592,8 @@ config LATENCYTOP
 	  Enable this option if you want to use the LatencyTOP tool
 	  to find out which userspace is blocking on what kernel operations.
 
-config FIREWIRE_OHCI_REMOTE_DMA
-	bool "Remote debugging via firewire-ohci"
-	depends on FIREWIRE_OHCI
-	help
-	  This option lets you use the FireWire bus for remote debugging.
-	  It enables unfiltered remote DMA in the firewire-ohci driver.
-	  See Documentation/debugging-via-ohci1394.txt for more information.
-
-	  If unsure, say N.
-
 config PROVIDE_OHCI1394_DMA_INIT
-	bool "Provide code for enabling DMA over FireWire early on boot"
+	bool "Remote debugging over FireWire early on boot"
 	depends on PCI && X86
 	help
 	  If you want to debug problems which hang or crash the kernel early

@@ -631,4 +621,15 @@ config PROVIDE_OHCI1394_DMA_INIT
 
 	  See Documentation/debugging-via-ohci1394.txt for more information.
 
+config FIREWIRE_OHCI_REMOTE_DMA
+	bool "Remote debugging over FireWire with firewire-ohci"
+	depends on FIREWIRE_OHCI
+	help
+	  This option lets you use the FireWire bus for remote debugging
+	  with help of the firewire-ohci driver. It enables unfiltered
+	  remote DMA in firewire-ohci.
+	  See Documentation/debugging-via-ohci1394.txt for more information.
+
+	  If unsure, say N.
+
 source "samples/Kconfig"
Signature · 3 lines
Stefan Richter
-=====-==--- -=-- -=-=-
http://arcgraph.de/sr/
#19 lore raw

Re: [PATCH linux1394-2.6.git] firewire: fw-ohci: add option for remote debugging - amendment

Quoted 3 lines · I wrote:

- Open the physical DMA filter in the top half of the IRQ handler and flush the necessary MMIO writes. This is to open the filter as soon as possible after bus reset.

...

Quoted 18 lines
drivers/firewire/fw-ohci.c +0 -5
@@ -1309,11 +1309,6 @@ static void bus_reset_tasklet(unsigned l
 		reg_write(ohci, OHCI1394_ConfigROMhdr, ohci->next_header);
 	}
 
-#ifdef CONFIG_FIREWIRE_OHCI_REMOTE_DMA
-	reg_write(ohci, OHCI1394_PhyReqFilterHiSet, ~0);
-	reg_write(ohci, OHCI1394_PhyReqFilterLoSet, ~0);
-#endif
-
 	spin_unlock_irqrestore(&ohci->lock, flags);
 
 	if (free_rom)

@@ -1341,8 +1336,14 @@ static irqreturn_t irq_handler(int irq, 
 	reg_write(ohci, OHCI1394_IntEventClear, event & ~OHCI1394_busReset);
 	log_irqs(event);

drivers/firewire/fw-ohci.c static irqreturn_t irq_handler(int irq, · line 1347

Quoted 10 lines
drivers/firewire/fw-ohci.c +7 -1
-	if (event & OHCI1394_selfIDComplete)
+	if (event & OHCI1394_selfIDComplete) {
+#ifdef CONFIG_FIREWIRE_OHCI_REMOTE_DMA
+		reg_write(ohci, OHCI1394_PhyReqFilterHiSet, ~0);
+		reg_write(ohci, OHCI1394_PhyReqFilterLoSet, ~0);
+		flush_writes(ohci);
+#endif
 		tasklet_schedule(&ohci->bus_reset_tasklet);
+	}

I retract this part of the patch. Writes to PhyReqFilter have no effect as long as intEvent.busReset isn't cleared. This happens in the bottom half of the bus reset handler (bus_reset_tasklet).

The rest of the patch stays valid.

Signature · 3 lines
Stefan Richter
-=====-==--- -=-- -=-==
http://arcgraph.de/sr/
#20 lore raw

Re: debug Kconfig option (was Re: linux-next: Tree for April 9)

In reply to Stefan Richter
Quoted 12 lines · On Thu, 10 Apr 2008 09:52:25 +0200 (CEST) Stefan Richter wrote:
Quoted 11 lines · Stephen Rothwell
Quoted 5 lines · On Thu, 10 Apr 2008 08:52:27 +0200 Ingo Molnar <[email protected]> wrote:

what type of conflict do you have there? If it's a new entry then you might be able to fix it by moving the new entry elsewhere in the file. Or if i introduced a new entry close to an existing entry you modify then i could move my new entry elsewhere.

Commit 523a65f1a7a339e528ca6d6d808516fe195fde03 ("firewire: fw-ohci: add option for remote debugging") in the ieee1394 tree adds a new entry just where the sched tree adds

Quoted 6 lines
Quoted 2 lines

source kernel/trace/Kconfig

I grab this opportunity to ask the list: Would you prefer the remote debugging option in the kernel hacking menu (as in the commit), or rather in the respective driver submenu?

I like it in the kernel hacking menu.

Quoted 96 lines

For reference:

Date: Thu, 28 Feb 2008 20:54:43 +0100 (CET)
From: Stefan Richter <[email protected]>
Subject: firewire: fw-ohci: add option for remote debugging

This way firewire-ohci can be used for remote debugging like ohci1394.

Signed-off-by Stefan Richter <[email protected]>
---
 Documentation/debugging-via-ohci1394.txt |   13 ++++++++-----
 drivers/firewire/fw-ohci.c               |    9 +++++++++
 lib/Kconfig.debug                        |   10 ++++++++++
 3 files changed, 27 insertions(+), 5 deletions(-)

Index: linux/Documentation/debugging-via-ohci1394.txt
===================================================================

Documentation/debugging-via-ohci1394.txt +8 -5
@@ -41,11 +41,14 @@ to a working state and enables physical 
 This can be turned off by ohci1394's module parameter phys_dma=0.
 
 The alternative firewire-ohci driver in drivers/firewire uses filtered physical
-DMA, hence is not yet suitable for remote debugging.
-
-Because ohci1394 depends on the PCI enumeration to be completed, an
-initialization routine which runs pretty early (long before console_init()
-which makes the printk buffer appear on the console can be called) was written.
+DMA by default, which is more secure but not suitable for remote debugging.
+Compile the driver with CONFIG_FIREWIRE_OHCI_REMOTE_DMA to get unfiltered
+physical DMA.
+
+Because ohci1394 and firewire-ohci depend on the PCI enumeration to be
+completed, an initialization routine which runs pretty early has been
+implemented for x86.  This routine runs long before console_init() can be
+called, i.e. before the printk buffer appears on the console.
 
 To activate it, enable CONFIG_PROVIDE_OHCI1394_DMA_INIT (Kernel hacking menu:
 Provide code for enabling DMA over FireWire early on boot) and pass the

Index: linux/drivers/firewire/fw-ohci.c
===================================================================

drivers/firewire/fw-ohci.c +9 -0
@@ -1097,6 +1097,11 @@ static void bus_reset_tasklet(unsigned l
 		reg_write(ohci, OHCI1394_ConfigROMhdr, ohci->next_header);
 	}
 
+#ifdef CONFIG_FIREWIRE_OHCI_REMOTE_DMA
+	reg_write(ohci, OHCI1394_PhyReqFilterHiSet, ~0);
+	reg_write(ohci, OHCI1394_PhyReqFilterLoSet, ~0);
+#endif
+
 	spin_unlock_irqrestore(&ohci->lock, flags);
 
 	if (free_rom)

@@ -1435,6 +1440,9 @@ static int ohci_cancel_packet(struct fw_
 static int
 ohci_enable_phys_dma(struct fw_card *card, int node_id, int generation)
 {
+#ifdef CONFIG_FIREWIRE_OHCI_REMOTE_DMA
+	return 0;
+#else
 	struct fw_ohci *ohci = fw_ohci(card);
 	unsigned long flags;
 	int n, retval = 0;

@@ -1466,6 +1474,7 @@ ohci_enable_phys_dma(struct fw_card *car
  out:
 	spin_unlock_irqrestore(&ohci->lock, flags);
 	return retval;
+#endif /* CONFIG_FIREWIRE_OHCI_REMOTE_DMA */
 }
 
 static u64

Index: linux/lib/Kconfig.debug
===================================================================

lib/Kconfig.debug +10 -0
@@ -592,6 +592,16 @@ config LATENCYTOP
 	  Enable this option if you want to use the LatencyTOP tool
 	  to find out which userspace is blocking on what kernel operations.
 
+config FIREWIRE_OHCI_REMOTE_DMA
+	bool "Remote debugging via firewire-ohci"
+	depends on FIREWIRE_OHCI
+	help
+	  This option lets you use the FireWire bus for remote debugging.
+	  It enables unfiltered remote DMA in the firewire-ohci driver.
+	  See Documentation/debugging-via-ohci1394.txt for more information.
+
+	  If unsure, say N.
+
 config PROVIDE_OHCI1394_DMA_INIT
 	bool "Provide code for enabling DMA over FireWire early on boot"
 	depends on PCI && X86
Signature · 1 line
--

---
~Randy

#21 lore raw
In reply to Stephen Rothwell
Quoted 7 lines · Stephen Rothwell
Quoted 5 lines · On Thu, 10 Apr 2008 08:52:27 +0200 Ingo Molnar <[email protected]> wrote:

what type of conflict do you have there? If it's a new entry then you might be able to fix it by moving the new entry elsewhere in the file. Or if i introduced a new entry close to an existing entry you modify then i could move my new entry elsewhere.

Quoted 5 lines

Commit 523a65f1a7a339e528ca6d6d808516fe195fde03 ("firewire: fw-ohci:
add option for remote debugging") in the ieee1394 tree adds a new entry just where the sched tree adds

source kernel/trace/Kconfig

hm, i think in this specific case the new firewire entry should be added after the PROVIDE_OHCI1394_DMA_INIT section. (that's how we extend groups of Kconfig entries anyway) The new trace entries in the scheduler tree follow that pattern and add the new kernel/trace/Kconfig at the right place. So if the firewire entry is added that way this conflict could be avoided.

Ingo

#22 lore raw
Quoted 13 lines · Ingo Molnar
Quoted 11 lines · Stephen Rothwell
Quoted 5 lines · On Thu, 10 Apr 2008 08:52:27 +0200 Ingo Molnar <[email protected]> wrote:

what type of conflict do you have there? If it's a new entry then you might be able to fix it by moving the new entry elsewhere in the file. Or if i introduced a new entry close to an existing entry you modify then i could move my new entry elsewhere.

Commit 523a65f1a7a339e528ca6d6d808516fe195fde03 ("firewire: fw-ohci:
add option for remote debugging") in the ieee1394 tree adds a new entry just where the sched tree adds

Quoted 8 lines
Quoted 1 line

source kernel/trace/Kconfig

hm, i think in this specific case the new firewire entry should be added after the PROVIDE_OHCI1394_DMA_INIT section. (that's how we extend groups of Kconfig entries anyway) The new trace entries in the scheduler tree follow that pattern and add the new kernel/trace/Kconfig at the right place. So if the firewire entry is added that way this conflict could be avoided.

Indeed, this order of the two options looks more logical now that you say it. Update patch will appear on LKML in a minute.

Stephen will still have a conflict in lib/Kconfig.debug when merging the tests tree, but this happens regardless what we two do because tests is based on 2.6.25-rc1, and mainline Kconfig.debug has changes post -rc1.

Signature · 3 lines
Stefan Richter
-=====-==--- -=-- -=-=-
http://arcgraph.de/sr/
#23 lore raw

[BUG] linux-next: Tree for April 9 warning on CC_STACKPROTECTOR, followed by kernel panic

In reply to Stephen Rothwell

Hi Stephen,

The next-20080409 kernel warns while booting up on a x86_64 machine. When compiled the kernel with CONFIG_CC_STACKPROTECTOR=y, the warning is followed by the kernel panic.

Testing -fstack-protector-all feature
No -fstack-protector-stack-frame!
-fstack-protector-all test failed

------------[ cut here ]------------
WARNING: at kernel/panic.c:365 __stack_chk_test+0x4b/0x50()
Modules linked in:

Pid: 1, comm: swapper Not tainted 2.6.25-rc8-next-20080409-autotest #1

Call Trace:
 [<ffffffff80231f5e>] warn_on_slowpath+0x51/0x63
 [<ffffffff80232d93>] printk+0x4e/0x56
 [<ffffffff80382fcd>] extract_entropy+0x47/0x90
 [<ffffffff80230000>] dup_mm+0xca/0x3fd
 [<ffffffff80231eba>] __stack_chk_test_func+0x21/0x32
 [<ffffffff80231fbb>] __stack_chk_test+0x4b/0x50
 [<ffffffff808ba8f1>] kernel_init+0x189/0x2f9
 [<ffffffff804ee221>] _spin_unlock_irq+0x9/0xc
 [<ffffffff8020cb88>] child_rip+0xa/0x12
 [<ffffffff808ba768>] kernel_init+0x0/0x2f9
 [<ffffffff8020cb7e>] child_rip+0x0/0x12

---[ end trace d88d2f3a71e3b32c ]---
Freeing unused kernel memory: 368k freed
Write protecting the kernel read-only data: 4188k
BUG: unable to handle kernel NULL pointer dereference at 00000000000002e8
IP: [<ffffffff80286c11>] kmem_cache_alloc+0x19/0x6b
PGD 3e925067 PUD 3e924067 PMD 0 
Oops: 0000 [1] SMP 
last sysfs file: 
CPU 0 
Modules linked in:
Pid: 1, comm: init Not tainted 2.6.25-rc8-next-20080409-autotest #1
RIP: 0010:[<ffffffff80286c11>]  [<ffffffff80286c11>] kmem_cache_alloc+0x19/0x6b
RSP: 0000:ffff81003f9c9f08  EFLAGS: 00010046
RAX: 0000000000000000 RBX: 0000000000000246 RCX: ffffffff80211f7e
RDX: 00007fff1f89e710 RSI: 00000000000000d0 RDI: 0000000000000000
RBP: 00007fff1f89e6f8 R08: 000000000065e300 R09: 000000000065e2e8
R10: 000000000066d800 R11: 0000000000000203 R12: 00000000000000d0
R13: 000000000047c290 R14: 000000000047c250 R15: 0000000000000000
FS:  000000000066d870(0063) GS:ffffffff8067a000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 00000000000002e8 CR3: 000000003e921000 CR4: 00000000000006e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process init (pid: 1, threadinfo ffff81003f9c8000, task ffff81003f9c6000)
Stack:  ffff81003f9c6000 00007fff1f89e6f8 0000000000000002 ffffffff80211f7e
 ffff81003e920060 ffffffff8033419c ffff81003f9c6000 ffffffff8020d96a
 0000000000000000 ffffffff804ee379 0000000000000000 000000000047c250
Call Trace:
 [<ffffffff80211f7e>] ? init_fpu+0x88/0xc9
 [<ffffffff8033419c>] ? __up_read+0x13/0x8a
 [<ffffffff8020d96a>] ? math_state_restore+0x19/0x5a
 [<ffffffff804ee379>] ? error_exit+0x0/0x51


Code: 4b 18 31 c0 48 89 f7 fc f3 aa 5b 5d 41 5c 48 89 f0 c3 41 54 41 89 f4 55 53 48 8b 4c 24 18 9c 5b fa 65 8b 04 25 24 00 00 00 48 98 <48> 8b ac c7 e8 02 00 00 48 8b 55 00 48 85 d2 75 10 83 ca ff 49 
RIP  [<ffffffff80286c11>] kmem_cache_alloc+0x19/0x6b
 RSP <ffff81003f9c9f08>
CR2: 00000000000002e8
---[ end trace d88d2f3a71e3b32c ]---
Kernel panic - not syncing: Attempted to kill init!

Pid: 1, comm: init Tainted: G D 2.6.25-rc8-next-20080409-autotest #1

Call Trace:
 [<ffffffff8023225d>] panic+0x86/0x144
 [<ffffffff80251911>] kallsyms_lookup+0x49/0x80
 [<ffffffff80286c11>] kmem_cache_alloc+0x19/0x6b
 [<ffffffff80232d93>] printk+0x4e/0x56
 [<ffffffff80232d93>] printk+0x4e/0x56
 [<ffffffff802351c9>] do_exit+0x71/0x682
 [<ffffffff804ee731>] oops_begin+0x0/0x8c
 [<ffffffff804f058d>] do_page_fault+0x738/0x7f3
 [<ffffffff804ee379>] error_exit+0x0/0x51
 [<ffffffff80211f7e>] init_fpu+0x88/0xc9
 [<ffffffff80286c11>] kmem_cache_alloc+0x19/0x6b
 [<ffffffff80211f7e>] init_fpu+0x88/0xc9
 [<ffffffff8033419c>] __up_read+0x13/0x8a
 [<ffffffff8020d96a>] math_state_restore+0x19/0x5a
 [<ffffffff804ee379>] error_exit+0x0/0x51
Signature · 4 lines
Thanks & Regards,
Kamalesh Babulal,
Linux Technology Center,
IBM, ISTL.
#24 lore raw

Re: [BUG] linux-next: Tree for April 9 warning on CC_STACKPROTECTOR, followed by kernel panic

Kamalesh Babulal pisze:

Quoted 14 lines

Hi Stephen,

The next-20080409 kernel warns while booting up on a x86_64 machine. When compiled the kernel with CONFIG_CC_STACKPROTECTOR=y, the warning is followed by the kernel panic.

Testing -fstack-protector-all feature
No -fstack-protector-stack-frame!
-fstack-protector-all test failed

------------[ cut here ]------------
WARNING: at kernel/panic.c:365 __stack_chk_test+0x4b/0x50()
Modules linked in:

Pid: 1, comm: swapper Not tainted 2.6.25-rc8-next-20080409-autotest #1

Quoted 14 lines
Call Trace:
 [<ffffffff80231f5e>] warn_on_slowpath+0x51/0x63
 [<ffffffff80232d93>] printk+0x4e/0x56
 [<ffffffff80382fcd>] extract_entropy+0x47/0x90
 [<ffffffff80230000>] dup_mm+0xca/0x3fd
 [<ffffffff80231eba>] __stack_chk_test_func+0x21/0x32
 [<ffffffff80231fbb>] __stack_chk_test+0x4b/0x50
 [<ffffffff808ba8f1>] kernel_init+0x189/0x2f9
 [<ffffffff804ee221>] _spin_unlock_irq+0x9/0xc
 [<ffffffff8020cb88>] child_rip+0xa/0x12
 [<ffffffff808ba768>] kernel_init+0x0/0x2f9
 [<ffffffff8020cb7e>] child_rip+0x0/0x12

---[ end trace d88d2f3a71e3b32c ]---

Hi,

what version of GCC are you using?

-Jacek

#25 lore raw

Re: [BUG] linux-next: Tree for April 9 warning on CC_STACKPROTECTOR, followed by kernel panic

Quoted 28 lines · Jacek Luczak

Kamalesh Babulal pisze:

Quoted 27 lines

Hi Stephen,

The next-20080409 kernel warns while booting up on a x86_64 machine. When compiled the kernel with CONFIG_CC_STACKPROTECTOR=y, the warning is followed by the kernel panic.

Testing -fstack-protector-all feature
No -fstack-protector-stack-frame!
-fstack-protector-all test failed

------------[ cut here ]------------
WARNING: at kernel/panic.c:365 __stack_chk_test+0x4b/0x50()
Modules linked in:

Pid: 1, comm: swapper Not tainted 2.6.25-rc8-next-20080409-autotest #1

Call Trace:
 [<ffffffff80231f5e>] warn_on_slowpath+0x51/0x63
 [<ffffffff80232d93>] printk+0x4e/0x56
 [<ffffffff80382fcd>] extract_entropy+0x47/0x90
 [<ffffffff80230000>] dup_mm+0xca/0x3fd
 [<ffffffff80231eba>] __stack_chk_test_func+0x21/0x32
 [<ffffffff80231fbb>] __stack_chk_test+0x4b/0x50
 [<ffffffff808ba8f1>] kernel_init+0x189/0x2f9
 [<ffffffff804ee221>] _spin_unlock_irq+0x9/0xc
 [<ffffffff8020cb88>] child_rip+0xa/0x12
 [<ffffffff808ba768>] kernel_init+0x0/0x2f9
 [<ffffffff8020cb7e>] child_rip+0x0/0x12
Quoted 7 lines
Quoted 1 line
---[ end trace d88d2f3a71e3b32c ]---

Hi,

what version of GCC are you using?

-Jacek

Hi Jacek,

I use the gcc version (GCC) 4.1.1 20060525 (Red Hat 4.1.1-1)

Signature · 4 lines
Thanks & Regards,
Kamalesh Babulal,
Linux Technology Center,
IBM, ISTL.
#26 lore raw

Re: [BUG] linux-next: Tree for April 9 warning on CC_STACKPROTECTOR, followed by kernel panic

Kamalesh Babulal pisze:

Quoted 30 lines
Quoted 29 lines · Jacek Luczak

Kamalesh Babulal pisze:

Quoted 28 lines

Hi Stephen,

The next-20080409 kernel warns while booting up on a x86_64 machine. When compiled the kernel with CONFIG_CC_STACKPROTECTOR=y, the warning is followed by the kernel panic.

Testing -fstack-protector-all feature
No -fstack-protector-stack-frame!
-fstack-protector-all test failed

------------[ cut here ]------------
WARNING: at kernel/panic.c:365 __stack_chk_test+0x4b/0x50()
Modules linked in:

Pid: 1, comm: swapper Not tainted 2.6.25-rc8-next-20080409-autotest #1

Call Trace:
 [<ffffffff80231f5e>] warn_on_slowpath+0x51/0x63
 [<ffffffff80232d93>] printk+0x4e/0x56
 [<ffffffff80382fcd>] extract_entropy+0x47/0x90
 [<ffffffff80230000>] dup_mm+0xca/0x3fd
 [<ffffffff80231eba>] __stack_chk_test_func+0x21/0x32
 [<ffffffff80231fbb>] __stack_chk_test+0x4b/0x50
 [<ffffffff808ba8f1>] kernel_init+0x189/0x2f9
 [<ffffffff804ee221>] _spin_unlock_irq+0x9/0xc
 [<ffffffff8020cb88>] child_rip+0xa/0x12
 [<ffffffff808ba768>] kernel_init+0x0/0x2f9
 [<ffffffff8020cb7e>] child_rip+0x0/0x12

---[ end trace d88d2f3a71e3b32c ]---
Quoted 8 lines
Quoted 5 lines

Hi,

what version of GCC are you using?

-Jacek

Hi Jacek,

I use the gcc version (GCC) 4.1.1 20060525 (Red Hat 4.1.1-1)

IMO it's GCC problem (I've seen a lot of problems with stack-protector and GCC 4.1 branch). Can you make some tests with 4.2 branch?

-Jacek
-Jacek

author
#27 lore raw

Re: [BUG] linux-next: Tree for April 9 warning on CC_STACKPROTECTOR, followed by kernel panic

In reply to Kamalesh Babulal

CC to Ingo ...

Quoted 92 lines · On Thu, 10 Apr 2008 15:09:17 +0530 Kamalesh Babulal…

Hi Stephen,

The next-20080409 kernel warns while booting up on a x86_64 machine. When compiled the kernel with CONFIG_CC_STACKPROTECTOR=y, the warning is followed by the kernel panic.

Testing -fstack-protector-all feature
No -fstack-protector-stack-frame!
-fstack-protector-all test failed

------------[ cut here ]------------
WARNING: at kernel/panic.c:365 __stack_chk_test+0x4b/0x50()
Modules linked in:

Pid: 1, comm: swapper Not tainted 2.6.25-rc8-next-20080409-autotest #1

Call Trace:
 [<ffffffff80231f5e>] warn_on_slowpath+0x51/0x63
 [<ffffffff80232d93>] printk+0x4e/0x56
 [<ffffffff80382fcd>] extract_entropy+0x47/0x90
 [<ffffffff80230000>] dup_mm+0xca/0x3fd
 [<ffffffff80231eba>] __stack_chk_test_func+0x21/0x32
 [<ffffffff80231fbb>] __stack_chk_test+0x4b/0x50
 [<ffffffff808ba8f1>] kernel_init+0x189/0x2f9
 [<ffffffff804ee221>] _spin_unlock_irq+0x9/0xc
 [<ffffffff8020cb88>] child_rip+0xa/0x12
 [<ffffffff808ba768>] kernel_init+0x0/0x2f9
 [<ffffffff8020cb7e>] child_rip+0x0/0x12

---[ end trace d88d2f3a71e3b32c ]---
Freeing unused kernel memory: 368k freed
Write protecting the kernel read-only data: 4188k
BUG: unable to handle kernel NULL pointer dereference at 00000000000002e8
IP: [<ffffffff80286c11>] kmem_cache_alloc+0x19/0x6b
PGD 3e925067 PUD 3e924067 PMD 0 
Oops: 0000 [1] SMP 
last sysfs file: 
CPU 0 
Modules linked in:
Pid: 1, comm: init Not tainted 2.6.25-rc8-next-20080409-autotest #1
RIP: 0010:[<ffffffff80286c11>]  [<ffffffff80286c11>] kmem_cache_alloc+0x19/0x6b
RSP: 0000:ffff81003f9c9f08  EFLAGS: 00010046
RAX: 0000000000000000 RBX: 0000000000000246 RCX: ffffffff80211f7e
RDX: 00007fff1f89e710 RSI: 00000000000000d0 RDI: 0000000000000000
RBP: 00007fff1f89e6f8 R08: 000000000065e300 R09: 000000000065e2e8
R10: 000000000066d800 R11: 0000000000000203 R12: 00000000000000d0
R13: 000000000047c290 R14: 000000000047c250 R15: 0000000000000000
FS:  000000000066d870(0063) GS:ffffffff8067a000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 00000000000002e8 CR3: 000000003e921000 CR4: 00000000000006e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process init (pid: 1, threadinfo ffff81003f9c8000, task ffff81003f9c6000)
Stack:  ffff81003f9c6000 00007fff1f89e6f8 0000000000000002 ffffffff80211f7e
 ffff81003e920060 ffffffff8033419c ffff81003f9c6000 ffffffff8020d96a
 0000000000000000 ffffffff804ee379 0000000000000000 000000000047c250
Call Trace:
 [<ffffffff80211f7e>] ? init_fpu+0x88/0xc9
 [<ffffffff8033419c>] ? __up_read+0x13/0x8a
 [<ffffffff8020d96a>] ? math_state_restore+0x19/0x5a
 [<ffffffff804ee379>] ? error_exit+0x0/0x51


Code: 4b 18 31 c0 48 89 f7 fc f3 aa 5b 5d 41 5c 48 89 f0 c3 41 54 41 89 f4 55 53 48 8b 4c 24 18 9c 5b fa 65 8b 04 25 24 00 00 00 48 98 <48> 8b ac c7 e8 02 00 00 48 8b 55 00 48 85 d2 75 10 83 ca ff 49 
RIP  [<ffffffff80286c11>] kmem_cache_alloc+0x19/0x6b
 RSP <ffff81003f9c9f08>
CR2: 00000000000002e8
---[ end trace d88d2f3a71e3b32c ]---
Kernel panic - not syncing: Attempted to kill init!

Pid: 1, comm: init Tainted: G D 2.6.25-rc8-next-20080409-autotest #1

Call Trace:
 [<ffffffff8023225d>] panic+0x86/0x144
 [<ffffffff80251911>] kallsyms_lookup+0x49/0x80
 [<ffffffff80286c11>] kmem_cache_alloc+0x19/0x6b
 [<ffffffff80232d93>] printk+0x4e/0x56
 [<ffffffff80232d93>] printk+0x4e/0x56
 [<ffffffff802351c9>] do_exit+0x71/0x682
 [<ffffffff804ee731>] oops_begin+0x0/0x8c
 [<ffffffff804f058d>] do_page_fault+0x738/0x7f3
 [<ffffffff804ee379>] error_exit+0x0/0x51
 [<ffffffff80211f7e>] init_fpu+0x88/0xc9
 [<ffffffff80286c11>] kmem_cache_alloc+0x19/0x6b
 [<ffffffff80211f7e>] init_fpu+0x88/0xc9
 [<ffffffff8033419c>] __up_read+0x13/0x8a
 [<ffffffff8020d96a>] math_state_restore+0x19/0x5a
 [<ffffffff804ee379>] error_exit+0x0/0x51
Signature · 4 lines
Thanks & Regards,
Kamalesh Babulal,
Linux Technology Center,
IBM, ISTL.
Signature · 3 lines
Cheers,
Stephen Rothwell                    [email protected]
http://www.canb.auug.org.au/~sfr/
#28 lore raw

Re: [BUG] linux-next: Tree for April 9 warning on CC_STACKPROTECTOR, followed by kernel panic

Quoted 1 line · Stephen Rothwell

CC to Ingo ...

i've reverted the guilty patch and will push out a new x86.git soon.

Ingo