On Fri, Dec 01, 2000 at 08:05:15AM +0000, Thomas Graichen wrote:
> [also changed the subject to something more useful here]
>
> Andrew Gildfind <ajag@xxxxxxxxxxxxxxxxxxxxxxx> wrote:
>
> > Hi Thomas,
>
> > Could you put a printk at the start of the sys_attrctl function defined
> > in linux/fs/stat.c, and rerun the QA test 020, or drive the attribute code
> > directly using xfs_attr, and check whether the printk actually gets called.
>
> > If it doesn't then we know for sure it's the syscall that isn't hooked up
> > correctly. unistd.h and entry.S looked like the only places which needed
> > to be changed but I may have missed something. If it does hit the the
> > attribute
> > syscall, then there's a more serious problem somewhere else in the code.
>
> looks like this is the case:
>
> ...
> Start mounting filesystem: ide0(3,8)
> Ending clean XFS mount for filesystem: ide0(3,8)
> here is sys_attrctl
> here is sys_attrctl
> here is sys_attrctl
> here is sys_attrctl
> here is sys_attrctl
> here is sys_attrctl
> here is sys_attrctl
> here is sys_attrctl
> here is sys_attrctl
> here is sys_attrctl
> here is sys_attrctl
> here is sys_attrctl
> here is sys_attrctl
> Start mounting filesystem: ide0(3,8)
> Ending clean XFS mount for filesystem: ide0(3,8)
> ppc:/usr/src/xfs/cmd/xfs/stress #
>
> this is the dmesg of check 020 - it gets called - so the problem is
> somethere deeper ... maybe anykind of endian stuff of the parameters?
> (just an idea) ... do you have any other idea?
>
> t
>
> --
> thomas.graichen@xxxxxxxxxxxxxx
> technical director innominate AG
> clustering & security the linux architects
> tel: +49-30-308806-13 fax: -77 http://www.innominate.com
Couple of observations first:
- xfs_attr always calls the attr_* and therefore the system call with
a path, rather than a file descriptor.
- xfs_attr is always called with ATTR_DONT_FOLLOW - that is it never follows
symlinks
The code looks like:
asmlinkage long sys_attrctl(attr_obj_t obj, int type,
attr_op_t *ops, int count)
{
int error = 0;
struct inode *inode;
struct dentry *dentry;
struct file *f = NULL;
struct nameidata nd;
if (count <= 0)
return -EINVAL;
lock_kernel();
switch (type) {
case ATTR_TYPE_FD:
if (! (f = fget(obj.fd))) {
error = -ENOENT;
goto unlock;
}
dentry = f->f_dentry;
break;
case ATTR_TYPE_PATH:
/* follow symlinks */
error = user_path_walk(obj.path, &nd);
if (error)
goto unlock;
dentry = nd.dentry;
break;
case ATTR_TYPE_LPATH:
error = user_path_walk_link(obj.path, &nd);
if (error)
goto unlock;
dentry = nd.dentry;
break;
case ATTR_TYPE_PID:
error = -ENOSYS;
goto unlock;
default:
error = -EINVAL;
goto unlock;
}
Which means that on the way in (and we know that at least its hitting the
syscall), it will always take the ATTR_TYPE_LPATH case.
I've had another look at your QA results (ppc.15-11-2000) they give the
following:
QA output created by 020
*** list non-existant file
*** print attributes
attr_list: Bad address
Could not list attributes for <TESTFILE>
!!! error return
*** list non-xfs file (in /proc)
*** print attributes
attr_list: Bad address
...
The first test checks the non-existent file case, which means that we
should come into the syscall, walk the path and die immediately with
an ENOENT, ie. we should never get into XFS code at all.
The fact that we are getting a bad address even in this case suggests to
me that there maybe something weird happening because the path comes
out of an attr_obj_t structure - are we sure that those structures are
the same size in userland/kernel on PPC?
So... can you whack in another printk just after the switch and check whether
the path lookup ever works - if it does I'm back in stumped-land, if not
we have our culprit..
Andrew
--
Andrew Gildfind - R&D Software Engineer - SGI PTG Melbourne Australia
email: ajag@xxxxxxxxxxxxxxxxx - work: +61.3.9834.8200 home: +61.3.9421.5335
--y0ulUmNC+osPPQO6--
|