On 14 Jan 2003, [EMAIL PROTECTED] wrote:
get_mutex:
ServerReqChallenge
ServerAuthenticate2
release_mutex:
Yes, that's what we meant.
I hypothesized to ab that in NT there is some kind of table
indexed by IP (or client name?) holding the challenges. I wonder why?
speculation
Martin Pool [mailto:[EMAIL PROTECTED]]
I hypothesized to ab that in NT there is some kind of table
indexed by IP (or client name?) holding the challenges. I wonder why?
I found a similar limitation in a commercial RADIUS server I was testing
against. Any given person could have only one
On Tue, Jan 14, 2003 at 05:25:20PM +1100, Tim Potter wrote:
On Sat, Jan 11, 2003 at 01:11:14AM +, [EMAIL PROTECTED] wrote:
On Fri, Jan 10, 2003 at 05:31:48PM +1100, Martin Pool wrote:
Here's my idea for fixing this in appliance-head, without reworking
the mutex reference count.
On Sat, Jan 11, 2003 at 01:11:14AM +, [EMAIL PROTECTED] wrote:
On Fri, Jan 10, 2003 at 05:31:48PM +1100, Martin Pool wrote:
Here's my idea for fixing this in appliance-head, without reworking
the mutex reference count.
Thanks for that - I've just checked in something close to this.
On Fri, Jan 10, 2003 at 05:31:48PM +1100, Martin Pool wrote:
Here's my idea for fixing this in appliance-head, without reworking
the mutex reference count.
Thanks for that - I've just checked in something close to this. Take
a look and let me know...
Thanks,
Jeremy.
I'm looking at jra's 1.33.2.16 change to winbindd_cmd.c in relation to
hp CR1501.
I think there are some problems with the way the mutex reference count
is handled. I'm not sure what is the cleanest way to fix it.
The mutexes are implemented on top of fcntl locks, which cannot be
nested.
Here's my idea for fixing this in appliance-head, without reworking
the mutex reference count.
Basically it tries to
- avoid undefined behaviour in the case where we fail to acquire the
mutex
- avoid leaking locks in the case where we fail to connect to the
server
- avoid releasing
