All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
To: linux-kernel@vger.kernel.org, lttng-dev@lists.lttng.org,
	rp@svcs.cs.pdx.edu
Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
	Stephen Hemminger <stephen@networkplumber.org>,
	Alan Stern <stern@rowland.harvard.edu>,
	Lai Jiangshan <jiangshanlai@gmail.com>
Subject: [RELEASE] Userspace RCU 0.13.0
Date: Thu, 3 Jun 2021 16:57:53 -0400 (EDT)	[thread overview]
Message-ID: <293749719.7760.1622753873071.JavaMail.zimbra@efficios.com> (raw)

Hi,

The Userspace RCU 0.13 release is mostly a library soname version bump
to address an ABI incompatibility between the 0.10 and { 0.11, 0.12 }
releases.

The observed application vs library compatibility problem occurs as follows:

- An application executable is built with _LGPL_SOURCE defined, includes
  any of the Userspace RCU 0.10 urcu flavor headers, and is built
  without the -fpic compiler option.

- The Userspace RCU 0.10 library shared objects are updated to 0.11
  or 0.12 without rebuilding the application.

- The application will hang, typically when RCU grace period
  (synchronize_rcu) is invoked.

Some possible work-arounds for this are:

- Rebuild the application against Userspace RCU 0.11+,
- Rebuild the application with -fpic.
- Upgrade Userspace RCU to 0.13+ without installing 0.11 nor 0.12.


* Explanation of the issue

In URCU 0.11, we introduced new symbols to clean up the library symbol
namespacing, using the "alias" attribute to keep emitting the old
symbols, expecting to preserve ABI backward compatibility.
Unfortunately, it turns out that even though it works well for function
symbols, it is broken for public global variables due to the way ELF
copy relocation works.

When building a non-PIC executable that uses an extern variable, a .bss
symbol is emitted in the executable. This will take precedence over the
symbol implemented within the library in the Global Symbol Table.
Unfortunately, the alias within the library will not be aware that the
actual GST symbol differs from its alias within the library, and the
addresses for the symbol and its alias will differ at runtime.

Considering that this compatibility issue affects official library
releases, there is little we can do beyond documenting this issue, and
bumping the Userspace RCU major soname for the next (0.13) release.

In summary, do not upgrade from Userspace RCU 0.10 to 0.11 or 0.12 if 
you have applications which:

- define _LGPL_SOURCE
- use Userspace RCU 0.10 headers
- are not compiled with -fpic

We recommend instead to upgrade to Userspace RCU 0.13, which bumps the
library soname major number.

Thanks,

Mathieu

Project website: http://liburcu.org
Git repository: git://git.liburcu.org/urcu.git

-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com

WARNING: multiple messages have this Message-ID (diff)
From: Mathieu Desnoyers via lttng-dev <lttng-dev@lists.lttng.org>
To: linux-kernel@vger.kernel.org, lttng-dev@lists.lttng.org,
	rp@svcs.cs.pdx.edu
Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
	 Stephen Hemminger <stephen@networkplumber.org>,
	 Alan Stern <stern@rowland.harvard.edu>,
	 Lai Jiangshan <jiangshanlai@gmail.com>
Subject: [lttng-dev] [RELEASE] Userspace RCU 0.13.0
Date: Thu, 3 Jun 2021 16:57:53 -0400 (EDT)	[thread overview]
Message-ID: <293749719.7760.1622753873071.JavaMail.zimbra@efficios.com> (raw)

Hi,

The Userspace RCU 0.13 release is mostly a library soname version bump
to address an ABI incompatibility between the 0.10 and { 0.11, 0.12 }
releases.

The observed application vs library compatibility problem occurs as follows:

- An application executable is built with _LGPL_SOURCE defined, includes
  any of the Userspace RCU 0.10 urcu flavor headers, and is built
  without the -fpic compiler option.

- The Userspace RCU 0.10 library shared objects are updated to 0.11
  or 0.12 without rebuilding the application.

- The application will hang, typically when RCU grace period
  (synchronize_rcu) is invoked.

Some possible work-arounds for this are:

- Rebuild the application against Userspace RCU 0.11+,
- Rebuild the application with -fpic.
- Upgrade Userspace RCU to 0.13+ without installing 0.11 nor 0.12.


* Explanation of the issue

In URCU 0.11, we introduced new symbols to clean up the library symbol
namespacing, using the "alias" attribute to keep emitting the old
symbols, expecting to preserve ABI backward compatibility.
Unfortunately, it turns out that even though it works well for function
symbols, it is broken for public global variables due to the way ELF
copy relocation works.

When building a non-PIC executable that uses an extern variable, a .bss
symbol is emitted in the executable. This will take precedence over the
symbol implemented within the library in the Global Symbol Table.
Unfortunately, the alias within the library will not be aware that the
actual GST symbol differs from its alias within the library, and the
addresses for the symbol and its alias will differ at runtime.

Considering that this compatibility issue affects official library
releases, there is little we can do beyond documenting this issue, and
bumping the Userspace RCU major soname for the next (0.13) release.

In summary, do not upgrade from Userspace RCU 0.10 to 0.11 or 0.12 if 
you have applications which:

- define _LGPL_SOURCE
- use Userspace RCU 0.10 headers
- are not compiled with -fpic

We recommend instead to upgrade to Userspace RCU 0.13, which bumps the
library soname major number.

Thanks,

Mathieu

Project website: http://liburcu.org
Git repository: git://git.liburcu.org/urcu.git

-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
_______________________________________________
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev

             reply	other threads:[~2021-06-03 20:57 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-03 20:57 Mathieu Desnoyers [this message]
2021-06-03 20:57 ` [lttng-dev] [RELEASE] Userspace RCU 0.13.0 Mathieu Desnoyers via lttng-dev

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=293749719.7760.1622753873071.JavaMail.zimbra@efficios.com \
    --to=mathieu.desnoyers@efficios.com \
    --cc=jiangshanlai@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lttng-dev@lists.lttng.org \
    --cc=paulmck@linux.vnet.ibm.com \
    --cc=rp@svcs.cs.pdx.edu \
    --cc=stephen@networkplumber.org \
    --cc=stern@rowland.harvard.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.