* Re: [PATCH net-next 1/5] gianfar: Cleanup device refs in gfar_private
From: Claudiu Manoil @ 2013-02-12 17:14 UTC (permalink / raw)
To: Paul Gortmaker; +Cc: netdev, David S. Miller
In-Reply-To: <511A57AA.8070004@windriver.com>
On 2/12/2013 4:54 PM, Paul Gortmaker wrote:
> On 13-02-12 07:47 AM, Claudiu Manoil wrote:
>> * remove unused device_node pointer
>> * remove duplicate SET_NETDEV_DEV()
>> * use device pointer (dev) to simplify the code and to
>> avoid double indirections (esp. on the "fast path")
>
> Ideally, when you find yourself making a list within the longlog,
> that is a hint that you might want to start making it into
> multiple commits, for ease of review. Granted #1 and #2 are
> trivial, but #3 probably could be a separate commit. Did you
> see any change in the object size or the disassembly when
> making change #3?
>
> P.
I didn't inspect the assembly code yet, but this should definitely
generate better, faster code. I don't see why it wouldn't...
Thanks,
Claudiu
^ permalink raw reply
* RE: [net-next 04/10] igb: Fix for sparse warning in igb_get_i2c_client
From: Wyborny, Carolyn @ 2013-02-12 17:17 UTC (permalink / raw)
To: Ben Hutchings, Kirsher, Jeffrey T
Cc: davem@davemloft.net, netdev@vger.kernel.org, gospo@redhat.com,
sassmann@redhat.com
In-Reply-To: <1360602355.2701.5.camel@bwh-desktop.uk.solarflarecom.com>
> -----Original Message-----
> From: Wyborny, Carolyn
> Sent: Tuesday, February 12, 2013 9:13 AM
> To: 'Ben Hutchings'; Kirsher, Jeffrey T
> Cc: davem@davemloft.net; netdev@vger.kernel.org; gospo@redhat.com;
> sassmann@redhat.com
> Subject: RE: [net-next 04/10] igb: Fix for sparse warning in igb_get_i2c_client
>
Please ignore my last email on this. I am working on the sparse error in igb_get_i2c_client as well as a lockdep error that turned up. Patch will be submitted to our internal test system as soon as possible.
Sorry for the thrash,
Carolyn
Carolyn Wyborny
Linux Development
Networking Division
Intel Corporation
^ permalink raw reply
* Re: [PATCH net-next 5/5] gianfar: Fix and cleanup Rx FCB handling
From: Paul Gortmaker @ 2013-02-12 17:19 UTC (permalink / raw)
To: Claudiu Manoil; +Cc: netdev, David S. Miller
In-Reply-To: <1360673237-349-5-git-send-email-claudiu.manoil@freescale.com>
On 13-02-12 07:47 AM, Claudiu Manoil wrote:
> NETIF_F_HW_VLAN_TX flag must not condition RxFCB usage.
The above statement isn't 100% clear to me. Is this the intent?
Currently, gfar_uses_fcb() calls gfar_is_vlan_on() which in turn
checks NETIF_F_HW_VLAN_TX. However there is no relation between
whether FCBs are used and the VLAN transmit state.
> In the case of RxBD rings, FCBs (Frame Control Block) are inserted by
> the eTSEC whenever RCTRL[PRSDEP] is set to a non-zero value. Only one
> FCB is inserted per frame (in the buffer pointed to by the RxBD with
> bit F set). TOE acceleration for receive is enabled for all rx frames
> in this case.
> Indroduce the uses_rxfcb field to signal RxFCB insertion in accordance
> with the specification above (leading to cleaner, less confusing code).
The is_vlan_on() and uses_fcb() calls were more self documenting than
setting/clearing a new single use variable added to priv, I think.
Even if they get changed/simplified, perhaps it is worth keeping them?
Rather than a specific priv->uses_rxfcb field, perhaps it makes sense
to make it more future proof with priv->rctrl field, that is a cached
value of the register, and then you keep gfar_uses_fcb() and it in
turn checks for RCTRL_PRSDEP_INIT bit in rctrl?
Also, the dependency/conditional on FSL_GIANFAR_DEV_HAS_TIMER seems
to simply vanish with this patch, and it isn't clear to me if that
was 100% intentional or not...
P.
--
>
> Cc: Paul Gortmaker <paul.gortmaker@windriver.com>
> Signed-off-by: Claudiu Manoil <claudiu.manoil@freescale.com>
> ---
> drivers/net/ethernet/freescale/gianfar.c | 41 ++++++++++++++---------------
> drivers/net/ethernet/freescale/gianfar.h | 1 +
> 2 files changed, 21 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/net/ethernet/freescale/gianfar.c b/drivers/net/ethernet/freescale/gianfar.c
> index 59fb3bf..3de608c 100644
> --- a/drivers/net/ethernet/freescale/gianfar.c
> +++ b/drivers/net/ethernet/freescale/gianfar.c
> @@ -349,6 +349,9 @@ static void gfar_init_mac(struct net_device *ndev)
> /* Configure the coalescing support */
> gfar_configure_coalescing(priv, 0xFF, 0xFF);
>
> + /* set this when rx hw offload (TOE) functions are being used */
> + priv->uses_rxfcb = 0;
> +
> if (priv->rx_filer_enable) {
> rctrl |= RCTRL_FILREN;
> /* Program the RIR0 reg with the required distribution */
> @@ -359,8 +362,10 @@ static void gfar_init_mac(struct net_device *ndev)
> if (ndev->flags & IFF_PROMISC)
> rctrl |= RCTRL_PROM;
>
> - if (ndev->features & NETIF_F_RXCSUM)
> + if (ndev->features & NETIF_F_RXCSUM) {
> rctrl |= RCTRL_CHECKSUMMING;
> + priv->uses_rxfcb = 1;
> + }
>
> if (priv->extended_hash) {
> rctrl |= RCTRL_EXTHASH;
> @@ -382,11 +387,15 @@ static void gfar_init_mac(struct net_device *ndev)
> }
>
> /* Enable HW time stamping if requested from user space */
> - if (priv->hwts_rx_en)
> + if (priv->hwts_rx_en) {
> rctrl |= RCTRL_PRSDEP_INIT | RCTRL_TS_ENABLE;
> + priv->uses_rxfcb = 1;
> + }
>
> - if (ndev->features & NETIF_F_HW_VLAN_RX)
> + if (ndev->features & NETIF_F_HW_VLAN_RX) {
> rctrl |= RCTRL_VLEX | RCTRL_PRSDEP_INIT;
> + priv->uses_rxfcb = 1;
> + }
>
> /* Init rctrl based on our settings */
> gfar_write(®s->rctrl, rctrl);
> @@ -505,20 +514,6 @@ void unlock_tx_qs(struct gfar_private *priv)
> spin_unlock(&priv->tx_queue[i]->txlock);
> }
>
> -static bool gfar_is_vlan_on(struct gfar_private *priv)
> -{
> - return (priv->ndev->features & NETIF_F_HW_VLAN_RX) ||
> - (priv->ndev->features & NETIF_F_HW_VLAN_TX);
> -}
> -
> -/* Returns 1 if incoming frames use an FCB */
> -static inline int gfar_uses_fcb(struct gfar_private *priv)
> -{
> - return gfar_is_vlan_on(priv) ||
> - (priv->ndev->features & NETIF_F_RXCSUM) ||
> - (priv->device_flags & FSL_GIANFAR_DEV_HAS_TIMER);
> -}
> -
> static void free_tx_pointers(struct gfar_private *priv)
> {
> int i;
> @@ -2331,10 +2326,13 @@ void gfar_check_rx_parser_mode(struct gfar_private *priv)
>
> tempval = gfar_read(®s->rctrl);
> /* If parse is no longer required, then disable parser */
> - if (tempval & RCTRL_REQ_PARSER)
> + if (tempval & RCTRL_REQ_PARSER) {
> tempval |= RCTRL_PRSDEP_INIT;
> - else
> + priv->uses_rxfcb = 1;
> + } else {
> tempval &= ~RCTRL_PRSDEP_INIT;
> + priv->uses_rxfcb = 0;
> + }
> gfar_write(®s->rctrl, tempval);
> }
>
> @@ -2367,6 +2365,7 @@ void gfar_vlan_mode(struct net_device *dev, netdev_features_t features)
> tempval = gfar_read(®s->rctrl);
> tempval |= (RCTRL_VLEX | RCTRL_PRSDEP_INIT);
> gfar_write(®s->rctrl, tempval);
> + priv->uses_rxfcb = 1;
> } else {
> /* Disable VLAN tag extraction */
> tempval = gfar_read(®s->rctrl);
> @@ -2395,7 +2394,7 @@ static int gfar_change_mtu(struct net_device *dev, int new_mtu)
> return -EINVAL;
> }
>
> - if (gfar_uses_fcb(priv))
> + if (priv->uses_rxfcb)
> frame_size += GMAC_FCB_LEN;
>
> frame_size += priv->padding;
> @@ -2766,7 +2765,7 @@ int gfar_clean_rx_ring(struct gfar_priv_rx_q *rx_queue, int rx_work_limit)
> bdp = rx_queue->cur_rx;
> base = rx_queue->rx_bd_base;
>
> - amount_pull = (gfar_uses_fcb(priv) ? GMAC_FCB_LEN : 0);
> + amount_pull = priv->uses_rxfcb ? GMAC_FCB_LEN : 0;
>
> while (!((bdp->status & RXBD_EMPTY) || (--rx_work_limit < 0))) {
> struct sk_buff *newskb;
> diff --git a/drivers/net/ethernet/freescale/gianfar.h b/drivers/net/ethernet/freescale/gianfar.h
> index 5304a58..386f1fe 100644
> --- a/drivers/net/ethernet/freescale/gianfar.h
> +++ b/drivers/net/ethernet/freescale/gianfar.h
> @@ -1061,6 +1061,7 @@ struct gfar_private {
> enum gfar_errata errata;
> unsigned int rx_buffer_size;
>
> + u16 uses_rxfcb;
> u16 padding;
>
> /* HW time stamping enabled flag */
>
^ permalink raw reply
* Re: [patch net-next v5 10/11] tbf: take into account gso skbs
From: Jiri Pirko @ 2013-02-12 17:31 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev, davem, edumazet, jhs, kuznet, j.vimal
In-Reply-To: <1360687182.6884.5.camel@edumazet-glaptop>
Tue, Feb 12, 2013 at 05:39:42PM CET, eric.dumazet@gmail.com wrote:
>On Tue, 2013-02-12 at 11:12 +0100, Jiri Pirko wrote:
>> Ignore max_size check for gso skbs. This check made bigger packets
>> incorrectly dropped. Remove this limitation for gso skbs.
>>
>> Also for peaks, ignore mtu for gso skbs.
>>
>> Signed-off-by: Jiri Pirko <jiri@resnulli.us>
>> ---
>> net/sched/sch_tbf.c | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/net/sched/sch_tbf.c b/net/sched/sch_tbf.c
>> index c8388f3..8973e93 100644
>> --- a/net/sched/sch_tbf.c
>> +++ b/net/sched/sch_tbf.c
>> @@ -121,7 +121,7 @@ static int tbf_enqueue(struct sk_buff *skb, struct Qdisc *sch)
>> struct tbf_sched_data *q = qdisc_priv(sch);
>> int ret;
>>
>> - if (qdisc_pkt_len(skb) > q->max_size)
>> + if (qdisc_pkt_len(skb) > q->max_size && !skb_is_gso(skb))
>> return qdisc_reshape_fail(skb, sch);
>>
>> ret = qdisc_enqueue(skb, q->qdisc);
>> @@ -165,7 +165,7 @@ static struct sk_buff *tbf_dequeue(struct Qdisc *sch)
>>
>> if (q->peak_present) {
>> ptoks = toks + q->ptokens;
>> - if (ptoks > q->mtu)
>> + if (ptoks > q->mtu && !skb_is_gso(skb))
>> ptoks = q->mtu;
>> ptoks -= (s64) psched_l2t_ns(&q->peak, len);
>> }
>
>
>I guess this part is wrong.
>
>If we dont cap ptoks to q->mtu we allow bigger bursts.
>
>Ideally we could re-segment the skb if psched_l2t_ns(&q->peak, len) is
>bigger than q->mtu
Okay - that sounds reasonable. Can you give me some hint how would you
imagine to do this?
Thanks.
Jiri
>
>
>
>
>
>
^ permalink raw reply
* Re: request for stable inclusion
From: David Miller @ 2013-02-12 17:39 UTC (permalink / raw)
To: caiqian; +Cc: netdev
In-Reply-To: <603624767.11006664.1359526575633.JavaMail.root@redhat.com>
From: CAI Qian <caiqian@redhat.com>
Date: Wed, 30 Jan 2013 01:16:15 -0500 (EST)
> 9c13cb8bb477a83b9a3c9e5a5478a4e21294a760
> tg3: Avoid null pointer dereference in tg3_interrupt in netconsole mode
>
> daf3ec688e057f6060fb9bb0819feac7a8bbf45c
> tg3: Fix crc errors on jumbo frame receive
>
> The above 2 commits looks like missing from the stable and the netdev
> stable queues. It was observed that the above issues can be reproduced in
> a kernel that as old as a 2.6.32-based fedora kernel, so I'd like to request
> to include them for 3.0.y, 3.4.y and 3.7.y.
Done.
> 1e47ee8367babe6a5e8adf44a714c7086657b87e
> netfilter: nf_conntrack: fix BUG_ON while removing nf_conntrack with netns
>
> This one looks like a candidate for 3.7-stable but also missing from the
> queues. Do you agree?
This has already been merged.
^ permalink raw reply
* Re: [PATCH] checksum: remove duplicated line of code in csum_fold
From: Pablo Neira Ayuso @ 2013-02-12 17:41 UTC (permalink / raw)
To: David Miller; +Cc: netdev, arnd
In-Reply-To: <20130212.121235.1398926681356889354.davem@davemloft.net>
On Tue, Feb 12, 2013 at 12:12:35PM -0500, David Miller wrote:
> From: pablo@netfilter.org
> Date: Tue, 12 Feb 2013 18:10:03 +0100
>
> > From: Pablo Neira Ayuso <pablo@netfilter.org>
> >
> > Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
>
> I am very sure that those two lines are there intentionally.
> The first addition one can overflow, therefore we need to
> fold again (which cannot overflow).
I was missing that, make sense indeed, thanks.
^ permalink raw reply
* Re: [patch net-next v5 10/11] tbf: take into account gso skbs
From: Eric Dumazet @ 2013-02-12 17:54 UTC (permalink / raw)
To: Jiri Pirko; +Cc: netdev, davem, edumazet, jhs, kuznet, j.vimal
In-Reply-To: <20130212173127.GC18057@minipsycho.orion>
On Tue, 2013-02-12 at 18:31 +0100, Jiri Pirko wrote:
> Tue, Feb 12, 2013 at 05:39:42PM CET, eric.dumazet@gmail.com wrote:
> >Ideally we could re-segment the skb if psched_l2t_ns(&q->peak, len) is
> >bigger than q->mtu
>
> Okay - that sounds reasonable. Can you give me some hint how would you
> imagine to do this?
>
This should be a generic helper, and we could use it in sch_codel /
sch_fq_codel / netem as well.
The trick in a qdisc is that we have to call qdisc_tree_decrease_qlen()
to alert parents that packet count changed.
If a GSO packet with 10 segments is segmented, we have to
qdisc_tree_decrease_qlen(sch, 1 - 10);
^ permalink raw reply
* Re: decnet: /proc/sys/net/decnet sysctl entries disappear
From: Larry Baker @ 2013-02-12 18:16 UTC (permalink / raw)
To: netdev
In-Reply-To: <20130211.200944.1447109432418679998.davem@davemloft.net>
David,
On 11 Feb 2013, at 5:09 PM, David Miller wrote:
>
> Attachments are not the correct way to submit a series of patches.
>
> Please read Documentation/SubmittingPatches
> --
> 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
I found scripts/get_maintainer.pl lists you as a maintainer of the decnet code. It also lists Chrissie Caulfield, but she has pretty much bowed out -- she's the one that told me to send my patches to the net-dev list.
To make this go as smoothly as possible, I'd like your advice about what I should do. So, my first question is: should I submit a bug report describing the faulty behavior and my diagnosis while I work on pruning my patches? To netdev@vger.kernel.org? Second: I made three patch files to account for the API changes to the kernel over time. Should those be individual submissions, related somehow by the tag in [PATCH tag]? Suggestions?
Who changes the banner, me or you? Do you have a recommendation for choosing the version in the banner?
Eric Biederman fixed the root cause of the faulty behavior in kernel 3.4-rc1. None of my systems are that new. He told me about patching stable kernels.
> But there are people who collect bug fixes and apply them to older
> kernels as long as a fix has been made to Linus's kernel and I would
> be happy to do a bit of code review and forward those patches
> to stable@vger.kernel.org if you that is what you are interested in
> doing with them.
Since the current kernel code has apparently fixed the problem, should I send my work to Eric/stable@vger.kernel.org instead of netdev@vger.kernel.org? I do not want to annoy anyone with issues that might seem trivial to most people -- most people have probably never heard of DECnet.
Thank you in advance for your time.
Larry Baker
US Geological Survey
650-329-5608
baker@usgs.gov
^ permalink raw reply
* Re: decnet: /proc/sys/net/decnet sysctl entries disappear
From: Larry Baker @ 2013-02-12 18:28 UTC (permalink / raw)
To: netdev
In-Reply-To: <20130211.235347.25383457019933412.davem@davemloft.net>
David,
On 11 Feb 2013, at 8:53 PM, David Miller wrote:
>
> Never email developers privately, ever. It is both rude and
> also a very poor use of global developer resources.
>
> Always ask on the appropriate, public, mailing list, so that
> any developer, not just me, can answer you.
I'm sorry you feel this way. Other developers have been very gracious in offering assistance and encouragement to solve this problem. I was following the instructions in Documentation/SubmittingPatches you guided me to. Specifically, the instructions to locate the assigned maintainer and "e-mail that person".
> 5) Select e-mail destination.
>
> Look through the MAINTAINERS file and the source code, and determine
> if your change applies to a specific subsystem of the kernel, with
> an assigned maintainer. If so, e-mail that person. The script
> scripts/get_maintainer.pl can be very useful at this step.
>
> If no maintainer is listed, or the maintainer does not respond, send
> your patch to the primary Linux kernel developer's mailing list,
> linux-kernel@vger.kernel.org. Most kernel developers monitor this
> e-mail list, and can comment on your changes.
scripts/get_maintainer.pl said that was you.
Larry Baker
US Geological Survey
650-329-5608
baker@usgs.gov
^ permalink raw reply
* Re: decnet: /proc/sys/net/decnet sysctl entries disappear
From: Joe Perches @ 2013-02-12 18:43 UTC (permalink / raw)
To: Larry Baker; +Cc: netdev
In-Reply-To: <A16FE98D-5476-4AB2-855F-0CDA3944E7F5@usgs.gov>
On Tue, 2013-02-12 at 10:28 -0800, Larry Baker wrote:
> On 11 Feb 2013, at 8:53 PM, David Miller wrote:
> > Never email developers privately, ever. It is both rude and
> > also a very poor use of global developer resources.
> >
> > Always ask on the appropriate, public, mailing list, so that
> > any developer, not just me, can answer you.
[]
> scripts/get_maintainer.pl said that was you.
It also said the netdev and lkml mailing lists.
I presume David is objecting not to the email,
but to the email without the cc's to the
appropriate mailing lists.
^ permalink raw reply
* Re: decnet: /proc/sys/net/decnet sysctl entries disappear
From: Ben Hutchings @ 2013-02-12 18:55 UTC (permalink / raw)
To: Larry Baker; +Cc: netdev
In-Reply-To: <A16FE98D-5476-4AB2-855F-0CDA3944E7F5@usgs.gov>
On Tue, 2013-02-12 at 10:28 -0800, Larry Baker wrote:
> David,
>
> On 11 Feb 2013, at 8:53 PM, David Miller wrote:
>
> >
> > Never email developers privately, ever. It is both rude and
> > also a very poor use of global developer resources.
> >
> > Always ask on the appropriate, public, mailing list, so that
> > any developer, not just me, can answer you.
>
> I'm sorry you feel this way. Other developers have been very gracious
> in offering assistance and encouragement to solve this problem. I was
> following the instructions in Documentation/SubmittingPatches you
> guided me to. Specifically, the instructions to locate the assigned
> maintainer and "e-mail that person".
It should also say to mail the related list(s); that's apparently a
documentation error.
> > 5) Select e-mail destination.
> >
> > Look through the MAINTAINERS file and the source code, and determine
> > if your change applies to a specific subsystem of the kernel, with
> > an assigned maintainer. If so, e-mail that person. The script
> > scripts/get_maintainer.pl can be very useful at this step.
> >
> > If no maintainer is listed, or the maintainer does not respond, send
> > your patch to the primary Linux kernel developer's mailing list,
> > linux-kernel@vger.kernel.org. Most kernel developers monitor this
> > e-mail list, and can comment on your changes.
>
> scripts/get_maintainer.pl said that was you.
David Miller is in overall charge of networking, so for any code under
drivers/net/ or net/ that doesn't have its own maintainer, he'll show up
as the primary maintainer. But in reality I doubt he spends much time
thinking about relatively obscure areas that have lost their specialist
maintainer.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: decnet: /proc/sys/net/decnet sysctl entries disappear
From: Larry Baker @ 2013-02-12 18:58 UTC (permalink / raw)
To: Joe Perches; +Cc: netdev
In-Reply-To: <1360694580.17456.2.camel@joe-AO722>
Joe,
On 12 Feb 2013, at 10:43 AM, Joe Perches wrote:
> On Tue, 2013-02-12 at 10:28 -0800, Larry Baker wrote:
>> On 11 Feb 2013, at 8:53 PM, David Miller wrote:
>>> Never email developers privately, ever. It is both rude and
>>> also a very poor use of global developer resources.
>>>
>>> Always ask on the appropriate, public, mailing list, so that
>>> any developer, not just me, can answer you.
> []
>> scripts/get_maintainer.pl said that was you.
>
> It also said the netdev and lkml mailing lists.
>
> I presume David is objecting not to the email,
> but to the email without the cc's to the
> appropriate mailing lists.
>
>
The instructions say "e-mail that person". There are only two persons listed as decnet maintainers, one of which has told me she is not involved much any more. The instructions only mention sending to mailing lists if the maintainer does not respond.
I explicitly followed the instructions.
If the developers want mailing lists CC'd right off the bat, the instructions should be updated.
Larry Baker
US Geological Survey
650-329-5608
baker@usgs.gov
^ permalink raw reply
* Re: decnet: /proc/sys/net/decnet sysctl entries disappear
From: Joe Perches @ 2013-02-12 19:15 UTC (permalink / raw)
To: Larry Baker; +Cc: netdev
In-Reply-To: <6AA3F012-5843-4D66-AB3D-F8D40D458450@usgs.gov>
On Tue, 2013-02-12 at 10:58 -0800, Larry Baker wrote:
> The instructions say "e-mail that person". There are only two persons
> listed as decnet maintainers, one of which has told me she is not
> involved much any more. The instructions only mention sending to
> mailing lists if the maintainer does not respond.
>
> I explicitly followed the instructions.
I think you need to read a little farther.
> If the developers want mailing lists CC'd right off the bat, the instructions should be updated.
from: Documentation/SubmittingPatches
6) Select your CC (e-mail carbon copy) list.
Unless you have a reason NOT to do so, CC linux-kernel@vger.kernel.org.
^ permalink raw reply
* Re: [net-next (TAKE 2) 0/4] IPv6 over Firewire
From: Stephan Gatzka @ 2013-02-12 19:46 UTC (permalink / raw)
To: YOSHIFUJI Hideaki; +Cc: netdev, linux1394-devel, davem, stefanr
In-Reply-To: <5118EE78.5000508@linux-ipv6.org>
> Have you tried after skb->ip_summed = CHECKSUM_NONE change?
>
> --yoshfuji
No, I' don't think so.
Nevertheless, there is some hope that I can try out your patch set
during this week and find some insight why IPv6 does not work with MacOS X.
Regards,
Stephan
^ permalink raw reply
* [PATCH net] ixgbe: Only set gso_type to SKB_GSO_TCPV4 as RSC does not support IPv6
From: Alexander Duyck @ 2013-02-12 19:45 UTC (permalink / raw)
To: netdev; +Cc: jeffrey.t.kirsher, davem, mst
The original fix that was applied for setting gso_type required more change
than necessary because it was assumed ixgbe does RSC on IPv6 frames and this
is not correct. RSC is only supported with IPv4/TCP frames only. As such we
can simplify the fix and avoid the unnecessary move of eth_type_trans.
The previous patch "ixgbe: fix gso type" and this patch reduce the entire fix
to one line that sets gso_type to TCPV4 if the frame is RSC.
Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
---
Sorry about not speaking up last week which would have allowed us to avoid
this patch but I was out on a business trip and had limited access to email
between flights.
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 9 +++------
1 files changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
index e1b2d22..b3e3294 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
@@ -1401,10 +1401,7 @@ static void ixgbe_set_rsc_gso_size(struct ixgbe_ring *ring,
/* set gso_size to avoid messing up TCP MSS */
skb_shinfo(skb)->gso_size = DIV_ROUND_UP((skb->len - hdr_len),
IXGBE_CB(skb)->append_cnt);
- if (skb->protocol == __constant_htons(ETH_P_IPV6))
- skb_shinfo(skb)->gso_type = SKB_GSO_TCPV6;
- else
- skb_shinfo(skb)->gso_type = SKB_GSO_TCPV4;
+ skb_shinfo(skb)->gso_type = SKB_GSO_TCPV4;
}
static void ixgbe_update_rsc_stats(struct ixgbe_ring *rx_ring,
@@ -1439,8 +1436,6 @@ static void ixgbe_process_skb_fields(struct ixgbe_ring *rx_ring,
{
struct net_device *dev = rx_ring->netdev;
- skb->protocol = eth_type_trans(skb, dev);
-
ixgbe_update_rsc_stats(rx_ring, skb);
ixgbe_rx_hash(rx_ring, rx_desc, skb);
@@ -1456,6 +1451,8 @@ static void ixgbe_process_skb_fields(struct ixgbe_ring *rx_ring,
}
skb_record_rx_queue(skb, rx_ring->queue_index);
+
+ skb->protocol = eth_type_trans(skb, dev);
}
static void ixgbe_rx_skb(struct ixgbe_q_vector *q_vector,
^ permalink raw reply related
* [ 24/61] net: calxedaxgmac: throw away overrun frames
From: Greg Kroah-Hartman @ 2013-02-12 20:34 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Rob Herring, David S. Miller, netdev
In-Reply-To: <20130212203417.890993903@linuxfoundation.org>
3.7-stable review patch. If anyone has any objections, please let me know.
------------------
From: Rob Herring <rob.herring@calxeda.com>
[ Upstream commit d6fb3be544b46a7611a3373fcaa62b5b0be01888 ]
The xgmac driver assumes 1 frame per descriptor. If a frame larger than
the descriptor's buffer size is received, the frame will spill over into
the next descriptor. So check for received frames that span more than one
descriptor and discard them. This prevents a crash if we receive erroneous
large packets.
Signed-off-by: Rob Herring <rob.herring@calxeda.com>
Cc: netdev@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/net/ethernet/calxeda/xgmac.c | 4 ++++
1 file changed, 4 insertions(+)
--- a/drivers/net/ethernet/calxeda/xgmac.c
+++ b/drivers/net/ethernet/calxeda/xgmac.c
@@ -546,6 +546,10 @@ static int desc_get_rx_status(struct xgm
return -1;
}
+ /* All frames should fit into a single buffer */
+ if (!(status & RXDESC_FIRST_SEG) || !(status & RXDESC_LAST_SEG))
+ return -1;
+
/* Check if packet has checksum already */
if ((status & RXDESC_FRAME_TYPE) && (status & RXDESC_EXT_STATUS) &&
!(ext_status & RXDESC_IP_PAYLOAD_MASK))
^ permalink raw reply
* [ 49/61] sctp: refactor sctp_outq_teardown to insure proper re-initalization
From: Greg Kroah-Hartman @ 2013-02-12 20:35 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Neil Horman, Jamie Parsons,
Vlad Yasevich, David S. Miller, netdev
In-Reply-To: <20130212203417.890993903@linuxfoundation.org>
3.7-stable review patch. If anyone has any objections, please let me know.
------------------
From: Neil Horman <nhorman@tuxdriver.com>
[ Upstream commit 2f94aabd9f6c925d77aecb3ff020f1cc12ed8f86 ]
Jamie Parsons reported a problem recently, in which the re-initalization of an
association (The duplicate init case), resulted in a loss of receive window
space. He tracked down the root cause to sctp_outq_teardown, which discarded
all the data on an outq during a re-initalization of the corresponding
association, but never reset the outq->outstanding_data field to zero. I wrote,
and he tested this fix, which does a proper full re-initalization of the outq,
fixing this problem, and hopefully future proofing us from simmilar issues down
the road.
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
Reported-by: Jamie Parsons <Jamie.Parsons@metaswitch.com>
Tested-by: Jamie Parsons <Jamie.Parsons@metaswitch.com>
CC: Jamie Parsons <Jamie.Parsons@metaswitch.com>
CC: Vlad Yasevich <vyasevich@gmail.com>
CC: "David S. Miller" <davem@davemloft.net>
CC: netdev@vger.kernel.org
Acked-by: Vlad Yasevich <vyasevich@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/sctp/outqueue.c | 12 ++++++++----
1 file changed, 8 insertions(+), 4 deletions(-)
--- a/net/sctp/outqueue.c
+++ b/net/sctp/outqueue.c
@@ -224,7 +224,7 @@ void sctp_outq_init(struct sctp_associat
/* Free the outqueue structure and any related pending chunks.
*/
-void sctp_outq_teardown(struct sctp_outq *q)
+static void __sctp_outq_teardown(struct sctp_outq *q)
{
struct sctp_transport *transport;
struct list_head *lchunk, *temp;
@@ -277,8 +277,6 @@ void sctp_outq_teardown(struct sctp_outq
sctp_chunk_free(chunk);
}
- q->error = 0;
-
/* Throw away any leftover control chunks. */
list_for_each_entry_safe(chunk, tmp, &q->control_chunk_list, list) {
list_del_init(&chunk->list);
@@ -286,11 +284,17 @@ void sctp_outq_teardown(struct sctp_outq
}
}
+void sctp_outq_teardown(struct sctp_outq *q)
+{
+ __sctp_outq_teardown(q);
+ sctp_outq_init(q->asoc, q);
+}
+
/* Free the outqueue structure and any related pending chunks. */
void sctp_outq_free(struct sctp_outq *q)
{
/* Throw away leftover chunks. */
- sctp_outq_teardown(q);
+ __sctp_outq_teardown(q);
/* If we were kmalloc()'d, free the memory. */
if (q->malloced)
^ permalink raw reply
* [ 14/22] sctp: refactor sctp_outq_teardown to insure proper re-initalization
From: Greg Kroah-Hartman @ 2013-02-12 20:36 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Neil Horman, Jamie Parsons,
Vlad Yasevich, David S. Miller, netdev
In-Reply-To: <20130212203413.459836020@linuxfoundation.org>
3.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Neil Horman <nhorman@tuxdriver.com>
[ Upstream commit 2f94aabd9f6c925d77aecb3ff020f1cc12ed8f86 ]
Jamie Parsons reported a problem recently, in which the re-initalization of an
association (The duplicate init case), resulted in a loss of receive window
space. He tracked down the root cause to sctp_outq_teardown, which discarded
all the data on an outq during a re-initalization of the corresponding
association, but never reset the outq->outstanding_data field to zero. I wrote,
and he tested this fix, which does a proper full re-initalization of the outq,
fixing this problem, and hopefully future proofing us from simmilar issues down
the road.
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
Reported-by: Jamie Parsons <Jamie.Parsons@metaswitch.com>
Tested-by: Jamie Parsons <Jamie.Parsons@metaswitch.com>
CC: Jamie Parsons <Jamie.Parsons@metaswitch.com>
CC: Vlad Yasevich <vyasevich@gmail.com>
CC: "David S. Miller" <davem@davemloft.net>
CC: netdev@vger.kernel.org
Acked-by: Vlad Yasevich <vyasevich@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/sctp/outqueue.c | 12 ++++++++----
1 file changed, 8 insertions(+), 4 deletions(-)
--- a/net/sctp/outqueue.c
+++ b/net/sctp/outqueue.c
@@ -223,7 +223,7 @@ void sctp_outq_init(struct sctp_associat
/* Free the outqueue structure and any related pending chunks.
*/
-void sctp_outq_teardown(struct sctp_outq *q)
+static void __sctp_outq_teardown(struct sctp_outq *q)
{
struct sctp_transport *transport;
struct list_head *lchunk, *temp;
@@ -276,8 +276,6 @@ void sctp_outq_teardown(struct sctp_outq
sctp_chunk_free(chunk);
}
- q->error = 0;
-
/* Throw away any leftover control chunks. */
list_for_each_entry_safe(chunk, tmp, &q->control_chunk_list, list) {
list_del_init(&chunk->list);
@@ -285,11 +283,17 @@ void sctp_outq_teardown(struct sctp_outq
}
}
+void sctp_outq_teardown(struct sctp_outq *q)
+{
+ __sctp_outq_teardown(q);
+ sctp_outq_init(q->asoc, q);
+}
+
/* Free the outqueue structure and any related pending chunks. */
void sctp_outq_free(struct sctp_outq *q)
{
/* Throw away leftover chunks. */
- sctp_outq_teardown(q);
+ __sctp_outq_teardown(q);
/* If we were kmalloc()'d, free the memory. */
if (q->malloced)
^ permalink raw reply
* [ 12/36] net: calxedaxgmac: throw away overrun frames
From: Greg Kroah-Hartman @ 2013-02-12 20:41 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Rob Herring, David S. Miller, netdev
In-Reply-To: <20130212203857.305594226@linuxfoundation.org>
3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Rob Herring <rob.herring@calxeda.com>
[ Upstream commit d6fb3be544b46a7611a3373fcaa62b5b0be01888 ]
The xgmac driver assumes 1 frame per descriptor. If a frame larger than
the descriptor's buffer size is received, the frame will spill over into
the next descriptor. So check for received frames that span more than one
descriptor and discard them. This prevents a crash if we receive erroneous
large packets.
Signed-off-by: Rob Herring <rob.herring@calxeda.com>
Cc: netdev@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/net/ethernet/calxeda/xgmac.c | 4 ++++
1 file changed, 4 insertions(+)
--- a/drivers/net/ethernet/calxeda/xgmac.c
+++ b/drivers/net/ethernet/calxeda/xgmac.c
@@ -547,6 +547,10 @@ static int desc_get_rx_status(struct xgm
return -1;
}
+ /* All frames should fit into a single buffer */
+ if (!(status & RXDESC_FIRST_SEG) || !(status & RXDESC_LAST_SEG))
+ return -1;
+
/* Check if packet has checksum already */
if ((status & RXDESC_FRAME_TYPE) && (status & RXDESC_EXT_STATUS) &&
!(ext_status & RXDESC_IP_PAYLOAD_MASK))
^ permalink raw reply
* [ 24/36] sctp: refactor sctp_outq_teardown to insure proper re-initalization
From: Greg Kroah-Hartman @ 2013-02-12 20:41 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Neil Horman, Jamie Parsons,
Vlad Yasevich, David S. Miller, netdev
In-Reply-To: <20130212203857.305594226@linuxfoundation.org>
3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Neil Horman <nhorman@tuxdriver.com>
[ Upstream commit 2f94aabd9f6c925d77aecb3ff020f1cc12ed8f86 ]
Jamie Parsons reported a problem recently, in which the re-initalization of an
association (The duplicate init case), resulted in a loss of receive window
space. He tracked down the root cause to sctp_outq_teardown, which discarded
all the data on an outq during a re-initalization of the corresponding
association, but never reset the outq->outstanding_data field to zero. I wrote,
and he tested this fix, which does a proper full re-initalization of the outq,
fixing this problem, and hopefully future proofing us from simmilar issues down
the road.
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
Reported-by: Jamie Parsons <Jamie.Parsons@metaswitch.com>
Tested-by: Jamie Parsons <Jamie.Parsons@metaswitch.com>
CC: Jamie Parsons <Jamie.Parsons@metaswitch.com>
CC: Vlad Yasevich <vyasevich@gmail.com>
CC: "David S. Miller" <davem@davemloft.net>
CC: netdev@vger.kernel.org
Acked-by: Vlad Yasevich <vyasevich@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/sctp/outqueue.c | 12 ++++++++----
1 file changed, 8 insertions(+), 4 deletions(-)
--- a/net/sctp/outqueue.c
+++ b/net/sctp/outqueue.c
@@ -223,7 +223,7 @@ void sctp_outq_init(struct sctp_associat
/* Free the outqueue structure and any related pending chunks.
*/
-void sctp_outq_teardown(struct sctp_outq *q)
+static void __sctp_outq_teardown(struct sctp_outq *q)
{
struct sctp_transport *transport;
struct list_head *lchunk, *temp;
@@ -276,8 +276,6 @@ void sctp_outq_teardown(struct sctp_outq
sctp_chunk_free(chunk);
}
- q->error = 0;
-
/* Throw away any leftover control chunks. */
list_for_each_entry_safe(chunk, tmp, &q->control_chunk_list, list) {
list_del_init(&chunk->list);
@@ -285,11 +283,17 @@ void sctp_outq_teardown(struct sctp_outq
}
}
+void sctp_outq_teardown(struct sctp_outq *q)
+{
+ __sctp_outq_teardown(q);
+ sctp_outq_init(q->asoc, q);
+}
+
/* Free the outqueue structure and any related pending chunks. */
void sctp_outq_free(struct sctp_outq *q)
{
/* Throw away leftover chunks. */
- sctp_outq_teardown(q);
+ __sctp_outq_teardown(q);
/* If we were kmalloc()'d, free the memory. */
if (q->malloced)
^ permalink raw reply
* Re: [PATCH net] ixgbe: Only set gso_type to SKB_GSO_TCPV4 as RSC does not support IPv6
From: Michael S. Tsirkin @ 2013-02-12 20:51 UTC (permalink / raw)
To: Alexander Duyck; +Cc: netdev, jeffrey.t.kirsher, davem
In-Reply-To: <20130212193624.17818.13843.stgit@ahduyck-cp1.jf.intel.com>
On Tue, Feb 12, 2013 at 11:45:44AM -0800, Alexander Duyck wrote:
> The original fix that was applied for setting gso_type required more change
> than necessary because it was assumed ixgbe does RSC on IPv6 frames and this
> is not correct. RSC is only supported with IPv4/TCP frames only. As such we
> can simplify the fix and avoid the unnecessary move of eth_type_trans.
>
> The previous patch "ixgbe: fix gso type" and this patch reduce the entire fix
> to one line that sets gso_type to TCPV4 if the frame is RSC.
>
> Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
Is this architectural? Is it safe to assume there won't be an update
that does RSC on IPv6?
> ---
>
> Sorry about not speaking up last week which would have allowed us to avoid
> this patch but I was out on a business trip and had limited access to email
> between flights.
>
> drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 9 +++------
> 1 files changed, 3 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
> index e1b2d22..b3e3294 100644
> --- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
> +++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
> @@ -1401,10 +1401,7 @@ static void ixgbe_set_rsc_gso_size(struct ixgbe_ring *ring,
> /* set gso_size to avoid messing up TCP MSS */
> skb_shinfo(skb)->gso_size = DIV_ROUND_UP((skb->len - hdr_len),
> IXGBE_CB(skb)->append_cnt);
> - if (skb->protocol == __constant_htons(ETH_P_IPV6))
> - skb_shinfo(skb)->gso_type = SKB_GSO_TCPV6;
> - else
> - skb_shinfo(skb)->gso_type = SKB_GSO_TCPV4;
> + skb_shinfo(skb)->gso_type = SKB_GSO_TCPV4;
> }
>
> static void ixgbe_update_rsc_stats(struct ixgbe_ring *rx_ring,
> @@ -1439,8 +1436,6 @@ static void ixgbe_process_skb_fields(struct ixgbe_ring *rx_ring,
> {
> struct net_device *dev = rx_ring->netdev;
>
> - skb->protocol = eth_type_trans(skb, dev);
> -
> ixgbe_update_rsc_stats(rx_ring, skb);
>
> ixgbe_rx_hash(rx_ring, rx_desc, skb);
> @@ -1456,6 +1451,8 @@ static void ixgbe_process_skb_fields(struct ixgbe_ring *rx_ring,
> }
>
> skb_record_rx_queue(skb, rx_ring->queue_index);
> +
> + skb->protocol = eth_type_trans(skb, dev);
> }
>
> static void ixgbe_rx_skb(struct ixgbe_q_vector *q_vector,
^ permalink raw reply
* Re: [PATCH net-next v2] net: sctp: remove unused multiple cookie keys
From: David Miller @ 2013-02-12 21:05 UTC (permalink / raw)
To: vyasevich; +Cc: dborkman, linux-sctp, netdev, nhorman, vyasevic
In-Reply-To: <511A631A.60803@gmail.com>
From: Vlad Yasevich <vyasevich@gmail.com>
Date: Tue, 12 Feb 2013 10:43:22 -0500
> On 02/12/2013 10:15 AM, Daniel Borkmann wrote:
>> Vlad says: The whole multiple cookie keys code is completely unused
>> and has been all this time. Noone uses anything other then the
>> secret_key[0] since there is no changeover support anywhere.
>>
>> Thus, for now clean up its left-over fragments.
>>
>> Cc: Neil Horman <nhorman@tuxdriver.com>
>> Cc: Vlad Yasevich <vyasevic@redhat.com>
>
> Acked-by: Vlad Yasevich <vyasevich@gmail.com>
Applied, thanks everyone.
^ permalink raw reply
* Re: bridge interface initial carrier state
From: Jiri Pirko @ 2013-02-12 21:06 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Dan Williams, netdev
In-Reply-To: <20130211135836.2220ca68@nehalam.linuxnetplumber.net>
Mon, Feb 11, 2013 at 10:58:36PM CET, stephen@networkplumber.org wrote:
>On Mon, 11 Feb 2013 14:01:55 -0600
>Dan Williams <dcbw@redhat.com> wrote:
>
>> Hi,
>>
>> I'm wondering if the initial carrier state of 'on' is intentional for a
>> bridge without ports; immediately after adding ports, the carrier is
>> recalculated and depends on the combined state of each port's carrier
>> and STP forwarding state. So a userspace program attempting to decide
>> whether the bridge was usable or not has to look at both (a) how many
>> ports are available and (b) bridge carrier state, instead of just
>> looking at the bridge carrier state.
>>
>> Dan
>
>It really should be off when no ports are present, but some initial startup
>scripts broke when it was that way.
How so? Can you give me an example of that script?
I think that any script should be able to handle a situation when carrier
of some device is down...
>--
>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: [PATCH] net: qmi_wwan: add Yota / Megafon M100-1 4g modem
From: David Miller @ 2013-02-12 21:06 UTC (permalink / raw)
To: bjorn; +Cc: netdev, linux-usb
In-Reply-To: <1360672970-32081-1-git-send-email-bjorn@mork.no>
From: Bjørn Mork <bjorn@mork.no>
Date: Tue, 12 Feb 2013 13:42:50 +0100
> Interface layout:
...
> Signed-off-by: Bjørn Mork <bjorn@mork.no>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] net: fix infinite loop in __skb_recv_datagram()
From: David Miller @ 2013-02-12 21:07 UTC (permalink / raw)
To: eric.dumazet; +Cc: tt.rantala, netdev, davej, xemul
In-Reply-To: <1360685813.13993.12.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Tue, 12 Feb 2013 08:16:53 -0800
> From: Eric Dumazet <edumazet@google.com>
>
> Tommi was fuzzing with trinity and reported the following problem :
>
> commit 3f518bf745 (datagram: Add offset argument to __skb_recv_datagram)
> missed that a raw socket receive queue can contain skbs with no payload.
>
> We can loop in __skb_recv_datagram() with MSG_PEEK mode, because
> wait_for_packet() is not prepared to skip these skbs.
...
> Reported-by: Tommi Rantala <tt.rantala@gmail.com>
> Tested-by: Tommi Rantala <tt.rantala@gmail.com>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Applied, thanks.
^ 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