Jon Paul Maloy <[EMAIL PROTECTED]> wrote:
> tipc_createport()->create_reference() returns i, to be
> used as a reference for the port instance.
> tipc_deleteport() uses that reference as argument when the
> port should be deleted.
> Hence, it is logically impossible that tipc_deleteport() can be called
> _for a port_ until tipc_create_port() has returned the reference to that
> port.
Ah, right.
> Jarek had a suggestion for a rather ugly fix which I did not quite
> understand, so I have been dragging my feet on this until I come
> up with something better. I will try to look into this again.
That would be good.
There is another warning in accept:
netsend/1450 is trying to acquire lock:
(sk_lock-AF_TIPC){--..}, at: [<c029e483>] accept+0x183/0x2e0
but task is already holding lock:
(sk_lock-AF_TIPC){--..}, at: [<c029e402>] accept+0x102/0x2e0
other info that might help us debug this:
1 lock held by netsend/1450:
#0: (sk_lock-AF_TIPC){--..}, at: [<c029e402>] accept+0x102/0x2e0
stack backtrace:
[<c010402a>] show_trace_log_lvl+0x1a/0x30
[<c0104712>] show_trace+0x12/0x20
[<c01047c6>] dump_stack+0x16/0x20
[<c0136d90>] __lock_acquire+0xad0/0xdc0
[<c01370d7>] lock_acquire+0x57/0x70
[<c023c0c5>] lock_sock_nested+0xe5/0x100
[<c029e483>] accept+0x183/0x2e0
[<c023b059>] sys_accept+0x89/0x150
[<c023b1e1>] sys_socketcall+0xc1/0x260
[<c0103018>] syscall_call+0x7/0xb
=======================
Which does not seem to be a bug either. (newsk can only ever
be locked after sk). Perhaps
lock_sock(new_sock)
should be changed to
lock_sock_nested(new_sk, SINGLE_DEPTH_NESTING); ?
Thanks,
Florian
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
tipc-discussion mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/tipc-discussion
