* Re: [PATCH net-next 1/5] tipc: silence sparse warnings
From: Andreas Bofjäll @ 2013-09-27 8:15 UTC (permalink / raw)
To: Ying Xue; +Cc: jon.maloy, netdev, tipc-discussion, David Miller
In-Reply-To: <52453B51.5070702@windriver.com>
On 09/27/2013 10:01 AM, Ying Xue wrote:
> Good point!
> It's better for us to use memcpy_fromiovecend() instead of
> skb_copy_to_linear_data() and its friends.
>
> We will submit another version to correct this error soon.
I could be wrong here, but I think you should also remove the entire
cast on line 1210 in link.c:
sect_crs = msg_sect[curr_sect].iov_base;
There should be no reason to cast there since you made sect_crs into
const unchar* __user and msg_sect[].iov_base is void* __user.
/Andreas
------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk
^ permalink raw reply
* Re: [PATCH] ipv6: Fix preferred_lft not updating in some cases
From: Hannes Frederic Sowa @ 2013-09-27 8:16 UTC (permalink / raw)
To: Paul Marks; +Cc: netdev, davem, yoshfuji, lorenzo
In-Reply-To: <1380147175-14874-1-git-send-email-pmarks@google.com>
On Wed, Sep 25, 2013 at 03:12:55PM -0700, Paul Marks wrote:
> Consider the scenario where an IPv6 router is advertising a fixed
> preferred_lft of 1800 seconds, while the valid_lft begins at 3600
> seconds and counts down in realtime.
>
> A client should reset its preferred_lft to 1800 every time the RA is
> received, but a bug is causing Linux to ignore the update.
>
> The core problem is here:
> if (prefered_lft != ifp->prefered_lft) {
>
> Note that ifp->prefered_lft is an offset, so it doesn't decrease over
> time. Thus, the comparison is always (1800 != 1800), which fails to
> trigger an update.
>
> The most direct solution would be to compute a "stored_prefered_lft",
> and use that value in the comparison. But I think that trying to filter
> out unnecessary updates here is a premature optimization. In order for
> the filter to apply, both of these would need to hold:
>
> - The advertised valid_lft and preferred_lft are both declining in
> real time.
> - No clock skew exists between the router & client.
>
> So in this patch, I've set "update_lft = 1" unconditionally, which
> allows the surrounding code to be greatly simplified.
I actually find this much harder to follow when verifying against the RFC.
> Signed-off-by: Paul Marks <pmarks@google.com>
> ---
> net/ipv6/addrconf.c | 52 +++++++++++++++-------------------------------------
> 1 file changed, 15 insertions(+), 37 deletions(-)
>
> diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
> index d6ff126..9a5052c 100644
> --- a/net/ipv6/addrconf.c
> +++ b/net/ipv6/addrconf.c
> @@ -2193,43 +2193,21 @@ ok:
> else
> stored_lft = 0;
> if (!update_lft && !create && stored_lft) {
> - if (valid_lft > MIN_VALID_LIFETIME ||
> - valid_lft > stored_lft)
> - update_lft = 1;
> - else if (stored_lft <= MIN_VALID_LIFETIME) {
> - /* valid_lft <= stored_lft is always true */
> - /*
> - * RFC 4862 Section 5.5.3e:
> - * "Note that the preferred lifetime of
> - * the corresponding address is always
> - * reset to the Preferred Lifetime in
> - * the received Prefix Information
> - * option, regardless of whether the
> - * valid lifetime is also reset or
> - * ignored."
> - *
> - * So if the preferred lifetime in
> - * this advertisement is different
> - * than what we have stored, but the
> - * valid lifetime is invalid, just
> - * reset prefered_lft.
> - *
> - * We must set the valid lifetime
> - * to the stored lifetime since we'll
> - * be updating the timestamp below,
> - * else we'll set it back to the
> - * minimum.
> - */
> - if (prefered_lft != ifp->prefered_lft) {
Wouldn't the easiest solution be to just drop this if and execute the two
lines below unconditionally?
> - valid_lft = stored_lft;
> - update_lft = 1;
> - }
> - } else {
> - valid_lft = MIN_VALID_LIFETIME;
> - if (valid_lft < prefered_lft)
> - prefered_lft = valid_lft;
> - update_lft = 1;
> - }
> + const u32 minimum_lft = min(
> + stored_lft, (u32)MIN_VALID_LIFETIME);
> + valid_lft = max(valid_lft, minimum_lft);
Quick question: Don't we need a prefered_lft = min(preferred_lft, valid_lft)
here?
> +
> + /* RFC4862 Section 5.5.3e:
> + * "Note that the preferred lifetime of the
> + * corresponding address is always reset to
> + * the Preferred Lifetime in the received
> + * Prefix Information option, regardless of
> + * whether the valid lifetime is also reset or
> + * ignored."
> + *
> + * So we should always update prefered_lft here.
> + */
> + update_lft = 1;
> }
>
> if (update_lft) {
Thanks,
Hannes
^ permalink raw reply
* Re: [PATCH 00/51] DMA mask changes
From: Russell King - ARM Linux @ 2013-09-27 8:27 UTC (permalink / raw)
To: Rafał Miłecki
Cc: alsa-devel, linux-doc, linux-mmc, linux-fbdev, linux-nvme,
linux-ide, devel@driverdev.osuosl.org, linux-samsung-soc,
Linux SCSI List, e1000-devel, b43-dev, linux-media, devicetree,
dri-devel, linux-tegra, linux-omap,
linux-arm-kernel@lists.infradead.org,
Solarflare linux maintainers, Network Development, linux-usb,
linux-wireless@vger.kernel.org, linux-crypto, uclinux-dist-devel
In-Reply-To: <CACna6rxkpYzdD8_Jfi22vA2suUa3k-JM65_gCySQpp4crVCoPg@mail.gmail.com>
On Thu, Sep 26, 2013 at 10:23:08PM +0200, Rafał Miłecki wrote:
> 2013/9/19 Russell King - ARM Linux <linux@arm.linux.org.uk>:
> > This email is only being sent to the mailing lists in question, not to
> > anyone personally. The list of individuals is far to great to do that.
> > I'm hoping no mailing lists reject the patches based on the number of
> > recipients.
>
> Huh, I think it was enough to send only 3 patches to the b43-dev@. Like:
> [PATCH 01/51] DMA-API: provide a helper to set both DMA and coherent DMA masks
> [PATCH 14/51] DMA-API: net: b43: (...)
> [PATCH 15/51] DMA-API: net: b43legacy: (...)
> ;)
>
> I believe Joe has some nice script for doing it that way. When fixing
> some coding style / formatting, he sends only related patches to the
> given ML.
If I did that, then the mailing lists would not get the first patch,
because almost none of the lists would be referred to by patch 1.
Moreover, people complain when they don't have access to the full
patch series - they assume patches are missing for some reason, and
they ask for the rest of the series.
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
^ permalink raw reply
* RE: [PATCH] iproute2: xfrm state add abort issue
From: David Laight @ 2013-09-27 8:26 UTC (permalink / raw)
To: Sohny Thomas, stephen, netdev
In-Reply-To: <52447DAC.2060701@linux.vnet.ibm.com>
> ip xfrm state add causes a SIGABRT due to a strncpy_chk .
> This happens since strncpy doesn't account for the '\0' .
> I have fixed this using sizeof instead of strlen .
>
> There is a redhat bug which documents this issue
>
> https://bugzilla.redhat.com/show_bug.cgi?id=982761
>
> Signed-off-by: Sohny Thomas <sohthoma@in.ibm.com>
>
> --------------
>
> diff --git a/ip/xfrm_state.c b/ip/xfrm_state.c
> index 389942c..7dd8799 100644
> --- a/ip/xfrm_state.c
> +++ b/ip/xfrm_state.c
> @@ -117,7 +117,7 @@ static int xfrm_algo_parse(struct xfrm_algo *alg,
> enum xfrm_attr_type_t type,
> char *name, char *key, char *buf, int max)
> {
> int len;
> - int slen = strlen(key);
> + int slen = sizeof(key);
you definitely don't want sizeof(key) - that is either 4 or 8.
David
^ permalink raw reply
* [PATCHv2 net-next] xfrm: Simplify SA looking up when using wildcard source
From: Fan Du @ 2013-09-27 8:32 UTC (permalink / raw)
To: steffen.klassert; +Cc: davem, netdev
__xfrm4/6_state_addr_check is a four steps check, all we need to do
is checking whether the destination address match when looking SA
using wildcard source address. Passing saddr from flow is worst option,
as the checking needs to reach the fourth step while actually only
one time checking will do the work.
So, simplify this process by only checking destination address when
using wildcard source address for looking up SAs.
Signed-off-by: Fan Du <fan.du@windriver.com>
---
v2:
- Rewrite a good qualified commit log message
- Use xfrm_addr_equal instead of remaking wheel
---
net/xfrm/xfrm_state.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/xfrm/xfrm_state.c b/net/xfrm/xfrm_state.c
index e1373d5..3fad928 100644
--- a/net/xfrm/xfrm_state.c
+++ b/net/xfrm/xfrm_state.c
@@ -824,7 +824,7 @@ xfrm_state_find(const xfrm_address_t *daddr, const xfrm_address_t *saddr,
x->props.reqid == tmpl->reqid &&
(mark & x->mark.m) == x->mark.v &&
!(x->props.flags & XFRM_STATE_WILDRECV) &&
- xfrm_state_addr_check(x, daddr, saddr, encap_family) &&
+ xfrm_addr_equal(&x->id.daddr, daddr, encap_family) &&
tmpl->mode == x->props.mode &&
tmpl->id.proto == x->id.proto &&
(tmpl->id.spi == x->id.spi || !tmpl->id.spi))
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH net-next] xfrm: Simplify SA looking up when using wildcard source address
From: Fan Du @ 2013-09-27 8:35 UTC (permalink / raw)
To: Steffen Klassert; +Cc: davem, netdev
In-Reply-To: <20130924114551.GT7660@secunet.com>
On 2013年09月24日 19:45, Steffen Klassert wrote:
> On Mon, Sep 23, 2013 at 05:18:37PM +0800, Fan Du wrote:
>> I'm not quite sure I get this "wildcard source address" right,
>> IMHO if a host needs to protect every traffic for a given remote host,
>> then the source address is wildcard address, i.e. all ZEROs.
>> (Please correct me if I'm bloodly wrong。。。)
>
> The above does not belong to a commit message, really.
> If you are not sure and you want comments on your patch,
> mark your patch as RFC. You should be sure that your patch
> is correct when you submit, at least in the moment you
> send it. I know that this can change a second after,
> but in that moment you should be sure.
One day without embarrassment is not my day :)
Have sent v2, please kindly review.
Thanks
>>
>> Here is the argument if above statement stands true:
>> __xfrm4/6_state_addr_check is a four steps check, all we need to do
>> is checking whether the destination address match. Passing saddr from
>> flow is worst option, as the checking needs to reach the fourth step.
>>
>> So, simply this process by only checking destination address only when
>> using wildcard source address for looking up SAs.
>>
>> Signed-off-by: Fan Du<fan.du@windriver.com>
>> ---
>
> If you have further comments on your patch that should not be
> included in the commit message, you can add them here.
>
>> include/net/xfrm.h | 31 +++++++++++++++++++++++++++++++
>> net/xfrm/xfrm_state.c | 2 +-
>> 2 files changed, 32 insertions(+), 1 deletion(-)
>>
>> diff --git a/include/net/xfrm.h b/include/net/xfrm.h
>> index e253bf0..fdb9343 100644
>> --- a/include/net/xfrm.h
>> +++ b/include/net/xfrm.h
>> @@ -1282,6 +1282,37 @@ xfrm_state_addr_check(const struct xfrm_state *x,
>> }
>>
>> static __inline__ int
>> +__xfrm4_state_daddr_check(const struct xfrm_state *x,
>> + const xfrm_address_t *daddr)
>> +{
>> + return ((daddr->a4 == x->id.daddr.a4) ? 1 : 0);
>> +}
>> +
>> +static __inline__ int
>> +__xfrm6_state_daddr_check(const struct xfrm_state *x,
>> + const xfrm_address_t *daddr)
>> +{
>> + if (ipv6_addr_equal((struct in6_addr *)daddr, (struct in6_addr *)&x->id.daddr))
>> + return 1;
>> + else
>> + return 0;
>> +}
>> +
>> +static __inline__ int
>> +xfrm_state_daddr_check(const struct xfrm_state *x,
>> + const xfrm_address_t *daddr,
>> + unsigned short family)
>> +{
>> + switch (family) {
>> + case AF_INET:
>> + return __xfrm4_state_daddr_check(x, daddr);
>> + case AF_INET6:
>> + return __xfrm6_state_daddr_check(x, daddr);
>> + }
>> + return 0;
>> +}
>
> You used whitespaces where you should use tabs in the whole patch.
> Please do the formating right to avoid cleanup patches.
>
> --
> 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
>
--
浮沉随浪只记今朝笑
--fan
^ permalink raw reply
* Re: [PATCH] IPv6: Allow the MTU of ipip6 tunnel to be set below 1280
From: Hannes Frederic Sowa @ 2013-09-27 8:37 UTC (permalink / raw)
To: Oussama Ghorbel
Cc: David S. Miller, Alexey Kuznetsov, James Morris,
Hideaki YOSHIFUJI, Patrick McHardy, netdev, linux-kernel
In-Reply-To: <1380207108-20030-1-git-send-email-oghorbell@gmail.com>
On Thu, Sep 26, 2013 at 03:51:48PM +0100, Oussama Ghorbel wrote:
> The (inner) MTU of a ipip6 (IPv4-in-IPv6) tunnel cannot be set below 1280, which is the minimum MTU in IPv6.
> However, there should be no IPv6 on the tunnel interface at all, so the IPv6 rules should not apply.
> More info at https://bugzilla.kernel.org/show_bug.cgi?id=15530
>
> This patch allows to check the minimum MTU for ipv6 tunnel according to these rules:
> -In case the tunnel is configured with ipip6 mode the minimum MTU is 68.
> -In case the tunnel is configured with ip6ip6 or any mode the minimum MTU is 1280.
>
> Signed-off-by: Oussama Ghorbel <oghorbell@gmail.com>
> ---
> net/ipv6/ip6_tunnel.c | 10 ++++++++--
> 1 file changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/net/ipv6/ip6_tunnel.c b/net/ipv6/ip6_tunnel.c
> index 1e55866..a66ead2 100644
> --- a/net/ipv6/ip6_tunnel.c
> +++ b/net/ipv6/ip6_tunnel.c
> @@ -1423,8 +1423,14 @@ ip6_tnl_ioctl(struct net_device *dev, struct ifreq *ifr, int cmd)
> static int
> ip6_tnl_change_mtu(struct net_device *dev, int new_mtu)
> {
> - if (new_mtu < IPV6_MIN_MTU) {
> - return -EINVAL;
> + struct ip6_tnl *t = netdev_priv(dev);
> +
> + if (t->parms.proto == IPPROTO_IPIP) {
> + if (new_mtu < 68)
> + return -EINVAL;
Maybe you could have a look at ip_tunnel_change_mtu in ipv4/ip_tunnel.c,
generalize this check as e.g. ip_tunnel_valid_mtu or something and use it
here? Maybe an af-independent ip_tunnel_max_mtu()?
> + } else {
> + if (new_mtu < IPV6_MIN_MTU)
> + return -EINVAL;
This check could also be used here, then.
> }
> dev->mtu = new_mtu;
> return 0;
Thanks,
Hannes
^ permalink raw reply
* Re: GRE support for IPv6
From: Hannes Frederic Sowa @ 2013-09-27 8:41 UTC (permalink / raw)
To: Templin, Fred L; +Cc: Stephen Hemminger, netdev@vger.kernel.org, xeb@mail.ru
In-Reply-To: <2134F8430051B64F815C691A62D98318108F59@XCH-BLV-504.nw.nos.boeing.com>
Hi Fred!
On Fri, Sep 13, 2013 at 10:37:01PM +0000, Templin, Fred L wrote:
> See attached for the patches as applied to iproute2-3.10.0.
> The code compiles cleanly - testing is in progress.
Could you resend the patches inline (formatted with git-format-patch) so that
patchwork[1] can track them?
[1] http://patchwork.ozlabs.org/project/netdev/list/
Greetings,
Hannes
^ permalink raw reply
* RE: rx_dropped count for USB ethernet interfaces
From: David Laight @ 2013-09-27 8:39 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20130926.132125.1343558938307288175.davem@redhat.com>
> From: "David Laight" <David.Laight@ACULAB.COM>
> Date: Thu, 26 Sep 2013 10:32:24 +0100
>
> > It isn't exactly useful behaviour though.
>
> In your opinion.
>
> We have tracepoints for people who want more fine grained drops
> in these kinds of situations.
>
> Also, the behavior of this statistic has existed for more than a
> decade so changing it is really not in the cards. Therefore any
> discussion about what would have been the best samentic to choose from
> the beginning is moot.
I suspect that not many people have networks with broadcast packets
for non-IP protocols - so don't ever see rx_dropped being incremented
because there wasn't a protocol stack looking for the packet.
A similar problem will arise if promiscuous mode is enabled
by someone who only wants a specific protocol - eg a specific
ethertype or a single LLC SAP value.
David
^ permalink raw reply
* Re: ipv6: strange routing behaviors on a multi-interfaces setup
From: Hannes Frederic Sowa @ 2013-09-27 8:50 UTC (permalink / raw)
To: Emmanuel Thierry; +Cc: netdev
In-Reply-To: <374AB8DA-F970-4652-B147-2094B56BE5F0@sekil.fr>
On Wed, Sep 25, 2013 at 06:53:07PM +0200, Emmanuel Thierry wrote:
> I experienced these problems on a 3.11.1 kernel but they look to be quite recurrent in the past versions as well.
A current solution would be to bind the socket to an interface
(SO_BINDTODEVICE) from user-space. I'll look if we can make the next hop
selection more fine grained.
Greetings,
Hannes
^ permalink raw reply
* Re: Bug - regression - Via velocity interface coming up freezes kernel
From: Dirk Kraft @ 2013-09-27 9:10 UTC (permalink / raw)
To: Francois Romieu; +Cc: netdev, Julia Lawall
In-Reply-To: <20130922221109.GA14246@electric-eye.fr.zoreil.com>
Hi,
My machine has now been running for multiple days with the proposed
patch. I was not able to see any warnings/error messages or any bad
behavior.
For me the proposed patch fixes the problem and I could not see any
new problems being introduced.
Thanks,
Dirk
^ permalink raw reply
* Re: [PATCH 1/4] [RFC] net: Explicitly initialize u64_stats_sync structures for lockdep
From: Eric Dumazet @ 2013-09-27 9:15 UTC (permalink / raw)
To: Ingo Molnar
Cc: John Stultz, LKML, Thomas Petazzoni, Mirko Lindner,
Stephen Hemminger, Roger Luethi, Patrick McHardy, Rusty Russell,
Michael S. Tsirkin, Alexey Kuznetsov, James Morris,
Hideaki YOSHIFUJI, Wensong Zhang, Simon Horman, Julian Anastasov,
Jesse Gross, Mathieu Desnoyers, Steven Rostedt, Peter Zijlstra,
Thomas Gleixner, David S. Miller, netdev, netfilter-devel
In-Reply-To: <20130927054455.GA6597@gmail.com>
On Fri, 2013-09-27 at 07:44 +0200, Ingo Molnar wrote:
> C cannot pass along symbolic names, unfortunately, so we are stuck with
> 1970's tech and the C preprocessor.
>
Yes, I realized that a bit too late.
> There's a way to make such macros look a tiny bit more structured and thus
> be more palatable:
>
> #if BITS_PER_LONG == 32 && defined(CONFIG_SMP)
> # define u64_stats_init(syncp) seqcount_init(syncp.seq)
> #else
> # define u64_stats_init(syncp)
> #endif
>
> Note, the 'else' branch should probably be:
>
> # define u64_stats_init(syncp) do { } while (0)
Yes, this is better ;)
Thanks !
^ permalink raw reply
* Re: [PATCH net-next 1/5] tipc: silence sparse warnings
From: Ying Xue @ 2013-09-27 9:48 UTC (permalink / raw)
To: Andreas Bofjäll; +Cc: jon.maloy, netdev, tipc-discussion, David Miller
In-Reply-To: <52453E8D.2020705@ericsson.com>
On 09/27/2013 04:15 PM, Andreas Bofjäll wrote:
> On 09/27/2013 10:01 AM, Ying Xue wrote:
>> Good point!
>> It's better for us to use memcpy_fromiovecend() instead of
>> skb_copy_to_linear_data() and its friends.
>>
>> We will submit another version to correct this error soon.
>
> I could be wrong here, but I think you should also remove the entire
> cast on line 1210 in link.c:
>
> sect_crs = msg_sect[curr_sect].iov_base;
>
> There should be no reason to cast there since you made sect_crs into
> const unchar* __user and msg_sect[].iov_base is void* __user.
>
You are right, thank you for your nice reminder!
Regards,
Ying
> /Andreas
>
>
------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk
^ permalink raw reply
* Re: [PATCHv2] ipvs: improved SH fallback strategy
From: Alexander Frolkin @ 2013-09-27 10:06 UTC (permalink / raw)
To: Julian Anastasov
Cc: Simon Horman, Sergei Shtylyov, lvs-devel, Wensong Zhang, netdev,
linux-kernel
In-Reply-To: <alpine.LFD.2.00.1309262255400.1949@ja.ssi.bg>
Improve the SH fallback realserver selection strategy.
With sh and sh-fallback, if a realserver is down, this attempts to
distribute the traffic that would have gone to that server evenly
among the remaining servers.
Signed-off-by: Alexander Frolkin <avf@eldamar.org.uk>
--
diff --git a/net/netfilter/ipvs/ip_vs_sh.c b/net/netfilter/ipvs/ip_vs_sh.c
index 3588fae..cc65b2f 100644
--- a/net/netfilter/ipvs/ip_vs_sh.c
+++ b/net/netfilter/ipvs/ip_vs_sh.c
@@ -115,27 +115,46 @@ ip_vs_sh_get(struct ip_vs_service *svc, struct ip_vs_sh_state *s,
}
-/* As ip_vs_sh_get, but with fallback if selected server is unavailable */
+/* As ip_vs_sh_get, but with fallback if selected server is unavailable
+ *
+ * The fallback strategy loops around the table starting from a "random"
+ * point (in fact, it is chosen to be the original hash value to make the
+ * algorithm deterministic) to find a new server.
+ */
static inline struct ip_vs_dest *
ip_vs_sh_get_fallback(struct ip_vs_service *svc, struct ip_vs_sh_state *s,
const union nf_inet_addr *addr, __be16 port)
{
- unsigned int offset;
- unsigned int hash;
+ unsigned int offset, roffset;
+ unsigned int hash, ihash;
struct ip_vs_dest *dest;
+ /* first try the dest it's supposed to go to */
+ ihash = ip_vs_sh_hashkey(svc->af, addr, port, 0);
+ dest = rcu_dereference(s->buckets[ihash].dest);
+ if (!dest)
+ return NULL;
+ if (!is_unavailable(dest))
+ return dest;
+
+ IP_VS_DBG_BUF(6, "SH: selected unavailable server %s:%d, reselecting",
+ IP_VS_DBG_ADDR(svc->af, &dest->addr), ntohs(dest->port));
+
+ /* if the original dest is unavailable, loop around the table
+ * starting from ihash to find a new dest
+ */
for (offset = 0; offset < IP_VS_SH_TAB_SIZE; offset++) {
- hash = ip_vs_sh_hashkey(svc->af, addr, port, offset);
+ roffset = (offset + ihash) % IP_VS_SH_TAB_SIZE;
+ hash = ip_vs_sh_hashkey(svc->af, addr, port, roffset);
dest = rcu_dereference(s->buckets[hash].dest);
if (!dest)
break;
- if (is_unavailable(dest))
- IP_VS_DBG_BUF(6, "SH: selected unavailable server "
- "%s:%d (offset %d)",
- IP_VS_DBG_ADDR(svc->af, &dest->addr),
- ntohs(dest->port), offset);
- else
+ if (!is_unavailable(dest))
return dest;
+ IP_VS_DBG_BUF(6, "SH: selected unavailable "
+ "server %s:%d (offset %d), reselecting",
+ IP_VS_DBG_ADDR(svc->af, &dest->addr),
+ ntohs(dest->port), roffset);
}
return NULL;
^ permalink raw reply related
* [PATCH] tcp: TSQ can use a dynamic limit
From: Eric Dumazet @ 2013-09-27 10:28 UTC (permalink / raw)
To: Cong Wang, David Miller
Cc: Wei Liu, Linux Kernel Network Developers, Yuchung Cheng,
Neal Cardwell
In-Reply-To: <1379861902.3431.12.camel@edumazet-glaptop>
From: Eric Dumazet <edumazet@google.com>
When TCP Small Queues was added, we used a sysctl to limit amount of
packets queues on Qdisc/device queues for a given TCP flow.
Problem is this limit is either too big for low rates, or too small
for high rates.
Now TCP stack has rate estimation in sk->sk_pacing_rate, and TSO
auto sizing, it can better control number of packets in Qdisc/device
queues.
New limit is two packets or at least 1 to 2 ms worth of packets.
Low rates flows benefit from this patch by having even smaller
number of packets in queues, allowing for faster recovery,
better RTT estimations.
High rates flows benefit from this patch by allowing more than 2 packets
in flight as we had reports this was a limiting factor to reach line
rate. [ In particular if TX completion is delayed because of coalescing
parameters ]
Example for a single flow on 10Gbp link controlled by FQ/pacing
14 packets in flight instead of 2
$ tc -s -d qd
qdisc fq 8001: dev eth0 root refcnt 32 limit 10000p flow_limit 100p
buckets 1024 quantum 3028 initial_quantum 15140
Sent 1168459366606 bytes 771822841 pkt (dropped 0, overlimits 0
requeues 6822476)
rate 9346Mbit 771713pps backlog 953820b 14p requeues 6822476
2047 flow, 2046 inactive, 1 throttled, delay 15673 ns
2372 gc, 0 highprio, 0 retrans, 9739249 throttled, 0 flows_plimit
Note that sk_pacing_rate is currently set to twice the actual rate, but
this might be refined in the future when a flow is in congestion
avoidance.
Additional change : skb->destructor should be set to tcp_wfree().
A future patch (for linux 3.13+) might remove tcp_limit_output_bytes
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Wei Liu <wei.liu2@citrix.com>
Cc: Cong Wang <xiyou.wangcong@gmail.com>
Cc: Yuchung Cheng <ycheng@google.com>
Cc: Neal Cardwell <ncardwell@google.com>
---
net/ipv4/tcp_output.c | 17 +++++++++++------
1 file changed, 11 insertions(+), 6 deletions(-)
diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
index 7c83cb8..c20e406 100644
--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
@@ -895,8 +895,7 @@ static int tcp_transmit_skb(struct sock *sk, struct sk_buff *skb, int clone_it,
skb_orphan(skb);
skb->sk = sk;
- skb->destructor = (sysctl_tcp_limit_output_bytes > 0) ?
- tcp_wfree : sock_wfree;
+ skb->destructor = tcp_wfree;
atomic_add(skb->truesize, &sk->sk_wmem_alloc);
/* Build TCP header and checksum it. */
@@ -1840,7 +1839,6 @@ static bool tcp_write_xmit(struct sock *sk, unsigned int mss_now, int nonagle,
while ((skb = tcp_send_head(sk))) {
unsigned int limit;
-
tso_segs = tcp_init_tso_segs(sk, skb, mss_now);
BUG_ON(!tso_segs);
@@ -1869,13 +1867,20 @@ static bool tcp_write_xmit(struct sock *sk, unsigned int mss_now, int nonagle,
break;
}
- /* TSQ : sk_wmem_alloc accounts skb truesize,
- * including skb overhead. But thats OK.
+ /* TCP Small Queues :
+ * Control number of packets in qdisc/devices to two packets / or ~1 ms.
+ * This allows for :
+ * - better RTT estimation and ACK scheduling
+ * - faster recovery
+ * - high rates
*/
- if (atomic_read(&sk->sk_wmem_alloc) >= sysctl_tcp_limit_output_bytes) {
+ limit = max(skb->truesize, sk->sk_pacing_rate >> 10);
+
+ if (atomic_read(&sk->sk_wmem_alloc) > limit) {
set_bit(TSQ_THROTTLED, &tp->tsq_flags);
break;
}
+
limit = mss_now;
if (tso_segs > 1 && !tcp_urg_mode(tp))
limit = tcp_mss_split_point(sk, skb, mss_now,
^ permalink raw reply related
* Re: [PATCH net-next 1/5] tipc: silence sparse warnings
From: Jon Maloy @ 2013-09-27 10:25 UTC (permalink / raw)
To: Ying Xue
Cc: Andreas Bofjäll, jon.maloy, netdev, paul.gortmaker,
erik.hugne, tipc-discussion
In-Reply-To: <52455471.8060102@windriver.com>
On 09/27/2013 05:48 AM, Ying Xue wrote:
> On 09/27/2013 04:15 PM, Andreas Bofjäll wrote:
>> On 09/27/2013 10:01 AM, Ying Xue wrote:
>>> Good point!
>>> It's better for us to use memcpy_fromiovecend() instead of
>>> skb_copy_to_linear_data() and its friends.
>>>
>>> We will submit another version to correct this error soon.
Can you fix this asap, so I can re-post it? And, let's continue the thread
in tipc-discussion only until we (incl Paul) are happy with this patch.
///jon
>> I could be wrong here, but I think you should also remove the entire
>> cast on line 1210 in link.c:
>>
>> sect_crs = msg_sect[curr_sect].iov_base;
>>
>> There should be no reason to cast there since you made sect_crs into
>> const unchar* __user and msg_sect[].iov_base is void* __user.
>>
> You are right, thank you for your nice reminder!
>
> Regards,
> Ying
>
>> /Andreas
>>
>>
^ permalink raw reply
* Re: [PATCH] IPv6: Allow the MTU of ipip6 tunnel to be set below 1280
From: Oussama Ghorbel @ 2013-09-27 10:45 UTC (permalink / raw)
To: Oussama Ghorbel, David S. Miller, Alexey Kuznetsov, James Morris,
Hideaki YOSHIFUJI, Patrick McHardy, netdev, linux-kernel
In-Reply-To: <20130927083730.GC28287@order.stressinduktion.org>
The ip6_tunnel.c module would be then dependent on ip_tunnel.c and may
be it would not be good thing?
As I have check in v3.10 there is no call from ip6_tunnel to ip_tunnel...
For information, there is no check for the maximum MTU for ipv4 in the
patch as this is not done for ipv6.
Regards,
Oussama
On Fri, Sep 27, 2013 at 9:37 AM, Hannes Frederic Sowa
<hannes@stressinduktion.org> wrote:
> On Thu, Sep 26, 2013 at 03:51:48PM +0100, Oussama Ghorbel wrote:
>> The (inner) MTU of a ipip6 (IPv4-in-IPv6) tunnel cannot be set below 1280, which is the minimum MTU in IPv6.
>> However, there should be no IPv6 on the tunnel interface at all, so the IPv6 rules should not apply.
>> More info at https://bugzilla.kernel.org/show_bug.cgi?id=15530
>>
>> This patch allows to check the minimum MTU for ipv6 tunnel according to these rules:
>> -In case the tunnel is configured with ipip6 mode the minimum MTU is 68.
>> -In case the tunnel is configured with ip6ip6 or any mode the minimum MTU is 1280.
>>
>> Signed-off-by: Oussama Ghorbel <oghorbell@gmail.com>
>> ---
>> net/ipv6/ip6_tunnel.c | 10 ++++++++--
>> 1 file changed, 8 insertions(+), 2 deletions(-)
>>
>> diff --git a/net/ipv6/ip6_tunnel.c b/net/ipv6/ip6_tunnel.c
>> index 1e55866..a66ead2 100644
>> --- a/net/ipv6/ip6_tunnel.c
>> +++ b/net/ipv6/ip6_tunnel.c
>> @@ -1423,8 +1423,14 @@ ip6_tnl_ioctl(struct net_device *dev, struct ifreq *ifr, int cmd)
>> static int
>> ip6_tnl_change_mtu(struct net_device *dev, int new_mtu)
>> {
>> - if (new_mtu < IPV6_MIN_MTU) {
>> - return -EINVAL;
>> + struct ip6_tnl *t = netdev_priv(dev);
>> +
>> + if (t->parms.proto == IPPROTO_IPIP) {
>> + if (new_mtu < 68)
>> + return -EINVAL;
>
> Maybe you could have a look at ip_tunnel_change_mtu in ipv4/ip_tunnel.c,
> generalize this check as e.g. ip_tunnel_valid_mtu or something and use it
> here? Maybe an af-independent ip_tunnel_max_mtu()?
>
>> + } else {
>> + if (new_mtu < IPV6_MIN_MTU)
>> + return -EINVAL;
>
> This check could also be used here, then.
>
>> }
>> dev->mtu = new_mtu;
>> return 0;
>
> Thanks,
>
> Hannes
>
^ permalink raw reply
* Re: [PATCH] IPv6: Allow the MTU of ipip6 tunnel to be set below 1280
From: Hannes Frederic Sowa @ 2013-09-27 10:58 UTC (permalink / raw)
To: Oussama Ghorbel
Cc: David S. Miller, Alexey Kuznetsov, James Morris,
Hideaki YOSHIFUJI, Patrick McHardy, netdev, linux-kernel
In-Reply-To: <CA+ev270=P9txSvo7AZN0YcsopwhCYtJCgcZCPsdofEJ+BX+EUQ@mail.gmail.com>
On Fri, Sep 27, 2013 at 11:45:48AM +0100, Oussama Ghorbel wrote:
> The ip6_tunnel.c module would be then dependent on ip_tunnel.c and may
> be it would not be good thing?
It could just be a static inline in some shared header. So there would
be no compile-time dependency.
> As I have check in v3.10 there is no call from ip6_tunnel to ip_tunnel...
>
> For information, there is no check for the maximum MTU for ipv4 in the
> patch as this is not done for ipv6.
I understand, but it would be better to limit the MTU here. There is a
(non-jumo) IPV6_MAXPLEN constant.
Looking through the source it seems grev6 does actually check this,
so it would not hurt adding them here, too.
Otherwise, I think your patch is fine.
Greetings,
Hannes
^ permalink raw reply
* [PATCH next] l2tp: add support for IPv4-mapped IPv6 addresses
From: François Cachereul @ 2013-09-27 11:17 UTC (permalink / raw)
To: James Chapman; +Cc: David S. Miller, netdev
IPv4 mapped addresses cause kernel panic.
The patch juste check whether the IPv6 address is an IPv4 mapped
address. If so, use IPv4 API instead of IPv6.
Signed-off-by: François CACHEREUL <f.cachereul@alphalink.fr>
---
net/l2tp/l2tp_core.c | 28 ++++++++++++++++++++++++----
net/l2tp/l2tp_core.h | 3 +++
2 files changed, 27 insertions(+), 4 deletions(-)
diff --git a/net/l2tp/l2tp_core.c b/net/l2tp/l2tp_core.c
index feae495..731aa40 100644
--- a/net/l2tp/l2tp_core.c
+++ b/net/l2tp/l2tp_core.c
@@ -496,6 +496,7 @@ out:
static inline int l2tp_verify_udp_checksum(struct sock *sk,
struct sk_buff *skb)
{
+ struct l2tp_tunnel *tunnel = (struct l2tp_tunnel *)sk->sk_user_data;
struct udphdr *uh = udp_hdr(skb);
u16 ulen = ntohs(uh->len);
__wsum psum;
@@ -504,7 +505,7 @@ static inline int l2tp_verify_udp_checksum(struct sock *sk,
return 0;
#if IS_ENABLED(CONFIG_IPV6)
- if (sk->sk_family == PF_INET6) {
+ if (sk->sk_family == PF_INET6 && !tunnel->v4mapped) {
if (!uh->check) {
LIMIT_NETDEBUG(KERN_INFO "L2TP: IPv6: checksum is 0\n");
return 1;
@@ -1128,7 +1129,7 @@ static int l2tp_xmit_core(struct l2tp_session *session, struct sk_buff *skb,
/* Queue the packet to IP for output */
skb->local_df = 1;
#if IS_ENABLED(CONFIG_IPV6)
- if (skb->sk->sk_family == PF_INET6)
+ if (skb->sk->sk_family == PF_INET6 && !tunnel->v4mapped)
error = inet6_csk_xmit(skb, NULL);
else
#endif
@@ -1255,7 +1256,7 @@ int l2tp_xmit_skb(struct l2tp_session *session, struct sk_buff *skb, int hdr_len
/* Calculate UDP checksum if configured to do so */
#if IS_ENABLED(CONFIG_IPV6)
- if (sk->sk_family == PF_INET6)
+ if (sk->sk_family == PF_INET6 && !tunnel->v4mapped)
l2tp_xmit_ipv6_csum(sk, skb, udp_len);
else
#endif
@@ -1620,6 +1621,10 @@ int l2tp_tunnel_create(struct net *net, int fd, int version, u32 tunnel_id, u32
int err;
struct socket *sock = NULL;
struct sock *sk = NULL;
+#if IS_ENABLED(CONFIG_IPV6)
+ struct inet_sock *inet = NULL;
+ struct ipv6_pinfo *np = NULL;
+#endif
struct l2tp_net *pn;
enum l2tp_encap_type encap = L2TP_ENCAPTYPE_UDP;
@@ -1704,6 +1709,21 @@ int l2tp_tunnel_create(struct net *net, int fd, int version, u32 tunnel_id, u32
if (cfg != NULL)
tunnel->debug = cfg->debug;
+#if IS_ENABLED(CONFIG_IPV6)
+ np = inet6_sk(sk);
+ if (sk->sk_family == PF_INET6 &&
+ ipv6_addr_v4mapped(&np->saddr) &&
+ ipv6_addr_v4mapped(&np->daddr)) {
+ tunnel->v4mapped = true;
+ inet = inet_sk(sk);
+ inet->inet_saddr = np->saddr.s6_addr32[3];
+ inet->inet_rcv_saddr = np->rcv_saddr.s6_addr32[3];
+ inet->inet_daddr = np->daddr.s6_addr32[3];
+ } else {
+ tunnel->v4mapped = false;
+ }
+#endif
+
/* Mark socket as an encapsulation socket. See net/ipv4/udp.c */
tunnel->encap = encap;
if (encap == L2TP_ENCAPTYPE_UDP) {
@@ -1712,7 +1732,7 @@ int l2tp_tunnel_create(struct net *net, int fd, int version, u32 tunnel_id, u32
udp_sk(sk)->encap_rcv = l2tp_udp_encap_recv;
udp_sk(sk)->encap_destroy = l2tp_udp_encap_destroy;
#if IS_ENABLED(CONFIG_IPV6)
- if (sk->sk_family == PF_INET6)
+ if (sk->sk_family == PF_INET6 && !tunnel->v4mapped)
udpv6_encap_enable();
else
#endif
diff --git a/net/l2tp/l2tp_core.h b/net/l2tp/l2tp_core.h
index 66a559b..6f251cb 100644
--- a/net/l2tp/l2tp_core.h
+++ b/net/l2tp/l2tp_core.h
@@ -194,6 +194,9 @@ struct l2tp_tunnel {
struct sock *sock; /* Parent socket */
int fd; /* Parent fd, if tunnel socket
* was created by userspace */
+#if IS_ENABLED(CONFIG_IPV6)
+ bool v4mapped;
+#endif
struct work_struct del_work;
--
1.7.10.4
^ permalink raw reply related
* [PATCH] ll_temac: Reset dma descriptors on ndo_open
From: Ricardo Ribalda Delgado @ 2013-09-27 11:24 UTC (permalink / raw)
To: David S. Miller, Joe Perches, Jingoo Han, Greg Kroah-Hartman,
Bill Pemberton, netdev, linux-kernel
Cc: Ricardo Ribalda Delgado
The dma descriptors are only initialized on the probe function.
If a packet is on the buffer when temac_stop is called, the dma
descriptors can be left on a incorrect status where no other package can
be sent.
So an interface could be left in an usable state after ifdow/ifup.
This patch makes sure that the descriptors are in a proper status when
the device is started.
Signed-off-by: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
---
drivers/net/ethernet/xilinx/ll_temac_main.c | 21 +++++++++++++++++++++
1 file changed, 21 insertions(+)
diff --git a/drivers/net/ethernet/xilinx/ll_temac_main.c b/drivers/net/ethernet/xilinx/ll_temac_main.c
index b88121f..8bae87f 100644
--- a/drivers/net/ethernet/xilinx/ll_temac_main.c
+++ b/drivers/net/ethernet/xilinx/ll_temac_main.c
@@ -229,6 +229,25 @@ static void temac_dma_bd_release(struct net_device *ndev)
}
/**
+ * temac_dma_bd_reset - Reset buffer descriptor rings
+ */
+static void temac_dma_bd_reset(struct net_device *ndev)
+{
+ struct temac_local *lp = netdev_priv(ndev);
+ int i;
+
+ for (i = 0; i < TX_BD_NUM; i++)
+ lp->tx_bd_v[i].app0 = 0;
+
+ lp->tx_bd_ci = 0;
+ lp->tx_bd_next = 0;
+ lp->tx_bd_tail = 0;
+ lp->rx_bd_ci = 0;
+
+ return;
+}
+
+/**
* temac_dma_bd_init - Setup buffer descriptor rings
*/
static int temac_dma_bd_init(struct net_device *ndev)
@@ -864,6 +883,8 @@ static int temac_open(struct net_device *ndev)
if (rc)
goto err_rx_irq;
+ temac_dma_bd_reset(ndev);
+
return 0;
err_rx_irq:
--
1.8.4.rc3
^ permalink raw reply related
* Re: question about map_read_chunks()
From: Dan Carpenter @ 2013-09-27 12:21 UTC (permalink / raw)
To: Tom Tucker; +Cc: J. Bruce Fields, netdev, linux-nfs
In-Reply-To: <20120220095019.GA21338@elgon.mountain>
I have looked at this again, and I still worry that it looks like a bug.
(remote security related blah blah blah).
regards,
dan carpenter
On Mon, Feb 20, 2012 at 12:50:19PM +0300, Dan Carpenter wrote:
> I had a couple questions about some map_read_chunks().
>
> net/sunrpc/xprtrdma/svc_rdma_recvfrom.c
>
> 150 ch_bytes = ntohl(ch->rc_target.rs_length);
> ^^^^^^^^
> It look like this is 32 bits from the network?
>
> 151 head->arg.head[0] = rqstp->rq_arg.head[0];
> 152 head->arg.tail[0] = rqstp->rq_arg.tail[0];
> 153 head->arg.pages = &head->pages[head->count];
> 154 head->hdr_count = head->count; /* save count of hdr pages */
> 155 head->arg.page_base = 0;
> 156 head->arg.page_len = ch_bytes;
> 157 head->arg.len = rqstp->rq_arg.len + ch_bytes;
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> Can overflow.
> 158 head->arg.buflen = rqstp->rq_arg.buflen + ch_bytes;
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> Same. I didn't follow it through to see if an overflow matters. Does
> it?
>
> 159 head->count++;
> 160 chl_map->ch[0].start = 0;
> 161 while (byte_count) {
> 162 rpl_map->sge[sge_no].iov_base =
> 163 page_address(rqstp->rq_arg.pages[page_no]) + page_off;
> 164 sge_bytes = min_t(int, PAGE_SIZE-page_off, ch_bytes);
> ^^^
> This is the wrong cast to use. A large ch_bytes would be counted as a
> negative value and get around the cap here.
>
> 165 rpl_map->sge[sge_no].iov_len = sge_bytes;
>
> regards,
> dan carpenter
^ permalink raw reply
* [net v2 0/6][pull request] Intel Wired LAN Driver Updates
From: Jeff Kirsher @ 2013-09-27 12:35 UTC (permalink / raw)
To: davem; +Cc: Jeff Kirsher, netdev, gospo, sassmann
This series contains updates to igb and i40e.
Todd provides a fix for 82580 devices in igb, where the ethtool
loopback test was missing 82580 copper devices.
Jesse provides five fixes/cleanups to i40e based on feedback from
Joe Perches and the community.
v2: fixed up patch 5 in the series based on feedback from Joe Perches
and David Miller
The following are changes since commit f875691640cd3fa67f7ad1d3130ff9fa7fdca042:
Merge branch 'fixes-for-3.12' of git://gitorious.org/linux-can/linux-can
and are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/net master
Jesse Brandeburg (5):
i40e: use common failure flow
i40e: small clean ups from review
i40e: convert ret to aq_ret
i40e: better return values
i40e: clean up coccicheck reported errors
Todd Fujinaka (1):
igb: Fix ethtool loopback test for 82580 copper
drivers/net/ethernet/intel/i40e/i40e_adminq.c | 7 +-
drivers/net/ethernet/intel/i40e/i40e_common.c | 2 +-
drivers/net/ethernet/intel/i40e/i40e_main.c | 162 +++++++++++++-------------
drivers/net/ethernet/intel/igb/igb_ethtool.c | 3 +
4 files changed, 89 insertions(+), 85 deletions(-)
--
1.8.3.1
^ permalink raw reply
* [net v2 3/6] i40e: small clean ups from review
From: Jeff Kirsher @ 2013-09-27 12:35 UTC (permalink / raw)
To: davem; +Cc: Jesse Brandeburg, netdev, gospo, sassmann, Joe Perches,
Jeff Kirsher
In-Reply-To: <1380285358-15685-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Jesse Brandeburg <jesse.brandeburg@intel.com>
As mentioned by Joe Perches clean up a loop flow.
Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
CC: Joe Perches <joe@perches.com>
Tested-by: Kavindya Deegala <kavindya.s.deegala@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/i40e/i40e_main.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/intel/i40e/i40e_main.c b/drivers/net/ethernet/intel/i40e/i40e_main.c
index 67f8fd5..865bc6b 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_main.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_main.c
@@ -174,8 +174,7 @@ static int i40e_get_lump(struct i40e_pf *pf, struct i40e_lump_tracking *pile,
u16 needed, u16 id)
{
int ret = -ENOMEM;
- int i = 0;
- int j = 0;
+ int i, j;
if (!pile || needed == 0 || id >= I40E_PILE_VALID_BIT) {
dev_info(&pf->pdev->dev,
@@ -186,7 +185,7 @@ static int i40e_get_lump(struct i40e_pf *pf, struct i40e_lump_tracking *pile,
/* start the linear search with an imperfect hint */
i = pile->search_hint;
- while (i < pile->num_entries && ret < 0) {
+ while (i < pile->num_entries) {
/* skip already allocated entries */
if (pile->list[i] & I40E_PILE_VALID_BIT) {
i++;
@@ -205,6 +204,7 @@ static int i40e_get_lump(struct i40e_pf *pf, struct i40e_lump_tracking *pile,
pile->list[i+j] = id | I40E_PILE_VALID_BIT;
ret = i;
pile->search_hint = i + j;
+ break;
} else {
/* not enough, so skip over it and continue looking */
i += j;
--
1.8.3.1
^ permalink raw reply related
* [net v2 2/6] i40e: use common failure flow
From: Jeff Kirsher @ 2013-09-27 12:35 UTC (permalink / raw)
To: davem; +Cc: Jesse Brandeburg, netdev, gospo, sassmann, Joe Perches,
Jeff Kirsher
In-Reply-To: <1380285358-15685-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Jesse Brandeburg <jesse.brandeburg@intel.com>
As mentioned by Joe Perches, we should be using
foo = alloc(...)
if (!foo)
return -ENOMEM;
return 0;
Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
CC: Joe Perches <joe@perches.com>
Tested-by: Kavindya Deegala <kavindya.s.deegala@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/i40e/i40e_main.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/intel/i40e/i40e_main.c b/drivers/net/ethernet/intel/i40e/i40e_main.c
index 601d482..67f8fd5 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_main.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_main.c
@@ -101,10 +101,10 @@ int i40e_allocate_dma_mem_d(struct i40e_hw *hw, struct i40e_dma_mem *mem,
mem->size = ALIGN(size, alignment);
mem->va = dma_zalloc_coherent(&pf->pdev->dev, mem->size,
&mem->pa, GFP_KERNEL);
- if (mem->va)
- return 0;
+ if (!mem->va)
+ return -ENOMEM;
- return -ENOMEM;
+ return 0;
}
/**
@@ -136,10 +136,10 @@ int i40e_allocate_virt_mem_d(struct i40e_hw *hw, struct i40e_virt_mem *mem,
mem->size = size;
mem->va = kzalloc(size, GFP_KERNEL);
- if (mem->va)
- return 0;
+ if (!mem->va)
+ return -ENOMEM;
- return -ENOMEM;
+ return 0;
}
/**
--
1.8.3.1
^ permalink raw reply related
* [net v2 1/6] igb: Fix ethtool loopback test for 82580 copper
From: Jeff Kirsher @ 2013-09-27 12:35 UTC (permalink / raw)
To: davem; +Cc: Todd Fujinaka, netdev, gospo, sassmann, Jeff Kirsher
In-Reply-To: <1380285358-15685-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Todd Fujinaka <todd.fujinaka@intel.com>
Add back 82580 loopback tests to ethtool.
Signed-off-by: Todd Fujinaka <todd.fujinaka@intel.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/igb/igb_ethtool.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/ethernet/intel/igb/igb_ethtool.c b/drivers/net/ethernet/intel/igb/igb_ethtool.c
index 48cbc83..86d5142 100644
--- a/drivers/net/ethernet/intel/igb/igb_ethtool.c
+++ b/drivers/net/ethernet/intel/igb/igb_ethtool.c
@@ -1607,6 +1607,9 @@ static int igb_integrated_phy_loopback(struct igb_adapter *adapter)
igb_write_phy_reg(hw, I347AT4_PAGE_SELECT, 0);
igb_write_phy_reg(hw, PHY_CONTROL, 0x4140);
}
+ } else if (hw->phy.type == e1000_phy_82580) {
+ /* enable MII loopback */
+ igb_write_phy_reg(hw, I82580_PHY_LBK_CTRL, 0x8041);
}
/* add small delay to avoid loopback test failure */
--
1.8.3.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox