* [PATCH 05/13] RDS: Fix congestion issues for loopback
From: Andy Grover @ 2010-03-11 23:49 UTC (permalink / raw)
To: netdev; +Cc: rds-devel
In-Reply-To: <1268351407-7394-1-git-send-email-andy.grover@oracle.com>
We have two kinds of loopback: software (via loop transport)
and hardware (via IB). sw is used for 127.0.0.1, and doesn't
support rdma ops. hw is used for sends to local device IPs,
and supports rdma. Both are used in different cases.
For both of these, when there is a congestion map update, we
want to call rds_cong_map_updated() but not actually send
anything -- since loopback local and foreign congestion maps
point to the same spot, they're already in sync.
The old code never called sw loop's xmit_cong_map(),so
rds_cong_map_updated() wasn't being called for it. sw loop
ports would not work right with the congestion monitor.
Fixing that meant that hw loopback now would send congestion maps
to itself. This is also undesirable (racy), so we check for this
case in the ib-specific xmit code.
Signed-off-by: Andy Grover <andy.grover@oracle.com>
---
net/rds/cong.c | 2 --
net/rds/ib_send.c | 7 +++++++
net/rds/loop.c | 7 -------
3 files changed, 7 insertions(+), 9 deletions(-)
diff --git a/net/rds/cong.c b/net/rds/cong.c
index 6d06cac..dd2711d 100644
--- a/net/rds/cong.c
+++ b/net/rds/cong.c
@@ -218,8 +218,6 @@ void rds_cong_queue_updates(struct rds_cong_map *map)
spin_lock_irqsave(&rds_cong_lock, flags);
list_for_each_entry(conn, &map->m_conn_list, c_map_item) {
- if (conn->c_loopback)
- continue;
if (!test_and_set_bit(0, &conn->c_map_queued)) {
rds_stats_inc(s_cong_update_queued);
queue_delayed_work(rds_wq, &conn->c_send_w, 0);
diff --git a/net/rds/ib_send.c b/net/rds/ib_send.c
index f380c3f..c18228a 100644
--- a/net/rds/ib_send.c
+++ b/net/rds/ib_send.c
@@ -482,6 +482,13 @@ int rds_ib_xmit(struct rds_connection *conn, struct rds_message *rm,
BUG_ON(off % RDS_FRAG_SIZE);
BUG_ON(hdr_off != 0 && hdr_off != sizeof(struct rds_header));
+ /* Do not send cong updates to IB loopback */
+ if (conn->c_loopback
+ && rm->m_inc.i_hdr.h_flags & RDS_FLAG_CONG_BITMAP) {
+ rds_cong_map_updated(conn->c_fcong, ~(u64) 0);
+ return sizeof(struct rds_header) + RDS_CONG_MAP_BYTES;
+ }
+
/* FIXME we may overallocate here */
if (be32_to_cpu(rm->m_inc.i_hdr.h_len) == 0)
i = 1;
diff --git a/net/rds/loop.c b/net/rds/loop.c
index 4a61997..93a45f1 100644
--- a/net/rds/loop.c
+++ b/net/rds/loop.c
@@ -80,16 +80,9 @@ static int rds_loop_xmit_cong_map(struct rds_connection *conn,
struct rds_cong_map *map,
unsigned long offset)
{
- unsigned long i;
-
BUG_ON(offset);
BUG_ON(map != conn->c_lcong);
- for (i = 0; i < RDS_CONG_MAP_PAGES; i++) {
- memcpy((void *)conn->c_fcong->m_page_addrs[i],
- (void *)map->m_page_addrs[i], PAGE_SIZE);
- }
-
rds_cong_map_updated(conn->c_fcong, ~(u64) 0);
return sizeof(struct rds_header) + RDS_CONG_MAP_BYTES;
--
1.6.3.3
^ permalink raw reply related
* [PATCH 09/13] RDS: Fix locking in rds_send_drop_to()
From: Andy Grover @ 2010-03-11 23:50 UTC (permalink / raw)
To: netdev; +Cc: rds-devel, Tina Yang
In-Reply-To: <1268351407-7394-1-git-send-email-andy.grover@oracle.com>
From: Tina Yang <tina.yang@oracle.com>
It seems rds_send_drop_to() called
__rds_rdma_send_complete(rs, rm, RDS_RDMA_CANCELED)
with only rds_sock lock, but not rds_message lock. It raced with
other threads that is attempting to modify the rds_message as well,
such as from within rds_rdma_send_complete().
Signed-off-by: Tina Yang <tina.yang@oracle.com>
Signed-off-by: Andy Grover <andy.grover@oracle.com>
---
net/rds/send.c | 13 +++++++------
1 files changed, 7 insertions(+), 6 deletions(-)
diff --git a/net/rds/send.c b/net/rds/send.c
index 1a2ef24..192a480 100644
--- a/net/rds/send.c
+++ b/net/rds/send.c
@@ -632,9 +632,6 @@ void rds_send_drop_to(struct rds_sock *rs, struct sockaddr_in *dest)
list_move(&rm->m_sock_item, &list);
rds_send_sndbuf_remove(rs, rm);
clear_bit(RDS_MSG_ON_SOCK, &rm->m_flags);
-
- /* If this is a RDMA operation, notify the app. */
- __rds_rdma_send_complete(rs, rm, RDS_RDMA_CANCELED);
}
/* order flag updates with the rs lock */
@@ -643,9 +640,6 @@ void rds_send_drop_to(struct rds_sock *rs, struct sockaddr_in *dest)
spin_unlock_irqrestore(&rs->rs_lock, flags);
- if (wake)
- rds_wake_sk_sleep(rs);
-
conn = NULL;
/* now remove the messages from the conn list as needed */
@@ -653,6 +647,10 @@ void rds_send_drop_to(struct rds_sock *rs, struct sockaddr_in *dest)
/* We do this here rather than in the loop above, so that
* we don't have to nest m_rs_lock under rs->rs_lock */
spin_lock_irqsave(&rm->m_rs_lock, flags2);
+ /* If this is a RDMA operation, notify the app. */
+ spin_lock(&rs->rs_lock);
+ __rds_rdma_send_complete(rs, rm, RDS_RDMA_CANCELED);
+ spin_unlock(&rs->rs_lock);
rm->m_rs = NULL;
spin_unlock_irqrestore(&rm->m_rs_lock, flags2);
@@ -681,6 +679,9 @@ void rds_send_drop_to(struct rds_sock *rs, struct sockaddr_in *dest)
if (conn)
spin_unlock_irqrestore(&conn->c_lock, flags);
+ if (wake)
+ rds_wake_sk_sleep(rs);
+
while (!list_empty(&list)) {
rm = list_entry(list.next, struct rds_message, m_sock_item);
list_del_init(&rm->m_sock_item);
--
1.6.3.3
^ permalink raw reply related
* [PATCH net-next 00/13] RDS bugfixes and cleanups
From: Andy Grover @ 2010-03-11 23:49 UTC (permalink / raw)
To: netdev; +Cc: rds-devel
Hi Dave,
These patches are against net-next, please apply.
Thanks -- Andy
^ permalink raw reply
* [PATCH 12/13] RDS: Do not call set_page_dirty() with irqs off
From: Andy Grover @ 2010-03-11 23:50 UTC (permalink / raw)
To: netdev; +Cc: rds-devel
In-Reply-To: <1268351407-7394-1-git-send-email-andy.grover@oracle.com>
set_page_dirty() unconditionally re-enables interrupts, so
if we call it with irqs off, they will be on after the call,
and that's bad. This patch moves the call after we've re-enabled
interrupts in send_drop_to(), so it's safe.
Also, add BUG_ONs to let us know if we ever do call set_page_dirty
with interrupts off.
Signed-off-by: Andy Grover <andy.grover@oracle.com>
---
net/rds/ib_rdma.c | 1 +
net/rds/rdma.c | 4 +++-
net/rds/send.c | 14 ++++++++------
3 files changed, 12 insertions(+), 7 deletions(-)
diff --git a/net/rds/ib_rdma.c b/net/rds/ib_rdma.c
index 65e668d..cfb1d90 100644
--- a/net/rds/ib_rdma.c
+++ b/net/rds/ib_rdma.c
@@ -440,6 +440,7 @@ static void __rds_ib_teardown_mr(struct rds_ib_mr *ibmr)
/* FIXME we need a way to tell a r/w MR
* from a r/o MR */
+ BUG_ON(in_interrupt());
set_page_dirty(page);
put_page(page);
}
diff --git a/net/rds/rdma.c b/net/rds/rdma.c
index 4c64daa..61b359d 100644
--- a/net/rds/rdma.c
+++ b/net/rds/rdma.c
@@ -438,8 +438,10 @@ void rds_rdma_free_op(struct rds_rdma_op *ro)
/* Mark page dirty if it was possibly modified, which
* is the case for a RDMA_READ which copies from remote
* to local memory */
- if (!ro->r_write)
+ if (!ro->r_write) {
+ BUG_ON(in_interrupt());
set_page_dirty(page);
+ }
put_page(page);
}
diff --git a/net/rds/send.c b/net/rds/send.c
index 51e2def..4629a0b 100644
--- a/net/rds/send.c
+++ b/net/rds/send.c
@@ -507,12 +507,13 @@ EXPORT_SYMBOL_GPL(rds_send_get_message);
*/
void rds_send_remove_from_sock(struct list_head *messages, int status)
{
- unsigned long flags = 0; /* silence gcc :P */
+ unsigned long flags;
struct rds_sock *rs = NULL;
struct rds_message *rm;
- local_irq_save(flags);
while (!list_empty(messages)) {
+ int was_on_sock = 0;
+
rm = list_entry(messages->next, struct rds_message,
m_conn_item);
list_del_init(&rm->m_conn_item);
@@ -527,7 +528,7 @@ void rds_send_remove_from_sock(struct list_head *messages, int status)
* while we're messing with it. It does not prevent the
* message from being removed from the socket, though.
*/
- spin_lock(&rm->m_rs_lock);
+ spin_lock_irqsave(&rm->m_rs_lock, flags);
if (!test_bit(RDS_MSG_ON_SOCK, &rm->m_flags))
goto unlock_and_drop;
@@ -556,21 +557,22 @@ void rds_send_remove_from_sock(struct list_head *messages, int status)
notifier->n_status = status;
rm->m_rdma_op->r_notifier = NULL;
}
- rds_message_put(rm);
+ was_on_sock = 1;
rm->m_rs = NULL;
}
spin_unlock(&rs->rs_lock);
unlock_and_drop:
- spin_unlock(&rm->m_rs_lock);
+ spin_unlock_irqrestore(&rm->m_rs_lock, flags);
rds_message_put(rm);
+ if (was_on_sock)
+ rds_message_put(rm);
}
if (rs) {
rds_wake_sk_sleep(rs);
sock_put(rds_rs_to_sk(rs));
}
- local_irq_restore(flags);
}
/*
--
1.6.3.3
^ permalink raw reply related
* [PATCH 13/13] RDS: Enable per-cpu workqueue threads
From: Andy Grover @ 2010-03-11 23:50 UTC (permalink / raw)
To: netdev; +Cc: rds-devel, Tina Yang
In-Reply-To: <1268351407-7394-1-git-send-email-andy.grover@oracle.com>
From: Tina Yang <tina.yang@oracle.com>
Create per-cpu workqueue threads instead of a single
krdsd thread. This is a step towards better scalability.
Signed-off-by: Andy Grover <andy.grover@oracle.com>
---
net/rds/threads.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/rds/threads.c b/net/rds/threads.c
index 00fa10e..786c20e 100644
--- a/net/rds/threads.c
+++ b/net/rds/threads.c
@@ -259,7 +259,7 @@ void rds_threads_exit(void)
int __init rds_threads_init(void)
{
- rds_wq = create_singlethread_workqueue("krdsd");
+ rds_wq = create_workqueue("krdsd");
if (rds_wq == NULL)
return -ENOMEM;
--
1.6.3.3
^ permalink raw reply related
* Re: [PATCH v4 2/7] net: remove old tcp_optlen function
From: Simon Horman @ 2010-03-12 0:26 UTC (permalink / raw)
To: William Allen Simpson
Cc: Linus Torvalds, Andrew Morton, Linux Kernel Developers,
Linux Kernel Network Developers, David Miller, Michael Chan
In-Reply-To: <4B98D9A2.8060603@gmail.com>
On Thu, Mar 11, 2010 at 06:53:06AM -0500, William Allen Simpson wrote:
> The tcp_optlen() function returns a potential *negative* unsigned.
>
> In the only two existing files using the old tcp_optlen() function,
> clean up confusing and inconsistent mixing of both byte and word
> offsets, and other coding style issues. Document assumptions.
IIRC, Dave already pointed out that this quoting style which singles him
out isn't appropriate. Perhaps you should consider updating it if you want
him to consider merging this and other changes with similar quotes in the
changelog.
I suggest moving the "No response from testers in 21+ weeks." to
below the "--- " somewhere and dropping everything else except
the Signed-off line that appears after this point.
> Quoth David Miller:
> This is transmit, and the packets can only come from the Linux
> TCP stack, not some external entity.
>
> You're being way too anal here, and adding these checks to
> drivers would be just a lot of rediculious bloat. [sic]
>
> Therefore, there are *no* checks for bad TCP and IP header sizes, nor
> any semantic changes. The drivers should function exactly as existing,
> although usage of int should ameliorate the issues.
> No response from testers in 21+ weeks.
>
> [removed comment references to commit log]
>
> Requires:
> net: tcp_header_len_th and tcp_option_len_th
>
> Signed-off-by: William.Allen.Simpson@gmail.com
> CC: Michael Chan <mchan@broadcom.com>
> ---
> drivers/net/bnx2.c | 29 +++++++++++++-----------
> drivers/net/tg3.c | 60 +++++++++++++++++++++++---------------------------
> include/linux/tcp.h | 5 ----
> 3 files changed, 44 insertions(+), 50 deletions(-)
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* Re: [PATCH 3/4] OMAP3 : clock data: Update name string for EMAC clocks.
From: Paul Walmsley @ 2010-03-12 2:02 UTC (permalink / raw)
To: Sriramakrishnan; +Cc: linux-omap, netdev, davinci-linux-open-source
In-Reply-To: <1268320422-32656-4-git-send-email-srk@ti.com>
On Thu, 11 Mar 2010, Sriramakrishnan wrote:
> The emac driver uses generic name for the module and phy
> clocks. Updated the omap3xxx_clks table to match the names
> used by the Davinci emac driver.
>
> Signed-off-by: Sriramakrishnan <srk@ti.com>
Acked-by: Paul Walmsley <paul@pwsan.com>
At some point, someone should go through that davinci_emac.c driver and
change the DaVinci references to "TI" or something generic, now that this
core exists on DaVinci, OMAP, etc.
> ---
> arch/arm/mach-omap2/clock3xxx_data.c | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/clock3xxx_data.c b/arch/arm/mach-omap2/clock3xxx_data.c
> index d5153b6..989da2e 100644
> --- a/arch/arm/mach-omap2/clock3xxx_data.c
> +++ b/arch/arm/mach-omap2/clock3xxx_data.c
> @@ -3472,8 +3472,8 @@ static struct omap_clk omap3xxx_clks[] = {
> CLK(NULL, "ipss_ick", &ipss_ick, CK_AM35XX),
> CLK(NULL, "rmii_ck", &rmii_ck, CK_AM35XX),
> CLK(NULL, "pclk_ck", &pclk_ck, CK_AM35XX),
> - CLK("davinci_emac", "ick", &emac_ick, CK_AM35XX),
> - CLK("davinci_emac", "fck", &emac_fck, CK_AM35XX),
> + CLK("davinci_emac", "emac_clk", &emac_ick, CK_AM35XX),
> + CLK("davinci_emac", "phy_clk", &emac_fck, CK_AM35XX),
> CLK("vpfe-capture", "master", &vpfe_ick, CK_AM35XX),
> CLK("vpfe-capture", "slave", &vpfe_fck, CK_AM35XX),
> CLK("musb_hdrc", "ick", &hsotgusb_ick_am35xx, CK_AM35XX),
> --
> 1.6.2.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
- Paul
^ permalink raw reply
* Re: [patch 1/5] phonet: use for_each_set_bit()
From: Rémi Denis-Courmont @ 2010-03-12 7:34 UTC (permalink / raw)
To: akpm; +Cc: davem, netdev, akinobu.mita
In-Reply-To: <201003112207.o2BM7nQn013486@imap1.linux-foundation.org>
On Thu, 11 Mar 2010 14:07:49 -0800, akpm@linux-foundation.org wrote:
> From: Akinobu Mita <akinobu.mita@gmail.com>
>
> Replace open-coded loop with for_each_set_bit().
>
> Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com>
> Cc: "David S. Miller" <davem@davemloft.net>
> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Acked-by: Rémi Denis-Courmont <remi.denis-courmont@nokia.com>
--
Rémi Denis-Courmont
http://www.remlab.net
http://fi.linkedin.com/in/remidenis
^ permalink raw reply
* Re: problem with kernel ipconfig over usb ethernet on v.2.6.33-rc3
From: christian pellegrin @ 2010-03-12 7:50 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20100310.143323.248163124.davem@davemloft.net>
Hi,
On Wed, Mar 10, 2010 at 11:33 PM, David Miller <davem@davemloft.net> wrote:
>
> Please let me know if this patch makes your setup work
> properly.
tested and it works, thanks.
Tested-by: Christian Pellegrin <chripell@fsfe.org>
--
Christian Pellegrin, see http://www.evolware.org/chri/
"Real Programmers don't play tennis, or any other sport which requires
you to change clothes. Mountain climbing is OK, and Real Programmers
wear their climbing boots to work in case a mountain should suddenly
spring up in the middle of the computer room."
^ permalink raw reply
* Re: problem with kernel ipconfig over usb ethernet on v.2.6.33-rc3
From: David Miller @ 2010-03-12 7:55 UTC (permalink / raw)
To: chripell; +Cc: netdev
In-Reply-To: <cabda6421003112350l518aab1cxe70d5ffe056914dd@mail.gmail.com>
From: christian pellegrin <chripell@gmail.com>
Date: Fri, 12 Mar 2010 08:50:25 +0100
> Hi,
>
> On Wed, Mar 10, 2010 at 11:33 PM, David Miller <davem@davemloft.net> wrote:
>>
>> Please let me know if this patch makes your setup work
>> properly.
>
> tested and it works, thanks.
>
> Tested-by: Christian Pellegrin <chripell@fsfe.org>
Thanks a lot for testing, I'll push this around.
^ permalink raw reply
* Re: 2.6.34-rc1: rcu lockdep bug?
From: Américo Wang @ 2010-03-12 7:56 UTC (permalink / raw)
To: Paul E. McKenney
Cc: Américo Wang, Peter Zijlstra, LKML,
Linux Kernel Network Developers
In-Reply-To: <20100311161751.GA3804@hack>
(Cc'ing netdev)
On Fri, Mar 12, 2010 at 12:17 AM, Américo Wang <xiyou.wangcong@gmail.com> wrote:
> On Thu, Mar 11, 2010 at 05:45:56AM -0800, Paul E. McKenney wrote:
>>On Thu, Mar 11, 2010 at 06:05:38PM +0800, Américo Wang wrote:
>>> Hello, Paul and Peter,
>>>
>>> Attached is the lockdep warning that I triggered today.
>>>
>>> I am not sure if this is a bug of rcu lockdep, because I am
>>> testing my patch when this occurred. However, in the backtrace,
>>> there is none of the functions that I touched, weird.
>>>
>>> So, please help to check if this is a bug of rcu lockdep.
>>
>>This sort of thing is caused by acquiring the same lock with softirq
>>(AKA BH) blocked and not, which can result in self-deadlock.
>>
>>There was such a bug in the RCU lockdep stuff in -tip, but it has long
>>since been fixed. If you were seeing that bug, rcu_do_batch() would
>>be on the stack, which it does not appear to be.
>>
>>So does your patch involve the usbfs_mutex? Or attempt to manipulate
>>vfs/fs state from withing networking softirq/BH context?
>>
>
> Nope, it is a patch for netpoll, nothing related with usb, nor vfs.
>
Ok, after decoding the lockdep output, it looks like that
netif_receive_skb() should call rcu_read_lock_bh() instead of rcu_read_lock()?
But I don't know if all callers of netif_receive_skb() are in softirq context.
Paul, what do you think?
Thank you.
^ permalink raw reply
* Re: 2.6.34-rc1: rcu lockdep bug?
From: David Miller @ 2010-03-12 8:07 UTC (permalink / raw)
To: xiyou.wangcong; +Cc: paulmck, peterz, linux-kernel, netdev
In-Reply-To: <2375c9f91003112356g1b4164e4pb5f63f0e0e2f310a@mail.gmail.com>
From: Américo Wang <xiyou.wangcong@gmail.com>
Date: Fri, 12 Mar 2010 15:56:03 +0800
> Ok, after decoding the lockdep output, it looks like that
> netif_receive_skb() should call rcu_read_lock_bh() instead of rcu_read_lock()?
> But I don't know if all callers of netif_receive_skb() are in softirq context.
Normally, netif_receive_skb() is invoked from softirq context.
However, via netpoll it can be invoked essentially from any context.
But, when this happens, the networking receive path makes amends such
that this works fine. That's what the netpoll_receive_skb() check in
netif_receive_skb() is for. That check makes it bail out early if the
call to netif_receive_skb() is via a netpoll invocation.
^ permalink raw reply
* Re: [PATCH 33/37] sound/soc: use .dev.of_node instead of .node in struct of_device
From: Jean Delvare @ 2010-03-12 8:26 UTC (permalink / raw)
To: Grant Likely
Cc: Mark Brown, monstr, gregkh, benh, akpm, davem, sfr, jgarzik,
ben-linux, dwmw2, jeremy.kerr, James.Bottomley,
microblaze-uclinux, linux-kernel, linuxppc-dev, sparclinux,
linux-ide, netdev, linux-i2c, devicetree-discuss, linux-scsi,
alsa-devel, timur, lrg
In-Reply-To: <fa686aa41003111322wc1f15b2hd3f653af060f56bf@mail.gmail.com>
On Thu, 11 Mar 2010 14:22:37 -0700, Grant Likely wrote:
> On Thu, Mar 11, 2010 at 12:34 PM, Mark Brown
> <broonie@opensource.wolfsonmicro.com> wrote:
> > On Thu, Mar 11, 2010 at 11:06:50AM -0700, Grant Likely wrote:
> >> .node is being removed
> >>
> >> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
> >
> > Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
> >
> > but please ensure that Liam and especially Timur also check this (both
> > CCed).
> >
> > For enormous patch serieses like this it's really nice if you can ensure
> > that each person is only CCed on the patches that they need to review.
> > Much less stuff in the inbox.
>
> Yeah, sorry about that (and to everyone receiving this thread, I'm
> really sorry. I won't do it again). I've already been yelled at for
> that. What happened is that on a previous series I was yelled at for
> not sending all patches to everyone (so that the patches could be
> reviewed in context). So, naturally, I made sure to include everyone
> on the whole series this time.... doh.
>
> Next time I post I'll constrain it to small chunks.
A good compromise IMHO is to send only the pieces they really have to
see and ack to each person, and provide a pointer to somewhere the full
series can be seen and downloaded for the interested.
--
Jean Delvare
^ permalink raw reply
* Re: 2.6.34-rc1: rcu lockdep bug?
From: Américo Wang @ 2010-03-12 8:59 UTC (permalink / raw)
To: David Miller; +Cc: paulmck, peterz, linux-kernel, netdev
In-Reply-To: <20100312.000705.225033546.davem@davemloft.net>
On Fri, Mar 12, 2010 at 4:07 PM, David Miller <davem@davemloft.net> wrote:
> From: Américo Wang <xiyou.wangcong@gmail.com>
> Date: Fri, 12 Mar 2010 15:56:03 +0800
>
>> Ok, after decoding the lockdep output, it looks like that
>> netif_receive_skb() should call rcu_read_lock_bh() instead of rcu_read_lock()?
>> But I don't know if all callers of netif_receive_skb() are in softirq context.
>
> Normally, netif_receive_skb() is invoked from softirq context.
>
> However, via netpoll it can be invoked essentially from any context.
>
> But, when this happens, the networking receive path makes amends such
> that this works fine. That's what the netpoll_receive_skb() check in
> netif_receive_skb() is for. That check makes it bail out early if the
> call to netif_receive_skb() is via a netpoll invocation.
>
Oh, I see. This means we should call rcu_read_lock_bh() instead.
If Paul has no objections, I will send a patch for this.
Thanks much, David!
^ permalink raw reply
* Re: 2.6.34-rc1: rcu lockdep bug?
From: Eric Dumazet @ 2010-03-12 11:11 UTC (permalink / raw)
To: Américo Wang; +Cc: David Miller, paulmck, peterz, linux-kernel, netdev
In-Reply-To: <2375c9f91003120059g771d162fxefc21beb2ab17b4d@mail.gmail.com>
Le vendredi 12 mars 2010 à 16:59 +0800, Américo Wang a écrit :
> On Fri, Mar 12, 2010 at 4:07 PM, David Miller <davem@davemloft.net> wrote:
> > From: Américo Wang <xiyou.wangcong@gmail.com>
> > Date: Fri, 12 Mar 2010 15:56:03 +0800
> >
> >> Ok, after decoding the lockdep output, it looks like that
> >> netif_receive_skb() should call rcu_read_lock_bh() instead of rcu_read_lock()?
> >> But I don't know if all callers of netif_receive_skb() are in softirq context.
> >
> > Normally, netif_receive_skb() is invoked from softirq context.
> >
> > However, via netpoll it can be invoked essentially from any context.
> >
> > But, when this happens, the networking receive path makes amends such
> > that this works fine. That's what the netpoll_receive_skb() check in
> > netif_receive_skb() is for. That check makes it bail out early if the
> > call to netif_receive_skb() is via a netpoll invocation.
> >
>
> Oh, I see. This means we should call rcu_read_lock_bh() instead.
> If Paul has no objections, I will send a patch for this.
>
Nope, its calling rcu_read_lock() from interrupt context and it should
stay as is (we dont need to disable bh, this has a cpu cost)
^ permalink raw reply
* Re: [PATCH] ipv4: add DiffServ priority based routing
From: Benny Amorsen @ 2010-03-12 11:18 UTC (permalink / raw)
To: David Miller; +Cc: philipp_subx, torsten.schmidt, netdev
In-Reply-To: <20100311.112941.177105216.davem@davemloft.net>
David Miller <davem@davemloft.net> writes:
> Look, this doesn't work. QoS handling and policy belongs in the
> egress point to the network, it's the only way to control this
> properly and prevent abuse.
First, QoS is important even within the network. Modern switches come
pre-configured with sane defaults which ensure that e.g. EF marked
packets get priority over non-EF-marked packets. Cisco, HP, and
Linksys-Cisco at least provide a decent out-of-the-box configuration.
This can obviously be abused, but the solution there is the same as in
network abuses: Either apply the LART or change the configuration of the
switches to be less trusting. We haven't, so far, had a customer where
the LART was necessary, much less had to reconfigure a switch.
So why not let Linux provide the same out-of-the-box experience as the
switches do? If the trust is abused Linux provides lots of tools to make
it less trusting or even to punish the abusers.
/Benny
^ permalink raw reply
* tcpdump -n -i wlan0 fails with -EINVAL on rc1
From: Oliver Neukum @ 2010-03-12 11:26 UTC (permalink / raw)
To: netdev
Hi,
I tried to trace my wlan connection. It failed. The connection itself
works. This worked on earlier kernels.
Regards
Oliver
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2309, ...}) = 0
socket(PF_PACKET, SOCK_RAW, 768) = 3
ioctl(3, SIOCGIFINDEX, {ifr_name="lo", ifr_index=1}) = 0
ioctl(3, SIOCGIFHWADDR, {ifr_name="wlan0", ifr_hwaddr=00:21:5d:c2:62:94}) = 0
ioctl(3, SIOCGIFINDEX, {ifr_name="wlan0", ifr_index=3}) = 0
bind(3, {sa_family=AF_PACKET, proto=0x03, if3, pkttype=PACKET_HOST, addr(0)={0, }, 20) = 0
getsockopt(3, SOL_SOCKET, SO_ERROR, [17179869184], [4]) = 0
setsockopt(3, SOL_PACKET, PACKET_ADD_MEMBERSHIP, "\3\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0", 16) = -1 EINVAL (Invalid argument)
vanamonde:/home/oneukum # ifconfig -a
eth0 Link encap:Ethernet Hardware Adresse 00:24:8C:74:5C:DB
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:24340 errors:0 dropped:0 overruns:0 frame:0
TX packets:24426 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 Sendewarteschlangenlänge:1000
RX bytes:21369424 (20.3 Mb) TX bytes:3849592 (3.6 Mb)
Interrupt:30 Basisadresse:0x2000
lo Link encap:Lokale Schleife
inet Adresse:127.0.0.1 Maske:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:746 errors:0 dropped:0 overruns:0 frame:0
TX packets:746 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 Sendewarteschlangenlänge:0
RX bytes:56324 (55.0 Kb) TX bytes:56324 (55.0 Kb)
pan0 Link encap:Ethernet Hardware Adresse D6:0C:59:F6:43:CB
BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 Sendewarteschlangenlänge:0
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
wlan0 Link encap:Ethernet Hardware Adresse 00:21:5D:C2:62:94
inet Adresse:192.168.1.39 Bcast:192.168.1.255 Maske:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:1389 errors:0 dropped:0 overruns:0 frame:0
TX packets:1708 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 Sendewarteschlangenlänge:1000
RX bytes:901640 (880.5 Kb) TX bytes:256580 (250.5 Kb)
vanamonde:/home/oneukum # lspci
00:00.0 Host bridge: Intel Corporation Mobile 4 Series Chipset Memory Controller Hub (rev 07)
00:01.0 PCI bridge: Intel Corporation Mobile 4 Series Chipset PCI Express Graphics Port (rev 07)
00:1a.0 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #4 (rev 03)
00:1a.1 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #5 (rev 03)
00:1a.2 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #6 (rev 03)
00:1a.7 USB Controller: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #2 (rev 03)
00:1b.0 Audio device: Intel Corporation 82801I (ICH9 Family) HD Audio Controller (rev 03)
00:1c.0 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 1 (rev 03)
00:1c.1 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 2 (rev 03)
00:1c.2 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 3 (rev 03)
00:1c.5 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 6 (rev 03)
00:1d.0 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #1 (rev 03)
00:1d.1 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #2 (rev 03)
00:1d.2 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #3 (rev 03)
00:1d.7 USB Controller: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #1 (rev 03)
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev 93)
00:1f.0 ISA bridge: Intel Corporation ICH9M LPC Interface Controller (rev 03)
00:1f.2 SATA controller: Intel Corporation ICH9M/M-E SATA AHCI Controller (rev 03)
01:00.0 VGA compatible controller: nVidia Corporation G96 [GeForce 9650M GT] (rev a1)
02:00.0 Memory controller: Intel Corporation Turbo Memory Controller (rev 11)
03:00.0 Network controller: Intel Corporation Wireless WiFi Link 5100
06:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 02)
07:01.0 FireWire (IEEE 1394): Ricoh Co Ltd R5C832 IEEE 1394 Controller (rev 05)
07:01.1 SD Host controller: Ricoh Co Ltd R5C822 SD/SDIO/MMC/MS/MSPro Host Adapter (rev 22)
07:01.2 System peripheral: Ricoh Co Ltd R5C843 MMC Host Controller (rev 12)
07:01.3 System peripheral: Ricoh Co Ltd R5C592 Memory Stick Bus Host Adapter (rev 12)
07:01.4 System peripheral: Ricoh Co Ltd xD-Picture Card Controller (rev 12)
^ permalink raw reply
* tcpdump broke in 2.6.34-rc1
From: Jan Engelhardt @ 2010-03-12 12:39 UTC (permalink / raw)
To: netdev; +Cc: Linux Kernel Mailing List
Greetings.
I am currently on 2.6.34-rc1 and found that tcpdump no
longer works (dies with setsockopt: invalid argument). Bisect-narrowed
it down to somewhere between
# good: [13dda80e48439b446d0bc9bab34b91484bc8f533] Merge branch 'davinci-for-lin
# bad: [b7f3a209e9b09b3110ea084836c75f2cd26b29f2] Merge git://git.kernel.org/pub
(bisecting in there gives me even a kernel panic on boot. Great fun. So
I'm leaving it at that.)
The strace output is:
socket(PF_PACKET, SOCK_RAW, 768) = 3
ioctl(3, SIOCGIFINDEX, {ifr_name="lo", ifr_index=1}) = 0
ioctl(3, SIOCGIFHWADDR, {ifr_name="eth0", ifr_hwaddr=08:00:27:6e:34:4a}) = 0
ioctl(3, SIOCGIFINDEX, {ifr_name="eth0", ifr_index=2}) = 0
bind(3, {sa_family=AF_PACKET, proto=0x03, if2, pkttype=PACKET_HOST, addr(0)={0,
}, 20) = 0
getsockopt(3, SOL_SOCKET, SO_ERROR, [17179869184], [4]) = 0
setsockopt(3, SOL_PACKET, PACKET_ADD_MEMBERSHIP,
"\2\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0", 16) = -1 EINVAL (Invalid argument)
^ permalink raw reply
* Re: 2.6.34-rc1: rcu lockdep bug?
From: Américo Wang @ 2010-03-12 13:11 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, paulmck, peterz, linux-kernel, netdev
In-Reply-To: <1268392276.3141.4.camel@edumazet-laptop>
On Fri, Mar 12, 2010 at 7:11 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Le vendredi 12 mars 2010 à 16:59 +0800, Américo Wang a écrit :
>> On Fri, Mar 12, 2010 at 4:07 PM, David Miller <davem@davemloft.net> wrote:
>> > From: Américo Wang <xiyou.wangcong@gmail.com>
>> > Date: Fri, 12 Mar 2010 15:56:03 +0800
>> >
>> >> Ok, after decoding the lockdep output, it looks like that
>> >> netif_receive_skb() should call rcu_read_lock_bh() instead of rcu_read_lock()?
>> >> But I don't know if all callers of netif_receive_skb() are in softirq context.
>> >
>> > Normally, netif_receive_skb() is invoked from softirq context.
>> >
>> > However, via netpoll it can be invoked essentially from any context.
>> >
>> > But, when this happens, the networking receive path makes amends such
>> > that this works fine. That's what the netpoll_receive_skb() check in
>> > netif_receive_skb() is for. That check makes it bail out early if the
>> > call to netif_receive_skb() is via a netpoll invocation.
>> >
>>
>> Oh, I see. This means we should call rcu_read_lock_bh() instead.
>> If Paul has no objections, I will send a patch for this.
>>
>
> Nope, its calling rcu_read_lock() from interrupt context and it should
> stay as is (we dont need to disable bh, this has a cpu cost)
>
Oh, but lockdep complains about rcu_read_lock(), it said
rcu_read_lock() can't be used in softirq context.
Am I missing something?
^ permalink raw reply
* Re: [PATCH v4 2/7] net: remove old tcp_optlen function
From: William Allen Simpson @ 2010-03-12 13:21 UTC (permalink / raw)
To: Simon Horman
Cc: Linus Torvalds, Andrew Morton, Linux Kernel Developers,
Linux Kernel Network Developers, David Miller, Michael Chan
In-Reply-To: <20100312002628.GB20795@verge.net.au>
On 3/11/10 7:26 PM, Simon Horman wrote:
> On Thu, Mar 11, 2010 at 06:53:06AM -0500, William Allen Simpson wrote:
>> The tcp_optlen() function returns a potential *negative* unsigned.
>>
>> In the only two existing files using the old tcp_optlen() function,
>> clean up confusing and inconsistent mixing of both byte and word
>> offsets, and other coding style issues. Document assumptions.
>
> IIRC, Dave already pointed out that this quoting style which singles him
> out isn't appropriate. Perhaps you should consider updating it if you want
> him to consider merging this and other changes with similar quotes in the
> changelog.
>
Thanks! I'm primarily concerned with fixing the bug(s) introduced by
commit ab6a5bb6b28a970104a34f0f6959b73cf61bdc72 that stuffs a negative
number (after subtraction) into an unsigned result. At the time, the
unsigned result was then stuffed back into int again. Later folks
changed the int to u32 (in some places, inconsistently).
However, Dave's requirement that there be no TCP or IP length checking
needs to be documented. Anybody coming to the code later will wonder why
that has not been done (eliminated from earlier versions of my patch).
Rather than spend valuable time refuting Dave and fixing all of the many
problems with TCP and IP lengths elsewhere in the tree (those are more
appropriate to other patches), just document his existing assumptions, and
move on....
Documentation/CodingStyle:
... put the comments at the head of the function, telling people what it
does, and possibly WHY it does it.
The short requirement statement is in the function header comment(s).
The full quote is in the commit log. Folks researching the "git blame"
for this patch in the future can read his rationale and hyperbole.
On Feb 17th, Dave mandated that "(see commit log)" in the source code
comments be removed:
"We do not refer to commit log messages from the source code."
That has been done, causing the patch version to increment.
> I suggest moving the "No response from testers in 21+ weeks." to
> below the "--- " somewhere and dropping everything else except
> the Signed-off line that appears after this point.
>
Thanks! I was unaware that putting such things after "--- " was allowed,
but checking Documentation/SubmittingPatches:
- A marker line containing simply "---".
- Any additional comments not suitable for the changelog.
In my next message, I'll update the change log.
Thanks again!
^ permalink raw reply
* Re: tcpdump broke in 2.6.34-rc1
From: Frans Pop @ 2010-03-12 13:23 UTC (permalink / raw)
To: Jan Engelhardt; +Cc: netdev, linux-kernel
In-Reply-To: <alpine.LSU.2.01.1003120037050.22042@obet.zrqbmnf.qr>
Jan Engelhardt wrote:
> I am currently on 2.6.34-rc1 and found that tcpdump no
> longer works (dies with setsockopt: invalid argument). Bisect-narrowed
> it down to somewhere between
Probably the same as http://lkml.org/lkml/2010/3/9/439, which has an exact
bisect.
Has a follow-up that it's fixed by
http://git.kernel.org/?p=linux/kernel/git/davem/net-2.6.git;a=commit;h=1162563f82b434e3099c9e6c1bbdba846d792f0d
Cheers,
FJP
^ permalink raw reply
* Re: [PATCH v4 2/7] net: remove old tcp_optlen function
From: William Allen Simpson @ 2010-03-12 13:25 UTC (permalink / raw)
To: Linus Torvalds, Andrew Morton
Cc: Linux Kernel Developers, Linux Kernel Network Developers,
David Miller, Michael Chan, Simon Horman
In-Reply-To: <4B98D9A2.8060603@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1167 bytes --]
The tcp_optlen() function returns a potential *negative* unsigned.
In the only two existing files using the old tcp_optlen() function,
clean up confusing and inconsistent mixing of both byte and word
offsets, and other coding style issues. Document assumptions.
Quoth David Miller:
This is transmit, and the packets can only come from the Linux
TCP stack, not some external entity.
You're being way too anal here, and adding these checks to
drivers would be just a lot of rediculious bloat. [sic]
Therefore, there are *no* checks for bad TCP and IP header sizes, nor
any semantic changes. The drivers should function exactly as existing,
although usage of int should ameliorate the issues.
Requires:
net: tcp_header_len_th and tcp_option_len_th
Signed-off-by: William.Allen.Simpson@gmail.com
CC: Michael Chan <mchan@broadcom.com>
---
drivers/net/bnx2.c | 29 +++++++++++++-----------
drivers/net/tg3.c | 60 +++++++++++++++++++++++---------------------------
include/linux/tcp.h | 5 ----
3 files changed, 44 insertions(+), 50 deletions(-)
No response from testers in 21+ weeks.
[removed comment references to commit log]
[-- Attachment #2: len_th+2b4+2.6.34-rc1.patch --]
[-- Type: text/plain, Size: 6918 bytes --]
diff --git a/drivers/net/bnx2.c b/drivers/net/bnx2.c
index 381887b..87607b8 100644
--- a/drivers/net/bnx2.c
+++ b/drivers/net/bnx2.c
@@ -6335,6 +6335,8 @@ bnx2_vlan_rx_register(struct net_device *dev, struct vlan_group *vlgrp)
/* Called with netif_tx_lock.
* bnx2_tx_int() runs without netif_tx_lock unless it needs to call
* netif_wake_queue().
+ *
+ * No TCP or IP length checking, as required by David Miller.
*/
static netdev_tx_t
bnx2_start_xmit(struct sk_buff *skb, struct net_device *dev)
@@ -6378,19 +6380,19 @@ bnx2_start_xmit(struct sk_buff *skb, struct net_device *dev)
(TX_BD_FLAGS_VLAN_TAG | (vlan_tx_tag_get(skb) << 16));
}
#endif
- if ((mss = skb_shinfo(skb)->gso_size)) {
- u32 tcp_opt_len;
- struct iphdr *iph;
+ mss = skb_shinfo(skb)->gso_size;
+ if (mss != 0) {
+ struct tcphdr *th = tcp_hdr(skb);
+ int tcp_opt_words = th->doff - (sizeof(*th) >> 2);
+ /* assumes positive tcp_opt_words without checking */
vlan_tag_flags |= TX_BD_FLAGS_SW_LSO;
- tcp_opt_len = tcp_optlen(skb);
-
if (skb_shinfo(skb)->gso_type & SKB_GSO_TCPV6) {
u32 tcp_off = skb_transport_offset(skb) -
sizeof(struct ipv6hdr) - ETH_HLEN;
- vlan_tag_flags |= ((tcp_opt_len >> 2) << 8) |
+ vlan_tag_flags |= (tcp_opt_words << 8) |
TX_BD_FLAGS_SW_FLAGS;
if (likely(tcp_off == 0))
vlan_tag_flags &= ~TX_BD_FLAGS_TCP6_OFF0_MSK;
@@ -6403,14 +6405,15 @@ bnx2_start_xmit(struct sk_buff *skb, struct net_device *dev)
mss |= (tcp_off & 0xc) << TX_BD_TCP6_OFF2_SHL;
}
} else {
- iph = ip_hdr(skb);
- if (tcp_opt_len || (iph->ihl > 5)) {
- vlan_tag_flags |= ((iph->ihl - 5) +
- (tcp_opt_len >> 2)) << 8;
- }
+ struct iphdr *iph = ip_hdr(skb);
+ int ip_opt_words = iph->ihl - (sizeof(*iph) >> 2);
+ /* assumes positive ip_opt_words without checking */
+ int opt_words = ip_opt_words + tcp_opt_words;
+
+ if (opt_words > 0)
+ vlan_tag_flags |= opt_words << 8;
}
- } else
- mss = 0;
+ }
mapping = pci_map_single(bp->pdev, skb->data, len, PCI_DMA_TODEVICE);
if (pci_dma_mapping_error(bp->pdev, mapping)) {
diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
index 0fa7688..6ad8184 100644
--- a/drivers/net/tg3.c
+++ b/drivers/net/tg3.c
@@ -5481,6 +5481,8 @@ static void tg3_set_txd(struct tg3_napi *tnapi, int entry,
/* hard_start_xmit for devices that don't have any bugs and
* support TG3_FLG2_HW_TSO_2 and TG3_FLG2_HW_TSO_3 only.
+ *
+ * No TCP or IP length checking, as required by David Miller.
*/
static netdev_tx_t tg3_start_xmit(struct sk_buff *skb,
struct net_device *dev)
@@ -5515,9 +5517,9 @@ static netdev_tx_t tg3_start_xmit(struct sk_buff *skb,
entry = tnapi->tx_prod;
base_flags = 0;
- mss = 0;
- if ((mss = skb_shinfo(skb)->gso_size) != 0) {
- int tcp_opt_len, ip_tcp_len;
+ mss = skb_shinfo(skb)->gso_size;
+ if (mss != 0) {
+ struct tcphdr *th;
u32 hdrlen;
if (skb_header_cloned(skb) &&
@@ -5525,18 +5527,16 @@ static netdev_tx_t tg3_start_xmit(struct sk_buff *skb,
dev_kfree_skb(skb);
goto out_unlock;
}
+ th = tcp_hdr(skb);
if (skb_shinfo(skb)->gso_type & SKB_GSO_TCPV6)
hdrlen = skb_headlen(skb) - ETH_HLEN;
else {
struct iphdr *iph = ip_hdr(skb);
- tcp_opt_len = tcp_optlen(skb);
- ip_tcp_len = ip_hdrlen(skb) + sizeof(struct tcphdr);
-
+ hdrlen = ip_hdrlen(skb) + tcp_header_len_th(th);
+ iph->tot_len = htons(mss + hdrlen);
iph->check = 0;
- iph->tot_len = htons(mss + ip_tcp_len + tcp_opt_len);
- hdrlen = ip_tcp_len + tcp_opt_len;
}
if (tp->tg3_flags2 & TG3_FLG2_HW_TSO_3) {
@@ -5550,7 +5550,7 @@ static netdev_tx_t tg3_start_xmit(struct sk_buff *skb,
base_flags |= (TXD_FLAG_CPU_PRE_DMA |
TXD_FLAG_CPU_POST_DMA);
- tcp_hdr(skb)->check = 0;
+ th->check = 0;
}
else if (skb->ip_summed == CHECKSUM_PARTIAL)
@@ -5683,6 +5683,8 @@ tg3_tso_bug_end:
/* hard_start_xmit for devices that have the 4G bug and/or 40-bit bug and
* support TG3_FLG2_HW_TSO_1 or firmware TSO only.
+ *
+ * No TCP or IP length checking, as required by David Miller.
*/
static netdev_tx_t tg3_start_xmit_dma_bug(struct sk_buff *skb,
struct net_device *dev)
@@ -5721,20 +5723,21 @@ static netdev_tx_t tg3_start_xmit_dma_bug(struct sk_buff *skb,
if (skb->ip_summed == CHECKSUM_PARTIAL)
base_flags |= TXD_FLAG_TCPUDP_CSUM;
- if ((mss = skb_shinfo(skb)->gso_size) != 0) {
+ mss = skb_shinfo(skb)->gso_size;
+ if (mss != 0) {
struct iphdr *iph;
- u32 tcp_opt_len, ip_tcp_len, hdr_len;
+ struct tcphdr *th;
+ u32 hdr_len;
+ int opt_bytes;
if (skb_header_cloned(skb) &&
pskb_expand_head(skb, 0, 0, GFP_ATOMIC)) {
dev_kfree_skb(skb);
goto out_unlock;
}
+ th = tcp_hdr(skb);
+ hdr_len = ip_hdrlen(skb) + tcp_header_len_th(th);
- tcp_opt_len = tcp_optlen(skb);
- ip_tcp_len = ip_hdrlen(skb) + sizeof(struct tcphdr);
-
- hdr_len = ip_tcp_len + tcp_opt_len;
if (unlikely((ETH_HLEN + hdr_len) > 80) &&
(tp->tg3_flags2 & TG3_FLG2_TSO_BUG))
return (tg3_tso_bug(tp, skb));
@@ -5746,13 +5749,14 @@ static netdev_tx_t tg3_start_xmit_dma_bug(struct sk_buff *skb,
iph->check = 0;
iph->tot_len = htons(mss + hdr_len);
if (tp->tg3_flags2 & TG3_FLG2_HW_TSO) {
- tcp_hdr(skb)->check = 0;
+ th->check = 0;
base_flags &= ~TXD_FLAG_TCPUDP_CSUM;
} else
- tcp_hdr(skb)->check = ~csum_tcpudp_magic(iph->saddr,
- iph->daddr, 0,
- IPPROTO_TCP,
- 0);
+ th->check = ~csum_tcpudp_magic(iph->saddr, iph->daddr,
+ 0, IPPROTO_TCP, 0);
+
+ opt_bytes = hdr_len - sizeof(*iph) - sizeof(*th);
+ /* assumes positive opt_bytes without checking */
if (tp->tg3_flags2 & TG3_FLG2_HW_TSO_3) {
mss |= (hdr_len & 0xc) << 12;
@@ -5763,19 +5767,11 @@ static netdev_tx_t tg3_start_xmit_dma_bug(struct sk_buff *skb,
mss |= hdr_len << 9;
else if ((tp->tg3_flags2 & TG3_FLG2_HW_TSO_1) ||
GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5705) {
- if (tcp_opt_len || iph->ihl > 5) {
- int tsflags;
-
- tsflags = (iph->ihl - 5) + (tcp_opt_len >> 2);
- mss |= (tsflags << 11);
- }
+ if (opt_bytes > 0)
+ mss |= opt_bytes << (11 - 2);
} else {
- if (tcp_opt_len || iph->ihl > 5) {
- int tsflags;
-
- tsflags = (iph->ihl - 5) + (tcp_opt_len >> 2);
- base_flags |= tsflags << 12;
- }
+ if (opt_bytes > 0)
+ base_flags |= opt_bytes << (12 - 2);
}
}
#if TG3_VLAN_TAG_USED
diff --git a/include/linux/tcp.h b/include/linux/tcp.h
index 48ddeb8..854ad65 100644
--- a/include/linux/tcp.h
+++ b/include/linux/tcp.h
@@ -220,11 +220,6 @@ static inline unsigned int tcp_hdrlen(const struct sk_buff *skb)
return tcp_hdr(skb)->doff * 4;
}
-static inline unsigned int tcp_optlen(const struct sk_buff *skb)
-{
- return (tcp_hdr(skb)->doff - 5) * 4;
-}
-
/* Length of fixed header plus standard options. */
static inline unsigned int tcp_header_len_th(const struct tcphdr *th)
{
--
1.6.3.3
^ permalink raw reply related
* Re: [PATCH 0/7] tcp: bugs and cleanup for 2.6.34-rc1
From: William Allen Simpson @ 2010-03-12 13:27 UTC (permalink / raw)
To: Joe Perches
Cc: Eric Dumazet, Linus Torvalds, Andrew Morton,
Linux Kernel Developers, Linux Kernel Network Developers,
David Miller, Penttilä Mika
In-Reply-To: <1268331251.17462.51.camel@Joe-Laptop.home>
On 3/11/10 1:14 PM, Joe Perches wrote:
> On Thu, 2010-03-11 at 12:38 -0500, William Allen Simpson wrote:
>>> http://git2.kernel.org/?p=linux/kernel/git/davem/net-2.6.git;a=commit;h=28b2774a0d5852236dab77a4147b8b88548110f1
>
> In that patch, it might be better to use
> u16 s_data_desired = 0;
> not
> int s_data_desired = 0;
>
Actually, Eric wrote that part of the message, and that patch. I expect
that ship has sailed, but you could submit a patch....
^ permalink raw reply
* Re: [PATCH 25/37] drivers/infiniband: use .dev.of_node instead of .node in struct of_device
From: Alexander Schmidt @ 2010-03-12 13:30 UTC (permalink / raw)
To: Roland Dreier
Cc: Grant Likely, alsa-devel, broonie, linux-ide, James.Bottomley,
linux-i2c, sparclinux, jeremy.kerr, sfr, linux-scsi, jgarzik,
microblaze-uclinux, devicetree-discuss, Christoph Raisch,
ben-linux, monstr, linuxppc-dev, netdev, gregkh, linux-kernel,
akpm, dwmw2, davem
In-Reply-To: <adavdd2d41q.fsf@roland-alpha.cisco.com>
On Thu, 11 Mar 2010 11:57:53 -0800
Roland Dreier <rdreier@cisco.com> wrote:
> Seems fine... adding EHCA guys just to make sure.
>
> > .node is being removed
> >
> > Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
Acked-by: Alexander Schmidt <alexs@linux.vnet.ibm.com>
^ permalink raw reply
* Re: [PATCH 5/6] smsc95xx: check return code from control messages
From: Steve.Glendinning @ 2010-03-12 13:32 UTC (permalink / raw)
To: Steve.Glendinning; +Cc: netdev
In-Reply-To: <1268245959-13861-6-git-send-email-steve.glendinning@smsc.com>
> +#define check_warn(ret, fmt, args...) \
> + ({ if (ret < 0) netdev_warn(dev->net, fmt, ##args); })
> +
> +#define check_warn_return(ret, format, args...) \
> + ({ if (ret < 0) { netdev_warn(dev->net, fmt, ##args); return ret; }
})
> +
> +#define check_warn_goto_done(ret, format, args...) \
> + ({ if (ret < 0) { netdev_warn(dev->net, fmt, ##args); goto done; }
})
> +
Apologies, this patch is broken.
Please do not apply this anywhere, I'll send a replacement patch shortly.
Steve
^ 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