* Re: [PATCH 1/1] ibmveth: Add suspend/resume support
From: David Miller @ 2010-05-18 0:09 UTC (permalink / raw)
To: brking; +Cc: netdev
In-Reply-To: <201005071156.o47BuCYM007062@d03av03.boulder.ibm.com>
From: Brian King <brking@linux.vnet.ibm.com>
Date: Fri, 07 May 2010 13:56:08 -0500
>
> Adds support for resuming from suspend for IBM virtual ethernet devices.
> We may have lost an interrupt over the suspend, so we just kick the
> interrupt handler to process anything that is outstanding.
>
> Signed-off-by: Brian King <brking@linux.vnet.ibm.com>
Applied, thank you.
^ permalink raw reply
* Re: [PATCH 1/1] ipv6 addrlabel: permit deletion of labels assigned to removed dev
From: David Miller @ 2010-05-18 0:08 UTC (permalink / raw)
To: fw; +Cc: netdev
In-Reply-To: <1273267893-22485-1-git-send-email-fw@strlen.de>
From: Florian Westphal <fw@strlen.de>
Date: Fri, 7 May 2010 23:31:33 +0200
> as addrlabels with an interface index are left alone when the
> interface gets removed this results in addrlabels that can no
> longer be removed.
>
> Restrict validation of index to adding new addrlabels.
>
> Signed-off-by: Florian Westphal <fw@strlen.de>
Applied, thanks Florian.
^ permalink raw reply
* Re: [PATCH 0/6] netns support in the kobject layer
From: David Miller @ 2010-05-17 23:48 UTC (permalink / raw)
To: gregkh
Cc: ebiederm, greg, kay.sievers, linux-kernel, tj, cornelia.huck,
eric.dumazet, bcrl, serue, netdev
In-Reply-To: <20100517210318.GA6170@suse.de>
From: Greg KH <gregkh@suse.de>
Date: Mon, 17 May 2010 14:03:18 -0700
> On Mon, May 17, 2010 at 01:58:44PM -0700, Eric W. Biederman wrote:
>> Greg KH <greg@kroah.com> writes:
>>
>> If I must I will resend these, but these patches are already in
>> production use, and I had them to you weeks before the merge window
>> closed.
>
> Yes, but they were not reviewed by the network maintainer until after
> the merge window closed. I already have your sysfs-namespace patches
> queued up for .35, and that's a big enough change for me to feel
> comfortable with at the moment.
Greg, this is complete bullshit. I reviewed them last week, they are fine
and have been around forever.
Merge them in now, making them wait until 2.6.36 is completely rediculious.
^ permalink raw reply
* Re: [PATCH 0/6] netns support in the kobject layer
From: Greg KH @ 2010-05-17 22:54 UTC (permalink / raw)
To: Eric W. Biederman
Cc: Greg KH, David Miller, kay.sievers, linux-kernel, tj,
cornelia.huck, eric.dumazet, bcrl, serue, netdev
In-Reply-To: <m1hbm6f93x.fsf@fess.ebiederm.org>
On Mon, May 17, 2010 at 03:37:22PM -0700, Eric W. Biederman wrote:
> Greg KH <gregkh@suse.de> writes:
>
> > On Mon, May 17, 2010 at 01:58:44PM -0700, Eric W. Biederman wrote:
> >> Greg KH <greg@kroah.com> writes:
> >>
> >> > On Sat, May 15, 2010 at 11:26:43PM -0700, David Miller wrote:
> >> >> From: Greg KH <greg@kroah.com>
> >> >> Date: Thu, 6 May 2010 13:04:04 -0700
> >> >>
> >> >> > On Tue, May 04, 2010 at 05:35:54PM -0700, Eric W. Biederman wrote:
> >> >> >>
> >> >> >> With the tagged sysfs support finally merged into Greg's tree,
> >> >> >> it is time for the last little bits of work to get the kobject
> >> >> >> layer and network namespaces to play together properly.
> >> >> >>
> >> >> >> These patches are roughly evenly divided between network layer work
> >> >> >> and sysfs layer work. Last time this conundrum came up I believe
> >> >> >> we decided that the easiest way to handle this was for Greg to carry
> >> >> >> all of the patches. David, Greg does that still make sense?
> >> >> >
> >> >> > That's fine, if I get David's ack on these.
> >> >>
> >> >> Looks good to me:
> >> >>
> >> >> Acked-by: David S. Miller <davem@davemloft.net>
> >> >
> >> > Ok. Eric, can you resend these to me when .35-rc1 is out so I can queue
> >> > them up then to get some testing in linux-next so that they can make it
> >> > into .36?
> >>
> >> Grumble. Grumble. Grumble.
> >>
> >> If I must I will resend these, but these patches are already in
> >> production use, and I had them to you weeks before the merge window
> >> closed.
> >
> > Yes, but they were not reviewed by the network maintainer until after
> > the merge window closed.
>
> Strictly speaking the day before but I get your point.
>
> > I already have your sysfs-namespace patches
> > queued up for .35, and that's a big enough change for me to feel
> > comfortable with at the moment.
> >
> >> Is there no way we can get these in for 2.6.35?
> >
> > No, sorry. One thing at a time please.
>
> Sure.
>
> If we are going to push this last bit off until the 2.6.36 time frame
> Dave, Greg mind if I flip around who I send these patches to?
>
> The big dependency is the sysfs-namespace patches which will be in
> 2.6.35, and if the patches get into net-next as well as linux-next
> there will be a larger number of potential testers.
Sure, that's fine with me.
thanks,
greg k-h
^ permalink raw reply
* [PATCH] net: Introduce skb_tunnel_rx() helper
From: Eric Dumazet @ 2010-05-17 22:50 UTC (permalink / raw)
To: David Miller; +Cc: netdev
skb rxhash should be cleared when a skb is handled by a tunnel before
being delivered again, so that correct packet steering can take place.
There are other cleanups and accounting that we can factorize in a new
helper, skb_tunnel_rx()
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
include/net/dst.h | 20 ++++++++++++++++++++
net/ipv4/ip_gre.c | 9 +--------
net/ipv4/ipip.c | 7 ++-----
net/ipv4/ipmr.c | 8 +++-----
net/ipv6/ip6_tunnel.c | 8 ++------
net/ipv6/ip6mr.c | 8 +++-----
net/ipv6/sit.c | 8 +++-----
7 files changed, 34 insertions(+), 34 deletions(-)
diff --git a/include/net/dst.h b/include/net/dst.h
index aac5a5f..d708c22 100644
--- a/include/net/dst.h
+++ b/include/net/dst.h
@@ -184,6 +184,26 @@ static inline void skb_dst_drop(struct sk_buff *skb)
skb->_skb_dst = 0UL;
}
+
+/**
+ * skb_tunnel_rx - prepare skb for rx reinsert
+ * @skb: buffer
+ * @dev: tunnel device
+ *
+ * After decapsulation, packet is going to re-enter (netif_rx()) our stack,
+ * so make some cleanups, and perform accounting.
+ */
+static inline void skb_tunnel_rx(struct sk_buff *skb, struct net_device *dev)
+{
+ skb->dev = dev;
+ /* TODO : stats should be SMP safe */
+ dev->stats.rx_packets++;
+ dev->stats.rx_bytes += skb->len;
+ skb->rxhash = 0;
+ skb_dst_drop(skb);
+ nf_reset(skb);
+}
+
/* Children define the path of the packet through the
* Linux networking. Thus, destinations are stackable.
*/
diff --git a/net/ipv4/ip_gre.c b/net/ipv4/ip_gre.c
index fe381d1..498cf69 100644
--- a/net/ipv4/ip_gre.c
+++ b/net/ipv4/ip_gre.c
@@ -538,7 +538,6 @@ static int ipgre_rcv(struct sk_buff *skb)
struct ip_tunnel *tunnel;
int offset = 4;
__be16 gre_proto;
- unsigned int len;
if (!pskb_may_pull(skb, 16))
goto drop_nolock;
@@ -629,8 +628,6 @@ static int ipgre_rcv(struct sk_buff *skb)
tunnel->i_seqno = seqno + 1;
}
- len = skb->len;
-
/* Warning: All skb pointers will be invalidated! */
if (tunnel->dev->type == ARPHRD_ETHER) {
if (!pskb_may_pull(skb, ETH_HLEN)) {
@@ -644,11 +641,7 @@ static int ipgre_rcv(struct sk_buff *skb)
skb_postpull_rcsum(skb, eth_hdr(skb), ETH_HLEN);
}
- stats->rx_packets++;
- stats->rx_bytes += len;
- skb->dev = tunnel->dev;
- skb_dst_drop(skb);
- nf_reset(skb);
+ skb_tunnel_rx(skb, tunnel->dev);
skb_reset_network_header(skb);
ipgre_ecn_decapsulate(iph, skb);
diff --git a/net/ipv4/ipip.c b/net/ipv4/ipip.c
index 0b27b14..7fd6367 100644
--- a/net/ipv4/ipip.c
+++ b/net/ipv4/ipip.c
@@ -374,11 +374,8 @@ static int ipip_rcv(struct sk_buff *skb)
skb->protocol = htons(ETH_P_IP);
skb->pkt_type = PACKET_HOST;
- tunnel->dev->stats.rx_packets++;
- tunnel->dev->stats.rx_bytes += skb->len;
- skb->dev = tunnel->dev;
- skb_dst_drop(skb);
- nf_reset(skb);
+ skb_tunnel_rx(skb, tunnel->dev);
+
ipip_ecn_decapsulate(iph, skb);
netif_rx(skb);
rcu_read_unlock();
diff --git a/net/ipv4/ipmr.c b/net/ipv4/ipmr.c
index 7a7ee1c..217ebe0 100644
--- a/net/ipv4/ipmr.c
+++ b/net/ipv4/ipmr.c
@@ -1831,14 +1831,12 @@ static int __pim_rcv(struct mr_table *mrt, struct sk_buff *skb,
skb->mac_header = skb->network_header;
skb_pull(skb, (u8*)encap - skb->data);
skb_reset_network_header(skb);
- skb->dev = reg_dev;
skb->protocol = htons(ETH_P_IP);
skb->ip_summed = 0;
skb->pkt_type = PACKET_HOST;
- skb_dst_drop(skb);
- reg_dev->stats.rx_bytes += skb->len;
- reg_dev->stats.rx_packets++;
- nf_reset(skb);
+
+ skb_tunnel_rx(skb, reg_dev);
+
netif_rx(skb);
dev_put(reg_dev);
diff --git a/net/ipv6/ip6_tunnel.c b/net/ipv6/ip6_tunnel.c
index 2599870..8f39893 100644
--- a/net/ipv6/ip6_tunnel.c
+++ b/net/ipv6/ip6_tunnel.c
@@ -723,14 +723,10 @@ static int ip6_tnl_rcv(struct sk_buff *skb, __u16 protocol,
skb->protocol = htons(protocol);
skb->pkt_type = PACKET_HOST;
memset(skb->cb, 0, sizeof(struct inet6_skb_parm));
- skb->dev = t->dev;
- skb_dst_drop(skb);
- nf_reset(skb);
- dscp_ecn_decapsulate(t, ipv6h, skb);
+ skb_tunnel_rx(skb, t->dev);
- t->dev->stats.rx_packets++;
- t->dev->stats.rx_bytes += skb->len;
+ dscp_ecn_decapsulate(t, ipv6h, skb);
netif_rx(skb);
rcu_read_unlock();
return 0;
diff --git a/net/ipv6/ip6mr.c b/net/ipv6/ip6mr.c
index 163850e..bd9e7d3 100644
--- a/net/ipv6/ip6mr.c
+++ b/net/ipv6/ip6mr.c
@@ -658,14 +658,12 @@ static int pim6_rcv(struct sk_buff *skb)
skb->mac_header = skb->network_header;
skb_pull(skb, (u8 *)encap - skb->data);
skb_reset_network_header(skb);
- skb->dev = reg_dev;
skb->protocol = htons(ETH_P_IPV6);
skb->ip_summed = 0;
skb->pkt_type = PACKET_HOST;
- skb_dst_drop(skb);
- reg_dev->stats.rx_bytes += skb->len;
- reg_dev->stats.rx_packets++;
- nf_reset(skb);
+
+ skb_tunnel_rx(skb, reg_dev);
+
netif_rx(skb);
dev_put(reg_dev);
return 0;
diff --git a/net/ipv6/sit.c b/net/ipv6/sit.c
index 5abae10..e51e650 100644
--- a/net/ipv6/sit.c
+++ b/net/ipv6/sit.c
@@ -566,11 +566,9 @@ static int ipip6_rcv(struct sk_buff *skb)
kfree_skb(skb);
return 0;
}
- tunnel->dev->stats.rx_packets++;
- tunnel->dev->stats.rx_bytes += skb->len;
- skb->dev = tunnel->dev;
- skb_dst_drop(skb);
- nf_reset(skb);
+
+ skb_tunnel_rx(skb, tunnel->dev);
+
ipip6_ecn_decapsulate(iph, skb);
netif_rx(skb);
rcu_read_unlock();
^ permalink raw reply related
* Re: [PATCH 0/6] netns support in the kobject layer
From: Eric W. Biederman @ 2010-05-17 22:37 UTC (permalink / raw)
To: Greg KH
Cc: Greg KH, David Miller, kay.sievers, linux-kernel, tj,
cornelia.huck, eric.dumazet, bcrl, serue, netdev
In-Reply-To: <20100517210318.GA6170@suse.de>
Greg KH <gregkh@suse.de> writes:
> On Mon, May 17, 2010 at 01:58:44PM -0700, Eric W. Biederman wrote:
>> Greg KH <greg@kroah.com> writes:
>>
>> > On Sat, May 15, 2010 at 11:26:43PM -0700, David Miller wrote:
>> >> From: Greg KH <greg@kroah.com>
>> >> Date: Thu, 6 May 2010 13:04:04 -0700
>> >>
>> >> > On Tue, May 04, 2010 at 05:35:54PM -0700, Eric W. Biederman wrote:
>> >> >>
>> >> >> With the tagged sysfs support finally merged into Greg's tree,
>> >> >> it is time for the last little bits of work to get the kobject
>> >> >> layer and network namespaces to play together properly.
>> >> >>
>> >> >> These patches are roughly evenly divided between network layer work
>> >> >> and sysfs layer work. Last time this conundrum came up I believe
>> >> >> we decided that the easiest way to handle this was for Greg to carry
>> >> >> all of the patches. David, Greg does that still make sense?
>> >> >
>> >> > That's fine, if I get David's ack on these.
>> >>
>> >> Looks good to me:
>> >>
>> >> Acked-by: David S. Miller <davem@davemloft.net>
>> >
>> > Ok. Eric, can you resend these to me when .35-rc1 is out so I can queue
>> > them up then to get some testing in linux-next so that they can make it
>> > into .36?
>>
>> Grumble. Grumble. Grumble.
>>
>> If I must I will resend these, but these patches are already in
>> production use, and I had them to you weeks before the merge window
>> closed.
>
> Yes, but they were not reviewed by the network maintainer until after
> the merge window closed.
Strictly speaking the day before but I get your point.
> I already have your sysfs-namespace patches
> queued up for .35, and that's a big enough change for me to feel
> comfortable with at the moment.
>
>> Is there no way we can get these in for 2.6.35?
>
> No, sorry. One thing at a time please.
Sure.
If we are going to push this last bit off until the 2.6.36 time frame
Dave, Greg mind if I flip around who I send these patches to?
The big dependency is the sysfs-namespace patches which will be in
2.6.35, and if the patches get into net-next as well as linux-next
there will be a larger number of potential testers.
Eric
^ permalink raw reply
* Re: [patch] pm_qos update fixing mmotm 2010-05-11 -dies in pm_qos_update_request()
From: Rafael J. Wysocki @ 2010-05-17 21:58 UTC (permalink / raw)
To: markgross
Cc: mgross, Valdis.Kletnieks, e1000-devel, netdev, linux-kernel,
linux-pm, akpm, davem
In-Reply-To: <20100517001241.GA2962@thegnar.org>
On Monday 17 May 2010, mgross wrote:
> On Mon, May 17, 2010 at 12:21:25AM +0200, Rafael J. Wysocki wrote:
> > On Saturday 15 May 2010, mgross wrote:
> > > On Sat, May 15, 2010 at 09:38:47PM +0200, Rafael J. Wysocki wrote:
> > > > On Saturday 15 May 2010, mgross wrote:
> > > > > I apologize for the goofy email address.
> > > > >
> > > > > The following is a fix for the crash reported by Valdis.
> > > > >
> > > > > The problem was that the original pm_qos silently fails when a request
> > > > > update is passed to a parameter that has not been added to the list
> > > > > yet. It seems that the e1000e is doing this. This update restores this
> > > > > behavior.
> > > > >
> > > > > I need to think about how to better handle such abuse, but for now this
> > > > > restores the original behavior.
> > > >
> > > > Can you please post a signed-off incremental patch against
> > > >
> > > > git://git.kernel.org/pub/scm/linux/kernel/git/rafael/suspend-2.6.git for-llinus
> > > >
> > > > that contains your original PM QOS update?
> > >
> > > No problem:
> > >
> > > Signed-off-by: markgross <markgross@thegnar.org>
> >
> > Thanks! Do you want to use this address for the sign-off or the Intel one?
>
> I guess so. Ever since switching groups within intel last summer my
> mgross@linux.intel.com address isn't checked as often as this one.
>
> The other option is to use my outlook email (mark.gross@intel.com), but
> I really hate posting from outlook. Besides, doing upstream kernel
> stuff isn't my day job any more so using markgross@thegnar.org makes
> sense to me.
Good. Patch applied to suspend-2.6/for-linus.
Thanks,
Rafael
------------------------------------------------------------------------------
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
^ permalink raw reply
* Re: iproute2 issue with adding rules.
From: Stephen Hemminger @ 2010-05-17 21:41 UTC (permalink / raw)
To: Ben Greear; +Cc: Chris Wright, NetDev
In-Reply-To: <4BF1A855.3090905@candelatech.com>
On Mon, 17 May 2010 13:34:29 -0700
Ben Greear <greearb@candelatech.com> wrote:
> On 05/17/2010 01:30 PM, Chris Wright wrote:
> > * Ben Greear (greearb@candelatech.com) wrote:
> >> On 05/17/2010 01:13 PM, Ben Greear wrote:
> >>> On 05/17/2010 12:03 PM, Ben Greear wrote:
> >>>> On older releases, you can do this with iproute:
> >>>>
> >>>> # ip ru add from 9.9.9.2/32 table 226 pref 400
> >>>> #
> >>>>
> >>>> But, in latest git, it returns an error:
> >>>> # ip ru add from 9.9.9.2/32 table 226 pref 400
> >>>> Error: an inet prefix is expected rather than "9.9.9.2/32".
> >>>>
> >>>> Is that on purpose?
> >>>
> >>> I was thinking maybe this was a library issue, since I compiled
> >>> on one machine and ran the 'ip' exe on another. So, I tried compiling
> >>> on the test system.
> >>
> >> I'm not thinking too well today, but this patch fixes the compile.
> >> No idea if it's actually correct code.
> >
> > Needs more changes than that patch.
>
> Ok, I'll try going back a few commits to find something that compiles
> w/out my hacks.
>
> Also, the rule addition does work..make install put ip in
> a different place than it's installed in fedora, so I wasn't
> actually running the latest code when I first tried to add
> the rule.
Distributions never seem to agree where it should be: /sbin or /usr/sbin
or even /bin
^ permalink raw reply
* [PATCH] [resend] fix non-mergeable buffers packet too large error handling
From: David L Stevens @ 2010-05-17 21:16 UTC (permalink / raw)
To: mst; +Cc: netdev, kvm, virtualization
This patch enforces single-buffer allocation when
mergeable rx buffers is not enabled.
Reported-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: David L Stevens <dlstevens@us.ibm.com>
diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
index 309c570..c346304 100644
--- a/drivers/vhost/net.c
+++ b/drivers/vhost/net.c
@@ -361,13 +361,21 @@ static void handle_rx(struct vhost_net *net)
break;
}
/* TODO: Should check and handle checksum. */
- if (vhost_has_feature(&net->dev, VIRTIO_NET_F_MRG_RXBUF) &&
- memcpy_toiovecend(vq->hdr, (unsigned char *)&headcount,
- offsetof(typeof(hdr), num_buffers),
- sizeof hdr.num_buffers)) {
- vq_err(vq, "Failed num_buffers write");
+ if (vhost_has_feature(&net->dev, VIRTIO_NET_F_MRG_RXBUF)) {
+ if (memcpy_toiovecend(vq->hdr,
+ (unsigned char *)&headcount,
+ offsetof(typeof(hdr),
+ num_buffers),
+ sizeof hdr.num_buffers)) {
+ vq_err(vq, "Failed num_buffers write");
+ vhost_discard_desc(vq, headcount);
+ break;
+ }
+ } else if (headcount > 1) {
+ vq_err(vq, "rx packet too large (%d) for guest",
+ sock_len);
vhost_discard_desc(vq, headcount);
- break;
+ continue;
}
vhost_add_used_and_signal_n(&net->dev, vq, vq->heads,
headcount);
^ permalink raw reply related
* [PATCH] tcp: tcp_synack_options() fix
From: Eric Dumazet @ 2010-05-17 21:04 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Bijay Singh, David Miller, <bhaskie@gmail.com>,
<bhutchings@solarflare.com>, netdev, Ilpo Järvinen
In-Reply-To: <20100517134240.1949f245@nehalam>
Le lundi 17 mai 2010 à 13:42 -0700, Stephen Hemminger a écrit :
> Since you are doing away with flag variable, why not this instead?
>
Sure, we can eliminate this doing_ts variable and save few bytes
Thanks
[PATCH] tcp: tcp_synack_options() fix
Commit 33ad798c924b4a (tcp: options clean up) introduced a problem
if MD5+SACK+timestamps were used in initial SYN message.
Some stacks (old linux for example) try to negotiate MD5+SACK+TSTAMP
sessions, but since 40 bytes of tcp options space are not enough to
store all the bits needed, we chose to disable timestamps in this case.
We send a SYN-ACK _without_ timestamp option, but socket has timestamps
enabled and all further outgoing messages contain a TS block, all with
the initial timestamp of the remote peer.
Fix is to really disable timestamps option for the whole session.
Reported-by: Bijay Singh <Bijay.Singh@guavus.com>
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
index 0dda86e..44e98d9 100644
--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
@@ -667,7 +667,6 @@ static unsigned tcp_synack_options(struct sock *sk,
u8 cookie_plus = (xvp != NULL && !xvp->cookie_out_never) ?
xvp->cookie_plus :
0;
- bool doing_ts = ireq->tstamp_ok;
#ifdef CONFIG_TCP_MD5SIG
*md5 = tcp_rsk(req)->af_specific->md5_lookup(sk, req);
@@ -680,7 +679,7 @@ static unsigned tcp_synack_options(struct sock *sk,
* rather than TS in order to fit in better with old,
* buggy kernels, but that was deemed to be unnecessary.
*/
- doing_ts &= !ireq->sack_ok;
+ ireq->tstamp_ok &= !ireq->sack_ok;
}
#else
*md5 = NULL;
@@ -695,7 +694,7 @@ static unsigned tcp_synack_options(struct sock *sk,
opts->options |= OPTION_WSCALE;
remaining -= TCPOLEN_WSCALE_ALIGNED;
}
- if (likely(doing_ts)) {
+ if (likely(ireq->tstamp_ok)) {
opts->options |= OPTION_TS;
opts->tsval = TCP_SKB_CB(skb)->when;
opts->tsecr = req->ts_recent;
@@ -703,7 +702,7 @@ static unsigned tcp_synack_options(struct sock *sk,
}
if (likely(ireq->sack_ok)) {
opts->options |= OPTION_SACK_ADVERTISE;
- if (unlikely(!doing_ts))
+ if (unlikely(!ireq->tstamp_ok))
remaining -= TCPOLEN_SACKPERM_ALIGNED;
}
@@ -711,7 +710,7 @@ static unsigned tcp_synack_options(struct sock *sk,
* If the <SYN> options fit, the same options should fit now!
*/
if (*md5 == NULL &&
- doing_ts &&
+ ireq->tstamp_ok &&
cookie_plus > TCPOLEN_COOKIE_BASE) {
int need = cookie_plus; /* has TCPOLEN_COOKIE_BASE */
^ permalink raw reply related
* Re: [PATCH 0/6] netns support in the kobject layer
From: Greg KH @ 2010-05-17 21:03 UTC (permalink / raw)
To: Eric W. Biederman
Cc: Greg KH, David Miller, kay.sievers, linux-kernel, tj,
cornelia.huck, eric.dumazet, bcrl, serue, netdev
In-Reply-To: <m1zkzyfdob.fsf@fess.ebiederm.org>
On Mon, May 17, 2010 at 01:58:44PM -0700, Eric W. Biederman wrote:
> Greg KH <greg@kroah.com> writes:
>
> > On Sat, May 15, 2010 at 11:26:43PM -0700, David Miller wrote:
> >> From: Greg KH <greg@kroah.com>
> >> Date: Thu, 6 May 2010 13:04:04 -0700
> >>
> >> > On Tue, May 04, 2010 at 05:35:54PM -0700, Eric W. Biederman wrote:
> >> >>
> >> >> With the tagged sysfs support finally merged into Greg's tree,
> >> >> it is time for the last little bits of work to get the kobject
> >> >> layer and network namespaces to play together properly.
> >> >>
> >> >> These patches are roughly evenly divided between network layer work
> >> >> and sysfs layer work. Last time this conundrum came up I believe
> >> >> we decided that the easiest way to handle this was for Greg to carry
> >> >> all of the patches. David, Greg does that still make sense?
> >> >
> >> > That's fine, if I get David's ack on these.
> >>
> >> Looks good to me:
> >>
> >> Acked-by: David S. Miller <davem@davemloft.net>
> >
> > Ok. Eric, can you resend these to me when .35-rc1 is out so I can queue
> > them up then to get some testing in linux-next so that they can make it
> > into .36?
>
> Grumble. Grumble. Grumble.
>
> If I must I will resend these, but these patches are already in
> production use, and I had them to you weeks before the merge window
> closed.
Yes, but they were not reviewed by the network maintainer until after
the merge window closed. I already have your sysfs-namespace patches
queued up for .35, and that's a big enough change for me to feel
comfortable with at the moment.
> Is there no way we can get these in for 2.6.35?
No, sorry. One thing at a time please.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH 0/6] netns support in the kobject layer
From: Eric W. Biederman @ 2010-05-17 20:58 UTC (permalink / raw)
To: Greg KH
Cc: David Miller, gregkh, kay.sievers, linux-kernel, tj,
cornelia.huck, eric.dumazet, bcrl, serue, netdev
In-Reply-To: <20100517181133.GB18721@kroah.com>
Greg KH <greg@kroah.com> writes:
> On Sat, May 15, 2010 at 11:26:43PM -0700, David Miller wrote:
>> From: Greg KH <greg@kroah.com>
>> Date: Thu, 6 May 2010 13:04:04 -0700
>>
>> > On Tue, May 04, 2010 at 05:35:54PM -0700, Eric W. Biederman wrote:
>> >>
>> >> With the tagged sysfs support finally merged into Greg's tree,
>> >> it is time for the last little bits of work to get the kobject
>> >> layer and network namespaces to play together properly.
>> >>
>> >> These patches are roughly evenly divided between network layer work
>> >> and sysfs layer work. Last time this conundrum came up I believe
>> >> we decided that the easiest way to handle this was for Greg to carry
>> >> all of the patches. David, Greg does that still make sense?
>> >
>> > That's fine, if I get David's ack on these.
>>
>> Looks good to me:
>>
>> Acked-by: David S. Miller <davem@davemloft.net>
>
> Ok. Eric, can you resend these to me when .35-rc1 is out so I can queue
> them up then to get some testing in linux-next so that they can make it
> into .36?
Grumble. Grumble. Grumble.
If I must I will resend these, but these patches are already in
production use, and I had them to you weeks before the merge window
closed.
Is there no way we can get these in for 2.6.35?
Eric
^ permalink raw reply
* Re: TCP-MD5 checksum failure on x86_64 SMP
From: Stephen Hemminger @ 2010-05-17 20:42 UTC (permalink / raw)
To: Eric Dumazet
Cc: Bijay Singh, David Miller, <bhaskie@gmail.com>,
<bhutchings@solarflare.com>, netdev, Ilpo Järvinen
In-Reply-To: <1274072629.2299.58.camel@edumazet-laptop>
On Mon, 17 May 2010 07:03:49 +0200
Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Le lundi 17 mai 2010 à 03:49 +0000, Bijay Singh a écrit :
>
> > I am on quite an old kernel 2.6.27 and could not apply your patches.
> >
> > Then i moved on to the kernel 2.6.32.11 however since then I have not been able to bring up my card, this is something i need to fix before i can test you fix. Working on that.
> >
>
> Thanks again for the status report.
>
> I see bug is older than what I stated in my previous mail
>
> I could reproduce it in my lab and confirm following patch fixes it
>
> This is a stable candidate (2.6.27 kernels)
>
> Thanks
>
> [PATCH] tcp: tcp_synack_options() fix
>
> Commit 33ad798c924b4a (tcp: options clean up) introduced a problem
> if MD5+SACK+timestamps were used in initial SYN message.
>
> Some stacks (old linux for example) try to negotiate MD5+SACK+TSTAMP
> sessions, but since 20 bytes of tcp options space are not enough to
> store all the bits needed, we chose to disable timestamps in this case.
>
> We send a SYN-ACK _without_ timestamp option, but socket has timestamps
> enabled and all further outgoing messages contain a TS block, all with
> the initial timestamp of the remote peer.
>
> Fix is to really disable timestamps option for the whole session.
>
> Reported-by: Bijay Singh <Bijay.Singh@guavus.com>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
> ---
> net/ipv4/tcp_output.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
> diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
> index 0dda86e..b8bb226 100644
> --- a/net/ipv4/tcp_output.c
> +++ b/net/ipv4/tcp_output.c
> @@ -667,7 +667,7 @@ static unsigned tcp_synack_options(struct sock *sk,
> u8 cookie_plus = (xvp != NULL && !xvp->cookie_out_never) ?
> xvp->cookie_plus :
> 0;
> - bool doing_ts = ireq->tstamp_ok;
> + bool doing_ts;
>
> #ifdef CONFIG_TCP_MD5SIG
> *md5 = tcp_rsk(req)->af_specific->md5_lookup(sk, req);
> @@ -680,11 +680,12 @@ static unsigned tcp_synack_options(struct sock *sk,
> * rather than TS in order to fit in better with old,
> * buggy kernels, but that was deemed to be unnecessary.
> */
> - doing_ts &= !ireq->sack_ok;
> + ireq->tstamp_ok &= !ireq->sack_ok;
> }
> #else
> *md5 = NULL;
> #endif
> + doing_ts = ireq->tstamp_ok;
>
> /* We always send an MSS option. */
> opts->mss = mss;
>
>
Since you are doing away with flag variable, why not this instead?
--- a/net/ipv4/tcp_output.c 2010-05-17 13:38:32.822025583 -0700
+++ b/net/ipv4/tcp_output.c 2010-05-17 13:41:47.321734775 -0700
@@ -668,7 +668,6 @@ static unsigned tcp_synack_options(struc
u8 cookie_plus = (xvp != NULL && !xvp->cookie_out_never) ?
xvp->cookie_plus :
0;
- bool doing_ts = ireq->tstamp_ok;
#ifdef CONFIG_TCP_MD5SIG
*md5 = tcp_rsk(req)->af_specific->md5_lookup(sk, req);
@@ -681,7 +680,7 @@ static unsigned tcp_synack_options(struc
* rather than TS in order to fit in better with old,
* buggy kernels, but that was deemed to be unnecessary.
*/
- doing_ts &= !ireq->sack_ok;
+ ireq->tstamp_ok &= !ireq->sack_ok;
}
#else
*md5 = NULL;
@@ -696,7 +695,7 @@ static unsigned tcp_synack_options(struc
opts->options |= OPTION_WSCALE;
remaining -= TCPOLEN_WSCALE_ALIGNED;
}
- if (likely(doing_ts)) {
+ if (likely(ireq->tstamp_ok)) {
opts->options |= OPTION_TS;
opts->tsval = TCP_SKB_CB(skb)->when;
opts->tsecr = req->ts_recent;
@@ -704,7 +703,7 @@ static unsigned tcp_synack_options(struc
}
if (likely(ireq->sack_ok)) {
opts->options |= OPTION_SACK_ADVERTISE;
- if (unlikely(!doing_ts))
+ if (unlikely(!ireq->tstamp_ok))
remaining -= TCPOLEN_SACKPERM_ALIGNED;
}
@@ -712,7 +711,7 @@ static unsigned tcp_synack_options(struc
* If the <SYN> options fit, the same options should fit now!
*/
if (*md5 == NULL &&
- doing_ts &&
+ ireq->tstamp_ok &&
cookie_plus > TCPOLEN_COOKIE_BASE) {
int need = cookie_plus; /* has TCPOLEN_COOKIE_BASE */
--
^ permalink raw reply
* Re: iproute2 issue with adding rules.
From: Ben Greear @ 2010-05-17 20:34 UTC (permalink / raw)
To: Chris Wright; +Cc: NetDev
In-Reply-To: <20100517203004.GD8301@sequoia.sous-sol.org>
On 05/17/2010 01:30 PM, Chris Wright wrote:
> * Ben Greear (greearb@candelatech.com) wrote:
>> On 05/17/2010 01:13 PM, Ben Greear wrote:
>>> On 05/17/2010 12:03 PM, Ben Greear wrote:
>>>> On older releases, you can do this with iproute:
>>>>
>>>> # ip ru add from 9.9.9.2/32 table 226 pref 400
>>>> #
>>>>
>>>> But, in latest git, it returns an error:
>>>> # ip ru add from 9.9.9.2/32 table 226 pref 400
>>>> Error: an inet prefix is expected rather than "9.9.9.2/32".
>>>>
>>>> Is that on purpose?
>>>
>>> I was thinking maybe this was a library issue, since I compiled
>>> on one machine and ran the 'ip' exe on another. So, I tried compiling
>>> on the test system.
>>
>> I'm not thinking too well today, but this patch fixes the compile.
>> No idea if it's actually correct code.
>
> Needs more changes than that patch.
Ok, I'll try going back a few commits to find something that compiles
w/out my hacks.
Also, the rule addition does work..make install put ip in
a different place than it's installed in fedora, so I wasn't
actually running the latest code when I first tried to add
the rule.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: iproute2 issue with adding rules.
From: Chris Wright @ 2010-05-17 20:30 UTC (permalink / raw)
To: Ben Greear; +Cc: NetDev
In-Reply-To: <4BF1A6D1.70507@candelatech.com>
* Ben Greear (greearb@candelatech.com) wrote:
> On 05/17/2010 01:13 PM, Ben Greear wrote:
> >On 05/17/2010 12:03 PM, Ben Greear wrote:
> >>On older releases, you can do this with iproute:
> >>
> >># ip ru add from 9.9.9.2/32 table 226 pref 400
> >>#
> >>
> >>But, in latest git, it returns an error:
> >># ip ru add from 9.9.9.2/32 table 226 pref 400
> >>Error: an inet prefix is expected rather than "9.9.9.2/32".
> >>
> >>Is that on purpose?
> >
> >I was thinking maybe this was a library issue, since I compiled
> >on one machine and ran the 'ip' exe on another. So, I tried compiling
> >on the test system.
>
> I'm not thinking too well today, but this patch fixes the compile.
> No idea if it's actually correct code.
Needs more changes than that patch.
thanks,
-chris
^ permalink raw reply
* Re: iproute2 issue with adding rules.
From: Ben Greear @ 2010-05-17 20:28 UTC (permalink / raw)
To: NetDev
In-Reply-To: <4BF1A352.5020500@candelatech.com>
On 05/17/2010 01:13 PM, Ben Greear wrote:
> On 05/17/2010 12:03 PM, Ben Greear wrote:
>> On older releases, you can do this with iproute:
>>
>> # ip ru add from 9.9.9.2/32 table 226 pref 400
>> #
>>
>> But, in latest git, it returns an error:
>> # ip ru add from 9.9.9.2/32 table 226 pref 400
>> Error: an inet prefix is expected rather than "9.9.9.2/32".
>>
>> Is that on purpose?
>
> I was thinking maybe this was a library issue, since I compiled
> on one machine and ran the 'ip' exe on another. So, I tried compiling
> on the test system.
I'm not thinking too well today, but this patch fixes the compile.
No idea if it's actually correct code.
Still can't add the rule like I was trying...but at least it's probably
not an issue with libraries:
[root@ct503-10G-09 iproute2]# git diff
diff --git a/ip/ipaddress.c b/ip/ipaddress.c
index 48f7b1e..4d4481a 100644
--- a/ip/ipaddress.c
+++ b/ip/ipaddress.c
@@ -331,13 +331,13 @@ int print_linkinfo(const struct sockaddr_nl *who,
);
}
}
- if (do_link && tb[IFLA_VFINFO] && tb[IFLA_NUM_VF]) {
+ if (do_link && tb[IFLA_VFINFO_LIST] && tb[IFLA_NUM_VF]) {
SPRINT_BUF(b1);
- struct rtattr *rta = tb[IFLA_VFINFO];
+ struct rtattr *rta = tb[IFLA_VFINFO_LIST];
struct ifla_vf_info *ivi;
int i;
for (i = 0; i < *(int *)RTA_DATA(tb[IFLA_NUM_VF]); i++) {
- if (rta->rta_type != IFLA_VFINFO) {
+ if (rta->rta_type != IFLA_VFINFO_LIST) {
fprintf(stderr, "BUG: rta type is %d\n", rta->rta_type);
break;
}
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply related
* Re: iproute2 issue with adding rules.
From: Stephen Hemminger @ 2010-05-17 20:27 UTC (permalink / raw)
To: Ben Greear; +Cc: NetDev
In-Reply-To: <4BF1A352.5020500@candelatech.com>
On Mon, 17 May 2010 13:13:06 -0700
Ben Greear <greearb@candelatech.com> wrote:
> On 05/17/2010 12:03 PM, Ben Greear wrote:
> > On older releases, you can do this with iproute:
> >
> > # ip ru add from 9.9.9.2/32 table 226 pref 400
> > #
> >
> > But, in latest git, it returns an error:
> > # ip ru add from 9.9.9.2/32 table 226 pref 400
> > Error: an inet prefix is expected rather than "9.9.9.2/32".
> >
> > Is that on purpose?
>
> I was thinking maybe this was a library issue, since I compiled
> on one machine and ran the 'ip' exe on another. So, I tried compiling
> on the test system.
>
> But, iproute will not compile, apparently because it finds the
> /usr/include/linux header files before whatever is packaged with
> iproute:
>
> gcc -D_GNU_SOURCE -O2 -Wstrict-prototypes -Wall -I../include -DRESOLVE_HOSTNAMES -DLIBDIR=\"/usr/lib/\" -c -o ipaddress.o ipaddress.c
> ipaddress.c: In function ‘print_linkinfo’:
> ipaddress.c:334: error: ‘IFLA_VFINFO’ undeclared (first use in this function)
> ipaddress.c:334: error: (Each undeclared identifier is reported only once
> ipaddress.c:334: error: for each function it appears in.)
> make[1]: *** [ipaddress.o] Error 1
> make[1]: Leaving directory `/root/git/iproute2/ip'
> make: *** [all] Error 2
>
>
> I tried moving /usr/include/linux out of the way, but then it blows up
> even worse (can't find errno.h, etc)
>
> Are we supposed to be able to compile iproute2 on a system with moderately
> outdated kernel headers?
>
> If not, why bother with the iproute/include/linux directory at all?
The issue is the last minute VF changes in 2.6.34 are not supported
in iproute util yet. Please wait until it is fixed.
^ permalink raw reply
* [PATCH v2] Fix SJA1000 command register writes on SMP systems
From: Oliver Hartkopp @ 2010-05-17 20:17 UTC (permalink / raw)
To: David Miller
Cc: SocketCAN Core Mailing List, Linux Netdev List,
Wolfgang Grandegger
The SJA1000 command register is concurrently written in the rx-path to free
the receive buffer _and_ in the tx-path to start the transmission.
The SJA1000 data sheet, 6.4.4 COMMAND REGISTER (CMR) states:
"Between two commands at least one internal clock cycle is needed in
order to proceed. The internal clock is half of the external oscillator
frequency."
On SMP systems this leads to a write stall in the tx-path, which can be
solved by adding some locking for the command register in the SMP case.
In this special case we also read the status register to settle the command
register write.
Thanks to Klaus Hitschler for the original fix and detailed problem
description.
This patch applies on net-2.6 and (with some offsets) on net-next-2.6 .
Signed-off-by: Oliver Hartkopp <socketcan-fJ+pQTUTwRTk1uMJSBkQmQ@public.gmane.org>
Acked-by: Wolfgang Grandegger <wg-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>
---
diff --git a/drivers/net/can/sja1000/sja1000.c b/drivers/net/can/sja1000/sja1000.c
index 145b1a7..2760085 100644
--- a/drivers/net/can/sja1000/sja1000.c
+++ b/drivers/net/can/sja1000/sja1000.c
@@ -84,6 +84,27 @@ static struct can_bittiming_const sja1000_bittiming_const = {
.brp_inc = 1,
};
+static void sja1000_write_cmdreg(struct sja1000_priv *priv, u8 val)
+{
+ /* the command register needs some locking on SMP systems */
+
+#ifdef CONFIG_SMP
+
+ unsigned long flags;
+
+ spin_lock_irqsave(&priv->cmdreg_lock, flags);
+ priv->write_reg(priv, REG_CMR, val);
+ priv->read_reg(priv, REG_SR);
+ spin_unlock_irqrestore(&priv->cmdreg_lock, flags);
+
+#else
+
+ /* write to the command register without locking */
+ priv->write_reg(priv, REG_CMR, val);
+
+#endif
+}
+
static int sja1000_probe_chip(struct net_device *dev)
{
struct sja1000_priv *priv = netdev_priv(dev);
@@ -297,7 +318,7 @@ static netdev_tx_t sja1000_start_xmit(struct sk_buff *skb,
can_put_echo_skb(skb, dev, 0);
- priv->write_reg(priv, REG_CMR, CMD_TR);
+ sja1000_write_cmdreg(priv, CMD_TR);
return NETDEV_TX_OK;
}
@@ -346,7 +367,7 @@ static void sja1000_rx(struct net_device *dev)
cf->can_id = id;
/* release receive buffer */
- priv->write_reg(priv, REG_CMR, CMD_RRB);
+ sja1000_write_cmdreg(priv, CMD_RRB);
netif_rx(skb);
@@ -374,7 +395,7 @@ static int sja1000_err(struct net_device *dev, uint8_t isrc, uint8_t status)
cf->data[1] = CAN_ERR_CRTL_RX_OVERFLOW;
stats->rx_over_errors++;
stats->rx_errors++;
- priv->write_reg(priv, REG_CMR, CMD_CDO); /* clear bit */
+ sja1000_write_cmdreg(priv, CMD_CDO); /* clear bit */
}
if (isrc & IRQ_EI) {
diff --git a/drivers/net/can/sja1000/sja1000.h b/drivers/net/can/sja1000/sja1000.h
index 97a622b..4527d95 100644
--- a/drivers/net/can/sja1000/sja1000.h
+++ b/drivers/net/can/sja1000/sja1000.h
@@ -168,6 +168,10 @@ struct sja1000_priv {
void __iomem *reg_base; /* ioremap'ed address to registers */
unsigned long irq_flags; /* for request_irq() */
+#ifdef CONFIG_SMP
+ spinlock_t cmdreg_lock; /* lock for concurrent cmd register writes */
+#endif
+
u16 flags; /* custom mode flags */
u8 ocr; /* output control register */
u8 cdr; /* clock divider register */
^ permalink raw reply related
* Re: iproute2 issue with adding rules.
From: Ben Greear @ 2010-05-17 20:13 UTC (permalink / raw)
To: NetDev
In-Reply-To: <4BF192F9.8000008@candelatech.com>
On 05/17/2010 12:03 PM, Ben Greear wrote:
> On older releases, you can do this with iproute:
>
> # ip ru add from 9.9.9.2/32 table 226 pref 400
> #
>
> But, in latest git, it returns an error:
> # ip ru add from 9.9.9.2/32 table 226 pref 400
> Error: an inet prefix is expected rather than "9.9.9.2/32".
>
> Is that on purpose?
I was thinking maybe this was a library issue, since I compiled
on one machine and ran the 'ip' exe on another. So, I tried compiling
on the test system.
But, iproute will not compile, apparently because it finds the
/usr/include/linux header files before whatever is packaged with
iproute:
gcc -D_GNU_SOURCE -O2 -Wstrict-prototypes -Wall -I../include -DRESOLVE_HOSTNAMES -DLIBDIR=\"/usr/lib/\" -c -o ipaddress.o ipaddress.c
ipaddress.c: In function ‘print_linkinfo’:
ipaddress.c:334: error: ‘IFLA_VFINFO’ undeclared (first use in this function)
ipaddress.c:334: error: (Each undeclared identifier is reported only once
ipaddress.c:334: error: for each function it appears in.)
make[1]: *** [ipaddress.o] Error 1
make[1]: Leaving directory `/root/git/iproute2/ip'
make: *** [all] Error 2
I tried moving /usr/include/linux out of the way, but then it blows up
even worse (can't find errno.h, etc)
Are we supposed to be able to compile iproute2 on a system with moderately
outdated kernel headers?
If not, why bother with the iproute/include/linux directory at all?
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [PATCH] Fix SJA1000 command register writes on SMP systems
From: Wolfgang Grandegger @ 2010-05-17 20:04 UTC (permalink / raw)
To: Oliver Hartkopp
Cc: SocketCAN Core Mailing List, Linux Netdev List, David Miller,
stable-DgEjT+Ai2ygdnm+yROfE0A
In-Reply-To: <4BF19D5B.1070604-fJ+pQTUTwRTk1uMJSBkQmQ@public.gmane.org>
On 05/17/2010 09:47 PM, Oliver Hartkopp wrote:
> On 17.05.2010 16:29, Wolfgang Grandegger wrote:
>> Hi Oliver,
>>
>> On 05/17/2010 01:06 PM, Oliver Hartkopp wrote:
>>> The SJA1000 command register is concurrently written in the rx-path to free
>>> the receive buffer _and_ in the tx-path to start the transmission.
>>> On SMP systems this leads to a write stall in the tx-path, which can be
>>> solved by adding some locking for the command register in the SMP case.
>>
>> We should explain why a write stall can happen. Here is the relavant
>> part from the SJA1000 data sheet, 6.4.4 COMMAND REGISTER (CMR):
>>
>> "Between two commands at least one internal clock cycle is needed in
>> order to proceed. The internal clock is half of the external oscillator
>> frequency."
>
> The delay directly after the register access can only be guaranteed when there
> is some locking around the command register write access.
Of course.
> In the end it boils down to a SMP issue again as this is (from all known
> environments) the only case, where the problem appears in reality.
> This was also what i've taken from the discussion on the SocketCAN ML.
I know.
> I don't stick on the patch description. Would you like to produce a different
> one? My Acked-by for the code remains sure :-)
I just suggested to mention the hardware requirements in the patch
description so people can understand why we need it. Feel free to add
what I wrote above.
Wolfgang.
^ permalink raw reply
* [PATCH] netfilter: fix description of expected checkentry return code on xt_target
From: Luciano Coelho @ 2010-05-17 20:00 UTC (permalink / raw)
To: netfilter-devel, netdev; +Cc: kaber
The text describing the return codes that are expected on calls to
checkentry() was incorrect. Instead of returning true or false, or an error
code, it should return 0 or an error code.
Signed-off-by: Luciano Coelho <luciano.coelho@nokia.com>
---
include/linux/netfilter/x_tables.h | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/include/linux/netfilter/x_tables.h b/include/linux/netfilter/x_tables.h
index c2ee5d8..c00cc0c 100644
--- a/include/linux/netfilter/x_tables.h
+++ b/include/linux/netfilter/x_tables.h
@@ -333,7 +333,7 @@ struct xt_target {
/* Called when user tries to insert an entry of this type:
hook_mask is a bitmask of hooks from which it can be
called. */
- /* Should return true or false, or an error code (-Exxxx). */
+ /* Should return 0 on success or an error code otherwise (-Exxxx). */
int (*checkentry)(const struct xt_tgchk_param *);
/* Called when entry of this type deleted. */
--
1.6.3.3
^ permalink raw reply related
* Re: [PATCH] Fix SJA1000 command register writes on SMP systems
From: Oliver Hartkopp @ 2010-05-17 19:47 UTC (permalink / raw)
To: Wolfgang Grandegger
Cc: SocketCAN Core Mailing List, Linux Netdev List, David Miller,
stable-DgEjT+Ai2ygdnm+yROfE0A
In-Reply-To: <4BF152E4.1060306-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>
On 17.05.2010 16:29, Wolfgang Grandegger wrote:
> Hi Oliver,
>
> On 05/17/2010 01:06 PM, Oliver Hartkopp wrote:
>> The SJA1000 command register is concurrently written in the rx-path to free
>> the receive buffer _and_ in the tx-path to start the transmission.
>> On SMP systems this leads to a write stall in the tx-path, which can be
>> solved by adding some locking for the command register in the SMP case.
>
> We should explain why a write stall can happen. Here is the relavant
> part from the SJA1000 data sheet, 6.4.4 COMMAND REGISTER (CMR):
>
> "Between two commands at least one internal clock cycle is needed in
> order to proceed. The internal clock is half of the external oscillator
> frequency."
The delay directly after the register access can only be guaranteed when there
is some locking around the command register write access.
In the end it boils down to a SMP issue again as this is (from all known
environments) the only case, where the problem appears in reality.
This was also what i've taken from the discussion on the SocketCAN ML.
I don't stick on the patch description. Would you like to produce a different
one? My Acked-by for the code remains sure :-)
Regards,
Oliver
^ permalink raw reply
* Re: [PATCH net-next-2.6 2/2] bonding: allow user-controlled output slave selection
From: Jay Vosburgh @ 2010-05-17 19:25 UTC (permalink / raw)
To: Neil Horman; +Cc: Andy Gospodarek, netdev
In-Reply-To: <20100517184508.GD17419@hmsreliant.think-freely.org>
Neil Horman <nhorman@tuxdriver.com> wrote:
>Neil Horman <nhorman@tuxdriver.com> wrote:
>> So, its sounding to me like everyone is leaning toward a new mode approach here.
>> Before we go ahead and start coding, I hear the bullet points for this approach
>> as:
>>
>> 1) Implement a new bond mode where queue ids are used to steer frames to output
>> interfaces
>>
>> 2) Use said mode to imply universal frame reception (i.e. remove the keep_all
>> knob, and turn on that behavior when this new mode is selected)
>>
>> 3) use John F.'s skb_should_drop changes to implement the keep_all feature.
>>
>> Does that sound about right?
>>
>> Regards
>> Neil
>>
>Ping, Jay, any feedback on these bullet points. I'd like to keep working on
>this while we have the time, but I'd rather not play guess & check on the list
>here any more than we need to.
I've been thinking on this and trying some variations.
After further discussion with John Fastabend, I don't think a
new mode is warranted for this particular work, largely because the FCOE
case wants to run under essentially any mode (the magic FCOE switches
don't care, they just divert the FC traffic regardless of the switch
port settings). Perhaps some specific multi-queue gizmo will become a
new mode down the road.
Part of my thinking for originally wanting a new mode was that
your changes didn't expose the slave device queues, but after further
discussion, that isn't actually the case.
I thought about removing the whole special case for "deliver to
direct bindings" and have a switch instead to always deliver to
everybody. In the end, I don't think that would end up making things
much simpler, because the special cases have to stay for the "normal"
inactive slave behavior to pass the ARP, ARP-over-VLAN, ETH_P_SLOW, etc
traffic. It also would come at the cost of disabling the duplicate
suppressor for the FCOE case, and I don't think that's what they want.
I'm thinking right now to go with more or less the three patch
series that John Fastabend posted last week, along with a variant of
your patch. As much as I'd like to do both things as a unified patch,
doing so just doesn't seem to simplify the existing code, and ends up
being less than optimal for both cases.
For John's patches, a few minor changes, but that basic idea
(flag in the skb); I'm still chewing on the "VLAN don't copy IFF_MASTER
or SLAVE flag" patch though, just to make sure it won't break anything,
but I don't think it's a critical change.
For your patch, I'm exploring the idea of not setting
IFF_SLAVE_INACTIVE on "inactive" slaves for an "all_slaves_active"
option (I think that's a more descriptive name than "keep_all") instead
of adding a new KEEP_ALL flag bit to priv_flags. Did you consider this
methodology and exclude it for some reason?
Hopefully there won't be any pushback against using a flag bit
in the skb. I haven't thought of a way to do what's desired in an
efficient manner without storing state in the skb somewhere. The
skb->skb_iif does hold the original device receiving the skb, but I have
to believe that converting that to a struct net_device * (for the
"direct bind to original slave" case) in __netif_receive_skb is more
expensive that stashing a flag in the skb.
-J
---
-Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com
^ permalink raw reply
* Kernel crash with sky2
From: Joerg Roedel @ 2010-05-17 18:52 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev
Hi Stephen,
I experience the following crash with 2.6.34 in the sky2 code on my
laptop when I plug off the lan-cable and then plug-off the power cable
and switching to battery. It does not happen with acpi=off.
I havn't tested earlier kernels but I can do that if necessary. I did
some initial research and found that the driver assumes that port[1] is
available when the status bits for it are set on the device. Please let
me know if you need any additional information or want me to test
anything.
The crash message is:
[ 107.010134] sky2 0000:02:00.0: PCI hardware error (0xffff)
[ 107.015614] sky2 0000:02:00.0: PCI Express error (0xffffffff)
[ 107.021355] sky2 0000:02:00.0: eth0: ram data read parity error
[ 107.027249] sky2 0000:02:00.0: eth0: ram data write parity error
[ 107.033253] sky2 0000:02:00.0: eth0: MAC parity error
[ 107.038283] sky2 0000:02:00.0: eth0: RX parity error
[ 107.043259] sky2 0000:02:00.0: eth0: TCP segmentation error
[ 107.048823] BUG: unable to handle kernel NULL pointer dereference at 0000000000000438
[ 107.053238] IP: [<ffffffffa0001713>] sky2_hw_error+0x153/0x310 [sky2]
[ 107.053238] PGD 139600067 PUD 139643067 PMD 0
[ 107.053238] Oops: 0000 [#1] SMP
[ 107.053238] last sysfs file: /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
[ 107.053238] CPU 1
[ 107.053238] Modules linked in: snd_hda_codec_atihdmi snd_hda_codec_idt snd_hda_intel rfcomm snd_pcm_oss snd_hda_2
[ 107.053238]
[ 107.053238] Pid: 7, comm: ksoftirqd/1 Not tainted 2.6.34-default #1 307E/HP ProBook 6545b
[ 107.053238] RIP: 0010:[<ffffffffa0001713>] [<ffffffffa0001713>] sky2_hw_error+0x153/0x310 [sky2]
[ 107.053238] RSP: 0018:ffff880001e83d78 EFLAGS: 00010202
[ 107.053238] RAX: 0000000000000001 RBX: 0000000000ffffff RCX: 00000000000001f4
[ 107.053238] RDX: 000000000000000a RSI: 0000000000000202 RDI: ffffffff81a5dc80
[ 107.053238] RBP: ffff880001e83db8 R08: 00000000ffffffff R09: 0000000000000000
[ 107.053238] R10: 0000000000000000 R11: 0000000000000001 R12: ffff88012862da00
[ 107.053238] R13: 0000000000000001 R14: 0000000000000001 R15: 0000000000000000
[ 107.053238] FS: 00007ff07987b800(0000) GS:ffff880001e80000(0000) knlGS:0000000000000000
[ 107.053238] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[ 107.053238] CR2: 0000000000000438 CR3: 0000000139641000 CR4: 00000000000006e0
[ 107.053238] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 107.053238] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[ 107.053238] Process ksoftirqd/1 (pid: 7, threadinfo ffff88013badc000, task ffff88013bad1700)
[ 107.053238] Stack:
[ 107.053238] ffff88013b488b00 ffff8801284f7000 00000a8800000ad7 00000000ffffffff
[ 107.053238] <0> ffff88012862da00 00000000ffffffff ffff88013b4d1000 ffff88013b488b00
[ 107.053238] <0> ffff880001e83ed8 ffffffffa000720f 0000000000000082 0000000000000000
[ 107.053238] Call Trace:
[ 107.053238] <IRQ>
[ 107.053238] [<ffffffffa000720f>] sky2_poll+0xeef/0x1020 [sky2]
[ 107.053238] [<ffffffff8101e1bb>] ? lapic_timer_broadcast+0x1b/0x20
[ 107.053238] [<ffffffff8106a76f>] ? __queue_work+0x3f/0x50
[ 107.053238] [<ffffffff8106a7b9>] ? delayed_work_timer_fn+0x39/0x50
[ 107.053238] [<ffffffff8142bffd>] net_rx_action+0xed/0x1f0
[ 107.053238] [<ffffffff81057250>] __do_softirq+0xb0/0x1d0
[ 107.053238] [<ffffffff81003e4c>] call_softirq+0x1c/0x30
[ 107.053238] <EOI>
[ 107.053238] [<ffffffff810058b5>] ? do_softirq+0x55/0x90
[ 107.053238] [<ffffffff81056dd0>] run_ksoftirqd+0x80/0x130
[ 107.053238] [<ffffffff81056d50>] ? run_ksoftirqd+0x0/0x130
[ 107.053238] [<ffffffff8106e8e6>] kthread+0x96/0xa0
[ 107.053238] [<ffffffff81003d54>] kernel_thread_helper+0x4/0x10
[ 107.053238] [<ffffffff8106e850>] ? kthread+0x0/0xa0
[ 107.053238] [<ffffffff81003d50>] ? kernel_thread_helper+0x0/0x10
[ 107.053238] Code: e8 d3 a7 43 e1 85 c0 0f 85 f5 00 00 00 44 89 f0 ba 00 02 00 00 c1 e0 06 0d a0 01 00 00 89 c0 4
[ 107.053238] RIP [<ffffffffa0001713>] sky2_hw_error+0x153/0x310 [sky2]
[ 107.053238] RSP <ffff880001e83d78>
[ 107.053238] CR2: 0000000000000438
[ 107.392268] ---[ end trace 8a4d942e73cd8681 ]---
[ 107.396866] Kernel panic - not syncing: Fatal exception in interrupt
[ 107.403214] Pid: 7, comm: ksoftirqd/1 Tainted: G D 2.6.34-default #1
[ 107.410230] Call Trace:
[ 107.412695] <IRQ> [<ffffffff8150d49d>] panic+0x7d/0xf7
[ 107.418004] [<ffffffff81511502>] oops_end+0xe2/0xf0
[ 107.422970] [<ffffffff8102dd6b>] no_context+0xfb/0x260
[ 107.428174] [<ffffffff8102dfdd>] __bad_area_nosemaphore+0x10d/0x1c0
[ 107.434523] [<ffffffff8102e0a3>] bad_area_nosemaphore+0x13/0x20
[ 107.440513] [<ffffffff81513aaf>] do_page_fault+0x26f/0x330
[ 107.446084] [<ffffffff815108df>] page_fault+0x1f/0x30
[ 107.451202] [<ffffffffa0001713>] ? sky2_hw_error+0x153/0x310 [sky2]
[ 107.457554] [<ffffffffa00015f6>] ? sky2_hw_error+0x36/0x310 [sky2]
[ 107.463811] [<ffffffffa000720f>] sky2_poll+0xeef/0x1020 [sky2]
[ 107.469706] [<ffffffff8101e1bb>] ? lapic_timer_broadcast+0x1b/0x20
[ 107.475980] [<ffffffff8106a76f>] ? __queue_work+0x3f/0x50
[ 107.481457] [<ffffffff8106a7b9>] ? delayed_work_timer_fn+0x39/0x50
[ 107.487698] [<ffffffff8142bffd>] net_rx_action+0xed/0x1f0
[ 107.493183] [<ffffffff81057250>] __do_softirq+0xb0/0x1d0
[ 107.498558] [<ffffffff81003e4c>] call_softirq+0x1c/0x30
[ 107.503868] <EOI> [<ffffffff810058b5>] ? do_softirq+0x55/0x90
[ 107.509788] [<ffffffff81056dd0>] run_ksoftirqd+0x80/0x130
[ 107.515275] [<ffffffff81056d50>] ? run_ksoftirqd+0x0/0x130
[ 107.520823] [<ffffffff8106e8e6>] kthread+0x96/0xa0
[ 107.525702] [<ffffffff81003d54>] kernel_thread_helper+0x4/0x10
[ 107.531612] [<ffffffff8106e850>] ? kthread+0x0/0xa0
[ 107.536563] [<ffffffff81003d50>] ? kernel_thread_helper+0x0/0x10
[ 107.542657] [drm:drm_fb_helper_panic] *ERROR* panic occurred, switching back to text console
[ 107.551054] BUG: scheduling while atomic: ksoftirqd/1/7/0x10000100
[ 107.552642] Modules linked in: snd_hda_codec_atihdmi snd_hda_codec_idt snd_hda_intel rfcomm snd_pcm_oss snd_hda_2
[ 107.552642] Pid: 7, comm: ksoftirqd/1 Tainted: G D 2.6.34-default #1
[ 107.552642] Call Trace:
[ 107.552642] <IRQ> [<ffffffff810402d1>] __schedule_bug+0x61/0x70
[ 107.552642] [<ffffffff8150ddec>] schedule+0x6cc/0x800
[ 107.552642] [<ffffffff8104c8ba>] __cond_resched+0x2a/0x40
[ 107.552642] [<ffffffff8150e020>] _cond_resched+0x30/0x40
[ 107.552642] [<ffffffff8111e241>] __kmalloc+0xc1/0x190
[ 107.552642] [<ffffffffa00b5613>] ? T.687+0x13/0x20 [drm_kms_helper]
[ 107.552642] [<ffffffffa00b5613>] T.687+0x13/0x20 [drm_kms_helper]
[ 107.552642] [<ffffffffa00b5707>] drm_crtc_helper_set_config+0xe7/0x880 [drm_kms_helper]
[ 107.552642] [<ffffffffa00b35d4>] drm_fb_helper_force_kernel_mode+0x74/0xa0 [drm_kms_helper]
[ 107.552642] [<ffffffffa00b3663>] drm_fb_helper_panic+0x23/0x30 [drm_kms_helper]
[ 107.552642] [<ffffffff81513bc6>] notifier_call_chain+0x56/0x80
[ 107.552642] [<ffffffff81513c2a>] atomic_notifier_call_chain+0x1a/0x20
[ 107.552642] [<ffffffff8150d4c9>] panic+0xa9/0xf7
[ 107.552642] [<ffffffff81511502>] oops_end+0xe2/0xf0
[ 107.552642] [<ffffffff8102dd6b>] no_context+0xfb/0x260
[ 107.552642] [<ffffffff8102dfdd>] __bad_area_nosemaphore+0x10d/0x1c0
[ 107.552642] [<ffffffff8102e0a3>] bad_area_nosemaphore+0x13/0x20
[ 107.552642] [<ffffffff81513aaf>] do_page_fault+0x26f/0x330
[ 107.552642] [<ffffffff815108df>] page_fault+0x1f/0x30
[ 107.552642] [<ffffffffa0001713>] ? sky2_hw_error+0x153/0x310 [sky2]
[ 107.552642] [<ffffffffa00015f6>] ? sky2_hw_error+0x36/0x310 [sky2]
[ 107.552642] [<ffffffffa000720f>] sky2_poll+0xeef/0x1020 [sky2]
[ 107.552642] [<ffffffff8101e1bb>] ? lapic_timer_broadcast+0x1b/0x20
[ 107.552642] [<ffffffff8106a76f>] ? __queue_work+0x3f/0x50
[ 107.552642] [<ffffffff8106a7b9>] ? delayed_work_timer_fn+0x39/0x50
[ 107.552642] [<ffffffff8142bffd>] net_rx_action+0xed/0x1f0
[ 107.552642] [<ffffffff81057250>] __do_softirq+0xb0/0x1d0
[ 107.552642] [<ffffffff81003e4c>] call_softirq+0x1c/0x30
[ 107.552642] <EOI> [<ffffffff810058b5>] ? do_softirq+0x55/0x90
[ 107.552642] [<ffffffff81056dd0>] run_ksoftirqd+0x80/0x130
[ 107.552642] [<ffffffff81056d50>] ? run_ksoftirqd+0x0/0x130
[ 107.552642] [<ffffffff8106e8e6>] kthread+0x96/0xa0
[ 107.552642] [<ffffffff81003d54>] kernel_thread_helper+0x4/0x10
[ 107.552642] [<ffffffff8106e850>] ? kthread+0x0/0xa0
[ 107.552642] [<ffffffff81003d50>] ? kernel_thread_helper+0x0/0x10
lspci -vvv -n of the device:
02:00.0 0200: 11ab:436c (rev 10)
Subsystem: 103c:3080
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 28
Region 0: Memory at d5200000 (64-bit, non-prefetchable) [size=16K]
Region 2: I/O ports at 4000 [size=256]
Expansion ROM at d0000000 [disabled] [size=128K]
Capabilities: [48] Power Management version 3
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [50] Vital Product Data <?>
Capabilities: [5c] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable+
Address: 00000000fee0100c Data: 4189
Capabilities: [c0] Express (v2) Legacy Endpoint, MSI 00
DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s unlimited, L1 unlimited
ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
MaxPayload 128 bytes, MaxReadReq 512 bytes
DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq+ AuxPwr+ TransPend-
LnkCap: Port #1, Speed 2.5GT/s, Width x1, ASPM L0s L1, Latency L0 <256ns, L1 unlimited
ClockPM+ Suprise- LLActRep- BwNot-
LnkCtl: ASPM L0s L1 Enabled; RCB 128 bytes Disabled- Retrain- CommClk+
ExtSynch- ClockPM+ AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
Capabilities: [100] Advanced Error Reporting <?>
Capabilities: [130] Device Serial Number 70-5a-b6-ff-ff-97-a6-80
Kernel driver in use: sky2
Kernel modules: sky2
Thanks,
Joerg
^ permalink raw reply
* Re: Kernel crash with sky2
From: Stephen Hemminger @ 2010-05-17 19:22 UTC (permalink / raw)
To: Joerg Roedel; +Cc: netdev
In-Reply-To: <20100517185228.GG9007@amd.com>
On Mon, 17 May 2010 20:52:28 +0200
Joerg Roedel <joerg.roedel@amd.com> wrote:
> Hi Stephen,
>
> I experience the following crash with 2.6.34 in the sky2 code on my
> laptop when I plug off the lan-cable and then plug-off the power cable
> and switching to battery. It does not happen with acpi=off.
So you have a busted BIOS that powers off the device.
> I havn't tested earlier kernels but I can do that if necessary. I did
> some initial research and found that the driver assumes that port[1] is
> available when the status bits for it are set on the device. Please let
> me know if you need any additional information or want me to test
> anything.
The driver assumes that it won't get garbage in NAPI.
> The crash message is:
>
> [ 107.010134] sky2 0000:02:00.0: PCI hardware error (0xffff)
> [ 107.015614] sky2 0000:02:00.0: PCI Express error (0xffffffff)
> [ 107.021355] sky2 0000:02:00.0: eth0: ram data read parity error
> [ 107.027249] sky2 0000:02:00.0: eth0: ram data write parity error
> [ 107.033253] sky2 0000:02:00.0: eth0: MAC parity error
> [ 107.038283] sky2 0000:02:00.0: eth0: RX parity error
> [ 107.043259] sky2 0000:02:00.0: eth0: TCP segmentation error
> [ 107.048823] BUG: unable to handle kernel NULL pointer dereference at 0000000000000438
> [ 107.053238] IP: [<ffffffffa0001713>] sky2_hw_error+0x153/0x310 [sky2]
> [ 107.053238] PGD 139600067 PUD 139643067 PMD 0
> [ 107.053238] Oops: 0000 [#1] SMP
> [ 107.053238] last sysfs file: /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
> [ 107.053238] CPU 1
> [ 107.053238] Modules linked in: snd_hda_codec_atihdmi snd_hda_codec_idt snd_hda_intel rfcomm snd_pcm_oss snd_hda_2
> [ 107.053238]
Something in power management has turned off your device.
The fact that the sky2 driver has decided to die is unintended casulty.
This will stop the crash, but not fix the problem with PM.
As soon as it sees the device off, it will go offline until you reboot.
--- a/drivers/net/sky2.c 2010-05-17 12:09:22.721738360 -0700
+++ b/drivers/net/sky2.c 2010-05-17 12:19:52.845893670 -0700
@@ -2904,6 +2904,16 @@ static int sky2_poll(struct napi_struct
int work_done = 0;
u16 idx;
+ if (unlikely(status == ~0)) {
+ int i;
+ dev_err(&hw->pdev->dev,
+ "device no longer available (powered off?)\n");
+
+ for (i = 0; i < hw->ports; i++)
+ netif_device_detach(hw->dev[i]);
+ goto complete;
+ }
+
if (unlikely(status & Y2_IS_ERROR))
sky2_err_intr(hw, status);
@@ -2922,7 +2932,7 @@ static int sky2_poll(struct napi_struct
if (work_done >= work_limit)
goto done;
}
-
+complete:
napi_complete(napi);
sky2_read32(hw, B0_Y2_SP_LISR);
done:
--
^ 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