* Re: [patch] s2io: use snprintf() as a safety feature
From: David Miller @ 2015-01-20 0:45 UTC (permalink / raw)
To: dan.carpenter; +Cc: jdmason, netdev, kernel-janitors
In-Reply-To: <20150119193451.GB32634@mwanda>
From: Dan Carpenter <dan.carpenter@oracle.com>
Date: Mon, 19 Jan 2015 22:34:51 +0300
> "sp->desc[i]" has 25 characters. "dev->name" has 15 characters. If we
> used all 15 characters then the sprintf() would overflow.
>
> I changed the "sprintf(sp->name, "%s Neterion %s"" to snprintf(), as
> well, even though it can't overflow just to be consistent.
>
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Applied, thanks Dan.
^ permalink raw reply
* Re: [PATCH v2 net-next] net: ipv6: Add sysctl entry to disable MTU updates from RA
From: David Miller @ 2015-01-20 0:29 UTC (permalink / raw)
To: harouth; +Cc: dborkman, netdev
In-Reply-To: <001501d03439$28f6d670$7ae48350$@codeaurora.org>
From: "Harout Hedeshian" <harouth@codeaurora.org>
Date: Mon, 19 Jan 2015 15:42:08 -0700
> Indeed, the patch is based on previous modifications to add sysctl/proc
> entries for IPv6 parameters. It is done this way to maintain consistency. Do
> you think we need a v3 without the changes to the sysctl_binary.c and
> corresponding changes in includes/uapi?
Probably, yes.
^ permalink raw reply
* Payment
From: Finance Department @ 2015-01-19 23:11 UTC (permalink / raw)
Dear Recipient,
You have been awarded the sum of 8,000,000.00 (Eight Million Pounds sterling) with reference number 77100146 by office of the ministry of finance UK.Send us your personal details to deliver your funds.
Gloria Peter
^ permalink raw reply
* Re: [PATCH v2 net-next] net: ipv6: Add sysctl entry to disable MTU updates from RA
From: Daniel Borkmann @ 2015-01-19 23:01 UTC (permalink / raw)
To: Harout Hedeshian; +Cc: netdev
In-Reply-To: <001501d03439$28f6d670$7ae48350$@codeaurora.org>
On 01/19/2015 11:42 PM, Harout Hedeshian wrote:
...
> Indeed, the patch is based on previous modifications to add sysctl/proc
> entries for IPv6 parameters. It is done this way to maintain consistency. Do
> you think we need a v3 without the changes to the sysctl_binary.c and
> corresponding changes in includes/uapi?
Yep, please.
> d9333196572 ("ipv6: Allow accepting RA from local IP addresses.") is as
> recent as June 2014.
Yeah, that looks wrong unfortunately.
^ permalink raw reply
* Re: [PATCH v2 net-next] net: ipv6: Add sysctl entry to disable MTU updates from RA
From: Daniel Borkmann @ 2015-01-19 23:01 UTC (permalink / raw)
To: Harout Hedeshian; +Cc: netdev
In-Reply-To: <1421703363-3376-1-git-send-email-harouth@codeaurora.org>
On 01/19/2015 10:36 PM, Harout Hedeshian wrote:
...
> diff --git a/Documentation/networking/ip-sysctl.txt b/Documentation/networking/ip-sysctl.txt
> index 85b0221..da50faa 100644
> --- a/Documentation/networking/ip-sysctl.txt
> +++ b/Documentation/networking/ip-sysctl.txt
> @@ -1287,6 +1287,13 @@ accept_ra_rtr_pref - BOOLEAN
> Functional default: enabled if accept_ra is enabled.
> disabled if accept_ra is disabled.
>
> +accept_ra_mtu - BOOLEAN
> + Apply the MTU value specified in RA option 5 (RFC4861). If
> + disabled, the MTU specified in the RA will be ignored.
> +
> + Functional default: enabled if accept_ra is enabled.
> + disabled if accept_ra is disabled.
Nit: please indent correctly with tab here.
> +
...
> diff --git a/include/uapi/linux/ipv6.h b/include/uapi/linux/ipv6.h
> index 73cb02d..437a6a4 100644
> --- a/include/uapi/linux/ipv6.h
> +++ b/include/uapi/linux/ipv6.h
> @@ -169,6 +169,7 @@ enum {
> DEVCONF_SUPPRESS_FRAG_NDISC,
> DEVCONF_ACCEPT_RA_FROM_LOCAL,
> DEVCONF_USE_OPTIMISTIC,
> + DEVCONF_ACCEPT_RA_MTU,
> DEVCONF_MAX
> };
You also need a corresponding ipv6_store_devconf() entry, otherwise
netlink dumps will always see this setting as disabled.
^ permalink raw reply
* RE: [PATCH v2 net-next] net: ipv6: Add sysctl entry to disable MTU updates from RA
From: Harout Hedeshian @ 2015-01-19 22:42 UTC (permalink / raw)
To: 'Daniel Borkmann'; +Cc: netdev
In-Reply-To: <54BD80D6.40402@redhat.com>
> -----Original Message-----
> From: netdev-owner@vger.kernel.org [mailto:netdev-
> owner@vger.kernel.org] On Behalf Of Daniel Borkmann
> Sent: Monday, January 19, 2015 3:11 PM
> To: Harout Hedeshian
> Cc: netdev@vger.kernel.org
> Subject: Re: [PATCH v2 net-next] net: ipv6: Add sysctl entry to disable
MTU
> updates from RA
>
> On 01/19/2015 10:36 PM, Harout Hedeshian wrote:
> ...
> > diff --git a/include/uapi/linux/sysctl.h b/include/uapi/linux/sysctl.h
> > index 0956373..45e4fcf 100644
> > --- a/include/uapi/linux/sysctl.h
> > +++ b/include/uapi/linux/sysctl.h
> > @@ -570,6 +570,7 @@ enum {
> > NET_IPV6_PROXY_NDP=23,
> > NET_IPV6_ACCEPT_SOURCE_ROUTE=25,
> > NET_IPV6_ACCEPT_RA_FROM_LOCAL=26,
> > + NET_IPV6_ACCEPT_RA_MTU=27,
> > __NET_IPV6_MAX
> > };
> >
> > diff --git a/kernel/sysctl_binary.c b/kernel/sysctl_binary.c index
> > 7e7746a..16091e5 100644
> > --- a/kernel/sysctl_binary.c
> > +++ b/kernel/sysctl_binary.c
> > @@ -523,6 +523,7 @@ static const struct bin_table
> bin_net_ipv6_conf_var_table[] = {
> > { CTL_INT, NET_IPV6_PROXY_NDP,
> "proxy_ndp" },
> > { CTL_INT, NET_IPV6_ACCEPT_SOURCE_ROUTE,
> "accept_source_route" },
> > { CTL_INT, NET_IPV6_ACCEPT_RA_FROM_LOCAL,
> "accept_ra_from_local" },
> > + { CTL_INT, NET_IPV6_ACCEPT_RA_MTU,
> "accept_ra_mtu" },
> > {}
> > };
>
> Hm, afaik, the binary sysctl interface is deprecated and nothing should be
> adding entries there anymore. I believe you copied this over from commit
> d9333196572 ("ipv6: Allow accepting RA from local IP addresses.")? :/
Hi Daniel,
Indeed, the patch is based on previous modifications to add sysctl/proc
entries for IPv6 parameters. It is done this way to maintain consistency. Do
you think we need a v3 without the changes to the sysctl_binary.c and
corresponding changes in includes/uapi?
d9333196572 ("ipv6: Allow accepting RA from local IP addresses.") is as
recent as June 2014.
Thanks,
Harout
--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux
Foundation Collaborative Project
^ permalink raw reply
* Re: tcp: Do not apply TSO segment limit to non-TSO packets
From: Herbert Xu @ 2015-01-19 22:40 UTC (permalink / raw)
To: Eric Dumazet
Cc: Thomas Jarosch, netdev, Steffen Klassert, Ben Hutchings,
David S. Miller
In-Reply-To: <CANn89iLpgUEuHQvyJHR8g3q62-Hi-XfYKeVpLvG__UQLrqR5Bg@mail.gmail.com>
On Mon, Jan 19, 2015 at 02:38:47PM -0800, Eric Dumazet wrote:
>
> SYN and FIN packets are in the send queue.
>
> They are valid and might have a zero size.
Right, obviously I meant packets in between the SYN and the FIN.
Technically SYN/FIN are not really zero-sided since they carry
one bit of information and yes they do get cleaned while the ones
in the middle will not.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: tcp: Do not apply TSO segment limit to non-TSO packets
From: Eric Dumazet @ 2015-01-19 22:38 UTC (permalink / raw)
To: Herbert Xu
Cc: Thomas Jarosch, netdev, Steffen Klassert, Ben Hutchings,
David S. Miller
In-Reply-To: <20150119223635.GA8735@gondor.apana.org.au>
On Mon, Jan 19, 2015 at 2:36 PM, Herbert Xu <herbert@gondor.apana.org.au> wrote:
> On Mon, Jan 19, 2015 at 09:19:48AM -0800, Eric Dumazet wrote:
>> Zero sized packets are valid, just take a look at tcpdump ;)
>
> But zero-sized packets in the send queue are not valid and will
> not ever be cleaned, which is what triggered the original bug.
SYN and FIN packets are in the send queue.
They are valid and might have a zero size.
^ permalink raw reply
* Re: tcp: Do not apply TSO segment limit to non-TSO packets
From: Herbert Xu @ 2015-01-19 22:36 UTC (permalink / raw)
To: Eric Dumazet
Cc: Thomas Jarosch, netdev, Steffen Klassert, Ben Hutchings,
David S. Miller
In-Reply-To: <CANn89i+U-PFbuUrp08s3Ec8BmjPFq1zj8Aj2=vPVO4-iiLkTuw@mail.gmail.com>
On Mon, Jan 19, 2015 at 09:19:48AM -0800, Eric Dumazet wrote:
> Zero sized packets are valid, just take a look at tcpdump ;)
But zero-sized packets in the send queue are not valid and will
not ever be cleaned, which is what triggered the original bug.
Although I'm not sure whether a WARN_ON will actually help since
it won't tell you why there is a zero-sized packet on the queue,
just the fact that there is. You'll know you've got a zero-sized
packet on the queue anyway by looking at the tcpdump.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH v2 net-next] net: ipv6: Add sysctl entry to disable MTU updates from RA
From: Daniel Borkmann @ 2015-01-19 22:10 UTC (permalink / raw)
To: Harout Hedeshian; +Cc: netdev
In-Reply-To: <1421703363-3376-1-git-send-email-harouth@codeaurora.org>
On 01/19/2015 10:36 PM, Harout Hedeshian wrote:
...
> diff --git a/include/uapi/linux/sysctl.h b/include/uapi/linux/sysctl.h
> index 0956373..45e4fcf 100644
> --- a/include/uapi/linux/sysctl.h
> +++ b/include/uapi/linux/sysctl.h
> @@ -570,6 +570,7 @@ enum {
> NET_IPV6_PROXY_NDP=23,
> NET_IPV6_ACCEPT_SOURCE_ROUTE=25,
> NET_IPV6_ACCEPT_RA_FROM_LOCAL=26,
> + NET_IPV6_ACCEPT_RA_MTU=27,
> __NET_IPV6_MAX
> };
>
> diff --git a/kernel/sysctl_binary.c b/kernel/sysctl_binary.c
> index 7e7746a..16091e5 100644
> --- a/kernel/sysctl_binary.c
> +++ b/kernel/sysctl_binary.c
> @@ -523,6 +523,7 @@ static const struct bin_table bin_net_ipv6_conf_var_table[] = {
> { CTL_INT, NET_IPV6_PROXY_NDP, "proxy_ndp" },
> { CTL_INT, NET_IPV6_ACCEPT_SOURCE_ROUTE, "accept_source_route" },
> { CTL_INT, NET_IPV6_ACCEPT_RA_FROM_LOCAL, "accept_ra_from_local" },
> + { CTL_INT, NET_IPV6_ACCEPT_RA_MTU, "accept_ra_mtu" },
> {}
> };
Hm, afaik, the binary sysctl interface is deprecated and nothing
should be adding entries there anymore. I believe you copied this
over from commit d9333196572 ("ipv6: Allow accepting RA from local
IP addresses.")? :/
^ permalink raw reply
* Re: [PATCH net] ipv6: stop sending PTB packets for MTU < 1280
From: Hagen Paul Pfeifer @ 2015-01-19 22:05 UTC (permalink / raw)
To: Hannes Frederic Sowa; +Cc: David Miller, netdev, stable, Fernando Gont
In-Reply-To: <1421697951.13047.9.camel@stressinduktion.org>
On 19 January 2015 at 21:05, Hannes Frederic Sowa
<hannes@stressinduktion.org> wrote:
> Oh yes, although we never exposed an ip route knob for that, it is still
> possible users did set manually, so we cannot get rid of that, agreed.
I thought about that, sure but come to the conclusion that the code
cleanup outweigh an potential user somewhere in space (well, the use
case is broken and should be fixed). Additionally, I left the
RTAX_FEATURE_ALLFRAG (as mentioned) and removed all related
functionality - no visible API change (except no-op behavior).
Davem, I will sent the patch anyway. Feel free to accept/ignore.
Hagen
^ permalink raw reply
* Re: [PATCH] ethernet: atheros: Add nss-gmac driver
From: wstephen-sgV2jX0FEOL9JmXXK+q4OQ @ 2015-01-19 21:58 UTC (permalink / raw)
To: Arnd Bergmann
Cc: wstephen-sgV2jX0FEOL9JmXXK+q4OQ, jcliburn-Re5JQEeQqe8AvxtiuMwx3w,
grant.likely-QSEj5FYQhm4dnm+yROfE0A,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA, devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <2318041.V2OJAPu7gC@wuerfel>
> On Thursday 15 January 2015 08:12:51 wstephen-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org wrote:
>>
>> The nss-gmac driver is for the internal GMAC IP in the Qualcomm IPQ806x
>> SoC. There are 2 ARM cores and 2 NSS cores inside the IPQ806x SoC. The
>> main purpose of these NSS cores is to offload the networking stack from
>> the ARM cores to achieve high performance at routing/ipsec..etc without
>> exhausting the ARM core CPU cycles. There is another nss-drv driver for
>> the NSS cores.
>
> I see.
>
>> The nss-gmac driver is designed to work standalone or with the nss-drv
>> driver so the switchable data plane overlay was implemented. When it
>> worked standalone, the data plane is running on the ARM core as a
>> standard
>> networking driver.
>
> How do you decide which way it gets used on a particular system?
>
By default the GMAC driver uses a native (Host ARM CPU) based data plane.
If the configuration loads the offload nss-drv driver, the offload driver
registers an overlay with the GMAC.
>> The nss-drv driver can take over the data plane and
>> offload it to the NSS cores. The STMicro stmmac driver does not have
>> this
>> kind of overlay design so is not suitable for IPQ806x. This is why we
>> don't based on the stmmac driver
>
> Which kind of offload is implemented specifically? 'data plane' sounds
> fairly generic and could mean anything, and the code isn't readable enough
> in its current form for me to find out.
The Network Subsystem (NSS core) provides a GMAC pass-through until it is
given a rule to offload work. Once a rule is given, it is capable of
performing: bridging, IPv4 NAT/FWD, IPv6 NAT/FWD, IPSec, LAG, and other
protocols.
>
> Arnd
>
Hope this clarify your question!
Thanks,
Stephen
--
To unsubscribe from this list: send the line "unsubscribe devicetree" 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: [RFC PATCH v2 1/2] net: af_packet support for direct ring access in user space
From: Neil Horman @ 2015-01-19 21:45 UTC (permalink / raw)
To: David Miller
Cc: john.fastabend, netdev, danny.zhou, dborkman, john.ronciak,
hannes, brouer
In-Reply-To: <20150114.153509.1264618607573705890.davem@davemloft.net>
On Wed, Jan 14, 2015 at 03:35:09PM -0500, David Miller wrote:
> From: John Fastabend <john.fastabend@gmail.com>
> Date: Mon, 12 Jan 2015 20:35:11 -0800
>
> > + if ((region.direction != DMA_BIDIRECTIONAL) &&
> > + (region.direction != DMA_TO_DEVICE) &&
> > + (region.direction != DMA_FROM_DEVICE))
> > + return -EFAULT;
> ...
> > + if ((umem->nmap == npages) &&
> > + (0 != dma_map_sg(dev->dev.parent, umem->sglist,
> > + umem->nmap, region.direction))) {
> > + region.iova = sg_dma_address(umem->sglist) + offset;
>
> I am having trouble seeing how this can work.
>
> dma_map_{single,sg}() mappings need synchronization after a DMA
> transfer takes place.
>
> For example if the DMA occurs to the device, then that region can
> be cached in the PCI controller's internal caches and thus future
> cpu writes into that memory region will not be seen, until a
> dma_sync_*() is invoked.
>
> That isn't going to happen when the device transmit queue is
> being completely managed in userspace.
>
> And this takes us back to the issue of protection, I don't think
> it is addressed properly yet.
>
> CAP_NET_ADMIN privileges do not mean "can crap all over memory"
> yet with this feature that can still happen.
>
> If we are dealing with a device which cannot provide strict protection
> to only the process's locked local pages, you have to do something
> to implement that protection.
>
> And you have _exactly_ one option to do that, abstracting the page
> addresses and eating a system call to trigger the sends, so that you
> can read from the user's (fake) descriptors and write into the real
> descriptors (translating the DMA addresses along the way) and
> triggering the TX doorbell.
>
> I am not going to consider seriously an implementation that says "yeah
> sometimes the user can crap onto other people's memory", this isn't
> MS-DOS, it's a system where proper memory protections are mandatory
> rather than optional.
>
Another stupid question - If we can't provide protection from the device to
ensure memory coherency, can we mitigate the problem by creating an iommu group
for the device?
I'd mentioned to john the possibility of using the existing dfwd offload
operations to do the allocation of queues so that we could reuse that code instead
of having to create a set of new queue allocation routines. What if, instead of
the dfwd queue allocation methods, we used sriov functionality here? I.e.,
plumb a virtual function, and set it in its own iommu group, but instead of
passing it off to a guest, we just let the host use it? That gives us the
opportunity to tear down the iommu mappings should the process exit, so if the
physical pages get re-allocated while DMA is in flight, we can just take the
iommu exception and avoid the memory corruption.
Its not perfect, in that we're still not syncing when we should be, but I think
it would be safe at least.
Thoughts?
Neil
^ permalink raw reply
* [PATCH v2 net-next] net: ipv6: Add sysctl entry to disable MTU updates from RA
From: Harout Hedeshian @ 2015-01-19 21:36 UTC (permalink / raw)
To: netdev; +Cc: Harout Hedeshian
The kernel forcefully applies MTU values received in router
advertisements provided the new MTU is less than the current. This
behavior is undesirable when the user space is managing the MTU. Instead
a sysctl flag 'accept_ra_mtu' is introduced such that the user space
can control whether or not RA provided MTU updates should be applied. The
default behavior is unchanged; user space must explicitly set this flag
to 0 for RA MTUs to be ignored.
Signed-off-by: Harout Hedeshian <harouth@codeaurora.org>
---
Documentation/networking/ip-sysctl.txt | 7 +++++++
include/linux/ipv6.h | 1 +
include/uapi/linux/ipv6.h | 1 +
include/uapi/linux/sysctl.h | 1 +
kernel/sysctl_binary.c | 1 +
net/ipv6/addrconf.c | 9 +++++++++
net/ipv6/ndisc.c | 2 +-
7 files changed, 21 insertions(+), 1 deletion(-)
diff --git a/Documentation/networking/ip-sysctl.txt b/Documentation/networking/ip-sysctl.txt
index 85b0221..da50faa 100644
--- a/Documentation/networking/ip-sysctl.txt
+++ b/Documentation/networking/ip-sysctl.txt
@@ -1287,6 +1287,13 @@ accept_ra_rtr_pref - BOOLEAN
Functional default: enabled if accept_ra is enabled.
disabled if accept_ra is disabled.
+accept_ra_mtu - BOOLEAN
+ Apply the MTU value specified in RA option 5 (RFC4861). If
+ disabled, the MTU specified in the RA will be ignored.
+
+ Functional default: enabled if accept_ra is enabled.
+ disabled if accept_ra is disabled.
+
accept_redirects - BOOLEAN
Accept Redirects.
diff --git a/include/linux/ipv6.h b/include/linux/ipv6.h
index c694e7b..2805062 100644
--- a/include/linux/ipv6.h
+++ b/include/linux/ipv6.h
@@ -52,6 +52,7 @@ struct ipv6_devconf {
__s32 force_tllao;
__s32 ndisc_notify;
__s32 suppress_frag_ndisc;
+ __s32 accept_ra_mtu;
void *sysctl;
};
diff --git a/include/uapi/linux/ipv6.h b/include/uapi/linux/ipv6.h
index 73cb02d..437a6a4 100644
--- a/include/uapi/linux/ipv6.h
+++ b/include/uapi/linux/ipv6.h
@@ -169,6 +169,7 @@ enum {
DEVCONF_SUPPRESS_FRAG_NDISC,
DEVCONF_ACCEPT_RA_FROM_LOCAL,
DEVCONF_USE_OPTIMISTIC,
+ DEVCONF_ACCEPT_RA_MTU,
DEVCONF_MAX
};
diff --git a/include/uapi/linux/sysctl.h b/include/uapi/linux/sysctl.h
index 0956373..45e4fcf 100644
--- a/include/uapi/linux/sysctl.h
+++ b/include/uapi/linux/sysctl.h
@@ -570,6 +570,7 @@ enum {
NET_IPV6_PROXY_NDP=23,
NET_IPV6_ACCEPT_SOURCE_ROUTE=25,
NET_IPV6_ACCEPT_RA_FROM_LOCAL=26,
+ NET_IPV6_ACCEPT_RA_MTU=27,
__NET_IPV6_MAX
};
diff --git a/kernel/sysctl_binary.c b/kernel/sysctl_binary.c
index 7e7746a..16091e5 100644
--- a/kernel/sysctl_binary.c
+++ b/kernel/sysctl_binary.c
@@ -523,6 +523,7 @@ static const struct bin_table bin_net_ipv6_conf_var_table[] = {
{ CTL_INT, NET_IPV6_PROXY_NDP, "proxy_ndp" },
{ CTL_INT, NET_IPV6_ACCEPT_SOURCE_ROUTE, "accept_source_route" },
{ CTL_INT, NET_IPV6_ACCEPT_RA_FROM_LOCAL, "accept_ra_from_local" },
+ { CTL_INT, NET_IPV6_ACCEPT_RA_MTU, "accept_ra_mtu" },
{}
};
diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index f7c8bbe..cdd70ed 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -201,6 +201,7 @@ static struct ipv6_devconf ipv6_devconf __read_mostly = {
.disable_ipv6 = 0,
.accept_dad = 1,
.suppress_frag_ndisc = 1,
+ .accept_ra_mtu = 1,
};
static struct ipv6_devconf ipv6_devconf_dflt __read_mostly = {
@@ -238,6 +239,7 @@ static struct ipv6_devconf ipv6_devconf_dflt __read_mostly = {
.disable_ipv6 = 0,
.accept_dad = 1,
.suppress_frag_ndisc = 1,
+ .accept_ra_mtu = 1,
};
/* Check if a valid qdisc is available */
@@ -5253,6 +5255,13 @@ static struct addrconf_sysctl_table
.proc_handler = proc_dointvec,
},
{
+ .procname = "accept_ra_mtu",
+ .data = &ipv6_devconf.accept_ra_mtu,
+ .maxlen = sizeof(int),
+ .mode = 0644,
+ .proc_handler = proc_dointvec,
+ },
+ {
/* sentinel */
}
},
diff --git a/net/ipv6/ndisc.c b/net/ipv6/ndisc.c
index 6828667..8a9d7c1 100644
--- a/net/ipv6/ndisc.c
+++ b/net/ipv6/ndisc.c
@@ -1348,7 +1348,7 @@ skip_routeinfo:
}
}
- if (ndopts.nd_opts_mtu) {
+ if (ndopts.nd_opts_mtu && in6_dev->cnf.accept_ra_mtu) {
__be32 n;
u32 mtu;
--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
^ permalink raw reply related
* RE: [PATCH net-next] net: ipv6: Add sysctl entry to disable MTU updates from RA
From: Harout Hedeshian @ 2015-01-19 21:31 UTC (permalink / raw)
To: 'David Miller'; +Cc: netdev
In-Reply-To: <20150119.155807.377681769985591321.davem@davemloft.net>
> -----Original Message-----
> From: David Miller [mailto:davem@davemloft.net]
> Sent: Monday, January 19, 2015 1:58 PM
> To: harouth@codeaurora.org
> Cc: netdev@vger.kernel.org
> Subject: Re: [PATCH net-next] net: ipv6: Add sysctl entry to disable MTU
> updates from RA
>
> From: Harout Hedeshian <harouth@codeaurora.org>
> Date: Fri, 16 Jan 2015 18:02:38 -0700
>
> > The kernel forcefully applies MTU values received in router
> > advertisements provided the new MTU is less than the current. This
> > behavior is undesirable when the user space is managing the MTU.
> > Instead a sysctl flag 'accept_ra_mtu' is introduced such that the user
> > space can control whether or not RA provided MTU updates should be
> > applied. The default behavior is unchanged; user space must explicitly
> > set this flag to 0 for RA MTUs to be ignored.
> >
> > Signed-off-by: Harout Hedeshian <harouth@codeaurora.org>
>
> A really sloppy submission, sorry I can't apply this.
>
> > + { CTL_INT, NET_IPV6_ACCEPT_RA_MTU,
> "accept_ra_mtu" },
Yes, it appears include/uapi/linux/sysctl.h was missed during a rebase. I
will correct this.
> This isn't defined anywhere, you left out some file while creating your
patch.
>
> kernel/sysctl_binary.c:526:13: error: ?NET_IPV6_ACCEPT_RA_MTU?
> undeclared here (not in a function)
>
>
> > - if (ndopts.nd_opts_mtu) {
> > + if (ndopts.nd_opts_mtu && in6_dev->cnf.accept_ra_mtu) {
>
> Too many spaced before the &&
Hmm. Looks like checkpatch.pl did does not catch this mistake. I only get
one warning about a line being too long:
harouth@harouth-lnx:/local/vg_local/lv_mainline/net_next/net-next$
./scripts/checkpatch.pl
0001-net-ipv6-Add-sysctl-entry-to-disable-MTU-updates-fro.patch
WARNING: line over 80 characters
#74: FILE: kernel/sysctl_binary.c:526:
+ { CTL_INT, NET_IPV6_ACCEPT_RA_MTU,
"accept_ra_mtu" },
total: 0 errors, 1 warnings, 0 checks, 69 lines checked
0001-net-ipv6-Add-sysctl-entry-to-disable-MTU-updates-fro.patch has style
problems, please review.
I will send an updated patch (v2) in a moment.
V2 patch passes compilation in sysctl_binary.c:
harouth@harouth-lnx:/local/vg_local/lv_mainline/net_next/net-next$ make -j8
ARCH=um
..
CC kernel/sysctl.o
CC kernel/sysctl_binary.o
..
Thanks,
Harout
--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux
Foundation Collaborative Project
^ permalink raw reply
* Re: ipvlan: Initial check-in of the IPVLAN driver.
From: David Miller @ 2015-01-19 21:20 UTC (permalink / raw)
To: dan.carpenter; +Cc: maheshb, netdev
In-Reply-To: <20150119144011.GA19086@mwanda>
From: Dan Carpenter <dan.carpenter@oracle.com>
Date: Mon, 19 Jan 2015 17:40:11 +0300
> The patch 2ad7bf363841: "ipvlan: Initial check-in of the IPVLAN
> driver." from Nov 23, 2014, leads to the following static checker
> warning:
>
> drivers/net/ipvlan/ipvlan_core.c:380 ipvlan_process_v6_outbound()
> warn: 'dst' isn't an ERR_PTR
>
> drivers/net/ipvlan/ipvlan_core.c
> 378
> 379 dst = ip6_route_output(dev_net(dev), NULL, &fl6);
> 380 if (IS_ERR(dst))
> 381 goto err;
>
> The ip6_route_output() function is not documented but it always returns
> a valid pointer. I believe you are supposed to check something like:
>
> if (dst->error) {
> ret = dst->error;
> goto error;
> }
>
> 382
> 383 skb_dst_drop(skb);
> 384 skb_dst_set(skb, dst);
This is correct.
^ permalink raw reply
* Re: [PATCH] phonet netlink: allow multiple messages per skb in route dump
From: David Miller @ 2015-01-19 21:20 UTC (permalink / raw)
To: johannes; +Cc: netdev, sakari.ailus, courmisch, johannes.berg
In-Reply-To: <1421666124-16055-1-git-send-email-johannes@sipsolutions.net>
From: Johannes Berg <johannes@sipsolutions.net>
Date: Mon, 19 Jan 2015 12:15:24 +0100
> From: Johannes Berg <johannes.berg@intel.com>
>
> My previous patch to this file changed the code to be bug-compatible
> towards userspace. Unless userspace (which I wasn't able to find)
> implements the dump reader by hand in a wrong way, this isn't needed.
> If it uses libnl or similar code putting multiple messages into a
> single SKB is far more efficient.
>
> Change the code to do this. While at it, also clean it up and don't
> use so many variables - just store the address in the callback args
> directly.
>
> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net 0/2] r8152: couldn't read OCP_SRAM_DATA
From: David Miller @ 2015-01-19 21:18 UTC (permalink / raw)
To: hayeswang; +Cc: netdev, nic_swsd, linux-kernel, linux-usb
In-Reply-To: <1394712342-15778-126-Taiwan-albertk@realtek.com>
From: Hayes Wang <hayeswang@realtek.com>
Date: Mon, 19 Jan 2015 17:02:44 +0800
> Read OCP_SRAM_DATA would read additional bytes and may let
> the hw abnormal.
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next 1/5] bonding: keep bond interface carrier off until at least one active member
From: Jay Vosburgh @ 2015-01-19 21:16 UTC (permalink / raw)
To: Jonathan Toppins
Cc: netdev, Scott Feldman, Andy Gospodarek, Veaceslav Falico,
Nikolay Aleksandrov
In-Reply-To: <1421423848-414-2-git-send-email-jtoppins@cumulusnetworks.com>
Jonathan Toppins <jtoppins@cumulusnetworks.com> wrote:
>From: Scott Feldman <sfeldma@cumulusnetworks.com>
>
>Bonding driver parameter min_links is now used to signal upper-level
>protocols of bond status. The way it works is if the total number of
>active members in slaves drops below min_links, the bond link carrier
>will go down, signaling upper levels that bond is inactive. When active
>members returns to >= min_links, bond link carrier will go up (RUNNING),
>and protocols can resume. When bond is carrier down, member ports are
>in stp fwd state blocked (rather than normal disabled state), so
>low-level ctrl protocols (LACP) can still get in and be processed by
>bonding driver.
Presuming that "stp" is Spanning Tree, is the last sentence
above actually describing the behavior of a bridge port when a bond is
the member of the bridge? I'm not sure I understand what "member ports"
refers to (bridge ports or bonding slaves).
One code comment, below...
>LACP will still do it's job while bond is carrier off, and if bond members
>become active, bond carrier will be turned back on, signaling higher-level
>protocols that bond is viable.
>
>Suggested setting of min_links is 1, rather than the default of zero.
>Using min_links=1 says that at least 1 slave must be active within bond
>for bond to be carrier on.
>
>Finally, when min_links bonding option is changed update carrier status.
>
>Cc: Scott Feldman <sfeldma@gmail.com>
>Cc: Andy Gospodarek <gospo@cumulusnetworks.com>
>Signed-off-by: Jonathan Toppins <jtoppins@cumulusnetworks.com>
>---
> drivers/net/bonding/bond_3ad.c | 18 ++++++++++++++----
> drivers/net/bonding/bond_main.c | 2 +-
> drivers/net/bonding/bond_options.c | 1 +
> include/net/bonding.h | 1 +
> 4 files changed, 17 insertions(+), 5 deletions(-)
>
>diff --git a/drivers/net/bonding/bond_3ad.c b/drivers/net/bonding/bond_3ad.c
>index 8baa87d..e9b706f 100644
>--- a/drivers/net/bonding/bond_3ad.c
>+++ b/drivers/net/bonding/bond_3ad.c
>@@ -189,6 +189,7 @@ static inline int __agg_has_partner(struct aggregator *agg)
> static inline void __disable_port(struct port *port)
> {
> bond_set_slave_inactive_flags(port->slave, BOND_SLAVE_NOTIFY_LATER);
>+ bond_3ad_set_carrier(port->slave->bond);
> }
>
> /**
>@@ -199,8 +200,10 @@ static inline void __enable_port(struct port *port)
> {
> struct slave *slave = port->slave;
>
>- if ((slave->link == BOND_LINK_UP) && bond_slave_is_up(slave))
>+ if ((slave->link == BOND_LINK_UP) && bond_slave_is_up(slave)) {
> bond_set_slave_active_flags(slave, BOND_SLAVE_NOTIFY_LATER);
>+ bond_3ad_set_carrier(slave->bond);
>+ }
> }
>
> /**
>@@ -2372,8 +2375,10 @@ void bond_3ad_handle_link_change(struct slave *slave, char link)
> int bond_3ad_set_carrier(struct bonding *bond)
> {
> struct aggregator *active;
>- struct slave *first_slave;
>+ struct slave *first_slave, *slave;
>+ struct list_head *iter;
> int ret = 1;
>+ int active_slaves = 0;
>
> rcu_read_lock();
> first_slave = bond_first_slave_rcu(bond);
>@@ -2381,10 +2386,15 @@ int bond_3ad_set_carrier(struct bonding *bond)
> ret = 0;
> goto out;
> }
>+
>+ bond_for_each_slave_rcu(bond, slave, iter)
>+ if (SLAVE_AD_INFO(slave)->aggregator.is_active)
>+ active_slaves++;
>+
> active = __get_active_agg(&(SLAVE_AD_INFO(first_slave)->aggregator));
>- if (active) {
>+ if (active && __agg_has_partner(active)) {
Why "__agg_has_partner"? Since the "else" of this clause is:
} else if (netif_carrier_ok(bond->dev)) {
netif_carrier_off(bond->dev);
}
I'm wondering if this will do the right thing for the case that
there are no LACP partners at all (e.g., the switch ports do not have
LACP enabled), in which case the active aggregator should be a single
"individual" port as a fallback, but will not have a partner.
-J
> /* are enough slaves available to consider link up? */
>- if (active->num_of_ports < bond->params.min_links) {
>+ if (active_slaves < bond->params.min_links) {
> if (netif_carrier_ok(bond->dev)) {
> netif_carrier_off(bond->dev);
> goto out;
>diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
>index 0dceba1..02ffedb 100644
>--- a/drivers/net/bonding/bond_main.c
>+++ b/drivers/net/bonding/bond_main.c
>@@ -334,7 +334,7 @@ static int bond_vlan_rx_kill_vid(struct net_device *bond_dev,
> *
> * Returns zero if carrier state does not change, nonzero if it does.
> */
>-static int bond_set_carrier(struct bonding *bond)
>+int bond_set_carrier(struct bonding *bond)
> {
> struct list_head *iter;
> struct slave *slave;
>diff --git a/drivers/net/bonding/bond_options.c b/drivers/net/bonding/bond_options.c
>index 9bd538d4..4df2894 100644
>--- a/drivers/net/bonding/bond_options.c
>+++ b/drivers/net/bonding/bond_options.c
>@@ -1181,6 +1181,7 @@ static int bond_option_min_links_set(struct bonding *bond,
> netdev_info(bond->dev, "Setting min links value to %llu\n",
> newval->value);
> bond->params.min_links = newval->value;
>+ bond_set_carrier(bond);
>
> return 0;
> }
>diff --git a/include/net/bonding.h b/include/net/bonding.h
>index 983a94b..29f53ea 100644
>--- a/include/net/bonding.h
>+++ b/include/net/bonding.h
>@@ -525,6 +525,7 @@ void bond_sysfs_slave_del(struct slave *slave);
> int bond_enslave(struct net_device *bond_dev, struct net_device *slave_dev);
> int bond_release(struct net_device *bond_dev, struct net_device *slave_dev);
> u32 bond_xmit_hash(struct bonding *bond, struct sk_buff *skb);
>+int bond_set_carrier(struct bonding *bond);
> void bond_select_active_slave(struct bonding *bond);
> void bond_change_active_slave(struct bonding *bond, struct slave *new_active);
> void bond_create_debugfs(void);
>--
>1.7.10.4
---
-Jay Vosburgh, jay.vosburgh@canonical.com
^ permalink raw reply
* Re: [PATCH net-next 1/7] r8152: adjust rx_bottom
From: David Miller @ 2015-01-19 21:13 UTC (permalink / raw)
To: sfeldma-Re5JQEeQqe8AvxtiuMwx3w
Cc: hayeswang-Rasf1IRRPZFBDgjK7y7TUQ, netdev-u79uwXL29TY76Z2rM5mHXA,
nic_swsd-Rasf1IRRPZFBDgjK7y7TUQ,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <CAE4R7bAv26f-+DW-TmjspJxAb-3Add5sf563mnMUTGCyiqG3rQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
From: Scott Feldman <sfeldma-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date: Mon, 19 Jan 2015 00:03:42 -0800
> On Sun, Jan 18, 2015 at 11:13 PM, Hayes Wang <hayeswang-Rasf1IRRPZFBDgjK7y7TUQ@public.gmane.org> wrote:
>> @@ -1746,7 +1746,18 @@ find_next_rx:
>> }
>>
>> submit:
>> - r8152_submit_rx(tp, agg, GFP_ATOMIC);
>> + if (!ret) {
>> + ret = r8152_submit_rx(tp, agg, GFP_ATOMIC);
>> + } else {
>> + urb->actual_length = 0;
>> + list_add_tail(&agg->list, next);
>
> Do you need a spin_lock_irqsave(&tp->rx_lock, flags) around this?
Indeed, and rtl_start_rx() seems to also access agg->list without
proper locking.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" 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: [PATCH] i40e: don't enable and init FCOE by default when do PF reset
From: Dev, Vasu @ 2015-01-19 21:10 UTC (permalink / raw)
To: ethan zhao, Kirsher, Jeffrey T
Cc: e1000-devel@lists.sourceforge.net, brian.maly@oracle.com,
Allan, Bruce W, Brandeburg, Jesse, Parikh, Neerav, Linux NICS,
Ronciak, John, netdev@vger.kernel.org, Ethan Zhao,
linux-kernel@vger.kernel.org
In-Reply-To: <54B9D082.9050601@oracle.com>
> -----Original Message-----
> From: ethan zhao [mailto:ethan.zhao@oracle.com]
> Sent: Friday, January 16, 2015 7:01 PM
> To: Kirsher, Jeffrey T
> Cc: Dev, Vasu; Ethan Zhao; Ronciak, John; Brandeburg, Jesse; Allan, Bruce W;
> Wyborny, Carolyn; Skidmore, Donald C; Rose, Gregory V; Vick, Matthew;
> Williams, Mitch A; Parikh, Neerav; Linux NICS; e1000-
> devel@lists.sourceforge.net; netdev@vger.kernel.org; linux-
> kernel@vger.kernel.org; brian.maly@oracle.com
> Subject: Re: [PATCH] i40e: don't enable and init FCOE by default when do PF
> reset
>
> Vasu,
>
> What' your idea about the v2, any suggestion ? Jeff is looking forward to
> see it.
>
Jeff was asking for v2 in response to your last comment as "disable FCOE as default configuration as a temporary step" but I think that is the fix and user should n't enable FCoE until they have FCoE enabled X710 FCoE with either fabric or VN2VN mode FCoE setup.
Thanks,
Vasu
> Thanks,
> Ethan
>
>
> On 2015/1/16 22:47, Jeff Kirsher wrote:
> > On Fri, 2015-01-16 at 09:48 +0800, ethan zhao wrote:
> >> Vasu,
> >>
> >> OK, disable FCOE as default configuration as a temporary step to
> >> make it work.
> > Sounds like I should expect a v2 coming, correct?
> >
> >>
> >> Thanks,
> >> Ethan
> >>
> >> On 2015/1/16 7:45, Dev, Vasu wrote:
> >>>> -----Original Message-----
> >>>> From: ethan zhao [mailto:ethan.zhao@oracle.com]
> >>>> Sent: Tuesday, January 13, 2015 6:41 PM
> >>>> To: Dev, Vasu
> >>>> Cc: Ethan Zhao; Ronciak, John; Kirsher, Jeffrey T; Brandeburg,
> >>>> Jesse; Allan, Bruce W; Wyborny, Carolyn; Skidmore, Donald C; Rose,
> >>>> Gregory V; Vick, Matthew; Williams, Mitch A; Parikh, Neerav; Linux
> >>>> NICS; e1000- devel@lists.sourceforge.net; netdev@vger.kernel.org;
> >>>> linux- kernel@vger.kernel.org; brian.maly@oracle.com
> >>>> Subject: Re: [PATCH] i40e: don't enable and init FCOE by default
> >>>> when do PF reset
> >>>>
> >>>> Vasu,
> >>>>
> >>>> On 2015/1/14 3:38, Dev, Vasu wrote:
> >>>>>> -----Original Message-----
> >>>>>>>>> diff --git a/drivers/net/ethernet/intel/i40e/i40e_main.c
> >>>>>>>>> b/drivers/net/ethernet/intel/i40e/i40e_main.c
> >>>>>>>>> index a5f2660..a2572cc 100644
> >>>>>>>>> --- a/drivers/net/ethernet/intel/i40e/i40e_main.c
> >>>>>>>>> +++ b/drivers/net/ethernet/intel/i40e/i40e_main.c
> >>>>>>>>> @@ -6180,9 +6180,12 @@ static void
> >>>>>>>>> i40e_reset_and_rebuild(struct i40e_pf *pf, bool reinit)
> >>>>>>>>> }
> >>>>>>>>> #endif /* CONFIG_I40E_DCB */
> >>>>>>>>> #ifdef I40E_FCOE
> >>>>>>>>> - ret = i40e_init_pf_fcoe(pf);
> >>>>>>>>> - if (ret)
> >>>>>>>>> - dev_info(&pf->pdev->dev, "init_pf_fcoe failed: %d\n", ret);
> >>>>>>>>> + if (pf->flags & I40E_FLAG_FCOE_ENABLED) {
> >>>>>>>>> + ret = i40e_init_pf_fcoe(pf);
> >>>>>>> Calling i40e_init_pf_fcoe() here conflicts with its
> >>>>>> I40E_FLAG_FCOE_ENABLED pre-condition since
> >>>> I40E_FLAG_FCOE_ENABLED is
> >>>>>> set by very same i40e_init_pf_fcoe(), in turn i40e_init_pf_fcoe()
> >>>>>> will never get called.
> >>>>>>
> >>>>>> I don't think so, here ,i40e_reset_and_rebuild() is not the
> >>>>>> only and the first place that i40e_init_pf_fcoe() is called, see
> >>>>>> i40e_probe(), that is the first chance.
> >>>>>>
> >>>>>> i40e_probe()
> >>>>>> -->i40e_sw_init()
> >>>>>> -->i40e_init_pf_fcoe()
> >>>>>>
> >>>>>> And the I40E_FLAG_FCOE_ENABLED is possible be set by
> >>>>>> i40e_fcoe_enable() or i40e_fcoe_disable() interface before the
> >>>>>> reset action is to be done.
> >>>>>>
> >>>>> It is set by i40e_init_pf_fcoe() and you are right that the
> >>>>> modified call flow
> >>>> by your patch won't impact setting of I40E_FLAG_FCOE_ENABLED
> anyway
> >>>> which could have prevented calling i40e_init_pf_fcoe() as I
> >>>> described above, so this is not an issue with the patch.
> >>>>>> BTW, the reason I post this patch is that we hit a bug, after
> >>>>>> setup vlan, the PF is enabled to FCOE.
> >>>>>>
> >>>>> Then that BUG would still remain un-fixed and calling
> >>>>> i40e_init_pf_fcoe()
> >>>> under I40E_FLAG_FCOE_ENABLED flag really won't affect call flow to
> >>>> fix anything. I mean I40E_FLAG_FCOE_ENABLED condition will be true
> >>>> with "pf-
> >>>>> hw.func_caps.fcoe == true" and otherwise calling
> >>>>> i40e_init_pf_fcoe() simply
> >>>> returns back early on after checking "pf->hw.func_caps.fcoe ==
> >>>> false", so how that bug is fixed here by added
> I40E_FLAG_FCOE_ENABLED condition ?
> >>>> What is the bug ?
> >>>> The func_caps.fcoe is assigned by following call path, under
> >>>> our test environment,
> >>>>
> >>>> i40e_probe()
> >>>> ->i40e_get_capabilities()
> >>>> ->i40e_aq_discover_capabilities()
> >>>> ->i40e_parse_discover_capabilities()
> >>>>
> >>>> Or
> >>>>
> >>>> i40e_reset_and_rebuild()
> >>>> ->i40e_get_capabilities()
> >>>> ->i40e_aq_discover_capabilities()
> >>>> ->i40e_parse_discover_capabilities()
> >>>>
> >>>> Under our test environment, the "pf->hw.func_caps.fcoe" is
> >>>> true. so if
> >>>> i40e_reset_and_rebuild() is called for VLAN setup, ethtool diagnostic
> test.
> >>>> And then i40e_init_pf_fcoe() is to be called,
> >>>>
> >>>> While if (!pf->hw.func_caps.fcoe) wouldn't return,
> >>>>
> >>> I said it would return with "pf->hw.func_caps.fcoe == false" in my last
> response, more details below.
> >>>
> >>>> So pf->flags is set to I40E_FLAG_FCOE_ENABLED.
> >>>>
> >>>> With my patch, i40e_init_pf_fcoe() is only called after
> >>>> I40E_FLAG_FCOE_ENABLED is set before reset.
> >>>>
> >>>> Enable FCOE in i40e_probe() or not is another issue.
> >>>>
> >>> Nope since both cases we should do i40e_init_pf_fcoe() or don't based
> on fcoe cap true or false.
> >>>
> >>> I don't have much to add as I described before with the your patch that
> "calling i40e_init_pf_fcoe() under I40E_FLAG_FCOE_ENABLED flag really
> won't affect call flow to fix anything. I mean I40E_FLAG_FCOE_ENABLED
> condition will be true with "pf->hw.func_caps.fcoe == true" and otherwise
> calling i40e_init_pf_fcoe() simply returns back early on after checking "pf-
> >hw.func_caps.fcoe == false".
> >>>
> >>> May be I'm missing something, I guess next either go with
> CONFIG_I40E_FCOE disable as I suggested before and now it in upstream
> kernel or we can have further off list discussion to fix the issue you are trying
> to fix with the patch.
> >>>
> >>> Thanks,
> >>> Vasu
> >>>
> >>>> Thanks,
> >>>> Ethan
> >>>>
> >>>>
> >>>>>>> Jeff Kirsher should be getting out a patch queued by me which
> >>>>>>> adds
> >>>>>> I40E_FCoE Kbuild option, in that FCoE is disabled by default and
> >>>>>> user could enable FCoE only if needed, that patch would do same
> >>>>>> of skipping
> >>>>>> i40e_init_pf_fcoe() whether FCoE capability in device enabled or
> >>>>>> not in default config.
> >>>>>> The following patch will not fix the above issue -- configuration
> >>>>>> of PF will be changed via reset.
> >>>>>> How about the FCOE is configured and disabled by
> >>>>>> i40e_fcoe_disable() , then reset happens ?
> >>>>>>
> >>>>> May be but if the BUG is due to FCoE being enabled then having it
> >>>>> disabled
> >>>> in config will avoid the bug for non FCoE config option and once
> >>>> bug is understood then that has to be fixed for FCoE enabled config
> >>>> also as I asked above.
> >>>>> Thanks Ethan for detailed response.
> >>>>> Vasu
> >>>>>
> >>>>>>> From patchwork Wed Oct 2 23:26:08 2013
> >>>>>>> Content-Type: text/plain; charset="utf-8"
> >>>>>>> MIME-Version: 1.0
> >>>>>>> Content-Transfer-Encoding: 7bit
> >>>>>>> Subject: [net] i40e: adds FCoE configure option
> >>>>>>> Date: Thu, 03 Oct 2013 07:26:08 -0000
> >>>>>>> From: Vasu Dev <vasu.dev@intel.com>
> >>>>>>> X-Patchwork-Id: 11797
> >>>>>>>
> >>>>>>> Adds FCoE config option I40E_FCOE, so that FCoE can be enabled
> >>>>>>> as needed but otherwise have it disabled by default.
> >>>>>>>
> >>>>>>> This also eliminate multiple FCoE config checks, instead now
> >>>>>>> just one config check for CONFIG_I40E_FCOE.
> >>>>>>>
> >>>>>>> The I40E FCoE was added with 3.17 kernel and therefore this
> >>>>>>> patch shall be applied to stable 3.17 kernel also.
> >>>>>>>
> >>>>>>> CC: <stable@vger.kernel.org>
> >>>>>>> Signed-off-by: Vasu Dev <vasu.dev@intel.com>
> >>>>>>> Tested-by: Jim Young <jamesx.m.young@intel.com>
> >>>>>>>
> >>>>>>> ---
> >>>>>>> drivers/net/ethernet/intel/Kconfig | 11 +++++++++++
> >>>>>>> drivers/net/ethernet/intel/i40e/Makefile | 2 +-
> >>>>>>> drivers/net/ethernet/intel/i40e/i40e_osdep.h | 4 ++--
> >>>>>>> 3 files changed, 14 insertions(+), 3 deletions(-)
> >>>>>>>
> >>>>>>> diff --git a/drivers/net/ethernet/intel/Kconfig
> >>>>>>> b/drivers/net/ethernet/intel/Kconfig
> >>>>>>> index 5b8300a..4d61ef5 100644
> >>>>>>> --- a/drivers/net/ethernet/intel/Kconfig
> >>>>>>> +++ b/drivers/net/ethernet/intel/Kconfig
> >>>>>>> @@ -281,6 +281,17 @@ config I40E_DCB
> >>>>>>>
> >>>>>>> If unsure, say N.
> >>>>>>>
> >>>>>>> +config I40E_FCOE
> >>>>>>> + bool "Fibre Channel over Ethernet (FCoE)"
> >>>>>>> + default n
> >>>>>>> + depends on I40E && DCB && FCOE
> >>>>>>> + ---help---
> >>>>>>> + Say Y here if you want to use Fibre Channel over Ethernet
> (FCoE)
> >>>>>>> + in the driver. This will create new netdev for exclusive FCoE
> >>>>>>> + use with XL710 FCoE offloads enabled.
> >>>>>>> +
> >>>>>>> + If unsure, say N.
> >>>>>>> +
> >>>>>>> config I40EVF
> >>>>>>> tristate "Intel(R) XL710 X710 Virtual Function Ethernet
> support"
> >>>>>>> depends on PCI_MSI
> >>>>>>> diff --git a/drivers/net/ethernet/intel/i40e/Makefile
> >>>>>>> b/drivers/net/ethernet/intel/i40e/Makefile
> >>>>>>> index 4b94ddb..c405819 100644
> >>>>>>> --- a/drivers/net/ethernet/intel/i40e/Makefile
> >>>>>>> +++ b/drivers/net/ethernet/intel/i40e/Makefile
> >>>>>>> @@ -44,4 +44,4 @@ i40e-objs := i40e_main.o \
> >>>>>>> i40e_virtchnl_pf.o
> >>>>>>>
> >>>>>>> i40e-$(CONFIG_I40E_DCB) += i40e_dcb.o i40e_dcb_nl.o
> >>>>>>> -i40e-$(CONFIG_FCOE:m=y) += i40e_fcoe.o
> >>>>>>> +i40e-$(CONFIG_I40E_FCOE) += i40e_fcoe.o
> >>>>>>> diff --git a/drivers/net/ethernet/intel/i40e/i40e_osdep.h
> >>>>>>> b/drivers/net/ethernet/intel/i40e/i40e_osdep.h
> >>>>>>> index 045b5c4..ad802dd 100644
> >>>>>>> --- a/drivers/net/ethernet/intel/i40e/i40e_osdep.h
> >>>>>>> +++ b/drivers/net/ethernet/intel/i40e/i40e_osdep.h
> >>>>>>> @@ -78,7 +78,7 @@ do { \
> >>>>>>> } while (0)
> >>>>>>>
> >>>>>>> typedef enum i40e_status_code i40e_status; -#if
> >>>>>>> defined(CONFIG_FCOE)
> >>>>>>> || defined(CONFIG_FCOE_MODULE)
> >>>>>>> +#ifdef CONFIG_I40E_FCOE
> >>>>>>> #define I40E_FCOE
> >>>>>>> -#endif /* CONFIG_FCOE or CONFIG_FCOE_MODULE */
> >>>>>>> +#endif
> >>>>>>> #endif /* _I40E_OSDEP_H_ */
> >>>>>>>
> >>>>>>>>> + if (ret)
> >>>>>>>>> + dev_info(&pf->pdev->dev,
> >>>>>>>>> + "init_pf_fcoe failed: %d\n", ret);
> >>>>>>>>> + }
> >>>>>>>>>
> >>>>>>>>> #endif
> >>>>>>>>> /* do basic switch setup */
> >>>>>>>>> --
> >>>>>>>>> 1.8.3.1
> >>>>>> Thanks,
> >>>>>> Ethan
> >
------------------------------------------------------------------------------
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet
_______________________________________________
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: [net-next PATCH v3 1/1] net: sched: Introduce connmark action
From: David Miller @ 2015-01-19 21:02 UTC (permalink / raw)
To: jhs; +Cc: netdev, nbd, pablo, fw, jiri, cwang
In-Reply-To: <1421616915-5377-1-git-send-email-jhs@emojatatu.com>
From: Jamal Hadi Salim <jhs@mojatatu.com>
Date: Sun, 18 Jan 2015 16:35:14 -0500
> From: Felix Fietkau <nbd@openwrt.org>
>
> This tc action allows you to retrieve the connection tracking mark
> This action has been used heavily by openwrt for a few years now.
>
> There are known limitations currently:
>
> doesn't work for initial packets, since we only query the ct table.
> Fine given use case is for returning packets
>
> no implicit defrag.
> frags should be rare so fix later..
>
> won't work for more complex tasks, e.g. lookup of other extensions
> since we have no means to store results
>
> we still have a 2nd lookup later on via normal conntrack path.
> This shouldn't break anything though since skb->nfct isn't altered.
>
> V2:
> remove unnecessary braces (Jiri)
> change the action identifier to 14 (Jiri)
> Fix some stylistic issues caught by checkpatch
> V3:
> Move module params to bottom (Cong)
> Get rid of tcf_hashinfo_init and friends and conform to newer API (Cong)
Applied, thanks Jamal.
^ permalink raw reply
* Re: [PATCH 0/2] bgmac: some fixes to napi usage
From: David Miller @ 2015-01-19 21:00 UTC (permalink / raw)
To: hauke; +Cc: zajec5, netdev
In-Reply-To: <1421606999-23692-1-git-send-email-hauke@hauke-m.de>
From: Hauke Mehrtens <hauke@hauke-m.de>
Date: Sun, 18 Jan 2015 19:49:57 +0100
> I compared the napi documentation with the bgmac driver and found some
> problems in that driver. These two patches should fix the problems.
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next] net: ipv6: Add sysctl entry to disable MTU updates from RA
From: David Miller @ 2015-01-19 20:58 UTC (permalink / raw)
To: harouth; +Cc: netdev
In-Reply-To: <1421456558-27144-1-git-send-email-harouth@codeaurora.org>
From: Harout Hedeshian <harouth@codeaurora.org>
Date: Fri, 16 Jan 2015 18:02:38 -0700
> The kernel forcefully applies MTU values received in router
> advertisements provided the new MTU is less than the current. This
> behavior is undesirable when the user space is managing the MTU. Instead
> a sysctl flag 'accept_ra_mtu' is introduced such that the user space
> can control whether or not RA provided MTU updates should be applied. The
> default behavior is unchanged; user space must explicitly set this flag
> to 0 for RA MTUs to be ignored.
>
> Signed-off-by: Harout Hedeshian <harouth@codeaurora.org>
A really sloppy submission, sorry I can't apply this.
> + { CTL_INT, NET_IPV6_ACCEPT_RA_MTU, "accept_ra_mtu" },
This isn't defined anywhere, you left out some file while creating
your patch.
kernel/sysctl_binary.c:526:13: error: ‘NET_IPV6_ACCEPT_RA_MTU’ undeclared here (not in a function)
> - if (ndopts.nd_opts_mtu) {
> + if (ndopts.nd_opts_mtu && in6_dev->cnf.accept_ra_mtu) {
Too many spaced before the &&
^ permalink raw reply
* Re: [PATCH net-next 3/5] bonding: fix incorrect lacp mux state when agg not active
From: David Miller @ 2015-01-19 20:56 UTC (permalink / raw)
To: jtoppins; +Cc: nikolay, netdev, gospo, wkok
In-Reply-To: <54BD6E28.8020705@cumulusnetworks.com>
From: Jonathan Toppins <jtoppins@cumulusnetworks.com>
Date: Mon, 19 Jan 2015 15:50:48 -0500
> On 1/19/15 2:26 PM, Nikolay Aleksandrov wrote:
>>> diff --git a/drivers/net/bonding/bond_3ad.c
>>> b/drivers/net/bonding/bond_3ad.c
>>> index e9b706f..52a8772 100644
>>> --- a/drivers/net/bonding/bond_3ad.c
>>> +++ b/drivers/net/bonding/bond_3ad.c
>>> @@ -471,10 +471,13 @@ static void __record_pdu(struct lacpdu *lacpdu,
>>> struct port *port)
>>> * and the port is matched
>>> */
>>> if ((port->sm_vars & AD_PORT_MATCHED)
>>> - && (lacpdu->actor_state & AD_STATE_SYNCHRONIZATION))
>>> + && (lacpdu->actor_state & AD_STATE_SYNCHRONIZATION)) {
>> In net/ it's preferred to have the logical operators at the end of the
>> previous line. It'd be nice if we start fixing these in bond_3ad.c
>> since
>> they're being touched by the patch anyhow.
>
> Ack, I prefer at the end too. Question, would it be acceptable to do
> the cleanup of the entire bond_3ad.c code in a separate patch? That
> way the fix vs. cleanup is clear.
If you're touching this line, fix it's style in-situ.
^ 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