* Re: Kernel panic nf_nat_setup_info+0x5b3/0x6e0
From: Eric Dumazet @ 2011-03-31 14:47 UTC (permalink / raw)
To: "Oleg A. Arkhangelsky"
Cc: Changli Gao, Patrick McHardy, netfilter-devel, netdev,
Paul E McKenney
In-Reply-To: <586191301580222@web107.yandex.ru>
Le jeudi 31 mars 2011 à 18:03 +0400, "Oleg A. Arkhangelsky" a écrit :
>
> 26.03.2011, 16:44, "Changli Gao" <xiaosuo@gmail.com>:
> > On Thu, Mar 3, 2011 at 3:33 PM, Changli Gao <xiaosuo@gmail.com>; wrote:
> >
> >> Please try the patch attached and test if the problem is solved or not. Thanks.
> >
> > Any feedback? Thanks.
> >
>
> Seems that patch is fine.
>
> https://bugzilla.kernel.org/show_bug.cgi?id=21512
>
I wonder if this is not hiding another bug.
Adding an RCU grace period might reduce the probability window.
By the time nf_conntrack_free(ct) is called, no other cpu/thread
could/should use ct, or ct->ext ?
Sure, another thread can find/pass_on ct in a lookup but should not use
it, since its refcount (ct_general.use) should be 0.
Patrick ?
^ permalink raw reply
* Re: [PATCH] Bridge: Removed unwanted check and improper usage of bridge locks
From: Stephen Hemminger @ 2011-03-31 15:36 UTC (permalink / raw)
To: Sasikanth V; +Cc: netdev, bridge
In-Reply-To: <1301423072-28093-1-git-send-email-sasikanth.v19@gmail.com>
On Tue, 29 Mar 2011 23:54:32 +0530
Sasikanth V <sasikanth.v19@gmail.com> wrote:
I don't think this is needed because br_dev_open is already covered
by the netlink mutex RTNL
^ permalink raw reply
* Re: [PATCH] skge: convert to hw_features
From: Stephen Hemminger @ 2011-03-31 15:41 UTC (permalink / raw)
To: Michał Mirosław; +Cc: netdev
In-Reply-To: <20110331110135.9625513A68@rere.qmqm.pl>
On Thu, 31 Mar 2011 13:01:35 +0200 (CEST)
Michał Mirosław <mirq-linux@rere.qmqm.pl> wrote:
> >From the code it looks like the hardware might support full HW_CSUM not
> just IP_CSUM. This needs testing and so is not changed here.
>
> Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
I don't think this will work right. The old code did not allow setting
tx/rx csum on the older GENESIS chip,
--
^ permalink raw reply
* Fw: [Bug 32322] New: Kernel crashes randomly due to unknown reason
From: Stephen Hemminger @ 2011-03-31 15:45 UTC (permalink / raw)
To: netdev
Begin forwarded message:
Date: Thu, 31 Mar 2011 08:22:53 GMT
From: bugzilla-daemon@bugzilla.kernel.org
To: shemminger@linux-foundation.org
Subject: [Bug 32322] New: Kernel crashes randomly due to unknown reason
https://bugzilla.kernel.org/show_bug.cgi?id=32322
Summary: Kernel crashes randomly due to unknown reason
Product: Networking
Version: 2.5
Kernel Version: 2.6.37.2
Platform: All
OS/Version: Linux
Tree: Mainline
Status: NEW
Severity: normal
Priority: P1
Component: IPV4
AssignedTo: shemminger@linux-foundation.org
ReportedBy: henrick19777@yahoo.com
Regression: No
Created an attachment (id=52732)
--> (https://bugzilla.kernel.org/attachment.cgi?id=52732)
kernel config file
Got a second kernel panic on this machine just randomly after ~26 days of
uptime. This server runs Debian Squeeze with vsftpd, rsync and apache2 services
installed from repositories. Here is the crash log:
------------[ cut here ]------------
kernel BUG at net/ipv4/tcp_output.c:994!
invalid opcode: 0000 [#1] SMP
last sysfs file: /sys/devices/pci0000:05/0000:05:07.1/local_cpus
Modules linked in:
Pid: 0, comm: kworker/0:1 Not tainted 2.6.37.2-hid3 #2 IBM eserver xSeries 235
-
[8671MAX]-/
EIP: 0060:[<c11c7f53>] EFLAGS: 00010206 CPU: 3
EIP is at tcp_fragment+0x15/0x239
EAX: c039ee00 EBX: f40e1200 ECX: 00003de0 EDX: f40e1200
ESI: f40e1200 EDI: c039ee00 EBP: 00003880 ESP: f50b7dd8
DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
Process kworker/0:1 (pid: 0, ti=f50b6000 task=f50b1bc0 task.ti=f50b2000)
Stack:
00003de0 00000286 c102841f c039ee00 f40e1200 f40e1218 00000023 c11c132d
000005a0 00000000 00000002 c039ee7c 00000001 c039ee00 0000072e 00000000
c11c57f6 00000001 00000001 00000000 00000001 00000026 00000006 c039ee7c
Call Trace:
[<c102841f>] ? __mod_timer+0xe3/0xec
[<c11c132d>] ? tcp_mark_head_lost+0x100/0x1a4
[<c11c57f6>] ? tcp_ack+0x154e/0x1813
[<c11c5e91>] ? tcp_rcv_established+0x3d6/0x48c
[<c11cb836>] ? tcp_v4_do_rcv+0x4a/0x1ad
[<c11cc64d>] ? tcp_v4_rcv+0x2dc/0x4cb
[<c11bd022>] ? tcp_gro_receive+0x84/0x1dd
[<c11b57e5>] ? ip_local_deliver+0x75/0x102
[<c11b572b>] ? ip_rcv+0x477/0x4bc
[<c11a0b80>] ? __netif_receive_skb+0x238/0x25a
[<c1006084>] ? nommu_sync_single_for_device+0x0/0x1
[<c11a11ab>] ? netif_receive_skb+0x5a/0x5f
[<c11a1253>] ? napi_skb_finish+0x1b/0x30
[<c116fce3>] ? tg3_poll_work+0x587/0x99f
[<c1170202>] ? tg3_poll+0x84/0x17d
[<c11a1680>] ? net_rx_action+0x53/0x12b
[<c1024503>] ? __do_softirq+0x70/0xfb
[<c1024493>] ? __do_softirq+0x0/0xfb
<IRQ>
[<c10243ed>] ? irq_exit+0x26/0x59
[<c100389d>] ? do_IRQ+0x7a/0x8b
[<c1002b29>] ? common_interrupt+0x29/0x30
[<c100764c>] ? default_idle+0x2b/0x3e
[<c10019f0>] ? cpu_idle+0x41/0x5d
Code: e8 33 ed ff ff 89 da 89 c1 89 f0 e8 6d e9 ff ff 31 c0 5b 5e 5f c3 55 57
89 c7 56 53 89 d3 83 ec 0c 89 0c 24 8b 6a 4c 39 e9 76 04 <0f> 0b eb fe f6 42 60
02 8b 72 50 74 27 8b 82 8c 00 00 00 8b 40
EIP: [<c11c7f53>] tcp_fragment+0x15/0x239 SS:ESP 0068:f50b7dd8
---[ end trace 2c2c1c63c61b172d ]---
Kernel panic - not syncing: Fatal exception in interrupt
Pid: 0, comm: kworker/0:1 Tainted: G D 2.6.37.2-hid3 #2
Call Trace:
[<c11eb2ac>] ? panic+0x4d/0x130
[<c1002e8e>] ? do_invalid_op+0x0/0x70
[<c1004a7d>] ? oops_end+0x6b/0x75
[<c1002ef5>] ? do_invalid_op+0x67/0x70
[<c11c7f53>] ? tcp_fragment+0x15/0x239
[<c11c0be2>] ? tcp_shifted_skb+0x1e7/0x200
[<c11c1699>] ? tcp_sacktag_walk+0x210/0x3a7
[<c11ecfee>] ? error_code+0x5a/0x60
[<c1002e8e>] ? do_invalid_op+0x0/0x70
[<c11c7f53>] ? tcp_fragment+0x15/0x239
[<c102841f>] ? __mod_timer+0xe3/0xec
[<c11c132d>] ? tcp_mark_head_lost+0x100/0x1a4
[<c11c57f6>] ? tcp_ack+0x154e/0x1813
[<c11c5e91>] ? tcp_rcv_established+0x3d6/0x48c
[<c11cb836>] ? tcp_v4_do_rcv+0x4a/0x1ad
[<c11cc64d>] ? tcp_v4_rcv+0x2dc/0x4cb
[<c11bd022>] ? tcp_gro_receive+0x84/0x1dd
[<c11b57e5>] ? ip_local_deliver+0x75/0x102
[<c11b572b>] ? ip_rcv+0x477/0x4bc
[<c11a0b80>] ? __netif_receive_skb+0x238/0x25a
[<c1006084>] ? nommu_sync_single_for_device+0x0/0x1
[<c11a11ab>] ? netif_receive_skb+0x5a/0x5f
[<c11a1253>] ? napi_skb_finish+0x1b/0x30
[<c116fce3>] ? tg3_poll_work+0x587/0x99f
[<c1170202>] ? tg3_poll+0x84/0x17d
[<c11a1680>] ? net_rx_action+0x53/0x12b
[<c1024503>] ? __do_softirq+0x70/0xfb
[<c1024493>] ? __do_softirq+0x0/0xfb
<IRQ> [<c10243ed>] ? irq_exit+0x26/0x59
[<c100389d>] ? do_IRQ+0x7a/0x8b
[<c1002b29>] ? common_interrupt+0x29/0x30
[<c100764c>] ? default_idle+0x2b/0x3e
[<c10019f0>] ? cpu_idle+0x41/0x5d
Rebooting in 20 seconds..
# cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 15
model : 2
model name : Intel(R) Xeon(TM) CPU 3.06GHz
stepping : 9
cpu MHz : 3060.475
cache size : 512 KB
physical id : 0
siblings : 2
core id : 0
cpu cores : 1
apicid : 0
initial apicid : 0
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 2
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe pebs bts cid xtpr
bogomips : 6120.95
clflush size : 64
cache_alignment : 128
address sizes : 36 bits physical, 32 bits virtual
power management:
processor : 1
vendor_id : GenuineIntel
cpu family : 15
model : 2
model name : Intel(R) Xeon(TM) CPU 3.06GHz
stepping : 9
cpu MHz : 3060.475
cache size : 512 KB
physical id : 3
siblings : 2
core id : 0
cpu cores : 1
apicid : 6
initial apicid : 6
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 2
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe pebs bts cid xtpr
bogomips : 6120.36
clflush size : 64
cache_alignment : 128
address sizes : 36 bits physical, 32 bits virtual
power management:
processor : 2
vendor_id : GenuineIntel
cpu family : 15
model : 2
model name : Intel(R) Xeon(TM) CPU 3.06GHz
stepping : 9
cpu MHz : 3060.475
cache size : 512 KB
physical id : 0
siblings : 2
core id : 0
cpu cores : 1
apicid : 1
initial apicid : 1
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 2
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe pebs bts cid xtpr
bogomips : 6120.33
clflush size : 64
cache_alignment : 128
address sizes : 36 bits physical, 32 bits virtual
power management:
processor : 3
vendor_id : GenuineIntel
cpu family : 15
model : 2
model name : Intel(R) Xeon(TM) CPU 3.06GHz
stepping : 9
cpu MHz : 3060.475
cache size : 512 KB
physical id : 3
siblings : 2
core id : 0
cpu cores : 1
apicid : 7
initial apicid : 7
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 2
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe pebs bts cid xtpr
bogomips : 6120.41
clflush size : 64
cache_alignment : 128
address sizes : 36 bits physical, 32 bits virtual
power management:
uname -a:
Linux debian 2.6.37.2-hid3 #2 SMP Wed Mar 2 23:34:19 EET 2011 i686 GNU/Linux
NO modules loaded.
The hardware is IBM eserver xSeries 235 - [8671MAX]-/
dmesg output and custom kernel config are attached.
THe crash happens randomly.
--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
--
^ permalink raw reply
* Re: [RFC PATCH] rtl8187: Fix led support for rfkill
From: wu zhangjin @ 2011-03-31 16:03 UTC (permalink / raw)
To: Hin-Tak Leung
Cc: Herton Ronaldo Krzesinski, Larry Finger,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA, Roman Mamedov
In-Reply-To: <4D8E8B1E.3030709-Rn4VEauK+AKRv+LV9MX5uipxlwaOVQ5f@public.gmane.org>
On Sun, Mar 27, 2011 at 8:55 AM, Hin-Tak Leung
<htl10-Rn4VEauK+AKRv+LV9MX5uipxlwaOVQ5f@public.gmane.org> wrote:
[...]
>
> Hmm, I seem to have the impression that there is code somewhere for
> switching a singular LED's behavior of the driver between one or the other,
> by echo'ing into sysfs or some other trickery? Or would that be a desired
> approach if that's not done at the moment?
Do you mean the interface: /sys/class/rfkill/rfkill0/state? or
something like /sys/class/leds/...::/brightness?
Seems the LED behavior can be triggered automatically by the rfkill
input event with the kernel config option(MAC80211_LEDS, RFKILL_LEDS),
so, echo'ing to such interface may be not a good idea ;-)
Best Regards,
Wu Zhangjin
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" 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: [RFC PATCH] rtl8187: Fix led support for rfkill
From: wu zhangjin @ 2011-03-31 16:04 UTC (permalink / raw)
To: Larry Finger
Cc: Hin-Tak Leung, Herton Ronaldo Krzesinski,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA, Roman Mamedov
In-Reply-To: <4D8FBE88.3050907-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org>
On Mon, Mar 28, 2011 at 6:47 AM, Larry Finger <Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org> wrote:
[...]
>
> I think the commit message should be revised. A simple statement like "the
> LED does not turn off when the rfkill switch is off" should be sufficient.
Yeah, the above statement is simpler ;-)
Regards,
Wu Zhangjin
>
> Larry
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" 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: [RFC PATCH] rtl8187: Fix led support for rfkill
From: wu zhangjin @ 2011-03-31 16:22 UTC (permalink / raw)
To: Herton Ronaldo Krzesinski
Cc: Larry Finger, Hin-Tak Leung, Herton Ronaldo Krzesinski,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA, Roman Mamedov
In-Reply-To: <20110328154046.GB2333@herton-IdeaPad-Y430>
On Mon, Mar 28, 2011 at 11:40 PM, Herton Ronaldo Krzesinski
<herton.krzesinski-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org> wrote:
[...]
>>
>> My rtl8187 devices are both external USB sticks, thus they have no
>> interaction with a radio-kill switch. I will test your patch to make
>> sure it does no harm to my system.
>>
>> I think the commit message should be revised. A simple statement
>> like "the LED does not turn off when the rfkill switch is off"
>> should be sufficient.
>
> The patch should work, but I wonder if we should be fiddling with priv->vif
> for this, perhaps we should not assume vif to be valid after
> rtl8187_remove_interface (I don't see problems with current
> rtl8187/mac80211 code on a quick look, but...)
>
Yes, but seems only two places have touched the vif pointer.
$ grep "vif =" -ur drivers/net/wireless/rtl818x/rtl8187/
drivers/net/wireless/rtl818x/rtl8187/dev.c: priv->vif = NULL;
drivers/net/wireless/rtl818x/rtl8187/dev.c: priv->vif = vif;
> I cleaner solution may be to use a priv->mode like p54.
Yep, then, we may need to add a 'mode' member to rtl8187_priv and
update it properly like p54.
So, What do you prefer? I will prepare a new patch asap.
Best Regards,
Wu Zhangjin
>
>>
>> Larry
>>
>
> --
> []'s
> Herton
>
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" 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
* usage of netdev_boot_setup_check() in modern NIC driver
From: Domenico Andreoli @ 2011-03-31 16:41 UTC (permalink / raw)
To: netdev
Hi all,
I'm working on the cs89x0 driver to make it a modern dual ISA/platform
driver (it is used on some non-ISA dev boards, like my QQ2440). Funny
game that could end in nothing except some new learnings for me.
It uses the netdev_boot_setup_check() function to get the configuration
from cmdline. The only other modern ISA driver (isa_(un)register_driver)
which uses it is the 3c509, which seems to invoke and immediately
overwrite part of the values just got.
Since nowdays module params can be set on the cmdline as well, may I
simply dump netdev_boot_setup_check()? It smells of legacy stuff.
In case of multiple NICs, which is the suggested way to pass the
different parameters (irq, iomem, etc) to every card?
Do you agree that such parameters have sense only on the ISA side of
the driver?
Regards,
Domenico
-----[ Domenico Andreoli, aka cavok
--[ http://www.dandreoli.com/gpgkey.asc
---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50
^ permalink raw reply
* Re: [PATCH 1/9 net-next-2.6] qlcnic: make PCI info available in all modes
From: Anirban Chakraborty @ 2011-03-31 17:04 UTC (permalink / raw)
To: David Miller; +Cc: netdev@vger.kernel.org, Dept_NX_Linux_NIC_Driver
In-Reply-To: <20110330.214049.137846353.davem@davemloft.net>
On Mar 30, 2011, at 9:40 PM, David Miller wrote:
> From: Anirban Chakraborty <anirban.chakraborty@qlogic.com>
> Date: Wed, 30 Mar 2011 13:21:36 -0700
>
>> From: Sony Chacko <sony.chacko@qlogic.com>
>>
>> Before this fix, PCI info was available only when multiple NIC functions were
>> present on a port.
>>
>> Signed-off-by: Sony Chacko <sony.chacko@qlogic.com>
>> Signed-off-by: Anirban Chakraborty <anirban.chakraborty@qlogic.com>
>
> Your email client has mangled all of these patches, turning tab characters
> into spaces.
>
> Given the number of patches that come in for the qlcnic driver, you guys
> have to do better than this.
Sorry about that. I use pine to send patches, not sure how it messed it up. I will resend it.
Thanks.
-Anirban
This message and any attached documents contain information from QLogic Corporation or its wholly-owned subsidiaries that may be confidential. If you are not the intended recipient, you may not read, copy, distribute, or use this information. If you have received this transmission in error, please notify the sender immediately by reply e-mail and then delete this message.
^ permalink raw reply
* Re: [RFC PATCH] rtl8187: Fix led support for rfkill
From: Herton Ronaldo Krzesinski @ 2011-03-31 17:19 UTC (permalink / raw)
To: wu zhangjin
Cc: Larry Finger, Hin-Tak Leung, Herton Ronaldo Krzesinski,
linux-wireless, netdev, Roman Mamedov
In-Reply-To: <AANLkTinwG5BR5=S14XYcwZ39c3k0xc9+2VsQFS+JHB0f@mail.gmail.com>
On Fri, Apr 01, 2011 at 12:22:51AM +0800, wu zhangjin wrote:
> On Mon, Mar 28, 2011 at 11:40 PM, Herton Ronaldo Krzesinski
> <herton.krzesinski@canonical.com> wrote:
> [...]
> >>
> >> My rtl8187 devices are both external USB sticks, thus they have no
> >> interaction with a radio-kill switch. I will test your patch to make
> >> sure it does no harm to my system.
> >>
> >> I think the commit message should be revised. A simple statement
> >> like "the LED does not turn off when the rfkill switch is off"
> >> should be sufficient.
> >
> > The patch should work, but I wonder if we should be fiddling with priv->vif
> > for this, perhaps we should not assume vif to be valid after
> > rtl8187_remove_interface (I don't see problems with current
> > rtl8187/mac80211 code on a quick look, but...)
> >
>
> Yes, but seems only two places have touched the vif pointer.
>
> $ grep "vif =" -ur drivers/net/wireless/rtl818x/rtl8187/
> drivers/net/wireless/rtl818x/rtl8187/dev.c: priv->vif = NULL;
> drivers/net/wireless/rtl818x/rtl8187/dev.c: priv->vif = vif;
>
> > I cleaner solution may be to use a priv->mode like p54.
>
> Yep, then, we may need to add a 'mode' member to rtl8187_priv and
> update it properly like p54.
>
> So, What do you prefer? I will prepare a new patch asap.
In the led code we dereference priv->vif, checking for priv->vif->type.
vif is a pointer from mac80211, and after rtl8187_remove_interface is
called by it, at least from my POV can do anything it wants with vif,
like freeing the sdata vif points to. From what I checked, it doesn't
free currently and your patch don't have issues, but may be it's better
to be safe and add a new "future proof" mode field.
And as your bug shows, the led code access priv->vif after
rtl8187_remove_interface, so we hit the case where vif could be
considered invalid.
So because of this and being cleaner I would go adding 'mode'.
>
> Best Regards,
> Wu Zhangjin
>
> >
> >>
> >> Larry
> >>
> >
> > --
> > []'s
> > Herton
> >
>
--
[]'s
Herton
^ permalink raw reply
* Re: [Bridge] [PATCH] bridge: return value for br_stp_recalculate_bridge_id()
From: Stephen Hemminger @ 2011-03-31 17:38 UTC (permalink / raw)
To: Dongdong Deng; +Cc: davem, netdev, bridge
In-Reply-To: <1301466207-16770-1-git-send-email-dongdong.deng@windriver.com>
Reported 3 times and already fixed.
^ permalink raw reply
* Re: [PATCH v2] ROSE: prevent heap corruption with bad facilities
From: Jiri Bohac @ 2011-03-31 18:02 UTC (permalink / raw)
To: Ben Hutchings; +Cc: Dan Rosenberg, ralf, davem, netdev, security
In-Reply-To: <1300639685.26693.286.camel@localhost>
On Sun, Mar 20, 2011 at 04:48:05PM +0000, Ben Hutchings wrote:
> @@ -365,49 +393,44 @@ static int rose_parse_ccitt(unsigned char *p, struct rose_facilities_struct *fac
> return n;
> }
>
> -int rose_parse_facilities(unsigned char *p,
> +int rose_parse_facilities(unsigned char *p, unsigned packet_len,
> struct rose_facilities_struct *facilities)
> {
> int facilities_len, len;
>
> facilities_len = *p++;
>
> - if (facilities_len == 0)
> + if (facilities_len == 0 || (unsigned)facilities_len > packet_len)
> return 0;
>
> - while (facilities_len > 0) {
> - if (*p == 0x00) {
> - facilities_len--;
> - p++;
> -
> - switch (*p) {
> - case FAC_NATIONAL: /* National */
> - len = rose_parse_national(p + 1, facilities, facilities_len - 1);
> - if (len < 0)
> - return 0;
> - facilities_len -= len + 1;
> - p += len + 1;
> - break;
> -
> - case FAC_CCITT: /* CCITT */
> - len = rose_parse_ccitt(p + 1, facilities, facilities_len - 1);
> - if (len < 0)
> - return 0;
> - facilities_len -= len + 1;
> - p += len + 1;
> - break;
> -
> - default:
> - printk(KERN_DEBUG "ROSE: rose_parse_facilities - unknown facilities family %02X\n", *p);
> - facilities_len--;
> - p++;
> - break;
> - }
> - } else
> - break; /* Error in facilities format */
> + while (facilities_len >= 3 && *p == 0x00) {
> + facilities_len--;
> + p++;
> +
> + switch (*p) {
> + case FAC_NATIONAL: /* National */
> + len = rose_parse_national(p + 1, facilities, facilities_len - 1);
> + break;
> +
> + case FAC_CCITT: /* CCITT */
> + len = rose_parse_ccitt(p + 1, facilities, facilities_len - 1);
> + break;
> +
> + default:
> + printk(KERN_DEBUG "ROSE: rose_parse_facilities - unknown facilities family %02X\n", *p);
> + len = 1;
> + break;
> + }
> +
> + if (len < 0)
> + return 0;
> + if (WARN_ON(len >= facilities_len))
> + return 0;
> + facilities_len -= len + 1;
> + p += len + 1;
> }
>
> - return 1;
> + return facilities_len == 0;
> }
This last hunk does not look correct. In the default branch of
the switch, you set len = 1, which means
p += 2; facilities_len -= 2.
The original code does
facilities_len--; p++;
... and it looks correct. So, to get the old behaviour back:
diff --git a/net/rose/rose_subr.c b/net/rose/rose_subr.c
index f6c71ca..9777700 100644
--- a/net/rose/rose_subr.c
+++ b/net/rose/rose_subr.c
@@ -418,7 +418,7 @@ int rose_parse_facilities(unsigned char *p, unsigned packet_len,
default:
printk(KERN_DEBUG "ROSE: rose_parse_facilities - unknown facilities family %02X\n", *p);
- len = 1;
+ len = 0;
break;
}
However, I wonder how much sense it makes to continue parsing the
facilities if an unknown facility family appears. We don't know
the length of its data, so we will interpret each 16 bytes a new
facilities header, hopefully soon bailing out on *p != 0x00.
In case of a long packet where every other byte is zero, the loop
will spam the kernel log with the printk ... which could probably
be classified as a security problem on its own. So how about the
following instead? I have no idea if this breaks some rose
specification, though.
Signed-off-by: Jiri Bohac <jbohac@suse.cz>
diff --git a/net/rose/rose_subr.c b/net/rose/rose_subr.c
index f6c71ca..e687c7f 100644
--- a/net/rose/rose_subr.c
+++ b/net/rose/rose_subr.c
@@ -418,8 +418,7 @@ int rose_parse_facilities(unsigned char *p, unsigned packet_len,
default:
printk(KERN_DEBUG "ROSE: rose_parse_facilities - unknown facilities family %02X\n", *p);
- len = 1;
- break;
+ return 0;
}
if (len < 0)
--
Jiri Bohac <jbohac@suse.cz>
SUSE Labs, SUSE CZ
^ permalink raw reply related
* Re: Fw: [Bug 32322] New: Kernel crashes randomly due to unknown reason
From: Ilpo Järvinen @ 2011-03-31 19:37 UTC (permalink / raw)
To: henrick19777; +Cc: Netdev
In-Reply-To: <20110331084530.187c9145@nehalam>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 3665 bytes --]
On Thu, 31 Mar 2011, Stephen Hemminger wrote:
> Begin forwarded message:
>
> Date: Thu, 31 Mar 2011 08:22:53 GMT
> From: bugzilla-daemon@bugzilla.kernel.org
> To: shemminger@linux-foundation.org
> Subject: [Bug 32322] New: Kernel crashes randomly due to unknown reason
>
>
> https://bugzilla.kernel.org/show_bug.cgi?id=32322
>
> Summary: Kernel crashes randomly due to unknown reason
> Product: Networking
> Version: 2.5
> Kernel Version: 2.6.37.2
> Platform: All
> OS/Version: Linux
> Tree: Mainline
> Status: NEW
> Severity: normal
> Priority: P1
> Component: IPV4
> AssignedTo: shemminger@linux-foundation.org
> ReportedBy: henrick19777@yahoo.com
> Regression: No
>
>
> Created an attachment (id=52732)
> --> (https://bugzilla.kernel.org/attachment.cgi?id=52732)
> kernel config file
>
> Got a second kernel panic on this machine just randomly after ~26 days of
> uptime. This server runs Debian Squeeze with vsftpd, rsync and apache2 services
> installed from repositories. Here is the crash log:
>
> ------------[ cut here ]------------
> kernel BUG at net/ipv4/tcp_output.c:994!
BUG(len < skb->len); it seems...
len = (packets-oldcount) * gso_size, but:
oldcnt < packets < cnt == oldcnt + pcount.
...I'd say there has to be some other invariant violated as skb should
always have length of at least gso_size * (pcount-1) + 1?
> invalid opcode: 0000 [#1] SMP
> last sysfs file: /sys/devices/pci0000:05/0000:05:07.1/local_cpus
> Modules linked in:
>
> Pid: 0, comm: kworker/0:1 Not tainted 2.6.37.2-hid3 #2 IBM eserver xSeries 235
> -
> [8671MAX]-/
> EIP: 0060:[<c11c7f53>] EFLAGS: 00010206 CPU: 3
> EIP is at tcp_fragment+0x15/0x239
> EAX: c039ee00 EBX: f40e1200 ECX: 00003de0 EDX: f40e1200
> ESI: f40e1200 EDI: c039ee00 EBP: 00003880 ESP: f50b7dd8
> DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
> Process kworker/0:1 (pid: 0, ti=f50b6000 task=f50b1bc0 task.ti=f50b2000)
> Stack:
> 00003de0 00000286 c102841f c039ee00 f40e1200 f40e1218 00000023 c11c132d
> 000005a0 00000000 00000002 c039ee7c 00000001 c039ee00 0000072e 00000000
> c11c57f6 00000001 00000001 00000000 00000001 00000026 00000006 c039ee7c
> Call Trace:
> [<c102841f>] ? __mod_timer+0xe3/0xec
> [<c11c132d>] ? tcp_mark_head_lost+0x100/0x1a4
...Another point... this particular check has unnecessarily high severity
as the callers need to be prepared to failures anyway... A patch below
(but this doesn't resolve the actual issue).
Yet another point, I suppose is should also be changed to check for
equality as then there isn't any point in calling fragment, but I don't
think it makes difference here now.
--
i.
--
[PATCH] tcp: len check is unnecessarily devastating, change to WARN_ON
All callers are prepared to alloc failures anyway, so this error
can safely be boomeranged to the callers domain without super
bad consequences. ...At worst the connection might go into a state
where each RTO tries to (unsuccessfully) re-fragment with such
a mis-sized value and eventually dies.
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi>
---
net/ipv4/tcp_output.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
index dfa5beb..8b0d016 100644
--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
@@ -1003,7 +1003,8 @@ int tcp_fragment(struct sock *sk, struct sk_buff *skb, u32 len,
int nlen;
u8 flags;
- BUG_ON(len > skb->len);
+ if (WARN_ON(len > skb->len))
+ return -EINVAL;
nsize = skb_headlen(skb) - len;
if (nsize < 0)
--
1.7.2.5
^ permalink raw reply related
* appletalk oops.
From: Dave Jones @ 2011-03-31 20:05 UTC (permalink / raw)
To: netdev
Just hit this on current git head while fuzzing syscalls.
I suspect we need to check somewhere for null sock's being passed in from userspace
I'm not sure yet this is appletalk specific, or it belongs somewhere further up
in accept.
Dave
[ 9264.494982] BUG: unable to handle kernel NULL pointer dereference at 000000000000004c
[ 9264.495660] IP: [<ffffffffa0593351>] sock_hold+0x9/0xf [appletalk]
[ 9264.495660] PGD 37a40067 PUD 860bd067 PMD 0
[ 9264.495660] Oops: 0002 [#1] SMP
[ 9264.495660] last sysfs file: /sys/devices/LNXSYSTM:00/device:00/PNP0C0A:00/power_supply/BAT0/energy_full
[ 9264.495660] CPU 1
[ 9264.495660] Modules linked in: tcp_lp nfnetlink can_bcm cmtp kernelcapi can_raw bnep hidp rfcomm rose ax25 af_key af_802154 atm pppoe pppox ppp_generic slhc irda crc_ccitt decnet rds can phonet appletalk ipx p8022 psnap llc p8023 sctp libcrc32c tun nfs fscache fuse nfsd lockd nfs_acl auth_rpcgss sunrpc cpufreq_ondemand acpi_cpufreq freq_table mperf ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables ipv6 uinput arc4 iwlagn snd_hda_codec_hdmi mac80211 snd_hda_codec_idt snd_usb_audio snd_hda_intel snd_hda_codec btusb bluetooth snd_seq uvcvideo snd_pcm snd_hwdep snd_usbmidi_lib dell_wmi zaurus cfg80211 sparse_keymap videodev snd_rawmidi dell_laptop cdc_ether snd_seq_device v4l2_compat_ioctl32 usbnet snd_timer dcdbas mii microcode cdc_acm cdc_wdm snd tg3 iTCO_wdt joydev
i2c_i801 pcspkr iTCO_vendor_support rfkill soundcore snd_page_alloc wmi i915 drm_kms_helper drm i2c_algo_bit i2c_core video [last unloaded: scsi_wait_scan]
[ 9264.495660]
[ 9264.495660] Pid: 3522, comm: trinity Not tainted 2.6.38-09065-g89078d5-dirty #6 Dell Inc. Adamo 13 /0N70T0
[ 9264.495660] RIP: 0010:[<ffffffffa0593351>] [<ffffffffa0593351>] sock_hold+0x9/0xf [appletalk]
[ 9264.495660] RSP: 0018:ffff88009e699dc8 EFLAGS: 00010296
[ 9264.523112] RAX: ffffffffa0596140 RBX: 0000000000000000 RCX: 0000000000000001
[ 9264.523112] RDX: ffff8800b6f76010 RSI: ffff8800b6f76000 RDI: 0000000000000000
[ 9264.523112] RBP: ffff88009e699dc8 R08: 0000000000000000 R09: 0000000000000000
[ 9264.523112] R10: ffff8800b6f76010 R11: 0000000000002000 R12: ffff8800a47f9080
[ 9264.523112] R13: ffff8800a47f90b0 R14: ffff8800a47f90b0 R15: ffff8800b8b097e0
[ 9264.523112] FS: 00007f4053fe8720(0000) GS:ffff88013fc00000(0000) knlGS:0000000000000000
[ 9264.523112] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[ 9264.523112] CR2: 000000000000004c CR3: 0000000086324000 CR4: 00000000000406e0
[ 9264.523112] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 9264.523112] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[ 9264.523112] Process trinity (pid: 3522, threadinfo ffff88009e698000, task ffff880109a38000)
[ 9264.523112] Stack:
[ 9264.523112] ffff88009e699df8 ffffffffa059454b 0000000000000000 ffff8800a47f9080
[ 9264.523112] ffffffffa0597550 ffff8800a47f90b0 ffff88009e699e18 ffffffff81404a87
[ 9264.523112] ffff8800b6f76000 0000000000000008 ffff88009e699e28 ffffffff81404b03
[ 9264.523112] Call Trace:
[ 9264.523112] [<ffffffffa059454b>] atalk_release+0x21/0x15b [appletalk]
[ 9264.523112] [<ffffffff81404a87>] sock_release+0x1f/0x74
[ 9264.523112] [<ffffffff81404b03>] sock_close+0x27/0x2b
[ 9264.523112] [<ffffffff8113f412>] fput+0x128/0x1f7
[ 9264.523112] [<ffffffff814053de>] sys_accept4+0x19b/0x1cb
[ 9264.523112] [<ffffffff814cdaf7>] ? schedule+0x6d9/0x70b
[ 9264.523112] [<ffffffff8108811b>] ? trace_hardirqs_off_caller+0x33/0x90
[ 9264.523112] [<ffffffff814d0339>] ? retint_swapgs+0x13/0x1b
[ 9264.523112] [<ffffffff8108bdf5>] ? trace_hardirqs_on_caller+0x10b/0x12f
[ 9264.523112] [<ffffffff810b09bd>] ? audit_syscall_entry+0x11c/0x148
[ 9264.523112] [<ffffffff8126744e>] ? trace_hardirqs_on_thunk+0x3a/0x3f
[ 9264.523112] [<ffffffff814d6bc2>] system_call_fastpath+0x16/0x1b
[ 9264.523112] Code: 75 e1 48 83 c3 08 48 81 fb 80 00 00 00 75 a5 48 c7 c7 10 70 59 a0 e8 bc c5 f3 e0 41 5a 5b c9 c3 90 90 55 48 89 e5 0f 1f 44 00 00 <f0> ff 47 4c c9 c3 55 48 89 e5 0f 1f 44 00 00 48 8b 97 88 02 00
[ 9264.523112] RIP [<ffffffffa0593351>] sock_hold+0x9/0xf [appletalk]
[ 9264.523112] RSP <ffff88009e699dc8>
[ 9264.523112] CR2: 000000000000004c
[ 9264.592577] ---[ end trace f86d1c3c82ba221d ]---
^ permalink raw reply
* Re: [PATCH] skge: convert to hw_features
From: Michał Mirosław @ 2011-03-31 20:48 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev
In-Reply-To: <20110331084102.71eb2b55@nehalam>
On Thu, Mar 31, 2011 at 08:41:02AM -0700, Stephen Hemminger wrote:
> On Thu, 31 Mar 2011 13:01:35 +0200 (CEST)
> Michał Mirosław <mirq-linux@rere.qmqm.pl> wrote:
> > >From the code it looks like the hardware might support full HW_CSUM not
> > just IP_CSUM. This needs testing and so is not changed here.
> >
> > Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
> I don't think this will work right. The old code did not allow setting
> tx/rx csum on the older GENESIS chip,
If you look at the changes near the end of patche, the hw_features are set
(and so features are made changeable) only when hw->chip_id != CHIP_ID_GENESIS.
Best Regards,
Michał Mirosław
^ permalink raw reply
* Re: [PATCH] skge: convert to hw_features
From: Stephen Hemminger @ 2011-03-31 20:56 UTC (permalink / raw)
To: Michał Mirosław; +Cc: netdev
In-Reply-To: <20110331204803.GA28109@rere.qmqm.pl>
On Thu, 31 Mar 2011 22:48:03 +0200
Michał Mirosław <mirq-linux@rere.qmqm.pl> wrote:
> On Thu, Mar 31, 2011 at 08:41:02AM -0700, Stephen Hemminger wrote:
> > On Thu, 31 Mar 2011 13:01:35 +0200 (CEST)
> > Michał Mirosław <mirq-linux@rere.qmqm.pl> wrote:
> > > >From the code it looks like the hardware might support full HW_CSUM not
> > > just IP_CSUM. This needs testing and so is not changed here.
> > >
> > > Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
> > I don't think this will work right. The old code did not allow setting
> > tx/rx csum on the older GENESIS chip,
>
> If you look at the changes near the end of patche, the hw_features are set
> (and so features are made changeable) only when hw->chip_id != CHIP_ID_GENESIS.
>
> Best Regards,
> Michał Mirosław
I actually have one of those old boards, let me test it.
^ permalink raw reply
* Re: [Bridge] [PATCH] bridge: return value for br_stp_recalculate_bridge_id()
From: Andrew Morton @ 2011-03-31 22:31 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Dongdong Deng, davem, netdev, bridge
In-Reply-To: <20110331103822.39b1a89e@nehalam>
On Thu, 31 Mar 2011 10:38:22 -0700
Stephen Hemminger <shemminger@vyatta.com> wrote:
> Reported 3 times and already fixed.
Four times!
Heaven knows why gcc treats that as a warning and not an error. It's a
guaranteed runtime bug.
^ permalink raw reply
* Re: [PATCH 07/19] timberdale: mfd_cell is now implicitly available to drivers
From: Grant Likely @ 2011-03-31 23:05 UTC (permalink / raw)
To: Andres Salomon
Cc: Samuel Ortiz, linux-kernel, Mark Brown, khali, ben-linux,
Peter Korsgaard, Mauro Carvalho Chehab, David Brownell, linux-i2c,
linux-media, netdev, spi-devel-general, Mocean Laboratories
In-Reply-To: <20110202200812.3d8d6cba@queued.net>
On Wed, Feb 02, 2011 at 08:08:12PM -0800, Andres Salomon wrote:
>
> No need to explicitly set the cell's platform_data/data_size.
>
> In this case, move the various platform_data pointers
> to driver_data. All of the clients which make use of it
> are also changed.
>
> Signed-off-by: Andres Salomon <dilinger@queued.net>
> ---
> drivers/dma/timb_dma.c | 2 +-
> drivers/gpio/timbgpio.c | 5 +-
> drivers/i2c/busses/i2c-ocores.c | 2 +-
> drivers/i2c/busses/i2c-xiic.c | 2 +-
> drivers/media/radio/radio-timb.c | 2 +-
> drivers/media/video/timblogiw.c | 2 +-
> drivers/mfd/timberdale.c | 81 +++++++++++++-------------------------
> drivers/net/ks8842.c | 2 +-
> drivers/spi/xilinx_spi.c | 2 +-
> 9 files changed, 36 insertions(+), 64 deletions(-)
>
> diff --git a/drivers/dma/timb_dma.c b/drivers/dma/timb_dma.c
> index 3b88a4e..aa06ca4 100644
> --- a/drivers/dma/timb_dma.c
> +++ b/drivers/dma/timb_dma.c
> @@ -684,7 +684,7 @@ static irqreturn_t td_irq(int irq, void *devid)
>
> static int __devinit td_probe(struct platform_device *pdev)
> {
> - struct timb_dma_platform_data *pdata = pdev->dev.platform_data;
> + struct timb_dma_platform_data *pdata = platform_get_drvdata(pdev);
Hold the phone. I know this has already been merged, but this isn't correct.
drvdata is under the ownership of the driver, which means it should
*not* be set when .probe() gets called. It is for driver private data
to do with as it needs, usually for internal state.
Gah. Not all devices instantiated via mfd will be an mfd device,
which means that the driver may very well expect an *entirely
different* platform_device pointer; which further means a very high
potential of incorrectly dereferenced structures (as evidenced by a
patch series that is not bisectable). For instance, the xilinx ip
cores are used by more than just mfd.
This is really bad. Since this is new in .39-rc1, I really think this
series needs to be reverted. Samuel, can you look at this please?
g.
> struct timb_dma *td;
> struct resource *iomem;
> int irq;
> diff --git a/drivers/gpio/timbgpio.c b/drivers/gpio/timbgpio.c
> index 58c8f30..e404487 100644
> --- a/drivers/gpio/timbgpio.c
> +++ b/drivers/gpio/timbgpio.c
> @@ -228,7 +228,7 @@ static int __devinit timbgpio_probe(struct platform_device *pdev)
> struct gpio_chip *gc;
> struct timbgpio *tgpio;
> struct resource *iomem;
> - struct timbgpio_platform_data *pdata = pdev->dev.platform_data;
> + struct timbgpio_platform_data *pdata = platform_get_drvdata(pdev);
> int irq = platform_get_irq(pdev, 0);
>
> if (!pdata || pdata->nr_pins > 32) {
> @@ -319,14 +319,13 @@ err_mem:
> static int __devexit timbgpio_remove(struct platform_device *pdev)
> {
> int err;
> - struct timbgpio_platform_data *pdata = pdev->dev.platform_data;
> struct timbgpio *tgpio = platform_get_drvdata(pdev);
> struct resource *iomem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> int irq = platform_get_irq(pdev, 0);
>
> if (irq >= 0 && tgpio->irq_base > 0) {
> int i;
> - for (i = 0; i < pdata->nr_pins; i++) {
> + for (i = 0; i < tgpio->gpio.ngpio; i++) {
> set_irq_chip(tgpio->irq_base + i, NULL);
> set_irq_chip_data(tgpio->irq_base + i, NULL);
> }
> diff --git a/drivers/i2c/busses/i2c-ocores.c b/drivers/i2c/busses/i2c-ocores.c
> index ef3bcb1..dc203ec 100644
> --- a/drivers/i2c/busses/i2c-ocores.c
> +++ b/drivers/i2c/busses/i2c-ocores.c
> @@ -305,7 +305,7 @@ static int __devinit ocores_i2c_probe(struct platform_device *pdev)
> return -EIO;
> }
>
> - pdata = pdev->dev.platform_data;
> + pdata = platform_get_drvdata(pdev);
> if (pdata) {
> i2c->regstep = pdata->regstep;
> i2c->clock_khz = pdata->clock_khz;
> diff --git a/drivers/i2c/busses/i2c-xiic.c b/drivers/i2c/busses/i2c-xiic.c
> index a9c419e..830b8c1 100644
> --- a/drivers/i2c/busses/i2c-xiic.c
> +++ b/drivers/i2c/busses/i2c-xiic.c
> @@ -704,7 +704,7 @@ static int __devinit xiic_i2c_probe(struct platform_device *pdev)
> if (irq < 0)
> goto resource_missing;
>
> - pdata = (struct xiic_i2c_platform_data *) pdev->dev.platform_data;
> + pdata = platform_get_drvdata(pdev);
> if (!pdata)
> return -EINVAL;
>
> diff --git a/drivers/media/radio/radio-timb.c b/drivers/media/radio/radio-timb.c
> index a185610..e7baf26 100644
> --- a/drivers/media/radio/radio-timb.c
> +++ b/drivers/media/radio/radio-timb.c
> @@ -148,7 +148,7 @@ static const struct v4l2_file_operations timbradio_fops = {
>
> static int __devinit timbradio_probe(struct platform_device *pdev)
> {
> - struct timb_radio_platform_data *pdata = pdev->dev.platform_data;
> + struct timb_radio_platform_data *pdata = platform_get_drvdata(pdev);
> struct timbradio *tr;
> int err;
>
> diff --git a/drivers/media/video/timblogiw.c b/drivers/media/video/timblogiw.c
> index fc611eb..61aa67a 100644
> --- a/drivers/media/video/timblogiw.c
> +++ b/drivers/media/video/timblogiw.c
> @@ -790,7 +790,7 @@ static int __devinit timblogiw_probe(struct platform_device *pdev)
> {
> int err;
> struct timblogiw *lw = NULL;
> - struct timb_video_platform_data *pdata = pdev->dev.platform_data;
> + struct timb_video_platform_data *pdata = platform_get_drvdata(pdev);
>
> if (!pdata) {
> dev_err(&pdev->dev, "No platform data\n");
> diff --git a/drivers/mfd/timberdale.c b/drivers/mfd/timberdale.c
> index 6ad8a7f..e9ae162 100644
> --- a/drivers/mfd/timberdale.c
> +++ b/drivers/mfd/timberdale.c
> @@ -384,8 +384,7 @@ static __devinitdata struct mfd_cell timberdale_cells_bar0_cfg0[] = {
> .name = "timb-dma",
> .num_resources = ARRAY_SIZE(timberdale_dma_resources),
> .resources = timberdale_dma_resources,
> - .platform_data = &timb_dma_platform_data,
> - .data_size = sizeof(timb_dma_platform_data),
> + .driver_data = &timb_dma_platform_data,
> },
> {
> .name = "timb-uart",
> @@ -396,43 +395,37 @@ static __devinitdata struct mfd_cell timberdale_cells_bar0_cfg0[] = {
> .name = "xiic-i2c",
> .num_resources = ARRAY_SIZE(timberdale_xiic_resources),
> .resources = timberdale_xiic_resources,
> - .platform_data = &timberdale_xiic_platform_data,
> - .data_size = sizeof(timberdale_xiic_platform_data),
> + .driver_data = &timberdale_xiic_platform_data,
> },
> {
> .name = "timb-gpio",
> .num_resources = ARRAY_SIZE(timberdale_gpio_resources),
> .resources = timberdale_gpio_resources,
> - .platform_data = &timberdale_gpio_platform_data,
> - .data_size = sizeof(timberdale_gpio_platform_data),
> + .driver_data = &timberdale_gpio_platform_data,
> },
> {
> .name = "timb-video",
> .num_resources = ARRAY_SIZE(timberdale_video_resources),
> .resources = timberdale_video_resources,
> - .platform_data = &timberdale_video_platform_data,
> - .data_size = sizeof(timberdale_video_platform_data),
> + .driver_data = &timberdale_video_platform_data,
> },
> {
> .name = "timb-radio",
> .num_resources = ARRAY_SIZE(timberdale_radio_resources),
> .resources = timberdale_radio_resources,
> - .platform_data = &timberdale_radio_platform_data,
> - .data_size = sizeof(timberdale_radio_platform_data),
> + .driver_data = &timberdale_radio_platform_data,
> },
> {
> .name = "xilinx_spi",
> .num_resources = ARRAY_SIZE(timberdale_spi_resources),
> .resources = timberdale_spi_resources,
> - .platform_data = &timberdale_xspi_platform_data,
> - .data_size = sizeof(timberdale_xspi_platform_data),
> + .driver_data = &timberdale_xspi_platform_data,
> },
> {
> .name = "ks8842",
> .num_resources = ARRAY_SIZE(timberdale_eth_resources),
> .resources = timberdale_eth_resources,
> - .platform_data = &timberdale_ks8842_platform_data,
> - .data_size = sizeof(timberdale_ks8842_platform_data)
> + .driver_data = &timberdale_ks8842_platform_data,
> },
> };
>
> @@ -441,8 +434,7 @@ static __devinitdata struct mfd_cell timberdale_cells_bar0_cfg1[] = {
> .name = "timb-dma",
> .num_resources = ARRAY_SIZE(timberdale_dma_resources),
> .resources = timberdale_dma_resources,
> - .platform_data = &timb_dma_platform_data,
> - .data_size = sizeof(timb_dma_platform_data),
> + .driver_data = &timb_dma_platform_data,
> },
> {
> .name = "timb-uart",
> @@ -458,15 +450,13 @@ static __devinitdata struct mfd_cell timberdale_cells_bar0_cfg1[] = {
> .name = "xiic-i2c",
> .num_resources = ARRAY_SIZE(timberdale_xiic_resources),
> .resources = timberdale_xiic_resources,
> - .platform_data = &timberdale_xiic_platform_data,
> - .data_size = sizeof(timberdale_xiic_platform_data),
> + .driver_data = &timberdale_xiic_platform_data,
> },
> {
> .name = "timb-gpio",
> .num_resources = ARRAY_SIZE(timberdale_gpio_resources),
> .resources = timberdale_gpio_resources,
> - .platform_data = &timberdale_gpio_platform_data,
> - .data_size = sizeof(timberdale_gpio_platform_data),
> + .driver_data = &timberdale_gpio_platform_data,
> },
> {
> .name = "timb-mlogicore",
> @@ -477,29 +467,25 @@ static __devinitdata struct mfd_cell timberdale_cells_bar0_cfg1[] = {
> .name = "timb-video",
> .num_resources = ARRAY_SIZE(timberdale_video_resources),
> .resources = timberdale_video_resources,
> - .platform_data = &timberdale_video_platform_data,
> - .data_size = sizeof(timberdale_video_platform_data),
> + .driver_data = &timberdale_video_platform_data,
> },
> {
> .name = "timb-radio",
> .num_resources = ARRAY_SIZE(timberdale_radio_resources),
> .resources = timberdale_radio_resources,
> - .platform_data = &timberdale_radio_platform_data,
> - .data_size = sizeof(timberdale_radio_platform_data),
> + .driver_data = &timberdale_radio_platform_data,
> },
> {
> .name = "xilinx_spi",
> .num_resources = ARRAY_SIZE(timberdale_spi_resources),
> .resources = timberdale_spi_resources,
> - .platform_data = &timberdale_xspi_platform_data,
> - .data_size = sizeof(timberdale_xspi_platform_data),
> + .driver_data = &timberdale_xspi_platform_data,
> },
> {
> .name = "ks8842",
> .num_resources = ARRAY_SIZE(timberdale_eth_resources),
> .resources = timberdale_eth_resources,
> - .platform_data = &timberdale_ks8842_platform_data,
> - .data_size = sizeof(timberdale_ks8842_platform_data)
> + .driver_data = &timberdale_ks8842_platform_data,
> },
> };
>
> @@ -508,8 +494,7 @@ static __devinitdata struct mfd_cell timberdale_cells_bar0_cfg2[] = {
> .name = "timb-dma",
> .num_resources = ARRAY_SIZE(timberdale_dma_resources),
> .resources = timberdale_dma_resources,
> - .platform_data = &timb_dma_platform_data,
> - .data_size = sizeof(timb_dma_platform_data),
> + .driver_data = &timb_dma_platform_data,
> },
> {
> .name = "timb-uart",
> @@ -520,36 +505,31 @@ static __devinitdata struct mfd_cell timberdale_cells_bar0_cfg2[] = {
> .name = "xiic-i2c",
> .num_resources = ARRAY_SIZE(timberdale_xiic_resources),
> .resources = timberdale_xiic_resources,
> - .platform_data = &timberdale_xiic_platform_data,
> - .data_size = sizeof(timberdale_xiic_platform_data),
> + .driver_data = &timberdale_xiic_platform_data,
> },
> {
> .name = "timb-gpio",
> .num_resources = ARRAY_SIZE(timberdale_gpio_resources),
> .resources = timberdale_gpio_resources,
> - .platform_data = &timberdale_gpio_platform_data,
> - .data_size = sizeof(timberdale_gpio_platform_data),
> + .driver_data = &timberdale_gpio_platform_data,
> },
> {
> .name = "timb-video",
> .num_resources = ARRAY_SIZE(timberdale_video_resources),
> .resources = timberdale_video_resources,
> - .platform_data = &timberdale_video_platform_data,
> - .data_size = sizeof(timberdale_video_platform_data),
> + .driver_data = &timberdale_video_platform_data,
> },
> {
> .name = "timb-radio",
> .num_resources = ARRAY_SIZE(timberdale_radio_resources),
> .resources = timberdale_radio_resources,
> - .platform_data = &timberdale_radio_platform_data,
> - .data_size = sizeof(timberdale_radio_platform_data),
> + .driver_data = &timberdale_radio_platform_data,
> },
> {
> .name = "xilinx_spi",
> .num_resources = ARRAY_SIZE(timberdale_spi_resources),
> .resources = timberdale_spi_resources,
> - .platform_data = &timberdale_xspi_platform_data,
> - .data_size = sizeof(timberdale_xspi_platform_data),
> + .driver_data = &timberdale_xspi_platform_data,
> },
> };
>
> @@ -558,8 +538,7 @@ static __devinitdata struct mfd_cell timberdale_cells_bar0_cfg3[] = {
> .name = "timb-dma",
> .num_resources = ARRAY_SIZE(timberdale_dma_resources),
> .resources = timberdale_dma_resources,
> - .platform_data = &timb_dma_platform_data,
> - .data_size = sizeof(timb_dma_platform_data),
> + .driver_data = &timb_dma_platform_data,
> },
> {
> .name = "timb-uart",
> @@ -570,43 +549,37 @@ static __devinitdata struct mfd_cell timberdale_cells_bar0_cfg3[] = {
> .name = "ocores-i2c",
> .num_resources = ARRAY_SIZE(timberdale_ocores_resources),
> .resources = timberdale_ocores_resources,
> - .platform_data = &timberdale_ocores_platform_data,
> - .data_size = sizeof(timberdale_ocores_platform_data),
> + .driver_data = &timberdale_ocores_platform_data,
> },
> {
> .name = "timb-gpio",
> .num_resources = ARRAY_SIZE(timberdale_gpio_resources),
> .resources = timberdale_gpio_resources,
> - .platform_data = &timberdale_gpio_platform_data,
> - .data_size = sizeof(timberdale_gpio_platform_data),
> + .driver_data = &timberdale_gpio_platform_data,
> },
> {
> .name = "timb-video",
> .num_resources = ARRAY_SIZE(timberdale_video_resources),
> .resources = timberdale_video_resources,
> - .platform_data = &timberdale_video_platform_data,
> - .data_size = sizeof(timberdale_video_platform_data),
> + .driver_data = &timberdale_video_platform_data,
> },
> {
> .name = "timb-radio",
> .num_resources = ARRAY_SIZE(timberdale_radio_resources),
> .resources = timberdale_radio_resources,
> - .platform_data = &timberdale_radio_platform_data,
> - .data_size = sizeof(timberdale_radio_platform_data),
> + .driver_data = &timberdale_radio_platform_data,
> },
> {
> .name = "xilinx_spi",
> .num_resources = ARRAY_SIZE(timberdale_spi_resources),
> .resources = timberdale_spi_resources,
> - .platform_data = &timberdale_xspi_platform_data,
> - .data_size = sizeof(timberdale_xspi_platform_data),
> + .driver_data = &timberdale_xspi_platform_data,
> },
> {
> .name = "ks8842",
> .num_resources = ARRAY_SIZE(timberdale_eth_resources),
> .resources = timberdale_eth_resources,
> - .platform_data = &timberdale_ks8842_platform_data,
> - .data_size = sizeof(timberdale_ks8842_platform_data)
> + .driver_data = &timberdale_ks8842_platform_data,
> },
> };
>
> diff --git a/drivers/net/ks8842.c b/drivers/net/ks8842.c
> index 928b2b8..7f0f51f 100644
> --- a/drivers/net/ks8842.c
> +++ b/drivers/net/ks8842.c
> @@ -1145,7 +1145,7 @@ static int __devinit ks8842_probe(struct platform_device *pdev)
> struct resource *iomem;
> struct net_device *netdev;
> struct ks8842_adapter *adapter;
> - struct ks8842_platform_data *pdata = pdev->dev.platform_data;
> + struct ks8842_platform_data *pdata = platform_get_drvdata(pdev);
> u16 id;
> unsigned i;
>
> diff --git a/drivers/spi/xilinx_spi.c b/drivers/spi/xilinx_spi.c
> index 7adaef6..2926dec 100644
> --- a/drivers/spi/xilinx_spi.c
> +++ b/drivers/spi/xilinx_spi.c
> @@ -474,7 +474,7 @@ static int __devinit xilinx_spi_probe(struct platform_device *dev)
> struct spi_master *master;
> u8 i;
>
> - pdata = dev->dev.platform_data;
> + pdata = platform_get_drvdata(dev);
> if (pdata) {
> num_cs = pdata->num_chipselect;
> little_endian = pdata->little_endian;
> --
> 1.7.2.3
>
^ permalink raw reply
* [PATCH net-next 2/3] bnx2x: don't write dcb/llfc fields in STORM memory
From: Michael Chan @ 2011-03-31 22:45 UTC (permalink / raw)
To: davem; +Cc: dmitry, eilong, netdev
In-Reply-To: <1301611533-9725-1-git-send-email-mchan@broadcom.com>
From: Dmitry Kravkov <dmitry@broadcom.com>
We could get hardware attention during DCB/FCoE traffic without this
fix.
Signed-off-by: Dmitry Kravkov <dmitry@broadcom.com>
Signed-off-by: Michael Chan <mchan@broadcom.com>
---
drivers/net/bnx2x/bnx2x_cmn.h | 13 ++++++++++++-
1 files changed, 12 insertions(+), 1 deletions(-)
diff --git a/drivers/net/bnx2x/bnx2x_cmn.h b/drivers/net/bnx2x/bnx2x_cmn.h
index ef37b98..775fef0 100644
--- a/drivers/net/bnx2x/bnx2x_cmn.h
+++ b/drivers/net/bnx2x/bnx2x_cmn.h
@@ -1041,12 +1041,23 @@ static inline void storm_memset_cmng(struct bnx2x *bp,
struct cmng_struct_per_port *cmng,
u8 port)
{
- size_t size = sizeof(struct cmng_struct_per_port);
+ size_t size =
+ sizeof(struct rate_shaping_vars_per_port) +
+ sizeof(struct fairness_vars_per_port) +
+ sizeof(struct safc_struct_per_port) +
+ sizeof(struct pfc_struct_per_port);
u32 addr = BAR_XSTRORM_INTMEM +
XSTORM_CMNG_PER_PORT_VARS_OFFSET(port);
__storm_memset_struct(bp, addr, size, (u32 *)cmng);
+
+ addr += size + 4 /* SKIP DCB+LLFC */;
+ size = sizeof(struct cmng_struct_per_port) -
+ size /* written */ - 4 /*skipped*/;
+
+ __storm_memset_struct(bp, addr, size,
+ (u32 *)(cmng->traffic_type_to_priority_cos));
}
/* HW Lock for shared dual port PHYs */
--
1.6.4.GIT
^ permalink raw reply related
* [PATCH net-next 3/3] bnx2x, cnic: Disable iSCSI if DCBX negotiation is successful
From: Michael Chan @ 2011-03-31 22:45 UTC (permalink / raw)
To: davem; +Cc: dmitry, eilong, netdev
In-Reply-To: <1301611533-9725-2-git-send-email-mchan@broadcom.com>
From: Dmitry Kravkov <dmitry@broadcom.com>
With current bnx2x firmware 6.2.9, iSCSI is not supported in DCB
network, so we need to disable it. Add cnic command to disconnect
iSCSI connections and prevent future connections when DCBX negotiation
succeeds.
Signed-off-by: Dmitry Kravkov <dmitry@broadcom.com>
Signed-off-by: Michael Chan <mchan@broadcom.com>
---
drivers/net/bnx2x/bnx2x_dcb.c | 22 ++++++++++++++
drivers/net/bnx2x/bnx2x_dcb.h | 8 ++++-
drivers/net/bnx2x/bnx2x_main.c | 5 +++
drivers/net/cnic.c | 64 ++++++++++++++++++++++++++++------------
drivers/net/cnic.h | 1 +
drivers/net/cnic_if.h | 6 ++-
6 files changed, 83 insertions(+), 23 deletions(-)
diff --git a/drivers/net/bnx2x/bnx2x_dcb.c b/drivers/net/bnx2x/bnx2x_dcb.c
index 9a24d79..1214907 100644
--- a/drivers/net/bnx2x/bnx2x_dcb.c
+++ b/drivers/net/bnx2x/bnx2x_dcb.c
@@ -571,6 +571,28 @@ void bnx2x_dcbx_set_params(struct bnx2x *bp, u32 state)
{
switch (state) {
case BNX2X_DCBX_STATE_NEG_RECEIVED:
+#ifdef BCM_CNIC
+ if (bp->state != BNX2X_STATE_OPENING_WAIT4_LOAD) {
+ struct cnic_ops *c_ops;
+ struct cnic_eth_dev *cp = &bp->cnic_eth_dev;
+ bp->flags |= NO_ISCSI_OOO_FLAG | NO_ISCSI_FLAG;
+ cp->drv_state |= CNIC_DRV_STATE_NO_ISCSI_OOO;
+ cp->drv_state |= CNIC_DRV_STATE_NO_ISCSI;
+
+ rcu_read_lock();
+ c_ops = rcu_dereference(bp->cnic_ops);
+ if (c_ops) {
+ bnx2x_cnic_notify(bp, CNIC_CTL_STOP_ISCSI_CMD);
+ rcu_read_unlock();
+ return;
+ }
+ rcu_read_unlock();
+ }
+
+ /* fall through if no CNIC initialized */
+ case BNX2X_DCBX_STATE_ISCSI_STOPPED:
+#endif
+
{
DP(NETIF_MSG_LINK, "BNX2X_DCBX_STATE_NEG_RECEIVED\n");
#ifdef BCM_DCBNL
diff --git a/drivers/net/bnx2x/bnx2x_dcb.h b/drivers/net/bnx2x/bnx2x_dcb.h
index 71b8eda..1e14775 100644
--- a/drivers/net/bnx2x/bnx2x_dcb.h
+++ b/drivers/net/bnx2x/bnx2x_dcb.h
@@ -183,9 +183,13 @@ void bnx2x_dcbx_set_state(struct bnx2x *bp, bool dcb_on, u32 dcbx_enabled);
enum {
BNX2X_DCBX_STATE_NEG_RECEIVED = 0x1,
- BNX2X_DCBX_STATE_TX_PAUSED = 0x2,
- BNX2X_DCBX_STATE_TX_RELEASED = 0x4
+#ifdef BCM_CNIC
+ BNX2X_DCBX_STATE_ISCSI_STOPPED,
+#endif
+ BNX2X_DCBX_STATE_TX_PAUSED,
+ BNX2X_DCBX_STATE_TX_RELEASED
};
+
void bnx2x_dcbx_set_params(struct bnx2x *bp, u32 state);
/* DCB netlink */
diff --git a/drivers/net/bnx2x/bnx2x_main.c b/drivers/net/bnx2x/bnx2x_main.c
index 32e64cc..f3cf889 100644
--- a/drivers/net/bnx2x/bnx2x_main.c
+++ b/drivers/net/bnx2x/bnx2x_main.c
@@ -10342,6 +10342,11 @@ static int bnx2x_drv_ctl(struct net_device *dev, struct drv_ctl_info *ctl)
break;
}
+ case DRV_CTL_ISCSI_STOPPED_CMD: {
+ bnx2x_dcbx_set_params(bp, BNX2X_DCBX_STATE_ISCSI_STOPPED);
+ break;
+ }
+
default:
BNX2X_ERR("unknown command %x\n", ctl->cmd);
rc = -EINVAL;
diff --git a/drivers/net/cnic.c b/drivers/net/cnic.c
index 8cca60e..5dfbff0 100644
--- a/drivers/net/cnic.c
+++ b/drivers/net/cnic.c
@@ -2966,31 +2966,36 @@ static int cnic_service_bnx2x(void *data, void *status_blk)
return 0;
}
-static void cnic_ulp_stop(struct cnic_dev *dev)
+static void cnic_ulp_stop_one(struct cnic_local *cp, int if_type)
{
- struct cnic_local *cp = dev->cnic_priv;
- int if_type;
-
- cnic_send_nlmsg(cp, ISCSI_KEVENT_IF_DOWN, NULL);
+ struct cnic_ulp_ops *ulp_ops;
- for (if_type = 0; if_type < MAX_CNIC_ULP_TYPE; if_type++) {
- struct cnic_ulp_ops *ulp_ops;
+ if (if_type == CNIC_ULP_ISCSI)
+ cnic_send_nlmsg(cp, ISCSI_KEVENT_IF_DOWN, NULL);
- mutex_lock(&cnic_lock);
- ulp_ops = rcu_dereference_protected(cp->ulp_ops[if_type],
- lockdep_is_held(&cnic_lock));
- if (!ulp_ops) {
- mutex_unlock(&cnic_lock);
- continue;
- }
- set_bit(ULP_F_CALL_PENDING, &cp->ulp_flags[if_type]);
+ mutex_lock(&cnic_lock);
+ ulp_ops = rcu_dereference_protected(cp->ulp_ops[if_type],
+ lockdep_is_held(&cnic_lock));
+ if (!ulp_ops) {
mutex_unlock(&cnic_lock);
+ return;
+ }
+ set_bit(ULP_F_CALL_PENDING, &cp->ulp_flags[if_type]);
+ mutex_unlock(&cnic_lock);
- if (test_and_clear_bit(ULP_F_START, &cp->ulp_flags[if_type]))
- ulp_ops->cnic_stop(cp->ulp_handle[if_type]);
+ if (test_and_clear_bit(ULP_F_START, &cp->ulp_flags[if_type]))
+ ulp_ops->cnic_stop(cp->ulp_handle[if_type]);
- clear_bit(ULP_F_CALL_PENDING, &cp->ulp_flags[if_type]);
- }
+ clear_bit(ULP_F_CALL_PENDING, &cp->ulp_flags[if_type]);
+}
+
+static void cnic_ulp_stop(struct cnic_dev *dev)
+{
+ struct cnic_local *cp = dev->cnic_priv;
+ int if_type;
+
+ for (if_type = 0; if_type < MAX_CNIC_ULP_TYPE; if_type++)
+ cnic_ulp_stop_one(cp, if_type);
}
static void cnic_ulp_start(struct cnic_dev *dev)
@@ -3039,6 +3044,12 @@ static int cnic_ctl(void *data, struct cnic_ctl_info *info)
cnic_put(dev);
break;
+ case CNIC_CTL_STOP_ISCSI_CMD: {
+ struct cnic_local *cp = dev->cnic_priv;
+ set_bit(CNIC_LCL_FL_STOP_ISCSI, &cp->cnic_local_flags);
+ queue_delayed_work(cnic_wq, &cp->delete_task, 0);
+ break;
+ }
case CNIC_CTL_COMPLETION_CMD: {
u32 cid = BNX2X_SW_CID(info->data.comp.cid);
u32 l5_cid;
@@ -3562,8 +3573,12 @@ static void cnic_init_csk_state(struct cnic_sock *csk)
static int cnic_cm_connect(struct cnic_sock *csk, struct cnic_sockaddr *saddr)
{
+ struct cnic_local *cp = csk->dev->cnic_priv;
int err = 0;
+ if (cp->ethdev->drv_state & CNIC_DRV_STATE_NO_ISCSI)
+ return -EOPNOTSUPP;
+
if (!cnic_in_use(csk))
return -EINVAL;
@@ -3965,6 +3980,17 @@ static void cnic_delete_task(struct work_struct *work)
cp = container_of(work, struct cnic_local, delete_task.work);
dev = cp->dev;
+ if (test_and_clear_bit(CNIC_LCL_FL_STOP_ISCSI, &cp->cnic_local_flags)) {
+ struct drv_ctl_info info;
+
+ rtnl_lock();
+ cnic_ulp_stop_one(cp, CNIC_ULP_ISCSI);
+ rtnl_unlock();
+
+ info.cmd = DRV_CTL_ISCSI_STOPPED_CMD;
+ cp->ethdev->drv_ctl(dev->netdev, &info);
+ }
+
for (i = 0; i < cp->max_cid_space; i++) {
struct cnic_context *ctx = &cp->ctx_tbl[i];
diff --git a/drivers/net/cnic.h b/drivers/net/cnic.h
index 4456260..3367a6d 100644
--- a/drivers/net/cnic.h
+++ b/drivers/net/cnic.h
@@ -226,6 +226,7 @@ struct cnic_local {
#define CNIC_LCL_FL_KWQ_INIT 0x0
#define CNIC_LCL_FL_L2_WAIT 0x1
#define CNIC_LCL_FL_RINGS_INITED 0x2
+#define CNIC_LCL_FL_STOP_ISCSI 0x4
struct cnic_dev *dev;
diff --git a/drivers/net/cnic_if.h b/drivers/net/cnic_if.h
index e01b49e..fdd8e46 100644
--- a/drivers/net/cnic_if.h
+++ b/drivers/net/cnic_if.h
@@ -12,8 +12,8 @@
#ifndef CNIC_IF_H
#define CNIC_IF_H
-#define CNIC_MODULE_VERSION "2.2.13"
-#define CNIC_MODULE_RELDATE "Jan 31, 2011"
+#define CNIC_MODULE_VERSION "2.2.14"
+#define CNIC_MODULE_RELDATE "Mar 30, 2011"
#define CNIC_ULP_RDMA 0
#define CNIC_ULP_ISCSI 1
@@ -85,6 +85,7 @@ struct kcqe {
#define CNIC_CTL_STOP_CMD 1
#define CNIC_CTL_START_CMD 2
#define CNIC_CTL_COMPLETION_CMD 3
+#define CNIC_CTL_STOP_ISCSI_CMD 4
#define DRV_CTL_IO_WR_CMD 0x101
#define DRV_CTL_IO_RD_CMD 0x102
@@ -94,6 +95,7 @@ struct kcqe {
#define DRV_CTL_START_L2_CMD 0x106
#define DRV_CTL_STOP_L2_CMD 0x107
#define DRV_CTL_RET_L2_SPQ_CREDIT_CMD 0x10c
+#define DRV_CTL_ISCSI_STOPPED_CMD 0x10d
struct cnic_ctl_completion {
u32 cid;
--
1.6.4.GIT
^ permalink raw reply related
* Re: [PATCH net-next 1/3] bnx2x: Update firmware to 6.2.9
From: David Miller @ 2011-04-01 0:06 UTC (permalink / raw)
To: mchan; +Cc: dmitry, eilong, netdev
In-Reply-To: <1301611533-9725-1-git-send-email-mchan@broadcom.com>
From: "Michael Chan" <mchan@broadcom.com>
Date: Thu, 31 Mar 2011 14:45:31 -0800
> From: Dmitry Kravkov <dmitry@broadcom.com>
>
> To fix bugs when running offloaded FCoE/iSCSI traffic in multiple
> Class of Service environments. In some scenarios, traffic could stop
> on certain rings and eventually all traffic would stop.
>
> Signed-off-by: Dmitry Kravkov <dmitry@broadcom.com>
> Signed-off-by: Michael Chan <mchan@broadcom.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next 2/3] bnx2x: don't write dcb/llfc fields in STORM memory
From: David Miller @ 2011-04-01 0:06 UTC (permalink / raw)
To: mchan; +Cc: dmitry, eilong, netdev
In-Reply-To: <1301611533-9725-2-git-send-email-mchan@broadcom.com>
From: "Michael Chan" <mchan@broadcom.com>
Date: Thu, 31 Mar 2011 14:45:32 -0800
> From: Dmitry Kravkov <dmitry@broadcom.com>
>
> We could get hardware attention during DCB/FCoE traffic without this
> fix.
>
> Signed-off-by: Dmitry Kravkov <dmitry@broadcom.com>
> Signed-off-by: Michael Chan <mchan@broadcom.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next 3/3] bnx2x, cnic: Disable iSCSI if DCBX negotiation is successful
From: David Miller @ 2011-04-01 0:06 UTC (permalink / raw)
To: mchan; +Cc: dmitry, eilong, netdev
In-Reply-To: <1301611533-9725-3-git-send-email-mchan@broadcom.com>
From: "Michael Chan" <mchan@broadcom.com>
Date: Thu, 31 Mar 2011 14:45:33 -0800
> From: Dmitry Kravkov <dmitry@broadcom.com>
>
> With current bnx2x firmware 6.2.9, iSCSI is not supported in DCB
> network, so we need to disable it. Add cnic command to disconnect
> iSCSI connections and prevent future connections when DCBX negotiation
> succeeds.
>
> Signed-off-by: Dmitry Kravkov <dmitry@broadcom.com>
> Signed-off-by: Michael Chan <mchan@broadcom.com>
Applied.
^ permalink raw reply
* [PATCH 0/7] Initialize flowi4 objects more efficiently.
From: David Miller @ 2011-04-01 0:12 UTC (permalink / raw)
To: netdev
When you do an initialization of an on-stack object such as:
struct foo x = { .member1 = bar, .member2 = baz };
GCC will emit a memset of the object, then fill in the parameters you
specify explicitly.
When the majority of the structure is being set explicitly, the memset
is basically unnecessary overhead. Emitting explicit stores to fill
in the zeros would be much cheaper, as well as avoid the function call
to memset.
Fix this for the cases which initialize most of the flowi4 object.
I therefore left alone cases such as:
struct flowi4 fl4 = { .daddr = daddr };
Since not only would any gains be minimal, we'd get code bloat and
much of such cases are also in the slow paths.
^ permalink raw reply
* [PATCH 1/7] net: Add helper flowi4_init_output().
From: David Miller @ 2011-04-01 0:12 UTC (permalink / raw)
To: netdev
On-stack initialization via assignment of flow structures are
expensive because GCC emits a memset() to clear the entire
structure out no matter what.
Add a helper for ipv4 output flow key setup which we can use to avoid
the memset.
Signed-off-by: David S. Miller <davem@davemloft.net>
---
include/net/flow.h | 21 +++++++++++++++++++++
1 files changed, 21 insertions(+), 0 deletions(-)
diff --git a/include/net/flow.h b/include/net/flow.h
index 7fe5a0f..37e77d6 100644
--- a/include/net/flow.h
+++ b/include/net/flow.h
@@ -70,6 +70,27 @@ struct flowi4 {
#define fl4_gre_key uli.gre_key
};
+static inline void flowi4_init_output(struct flowi4 *fl4, int oif,
+ __u32 mark, __u8 tos, __u8 scope,
+ __u8 proto, __u8 flags,
+ __be32 daddr, __be32 saddr,
+ __be16 dport, __be32 sport)
+{
+ fl4->flowi4_oif = oif;
+ fl4->flowi4_iif = 0;
+ fl4->flowi4_mark = mark;
+ fl4->flowi4_tos = tos;
+ fl4->flowi4_scope = scope;
+ fl4->flowi4_proto = proto;
+ fl4->flowi4_flags = flags;
+ fl4->flowi4_secid = 0;
+ fl4->daddr = daddr;
+ fl4->saddr = saddr;
+ fl4->fl4_sport = sport;
+ fl4->fl4_dport = dport;
+}
+
+
struct flowi6 {
struct flowi_common __fl_common;
#define flowi6_oif __fl_common.flowic_oif
--
1.7.4.2
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox