diff --git a/.version b/.version index 0544f90761..9187872374 100644 --- a/.version +++ b/.version @@ -1 +1 @@ -20.17.0-rc1 +20.17.0-rc2 diff --git a/CHANGES.html b/CHANGES.html index 9ea54671bd..6ede5e9739 120000 --- a/CHANGES.html +++ b/CHANGES.html @@ -1 +1 @@ -ChangeLogs/ChangeLog-20.17.0-rc1.html \ No newline at end of file +ChangeLogs/ChangeLog-20.17.0-rc2.html \ No newline at end of file diff --git a/CHANGES.md b/CHANGES.md index 0c30ae4636..04004df028 120000 --- a/CHANGES.md +++ b/CHANGES.md @@ -1 +1 @@ -ChangeLogs/ChangeLog-20.17.0-rc1.md \ No newline at end of file +ChangeLogs/ChangeLog-20.17.0-rc2.md \ No newline at end of file diff --git a/ChangeLogs/ChangeLog-20.17.0-rc2.html b/ChangeLogs/ChangeLog-20.17.0-rc2.html new file mode 100644 index 0000000000..d78fcb2764 --- /dev/null +++ b/ChangeLogs/ChangeLog-20.17.0-rc2.html @@ -0,0 +1,61 @@ +
Author: George Joseph + Date: 2025-11-06
+After PR #1498 added read locking to channelstorage_cpp_map_name_id, if ARI + channels/externalMedia was called with a custom channel id AND the + cpp_map_name_id channel storage backend is in use, a deadlock can occur when + hanging up the channel. It's actually triggered in + channel.c:__ast_channel_alloc_ap() when it gets a write lock on the + channelstorage driver then subsequently does a lookup for channel uniqueid + which now does a read lock. This is an invalid operation and causes the lock + state to get "bad". When the channels try to hang up, a write lock is + attempted again which hangs and causes the deadlock.
+Now instead of the cpp_map_name_id channelstorage driver "get" APIs + automatically performing a read lock, they take a "lock" parameter which + allows a caller who already has a write lock to indicate that the "get" API + must not attempt its own lock. This prevents the state from getting mesed up.
+The ao2_legacy driver uses the ao2 container's recursive mutex so doesn't + have this issue but since it also implements the common channelstorage API, + it needed its "get" implementations updated to take the lock parameter. They + just don't use it.
+Resolves: #1578
+ diff --git a/ChangeLogs/ChangeLog-20.17.0-rc2.md b/ChangeLogs/ChangeLog-20.17.0-rc2.md new file mode 100644 index 0000000000..b244918d53 --- /dev/null +++ b/ChangeLogs/ChangeLog-20.17.0-rc2.md @@ -0,0 +1,72 @@ + +## Change Log for Release asterisk-20.17.0-rc2 + +### Links: + + - [Full ChangeLog](https://downloads.asterisk.org/pub/telephony/asterisk/releases/ChangeLog-20.17.0-rc2.html) + - [GitHub Diff](https://github.com/asterisk/asterisk/compare/20.17.0-rc1...20.17.0-rc2) + - [Tarball](https://downloads.asterisk.org/pub/telephony/asterisk/asterisk-20.17.0-rc2.tar.gz) + - [Downloads](https://downloads.asterisk.org/pub/telephony/asterisk) + +### Summary: + +- Commits: 1 +- Commit Authors: 1 +- Issues Resolved: 1 +- Security Advisories Resolved: 0 + +### User Notes: + + +### Upgrade Notes: + + +### Developer Notes: + + +### Commit Authors: + +- George Joseph: (1) + +## Issue and Commit Detail: + +### Closed Issues: + + - 1578: [bug]: Deadlock with externalMedia custom channel id and cpp map channel backend + +### Commits By Author: + +- #### George Joseph (1): + +### Commit List: + +- channelstorage: Allow storage driver read locking to be skipped. + +### Commit Details: + +#### channelstorage: Allow storage driver read locking to be skipped. + Author: George Joseph + Date: 2025-11-06 + + After PR #1498 added read locking to channelstorage_cpp_map_name_id, if ARI + channels/externalMedia was called with a custom channel id AND the + cpp_map_name_id channel storage backend is in use, a deadlock can occur when + hanging up the channel. It's actually triggered in + channel.c:__ast_channel_alloc_ap() when it gets a write lock on the + channelstorage driver then subsequently does a lookup for channel uniqueid + which now does a read lock. This is an invalid operation and causes the lock + state to get "bad". When the channels try to hang up, a write lock is + attempted again which hangs and causes the deadlock. + + Now instead of the cpp_map_name_id channelstorage driver "get" APIs + automatically performing a read lock, they take a "lock" parameter which + allows a caller who already has a write lock to indicate that the "get" API + must not attempt its own lock. This prevents the state from getting mesed up. + + The ao2_legacy driver uses the ao2 container's recursive mutex so doesn't + have this issue but since it also implements the common channelstorage API, + it needed its "get" implementations updated to take the lock parameter. They + just don't use it. + + Resolves: #1578 + diff --git a/README.html b/README.html index f6eeef21e1..1f5d22841c 100644 --- a/README.html +++ b/README.html @@ -1,4 +1,4 @@ -By Mark Spencer <markster@digium.com> and the Asterisk.org developer community.
Copyright (C) 2001-2025 Sangoma Technologies Corporation and other copyright holders.
@@ -37,7 +37,7 @@ hardware.
If you are updating from a previous version of Asterisk, make sure you
read the Change Logs.
-
+
NEW INSTALLATIONS
diff --git a/README.md b/README.md
index aa4dbc2a64..d200a69896 100644
--- a/README.md
+++ b/README.md
@@ -55,7 +55,7 @@ If you are updating from a previous version of Asterisk, make sure you
read the Change Logs.
-[Change Logs](ChangeLogs/ChangeLog-20.17.0-rc1.html)
+[Change Logs](ChangeLogs/ChangeLog-20.17.0-rc2.html)
### NEW INSTALLATIONS