Created attachment 45177 [details]
create real-time thread on the cpu with only one core.

Please provide a testcase to reproduce the issue.  Also note that GCC 6 is no longer supported.  This sounds like an issue in the libsanitizer interceptor
to me, the pthread_create interceptor does

    // Wait until the AsanThread object is initialized and the ThreadRegistry
    // entry is in "started" state. One reason for this is that after this
    // interceptor exits, the child thread's stack may be the only thing holding
    // the |arg| pointer. This may cause LSan to report a leak if leak checking
    // happens at a point when the interceptor has already exited, but the stack
    // range for the child thread is not yet known.
    while (atomic_load(&param.is_registered, memory_order_acquire) == 0)
      internal_sched_yield();

but sched_yield should allow other threads to do progress.  That might not
work if the current thread is realtime of course.  But isn't that a
user error (or a kernel bug when explicitely yield()ing)?

Also this seems like it is an upstream issue too.

(In reply to Andrew Pinski from comment #3)
> Also this seems like it is an upstream issue too.

This is how we handle it.
When the parent's sched_priority isn't sam as the children's
  1 If the parent's sched_priority is greater than the children's, raising the children's sched_priority. After register children, restore the children's sched_priority.
  2 If children's sched_priority is greater than the parent's, raising the parent's sched_priority. After register children, restore the parent's sched_priority.

(In reply to Richard Biener from comment #2)
> Please provide a testcase to reproduce the issue.  Also note that GCC 6 is
> no longer supported.  This sounds like an issue in the libsanitizer
> interceptor
> to me, the pthread_create interceptor does
> 
>     // Wait until the AsanThread object is initialized and the ThreadRegistry
>     // entry is in "started" state. One reason for this is that after this
>     // interceptor exits, the child thread's stack may be the only thing
> holding
>     // the |arg| pointer. This may cause LSan to report a leak if leak
> checking
>     // happens at a point when the interceptor has already exited, but the
> stack
>     // range for the child thread is not yet known.
>     while (atomic_load(&param.is_registered, memory_order_acquire) == 0)
>       internal_sched_yield();
> 
> but sched_yield should allow other threads to do progress.  That might not
> work if the current thread is realtime of course.  But isn't that a
> user error (or a kernel bug when explicitely yield()ing)?

  It isn't user error or a kernel bug. the user's program is normal, and kernel is no bug when explicitely yield()ing. It's address-sanitizer's bug. Adding address-sanitizer, it is deadlock because of  parent and child threads wait of resources from each other.
  We deal with the bug by raising the priority of parent or child threads. Then the pthread_create is ok.