* 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 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: [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 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 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 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] 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] 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 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 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] 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] 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 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 -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 0/5] Better namespace handling for /sys/class/net/bonding_masters
From: David Miller @ 2011-10-19 4:09 UTC (permalink / raw)
To: ebiederm; +Cc: gregkh, linux-kernel, netdev, htejun, fubar, andy
In-Reply-To: <m1hb3dbae5.fsf@fess.ebiederm.org>
From: ebiederm@xmission.com (Eric W. Biederman)
Date: Thu, 13 Oct 2011 00:47:46 -0700
> Greg, Dave I'm don't know whose tree to merge this through as this code
> is equally device-core and networking. I am hoping that we can get this
> improvement merged for 3.2.
I'm happy to take this series into my net-next tree.
Greg? Any objections?
^ permalink raw reply
* Re: Bug#645589: linux-image-3.0.0-2-amd64: sky2 rx errors on 3.0, 2.6.32 works
From: Ben Hutchings @ 2011-10-19 4:09 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: 645589, Antti Salmela, netdev
In-Reply-To: <20111018111308.2c5a6580@nehalam.linuxnetplumber.net>
[-- Attachment #1: Type: text/plain, Size: 3809 bytes --]
On Tue, 2011-10-18 at 11:13 -0700, Stephen Hemminger wrote:
> On Tue, 18 Oct 2011 04:43:06 +0100
> Ben Hutchings <ben@decadent.org.uk> wrote:
>
> > On Mon, 2011-10-17 at 10:40 +0300, Antti Salmela wrote:
> > > Package: linux-2.6
> > > Version: 3.0.0-5
> > > Severity: normal
> > >
> > >
> > > sky2 loses packets on 3.0 (-3 and -5) and 3.1-rc7, 2.6.32-38 and
> > > setting interface to promiscuous works.
> > >
> > > [ 60.118244] sky2 0000:02:00.0: eth0: rx error, status 0xb92100 length 185
> > > [ 62.664370] sky2 0000:02:00.0: eth0: rx error, status 0x602100 length 96
> > > [ 63.370051] sky2 0000:02:00.0: eth0: rx error, status 0x422100 length 66
> > > [ 63.714672] sky2 0000:02:00.0: eth0: rx error, status 0x722100 length 114
> > > [ 64.513458] device eth0 entered promiscuous mode
> >
> > It looks like this is a bug in accounting of VLAN tags, though I don't
> > see what difference promiscuous mode should make.
> >
> > The log messages show that status has the VLAN flag (bit 13) set and the
> > length field (bits 16:28) equals the length passed into sky2_receive(),
> > but that function expects the length field to be greater by VLAN_HLEN.
> >
> > This device is:
> >
> > [...]
> > > 02:00.0 Ethernet controller [0200]: Marvell Technology Group Ltd. 88E8053 PCI-E Gigabit Ethernet Controller [11ab:4362] (rev 19)
> > > Subsystem: ASUSTeK Computer Inc. Marvell 88E8053 Gigabit Ethernet controller PCIe (Asus) [1043:8142]
> > > Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
> > > Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
> > > Latency: 0, Cache Line Size: 16 bytes
> > > Interrupt: pin A routed to IRQ 43
> > > Region 0: Memory at cdefc000 (64-bit, non-prefetchable) [size=16K]
> > > Region 2: I/O ports at c800 [size=256]
> > > Expansion ROM at cdec0000 [disabled] [size=128K]
> > > Capabilities: <access denied>
> > > Kernel driver in use: sky2
> > [...]
>
> The accounting is supposed to be:
> MAC = total length of packet (including vlan)
> DMA = bytes dma'd to buffer (does not include vlan)
> Looks like the code is incorrect for the case where hardware
> VLAN stripping is disabled.
But if that's true, I'd expect to see these errors in 2.6.32 (where VLAN
tag extraction is disabled until a VLAN group is created) and not in 3.0
(where it is enabled by default). Instead it's 3.0 that is broken.
I also don't see why changing promiscuous mode would make a difference.
> What happens is that status bit
> still has the VLAN flag, but DMA engine leaves the VLAN tag
> in the DMA buffer so the check fails.
>
> Proper accounting would involve more state machine mechanics
> about whether VLAN tag has already been seen in current receive
> status ring.
Shouldn't you should restart the relevant queue when changing VLAN tag
extraction/insertion?
> For now probably best to do something like:
>
> --- net-next.orig/drivers/net/ethernet/marvell/sky2.c 2011-10-18 11:09:04.108683763 -0700
> +++ net-next/drivers/net/ethernet/marvell/sky2.c 2011-10-18 11:09:53.661264323 -0700
> @@ -2543,7 +2543,8 @@ static struct sk_buff *sky2_receive(stru
> struct sk_buff *skb = NULL;
> u16 count = (status & GMR_FS_LEN) >> 16;
>
> - if (status & GMR_FS_VLAN)
> + if ((dev->features & NETIF_F_HW_VLAN_RX) &&
> + (status & GMR_FS_VLAN))
> count -= VLAN_HLEN; /* Account for vlan tag */
It looks like this is needed to restore the workaround for broken status
flags on the FE+. But I doubt it will fix this problem.
Ben.
> netif_printk(sky2, rx_status, KERN_DEBUG, dev,
>
>
>
>
>
--
Ben Hutchings
73.46% of all statistics are made up.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* Re: Comment on nf_queue NF_STOLEN patch
From: Eric Dumazet @ 2011-10-19 4:10 UTC (permalink / raw)
To: Jim Sansing
Cc: Linux Network Development list, Netfilter Development Mailinglist,
Florian Westphal
In-Reply-To: <4E9DF0EB.8080008@verizon.net>
Le mardi 18 octobre 2011 à 17:34 -0400, Jim Sansing a écrit :
> Eric Dumazet wrote:
> > Le mardi 18 octobre 2011 à 15:08 -0400, Jim Sansing a écrit :
> >
> >> I have been working on a kernel module that registers with netfilter,
> >> and I noticed that a patch was added to nf_queue that changed the
> >> handling of return code NF_FILTER from 'do nothing' to 'free the skb'.
> >> I'm not sure which kernel version this went in, but the date of the
> >> patch is Feb, 19, 2010.
> >>
> >> Everything I have read about netfilter states that it is up to the
> >> netfilter hook to free the skb if NF_STOLEN is returned. The
> >> implications of this patch from a hook programming perspective are:
> >>
> >> 1) If the skb is used after the return from the hook, it must be cloned.
> >> 2) The original skb must not be freed.
> >>
> >> I suggest that a comment be added to include/linux/netfilter.h that says
> >> explicitly the skb will be freed if NF_STOLEN is returned.
> >>
> >
> > But its not true. Just read the code.
> >
> > If you are working on this stuff I recommend you take a look at
> > commits :
> >
> > c6675233f9015d3c0460c8aab53ed9b99d915c64
> > (netfilter: nf_queue: reject NF_STOLEN verdicts from userspace)
> >
> > fad54440438a7c231a6ae347738423cbabc936d9
> > (netfilter: avoid double free in nf_reinject)
> >
> > 64507fdbc29c3a622180378210ecea8659b14e40
> > (netfilter: nf_queue: fix NF_STOLEN skb leak)
> >
> > 3bc38712e3a6e0596ccb6f8299043a826f983701
> > ([NETFILTER]: nf_queue: handle NF_STOP and unknown verdicts in
> > nf_reinject)
> >
> >
>
> I see that fad54440438a7c231a6ae347738423cbabc936d9 (netfilter: avoid
> double free in nf_reinject) returns the switch case for NF_STOLEN back
> to the original state, but I just downloaded 3.0.4, and the skb is still
> freed. So for some versions of the kernel, the situation exists.
> Hopefully anyone who runs into it will find this thread.
>
Hopefully netfilter guys (CCed) will sort out the problem and ask stable
submissions, if not already done. 3.0.4 is quite old :)
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" 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-next] l2tp: give proper headroom in pppol2tp_xmit()
From: David Miller @ 2011-10-19 4:12 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1318996826.19139.11.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Wed, 19 Oct 2011 06:00:26 +0200
> 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.
No MIPS specific code is needed to support perf tracepoint
analysis features.
And even if core perf support were required, MIPS's lack of proper
perf support would not the basis upon which we would add features.
^ 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:14 UTC (permalink / raw)
To: eric.dumazet
Cc: mitsuo.hayasaka.hu, fubar, andy, netdev, linux-kernel,
yrl.pp-manager.tt, xiyou.wangcong
In-Reply-To: <1318997127.19139.14.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Wed, 19 Oct 2011 06:05:27 +0200
> 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>
...
> 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>
Thanks for reviewing Eric, applied.
^ permalink raw reply
* Re: [PATCH 0/3] net: time stamping fixes
From: David Miller @ 2011-10-19 4:16 UTC (permalink / raw)
To: richardcochran; +Cc: netdev, eric.dumazet, johannes
In-Reply-To: <cover.1318498805.git.richard.cochran@omicron.at>
From: Richard Cochran <richardcochran@gmail.com>
Date: Thu, 13 Oct 2011 11:46:26 +0200
> The first patch fixes a bug in the time stamping code introduced in
> v2.6.36 of the kernel.
>
> The other two patches depend on the first patch and fix two bugs in a
> PTP Hardware Clock driver. This driver was first introduced in Linux
> version 3.0.
>
> Richard Cochran (3):
> net: hold sock reference while processing tx timestamps
> dp83640: use proper function to free transmit time stamping packets
> dp83640: free packet queues on remove
Johannes and Eric, please help review Richard's fixes here.
Thanks!
^ permalink raw reply
* Re: [PATCH net-next] l2tp: give proper headroom in pppol2tp_xmit()
From: Eric Dumazet @ 2011-10-19 4:24 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20111019.001216.1105373017883639047.davem@davemloft.net>
Le mercredi 19 octobre 2011 à 00:12 -0400, David Miller a écrit :
> From: Eric Dumazet <eric.dumazet@gmail.com>
> Date: Wed, 19 Oct 2011 06:00:26 +0200
> >
> > Target of the patch is an embedded device, MIPS based.
> >
> > I am not sure perf is available on it.
>
> No MIPS specific code is needed to support perf tracepoint
> analysis features.
>
OK then I'll take a look, thanks for the hint !
^ permalink raw reply
* Re: [PATCH 1/3] net: hold sock reference while processing tx timestamps
From: Eric Dumazet @ 2011-10-19 4:42 UTC (permalink / raw)
To: Richard Cochran; +Cc: netdev, David Miller, Johannes Berg, stable
In-Reply-To: <a9a9d4c4fbd872c8a5aa46cf412bdcb07617b00a.1318498805.git.richard.cochran@omicron.at>
Le jeudi 13 octobre 2011 à 11:46 +0200, Richard Cochran a écrit :
> The pair of functions,
>
> * skb_clone_tx_timestamp()
> * skb_complete_tx_timestamp()
>
> were designed to allow timestamping in PHY devices. The first
> function, called during the MAC driver's hard_xmit method, identifies
> PTP protocol packets, clones them, and gives them to the PHY device
> driver. The PHY driver may hold onto the packet and deliver it at a
> later time using the second function, which adds the packet to the
> socket's error queue.
>
> As pointed out by Johannes, nothing prevents the socket from
> disappearing while the cloned packet is sitting in the PHY driver
> awaiting a timestamp. This patch fixes the issue by taking a reference
> on the socket for each such packet. In addition, the comments
> regarding the usage of these function are expanded to highlight the
> rule that PHY drivers must use skb_complete_tx_timestamp() to release
> the packet, in order to release the socket reference, too.
>
> These functions first appeared in v2.6.36.
>
> Reported-by: Johannes Berg <johannes@sipsolutions.net>
> Signed-off-by: Richard Cochran <richard.cochran@omicron.at>
> Cc: <stable@kernel.org>
Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
^ permalink raw reply
* Re: [PATCH 2/3] dp83640: use proper function to free transmit time stamping packets
From: Eric Dumazet @ 2011-10-19 4:47 UTC (permalink / raw)
To: Richard Cochran; +Cc: netdev, David Miller, Johannes Berg, stable
In-Reply-To: <d4208d065cae9f825a750d6520e5f641f76b5e39.1318498805.git.richard.cochran@omicron.at>
Le jeudi 13 octobre 2011 à 11:46 +0200, Richard Cochran a écrit :
> The previous commit enforces a new rule for handling the cloned packets
> for transmit time stamping. These packets must not be freed using any other
> function than skb_complete_tx_timestamp. This commit fixes the one and only
> driver using this API.
>
> The driver first appeared in v3.0.
>
> Signed-off-by: Richard Cochran <richard.cochran@omicron.at>
> Cc: <stable@kernel.org>
Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
^ permalink raw reply
* Re: [PATCH 3/3] dp83640: free packet queues on remove
From: Eric Dumazet @ 2011-10-19 4:48 UTC (permalink / raw)
To: Richard Cochran; +Cc: netdev, David Miller, Johannes Berg, stable
In-Reply-To: <32e73bbe8141d803ebb58488e6cb60870bce4975.1318498805.git.richard.cochran@omicron.at>
Le jeudi 13 octobre 2011 à 11:46 +0200, Richard Cochran a écrit :
> If the PHY should disappear (for example, on an USB Ethernet MAC), then
> the driver would leak any undelivered time stamp packets. This commit
> fixes the issue by calling the appropriate functions to free any packets
> left in the transmit and receive queues.
>
> The driver first appeared in v3.0.
>
> Signed-off-by: Richard Cochran <richard.cochran@omicron.at>
> Cc: <stable@kernel.org>
Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
^ permalink raw reply
* Re: [PATCH 0/3] net: time stamping fixes
From: Johannes Berg @ 2011-10-19 5:15 UTC (permalink / raw)
To: David Miller; +Cc: richardcochran, netdev, eric.dumazet
In-Reply-To: <20111019.001610.312990203017422173.davem@davemloft.net>
On Wed, 2011-10-19 at 00:16 -0400, David Miller wrote:
> From: Richard Cochran <richardcochran@gmail.com>
> Date: Thu, 13 Oct 2011 11:46:26 +0200
>
> > The first patch fixes a bug in the time stamping code introduced in
> > v2.6.36 of the kernel.
> >
> > The other two patches depend on the first patch and fix two bugs in a
> > PTP Hardware Clock driver. This driver was first introduced in Linux
> > version 3.0.
> >
> > Richard Cochran (3):
> > net: hold sock reference while processing tx timestamps
> > dp83640: use proper function to free transmit time stamping packets
> > dp83640: free packet queues on remove
>
> Johannes and Eric, please help review Richard's fixes here.
The only thing I'm not completely sure about is whether or not it is
permissible to sock_hold() at that point. I'm probably just missing
something, but: if sk_free() was called before hard_start_xmit() which
will call skb_clone_tx_timestamp(), can we really call sock_hold()?
The reason I ask is that sock_wfree() doesn't check sk_refcnt, so if it
is possible for sk_free() to have been called before hard_start_xmit(),
maybe because the packet was stuck on the qdisc for a while, the socket
won't be released (sk_free checks sk_wmem_alloc) but the sk_wfree() when
the original skb is freed will actually free the socket, invalidating
the clone's sk pointer *even though* we called sock_hold() right after
making the clone.
So what guarantees that sk_refcnt is still non-zero when we make the
clone? Alternatively, should sock_wfree() check sk_refcnt?
johannes
^ 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