Re: [Gluster-devel] mem-pool.c magic trailer causes SIGBUS, fix or remove?
Hi Amar, So fix is what I did first, but someone was wondering about the additional cost of the alignment calculation in the memory allocation path. (Though, the unaligned write of the trailer might be as many cycles of slowdown as a roundup calculation on platforms that handle unaligned access in microcode). The pull request with the fix is at: https://github.com/gluster/glusterfs/pull/2669 With that, glusterd can now run on SPARC64 - without crashing in one of the first few memory allocations. Though, I still can not get glusterd on SPARC64 to sync up with the pool. Whether with the trailer fixed, or the trailer removed. I end up with cksum errors on /var/lib/glusterfs/ files - starting with a completely clean /var/lib/glusterfs on the SPARC64 box. The 2 big differences between the SPARC64 host and the other hosts that are happily synced are: - distro (SPARC64 is debian; others are Fedora) - endianness. Wondering if either of those could be a factor? Thanks, Paul On Thu, 29 Jul 2021, Amar Tumballi wrote: Thanks for the initiative Paul. Let me answer the major question from the thread. Remove the trailer? Or fix it? Ideal one is to fix it, as we do use mem-pool info to identify leaks etc through statedumps of the process. Remove can be an option on SPARC to start with if fixing is time consuming. I recommend removing the trailer within a #ifdef codeblock, so it may continue work in places where its already working. regards, -- Paul Jakma | p...@jakma.org | @pjakma | Key ID: 0xD86BF79464A2FF6A Fortune: Honesty pays, but it doesn't seem to pay enough to suit some people. -- F. M. Hubbard --- Community Meeting Calendar: Schedule - Every 2nd and 4th Tuesday at 14:30 IST / 09:00 UTC Bridge: https://meet.google.com/cpu-eiue-hvk Gluster-devel mailing list Gluster-devel@gluster.org https://lists.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] mem-pool.c magic trailer causes SIGBUS, fix or remove?
Thanks for the initiative Paul. Let me answer the major question from the thread. > > Remove the trailer? Or fix it? Ideal one is to fix it, as we do use mem-pool info to identify leaks etc through statedumps of the process. Remove can be an option on SPARC to start with if fixing is time consuming. I recommend removing the trailer within a #ifdef codeblock, so it may continue work in places where its already working. -Amar On Tue, Jul 27, 2021 at 7:45 PM Paul Jakma wrote: > Hi, > > The magic trailer added at the end of memory allocations in mem-pool.c > doesn't have its alignment ensured. This can lead to SIGBUS and > abnormal exits on some platforms (e.g., SPARC64). > > I have a patch to round-up the header and allocation size to get the > right alignment for the trailer (I think). > > It does complicate the memory allocation a little further. > > Question is whether it would just be simpler to remove the trailer, and > simplify the code? > > There are a number of external tools that exist to debug memory allocs, > from runtime loadable debug malloc libraries, to compiler features > (ASAN, etc.), to valgrind. > > Glusterfs could just rely on those, and so simplify and (perhaps) > speed-up its own, general-case memory code. > > Remove the trailer? Or fix it? > > regards, > -- > Paul Jakma | p...@jakma.org | @pjakma | Key ID: 0xD86BF79464A2FF6A > Fortune: > Many people are secretly interested in life. > --- > > Community Meeting Calendar: > Schedule - > Every 2nd and 4th Tuesday at 14:30 IST / 09:00 UTC > Bridge: https://meet.google.com/cpu-eiue-hvk > > Gluster-devel mailing list > Gluster-devel@gluster.org > https://lists.gluster.org/mailman/listinfo/gluster-devel > > -- -- https://kadalu.io Container Storage made easy! --- Community Meeting Calendar: Schedule - Every 2nd and 4th Tuesday at 14:30 IST / 09:00 UTC Bridge: https://meet.google.com/cpu-eiue-hvk Gluster-devel mailing list Gluster-devel@gluster.org https://lists.gluster.org/mailman/listinfo/gluster-devel
[Gluster-devel] mem-pool.c magic trailer causes SIGBUS, fix or remove?
Hi, The magic trailer added at the end of memory allocations in mem-pool.c doesn't have its alignment ensured. This can lead to SIGBUS and abnormal exits on some platforms (e.g., SPARC64). I have a patch to round-up the header and allocation size to get the right alignment for the trailer (I think). It does complicate the memory allocation a little further. Question is whether it would just be simpler to remove the trailer, and simplify the code? There are a number of external tools that exist to debug memory allocs, from runtime loadable debug malloc libraries, to compiler features (ASAN, etc.), to valgrind. Glusterfs could just rely on those, and so simplify and (perhaps) speed-up its own, general-case memory code. Remove the trailer? Or fix it? regards, -- Paul Jakma | p...@jakma.org | @pjakma | Key ID: 0xD86BF79464A2FF6A Fortune: Many people are secretly interested in life. --- Community Meeting Calendar: Schedule - Every 2nd and 4th Tuesday at 14:30 IST / 09:00 UTC Bridge: https://meet.google.com/cpu-eiue-hvk Gluster-devel mailing list Gluster-devel@gluster.org https://lists.gluster.org/mailman/listinfo/gluster-devel
