> This is a multi-part message in MIME format.
> --------------D2D5C20439DB0E109D59E290
> Content-Type: text/plain; charset=us-ascii
> Content-Transfer-Encoding: 7bit
>
> All,
>
> Nathan Scott wrote:
> >
> > If its not too big, you could post the patch to the list (even
> > before the issues are dealt with if you like - its easier for
> > people to give help if they can reproduce the problems you're
> > seeing themselves).
>
> Okay, here goes! I've attached the patch. B2Zipped, it's about 20K.
> Sorry if you're on a dialup, like me ;-(.
>
> If others would look over my code, and test the dickens (a very
> technical term) out of this patch, I'd appreciate it.
>
> To reiterate, the problems I'm having are:
>
> First: If I set an ACL, and immediatly attempt to excersize it
> (notablly turning off owner execute), it fails. Inserting an acl_get(2)
> or a stat(2) between the acl_set(2) and execl(2) attempt, corrects the
> problem.
>
> Second: sometimes after running the test suite, the executable becomes
> unable to execute any more, failing with 'Text file busy'. The XFS
> partition can't be unmounted after that point. Sorry, I've not been
> able to narrow this one any further.
>
> Third: my use of VOP_READ_LOCK in the VOP_ACL_GET(...) macro in
> xfs/linux/xfs_vnode.h. Is it necessary? Since it in turn calls
> VOP_ATTR_GET, it will attempt to lock it twice. Is that a Good Thing,
> or like in pthreads, a Bad Thing? Under Linux, by the by, the
> VOP_READ_LOCK is #defined away to nothing, so I can't look at the
> vop_read_lock function to understand it ;-(.
>
> Thanks, and have fun!
> --
>
This patch does not apply very well - you appear to be sending diffs to
files which do not currently appear in the xfs tree, e.g. the contents of
cmd/xfs/acl. It is also a patch against test8 rather than the current test10.
If possible could you please move your code base up to the latest development
tree, and redo the patch using diff -Nuar between an unmodified tree and your
modified tree.
Thanks
Steve
p.s. I notice that in xfs_vnodeops.c you added back in all the access checks
which were turned off. These were deliberately removed in the linux port since
they duplicate calls made from above the VFS layer via the permission
function into linvfs_permission. Do you have a reason for this.
The VN_BHV_READ_LOCK ... VN_BHV_READ_UNLOCK macros do evaluate to nothing,
they will turn into calls to obtain a read lock if cxfs is present on the
system. There are a very few occasions where a write lock is obtained, so
nesting is actually a problem in this case - however, when that work is done
someone else here at SGI will have to take care of it.
|