* Re: [PATCH 01/17] netfilter: nf_nat: use hash random for bysource hash
From: Eric Dumazet @ 2011-11-21 7:43 UTC (permalink / raw)
To: kaber; +Cc: netfilter-devel, netdev, ulrich.weber
In-Reply-To: <1321854369-3432-2-git-send-email-kaber@trash.net>
Le lundi 21 novembre 2011 à 06:45 +0100, kaber@trash.net a écrit :
> From: Patrick McHardy <kaber@trash.net>
>
> Use nf_conntrack_hash_rnd in NAT bysource hash to avoid hash chain attacks.
>
> Signed-off-by: Patrick McHardy <kaber@trash.net>
Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
^ permalink raw reply
* Re: Problems with dropped packets on bonded interface for 3.x kernels
From: Albert Chin @ 2011-11-21 7:44 UTC (permalink / raw)
To: netdev
In-Reply-To: <1321857123.17419.2.camel@edumazet-laptop>
On Mon, Nov 21, 2011 at 07:32:03AM +0100, Eric Dumazet wrote:
> Le dimanche 20 novembre 2011 à 23:16 -0600, Albert Chin a écrit :
> > I'm running Ubuntu 11.10 on an Intel SR2625URLXR system with an Intel
> > S5520UR motherboard and an internal Intel E1G44HT (I340-T4) Quad Port
> > Server Adapter. I am seeing dropped packets on a bonded interface,
> > comprised of two GigE ports on the Intel E1G44HT Quad Port Server
> > Adapter. The following kernels exhibit this problem:
> > 3.0.0-12-server, 3.0.0-13-server, 3.1.0-2-server, 3.2.0-rc2
> > Installing Fedora 16 with a 3.1.1-1.fc16.x86_64 also showed dropped
> > packets.
> >
> > I also tried RHEL6 with a 2.6.32-131.17.1.el6.x86_64 kernel and didn't
> > see any dropped packets. Testing an older 2.6.32-28.55-generic Ubuntu
> > kernel also didn't show any dropped packets.
> >
> > So, with 2.6, I don't see dropped packets, but everything including
> > 3.0 and after show dropped packets.
> >
> > # ifconfig bond0
> > bond0 Link encap:Ethernet HWaddr 00:1b:21:d3:f6:0a
> > inet6 addr: fe80::21b:21ff:fed3:f60a/64 Scope:Link
> > UP BROADCAST RUNNING MASTER MULTICAST MTU:1500 Metric:1
> > RX packets:225 errors:0 dropped:186 overruns:0 frame:0
> > TX packets:231 errors:0 dropped:0 overruns:0 carrier:0
> > collisions:0 txqueuelen:0
> > RX bytes:25450 (25.4 KB) TX bytes:28368 (28.3 KB)
> >
> > [[ snip snip ]]
>
> Old kernels were dropping some packets (unknown protocols...) without
> counting them.
>
> So following patch was added in 2.6.37 :
>
> You could use tcdpump to identify what are these dropped packets :)
So only "unknown" protocols are dropped? I just ran tcpdump for 96
packets and inspected the output. The only packets received are LACP,
ARP, STP (Spanning Tree Protocol), DTP (Dynamic Trunking Protocol).
How are these "unknown"?
> commit caf586e5f23cebb2a68cbaf288d59dbbf2d74052
> Author: Eric Dumazet <eric.dumazet@gmail.com>
> Date: Thu Sep 30 21:06:55 2010 +0000
>
> net: add a core netdev->rx_dropped counter
>
> In various situations, a device provides a packet to our stack and we
> drop it before it enters protocol stack :
> - softnet backlog full (accounted in /proc/net/softnet_stat)
> - bad vlan tag (not accounted)
> - unknown/unregistered protocol (not accounted)
>
> We can handle a per-device counter of such dropped frames at core level,
> and automatically adds it to the device provided stats (rx_dropped), so
> that standard tools can be used (ifconfig, ip link, cat /proc/net/dev)
>
> This is a generalization of commit 8990f468a (net: rx_dropped
> accounting), thus reverting it.
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
> Signed-off-by: David S. Miller <davem@davemloft.net>
--
albert chin (china@thewrittenword.com)
^ permalink raw reply
* Re: [PATCH 1/4] ipv4: Fix pmtu propagating
From: Steffen Klassert @ 2011-11-21 7:56 UTC (permalink / raw)
To: David Miller; +Cc: gaofeng, netdev
In-Reply-To: <20111109120851.GA10138@secunet.com>
On Wed, Nov 09, 2011 at 01:08:51PM +0100, Steffen Klassert wrote:
> On Tue, Nov 08, 2011 at 02:33:02PM -0500, David Miller wrote:
> > From: David Miller <davem@davemloft.net>
> > Date: Tue, 08 Nov 2011 14:19:50 -0500 (EST)
> >
> > > I suspect that your real problem has nothing to do with UDP or RAW,
> > > but rather the issue is that entries already in the routing cache
> > > with a NULL peer need to be refreshed with peer information created
> > > in another context.
>
> Yes, that's the problem.
>
> >
> > So you want something like this patch:
> >
>
> Originally, I wanted to fix it with the patch below.
>
> Given the fact that dst->obsolete is not null, this should
> do the same like your patch for output routes. During the
> tests with this patch I noticed a problem with that.
> Unfortunately I can't remember what it was...
>
> I'll do some investigating, perhaps I can get it back to my mind.
>
> I did some quick tests with this and with your patch and both
> seem to fix the problem at the first glance.
>
I still don't see any problems with both of the patches.
So I assume that both patches would fix the issue. However,
your patch is probaply less fragile as this does not depend
on a certain value of dst->obsolete.
^ permalink raw reply
* Re: Problems with dropped packets on bonded interface for 3.x kernels
From: Eric Dumazet @ 2011-11-21 8:02 UTC (permalink / raw)
To: netdev
In-Reply-To: <20111121074453.GA7596@china>
Le lundi 21 novembre 2011 à 01:44 -0600, Albert Chin a écrit :
> So only "unknown" protocols are dropped? I just ran tcpdump for 96
> packets and inspected the output. The only packets received are LACP,
> ARP, STP (Spanning Tree Protocol), DTP (Dynamic Trunking Protocol).
> How are these "unknown"?
No protocol handler is setup to analyze some them in your box.
(ARP is handled of course)
Like if you receive IPv6 packets while IPv6 was not compiled/loaded into
your kernel.
Nothing you have to worry about. We receive plenty of unknown packets
these days...
^ permalink raw reply
* Re: WARNING: at mm/slub.c:3357, kernel BUG at mm/slub.c:3413
From: Markus Trippelsdorf @ 2011-11-21 8:05 UTC (permalink / raw)
To: Alex,Shi
Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org,
Christoph Lameter, Pekka Enberg, Matt Mackall,
netdev@vger.kernel.org, Eric Dumazet
In-Reply-To: <1321836285.30341.554.camel@debian>
On 2011.11.21 at 08:44 +0800, Alex,Shi wrote:
> On Fri, 2011-11-18 at 20:02 +0800, Markus Trippelsdorf wrote:
> > On 2011.11.18 at 09:54 +0100, Markus Trippelsdorf wrote:
> > > On 2011.11.18 at 16:43 +0800, Alex,Shi wrote:
> > > > > >
> > > > > > The dirty flag comes from a bunch of unrelated xfs patches from Christoph, that
> > > > > > I'm testing right now.
> > > >
> > > > Where is the xfs patchset? I am wondering if it is due to slub code.
> >
> > I begin to wonder if this might be the result of a compiler bug.
> > The kernel in question was compiled with gcc version 4.7.0 20111117. And
> > there was commit to the gcc repository today that looks suspicious:
> > http://gcc.gnu.org/viewcvs?view=revision&revision=181466
> >
>
> Tell us if it is still there and you can reproduce it.
Hm, just noticed the "3.2.0-rc1 panic on PowerPC" thread:
http://thread.gmane.org/gmane.linux.kernel/1215584
The backtraces look suspiciously similar to mine.
--
Markus
^ permalink raw reply
* Re: Problems with dropped packets on bonded interface for 3.x kernels
From: Albert Chin @ 2011-11-21 8:08 UTC (permalink / raw)
To: netdev
In-Reply-To: <1321862549.17419.12.camel@edumazet-laptop>
On Mon, Nov 21, 2011 at 09:02:29AM +0100, Eric Dumazet wrote:
> Le lundi 21 novembre 2011 à 01:44 -0600, Albert Chin a écrit :
>
> > So only "unknown" protocols are dropped? I just ran tcpdump for 96
> > packets and inspected the output. The only packets received are LACP,
> > ARP, STP (Spanning Tree Protocol), DTP (Dynamic Trunking Protocol).
> > How are these "unknown"?
>
> No protocol handler is setup to analyze some them in your box.
>
> (ARP is handled of course)
>
> Like if you receive IPv6 packets while IPv6 was not compiled/loaded into
> your kernel.
>
> Nothing you have to worry about. We receive plenty of unknown packets
> these days...
Ok. If the above is the case though, I should see dropped packets on
all of my interfaces. But, I only see it on the bonded interface.
Kinda odd.
Thanks.
--
albert chin (china@thewrittenword.com)
^ permalink raw reply
* Re: WARNING: at mm/slub.c:3357, kernel BUG at mm/slub.c:3413
From: Markus Trippelsdorf @ 2011-11-21 8:24 UTC (permalink / raw)
To: Alex,Shi
Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org,
Christoph Lameter, Pekka Enberg, Matt Mackall,
netdev@vger.kernel.org, Eric Dumazet
In-Reply-To: <20111121080554.GB1625@x4.trippels.de>
On 2011.11.21 at 09:05 +0100, Markus Trippelsdorf wrote:
> On 2011.11.21 at 08:44 +0800, Alex,Shi wrote:
> > On Fri, 2011-11-18 at 20:02 +0800, Markus Trippelsdorf wrote:
> > > On 2011.11.18 at 09:54 +0100, Markus Trippelsdorf wrote:
> > > > On 2011.11.18 at 16:43 +0800, Alex,Shi wrote:
> > > > > > >
> > > > > > > The dirty flag comes from a bunch of unrelated xfs patches from Christoph, that
> > > > > > > I'm testing right now.
> > > > >
> > > > > Where is the xfs patchset? I am wondering if it is due to slub code.
> > >
> > > I begin to wonder if this might be the result of a compiler bug.
> > > The kernel in question was compiled with gcc version 4.7.0 20111117. And
> > > there was commit to the gcc repository today that looks suspicious:
> > > http://gcc.gnu.org/viewcvs?view=revision&revision=181466
> > >
> >
> > Tell us if it is still there and you can reproduce it.
>
> Hm, just noticed the "3.2.0-rc1 panic on PowerPC" thread:
> http://thread.gmane.org/gmane.linux.kernel/1215584
>
> The backtraces look suspiciously similar to mine.
So everything points to commit 87fb4b7b533:
"net: more accurate skb truesize"
Can you take a look Eric?
--
Markus
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: WARNING: at mm/slub.c:3357, kernel BUG at mm/slub.c:3413
From: Eric Dumazet @ 2011-11-21 8:56 UTC (permalink / raw)
To: Markus Trippelsdorf
Cc: Alex,Shi, linux-kernel@vger.kernel.org, linux-mm@kvack.org,
Christoph Lameter, Pekka Enberg, Matt Mackall,
netdev@vger.kernel.org
In-Reply-To: <20111121082445.GD1625@x4.trippels.de>
Le lundi 21 novembre 2011 à 09:24 +0100, Markus Trippelsdorf a écrit :
> So everything points to commit 87fb4b7b533:
> "net: more accurate skb truesize"
>
> Can you take a look Eric?
>
Sure I can, right now.
I'll send an update ASAP
Thanks
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: WARNING: at mm/slub.c:3357, kernel BUG at mm/slub.c:3413
From: Eric Dumazet @ 2011-11-21 9:16 UTC (permalink / raw)
To: Markus Trippelsdorf
Cc: Alex,Shi, linux-kernel@vger.kernel.org, linux-mm@kvack.org,
Christoph Lameter, Pekka Enberg, Matt Mackall,
netdev@vger.kernel.org
In-Reply-To: <20111121082445.GD1625@x4.trippels.de>
Le lundi 21 novembre 2011 à 09:24 +0100, Markus Trippelsdorf a écrit :
> On 2011.11.21 at 09:05 +0100, Markus Trippelsdorf wrote:
> > On 2011.11.21 at 08:44 +0800, Alex,Shi wrote:
> > > On Fri, 2011-11-18 at 20:02 +0800, Markus Trippelsdorf wrote:
> > > > On 2011.11.18 at 09:54 +0100, Markus Trippelsdorf wrote:
> > > > > On 2011.11.18 at 16:43 +0800, Alex,Shi wrote:
> > > > > > > >
> > > > > > > > The dirty flag comes from a bunch of unrelated xfs patches from Christoph, that
> > > > > > > > I'm testing right now.
> > > > > >
> > > > > > Where is the xfs patchset? I am wondering if it is due to slub code.
> > > >
> > > > I begin to wonder if this might be the result of a compiler bug.
> > > > The kernel in question was compiled with gcc version 4.7.0 20111117. And
> > > > there was commit to the gcc repository today that looks suspicious:
> > > > http://gcc.gnu.org/viewcvs?view=revision&revision=181466
> > > >
> > >
> > > Tell us if it is still there and you can reproduce it.
> >
> > Hm, just noticed the "3.2.0-rc1 panic on PowerPC" thread:
> > http://thread.gmane.org/gmane.linux.kernel/1215584
> >
> > The backtraces look suspiciously similar to mine.
>
> So everything points to commit 87fb4b7b533:
> "net: more accurate skb truesize"
>
> Can you take a look Eric?
This commit was followed by a fix (for SLOB, since SLUB/SLAB were not
affected)
Check commit bc417e30f8df (net: Add back alignment for size for
__alloc_skb)
If current kernel still crash, I believe there is a problem elsewhere (a
refcounting problem) that makes underlying page being reused :
The ksize(skb->head) call in pskb_expand_head() assumes skb->head is a
valid zone, not an already freed one...
By the way, we probably can remove (almost dead) code from
pskb_expand_head() since we now place struct skb_shared_info at the end
of skb->head at skb creation.
I'll send this patch later for net-next
diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index 18a3ceb..5fd67a8 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -892,17 +892,6 @@ int pskb_expand_head(struct sk_buff *skb, int nhead, int ntail,
fastpath = atomic_read(&skb_shinfo(skb)->dataref) == delta;
}
- if (fastpath &&
- size + sizeof(struct skb_shared_info) <= ksize(skb->head)) {
- memmove(skb->head + size, skb_shinfo(skb),
- offsetof(struct skb_shared_info,
- frags[skb_shinfo(skb)->nr_frags]));
- memmove(skb->head + nhead, skb->head,
- skb_tail_pointer(skb) - skb->head);
- off = nhead;
- goto adjust_others;
- }
-
data = kmalloc(size + sizeof(struct skb_shared_info), gfp_mask);
if (!data)
goto nodata;
@@ -935,7 +924,6 @@ int pskb_expand_head(struct sk_buff *skb, int nhead, int ntail,
off = (data + nhead) - skb->head;
skb->head = data;
-adjust_others:
skb->data += off;
#ifdef NET_SKBUFF_DATA_USES_OFFSET
skb->end = size;
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply related
* Re: iproute2 back at kernel.org
From: Petr Šabata @ 2011-11-21 9:15 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev
In-Reply-To: <20111011165908.0d6ed7de@nehalam.linuxnetplumber.net>
[-- Attachment #1: Type: text/plain, Size: 455 bytes --]
On Tue, Oct 11, 2011 at 04:59:08PM -0700, Stephen Hemminger wrote:
> Now that kernel.org is back online, the iproute2 repository is back
> at it's old location.
> git://git.kernel.org/pub/scm/linux/kernel/git/shemminger/iproute2
>
> I have frozen and tagged the v3.0 release, but don't have a good place
> to put the tar ball yet (stay tuned). Also the signing key for the release
> will be changing.
Are there any news on this?
-- Petr
[-- Attachment #2: Type: application/pgp-signature, Size: 230 bytes --]
^ permalink raw reply
* Re: [PATCH] net, sja1000: Don't include version.h in peak_pci.c when not needed
From: Marc Kleine-Budde @ 2011-11-21 9:51 UTC (permalink / raw)
To: Jesper Juhl
Cc: linux-can, netdev, linux-kernel, David S. Miller,
Wolfgang Grandegger
In-Reply-To: <alpine.LNX.2.00.1111202204480.17195@swampdragon.chaosbits.net>
[-- Attachment #1: Type: text/plain, Size: 595 bytes --]
On 11/20/2011 10:07 PM, Jesper Juhl wrote:
> It was pointed out by "make versioncheck" that we do not need to include
> version.h in drivers/net/can/sja1000/peak_pci.c
> This patch removes the unneeded include.
>
> Signed-off-by: Jesper Juhl <jj@chaosbits.net>
Acked-by: Marc Kleine-Budde <mkl@pengutronix.de>
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]
^ permalink raw reply
* [GIT PULL] Support for Cadence GEM in the MACB driver
From: Jamie Iles @ 2011-11-21 10:00 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Jean-Christophe PLAGNIOL-VILLARD, Nicolas Ferre, netdev,
linux-arm-kernel, davem
Hi Arnd,
Please consider pulling the patches to add support for Cadence GEM to
the MACB driver. These have been ready to go for a little while but got
held up with the rename of Ethernet drivers in the last merge window.
It would be great if we can get some exposure in -next for a little
while before the next merge window.
Thanks,
Jamie
The following changes since commit cfcfc9eca2bcbd26a8e206baeb005b055dbf8e37:
Linux 3.2-rc2 (2011-11-15 15:02:59 -0200)
are available in the git repository at:
git://github.com/jamieiles/linux-2.6-ji.git macb-gem
Jamie Iles (9):
at91: provide macb clks with "pclk" and "hclk" name
macb: remove conditional clk handling
macb: unify at91 and avr32 platform data
macb: convert printk to netdev_ and friends
macb: initial support for Cadence GEM
macb: support higher rate GEM MDIO clock divisors
macb: support statistics for GEM devices
macb: support DMA bus widths > 32 bits
macb: allow GEM to have configurable receive buffer size
arch/arm/mach-at91/at91cap9.c | 8 +-
arch/arm/mach-at91/at91cap9_devices.c | 6 +-
arch/arm/mach-at91/at91rm9200_devices.c | 6 +-
arch/arm/mach-at91/at91sam9260.c | 8 +-
arch/arm/mach-at91/at91sam9260_devices.c | 6 +-
arch/arm/mach-at91/at91sam9263.c | 8 +-
arch/arm/mach-at91/at91sam9263_devices.c | 6 +-
arch/arm/mach-at91/at91sam9g45.c | 8 +-
arch/arm/mach-at91/at91sam9g45_devices.c | 6 +-
arch/arm/mach-at91/board-1arm.c | 2 +-
arch/arm/mach-at91/board-afeb-9260v1.c | 2 +-
arch/arm/mach-at91/board-cam60.c | 2 +-
arch/arm/mach-at91/board-cap9adk.c | 2 +-
arch/arm/mach-at91/board-carmeva.c | 2 +-
arch/arm/mach-at91/board-cpu9krea.c | 2 +-
arch/arm/mach-at91/board-cpuat91.c | 2 +-
arch/arm/mach-at91/board-csb337.c | 2 +-
arch/arm/mach-at91/board-csb637.c | 2 +-
arch/arm/mach-at91/board-eb9200.c | 2 +-
arch/arm/mach-at91/board-ecbat91.c | 2 +-
arch/arm/mach-at91/board-eco920.c | 2 +-
arch/arm/mach-at91/board-foxg20.c | 2 +-
arch/arm/mach-at91/board-gsia18s.c | 2 +-
arch/arm/mach-at91/board-kafa.c | 2 +-
arch/arm/mach-at91/board-kb9202.c | 2 +-
arch/arm/mach-at91/board-neocore926.c | 2 +-
arch/arm/mach-at91/board-pcontrol-g20.c | 2 +-
arch/arm/mach-at91/board-picotux200.c | 2 +-
arch/arm/mach-at91/board-qil-a9260.c | 2 +-
arch/arm/mach-at91/board-rm9200dk.c | 2 +-
arch/arm/mach-at91/board-rm9200ek.c | 2 +-
arch/arm/mach-at91/board-rsi-ews.c | 2 +-
arch/arm/mach-at91/board-sam9-l9260.c | 2 +-
arch/arm/mach-at91/board-sam9260ek.c | 2 +-
arch/arm/mach-at91/board-sam9263ek.c | 2 +-
arch/arm/mach-at91/board-sam9g20ek.c | 2 +-
arch/arm/mach-at91/board-sam9m10g45ek.c | 2 +-
arch/arm/mach-at91/board-snapper9260.c | 2 +-
arch/arm/mach-at91/board-stamp9g20.c | 2 +-
arch/arm/mach-at91/board-usb-a926x.c | 2 +-
arch/arm/mach-at91/board-yl-9200.c | 2 +-
arch/arm/mach-at91/include/mach/board.h | 14 +-
arch/avr32/boards/atngw100/setup.c | 2 +-
arch/avr32/boards/atstk1000/atstk1002.c | 2 +-
arch/avr32/boards/favr-32/setup.c | 2 +-
arch/avr32/boards/hammerhead/setup.c | 2 +-
arch/avr32/boards/merisc/setup.c | 2 +-
arch/avr32/boards/mimc200/setup.c | 2 +-
arch/avr32/mach-at32ap/at32ap700x.c | 8 +-
arch/avr32/mach-at32ap/include/mach/board.h | 7 +-
drivers/net/ethernet/Makefile | 2 +-
drivers/net/ethernet/cadence/Kconfig | 16 +-
drivers/net/ethernet/cadence/at91_ether.c | 3 +-
drivers/net/ethernet/cadence/at91_ether.h | 4 +-
drivers/net/ethernet/cadence/macb.c | 344 +++++++++++++++++----------
drivers/net/ethernet/cadence/macb.h | 150 ++++++++++++-
include/linux/platform_data/macb.h | 17 ++
57 files changed, 492 insertions(+), 211 deletions(-)
create mode 100644 include/linux/platform_data/macb.h
^ permalink raw reply
* Re: [PATCH 1/1] net/macb: add DT support
From: Nicolas Ferre @ 2011-11-21 10:08 UTC (permalink / raw)
To: Jamie Iles, Jean-Christophe PLAGNIOL-VILLARD; +Cc: devicetree-discuss, netdev
In-Reply-To: <20111120171123.GA7845@gallagher>
On 11/20/2011 06:11 PM, Jamie Iles :
> On Sun, Nov 20, 2011 at 05:47:40PM +0100, Jean-Christophe PLAGNIOL-VILLARD wrote:
>> On 15:58 Fri 18 Nov , Jamie Iles wrote:
>>> Hi Jean-Christophe,
>>>
>>> On Fri, Nov 18, 2011 at 03:29:25PM +0100, Jean-Christophe PLAGNIOL-VILLARD wrote:
>>>> allow the DT to pass the mac address and the phy mode
>>>>
>>>> Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
>>>> Cc: Jamie Iles <jamie@jamieiles.com>
>>>> Cc: Nicolas Ferre <nicolas.ferre@atmel.com>
>>>
>>> This looks OK to me in principle. I can't easily test this at the
>>> moment, but as I don't have a DT platform that has the clk framework up
>>> and running. A couple of nits/questions inline, but thanks for doing
>>> this!
>>>
>>> Jamie
>>>
>>>> ---
>>>> Documentation/devicetree/bindings/net/macb.txt | 22 ++++++++
>>>> drivers/net/ethernet/cadence/macb.c | 65 +++++++++++++++++++++---
>>>> drivers/net/ethernet/cadence/macb.h | 2 +
>>>> 3 files changed, 81 insertions(+), 8 deletions(-)
>>>> create mode 100644 Documentation/devicetree/bindings/net/macb.txt
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/net/macb.txt b/Documentation/devicetree/bindings/net/macb.txt
>>>> new file mode 100644
>>>> index 0000000..2b727ec
>>>> --- /dev/null
>>>> +++ b/Documentation/devicetree/bindings/net/macb.txt
>>>> @@ -0,0 +1,22 @@
>>>> +* Cadence EMACB
>>>> +
>>>> +Implemeted on Atmel AT91 & AVR32 SoC
>>>
>>> I think something along the lines of "Binding for the Cadence MACB
>>> Ethernet controller" rather than listing specific parts might be
>>> clearer.
>> I prefer as we will have implementation detail in the binding
>
> I can't see any Atmel specific implementation detail here though so lets
> keep it generic for now. There isn't a benefit to keeping a list of
> SoC's that the device is implemented in here as it'll only become out of
> date. We need to make it easy for other vendors to reuse the binding +
> driver.
Yes, now that Jamie has made the driver generic, we should not advertise
for specific SoC...
>>>> + compatible = "atmel,macb";
>>>
>>> This should be "cdns,macb" as it isn't Atmel specific. I believe cdns
>>> is the correct stock ticker symbol for Cadence.
>> here I put "atmel,macb" on purpose to specify the difference of the IP between
>> the soc, in fact it should have been atmel-at91,macb
No, before comma means "manufacturer".
> Well if we really can't detect the difference from the revision register
> then we should have "cdns,macb" *and* "atmel,at91-macb" at least then
> where platforms could claim compatibility as:
>
> compatible = "atmel,at91-macb", "cdns,macb";
>
> If we consider that another vendor integrates the Cadence IP, then it
> makes much more sense to claim compatibility with a Cadence string
> rather than an Atmel one...
Yes, it seems that you manage to use the revision register to identify
the IP. So here again, maybe the generic compatible string is enough...
>>>
>>>> + reg = <oxfffc4000 0x4000>;
>>>> + interrupts = <21>;
>>>> + phy-mode = "mii";
>>>> + };
>>>> diff --git a/drivers/net/ethernet/cadence/macb.c b/drivers/net/ethernet/cadence/macb.c
>>>> index a437b46..2c345bc 100644
>>>> --- a/drivers/net/ethernet/cadence/macb.c
>>>> +++ b/drivers/net/ethernet/cadence/macb.c
>>>> @@ -20,6 +20,9 @@
>>>> #include <linux/etherdevice.h>
>>>> #include <linux/dma-mapping.h>
>>>> #include <linux/platform_device.h>
>>>> +#include <linux/of.h>
>>>> +#include <linux/of_device.h>
>>>> +#include <linux/of_net.h>
>>>> #include <linux/phy.h>
>>>>
>>>> #include <mach/board.h>
>>>> @@ -81,6 +84,20 @@ static void __init macb_get_hwaddr(struct macb *bp)
>>>> addr[4] = top & 0xff;
>>>> addr[5] = (top >> 8) & 0xff;
>>>>
>>>> +#ifdef CONFIG_OF
>>>> + /*
>>>> + * 2) from device tree data
>>>> + */
>>>> + if (!is_valid_ether_addr(addr)) {
>>>> + struct device_node *np = bp->pdev->dev.of_node;
>>>> + if (np) {
>>>> + const char *mac = of_get_mac_address(np);
>>>> + if (mac)
>>>> + memcpy(addr, mac, sizeof(addr));
>>>> + }
>>>> + }
>>>> +#endif
>>>
>>> I'm a bit conflicted here. I think we should always use the MAC address
>>> from the device tree if it is present even if the current MAC address is
>>> valid.
>> if the mac is already programmed in the register we just keep it
>> I prefer this way if the bootloader set it we keep it
>
> But I don't think that makes sense - if there is a MAC address in the
> DT, which is an optional property then the DT author must want to set
> the MAC address from the DT. We should really prefer an explicit
> assignment over an implicit one.
Yes, that seems sensible.
Best regards,
--
Nicolas Ferre
^ permalink raw reply
* Re: [BUG] 3.2-rc2: BUG kmalloc-8: Redzone overwritten
From: Eric Dumazet @ 2011-11-21 10:15 UTC (permalink / raw)
To: Sasha Levin, David Miller
Cc: Matt Mackall, Christoph Lameter, Pekka Enberg, linux-mm,
linux-kernel, netdev
In-Reply-To: <1321866845.3831.7.camel@lappy>
Le lundi 21 novembre 2011 à 11:14 +0200, Sasha Levin a écrit :
> Hi All,
>
> I got the following output when running some tests (I'm not really sure
> what exactly happened when this bug was triggered):
>
> [13850.947279] =============================================================================
> [13850.948024] BUG kmalloc-8: Redzone overwritten
> [13850.948024] -----------------------------------------------------------------------------
> [13850.948024]
> [13850.948024] INFO: 0xffff8800104f6d28-0xffff8800104f6d2b. First byte 0x0 instead of 0xcc
> [13850.948024] INFO: Allocated in __seq_open_private+0x20/0x5e age=4436 cpu=0 pid=17295
> [13850.948024] __slab_alloc.clone.46+0x3e7/0x456
> [13850.948024] __kmalloc+0x8c/0x110
> [13850.948024] __seq_open_private+0x20/0x5e
> [13850.948024] seq_open_net+0x3b/0x5d
> [13850.948024] dev_mc_seq_open+0x15/0x17
> [13850.948024] proc_reg_open+0xad/0x127
> [13850.948024] __dentry_open+0x1a0/0x2fe
> [13850.948024] nameidata_to_filp+0x63/0x6a
> [13850.948024] do_last+0x59e/0x5cb
> [13850.948024] path_openat+0xcd/0x35d
> [13850.948024] do_filp_open+0x38/0x84
> [13850.948024] do_sys_open+0x6f/0x101
> [13850.948024] sys_open+0x1b/0x1d
> [13850.948024] system_call_fastpath+0x16/0x1b
> [13850.948024] INFO: Freed in seq_release_private+0x26/0x45 age=30272 cpu=0 pid=17283
> [13850.948024] __slab_free+0x35/0x1dc
> [13850.948024] kfree+0xb6/0xbf
> [13850.948024] seq_release_private+0x26/0x45
> [13850.948024] seq_release_net+0x32/0x3b
> [13850.948024] proc_reg_release+0xd9/0xf6
> [13850.948024] fput+0x11e/0x1dc
> [13850.948024] filp_close+0x6e/0x79
> [13850.948024] put_files_struct+0xcc/0x196
> [13850.948024] exit_files+0x46/0x4f
> [13850.948024] do_exit+0x264/0x75c
> [13850.948024] do_group_exit+0x83/0xb1
> [13850.948024] sys_exit_group+0x12/0x16
> [13850.948024] system_call_fastpath+0x16/0x1b
> [13850.948024] INFO: Slab 0xffffea0000413d80 objects=12 used=8 fp=0xffff8800104f6000 flags=0x10000000000081
> [13850.948024] INFO: Object 0xffff8800104f6d20 @offset=3360 fp=0xffff8800104f6e70
> [13850.948024]
> [13850.948024] Bytes b4 ffff8800104f6d10: 39 64 00 00 01 00 00 00 5a 5a 5a 5a 5a 5a 5a 5a 9d......ZZZZZZZZ
> [13850.948024] Object ffff8800104f6d20: 00 a9 38 83 ff ff ff ff ..8.....
> [13850.948024] Redzone ffff8800104f6d28: 00 00 00 00 cc cc cc cc ........
> [13850.948024] Padding ffff8800104f6e68: 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZ
> [13850.948024] Pid: 17295, comm: trinity Tainted: G W 3.2.0-rc2-sasha-00146-gc729049-dirty #15
> [13850.948024] Call Trace:
> [13850.948024] [<ffffffff8112c8f6>] ? print_section+0x38/0x3a
> [13850.948024] [<ffffffff8112ca21>] print_trailer+0x129/0x132
> [13850.948024] [<ffffffff8112cd02>] check_bytes_and_report+0xb2/0xeb
> [13850.948024] [<ffffffff8115bacc>] ? __seq_open_private+0x31/0x5e
> [13850.948024] [<ffffffff8112d811>] check_object+0x4e/0x1ae
> [13850.948024] [<ffffffff8115ba7c>] ? seq_release_private+0x26/0x45
> [13850.948024] [<ffffffff8112e723>] free_debug_processing+0x96/0x1dc
> [13850.948024] [<ffffffff8115ba7c>] ? seq_release_private+0x26/0x45
> [13850.948024] [<ffffffff8112ec07>] __slab_free+0x35/0x1dc
> [13850.948024] [<ffffffff8115ba7c>] ? seq_release_private+0x26/0x45
> [13850.948024] [<ffffffff8115ba7c>] ? seq_release_private+0x26/0x45
> [13850.948024] [<ffffffff81626be3>] ? debug_check_no_obj_freed+0x12/0x17
> [13850.948024] [<ffffffff8115ba7c>] ? seq_release_private+0x26/0x45
> [13850.948024] [<ffffffff8113041f>] kfree+0xb6/0xbf
> [13850.948024] [<ffffffff81196f4b>] ? single_open_net+0x54/0x54
> [13850.948024] [<ffffffff8115ba7c>] seq_release_private+0x26/0x45
> [13850.948024] [<ffffffff81196f7d>] seq_release_net+0x32/0x3b
> [13850.948024] [<ffffffff8118dc6c>] proc_reg_release+0xd9/0xf6
> [13850.948024] [<ffffffff811418cf>] fput+0x11e/0x1dc
> [13850.948024] [<ffffffff8113f3d8>] filp_close+0x6e/0x79
> [13850.948024] [<ffffffff81089f17>] put_files_struct+0xcc/0x196
> [13850.948024] [<ffffffff8108a074>] exit_files+0x46/0x4f
> [13850.948024] [<ffffffff8108a756>] do_exit+0x264/0x75c
> [13850.948024] [<ffffffff8113f67c>] ? fsnotify_modify+0x60/0x68
> [13850.948024] [<ffffffff81b96f8a>] ? sysret_check+0x2e/0x69
> [13850.948024] [<ffffffff8108ad01>] do_group_exit+0x83/0xb1
> [13850.948024] [<ffffffff8108ad41>] sys_exit_group+0x12/0x16
> [13850.948024] [<ffffffff81b96f52>] system_call_fastpath+0x16/0x1b
> [13850.948024] FIX kmalloc-8: Restoring 0xffff8800104f6d28-0xffff8800104f6d2b=0xcc
> [13850.948024]
> [14925.113722] =============================================================================
> [14925.114041] BUG kmalloc-8: Redzone overwritten
> [14925.114041] -----------------------------------------------------------------------------
> [14925.114041]
> [14925.114041] INFO: 0xffff8800104f2d28-0xffff8800104f2d2b. First byte 0x0 instead of 0xcc
> [14925.114041] INFO: Allocated in __seq_open_private+0x20/0x5e age=6777 cpu=0 pid=17491
> [14925.114041] __slab_alloc.clone.46+0x3e7/0x456
> [14925.114041] __kmalloc+0x8c/0x110
> [14925.114041] __seq_open_private+0x20/0x5e
> [14925.114041] seq_open_net+0x3b/0x5d
> [14925.114041] dev_mc_seq_open+0x15/0x17
> [14925.114041] proc_reg_open+0xad/0x127
> [14925.114041] __dentry_open+0x1a0/0x2fe
> [14925.114041] nameidata_to_filp+0x63/0x6a
> [14925.114041] do_last+0x59e/0x5cb
> [14925.114041] path_openat+0xcd/0x35d
> [14925.114041] do_filp_open+0x38/0x84
> [14925.114041] do_sys_open+0x6f/0x101
> [14925.114041] sys_open+0x1b/0x1d
> [14925.114041] system_call_fastpath+0x16/0x1b
> [14925.114041] INFO: Freed in seq_release_private+0x26/0x45 age=30836 cpu=0 pid=17487
> [14925.114041] __slab_free+0x35/0x1dc
> [14925.114041] kfree+0xb6/0xbf
> [14925.114041] seq_release_private+0x26/0x45
> [14925.114041] seq_release_net+0x32/0x3b
> [14925.114041] proc_reg_release+0xd9/0xf6
> [14925.114041] fput+0x11e/0x1dc
> [14925.114041] filp_close+0x6e/0x79
> [14925.114041] put_files_struct+0xcc/0x196
> [14925.114041] exit_files+0x46/0x4f
> [14925.114041] do_exit+0x264/0x75c
> [14925.114041] do_group_exit+0x83/0xb1
> [14925.114041] sys_exit_group+0x12/0x16
> [14925.114041] system_call_fastpath+0x16/0x1b
> [14925.114041] INFO: Slab 0xffffea0000413c80 objects=12 used=11 fp=0xffff8800104f27e0 flags=0x10000000000081
> [14925.114041] INFO: Object 0xffff8800104f2d20 @offset=3360 fp=0xffff8800104f2bd0
> [14925.114041]
> [14925.114041] Bytes b4 ffff8800104f2d10: 0a b1 de 00 01 00 00 00 5a 5a 5a 5a 5a 5a 5a 5a ........ZZZZZZZZ
> [14925.114041] Object ffff8800104f2d20: 00 a9 38 83 ff ff ff ff ..8.....
> [14925.114041] Redzone ffff8800104f2d28: 00 00 00 00 cc cc cc cc ........
> [14925.114041] Padding ffff8800104f2e68: 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZ
> [14925.114041] Pid: 17491, comm: trinity Tainted: G W 3.2.0-rc2-sasha-00146-gc729049-dirty #15
> [14925.114041] Call Trace:
> [14925.114041] [<ffffffff8112c8f6>] ? print_section+0x38/0x3a
> [14925.114041] [<ffffffff8112ca21>] print_trailer+0x129/0x132
> [14925.114041] [<ffffffff8112cd02>] check_bytes_and_report+0xb2/0xeb
> [14925.114041] [<ffffffff8115bacc>] ? __seq_open_private+0x31/0x5e
> [14925.114041] [<ffffffff8112d811>] check_object+0x4e/0x1ae
> [14925.114041] [<ffffffff8115ba7c>] ? seq_release_private+0x26/0x45
> [14925.114041] [<ffffffff8112e723>] free_debug_processing+0x96/0x1dc
> [14925.114041] [<ffffffff8115ba7c>] ? seq_release_private+0x26/0x45
> [14925.114041] [<ffffffff8112ec07>] __slab_free+0x35/0x1dc
> [14925.114041] [<ffffffff8115ba7c>] ? seq_release_private+0x26/0x45
> [14925.114041] [<ffffffff8115ba7c>] ? seq_release_private+0x26/0x45
> [14925.114041] [<ffffffff81626be3>] ? debug_check_no_obj_freed+0x12/0x17
> [14925.114041] [<ffffffff8115ba7c>] ? seq_release_private+0x26/0x45
> [14925.114041] [<ffffffff8113041f>] kfree+0xb6/0xbf
> [14925.114041] [<ffffffff81196f4b>] ? single_open_net+0x54/0x54
> [14925.114041] [<ffffffff8115ba7c>] seq_release_private+0x26/0x45
> [14925.114041] [<ffffffff81196f7d>] seq_release_net+0x32/0x3b
> [14925.114041] [<ffffffff8118dc6c>] proc_reg_release+0xd9/0xf6
> [14925.114041] [<ffffffff811418cf>] fput+0x11e/0x1dc
> [14925.114041] [<ffffffff8113f3d8>] filp_close+0x6e/0x79
> [14925.114041] [<ffffffff81089f17>] put_files_struct+0xcc/0x196
> [14925.114041] [<ffffffff8108a074>] exit_files+0x46/0x4f
> [14925.114041] [<ffffffff8108a756>] do_exit+0x264/0x75c
> [14925.114041] [<ffffffff8104ca1b>] ? smp_apic_timer_interrupt+0x76/0x84
> [14925.114041] [<ffffffff81b966b8>] ? retint_restore_args+0x13/0x13
> [14925.114041] [<ffffffff8108ad01>] do_group_exit+0x83/0xb1
> [14925.114041] [<ffffffff8108ad41>] sys_exit_group+0x12/0x16
> [14925.114041] [<ffffffff81b96f52>] system_call_fastpath+0x16/0x1b
> [14925.114041] FIX kmalloc-8: Restoring 0xffff8800104f2d28-0xffff8800104f2d2b=0xcc
> [14925.114041]
> [15958.081391] general protection fault: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC
> [15958.082012] CPU 1
> [15958.082012] Pid: 15, comm: rcuc/1 Tainted: G W 3.2.0-rc2-sasha-00146-gc729049-dirty #15
> [15958.082012] RIP: 0010:[<ffffffff810b305b>] [<ffffffff810b305b>] __lock_acquire+0xff/0xe50
> [15958.082012] RSP: 0000:ffff880013c03cc8 EFLAGS: 00010002
> [15958.082012] RAX: 6b6b6b6b6b6b6b6b RBX: ffff8800124daf60 RCX: 0000000000000000
> [15958.082012] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff880010b82568
> [15958.082012] RBP: ffff880013c03d98 R08: 0000000000000002 R09: 0000000000000000
> [15958.082012] R10: ffff880010b82568 R11: 0000000000000001 R12: ffff880010b82568
> [15958.082012] R13: 0000000000000002 R14: 0000000000000000 R15: ffff880013c03f18
> [15958.082012] FS: 0000000000000000(0000) GS:ffff880013c00000(0000) knlGS:0000000000000000
> [15958.082012] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> [15958.082012] CR2: 00007f9193a05c2c CR3: 0000000010735000 CR4: 00000000000406e0
> [15958.082012] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> [15958.082012] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> [15958.082012] Process rcuc/1 (pid: 15, threadinfo ffff8800124e6000, task ffff8800124daf60)
> [15958.082012] Stack:
> [15958.082012] ffff880013dceb10 ffff8800124daf60 ffffffff00000000 0000000000000000
> [15958.082012] ffff880010b82568 0000000000000082 ffff880000000000 ffffffff810b1d97
> [15958.082012] ffff8800124daf60 ffff880013c03ee8 ffff880013c03df8 ffffffff816141ae
> [15958.082012] Call Trace:
> [15958.082012] <IRQ>
> [15958.082012] [<ffffffff810b1d97>] ? trace_hardirqs_on_caller+0x151/0x197
> [15958.082012] [<ffffffff816141ae>] ? trace_hardirqs_on_thunk+0x3a/0x3f
> [15958.082012] [<ffffffff810b4255>] lock_acquire+0x8a/0xa7
> [15958.082012] [<ffffffff81aa6314>] ? dn_slow_timer+0x20/0x108
> [15958.082012] [<ffffffff810afac3>] ? arch_local_irq_restore+0x12/0x19
> [15958.082012] [<ffffffff81b958b7>] _raw_spin_lock+0x3b/0x6e
> [15958.082012] [<ffffffff81aa6314>] ? dn_slow_timer+0x20/0x108
> [15958.082012] [<ffffffff81aa6314>] dn_slow_timer+0x20/0x108
> [15958.082012] [<ffffffff810915f1>] run_timer_softirq+0x1da/0x28c
> [15958.082012] [<ffffffff81091599>] ? run_timer_softirq+0x182/0x28c
> [15958.082012] [<ffffffff81aa62f4>] ? dn_neigh_elist+0x3a/0x3a
> [15958.082012] [<ffffffff8108c2e4>] __do_softirq+0xa4/0x14b
> [15958.082012] [<ffffffff81b9923c>] call_softirq+0x1c/0x30
> [15958.082012] <EOI>
> [15958.082012] [<ffffffff8103525a>] do_softirq+0x62/0xb8
> [15958.082012] [<ffffffff810e1711>] ? rcu_cpu_kthread+0x284/0x2b8
> [15958.082012] [<ffffffff8108c1cb>] _local_bh_enable_ip+0xaf/0xe6
> [15958.082012] [<ffffffff8108c233>] local_bh_enable+0xd/0xf
> [15958.082012] [<ffffffff810e1711>] rcu_cpu_kthread+0x284/0x2b8
> [15958.082012] [<ffffffff810e148d>] ? rcu_do_batch.clone.24+0x1fe/0x1fe
> [15958.082012] [<ffffffff8109ee97>] kthread+0x9b/0xa3
> [15958.082012] [<ffffffff810b1d97>] ? trace_hardirqs_on_caller+0x151/0x197
> [15958.082012] [<ffffffff81b99144>] kernel_thread_helper+0x4/0x10
> [15958.082012] [<ffffffff81b966b8>] ? retint_restore_args+0x13/0x13
> [15958.082012] [<ffffffff8109edfc>] ? kthread_flush_work_fn+0xf/0xf
> [15958.082012] [<ffffffff81b99140>] ? gs_change+0x13/0x13
> [15958.082012] Code: 8d 40 ff ff ff 4c 89 95 50 ff ff ff 45 31 f6 e8 23 fc ff ff 44 8b 8d 40 ff ff ff 48 85 c0 4c 8b 95 50 ff ff ff 0f 84 e4 0c 00 00 <f0> ff 80 98 01 00 00 44 8b bb d0 08 00 00 83 3d 64 27 74 01 00
> [15958.082012] RIP [<ffffffff810b305b>] __lock_acquire+0xff/0xe50
> [15958.082012] RSP <ffff880013c03cc8>
> [15958.082012] ---[ end trace 21ee6c8ed26977a8 ]---
> [15958.082012] Kernel panic - not syncing: Fatal exception in interrupt
> [15958.082012] Pid: 15, comm: rcuc/1 Tainted: G D W 3.2.0-rc2-sasha-00146-gc729049-dirty #15
> [15958.082012] Call Trace:
> [15958.082012] <IRQ> [<ffffffff81b930f3>] panic+0x96/0x1c3
> [15958.082012] [<ffffffff81036626>] oops_end+0xcf/0xdf
> [15958.082012] [<ffffffff8103677c>] die+0x55/0x61
> [15958.082012] [<ffffffff8103417b>] do_general_protection+0x12e/0x136
> [15958.082012] [<ffffffff81b966e8>] ? restore_args+0x30/0x30
> [15958.082012] [<ffffffff81b96935>] general_protection+0x25/0x30
> [15958.082012] [<ffffffff810b305b>] ? __lock_acquire+0xff/0xe50
> [15958.082012] [<ffffffff810b2fcb>] ? __lock_acquire+0x6f/0xe50
> [15958.082012] [<ffffffff810b1d97>] ? trace_hardirqs_on_caller+0x151/0x197
> [15958.082012] [<ffffffff816141ae>] ? trace_hardirqs_on_thunk+0x3a/0x3f
> [15958.082012] [<ffffffff810b4255>] lock_acquire+0x8a/0xa7
> [15958.082012] [<ffffffff81aa6314>] ? dn_slow_timer+0x20/0x108
> [15958.082012] [<ffffffff810afac3>] ? arch_local_irq_restore+0x12/0x19
> [15958.082012] [<ffffffff81b958b7>] _raw_spin_lock+0x3b/0x6e
> [15958.082012] [<ffffffff81aa6314>] ? dn_slow_timer+0x20/0x108
> [15958.082012] [<ffffffff81aa6314>] dn_slow_timer+0x20/0x108
> [15958.082012] [<ffffffff810915f1>] run_timer_softirq+0x1da/0x28c
> [15958.082012] [<ffffffff81091599>] ? run_timer_softirq+0x182/0x28c
> [15958.082012] [<ffffffff81aa62f4>] ? dn_neigh_elist+0x3a/0x3a
> [15958.082012] [<ffffffff8108c2e4>] __do_softirq+0xa4/0x14b
> [15958.082012] [<ffffffff81b9923c>] call_softirq+0x1c/0x30
> [15958.082012] <EOI> [<ffffffff8103525a>] do_softirq+0x62/0xb8
> [15958.082012] [<ffffffff810e1711>] ? rcu_cpu_kthread+0x284/0x2b8
> [15958.082012] [<ffffffff8108c1cb>] _local_bh_enable_ip+0xaf/0xe6
> [15958.082012] [<ffffffff8108c233>] local_bh_enable+0xd/0xf
> [15958.082012] [<ffffffff810e1711>] rcu_cpu_kthread+0x284/0x2b8
> [15958.082012] [<ffffffff810e148d>] ? rcu_do_batch.clone.24+0x1fe/0x1fe
> [15958.082012] [<ffffffff8109ee97>] kthread+0x9b/0xa3
> [15958.082012] [<ffffffff810b1d97>] ? trace_hardirqs_on_caller+0x151/0x197
> [15958.082012] [<ffffffff81b99144>] kernel_thread_helper+0x4/0x10
> [15958.082012] [<ffffffff81b966b8>] ? retint_restore_args+0x13/0x13
> [15958.082012] [<ffffffff8109edfc>] ? kthread_flush_work_fn+0xf/0xf
> [15958.082012] [<ffffffff81b99140>] ? gs_change+0x13/0x13
> [15958.082012] Rebooting in 1 seconds..
> # KVM session ended normally.
>
> Please let me know if theres anything I can do to help debugging it.
>
Hmm, trinity tries to crash decnet ;)
Maybe we should remove this decnet stuff for good instead of tracking
all bugs just for the record. Is there anybody still using decnet ?
For example dn_start_slow_timer() starts a timer without holding a
reference on struct sock, this is highly suspect.
[PATCH] decnet: proper socket refcounting
Better use sk_reset_timer() / sk_stop_timer() helpers to make sure we
dont access already freed/reused memory later.
Reported-by: Sasha Levin <levinsasha928@gmail.com>
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
net/decnet/dn_timer.c | 16 +++++-----------
1 file changed, 5 insertions(+), 11 deletions(-)
diff --git a/net/decnet/dn_timer.c b/net/decnet/dn_timer.c
index 67f691b..9f95f0d 100644
--- a/net/decnet/dn_timer.c
+++ b/net/decnet/dn_timer.c
@@ -36,16 +36,13 @@ static void dn_slow_timer(unsigned long arg);
void dn_start_slow_timer(struct sock *sk)
{
- sk->sk_timer.expires = jiffies + SLOW_INTERVAL;
- sk->sk_timer.function = dn_slow_timer;
- sk->sk_timer.data = (unsigned long)sk;
-
- add_timer(&sk->sk_timer);
+ setup_timer(&sk->sk_timer, dn_slow_timer, (unsigned long)sk);
+ sk_reset_timer(sk, &sk->sk_timer, jiffies + SLOW_INTERVAL);
}
void dn_stop_slow_timer(struct sock *sk)
{
- del_timer(&sk->sk_timer);
+ sk_stop_timer(sk, &sk->sk_timer);
}
static void dn_slow_timer(unsigned long arg)
@@ -57,8 +54,7 @@ static void dn_slow_timer(unsigned long arg)
bh_lock_sock(sk);
if (sock_owned_by_user(sk)) {
- sk->sk_timer.expires = jiffies + HZ / 10;
- add_timer(&sk->sk_timer);
+ sk_reset_timer(sk, &sk->sk_timer, jiffies + HZ / 10);
goto out;
}
@@ -100,9 +96,7 @@ static void dn_slow_timer(unsigned long arg)
scp->keepalive_fxn(sk);
}
- sk->sk_timer.expires = jiffies + SLOW_INTERVAL;
-
- add_timer(&sk->sk_timer);
+ sk_reset_timer(sk, &sk->sk_timer, jiffies + SLOW_INTERVAL);
out:
bh_unlock_sock(sk);
sock_put(sk);
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply related
* Re: [BUG] 3.2-rc2: BUG kmalloc-8: Redzone overwritten
From: Eric Dumazet @ 2011-11-21 10:21 UTC (permalink / raw)
To: Sasha Levin
Cc: David Miller, Matt Mackall, Christoph Lameter, Pekka Enberg,
linux-mm, linux-kernel, netdev
In-Reply-To: <1321870529.2552.19.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
Le lundi 21 novembre 2011 à 11:15 +0100, Eric Dumazet a écrit :
>
> Hmm, trinity tries to crash decnet ;)
>
> Maybe we should remove this decnet stuff for good instead of tracking
> all bugs just for the record. Is there anybody still using decnet ?
>
> For example dn_start_slow_timer() starts a timer without holding a
> reference on struct sock, this is highly suspect.
>
> [PATCH] decnet: proper socket refcounting
>
> Better use sk_reset_timer() / sk_stop_timer() helpers to make sure we
> dont access already freed/reused memory later.
>
> Reported-by: Sasha Levin <levinsasha928@gmail.com>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Hmm, I forgot to remove the sock_hold(sk) call from dn_slow_timer(),
here is V2 :
[PATCH] decnet: proper socket refcounting
Better use sk_reset_timer() / sk_stop_timer() helpers to make sure we
dont access already freed/reused memory later.
Reported-by: Sasha Levin <levinsasha928@gmail.com>
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
V2: remove sock_hold(sk) call from dn_slow_timer()
net/decnet/dn_timer.c | 17 +++++------------
1 file changed, 5 insertions(+), 12 deletions(-)
diff --git a/net/decnet/dn_timer.c b/net/decnet/dn_timer.c
index 67f691b..d9c150c 100644
--- a/net/decnet/dn_timer.c
+++ b/net/decnet/dn_timer.c
@@ -36,16 +36,13 @@ static void dn_slow_timer(unsigned long arg);
void dn_start_slow_timer(struct sock *sk)
{
- sk->sk_timer.expires = jiffies + SLOW_INTERVAL;
- sk->sk_timer.function = dn_slow_timer;
- sk->sk_timer.data = (unsigned long)sk;
-
- add_timer(&sk->sk_timer);
+ setup_timer(&sk->sk_timer, dn_slow_timer, (unsigned long)sk);
+ sk_reset_timer(sk, &sk->sk_timer, jiffies + SLOW_INTERVAL);
}
void dn_stop_slow_timer(struct sock *sk)
{
- del_timer(&sk->sk_timer);
+ sk_stop_timer(sk, &sk->sk_timer);
}
static void dn_slow_timer(unsigned long arg)
@@ -53,12 +50,10 @@ static void dn_slow_timer(unsigned long arg)
struct sock *sk = (struct sock *)arg;
struct dn_scp *scp = DN_SK(sk);
- sock_hold(sk);
bh_lock_sock(sk);
if (sock_owned_by_user(sk)) {
- sk->sk_timer.expires = jiffies + HZ / 10;
- add_timer(&sk->sk_timer);
+ sk_reset_timer(sk, &sk->sk_timer, jiffies + HZ / 10);
goto out;
}
@@ -100,9 +95,7 @@ static void dn_slow_timer(unsigned long arg)
scp->keepalive_fxn(sk);
}
- sk->sk_timer.expires = jiffies + SLOW_INTERVAL;
-
- add_timer(&sk->sk_timer);
+ sk_reset_timer(sk, &sk->sk_timer, jiffies + SLOW_INTERVAL);
out:
bh_unlock_sock(sk);
sock_put(sk);
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply related
* Re: [BUG] 3.2-rc2: BUG kmalloc-8: Redzone overwritten
From: Sasha Levin @ 2011-11-21 10:22 UTC (permalink / raw)
To: Eric Dumazet
Cc: David Miller, Matt Mackall, Christoph Lameter, Pekka Enberg,
linux-mm, linux-kernel, netdev
In-Reply-To: <1321870915.2552.22.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
On Mon, 2011-11-21 at 11:21 +0100, Eric Dumazet wrote:
> Le lundi 21 novembre 2011 à 11:15 +0100, Eric Dumazet a écrit :
>
> >
> > Hmm, trinity tries to crash decnet ;)
> >
> > Maybe we should remove this decnet stuff for good instead of tracking
> > all bugs just for the record. Is there anybody still using decnet ?
> >
> > For example dn_start_slow_timer() starts a timer without holding a
> > reference on struct sock, this is highly suspect.
> >
> > [PATCH] decnet: proper socket refcounting
> >
> > Better use sk_reset_timer() / sk_stop_timer() helpers to make sure we
> > dont access already freed/reused memory later.
> >
> > Reported-by: Sasha Levin <levinsasha928@gmail.com>
> > Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
>
> Hmm, I forgot to remove the sock_hold(sk) call from dn_slow_timer(),
> here is V2 :
>
> [PATCH] decnet: proper socket refcounting
>
> Better use sk_reset_timer() / sk_stop_timer() helpers to make sure we
> dont access already freed/reused memory later.
>
> Reported-by: Sasha Levin <levinsasha928@gmail.com>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
> ---
[snip]
Applied locally and running same tests as before, will update with
results.
--
Sasha.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH 10/17] netfilter: ipv6: expand skb head in ip6_route_me_harder after oif change
From: Eric Dumazet @ 2011-11-21 10:29 UTC (permalink / raw)
To: kaber; +Cc: netfilter-devel, netdev, ulrich.weber
In-Reply-To: <1321854369-3432-11-git-send-email-kaber@trash.net>
Le lundi 21 novembre 2011 à 06:46 +0100, kaber@trash.net a écrit :
> From: Patrick McHardy <kaber@trash.net>
>
> Expand the skb headroom if the oif changed due to rerouting similar to
> how IPv4 packets are handled.
>
> Signed-off-by: Patrick McHardy <kaber@trash.net>
> ---
> net/ipv6/netfilter.c | 7 +++++++
> 1 files changed, 7 insertions(+), 0 deletions(-)
>
> diff --git a/net/ipv6/netfilter.c b/net/ipv6/netfilter.c
> index 30fcee4..d39e954 100644
> --- a/net/ipv6/netfilter.c
> +++ b/net/ipv6/netfilter.c
> @@ -14,6 +14,7 @@ int ip6_route_me_harder(struct sk_buff *skb)
> {
> struct net *net = dev_net(skb_dst(skb)->dev);
> const struct ipv6hdr *iph = ipv6_hdr(skb);
> + unsigned int hh_len;
> struct dst_entry *dst;
> struct flowi6 fl6 = {
> .flowi6_oif = skb->sk ? skb->sk->sk_bound_dev_if : 0,
> @@ -46,6 +47,12 @@ int ip6_route_me_harder(struct sk_buff *skb)
> }
> #endif
>
> + /* Change in oif may mean change in hh_len. */
> + hh_len = skb_dst(skb)->dev->hard_header_len;
> + if (skb_headroom(skb) < hh_len &&
> + pskb_expand_head(skb, hh_len - skb_headroom(skb), 0, GFP_ATOMIC))
> + return -1;
> +
Hmm, We had a problem recently on Tile arches because of unaligned
accesses.
Had you seen the bug report and proposed patch ?
Fix is to instead do :
pskb_expand_head(skb,
HH_DATA_ALIGN(hh_len - skb_headroom(skb)),
0,
GFP_ATOMIC);
--
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 v2 1/3] dt/net: add helper function of_get_phy_mode
From: Nicolas Ferre @ 2011-11-21 10:57 UTC (permalink / raw)
To: Shawn Guo, Grant Likely, devicetree-discuss, devicetree-discuss
Cc: 'linux-arm-kernel@lists.infradead.org', netdev,
Rob Herring
Hi all,
> It adds the helper function of_get_phy_mode getting phy interface
> from device tree.
>
> Signed-off-by: Shawn Guo <shawn.guo <at> linaro.org>
> Cc: Grant Likely <grant.likely <at> secretlab.ca>
> ---
> drivers/of/of_net.c | 43 +++++++++++++++++++++++++++++++++++++++++++
> include/linux/of_net.h | 1 +
[..]
> +const int of_get_phy_mode(struct device_node *np)
Nice helper function, indeed.
> +{
> + const char *pm;
> + int err, i;
> +
> + err = of_property_read_string(np, "phy-mode", &pm);
Just a quick question about the use of the "phy-mode" string:
- I know that it is widely used in drivers
- but, I discovered that in the ePAPR the string mentioned is "phy-connection-type" (6.5.2.2)
- and it is true also that in the very same document, we find the "phy-mode" in the Appendix B1 example...
Why this naming is not consistent (even in ePAPR)?
Best regards,
--
Nicolas Ferre
^ permalink raw reply
* Re: [BUG] 3.2-rc2: BUG kmalloc-8: Redzone overwritten
From: Steven Whitehouse @ 2011-11-21 10:58 UTC (permalink / raw)
To: Eric Dumazet
Cc: Sasha Levin, David Miller, Matt Mackall, Christoph Lameter,
Pekka Enberg, linux-mm, linux-kernel, netdev, Chrissie Caulfield
In-Reply-To: <1321870915.2552.22.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
Hi,
On Mon, 2011-11-21 at 11:21 +0100, Eric Dumazet wrote:
> Le lundi 21 novembre 2011 à 11:15 +0100, Eric Dumazet a écrit :
>
> >
> > Hmm, trinity tries to crash decnet ;)
> >
> > Maybe we should remove this decnet stuff for good instead of tracking
> > all bugs just for the record. Is there anybody still using decnet ?
> >
The best place to ask that question is on the decnet mailing list:
linux-decnet-user@lists.sourceforge.net. I've BCC'd this message since
that list requires you to be subscribed in order to post there.
I have to say that I've been wondering lately whether it has got to the
point where it is no longer useful. Has anybody actually tested it
lately against "real" DEC implementations?
Steve.
>
> > For example dn_start_slow_timer() starts a timer without holding a
> > reference on struct sock, this is highly suspect.
> >
> > [PATCH] decnet: proper socket refcounting
> >
> > Better use sk_reset_timer() / sk_stop_timer() helpers to make sure we
> > dont access already freed/reused memory later.
> >
> > Reported-by: Sasha Levin <levinsasha928@gmail.com>
> > Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
>
> Hmm, I forgot to remove the sock_hold(sk) call from dn_slow_timer(),
> here is V2 :
>
> [PATCH] decnet: proper socket refcounting
>
> Better use sk_reset_timer() / sk_stop_timer() helpers to make sure we
> dont access already freed/reused memory later.
>
> Reported-by: Sasha Levin <levinsasha928@gmail.com>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
> ---
> V2: remove sock_hold(sk) call from dn_slow_timer()
>
> net/decnet/dn_timer.c | 17 +++++------------
> 1 file changed, 5 insertions(+), 12 deletions(-)
>
> diff --git a/net/decnet/dn_timer.c b/net/decnet/dn_timer.c
> index 67f691b..d9c150c 100644
> --- a/net/decnet/dn_timer.c
> +++ b/net/decnet/dn_timer.c
> @@ -36,16 +36,13 @@ static void dn_slow_timer(unsigned long arg);
>
> void dn_start_slow_timer(struct sock *sk)
> {
> - sk->sk_timer.expires = jiffies + SLOW_INTERVAL;
> - sk->sk_timer.function = dn_slow_timer;
> - sk->sk_timer.data = (unsigned long)sk;
> -
> - add_timer(&sk->sk_timer);
> + setup_timer(&sk->sk_timer, dn_slow_timer, (unsigned long)sk);
> + sk_reset_timer(sk, &sk->sk_timer, jiffies + SLOW_INTERVAL);
> }
>
> void dn_stop_slow_timer(struct sock *sk)
> {
> - del_timer(&sk->sk_timer);
> + sk_stop_timer(sk, &sk->sk_timer);
> }
>
> static void dn_slow_timer(unsigned long arg)
> @@ -53,12 +50,10 @@ static void dn_slow_timer(unsigned long arg)
> struct sock *sk = (struct sock *)arg;
> struct dn_scp *scp = DN_SK(sk);
>
> - sock_hold(sk);
> bh_lock_sock(sk);
>
> if (sock_owned_by_user(sk)) {
> - sk->sk_timer.expires = jiffies + HZ / 10;
> - add_timer(&sk->sk_timer);
> + sk_reset_timer(sk, &sk->sk_timer, jiffies + HZ / 10);
> goto out;
> }
>
> @@ -100,9 +95,7 @@ static void dn_slow_timer(unsigned long arg)
> scp->keepalive_fxn(sk);
> }
>
> - sk->sk_timer.expires = jiffies + SLOW_INTERVAL;
> -
> - add_timer(&sk->sk_timer);
> + sk_reset_timer(sk, &sk->sk_timer, jiffies + SLOW_INTERVAL);
> out:
> bh_unlock_sock(sk);
> sock_put(sk);
>
>
> --
> 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
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH 1/1] net/macb: add DT support
From: Nicolas Ferre @ 2011-11-21 11:08 UTC (permalink / raw)
To: Jean-Christophe PLAGNIOL-VILLARD; +Cc: devicetree-discuss, netdev, Jamie Iles
In-Reply-To: <1321626565-11261-1-git-send-email-plagnioj@jcrosoft.com>
On 11/18/2011 03:29 PM, Jean-Christophe PLAGNIOL-VILLARD :
> allow the DT to pass the mac address and the phy mode
>
> Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
> Cc: Jamie Iles <jamie@jamieiles.com>
> Cc: Nicolas Ferre <nicolas.ferre@atmel.com>
> ---
> Documentation/devicetree/bindings/net/macb.txt | 22 ++++++++
> drivers/net/ethernet/cadence/macb.c | 65 +++++++++++++++++++++---
> drivers/net/ethernet/cadence/macb.h | 2 +
> 3 files changed, 81 insertions(+), 8 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/net/macb.txt
>
> diff --git a/Documentation/devicetree/bindings/net/macb.txt b/Documentation/devicetree/bindings/net/macb.txt
> new file mode 100644
> index 0000000..2b727ec
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/macb.txt
> @@ -0,0 +1,22 @@
> +* Cadence EMACB
> +
> +Implemeted on Atmel AT91 & AVR32 SoC
Ditto with Jamie's comments.
> +
> +Required properties:
> +- compatible : Should be "atmel,macb" for Atmel
> +- reg : Address and length of the register set for the device
> +- interrupts : Should contain macb interrupt
> +- phy-mode : String, operation mode of the PHY interface.
> + Supported values are: "mii", "rmii",
> +
> +Optional properties:
> +- local-mac-address : 6 bytes, mac address
> +
> +Examples:
> +
> + macb0: macb@fffc4000 {
> + compatible = "atmel,macb";
Ditto.
> + reg = <oxfffc4000 0x4000>;
> + interrupts = <21>;
> + phy-mode = "mii";
> + };
> diff --git a/drivers/net/ethernet/cadence/macb.c b/drivers/net/ethernet/cadence/macb.c
> index a437b46..2c345bc 100644
> --- a/drivers/net/ethernet/cadence/macb.c
> +++ b/drivers/net/ethernet/cadence/macb.c
> @@ -20,6 +20,9 @@
> #include <linux/etherdevice.h>
> #include <linux/dma-mapping.h>
> #include <linux/platform_device.h>
> +#include <linux/of.h>
> +#include <linux/of_device.h>
> +#include <linux/of_net.h>
> #include <linux/phy.h>
>
> #include <mach/board.h>
> @@ -81,6 +84,20 @@ static void __init macb_get_hwaddr(struct macb *bp)
> addr[4] = top & 0xff;
> addr[5] = (top >> 8) & 0xff;
>
> +#ifdef CONFIG_OF
> + /*
> + * 2) from device tree data
> + */
> + if (!is_valid_ether_addr(addr)) {
> + struct device_node *np = bp->pdev->dev.of_node;
> + if (np) {
> + const char *mac = of_get_mac_address(np);
> + if (mac)
Maybe here also, check is_valid_ether_addr(mac): it seems safer.
> + memcpy(addr, mac, sizeof(addr));
> + }
> + }
> +#endif
> +
> if (is_valid_ether_addr(addr)) {
> memcpy(bp->dev->dev_addr, addr, sizeof(addr));
> } else {
> @@ -191,7 +208,6 @@ static int macb_mii_probe(struct net_device *dev)
> {
> struct macb *bp = netdev_priv(dev);
> struct phy_device *phydev;
> - struct eth_platform_data *pdata;
> int ret;
>
> phydev = phy_find_first(bp->mii_bus);
> @@ -200,14 +216,11 @@ static int macb_mii_probe(struct net_device *dev)
> return -1;
> }
>
> - pdata = bp->pdev->dev.platform_data;
> /* TODO : add pin_irq */
>
> /* attach the mac to the phy */
> ret = phy_connect_direct(dev, phydev, &macb_handle_link_change, 0,
> - pdata && pdata->is_rmii ?
> - PHY_INTERFACE_MODE_RMII :
> - PHY_INTERFACE_MODE_MII);
> + bp->phy_interface);
> if (ret) {
> printk(KERN_ERR "%s: Could not attach to PHY\n", dev->name);
> return ret;
> @@ -1117,6 +1130,30 @@ static const struct net_device_ops macb_netdev_ops = {
> #endif
> };
>
> +#if defined(CONFIG_OF)
> +static const struct of_device_id macb_dt_ids[] = {
> + { .compatible = "atmel,macb" },
> + { /* sentinel */ }
> +};
> +
> +MODULE_DEVICE_TABLE(of, macb_dt_ids);
> +
> +static int __devinit macb_get_phy_mode_dt(struct platform_device *pdev)
> +{
> + struct device_node *np = pdev->dev.of_node;
> +
> + if (np)
> + return of_get_phy_mode(np);
> +
> + return -ENODEV;
> +}
> +#else
> +static int __devinit macb_get_phy_mode_dt(struct platform_device *pdev)
> +{
> + return -ENODEV;
> +}
> +#endif
> +
> static int __init macb_probe(struct platform_device *pdev)
> {
> struct eth_platform_data *pdata;
> @@ -1210,20 +1247,31 @@ static int __init macb_probe(struct platform_device *pdev)
> macb_writel(bp, NCFGR, config);
>
> macb_get_hwaddr(bp);
> - pdata = pdev->dev.platform_data;
>
> - if (pdata && pdata->is_rmii)
> + err = macb_get_phy_mode_dt(pdev);
> + if (err < 0) {
> + pdata = pdev->dev.platform_data;
> + if (pdata && pdata->is_rmii)
> + bp->phy_interface = PHY_INTERFACE_MODE_RMII;
> + else
> + bp->phy_interface = PHY_INTERFACE_MODE_MII;
> + } else {
> + bp->phy_interface = err;
> + }
> +
> + if (bp->phy_interface == PHY_INTERFACE_MODE_RMII) {
> #if defined(CONFIG_ARCH_AT91)
> macb_writel(bp, USRIO, (MACB_BIT(RMII) | MACB_BIT(CLKEN)) );
> #else
> macb_writel(bp, USRIO, 0);
> #endif
> - else
> + } else {
> #if defined(CONFIG_ARCH_AT91)
> macb_writel(bp, USRIO, MACB_BIT(CLKEN));
> #else
> macb_writel(bp, USRIO, MACB_BIT(MII));
> #endif
> + }
>
> bp->tx_pending = DEF_TX_RING_PENDING;
>
> @@ -1344,6 +1392,7 @@ static struct platform_driver macb_driver = {
> .driver = {
> .name = "macb",
> .owner = THIS_MODULE,
> + .of_match_table = of_match_ptr(macb_dt_ids),
> },
> };
>
> diff --git a/drivers/net/ethernet/cadence/macb.h b/drivers/net/ethernet/cadence/macb.h
> index d3212f6..8342744 100644
> --- a/drivers/net/ethernet/cadence/macb.h
> +++ b/drivers/net/ethernet/cadence/macb.h
> @@ -389,6 +389,8 @@ struct macb {
> unsigned int link;
> unsigned int speed;
> unsigned int duplex;
> +
> + phy_interface_t phy_interface;
> };
>
> #endif /* _MACB_H */
--
Nicolas Ferre
^ permalink raw reply
* [PATCH 0/8] net/mlx4 features and fixes
From: Yevgeny Petrilin @ 2011-11-21 8:43 UTC (permalink / raw)
To: davem; +Cc: netdev, yevgenyp, ogerlitz, oren, amirv
Hello David,
This is a series of patches for mlx4_en driver.
synchronized the different commits into a single series.
Thanks,
Yevgeny
Or Gerlitz (3):
net/mlx4: move RSS related definitions to be global
net/mlx4: fix UDP RSS related settings
net/mlx4_en: fix sparse warning on a cast which truncates bits from constant value
Yevgeny Petrilin (1):
net/mlx4_en: using non collapsed CQ on TX
Oren Duer (1):
net/mlx4_en: fix WOL handlers were always looking at port2, capability bit
Amir Vadai (3):
net/mlx4_en: allow setting number of rx rings for, RSS/TCP
net/mlx4_en: adding loopback support
net/mlx4_en: bug fix for the case of vlan id 0 and UP 0
drivers/net/ethernet/mellanox/mlx4/en_cq.c | 7 --
drivers/net/ethernet/mellanox/mlx4/en_ethtool.c | 20 +++++
drivers/net/ethernet/mellanox/mlx4/en_main.c | 7 +-
drivers/net/ethernet/mellanox/mlx4/en_netdev.c | 1
drivers/net/ethernet/mellanox/mlx4/en_resources.c | 2
drivers/net/ethernet/mellanox/mlx4/en_rx.c | 25 +++++--
drivers/net/ethernet/mellanox/mlx4/en_tx.c | 74 +++++++++++-----------
drivers/net/ethernet/mellanox/mlx4/mlx4_en.h | 12 ---
include/linux/mlx4/device.h | 3
include/linux/mlx4/qp.h | 28 ++++++++
10 files changed, 115 insertions(+), 64 deletions(-)
^ permalink raw reply
* [PATCH 1/8] net/mlx4: move RSS related definitions to be global
From: Yevgeny Petrilin @ 2011-11-21 8:43 UTC (permalink / raw)
To: davem; +Cc: netdev, yevgenyp, ogerlitz, oren, amirv
From: Or Gerlitz <ogerlitz@mellanox.com>
Towards adding RSS support for IB drivers/application who use
the mlx4 HW, make the RSS related definitions global and change
the mlx4_en driver to use them.
Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
Signed-off-by: Shlomo Pongratz <shlomop@mellanox.com>
---
drivers/net/ethernet/mellanox/mlx4/en_resources.c | 2 +-
drivers/net/ethernet/mellanox/mlx4/en_rx.c | 10 ++++---
drivers/net/ethernet/mellanox/mlx4/mlx4_en.h | 10 -------
include/linux/mlx4/qp.h | 27 +++++++++++++++++++++
4 files changed, 34 insertions(+), 15 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx4/en_resources.c b/drivers/net/ethernet/mellanox/mlx4/en_resources.c
index 0dfb4ec..bcbc54c 100644
--- a/drivers/net/ethernet/mellanox/mlx4/en_resources.c
+++ b/drivers/net/ethernet/mellanox/mlx4/en_resources.c
@@ -44,7 +44,7 @@ void mlx4_en_fill_qp_context(struct mlx4_en_priv *priv, int size, int stride,
struct mlx4_en_dev *mdev = priv->mdev;
memset(context, 0, sizeof *context);
- context->flags = cpu_to_be32(7 << 16 | rss << 13);
+ context->flags = cpu_to_be32(7 << 16 | rss << MLX4_RSS_QPC_FLAG_OFFSET);
context->pd = cpu_to_be32(mdev->priv_pdn);
context->mtu_msgmax = 0xff;
if (!is_tx && !rss)
diff --git a/drivers/net/ethernet/mellanox/mlx4/en_rx.c b/drivers/net/ethernet/mellanox/mlx4/en_rx.c
index b89c36d..86cb300 100644
--- a/drivers/net/ethernet/mellanox/mlx4/en_rx.c
+++ b/drivers/net/ethernet/mellanox/mlx4/en_rx.c
@@ -833,9 +833,10 @@ int mlx4_en_config_rss_steer(struct mlx4_en_priv *priv)
struct mlx4_en_dev *mdev = priv->mdev;
struct mlx4_en_rss_map *rss_map = &priv->rss_map;
struct mlx4_qp_context context;
- struct mlx4_en_rss_context *rss_context;
+ struct mlx4_rss_context *rss_context;
void *ptr;
- u8 rss_mask = 0x3f;
+ u8 rss_mask = (MLX4_RSS_IPV4 | MLX4_RSS_TCP_IPV4 | MLX4_RSS_IPV6 |
+ MLX4_RSS_TCP_IPV6 | MLX4_RSS_UDP_IPV4 | MLX4_RSS_UDP_IPV6);
int i, qpn;
int err = 0;
int good_qps = 0;
@@ -873,13 +874,14 @@ int mlx4_en_config_rss_steer(struct mlx4_en_priv *priv)
mlx4_en_fill_qp_context(priv, 0, 0, 0, 1, priv->base_qpn,
priv->rx_ring[0].cqn, &context);
- ptr = ((void *) &context) + 0x3c;
+ ptr = ((void *) &context) + offsetof(struct mlx4_qp_context, pri_path)
+ + MLX4_RSS_OFFSET_IN_QPC_PRI_PATH;
rss_context = ptr;
rss_context->base_qpn = cpu_to_be32(ilog2(priv->rx_ring_num) << 24 |
(rss_map->base_qpn));
rss_context->default_qpn = cpu_to_be32(rss_map->base_qpn);
rss_context->flags = rss_mask;
- rss_context->hash_fn = 1;
+ rss_context->hash_fn = MLX4_RSS_HASH_TOP;
for (i = 0; i < 10; i++)
rss_context->rss_key[i] = rsskey[i];
diff --git a/drivers/net/ethernet/mellanox/mlx4/mlx4_en.h b/drivers/net/ethernet/mellanox/mlx4/mlx4_en.h
index 8fda331c..6e2657d 100644
--- a/drivers/net/ethernet/mellanox/mlx4/mlx4_en.h
+++ b/drivers/net/ethernet/mellanox/mlx4/mlx4_en.h
@@ -365,16 +365,6 @@ struct mlx4_en_rss_map {
enum mlx4_qp_state indir_state;
};
-struct mlx4_en_rss_context {
- __be32 base_qpn;
- __be32 default_qpn;
- u16 reserved;
- u8 hash_fn;
- u8 flags;
- __be32 rss_key[10];
- __be32 base_qpn_udp;
-};
-
struct mlx4_en_port_state {
int link_state;
int link_speed;
diff --git a/include/linux/mlx4/qp.h b/include/linux/mlx4/qp.h
index 48cc4cb..6562ff6 100644
--- a/include/linux/mlx4/qp.h
+++ b/include/linux/mlx4/qp.h
@@ -97,6 +97,33 @@ enum {
MLX4_QP_BIT_RIC = 1 << 4,
};
+enum {
+ MLX4_RSS_HASH_XOR = 0,
+ MLX4_RSS_HASH_TOP = 1,
+
+ MLX4_RSS_UDP_IPV6 = 1 << 0,
+ MLX4_RSS_UDP_IPV4 = 1 << 1,
+ MLX4_RSS_TCP_IPV6 = 1 << 2,
+ MLX4_RSS_IPV6 = 1 << 3,
+ MLX4_RSS_TCP_IPV4 = 1 << 4,
+ MLX4_RSS_IPV4 = 1 << 5,
+
+ /* offset of mlx4_rss_context within mlx4_qp_context.pri_path */
+ MLX4_RSS_OFFSET_IN_QPC_PRI_PATH = 0x24,
+ /* offset of being RSS indirection QP within mlx4_qp_context.flags */
+ MLX4_RSS_QPC_FLAG_OFFSET = 13,
+};
+
+struct mlx4_rss_context {
+ __be32 base_qpn;
+ __be32 default_qpn;
+ u16 reserved;
+ u8 hash_fn;
+ u8 flags;
+ __be32 rss_key[10];
+ __be32 base_qpn_udp;
+};
+
struct mlx4_qp_path {
u8 fl;
u8 reserved1[2];
--
1.7.7
^ permalink raw reply related
* [PATCH 2/8] net/mlx4: fix UDP RSS related settings
From: Yevgeny Petrilin @ 2011-11-21 8:43 UTC (permalink / raw)
To: davem; +Cc: netdev, yevgenyp, ogerlitz, oren, amirv
From: Or Gerlitz <ogerlitz@mellanox.com>
Using RSS which takes into account UDP headers is controlled by
a module param, fix the setting of the HW RSS context to align
with that scheme. So far it was uncoditionally allowing hashing
on the UDP headers.
Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
---
drivers/net/ethernet/mellanox/mlx4/en_rx.c | 8 +++++---
1 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx4/en_rx.c b/drivers/net/ethernet/mellanox/mlx4/en_rx.c
index 86cb300..3c24e16 100644
--- a/drivers/net/ethernet/mellanox/mlx4/en_rx.c
+++ b/drivers/net/ethernet/mellanox/mlx4/en_rx.c
@@ -836,7 +836,7 @@ int mlx4_en_config_rss_steer(struct mlx4_en_priv *priv)
struct mlx4_rss_context *rss_context;
void *ptr;
u8 rss_mask = (MLX4_RSS_IPV4 | MLX4_RSS_TCP_IPV4 | MLX4_RSS_IPV6 |
- MLX4_RSS_TCP_IPV6 | MLX4_RSS_UDP_IPV4 | MLX4_RSS_UDP_IPV6);
+ MLX4_RSS_TCP_IPV6);
int i, qpn;
int err = 0;
int good_qps = 0;
@@ -879,14 +879,16 @@ int mlx4_en_config_rss_steer(struct mlx4_en_priv *priv)
rss_context = ptr;
rss_context->base_qpn = cpu_to_be32(ilog2(priv->rx_ring_num) << 24 |
(rss_map->base_qpn));
+ if (priv->mdev->profile.udp_rss) {
+ rss_mask |= MLX4_RSS_UDP_IPV4 | MLX4_RSS_UDP_IPV6;
+ rss_context->base_qpn_udp = rss_context->default_qpn;
+ }
rss_context->default_qpn = cpu_to_be32(rss_map->base_qpn);
rss_context->flags = rss_mask;
rss_context->hash_fn = MLX4_RSS_HASH_TOP;
for (i = 0; i < 10; i++)
rss_context->rss_key[i] = rsskey[i];
- if (priv->mdev->profile.udp_rss)
- rss_context->base_qpn_udp = rss_context->default_qpn;
err = mlx4_qp_to_ready(mdev->dev, &priv->res.mtt, &context,
&rss_map->indir_qp, &rss_map->indir_state);
if (err)
--
1.7.7
^ permalink raw reply related
* [PATCH 3/8] net/mlx4_en: fix sparse warning on a cast which, truncates bits from constant value
From: Yevgeny Petrilin @ 2011-11-21 8:43 UTC (permalink / raw)
To: davem; +Cc: netdev, yevgenyp, ogerlitz, oren, amirv
From: Or Gerlitz <ogerlitz@mellanox.com>
the MLX4_EN_WOL_DO_MODIFY flag which is defined through enum targets
bit 63, this triggers a "cast truncate bits from constant value
(8000000000000000 becomes 0)" warning from sparse, fix that by using
define instead of enum.
Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
---
drivers/net/ethernet/mellanox/mlx4/mlx4_en.h | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx4/mlx4_en.h b/drivers/net/ethernet/mellanox/mlx4/mlx4_en.h
index 6e2657d..c367832 100644
--- a/drivers/net/ethernet/mellanox/mlx4/mlx4_en.h
+++ b/drivers/net/ethernet/mellanox/mlx4/mlx4_en.h
@@ -484,9 +484,9 @@ struct mlx4_en_priv {
enum mlx4_en_wol {
MLX4_EN_WOL_MAGIC = (1ULL << 61),
MLX4_EN_WOL_ENABLED = (1ULL << 62),
- MLX4_EN_WOL_DO_MODIFY = (1ULL << 63),
};
+#define MLX4_EN_WOL_DO_MODIFY (1ULL << 63)
void mlx4_en_destroy_netdev(struct net_device *dev);
int mlx4_en_init_netdev(struct mlx4_en_dev *mdev, int port,
--
1.7.7
^ permalink raw reply related
* [PATCH 4/8] net/mlx4_en: using non collapsed CQ on TX
From: Yevgeny Petrilin @ 2011-11-21 8:43 UTC (permalink / raw)
To: davem; +Cc: netdev, yevgenyp, ogerlitz, oren, amirv
From: Yevgeny Petrilin <yevgenyp@mellanox.co.il>
Moving to regular Completion Queue implementation (not collapsed)
Completion for each transmitted packet is written to new entry.
Signed-off-by: Yevgeny Petrilin <yevgenyp@mellanox.co.il>
---
drivers/net/ethernet/mellanox/mlx4/en_cq.c | 7 +--
drivers/net/ethernet/mellanox/mlx4/en_tx.c | 65 ++++++++++++++--------------
2 files changed, 35 insertions(+), 37 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx4/en_cq.c b/drivers/net/ethernet/mellanox/mlx4/en_cq.c
index 227997d..2d1a342 100644
--- a/drivers/net/ethernet/mellanox/mlx4/en_cq.c
+++ b/drivers/net/ethernet/mellanox/mlx4/en_cq.c
@@ -51,10 +51,7 @@ int mlx4_en_create_cq(struct mlx4_en_priv *priv,
int err;
cq->size = entries;
- if (mode == RX)
- cq->buf_size = cq->size * sizeof(struct mlx4_cqe);
- else
- cq->buf_size = sizeof(struct mlx4_cqe);
+ cq->buf_size = cq->size * sizeof(struct mlx4_cqe);
cq->ring = ring;
cq->is_tx = mode;
@@ -120,7 +117,7 @@ int mlx4_en_activate_cq(struct mlx4_en_priv *priv, struct mlx4_en_cq *cq,
cq->size = priv->rx_ring[cq->ring].actual_size;
err = mlx4_cq_alloc(mdev->dev, cq->size, &cq->wqres.mtt, &mdev->priv_uar,
- cq->wqres.db.dma, &cq->mcq, cq->vector, cq->is_tx);
+ cq->wqres.db.dma, &cq->mcq, cq->vector, 0);
if (err)
return err;
diff --git a/drivers/net/ethernet/mellanox/mlx4/en_tx.c b/drivers/net/ethernet/mellanox/mlx4/en_tx.c
index d901b42..3094f94 100644
--- a/drivers/net/ethernet/mellanox/mlx4/en_tx.c
+++ b/drivers/net/ethernet/mellanox/mlx4/en_tx.c
@@ -307,59 +307,60 @@ int mlx4_en_free_tx_buf(struct net_device *dev, struct mlx4_en_tx_ring *ring)
return cnt;
}
-
static void mlx4_en_process_tx_cq(struct net_device *dev, struct mlx4_en_cq *cq)
{
struct mlx4_en_priv *priv = netdev_priv(dev);
struct mlx4_cq *mcq = &cq->mcq;
struct mlx4_en_tx_ring *ring = &priv->tx_ring[cq->ring];
- struct mlx4_cqe *cqe = cq->buf;
+ struct mlx4_cqe *cqe;
u16 index;
- u16 new_index;
+ u16 new_index, ring_index;
u32 txbbs_skipped = 0;
- u32 cq_last_sav;
-
- /* index always points to the first TXBB of the last polled descriptor */
- index = ring->cons & ring->size_mask;
- new_index = be16_to_cpu(cqe->wqe_index) & ring->size_mask;
- if (index == new_index)
- return;
+ u32 cons_index = mcq->cons_index;
+ int size = cq->size;
+ u32 size_mask = ring->size_mask;
+ struct mlx4_cqe *buf = cq->buf;
if (!priv->port_up)
return;
- /*
- * We use a two-stage loop:
- * - the first samples the HW-updated CQE
- * - the second frees TXBBs until the last sample
- * This lets us amortize CQE cache misses, while still polling the CQ
- * until is quiescent.
- */
- cq_last_sav = mcq->cons_index;
- do {
+ index = cons_index & size_mask;
+ cqe = &buf[index];
+ ring_index = ring->cons & size_mask;
+
+ /* Process all completed CQEs */
+ while (XNOR(cqe->owner_sr_opcode & MLX4_CQE_OWNER_MASK,
+ cons_index & size)) {
+ /*
+ * make sure we read the CQE after we read the
+ * ownership bit
+ */
+ rmb();
+
+ /* Skip over last polled CQE */
+ new_index = be16_to_cpu(cqe->wqe_index) & size_mask;
+
do {
- /* Skip over last polled CQE */
- index = (index + ring->last_nr_txbb) & ring->size_mask;
txbbs_skipped += ring->last_nr_txbb;
-
- /* Poll next CQE */
+ ring_index = (ring_index + ring->last_nr_txbb) & size_mask;
+ /* free next descriptor */
ring->last_nr_txbb = mlx4_en_free_tx_desc(
- priv, ring, index,
- !!((ring->cons + txbbs_skipped) &
- ring->size));
- ++mcq->cons_index;
+ priv, ring, ring_index,
+ !!((ring->cons + txbbs_skipped) &
+ ring->size));
+ } while (ring_index != new_index);
- } while (index != new_index);
+ ++cons_index;
+ index = cons_index & size_mask;
+ cqe = &buf[index];
+ }
- new_index = be16_to_cpu(cqe->wqe_index) & ring->size_mask;
- } while (index != new_index);
- AVG_PERF_COUNTER(priv->pstats.tx_coal_avg,
- (u32) (mcq->cons_index - cq_last_sav));
/*
* To prevent CQ overflow we first update CQ consumer and only then
* the ring consumer.
*/
+ mcq->cons_index = cons_index;
mlx4_cq_set_ci(mcq);
wmb();
ring->cons += txbbs_skipped;
--
1.7.7
^ permalink raw reply related
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