* Re: [Bugme-new] [Bug 15379] New: u32 classifier port range calculation error
From: jamal @ 2010-02-25 3:24 UTC (permalink / raw)
To: Andrew Morton; +Cc: netdev, bugzilla-daemon, bugme-daemon, reinaldoc
In-Reply-To: <20100224145220.da5ec0b0.akpm@linux-foundation.org>
This is expected.
An incoming packet is masked with 0x1FE0 at offset 20 and the
value is compared to 6880. If they match, success.
So between 1-10000, you essentially have some starting at 6880.
And then at a large number prolly around port 15000, you have
a few more. and the pattern repeats etc.
cheers,
jamal
On Wed, 2010-02-24 at 14:52 -0800, Andrew Morton wrote:
> (switched to email. Please respond via emailed reply-to-all, not via the
> bugzilla web interface).
>
> On Tue, 23 Feb 2010 20:56:09 GMT bugzilla-daemon@bugzilla.kernel.org wrote:
>
> > http://bugzilla.kernel.org/show_bug.cgi?id=15379
> >
> > Summary: u32 classifier port range calculation error
> > Product: Networking
> > Version: 2.5
> > Kernel Version: All (2.6.32 tested)
> > Platform: All
> > OS/Version: Linux
> > Tree: Mainline
> > Status: NEW
> > Severity: normal
> > Priority: P1
> > Component: Other
> > AssignedTo: acme@ghostprotocols.net
> > ReportedBy: reinaldoc@gmail.com
> > Regression: No
> >
> >
> > U32 classifier have a problem on mask calculation of IP port range value.
> >
> > To reproduce the problem:
> >
> > ##### MASK CALCULATION FOR PORT RANGE 6880->6911
> >
> > echo "obase=16;(2^13)-32" | bc
> > 1FE0
> >
> > Example:
> >
> > ###### TC SAMPLE RULES
> > tc qdisc del dev eth0 root >/dev/null 2>&1
> >
> > tc qdisc add dev eth0 root handle 1: htb default 1100
> > tc class add dev eth0 root classid 1:1000 htb rate 1000Mbit ceil 1000Mbit
> > tc class add dev eth0 classid 1:1100 parent 1:1000 htb prio 0 rate 999Mbit
> > ceil 999Mbit
> > tc class add dev eth0 classid 1:1200 parent 1:1000 htb prio 0 rate 1Mbit
> > ceil 1Mbit
> >
> > tc filter add dev eth0 protocol ip prio 1 parent 1: u32 flowid 1:1200 match ip
> > dport 6880 0x1FE0
> >
> > ###### STATS CLEAN ** success 0
> > tc -s filter show dev eth0
> > filter parent 1: protocol ip pref 1 u32
> > filter parent 1: protocol ip pref 1 u32 fh 800: ht divisor 1
> > filter parent 1: protocol ip pref 1 u32 fh 800::800 order 2048 key ht 800 bkt 0
> > flowid 1:1200 (rule hit 116 success 0)
> > match 00001ae0/00001fe0 at 20 (success 0 )
> >
> > ###### SENDING PACKETS I
> > # nmap example.ufpa.br -p 1-10000
> >
> > ###### STATS I ** success 32 (OK)
> > # tc -s filter show dev eth0
> > filter parent 1: protocol ip pref 1 u32
> > filter parent 1: protocol ip pref 1 u32 fh 800: ht divisor 1
> > filter parent 1: protocol ip pref 1 u32 fh 800::800 order 2048 key ht 800 bkt 0
> > flowid 1:1200 (rule hit 12676 success 32)
> > match 00001ae0/00001fe0 at 20 (success 32 )
> >
> > ###### SENDING PACKETS II
> > # nmap example.ufpa.br -p 10000-20000
> >
> > ###### STATS II ** success 64 (ERROR) - should not match
> >
> > # tc -s filter show dev eth0
> > filter parent 1: protocol ip pref 1 u32
> > filter parent 1: protocol ip pref 1 u32 fh 800: ht divisor 1
> > filter parent 1: protocol ip pref 1 u32 fh 800::800 order 2048 key ht 800 bkt 0
> > flowid 1:1200 (rule hit 25172 success 64)
> > match 00001ae0/00001fe0 at 20 (success 64 )
> >
> > ###### SENDING PACKETS III
> > # nmap example.ufpa.br -p 20000-30000
> >
> > ###### STATS III ** success 96 (ERROR) - should not match
> >
> > # tc -s filter show dev eth0
> > filter parent 1: protocol ip pref 1 u32
> > filter parent 1: protocol ip pref 1 u32 fh 800: ht divisor 1
> > filter parent 1: protocol ip pref 1 u32 fh 800::800 order 2048 key ht 800 bkt 0
> > flowid 1:1200 (rule hit 43131 success 96)
> > match 00001ae0/00001fe0 at 20 (success 96 )
> >
> > ### End
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [net-next PATCH v5 2/3] sysctl: add proc_do_large_bitmap
From: Cong Wang @ 2010-02-25 3:18 UTC (permalink / raw)
To: Octavian Purdila
Cc: David Miller, Linux Kernel Network Developers,
Linux Kernel Developers, Eric W. Biederman
In-Reply-To: <4B85CFB4.5030908@redhat.com>
Cong Wang wrote:
> Octavian Purdila wrote:
>> On Wednesday 24 February 2010 07:24:00 you wrote:
>>> Octavian Purdila wrote:
>>>> Here is a new version of this patch which fixes both the comma and
>>>> invalid value issues, please give it a try.
>>> Sorry, it is even worse. :(
>>>
>>>> [net-next PATCH v5 2/3] sysctl: add proc_do_large_bitmap
>>>>
>>>> The new function can be used to read/write large bitmaps via /proc. A
>>>> comma separated range format is used for compact output and input
>>>> (e.g. 1,3-4,10-10).
>>> Writing "50000-50100" gets EINVAL, it should be success.
>>> Writing "50000,50100" fails too.
>>>
>>
>> Hmm, they don't fail for me :-/
>>
>>> Please, at least, do some basic testing.
>>>
>>
>> I do test them, I've attached the current test batch I was using.
>>
>> Anyways, today I've noticed that "1,2 3" does not fail and even more
>> importantly the final value is "3".
>> Being that I don't see a way of fixing this without not acknowledging
>> 1,2 even though we will do set these values, I revisited the "1 2 3"
>> issue. And I don't understand why this is actually an issue, we are
>> just being more permissive (i.e. we are allowing as separators both
>> whitespaces and ,).
>>
>>
>
> Oops, after rechecking my test case, it is actually my test case's
> fault. Sorry for this. I will fix my test case and run it again.
>
Hi,
Still a small problem, if I do write(fd, "50000,50100", 12) I will
get a return value of 11, which should mean 11 bytes are written,
however, actually only the first 6 bytes are accepted.
The rest looks better now.
Or am I missing something here? :)
Thanks!
^ permalink raw reply
* [RFC PATCH] accounting for socket backlog
From: Zhu Yi @ 2010-02-25 3:13 UTC (permalink / raw)
To: netdev
Hi,
We got system OOM while running some UDP netperf testing on the loopback
device. The case is multiple senders sent stream UDP packets to a single
receiver via loopback on local host. Of course, the receiver is not able
to handle all the packets in time. But we surprisingly found that these
packets were not discarded due to the receiver's sk->sk_rcvbuf limit.
Instead, they are kept queuing to sk->sk_backlog and finally ate up all
the memory. We believe this is a secure hole that a none privileged user
can crash the system.
The root cause for this problem is, when the receiver is doing
__release_sock() (i.e. after userspace recv, kernel udp_recvmsg ->
skb_free_datagram_locked -> release_sock), it moves skbs from backlog to
sk_receive_queue with the softirq enabled. In the above case, multiple
busy senders will almost make it an endless loop. The skbs in the
backlog end up eat all the system memory.
The patch fixed this problem by adding accounting for the socket
backlog. So that the backlog size can be restricted by protocol's choice
(i.e. UDP).
Signed-off-by: Zhu Yi <yi.zhu@intel.com>
---
diff --git a/include/net/sock.h b/include/net/sock.h
index 3f1a480..2e003b9 100644
--- a/include/net/sock.h
+++ b/include/net/sock.h
@@ -253,6 +253,7 @@ struct sock {
struct {
struct sk_buff *head;
struct sk_buff *tail;
+ atomic_t len;
} sk_backlog;
wait_queue_head_t *sk_sleep;
struct dst_entry *sk_dst_cache;
@@ -583,11 +584,13 @@ static inline void sk_add_backlog(struct sock *sk, struct sk_buff *skb)
sk->sk_backlog.tail->next = skb;
sk->sk_backlog.tail = skb;
}
+ atomic_add(skb->truesize, &sk->sk_backlog.len);
skb->next = NULL;
}
static inline int sk_backlog_rcv(struct sock *sk, struct sk_buff *skb)
{
+ atomic_sub(skb->truesize, &sk->sk_backlog.len);
return sk->sk_backlog_rcv(sk, skb);
}
diff --git a/net/core/sock.c b/net/core/sock.c
index e1f6f22..3b988f2 100644
--- a/net/core/sock.c
+++ b/net/core/sock.c
@@ -1138,6 +1138,7 @@ struct sock *sk_clone(const struct sock *sk, const gfp_t priority)
sock_lock_init(newsk);
bh_lock_sock(newsk);
newsk->sk_backlog.head = newsk->sk_backlog.tail = NULL;
+ atomic_set(&newsk->sk_backlog.len, 0);
atomic_set(&newsk->sk_rmem_alloc, 0);
/*
diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
index f0126fd..e019067 100644
--- a/net/ipv4/udp.c
+++ b/net/ipv4/udp.c
@@ -1372,8 +1372,13 @@ int udp_queue_rcv_skb(struct sock *sk, struct sk_buff *skb)
bh_lock_sock(sk);
if (!sock_owned_by_user(sk))
rc = __udp_queue_rcv_skb(sk, skb);
- else
+ else {
+ if (atomic_read(&sk->sk_backlog.len) >= sk->sk_rcvbuf) {
+ bh_unlock_sock(sk);
+ goto drop;
+ }
sk_add_backlog(sk, skb);
+ }
bh_unlock_sock(sk);
return rc;
^ permalink raw reply related
* Re: [PATCH]: tipc: Fix oops on send prior to entering networked mode
From: Neil Horman @ 2010-02-25 1:42 UTC (permalink / raw)
To: David Miller; +Cc: allan.stephens, netdev, jon.maloy, tipc-discussion
In-Reply-To: <20100224.173436.212403104.davem@davemloft.net>
On Wed, Feb 24, 2010 at 05:34:36PM -0800, David Miller wrote:
> From: "Stephens, Allan" <allan.stephens@windriver.com>
> Date: Wed, 24 Feb 2010 11:05:12 -0800
>
> > Have you tried upgrading your system to use TIPC 1.7.6 (available at
> > http://tipc.sourceforge.net/tipc_linux.html)? This is a significant
> > revised and enhanced version of TIPC that hasn't yet made its way into
> > mainsteam Linux, and seems to be the version-of-choice for most TIPC
> > users. It also appears to avoid a number of the issues that currently
> > exist in TIPC 1.6, including the one caused by the random configuration
> > command you mentioned in your email below.
> >
> > I didn't have a problem with you working on a small patch for TIPC 1.6
> > to get around a limited problem, but I'd hate to see you waste time on
> > fixing issues that have already been addressed in TIPC 1.7.
>
> Why is the TIPC kernel protocol code being developed out of tree
> instead of directly upstream?
>
> Regardless of that, if the code is in the kernel tree and it can be
> OOPS'd, we must fix it.
>
Agreed, with a combination of:
1) The patch which Allan posted to check tipc_net.zone and tipc_local_nodes for
being NULL in tipc_select_node
2) The patch that I asked Allan to extract from the sourceforge package which
adds checks for TIPC_NET_MODE in the appropriate places
3) The patch I posted to close the race in the setting of tipc_mode
we should fix all the oopses I've found so far.
Ideally it would seem what would be most appropriate would be to wholesale
import tipc 1.7.6 from sourceforge to the kernel to get all the fixes that have
gone in there. That seems like its been waiting in the wings for over a year
now.
Neil
^ permalink raw reply
* Re: [PATCH]: tipc: Fix oops on send prior to entering networked mode
From: David Miller @ 2010-02-25 1:38 UTC (permalink / raw)
To: nhorman; +Cc: allan.stephens, netdev, jon.maloy, tipc-discussion
In-Reply-To: <20100224211507.GC15380@hmsreliant.think-freely.org>
From: Neil Horman <nhorman@tuxdriver.com>
Date: Wed, 24 Feb 2010 16:15:07 -0500
> Looking at the 1.7.6 tarball on sourceforge, its dated 10/10/2008,
> so you've basically got a 1.5 year lag between the development
> version and the commited version that distributions are using (and
> counting). I'm sorry, I'm not trying to be crass about this, but
> its rather disconcerting to see that kind of discrepancy between the
> code development point and whats in net-next. It implies that the
> only fix for a tipc problem is a wholesale upgrade of the tipc
> directory in the kernel (since it would seem the sourceforge tipc
> cvs tree has gone unused for a few years).
I'm extremely upset about this.
Especially given the fact that EVERY DAMN TIME there were TIPC
patches posted I applied EVERY DAMN ONE of them, and I did so
in an expediant manner.
So there is zero reason for the TIPC protocol development to not have
occured upstream. I, in fact, facilitated things to work that way in
the smoothest way possible, if only the TIPC developers had obliged.
^ permalink raw reply
* Re: netfilter 00/08: netfilter update
From: Shan Wei @ 2010-02-25 1:36 UTC (permalink / raw)
To: Patrick McHardy; +Cc: davem, netdev, netfilter-devel
In-Reply-To: <20100224174927.16391.59798.sendpatchset@x2.localnet>
Patrick McHardy wrote, at 02/25/2010 01:49 AM:
> Hi Dave,
>
> following is the probably final netfilter update for 2.6.34, containing:
2.6.33 is just released, and Linus Torvalds said that
this merger window period is about ten-to-twelve days.
Is it enough for us to review patch-set with title "IPv6:netfilter: defragment"?
Is there hope to merger this patch-set for 2.6.34?
--
Best Regards
-----
Shan Wei
^ permalink raw reply
* Re: [PATCH]: tipc: Fix oops on send prior to entering networked mode
From: David Miller @ 2010-02-25 1:34 UTC (permalink / raw)
To: allan.stephens; +Cc: nhorman, netdev, jon.maloy, tipc-discussion
In-Reply-To: <29C1DC0826876849BDD9F1C67ABA2943070F1534@ala-mail09.corp.ad.wrs.com>
From: "Stephens, Allan" <allan.stephens@windriver.com>
Date: Wed, 24 Feb 2010 11:05:12 -0800
> Have you tried upgrading your system to use TIPC 1.7.6 (available at
> http://tipc.sourceforge.net/tipc_linux.html)? This is a significant
> revised and enhanced version of TIPC that hasn't yet made its way into
> mainsteam Linux, and seems to be the version-of-choice for most TIPC
> users. It also appears to avoid a number of the issues that currently
> exist in TIPC 1.6, including the one caused by the random configuration
> command you mentioned in your email below.
>
> I didn't have a problem with you working on a small patch for TIPC 1.6
> to get around a limited problem, but I'd hate to see you waste time on
> fixing issues that have already been addressed in TIPC 1.7.
Why is the TIPC kernel protocol code being developed out of tree
instead of directly upstream?
Regardless of that, if the code is in the kernel tree and it can be
OOPS'd, we must fix it.
^ permalink raw reply
* Re: [net-next PATCH v5 2/3] sysctl: add proc_do_large_bitmap
From: Cong Wang @ 2010-02-25 1:17 UTC (permalink / raw)
To: Octavian Purdila
Cc: David Miller, Linux Kernel Network Developers,
Linux Kernel Developers, Eric W. Biederman
In-Reply-To: <201002241402.54122.opurdila@ixiacom.com>
Octavian Purdila wrote:
> On Wednesday 24 February 2010 07:24:00 you wrote:
>> Octavian Purdila wrote:
>>> Here is a new version of this patch which fixes both the comma and
>>> invalid value issues, please give it a try.
>> Sorry, it is even worse. :(
>>
>>> [net-next PATCH v5 2/3] sysctl: add proc_do_large_bitmap
>>>
>>> The new function can be used to read/write large bitmaps via /proc. A
>>> comma separated range format is used for compact output and input
>>> (e.g. 1,3-4,10-10).
>> Writing "50000-50100" gets EINVAL, it should be success.
>> Writing "50000,50100" fails too.
>>
>
> Hmm, they don't fail for me :-/
>
>> Please, at least, do some basic testing.
>>
>
> I do test them, I've attached the current test batch I was using.
>
> Anyways, today I've noticed that "1,2 3" does not fail and even more
> importantly the final value is "3".
>
> Being that I don't see a way of fixing this without not acknowledging 1,2 even
> though we will do set these values, I revisited the "1 2 3" issue. And I don't
> understand why this is actually an issue, we are just being more permissive
> (i.e. we are allowing as separators both whitespaces and ,).
>
>
Oops, after rechecking my test case, it is actually my test case's
fault. Sorry for this. I will fix my test case and run it again.
>
> I will resend the whole patch series once we get this formatting issue
> resolved.
>
Thanks much!
^ permalink raw reply
* [PATCH net-next 5/6] cnic: Use union for the status blocks of different devices.
From: Michael Chan @ 2010-02-25 0:42 UTC (permalink / raw)
To: davem; +Cc: netdev
In-Reply-To: <1267058529-18454-4-git-send-email-mchan@broadcom.com>
We only need to assign the status block address once and it also saves
space in the structure.
Signed-off-by: Michael Chan <mchan@broadcom.com>
Signed-off-by: Benjamin Li <benli@broadcom.com>
Signed-off-by: Eddie Wai <waie@broadcom.com>
---
drivers/net/cnic.c | 35 +++++++++++++++++------------------
drivers/net/cnic.h | 9 ++++++---
2 files changed, 23 insertions(+), 21 deletions(-)
diff --git a/drivers/net/cnic.c b/drivers/net/cnic.c
index 0defe61..463408f 100644
--- a/drivers/net/cnic.c
+++ b/drivers/net/cnic.c
@@ -900,7 +900,8 @@ static int cnic_alloc_uio(struct cnic_dev *dev) {
uinfo->mem[0].memtype = UIO_MEM_PHYS;
if (test_bit(CNIC_F_BNX2_CLASS, &dev->flags)) {
- uinfo->mem[1].addr = (unsigned long) cp->status_blk & PAGE_MASK;
+ uinfo->mem[1].addr = (unsigned long) cp->status_blk.gen &
+ PAGE_MASK;
if (cp->ethdev->drv_state & CNIC_DRV_STATE_USING_MSIX)
uinfo->mem[1].size = BNX2_SBLK_MSIX_ALIGN_SIZE * 9;
else
@@ -1103,10 +1104,9 @@ static int cnic_alloc_bnx2x_resc(struct cnic_dev *dev)
if (ret)
goto error;
- cp->bnx2x_status_blk = cp->status_blk;
cp->bnx2x_def_status_blk = cp->ethdev->irq_arr[1].status_blk;
- memset(cp->bnx2x_status_blk, 0, sizeof(struct host_status_block));
+ memset(cp->status_blk.bnx2x, 0, sizeof(*cp->status_blk.bnx2x));
cp->l2_rx_ring_size = 15;
@@ -2205,7 +2205,7 @@ static void cnic_service_bnx2_msix(unsigned long data)
{
struct cnic_dev *dev = (struct cnic_dev *) data;
struct cnic_local *cp = dev->cnic_priv;
- struct status_block_msix *status_blk = cp->bnx2_status_blk;
+ struct status_block_msix *status_blk = cp->status_blk.bnx2;
u32 status_idx = status_blk->status_idx;
u16 hw_prod, sw_prod;
int kcqe_cnt;
@@ -2251,7 +2251,7 @@ static irqreturn_t cnic_irq(int irq, void *dev_instance)
if (cp->ack_int)
cp->ack_int(dev);
- prefetch(cp->status_blk);
+ prefetch(cp->status_blk.gen);
prefetch(&cp->kcq[KCQ_PG(prod)][KCQ_IDX(prod)]);
if (likely(test_bit(CNIC_F_CNIC_UP, &dev->flags)))
@@ -2292,7 +2292,7 @@ static void cnic_service_bnx2x_bh(unsigned long data)
struct cnic_local *cp = dev->cnic_priv;
u16 hw_prod, sw_prod;
struct cstorm_status_block_c *sblk =
- &cp->bnx2x_status_blk->c_status_block;
+ &cp->status_blk.bnx2x->c_status_block;
u32 status_idx = sblk->status_block_index;
int kcqe_cnt;
@@ -2334,7 +2334,7 @@ static int cnic_service_bnx2x(void *data, void *status_blk)
struct cnic_local *cp = dev->cnic_priv;
u16 prod = cp->kcq_prod_idx & MAX_KCQ_IDX;
- prefetch(cp->status_blk);
+ prefetch(cp->status_blk.bnx2x);
prefetch(&cp->kcq[KCQ_PG(prod)][KCQ_IDX(prod)]);
if (likely(test_bit(CNIC_F_CNIC_UP, &dev->flags)))
@@ -3409,8 +3409,7 @@ static int cnic_init_bnx2_irq(struct cnic_dev *dev)
CNIC_WR(dev, base + BNX2_HC_COM_TICKS_OFF, (64 << 16) | 220);
CNIC_WR(dev, base + BNX2_HC_CMD_TICKS_OFF, (64 << 16) | 220);
- cp->bnx2_status_blk = cp->status_blk;
- cp->last_status_idx = cp->bnx2_status_blk->status_idx;
+ cp->last_status_idx = cp->status_blk.bnx2->status_idx;
tasklet_init(&cp->cnic_irq_task, cnic_service_bnx2_msix,
(unsigned long) dev);
err = request_irq(ethdev->irq_arr[0].vector, cnic_irq, 0,
@@ -3419,7 +3418,7 @@ static int cnic_init_bnx2_irq(struct cnic_dev *dev)
tasklet_disable(&cp->cnic_irq_task);
return err;
}
- while (cp->bnx2_status_blk->status_completion_producer_index &&
+ while (cp->status_blk.bnx2->status_completion_producer_index &&
i < 10) {
CNIC_WR(dev, BNX2_HC_COALESCE_NOW,
1 << (11 + sblk_num));
@@ -3427,13 +3426,13 @@ static int cnic_init_bnx2_irq(struct cnic_dev *dev)
i++;
barrier();
}
- if (cp->bnx2_status_blk->status_completion_producer_index) {
+ if (cp->status_blk.bnx2->status_completion_producer_index) {
cnic_free_irq(dev);
goto failed;
}
} else {
- struct status_block *sblk = cp->status_blk;
+ struct status_block *sblk = cp->status_blk.gen;
u32 hc_cmd = CNIC_RD(dev, BNX2_HC_COMMAND);
int i = 0;
@@ -3490,7 +3489,7 @@ static void cnic_init_bnx2_tx_ring(struct cnic_dev *dev)
int i;
struct tx_bd *txbd;
dma_addr_t buf_map;
- struct status_block *s_blk = cp->status_blk;
+ struct status_block *s_blk = cp->status_blk.gen;
sb_id = cp->status_blk_num;
tx_cid = 20;
@@ -3498,7 +3497,7 @@ static void cnic_init_bnx2_tx_ring(struct cnic_dev *dev)
cnic_init_context(dev, tx_cid + 1);
cp->tx_cons_ptr = &s_blk->status_tx_quick_consumer_index2;
if (ethdev->drv_state & CNIC_DRV_STATE_USING_MSIX) {
- struct status_block_msix *sblk = cp->status_blk;
+ struct status_block_msix *sblk = cp->status_blk.bnx2;
tx_cid = TX_TSS_CID + sb_id - 1;
cnic_init_context(dev, tx_cid);
@@ -3554,7 +3553,7 @@ static void cnic_init_bnx2_rx_ring(struct cnic_dev *dev)
u32 cid_addr, sb_id, val, coal_reg, coal_val;
int i;
struct rx_bd *rxbd;
- struct status_block *s_blk = cp->status_blk;
+ struct status_block *s_blk = cp->status_blk.gen;
sb_id = cp->status_blk_num;
cnic_init_context(dev, 2);
@@ -3562,7 +3561,7 @@ static void cnic_init_bnx2_rx_ring(struct cnic_dev *dev)
coal_reg = BNX2_HC_COMMAND;
coal_val = CNIC_RD(dev, coal_reg);
if (ethdev->drv_state & CNIC_DRV_STATE_USING_MSIX) {
- struct status_block_msix *sblk = cp->status_blk;
+ struct status_block_msix *sblk = cp->status_blk.bnx2;
cp->rx_cons_ptr = &sblk->status_rx_quick_consumer_index;
coal_reg = BNX2_HC_COALESCE_NOW;
@@ -3661,7 +3660,7 @@ static int cnic_start_bnx2_hw(struct cnic_dev *dev)
{
struct cnic_local *cp = dev->cnic_priv;
struct cnic_eth_dev *ethdev = cp->ethdev;
- struct status_block *sblk = cp->status_blk;
+ struct status_block *sblk = cp->status_blk.gen;
u32 val;
int err;
@@ -4250,7 +4249,7 @@ static int cnic_start_hw(struct cnic_dev *dev)
cp->chip_id = ethdev->chip_id;
pci_dev_get(dev->pcidev);
cp->func = PCI_FUNC(dev->pcidev->devfn);
- cp->status_blk = ethdev->irq_arr[0].status_blk;
+ cp->status_blk.gen = ethdev->irq_arr[0].status_blk;
cp->status_blk_num = ethdev->irq_arr[0].status_blk_num;
err = cp->alloc_resc(dev);
diff --git a/drivers/net/cnic.h b/drivers/net/cnic.h
index 1921597..d566390 100644
--- a/drivers/net/cnic.h
+++ b/drivers/net/cnic.h
@@ -224,9 +224,12 @@ struct cnic_local {
u16 kcq_prod_idx;
u32 kcq_io_addr;
- void *status_blk;
- struct status_block_msix *bnx2_status_blk;
- struct host_status_block *bnx2x_status_blk;
+ union {
+ void *gen;
+ struct status_block_msix *bnx2;
+ struct host_status_block *bnx2x;
+ } status_blk;
+
struct host_def_status_block *bnx2x_def_status_blk;
u32 status_blk_num;
--
1.6.4.GIT
^ permalink raw reply related
* [PATCH net-next 2/6] cnic: Finetune iSCSI connection reset.
From: Michael Chan @ 2010-02-25 0:42 UTC (permalink / raw)
To: davem; +Cc: netdev
In-Reply-To: <1267058529-18454-1-git-send-email-mchan@broadcom.com>
From: Eddie Wai <waie@broadcom.com>
For bnx2 devices, always send notification to bnx2i to let it initiate
the cleanup when RST is received.
For bnx2x devices, add unsolicited RST_COMP handling to start the cleanup.
Signed-off-by: Eddie Wai <waie@broadcom.com>
Signed-off-by: Michael Chan <mchan@broadcom.com>
Signed-off-by: Benjamin Li <benli@broadcom.com>
---
drivers/net/cnic.c | 21 ++++++++++++++++-----
1 files changed, 16 insertions(+), 5 deletions(-)
diff --git a/drivers/net/cnic.c b/drivers/net/cnic.c
index 0fe8371..40865aa 100644
--- a/drivers/net/cnic.c
+++ b/drivers/net/cnic.c
@@ -3108,7 +3108,10 @@ static void cnic_cm_process_kcqe(struct cnic_dev *dev, struct kcqe *kcqe)
break;
case L4_KCQE_OPCODE_VALUE_RESET_RECEIVED:
- if (test_and_clear_bit(SK_F_OFFLD_COMPLETE, &csk->flags))
+ if (test_bit(CNIC_F_BNX2_CLASS, &dev->flags)) {
+ cnic_cm_upcall(cp, csk, opcode);
+ break;
+ } else if (test_and_clear_bit(SK_F_OFFLD_COMPLETE, &csk->flags))
csk->state = opcode;
/* fall through */
case L4_KCQE_OPCODE_VALUE_CLOSE_COMP:
@@ -3172,6 +3175,16 @@ static int cnic_ready_to_close(struct cnic_sock *csk, u32 opcode)
if (!test_and_set_bit(SK_F_CLOSING, &csk->flags))
return 1;
}
+ /* 57710+ only workaround to handle unsolicited RESET_COMP
+ * which will be treated like a RESET RCVD notification
+ * which triggers the clean up procedure
+ */
+ else if (opcode == L4_KCQE_OPCODE_VALUE_RESET_COMP) {
+ if (!test_and_set_bit(SK_F_CLOSING, &csk->flags)) {
+ csk->state = L4_KCQE_OPCODE_VALUE_RESET_RECEIVED;
+ return 1;
+ }
+ }
return 0;
}
@@ -3181,10 +3194,8 @@ static void cnic_close_bnx2_conn(struct cnic_sock *csk, u32 opcode)
struct cnic_local *cp = dev->cnic_priv;
clear_bit(SK_F_CONNECT_START, &csk->flags);
- if (cnic_ready_to_close(csk, opcode)) {
- cnic_close_conn(csk);
- cnic_cm_upcall(cp, csk, opcode);
- }
+ cnic_close_conn(csk);
+ cnic_cm_upcall(cp, csk, opcode);
}
static void cnic_cm_stop_bnx2_hw(struct cnic_dev *dev)
--
1.6.4.GIT
^ permalink raw reply related
* [PATCH net-next 3/6] cnic: Fix panic in cnic_iscsi_nl_msg_recv() when device is down.
From: Michael Chan @ 2010-02-25 0:42 UTC (permalink / raw)
To: davem; +Cc: netdev
In-Reply-To: <1267058529-18454-2-git-send-email-mchan@broadcom.com>
Some data structures are freed when the device is down and it will
crash if an ISCSI netlink message is received. Add RCU protection
to prevent this. In the shutdown path, ulp_ops[CNIC_ULP_L4] is
assigned NULL and rcu_synchronized before freeing the data
structures.
Signed-off-by: Michael Chan <mchan@broadcom.com>
---
drivers/net/cnic.c | 7 +++++++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/drivers/net/cnic.c b/drivers/net/cnic.c
index 40865aa..4558444 100644
--- a/drivers/net/cnic.c
+++ b/drivers/net/cnic.c
@@ -327,6 +327,12 @@ static int cnic_iscsi_nl_msg_recv(struct cnic_dev *dev, u32 msg_type,
if (l5_cid >= MAX_CM_SK_TBL_SZ)
break;
+ rcu_read_lock();
+ if (!rcu_dereference(cp->ulp_ops[CNIC_ULP_L4])) {
+ rc = -ENODEV;
+ rcu_read_unlock();
+ break;
+ }
csk = &cp->csk_tbl[l5_cid];
csk_hold(csk);
if (cnic_in_use(csk)) {
@@ -341,6 +347,7 @@ static int cnic_iscsi_nl_msg_recv(struct cnic_dev *dev, u32 msg_type,
cnic_cm_set_pg(csk);
}
csk_put(csk);
+ rcu_read_unlock();
rc = 0;
}
}
--
1.6.4.GIT
^ permalink raw reply related
* [PATCH net-next 6/6] cnic: Update version to 2.1.1.
From: Michael Chan @ 2010-02-25 0:42 UTC (permalink / raw)
To: davem; +Cc: netdev
In-Reply-To: <1267058529-18454-5-git-send-email-mchan@broadcom.com>
And update copyright to 2010.
Signed-off-by: Michael Chan <mchan@broadcom.com>
---
drivers/net/cnic.c | 2 +-
drivers/net/cnic.h | 2 +-
drivers/net/cnic_defs.h | 2 +-
drivers/net/cnic_if.h | 6 +++---
4 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/net/cnic.c b/drivers/net/cnic.c
index 463408f..9781942 100644
--- a/drivers/net/cnic.c
+++ b/drivers/net/cnic.c
@@ -1,6 +1,6 @@
/* cnic.c: Broadcom CNIC core network driver.
*
- * Copyright (c) 2006-2009 Broadcom Corporation
+ * Copyright (c) 2006-2010 Broadcom Corporation
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
diff --git a/drivers/net/cnic.h b/drivers/net/cnic.h
index d566390..a0d853d 100644
--- a/drivers/net/cnic.h
+++ b/drivers/net/cnic.h
@@ -1,6 +1,6 @@
/* cnic.h: Broadcom CNIC core network driver.
*
- * Copyright (c) 2006-2009 Broadcom Corporation
+ * Copyright (c) 2006-2010 Broadcom Corporation
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
diff --git a/drivers/net/cnic_defs.h b/drivers/net/cnic_defs.h
index 9827b27..7ce694d 100644
--- a/drivers/net/cnic_defs.h
+++ b/drivers/net/cnic_defs.h
@@ -1,7 +1,7 @@
/* cnic.c: Broadcom CNIC core network driver.
*
- * Copyright (c) 2006-2009 Broadcom Corporation
+ * Copyright (c) 2006-2010 Broadcom Corporation
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
diff --git a/drivers/net/cnic_if.h b/drivers/net/cnic_if.h
index 8aaf98b..110c620 100644
--- a/drivers/net/cnic_if.h
+++ b/drivers/net/cnic_if.h
@@ -1,6 +1,6 @@
/* cnic_if.h: Broadcom CNIC core network driver.
*
- * Copyright (c) 2006 Broadcom Corporation
+ * Copyright (c) 2006-2010 Broadcom Corporation
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
@@ -12,8 +12,8 @@
#ifndef CNIC_IF_H
#define CNIC_IF_H
-#define CNIC_MODULE_VERSION "2.1.0"
-#define CNIC_MODULE_RELDATE "Oct 10, 2009"
+#define CNIC_MODULE_VERSION "2.1.1"
+#define CNIC_MODULE_RELDATE "Feb 22, 2010"
#define CNIC_ULP_RDMA 0
#define CNIC_ULP_ISCSI 1
--
1.6.4.GIT
^ permalink raw reply related
* [PATCH net-next 1/6] cnic: Finetune iSCSI connection set up.
From: Michael Chan @ 2010-02-25 0:42 UTC (permalink / raw)
To: davem; +Cc: netdev
From: Eddie Wai <waie@broadcom.com>
Initialize IP ID and handle some additional connection errors.
Signed-off-by: Eddie Wai <waie@broadcom.com>
Signed-off-by: Michael Chan <mchan@broadcom.com>
Signed-off-by: Benjamin Li <benli@broadcom.com>
---
drivers/net/cnic.c | 17 ++++++++++++++++-
drivers/net/cnic.h | 2 +-
2 files changed, 17 insertions(+), 2 deletions(-)
diff --git a/drivers/net/cnic.c b/drivers/net/cnic.c
index 6aecef9..0fe8371 100644
--- a/drivers/net/cnic.c
+++ b/drivers/net/cnic.c
@@ -2507,7 +2507,7 @@ static int cnic_cm_offload_pg(struct cnic_sock *csk)
l4kwqe->sa5 = dev->mac_addr[5];
l4kwqe->etype = ETH_P_IP;
- l4kwqe->ipid_count = DEF_IPID_COUNT;
+ l4kwqe->ipid_start = DEF_IPID_START;
l4kwqe->host_opaque = csk->l5_cid;
if (csk->vlan_id) {
@@ -3046,6 +3046,14 @@ static void cnic_cm_process_offld_pg(struct cnic_dev *dev, struct l4_kcq *kcqe)
clear_bit(SK_F_OFFLD_SCHED, &csk->flags);
goto done;
}
+ /* Possible PG kcqe status: SUCCESS, OFFLOADED_PG, or CTX_ALLOC_FAIL */
+ if (kcqe->status == L4_KCQE_COMPLETION_STATUS_CTX_ALLOC_FAIL) {
+ clear_bit(SK_F_OFFLD_SCHED, &csk->flags);
+ cnic_cm_upcall(cp, csk,
+ L4_KCQE_OPCODE_VALUE_CONNECT_COMPLETE);
+ goto done;
+ }
+
csk->pg_cid = kcqe->pg_cid;
set_bit(SK_F_PG_OFFLD_COMPLETE, &csk->flags);
cnic_cm_conn_req(csk);
@@ -3083,6 +3091,13 @@ static void cnic_cm_process_kcqe(struct cnic_dev *dev, struct kcqe *kcqe)
}
switch (opcode) {
+ case L5CM_RAMROD_CMD_ID_TCP_CONNECT:
+ if (l4kcqe->status != 0) {
+ clear_bit(SK_F_OFFLD_SCHED, &csk->flags);
+ cnic_cm_upcall(cp, csk,
+ L4_KCQE_OPCODE_VALUE_CONNECT_COMPLETE);
+ }
+ break;
case L4_KCQE_OPCODE_VALUE_CONNECT_COMPLETE:
if (l4kcqe->status == 0)
set_bit(SK_F_OFFLD_COMPLETE, &csk->flags);
diff --git a/drivers/net/cnic.h b/drivers/net/cnic.h
index 241d09a..1921597 100644
--- a/drivers/net/cnic.h
+++ b/drivers/net/cnic.h
@@ -101,7 +101,7 @@ struct cnic_redirect_entry {
#define BNX2X_KWQ_DATA(cp, x) \
&(cp)->kwq_16_data[BNX2X_KWQ_DATA_PG(cp, x)][BNX2X_KWQ_DATA_IDX(cp, x)]
-#define DEF_IPID_COUNT 0xc001
+#define DEF_IPID_START 0x8000
#define DEF_KA_TIMEOUT 10000
#define DEF_KA_INTERVAL 300000
--
1.6.4.GIT
^ permalink raw reply related
* [PATCH net-next 4/6] cnic: Simplify route checking during iSCSI connection.
From: Michael Chan @ 2010-02-25 0:42 UTC (permalink / raw)
To: davem; +Cc: netdev
In-Reply-To: <1267058529-18454-3-git-send-email-mchan@broadcom.com>
With a separate IP address for iSCSI, connections should proceed
whether or not we can get a route to the target from the network stack.
It is possible that the network IP address may not reach the iSCSI target.
Signed-off-by: Michael Chan <mchan@broadcom.com>
Signed-off-by: Benjamin Li <benli@broadcom.com>
Signed-off-by: Eddie Wai <waie@broadcom.com>
---
drivers/net/cnic.c | 37 +++++++++++++------------------------
1 files changed, 13 insertions(+), 24 deletions(-)
diff --git a/drivers/net/cnic.c b/drivers/net/cnic.c
index 4558444..0defe61 100644
--- a/drivers/net/cnic.c
+++ b/drivers/net/cnic.c
@@ -2860,8 +2860,8 @@ static int cnic_get_route(struct cnic_sock *csk, struct cnic_sockaddr *saddr)
{
struct cnic_dev *dev = csk->dev;
struct cnic_local *cp = dev->cnic_priv;
- int is_v6, err, rc = -ENETUNREACH;
- struct dst_entry *dst;
+ int is_v6, rc = 0;
+ struct dst_entry *dst = NULL;
struct net_device *realdev;
u32 local_port;
@@ -2877,39 +2877,31 @@ static int cnic_get_route(struct cnic_sock *csk, struct cnic_sockaddr *saddr)
clear_bit(SK_F_IPV6, &csk->flags);
if (is_v6) {
-#if defined(CONFIG_IPV6) || (defined(CONFIG_IPV6_MODULE) && defined(MODULE))
set_bit(SK_F_IPV6, &csk->flags);
- err = cnic_get_v6_route(&saddr->remote.v6, &dst);
- if (err)
- return err;
-
- if (!dst || dst->error || !dst->dev)
- goto err_out;
+ cnic_get_v6_route(&saddr->remote.v6, &dst);
memcpy(&csk->dst_ip[0], &saddr->remote.v6.sin6_addr,
sizeof(struct in6_addr));
csk->dst_port = saddr->remote.v6.sin6_port;
local_port = saddr->local.v6.sin6_port;
-#else
- return rc;
-#endif
} else {
- err = cnic_get_v4_route(&saddr->remote.v4, &dst);
- if (err)
- return err;
-
- if (!dst || dst->error || !dst->dev)
- goto err_out;
+ cnic_get_v4_route(&saddr->remote.v4, &dst);
csk->dst_ip[0] = saddr->remote.v4.sin_addr.s_addr;
csk->dst_port = saddr->remote.v4.sin_port;
local_port = saddr->local.v4.sin_port;
}
- csk->vlan_id = cnic_get_vlan(dst->dev, &realdev);
- if (realdev != dev->netdev)
- goto err_out;
+ csk->vlan_id = 0;
+ csk->mtu = dev->netdev->mtu;
+ if (dst && dst->dev) {
+ u16 vlan = cnic_get_vlan(dst->dev, &realdev);
+ if (realdev == dev->netdev) {
+ csk->vlan_id = vlan;
+ csk->mtu = dst_mtu(dst);
+ }
+ }
if (local_port >= CNIC_LOCAL_PORT_MIN &&
local_port < CNIC_LOCAL_PORT_MAX) {
@@ -2927,9 +2919,6 @@ static int cnic_get_route(struct cnic_sock *csk, struct cnic_sockaddr *saddr)
}
csk->src_port = local_port;
- csk->mtu = dst_mtu(dst);
- rc = 0;
-
err_out:
dst_release(dst);
return rc;
--
1.6.4.GIT
^ permalink raw reply related
* Re: [PATCH v2 0/3] e1000e,igb,ixgbe: add registers etc. printout code just before resetting adapters
From: Taku Izumi @ 2010-02-25 0:30 UTC (permalink / raw)
To: jeffrey.t.kirsher
Cc: Brandeburg, Jesse, netdev@vger.kernel.org, Allan, Bruce W,
David S. Miller, Ronciak, John, Waskiewicz Jr, Peter P,
Koki Sanagi, Kenji Kaneshige, chavey@google.com,
e1000-devel@lists.sourceforge.net
In-Reply-To: <1266578456.25502.23.camel@localhost.localdomain>
Hi Jeff,
> To answer your question, no there are no files you can't submit patches
> to. We do have some common files which are used/shared amongst all of
> our drivers which are used for initializing and/or bring up the
> hardware, so when a patch is submitted to our drivers which changes our
> "shared code" our first question is "Is this change necessary for all of
> our drivers?" and if the answer is no, then we take a look at what
> changes can be made in the code which is not shared among our other
> drivers.
Please tell me concretely which part of my former submitted patchset is bad?
Next time I'll create under that condition.
Best regards,
Taku Izumi
^ permalink raw reply
* Re: [PATCH v2 0/3] e1000e,igb,ixgbe: add registers etc. printout code just before resetting adapters
From: Taku Izumi @ 2010-02-25 0:24 UTC (permalink / raw)
To: Laurent Chavey
Cc: jeffrey.t.kirsher, Brandeburg, Jesse, netdev@vger.kernel.org,
Allan, Bruce W, David S. Miller, Ronciak, John,
Waskiewicz Jr, Peter P, Koki Sanagi, Kenji Kaneshige,
e1000-devel@lists.sourceforge.net
In-Reply-To: <97949e3e1002241136q70f55c97rafd79c2a5a19349c@mail.gmail.com>
Hi Chavey,
> I like the idea of adding debugging support. While using syslog does provide
> a "easier" way to get the output out, I am wondering if it would be
> worse the while
> to try to add a generic debug interface (via ethtool / netlink) that
> each driver would
> then support.
>
> If using syslog is the choosen way, then having the feature on by
> default may not
> be wanted.
I think these pritout messages are not only for debugging purpose but
a kind of error notification, for adapter resetting is error.
I prefer that these messages are always output wheter debugging mode is enabled
or not, but if it is not hoped to be always output to syslog, another place
(like a private ring buffer) is also acceptable.
Now I'm considering to output to private pring buffer.
Taku Izumi
^ permalink raw reply
* [PATCH] netdev: use list_first_entry macro
From: Stephen Hemminger @ 2010-02-25 0:01 UTC (permalink / raw)
To: David Miller; +Cc: netdev
Use list_first_entry macro; no longer any need to use
'next' directly in list to find first entry.
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
--- a/net/core/dev.c 2010-02-24 15:14:47.502112037 -0800
+++ b/net/core/dev.c 2010-02-24 15:15:45.201861020 -0800
@@ -3018,7 +3018,7 @@ static void net_rx_action(struct softirq
* entries to the tail of this list, and only ->poll()
* calls can remove this head entry from the list.
*/
- n = list_entry(list->next, struct napi_struct, poll_list);
+ n = list_first_entry(list, struct napi_struct, poll_list);
have = netpoll_poll_lock(n);
@@ -4882,7 +4882,7 @@ static void rollback_registered_many(str
}
/* Process any work delayed until the end of the batch */
- dev = list_entry(head->next, struct net_device, unreg_list);
+ dev = list_first_entry(head, struct net_device, unreg_list);
call_netdevice_notifiers(NETDEV_UNREGISTER_BATCH, dev);
synchronize_net();
@@ -5268,7 +5268,7 @@ void netdev_run_todo(void)
while (!list_empty(&list)) {
struct net_device *dev
- = list_entry(list.next, struct net_device, todo_list);
+ = list_first_entry(&list, struct net_device, todo_list);
list_del(&dev->todo_list);
if (unlikely(dev->reg_state != NETREG_UNREGISTERING)) {
^ permalink raw reply
* Re: [Bugme-new] [Bug 15379] New: u32 classifier port range calculation error
From: Andrew Morton @ 2010-02-24 22:52 UTC (permalink / raw)
To: netdev; +Cc: bugzilla-daemon, bugme-daemon, reinaldoc
In-Reply-To: <bug-15379-10286@http.bugzilla.kernel.org/>
(switched to email. Please respond via emailed reply-to-all, not via the
bugzilla web interface).
On Tue, 23 Feb 2010 20:56:09 GMT bugzilla-daemon@bugzilla.kernel.org wrote:
> http://bugzilla.kernel.org/show_bug.cgi?id=15379
>
> Summary: u32 classifier port range calculation error
> Product: Networking
> Version: 2.5
> Kernel Version: All (2.6.32 tested)
> Platform: All
> OS/Version: Linux
> Tree: Mainline
> Status: NEW
> Severity: normal
> Priority: P1
> Component: Other
> AssignedTo: acme@ghostprotocols.net
> ReportedBy: reinaldoc@gmail.com
> Regression: No
>
>
> U32 classifier have a problem on mask calculation of IP port range value.
>
> To reproduce the problem:
>
> ##### MASK CALCULATION FOR PORT RANGE 6880->6911
>
> echo "obase=16;(2^13)-32" | bc
> 1FE0
>
> Example:
>
> ###### TC SAMPLE RULES
> tc qdisc del dev eth0 root >/dev/null 2>&1
>
> tc qdisc add dev eth0 root handle 1: htb default 1100
> tc class add dev eth0 root classid 1:1000 htb rate 1000Mbit ceil 1000Mbit
> tc class add dev eth0 classid 1:1100 parent 1:1000 htb prio 0 rate 999Mbit
> ceil 999Mbit
> tc class add dev eth0 classid 1:1200 parent 1:1000 htb prio 0 rate 1Mbit
> ceil 1Mbit
>
> tc filter add dev eth0 protocol ip prio 1 parent 1: u32 flowid 1:1200 match ip
> dport 6880 0x1FE0
>
> ###### STATS CLEAN ** success 0
> tc -s filter show dev eth0
> filter parent 1: protocol ip pref 1 u32
> filter parent 1: protocol ip pref 1 u32 fh 800: ht divisor 1
> filter parent 1: protocol ip pref 1 u32 fh 800::800 order 2048 key ht 800 bkt 0
> flowid 1:1200 (rule hit 116 success 0)
> match 00001ae0/00001fe0 at 20 (success 0 )
>
> ###### SENDING PACKETS I
> # nmap example.ufpa.br -p 1-10000
>
> ###### STATS I ** success 32 (OK)
> # tc -s filter show dev eth0
> filter parent 1: protocol ip pref 1 u32
> filter parent 1: protocol ip pref 1 u32 fh 800: ht divisor 1
> filter parent 1: protocol ip pref 1 u32 fh 800::800 order 2048 key ht 800 bkt 0
> flowid 1:1200 (rule hit 12676 success 32)
> match 00001ae0/00001fe0 at 20 (success 32 )
>
> ###### SENDING PACKETS II
> # nmap example.ufpa.br -p 10000-20000
>
> ###### STATS II ** success 64 (ERROR) - should not match
>
> # tc -s filter show dev eth0
> filter parent 1: protocol ip pref 1 u32
> filter parent 1: protocol ip pref 1 u32 fh 800: ht divisor 1
> filter parent 1: protocol ip pref 1 u32 fh 800::800 order 2048 key ht 800 bkt 0
> flowid 1:1200 (rule hit 25172 success 64)
> match 00001ae0/00001fe0 at 20 (success 64 )
>
> ###### SENDING PACKETS III
> # nmap example.ufpa.br -p 20000-30000
>
> ###### STATS III ** success 96 (ERROR) - should not match
>
> # tc -s filter show dev eth0
> filter parent 1: protocol ip pref 1 u32
> filter parent 1: protocol ip pref 1 u32 fh 800: ht divisor 1
> filter parent 1: protocol ip pref 1 u32 fh 800::800 order 2048 key ht 800 bkt 0
> flowid 1:1200 (rule hit 43131 success 96)
> match 00001ae0/00001fe0 at 20 (success 96 )
>
> ### End
^ permalink raw reply
* [PATCH] myri10ge: optimize 4k-boundary check when stocking rx pages
From: Brice Goglin @ 2010-02-24 22:11 UTC (permalink / raw)
To: David S. Miller; +Cc: Linux Network Development list
Small optimization to the code which checks to see if we'd cross
a 4K boundary when stocking RX ring.
Signed-off-by: Brice Goglin <brice@myri.com>
Signed-off-by: Andrew Gallatin <gallatin@myri.com>
Signed-off-by: Guillaume Morin <guillaume@morinfr.org>
diff --git a/drivers/net/myri10ge/myri10ge.c b/drivers/net/myri10ge/myri10ge.c
index c0884a9..03f9fc0 100644
--- a/drivers/net/myri10ge/myri10ge.c
+++ b/drivers/net/myri10ge/myri10ge.c
@@ -75,7 +75,7 @@
#include "myri10ge_mcp.h"
#include "myri10ge_mcp_gen_header.h"
-#define MYRI10GE_VERSION_STR "1.5.1-1.453"
+#define MYRI10GE_VERSION_STR "1.5.2-1.459"
MODULE_DESCRIPTION("Myricom 10G driver (10GbE)");
MODULE_AUTHOR("Maintainer: help@myri.com");
@@ -1201,6 +1201,9 @@ myri10ge_alloc_rx_pages(struct myri10ge_priv *mgp, struct myri10ge_rx_buf *rx,
{
struct page *page;
int idx;
+#if MYRI10GE_ALLOC_SIZE > 4096
+ int end_offset;
+#endif
if (unlikely(rx->watchdog_needed && !watchdog))
return;
@@ -1242,9 +1245,9 @@ myri10ge_alloc_rx_pages(struct myri10ge_priv *mgp, struct myri10ge_rx_buf *rx,
#if MYRI10GE_ALLOC_SIZE > 4096
/* don't cross a 4KB boundary */
- if ((rx->page_offset >> 12) !=
- ((rx->page_offset + bytes - 1) >> 12))
- rx->page_offset = (rx->page_offset + 4096) & ~4095;
+ end_offset = rx->page_offset + bytes - 1;
+ if ((unsigned)(rx->page_offset ^ end_offset) > 4095)
+ rx->page_offset = end_offset & ~4095;
#endif
rx->fill_cnt++;
^ permalink raw reply related
* Re: [PATCH]: tipc: Fix oops on send prior to entering networked mode
From: Neil Horman @ 2010-02-24 21:19 UTC (permalink / raw)
To: Stephens, Allan; +Cc: netdev, jon.maloy, tipc-discussion, davem
In-Reply-To: <29C1DC0826876849BDD9F1C67ABA2943070F1534@ala-mail09.corp.ad.wrs.com>
As noted in my previous note, I'd agreed tht the preiviously posted patches for
the various tipc patches we encountered were sufficient for the oops at hand.
This patch closes the race condition thats left open after the application of
those patches.
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
include/net/tipc/tipc.h | 3 ++-
net/tipc/net.c | 8 +++++---
2 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/include/net/tipc/tipc.h b/include/net/tipc/tipc.h
index 9566608..14076e9 100644
--- a/include/net/tipc/tipc.h
+++ b/include/net/tipc/tipc.h
@@ -54,7 +54,8 @@ u32 tipc_get_addr(void);
#define TIPC_NOT_RUNNING 0
#define TIPC_NODE_MODE 1
-#define TIPC_NET_MODE 2
+#define TIPC_TRANS_MODE 2
+#define TIPC_NET_MODE 3
typedef void (*tipc_mode_event)(void *usr_handle, int mode, u32 addr);
diff --git a/net/tipc/net.c b/net/tipc/net.c
index 7906608..daeafe7 100644
--- a/net/tipc/net.c
+++ b/net/tipc/net.c
@@ -278,7 +278,7 @@ int tipc_net_start(u32 addr)
tipc_cfg_stop();
tipc_own_addr = addr;
- tipc_mode = TIPC_NET_MODE;
+ tipc_mode = TIPC_TRANS_MODE;
tipc_named_reinit();
tipc_port_reinit();
@@ -295,18 +295,20 @@ int tipc_net_start(u32 addr)
info("Started in network mode\n");
info("Own node address %s, network identity %u\n",
addr_string_fill(addr_string, tipc_own_addr), tipc_net_id);
+ tipc_mode = TIPC_NET_MODE;
return 0;
}
void tipc_net_stop(void)
{
- if (tipc_mode != TIPC_NET_MODE)
+ if (tipc_mode < TIPC_TRANS_MODE)
return;
+ tipc_mode = TIPC_TRANS_MODE;
write_lock_bh(&tipc_net_lock);
tipc_bearer_stop();
- tipc_mode = TIPC_NODE_MODE;
tipc_bclink_stop();
net_stop();
+ tipc_mode = TIPC_NODE_MODE;
write_unlock_bh(&tipc_net_lock);
info("Left network mode \n");
}
^ permalink raw reply related
* Re: [PATCH]: tipc: Fix oops on send prior to entering networked mode
From: Neil Horman @ 2010-02-24 21:15 UTC (permalink / raw)
To: Stephens, Allan; +Cc: netdev, jon.maloy, tipc-discussion, davem
In-Reply-To: <29C1DC0826876849BDD9F1C67ABA2943070F1534@ala-mail09.corp.ad.wrs.com>
On Wed, Feb 24, 2010 at 11:05:12AM -0800, Stephens, Allan wrote:
> Hi Neil:
>
> Have you tried upgrading your system to use TIPC 1.7.6 (available at
> http://tipc.sourceforge.net/tipc_linux.html)? This is a significant
> revised and enhanced version of TIPC that hasn't yet made its way into
> mainsteam Linux, and seems to be the version-of-choice for most TIPC
> users. It also appears to avoid a number of the issues that currently
> exist in TIPC 1.6, including the one caused by the random configuration
> command you mentioned in your email below.
>
> I didn't have a problem with you working on a small patch for TIPC 1.6
> to get around a limited problem, but I'd hate to see you waste time on
> fixing issues that have already been addressed in TIPC 1.7.
>
Yeah, yeah, it looks like 1.7.6 peppered the config paths with tipc_mode checks
all over the place. Fine, can you post a patch here of the change that added
that? Can you also post a version of the patch that you posted for the
tipc_local_node patch and tipc_net that davem can apply (since that fixed the
remaining problems).
That just leaves the race condition on the mode setting (in which there is a
time between the setting of tipc_mode and the completion of tipc_net_start
during which you can pass all the mode checks without having all the data
initalized. I'll send a patch for that shortly.
As for this being a waste of time, its really not. Despite having a later
version that developers might like to use, most distributions fork the upstream
kernel directly, and assume fixes appear here. Even if developers never use the
tipc module that ships with the upstream kernel, just having it built in case
anyone wants to use it opens those distributions up to critical bugs, like this
one, which allows unprivlidged local users to crash the system. And for those
distributions, 'Just go get the latest source' really isn't a viable option in
many/most cases. If its not fixed in the public kernel, then the code isn't very
worthwhile to anyone. And for those distributions, 'Just go get the latest
source' really isn't a viable option in many/most cases.
Looking at the 1.7.6 tarball on sourceforge, its dated 10/10/2008, so you've
basically got a 1.5 year lag between the development version and the commited
version that distributions are using (and counting). I'm sorry, I'm not trying
to be crass about this, but its rather disconcerting to see that kind of
discrepancy between the code development point and whats in net-next. It
implies that the only fix for a tipc problem is a wholesale upgrade of the tipc
directory in the kernel (since it would seem the sourceforge tipc cvs tree has
gone unused for a few years). Based on that it seems unwise for any
distribution to default include tipc in its kernel. Would you agree?
Anywho, given what you have in the tarball at the sourceforge site, a patch that
adds all the requisite TIPC_NET_MODE checks as well as the previous patch to
check tipc_net and tipc_local_node I think satisfies the bug at hand, if you
would please post those with your sign-off, I'll ack them, and I'll post a patch
for the remaining race shortly.
Thanks & Regards
Neil
> Regards,
> Al
>
> > -----Original Message-----
> > From: Neil Horman [mailto:nhorman@tuxdriver.com]
> > Sent: Wednesday, February 24, 2010 1:54 PM
> > To: Stephens, Allan
> > Cc: netdev@vger.kernel.org; jon.maloy@ericsson.com;
> > tipc-discussion@lists.sourceforge.net; davem@davemloft.net
> > Subject: Re: [PATCH]: tipc: Fix oops on send prior to
> > entering networked mode
> >
> > On Tue, Feb 23, 2010 at 08:21:25AM -0800, Stephens, Allan wrote:
> > > Neil wrote:
> > >
> > > > I agree that you patch fixes the exact problem that I
> > reported here,
> > > > but theres more to it than that. A quick grep of the tipc stack
> > > > reveals the following
> > > > symbols:
> > > > tipc_bearers
> > > > media_list
> > > > tipc_local_nodes
> > > > bcbearer
> > > > bclink
> > > > tipc_net.zones
> > > >
> > > > All of these symbols:
> > > >
> > > > 1) Are allocated dynamically in tipc_net_start, _after_
> > tipc_mode is
> > > > set to TIPC_NET_MODE
> > > >
> > > > 2) dereferenced without NULL pointer checks in either the
> > send path
> > > > or in the netlink configuration path, both of which are reachable
> > > > from user space.
> > > >
> > > > So your patch fixes the last item on your list, but what
> > about the
> > > > others? In fact, I'll bet I can very quickly change the
> > application
> > > > to trip over a null tipc_local_nodes dereference by changing the
> > > > destination address to be something within zone 0, cluster 0.
> > >
> > > The semantics of TIPC addressing don't allow a node address of the
> > > form <0.0.N> where N != 0, so this kind of a send ateempt should be
> > > caught and handled by TIPC. However, you've already found
> > one missing
> > > error check, so it's certainly worth trying it out!
> > >
> >
> > So, I've tested out your patch, and it fixes the problem that
> > was reported (no suprisingly, it was pretty clear that it
> > would), it also managed to fix the access to tipc_local_nodes
> > (I'd previously missed the chunk of the patch that added the
> > ? to that access), so thats all great. Then I did this:
> > ./tipc-config -lsr 1.1.10:eth3-1.1.17:eth2
> >
> > And got this:
> >
> > BUG: unable to handle kernel NULL pointer dereference at
> > 00000000000000c4
> > IP: [<ffffffffa030f6a8>] tipc_bearer_find_interface+0x1f/0x66
> > [tipc] PGD 11be1a067 PUD 11c721067 PMD 0
> > Oops: 0000 [#1] SMP
> > last sysfs file:
> > /sys/devices/system/cpu/cpu3/cache/index2/shared_cpu_map
> > CPU 3
> > Pid: 1284, comm: tipc-config Not tainted 2.6.33-rc8 #1
> > 0YK962/PowerEdge SC1435
> > RIP: 0010:[<ffffffffa030f6a8>] [<ffffffffa030f6a8>]
> > tipc_bearer_find_interface+0x1f/0x66 [tipc]
> > RSP: 0018:ffff88011c7b3a08 EFLAGS: 00010246
> > RAX: 0000000000000001 RBX: 0000000000000000 RCX: ffff88011c7b3900
> > RDX: 0000000000000000 RSI: ffff88011c7b39c0 RDI: ffff88011c7b3a3c
> > RBP: ffff88011c7b3a28 R08: 0000000000000032 R09: 000000000000000a
> > R10: ffffffffa03258b8 R11: 0000000000000000 R12: 0000000000000000
> > R13: ffff88011c7b3a3c R14: 0000000000000040 R15: ffffffff829a89b0
> > FS: 00007fd2d1c56700(0000) GS:ffff880082400000(0000)
> > knlGS:0000000000000000
> > CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> > CR2: 00000000000000c4 CR3: 000000011c7aa000 CR4: 00000000000006e0
> > DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> > DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7:
> > 0000000000000400 Process tipc-config (pid: 1284, threadinfo
> > ffff88011c7b2000, task
> > ffff88011cba48a0)
> > Stack:
> > ffff880023022260 ffff88011c7b3a38 ffff880023022260
> > ffff88011c7b3aa0 <0> ffff88011c7b3a88 ffffffffa031294c
> > 336874650100100a ffff880023022200 <0> 0100101100000040
> > ffffff0032687465 ffff88011c7b3a88 00000000c78c4377 Call Trace:
> > [<ffffffffa031294c>] link_find_link+0x40/0x9d [tipc]
> > [<ffffffffa0312fce>] ? tipc_link_cmd_reset_stats+0x63/0xbb
> > [tipc] [<ffffffffa0312fda>]
> > tipc_link_cmd_reset_stats+0x6f/0xbb [tipc]
> > [<ffffffffa031093d>] tipc_cfg_do_cmd+0x2ae/0x7d4 [tipc]
> > [<ffffffffa031a506>] handle_cmd+0x68/0xba [tipc]
> > [<ffffffff813d493f>] genl_rcv_msg+0x1c7/0x1eb
> > [<ffffffff813d4778>] ? genl_rcv_msg+0x0/0x1eb
> > [<ffffffff813d3895>] netlink_rcv_skb+0x43/0x94
> > [<ffffffff813d4771>] genl_rcv+0x26/0x2d [<ffffffff813d3664>]
> > netlink_unicast+0x125/0x18e [<ffffffff813d3e4e>]
> > netlink_sendmsg+0x259/0x268 [<ffffffff813a57d4>]
> > __sock_sendmsg+0x5e/0x69 [<ffffffff813a7f37>]
> > sock_aio_write+0xc0/0xd4 [<ffffffff8107e57f>] ?
> > print_lock_contention_bug+0x1b/0xe0
> > [<ffffffff81114f59>] do_sync_write+0xc4/0x101
> > [<ffffffff811e5cd9>] ? selinux_file_permission+0xa7/0xb3
> > [<ffffffff811dbdf1>] ? security_file_permission+0x16/0x18
> > [<ffffffff811154e8>] vfs_write+0xc1/0x10b
> > [<ffffffff8107cb35>] ? trace_hardirqs_on_caller+0x1f/0x141
> > [<ffffffff811155f2>] sys_write+0x4a/0x6e
> > [<ffffffff81009b82>] system_call_fastpath+0x16/0x1b
> > Code: 5f 5b 41 5c 41 5d 41 5e 41 5f c9 c3 55 48 89 e5 41 55
> > 41 54 53 48 83 ec 08 0f 1f 44 00 00 48 8b 1d 86 68 01 00 45
> > 31 e4 49 89 fd <83> bb c4 00 00 00 00 74 1e 48 8d 7b 5c be 3a
> > 00 00 00 e8 RIP [<ffffffffa030f6a8>]
> > tipc_bearer_find_interface+0x1f/0x66 [tipc] RSP <ffff88011c7b3a08>
> > CR2: 00000000000000c4
> > ---[ end trace a14d3b6105c45243 ]---
> >
> > The use of that command was arbitrary, it was just one of the
> > paths from user space to one of the variables that I
> > mentioned previously. And my patch wouldn't have fixed this
> > either, but its illustrative of my earlier assertion, that
> > theres no real synchronization between the user-space
> > accessable paths in tipc and the implementation state which
> > should gate access to those paths.
> >
> > Now we could continue to add NULL checks whereever these bugs
> > pop up (and perhaps in the above case specifically that might
> > be valid, I'm not sure yet), but that just feels like a
> > loosing battle that we might never quite catch up with, as
> > the code evolves. Seems to me like a better solution would
> > be adding common gating in the netlink and send paths to
> > ensure that only when the system was properly configured
> > could you send various messages into the stack.
> >
> > I'll try to put an omibus patch together shortly.
> >
> > Thanks!
> > Neil
> >
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* [PATCH] greth: convert to netdev_tx_t
From: Denis Kirjanov <kirjanov@gmail.com @ 2010-02-24 20:25 UTC (permalink / raw)
To: davem; +Cc: kristoffer, netdev
Convert to netdev_tx_t
Signed-off-by: Denis Kirjanov <kirjanov@gmail.com>
---
drivers/net/greth.c | 12 ++++++++----
1 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/net/greth.c b/drivers/net/greth.c
index d203233..d75b461 100644
--- a/drivers/net/greth.c
+++ b/drivers/net/greth.c
@@ -66,8 +66,10 @@ module_param(greth_edcl, int, 0);
MODULE_PARM_DESC(greth_edcl, "GRETH EDCL usage indicator. Set to 1 if EDCL is used.");
static int greth_open(struct net_device *dev);
-static int greth_start_xmit(struct sk_buff *skb, struct net_device *dev);
-static int greth_start_xmit_gbit(struct sk_buff *skb, struct net_device *dev);
+static netdev_tx_t greth_start_xmit(struct sk_buff *skb,
+ struct net_device *dev);
+static netdev_tx_t greth_start_xmit_gbit(struct sk_buff *skb,
+ struct net_device *dev);
static int greth_rx(struct net_device *dev, int limit);
static int greth_rx_gbit(struct net_device *dev, int limit);
static void greth_clean_tx(struct net_device *dev);
@@ -379,7 +381,8 @@ static int greth_close(struct net_device *dev)
return 0;
}
-static int greth_start_xmit(struct sk_buff *skb, struct net_device *dev)
+static netdev_tx_t
+greth_start_xmit(struct sk_buff *skb, struct net_device *dev)
{
struct greth_private *greth = netdev_priv(dev);
struct greth_bd *bdp;
@@ -441,7 +444,8 @@ out:
}
-static int greth_start_xmit_gbit(struct sk_buff *skb, struct net_device *dev)
+static netdev_tx_t
+greth_start_xmit_gbit(struct sk_buff *skb, struct net_device *dev)
{
struct greth_private *greth = netdev_priv(dev);
struct greth_bd *bdp;
^ permalink raw reply related
* Re: [net-next-2.6 PATCH] infiniband: convert to use netdev_for_each_mc_addr
From: Jiri Pirko @ 2010-02-24 20:18 UTC (permalink / raw)
To: Tung, Chien Tin
Cc: netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org, Latif, Faisal,
linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <603F8A3875DCE940BA37B49D0A6EA0AE842606EE-uLM7Qlg6Mbekrb+BlOpmy7fspsVTdybXVpNB7YpNyf8@public.gmane.org>
Wed, Feb 24, 2010 at 08:46:24PM CET, chien.tin.tung-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org wrote:
>Hi Jiri,
>
>I am having trouble applying your patch. It is erroring out on hunk #5.
>Current nes_nic.c does not have this line:
>
>>- netdev_mc_count(netdev), !!(netdev->flags & IFF_PROMISC),
This is present in current net-next tree.
Jirka
>
>Did I miss an old patch?
>
>Chien
>
>For reference:
>
>>diff --git a/drivers/infiniband/hw/nest/nes_nic.c b/drivers/infiniband/hw/nest/nes_nic.c
>>index c04f8fc..9384f5d 100644
>>--- a/drivers/infiniband/hw/nes/nes_nic.c
>>+++ b/drivers/infiniband/hw/nest/nes_nic.c
>[...]
>>@@ -862,19 +871,30 @@ static void nes_netdev_set_multicast_list(struct net_device *netdev)
>> }
>>
>> nes_debug(NES_DBG_NIC_RX, "Number of MC entries = %d, Promiscous = %d, All Multicast = %d.\n",
>>- netdev_mc_count(netdev), !!(netdev->flags & IFF_PROMISC),
>>+ mc_count, !!(netdev->flags & IFF_PROMISC),
>> !!(netdev->flags & IFF_ALLMULTI));
>> if (!mc_all_on) {
>>- multicast_addr = netdev->mc_list;
>>+ char *addrs;
>>+ int i;
>>+ struct dev_mc_list *mcaddr;
>>+
>>+ addrs = kmalloc(ETH_ALEN * mc_count, GFP_ATOMIC);
>>+ if (!addrs) {
>>+ set_allmulti(nesdev, nic_active_bit);
>>+ goto unlock;
>>+ }
>>+ i = 0;
>>+ netdev_for_each_mc_addr(mcaddr, netdev)
>>+ memcpy(get_addr(addrs, i++),
>>+ mcaddr->dmi_addr, ETH_ALEN);
>>+
>> perfect_filter_register_address = NES_IDX_PERFECT_FILTER_LOW +
>> pft_entries_preallocated * 0x8;
>>- for (mc_index = 0; mc_index < max_pft_entries_avaiable;
>>- mc_index++) {
>>- while (multicast_addr && nesvnic->mcrq_mcast_filter &&
>>+ for (i = 0, mc_index = 0; mc_index < max_pft_entries_avaiable;
>>+ mc_index++) {
>>+ while (i < mc_count && nesvnic->mcrq_mcast_filter &&
>> ((mc_nic_index = nesvnic->mcrq_mcast_filter(nesvnic,
>>- multicast_addr->dmi_addr)) == 0)) {
>>- multicast_addr = multicast_addr->next;
>>- }
>>+ get_addr(addrs, i++))) == 0));
>> if (mc_nic_index < 0)
>> mc_nic_index = nesvnic->nic_index;
>> while (nesadapter->pft_mcast_map[mc_index] < 16 &&
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Possible packet loss issue in recent net-next
From: Tantilov, Emil S @ 2010-02-24 19:59 UTC (permalink / raw)
To: netdev@vger.kernel.org
Cc: Brandeburg, Jesse, Duyck, Alexander H, davem@davemloft.net
[-- Attachment #1: Type: text/plain, Size: 542 bytes --]
In the last few pulls from net-next I am seeing an issue where sometimes a transfer would stall for about 30secs and then continue. I see this with simple commands like `rsh server uname -a` and ftp transfers. It happens with multiple drivers.
I have not done much digging into it yet, but just wanted to check if it's a known issue. I don't see this problem when testing with the torvalds tree.
Attached is a capture from the rsh session that fails. The "server" (190.1.15.5) is the system running net-next kernel.
Thanks,
Emil
[-- Attachment #2: client_bad_run2.cap --]
[-- Type: application/octet-stream, Size: 2361 bytes --]
[-- Attachment #3: server_bad_run2.cap --]
[-- Type: application/octet-stream, Size: 2367 bytes --]
[-- Attachment #4: merged2.cap --]
[-- Type: application/octet-stream, Size: 4704 bytes --]
^ permalink raw reply
* RE: [net-next-2.6 PATCH] infiniband: convert to use netdev_for_each_mc_addr
From: Tung, Chien Tin @ 2010-02-24 19:46 UTC (permalink / raw)
To: Jiri Pirko, netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Cc: davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org, Latif, Faisal,
linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <20100224151108.GD2663-YzwxZg+R7evMbnheQZGK0N5OCZ2W11yPFxja6HXR22MAvxtiuMwx3w@public.gmane.org>
Hi Jiri,
I am having trouble applying your patch. It is erroring out on hunk #5.
Current nes_nic.c does not have this line:
>- netdev_mc_count(netdev), !!(netdev->flags & IFF_PROMISC),
Did I miss an old patch?
Chien
For reference:
>diff --git a/drivers/infiniband/hw/nest/nes_nic.c b/drivers/infiniband/hw/nest/nes_nic.c
>index c04f8fc..9384f5d 100644
>--- a/drivers/infiniband/hw/nes/nes_nic.c
>+++ b/drivers/infiniband/hw/nest/nes_nic.c
[...]
>@@ -862,19 +871,30 @@ static void nes_netdev_set_multicast_list(struct net_device *netdev)
> }
>
> nes_debug(NES_DBG_NIC_RX, "Number of MC entries = %d, Promiscous = %d, All Multicast = %d.\n",
>- netdev_mc_count(netdev), !!(netdev->flags & IFF_PROMISC),
>+ mc_count, !!(netdev->flags & IFF_PROMISC),
> !!(netdev->flags & IFF_ALLMULTI));
> if (!mc_all_on) {
>- multicast_addr = netdev->mc_list;
>+ char *addrs;
>+ int i;
>+ struct dev_mc_list *mcaddr;
>+
>+ addrs = kmalloc(ETH_ALEN * mc_count, GFP_ATOMIC);
>+ if (!addrs) {
>+ set_allmulti(nesdev, nic_active_bit);
>+ goto unlock;
>+ }
>+ i = 0;
>+ netdev_for_each_mc_addr(mcaddr, netdev)
>+ memcpy(get_addr(addrs, i++),
>+ mcaddr->dmi_addr, ETH_ALEN);
>+
> perfect_filter_register_address = NES_IDX_PERFECT_FILTER_LOW +
> pft_entries_preallocated * 0x8;
>- for (mc_index = 0; mc_index < max_pft_entries_avaiable;
>- mc_index++) {
>- while (multicast_addr && nesvnic->mcrq_mcast_filter &&
>+ for (i = 0, mc_index = 0; mc_index < max_pft_entries_avaiable;
>+ mc_index++) {
>+ while (i < mc_count && nesvnic->mcrq_mcast_filter &&
> ((mc_nic_index = nesvnic->mcrq_mcast_filter(nesvnic,
>- multicast_addr->dmi_addr)) == 0)) {
>- multicast_addr = multicast_addr->next;
>- }
>+ get_addr(addrs, i++))) == 0));
> if (mc_nic_index < 0)
> mc_nic_index = nesvnic->nic_index;
> while (nesadapter->pft_mcast_map[mc_index] < 16 &&
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
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