Date:   Thu, 7 Dec 2000 21:22:18 +1100
From:   Andrew Gildfind <ajag@fudge.melbourne.sgi.com>
To:     thomas.graichen@innominate.de
Cc:     linux-xfs@oss.sgi.com
Subject: Re: (fwd) Re: sys_attrctl not working on ppc
Message-ID: <20001207212218.A7184@fudge.melbourne.sgi.com>
References: <20001207084102.8701325994@orange.bln.innominate.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
In-Reply-To: <20001207084102.8701325994@orange.bln.innominate.de>; from graichen@innominate.de on Thu, Dec 07, 2000 at 09:41:02AM +0100
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On Thu, Dec 07, 2000 at 09:41:02AM +0100, Thomas Graichen wrote:
> Andrew Gildfind <ajag@fudge.melbourne.sgi.com> wrote:
> 
> > 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)
> ...
> 
> > 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?
> 
> looks like (i hope this test is correct)
> 
> ppc:/usr/src/xfs/linux # gdb fs/xfs/xfs.o 
> GNU gdb 4.18
> Copyright 1998 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you are
> welcome to change it and/or distribute copies of it under certain conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB.  Type "show warranty" for details.
> This GDB was configured as "ppc-suse-linux"...
> (gdb) print sizeof(attr_obj_t)
> $1 = 4
> (gdb) quit
> ppc:/usr/src/xfs/linux # gdb ../cmd/xfs/db/xfs_db 
> GNU gdb 4.18
> Copyright 1998 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you are
> welcome to change it and/or distribute copies of it under certain conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB.  Type "show warranty" for details.
> This GDB was configured as "ppc-suse-linux"...
> (gdb) print sizeof(attr_obj_t)
> $1 = 4
> (gdb)
> 
> > 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..
> 
> ok - here is the result:
> 
> Start mounting filesystem: ide0(3,8)
> Ending clean XFS mount for filesystem: ide0(3,8)
> ATTR_TYPE_PATH
> ATTR_TYPE_PATH
> ATTR_TYPE_PATH
> ATTR_TYPE_PATH
> ATTR_TYPE_PATH
> ATTR_TYPE_PATH
> ATTR_TYPE_PATH
> ATTR_TYPE_PATH
> ATTR_TYPE_PATH
> ATTR_TYPE_PATH
> ATTR_TYPE_PATH
> ATTR_TYPE_PATH
> ATTR_TYPE_PATH
> Start mounting filesystem: ide0(3,8)
> Ending clean XFS mount for filesystem: ide0(3,8)
> 

So to confirm the call made its way through the switch ok and went on to call
the vfs? Is ATTR_TYPE_PATH the type that came in with the call? If it was
then there's a bug in the library that maps the IRIXy flags to the attrctl
flags (that's a separate issue tho).

Do you have any more recent stress test outputs I could have a look at?

> so any new ideas?

One of the copy-ins later in the code is stuffed? Given that it already
passes on little-endian ia32 (all the on-disk stuff is big-endian) it's
probably not likely to be an endian issues in the core -> disk -> core 
conversion problem but I'm not really sure what's going on.

If you can let me have a current stress test output I'll have a look 
and see if I can think of anything else.

Andrew

-- 
Andrew Gildfind - R&D Software Engineer - SGI PTG Melbourne Australia
email: ajag@melbourne.sgi.com - work: +61.3.9834.8200 home: +61.3.9421.5335