* Re: [PATCH v3 net-next 01/11] net: dsa: microchip: Replace license with GPL
From: Pavel Machek @ 2018-10-24 11:05 UTC (permalink / raw)
To: Tristram.Ha
Cc: Andrew Lunn, Florian Fainelli, Ruediger Schmitt, UNGLinuxDriver,
netdev
In-Reply-To: <1540261575-1889-2-git-send-email-Tristram.Ha@microchip.com>
[-- Attachment #1: Type: text/plain, Size: 1246 bytes --]
On Mon 2018-10-22 19:26:05, Tristram.Ha@microchip.com wrote:
> From: Tristram Ha <Tristram.Ha@microchip.com>
>
> Replace license with GPL.
>
> Signed-off-by: Tristram Ha <Tristram.Ha@microchip.com>
> Reviewed-by: Woojung Huh <Woojung.Huh@microchip.com>
> Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Acked-by: Pavel Machek <pavel@ucw.cz>
> @@ -1,19 +1,20 @@
> /*
> * Microchip KSZ9477 register definitions
> *
> - * Copyright (C) 2017
> + * Copyright (C) 2017-2018 Microchip Technology Inc.
> *
> - * Permission to use, copy, modify, and/or distribute this software for any
> - * purpose with or without fee is hereby granted, provided that the above
> - * copyright notice and this permission notice appear in all copies.
> + * 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 Software Foundation; either version 2
> + * of the License, or (at your option) any later version.
> *
But going to SPDX and getting rid of this legaleese would be even
better.
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply
* Re: [PATCH v3 net-next 03/11] net: dsa: microchip: Initialize mutex before use
From: Pavel Machek @ 2018-10-24 11:07 UTC (permalink / raw)
To: Tristram.Ha
Cc: Andrew Lunn, Florian Fainelli, Ruediger Schmitt,
Arkadi Sharshevsky, UNGLinuxDriver, netdev
In-Reply-To: <1540261575-1889-4-git-send-email-Tristram.Ha@microchip.com>
[-- Attachment #1: Type: text/plain, Size: 1324 bytes --]
On Mon 2018-10-22 19:26:07, Tristram.Ha@microchip.com wrote:
> From: Tristram Ha <Tristram.Ha@microchip.com>
>
> Initialize mutex before use.
>
> Signed-off-by: Tristram Ha <Tristram.Ha@microchip.com>
> ---
> drivers/net/dsa/microchip/ksz_common.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/dsa/microchip/ksz_common.c b/drivers/net/dsa/microchip/ksz_common.c
> index 8c5853e..88e8d2a 100644
> --- a/drivers/net/dsa/microchip/ksz_common.c
> +++ b/drivers/net/dsa/microchip/ksz_common.c
> @@ -1118,7 +1118,6 @@ static int ksz_switch_init(struct ksz_device *dev)
> {
> int i;
>
> - mutex_init(&dev->reg_mutex);
> mutex_init(&dev->stats_mutex);
> mutex_init(&dev->alu_mutex);
> mutex_init(&dev->vlan_mutex);
> @@ -1207,6 +1206,9 @@ int ksz_switch_register(struct ksz_device *dev)
> if (dev->pdata)
> dev->chip_id = dev->pdata->chip_id;
>
> + /* mutex is used in next function call. */
> + mutex_init(&dev->reg_mutex);
> +
> if (ksz_switch_detect(dev))
> return -EINVAL;
Actually, would it make sense to move all mutex_init's there? No harm
in doing them sooner...
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply
* [PATCH RFC] net: dsa: Make switches VLAN aware when enslaved into a bridge
From: Florian Fainelli @ 2018-10-24 19:36 UTC (permalink / raw)
To: netdev
Cc: jiri, petr, idosch, privat, Woojung.Huh, tristram.ha,
Florian Fainelli, Andrew Lunn, Vivien Didelot, David S. Miller,
open list
Commit 2ea7a679ca2a ("net: dsa: Don't add vlans when vlan filtering is
disabled") changed the behavior of DSA switches when the switch ports
are enslaved into the bridge and only pushed the VLAN configuration down
to the switch if the bridge is configured with VLAN filtering enabled.
This is unfortunately wrong, because what vlan_filtering configures is a
policy on the acceptance of VLAN tagged frames with an unknown VID.
vlan_filtering=0 means a frame with a VLAN tag that is not part of the
VLAN table should be allowed to ingress the switch, and vlan_fltering=1
would reject that frame.
Fixes: 2ea7a679ca2a ("net: dsa: Don't add vlans when vlan filtering is disabled")
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
Andrew,
I checked with Jiri and he confirmed that our interpretention of
vlan_filtering in DSA was incorrect and that it does denote whether the
switch should be doing VID ingress policy checking.
You mentioned in the commit message some problems without being too
specific about them which is why I am putting the same checks in
mv88e6xxx in order not to break your use cases. Let me know if you want
to drop that hunk entirely.
Thanks!
drivers/net/dsa/mv88e6xxx/chip.c | 7 ++++++-
net/dsa/port.c | 10 ++--------
2 files changed, 8 insertions(+), 9 deletions(-)
diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c
index 8da3d39e3218..df411e776911 100644
--- a/drivers/net/dsa/mv88e6xxx/chip.c
+++ b/drivers/net/dsa/mv88e6xxx/chip.c
@@ -1684,13 +1684,14 @@ static int _mv88e6xxx_port_vlan_add(struct mv88e6xxx_chip *chip, int port,
static void mv88e6xxx_port_vlan_add(struct dsa_switch *ds, int port,
const struct switchdev_obj_port_vlan *vlan)
{
+ struct dsa_port *dp = &ds->ports[i];
struct mv88e6xxx_chip *chip = ds->priv;
bool untagged = vlan->flags & BRIDGE_VLAN_INFO_UNTAGGED;
bool pvid = vlan->flags & BRIDGE_VLAN_INFO_PVID;
u8 member;
u16 vid;
- if (!chip->info->max_vid)
+ if (!chip->info->max_vid || br_vlan_enabled(dp->bridge_dev))
return;
if (dsa_is_dsa_port(ds, port) || dsa_is_cpu_port(ds, port))
@@ -1751,12 +1752,16 @@ static int mv88e6xxx_port_vlan_del(struct dsa_switch *ds, int port,
const struct switchdev_obj_port_vlan *vlan)
{
struct mv88e6xxx_chip *chip = ds->priv;
+ struct dsa_port *dp = &ds->ports[i];
u16 pvid, vid;
int err = 0;
if (!chip->info->max_vid)
return -EOPNOTSUPP;
+ if (br_vlan_enabled(dp->bridge_dev))
+ return 0;
+
mutex_lock(&chip->reg_lock);
err = mv88e6xxx_port_get_pvid(chip, port, &pvid);
diff --git a/net/dsa/port.c b/net/dsa/port.c
index ed0595459df1..111d7cfc8982 100644
--- a/net/dsa/port.c
+++ b/net/dsa/port.c
@@ -255,10 +255,7 @@ int dsa_port_vlan_add(struct dsa_port *dp,
if (netif_is_bridge_master(vlan->obj.orig_dev))
return -EOPNOTSUPP;
- if (br_vlan_enabled(dp->bridge_dev))
- return dsa_port_notify(dp, DSA_NOTIFIER_VLAN_ADD, &info);
-
- return 0;
+ return dsa_port_notify(dp, DSA_NOTIFIER_VLAN_ADD, &info);
}
int dsa_port_vlan_del(struct dsa_port *dp,
@@ -273,10 +270,7 @@ int dsa_port_vlan_del(struct dsa_port *dp,
if (netif_is_bridge_master(vlan->obj.orig_dev))
return -EOPNOTSUPP;
- if (br_vlan_enabled(dp->bridge_dev))
- return dsa_port_notify(dp, DSA_NOTIFIER_VLAN_DEL, &info);
-
- return 0;
+ return dsa_port_notify(dp, DSA_NOTIFIER_VLAN_DEL, &info);
}
static struct phy_device *dsa_port_get_phy_device(struct dsa_port *dp)
--
2.17.1
^ permalink raw reply related
* [PATCH v2 bpf] bpf: devmap: fix wrong interface selection in notifier_call
From: Taehee Yoo @ 2018-10-24 11:15 UTC (permalink / raw)
To: daniel, ast; +Cc: netdev, john.fastabend, ap420073
The dev_map_notification() removes interface in devmap if
unregistering interface's ifindex is same.
But only checking ifindex is not enough because other netns can have
same ifindex. so that wrong interface selection could occurred.
Hence netdev pointer comparison code is added.
v2: compare netdev pointer instead of using net_eq() (Daniel Borkmann)
v1: Initial patch
Fixes: 2ddf71e23cc2 ("net: add notifier hooks for devmap bpf map")
Signed-off-by: Taehee Yoo <ap420073@gmail.com>
---
kernel/bpf/devmap.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/kernel/bpf/devmap.c b/kernel/bpf/devmap.c
index 141710b82a6c..191b79948424 100644
--- a/kernel/bpf/devmap.c
+++ b/kernel/bpf/devmap.c
@@ -512,8 +512,7 @@ static int dev_map_notification(struct notifier_block *notifier,
struct bpf_dtab_netdev *dev, *odev;
dev = READ_ONCE(dtab->netdev_map[i]);
- if (!dev ||
- dev->dev->ifindex != netdev->ifindex)
+ if (!dev || netdev != dev->dev)
continue;
odev = cmpxchg(&dtab->netdev_map[i], dev, NULL);
if (dev == odev)
--
2.17.1
^ permalink raw reply related
* Re: [PATCH] Change judgment len position
From: Willy Tarreau @ 2018-10-24 20:09 UTC (permalink / raw)
To: Eric Dumazet
Cc: joe, wanghaifine, David Miller, Alexey Kuznetsov,
Hideaki YOSHIFUJI, netdev, LKML
In-Reply-To: <CANn89iLH=VP1i=KS5QV1x41EpQM5-o1TJfDh01Y++bMpFpfBRg@mail.gmail.com>
On Wed, Oct 24, 2018 at 10:03:08AM -0700, Eric Dumazet wrote:
> On Wed, Oct 24, 2018 at 9:54 AM Joe Perches <joe@perches.com> wrote:
>
> > I think if the point is to test for negative numbers,
> > it's clearer to do that before using min_t.and it's
> > probably clearer not to use min_t at all.
> >
>
> ...
>
> >
> > if (len > sizeof(int))
> > len = sizeof(int);
>
> It is a matter of taste really, I know some people (like me) sometimes
> mixes min() and max()
I do mix them up a lot as well because I tend to read "x=min(y,4)" as
"take y with a minimum value of 4" which in fact would be "max(y,4)".
> I would suggest that if someones wants to change the current code, a
> corresponding test
> would be added in tools/testing/selftests/net
In any case, what matters to me is that for now the only risk the existing
code represents is to overwrite up to one int of some userspace if the size
is negative, and we don't want that a wrong fix results in doing something
worse by accident like reading 2GB of kernel memory. I agree that Joe's
test with len<0 then len>sizeof(int) seems to work, but a test is probably
useful at least to ensure that the next person who passes there and wants
to turn this into min_t() again clearly catches all bad cases.
Regards,
Willy
^ permalink raw reply
* Re: [net-next 03/11] igc: Add netdev
From: Neftin, Sasha @ 2018-10-24 11:43 UTC (permalink / raw)
To: Jakub Kicinski, Jeff Kirsher
Cc: davem, netdev, nhorman, sassmann, Neftin, Sasha
In-Reply-To: <20181018101512.25588895@cakuba.netronome.com>
On 10/18/2018 20:15, Jakub Kicinski wrote:
> On Wed, 17 Oct 2018 15:23:14 -0700, Jeff Kirsher wrote:
>> +/**
>> + * igc_ioctl - I/O control method
>> + * @netdev: network interface device structure
>> + * @ifreq: frequency
>
> Is it? :)
>
Ah... Good catch. I will fix that and submit patch.
>> + * @cmd: command
>> + */
>> +static int igc_ioctl(struct net_device *netdev, struct ifreq *ifr, int cmd)
>> +{
>> + switch (cmd) {
>> + default:
>> + return -EOPNOTSUPP;
>> + }
>> +}
>
> You don't seem to be adding anything to this function in the series.
> Why add the stub?
>
Right. Still not in use. I will remove and add per demand.
Thanks for your comments.
^ permalink raw reply
* Hello My Dear Friend,
From: Mr Marc Joseph Hebert @ 2018-10-24 11:53 UTC (permalink / raw)
In-Reply-To: <643125976.71607.1540382036243.ref@mail.yahoo.com>
I am Mr Marc Joseph Hebert a I work in the Finance Risk control/Accounts Broker Unit of a prestigious bank in London. Under varying state laws in United Kingdom, financial institutions and other companies are required to turn over any funds considered "abandoned," including uncashed paychecks, forgotten bank account balances, unclaimed refunds, insurance payouts and contents of safe deposit boxes. I have the official duty to process and release unclaimed funds in the bank to government treasury.
Recently, there are multiple abandoned accounts in the bank which I have transferred some to the government treasury. Some of these funds are what I want to transfer (10.6m GBP) out of the bank to a sincere and
trustworthy person for either investment purpose or sharing between us. Can you handle this with confidentiality, sincerity and seriousness?
Please indicate your interest by simply replying to this email with your full personal details below.
(1) Your Full Name:
(2) Full Residential Address:
(3) Phone And Fax Number:
(4) Occupation:
(5) Whatsapp Number:
I anticipate your urgent response to this financial deal.
Your responds should be forwarded to my private email below.
marc.joseph.hebert1@gmail.com
Sincerely,
Mr Marc Joseph Hebert
Finance Risk control/Accounts Broker Unit.
^ permalink raw reply
* Re: [PATCH net-next 3/4] net: phy-c45: Implement reset/suspend/resume callbacks
From: Andrew Lunn @ 2018-10-24 12:03 UTC (permalink / raw)
To: Jose Abreu
Cc: Russell King - ARM Linux, Florian Fainelli, netdev,
David S. Miller, Joao Pinto
In-Reply-To: <5e65254c-04dc-6dba-eb1c-10bafadf95c5@synopsys.com>
> Since 719655a14971 ("net: phy: Replace phy driver features u32
> with link_mode bitmap"), phy_probe() calls
> ethtool_convert_link_mode_to_legacy_u32() with phydrv->features
> as argument. Since features are NULL, we will get NULL pointer
> dereference.
Hi Jose
Thanks for pointing that out. I will fix it ASAP.
Andrew
^ permalink raw reply
* Re: [PATCH v2] bpf: btf: Fix a missing-check bug
From: Martin Lau @ 2018-10-24 20:42 UTC (permalink / raw)
To: Wenwen Wang
Cc: Kangjie Lu, Alexei Starovoitov, Daniel Borkmann,
open list:BPF (Safe dynamic programs and tools),
open list:BPF (Safe dynamic programs and tools)
In-Reply-To: <20181024182239.lz7uicceihzmxabh@kafai-mbp>
On Wed, Oct 24, 2018 at 06:22:46PM +0000, Martin Lau wrote:
> On Wed, Oct 24, 2018 at 05:26:23PM +0000, Martin Lau wrote:
> > On Wed, Oct 24, 2018 at 08:00:19AM -0500, Wenwen Wang wrote:
> > > In btf_parse(), the header of the user-space btf data 'btf_data' is firstly
> > > parsed and verified through btf_parse_hdr(). In btf_parse_hdr(), the header
> > > is copied from user-space 'btf_data' to kernel-space 'btf->hdr' and then
> > > verified. If no error happens during the verification process, the whole
> > > data of 'btf_data', including the header, is then copied to 'data' in
> > > btf_parse(). It is obvious that the header is copied twice here. More
> > > importantly, no check is enforced after the second copy to make sure the
> > > headers obtained in these two copies are same. Given that 'btf_data'
> > > resides in the user space, a malicious user can race to modify the header
> > > between these two copies. By doing so, the user can inject inconsistent
> > > data, which can cause undefined behavior of the kernel and introduce
> > > potential security risk.
> btw, I am working on a patch that copies the btf_data before parsing/verifying
> the header. That should avoid this from happening but that will
> require a bit more code churns for the bpf branch.
>
It is what I have in mind:
It is not a good idea to check the BTF header before copying the
user btf_data. The verified header may not be the one actually
copied to btf->data (e.g. userspace may modify the passed in
btf_data in between). Like the one fixed in
commit 8af03d1ae2e1 ("bpf: btf: Fix a missing check bug").
This patch copies the user btf_data before parsing/verifying
the BTF header.
Fixes: 69b693f0aefa ("bpf: btf: Introduce BPF Type Format (BTF)")
Signed-off-by: Martin KaFai Lau <kafai@fb.com>
---
kernel/bpf/btf.c | 58 +++++++++++++++++++++---------------------------
1 file changed, 25 insertions(+), 33 deletions(-)
diff --git a/kernel/bpf/btf.c b/kernel/bpf/btf.c
index 378cef70341c..ee4c82667d65 100644
--- a/kernel/bpf/btf.c
+++ b/kernel/bpf/btf.c
@@ -2067,56 +2067,47 @@ static int btf_check_sec_info(struct btf_verifier_env *env,
return 0;
}
-static int btf_parse_hdr(struct btf_verifier_env *env, void __user *btf_data,
- u32 btf_data_size)
+static int btf_parse_hdr(struct btf_verifier_env *env)
{
+ u32 hdr_len, hdr_copy, btf_data_size;
const struct btf_header *hdr;
- u32 hdr_len, hdr_copy;
- /*
- * Minimal part of the "struct btf_header" that
- * contains the hdr_len.
- */
- struct btf_min_header {
- u16 magic;
- u8 version;
- u8 flags;
- u32 hdr_len;
- } __user *min_hdr;
struct btf *btf;
int err;
btf = env->btf;
- min_hdr = btf_data;
+ btf_data_size = btf->data_size;
- if (btf_data_size < sizeof(*min_hdr)) {
+ if (btf_data_size <
+ offsetof(struct btf_header, hdr_len) + sizeof(hdr->hdr_len)) {
btf_verifier_log(env, "hdr_len not found");
return -EINVAL;
}
- if (get_user(hdr_len, &min_hdr->hdr_len))
- return -EFAULT;
-
+ hdr = btf->data;
+ hdr_len = hdr->hdr_len;
if (btf_data_size < hdr_len) {
btf_verifier_log(env, "btf_header not found");
return -EINVAL;
}
- err = bpf_check_uarg_tail_zero(btf_data, sizeof(btf->hdr), hdr_len);
- if (err) {
- if (err == -E2BIG)
- btf_verifier_log(env, "Unsupported btf_header");
- return err;
+ /* Ensure the unsupported header fields are zero */
+ if (hdr_len > sizeof(btf->hdr)) {
+ u8 *expected_zero = btf->data + sizeof(btf->hdr);
+ u8 *end = btf->data + hdr_len;
+
+ for (; expected_zero < end; expected_zero++) {
+ if (*expected_zero) {
+ btf_verifier_log(env, "Unsupported btf_header");
+ return -E2BIG;
+ }
+ }
}
hdr_copy = min_t(u32, hdr_len, sizeof(btf->hdr));
- if (copy_from_user(&btf->hdr, btf_data, hdr_copy))
- return -EFAULT;
+ memcpy(&btf->hdr, btf->data, hdr_copy);
hdr = &btf->hdr;
- if (hdr->hdr_len != hdr_len)
- return -EINVAL;
-
btf_verifier_log_hdr(env, btf_data_size);
if (hdr->magic != BTF_MAGIC) {
@@ -2186,10 +2177,6 @@ static struct btf *btf_parse(void __user *btf_data, u32 btf_data_size,
}
env->btf = btf;
- err = btf_parse_hdr(env, btf_data, btf_data_size);
- if (err)
- goto errout;
-
data = kvmalloc(btf_data_size, GFP_KERNEL | __GFP_NOWARN);
if (!data) {
err = -ENOMEM;
@@ -2198,13 +2185,18 @@ static struct btf *btf_parse(void __user *btf_data, u32 btf_data_size,
btf->data = data;
btf->data_size = btf_data_size;
- btf->nohdr_data = btf->data + btf->hdr.hdr_len;
if (copy_from_user(data, btf_data, btf_data_size)) {
err = -EFAULT;
goto errout;
}
+ err = btf_parse_hdr(env);
+ if (err)
+ goto errout;
+
+ btf->nohdr_data = btf->data + btf->hdr.hdr_len;
+
err = btf_parse_str_sec(env);
if (err)
goto errout;
--
2.17.1
^ permalink raw reply related
* Re: [PATCH] Change judgment len position
From: Willy Tarreau @ 2018-10-24 20:48 UTC (permalink / raw)
To: Joe Perches; +Cc: David Miller, wanghaifine, netdev, LKML
In-Reply-To: <61d94f2a5563db4d6580c8385c3b93c8eeb3669a.camel@perches.com>
On Wed, Oct 24, 2018 at 11:28:11AM -0700, Joe Perches wrote:
> On Wed, 2018-10-24 at 10:10 -0700, David Miller wrote:
> > From: Wang Hai <wanghaifine@gmail.com>
> > Date: Wed, 24 Oct 2018 23:47:29 +0800
> >
> > > To determine whether len is less than zero, it should be put before
> > > the function min_t, because the return value of min_t is not likely
> > > to be less than zero.
> []
> > > diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
> []
> > > @@ -3301,11 +3301,11 @@ static int do_tcp_getsockopt(struct sock *sk, int level,
> > > struct net *net = sock_net(sk);
> > > int val, len;
> > >
> > > + len = min_t(unsigned int, len, sizeof(int));
> > > +
> > > if (get_user(len, optlen))
> > > return -EFAULT;
> >
> > You can't be serious?
>
> I'm not personally taken aback by this but
> there is the new Code of
> Conduct to consider.
>
> John McEnroe earned quite a bit of his
> reputation as an 'enfant terrible' via a
> similar statement.
>
> https://www.youtube.com/watch?v=t0hK1wyrrAU
>
> Perhaps a different word choice next time in
> reply to submitters of ill-considered and/or
> defective patches could be useful.
Maybe but on this one I think we're really out of the scope of the CoC.
When you read this patch from an apparent first-time contributor (no
trace in either LKML, netdev or even google), the level of assurance
in the commit message is pretty good, showing that he's not at all a
beginner, which doesn't match at all the type of error seen in the
code, which doesn't even need to be compiled to see that it will emit
a warning and not work as advertised. Moreover, the commit message is
vague enough to seem it tries to cover the patch, and doesn't even
match what's done in the patch.
When you factor in the fact that the code opens a big but very discrete
vulnerability, I tend to think that in fact we're not facing a newbie
at all but someone deliberately trying to inject a subtle backdoor into
the kernel and disguise it as a vague bug fix, possibly even hoping that
it would find its way to -stable. I would not be surprised if this e-mail
address is a throw-away anonymous address created just for this occasion.
I could totally be wrong of course, but the clues are quite heavy here
as I find it hard to argue for a series of beginner's mistakes. If this
person really exists and can explain how we ended up there, I will of
course happily retract my suspicion and apologize.
Willy
^ permalink raw reply
* [PATCH net] ipv6/ndisc: Preserve IPv6 control buffer if protocol error handlers are called
From: Stefano Brivio @ 2018-10-24 12:37 UTC (permalink / raw)
To: David S. Miller; +Cc: Hideaki YOSHIFUJI, netdev
Commit a61bbcf28a8c ("[NET]: Store skb->timestamp as offset to a base
timestamp") introduces a neighbour control buffer and zeroes it out in
ndisc_rcv(), as ndisc_recv_ns() uses it.
Commit f2776ff04722 ("[IPV6]: Fix address/interface handling in UDP and
DCCP, according to the scoping architecture.") introduces the usage of the
IPv6 control buffer in protocol error handlers (e.g. inet6_iif() in
present-day __udp6_lib_err()).
Now, with commit b94f1c0904da ("ipv6: Use icmpv6_notify() to propagate
redirect, instead of rt6_redirect()."), we call protocol error handlers
from ndisc_redirect_rcv(), after the control buffer is already stolen and
some parts are already zeroed out. This implies that inet6_iif() on this
path will always return zero.
This gives unexpected results on UDP socket lookup in __udp6_lib_err(), as
we might actually need to match sockets for a given interface.
Instead of always claiming the control buffer in ndisc_rcv(), do that only
when needed.
Fixes: b94f1c0904da ("ipv6: Use icmpv6_notify() to propagate redirect, instead of rt6_redirect().")
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
---
net/ipv6/ndisc.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/net/ipv6/ndisc.c b/net/ipv6/ndisc.c
index 0ec273997d1d..673a4a932f2a 100644
--- a/net/ipv6/ndisc.c
+++ b/net/ipv6/ndisc.c
@@ -1732,10 +1732,9 @@ int ndisc_rcv(struct sk_buff *skb)
return 0;
}
- memset(NEIGH_CB(skb), 0, sizeof(struct neighbour_cb));
-
switch (msg->icmph.icmp6_type) {
case NDISC_NEIGHBOUR_SOLICITATION:
+ memset(NEIGH_CB(skb), 0, sizeof(struct neighbour_cb));
ndisc_recv_ns(skb);
break;
--
2.19.1
^ permalink raw reply related
* Re: [PATCH net-next] net: hns3: Fix for warning uninitialized symbol hw_err_lst3
From: David Miller @ 2018-10-24 21:26 UTC (permalink / raw)
To: salil.mehta
Cc: yisen.zhuang, lipeng321, mehta.salil, dan.carpenter, netdev,
linux-kernel, linuxarm, shiju.jose
In-Reply-To: <20181024143218.4204-1-salil.mehta@huawei.com>
From: Salil Mehta <salil.mehta@huawei.com>
Date: Wed, 24 Oct 2018 15:32:18 +0100
> From: Shiju Jose <shiju.jose@huawei.com>
>
> This patch fixes the smatch warning,
>
> drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_err.c:700
> hclge_log_and_clear_ppp_error() error: uninitialized symbol
> 'hw_err_lst3'
>
> Link: https://lkml.org/lkml/2018/10/23/430
>
> Fixes: da2d072a9ea7 ("net: hns3: Add enable and process hw errors from PPP")
> Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
> Signed-off-by: Shiju Jose <shiju.jose@huawei.com>
> Signed-off-by: Salil Mehta <salil.mehta@huawei.com>
Applied.
^ permalink raw reply
* [PATCH v2] bpf: btf: Fix a missing-check bug
From: Wenwen Wang @ 2018-10-24 13:00 UTC (permalink / raw)
To: Wenwen Wang
Cc: Kangjie Lu, Alexei Starovoitov, Daniel Borkmann,
open list:BPF (Safe dynamic programs and tools),
open list:BPF (Safe dynamic programs and tools)
In btf_parse(), the header of the user-space btf data 'btf_data' is firstly
parsed and verified through btf_parse_hdr(). In btf_parse_hdr(), the header
is copied from user-space 'btf_data' to kernel-space 'btf->hdr' and then
verified. If no error happens during the verification process, the whole
data of 'btf_data', including the header, is then copied to 'data' in
btf_parse(). It is obvious that the header is copied twice here. More
importantly, no check is enforced after the second copy to make sure the
headers obtained in these two copies are same. Given that 'btf_data'
resides in the user space, a malicious user can race to modify the header
between these two copies. By doing so, the user can inject inconsistent
data, which can cause undefined behavior of the kernel and introduce
potential security risk.
To avoid the above issue, this patch copies the parsed header from
'btf->hdr' to 'data'. The remaining part in 'data' is still copied from the
user-space 'btf_data'.
Signed-off-by: Wenwen Wang <wang6495@umn.edu>
---
kernel/bpf/btf.c | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/kernel/bpf/btf.c b/kernel/bpf/btf.c
index 378cef7..b52a834a 100644
--- a/kernel/bpf/btf.c
+++ b/kernel/bpf/btf.c
@@ -2152,6 +2152,7 @@ static struct btf *btf_parse(void __user *btf_data, u32 btf_data_size,
struct btf_verifier_env *env = NULL;
struct bpf_verifier_log *log;
struct btf *btf = NULL;
+ u32 hdr_len;
u8 *data;
int err;
@@ -2200,7 +2201,15 @@ static struct btf *btf_parse(void __user *btf_data, u32 btf_data_size,
btf->data_size = btf_data_size;
btf->nohdr_data = btf->data + btf->hdr.hdr_len;
- if (copy_from_user(data, btf_data, btf_data_size)) {
+ /*
+ * The header at btf_data could be modified by a malicious user
+ * after it is parsed. So we copy the parsed header here. The
+ * remaining part is still copied from btf_data.
+ */
+ hdr_len = min_t(u32, btf->hdr.hdr_len, sizeof(btf->hdr));
+ memcpy(data, &btf->hdr, hdr_len);
+ if (copy_from_user(data + hdr_len, (u8 __user *)btf_data + hdr_len,
+ btf_data_size - hdr_len)) {
err = -EFAULT;
goto errout;
}
--
2.7.4
^ permalink raw reply related
* Resolved: Was: PROBLEM: NETDEV WATCHDOG r8169 transmit queue time out in commit 4fd48c4ac0a0578862819295222a825c97686ac7 onwards.
From: Iain Price @ 2018-10-24 13:06 UTC (permalink / raw)
To: Realtek linux nic maintainers; +Cc: netdev
In-Reply-To: <a0776d7e-c88a-6bf8-286e-d5aa429f036a@predestined.net>
Not sure if this was picked up when I originally posted it, or if this
feedback is useful but:
I noticed some rtl8169 driver changes in 4.18.15, pulled that from git
last friday and rolled it and did some bandwith intensive rsync tests
etc that would provoke the problem quite reliably before, and got no
reaction.
Gentoo released the gentoo-sources for 4.18.16 on Sunday and I switched
back to using this kernel, and this has been stable for 3 days now,
versus the problem traditionally turning up within 2-12 hours, again
suggesting the problem has gone away (or at least significantly changed).
Just to confirm that this seems to have fixed things for me, and to
thank you for all the time and effort (both on the relevant module and
more generally).
Iain
^ permalink raw reply
* Re: Attribute failed policy validation
From: Florian Westphal @ 2018-10-24 13:07 UTC (permalink / raw)
To: Marco Berizzi; +Cc: netdev, dsahern
In-Reply-To: <2054265373.707198.1540374961653@mail.libero.it>
Marco Berizzi <pupilla@libero.it> wrote:
[ CC David ]
> root@Calimero:~# tc qdisc add dev eth0 root handle 1:0 hfsc default 1
> Error: Attribute failed policy validation.
caused by:
commit 8b4c3cdd9dd8290343ce959a132d3b334062c5b9
net: sched: Add policy validation for tc attributes
Looks like TCA_OPTIONS is NLA_BINARY in hfsc case, so
we can't enforce NLA_NESTED :-(
^ permalink raw reply
* RE: [RFC] arm64: dts: lx2160aqds: Add mdio mux nodes
From: Pankaj Bansal @ 2018-10-24 13:18 UTC (permalink / raw)
To: Pankaj Bansal, Andrew Lunn, Florian Fainelli, Shawn Guo, Leo Li
Cc: netdev@vger.kernel.org,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS
In-Reply-To: <20181024183017.15142-1-pankaj.bansal@nxp.com>
Hi All,
As per the device tree ePappr https://elinux.org/images/c/cf/Power_ePAPR_APPROVED_v1.1.pdf
section 2.2.1
Each node in the device tree is named according to the following convention:
node-name@unit-address
The node-name shall start with a lower or uppercase character and should describe the general class of device.
The unit-address component of the name is specific to the bus type on which the node sits. It consists of one or more ASCII characters from the set of characters in Table 2-1. The unit-address must match the first address specified in the reg property of the node. If the node has no reg property, the @ and unit-address must be omitted and the node-name alone differentiates the node from other nodes at the same level in the tree.
I am having a hard time following this convention when defining mdio-mux nodes for LX2160AQDS.
The mdio-mux in LX2160AQDS is controlled by same register in fpga. Only some bits are different for the two buses' mux.
How to differentiate between the node names for two buses' muxes?
For now I have made their names as mdio-mux@54_f8 and mdio-mux@54_07.
The first number is register address and second number indicates the bit mask that is used to select the bits from that register for a bus.
Any better alternatives?
Regards,
Pankaj Bansal
-----Original Message-----
From: Pankaj Bansal
Sent: Wednesday, October 24, 2018 6:35 PM
To: Pankaj Bansal <pankaj.bansal@nxp.com>
Subject: [RFC] arm64: dts: lx2160aqds: Add mdio mux nodes
The two external MDIO buses used to communicate with phy devices that
are external to SOC are muxed in LX2160AQDS board.
These buses can be routed to any one of the eight IO slots on LX2160AQDS
board depending on value in fpga register 0x54.
Additionally the external MDIO1 is used to communicate to the onboard
RGMII phy devices.
The mdio1 is controlled by bits 4-7 of fpga register and mdio2 is controlled by
bits 0-3 of fpga register.
Signed-off-by: Pankaj Bansal <pankaj.bansal@nxp.com>
---
Notes:
This patch depends on below patches:
[1] https://lore.kernel.org/patchwork/project/lkml/list/?series=369563
[2] https://patchwork.kernel.org/patch/10645287/
This patch is used by below patches:
[1]https://patchwork.ozlabs.org/project/netdev/list/?series=69426&state=%2A&archive=both
.../boot/dts/freescale/fsl-lx2160a-qds.dts | 115 +++++++++++++++++
.../boot/dts/freescale/fsl-lx2160a.dtsi | 22 ++++
2 files changed, 137 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a-qds.dts
b/arch/arm64/boot/dts/freescale/fsl-lx2160a-qds.dts
index 99a22abbe725..4b282bf6c36a 100644
--- a/arch/arm64/boot/dts/freescale/fsl-lx2160a-qds.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a-qds.dts
@@ -46,6 +46,121 @@
&i2c0 {
status = "okay";
+ fpga@66 {
+ compatible = "fsl,lx2160aqds-fpga", "fsl,fpga-qixis-i2c";
+ reg = <0x66>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ mdio-mux@54_f8 {
+ mdio-parent-bus = <&emdio1>;
+ reg = <0x54>; /* BRDCFG4 */
+ mux-mask = <0xf8>; /* EMI1_MDIO */
+ #address-cells=<1>;
+ #size-cells = <0>;
+
+ mdio@0 {
+ reg = <0x00>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+ mdio@40 {
+ reg = <0x40>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+ mdio@c0 {
+ reg = <0xc0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+ mdio@c8 {
+ reg = <0xc8>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+ mdio@d0 {
+ reg = <0xd0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+ mdio@d8 {
+ reg = <0xd8>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+ mdio@e0 {
+ reg = <0xe0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+ mdio@e8 {
+ reg = <0xe8>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+ mdio@f0 {
+ reg = <0xf0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+ mdio@f8 {
+ reg = <0xf8>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+ };
+
+ mdio-mux@54_07 {
+ mdio-parent-bus = <&emdio2>;
+ reg = <0x54>; /* BRDCFG4 */
+ mux-mask = <0x07>; /* EMI2_MDIO */
+ #address-cells=<1>;
+ #size-cells = <0>;
+
+ mdio@0 {
+ reg = <0x00>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+ mdio@1 {
+ reg = <0x01>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+ mdio@2 {
+ reg = <0x02>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+ mdio@3 {
+ reg = <0x03>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+ mdio@4 {
+ reg = <0x04>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+ mdio@5 {
+ reg = <0x05>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+ mdio@6 {
+ reg = <0x06>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+ mdio@7 {
+ reg = <0x07>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+ };
+ };
+
i2c-mux@77 {
compatible = "nxp,pca9547";
reg = <0x77>;
diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
b/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
index 56f846c55812..e16b1643595b 100644
--- a/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
@@ -761,5 +761,27 @@
<GIC_SPI 209 IRQ_TYPE_LEVEL_HIGH>;
dma-coherent;
};
+
+ /* TODO: WRIOP (CCSR?) */
+ emdio1: mdio@0x8B96000 { /* WRIOP0: 0x8B8_0000, E-MDIO1: 0x1_6000 */
+ compatible = "fsl,fman-memac-mdio";
+ reg = <0x0 0x8B96000 0x0 0x1000>;
+ device_type = "mdio"; /* TODO: is this necessary? */
+ little-endian; /* force the driver in LE mode */
+
+ /* Not necessary on the QDS, but needed on the RDB*/
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ emdio2: mdio@0x8B97000 { /* WRIOP0: 0x8B8_0000, E-MDIO2: 0x1_7000 */
+ compatible = "fsl,fman-memac-mdio";
+ reg = <0x0 0x8B97000 0x0 0x1000>;
+ device_type = "mdio"; /* TODO: is this necessary? */
+ little-endian; /* force the driver in LE mode */
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
};
};
^ permalink raw reply related
* Re: [PATCH v2] bpf: btf: Fix a missing-check bug
From: Song Liu @ 2018-10-24 21:50 UTC (permalink / raw)
To: Martin KaFai Lau
Cc: wang6495, kjlu, Alexei Starovoitov, Daniel Borkmann, Networking,
open list
In-Reply-To: <20181024203548.glxgu3bqd47minmg@kafai-mbp>
On Wed, Oct 24, 2018 at 1:45 PM Martin Lau <kafai@fb.com> wrote:
>
> On Wed, Oct 24, 2018 at 06:22:46PM +0000, Martin Lau wrote:
> > On Wed, Oct 24, 2018 at 05:26:23PM +0000, Martin Lau wrote:
> > > On Wed, Oct 24, 2018 at 08:00:19AM -0500, Wenwen Wang wrote:
> > > > In btf_parse(), the header of the user-space btf data 'btf_data' is firstly
> > > > parsed and verified through btf_parse_hdr(). In btf_parse_hdr(), the header
> > > > is copied from user-space 'btf_data' to kernel-space 'btf->hdr' and then
> > > > verified. If no error happens during the verification process, the whole
> > > > data of 'btf_data', including the header, is then copied to 'data' in
> > > > btf_parse(). It is obvious that the header is copied twice here. More
> > > > importantly, no check is enforced after the second copy to make sure the
> > > > headers obtained in these two copies are same. Given that 'btf_data'
> > > > resides in the user space, a malicious user can race to modify the header
> > > > between these two copies. By doing so, the user can inject inconsistent
> > > > data, which can cause undefined behavior of the kernel and introduce
> > > > potential security risk.
> > btw, I am working on a patch that copies the btf_data before parsing/verifying
> > the header. That should avoid this from happening but that will
> > require a bit more code churns for the bpf branch.
> >
> It is what I have in mind:
>
>
> It is not a good idea to check the BTF header before copying the
> user btf_data. The verified header may not be the one actually
> copied to btf->data (e.g. userspace may modify the passed in
> btf_data in between). Like the one fixed in
> commit 8af03d1ae2e1 ("bpf: btf: Fix a missing check bug").
>
> This patch copies the user btf_data before parsing/verifying
> the BTF header.
>
> Fixes: 69b693f0aefa ("bpf: btf: Introduce BPF Type Format (BTF)")
> Signed-off-by: Martin KaFai Lau <kafai@fb.com>
Acked-by: Song Liu <songliubraving@fb.com>
> ---
> kernel/bpf/btf.c | 58 +++++++++++++++++++++---------------------------
> 1 file changed, 25 insertions(+), 33 deletions(-)
>
> diff --git a/kernel/bpf/btf.c b/kernel/bpf/btf.c
> index 378cef70341c..ee4c82667d65 100644
> --- a/kernel/bpf/btf.c
> +++ b/kernel/bpf/btf.c
> @@ -2067,56 +2067,47 @@ static int btf_check_sec_info(struct btf_verifier_env *env,
> return 0;
> }
>
> -static int btf_parse_hdr(struct btf_verifier_env *env, void __user *btf_data,
> - u32 btf_data_size)
> +static int btf_parse_hdr(struct btf_verifier_env *env)
> {
> + u32 hdr_len, hdr_copy, btf_data_size;
> const struct btf_header *hdr;
> - u32 hdr_len, hdr_copy;
> - /*
> - * Minimal part of the "struct btf_header" that
> - * contains the hdr_len.
> - */
> - struct btf_min_header {
> - u16 magic;
> - u8 version;
> - u8 flags;
> - u32 hdr_len;
> - } __user *min_hdr;
> struct btf *btf;
> int err;
>
> btf = env->btf;
> - min_hdr = btf_data;
> + btf_data_size = btf->data_size;
>
> - if (btf_data_size < sizeof(*min_hdr)) {
> + if (btf_data_size <
> + offsetof(struct btf_header, hdr_len) + sizeof(hdr->hdr_len)) {
> btf_verifier_log(env, "hdr_len not found");
> return -EINVAL;
> }
>
> - if (get_user(hdr_len, &min_hdr->hdr_len))
> - return -EFAULT;
> -
> + hdr = btf->data;
> + hdr_len = hdr->hdr_len;
> if (btf_data_size < hdr_len) {
> btf_verifier_log(env, "btf_header not found");
> return -EINVAL;
> }
>
> - err = bpf_check_uarg_tail_zero(btf_data, sizeof(btf->hdr), hdr_len);
> - if (err) {
> - if (err == -E2BIG)
> - btf_verifier_log(env, "Unsupported btf_header");
> - return err;
> + /* Ensure the unsupported header fields are zero */
> + if (hdr_len > sizeof(btf->hdr)) {
> + u8 *expected_zero = btf->data + sizeof(btf->hdr);
> + u8 *end = btf->data + hdr_len;
> +
> + for (; expected_zero < end; expected_zero++) {
> + if (*expected_zero) {
> + btf_verifier_log(env, "Unsupported btf_header");
> + return -E2BIG;
> + }
> + }
> }
>
> hdr_copy = min_t(u32, hdr_len, sizeof(btf->hdr));
> - if (copy_from_user(&btf->hdr, btf_data, hdr_copy))
> - return -EFAULT;
> + memcpy(&btf->hdr, btf->data, hdr_copy);
>
> hdr = &btf->hdr;
>
> - if (hdr->hdr_len != hdr_len)
> - return -EINVAL;
> -
> btf_verifier_log_hdr(env, btf_data_size);
>
> if (hdr->magic != BTF_MAGIC) {
> @@ -2186,10 +2177,6 @@ static struct btf *btf_parse(void __user *btf_data, u32 btf_data_size,
> }
> env->btf = btf;
>
> - err = btf_parse_hdr(env, btf_data, btf_data_size);
> - if (err)
> - goto errout;
> -
> data = kvmalloc(btf_data_size, GFP_KERNEL | __GFP_NOWARN);
> if (!data) {
> err = -ENOMEM;
> @@ -2198,13 +2185,18 @@ static struct btf *btf_parse(void __user *btf_data, u32 btf_data_size,
>
> btf->data = data;
> btf->data_size = btf_data_size;
> - btf->nohdr_data = btf->data + btf->hdr.hdr_len;
>
> if (copy_from_user(data, btf_data, btf_data_size)) {
> err = -EFAULT;
> goto errout;
> }
>
> + err = btf_parse_hdr(env);
> + if (err)
> + goto errout;
> +
> + btf->nohdr_data = btf->data + btf->hdr.hdr_len;
> +
> err = btf_parse_str_sec(env);
> if (err)
> goto errout;
> --
> 2.17.1
>
>
^ permalink raw reply
* Re: [LKP] [tcp] a337531b94: netperf.Throughput_Mbps -6.1% regression
From: Eric Dumazet @ 2018-10-24 13:27 UTC (permalink / raw)
To: kernel test robot, Yuchung Cheng
Cc: David S. Miller, Wei Wang, Neal Cardwell, Eric Dumazet,
Soheil Hassas Yeganeh, LKML, netdev, lkp
In-Reply-To: <20181024121358.GM24195@shao2-debian>
Hi Rong
This has been reported already, and we believe this has been fixed with :
commit 041a14d2671573611ffd6412bc16e2f64469f7fb
Author: Yuchung Cheng <ycheng@google.com>
Date: Mon Oct 1 15:42:32 2018 -0700
tcp: start receiver buffer autotuning sooner
Previously receiver buffer auto-tuning starts after receiving
one advertised window amount of data. After the initial receiver
buffer was raised by patch a337531b942b ("tcp: up initial rmem to
128KB and SYN rwin to around 64KB"), the reciver buffer may take
too long to start raising. To address this issue, this patch lowers
the initial bytes expected to receive roughly the expected sender's
initial window.
Fixes: a337531b942b ("tcp: up initial rmem to 128KB and SYN rwin to around 64KB")
Signed-off-by: Yuchung Cheng <ycheng@google.com>
Signed-off-by: Wei Wang <weiwan@google.com>
Signed-off-by: Neal Cardwell <ncardwell@google.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reviewed-by: Soheil Hassas Yeganeh <soheil@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Thanks
On 10/24/2018 05:13 AM, kernel test robot wrote:
> Greeting,
>
> FYI, we noticed a -6.1% regression of netperf.Throughput_Mbps due to commit:
>
>
> commit: a337531b942bd8a03e7052444d7e36972aac2d92 ("tcp: up initial rmem to 128KB and SYN rwin to around 64KB")
> https://git.kernel.org/cgit/linux/kernel/git/davem/net-next.git master
>
> in testcase: netperf
> on test machine: 16 threads Intel(R) Xeon(R) CPU D-1541 @ 2.10GHz with 8G memory
> with following parameters:
>
> ip: ipv4
> runtime: 900s
> nr_threads: 200%
> cluster: cs-localhost
> test: TCP_STREAM
> ucode: 0x7000013
> cpufreq_governor: performance
>
> test-description: Netperf is a benchmark that can be use to measure various aspect of networking performance.
> test-url: http://www.netperf.org/netperf/
>
> In addition to that, the commit also has significant impact on the following tests:
>
> +------------------+-------------------------------------------------------------------+
> | testcase: change | netperf: netperf.Throughput_Mbps -1.0% regression |
> | test machine | 16 threads Intel(R) Xeon(R) CPU D-1541 @ 2.10GHz with 8G memory |
> | test parameters | cluster=cs-localhost |
> | | cpufreq_governor=performance |
> | | ip=ipv4 |
> | | nr_threads=200% |
> | | runtime=300s |
> | | send_size=5K |
> | | test=TCP_SENDFILE |
> | | ucode=0x7000013 |
> +------------------+-------------------------------------------------------------------+
> | testcase: change | netperf: netperf.Throughput_Mbps -5.9% regression |
> | test machine | 16 threads Intel(R) Xeon(R) CPU D-1541 @ 2.10GHz with 8G memory |
> | test parameters | cluster=cs-localhost |
> | | cpufreq_governor=performance |
> | | ip=ipv4 |
> | | nr_threads=200% |
> | | runtime=900s |
> | | test=TCP_MAERTS |
> | | ucode=0x7000013 |
> +------------------+-------------------------------------------------------------------+
> | testcase: change | netperf: netperf.Throughput_Mbps -3.2% regression |
> | test machine | 4 threads Intel(R) Core(TM) i5-3317U CPU @ 1.70GHz with 4G memory |
> | test parameters | cluster=cs-localhost |
> | | cpufreq_governor=performance |
> | | ip=ipv4 |
> | | nr_threads=200% |
> | | runtime=900s |
> | | test=TCP_MAERTS |
> | | ucode=0x20 |
> +------------------+-------------------------------------------------------------------+
>
>
> Details are as below:
> -------------------------------------------------------------------------------------------------->
>
>
> To reproduce:
>
> git clone https://github.com/intel/lkp-tests.git
> cd lkp-tests
> bin/lkp install job.yaml # job file is attached in this email
> bin/lkp run job.yaml
>
> =========================================================================================
> cluster/compiler/cpufreq_governor/ip/kconfig/nr_threads/rootfs/runtime/tbox_group/test/testcase/ucode:
> cs-localhost/gcc-7/performance/ipv4/x86_64-rhel-7.2/200%/debian-x86_64-2018-04-03.cgz/900s/lkp-bdw-de1/TCP_STREAM/netperf/0x7000013
>
> commit:
> 3ff6cde846 ("hns3: Another build fix.")
> a337531b94 ("tcp: up initial rmem to 128KB and SYN rwin to around 64KB")
>
> 3ff6cde846857d45 a337531b942bd8a03e7052444d
> ---------------- --------------------------
> fail:runs %reproduction fail:runs
> | | |
> :4 50% 2:4 dmesg.WARNING:at#for_ip_interrupt_entry/0x
> %stddev %change %stddev
> \ | \
> 2497 -6.1% 2345 netperf.Throughput_Mbps
> 79924 -6.1% 75061 netperf.Throughput_total_Mbps
> 186513 +11.3% 207590 netperf.time.involuntary_context_switches
> 5.488e+08 -6.1% 5.154e+08 netperf.workload
> 1172 ± 34% -37.6% 731.75 ± 5% cpuidle.C1E.usage
> 1137 ± 34% -40.0% 682.25 ± 8% turbostat.C1E
> 2775 ± 11% +17.5% 3261 ± 9% sched_debug.cpu.nr_switches.stddev
> 0.01 ± 17% +28.2% 0.01 ± 10% sched_debug.rt_rq:/.rt_time.avg
> 0.14 ± 17% +28.2% 0.18 ± 10% sched_debug.rt_rq:/.rt_time.max
> 0.03 ± 17% +28.2% 0.04 ± 10% sched_debug.rt_rq:/.rt_time.stddev
> 66336 +0.9% 66948 proc-vmstat.nr_anon_pages
> 2.755e+08 -6.1% 2.588e+08 proc-vmstat.numa_hit
> 2.755e+08 -6.1% 2.588e+08 proc-vmstat.numa_local
> 2.197e+09 -6.1% 2.064e+09 proc-vmstat.pgalloc_normal
> 2.197e+09 -6.1% 2.064e+09 proc-vmstat.pgfree
> 5.903e+11 -7.9% 5.438e+11 perf-stat.branch-instructions
> 2.68 -0.0 2.64 perf-stat.branch-miss-rate%
> 1.582e+10 -9.2% 1.436e+10 perf-stat.branch-misses
> 6.26e+11 -4.7% 5.964e+11 perf-stat.cache-misses
> 6.26e+11 -4.7% 5.964e+11 perf-stat.cache-references
> 11.69 +8.6% 12.69 perf-stat.cpi
> 123723 +2.1% 126291 perf-stat.cpu-migrations
> 0.09 ± 2% +0.0 0.09 perf-stat.dTLB-load-miss-rate%
> 1.475e+12 -7.1% 1.37e+12 perf-stat.dTLB-loads
> 1.094e+12 -6.9% 1.018e+12 perf-stat.dTLB-stores
> 2.912e+08 ± 5% -13.0% 2.533e+08 perf-stat.iTLB-loads
> 3.019e+12 -7.9% 2.781e+12 perf-stat.instructions
> 0.09 -7.9% 0.08 perf-stat.ipc
> 5500 -1.9% 5394 perf-stat.path-length
> 0.53 ± 2% -0.2 0.38 ± 57% perf-profile.calltrace.cycles-pp.ip_output.__ip_queue_xmit.__tcp_transmit_skb.tcp_write_xmit.__tcp_push_pending_frames
> 0.63 ± 2% -0.1 0.58 ± 4% perf-profile.calltrace.cycles-pp.syscall_return_via_sysret
> 0.73 ± 3% +0.1 0.78 ± 2% perf-profile.calltrace.cycles-pp.tcp_clean_rtx_queue.tcp_ack.tcp_rcv_established.tcp_v4_do_rcv.tcp_v4_rcv
> 0.96 +0.1 1.03 perf-profile.calltrace.cycles-pp.tcp_ack.tcp_rcv_established.tcp_v4_do_rcv.tcp_v4_rcv.ip_local_deliver_finish
> 98.02 +0.1 98.13 perf-profile.calltrace.cycles-pp.entry_SYSCALL_64_after_hwframe
> 97.88 +0.1 98.00 perf-profile.calltrace.cycles-pp.do_syscall_64.entry_SYSCALL_64_after_hwframe
> 0.70 ± 3% -0.1 0.64 ± 4% perf-profile.children.cycles-pp.syscall_return_via_sysret
> 0.26 ± 5% -0.0 0.21 ± 6% perf-profile.children.cycles-pp._raw_spin_lock_bh
> 0.28 ± 5% -0.0 0.24 ± 6% perf-profile.children.cycles-pp.lock_sock_nested
> 0.46 ± 4% -0.0 0.43 ± 2% perf-profile.children.cycles-pp.nf_hook_slow
> 0.21 ± 8% -0.0 0.18 ± 5% perf-profile.children.cycles-pp.tcp_rcv_space_adjust
> 0.08 ± 5% -0.0 0.06 perf-profile.children.cycles-pp.entry_SYSCALL_64_stage2
> 0.08 ± 6% -0.0 0.06 ± 6% perf-profile.children.cycles-pp.ip_finish_output
> 0.17 ± 6% +0.0 0.20 ± 5% perf-profile.children.cycles-pp.tcp_event_new_data_sent
> 0.24 ± 4% +0.0 0.27 ± 2% perf-profile.children.cycles-pp.mod_timer
> 0.15 ± 2% +0.0 0.18 ± 2% perf-profile.children.cycles-pp.__might_sleep
> 0.80 ± 3% +0.0 0.84 ± 2% perf-profile.children.cycles-pp.tcp_clean_rtx_queue
> 0.30 ± 3% +0.1 0.36 ± 4% perf-profile.children.cycles-pp.__might_fault
> 1.61 ± 4% +0.1 1.69 perf-profile.children.cycles-pp.__release_sock
> 1.06 ± 2% +0.1 1.14 perf-profile.children.cycles-pp.tcp_ack
> 98.24 +0.1 98.36 perf-profile.children.cycles-pp.entry_SYSCALL_64_after_hwframe
> 98.09 +0.1 98.23 perf-profile.children.cycles-pp.do_syscall_64
> 70.28 +0.6 70.86 perf-profile.children.cycles-pp.copy_user_enhanced_fast_string
> 1.56 -0.1 1.48 ± 3% perf-profile.self.cycles-pp.copy_page_to_iter
> 0.70 ± 3% -0.1 0.64 ± 4% perf-profile.self.cycles-pp.syscall_return_via_sysret
> 1.37 ± 2% -0.1 1.32 ± 2% perf-profile.self.cycles-pp.__free_pages_ok
> 0.55 ± 3% -0.0 0.50 ± 3% perf-profile.self.cycles-pp.__alloc_skb
> 0.44 ± 3% -0.0 0.40 ± 5% perf-profile.self.cycles-pp.tcp_recvmsg
> 0.16 ± 9% -0.0 0.14 ± 5% perf-profile.self.cycles-pp.sock_has_perm
> 0.08 ± 6% -0.0 0.06 perf-profile.self.cycles-pp.entry_SYSCALL_64_stage2
> 0.10 ± 4% +0.0 0.12 ± 6% perf-profile.self.cycles-pp.tcp_clean_rtx_queue
> 0.14 ± 6% +0.0 0.17 ± 4% perf-profile.self.cycles-pp.__might_sleep
> 69.25 +0.5 69.77 perf-profile.self.cycles-pp.copy_user_enhanced_fast_string
>
>
>
> netperf.Throughput_Mbps
>
> 3000 +-+------------------------------------------------------------------+
> | |
> 2500 +-+..+.+..+.+..+.+..+.+..+.+..+.+..+.+.+..+.+..+.+..+.+..+.+..+.+..+.|
> O O O O O O O O O O O O O O O O O O O O O O O O O |
> | : |
> 2000 +-+ |
> |: |
> 1500 +-+ |
> |: |
> 1000 +-+ |
> |: |
> |: |
> 500 +-+ |
> | |
> 0 +-+------------------------------------------------------------------+
>
>
> netperf.Throughput_total_Mbps
>
> 90000 +-+-----------------------------------------------------------------+
> | |
> 80000 O-O..O.O..O.O..O.O.O..O.O..O.O..O.O.O..O.O..O.O..O.O.O..O.O..+.+..+.|
> 70000 +-+ |
> | : |
> 60000 +-+ |
> 50000 +-+ |
> |: |
> 40000 +-+ |
> 30000 +-+ |
> |: |
> 20000 +-+ |
> 10000 +-+ |
> | |
> 0 +-+-----------------------------------------------------------------+
>
>
> netperf.workload
>
> 6e+08 +-+-----------------------------------------------------------------+
> | +..+.+..+.+..+.+.+..+.+..+.+..+.+.+..+.+..+.+..+.+.+..+.+..+.+..+.|
> 5e+08 O-O O O O O O O O O O O O O O O O O O O O O O O O |
> | : |
> | : |
> 4e+08 +-+ |
> |: |
> 3e+08 +-+ |
> |: |
> 2e+08 +-+ |
> |: |
> | |
> 1e+08 +-+ |
> | |
> 0 +-+-----------------------------------------------------------------+
>
>
> [*] bisect-good sample
> [O] bisect-bad sample
>
> ***************************************************************************************************
> lkp-bdw-de1: 16 threads Intel(R) Xeon(R) CPU D-1541 @ 2.10GHz with 8G memory
> =========================================================================================
> cluster/compiler/cpufreq_governor/ip/kconfig/nr_threads/rootfs/runtime/send_size/tbox_group/test/testcase/ucode:
> cs-localhost/gcc-7/performance/ipv4/x86_64-rhel-7.2/200%/debian-x86_64-2018-04-03.cgz/300s/5K/lkp-bdw-de1/TCP_SENDFILE/netperf/0x7000013
>
> commit:
> 3ff6cde846 ("hns3: Another build fix.")
> a337531b94 ("tcp: up initial rmem to 128KB and SYN rwin to around 64KB")
>
> 3ff6cde846857d45 a337531b942bd8a03e7052444d
> ---------------- --------------------------
> fail:runs %reproduction fail:runs
> | | |
> 1:4 -25% :4 dmesg.WARNING:at#for_ip_interrupt_entry/0x
> %stddev %change %stddev
> \ | \
> 5211 -1.0% 5160 netperf.Throughput_Mbps
> 166777 -1.0% 165138 netperf.Throughput_total_Mbps
> 1268 -1.6% 1247 netperf.time.percent_of_cpu_this_job_got
> 3539 -1.6% 3481 netperf.time.system_time
> 282.77 -1.5% 278.54 netperf.time.user_time
> 1435875 -1.0% 1421780 netperf.time.voluntary_context_switches
> 1.222e+09 -1.0% 1.21e+09 netperf.workload
> 22728 -1.3% 22437 vmstat.system.cs
> 1218263 ± 3% -5.6% 1150027 ± 4% proc-vmstat.pgalloc_normal
> 1197588 ± 4% -6.0% 1125684 ± 4% proc-vmstat.pgfree
> 3424 ± 17% -28.2% 2456 ± 21% sched_debug.cpu.nr_load_updates.stddev
> 9.00 ± 11% -19.9% 7.21 ± 11% sched_debug.cpu.nr_uninterruptible.max
> 35344728 ± 33% -94.5% 1954598 ±144% cpuidle.C3.time
> 79217 ± 32% -95.5% 3571 ±115% cpuidle.C3.usage
> 13342584 ± 19% +253.4% 47153200 ± 34% cpuidle.C6.time
> 17886 ± 21% +185.8% 51115 ± 34% cpuidle.C6.usage
> 4295 ± 24% +108.0% 8934 ± 53% cpuidle.POLL.time
> 79180 ± 32% -95.6% 3487 ±118% turbostat.C3
> 0.73 ± 32% -0.7 0.04 ±144% turbostat.C3%
> 17693 ± 21% +187.9% 50931 ± 34% turbostat.C6
> 0.27 ± 19% +0.7 0.97 ± 34% turbostat.C6%
> 0.35 ± 30% -89.9% 0.04 ±173% turbostat.CPU%c3
> 0.08 ± 6% +693.3% 0.59 ± 38% turbostat.CPU%c6
> 2.95 +3.1% 3.04 turbostat.RAMWatt
> 1.711e+12 -1.3% 1.689e+12 perf-stat.branch-instructions
> 5.345e+10 -1.2% 5.283e+10 perf-stat.branch-misses
> 9.417e+10 +16.7% 1.099e+11 perf-stat.cache-misses
> 9.417e+10 +16.7% 1.099e+11 perf-stat.cache-references
> 6927335 -1.1% 6849494 perf-stat.context-switches
> 2.936e+12 -1.3% 2.899e+12 perf-stat.dTLB-loads
> 1.796e+12 -1.3% 1.773e+12 perf-stat.dTLB-stores
> 80.43 +3.5 83.95 perf-stat.iTLB-load-miss-rate%
> 3.809e+09 ± 4% -4.7% 3.629e+09 ± 2% perf-stat.iTLB-load-misses
> 9.248e+08 ± 3% -25.0% 6.934e+08 perf-stat.iTLB-loads
> 8.835e+12 -1.3% 8.719e+12 perf-stat.instructions
> 69.17 -1.1 68.08 perf-profile.calltrace.cycles-pp.__x64_sys_sendfile64.do_syscall_64.entry_SYSCALL_64_after_hwframe
> 65.80 -1.0 64.79 perf-profile.calltrace.cycles-pp.do_sendfile.__x64_sys_sendfile64.do_syscall_64.entry_SYSCALL_64_after_hwframe
> 55.88 -0.8 55.04 perf-profile.calltrace.cycles-pp.do_splice_direct.do_sendfile.__x64_sys_sendfile64.do_syscall_64.entry_SYSCALL_64_after_hwframe
> 52.32 -0.8 51.56 perf-profile.calltrace.cycles-pp.splice_direct_to_actor.do_splice_direct.do_sendfile.__x64_sys_sendfile64.do_syscall_64
> 35.71 -0.6 35.11 perf-profile.calltrace.cycles-pp.direct_splice_actor.splice_direct_to_actor.do_splice_direct.do_sendfile.__x64_sys_sendfile64
> 34.84 -0.6 34.26 perf-profile.calltrace.cycles-pp.splice_from_pipe.direct_splice_actor.splice_direct_to_actor.do_splice_direct.do_sendfile
> 33.94 -0.5 33.41 perf-profile.calltrace.cycles-pp.__splice_from_pipe.splice_from_pipe.direct_splice_actor.splice_direct_to_actor.do_splice_direct
> 26.16 -0.5 25.70 perf-profile.calltrace.cycles-pp.tcp_sendpage.inet_sendpage.kernel_sendpage.sock_sendpage.pipe_to_sendpage
> 30.02 -0.5 29.55 perf-profile.calltrace.cycles-pp.pipe_to_sendpage.__splice_from_pipe.splice_from_pipe.direct_splice_actor.splice_direct_to_actor
> 28.77 -0.4 28.34 perf-profile.calltrace.cycles-pp.sock_sendpage.pipe_to_sendpage.__splice_from_pipe.splice_from_pipe.direct_splice_actor
> 27.68 -0.4 27.27 perf-profile.calltrace.cycles-pp.inet_sendpage.kernel_sendpage.sock_sendpage.pipe_to_sendpage.__splice_from_pipe
> 27.98 -0.4 27.58 perf-profile.calltrace.cycles-pp.kernel_sendpage.sock_sendpage.pipe_to_sendpage.__splice_from_pipe.splice_from_pipe
> 20.30 -0.3 19.95 perf-profile.calltrace.cycles-pp.tcp_sendpage_locked.tcp_sendpage.inet_sendpage.kernel_sendpage.sock_sendpage
> 19.49 -0.3 19.16 perf-profile.calltrace.cycles-pp.do_tcp_sendpages.tcp_sendpage_locked.tcp_sendpage.inet_sendpage.kernel_sendpage
> 9.78 -0.2 9.53 perf-profile.calltrace.cycles-pp.tcp_write_xmit.__tcp_push_pending_frames.do_tcp_sendpages.tcp_sendpage_locked.tcp_sendpage
> 9.94 -0.2 9.70 perf-profile.calltrace.cycles-pp.__tcp_push_pending_frames.do_tcp_sendpages.tcp_sendpage_locked.tcp_sendpage.inet_sendpage
> 6.32 -0.2 6.09 perf-profile.calltrace.cycles-pp.__tcp_transmit_skb.tcp_write_xmit.__tcp_push_pending_frames.do_tcp_sendpages.tcp_sendpage_locked
> 5.59 -0.2 5.42 perf-profile.calltrace.cycles-pp.__ip_queue_xmit.__tcp_transmit_skb.tcp_write_xmit.__tcp_push_pending_frames.do_tcp_sendpages
> 5.19 -0.2 5.02 perf-profile.calltrace.cycles-pp.ip_output.__ip_queue_xmit.__tcp_transmit_skb.tcp_write_xmit.__tcp_push_pending_frames
> 4.79 -0.2 4.62 perf-profile.calltrace.cycles-pp.ip_rcv.__netif_receive_skb_one_core.process_backlog.net_rx_action.__softirqentry_text_start
> 5.51 -0.2 5.35 perf-profile.calltrace.cycles-pp.__softirqentry_text_start.do_softirq_own_stack.do_softirq.__local_bh_enable_ip.ip_finish_output2
> 5.00 -0.2 4.84 perf-profile.calltrace.cycles-pp.__netif_receive_skb_one_core.process_backlog.net_rx_action.__softirqentry_text_start.do_softirq_own_stack
> 5.52 -0.2 5.36 perf-profile.calltrace.cycles-pp.do_softirq_own_stack.do_softirq.__local_bh_enable_ip.ip_finish_output2.ip_output
> 5.37 -0.2 5.21 perf-profile.calltrace.cycles-pp.net_rx_action.__softirqentry_text_start.do_softirq_own_stack.do_softirq.__local_bh_enable_ip
> 4.68 -0.2 4.53 perf-profile.calltrace.cycles-pp.security_file_permission.do_sendfile.__x64_sys_sendfile64.do_syscall_64.entry_SYSCALL_64_after_hwframe
> 5.61 -0.2 5.46 perf-profile.calltrace.cycles-pp.do_softirq.__local_bh_enable_ip.ip_finish_output2.ip_output.__ip_queue_xmit
> 5.21 -0.2 5.06 perf-profile.calltrace.cycles-pp.process_backlog.net_rx_action.__softirqentry_text_start.do_softirq_own_stack.do_softirq
> 4.58 -0.2 4.42 perf-profile.calltrace.cycles-pp.ip_finish_output2.ip_output.__ip_queue_xmit.__tcp_transmit_skb.tcp_write_xmit
> 5.66 -0.2 5.50 perf-profile.calltrace.cycles-pp.__local_bh_enable_ip.ip_finish_output2.ip_output.__ip_queue_xmit.__tcp_transmit_skb
> 4.39 -0.2 4.24 perf-profile.calltrace.cycles-pp.__entry_SYSCALL_64_trampoline
> 2.87 ± 2% -0.1 2.76 perf-profile.calltrace.cycles-pp.selinux_file_permission.security_file_permission.do_sendfile.__x64_sys_sendfile64.do_syscall_64
> 1.25 ± 3% -0.1 1.15 perf-profile.calltrace.cycles-pp.__inode_security_revalidate.selinux_file_permission.security_file_permission.do_sendfile.__x64_sys_sendfile64
> 4.30 -0.1 4.20 perf-profile.calltrace.cycles-pp.ip_local_deliver_finish.ip_local_deliver.ip_rcv.__netif_receive_skb_one_core.process_backlog
> 1.86 -0.1 1.77 ± 3% perf-profile.calltrace.cycles-pp.release_sock.tcp_sendpage.inet_sendpage.kernel_sendpage.sock_sendpage
> 1.14 -0.1 1.08 ± 2% perf-profile.calltrace.cycles-pp.file_has_perm.security_file_permission.do_splice_direct.do_sendfile.__x64_sys_sendfile64
> 0.69 -0.1 0.63 perf-profile.calltrace.cycles-pp.tcp_release_cb.release_sock.tcp_sendpage.inet_sendpage.kernel_sendpage
> 0.61 ± 2% -0.1 0.56 ± 2% perf-profile.calltrace.cycles-pp.__might_fault.__x64_sys_sendfile64.do_syscall_64.entry_SYSCALL_64_after_hwframe
> 0.61 ± 2% -0.0 0.57 ± 4% perf-profile.calltrace.cycles-pp.avc_has_perm.file_has_perm.security_file_permission.do_splice_direct.do_sendfile
> 0.57 ± 2% +0.0 0.61 ± 2% perf-profile.calltrace.cycles-pp.___might_sleep.__might_fault.copy_page_to_iter.skb_copy_datagram_iter.tcp_recvmsg
> 90.63 +0.2 90.83 perf-profile.calltrace.cycles-pp.do_syscall_64.entry_SYSCALL_64_after_hwframe
> 91.39 +0.2 91.62 perf-profile.calltrace.cycles-pp.entry_SYSCALL_64_after_hwframe
> 20.12 +1.3 21.46 perf-profile.calltrace.cycles-pp.__x64_sys_recvfrom.do_syscall_64.entry_SYSCALL_64_after_hwframe
> 20.10 +1.3 21.44 perf-profile.calltrace.cycles-pp.__sys_recvfrom.__x64_sys_recvfrom.do_syscall_64.entry_SYSCALL_64_after_hwframe
> 19.84 +1.4 21.24 perf-profile.calltrace.cycles-pp.tcp_recvmsg.inet_recvmsg.__sys_recvfrom.__x64_sys_recvfrom.do_syscall_64
> 19.89 +1.4 21.30 perf-profile.calltrace.cycles-pp.inet_recvmsg.__sys_recvfrom.__x64_sys_recvfrom.do_syscall_64.entry_SYSCALL_64_after_hwframe
> 15.07 +1.6 16.65 perf-profile.calltrace.cycles-pp.skb_copy_datagram_iter.tcp_recvmsg.inet_recvmsg.__sys_recvfrom.__x64_sys_recvfrom
> 14.25 +1.6 15.82 perf-profile.calltrace.cycles-pp.copy_page_to_iter.skb_copy_datagram_iter.tcp_recvmsg.inet_recvmsg.__sys_recvfrom
> 11.15 +1.6 12.74 perf-profile.calltrace.cycles-pp.copyout.copy_page_to_iter.skb_copy_datagram_iter.tcp_recvmsg.inet_recvmsg
> 10.84 +1.6 12.45 perf-profile.calltrace.cycles-pp.copy_user_enhanced_fast_string.copyout.copy_page_to_iter.skb_copy_datagram_iter.tcp_recvmsg
> 69.33 -1.1 68.23 perf-profile.children.cycles-pp.__x64_sys_sendfile64
> 65.94 -1.0 64.92 perf-profile.children.cycles-pp.do_sendfile
> 55.98 -0.8 55.14 perf-profile.children.cycles-pp.do_splice_direct
> 52.38 -0.8 51.60 perf-profile.children.cycles-pp.splice_direct_to_actor
> 35.77 -0.6 35.16 perf-profile.children.cycles-pp.direct_splice_actor
> 34.91 -0.6 34.33 perf-profile.children.cycles-pp.splice_from_pipe
> 34.07 -0.5 33.53 perf-profile.children.cycles-pp.__splice_from_pipe
> 30.09 -0.5 29.62 perf-profile.children.cycles-pp.pipe_to_sendpage
> 26.31 -0.5 25.86 perf-profile.children.cycles-pp.tcp_sendpage
> 28.85 -0.4 28.42 perf-profile.children.cycles-pp.sock_sendpage
> 27.75 -0.4 27.33 perf-profile.children.cycles-pp.inet_sendpage
> 28.05 -0.4 27.65 perf-profile.children.cycles-pp.kernel_sendpage
> 20.38 -0.3 20.03 perf-profile.children.cycles-pp.tcp_sendpage_locked
> 19.62 -0.3 19.29 perf-profile.children.cycles-pp.do_tcp_sendpages
> 9.69 -0.3 9.42 perf-profile.children.cycles-pp.security_file_permission
> 8.60 -0.2 8.38 perf-profile.children.cycles-pp.__tcp_transmit_skb
> 10.66 -0.2 10.43 perf-profile.children.cycles-pp.tcp_write_xmit
> 10.79 -0.2 10.56 perf-profile.children.cycles-pp.__tcp_push_pending_frames
> 7.82 -0.2 7.64 perf-profile.children.cycles-pp.__ip_queue_xmit
> 7.38 -0.2 7.20 perf-profile.children.cycles-pp.ip_output
> 6.36 -0.2 6.19 perf-profile.children.cycles-pp.__local_bh_enable_ip
> 5.95 -0.2 5.78 perf-profile.children.cycles-pp.__entry_SYSCALL_64_trampoline
> 4.86 -0.2 4.69 perf-profile.children.cycles-pp.ip_rcv
> 5.07 -0.2 4.91 perf-profile.children.cycles-pp.__netif_receive_skb_one_core
> 5.44 -0.2 5.29 perf-profile.children.cycles-pp.net_rx_action
> 5.58 -0.2 5.42 perf-profile.children.cycles-pp.do_softirq_own_stack
> 5.28 -0.2 5.13 perf-profile.children.cycles-pp.process_backlog
> 6.70 -0.2 6.55 perf-profile.children.cycles-pp.ip_finish_output2
> 5.67 -0.1 5.52 perf-profile.children.cycles-pp.do_softirq
> 2.76 ± 3% -0.1 2.62 perf-profile.children.cycles-pp.__inode_security_revalidate
> 1.39 ± 4% -0.1 1.27 ± 2% perf-profile.children.cycles-pp._cond_resched
> 4.45 -0.1 4.34 perf-profile.children.cycles-pp.ip_local_deliver
> 0.73 ± 5% -0.1 0.64 ± 3% perf-profile.children.cycles-pp.rcu_all_qs
> 0.72 -0.1 0.65 perf-profile.children.cycles-pp.tcp_release_cb
> 0.30 ± 5% -0.1 0.24 ± 3% perf-profile.children.cycles-pp.tcp_rcv_space_adjust
> 0.43 ± 4% -0.0 0.39 ± 5% perf-profile.children.cycles-pp.copy_user_generic_unrolled
> 0.17 ± 7% -0.0 0.12 ± 6% perf-profile.children.cycles-pp.ip_rcv_finish_core
> 0.19 ± 7% -0.0 0.15 ± 6% perf-profile.children.cycles-pp.ip_rcv_finish
> 0.14 ± 5% -0.0 0.11 ± 8% perf-profile.children.cycles-pp.tcp_rearm_rto
> 0.10 ± 11% -0.0 0.06 ± 6% perf-profile.children.cycles-pp.sockfd_lookup_light
> 0.07 ± 5% +0.0 0.09 ± 5% perf-profile.children.cycles-pp.skb_entail
> 0.11 ± 3% +0.0 0.13 ± 6% perf-profile.children.cycles-pp.scheduler_tick
> 0.51 ± 3% +0.0 0.55 ± 3% perf-profile.children.cycles-pp.tcp_established_options
> 90.70 +0.2 90.90 perf-profile.children.cycles-pp.do_syscall_64
> 91.47 +0.2 91.70 perf-profile.children.cycles-pp.entry_SYSCALL_64_after_hwframe
> 20.13 +1.3 21.47 perf-profile.children.cycles-pp.__x64_sys_recvfrom
> 20.10 +1.3 21.44 perf-profile.children.cycles-pp.__sys_recvfrom
> 19.89 +1.4 21.30 perf-profile.children.cycles-pp.inet_recvmsg
> 19.84 +1.4 21.26 perf-profile.children.cycles-pp.tcp_recvmsg
> 16.63 +1.6 18.19 perf-profile.children.cycles-pp.copy_page_to_iter
> 15.08 +1.6 16.66 perf-profile.children.cycles-pp.skb_copy_datagram_iter
> 11.24 +1.6 12.82 perf-profile.children.cycles-pp.copyout
> 11.24 +1.6 12.82 perf-profile.children.cycles-pp.copy_user_enhanced_fast_string
> 5.68 -0.2 5.51 perf-profile.self.cycles-pp.__entry_SYSCALL_64_trampoline
> 0.67 -0.1 0.60 ± 2% perf-profile.self.cycles-pp.tcp_release_cb
> 0.93 ± 2% -0.1 0.86 ± 2% perf-profile.self.cycles-pp.__inode_security_revalidate
> 1.09 ± 2% -0.0 1.05 ± 2% perf-profile.self.cycles-pp.do_syscall_64
> 0.16 ± 9% -0.0 0.12 ± 7% perf-profile.self.cycles-pp.ip_rcv_finish_core
> 0.09 ± 11% -0.0 0.05 ± 62% perf-profile.self.cycles-pp.__tcp_ack_snd_check
> 0.40 ± 3% -0.0 0.36 ± 7% perf-profile.self.cycles-pp.copy_user_generic_unrolled
> 0.80 -0.0 0.77 ± 2% perf-profile.self.cycles-pp.current_time
> 0.28 ± 2% -0.0 0.25 ± 3% perf-profile.self.cycles-pp.tcp_recvmsg
> 0.27 ± 6% -0.0 0.24 ± 5% perf-profile.self.cycles-pp.__alloc_skb
> 0.18 ± 6% -0.0 0.15 ± 7% perf-profile.self.cycles-pp.tcp_mstamp_refresh
> 0.10 ± 5% -0.0 0.08 ± 5% perf-profile.self.cycles-pp.__tcp_select_window
> 0.22 ± 3% +0.0 0.24 ± 2% perf-profile.self.cycles-pp._raw_spin_lock_irqsave
> 0.46 ± 5% +0.0 0.51 ± 4% perf-profile.self.cycles-pp.tcp_established_options
> 11.14 +1.5 12.68 perf-profile.self.cycles-pp.copy_user_enhanced_fast_string
>
>
>
> ***************************************************************************************************
> lkp-bdw-de1: 16 threads Intel(R) Xeon(R) CPU D-1541 @ 2.10GHz with 8G memory
> =========================================================================================
> cluster/compiler/cpufreq_governor/ip/kconfig/nr_threads/rootfs/runtime/tbox_group/test/testcase/ucode:
> cs-localhost/gcc-7/performance/ipv4/x86_64-rhel-7.2/200%/debian-x86_64-2018-04-03.cgz/900s/lkp-bdw-de1/TCP_MAERTS/netperf/0x7000013
>
> commit:
> 3ff6cde846 ("hns3: Another build fix.")
> a337531b94 ("tcp: up initial rmem to 128KB and SYN rwin to around 64KB")
>
> 3ff6cde846857d45 a337531b942bd8a03e7052444d
> ---------------- --------------------------
> fail:runs %reproduction fail:runs
> | | |
> 1:4 2% 1:4 perf-profile.children.cycles-pp.schedule_timeout
> %stddev %change %stddev
> \ | \
> 2497 -5.9% 2349 netperf.Throughput_Mbps
> 79914 -5.9% 75172 netperf.Throughput_total_Mbps
> 2472 +4.7% 2588 netperf.time.maximum_resident_set_size
> 8998 +8.0% 9715 netperf.time.minor_page_faults
> 88.91 -13.7% 76.77 netperf.time.user_time
> 5.487e+08 -5.9% 5.162e+08 netperf.workload
> 50507215 ± 49% -63.0% 18671277 ± 27% cpuidle.C3.time
> 111760 ± 6% +12.4% 125584 ± 3% meminfo.DirectMap4k
> 0.35 ± 49% -0.2 0.13 ± 29% turbostat.C3%
> 42.19 -1.2% 41.70 turbostat.PkgWatt
> 1988 +9.6% 2180 ± 2% sched_debug.cfs_rq:/.util_est_enqueued.max
> 401.62 ± 3% +11.2% 446.64 ± 4% sched_debug.cfs_rq:/.util_est_enqueued.stddev
> 3.91 ± 12% -18.4% 3.19 ± 14% sched_debug.cpu.nr_uninterruptible.stddev
> 697.25 ± 4% +48.3% 1034 ± 19% slabinfo.dmaengine-unmap-16.active_objs
> 697.25 ± 4% +48.3% 1034 ± 19% slabinfo.dmaengine-unmap-16.num_objs
> 1464 ± 11% -20.9% 1157 ± 9% slabinfo.skbuff_head_cache.active_objs
> 1464 ± 11% -20.9% 1157 ± 9% slabinfo.skbuff_head_cache.num_objs
> 70462 +1.3% 71390 proc-vmstat.nr_active_anon
> 66190 +1.5% 67154 proc-vmstat.nr_anon_pages
> 70462 +1.3% 71390 proc-vmstat.nr_zone_active_anon
> 2.756e+08 -6.0% 2.592e+08 proc-vmstat.numa_hit
> 2.756e+08 -6.0% 2.592e+08 proc-vmstat.numa_local
> 2.197e+09 -6.0% 2.067e+09 proc-vmstat.pgalloc_normal
> 2.197e+09 -6.0% 2.066e+09 proc-vmstat.pgfree
> 5.831e+11 -7.8% 5.377e+11 perf-stat.branch-instructions
> 1.567e+10 -8.9% 1.428e+10 perf-stat.branch-misses
> 6.246e+11 -4.4% 5.974e+11 perf-stat.cache-misses
> 6.246e+11 -4.4% 5.974e+11 perf-stat.cache-references
> 11.79 +8.4% 12.78 perf-stat.cpi
> 122574 +2.4% 125502 perf-stat.cpu-migrations
> 1.473e+12 -7.0% 1.369e+12 perf-stat.dTLB-loads
> 0.07 ± 13% +0.0 0.09 ± 6% perf-stat.dTLB-store-miss-rate%
> 7.83e+08 ± 13% +15.6% 9.049e+08 ± 6% perf-stat.dTLB-store-misses
> 1.092e+12 -6.8% 1.017e+12 perf-stat.dTLB-stores
> 1.153e+09 -10.1% 1.037e+09 perf-stat.iTLB-load-misses
> 2.66e+08 ± 4% -7.0% 2.474e+08 perf-stat.iTLB-loads
> 2.994e+12 -7.8% 2.761e+12 perf-stat.instructions
> 0.08 -7.8% 0.08 perf-stat.ipc
> 5456 -2.0% 5348 perf-stat.path-length
> 2.62 -0.1 2.49 perf-profile.calltrace.cycles-pp.tcp_write_xmit.__tcp_push_pending_frames.tcp_rcv_established.tcp_v4_do_rcv.tcp_v4_rcv
> 2.64 -0.1 2.51 perf-profile.calltrace.cycles-pp.__tcp_push_pending_frames.tcp_rcv_established.tcp_v4_do_rcv.tcp_v4_rcv.ip_local_deliver_finish
> 2.83 -0.1 2.73 perf-profile.calltrace.cycles-pp.__free_pages_ok.skb_release_data.__kfree_skb.tcp_recvmsg.inet_recvmsg
> 3.64 -0.1 3.54 perf-profile.calltrace.cycles-pp.__kfree_skb.tcp_recvmsg.inet_recvmsg.__sys_recvfrom.__x64_sys_recvfrom
> 3.27 -0.1 3.18 perf-profile.calltrace.cycles-pp.skb_release_data.__kfree_skb.tcp_recvmsg.inet_recvmsg.__sys_recvfrom
> 98.03 +0.1 98.11 perf-profile.calltrace.cycles-pp.entry_SYSCALL_64_after_hwframe
> 97.89 +0.1 97.96 perf-profile.calltrace.cycles-pp.do_syscall_64.entry_SYSCALL_64_after_hwframe
> 0.44 ± 58% +0.3 0.71 ± 5% perf-profile.calltrace.cycles-pp.smp_apic_timer_interrupt.apic_timer_interrupt.copy_user_enhanced_fast_string.copyout.copy_page_to_iter
> 2.92 ± 6% +0.4 3.29 ± 4% perf-profile.calltrace.cycles-pp.apic_timer_interrupt.copy_user_enhanced_fast_string.copyout.copy_page_to_iter.skb_copy_datagram_iter
> 0.00 +0.5 0.55 ± 6% perf-profile.calltrace.cycles-pp.hrtimer_interrupt.smp_apic_timer_interrupt.apic_timer_interrupt.copy_user_enhanced_fast_string.copyout
> 3.64 -0.1 3.52 perf-profile.children.cycles-pp.tcp_write_xmit
> 3.60 -0.1 3.48 perf-profile.children.cycles-pp.__tcp_push_pending_frames
> 2.84 -0.1 2.74 perf-profile.children.cycles-pp.__free_pages_ok
> 4.08 -0.1 4.00 perf-profile.children.cycles-pp.__kfree_skb
> 0.80 ± 2% -0.1 0.74 ± 3% perf-profile.children.cycles-pp.__entry_SYSCALL_64_trampoline
> 0.23 ± 4% -0.0 0.20 ± 5% perf-profile.children.cycles-pp.__sk_mem_schedule
> 0.22 ± 4% -0.0 0.19 ± 5% perf-profile.children.cycles-pp.__sk_mem_raise_allocated
> 0.06 -0.0 0.04 ± 57% perf-profile.children.cycles-pp.tcp_release_cb
> 0.08 ± 6% -0.0 0.06 ± 15% perf-profile.children.cycles-pp.__tcp_select_window
> 0.23 +0.0 0.24 ± 2% perf-profile.children.cycles-pp.__tcp_send_ack
> 0.06 ± 11% +0.0 0.08 ± 5% perf-profile.children.cycles-pp.___perf_sw_event
> 0.06 ± 14% +0.0 0.09 ± 13% perf-profile.children.cycles-pp.tcp_write_timer_handler
> 0.12 ± 7% +0.0 0.15 ± 5% perf-profile.children.cycles-pp.update_curr
> 0.06 ± 11% +0.0 0.09 ± 17% perf-profile.children.cycles-pp.call_timer_fn
> 0.17 ± 4% +0.0 0.20 ± 3% perf-profile.children.cycles-pp.___slab_alloc
> 0.18 ± 4% +0.0 0.21 ± 3% perf-profile.children.cycles-pp.__slab_alloc
> 0.05 ± 58% +0.0 0.08 ± 15% perf-profile.children.cycles-pp.tcp_write_timer
> 0.04 ± 58% +0.0 0.08 ± 16% perf-profile.children.cycles-pp.tcp_send_loss_probe
> 0.32 ± 3% +0.0 0.35 perf-profile.children.cycles-pp.kmem_cache_alloc_node
> 0.14 ± 7% +0.0 0.19 ± 16% perf-profile.children.cycles-pp.preempt_schedule_common
> 0.21 ± 12% +0.1 0.27 ± 6% perf-profile.children.cycles-pp.task_tick_fair
> 0.00 +0.1 0.06 ± 11% perf-profile.children.cycles-pp.__tcp_retransmit_skb
> 0.51 ± 3% +0.1 0.57 ± 6% perf-profile.children.cycles-pp.__sched_text_start
> 1.61 +0.1 1.68 ± 2% perf-profile.children.cycles-pp.__release_sock
> 1.06 ± 3% +0.1 1.14 ± 2% perf-profile.children.cycles-pp.tcp_ack
> 0.28 ± 9% +0.1 0.36 ± 4% perf-profile.children.cycles-pp.scheduler_tick
> 98.09 +0.1 98.18 perf-profile.children.cycles-pp.do_syscall_64
> 98.23 +0.1 98.32 perf-profile.children.cycles-pp.entry_SYSCALL_64_after_hwframe
> 0.49 ± 8% +0.1 0.58 ± 5% perf-profile.children.cycles-pp.update_process_times
> 0.50 ± 8% +0.1 0.61 ± 6% perf-profile.children.cycles-pp.tick_sched_handle
> 0.54 ± 9% +0.1 0.67 ± 5% perf-profile.children.cycles-pp.tick_sched_timer
> 0.79 ± 8% +0.1 0.93 ± 3% perf-profile.children.cycles-pp.__hrtimer_run_queues
> 0.93 ± 9% +0.2 1.09 ± 2% perf-profile.children.cycles-pp.hrtimer_interrupt
> 1.13 ± 10% +0.2 1.37 ± 4% perf-profile.children.cycles-pp.smp_apic_timer_interrupt
> 2.51 ± 6% +0.4 2.87 ± 3% perf-profile.children.cycles-pp.apic_timer_interrupt
> 70.21 +0.4 70.63 perf-profile.children.cycles-pp.copy_user_enhanced_fast_string
> 1.61 -0.1 1.49 ± 2% perf-profile.self.cycles-pp.copy_page_to_iter
> 0.78 ± 2% -0.1 0.72 ± 3% perf-profile.self.cycles-pp.__entry_SYSCALL_64_trampoline
> 1.37 -0.1 1.32 perf-profile.self.cycles-pp.__free_pages_ok
> 0.21 ± 5% -0.0 0.18 ± 4% perf-profile.self.cycles-pp.__sk_mem_raise_allocated
> 0.65 ± 2% -0.0 0.62 perf-profile.self.cycles-pp.free_one_page
> 0.41 ± 2% -0.0 0.39 ± 4% perf-profile.self.cycles-pp.skb_copy_datagram_iter
> 0.08 ± 6% -0.0 0.06 ± 15% perf-profile.self.cycles-pp.__tcp_select_window
> 0.10 ± 5% -0.0 0.08 ± 8% perf-profile.self.cycles-pp.import_single_range
> 0.14 ± 5% +0.0 0.16 ± 5% perf-profile.self.cycles-pp.___slab_alloc
> 0.19 ± 3% +0.0 0.21 ± 3% perf-profile.self.cycles-pp.kmem_cache_alloc_node
> 0.15 ± 4% +0.0 0.17 ± 4% perf-profile.self.cycles-pp.__might_sleep
> 0.03 ±100% +0.0 0.07 ± 13% perf-profile.self.cycles-pp.___perf_sw_event
>
>
>
> ***************************************************************************************************
> lkp-u410: 4 threads Intel(R) Core(TM) i5-3317U CPU @ 1.70GHz with 4G memory
> =========================================================================================
> cluster/compiler/cpufreq_governor/ip/kconfig/nr_threads/rootfs/runtime/tbox_group/test/testcase/ucode:
> cs-localhost/gcc-7/performance/ipv4/x86_64-rhel-7.2/200%/debian-x86_64-2018-04-03.cgz/900s/lkp-u410/TCP_MAERTS/netperf/0x20
>
> commit:
> 3ff6cde846 ("hns3: Another build fix.")
> a337531b94 ("tcp: up initial rmem to 128KB and SYN rwin to around 64KB")
>
> 3ff6cde846857d45 a337531b942bd8a03e7052444d
> ---------------- --------------------------
> fail:runs %reproduction fail:runs
> | | |
> 4:4 -100% :4 dmesg.RIP:intel_modeset_init[i915]
> 4:4 -100% :4 dmesg.WARNING:at_drivers/gpu/drm/i915/intel_display.c:#intel_modeset_init[i915]
> 2:4 -3% 2:4 perf-profile.children.cycles-pp.schedule_timeout
> %stddev %change %stddev
> \ | \
> 3879 -3.2% 3753 netperf.Throughput_Mbps
> 31036 -3.2% 30030 netperf.Throughput_total_Mbps
> 2463 +3.6% 2552 netperf.time.maximum_resident_set_size
> 2499 +7.5% 2685 netperf.time.minor_page_faults
> 24.96 -14.8% 21.28 ± 8% netperf.time.user_time
> 543040 ± 13% -15.9% 456816 ± 2% netperf.time.voluntary_context_switches
> 2.131e+08 -3.2% 2.062e+08 netperf.workload
> 21274 +3.3% 21986 interrupts.CAL:Function_call_interrupts
> 826.00 ± 6% -27.1% 602.00 ± 23% slabinfo.skbuff_head_cache.active_objs
> 3904 ± 2% -4.5% 3728 vmstat.system.cs
> 56.50 ± 2% +8.8% 61.50 ± 5% turbostat.CoreTmp
> 56.75 ± 2% +8.4% 61.50 ± 5% turbostat.PkgTmp
> 4224 ±173% +294.2% 16653 ± 52% sched_debug.cfs_rq:/.spread0.avg
> 110.92 ± 8% -22.2% 86.34 ± 10% sched_debug.cfs_rq:/.util_avg.stddev
> 896147 ± 3% -11.3% 795033 ± 4% sched_debug.cpu.avg_idle.max
> 162406 ± 9% -26.1% 119960 ± 21% sched_debug.cpu.avg_idle.stddev
> 59886 ± 3% -3.8% 57590 proc-vmstat.nr_dirty_background_threshold
> 119920 ± 3% -3.8% 115322 proc-vmstat.nr_dirty_threshold
> 628429 ± 3% -3.7% 605425 proc-vmstat.nr_free_pages
> 1.071e+08 -3.2% 1.036e+08 proc-vmstat.numa_hit
> 1.071e+08 -3.2% 1.036e+08 proc-vmstat.numa_local
> 8.503e+08 -3.2% 8.229e+08 proc-vmstat.pgfree
> 2.265e+11 -5.7% 2.135e+11 perf-stat.branch-instructions
> 3.01 -0.1 2.94 perf-stat.branch-miss-rate%
> 6.809e+09 -7.8% 6.279e+09 ± 3% perf-stat.branch-misses
> 30.13 +2.0 32.13 perf-stat.cache-miss-rate%
> 5.149e+10 +3.2% 5.314e+10 perf-stat.cache-misses
> 1.709e+11 -3.2% 1.654e+11 perf-stat.cache-references
> 3532029 ± 2% -4.5% 3373137 perf-stat.context-switches
> 7.31 +6.2% 7.76 perf-stat.cpi
> 5.633e+09 ± 2% -5.8% 5.308e+09 perf-stat.dTLB-load-misses
> 7.264e+11 -4.1% 6.964e+11 perf-stat.dTLB-loads
> 6.35e+11 -4.0% 6.097e+11 perf-stat.dTLB-stores
> 4.029e+08 -7.1% 3.743e+08 ± 2% perf-stat.iTLB-load-misses
> 1.157e+12 -5.7% 1.091e+12 perf-stat.instructions
> 0.14 -5.8% 0.13 perf-stat.ipc
> 5426 -2.5% 5289 perf-stat.path-length
> 1.16 ± 6% -0.2 0.99 ± 3% perf-profile.calltrace.cycles-pp.__entry_SYSCALL_64_trampoline
> 0.99 ± 6% -0.1 0.88 ± 10% perf-profile.calltrace.cycles-pp.tcp_v4_do_rcv.__release_sock.release_sock.tcp_recvmsg.inet_recvmsg
> 96.58 +0.3 96.87 perf-profile.calltrace.cycles-pp.entry_SYSCALL_64_after_hwframe
> 26.12 ± 2% +1.3 27.40 perf-profile.calltrace.cycles-pp.copy_user_enhanced_fast_string.copyin._copy_from_iter_full.tcp_sendmsg_locked.tcp_sendmsg
> 26.39 ± 2% +1.3 27.69 perf-profile.calltrace.cycles-pp.copyin._copy_from_iter_full.tcp_sendmsg_locked.tcp_sendmsg.sock_sendmsg
> 27.12 ± 3% +1.4 28.48 perf-profile.calltrace.cycles-pp._copy_from_iter_full.tcp_sendmsg_locked.tcp_sendmsg.sock_sendmsg.__sys_sendto
> 41.73 ± 2% +1.7 43.40 ± 2% perf-profile.calltrace.cycles-pp.tcp_sendmsg_locked.tcp_sendmsg.sock_sendmsg.__sys_sendto.__x64_sys_sendto
> 43.17 ± 2% +1.7 44.87 ± 2% perf-profile.calltrace.cycles-pp.tcp_sendmsg.sock_sendmsg.__sys_sendto.__x64_sys_sendto.do_syscall_64
> 43.75 ± 2% +1.8 45.51 perf-profile.calltrace.cycles-pp.sock_sendmsg.__sys_sendto.__x64_sys_sendto.do_syscall_64.entry_SYSCALL_64_after_hwframe
> 44.88 ± 2% +1.8 46.63 perf-profile.calltrace.cycles-pp.__x64_sys_sendto.do_syscall_64.entry_SYSCALL_64_after_hwframe
> 44.73 ± 2% +1.8 46.53 perf-profile.calltrace.cycles-pp.__sys_sendto.__x64_sys_sendto.do_syscall_64.entry_SYSCALL_64_after_hwframe
> 1.38 ± 6% -0.2 1.20 ± 3% perf-profile.children.cycles-pp.__entry_SYSCALL_64_trampoline
> 0.42 ± 9% -0.1 0.31 ± 9% perf-profile.children.cycles-pp.tcp_queue_rcv
> 0.79 ± 6% -0.1 0.68 ± 5% perf-profile.children.cycles-pp.ktime_get_with_offset
> 0.32 ± 12% -0.1 0.21 ± 33% perf-profile.children.cycles-pp.scheduler_tick
> 0.35 ± 12% -0.1 0.26 ± 11% perf-profile.children.cycles-pp.tcp_try_coalesce
> 0.29 ± 10% -0.1 0.20 ± 17% perf-profile.children.cycles-pp.skb_try_coalesce
> 0.88 ± 2% -0.1 0.79 ± 4% perf-profile.children.cycles-pp.tcp_mstamp_refresh
> 0.32 ± 9% -0.1 0.26 ± 18% perf-profile.children.cycles-pp.ip_local_out
> 0.41 ± 3% +0.0 0.45 ± 4% perf-profile.children.cycles-pp.selinux_ip_postroute
> 0.03 ±102% +0.1 0.09 ± 24% perf-profile.children.cycles-pp.lock_timer_base
> 0.00 +0.1 0.08 ± 29% perf-profile.children.cycles-pp.raw_local_deliver
> 0.57 ± 4% +0.1 0.66 ± 7% perf-profile.children.cycles-pp.tcp_event_new_data_sent
> 0.20 ± 28% +0.1 0.29 ± 21% perf-profile.children.cycles-pp._cond_resched
> 64.27 +0.5 64.78 perf-profile.children.cycles-pp.copy_user_enhanced_fast_string
> 26.41 ± 2% +1.3 27.70 perf-profile.children.cycles-pp.copyin
> 27.16 ± 3% +1.3 28.50 perf-profile.children.cycles-pp._copy_from_iter_full
> 41.76 ± 2% +1.7 43.44 ± 2% perf-profile.children.cycles-pp.tcp_sendmsg_locked
> 43.19 ± 2% +1.7 44.88 ± 2% perf-profile.children.cycles-pp.tcp_sendmsg
> 44.88 ± 2% +1.8 46.65 perf-profile.children.cycles-pp.__x64_sys_sendto
> 43.75 ± 2% +1.8 45.51 perf-profile.children.cycles-pp.sock_sendmsg
> 44.74 ± 2% +1.8 46.54 perf-profile.children.cycles-pp.__sys_sendto
> 1.21 ± 8% -0.2 0.99 ± 5% perf-profile.self.cycles-pp.copy_page_to_iter
> 1.32 ± 6% -0.2 1.15 ± 3% perf-profile.self.cycles-pp.__entry_SYSCALL_64_trampoline
> 0.29 ± 9% -0.1 0.20 ± 18% perf-profile.self.cycles-pp.skb_try_coalesce
> 0.50 ± 9% -0.1 0.42 ± 10% perf-profile.self.cycles-pp.ktime_get_with_offset
> 0.19 ± 14% -0.1 0.12 ± 10% perf-profile.self.cycles-pp.__local_bh_enable_ip
> 0.08 ± 10% -0.0 0.03 ±102% perf-profile.self.cycles-pp.selinux_sock_rcv_skb_compat
> 0.13 ± 3% -0.0 0.08 ± 57% perf-profile.self.cycles-pp.__x64_sys_sendto
> 0.07 ± 12% -0.0 0.03 ±100% perf-profile.self.cycles-pp._raw_spin_unlock_irqrestore
> 0.11 ± 11% -0.0 0.08 ± 22% perf-profile.self.cycles-pp.__sys_recvfrom
> 0.05 ± 61% +0.0 0.09 ± 11% perf-profile.self.cycles-pp.selinux_ip_postroute
> 0.09 ± 20% +0.1 0.15 ± 31% perf-profile.self.cycles-pp.rcu_all_qs
> 0.00 +0.1 0.07 ± 28% perf-profile.self.cycles-pp.raw_local_deliver
>
>
>
>
>
> Disclaimer:
> Results have been estimated based on internal Intel analysis and are provided
> for informational purposes only. Any difference in system hardware or software
> design or configuration may affect actual performance.
>
>
> Thanks,
> Rong Chen
>
^ permalink raw reply
* Re: [PATCH RFC] net: dsa: Make switches VLAN aware when enslaved into a bridge
From: Florian Fainelli @ 2018-10-24 22:10 UTC (permalink / raw)
To: netdev
Cc: jiri, petr, idosch, privat, Woojung.Huh, tristram.ha, Andrew Lunn,
Vivien Didelot, David S. Miller, open list
In-Reply-To: <20181024193657.24012-1-f.fainelli@gmail.com>
On 10/24/18 12:36 PM, Florian Fainelli wrote:
> Commit 2ea7a679ca2a ("net: dsa: Don't add vlans when vlan filtering is
> disabled") changed the behavior of DSA switches when the switch ports
> are enslaved into the bridge and only pushed the VLAN configuration down
> to the switch if the bridge is configured with VLAN filtering enabled.
>
> This is unfortunately wrong, because what vlan_filtering configures is a
> policy on the acceptance of VLAN tagged frames with an unknown VID.
>
> vlan_filtering=0 means a frame with a VLAN tag that is not part of the
> VLAN table should be allowed to ingress the switch, and vlan_fltering=1
> would reject that frame.
>
> Fixes: 2ea7a679ca2a ("net: dsa: Don't add vlans when vlan filtering is disabled")
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
> ---
> Andrew,
>
> I checked with Jiri and he confirmed that our interpretention of
> vlan_filtering in DSA was incorrect and that it does denote whether the
> switch should be doing VID ingress policy checking.
>
> You mentioned in the commit message some problems without being too
> specific about them which is why I am putting the same checks in
> mv88e6xxx in order not to break your use cases. Let me know if you want
> to drop that hunk entirely.
>
> Thanks!
>
> drivers/net/dsa/mv88e6xxx/chip.c | 7 ++++++-
> net/dsa/port.c | 10 ++--------
> 2 files changed, 8 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c
> index 8da3d39e3218..df411e776911 100644
> --- a/drivers/net/dsa/mv88e6xxx/chip.c
> +++ b/drivers/net/dsa/mv88e6xxx/chip.c
> @@ -1684,13 +1684,14 @@ static int _mv88e6xxx_port_vlan_add(struct mv88e6xxx_chip *chip, int port,
> static void mv88e6xxx_port_vlan_add(struct dsa_switch *ds, int port,
> const struct switchdev_obj_port_vlan *vlan)
> {
> + struct dsa_port *dp = &ds->ports[i];
This should obviously be port instead of i, but I would still appreciate
a review, thanks!
--
Florian
^ permalink raw reply
* [PATCH net-next 0/4] net: ethernet: ti: cpsw: fix vlan mcast
From: Ivan Khoronzhuk @ 2018-10-24 22:10 UTC (permalink / raw)
To: grygorii.strashko, davem
Cc: linux-omap, netdev, linux-kernel, alexander.h.duyck, bjorn,
Ivan Khoronzhuk
The cpsw holds separate mcast entires for vlan entries. At this moment
driver adds only not vlan mcast addresses, omitting vlan/mcast entries.
As result mcast for vlans doesn't work. It can be fixed by adding same
mcast entries for every created vlan, but this patchseries uses more
sophisticated way and allows to create mcast entries only for vlans
that really require it. Generic functions from this series can be
reused for fixing vlan and macvlan unicast.
Simple example of ALE table before and after this series, having same
mcast entries as for vlan 100 as for real device (reserved vlan 2),
and one mcast address only for vlan 100 - 01:1b:19:00:00:00.
<---- Before this patchset ---->
vlan , vid = 2, untag_force = 0x5, reg_mcast = 0x5, mem_list = 0x5
mcast, vid = 2, addr = ff:ff:ff:ff:ff:ff, port_mask = 0x1
ucast, vid = 2, addr = 74:da:ea:47:7d:9d, persistant, port_num = 0x0
vlan , vid = 0, untag_force = 0x7, reg_mcast = 0x0, mem_list = 0x7
mcast, vid = 2, addr = 33:33:00:00:00:01, port_mask = 0x1
mcast, vid = 2, addr = 01:00:5e:00:00:01, port_mask = 0x1
vlan , vid = 1, untag_force = 0x3, reg_mcast = 0x3, mem_list = 0x3
mcast, vid = 1, addr = ff:ff:ff:ff:ff:ff, port_mask = 0x1
ucast, vid = 1, addr = 74:da:ea:47:7d:9c, persistant, port_num = 0x0
mcast, vid = 1, addr = 33:33:00:00:00:01, port_mask = 0x1
mcast, vid = 1, addr = 01:00:5e:00:00:01, port_mask = 0x1
mcast, vid = 2, addr = 01:80:c2:00:00:00, port_mask = 0x1
mcast, vid = 2, addr = 01:80:c2:00:00:03, port_mask = 0x1
mcast, vid = 2, addr = 01:80:c2:00:00:0e, port_mask = 0x1
mcast, vid = 1, addr = 01:80:c2:00:00:00, port_mask = 0x1
mcast, vid = 1, addr = 01:80:c2:00:00:03, port_mask = 0x1
mcast, vid = 1, addr = 01:80:c2:00:00:0e, port_mask = 0x1
mcast, vid = 2, addr = 33:33:ff:47:7d:9d, port_mask = 0x1
mcast, vid = 2, addr = 33:33:00:00:00:fb, port_mask = 0x1
mcast, vid = 2, addr = 33:33:00:01:00:03, port_mask = 0x1
mcast, vid = 1, addr = 33:33:ff:47:7d:9c, port_mask = 0x1
mcast, vid = 1, addr = 33:33:00:00:00:fb, port_mask = 0x1
mcast, vid = 1, addr = 33:33:00:01:00:03, port_mask = 0x1
mcast, vid = 1, addr = 01:00:5e:00:00:fb, port_mask = 0x1
mcast, vid = 1, addr = 01:00:5e:00:00:fc, port_mask = 0x1
vlan , vid = 100, untag_force = 0x0, reg_mcast = 0x5, mem_list = 0x5
ucast, vid = 100, addr = 74:da:ea:47:7d:9d, persistant, port_num = 0x0
mcast, vid = 100, addr = ff:ff:ff:ff:ff:ff, port_mask = 0x1
mcast, vid = 2, addr = 01:1b:19:00:00:00, port_mask = 0x1
^^^
Here mcast entry (ptpl2), has to be added only for vlan 100
but added for reserved vlan 2...that's not enough.
<---- After this patchset ---->
vlan , vid = 2, untag_force = 0x5, reg_mcast = 0x5, mem_list = 0x5
mcast, vid = 2, addr = ff:ff:ff:ff:ff:ff, port_mask = 0x1
ucast, vid = 2, addr = 74:da:ea:47:7d:9d, persistant, port_num = 0x0
vlan , vid = 0, untag_force = 0x7, reg_mcast = 0x0, mem_list = 0x7
mcast, vid = 2, addr = 33:33:00:00:00:01, port_mask = 0x1
mcast, vid = 2, addr = 01:00:5e:00:00:01, port_mask = 0x1
vlan , vid = 1, untag_force = 0x3, reg_mcast = 0x3, mem_list = 0x3
mcast, vid = 1, addr = ff:ff:ff:ff:ff:ff, port_mask = 0x1
ucast, vid = 1, addr = 74:da:ea:47:7d:9c, persistant, port_num = 0x0
mcast, vid = 1, addr = 33:33:00:00:00:01, port_mask = 0x1
mcast, vid = 1, addr = 01:00:5e:00:00:01, port_mask = 0x1
mcast, vid = 2, addr = 01:80:c2:00:00:00, port_mask = 0x1
mcast, vid = 2, addr = 01:80:c2:00:00:03, port_mask = 0x1
mcast, vid = 2, addr = 01:80:c2:00:00:0e, port_mask = 0x1
mcast, vid = 1, addr = 01:80:c2:00:00:00, port_mask = 0x1
mcast, vid = 1, addr = 01:80:c2:00:00:03, port_mask = 0x1
mcast, vid = 1, addr = 01:80:c2:00:00:0e, port_mask = 0x1
mcast, vid = 2, addr = 33:33:ff:47:7d:9d, port_mask = 0x1
mcast, vid = 1, addr = 33:33:ff:47:7d:9c, port_mask = 0x1
mcast, vid = 2, addr = 33:33:00:00:00:fb, port_mask = 0x1
mcast, vid = 2, addr = 33:33:00:01:00:03, port_mask = 0x1
mcast, vid = 1, addr = 33:33:00:00:00:fb, port_mask = 0x1
mcast, vid = 1, addr = 33:33:00:01:00:03, port_mask = 0x1
vlan , vid = 100, untag_force = 0x0, reg_mcast = 0x5, mem_list = 0x5
ucast, vid = 100, addr = 74:da:ea:47:7d:9d, persistant, port_num = 0x0
mcast, vid = 100, addr = ff:ff:ff:ff:ff:ff, port_mask = 0x1
mcast, vid = 100, addr = 33:33:00:00:00:01, port_mask = 0x1
mcast, vid = 100, addr = 01:00:5e:00:00:01, port_mask = 0x1
mcast, vid = 100, addr = 33:33:ff:47:7d:9d, port_mask = 0x1
mcast, vid = 100, addr = 01:80:c2:00:00:00, port_mask = 0x1
mcast, vid = 100, addr = 01:80:c2:00:00:03, port_mask = 0x1
mcast, vid = 100, addr = 01:80:c2:00:00:0e, port_mask = 0x1
mcast, vid = 100, addr = 33:33:00:00:00:fb, port_mask = 0x1
mcast, vid = 100, addr = 33:33:00:01:00:03, port_mask = 0x1
mcast, vid = 100, addr = 01:1b:19:00:00:00, port_mask = 0x1
^^^
Here mcast entry (ptpl2), is added only for vlan 100
as it should be.
Based on net-next/master
Ivan Khoronzhuk (4):
net: core: dev_addr_lists: add auxiliary func to handle reference
address updates
net: 8021q: vlan_core: allow use list of vlans for real device
net: ethernet: ti: cpsw: fix vlan mcast
net: ethernet: ti: cpsw: fix vlan configuration while down/up
drivers/net/ethernet/ti/cpsw.c | 212 ++++++++++++++++++++++++++++-----
include/linux/if_vlan.h | 11 ++
include/linux/netdevice.h | 10 ++
net/8021q/vlan_core.c | 27 +++++
net/core/dev_addr_lists.c | 97 +++++++++++++++
5 files changed, 326 insertions(+), 31 deletions(-)
--
2.17.1
^ permalink raw reply
* [PATCH 0/3] PM: Renesas: Remove dummy runtime PM callbacks
From: Jarkko Nikula @ 2018-10-24 13:51 UTC (permalink / raw)
To: linux-pm
Cc: linux-i2c, Wolfram Sang, netdev, David S . Miller,
Sergei Shtylyov, linux-renesas-soc, linux-usb, Yoshihiro Shimoda,
Jarkko Nikula
I noticed these independent Renesas drivers have needless dummy runtime
PM callbacks. I don't have the HW so only build tested.
Patches can be applied independently to their own subsystems. I wanted to
send them together if some of them gets Tested-by or sees a regression.
Jarkko Nikula (3):
i2c: sh_mobile: Remove dummy runtime PM callbacks
net: ethernet: Remove dummy runtime PM callbacks from Renesas drivers
usb: renesas_usbhs: Remove dummy runtime PM callbacks
drivers/i2c/busses/i2c-sh_mobile.c | 18 ------------------
drivers/net/ethernet/renesas/ravb_main.c | 13 -------------
drivers/net/ethernet/renesas/sh_eth.c | 13 -------------
drivers/usb/renesas_usbhs/common.c | 14 --------------
4 files changed, 58 deletions(-)
--
2.19.1
^ permalink raw reply
* [PATCH 1/3] i2c: sh_mobile: Remove dummy runtime PM callbacks
From: Jarkko Nikula @ 2018-10-24 13:51 UTC (permalink / raw)
To: linux-pm
Cc: linux-i2c, Wolfram Sang, netdev, David S . Miller,
Sergei Shtylyov, linux-renesas-soc, linux-usb, Yoshihiro Shimoda,
Jarkko Nikula
In-Reply-To: <20181024135134.28456-1-jarkko.nikula@linux.intel.com>
Platform drivers don't need dummy runtime PM callbacks that just return
success and non-NULL pm pointer in their struct device_driver in order
to have runtime PM happening. This has changed since following commits:
05aa55dddb9e ("PM / Runtime: Lenient generic runtime pm callbacks")
543f2503a956 ("PM / platform_bus: Allow runtime PM by default")
8b313a38ecff ("PM / Platform: Use generic runtime PM callbacks directly")
Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
---
Only build tested.
---
drivers/i2c/busses/i2c-sh_mobile.c | 18 ------------------
1 file changed, 18 deletions(-)
diff --git a/drivers/i2c/busses/i2c-sh_mobile.c b/drivers/i2c/busses/i2c-sh_mobile.c
index 818cab14e87c..a7a7a9c3bc7c 100644
--- a/drivers/i2c/busses/i2c-sh_mobile.c
+++ b/drivers/i2c/busses/i2c-sh_mobile.c
@@ -947,27 +947,9 @@ static int sh_mobile_i2c_remove(struct platform_device *dev)
return 0;
}
-static int sh_mobile_i2c_runtime_nop(struct device *dev)
-{
- /* Runtime PM callback shared between ->runtime_suspend()
- * and ->runtime_resume(). Simply returns success.
- *
- * This driver re-initializes all registers after
- * pm_runtime_get_sync() anyway so there is no need
- * to save and restore registers here.
- */
- return 0;
-}
-
-static const struct dev_pm_ops sh_mobile_i2c_dev_pm_ops = {
- .runtime_suspend = sh_mobile_i2c_runtime_nop,
- .runtime_resume = sh_mobile_i2c_runtime_nop,
-};
-
static struct platform_driver sh_mobile_i2c_driver = {
.driver = {
.name = "i2c-sh_mobile",
- .pm = &sh_mobile_i2c_dev_pm_ops,
.of_match_table = sh_mobile_i2c_dt_ids,
},
.probe = sh_mobile_i2c_probe,
--
2.19.1
^ permalink raw reply related
* [PATCH 2/3] net: ethernet: Remove dummy runtime PM callbacks from Renesas drivers
From: Jarkko Nikula @ 2018-10-24 13:51 UTC (permalink / raw)
To: linux-pm
Cc: linux-i2c, Wolfram Sang, netdev, David S . Miller,
Sergei Shtylyov, linux-renesas-soc, linux-usb, Yoshihiro Shimoda,
Jarkko Nikula
In-Reply-To: <20181024135134.28456-1-jarkko.nikula@linux.intel.com>
Platform drivers don't need dummy runtime PM callbacks that just return
success in order to have runtime PM happening. This has changed since
following commits:
05aa55dddb9e ("PM / Runtime: Lenient generic runtime pm callbacks")
543f2503a956 ("PM / platform_bus: Allow runtime PM by default")
8b313a38ecff ("PM / Platform: Use generic runtime PM callbacks directly")
Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
---
Only build tested.
---
drivers/net/ethernet/renesas/ravb_main.c | 13 -------------
drivers/net/ethernet/renesas/sh_eth.c | 13 -------------
2 files changed, 26 deletions(-)
diff --git a/drivers/net/ethernet/renesas/ravb_main.c b/drivers/net/ethernet/renesas/ravb_main.c
index defed0d0c51d..9498f9d67501 100644
--- a/drivers/net/ethernet/renesas/ravb_main.c
+++ b/drivers/net/ethernet/renesas/ravb_main.c
@@ -2335,21 +2335,8 @@ static int __maybe_unused ravb_resume(struct device *dev)
return ret;
}
-static int __maybe_unused ravb_runtime_nop(struct device *dev)
-{
- /* Runtime PM callback shared between ->runtime_suspend()
- * and ->runtime_resume(). Simply returns success.
- *
- * This driver re-initializes all registers after
- * pm_runtime_get_sync() anyway so there is no need
- * to save and restore registers here.
- */
- return 0;
-}
-
static const struct dev_pm_ops ravb_dev_pm_ops = {
SET_SYSTEM_SLEEP_PM_OPS(ravb_suspend, ravb_resume)
- SET_RUNTIME_PM_OPS(ravb_runtime_nop, ravb_runtime_nop, NULL)
};
static struct platform_driver ravb_driver = {
diff --git a/drivers/net/ethernet/renesas/sh_eth.c b/drivers/net/ethernet/renesas/sh_eth.c
index f27a0dc8c563..980310686d45 100644
--- a/drivers/net/ethernet/renesas/sh_eth.c
+++ b/drivers/net/ethernet/renesas/sh_eth.c
@@ -3447,21 +3447,8 @@ static int sh_eth_resume(struct device *dev)
}
#endif
-static int sh_eth_runtime_nop(struct device *dev)
-{
- /* Runtime PM callback shared between ->runtime_suspend()
- * and ->runtime_resume(). Simply returns success.
- *
- * This driver re-initializes all registers after
- * pm_runtime_get_sync() anyway so there is no need
- * to save and restore registers here.
- */
- return 0;
-}
-
static const struct dev_pm_ops sh_eth_dev_pm_ops = {
SET_SYSTEM_SLEEP_PM_OPS(sh_eth_suspend, sh_eth_resume)
- SET_RUNTIME_PM_OPS(sh_eth_runtime_nop, sh_eth_runtime_nop, NULL)
};
#define SH_ETH_PM_OPS (&sh_eth_dev_pm_ops)
#else
--
2.19.1
^ permalink raw reply related
* [PATCH 3/3] usb: renesas_usbhs: Remove dummy runtime PM callbacks
From: Jarkko Nikula @ 2018-10-24 13:51 UTC (permalink / raw)
To: linux-pm
Cc: linux-i2c, Wolfram Sang, netdev, David S . Miller,
Sergei Shtylyov, linux-renesas-soc, linux-usb, Yoshihiro Shimoda,
Jarkko Nikula
In-Reply-To: <20181024135134.28456-1-jarkko.nikula@linux.intel.com>
Platform drivers don't need dummy runtime PM callbacks that just return
success in order to have runtime PM happening. This has changed since
following commits:
05aa55dddb9e ("PM / Runtime: Lenient generic runtime pm callbacks")
543f2503a956 ("PM / platform_bus: Allow runtime PM by default")
8b313a38ecff ("PM / Platform: Use generic runtime PM callbacks directly")
Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
---
Only build tested.
---
drivers/usb/renesas_usbhs/common.c | 14 --------------
1 file changed, 14 deletions(-)
diff --git a/drivers/usb/renesas_usbhs/common.c b/drivers/usb/renesas_usbhs/common.c
index a3e1290d682d..0e760f228dd8 100644
--- a/drivers/usb/renesas_usbhs/common.c
+++ b/drivers/usb/renesas_usbhs/common.c
@@ -874,23 +874,9 @@ static int usbhsc_resume(struct device *dev)
return 0;
}
-static int usbhsc_runtime_nop(struct device *dev)
-{
- /* Runtime PM callback shared between ->runtime_suspend()
- * and ->runtime_resume(). Simply returns success.
- *
- * This driver re-initializes all registers after
- * pm_runtime_get_sync() anyway so there is no need
- * to save and restore registers here.
- */
- return 0;
-}
-
static const struct dev_pm_ops usbhsc_pm_ops = {
.suspend = usbhsc_suspend,
.resume = usbhsc_resume,
- .runtime_suspend = usbhsc_runtime_nop,
- .runtime_resume = usbhsc_runtime_nop,
};
static struct platform_driver renesas_usbhs_driver = {
--
2.19.1
^ permalink raw reply related
* Re: [PATCH v3 2/7] include: add setbits_leXX/clrbits_leXX/clrsetbits_leXX in linux/setbits.h
From: Jakub Kicinski @ 2018-10-24 22:46 UTC (permalink / raw)
To: Corentin Labbe
Cc: Gilles.Muller, Julia.Lawall, agust, airlied, alexandre.torgue,
alistair, benh, carlo, davem, galak, joabreu, khilman,
matthias.bgg, maxime.ripard, michal.lkml, mpe, mporter,
narmstrong, nicolas.palix, oss, paulus, peppe.cavallaro, tj, vitb,
wens, cocci, dri-devel, linux-amlogic, linux-arm-kernel,
linux-ide, linux-kernel, linux-mediatek, linuxppc-dev
In-Reply-To: <1540366553-18541-3-git-send-email-clabbe@baylibre.com>
On Wed, 24 Oct 2018 07:35:48 +0000, Corentin Labbe wrote:
> This patch adds setbits_le32/clrbits_le32/clrsetbits_le32 and
> setbits_le64/clrbits_le64/clrsetbits_le64 in linux/setbits.h header.
>
> Signed-off-by: Corentin Labbe <clabbe@baylibre.com>
Did you have a look at all the functions defined in bitfield.h?
(including the magic macro-generated ones?) Perhaps those could be
used here?
I also share the concerns about the non-atomic RMW. Obviously correct
beats short IMHO.
> diff --git a/include/linux/setbits.h b/include/linux/setbits.h
> new file mode 100644
> index 000000000000..c82faf8d7fe4
> --- /dev/null
> +++ b/include/linux/setbits.h
> @@ -0,0 +1,84 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +#ifndef __LINUX_SETBITS_H
> +#define __LINUX_SETBITS_H
> +
> +#include <linux/io.h>
> +
> +#define __setbits(rfn, wfn, addr, set) wfn((rfn(addr) | (set)), addr)
> +#define __clrbits(rfn, wfn, addr, mask) wfn((rfn(addr) & ~(mask)), addr)
> +#define __clrsetbits(rfn, wfn, addr, mask, set) wfn(((rfn(addr) & ~(mask)) | (set)), addr)
> +#define __setclrbits(rfn, wfn, addr, mask, set) wfn(((rfn(addr) | (set)) & ~(mask)), addr)
> +
> +#ifndef setbits_le32
> +#define setbits_le32(addr, set) __setbits(readl, writel, addr, set)
> +#endif
> +#ifndef setbits_le32_relaxed
> +#define setbits_le32_relaxed(addr, set) __setbits(readl_relaxed, writel_relaxed, \
> + addr, set)
> +#endif
> +
> +#ifndef clrbits_le32
> +#define clrbits_le32(addr, mask) __clrbits(readl, writel, addr, mask)
> +#endif
> +#ifndef clrbits_le32_relaxed
> +#define clrbits_le32_relaxed(addr, mask) __clrbits(readl_relaxed, writel_relaxed, \
> + addr, mask)
> +#endif
> +
> +#ifndef clrsetbits_le32
> +#define clrsetbits_le32(addr, mask, set) __clrsetbits(readl, writel, addr, mask, set)
> +#endif
> +#ifndef clrsetbits_le32_relaxed
> +#define clrsetbits_le32_relaxed(addr, mask, set) __clrsetbits(readl_relaxed, \
> + writel_relaxed, \
> + addr, mask, set)
> +#endif
> +
> +#ifndef setclrbits_le32
> +#define setclrbits_le32(addr, mask, set) __setclrbits(readl, writel, addr, mask, set)
> +#endif
> +#ifndef setclrbits_le32_relaxed
> +#define setclrbits_le32_relaxed(addr, mask, set) __setclrbits(readl_relaxed, \
> + writel_relaxed, \
> + addr, mask, set)
> +#endif
> +
> +/* We cannot use CONFIG_64BIT as some x86 drivers use non-atomicwriteq() */
> +#if defined(writeq) && defined(readq)
> +#ifndef setbits_le64
> +#define setbits_le64(addr, set) __setbits(readq, writeq, addr, set)
> +#endif
> +#ifndef setbits_le64_relaxed
> +#define setbits_le64_relaxed(addr, set) __setbits(readq_relaxed, writeq_relaxed, \
> + addr, set)
> +#endif
> +
> +#ifndef clrbits_le64
> +#define clrbits_le64(addr, mask) __clrbits(readq, writeq, addr, mask)
> +#endif
> +#ifndef clrbits_le64_relaxed
> +#define clrbits_le64_relaxed(addr, mask) __clrbits(readq_relaxed, writeq_relaxed, \
> + addr, mask)
> +#endif
> +
> +#ifndef clrsetbits_le64
> +#define clrsetbits_le64(addr, mask, set) __clrsetbits(readq, writeq, addr, mask, set)
> +#endif
> +#ifndef clrsetbits_le64_relaxed
> +#define clrsetbits_le64_relaxed(addr, mask, set) __clrsetbits(readq_relaxed, \
> + writeq_relaxed, \
> + addr, mask, set)
> +#endif
> +
> +#ifndef setclrbits_le64
> +#define setclrbits_le64(addr, mask, set) __setclrbits(readq, writeq, addr, mask, set)
> +#endif
> +#ifndef setclrbits_le64_relaxed
> +#define setclrbits_le64_relaxed(addr, mask, set) __setclrbits(readq_relaxed, \
> + writeq_relaxed, \
> + addr, mask, set)
> +#endif
> +
> +#endif /* writeq/readq */
> +
> +#endif /* __LINUX_SETBITS_H */
^ 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