[BUG][AX25] mkiss and ax25_route lockdep warning

[BUG][AX25] mkiss and ax25_route lockdep warning

[Jann Traschewski]

Hello,

After using "Lock debugging: prove locking correctness" with the Kernel I
got this warning:

=================================
[ INFO: inconsistent lock state ]
2.6.24-dg8ngn-p02 #1
---------------------------------
inconsistent {softirq-on-W} -> {in-softirq-R} usage.
linuxnet/3046 [HC0[0]:SC1[2]:HE1:SE0] takes:
 (ax25_route_lock){--.+}, at: [<f8a0cfb7>] ax25_get_route+0x18/0xb7 [ax25]
{softirq-on-W} state was registered at:
  [<c013a340>] __lock_acquire+0x464/0xb7b
  [<c01398d8>] mark_held_locks+0x39/0x53
  [<c0124d35>] local_bh_enable_ip+0xcd/0xd5
  [<c0139aaf>] trace_hardirqs_on+0x11a/0x13d
  [<c013ae58>] lock_acquire+0x5f/0x77
  [<f8a0d381>] ax25_rt_ioctl+0x66/0x325 [ax25]
  [<c0299ce7>] _write_lock+0x29/0x34
  [<f8a0d381>] ax25_rt_ioctl+0x66/0x325 [ax25]
  [<f8a0d381>] ax25_rt_ioctl+0x66/0x325 [ax25]
  [<f8a0f699>] ax25_ioctl+0x1b6/0x5b8 [ax25]
  [<c0161280>] fd_install+0x1e/0x46
  [<c0299c7a>] _spin_lock+0x29/0x34
  [<c022e75d>] sock_ioctl+0x1bb/0x1e0
  [<c022e5a2>] sock_ioctl+0x0/0x1e0
  [<c016c76f>] do_ioctl+0x1f/0x62
  [<c016c9d2>] vfs_ioctl+0x220/0x232
  [<c0139aaf>] trace_hardirqs_on+0x11a/0x13d
  [<c016ca17>] sys_ioctl+0x33/0x4c
  [<c0103ea2>] syscall_call+0x7/0xb
  [<ffffffff>] 0xffffffff
irq event stamp: 120000
hardirqs last  enabled at (120000): [<c0124d35>]
local_bh_enable_ip+0xcd/0xd5
hardirqs last disabled at (119999): [<c0124cc3>]
local_bh_enable_ip+0x5b/0xd5
softirqs last  enabled at (119892): [<f89fd53d>]
mkiss_receive_buf+0x2a5/0x394 [mkiss]
softirqs last disabled at (119893): [<c01249f0>] do_softirq+0x37/0x4d

other info that might help us debug this:
5 locks held by linuxnet/3046:
 #0:  (&tty->atomic_write_lock){--..}, at: [<c01ded5e>]
tty_write_lock+0x11/0x37
 #1:  (rcu_read_lock){..--}, at: [<c023a8d2>] net_rx_action+0x4e/0x1c4
 #2:  (rcu_read_lock){..--}, at: [<c0238579>] netif_receive_skb+0xe6/0x3d6
 #3:  (rcu_read_lock){..--}, at: [<c025549d>]
ip_local_deliver_finish+0x2d/0x1f7
 #4:  (slock-AF_INET){-+..}, at: [<c0274e43>] icmp_send+0x10e/0x37a

stack backtrace:
Pid: 3046, comm: linuxnet Not tainted 2.6.24-dg8ngn-p02 #1
 [<c0138e13>] print_usage_bug+0x138/0x142
 [<c013961f>] mark_lock+0x1ca/0x44a
 [<c013a2d9>] __lock_acquire+0x3fd/0xb7b
 [<c01398d8>] mark_held_locks+0x39/0x53
 [<c0124d35>] local_bh_enable_ip+0xcd/0xd5
 [<c013ae58>] lock_acquire+0x5f/0x77
 [<f8a0cfb7>] ax25_get_route+0x18/0xb7 [ax25]
 [<c0299dc7>] _read_lock+0x29/0x34
 [<f8a0cfb7>] ax25_get_route+0x18/0xb7 [ax25]
 [<f8a0cfb7>] ax25_get_route+0x18/0xb7 [ax25]
 [<f89fda29>] ax_header+0x0/0x1a [mkiss]
 [<f8a0c3f6>] ax25_rebuild_header+0x30/0x202 [ax25]
 [<f89fda29>] ax_header+0x0/0x1a [mkiss]
 [<c023f90c>] neigh_compat_output+0x7b/0x97
 [<c0258bd6>] ip_finish_output+0x1da/0x204
 [<c0259a26>] ip_output+0x74/0x89
 [<c0257831>] ip_push_pending_frames+0x2d8/0x33a
 [<c025742c>] dst_output+0x0/0x7
 [<c0275039>] icmp_send+0x304/0x37a
 [<c013a353>] __lock_acquire+0x477/0xb7b
 [<c0270c05>] __udp4_lib_lookup+0xec/0xf6
 [<c0271a48>] __udp4_lib_rcv+0x586/0x771
 [<c02555ae>] ip_local_deliver_finish+0x13e/0x1f7
 [<c025549d>] ip_local_deliver_finish+0x2d/0x1f7
 [<c0255451>] ip_rcv_finish+0x2c1/0x2e0
 [<c025591c>] ip_rcv+0x1f0/0x22b
 [<c0255190>] ip_rcv_finish+0x0/0x2e0
 [<c0238808>] netif_receive_skb+0x375/0x3d6
 [<c0238579>] netif_receive_skb+0xe6/0x3d6
 [<c023adc4>] process_backlog+0x6c/0xcd
 [<c023a940>] net_rx_action+0xbc/0x1c4
 [<c023a8d2>] net_rx_action+0x4e/0x1c4
 [<c0124944>] __do_softirq+0x69/0xde
 [<f89fd53d>] mkiss_receive_buf+0x2a5/0x394 [mkiss]
 [<c01249f0>] do_softirq+0x37/0x4d
 [<c0124d15>] local_bh_enable_ip+0xad/0xd5
 [<f89fd53d>] mkiss_receive_buf+0x2a5/0x394 [mkiss]
 [<c029a042>] _spin_unlock_irqrestore+0x34/0x39
 [<c01e3233>] pty_write+0x2f/0x39
 [<c01e1233>] write_chan+0x22d/0x2a1
 [<c01191e7>] default_wake_function+0x0/0x8
 [<c01def37>] tty_write+0x14d/0x1c2
 [<c01e1006>] write_chan+0x0/0x2a1
 [<c01dedea>] tty_write+0x0/0x1c2
 [<c0162f28>] vfs_write+0x8a/0x10c
 [<c01634a4>] sys_write+0x41/0x67
 [<c0103ea2>] syscall_call+0x7/0xb
 =======================


--
Jann Traschewski, Drosselstr.1, D-90513 Zirndorf, Germany
Tel.: +49-911-696971, Mobile: +49-170-1045937, EMail: jann@gmx.de
Ham: DG8NGN / DB0VOX, http://www.qsl.net/db0fhn, ICQ UIN: 4130182 

[PATCH][AX25] ax25_route: make ax25_route_lock BH safe

[Jarek Poplawski]

Subject: [AX25] ax25_route: make ax25_route_lock BH safe

> =================================
> [ INFO: inconsistent lock state ]
> 2.6.24-dg8ngn-p02 #1
> ---------------------------------
> inconsistent {softirq-on-W} -> {in-softirq-R} usage.
> linuxnet/3046 [HC0[0]:SC1[2]:HE1:SE0] takes:
>  (ax25_route_lock){--.+}, at: [<f8a0cfb7>] ax25_get_route+0x18/0xb7 [ax25]
> {softirq-on-W} state was registered at:
...

This lockdep report shows that ax25_route_lock is taken for reading in
softirq context, and for writing in process context with BHs enabled.
So, to make this safe, all write_locks in ax25_route.c are changed to
_bh versions.


Reported-by: Jann Traschewski <jann@gmx.de>,
Signed-off-by: Jarek Poplawski <jarkao2@gmail.com>

---

diff -Nurp 2.6.24-mm1-/net/ax25/ax25_route.c 2.6.24-mm1+/net/ax25/ax25_route.c
--- 2.6.24-mm1-/net/ax25/ax25_route.c	2008-02-05 07:45:38.000000000 +0000
+++ 2.6.24-mm1+/net/ax25/ax25_route.c	2008-02-11 11:58:47.000000000 +0000
@@ -45,7 +45,7 @@ void ax25_rt_device_down(struct net_devi
 {
 	ax25_route *s, *t, *ax25_rt;
 
-	write_lock(&ax25_route_lock);
+	write_lock_bh(&ax25_route_lock);
 	ax25_rt = ax25_route_list;
 	while (ax25_rt != NULL) {
 		s       = ax25_rt;
@@ -68,7 +68,7 @@ void ax25_rt_device_down(struct net_devi
 			}
 		}
 	}
-	write_unlock(&ax25_route_lock);
+	write_unlock_bh(&ax25_route_lock);
 }
 
 static int __must_check ax25_rt_add(struct ax25_routes_struct *route)
@@ -82,7 +82,7 @@ static int __must_check ax25_rt_add(stru
 	if (route->digi_count > AX25_MAX_DIGIS)
 		return -EINVAL;
 
-	write_lock(&ax25_route_lock);
+	write_lock_bh(&ax25_route_lock);
 
 	ax25_rt = ax25_route_list;
 	while (ax25_rt != NULL) {
@@ -92,7 +92,7 @@ static int __must_check ax25_rt_add(stru
 			ax25_rt->digipeat = NULL;
 			if (route->digi_count != 0) {
 				if ((ax25_rt->digipeat = kmalloc(sizeof(ax25_digi), GFP_ATOMIC)) == NULL) {
-					write_unlock(&ax25_route_lock);
+					write_unlock_bh(&ax25_route_lock);
 					return -ENOMEM;
 				}
 				ax25_rt->digipeat->lastrepeat = -1;
@@ -102,14 +102,14 @@ static int __must_check ax25_rt_add(stru
 					ax25_rt->digipeat->calls[i]    = route->digi_addr[i];
 				}
 			}
-			write_unlock(&ax25_route_lock);
+			write_unlock_bh(&ax25_route_lock);
 			return 0;
 		}
 		ax25_rt = ax25_rt->next;
 	}
 
 	if ((ax25_rt = kmalloc(sizeof(ax25_route), GFP_ATOMIC)) == NULL) {
-		write_unlock(&ax25_route_lock);
+		write_unlock_bh(&ax25_route_lock);
 		return -ENOMEM;
 	}
 
@@ -120,7 +120,7 @@ static int __must_check ax25_rt_add(stru
 	ax25_rt->ip_mode      = ' ';
 	if (route->digi_count != 0) {
 		if ((ax25_rt->digipeat = kmalloc(sizeof(ax25_digi), GFP_ATOMIC)) == NULL) {
-			write_unlock(&ax25_route_lock);
+			write_unlock_bh(&ax25_route_lock);
 			kfree(ax25_rt);
 			return -ENOMEM;
 		}
@@ -133,7 +133,7 @@ static int __must_check ax25_rt_add(stru
 	}
 	ax25_rt->next   = ax25_route_list;
 	ax25_route_list = ax25_rt;
-	write_unlock(&ax25_route_lock);
+	write_unlock_bh(&ax25_route_lock);
 
 	return 0;
 }
@@ -152,7 +152,7 @@ static int ax25_rt_del(struct ax25_route
 	if ((ax25_dev = ax25_addr_ax25dev(&route->port_addr)) == NULL)
 		return -EINVAL;
 
-	write_lock(&ax25_route_lock);
+	write_lock_bh(&ax25_route_lock);
 
 	ax25_rt = ax25_route_list;
 	while (ax25_rt != NULL) {
@@ -174,7 +174,7 @@ static int ax25_rt_del(struct ax25_route
 			}
 		}
 	}
-	write_unlock(&ax25_route_lock);
+	write_unlock_bh(&ax25_route_lock);
 
 	return 0;
 }
@@ -188,7 +188,7 @@ static int ax25_rt_opt(struct ax25_route
 	if ((ax25_dev = ax25_addr_ax25dev(&rt_option->port_addr)) == NULL)
 		return -EINVAL;
 
-	write_lock(&ax25_route_lock);
+	write_lock_bh(&ax25_route_lock);
 
 	ax25_rt = ax25_route_list;
 	while (ax25_rt != NULL) {
@@ -216,7 +216,7 @@ static int ax25_rt_opt(struct ax25_route
 	}
 
 out:
-	write_unlock(&ax25_route_lock);
+	write_unlock_bh(&ax25_route_lock);
 	return err;
 }
 
@@ -492,7 +492,7 @@ void __exit ax25_rt_free(void)
 {
 	ax25_route *s, *ax25_rt = ax25_route_list;
 
-	write_lock(&ax25_route_lock);
+	write_lock_bh(&ax25_route_lock);
 	while (ax25_rt != NULL) {
 		s       = ax25_rt;
 		ax25_rt = ax25_rt->next;
@@ -500,5 +500,5 @@ void __exit ax25_rt_free(void)
 		kfree(s->digipeat);
 		kfree(s);
 	}
-	write_unlock(&ax25_route_lock);
+	write_unlock_bh(&ax25_route_lock);
 }

Re: [PATCH][AX25] ax25_route: make ax25_route_lock BH safe

[David Miller]

From: Jarek Poplawski <jarkao2@gmail.com>
Date: Mon, 11 Feb 2008 12:42:51 +0000

> [AX25] ax25_route: make ax25_route_lock BH safe
> 
> > =================================
> > [ INFO: inconsistent lock state ]
> > 2.6.24-dg8ngn-p02 #1
> > ---------------------------------
> > inconsistent {softirq-on-W} -> {in-softirq-R} usage.
> > linuxnet/3046 [HC0[0]:SC1[2]:HE1:SE0] takes:
> >  (ax25_route_lock){--.+}, at: [<f8a0cfb7>] ax25_get_route+0x18/0xb7 [ax25]
> > {softirq-on-W} state was registered at:
> ...
> 
> This lockdep report shows that ax25_route_lock is taken for reading in
> softirq context, and for writing in process context with BHs enabled.
> So, to make this safe, all write_locks in ax25_route.c are changed to
> _bh versions.
> 
> 
> Reported-by: Jann Traschewski <jann@gmx.de>,
> Signed-off-by: Jarek Poplawski <jarkao2@gmail.com>

Applied, thanks a lot Jarek.

Re: [PATCH][AX25] ax25_route: make ax25_route_lock BH safe

[Jann Traschewski]

Applied on 2.6.24.2 and up without any problems/warnings since 12 hours.
Thanks,
Jann

> -----Ursprüngliche Nachricht-----
> Von: Jarek Poplawski [mailto:jarkao2@gmail.com] 
> Gesendet: Montag, 11. Februar 2008 13:43
> An: David Miller
> Cc: Jann Traschewski; Bernard Pidoux F6BVP; Ralf Baechle 
> DL5RB; netdev@vger.kernel.org
> Betreff: [PATCH][AX25] ax25_route: make ax25_route_lock BH safe
> 
> 
> Subject: [AX25] ax25_route: make ax25_route_lock BH safe
> 
> > =================================
> > [ INFO: inconsistent lock state ]
> > 2.6.24-dg8ngn-p02 #1
> > ---------------------------------
> > inconsistent {softirq-on-W} -> {in-softirq-R} usage.
> > linuxnet/3046 [HC0[0]:SC1[2]:HE1:SE0] takes:
> >  (ax25_route_lock){--.+}, at: [<f8a0cfb7>] ax25_get_route+0x18/0xb7 
> > [ax25] {softirq-on-W} state was registered at:
> ...
> 
> This lockdep report shows that ax25_route_lock is taken for 
> reading in softirq context, and for writing in process 
> context with BHs enabled.
> So, to make this safe, all write_locks in ax25_route.c are 
> changed to _bh versions.
> 
> 
> Reported-by: Jann Traschewski <jann@gmx.de>,
> Signed-off-by: Jarek Poplawski <jarkao2@gmail.com>
> 
> ---
> 
> diff -Nurp 2.6.24-mm1-/net/ax25/ax25_route.c 
> 2.6.24-mm1+/net/ax25/ax25_route.c
> --- 2.6.24-mm1-/net/ax25/ax25_route.c	2008-02-05 
> 07:45:38.000000000 +0000
> +++ 2.6.24-mm1+/net/ax25/ax25_route.c	2008-02-11 
> 11:58:47.000000000 +0000
> @@ -45,7 +45,7 @@ void ax25_rt_device_down(struct net_devi  {
>  	ax25_route *s, *t, *ax25_rt;
>  
> -	write_lock(&ax25_route_lock);
> +	write_lock_bh(&ax25_route_lock);
>  	ax25_rt = ax25_route_list;
>  	while (ax25_rt != NULL) {
>  		s       = ax25_rt;
> @@ -68,7 +68,7 @@ void ax25_rt_device_down(struct net_devi
>  			}
>  		}
>  	}
> -	write_unlock(&ax25_route_lock);
> +	write_unlock_bh(&ax25_route_lock);
>  }
>  
>  static int __must_check ax25_rt_add(struct 
> ax25_routes_struct *route) @@ -82,7 +82,7 @@ static int 
> __must_check ax25_rt_add(stru
>  	if (route->digi_count > AX25_MAX_DIGIS)
>  		return -EINVAL;
>  
> -	write_lock(&ax25_route_lock);
> +	write_lock_bh(&ax25_route_lock);
>  
>  	ax25_rt = ax25_route_list;
>  	while (ax25_rt != NULL) {
> @@ -92,7 +92,7 @@ static int __must_check ax25_rt_add(stru
>  			ax25_rt->digipeat = NULL;
>  			if (route->digi_count != 0) {
>  				if ((ax25_rt->digipeat = 
> kmalloc(sizeof(ax25_digi), GFP_ATOMIC)) == NULL) {
> -					write_unlock(&ax25_route_lock);
> +					
> write_unlock_bh(&ax25_route_lock);
>  					return -ENOMEM;
>  				}
>  				ax25_rt->digipeat->lastrepeat = 
> -1; @@ -102,14 +102,14 @@ static int __must_check ax25_rt_add(stru
>  					
> ax25_rt->digipeat->calls[i]    = route->digi_addr[i];
>  				}
>  			}
> -			write_unlock(&ax25_route_lock);
> +			write_unlock_bh(&ax25_route_lock);
>  			return 0;
>  		}
>  		ax25_rt = ax25_rt->next;
>  	}
>  
>  	if ((ax25_rt = kmalloc(sizeof(ax25_route), GFP_ATOMIC)) 
> == NULL) {
> -		write_unlock(&ax25_route_lock);
> +		write_unlock_bh(&ax25_route_lock);
>  		return -ENOMEM;
>  	}
>  
> @@ -120,7 +120,7 @@ static int __must_check ax25_rt_add(stru
>  	ax25_rt->ip_mode      = ' ';
>  	if (route->digi_count != 0) {
>  		if ((ax25_rt->digipeat = 
> kmalloc(sizeof(ax25_digi), GFP_ATOMIC)) == NULL) {
> -			write_unlock(&ax25_route_lock);
> +			write_unlock_bh(&ax25_route_lock);
>  			kfree(ax25_rt);
>  			return -ENOMEM;
>  		}
> @@ -133,7 +133,7 @@ static int __must_check ax25_rt_add(stru
>  	}
>  	ax25_rt->next   = ax25_route_list;
>  	ax25_route_list = ax25_rt;
> -	write_unlock(&ax25_route_lock);
> +	write_unlock_bh(&ax25_route_lock);
>  
>  	return 0;
>  }
> @@ -152,7 +152,7 @@ static int ax25_rt_del(struct ax25_route
>  	if ((ax25_dev = ax25_addr_ax25dev(&route->port_addr)) == NULL)
>  		return -EINVAL;
>  
> -	write_lock(&ax25_route_lock);
> +	write_lock_bh(&ax25_route_lock);
>  
>  	ax25_rt = ax25_route_list;
>  	while (ax25_rt != NULL) {
> @@ -174,7 +174,7 @@ static int ax25_rt_del(struct ax25_route
>  			}
>  		}
>  	}
> -	write_unlock(&ax25_route_lock);
> +	write_unlock_bh(&ax25_route_lock);
>  
>  	return 0;
>  }
> @@ -188,7 +188,7 @@ static int ax25_rt_opt(struct ax25_route
>  	if ((ax25_dev = 
> ax25_addr_ax25dev(&rt_option->port_addr)) == NULL)
>  		return -EINVAL;
>  
> -	write_lock(&ax25_route_lock);
> +	write_lock_bh(&ax25_route_lock);
>  
>  	ax25_rt = ax25_route_list;
>  	while (ax25_rt != NULL) {
> @@ -216,7 +216,7 @@ static int ax25_rt_opt(struct ax25_route
>  	}
>  
>  out:
> -	write_unlock(&ax25_route_lock);
> +	write_unlock_bh(&ax25_route_lock);
>  	return err;
>  }
>  
> @@ -492,7 +492,7 @@ void __exit ax25_rt_free(void)  {
>  	ax25_route *s, *ax25_rt = ax25_route_list;
>  
> -	write_lock(&ax25_route_lock);
> +	write_lock_bh(&ax25_route_lock);
>  	while (ax25_rt != NULL) {
>  		s       = ax25_rt;
>  		ax25_rt = ax25_rt->next;
> @@ -500,5 +500,5 @@ void __exit ax25_rt_free(void)
>  		kfree(s->digipeat);
>  		kfree(s);
>  	}
> -	write_unlock(&ax25_route_lock);
> +	write_unlock_bh(&ax25_route_lock);
>  }

Re: [PATCH][AX25] ax25_route: make ax25_route_lock BH safe

[Jarek Poplawski]

On Tue, Feb 12, 2008 at 09:43:26AM +0100, Jann Traschewski wrote:
> Applied on 2.6.24.2 and up without any problems/warnings since 12 hours.
> Thanks,
> Jann

Thanks Jann, too!

BTW, I hope maybe until tomorrow I'll figure out something about those
earlier two AX25 testing patches.

Regards,
Jarek P.

[PATCH][ROSE][NETROM] display neigh instead of address

[Bernard Pidoux F6BVP]

[-- Attachment #1: Type: text/plain, Size: 1187 bytes --]

Hi,

I submit the following patch against kernel 2.6.24.3 to replace
labels "addr" in /proc/net/rose_neigh and /proc/net/nr_neigh
by labels "neigh" for the display of neighbour numbers in the
first columns.

This makes the reading of proc more consistent with the labels of
/proc/net/rose_nodes and /proc/net/nr_nodes.
Finding the callsign of a given node neighbour number becomes easier.

Here are some examples of the new display :


/proc/net/rose_neigh
neigh callsign  dev  count use mode restart  t0  tf digipeaters
00012 F6BVP-7   ax0      2   0  DTE      no   0   0
00011 F6BVP-9   ax0      3   0  DTE      no   0   0

/proc/net/rose_nodes
address    mask n neigh neigh neigh
2080175502 0010 1 00001
2080175520 0010 2 00011 00012



/proc/net/nr_neigh NetRom neigh
neigh callsign  dev  qual lock count failed digipeaters
00013 K4GBB-14  ax0   255    0     1      0
00012 KD4YAL-5  ax0   255    0     2      0

/proc/net/nr_nodes NetRom nodes
callsign  mnemonic w n qual obs neigh qual obs neigh qual obs neigh
VK2AFY-0  AFYNOD   1 1  194   6 00005
F5KCK-13  LNXKCK   1 1  254   4 00003
KD4YAL-4  FBBYAL   1 2  254   6 00012  198   5 00005


73 de Bernard, f6bvp

----------------

[-- Attachment #2: neigh_show_2.6.24.patch --]
[-- Type: text/x-patch, Size: 868 bytes --]

--- a/net/netrom/nr_route.c	2008-01-24 23:58:37.000000000 +0100
+++ b/net/netrom/nr_route.c	2008-02-29 20:29:48.000000000 +0100
@@ -982,7 +982,7 @@ static int nr_neigh_show(struct seq_file
 	int i;
 
 	if (v == SEQ_START_TOKEN)
-		seq_puts(seq, "addr  callsign  dev  qual lock count failed digipeaters\n");
+		seq_puts(seq, "neigh callsign  dev  qual lock count failed digipeaters\n");
 	else {
 		struct nr_neigh *nr_neigh = v;
 
--- a/net/rose/rose_route.c	2008-01-24 23:58:37.000000000 +0100
+++ b/net/rose/rose_route.c	2008-02-29 20:31:35.000000000 +0100
@@ -1178,7 +1178,7 @@ static int rose_neigh_show(struct seq_fi
 
 	if (v == SEQ_START_TOKEN)
 		seq_puts(seq,
-			 "addr  callsign  dev  count use mode restart  t0  tf digipeaters\n");
+			 "neigh callsign  dev  count use mode restart  t0  tf digipeaters\n");
 	else {
 		struct rose_neigh *rose_neigh = v;
 

Re: [PATCH][ROSE][NETROM] display neigh instead of address

[David Miller]

From: Bernard Pidoux F6BVP <f6bvp@free.fr>
Date: Fri, 29 Feb 2008 23:45:03 +0100

> I submit the following patch against kernel 2.6.24.3 to replace
> labels "addr" in /proc/net/rose_neigh and /proc/net/nr_neigh
> by labels "neigh" for the display of neighbour numbers in the
> first columns.
> 
> This makes the reading of proc more consistent with the labels of
> /proc/net/rose_nodes and /proc/net/nr_nodes.
> Finding the callsign of a given node neighbour number becomes easier.

I'm not so sure there is much value to this.
"address", "neigh", it's all about the same.

Yes, it's inconsistent in various areas, but procfs
output is like a fixed API with userspace and we generally
cannot change it without potentially breaking userspace.

Re: [PATCH][ROSE][NETROM] display neigh instead of address

[pidoux]

David Miller a écrit :
> From: Bernard Pidoux F6BVP <f6bvp@free.fr>
> Date: Fri, 29 Feb 2008 23:45:03 +0100
>
>   
>> I submit the following patch against kernel 2.6.24.3 to replace
>> labels "addr" in /proc/net/rose_neigh and /proc/net/nr_neigh
>> by labels "neigh" for the display of neighbour numbers in the
>> first columns.
>>
>> This makes the reading of proc more consistent with the labels of
>> /proc/net/rose_nodes and /proc/net/nr_nodes.
>> Finding the callsign of a given node neighbour number becomes easier.
>>     
>
> I'm not so sure there is much value to this.
> "address", "neigh", it's all about the same.
>
> Yes, it's inconsistent in various areas, but procfs
> output is like a fixed API with userspace and we generally
> cannot change it without potentially breaking userspace.
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>
>   
I thought that the patch would only affect /proc/net/rose and 
/proc/net/netrom, not /proc/net.
However I understand your objection.
Meanwhile application programs can deal with the present labels as far 
as we keep in mind that "addr" and "neigh" are talking about the same thing.
Thanks for the explanation.

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