* Re: unsubscribe netdev
From: Peter Portante @ 2012-07-23 17:26 UTC (permalink / raw)
To: netdev
In-Reply-To: <C8E995C2-7D48-451F-8AEA-69BF2DA59F1F@redhat.com>
unsubscribe netdev
^ permalink raw reply
* Re: [PATCH 1/2] ipvs: ip_vs_ftp depends on nf_conntrack_ftp helper
From: Pablo Neira Ayuso @ 2012-07-23 17:39 UTC (permalink / raw)
To: Simon Horman
Cc: Julian Anastasov, lvs-devel, netdev, netfilter-devel,
Wensong Zhang, Hans Schillstrom, Jesper Dangaard Brouer
In-Reply-To: <20120723064818.GK6603@verge.net.au>
On Mon, Jul 23, 2012 at 03:48:18PM +0900, Simon Horman wrote:
> On Thu, Jul 12, 2012 at 10:43:22PM +0300, Julian Anastasov wrote:
> >
> > Hello,
> >
> > On Thu, 12 Jul 2012, Pablo Neira Ayuso wrote:
> >
> > > On Wed, Jul 11, 2012 at 09:25:26AM +0900, Simon Horman wrote:
> > > > From: Julian Anastasov <ja@ssi.bg>
> > > >
> > > > The FTP application indirectly depends on the
> > > > nf_conntrack_ftp helper for proper NAT support. If the
> > > > module is not loaded, IPVS can resize the packets for the
> > > > command connection, eg. PASV response but the SEQ adjustment
> > > > logic in ipv4_confirm is not called without helper.
> > > >
> > > > Signed-off-by: Julian Anastasov <ja@ssi.bg>
> > > > Signed-off-by: Simon Horman <horms@verge.net.au>
> > > > ---
> > > > net/netfilter/ipvs/Kconfig | 3 ++-
> > > > 1 file changed, 2 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/net/netfilter/ipvs/Kconfig b/net/netfilter/ipvs/Kconfig
> > > > index f987138..8b2cffd 100644
> > > > --- a/net/netfilter/ipvs/Kconfig
> > > > +++ b/net/netfilter/ipvs/Kconfig
> > > > @@ -250,7 +250,8 @@ comment 'IPVS application helper'
> > > >
> > > > config IP_VS_FTP
> > > > tristate "FTP protocol helper"
> > > > - depends on IP_VS_PROTO_TCP && NF_CONNTRACK && NF_NAT
> > > > + depends on IP_VS_PROTO_TCP && NF_CONNTRACK && NF_NAT && \
> > > > + NF_CONNTRACK_FTP
> > >
> > > If you require FTP NAT support, then this depends on NF_NAT_FTP
> > > instead of NF_CONNTRACK_FTP.
> >
> > No, I just checked again, it works without nf_nat_ftp,
> > only nf_nat, nf_conntrack_ftp and iptable_nat are needed.
> > We use packet mangling part from nf_nat (nf_nat_mangle_tcp_packet).
>
> Is there a consensus on this?
Fine with me, just wanted to make sure this what you wanted. Thanks
Simon.
^ permalink raw reply
* [net-next] net/ipv4/ip_vti.c: Fix __rcu warnings detected by sparse.
From: Saurabh @ 2012-07-23 17:52 UTC (permalink / raw)
To: netdev
With CONFIG_SPARSE_RCU_POINTER=y sparse identified references which did not
specificy __rcu in ip_vti.c
Signed-off-by: Saurabh Mohan <saurabh.mohan@vyatta.com>
Reported-by: Fengguang Wu <fengguang.wu@intel.com>
---
diff --git a/net/ipv4/ip_vti.c b/net/ipv4/ip_vti.c
index c41b5c3..3511ffb 100644
--- a/net/ipv4/ip_vti.c
+++ b/net/ipv4/ip_vti.c
@@ -55,7 +55,7 @@ struct vti_net {
struct ip_tunnel __rcu *tunnels_r[HASH_SIZE];
struct ip_tunnel __rcu *tunnels_l[HASH_SIZE];
struct ip_tunnel __rcu *tunnels_wc[1];
- struct ip_tunnel **tunnels[4];
+ struct ip_tunnel __rcu **tunnels[4];
struct net_device *fb_tunnel_dev;
};
@@ -160,8 +160,8 @@ static struct ip_tunnel *vti_tunnel_lookup(struct net *net,
return NULL;
}
-static struct ip_tunnel **__vti_bucket(struct vti_net *ipn,
- struct ip_tunnel_parm *parms)
+static struct ip_tunnel __rcu **__vti_bucket(struct vti_net *ipn,
+ struct ip_tunnel_parm *parms)
{
__be32 remote = parms->iph.daddr;
__be32 local = parms->iph.saddr;
@@ -179,8 +179,8 @@ static struct ip_tunnel **__vti_bucket(struct vti_net *ipn,
return &ipn->tunnels[prio][h];
}
-static inline struct ip_tunnel **vti_bucket(struct vti_net *ipn,
- struct ip_tunnel *t)
+static inline struct ip_tunnel __rcu **vti_bucket(struct vti_net *ipn,
+ struct ip_tunnel *t)
{
return __vti_bucket(ipn, &t->parms);
}
^ permalink raw reply related
* Re: [PATCH 00/16] Remove the ipv4 routing cache
From: Paweł Staszewski @ 2012-07-23 17:54 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, netdev
In-Reply-To: <1343027752.2626.10175.camel@edumazet-glaptop>
W dniu 2012-07-23 09:15, Eric Dumazet pisze:
> On Sun, 2012-07-22 at 17:39 -0700, David Miller wrote:
>> Just FYI, I'm pushing this work out to net-next now.
>> --
> Excellent !
>
> Thanks a lot David
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
Yes
Excellent work.
I make some real life tests with 10Gbit traffic and make some rdos.
With kernel 3.4.5 when I reach 6M routing cache entries - traffic is not
forwarded - on my hardware with 64G RAM
With kernel - 3.5.0-rc7-next-20120720 + David M. patches - route cache
removal + fix
Traffic is forwarder all the time at speed 8.2Mpps RX from traffic
generator and 8.2Mpps TX to the sink
Also I see performance improvement.
With kernel 3.4.5 I can reach maximum od 7.5Mpps with my hardware
And with kernel 3.5.0-rc7-next-20120720 i can reach 8.2Mpps - forwarding
UDP performance - can be more - but my TX pktgen that use 6 cores can't
do more.
Really thanks for this :)
BR
Paweł Staszewski
^ permalink raw reply
* Re: [PATCH] mlx4: Add support for EEH error recovery
From: Kleber Sacilotto de Souza @ 2012-07-23 18:12 UTC (permalink / raw)
To: Or Gerlitz
Cc: David Miller, netdev, jackm, yevgenyp, cascardo, brking, shlomop
In-Reply-To: <500D556F.4000409@mellanox.com>
On 07/23/2012 10:45 AM, Or Gerlitz wrote:
> On 7/23/2012 4:18 PM, Kleber Sacilotto de Souza wrote:
>> Exactly. The callbacks implemented are from standard PCI error recovery
>> (Documentation/PCI/pci-error-recovery.txt) and the changes doesn't
>> assume any platform in specific. The code was tested only on powerpc
>> systems [...]
>
> So how did you test that? using the kernel provided error injection
> support and user space tool (which?) or in another way? we've trying
> quickly here to inject errors using /sbin/ear-inject from
> ras-utils-6.1-1.el6.x86_64 on a kernel built with
>
> CONFIG_PCIEAER=y
> CONFIG_PCIEAER_INJECT=m
For powerpc we have an IBM internal user space tool that injects the
error on the bus with the aid of the system firmware. The kernel used
was built with the option:
CONFIG_EEH=y
and without the AER options. I will run some more tests with the AER
options activated.
>
> and it failed to inject errors, SB details.
>
> Or.
>> since I don't have any mlx4 card on other platforms, however,
>> these changes shouldn't make the error recover any worse than the
>> current state.
>
>> # lspci | grep 08.00.1
>> 08:00.1 Ethernet controller: Intel Corporation 82575EB Gigabit Network
>> Connection (rev 02)
>
>> # cat /tmp/intel.aer
>> AER
>> BUS 8 DEV 0 FN 1
>> COR_STATUS BAD_TLP
>> HEADER_LOG 0 1 2 3
>
>> # /sbin/aer-inject < /tmp/intel.aer
>> Error: Failed to write, Invalid argument
>
>
>
>> # strace -F -f /sbin/aer-inject < /tmp/intel.aer
>> [...]
>
>> open("/dev/aer_inject", O_WRONLY) = 3
>> write(3, "\10\0\1\0\0\0\0\0@\0\0\0\0\0\0\0\1\0\0\0\2\0\0\0\3\0\0\0",
>> 28) = -1 EINVAL (Invalid argument)
>> write(2, "Error: ", 7Error: ) = 7
>> write(2, "Failed to write", 15Failed to write) = 15
>> write(2, ", Invalid argument\n", 19, Invalid argument
>> ) = 19
>> exit_group(-1) = ?
>
>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
Kleber Sacilotto de Souza
IBM Linux Technology Center
^ permalink raw reply
* Re: New commands to configure IOV features
From: Stephen Hemminger @ 2012-07-23 18:36 UTC (permalink / raw)
To: Chris Friesen
Cc: Don Dutile, Ben Hutchings, David Miller, yuvalmin, gregory.v.rose,
netdev, linux-pci
In-Reply-To: <500D6932.8090306@genband.com>
On Mon, 23 Jul 2012 09:09:38 -0600
Chris Friesen <chris.friesen@genband.com> wrote:
> On 07/23/2012 08:03 AM, Don Dutile wrote:
> > On 07/20/2012 07:42 PM, Chris Friesen wrote:
> >>
> >> I actually have a use-case where the guest needs to be able to modify
> >> the MAC addresses of network devices that are actually VFs.
> >>
> >> The guest is bonding the network devices together, so the bonding
> >> driver in the guest expects to be able to set all the slaves to the
> >> same MAC address.
> >>
> >> As I read the ixgbe driver, this should be possible as long as the
> >> host hasn't explicitly set the MAC address of the VF. Is that correct?
> >>
> >> Chris
> >
> > Interesting tug of war: hypervisors will want to set the macaddrs for
> > security reasons,
> > some guests may want to set macaddr for
> > (valid?) config reasons.
> >
>
> In our case we have control over both guest an host anyways, so it's
> less of a security issue. In the general case though I could see it
> being an interesting problem.
>
> Back to the original discussion though--has anyone got any ideas about
> the best way to trigger runtime creation of VFs? I don't know what the
> binary APIs looks like, but via sysfs I could see something like
>
> echo number_of_new_vfs_to_create >
> /sys/bus/pci/devices/<address>/create_vfs
>
> Something else that occurred to me--is there buy-in from driver
> maintainers? I know the Intel ethernet drivers (what I'm most familiar
> with) would need to be substantially modified to support on-the-fly
> addition of new vfs. Currently they assume that the number of vfs is
> known at module init time.
>
Why couldn't rtnl_link_ops be used for this. It is already the preferred
interface to create vlan's, bond devices, and other virtual devices?
The one issue is that do the created VF's exist in kernel as devices
or only visible to guest?
^ permalink raw reply
* Re: [PATCH net/for-next V1 1/1] IB/ipoib: break linkage to neighbouring system
From: Or Gerlitz @ 2012-07-23 18:37 UTC (permalink / raw)
To: Eric Dumazet
Cc: Or Gerlitz, roland-DgEjT+Ai2ygdnm+yROfE0A,
davem-fT/PcQaiUtIeIZ0/mPfg9Q, Christoph Lameter,
linux-rdma-u79uwXL29TY76Z2rM5mHXA, erezsh-VPRAkNaXOzVWk0Htik3J/w,
Shlomo Pongratz, netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1343063863.2626.11028.camel@edumazet-glaptop>
On Mon, Jul 23, 2012 at 8:17 PM, Eric Dumazet <eric.dumazet-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> I have no idea of what you are talking about, I have not the patch or a
> copy of it ;)
http://marc.info/?t=134271491300002&r=1&w=2
http://marc.info/?t=134271491300005&r=1&w=2
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* RE: New commands to configure IOV features
From: Rose, Gregory V @ 2012-07-23 18:40 UTC (permalink / raw)
To: Stephen Hemminger, Chris Friesen
Cc: Don Dutile, Ben Hutchings, David Miller, yuvalmin@broadcom.com,
netdev@vger.kernel.org, linux-pci@vger.kernel.org
In-Reply-To: <20120723113607.56ce7aaf@nehalam.linuxnetplumber.net>
> -----Original Message-----
> From: Stephen Hemminger [mailto:shemminger@vyatta.com]
> Sent: Monday, July 23, 2012 11:36 AM
> To: Chris Friesen
> Cc: Don Dutile; Ben Hutchings; David Miller; yuvalmin@broadcom.com; Rose,
> Gregory V; netdev@vger.kernel.org; linux-pci@vger.kernel.org
> Subject: Re: New commands to configure IOV features
>
> On Mon, 23 Jul 2012 09:09:38 -0600
> Chris Friesen <chris.friesen@genband.com> wrote:
>
> > On 07/23/2012 08:03 AM, Don Dutile wrote:
> > > On 07/20/2012 07:42 PM, Chris Friesen wrote:
> > >>
> > >> I actually have a use-case where the guest needs to be able to
> > >> modify the MAC addresses of network devices that are actually VFs.
> > >>
> > >> The guest is bonding the network devices together, so the bonding
> > >> driver in the guest expects to be able to set all the slaves to the
> > >> same MAC address.
> > >>
> > >> As I read the ixgbe driver, this should be possible as long as the
> > >> host hasn't explicitly set the MAC address of the VF. Is that
> correct?
> > >>
> > >> Chris
> > >
> > > Interesting tug of war: hypervisors will want to set the macaddrs
> > > for security reasons,
> > > some guests may want to set macaddr for
> > > (valid?) config reasons.
> > >
> >
> > In our case we have control over both guest an host anyways, so it's
> > less of a security issue. In the general case though I could see it
> > being an interesting problem.
> >
> > Back to the original discussion though--has anyone got any ideas about
> > the best way to trigger runtime creation of VFs? I don't know what
> > the binary APIs looks like, but via sysfs I could see something like
> >
> > echo number_of_new_vfs_to_create >
> > /sys/bus/pci/devices/<address>/create_vfs
> >
> > Something else that occurred to me--is there buy-in from driver
> > maintainers? I know the Intel ethernet drivers (what I'm most
> > familiar
> > with) would need to be substantially modified to support on-the-fly
> > addition of new vfs. Currently they assume that the number of vfs is
> > known at module init time.
> >
>
> Why couldn't rtnl_link_ops be used for this. It is already the preferred
> interface to create vlan's, bond devices, and other virtual devices?
> The one issue is that do the created VF's exist in kernel as devices or
> only visible to guest?
I would say that rtnl_link_ops are network oriented and not appropriate for something like a storage controller or graphics device, which are two other common SR-IOV capable devices.
I think it should be oriented toward the PCIe interface and subsystems in the kernel.
- Greg
^ permalink raw reply
* Re: ibmveth bug?
From: Nishanth Aravamudan @ 2012-07-23 19:03 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: santil, anton, paulus, netdev, linux-kernel, Anton Blanchard
In-Reply-To: <1342831966.29855.6.camel@pasglop>
Hi Ben,
On 21.07.2012 [10:52:46 +1000], Benjamin Herrenschmidt wrote:
> On Fri, 2012-07-20 at 15:41 -0700, Nishanth Aravamudan wrote:
> > Ping on this ... we've tripped the same issue on a different system, it
> > would appear. Would appreciate if anyone can provide answers to the
> > questions below.
>
> Well, I haven't hit it but your description makes sense. Why not use
> dma_alloc_coherent though ? Rather than kmalloc followed by map ?
Thanks for the response!
dma_alloc_coherent here makes sense. I honestly haven't though too much
about solutions yet, as the problem isn't consistent. For instance, the
one reproducer right now is hitting it only at install time, and only if
another particular PCI device is also plugged in to the machine.
> At least on power we give you page alignment for these, so the problem
> is solved magically :-) Another option is GFP + dma_map_page which is
> roughly equivalent.
>
> If you think it's a waste of space based on the queue size, then just
> add an extra pointer, I wouldn't bother with a cache for something only
> allocated when the driver initializes.
Agreed, will try to code something up this week.
Thanks,
Nish
>
> Cheers,
> Ben.
>
> > Thanks,
> > Nish
> >
> > On 15.05.2012 [10:01:41 -0700], Nishanth Aravamudan wrote:
> > > Hi Santiago,
> > >
> > > Are you still working on ibmveth?
> > >
> > > I've found a very sporadic bug with ibmveth in some testing. PAPR
> > > requires that:
> > >
> > > "Validate the Buffer Descriptor of the receive queue buffer (I/O
> > > addresses for entire buffer length starting at the spec- ified I/O
> > > address are translated by the RTCE table, length is a multiple of 16
> > > bytes, and alignment is on a 16 byte boundary) else H_Parameter."
> > >
> > > but from what I can tell ibmveth.c is not enforcing this last condition:
> > >
> > > adapter->rx_queue.queue_addr =
> > > kmalloc(adapter->rx_queue.queue_len, GFP_KERNEL);
> > >
> > > ...
> > >
> > > adapter->rx_queue.queue_dma = dma_map_single(dev,
> > > adapter->rx_queue.queue_addr, adapter->rx_queue.queue_len,
> > > DMA_BIDIRECTIONAL);
> > >
> > > ...
> > >
> > > rxq_desc.fields.address = adapter->rx_queue.queue_dma;
> > >
> > > ...
> > >
> > >
> > > lpar_rc = ibmveth_register_logical_lan(adapter, rxq_desc,
> > > mac_address);
> > > netdev_err(netdev, "buffer TCE:0x%llx filter TCE:0x%llx rxq "
> > > "desc:0x%llx MAC:0x%llx\n", adapter->buffer_list_dma,
> > > adapter->filter_list_dma, rxq_desc.desc, mac_address);
> > >
> > > And I got on one install attempt:
> > >
> > > [ 39.978430] ibmveth 30000004: eth0: h_register_logical_lan failed with -4
> > > [ 39.978449] ibmveth 30000004: eth0: buffer TCE:0x1000 filter TCE:0x10000 rxq desc:0x80006010000200a8 MAC:0x56754de8e904
> > >
> > > rxq desc, as you can see is not 16byte aligned. kmalloc() only
> > > guarantees 8-byte alignment (as does gcc, I think). Initially, I thought
> > > we could just overallocate the queue_addr and ALIGN() down, but then we
> > > would need to save the original kmalloc pointer in a new struct member
> > > per rx_queue.
> > >
> > > So a couple of questions:
> > >
> > > 1) Is my analysis accurate? :)
> > >
> > > 2) How gross would it be to save an extra pointer for every rx_queue?
> > >
> > > 3) Based upon 2), is it better to just go ahead and create our own
> > > kmem_cache (which gets an alignment specified)?
> > >
> > > For 3), I started coding this, but couldn't find a clean place to
> > > allocate the kmem_cache itself, as the size of each object depends on
> > > the run-time characteristics (afaict), but needs to be specified at
> > > cache creation time. Any insight you could provide would be great!
> > >
> > > Thanks,
> > > Nish
> > >
> > > --
> > > Nishanth Aravamudan <nacc@us.ibm.com>
> > > IBM Linux Technology Center
> >
>
>
--
Nishanth Aravamudan <nacc@us.ibm.com>
IBM Linux Technology Center
^ permalink raw reply
* Re: [PATCH 11/16] ipv4: Cache input routes in fib_info nexthops.
From: Julian Anastasov @ 2012-07-23 20:00 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <alpine.LFD.2.00.1207231157590.1626@ja.ssi.bg>
Hello,
On Mon, 23 Jul 2012, Julian Anastasov wrote:
> The problem with rt_iif is worse. May be we
> can cache only the first iif, other packets will see
> different iif in nh_rth_input and will get non-cached
> result. For boxes with 2 or more interfaces only one
> can use the cache. One setup can have large traffic
> from LAN, other can be server for remote clients.
May be we can replace rt_iif with skb->dev->ifindex ?
If we have dst, there must be skb->dev ? Only for
output routes we should check places that rely on
inet_iif().
Regards
--
Julian Anastasov <ja@ssi.bg>
^ permalink raw reply
* Re: [patch] openvswitch: potential NULL deref in sample()
From: Jesse Gross @ 2012-07-23 19:54 UTC (permalink / raw)
To: Dan Carpenter
Cc: dev-yBygre7rU0TnMu66kgdUjQ, netdev-u79uwXL29TY76Z2rM5mHXA,
kernel-janitors-u79uwXL29TY76Z2rM5mHXA, David S. Miller
In-Reply-To: <20120723074628.GA30892-mgFCXtclrQlZLf2FXnZxJA@public.gmane.org>
On Mon, Jul 23, 2012 at 12:46 AM, Dan Carpenter
<dan.carpenter-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org> wrote:
> If there is no OVS_SAMPLE_ATTR_ACTIONS set then "acts_list" is NULL and
> it leads to a NULL dereference when we call nla_len(acts_list). This
> is a static checker fix, not something I have seen in testing.
>
> Signed-off-by: Dan Carpenter <dan.carpenter-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
This can never happen in practice because the action list is validated
at the time that userspace installs the flow. There are plenty of
things in this category that would appear to be unsafe because we'd
much rather do sanity checking on a per-flow basis rather than
per-packet.
^ permalink raw reply
* Re: [PATCH 11/16] ipv4: Cache input routes in fib_info nexthops.
From: David Miller @ 2012-07-23 19:58 UTC (permalink / raw)
To: ja; +Cc: netdev
In-Reply-To: <alpine.LFD.2.00.1207232245230.1619@ja.ssi.bg>
From: Julian Anastasov <ja@ssi.bg>
Date: Mon, 23 Jul 2012 23:00:57 +0300 (EEST)
> May be we can replace rt_iif with skb->dev->ifindex ?
> If we have dst, there must be skb->dev ? Only for
> output routes we should check places that rely on
> inet_iif().
Right, just as I was drinking my first coffee after reading
your previous email I was thinking about this.
The only time skb->dev->ifindex can change from rt->rt_iif is when we
demux a tunnel, but at that point we would first reinject and do
another route lookup, at which point rt->rt_iif would match again.
And this is the intended semantic of this field anyways.
I'll look into what we can do here, and I'll also try to come up
with some ideas wrt. the DIRECTSRC issue as well.
Thanks Julian.
^ permalink raw reply
* Re: [PATCH] USB: plusb: Add support for PL-2501
From: David Miller @ 2012-07-23 20:08 UTC (permalink / raw)
To: bas; +Cc: linux-kernel, sshtylyov, linux-usb, netdev, greg
In-Reply-To: <alpine.LNX.2.02.1207231540580.1183@bas>
From: kyak <bas@bmail.ru>
Date: Mon, 23 Jul 2012 15:44:11 +0400 (MSK)
> From: Mikhail Peselnik <peselnik@gmail.com>
>
> This patch adds support for PL-2501 by adding the appropriate USB
> ID's. This chip is used in several USB 'Easy Trasfer' Cables.
>
> Signed-off-by: Mikhail Peselnik <peselnik@gmail.com>
> Tested-by: Mikhail Peselnik <peselnik@gmail.com>
This does not apply cleanly to my net-next tree at all.
^ permalink raw reply
* Re: [PATCH] ipv4: Remove redundant assignment
From: David Miller @ 2012-07-23 20:09 UTC (permalink / raw)
To: mlin; +Cc: netdev
In-Reply-To: <1343052681.4600.5.camel@monkey32>
From: Lin Ming <mlin@ss.pku.edu.cn>
Date: Mon, 23 Jul 2012 22:11:21 +0800
> It is redundant to set no_addr and accept_local to 0 and then set them
> with other values just after that.
>
> Signed-off-by: Lin Ming <mlin@ss.pku.edu.cn>
Applied, thanks.
^ permalink raw reply
* Re: [net-next] net/ipv4/ip_vti.c: Fix __rcu warnings detected by sparse.
From: David Miller @ 2012-07-23 20:09 UTC (permalink / raw)
To: saurabh.mohan; +Cc: netdev
In-Reply-To: <20120723175204.GA2762@debian-saurabh-64.vyatta.com>
From: Saurabh <saurabh.mohan@vyatta.com>
Date: Mon, 23 Jul 2012 10:52:04 -0700
>
>
> With CONFIG_SPARSE_RCU_POINTER=y sparse identified references which did not
> specificy __rcu in ip_vti.c
>
> Signed-off-by: Saurabh Mohan <saurabh.mohan@vyatta.com>
> Reported-by: Fengguang Wu <fengguang.wu@intel.com>
Applied.
^ permalink raw reply
* Re: [PATCH 00/16] Remove the ipv4 routing cache
From: David Miller @ 2012-07-23 20:10 UTC (permalink / raw)
To: pstaszewski; +Cc: eric.dumazet, netdev
In-Reply-To: <500D8FEE.7050802@itcare.pl>
From: Paweł Staszewski <pstaszewski@itcare.pl>
Date: Mon, 23 Jul 2012 19:54:54 +0200
> Really thanks for this :)
Thanks for testing.
^ permalink raw reply
* [PATCH] decnet: Don't set RTCF_DIRECTSRC.
From: David Miller @ 2012-07-23 20:17 UTC (permalink / raw)
To: netdev
It's an ipv4 defined route flag, and only ipv4 uses it.
Signed-off-by: David S. Miller <davem@davemloft.net>
---
net/decnet/dn_route.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/net/decnet/dn_route.c b/net/decnet/dn_route.c
index 23cc11d..85a3604 100644
--- a/net/decnet/dn_route.c
+++ b/net/decnet/dn_route.c
@@ -1424,7 +1424,6 @@ static int dn_route_input_slow(struct sk_buff *skb)
/* Packet was intra-ethernet, so we know its on-link */
if (cb->rt_flags & DN_RT_F_IE) {
gateway = cb->src;
- flags |= RTCF_DIRECTSRC;
goto make_route;
}
@@ -1437,7 +1436,6 @@ static int dn_route_input_slow(struct sk_buff *skb)
/* Close eyes and pray */
gateway = cb->src;
- flags |= RTCF_DIRECTSRC;
goto make_route;
default:
goto e_inval;
--
1.7.10.4
^ permalink raw reply related
* [PATCH 1/2] ipv4: Really ignore ICMP address requests/replies.
From: David Miller @ 2012-07-23 20:23 UTC (permalink / raw)
To: netdev
Alexey removed kernel side support for requests, and the
only thing we do for replies is log a message if something
doesn't look right.
As Alexey's comment indicates, this belongs in userspace (if
anywhere), and thus we can safely just get rid of this code.
Signed-off-by: David S. Miller <davem@davemloft.net>
---
net/ipv4/icmp.c | 84 ++-----------------------------------------------------
1 file changed, 2 insertions(+), 82 deletions(-)
diff --git a/net/ipv4/icmp.c b/net/ipv4/icmp.c
index ea3a996..f2a06be 100644
--- a/net/ipv4/icmp.c
+++ b/net/ipv4/icmp.c
@@ -837,86 +837,6 @@ out_err:
goto out;
}
-
-/*
- * Handle ICMP_ADDRESS_MASK requests. (RFC950)
- *
- * RFC1122 (3.2.2.9). A host MUST only send replies to
- * ADDRESS_MASK requests if it's been configured as an address mask
- * agent. Receiving a request doesn't constitute implicit permission to
- * act as one. Of course, implementing this correctly requires (SHOULD)
- * a way to turn the functionality on and off. Another one for sysctl(),
- * I guess. -- MS
- *
- * RFC1812 (4.3.3.9). A router MUST implement it.
- * A router SHOULD have switch turning it on/off.
- * This switch MUST be ON by default.
- *
- * Gratuitous replies, zero-source replies are not implemented,
- * that complies with RFC. DO NOT implement them!!! All the idea
- * of broadcast addrmask replies as specified in RFC950 is broken.
- * The problem is that it is not uncommon to have several prefixes
- * on one physical interface. Moreover, addrmask agent can even be
- * not aware of existing another prefixes.
- * If source is zero, addrmask agent cannot choose correct prefix.
- * Gratuitous mask announcements suffer from the same problem.
- * RFC1812 explains it, but still allows to use ADDRMASK,
- * that is pretty silly. --ANK
- *
- * All these rules are so bizarre, that I removed kernel addrmask
- * support at all. It is wrong, it is obsolete, nobody uses it in
- * any case. --ANK
- *
- * Furthermore you can do it with a usermode address agent program
- * anyway...
- */
-
-static void icmp_address(struct sk_buff *skb)
-{
-#if 0
- net_dbg_ratelimited("a guy asks for address mask. Who is it?\n");
-#endif
-}
-
-/*
- * RFC1812 (4.3.3.9). A router SHOULD listen all replies, and complain
- * loudly if an inconsistency is found.
- * called with rcu_read_lock()
- */
-
-static void icmp_address_reply(struct sk_buff *skb)
-{
- struct rtable *rt = skb_rtable(skb);
- struct net_device *dev = skb->dev;
- struct in_device *in_dev;
- struct in_ifaddr *ifa;
-
- if (skb->len < 4 || !(rt->rt_flags&RTCF_DIRECTSRC))
- return;
-
- in_dev = __in_dev_get_rcu(dev);
- if (!in_dev)
- return;
-
- if (in_dev->ifa_list &&
- IN_DEV_LOG_MARTIANS(in_dev) &&
- IN_DEV_FORWARD(in_dev)) {
- __be32 _mask, *mp;
-
- mp = skb_header_pointer(skb, 0, sizeof(_mask), &_mask);
- BUG_ON(mp == NULL);
- for (ifa = in_dev->ifa_list; ifa; ifa = ifa->ifa_next) {
- if (*mp == ifa->ifa_mask &&
- inet_ifa_match(ip_hdr(skb)->saddr, ifa))
- break;
- }
- if (!ifa)
- net_info_ratelimited("Wrong address mask %pI4 from %s/%pI4\n",
- mp,
- dev->name, &ip_hdr(skb)->saddr);
- }
-}
-
static void icmp_discard(struct sk_buff *skb)
{
}
@@ -1080,10 +1000,10 @@ static const struct icmp_control icmp_pointers[NR_ICMP_TYPES + 1] = {
.handler = icmp_discard,
},
[ICMP_ADDRESS] = {
- .handler = icmp_address,
+ .handler = icmp_discard,
},
[ICMP_ADDRESSREPLY] = {
- .handler = icmp_address_reply,
+ .handler = icmp_discard,
},
};
--
1.7.10.4
^ permalink raw reply related
* [PATCH 2/2] ipv4: Remove all RTCF_DIRECTSRC handliing.
From: David Miller @ 2012-07-23 20:23 UTC (permalink / raw)
To: netdev
The last and final kernel user, ICMP address replies,
has been removed.
Signed-off-by: David S. Miller <davem@davemloft.net>
---
net/ipv4/route.c | 11 ++---------
1 file changed, 2 insertions(+), 9 deletions(-)
diff --git a/net/ipv4/route.c b/net/ipv4/route.c
index 9add088..34017be 100644
--- a/net/ipv4/route.c
+++ b/net/ipv4/route.c
@@ -1391,9 +1391,6 @@ static int __mkroute_input(struct sk_buff *skb,
goto cleanup;
}
- if (err)
- flags |= RTCF_DIRECTSRC;
-
if (out_dev == in_dev && err &&
(IN_DEV_SHARED_MEDIA(out_dev) ||
inet_addr_onlink(out_dev, saddr, FIB_RES_GW(*res))))
@@ -1416,7 +1413,7 @@ static int __mkroute_input(struct sk_buff *skb,
do_cache = false;
if (res->fi) {
- if (!(flags & RTCF_DIRECTSRC) && !itag) {
+ if (!itag) {
rth = FIB_RES_NH(*res).nh_rth_input;
if (rt_cache_valid(rth)) {
dst_hold(&rth->dst);
@@ -1558,8 +1555,6 @@ static int ip_route_input_slow(struct sk_buff *skb, __be32 daddr, __be32 saddr,
dev, in_dev, &itag);
if (err < 0)
goto martian_source_keep_err;
- if (err)
- flags |= RTCF_DIRECTSRC;
goto local_input;
}
@@ -1580,8 +1575,6 @@ brd_input:
in_dev, &itag);
if (err < 0)
goto martian_source_keep_err;
- if (err)
- flags |= RTCF_DIRECTSRC;
}
flags |= RTCF_BROADCAST;
res.type = RTN_BROADCAST;
@@ -1590,7 +1583,7 @@ brd_input:
local_input:
do_cache = false;
if (res.fi) {
- if (!(flags & RTCF_DIRECTSRC) && !itag) {
+ if (!itag) {
rth = FIB_RES_NH(res).nh_rth_input;
if (rt_cache_valid(rth)) {
dst_hold(&rth->dst);
--
1.7.10.4
^ permalink raw reply related
* Re: [PATCH] mlx4: Add support for EEH error recovery
From: Kleber Sacilotto de Souza @ 2012-07-23 20:53 UTC (permalink / raw)
To: Or Gerlitz
Cc: David Miller, netdev, jackm, yevgenyp, cascardo, brking, shlomop
In-Reply-To: <500D93F5.4090305@linux.vnet.ibm.com>
On 07/23/2012 03:12 PM, Kleber Sacilotto de Souza wrote:
> On 07/23/2012 10:45 AM, Or Gerlitz wrote:
>
>> On 7/23/2012 4:18 PM, Kleber Sacilotto de Souza wrote:
>>> Exactly. The callbacks implemented are from standard PCI error recovery
>>> (Documentation/PCI/pci-error-recovery.txt) and the changes doesn't
>>> assume any platform in specific. The code was tested only on powerpc
>>> systems [...]
>>
>> So how did you test that? using the kernel provided error injection
>> support and user space tool (which?) or in another way? we've trying
>> quickly here to inject errors using /sbin/ear-inject from
>> ras-utils-6.1-1.el6.x86_64 on a kernel built with
>>
>> CONFIG_PCIEAER=y
>> CONFIG_PCIEAER_INJECT=m
>
>
> For powerpc we have an IBM internal user space tool that injects the
> error on the bus with the aid of the system firmware. The kernel used
> was built with the option:
>
> CONFIG_EEH=y
>
> and without the AER options. I will run some more tests with the AER
> options activated.
I tested the powerpc error injection with
CONFIG_EEH=y
CONFIG_PCIEAER=y
CONFIG_PCIEAER_INJECT=m
and with the aer_inject module loaded and it didn't affect the EEH
recovery, the adapter recovered as expected.
>
>>
>> and it failed to inject errors, SB details.
>>
>> Or.
>>> since I don't have any mlx4 card on other platforms, however,
>>> these changes shouldn't make the error recover any worse than the
>>> current state.
>>
>>> # lspci | grep 08.00.1
>>> 08:00.1 Ethernet controller: Intel Corporation 82575EB Gigabit Network
>>> Connection (rev 02)
>>
>>> # cat /tmp/intel.aer
>>> AER
>>> BUS 8 DEV 0 FN 1
>>> COR_STATUS BAD_TLP
>>> HEADER_LOG 0 1 2 3
>>
>>> # /sbin/aer-inject < /tmp/intel.aer
>>> Error: Failed to write, Invalid argument
>>
>>
>>
>>> # strace -F -f /sbin/aer-inject < /tmp/intel.aer
>>> [...]
>>
>>> open("/dev/aer_inject", O_WRONLY) = 3
>>> write(3, "\10\0\1\0\0\0\0\0@\0\0\0\0\0\0\0\1\0\0\0\2\0\0\0\3\0\0\0",
>>> 28) = -1 EINVAL (Invalid argument)
>>> write(2, "Error: ", 7Error: ) = 7
>>> write(2, "Failed to write", 15Failed to write) = 15
>>> write(2, ", Invalid argument\n", 19, Invalid argument
>>> ) = 19
>>> exit_group(-1) = ?
>>
>>
>>
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe netdev" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>
>
>
--
Kleber Sacilotto de Souza
IBM Linux Technology Center
^ permalink raw reply
* Re: [PATCH 11/16] ipv4: Cache input routes in fib_info nexthops.
From: David Miller @ 2012-07-23 21:06 UTC (permalink / raw)
To: ja; +Cc: netdev
In-Reply-To: <20120723.125837.2165279339112720363.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Date: Mon, 23 Jul 2012 12:58:37 -0700 (PDT)
> The only time skb->dev->ifindex can change from rt->rt_iif is when we
> demux a tunnel, but at that point we would first reinject and do
> another route lookup, at which point rt->rt_iif would match again.
>
> And this is the intended semantic of this field anyways.
Ok Julian, you probably already say the DIRECTSRC patches and upcoming
are two patches to take care of the rt->rt_iif thing.
^ permalink raw reply
* [PATCH 1/2] ipv4: Prepare for change of rt->rt_iif encoding.
From: David Miller @ 2012-07-23 21:07 UTC (permalink / raw)
To: netdev; +Cc: ja
Use inet_iif() consistently, and for TCP record the input interface of
cached RX dst in inet sock.
rt->rt_iif is going to be encoded differently, so that we can
legitimately cache input routes in the FIB info more aggressively.
When the input interface is "use SKB device index" the rt->rt_iif will
be set to zero.
This forces us to move the TCP RX dst cache installation into the ipv4
specific code, and as well it should since doing the route caching for
ipv6 is pointless at the moment since it is not inspected in the ipv6
input paths yet.
Also, remove the unlikely on dst->obsolete, all ipv4 dsts have
obsolete set to a non-zero value to force invocation of the check
callback.
Signed-off-by: David S. Miller <davem@davemloft.net>
---
include/net/inet_sock.h | 1 +
net/dccp/ipv4.c | 2 +-
net/ipv4/icmp.c | 2 +-
net/ipv4/ip_sockglue.c | 5 ++---
net/ipv4/route.c | 2 +-
net/ipv4/tcp_input.c | 12 ------------
net/ipv4/tcp_ipv4.c | 24 ++++++++++++++++++------
net/sched/cls_route.c | 2 +-
net/sched/em_meta.c | 2 +-
net/sctp/protocol.c | 2 +-
10 files changed, 27 insertions(+), 27 deletions(-)
diff --git a/include/net/inet_sock.h b/include/net/inet_sock.h
index 924d7b9..613cfa4 100644
--- a/include/net/inet_sock.h
+++ b/include/net/inet_sock.h
@@ -172,6 +172,7 @@ struct inet_sock {
int uc_index;
int mc_index;
__be32 mc_addr;
+ int rx_dst_ifindex;
struct ip_mc_socklist __rcu *mc_list;
struct inet_cork_full cork;
};
diff --git a/net/dccp/ipv4.c b/net/dccp/ipv4.c
index 25428d0..176ecdb 100644
--- a/net/dccp/ipv4.c
+++ b/net/dccp/ipv4.c
@@ -481,7 +481,7 @@ static struct dst_entry* dccp_v4_route_skb(struct net *net, struct sock *sk,
struct rtable *rt;
const struct iphdr *iph = ip_hdr(skb);
struct flowi4 fl4 = {
- .flowi4_oif = skb_rtable(skb)->rt_iif,
+ .flowi4_oif = inet_iif(skb),
.daddr = iph->saddr,
.saddr = iph->daddr,
.flowi4_tos = RT_CONN_FLAGS(sk),
diff --git a/net/ipv4/icmp.c b/net/ipv4/icmp.c
index f2a06be..f2eccd5 100644
--- a/net/ipv4/icmp.c
+++ b/net/ipv4/icmp.c
@@ -571,7 +571,7 @@ void icmp_send(struct sk_buff *skb_in, int type, int code, __be32 info)
rcu_read_lock();
if (rt_is_input_route(rt) &&
net->ipv4.sysctl_icmp_errors_use_inbound_ifaddr)
- dev = dev_get_by_index_rcu(net, rt->rt_iif);
+ dev = dev_get_by_index_rcu(net, inet_iif(skb_in));
if (dev)
saddr = inet_select_addr(dev, 0, RT_SCOPE_LINK);
diff --git a/net/ipv4/ip_sockglue.c b/net/ipv4/ip_sockglue.c
index de29f46..5eea4a8 100644
--- a/net/ipv4/ip_sockglue.c
+++ b/net/ipv4/ip_sockglue.c
@@ -1027,10 +1027,9 @@ e_inval:
void ipv4_pktinfo_prepare(struct sk_buff *skb)
{
struct in_pktinfo *pktinfo = PKTINFO_SKB_CB(skb);
- const struct rtable *rt = skb_rtable(skb);
- if (rt) {
- pktinfo->ipi_ifindex = rt->rt_iif;
+ if (skb_rtable(skb)) {
+ pktinfo->ipi_ifindex = inet_iif(skb);
pktinfo->ipi_spec_dst.s_addr = fib_compute_spec_dst(skb);
} else {
pktinfo->ipi_ifindex = 0;
diff --git a/net/ipv4/route.c b/net/ipv4/route.c
index 34017be..f6be781 100644
--- a/net/ipv4/route.c
+++ b/net/ipv4/route.c
@@ -848,7 +848,7 @@ void ip_rt_send_redirect(struct sk_buff *skb)
if (log_martians &&
peer->rate_tokens == ip_rt_redirect_number)
net_warn_ratelimited("host %pI4/if%d ignores redirects for %pI4 to %pI4\n",
- &ip_hdr(skb)->saddr, rt->rt_iif,
+ &ip_hdr(skb)->saddr, inet_iif(skb),
&ip_hdr(skb)->daddr, &rt->rt_gateway);
#endif
}
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index 21d7f8f..3e07a64 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -5391,18 +5391,6 @@ int tcp_rcv_established(struct sock *sk, struct sk_buff *skb,
{
struct tcp_sock *tp = tcp_sk(sk);
- if (sk->sk_rx_dst) {
- struct dst_entry *dst = sk->sk_rx_dst;
- if (unlikely(dst->obsolete)) {
- if (dst->ops->check(dst, 0) == NULL) {
- dst_release(dst);
- sk->sk_rx_dst = NULL;
- }
- }
- }
- if (unlikely(sk->sk_rx_dst == NULL))
- sk->sk_rx_dst = dst_clone(skb_dst(skb));
-
/*
* Header prediction.
* The code loosely follows the one in the famous
diff --git a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c
index bc5432e..3e30548 100644
--- a/net/ipv4/tcp_ipv4.c
+++ b/net/ipv4/tcp_ipv4.c
@@ -1618,6 +1618,20 @@ int tcp_v4_do_rcv(struct sock *sk, struct sk_buff *skb)
if (sk->sk_state == TCP_ESTABLISHED) { /* Fast path */
sock_rps_save_rxhash(sk, skb);
+ if (sk->sk_rx_dst) {
+ struct dst_entry *dst = sk->sk_rx_dst;
+ if (dst->ops->check(dst, 0) == NULL) {
+ dst_release(dst);
+ sk->sk_rx_dst = NULL;
+ }
+ }
+ if (unlikely(sk->sk_rx_dst == NULL)) {
+ struct inet_sock *icsk = inet_sk(sk);
+ struct rtable *rt = skb_rtable(skb);
+
+ sk->sk_rx_dst = dst_clone(&rt->dst);
+ icsk->rx_dst_ifindex = inet_iif(skb);
+ }
if (tcp_rcv_established(sk, skb, tcp_hdr(skb), skb->len)) {
rsk = sk;
goto reset;
@@ -1700,14 +1714,12 @@ void tcp_v4_early_demux(struct sk_buff *skb)
skb->destructor = sock_edemux;
if (sk->sk_state != TCP_TIME_WAIT) {
struct dst_entry *dst = sk->sk_rx_dst;
+ struct inet_sock *icsk = inet_sk(sk);
if (dst)
dst = dst_check(dst, 0);
- if (dst) {
- struct rtable *rt = (struct rtable *) dst;
-
- if (rt->rt_iif == dev->ifindex)
- skb_dst_set_noref(skb, dst);
- }
+ if (dst &&
+ icsk->rx_dst_ifindex == dev->ifindex)
+ skb_dst_set_noref(skb, dst);
}
}
}
diff --git a/net/sched/cls_route.c b/net/sched/cls_route.c
index 36fec42..44f405c 100644
--- a/net/sched/cls_route.c
+++ b/net/sched/cls_route.c
@@ -143,7 +143,7 @@ static int route4_classify(struct sk_buff *skb, const struct tcf_proto *tp,
if (head == NULL)
goto old_method;
- iif = ((struct rtable *)dst)->rt_iif;
+ iif = inet_iif(skb);
h = route4_fastmap_hash(id, iif);
if (id == head->fastmap[h].id &&
diff --git a/net/sched/em_meta.c b/net/sched/em_meta.c
index 4790c69..4ab6e33 100644
--- a/net/sched/em_meta.c
+++ b/net/sched/em_meta.c
@@ -264,7 +264,7 @@ META_COLLECTOR(int_rtiif)
if (unlikely(skb_rtable(skb) == NULL))
*err = -1;
else
- dst->value = skb_rtable(skb)->rt_iif;
+ dst->value = inet_iif(skb);
}
/**************************************************************************
diff --git a/net/sctp/protocol.c b/net/sctp/protocol.c
index 9c90811..1f89c4e 100644
--- a/net/sctp/protocol.c
+++ b/net/sctp/protocol.c
@@ -568,7 +568,7 @@ static void sctp_v4_get_saddr(struct sctp_sock *sk,
/* What interface did this skb arrive on? */
static int sctp_v4_skb_iif(const struct sk_buff *skb)
{
- return skb_rtable(skb)->rt_iif;
+ return inet_iif(skb);
}
/* Was this packet marked by Explicit Congestion Notification? */
--
1.7.10.4
^ permalink raw reply related
* [PATCH 2/2] ipv4: Change rt->rt_iif encoding.
From: David Miller @ 2012-07-23 21:07 UTC (permalink / raw)
To: netdev; +Cc: ja
On input packet processing, rt->rt_iif will be zero if we should
use skb->dev->ifindex.
Since we access rt->rt_iif consistently via inet_iif(), that is
the only spot whose interpretation have to adjust.
Signed-off-by: David S. Miller <davem@davemloft.net>
---
include/net/route.h | 6 +++++-
net/ipv4/route.c | 8 ++++----
2 files changed, 9 insertions(+), 5 deletions(-)
diff --git a/include/net/route.h b/include/net/route.h
index 60d611d..d418ae1 100644
--- a/include/net/route.h
+++ b/include/net/route.h
@@ -277,7 +277,11 @@ static inline struct rtable *ip_route_newports(struct flowi4 *fl4, struct rtable
static inline int inet_iif(const struct sk_buff *skb)
{
- return skb_rtable(skb)->rt_iif;
+ int iif = skb_rtable(skb)->rt_iif;
+
+ if (iif)
+ return iif;
+ return skb->dev->ifindex;
}
extern int sysctl_ip_default_ttl;
diff --git a/net/ipv4/route.c b/net/ipv4/route.c
index f6be781..6bcb8fc 100644
--- a/net/ipv4/route.c
+++ b/net/ipv4/route.c
@@ -1309,7 +1309,7 @@ static int ip_route_input_mc(struct sk_buff *skb, __be32 daddr, __be32 saddr,
rth->rt_flags = RTCF_MULTICAST;
rth->rt_type = RTN_MULTICAST;
rth->rt_is_input= 1;
- rth->rt_iif = dev->ifindex;
+ rth->rt_iif = 0;
rth->rt_pmtu = 0;
rth->rt_gateway = 0;
if (our) {
@@ -1435,7 +1435,7 @@ static int __mkroute_input(struct sk_buff *skb,
rth->rt_flags = flags;
rth->rt_type = res->type;
rth->rt_is_input = 1;
- rth->rt_iif = in_dev->dev->ifindex;
+ rth->rt_iif = 0;
rth->rt_pmtu = 0;
rth->rt_gateway = 0;
@@ -1608,7 +1608,7 @@ local_input:
rth->rt_flags = flags|RTCF_LOCAL;
rth->rt_type = res.type;
rth->rt_is_input = 1;
- rth->rt_iif = dev->ifindex;
+ rth->rt_iif = 0;
rth->rt_pmtu = 0;
rth->rt_gateway = 0;
if (res.type == RTN_UNREACHABLE) {
@@ -1772,7 +1772,7 @@ static struct rtable *__mkroute_output(const struct fib_result *res,
rth->rt_flags = flags;
rth->rt_type = type;
rth->rt_is_input = 0;
- rth->rt_iif = orig_oif ? : dev_out->ifindex;
+ rth->rt_iif = orig_oif ? : 0;
rth->rt_pmtu = 0;
rth->rt_gateway = 0;
--
1.7.10.4
^ permalink raw reply related
* [PATCH] r8169: revert "add byte queue limit support".
From: Francois Romieu @ 2012-07-23 20:55 UTC (permalink / raw)
To: David Miller; +Cc: hayeswang, netdev, Alex Villacís Lasso, Josh Boyer
This reverts commit 036dafa28da1e2565a8529de2ae663c37b7a0060.
First it appears in bisection, then reverting it solves the usual
netdev watchdog problem for different people. I don't have a proper
fix yet so get rid of it.
Bisected-and-reported-by: Alex Villacís Lasso <a_villacis@palosanto.com>
Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
Cc: Josh Boyer <jwboyer@redhat.com>
Cc: Hayes Wang <hayeswang@realtek.com>
---
The original 036da... commit has been modified due to the newly introduced
skb_tx_timestamp in rtl8169_start_xmit. The herein included patch qualifies
for 3.4-stable as well.
drivers/net/ethernet/realtek/r8169.c | 27 +++++----------------------
1 file changed, 5 insertions(+), 22 deletions(-)
diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c
index d7a04e0..eb81da4 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -5380,7 +5380,6 @@ static void rtl8169_tx_clear(struct rtl8169_private *tp)
{
rtl8169_tx_clear_range(tp, tp->dirty_tx, NUM_TX_DESC);
tp->cur_tx = tp->dirty_tx = 0;
- netdev_reset_queue(tp->dev);
}
static void rtl_reset_work(struct rtl8169_private *tp)
@@ -5535,8 +5534,6 @@ static netdev_tx_t rtl8169_start_xmit(struct sk_buff *skb,
txd->opts2 = cpu_to_le32(opts[1]);
- netdev_sent_queue(dev, skb->len);
-
skb_tx_timestamp(skb);
wmb();
@@ -5633,16 +5630,9 @@ static void rtl8169_pcierr_interrupt(struct net_device *dev)
rtl_schedule_task(tp, RTL_FLAG_TASK_RESET_PENDING);
}
-struct rtl_txc {
- int packets;
- int bytes;
-};
-
static void rtl_tx(struct net_device *dev, struct rtl8169_private *tp)
{
- struct rtl8169_stats *tx_stats = &tp->tx_stats;
unsigned int dirty_tx, tx_left;
- struct rtl_txc txc = { 0, 0 };
dirty_tx = tp->dirty_tx;
smp_rmb();
@@ -5661,24 +5651,17 @@ static void rtl_tx(struct net_device *dev, struct rtl8169_private *tp)
rtl8169_unmap_tx_skb(&tp->pci_dev->dev, tx_skb,
tp->TxDescArray + entry);
if (status & LastFrag) {
- struct sk_buff *skb = tx_skb->skb;
-
- txc.packets++;
- txc.bytes += skb->len;
- dev_kfree_skb(skb);
+ u64_stats_update_begin(&tp->tx_stats.syncp);
+ tp->tx_stats.packets++;
+ tp->tx_stats.bytes += tx_skb->skb->len;
+ u64_stats_update_end(&tp->tx_stats.syncp);
+ dev_kfree_skb(tx_skb->skb);
tx_skb->skb = NULL;
}
dirty_tx++;
tx_left--;
}
- u64_stats_update_begin(&tx_stats->syncp);
- tx_stats->packets += txc.packets;
- tx_stats->bytes += txc.bytes;
- u64_stats_update_end(&tx_stats->syncp);
-
- netdev_completed_queue(dev, txc.packets, txc.bytes);
-
if (tp->dirty_tx != dirty_tx) {
tp->dirty_tx = dirty_tx;
/* Sync with rtl8169_start_xmit:
--
1.7.10.4
^ permalink raw reply related
* Re: [PATCH] mlx4: Add support for EEH error recovery
From: Or Gerlitz @ 2012-07-23 21:26 UTC (permalink / raw)
To: Kleber Sacilotto de Souza
Cc: Or Gerlitz, David Miller, netdev, jackm, yevgenyp, cascardo,
brking, shlomop
In-Reply-To: <500DB9CE.5080100@linux.vnet.ibm.com>
Kleber Sacilotto de Souza <klebers@linux.vnet.ibm.com> wrote:
>> For powerpc we have an IBM internal user space tool that injects the
>> error on the bus with the aid of the system firmware. The kernel used
>> was built with the option:
>> CONFIG_EEH=y
>> and without the AER options. I will run some more tests with the AER
>> options activated.
> I tested the powerpc error injection with
>
> CONFIG_EEH=y
> CONFIG_PCIEAER=y
> CONFIG_PCIEAER_INJECT=m
>
> and with the aer_inject module loaded and it didn't affect the EEH
> recovery, the adapter recovered as expected.
I wasn't sure to follow what did you mean by "it didn't affect the EEH
recovery", how did you use the aer_inject module, is that through
user-space tool which is available for us?
Or.
^ 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