Re: [PATCH] elf: Fix fences in _dl_find_object_update (bug 28745)

[Tulio Magno Quites Machado Filho <tuliom@linux.ibm.com>]

I haven't been able to reproduce the issue after applying this patch.
I've found a coding style issue:

Florian Weimer via Libc-alpha <libc-alpha@sourceware.org> writes:

> diff --git a/elf/dl-find_object.c b/elf/dl-find_object.c
> index 721fed50d6..a2f7144a34 100644
> --- a/elf/dl-find_object.c
> +++ b/elf/dl-find_object.c
> @@ -293,8 +297,20 @@ _dlfo_mappings_end_update_no_switch (void)
>  static inline bool
>  _dlfo_read_success (uint64_t start_version)
>  {
> -  return _dlfo_read_start_version () == start_version;
> -}
> +  /* See Hans Boehm, Can Seqlocks Get Along with Programming Language
> +     Memory Models?, Section 4.  This is necessary so that loads in
> +     the TM region are not ordered passed the version check below.  */
> +  atomic_thread_fence_acquire ();
> +
> +  /* Synchronizes with stores in _dlfo_mappings_begin_update,
> +     _dlfo_mappings_end_update, _dlfo_mappings_end_update_no_switch.
> +     It is important that all stores from the last update have been
> +     visible, and stores from the next updates are not.
> +
> +     Unlike with seqlocks, there is no check for odd versions here
> +     because we have read the unmodified copy (confirmed to be
> +     unmodified by the unchanged version).  */
> + return _dlfo_read_start_version () == start_version; }

   ^ Wrong indentation here                              ^ Closing brackets here

Thanks!

-- 
Tulio Magno