* Re: [PATCH] Change judgment len position
From: Eric Dumazet @ 2018-10-25 0:50 UTC (permalink / raw)
To: Joe Perches, David Miller
Cc: w, wanghaifine, netdev, linux-kernel, fengguang.wu, lkp
In-Reply-To: <825268591809f66eb475c3b41c327809a304388f.camel@perches.com>
On 10/24/2018 05:23 PM, Joe Perches wrote:
>
> "You can't be serious?" is kind?
Context maybe ? As a non native, I do not see why it is an offense.
I would like very much we discuss about patches here, not about whatever
interpretation you or anyone could make from any answers.
Recipe for disaster in linux community :
1) Write a bot, sending one wrong patch every hour, with a random "From:" name
and email address.
Yeah, can you believe a bot can actually 'Signed-off-by:' a patch ???
2) Hundred of emails sent, from reviewers, annoyed maintainers, and flames
because the proper words for newbies were not _carefully_ chosen.
So just wait for an answer from the supposed patch author, and see what happens next.
Thank you.
^ permalink raw reply
* Re: [PATCH ghak90 (was ghak32) V4 03/10] audit: log container info of syscalls
From: Richard Guy Briggs @ 2018-10-25 0:42 UTC (permalink / raw)
To: Paul Moore
Cc: containers, linux-api, linux-audit, linux-fsdevel, linux-kernel,
netdev, netfilter-devel, ebiederm, luto, carlos, dhowells, viro,
simo, Eric Paris, Serge Hallyn
In-Reply-To: <CAHC9VhRF1vsxM-k0Lw-9NqS9b9rgXRRBu0tq4ajdFpMqUxiH4A@mail.gmail.com>
On 2018-10-24 16:55, Paul Moore wrote:
> On Wed, Oct 24, 2018 at 11:15 AM Richard Guy Briggs <rgb@redhat.com> wrote:
> > On 2018-10-19 19:16, Paul Moore wrote:
> > > On Sun, Aug 5, 2018 at 4:32 AM Richard Guy Briggs <rgb@redhat.com> wrote:
> > > > Create a new audit record AUDIT_CONTAINER to document the audit
> > > > container identifier of a process if it is present.
> > > >
> > > > Called from audit_log_exit(), syscalls are covered.
> > > >
> > > > A sample raw event:
> > > > type=SYSCALL msg=audit(1519924845.499:257): arch=c000003e syscall=257 success=yes exit=3 a0=ffffff9c a1=56374e1cef30 a2=241 a3=1b6 items=2 ppid=606 pid=635 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=3 comm="bash" exe="/usr/bin/bash" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key="tmpcontainerid"
> > > > type=CWD msg=audit(1519924845.499:257): cwd="/root"
> > > > type=PATH msg=audit(1519924845.499:257): item=0 name="/tmp/" inode=13863 dev=00:27 mode=041777 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:tmp_t:s0 nametype= PARENT cap_fp=0000000000000000 cap_fi=0000000000000000 cap_fe=0 cap_fver=0
> > > > type=PATH msg=audit(1519924845.499:257): item=1 name="/tmp/tmpcontainerid" inode=17729 dev=00:27 mode=0100644 ouid=0 ogid=0 rdev=00:00 obj=unconfined_u:object_r:user_tmp_t:s0 nametype=CREATE cap_fp=0000000000000000 cap_fi=0000000000000000 cap_fe=0 cap_fver=0
> > > > type=PROCTITLE msg=audit(1519924845.499:257): proctitle=62617368002D6300736C65657020313B206563686F2074657374203E202F746D702F746D70636F6E7461696E65726964
> > > > type=CONTAINER msg=audit(1519924845.499:257): op=task contid=123458
> > > >
> > > > See: https://github.com/linux-audit/audit-kernel/issues/90
> > > > See: https://github.com/linux-audit/audit-userspace/issues/51
> > > > See: https://github.com/linux-audit/audit-testsuite/issues/64
> > > > See: https://github.com/linux-audit/audit-kernel/wiki/RFE-Audit-Container-ID
> > > > Signed-off-by: Richard Guy Briggs <rgb@redhat.com>
> > > > Acked-by: Serge Hallyn <serge@hallyn.com>
> > > > Acked-by: Steve Grubb <sgrubb@redhat.com>
> > > > ---
> > > > include/linux/audit.h | 7 +++++++
> > > > include/uapi/linux/audit.h | 1 +
> > > > kernel/audit.c | 24 ++++++++++++++++++++++++
> > > > kernel/auditsc.c | 3 +++
> > > > 4 files changed, 35 insertions(+)
> > >
> > > ...
> > >
> > > > @@ -2045,6 +2045,30 @@ void audit_log_session_info(struct audit_buffer *ab)
> > > > audit_log_format(ab, " auid=%u ses=%u", auid, sessionid);
> > > > }
> > > >
> > > > +/*
> > > > + * audit_log_contid - report container info
> > > > + * @tsk: task to be recorded
> > > > + * @context: task or local context for record
> > > > + * @op: contid string description
> > > > + */
> > > > +int audit_log_contid(struct task_struct *tsk,
> > > > + struct audit_context *context, char *op)
> > > > +{
> > > > + struct audit_buffer *ab;
> > > > +
> > > > + if (!audit_contid_set(tsk))
> > > > + return 0;
> > > > + /* Generate AUDIT_CONTAINER record with container ID */
> > > > + ab = audit_log_start(context, GFP_KERNEL, AUDIT_CONTAINER);
> > > > + if (!ab)
> > > > + return -ENOMEM;
> > > > + audit_log_format(ab, "op=%s contid=%llu",
> > > > + op, audit_get_contid(tsk));
> > > > + audit_log_end(ab);
> > > > + return 0;
> > > > +}
> > > > +EXPORT_SYMBOL(audit_log_contid);
> > >
> > > As discussed in the previous iteration of the patch, I prefer
> > > AUDIT_CONTAINER_ID here over AUDIT_CONTAINER. If you feel strongly
> > > about keeping it as-is with AUDIT_CONTAINER I suppose I could live
> > > with that, but it is isn't my first choice.
> >
> > I don't have a strong opinion on this one, mildly preferring the shorter
> > one only because it is shorter.
>
> We already have multiple AUDIT_CONTAINER* record types, so it seems as
> though we should use "AUDIT_CONTAINER" as a prefix of sorts, rather
> than a type itself.
I'm fine with that. I'd still like to hear Steve's input. He had
stronger opinions than me.
> > > However, I do care about the "op" field in this record. It just
> > > doesn't make any sense; the way you are using it it is more of a
> > > context field than an operations field, and even then why is the
> > > context important from a logging and/or security perspective? Drop it
> > > please.
> >
> > I'll rename it to whatever you like. I'd suggest "ref=". The reason I
> > think it is important is there are multiple sources that aren't always
> > obvious from the other records to which it is associated. In the case
> > of ptrace and signals, there can be many target tasks listed (OBJ_PID)
> > with no other way to distinguish the matching audit container identifier
> > records all for one event. This is in addition to the default syscall
> > container identifier record. I'm not currently happy with the text
> > content to link the two, but that should be solvable (most obvious is
> > taret PID). Throwing away this information seems shortsighted.
>
> It would be helpful if you could generate real audit events
> demonstrating the problems you are describing, as well as a more
> standard syscall event, so we can discuss some possible solutions.
If the auditted process is in a container and it ptraces or signals
another process in a container, there will be two AUDIT_CONTAINER
records for the same event that won't be identified as to which record
belongs to which process or other record (SYSCALL vs 1+ OBJ_PID
records). There could be many signals recorded, each with their own
OBJ_PID record. The first is stored in the audit context and additional
ones are stored in a chained struct that can accommodate 16 entries each.
(See audit_signal_info(), __audit_ptrace().)
(As a side note, on code inspection it appears that a signal target
would get overwritten by a ptrace action if they were to happen in that
order.)
> paul moore
- RGB
--
Richard Guy Briggs <rgb@redhat.com>
Sr. S/W Engineer, Kernel Security, Base Operating Systems
Remote, Ottawa, Red Hat Canada
IRC: rgb, SunRaycer
Voice: +1.647.777.2635, Internal: (81) 32635
^ permalink raw reply
* Re: [PATCH] Change judgment len position
From: Joe Perches @ 2018-10-25 0:23 UTC (permalink / raw)
To: David Miller; +Cc: w, wanghaifine, netdev, linux-kernel, fengguang.wu, lkp
In-Reply-To: <20181024.170213.632063387857625082.davem@davemloft.net>
On Wed, 2018-10-24 at 17:02 -0700, David Miller wrote:
> From: Joe Perches <joe@perches.com>
> Date: Wed, 24 Oct 2018 16:46:18 -0700
>
> > I would have suggested David reply with only his second sentence
> > and maybe a pointer to kernelnewbies or staging.is
>
> I maintain that I was not out of line with my comment.
>
> I sought a second opinion from Greg KH and others, and they agree with
> me that I was still kind with my choice of words.
"You can't be serious?" is kind?
> I think you're taking things too far, and I will simply not stand for
> this overreaching judgement upon my behavior on this list which is
> completely not justified.
Even above here, concision is generally better.
overreaching and completely are probably not reasonable.
openness and defensiveness are somewhat antithetic.
>From the new Code of Conduct (which I don't even approve)
* Gracefully accepting constructive criticism.
cheers, Joe
^ permalink raw reply
* [PATCH 2/2] Bluetooth: btqcomsmd: use HCI_QUIRK_USE_BDADDR_PROPERTY
From: Matthias Kaehlcke @ 2018-10-25 0:21 UTC (permalink / raw)
To: Marcel Holtmann, Johan Hedberg, David S . Miller, Loic Poulain
Cc: linux-bluetooth, netdev, linux-kernel, Balakrishna Godavarthi,
Brian Norris, Dmitry Grinberg, Matthias Kaehlcke
In-Reply-To: <20181025002134.256791-1-mka@chromium.org>
Use the HCI_QUIRK_USE_BDADDR_PROPERTY quirk to let the HCI
core handle the reading of 'local-bd-address'. With this there
is no need to set HCI_QUIRK_INVALID_BDADDR, the case of a
non-existing or invalid fwnode property is handled by the core
code.
Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
---
I couldn't actually test the changes in this driver since I
don't have a device with this controller. Could someone
from Qualcomm help with this?
---
drivers/bluetooth/btqcomsmd.c | 28 +++-------------------------
1 file changed, 3 insertions(+), 25 deletions(-)
diff --git a/drivers/bluetooth/btqcomsmd.c b/drivers/bluetooth/btqcomsmd.c
index 7df3eed1ef5e..e5841602c4f1 100644
--- a/drivers/bluetooth/btqcomsmd.c
+++ b/drivers/bluetooth/btqcomsmd.c
@@ -125,23 +125,10 @@ static int btqcomsmd_setup(struct hci_dev *hdev)
return PTR_ERR(skb);
kfree_skb(skb);
- /* Devices do not have persistent storage for BD address. If no
- * BD address has been retrieved during probe, mark the device
- * as having an invalid BD address.
+ /* Devices do not have persistent storage for BD address. Retrieve
+ * it from the firmware node property.
*/
- if (!bacmp(&btq->bdaddr, BDADDR_ANY)) {
- set_bit(HCI_QUIRK_INVALID_BDADDR, &hdev->quirks);
- return 0;
- }
-
- /* When setting a configured BD address fails, mark the device
- * as having an invalid BD address.
- */
- err = qca_set_bdaddr_rome(hdev, &btq->bdaddr);
- if (err) {
- set_bit(HCI_QUIRK_INVALID_BDADDR, &hdev->quirks);
- return 0;
- }
+ set_bit(HCI_QUIRK_USE_BDADDR_PROPERTY, &hdev->quirks);
return 0;
}
@@ -169,15 +156,6 @@ static int btqcomsmd_probe(struct platform_device *pdev)
if (IS_ERR(btq->cmd_channel))
return PTR_ERR(btq->cmd_channel);
- /* The local-bd-address property is usually injected by the
- * bootloader which has access to the allocated BD address.
- */
- if (!of_property_read_u8_array(pdev->dev.of_node, "local-bd-address",
- (u8 *)&btq->bdaddr, sizeof(bdaddr_t))) {
- dev_info(&pdev->dev, "BD address %pMR retrieved from device-tree",
- &btq->bdaddr);
- }
-
hdev = hci_alloc_dev();
if (!hdev)
return -ENOMEM;
--
2.19.1.568.g152ad8e336-goog
^ permalink raw reply related
* [PATCH 0/2] Add quirk for reading BD_ADDR from fwnode property
From: Matthias Kaehlcke @ 2018-10-25 0:21 UTC (permalink / raw)
To: Marcel Holtmann, Johan Hedberg, David S . Miller, Loic Poulain
Cc: linux-bluetooth, netdev, linux-kernel, Balakrishna Godavarthi,
Brian Norris, Dmitry Grinberg, Matthias Kaehlcke
On some systems the Bluetooth Device Address (BD_ADDR) isn't stored
on the Bluetooth chip itself. One way to configure the address is
through the device tree (patched in by the bootloader). The btqcomsmd
driver is an example, it can read the address from the DT property
'local-bd-address'. It is also planned to extend the hci_qca driver
to support setting the BD address through the DT.
To avoid redundant open-coded reading of 'local-bd-address' and error
handling this series adds the quirk HCI_QUIRK_USE_BDADDR_PROPERTY to
retrieve the BD address of a device from the DT and adapts the
btqcomsmd driver to use this quirk.
Matthias Kaehlcke (2):
Bluetooth: Add quirk for reading BD_ADDR from fwnode property
Bluetooth: btqcomsmd: use HCI_QUIRK_USE_BDADDR_PROPERTY
drivers/bluetooth/btqcomsmd.c | 28 +++--------------------
include/net/bluetooth/hci.h | 12 ++++++++++
net/bluetooth/hci_core.c | 42 +++++++++++++++++++++++++++++++++++
net/bluetooth/mgmt.c | 6 +++--
4 files changed, 61 insertions(+), 27 deletions(-)
--
2.19.1.568.g152ad8e336-goog
^ permalink raw reply
* [PATCH] Change judgment len position
From: Wang Hai @ 2018-10-24 15:47 UTC (permalink / raw)
To: edumazet; +Cc: davem, kuznet, yoshfuji, netdev, linux-kernel, Wang Hai
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.
Signed-off-by: Wang Hai <wanghaifine@gmail.com>
---
net/ipv4/tcp.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
index 10c624639..49af9fdc3 100644
--- 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;
- len = min_t(unsigned int, len, sizeof(int));
-
if (len < 0)
return -EINVAL;
--
2.17.1
^ permalink raw reply related
* Re: [PATCH] r8169: Add new device ID support
From: Stephen Hemminger @ 2018-10-24 15:47 UTC (permalink / raw)
To: Shawn Lin; +Cc: David Miller, nic_swsd, netdev
In-Reply-To: <db4ae0f0-97e4-d2c1-9ac9-e689e3d80447@rock-chips.com>
On Wed, 24 Oct 2018 14:29:34 +0800
Shawn Lin <shawn.lin@rock-chips.com> wrote:
> On 2018/10/24 13:54, David Miller wrote:
> > From: Shawn Lin <shawn.lin@rock-chips.com>
> > Date: Wed, 24 Oct 2018 13:48:55 +0800
> >
> >> Hi David,
> >>
> >> On 2018/10/24 10:19, David Miller wrote:
> >>> From: Shawn Lin <shawn.lin@rock-chips.com>
> >>> Date: Wed, 24 Oct 2018 09:46:47 +0800
> >>>
> >>>> It's found my r8169 ethernet card at hand has a device ID
> >>>> of 0x0000 which wasn't on the list of rtl8169_pci_tbl. Add
> >>>> a new entry to make it work:
> >>> ...
> >>>> 01:00.0 Class 0200: 10ec:0000
> >>> I don't know about this.
> >>> A value of zero could mean the device is mis-responding to
> >>> PCI config space requests or something like that.
> >>
> >> It was working fine on my retired Windows XP home PC with same devcice
> >> ID listed, so I guess r8169 driver for windows system knows 0x0000 is
> >> also valid.
> >
> > It is also possible the device comes up in a different state.
> >
> > Under windows does it show with that device ID of zero?
>
> yup. More precisely, I checked how BIOS enumerate it by PCIe analyzer
> and see it does report 0x0000 as device ID.
>
> >
> >
> >
>
Look at device manager properties of the device in Windows?
^ permalink raw reply
* Re: [PATCH] Change judgment len position
From: David Miller @ 2018-10-25 0:02 UTC (permalink / raw)
To: joe; +Cc: w, wanghaifine, netdev, linux-kernel, fengguang.wu, lkp
In-Reply-To: <49ec92564284b5beb0a151bce1d537b51340d0a8.camel@perches.com>
From: Joe Perches <joe@perches.com>
Date: Wed, 24 Oct 2018 16:46:18 -0700
> I would have suggested David reply with only his second sentence
> and maybe a pointer to kernelnewbies or staging.
I maintain that I was not out of line with my comment.
I sought a second opinion from Greg KH and others, and they agree with
me that I was still kind with my choice of words.
I think you're taking things too far, and I will simply not stand for
this overreaching judgement upon my behavior on this list which is
completely not justified.
Thank you.
^ permalink raw reply
* [PATCH net] net: sched: Remove TCA_OPTIONS from policy
From: David Ahern @ 2018-10-24 15:32 UTC (permalink / raw)
To: netdev, davem, pupilla; +Cc: David Ahern
From: David Ahern <dsahern@gmail.com>
Marco reported an error with hfsc:
root@Calimero:~# tc qdisc add dev eth0 root handle 1:0 hfsc default 1
Error: Attribute failed policy validation.
Apparently a few implementations pass TCA_OPTIONS as a binary instead
of nested attribute, so drop TCA_OPTIONS from the policy.
Fixes: 8b4c3cdd9dd8 ("net: sched: Add policy validation for tc attributes")
Reported-by: Marco Berizzi <pupilla@libero.it>
Signed-off-by: David Ahern <dsahern@gmail.com>
---
net/sched/sch_api.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/net/sched/sch_api.c b/net/sched/sch_api.c
index 3dc0acf54245..be7cd140b2a3 100644
--- a/net/sched/sch_api.c
+++ b/net/sched/sch_api.c
@@ -1309,7 +1309,6 @@ check_loop_fn(struct Qdisc *q, unsigned long cl, struct qdisc_walker *w)
const struct nla_policy rtm_tca_policy[TCA_MAX + 1] = {
[TCA_KIND] = { .type = NLA_STRING },
- [TCA_OPTIONS] = { .type = NLA_NESTED },
[TCA_RATE] = { .type = NLA_BINARY,
.len = sizeof(struct tc_estimator) },
[TCA_STAB] = { .type = NLA_NESTED },
--
2.11.0
^ permalink raw reply related
* Re: [net-next][PATCH] net/ipv4: fix a net leak
From: David Ahern @ 2018-10-24 15:21 UTC (permalink / raw)
To: David Ahern, Li RongQing, netdev, David Miller
In-Reply-To: <92af7409-6154-eb85-7d2f-56f5288b8894@gmail.com>
On 10/24/18 9:02 AM, David Ahern wrote:
> On 10/24/18 3:36 AM, Li RongQing wrote:
>> put net when input a invalid ifindex, otherwise it will be leaked
>>
>> Fixes: 5fcd266a9f64("net/ipv4: Add support for dumping addresses for a specific device")
>> Cc: David Ahern <dsahern@gmail.com>
>> Signed-off-by: Zhang Yu <zhangyu31@baidu.com>
>> Signed-off-by: Li RongQing <lirongqing@baidu.com>
>> ---
>> net/ipv4/devinet.c | 4 +++-
>> 1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/net/ipv4/devinet.c b/net/ipv4/devinet.c
>> index 63d5b58fbfdb..fd0c5a47e742 100644
>> --- a/net/ipv4/devinet.c
>> +++ b/net/ipv4/devinet.c
>> @@ -1775,8 +1775,10 @@ static int inet_dump_ifaddr(struct sk_buff *skb, struct netlink_callback *cb)
>>
>> if (fillargs.ifindex) {
>> dev = __dev_get_by_index(tgt_net, fillargs.ifindex);
>> - if (!dev)
>> + if (!dev) {
>> + put_net(tgt_net);
>> return -ENODEV;
>> + }
>>
>> in_dev = __in_dev_get_rtnl(dev);
>> if (in_dev) {
>>
>
> Good catch. IPv6 has the same problem. Will fix that one.
>
Actually remove that 'Reviewed-by'. You should only call put_net if
(fillargs.netnsid >= 0)
DaveM: just want to call this out since I mistakenly added the
Reviewed-by. This patch should be dropped.
^ permalink raw reply
* Re: [PATCH] Change judgment len position
From: Joe Perches @ 2018-10-24 23:46 UTC (permalink / raw)
To: Willy Tarreau; +Cc: David Miller, wanghaifine, netdev, LKML, Fengguang Wu, lkp
In-Reply-To: <20181024204852.GA25509@1wt.eu>
(adding Fengguang Wu and lkp)
On Wed, 2018-10-24 at 22:48 +0200, Willy Tarreau wrote:
> 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.
Which to me is more of an indication of beginner-ness.
> 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,
That seems unlikely as it introduces a compilation warning.
A real intentional backdoor from a nefarious source would
likely be completely correct about compilation and use the
typical commit subject style.
Anyway, who know for certain right now.
I would have suggested David reply with only his second sentence
and maybe a pointer to kernelnewbies or staging.
Just something like:
nack: 'len' has no value before the get_user() call.
Please try to make your first patch in drivers/staging
to get familiar with submitting patches to the kernel.
https://kernelnewbies.org/FirstKernelPatch
Maybe there's utility in creating a filtering and auto-reply
tool for first time patch submitters for all the vger mailing
lists using some combination of previously known submitters
and the 0-day robot to point those first time submitters of
defective patches to kernelnewbies and staging.
cheers, Joe
^ permalink raw reply
* Re: [net-next][PATCH] net/ipv4: fix a net leak
From: David Ahern @ 2018-10-24 15:02 UTC (permalink / raw)
To: Li RongQing, netdev
In-Reply-To: <1540373788-15078-1-git-send-email-lirongqing@baidu.com>
On 10/24/18 3:36 AM, Li RongQing wrote:
> put net when input a invalid ifindex, otherwise it will be leaked
>
> Fixes: 5fcd266a9f64("net/ipv4: Add support for dumping addresses for a specific device")
> Cc: David Ahern <dsahern@gmail.com>
> Signed-off-by: Zhang Yu <zhangyu31@baidu.com>
> Signed-off-by: Li RongQing <lirongqing@baidu.com>
> ---
> net/ipv4/devinet.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/net/ipv4/devinet.c b/net/ipv4/devinet.c
> index 63d5b58fbfdb..fd0c5a47e742 100644
> --- a/net/ipv4/devinet.c
> +++ b/net/ipv4/devinet.c
> @@ -1775,8 +1775,10 @@ static int inet_dump_ifaddr(struct sk_buff *skb, struct netlink_callback *cb)
>
> if (fillargs.ifindex) {
> dev = __dev_get_by_index(tgt_net, fillargs.ifindex);
> - if (!dev)
> + if (!dev) {
> + put_net(tgt_net);
> return -ENODEV;
> + }
>
> in_dev = __in_dev_get_rtnl(dev);
> if (in_dev) {
>
Good catch. IPv6 has the same problem. Will fix that one.
Reviewed-by: David Ahern <dsahern@gmail.com>
^ permalink raw reply
* Re: Attribute failed policy validation
From: David Ahern @ 2018-10-24 14:58 UTC (permalink / raw)
To: Florian Westphal, Marco Berizzi; +Cc: netdev, dsahern
In-Reply-To: <20181024130742.777kcbzp667mo5rm@breakpoint.cc>
On 10/24/18 7:07 AM, Florian Westphal wrote:
> 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 :-(
>
Yep. I'll send a fix.
^ permalink raw reply
* Re: [PATCH 0/3] PM: Renesas: Remove dummy runtime PM callbacks
From: Wolfram Sang @ 2018-10-24 14:22 UTC (permalink / raw)
To: Jarkko Nikula, Magnus Damm
Cc: linux-pm, linux-i2c, Wolfram Sang, netdev, David S . Miller,
Sergei Shtylyov, linux-renesas-soc, linux-usb, Yoshihiro Shimoda
In-Reply-To: <20181024135134.28456-1-jarkko.nikula@linux.intel.com>
[-- Attachment #1: Type: text/plain, Size: 1155 bytes --]
On Wed, Oct 24, 2018 at 04:51:31PM +0300, Jarkko Nikula wrote:
> 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.
At least the I2C driver part of this was on my todo list as well (just a
bit lower :/). I wanted to find out why they have been there in the
first place. Do you know if such callbacks were needed "back in the
days"?
Adding Magnus to recipients...
>
> 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
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* 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
* [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
* [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 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 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 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
* 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
* 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 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: [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: 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
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