This set of patches is the result of my taking a second look at the sbus code. One of the driving factors was the removal of talloc_reference() given the uncertainty about this API upstream.
During the review I decided to rationalize the use of names, combined server and connection structures so that one single set of watch functions can be used without the need of additional placeholder structures (I've done this in 2 steps with a placeholder structure first).
Finally I found some minor bugs and potential memory leaks I resolved in patches. One notable bug that was hiding in the code is that the responder context was holding only one sbus_connection structure and we were assigning to it both the monitor and the dp connection structures. We don't reference the monitor connection after we instantiate it so if the monitor connection was set up first we wouldn't notice it. With my patches I started seeing that the dp connection was set up first some times and this led to failures as messages intended for the data provider were received by the monitor, and it would reply with a Method Unknown error of course.
Simo.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 08/06/2009 05:47 AM, Simo Sorce wrote:
This set of patches is the result of my taking a second look at the sbus code. One of the driving factors was the removal of talloc_reference() given the uncertainty about this API upstream.
During the review I decided to rationalize the use of names, combined server and connection structures so that one single set of watch functions can be used without the need of additional placeholder structures (I've done this in 2 steps with a placeholder structure first).
Finally I found some minor bugs and potential memory leaks I resolved in patches. One notable bug that was hiding in the code is that the responder context was holding only one sbus_connection structure and we were assigning to it both the monitor and the dp connection structures. We don't reference the monitor connection after we instantiate it so if the monitor connection was set up first we wouldn't notice it. With my patches I started seeing that the dp connection was set up first some times and this led to failures as messages intended for the data provider were received by the monitor, and it would reply with a Method Unknown error of course.
Simo.
sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/sssd-devel
All six patches are acked.
- -- Stephen Gallagher RHCE 804006346421761
Looking to carve out IT costs? www.redhat.com/carveoutcosts/
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 08/10/2009 09:37 AM, Stephen Gallagher wrote:
On 08/06/2009 05:47 AM, Simo Sorce wrote:
This set of patches is the result of my taking a second look at the sbus code. One of the driving factors was the removal of talloc_reference() given the uncertainty about this API upstream.
During the review I decided to rationalize the use of names, combined server and connection structures so that one single set of watch functions can be used without the need of additional placeholder structures (I've done this in 2 steps with a placeholder structure first).
Finally I found some minor bugs and potential memory leaks I resolved in patches. One notable bug that was hiding in the code is that the responder context was holding only one sbus_connection structure and we were assigning to it both the monitor and the dp connection structures. We don't reference the monitor connection after we instantiate it so if the monitor connection was set up first we wouldn't notice it. With my patches I started seeing that the dp connection was set up first some times and this led to failures as messages intended for the data provider were received by the monitor, and it would reply with a Method Unknown error of course.
Simo.
sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/sssd-devel
All six patches are acked.
Pushed to master. _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/sssd-devel
- -- Stephen Gallagher RHCE 804006346421761
Looking to carve out IT costs? www.redhat.com/carveoutcosts/
sssd-devel@lists.fedorahosted.org
-
Simo Sorce -
Stephen Gallagher