* Re: [PATCH] mwifiex: Fix skipped vendor specific IEs
From: Sergei Shtylyov @ 2018-07-24 9:07 UTC (permalink / raw)
To: roman.stratiienko, akarwar
Cc: nishants, kvalo, linux-wireless, netdev, linux-kernel
In-Reply-To: <1532352699-3232-1-git-send-email-roman.stratiienko@globallogic.com>
Hello!
On 7/23/2018 4:31 PM, roman.stratiienko@globallogic.com wrote:
> From: Roman Stratiienko <roman.stratiienko@globallogic.com>
>
> Only microsoft specific IE is added by FW
> Let other IEs to pass from userspace
"To" not needed here.
>
> Signed-off-by: Roman Stratiienko <roman.stratiienko@globallogic.com>
> ---
> drivers/net/wireless/marvell/mwifiex/ie.c | 10 +++++++++-
> 1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/marvell/mwifiex/ie.c b/drivers/net/wireless/marvell/mwifiex/ie.c
> index c488c30..c58b345 100644
> --- a/drivers/net/wireless/marvell/mwifiex/ie.c
> +++ b/drivers/net/wireless/marvell/mwifiex/ie.c
> @@ -353,8 +353,16 @@ static int mwifiex_uap_parse_tail_ies(struct mwifiex_private *priv,
> case WLAN_EID_HT_OPERATION:
> case WLAN_EID_VHT_CAPABILITY:
> case WLAN_EID_VHT_OPERATION:
> - case WLAN_EID_VENDOR_SPECIFIC:
> break;
> + case WLAN_EID_VENDOR_SPECIFIC:
> + /* Skip only Microsoft IE that added by FW
^^^^
That's?
> + * Let other vendor specific IE to pass
"To" not needed here as well...
[...]
MBR, Sergei
^ permalink raw reply
* Re: [PATCH] net/p9/trans_fd.c: fix double list_del()
From: Dominique Martinet @ 2018-07-24 10:19 UTC (permalink / raw)
To: Tomas Bortoli
Cc: jiangyiwen, davem, v9fs-developer, netdev, linux-kernel,
syzkaller
In-Reply-To: <844e4101-6980-82dd-6f02-0a7193ed438c@gmail.com>
Tomas Bortoli wrote on Tue, Jul 24, 2018:
> >> @@ -228,6 +226,7 @@ static void p9_conn_cancel(struct p9_conn *m, int err)
> >> req->t_err = err;
> >> p9_client_cb(m->client, req, REQ_STATUS_ERROR);
> >> }
> >> + spin_unlock(&m->client->lock);
> >
> > If you want to expand the ranges of client->lock, the cancel_list will not
> > be necessary, you can optimize this code.
> >
>
> Unfortunately, not. Moving the spin_lock() before the for makes the
> crash appear again. This because the calls to list_move() in the for
> before delete all the elements from req->req_list, so the list is empty,
> another call to list_del() would trigger a double del.
> That's why we hold the lock to update the status of all those requests..
> otherwise we have again the race with p9_fd_cancel().
What (I think) he meant is that since you're holding the lock all the
way, you don't need to transfer all the items to a temporary list to
loop on it immediately afterwards, but you could call the client cb
directly.
I'm personally not a fan of this approach as that would duplicate the
code, even if the loop isn't big...
This code is only called at disconnect time so I think using the extra
list doesn't hurt anyone; but as usual do what you feel is better; I
don't mind much either way.
--
Dominique Martinet
^ permalink raw reply
* Re: [PATCH] netfilter: avoid stalls in nf_ct_alloc_hashtable
From: Florian Westphal @ 2018-07-24 9:19 UTC (permalink / raw)
To: Li RongQing; +Cc: netdev, pablo, kadlec, fw
In-Reply-To: <1532416745-9926-1-git-send-email-lirongqing@baidu.com>
Li RongQing <lirongqing@baidu.com> wrote:
> when system forks a process with CLONE_NEWNET flag under the
> high memory pressure, it will trigger memory reclaim and stall
> for a long time because nf_ct_alloc_hashtable need to allocate
> high-order memory at that time. The calltrace as below:
> nf_ct_alloc_hashtable
> nf_conntrack_init_net
This call trace is from a kernel < 4.7.
commit 56d52d4892d0e478a005b99ed10d0a7f488ea8c1
netfilter: conntrack: use a single hashtable for all namespaces
removed per-netns hash table.
^ permalink raw reply
* Re: [PATCH v3 bpf-next 3/8] veth: Avoid drops by oversized packets when XDP is enabled
From: Toshiaki Makita @ 2018-07-24 9:39 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Toshiaki Makita, netdev, Alexei Starovoitov, Daniel Borkmann,
Jesper Dangaard Brouer
In-Reply-To: <75bacf34-0dd8-a49a-b595-001400f36349@lab.ntt.co.jp>
On 2018/07/24 10:56, Toshiaki Makita wrote:
> On 2018/07/24 9:27, Jakub Kicinski wrote:
>> On Mon, 23 Jul 2018 00:13:03 +0900, Toshiaki Makita wrote:
>>> From: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
>>>
>>> All oversized packets including GSO packets are dropped if XDP is
>>> enabled on receiver side, so don't send such packets from peer.
>>>
>>> Drop TSO and SCTP fragmentation features so that veth devices themselves
>>> segment packets with XDP enabled. Also cap MTU accordingly.
>>>
>>> Signed-off-by: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
>>
>> Is there any precedence for fixing up features and MTU like this? Most
>> drivers just refuse to install the program if settings are incompatible.
>
> I don't know any precedence. I can refuse the program on installing it
> when features and MTU are not appropriate. Is it preferred?
> Note that with current implementation wanted_features are not touched so
> features will be restored when the XDP program is removed. MTU will not
> be restored though, as I do not remember the original MTU.
I just recalled that virtio_net used to refused XDP when guest offload
features are incompatible but now it dynamically fixup them on
installing an XDP program.
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3f93522ffab2d46a36b57adf324a54e674fc9536
--
Toshiaki Makita
^ permalink raw reply
* Re: [PATCH] net/p9/trans_fd.c: fix double list_del()
From: Tomas Bortoli @ 2018-07-24 10:47 UTC (permalink / raw)
To: Dominique Martinet
Cc: jiangyiwen, davem, v9fs-developer, netdev, linux-kernel,
syzkaller
In-Reply-To: <20180724101932.GA17454@nautica>
On 07/24/2018 12:19 PM, Dominique Martinet wrote:
> Tomas Bortoli wrote on Tue, Jul 24, 2018:
>>>> @@ -228,6 +226,7 @@ static void p9_conn_cancel(struct p9_conn *m, int err)
>>>> req->t_err = err;
>>>> p9_client_cb(m->client, req, REQ_STATUS_ERROR);
>>>> }
>>>> + spin_unlock(&m->client->lock);
>>>
>>> If you want to expand the ranges of client->lock, the cancel_list will not
>>> be necessary, you can optimize this code.
>>>
>>
>> Unfortunately, not. Moving the spin_lock() before the for makes the
>> crash appear again. This because the calls to list_move() in the for
>> before delete all the elements from req->req_list, so the list is empty,
>> another call to list_del() would trigger a double del.
>> That's why we hold the lock to update the status of all those requests..
>> otherwise we have again the race with p9_fd_cancel().
>
> What (I think) he meant is that since you're holding the lock all the
> way, you don't need to transfer all the items to a temporary list to
> loop on it immediately afterwards, but you could call the client cb
> directly.
>
Yeah that is possible.
> I'm personally not a fan of this approach as that would duplicate the
> code, even if the loop isn't big...
Yep
>
> This code is only called at disconnect time so I think using the extra
> list doesn't hurt anyone; but as usual do what you feel is better; I
> don't mind much either way.
>
I think it's fine as it is.
^ permalink raw reply
* [PATCH net 1/1] bnx2x: Fix invalid memory access in rss hash config path.
From: Sudarsana Reddy Kalluru @ 2018-07-24 9:43 UTC (permalink / raw)
To: davem; +Cc: netdev, ariel.elior
Rx hash/filter table configuration uses rss_conf_obj to configure filters
in the hardware. This object is initialized only when the interface is
brought up.
This patch adds driver changes to configure rss params only when the device
is in opened state. In port disabled case, the config will be cached in the
driver structure which will be applied in the successive load path.
Please consider applying it to 'net' branch.
Signed-off-by: Sudarsana Reddy Kalluru <Sudarsana.Kalluru@cavium.com>
---
drivers/net/ethernet/broadcom/bnx2x/bnx2x_ethtool.c | 13 ++++++++++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_ethtool.c b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_ethtool.c
index da18aa2..a4a90b6c 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_ethtool.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_ethtool.c
@@ -3388,14 +3388,18 @@ static int bnx2x_set_rss_flags(struct bnx2x *bp, struct ethtool_rxnfc *info)
DP(BNX2X_MSG_ETHTOOL,
"rss re-configured, UDP 4-tupple %s\n",
udp_rss_requested ? "enabled" : "disabled");
- return bnx2x_rss(bp, &bp->rss_conf_obj, false, true);
+ if (bp->state == BNX2X_STATE_OPEN)
+ return bnx2x_rss(bp, &bp->rss_conf_obj, false,
+ true);
} else if ((info->flow_type == UDP_V6_FLOW) &&
(bp->rss_conf_obj.udp_rss_v6 != udp_rss_requested)) {
bp->rss_conf_obj.udp_rss_v6 = udp_rss_requested;
DP(BNX2X_MSG_ETHTOOL,
"rss re-configured, UDP 4-tupple %s\n",
udp_rss_requested ? "enabled" : "disabled");
- return bnx2x_rss(bp, &bp->rss_conf_obj, false, true);
+ if (bp->state == BNX2X_STATE_OPEN)
+ return bnx2x_rss(bp, &bp->rss_conf_obj, false,
+ true);
}
return 0;
@@ -3509,7 +3513,10 @@ static int bnx2x_set_rxfh(struct net_device *dev, const u32 *indir,
bp->rss_conf_obj.ind_table[i] = indir[i] + bp->fp->cl_id;
}
- return bnx2x_config_rss_eth(bp, false);
+ if (bp->state == BNX2X_STATE_OPEN)
+ return bnx2x_config_rss_eth(bp, false);
+
+ return 0;
}
/**
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH v3] hv_netvsc: Add per-cpu ethtool stats for netvsc
From: Vitaly Kuznetsov @ 2018-07-24 11:00 UTC (permalink / raw)
To: Yidong Ren
Cc: Stephen Hemminger, netdev@vger.kernel.org, Haiyang Zhang,
linux-kernel@vger.kernel.org, Madhan Sivakumar,
devel@linuxdriverproject.org, David S. Miller
In-Reply-To: <SN6PR2101MB11359728E41C4B2AB8E7736D84550@SN6PR2101MB1135.namprd21.prod.outlook.com>
Yidong Ren <Yidong.Ren@microsoft.com> writes:
>> From: Yidong Ren <yidren@linuxonhyperv.com>
>> Sent: Monday, July 23, 2018 6:26 PM
>> + pcpu_sum = kvmalloc(sizeof(struct netvsc_ethtool_pcpu_stats) *
>> + num_present_cpus(), GFP_KERNEL);
>
> Since there is no plan for CPU hotplug in Hyper-V in short term, it is fine
> to use num_present_cpus for now. We can move to debugfs later if necessary.
While you do for_each_present_cpu() in netvsc_get_ethtool_stats(),
netvsc_get_pcpu_stats() does for_each_possible_cpu(). This looks
inconsistent.
The allocation you're doing here is short-lived so I would suggest you
use possible_cpus everywhere. Even knowing there's no CPU hotplug on
Hyper-V at this moment, it can appear later and we'll get a hard-to-find
issue. Moreover, we may consider using netvsc driver on e.g. KVM with
Hyper-V enlightenments and KVM has CPU hotplug already.
--
Vitaly
^ permalink raw reply
* Re: [PATCH] netfilter: avoid stalls in nf_ct_alloc_hashtable
From: Sergei Shtylyov @ 2018-07-24 9:58 UTC (permalink / raw)
To: Li RongQing, netdev, pablo, kadlec, fw
In-Reply-To: <1532416745-9926-1-git-send-email-lirongqing@baidu.com>
Hello!
On 7/24/2018 10:19 AM, Li RongQing wrote:
> when system forks a process with CLONE_NEWNET flag under the
> high memory pressure, it will trigger memory reclaim and stall
> for a long time because nf_ct_alloc_hashtable need to allocate
> high-order memory at that time. The calltrace as below:
>
> delay_tsc
> __delay
> _raw_spin_lock
> _spin_lock
> mmu_shrink
> shrink_slab
> zone_reclaim
> get_page_from_freelist
> __alloc_pages_nodemask
> alloc_pages_current
> __get_free_pages
> nf_ct_alloc_hashtable
> nf_conntrack_init_net
> setup_net
> copy_net_ns
> create_new_namespaces
> copy_namespaces
> copy_process
> do_fork
> sys_clone
> stub_clone
> __clone
>
> not use the directly memory reclaim flag to avoid stall
You mean "do not use"?
> Signed-off-by: Ni Xun <nixun@baidu.com>
> Signed-off-by: Zhang Yu <zhangyu31@baidu.com>
> Signed-off-by: Wang Li <wangli39@baidu.com>
> Signed-off-by: Li RongQing <lirongqing@baidu.com>
[...]
MBR, Sergei
^ permalink raw reply
* 答复: [PATCH] netfilter: avoid stalls in nf_ct_alloc_hashtable
From: Li,Rongqing @ 2018-07-24 9:50 UTC (permalink / raw)
To: Florian Westphal
Cc: netdev@vger.kernel.org, pablo@netfilter.org,
kadlec@blackhole.kfki.hu
In-Reply-To: <20180724091946.d3b764rlsuid4jai@breakpoint.cc>
> -----邮件原件-----
> 发件人: Florian Westphal [mailto:fw@strlen.de]
> 发送时间: 2018年7月24日 17:20
> 收件人: Li,Rongqing <lirongqing@baidu.com>
> 抄送: netdev@vger.kernel.org; pablo@netfilter.org;
> kadlec@blackhole.kfki.hu; fw@strlen.de
> 主题: Re: [PATCH] netfilter: avoid stalls in nf_ct_alloc_hashtable
>
> Li RongQing <lirongqing@baidu.com> wrote:
> > when system forks a process with CLONE_NEWNET flag under the high
> > memory pressure, it will trigger memory reclaim and stall for a long
> > time because nf_ct_alloc_hashtable need to allocate high-order memory
> > at that time. The calltrace as below:
>
> > nf_ct_alloc_hashtable
> > nf_conntrack_init_net
>
> This call trace is from a kernel < 4.7.
>
Sorry; it is
> commit 56d52d4892d0e478a005b99ed10d0a7f488ea8c1
> netfilter: conntrack: use a single hashtable for all namespaces
>
> removed per-netns hash table.
Thanks, Your patch fixes my issue;
My patch may be able to reduce stall when modprobe nf module in memory stress,
Do you think this patch has any value?
-RongQing
^ permalink raw reply
* [PATCH 1/4] treewide: convert ISO_8859-1 text comments to utf-8
From: Arnd Bergmann @ 2018-07-24 11:13 UTC (permalink / raw)
To: Andrew Morton
Cc: Joe Perches, Arnd Bergmann, Samuel Ortiz, David S. Miller,
Rob Herring, Michael Ellerman, Jonathan Cameron, linux-wireless,
netdev, devicetree, linux-kernel, linux-arm-kernel, linux-crypto,
linuxppc-dev, linux-iio, linux-pm, lvs-devel, netfilter-devel,
coreteam
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=Binary, Size: 30563 bytes --]
Almost all files in the kernel are either plain text or UTF-8
encoded. A couple however are ISO_8859-1, usually just a few
characters in a C comments, for historic reasons.
This converts them all to UTF-8 for consistency.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
.../devicetree/bindings/net/nfc/pn544.txt | 2 +-
arch/arm/boot/dts/sun4i-a10-inet97fv2.dts | 2 +-
arch/arm/crypto/sha256_glue.c | 2 +-
arch/arm/crypto/sha256_neon_glue.c | 4 +-
drivers/crypto/vmx/ghashp8-ppc.pl | 12 +-
drivers/iio/dac/ltc2632.c | 2 +-
drivers/power/reset/ltc2952-poweroff.c | 4 +-
kernel/events/callchain.c | 2 +-
net/netfilter/ipvs/Kconfig | 8 +-
net/netfilter/ipvs/ip_vs_mh.c | 4 +-
tools/power/cpupower/po/de.po | 44 +++----
tools/power/cpupower/po/fr.po | 120 +++++++++---------
12 files changed, 103 insertions(+), 103 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/nfc/pn544.txt b/Documentation/devicetree/bindings/net/nfc/pn544.txt
index 538a86f7b2b0..72593f056b75 100644
--- a/Documentation/devicetree/bindings/net/nfc/pn544.txt
+++ b/Documentation/devicetree/bindings/net/nfc/pn544.txt
@@ -2,7 +2,7 @@
Required properties:
- compatible: Should be "nxp,pn544-i2c".
-- clock-frequency: I²C work frequency.
+- clock-frequency: I²C work frequency.
- reg: address on the bus
- interrupt-parent: phandle for the interrupt gpio controller
- interrupts: GPIO interrupt to which the chip is connected
diff --git a/arch/arm/boot/dts/sun4i-a10-inet97fv2.dts b/arch/arm/boot/dts/sun4i-a10-inet97fv2.dts
index 5d096528e75a..71c27ea0b53e 100644
--- a/arch/arm/boot/dts/sun4i-a10-inet97fv2.dts
+++ b/arch/arm/boot/dts/sun4i-a10-inet97fv2.dts
@@ -1,7 +1,7 @@
/*
* Copyright 2014 Open Source Support GmbH
*
- * David Lanzendörfer <david.lanzendoerfer@o2s.ch>
+ * David Lanzendörfer <david.lanzendoerfer@o2s.ch>
*
* This file is dual-licensed: you can use it either under the terms
* of the GPL or the X11 license, at your option. Note that this dual
diff --git a/arch/arm/crypto/sha256_glue.c b/arch/arm/crypto/sha256_glue.c
index bf8ccff2c9d0..0ae900e778f3 100644
--- a/arch/arm/crypto/sha256_glue.c
+++ b/arch/arm/crypto/sha256_glue.c
@@ -2,7 +2,7 @@
* Glue code for the SHA256 Secure Hash Algorithm assembly implementation
* using optimized ARM assembler and NEON instructions.
*
- * Copyright © 2015 Google Inc.
+ * Copyright © 2015 Google Inc.
*
* This file is based on sha256_ssse3_glue.c:
* Copyright (C) 2013 Intel Corporation
diff --git a/arch/arm/crypto/sha256_neon_glue.c b/arch/arm/crypto/sha256_neon_glue.c
index 9bbee56fbdc8..1d82c6cd31a4 100644
--- a/arch/arm/crypto/sha256_neon_glue.c
+++ b/arch/arm/crypto/sha256_neon_glue.c
@@ -2,10 +2,10 @@
* Glue code for the SHA256 Secure Hash Algorithm assembly implementation
* using NEON instructions.
*
- * Copyright © 2015 Google Inc.
+ * Copyright © 2015 Google Inc.
*
* This file is based on sha512_neon_glue.c:
- * Copyright © 2014 Jussi Kivilinna <jussi.kivilinna@iki.fi>
+ * Copyright © 2014 Jussi Kivilinna <jussi.kivilinna@iki.fi>
*
* This program is free software; you can redistribute it and/or modify it
* under the terms of the GNU General Public License as published by the Free
diff --git a/drivers/crypto/vmx/ghashp8-ppc.pl b/drivers/crypto/vmx/ghashp8-ppc.pl
index f746af271460..38b06503ede0 100644
--- a/drivers/crypto/vmx/ghashp8-ppc.pl
+++ b/drivers/crypto/vmx/ghashp8-ppc.pl
@@ -129,9 +129,9 @@ $code=<<___;
le?vperm $IN,$IN,$IN,$lemask
vxor $zero,$zero,$zero
- vpmsumd $Xl,$IN,$Hl # H.lo·Xi.lo
- vpmsumd $Xm,$IN,$H # H.hi·Xi.lo+H.lo·Xi.hi
- vpmsumd $Xh,$IN,$Hh # H.hi·Xi.hi
+ vpmsumd $Xl,$IN,$Hl # H.lo·Xi.lo
+ vpmsumd $Xm,$IN,$H # H.hi·Xi.lo+H.lo·Xi.hi
+ vpmsumd $Xh,$IN,$Hh # H.hi·Xi.hi
vpmsumd $t2,$Xl,$xC2 # 1st phase
@@ -187,11 +187,11 @@ $code=<<___;
.align 5
Loop:
subic $len,$len,16
- vpmsumd $Xl,$IN,$Hl # H.lo·Xi.lo
+ vpmsumd $Xl,$IN,$Hl # H.lo·Xi.lo
subfe. r0,r0,r0 # borrow?-1:0
- vpmsumd $Xm,$IN,$H # H.hi·Xi.lo+H.lo·Xi.hi
+ vpmsumd $Xm,$IN,$H # H.hi·Xi.lo+H.lo·Xi.hi
and r0,r0,$len
- vpmsumd $Xh,$IN,$Hh # H.hi·Xi.hi
+ vpmsumd $Xh,$IN,$Hh # H.hi·Xi.hi
add $inp,$inp,r0
vpmsumd $t2,$Xl,$xC2 # 1st phase
diff --git a/drivers/iio/dac/ltc2632.c b/drivers/iio/dac/ltc2632.c
index cca278eaa138..885105135580 100644
--- a/drivers/iio/dac/ltc2632.c
+++ b/drivers/iio/dac/ltc2632.c
@@ -1,7 +1,7 @@
/*
* LTC2632 Digital to analog convertors spi driver
*
- * Copyright 2017 Maxime Roussin-Bélanger
+ * Copyright 2017 Maxime Roussin-Bélanger
* expanded by Silvan Murer <silvan.murer@gmail.com>
*
* Licensed under the GPL-2.
diff --git a/drivers/power/reset/ltc2952-poweroff.c b/drivers/power/reset/ltc2952-poweroff.c
index 6b911b6b10a6..c484584745bc 100644
--- a/drivers/power/reset/ltc2952-poweroff.c
+++ b/drivers/power/reset/ltc2952-poweroff.c
@@ -2,7 +2,7 @@
* LTC2952 (PowerPath) driver
*
* Copyright (C) 2014, Xsens Technologies BV <info@xsens.com>
- * Maintainer: René Moll <linux@r-moll.nl>
+ * Maintainer: René Moll <linux@r-moll.nl>
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License
@@ -319,6 +319,6 @@ static struct platform_driver ltc2952_poweroff_driver = {
module_platform_driver(ltc2952_poweroff_driver);
-MODULE_AUTHOR("René Moll <rene.moll@xsens.com>");
+MODULE_AUTHOR("René Moll <rene.moll@xsens.com>");
MODULE_DESCRIPTION("LTC PowerPath power-off driver");
MODULE_LICENSE("GPL v2");
diff --git a/kernel/events/callchain.c b/kernel/events/callchain.c
index c187aa3df3c8..24a77c34e9ad 100644
--- a/kernel/events/callchain.c
+++ b/kernel/events/callchain.c
@@ -4,7 +4,7 @@
* Copyright (C) 2008 Thomas Gleixner <tglx@linutronix.de>
* Copyright (C) 2008-2011 Red Hat, Inc., Ingo Molnar
* Copyright (C) 2008-2011 Red Hat, Inc., Peter Zijlstra
- * Copyright © 2009 Paul Mackerras, IBM Corp. <paulus@au1.ibm.com>
+ * Copyright © 2009 Paul Mackerras, IBM Corp. <paulus@au1.ibm.com>
*
* For licensing details see kernel-base/COPYING
*/
diff --git a/net/netfilter/ipvs/Kconfig b/net/netfilter/ipvs/Kconfig
index 05dc1b77e466..cad48d07c818 100644
--- a/net/netfilter/ipvs/Kconfig
+++ b/net/netfilter/ipvs/Kconfig
@@ -296,10 +296,10 @@ config IP_VS_MH_TAB_INDEX
stored in a hash table. This table is assigned by a preference
list of the positions to each destination until all slots in
the table are filled. The index determines the prime for size of
- the table as 251, 509, 1021, 2039, 4093, 8191, 16381, 32749,
- 65521 or 131071. When using weights to allow destinations to
- receive more connections, the table is assigned an amount
- proportional to the weights specified. The table needs to be large
+ the table as 251, 509, 1021, 2039, 4093, 8191, 16381, 32749,
+ 65521 or 131071. When using weights to allow destinations to
+ receive more connections, the table is assigned an amount
+ proportional to the weights specified. The table needs to be large
enough to effectively fit all the destinations multiplied by their
respective weights.
diff --git a/net/netfilter/ipvs/ip_vs_mh.c b/net/netfilter/ipvs/ip_vs_mh.c
index 0f795b186eb3..94d9d349ebb0 100644
--- a/net/netfilter/ipvs/ip_vs_mh.c
+++ b/net/netfilter/ipvs/ip_vs_mh.c
@@ -5,10 +5,10 @@
*
*/
-/* The mh algorithm is to assign a preference list of all the lookup
+/* The mh algorithm is to assign a preference list of all the lookup
* table positions to each destination and populate the table with
* the most-preferred position of destinations. Then it is to select
- * destination with the hash key of source IP address through looking
+ * destination with the hash key of source IP address through looking
* up a the lookup table.
*
* The algorithm is detailed in:
diff --git a/tools/power/cpupower/po/de.po b/tools/power/cpupower/po/de.po
index 78c09e51663a..840c17cc450a 100644
--- a/tools/power/cpupower/po/de.po
+++ b/tools/power/cpupower/po/de.po
@@ -323,12 +323,12 @@ msgstr " Hardwarebedingte Grenzen der Taktfrequenz: "
#: utils/cpufreq-info.c:256
#, c-format
msgid " available frequency steps: "
-msgstr " mögliche Taktfrequenzen: "
+msgstr " mögliche Taktfrequenzen: "
#: utils/cpufreq-info.c:269
#, c-format
msgid " available cpufreq governors: "
-msgstr " mögliche Regler: "
+msgstr " mögliche Regler: "
#: utils/cpufreq-info.c:280
#, c-format
@@ -381,7 +381,7 @@ msgstr "Optionen:\n"
msgid " -e, --debug Prints out debug information [default]\n"
msgstr ""
" -e, --debug Erzeugt detaillierte Informationen, hilfreich\n"
-" zum Aufspüren von Fehlern\n"
+" zum Aufspüren von Fehlern\n"
#: utils/cpufreq-info.c:475
#, c-format
@@ -424,7 +424,7 @@ msgstr " -p, --policy Findet die momentane Taktik heraus *\n"
#: utils/cpufreq-info.c:482
#, c-format
msgid " -g, --governors Determines available cpufreq governors *\n"
-msgstr " -g, --governors Erzeugt eine Liste mit verfügbaren Reglern *\n"
+msgstr " -g, --governors Erzeugt eine Liste mit verfügbaren Reglern *\n"
#: utils/cpufreq-info.c:483
#, c-format
@@ -450,7 +450,7 @@ msgstr ""
#, c-format
msgid " -s, --stats Shows cpufreq statistics if available\n"
msgstr ""
-" -s, --stats Zeigt, sofern möglich, Statistiken über cpufreq an.\n"
+" -s, --stats Zeigt, sofern möglich, Statistiken über cpufreq an.\n"
#: utils/cpufreq-info.c:487
#, c-format
@@ -473,9 +473,9 @@ msgid ""
"cpufreq\n"
" interface in 2.4. and early 2.6. kernels\n"
msgstr ""
-" -o, --proc Erzeugt Informationen in einem ähnlichem Format zu "
+" -o, --proc Erzeugt Informationen in einem ähnlichem Format zu "
"dem\n"
-" der /proc/cpufreq-Datei in 2.4. und frühen 2.6.\n"
+" der /proc/cpufreq-Datei in 2.4. und frühen 2.6.\n"
" Kernel-Versionen\n"
#: utils/cpufreq-info.c:491
@@ -491,7 +491,7 @@ msgstr ""
#: utils/cpufreq-info.c:492 utils/cpuidle-info.c:152
#, c-format
msgid " -h, --help Prints out this screen\n"
-msgstr " -h, --help Gibt diese Kurzübersicht aus\n"
+msgstr " -h, --help Gibt diese Kurzübersicht aus\n"
#: utils/cpufreq-info.c:495
#, c-format
@@ -501,7 +501,7 @@ msgid ""
msgstr ""
"Sofern kein anderer Parameter als '-c, --cpu' angegeben wird, liefert "
"dieses\n"
-"Programm Informationen, die z.B. zum Berichten von Fehlern nützlich sind.\n"
+"Programm Informationen, die z.B. zum Berichten von Fehlern nützlich sind.\n"
#: utils/cpufreq-info.c:497
#, c-format
@@ -557,7 +557,7 @@ msgid ""
"select\n"
msgstr ""
" -d FREQ, --min FREQ neue minimale Taktfrequenz, die der Regler\n"
-" auswählen darf\n"
+" auswählen darf\n"
#: utils/cpufreq-set.c:28
#, c-format
@@ -566,7 +566,7 @@ msgid ""
"select\n"
msgstr ""
" -u FREQ, --max FREQ neue maximale Taktfrequenz, die der Regler\n"
-" auswählen darf\n"
+" auswählen darf\n"
#: utils/cpufreq-set.c:29
#, c-format
@@ -579,20 +579,20 @@ msgid ""
" -f FREQ, --freq FREQ specific frequency to be set. Requires userspace\n"
" governor to be available and loaded\n"
msgstr ""
-" -f FREQ, --freq FREQ setze exakte Taktfrequenz. Benötigt den Regler\n"
+" -f FREQ, --freq FREQ setze exakte Taktfrequenz. Benötigt den Regler\n"
" 'userspace'.\n"
#: utils/cpufreq-set.c:32
#, c-format
msgid " -r, --related Switches all hardware-related CPUs\n"
msgstr ""
-" -r, --related Setze Werte für alle CPUs, deren Taktfrequenz\n"
+" -r, --related Setze Werte für alle CPUs, deren Taktfrequenz\n"
" hardwarebedingt identisch ist.\n"
#: utils/cpufreq-set.c:33 utils/cpupower-set.c:28 utils/cpupower-info.c:27
#, c-format
msgid " -h, --help Prints out this screen\n"
-msgstr " -h, --help Gibt diese Kurzübersicht aus\n"
+msgstr " -h, --help Gibt diese Kurzübersicht aus\n"
#: utils/cpufreq-set.c:35
#, fuzzy, c-format
@@ -618,8 +618,8 @@ msgstr ""
" angenommen\n"
"2. Der Parameter -f bzw. --freq kann mit keinem anderen als dem Parameter\n"
" -c bzw. --cpu kombiniert werden\n"
-"3. FREQuenzen können in Hz, kHz (Standard), MHz, GHz oder THz eingegeben\n"
-" werden, indem der Wert und unmittelbar anschließend (ohne Leerzeichen!)\n"
+"3. FREQuenzen können in Hz, kHz (Standard), MHz, GHz oder THz eingegeben\n"
+" werden, indem der Wert und unmittelbar anschließend (ohne Leerzeichen!)\n"
" die Einheit angegeben werden. (Bsp: 1GHz )\n"
" (FREQuenz in kHz =^ MHz * 1000 =^ GHz * 1000000).\n"
@@ -638,7 +638,7 @@ msgid ""
msgstr ""
"Beim Einstellen ist ein Fehler aufgetreten. Typische Fehlerquellen sind:\n"
"- nicht ausreichende Rechte (Administrator)\n"
-"- der Regler ist nicht verfügbar bzw. nicht geladen\n"
+"- der Regler ist nicht verfügbar bzw. nicht geladen\n"
"- die angegebene Taktik ist inkorrekt\n"
"- eine spezifische Frequenz wurde angegeben, aber der Regler 'userspace'\n"
" kann entweder hardwarebedingt nicht genutzt werden oder ist nicht geladen\n"
@@ -821,7 +821,7 @@ msgstr ""
#: utils/cpuidle-info.c:48
#, fuzzy, c-format
msgid "Available idle states:"
-msgstr " mögliche Taktfrequenzen: "
+msgstr " mögliche Taktfrequenzen: "
#: utils/cpuidle-info.c:71
#, c-format
@@ -924,7 +924,7 @@ msgstr "Aufruf: cpufreq-info [Optionen]\n"
msgid " -s, --silent Only show general C-state information\n"
msgstr ""
" -e, --debug Erzeugt detaillierte Informationen, hilfreich\n"
-" zum Aufspüren von Fehlern\n"
+" zum Aufspüren von Fehlern\n"
#: utils/cpuidle-info.c:150
#, fuzzy, c-format
@@ -933,9 +933,9 @@ msgid ""
"acpi/processor/*/power\n"
" interface in older kernels\n"
msgstr ""
-" -o, --proc Erzeugt Informationen in einem ähnlichem Format zu "
+" -o, --proc Erzeugt Informationen in einem ähnlichem Format zu "
"dem\n"
-" der /proc/cpufreq-Datei in 2.4. und frühen 2.6.\n"
+" der /proc/cpufreq-Datei in 2.4. und frühen 2.6.\n"
" Kernel-Versionen\n"
#: utils/cpuidle-info.c:209
@@ -949,7 +949,7 @@ msgstr ""
#~ " -c CPU, --cpu CPU CPU number which information shall be determined "
#~ "about\n"
#~ msgstr ""
-#~ " -c CPU, --cpu CPU Nummer der CPU, über die Informationen "
+#~ " -c CPU, --cpu CPU Nummer der CPU, über die Informationen "
#~ "herausgefunden werden sollen\n"
#~ msgid ""
diff --git a/tools/power/cpupower/po/fr.po b/tools/power/cpupower/po/fr.po
index 245ad20a9bf9..b46ca2548f86 100644
--- a/tools/power/cpupower/po/fr.po
+++ b/tools/power/cpupower/po/fr.po
@@ -212,7 +212,7 @@ msgstr ""
#: utils/cpupower.c:91
#, c-format
msgid "Report errors and bugs to %s, please.\n"
-msgstr "Veuillez rapportez les erreurs et les bogues à %s, s'il vous plait.\n"
+msgstr "Veuillez rapportez les erreurs et les bogues à %s, s'il vous plait.\n"
#: utils/cpupower.c:114
#, c-format
@@ -227,14 +227,14 @@ msgstr ""
#: utils/cpufreq-info.c:31
#, c-format
msgid "Couldn't count the number of CPUs (%s: %s), assuming 1\n"
-msgstr "Détermination du nombre de CPUs (%s : %s) impossible. Assume 1\n"
+msgstr "Détermination du nombre de CPUs (%s : %s) impossible. Assume 1\n"
#: utils/cpufreq-info.c:63
#, c-format
msgid ""
" minimum CPU frequency - maximum CPU frequency - governor\n"
msgstr ""
-" Fréquence CPU minimale - Fréquence CPU maximale - régulateur\n"
+" Fréquence CPU minimale - Fréquence CPU maximale - régulateur\n"
#: utils/cpufreq-info.c:151
#, c-format
@@ -302,12 +302,12 @@ msgstr " pilote : %s\n"
#: utils/cpufreq-info.c:219
#, fuzzy, c-format
msgid " CPUs which run at the same hardware frequency: "
-msgstr " CPUs qui doivent changer de fréquences en même temps : "
+msgstr " CPUs qui doivent changer de fréquences en même temps : "
#: utils/cpufreq-info.c:230
#, fuzzy, c-format
msgid " CPUs which need to have their frequency coordinated by software: "
-msgstr " CPUs qui doivent changer de fréquences en même temps : "
+msgstr " CPUs qui doivent changer de fréquences en même temps : "
#: utils/cpufreq-info.c:241
#, c-format
@@ -317,22 +317,22 @@ msgstr ""
#: utils/cpufreq-info.c:247
#, c-format
msgid " hardware limits: "
-msgstr " limitation matérielle : "
+msgstr " limitation matérielle : "
#: utils/cpufreq-info.c:256
#, c-format
msgid " available frequency steps: "
-msgstr " plage de fréquence : "
+msgstr " plage de fréquence : "
#: utils/cpufreq-info.c:269
#, c-format
msgid " available cpufreq governors: "
-msgstr " régulateurs disponibles : "
+msgstr " régulateurs disponibles : "
#: utils/cpufreq-info.c:280
#, c-format
msgid " current policy: frequency should be within "
-msgstr " tactique actuelle : la fréquence doit être comprise entre "
+msgstr " tactique actuelle : la fréquence doit être comprise entre "
#: utils/cpufreq-info.c:282
#, c-format
@@ -345,18 +345,18 @@ msgid ""
"The governor \"%s\" may decide which speed to use\n"
" within this range.\n"
msgstr ""
-"Le régulateur \"%s\" est libre de choisir la vitesse\n"
-" dans cette plage de fréquences.\n"
+"Le régulateur \"%s\" est libre de choisir la vitesse\n"
+" dans cette plage de fréquences.\n"
#: utils/cpufreq-info.c:293
#, c-format
msgid " current CPU frequency is "
-msgstr " la fréquence actuelle de ce CPU est "
+msgstr " la fréquence actuelle de ce CPU est "
#: utils/cpufreq-info.c:296
#, c-format
msgid " (asserted by call to hardware)"
-msgstr " (vérifié par un appel direct du matériel)"
+msgstr " (vérifié par un appel direct du matériel)"
#: utils/cpufreq-info.c:304
#, c-format
@@ -377,7 +377,7 @@ msgstr "Options :\n"
#: utils/cpufreq-info.c:474
#, fuzzy, c-format
msgid " -e, --debug Prints out debug information [default]\n"
-msgstr " -e, --debug Afficher les informations de déboguage\n"
+msgstr " -e, --debug Afficher les informations de déboguage\n"
#: utils/cpufreq-info.c:475
#, c-format
@@ -385,8 +385,8 @@ msgid ""
" -f, --freq Get frequency the CPU currently runs at, according\n"
" to the cpufreq core *\n"
msgstr ""
-" -f, --freq Obtenir la fréquence actuelle du CPU selon le point\n"
-" de vue du coeur du système de cpufreq *\n"
+" -f, --freq Obtenir la fréquence actuelle du CPU selon le point\n"
+" de vue du coeur du système de cpufreq *\n"
#: utils/cpufreq-info.c:477
#, c-format
@@ -394,8 +394,8 @@ msgid ""
" -w, --hwfreq Get frequency the CPU currently runs at, by reading\n"
" it from hardware (only available to root) *\n"
msgstr ""
-" -w, --hwfreq Obtenir la fréquence actuelle du CPU directement par\n"
-" le matériel (doit être root) *\n"
+" -w, --hwfreq Obtenir la fréquence actuelle du CPU directement par\n"
+" le matériel (doit être root) *\n"
#: utils/cpufreq-info.c:479
#, c-format
@@ -403,13 +403,13 @@ msgid ""
" -l, --hwlimits Determine the minimum and maximum CPU frequency "
"allowed *\n"
msgstr ""
-" -l, --hwlimits Affiche les fréquences minimales et maximales du CPU "
+" -l, --hwlimits Affiche les fréquences minimales et maximales du CPU "
"*\n"
#: utils/cpufreq-info.c:480
#, c-format
msgid " -d, --driver Determines the used cpufreq kernel driver *\n"
-msgstr " -d, --driver Affiche le pilote cpufreq utilisé *\n"
+msgstr " -d, --driver Affiche le pilote cpufreq utilisé *\n"
#: utils/cpufreq-info.c:481
#, c-format
@@ -420,7 +420,7 @@ msgstr " -p, --policy Affiche la tactique actuelle de cpufreq *\n"
#, c-format
msgid " -g, --governors Determines available cpufreq governors *\n"
msgstr ""
-" -g, --governors Affiche les régulateurs disponibles de cpufreq *\n"
+" -g, --governors Affiche les régulateurs disponibles de cpufreq *\n"
#: utils/cpufreq-info.c:483
#, fuzzy, c-format
@@ -429,7 +429,7 @@ msgid ""
"frequency *\n"
msgstr ""
" -a, --affected-cpus Affiche quels sont les CPUs qui doivent changer de\n"
-" fréquences en même temps *\n"
+" fréquences en même temps *\n"
#: utils/cpufreq-info.c:484
#, fuzzy, c-format
@@ -438,7 +438,7 @@ msgid ""
" coordinated by software *\n"
msgstr ""
" -a, --affected-cpus Affiche quels sont les CPUs qui doivent changer de\n"
-" fréquences en même temps *\n"
+" fréquences en même temps *\n"
#: utils/cpufreq-info.c:486
#, c-format
@@ -453,7 +453,7 @@ msgid ""
" -y, --latency Determines the maximum latency on CPU frequency "
"changes *\n"
msgstr ""
-" -l, --hwlimits Affiche les fréquences minimales et maximales du CPU "
+" -l, --hwlimits Affiche les fréquences minimales et maximales du CPU "
"*\n"
#: utils/cpufreq-info.c:488
@@ -469,7 +469,7 @@ msgid ""
" interface in 2.4. and early 2.6. kernels\n"
msgstr ""
" -o, --proc Affiche les informations en utilisant l'interface\n"
-" fournie par /proc/cpufreq, présente dans les "
+" fournie par /proc/cpufreq, présente dans les "
"versions\n"
" 2.4 et les anciennes versions 2.6 du noyau\n"
@@ -485,7 +485,7 @@ msgstr ""
#: utils/cpufreq-info.c:492 utils/cpuidle-info.c:152
#, c-format
msgid " -h, --help Prints out this screen\n"
-msgstr " -h, --help affiche l'aide-mémoire\n"
+msgstr " -h, --help affiche l'aide-mémoire\n"
#: utils/cpufreq-info.c:495
#, c-format
@@ -493,8 +493,8 @@ msgid ""
"If no argument or only the -c, --cpu parameter is given, debug output about\n"
"cpufreq is printed which is useful e.g. for reporting bugs.\n"
msgstr ""
-"Par défaut, les informations de déboguage seront affichées si aucun\n"
-"argument, ou bien si seulement l'argument -c (--cpu) est donné, afin de\n"
+"Par défaut, les informations de déboguage seront affichées si aucun\n"
+"argument, ou bien si seulement l'argument -c (--cpu) est donné, afin de\n"
"faciliter les rapports de bogues par exemple\n"
#: utils/cpufreq-info.c:497
@@ -517,8 +517,8 @@ msgid ""
"You can't specify more than one --cpu parameter and/or\n"
"more than one output-specific argument\n"
msgstr ""
-"On ne peut indiquer plus d'un paramètre --cpu, tout comme l'on ne peut\n"
-"spécifier plus d'un argument de formatage\n"
+"On ne peut indiquer plus d'un paramètre --cpu, tout comme l'on ne peut\n"
+"spécifier plus d'un argument de formatage\n"
#: utils/cpufreq-info.c:600 utils/cpufreq-set.c:82 utils/cpupower-set.c:42
#: utils/cpupower-info.c:42 utils/cpuidle-info.c:213
@@ -529,7 +529,7 @@ msgstr "option invalide\n"
#: utils/cpufreq-info.c:617
#, c-format
msgid "couldn't analyze CPU %d as it doesn't seem to be present\n"
-msgstr "analyse du CPU %d impossible puisqu'il ne semble pas être présent\n"
+msgstr "analyse du CPU %d impossible puisqu'il ne semble pas être présent\n"
#: utils/cpufreq-info.c:620 utils/cpupower-info.c:142
#, c-format
@@ -547,8 +547,8 @@ msgid ""
" -d FREQ, --min FREQ new minimum CPU frequency the governor may "
"select\n"
msgstr ""
-" -d FREQ, --min FREQ nouvelle fréquence minimale du CPU à utiliser\n"
-" par le régulateur\n"
+" -d FREQ, --min FREQ nouvelle fréquence minimale du CPU à utiliser\n"
+" par le régulateur\n"
#: utils/cpufreq-set.c:28
#, c-format
@@ -556,13 +556,13 @@ msgid ""
" -u FREQ, --max FREQ new maximum CPU frequency the governor may "
"select\n"
msgstr ""
-" -u FREQ, --max FREQ nouvelle fréquence maximale du CPU à utiliser\n"
-" par le régulateur\n"
+" -u FREQ, --max FREQ nouvelle fréquence maximale du CPU à utiliser\n"
+" par le régulateur\n"
#: utils/cpufreq-set.c:29
#, c-format
msgid " -g GOV, --governor GOV new cpufreq governor\n"
-msgstr " -g GOV, --governor GOV active le régulateur GOV\n"
+msgstr " -g GOV, --governor GOV active le régulateur GOV\n"
#: utils/cpufreq-set.c:30
#, c-format
@@ -570,9 +570,9 @@ msgid ""
" -f FREQ, --freq FREQ specific frequency to be set. Requires userspace\n"
" governor to be available and loaded\n"
msgstr ""
-" -f FREQ, --freq FREQ fixe la fréquence du processeur à FREQ. Il faut\n"
-" que le régulateur « userspace » soit disponible \n"
-" et activé.\n"
+" -f FREQ, --freq FREQ fixe la fréquence du processeur à FREQ. Il faut\n"
+" que le régulateur « userspace » soit disponible \n"
+" et activé.\n"
#: utils/cpufreq-set.c:32
#, c-format
@@ -582,7 +582,7 @@ msgstr ""
#: utils/cpufreq-set.c:33 utils/cpupower-set.c:28 utils/cpupower-info.c:27
#, fuzzy, c-format
msgid " -h, --help Prints out this screen\n"
-msgstr " -h, --help affiche l'aide-mémoire\n"
+msgstr " -h, --help affiche l'aide-mémoire\n"
#: utils/cpufreq-set.c:35
#, fuzzy, c-format
@@ -602,11 +602,11 @@ msgid ""
" (FREQuency in kHz =^ Hz * 0.001 =^ MHz * 1000 =^ GHz * 1000000).\n"
msgstr ""
"Remarque :\n"
-"1. Le CPU numéro 0 sera utilisé par défaut si -c (ou --cpu) est omis ;\n"
-"2. l'argument -f FREQ (ou --freq FREQ) ne peut être utilisé qu'avec --cpu ;\n"
-"3. on pourra préciser l'unité des fréquences en postfixant sans aucune "
+"1. Le CPU numéro 0 sera utilisé par défaut si -c (ou --cpu) est omis ;\n"
+"2. l'argument -f FREQ (ou --freq FREQ) ne peut être utilisé qu'avec --cpu ;\n"
+"3. on pourra préciser l'unité des fréquences en postfixant sans aucune "
"espace\n"
-" les valeurs par hz, kHz (par défaut), MHz, GHz ou THz\n"
+" les valeurs par hz, kHz (par défaut), MHz, GHz ou THz\n"
" (kHz =^ Hz * 0.001 =^ MHz * 1000 =^ GHz * 1000000).\n"
#: utils/cpufreq-set.c:57
@@ -622,21 +622,21 @@ msgid ""
"frequency\n"
" or because the userspace governor isn't loaded?\n"
msgstr ""
-"En ajustant les nouveaux paramètres, une erreur est apparue. Les sources\n"
+"En ajustant les nouveaux paramètres, une erreur est apparue. Les sources\n"
"d'erreur typique sont :\n"
-"- droit d'administration insuffisant (êtes-vous root ?) ;\n"
-"- le régulateur choisi n'est pas disponible, ou bien n'est pas disponible "
+"- droit d'administration insuffisant (êtes-vous root ?) ;\n"
+"- le régulateur choisi n'est pas disponible, ou bien n'est pas disponible "
"en\n"
" tant que module noyau ;\n"
"- la tactique n'est pas disponible ;\n"
-"- vous voulez utiliser l'option -f/--freq, mais le régulateur « userspace »\n"
-" n'est pas disponible, par exemple parce que le matériel ne le supporte\n"
-" pas, ou bien n'est tout simplement pas chargé.\n"
+"- vous voulez utiliser l'option -f/--freq, mais le régulateur « userspace »\n"
+" n'est pas disponible, par exemple parce que le matériel ne le supporte\n"
+" pas, ou bien n'est tout simplement pas chargé.\n"
#: utils/cpufreq-set.c:170
#, c-format
msgid "wrong, unknown or unhandled CPU?\n"
-msgstr "CPU inconnu ou non supporté ?\n"
+msgstr "CPU inconnu ou non supporté ?\n"
#: utils/cpufreq-set.c:302
#, c-format
@@ -653,7 +653,7 @@ msgid ""
"At least one parameter out of -f/--freq, -d/--min, -u/--max, and\n"
"-g/--governor must be passed\n"
msgstr ""
-"L'un de ces paramètres est obligatoire : -f/--freq, -d/--min, -u/--max et\n"
+"L'un de ces paramètres est obligatoire : -f/--freq, -d/--min, -u/--max et\n"
"-g/--governor\n"
#: utils/cpufreq-set.c:347
@@ -810,7 +810,7 @@ msgstr ""
#: utils/cpuidle-info.c:48
#, fuzzy, c-format
msgid "Available idle states:"
-msgstr " plage de fréquence : "
+msgstr " plage de fréquence : "
#: utils/cpuidle-info.c:71
#, c-format
@@ -911,7 +911,7 @@ msgstr "Usage : cpufreq-info [options]\n"
#: utils/cpuidle-info.c:149
#, fuzzy, c-format
msgid " -s, --silent Only show general C-state information\n"
-msgstr " -e, --debug Afficher les informations de déboguage\n"
+msgstr " -e, --debug Afficher les informations de déboguage\n"
#: utils/cpuidle-info.c:150
#, fuzzy, c-format
@@ -921,7 +921,7 @@ msgid ""
" interface in older kernels\n"
msgstr ""
" -o, --proc Affiche les informations en utilisant l'interface\n"
-" fournie par /proc/cpufreq, présente dans les "
+" fournie par /proc/cpufreq, présente dans les "
"versions\n"
" 2.4 et les anciennes versions 2.6 du noyau\n"
@@ -929,19 +929,19 @@ msgstr ""
#, fuzzy, c-format
msgid "You can't specify more than one output-specific argument\n"
msgstr ""
-"On ne peut indiquer plus d'un paramètre --cpu, tout comme l'on ne peut\n"
-"spécifier plus d'un argument de formatage\n"
+"On ne peut indiquer plus d'un paramètre --cpu, tout comme l'on ne peut\n"
+"spécifier plus d'un argument de formatage\n"
#~ msgid ""
#~ " -c CPU, --cpu CPU CPU number which information shall be determined "
#~ "about\n"
#~ msgstr ""
-#~ " -c CPU, --cpu CPU Numéro du CPU pour lequel l'information sera "
-#~ "affichée\n"
+#~ " -c CPU, --cpu CPU Numéro du CPU pour lequel l'information sera "
+#~ "affichée\n"
#~ msgid ""
#~ " -c CPU, --cpu CPU number of CPU where cpufreq settings shall be "
#~ "modified\n"
#~ msgstr ""
-#~ " -c CPU, --cpu CPU numéro du CPU à prendre en compte pour les\n"
+#~ " -c CPU, --cpu CPU numéro du CPU à prendre en compte pour les\n"
#~ " changements\n"
--
2.18.0
^ permalink raw reply related
* RE: [PATCH] net: ethernet: fs-enet: Use generic CRC32 implementation
From: David Laight @ 2018-07-24 11:22 UTC (permalink / raw)
To: 'Krzysztof Kozlowski'
Cc: Pantelis Antoniou, David S. Miller, linuxppc-dev@lists.ozlabs.org,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
Eric Biggers
In-Reply-To: <CAJKOXPdveQeg_M42v69m9vBEz2SaJE0_BZNRUqGLt4Ve+ZLYSg@mail.gmail.com>
From: Krzysztof Kozlowski
> Sent: 24 July 2018 12:12
...
> >> Not tested on hardware.
> >
> > Have you verified that the old and new functions give the
> > same result for a few mac addresses?
> > It is very easy to use the wrong bits in crc calculations
> > or generate the output in the wrong bit order.
>
> I copied the original code and new one onto a different driver and run
> this in a loop for thousands of data input (although not all possible
> MAC combinations). The output was the same. I agree however that real
> testing would be important.
Since CRC are linear you only need to check that each input
bit generates the correct output.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
^ permalink raw reply
* [PATCH] Make Surface Dock 3 work again
From: Mathias Radtke @ 2018-07-24 10:08 UTC (permalink / raw)
To: oliver, hayeswang, netdev
Hi,
since Kernel 4.10 the usage of the Surface Dock 3 is broken.
The network driver r8152 reports Tx Error -71.
The patch removes the dock from the r8152 driver and also removed it
from the cdc_ether drivers blacklist. Therefore the cdc_driver takes
over and the dock works again.
diff -uprN -X linux-vanilla/Documentation/dontdiff
linux-vanilla/drivers/net/usb/cdc_ether.c linux/drivers/net/usb/cdc_ether.c
--- linux-vanilla/drivers/net/usb/cdc_ether.c 2018-07-24
07:53:47.474426679 +0200
+++ linux/drivers/net/usb/cdc_ether.c 2018-07-24 07:55:24.268740306 +0200
@@ -807,13 +807,6 @@ static const struct usb_device_id produc
.driver_info = 0,
},
-/* Microsoft Surface 3 dock (based on Realtek RTL8153) */
-{
- USB_DEVICE_AND_INTERFACE_INFO(MICROSOFT_VENDOR_ID, 0x07c6,
USB_CLASS_COMM,
- USB_CDC_SUBCLASS_ETHERNET, USB_CDC_PROTO_NONE),
- .driver_info = 0,
-},
-
/* TP-LINK UE300 USB 3.0 Ethernet Adapters (based on Realtek
RTL8153) */
{
USB_DEVICE_AND_INTERFACE_INFO(TPLINK_VENDOR_ID, 0x0601,
USB_CLASS_COMM,
diff -uprN -X linux-vanilla/Documentation/dontdiff
linux-vanilla/drivers/net/usb/r8152.c linux/drivers/net/usb/r8152.c
--- linux-vanilla/drivers/net/usb/r8152.c 2018-07-24
07:53:47.494426331 +0200
+++ linux/drivers/net/usb/r8152.c 2018-07-24 07:55:05.705064110 +0200
@@ -5323,7 +5323,6 @@ static const struct usb_device_id rtl815
{REALTEK_USB_DEVICE(VENDOR_ID_REALTEK, 0x8152)},
{REALTEK_USB_DEVICE(VENDOR_ID_REALTEK, 0x8153)},
{REALTEK_USB_DEVICE(VENDOR_ID_MICROSOFT, 0x07ab)},
- {REALTEK_USB_DEVICE(VENDOR_ID_MICROSOFT, 0x07c6)},
{REALTEK_USB_DEVICE(VENDOR_ID_SAMSUNG, 0xa101)},
{REALTEK_USB_DEVICE(VENDOR_ID_LENOVO, 0x304f)},
{REALTEK_USB_DEVICE(VENDOR_ID_LENOVO, 0x3062)},
Cheers
--
Mathias Radtke
---
http://uib.de/de/support-schulung/schulung/
uib gmbh
Bonifaziusplatz 1B
55118 Mainz
E-Mail: m.radtke@uib.de
Internet: www.uib.de
Geschäftsführer: dr. detlef oertel & erol ueluekmen
Handelsregister: Amtsgericht Mainz HRB 6942
^ permalink raw reply
* Re: [net-next 10/16] net/mlx5: Support PCIe buffer congestion handling via Devlink
From: Eran Ben Elisha @ 2018-07-24 10:31 UTC (permalink / raw)
To: Jakub Kicinski, Saeed Mahameed, Jiri Pirko
Cc: David S. Miller, netdev@vger.kernel.org
In-Reply-To: <20180718184947.6e472ee4@cakuba.netronome.com>
On 7/19/2018 4:49 AM, Jakub Kicinski wrote:
> On Wed, 18 Jul 2018 18:01:01 -0700, Saeed Mahameed wrote:
>> +static const struct devlink_param mlx5_devlink_params[] = {
>> + DEVLINK_PARAM_DRIVER(MLX5_DEVLINK_PARAM_ID_CONGESTION_ACTION,
>> + "congestion_action",
>> + DEVLINK_PARAM_TYPE_U8,
>> + BIT(DEVLINK_PARAM_CMODE_RUNTIME),
>> + mlx5_devlink_get_congestion_action,
>> + mlx5_devlink_set_congestion_action, NULL),
>> + DEVLINK_PARAM_DRIVER(MLX5_DEVLINK_PARAM_ID_CONGESTION_MODE,
>> + "congestion_mode",
>> + DEVLINK_PARAM_TYPE_U8,
>> + BIT(DEVLINK_PARAM_CMODE_RUNTIME),
>> + mlx5_devlink_get_congestion_mode,
>> + mlx5_devlink_set_congestion_mode, NULL),
>> +};
>
> The devlink params haven't been upstream even for a full cycle and
> already you guys are starting to use them to configure standard
> features like queuing.
We developed the devlink params in order to support non-standard
configuration only. And for non-standard, there are generic and vendor
specific options.
The queuing model is a standard. However here we are configuring the
outbound PCIe buffers on the receive path from NIC port toward the
host(s) in Single / MultiHost environment.
(You can see the driver processing based on this param as part of the RX
patch for the marked option here https://patchwork.ozlabs.org/patch/945998/)
>
> I know your HW is not capable of doing full RED offload, it's a
> snowflake.
The algorithm which is applied here for the drop option is not the core
of this feature.
> You tell us you're doing custom DCB configuration hacks on
> one side (previous argument we had) and custom devlink parameter
> configuration hacks on PCIe.
>
> Perhaps the idea that we're trying to use the existing Linux APIs for
> HW configuration only applies to forwarding behaviour.
Hopefully I explained above well why it is not related.
^ permalink raw reply
* [PATCH] wcn36xx: Use kmemdup instead of duplicating it in wcn36xx_smd_process_ptt_msg_rsp
From: YueHaibing @ 2018-07-24 11:43 UTC (permalink / raw)
To: davem, kvalo; +Cc: linux-kernel, netdev, linux-wireless, wcn36xx, YueHaibing
Replace calls to kmalloc followed by a memcpy with a direct call to
kmemdup.
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
drivers/net/wireless/ath/wcn36xx/smd.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/ath/wcn36xx/smd.c b/drivers/net/wireless/ath/wcn36xx/smd.c
index b4dadf7..70c97ec 100644
--- a/drivers/net/wireless/ath/wcn36xx/smd.c
+++ b/drivers/net/wireless/ath/wcn36xx/smd.c
@@ -792,10 +792,10 @@ static int wcn36xx_smd_process_ptt_msg_rsp(void *buf, size_t len,
rsp->header.len - sizeof(rsp->ptt_msg_resp_status));
if (rsp->header.len > 0) {
- *p_ptt_rsp_msg = kmalloc(rsp->header.len, GFP_ATOMIC);
+ *p_ptt_rsp_msg = kmemdup(rsp->ptt_msg, rsp->header.len,
+ GFP_ATOMIC);
if (!*p_ptt_rsp_msg)
return -ENOMEM;
- memcpy(*p_ptt_rsp_msg, rsp->ptt_msg, rsp->header.len);
}
return ret;
}
--
2.7.0
^ permalink raw reply related
* [PATCH] mwifiex: Fix skipped vendor specific IEs
From: roman.stratiienko-hExfYMNmJl/Cnp4W7fqMDg @ 2018-07-24 11:47 UTC (permalink / raw)
To: akarwar-eYqpPyKDWXRBDgjK7y7TUQ
Cc: nishants-eYqpPyKDWXRBDgjK7y7TUQ, kvalo-sgV2jX0FEOL9JmXXK+q4OQ,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
sergei.shtylyov-M4DtvfQ/ZS1MRgGoP+s0PdBPR1lH4CV8,
Roman Stratiienko
From: Roman Stratiienko <roman.stratiienko-hExfYMNmJl/Cnp4W7fqMDg@public.gmane.org>
Mwifiex firmware inserts only Microsoft information element
Allow other vendor specific IEs to pass from userspace
Signed-off-by: Roman Stratiienko <roman.stratiienko-hExfYMNmJl/Cnp4W7fqMDg@public.gmane.org>
---
drivers/net/wireless/marvell/mwifiex/ie.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/marvell/mwifiex/ie.c b/drivers/net/wireless/marvell/mwifiex/ie.c
index b10baac..75cbd60 100644
--- a/drivers/net/wireless/marvell/mwifiex/ie.c
+++ b/drivers/net/wireless/marvell/mwifiex/ie.c
@@ -355,8 +355,14 @@ static int mwifiex_uap_parse_tail_ies(struct mwifiex_private *priv,
case WLAN_EID_HT_OPERATION:
case WLAN_EID_VHT_CAPABILITY:
case WLAN_EID_VHT_OPERATION:
- case WLAN_EID_VENDOR_SPECIFIC:
break;
+ case WLAN_EID_VENDOR_SPECIFIC:
+ /* Skip only Microsoft WMM IE */
+ if (cfg80211_find_vendor_ie(WLAN_OUI_MICROSOFT,
+ WLAN_OUI_TYPE_MICROSOFT_WMM,
+ (const u8 *)hdr,
+ hdr->len + sizeof(struct ieee_types_header)))
+ break;
default:
memcpy(gen_ie->ie_buffer + ie_len, hdr,
hdr->len + sizeof(struct ieee_types_header));
--
2.7.4
^ permalink raw reply related
* Re: [PATCH net-next] virtio_net: force_napi_tx module param.
From: Michael S. Tsirkin @ 2018-07-24 10:42 UTC (permalink / raw)
To: Caleb Raitto; +Cc: jasowang, davem, netdev, Caleb Raitto
In-Reply-To: <20180723231119.142904-1-caleb.raitto@gmail.com>
On Mon, Jul 23, 2018 at 04:11:19PM -0700, Caleb Raitto wrote:
> From: Caleb Raitto <caraitto@google.com>
>
> The driver disables tx napi if it's not certain that completions will
> be processed affine with tx service.
>
> Its heuristic doesn't account for some scenarios where it is, such as
> when the queue pair count matches the core but not hyperthread count.
>
> Allow userspace to override the heuristic. This is an alternative
> solution to that in the linked patch. That added more logic in the
> kernel for these cases, but the agreement was that this was better left
> to user control.
>
> Do not expand the existing napi_tx variable to a ternary value,
> because doing so can break user applications that expect
> boolean ('Y'/'N') instead of integer output. Add a new param instead.
>
> Link: https://patchwork.ozlabs.org/patch/725249/
> Acked-by: Willem de Bruijn <willemb@google.com>
> Acked-by: Jon Olson <jonolson@google.com>
> Signed-off-by: Caleb Raitto <caraitto@google.com>
Is there a reason the same rule should apply to all devices?
If not shouldn't this be an ethtool option?
> ---
> drivers/net/virtio_net.c | 7 ++++---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> index 2ff08bc103a9..d9aca4e90d6b 100644
> --- a/drivers/net/virtio_net.c
> +++ b/drivers/net/virtio_net.c
> @@ -39,10 +39,11 @@
> static int napi_weight = NAPI_POLL_WEIGHT;
> module_param(napi_weight, int, 0444);
>
> -static bool csum = true, gso = true, napi_tx;
> +static bool csum = true, gso = true, napi_tx, force_napi_tx;
> module_param(csum, bool, 0444);
> module_param(gso, bool, 0444);
> module_param(napi_tx, bool, 0644);
> +module_param(force_napi_tx, bool, 0644);
>
> /* FIXME: MTU in config. */
> #define GOOD_PACKET_LEN (ETH_HLEN + VLAN_HLEN + ETH_DATA_LEN)
> @@ -1201,7 +1202,7 @@ static void virtnet_napi_tx_enable(struct virtnet_info *vi,
> /* Tx napi touches cachelines on the cpu handling tx interrupts. Only
> * enable the feature if this is likely affine with the transmit path.
> */
> - if (!vi->affinity_hint_set) {
> + if (!vi->affinity_hint_set && !force_napi_tx) {
> napi->weight = 0;
> return;
> }
> @@ -2646,7 +2647,7 @@ static int virtnet_alloc_queues(struct virtnet_info *vi)
> netif_napi_add(vi->dev, &vi->rq[i].napi, virtnet_poll,
> napi_weight);
> netif_tx_napi_add(vi->dev, &vi->sq[i].napi, virtnet_poll_tx,
> - napi_tx ? napi_weight : 0);
> + (napi_tx || force_napi_tx) ? napi_weight : 0);
>
> sg_init_table(vi->rq[i].sg, ARRAY_SIZE(vi->rq[i].sg));
> ewma_pkt_len_init(&vi->rq[i].mrg_avg_pkt_len);
> --
> 2.18.0.233.g985f88cf7e-goog
^ permalink raw reply
* [PATCH] wcn36xx: use dma_zalloc_coherent instead of allocator/memset
From: YueHaibing @ 2018-07-24 11:52 UTC (permalink / raw)
To: davem, kvalo; +Cc: linux-kernel, netdev, linux-wireless, wcn36xx, YueHaibing
Use dma_zalloc_coherent instead of dma_alloc_coherent
followed by memset 0.
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
drivers/net/wireless/ath/wcn36xx/dxe.c | 19 +++++++++----------
1 file changed, 9 insertions(+), 10 deletions(-)
diff --git a/drivers/net/wireless/ath/wcn36xx/dxe.c b/drivers/net/wireless/ath/wcn36xx/dxe.c
index 06cfe8d..5ab3e31 100644
--- a/drivers/net/wireless/ath/wcn36xx/dxe.c
+++ b/drivers/net/wireless/ath/wcn36xx/dxe.c
@@ -174,13 +174,12 @@ static int wcn36xx_dxe_init_descs(struct device *dev, struct wcn36xx_dxe_ch *wcn
int i;
size = wcn_ch->desc_num * sizeof(struct wcn36xx_dxe_desc);
- wcn_ch->cpu_addr = dma_alloc_coherent(dev, size, &wcn_ch->dma_addr,
- GFP_KERNEL);
+ wcn_ch->cpu_addr = dma_zalloc_coherent(dev, size,
+ &wcn_ch->dma_addr,
+ GFP_KERNEL);
if (!wcn_ch->cpu_addr)
return -ENOMEM;
- memset(wcn_ch->cpu_addr, 0, size);
-
cur_dxe = (struct wcn36xx_dxe_desc *)wcn_ch->cpu_addr;
cur_ctl = wcn_ch->head_blk_ctl;
@@ -628,13 +627,13 @@ int wcn36xx_dxe_allocate_mem_pools(struct wcn36xx *wcn)
16 - (WCN36XX_BD_CHUNK_SIZE % 8);
s = wcn->mgmt_mem_pool.chunk_size * WCN36XX_DXE_CH_DESC_NUMB_TX_H;
- cpu_addr = dma_alloc_coherent(wcn->dev, s, &wcn->mgmt_mem_pool.phy_addr,
- GFP_KERNEL);
+ cpu_addr = dma_zalloc_coherent(wcn->dev, s,
+ &wcn->mgmt_mem_pool.phy_addr,
+ GFP_KERNEL);
if (!cpu_addr)
goto out_err;
wcn->mgmt_mem_pool.virt_addr = cpu_addr;
- memset(cpu_addr, 0, s);
/* Allocate BD headers for DATA frames */
@@ -643,13 +642,13 @@ int wcn36xx_dxe_allocate_mem_pools(struct wcn36xx *wcn)
16 - (WCN36XX_BD_CHUNK_SIZE % 8);
s = wcn->data_mem_pool.chunk_size * WCN36XX_DXE_CH_DESC_NUMB_TX_L;
- cpu_addr = dma_alloc_coherent(wcn->dev, s, &wcn->data_mem_pool.phy_addr,
- GFP_KERNEL);
+ cpu_addr = dma_zalloc_coherent(wcn->dev, s,
+ &wcn->data_mem_pool.phy_addr,
+ GFP_KERNEL);
if (!cpu_addr)
goto out_err;
wcn->data_mem_pool.virt_addr = cpu_addr;
- memset(cpu_addr, 0, s);
return 0;
--
2.7.0
^ permalink raw reply related
* [PATCH net-next] netlink: do not store start function in netlink_cb
From: Florian Westphal @ 2018-07-24 10:47 UTC (permalink / raw)
To: netdev; +Cc: Florian Westphal
->start() is called once when dump is being initialized, there is no
need to store it in netlink_cb.
Signed-off-by: Florian Westphal <fw@strlen.de>
---
include/linux/netlink.h | 1 -
net/netlink/af_netlink.c | 5 ++---
2 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/include/linux/netlink.h b/include/linux/netlink.h
index f3075d6c7e82..71f121b66ca8 100644
--- a/include/linux/netlink.h
+++ b/include/linux/netlink.h
@@ -170,7 +170,6 @@ netlink_skb_clone(struct sk_buff *skb, gfp_t gfp_mask)
struct netlink_callback {
struct sk_buff *skb;
const struct nlmsghdr *nlh;
- int (*start)(struct netlink_callback *);
int (*dump)(struct sk_buff * skb,
struct netlink_callback *cb);
int (*done)(struct netlink_callback *cb);
diff --git a/net/netlink/af_netlink.c b/net/netlink/af_netlink.c
index 393573a99a5a..f6ac7693d2cc 100644
--- a/net/netlink/af_netlink.c
+++ b/net/netlink/af_netlink.c
@@ -2300,7 +2300,6 @@ int __netlink_dump_start(struct sock *ssk, struct sk_buff *skb,
cb = &nlk->cb;
memset(cb, 0, sizeof(*cb));
- cb->start = control->start;
cb->dump = control->dump;
cb->done = control->done;
cb->nlh = nlh;
@@ -2309,8 +2308,8 @@ int __netlink_dump_start(struct sock *ssk, struct sk_buff *skb,
cb->min_dump_alloc = control->min_dump_alloc;
cb->skb = skb;
- if (cb->start) {
- ret = cb->start(cb);
+ if (control->start) {
+ ret = control->start(cb);
if (ret)
goto error_put;
}
--
2.16.4
^ permalink raw reply related
* [PATCH net-next v2] net: remove redundant input checks in SIOCSIFTXQLEN case of dev_ifsioc
From: Tariq Toukan @ 2018-07-24 10:53 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, Eran Ben Elisha, Tariq Toukan, Cong Wang
The cited patch added a call to dev_change_tx_queue_len in
SIOCSIFTXQLEN case.
This obsoletes the new len comparison check done before the function call.
Remove it here.
For the desicion of keep/remove the negative value check, we examine the
range check in dev_change_tx_queue_len.
On 64-bit we will fail with -ERANGE. The 32-bit int ifr_qlen will be sign
extended to 64-bits when it is passed into dev_change_tx_queue_len(). And
then for negative values this test triggers:
if (new_len != (unsigned int)new_len)
return -ERANGE;
because:
if (0xffffffffWHATEVER != 0x00000000WHATEVER)
On 32-bit the signed value will be accepted, changing behavior.
Therefore, the negative value check is kept.
Fixes: 3f76df198288 ("net: use dev_change_tx_queue_len() for SIOCSIFTXQLEN")
Signed-off-by: Tariq Toukan <tariqt@mellanox.com>
Reviewed-by: Eran Ben Elisha <eranbe@mellanox.com>
Cc: Cong Wang <xiyou.wangcong@gmail.com>
---
net/core/dev_ioctl.c | 7 +------
1 file changed, 1 insertion(+), 6 deletions(-)
v1 -> v2:
* Retained negative value check, per comments from Cong and Dave.
* Updated commit message accordingly.
diff --git a/net/core/dev_ioctl.c b/net/core/dev_ioctl.c
index 50537ff961a7..90e8aa36881e 100644
--- a/net/core/dev_ioctl.c
+++ b/net/core/dev_ioctl.c
@@ -284,12 +284,7 @@ static int dev_ifsioc(struct net *net, struct ifreq *ifr, unsigned int cmd)
case SIOCSIFTXQLEN:
if (ifr->ifr_qlen < 0)
return -EINVAL;
- if (dev->tx_queue_len ^ ifr->ifr_qlen) {
- err = dev_change_tx_queue_len(dev, ifr->ifr_qlen);
- if (err)
- return err;
- }
- return 0;
+ return dev_change_tx_queue_len(dev, ifr->ifr_qlen);
case SIOCSIFNAME:
ifr->ifr_newname[IFNAMSIZ-1] = '\0';
--
1.8.3.1
^ permalink raw reply related
* [PATCH net-next 3/3] net/mlx5e: Offload TC matching on tos/ttl for ip tunnels
From: Or Gerlitz @ 2018-07-24 10:59 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, Saeed Mahameed, Or Gerlitz
In-Reply-To: <1532429975-6490-1-git-send-email-ogerlitz@mellanox.com>
Enable offloading of TC matching on tos/ttl for ipv4/6 tunnels.
Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
Reviewed-by: Roi Dayan <roid@mellanox.com>
---
drivers/net/ethernet/mellanox/mlx5/core/en_tc.c | 23 ++++++++++++++++++++++-
1 files changed, 22 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c b/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c
index de23758..bdec95d 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c
@@ -1207,6 +1207,26 @@ static int parse_tunnel_attr(struct mlx5e_priv *priv,
MLX5_SET(fte_match_set_lyr_2_4, headers_v, ethertype, ETH_P_IPV6);
}
+ if (dissector_uses_key(f->dissector, FLOW_DISSECTOR_KEY_ENC_IP)) {
+ struct flow_dissector_key_ip *key =
+ skb_flow_dissector_target(f->dissector,
+ FLOW_DISSECTOR_KEY_ENC_IP,
+ f->key);
+ struct flow_dissector_key_ip *mask =
+ skb_flow_dissector_target(f->dissector,
+ FLOW_DISSECTOR_KEY_ENC_IP,
+ f->mask);
+
+ MLX5_SET(fte_match_set_lyr_2_4, headers_c, ip_ecn, mask->tos & 0x3);
+ MLX5_SET(fte_match_set_lyr_2_4, headers_v, ip_ecn, key->tos & 0x3);
+
+ MLX5_SET(fte_match_set_lyr_2_4, headers_c, ip_dscp, mask->tos >> 2);
+ MLX5_SET(fte_match_set_lyr_2_4, headers_v, ip_dscp, key->tos >> 2);
+
+ MLX5_SET(fte_match_set_lyr_2_4, headers_c, ttl_hoplimit, mask->ttl);
+ MLX5_SET(fte_match_set_lyr_2_4, headers_v, ttl_hoplimit, key->ttl);
+ }
+
/* Enforce DMAC when offloading incoming tunneled flows.
* Flow counters require a match on the DMAC.
*/
@@ -1255,7 +1275,8 @@ static int __parse_cls_flower(struct mlx5e_priv *priv,
BIT(FLOW_DISSECTOR_KEY_ENC_PORTS) |
BIT(FLOW_DISSECTOR_KEY_ENC_CONTROL) |
BIT(FLOW_DISSECTOR_KEY_TCP) |
- BIT(FLOW_DISSECTOR_KEY_IP))) {
+ BIT(FLOW_DISSECTOR_KEY_IP) |
+ BIT(FLOW_DISSECTOR_KEY_ENC_IP))) {
netdev_warn(priv->netdev, "Unsupported key used: 0x%x\n",
f->dissector->used_keys);
return -EOPNOTSUPP;
--
1.7.1
^ permalink raw reply related
* [PATCH net-next 2/3] net/mlx5e: Support setup of tos and ttl for tunnel key TC action offload
From: Or Gerlitz @ 2018-07-24 10:59 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, Saeed Mahameed, Or Gerlitz
In-Reply-To: <1532429975-6490-1-git-send-email-ogerlitz@mellanox.com>
Use the values provided by user-space for the encapsulation headers.
Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
Reviewed-by: Roi Dayan <roid@mellanox.com>
---
drivers/net/ethernet/mellanox/mlx5/core/en_tc.c | 21 ++++++++++++---------
1 files changed, 12 insertions(+), 9 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c b/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c
index d00f8f8..de23758 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c
@@ -2215,7 +2215,7 @@ static int mlx5e_route_lookup_ipv6(struct mlx5e_priv *priv,
static void gen_vxlan_header_ipv4(struct net_device *out_dev,
char buf[], int encap_size,
unsigned char h_dest[ETH_ALEN],
- u8 ttl,
+ u8 tos, u8 ttl,
__be32 daddr,
__be32 saddr,
__be16 udp_dst_port,
@@ -2235,6 +2235,7 @@ static void gen_vxlan_header_ipv4(struct net_device *out_dev,
ip->daddr = daddr;
ip->saddr = saddr;
+ ip->tos = tos;
ip->ttl = ttl;
ip->protocol = IPPROTO_UDP;
ip->version = 0x4;
@@ -2248,7 +2249,7 @@ static void gen_vxlan_header_ipv4(struct net_device *out_dev,
static void gen_vxlan_header_ipv6(struct net_device *out_dev,
char buf[], int encap_size,
unsigned char h_dest[ETH_ALEN],
- u8 ttl,
+ u8 tos, u8 ttl,
struct in6_addr *daddr,
struct in6_addr *saddr,
__be16 udp_dst_port,
@@ -2265,7 +2266,7 @@ static void gen_vxlan_header_ipv6(struct net_device *out_dev,
ether_addr_copy(eth->h_source, out_dev->dev_addr);
eth->h_proto = htons(ETH_P_IPV6);
- ip6_flow_hdr(ip6h, 0, 0);
+ ip6_flow_hdr(ip6h, tos, 0);
/* the HW fills up ipv6 payload len */
ip6h->nexthdr = IPPROTO_UDP;
ip6h->hop_limit = ttl;
@@ -2287,8 +2288,8 @@ static int mlx5e_create_encap_header_ipv4(struct mlx5e_priv *priv,
struct net_device *out_dev;
struct neighbour *n = NULL;
struct flowi4 fl4 = {};
+ u8 nud_state, tos, ttl;
char *encap_header;
- u8 nud_state, ttl;
int err;
if (max_encap_size < ipv4_encap_size) {
@@ -2311,7 +2312,8 @@ static int mlx5e_create_encap_header_ipv4(struct mlx5e_priv *priv,
goto free_encap;
}
- ttl = 0;
+ tos = tun_key->tos;
+ ttl = tun_key->ttl;
fl4.flowi4_tos = tun_key->tos;
fl4.daddr = tun_key->u.ipv4.dst;
@@ -2347,7 +2349,7 @@ static int mlx5e_create_encap_header_ipv4(struct mlx5e_priv *priv,
switch (e->tunnel_type) {
case MLX5_HEADER_TYPE_VXLAN:
gen_vxlan_header_ipv4(out_dev, encap_header,
- ipv4_encap_size, e->h_dest, ttl,
+ ipv4_encap_size, e->h_dest, tos, ttl,
fl4.daddr,
fl4.saddr, tun_key->tp_dst,
tunnel_id_to_key32(tun_key->tun_id));
@@ -2395,8 +2397,8 @@ static int mlx5e_create_encap_header_ipv6(struct mlx5e_priv *priv,
struct net_device *out_dev;
struct neighbour *n = NULL;
struct flowi6 fl6 = {};
+ u8 nud_state, tos, ttl;
char *encap_header;
- u8 ttl, nud_state;
int err;
if (max_encap_size < ipv6_encap_size) {
@@ -2419,7 +2421,8 @@ static int mlx5e_create_encap_header_ipv6(struct mlx5e_priv *priv,
goto free_encap;
}
- ttl = 0;
+ tos = tun_key->tos;
+ ttl = tun_key->ttl;
fl6.flowlabel = ip6_make_flowinfo(RT_TOS(tun_key->tos), tun_key->label);
fl6.daddr = tun_key->u.ipv6.dst;
@@ -2455,7 +2458,7 @@ static int mlx5e_create_encap_header_ipv6(struct mlx5e_priv *priv,
switch (e->tunnel_type) {
case MLX5_HEADER_TYPE_VXLAN:
gen_vxlan_header_ipv6(out_dev, encap_header,
- ipv6_encap_size, e->h_dest, ttl,
+ ipv6_encap_size, e->h_dest, tos, ttl,
&fl6.daddr,
&fl6.saddr, tun_key->tp_dst,
tunnel_id_to_key32(tun_key->tun_id));
--
1.7.1
^ permalink raw reply related
* [PATCH net-next 1/3] net/mlx5e: Use ttl from route lookup on tc encap offload only if needed
From: Or Gerlitz @ 2018-07-24 10:59 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, Saeed Mahameed, Or Gerlitz
In-Reply-To: <1532429975-6490-1-git-send-email-ogerlitz@mellanox.com>
Currnetly, the ttl for the encapsulation headers is taken from the
route lookup result. As a pre-step to allow for an offload case when
the user specifies the ttl, take it from the route lookup only if
not zero. While here, also move to use u8 instead int for the ttl.
Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
Reviewed-by: Roi Dayan <roid@mellanox.com>
---
drivers/net/ethernet/mellanox/mlx5/core/en_tc.c | 27 ++++++++++++++--------
1 files changed, 17 insertions(+), 10 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c b/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c
index b5f854f..d00f8f8 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c
@@ -2121,7 +2121,7 @@ static int mlx5e_route_lookup_ipv4(struct mlx5e_priv *priv,
struct net_device **out_dev,
struct flowi4 *fl4,
struct neighbour **out_n,
- int *out_ttl)
+ u8 *out_ttl)
{
struct mlx5_eswitch *esw = priv->mdev->priv.eswitch;
struct mlx5e_rep_priv *uplink_rpriv;
@@ -2145,7 +2145,8 @@ static int mlx5e_route_lookup_ipv4(struct mlx5e_priv *priv,
else
*out_dev = rt->dst.dev;
- *out_ttl = ip4_dst_hoplimit(&rt->dst);
+ if (!(*out_ttl))
+ *out_ttl = ip4_dst_hoplimit(&rt->dst);
n = dst_neigh_lookup(&rt->dst, &fl4->daddr);
ip_rt_put(rt);
if (!n)
@@ -2174,7 +2175,7 @@ static int mlx5e_route_lookup_ipv6(struct mlx5e_priv *priv,
struct net_device **out_dev,
struct flowi6 *fl6,
struct neighbour **out_n,
- int *out_ttl)
+ u8 *out_ttl)
{
struct neighbour *n = NULL;
struct dst_entry *dst;
@@ -2189,7 +2190,8 @@ static int mlx5e_route_lookup_ipv6(struct mlx5e_priv *priv,
if (ret < 0)
return ret;
- *out_ttl = ip6_dst_hoplimit(dst);
+ if (!(*out_ttl))
+ *out_ttl = ip6_dst_hoplimit(dst);
uplink_rpriv = mlx5_eswitch_get_uplink_priv(esw, REP_ETH);
/* if the egress device isn't on the same HW e-switch, we use the uplink */
@@ -2213,7 +2215,7 @@ static int mlx5e_route_lookup_ipv6(struct mlx5e_priv *priv,
static void gen_vxlan_header_ipv4(struct net_device *out_dev,
char buf[], int encap_size,
unsigned char h_dest[ETH_ALEN],
- int ttl,
+ u8 ttl,
__be32 daddr,
__be32 saddr,
__be16 udp_dst_port,
@@ -2246,7 +2248,7 @@ static void gen_vxlan_header_ipv4(struct net_device *out_dev,
static void gen_vxlan_header_ipv6(struct net_device *out_dev,
char buf[], int encap_size,
unsigned char h_dest[ETH_ALEN],
- int ttl,
+ u8 ttl,
struct in6_addr *daddr,
struct in6_addr *saddr,
__be16 udp_dst_port,
@@ -2286,8 +2288,8 @@ static int mlx5e_create_encap_header_ipv4(struct mlx5e_priv *priv,
struct neighbour *n = NULL;
struct flowi4 fl4 = {};
char *encap_header;
- int ttl, err;
- u8 nud_state;
+ u8 nud_state, ttl;
+ int err;
if (max_encap_size < ipv4_encap_size) {
mlx5_core_warn(priv->mdev, "encap size %d too big, max supported is %d\n",
@@ -2308,6 +2310,9 @@ static int mlx5e_create_encap_header_ipv4(struct mlx5e_priv *priv,
err = -EOPNOTSUPP;
goto free_encap;
}
+
+ ttl = 0;
+
fl4.flowi4_tos = tun_key->tos;
fl4.daddr = tun_key->u.ipv4.dst;
fl4.saddr = tun_key->u.ipv4.src;
@@ -2391,8 +2396,8 @@ static int mlx5e_create_encap_header_ipv6(struct mlx5e_priv *priv,
struct neighbour *n = NULL;
struct flowi6 fl6 = {};
char *encap_header;
- int err, ttl = 0;
- u8 nud_state;
+ u8 ttl, nud_state;
+ int err;
if (max_encap_size < ipv6_encap_size) {
mlx5_core_warn(priv->mdev, "encap size %d too big, max supported is %d\n",
@@ -2414,6 +2419,8 @@ static int mlx5e_create_encap_header_ipv6(struct mlx5e_priv *priv,
goto free_encap;
}
+ ttl = 0;
+
fl6.flowlabel = ip6_make_flowinfo(RT_TOS(tun_key->tos), tun_key->label);
fl6.daddr = tun_key->u.ipv6.dst;
fl6.saddr = tun_key->u.ipv6.src;
--
1.7.1
^ permalink raw reply related
* [PATCH net-next 0/3] net/mlx5: Offload setting/matching on tunnel tos/ttl
From: Or Gerlitz @ 2018-07-24 10:59 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, Saeed Mahameed, Or Gerlitz
This series enables mlx5 offloading of tc eswitch rules that set tos/ttl (encap) or
match on them (decap) for tunnels.
Or Gerlitz (3):
net/mlx5e: Use ttl from route lookup on tc encap offload only if needed
net/mlx5e: Support setup of tos and ttl for tunnel key TC action offload
net/mlx5e: Offload TC matching on tos/ttl for ip tunnels
drivers/net/ethernet/mellanox/mlx5/core/en_tc.c | 59 +++++++++++++++++-----
1 files changed, 45 insertions(+), 14 deletions(-)
^ permalink raw reply
* RE: [PATCH] net: ethernet: fs-enet: Use generic CRC32 implementation
From: David Laight @ 2018-07-24 11:05 UTC (permalink / raw)
To: 'Krzysztof Kozlowski', Pantelis Antoniou, David S. Miller,
linuxppc-dev@lists.ozlabs.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
Cc: Eric Biggers
In-Reply-To: <20180723162020.6221-1-krzk@kernel.org>
From: Krzysztof Kozlowski
> Sent: 23 July 2018 17:20
> Use generic kernel CRC32 implementation because it:
> 1. Should be faster (uses lookup tables),
Are you sure?
The lookup tables are unlikely to be in the data cache and
the 6 cache misses kill performance.
(Not that it particularly matters when setting up multicast hash tables).
> 2. Removes duplicated CRC generation code,
> 3. Uses well-proven algorithm instead of coding it one more time.
...
>
> Not tested on hardware.
Have you verified that the old and new functions give the
same result for a few mac addresses?
It is very easy to use the wrong bits in crc calculations
or generate the output in the wrong bit order.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
^ permalink raw reply
* Re: [PATCH] net: ethernet: fs-enet: Use generic CRC32 implementation
From: Krzysztof Kozlowski @ 2018-07-24 11:11 UTC (permalink / raw)
To: David Laight
Cc: Pantelis Antoniou, David S. Miller, linuxppc-dev@lists.ozlabs.org,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
Eric Biggers
In-Reply-To: <5ef968e1cb2a473cad97f6bfead369ca@AcuMS.aculab.com>
On 24 July 2018 at 13:05, David Laight <David.Laight@aculab.com> wrote:
> From: Krzysztof Kozlowski
>> Sent: 23 July 2018 17:20
>> Use generic kernel CRC32 implementation because it:
>> 1. Should be faster (uses lookup tables),
>
> Are you sure?
> The lookup tables are unlikely to be in the data cache and
> the 6 cache misses kill performance.
> (Not that it particularly matters when setting up multicast hash tables).
Good point, so this statement should be rather "Could be faster"... I
did not run any performance tests so this is not backed up by any
data.
I think the main benefit is rather easier code maintenance by removing
duplicated, custom code.
>> 2. Removes duplicated CRC generation code,
>> 3. Uses well-proven algorithm instead of coding it one more time.
> ...
>>
>> Not tested on hardware.
>
> Have you verified that the old and new functions give the
> same result for a few mac addresses?
> It is very easy to use the wrong bits in crc calculations
> or generate the output in the wrong bit order.
I copied the original code and new one onto a different driver and run
this in a loop for thousands of data input (although not all possible
MAC combinations). The output was the same. I agree however that real
testing would be important.
Best regards,
Krzysztof
^ 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