* 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: 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: [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
* [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 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] 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-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
* 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-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
* 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] [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 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
* [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
* [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] 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
* 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
* 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 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: Grant Likely @ 2010-06-09 23:45 UTC (permalink / raw)
To: Randy Dunlap; +Cc: David Miller, sfr, netdev, linux-next, linux-kernel
In-Reply-To: <20100609154409.bf024c0c.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>
>
> 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?
Thanks,
g.
> 1 file changed, 3 deletions(-)
>
> --- linux-next-20100609.orig/drivers/net/niu.c
> +++ linux-next-20100609/drivers/net/niu.c
> @@ -28,10 +28,7 @@
> #include <linux/slab.h>
>
> #include <linux/io.h>
> -
> -#ifdef CONFIG_SPARC64
> #include <linux/of_device.h>
> -#endif
>
> #include "niu.h"
>
>
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: 2.6.25-rc2 pull request, stop log noise from CONFIG_RPS
From: David Miller @ 2010-06-09 23:28 UTC (permalink / raw)
To: timg; +Cc: eric.dumazet, netdev
In-Reply-To: <20100609195110.02FEAF89E9@sepang.rtg.net>
From: timg@tpi.com (Tim Gardner)
Date: Wed, 9 Jun 2010 13:51:09 -0600 (MDT)
> Please consider applying this patch in order to stop
> log noise under certain configurations.
Pulled, thanks Tim.
^ permalink raw reply
* Re: [PATCH] gianfar: Revive the driver for eTSEC devices (disable timestamping)
From: David Miller @ 2010-06-09 23:27 UTC (permalink / raw)
To: avorontsov; +Cc: netdev, Manfred.Rudigier, linuxppc-dev
In-Reply-To: <20100609193219.GA8629@oksana.dev.rtsoft.ru>
From: Anton Vorontsov <avorontsov@mvista.com>
Date: Wed, 9 Jun 2010 23:32:19 +0400
> 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).
>
> 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.
>
> Also, I recall that Freescale BSPs were explicitly disabling the
> timestamping because of a performance drop.
>
> 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.
>
> Signed-off-by: Anton Vorontsov <avorontsov@mvista.com>
Agreed, applied, thanks Anton.
^ permalink raw reply
* Re: [patch] caif: fix a couple range checks
From: David Miller @ 2010-06-09 23:19 UTC (permalink / raw)
To: sjur.brandeland; +Cc: error27, netdev, kernel-janitors
In-Reply-To: <81C3A93C17462B4BBD7E272753C10579169C4D9E64@EXDCVYMBSTM005.EQ1STM.local>
From: Sjur BRENDELAND <sjur.brandeland@stericsson.com>
Date: Wed, 9 Jun 2010 11:11:38 +0200
>> From: Dan Carpenter [mailto:error27@gmail.com]
>>
>> The extra ! character means that these conditions are always false.
>
>
> Looks good, thanks. This is embarrassing, I should caught this ages ago.
> Acked-by: Sjur Braendeland <sjur.brandeland@stericsson.com>
Applied, thanks guys.
^ permalink raw reply
* Re: [PATCH] phylib: Add support for the LXT973 phy.
From: David Miller @ 2010-06-09 23:17 UTC (permalink / raw)
To: richardcochran; +Cc: afleming, netdev
In-Reply-To: <20100607153932.GA2800@riccoc20.at.omicron.at>
From: Richard Cochran <richardcochran@gmail.com>
Date: Mon, 7 Jun 2010 17:39:32 +0200
> This patch implements a work around for Erratum 5, "3.3 V Fiber Speed
> Selection." If the hardware wiring does not respect this erratum, then
> fiber optic mode will not work properly.
>
> Signed-off-by: Richard Cochran <richard.cochran@omicron.at>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next-2.6] phonet: use call_rcu for phonet device free
From: David Miller @ 2010-06-09 23:15 UTC (permalink / raw)
To: eric.dumazet; +Cc: remi, jpirko, netdev
In-Reply-To: <1275918583.2545.84.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Mon, 07 Jun 2010 15:49:43 +0200
> Le lundi 07 juin 2010 à 15:43 +0200, Rémi Denis-Courmont a écrit :
>> On Mon, 7 Jun 2010 15:27:39 +0200, Jiri Pirko <jpirko@redhat.com> wrote:
>> > Use call_rcu rather than synchronize_rcu.
>> >
>> > Signed-off-by: Jiri Pirko <jpirko@redhat.com>
>>
>> This looks fine to me, but what is the goal here? The RCU documentation
>> seems to imply that synchronize_rcu() is preferable over call_rcu() when at
>> all possible.
>>
>
> Thats not exactly that.
>
> synchronize_rcu() is easier, in respect of memory use.
> But its drawback is current thread is blocked for several milli seconds.
>
> In the end, call_rcu() is more scalable.
>
> Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied, thanks.
^ permalink raw reply
* Re: Packet capture and Bonding asymmetries
From: Jay Vosburgh @ 2010-06-09 22:52 UTC (permalink / raw)
To: Paul LeoNerd Evans; +Cc: netdev
In-Reply-To: <20100609212704.GY11110@cel.leo>
Paul LeoNerd Evans <leonerd@leonerd.org.uk> wrote:
>We use ethernet bonding to bond eth0 + eth1 into bond0, in an
>active/standby failover pair. Given this is for redundancy, we put the
>two physical ethernet links into different switches that follow
>different paths in the data centre.
>
>Given this topology, it can be really useful to know which physical
>interface packets are received on. It seems the bonding driver doesn't
>make this happen:
>
> # uname -r
> 2.6.31.12
>
> # head -1 /proc/net/bonding/bond0
> Ethernet Channel Bonding Driver: v3.5.0 (November 4, 2008)
>
> # pktdump -f icmp
> [15:27:12] RX(bond0): ICMP| 192.168.57.6->192.168.57.1 echo-request seq=1
> [15:27:12] TX(bond0): ICMP| 192.168.57.1->192.168.57.6 echo-reply seq=1
> [15:27:12] TX(eth0): ICMP| 192.168.57.1->192.168.57.6 echo-reply seq=1
>
>I.e. when we transmit we see both the virtual bond0 interface and the
>physical eth0 doing so; but when we receive only the virtual bond0
>appears to do so.
>
>I believe this should be fixable with a one-line patch; just adding a
>call to netif_nit_deliver(skb) from within the bonding driver... though
>just offhand I'm unable to find exactly the line where packets received
>on slaves gets passed up to the master. :)
This won't work, because bonding does not have a receive
function in the usual sense. Instead, the slaves do their normal
receive logic, and then in __netif_receive_skb, packets are assigned to
the bonding master if the device is a slave.
On the TX side, packet capture can happen at both the bonding
device and at the slave, because the packet will pass through both.
>Can anyone advise on the sensibility or otherwise of this plan? I really
>would like the behaviour where I can see how packets are received - is
>this a good plan to acheive it?
For your own private testing, you could add a call to
__netif_nit_deliver in netif_receive_skb prior to this part:
master = ACCESS_ONCE(orig_dev->master);
if (master) {
if (skb_bond_should_drop(skb, master))
null_or_orig = orig_dev; /* deliver only exact match */
else
skb->dev = master;
}
This will give you multiple captures of the same packet, as is
seen for transmit (i.e., one on the slave, one on the bond). For
non-bonding devices, tcpdump will see each packet twice on the same
device, so it's not really suitable for general use.
>I may sometime have a hack at writing a patch for this anyway, presuming
>no major objections...
If merely knowing the traffic counts is sufficient, the slaves
do count their received packets individually, so, e.g., ifconfig will
show how many packets a particular slave has received, regardless of
what bonding does with them. The packet counts for the bonding device
itself are merely a sum of all of its slaves.
Also, generally speaking, IP protocol traffic that arrives on an
inactive bonding slave is not delivered. If you're using active-backup
mode, and your traffic makes it through, it likely arrived on the active
slave.
-J
---
-Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com
^ 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