* unexpected TCP behaviour when deleting local IP addresses
From: Chris Friesen @ 2012-10-16 21:12 UTC (permalink / raw)
To: netdev
I'm seeing some strange behaviour with local TCP connections. The
scenario goes as follows:
1) create new IP address and assign to eth device
2) TCP server starts listening on that IP address
3) TCP client connects to server
4) remove new IP address
5) kill server with ctrl-C. At this point it appears that because the
address was removed the shutdown message isn't processed properly.
netstat shows the server socket as FIN_WAIT1, but the client socket is
still ESTABLISHED.
6) client writes to the connected socket (this passes with no error)
7) client waits for response from server, and waits forever or until
keepalive expires
This was originally seen on 2.6.27, but I've verified it on 2.6.35.
I'll see about trying it on current git.
Is the waiting forever in step 7 a bug, or is this legitimate TCP
behaviour since the server was basically shut down uncleanly?
If we don't remove the address in step 4, then step 5 results in the
server socket going to FIN_WAIT2 and the client socket going to
CLOSE_WAIT and step 7 returns right away with zero bytes.
In the "remove IP address" case I would expect step 6 to cause some sort
of error since the IP address no longer exists.
The interesting thing is that if you do this sort of scenario with the
client and server on different hosts then you get a "no route to host"
error at step 6.
Curious how this is supposed to work...
Chris
^ permalink raw reply
* RE: [PATCH 1/2] Fix build error caused by broken PCH_PTP module dependency.
From: Keller, Jacob E @ 2012-10-16 21:08 UTC (permalink / raw)
To: David Miller, bhutchings@solarflare.com
Cc: richardcochran@gmail.com, haicheng.li@linux.intel.com,
netdev@vger.kernel.org, tshimizu818@gmail.com,
linux-kernel@vger.kernel.org, haicheng.lee@gmail.com
In-Reply-To: <20121016.161721.460693104731176775.davem@davemloft.net>
> -----Original Message-----
> From: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.kernel.org]
> On Behalf Of David Miller
> Sent: Tuesday, October 16, 2012 1:17 PM
> To: bhutchings@solarflare.com
> Cc: richardcochran@gmail.com; haicheng.li@linux.intel.com;
> netdev@vger.kernel.org; tshimizu818@gmail.com; linux-
> kernel@vger.kernel.org; haicheng.lee@gmail.com
> Subject: Re: [PATCH 1/2] Fix build error caused by broken PCH_PTP module
> dependency.
>
> From: Ben Hutchings <bhutchings@solarflare.com>
> Date: Tue, 16 Oct 2012 21:09:27 +0100
>
> > I think the various kconfig options should be changed as follows:
> >
> > 1. Only PTP_1588_CLOCK selects PPS.
> > 2. Nothing depends on EXPERIMENTAL. (This stuff has been in for 18
> > months and it's even being backported to RHEL 6 now.)
> > 3. Either:
> > (a) The per-driver PHC options select nothing, and the driver options
> > do e.g.:
> > select PTP_1588_CLOCK if IGB_PTP
> > (b) The per-driver PHC options are removed and the driver options do:
> > select PTP_1588_CLOCK
> > (i.e. PHC support is unconditional)
> >
> > Any objections to this, or preference for (a) vs (b)?
>
> No objections, prefer (b).
No objections here, I also prefer (b). The feature shouldn't have much impact unless enabled via hwtstamp_ioctl, and it drastically reduces requirement on end-user needing to enable PHC support.
- Jake
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 1/5] ARM: OMAP2+: gpmc: Fix kernel BUG for DT boot mode
From: Jon Hunter @ 2012-10-16 20:58 UTC (permalink / raw)
To: Tony Lindgren
Cc: Richard Cochran, Afzal Mohammed, Russell King, Arnd Bergmann,
netdev, hvaibhav@ti.com, David Miller, linux-arm-kernel,
linux-omap@vger.kernel.org
In-Reply-To: <20121016174835.GV15569@atomide.com>
Hi Tony,
On 10/16/2012 12:48 PM, Tony Lindgren wrote:
> * Richard Cochran <richardcochran@gmail.com> [121015 12:18]:
>> From: hvaibhav@ti.com <hvaibhav@ti.com>
>>
>> With recent changes in omap gpmc driver code, in case of DT
>> boot mode, where bootloader does not configure gpmc cs space
>> will result into kernel BUG() inside gpmc_mem_init() function,
>> as gpmc cs0 gpmc_config7[0].csvalid bit is set to '1' and
>> gpmc_config7[0].baseaddress is set to '0' on reset.
>>
>> This use-case is applicable for any board/EVM which doesn't have
>> any peripheral connected to gpmc cs0, for example BeagleXM and
>> BeagleBone, so DT boot mode fails.
>>
>> This patch adds of_have_populated_dt() check before creating
>> device, so that for DT boot mode, gpmc probe will not be called
>> which is expected behavior, as gpmc is not supported yet from DT.
>
> I'm applying this one into omap-for-v3.7-rc1/fixes-part2.
>
> Next time, please also cc linux-omap@vger.kernel.org for series
> like this. I'm sure the people reading the omap list are interested
> in these.
This patch appears to be masking an underlying issue. How about
something like the following ...
Cheers
Jon
>From 753a4928bf6f7baa4c001bdca3d15a85e999db4c Mon Sep 17 00:00:00 2001
From: Jon Hunter <jon-hunter@ti.com>
Date: Tue, 16 Oct 2012 15:22:58 -0500
Subject: [PATCH] ARM: OMAP2+: Allow kernel to boot even if GPMC fails to
reserve memory
Currently, if the GPMC driver fails to reserve memory when probed we will
call BUG() and the kernel will not boot. Instead of calling BUG(), return
an error from probe and allow kernel to boot.
Tested on AM335x beagle bone board.
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
---
arch/arm/mach-omap2/gpmc.c | 18 +++++++++++++-----
1 file changed, 13 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 5ac5cf3..8f0d3c8 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -868,9 +868,9 @@ static void __devexit gpmc_mem_exit(void)
}
-static void __devinit gpmc_mem_init(void)
+static int __devinit gpmc_mem_init(void)
{
- int cs;
+ int cs, rc;
unsigned long boot_rom_space = 0;
/* never allocate the first page, to facilitate bug detection;
@@ -890,13 +890,17 @@ static void __devinit gpmc_mem_init(void)
if (!gpmc_cs_mem_enabled(cs))
continue;
gpmc_cs_get_memconf(cs, &base, &size);
- if (gpmc_cs_insert_mem(cs, base, size) < 0)
- BUG();
+ rc = gpmc_cs_insert_mem(cs, base, size);
+ if (IS_ERR_VALUE(rc))
+ return rc;
}
+
+ return 0;
}
static __devinit int gpmc_probe(struct platform_device *pdev)
{
+ int rc;
u32 l;
struct resource *res;
@@ -936,7 +940,11 @@ static __devinit int gpmc_probe(struct platform_device *pdev)
dev_info(gpmc_dev, "GPMC revision %d.%d\n", GPMC_REVISION_MAJOR(l),
GPMC_REVISION_MINOR(l));
- gpmc_mem_init();
+ rc = gpmc_mem_init();
+ if (IS_ERR_VALUE(rc)) {
+ dev_err(gpmc_dev, "failed to reserve memory\n");
+ return rc;
+ }
if (IS_ERR_VALUE(gpmc_setup_irq()))
dev_warn(gpmc_dev, "gpmc_setup_irq failed\n");
--
1.7.9.5
^ permalink raw reply related
* Re: [stable 2.6.32.y] net/ipv4: fix cached ipv4 dsts never invalidated
From: Benjamin LaHaise @ 2012-10-16 20:49 UTC (permalink / raw)
To: David Miller; +Cc: w, stable, netdev
In-Reply-To: <20121016.164539.753785374589743655.davem@davemloft.net>
On Tue, Oct 16, 2012 at 04:45:39PM -0400, David Miller wrote:
> This is only a partial fix.
>
> Only recently did this issue get resolved completely.
>
> See commits surrounding:
Thanks for the pointers David. I'll cherry pick / backport the relevant
changes for Willy as well.
-ben
--
"Thought is the essence of where you are now."
^ permalink raw reply
* Re: [stable 2.6.32.y] net/ipv4: fix cached ipv4 dsts never invalidated
From: David Miller @ 2012-10-16 20:45 UTC (permalink / raw)
To: bcrl; +Cc: w, stable, netdev
In-Reply-To: <20121016203449.GA25889@kvack.org>
From: Benjamin LaHaise <bcrl@kvack.org>
Date: Tue, 16 Oct 2012 16:41:04 -0400
> From: Timo Teras <timo.teras@iki.fi>
> commit d11a4dc18bf41719c9f0d7ed494d295dd2973b92
> Author: Timo Teräs <timo.teras@iki.fi>
> Date: Thu Mar 18 23:20:20 2010 +0000
>
> ipv4: check rt_genid in dst_check
>
> Xfrm_dst keeps a reference to ipv4 rtable entries on each
> cached bundle. The only way to renew xfrm_dst when the underlying
> route has changed, is to implement dst_check for this. This is
> what ipv6 side does too.
>
> The problems started after 87c1e12b5eeb7b30b4b41291bef8e0b41fc3dde9
> ("ipsec: Fix bogus bundle flowi") which fixed a bug causing xfrm_dst
> to not get reused, until that all lookups always generated new
> xfrm_dst with new route reference and path mtu worked. But after the
> fix, the old routes started to get reused even after they were expired
> causing pmtu to break (well it would occationally work if the rtable
> gc had run recently and marked the route obsolete causing dst_check to
> get called).
>
> Signed-off-by: Timo Teras <timo.teras@iki.fi>
> Acked-by: Herbert Xu <herbert@gondor.apana.org.au>
> Signed-off-by: David S. Miller <davem@davemloft.net>
> ---
> Hi Willy,
>
> Can you please consider applying d11a4dc18bf41719c9f0d7ed494d295dd2973b92
> to 2.6.32.y? This fixes an issue with cached IPv4 routes never being
> invalidated. For more details of the problem this causes, see
> http://marc.info/?l=linux-netdev&m=135015076708950&w=2 . Thanks!
This is only a partial fix.
Only recently did this issue get resolved completely.
See commits surrounding:
From b42664f898c976247f7f609b8bb9c94d7475ca10 Mon Sep 17 00:00:00 2001
From: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Date: Mon, 10 Sep 2012 22:09:44 +0000
Subject: [PATCH] netns: move net->ipv4.rt_genid to net->rt_genid
This commit prepares the use of rt_genid by both IPv4 and IPv6.
Initialization is left in IPv4 part.
Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
include/net/net_namespace.h | 10 ++++++++++
include/net/netns/ipv4.h | 1 -
net/ipv4/route.c | 9 ++-------
3 files changed, 12 insertions(+), 8 deletions(-)
diff --git a/include/net/net_namespace.h b/include/net/net_namespace.h
index ae1cd6c..fd87963 100644
--- a/include/net/net_namespace.h
+++ b/include/net/net_namespace.h
@@ -102,6 +102,7 @@ struct net {
#endif
struct netns_ipvs *ipvs;
struct sock *diag_nlsk;
+ atomic_t rt_genid;
};
@@ -300,5 +301,14 @@ static inline void unregister_net_sysctl_table(struct ctl_table_header *header)
}
#endif
+static inline int rt_genid(struct net *net)
+{
+ return atomic_read(&net->rt_genid);
+}
+
+static inline void rt_genid_bump(struct net *net)
+{
+ atomic_inc(&net->rt_genid);
+}
#endif /* __NET_NET_NAMESPACE_H */
diff --git a/include/net/netns/ipv4.h b/include/net/netns/ipv4.h
index 1474dd6..eb24dbc 100644
--- a/include/net/netns/ipv4.h
+++ b/include/net/netns/ipv4.h
@@ -65,7 +65,6 @@ struct netns_ipv4 {
unsigned int sysctl_ping_group_range[2];
long sysctl_tcp_mem[3];
- atomic_t rt_genid;
atomic_t dev_addr_genid;
#ifdef CONFIG_IP_MROUTE
diff --git a/net/ipv4/route.c b/net/ipv4/route.c
index be27cfa9..fd9af60 100644
--- a/net/ipv4/route.c
+++ b/net/ipv4/route.c
@@ -202,11 +202,6 @@ EXPORT_SYMBOL(ip_tos2prio);
static DEFINE_PER_CPU(struct rt_cache_stat, rt_cache_stat);
#define RT_CACHE_STAT_INC(field) __this_cpu_inc(rt_cache_stat.field)
-static inline int rt_genid(struct net *net)
-{
- return atomic_read(&net->ipv4.rt_genid);
-}
-
#ifdef CONFIG_PROC_FS
static void *rt_cache_seq_start(struct seq_file *seq, loff_t *pos)
{
@@ -449,7 +444,7 @@ static inline bool rt_is_expired(const struct rtable *rth)
void rt_cache_flush(struct net *net)
{
- atomic_inc(&net->ipv4.rt_genid);
+ rt_genid_bump(net);
}
static struct neighbour *ipv4_neigh_lookup(const struct dst_entry *dst,
@@ -2506,7 +2501,7 @@ static __net_initdata struct pernet_operations sysctl_route_ops = {
static __net_init int rt_genid_init(struct net *net)
{
- atomic_set(&net->ipv4.rt_genid, 0);
+ atomic_set(&net->rt_genid, 0);
get_random_bytes(&net->ipv4.dev_addr_genid,
sizeof(net->ipv4.dev_addr_genid));
return 0;
--
1.7.11.7
^ permalink raw reply related
* [stable 2.6.32.y] net/ipv4: fix cached ipv4 dsts never invalidated
From: Benjamin LaHaise @ 2012-10-16 20:41 UTC (permalink / raw)
To: Willy Tarreau; +Cc: stable, netdev
From: Timo Teras <timo.teras@iki.fi>
commit d11a4dc18bf41719c9f0d7ed494d295dd2973b92
Author: Timo Teräs <timo.teras@iki.fi>
Date: Thu Mar 18 23:20:20 2010 +0000
ipv4: check rt_genid in dst_check
Xfrm_dst keeps a reference to ipv4 rtable entries on each
cached bundle. The only way to renew xfrm_dst when the underlying
route has changed, is to implement dst_check for this. This is
what ipv6 side does too.
The problems started after 87c1e12b5eeb7b30b4b41291bef8e0b41fc3dde9
("ipsec: Fix bogus bundle flowi") which fixed a bug causing xfrm_dst
to not get reused, until that all lookups always generated new
xfrm_dst with new route reference and path mtu worked. But after the
fix, the old routes started to get reused even after they were expired
causing pmtu to break (well it would occationally work if the rtable
gc had run recently and marked the route obsolete causing dst_check to
get called).
Signed-off-by: Timo Teras <timo.teras@iki.fi>
Acked-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
Hi Willy,
Can you please consider applying d11a4dc18bf41719c9f0d7ed494d295dd2973b92
to 2.6.32.y? This fixes an issue with cached IPv4 routes never being
invalidated. For more details of the problem this causes, see
http://marc.info/?l=linux-netdev&m=135015076708950&w=2 . Thanks!
-ben
Signed-off-by: Benjamin LaHaise <bcrl@kvack.org>
diff --git a/net/ipv4/route.c b/net/ipv4/route.c
index a770df2..32d3961 100644
--- a/net/ipv4/route.c
+++ b/net/ipv4/route.c
@@ -1441,7 +1441,7 @@ void ip_rt_redirect(__be32 old_gw, __be32 daddr, __be32 new_gw,
dev_hold(rt->u.dst.dev);
if (rt->idev)
in_dev_hold(rt->idev);
- rt->u.dst.obsolete = 0;
+ rt->u.dst.obsolete = -1;
rt->u.dst.lastuse = jiffies;
rt->u.dst.path = &rt->u.dst;
rt->u.dst.neighbour = NULL;
@@ -1506,7 +1506,7 @@ static struct dst_entry *ipv4_negative_advice(struct dst_entry *dst)
struct dst_entry *ret = dst;
if (rt) {
- if (dst->obsolete) {
+ if (dst->obsolete > 0) {
ip_rt_put(rt);
ret = NULL;
} else if ((rt->rt_flags & RTCF_REDIRECTED) ||
@@ -1726,7 +1726,9 @@ static void ip_rt_update_pmtu(struct dst_entry *dst, u32 mtu)
static struct dst_entry *ipv4_dst_check(struct dst_entry *dst, u32 cookie)
{
- return NULL;
+ if (rt_is_expired((struct rtable *)dst))
+ return NULL;
+ return dst;
}
static void ipv4_dst_destroy(struct dst_entry *dst)
@@ -1888,7 +1890,8 @@ static int ip_route_input_mc(struct sk_buff *skb, __be32 daddr, __be32 saddr,
if (!rth)
goto e_nobufs;
- rth->u.dst.output= ip_rt_bug;
+ rth->u.dst.output = ip_rt_bug;
+ rth->u.dst.obsolete = -1;
atomic_set(&rth->u.dst.__refcnt, 1);
rth->u.dst.flags= DST_HOST;
@@ -2054,6 +2057,7 @@ static int __mkroute_input(struct sk_buff *skb,
rth->fl.oif = 0;
rth->rt_spec_dst= spec_dst;
+ rth->u.dst.obsolete = -1;
rth->u.dst.input = ip_forward;
rth->u.dst.output = ip_output;
rth->rt_genid = rt_genid(dev_net(rth->u.dst.dev));
@@ -2218,6 +2222,7 @@ local_input:
goto e_nobufs;
rth->u.dst.output= ip_rt_bug;
+ rth->u.dst.obsolete = -1;
rth->rt_genid = rt_genid(net);
atomic_set(&rth->u.dst.__refcnt, 1);
@@ -2444,6 +2449,7 @@ static int __mkroute_output(struct rtable **result,
rth->rt_spec_dst= fl->fl4_src;
rth->u.dst.output=ip_output;
+ rth->u.dst.obsolete = -1;
rth->rt_genid = rt_genid(dev_net(dev_out));
RT_CACHE_STAT_INC(out_slow_tot);
--
"Thought is the essence of where you are now."
^ permalink raw reply related
* Re: [PATCH] bnx2x: fix handling mf storage modes
From: David Miller @ 2012-10-16 20:25 UTC (permalink / raw)
To: dmitry; +Cc: netdev, ariele, eilong
In-Reply-To: <1350386907-25737-1-git-send-email-dmitry@broadcom.com>
From: "Dmitry Kravkov" <dmitry@broadcom.com>
Date: Tue, 16 Oct 2012 13:28:27 +0200
> Since commit a3348722 AFEX FCoE function is continuously reset.
> The patch prevents the resetting and removes debug print
> to stop garbaging syslog.
>
> Signed-off-by: Dmitry Kravkov <dmitry@broadcom.com>
> Signed-off-by: Ariel Elior <ariele@broadcom.com>
> Signed-off-by: Eilon Greenstein <eilong@broadcom.com>
Applied.
^ permalink raw reply
* Re: [PATCH 1/2] Fix build error caused by broken PCH_PTP module dependency.
From: David Miller @ 2012-10-16 20:17 UTC (permalink / raw)
To: bhutchings
Cc: richardcochran, haicheng.li, netdev, tshimizu818, linux-kernel,
haicheng.lee
In-Reply-To: <1350418167.2649.47.camel@bwh-desktop.uk.solarflarecom.com>
From: Ben Hutchings <bhutchings@solarflare.com>
Date: Tue, 16 Oct 2012 21:09:27 +0100
> I think the various kconfig options should be changed as follows:
>
> 1. Only PTP_1588_CLOCK selects PPS.
> 2. Nothing depends on EXPERIMENTAL. (This stuff has been in for 18
> months and it's even being backported to RHEL 6 now.)
> 3. Either:
> (a) The per-driver PHC options select nothing, and the driver options
> do e.g.:
> select PTP_1588_CLOCK if IGB_PTP
> (b) The per-driver PHC options are removed and the driver options do:
> select PTP_1588_CLOCK
> (i.e. PHC support is unconditional)
>
> Any objections to this, or preference for (a) vs (b)?
No objections, prefer (b).
^ permalink raw reply
* Re: [PATCH 1/2] Fix build error caused by broken PCH_PTP module dependency.
From: Ben Hutchings @ 2012-10-16 20:09 UTC (permalink / raw)
To: David Miller, Richard Cochran
Cc: haicheng.li, netdev, tshimizu818, linux-kernel, haicheng.lee
In-Reply-To: <20121003.204336.1981040659629176119.davem@davemloft.net>
On Wed, 2012-10-03 at 20:43 -0400, David Miller wrote:
> From: Ben Hutchings <bhutchings@solarflare.com>
> Date: Wed, 3 Oct 2012 22:45:10 +0100
>
> > I thought of it as being a peripheral feature (which most Solarflare
> > hardware doesn't implement) so it made sense for SFC_PTP to be optional
> > like SFC_MTD and so on. But I'm quite happy to use a select instead, if
> > you want that to be the convention for all drivers implementing PHC.
>
> I think that consistency might trump those conerns you mentioned, at
> least in this case.
Currently such kconfig options look like, for example:
config IGB_PTP
bool "PTP Hardware Clock (PHC)"
default n
depends on IGB && EXPERIMENTAL
select PPS
select PTP_1588_CLOCK
---help---
Say Y here if you want to use PTP Hardware Clock (PHC) in the
driver. Only the basic clock operations have been implemented.
Every timestamp and clock read operations must consult the
overflow counter to form a correct time value.
There are a number of problems with this:
1. PTP_1588_CLOCK depends on PPS, so this has to select it as well.
2. PPS and PTP_1588_CLOCK depend on EXPERIMENTAL, so this has to as
well.
3. It's a boolean, so whatever it selects is built-in, even though the
driver it relates to may be a module.
I think the various kconfig options should be changed as follows:
1. Only PTP_1588_CLOCK selects PPS.
2. Nothing depends on EXPERIMENTAL. (This stuff has been in for 18
months and it's even being backported to RHEL 6 now.)
3. Either:
(a) The per-driver PHC options select nothing, and the driver options
do e.g.:
select PTP_1588_CLOCK if IGB_PTP
(b) The per-driver PHC options are removed and the driver options do:
select PTP_1588_CLOCK
(i.e. PHC support is unconditional)
Any objections to this, or preference for (a) vs (b)?
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [PATCH 1/5] ARM: OMAP2+: gpmc: Fix kernel BUG for DT boot mode
From: Jon Hunter @ 2012-10-16 19:47 UTC (permalink / raw)
To: Richard Cochran
Cc: netdev, Afzal Mohammed, Russell King, Arnd Bergmann,
Tony Lindgren, hvaibhav@ti.com, David Miller, linux-arm-kernel,
linux-omap@vger.kernel.org
In-Reply-To: <41d66042625157d089e9c9532030a6831e79c641.1350327324.git.richardcochran@gmail.com>
On 10/15/2012 02:16 PM, Richard Cochran wrote:
> From: hvaibhav@ti.com <hvaibhav@ti.com>
>
> With recent changes in omap gpmc driver code, in case of DT
> boot mode, where bootloader does not configure gpmc cs space
> will result into kernel BUG() inside gpmc_mem_init() function,
> as gpmc cs0 gpmc_config7[0].csvalid bit is set to '1' and
> gpmc_config7[0].baseaddress is set to '0' on reset.
I am not sure I completely follow the logic here.
Won't this problem occur if the bootloader does not configure the gpmc
cs space AND we are not using DT?
Is the csvalid bit set because we are booting from the internal ROM?
I guess I don't see why csvalid bit being set and a base-address of 0x0
should not be allowed. That should be a valid combination.
One problem I see with gpmc_mem_init() is that it assumes that
BOOT_ROM_SPACE is 1MB for all devices starting at 0x0 apart from the
apollon board. For newer devices such as OMAP4, there is only 48KB of
internal ROM and only mapped to 0x0 when booting from internal ROM. So
this needs to be fixed.
How much internal ROM does the AM335x have and where is it mapped?
> This use-case is applicable for any board/EVM which doesn't have
> any peripheral connected to gpmc cs0, for example BeagleXM and
> BeagleBone, so DT boot mode fails.
>
> This patch adds of_have_populated_dt() check before creating
> device, so that for DT boot mode, gpmc probe will not be called
> which is expected behavior, as gpmc is not supported yet from DT.
Yes, but we do actually still allow some platform devices to be probed
(such as dmtimers) when booting with DT that don't support DT yet. So
this change prevents us from using the gpmc on boards when booting with DT.
I am not convinced that this is addressing the underlying problem with
gpmc_mem_init().
Cheers
Jon
^ permalink raw reply
* Re: [patch net] vlan: fix bond/team enslave of vlan challenged slave/port
From: David Miller @ 2012-10-16 18:56 UTC (permalink / raw)
To: jiri; +Cc: netdev, fubar, andy, kaber, jstanley
In-Reply-To: <1350225056-14144-1-git-send-email-jiri@resnulli.us>
From: Jiri Pirko <jiri@resnulli.us>
Date: Sun, 14 Oct 2012 16:30:56 +0200
> In vlan_uses_dev() check for number of vlan devs rather than existence
> of vlan_info. The reason is that vlan id 0 is there without appropriate
> vlan dev on it by default which prevented from enslaving vlan challenged
> dev.
>
> Reported-by: Jon Stanley <jstanley@rmrf.net>
> Signed-off-by: Jiri Pirko <jiri@resnulli.us>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH] sctp: fix call to SCTP_CMD_PROCESS_SACK in sctp_cmd_interpreter()
From: David Miller @ 2012-10-16 18:56 UTC (permalink / raw)
To: vyasevich; +Cc: nicolas.dichtel, linux-sctp, netdev, zijie.pan
In-Reply-To: <507C2E76.3030801@gmail.com>
From: Vlad Yasevich <vyasevich@gmail.com>
Date: Mon, 15 Oct 2012 11:40:38 -0400
> On 10/15/2012 09:56 AM, nicolas.dichtel@6wind.com wrote:
>> From: Zijie Pan <zijie.pan@6wind.com>
>>
>> Bug introduced by commit edfee0339e681a784ebacec7e8c2dc97dc6d2839
>> (sctp: check src addr when processing SACK to update transport state)
>>
>> Signed-off-by: Zijie Pan <zijie.pan@6wind.com>
>> Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
>
> Shutdown case.. ACK.
>
> Acked-by: Vlad Yasevich <vyasevich@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH] ipv6: addrconf: fix /proc/net/if_inet6
From: David Miller @ 2012-10-16 18:55 UTC (permalink / raw)
To: eric.dumazet; +Cc: janhinnerk.stosch, netdev, mihai.maruseac
In-Reply-To: <1350409047.3954.1295.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Tue, 16 Oct 2012 19:37:27 +0200
> From: Eric Dumazet <edumazet@google.com>
>
> Commit 1d5783030a1 (ipv6/addrconf: speedup /proc/net/if_inet6 filling)
> added bugs hiding some devices from if_inet6 and breaking applications.
>
> "ip -6 addr" could still display all IPv6 addresses, while "ifconfig -a"
> couldnt.
>
> One way to reproduce the bug is by starting in a shell :
>
> unshare -n /bin/bash
> ifconfig lo up
>
> And in original net namespace, lo device disappeared from if_inet6
>
> Reported-by: Jan Hinnerk Stosch <janhinnerk.stosch@gmail.com>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Cc: Mihai Maruseac <mihai.maruseac@gmail.com>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [patch 0/2] s390: network bug fixes for net
From: David Miller @ 2012-10-16 18:42 UTC (permalink / raw)
To: frank.blaschka; +Cc: netdev, linux-s390
In-Reply-To: <20121016052116.210859505@de.ibm.com>
From: frank.blaschka@de.ibm.com
Date: Tue, 16 Oct 2012 07:21:16 +0200
> Hi Dave,
>
> here are some bug fixes for net.
>
> shortlog:
>
> Hendrik Brueckner (1)
> smsgiucv: reestablish IUCV path after resume
>
> Stefan Raspl (1)
> qeth: fix deadlock between recovery and bonding driver
Both applied, thanks.
^ permalink raw reply
* Re: [PATCH] ipv6: addrconf: fix /proc/net/if_inet6
From: David Miller @ 2012-10-16 18:39 UTC (permalink / raw)
To: janhinnerk.stosch; +Cc: eric.dumazet, netdev, mihai.maruseac
In-Reply-To: <CAO_aot45DY4A-uM-O1udZUh9XDKJxszgD7w+iVpJw_qcivEeMw@mail.gmail.com>
From: Jan Hinnerk Stosch <janhinnerk.stosch@gmail.com>
Date: Tue, 16 Oct 2012 20:30:19 +0200
> 2012/10/16 Eric Dumazet <eric.dumazet@gmail.com>:
>> From: Eric Dumazet <edumazet@google.com>
>>
>> Commit 1d5783030a1 (ipv6/addrconf: speedup /proc/net/if_inet6 filling)
>> added bugs hiding some devices from if_inet6 and breaking applications.
>>
>> "ip -6 addr" could still display all IPv6 addresses, while "ifconfig -a"
>> couldnt.
>>
>> One way to reproduce the bug is by starting in a shell :
>>
>> unshare -n /bin/bash
>> ifconfig lo up
>>
>> And in original net namespace, lo device disappeared from if_inet6
>>
>> Reported-by: Jan Hinnerk Stosch <janhinnerk.stosch@gmail.com>
>> Signed-off-by: Eric Dumazet <edumazet@google.com>
>> Cc: Mihai Maruseac <mihai.maruseac@gmail.com>
...
> Yes, everything works fine again. Thank you very much!
Thanks for testing.
^ permalink raw reply
* Re: [PATCH] ipv6: addrconf: fix /proc/net/if_inet6
From: Jan Hinnerk Stosch @ 2012-10-16 18:30 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, netdev, Mihai Maruseac
In-Reply-To: <1350409047.3954.1295.camel@edumazet-glaptop>
2012/10/16 Eric Dumazet <eric.dumazet@gmail.com>:
> From: Eric Dumazet <edumazet@google.com>
>
> Commit 1d5783030a1 (ipv6/addrconf: speedup /proc/net/if_inet6 filling)
> added bugs hiding some devices from if_inet6 and breaking applications.
>
> "ip -6 addr" could still display all IPv6 addresses, while "ifconfig -a"
> couldnt.
>
> One way to reproduce the bug is by starting in a shell :
>
> unshare -n /bin/bash
> ifconfig lo up
>
> And in original net namespace, lo device disappeared from if_inet6
>
> Reported-by: Jan Hinnerk Stosch <janhinnerk.stosch@gmail.com>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Cc: Mihai Maruseac <mihai.maruseac@gmail.com>
> ---
> Please Jan test following fix, thanks !
>
> net/ipv6/addrconf.c | 15 +++++++++------
> 1 file changed, 9 insertions(+), 6 deletions(-)
>
> diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
> index d7c56f8..0424e4e 100644
> --- a/net/ipv6/addrconf.c
> +++ b/net/ipv6/addrconf.c
> @@ -3064,14 +3064,15 @@ static struct inet6_ifaddr *if6_get_first(struct seq_file *seq, loff_t pos)
> struct hlist_node *n;
> hlist_for_each_entry_rcu_bh(ifa, n, &inet6_addr_lst[state->bucket],
> addr_lst) {
> + if (!net_eq(dev_net(ifa->idev->dev), net))
> + continue;
> /* sync with offset */
> if (p < state->offset) {
> p++;
> continue;
> }
> state->offset++;
> - if (net_eq(dev_net(ifa->idev->dev), net))
> - return ifa;
> + return ifa;
> }
>
> /* prepare for next bucket */
> @@ -3089,18 +3090,20 @@ static struct inet6_ifaddr *if6_get_next(struct seq_file *seq,
> struct hlist_node *n = &ifa->addr_lst;
>
> hlist_for_each_entry_continue_rcu_bh(ifa, n, addr_lst) {
> + if (!net_eq(dev_net(ifa->idev->dev), net))
> + continue;
> state->offset++;
> - if (net_eq(dev_net(ifa->idev->dev), net))
> - return ifa;
> + return ifa;
> }
>
> while (++state->bucket < IN6_ADDR_HSIZE) {
> state->offset = 0;
> hlist_for_each_entry_rcu_bh(ifa, n,
> &inet6_addr_lst[state->bucket], addr_lst) {
> + if (!net_eq(dev_net(ifa->idev->dev), net))
> + continue;
> state->offset++;
> - if (net_eq(dev_net(ifa->idev->dev), net))
> - return ifa;
> + return ifa;
> }
> }
>
>
>
Yes, everything works fine again. Thank you very much!
^ permalink raw reply
* Re: amd64, v3.6.0: Kernel panic + BUG at net/netfilter/nf_conntrack_core.c:220!
From: Ian Applegate @ 2012-10-16 18:03 UTC (permalink / raw)
To: Pablo Neira Ayuso
Cc: Borislav Petkov, linux-kernel, netfilter-devel, netfilter,
coreteam, netdev
In-Reply-To: <20121016162709.GA13897@1984>
I will be doing much wider testing on 3.6 this week, will keep you
updated if I see this issue again. I don't see a logical way into that
trap myself and looking at the revision history we've been running
this code path for a very long time without issue. The machine in
question has a fairly high MTBF which is why I thought this odd, but
it is most likely random memory corruption.
Thanks!
Ian Applegate
On Tue, Oct 16, 2012 at 9:27 AM, Pablo Neira Ayuso <pablo@netfilter.org> wrote:
> On Fri, Oct 12, 2012 at 01:32:06AM +0200, Pablo Neira Ayuso wrote:
>> On Thu, Oct 11, 2012 at 11:27:33PM +0200, Borislav Petkov wrote:
>> > On Thu, Oct 11, 2012 at 12:13:33PM -0700, Ian Applegate wrote:
>> > > On machines serving mainly http traffic we are seeing the following
>> > > panic, which is not yet reproducible.
>> >
>> > Must be this BUG_ON:
>> >
>> > if (!nf_ct_is_confirmed(ct)) {
>> > BUG_ON(hlist_nulls_unhashed(&ct->tuplehash[IP_CT_DIR_ORIGINAL].hnnode));
>> > hlist_nulls_del_rcu(&ct->tuplehash[IP_CT_DIR_ORIGINAL].hnnode);
>> > }
>>
>> At quick glance, I think we're hitting a memory corruption, I don't
>> see by now any sane code path to reach that bugtrap.
>
> Did you manage to obtain more information regarding this bug?
>
> I don't find any recent change in the conntrack source that may lead
> us to hit that.
>
> Thanks.
>
>> More comments below:
>>
>> > Spamming some more lists and leaving the rest for reference.
>> >
>> > >
>> > >
>> > > [180926.566743] ------------[ cut here ]------------
>> > > [180926.572034] kernel BUG at net/netfilter/nf_conntrack_core.c:220!
>> > > [180926.578873] invalid opcode: 0000 [#1] SMP
>> > > [180926.583594] Modules linked in: xfs exportfs ipmi_devintf ipmi_si
>> > > ipmi_msghandler dm_mod md_mod nf_conntr
>> > > ack_ipv6 nf_defrag_ipv6 ip6table_filter ip6table_raw ip6_tables
>> > > nf_conntrack_ipv4 nf_defrag_ipv4 xt_tcpudp x
>> > > t_conntrack xt_multiport iptable_filter xt_NOTRACK nf_conntrack
>> > > iptable_raw ip_tables x_tables nfsv4 auth_rp
>> > > cgss fuse nfsv3 nfs_acl nfs fscache lockd sunrpc sfc mtd i2c_algo_bit
>> > > i2c_core mdio igb dca uhci_hcd coretem
>> > > p acpi_cpufreq kvm_intel kvm crc32c_intel aesni_intel ablk_helper
>> > > cryptd aes_x86_64 aes_generic evdev sd_mod
>> > > crc_t10dif mperf snd_pcm ahci snd_timer tpm_tis microcode snd tpm
>> > > libahci tpm_bios soundcore libata snd_pag
>> > > e_alloc pcspkr ehci_hcd lpc_ich usbcore mfd_core hpsa scsi_mod
>> > > usb_common button processor thermal_sys
>> > > [180926.657762] CPU 12
>> > > [180926.660008] Pid: 5948, comm: nginx-fl Not tainted 3.6.0-cloudflare
>> > > #1 HP ProLiant DL180 G6
>> > > [180926.669820] RIP: 0010:[<ffffffffa02ccdd1>] [<ffffffffa02ccdd1>]
>> > > destroy_conntrack+0x55/0xa9 [nf_conntrack]
>> > > [180926.680871] RSP: 0018:ffff8805bd73fbb8 EFLAGS: 00010246
>> > > [180926.686930] RAX: 0000000000000000 RBX: ffff8806b6f56c30 RCX:
>> > > ffff8805bd73fc48
>> > > [180926.695055] RDX: 0000000000000000 RSI: 0000000000000006 RDI:
>> > > ffff8806b6f56c30
>> > > [180926.703179] RBP: ffffffff81651780 R08: 00000000000172e0 R09:
>> > > ffffffff812cef91
>> > > [180926.711304] R10: dead000000200200 R11: dead000000100100 R12:
>> > > ffff8806b6f56c30
>> > > [180926.727451] R13: 0000000000000000 R14: ffffffffa02d6030 R15:
>> > > 0000000000000000
>> > > [180926.735575] FS: 00007f382cdb2710(0000) GS:ffff880627cc0000(0000)
>> > > knlGS:0000000000000000
>> > > [180926.744766] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>> > > [180926.751312] CR2: ffffffffff600400 CR3: 00000005bd8d3000 CR4:
>> > > 00000000000007e0
>> > > [180926.759436] DR0: 0000000000000000 DR1: 0000000000000000 DR2:
>> > > 0000000000000000
>> > > [180926.767560] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7:
>> > > 0000000000000400
>> > > [180926.775686] Process nginx-fl (pid: 5948, threadinfo
>> > > ffff8805bd73e000, task ffff8805c9755960)
>> > > [180926.785265] Stack:
>> > > [180926.787634] 0000000000000000 ffffffff81651780 ffff8802720c2900
>> > > ffffffffa02cde78
>> > > [180926.796087] ffffffff81651ec0 ffffffffa02d6030 00000000bff0efab
>> > > ffff8805ffffffff
>> > > [180926.804532] 0002880500000002 0000000300000014 0000001400000003
>> > > 06ff880600000002
>> > > [180926.812985] Call Trace:
>> > > [180926.815845] [<ffffffffa02cde78>] ? nf_conntrack_in+0x4ed/0x5bc
>> > > [nf_conntrack]
>>
>> Here below the trace shows the output path to close a tcp socket. But
>> the line above refers to a conntrack function that is called in the
>> input path.
>>
>> If this process is just acting as plain http server, this backtrace
>> doesn't seem consistent to me.
>>
>> > > [180926.824069] [<ffffffff812ac195>] ? nf_iterate+0x41/0x77
>> > > [180926.830131] [<ffffffff812b3820>] ? ip_options_echo+0x2ed/0x2ed
>> > > [180926.836873] [<ffffffff812ac2ee>] ? nf_hook_slow+0x68/0xfd
>> > > [180926.843127] [<ffffffff812b3820>] ? ip_options_echo+0x2ed/0x2ed
>> > > [180926.849866] [<ffffffff812b55a8>] ? __ip_local_out+0x98/0x9d
>> > > [180926.856315] [<ffffffff812b55b6>] ? ip_local_out+0x9/0x19
>> > > [180926.862465] [<ffffffff812c7582>] ? tcp_transmit_skb+0x7ae/0x7f1
>> > > [180926.869305] [<ffffffff810fff4c>] ? virt_to_head_page+0x9/0x2c
>> > > [180926.875949] [<ffffffff812c78a6>] ? tcp_send_active_reset+0xd5/0x101
>> > > [180926.883175] [<ffffffff812bc38f>] ? tcp_close+0x118/0x354
>> > > [180926.889334] [<ffffffff812dbdc2>] ? inet_release+0x75/0x7b
>> > > [180926.895591] [<ffffffff81278bff>] ? sock_release+0x19/0x73
>> > > [180926.901845] [<ffffffff81278c7b>] ? sock_close+0x22/0x27
>> > > [180926.907906] [<ffffffff81109de8>] ? __fput+0xe9/0x1ae
>> > > [180926.913677] [<ffffffff81057157>] ? task_work_run+0x53/0x67
>> > > [180926.920031] [<ffffffff8100e50c>] ? do_notify_resume+0x79/0x8d
>> > > [180926.926673] [<ffffffff8134e5b2>] ? int_signal+0x12/0x17
>> > > [180926.932732] Code: 05 48 89 df ff d0 48 c7 c7 30 66 2d a0 e8 11 b0
>> > > 07 e1 48 89 df e8 72 25 00 00 48 8b 43
>> > > 78 a8 08 75 2a 48 8b 53 10 48 85 d2 75 04 <0f> 0b eb fe 48 8b 43 08
>> > > 48 89 02 a8 01 75 04 48 89 50 08 48 be
>> > > [180926.954788] RIP [<ffffffffa02ccdd1>] destroy_conntrack+0x55/0xa9
>> > > [nf_conntrack]
>> > > [180926.963217] RSP <ffff8805bd73fbb8>
>> > > [180926.967700] ---[ end trace 54a660a52afd5820 ]---
>> > > [180926.973038] Kernel panic - not syncing: Fatal exception in interrupt
>> > >
>> > > ---
>> > > Ian Applegate
>> > > CloudFlare
>> > > --
>> > > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>> > > the body of a message to majordomo@vger.kernel.org
>> > > More majordomo info at http://vger.kernel.org/majordomo-info.html
>> > > Please read the FAQ at http://www.tux.org/lkml/
>> >
>> > --
>> > Regards/Gruss,
>> > Boris.
^ permalink raw reply
* Re: [PATCH 5/5] arm/dts: am33xx: Add cpsw and mdio module nodes for AM33XX
From: Tony Lindgren @ 2012-10-16 17:51 UTC (permalink / raw)
To: Richard Cochran
Cc: netdev, Mugunthan V N, Russell King, Arnd Bergmann,
Vaibhav Hiremath, David Miller, linux-arm-kernel
In-Reply-To: <b4d88ef79fb0dec95bb598aaf1f15f0a7344c435.1350327325.git.richardcochran@gmail.com>
* Richard Cochran <richardcochran@gmail.com> [121015 12:23]:
> From: Mugunthan V N <mugunthanvnm@ti.com>
>
> Add CPSW and MDIO related device tree data for AM33XX.
> Also enable them into board/evm dts files by providing
> respective phy-id.
These omap specific .dts changes should be queued by Benoit Cousson,
please cc him and linux-omap.
Regards,
Tony
^ permalink raw reply
* Re: [PATCH 2/5] ARM: OMAP3+: hwmod: Add AM33XX HWMOD data for davinci_mdio
From: Tony Lindgren @ 2012-10-16 17:50 UTC (permalink / raw)
To: Richard Cochran
Cc: netdev, Mugunthan V N, Russell King, Arnd Bergmann,
linux-arm-kernel, David Miller
In-Reply-To: <c048044c10b5712e25d190a0ae1dfee3155f81f7.1350327325.git.richardcochran@gmail.com>
* Richard Cochran <richardcochran@gmail.com> [121015 12:23]:
> From: Mugunthan V N <mugunthanvnm@ti.com>
>
> This patch adds minimal hwmod support for davinci mdio driver. This patch
> requires rework on parent child relation between cpsw and davinci mdio
> hwmod data to support runtime PM.
Looks like Paul Walmsley may have missed this one, maybe please resend
with him and linux-omap cc:d.
Regards,
Tony
^ permalink raw reply
* Re: [PATCH 1/5] ARM: OMAP2+: gpmc: Fix kernel BUG for DT boot mode
From: Tony Lindgren @ 2012-10-16 17:48 UTC (permalink / raw)
To: Richard Cochran
Cc: netdev, linux-arm-kernel, Arnd Bergmann, David Miller,
Russell King, hvaibhav@ti.com, Afzal Mohammed
In-Reply-To: <41d66042625157d089e9c9532030a6831e79c641.1350327324.git.richardcochran@gmail.com>
* Richard Cochran <richardcochran@gmail.com> [121015 12:18]:
> From: hvaibhav@ti.com <hvaibhav@ti.com>
>
> With recent changes in omap gpmc driver code, in case of DT
> boot mode, where bootloader does not configure gpmc cs space
> will result into kernel BUG() inside gpmc_mem_init() function,
> as gpmc cs0 gpmc_config7[0].csvalid bit is set to '1' and
> gpmc_config7[0].baseaddress is set to '0' on reset.
>
> This use-case is applicable for any board/EVM which doesn't have
> any peripheral connected to gpmc cs0, for example BeagleXM and
> BeagleBone, so DT boot mode fails.
>
> This patch adds of_have_populated_dt() check before creating
> device, so that for DT boot mode, gpmc probe will not be called
> which is expected behavior, as gpmc is not supported yet from DT.
I'm applying this one into omap-for-v3.7-rc1/fixes-part2.
Next time, please also cc linux-omap@vger.kernel.org for series
like this. I'm sure the people reading the omap list are interested
in these.
Regards,
Tony
^ permalink raw reply
* [PATCH] ipv6: addrconf: fix /proc/net/if_inet6
From: Eric Dumazet @ 2012-10-16 17:37 UTC (permalink / raw)
To: Jan Hinnerk Stosch, David Miller; +Cc: netdev, Mihai Maruseac
In-Reply-To: <1350406522.3954.1242.camel@edumazet-glaptop>
From: Eric Dumazet <edumazet@google.com>
Commit 1d5783030a1 (ipv6/addrconf: speedup /proc/net/if_inet6 filling)
added bugs hiding some devices from if_inet6 and breaking applications.
"ip -6 addr" could still display all IPv6 addresses, while "ifconfig -a"
couldnt.
One way to reproduce the bug is by starting in a shell :
unshare -n /bin/bash
ifconfig lo up
And in original net namespace, lo device disappeared from if_inet6
Reported-by: Jan Hinnerk Stosch <janhinnerk.stosch@gmail.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Mihai Maruseac <mihai.maruseac@gmail.com>
---
Please Jan test following fix, thanks !
net/ipv6/addrconf.c | 15 +++++++++------
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index d7c56f8..0424e4e 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -3064,14 +3064,15 @@ static struct inet6_ifaddr *if6_get_first(struct seq_file *seq, loff_t pos)
struct hlist_node *n;
hlist_for_each_entry_rcu_bh(ifa, n, &inet6_addr_lst[state->bucket],
addr_lst) {
+ if (!net_eq(dev_net(ifa->idev->dev), net))
+ continue;
/* sync with offset */
if (p < state->offset) {
p++;
continue;
}
state->offset++;
- if (net_eq(dev_net(ifa->idev->dev), net))
- return ifa;
+ return ifa;
}
/* prepare for next bucket */
@@ -3089,18 +3090,20 @@ static struct inet6_ifaddr *if6_get_next(struct seq_file *seq,
struct hlist_node *n = &ifa->addr_lst;
hlist_for_each_entry_continue_rcu_bh(ifa, n, addr_lst) {
+ if (!net_eq(dev_net(ifa->idev->dev), net))
+ continue;
state->offset++;
- if (net_eq(dev_net(ifa->idev->dev), net))
- return ifa;
+ return ifa;
}
while (++state->bucket < IN6_ADDR_HSIZE) {
state->offset = 0;
hlist_for_each_entry_rcu_bh(ifa, n,
&inet6_addr_lst[state->bucket], addr_lst) {
+ if (!net_eq(dev_net(ifa->idev->dev), net))
+ continue;
state->offset++;
- if (net_eq(dev_net(ifa->idev->dev), net))
- return ifa;
+ return ifa;
}
}
^ permalink raw reply related
* Re: EG20T and Micrel KSZ9021 Gigabit Ethernet
From: James Kosin @ 2012-10-16 17:21 UTC (permalink / raw)
Cc: netdev
In-Reply-To: <507D95A2.9090206@intcomgrp.com>
I have to remember to use plain text only....
On 10/16/2012 1:13 PM, James Kosin wrote:
> Hmmm... interesting turn of events.
>
> The problem seems to be in 10 speed support. I hooked the Ethernet
> PHY to a100TX port and don't get these errors.
>
> James
>
> On 10/5/2012 5:09 PM, Francois Romieu wrote:
>> (please don't top post)
>>
>> James Kosin <jkosin@intcomgrp.com> :
>>> The driver is always reporting:
>>> [...] pch_gbe: Transfer Carrier Sense Error
>> You should send more information. Say dmesg, link stats (ip link),
>> ethtool information, stats and offload settings.
>>
>> We have a small Micrel ksz9021 phy driver that the pch_gbe driver does
>> not use and the latter pokes into some phy specific register (0x10) that
>> the Micrel document does not include in its list of vendor registers...
>>
>> Does your motherboard vendor offer some linux driver ?
>>
>> /note to myself: pch_gbe should use standard mii.h registers instead
>> of defining its own redundant set of registers.
>>
>> --
>> Ueimor
>>
>
^ permalink raw reply
* Re: [PATCH V2 0/7] support the cpts found on am335x devices
From: Richard Cochran @ 2012-10-16 17:14 UTC (permalink / raw)
To: N, Mugunthan V
Cc: netdev@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
David Miller, Chemparathy, Cyril, Govindarajan, Sriramakrishnan
In-Reply-To: <EB1619762EAF8B4E97A227FB77B7E0293E9F82F0@DBDE01.ent.ti.com>
On Tue, Oct 16, 2012 at 04:33:55PM +0000, N, Mugunthan V wrote:
> I had seen some issues with the patch series.
Please take another look. Excepting the last, none of your points
holds water.
> * CPTS will hold only LSB 32 bits of 64 bit Timer and the upper 32 bit
> time value has to be taken care by the software, but the time stamp
> which is passed to skb or PTP clock consist of only 32 bit time value
The driver handles this already.
> * CPTS interrupts should be utilized to service Half and Full roll over
> events as it is non sync events with respect to get/set time and PTP
> pkt Tx/Rx
Nope, no need for interrupts, since we already have a better way to
handle this.
> * CPTS Time which is obtained from hardware is not actually a nano
> seconds as the CPTS ref clock is tied to 250MHz for AM335x.
Did you even look at the code in my patch?
> * CPSW register mapping done in this patch series removes the CPSW
> driver support for previous version found in TI814x
In which Linux version (or commit) did this driver appear?
I never saw it.
> * CPSW Time stamping is done only for port 0 and port 1 is not done
Yes, you are right, and it is strange that the hardware time stamps on
the external ports of the switch, and not at the host port as it
should. Of course it does present us with a problem, since we cannot
reasonably have both ports time stamping at the same time. I propose
simply using a device tree attribute to tell which port to activate.
Thanks,
Richard
^ permalink raw reply
* Re: bpf filter : support for vlan tag
From: Eric Dumazet @ 2012-10-16 17:06 UTC (permalink / raw)
To: Ani Sinha; +Cc: Daniel Borkmann, netdev
In-Reply-To: <CAOxq_8NKn96RPE327L54c0zozdksT5dEhaKGMP+7rV4VMMbT+g@mail.gmail.com>
On Tue, 2012-10-16 at 09:54 -0700, Ani Sinha wrote:
> On Tue, Oct 16, 2012 at 4:28 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>
> >
> > Note that if speed is needed, we also want to update various JIT
> > implementations.
> >
>
> Thanks Eric for the patch. I will take a look at it. We also need the
> JIT module support as well (for x86 and x86_64) since we use the JIT
> filter. I have been studying the various instructions and how other
> filter operations have been implemented using them but it will take me
> a little bit more time to understand the code.
Dont worry, I'll do the JIT part (but only for x86_64, we dont support
i386)
^ permalink raw reply
* Re: [RFC PATCH] net/core: support runtime PM on net_device
From: Rafael J. Wysocki @ 2012-10-16 17:07 UTC (permalink / raw)
To: Ming Lei; +Cc: David S. Miller, Oliver Neukum, Alan Stern, netdev, linux-pm
In-Reply-To: <1349873913-10701-1-git-send-email-ming.lei@canonical.com>
On Wednesday 10 of October 2012 20:58:33 Ming Lei wrote:
> In ioctl path on net_device, the physical deivce is often
> touched, but the physical device may have been put into runtime
> suspend state already, so cause some utilitis(ifconfig, ethtool,
> ...) to return failure in this situation.
>
> This patch enables runtime PM on net_device and mark it as
> no_callbacks, and resumes the net_device if physical device
> is to be accessed, then suspends it after completion of the
> access.
>
> This patch fixes the problem above.
>
> Signed-off-by: Ming Lei <ming.lei@canonical.com>
Well, it looks good in principle.
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> ---
> net/core/dev.c | 83 +++++++++++++++++++++++++++++++-------------------
> net/core/ethtool.c | 9 ++++--
> net/core/net-sysfs.c | 4 +++
> 3 files changed, 63 insertions(+), 33 deletions(-)
>
> diff --git a/net/core/dev.c b/net/core/dev.c
> index de2bad7..d46d4ed 100644
> --- a/net/core/dev.c
> +++ b/net/core/dev.c
> @@ -135,6 +135,7 @@
> #include <linux/net_tstamp.h>
> #include <linux/static_key.h>
> #include <net/flow_keys.h>
> +#include <linux/pm_runtime.h>
>
> #include "net-sysfs.h"
>
> @@ -4966,39 +4967,24 @@ static int dev_ifsioc_locked(struct net *net, struct ifreq *ifr, unsigned int cm
> /*
> * Perform the SIOCxIFxxx calls, inside rtnl_lock()
> */
> -static int dev_ifsioc(struct net *net, struct ifreq *ifr, unsigned int cmd)
> +static int __dev_ifsioc(struct net *net, struct ifreq *ifr, unsigned int cmd)
> {
> int err;
> struct net_device *dev = __dev_get_by_name(net, ifr->ifr_name);
> const struct net_device_ops *ops;
>
> - if (!dev)
> - return -ENODEV;
> -
> ops = dev->netdev_ops;
>
> switch (cmd) {
> case SIOCSIFFLAGS: /* Set interface flags */
> return dev_change_flags(dev, ifr->ifr_flags);
>
> - case SIOCSIFMETRIC: /* Set the metric on the interface
> - (currently unused) */
> - return -EOPNOTSUPP;
> -
> case SIOCSIFMTU: /* Set the MTU of a device */
> return dev_set_mtu(dev, ifr->ifr_mtu);
>
> case SIOCSIFHWADDR:
> return dev_set_mac_address(dev, &ifr->ifr_hwaddr);
>
> - case SIOCSIFHWBROADCAST:
> - if (ifr->ifr_hwaddr.sa_family != dev->type)
> - return -EINVAL;
> - memcpy(dev->broadcast, ifr->ifr_hwaddr.sa_data,
> - min(sizeof ifr->ifr_hwaddr.sa_data, (size_t) dev->addr_len));
> - call_netdevice_notifiers(NETDEV_CHANGEADDR, dev);
> - return 0;
> -
> case SIOCSIFMAP:
> if (ops->ndo_set_config) {
> if (!netif_device_present(dev))
> @@ -5022,21 +5008,6 @@ static int dev_ifsioc(struct net *net, struct ifreq *ifr, unsigned int cmd)
> if (!netif_device_present(dev))
> return -ENODEV;
> return dev_mc_del_global(dev, ifr->ifr_hwaddr.sa_data);
> -
> - case SIOCSIFTXQLEN:
> - if (ifr->ifr_qlen < 0)
> - return -EINVAL;
> - dev->tx_queue_len = ifr->ifr_qlen;
> - return 0;
> -
> - case SIOCSIFNAME:
> - ifr->ifr_newname[IFNAMSIZ-1] = '\0';
> - return dev_change_name(dev, ifr->ifr_newname);
> -
> - case SIOCSHWTSTAMP:
> - err = net_hwtstamp_validate(ifr);
> - if (err)
> - return err;
> /* fall through */
>
> /*
> @@ -5072,6 +5043,56 @@ static int dev_ifsioc(struct net *net, struct ifreq *ifr, unsigned int cmd)
> return err;
> }
>
> +static int dev_ifsioc(struct net *net, struct ifreq *ifr, unsigned int cmd)
> +{
> + int err;
> + struct net_device *dev = __dev_get_by_name(net, ifr->ifr_name);
> + const struct net_device_ops *ops;
> +
> + if (!dev)
> + return -ENODEV;
> +
> + ops = dev->netdev_ops;
> +
> + switch (cmd) {
> + case SIOCSIFMETRIC: /* Set the metric on the interface
> + (currently unused) */
> + return -EOPNOTSUPP;
> +
> + case SIOCSIFHWBROADCAST:
> + if (ifr->ifr_hwaddr.sa_family != dev->type)
> + return -EINVAL;
> + memcpy(dev->broadcast, ifr->ifr_hwaddr.sa_data,
> + min(sizeof ifr->ifr_hwaddr.sa_data, (size_t) dev->addr_len));
> + call_netdevice_notifiers(NETDEV_CHANGEADDR, dev);
> + return 0;
> +
> + case SIOCSIFTXQLEN:
> + if (ifr->ifr_qlen < 0)
> + return -EINVAL;
> + dev->tx_queue_len = ifr->ifr_qlen;
> + return 0;
> +
> + case SIOCSIFNAME:
> + ifr->ifr_newname[IFNAMSIZ-1] = '\0';
> + return dev_change_name(dev, ifr->ifr_newname);
> +
> + case SIOCSHWTSTAMP:
> + err = net_hwtstamp_validate(ifr);
> + if (err)
> + return err;
> + }
> +
> + if (pm_runtime_get_sync(&dev->dev) < 0)
> + return -ENODEV;
> +
> + err = __dev_ifsioc(net, ifr, cmd);
> +
> + pm_runtime_put(&dev->dev);
> +
> + return err;
> +}
> +
> /*
> * This function handles all "interface"-type I/O control requests. The actual
> * 'doing' part of this is dev_ifsioc above.
> diff --git a/net/core/ethtool.c b/net/core/ethtool.c
> index 4d64cc2..2dc43da 100644
> --- a/net/core/ethtool.c
> +++ b/net/core/ethtool.c
> @@ -25,6 +25,7 @@
> #include <linux/slab.h>
> #include <linux/rtnetlink.h>
> #include <linux/sched.h>
> +#include <linux/pm_runtime.h>
>
> /*
> * Some useful ethtool_ops methods that're device independent.
> @@ -1464,10 +1465,13 @@ int dev_ethtool(struct net *net, struct ifreq *ifr)
> return -EPERM;
> }
>
> + if ((ret = pm_runtime_get_sync(&dev->dev)) < 0)
> + return -ENODEV;
> +
> if (dev->ethtool_ops->begin) {
> rc = dev->ethtool_ops->begin(dev);
> if (rc < 0)
> - return rc;
> + goto exit;
> }
> old_features = dev->features;
>
> @@ -1648,6 +1652,7 @@ int dev_ethtool(struct net *net, struct ifreq *ifr)
>
> if (old_features != dev->features)
> netdev_features_change(dev);
> -
> +exit:
> + pm_runtime_put(&dev->dev);
> return rc;
> }
> diff --git a/net/core/net-sysfs.c b/net/core/net-sysfs.c
> index bcf02f6..c9adb89 100644
> --- a/net/core/net-sysfs.c
> +++ b/net/core/net-sysfs.c
> @@ -23,6 +23,7 @@
> #include <linux/export.h>
> #include <linux/jiffies.h>
> #include <net/wext.h>
> +#include <linux/pm_runtime.h>
>
> #include "net-sysfs.h"
>
> @@ -1415,6 +1416,9 @@ int netdev_register_kobject(struct net_device *net)
> if (error)
> return error;
>
> + pm_runtime_no_callbacks(dev);
> + pm_runtime_enable(dev);
> +
> error = register_queue_kobjects(net);
> if (error) {
> device_del(dev);
>
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
^ 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