xfs
[Top] [All Lists]

XFS ACL Patch

To: linux-xfs@xxxxxxxxxxx
Subject: XFS ACL Patch
From: Danny <danscox@xxxxxxxxxxxxxx>
Date: Wed, 15 Nov 2000 15:43:44 -0500
Organization: Connex Inc
References: <3A11C6E3.62F04C3D@mindspring.com> <10011152053.ZM138831@wobbly.melbourne.sgi.com>
Sender: owner-linux-xfs@xxxxxxxxxxx
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!
--

Remember: life is too important to take seriously!

Danny

Attachment: acl.patch.bz2
Description: Binary data

<Prev in Thread] Current Thread [Next in Thread>