* Re: ixgbe dump
From: Yinghai Lu @ 2010-11-22 22:41 UTC (permalink / raw)
To: Skidmore, Donald C
Cc: Brandeburg, Jesse, David Miller, NetDev, Kirsher, Jeffrey T
In-Reply-To: <29F4ED941D916B48B88B4D2A4F3D1B9C01CBFC68C5@orsmsx509.amr.corp.intel.com>
On Thu, Nov 18, 2010 at 11:30 AM, Skidmore, Donald C
<donald.c.skidmore@intel.com> wrote:
>>-----Original Message-----
>>From: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.kernel.org] On
>>Behalf Of Yinghai Lu
>>Sent: Wednesday, November 17, 2010 5:22 PM
>>To: Brandeburg, Jesse; David Miller
>>Cc: NetDev
>>Subject: ixgbe dump
>>
>>[ 1546.287521] md: stopping all md devices.
>>[ 1547.283729] kvm: exiting hardware virtualization
>>[ 1547.292876] sd 2:2:1:0: [sdb] Synchronizing SCSI cache
>>[ 1547.293831] sd 2:2:0:0: [sda] Synchronizing SCSI cache
>>[ 1547.299627] BUG: unable to handle kernel NULL pointer dereference at
>>0000000000000033
>>[ 1547.315819] IP: [<ffffffff81746273>] ixgbe_set_rx_mode+0x265/0x38e
>>[ 1547.316448] PGD 3ff4487067 PUD 3ff216b067 PMD 0
>>[ 1547.335626] Oops: 0000 [#1] SMP
>>[ 1547.335941] last sysfs file: /sys/kernel/kexec_loaded
>>[ 1547.336381] CPU 0
>>[ 1547.336548] Modules linked in:
>>[ 1547.355798]
>>[ 1547.355968] Pid: 25630, comm: kexec Not tainted 2.6.37-rc2-tip-yh-01961-
>>g6034289-dirty #281 /Sun Fire X4800
>>[ 1547.375849] RIP: 0010:[<ffffffff81746273>] [<ffffffff81746273>]
>>ixgbe_set_rx_mode+0x265/0x38e
>>[ 1547.395543] RSP: 0018:ffff881fb9d49ce8 EFLAGS: 00010287
>>[ 1547.396080] RAX: 0000000000000000 RBX: ffff88dffe5a0940 RCX:
>>ffff88dffe5a0940
>>[ 1547.415635] RDX: 0000000000000000 RSI: 0000000000000001 RDI:
>>ffffc90077780000
>>[ 1547.416299] RBP: ffff881fb9d49d48 R08: 0000000000000000 R09:
>>0000000000000000
>>[ 1547.435860] R10: 000000000000a608 R11: 0000000000000000 R12:
>>0000000000000000
>>[ 1547.455516] R13: ffff88dffe5a0000 R14: 0000000000003400 R15:
>>ffff881fb9d49db7
>>[ 1547.456257] FS: 00000000006e0850(0063) GS:ffff88207d600000(0000)
>>knlGS:0000000000000000
>>[ 1547.475937] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
>>[ 1547.495330] CR2: 0000000000000033 CR3: 0000003ffa77e000 CR4:
>>00000000000006f0
>>[ 1547.496009] DR0: 0000000000000000 DR1: 0000000000000000 DR2:
>>0000000000000000
>>[ 1547.515594] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7:
>>0000000000000400
>>[ 1547.516229] Process kexec (pid: 25630, threadinfo ffff881fb9d48000, task
>>ffff881f8a57a2d0)
>>[ 1547.536039] Stack:
>>[ 1547.536244] 0000000000000040 0000002b00000000 ffff881ffedc1000
>>0000000000000006
>>[ 1547.555894] ffff88dffe5a1b40 0b00000081454ec8 ffff881fb9d49d48
>>ffff88dffe5a0940
>>[ 1547.575411] ffff881ffedc1000 000000000000001e 0000000000000000
>>ffff881fb9d49db7
>>[ 1547.576131] Call Trace:
>>[ 1547.595251] [<ffffffff8174a8f4>] __ixgbe_shutdown+0x9d/0x153
>>[ 1547.595770] [<ffffffff8174a9c4>] ixgbe_shutdown+0x1a/0x43
>>[ 1547.615250] [<ffffffff814574bb>] pci_device_shutdown+0x2c/0x40
>>[ 1547.615887] [<ffffffff8151c5e9>] device_shutdown+0x75/0xb0
>>[ 1547.635268] [<ffffffff8108f461>] kernel_restart_prepare+0x2c/0x33
>>[ 1547.635927] [<ffffffff810bc821>] kernel_kexec+0x38/0x6b
>>[ 1547.655252] [<ffffffff8108f618>] sys_reboot+0x156/0x194
>>[ 1547.655765] [<ffffffff8114422a>] ? __d_free+0x59/0x5e
>>[ 1547.675145] [<ffffffff81144283>] ? d_free+0x54/0x66
>>[ 1547.675612] [<ffffffff8114439d>] ? d_kill+0x3b/0x43
>>[ 1547.695025] [<ffffffff81144a1c>] ? dput+0x40/0x140
>>[ 1547.695539] [<ffffffff811351a9>] ? fput+0x1d7/0x1e6
>>[ 1547.696045] [<ffffffff81036c0c>] ? sysret_check+0x27/0x62
>>[ 1547.715426] [<ffffffff81cd9772>] ? trace_hardirqs_on_thunk+0x3a/0x3f
>>[ 1547.734897] [<ffffffff81036bdb>] system_call_fastpath+0x16/0x1b
>>[ 1547.735428] Code: d2 e9 81 00 00 00 48 8b 83 00 12 00 00 8b 80 88 50 00
>>00 0d 00 00 00 80 e9 a7 00 00 00 48 8b 81 00 0a 00 00 48 8b bb 00 12 00 00
>><0f> b6 40 33 83 f8 3f 7f 0d 89 c6 c1 e6 06 81 c6 28 10 00 00 eb
>>[ 1547.775262] RIP [<ffffffff81746273>] ixgbe_set_rx_mode+0x265/0x38e
>>[ 1547.775909] RSP <ffff881fb9d49ce8>
>>[ 1547.794997] CR2: 0000000000000033
>>[ 1547.795987] ---[ end trace 4ed9616adc45007c ]---
>>--
>>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
>
> Thanks for the dump.
>
> I believe I've found the problem and will get a patch to Jeff shortly.
Did you have that patch posted already?
Thanks
Yinghai
^ permalink raw reply
* [PATCH v2] tcp: restrict net.ipv4.tcp_adv_win_scale (#20312)
From: Alexey Dobriyan @ 2010-11-22 22:54 UTC (permalink / raw)
To: davem; +Cc: Eric Dumazet, shemminger, netdev, Ben Hutchings
In-Reply-To: <1289830722.2586.5.camel@bwh-desktop>
tcp_win_from_space() does the following:
if (sysctl_tcp_adv_win_scale <= 0)
return space >> (-sysctl_tcp_adv_win_scale);
else
return space - (space >> sysctl_tcp_adv_win_scale);
"space" is int.
As per C99 6.5.7 (3) shifting int for 32 or more bits is
undefined behaviour.
Indeed, if sysctl_tcp_adv_win_scale is exactly 32,
space >> 32 equals space and function returns 0.
Which means we busyloop in tcp_fixup_rcvbuf().
Restrict net.ipv4.tcp_adv_win_scale to [-31, 31].
Fix https://bugzilla.kernel.org/show_bug.cgi?id=20312
Steps to reproduce:
echo 32 >/proc/sys/net/ipv4/tcp_adv_win_scale
wget www.kernel.org
[softlockup]
Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
---
Documentation/networking/ip-sysctl.txt | 1 +
net/ipv4/sysctl_net_ipv4.c | 6 +++++-
2 files changed, 6 insertions(+), 1 deletion(-)
--- a/Documentation/networking/ip-sysctl.txt
+++ b/Documentation/networking/ip-sysctl.txt
@@ -144,6 +144,7 @@ tcp_adv_win_scale - INTEGER
Count buffering overhead as bytes/2^tcp_adv_win_scale
(if tcp_adv_win_scale > 0) or bytes-bytes/2^(-tcp_adv_win_scale),
if it is <= 0.
+ Possible values are [-31, 31], inclusive.
Default: 2
tcp_allowed_congestion_control - STRING
--- a/net/ipv4/sysctl_net_ipv4.c
+++ b/net/ipv4/sysctl_net_ipv4.c
@@ -26,6 +26,8 @@ static int zero;
static int tcp_retr1_max = 255;
static int ip_local_port_range_min[] = { 1, 1 };
static int ip_local_port_range_max[] = { 65535, 65535 };
+static int tcp_adv_win_scale_min = -31;
+static int tcp_adv_win_scale_max = 31;
/* Update system visible IP port range */
static void set_local_port_range(int range[2])
@@ -426,7 +428,9 @@ static struct ctl_table ipv4_table[] = {
.data = &sysctl_tcp_adv_win_scale,
.maxlen = sizeof(int),
.mode = 0644,
- .proc_handler = proc_dointvec
+ .proc_handler = proc_dointvec_minmax,
+ .extra1 = &tcp_adv_win_scale_min,
+ .extra2 = &tcp_adv_win_scale_max,
},
{
.procname = "tcp_tw_reuse",
^ permalink raw reply
* Re: ixgbe dump
From: Jeff Kirsher @ 2010-11-22 23:22 UTC (permalink / raw)
To: Yinghai Lu; +Cc: Skidmore, Donald C, Brandeburg, Jesse, David Miller, NetDev
In-Reply-To: <AANLkTinQ-6CaUY3bYd+SMBCaNvU5YiXL2P+gh7N1tM-x@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 4825 bytes --]
On Mon, 2010-11-22 at 14:41 -0800, Yinghai Lu wrote:
> On Thu, Nov 18, 2010 at 11:30 AM, Skidmore, Donald C
> <donald.c.skidmore@intel.com> wrote:
> >>-----Original Message-----
> >>From: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.kernel.org] On
> >>Behalf Of Yinghai Lu
> >>Sent: Wednesday, November 17, 2010 5:22 PM
> >>To: Brandeburg, Jesse; David Miller
> >>Cc: NetDev
> >>Subject: ixgbe dump
> >>
> >>[ 1546.287521] md: stopping all md devices.
> >>[ 1547.283729] kvm: exiting hardware virtualization
> >>[ 1547.292876] sd 2:2:1:0: [sdb] Synchronizing SCSI cache
> >>[ 1547.293831] sd 2:2:0:0: [sda] Synchronizing SCSI cache
> >>[ 1547.299627] BUG: unable to handle kernel NULL pointer dereference at
> >>0000000000000033
> >>[ 1547.315819] IP: [<ffffffff81746273>] ixgbe_set_rx_mode+0x265/0x38e
> >>[ 1547.316448] PGD 3ff4487067 PUD 3ff216b067 PMD 0
> >>[ 1547.335626] Oops: 0000 [#1] SMP
> >>[ 1547.335941] last sysfs file: /sys/kernel/kexec_loaded
> >>[ 1547.336381] CPU 0
> >>[ 1547.336548] Modules linked in:
> >>[ 1547.355798]
> >>[ 1547.355968] Pid: 25630, comm: kexec Not tainted 2.6.37-rc2-tip-yh-01961-
> >>g6034289-dirty #281 /Sun Fire X4800
> >>[ 1547.375849] RIP: 0010:[<ffffffff81746273>] [<ffffffff81746273>]
> >>ixgbe_set_rx_mode+0x265/0x38e
> >>[ 1547.395543] RSP: 0018:ffff881fb9d49ce8 EFLAGS: 00010287
> >>[ 1547.396080] RAX: 0000000000000000 RBX: ffff88dffe5a0940 RCX:
> >>ffff88dffe5a0940
> >>[ 1547.415635] RDX: 0000000000000000 RSI: 0000000000000001 RDI:
> >>ffffc90077780000
> >>[ 1547.416299] RBP: ffff881fb9d49d48 R08: 0000000000000000 R09:
> >>0000000000000000
> >>[ 1547.435860] R10: 000000000000a608 R11: 0000000000000000 R12:
> >>0000000000000000
> >>[ 1547.455516] R13: ffff88dffe5a0000 R14: 0000000000003400 R15:
> >>ffff881fb9d49db7
> >>[ 1547.456257] FS: 00000000006e0850(0063) GS:ffff88207d600000(0000)
> >>knlGS:0000000000000000
> >>[ 1547.475937] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> >>[ 1547.495330] CR2: 0000000000000033 CR3: 0000003ffa77e000 CR4:
> >>00000000000006f0
> >>[ 1547.496009] DR0: 0000000000000000 DR1: 0000000000000000 DR2:
> >>0000000000000000
> >>[ 1547.515594] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7:
> >>0000000000000400
> >>[ 1547.516229] Process kexec (pid: 25630, threadinfo ffff881fb9d48000, task
> >>ffff881f8a57a2d0)
> >>[ 1547.536039] Stack:
> >>[ 1547.536244] 0000000000000040 0000002b00000000 ffff881ffedc1000
> >>0000000000000006
> >>[ 1547.555894] ffff88dffe5a1b40 0b00000081454ec8 ffff881fb9d49d48
> >>ffff88dffe5a0940
> >>[ 1547.575411] ffff881ffedc1000 000000000000001e 0000000000000000
> >>ffff881fb9d49db7
> >>[ 1547.576131] Call Trace:
> >>[ 1547.595251] [<ffffffff8174a8f4>] __ixgbe_shutdown+0x9d/0x153
> >>[ 1547.595770] [<ffffffff8174a9c4>] ixgbe_shutdown+0x1a/0x43
> >>[ 1547.615250] [<ffffffff814574bb>] pci_device_shutdown+0x2c/0x40
> >>[ 1547.615887] [<ffffffff8151c5e9>] device_shutdown+0x75/0xb0
> >>[ 1547.635268] [<ffffffff8108f461>] kernel_restart_prepare+0x2c/0x33
> >>[ 1547.635927] [<ffffffff810bc821>] kernel_kexec+0x38/0x6b
> >>[ 1547.655252] [<ffffffff8108f618>] sys_reboot+0x156/0x194
> >>[ 1547.655765] [<ffffffff8114422a>] ? __d_free+0x59/0x5e
> >>[ 1547.675145] [<ffffffff81144283>] ? d_free+0x54/0x66
> >>[ 1547.675612] [<ffffffff8114439d>] ? d_kill+0x3b/0x43
> >>[ 1547.695025] [<ffffffff81144a1c>] ? dput+0x40/0x140
> >>[ 1547.695539] [<ffffffff811351a9>] ? fput+0x1d7/0x1e6
> >>[ 1547.696045] [<ffffffff81036c0c>] ? sysret_check+0x27/0x62
> >>[ 1547.715426] [<ffffffff81cd9772>] ? trace_hardirqs_on_thunk+0x3a/0x3f
> >>[ 1547.734897] [<ffffffff81036bdb>] system_call_fastpath+0x16/0x1b
> >>[ 1547.735428] Code: d2 e9 81 00 00 00 48 8b 83 00 12 00 00 8b 80 88 50 00
> >>00 0d 00 00 00 80 e9 a7 00 00 00 48 8b 81 00 0a 00 00 48 8b bb 00 12 00 00
> >><0f> b6 40 33 83 f8 3f 7f 0d 89 c6 c1 e6 06 81 c6 28 10 00 00 eb
> >>[ 1547.775262] RIP [<ffffffff81746273>] ixgbe_set_rx_mode+0x265/0x38e
> >>[ 1547.775909] RSP <ffff881fb9d49ce8>
> >>[ 1547.794997] CR2: 0000000000000033
> >>[ 1547.795987] ---[ end trace 4ed9616adc45007c ]---
> >>--
> >>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
> >
> > Thanks for the dump.
> >
> > I believe I've found the problem and will get a patch to Jeff shortly.
>
> Did you have that patch posted already?
>
> Thanks
>
> Yinghai
It is not posted yet. Don got the patch to our testers and they are
doing a quick validation on the patch before I post it to netdev.
I can send you the patch, so that you can assist in letting us know if
it resolves the issue.
Cheers,
Jeff
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: ixgbe dump
From: Yinghai Lu @ 2010-11-22 23:28 UTC (permalink / raw)
To: jeffrey.t.kirsher
Cc: Skidmore, Donald C, Brandeburg, Jesse, David Miller, NetDev
In-Reply-To: <1290468133.2603.2.camel@jtkirshe-MOBL1>
On Mon, Nov 22, 2010 at 3:22 PM, Jeff Kirsher
<jeffrey.t.kirsher@intel.com> wrote:
>
> It is not posted yet. Don got the patch to our testers and they are
> doing a quick validation on the patch before I post it to netdev.
>
> I can send you the patch, so that you can assist in letting us know if
> it resolves the issue.
sure. please send that to me.
Thanks
^ permalink raw reply
* Re: [PATCH] arch/tile: fix rwlock so would-be write lockers don't block new readers
From: Cypher Wu @ 2010-11-23 1:36 UTC (permalink / raw)
To: Chris Metcalf; +Cc: linux-kernel, Américo Wang, Eric Dumazet, netdev
In-Reply-To: <4CEA71AD.5010606@tilera.com>
2010/11/22 Chris Metcalf <cmetcalf@tilera.com>:
> On 11/22/2010 12:39 AM, Cypher Wu wrote:
>> 2010/11/15 Chris Metcalf <cmetcalf@tilera.com>:
>>> This avoids a deadlock in the IGMP code where one core gets a read
>>> lock, another core starts trying to get a write lock (thus blocking
>>> new readers), and then the first core tries to recursively re-acquire
>>> the read lock.
>>>
>>> We still try to preserve some degree of balance by giving priority
>>> to additional write lockers that come along while the lock is held
>>> for write, so they can all complete quickly and return the lock to
>>> the readers.
>>>
>>> Signed-off-by: Chris Metcalf <cmetcalf@tilera.com>
>>> ---
>>> This should apply relatively cleanly to 2.6.26.7 source code too.
>>> [...]
>>
>> I've finished my business trip and tested that patch for more than an
>> hour and it works. The test is still running now.
>>
>> But it seems there still has a potential problem: we used ticket lock
>> for write_lock(), and if there are so many write_lock() occurred, is
>> 256 ticket enough for 64 or even more cores to avoiding overflow?
>> Since is we try to write_unlock() and there's already write_lock()
>> waiting we'll only adding current ticket.
>
> This is OK, since each core can issue at most one (blocking) write_lock(),
> and we have only 64 cores. Future >256 core machines will be based on
> TILE-Gx anyway, which doesn't have the 256-core limit since it doesn't use
> the spinlock_32.c implementation.
>
> --
> Chris Metcalf, Tilera Corp.
> http://www.tilera.com
>
>
Say, if core A try to write_lock() rwlock and current_ticket_ is 0 and
it write next_ticket_ to 1, when it processing the lock, core B try to
write_lock() again and write next_ticket_ to 2, then when A
write_unlock() it seen that (current_ticket_+1) is not equal to
next_ticket_, so it increment current_ticket_, and core B get the
lock. If core A try write_lock again before core B write_unlock, it
will increment next_ticket_ to 3. And so on.
This may rarely happened, I've tested it yesterday for several hours
it goes very well under pressure.
--
Cyberman Wu
http://www.meganovo.com
^ permalink raw reply
* Re: [PATCH] via-rhine: hardware VLAN support
From: Jesse Gross @ 2010-11-23 2:02 UTC (permalink / raw)
To: Roger Luethi; +Cc: netdev, David S. Miller
In-Reply-To: <20101121131756.GA18509@core.hellgate.ch>
On Sun, Nov 21, 2010 at 5:17 AM, Roger Luethi <rl@hellgate.ch> wrote:
> On Mon, 08 Nov 2010 12:53:57 -0800, Jesse Gross wrote:
>> On Mon, Nov 8, 2010 at 8:21 AM, Roger Luethi <rl@hellgate.ch> wrote:
>> > On Fri, 05 Nov 2010 11:31:56 -0700, Jesse Gross wrote:
>> > Can you point me to a driver that has been switched to use the new methods
>> > already? Is there some other form of documentation?
>>
>> bnx2 is an example of a driver that has been converted. The commit
>> that actually made the change was
>> 7d0fd2117e3d0550d7987b3aff2bfbc0244cf7c6, which should highlight the
>> differences. A key point is that drivers should no longer reference
>> vlan groups at all.
>
> bnx2 does not support hardware VLAN filters, but ixgbe does (converted by
> commit f62bbb5e62c6e4a91fb222d22bc46e8d4d7e59ef). ixgbe keeps a list of
> configured VLANs in a device private data structure (active_vlans). Is that
> the model to follow?
Yes, that's right. The driver should store whatever information it
requires to manage the CAM or restore the state after a board reset.
^ permalink raw reply
* Re: possible kernel oops from user MSS
From: Li Yewang @ 2010-11-23 2:48 UTC (permalink / raw)
To: David Miller; +Cc: mzhang, netdev
In-Reply-To: <20101112.152607.193708973.davem@davemloft.net>
At 2010-11-13 7:26, David Miller wrote:
> From: Min Zhang<mzhang@mvista.com>
> Date: Fri, 12 Nov 2010 14:59:58 -0800
>
>> Regarding commit 7a1abd08d52fdeddb3e9a5a33f2f15cc6a5674d2 ("tcp:
>> Increase TCP_MAXSEG socket option minimum"). What is the reason
>> TCP_MAXSEG minimum be 64? Isn't the exact be 40 which is
>> TCPOLEN_MD5SIG_ALIGNED(20) + TCPOLEN_TSTAMP_ALIGNED(12) + 8?
>>
>> Or is it better to use TCP_MIN_MSS from tcp.h:
>>
>> /* Minimal accepted MSS. It is (60+60+8) - (20+20). */
>> #define TCP_MIN_MSS 88U
>
> I suppose TCP_MIN_MSS would be better to use, I'll make that
> change, thanks.
David, do you have plan to fix this bug using TCP_MIN_MSS?
^ permalink raw reply
* Re: possible kernel oops from user MSS
From: David Miller @ 2010-11-23 2:59 UTC (permalink / raw)
To: lyw; +Cc: mzhang, netdev
In-Reply-To: <4CEB2B8E.3090904@cn.fujitsu.com>
From: Li Yewang <lyw@cn.fujitsu.com>
Date: Tue, 23 Nov 2010 10:48:46 +0800
>
>
> At 2010-11-13 7:26, David Miller wrote:
>> From: Min Zhang<mzhang@mvista.com>
>> Date: Fri, 12 Nov 2010 14:59:58 -0800
>>
>>> Regarding commit 7a1abd08d52fdeddb3e9a5a33f2f15cc6a5674d2 ("tcp:
>>> Increase TCP_MAXSEG socket option minimum"). What is the reason
>>> TCP_MAXSEG minimum be 64? Isn't the exact be 40 which is
>>> TCPOLEN_MD5SIG_ALIGNED(20) + TCPOLEN_TSTAMP_ALIGNED(12) + 8?
>>>
>>> Or is it better to use TCP_MIN_MSS from tcp.h:
>>>
>>> /* Minimal accepted MSS. It is (60+60+8) - (20+20). */
>>> #define TCP_MIN_MSS 88U
>>
>> I suppose TCP_MIN_MSS would be better to use, I'll make that
>> change, thanks.
>
> David, do you have plan to fix this bug using TCP_MIN_MSS?
I will, it's deep in my backlog and pretty low priority right now.
^ permalink raw reply
* RE: ixgbe dump
From: Skidmore, Donald C @ 2010-11-23 3:31 UTC (permalink / raw)
To: Yinghai Lu, Kirsher, Jeffrey T; +Cc: Brandeburg, Jesse, David Miller, NetDev
In-Reply-To: <AANLkTi=Esp=y2ci=RrCeXYVaxnbrJY3NXpaBgPOBqc7p@mail.gmail.com>
Hi Yinghai,
I was hoping we could have had this patch pushed upstream sooner, but we have quite a few in our internal queue right now.
If this doesn't solve your issue please let me know.
Thanks,
-Don Skidmore <donald.c.skidmore@intel.com>
After freeing the rings we were not zeroing out the ring count values.
This patch now clears these counts correctly.
Reported-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Don Skidmore <donald.c.skidmore@intel.com>
---
drivers/net/ixgbe/ixgbe_main.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/drivers/net/ixgbe/ixgbe_main.c b/drivers/net/ixgbe/ixgbe_main.c
index fbad4d8..eee0b29 100644
--- a/drivers/net/ixgbe/ixgbe_main.c
+++ b/drivers/net/ixgbe/ixgbe_main.c
@@ -4771,6 +4771,9 @@ void ixgbe_clear_interrupt_scheme(struct ixgbe_adapter *adapter)
adapter->rx_ring[i] = NULL;
}
+ adapter->num_tx_queues = 0;
+ adapter->num_rx_queues = 0;
+
ixgbe_free_q_vectors(adapter);
ixgbe_reset_interrupt_capability(adapter);
}
>-----Original Message-----
>From: yhlu.kernel@gmail.com [mailto:yhlu.kernel@gmail.com] On Behalf Of
>Yinghai Lu
>Sent: Monday, November 22, 2010 3:28 PM
>To: Kirsher, Jeffrey T
>Cc: Skidmore, Donald C; Brandeburg, Jesse; David Miller; NetDev
>Subject: Re: ixgbe dump
>
>On Mon, Nov 22, 2010 at 3:22 PM, Jeff Kirsher
><jeffrey.t.kirsher@intel.com> wrote:
>>
>> It is not posted yet. Don got the patch to our testers and they are
>> doing a quick validation on the patch before I post it to netdev.
>>
>> I can send you the patch, so that you can assist in letting us know if
>> it resolves the issue.
>
>sure. please send that to me.
>
>Thanks
^ permalink raw reply related
* [PATCH 1/3] decnet: Move to staging
From: Ben Hutchings @ 2010-11-23 3:51 UTC (permalink / raw)
To: David Miller, Greg Kroah-Hartman; +Cc: netdev, devel, Debian kernel maintainers
Recent review has revealed several bugs in obscure protocol
implementations that can be exploited by local users for denial of
service or privilege escalation.
The decnet protocol (PF_DECnet) is unmaintained. Since 2.6.12-rc2 the
only changes appear to be adjustments for net API changes and fixes
for bugs found by inspection.
This protocol generally should not be enabled by distributions, since
the cost of a security flaw affecting all installed systems presumably
outweighs the benefit to the few (if any) legitimate users.
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
---
drivers/staging/Kconfig | 2 ++
net/Kconfig | 2 --
net/decnet/Kconfig | 3 +++
3 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/Kconfig b/drivers/staging/Kconfig
index 5eafdf4..dd94cb2 100644
--- a/drivers/staging/Kconfig
+++ b/drivers/staging/Kconfig
@@ -175,5 +175,7 @@ source "drivers/staging/intel_sst/Kconfig"
source "drivers/staging/speakup/Kconfig"
+source "net/decnet/Kconfig"
+
endif # !STAGING_EXCLUDE_BUILD
endif # STAGING
diff --git a/net/Kconfig b/net/Kconfig
index 55fd82e..9e4fc29 100644
--- a/net/Kconfig
+++ b/net/Kconfig
@@ -186,7 +186,6 @@ config BRIDGE_NETFILTER
source "net/netfilter/Kconfig"
source "net/ipv4/netfilter/Kconfig"
source "net/ipv6/netfilter/Kconfig"
-source "net/decnet/netfilter/Kconfig"
source "net/bridge/netfilter/Kconfig"
endif
@@ -201,7 +200,6 @@ source "net/802/Kconfig"
source "net/bridge/Kconfig"
source "net/dsa/Kconfig"
source "net/8021q/Kconfig"
-source "net/decnet/Kconfig"
source "net/llc/Kconfig"
source "net/ipx/Kconfig"
source "drivers/net/appletalk/Kconfig"
diff --git a/net/decnet/Kconfig b/net/decnet/Kconfig
index 7914fd6..9d17166 100644
--- a/net/decnet/Kconfig
+++ b/net/decnet/Kconfig
@@ -41,3 +41,6 @@ config DECNET_ROUTER
See <file:Documentation/networking/decnet.txt> for more information.
+if NETFILTER
+source "net/decnet/netfilter/Kconfig"
+endif
--
1.7.2.3
^ permalink raw reply related
* [PATCH 2/3] econet: Move to staging
From: Ben Hutchings @ 2010-11-23 3:52 UTC (permalink / raw)
To: David Miller, Greg Kroah-Hartman; +Cc: netdev, devel, Debian kernel maintainers
Recent review has revealed several bugs in obscure protocol
implementations that can be exploited by local users for denial of
service or privilege escalation.
The econet protocol (PF_ECONET) is unmaintained. There appear to be
no published applications for it, and it has never progressed beyond
'experimental' status.
This protocol generally should not be enabled by distributions, since
the cost of a security flaw affecting all installed systems presumably
outweighs the benefit to the few (if any) legitimate users.
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
---
drivers/staging/Kconfig | 2 ++
net/Kconfig | 1 -
2 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/staging/Kconfig b/drivers/staging/Kconfig
index dd94cb2..a9dd984 100644
--- a/drivers/staging/Kconfig
+++ b/drivers/staging/Kconfig
@@ -177,5 +177,7 @@ source "drivers/staging/speakup/Kconfig"
source "net/decnet/Kconfig"
+source "net/econet/Kconfig"
+
endif # !STAGING_EXCLUDE_BUILD
endif # STAGING
diff --git a/net/Kconfig b/net/Kconfig
index 9e4fc29..059c9f1 100644
--- a/net/Kconfig
+++ b/net/Kconfig
@@ -205,7 +205,6 @@ source "net/ipx/Kconfig"
source "drivers/net/appletalk/Kconfig"
source "net/x25/Kconfig"
source "net/lapb/Kconfig"
-source "net/econet/Kconfig"
source "net/wanrouter/Kconfig"
source "net/phonet/Kconfig"
source "net/ieee802154/Kconfig"
--
1.7.2.3
^ permalink raw reply related
* [PATCH 3/3] x25: Move to staging
From: Ben Hutchings @ 2010-11-23 3:55 UTC (permalink / raw)
To: Andrew Hendry, David Miller, Greg Kroah-Hartman
Cc: netdev, devel, Debian kernel maintainers, linux-x25
Recent review has revealed several bugs in obscure protocol
implementations that can be exploited by local users for denial of
service or privilege escalation.
The x25 protocol (PF_X25) receives only 'odd fixes'. There appear to
be no published applications for it, and it has never progressed
beyond 'experimental' status.
This protocol generally should not be enabled by distributions, since
the cost of a security flaw affecting all installed systems presumably
outweighs the benefit to the few (if any) legitimate users.
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
---
I'm somewhat less sure about this one; maybe it's improving? But there
is little enough sign of any usefulness after 10 years.
There are several X25 dependencies that presumably should be moved too.
Ben.
drivers/staging/Kconfig | 2 ++
net/Kconfig | 1 -
2 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/staging/Kconfig b/drivers/staging/Kconfig
index a9dd984..1347242 100644
--- a/drivers/staging/Kconfig
+++ b/drivers/staging/Kconfig
@@ -179,5 +179,7 @@ source "net/decnet/Kconfig"
source "net/econet/Kconfig"
+source "net/x25/Kconfig"
+
endif # !STAGING_EXCLUDE_BUILD
endif # STAGING
diff --git a/net/Kconfig b/net/Kconfig
index 059c9f1..1d396ba 100644
--- a/net/Kconfig
+++ b/net/Kconfig
@@ -203,7 +203,6 @@ source "net/8021q/Kconfig"
source "net/llc/Kconfig"
source "net/ipx/Kconfig"
source "drivers/net/appletalk/Kconfig"
-source "net/x25/Kconfig"
source "net/lapb/Kconfig"
source "net/wanrouter/Kconfig"
source "net/phonet/Kconfig"
--
1.7.2.3
^ permalink raw reply related
* Re: ixgbe dump
From: Yinghai Lu @ 2010-11-23 4:15 UTC (permalink / raw)
To: Skidmore, Donald C
Cc: Kirsher, Jeffrey T, Brandeburg, Jesse, David Miller, NetDev
In-Reply-To: <29F4ED941D916B48B88B4D2A4F3D1B9C01CC08FBCF@orsmsx509.amr.corp.intel.com>
On Mon, Nov 22, 2010 at 7:31 PM, Skidmore, Donald C
<donald.c.skidmore@intel.com> wrote:
>
> Hi Yinghai,
>
> I was hoping we could have had this patch pushed upstream sooner, but we have quite a few in our internal queue right now.
>
> If this doesn't solve your issue please let me know.
>
> Thanks,
> -Don Skidmore <donald.c.skidmore@intel.com>
>
>
>
>
> After freeing the rings we were not zeroing out the ring count values.
> This patch now clears these counts correctly.
>
> Reported-by: Yinghai Lu <yinghai@kernel.org>
> Signed-off-by: Don Skidmore <donald.c.skidmore@intel.com>
> ---
>
> drivers/net/ixgbe/ixgbe_main.c | 3 +++
> 1 files changed, 3 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/net/ixgbe/ixgbe_main.c b/drivers/net/ixgbe/ixgbe_main.c
> index fbad4d8..eee0b29 100644
> --- a/drivers/net/ixgbe/ixgbe_main.c
> +++ b/drivers/net/ixgbe/ixgbe_main.c
> @@ -4771,6 +4771,9 @@ void ixgbe_clear_interrupt_scheme(struct ixgbe_adapter *adapter)
> adapter->rx_ring[i] = NULL;
> }
>
> + adapter->num_tx_queues = 0;
> + adapter->num_rx_queues = 0;
> +
> ixgbe_free_q_vectors(adapter);
> ixgbe_reset_interrupt_capability(adapter);
> }
OK, that fix the problem.
Thanks
Yinghai
^ permalink raw reply
* RE: ixgbe dump
From: Skidmore, Donald C @ 2010-11-23 4:18 UTC (permalink / raw)
To: Yinghai Lu; +Cc: Kirsher, Jeffrey T, Brandeburg, Jesse, David Miller, NetDev
In-Reply-To: <AANLkTi=ceFYmLuqYhWxyoQ2A3Wev6Dw7V2U+sc-D8d9_@mail.gmail.com>
>-----Original Message-----
>From: yhlu.kernel@gmail.com [mailto:yhlu.kernel@gmail.com] On Behalf Of
>Yinghai Lu
>Sent: Monday, November 22, 2010 8:16 PM
>To: Skidmore, Donald C
>Cc: Kirsher, Jeffrey T; Brandeburg, Jesse; David Miller; NetDev
>Subject: Re: ixgbe dump
>
>On Mon, Nov 22, 2010 at 7:31 PM, Skidmore, Donald C
><donald.c.skidmore@intel.com> wrote:
>>
>> Hi Yinghai,
>>
>> I was hoping we could have had this patch pushed upstream sooner, but we
>have quite a few in our internal queue right now.
>>
>> If this doesn't solve your issue please let me know.
>>
>> Thanks,
>> -Don Skidmore <donald.c.skidmore@intel.com>
>>
>>
>>
>>
>> After freeing the rings we were not zeroing out the ring count values.
>> This patch now clears these counts correctly.
>>
>> Reported-by: Yinghai Lu <yinghai@kernel.org>
>> Signed-off-by: Don Skidmore <donald.c.skidmore@intel.com>
>> ---
>>
>> drivers/net/ixgbe/ixgbe_main.c | 3 +++
>> 1 files changed, 3 insertions(+), 0 deletions(-)
>>
>> diff --git a/drivers/net/ixgbe/ixgbe_main.c
>b/drivers/net/ixgbe/ixgbe_main.c
>> index fbad4d8..eee0b29 100644
>> --- a/drivers/net/ixgbe/ixgbe_main.c
>> +++ b/drivers/net/ixgbe/ixgbe_main.c
>> @@ -4771,6 +4771,9 @@ void ixgbe_clear_interrupt_scheme(struct
>ixgbe_adapter *adapter)
>> adapter->rx_ring[i] = NULL;
>> }
>>
>> + adapter->num_tx_queues = 0;
>> + adapter->num_rx_queues = 0;
>> +
>> ixgbe_free_q_vectors(adapter);
>> ixgbe_reset_interrupt_capability(adapter);
>> }
>
>OK, that fix the problem.
>
>Thanks
>
>Yinghai
That great to hear. Hopefully we will be able to get the patch submitted soon.
Thanks,
-Don
^ permalink raw reply
* Re: [PATCH 1/3] decnet: Move to staging
From: Stephen Hemminger @ 2010-11-23 4:31 UTC (permalink / raw)
To: Ben Hutchings
Cc: David Miller, Greg Kroah-Hartman, netdev, devel,
Debian kernel maintainers
In-Reply-To: <1290484313.6770.1328.camel@localhost>
On Tue, 23 Nov 2010 03:51:53 +0000
Ben Hutchings <ben@decadent.org.uk> wrote:
> Recent review has revealed several bugs in obscure protocol
> implementations that can be exploited by local users for denial of
> service or privilege escalation.
>
> The decnet protocol (PF_DECnet) is unmaintained. Since 2.6.12-rc2 the
> only changes appear to be adjustments for net API changes and fixes
> for bugs found by inspection.
>
> This protocol generally should not be enabled by distributions, since
> the cost of a security flaw affecting all installed systems presumably
> outweighs the benefit to the few (if any) legitimate users.
>
> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
NAK there are still users and stuff does get fixed.
If you don't like it then disable it from config.
--
^ permalink raw reply
* Re: [PATCH 3/3] x25: Move to staging
From: Stephen Hemminger @ 2010-11-23 4:31 UTC (permalink / raw)
To: Ben Hutchings
Cc: Andrew Hendry, David Miller, Greg Kroah-Hartman, netdev, devel,
Debian kernel maintainers, linux-x25
In-Reply-To: <1290484528.6770.1336.camel@localhost>
On Tue, 23 Nov 2010 03:55:28 +0000
Ben Hutchings <ben@decadent.org.uk> wrote:
> Recent review has revealed several bugs in obscure protocol
> implementations that can be exploited by local users for denial of
> service or privilege escalation.
>
> The x25 protocol (PF_X25) receives only 'odd fixes'. There appear to
> be no published applications for it, and it has never progressed
> beyond 'experimental' status.
>
> This protocol generally should not be enabled by distributions, since
> the cost of a security flaw affecting all installed systems presumably
> outweighs the benefit to the few (if any) legitimate users.
>
> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
> ---
> I'm somewhat less sure about this one; maybe it's improving? But there
> is little enough sign of any usefulness after 10 years.
>
> There are several X25 dependencies that presumably should be moved too.
No. If you don't like it then don't enable it.
^ permalink raw reply
* Re: [PATCH 2/3] econet: Move to staging
From: Stephen Hemminger @ 2010-11-23 4:32 UTC (permalink / raw)
To: Ben Hutchings
Cc: David Miller, Greg Kroah-Hartman, netdev, devel,
Debian kernel maintainers
In-Reply-To: <1290484348.6770.1329.camel@localhost>
On Tue, 23 Nov 2010 03:52:28 +0000
Ben Hutchings <ben@decadent.org.uk> wrote:
> Recent review has revealed several bugs in obscure protocol
> implementations that can be exploited by local users for denial of
> service or privilege escalation.
>
> The econet protocol (PF_ECONET) is unmaintained. There appear to be
> no published applications for it, and it has never progressed beyond
> 'experimental' status.
>
> This protocol generally should not be enabled by distributions, since
> the cost of a security flaw affecting all installed systems presumably
> outweighs the benefit to the few (if any) legitimate users.
>
> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
This I agree with. Probably the Arcnet devices as well.
Most distro's don't enable it anyway.
^ permalink raw reply
* Re: [PATCH 3/3] x25: Move to staging
From: Andrew Hendry @ 2010-11-23 5:05 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Ben Hutchings, David Miller, Greg Kroah-Hartman, netdev, devel,
Debian kernel maintainers, linux-x25
In-Reply-To: <20101122203155.27534f3b@nehalam>
There are users of linux X.25 for production environments, please don't..
It works well enough, there have been some X.25 over TCP bits of code
floating around the Internet and mailing lists.
There is an x25 loopback device on sourceforge using tuntap which I
have been using to test slowly removing the bkls.
Regards,
Andrew.
On Tue, Nov 23, 2010 at 3:31 PM, Stephen Hemminger
<shemminger@vyatta.com> wrote:
> On Tue, 23 Nov 2010 03:55:28 +0000
> Ben Hutchings <ben@decadent.org.uk> wrote:
>
>> Recent review has revealed several bugs in obscure protocol
>> implementations that can be exploited by local users for denial of
>> service or privilege escalation.
>>
>> The x25 protocol (PF_X25) receives only 'odd fixes'. There appear to
>> be no published applications for it, and it has never progressed
>> beyond 'experimental' status.
>>
>> This protocol generally should not be enabled by distributions, since
>> the cost of a security flaw affecting all installed systems presumably
>> outweighs the benefit to the few (if any) legitimate users.
>>
>> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
>> ---
>> I'm somewhat less sure about this one; maybe it's improving? But there
>> is little enough sign of any usefulness after 10 years.
>>
>> There are several X25 dependencies that presumably should be moved too.
>
> No. If you don't like it then don't enable it.
>
^ permalink raw reply
* Re: [PATCH 1/3] decnet: Move to staging
From: David Miller @ 2010-11-23 5:19 UTC (permalink / raw)
To: shemminger; +Cc: ben, gregkh, netdev, devel, debian-kernel
In-Reply-To: <20101122203131.7cbd604b@nehalam>
From: Stephen Hemminger <shemminger@vyatta.com>
Date: Mon, 22 Nov 2010 20:31:31 -0800
> On Tue, 23 Nov 2010 03:51:53 +0000
> Ben Hutchings <ben@decadent.org.uk> wrote:
>
>> Recent review has revealed several bugs in obscure protocol
>> implementations that can be exploited by local users for denial of
>> service or privilege escalation.
>>
>> The decnet protocol (PF_DECnet) is unmaintained. Since 2.6.12-rc2 the
>> only changes appear to be adjustments for net API changes and fixes
>> for bugs found by inspection.
>>
>> This protocol generally should not be enabled by distributions, since
>> the cost of a security flaw affecting all installed systems presumably
>> outweighs the benefit to the few (if any) legitimate users.
>>
>> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
>
> NAK there are still users and stuff does get fixed.
> If you don't like it then disable it from config.
Seriously, I can't even remember a bonifides security flaw in decnet
being found recently and in fact the decnet stack is very well written
code.
^ permalink raw reply
* [PATCH net-next] sctp: kill unused macro definition
From: Shan Wei @ 2010-11-23 9:00 UTC (permalink / raw)
To: Vlad Yasevich, David Miller; +Cc: linux-sctp, Network-Maillist
These macros have been existed for several years since v2.6.12-rc2.
But they never be used. So remove them now.
Signed-off-by: Shan Wei <shanwei@cn.fujitsu.com>
---
include/net/sctp/constants.h | 14 --------------
1 files changed, 0 insertions(+), 14 deletions(-)
diff --git a/include/net/sctp/constants.h b/include/net/sctp/constants.h
index 6390884..c70d8cc 100644
--- a/include/net/sctp/constants.h
+++ b/include/net/sctp/constants.h
@@ -61,7 +61,6 @@ enum { SCTP_DEFAULT_INSTREAMS = SCTP_MAX_STREAM };
* symbols. CIDs are dense through SCTP_CID_BASE_MAX.
*/
#define SCTP_CID_BASE_MAX SCTP_CID_SHUTDOWN_COMPLETE
-#define SCTP_CID_MAX SCTP_CID_ASCONF_ACK
#define SCTP_NUM_BASE_CHUNK_TYPES (SCTP_CID_BASE_MAX + 1)
@@ -86,9 +85,6 @@ typedef enum {
} sctp_event_t;
-#define SCTP_EVENT_T_MAX SCTP_EVENT_T_PRIMITIVE
-#define SCTP_EVENT_T_NUM (SCTP_EVENT_T_MAX + 1)
-
/* As a convenience for the state machine, we append SCTP_EVENT_* and
* SCTP_ULP_* to the list of possible chunks.
*/
@@ -162,9 +158,6 @@ SCTP_SUBTYPE_CONSTRUCTOR(PRIMITIVE, sctp_event_primitive_t, primitive)
- (unsigned long)(c->chunk_hdr)\
- sizeof(sctp_data_chunk_t)))
-#define SCTP_MAX_ERROR_CAUSE SCTP_ERROR_NONEXIST_IP
-#define SCTP_NUM_ERROR_CAUSE 10
-
/* Internal error codes */
typedef enum {
@@ -266,7 +259,6 @@ enum { SCTP_ARBITRARY_COOKIE_ECHO_LEN = 200 };
#define SCTP_TSN_MAP_INITIAL BITS_PER_LONG
#define SCTP_TSN_MAP_INCREMENT SCTP_TSN_MAP_INITIAL
#define SCTP_TSN_MAP_SIZE 4096
-#define SCTP_TSN_MAX_GAP 65535
/* We will not record more than this many duplicate TSNs between two
* SACKs. The minimum PMTU is 576. Remove all the headers and there
@@ -301,9 +293,6 @@ enum { SCTP_MAX_GABS = 16 };
#define SCTP_CLOCK_GRANULARITY 1 /* 1 jiffy */
-#define SCTP_DEF_MAX_INIT 6
-#define SCTP_DEF_MAX_SEND 10
-
#define SCTP_DEFAULT_COOKIE_LIFE (60 * 1000) /* 60 seconds */
#define SCTP_DEFAULT_MINWINDOW 1500 /* default minimum rwnd size */
@@ -317,9 +306,6 @@ enum { SCTP_MAX_GABS = 16 };
*/
#define SCTP_DEFAULT_MINSEGMENT 512 /* MTU size ... if no mtu disc */
#define SCTP_HOW_MANY_SECRETS 2 /* How many secrets I keep */
-#define SCTP_HOW_LONG_COOKIE_LIVE 3600 /* How many seconds the current
- * secret will live?
- */
#define SCTP_SECRET_SIZE 32 /* Number of octets in a 256 bits. */
#define SCTP_SIGNATURE_SIZE 20 /* size of a SLA-1 signature */
--
1.6.3.3
^ permalink raw reply related
* Draft manpage for recvmmsg
From: Andi Kleen @ 2010-11-23 10:15 UTC (permalink / raw)
To: linux-man-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
acme-H+wXaHxf7aLQT0dZR+AlfA
Here's a draft manpage for recvmmsg(2), which is one
of the last undocumented syscalls currently.
Please review and comment.
-Andi
.TH RECVMMSG 2 2010-11-23 "Linux" "Linux Programmer's Manual"
.SH NAME
recvmmsg \- receive multiple messages on a socket
.SH SYNOPSIS
.BI "#include <sys/socket.h>"
.br
.BI "int recvmmsg(int " fd ", struct mmsghdr *" mmsghdr \
", unsigned int " vlen ","
.br
.BI " unsigned int " flags ", struct timespec *" timeout ");"
.SH DESCRIPTION
The
.B recvmmsg
system call receives multiple messages in a socket.
It acts similar to
.B recvmsg(2),
but allows to batch multiple receive operations into a single syscall.
In addition it support an explicit timeout.
.B fd
is the file descriptor of the socket to receive data from.
.B mmsghdr
is a pointer to an array with length
.B vlen
of
.I mmsghdr
structures.
.I struct mmsg
is defined in
.I sys/socket.h
as:
.in +4n
.nf
struct mmsghdr {
struct msghdr msg_hdr; /* Message header */
unsigned int msg_len; /* Number of received bytes for header */
};
.fi
.in
.PP
.B msg_hdr
is a struct
.I msghdr
as described in
.I recvmsg(2).
.B msg_len
is the number of bytes returned for the message in the entry.
This field has the same value as the return value of a single
.I recvmsg(2)
on the header.
.B flags
contains flags ored together. The flags are the same
as documented for
.I recvmsg(2).
The additional
.B MSG_WAITFORONE
turns one
.I MSG_DONTWAIT
after the first message has been received.
.B timeout
points to a
.I struct timespec
(see
.I clock_gettime(2)
)
defining a timeout for receiving, or
.I NULL
for no timeout. When the timeout expires
.I recvmmsg
returns.
.SH RETURN VALUE
.I recvmmsg
returns the number of messages received in
.I mmsghdr
or
-1
when an error occurs. The
.I msg_len
members of
.I mmsghdr
are updated for each received message,
in addition to other fields in the msg_hdr for each message,
as described in
.I recvmsg(2).
.SH SEE ALSO
.B recvmsg(2),
.B sendmsg(2),
.B socket(7),
.B socket(2),
.B clock_gettime(2)
.SH VERSIONS
The
.I recvmmsg
syscall was added with kernel 2.6.32.
Support in glibc was added with 2.6.12.
On earlier glibcs the function can be called
manually using
.I syscall(2).
--
ak-VuQAYsv1563Yd54FQh9/CA@public.gmane.org -- Speaking for myself only.
--
To unsubscribe from this list: send the line "unsubscribe linux-man" 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
* [PATCH NEXT] qlcnic: avoid using reset_devices as it may become obsolete.
From: Amit Kumar Salecha @ 2010-11-23 11:25 UTC (permalink / raw)
To: davem; +Cc: netdev, ameen.rahman, anirban.chakraborty, Rajesh Borundia
From: Rajesh Borundia <rajesh.borundia@qlogic.com>
In kdump environment do not depend upon reset_devices parameter
to reset the pci function as this parameter may become obsolete.
Instead use an adapter specific mechanism to determine if the pci
function needs to be reset.
Per function refcount is maintained in driver, which is set in probe
and reset in remove handler of adapter. If the probe detects the count
as non zero then reset the function.
Signed-off-by: Rajesh Borundia <rajesh.borundia@qlogic.com>
Signed-off-by: Amit Kumar Salecha <amit.salecha@qlogic.com>
---
drivers/net/qlcnic/qlcnic.h | 1 +
drivers/net/qlcnic/qlcnic_ctx.c | 4 +++-
drivers/net/qlcnic/qlcnic_hdr.h | 2 +-
drivers/net/qlcnic/qlcnic_main.c | 5 +++++
4 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/net/qlcnic/qlcnic.h b/drivers/net/qlcnic/qlcnic.h
index 56f54ff..9513a83 100644
--- a/drivers/net/qlcnic/qlcnic.h
+++ b/drivers/net/qlcnic/qlcnic.h
@@ -923,6 +923,7 @@ struct qlcnic_ipaddr {
#define QLCNIC_MACSPOOF 0x200
#define QLCNIC_MAC_OVERRIDE_DISABLED 0x400
#define QLCNIC_PROMISC_DISABLED 0x800
+#define QLCNIC_NEED_FLR 0x1000
#define QLCNIC_IS_MSI_FAMILY(adapter) \
((adapter)->flags & (QLCNIC_MSI_ENABLED | QLCNIC_MSIX_ENABLED))
diff --git a/drivers/net/qlcnic/qlcnic_ctx.c b/drivers/net/qlcnic/qlcnic_ctx.c
index 3ad1f3e..29cbc2a 100644
--- a/drivers/net/qlcnic/qlcnic_ctx.c
+++ b/drivers/net/qlcnic/qlcnic_ctx.c
@@ -480,8 +480,10 @@ int qlcnic_fw_create_ctx(struct qlcnic_adapter *adapter)
{
int err;
- if (reset_devices)
+ if (adapter->flags & QLCNIC_NEED_FLR) {
pci_reset_function(adapter->pdev);
+ adapter->flags &= ~QLCNIC_NEED_FLR;
+ }
err = qlcnic_fw_cmd_create_rx_ctx(adapter);
if (err)
diff --git a/drivers/net/qlcnic/qlcnic_hdr.h b/drivers/net/qlcnic/qlcnic_hdr.h
index 4290b80..566e0e8 100644
--- a/drivers/net/qlcnic/qlcnic_hdr.h
+++ b/drivers/net/qlcnic/qlcnic_hdr.h
@@ -722,7 +722,7 @@ enum {
#define QLCNIC_DEV_NPAR_OPER 1 /* NPAR Operational */
#define QLCNIC_DEV_NPAR_OPER_TIMEO 30 /* Operational time out */
-#define QLC_DEV_CHECK_ACTIVE(VAL, FN) ((VAL) &= (1 << (FN * 4)))
+#define QLC_DEV_CHECK_ACTIVE(VAL, FN) ((VAL) & (1 << (FN * 4)))
#define QLC_DEV_SET_REF_CNT(VAL, FN) ((VAL) |= (1 << (FN * 4)))
#define QLC_DEV_CLR_REF_CNT(VAL, FN) ((VAL) &= ~(1 << (FN * 4)))
#define QLC_DEV_SET_RST_RDY(VAL, FN) ((VAL) |= (1 << (FN * 4)))
diff --git a/drivers/net/qlcnic/qlcnic_main.c b/drivers/net/qlcnic/qlcnic_main.c
index a3dcd04..899df5a 100644
--- a/drivers/net/qlcnic/qlcnic_main.c
+++ b/drivers/net/qlcnic/qlcnic_main.c
@@ -1485,6 +1485,7 @@ qlcnic_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
uint8_t revision_id;
uint8_t pci_using_dac;
char brd_name[QLCNIC_MAX_BOARD_NAME_LEN];
+ u32 val;
err = pci_enable_device(pdev);
if (err)
@@ -1546,6 +1547,10 @@ qlcnic_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
if (err)
goto err_out_iounmap;
+ val = QLCRD32(adapter, QLCNIC_CRB_DRV_ACTIVE);
+ if (QLC_DEV_CHECK_ACTIVE(val, adapter->portnum))
+ adapter->flags |= QLCNIC_NEED_FLR;
+
err = adapter->nic_ops->start_firmware(adapter);
if (err) {
dev_err(&pdev->dev, "Loading fw failed.Please Reboot\n");
--
1.7.3.2
^ permalink raw reply related
* Re: Draft manpage for recvmmsg
From: Arnaldo Carvalho de Melo @ 2010-11-23 12:36 UTC (permalink / raw)
To: Andi Kleen
Cc: linux-man-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20101123101551.GA20431-u0/ZJuX+froe6aEkudXLsA@public.gmane.org>
Em Tue, Nov 23, 2010 at 11:15:51AM +0100, Andi Kleen escreveu:
>
> Here's a draft manpage for recvmmsg(2), which is one
> of the last undocumented syscalls currently.
> Please review and comment.
Looks ok, thanks for writing it.
- Arnaldo
--
To unsubscribe from this list: send the line "unsubscribe linux-man" 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
* net-2.6 [Patch 1/1][BUG-FIX] dccp: advancing the Ack window
From: Gerrit Renker @ 2010-11-23 12:36 UTC (permalink / raw)
To: David Miller; +Cc: dccp, netdev
Dave,
please can you consider the following bug fix (applies on both net-2.6 and
net-next-2.6). I have no other dccp patches this week -- the second one that
follows is for the test tree only and is meant for RFC.
Best regards
Gerrit
(also on git://eden-feed.erg.abdn.ac.uk/net-next-2.6 [subtree 'dccp'])
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Patch / Fix <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
dccp: fix error in updating the GAR
This fixes a bug in updating the Greatest Acknowledgment number Received (GAR):
the current implementation does not track the greatest received value -
lower values in the range AWL..AWH (RFC 4340, 7.5.1) erase higher ones.
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
---
net/dccp/input.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/net/dccp/input.c
+++ b/net/dccp/input.c
@@ -241,7 +241,8 @@ static int dccp_check_seqno(struct sock
dccp_update_gsr(sk, seqno);
if (dh->dccph_type != DCCP_PKT_SYNC &&
- (ackno != DCCP_PKT_WITHOUT_ACK_SEQ))
+ ackno != DCCP_PKT_WITHOUT_ACK_SEQ &&
+ after48(ackno, dp->dccps_gar))
dp->dccps_gar = ackno;
} else {
unsigned long now = jiffies;
^ permalink raw reply
* dccp-test-tree [RFC][Patch 1/1] dccp: requesting comments re updating ARP/neighbour table state
From: Gerrit Renker @ 2010-11-23 12:44 UTC (permalink / raw)
To: dccp, netdev
In-Reply-To: <20101123123656.GB3915@gerrit.erg.abdn.ac.uk>
I noted that DCCP apparently does not update the neighbour tables in the same
way as TCP (or UDP with MSG_CONFIRM).
This patch adds the missing calls to dst_update(). I would appreciate review
and comments in case I missed something.
DCCP does not have the equivalent of tcp_init_metrics()/tcp_update_metrics().
It seems that this functionality would be more in the CCIDs than in the main
DCCP module (for instance, CCID-3 does not understand ssthresh/cwnd and uses
a different RTT sampling algorithm).
This patch is meant for RFC, not currently for submission. It is in the DCCP
test tree, on
git://eden-feed.erg.abdn.ac.uk/dccp_exp [subtree 'dccp']
>>>>>>>>>>>>>>>>>>>>>>>>> Patch <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
dccp: indicate forward progress of connection to lower layer
This patch implements three cases of indicating forward progress:
1. Peer acknowledging receipt of connection initiation.
This corresponds to the cases where tcp_init_metrics() is called:
* receiving Syn-Ack in response to Syn (tcp_rcv_synsent_state_process),
* receiving Ack to finish the handshake (TCP_SYN_RECV -> TCP_ESTABLISHED);
which in DCCP corresponds to
* receiving Response after Request (dccp_rcv_request_sent_state_process),
* moving from RESPOND/PARTOPEN to OPEN when receiving an Ack/DataAck
(RESPOND) or non-Sync/Reset (PARTOPEN).
The latter does no extra rebuild_header() as in tcp_rcv_state_process(),
since in DCCP an active (client) socket can not become a passive one later,
and since dccp_v{4,6}_request_recv_sock() already talk to the routing
system.
2. Peer advancing GAR (greatest acknowledgment number received).
This is comparable to making forward progress in tcp_ack().
3. Peer acknowledging request to terminate the connection.
This corresponds to TCP teardown -
* receiving Ack-of-Fin in FIN_WAIT1/LAST_ACK (tcp_rcv_state_process),
* entering TIME_WAIT (tcp_time_wait),
and is realized in DCCP when receiving
* a Reset packet with code "Closed" (in response to DCCP-Close),
* a Close packet after sending a CloseReq,
* a Close packet after sending a Close (simultaneous close).
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
---
net/dccp/input.c | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)
--- a/net/dccp/input.c
+++ b/net/dccp/input.c
@@ -71,6 +71,7 @@ static int dccp_rcv_close(struct sock *s
/* fall through */
case DCCP_REQUESTING:
case DCCP_ACTIVE_CLOSEREQ:
+ dst_confirm(__sk_dst_get(sk));
dccp_send_reset(sk, DCCP_RESET_CODE_CLOSED);
dccp_done(sk);
break;
@@ -155,6 +156,8 @@ static void dccp_rcv_reset(struct sock *
/* Queue the equivalent of TCP fin so that dccp_recvmsg exits the loop */
dccp_fin(sk, skb);
+ if (dccp_hdr_reset(skb)->dccph_reset_code == DCCP_RESET_CODE_CLOSED)
+ dst_confirm(__sk_dst_get(sk));
if (err && !sock_flag(sk, SOCK_DEAD))
sk_wake_async(sk, SOCK_WAKE_IO, POLL_ERR);
dccp_time_wait(sk, DCCP_TIME_WAIT, 0);
@@ -242,8 +245,10 @@ static int dccp_check_seqno(struct sock
if (dh->dccph_type != DCCP_PKT_SYNC &&
ackno != DCCP_PKT_WITHOUT_ACK_SEQ &&
- after48(ackno, dp->dccps_gar))
+ after48(ackno, dp->dccps_gar)) {
+ dst_confirm(__sk_dst_get(sk));
dp->dccps_gar = ackno;
+ }
} else {
unsigned long now = jiffies;
/*
@@ -475,6 +480,8 @@ static int dccp_rcv_request_sent_state_p
/* Make sure socket is routed, for correct metrics. */
icsk->icsk_af_ops->rebuild_header(sk);
+ dst_confirm(__sk_dst_get(sk));
+
if (!sock_flag(sk, SOCK_DEAD)) {
sk->sk_state_change(sk);
sk_wake_async(sk, SOCK_WAKE_IO, POLL_OUT);
@@ -556,6 +563,8 @@ static int dccp_rcv_respond_partopen_sta
dp->dccps_syn_rtt = dccp_sample_rtt(sk, 10 * delta);
}
+ dst_confirm(__sk_dst_get(sk));
+
dp->dccps_osr = DCCP_SKB_CB(skb)->dccpd_seq;
dccp_set_state(sk, DCCP_OPEN);
^ permalink raw reply
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