[Gluster-devel] Fwd: [Gluster-Maintainers] Build failed in Jenkins: regression-test-burn-in #4067
C7 nightly has a crash too.
-- Forwarded message -
From:
Date: Sat, 18 Aug 2018 at 00:01
Subject: [Gluster-Maintainers] Build failed in Jenkins:
regression-test-burn-in #4067
To:
See <
https://build.gluster.org/job/regression-test-burn-in/4067/display/redirect?page=changes
>
Changes:
[Amar Tumballi] jbr : fix coverity issues in jbr
[Amar Tumballi] statedump : fix coverity issues
[Amar Tumballi] glusterd: coverity defects fix introduced by commit 1f3bfe7
[Amar Tumballi] features/acl: Fix a possible null dereference
[Amar Tumballi] meta : fix coverity in meta-helpers.c
[Amar Tumballi] nfs-server-mount : fix coverity issues in mount3.c
[Amar Tumballi] posix: FORWARD_NULL coverity fix
[Amar Tumballi] locks: FORWARD_NULL coverity fix
[Amar Tumballi] doc: Add details around xlator categories
[Amar Tumballi] features/changelog: Fix missing unlocks
--
[...truncated 981.94 KB...]
this = 0x7f6f2c007e50
priv = 0x7f6f2c0ab440
stub = 0x0
tmp = 0x0
list = {next = 0x7f6f0f7fde90, prev = 0x7f6f0f7fde90}
count = 0
do_fsync = true
__FUNCTION__ = "posix_fsyncer"
#3 0x7f6f3d561e25 in start_thread () from /lib64/libpthread.so.0
No symbol table info available.
#4 0x7f6f3cc26bad in clone () from /lib64/libc.so.6
No symbol table info available.
Thread 10 (Thread 0x7f6f24233700 (LWP 28244)):
#0 0x7f6f3d565d42 in pthread_cond_timedwait@@GLIBC_2.3.2 () from
/lib64/libpthread.so.0
No symbol table info available.
#1 0x7f6f2a810737 in iot_worker (data=0x7f6f2c068f40) at <
https://build.gluster.org/job/regression-test-burn-in/ws/xlators/performance/io-threads/src/io-threads.c
>:195
conf = 0x7f6f2c068f40
this = 0x7f6f2c020020
stub = 0x0
sleep_till = {tv_sec = 1534527479, tv_nsec = 542650613}
ret = 0
pri = -1
bye = false
__FUNCTION__ = "iot_worker"
#2 0x7f6f3d561e25 in start_thread () from /lib64/libpthread.so.0
No symbol table info available.
#3 0x7f6f3cc26bad in clone () from /lib64/libc.so.6
No symbol table info available.
Thread 9 (Thread 0x7f6f3ea2a780 (LWP 28136)):
#0 0x7f6f3d562f97 in pthread_join () from /lib64/libpthread.so.0
No symbol table info available.
#1 0x7f6f3e589159 in event_dispatch_epoll (event_pool=0x770c30) at <
https://build.gluster.org/job/regression-test-burn-in/ws/libglusterfs/src/event-epoll.c
>:750
i = 1
t_id = 140115546580736
pollercount = 1
ret = 0
ev_data = 0x7bc6c0
thread_name = "epoll000\000\000"
__FUNCTION__ = "event_dispatch_epoll"
#2 0x7f6f3e546b4a in event_dispatch (event_pool=0x770c30) at <
https://build.gluster.org/job/regression-test-burn-in/ws/libglusterfs/src/event.c
>:124
ret = -1
__FUNCTION__ = "event_dispatch"
#3 0x0040b539 in ?? ()
No symbol table info available.
#4 0x in ?? ()
No symbol table info available.
Thread 8 (Thread 0x7f6f35afe700 (LWP 28137)):
#0 0x7f6f3d568f3d in nanosleep () from /lib64/libpthread.so.0
No symbol table info available.
#1 0x7f6f3e520ef4 in gf_timer_proc (data=0x7796f0) at <
https://build.gluster.org/job/regression-test-burn-in/ws/libglusterfs/src/timer.c
>:202
now = 516473032615399
now_ts = {tv_sec = 516473, tv_nsec = 32615399}
reg = 0x7796f0
sleepts = {tv_sec = 1, tv_nsec = 0}
event = 0x779700
tmp = 0x779700
old_THIS = 0x7f6f3e81a2c0
#2 0x7f6f3d561e25 in start_thread () from /lib64/libpthread.so.0
No symbol table info available.
#3 0x7f6f3cc26bad in clone () from /lib64/libc.so.6
No symbol table info available.
Thread 7 (Thread 0x7f6f24274700 (LWP 28202)):
#0 0x7f6f3d565d42 in pthread_cond_timedwait@@GLIBC_2.3.2 () from
/lib64/libpthread.so.0
No symbol table info available.
#1 0x7f6f2a810737 in iot_worker (data=0x7f6f2c068f40) at <
https://build.gluster.org/job/regression-test-burn-in/ws/xlators/performance/io-threads/src/io-threads.c
>:195
conf = 0x7f6f2c068f40
this = 0x7f6f2c020020
stub = 0x0
sleep_till = {tv_sec = 1534527479, tv_nsec = 542650613}
ret = 0
pri = -1
bye = false
__FUNCTION__ = "iot_worker"
#2 0x7f6f3d561e25 in start_thread () from /lib64/libpthread.so.0
No symbol table info available.
#3 0x7f6f3cc26bad in clone () from /lib64/libc.so.6
No symbol table info available.
Thread 6 (Thread 0x7f6f2647a700 (LWP 28150)):
#0 0x7f6f3cc1dc73 in select () from /lib64/libc.so.6
No symbol table info available.
#1 0x7f6f2b92aace in changelog_ev_dispatch (data=0x7f6f2c08c0a8) at <
https://build.gluster.org/job/regression-test-burn-in/ws/xlators/features/changelog/src/changelog-ev-handle.c
>:350
ret = 3
opaque = 0x0
this = 0x7f6f2c0116b0
c_clnt = 0x7f6f2c08c0a8
tv = {tv_sec = 0, tv_usec = 128007}
__FUNCTION__
[Gluster-devel] Fwd: [Gluster-Maintainers] Build failed in Jenkins: regression-test-with-multiplex #831
This is the first nightly job failure since we reopened the master branch.
Crash seems to be from fini () code path. Need investigation and RCA here.
-- Forwarded message -
From:
Date: Fri, 17 Aug 2018 at 23:54
Subject: [Gluster-Maintainers] Build failed in Jenkins:
regression-test-with-multiplex #831
To: ,
See <
https://build.gluster.org/job/regression-test-with-multiplex/831/display/redirect?page=changes
>
Changes:
[Amar Tumballi] jbr : fix coverity issues in jbr
[Amar Tumballi] statedump : fix coverity issues
[Amar Tumballi] glusterd: coverity defects fix introduced by commit 1f3bfe7
[Amar Tumballi] features/acl: Fix a possible null dereference
[Amar Tumballi] meta : fix coverity in meta-helpers.c
[Amar Tumballi] nfs-server-mount : fix coverity issues in mount3.c
[Amar Tumballi] posix: FORWARD_NULL coverity fix
[Amar Tumballi] locks: FORWARD_NULL coverity fix
[Amar Tumballi] doc: Add details around xlator categories
[Amar Tumballi] features/changelog: Fix missing unlocks
--
[...truncated 1.01 MB...]
top = 0x0
victim = 0x0
trav_p = 0x0
count = 0
victim_found = false
ctx = 0x16cc010
__FUNCTION__ = "posix_health_check_thread_proc"
#3 0x7fba8e08ee25 in start_thread () from /lib64/libpthread.so.0
No symbol table info available.
#4 0x7fba8d753bad in clone () from /lib64/libc.so.6
No symbol table info available.
Thread 8 (Thread 0x7fba2b5f0700 (LWP 31062)):
#0 0x7fba8d71a56d in nanosleep () from /lib64/libc.so.6
No symbol table info available.
#1 0x7fba8d71a404 in sleep () from /lib64/libc.so.6
No symbol table info available.
#2 0x7fba816f2081 in posix_disk_space_check_thread_proc
(data=0x7fba505beff0) at <
https://build.gluster.org/job/regression-test-with-multiplex/ws/xlators/storage/posix/src/posix-helpers.c
>:2286
this = 0x7fba505beff0
priv = 0x7fba53fe9490
interval = 5
ret = 0
__FUNCTION__ = "posix_disk_space_check_thread_proc"
#3 0x7fba8e08ee25 in start_thread () from /lib64/libpthread.so.0
No symbol table info available.
#4 0x7fba8d753bad in clone () from /lib64/libc.so.6
No symbol table info available.
Thread 7 (Thread 0x7fba703b3700 (LWP 31055)):
#0 0x7fba8e092d42 in pthread_cond_timedwait@@GLIBC_2.3.2 () from
/lib64/libpthread.so.0
No symbol table info available.
#1 0x7fba7b345737 in iot_worker (data=0x7fba53ba86b0) at <
https://build.gluster.org/job/regression-test-with-multiplex/ws/xlators/performance/io-threads/src/io-threads.c
>:195
conf = 0x7fba53ba86b0
this = 0x7fba53277620
stub = 0x0
sleep_till = {tv_sec = 1534518836, tv_nsec = 345143975}
ret = 0
pri = -1
bye = false
__FUNCTION__ = "iot_worker"
#2 0x7fba8e08ee25 in start_thread () from /lib64/libpthread.so.0
No symbol table info available.
#3 0x7fba8d753bad in clone () from /lib64/libc.so.6
No symbol table info available.
Thread 6 (Thread 0x7fba704f5700 (LWP 31054)):
#0 0x7fba8e092995 in pthread_cond_wait@@GLIBC_2.3.2 () from
/lib64/libpthread.so.0
No symbol table info available.
#1 0x7fba7aae8308 in index_worker (data=0x7fba5327d8a0) at <
https://build.gluster.org/job/regression-test-with-multiplex/ws/xlators/features/index/src/index.c
>:218
priv = 0x7fba53b980f0
this = 0x7fba5327d8a0
stub = 0x0
bye = false
#2 0x7fba8e08ee25 in start_thread () from /lib64/libpthread.so.0
No symbol table info available.
#3 0x7fba8d753bad in clone () from /lib64/libc.so.6
No symbol table info available.
Thread 5 (Thread 0x7fba1d4d5700 (LWP 30825)):
#0 0x7fba8e092995 in pthread_cond_wait@@GLIBC_2.3.2 () from
/lib64/libpthread.so.0
No symbol table info available.
#1 0x7fba8edf9da0 in rpcsvc_request_handler (arg=0x7fba7c046210) at <
https://build.gluster.org/job/regression-test-with-multiplex/ws/rpc/rpc-lib/src/rpcsvc.c
>:1983
program = 0x7fba7c046210
req = 0x0
actor = 0x0
done = false
ret = 0
__FUNCTION__ = "rpcsvc_request_handler"
#2 0x7fba8e08ee25 in start_thread () from /lib64/libpthread.so.0
No symbol table info available.
#3 0x7fba8d753bad in clone () from /lib64/libc.so.6
No symbol table info available.
Thread 4 (Thread 0x7fba1dcd6700 (LWP 30824)):
#0 0x7fba8e092995 in pthread_cond_wait@@GLIBC_2.3.2 () from
/lib64/libpthread.so.0
No symbol table info available.
#1 0x7fba8edf9da0 in rpcsvc_request_handler (arg=0x7fba7c0465d0) at <
https://build.gluster.org/job/regression-test-with-multiplex/ws/rpc/rpc-lib/src/rpcsvc.c
>:1983
program = 0x7fba7c0465d0
req = 0x0
actor = 0x7fba7a449700
done = false
ret = 0
__FUNCTION__ = "rpcsvc_request_handler"
#2 0x7fba8e08ee25 in start_thread () from /lib64/libpthread.so.0
No symbol table info available.
#3 0x7fba8d753bad in clone () from /lib64/libc.so
Re: [Gluster-devel] Glusterfs v4.1.1 issue encountered while executing test case ./tests/basic/namespace.t
Hi Abhay, Would it be possible for you to change the namsepace.t and trash.t (as discussed in IRC) tests to work with both endian architectures? Both failures seem to be linked to the issue that SuperFastHash() provides different values on little & big endian architectures. You could do something like `lspcu | grep "Little Endian" to determine the endianess and this value can be used to have the right behavior in tests. Please feel free to let me know if you need more assistance in fixing both namespace.t and trash.t tests. Regards, Vijay On Mon, Aug 13, 2018 at 12:26 PM Abhay Singh wrote: > Hi, > I am working on Glusterfs v4.1.1 for Ubuntu 16.04 on big endian > architecture. After successful build and running the test cases, I > encountered a test case failure. The test case is:- > ·./tests/basic/namespace.t > > In the test case *./tests/basic/namespace.t*, a NAMESPACE_HASH is > generated after calling a SuperFastHash() function on the corresponding > folder names. This hash differs on big endian and little endian > architectures. Therefore, I have changed the code accordingly. Although > there is another subtest in this test which fails with the following error:- > TEST 30 (line 119): Y check_samples CREATE 1268089390 /namespace3/file > patchy0 > getfattr: /d/backends/patchy0/namespace3/file: No such file or directory > > As seen above, the error is occurring because the folder > /d/backends/patchy0/namespace3/ doesn’t contain “file”. However, I resolved > this subtest by changing the folder to /d/backends/patchy6/namespace3/ > where “file” is actually present. > But same is not the case for little endian architectures where the test > case passes without any changes. > The type of filesystem /d/backends is “ext4” and there is enough space > allocated to the directory. > Therefore, could you please provide me with some more insight as to why is > this happening? > > > *Thanks and Regards,* > *Abhay Singh* > ___ > Gluster-devel mailing list > Gluster-devel@gluster.org > https://lists.gluster.org/mailman/listinfo/gluster-devel ___ Gluster-devel mailing list Gluster-devel@gluster.org https://lists.gluster.org/mailman/listinfo/gluster-devel
[Gluster-devel] Coverity covscan for 2018-08-17-522352d4 (master branch)
GlusterFS Coverity covscan results for the master branch are available from http://download.gluster.org/pub/gluster/glusterfs/static-analysis/master/glusterfs-coverity/2018-08-17-522352d4/ Coverity covscan results for other active branches are also available at http://download.gluster.org/pub/gluster/glusterfs/static-analysis/ ___ Gluster-devel mailing list Gluster-devel@gluster.org https://lists.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] Problems about acl_get_file used in posix_pacl_get
On Fri, Aug 17, 2018 at 07:11:12PM +0800, Kinglong Mee wrote: > Hi Niels, > > On 2018/8/17 18:14, Niels de Vos wrote: > > On Fri, Aug 17, 2018 at 05:22:17PM +0800, Kinglong Mee wrote: > >> Hi Niels, > >> > >> On 2018/8/17 17:13, Niels de Vos wrote: > >>> On Fri, Aug 17, 2018 at 03:04:43PM +0800, Kinglong Mee wrote: > Hello folks, > > nfs-ganesha using the new gfapi named glfs_h_acl_set/glfs_h_acl_get, > at xlator posix, glusterfsd calls acl_get_file/acl_set_file (libacl > functions) to process xattrs. > > By default, sys_lsetxattr/sys_llistxattr/sys_lgetxattr/sys_lremovexattr > are used to process xattrs. > But, unfortunately, those two functions do syscall by getxattr/setxattr. > I don't think that is we want. > > Is it a known problem ? > >>> > >>> There should not be a problem for libacl to use syscalls directly. The > >>> Gluster sources use sys_ so that there can be wrappers for the > >>> differences between OS's. In the end, these sys_ functions will > >>> mostly call the with (adapted) arguments. > >>> > >>> I do not know what problem you are facing, but I can imagine that there > >>> is a 'getxattr' symbol in the executable image that gets called by > >>> libacl, instead of the 'getxattr' syscall. This will likely result in > >>> very strange behaviour, if not segfaults. > >> > >> Sorry for my unclear description. > >> The real problem here is libacl gets/sets xattrs by getxattr/setxattr > >> which follow symbolic links, > >> but, posix xlator get/set xattrs by sys_l*xattr which do not follow > >> symbolic links. > > > > Permission checking is done by the kernel. I do not think setting ACLs > > on a symlink makes much sense. More liberal permissions on the symlink > > will not help with accessing the contents, and restricting permissions > > on a symlink still give the user to access the contents through its real > > filename. > > > > Is there a reason that having ACLs on a symlink can have benefits? > > Sorry, i don't know. > > Md-cache supports caching GF_POSIX_ACL_ACCESS/GF_POSIX_ACL_DEFAULT right now, > but posix_xattr_fill (call _posix_xattr_get_set) does not fill those two > xattrs. > > After I adds the posix_pacl_get to _posix_xattr_get_set, > there are some problems for symlink files. > So that, I find the different between acl_get_file and > sys_llistxattr/sys_lgetxattr. Because (Linux) filesystems do not have ACLs on symlinks, I think md-cache should also not fetch/cache ACLs on symlinks. Poornima, do you have an opinion about this? Niels ___ Gluster-devel mailing list Gluster-devel@gluster.org https://lists.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] Problems about acl_get_file used in posix_pacl_get
Hi Niels, On 2018/8/17 18:14, Niels de Vos wrote: > On Fri, Aug 17, 2018 at 05:22:17PM +0800, Kinglong Mee wrote: >> Hi Niels, >> >> On 2018/8/17 17:13, Niels de Vos wrote: >>> On Fri, Aug 17, 2018 at 03:04:43PM +0800, Kinglong Mee wrote: Hello folks, nfs-ganesha using the new gfapi named glfs_h_acl_set/glfs_h_acl_get, at xlator posix, glusterfsd calls acl_get_file/acl_set_file (libacl functions) to process xattrs. By default, sys_lsetxattr/sys_llistxattr/sys_lgetxattr/sys_lremovexattr are used to process xattrs. But, unfortunately, those two functions do syscall by getxattr/setxattr. I don't think that is we want. Is it a known problem ? >>> >>> There should not be a problem for libacl to use syscalls directly. The >>> Gluster sources use sys_ so that there can be wrappers for the >>> differences between OS's. In the end, these sys_ functions will >>> mostly call the with (adapted) arguments. >>> >>> I do not know what problem you are facing, but I can imagine that there >>> is a 'getxattr' symbol in the executable image that gets called by >>> libacl, instead of the 'getxattr' syscall. This will likely result in >>> very strange behaviour, if not segfaults. >> >> Sorry for my unclear description. >> The real problem here is libacl gets/sets xattrs by getxattr/setxattr which >> follow symbolic links, >> but, posix xlator get/set xattrs by sys_l*xattr which do not follow symbolic >> links. > > Permission checking is done by the kernel. I do not think setting ACLs > on a symlink makes much sense. More liberal permissions on the symlink > will not help with accessing the contents, and restricting permissions > on a symlink still give the user to access the contents through its real > filename. > > Is there a reason that having ACLs on a symlink can have benefits? Sorry, i don't know. Md-cache supports caching GF_POSIX_ACL_ACCESS/GF_POSIX_ACL_DEFAULT right now, but posix_xattr_fill (call _posix_xattr_get_set) does not fill those two xattrs. After I adds the posix_pacl_get to _posix_xattr_get_set, there are some problems for symlink files. So that, I find the different between acl_get_file and sys_llistxattr/sys_lgetxattr. thanks, Kinglong Mee ___ Gluster-devel mailing list Gluster-devel@gluster.org https://lists.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] Problems about acl_get_file used in posix_pacl_get
On Fri, Aug 17, 2018 at 05:22:17PM +0800, Kinglong Mee wrote: > Hi Niels, > > On 2018/8/17 17:13, Niels de Vos wrote: > > On Fri, Aug 17, 2018 at 03:04:43PM +0800, Kinglong Mee wrote: > >> Hello folks, > >> > >> nfs-ganesha using the new gfapi named glfs_h_acl_set/glfs_h_acl_get, > >> at xlator posix, glusterfsd calls acl_get_file/acl_set_file (libacl > >> functions) to process xattrs. > >> > >> By default, sys_lsetxattr/sys_llistxattr/sys_lgetxattr/sys_lremovexattr > >> are used to process xattrs. > >> But, unfortunately, those two functions do syscall by getxattr/setxattr. > >> I don't think that is we want. > >> > >> Is it a known problem ? > > > > There should not be a problem for libacl to use syscalls directly. The > > Gluster sources use sys_ so that there can be wrappers for the > > differences between OS's. In the end, these sys_ functions will > > mostly call the with (adapted) arguments. > > > > I do not know what problem you are facing, but I can imagine that there > > is a 'getxattr' symbol in the executable image that gets called by > > libacl, instead of the 'getxattr' syscall. This will likely result in > > very strange behaviour, if not segfaults. > > Sorry for my unclear description. > The real problem here is libacl gets/sets xattrs by getxattr/setxattr which > follow symbolic links, > but, posix xlator get/set xattrs by sys_l*xattr which do not follow symbolic > links. Permission checking is done by the kernel. I do not think setting ACLs on a symlink makes much sense. More liberal permissions on the symlink will not help with accessing the contents, and restricting permissions on a symlink still give the user to access the contents through its real filename. Is there a reason that having ACLs on a symlink can have benefits? Niels ___ Gluster-devel mailing list Gluster-devel@gluster.org https://lists.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] Problems about acl_get_file used in posix_pacl_get
Hi Niels, On 2018/8/17 17:13, Niels de Vos wrote: > On Fri, Aug 17, 2018 at 03:04:43PM +0800, Kinglong Mee wrote: >> Hello folks, >> >> nfs-ganesha using the new gfapi named glfs_h_acl_set/glfs_h_acl_get, >> at xlator posix, glusterfsd calls acl_get_file/acl_set_file (libacl >> functions) to process xattrs. >> >> By default, sys_lsetxattr/sys_llistxattr/sys_lgetxattr/sys_lremovexattr are >> used to process xattrs. >> But, unfortunately, those two functions do syscall by getxattr/setxattr. >> I don't think that is we want. >> >> Is it a known problem ? > > There should not be a problem for libacl to use syscalls directly. The > Gluster sources use sys_ so that there can be wrappers for the > differences between OS's. In the end, these sys_ functions will > mostly call the with (adapted) arguments. > > I do not know what problem you are facing, but I can imagine that there > is a 'getxattr' symbol in the executable image that gets called by > libacl, instead of the 'getxattr' syscall. This will likely result in > very strange behaviour, if not segfaults. Sorry for my unclear description. The real problem here is libacl gets/sets xattrs by getxattr/setxattr which follow symbolic links, but, posix xlator get/set xattrs by sys_l*xattr which do not follow symbolic links. thanks, Kinglong Mee ___ Gluster-devel mailing list Gluster-devel@gluster.org https://lists.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] Problems about acl_get_file used in posix_pacl_get
On Fri, Aug 17, 2018 at 03:04:43PM +0800, Kinglong Mee wrote: > Hello folks, > > nfs-ganesha using the new gfapi named glfs_h_acl_set/glfs_h_acl_get, > at xlator posix, glusterfsd calls acl_get_file/acl_set_file (libacl > functions) to process xattrs. > > By default, sys_lsetxattr/sys_llistxattr/sys_lgetxattr/sys_lremovexattr are > used to process xattrs. > But, unfortunately, those two functions do syscall by getxattr/setxattr. > I don't think that is we want. > > Is it a known problem ? There should not be a problem for libacl to use syscalls directly. The Gluster sources use sys_ so that there can be wrappers for the differences between OS's. In the end, these sys_ functions will mostly call the with (adapted) arguments. I do not know what problem you are facing, but I can imagine that there is a 'getxattr' symbol in the executable image that gets called by libacl, instead of the 'getxattr' syscall. This will likely result in very strange behaviour, if not segfaults. None of the Gluster libraries or xlators is allowed to expose symbols that collide with 'standard' ones. This includes syscalls or symbols from commonly used libraries. To fix this, all symbols in the Gluster libraries should have a gf_ prefix. This is not commonly done for xlators, and we have had issues with that before. All FOPs and callbacks in xlators should in general be marked static to prevent symbol collisions. HTH, Niels ___ Gluster-devel mailing list Gluster-devel@gluster.org https://lists.gluster.org/mailman/listinfo/gluster-devel
[Gluster-devel] Problems about acl_get_file used in posix_pacl_get
Hello folks,
nfs-ganesha using the new gfapi named glfs_h_acl_set/glfs_h_acl_get,
at xlator posix, glusterfsd calls acl_get_file/acl_set_file (libacl functions)
to process xattrs.
By default, sys_lsetxattr/sys_llistxattr/sys_lgetxattr/sys_lremovexattr are
used to process xattrs.
But, unfortunately, those two functions do syscall by getxattr/setxattr.
I don't think that is we want.
Is it a known problem ?
following are acl_get_file/acl_set_file functions
--
/* 23.4.16 */
acl_t
acl_get_file(const char *path_p, acl_type_t type)
{
const size_t size_guess = acl_ea_size(16);
char *ext_acl_p = alloca(size_guess);
const char *name;
int retval;
switch(type) {
case ACL_TYPE_ACCESS:
name = ACL_EA_ACCESS;
break;
case ACL_TYPE_DEFAULT:
name = ACL_EA_DEFAULT;
break;
default:
errno = EINVAL;
return NULL;
}
if (!ext_acl_p)
return NULL;
retval = getxattr(path_p, name, ext_acl_p, size_guess);
if (retval == -1 && errno == ERANGE) {
retval = getxattr(path_p, name, NULL, 0);
if (retval > 0) {
ext_acl_p = alloca(retval);
if (!ext_acl_p)
return NULL;
retval = getxattr(path_p, name, ext_acl_p, retval);
}
}
if (retval > 0) {
acl_t acl = __acl_from_xattr(ext_acl_p, retval);
return acl;
} else if (retval == 0 || errno == ENOATTR || errno == ENODATA) {
struct stat st;
if (stat(path_p, &st) != 0)
return NULL;
if (type == ACL_TYPE_DEFAULT) {
if (S_ISDIR(st.st_mode))
return acl_init(0);
else {
errno = EACCES;
return NULL;
}
} else
return acl_from_mode(st.st_mode);
} else
return NULL;
}
/* 23.4.22 */
int
acl_set_file(const char *path_p, acl_type_t type, acl_t acl)
{
acl_obj *acl_obj_p = ext2int(acl, acl);
char *ext_acl_p;
const char *name;
size_t size;
int error;
if (!acl_obj_p)
return -1;
switch (type) {
case ACL_TYPE_ACCESS:
name = ACL_EA_ACCESS;
break;
case ACL_TYPE_DEFAULT:
name = ACL_EA_DEFAULT;
break;
default:
errno = EINVAL;
return -1;
}
if (type == ACL_TYPE_DEFAULT) {
struct stat st;
if (stat(path_p, &st) != 0)
return -1;
/* Only directories may have default ACLs. */
if (!S_ISDIR(st.st_mode)) {
errno = EACCES;
return -1;
}
}
ext_acl_p = __acl_to_xattr(acl_obj_p, &size);
if (!ext_acl_p)
return -1;
error = setxattr(path_p, name, (char *)ext_acl_p, size, 0);
free(ext_acl_p);
return error;
}
thanks,
Kinglong Mee
___
Gluster-devel mailing list
Gluster-devel@gluster.org
https://lists.gluster.org/mailman/listinfo/gluster-devel
