Attention is currently required from: daniel.

pespin has posted comments on this change. ( 
https://gerrit.osmocom.org/c/libosmocore/+/34144 )

Change subject: osmo_io: Avoid potential double free when sending msgb
......................................................................


Patch Set 1:

(3 comments)

Commit Message:

https://gerrit.osmocom.org/c/libosmocore/+/34144/comment/cd32b5e7_41a2bc70
PS1, Line 16: mean time. To avoid that set the parent of any msgb in the tx 
queue to the
time is indeed mean sometimes.


Patchset:

PS1:
All the talloc parent in here looks already quite complex and I have the 
feeling it's becoming even more complex here. I think all this deserves a bit 
more of explanation/documentation since I think I'm not gasping it completely.

IIUC we used to enqueue messages to be written to the socket in an internal 
queue of iofd, but those messages where actually not owned (talloc parent) by 
the iofd, but by some other random context outside of it. This looks wrong to 
me. messages enqueued in an iofd should always be owned by iofd.
I think you are going into this direction (iofd owning it) but the solution 
passing lots of extra ctx doesn't look good to me at first sight. I'd welcome 
further explanation on why all those ctx pointers are needed.


File src/core/osmo_io.c:

https://gerrit.osmocom.org/c/libosmocore/+/34144/comment/197b573b_3b9482a1 
PS1, Line 324:
non-related ws



--
To view, visit https://gerrit.osmocom.org/c/libosmocore/+/34144
To unsubscribe, or for help writing mail filters, visit 
https://gerrit.osmocom.org/settings

Gerrit-Project: libosmocore
Gerrit-Branch: master
Gerrit-Change-Id: I3a279b55a3adff96948120683c844e1508d0ba94
Gerrit-Change-Number: 34144
Gerrit-PatchSet: 1
Gerrit-Owner: daniel <[email protected]>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Reviewer: laforge <[email protected]>
Gerrit-CC: pespin <[email protected]>
Gerrit-Attention: daniel <[email protected]>
Gerrit-Comment-Date: Fri, 11 Aug 2023 16:32:41 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: No
Gerrit-MessageType: comment

Reply via email to