Attention is currently required from: laforge.
fixeria has posted comments on this change. ( https://gerrit.osmocom.org/c/osmo-bts/+/27805 )
Change subject: osmo-bts-trx: fix scheduling of dummy FACCH/H and FACCH/F
......................................................................
Patch Set 1:
(1 comment)
File src/osmo-bts-trx/sched_lchan_tchf.c:
https://gerrit.osmocom.org/c/osmo-bts/+/27805/comment/02cd1fec_3babd0b7
PS1, Line 333: chan_state->dl_facch_bursts = 8;
> you're not setting dl_ongoing_facch here (unlike TCH/H). […]
Yes, this is intentional: dl_ongoing_facch is only used in tx_tchh_fn(), where you need to skip encoding of the buffer while sending the middle two bursts of FACCH/H. Here both speech and FACCH/F have equal interleaving period.
--
To view, visit https://gerrit.osmocom.org/c/osmo-bts/+/27805
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings
Gerrit-Project: osmo-bts
Gerrit-Branch: master
Gerrit-Change-Id: Ief12eb67ad80de3b71f5226858dc2e0c8ae76948
Gerrit-Change-Number: 27805
Gerrit-PatchSet: 1
Gerrit-Owner: fixeria <vyanitskiy(a)sysmocom.de>
Gerrit-Reviewer: Jenkins Builder
Gerrit-CC: laforge <laforge(a)osmocom.org>
Gerrit-Attention: laforge <laforge(a)osmocom.org>
Gerrit-Comment-Date: Sat, 16 Apr 2022 15:52:09 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: No
Comment-In-Reply-To: laforge <laforge(a)osmocom.org>
Gerrit-MessageType: comment
Attention is currently required from: fixeria.
laforge has posted comments on this change. ( https://gerrit.osmocom.org/c/osmo-bts/+/27802 )
Change subject: osmo-bts-trx: move tx_tch_common() into a separate file
......................................................................
Patch Set 1:
(1 comment)
Patchset:
PS1:
do we have actual evidence to that? I'm always skeptical making theoretical assumptions/claims about what the compiler might or might not do.
--
To view, visit https://gerrit.osmocom.org/c/osmo-bts/+/27802
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings
Gerrit-Project: osmo-bts
Gerrit-Branch: master
Gerrit-Change-Id: Id0b9d604e6969a8db73ef451fbcad00f57325fc4
Gerrit-Change-Number: 27802
Gerrit-PatchSet: 1
Gerrit-Owner: fixeria <vyanitskiy(a)sysmocom.de>
Gerrit-Reviewer: Jenkins Builder
Gerrit-CC: laforge <laforge(a)osmocom.org>
Gerrit-Attention: fixeria <vyanitskiy(a)sysmocom.de>
Gerrit-Comment-Date: Sat, 16 Apr 2022 14:24:27 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: No
Gerrit-MessageType: comment
laforge has submitted this change. ( https://gerrit.osmocom.org/c/dahdi-linux/+/27806 )
Change subject: Fix NULL pointer dereference for pseudo channels
......................................................................
Fix NULL pointer dereference for pseudo channels
pseudo channels are characterized by the fact that they have their span
member set to NULL. This is illustrated by the is_pseudo_chan()
function.
However, when using RXMIRROR/TXMIRROR, __putbuf_chunk() is called not
just on the real channel, but also on the mirror (pseudo) channel.
Hence, __putbuf_chunk() and friends must not dereference the ->span
member without first checking that this channel actually does have
a non-NULL span assigned.
I originally thought that those unconditional de-references must have
been introduced after the RXMIRROR/TXMIRROR was merged - but checked the
git history and it seems like the bug has been present ever sicne
this functionality was merged in 2010 in commit
9090c6fcd289b497e00e8e5fb9cc3546e0dfe7d6
Change-Id: I747a696c9a5865c11461b6357a10346a8d0d1621
Closes: OS#5531
---
M drivers/dahdi/dahdi-base.c
1 file changed, 3 insertions(+), 3 deletions(-)
Approvals:
Jenkins Builder: Verified
laforge: Looks good to me, approved
diff --git a/drivers/dahdi/dahdi-base.c b/drivers/dahdi/dahdi-base.c
index 96e4afd..2b6256b 100644
--- a/drivers/dahdi/dahdi-base.c
+++ b/drivers/dahdi/dahdi-base.c
@@ -9203,7 +9203,7 @@
buf[ms->readidx[ms->inreadbuf]++] = rxc;
/* Pay attention to the possibility of an overrun */
if (ms->readidx[ms->inreadbuf] >= ms->blocksize) {
- if (!ss->span->alarms)
+ if (ss->span && !ss->span->alarms)
module_printk(KERN_WARNING, "HDLC Receiver overrun on channel %s (master=%s)\n", ss->name, ss->master->name);
abort=DAHDI_EVENT_OVERRUN;
/* Force the HDLC state back to frame-search mode */
@@ -9375,7 +9375,7 @@
tasklet_schedule(&ms->ppp_calls);
} else
#endif
- if (test_bit(DAHDI_FLAGBIT_OPEN, &ms->flags) && !ss->span->alarms) {
+ if (test_bit(DAHDI_FLAGBIT_OPEN, &ms->flags) && ss->span && !ss->span->alarms) {
/* Notify the receiver... */
__qevent(ss->master, abort);
}
@@ -9443,7 +9443,7 @@
{
if (ss->inreadbuf >= 0)
ss->readidx[ss->inreadbuf] = 0;
- if (test_bit(DAHDI_FLAGBIT_OPEN, &ss->flags) && !ss->span->alarms)
+ if (test_bit(DAHDI_FLAGBIT_OPEN, &ss->flags) && ss->span && !ss->span->alarms)
__qevent(ss->master, event);
}
--
To view, visit https://gerrit.osmocom.org/c/dahdi-linux/+/27806
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings
Gerrit-Project: dahdi-linux
Gerrit-Branch: master
Gerrit-Change-Id: I747a696c9a5865c11461b6357a10346a8d0d1621
Gerrit-Change-Number: 27806
Gerrit-PatchSet: 1
Gerrit-Owner: laforge <laforge(a)osmocom.org>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Reviewer: laforge <laforge(a)osmocom.org>
Gerrit-MessageType: merged
laforge has uploaded this change for review. ( https://gerrit.osmocom.org/c/dahdi-linux/+/27806 )
Change subject: Fix NULL pointer dereference for pseudo channels
......................................................................
Fix NULL pointer dereference for pseudo channels
pseudo channels are characterized by the fact that they have their span
member set to NULL. This is illustrated by the is_pseudo_chan()
function.
However, when using RXMIRROR/TXMIRROR, __putbuf_chunk() is called not
just on the real channel, but also on the mirror (pseudo) channel.
Hence, __putbuf_chunk() and friends must not dereference the ->span
member without first checking that this channel actually does have
a non-NULL span assigned.
I originally thought that those unconditional de-references must have
been introduced after the RXMIRROR/TXMIRROR was merged - but checked the
git history and it seems like the bug has been present ever sicne
this functionality was merged in 2010 in commit
9090c6fcd289b497e00e8e5fb9cc3546e0dfe7d6
Change-Id: I747a696c9a5865c11461b6357a10346a8d0d1621
Closes: OS#5531
---
M drivers/dahdi/dahdi-base.c
1 file changed, 3 insertions(+), 3 deletions(-)
git pull ssh://gerrit.osmocom.org:29418/dahdi-linux refs/changes/06/27806/1
diff --git a/drivers/dahdi/dahdi-base.c b/drivers/dahdi/dahdi-base.c
index 96e4afd..2b6256b 100644
--- a/drivers/dahdi/dahdi-base.c
+++ b/drivers/dahdi/dahdi-base.c
@@ -9203,7 +9203,7 @@
buf[ms->readidx[ms->inreadbuf]++] = rxc;
/* Pay attention to the possibility of an overrun */
if (ms->readidx[ms->inreadbuf] >= ms->blocksize) {
- if (!ss->span->alarms)
+ if (ss->span && !ss->span->alarms)
module_printk(KERN_WARNING, "HDLC Receiver overrun on channel %s (master=%s)\n", ss->name, ss->master->name);
abort=DAHDI_EVENT_OVERRUN;
/* Force the HDLC state back to frame-search mode */
@@ -9375,7 +9375,7 @@
tasklet_schedule(&ms->ppp_calls);
} else
#endif
- if (test_bit(DAHDI_FLAGBIT_OPEN, &ms->flags) && !ss->span->alarms) {
+ if (test_bit(DAHDI_FLAGBIT_OPEN, &ms->flags) && ss->span && !ss->span->alarms) {
/* Notify the receiver... */
__qevent(ss->master, abort);
}
@@ -9443,7 +9443,7 @@
{
if (ss->inreadbuf >= 0)
ss->readidx[ss->inreadbuf] = 0;
- if (test_bit(DAHDI_FLAGBIT_OPEN, &ss->flags) && !ss->span->alarms)
+ if (test_bit(DAHDI_FLAGBIT_OPEN, &ss->flags) && ss->span && !ss->span->alarms)
__qevent(ss->master, event);
}
--
To view, visit https://gerrit.osmocom.org/c/dahdi-linux/+/27806
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings
Gerrit-Project: dahdi-linux
Gerrit-Branch: master
Gerrit-Change-Id: I747a696c9a5865c11461b6357a10346a8d0d1621
Gerrit-Change-Number: 27806
Gerrit-PatchSet: 1
Gerrit-Owner: laforge <laforge(a)osmocom.org>
Gerrit-MessageType: newchange
Attention is currently required from: fixeria, pespin, dexter.
laforge has posted comments on this change. ( https://gerrit.osmocom.org/c/osmo-mgw/+/27608 )
Change subject: mgcp_network: log RTP/RTCP reception failures
......................................................................
Patch Set 3:
(1 comment)
File src/libosmo-mgcp/mgcp_network.c:
https://gerrit.osmocom.org/c/osmo-mgw/+/27608/comment/0c491a23_58717088
PS1, Line 1515: if (rc < 0) {
> Ack
indeed, we need specific information what has failed (in the code where that failure is detected) rather than some generic statement that "something" has failed. Also, keep in mind that RTP packets occur at high rates and we always have to be careful not to overload logs with tons of stuff.
--
To view, visit https://gerrit.osmocom.org/c/osmo-mgw/+/27608
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings
Gerrit-Project: osmo-mgw
Gerrit-Branch: master
Gerrit-Change-Id: Ic0e60fe2fb9d96b8ae18bb862b5715359a10e849
Gerrit-Change-Number: 27608
Gerrit-PatchSet: 3
Gerrit-Owner: dexter <pmaier(a)sysmocom.de>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Reviewer: fixeria <vyanitskiy(a)sysmocom.de>
Gerrit-Reviewer: pespin <pespin(a)sysmocom.de>
Gerrit-CC: laforge <laforge(a)osmocom.org>
Gerrit-Attention: fixeria <vyanitskiy(a)sysmocom.de>
Gerrit-Attention: pespin <pespin(a)sysmocom.de>
Gerrit-Attention: dexter <pmaier(a)sysmocom.de>
Gerrit-Comment-Date: Sat, 16 Apr 2022 08:47:05 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: No
Comment-In-Reply-To: fixeria <vyanitskiy(a)sysmocom.de>
Comment-In-Reply-To: pespin <pespin(a)sysmocom.de>
Gerrit-MessageType: comment