Attention is currently required from: neels, fixeria, pespin, lynxis lazus. laforge has posted comments on this change. ( https://gerrit.osmocom.org/c/osmo-bsc/+/29788 )
Change subject: Add BTS setup ramping to prevent BSC overloading ......................................................................
Patch Set 15:
(4 comments)
File src/osmo-bsc/bts_setup_ramp.c:
https://gerrit.osmocom.org/c/osmo-bsc/+/29788/comment/e7235419_98adc791 PS4, Line 98: && net->bts_setup_ramp.step_size > 0
Not addressed.
Ack
https://gerrit.osmocom.org/c/osmo-bsc/+/29788/comment/1b8ffa98_c313ee44 PS4, Line 101: net->bts_setup_ramp.active
The point is to use the API here so that if you/anyone changes the API implementtion you don't need […]
Ack
https://gerrit.osmocom.org/c/osmo-bsc/+/29788/comment/0c6aa072_4c9dd25d PS4, Line 201: INIT_LLIST_HEAD(&bts->bts_setup_ramp.list);
Comment was not added.
The Linux kernel llist API has always worked in the way that you cannot llist_del() a llist_entry that was never added to a list via llist_add(). I don't really see why this is suddently becoming a problem. It's simply not safe. Just like you cannot unlock a pthread mutex that was never initialized, or whatever other API or interface you can come up with where you cannot undo something you never did in the first place.
File src/osmo-bsc/bts_setup_ramp.c:
https://gerrit.osmocom.org/c/osmo-bsc/+/29788/comment/2b5d26c5_77307955 PS15, Line 74: net->bts_setup_ramp.count >= net->bts_setup_ramp.step_size)
This line needs to be aligned to the opening brace, otherwise it looks like the block's body.
Ack