<div dir="ltr"><div><div><div><div><div>Emmanuel,<br></div> I procrastinated too long on this :-/, It is July already :-(. I just looked at the man page in Linux and it is a bit confusing, so I am not sure how to go ahead.<br><br></div>For readdir_r(), I see:<br><br>DESCRIPTION<br> This function is deprecated; use readdir(3) instead.<br><br> The readdir_r() function was invented as a reentrant version of readdir(3). It reads<br> the next directory entry from the directory stream dirp, and returns it in the call‐<br> er-allocated buffer pointed to by entry. For details of the dirent structure, see<br> readir(3).<br><br></div>For readdir(3) I see:<br>ATTRIBUTES<br> For an explanation of the terms used in this section, see attributes(7).<br><br> ┌──────────┬───────────────┬──────────────────────────┐<br> │Interface │ Attribute │ Value │<br> ├──────────┼───────────────┼──────────────────────────┤<br> │readdir() │ Thread safety │ MT-Unsafe race:dirstream │<br> └──────────┴───────────────┴──────────────────────────┘<br><br> In the current POSIX.1 specification (POSIX.1-2008), readdir() is not required to be thread-safe. However, in modern implementations (including the glibc implementation), concur‐<br> rent calls to readdir() that specify different directory streams are thread-safe. In cases where multiple threads must read from the same directory stream, using readdir() with<br> external synchronization is still preferable to the use of the deprecated readdir_r(3) function. It is expected that a future version of POSIX.1 will require that readdir() be<br> thread-safe when concurrently employed on different directory streams.<br><br></div><br></div>So should we do readdir() with external locks for everything instead?<br><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Feb 11, 2016 at 2:35 PM, Emmanuel Dreyfus <span dir="ltr"><<a href="mailto:manu@netbsd.org" target="_blank">manu@netbsd.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Juste to make sure there is no misunderstanding here: unfortunately I<br>
do not have time right now to submit a fix. It would be nice if someone<br>
else coule look at it.<br>
<div class="HOEnZb"><div class="h5"><br>
On Wed, Feb 10, 2016 at 01:48:52PM +0000, Emmanuel Dreyfus wrote:<br>
> Hi<br>
><br>
> After obtaining a core in a regression, I noticed there are a few readdir()<br>
> use in threaded code. This is begging for a crash, as readdir() maintains<br>
> an internal state that will be trashed on concurent use. readdir_r()<br>
> should be used instead.<br>
><br>
> A quick search shows readdir(à usage here:<br>
> contrib/fuse-util/mount_util.c:30<br>
> extras/test/ld-preload-test/ld-preload-test.c:310<br>
> extras/test/test-ffop.c:550<br>
> libglusterfs/src/compat.c:256<br>
> libglusterfs/src/compat.c:315<br>
> libglusterfs/src/syscall.c:97<br>
> tests/basic/fops-sanity.c:662<br>
> tests/utils/arequal-checksum.c:331<br>
><br>
> Occurences in contrib, extra and tests are probably harmless are there<br>
> are usage in standalone programs that are not threaded. We are left with<br>
> three groups of problems:<br>
><br>
> 1) libglusterfs/src/compat.c:256 and libglusterfs/src/compat.c:315<br>
> This is Solaris compatibility code. Is it used at all?<br>
><br>
> 2) libglusterfs/src/syscall.c:97 This is the sys_readdir() wrapper,<br>
> which is in turn used in:<br>
> libglusterfs/src/run.c:284<br>
> xlators/features/bit-rot/src/stub/bit-rot-stub-helpers.c:582<br>
> xlators/features/changelog/lib/src/gf-history-changelog.c:854<br>
> xlators/features/index/src/index.c:471<br>
> xlators/mgmt/glusterd/src/glusterd-snapshot-utils.c<br>
> xlators/storage/posix/src/posix.c:3700<br>
> xlators/storage/posix/src/posix.c:5896<br>
><br>
> 3) We also find sys_readdir() in libglusterfs/src/common-utils.h for<br>
> GF_FOR_EACH_ENTRY_IN_DIR() which in turn appears in:<br>
> libglusterfs/src/common-utils.c:3979<br>
> libglusterfs/src/common-utils.c:4002<br>
> xlators/mgmt/glusterd/src/glusterd-hooks.c:365<br>
> xlators/mgmt/glusterd/src/glusterd-hooks.c:379<br>
> xlators/mgmt/glusterd/src/glusterd-store.c:651<br>
> xlators/mgmt/glusterd/src/glusterd-store.c:661<br>
> xlators/mgmt/glusterd/src/glusterd-store.c:1781<br>
> xlators/mgmt/glusterd/src/glusterd-store.c:1806<br>
> xlators/mgmt/glusterd/src/glusterd-store.c:3044<br>
> xlators/mgmt/glusterd/src/glusterd-store.c:3072<br>
> xlators/mgmt/glusterd/src/glusterd-store.c:3593<br>
> xlators/mgmt/glusterd/src/glusterd-store.c:3606<br>
> xlators/mgmt/glusterd/src/glusterd-store.c:4032<br>
> xlators/mgmt/glusterd/src/glusterd-store.c:4111<br>
><br>
> There a hive of sprious bugs to squash here.<br>
><br>
> --<br>
> Emmanuel Dreyfus<br>
> <a href="mailto:manu@netbsd.org">manu@netbsd.org</a><br>
> _______________________________________________<br>
> Gluster-devel mailing list<br>
> <a href="mailto:Gluster-devel@gluster.org">Gluster-devel@gluster.org</a><br>
> <a href="http://www.gluster.org/mailman/listinfo/gluster-devel" rel="noreferrer" target="_blank">http://www.gluster.org/mailman/listinfo/gluster-devel</a><br>
<br>
--<br>
Emmanuel Dreyfus<br>
<a href="mailto:manu@netbsd.org">manu@netbsd.org</a><br>
_______________________________________________<br>
Gluster-devel mailing list<br>
<a href="mailto:Gluster-devel@gluster.org">Gluster-devel@gluster.org</a><br>
<a href="http://www.gluster.org/mailman/listinfo/gluster-devel" rel="noreferrer" target="_blank">http://www.gluster.org/mailman/listinfo/gluster-devel</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">Pranith<br></div></div>
</div>