Netdev List
 help / color / mirror / Atom feed
* Re: [PATCH 2/5] Export the raw sock's security context to proc.
From: Stephen Smalley @ 2011-08-05 13:51 UTC (permalink / raw)
  To: rongqing.li; +Cc: netdev, selinux, lsm
In-Reply-To: <1312534686-4099-3-git-send-email-rongqing.li@windriver.com>

On Fri, 2011-08-05 at 16:58 +0800, rongqing.li@windriver.com wrote:
> From: Roy.Li <rongqing.li@windriver.com>
> 
> The element sk_security of struct sock represents the socket
> security context ID, which is inheriting from the process when
> creates this socket on most of the time.
> 
> but when SELinux type_transition rule is applied to socket, or
> application sets /proc/xxx/attr/createsock, the socket security
> context would be different from the creating process. on this
> condition, the "netstat -Z" will return wrong value, since
> "netstat -Z" only returns the process security context as socket
> process security.
> 
> Export the raw sock's security context to proc, so that "netstat -Z"
> could be fixed by reading procfs.
> 
> Signed-off-by: Roy.Li <rongqing.li@windriver.com>
> ---
>  net/ipv4/raw.c |    9 +++++++--
>  1 files changed, 7 insertions(+), 2 deletions(-)
> 
> diff --git a/net/ipv4/raw.c b/net/ipv4/raw.c
> index 1457acb..645d373 100644
> --- a/net/ipv4/raw.c
> +++ b/net/ipv4/raw.c
> @@ -972,6 +972,7 @@ EXPORT_SYMBOL_GPL(raw_seq_stop);
>  
>  static void raw_sock_seq_show(struct seq_file *seq, struct sock *sp, int i)
>  {
> +	int sclen;
>  	struct inet_sock *inet = inet_sk(sp);
>  	__be32 dest = inet->inet_daddr,
>  	       src = inet->inet_rcv_saddr;
> @@ -979,12 +980,15 @@ static void raw_sock_seq_show(struct seq_file *seq, struct sock *sp, int i)
>  	      srcp  = inet->inet_num;
>  
>  	seq_printf(seq, "%4d: %08X:%04X %08X:%04X"
> -		" %02X %08X:%08X %02X:%08lX %08X %5d %8d %lu %d %pK %d\n",
> +		" %02X %08X:%08X %02X:%08lX %08X %5d %8d %lu %d %pK %d",
>  		i, src, srcp, dest, destp, sp->sk_state,
>  		sk_wmem_alloc_get(sp),
>  		sk_rmem_alloc_get(sp),
>  		0, 0L, 0, sock_i_uid(sp), 0, sock_i_ino(sp),
>  		atomic_read(&sp->sk_refcnt), sp, atomic_read(&sp->sk_drops));
> +
> +	sock_write_secctx(sp, seq, &sclen);

You don't seem to use the return value or the sclen.  If that's
intentional, then why does sclen exist and why isn't the function void?

> +	seq_putc(seq, '\n');
>  }
>  
>  static int raw_seq_show(struct seq_file *seq, void *v)
> @@ -992,7 +996,8 @@ static int raw_seq_show(struct seq_file *seq, void *v)
>  	if (v == SEQ_START_TOKEN)
>  		seq_printf(seq, "  sl  local_address rem_address   st tx_queue "
>  				"rx_queue tr tm->when retrnsmt   uid  timeout "
> -				"inode ref pointer drops\n");
> +				"inode ref pointer drops %s",
> +				(selinux_is_enabled() ? "  scontext\n" : "\n"));

The rest of your code isn't SELinux-specific and should work for other
security modules, so there is no reason to make this SELinux-specific
either.  The audit system may provide a useful example.  I'd just always
include the field header (otherwise how can we add any further fields
unambiguously?), and make it something more general, like "seclabel".

>  	else
>  		raw_sock_seq_show(seq, v, raw_seq_private(seq)->bucket);
>  	return 0;

-- 
Stephen Smalley
National Security Agency


^ permalink raw reply

* Re: return of ip_rt_bug()
From: Tom London @ 2011-08-05 13:37 UTC (permalink / raw)
  To: Julian Anastasov; +Cc: Dave Jones, netdev
In-Reply-To: <CAFiZG+Ve9Y4v9CWCrbGsR+7C79AyoiWncVSVbeqApDuKaPm_jA@mail.gmail.com>

On Fri, Aug 5, 2011 at 6:30 AM, Tom London <selinux@gmail.com> wrote:
> On Fri, Aug 5, 2011 at 6:18 AM, Tom London <selinux@gmail.com> wrote:
>> On Fri, Aug 5, 2011 at 12:56 AM, Julian Anastasov <ja@ssi.bg> wrote:
>>>
>>>        Hello,
>>>
>>> On Thu, 4 Aug 2011, Tom London wrote:
>>>
>>>> So, my router is just giving my wired NIC different addresses....
>>>>
>>>> More I can provide?
>>>
>>>        Thanks! Can you check in dmesg or in another log
>>> about the first IP address in such line:
>>>
>>> printk(KERN_DEBUG "ip_rt_bug: %pI4 -> %pI4, %s\n"
>>>
>>>        Is it now 192.168.2.6 ?
>>>
>>> Regards
>>>
>>> --
>>> Julian Anastasov <ja@ssi.bg>
>>>
>>
>> Sorry, don't see those messages.  I guess I'll have to reboot with
>> 'debug' to see that.
>>
>> Before I do that, I booted this time with the RFKILL switch set to
>> kill the radio (both BT and WIFI), and reran the above tests.
>>
>> Here is what 'ip monitor' said:
>>
>> [root@tlondon ~]# ip monitor
>> 192.168.2.1 dev eth0 lladdr 00:1c:df:e2:3e:e9 STALE
>> 192.168.2.1 dev eth0 lladdr 00:1c:df:e2:3e:e9 REACHABLE
>> 192.168.2.1 dev eth0 lladdr 00:1c:df:e2:3e:e9 STALE
>> 192.168.2.1 dev eth0 lladdr 00:1c:df:e2:3e:e9 STALE
>> ff02::fb via ff02::fb dev eth0  metric 0
>>    cache
>> 192.168.2.1 dev eth0 lladdr 00:1c:df:e2:3e:e9 STALE
>>
>> Here is what 'inotail -f /var/log/messages' said:
>>
>>
>> Aug  5 06:12:21 tlondon kernel: [  536.727187] usb 3-1: new full speed
>> USB device number 2 using uhci_hcd
>> Aug  5 06:12:21 tlondon kernel: [  537.315296] usb 3-1: New USB device
>> found, idVendor=04b8, idProduct=010a
>> Aug  5 06:12:21 tlondon kernel: [  537.315308] usb 3-1: New USB device
>> strings: Mfr=1, Product=2, SerialNumber=0
>> Aug  5 06:12:21 tlondon kernel: [  537.315317] usb 3-1: Product: Perfection1640
>> Aug  5 06:12:21 tlondon kernel: [  537.315323] usb 3-1: Manufacturer: EPSON
>> Aug  5 06:12:21 tlondon mtp-probe: checking bus 3, device 2:
>> "/sys/devices/pci0000:00/0000:00:1a.0/usb3/3-1"
>> Aug  5 06:12:22 tlondon mtp-probe: bus: 3, device: 2 was not an MTP device
>>
>> So, no WARN_ON messages.
>>
>> I'd like to conclude that this is due to UDP casting on the wlan.
>> I'll reboot with the radio on and in debug mode to see what happens.
>>
>> tom
>> --
>> Tom London
>>
>
> Hmmm, first attempt at recreating in debug mode didn't actually
> produce any WARN_ON reports.
>
> 'ip monitor' did say:
>
> [root@tlondon ~]# ip monitor
> 239.255.255.250 dev eth0 lladdr 01:00:5e:7f:ff:fa NOARP
> 3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP>
>    link/ether
> ff02::2 dev wlan0 lladdr 33:33:00:00:00:02 NOARP
> ff02::16 dev wlan0 lladdr 33:33:00:00:00:16 NOARP
> ff02::1:ffac:c692 dev wlan0 lladdr 33:33:ff:ac:c6:92 NOARP
> 192.168.2.1 dev eth0 lladdr 00:1c:df:e2:3e:e9 STALE
> 3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP>
>    link/ether
>
> Will try one more time.
>
> tom
>
> --
> Tom London
>

Can't seem to reproduce this when I boot with 'debug' on the boot line.

Here is what 'ip monitor' says:

[root@tlondon ~]# ip monitor
ff02::1:ffac:c692 dev wlan0 lladdr 33:33:ff:ac:c6:92 NOARP
ff02::16 dev wlan0 lladdr 33:33:00:00:00:16 NOARP
ff02::2 dev wlan0 lladdr 33:33:00:00:00:02 NOARP
3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP>
    link/ether

tom
-- 
Tom London

^ permalink raw reply

* Re: [PATCH 1/5] Define the function to write sock's security context to seq_file.
From: Stephen Smalley @ 2011-08-05 13:32 UTC (permalink / raw)
  To: rongqing.li-CWA4WttNNZF54TAoqtyWWQ
  Cc: netdev-u79uwXL29TY76Z2rM5mHXA, selinux-+05T5uksL2qpZYMLLGbcSA,
	lsm
In-Reply-To: <1312534686-4099-2-git-send-email-rongqing.li-CWA4WttNNZF54TAoqtyWWQ@public.gmane.org>

On Fri, 2011-08-05 at 16:58 +0800, rongqing.li-CWA4WttNNZF54TAoqtyWWQ@public.gmane.org wrote:
> From: Roy.Li <rongqing.li-CWA4WttNNZF54TAoqtyWWQ@public.gmane.org>
> 
> This function will write the sock's security context to a seq_file
> and return the error code, and the number of characters successfully
> written is written in int pointers parameter.
> 
> This function will be called when export socket information to proc.
> 
> Signed-off-by: Roy.Li <rongqing.li-CWA4WttNNZF54TAoqtyWWQ@public.gmane.org>
> ---
>  include/net/sock.h |    1 +
>  net/core/sock.c    |   26 ++++++++++++++++++++++++++
>  2 files changed, 27 insertions(+), 0 deletions(-)
> 

> diff --git a/net/core/sock.c b/net/core/sock.c
> index bc745d0..1126a49 100644
> --- a/net/core/sock.c
> +++ b/net/core/sock.c
> @@ -2254,6 +2254,32 @@ void sk_common_release(struct sock *sk)
>  }
>  EXPORT_SYMBOL(sk_common_release);
>  
> +int sock_write_secctx(struct sock *sk, struct seq_file *seq, int *len)
> +{
> +	struct flowi fl;
> +	char *ctx = NULL;
> +	u32 ctxlen;
> +	int res = 0;
> +
> +	*len = 0;
> +
> +	if (sk == NULL)
> +		return -EINVAL;
> +	res = security_socket_getsockname(sk->sk_socket);
> +	if (res)
> +		return res;
> +
> +	security_sk_classify_flow(sk, &fl);

Rather than using a fake flowi, just define and use
security_sk_getsecid().  There is already a security_ops->sk_getsecid()
hook, so you just need the wrapper function.

> +
> +	res = security_secid_to_secctx(fl.flowi_secid, &ctx, &ctxlen);
> +	if (res)
> +		return res;
> +
> +	seq_printf(seq, " %s%n", ctx, len);
> +	security_release_secctx(ctx, ctxlen);
> +	return res;
> +}
> +
>  static DEFINE_RWLOCK(proto_list_lock);
>  static LIST_HEAD(proto_list);
>  

-- 
Stephen Smalley
National Security Agency

^ permalink raw reply

* Re: return of ip_rt_bug()
From: Tom London @ 2011-08-05 13:30 UTC (permalink / raw)
  To: Julian Anastasov; +Cc: Dave Jones, netdev
In-Reply-To: <CAFiZG+Wmv_FEx2ZX3qZt0tAr-QVQD_javX1gbRWujr9xyf7nbQ@mail.gmail.com>

On Fri, Aug 5, 2011 at 6:18 AM, Tom London <selinux@gmail.com> wrote:
> On Fri, Aug 5, 2011 at 12:56 AM, Julian Anastasov <ja@ssi.bg> wrote:
>>
>>        Hello,
>>
>> On Thu, 4 Aug 2011, Tom London wrote:
>>
>>> So, my router is just giving my wired NIC different addresses....
>>>
>>> More I can provide?
>>
>>        Thanks! Can you check in dmesg or in another log
>> about the first IP address in such line:
>>
>> printk(KERN_DEBUG "ip_rt_bug: %pI4 -> %pI4, %s\n"
>>
>>        Is it now 192.168.2.6 ?
>>
>> Regards
>>
>> --
>> Julian Anastasov <ja@ssi.bg>
>>
>
> Sorry, don't see those messages.  I guess I'll have to reboot with
> 'debug' to see that.
>
> Before I do that, I booted this time with the RFKILL switch set to
> kill the radio (both BT and WIFI), and reran the above tests.
>
> Here is what 'ip monitor' said:
>
> [root@tlondon ~]# ip monitor
> 192.168.2.1 dev eth0 lladdr 00:1c:df:e2:3e:e9 STALE
> 192.168.2.1 dev eth0 lladdr 00:1c:df:e2:3e:e9 REACHABLE
> 192.168.2.1 dev eth0 lladdr 00:1c:df:e2:3e:e9 STALE
> 192.168.2.1 dev eth0 lladdr 00:1c:df:e2:3e:e9 STALE
> ff02::fb via ff02::fb dev eth0  metric 0
>    cache
> 192.168.2.1 dev eth0 lladdr 00:1c:df:e2:3e:e9 STALE
>
> Here is what 'inotail -f /var/log/messages' said:
>
>
> Aug  5 06:12:21 tlondon kernel: [  536.727187] usb 3-1: new full speed
> USB device number 2 using uhci_hcd
> Aug  5 06:12:21 tlondon kernel: [  537.315296] usb 3-1: New USB device
> found, idVendor=04b8, idProduct=010a
> Aug  5 06:12:21 tlondon kernel: [  537.315308] usb 3-1: New USB device
> strings: Mfr=1, Product=2, SerialNumber=0
> Aug  5 06:12:21 tlondon kernel: [  537.315317] usb 3-1: Product: Perfection1640
> Aug  5 06:12:21 tlondon kernel: [  537.315323] usb 3-1: Manufacturer: EPSON
> Aug  5 06:12:21 tlondon mtp-probe: checking bus 3, device 2:
> "/sys/devices/pci0000:00/0000:00:1a.0/usb3/3-1"
> Aug  5 06:12:22 tlondon mtp-probe: bus: 3, device: 2 was not an MTP device
>
> So, no WARN_ON messages.
>
> I'd like to conclude that this is due to UDP casting on the wlan.
> I'll reboot with the radio on and in debug mode to see what happens.
>
> tom
> --
> Tom London
>

Hmmm, first attempt at recreating in debug mode didn't actually
produce any WARN_ON reports.

'ip monitor' did say:

[root@tlondon ~]# ip monitor
239.255.255.250 dev eth0 lladdr 01:00:5e:7f:ff:fa NOARP
3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP>
    link/ether
ff02::2 dev wlan0 lladdr 33:33:00:00:00:02 NOARP
ff02::16 dev wlan0 lladdr 33:33:00:00:00:16 NOARP
ff02::1:ffac:c692 dev wlan0 lladdr 33:33:ff:ac:c6:92 NOARP
192.168.2.1 dev eth0 lladdr 00:1c:df:e2:3e:e9 STALE
3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP>
    link/ether

Will try one more time.

tom

-- 
Tom London

^ permalink raw reply

* Re: return of ip_rt_bug()
From: Tom London @ 2011-08-05 13:18 UTC (permalink / raw)
  To: Julian Anastasov; +Cc: Dave Jones, netdev
In-Reply-To: <alpine.LFD.2.00.1108051048160.1494@ja.ssi.bg>

On Fri, Aug 5, 2011 at 12:56 AM, Julian Anastasov <ja@ssi.bg> wrote:
>
>        Hello,
>
> On Thu, 4 Aug 2011, Tom London wrote:
>
>> So, my router is just giving my wired NIC different addresses....
>>
>> More I can provide?
>
>        Thanks! Can you check in dmesg or in another log
> about the first IP address in such line:
>
> printk(KERN_DEBUG "ip_rt_bug: %pI4 -> %pI4, %s\n"
>
>        Is it now 192.168.2.6 ?
>
> Regards
>
> --
> Julian Anastasov <ja@ssi.bg>
>

Sorry, don't see those messages.  I guess I'll have to reboot with
'debug' to see that.

Before I do that, I booted this time with the RFKILL switch set to
kill the radio (both BT and WIFI), and reran the above tests.

Here is what 'ip monitor' said:

[root@tlondon ~]# ip monitor
192.168.2.1 dev eth0 lladdr 00:1c:df:e2:3e:e9 STALE
192.168.2.1 dev eth0 lladdr 00:1c:df:e2:3e:e9 REACHABLE
192.168.2.1 dev eth0 lladdr 00:1c:df:e2:3e:e9 STALE
192.168.2.1 dev eth0 lladdr 00:1c:df:e2:3e:e9 STALE
ff02::fb via ff02::fb dev eth0  metric 0
    cache
192.168.2.1 dev eth0 lladdr 00:1c:df:e2:3e:e9 STALE

Here is what 'inotail -f /var/log/messages' said:


Aug  5 06:12:21 tlondon kernel: [  536.727187] usb 3-1: new full speed
USB device number 2 using uhci_hcd
Aug  5 06:12:21 tlondon kernel: [  537.315296] usb 3-1: New USB device
found, idVendor=04b8, idProduct=010a
Aug  5 06:12:21 tlondon kernel: [  537.315308] usb 3-1: New USB device
strings: Mfr=1, Product=2, SerialNumber=0
Aug  5 06:12:21 tlondon kernel: [  537.315317] usb 3-1: Product: Perfection1640
Aug  5 06:12:21 tlondon kernel: [  537.315323] usb 3-1: Manufacturer: EPSON
Aug  5 06:12:21 tlondon mtp-probe: checking bus 3, device 2:
"/sys/devices/pci0000:00/0000:00:1a.0/usb3/3-1"
Aug  5 06:12:22 tlondon mtp-probe: bus: 3, device: 2 was not an MTP device

So, no WARN_ON messages.

I'd like to conclude that this is due to UDP casting on the wlan.
I'll reboot with the radio on and in debug mode to see what happens.

tom
-- 
Tom London

^ permalink raw reply

* Re: [Bugme-new] [Bug 39742] New:  3.0.0 (2.6.39.3 also) kernel BUG at include/linux/skbuff.h:1189!
From: Rustam Afanasyev @ 2011-08-05 12:55 UTC (permalink / raw)
  To: Andrew Morton; +Cc: netdev, bugme-daemon, Patrick McHardy
In-Reply-To: <20110722144214.577718f0.akpm@linux-foundation.org>

New kernel, with "gre: fix improper error handling" applied - result 
same. Please Help! Which new git tree you recommend me to testing?
------------------------------------------------
[ 4081.605966] ------------[ cut here ]------------
[ 4081.609919] kernel BUG at include/linux/skbuff.h:1189!
[ 4081.609919] invalid opcode: 0000 [#1] PREEMPT SMP
[ 4081.609919] CPU 1
[ 4081.609919] Modules linked in: cls_fw sch_sfq arc4 ecb ppp_mppe 
act_mirred act_skbedit cls_u32 sch_ingress l2tp_ppp l2t
p_netlink l2tp_core pptp pppox ppp_generic slhc gre 8021q garp stp 
cls_flow sch_htb ifb ipt_NETFLOW xt_mark nf_conntrack_i
pv4 nf_defrag_ipv4 xt_state xt_TCPMSS ipt_LOG xt_recent xt_NOTRACK 
nf_conntrack xt_statistic ts_kmp xt_tcpudp xt_string xt
_multiport xt_set iptable_raw iptable_mangle iptable_filter ip_tables 
x_tables ip_set_hash_ip ip_set_hash_net ip_set nfnet
link dm_multipath scsi_dh dm_mod psmouse sr_mod evdev pcspkr rtc_cmos 
cdrom sg serio_raw i2c_i801 ehci_hcd tg3 uhci_hcd i2
c_core i3000_edac igb usbcore edac_core dca processor button ext3 jbd 
mbcache sd_mod crc_t10dif ide_pci_generic ide_core p
ata_acpi ata_generic ata_piix libata scsi_mod
[ 4081.609919]
[ 4081.609919] Pid: 0, comm: kworker/0:0 Not tainted 3.0.0-un-def-alt2 
#1 ASUS RS100-E4/PI2/P5M2-M/RS100-E4
[ 4081.609919] RIP: 0010:[<ffffffff8136ca2b>]  [<ffffffff8136ca2b>] 
skb_pull+0x2b/0x30
[ 4081.609919] RSP: 0018:ffff88011fc83ab0  EFLAGS: 00010283
[ 4081.609919] RAX: 000000000000057e RBX: ffff88011378db80 RCX: 
0000000000000179
[ 4081.609919] RDX: 0000000000000179 RSI: 0000000000000002 RDI: 
ffff88011378db80
[ 4081.609919] RBP: ffff88011fc83ab0 R08: 0000000000000000 R09: 
0000000000000102
[ 4081.609919] R10: 0000000000000000 R11: 0000000000000001 R12: 
ffff88010d0a8800
[ 4081.609919] R13: ffff88010dc4186e R14: 000000000000002f R15: 
ffffffff8168dd80
[ 4081.609919] FS:  0000000000000000(0000) GS:ffff88011fc80000(0000) 
knlGS:0000000000000000
[ 4081.609919] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[ 4081.609919] CR2: 0000000000fc10fc CR3: 0000000001625000 CR4: 
00000000000006e0
[ 4081.609919] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 
0000000000000000
[ 4081.609919] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 
0000000000000400
[ 4081.609919] Process kworker/0:0 (pid: 0, threadinfo ffff880118f5c000, 
task ffff880118f5a480)
[ 4081.609919] Stack:
[ 4081.609919]  ffff88011fc83ae0 ffffffffa03267fa ffff88011fc83ae0 
ffff88010d0a8800
[ 4081.609919]  ffff88011378db80 ffff88010d0a8850 ffff88011fc83b10 
ffffffff8136bddc
[ 4081.609919]  ffff88011fc83b40 ffff88011378db80 ffff88010d0a8800 
000000008b55000a
[ 4081.609919] Call Trace:
[ 4081.609919]  <IRQ>
[ 4081.609919]  [<ffffffffa03267fa>] pptp_rcv_core+0x21a/0x220 [pptp]
[ 4081.609919]  [<ffffffff8136bddc>] sk_receive_skb+0x13c/0x160
[ 4081.609919]  [<ffffffffa03261be>] pptp_rcv+0x15e/0x1b0 [pptp]
[ 4081.609919]  [<ffffffffa03080e3>] gre_rcv+0x73/0xa0 [gre]
[ 4081.609919]  [<ffffffff813af10d>] ip_local_deliver_finish+0xed/0x2c0
[ 4081.609919]  [<ffffffff813af360>] ip_local_deliver+0x80/0x90
[ 4081.609919]  [<ffffffff813ae959>] ip_rcv_finish+0x119/0x3b0
[ 4081.609919]  [<ffffffff813aef4d>] ip_rcv+0x21d/0x2f0
[ 4081.609919]  [<ffffffff8137cffc>] __netif_receive_skb+0x20c/0x6c0
[ 4081.609919]  [<ffffffff8137dbcd>] netif_receive_skb+0xbd/0xd0
[ 4081.609919]  [<ffffffff8125fcfc>] ? is_swiotlb_buffer+0x3c/0x50
[ 4081.609919]  [<ffffffff8137dd30>] napi_skb_finish+0x50/0x70
[ 4081.609919]  [<ffffffff8137e315>] napi_gro_receive+0xc5/0xd0
[ 4081.609919]  [<ffffffffa01dbe0f>] igb_poll+0x6cf/0xb50 [igb]
[ 4081.609919]  [<ffffffff8137d004>] ? __netif_receive_skb+0x214/0x6c0
[ 4081.609919]  [<ffffffff8137d004>] ? __netif_receive_skb+0x214/0x6c0
[ 4081.609919]  [<ffffffff8137f0d4>] net_rx_action+0x164/0x340
[ 4081.609919]  [<ffffffff810684b5>] __do_softirq+0xd5/0x270
[ 4081.609919]  [<ffffffff8143c89c>] call_softirq+0x1c/0x30
[ 4081.609919]  [<ffffffff8100e6c5>] do_softirq+0x95/0xe0
[ 4081.609919]  [<ffffffff81068305>] irq_exit+0xd5/0xf0
[ 4081.609919]  [<ffffffff8100dec1>] do_IRQ+0x61/0xd0
[ 4081.609919]  [<ffffffff81434753>] common_interrupt+0x13/0x13
[ 4081.609919]  <EOI>
[ 4081.609919]  [<ffffffff8108af60>] ? sched_clock_cpu+0xd0/0x140
[ 4081.609919]  [<ffffffff81015936>] ? mwait_idle+0xe6/0x2b0
[ 4081.609919]  [<ffffffff8101589a>] ? mwait_idle+0x4a/0x2b0
[ 4081.609919]  [<ffffffff8100bb76>] cpu_idle+0x66/0xd0
[ 4081.609919]  [<ffffffff8142c8f9>] start_secondary+0x1bf/0x1c4
[ 4081.609919] Code: 8b 47 68 55 48 89 e5 39 c6 77 1c 29 f0 3b 47 6c 89 
47 68 72 16 89 f0 48 03 87 e0 00 00 00 48 89 87 e0
  00 00 00 c9 c3 31 c0 c9 c3 <0f> 0b eb fe 90 55 39 77 68 48 89 e5 76 1c 
8b 47 6c 85 c0 75 17
[ 4081.609919] RIP  [<ffffffff8136ca2b>] skb_pull+0x2b/0x30
[ 4081.609919]  RSP <ffff88011fc83ab0>
[ 4082.825070] ---[ end trace d6baf8611ae0f359 ]---
[ 4082.838992] Kernel panic - not syncing: Fatal exception in interrupt
[ 4082.858102] Pid: 0, comm: kworker/0:0 Tainted: G      D 
3.0.0-un-def-alt2 #1
[ 4082.881241] Call Trace:
[ 4082.888651]  <IRQ>  [<ffffffff81430b2a>] panic+0x96/0x1bb
[ 4082.904981]  [<ffffffff8143577a>] oops_end+0x10a/0x120
[ 4082.920451]  [<ffffffff8100fbf6>] die+0x56/0x90
[ 4082.934102]  [<ffffffff81434e64>] do_trap+0xc4/0x170
[ 4082.949051]  [<ffffffff8100d801>] do_invalid_op+0xa1/0xb0
[ 4082.965301]  [<ffffffff8136ca2b>] ? skb_pull+0x2b/0x30
[ 4082.980772]  [<ffffffff8106837c>] ? local_bh_enable+0x5c/0xc0
[ 4082.998067]  [<ffffffffa026935a>] ? ipt_do_table+0x22a/0x640 [ip_tables]
[ 4083.018212]  [<ffffffff8143c61b>] invalid_op+0x1b/0x20
[ 4083.033683]  [<ffffffff8136ca2b>] ? skb_pull+0x2b/0x30
[ 4083.049153]  [<ffffffffa03267fa>] pptp_rcv_core+0x21a/0x220 [pptp]
[ 4083.067742]  [<ffffffff8136bddc>] sk_receive_skb+0x13c/0x160
[ 4083.084774]  [<ffffffffa03261be>] pptp_rcv+0x15e/0x1b0 [pptp]
[ 4083.102064]  [<ffffffffa03080e3>] gre_rcv+0x73/0xa0 [gre]
[ 4083.118314]  [<ffffffff813af10d>] ip_local_deliver_finish+0xed/0x2c0
[ 4083.137425]  [<ffffffff813af360>] ip_local_deliver+0x80/0x90
[ 4083.154453]  [<ffffffff813ae959>] ip_rcv_finish+0x119/0x3b0
[ 4083.171223]  [<ffffffff813aef4d>] ip_rcv+0x21d/0x2f0
[ 4083.186174]  [<ffffffff8137cffc>] __netif_receive_skb+0x20c/0x6c0
[ 4083.204504]  [<ffffffff8137dbcd>] netif_receive_skb+0xbd/0xd0
[ 4083.221795]  [<ffffffff8125fcfc>] ? is_swiotlb_buffer+0x3c/0x50
[ 4083.239605]  [<ffffffff8137dd30>] napi_skb_finish+0x50/0x70
[ 4083.256374]  [<ffffffff8137e315>] napi_gro_receive+0xc5/0xd0
[ 4083.273412]  [<ffffffffa01dbe0f>] igb_poll+0x6cf/0xb50 [igb]
[ 4083.290436]  [<ffffffff8137d004>] ? __netif_receive_skb+0x214/0x6c0
[ 4083.309286]  [<ffffffff8137d004>] ? __netif_receive_skb+0x214/0x6c0
[ 4083.328136]  [<ffffffff8137f0d4>] net_rx_action+0x164/0x340
[ 4083.344906]  [<ffffffff810684b5>] __do_softirq+0xd5/0x270
[ 4083.361157]  [<ffffffff8143c89c>] call_softirq+0x1c/0x30
[ 4083.377147]  [<ffffffff8100e6c5>] do_softirq+0x95/0xe0
[ 4083.392618]  [<ffffffff81068305>] irq_exit+0xd5/0xf0
[ 4083.407565]  [<ffffffff8100dec1>] do_IRQ+0x61/0xd0
[ 4083.421998]  [<ffffffff81434753>] common_interrupt+0x13/0x13
[ 4083.439027]  <EOI>  [<ffffffff8108af60>] ? sched_clock_cpu+0xd0/0x140
[ 4083.458477]  [<ffffffff81015936>] ? mwait_idle+0xe6/0x2b0
[ 4083.474725]  [<ffffffff8101589a>] ? mwait_idle+0x4a/0x2b0
[ 4083.490976]  [<ffffffff8100bb76>] cpu_idle+0x66/0xd0
[ 4083.505927]  [<ffffffff8142c8f9>] start_secondary+0x1bf/0x1c4
[ 4083.523225] Rebooting in 30 seconds..
------------------------------------------------


^ permalink raw reply

* Re: [RFC 2/4] [flexcan] Introduce a flexcan_clk set of functions.
From: Robin Holt @ 2011-08-05 12:44 UTC (permalink / raw)
  To: Marc Kleine-Budde
  Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
	netdev-u79uwXL29TY76Z2rM5mHXA, U Bhaskar-B22300,
	Wolfgang Grandegger
In-Reply-To: <4E3BE23A.5080706-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>

On Fri, Aug 05, 2011 at 02:29:46PM +0200, Marc Kleine-Budde wrote:
> On 08/05/2011 01:36 PM, Robin Holt wrote:
> > I implemented the coding style changes below (Sorry I missed the two
> > the first time).
> 
> np :)
> 
> > As for a better implementation, I guess I would need to understand what
> > is being attempted here.  I only marginally understand the flexcan
> > hardware on the Freescale P1010 and certainly am clueless about arm
> > implementations of flexcan.  I just skimmed over freescale's site
> 
> The arm side is working already :)
> However we just support the busclock on ARM [1]. For the first shot
> stick to that clock, too.
> 
> [1] (http://lxr.linux.no/linux+v3.0/drivers/net/can/flexcan.c#L857)
> 
> > and it looks like I would be looking at their i.MX25, i.MX28, i.MX35,
> > and i.MX53 family of processors.  I will attempt to find some useful
> > documentation of those and look at the kernel sources for what the clk_*
> > functions are trying to accomplish.
> > 
> > I _THINK_ I understand.  It looks like I could implement this as a powerpc
> > p1010 specific thing and get the same effect without impacting flexcan.c.
> > I also think I understand that the i.MX25 family of processors do
> > essentially the same thing the p1010 is doing for determining the
> > clock rate.
> 
> It seems that arch/powerpc/platforms/512x/clock.c implements a clock
> interface. I think the p1010 should implement something similar. (Note:
> I'm not a ppc guy :)
> 
> I'm looking forward for new patches.

I agree.  I think I will have that implemented shortly after I get to the
office (about an hour for drive, etc).  I think I am going to implement
a simple match on the dev_id of flexcan.0 or flexcan.1 and otherwise
return failure.

I also looked at implementing the CLOCKDEV_LOOKUP but think that is
going to drive me to drink.

Thanks,
Robin

^ permalink raw reply

* Re: [forcedeth bug] Re: [GIT] Networking
From: Jiri Pirko @ 2011-08-05 12:31 UTC (permalink / raw)
  To: Ingo Molnar; +Cc: David Miller, torvalds, akpm, netdev, linux-kernel
In-Reply-To: <20110805121855.GC13055@elte.hu>

Fri, Aug 05, 2011 at 02:18:55PM CEST, mingo@elte.hu wrote:
>
>* Jiri Pirko <jpirko@redhat.com> wrote:
>
>> >> Is DEV_HAS_VLAN set in id->driver_data (L5344) ?
>> >
>> >How do i tell that without hacking the driver?
>> 
>> look in dmesg for line like:
>> "forcedeth 0000:00:08.0: highdma csum vlan pwrctl mgmt gbit lnktim msi
>> desc-v3"
>> 
>> if "vlan" is there, DEV_HAS_VLAN is set
>
>[    3.534489] forcedeth 0000:00:0a.0: highdma csum gbit lnktim desc-v3
>
>Note, this is a pretty old system with an old nvidia chipset and 
>on-board ethernet:
>
>00:0a.0 Bridge: nVidia Corporation CK804 Ethernet Controller (rev a3)
>        Subsystem: ASUSTeK Computer Inc. K8N4-E Mainboard
>        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
>        Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
>        Latency: 0 (250ns min, 5000ns max)
>        Interrupt: pin A routed to IRQ 11
>        Region 0: Memory at da100000 (32-bit, non-prefetchable) [size=4K]
>        Region 1: I/O ports at d000 [size=8]
>        Capabilities: [44] Power Management version 2
>                Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
>                Status: D0 PME-Enable+ DSel=0 DScale=0 PME-

Please do lspci -nn

There are two CK804 chips:
0x10DE, 0x0056
0x10DE, 0x0057

I have only the second one handy - Getting the machine as we speak.

Jirka

>
>Thanks,
>
>	Ingo

^ permalink raw reply

* [PATCH] Bridge: Always send NETDEV_CHANGEADDR up on br MAC change.
From: Andrei Warkentin @ 2011-08-05  1:55 UTC (permalink / raw)
  To: netdev; +Cc: Andrei Warkentin, Stephen Hemminger
In-Reply-To: <1312509349-23363-1-git-send-email-andreiw@motorola.com>

This ensures the neighbor entries associated with the bridge
dev are flushed, also invalidating the associated cached L2 headers.

This means we br_add_if/br_del_if ports to implement hand-over and
not wind up with bridge packets going out with stale MAC.

This means we can also change MAC of port device and also not wind
up with bridge packets going out with stale MAC.

This builds on Stephen Hemminger's patch, also handling the br_del_if
case, port MAC change case, and bridge MAC manual assignment case.

Change-Id: I6039ba021006f854e0e7e83dd1c4261c500aeab7
Cc: Stephen Hemminger <shemminger@vyatta.com>
Signed-off-by: Andrei Warkentin <andreiw@motorola.com>
---
 net/bridge/br_device.c |    1 +
 net/bridge/br_if.c     |    6 +++++-
 net/bridge/br_notify.c |    2 ++
 net/bridge/br_stp_if.c |    2 +-
 4 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/net/bridge/br_device.c b/net/bridge/br_device.c
index cf09fe5..ef18070 100644
--- a/net/bridge/br_device.c
+++ b/net/bridge/br_device.c
@@ -162,6 +162,7 @@ static int br_set_mac_address(struct net_device *dev, void *p)
 	br->flags |= BR_SET_MAC_ADDR;
 	spin_unlock_bh(&br->lock);
 
+	call_netdevice_notifiers(NETDEV_CHANGEADDR, dev);
 	return 0;
 }
 
diff --git a/net/bridge/br_if.c b/net/bridge/br_if.c
index 204e542..36ad887 100644
--- a/net/bridge/br_if.c
+++ b/net/bridge/br_if.c
@@ -481,6 +481,7 @@ put_back:
 int br_del_if(struct net_bridge *br, struct net_device *dev)
 {
 	struct net_bridge_port *p;
+	bool changed_addr;
 
 	if (!br_port_exists(dev))
 		return -EINVAL;
@@ -492,10 +493,13 @@ int br_del_if(struct net_bridge *br, struct net_device *dev)
 	del_nbp(p);
 
 	spin_lock_bh(&br->lock);
-	br_stp_recalculate_bridge_id(br);
+	changed_addr = br_stp_recalculate_bridge_id(br);
 	br_features_recompute(br);
 	spin_unlock_bh(&br->lock);
 
+	if (changed_addr)
+		call_netdevice_notifiers(NETDEV_CHANGEADDR, br->dev);
+
 	return 0;
 }
 
diff --git a/net/bridge/br_notify.c b/net/bridge/br_notify.c
index 404d4e1..c7160b1 100644
--- a/net/bridge/br_notify.c
+++ b/net/bridge/br_notify.c
@@ -53,6 +53,8 @@ static int br_device_event(struct notifier_block *unused, unsigned long event, v
 		br_fdb_changeaddr(p, dev->dev_addr);
 		br_stp_recalculate_bridge_id(br);
 		spin_unlock_bh(&br->lock);
+
+		call_netdevice_notifiers(NETDEV_CHANGEADDR, br->dev);
 		break;
 
 	case NETDEV_CHANGE:
diff --git a/net/bridge/br_stp_if.c b/net/bridge/br_stp_if.c
index c0990ba..4528e9a 100644
--- a/net/bridge/br_stp_if.c
+++ b/net/bridge/br_stp_if.c
@@ -213,7 +213,7 @@ bool br_stp_recalculate_bridge_id(struct net_bridge *br)
 
 	/* user has chosen a value so keep it */
 	if (br->flags & BR_SET_MAC_ADDR)
-		return;
+		return false;
 
 	list_for_each_entry(p, &br->port_list, list) {
 		if (addr == br_mac_zero ||
-- 
1.7.0.4


^ permalink raw reply related

* Re: [RFC 2/4] [flexcan] Introduce a flexcan_clk set of functions.
From: Marc Kleine-Budde @ 2011-08-05 12:29 UTC (permalink / raw)
  To: Robin Holt
  Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
	netdev-u79uwXL29TY76Z2rM5mHXA, U Bhaskar-B22300,
	Wolfgang Grandegger
In-Reply-To: <20110805113638.GF4926-sJ/iWh9BUns@public.gmane.org>


[-- Attachment #1.1: Type: text/plain, Size: 1710 bytes --]

On 08/05/2011 01:36 PM, Robin Holt wrote:
> I implemented the coding style changes below (Sorry I missed the two
> the first time).

np :)

> As for a better implementation, I guess I would need to understand what
> is being attempted here.  I only marginally understand the flexcan
> hardware on the Freescale P1010 and certainly am clueless about arm
> implementations of flexcan.  I just skimmed over freescale's site

The arm side is working already :)
However we just support the busclock on ARM [1]. For the first shot
stick to that clock, too.

[1] (http://lxr.linux.no/linux+v3.0/drivers/net/can/flexcan.c#L857)

> and it looks like I would be looking at their i.MX25, i.MX28, i.MX35,
> and i.MX53 family of processors.  I will attempt to find some useful
> documentation of those and look at the kernel sources for what the clk_*
> functions are trying to accomplish.
> 
> I _THINK_ I understand.  It looks like I could implement this as a powerpc
> p1010 specific thing and get the same effect without impacting flexcan.c.
> I also think I understand that the i.MX25 family of processors do
> essentially the same thing the p1010 is doing for determining the
> clock rate.

It seems that arch/powerpc/platforms/512x/clock.c implements a clock
interface. I think the p1010 should implement something similar. (Note:
I'm not a ppc guy :)

I'm looking forward for new patches.

cheers, Marc

-- 
Pengutronix e.K.                  | Marc Kleine-Budde           |
Industrial Linux Solutions        | Phone: +49-231-2826-924     |
Vertretung West/Dortmund          | Fax:   +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686  | http://www.pengutronix.de   |


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

[-- Attachment #2: Type: text/plain, Size: 188 bytes --]

_______________________________________________
Socketcan-core mailing list
Socketcan-core-0fE9KPoRgkgATYTw5x5z8w@public.gmane.org
https://lists.berlios.de/mailman/listinfo/socketcan-core

^ permalink raw reply

* Re: [PATCH] ATM: Delete no use FILL_RX_POOLS_IN_BH marco
From: Wang Shaoyan @ 2011-08-05 12:20 UTC (permalink / raw)
  To: netdev
In-Reply-To: <1310130103-4847-1-git-send-email-wangshaoyan.pt@taobao.com>

applied

2011/7/8  <stufever@gmail.com>:
> From: Wang Shaoyan <wangshaoyan.pt@taobao.com>
>
> The macro FILL_RX_POOLS_IN_BH is never been used, in order to avoid
> the compiler reports error because of the usage of function INIT_WORK,
> we just delete the marco.
>
> Cc: Chas Williams <chas@cmf.nrl.navy.mil>
> Cc: linux-atm-general@lists.sourceforge.net
> Signed-off-by: Wang Shaoyan <wangshaoyan.pt@taobao.com>
> ---
>  drivers/atm/ambassador.c |   11 +----------
>  drivers/atm/ambassador.h |    4 ----
>  2 files changed, 1 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/atm/ambassador.c b/drivers/atm/ambassador.c
> index a5fcb1e..bb3b016 100644
> --- a/drivers/atm/ambassador.c
> +++ b/drivers/atm/ambassador.c
> @@ -813,7 +813,7 @@ static void fill_rx_pool (amb_dev * dev, unsigned char pool,
>   return;
>  }
>
> -// top up all RX pools (can also be called as a bottom half)
> +// top up all RX pools
>  static void fill_rx_pools (amb_dev * dev) {
>   unsigned char pool;
>
> @@ -872,11 +872,7 @@ static irqreturn_t interrupt_handler(int irq, void *dev_id) {
>       ++irq_work;
>
>     if (irq_work) {
> -#ifdef FILL_RX_POOLS_IN_BH
> -      schedule_work (&dev->bh);
> -#else
>       fill_rx_pools (dev);
> -#endif
>
>       PRINTD (DBG_IRQ, "work done: %u", irq_work);
>     } else {
> @@ -2154,11 +2150,6 @@ static void setup_dev(amb_dev *dev, struct pci_dev *pci_dev)
>       dev->tx_avail = ATM_OC3_PCR;
>       dev->rx_avail = ATM_OC3_PCR;
>
> -#ifdef FILL_RX_POOLS_IN_BH
> -      // initialise bottom half
> -      INIT_WORK(&dev->bh, (void (*)(void *)) fill_rx_pools, dev);
> -#endif
> -
>       // semaphore for txer/rxer modifications - we cannot use a
>       // spinlock as the critical region needs to switch processes
>       mutex_init(&dev->vcc_sf);
> diff --git a/drivers/atm/ambassador.h b/drivers/atm/ambassador.h
> index bd1c46a..aa97105 100644
> --- a/drivers/atm/ambassador.h
> +++ b/drivers/atm/ambassador.h
> @@ -630,10 +630,6 @@ struct amb_dev {
>   u32              iobase;
>   u32 *            membase;
>
> -#ifdef FILL_RX_POOLS_IN_BH
> -  struct work_struct bh;
> -#endif
> -
>   amb_cq           cq;
>   amb_txq          txq;
>   amb_rxq          rxq[NUM_RX_POOLS];
> --
> 1.7.4.1
>
>



-- 
Wang Shaoyan

^ permalink raw reply

* Re: [forcedeth bug] Re: [GIT] Networking
From: Ingo Molnar @ 2011-08-05 12:18 UTC (permalink / raw)
  To: Jiri Pirko; +Cc: David Miller, torvalds, akpm, netdev, linux-kernel
In-Reply-To: <20110805112557.GD1928@minipsycho.orion>


* Jiri Pirko <jpirko@redhat.com> wrote:

> >> Is DEV_HAS_VLAN set in id->driver_data (L5344) ?
> >
> >How do i tell that without hacking the driver?
> 
> look in dmesg for line like:
> "forcedeth 0000:00:08.0: highdma csum vlan pwrctl mgmt gbit lnktim msi
> desc-v3"
> 
> if "vlan" is there, DEV_HAS_VLAN is set

[    3.534489] forcedeth 0000:00:0a.0: highdma csum gbit lnktim desc-v3

Note, this is a pretty old system with an old nvidia chipset and 
on-board ethernet:

00:0a.0 Bridge: nVidia Corporation CK804 Ethernet Controller (rev a3)
        Subsystem: ASUSTeK Computer Inc. K8N4-E Mainboard
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
        Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Latency: 0 (250ns min, 5000ns max)
        Interrupt: pin A routed to IRQ 11
        Region 0: Memory at da100000 (32-bit, non-prefetchable) [size=4K]
        Region 1: I/O ports at d000 [size=8]
        Capabilities: [44] Power Management version 2
                Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
                Status: D0 PME-Enable+ DSel=0 DScale=0 PME-

Thanks,

	Ingo

^ permalink raw reply

* RE: [PATCHv2 NEXT 1/1] netxen: add vlan accel support
From: Amit Salecha @ 2011-08-05 12:13 UTC (permalink / raw)
  To: David Miller; +Cc: netdev, Ameen Rahman, Rajesh Borundia
In-Reply-To: <20110805.042755.2121843538632981106.davem@davemloft.net>

> From: David Miller [mailto:davem@davemloft.net]
> Sent: Friday, August 05, 2011 4:58 PM
> 
> From: Amit Salecha <amit.salecha@qlogic.com>
> Date: Fri, 5 Aug 2011 06:04:10 -0500
> 
> > This is true, but problem is after fw recovery. So flow is
> > 1) vlan device added
> > 2) Driver program ip address of vlan device (through inet events)
> > 3) Fw recovery
> > 4) After fw recovery driver need to program ip addresses again which
> were already programmed.
> >    After fw recovery there won't be any inet/netdev event.
> >
> > Simple solution is to maintain those ip addresses in driver.
> 
> When you program the device, in response to inet events, maintain a
> software list in the driver that remembers the IP address state.
> 
> Then on FW recovery, walk the special list to reprogram the device.

Make sense. Will repost patch with above logic
-Thanks.


^ permalink raw reply

* Re: [forcedeth bug] Re: [GIT] Networking
From: Jiri Pirko @ 2011-08-05 11:44 UTC (permalink / raw)
  To: Neil Horman
  Cc: Ingo Molnar, David Miller, torvalds, akpm, netdev, linux-kernel
In-Reply-To: <20110805111231.GA29466@hmsreliant.think-freely.org>

Fri, Aug 05, 2011 at 01:12:31PM CEST, nhorman@tuxdriver.com wrote:
>On Fri, Aug 05, 2011 at 12:29:03PM +0200, Ingo Molnar wrote:
>> 
>> * Jiri Pirko <jpirko@redhat.com> wrote:
>> 
>> > Thu, Aug 04, 2011 at 11:53:54PM CEST, mingo@elte.hu wrote:
>> > >
>> > >* Ingo Molnar <mingo@elte.hu> wrote:
>> > >
>> > >>  0891b0e08937: forcedeth: fix vlans
>> > >
>> > >Hm, forcedeth is still giving me trouble even on latest -git that has 
>> > >the above fix included.
>> > >
>> > >The symptom is a stuck interface, no packets in. There's a frame 
>> > >error RX packet:
>> > >
>> > > [root@mercury ~]# ifconfig eth0
>> > > eth0      Link encap:Ethernet  HWaddr 00:13:D4:DC:41:12  
>> > >           inet addr:10.0.1.13  Bcast:10.0.1.255  Mask:255.255.255.0
>> > >           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>> > >           RX packets:0 errors:1 dropped:0 overruns:0 frame:1
>> > >           TX packets:531 errors:0 dropped:0 overruns:0 carrier:0
>> > >           collisions:0 txqueuelen:1000 
>> > >           RX bytes:0 (0.0 b)  TX bytes:34112 (33.3 KiB)
>> > >           Interrupt:35 
>> > >
>> > >Weirdly enough a defconfig x86 bootup works just fine - it's certain 
>> > >.config combinations that trigger the bug. I've attached such a 
>> > >config.
>> > >
>> > >Note that at least once i've observed a seemingly good kernel going 
>> > >'bad' after a couple of minutes uptime. I've also observed 
>> > >intermittent behavior - apparent lost packets and a laggy network.
>> > >
>> > >I have done 3 failed attempts to bisect it any further - i got to the 
>> > >commit that got fixed by:
>> > >
>> > >  0891b0e08937: forcedeth: fix vlans
>> > >
>> > >... but that's something we already knew.
>> > >
>> > >Let me know if there's any data i can provide to help debug this 
>> > >problem.
>> > >
>> > >Thanks,
>> > >
>> > >	Ingo
>> > 
>> > Interesting.
>> > 
>> > Is DEV_HAS_VLAN set in id->driver_data (L5344) ?
>> 
>Looks like you can match it to pci id.  Device ids 0x0372 and 0x0373 look to
>have the flag set
>
>> How do i tell that without hacking the driver?
>> 
>> > If so, would you try to disable both rx an tx vlan accel using 
>> > ethtool and see if it helps?
>> 
>> Should i do that when the device is in a stuck state and see whether 
>> it recovers?
>> 
>> Also, please provide the exact ethtool command sequences i should 
>> try, this makes it easier for me to test exactly what you want me to 
>> test.
>> 
>should be:
>ethtool -K ethX rxvlan off txvlan off
>
>I'm just poking about, but If I had to guess it looks like the card you have
>ingo is an older forcedeth and uses the older format ring descriptor (I base
>this on the fact that the rx error count noted above only gets incremented ni
>nv_rx_process, but not nv_rx_process_optimized.  Both paths should support hw
>vlan acceleration though and Jiris fixes for vlan hw rx acceleration were only
>applied to the optimized path.

Well hw accel was not implemented in nv_rx_process before so I did not
see any reason to do so during vlan conversion. Anyway, since this path
was touched, I do not see reason why regression might happen there. Only
change is that now hw accel is enabled by default (before, it got
enabled only when vid was added). So if turning off hw accel fixes the
problem for Ingo, I would tend fix this by simply disabling vlan hw
accel for non-optimized path, by patch like this:

diff --git a/drivers/net/forcedeth.c b/drivers/net/forcedeth.c
index e55df30..3f1b24b 100644
--- a/drivers/net/forcedeth.c
+++ b/drivers/net/forcedeth.c
@@ -5341,7 +5341,7 @@ static int __devinit nv_probe(struct pci_dev *pci_dev, const struct pci_device_i
 	}
 
 	np->vlanctl_bits = 0;
-	if (id->driver_data & DEV_HAS_VLAN) {
+	if (id->driver_data & DEV_HAS_VLAN && nv_optimized(np)) {
 		np->vlanctl_bits = NVREG_VLANCONTROL_ENABLE;
 		dev->hw_features |= NETIF_F_HW_VLAN_RX | NETIF_F_HW_VLAN_TX;
 	}

Strange kind of hw this is ....

>
>Neil
>
>> Thanks,
>> 
>> 	Ingo
>> --
>> 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
>> 

^ permalink raw reply related

* Re: [RFC 2/4] [flexcan] Introduce a flexcan_clk set of functions.
From: Robin Holt @ 2011-08-05 11:36 UTC (permalink / raw)
  To: Marc Kleine-Budde; +Cc: Robin Holt, Wolfgang Grandegger, socketcan-core, netdev
In-Reply-To: <4E3BAB03.4040803@pengutronix.de>

I implemented the coding style changes below (Sorry I missed the two
the first time).

As for a better implementation, I guess I would need to understand what
is being attempted here.  I only marginally understand the flexcan
hardware on the Freescale P1010 and certainly am clueless about arm
implementations of flexcan.  I just skimmed over freescale's site
and it looks like I would be looking at their i.MX25, i.MX28, i.MX35,
and i.MX53 family of processors.  I will attempt to find some useful
documentation of those and look at the kernel sources for what the clk_*
functions are trying to accomplish.

I _THINK_ I understand.  It looks like I could implement this as a powerpc
p1010 specific thing and get the same effect without impacting flexcan.c.
I also think I understand that the i.MX25 family of processors do
essentially the same thing the p1010 is doing for determining the
clock rate.

Thanks,
Robin

On Fri, Aug 05, 2011 at 10:34:11AM +0200, Marc Kleine-Budde wrote:
> On 08/05/2011 04:06 AM, Robin Holt wrote:
> > The freescale P1010RDB board does not have a
> > clk_{get,put,get_rate,enable,disable} set of functions.  Wrap these with a
> > flexcan_ #define for arm, and implement a more complete function for ppc.
> 
> Some codingstyle nitpicks inline. I hope we'll find a cleaner solution
> than this patch.
> 
> Marc
> 
> > Signed-off-by: Robin Holt <holt@sgi.com>
> > To: Marc Kleine-Budde <mkl@pengutronix.de>
> > To: Wolfgang Grandegger <wg@grandegger.com>
> > Cc: socketcan-core@lists.berlios.de
> > Cc: netdev@vger.kernel.org
> > ---
> >  drivers/net/can/flexcan.c |  114 +++++++++++++++++++++++++++++++++++++++++----
> >  1 files changed, 105 insertions(+), 9 deletions(-)
> > 
> > diff --git a/drivers/net/can/flexcan.c b/drivers/net/can/flexcan.c
> > index 74b1706..3417d0b 100644
> > --- a/drivers/net/can/flexcan.c
> > +++ b/drivers/net/can/flexcan.c
> > @@ -220,6 +220,102 @@ static inline void flexcan_write(u32 val, void __iomem *addr)
> >  }
> >  #endif
> >  
> > +#if defined(__powerpc__)
> > +struct flexcan_clk {
> > +	unsigned long rate;
> > +	void *data;
> > +};
> > +
> > +static struct clk *flexcan_clk_get(struct device *dev, const char *id)
> > +{
> > +	struct flexcan_clk *clock;
> > +	u32 *clock_freq;
> > +	u32 *clock_divider;
> > +	int err;
> > +
> > +	clock = kmalloc(sizeof(struct flexcan_clk), GFP_KERNEL);
> > +	if (!clock) {
> > +		dev_err(dev, "Cannot allocate memory\n");
> > +		err = -ENOMEM;
> > +		goto failed_clock;
> > +	}
> > +	clock_freq = (u32 *)of_get_property(dev->of_node, "clock_freq", NULL);
> > +	if (!clock_freq) {
> > +		dev_err(dev, "Cannot find clock_freq property\n");
> > +		err = -EINVAL;
> > +		goto failed_clock;
> > +	}
> > +
> > +	clock_divider = (u32 *) of_get_property(dev->of_node,
>                                ^
> 
> remove this space, please
> > +					"fsl,flexcan-clock-divider", NULL);
> > +	if (clock_divider == NULL) {
> 
> !clock_divider
> 
> > +		dev_err(dev, "Cannot find fsl,flexcan-clock-divider property\n");
> > +		err = -EINVAL;
> > +		goto failed_clock;
> > +	}
> > +
> > +	clock->rate = DIV_ROUND_CLOSEST(*clock_freq / *clock_divider, 1000);
> > +	clock->rate *= 1000;
> > +
> > +	return (struct clk *)clock;
> > +
> > + failed_clock:
> > +	kfree(clock);
> > +	return ERR_PTR(err);
> > +}
> > +
> > +static inline void flexcan_clk_put(struct clk *_clk)
> > +{
> > +	struct flexcan_clk *clk = (struct flexcan_clk *)_clk;
> 
> that cast is not needed.
> 
> > +
> > +	kfree(clk);
> > +}
> > +
> > +static inline int flexcan_clk_enable(struct clk *clk)
> > +{
> > +	return 0;
> > +}
> > +
> > +static inline void flexcan_clk_disable(struct clk *clk)
> > +{
> > +	return;
> > +}
> > +
> > +static inline unsigned long flexcan_clk_get_rate(struct clk *_clk)
> > +{
> > +	struct flexcan_clk *clk = (struct flexcan_clk *)_clk;
> > +
> > +	return clk->rate;
> > +}
> > +
> > +#else
> > +static inline struct clk *flexcan_clk_get(struct device *dev, const char *id)
> > +{
> > +	return clk_get(dev, id);
> > +}
> > +
> > +static inline void flexcan_clk_put(struct clk *clk)
> > +{
> > +	clk_put(clk);
> > +}
> > +
> > +static inline int flexcan_clk_enable(struct clk *clk)
> > +{
> > +	return clk_enable(clk);
> > +}
> > +
> > +static inline void flexcan_clk_disable(struct clk *clk)
> > +{
> > +	clk_disable(clk);
> > +}
> > +
> > +static inline unsigned long flexcan_clk_get_rate(struct clk *clk)
> > +{
> > +	return clk_get_rate(clk);
> > +}
> > +
> > +#endif
> > +
> >  /*
> >   * Swtich transceiver on or off
> >   */
> > @@ -807,7 +903,7 @@ static int flexcan_open(struct net_device *dev)
> >  	struct flexcan_priv *priv = netdev_priv(dev);
> >  	int err;
> >  
> > -	clk_enable(priv->clk);
> > +	flexcan_clk_enable(priv->clk);
> >  
> >  	err = open_candev(dev);
> >  	if (err)
> > @@ -829,7 +925,7 @@ static int flexcan_open(struct net_device *dev)
> >   out_close:
> >  	close_candev(dev);
> >   out:
> > -	clk_disable(priv->clk);
> > +	flexcan_clk_disable(priv->clk);
> >  
> >  	return err;
> >  }
> > @@ -843,7 +939,7 @@ static int flexcan_close(struct net_device *dev)
> >  	flexcan_chip_stop(dev);
> >  
> >  	free_irq(dev->irq, dev);
> > -	clk_disable(priv->clk);
> > +	flexcan_clk_disable(priv->clk);
> >  
> >  	close_candev(dev);
> >  
> > @@ -882,7 +978,7 @@ static int __devinit register_flexcandev(struct net_device *dev)
> >  	struct flexcan_regs __iomem *regs = priv->base;
> >  	u32 reg, err;
> >  
> > -	clk_enable(priv->clk);
> > +	flexcan_clk_enable(priv->clk);
> >  
> >  	/* select "bus clock", chip must be disabled */
> >  	flexcan_chip_disable(priv);
> > @@ -916,7 +1012,7 @@ static int __devinit register_flexcandev(struct net_device *dev)
> >   out:
> >  	/* disable core and turn off clocks */
> >  	flexcan_chip_disable(priv);
> > -	clk_disable(priv->clk);
> > +	flexcan_clk_disable(priv->clk);
> >  
> >  	return err;
> >  }
> > @@ -936,7 +1032,7 @@ static int __devinit flexcan_probe(struct platform_device *pdev)
> >  	resource_size_t mem_size;
> >  	int err, irq;
> >  
> > -	clk = clk_get(&pdev->dev, NULL);
> > +	clk = flexcan_clk_get(&pdev->dev, NULL);
> >  	if (IS_ERR(clk)) {
> >  		dev_err(&pdev->dev, "no clock defined\n");
> >  		err = PTR_ERR(clk);
> > @@ -973,7 +1069,7 @@ static int __devinit flexcan_probe(struct platform_device *pdev)
> >  	dev->flags |= IFF_ECHO; /* we support local echo in hardware */
> >  
> >  	priv = netdev_priv(dev);
> > -	priv->can.clock.freq = clk_get_rate(clk);
> > +	priv->can.clock.freq = flexcan_clk_get_rate(clk);
> >  	priv->can.bittiming_const = &flexcan_bittiming_const;
> >  	priv->can.do_set_mode = flexcan_set_mode;
> >  	priv->can.do_get_berr_counter = flexcan_get_berr_counter;
> > @@ -1008,7 +1104,7 @@ static int __devinit flexcan_probe(struct platform_device *pdev)
> >   failed_map:
> >  	release_mem_region(mem->start, mem_size);
> >   failed_get:
> > -	clk_put(clk);
> > +	flexcan_clk_put(clk);
> >   failed_clock:
> >  	return err;
> >  }
> > @@ -1026,7 +1122,7 @@ static int __devexit flexcan_remove(struct platform_device *pdev)
> >  	mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> >  	release_mem_region(mem->start, resource_size(mem));
> >  
> > -	clk_put(priv->clk);
> > +	flexcan_clk_put(priv->clk);
> >  
> >  	free_candev(dev);
> >  
> 
> 
> -- 
> Pengutronix e.K.                  | Marc Kleine-Budde           |
> Industrial Linux Solutions        | Phone: +49-231-2826-924     |
> Vertretung West/Dortmund          | Fax:   +49-5121-206917-5555 |
> Amtsgericht Hildesheim, HRA 2686  | http://www.pengutronix.de   |
> 



^ permalink raw reply

* Re: [PATCHv2 NEXT 1/1] netxen: add vlan accel support
From: David Miller @ 2011-08-05 11:27 UTC (permalink / raw)
  To: amit.salecha; +Cc: netdev, ameen.rahman, rajesh.borundia
In-Reply-To: <99737F4847ED0A48AECC9F4A1974A4B80FE464EF99@MNEXMB2.qlogic.org>

From: Amit Salecha <amit.salecha@qlogic.com>
Date: Fri, 5 Aug 2011 06:04:10 -0500

> This is true, but problem is after fw recovery. So flow is 
> 1) vlan device added
> 2) Driver program ip address of vlan device (through inet events)
> 3) Fw recovery
> 4) After fw recovery driver need to program ip addresses again which were already programmed.
>    After fw recovery there won't be any inet/netdev event.
> 
> Simple solution is to maintain those ip addresses in driver.

When you program the device, in response to inet events, maintain a
software list in the driver that remembers the IP address state.

Then on FW recovery, walk the special list to reprogram the device.

^ permalink raw reply

* Re: [forcedeth bug] Re: [GIT] Networking
From: Jiri Pirko @ 2011-08-05 11:25 UTC (permalink / raw)
  To: Ingo Molnar; +Cc: David Miller, torvalds, akpm, netdev, linux-kernel
In-Reply-To: <20110805102903.GF2420@elte.hu>

Fri, Aug 05, 2011 at 12:29:03PM CEST, mingo@elte.hu wrote:
>
>* Jiri Pirko <jpirko@redhat.com> wrote:
>
>> Thu, Aug 04, 2011 at 11:53:54PM CEST, mingo@elte.hu wrote:
>> >
>> >* Ingo Molnar <mingo@elte.hu> wrote:
>> >
>> >>  0891b0e08937: forcedeth: fix vlans
>> >
>> >Hm, forcedeth is still giving me trouble even on latest -git that has 
>> >the above fix included.
>> >
>> >The symptom is a stuck interface, no packets in. There's a frame 
>> >error RX packet:
>> >
>> > [root@mercury ~]# ifconfig eth0
>> > eth0      Link encap:Ethernet  HWaddr 00:13:D4:DC:41:12  
>> >           inet addr:10.0.1.13  Bcast:10.0.1.255  Mask:255.255.255.0
>> >           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>> >           RX packets:0 errors:1 dropped:0 overruns:0 frame:1
>> >           TX packets:531 errors:0 dropped:0 overruns:0 carrier:0
>> >           collisions:0 txqueuelen:1000 
>> >           RX bytes:0 (0.0 b)  TX bytes:34112 (33.3 KiB)
>> >           Interrupt:35 
>> >
>> >Weirdly enough a defconfig x86 bootup works just fine - it's certain 
>> >.config combinations that trigger the bug. I've attached such a 
>> >config.
>> >
>> >Note that at least once i've observed a seemingly good kernel going 
>> >'bad' after a couple of minutes uptime. I've also observed 
>> >intermittent behavior - apparent lost packets and a laggy network.
>> >
>> >I have done 3 failed attempts to bisect it any further - i got to the 
>> >commit that got fixed by:
>> >
>> >  0891b0e08937: forcedeth: fix vlans
>> >
>> >... but that's something we already knew.
>> >
>> >Let me know if there's any data i can provide to help debug this 
>> >problem.
>> >
>> >Thanks,
>> >
>> >	Ingo
>> 
>> Interesting.
>> 
>> Is DEV_HAS_VLAN set in id->driver_data (L5344) ?
>
>How do i tell that without hacking the driver?

look in dmesg for line like:
"forcedeth 0000:00:08.0: highdma csum vlan pwrctl mgmt gbit lnktim msi
desc-v3"

if "vlan" is there, DEV_HAS_VLAN is set

>
>> If so, would you try to disable both rx an tx vlan accel using 
>> ethtool and see if it helps?
>
>Should i do that when the device is in a stuck state and see whether 
>it recovers?

Yes.

>
>Also, please provide the exact ethtool command sequences i should 
>try, this makes it easier for me to test exactly what you want me to 
>test.

ethtool -K eth0 txvlan off rxvlan off


>
>Thanks,
>
>	Ingo

^ permalink raw reply

* [GIT] Networking
From: David Miller @ 2011-08-05 11:20 UTC (permalink / raw)
  To: torvalds; +Cc: akpm, netdev, linux-kernel


The only serious regression that I know of which is still
pending is that forcedeth issue Ingo reported and I'm hoping
Jiri can resolve that quickly, otherwise we'll revert all the
VLAN changes as per Ingo's revert patch.

1) Fix sendmmsg() regressions, particularly wrt. certain LSMs which
   need to validate the sockaddr of every sendmsg call.  From
   Tetsuo Handa and Anton Blanchard.

2) Fix truncard ATM packets over br2864, from Chas Williams.

3) sfq_enqueue() corrupts queue state due to missing checks and
   call to qdisc_tree_decrease_qlen(), from Eric Dumazet.

4) Paul Moore contact info update.

5) Fix accidental TX restart during NIC unload in bnx2x driver, from
   Vladislav Zolotarov.

6) Fix setting MAC address on 8168e-vl chips, from Francois
   Romieu.

7) dst->neighbour accesses need RCU handling now, since these days
   we can change it on a live object, fix from Eric Dumazet.

8) Two MLX4 bug fixes from Yevgeny Petrilin based upon reports by
   Roland Dreier.

9) Fix lost "wrap" bit in TX ring of macb driver during TX underrun
   recovery, from Tord Andersson.

10) Fix endianness problems in cdc_ncm driver, from Giuseppe Scrivano.

11) IPV4 multicast code uses wrong variable to index array, from Julia
    Lawall.

12) Similar array indexing problem in NIU driver, also from Julia Lawall.

13) Fix sunrpc kerneldoc warning, from Randy Dunlap.

14) Fix ->real_parent access race in proc connector, from Oleg Nesterov.

15) Add device ID for DLINK 530T rev C1 to R8169 driver, from Lennart
    Sorensen.

16) sis190 needs private ->ndo_set_mac_address handler so it can update
    it's RX filter properly.  From Klement Fish.

17) Fix key lengths for rfc3686(ctr(aes)) IPSEC algorithm entry, from
    Tushar Gohad.

18) IPVS needs to unregister notifier on module unload, from Hans
    Schillstrom and Simon Horman.

19) Fix off-by-one in nl80211_trigger_scan(), from Dan Carpenter.

20) Fix rtlwifi OOPS on ARM, from Larry Finger.

21) Fix accidental bzero() of 'skb' instead of skb data area in rt2x00
    driver, oops, fix from Stanislaw Gruszka.

22) Fix regression causing iwlagn to not set driver private properly,
    from Emmanuel Grumbach.

23) Do not use power save idle mode on iwl 5000 series chips, from
    Wey-Yi Guy.

24) Wake on Lan doesn't work on second port of i350 IGB devices, fix
    from Carolyn Wyborny.

25) Fix suspend/resume on ath9k when ASM is disabled, from Stanislaw
    Gruszka.

Please pull, thanks a lot!

The following changes since commit 140d0b2108faebc77c6523296e211e509cb9f5f9:

  Do 'shm_init_ns()' in an early pure_initcall (2011-08-04 19:35:59 -1000)

are available in the git repository at:
  master.kernel.org:/pub/scm/linux/kernel/git/davem/net.git master

Anton Blanchard (2):
      net: sendmmsg should only return an error if no messages were sent
      net: Cap number of elements for sendmmsg

Bruce Allan (2):
      e1000e: remove unnecessary check for NULL pointer
      e1000e: minor re-order of #include files

Carolyn Wyborny (1):
      igb: fix WOL on second port of i350 device

Chas Williams (1):
      atm: br2864: sent packets truncated in VC routed mode

Dan Carpenter (1):
      cfg80211: off by one in nl80211_trigger_scan()

David S. Miller (4):
      Merge branch 'master' of git://git.kernel.org/.../horms/ipvs-2.6
      MAINTAINERS: Remove Pekka Savola from ipv6.
      Merge branch 'for-davem' of git://git.kernel.org/.../linville/wireless
      Merge branch 'master' of master.kernel.org:/.../jkirsher/net

Don Skidmore (1):
      ixgbe: fix __ixgbe_notify_dca() bail out code

Emil Tantilov (1):
      ixgbe: fix PHY link setup for 82599

Emmanuel Grumbach (1):
      iwlagn: sysfs couldn't find the priv pointer

Eric Dumazet (3):
      sch_sfq: fix sfq_enqueue()
      net: add kerneldoc to skb_copy_bits()
      net: fix NULL dereferences in check_peer_redir()

Felix Fietkau (1):
      ath9k: initialize tx chainmask before testing channel tx power values

Giuseppe Scrivano (1):
      cdc_ncm: fix endianness problem.

Helmut Schaa (1):
      rt2x00: Fix compilation without CONFIG_RT2X00_LIB_CRYPTO

Jesper Juhl (1):
      Documentation/bonding.txt: Update to 3.x version numbers

Jesse Brandeburg (1):
      intel drivers: repair missing flush operations

Joe Perches (1):
      MAINTAINERS: orphan FrameRelay DLCI

John W. Linville (1):
      Merge git://git.kernel.org/.../linville/wireless-next into for-davem

Jon Mason (1):
      irda: use PCI_VENDOR_ID_*

Julia Lawall (2):
      net: adjust array index
      drivers/net/niu.c: adjust array index

Klement Fish (1):
      sis190: Rx filter init is needed for MAC address change.

Larry Finger (1):
      rtlwifi: Fix kernel oops on ARM SOC

Lennart Sorensen (1):
      r8169: Add support for D-Link 530T rev C1 (Kernel Bug 38862)

Max Matveev (1):
      ipv6: check for IPv4 mapped addresses when connecting IPv6 sockets

Oleg Nesterov (1):
      proc_fork_connector: a lockless ->real_parent usage is not safe

Paul Moore (2):
      doc: Update the MAINTAINERS info for Paul Moore
      doc: Update the email address for Paul Moore in various source files

Randy Dunlap (1):
      net: fix new sunrpc kernel-doc warning

Simon Horman (1):
      IPVS: Free resources on module removal

Stanislaw Gruszka (4):
      iwlegacy: set tx power after rxon_assoc
      ath9k: skip ->config_pci_powersave() if PCIe port has ASPM disabled
      rt2x00: rt2800: fix zeroing skb structure
      rt2x00: fix usage of NULL queue

Tetsuo Handa (1):
      net: Fix security_socket_sendmsg() bypass problem.

Tord Andersson (1):
      macb: restore wrap bit when performing underrun cleanup

Tushar Gohad (1):
      xfrm: Fix key lengths for rfc3686(ctr(aes))

Vladislav Zolotarov (1):
      bnx2x: Prevent restarting Tx during bnx2x_nic_unload

Wey-Yi Guy (1):
      iwlagn: 5000 do not support idle mode

Yaniv Rosner (10):
      bnx2x: Fix missing pause on for 578xx
      bnx2x: Fix chip hanging due to TX pipe stall.
      bnx2x: Fix remote fault handling
      bnx2x: Fix BCM578xx-B0 MDIO access
      bnx2x: Fix LED behavior
      bnx2x: Fix link issue with DAC over 578xx
      bnx2x: Fix BCM84833 link
      bnx2x: Fix BCM54618se invalid link indication
      bnx2x: Fix BCM578xx MAC test
      bnx2x: Clear MDIO access warning during first driver load

Yevgeny Petrilin (2):
      mlx4: Fixing Ethernet unicast packet steering
      mlx4: decreasing ref count when removing mac

françois romieu (1):
      r8169 : MAC address change fix for the 8168e-vl.

 Documentation/networking/bonding.txt       |    2 +-
 MAINTAINERS                                |   10 +-
 drivers/connector/cn_proc.c                |    8 +-
 drivers/net/bnx2x/bnx2x_cmn.c              |   10 +-
 drivers/net/bnx2x/bnx2x_hsi.h              |    2 +
 drivers/net/bnx2x/bnx2x_link.c             |  218 +++++++++++++++++++---------
 drivers/net/bnx2x/bnx2x_link.h             |    3 +-
 drivers/net/bnx2x/bnx2x_reg.h              |    6 +-
 drivers/net/e1000/e1000_ethtool.c          |    6 +
 drivers/net/e1000/e1000_hw.c               |    3 +
 drivers/net/e1000e/es2lan.c                |    2 +
 drivers/net/e1000e/ethtool.c               |   11 ++-
 drivers/net/e1000e/ich8lan.c               |    7 +-
 drivers/net/e1000e/lib.c                   |    1 +
 drivers/net/e1000e/netdev.c                |    2 +-
 drivers/net/e1000e/phy.c                   |    2 +
 drivers/net/igb/e1000_nvm.c                |    1 +
 drivers/net/igb/igb_ethtool.c              |    5 +
 drivers/net/igb/igb_main.c                 |    4 +-
 drivers/net/igbvf/netdev.c                 |    2 +
 drivers/net/irda/smsc-ircc2.c              |   18 +--
 drivers/net/ixgb/ixgb_ee.c                 |    9 +
 drivers/net/ixgb/ixgb_hw.c                 |    2 +
 drivers/net/ixgbe/ixgbe_82599.c            |    1 +
 drivers/net/ixgbe/ixgbe_common.c           |    1 +
 drivers/net/ixgbe/ixgbe_ethtool.c          |    5 +
 drivers/net/ixgbe/ixgbe_main.c             |    3 +-
 drivers/net/ixgbe/ixgbe_phy.c              |    3 +
 drivers/net/ixgbe/ixgbe_x540.c             |    1 +
 drivers/net/macb.c                         |    3 +
 drivers/net/mlx4/en_port.c                 |    2 +-
 drivers/net/mlx4/main.c                    |    2 +
 drivers/net/mlx4/port.c                    |    9 +-
 drivers/net/niu.c                          |    4 +-
 drivers/net/r8169.c                        |   28 ++++
 drivers/net/sis190.c                       |   12 ++-
 drivers/net/usb/cdc_ncm.c                  |  156 +++++++-------------
 drivers/net/wireless/ath/ath9k/ar9002_hw.c |    6 +-
 drivers/net/wireless/ath/ath9k/ar9003_hw.c |    6 +-
 drivers/net/wireless/ath/ath9k/hw.c        |   11 +-
 drivers/net/wireless/ath/ath9k/hw.h        |    3 +-
 drivers/net/wireless/ath/ath9k/init.c      |    2 +
 drivers/net/wireless/ath/ath9k/pci.c       |   27 ++++
 drivers/net/wireless/iwlegacy/iwl-3945.c   |    6 +-
 drivers/net/wireless/iwlegacy/iwl-4965.c   |    8 +-
 drivers/net/wireless/iwlwifi/iwl-5000.c    |    1 +
 drivers/net/wireless/iwlwifi/iwl-core.h    |    2 +
 drivers/net/wireless/iwlwifi/iwl-pci.c     |   18 +-
 drivers/net/wireless/iwlwifi/iwl-power.c   |    3 +-
 drivers/net/wireless/rt2x00/rt2800lib.c    |    3 +-
 drivers/net/wireless/rt2x00/rt2x00lib.h    |    3 +-
 drivers/net/wireless/rt2x00/rt2x00mac.c    |    5 +-
 drivers/net/wireless/rtlwifi/pci.c         |   20 ++-
 include/net/cipso_ipv4.h                   |    2 +-
 include/net/dst.h                          |   17 ++-
 include/net/netlabel.h                     |    2 +-
 net/atm/br2684.c                           |    2 -
 net/core/skbuff.c                          |   17 ++-
 net/ipv4/igmp.c                            |    2 +-
 net/ipv4/ip_output.c                       |   10 +-
 net/ipv4/route.c                           |   14 +-
 net/ipv6/addrconf.c                        |    2 +-
 net/ipv6/datagram.c                        |   11 +-
 net/ipv6/ip6_fib.c                         |    2 +-
 net/ipv6/ip6_output.c                      |   13 ++-
 net/ipv6/route.c                           |   35 +++--
 net/netfilter/ipvs/ip_vs_ctl.c             |    1 +
 net/netlabel/Makefile                      |    2 -
 net/netlabel/netlabel_addrlist.c           |    2 +-
 net/netlabel/netlabel_addrlist.h           |    2 +-
 net/netlabel/netlabel_cipso_v4.c           |    2 +-
 net/netlabel/netlabel_cipso_v4.h           |    2 +-
 net/netlabel/netlabel_domainhash.c         |    2 +-
 net/netlabel/netlabel_domainhash.h         |    2 +-
 net/netlabel/netlabel_kapi.c               |    2 +-
 net/netlabel/netlabel_mgmt.c               |    2 +-
 net/netlabel/netlabel_mgmt.h               |    2 +-
 net/netlabel/netlabel_unlabeled.c          |    2 +-
 net/netlabel/netlabel_unlabeled.h          |    2 +-
 net/netlabel/netlabel_user.c               |    2 +-
 net/netlabel/netlabel_user.h               |    2 +-
 net/sched/sch_sfq.c                        |    7 +-
 net/socket.c                               |   73 +++++----
 net/sunrpc/xprt.c                          |    1 +
 net/wireless/nl80211.c                     |    2 +-
 net/xfrm/xfrm_algo.c                       |    4 +-
 security/selinux/hooks.c                   |    2 +-
 security/selinux/include/netif.h           |    2 +-
 security/selinux/include/netlabel.h        |    2 +-
 security/selinux/include/netnode.h         |    2 +-
 security/selinux/include/netport.h         |    2 +-
 security/selinux/netif.c                   |    2 +-
 security/selinux/netlabel.c                |    2 +-
 security/selinux/netnode.c                 |    2 +-
 security/selinux/netport.c                 |    2 +-
 security/selinux/selinuxfs.c               |    2 +-
 security/selinux/ss/ebitmap.c              |    2 +-
 security/selinux/ss/mls.c                  |    2 +-
 security/selinux/ss/mls.h                  |    2 +-
 security/selinux/ss/policydb.c             |    2 +-
 security/selinux/ss/services.c             |    2 +-
 security/smack/smack_lsm.c                 |    2 +-
 102 files changed, 615 insertions(+), 350 deletions(-)

^ permalink raw reply

* Re: [forcedeth bug] Re: [GIT] Networking
From: Neil Horman @ 2011-08-05 11:12 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Jiri Pirko, David Miller, torvalds, akpm, netdev, linux-kernel
In-Reply-To: <20110805102903.GF2420@elte.hu>

On Fri, Aug 05, 2011 at 12:29:03PM +0200, Ingo Molnar wrote:
> 
> * Jiri Pirko <jpirko@redhat.com> wrote:
> 
> > Thu, Aug 04, 2011 at 11:53:54PM CEST, mingo@elte.hu wrote:
> > >
> > >* Ingo Molnar <mingo@elte.hu> wrote:
> > >
> > >>  0891b0e08937: forcedeth: fix vlans
> > >
> > >Hm, forcedeth is still giving me trouble even on latest -git that has 
> > >the above fix included.
> > >
> > >The symptom is a stuck interface, no packets in. There's a frame 
> > >error RX packet:
> > >
> > > [root@mercury ~]# ifconfig eth0
> > > eth0      Link encap:Ethernet  HWaddr 00:13:D4:DC:41:12  
> > >           inet addr:10.0.1.13  Bcast:10.0.1.255  Mask:255.255.255.0
> > >           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
> > >           RX packets:0 errors:1 dropped:0 overruns:0 frame:1
> > >           TX packets:531 errors:0 dropped:0 overruns:0 carrier:0
> > >           collisions:0 txqueuelen:1000 
> > >           RX bytes:0 (0.0 b)  TX bytes:34112 (33.3 KiB)
> > >           Interrupt:35 
> > >
> > >Weirdly enough a defconfig x86 bootup works just fine - it's certain 
> > >.config combinations that trigger the bug. I've attached such a 
> > >config.
> > >
> > >Note that at least once i've observed a seemingly good kernel going 
> > >'bad' after a couple of minutes uptime. I've also observed 
> > >intermittent behavior - apparent lost packets and a laggy network.
> > >
> > >I have done 3 failed attempts to bisect it any further - i got to the 
> > >commit that got fixed by:
> > >
> > >  0891b0e08937: forcedeth: fix vlans
> > >
> > >... but that's something we already knew.
> > >
> > >Let me know if there's any data i can provide to help debug this 
> > >problem.
> > >
> > >Thanks,
> > >
> > >	Ingo
> > 
> > Interesting.
> > 
> > Is DEV_HAS_VLAN set in id->driver_data (L5344) ?
> 
Looks like you can match it to pci id.  Device ids 0x0372 and 0x0373 look to
have the flag set

> How do i tell that without hacking the driver?
> 
> > If so, would you try to disable both rx an tx vlan accel using 
> > ethtool and see if it helps?
> 
> Should i do that when the device is in a stuck state and see whether 
> it recovers?
> 
> Also, please provide the exact ethtool command sequences i should 
> try, this makes it easier for me to test exactly what you want me to 
> test.
> 
should be:
ethtool -K ethX rxvlan off txvlan off

I'm just poking about, but If I had to guess it looks like the card you have
ingo is an older forcedeth and uses the older format ring descriptor (I base
this on the fact that the rx error count noted above only gets incremented ni
nv_rx_process, but not nv_rx_process_optimized.  Both paths should support hw
vlan acceleration though and Jiris fixes for vlan hw rx acceleration were only
applied to the optimized path.

Neil

> Thanks,
> 
> 	Ingo
> --
> 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
> 

^ permalink raw reply

* RE: [PATCHv2 NEXT 1/1] netxen: add vlan accel support
From: Amit Salecha @ 2011-08-05 11:04 UTC (permalink / raw)
  To: David Miller; +Cc: netdev, Ameen Rahman, Rajesh Borundia
In-Reply-To: <20110805.032606.1214964517719657458.davem@davemloft.net>

> From: David Miller [mailto:davem@davemloft.net]
> Sent: Friday, August 05, 2011 3:56 PM
> 
> From: Amit Salecha <amit.salecha@qlogic.com>
> Date: Fri, 5 Aug 2011 05:12:37 -0500
> 
> > After fw recovery we don't get vlan devices by any kernel api, so we
> > are adding NETIF_VLAN_ACC support.  Earlier kernel had vlan group
> > support, through that we get vlan devices and then their ip
> > addresses.
> 
> Every time an IP address is added or removed there is a notification
> generated on the "inetaddr_chain", and you seem to be properly using
> this.
> 
> You have the VLAN device expansion in there as well.
> 
> Why doesn't this work?
> 
> The IP addresses cannot be added or removed from the VLAN device
> until it is attached to your device.  So you should see any IP
> address manipulation that occurs for VLANs stacked on top of
> your device.
>

This is true, but problem is after fw recovery. So flow is 
1) vlan device added
2) Driver program ip address of vlan device (through inet events)
3) Fw recovery
4) After fw recovery driver need to program ip addresses again which were already programmed.
   After fw recovery there won't be any inet/netdev event.

Simple solution is to maintain those ip addresses in driver.

It can be more easier, if we can get vlan ip addresses(or vlan device) by some kernel api.

-Amit
 



^ permalink raw reply

* Re: [PATCH] ipv6: check for IPv4 mapped addresses when connecting IPv6 sockets
From: David Miller @ 2011-08-05 10:57 UTC (permalink / raw)
  To: makc; +Cc: netdev, vladislav.yasevich
In-Reply-To: <20110804075506.62225813270B@regina.usersys.redhat.com>

From: Max Matveev <makc@redhat.com>
Date: Thu, 4 Aug 2011 17:42:44 +1000

> When support for binding to 'mapped INADDR_ANY (::ffff.0.0.0.0)' was added
> in 0f8d3c7ac3693d7b6c731bf2159273a59bf70e12 the rest of the code
> wasn't told so now it's possible to bind IPv6 datagram socket to
> ::ffff.0.0.0.0, connect it to another IPv4 address and it will all
> work except for getsockhame() which does not return the local address
> as expected.
> 
> To give getsockname() something to work with check for 'mapped INADDR_ANY'
> when connecting and update the in-core source addresses appropriately.
> 
> Signed-off-by: Max Matveev <makc@redhat.com>

Applied, but I had to fixup some trailing whitespace:

> @@ -102,10 +107,12 @@ ipv4_connected:
>  
>  		ipv6_addr_set_v4mapped(inet->inet_daddr, &np->daddr);
>  
> -		if (ipv6_addr_any(&np->saddr))
> +		if (ipv6_addr_any(&np->saddr) ||
> +		    ipv6_mapped_addr_any(&np->saddr))
>  			ipv6_addr_set_v4mapped(inet->inet_saddr, &np->saddr);
>  
> -		if (ipv6_addr_any(&np->rcv_saddr)) {
> +		if (ipv6_addr_any(&np->rcv_saddr) || 
						    ^^

there.

^ permalink raw reply

* Re: [PATCH] mlx4: decreasing ref count when removing mac
From: David Miller @ 2011-08-05 10:36 UTC (permalink / raw)
  To: roland-DgEjT+Ai2ygdnm+yROfE0A
  Cc: yevgenyp-VPRAkNaXOzVS1MOuV/RT9w,
	linux-rdma-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <CAL1RGDWVBWvc_p_XM2BQ-jV8DG19ZcbCcpntMJifED2frR+jcQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>

From: Roland Dreier <roland-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Date: Thu, 4 Aug 2011 05:55:39 -0700

>> For older FW versions, when a Mac address removed from Mac table,
>> we should set 0 for reference count for the corresponding Mac index.
>> Fixes a bug where removing Mac from the table still left that entry as
>> invalid.
> 
> This fixes my problems with MTU settings with old FW.
> 
> Tested-by: Roland Dreier <roland-BHEL68pLQRGGvPXPguhicg@public.gmane.org>

Applied, thanks everyone.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply

* Re: [net 0/6][pull request] Intel Wired LAN Driver Update
From: David Miller @ 2011-08-05 10:35 UTC (permalink / raw)
  To: jeffrey.t.kirsher; +Cc: netdev, gospo, sassmann
In-Reply-To: <1312460298-20405-1-git-send-email-jeffrey.t.kirsher@intel.com>

From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Thu,  4 Aug 2011 05:18:12 -0700

> The following series contains updates to e1000, e1000e, igb, igbvf,
> ixgb and ixgbe.
> 
> The following are changes since commit d3e614577198757d5854caa912e88f2d4296479b:
>   macb: restore wrap bit when performing underrun cleanup
> and are available in the git repository at:
>   master.kernel.org:/pub/scm/linux/kernel/git/jkirsher/net master

Pulled, thanks Jeff.

^ permalink raw reply

* [PATCH] netfilter: avoid double free in nf_reinject
From: Julian Anastasov @ 2011-08-05 10:36 UTC (permalink / raw)
  To: Patrick McHardy; +Cc: netfilter-devel, netdev, Kumar Swamy


	NF_STOLEN means skb was already freed

Signed-off-by: Julian Anastasov <ja@ssi.bg>
---

	May be fixes IPVS+ip_queue problem reported by Kumar Swamy:

	http://marc.info/?l=linux-virtual-server&m=131098073717449&w=2

diff -urp v3.0/linux/net/netfilter/nf_queue.c linux/net/netfilter/nf_queue.c
--- v3.0/linux/net/netfilter/nf_queue.c	2011-05-20 10:38:08.000000000 +0300
+++ linux/net/netfilter/nf_queue.c	2011-08-05 13:18:29.755962759 +0300
@@ -312,6 +312,7 @@ void nf_reinject(struct nf_queue_entry *
 		}
 		break;
 	case NF_STOLEN:
+		break;
 	default:
 		kfree_skb(skb);
 	}

^ permalink raw reply

* Re: [PATCH 0/3] sendmmsg fixes
From: David Miller @ 2011-08-05 10:31 UTC (permalink / raw)
  To: anton; +Cc: penguin-kernel, eparis, casey, mjt, netdev, linux-security-module
In-Reply-To: <20110805000737.743684961@samba.org>

From: Anton Blanchard <anton@samba.org>
Date: Fri, 05 Aug 2011 10:07:37 +1000

> Here are the current set of sendmmsg fixes that pass my test
> cases. Any review would be much appreciated.

All applied, thanks!

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox