* Re: [PATCH net -v2] [BUGFIX] bonding: use local function pointer of bond->recv_probe in bond_handle_frame
From: Eric Dumazet @ 2011-10-19 4:05 UTC (permalink / raw)
To: Mitsuo Hayasaka
Cc: Jay Vosburgh, Andy Gospodarek, netdev, linux-kernel,
yrl.pp-manager.tt, WANG Cong
In-Reply-To: <20111013020429.3554.78679.stgit@ltc219.sdl.hitachi.co.jp>
Le jeudi 13 octobre 2011 à 11:04 +0900, Mitsuo Hayasaka a écrit :
> The bond->recv_probe is called in bond_handle_frame() when
> a packet is received, but bond_close() sets it to NULL. So,
> a panic occurs when both functions work in parallel.
>
> Why this happen:
> After null pointer check of bond->recv_probe, an sk_buff is
> duplicated and bond->recv_probe is called in bond_handle_frame.
> So, a panic occurs when bond_close() is called between the
> check and call of bond->recv_probe.
>
> Patch:
> This patch uses a local function pointer of bond->recv_probe
> in bond_handle_frame(). So, it can avoid the null pointer
> dereference.
>
>
> Signed-off-by: Mitsuo Hayasaka <mitsuo.hayasaka.hu@hitachi.com>
> Cc: Jay Vosburgh <fubar@us.ibm.com>
> Cc: Andy Gospodarek <andy@greyhouse.net>
> Cc: Eric Dumazet <eric.dumazet@gmail.com>
> Cc: WANG Cong <xiyou.wangcong@gmail.com>
> ---
>
> drivers/net/bonding/bond_main.c | 7 +++++--
> 1 files changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
> index 6d79b78..de3d351 100644
> --- a/drivers/net/bonding/bond_main.c
> +++ b/drivers/net/bonding/bond_main.c
> @@ -1435,6 +1435,8 @@ static rx_handler_result_t bond_handle_frame(struct sk_buff **pskb)
> struct sk_buff *skb = *pskb;
> struct slave *slave;
> struct bonding *bond;
> + void (*recv_probe)(struct sk_buff *, struct bonding *,
> + struct slave *);
>
> skb = skb_share_check(skb, GFP_ATOMIC);
> if (unlikely(!skb))
> @@ -1448,11 +1450,12 @@ static rx_handler_result_t bond_handle_frame(struct sk_buff **pskb)
> if (bond->params.arp_interval)
> slave->dev->last_rx = jiffies;
>
> - if (bond->recv_probe) {
> + recv_probe = ACCESS_ONCE(bond->recv_probe);
> + if (recv_probe) {
> struct sk_buff *nskb = skb_clone(skb, GFP_ATOMIC);
>
> if (likely(nskb)) {
> - bond->recv_probe(nskb, bond, slave);
> + recv_probe(nskb, bond, slave);
> dev_kfree_skb(nskb);
> }
> }
>
Sorry, I forgot to add my official ack. Even if not a perfect patch, its
a step into right direction.
Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
^ permalink raw reply
* Re: [PATCH net -v2] [BUGFIX] bonding: use local function pointer of bond->recv_probe in bond_handle_frame
From: David Miller @ 2011-10-19 4:03 UTC (permalink / raw)
To: mitsuo.hayasaka.hu
Cc: fubar, andy, netdev, linux-kernel, yrl.pp-manager.tt,
eric.dumazet, xiyou.wangcong
In-Reply-To: <20111013020429.3554.78679.stgit@ltc219.sdl.hitachi.co.jp>
From: Mitsuo Hayasaka <mitsuo.hayasaka.hu@hitachi.com>
Date: Thu, 13 Oct 2011 11:04:29 +0900
> The bond->recv_probe is called in bond_handle_frame() when
> a packet is received, but bond_close() sets it to NULL. So,
> a panic occurs when both functions work in parallel.
>
> Why this happen:
> After null pointer check of bond->recv_probe, an sk_buff is
> duplicated and bond->recv_probe is called in bond_handle_frame.
> So, a panic occurs when bond_close() is called between the
> check and call of bond->recv_probe.
>
> Patch:
> This patch uses a local function pointer of bond->recv_probe
> in bond_handle_frame(). So, it can avoid the null pointer
> dereference.
>
>
> Signed-off-by: Mitsuo Hayasaka <mitsuo.hayasaka.hu@hitachi.com>
> Cc: Jay Vosburgh <fubar@us.ibm.com>
> Cc: Andy Gospodarek <andy@greyhouse.net>
> Cc: Eric Dumazet <eric.dumazet@gmail.com>
> Cc: WANG Cong <xiyou.wangcong@gmail.com>
Bonding folks please review this, thanks.
^ permalink raw reply
* Re: [PATCH net-next] net: add skb frag size accessors
From: Eric Dumazet @ 2011-10-19 4:02 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20111018.234906.106954726563794928.davem@davemloft.net>
Le mardi 18 octobre 2011 à 23:49 -0400, David Miller a écrit :
> It seems that enough has changed that this patch no longer applies,
> I'm sorry for taking so long to get to it as that is part of the
> reason this situation was created.
>
> I'd really appreciate it if you'd respin this patch, thanks1
No worry, I'll respin it, thanks David.
^ permalink raw reply
* Re: [PATCH] smsc911x: Add support for SMSC LAN89218
From: David Miller @ 2011-10-19 4:01 UTC (permalink / raw)
To: phil.edworthy; +Cc: netdev, steve.glendinning
In-Reply-To: <1318422579-26243-1-git-send-email-phil.edworthy@renesas.com>
From: Phil Edworthy <phil.edworthy@renesas.com>
Date: Wed, 12 Oct 2011 13:29:39 +0100
> LAN89218 is register compatible with LAN911x.
>
> Signed-off-by: Phil Edworthy <phil.edworthy@renesas.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next] l2tp: give proper headroom in pppol2tp_xmit()
From: Eric Dumazet @ 2011-10-19 4:00 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20111018.233444.955647916101091708.davem@davemloft.net>
Le mardi 18 octobre 2011 à 23:34 -0400, David Miller a écrit :
> From: Eric Dumazet <eric.dumazet@gmail.com>
> > Maybe we should add a counter to help diagnose too many
> > pskb_expand_head() calls...
>
> I think it's the kind of event that deserves a tracepoint, this way one
> could use perf to notice and diagnose such problems.
Target of the patch is an embedded device, MIPS based.
I am not sure perf is available on it.
Thanks
^ permalink raw reply
* Re: [patch net-2.6] tg3: negate USE_PHYLIB flag check
From: David Miller @ 2011-10-19 4:00 UTC (permalink / raw)
To: mcarlson; +Cc: jpirko, netdev, eric.dumazet, mchan
In-Reply-To: <20111012235501.GA31550@mcarlson.broadcom.com>
From: "Matt Carlson" <mcarlson@broadcom.com>
Date: Wed, 12 Oct 2011 16:55:01 -0700
> On Wed, Oct 12, 2011 at 02:00:41AM -0700, Jiri Pirko wrote:
>> USE_PHYLIB flag in tg3_remove_one() is being checked incorrectly. This
>> results tg3_phy_fini->phy_disconnect is never called and when tg3 module
>> is removed.
>>
>> In my case this resulted in panics in phy_state_machine calling function
>> phydev->adjust_link.
>>
>> So correct this check.
>>
>> Signed-off-by: Jiri Pirko <jpirko@redhat.com>
>
> Introduced by commit 63c3a66fe6c827a731dcbdee181158b295626f83, entitled
> "tg3: Convert u32 flag,flg2,flg3 uses to bitmap".
>
> Acked-by: Matt Carlson <mcarlson@broadcom.com>
Applied and queued up for -stable, thanks!
^ permalink raw reply
* Re: [PATCH] flexcan: fix flood of irq's after error condition triggered
From: David Miller @ 2011-10-19 3:58 UTC (permalink / raw)
To: Reuben.Dowle; +Cc: netdev
In-Reply-To: <70F6AAAFDC054F41B9994A9BCD3DF64E16D09892@exch01-aklnz.MARINE.NET.INT>
From: "Reuben Dowle" <Reuben.Dowle@navico.com>
Date: Wed, 12 Oct 2011 16:41:11 +1300
> On my i.MX28 development kit board, I am able to use the flexcan module without problems, until I introduce a bus error by disconnecting the cable. As soon as this is done, the cpu usage goes to 100% percent due to the irq handler being called constantly.
>
> It seems this error can be traced to the irq handler not clearing the irq flags. The flexcan driver is enabling several interrupts, but only clearing one of them.
>
>>From the user manual:
>
> 25.6.8 Error and Status Register (HW_CAN_ESR)
> This register reflects various error conditions, some general status of the device and it is
> the source of four interrupts to the ARM. The reported error conditions are those that
> occurred since the last time the ARM read this register. The ARM read action clears bits.
> Bits are status bits. Most bits in this register are read-only, except TWRN_INT, RWRN_INT,
> BOFF_INT, WAK_INT and ERR_INT, which are interrupt flags that can be cleared by
> writing 1 to them (writing 0 has no effect).
>
> This is ambiguous. It says that reading clears the bits, but then says that some of the bits can be cleared by writing 1 to them. In practice it seems that all the ones listed above as being able to be cleared by writing 1 to them MUST be cleared by writing 1 to them.
>
> Signed-off-by: Reuben Dowle <reuben.dowle@navico.com>
This patch does not apply properly to net-next tree, please respin it
into a properly applying patch.
You also need to properly format the text of your commit message, put
line breaks at 80 columns please.
^ permalink raw reply
* Re: [PATCH] route:ip_rt_frag_needed always return unzero
From: Eric Dumazet @ 2011-10-19 3:57 UTC (permalink / raw)
To: Gao feng; +Cc: davem, kuznet, jmorris, netdev
In-Reply-To: <4E9E36DC.4050304@cn.fujitsu.com>
Le mercredi 19 octobre 2011 à 10:33 +0800, Gao feng a écrit :
> And move atomic_inc(&__rt_peer_genid) just like func ip_rt_update_pmtu?
>
> diff --git a/net/ipv4/route.c b/net/ipv4/route.c
> index 6cde0fa..3e1aa5c 100644
> --- a/net/ipv4/route.c
> +++ b/net/ipv4/route.c
> @@ -1568,11 +1568,12 @@ unsigned short ip_rt_frag_needed(struct net *net, const
> est_mtu = mtu;
> peer->pmtu_learned = mtu;
> peer->pmtu_expires = pmtu_expires;
> +
> + atomic_inc(&__rt_peer_genid);
> }
>
> inet_putpeer(peer);
>
> - atomic_inc(&__rt_peer_genid);
> }
> return est_mtu;
> }
>
This one is fine, please provide a changelog and official submission.
Thanks
^ permalink raw reply
* Re: [PATCH v2] netconsole: enable netconsole can make net_device refcnt incorrent
From: David Miller @ 2011-10-19 3:55 UTC (permalink / raw)
To: fbl; +Cc: gaofeng, netdev, eric.dumazet
In-Reply-To: <20111012102344.0b718260@asterix.rh>
From: Flavio Leitner <fbl@redhat.com>
Date: Wed, 12 Oct 2011 10:23:44 -0300
> On Wed, 12 Oct 2011 10:08:11 +0800
> Gao feng <gaofeng@cn.fujitsu.com> wrote:
>
>> There is no check if netconsole is enabled current.
>> so when exec echo 1 > enabled;
>> the reference of net_device will increment always.
>>
>> Signed-off-by: Gao feng <gaofeng@cn.fujitsu.com>
>> ---
>> drivers/net/netconsole.c | 5 +++++
>> 1 files changed, 5 insertions(+), 0 deletions(-)
>
> Looks better, thanks!
> Acked-by: Flavio Leitner <fbl@redhat.com>
Applied, thanks everyone.
^ permalink raw reply
* Re: [PATCH 2/2] xfrm6: Don't call icmpv6_send on local error
From: David Miller @ 2011-10-19 3:53 UTC (permalink / raw)
To: steffen.klassert; +Cc: herbert, netdev
In-Reply-To: <20111011114430.GJ1830@secunet.com>
From: Steffen Klassert <steffen.klassert@secunet.com>
Date: Tue, 11 Oct 2011 13:44:30 +0200
> Calling icmpv6_send() on a local message size error leads to
> an incorrect update of the path mtu. So use xfrm6_local_rxpmtu()
> to notify about the pmtu if the IPV6_DONTFRAG socket option is
> set on an udp or raw socket, according RFC 3542 and use
> ipv6_local_error() otherwise.
>
> Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
Applied.
^ permalink raw reply
* Re: [PATCH 1/2] ipv6: Fix IPsec slowpath fragmentation problem
From: David Miller @ 2011-10-19 3:53 UTC (permalink / raw)
To: steffen.klassert; +Cc: herbert, netdev
In-Reply-To: <20111011114333.GI1830@secunet.com>
From: Steffen Klassert <steffen.klassert@secunet.com>
Date: Tue, 11 Oct 2011 13:43:33 +0200
> ip6_append_data() builds packets based on the mtu from dst_mtu(rt->dst.path).
> On IPsec the effective mtu is lower because we need to add the protocol
> headers and trailers later when we do the IPsec transformations. So after
> the IPsec transformations the packet might be too big, which leads to a
> slowpath fragmentation then. This patch fixes this by building the packets
> based on the lower IPsec mtu from dst_mtu(&rt->dst) and adapts the exthdr
> handling to this.
>
> Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] xfrm: Simplify the replay check and advance functions
From: David Miller @ 2011-10-19 3:51 UTC (permalink / raw)
To: steffen.klassert; +Cc: herbert, netdev
In-Reply-To: <20111011115837.GK1830@secunet.com>
From: Steffen Klassert <steffen.klassert@secunet.com>
Date: Tue, 11 Oct 2011 13:58:37 +0200
> The replay check and replay advance functions had some code
> duplications. This patch removes the duplications.
>
> Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] ipv6: Remove superfluous NULL pointer check in ipv6_local_rxpmtu
From: David Miller @ 2011-10-19 3:51 UTC (permalink / raw)
To: steffen.klassert; +Cc: netdev
In-Reply-To: <20111011120102.GL1830@secunet.com>
From: Steffen Klassert <steffen.klassert@secunet.com>
Date: Tue, 11 Oct 2011 14:01:02 +0200
> The pointer to mtu_info is taken from the common buffer
> of the skb, thus it can't be a NULL pointer. This patch
> removes this check on mtu_info.
>
> Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
Applied.
^ permalink raw reply
* Re: [net-next] net/phy: extra delay only for RGMII interfaces for IC+ IP 1001
From: David Miller @ 2011-10-19 3:50 UTC (permalink / raw)
To: peppe.cavallaro; +Cc: netdev
In-Reply-To: <1318318676-4493-1-git-send-email-peppe.cavallaro@st.com>
From: Giuseppe CAVALLARO <peppe.cavallaro@st.com>
Date: Tue, 11 Oct 2011 09:37:56 +0200
> The extra delay of 2ns to adjust RX clock phase is actually needed
> in RGMII mode. Tested on the HDK7108 (STx7108c2).
>
> Signed-off-by: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Applied, thank you.
^ permalink raw reply
* Re: [PATCH] route:ip_rt_frag_needed always return unzero
From: Eric Dumazet @ 2011-10-19 3:49 UTC (permalink / raw)
To: Gao feng; +Cc: davem, kuznet, jmorris, netdev
In-Reply-To: <4E9E2929.7070701@cn.fujitsu.com>
Le mercredi 19 octobre 2011 à 09:34 +0800, Gao feng a écrit :
> 2011.10.18 17:23, Eric Dumazet wrote:
> > Le mardi 18 octobre 2011 à 15:04 +0800, Gao feng a écrit :
> >> int function ip_rt_frag_need,if peer is null,
> >> there is no need to do ipprot->err_handler.
> >> I am right?
> >>
> >> Signed-off-by: Gao feng <gaofeng@cn.fujitsu.com>
> >> ---
> >> net/ipv4/route.c | 2 +-
> >> 1 files changed, 1 insertions(+), 1 deletions(-)
> >>
> >> diff --git a/net/ipv4/route.c b/net/ipv4/route.c
> >> index 075212e..6cde0fa 100644
> >> --- a/net/ipv4/route.c
> >> +++ b/net/ipv4/route.c
> >> @@ -1574,7 +1574,7 @@ unsigned short ip_rt_frag_needed(struct net *net, const struct iphdr *iph,
> >>
> >> atomic_inc(&__rt_peer_genid);
> >> }
> >> - return est_mtu ? : new_mtu;
> >> + return est_mtu;
> >> }
> >>
> >> static void check_peer_pmtu(struct dst_entry *dst, struct inet_peer *peer)
> >
> > No idea why you want this, your changelog is a bit cryptic :)
> >
> > Wont this bypass the raw_icmp_error(skb, protocol, info);
> > call in icmp_unreach() as well ?
> >
> >
>
> thanks Eric!
>
> I mean that the pmtu is update by inet_peer->pmtu_learned as I know.
> so in function ip_rt_frag_needed,
> if inet_peer is null or someting else make the setting of inet_peer->pmtu_learned failed.
> there is no need to call function tcp_v4_err.
>
> the call stack is
> icmp_unreach
> |
> |--->ip_rt_frag_needed(fill inet_peer)
> |
> |--->raw_icmp_error()
> |
> |--->ipprot->err_handler(tcp_v4_err or something else)
> |
> |--->tcp_v4_err(frag need icmp is triggered by tcp packet)
> |
> |--->do_pmtu_discovery
> (in this function both __sk_dst_check or dst->ops->update_pmtu
> need struct inet_peer to update pmtu)
>
> so,I think when set inet_peer->pmtu_learned failed,
> in func icmp_unreach we should goto out immediately.
>
> And it's confuse me that why func ping_err and udp_err not update the pmtu?
> What I miss?
You dont answer my question : After your patch, we now dont call
raw_icmp_error() anymore. Why is is valid ?
Not finding/create inet_peer is very unlikely : This occurs only under
high stress and out of memory condition. Is it really happening on your
machines ?
^ permalink raw reply
* Re: [PATCH net-next] net: add skb frag size accessors
From: David Miller @ 2011-10-19 3:49 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1318279267.2567.19.camel@edumazet-laptop>
It seems that enough has changed that this patch no longer applies,
I'm sorry for taking so long to get to it as that is part of the
reason this situation was created.
I'd really appreciate it if you'd respin this patch, thanks1
^ permalink raw reply
* Re: [net-next PATCH] net: allow vlan traffic to be received under bond
From: David Miller @ 2011-10-19 3:47 UTC (permalink / raw)
To: jesse; +Cc: john.r.fastabend, hans.schillstrom, jpirko, mbizon, netdev, fubar
In-Reply-To: <CAEP_g=9dk_ERdnw4Hw_8RO8Z23E1g2Q9G=AxPkiaVhwbHvo47A@mail.gmail.com>
From: Jesse Gross <jesse@nicira.com>
Date: Thu, 13 Oct 2011 17:22:02 -0700
> Actually, for most of 2.6.x the behavior was somewhat
> non-deterministic since it depended on kernel version and the NIC. As
> a result, I think we can safely say that this wasn't a particularly
> firm interface that we have to be wedded to. Based on overwhelming
> feedback, I think the interface in this patch is the preferred one and
> what we should stabilize on.
Agreed, and I've applied this patch to net-next, thanks everyone!
^ permalink raw reply
* Re: [net-next v2] cs89x0: Move the driver into the Cirrus dir
From: David Miller @ 2011-10-19 3:42 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, sassmann, nelson, akpm
In-Reply-To: <1318061264-25310-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Sat, 8 Oct 2011 01:07:44 -0700
> The cs89x0 driver was initial placed in the apple/ when it
> should have been placed in the cirrus/. This resolves the
> issue by moving the dirver and fixing up the respective
> Kconfig(s) and Makefile(s).
>
> Thanks to Sascha for reporting the issue.
>
> -v2 Fix a config error that was introduced with v1 by removing
> the dependency on MACE for NET_VENDOR_APPLE.
>
> CC: Russell Nelson <nelson@crynwr.com>
> CC: Andrew Morton <akpm@linux-foundation.org>
> Reported-by: Sascha Hauer <s.hauer@pengutronix.de>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] bluetooth: Properly clone LSM attributes to newly created child connections
From: David Miller @ 2011-10-19 3:36 UTC (permalink / raw)
To: pmoore; +Cc: netdev, linux-security-module, selinux
In-Reply-To: <20111007194059.12345.13398.stgit@sifl>
From: Paul Moore <pmoore@redhat.com>
Date: Fri, 07 Oct 2011 15:40:59 -0400
> The Bluetooth stack has internal connection handlers for all of the various
> Bluetooth protocols, and unfortunately, they are currently lacking the LSM
> hooks found in the core network stack's connection handlers. I say
> unfortunately, because this can cause problems for users who have have an
> LSM enabled and are using certain Bluetooth devices. See one problem
> report below:
>
> * http://bugzilla.redhat.com/show_bug.cgi?id=741703
>
> In order to keep things simple at this point in time, this patch fixes the
> problem by cloning the parent socket's LSM attributes to the newly created
> child socket. If we decide we need a more elaborate LSM marking mechanism
> for Bluetooth (I somewhat doubt this) we can always revisit this decision
> in the future.
>
> Reported-by: James M. Cape <jcape@ignore-your.tv>
> Signed-off-by: Paul Moore <pmoore@redhat.com>
Applied, thanks!
^ permalink raw reply
* Re: [PATCH net-next] l2tp: give proper headroom in pppol2tp_xmit()
From: David Miller @ 2011-10-19 3:34 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1318002357.3207.28.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Fri, 07 Oct 2011 17:45:57 +0200
> pppol2tp_xmit() calls skb_cow_head(skb, 2) before calling
> l2tp_xmit_skb()
>
> Then l2tp_xmit_skb() calls again skb_cow_head(skb, large_headroom)
>
> This patchs changes the first skb_cow_head() call to supply the needed
> headroom to make sure at most one (expensive) pskb_expand_head() is
> done.
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
> ---
> Maybe we should add a counter to help diagnose too many
> pskb_expand_head() calls...
Applied.
I think it's the kind of event that deserves a tracepoint, this way one
could use perf to notice and diagnose such problems.
^ permalink raw reply
* Re: [PATCH] l2tp: fix a potential skb leak in l2tp_xmit_skb()
From: David Miller @ 2011-10-19 3:32 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1318001746.3207.21.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Fri, 07 Oct 2011 17:35:46 +0200
> l2tp_xmit_skb() can leak one skb if skb_cow_head() returns an error.
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied and queued up for -stable, thanks Eric.
^ permalink raw reply
* Re: [PATCH] pch_gbe: compilation warning in pch_gbe_setup_rctl() fixed
From: David Miller @ 2011-10-19 3:28 UTC (permalink / raw)
To: vvs; +Cc: netdev, toshiharu-linux, vvs
In-Reply-To: <1317974359-20548-1-git-send-email-vvs@parallels.com>
From: Vasily Averin <vvs@parallels.com>
Date: Fri, 7 Oct 2011 11:59:19 +0400
> From: Vasily Averin <vvs@sw.ru>
>
> compilation warning fixed
> drivers/net/pch_gbe/pch_gbe_main.c: In function ‘pch_gbe_setup_rctl’:
> drivers/net/pch_gbe/pch_gbe_main.c:701:21: warning: unused variable ‘netdev’
>
> Signed-off-by: Vasily Averin <vvs@sw.ru>
This patch is not appropriate for the 'net' tree, and in the
'net-next' tree not only is the driver in a completely different
directory but also this warning is already fixed.
^ permalink raw reply
* Re: [PATCH] bridge: fix hang on removal of bridge via netlink
From: David Miller @ 2011-10-19 3:24 UTC (permalink / raw)
To: sri; +Cc: shemminger, netdev
In-Reply-To: <1317942169.6433.17.camel@w-sridhar.beaverton.ibm.com>
From: Sridhar Samudrala <sri@us.ibm.com>
Date: Thu, 06 Oct 2011 16:02:49 -0700
> On Thu, 2011-10-06 at 14:19 -0700, Stephen Hemminger wrote:
>> Need to cleanup bridge device timers and ports when being bridge
>> device is being removed via netlink.
>>
>> This fixes the problem of observed when doing:
>> ip link add br0 type bridge
>> ip link set dev eth1 master br0
>> ip link set br0 up
>> ip link del br0
>>
>> which would cause br0 to hang in unregister_netdev because
>> of leftover reference count.
>>
>> Reported-by: Sridhar Samudrala <sri@us.ibm.com>
>> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
>
> Acked-by: Sridhar Samudrala <sri@us.ibm.com>
Applied to 'net' and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH net-next] macvlan: handle fragmented multicast frames
From: David Miller @ 2011-10-19 3:22 UTC (permalink / raw)
To: eric.dumazet; +Cc: greearb, netdev
In-Reply-To: <1317932911.3457.31.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 06 Oct 2011 22:28:31 +0200
> [PATCH net-next] macvlan: handle fragmented multicast frames
>
> Fragmented multicast frames are delivered to a single macvlan port,
> because ip defrag logic considers other samples are redundant.
>
> Implement a defrag step before trying to send the multicast frame.
>
> Reported-by: Ben Greear <greearb@candelatech.com>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied to net-next, thanks.
^ permalink raw reply
* Re: [PATCH net] vlan:make mtu of vlan equal to physical dev
From: Ben Greear @ 2011-10-19 2:51 UTC (permalink / raw)
To: WeipingPan; +Cc: herbert, open list:NETWORKING [GENERAL]
In-Reply-To: <4E9E30B8.5030904@gmail.com>
On 10/18/2011 07:06 PM, WeipingPan wrote:
> Hi, Herbert,
>
> What do you think of this patch ?
>
> thanks
> Weiping Pan
> On 10/08/2011 06:12 PM, Weiping Pan wrote:
>> Default mtu of vlan device is the same with mtu of physical device,
>> for example 1500, but when change physics mtu to 1600,
>> VLAN device's mtu is still 1500.
>> Certainly, you can change vlan device's mtu to 1600 manually,
>> but I think when you change physics device's mtu, VLAN's mtu should be changed
>> automatically instead of by manually.
I don't like the idea. It's perfectly valid to have the physical dev with 9000 MTU
and have vlans with 1500 MTU.
>> Steps to Reproduce:
>> 1.vconfig add eth4 3
>> 2.ifconfig eth4 mtu 1600
>> 3.check mtu on eth4.3
>>
>> And what's worse is that if you decrease mtu of pyhsical device,
>> and when you want to increase it, the mtu of vlan device won't be changed.
That *might* be worth fixing, but even so, some NICs might handle that
just fine, so my opinion is that this should not change either.
Thanks,
Ben
>>
>> Steps to Reproduce:
>> 1.vconfig add eth4 3
>> 2.ifconfig eth4 mtu 100
>> 3.ifconfig eth4 mtu 1500
>> 4.the mtu of eth4.3 is still 100
>>
>> This bug is reported by Liang Zheng(lzheng@redhat.com).
>>
>> Signed-off-by: Weiping Pan<panweiping3@gmail.com>
>> ---
>> net/8021q/vlan.c | 3 ---
>> 1 files changed, 0 insertions(+), 3 deletions(-)
>>
>> diff --git a/net/8021q/vlan.c b/net/8021q/vlan.c
>> index 8970ba1..f6072b4 100644
>> --- a/net/8021q/vlan.c
>> +++ b/net/8021q/vlan.c
>> @@ -417,9 +417,6 @@ static int vlan_device_event(struct notifier_block *unused, unsigned long event,
>> if (!vlandev)
>> continue;
>>
>> - if (vlandev->mtu<= dev->mtu)
>> - continue;
>> -
>> dev_set_mtu(vlandev, dev->mtu);
>> }
>> break;
>
> --
> 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
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ 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