On Thursday July 19, [EMAIL PROTECTED] wrote:
> Ugh, not a good day for me today ... my earlier conclusion was right,
> but not the reasoning behind it ... hopefully this time I'll do better :-)
Looks good. Thanks for your helpful analysis.
>
> 0x34 bytes is the offset of ex_uuid in struct fh_export.
> %ecx == 0, which means ex_uuid was NULL.
Yup. That shouldn't happen, but I can see that it is possible.
There was another case were ex_uuid could conceivably be referenced
while NULL that I fixed a little while ago. Looks like I need to fix
this one too. Something like the following.
Thanks,
NeilBrown
Signed-off-by: Neil Brown <[EMAIL PROTECTED]>
### Diffstat output
./fs/nfsd/nfsfh.c | 20 +++++++++++++++-----
1 file changed, 15 insertions(+), 5 deletions(-)
diff .prev/fs/nfsd/nfsfh.c ./fs/nfsd/nfsfh.c
--- .prev/fs/nfsd/nfsfh.c 2007-07-13 17:41:48.000000000 +1000
+++ ./fs/nfsd/nfsfh.c 2007-07-20 12:53:36.000000000 +1000
@@ -566,13 +566,23 @@ enum fsid_source fsid_source(struct svc_
case FSID_DEV:
case FSID_ENCODE_DEV:
case FSID_MAJOR_MINOR:
- return FSIDSOURCE_DEV;
+ if (fhp->fh_export->ex_dentry->d_inode->i_sb->s_type->fs_flags
+ & FS_REQUIRES_DEV)
+ return FSIDSOURCE_DEV;
+ break;
case FSID_NUM:
- return FSIDSOURCE_FSID;
- default:
if (fhp->fh_export->ex_flags & NFSEXP_FSID)
return FSIDSOURCE_FSID;
- else
- return FSIDSOURCE_UUID;
+ break;
+ default:
+ break;
}
+ /* either a UUID type filehandle, or the filehandle doesn't
+ * match the export.
+ */
+ if (fhp->fh_export->ex_flags & NFSEXP_FSID)
+ return FSIDSOURCE_FSID;
+ if (fhp->fh_export->ex_uuid)
+ return FSIDSOURCE_UUID;
+ return FSIDSOURCE_DEV;
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
