* Re: [RFC] dependencies for platform drivers (was Re: ax88796: add superh to kconfig dependencies)
From: Ralf Baechle @ 2007-11-09 9:26 UTC (permalink / raw)
To: Al Viro; +Cc: Magnus Damm, netdev, lethal, ben-linux, akpm, jeff, linux-arch
In-Reply-To: <20071108081854.GN8181@ftp.linux.org.uk>
On Thu, Nov 08, 2007 at 08:18:54AM +0000, Al Viro wrote:
> On Thu, Nov 08, 2007 at 04:31:05PM +0900, Magnus Damm wrote:
> > config AX88796
> > tristate "ASIX AX88796 NE2000 clone support"
> > - depends on ARM || MIPS
> > + depends on ARM || MIPS || SUPERH
>
> You know, that really sucks more and more. How about doing the following:
> a) making it depend on PLAT_HAS_AX88796
> b) adding selects for all subarchitectures that have the corresponding
> platform device
> and setting that as a uniform policy for platform drivers? For things like
> SM501 we would do
> config MFD_SM501
> depends on PCI || PLAT_HAS_SM501
> etc.
>
> Seriously, folks, we are getting shitloads of platform drivers with no
> dependencies whatsoever, needed on a handful of targets and occasionally
> failing to build on unrelated architectures. Moreover, having a list
> of architectures in dependencies for each of those suckers is a PITA
> from the conflict POV. Not to mention platform drivers that fall into
> the mainline kernel with not a single platform device for them, etc.
>
> Comments?
commit def47c5095d53814512bb0c62ec02dfdec769db1
Author: Jeff Garzik <jeff@garzik.org>
Date: Tue Jul 10 14:06:48 2007 -0400
[netdrvr] Fix dependencies for ax88796 ne2k clone driver
It needs writesb(), not available on all platforms.
Signed-off-by: Jeff Garzik <jeff@garzik.org>
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index a3bef22..a64c2fb 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -199,6 +199,7 @@ source "drivers/net/arm/Kconfig"
config AX88796
tristate "ASIX AX88796 NE2000 clone support"
+ depends on ARM || MIPS
select CRC32
select MII
help
If writesb() is not an official API then maybe the answer should have been
to either add that API to other architectures or fix the driver.
I guess this incident means I need to go through all Kconfig* files to
see what bogus architecture dependencies on MIPS or !MIPS exist ...
Ralf
^ permalink raw reply related
* Re: [RFC] dependencies for platform drivers (was Re: ax88796: add superh to kconfig dependencies)
From: Paul Mundt @ 2007-11-09 9:40 UTC (permalink / raw)
To: Ralf Baechle
Cc: Al Viro, Magnus Damm, netdev, ben-linux, akpm, jeff, linux-arch
In-Reply-To: <20071109092652.GA13350@linux-mips.org>
On Fri, Nov 09, 2007 at 09:26:52AM +0000, Ralf Baechle wrote:
> If writesb() is not an official API then maybe the answer should have been
> to either add that API to other architectures or fix the driver.
>
> I guess this incident means I need to go through all Kconfig* files to
> see what bogus architecture dependencies on MIPS or !MIPS exist ...
>
While writesb() isn't an official API, the iowriteX_rep() interfaces
theoretically are. Tidying up the driver for iomap is probably a better
option.
^ permalink raw reply
* Re: [PATCH 1/1]: Using ICMP type and code in xfrm selector
From: Herbert Xu @ 2007-11-09 11:29 UTC (permalink / raw)
To: Joy Latten; +Cc: netdev, davem, tgraf
In-Reply-To: <200711022317.lA2NHeX2018386@faith.austin.ibm.com>
On Fri, Nov 02, 2007 at 06:17:40PM -0500, Joy Latten wrote:
>
> While fixing this I wondered why we put icmp message
> type in sport and code in dport?
Where we put the info in the kernel is not specified by the
RFC. It has to document where you put it in IKE because IKE
is used by two systems which must agree on one format.
Your patch looks OK to me but in general we want to encourage
applications to use the xfrm_user interface as pf_key is not
portable anyway because of the lack of a standard specification
that covers the SPD.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH] using mii-bitbang on different processor ports - update the booting-without-of.txt-file
From: Sergej Stepanov @ 2007-11-09 11:38 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, netdev, jgarzik
In-Reply-To: <47336F9D.8060405@freescale.com>
Am Donnerstag, den 08.11.2007, 14:20 -0600 schrieb Scott Wood:
> Sergej Stepanov wrote:
> > If both mdio and mdc controlling pins are on the same processor port,
> > one resource should be used.
> > Otherwise, two resources are used: the 1-st - mdio, the 2-nd - mdc.
>
> How about:
> The first reg resource is the I/O port register block on which MDIO
> resides. The second reg resource is the I/O port register block on
> which MDC resides. If there is only one reg resource, it is used for
> both MDIO and MDC.
>
Ok.
> We also need to change the reference to port C in fsl,mdio-pin and
> fsl,mdc-pin.
Do you mean this:
Currently defined compatibles:
fsl,pq1-fec-mdio (reg is same as first resource of FEC device)
-> fsl,cpm2-mdio-bitbang (reg is port C registers)
Properties for fsl,cpm2-mdio-bitbang:
-> fsl,mdio-pin : pin of port C controlling mdio data
-> fsl,mdc-pin : pin of port C controlling mdio clock
Right. But i thought it would be related to the example,
and than the reader gets the short comment about I/O ports.
Or the other variant would be:
--------------------
iv) MDIO
Currently defined compatibles:
fsl,pq1-fec-mdio (reg is same as first resource of FEC device)
fsl,cpm2-mdio-bitbang (reg is the I/O port register block(s))
Properties for fsl,cpm2-mdio-bitbang:
The first reg resource is the I/O port register block on which MDIO
resides. The second reg resource is the I/O port register block on
which MDC resides. If there is only one reg resource, it is used for
both MDIO and MDC.
fsl,mdio-pin : pin of chosen port for controlling mdio data
fsl,mdc-pin : pin of chosen port for controlling mdio clock
Example:
mdio@10d40 {
device_type = "mdio";
compatible = "fsl,mpc8272ads-mdio-bitbang",
"fsl,mpc8272-mdio-bitbang",
"fsl,cpm2-mdio-bitbang";
reg = <10d40 14>;
#address-cells = <1>;
#size-cells = <0>;
fsl,mdio-pin = <12>;
fsl,mdc-pin = <13>;
};
-----------------
Regards
Sergej.
^ permalink raw reply
* Re: [RFC] dependencies for platform drivers (was Re: ax88796: add superh to kconfig dependencies)
From: Russell King @ 2007-11-09 12:02 UTC (permalink / raw)
To: Paul Mundt, Ralf Baechle, Al Viro, Magnus Damm, netdev, ben-linux
In-Reply-To: <20071109094023.GA7022@linux-sh.org>
On Fri, Nov 09, 2007 at 06:40:23PM +0900, Paul Mundt wrote:
> On Fri, Nov 09, 2007 at 09:26:52AM +0000, Ralf Baechle wrote:
> > If writesb() is not an official API then maybe the answer should have been
> > to either add that API to other architectures or fix the driver.
> >
> > I guess this incident means I need to go through all Kconfig* files to
> > see what bogus architecture dependencies on MIPS or !MIPS exist ...
> >
> While writesb() isn't an official API, the iowriteX_rep() interfaces
> theoretically are. Tidying up the driver for iomap is probably a better
> option.
writesb() predates iowriteX_rep() interfaces by quite a number of years,
though if you're using writesb(), converting over to iowriteX_rep() is
really a no-brainer.
writesb() is effectively what mmio_outsb() is, and exists to do what
outsb() does but for peripherals mapped using ioremap on ARM rather
than trying to emulate them via the legacy x86 IO interfaces.
Note that it would've been far better that whoever invented mmio_outsb()
looked around and noticed that some of us already have an implementation
called writesb()... but time has proven that folk seem to be blinkered
to anything not x86.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
^ permalink raw reply
* Re: [PATCH 1/5] fix send buffer check
From: Herbert Xu @ 2007-11-09 12:24 UTC (permalink / raw)
To: Hideo AOKI
Cc: David Miller, netdev, Satoshi Oshima, Andi Kleen,
Stephen Hemminger, Evgeniy Polyakov, yoshfuji, Yumiko Sugita
In-Reply-To: <47264F2D.3010105@redhat.com>
On Mon, Oct 29, 2007 at 05:22:53PM -0400, Hideo AOKI wrote:
> This patch introduces sndbuf size check before memory allocation for
> send buffer.
Looks good, what about IPv6?
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH 2/5] accounting unit and variable
From: Herbert Xu @ 2007-11-09 12:34 UTC (permalink / raw)
To: Hideo AOKI
Cc: David Miller, netdev, Satoshi Oshima, Andi Kleen,
Stephen Hemminger, Evgeniy Polyakov, yoshfuji, Yumiko Sugita
In-Reply-To: <47264F3E.3080306@redhat.com>
On Mon, Oct 29, 2007 at 05:23:10PM -0400, Hideo AOKI wrote:
>
> +#define SK_DATAGRAM_MEM_QUANTUM ((int)PAGE_SIZE)
> +
> +static inline int sk_datagram_pages(int amt)
> +{
> + return DIV_ROUND_UP(amt, SK_DATAGRAM_MEM_QUANTUM);
> +}
Does this really have to be int? Unsigned would let the compiler
optimise this to a simple shift.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [RFC] dependencies for platform drivers (was Re: ax88796: add superh to kconfig dependencies)
From: Ben Dooks @ 2007-11-09 12:08 UTC (permalink / raw)
To: Paul Mundt, Ralf Baechle, Al Viro, Magnus Damm, netdev, ben-linux
In-Reply-To: <20071109094023.GA7022@linux-sh.org>
On Fri, Nov 09, 2007 at 06:40:23PM +0900, Paul Mundt wrote:
> On Fri, Nov 09, 2007 at 09:26:52AM +0000, Ralf Baechle wrote:
> > If writesb() is not an official API then maybe the answer should have been
> > to either add that API to other architectures or fix the driver.
> >
> > I guess this incident means I need to go through all Kconfig* files to
> > see what bogus architecture dependencies on MIPS or !MIPS exist ...
> >
> While writesb() isn't an official API, the iowriteX_rep() interfaces
> theoretically are. Tidying up the driver for iomap is probably a better
> option.
If anyone else isn't interested in doing this, and there are
no objections to having it done, then I would be willing to
look at moving to the iowrite interfaces.
The only other way would be to add an 8/16bit configuration
to drop the use of writesb, as I belive most people connect
these devices in 16bit mode.
--
Ben (ben@fluff.org, http://www.fluff.org/)
'a smiley only costs 4 bytes'
^ permalink raw reply
* Re: [RFC] dependencies for platform drivers (was Re: ax88796: add superh to kconfig dependencies)
From: Ben Dooks @ 2007-11-09 12:06 UTC (permalink / raw)
To: Al Viro; +Cc: Magnus Damm, netdev, lethal, ben-linux, akpm, jeff, linux-arch
In-Reply-To: <20071108081854.GN8181@ftp.linux.org.uk>
On Thu, Nov 08, 2007 at 08:18:54AM +0000, Al Viro wrote:
> On Thu, Nov 08, 2007 at 04:31:05PM +0900, Magnus Damm wrote:
> > config AX88796
> > tristate "ASIX AX88796 NE2000 clone support"
> > - depends on ARM || MIPS
> > + depends on ARM || MIPS || SUPERH
>
> You know, that really sucks more and more. How about doing the following:
> a) making it depend on PLAT_HAS_AX88796
> b) adding selects for all subarchitectures that have the corresponding
> platform device
> and setting that as a uniform policy for platform drivers? For things like
> SM501 we would do
> config MFD_SM501
> depends on PCI || PLAT_HAS_SM501
> etc.
The PLAT_HAS_xxx method is nice, and I would like it applied to other places
in the kernel (see libata arugment below), and would have acked
this patch if it hadn't already been applied by Jeff.
The only reservation is that this doesn't show up the posibilty
of having the driver in the menuconfig, but anyone adding new
board support (should) be bright enough to look through the
Kconfig scripts before deciding they need to write an entirely
new driver.
I would note you may want to do PLAT_HAS_NET_AX88796 as there is
entirely a posibility of confusing this with the simple parallel
port driver which a board may not have support for.
> Seriously, folks, we are getting shitloads of platform drivers with no
> dependencies whatsoever, needed on a handful of targets and occasionally
> failing to build on unrelated architectures. Moreover, having a list
> of architectures in dependencies for each of those suckers is a PITA
> from the conflict POV. Not to mention platform drivers that fall into
> the mainline kernel with not a single platform device for them, etc.
There is a general problem with chicken-vs-egg here, how do you submit
support for a machine's platform device without the platform device
being there (and vice-versa) with seperate maintainers for network
and machine support?
One of my colleagues has passed along comments you made about a pair
of the simtec drivers (simtec-i2c and simtec-ide) which have been
added, but have no current users as patches have been stalled either
in submission process, or awaiting for an resolution. In the case
of simtec-ide, I would like to replace it with platform-ata, but
the libata maintainers seem wholy un-interested in
PLAT_HAS_PLATFORM_ATA or similar.
--
Ben (ben@fluff.org, http://www.fluff.org/)
'a smiley only costs 4 bytes'
^ permalink raw reply
* Re: [PATCH 3/5] memory accounting
From: Herbert Xu @ 2007-11-09 13:07 UTC (permalink / raw)
To: Hideo AOKI
Cc: David Miller, netdev, Satoshi Oshima, Andi Kleen,
Stephen Hemminger, Evgeniy Polyakov, yoshfuji, Yumiko Sugita
In-Reply-To: <47264F49.90308@redhat.com>
On Mon, Oct 29, 2007 at 05:23:21PM -0400, Hideo AOKI wrote:
> This patch adds UDP memory usage accounting in IPv4.
>
> --
> Hideo Aoki
> Hitachi Computer Products (America) Inc.
>
> Signed-off-by: Satoshi Oshima <satoshi.oshima.fk@hitachi.com>
> Signed-off-by: Hideo Aoki <haoki@redhat.com>
This looks fine for now. Although in future I'd prefer this
to use the forward alloc model used by stream sockets. In fact
we should be able to share most of that code too.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* [PATCH 1/4] Un-define the IPTUNNEL_XMIT() macro
From: Pavel Emelyanov @ 2007-11-09 13:09 UTC (permalink / raw)
To: David Miller; +Cc: Linux Netdev List, devel
This one is used in all the smth-to-ip tunnels we have and
looks ... not very good. Make this a regular function in the
tunnel4.ko module.
Signed-off-by: Pavel Emelyanov <xemul@openvz.org>
---
diff --git a/include/net/ipip.h b/include/net/ipip.h
index 7cdc914..bc8f4a1 100644
--- a/include/net/ipip.h
+++ b/include/net/ipip.h
@@ -25,23 +25,7 @@ struct ip_tunnel
struct ip_tunnel_parm parms;
};
-#define IPTUNNEL_XMIT() do { \
- int err; \
- int pkt_len = skb->len; \
- \
- skb->ip_summed = CHECKSUM_NONE; \
- iph->tot_len = htons(skb->len); \
- ip_select_ident(iph, &rt->u.dst, NULL); \
- ip_send_check(iph); \
- \
- err = NF_HOOK(PF_INET, NF_IP_LOCAL_OUT, skb, NULL, rt->u.dst.dev, dst_output);\
- if (net_xmit_eval(err) == 0) { \
- stats->tx_bytes += pkt_len; \
- stats->tx_packets++; \
- } else { \
- stats->tx_errors++; \
- stats->tx_aborted_errors++; \
- } \
-} while (0)
+void iptunnel_xmit(struct sk_buff *skb, struct rtable *rt,
+ struct net_device_stats *stats);
#endif
diff --git a/net/ipv4/ip_gre.c b/net/ipv4/ip_gre.c
index 02b02a8..4fc19b3 100644
--- a/net/ipv4/ip_gre.c
+++ b/net/ipv4/ip_gre.c
@@ -882,7 +882,7 @@ static int ipgre_tunnel_xmit(struct sk_buff *skb, struct net_device *dev)
nf_reset(skb);
- IPTUNNEL_XMIT();
+ iptunnel_xmit(skb, rt, stats);
tunnel->recursion--;
return 0;
diff --git a/net/ipv4/ipip.c b/net/ipv4/ipip.c
index 8c2b2b0..01f6d34 100644
--- a/net/ipv4/ipip.c
+++ b/net/ipv4/ipip.c
@@ -638,7 +638,7 @@ static int ipip_tunnel_xmit(struct sk_buff *skb, struct net_device *dev)
nf_reset(skb);
- IPTUNNEL_XMIT();
+ iptunnel_xmit(skb, rt, stats);
tunnel->recursion--;
return 0;
diff --git a/net/ipv4/tunnel4.c b/net/ipv4/tunnel4.c
index a794a8c..c71617c 100644
--- a/net/ipv4/tunnel4.c
+++ b/net/ipv4/tunnel4.c
@@ -8,6 +8,7 @@
#include <linux/mutex.h>
#include <linux/netdevice.h>
#include <linux/skbuff.h>
+#include <linux/netfilter_ipv4.h>
#include <net/icmp.h>
#include <net/ip.h>
#include <net/protocol.h>
@@ -71,6 +72,32 @@ int xfrm4_tunnel_deregister(struct xfrm_tunnel *handler, unsigned short family)
EXPORT_SYMBOL(xfrm4_tunnel_deregister);
+void iptunnel_xmit(struct sk_buff *skb, struct rtable *rt,
+ struct net_device_stats *stats)
+{
+ int err;
+ struct iphdr *iph = ip_hdr(skb);
+ int pkt_len = skb->len;
+
+ skb->ip_summed = CHECKSUM_NONE;
+ iph->tot_len = htons(skb->len);
+ ip_select_ident(iph, &rt->u.dst, NULL);
+ ip_send_check(iph);
+
+ err = NF_HOOK(PF_INET, NF_IP_LOCAL_OUT, skb, NULL,
+ rt->u.dst.dev, dst_output);
+
+ if (net_xmit_eval(err) == 0) {
+ stats->tx_bytes += pkt_len;
+ stats->tx_packets++;
+ } else {
+ stats->tx_errors++;
+ stats->tx_aborted_errors++;
+ }
+}
+
+EXPORT_SYMBOL(iptunnel_xmit);
+
static int tunnel4_rcv(struct sk_buff *skb)
{
struct xfrm_tunnel *handler;
diff --git a/net/ipv6/sit.c b/net/ipv6/sit.c
index 71433d2..49b30ca 100644
--- a/net/ipv6/sit.c
+++ b/net/ipv6/sit.c
@@ -579,7 +579,7 @@ static int ipip6_tunnel_xmit(struct sk_buff *skb, struct net_device *dev)
nf_reset(skb);
- IPTUNNEL_XMIT();
+ iptunnel_xmit(skb, rt, stats);
tunnel->recursion--;
return 0;
--
1.5.3.4
^ permalink raw reply related
* [PATCH 2/4] Add missed tunnel64_err handler
From: Pavel Emelyanov @ 2007-11-09 13:14 UTC (permalink / raw)
To: David Miller; +Cc: Linux Netdev List, devel
The tunnel64_protocol uses the tunnel4_protocol's err_handler and
thus calls the tunnel4_protocol's handlers.
This is not very good, as in case of (icmp) error the wrong error
handlers will be called (e.g. ipip ones instead of sit) and this
won't be noticed at all, because the error is not reported.
Was that made deliberately and I miss something?
Signed-off-by: Pavel Emelyanov <xemul@openvz.org>
---
diff --git a/net/ipv4/tunnel4.c b/net/ipv4/tunnel4.c
index c71617c..7938430 100644
--- a/net/ipv4/tunnel4.c
+++ b/net/ipv4/tunnel4.c
@@ -145,6 +145,17 @@ static void tunnel4_err(struct sk_buff *skb, u32 info)
break;
}
+#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE)
+static void tunnel64_err(struct sk_buff *skb, u32 info)
+{
+ struct xfrm_tunnel *handler;
+
+ for (handler = tunnel64_handlers; handler; handler = handler->next)
+ if (!handler->err_handler(skb, info))
+ break;
+}
+#endif
+
static struct net_protocol tunnel4_protocol = {
.handler = tunnel4_rcv,
.err_handler = tunnel4_err,
@@ -154,7 +165,7 @@ static struct net_protocol tunnel4_protocol = {
#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE)
static struct net_protocol tunnel64_protocol = {
.handler = tunnel64_rcv,
- .err_handler = tunnel4_err,
+ .err_handler = tunnel64_err,
.no_policy = 1,
};
#endif
--
1.5.3.4
^ permalink raw reply related
* [PATCH 3/4] Cleanup the xfrm4_tunnel_(un)register
From: Pavel Emelyanov @ 2007-11-09 13:16 UTC (permalink / raw)
To: David Miller; +Cc: Linux Netdev List, devel
Both check for the family to select an appropriate tunnel list.
Consolidate this check and make the for() loop more readable.
Signed-off-by: Pavel Emelyanov <xemul@openvz.org>
---
diff --git a/net/ipv4/tunnel4.c b/net/ipv4/tunnel4.c
index 7938430..b662a9e 100644
--- a/net/ipv4/tunnel4.c
+++ b/net/ipv4/tunnel4.c
@@ -18,6 +18,11 @@ static struct xfrm_tunnel *tunnel4_handlers;
static struct xfrm_tunnel *tunnel64_handlers;
static DEFINE_MUTEX(tunnel4_mutex);
+static inline struct xfrm_tunnel **fam_handlers(unsigned short family)
+{
+ return (family == AF_INET) ? &tunnel4_handlers : &tunnel64_handlers;
+}
+
int xfrm4_tunnel_register(struct xfrm_tunnel *handler, unsigned short family)
{
struct xfrm_tunnel **pprev;
@@ -26,8 +31,7 @@ int xfrm4_tunnel_register(struct xfrm_tunnel *handler, unsigned short family)
mutex_lock(&tunnel4_mutex);
- for (pprev = (family == AF_INET) ? &tunnel4_handlers : &tunnel64_handlers;
- *pprev; pprev = &(*pprev)->next) {
+ for (pprev = fam_handlers(family); *pprev; pprev = &(*pprev)->next) {
if ((*pprev)->priority > priority)
break;
if ((*pprev)->priority == priority)
@@ -54,8 +58,7 @@ int xfrm4_tunnel_deregister(struct xfrm_tunnel *handler, unsigned short family)
mutex_lock(&tunnel4_mutex);
- for (pprev = (family == AF_INET) ? &tunnel4_handlers : &tunnel64_handlers;
- *pprev; pprev = &(*pprev)->next) {
+ for (pprev = fam_handlers(family); *pprev; pprev = &(*pprev)->next) {
if (*pprev == handler) {
*pprev = handler->next;
ret = 0;
--
1.5.3.4
^ permalink raw reply related
* [PATCH 4/4] Consolidate equal handlers in tunnel4.c
From: Pavel Emelyanov @ 2007-11-09 13:18 UTC (permalink / raw)
To: David Miller; +Cc: Linux Netdev List, devel
Two sets - tunnel[6]4_rcv() and tunnel[6]4_err - do the same
thing, but scan for different lists of tunnels, so this code
is easily consolidated.
Signed-off-by: Pavel Emelyanov <xemul@openvz.ogr>
---
diff --git a/net/ipv4/tunnel4.c b/net/ipv4/tunnel4.c
index b662a9e..c85547d 100644
--- a/net/ipv4/tunnel4.c
+++ b/net/ipv4/tunnel4.c
@@ -101,14 +101,14 @@ void iptunnel_xmit(struct sk_buff *skb, struct rtable *rt,
EXPORT_SYMBOL(iptunnel_xmit);
-static int tunnel4_rcv(struct sk_buff *skb)
+static int tunnel_rcv(struct xfrm_tunnel *handlers, struct sk_buff *skb)
{
struct xfrm_tunnel *handler;
if (!pskb_may_pull(skb, sizeof(struct iphdr)))
goto drop;
- for (handler = tunnel4_handlers; handler; handler = handler->next)
+ for (handler = handlers; handler; handler = handler->next)
if (!handler->handler(skb))
return 0;
@@ -119,43 +119,36 @@ drop:
return 0;
}
+static int tunnel4_rcv(struct sk_buff *skb)
+{
+ return tunnel_rcv(tunnel4_handlers, skb);
+}
+
#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE)
static int tunnel64_rcv(struct sk_buff *skb)
{
- struct xfrm_tunnel *handler;
-
- if (!pskb_may_pull(skb, sizeof(struct iphdr)))
- goto drop;
-
- for (handler = tunnel64_handlers; handler; handler = handler->next)
- if (!handler->handler(skb))
- return 0;
-
- icmp_send(skb, ICMP_DEST_UNREACH, ICMP_PORT_UNREACH, 0);
-
-drop:
- kfree_skb(skb);
- return 0;
+ return tunnel_rcv(tunnel64_handlers, skb);
}
#endif
-static void tunnel4_err(struct sk_buff *skb, u32 info)
+static void tunnel_err(struct xfrm_tunnel *handlers, struct sk_buff *skb, u32 i)
{
struct xfrm_tunnel *handler;
- for (handler = tunnel4_handlers; handler; handler = handler->next)
- if (!handler->err_handler(skb, info))
+ for (handler = handlers; handler; handler = handler->next)
+ if (!handler->err_handler(skb, i))
break;
}
+static void tunnel4_err(struct sk_buff *skb, u32 info)
+{
+ tunnel_err(tunnel4_handlers, skb, info);
+}
+
#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE)
static void tunnel64_err(struct sk_buff *skb, u32 info)
{
- struct xfrm_tunnel *handler;
-
- for (handler = tunnel64_handlers; handler; handler = handler->next)
- if (!handler->err_handler(skb, info))
- break;
+ tunnel_err(tunnel64_handlers, skb, info);
}
#endif
--
1.5.3.4
^ permalink raw reply related
* Re: [PATCH 0/5] fixups for mpc8360 rev. 2.1 erratum #2 (RGMII Timing)
From: Anton Vorontsov @ 2007-11-09 13:25 UTC (permalink / raw)
To: Kim Phillips; +Cc: Li Yang, Kumar Gala, netdev, linuxppc-dev, paulus, jgarzik
In-Reply-To: <20071108131135.e16a2f9a.kim.phillips@freescale.com>
On Thu, Nov 08, 2007 at 01:11:35PM -0600, Kim Phillips wrote:
[...]
> right, but whether it does or not doesn't affect your failure outcome
> either I'm assuming.
>
> > > If it's something like 0x03, the u-boot patch will probably look like:
> > >
> > > if ((bcsr[12] == 0x10) &&
> > > (immr->sysconf.spridr == SPR_8360_REV21 ||
> > > immr->sysconf.spridr == SPR_8360E_REV21))
> > > /* if phy-connection-type is "rgmii-id", set it to "rgmii-rxid" */
> > > ...
> > >
> > > but these linux patches would remain the same (the clk and data delay
> > > settings for the UCC's are still valid; it's just the PHY config
> > > that is triggering your problem from what I can tell).
> >
> > Yup, most likely this is not UCC specific, but PHY. For some reason
> > delays making harm here...
And today I was unable to reproduce yesterday's behaviour. Your
patches works fine, with sixth patch and without it. With -rxid
and with just -id.
Though, after few resets I hit on that:
- - - -
U-Boot 1.3.0-rc3-g281df457-dirty (Nov 6 2007 - 18:19:35) MPC83XX
Reset Status: External/Internal Soft, External/Internal Hard
CPU: e300c1, MPC8360E, Rev: 21 at 528 MHz, CSB: 264 MHz
Board: Freescale MPC8360EMDS
I2C: ready
DRAM: 256 MB (DDR2, 64-bit, ECC on)
SDRAM: 64 MB (local bus)
FLASH: 32 MB
In: serial
Out: serial
Err: serial
Net: UEC: PHY is Marvell 88E11x1 (1410cc2)
FSL UEC0: Full Duplex
switching to rgmii 100
FSL UEC0: Speed 100BT
FSL UEC0: Link is up
read wrong value : mii_id 1,mii_reg 2, base e0103120
read wrong value : mii_id 1,mii_reg 3, base e0103120
UEC: PHY is Generic MII (ffffffff)
read wrong value : mii_id 1,mii_reg 1, base e0103120
read wrong value : mii_id 1,mii_reg 1, base e0103120
read wrong value : mii_id 1,mii_reg 5, base e0103120
FSL UEC1: Full Duplex
switching to rgmii 100
FSL UEC1: Speed 100BT
FSL UEC1: Link is up
FSL UEC0, FSL UEC1
- - - -
And UCC1 does not work at all. After another reset that message
disappears and it does work again.
So, I think hardware is tricking me in various ways, not your
patches fault.
:-(
--
Anton Vorontsov
email: cbou@mail.ru
backup email: ya-cbou@yandex.ru
irc://irc.freenode.net/bd2
^ permalink raw reply
* [PATCH] ehea: Add kdump support
From: Thomas Klein @ 2007-11-09 13:33 UTC (permalink / raw)
To: Jeff Garzik
Cc: Christoph Raisch, Jan-Bernd Themann, linux-kernel, linux-ppc,
Marcus Eder, netdev, Stefan Roscher, Michael Ellermann,
Michael Neuling, Paul Mackerras
To support ehea driver reloading in a kdump kernel the driver has to perform
firmware handle deregistrations when the original kernel crashes. As there's
currently no notifier chain for machine crashes this patch enables kdump support
in the ehea driver by bending the ppc_md.machine_crash_shutdown hook to its own
machine crash handler. The original machine_crash_shutdown() fn is called
afterwards. This works fine as long as the ehea driver is the only one which
does so. Problems may occur if other drivers do the same and unload regularly.
This patch enables 2.6.24-rc2 to use kdump with ehea and only puts a very
low risk on base kernel. In 2.6.24 we know ehea is the only user of this
mechanism. The next step for 2.6.25 would be to add a proper notifier chain.
The full solution might be that register_reboot_notifier() provides sth
like a SYS_CRASH action. Please apply.
Signed-off-by: Thomas Klein <tklein@de.ibm.com>
---
drivers/net/ehea/ehea.h | 2 +-
drivers/net/ehea/ehea_main.c | 28 ++++++++++++++++++++++++++++
2 files changed, 29 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ehea/ehea.h b/drivers/net/ehea/ehea.h
index f78e5bf..5935899 100644
--- a/drivers/net/ehea/ehea.h
+++ b/drivers/net/ehea/ehea.h
@@ -40,7 +40,7 @@
#include <asm/io.h>
#define DRV_NAME "ehea"
-#define DRV_VERSION "EHEA_0080"
+#define DRV_VERSION "EHEA_0081"
/* eHEA capability flags */
#define DLPAR_PORT_ADD_REM 1
diff --git a/drivers/net/ehea/ehea_main.c b/drivers/net/ehea/ehea_main.c
index f0319f1..40a732e 100644
--- a/drivers/net/ehea/ehea_main.c
+++ b/drivers/net/ehea/ehea_main.c
@@ -37,6 +37,7 @@
#include <linux/reboot.h>
#include <net/ip.h>
+#include <asm-powerpc/machdep.h>
#include "ehea.h"
#include "ehea_qmr.h"
@@ -98,6 +99,7 @@ static int port_name_cnt = 0;
static LIST_HEAD(adapter_list);
u64 ehea_driver_flags = 0;
struct work_struct ehea_rereg_mr_task;
+static void (*orig_machine_crash_shutdown)(struct pt_regs *regs);
struct semaphore dlpar_mem_lock;
@@ -3312,6 +3314,29 @@ static struct notifier_block ehea_reboot_nb = {
.notifier_call = ehea_reboot_notifier,
};
+void ehea_crash_notifier(struct pt_regs *regs)
+{
+ ehea_info("Machine crash: freeing all eHEA resources");
+ ibmebus_unregister_driver(&ehea_driver);
+ orig_machine_crash_shutdown(regs);
+}
+
+void ehea_register_crash_notifier(void)
+{
+#ifdef CONFIG_KEXEC
+ orig_machine_crash_shutdown =
+ (void*)__xchg_u64((unsigned long*)&ppc_md.machine_crash_shutdown,
+ (unsigned long)ehea_crash_notifier);
+#endif
+}
+
+void ehea_unregister_crash_notifier(void)
+{
+#ifdef CONFIG_KEXEC
+ ppc_md.machine_crash_shutdown = orig_machine_crash_shutdown;
+#endif
+}
+
static int check_module_parm(void)
{
int ret = 0;
@@ -3369,6 +3394,7 @@ int __init ehea_module_init(void)
goto out;
register_reboot_notifier(&ehea_reboot_nb);
+ ehea_register_crash_notifier();
ret = ibmebus_register_driver(&ehea_driver);
if (ret) {
@@ -3382,6 +3408,7 @@ int __init ehea_module_init(void)
ehea_error("failed to register capabilities attribute, ret=%d",
ret);
unregister_reboot_notifier(&ehea_reboot_nb);
+ ehea_unregister_crash_notifier();
ibmebus_unregister_driver(&ehea_driver);
goto out;
}
@@ -3396,6 +3423,7 @@ static void __exit ehea_module_exit(void)
driver_remove_file(&ehea_driver.driver, &driver_attr_capabilities);
ibmebus_unregister_driver(&ehea_driver);
unregister_reboot_notifier(&ehea_reboot_nb);
+ ehea_unregister_crash_notifier();
ehea_destroy_busmap();
}
--
1.5.2
^ permalink raw reply related
* Re: [PATCH 0/5] fixups for mpc8360 rev. 2.1 erratum #2 (RGMII Timing)
From: Anton Vorontsov @ 2007-11-09 13:33 UTC (permalink / raw)
To: Kim Phillips; +Cc: Li Yang, Kumar Gala, netdev, linuxppc-dev, paulus, jgarzik
In-Reply-To: <20071105121530.5c38fbb7.kim.phillips@freescale.com>
On Mon, Nov 05, 2007 at 12:15:30PM -0600, Kim Phillips wrote:
> Hello all,
>
> the following patches fix RGMII timing for rev. 2.1 of the mpc8360,
> according to erratum #2 (erratum text included below). Basically the
> most intrusive part is the addition of two new RGMII Internal Delay
> modes; one for TX delay only, and the other for RX delay only (i.e, not
> both at the same time).
>
> Please review, and since this affects both netdev and powerpc trees,
> one maintainer should ack them for the other to push upstream (i.e,
> Kumar acks them, and Leo picks them up to go through netdev or the
> other way around; either way is fine with me). I'm hoping they're
> trivial enough to go in 2.6.24.
All five patches are
Tested-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Let's hope they'll hit 2.6.24.
Thanks,
--
Anton Vorontsov
email: cbou@mail.ru
backup email: ya-cbou@yandex.ru
irc://irc.freenode.net/bd2
^ permalink raw reply
* [PATCH][PACKET] Use existing sock refcnt debugging infrastructure
From: Pavel Emelyanov @ 2007-11-09 13:39 UTC (permalink / raw)
To: David Miller; +Cc: Arnaldo Carvalho de Melo, Linux Netdev List, devel
The packet_socks_nr variable is used purely for debugging
the number of sockets.
As Arnaldo pointed out, there's already an infrastructure
for this purposes, so switch to using it.
Signed-off-by: Pavel Emelyanov <xemul@openvz.org>
---
diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
index 4cb2dfb..36331a5 100644
--- a/net/packet/af_packet.c
+++ b/net/packet/af_packet.c
@@ -139,9 +139,6 @@ dev->hard_header == NULL (ll header is added by device, we cannot control it)
static HLIST_HEAD(packet_sklist);
static DEFINE_RWLOCK(packet_sklist_lock);
-static atomic_t packet_socks_nr;
-
-
/* Private packet socket structures. */
struct packet_mclist
@@ -236,10 +233,7 @@ static void packet_sock_destruct(struct sock *sk)
return;
}
- atomic_dec(&packet_socks_nr);
-#ifdef PACKET_REFCNT_DEBUG
- printk(KERN_DEBUG "PACKET socket %p is free, %d are alive\n", sk, atomic_read(&packet_socks_nr));
-#endif
+ sk_refcnt_debug_dec(sk);
}
@@ -849,6 +843,7 @@ static int packet_release(struct socket *sock)
/* Purge queues */
skb_queue_purge(&sk->sk_receive_queue);
+ sk_refcnt_debug_release(sk);
sock_put(sk);
return 0;
@@ -1010,7 +1005,7 @@ static int packet_create(struct net *net, struct socket *sock, int protocol)
po->num = proto;
sk->sk_destruct = packet_sock_destruct;
- atomic_inc(&packet_socks_nr);
+ sk_refcnt_debug_inc(sk);
/*
* Attach a protocol block
--
1.5.3.4
^ permalink raw reply related
* [PATCH][IPX] Use existing sock refcnt debugging infrastructure
From: Pavel Emelyanov @ 2007-11-09 13:42 UTC (permalink / raw)
To: David Miller; +Cc: Arnaldo Carvalho de Melo, Linux Netdev List, devel
Just like in the af_packet.c, the ipx_sock_nr variable is used
for debugging purposes.
Switch to using existing infrastructure. Thanks to Arnaldo for
pointing this out.
Signed-off-by: Pavel Emelyanov <xemul@openvz.org>
---
diff --git a/net/ipx/af_ipx.c b/net/ipx/af_ipx.c
index a195a66..c76a952 100644
--- a/net/ipx/af_ipx.c
+++ b/net/ipx/af_ipx.c
@@ -92,11 +92,6 @@ extern int ipxrtr_route_skb(struct sk_buff *skb);
extern struct ipx_route *ipxrtr_lookup(__be32 net);
extern int ipxrtr_ioctl(unsigned int cmd, void __user *arg);
-#undef IPX_REFCNT_DEBUG
-#ifdef IPX_REFCNT_DEBUG
-atomic_t ipx_sock_nr;
-#endif
-
struct ipx_interface *ipx_interfaces_head(void)
{
struct ipx_interface *rc = NULL;
@@ -151,14 +146,7 @@ static void ipx_destroy_socket(struct sock *sk)
{
ipx_remove_socket(sk);
skb_queue_purge(&sk->sk_receive_queue);
-#ifdef IPX_REFCNT_DEBUG
- atomic_dec(&ipx_sock_nr);
- printk(KERN_DEBUG "IPX socket %p released, %d are still alive\n", sk,
- atomic_read(&ipx_sock_nr));
- if (atomic_read(&sk->sk_refcnt) != 1)
- printk(KERN_DEBUG "Destruction sock ipx %p delayed, cnt=%d\n",
- sk, atomic_read(&sk->sk_refcnt));
-#endif
+ sk_refcnt_debug_dec(sk);
sock_put(sk);
}
@@ -1384,11 +1372,8 @@ static int ipx_create(struct net *net, struct socket *sock, int protocol)
sk = sk_alloc(net, PF_IPX, GFP_KERNEL, &ipx_proto);
if (!sk)
goto out;
-#ifdef IPX_REFCNT_DEBUG
- atomic_inc(&ipx_sock_nr);
- printk(KERN_DEBUG "IPX socket %p created, now we have %d alive\n", sk,
- atomic_read(&ipx_sock_nr));
-#endif
+
+ sk_refcnt_debug_inc(sk);
sock_init_data(sock, sk);
sk->sk_no_check = 1; /* Checksum off by default */
sock->ops = &ipx_dgram_ops;
@@ -1409,6 +1394,7 @@ static int ipx_release(struct socket *sock)
sock_set_flag(sk, SOCK_DEAD);
sock->sk = NULL;
+ sk_refcnt_debug_release(sk);
ipx_destroy_socket(sk);
out:
return 0;
--
1.5.3.4
^ permalink raw reply related
* Re: [PATCH] Fix buglets in mpc5200 FEC code that are corrupting memory.
From: Grant Likely @ 2007-11-09 13:57 UTC (permalink / raw)
To: Domen Puncer, Jeff Garzik; +Cc: Jon Smirl, PowerPC dev list, netdev
In-Reply-To: <20071109091245.GA3148@nd47.coderock.org>
On 11/9/07, Domen Puncer <domen.puncer@telargo.com> wrote:
> On 09/11/07 00:31 -0500, Jon Smirl wrote:
> > This is the reason I couldn't get user space started or connect to my
> > nfs server. Patch is against current linus git.
> >
> > mpc5200 fec driver is corrupting memory. This patch fixes two bugs
> > where the wrong skb buffer was being referenced.
> >
> > Signed-off-by: Jon Smirl <jonsmirl@gmail.com>
>
> Acked-by: Domen Puncer <domen.puncer@telargo.com>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
Jeff, can you please pick this up for .24?
Thanks,
g.
>
> I can't test it at the moment, but the patch is obviously correct,
> mapped buffer should be the _same_ as submitted.
>
> >
> > ---
> >
> > drivers/net/fec_mpc52xx.c | 4 ++--
> > 1 files changed, 2 insertions(+), 2 deletions(-)
> >
> >
> > diff --git a/drivers/net/fec_mpc52xx.c b/drivers/net/fec_mpc52xx.c
> > index a8a0ee2..ddfcc0b 100644
> > --- a/drivers/net/fec_mpc52xx.c
> > +++ b/drivers/net/fec_mpc52xx.c
> > @@ -422,7 +422,7 @@ static irqreturn_t mpc52xx_fec_rx_interrupt(int
> > irq, void *dev_id)
> >
> > rskb = bcom_retrieve_buffer(priv->rx_dmatsk, &status,
> > (struct bcom_bd **)&bd);
> > - dma_unmap_single(&dev->dev, bd->skb_pa, skb->len, DMA_FROM_DEVICE);
> > + dma_unmap_single(&dev->dev, bd->skb_pa, rskb->len, DMA_FROM_DEVICE);
> >
> > /* Test for errors in received frame */
> > if (status & BCOM_FEC_RX_BD_ERRORS) {
> > @@ -467,7 +467,7 @@ static irqreturn_t mpc52xx_fec_rx_interrupt(int
> > irq, void *dev_id)
> > bcom_prepare_next_buffer(priv->rx_dmatsk);
> >
> > bd->status = FEC_RX_BUFFER_SIZE;
> > - bd->skb_pa = dma_map_single(&dev->dev, rskb->data,
> > + bd->skb_pa = dma_map_single(&dev->dev, skb->data,
> > FEC_RX_BUFFER_SIZE, DMA_FROM_DEVICE);
> >
> > bcom_submit_next_buffer(priv->rx_dmatsk, skb);
> >
> >
> > --
> > Jon Smirl
> > jonsmirl@gmail.com
>
> --
> Domen Puncer | Research & Development
> .............................................................................................
> Telargo d.o.o. | Zagrebška cesta 20 | 2000 Maribor | Slovenia
> .............................................................................................
> www.telargo.com
>
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [PATCH][PACKET] Use existing sock refcnt debugging infrastructure
From: Arnaldo Carvalho de Melo @ 2007-11-09 14:37 UTC (permalink / raw)
To: Pavel Emelyanov
Cc: David Miller, Arnaldo Carvalho de Melo, Linux Netdev List, devel
In-Reply-To: <4734631D.6080807@openvz.org>
Em Fri, Nov 09, 2007 at 04:39:41PM +0300, Pavel Emelyanov escreveu:
> The packet_socks_nr variable is used purely for debugging
> the number of sockets.
>
> As Arnaldo pointed out, there's already an infrastructure
> for this purposes, so switch to using it.
>
> Signed-off-by: Pavel Emelyanov <xemul@openvz.org>
Acked-by: Arnaldo Carvalho de Melo <acme@redhat.com>
> ---
>
> diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
> index 4cb2dfb..36331a5 100644
> --- a/net/packet/af_packet.c
> +++ b/net/packet/af_packet.c
> @@ -139,9 +139,6 @@ dev->hard_header == NULL (ll header is added by device, we cannot control it)
> static HLIST_HEAD(packet_sklist);
> static DEFINE_RWLOCK(packet_sklist_lock);
>
> -static atomic_t packet_socks_nr;
> -
> -
> /* Private packet socket structures. */
>
> struct packet_mclist
> @@ -236,10 +233,7 @@ static void packet_sock_destruct(struct sock *sk)
> return;
> }
>
> - atomic_dec(&packet_socks_nr);
> -#ifdef PACKET_REFCNT_DEBUG
> - printk(KERN_DEBUG "PACKET socket %p is free, %d are alive\n", sk, atomic_read(&packet_socks_nr));
> -#endif
> + sk_refcnt_debug_dec(sk);
> }
>
>
> @@ -849,6 +843,7 @@ static int packet_release(struct socket *sock)
> /* Purge queues */
>
> skb_queue_purge(&sk->sk_receive_queue);
> + sk_refcnt_debug_release(sk);
>
> sock_put(sk);
> return 0;
> @@ -1010,7 +1005,7 @@ static int packet_create(struct net *net, struct socket *sock, int protocol)
> po->num = proto;
>
> sk->sk_destruct = packet_sock_destruct;
> - atomic_inc(&packet_socks_nr);
> + sk_refcnt_debug_inc(sk);
>
> /*
> * Attach a protocol block
> --
> 1.5.3.4
>
> -
> 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][IPX] Use existing sock refcnt debugging infrastructure
From: Arnaldo Carvalho de Melo @ 2007-11-09 14:39 UTC (permalink / raw)
To: Pavel Emelyanov
Cc: David Miller, Arnaldo Carvalho de Melo, Linux Netdev List, devel
In-Reply-To: <473463AD.9000807@openvz.org>
Em Fri, Nov 09, 2007 at 04:42:05PM +0300, Pavel Emelyanov escreveu:
> Just like in the af_packet.c, the ipx_sock_nr variable is used
> for debugging purposes.
>
> Switch to using existing infrastructure. Thanks to Arnaldo for
> pointing this out.
>
> Signed-off-by: Pavel Emelyanov <xemul@openvz.org>
Acked-by: Arnaldo Carvalho de Melo <acme@redhat.com>
^ permalink raw reply
* [RFC][PATCH][LLC] Use existing sock refcnt debugging
From: Pavel Emelyanov @ 2007-11-09 14:43 UTC (permalink / raw)
To: Arnaldo Carvalho de Melo; +Cc: Linux Netdev List, devel
Hi, Arnaldo.
I've grep-ed through the code and found one more place, where
the sk refcnt debugging is required, but is still performed in
an old fashion - this is the LLC2.
The problem in using the sk_refcnt_debug_xxx here is that these
socks do not provide the sk_destruct callback to catch the
moment of the sock destruction.
Making this callback mandatory is not a good solution, as most
often it will be empty and thus useless. Making this callback
be set under the #ifdef SOCK_REFCNT_DEBUG is even more ugly
than the previous one.
So, I propose to extend the sk_refcnt_debug_xxx set of helperf
for those socks not having the sk_destruct callback by default,
like the LLC2 ones.
The new helper is sk_refcnt_debug_inc_undo(sk) sets the
sk_destruct callback into the sk_refcnt_debug_dec() in case the
SOCK_REFCNT_DEBUG is on.
What do you think about it?
Signed-off-by: Pavel Emelyanov <xemul@openvz.org>
---
diff --git a/include/net/sock.h b/include/net/sock.h
index 5504fb9..1404ab9 100644
--- a/include/net/sock.h
+++ b/include/net/sock.h
@@ -654,10 +654,21 @@ static inline void sk_refcnt_debug_release(const struct sock *sk)
printk(KERN_DEBUG "Destruction of the %s socket %p delayed, refcnt=%d\n",
sk->sk_prot->name, sk, atomic_read(&sk->sk_refcnt));
}
+
+/*
+ * this one is to be used *only* for thouse socks, that
+ * do not have their own sk_destruct callback
+ */
+static inline void sk_refcnt_debug_inc_undo(struct sock *sk)
+{
+ sk_refcnt_debug_inc(sk);
+ sk->sk_destruct = sk_refcnt_debug_dec;
+}
#else /* SOCK_REFCNT_DEBUG */
#define sk_refcnt_debug_inc(sk) do { } while (0)
#define sk_refcnt_debug_dec(sk) do { } while (0)
#define sk_refcnt_debug_release(sk) do { } while (0)
+#define sk_refcnt_debug_inc_undo(sk) do { } while (0)
#endif /* SOCK_REFCNT_DEBUG */
/* Called with local bh disabled */
diff --git a/net/llc/llc_conn.c b/net/llc/llc_conn.c
index 5c0b484..6ee8778 100644
--- a/net/llc/llc_conn.c
+++ b/net/llc/llc_conn.c
@@ -775,11 +775,6 @@ drop_unlock:
goto out;
}
-#undef LLC_REFCNT_DEBUG
-#ifdef LLC_REFCNT_DEBUG
-static atomic_t llc_sock_nr;
-#endif
-
/**
* llc_backlog_rcv - Processes rx frames and expired timers.
* @sk: LLC sock (p8022 connection)
@@ -875,11 +870,7 @@ struct sock *llc_sk_alloc(struct net *net, int family, gfp_t priority, struct pr
goto out;
llc_sk_init(sk);
sock_init_data(NULL, sk);
-#ifdef LLC_REFCNT_DEBUG
- atomic_inc(&llc_sock_nr);
- printk(KERN_DEBUG "LLC socket %p created in %s, now we have %d alive\n", sk,
- __FUNCTION__, atomic_read(&llc_sock_nr));
-#endif
+ sk_refcnt_debug_inc_undo(sk);
out:
return sk;
}
@@ -905,18 +896,7 @@ void llc_sk_free(struct sock *sk)
skb_queue_purge(&sk->sk_receive_queue);
skb_queue_purge(&sk->sk_write_queue);
skb_queue_purge(&llc->pdu_unack_q);
-#ifdef LLC_REFCNT_DEBUG
- if (atomic_read(&sk->sk_refcnt) != 1) {
- printk(KERN_DEBUG "Destruction of LLC sock %p delayed in %s, cnt=%d\n",
- sk, __FUNCTION__, atomic_read(&sk->sk_refcnt));
- printk(KERN_DEBUG "%d LLC sockets are still alive\n",
- atomic_read(&llc_sock_nr));
- } else {
- atomic_dec(&llc_sock_nr);
- printk(KERN_DEBUG "LLC socket %p released in %s, %d are still alive\n", sk,
- __FUNCTION__, atomic_read(&llc_sock_nr));
- }
-#endif
+ sk_refcnt_debug_release(sk);
sock_put(sk);
}
^ permalink raw reply related
* [PATCH] Fix infinite loop on dev_mc_unsync()
From: Luis R. Rodriguez @ 2007-11-09 15:11 UTC (permalink / raw)
To: netdev-u79uwXL29TY76Z2rM5mHXA
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA, Jeff Garzik
While reviewing net/core/dev_mcast.c I found what I think is an
infinite loop on dev_mc_unsync(). This fixes it. We make use of
this guy on mac80211 in ieee80211_stop(). This is untested.
Signed-off-by: Luis R. Rodriguez <mcgrof-NvJAj8134tRxEa0u/P/EHDe48wsgrGvP@public.gmane.org>
diff --git a/net/core/dev_mcast.c b/net/core/dev_mcast.c
index 15241cf..5373c03 100644
--- a/net/core/dev_mcast.c
+++ b/net/core/dev_mcast.c
@@ -168,8 +168,10 @@ void dev_mc_unsync(struct net_device *to, struct net_device *from)
da = from->mc_list;
while (da != NULL) {
next = da->next;
- if (!da->da_synced)
+ if (!da->da_synced) {
+ da = next;
continue;
+ }
__dev_addr_delete(&to->mc_list, &to->mc_count,
da->da_addr, da->da_addrlen, 0);
da->da_synced = 0;
^ permalink raw reply related
* [PATCH 2.6.24] RDMA/cxgb3: Set the max_qp_init_rd_atom attribute.
From: Steve Wise @ 2007-11-09 15:21 UTC (permalink / raw)
To: rdreier; +Cc: netdev, general
RDMA/cxgb3: Set the max_qp_init_rd_atom attribute.
Attribute max_qp_init_rd_atom is not getting set. Version 1.0.4 of
librdmacm now validates the user's requested initiator and responder
resources vs the max supported by the device. Since iw_cxgb3 wasn't
setting this attribute (and it defaulted to 0), all rdma_connect()s fail
if there are initiator resources requested by the app.
Signed-off-by: Steve Wise <swise@opengridcomputing.com>
---
drivers/infiniband/hw/cxgb3/iwch_provider.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/infiniband/hw/cxgb3/iwch_provider.c b/drivers/infiniband/hw/cxgb3/iwch_provider.c
index f0c7775..b5436ca 100644
--- a/drivers/infiniband/hw/cxgb3/iwch_provider.c
+++ b/drivers/infiniband/hw/cxgb3/iwch_provider.c
@@ -1000,6 +1000,7 @@ static int iwch_query_device(struct ib_device *ibdev,
props->max_sge = dev->attr.max_sge_per_wr;
props->max_sge_rd = 1;
props->max_qp_rd_atom = dev->attr.max_rdma_reads_per_qp;
+ props->max_qp_init_rd_atom = dev->attr.max_rdma_reads_per_qp;
props->max_cq = dev->attr.max_cqs;
props->max_cqe = dev->attr.max_cqes_per_cq;
props->max_mr = dev->attr.max_mem_regs;
^ 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