* [PATCH net-2.6] ax25: netrom: rose: Fix timer oopses
[not found] ` <4B507FAA.8010007@free.fr>
@ 2010-01-15 20:36 ` Jarek Poplawski
2010-01-16 9:04 ` David Miller
` (3 more replies)
0 siblings, 4 replies; 24+ messages in thread
From: Jarek Poplawski @ 2010-01-15 20:36 UTC (permalink / raw)
To: David S. Miller
Cc: Bernard Pidoux, Bernard Pidoux, linux-kernel, Linux Netdev List,
Ralf Baechle, linux-hams, Rafael J. Wysocki
On Fri, Jan 15, 2010 at 03:46:02PM +0100, Bernard Pidoux wrote:
> Hi Jarek,
Hi Bernard,
>
> Congratulation. With your patch I did not see any more kernel panics
> since my last post.
> I think it should be commited.
> Many thanks.
>
> Wishing you a happy new year 2010.
>
Happy new year to you as well.
Thanks,
Jarek P.
-------------------->
Wrong ax25_cb refcounting in ax25_send_frame() and by its callers can
cause timer oopses (first reported with 2.6.29.6 kernel).
Fixes: http://bugzilla.kernel.org/show_bug.cgi?id=14905
Reported-by: Bernard Pidoux <bpidoux@free.fr>
Tested-by: Bernard Pidoux <bpidoux@free.fr>
Signed-off-by: Jarek Poplawski <jarkao2@gmail.com>
---
include/net/netrom.h | 2 ++
net/ax25/ax25_out.c | 6 ++++++
net/netrom/nr_route.c | 11 ++++++-----
net/rose/rose_link.c | 8 ++++++++
net/rose/rose_route.c | 5 +++++
5 files changed, 27 insertions(+), 5 deletions(-)
diff --git a/include/net/netrom.h b/include/net/netrom.h
index 15696b1..ab170a6 100644
--- a/include/net/netrom.h
+++ b/include/net/netrom.h
@@ -132,6 +132,8 @@ static __inline__ void nr_node_put(struct nr_node *nr_node)
static __inline__ void nr_neigh_put(struct nr_neigh *nr_neigh)
{
if (atomic_dec_and_test(&nr_neigh->refcount)) {
+ if (nr_neigh->ax25)
+ ax25_cb_put(nr_neigh->ax25);
kfree(nr_neigh->digipeat);
kfree(nr_neigh);
}
diff --git a/net/ax25/ax25_out.c b/net/ax25/ax25_out.c
index bf706f8..1491260 100644
--- a/net/ax25/ax25_out.c
+++ b/net/ax25/ax25_out.c
@@ -92,6 +92,12 @@ ax25_cb *ax25_send_frame(struct sk_buff *skb, int paclen, ax25_address *src, ax2
#endif
}
+ /*
+ * There is one ref for the state machine; a caller needs
+ * one more to put it back, just like with the existing one.
+ */
+ ax25_cb_hold(ax25);
+
ax25_cb_add(ax25);
ax25->state = AX25_STATE_1;
diff --git a/net/netrom/nr_route.c b/net/netrom/nr_route.c
index aacba76..e2e2d33 100644
--- a/net/netrom/nr_route.c
+++ b/net/netrom/nr_route.c
@@ -843,12 +843,13 @@ int nr_route_frame(struct sk_buff *skb, ax25_cb *ax25)
dptr = skb_push(skb, 1);
*dptr = AX25_P_NETROM;
- ax25s = ax25_send_frame(skb, 256, (ax25_address *)dev->dev_addr, &nr_neigh->callsign, nr_neigh->digipeat, nr_neigh->dev);
- if (nr_neigh->ax25 && ax25s) {
- /* We were already holding this ax25_cb */
+ ax25s = nr_neigh->ax25;
+ nr_neigh->ax25 = ax25_send_frame(skb, 256,
+ (ax25_address *)dev->dev_addr,
+ &nr_neigh->callsign,
+ nr_neigh->digipeat, nr_neigh->dev);
+ if (ax25s)
ax25_cb_put(ax25s);
- }
- nr_neigh->ax25 = ax25s;
dev_put(dev);
ret = (nr_neigh->ax25 != NULL);
diff --git a/net/rose/rose_link.c b/net/rose/rose_link.c
index bd86a63..5ef5f69 100644
--- a/net/rose/rose_link.c
+++ b/net/rose/rose_link.c
@@ -101,13 +101,17 @@ static void rose_t0timer_expiry(unsigned long param)
static int rose_send_frame(struct sk_buff *skb, struct rose_neigh *neigh)
{
ax25_address *rose_call;
+ ax25_cb *ax25s;
if (ax25cmp(&rose_callsign, &null_ax25_address) == 0)
rose_call = (ax25_address *)neigh->dev->dev_addr;
else
rose_call = &rose_callsign;
+ ax25s = neigh->ax25;
neigh->ax25 = ax25_send_frame(skb, 260, rose_call, &neigh->callsign, neigh->digipeat, neigh->dev);
+ if (ax25s)
+ ax25_cb_put(ax25s);
return (neigh->ax25 != NULL);
}
@@ -120,13 +124,17 @@ static int rose_send_frame(struct sk_buff *skb, struct rose_neigh *neigh)
static int rose_link_up(struct rose_neigh *neigh)
{
ax25_address *rose_call;
+ ax25_cb *ax25s;
if (ax25cmp(&rose_callsign, &null_ax25_address) == 0)
rose_call = (ax25_address *)neigh->dev->dev_addr;
else
rose_call = &rose_callsign;
+ ax25s = neigh->ax25;
neigh->ax25 = ax25_find_cb(rose_call, &neigh->callsign, neigh->digipeat, neigh->dev);
+ if (ax25s)
+ ax25_cb_put(ax25s);
return (neigh->ax25 != NULL);
}
diff --git a/net/rose/rose_route.c b/net/rose/rose_route.c
index 795c4b0..70a0b3b 100644
--- a/net/rose/rose_route.c
+++ b/net/rose/rose_route.c
@@ -235,6 +235,8 @@ static void rose_remove_neigh(struct rose_neigh *rose_neigh)
if ((s = rose_neigh_list) == rose_neigh) {
rose_neigh_list = rose_neigh->next;
+ if (rose_neigh->ax25)
+ ax25_cb_put(rose_neigh->ax25);
kfree(rose_neigh->digipeat);
kfree(rose_neigh);
return;
@@ -243,6 +245,8 @@ static void rose_remove_neigh(struct rose_neigh *rose_neigh)
while (s != NULL && s->next != NULL) {
if (s->next == rose_neigh) {
s->next = rose_neigh->next;
+ if (rose_neigh->ax25)
+ ax25_cb_put(rose_neigh->ax25);
kfree(rose_neigh->digipeat);
kfree(rose_neigh);
return;
@@ -812,6 +816,7 @@ void rose_link_failed(ax25_cb *ax25, int reason)
if (rose_neigh != NULL) {
rose_neigh->ax25 = NULL;
+ ax25_cb_put(ax25);
rose_del_route_by_neigh(rose_neigh);
rose_kill_by_neigh(rose_neigh);
^ permalink raw reply related [flat|nested] 24+ messages in thread
* Re: [PATCH net-2.6] ax25: netrom: rose: Fix timer oopses
2010-01-15 20:36 ` [PATCH net-2.6] ax25: netrom: rose: Fix timer oopses Jarek Poplawski
@ 2010-01-16 9:04 ` David Miller
2011-06-16 20:23 ` [AX25] inconsistent lock state f6bvp
` (2 subsequent siblings)
3 siblings, 0 replies; 24+ messages in thread
From: David Miller @ 2010-01-16 9:04 UTC (permalink / raw)
To: jarkao2
Cc: bpidoux, bernard.pidoux, linux-kernel, netdev, ralf, linux-hams,
rjw
From: Jarek Poplawski <jarkao2@gmail.com>
Date: Fri, 15 Jan 2010 21:36:54 +0100
> Wrong ax25_cb refcounting in ax25_send_frame() and by its callers can
> cause timer oopses (first reported with 2.6.29.6 kernel).
>
> Fixes: http://bugzilla.kernel.org/show_bug.cgi?id=14905
>
> Reported-by: Bernard Pidoux <bpidoux@free.fr>
> Tested-by: Bernard Pidoux <bpidoux@free.fr>
> Signed-off-by: Jarek Poplawski <jarkao2@gmail.com>
Applied, thanks everyone.
^ permalink raw reply [flat|nested] 24+ messages in thread
* [AX25] inconsistent lock state
2010-01-15 20:36 ` [PATCH net-2.6] ax25: netrom: rose: Fix timer oopses Jarek Poplawski
2010-01-16 9:04 ` David Miller
@ 2011-06-16 20:23 ` f6bvp
2011-06-17 13:28 ` Ralf Baechle
2011-06-17 13:36 ` Arnd Bergmann
2011-06-16 20:40 ` f6bvp
2011-07-07 13:31 ` Question with axudp Bernard, f6bvp
3 siblings, 2 replies; 24+ messages in thread
From: f6bvp @ 2011-06-16 20:23 UTC (permalink / raw)
To: linux-kernel; +Cc: Jarek Poplawski, Linux Netdev List, Ralf Baechle, linux-hams
Hi,
When unpluging ethernet connector a few seconds I observed the following
kernel message :
Jun 16 12:03:25 f6bvp-9 kernel: e1000e: eth1 NIC Link is Down
Jun 16 12:03:25 f6bvp-9 ifplugd(eth1)[1541]: Link beat lost.
Jun 16 12:03:31 f6bvp-9 ifplugd(eth1)[1541]: Executing
'/etc/ifplugd/ifplugd.action eth1 down'.
Jun 16 12:03:31 f6bvp-9 avahi-daemon[2197]: Withdrawing address record
for 192.168.0.66 on eth1.
Jun 16 12:03:31 f6bvp-9 avahi-daemon[2197]: Leaving mDNS multicast group
on interface eth1.IPv4 with address 192.168.0.66.
Jun 16 12:03:31 f6bvp-9 avahi-daemon[2197]: Interface eth1.IPv4 no
longer relevant for mDNS.
Jun 16 12:03:31 f6bvp-9 avahi-daemon[2197]: Withdrawing address record
for fe80::21c:c0ff:fe36:723e on eth1.
Jun 16 12:03:31 f6bvp-9 vnstatd[2022]: SIGHUP received, flushing data to
disk and reloading config.
Jun 16 12:03:31 f6bvp-9 ifplugd(eth1)[1541]: client: Rechargement de la
configuration de vnstatd : #033[65G[#033[1;32m OK #033[0;39m]#015
Jun 16 12:03:31 f6bvp-9 ifplugd(eth1)[1541]: Program executed successfully.
Jun 16 12:03:31 f6bvp-9 kernel: ADDRCONF(NETDEV_UP): eth1: link is not ready
Jun 16 12:03:34 f6bvp-9 kernel:
Jun 16 12:03:34 f6bvp-9 kernel: =================================
Jun 16 12:03:34 f6bvp-9 kernel: [ INFO: inconsistent lock state ]
Jun 16 12:03:34 f6bvp-9 kernel: 2.6.39.1 #3
Jun 16 12:03:34 f6bvp-9 kernel: ---------------------------------
Jun 16 12:03:34 f6bvp-9 kernel: inconsistent {IN-SOFTIRQ-R} ->
{SOFTIRQ-ON-W} usage.
Jun 16 12:03:34 f6bvp-9 kernel: ax25ipd/2813 [HC0[0]:SC0[0]:HE1:SE1] takes:
Jun 16 12:03:34 f6bvp-9 kernel: (disc_data_lock){+++?.-}, at:
[<ffffffffa018552b>] mkiss_close+0x1b/0x90 [mkiss]
Jun 16 12:03:34 f6bvp-9 kernel: {IN-SOFTIRQ-R} state was registered at:
Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff8109484e>]
__lock_acquire+0x57e/0x14c0
Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff81095836>]
lock_acquire+0xa6/0x160
Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff813f64f4>]
_raw_read_lock+0x34/0x50
Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffffa01850ed>]
mkiss_get+0x1d/0x50 [mkiss]
Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffffa018517e>]
mkiss_write_wakeup+0x1e/0xb0 [mkiss]
Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff8129457e>] tty_wakeup+0x6e/0x80
Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff8129f243>] pty_write+0x73/0x80
Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffffa0185d2e>]
ax_xmit+0x27e/0x5e0 [mkiss]
Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff81339dac>]
dev_hard_start_xmit+0x34c/0x6f0
Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff81358b4d>]
sch_direct_xmit+0xdd/0x260
Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff8133cc8f>]
dev_queue_xmit+0x1af/0x8a0
Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffffa0325072>]
ax25_queue_xmit+0x52/0x60 [ax25]
Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffffa032516f>]
ax25_transmit_buffer+0xef/0x130 [ax25]
Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffffa0325238>]
ax25_send_iframe+0x88/0xe0 [ax25]
Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffffa032536e>]
ax25_kick+0xde/0x220 [ax25]
Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffffa0326715>]
ax25_std_frame_in+0x65/0x920 [ax25]
Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffffa03241da>]
ax25_rcv+0x3aa/0x9a0 [ax25]
Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffffa032486f>]
ax25_kiss_rcv+0x9f/0xb0 [ax25]
Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff8133bba5>]
__netif_receive_skb+0x205/0x6d0
Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff8133c144>]
process_backlog+0xd4/0x1e0
Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff8133c995>]
net_rx_action+0x125/0x270
Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff810618f1>]
__do_softirq+0xc1/0x210
Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff813ffa9c>] call_softirq+0x1c/0x30
Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff810627db>]
local_bh_enable_ip+0xeb/0xf0
Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff813f6594>]
_raw_spin_unlock_bh+0x34/0x40
Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffffa0186522>]
mkiss_receive_buf+0x2e2/0x3dc [mkiss]
Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff8129e122>]
flush_to_ldisc+0x1b2/0x1d0
Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff810762c0>]
process_one_work+0x1a0/0x510
Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff81078ba2>]
worker_thread+0x172/0x400
Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff8107d816>] kthread+0xb6/0xc0
Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff813ff9a4>]
kernel_thread_helper+0x4/0x10
Jun 16 12:03:34 f6bvp-9 kernel: irq event stamp: 76635461
Jun 16 12:03:34 f6bvp-9 kernel: hardirqs last enabled at (76635461):
[<ffffffff813f6620>] _raw_spin_unlock_irqrestore+0x40/0x70
Jun 16 12:03:34 f6bvp-9 kernel: hardirqs last disabled at (76635460):
[<ffffffff813f5f1e>] _raw_spin_lock_irqsave+0x2e/0x70
Jun 16 12:03:34 f6bvp-9 kernel: softirqs last enabled at (76635394):
[<ffffffff81329337>] sk_common_release+0x67/0xd0
Jun 16 12:03:34 f6bvp-9 kernel: softirqs last disabled at (76635392):
[<ffffffff813f60f6>] _raw_write_lock_bh+0x16/0x50
Jun 16 12:03:34 f6bvp-9 kernel:
Jun 16 12:03:34 f6bvp-9 kernel: other info that might help us debug this:
Jun 16 12:03:34 f6bvp-9 kernel: 2 locks held by ax25ipd/2813:
Jun 16 12:03:34 f6bvp-9 kernel: #0: (big_tty_mutex){+.+.+.}, at:
[<ffffffff813f67ce>] tty_lock+0x2e/0x4f
Jun 16 12:03:34 f6bvp-9 kernel: #1: (&tty->ldisc_mutex){+.+.+.}, at:
[<ffffffff8129d597>] tty_ldisc_hangup+0xe7/0x250
Jun 16 12:03:34 f6bvp-9 kernel:
Jun 16 12:03:34 f6bvp-9 kernel: stack backtrace:
Jun 16 12:03:34 f6bvp-9 kernel: Pid: 2813, comm: ax25ipd Not tainted
2.6.39.1 #3
Jun 16 12:03:34 f6bvp-9 kernel: Call Trace:
Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff81092dc0>]
print_usage_bug+0x170/0x180
Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff81093a81>] mark_lock+0x211/0x3f0
Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff810948c4>]
__lock_acquire+0x5f4/0x14c0
Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff81093ccb>] ?
mark_held_locks+0x6b/0xa0
Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff813f65d0>] ?
_raw_spin_unlock_irq+0x30/0x40
Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff81093fcd>] ?
trace_hardirqs_on_caller+0x13d/0x180
Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff81095836>] lock_acquire+0xa6/0x160
Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffffa018552b>] ?
mkiss_close+0x1b/0x90 [mkiss]
Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff81093ccb>] ?
mark_held_locks+0x6b/0xa0
Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff813f6221>]
_raw_write_lock+0x31/0x40
Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffffa018552b>] ?
mkiss_close+0x1b/0x90 [mkiss]
Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff8113775e>] ?
kmem_cache_alloc_trace+0x7e/0x140
Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffffa018552b>]
mkiss_close+0x1b/0x90 [mkiss]
Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff8129c84b>]
tty_ldisc_close+0x4b/0x70
Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff8129ce90>]
tty_ldisc_reinit+0x40/0x80
Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff8129d5b4>]
tty_ldisc_hangup+0x104/0x250
Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff8129588c>]
__tty_hangup+0x15c/0x3e0
Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff8109401d>] ?
trace_hardirqs_on+0xd/0x10
Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff81295b3e>] tty_vhangup+0xe/0x10
Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff8129f37e>] pty_close+0x10e/0x160
Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff81295ceb>] tty_release+0x16b/0x640
Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff8113920a>] ?
kmem_cache_free+0x11a/0x160
Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff81142f9a>] fput+0xea/0x230
Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff8113ee03>] filp_close+0x63/0x90
Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff8105dab1>]
put_files_struct+0x171/0x190
Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff8105d978>] ?
put_files_struct+0x38/0x190
Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff8105db22>] exit_files+0x52/0x60
Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff8105deb9>] do_exit+0x189/0x860
Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff81142cc0>] ? fget+0xd0/0xd0
Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff813f69b9>] ?
retint_swapgs+0x13/0x1b
Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff8105e5eb>] do_group_exit+0x5b/0xd0
Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff8105e677>]
sys_exit_group+0x17/0x20
Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff813fe812>]
system_call_fastpath+0x16/0x1b
Kernel is 2.6.39.1
Is there something wrong in AX25 code or (more unlikely) is this
operation not permitted ?
Thanks for help.
Bernard Pidoux
--
To unsubscribe from this list: send the line "unsubscribe linux-hams" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 24+ messages in thread
* [AX25] inconsistent lock state
2010-01-15 20:36 ` [PATCH net-2.6] ax25: netrom: rose: Fix timer oopses Jarek Poplawski
2010-01-16 9:04 ` David Miller
2011-06-16 20:23 ` [AX25] inconsistent lock state f6bvp
@ 2011-06-16 20:40 ` f6bvp
2022-01-25 11:46 ` [AX25] ipv6 incompatible with AX.25 Bernard Pidoux
2011-07-07 13:31 ` Question with axudp Bernard, f6bvp
3 siblings, 1 reply; 24+ messages in thread
From: f6bvp @ 2011-06-16 20:40 UTC (permalink / raw)
To: linux-kernel; +Cc: Linux Netdev List, Ralf Baechle, linux-hams
Hi,
When unpluging ethernet connector a few seconds I observed the following
kernel message :
Jun 16 12:03:25 f6bvp-9 kernel: e1000e: eth1 NIC Link is Down
Jun 16 12:03:25 f6bvp-9 ifplugd(eth1)[1541]: Link beat lost.
Jun 16 12:03:31 f6bvp-9 ifplugd(eth1)[1541]: Executing
'/etc/ifplugd/ifplugd.action eth1 down'.
Jun 16 12:03:31 f6bvp-9 avahi-daemon[2197]: Withdrawing address record
for 192.168.0.66 on eth1.
Jun 16 12:03:31 f6bvp-9 avahi-daemon[2197]: Leaving mDNS multicast group
on interface eth1.IPv4 with address 192.168.0.66.
Jun 16 12:03:31 f6bvp-9 avahi-daemon[2197]: Interface eth1.IPv4 no
longer relevant for mDNS.
Jun 16 12:03:31 f6bvp-9 avahi-daemon[2197]: Withdrawing address record
for fe80::21c:c0ff:fe36:723e on eth1.
Jun 16 12:03:31 f6bvp-9 vnstatd[2022]: SIGHUP received, flushing data to
disk and reloading config.
Jun 16 12:03:31 f6bvp-9 ifplugd(eth1)[1541]: client: Rechargement de la
configuration de vnstatd : #033[65G[#033[1;32m OK #033[0;39m]#015
Jun 16 12:03:31 f6bvp-9 ifplugd(eth1)[1541]: Program executed successfully.
Jun 16 12:03:31 f6bvp-9 kernel: ADDRCONF(NETDEV_UP): eth1: link is not ready
Jun 16 12:03:34 f6bvp-9 kernel:
Jun 16 12:03:34 f6bvp-9 kernel: =================================
Jun 16 12:03:34 f6bvp-9 kernel: [ INFO: inconsistent lock state ]
Jun 16 12:03:34 f6bvp-9 kernel: 2.6.39.1 #3
Jun 16 12:03:34 f6bvp-9 kernel: ---------------------------------
Jun 16 12:03:34 f6bvp-9 kernel: inconsistent {IN-SOFTIRQ-R} ->
{SOFTIRQ-ON-W} usage.
Jun 16 12:03:34 f6bvp-9 kernel: ax25ipd/2813 [HC0[0]:SC0[0]:HE1:SE1] takes:
Jun 16 12:03:34 f6bvp-9 kernel: (disc_data_lock){+++?.-}, at:
[<ffffffffa018552b>] mkiss_close+0x1b/0x90 [mkiss]
Jun 16 12:03:34 f6bvp-9 kernel: {IN-SOFTIRQ-R} state was registered at:
Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff8109484e>]
__lock_acquire+0x57e/0x14c0
Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff81095836>]
lock_acquire+0xa6/0x160
Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff813f64f4>]
_raw_read_lock+0x34/0x50
Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffffa01850ed>]
mkiss_get+0x1d/0x50 [mkiss]
Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffffa018517e>]
mkiss_write_wakeup+0x1e/0xb0 [mkiss]
Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff8129457e>] tty_wakeup+0x6e/0x80
Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff8129f243>] pty_write+0x73/0x80
Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffffa0185d2e>]
ax_xmit+0x27e/0x5e0 [mkiss]
Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff81339dac>]
dev_hard_start_xmit+0x34c/0x6f0
Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff81358b4d>]
sch_direct_xmit+0xdd/0x260
Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff8133cc8f>]
dev_queue_xmit+0x1af/0x8a0
Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffffa0325072>]
ax25_queue_xmit+0x52/0x60 [ax25]
Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffffa032516f>]
ax25_transmit_buffer+0xef/0x130 [ax25]
Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffffa0325238>]
ax25_send_iframe+0x88/0xe0 [ax25]
Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffffa032536e>]
ax25_kick+0xde/0x220 [ax25]
Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffffa0326715>]
ax25_std_frame_in+0x65/0x920 [ax25]
Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffffa03241da>]
ax25_rcv+0x3aa/0x9a0 [ax25]
Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffffa032486f>]
ax25_kiss_rcv+0x9f/0xb0 [ax25]
Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff8133bba5>]
__netif_receive_skb+0x205/0x6d0
Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff8133c144>]
process_backlog+0xd4/0x1e0
Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff8133c995>]
net_rx_action+0x125/0x270
Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff810618f1>]
__do_softirq+0xc1/0x210
Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff813ffa9c>] call_softirq+0x1c/0x30
Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff810627db>]
local_bh_enable_ip+0xeb/0xf0
Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff813f6594>]
_raw_spin_unlock_bh+0x34/0x40
Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffffa0186522>]
mkiss_receive_buf+0x2e2/0x3dc [mkiss]
Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff8129e122>]
flush_to_ldisc+0x1b2/0x1d0
Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff810762c0>]
process_one_work+0x1a0/0x510
Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff81078ba2>]
worker_thread+0x172/0x400
Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff8107d816>] kthread+0xb6/0xc0
Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff813ff9a4>]
kernel_thread_helper+0x4/0x10
Jun 16 12:03:34 f6bvp-9 kernel: irq event stamp: 76635461
Jun 16 12:03:34 f6bvp-9 kernel: hardirqs last enabled at (76635461):
[<ffffffff813f6620>] _raw_spin_unlock_irqrestore+0x40/0x70
Jun 16 12:03:34 f6bvp-9 kernel: hardirqs last disabled at (76635460):
[<ffffffff813f5f1e>] _raw_spin_lock_irqsave+0x2e/0x70
Jun 16 12:03:34 f6bvp-9 kernel: softirqs last enabled at (76635394):
[<ffffffff81329337>] sk_common_release+0x67/0xd0
Jun 16 12:03:34 f6bvp-9 kernel: softirqs last disabled at (76635392):
[<ffffffff813f60f6>] _raw_write_lock_bh+0x16/0x50
Jun 16 12:03:34 f6bvp-9 kernel:
Jun 16 12:03:34 f6bvp-9 kernel: other info that might help us debug this:
Jun 16 12:03:34 f6bvp-9 kernel: 2 locks held by ax25ipd/2813:
Jun 16 12:03:34 f6bvp-9 kernel: #0: (big_tty_mutex){+.+.+.}, at:
[<ffffffff813f67ce>] tty_lock+0x2e/0x4f
Jun 16 12:03:34 f6bvp-9 kernel: #1: (&tty->ldisc_mutex){+.+.+.}, at:
[<ffffffff8129d597>] tty_ldisc_hangup+0xe7/0x250
Jun 16 12:03:34 f6bvp-9 kernel:
Jun 16 12:03:34 f6bvp-9 kernel: stack backtrace:
Jun 16 12:03:34 f6bvp-9 kernel: Pid: 2813, comm: ax25ipd Not tainted
2.6.39.1 #3
Jun 16 12:03:34 f6bvp-9 kernel: Call Trace:
Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff81092dc0>]
print_usage_bug+0x170/0x180
Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff81093a81>] mark_lock+0x211/0x3f0
Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff810948c4>]
__lock_acquire+0x5f4/0x14c0
Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff81093ccb>] ?
mark_held_locks+0x6b/0xa0
Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff813f65d0>] ?
_raw_spin_unlock_irq+0x30/0x40
Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff81093fcd>] ?
trace_hardirqs_on_caller+0x13d/0x180
Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff81095836>] lock_acquire+0xa6/0x160
Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffffa018552b>] ?
mkiss_close+0x1b/0x90 [mkiss]
Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff81093ccb>] ?
mark_held_locks+0x6b/0xa0
Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff813f6221>]
_raw_write_lock+0x31/0x40
Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffffa018552b>] ?
mkiss_close+0x1b/0x90 [mkiss]
Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff8113775e>] ?
kmem_cache_alloc_trace+0x7e/0x140
Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffffa018552b>]
mkiss_close+0x1b/0x90 [mkiss]
Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff8129c84b>]
tty_ldisc_close+0x4b/0x70
Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff8129ce90>]
tty_ldisc_reinit+0x40/0x80
Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff8129d5b4>]
tty_ldisc_hangup+0x104/0x250
Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff8129588c>]
__tty_hangup+0x15c/0x3e0
Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff8109401d>] ?
trace_hardirqs_on+0xd/0x10
Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff81295b3e>] tty_vhangup+0xe/0x10
Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff8129f37e>] pty_close+0x10e/0x160
Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff81295ceb>] tty_release+0x16b/0x640
Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff8113920a>] ?
kmem_cache_free+0x11a/0x160
Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff81142f9a>] fput+0xea/0x230
Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff8113ee03>] filp_close+0x63/0x90
Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff8105dab1>]
put_files_struct+0x171/0x190
Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff8105d978>] ?
put_files_struct+0x38/0x190
Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff8105db22>] exit_files+0x52/0x60
Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff8105deb9>] do_exit+0x189/0x860
Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff81142cc0>] ? fget+0xd0/0xd0
Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff813f69b9>] ?
retint_swapgs+0x13/0x1b
Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff8105e5eb>] do_group_exit+0x5b/0xd0
Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff8105e677>]
sys_exit_group+0x17/0x20
Jun 16 12:03:34 f6bvp-9 kernel: [<ffffffff813fe812>]
system_call_fastpath+0x16/0x1b
Kernel is 2.6.39.1
Is there something wrong in AX25 code or (more unlikely) is this
operation not permitted ?
Thanks for help.
Bernard Pidoux
--
To unsubscribe from this list: send the line "unsubscribe linux-hams" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [AX25] inconsistent lock state
2011-06-16 20:23 ` [AX25] inconsistent lock state f6bvp
@ 2011-06-17 13:28 ` Ralf Baechle
2011-06-17 13:36 ` Arnd Bergmann
1 sibling, 0 replies; 24+ messages in thread
From: Ralf Baechle @ 2011-06-17 13:28 UTC (permalink / raw)
To: f6bvp; +Cc: linux-kernel, Jarek Poplawski, Linux Netdev List, linux-hams
On Thu, Jun 16, 2011 at 10:23:09PM +0200, f6bvp wrote:
> When unpluging ethernet connector a few seconds I observed the
> following kernel message :
Can you describe your setup and what you did to trigger this?
Ralf
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [AX25] inconsistent lock state
2011-06-16 20:23 ` [AX25] inconsistent lock state f6bvp
2011-06-17 13:28 ` Ralf Baechle
@ 2011-06-17 13:36 ` Arnd Bergmann
2011-06-17 13:51 ` Ralf Baechle
1 sibling, 1 reply; 24+ messages in thread
From: Arnd Bergmann @ 2011-06-17 13:36 UTC (permalink / raw)
To: f6bvp
Cc: linux-kernel, Jarek Poplawski, Linux Netdev List, Ralf Baechle,
linux-hams
On Thursday 16 June 2011 22:23:09 f6bvp wrote:
> Jun 16 12:03:34 f6bvp-9 kernel: =================================
> Jun 16 12:03:34 f6bvp-9 kernel: [ INFO: inconsistent lock state ]
> Jun 16 12:03:34 f6bvp-9 kernel: 2.6.39.1 #3
> Jun 16 12:03:34 f6bvp-9 kernel: ---------------------------------
> Jun 16 12:03:34 f6bvp-9 kernel: inconsistent {IN-SOFTIRQ-R} -> {SOFTIRQ-ON-W} usage.
> Jun 16 12:03:34 f6bvp-9 kernel: ax25ipd/2813 [HC0[0]:SC0[0]:HE1:SE1] takes:
> Jun 16 12:03:34 f6bvp-9 kernel: (disc_data_lock){+++?.-}, at: [<ffffffffa018552b>] mkiss_close+0x1b/0x90 [mkiss]
> Jun 16 12:03:34 f6bvp-9 kernel: {IN-SOFTIRQ-R} state was registered at:
> ...
> Is there something wrong in AX25 code or (more unlikely) is this
> operation not permitted ?
The message hints that disc_data_lock is aquired with softirqs disabled,
but does not itself disable softirqs, which can in rare circumstances
lead to a deadlock.
Does this fix it?
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
--- a/drivers/net/hamradio/mkiss.c
+++ b/drivers/net/hamradio/mkiss.c
@@ -708,11 +708,11 @@ static struct mkiss *mkiss_get(struct tty_struct *tty)
{
struct mkiss *ax;
- read_lock(&disc_data_lock);
+ read_lock_bh(&disc_data_lock);
ax = tty->disc_data;
if (ax)
atomic_inc(&ax->refcnt);
- read_unlock(&disc_data_lock);
+ read_unlock_bh(&disc_data_lock);
return ax;
}
@@ -813,10 +813,10 @@ static void mkiss_close(struct tty_struct *tty)
{
struct mkiss *ax;
- write_lock(&disc_data_lock);
+ write_lock_bh(&disc_data_lock);
ax = tty->disc_data;
tty->disc_data = NULL;
- write_unlock(&disc_data_lock);
+ write_unlock_bh(&disc_data_lock);
if (!ax)
return;
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [AX25] inconsistent lock state
2011-06-17 13:36 ` Arnd Bergmann
@ 2011-06-17 13:51 ` Ralf Baechle
2011-06-17 14:11 ` Arnd Bergmann
2011-06-17 15:26 ` [AX25] inconsistent lock state f6bvp
0 siblings, 2 replies; 24+ messages in thread
From: Ralf Baechle @ 2011-06-17 13:51 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: f6bvp, linux-kernel, Linux Netdev List, linux-hams
On Fri, Jun 17, 2011 at 03:36:15PM +0200, Arnd Bergmann wrote:
(Removed Jarek from cc; his email bounces.)
> The message hints that disc_data_lock is aquired with softirqs disabled,
> but does not itself disable softirqs, which can in rare circumstances
> lead to a deadlock.
>
> Does this fix it?
If so, drivers/net/hamradio.c, function sp_get() would probably need the
equivalent fix. Same for drivers/net/ppp_async.c:ap_get() and sp_get() in
drivers/net/ppp_synctty.c.
Ralf
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [AX25] inconsistent lock state
2011-06-17 13:51 ` Ralf Baechle
@ 2011-06-17 14:11 ` Arnd Bergmann
2011-06-17 15:31 ` f6bvp
2011-06-25 15:51 ` f6bvp
2011-06-17 15:26 ` [AX25] inconsistent lock state f6bvp
1 sibling, 2 replies; 24+ messages in thread
From: Arnd Bergmann @ 2011-06-17 14:11 UTC (permalink / raw)
To: Ralf Baechle; +Cc: f6bvp, linux-kernel, Linux Netdev List, linux-hams
On Friday 17 June 2011 15:51:48 Ralf Baechle wrote:
> On Fri, Jun 17, 2011 at 03:36:15PM +0200, Arnd Bergmann wrote:
>
> (Removed Jarek from cc; his email bounces.)
>
> > The message hints that disc_data_lock is aquired with softirqs disabled,
> > but does not itself disable softirqs, which can in rare circumstances
> > lead to a deadlock.
> >
> > Does this fix it?
>
> If so, drivers/net/hamradio.c, function sp_get() would probably need the
> equivalent fix. Same for drivers/net/ppp_async.c:ap_get() and sp_get() in
> drivers/net/ppp_synctty.c.
It seems that ppp_synctty.c is ok, it uses write_lock_irq() already,
sixpack.c looks like it has the same bug as mkiss. I also realized
after sending out the patch that only the write_lock needs to be
changed to write_lock_bh, while read_lock can leave softirqs enabled
because it can be called recursively.
Arnd
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [AX25] inconsistent lock state
2011-06-17 13:51 ` Ralf Baechle
2011-06-17 14:11 ` Arnd Bergmann
@ 2011-06-17 15:26 ` f6bvp
1 sibling, 0 replies; 24+ messages in thread
From: f6bvp @ 2011-06-17 15:26 UTC (permalink / raw)
To: Ralf Baechle; +Cc: Arnd Bergmann, linux-kernel, Linux Netdev List, linux-hams
Hi Ralf,
I wanted to check FPAC ROSE application behaviour when Ethernet link was
shutdown.
To do this I removed the ethernet connector !
I agree this was a very agressive action.
73s de Bernard, f6bvp
Le 17/06/2011 15:51, Ralf Baechle a écrit :
> On Fri, Jun 17, 2011 at 03:36:15PM +0200, Arnd Bergmann wrote:
>
> (Removed Jarek from cc; his email bounces.)
>
>> The message hints that disc_data_lock is aquired with softirqs disabled,
>> but does not itself disable softirqs, which can in rare circumstances
>> lead to a deadlock.
>>
>> Does this fix it?
> If so, drivers/net/hamradio.c, function sp_get() would probably need the
> equivalent fix. Same for drivers/net/ppp_async.c:ap_get() and sp_get() in
> drivers/net/ppp_synctty.c.
>
> Ralf
--
To unsubscribe from this list: send the line "unsubscribe linux-hams" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [AX25] inconsistent lock state
2011-06-17 14:11 ` Arnd Bergmann
@ 2011-06-17 15:31 ` f6bvp
2011-06-25 15:51 ` f6bvp
1 sibling, 0 replies; 24+ messages in thread
From: f6bvp @ 2011-06-17 15:31 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: Ralf Baechle, linux-kernel, Linux Netdev List, linux-hams
Hi Arnd,
I will apply your patch with write_lock_bh only following your
remark about recursive call.
I agree that the error message did not appear systematically
when doing what I did i.e. unpluging the ethernet cable from
the computer interface.
However, I will perform the same a few times and see what happens.
Many thanks.
Bernard
Le 17/06/2011 16:11, Arnd Bergmann a écrit :
> On Friday 17 June 2011 15:51:48 Ralf Baechle wrote:
>> On Fri, Jun 17, 2011 at 03:36:15PM +0200, Arnd Bergmann wrote:
>>
>> (Removed Jarek from cc; his email bounces.)
>>
>>> The message hints that disc_data_lock is aquired with softirqs disabled,
>>> but does not itself disable softirqs, which can in rare circumstances
>>> lead to a deadlock.
>>>
>>> Does this fix it?
>> If so, drivers/net/hamradio.c, function sp_get() would probably need the
>> equivalent fix. Same for drivers/net/ppp_async.c:ap_get() and sp_get() in
>> drivers/net/ppp_synctty.c.
> It seems that ppp_synctty.c is ok, it uses write_lock_irq() already,
> sixpack.c looks like it has the same bug as mkiss. I also realized
> after sending out the patch that only the write_lock needs to be
> changed to write_lock_bh, while read_lock can leave softirqs enabled
> because it can be called recursively.
>
> Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-hams" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [AX25] inconsistent lock state
2011-06-17 14:11 ` Arnd Bergmann
2011-06-17 15:31 ` f6bvp
@ 2011-06-25 15:51 ` f6bvp
2011-06-25 16:39 ` Ralf Baechle DL5RB
2012-10-21 15:18 ` [NetRom] possible circular locking dependency detected Bernard f6bvp
1 sibling, 2 replies; 24+ messages in thread
From: f6bvp @ 2011-06-25 15:51 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: Ralf Baechle, linux-kernel, Linux Netdev List, linux-hams
Hi,
I applied the patch and since then I could not reproduce the
inconsistent lock state.
Thus mkiss patch fixed it.
Thanks,
Bernard
Le 17/06/2011 16:11, Arnd Bergmann a écrit :
> On Friday 17 June 2011 15:51:48 Ralf Baechle wrote:
>> On Fri, Jun 17, 2011 at 03:36:15PM +0200, Arnd Bergmann wrote:
>>
>> (Removed Jarek from cc; his email bounces.)
>>
>>> The message hints that disc_data_lock is aquired with softirqs disabled,
>>> but does not itself disable softirqs, which can in rare circumstances
>>> lead to a deadlock.
>>>
>>> Does this fix it?
>> If so, drivers/net/hamradio.c, function sp_get() would probably need the
>> equivalent fix. Same for drivers/net/ppp_async.c:ap_get() and sp_get() in
>> drivers/net/ppp_synctty.c.
> It seems that ppp_synctty.c is ok, it uses write_lock_irq() already,
> sixpack.c looks like it has the same bug as mkiss. I also realized
> after sending out the patch that only the write_lock needs to be
> changed to write_lock_bh, while read_lock can leave softirqs enabled
> because it can be called recursively.
>
> Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-hams" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [AX25] inconsistent lock state
2011-06-25 15:51 ` f6bvp
@ 2011-06-25 16:39 ` Ralf Baechle DL5RB
2011-07-01 13:00 ` Bernard F6BVP
2012-10-21 15:18 ` [NetRom] possible circular locking dependency detected Bernard f6bvp
1 sibling, 1 reply; 24+ messages in thread
From: Ralf Baechle DL5RB @ 2011-06-25 16:39 UTC (permalink / raw)
To: f6bvp; +Cc: Arnd Bergmann, linux-kernel, Linux Netdev List, linux-hams
On Sat, Jun 25, 2011 at 05:51:39PM +0200, f6bvp wrote:
> I applied the patch and since then I could not reproduce the
> inconsistent lock state.
> Thus mkiss patch fixed it.
I also think the patch is the right thing, so
Acked-by: Ralf Baechle <ralf@linux-mips.org>
Ralf
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [AX25] inconsistent lock state
2011-06-25 16:39 ` Ralf Baechle DL5RB
@ 2011-07-01 13:00 ` Bernard F6BVP
2011-07-01 21:28 ` [PATCH] 6pack,mkiss: fix lock inconsistency Arnd Bergmann
0 siblings, 1 reply; 24+ messages in thread
From: Bernard F6BVP @ 2011-07-01 13:00 UTC (permalink / raw)
To: Ralf Baechle DL5RB
Cc: Arnd Bergmann, linux-kernel, Linux Netdev List, linux-hams
Hi all,
Now, who is going to commit this mkiss patch and the equivalent one for
sixpack.c ?
Bernard, f6bvp
Le 25/06/2011 18:39, Ralf Baechle DL5RB a écrit :
> On Sat, Jun 25, 2011 at 05:51:39PM +0200, f6bvp wrote:
>
>> I applied the patch and since then I could not reproduce the
>> inconsistent lock state.
>> Thus mkiss patch fixed it.
>
> I also think the patch is the right thing, so
>
> Acked-by: Ralf Baechle<ralf@linux-mips.org>
>
> Ralf
--
To unsubscribe from this list: send the line "unsubscribe linux-hams" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 24+ messages in thread
* [PATCH] 6pack,mkiss: fix lock inconsistency
2011-07-01 13:00 ` Bernard F6BVP
@ 2011-07-01 21:28 ` Arnd Bergmann
2011-07-02 0:30 ` David Miller
0 siblings, 1 reply; 24+ messages in thread
From: Arnd Bergmann @ 2011-07-01 21:28 UTC (permalink / raw)
To: Bernard F6BVP, David Miller
Cc: Ralf Baechle DL5RB, linux-kernel, Linux Netdev List, linux-hams
Lockdep found a locking inconsistency in the mkiss_close function:
> kernel: [ INFO: inconsistent lock state ]
> kernel: 2.6.39.1 #3
> kernel: ---------------------------------
> kernel: inconsistent {IN-SOFTIRQ-R} -> {SOFTIRQ-ON-W} usage.
> kernel: ax25ipd/2813 [HC0[0]:SC0[0]:HE1:SE1] takes:
> kernel: (disc_data_lock){+++?.-}, at: [<ffffffffa018552b>] mkiss_close+0x1b/0x90 [mkiss]
> kernel: {IN-SOFTIRQ-R} state was registered at:
The message hints that disc_data_lock is aquired with softirqs disabled,
but does not itself disable softirqs, which can in rare circumstances
lead to a deadlock.
The same problem is present in the 6pack driver, this patch fixes both
by using write_lock_bh instead of write_lock.
Reported-by: Bernard F6BVP <f6bvp@free.fr>
Tested-by: Bernard F6BVP <f6bvp@free.fr>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Ralf Baechle<ralf@linux-mips.org>
Cc: stable@kernel.org
---
On Friday 01 July 2011 15:00:35 Bernard F6BVP wrote:
>
> Now, who is going to commit this mkiss patch and the equivalent one for
> sixpack.c ?
Here's a formal patch with all the right tags, I assume that David Miller
will apply that to the netdev tree.
diff --git a/drivers/net/hamradio/6pack.c b/drivers/net/hamradio/6pack.c
index 9624cbf..fea7cb4 100644
--- a/drivers/net/hamradio/6pack.c
+++ b/drivers/net/hamradio/6pack.c
@@ -694,10 +694,10 @@ static void sixpack_close(struct tty_struct *tty)
{
struct sixpack *sp;
- write_lock(&disc_data_lock);
+ write_lock_bh(&disc_data_lock);
sp = tty->disc_data;
tty->disc_data = NULL;
- write_unlock(&disc_data_lock);
+ write_unlock_bh(&disc_data_lock);
if (!sp)
return;
diff --git a/drivers/net/hamradio/mkiss.c b/drivers/net/hamradio/mkiss.c
index 9f84c83..324f7bf 100644
--- a/drivers/net/hamradio/mkiss.c
+++ b/drivers/net/hamradio/mkiss.c
@@ -813,10 +813,10 @@ static void mkiss_close(struct tty_struct *tty)
{
struct mkiss *ax;
- write_lock(&disc_data_lock);
+ write_lock_bh(&disc_data_lock);
ax = tty->disc_data;
tty->disc_data = NULL;
- write_unlock(&disc_data_lock);
+ write_unlock_bh(&disc_data_lock);
if (!ax)
return;
^ permalink raw reply related [flat|nested] 24+ messages in thread
* Re: [PATCH] 6pack,mkiss: fix lock inconsistency
2011-07-01 21:28 ` [PATCH] 6pack,mkiss: fix lock inconsistency Arnd Bergmann
@ 2011-07-02 0:30 ` David Miller
0 siblings, 0 replies; 24+ messages in thread
From: David Miller @ 2011-07-02 0:30 UTC (permalink / raw)
To: arnd; +Cc: f6bvp, ralf, linux-kernel, netdev, linux-hams
From: Arnd Bergmann <arnd@arndb.de>
Date: Fri, 1 Jul 2011 23:28:46 +0200
> Lockdep found a locking inconsistency in the mkiss_close function:
>
>> kernel: [ INFO: inconsistent lock state ]
>> kernel: 2.6.39.1 #3
>> kernel: ---------------------------------
>> kernel: inconsistent {IN-SOFTIRQ-R} -> {SOFTIRQ-ON-W} usage.
>> kernel: ax25ipd/2813 [HC0[0]:SC0[0]:HE1:SE1] takes:
>> kernel: (disc_data_lock){+++?.-}, at: [<ffffffffa018552b>] mkiss_close+0x1b/0x90 [mkiss]
>> kernel: {IN-SOFTIRQ-R} state was registered at:
>
> The message hints that disc_data_lock is aquired with softirqs disabled,
> but does not itself disable softirqs, which can in rare circumstances
> lead to a deadlock.
> The same problem is present in the 6pack driver, this patch fixes both
> by using write_lock_bh instead of write_lock.
>
> Reported-by: Bernard F6BVP <f6bvp@free.fr>
> Tested-by: Bernard F6BVP <f6bvp@free.fr>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Acked-by: Ralf Baechle<ralf@linux-mips.org>
> Cc: stable@kernel.org
Applied, thanks!
^ permalink raw reply [flat|nested] 24+ messages in thread
* Question with axudp
2010-01-15 20:36 ` [PATCH net-2.6] ax25: netrom: rose: Fix timer oopses Jarek Poplawski
` (2 preceding siblings ...)
2011-06-16 20:40 ` f6bvp
@ 2011-07-07 13:31 ` Bernard, f6bvp
2011-07-07 21:43 ` Robert Thoelen
3 siblings, 1 reply; 24+ messages in thread
From: Bernard, f6bvp @ 2011-07-07 13:31 UTC (permalink / raw)
To: Robert Thoelen; +Cc: linux-hams
Hello Robert,
You have probably noticed that you can define different routes in
ax25ipd.conf according to SSIDs values with SSID zero as a wild card,
i.e. all SSIDs destinations will be routed via this address. For example :
#
route f6bvp-9 192.168.0.64 udp 10094 b
route f6bvp-8 192.168.0.64 udp 10094
route f6bvp-14 192.168.0.64 udp 10094
# F4BWT-0 = joker
route f4bwt-0 62.147.157.243 udp 10093 b
route kd4yal-0 kd4yal.servebbs.org udp 10093 b
route f6gov-0 f6gov.no-ip.org udp 10093 b
Note that parameter b will allow NetRom broadcast through this route.
You may also play with the verbose and min_obs parameter values in
/etc/ax25/nrbroadcast
With min_obs equal to 255 and verbose = 0 for a specific HF port there
will be minimal broadcast.
73 de Bernard, f6bvp
> List: linux-hams
> Subject: Question with axudp
> From: Robert Thoelen <kd1zd () rtcubed ! org>
> Date: 2011-07-05 23:30:55
> Message-ID: CAAynhLMhGVDiVsAugsWSOLTRkrw6OeXRYeyKJEdUVaHMmE0rZQ () mail ! gmail ! com
I have a system running UROnode, and I have a couple of internet
links. I want to create a virtual machine in a data center to run
UROnode and have my internet axudp links connect to that system.
Then, I can use one connection from my home station via axudp to
connect to the virtual machine. The purpose behind this is among
other reasons to keep netrom broadcasts from cluttering my RF node.
Anyway, the virtual machine seems to be working well and is
broadcasting its netrom node to the home system. I'm having trouble
getting the home system to send packets back to the virtual machine.
My question is: if I use a few ssids with my callsign, will that
cause ax25ipd from routing another ssid with my call? The virtual
machine is kd1zd-9, and the home system uses kd1zd-3 to kd1zd-7.
What could be causing the home system to not send packets out to the
virtual machine? The other axudp links in the .conf file work fine.
Thanks,
Bob
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Question with axudp
2011-07-07 13:31 ` Question with axudp Bernard, f6bvp
@ 2011-07-07 21:43 ` Robert Thoelen
0 siblings, 0 replies; 24+ messages in thread
From: Robert Thoelen @ 2011-07-07 21:43 UTC (permalink / raw)
To: linux-hams
I've got beyond my problem of my system not sending out packets. The
trouble I have now is that people can connect to my node, which only
has one link. When I or they try to connect to another station off
of it, we get disconnected.
For example, if my station is "A", the node I setup is "B", and
another person linking on the internet is "C", both "A" and "C" can
connect to "B", but when trying to connect beyond "B", a disconnect
occurs.
I've tried using "listen" to see if there are any clues, but I can't see any.
On Thu, Jul 7, 2011 at 9:31 AM, Bernard, f6bvp <f6bvp@free.fr> wrote:
> Hello Robert,
>
> You have probably noticed that you can define different routes in
> ax25ipd.conf according to SSIDs values with SSID zero as a wild card, i.e.
> all SSIDs destinations will be routed via this address. For example :
>
> #
> route f6bvp-9 192.168.0.64 udp 10094 b
> route f6bvp-8 192.168.0.64 udp 10094
> route f6bvp-14 192.168.0.64 udp 10094
> # F4BWT-0 = joker
> route f4bwt-0 62.147.157.243 udp 10093 b
> route kd4yal-0 kd4yal.servebbs.org udp 10093 b
> route f6gov-0 f6gov.no-ip.org udp 10093 b
>
> Note that parameter b will allow NetRom broadcast through this route.
>
> You may also play with the verbose and min_obs parameter values in
> /etc/ax25/nrbroadcast
> With min_obs equal to 255 and verbose = 0 for a specific HF port there will
> be minimal broadcast.
>
> 73 de Bernard, f6bvp
>
>
>> List: linux-hams
>> Subject: Question with axudp
>> From: Robert Thoelen <kd1zd () rtcubed ! org>
>> Date: 2011-07-05 23:30:55
>> Message-ID: CAAynhLMhGVDiVsAugsWSOLTRkrw6OeXRYeyKJEdUVaHMmE0rZQ () mail !
>> gmail ! com
>
> I have a system running UROnode, and I have a couple of internet
> links. I want to create a virtual machine in a data center to run
> UROnode and have my internet axudp links connect to that system.
> Then, I can use one connection from my home station via axudp to
> connect to the virtual machine. The purpose behind this is among
> other reasons to keep netrom broadcasts from cluttering my RF node.
>
> Anyway, the virtual machine seems to be working well and is
> broadcasting its netrom node to the home system. I'm having trouble
> getting the home system to send packets back to the virtual machine.
>
> My question is: if I use a few ssids with my callsign, will that
> cause ax25ipd from routing another ssid with my call? The virtual
> machine is kd1zd-9, and the home system uses kd1zd-3 to kd1zd-7.
>
> What could be causing the home system to not send packets out to the
> virtual machine? The other axudp links in the .conf file work fine.
>
> Thanks,
> Bob
>
--
Robert Thoelen, III KD1ZD
Station phone: (860) 849-1101
Check out the KD1ZD Amateur TCP/IP Radio
page at http://www.rtcubed.org/kd1zd
--
To unsubscribe from this list: send the line "unsubscribe linux-hams" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 24+ messages in thread
* [NetRom] possible circular locking dependency detected
2011-06-25 15:51 ` f6bvp
2011-06-25 16:39 ` Ralf Baechle DL5RB
@ 2012-10-21 15:18 ` Bernard f6bvp
1 sibling, 0 replies; 24+ messages in thread
From: Bernard f6bvp @ 2012-10-21 15:18 UTC (permalink / raw)
Cc: Ralf Baechle, linux-kernel, Linux Netdev List, linux-hams,
Bernard Pidoux
[-- Attachment #1: Type: text/plain, Size: 191 bytes --]
Hi,
When shutting down my dual core system, there was a possible circular
locking dependency detected that is related to NetRom.
Here is the syslog report.
Regards,
Bernard, f6bvp
[-- Attachment #2: ax25ipd_not_tainted.txt --]
[-- Type: text/plain, Size: 13728 bytes --]
Oct 21 12:10:35 f6bvp-8 aprslist[1773]: terminating on SIGTERM
Oct 21 12:10:35 f6bvp-8 fpacstat: terminating on SIGTERM
Oct 21 12:10:35 f6bvp-8 netromd[1653]: terminating on SIGTERM
Oct 21 12:10:35 f6bvp-8 ax25ipd:
Oct 21 12:10:35 f6bvp-8 ax25ipd: socket udp on port 10094
Oct 21 12:10:35 f6bvp-8 ax25ipd: mode tnc
Oct 21 12:10:35 f6bvp-8 ax25ipd: device /dev/ptmx
Oct 21 12:10:35 f6bvp-8 ax25ipd: speed 115200
Oct 21 12:10:35 f6bvp-8 ax25ipd: loglevel 1
Oct 21 12:10:35 f6bvp-8 ax25ipd:
Oct 21 12:10:35 f6bvp-8 ax25ipd: K4GBB 184.4.148.122 udp 10094 1
Oct 21 12:10:35 f6bvp-8 ax25ipd: F8COJ 0.0.0.0 udp 10093 1
Oct 21 12:10:35 f6bvp-8 ax25ipd: F3KT 62.147.189.164 udp 10093 1
Oct 21 12:10:35 f6bvp-8 ax25ipd: F6BVP-12 192.168.0.68 udp 10093 4
Oct 21 12:10:35 f6bvp-8 ax25ipd: F6BVP-11 192.168.0.115 udp 10093 4
Oct 21 12:10:35 f6bvp-8 ax25ipd: F6BVP-10 192.168.0.115 udp 10093 5
Oct 21 12:10:35 f6bvp-8 ax25ipd: VA2BBS 24.212.252.110 udp 10093 1
Oct 21 12:10:35 f6bvp-8 ax25ipd: ON4HU 81.243.88.115 udp 10093 1
Oct 21 12:10:35 f6bvp-8 ax25ipd: IZ3LSV 88.149.155.158 udp 10094 5
Oct 21 12:10:35 f6bvp-8 ax25ipd:
Oct 21 12:10:35 f6bvp-8 nfs-server[27474]: Arrêt de NFS kernel daemon
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150299]
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150313] ======================================================
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150317] [ INFO: possible circular locking dependency detected ]
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150321] 3.6.1 #1 Not tainted
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150325] -------------------------------------------------------
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150329] ax25ipd/1580 is trying to acquire lock:
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150333] (nr_node_list_lock){+.....}, at: [<ffffffffa06775ec>] nr_rt_device_down+0x7c/0x240 [netrom]
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150352]
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150352] but task is already holding lock:
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150356] (nr_neigh_list_lock){+.-.-.}, at: [<ffffffffa0677596>] nr_rt_device_down+0x26/0x240 [netrom]
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150373]
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150373] which lock already depends on the new lock.
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150373]
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150378]
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150378] the existing dependency chain (in reverse order) is:
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150382]
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150382] -> #2 (nr_neigh_list_lock){+.-.-.}:
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150396] [<ffffffff810b6452>] lock_acquire+0x92/0x120
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150409] [<ffffffff81482b76>] _raw_spin_lock_bh+0x36/0x50
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150418] [<ffffffffa06769eb>] nr_remove_neigh+0x1b/0xb0 [netrom]
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150429] [<ffffffffa0677c20>] nr_rt_ioctl+0x2b0/0xa60 [netrom]
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150438] [<ffffffffa0673fa1>] nr_ioctl+0x51/0x1d0 [netrom]
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150445] [<ffffffff813973e0>] sock_do_ioctl+0x30/0x70
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150454] [<ffffffff813976f9>] sock_ioctl+0x79/0x2f0
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150460] [<ffffffff8118dd08>] do_vfs_ioctl+0x98/0x560
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150468] [<ffffffff8118e261>] sys_ioctl+0x91/0xa0
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150477] [<ffffffff8148b6b9>] system_call_fastpath+0x16/0x1b
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150486]
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150486] -> #1 (&(&nr_node->node_lock)->rlock){+.....}:
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150498] [<ffffffff810b6452>] lock_acquire+0x92/0x120
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150505] [<ffffffff81482b76>] _raw_spin_lock_bh+0x36/0x50
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150512] [<ffffffffa0676acc>] nr_node_show+0x4c/0x150 [netrom]
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150522] [<ffffffff8119da5c>] seq_read+0x26c/0x420
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150529] [<ffffffff811e1046>] proc_reg_read+0x86/0xc0
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150537] [<ffffffff8117b01c>] vfs_read+0xac/0x180
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150546] [<ffffffff8117b13a>] sys_read+0x4a/0x90
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150552] [<ffffffff8148b6b9>] system_call_fastpath+0x16/0x1b
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150559]
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150559] -> #0 (nr_node_list_lock){+.....}:
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150571] [<ffffffff810b5c41>] __lock_acquire+0x1a91/0x1ce0
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150578] [<ffffffff810b6452>] lock_acquire+0x92/0x120
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150586] [<ffffffff81482b76>] _raw_spin_lock_bh+0x36/0x50
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150592] [<ffffffffa06775ec>] nr_rt_device_down+0x7c/0x240 [netrom]
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150601] [<ffffffffa0674b4d>] nr_device_event+0x7d/0xa0 [netrom]
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150608] [<ffffffff81487388>] notifier_call_chain+0x58/0xb0
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150617] [<ffffffff810810c6>] raw_notifier_call_chain+0x16/0x20
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150625] [<ffffffff813ae526>] call_netdevice_notifiers+0x36/0x60
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150633] [<ffffffff813ae71f>] dev_close_many+0xbf/0x100
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150639] [<ffffffff813ae838>] rollback_registered_many+0xd8/0x250
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150645] [<ffffffff813aea4d>] rollback_registered+0x2d/0x40
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150653] [<ffffffff813b17a8>] unregister_netdevice_queue+0x68/0xc0
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150659] [<ffffffff813b1820>] unregister_netdev+0x20/0x30
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150666] [<ffffffffa05df4e7>] mkiss_close+0x57/0x90 [mkiss]
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150674] [<ffffffff81309ed1>] tty_ldisc_close.isra.2+0x41/0x60
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150683] [<ffffffff8130a0d0>] tty_ldisc_reinit+0x40/0x80
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150689] [<ffffffff8130a850>] tty_ldisc_hangup+0x190/0x340
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150695] [<ffffffff81301f8a>] __tty_hangup+0x10a/0x3c0
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150703] [<ffffffff8130226e>] tty_vhangup+0xe/0x10
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150709] [<ffffffff8130c66e>] pty_close+0x10e/0x180
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150716] [<ffffffff81303212>] tty_release+0x182/0x5c0
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150724] [<ffffffff8117bf9e>] __fput+0xae/0x230
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150734] [<ffffffff8117c12e>] ____fput+0xe/0x10
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150740] [<ffffffff81076fb9>] task_work_run+0x69/0x90
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150748] [<ffffffff8105abef>] do_exit+0x87f/0x900
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150756] [<ffffffff8105afce>] do_group_exit+0x4e/0xc0
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150763] [<ffffffff8105b057>] sys_exit_group+0x17/0x20
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150770] [<ffffffff8148b6b9>] system_call_fastpath+0x16/0x1b
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150778]
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150778] other info that might help us debug this:
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150778]
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150782] Chain exists of:
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150782] nr_node_list_lock --> &(&nr_node->node_lock)->rlock --> nr_neigh_list_lock
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150782]
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150799] Possible unsafe locking scenario:
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150799]
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150803] CPU0 CPU1
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150806] ---- ----
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150809] lock(nr_neigh_list_lock);
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150819] lock(&(&nr_node->node_lock)->rlock);
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150826] lock(nr_neigh_list_lock);
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150834] lock(nr_node_list_lock);
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150842]
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150842] *** DEADLOCK ***
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150842]
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150847] 4 locks held by ax25ipd/1580:
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150851] #0: (big_tty_mutex){+.+.+.}, at: [<ffffffff814832d7>] tty_lock+0x17/0x19
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150867] #1: (&tty->ldisc_mutex){+.+.+.}, at: [<ffffffff8130a7d7>] tty_ldisc_hangup+0x117/0x340
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150885] #2: (rtnl_mutex){+.+.+.}, at: [<ffffffff813c11c7>] rtnl_lock+0x17/0x20
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150901] #3: (nr_neigh_list_lock){+.-.-.}, at: [<ffffffffa0677596>] nr_rt_device_down+0x26/0x240 [netrom]
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150921]
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150921] stack backtrace:
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150927] Pid: 1580, comm: ax25ipd Not tainted 3.6.1 #1
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150930] Call Trace:
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150938] [<ffffffff81479b5a>] print_circular_bug+0x289/0x29a
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150945] [<ffffffff810b5c41>] __lock_acquire+0x1a91/0x1ce0
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150954] [<ffffffffa06775ec>] ? nr_rt_device_down+0x7c/0x240 [netrom]
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150960] [<ffffffff810b6452>] lock_acquire+0x92/0x120
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150969] [<ffffffffa06775ec>] ? nr_rt_device_down+0x7c/0x240 [netrom]
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150976] [<ffffffff81482b76>] _raw_spin_lock_bh+0x36/0x50
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150984] [<ffffffffa06775ec>] ? nr_rt_device_down+0x7c/0x240 [netrom]
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150990] [<ffffffff810b6ec5>] ? trace_hardirqs_on_caller+0x105/0x190
Oct 21 12:10:36 f6bvp-8 kernel: [522519.150997] [<ffffffffa0674b41>] ? nr_device_event+0x71/0xa0 [netrom]
Oct 21 12:10:36 f6bvp-8 kernel: [522519.151005] [<ffffffffa06775ec>] nr_rt_device_down+0x7c/0x240 [netrom]
Oct 21 12:10:36 f6bvp-8 kernel: [522519.151011] [<ffffffff8105d1a7>] ? local_bh_enable_ip+0x97/0x100
Oct 21 12:10:36 f6bvp-8 kernel: [522519.151019] [<ffffffffa0674b4d>] nr_device_event+0x7d/0xa0 [netrom]
Oct 21 12:10:36 f6bvp-8 kernel: [522519.151026] [<ffffffff81487388>] notifier_call_chain+0x58/0xb0
Oct 21 12:10:36 f6bvp-8 kernel: [522519.151033] [<ffffffff810810c6>] raw_notifier_call_chain+0x16/0x20
Oct 21 12:10:36 f6bvp-8 kernel: [522519.151038] [<ffffffff813ae526>] call_netdevice_notifiers+0x36/0x60
Oct 21 12:10:36 f6bvp-8 kernel: [522519.151044] [<ffffffff813ae71f>] dev_close_many+0xbf/0x100
Oct 21 12:10:36 f6bvp-8 kernel: [522519.151050] [<ffffffff813ae838>] rollback_registered_many+0xd8/0x250
Oct 21 12:10:36 f6bvp-8 kernel: [522519.151055] [<ffffffff813aea4d>] rollback_registered+0x2d/0x40
Oct 21 12:10:36 f6bvp-8 kernel: [522519.151061] [<ffffffff813b17a8>] unregister_netdevice_queue+0x68/0xc0
Oct 21 12:10:36 f6bvp-8 kernel: [522519.151068] [<ffffffff813b1820>] unregister_netdev+0x20/0x30
Oct 21 12:10:36 f6bvp-8 kernel: [522519.151077] [<ffffffffa05df4e7>] mkiss_close+0x57/0x90 [mkiss]
Oct 21 12:10:36 f6bvp-8 kernel: [522519.151083] [<ffffffff81309ed1>] tty_ldisc_close.isra.2+0x41/0x60
Oct 21 12:10:36 f6bvp-8 kernel: [522519.151089] [<ffffffff8130a0d0>] tty_ldisc_reinit+0x40/0x80
Oct 21 12:10:36 f6bvp-8 kernel: [522519.151094] [<ffffffff8130a850>] tty_ldisc_hangup+0x190/0x340
Oct 21 12:10:36 f6bvp-8 kernel: [522519.151101] [<ffffffff81301f8a>] __tty_hangup+0x10a/0x3c0
Oct 21 12:10:36 f6bvp-8 kernel: [522519.151107] [<ffffffff810b6f5d>] ? trace_hardirqs_on+0xd/0x10
Oct 21 12:10:36 f6bvp-8 kernel: [522519.151114] [<ffffffff8130226e>] tty_vhangup+0xe/0x10
Oct 21 12:10:36 f6bvp-8 kernel: [522519.151120] [<ffffffff8130c66e>] pty_close+0x10e/0x180
Oct 21 12:10:36 f6bvp-8 kernel: [522519.151126] [<ffffffff81303212>] tty_release+0x182/0x5c0
Oct 21 12:10:36 f6bvp-8 kernel: [522519.151132] [<ffffffff81192d92>] ? dput+0x62/0x1b0
Oct 21 12:10:36 f6bvp-8 kernel: [522519.151138] [<ffffffff8117bf9e>] __fput+0xae/0x230
Oct 21 12:10:36 f6bvp-8 kernel: [522519.151144] [<ffffffff8117c12e>] ____fput+0xe/0x10
Oct 21 12:10:36 f6bvp-8 kernel: [522519.151148] [<ffffffff81076fb9>] task_work_run+0x69/0x90
Oct 21 12:10:36 f6bvp-8 kernel: [522519.151148] [<ffffffff8105abef>] do_exit+0x87f/0x900
Oct 21 12:10:36 f6bvp-8 kernel: [522519.151148] [<ffffffff81483495>] ? retint_swapgs+0x13/0x1b
Oct 21 12:10:36 f6bvp-8 kernel: [522519.151148] [<ffffffff8105afce>] do_group_exit+0x4e/0xc0
Oct 21 12:10:36 f6bvp-8 kernel: [522519.151148] [<ffffffff8105b057>] sys_exit_group+0x17/0x20
Oct 21 12:10:36 f6bvp-8 kernel: [522519.151148] [<ffffffff8148b6b9>] system_call_fastpath+0x16/0x1b
^ permalink raw reply [flat|nested] 24+ messages in thread
* [AX25] ipv6 incompatible with AX.25
2011-06-16 20:40 ` f6bvp
@ 2022-01-25 11:46 ` Bernard Pidoux
2022-01-25 18:14 ` David Ranch
2022-02-06 21:12 ` [AX25] unreleased sockets after disconnecting Bernard Pidoux , f6bvp
0 siblings, 2 replies; 24+ messages in thread
From: Bernard Pidoux @ 2022-01-25 11:46 UTC (permalink / raw)
To: linux-hams; +Cc: List for the LINUX version of FBB, fpac, F3KT, F6BVP
Hi,
Recently installing a new node for kernel rose module debugging (...) I
experienced a few connexion troubles.
Some are already known AX.25 bug and rose bug that I wanted to
investigate taking advantage of kernel Ubuntu 5.4.151 source
availability that can be patched and module recompiled.
Here is a new feature interfering with AX.25 connexions as displayed in
/var/log/syslog :
Jan 25 12:16:31 f6bvp-Ubuntu kernel: [ 6942.400016] IPv6:
ADDRCONF(NETDEV_CHANGE): ax0: link becomes ready
After some investigations I added the following four lines in
/etc/sysctl.conf and rebooted :
# Disable ipv6
net.ipv6.conf.all.disable_ipv6=1
net.ipv6.conf.default.disable_ipv6=1
net.ipv6.conf.lo.disable_ipv6=1
Then no more ipv6 are shown by ifconfig and AX25 connexions via LAN are
now ok !
enp5s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 44.168.19.21 netmask 255.255.255.240 broadcast 44.168.19.31
ether 00:23:54:8d:41:e9 txqueuelen 1000 (Ethernet)
RX packets 44907 bytes 60439240 (60.4 MB)
RX errors 0 dropped 53 overruns 0 frame 0
TX packets 16668 bytes 2115347 (2.1 MB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
Looking at my ROSE/FPAC nodes I found that I could perform the same
changes on my RaspBerry Pis nodes for better results.
I hope this will help and I have a question. Shall this line be
uncommented in sysctl.conf ?
# Uncomment the next line to enable packet forwarding for IPv4
#net.ipv4.ip_forward=1
I actually have the following in my ax25start script :
ax25start:echo 1 > /proc/sys/net/ipv4/ip_forward
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [AX25] ipv6 incompatible with AX.25
2022-01-25 11:46 ` [AX25] ipv6 incompatible with AX.25 Bernard Pidoux
@ 2022-01-25 18:14 ` David Ranch
2022-01-31 12:04 ` [ROSE] rose socket destination address empty in connect tests Bernard Pidoux , f6bvp
[not found] ` <724d87c5-3029-702a-32c9-b64677a2da0e@free.fr>
2022-02-06 21:12 ` [AX25] unreleased sockets after disconnecting Bernard Pidoux , f6bvp
1 sibling, 2 replies; 24+ messages in thread
From: David Ranch @ 2022-01-25 18:14 UTC (permalink / raw)
To: f6bvp, linux-hams; +Cc: List for the LINUX version of FBB, fpac, F3KT
Hey Bernard,
When you saw the lines:
--
Jan 25 12:16:31 f6bvp-Ubuntu kernel: [ 6942.400016] IPv6:
ADDRCONF(NETDEV_CHANGE): ax0: link becomes ready
--
was the AX25 interface not up and usable for classic packet regardless
of it's IPv6 state? Generally speaking, I had been been disabling IPv6
for the longest time but I've been leaving it enabled as all of us need
to start embracing IPv6. Anyway, on my Ubuntu 20.04 machine, I have
IPv6 enabled with AX25 interfaces present though I only have a link
local address on my primary Ethernet interface (no IPv6 on ax0). It
should be noted I do NOT use AXIPv4 and it wouldn't surprised me if
AXIPv6 doesn't work. There are a lot of tools in modern Linuxes that
don't even support all aspects of AX25, NETROM, ROSE, etc. in modern
tools like "ip", etc. Many of us have to resort to installing legacy
tools like ifconfig and route to get the job done.
--
$ ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state
UP group default qlen 1000
link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff
altname enp0s31f6
inet 192.168.0.25/24 brd 192.168.0.255 scope global dynamic
noprefixroute eth0
valid_lft 66471sec preferred_lft 66471sec
inet6 fe80::xxxx:xxxx:xxxx:xxxx/64 scope link
valid_lft forever preferred_lft forever
3: wlan0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue
state DOWN group default qlen 1000
link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff
altname wlp4s0
4: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue
state DOWN group default qlen 1000
link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff
inet 192.168.122.1/24 brd 192.168.122.255 scope global virbr0
valid_lft forever preferred_lft forever
5: virbr0-nic: <BROADCAST,MULTICAST> mtu 1500 qdisc fq_codel master
virbr0 state DOWN group default qlen 1000
link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff
11: ax0: <BROADCAST,UP,LOWER_UP> mtu 255 qdisc fq_codel state UNKNOWN
group default qlen 10
link/ax25 xx:xx:xx:xx:xx:xx:xx brd a2:a6:a8:40:40:40:00
inet 44.128.0.1/24 scope global ax0
valid_lft forever preferred_lft forever
--
> I hope this will help and I have a question. Shall this line be
> uncommented in sysctl.conf ?
>
> # Uncomment the next line to enable packet forwarding for IPv4
> #net.ipv4.ip_forward=1
I question if you really want this on as this should only be enabled if
you what your LInux device to be a router (aka.. forwarding packets
between one interface and another). This is NOT used if remote stations
just want to reach your machine via IP. Fyi, this kernel /proc command
alone isn't enough to get routing working. You also need to setup
forwarding policies using tools like iptables (legacy) or nftables
(newest way).
> I actually have the following in my ax25start script :
>
> ax25start:echo 1 > /proc/sys/net/ipv4/ip_forward
Same point as above.
--David
KI6ZHD
^ permalink raw reply [flat|nested] 24+ messages in thread
* [ROSE] rose socket destination address empty in connect tests
2022-01-25 18:14 ` David Ranch
@ 2022-01-31 12:04 ` Bernard Pidoux , f6bvp
[not found] ` <724d87c5-3029-702a-32c9-b64677a2da0e@free.fr>
1 sibling, 0 replies; 24+ messages in thread
From: Bernard Pidoux , f6bvp @ 2022-01-31 12:04 UTC (permalink / raw)
To: David Ranch, linux-hams; +Cc: F3KT
[-- Attachment #1: Type: text/plain, Size: 1096 bytes --]
I noticed and already reported elsewhere that rose protocol had been
broken since kernel 5.4.83.
The symptom is a very long delay during some connect requests
terminating after a connection timed out.
As suggested by David, using "rose_call" utility from ax25tools package,
I finally found that the reason of failure is an empty destination
address as shown in rose sockets displayed by netstat.
By the way, I am glad rose protocol dump patch I committed a while ago
is now incorporated into netstat, despite --rose option is still
undocumented in netstat manual and help. Only --ax25 and --netrom are
documented.
In attached file I demonstrate that rose socket destination address is
correctly populated when rose_call is used in kernel 5.4.79 but
unfortunately the address field is empty in kernel 5.4.83 and following
kernels. I added netrom_call for comparison.
This explains clearly why connect request stays in a waiting loop with
rose protocole !
Now, one has to find where rose socket destination address is erased or
forgotten in rose module or libc !
Bernard, f6bvp
[-- Attachment #2: Rose_call_comparison.txt --]
[-- Type: text/plain, Size: 3079 bytes --]
Linux f6bvp-Ubuntu 5.4.0-96-generic #109-Ubuntu SMP Wed Jan 12 16:49:16 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
netrom_call netnod f6bvp f6bvp-14
netrom_call netnod f6bvp f6bvp-2
rose_call rose0 f6bvp f6bvp-4 2080175524
rose_call rose0 f6bvp f6bvp-8 2080175520
netstat --rose --netrom
Active NET/ROM sockets at f6bvp-4 (Ubuntu 5.4.0-96)
User Dest Source Device State Vr/Vs Send-Q Recv-Q
F6BVP-0 F6BVP-14 F6BVP-2 nr0 CONN SENT 000/000 0 0
F6BVP-0 F6BVP-2 F6BVP-2 nr0 ESTABLISHED 000/001 0 0
F6BVP-0 F6BVP-2 F6BVP-2 nr0 ESTABLISHED 001/000 0 0
* * F6BVP-2 nr0 LISTENING 000/000 0 0
* * F6BVP-2 nr0 LISTENING 000/000 0 0
------------------------------------------------------------------------------
Active ROSE sockets at f6bvp-4 (Ubuntu 5.4.0-96)
dest_addr dest_call src_addr src_call dev lci neigh state
F6BVP-8 2080175524 F6BVP-0 rose0 1 2 ESTABLISHED
F6BVP-4 2080175524 F6BVP-0 rose0 2 1 DISC SENT
* 2080175524 FPAD-0 rose0 0 0 LISTENING
* 2080175524 ??????-? rose0 0 0 LISTENING
------------------------------------------------------------------------------
rose node f6bvp-4 connected by a rose_call from f6bvp at remote node f6bvp-8
rose_call rose0 f6bvp f6bvp-4 2080175524
rose_call rose0 f6bvp f6bvp-8 2080175520
Active NET/ROM sockets at f6bvp-8 (kernel 5.4.79)
User Dest Source Device State Vr/Vs Send-Q Recv-Q
* * F6BVP-2 nr0 LISTENING 000/000 0 0
* * F6BVP-2 nr0 LISTENING 000/000 0 0
------------------------------------------------------------------------------
netrom_call netnod f6bvp BVPN8:f6bvp-14
netrom_call netnod f6bvp BVPN4:F6BVP-2
sockets NET/ROM actives at f6bvp-8 (kernel 5.4.79)
Utilisatr Dest Source Periph Etat Vr/Vs Send-Q Recv-Q
F6BVP-0 F6BVP-2 F6BVP-14 nr0 CONN SENT 000/000 0 0
F6BVP-0 F6BVP-14 F6BVP-14 nr0 ESTABLISHED 000/001 0 0
F6BVP-0 F6BVP-14 F6BVP-14 nr0 ESTABLISHED 001/000 0 0
* * F6BVP-14 nr0 LISTENING 000/000 0 0
* * F6BVP-14 nr0 LISTENING 000/000 0 0
-------------------------------------------------------------------------------
rose node f6bvp-8 connected by a rose_call from f6bvp-8
rose_call rose0 f6bvp f6bvp-8 2080175520
Active ROSE sockets at f6bvp-8 (kernel 5.4.79)
dest_addr dest_call src_addr src_call dev lci neigh state
2080175524 F6BVP-4 2080175520 F6BVP-0 rose0 32 23 ESTABLISHED
2080175520 F6BVP-0 2080175520 F6BVP-8 rose0 31 1 ESTABLISHED
* * 2080175520 F6BVP-1 rose0 0 0 LISTENING
------------------------------------------------------------------------------
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [AX25] ipv6 incompatible with AX.25
[not found] ` <724d87c5-3029-702a-32c9-b64677a2da0e@free.fr>
@ 2022-01-31 17:36 ` Bernard Pidoux , f6bvp
0 siblings, 0 replies; 24+ messages in thread
From: Bernard Pidoux , f6bvp @ 2022-01-31 17:36 UTC (permalink / raw)
To: David Ranch, linux-hams; +Cc: List for the LINUX version of FBB
[-- Attachment #1: Type: text/plain, Size: 515 bytes --]
Hello David,
To answer more precisely your question I prefere to include the listing
of an ./ax25up script initializing AX.25 on my Ubuntu PC followed by
dmesg and ifconfig messages.
Without disabling IPv6 I confirm that my LAN AX.25 was not behaving
correctly as I wrote before.
It is strange that there are still two messages about IPv6 while
Ethernet device had previously been disabled in Ubuntu as shown.
Then ifconfig shows that IPv6 is also disabled by command in the script.
73 de Bernard, f6bvp
[-- Attachment #2: IPv6.txt --]
[-- Type: text/plain, Size: 1383 bytes --]
11.020470] IPv6: ADDRCONF(NETDEV_CHANGE): enp5s0: link becomes ready
.......
[ 77.279872] NET: Registered protocol family 3
[ 77.282810] mkiss: AX.25 Multikiss, Hans Albas PE1AYX
[ 77.283391] mkiss: ax0: crc mode is auto.
[ 77.283542] IPv6: ADDRCONF(NETDEV_CHANGE): ax0: link becomes ready
[ 79.303742] NET: Registered protocol family 6
[ 95.504868] mkiss: ax0: Trying crc-smack
[ 95.505128] mkiss: ax0: Trying crc-flexnet
./ax25up
net.ipv6.conf.all.disable_ipv6 = 1
/bin/rm: cannot remove '/var/ax25/fbb/*.res': No such file or directory
Installing ax25ipd Unix98 master pseudo tty
Installing a KISS link on ethernet port
Port axudp attached to ax0
Starting NetRom...
Init Netrom
NET/ROM port netnod bound to device nr0
NET: Registered protocol family 3
[ 65.032811] mkiss: AX.25 Multikiss, Hans Albas PE1AYX
[ 65.033552] mkiss: ax0: crc mode is auto.
[ 65.033739] IPv6: ADDRCONF(NETDEV_CHANGE): ax0: link becomes ready
[ 67.060544] NET: Registered protocol family 6
[ 83.265806] mkiss: ax0: Trying crc-smack
[ 83.265970] mkiss: ax0: Trying crc-flexnet
ax0: flags=67<UP,BROADCAST,RUNNING> mtu 253
ax25 F6BVP-4 txqueuelen 10 (AMPR AX.25)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 6 bytes 307 (307.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
^ permalink raw reply [flat|nested] 24+ messages in thread
* [AX25] unreleased sockets after disconnecting
2022-01-25 11:46 ` [AX25] ipv6 incompatible with AX.25 Bernard Pidoux
2022-01-25 18:14 ` David Ranch
@ 2022-02-06 21:12 ` Bernard Pidoux , f6bvp
2022-02-20 9:18 ` Thomas Osterried
1 sibling, 1 reply; 24+ messages in thread
From: Bernard Pidoux , f6bvp @ 2022-02-06 21:12 UTC (permalink / raw)
To: linux-hams
[-- Attachment #1: Type: text/plain, Size: 610 bytes --]
For long time it as been reported by many AX.25 users that connexions
were precluded after terminating a connexion with a remote station.
Some hamradio maintainers have been pretending not to be aware of such
issue for lacking proofs.
I must restart my packet radio FPAC node (AX.25, ROSE and NetRom
protocoles) every other hour in order to let connexions available again
for neighbours.
Here are some evidence from cat /proc/net/ax25 showing old remnants of
connexions presumably there for ax25 sockets were not released.
73 de Bernard, f6bvp
http://radiotelescope-lavillette.fr/
http://f6bvp.org
[-- Attachment #2: proc_net_ax25.txt --]
[-- Type: text/plain, Size: 18868 bytes --]
pi@F6BVP-8:~ $ cat /proc/net/ax25
5003cece ax0 F6BVP-14 CT1ENI-8 3 0 0 0 0 10 0 3 289 300 0 0 0 10 5 2 256 * * *
6cc44439 ax0 F6BVP-8* F6BVP-1,F6BVP-8* 1 0 0 0 34 40 0 3 0 300 0 0 3 10 5 2 256 0 0 146395
f5133389 ax0 F6BVP-1 * 0 0 0 0 0 10 0 3 0 300 0 0 0 10 5 2 256 0 0 150738
d66d172a ax0 F6BVP-1 * 0 0 0 0 0 10 0 3 0 300 0 0 0 10 5 2 256 0 0 150177
69126716 ax0 F6BVP-9 F6BVP-7 3 5 6 5 0 7 0 3 208 300 0 0 0 10 3 2 256 * * *
b369f029 ax0 F6BVP-9 VE3XPG-9 1 0 0 0 46 50 0 3 0 300 0 0 4 10 5 2 256 * * *
766f8f9e ax0 F6BVP-9 K4GBB-9 1 0 0 0 46 50 0 3 0 300 0 0 4 10 5 2 256 * * *
6a2b78e8 ax0 F6BVP-9 F6KKR-9 3 3 4 3 0 7 0 3 204 300 0 0 0 10 3 2 256 * * *
b421ffed ax0 F6BVP-9 F6CNB-9 1 0 0 0 46 50 0 3 0 300 0 0 4 10 5 2 256 * * *
a9bcab73 ax0 F6BVP-9 F3KT-11 3 3 3 3 0 7 0 3 204 300 0 0 0 10 3 2 256 * * *
cd3ca2e2 ax0 F6BVP-9 F5KTR-11 3 3 3 3 0 7 0 3 204 300 0 0 0 10 3 2 256 * * *
b2786e19 ax0 F6BVP-9 F6BVP-11 3 6 6 6 0 7 0 3 208 300 0 0 0 10 3 2 256 * * *
e76acc60 ax0 F6BVP-9 F6CNB-11 1 0 0 0 46 50 0 3 0 300 0 0 4 10 5 2 256 * * *
b7916c4d ax0 F6BVP-9 F6BVP-5 1 0 0 0 46 50 0 3 0 300 0 0 4 10 5 2 256 * * *
c524e5e2 ax0 F6BVP-9 SV2HRT-9 3 3 4 3 0 7 0 3 206 300 0 0 0 10 3 2 256 * * *
37e9dec5 ax0 F6BVP-9 NA7KR-9 1 0 0 0 46 50 0 3 0 300 0 0 4 10 5 2 256 * * *
5df12c98 ??? F6BVP-15* * 0 0 0 0 0 10 0 3 0 300 0 0 0 10 5 2 256 0 0 146297
5c22f399 ??? F6BVP-15 * 0 0 0 0 0 10 0 3 0 300 0 0 0 10 5 2 256 0 0 146296
12b99fab ??? F6BVP-8 * 0 0 0 0 0 10 0 3 0 300 0 0 0 10 5 2 256 0 0 150118
f8390732 ??? F6BVP-8* * 0 0 0 0 0 10 0 3 0 300 0 0 0 10 5 2 256 0 0 150117
da72643f ??? F6BVP-9* * 0 0 0 0 0 10 0 3 0 300 0 0 0 10 5 2 256 0 0 150116
8bcdc6af ax0 F6BVP-1 * 0 0 0 0 0 10 0 3 0 300 0 0 0 10 5 2 256 0 0 147235
2f401d3f ??? F6BVP-9 F3KT-11 0 7 3 7 0 4 0 3 0 300 0 0 0 10 2 2 256 * * *
25d1fc26 ??? F6BVP-14 CT1ENI-8 0 0 5 0 0 10 0 3 0 300 0 0 0 10 5 2 256 * * *
2e9a4094 ??? F6BVP-9 VE3XPG-9 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * *
9e33e87e ??? F6BVP-9 K4GBB-9 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * *
bb7f5961 ??? F6BVP-9 SV2HRT-9 0 5 2 5 0 5 0 3 0 300 0 0 0 10 2 2 256 * * *
f1ffdabd ??? F6BVP-9 NA7KR-9 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * *
bc41856c ??? F6BVP-9 F6BVP-7 0 0 0 0 0 5 0 3 0 300 0 0 0 10 2 2 256 * * *
815fc9a0 ??? F6BVP-9 F6BVP-11 0 3 2 2 0 4 0 3 0 300 0 0 0 10 2 2 256 * * *
db5a5ecd ??? F6BVP-14 CT1ENI-8 0 0 5 0 0 10 0 3 0 300 0 0 0 10 5 2 256 * * *
2b4612f8 ??? F6BVP-9 F6BVP-7 0 2 1 2 0 4 0 3 0 300 0 0 0 10 2 2 256 * * *
0c01c5a6 ??? F6BVP-9 VE3XPG-9 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * *
1454c25e ??? F6BVP-9 K4GBB-9 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * *
ee032b7b ??? F6BVP-9 F6KKR-9 0 5 7 5 0 6 0 3 0 300 0 0 0 10 3 2 256 * * *
29e476ec ??? F6BVP-9 F6CNB-9 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * *
f64f0c0a ??? F6BVP-9 F3KT-11 0 7 3 7 0 3 0 3 0 300 0 0 0 10 1 2 256 * * *
a141c42b ??? F6BVP-9 F5KTR-11 0 7 7 7 0 4 0 3 0 300 0 0 0 10 2 2 256 * * *
236bd0e7 ??? F6BVP-9 F6BVP-11 0 7 6 6 0 7 0 3 0 300 0 0 0 10 3 2 256 * * *
1cdabd88 ??? F6BVP-9 F6CNB-11 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * *
329a294b ??? F6BVP-9 F6BVP-5 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * *
ad7d5817 ??? F6BVP-9 SV2HRT-9 0 1 3 1 0 4 0 3 0 300 0 0 0 10 2 2 256 * * *
3faef81e ??? F6BVP-9 NA7KR-9 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * *
2c1200f5 ??? F6BVP-14 CT1ENI-8 0 0 5 0 0 10 0 3 0 300 0 0 0 10 5 2 256 * * *
a4e01182 ??? F6BVP-9 F6BVP-7 0 2 1 2 0 4 0 3 0 300 0 0 0 10 2 2 256 * * *
7c8bfddd ??? F6BVP-9 VE3XPG-9 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * *
91a654b0 ??? F6BVP-9 K4GBB-9 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * *
aae8b3c0 ??? F6BVP-9 F6KKR-9 0 4 6 4 0 7 0 3 0 300 0 0 0 10 3 2 256 * * *
ac2c0d0b ??? F6BVP-9 F6CNB-9 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * *
7102605f ??? F6BVP-9 F3KT-11 0 6 1 6 0 3 0 3 0 300 0 0 0 10 1 2 256 * * *
09da8a86 ??? F6BVP-9 F5KTR-11 0 5 5 5 0 4 0 3 0 300 0 0 0 10 2 2 256 * * *
32e82168 ??? F6BVP-9 F6BVP-11 0 7 6 6 0 7 0 3 0 300 0 0 0 10 3 2 256 * * *
e2ab507d ??? F6BVP-9 F6CNB-11 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * *
5f5ab697 ??? F6BVP-9 F6BVP-5 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * *
4e11b6d2 ??? F6BVP-9 SV2HRT-9 0 0 0 0 0 5 0 3 0 300 0 0 0 10 2 2 256 * * *
580ca5d8 ??? F6BVP-9 NA7KR-9 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * *
c4fb6d80 ??? F6BVP-14 CT1ENI-8 0 0 5 0 0 10 0 3 0 300 0 0 0 10 5 2 256 * * *
e5b82c26 ??? F6BVP-9 F6BVP-7 0 3 2 3 0 3 0 3 0 300 0 0 0 10 1 2 256 * * *
787f7d2a ??? F6BVP-9 VE3XPG-9 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * *
f4cf53af ??? F6BVP-9 K4GBB-9 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * *
fbc448d8 ??? F6BVP-9 F6KKR-9 0 4 6 4 0 7 0 3 0 300 0 0 0 10 3 2 256 * * *
205a459b ??? F6BVP-9 F6CNB-9 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * *
7427f903 ??? F6BVP-9 F3KT-11 0 0 3 0 0 3 0 3 0 300 0 0 0 10 1 2 256 * * *
6e8f2c70 ??? F6BVP-9 F5KTR-11 0 6 6 6 0 4 0 3 0 300 0 0 0 10 2 2 256 * * *
333b1672 ??? F6BVP-9 F6BVP-11 0 4 4 4 0 8 0 3 0 300 0 0 0 10 4 2 256 * * *
57a731d5 ??? F6BVP-9 F6CNB-11 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * *
4a62dd32 ??? F6BVP-9 F6BVP-5 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * *
1ad9c71b ??? F6BVP-9 SV2HRT-9 0 1 3 1 0 4 0 3 0 300 0 0 0 10 2 2 256 * * *
fe8b8732 ??? F6BVP-9 NA7KR-9 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * *
e40a2287 ??? F6BVP-14 CT1ENI-8 0 0 5 0 0 10 0 3 0 300 0 0 0 10 5 2 256 * * *
9f399c0e ??? F6BVP-9 F6BVP-7 0 2 1 2 0 4 0 3 0 300 0 0 0 10 2 2 256 * * *
17691e12 ??? F6BVP-9 VE3XPG-9 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * *
d057ea1f ??? F6BVP-9 K4GBB-9 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * *
7fdddaf1 ??? F6BVP-9 F6KKR-9 0 5 7 5 0 6 0 3 0 300 0 0 0 10 3 2 256 * * *
0838d276 ??? F6BVP-9 F6CNB-9 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * *
56f94d7c ??? F6BVP-9 F3KT-11 0 5 1 5 0 3 0 3 0 300 0 0 0 10 1 2 256 * * *
87bfd797 ??? F6BVP-9 F5KTR-11 0 3 3 3 0 4 0 3 0 300 0 0 0 10 2 2 256 * * *
92c1daa6 ??? F6BVP-9 F6BVP-11 0 7 6 6 0 7 0 3 0 300 0 0 0 10 3 2 256 * * *
8e7b67d3 ??? F6BVP-9 F6CNB-11 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * *
cbda6426 ??? F6BVP-9 F6BVP-5 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * *
43c3ba0f ??? F6BVP-9 SV2HRT-9 0 5 6 5 0 4 0 3 0 300 0 0 0 10 2 2 256 * * *
f8496df4 ??? F6BVP-9 NA7KR-9 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * *
179ad97f ??? F6BVP-14 CT1ENI-8 0 0 5 0 0 10 0 3 0 300 0 0 0 10 5 2 256 * * *
0db4eb8a ??? F6BVP-9 F6BVP-7 0 2 1 2 0 4 0 3 0 300 0 0 0 10 2 2 256 * * *
2b286aed ??? F6BVP-9 VE3XPG-9 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * *
22b2e8d3 ??? F6BVP-9 K4GBB-9 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * *
c6a97925 ??? F6BVP-9 F6KKR-9 0 4 6 4 0 6 0 3 0 300 0 0 0 10 3 2 256 * * *
81bb2072 ??? F6BVP-9 F6CNB-9 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * *
e24ffe27 ??? F6BVP-9 F3KT-11 0 4 0 4 0 3 0 3 0 300 0 0 0 10 1 2 256 * * *
011fdac8 ??? F6BVP-9 F5KTR-11 0 7 7 7 0 4 0 3 0 300 0 0 0 10 2 2 256 * * *
2c233acb ??? F6BVP-9 F6BVP-11 0 7 6 6 0 7 0 3 0 300 0 0 0 10 3 2 256 * * *
28f0eef0 ??? F6BVP-9 F6CNB-11 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * *
a13dbae2 ??? F6BVP-9 F6BVP-5 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * *
caa16fa8 ??? F6BVP-9 SV2HRT-9 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * *
38014152 ??? F6BVP-9 NA7KR-9 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * *
981df63d ??? F6BVP-14 CT1ENI-8 0 0 5 0 0 10 0 3 0 300 0 0 0 10 5 2 256 * * *
f5e00e0f ??? F6BVP-9 F6BVP-7 0 2 1 2 0 4 0 3 0 300 0 0 0 10 2 2 256 * * *
fc0f242f ??? F6BVP-9 VE3XPG-9 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * *
3cca8e30 ??? F6BVP-9 K4GBB-9 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * *
17cbd0be ??? F6BVP-9 F6KKR-9 0 4 6 4 0 7 0 3 0 300 0 0 0 10 3 2 256 * * *
c5088ba1 ??? F6BVP-9 F6CNB-9 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * *
9baa33fc ??? F6BVP-9 F3KT-11 0 3 0 3 0 3 0 3 0 300 0 0 0 10 1 2 256 * * *
819d4eb9 ??? F6BVP-9 F5KTR-11 0 3 0 3 0 3 0 3 0 300 0 0 0 10 1 2 256 * * *
d2b68e0d ??? F6BVP-9 F6BVP-11 0 7 6 6 0 7 0 3 0 300 0 0 0 10 3 2 256 * * *
ddfa546c ??? F6BVP-9 F6CNB-11 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * *
b0f953bc ??? F6BVP-9 F6BVP-5 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * *
b8a94f0e ??? F6BVP-9 SV2HRT-9 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * *
a8f267fb ??? F6BVP-9 NA7KR-9 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * *
b8bf7081 ??? F6BVP-14 CT1ENI-8 0 0 5 0 0 10 0 3 0 300 0 0 0 10 5 2 256 * * *
c14eee27 ??? F6BVP-9 F6BVP-7 0 2 1 2 0 4 0 3 0 300 0 0 0 10 2 2 256 * * *
41bcde27 ??? F6BVP-9 VE3XPG-9 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * *
342b49e7 ??? F6BVP-9 K4GBB-9 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * *
0832dbdf ??? F6BVP-9 F6KKR-9 0 5 7 5 0 6 0 3 0 300 0 0 0 10 3 2 256 * * *
97376b88 ??? F6BVP-9 F6CNB-9 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * *
a53b0ac2 ??? F6BVP-9 F3KT-11 0 5 2 5 0 3 0 3 0 300 0 0 0 10 1 2 256 * * *
5e77d1d0 ??? F6BVP-9 F5KTR-11 0 7 7 7 0 4 0 3 0 300 0 0 0 10 2 2 256 * * *
f895195f ??? F6BVP-9 F6BVP-11 0 7 6 6 0 7 0 3 0 300 0 0 0 10 3 2 256 * * *
d76b4443 ??? F6BVP-9 F6CNB-11 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * *
c225807b ??? F6BVP-9 F6BVP-5 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * *
fed88d20 ??? F6BVP-9 SV2HRT-9 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * *
9aff6a70 ??? F6BVP-9 NA7KR-9 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * *
f4b09f9f ??? F6BVP-9 F3KT-11 0 5 2 5 0 4 0 3 0 300 0 0 0 10 2 2 256 * * *
a32d1e88 ??? F6BVP-14 CT1ENI-8 0 0 5 0 0 10 0 3 0 300 0 0 0 10 5 2 256 * * *
6fbf5998 ??? F6BVP-9 VE3XPG-9 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * *
1ef30ff2 ??? F6BVP-9 K4GBB-9 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * *
34a12cea ??? F6BVP-9 SV2HRT-9 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * *
0a40cbd9 ??? F6BVP-9 NA7KR-9 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * *
fc1ba6af ??? F6BVP-9 F6BVP-7 0 0 0 0 0 5 0 3 0 300 0 0 0 10 2 2 256 * * *
349f44e1 ??? F6BVP-9 F6BVP-11 0 3 2 2 0 4 0 3 0 300 0 0 0 10 2 2 256 * * *
e41aab46 ??? F6BVP-14 CT1ENI-8 0 0 5 0 0 10 0 3 0 300 0 0 0 10 5 2 256 * * *
e0ece209 ??? F6BVP-9 F6BVP-7 0 3 2 3 0 3 0 3 0 300 0 0 0 10 1 2 256 * * *
3b7d9f0c ??? F6BVP-9 VE3XPG-9 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * *
b7f26df3 ??? F6BVP-9 K4GBB-9 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * *
eb70a53f ??? F6BVP-9 F6KKR-9 0 5 7 5 0 6 0 3 0 300 0 0 0 10 3 2 256 * * *
c08704c9 ??? F6BVP-9 F6CNB-9 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * *
e0389589 ??? F6BVP-9 F3KT-11 0 0 3 0 0 3 0 3 0 300 0 0 0 10 1 2 256 * * *
32d9a149 ??? F6BVP-9 F5KTR-11 0 0 6 0 0 0 0 3 0 300 0 0 0 10 0 2 256 * * *
81b23fa0 ??? F6BVP-9 F6BVP-11 0 4 4 4 0 9 0 3 0 300 0 0 0 10 4 2 256 * * *
630884e1 ??? F6BVP-9 F6CNB-11 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * *
ca370221 ??? F6BVP-9 F6BVP-5 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * *
ba7bc312 ??? F6BVP-9 SV2HRT-9 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * *
c5bad46d ??? F6BVP-9 NA7KR-9 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * *
d9da749f ??? F6BVP-9 F3KT-11 0 6 3 6 0 4 0 3 0 300 0 0 0 10 2 2 256 * * *
18fa6edb ??? F6BVP-14 CT1ENI-8 0 0 5 0 0 10 0 3 0 300 0 0 0 10 5 2 256 * * *
9a6662c2 ??? F6BVP-9 VE3XPG-9 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * *
160cde41 ??? F6BVP-9 K4GBB-9 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * *
29ed5a63 ??? F6BVP-9 SV2HRT-9 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * *
dbbb85f3 ??? F6BVP-9 NA7KR-9 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * *
1b52032c ??? F6BVP-9 F6BVP-11 0 6 6 6 0 6 0 3 0 300 0 0 0 10 3 2 256 * * *
d2e88f83 ??? F6BVP-9 F6BVP-7 0 0 7 0 0 4 0 3 0 300 0 0 0 10 2 2 256 * * *
1261ac60 ??? F6BVP-14 F3KT-12 0 0 1 0 0 10 0 3 0 300 0 0 0 10 5 2 256 * * *
2656b02d ??? F6BVP-9 SV1HCC-9 0 0 2 0 0 10 0 3 0 300 0 0 0 10 5 2 256 * * *
c6c095ab ??? F6BVP-14 CT1ENI-8 0 0 5 0 0 10 0 3 0 300 0 0 0 10 5 2 256 * * *
d7aed580 ??? F6BVP-9 F6BVP-7 0 2 1 2 0 4 0 3 0 300 0 0 0 10 2 2 256 * * *
1464b07c ??? F6BVP-9 VE3XPG-9 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * *
6168a84f ??? F6BVP-9 K4GBB-9 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * *
fd05f264 ??? F6BVP-9 F6KKR-9 0 4 6 4 0 7 0 3 0 300 0 0 0 10 3 2 256 * * *
41e07126 ??? F6BVP-9 F6CNB-9 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * *
b8702c35 ??? F6BVP-9 F3KT-11 0 6 7 6 0 2 0 3 0 300 0 0 0 10 1 2 256 * * *
66c54f7d ??? F6BVP-9 F5KTR-11 0 6 7 6 0 4 0 3 0 300 0 0 0 10 2 2 256 * * *
f016d485 ??? F6BVP-9 F6BVP-11 0 7 6 6 0 7 0 3 0 300 0 0 0 10 3 2 256 * * *
85b42058 ??? F6BVP-9 F6CNB-11 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * *
d4cd2eaa ??? F6BVP-9 F6BVP-5 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * *
7f389c3c ??? F6BVP-9 SV2HRT-9 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * *
0107be95 ??? F6BVP-9 NA7KR-9 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * *
d88d3b3e ??? F6BVP-9 F3KT-11 0 5 2 5 0 4 0 3 0 300 0 0 0 10 2 2 256 * * *
d6dd98e6 ??? F6BVP-14 CT1ENI-8 0 0 5 0 0 10 0 3 0 300 0 0 0 10 5 2 256 * * *
675ad4a5 ??? F6BVP-9 VE3XPG-9 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * *
10508c69 ??? F6BVP-9 K4GBB-9 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * *
3cb64e7f ??? F6BVP-9 SV2HRT-9 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * *
06448390 ??? F6BVP-9 NA7KR-9 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * *
75f99020 ??? F6BVP-9 F6BVP-7 0 0 0 0 0 5 0 3 0 300 0 0 0 10 2 2 256 * * *
b09fa08b ??? F6BVP-9 F6BVP-11 0 2 2 1 0 4 0 3 0 300 0 0 0 10 2 2 256 * * *
91ae7293 ??? F6BVP-9 F3KT-11 0 6 3 6 0 5 0 3 0 300 0 0 0 10 1 2 256 * * *
889bb771 ??? F6BVP-14 CT1ENI-8 0 0 5 0 0 10 0 3 0 300 0 0 0 10 5 2 256 * * *
eb011bee ??? F6BVP-9 VE3XPG-9 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * *
4b1f807e ??? F6BVP-9 K4GBB-9 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * *
6125892f ??? F6BVP-9 SV2HRT-9 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * *
941f47b0 ??? F6BVP-9 NA7KR-9 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * *
ecd2734d ??? F6BVP-9 F6BVP-7 0 7 7 7 0 1 0 3 0 300 0 0 0 10 0 2 256 * * *
52c7dcf8 ??? F6BVP-9 F6BVP-11 0 3 2 2 0 4 0 3 0 300 0 0 0 10 2 2 256 * * *
060f21d8 ??? F6BVP-9 F3KT-11 0 5 2 5 0 4 0 3 0 300 0 0 0 10 2 2 256 * * *
44caff01 ??? F6BVP-14 CT1ENI-8 0 0 5 0 0 10 0 3 0 300 0 0 0 10 5 2 256 * * *
8099c5f8 ??? F6BVP-9 VE3XPG-9 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * *
f359beb8 ??? F6BVP-9 K4GBB-9 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * *
134f8d50 ??? F6BVP-9 SV2HRT-9 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * *
7fe32198 ??? F6BVP-9 NA7KR-9 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * *
1ea2ecbe ??? F6BVP-9 F6BVP-7 0 0 0 0 0 5 0 3 0 300 0 0 0 10 2 2 256 * * *
834fa3d0 ??? F6BVP-9 F6BVP-11 0 2 2 1 0 4 0 3 0 300 0 0 0 10 2 2 256 * * *
34ece46f ??? F6BVP-9 F3KT-11 0 5 2 5 0 4 0 3 0 300 0 0 0 10 2 2 256 * * *
0dfb3266 ??? F6BVP-9 F6KKR-9 0 1 1 1 0 6 0 3 0 300 0 0 0 10 3 2 256 * * *
94c93b07 ??? F6BVP-14 CT1ENI-8 0 0 5 0 0 10 0 3 0 300 0 0 0 10 5 2 256 * * *
432f60fa ??? F6BVP-9 VE3XPG-9 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * *
db00d30e ??? F6BVP-9 K4GBB-9 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * *
2e751dfe ??? F6BVP-9 SV2HRT-9 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * *
db386684 ??? F6BVP-9 NA7KR-9 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * *
bf737dfe ??? F6BVP-9 F6BVP-7 0 3 4 3 0 5 0 3 0 300 0 0 0 10 2 2 256 * * *
836d3f41 ??? F6BVP-9 F6BVP-11 0 3 2 2 0 4 0 3 0 300 0 0 0 10 2 2 256 * * *
6fb25b79 ??? F6BVP-14 CT1ENI-8 0 0 5 0 0 10 0 3 0 300 0 0 0 10 5 2 256 * * *
5357051b ??? F6BVP-9 F6BVP-7 0 2 1 2 0 4 0 3 0 300 0 0 0 10 2 2 256 * * *
ca09254d ??? F6BVP-9 VE3XPG-9 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * *
cb81c016 ??? F6BVP-9 K4GBB-9 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * *
9bb1b538 ??? F6BVP-9 F6KKR-9 0 5 6 5 0 5 0 3 0 300 0 0 0 10 2 2 256 * * *
8b88c1a1 ??? F6BVP-9 F6CNB-9 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * *
0f7dbb2e ??? F6BVP-9 F3KT-11 0 4 0 4 0 3 0 3 0 300 0 0 0 10 1 2 256 * * *
74c6ea65 ??? F6BVP-9 F5KTR-11 0 5 5 5 0 4 0 3 0 300 0 0 0 10 2 2 256 * * *
fa7e1029 ??? F6BVP-9 F6BVP-11 0 7 6 6 0 6 0 3 0 300 0 0 0 10 3 2 256 * * *
20168113 ??? F6BVP-9 F6CNB-11 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * *
8156ed6c ??? F6BVP-9 F6BVP-5 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * *
5d657704 ??? F6BVP-9 SV2HRT-9 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * *
da5c3ca8 ??? F6BVP-9 NA7KR-9 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * *
8e447fe2 ??? F6BVP-14 G1GXB-10 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * *
ee72bea4 ??? F6BVP-14 CT1ENI-8 0 0 6 0 0 10 0 3 0 300 0 0 0 10 5 2 256 * * *
114816ce ??? F6BVP-9 F6BVP-7 0 2 1 2 0 4 0 3 0 300 0 0 0 10 2 2 256 * * *
aca3f37c ??? F6BVP-9 VE3XPG-9 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * *
e02c8339 ??? F6BVP-9 K4GBB-9 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * *
280308c6 ??? F6BVP-9 F6KKR-9 0 5 7 5 0 6 0 3 0 300 0 0 0 10 3 2 256 * * *
55370f0d ??? F6BVP-9 F6CNB-9 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * *
da367dc2 ??? F6BVP-9 F3KT-11 0 5 2 5 0 4 0 3 0 300 0 0 0 10 2 2 256 * * *
ac6f0248 ??? F6BVP-9 F5KTR-11 0 4 5 4 0 4 0 3 0 300 0 0 0 10 2 2 256 * * *
55e140aa ??? F6BVP-9 F6BVP-11 0 7 6 6 0 6 0 3 0 300 0 0 0 10 3 2 256 * * *
b5e7d48c ??? F6BVP-9 F6CNB-11 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * *
e195779f ??? F6BVP-9 F6BVP-5 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * *
91a8f1b1 ??? F6BVP-9 SV2HRT-9 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * *
5c998a3e ??? F6BVP-9 NA7KR-9 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * *
9d9c3799 ??? F6BVP-9 F6CNB-11 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * *
427e912a ??? F6BVP-9 F5KTR-11 0 4 5 4 0 8 0 3 0 300 0 0 0 10 4 2 256 * * *
5885374e ??? F6BVP-9 F3KT-11 0 6 4 6 0 5 0 3 0 300 0 0 0 10 2 2 256 * * *
c7cd8534 ??? F6BVP-14 CT1ENI-8 0 0 5 0 0 10 0 3 0 300 0 0 0 10 5 2 256 * * *
40f74703 ??? F6BVP-9 VE3XPG-9 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * *
effabcd9 ??? F6BVP-9 K4GBB-9 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * *
20fea5d5 ??? F6BVP-9 SV2HRT-9 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * *
59cbd839 ??? F6BVP-9 NA7KR-9 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * *
1a92eda8 ??? F6BVP-9 F6BVP-7 0 0 7 0 0 1 0 3 0 300 0 0 0 10 0 2 256 * * *
3062b2fa ??? F6BVP-9 F6BVP-11 0 3 2 2 0 4 0 3 0 300 0 0 0 10 2 2 256 * * *
d8a3dcfd ??? F6BVP-14 CT1ENI-8 0 0 0 0 0 90 0 3 0 300 0 0 8 10 5 2 256 * * *
658e7e31 ??? F6BVP-9 VE3XPG-9 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * *
222589d0 ??? F6BVP-9 K4GBB-9 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * *
78ceae6f ??? F6BVP-9 F6KKR-9 0 6 4 4 0 77 0 3 0 300 0 0 10 10 3 2 256 * * *
1f46d0f6 ??? F6BVP-9 F6CNB-9 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * *
90ceefe7 ??? F6BVP-9 F3KT-11 0 5 1 3 0 68 0 3 0 300 0 0 10 10 3 2 256 * * *
94b532f7 ??? F6BVP-9 F5KTR-11 0 6 5 4 0 77 0 3 0 300 0 0 10 10 3 2 256 * * *
85e79959 ??? F6BVP-9 F6BVP-11 0 3 4 3 0 6 0 3 0 300 0 0 0 10 3 2 256 * * *
af5671b0 ??? F6BVP-9 F6CNB-11 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * *
e0308fce ??? F6BVP-9 F6BVP-5 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * *
322a8470 ??? F6BVP-9 SV2HRT-9 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * *
3958cc59 ??? F6BVP-9 NA7KR-9 0 0 0 0 0 110 0 3 0 300 0 0 10 10 5 2 256 * * *
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [AX25] unreleased sockets after disconnecting
2022-02-06 21:12 ` [AX25] unreleased sockets after disconnecting Bernard Pidoux , f6bvp
@ 2022-02-20 9:18 ` Thomas Osterried
0 siblings, 0 replies; 24+ messages in thread
From: Thomas Osterried @ 2022-02-20 9:18 UTC (permalink / raw)
To: Bernard Pidoux , f6bvp; +Cc: linux-hams
> Am 06.02.2022 um 22:12 schrieb Bernard Pidoux , f6bvp <f6bvp@free.fr>:
>
> For long time it as been reported by many AX.25 users that connexions were precluded after terminating a connexion with a remote station.
>
> Some hamradio maintainers have been pretending not to be aware of such issue for lacking proofs.
The problem is known. Iirc correctly, we have seen some approaches over the years to fix this issue. The last one I'd like to discuss is by YO2LOJ
(Subject "NET/ROM bug fix from YO2LOJ?" in this list):
That patch is against the problem, that disconnected sessions still are listet, in "LISTENING" state'.
I'm not sure if it is exactly your problem, because in your /proc/net/ax25 example, those sessions seem to belong to iface "???" instead of "ax0".
I can reproduce (testet last week) is the following:
boot
configure ax25 iface
no userspace process started
connect from outside
disconnect from outside
->
netstat --ax25 shows that session in LISTEN state. In contrast to your output, it refers to the interface (not to "???").
The problem with the patch is, we observed a new, in my opinion unliked, behavior:
now a new connection is disconnected instantly (as long as no userspace daemon is listening).
But there are protocols like "IP mode VC" need to be able to connect, even when no userspace daemon is running.
> I must restart my packet radio FPAC node (AX.25, ROSE and NetRom protocoles) every other hour in order to let connexions available again for neighbours.
Perhaps you could try YO2LOJ's kernel patch and test if it helps for your urgent problem, or if there's another problem in the session-cleanup code.
> Here are some evidence from cat /proc/net/ax25 showing old remnants of connexions presumably there for ax25 sockets were not released.
>
> 73 de Bernard, f6bvp
vy 73,
- Thomas dl9sau
^ permalink raw reply [flat|nested] 24+ messages in thread
end of thread, other threads:[~2022-02-20 9:18 UTC | newest]
Thread overview: 24+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <4B2CD772.1030106@upmc.fr>
[not found] ` <4B2D1025.1020106@gmail.com>
[not found] ` <4B2E6729.1090102@free.fr>
[not found] ` <4B507FAA.8010007@free.fr>
2010-01-15 20:36 ` [PATCH net-2.6] ax25: netrom: rose: Fix timer oopses Jarek Poplawski
2010-01-16 9:04 ` David Miller
2011-06-16 20:23 ` [AX25] inconsistent lock state f6bvp
2011-06-17 13:28 ` Ralf Baechle
2011-06-17 13:36 ` Arnd Bergmann
2011-06-17 13:51 ` Ralf Baechle
2011-06-17 14:11 ` Arnd Bergmann
2011-06-17 15:31 ` f6bvp
2011-06-25 15:51 ` f6bvp
2011-06-25 16:39 ` Ralf Baechle DL5RB
2011-07-01 13:00 ` Bernard F6BVP
2011-07-01 21:28 ` [PATCH] 6pack,mkiss: fix lock inconsistency Arnd Bergmann
2011-07-02 0:30 ` David Miller
2012-10-21 15:18 ` [NetRom] possible circular locking dependency detected Bernard f6bvp
2011-06-17 15:26 ` [AX25] inconsistent lock state f6bvp
2011-06-16 20:40 ` f6bvp
2022-01-25 11:46 ` [AX25] ipv6 incompatible with AX.25 Bernard Pidoux
2022-01-25 18:14 ` David Ranch
2022-01-31 12:04 ` [ROSE] rose socket destination address empty in connect tests Bernard Pidoux , f6bvp
[not found] ` <724d87c5-3029-702a-32c9-b64677a2da0e@free.fr>
2022-01-31 17:36 ` [AX25] ipv6 incompatible with AX.25 Bernard Pidoux , f6bvp
2022-02-06 21:12 ` [AX25] unreleased sockets after disconnecting Bernard Pidoux , f6bvp
2022-02-20 9:18 ` Thomas Osterried
2011-07-07 13:31 ` Question with axudp Bernard, f6bvp
2011-07-07 21:43 ` Robert Thoelen
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).