[LTP] [RFC PATCH 0/2] Allow to compile on archs without atomic support

[LTP] [RFC PATCH 0/2] Allow to compile on archs without atomic support

[Petr Vorel]

Hi,

I know as this has quite low priority (benefit only people with old
compilers and archs), but why not to give a chance them to have at least
something from LTP?
Quite a lot of tests it's working, affected are only tests using threads
on new API or fuzzy synchronization and counting results for tests using
new api.

Kind regards,
Petr

Petr Vorel (2):
  tst_atomic.h: Allow to compile on archs without atomic support
  lib/tst_test.c: Don't print results on archs without atomic

 include/tst_atomic.h | 31 +++++++++++++++++++++++++++++--
 lib/tst_test.c       |  4 ++++
 2 files changed, 33 insertions(+), 2 deletions(-)

-- 
2.15.1

[LTP] [RFC PATCH 1/2] tst_atomic.h: Allow to compile on archs without atomic support

[Petr Vorel]

Some archs without atomic support in compiler and without our own
implementation can now benefit with at least having tests which don't
need atomic support.

Signed-off-by: Petr Vorel <pvorel@suse.cz>
---
 include/tst_atomic.h | 31 +++++++++++++++++++++++++++++--
 1 file changed, 29 insertions(+), 2 deletions(-)

diff --git a/include/tst_atomic.h b/include/tst_atomic.h
index 5736d28bb..a4ccb8592 100644
--- a/include/tst_atomic.h
+++ b/include/tst_atomic.h
@@ -61,7 +61,11 @@
 #ifndef TST_ATOMIC_H__
 #define TST_ATOMIC_H__
 
+#include <stdlib.h>
+#include <stdio.h>
+
 #include "config.h"
+#include "tst_res_flags.h"
 
 #if HAVE_ATOMIC_MEMORY_MODEL == 1
 static inline int tst_atomic_add_return(int i, int *v)
@@ -309,8 +313,31 @@ static inline int tst_atomic_add_return(int i, int *v)
 }
 
 #else /* HAVE_SYNC_ADD_AND_FETCH == 1 */
-# error Your compiler does not provide __atomic_add_fetch, __sync_add_and_fetch \
-        and an LTP implementation is missing for your architecture.
+# define LTP_NO_ATOMIC "WARNING: Your compiler does not provide __atomic_add_fetch, " \
+	"__sync_add_and_fetch and an LTP implementation is missing for your architecture. " \
+	"Tests using atomic operations (e.g. using threads on new API or fuzzy synchronization) will not work.\n"
+
+# warning Your compiler does not provide __atomic_add_fetch \
+	__sync_add_and_fetch and an LTP implementation is missing for your architecture. \
+	Tests using atomic operations (e.g. using threads on new API or fuzzy synchronization) will not work.
+
+static inline int tst_atomic_add_return(int i LTP_ATTRIBUTE_UNUSED, int *v LTP_ATTRIBUTE_UNUSED)
+{
+	printf(LTP_NO_ATOMIC);
+	exit(TCONF);
+}
+
+static inline int tst_atomic_load(int *v LTP_ATTRIBUTE_UNUSED)
+{
+	printf(LTP_NO_ATOMIC);
+	exit(TCONF);
+}
+
+static inline void tst_atomic_store(int i LTP_ATTRIBUTE_UNUSED, int *v LTP_ATTRIBUTE_UNUSED)
+{
+	printf(LTP_NO_ATOMIC);
+	exit(TCONF);
+}
 #endif
 
 #ifdef LTP_USE_GENERIC_LOAD_STORE_ASM
-- 
2.15.1

[LTP] [RFC PATCH 2/2] lib/tst_test.c: Don't print results on archs without atomic

[Petr Vorel]

Signed-off-by: Petr Vorel <pvorel@suse.cz>
---
 lib/tst_test.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/lib/tst_test.c b/lib/tst_test.c
index e7b9cddf1..d5d0d60b9 100644
--- a/lib/tst_test.c
+++ b/lib/tst_test.c
@@ -574,6 +574,7 @@ int tst_parse_float(const char *str, float *val, float min, float max)
 static void do_exit(int ret)
 {
 	if (results) {
+#ifndef LTP_NO_ATOMIC
 		printf("\nSummary:\n");
 		printf("passed   %d\n", results->passed);
 		printf("failed   %d\n", results->failed);
@@ -588,6 +589,9 @@ static void do_exit(int ret)
 
 		if (results->warnings)
 			ret |= TWARN;
+#else
+	printf("WARNING: Results not counted due missing atomic support.\n");
+#endif
 	}
 
 	do_cleanup();
-- 
2.15.1

[LTP] [RFC PATCH 0/2] Allow to compile on archs without atomic support

[Jan Stancek]

----- Original Message -----
> Hi,

Hi,

> 
> I know as this has quite low priority (benefit only people with old
> compilers and archs), but why not to give a chance them to have at least
> something from LTP?

Compiler shouldn't matter, we have fallbacks.
So I assume this concerns only some architectures we currently don't support.

> Quite a lot of tests it's working, affected are only tests using threads
> on new API or fuzzy synchronization and counting results for tests using
> new api.

What if we made general implementation with some locking? It would be
slower, but I think we don't use atomics that much for it to matter.

Regards,
Jan

[LTP] [RFC PATCH 0/2] Allow to compile on archs without atomic support

[Petr Vorel]

Hi Jan,

thanks for your comments.

> > I know as this has quite low priority (benefit only people with old
> > compilers and archs), but why not to give a chance them to have at least
> > something from LTP?

> Compiler shouldn't matter, we have fallbacks.
> So I assume this concerns only some architectures we currently don't support.
Yes.

> > Quite a lot of tests it's working, affected are only tests using threads
> > on new API or fuzzy synchronization and counting results for tests using
> > new api.

> What if we made general implementation with some locking? It would be
> slower, but I think we don't use atomics that much for it to matter.
Makes sense. I'll implement it.


> Regards,
> Jan


Kind regards,
Petr

[LTP] [RFC PATCH 0/2] Allow to compile on archs without atomic support

[Cyril Hrubis]

Hi!
> What if we made general implementation with some locking? It would be
> slower, but I think we don't use atomics that much for it to matter.

Atomic increment was easiest way how to make the test library thread
safe I wasn't concerned with speed at all. But that is not true for the
CVE tests which use atomic operation to synchronize threads to trigger
races.

-- 
Cyril Hrubis
chrubis@suse.cz

[LTP] [RFC PATCH 0/2] Allow to compile on archs without atomic support

[Petr Vorel]

Hi,

> > What if we made general implementation with some locking? It would be
> > slower, but I think we don't use atomics that much for it to matter.

> Atomic increment was easiest way how to make the test library thread
> safe I wasn't concerned with speed at all. But that is not true for the
> CVE tests which use atomic operation to synchronize threads to trigger
> races.
That's why I implemented it in v1 as simple exit(). So are we ok that CVE tests will
probably be failing / taking so long?

Thank you both, for considering it, as I know it's only corner case.


Kind regards,
Petr