* Re: [PATCH 1/4 net-next] net: phy: add Generic Netlink Ethernet switch configuration API
From: Felix Fietkau @ 2013-10-25 13:01 UTC (permalink / raw)
To: Jamal Hadi Salim, Florian Fainelli, Neil Horman
Cc: John Fastabend, netdev, David Miller, Sascha Hauer, John Crispin,
Jonas Gorski, Gary Thomas, Vlad Yasevich, Stephen Hemminger
In-Reply-To: <526A5949.6040404@mojatatu.com>
On 2013-10-25 1:43 PM, Jamal Hadi Salim wrote:
> Hi Felix,
>
> Sorry for the latency - some distractions on the side.
>
> On 10/23/13 10:32, Felix Fietkau wrote:
>> On 2013-10-23 4:09 PM, Jamal Hadi Salim wrote:
>
>>> *MAC address setting?
>> Typically ignored by switches.
>>
>
> Ok, I take it the minority allow you to do this.
> For most, the switch port has some factory shipped MAC address?
I think it's common for the switch to have a global MAC address, not a
per-port one.
>>> *MTU setting
>> Can usually not be controlled per-port. Where supported, it is usually a
>> global configuration parameter for the switch.
>
> Does that mean one mtu for all switch ports on such devices?
Correct.
>>> * If something shows up on the cpu port and comes up, we can make it
>>> appear to be from such a netdev (for the case where this applies)
>> I think that's actually more confusing for users if they find the same
>> kind of devices on multiple different switches, and on some they can be
>> used directly, on others they cannot.
>
> But how does it work today for the case where you have one chip that
> wont pass up the tag to the cpu and another that does? i.e what
> happens to packets that end up being shunted to CPU?
'won't pass up the tag'? The switch is treated in pretty much the same
way as a normal managed standalone switch (you know, one you can buy in
a shop and plug your Ethernet cable into).
You simply tell it, which VLANs to put on which ports, and make the
ports tagged or untagged.
The link between the switch and the CPU is not really special, for the
switch it's just another port. This way of configuring works with pretty
much all switches that we're using.
>> The classical Linux tools here only cover the most basic configuration
>> parts. In many cases, separate configuration options are needed. For
>> example, on some switches, forwarding table IDs can be assigned to VLANs.
>
> Multiple forwarding tables?
Yes, some switches have them, and they can be useful when dealing with
multiple VLANs.
>> Also, the switch driver is completely independent of the network device
>> driver that drives the port connected to the CPU port of the switch.
>
> I guess this is because one piece manages attributes and other is
> for packet processing?
> There is good precedence in a few embedded systems which are
> equally challenged but still expose ports as netdevs.
No, because the connection between the CPU and the switch is handled by
a normal Ethernet MAC. The Ethernet chip doesn't care if there's a
switch connected to it, or a regular PHY.
It's just a normal MII connection, nothing more.
>>The
>> only ways I can imagine implementing this in the Linux network stack
>> involve an unhealthy amount of layering violations or other forms of
>> ugly hackery.
>> The switch driver usually attaches itself as a PHY driver, there is no
>> monolithic switch netdev.
>
> Shouldnt the PHY driver be owned by some netdev?
Right, the netdev that owns the PHY is a normal Ethernet MAC, running
any normal Linux Ethernet driver.
>> I fully agree that this would be nice to have. I've given quite a bit of
>> thought to trying to figure out if there's a simple clean way to
>> implement this, but in all of the proposals I've seen so far, the costs
>> (complexity, bloat, quirky interfaces) seem to massively outweigh the
>> benefits.
> I can understand the massive differences in capabilities make this
> harder to retrofit. But if the only cause for impendance mismatch
> is these capability differences, I think it can be resolved.
> We need a way to discover them and only use those available.
I remain absolutely unconvinced that this will make the end result
better. Right now, these switches act like separate devices, because
aside from the fact that they're put on the same board with other
components, they pretty much *are* separate devices.
You seem to insist on treating it as a kind of port multiplexer + bridge
accelerator instead of a mostly standalone switch.
This may work for some devices, but on others this simply a model that
the hardware wasn't designed for. Sure, we could try to cram in all
those special cases, extra options, and hack through the layers where
they're in the way. If *all* you care about is being able to reuse the
existing interfaces, that might even seem like a good idea.
On the other hand, I've pointed out quite a few examples where the model
of trying to cram it into the bridge API is just a bad fit in general.
>> I don't think bloating up the netdev feature flags for lots of
>> single-vendor fields is a good idea.
>
> I agree if you say there is a variety of capabilities.
> But if this is to be resolved - there has to be a way for these
> capabilities to be advertised by low level (and netdev->features
> is our only vehicle at the moment). We could have switch features
> in addition etc etc.
Aside from the fact that the swconfig code is already there, the model
that it uses is inherently simple. I worry about all the extra
complexity that we will have to add to try to retrofit this into a
mostly incompatible configuration model.
>> swconfig simply allows the driver
>> to register its own global, per-port and per-vlan attributes and user
>> space can discover them.
>>
>> That also avoids the nasty issue of userspace code having to know about
>> all possible vendor specific features and bits of status information.
> So it seems to me you already have taken care of this piece.
> Why not pull that into the netdev or bridge core and then re-use it?
Because it just doesn't fit there very well.
- Felix
^ permalink raw reply
* Re: Odd SCTP behaviour after remote host reboot.
From: Vladislav Yasevich @ 2013-10-25 12:36 UTC (permalink / raw)
To: David Laight; +Cc: netdev@vger.kernel.org
In-Reply-To: <AE90C24D6B3A694183C094C60CF0A2F6026B73B3@saturn3.aculab.com>
On Fri, Oct 25, 2013 at 6:19 AM, David Laight <David.Laight@aculab.com> wrote:
> I've just been given a very odd Wireshark trace from a customer.
>
> There is a single SCTP association with src_port==dst_port=5104 (m3ua).
> The remote system is reset and establishes a new association with the
> same port numbers.
> (The trace shows init/init_ack/cookie/cookie_ack with new verification tags.)
> However the data seems to have been linked back to the original socket!
> There are no further packets sent with the old verification tag.
>
> This isn't what I expect, and seems inappropriate for a reliable transport.
>
> The kernel they are running is old - 2.6.18-164 RHEL 5 update 4 from 2009!
> My guess is that it won't include any SCTP updates - so the latest RHEL 5
> kernel (2.6.18-358) won't be any better.
>
> Any idea when this might have been fixed?
> If they want to use RH, the latest kernel is based on 2.6.32.
This sounds like a problem with restarts that (according to git) was fixed
in 2.6.22.
-vlad
^ permalink raw reply
* Re: [PATCH 1/4 net-next] net: phy: add Generic Netlink Ethernet switch configuration API
From: Jamal Hadi Salim @ 2013-10-25 11:43 UTC (permalink / raw)
To: Felix Fietkau, Florian Fainelli, Neil Horman
Cc: John Fastabend, netdev, David Miller, Sascha Hauer, John Crispin,
Jonas Gorski, Gary Thomas, Vlad Yasevich, Stephen Hemminger
In-Reply-To: <5267DDE6.70600@openwrt.org>
Hi Felix,
Sorry for the latency - some distractions on the side.
On 10/23/13 10:32, Felix Fietkau wrote:
> On 2013-10-23 4:09 PM, Jamal Hadi Salim wrote:
>> *MAC address setting?
> Typically ignored by switches.
>
Ok, I take it the minority allow you to do this.
For most, the switch port has some factory shipped MAC address?
>> *MTU setting
> Can usually not be controlled per-port. Where supported, it is usually a
> global configuration parameter for the switch.
Does that mean one mtu for all switch ports on such devices?
>> * If something shows up on the cpu port and comes up, we can make it
>> appear to be from such a netdev (for the case where this applies)
> I think that's actually more confusing for users if they find the same
> kind of devices on multiple different switches, and on some they can be
> used directly, on others they cannot.
>
But how does it work today for the case where you have one chip that
wont pass up the tag to the cpu and another that does? i.e what
happens to packets that end up being shunted to CPU?
> The classical Linux tools here only cover the most basic configuration
> parts. In many cases, separate configuration options are needed. For
> example, on some switches, forwarding table IDs can be assigned to VLANs.
Multiple forwarding tables?
> Also, the switch driver is completely independent of the network device
> driver that drives the port connected to the CPU port of the switch.
I guess this is because one piece manages attributes and other is
for packet processing?
There is good precedence in a few embedded systems which are
equally challenged but still expose ports as netdevs.
>The
> only ways I can imagine implementing this in the Linux network stack
> involve an unhealthy amount of layering violations or other forms of
> ugly hackery.
>
> The switch driver usually attaches itself as a PHY driver, there is no
> monolithic switch netdev.
>
Shouldnt the PHY driver be owned by some netdev?
> I fully agree that this would be nice to have. I've given quite a bit of
> thought to trying to figure out if there's a simple clean way to
> implement this, but in all of the proposals I've seen so far, the costs
> (complexity, bloat, quirky interfaces) seem to massively outweigh the
> benefits.
>
I can understand the massive differences in capabilities make this
harder to retrofit. But if the only cause for impendance mismatch
is these capability differences, I think it can be resolved.
We need a way to discover them and only use those available.
> I don't think bloating up the netdev feature flags for lots of
> single-vendor fields is a good idea.
I agree if you say there is a variety of capabilities.
But if this is to be resolved - there has to be a way for these
capabilities to be advertised by low level (and netdev->features
is our only vehicle at the moment). We could have switch features
in addition etc etc.
> swconfig simply allows the driver
> to register its own global, per-port and per-vlan attributes and user
> space can discover them.
>
> That also avoids the nasty issue of userspace code having to know about
> all possible vendor specific features and bits of status information.
>
So it seems to me you already have taken care of this piece.
Why not pull that into the netdev or bridge core and then re-use it?
cheers,
jamal
^ permalink raw reply
* Re: [gpio:for-next 67/67] pch_gbe_main.c:undefined reference to `devm_gpio_request_one'
From: Linus Walleij @ 2013-10-25 10:49 UTC (permalink / raw)
To: Darren Hart, David S. Miller, netdev@vger.kernel.org
Cc: Fengguang Wu, David Cohen, Alexandre Courbot,
linux-gpio@vger.kernel.org
In-Reply-To: <CACRpkdYvOMiBOXRi61LjemMSoafR6kv3XoY=A5E90hwMumdw9A@mail.gmail.com>
On Fri, Oct 25, 2013 at 12:41 PM, Linus Walleij
<linus.walleij@linaro.org> wrote:
>> I wouldn't object to adding a dependency to GPIO_PCH and GPIOLIB
>> unconditionally for PCH_GBE as GPIO_PCH is the same chip... but I don't
>> know if David Miller would be amenable to that.
>
> Well we should probably just stick a dependency to GPIOLIB in there.
>
> - It #includes <linux/gpio.h>
> - It uses gpiolib functions to do something vital
>
> It was just happy that dummy versions were slotted in until now.
...or maybe I'm just confused now?
Should we just add a static inline stub of devm_gpio_request_one()?
Yours,
Linus Walleij
^ permalink raw reply
* Herzlichen Glückwunsch Empfänger!
From: Weir Charitable Trust @ 2013-10-25 10:38 UTC (permalink / raw)
Grüße & Glückwünsche!
Wir spenden offiziell die Summe von £ 1.000.000,00 EUR zu Ihnen.
Meine Frau und ich waren die größten Preisträger von £ 161,163,000.00 GBP in der 2011 Euro -Million Lottery Jackpot . Wir sind offiziell spendet die Summe von £ 48.000.000,00 GBP zur Nächstenliebe und Armut Erhebung über unsere Weir Charitable Trust Programm vor kurzem im Jahr 2013 ins Leben gerufen und Ihre E-Mail- ID geschieht unter den 48 zufällig ausgewählten E-Mail- Benutzer durch die Micro-Soft/Google Management Team eingereicht werden Nutzen £ 1.000.000,00 GBP jeweils aus der laufenden Charity Scheme , weltweit !
Sie sind in nicht mehr als 48 Stunden nach Erhalt dieser Mitteilung ( wenn diese E-Mail- ID aktiv ist) , um sofort für Ihren Gewinn Verarbeitung einreichen reagieren. Eine neue Empfänger wird nach 48 Stunden gewählt werden ! Ihre Spende ist Code No " WCT31UK "; zur Vermeidung der Doppelbesteuerung behauptet der Preisgelder, bitte geben Sie Ihre Spende Code No " WCT31UK " auf die Betreff-Zeile oder in Ihrem E-Mail- Rückkehr . Herzlichen Glückwunsch noch einmal ! Überprüfen Sie die Echtheit unserer Euro -Million Gewinne an
http://www.dailyrecord.co.uk/news/scottish-news/euromillions-lottery-winners-chris-and-colin-1585568
herzlichst ,
Colin & Chris Weir
( Weir Charitable Trust)
^ permalink raw reply
* Re: [gpio:for-next 67/67] pch_gbe_main.c:undefined reference to `devm_gpio_request_one'
From: Linus Walleij @ 2013-10-25 10:41 UTC (permalink / raw)
To: Darren Hart, David S. Miller, netdev@vger.kernel.org
Cc: Fengguang Wu, David Cohen, Alexandre Courbot,
linux-gpio@vger.kernel.org
In-Reply-To: <1382696677.4970.40.camel@dvhart-mobl4.amr.corp.intel.com>
On Fri, Oct 25, 2013 at 12:24 PM, Darren Hart <dvhart@linux.intel.com> wrote:
> On Fri, 2013-10-25 at 11:34 +0200, Linus Walleij wrote:
> Minnow doesn't currently have a CONFIG_ upstream which can be used to
> force this selection.
Well it wouldn't help with randconfig or allyesconfig anyway.
>> Is there some default y we can add so this gets compiled for this
>> entire board, or shall I set:
>>
>> depends on PCH_GBE
>> default y
>>
>> On the GPIO_LYNXPOINT or GPIO_PCH driver?
>
> Why would GPIO_PCH depend on PCH_GBE? The inverse is certainly true for
> MinnowBoard.
OK this was the wrong idea.
> I had some MinnowBoard Kconfig bits in my early drivers, but they
> included things like CONFIG_MINNOWBOARD which is not upstream (rightly
> so) but it means I don't have a way to conditionally make PCH_GBE
> dependent on GPIO_PCH and GPIOLIB.
>
> I wouldn't object to adding a dependency to GPIO_PCH and GPIOLIB
> unconditionally for PCH_GBE as GPIO_PCH is the same chip... but I don't
> know if David Miller would be amenable to that.
Well we should probably just stick a dependency to GPIOLIB in there.
- It #includes <linux/gpio.h>
- It uses gpiolib functions to do something vital
It was just happy that dummy versions were slotted in until now.
I'll post the following:
diff --git a/drivers/net/ethernet/oki-semi/pch_gbe/Kconfig b/drivers/net/etherne
index a588ffde9700..f2528262aba7 100644
--- a/drivers/net/ethernet/oki-semi/pch_gbe/Kconfig
+++ b/drivers/net/ethernet/oki-semi/pch_gbe/Kconfig
@@ -4,7 +4,7 @@
config PCH_GBE
tristate "OKI SEMICONDUCTOR IOH(ML7223/ML7831) GbE"
- depends on PCI && (X86 || COMPILE_TEST)
+ depends on PCI && GPIOLIB && (X86 || COMPILE_TEST)
select MII
select PTP_1588_CLOCK_PCH
---help---
Yours,
Linus Walleij
^ permalink raw reply related
* Odd SCTP behaviour after remote host reboot.
From: David Laight @ 2013-10-25 10:19 UTC (permalink / raw)
To: netdev
I've just been given a very odd Wireshark trace from a customer.
There is a single SCTP association with src_port==dst_port=5104 (m3ua).
The remote system is reset and establishes a new association with the
same port numbers.
(The trace shows init/init_ack/cookie/cookie_ack with new verification tags.)
However the data seems to have been linked back to the original socket!
There are no further packets sent with the old verification tag.
This isn't what I expect, and seems inappropriate for a reliable transport.
The kernel they are running is old - 2.6.18-164 RHEL 5 update 4 from 2009!
My guess is that it won't include any SCTP updates - so the latest RHEL 5
kernel (2.6.18-358) won't be any better.
Any idea when this might have been fixed?
If they want to use RH, the latest kernel is based on 2.6.32.
David
^ permalink raw reply
* Re: [patch net-next] ipv6: allow userspace to create address with IFLA_F_TEMPORARY flag
From: Vladislav Yasevich @ 2013-10-25 10:05 UTC (permalink / raw)
To: Jiri Pirko
Cc: netdev@vger.kernel.org, David Miller, kuznet, jmorris, yoshfuji,
kaber, thaller, Stephen Hemminger
In-Reply-To: <20131024165931.GA1475@minipsycho.orion>
On Thu, Oct 24, 2013 at 12:59 PM, Jiri Pirko <jiri@resnulli.us> wrote:
> Thu, Oct 24, 2013 at 04:02:53PM CEST, hannes@stressinduktion.org wrote:
>>On Thu, Oct 24, 2013 at 03:45:55PM +0200, Jiri Pirko wrote:
>>> This is needed in order to implement userspace address configuration,
>>> namely ip6-privacy (rfc4941) in NetworkManager.
>>>
>>> Signed-off-by: Jiri Pirko <jiri@resnulli.us>
>>> ---
>>> net/ipv6/addrconf.c | 3 ++-
>>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
>>> index cd3fb30..962c7c9 100644
>>> --- a/net/ipv6/addrconf.c
>>> +++ b/net/ipv6/addrconf.c
>>> @@ -3715,7 +3715,8 @@ inet6_rtm_newaddr(struct sk_buff *skb, struct nlmsghdr *nlh)
>>> return -ENODEV;
>>>
>>> /* We ignore other flags so far. */
>>> - ifa_flags = ifm->ifa_flags & (IFA_F_NODAD | IFA_F_HOMEADDRESS);
>>> + ifa_flags = ifm->ifa_flags & (IFA_F_NODAD | IFA_F_HOMEADDRESS |
>>> + IFA_F_TEMPORARY);
>>>
>>> ifa = ipv6_get_ifaddr(net, pfx, dev, 1);
>>> if (ifa == NULL) {
>>
>>Hm, the kernel will pick up IFA_F_TEMPORARY marked addresses and do ipv6 address
>>regeneration (depending on lifetimes). Is this intended?
>
> I think that that behaviour is valid. It is in compliance with valid lft and
> preferred lft behaviour.
>
Actually, I don't think it would do the regeneration since ifpub
pointer is not set.
I appears that the temp address management would have to be done in
userspace.
-vlad
>>
>>Btw. I am very interested in this topic as there is currently work in the IETF
>>to move away from eui-48 generation of addresses:
>>
>>https://datatracker.ietf.org/doc/draft-ietf-6man-stable-privacy-addresses/
>>
>>This needs to be done in userspace as we depend on a secret generated at
>>system install time.
>>
>>Greetings,
>>
>> Hannes
>>
> --
> 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
^ permalink raw reply
* Re: Big performance loss from 3.4.63 to 3.10.13 when routing ipv4
From: Wolfgang Walter @ 2013-10-25 9:33 UTC (permalink / raw)
To: Steffen Klassert; +Cc: Eric Dumazet, David Miller, hannes, netdev, klassert
In-Reply-To: <20131025080158.GC31491@secunet.com>
Am Freitag, 25. Oktober 2013, 10:01:58 schrieb Steffen Klassert:
> On Thu, Oct 24, 2013 at 12:52:58AM +0200, Wolfgang Walter wrote:
> > On Wednesday 23 October 2013 10:06:32 Eric Dumazet wrote:
> > > On Wed, 2013-10-23 at 18:59 +0200, Wolfgang Walter wrote:
> > > > Ah, ok. I use SLUB, but SLABINFO=y.
> > > >
> > > > Without much traffic it is:
> > > >
> > > > # grep dst /proc/slabinfo
> > > > xfrm_dst_cache 4435 4608 448 36 4 : tunables 0 0
> > > > 0
> > > >
> > > > : slabdata 128 128 0
> > > >
> > > > on the big one.
> > > >
> > > > I can recompile the kernels with SLAB instead of SLUB if SLAB gives
> > > > more
> > > > usefull infos.
> > >
> > > Not needed, because it seems we do not merge this SLUB cache with
> > > another one.
> >
> > Ok. I can't see xfrm_dst_cache on 32bit-systems, though.
> >
> > > So please post this information, because I believe the default should be
> > > 65536, not 1024 or 4096
> >
> > Indeed I already saw higher values, at the moment I see:
> >
> > # while true; do grep dst /proc/slabinfo ; sleep 1; done
> > xfrm_dst_cache 12636 12636 448 36 4 : tunables 0 0 0
> > : slabdata 351 351 0
> We currently start the garbage collector if we have more than gc_thresh
> (1024) dst entries allocated and refuse new allocations at 2 * gc_thresh.
>
> So maybe we should set gc_thresh to 32768. Than we can have 65536 dst
> entries in the system (cache + packets in flight) before we refuse
> new allocations. In paticular we can still cache another 32768 dst
> entries after the garbage collector was started. It looks like you
> had never more than 15000 dst entries cached, so a default of 32768
> looks reasonable and should also keep smaller embedded routers happy.
The maximum I saw was 18000. I think 32768 is a good value especially as this
seems to be the minimum on 3.4.x if you have 512MB ram.
Is it possible to log a warning the first time one hits the limit? Something
like "xfrm_dst_cache full, consider increasing net.ipv4.xfrm4_gc_thresh and/or
net.ipv6.xfrm6_gc_thresh"?
Regards,
--
Wolfgang Walter
Studentenwerk München
Anstalt des öffentlichen Rechts
^ permalink raw reply
* Re: Big performance loss from 3.4.63 to 3.10.13 when routing ipv4
From: Steffen Klassert @ 2013-10-25 9:20 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Wolfgang Walter, David Miller, hannes, netdev, klassert
In-Reply-To: <1382691028.7572.78.camel@edumazet-glaptop.roam.corp.google.com>
On Fri, Oct 25, 2013 at 01:50:28AM -0700, Eric Dumazet wrote:
>
> 32768 as the default seems fine to me
>
> 448 bytes per dst -> thats less than 30 Mbytes of memory if we hit 65536
> dst.
>
Ok, I'll add the patch below to to the ipsec tree if everyone is fine
with that threshold.
Subject: [PATCH RFC] xfrm: Increase the garbage collector threshold
With the removal of the routing cache, we lost the
option to tweak the garbage collector threshold
along with the maximum routing cache size. So git
commit 703fb94ec ("xfrm: Fix the gc threshold value
for ipv4") moved back to a static threshold.
It turned out that the current threshold before we
start garbage collecting is much to small for some
workloads, so increase it from 1024 to 32768. This
means that we start the garbage collector if we have
more than 32768 dst entries in the system and refuse
new allocations if we are above 65536.
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
---
net/ipv4/xfrm4_policy.c | 2 +-
net/ipv6/xfrm6_policy.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/ipv4/xfrm4_policy.c b/net/ipv4/xfrm4_policy.c
index ccde542..4764ee4 100644
--- a/net/ipv4/xfrm4_policy.c
+++ b/net/ipv4/xfrm4_policy.c
@@ -236,7 +236,7 @@ static struct dst_ops xfrm4_dst_ops = {
.destroy = xfrm4_dst_destroy,
.ifdown = xfrm4_dst_ifdown,
.local_out = __ip_local_out,
- .gc_thresh = 1024,
+ .gc_thresh = 32768,
};
static struct xfrm_policy_afinfo xfrm4_policy_afinfo = {
diff --git a/net/ipv6/xfrm6_policy.c b/net/ipv6/xfrm6_policy.c
index 08ed277..dd503a3 100644
--- a/net/ipv6/xfrm6_policy.c
+++ b/net/ipv6/xfrm6_policy.c
@@ -285,7 +285,7 @@ static struct dst_ops xfrm6_dst_ops = {
.destroy = xfrm6_dst_destroy,
.ifdown = xfrm6_dst_ifdown,
.local_out = __ip6_local_out,
- .gc_thresh = 1024,
+ .gc_thresh = 32768,
};
static struct xfrm_policy_afinfo xfrm6_policy_afinfo = {
--
1.7.9.5
^ permalink raw reply related
* Re: vxlan gso is broken by stackable gso_segment()
From: Eric Dumazet @ 2013-10-25 9:09 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: Eric Dumazet, Stephen Hemminger, David S. Miller, netdev
In-Reply-To: <1382674000.7572.75.camel@edumazet-glaptop.roam.corp.google.com>
On Thu, 2013-10-24 at 21:06 -0700, Eric Dumazet wrote:
> On Thu, 2013-10-24 at 18:59 -0700, Alexei Starovoitov wrote:
> > gre seems to be fine.
> > packets seem to be segmented with wrong length and being dropped.
> > After client iperf is finished, in few seconds I see the warning:
> >
> > [ 329.669685] WARNING: CPU: 3 PID: 3817 at net/core/skbuff.c:3474
> > skb_try_coalesce+0x3a0/0x3f0()
> > [ 329.669688] Modules linked in: vxlan ip_tunnel veth ip6table_filter
> > ip6_tables ebtable_nat ebtables nf_conntrack_ipv4 nf_defrag_ipv4
> > xt_state nf_conntrack xt_CHECKSUM iptable_mangle ipt_REJECT xt_tcpudp
> > iptable_filter ip_tables x_tables bridge stp llc vhost_net macvtap
> > macvlan vhost kvm_intel kvm iscsi_tcp libiscsi_tcp libiscsi
> > scsi_transport_iscsi dm_crypt hid_generic eeepc_wmi asus_wmi
> > sparse_keymap mxm_wmi dm_multipath psmouse serio_raw usbhid hid
> > parport_pc ppdev firewire_ohci e1000e firewire_core lpc_ich crc_itu_t
> > binfmt_misc igb dca ptp pps_core mac_hid wmi lp parport i2o_config
> > i2o_block video
> > [ 329.669746] CPU: 3 PID: 3817 Comm: iperf Not tainted 3.12.0-rc6+ #81
> > [ 329.669748] Hardware name: System manufacturer System Product
> > Name/P8Z77 WS, BIOS 3007 07/26/2012
> > [ 329.669750] 0000000000000009 ffff88082fb839d8 ffffffff8175427a
> > 0000000000000002
> > [ 329.669756] 0000000000000000 ffff88082fb83a18 ffffffff8105206c
> > ffff880808f926f8
> > [ 329.669760] ffff8807ef122b00 ffff8807ef122a00 0000000000000576
> > ffff88082fb83a94
> > [ 329.669765] Call Trace:
> > [ 329.669767] <IRQ> [<ffffffff8175427a>] dump_stack+0x55/0x76
> > [ 329.669779] [<ffffffff8105206c>] warn_slowpath_common+0x8c/0xc0
> > [ 329.669783] [<ffffffff810520ba>] warn_slowpath_null+0x1a/0x20
> > [ 329.669787] [<ffffffff816150f0>] skb_try_coalesce+0x3a0/0x3f0
> > [ 329.669793] [<ffffffff8167bce4>] tcp_try_coalesce.part.44+0x34/0xa0
> > [ 329.669797] [<ffffffff8167d168>] tcp_queue_rcv+0x108/0x150
> > [ 329.669801] [<ffffffff8167f129>] tcp_data_queue+0x299/0xd00
> > [ 329.669806] [<ffffffff816822f4>] tcp_rcv_established+0x2d4/0x8f0
> > [ 329.669809] [<ffffffff8168d8b5>] tcp_v4_do_rcv+0x295/0x520
> > [ 329.669813] [<ffffffff8168fb08>] tcp_v4_rcv+0x888/0xc30
> > [ 329.669818] [<ffffffff816651d3>] ? ip_local_deliver_finish+0x43/0x480
> > [ 329.669823] [<ffffffff810cae04>] ? __lock_is_held+0x54/0x80
> > [ 329.669827] [<ffffffff816652fb>] ip_local_deliver_finish+0x16b/0x480
> > [ 329.669831] [<ffffffff816651d3>] ? ip_local_deliver_finish+0x43/0x480
> > [ 329.669836] [<ffffffff81666018>] ip_local_deliver+0x48/0x80
> > [ 329.669840] [<ffffffff81665770>] ip_rcv_finish+0x160/0x770
> > [ 329.669845] [<ffffffff816662f8>] ip_rcv+0x2a8/0x3e0
> > [ 329.669849] [<ffffffff81623d13>] __netif_receive_skb_core+0xa63/0xdb0
> > [ 329.669853] [<ffffffff816233b8>] ? __netif_receive_skb_core+0x108/0xdb0
> > [ 329.669858] [<ffffffff8175d37f>] ? _raw_spin_unlock_irqrestore+0x3f/0x70
> > [ 329.669862] [<ffffffff8162417b>] ? process_backlog+0xab/0x180
> > [ 329.669866] [<ffffffff81624081>] __netif_receive_skb+0x21/0x70
> > [ 329.669869] [<ffffffff81624184>] process_backlog+0xb4/0x180
> > [ 329.669873] [<ffffffff81626d08>] ? net_rx_action+0x98/0x350
> > [ 329.669876] [<ffffffff81626dca>] net_rx_action+0x15a/0x350
> > [ 329.669882] [<ffffffff81057f97>] __do_softirq+0xf7/0x3f0
> > [ 329.669886] [<ffffffff8176820c>] call_softirq+0x1c/0x30
> > [ 329.669887] <EOI> [<ffffffff81004bed>] do_softirq+0x8d/0xc0
> > [ 329.669896] [<ffffffff8160de03>] ? release_sock+0x193/0x1f0
> > [ 329.669901] [<ffffffff81057a5b>] local_bh_enable_ip+0xdb/0xf0
> > [ 329.669906] [<ffffffff8175d2e4>] _raw_spin_unlock_bh+0x44/0x50
> > [ 329.669910] [<ffffffff8160de03>] release_sock+0x193/0x1f0
> > [ 329.669914] [<ffffffff81679237>] tcp_recvmsg+0x467/0x1030
> > [ 329.669919] [<ffffffff816ab424>] inet_recvmsg+0x134/0x230
> > [ 329.669923] [<ffffffff8160a17d>] sock_recvmsg+0xad/0xe0
> >
> > to reproduce do:
> > $ sudo brctl addbr br0
> > $ sudo ifconfig br0 up
> > $ cat foo1.conf
> > lxc.network.type = veth
> > lxc.network.flags = up
> > lxc.network.link = br0
> > lxc.network.ipv4 = 10.2.3.5/24
> > $sudo lxc-start -n foo1 -f ./foo1.conf bash
> > #ip li add vxlan0 type vxlan id 42 group 239.1.1.1 dev eth0
> > #ip addr add 192.168.99.1/24 dev vxlan0
> > #ip link set up dev vxlan0
> > #iperf -s
> >
> > similar for another lxc with different IP
> > $sudo lxc-start -n foo2 -f ./foo2.conf bash
> > #ip li add vxlan0 type vxlan id 42 group 239.1.1.1 dev eth0
> > #ip addr add 192.168.99.2/24 dev vxlan0
> > #ip link set up dev vxlan0
> > # iperf -c 192.168.99.1
> >
> > I keep hitting it all the time.
> >
> >
>
> Thanks for all these details.
>
> I am in Edinburgh for the Kernel Summit, I'll take a look at this as
> soon as possible.
Could you try following fix ?
Thanks !
diff --git a/net/ipv4/af_inet.c b/net/ipv4/af_inet.c
index f4a159e..17dd8320 100644
--- a/net/ipv4/af_inet.c
+++ b/net/ipv4/af_inet.c
@@ -1252,6 +1252,7 @@ static struct sk_buff *inet_gso_segment(struct sk_buff *skb,
const struct net_offload *ops;
unsigned int offset = 0;
struct iphdr *iph;
+ bool udpfrag;
bool tunnel;
int proto;
int nhoff;
@@ -1306,10 +1307,11 @@ static struct sk_buff *inet_gso_segment(struct sk_buff *skb,
if (IS_ERR_OR_NULL(segs))
goto out;
+ udpfrag = !!skb->encapsulation && proto == IPPROTO_UDP;
skb = segs;
do {
iph = (struct iphdr *)(skb_mac_header(skb) + nhoff);
- if (!tunnel && proto == IPPROTO_UDP) {
+ if (udpfrag) {
iph->id = htons(id);
iph->frag_off = htons(offset >> 3);
if (skb->next != NULL)
^ permalink raw reply related
* Re: Big performance loss from 3.4.63 to 3.10.13 when routing ipv4
From: Eric Dumazet @ 2013-10-25 8:50 UTC (permalink / raw)
To: Steffen Klassert; +Cc: Wolfgang Walter, David Miller, hannes, netdev, klassert
In-Reply-To: <20131025080158.GC31491@secunet.com>
On Fri, 2013-10-25 at 10:01 +0200, Steffen Klassert wrote:
> We currently start the garbage collector if we have more than gc_thresh
> (1024) dst entries allocated and refuse new allocations at 2 * gc_thresh.
>
> So maybe we should set gc_thresh to 32768. Than we can have 65536 dst
> entries in the system (cache + packets in flight) before we refuse
> new allocations. In paticular we can still cache another 32768 dst
> entries after the garbage collector was started. It looks like you
> had never more than 15000 dst entries cached, so a default of 32768
> looks reasonable and should also keep smaller embedded routers happy.
32768 as the default seems fine to me
448 bytes per dst -> thats less than 30 Mbytes of memory if we hit 65536
dst.
^ permalink raw reply
* Re: [RFC PATCH net-next] ppp: Allow ppp device connected to an l2tp session to change of namespace
From: François Cachereul @ 2013-10-25 8:27 UTC (permalink / raw)
To: James Chapman; +Cc: Benjamin LaHaise, Paul Mackerras, netdev, linux-ppp
In-Reply-To: <52695012.6090700@katalix.com>
On 10/24/2013 06:51 PM, James Chapman wrote:
> On 24/10/13 16:53, Benjamin LaHaise wrote:
>> On Thu, Oct 24, 2013 at 04:43:42PM +0100, James Chapman wrote:
>>> I'm thinking about the implications of a skb in the net namespace of the
>>> ppp interface passing through a tunnel socket which is in another
>>> namespace. I think net namespaces are completely isolated.
>>>
>>> To keep your ppp interfaces isolated from each other, have you
>>> considered using netfilter to prevent data being passed between ppp
>>> interfaces?
>>
>> Using network namespaces for this is far more efficient. We've already
>> added support for doing this to other tunneling interfaces. This approach
>> also makes creating VPNs where there is re-use of the private address space
>> between different customers far easier to implement.
>>
>> -ben
>
> Yes, it's definitely more efficient and potentially useful, I agree.
>
> But unlike the other tunneling interfaces for which this has already
> been done, L2TP uses a socket for its tunnel and a skb will cross net
> namespace boundaries while passing through the socket. I remember a
> similar discussion came up several months ago with vxlan which also uses
> UDP sockets. See http://www.spinics.net/lists/netdev/msg221498.html.
>
> Changing the behaviour of ppp interfaces only when they are created by
> l2tp feels wrong to me, unless it is the first step in doing the same
> for all ppp interfaces.
I agree, I only took care of l2TP first because it seemed safe and that's
why I posted the patch as RFC in the first place.
François
^ permalink raw reply
* Re: [RFC PATCH net-next] ppp: Allow ppp device connected to an l2tp session to change of namespace
From: François Cachereul @ 2013-10-25 8:24 UTC (permalink / raw)
To: Benjamin LaHaise; +Cc: James Chapman, Paul Mackerras, netdev, linux-ppp
In-Reply-To: <20131024155354.GQ2704@kvack.org>
On 10/24/2013 05:53 PM, Benjamin LaHaise wrote:
> On Thu, Oct 24, 2013 at 04:43:42PM +0100, James Chapman wrote:
>> I'm thinking about the implications of a skb in the net namespace of the
>> ppp interface passing through a tunnel socket which is in another
>> namespace. I think net namespaces are completely isolated.
>>
>> To keep your ppp interfaces isolated from each other, have you
>> considered using netfilter to prevent data being passed between ppp
>> interfaces?
>
> Using network namespaces for this is far more efficient. We've already
> added support for doing this to other tunneling interfaces. This approach
> also makes creating VPNs where there is re-use of the private address space
> between different customers far easier to implement.
>
> -ben
That's indeed on of the problems we have to deal with and net namespaces
seems to be the right answer.
François
^ permalink raw reply
* READY? Write me:lidwayllc@gmail.com
From: Elizabeta Mataiche @ 2013-10-25 8:01 UTC (permalink / raw)
Are you seeking for financial assistance of any kind?
contact us asap. READY? Write me:lidwayllc@gmail.com
_____________________________________________________________________________________________________________
Disclaimer: The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you receive this in error, please contact the sender and delete the material from any computer. Any views or opinions presented are solely those of the authors and do not necessarily represent those of HMC.
_______________________________________________________________________________________________________________
^ permalink raw reply
* [PATCH 1/2] net/benet: Identify interface type in advance
From: Gavin Shan @ 2013-10-25 8:02 UTC (permalink / raw)
To: netdev; +Cc: sathya.perla, Gavin Shan
Function be_map_pci_bars() is being called in be_ctrl_init(). Since
be_ctrl_init() has fetched the value of PCI config register 0x58,
we needn't access the same register in be_map_pci_bars() again to
incur unnecessary PCI config access.
Signed-off-by: Gavin Shan <shangw@linux.vnet.ibm.com>
---
drivers/net/ethernet/emulex/benet/be_main.c | 9 +++------
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/emulex/benet/be_main.c b/drivers/net/ethernet/emulex/benet/be_main.c
index 2c38cc4..1a799d2 100644
--- a/drivers/net/ethernet/emulex/benet/be_main.c
+++ b/drivers/net/ethernet/emulex/benet/be_main.c
@@ -3960,11 +3960,6 @@ static int be_roce_map_pci_bars(struct be_adapter *adapter)
static int be_map_pci_bars(struct be_adapter *adapter)
{
u8 __iomem *addr;
- u32 sli_intf;
-
- pci_read_config_dword(adapter->pdev, SLI_INTF_REG_OFFSET, &sli_intf);
- adapter->if_type = (sli_intf & SLI_INTF_IF_TYPE_MASK) >>
- SLI_INTF_IF_TYPE_SHIFT;
if (BEx_chip(adapter) && be_physfn(adapter)) {
adapter->csr = pci_iomap(adapter->pdev, 2, 0);
@@ -4011,7 +4006,9 @@ static int be_ctrl_init(struct be_adapter *adapter)
pci_read_config_dword(adapter->pdev, SLI_INTF_REG_OFFSET, &sli_intf);
adapter->sli_family = (sli_intf & SLI_INTF_FAMILY_MASK) >>
- SLI_INTF_FAMILY_SHIFT;
+ SLI_INTF_FAMILY_SHIFT;
+ adapter->if_type = (sli_intf & SLI_INTF_IF_TYPE_MASK) >>
+ SLI_INTF_IF_TYPE_SHIFT;
adapter->virtfn = (sli_intf & SLI_INTF_FT_MASK) ? 1 : 0;
status = be_map_pci_bars(adapter);
--
1.7.9.5
^ permalink raw reply related
* [PATCH 2/2] net/benet: Make lancer_wait_ready() static
From: Gavin Shan @ 2013-10-25 8:02 UTC (permalink / raw)
To: netdev; +Cc: sathya.perla, Gavin Shan
In-Reply-To: <1382688165-20957-1-git-send-email-shangw@linux.vnet.ibm.com>
The function needn't to be public, so to make it as static.
Signed-off-by: Gavin Shan <shangw@linux.vnet.ibm.com>
---
drivers/net/ethernet/emulex/benet/be_cmds.c | 2 +-
drivers/net/ethernet/emulex/benet/be_cmds.h | 1 -
2 files changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/emulex/benet/be_cmds.c b/drivers/net/ethernet/emulex/benet/be_cmds.c
index c08fd32..c30ab8f 100644
--- a/drivers/net/ethernet/emulex/benet/be_cmds.c
+++ b/drivers/net/ethernet/emulex/benet/be_cmds.c
@@ -522,7 +522,7 @@ static u16 be_POST_stage_get(struct be_adapter *adapter)
return sem & POST_STAGE_MASK;
}
-int lancer_wait_ready(struct be_adapter *adapter)
+static int lancer_wait_ready(struct be_adapter *adapter)
{
#define SLIPORT_READY_TIMEOUT 30
u32 sliport_status;
diff --git a/drivers/net/ethernet/emulex/benet/be_cmds.h b/drivers/net/ethernet/emulex/benet/be_cmds.h
index 108ca8a..dd522b0 100644
--- a/drivers/net/ethernet/emulex/benet/be_cmds.h
+++ b/drivers/net/ethernet/emulex/benet/be_cmds.h
@@ -1983,7 +1983,6 @@ extern int be_cmd_get_ext_fat_capabilites(struct be_adapter *adapter,
extern int be_cmd_set_ext_fat_capabilites(struct be_adapter *adapter,
struct be_dma_mem *cmd,
struct be_fat_conf_params *cfgs);
-extern int lancer_wait_ready(struct be_adapter *adapter);
extern int lancer_physdev_ctrl(struct be_adapter *adapter, u32 mask);
extern int lancer_initiate_dump(struct be_adapter *adapter);
extern bool dump_present(struct be_adapter *adapter);
--
1.7.9.5
^ permalink raw reply related
* Re: Big performance loss from 3.4.63 to 3.10.13 when routing ipv4
From: Steffen Klassert @ 2013-10-25 8:01 UTC (permalink / raw)
To: Wolfgang Walter; +Cc: Eric Dumazet, David Miller, hannes, netdev, klassert
In-Reply-To: <5743349.5WGxWa1M1u@ei.h3.stusta.mhn.de>
On Thu, Oct 24, 2013 at 12:52:58AM +0200, Wolfgang Walter wrote:
> On Wednesday 23 October 2013 10:06:32 Eric Dumazet wrote:
> > On Wed, 2013-10-23 at 18:59 +0200, Wolfgang Walter wrote:
> > > Ah, ok. I use SLUB, but SLABINFO=y.
> > >
> > > Without much traffic it is:
> > >
> > > # grep dst /proc/slabinfo
> > > xfrm_dst_cache 4435 4608 448 36 4 : tunables 0 0 0
> > > : slabdata 128 128 0
> > >
> > > on the big one.
> > >
> > > I can recompile the kernels with SLAB instead of SLUB if SLAB gives more
> > > usefull infos.
> > Not needed, because it seems we do not merge this SLUB cache with
> > another one.
>
> Ok. I can't see xfrm_dst_cache on 32bit-systems, though.
>
> >
> > So please post this information, because I believe the default should be
> > 65536, not 1024 or 4096
> >
>
> Indeed I already saw higher values, at the moment I see:
>
> # while true; do grep dst /proc/slabinfo ; sleep 1; done
> xfrm_dst_cache 12636 12636 448 36 4 : tunables 0 0 0 : slabdata 351 351 0
We currently start the garbage collector if we have more than gc_thresh
(1024) dst entries allocated and refuse new allocations at 2 * gc_thresh.
So maybe we should set gc_thresh to 32768. Than we can have 65536 dst
entries in the system (cache + packets in flight) before we refuse
new allocations. In paticular we can still cache another 32768 dst
entries after the garbage collector was started. It looks like you
had never more than 15000 dst entries cached, so a default of 32768
looks reasonable and should also keep smaller embedded routers happy.
^ permalink raw reply
* [PATCH 2/3] net, datagram: fix the uncorrect comment in zerocopy_sg_from_iovec()
From: Zhi Yong Wu @ 2013-10-25 7:49 UTC (permalink / raw)
To: netdev; +Cc: linux-kernel, Zhi Yong Wu
In-Reply-To: <1382687360-27794-1-git-send-email-zwu.kernel@gmail.com>
From: Zhi Yong Wu <wuzhy@linux.vnet.ibm.com>
Signed-off-by: Zhi Yong Wu <wuzhy@linux.vnet.ibm.com>
---
net/core/datagram.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/core/datagram.c b/net/core/datagram.c
index af814e7..a16ed7b 100644
--- a/net/core/datagram.c
+++ b/net/core/datagram.c
@@ -577,7 +577,7 @@ EXPORT_SYMBOL(skb_copy_datagram_from_iovec);
/**
* zerocopy_sg_from_iovec - Build a zerocopy datagram from an iovec
* @skb: buffer to copy
- * @from: io vector to copy to
+ * @from: io vector to copy from
* @offset: offset in the io vector to start copying from
* @count: amount of vectors to copy to buffer from
*
--
1.7.11.7
^ permalink raw reply related
* [PATCH 3/3] net, iovec: fix the uncorrect comment in memcpy_fromiovecend()
From: Zhi Yong Wu @ 2013-10-25 7:49 UTC (permalink / raw)
To: netdev; +Cc: linux-kernel, Zhi Yong Wu
In-Reply-To: <1382687360-27794-1-git-send-email-zwu.kernel@gmail.com>
From: Zhi Yong Wu <wuzhy@linux.vnet.ibm.com>
Signed-off-by: Zhi Yong Wu <wuzhy@linux.vnet.ibm.com>
---
net/core/iovec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/core/iovec.c b/net/core/iovec.c
index b77eeec..4cdb7c4 100644
--- a/net/core/iovec.c
+++ b/net/core/iovec.c
@@ -100,7 +100,7 @@ int memcpy_toiovecend(const struct iovec *iov, unsigned char *kdata,
EXPORT_SYMBOL(memcpy_toiovecend);
/*
- * Copy iovec from kernel. Returns -EFAULT on error.
+ * Copy iovec to kernel. Returns -EFAULT on error.
*/
int memcpy_fromiovecend(unsigned char *kdata, const struct iovec *iov,
--
1.7.11.7
^ permalink raw reply related
* [PATCH 1/3] vxlan: silence one build warning
From: Zhi Yong Wu @ 2013-10-25 7:49 UTC (permalink / raw)
To: netdev; +Cc: linux-kernel, Zhi Yong Wu
From: Zhi Yong Wu <wuzhy@linux.vnet.ibm.com>
drivers/net/vxlan.c: In function ‘vxlan_sock_add’:
drivers/net/vxlan.c:2298:11: warning: ‘sock’ may be used uninitialized in this function [-Wmaybe-uninitialized]
drivers/net/vxlan.c:2275:17: note: ‘sock’ was declared here
LD drivers/net/built-in.o
Signed-off-by: Zhi Yong Wu <wuzhy@linux.vnet.ibm.com>
---
drivers/net/vxlan.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/vxlan.c b/drivers/net/vxlan.c
index 2ef5b62..e15f1af 100644
--- a/drivers/net/vxlan.c
+++ b/drivers/net/vxlan.c
@@ -2272,7 +2272,7 @@ static struct vxlan_sock *vxlan_socket_create(struct net *net, __be16 port,
{
struct vxlan_net *vn = net_generic(net, vxlan_net_id);
struct vxlan_sock *vs;
- struct socket *sock;
+ struct socket *sock = NULL;
struct sock *sk;
int rc = 0;
unsigned int h;
--
1.7.11.7
^ permalink raw reply related
* Kernel 3.12: netconsole no longer working with bridged network interfaces ?
From: Bart Van Assche @ 2013-10-25 7:26 UTC (permalink / raw)
To: netdev@vger.kernel.org; +Cc: David Miller
Hello,
If I try to enable netconsole with kernel 3.12-rc5 on a non-bridged
network interface (e.g. controlled by the virtio_net driver) that works
fine. However, if I try to enable netconsole with kernel 3.12-rc5 on a
bridged network interface the remote system does not receive any kernel
messages over the network. Enabling netconsole over a bridged network
interface works fine with every older kernel I have tried so far (e.g.
3.11.6). Did I perhaps run into a regression ?
Thanks,
Bart.
^ permalink raw reply
* Re: crypto: skcipher - Use eseqiv even on UP machines
From: Steffen Klassert @ 2013-10-25 6:50 UTC (permalink / raw)
To: Herbert Xu; +Cc: David S. Miller, netdev, Linux Crypto Mailing List
In-Reply-To: <20131024124149.GA10587@gondor.apana.org.au>
On Thu, Oct 24, 2013 at 08:41:49PM +0800, Herbert Xu wrote:
> Hi:
>
> Previously we would use eseqiv on all async ciphers in all cases,
> and sync ciphers if we have more than one CPU. This meant that
> chainiv is only used in the case of sync ciphers on a UP machine.
>
> As chainiv may aid attackers by making the IV predictable, even
> though this risk itself is small, the above usage pattern causes
> it to further leak information about the host.
>
> This patch addresses these issues by using eseqiv even if we're
> on a UP machine.
>
> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
>
That's fine by me.
Acked-by: Steffen Klassert <steffen.klassert@secunet.com>
^ permalink raw reply
* Re: [PATCH net-next 1/6] epic100: replace printk with netdev_ calls
From: Joe Perches @ 2013-10-25 6:41 UTC (permalink / raw)
To: Ben Boeckel; +Cc: netdev
In-Reply-To: <1382682422-22677-2-git-send-email-mathstuf@gmail.com>
On Fri, 2013-10-25 at 02:26 -0400, Ben Boeckel wrote:
> Signed-off-by: Ben Boeckel <mathstuf@gmail.com>
Hi Ben.
Please run your patches through checkpatch.pl
> diff --git a/drivers/net/ethernet/smsc/epic100.c b/drivers/net/ethernet/smsc/epic100.c
[]
> @@ -490,7 +488,7 @@ static int epic_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
> if (ret < 0)
> goto err_out_unmap_rx;
>
> - printk(KERN_INFO "%s: %s at %lx, IRQ %d, %pM\n",
> + netdev_info(dev, "%s: %s at %lx, IRQ %d, %pM\n",
> dev->name, pci_id_tbl[chip_idx].name,
> (long)pci_resource_start(pdev, EPIC_BAR), pdev->irq,
> dev->dev_addr);
Please align the subsequent lines to the open parenthesis
and this conversion would now emit dev->name twice.
Try:
netdev_info(dev, "%s at %lx, IRQ %d, %pM\n",
pci_id_tbl[chip_idx].name,
(long)pci_resource_start(pdev, EPIC_BAR),
pdev->irq, dev->dev_addr);
> @@ -703,7 +701,7 @@ static int epic_open(struct net_device *dev)
> mdio_write(dev, ep->phys[0], MII_BMCR, media2miictl[dev->if_port&15]);
> if (dev->if_port == 1) {
> if (debug > 1)
> - printk(KERN_INFO "%s: Using the 10base2 transceiver, MII "
> + netdev_info(dev, "%s: Using the 10base2 transceiver, MII "
> "status %4.4x.\n",
Please coalesce the format fragments into a single line.
> dev->name, mdio_read(dev, ep->phys[0], MII_BMSR));
same problem with duplicate dev->name
etc.
^ permalink raw reply
* [PATCH net-next 6/6] smsc9420: replace printk with netdev_ calls
From: Ben Boeckel @ 2013-10-25 6:27 UTC (permalink / raw)
To: netdev; +Cc: Ben Boeckel
In-Reply-To: <1382682422-22677-1-git-send-email-mathstuf@gmail.com>
Signed-off-by: Ben Boeckel <mathstuf@gmail.com>
---
drivers/net/ethernet/smsc/smsc9420.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/smsc/smsc9420.c b/drivers/net/ethernet/smsc/smsc9420.c
index e55e336..6840304 100644
--- a/drivers/net/ethernet/smsc/smsc9420.c
+++ b/drivers/net/ethernet/smsc/smsc9420.c
@@ -1600,24 +1600,24 @@ smsc9420_probe(struct pci_dev *pdev, const struct pci_device_id *id)
SET_NETDEV_DEV(dev, &pdev->dev);
if (!(pci_resource_flags(pdev, SMSC_BAR) & IORESOURCE_MEM)) {
- printk(KERN_ERR "Cannot find PCI device base address\n");
+ netdev_err(dev, "Cannot find PCI device base address\n");
goto out_free_netdev_2;
}
if ((pci_request_regions(pdev, DRV_NAME))) {
- printk(KERN_ERR "Cannot obtain PCI resources, aborting.\n");
+ netdev_err(dev, "Cannot obtain PCI resources, aborting.\n");
goto out_free_netdev_2;
}
if (pci_set_dma_mask(pdev, DMA_BIT_MASK(32))) {
- printk(KERN_ERR "No usable DMA configuration, aborting.\n");
+ netdev_err(dev, "No usable DMA configuration, aborting.\n");
goto out_free_regions_3;
}
virt_addr = ioremap(pci_resource_start(pdev, SMSC_BAR),
pci_resource_len(pdev, SMSC_BAR));
if (!virt_addr) {
- printk(KERN_ERR "Cannot map device registers, aborting.\n");
+ netdev_err(dev, "Cannot map device registers, aborting.\n");
goto out_free_regions_3;
}
--
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