Re: nfsd, v4: oops in find_acceptable_alias, ppc32 Linux, post-2.6.27-rc1
Paul Collins [EMAIL PROTECTED] writes:
J. Bruce Fields [EMAIL PROTECTED] writes:
On Sun, Aug 03, 2008 at 12:03:18AM +1200, Paul Collins wrote:
I just got the oops below on a ppc32 NFS4 server. I was cross-compiling
Linux with an amd64 client at the time. The server is running Linus's
tree as of 94ad374a0751f40d25e22e036c37f7263569d24c, the client is
running 2.6.26.
The server's kernel was cross-compiled with gcc 4.2.4-3 and binutils
2.18.50.20080610-1, both built from the Debian sources following their
toolchain-building procedures.
Without having really thought about this,
496d6c32d4d057cb44272d9bd587ff97d023ee92 nfsd: fix spurious
EACCESS in reconnect_path()
is one suspect; it might be worth checking whether the problem's
reproduceable with that reverted. But I assume we're not so lucky as to
have a 100% reproduceable problem here?
Unknown. I've kicked off a fresh build. Here's hoping!
I can trigger it reliably with a 2.6.26 client. I've also triggered it
with 496d6c32d4d057cb44272d9bd587ff97d023ee92 reverted on the server.
It's harder to trigger with 2.6.27-rc1+ but I managed to get an Oops
on the fourth build after three successful builds on the NFS4 mount.
One of the Oopses I got with 2.6.26 had a slightly different call trace:
Unable to handle kernel paging request for instruction fetch
Faulting instruction address: 0x
Oops: Kernel access of bad area, sig: 11 [#1]
PowerMac
Modules linked in: radeon drm snd_aoa_codec_tas snd_aoa_fabric_layout b43
mac80211 snd_aoa cfg80211 pcmcia snd_aoa_i2sbus snd_pcm_oss snd_pcm
snd_page_alloc snd_aoa_soundbus yenta_socket rsrc_nonstatic pcmcia_core ssb
uninorth_agp agpgart ehci_hcd ohci_hcd
NIP: LR: c0159bb0 CTR:
REGS: c1f79ca0 TRAP: 0400 Not tainted (2.6.27-rc1-00158-g643fbd8)
MSR: 40009032 EE,ME,IR,DR CR: 22002022 XER: 2000
TASK = c1ca5440[2321] 'nfsd' THREAD: c1f78000
GPR00: 0008 c1f79d50 c1ca5440 82002044 edda2c54 002d6642 002d6642 e05f26bc
GPR08: ee126e60 eed7a600 c1f79d50 0007 018985fc 01898404
GPR16: 01898710 018c7894 c04b03f4 c04b03e0 c0173da0 c05f4e84 f000 0001
GPR24: c00c05dc 82002044 ef80cca0 edda2c54 ee10d020 c0437120 c1f79d50
NIP [] 0x0
LR [c0159bb0] exportfs_decode_fh+0xa8/0x200
Call Trace:
[c1f79d50] [c0159b54] exportfs_decode_fh+0x4c/0x200 (unreliable)
[c1f79e80] [c015d568] fh_verify+0x2e8/0x578
[c1f79ed0] [c016b1ec] nfsd4_putfh+0x60/0x78
[c1f79ef0] [c016afd0] nfsd4_proc_compound+0x1e4/0x34c
[c1f79f30] [c015a060] nfsd_dispatch+0xfc/0x220
[c1f79f50] [c0400c70] svc_process+0x3e4/0x6e8
[c1f79f90] [c015a8bc] nfsd+0x1c4/0x294
[c1f79fd0] [c0049e48] kthread+0x5c/0x9c
[c1f79ff0] [c00125c0] kernel_thread+0x44/0x60
Instruction dump:
---[ end trace 3dfa6e448b5c7077 ]---
--
Paul Collins
Wellington, New Zealand
Dag vijandelijk luchtschip de huismeester is dood
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: nfsd, v4: oops in find_acceptable_alias, ppc32 Linux, post-2.6.27-rc1
On Sunday August 3, [EMAIL PROTECTED] wrote: I can trigger it reliably with a 2.6.26 client. I've also triggered it with 496d6c32d4d057cb44272d9bd587ff97d023ee92 reverted on the server. It's harder to trigger with 2.6.27-rc1+ but I managed to get an Oops on the fourth build after three successful builds on the NFS4 mount. One of the Oopses I got with 2.6.26 had a slightly different call trace: Unable to handle kernel paging request for instruction fetch Faulting instruction address: 0x So we have called a function pointer which was NULL. There a lots of function pointers in use in this code. There is the 'acceptable' function. There is -fh_to_dentry and -fh_to_parent. And various inode operations line -lookup, but that is a bit further away. NIP [] 0x0 LR [c0159bb0] exportfs_decode_fh+0xa8/0x200 I guess this is where the call came from. exportfs_decode_fh is never passed NULL for 'acceptable'. Only ever 'nfsd_acceptable'. -fh_to_parent is tested for NULL before being called, and -fh_to_dentry is called very early in exportfs_decode_fh, where as the bad call is 0xa8 in to the function. Is it possible that -fh_to_parent is being changed immediately after being tested for NULL and before being dereferenced. That seems unlikely. What filesystem is being exported here? Can you get an assembly version of exportfs_decode_fh, so we can check what is happening at 0xa8 (and 0x4c). Either disassemble exportfs_decode_fh in gdb, or make fs/exportfs/expfs.i (I think). NeilBrown Call Trace: [c1f79d50] [c0159b54] exportfs_decode_fh+0x4c/0x200 (unreliable) [c1f79e80] [c015d568] fh_verify+0x2e8/0x578 [c1f79ed0] [c016b1ec] nfsd4_putfh+0x60/0x78 [c1f79ef0] [c016afd0] nfsd4_proc_compound+0x1e4/0x34c [c1f79f30] [c015a060] nfsd_dispatch+0xfc/0x220 [c1f79f50] [c0400c70] svc_process+0x3e4/0x6e8 [c1f79f90] [c015a8bc] nfsd+0x1c4/0x294 [c1f79fd0] [c0049e48] kthread+0x5c/0x9c [c1f79ff0] [c00125c0] kernel_thread+0x44/0x60 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: nfsd, v4: oops in find_acceptable_alias, ppc32 Linux, post-2.6.27-rc1
Neil Brown [EMAIL PROTECTED] writes: On Sunday August 3, [EMAIL PROTECTED] wrote: I can trigger it reliably with a 2.6.26 client. I've also triggered it with 496d6c32d4d057cb44272d9bd587ff97d023ee92 reverted on the server. It's harder to trigger with 2.6.27-rc1+ but I managed to get an Oops on the fourth build after three successful builds on the NFS4 mount. One of the Oopses I got with 2.6.26 had a slightly different call trace: Unable to handle kernel paging request for instruction fetch Faulting instruction address: 0x So we have called a function pointer which was NULL. There a lots of function pointers in use in this code. There is the 'acceptable' function. There is -fh_to_dentry and -fh_to_parent. And various inode operations line -lookup, but that is a bit further away. NIP [] 0x0 LR [c0159bb0] exportfs_decode_fh+0xa8/0x200 I guess this is where the call came from. exportfs_decode_fh is never passed NULL for 'acceptable'. Only ever 'nfsd_acceptable'. -fh_to_parent is tested for NULL before being called, and -fh_to_dentry is called very early in exportfs_decode_fh, where as the bad call is 0xa8 in to the function. Is it possible that -fh_to_parent is being changed immediately after being tested for NULL and before being dereferenced. That seems unlikely. What filesystem is being exported here? Boring old ext3 (on LVM, on dm-crypt). Can you get an assembly version of exportfs_decode_fh, so we can check what is happening at 0xa8 (and 0x4c). Dump of assembler code for function exportfs_decode_fh: 0xc015b7cc exportfs_decode_fh+0: mflrr0 0xc015b7d0 exportfs_decode_fh+4: stw r0,4(r1) 0xc015b7d4 exportfs_decode_fh+8: bl 0xc0013154 _mcount 0xc015b7d8 exportfs_decode_fh+12: stwur1,-304(r1) 0xc015b7dc exportfs_decode_fh+16: mflrr0 0xc015b7e0 exportfs_decode_fh+20: stmwr22,264(r1) 0xc015b7e4 exportfs_decode_fh+24: mr r27,r3 0xc015b7e8 exportfs_decode_fh+28: mr r31,r1 0xc015b7ec exportfs_decode_fh+32: stw r0,308(r1) 0xc015b7f0 exportfs_decode_fh+36: mr r25,r7 0xc015b7f4 exportfs_decode_fh+40: mr r26,r8 0xc015b7f8 exportfs_decode_fh+44: mr r29,r4 0xc015b7fc exportfs_decode_fh+48: mr r24,r5 0xc015b800 exportfs_decode_fh+52: mr r23,r6 0xc015b804 exportfs_decode_fh+56: lwz r3,20(r3) 0xc015b808 exportfs_decode_fh+60: lwz r30,48(r3) 0xc015b80c exportfs_decode_fh+64: lwz r0,4(r30) 0xc015b810 exportfs_decode_fh+68: mtctr r0 0xc015b814 exportfs_decode_fh+72: bctrl 0xc015b818 exportfs_decode_fh+76: mr. r28,r3 0xc015b81c exportfs_decode_fh+80: bne+0xc015b824 exportfs_decode_fh+88 0xc015b820 exportfs_decode_fh+84: li r28,-116 0xc015b824 exportfs_decode_fh+88: li r22,-4096 0xc015b828 exportfs_decode_fh+92: cmplw cr7,r28,r22 0xc015b82c exportfs_decode_fh+96: bgt-cr7,0xc015b9b0 exportfs_decode_fh+484 0xc015b830 exportfs_decode_fh+100:lwz r9,8(r28) 0xc015b834 exportfs_decode_fh+104:lhz r0,114(r9) 0xc015b838 exportfs_decode_fh+108:rlwinm r0,r0,0,16,19 0xc015b83c exportfs_decode_fh+112:cmpwi cr7,r0,16384 0xc015b840 exportfs_decode_fh+116:bne-cr7,0xc015b880 exportfs_decode_fh+180 0xc015b844 exportfs_decode_fh+120:lwz r0,4(r28) 0xc015b848 exportfs_decode_fh+124:andi. r9,r0,4 0xc015b84c exportfs_decode_fh+128:beq-0xc015b864 exportfs_decode_fh+152 0xc015b850 exportfs_decode_fh+132:mr r3,r27 0xc015b854 exportfs_decode_fh+136:mr r4,r28 0xc015b858 exportfs_decode_fh+140:bl 0xc015b45c reconnect_path 0xc015b85c exportfs_decode_fh+144:mr. r30,r3 0xc015b860 exportfs_decode_fh+148:bne-0xc015b9a4 exportfs_decode_fh+472 0xc015b864 exportfs_decode_fh+152:mr r3,r26 0xc015b868 exportfs_decode_fh+156:mr r4,r28 0xc015b86c exportfs_decode_fh+160:mtctr r25 0xc015b870 exportfs_decode_fh+164:bctrl 0xc015b874 exportfs_decode_fh+168:cmpwi cr7,r3,0 0xc015b878 exportfs_decode_fh+172:beq+cr7,0xc015b998 exportfs_decode_fh+460 0xc015b87c exportfs_decode_fh+176:b 0xc015b9b0 exportfs_decode_fh+484 0xc015b880 exportfs_decode_fh+180:mr r3,r28 0xc015b884 exportfs_decode_fh+184:mr r4,r25 0xc015b888 exportfs_decode_fh+188:mr r5,r26 0xc015b88c exportfs_decode_fh+192:bl 0xc015b6c4 find_acceptable_alias 0xc015b890 exportfs_decode_fh+196:cmpwi r3,0 0xc015b894 exportfs_decode_fh+200:bne+0xc015b990 exportfs_decode_fh+452 0xc015b898 exportfs_decode_fh+204:lwz r0,8(r30) 0xc015b89c exportfs_decode_fh+208:cmpwi cr7,r0,0 0xc015b8a0 exportfs_decode_fh+212:beq-cr7,0xc015b9a0 exportfs_decode_fh+468 0xc015b8a4 exportfs_decode_fh+216:mr r4,r29 0xc015b8a8 exportfs_decode_fh+220:mr r5,r24 0xc015b8ac exportfs_decode_fh+224:lwz r3,20(r27) 0xc015b8b0
Re: [PATCH 8/8] powerpc: last bits to support kdump on ppc32
On Fri, 2008-08-01 at 18:14 +0400, Anton Vorontsov wrote:
From: Dale Farnsworth [EMAIL PROTECTED]
Wire up the trampoline code for ppc32 to relay exceptions from the
vectors at address 0 to vectors at address 32MB, and modify Kconfig
to enable Kdump support for all powerpcs (except BookE, for now).
Signed-off-by: Dale Farnsworth [EMAIL PROTECTED]
Signed-off-by: Anton Vorontsov [EMAIL PROTECTED]
diff --git a/arch/powerpc/kernel/crash_dump.c
b/arch/powerpc/kernel/crash_dump.c
index e0debcc..96cd521 100644
--- a/arch/powerpc/kernel/crash_dump.c
+++ b/arch/powerpc/kernel/crash_dump.c
@@ -34,7 +34,11 @@ void __init reserve_kdump_trampoline(void)
static void __init create_trampoline(unsigned long addr)
{
- unsigned int *p = (unsigned int *)addr;
+ unsigned int *p;
+
+ /* XXX: why this code is working without += PAGE_OFFSET on PPC64? */
+ addr += PAGE_OFFSET;
+ p = (unsigned int *)addr;
Because we're still in real mode when we call it.
It's kind of funny that it works on 32-bit as well. You're creating a
branch from 0xc000 to 0xc200, and then expecting it to work when
you're in real mode and you actually want to jump from 0x0 to 0x200
- luckily it's a relative branch :)
To clean this up you should just be able to change the definitions for
KDUMP_TRAMPOLINE_START/END to include PAGE_OFFSET and that should work
for 32 64-bit.
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
signature.asc
Description: This is a digitally signed message part
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2] powerpc: move include files to arch/powerpc/include/asm
On Aug 1, 2008, at 12:20 AM, Stephen Rothwell wrote:
from include/asm-powerpc. This is the result of a
mkdir arch/powerpc/include/asm
git mv include/asm-powerpc/* arch/powerpc/include/asm
Followed by a few documentation/comment fixups and a couple of places
where asm-powepc/... was being used explicitly. Of the latter only
one was outside the arch code and it is a driver only built for
powerpc.
Signed-off-by: Stephen Rothwell [EMAIL PROTECTED]
---
v2 don't change other arch files - the fixups are only in comments
anyway.
This patch can be applied with git am - the full patch is way to bug
for our mailing lists.
This has been built for all the powerpc defconfigs including
all{no,mod,yes}config. There was only one failure, but that is
expected anyway (I had to apply patches for the iommu and hfcmulti
breakages).
Paul, what's the plan for this change? If this is something that will
go in so can we get a tree with it so we can base other patches on it
(like the PPC_MERGE cleanup)?
- k
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2] powerpc: move include files to arch/powerpc/include/asm
On Fri, 1 Aug 2008 15:20:30 +1000 Stephen Rothwell [EMAIL PROTECTED] wrote: This patch can be applied with git am - the full patch is way to bug ^^^ Freudian slip :-) -- Cheers, Stephen Rothwell[EMAIL PROTECTED] http://www.canb.auug.org.au/~sfr/ pgp3shIEbZq2V.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2] powerpc: move include files to arch/powerpc/include/asm
On Sun, 3 Aug 2008 09:58:14 -0500 Kumar Gala [EMAIL PROTECTED] wrote:
Paul, what's the plan for this change? If this is something that will
go in so can we get a tree with it so we can base other patches on it
(like the PPC_MERGE cleanup)?
It looks like Linus is happy to take these patches, so if Paul is game he
could just shove it in powerpc-{next,master,merge} and ask Linus to pull
it. The sooner the better in that case.
--
Cheers,
Stephen Rothwell[EMAIL PROTECTED]
http://www.canb.auug.org.au/~sfr/
pgpvb5QUGH55G.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
to schedule() or not to schedule() ?
Hi,
I have the following near the top of my cpufreq driver target routine:
while(test_and_set_bit(cf750gxmCfgChangeBit,cf750gxvStateBits)) {
/*
* Someone mucking with our cfg? (I hope it is ok to call
* schedule() here! - truth is I have no idea what I am doing
* ... my reasoning is I want to yeild the cpu so whoever is
* mucking around can finish)
*/
schedule();
}
This is to prevent bad things from happening if someone is trying to
change a parameter for the driver via sysfs while the target routine is
running. Fortunately, because I had a bug where this bit was not getting
cleared on one of the paths through the target routine ... I now know it
is not safe to call schedule (it got stuck in there - knocked out my adb
keyboard! - (I think target is called from a timer that the governor
sets up ... interrupt context?)).
How does one very briefly yield the cpu in this context?
kevin
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: nfsd, v4: oops in find_acceptable_alias, ppc32 Linux, post-2.6.27-rc1
On Monday August 4, [EMAIL PROTECTED] wrote: Neil Brown [EMAIL PROTECTED] writes: What filesystem is being exported here? Boring old ext3 (on LVM, on dm-crypt). Good. That makes it easier. Can you get an assembly version of exportfs_decode_fh, so we can check what is happening at 0xa8 (and 0x4c). Thanks. bctrl appears to be the indirect-function-call opcode. There are three of them one each for -fh_to_dentry acceptable -fh_to_parent 0xa8 is 'acceptable'. In the first traceback, the crash was a call from very early in find_acceptable_alias, The first significant thing it does is call the 'acceptable' function. So it seems clear that 'acceptable' is NULL. It is equally clear that we never ever set it to NULL in the code. The logical conclusion is compiler error. We can confirm (hopefully) by looking at a disassembly of fh_verify. Maybe because nfsd_acceptable is 'static' and never explicitly called, gcc gets confused and optimises it away. Maybe a disassembly of nfsd_acceptable would be informative ... particularly if it turns out to be empty. Could you try removing the 'static' declaration for nfsd_acceptable and recompile? Or maybe try a different compiler? Thanks, NeilBrown ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[git pull] Please pull powerpc.git merge branch
Linus, Please pull from the 'merge' branch of git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git merge The main thing there is that we have moved the powerpc include files from include/asm-powerpc to arch/powerpc/include/asm. There is also a commit from Kumar Gala that removes code that was only referenced when compiling with ARCH=ppc, and is now dead since arch/ppc is gone, plus a couple of warning fixes from Tony Breeds. (Note that the stuff in arch/powerpc/include/asm/irq.h all came from include/asm-powerpc/irq.h; there was enough stuff removed by Kumar's patch that the git rename detection logic didn't see it as a rename.) Thanks, Paul. Documentation/powerpc/booting-without-of.txt |4 +- Documentation/powerpc/eeh-pci-error-recovery.txt |2 +- arch/powerpc/Kconfig.debug |2 +- arch/powerpc/boot/io.h |2 +- .../powerpc/include/asm}/8253pit.h |0 .../powerpc/include/asm}/8xx_immap.h |0 .../powerpc/include/asm}/Kbuild|0 .../powerpc/include/asm}/a.out.h |0 .../powerpc/include/asm}/abs_addr.h|0 .../asm-powerpc = arch/powerpc/include/asm}/agp.h |0 .../powerpc/include/asm}/asm-compat.h |0 .../powerpc/include/asm}/atomic.h |0 .../powerpc/include/asm}/auxvec.h |0 .../powerpc/include/asm}/backlight.h |0 .../powerpc/include/asm}/bitops.h |0 .../powerpc/include/asm}/bootx.h |0 .../powerpc/include/asm}/btext.h |0 .../asm-powerpc = arch/powerpc/include/asm}/bug.h |0 .../powerpc/include/asm}/bugs.h|0 .../powerpc/include/asm}/byteorder.h |0 .../powerpc/include/asm}/cache.h |0 .../powerpc/include/asm}/cacheflush.h |0 .../powerpc/include/asm}/cell-pmu.h|0 .../powerpc/include/asm}/cell-regs.h |0 .../powerpc/include/asm}/checksum.h|0 .../powerpc/include/asm}/clk_interface.h |0 .../powerpc/include/asm}/code-patching.h |0 .../powerpc/include/asm}/compat.h |0 .../asm-powerpc = arch/powerpc/include/asm}/cpm.h |0 .../powerpc/include/asm}/cpm1.h|0 .../powerpc/include/asm}/cpm2.h|0 .../powerpc/include/asm}/cputable.h|0 .../powerpc/include/asm}/cputhreads.h |0 .../powerpc/include/asm}/cputime.h |0 .../powerpc/include/asm}/current.h |0 .../powerpc/include/asm}/dbdma.h |0 .../powerpc/include/asm}/dcr-generic.h |0 .../powerpc/include/asm}/dcr-mmio.h|0 .../powerpc/include/asm}/dcr-native.h |0 .../powerpc/include/asm}/dcr-regs.h|0 .../asm-powerpc = arch/powerpc/include/asm}/dcr.h |6 +- .../powerpc/include/asm}/delay.h |0 .../powerpc/include/asm}/device.h |0 .../powerpc/include/asm}/div64.h |0 .../powerpc/include/asm}/dma-mapping.h |0 .../asm-powerpc = arch/powerpc/include/asm}/dma.h |0 .../powerpc/include/asm}/edac.h|0 .../asm-powerpc = arch/powerpc/include/asm}/eeh.h |0 .../powerpc/include/asm}/eeh_event.h |0 .../asm-powerpc = arch/powerpc/include/asm}/elf.h |0 .../powerpc/include/asm}/emergency-restart.h |0 .../powerpc/include/asm}/errno.h |0 .../powerpc/include/asm}/exception.h |0 .../asm-powerpc = arch/powerpc/include/asm}/fb.h |0 .../powerpc/include/asm}/fcntl.h |0 .../powerpc/include/asm}/feature-fixups.h |0 .../powerpc/include/asm}/firmware.h|0 .../powerpc/include/asm}/fixmap.h |0 .../powerpc/include/asm}/floppy.h |0 .../powerpc/include/asm}/fs_pd.h |0 .../powerpc/include/asm}/fsl_gtm.h |0 .../powerpc/include/asm}/fsl_lbc.h |0 .../powerpc/include/asm}/ftrace.h |0 .../powerpc/include/asm}/futex.h |0 .../powerpc/include/asm}/gpio.h|0 .../powerpc/include/asm}/grackle.h |0 .../powerpc/include/asm}/hardirq.h |0 .../powerpc/include/asm}/heathrow.h|0 .../powerpc/include/asm}/highmem.h |0 .../powerpc/include/asm}/hugetlb.h |0 .../powerpc/include/asm}/hvcall.h |0 .../powerpc/include/asm}/hvconsole.h |0
Re: nfsd, v4: oops in find_acceptable_alias, ppc32 Linux, post-2.6.27-rc1
Neil Brown [EMAIL PROTECTED] writes: bctrl appears to be the indirect-function-call opcode. There are three of them one each for -fh_to_dentry acceptable -fh_to_parent 0xa8 is 'acceptable'. In the first traceback, the crash was a call from very early in find_acceptable_alias, The first significant thing it does is call the 'acceptable' function. So it seems clear that 'acceptable' is NULL. It is equally clear that we never ever set it to NULL in the code. The logical conclusion is compiler error. We can confirm (hopefully) by looking at a disassembly of fh_verify. Maybe because nfsd_acceptable is 'static' and never explicitly called, gcc gets confused and optimises it away. Maybe a disassembly of nfsd_acceptable would be informative ... particularly if it turns out to be empty. Here's the disassembly. Dump of assembler code for function nfsd_acceptable: 0xc015f450 nfsd_acceptable+0: mflrr0 0xc015f454 nfsd_acceptable+4: stw r0,4(r1) 0xc015f458 nfsd_acceptable+8: bl 0xc0013154 _mcount 0xc015f45c nfsd_acceptable+12:stwur1,-32(r1) 0xc015f460 nfsd_acceptable+16:mflrr0 0xc015f464 nfsd_acceptable+20:stmwr28,16(r1) 0xc015f468 nfsd_acceptable+24:mr r28,r3 0xc015f46c nfsd_acceptable+28:mr r31,r1 0xc015f470 nfsd_acceptable+32:stw r0,36(r1) 0xc015f474 nfsd_acceptable+36:li r30,1 0xc015f478 nfsd_acceptable+40:lwz r0,24(r3) 0xc015f47c nfsd_acceptable+44:mr r3,r4 0xc015f480 nfsd_acceptable+48:andi. r9,r0,1024 0xc015f484 nfsd_acceptable+52:bne-0xc015f56c nfsd_acceptable+284 0xc015f488 nfsd_acceptable+56:cmpwi cr7,r4,0 0xc015f48c nfsd_acceptable+60:beq-cr7,0xc015f4b0 nfsd_acceptable+96 0xc015f490 nfsd_acceptable+64:lwz r0,0(r4) 0xc015f494 nfsd_acceptable+68:cntlzw r0,r0 0xc015f498 nfsd_acceptable+72:rlwinm r0,r0,27,5,31 0xc015f49c nfsd_acceptable+76:twnei r0,0 0xc015f4a0 nfsd_acceptable+80:lwarx r0,0,r4 0xc015f4a4 nfsd_acceptable+84:addic r0,r0,1 0xc015f4a8 nfsd_acceptable+88:stwcx. r0,0,r4 0xc015f4ac nfsd_acceptable+92:bne-0xc015f4a0 nfsd_acceptable+80 0xc015f4b0 nfsd_acceptable+96:mr r29,r3 0xc015f4b4 nfsd_acceptable+100: b 0xc015f508 nfsd_acceptable+184 0xc015f4b8 nfsd_acceptable+104: beq-cr6,0xc015f4dc nfsd_acceptable+140 0xc015f4bc nfsd_acceptable+108: lwz r0,0(r30) 0xc015f4c0 nfsd_acceptable+112: cntlzw r0,r0 0xc015f4c4 nfsd_acceptable+116: rlwinm r0,r0,27,5,31 0xc015f4c8 nfsd_acceptable+120: twnei r0,0 0xc015f4cc nfsd_acceptable+124: lwarx r0,0,r30 0xc015f4d0 nfsd_acceptable+128: addic r0,r0,1 0xc015f4d4 nfsd_acceptable+132: stwcx. r0,0,r30 0xc015f4d8 nfsd_acceptable+136: bne-0xc015f4cc nfsd_acceptable+124 0xc015f4dc nfsd_acceptable+140: lwz r3,8(r30) 0xc015f4e0 nfsd_acceptable+144: li r4,1 0xc015f4e4 nfsd_acceptable+148: bl 0xc00b2f50 inode_permission 0xc015f4e8 nfsd_acceptable+152: cmpwi cr7,r3,0 0xc015f4ec nfsd_acceptable+156: mr r3,r29 0xc015f4f0 nfsd_acceptable+160: bge+cr7,0xc015f500 nfsd_acceptable+176 0xc015f4f4 nfsd_acceptable+164: mr r3,r30 0xc015f4f8 nfsd_acceptable+168: bl 0xc00befb0 dput 0xc015f4fc nfsd_acceptable+172: b 0xc015f524 nfsd_acceptable+212 0xc015f500 nfsd_acceptable+176: bl 0xc00befb0 dput 0xc015f504 nfsd_acceptable+180: mr r29,r30 0xc015f508 nfsd_acceptable+184: lwz r0,32(r28) 0xc015f50c nfsd_acceptable+188: cmpwcr7,r29,r0 0xc015f510 nfsd_acceptable+192: beq-cr7,0xc015f524 nfsd_acceptable+212 0xc015f514 nfsd_acceptable+196: lwz r30,20(r29) 0xc015f518 nfsd_acceptable+200: cmpwcr7,r29,r30 0xc015f51c nfsd_acceptable+204: cmpwi cr6,r30,0 0xc015f520 nfsd_acceptable+208: bne+cr7,0xc015f4b8 nfsd_acceptable+104 0xc015f524 nfsd_acceptable+212: lwz r0,32(r28) 0xc015f528 nfsd_acceptable+216: cmpwcr7,r29,r0 0xc015f52c nfsd_acceptable+220: beq-cr7,0xc015f554 nfsd_acceptable+260 0xc015f530 nfsd_acceptable+224: lis r9,-16296 0xc015f534 nfsd_acceptable+228: lwz r0,17792(r9) 0xc015f538 nfsd_acceptable+232: andi. r9,r0,2 0xc015f53c nfsd_acceptable+236: beq+0xc015f554 nfsd_acceptable+260 0xc015f540 nfsd_acceptable+240: lis r3,-16309 0xc015f544 nfsd_acceptable+244: lwz r5,32(r29) 0xc015f548 nfsd_acceptable+248: mr r4,r29 0xc015f54c nfsd_acceptable+252: addir3,r3,7972 0xc015f550 nfsd_acceptable+256: bl 0xc00330d4 printk 0xc015f554 nfsd_acceptable+260: lwz r0,32(r28) 0xc015f558 nfsd_acceptable+264: mr r3,r29 0xc015f55c nfsd_acceptable+268: xor r30,r29,r0 0xc015f560 nfsd_acceptable+272: cntlzw
dtc: Make many functions 'static'
This patch marks various functions not shared between c files
'static', as they should be. There are a couple of functions in dtc,
and many in the testsuite.
This is *almost* enough to enable the -Wmissing-prototypes warning.
It's not quite enough, because there's a mess of junk in the flex
generated code which triggers that warning which I'm not yet sure how
to deal with.
Signed-off-by: David Gibson [EMAIL PROTECTED]
Index: dtc/data.c
===
--- dtc.orig/data.c 2008-08-04 15:12:33.0 +1000
+++ dtc/data.c 2008-08-04 15:12:46.0 +1000
@@ -217,7 +217,7 @@ struct data data_insert_at_marker(struct
return d;
}
-struct data data_append_markers(struct data d, struct marker *m)
+static struct data data_append_markers(struct data d, struct marker *m)
{
struct marker **mp = d.markers;
Index: dtc/tests/get_name.c
===
--- dtc.orig/tests/get_name.c 2008-08-04 15:14:38.0 +1000
+++ dtc/tests/get_name.c2008-08-04 15:14:40.0 +1000
@@ -28,7 +28,7 @@
#include tests.h
#include testdata.h
-void check_name(void *fdt, const char *path)
+static void check_name(void *fdt, const char *path)
{
int offset;
const char *getname, *getname2, *checkname;
Index: dtc/tests/get_path.c
===
--- dtc.orig/tests/get_path.c 2008-08-04 15:17:19.0 +1000
+++ dtc/tests/get_path.c2008-08-04 15:17:41.0 +1000
@@ -30,7 +30,7 @@
#define POISON ('\xff')
-void check_path_buf(void *fdt, const char *path, int pathlen, int buflen)
+static void check_path_buf(void *fdt, const char *path, int pathlen, int
buflen)
{
int offset;
char buf[buflen+1];
@@ -63,7 +63,7 @@ void check_path_buf(void *fdt, const cha
FAIL(fdt_get_path([%d bytes]) overran buffer, buflen);
}
-void check_path(void *fdt, const char *path)
+static void check_path(void *fdt, const char *path)
{
int pathlen = strlen(path);
Index: dtc/tests/get_phandle.c
===
--- dtc.orig/tests/get_phandle.c2008-08-04 15:14:50.0 +1000
+++ dtc/tests/get_phandle.c 2008-08-04 15:14:53.0 +1000
@@ -28,7 +28,7 @@
#include tests.h
#include testdata.h
-void check_phandle(void *fdt, const char *path, uint32_t checkhandle)
+static void check_phandle(void *fdt, const char *path, uint32_t checkhandle)
{
int offset;
uint32_t phandle;
Index: dtc/tests/node_offset_by_prop_value.c
===
--- dtc.orig/tests/node_offset_by_prop_value.c 2008-08-04 15:15:40.0
+1000
+++ dtc/tests/node_offset_by_prop_value.c 2008-08-04 15:16:17.0
+1000
@@ -29,7 +29,7 @@
#include tests.h
#include testdata.h
-void vcheck_search(void *fdt, const char *propname, const void *propval,
+static void vcheck_search(void *fdt, const char *propname, const void *propval,
int proplen, va_list ap)
{
int offset = -1, target;
@@ -48,7 +48,7 @@ void vcheck_search(void *fdt, const char
} while (target = 0);
}
-void check_search(void *fdt, const char *propname, const void *propval,
+static void check_search(void *fdt, const char *propname, const void *propval,
int proplen, ...)
{
va_list ap;
@@ -58,7 +58,8 @@ void check_search(void *fdt, const char
va_end(ap);
}
-void check_search_str(void *fdt, const char *propname, const char *propval,
...)
+static void check_search_str(void *fdt, const char *propname,
+const char *propval, ...)
{
va_list ap;
Index: dtc/tests/parent_offset.c
===
--- dtc.orig/tests/parent_offset.c 2008-08-04 15:15:19.0 +1000
+++ dtc/tests/parent_offset.c 2008-08-04 15:15:29.0 +1000
@@ -28,7 +28,7 @@
#include tests.h
#include testdata.h
-int path_parent_len(const char *path)
+static int path_parent_len(const char *path)
{
const char *p = strrchr(path, '/');
@@ -40,7 +40,7 @@ int path_parent_len(const char *path)
return p - path;
}
-void check_path(struct fdt_header *fdt, const char *path)
+static void check_path(struct fdt_header *fdt, const char *path)
{
char *parentpath;
int nodeoffset, parentoffset, parentpathoffset, pathparentlen;
Index: dtc/tests/path_offset.c
===
--- dtc.orig/tests/path_offset.c2008-08-04 15:14:18.0 +1000
+++ dtc/tests/path_offset.c 2008-08-04 15:14:20.0 +1000
@@ -28,7 +28,7 @@
#include tests.h
#include testdata.h
-int check_subnode(void *fdt, int parent, const char *name)
+static int check_subnode(void *fdt, int parent, const char *name)
