* Re: [PATCH 1/2 -next] of_device.h: provide struct of_device even when not enabled
From: Grant Likely @ 2010-06-09 23:47 UTC (permalink / raw)
To: Randy Dunlap; +Cc: David Miller, sfr, netdev, linux-next, linux-kernel
In-Reply-To: <20100609154405.20095178.randy.dunlap@oracle.com>
On Wed, Jun 9, 2010 at 4:44 PM, Randy Dunlap <randy.dunlap@oracle.com> wrote:
> From: Randy Dunlap <randy.dunlap@oracle.com>
>
> Drivers may use struct of_device (struct platform_device), even when
> CONFIG_OF_DEVICE is not enabled, so minimally provide that struct
> for that kconfig case.
>
> Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
> Cc: Grant Likely <grant.likely@secretlab.ca>
> Cc: Dave Miller <davem@davemloft.net>
> ---
> include/linux/of_device.h | 4 ++++
> 1 file changed, 4 insertions(+)
>
> --- linux-next-20100609.orig/include/linux/of_device.h
> +++ linux-next-20100609/include/linux/of_device.h
> @@ -47,6 +47,10 @@ extern ssize_t of_device_get_modalias(st
>
> extern int of_device_uevent(struct device *dev, struct kobj_uevent_env *env);
>
> +#else
> +
> +#include <linux/platform_device.h>
> +#define of_device platform_device
I should probably just move these 2 lines out of the #if/else/endif
block entirely. I'll make that change and test it out.
g.
^ permalink raw reply
* Re: [PATCH 2/2 -next] niu: always include of_device.h
From: David Miller @ 2010-06-10 0:29 UTC (permalink / raw)
To: grant.likely; +Cc: randy.dunlap, sfr, netdev, linux-next, linux-kernel
In-Reply-To: <AANLkTikuIgeSMC5_IzAQGEQRso4udBvBGPcioAiArWb5@mail.gmail.com>
From: Grant Likely <grant.likely@secretlab.ca>
Date: Wed, 9 Jun 2010 17:45:54 -0600
> On Wed, Jun 9, 2010 at 4:44 PM, Randy Dunlap <randy.dunlap@oracle.com> wrote:
>> From: Randy Dunlap <randy.dunlap@oracle.com>
>>
>> The niu driver uses struct of_device when built on any arch, not
>> only SPARC64, so always #include <linux/of_device.h>.
>>
>> drivers/net/niu.c:9700: warning: 'struct of_device' declared inside parameter list
>> drivers/net/niu.c:9700: warning: its scope is only this definition or declaration, which is probably not what you want
>> drivers/net/niu.c:9716: warning: assignment from incompatible pointer type
>>
>> Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
>> Cc: Grant Likely <grant.likely@secretlab.ca>
>> Cc: Dave Miller <davem@davemloft.net>
>> ---
>> drivers/net/niu.c | 3 ---
>
> Looks okay to me (but I haven't build tested it yet). The bulk of
> of_device.h is compiled out when CONFIG_OF_DEVICE is not selected.
>
> David, are you okay with me taking this via my tree as it depends on
> Randy's other patch?
Yep, that's totally fine with me:
Acked-by: David S. Miller <davem@davemloft.net>
^ permalink raw reply
* Re: [PATCH] r8169: fix mdio_read and update mdio_write according to hw specs
From: David Miller @ 2010-06-10 0:32 UTC (permalink / raw)
To: romieu; +Cc: timo.teras, netdev, hayeswang
In-Reply-To: <20100609061825.GA7087@electric-eye.fr.zoreil.com>
From: Francois Romieu <romieu@fr.zoreil.com>
Date: Wed, 9 Jun 2010 08:18:25 +0200
> Timo Teräs <timo.teras@iki.fi> :
>> Realtek confirmed that a 20us delay is needed after mdio_read and
>> mdio_write operations. Reduce the delay in mdio_write, and add it
>> to mdio_read too. Also add a comment that the 20us is from hw specs.
>>
>> Signed-off-by: Timo Teräs <timo.teras@iki.fi>
>
> Acked-off-by: Francois Romieu <romieu@fr.zoreil.com>
I think you meant "Acked-by: " :-) I fixed this and committed
Timo's patch, thanks everyone!
^ permalink raw reply
* [PATCH] tc: revert "echo" in install target
From: Mike Frysinger @ 2010-06-10 0:52 UTC (permalink / raw)
To: stephen.hemminger, netdev; +Cc: Andreas Henriksson
The recent commit "iproute2: add option to build m_xt as a tc module"
(ab814d635529787) looks like it wrongly included debug changes in the
install target. So drop the `echo` so the tc binary actually gets
installed again.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
---
tc/Makefile | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/tc/Makefile b/tc/Makefile
index 01a16fc..3aa9f26 100644
--- a/tc/Makefile
+++ b/tc/Makefile
@@ -99,10 +99,10 @@ libtc.a: $(TCLIB)
$(AR) rcs $@ $(TCLIB)
install: all
- echo mkdir -p $(MODDESTDIR)
- echo install -m 0755 tc $(DESTDIR)$(SBINDIR)
+ mkdir -p $(MODDESTDIR)
+ install -m 0755 tc $(DESTDIR)$(SBINDIR)
for i in $(TCSO); \
- do echo install -m 755 $$i $(MODDESTDIR); \
+ do install -m 755 $$i $(MODDESTDIR); \
done
if [ ! -f $(MODDESTDIR)/m_ipt.so ]; then \
if [ -f $(MODDESTDIR)/m_xt.so ]; \
--
1.7.1
^ permalink raw reply related
* [PATCH] netem: fix installs of dist files
From: Mike Frysinger @ 2010-06-10 0:52 UTC (permalink / raw)
To: stephen.hemminger, netdev
The tc program searches LIBDIR by default for the .dist files, and that
defaults to /usr/lib. But the netem subdir has /lib/ hardcoded which
means the default build+install results in the files not being found.
Further, these are plain text files which are read at runtime, so it
doesn't make sense to give them executable bits.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
---
netem/Makefile | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/netem/Makefile b/netem/Makefile
index b6ccfc6..e52e125 100644
--- a/netem/Makefile
+++ b/netem/Makefile
@@ -20,9 +20,9 @@ stats: stats.c
$(HOSTCC) $(CCOPTS) -I../include -o $@ $@.c -lm
install: all
- mkdir -p $(DESTDIR)/lib/tc
+ mkdir -p $(DESTDIR)$(LIBDIR)/tc
for i in $(DISTDATA); \
- do install -m 755 $$i $(DESTDIR)/lib/tc; \
+ do install -m 644 $$i $(DESTDIR)$(LIBDIR)/tc; \
done
clean:
--
1.7.1
^ permalink raw reply related
* [PATCH] dnet: fix strict aliasing warnings
From: Mike Frysinger @ 2010-06-10 0:52 UTC (permalink / raw)
To: stephen.hemminger, netdev
Recent gcc doesn't like it when you cast char pointers to uint16_t
pointers and then dereference it. So use memcpy() instead and let
gcc take care of optimizing things away (when appropriate). This
should also fix alignment issues on arches where gcc packs the char
pointer tighter than 16bits.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
---
lib/dnet_ntop.c | 8 ++++++--
lib/dnet_pton.c | 5 ++++-
2 files changed, 10 insertions(+), 3 deletions(-)
diff --git a/lib/dnet_ntop.c b/lib/dnet_ntop.c
index 9500df8..507a7eb 100644
--- a/lib/dnet_ntop.c
+++ b/lib/dnet_ntop.c
@@ -1,4 +1,5 @@
#include <errno.h>
+#include <string.h>
#include <sys/types.h>
#include <netinet/in.h>
@@ -35,11 +36,14 @@ static __inline__ int do_digit(char *str, u_int16_t *addr, u_int16_t scale, size
static const char *dnet_ntop1(const struct dn_naddr *dna, char *str, size_t len)
{
- u_int16_t addr = dn_ntohs(*(u_int16_t *)dna->a_addr);
- u_int16_t area = addr >> 10;
+ u_int16_t addr, area;
size_t pos = 0;
int started = 0;
+ memcpy(&addr, dna->a_addr, sizeof(addr));
+ addr = dn_ntohs(addr);
+ area = addr >> 10;
+
if (dna->a_len != 2)
return NULL;
diff --git a/lib/dnet_pton.c b/lib/dnet_pton.c
index bd7727a..7385756 100644
--- a/lib/dnet_pton.c
+++ b/lib/dnet_pton.c
@@ -1,4 +1,5 @@
#include <errno.h>
+#include <string.h>
#include <sys/types.h>
#include <netinet/in.h>
@@ -37,6 +38,7 @@ static int dnet_num(const char *src, u_int16_t * dst)
static int dnet_pton1(const char *src, struct dn_naddr *dna)
{
+ u_int16_t addr;
u_int16_t area = 0;
u_int16_t node = 0;
int pos;
@@ -48,7 +50,8 @@ static int dnet_pton1(const char *src, struct dn_naddr *dna)
if ((pos == 0) || (node > 1023))
return 0;
dna->a_len = 2;
- *(u_int16_t *)dna->a_addr = dn_htons((area << 10) | node);
+ addr = dn_htons((area << 10) | node);
+ memcpy(dna->a_addr, &addr, sizeof(addr));
return 1;
}
--
1.7.1
^ permalink raw reply related
* Re: [PATCH 2/2] [PATCH] ucc_geth: fix for RX skb buffers recycling
From: David Miller @ 2010-06-10 1:02 UTC (permalink / raw)
To: geomatsi; +Cc: netdev, leoli, avorontsov
In-Reply-To: <1275935894-30483-2-git-send-email-geomatsi@gmail.com>
From: Sergey Matyukevich <geomatsi@gmail.com>
Date: Mon, 7 Jun 2010 22:38:14 +0400
> This patch implements a proper recycling of skb buffers belonging to RX error
> path. The suggested fix actually follows the recycling scheme implemented for
> TX skb buffers in the same driver (see 'ucc_geth_tx' function): skb buffers
> are checked by 'skb_recycle_check' function and deleted if can't be recycled.
>
> This problem in recycling of skb buffers was discovered by accident in a setup
> when ethernet interface on one link end was full-duplex while another was
> half-duplex. In this case numerous corrupted frames were received by
> full-duplex interface due to late collisions. RX skb buffers with error
> frames were not properly recycled, that is why overflow occured from time to
> time on the next use of those buffers. Here is example of crush dump:
The lack of skb_recycle_check() is not the true cause of this bug.
You should never, ever, need to make skb_recycle_check() tests on
packets in this situation. Once the skb pointers are properly adjusted
it will have sufficient room.
And that points to what the real problem is, the problem is the
skb->data assignment. It's trying to get the SKB data pointers back
into the same state they are in when dev_alloc_skb() returns a packet
buffer.
But this assignment isn't accomplishing that, in fact it's corrupting
the SKB because after adjusting skb->data, skb->tail and skb->len will
become incorrect. And this is what you need to fix.
That's why you get the skb_put() over panics, not because you lack
a skb_recycle_check() call here.
In fact, what your patch makes happen is that the error packets will
never get recycled. The skb_recycle_check() will always fail.
Please fix this bug properly by correctly restoring the SKB pointers
and lengths to their initial state, then you can retain the
unconditional queueing of the error packet onto the recycle list.
Once you do that, all of the checks done by skb_recycle_check() are
superfluous and will always pass, and we know this. The buffer is
not fragmented, there aren't any clones or external references to it,
and once you fix up the data pointers properly it will have enough
room as necessary for the RX buffer size the driver is currently using.
There are numerous helper routines in linux/skbuff.h that can be used
to do this properly, which will adjust a pointer and make the
corresponding adjustment to skb->len as well when necessary.
^ permalink raw reply
* Re: [PATCH net-next-2.6] [PPPOE] cleanup: remove pppoe_xmit() declaration.
From: David Miller @ 2010-06-10 1:07 UTC (permalink / raw)
To: ramirose; +Cc: netdev
In-Reply-To: <AANLkTim_Jg51_xyfeLD3m4i88TGv8B2SRHFZ-H31w1YK@mail.gmail.com>
From: Rami Rosen <ramirose@gmail.com>
Date: Wed, 9 Jun 2010 08:07:56 +0300
> Signed-off-by: Rami Rosen <ramirose@gmail.com>
Applied, thanks Rami.
^ permalink raw reply
* Re: [PATCH net-next-2.6] ipv6: mcast: RCU conversions
From: David Miller @ 2010-06-10 1:07 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, yoshfuji
In-Reply-To: <1275980702.2775.193.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Tue, 08 Jun 2010 09:05:02 +0200
> - ipv6_sock_mc_join() : doesnt touch dev refcount
>
> - ipv6_sock_mc_drop() : doesnt touch dev/idev refcounts
>
> - ip6_mc_find_dev() becomes ip6_mc_find_dev_rcu() (called from rcu),
> and doesnt touch dev/idev refcounts
>
> - ipv6_sock_mc_close() : doesnt touch dev/idev refcounts
>
> - ip6_mc_source() uses ip6_mc_find_dev_rcu()
>
> - ip6_mc_msfilter() uses ip6_mc_find_dev_rcu()
>
> - ip6_mc_msfget() uses ip6_mc_find_dev_rcu()
>
> - ipv6_dev_mc_dec(), ipv6_chk_mcast_addr(),
> igmp6_event_query(), igmp6_event_report(),
> mld_sendpack(), igmp6_send() dont touch idev refcount
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next-2.6] icmp: RCU conversion in icmp_address_reply()
From: David Miller @ 2010-06-10 1:07 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1275986075.2475.73.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Tue, 08 Jun 2010 10:34:35 +0200
> - rcu_read_lock() already held by caller
> - use __in_dev_get_rcu() instead of in_dev_get() / in_dev_put()
> - remove goto out;
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied.
^ permalink raw reply
* Interesting issue when using IPv6 autoconf sysctl.
From: Ben Greear @ 2010-06-10 1:09 UTC (permalink / raw)
To: NetDev
I just tried using the /proc/sys/net/ipv6/conf/[dev]/autoconf
feature to run off auto-configured link-local addresses
for one of my interfaces.
It worked like a charm, the address is gone,
and now the /proc/sys/net/ipv6/conf/[dev]
directory does not exist so I can't turn it back on!
I can work around this by forcing an ipv6 address back
onto the interface and then removing it, but that
is pretty crufty!
There has got to be a better way to implement this!
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [PATCH net-2.6] ipv6: fix ICMP6_MIB_OUTERRORS
From: David Miller @ 2010-06-10 1:39 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1275985484.2475.59.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Tue, 08 Jun 2010 10:24:44 +0200
> In commit 1f8438a85366 (icmp: Account for ICMP out errors), I did a typo
> on IPV6 side, using ICMP6_MIB_OUTMSGS instead of ICMP6_MIB_OUTERRORS
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied, thanks Eric.
^ permalink raw reply
* [PATCH net-next-2.6] ip: ip_ra_control() rcu fix
From: Eric Dumazet @ 2010-06-10 2:15 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20100607.212612.35795010.davem@davemloft.net>
Le lundi 07 juin 2010 à 21:26 -0700, David Miller a écrit :
> From: Eric Dumazet <eric.dumazet@gmail.com>
> Date: Mon, 07 Jun 2010 15:12:08 +0200
>
> > Straightforward conversion to RCU.
> >
> > One rwlock becomes a spinlock, and is static.
> >
> > Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
>
> Applied.
Hmm, rcu is tricky, I should re-read all my previous patches :(
Here is a followup on this patch, thanks !
[PATCH net-next-2.6] ip: ip_ra_control() rcu fix
commit 66018506e15b (ip: Router Alert RCU conversion) introduced RCU
lookups to ip_call_ra_chain(). It missed proper deinit phase :
When ip_ra_control() deletes an ip_ra_chain, it should make sure
ip_call_ra_chain() users can not start to use socket during the rcu
grace period. It should also delay the sock_put() after the grace
period, or we risk a premature socket freeing and corruptions, as
raw sockets are not rcu protected yet.
This delay avoids using expensive atomic_inc_not_return() in
ip_call_ra_chain().
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
include/net/ip.h | 5 ++++-
net/ipv4/ip_sockglue.c | 19 +++++++++++++++----
2 files changed, 19 insertions(+), 5 deletions(-)
diff --git a/include/net/ip.h b/include/net/ip.h
index 9982c97..d52f011 100644
--- a/include/net/ip.h
+++ b/include/net/ip.h
@@ -61,7 +61,10 @@ struct ipcm_cookie {
struct ip_ra_chain {
struct ip_ra_chain *next;
struct sock *sk;
- void (*destructor)(struct sock *);
+ union {
+ void (*destructor)(struct sock *);
+ struct sock *saved_sk;
+ };
struct rcu_head rcu;
};
diff --git a/net/ipv4/ip_sockglue.c b/net/ipv4/ip_sockglue.c
index 08b9519..47fff52 100644
--- a/net/ipv4/ip_sockglue.c
+++ b/net/ipv4/ip_sockglue.c
@@ -241,9 +241,13 @@ int ip_cmsg_send(struct net *net, struct msghdr *msg, struct ipcm_cookie *ipc)
struct ip_ra_chain *ip_ra_chain;
static DEFINE_SPINLOCK(ip_ra_lock);
-static void ip_ra_free_rcu(struct rcu_head *head)
+
+static void ip_ra_destroy_rcu(struct rcu_head *head)
{
- kfree(container_of(head, struct ip_ra_chain, rcu));
+ struct ip_ra_chain *ra = container_of(head, struct ip_ra_chain, rcu);
+
+ sock_put(ra->saved_sk);
+ kfree(ra);
}
int ip_ra_control(struct sock *sk, unsigned char on,
@@ -264,13 +268,20 @@ int ip_ra_control(struct sock *sk, unsigned char on,
kfree(new_ra);
return -EADDRINUSE;
}
+ /* dont let ip_call_ra_chain() use sk again */
+ ra->sk = NULL;
rcu_assign_pointer(*rap, ra->next);
spin_unlock_bh(&ip_ra_lock);
if (ra->destructor)
ra->destructor(sk);
- sock_put(sk);
- call_rcu(&ra->rcu, ip_ra_free_rcu);
+ /*
+ * Delay sock_put(sk) and kfree(ra) after one rcu grace
+ * period. This guarantee ip_call_ra_chain() dont need
+ * to mess with socket refcounts.
+ */
+ ra->saved_sk = sk;
+ call_rcu(&ra->rcu, ip_ra_destroy_rcu);
return 0;
}
}
^ permalink raw reply related
* Re: [PATCH net-next-2.6] ip: ip_ra_control() rcu fix
From: Eric Dumazet @ 2010-06-10 2:21 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <1276136109.2475.9.camel@edumazet-laptop>
Le jeudi 10 juin 2010 à 04:15 +0200, Eric Dumazet a écrit :
> [PATCH net-next-2.6] ip: ip_ra_control() rcu fix
>
> commit 66018506e15b (ip: Router Alert RCU conversion) introduced RCU
> lookups to ip_call_ra_chain(). It missed proper deinit phase :
> When ip_ra_control() deletes an ip_ra_chain, it should make sure
> ip_call_ra_chain() users can not start to use socket during the rcu
> grace period. It should also delay the sock_put() after the grace
> period, or we risk a premature socket freeing and corruptions, as
> raw sockets are not rcu protected yet.
>
> This delay avoids using expensive atomic_inc_not_return() in
Grrr... should be atomic_inc_not_zero(), sorry for the typo in
ChangeLog :(
[PATCH net-next-2.6 v2] ip: ip_ra_control() rcu fix
commit 66018506e15b (ip: Router Alert RCU conversion) introduced RCU
lookups to ip_call_ra_chain(). It missed proper deinit phase :
When ip_ra_control() deletes an ip_ra_chain, it should make sure
ip_call_ra_chain() users can not start to use socket during the rcu
grace period. It should also delay the sock_put() after the grace
period, or we risk a premature socket freeing and corruptions, as
raw sockets are not rcu protected yet.
This delay avoids using expensive atomic_inc_not_zero() in
ip_call_ra_chain().
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
include/net/ip.h | 5 ++++-
net/ipv4/ip_sockglue.c | 19 +++++++++++++++----
2 files changed, 19 insertions(+), 5 deletions(-)
diff --git a/include/net/ip.h b/include/net/ip.h
index 9982c97..d52f011 100644
--- a/include/net/ip.h
+++ b/include/net/ip.h
@@ -61,7 +61,10 @@ struct ipcm_cookie {
struct ip_ra_chain {
struct ip_ra_chain *next;
struct sock *sk;
- void (*destructor)(struct sock *);
+ union {
+ void (*destructor)(struct sock *);
+ struct sock *saved_sk;
+ };
struct rcu_head rcu;
};
diff --git a/net/ipv4/ip_sockglue.c b/net/ipv4/ip_sockglue.c
index 08b9519..47fff52 100644
--- a/net/ipv4/ip_sockglue.c
+++ b/net/ipv4/ip_sockglue.c
@@ -241,9 +241,13 @@ int ip_cmsg_send(struct net *net, struct msghdr *msg, struct ipcm_cookie *ipc)
struct ip_ra_chain *ip_ra_chain;
static DEFINE_SPINLOCK(ip_ra_lock);
-static void ip_ra_free_rcu(struct rcu_head *head)
+
+static void ip_ra_destroy_rcu(struct rcu_head *head)
{
- kfree(container_of(head, struct ip_ra_chain, rcu));
+ struct ip_ra_chain *ra = container_of(head, struct ip_ra_chain, rcu);
+
+ sock_put(ra->saved_sk);
+ kfree(ra);
}
int ip_ra_control(struct sock *sk, unsigned char on,
@@ -264,13 +268,20 @@ int ip_ra_control(struct sock *sk, unsigned char on,
kfree(new_ra);
return -EADDRINUSE;
}
+ /* dont let ip_call_ra_chain() use sk again */
+ ra->sk = NULL;
rcu_assign_pointer(*rap, ra->next);
spin_unlock_bh(&ip_ra_lock);
if (ra->destructor)
ra->destructor(sk);
- sock_put(sk);
- call_rcu(&ra->rcu, ip_ra_free_rcu);
+ /*
+ * Delay sock_put(sk) and kfree(ra) after one rcu grace
+ * period. This guarantee ip_call_ra_chain() dont need
+ * to mess with socket refcounts.
+ */
+ ra->saved_sk = sk;
+ call_rcu(&ra->rcu, ip_ra_destroy_rcu);
return 0;
}
}
^ permalink raw reply related
* [PATCH net-next-2.6] econet: fix locking
From: Eric Dumazet @ 2010-06-10 2:33 UTC (permalink / raw)
To: David Miller; +Cc: netdev
econet lacks proper locking. It holds econet_lock only when inserting or
deleting an entry in econet_sklist, not during lookups.
- convert econet_lock from rwlock to spinlock
- use econet_lock in ec_listening_socket() lookup
- use appropriate sock_hold() / sock_put() to avoid corruptions.
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
net/econet/af_econet.c | 27 ++++++++++++++++++---------
1 file changed, 18 insertions(+), 9 deletions(-)
diff --git a/net/econet/af_econet.c b/net/econet/af_econet.c
index 2a5a805..dc54bd0 100644
--- a/net/econet/af_econet.c
+++ b/net/econet/af_econet.c
@@ -48,7 +48,7 @@
static const struct proto_ops econet_ops;
static struct hlist_head econet_sklist;
-static DEFINE_RWLOCK(econet_lock);
+static DEFINE_SPINLOCK(econet_lock);
static DEFINE_MUTEX(econet_mutex);
/* Since there are only 256 possible network numbers (or fewer, depends
@@ -98,16 +98,16 @@ struct ec_cb
static void econet_remove_socket(struct hlist_head *list, struct sock *sk)
{
- write_lock_bh(&econet_lock);
+ spin_lock_bh(&econet_lock);
sk_del_node_init(sk);
- write_unlock_bh(&econet_lock);
+ spin_unlock_bh(&econet_lock);
}
static void econet_insert_socket(struct hlist_head *list, struct sock *sk)
{
- write_lock_bh(&econet_lock);
+ spin_lock_bh(&econet_lock);
sk_add_node(sk, list);
- write_unlock_bh(&econet_lock);
+ spin_unlock_bh(&econet_lock);
}
/*
@@ -782,15 +782,19 @@ static struct sock *ec_listening_socket(unsigned char port, unsigned char
struct sock *sk;
struct hlist_node *node;
+ spin_lock(&econet_lock);
sk_for_each(sk, node, &econet_sklist) {
struct econet_sock *opt = ec_sk(sk);
if ((opt->port == port || opt->port == 0) &&
(opt->station == station || opt->station == 0) &&
- (opt->net == net || opt->net == 0))
+ (opt->net == net || opt->net == 0)) {
+ sock_hold(sk);
goto found;
+ }
}
sk = NULL;
found:
+ spin_unlock(&econet_lock);
return sk;
}
@@ -852,7 +856,7 @@ static void aun_incoming(struct sk_buff *skb, struct aunhdr *ah, size_t len)
{
struct iphdr *ip = ip_hdr(skb);
unsigned char stn = ntohl(ip->saddr) & 0xff;
- struct sock *sk;
+ struct sock *sk = NULL;
struct sk_buff *newskb;
struct ec_device *edev = skb->dev->ec_ptr;
@@ -882,10 +886,13 @@ static void aun_incoming(struct sk_buff *skb, struct aunhdr *ah, size_t len)
}
aun_send_response(ip->saddr, ah->handle, 3, 0);
+ sock_put(sk);
return;
bad:
aun_send_response(ip->saddr, ah->handle, 4, 0);
+ if (sk)
+ sock_put(sk);
}
/*
@@ -1050,7 +1057,7 @@ release:
static int econet_rcv(struct sk_buff *skb, struct net_device *dev, struct packet_type *pt, struct net_device *orig_dev)
{
struct ec_framehdr *hdr;
- struct sock *sk;
+ struct sock *sk = NULL;
struct ec_device *edev = dev->ec_ptr;
if (!net_eq(dev_net(dev), &init_net))
@@ -1085,10 +1092,12 @@ static int econet_rcv(struct sk_buff *skb, struct net_device *dev, struct packet
if (ec_queue_packet(sk, skb, edev->net, hdr->src_stn, hdr->cb,
hdr->port))
goto drop;
-
+ sock_put(sk);
return NET_RX_SUCCESS;
drop:
+ if (sk)
+ sock_put(sk);
kfree_skb(skb);
return NET_RX_DROP;
}
^ permalink raw reply related
* Re: [PATCH] gianfar: Revive the driver for eTSEC devices (disable timestamping)
From: Richard Cochran @ 2010-06-10 6:29 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: David Miller, Manfred Rudigier, netdev, linuxppc-dev
In-Reply-To: <20100609193219.GA8629@oksana.dev.rtsoft.ru>
On Wed, Jun 09, 2010 at 11:32:19PM +0400, Anton Vorontsov wrote:
> Since commit cc772ab7cdcaa24d1fae332d92a1602788644f7a ("gianfar: Add
> hardware RX timestamping support"), the driver no longer works on
> at least MPC8313ERDB and MPC8568EMDS boards (and possibly much more
> boards as well).
What do you mean by, "no longer works?" The driver works fine for us,
even without TMR_CTRL[TE] set. We tested the driver on two MPC8313ERDB
REV C boards, one P2020DS, and one P2020RDB.
> That's how MPC8313 Reference Manual describes RCTRL_TS_ENABLE bit:
>
> Timestamp incoming packets as padding bytes. PAL field is set
> to 8 if the PAL field is programmed to less than 8. Must be set
> to zero if TMR_CTRL[TE]=0.
>
> I see that the commit above sets this bit, but it doesn't handle
> TMR_CTRL. Manfred probably had this bit set by the firmware for
> his boards. But obviously this isn't true for all boards in the
> wild.
No, we did not set TMR_CTRL[TE].
For the Rx timestamps, we simply enabled them unconditionally. The
effect of not setting TMR_CTRL[TE] was that the timestamps were
invalid, but that should not matter if user space has not configured
the PTP clock. We left the TMR_CTRL[TE] bit for the PTP clock driver
(recently submitted and discussed on netdev). Actually, I copy the PTP
clock driver to the target via 'scp' during development, and I never
had any trouble.
> Also, I recall that Freescale BSPs were explicitly disabling the
> timestamping because of a performance drop.
The BSPs that we have, for the MPC8313ERDB and the P2020RBD both
include a (hacky) PTP timestmaping driver. Can you be more specific
about where and when Freescale is disabling timestamping?
> For now, the best way to deal with this is just disable the
> timestamping, and later we can discuss proper device tree bindings
> and implement enabling this feature via some property.
Okay, but now we want to identify what exactly works and what not. As
mentioned, we tested this driver on four different boards and did not
see any problems.
Thanks,
Richard
^ permalink raw reply
* Re: Bug#584238: linux-image-2.6.32-3-486: When using USB to Ethernet nework adapter later on get error: blocked for more than 120 seconds
From: Petko Manolov @ 2010-06-10 6:49 UTC (permalink / raw)
To: Paul Chany; +Cc: Ben Hutchings, 584238, Petko Manolov, netdev
In-Reply-To: <87aar4e49d.fsf@debian-laptop.localdomain>
The project ain't dead yet, i has moved into the mainline long time ago.
Petko
On Wed, 9 Jun 2010, Paul Chany wrote:
> Ben Hutchings <ben@decadent.org.uk> writes:
>
>> On Wed, 2010-06-02 at 16:45 +0200, Paul Chany wrote:
>>> Package: linux-2.6
>>> Version: 2.6.32-9
>>> Severity: normal
>>> Tags: squeeze
>>>
>>> When using USB to Ethernet adapter later on get error on console:
>>>
>>> [11531.988248] INOF: task khubd:618 blocked for more than 120 seconds.
>>> [11531.988377] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this
>>> message.
>>> [11531.990656] INFO: task pegasus:1156 blocked for more than 120 seconds.
>>> [11531.990722] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this
>>> message.
>>>
>>> After that I can't reconfigure anymore network, nor reboot the system with the command:
>>> sudo shutdown -t 1 -r now
>>> because the system hangs forever.
>>>
>>> It is not help if I unplug and plug in again the network adapter, it is not recognised by
>>> the kernel anymore.
>>
>> I'm forwarding this to the pegasus driver developers so they can comment
>> on it.
>>
>> Debian kernel version 2.6.32-9 is closely based on stable kernel
>> 2.6.32.9.
>
> It seems that the developers dont' responds for this bugreport at all.
> Is the pegasus kernel driver a dead project now?
> There in their projectpage: http://pegasus2.sourceforge.net/
> one can see that that pegasus is available
> only for kernels 2.4 and 2.5 but not for 2.6, right?
>
> In the meantime I can to reboot every hour or so because of this buggish
> driver.
>
> --
> Regards,
> Paul Chany
> You can freely correct my English.
> http://csanyi-pal.info
>
^ permalink raw reply
* Re: no reassembly for outgoing packets on RAW socket
From: Jiri Olsa @ 2010-06-10 6:56 UTC (permalink / raw)
To: Patrick McHardy; +Cc: netdev, Netfilter Developer Mailing List
In-Reply-To: <4C0FA24A.7060907@trash.net>
On Wed, Jun 09, 2010 at 04:16:42PM +0200, Patrick McHardy wrote:
> Jiri Olsa wrote:
> > On Fri, Jun 04, 2010 at 02:03:17PM +0200, Patrick McHardy wrote:
> >
> >> Jiri Olsa wrote:
> >>
> >>> hi,
> >>>
> >>> I'd like to be able to sendout a single IP packet with MF flag set.
> >>>
> >>> When using RAW sockets the packet will get stuck in the
> >>> netfilter (NF_INET_LOCAL_OUT nf_defrag_ipv4 reassembly unit)
> >>> and wont ever make it out..
> >>>
> >>> I made a change which bypass the outgoing reassembly for
> >>> RAW sockets, but I'm not sure wether it's too invasive..
> >>>
> >> That would break reassembly (and thus connection tracking) for cases
> >> where its really intended.
> >>
> >>
> >>> Is there any standard for RAW sockets behaviour?
> >>> Or another way around? :)
> >>>
> >> You could use the NOTRACK target to bypass connection tracking.
> >>
> >
> > ok,
> >
> > I tried the NOTRACK target, but the packet is still going
> > throught reassembly, because the RAW filter has lower priority
> > then the connection track defragmentation..
> >
>
> Right.
> > I was able to get it bypassed by attached patch and following
> > command:
> >
> > iptables -v -t raw -A OUTPUT -p icmp -j NOTRACK
> >
> > again, not sure if this is too invasive ;)
> >
>
> Well, we can't change it in the mainline kernel.
> > If this is not the way, I'd appreciatte any hint.. my goal is
> > to put malformed packet on the wire (more frags bit set for a
> > non fragmented packet)
>
> I don't have any good suggestions besides adding a flag to the IPCB
> and skipping defragmentation based on that.
ok,
I can see a way when I set this via setsockopt to the socket,
and check the value before the defragmentation.. would such a new
setsock option be acceptable?
I'm not sure I can see a way via IPCB, AFAICS it's for skb bound flags
which arise during the skb processing.
thanks,
jirka
^ permalink raw reply
* Re: no reassembly for outgoing packets on RAW socket
From: Jiri Olsa @ 2010-06-10 6:57 UTC (permalink / raw)
To: Jan Engelhardt; +Cc: Patrick McHardy, netdev, Netfilter Developer Mailing List
In-Reply-To: <alpine.LSU.2.01.1006091719010.30265@obet.zrqbmnf.qr>
On Wed, Jun 09, 2010 at 05:20:37PM +0200, Jan Engelhardt wrote:
>
> On Wednesday 2010-06-09 17:16, Patrick McHardy wrote:
> >Jan Engelhardt wrote:
> >> On Wednesday 2010-06-09 16:16, Patrick McHardy wrote:
> >>>>> You could use the NOTRACK target to bypass connection tracking.
> >>>>>
> >>>> I tried the NOTRACK target, but the packet is still going
> >>>> throught reassembly, because the RAW filter has lower priority
> >>>> then the connection track defragmentation..
> >>>
> >>> Right.
> >>
> >> Blech. That reminds me of
> >> http://marc.info/?l=netfilter-devel&m=126581823826735&w=2
> >
> >We already fixed that.
>
> I know, and I posted it for the understanding of the OP
> as to why RAW is after DEFRAG.
thanks, it's helpful
jirka
^ permalink raw reply
* [patch] enic: cleanup vic_provinfo_alloc()
From: Dan Carpenter @ 2010-06-10 7:59 UTC (permalink / raw)
To: Scott Feldman; +Cc: Vasanthy Kolluri, Roopa Prabhu, netdev, kernel-janitors
If oui were a null variable then vic_provinfo_alloc() would leak memory.
But this function is only called from one place and oui is not null so
I removed the check.
I also moved the memory allocation down a line so it was easier to spot.
(No one ever reads variable declarations).
Signed-off-by: Dan Carpenter <error27@gmail.com>
diff --git a/drivers/net/enic/vnic_vic.c b/drivers/net/enic/vnic_vic.c
index d769772..0a35085 100644
--- a/drivers/net/enic/vnic_vic.c
+++ b/drivers/net/enic/vnic_vic.c
@@ -25,9 +25,10 @@
struct vic_provinfo *vic_provinfo_alloc(gfp_t flags, u8 *oui, u8 type)
{
- struct vic_provinfo *vp = kzalloc(VIC_PROVINFO_MAX_DATA, flags);
+ struct vic_provinfo *vp;
- if (!vp || !oui)
+ vp = kzalloc(VIC_PROVINFO_MAX_DATA, flags);
+ if (!vp)
return NULL;
memcpy(vp->oui, oui, sizeof(vp->oui));
^ permalink raw reply related
* Re: [PATCH 1/2] pktgen: increasing transmission granularity
From: Daniel Turull @ 2010-06-10 8:44 UTC (permalink / raw)
To: David Miller; +Cc: netdev, robert, jens.laas
In-Reply-To: <20100609.135040.193710199.davem@davemloft.net>
This patch correct a bug in the delay of pktgen.
It makes sure the inter-packet interval is accurate.
Signed-off-by: Daniel Turull <daniel.turull@gmail.com>
---
diff --git a/net/core/pktgen.c b/net/core/pktgen.c
index 2ad68da..1dacd7b 100644
--- a/net/core/pktgen.c
+++ b/net/core/pktgen.c
@@ -2170,7 +2170,7 @@ static void spin(struct pktgen_dev *pkt_dev, ktime_t spin_until)
end_time = ktime_now();
pkt_dev->idle_acc += ktime_to_ns(ktime_sub(end_time, start_time));
- pkt_dev->next_tx = ktime_add_ns(end_time, pkt_dev->delay);
+ pkt_dev->next_tx = ktime_add_ns(spin_until, pkt_dev->delay);
}
static inline void set_pkt_overhead(struct pktgen_dev *pkt_dev)
^ permalink raw reply related
* Re: [PATCH][RFC] Infrastructure for compact call location representation
From: Nick Piggin @ 2010-06-10 8:47 UTC (permalink / raw)
To: David VomLehn; +Cc: Stephen Hemminger, to, netdev
In-Reply-To: <20100609182244.GC19804@dvomlehn-lnx2.corp.sa.net>
On Wed, Jun 09, 2010 at 11:22:44AM -0700, David VomLehn wrote:
> On Wed, Jun 09, 2010 at 03:44:17AM -0500, Nick Piggin wrote:
> > On Tue, Jun 08, 2010 at 08:44:56AM -0700, Stephen Hemminger wrote:
> > > On Mon, 7 Jun 2010 17:30:52 -0700
> > > David VomLehn <dvomlehn@cisco.com> wrote:
> > > > History
> > > > v2 Support small callsite IDs and split out out-of-band parameter
> > > > parsing.
> > > > V1 Initial release
> > > >
> > > > Signed-off-by: David VomLehn <dvomlehn@cisco.com>
> > >
> > > This is really Linux Kernel Mailing List material (not just netdev). And it will
> > > be a hard sell to get it accepted, because it is basically an alternative call
> > > tracing mechanism, and there are already several of these in use or under development
> > > (see perf and ftrace).
> >
> > What about a generic extension or layer on top of stacktrace that
> > does caching and unique IDs for stack traces. This way you can get
> > callsites or _full_ stack traces if required, and it shouldn't require
> > any extra magic in the net functions.
>
> Since the code calls BUG() when it detects an error, you already get the
> full stack trace of the location where the problem is detected. The question
> is the relative cost and benefits of a full stack trace of the previous
> sk_buff state modification. Since I'm working in a MIPS processor
> environment, I am rather prejudiced against doing any stack trace I don't
> have to; for now, at least, they are *very* expensive on MIPS.
Point is that you could select this depending on whether or not you
want it. If not, then you can just record the current IP.
> The two times this code (or its ancestor) has found problems in a deployed
> software stack, the engineers reported they there were able to immediately
> find and fix the problem. This suggests that we don't need to take on the
> complexity of the stack backtrace, at least for now. If this gets added to
> the mainline and people find they need the extra information, I'd be all
> for it.
I don't think it would get added to mainline with the tracing stuff
as a special hack under net/. I'm not saying it's not useful, but it
should just go into core code.
^ permalink raw reply
* Re: [PATCH 1/2] pktgen: increasing transmission granularity
From: Daniel Turull @ 2010-06-10 8:49 UTC (permalink / raw)
To: David Miller; +Cc: netdev, robert, jens.laas
In-Reply-To: <20100609.135040.193710199.davem@davemloft.net>
This patch increases the granularity of the rate generated by pktgen.
The previous version of pktgen uses micro seconds (udelay) resolution when it
was delayed causing gaps in the rates. It is changed to nanosecond (ndelay).
Now any rate is possible.
Also it allows to set, the desired rate in Mb/s or packets per second.
The documentation has been updated.
Signed-off-by: Daniel Turull <daniel.turull@gmail.com>
---
diff --git a/Documentation/networking/pktgen.txt b/Documentation/networking/pktgen.txt
index 61bb645..75e4fd7 100644
--- a/Documentation/networking/pktgen.txt
+++ b/Documentation/networking/pktgen.txt
@@ -151,6 +151,8 @@ Examples:
pgset stop aborts injection. Also, ^C aborts generator.
+ pgset "rate 300M" set rate to 300 Mb/s
+ pgset "ratep 1000000" set rate to 1Mpps
Example scripts
===============
@@ -241,6 +243,9 @@ src6
flows
flowlen
+rate
+ratep
+
References:
ftp://robur.slu.se/pub/Linux/net-development/pktgen-testing/
ftp://robur.slu.se/pub/Linux/net-development/pktgen-testing/examples/
diff --git a/net/core/pktgen.c b/net/core/pktgen.c
index 1dacd7b..6428653 100644
--- a/net/core/pktgen.c
+++ b/net/core/pktgen.c
@@ -169,7 +169,7 @@
#include <asm/dma.h>
#include <asm/div64.h> /* do_div */
-#define VERSION "2.73"
+#define VERSION "2.74"
#define IP_NAME_SZ 32
#define MAX_MPLS_LABELS 16 /* This is the max label stack depth */
#define MPLS_STACK_BOTTOM htonl(0x00000100)
@@ -980,6 +980,40 @@ static ssize_t pktgen_if_write(struct file *file,
(unsigned long long) pkt_dev->delay);
return count;
}
+ if (!strcmp(name, "rate")) {
+ len = num_arg(&user_buffer[i], 10, &value);
+ if (len < 0)
+ return len;
+
+ i += len;
+ if (!value)
+ return len;
+ pkt_dev->delay = pkt_dev->min_pkt_size*8*NSEC_PER_USEC/value;
+ if (debug)
+ printk(KERN_INFO
+ "pktgen: Delay set at: %llu ns\n",
+ pkt_dev->delay);
+
+ sprintf(pg_result, "OK: rate=%lu", value);
+ return count;
+ }
+ if (!strcmp(name, "ratep")) {
+ len = num_arg(&user_buffer[i], 10, &value);
+ if (len < 0)
+ return len;
+
+ i += len;
+ if (!value)
+ return len;
+ pkt_dev->delay = NSEC_PER_SEC/value;
+ if (debug)
+ printk(KERN_INFO
+ "pktgen: Delay set at: %llu ns\n",
+ pkt_dev->delay);
+
+ sprintf(pg_result, "OK: rate=%lu", value);
+ return count;
+ }
if (!strcmp(name, "udp_src_min")) {
len = num_arg(&user_buffer[i], 10, &value);
if (len < 0)
@@ -2142,15 +2176,15 @@ static void spin(struct pktgen_dev *pkt_dev, ktime_t spin_until)
hrtimer_init_on_stack(&t.timer, CLOCK_MONOTONIC, HRTIMER_MODE_ABS);
hrtimer_set_expires(&t.timer, spin_until);
- remaining = ktime_to_us(hrtimer_expires_remaining(&t.timer));
+ remaining = ktime_to_ns(hrtimer_expires_remaining(&t.timer));
if (remaining <= 0) {
pkt_dev->next_tx = ktime_add_ns(spin_until, pkt_dev->delay);
return;
}
start_time = ktime_now();
- if (remaining < 100)
- udelay(remaining); /* really small just spin */
+ if (remaining < 100000)
+ ndelay(remaining); /* really small just spin */
else {
/* see do_nanosleep */
hrtimer_init_sleeper(&t, current);
^ permalink raw reply related
* Re: no reassembly for outgoing packets on RAW socket
From: Patrick McHardy @ 2010-06-10 9:14 UTC (permalink / raw)
To: Jiri Olsa; +Cc: netdev, Netfilter Developer Mailing List
In-Reply-To: <20100610065631.GA1915@jolsa.lab.eng.brq.redhat.com>
Jiri Olsa wrote:
> On Wed, Jun 09, 2010 at 04:16:42PM +0200, Patrick McHardy wrote:
>
>>> If this is not the way, I'd appreciatte any hint.. my goal is
>>> to put malformed packet on the wire (more frags bit set for a
>>> non fragmented packet)
>>>
>> I don't have any good suggestions besides adding a flag to the IPCB
>> and skipping defragmentation based on that.
>>
> ok,
>
> I can see a way when I set this via setsockopt to the socket,
> and check the value before the defragmentation.. would such a new
> setsock option be acceptable?
>
> I'm not sure I can see a way via IPCB, AFAICS it's for skb bound flags
> which arise during the skb processing.
>
Yes, a socket option is basically what I was suggesting, using the
IPCB to mark the packet. But just marking the socket is fine of
course.
^ permalink raw reply
* Re: [patch] enic: cleanup vic_provinfo_alloc()
From: walter harms @ 2010-06-10 9:22 UTC (permalink / raw)
To: Dan Carpenter
Cc: Scott Feldman, Vasanthy Kolluri, Roopa Prabhu, netdev,
kernel-janitors
In-Reply-To: <20100610075903.GL5483@bicker>
Dan Carpenter schrieb:
> If oui were a null variable then vic_provinfo_alloc() would leak memory.
> But this function is only called from one place and oui is not null so
> I removed the check.
>
> I also moved the memory allocation down a line so it was easier to spot.
> (No one ever reads variable declarations).
>
> Signed-off-by: Dan Carpenter <error27@gmail.com>
>
> diff --git a/drivers/net/enic/vnic_vic.c b/drivers/net/enic/vnic_vic.c
> index d769772..0a35085 100644
> --- a/drivers/net/enic/vnic_vic.c
> +++ b/drivers/net/enic/vnic_vic.c
> @@ -25,9 +25,10 @@
>
> struct vic_provinfo *vic_provinfo_alloc(gfp_t flags, u8 *oui, u8 type)
> {
> - struct vic_provinfo *vp = kzalloc(VIC_PROVINFO_MAX_DATA, flags);
> + struct vic_provinfo *vp;
>
> - if (!vp || !oui)
> + vp = kzalloc(VIC_PROVINFO_MAX_DATA, flags);
> + if (!vp)
> return NULL;
>
> memcpy(vp->oui, oui, sizeof(vp->oui));
> --
This looks like memdup() ?
re,
wh
^ 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