* Re: [PATCH net-next] virtio_net: ethtool tx napi configuration
From: Jason Wang @ 2018-09-27 8:50 UTC (permalink / raw)
To: Willem de Bruijn
Cc: Florian Fainelli, Network Development, David Miller, caleb.raitto,
Michael S. Tsirkin, Jon Olson (Google Drive), Willem de Bruijn
In-Reply-To: <CAF=yD-KEcWuYrSofugYBc3kwWvQdFDsv3z_yWx5-JDzyMga1qw@mail.gmail.com>
On 2018年09月14日 12:46, Willem de Bruijn wrote:
>> I'm not sure I get this. If we don't enable tx napi, we tend to delay TX
>> interrupt if we found the ring is about to full to avoid interrupt
>> storm, so we're probably ok in this case.
> I'm only concerned about the transition state when converting from
> napi to no-napi when the queue is stopped and tx interrupt disabled.
>
> With napi mode the interrupt is only disabled if napi is scheduled,
> in which case it will eventually reenable the interrupt. But when
> switching to no-napi mode in this state no progress will be made.
>
> But it seems this cannot happen. When converting to no-napi
> mode, set_coalesce waits for napi to complete in napi_disable.
> So the interrupt should always start enabled when transitioning
> into no-napi mode.
An update, I meet a hang in napi_disalbe(). But it's hard to be
reproduced. I tend to choose a easy way like V1 that only allow the
switching when device is down.
I will post the patch after a vacation. (or you can post if it was
urgent for you).
Thanks
^ permalink raw reply
* [PATCH] MAINTAINERS: change bridge maintainers
From: Stephen Hemminger @ 2018-09-27 8:47 UTC (permalink / raw)
To: davem; +Cc: netdev, Stephen Hemminger, Stephen Hemminger
I haven't been doing reviews only but not active development on bridge
code for several years. Roopa and Nikolay have been doing most of
the new features and have agreed to take over as new co-maintainers.
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
---
MAINTAINERS | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 7233a9ed0f5b..123ae2e65d94 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5470,7 +5470,8 @@ S: Odd Fixes
F: drivers/net/ethernet/agere/
ETHERNET BRIDGE
-M: Stephen Hemminger <stephen@networkplumber.org>
+M: Roopa Prabhu <roopa@cumulusnetworks.com>
+M: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
L: bridge@lists.linux-foundation.org (moderated for non-subscribers)
L: netdev@vger.kernel.org
W: http://www.linuxfoundation.org/en/Net:Bridge
--
2.17.1
^ permalink raw reply related
* Re: [PATCH] ieee802154: remove a redundant local variable 'i'
From: Stefan Schmidt @ 2018-09-27 14:47 UTC (permalink / raw)
To: zhong jiang, davem; +Cc: alex.aring, netdev, linux-kernel
In-Reply-To: <1537368097-60101-1-git-send-email-zhongjiang@huawei.com>
Hello.
On 19/09/2018 16:41, zhong jiang wrote:
> The local variable 'i' is never used after being assigned.
> hence it should be redundant adn can be removed.
>
> Signed-off-by: zhong jiang <zhongjiang@huawei.com>
> ---
> net/ieee802154/nl802154.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/net/ieee802154/nl802154.c b/net/ieee802154/nl802154.c
> index 99f6c25..5b90151 100644
> --- a/net/ieee802154/nl802154.c
> +++ b/net/ieee802154/nl802154.c
> @@ -445,7 +445,6 @@ static int nl802154_send_wpan_phy(struct cfg802154_registered_device *rdev,
> {
> struct nlattr *nl_cmds;
> void *hdr;
> - int i;
>
> hdr = nl802154hdr_put(msg, portid, seq, flags, cmd);
> if (!hdr)
> @@ -508,7 +507,6 @@ static int nl802154_send_wpan_phy(struct cfg802154_registered_device *rdev,
> if (!nl_cmds)
> goto nla_put_failure;
>
> - i = 0;
> #define CMD(op, n) \
> do { \
> if (rdev->ops->op) { \
>
Sorry, but this patch is wrong. The variable i is used in line 513
inside the CMD() macro. The compiler clearly tells this when running
with your patch:
net/ieee802154/nl802154.c: In function ‘nl802154_send_wpan_phy’:
net/ieee802154/nl802154.c:513:4: error: ‘i’ undeclared (first use in
this function)
I would appreciate if patches sent out would at least be compile tested.
regards
Stefan Schmidt
^ permalink raw reply
* Re: [PATCH v3 0/5] netlink: nested policy validation
From: Johannes Berg @ 2018-09-27 8:22 UTC (permalink / raw)
To: David Miller; +Cc: netdev, dsahern
In-Reply-To: <20180926.102154.1962354339786539715.davem@davemloft.net>
On Wed, 2018-09-26 at 10:21 -0700, David Miller wrote:
> From: Johannes Berg <johannes@sipsolutions.net>
> Date: Wed, 26 Sep 2018 11:15:29 +0200
>
> > This adds nested policy validation, which lets you specify the
> > nested attribute type, e.g. NLA_NESTED with sub-policy, or the
> > new NLA_NESTED_ARRAY with sub-sub-policy.
> >
> >
> > Changes in v2:
> > * move setting the bad attr pointer/message into validate_nla()
> > * remove the recursion patch since that's no longer needed
> > * simply skip the generic bad attr pointer/message setting in
> > case of nested nla_validate() failing since that could fail
> > only due to validate_nla() failing inside, which already sets
> > the extack information
> >
> > Changes in v3:
> > * fix NLA_REJECT to have an error message if none is in policy
>
> Looks great Johannes, series applied.
Sorry to nag, but I see patches that you replied to later than this in
the tree, but not this.
Or did you see something wrong with this later and dropped it?
johannes
^ permalink raw reply
* Re: [PATCH] team: set IFF_SLAVE on team ports
From: Chas Williams @ 2018-09-27 14:04 UTC (permalink / raw)
To: Jiri Pirko, Jan Blunck; +Cc: LKML, netdev
In-Reply-To: <20150710064147.GA2204@nanopsycho.orion>
On 07/10/15 02:41, Jiri Pirko wrote:
> Thu, Jul 09, 2015 at 05:36:55PM CEST, jblunck@infradead.org wrote:
>> On Thu, Jul 9, 2015 at 12:07 PM, Jiri Pirko <jiri@resnulli.us> wrote:
>>> Thu, Jul 09, 2015 at 11:58:34AM CEST, jblunck@infradead.org wrote:
>>>> The code in net/ipv6/addrconf.c:addrconf_notify() tests for IFF_SLAVE to
>>>> decide if it should start the address configuration. Since team ports
>>>> shouldn't get link-local addresses assigned lets set IFF_SLAVE when linking
>>>> a port to the team master.
>>>
>>> I don't want to use IFF_SLAVE in team. Other master-slave devices are
>>> not using that as well, for example bridge, ovs, etc.
>>>
>>
>> Maybe they need to get fixed too. I've used that flag because it is
>> documented as
>> a "slave of a load balancer" which describes what a team port is.
>>
>>
>>> I think that this should be fixed in addrconf_notify. It should lookup
>>> if there is a master on top and bail out in that case.
>>
>> There are other virtual interfaces that have a master assigned and want to
>> participate in IPv6 address configuration.
>
> Can you give me an example?
I would like to revisit this patch (yes, I know it has been a while). I
believe the VRF implementation uses master to group the interfaces under
a single interface.
I don't see a reason not to use IFF_SLAVE since team and bonding are
fairly similar.
>>
>> Unless we want to have a cascade of conditionals testing the priv_flags in
>> addrconf_notify() this is asking for a new net_device_flags flag.
>> Maybe something
>> generic like IFF_L2PORT ?
>>
>> Thanks,
>> Jan
>>
>> [ Jiri, sorry for getting that mail twice ]
>
>
>
^ permalink raw reply
* [PATCH iproute2] vxlan: show correct ttl inherit info
From: Hangbin Liu @ 2018-09-27 7:28 UTC (permalink / raw)
To: netdev; +Cc: Stephen Hemminger, David Ahern, Phil Sutter, Hangbin Liu
We should only show ttl inherit when IFLA_VXLAN_TTL_INHERIT supplied.
Otherwise show the ttl number, or auto when it is 0.
Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
---
ip/iplink_vxlan.c | 16 ++++++++++------
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/ip/iplink_vxlan.c b/ip/iplink_vxlan.c
index 831f39a..7fc0e2b 100644
--- a/ip/iplink_vxlan.c
+++ b/ip/iplink_vxlan.c
@@ -145,7 +145,7 @@ static int vxlan_parse_opt(struct link_util *lu, int argc, char **argv,
NEXT_ARG();
check_duparg(&attrs, IFLA_VXLAN_TTL, "ttl", *argv);
if (strcmp(*argv, "inherit") == 0) {
- addattr_l(n, 1024, IFLA_VXLAN_TTL_INHERIT, NULL, 0);
+ addattr(n, 1024, IFLA_VXLAN_TTL_INHERIT);
} else if (strcmp(*argv, "auto") == 0) {
addattr8(n, 1024, IFLA_VXLAN_TTL, ttl);
} else {
@@ -527,12 +527,16 @@ static void vxlan_print_opt(struct link_util *lu, FILE *f, struct rtattr *tb[])
print_string(PRINT_FP, NULL, "tos %s ", "inherit");
}
- if (tb[IFLA_VXLAN_TTL])
- ttl = rta_getattr_u8(tb[IFLA_VXLAN_TTL]);
- if (is_json_context() || ttl)
- print_uint(PRINT_ANY, "ttl", "ttl %u ", ttl);
- else
+ if (tb[IFLA_VXLAN_TTL_INHERIT] &&
+ rta_getattr_u8(tb[IFLA_VXLAN_TTL_INHERIT])) {
print_string(PRINT_FP, NULL, "ttl %s ", "inherit");
+ } else if (tb[IFLA_VXLAN_TTL]) {
+ ttl = rta_getattr_u8(tb[IFLA_VXLAN_TTL]);
+ if (is_json_context() || ttl)
+ print_uint(PRINT_ANY, "ttl", "ttl %u ", ttl);
+ else
+ print_string(PRINT_FP, NULL, "ttl %s ", "auto");
+ }
if (tb[IFLA_VXLAN_LABEL]) {
__u32 label = rta_getattr_u32(tb[IFLA_VXLAN_LABEL]);
--
2.5.5
^ permalink raw reply related
* [PATCH iproute2-next] geneve: fix ttl inherit behavior
From: Hangbin Liu @ 2018-09-27 7:27 UTC (permalink / raw)
To: netdev; +Cc: Stephen Hemminger, David Ahern, Phil Sutter, Hangbin Liu
Currently when we add geneve with "ttl inherit", we set ttl to 0, which
is actually use whatever default value instead of inherit the inner
protocol's ttl value.
To respect compatibility with old behavior and make a difference between
ttl inherit and ttl == 0, we add an attribute IFLA_GENEVE_TTL_INHERIT in
kernel commit 52d0d404d39dd ("geneve: add ttl inherit support").
Now let's use "ttl inherit" to inherit the inner protocol's ttl, and use
"ttl auto" to means "use whatever default value", the same behavior with
ttl == 0.
Reported-by: Jianlin Shi <jishi@redhat.com>
Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
---
include/uapi/linux/if_link.h | 1 +
ip/iplink_geneve.c | 20 +++++++++++++-------
2 files changed, 14 insertions(+), 7 deletions(-)
diff --git a/include/uapi/linux/if_link.h b/include/uapi/linux/if_link.h
index f4a9715..02d7bdf 100644
--- a/include/uapi/linux/if_link.h
+++ b/include/uapi/linux/if_link.h
@@ -552,6 +552,7 @@ enum {
IFLA_GENEVE_UDP_ZERO_CSUM6_TX,
IFLA_GENEVE_UDP_ZERO_CSUM6_RX,
IFLA_GENEVE_LABEL,
+ IFLA_GENEVE_TTL_INHERIT,
__IFLA_GENEVE_MAX
};
#define IFLA_GENEVE_MAX (__IFLA_GENEVE_MAX - 1)
diff --git a/ip/iplink_geneve.c b/ip/iplink_geneve.c
index 26e70ff..c417842 100644
--- a/ip/iplink_geneve.c
+++ b/ip/iplink_geneve.c
@@ -34,7 +34,7 @@ static void print_explain(FILE *f)
"Where: VNI := 0-16777215\n"
" ADDR := IP_ADDRESS\n"
" TOS := { NUMBER | inherit }\n"
- " TTL := { 1..255 | inherit }\n"
+ " TTL := { 1..255 | auto | inherit }\n"
" LABEL := 0-1048575\n"
);
}
@@ -94,7 +94,9 @@ static int geneve_parse_opt(struct link_util *lu, int argc, char **argv,
NEXT_ARG();
check_duparg(&attrs, IFLA_GENEVE_TTL, "ttl", *argv);
- if (strcmp(*argv, "inherit") != 0) {
+ if (strcmp(*argv, "inherit") == 0) {
+ addattr8(n, 1024, IFLA_GENEVE_TTL_INHERIT, 1);
+ } else if (strcmp(*argv, "auto") != 0) {
if (get_unsigned(&uval, *argv, 0))
invarg("invalid TTL", *argv);
if (uval > 255)
@@ -265,12 +267,16 @@ static void geneve_print_opt(struct link_util *lu, FILE *f, struct rtattr *tb[])
}
}
- if (tb[IFLA_GENEVE_TTL])
- ttl = rta_getattr_u8(tb[IFLA_GENEVE_TTL]);
- if (is_json_context() || ttl)
- print_uint(PRINT_ANY, "ttl", "ttl %u ", ttl);
- else
+ if (tb[IFLA_GENEVE_TTL_INHERIT] &&
+ rta_getattr_u8(tb[IFLA_GENEVE_TTL_INHERIT])) {
print_string(PRINT_FP, NULL, "ttl %s ", "inherit");
+ } else if (tb[IFLA_GENEVE_TTL]) {
+ ttl = rta_getattr_u8(tb[IFLA_GENEVE_TTL]);
+ if (is_json_context() || ttl)
+ print_uint(PRINT_ANY, "ttl", "ttl %u ", ttl);
+ else
+ print_string(PRINT_FP, NULL, "ttl %s ", "auto");
+ }
if (tb[IFLA_GENEVE_TOS])
tos = rta_getattr_u8(tb[IFLA_GENEVE_TOS]);
--
2.5.5
^ permalink raw reply related
* Re: KASAN: use-after-free Read in tcf_block_find
From: Dmitry Vyukov @ 2018-09-27 13:42 UTC (permalink / raw)
To: Eric Dumazet
Cc: Cong Wang, syzbot+37b8770e6d5a8220a039, David Miller,
Jamal Hadi Salim, Jiri Pirko, LKML,
Linux Kernel Network Developers, syzkaller-bugs
In-Reply-To: <10a02f06-2e6c-e70b-2766-012a835d3a57@gmail.com>
On Thu, Sep 27, 2018 at 3:24 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On 09/27/2018 06:02 AM, Dmitry Vyukov wrote:
>
>> I am not suggesting to commit this. This is just a hack for debugging.
>> It in fact lead to some warnings, but still allowed me to reproduce
>> the bug reliably.
>>
>
> Had you got more meaningful stack traces ?
>
> (Showing which context was actually doing the dst_release())
nope... I just handed off the instructions to Wei since she said she
can't reproduce it.
>>>> + dst_destroy_rcu(&dst->rcu_head);
>>>> + }
>>>> + }
>>>> }
>>>> }
>
> Thanks.
^ permalink raw reply
* RE: [PATCH v2 00/22] SMMU enablement for NXP LS1043A and LS1046A
From: Madalin-cristian Bucur @ 2018-09-27 13:39 UTC (permalink / raw)
To: Laurentiu Tudor, davem@davemloft.net
Cc: devicetree@vger.kernel.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, Roy Pledge,
shawnguo@kernel.org, Leo Li, robin.murphy@arm.com, Bharat Bhushan
In-Reply-To: <20180926132247.10971-1-laurentiu.tudor@nxp.com>
> -----Original Message-----
> From: laurentiu.tudor@nxp.com [mailto:laurentiu.tudor@nxp.com]
> Sent: Wednesday, September 26, 2018 4:22 PM
> To: devicetree@vger.kernel.org; netdev@vger.kernel.org; linux-
> kernel@vger.kernel.org; linux-arm-kernel@lists.infradead.org
> Cc: Roy Pledge <roy.pledge@nxp.com>; Madalin-cristian Bucur
> <madalin.bucur@nxp.com>; davem@davemloft.net; shawnguo@kernel.org; Leo Li
> <leoyang.li@nxp.com>; robin.murphy@arm.com; Bharat Bhushan
> <bharat.bhushan@nxp.com>; Laurentiu Tudor <laurentiu.tudor@nxp.com>
> Subject: [PATCH v2 00/22] SMMU enablement for NXP LS1043A and LS1046A
>
> From: Laurentiu Tudor <laurentiu.tudor@nxp.com>
>
> This patch series adds SMMU support for NXP LS1043A and LS1046A chips
> and consists mostly in important driver fixes and the required device
> tree updates. It touches several subsystems and consists of three main
> parts:
> - changes in soc/drivers/fsl/qbman drivers adding iommu mapping of
> reserved memory areas, fixes and defered probe support
> - changes in drivers/net/ethernet/freescale/dpaa_eth drivers
> consisting in misc dma mapping related fixes and probe ordering
> - addition of the actual arm smmu device tree node together with
> various adjustments to the device trees
>
> Performance impact
>
> Running iperf benchmarks in a back-to-back setup (both sides
> having smmu enabled) on a 10GBps port show an important
> networking performance degradation of around 40% (9.48Gbps
> linerate vs 5.45Gbps) and around 30%-35% with iommu.strict=1.
> If you need performance but without SMMU support you can use
> "iommu.passthrough=1" to disable SMMU.
>
> The patch set is based on net-next so, if generally agreed, I'd suggest
> to get the patches through the netdev tree after getting all the Acks.
>
> Changes in v2:
> - dropped confusing comments in smmu interrupt property (Robin)
> - add an intermediate simple-bus for usb to fix dma size issue (Robin)
> - use defines instead of numbers in smmu interrupt definition
> - drop redundant double iommu_get_domain_for_dev() call in few qbman
> patches
>
> Laurentiu Tudor (22):
> soc/fsl/qman: fixup liodns only on ppc targets
> soc/fsl/bman: map FBPR area in the iommu
> soc/fsl/qman: map FQD and PFDR areas in the iommu
> soc/fsl/qman-portal: map CENA area in the iommu
> soc/fsl/qbman: add APIs to retrieve the probing status
> soc/fsl/qman_portals: defer probe after qman's probe
> soc/fsl/bman_portals: defer probe after bman's probe
> soc/fsl/qbman_portals: add APIs to retrieve the probing status
> fsl/fman: backup and restore ICID registers
> fsl/fman: add API to get the device behind a fman port
> dpaa_eth: defer probing after qbman
> dpaa_eth: base dma mappings on the fman rx port
> dpaa_eth: fix iova handling for contiguous frames
> dpaa_eth: fix iova handling for sg frames
> dpaa_eth: fix SG frame cleanup
> arm64: dts: ls1046a: add smmu node
> arm64: dts: ls1043a: add smmu node
> arm64: dts: ls104xa: set mask to drop TBU ID from StreamID
> arm64: dts: ls104x: add missing dma ranges property
> arm64: dts: ls104x: add iommu-map to pci controllers
> arm64: dts: ls104x: make dma-coherent global to the SoC
> arm64: dts: ls104x: use a pseudo-bus to constrain usb dma size
>
> .../arm64/boot/dts/freescale/fsl-ls1043a.dtsi | 106 ++++++++++----
> .../arm64/boot/dts/freescale/fsl-ls1046a.dtsi | 102 ++++++++++---
> .../net/ethernet/freescale/dpaa/dpaa_eth.c | 136 ++++++++++++------
> drivers/net/ethernet/freescale/fman/fman.c | 35 ++++-
> drivers/net/ethernet/freescale/fman/fman.h | 4 +
> .../net/ethernet/freescale/fman/fman_port.c | 14 ++
> .../net/ethernet/freescale/fman/fman_port.h | 2 +
> drivers/soc/fsl/qbman/bman_ccsr.c | 22 +++
> drivers/soc/fsl/qbman/bman_portal.c | 20 ++-
> drivers/soc/fsl/qbman/qman_ccsr.c | 28 ++++
> drivers/soc/fsl/qbman/qman_portal.c | 35 +++++
> include/soc/fsl/bman.h | 16 +++
> include/soc/fsl/qman.h | 17 +++
> 13 files changed, 438 insertions(+), 99 deletions(-)
>
> --
> 2.17.1
For the fsl/fman and dpaa_eth:
Acked-by: Madalin Bucur <madalin.bucur@nxp.com>
Thank you
^ permalink raw reply
* Re: [PATCH] netlink: add policy attribute range validation
From: Michal Kubecek @ 2018-09-27 7:16 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, netdev
In-Reply-To: <1537994127.28767.39.camel@sipsolutions.net>
On Wed, Sep 26, 2018 at 10:35:27PM +0200, Johannes Berg wrote:
> On Wed, 2018-09-26 at 22:17 +0200, Johannes Berg wrote:
> > On Wed, 2018-09-26 at 22:06 +0200, Johannes Berg wrote:
> > > From: Johannes Berg <johannes.berg@intel.com>
> > >
> > > Without further bloating the policy structs, we can overload
> > > the `validation_data' pointer with a struct of s16 min, max
> > > and use those to validate ranges in NLA_{U,S}{8,16,32,64}
> > > attributes.
> > >
> > > It may sound strange to validate NLA_U32 with a s16 max, but
> > > in many cases NLA_U32 is used for enums etc. since there's no
> > > size benefit in using a smaller attribute width anyway, due
> > > to netlink attribute alignment; in cases like that it's still
> > > useful, particularly when the attribute really transports an
> > > enum value.
> >
> > That said, I did find a few places where we could benefit from a larger
> > type here - e.g. having a NLA_U16 that must be non-zero cannot be
> > represented in the policy as is, since you can't set max to 65535.
>
> We could also fix that, btw, by taking two bits out of the "type" field,
> and letting those indicate "check_min" and "check_max". That would also
> fix the other thing I noted regarding the union, I suppose.
>
> I didn't really like that too much because it makes the whole thing far
> more complex, but perhaps if we hide it behind macros like
>
> #define NLA_POLICY_RANGE(tp, _min, _max) {
> .type = tp,
> .min = _min, .check_min = 1,
> .max = _max, .check_max = 1,
> }
>
> #define NLA_POLICY_MIN(tp, _min) {
> .type = tp,
> .min = _min, .check_min = 1,
> }
>
> #define NLA_POLICY_MAX(tp, _max) {
> .type = tp,
> .max = _max, .check_max = 1,
> }
>
> it becomes more palatable?
The overloading still feels a bit complicated. Perhaps we could rather
use validation_data in the natural way, i.e. as a pointer to validation
data. That would be a struct (maybe array) of two values of the
corresponding type. It would mean a bit more data and a bit more writing
but it would be IMHO more straightforward.
Michal Kubecek
^ permalink raw reply
* [PATCH bpf-next] bpf: test_bpf: add dummy dev->net for flow_dissector
From: Song Liu @ 2018-09-27 7:15 UTC (permalink / raw)
To: netdev; +Cc: daniel, kernel-team, Song Liu, Willem de Bruijn, Petar Penkov
Latest changes in __skb_flow_dissect() assume skb->dev has valid nd_net.
However, this is not true for test_bpf. As a result, test_bpf.ko crashes
the system with the following stack trace:
[ 1133.716622] BUG: unable to handle kernel paging request at 0000000000001030
[ 1133.716623] PGD 8000001fbf7ee067
[ 1133.716624] P4D 8000001fbf7ee067
[ 1133.716624] PUD 1f6c1cf067
[ 1133.716625] PMD 0
[ 1133.716628] Oops: 0000 [#1] SMP PTI
[ 1133.716630] CPU: 7 PID: 40473 Comm: modprobe Kdump: loaded Not tainted 4.19.0-rc5-00805-gca11cc92ccd2 #1167
[ 1133.716631] Hardware name: Wiwynn Leopard-Orv2/Leopard-DDR BW, BIOS LBM12.5 12/06/2017
[ 1133.716638] RIP: 0010:__skb_flow_dissect+0x83/0x1680
[ 1133.716639] Code: 04 00 00 41 0f b7 44 24 04 48 85 db 4d 8d 14 07 0f 84 01 02 00 00 48 8b 43 10 48 85 c0 0f 84 e5 01 00 00 48 8b 80 a8 04 00 00 <48> 8b 90 30 10 00 00 48 85 d2 0f 84 dd 01 00 00 31 c0 b9 05 00 00
[ 1133.716640] RSP: 0018:ffffc900303c7a80 EFLAGS: 00010282
[ 1133.716642] RAX: 0000000000000000 RBX: ffff881fea0b7400 RCX: 0000000000000000
[ 1133.716643] RDX: ffffc900303c7bb4 RSI: ffffffff8235c3e0 RDI: ffff881fea0b7400
[ 1133.716643] RBP: ffffc900303c7b80 R08: 0000000000000000 R09: 000000000000000e
[ 1133.716644] R10: ffffc900303c7bb4 R11: ffff881fb6840400 R12: ffffffff8235c3e0
[ 1133.716645] R13: 0000000000000008 R14: 000000000000001e R15: ffffc900303c7bb4
[ 1133.716646] FS: 00007f54e75d3740(0000) GS:ffff881fff5c0000(0000) knlGS:0000000000000000
[ 1133.716648] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 1133.716649] CR2: 0000000000001030 CR3: 0000001f6c226005 CR4: 00000000003606e0
[ 1133.716649] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 1133.716650] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 1133.716651] Call Trace:
[ 1133.716660] ? sched_clock_cpu+0xc/0xa0
[ 1133.716662] ? sched_clock_cpu+0xc/0xa0
[ 1133.716665] ? log_store+0x1b5/0x260
[ 1133.716667] ? up+0x12/0x60
[ 1133.716669] ? skb_get_poff+0x4b/0xa0
[ 1133.716674] ? __kmalloc_reserve.isra.47+0x2e/0x80
[ 1133.716675] skb_get_poff+0x4b/0xa0
[ 1133.716680] bpf_skb_get_pay_offset+0xa/0x10
[ 1133.716686] ? test_bpf_init+0x578/0x1000 [test_bpf]
[ 1133.716690] ? netlink_broadcast_filtered+0x153/0x3d0
[ 1133.716695] ? free_pcppages_bulk+0x324/0x600
[ 1133.716696] ? 0xffffffffa0279000
[ 1133.716699] ? do_one_initcall+0x46/0x1bd
[ 1133.716704] ? kmem_cache_alloc_trace+0x144/0x1a0
[ 1133.716709] ? do_init_module+0x5b/0x209
[ 1133.716712] ? load_module+0x2136/0x25d0
[ 1133.716715] ? __do_sys_finit_module+0xba/0xe0
[ 1133.716717] ? __do_sys_finit_module+0xba/0xe0
[ 1133.716719] ? do_syscall_64+0x48/0x100
[ 1133.716724] ? entry_SYSCALL_64_after_hwframe+0x44/0xa9
This patch fixes tes_bpf by adding a dummy struct net to the dummy dev.
Fixes: d0e13a1488ad ("flow_dissector: lookup netns by skb->sk if skb->dev is NULL")
Fixes: d58e468b1112 ("flow_dissector: implements flow dissector BPF hook")
Cc: Willem de Bruijn <willemb@google.com>
Cc: Petar Penkov <ppenkov@google.com>
Signed-off-by: Song Liu <songliubraving@fb.com>
---
lib/test_bpf.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/lib/test_bpf.c b/lib/test_bpf.c
index 08d3d59dca17..5e29d4bd06c8 100644
--- a/lib/test_bpf.c
+++ b/lib/test_bpf.c
@@ -6470,6 +6470,7 @@ static struct bpf_test tests[] = {
},
};
+static struct net net;
static struct net_device dev;
static struct sk_buff *populate_skb(char *buf, int size)
@@ -6494,6 +6495,8 @@ static struct sk_buff *populate_skb(char *buf, int size)
skb->queue_mapping = SKB_QUEUE_MAP;
skb->vlan_tci = SKB_VLAN_TCI;
skb->vlan_proto = htons(ETH_P_IP);
+ dev_net_set(&dev, &net);
+ RCU_INIT_POINTER(net.flow_dissector_prog, NULL);
skb->dev = &dev;
skb->dev->ifindex = SKB_DEV_IFINDEX;
skb->dev->type = SKB_DEV_TYPE;
--
2.17.1
^ permalink raw reply related
* Re: [PATCH net-next v6 07/23] zinc: ChaCha20 ARM and ARM64 implementations
From: Jason A. Donenfeld @ 2018-09-27 13:26 UTC (permalink / raw)
To: Thomas Gleixner
Cc: Ard Biesheuvel, LKML, Netdev, Linux Crypto Mailing List,
David Miller, Greg Kroah-Hartman, Samuel Neves, Andrew Lutomirski,
Jean-Philippe Aumasson, Russell King - ARM Linux,
linux-arm-kernel
In-Reply-To: <CAHmME9qNn5aRgtbV3bAsz3xW1A49a7RMMkOzGruBUPzLVUxVNg@mail.gmail.com>
Hi Thomas,
I'm trying to optimize this for crypto performance while still taking
into account preemption concerns. I'm having a bit of trouble figuring
out a way to determine numerically what the upper bounds for this
stuff looks like. I'm sure I could pick a pretty sane number that's
arguably okay -- and way under the limit -- but I still am interested
in determining what that limit actually is. I was hoping there'd be a
debugging option called, "warn if preemption is disabled for too
long", or something, but I couldn't find anything like that. I'm also
not quite sure what the latency limits are, to just compute this with
a formula. Essentially what I'm trying to determine is:
preempt_disable();
asm volatile(".fill N, 1, 0x90;");
preempt_enable();
What is the maximum value of N for which the above is okay? What
technique would you generally use in measuring this?
Thanks,
Jason
^ permalink raw reply
* Re: [PATCH 1/2] net: dpaa2: move DPAA2 PTP driver out of staging/
From: Andrew Lunn @ 2018-09-27 13:25 UTC (permalink / raw)
To: Yangbo Lu
Cc: linux-kernel, devel, netdev, Richard Cochran, David S . Miller,
Ioana Radulescu, Greg Kroah-Hartman
In-Reply-To: <20180927111228.46118-1-yangbo.lu@nxp.com>
On Thu, Sep 27, 2018 at 07:12:27PM +0800, Yangbo Lu wrote:
> This patch is to move DPAA2 PTP driver out of staging/
> since the dpaa2-eth had been moved out.
>
> Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com>
> ---
> drivers/net/ethernet/freescale/Kconfig | 9 +--------
> drivers/net/ethernet/freescale/dpaa2/Kconfig | 15 +++++++++++++++
> drivers/net/ethernet/freescale/dpaa2/Makefile | 6 ++++--
> .../ethernet/freescale/dpaa2}/dprtc-cmd.h | 0
> .../rtc => net/ethernet/freescale/dpaa2}/dprtc.c | 0
> .../rtc => net/ethernet/freescale/dpaa2}/dprtc.h | 0
> .../rtc => net/ethernet/freescale/dpaa2}/rtc.c | 0
> .../rtc => net/ethernet/freescale/dpaa2}/rtc.h | 0
> drivers/staging/fsl-dpaa2/Kconfig | 8 --------
> drivers/staging/fsl-dpaa2/Makefile | 1 -
> drivers/staging/fsl-dpaa2/rtc/Makefile | 7 -------
> 11 files changed, 20 insertions(+), 26 deletions(-)
> create mode 100644 drivers/net/ethernet/freescale/dpaa2/Kconfig
> rename drivers/{staging/fsl-dpaa2/rtc => net/ethernet/freescale/dpaa2}/dprtc-cmd.h (100%)
> rename drivers/{staging/fsl-dpaa2/rtc => net/ethernet/freescale/dpaa2}/dprtc.c (100%)
> rename drivers/{staging/fsl-dpaa2/rtc => net/ethernet/freescale/dpaa2}/dprtc.h (100%)
> rename drivers/{staging/fsl-dpaa2/rtc => net/ethernet/freescale/dpaa2}/rtc.c (100%)
> rename drivers/{staging/fsl-dpaa2/rtc => net/ethernet/freescale/dpaa2}/rtc.h (100%)
Hi Yangbo
Calling a ptp driver rtc.[ch] seems rather odd. Could you fixup the
name, change it to ptp.[ch]. Also, some of the function names, and
structures, rtc_probe->ptp_probe, rtc_remove->ptp_remove,
rtc_match_id_table-> ptp_match_id_table, etc.
ptp_dpaa2_adjfreq() probably should return err, not 0.
ptp_dpaa2_gettime() again does not return the error.
If fact, it seems like all the main functions ignore errors.
kzalloc() could be changed to devm_kzalloc() to simplify the cleanup
Can ptp_dpaa2_caps be made const?
dpaa2_phc_index does not appear to be used.
dev_set_drvdata(dev, NULL); is not needed.
Can rtc_drv be made const?
Is rtc.h used by anything other than rtc.c? It seems like it can be removed.
It seems like there is a lot of code in dprtc.c which is unused. rtc.c
does nothing with interrupts for example. Do you plan to make use of
this extra code? Or can it be removed leaving just what is needed?
struct dprtc_cmd_get_irq - Putting pad at the beginning of a struct
seems very odd. And it is not the only example.
Andrew
^ permalink raw reply
* Re: KASAN: use-after-free Read in tcf_block_find
From: Eric Dumazet @ 2018-09-27 13:24 UTC (permalink / raw)
To: Dmitry Vyukov, Eric Dumazet
Cc: Cong Wang, syzbot+37b8770e6d5a8220a039, David Miller,
Jamal Hadi Salim, Jiri Pirko, LKML,
Linux Kernel Network Developers, syzkaller-bugs
In-Reply-To: <CACT4Y+ZvoVsL_BjBWr7QPnXOPGXqkqKfo-NQcox7vaAFPWVUVg@mail.gmail.com>
On 09/27/2018 06:02 AM, Dmitry Vyukov wrote:
> I am not suggesting to commit this. This is just a hack for debugging.
> It in fact lead to some warnings, but still allowed me to reproduce
> the bug reliably.
>
Had you got more meaningful stack traces ?
(Showing which context was actually doing the dst_release())
>>> + dst_destroy_rcu(&dst->rcu_head);
>>> + }
>>> + }
>>> }
>>> }
Thanks.
^ permalink raw reply
* Re: KASAN: use-after-free Read in tcf_block_find
From: Dmitry Vyukov @ 2018-09-27 13:02 UTC (permalink / raw)
To: Eric Dumazet
Cc: Cong Wang, syzbot+37b8770e6d5a8220a039, David Miller,
Jamal Hadi Salim, Jiri Pirko, LKML,
Linux Kernel Network Developers, syzkaller-bugs
In-Reply-To: <de41f26b-efe6-9985-cf38-169c18791cd6@gmail.com>
On Thu, Sep 27, 2018 at 3:00 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>
>
> On 09/27/2018 01:10 AM, Dmitry Vyukov wrote:
>
>>
>> Would a stack trace for call_rcu be helpful here? I have this idea for
>> a long time, but never get around to implementing it:
>> https://bugzilla.kernel.org/show_bug.cgi?id=198437
>>
>> Also FWIW I recently used the following hack for another net bug. It
>> made that other bug involving call_rcu way more likely to fire. Maybe
>> it will be helpful here too.
>>
>> diff --git a/net/core/dst.c b/net/core/dst.c
>> index 81ccf20e28265..591a8d0aca545 100644
>> --- a/net/core/dst.c
>> +++ b/net/core/dst.c
>> @@ -187,8 +187,16 @@ void dst_release(struct dst_entry *dst)
>> if (unlikely(newrefcnt < 0))
>> net_warn_ratelimited("%s: dst:%p refcnt:%d\n",
>> __func__, dst, newrefcnt);
>> - if (!newrefcnt)
>> - call_rcu(&dst->rcu_head, dst_destroy_rcu);
>> + if (!newrefcnt) {
>> + if (lock_is_held(&rcu_bh_lock_map) ||
>> + lock_is_held(&rcu_lock_map) ||
>> + lock_is_held(&rcu_sched_lock_map)) {
>> + call_rcu(&dst->rcu_head, dst_destroy_rcu);
>> + } else {
>> + synchronize_rcu();
>
> dst_release() can be called in context we hold a spinlock, this would be bad to reschedule here.
I am not suggesting to commit this. This is just a hack for debugging.
It in fact lead to some warnings, but still allowed me to reproduce
the bug reliably.
>> + dst_destroy_rcu(&dst->rcu_head);
>> + }
>> + }
>> }
>> }
^ permalink raw reply
* Re: KASAN: use-after-free Read in tcf_block_find
From: Eric Dumazet @ 2018-09-27 13:00 UTC (permalink / raw)
To: Dmitry Vyukov, Cong Wang
Cc: Eric Dumazet, syzbot+37b8770e6d5a8220a039, David Miller,
Jamal Hadi Salim, Jiri Pirko, LKML,
Linux Kernel Network Developers, syzkaller-bugs
In-Reply-To: <CACT4Y+YbQbZ7XTPK1HLvPiR9rmSm7Cz0H2LJAFfYfAta1Y3CiQ@mail.gmail.com>
On 09/27/2018 01:10 AM, Dmitry Vyukov wrote:
>
> Would a stack trace for call_rcu be helpful here? I have this idea for
> a long time, but never get around to implementing it:
> https://bugzilla.kernel.org/show_bug.cgi?id=198437
>
> Also FWIW I recently used the following hack for another net bug. It
> made that other bug involving call_rcu way more likely to fire. Maybe
> it will be helpful here too.
>
> diff --git a/net/core/dst.c b/net/core/dst.c
> index 81ccf20e28265..591a8d0aca545 100644
> --- a/net/core/dst.c
> +++ b/net/core/dst.c
> @@ -187,8 +187,16 @@ void dst_release(struct dst_entry *dst)
> if (unlikely(newrefcnt < 0))
> net_warn_ratelimited("%s: dst:%p refcnt:%d\n",
> __func__, dst, newrefcnt);
> - if (!newrefcnt)
> - call_rcu(&dst->rcu_head, dst_destroy_rcu);
> + if (!newrefcnt) {
> + if (lock_is_held(&rcu_bh_lock_map) ||
> + lock_is_held(&rcu_lock_map) ||
> + lock_is_held(&rcu_sched_lock_map)) {
> + call_rcu(&dst->rcu_head, dst_destroy_rcu);
> + } else {
> + synchronize_rcu();
dst_release() can be called in context we hold a spinlock, this would be bad to reschedule here.
> + dst_destroy_rcu(&dst->rcu_head);
> + }
> + }
> }
> }
>
^ permalink raw reply
* [PATCH net-next] qed: Remove set but not used variable 'p_archipelago'
From: YueHaibing @ 2018-09-27 6:45 UTC (permalink / raw)
To: Ariel Elior, David S. Miller
Cc: YueHaibing, everest-linux-l2, netdev, kernel-janitors
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/net/ethernet/qlogic/qed/qed_ooo.c: In function 'qed_ooo_delete_isles':
drivers/net/ethernet/qlogic/qed/qed_ooo.c:354:30: warning:
variable 'p_archipelago' set but not used [-Wunused-but-set-variable]
drivers/net/ethernet/qlogic/qed/qed_ooo.c: In function 'qed_ooo_join_isles':
drivers/net/ethernet/qlogic/qed/qed_ooo.c:463:30: warning:
variable 'p_archipelago' set but not used [-Wunused-but-set-variable]
Since commit 1eec2437d14c ("qed: Make OOO archipelagos into an array"),
'p_archipelago' is no longer in use.
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
drivers/net/ethernet/qlogic/qed/qed_ooo.c | 4 ----
1 file changed, 4 deletions(-)
diff --git a/drivers/net/ethernet/qlogic/qed/qed_ooo.c b/drivers/net/ethernet/qlogic/qed/qed_ooo.c
index 63931df..ffac4ac 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_ooo.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_ooo.c
@@ -351,11 +351,9 @@ void qed_ooo_delete_isles(struct qed_hwfn *p_hwfn,
struct qed_ooo_info *p_ooo_info,
u32 cid, u8 drop_isle, u8 drop_size)
{
- struct qed_ooo_archipelago *p_archipelago = NULL;
struct qed_ooo_isle *p_isle = NULL;
u8 isle_idx;
- p_archipelago = qed_ooo_seek_archipelago(p_hwfn, p_ooo_info, cid);
for (isle_idx = 0; isle_idx < drop_size; isle_idx++) {
p_isle = qed_ooo_seek_isle(p_hwfn, p_ooo_info, cid, drop_isle);
if (!p_isle) {
@@ -460,7 +458,6 @@ void qed_ooo_add_new_buffer(struct qed_hwfn *p_hwfn,
void qed_ooo_join_isles(struct qed_hwfn *p_hwfn,
struct qed_ooo_info *p_ooo_info, u32 cid, u8 left_isle)
{
- struct qed_ooo_archipelago *p_archipelago = NULL;
struct qed_ooo_isle *p_right_isle = NULL;
struct qed_ooo_isle *p_left_isle = NULL;
@@ -473,7 +470,6 @@ void qed_ooo_join_isles(struct qed_hwfn *p_hwfn,
return;
}
- p_archipelago = qed_ooo_seek_archipelago(p_hwfn, p_ooo_info, cid);
list_del(&p_right_isle->list_entry);
p_ooo_info->cur_isles_number--;
if (left_isle) {
^ permalink raw reply related
* [PATCH net V2] vhost-vsock: fix use after free
From: Jason Wang @ 2018-09-27 12:22 UTC (permalink / raw)
To: stefanha, mst
Cc: kvm, virtualization, netdev, linux-kernel, sergei.shtylyov,
Jason Wang
The access of vsock is not protected by vhost_vsock_lock. This may
lead to use after free since vhost_vsock_dev_release() may free the
pointer at the same time.
Fix this by holding the lock during the access.
Reported-by: syzbot+e3e074963495f92a89ed@syzkaller.appspotmail.com
Fixes: 16320f363ae1 ("vhost-vsock: add pkt cancel capability")
Fixes: 433fc58e6bf2 ("VSOCK: Introduce vhost_vsock.ko")
Cc: Stefan Hajnoczi <stefanha@redhat.com>
Signed-off-by: Jason Wang <jasowang@redhat.com>
---
- V2: fix typos
- The patch is needed for -stable.
---
drivers/vhost/vsock.c | 26 +++++++++++++++++++-------
1 file changed, 19 insertions(+), 7 deletions(-)
diff --git a/drivers/vhost/vsock.c b/drivers/vhost/vsock.c
index 34bc3ab40c6d..7d0b292867fd 100644
--- a/drivers/vhost/vsock.c
+++ b/drivers/vhost/vsock.c
@@ -210,21 +210,27 @@ vhost_transport_send_pkt(struct virtio_vsock_pkt *pkt)
struct vhost_vsock *vsock;
int len = pkt->len;
+ spin_lock_bh(&vhost_vsock_lock);
+
/* Find the vhost_vsock according to guest context id */
- vsock = vhost_vsock_get(le64_to_cpu(pkt->hdr.dst_cid));
+ vsock = __vhost_vsock_get(le64_to_cpu(pkt->hdr.dst_cid));
if (!vsock) {
virtio_transport_free_pkt(pkt);
+ spin_unlock_bh(&vhost_vsock_lock);
return -ENODEV;
}
if (pkt->reply)
atomic_inc(&vsock->queued_replies);
- spin_lock_bh(&vsock->send_pkt_list_lock);
+ spin_lock(&vsock->send_pkt_list_lock);
list_add_tail(&pkt->list, &vsock->send_pkt_list);
- spin_unlock_bh(&vsock->send_pkt_list_lock);
+ spin_unlock(&vsock->send_pkt_list_lock);
vhost_work_queue(&vsock->dev, &vsock->send_pkt_work);
+
+ spin_unlock_bh(&vhost_vsock_lock);
+
return len;
}
@@ -236,18 +242,22 @@ vhost_transport_cancel_pkt(struct vsock_sock *vsk)
int cnt = 0;
LIST_HEAD(freeme);
+ spin_lock_bh(&vhost_vsock_lock);
+
/* Find the vhost_vsock according to guest context id */
- vsock = vhost_vsock_get(vsk->remote_addr.svm_cid);
- if (!vsock)
+ vsock = __vhost_vsock_get(vsk->remote_addr.svm_cid);
+ if (!vsock) {
+ spin_unlock_bh(&vhost_vsock_lock);
return -ENODEV;
+ }
- spin_lock_bh(&vsock->send_pkt_list_lock);
+ spin_lock(&vsock->send_pkt_list_lock);
list_for_each_entry_safe(pkt, n, &vsock->send_pkt_list, list) {
if (pkt->vsk != vsk)
continue;
list_move(&pkt->list, &freeme);
}
- spin_unlock_bh(&vsock->send_pkt_list_lock);
+ spin_unlock(&vsock->send_pkt_list_lock);
list_for_each_entry_safe(pkt, n, &freeme, list) {
if (pkt->reply)
@@ -265,6 +275,8 @@ vhost_transport_cancel_pkt(struct vsock_sock *vsk)
vhost_poll_queue(&tx_vq->poll);
}
+ spin_unlock_bh(&vhost_vsock_lock);
+
return 0;
}
--
2.17.1
^ permalink raw reply related
* Re: [PATCH net] vhost-vsock: fix use after free
From: Jason Wang @ 2018-09-27 12:21 UTC (permalink / raw)
To: Sergei Shtylyov, stefanha, mst; +Cc: kvm, virtualization, netdev, linux-kernel
In-Reply-To: <a413a8b4-302d-7fbc-092d-95e8aa421c4c@cogentembedded.com>
On 2018年09月27日 17:52, Sergei Shtylyov wrote:
> Hello!
>
> On 9/27/2018 11:43 AM, Jason Wang wrote:
>
> Just a couple of typos...
>
>> The access of vsock is not protected by vhost_vsock_lock. This may
>> lead use after free since vhost_vsock_dev_release() may free the
>
> Lead to use.
>
>> pointer at the same time.
>>
>> Fix this by holding the lock during the acess.
>
> Access.
>
>> Reported-by: syzbot+e3e074963495f92a89ed@syzkaller.appspotmail.com
>> Fixes: 16320f363ae1 ("vhost-vsock: add pkt cancel capability")
>> Fixes: 433fc58e6bf2 ("VSOCK: Introduce vhost_vsock.ko")
>> Cc: Stefan Hajnoczi <stefanha@redhat.com>
>> Signed-off-by: Jason Wang <jasowang@redhat.com>
> [...]
>
> MBR, Sergei
Let me post V2.
Thanks
^ permalink raw reply
* (sin asunto)
From: Mrs. Mavis Wanczyk @ 2018-09-27 4:53 UTC (permalink / raw)
--
Good Day,
I, Mavis Wanczyk donates $ 5 Million Dollars to you, from part of my
Powerball
Jackpot Lottery of $ 758 Million Dollars, respond with your details for
claims.
I await your earliest response and God Bless you.
Good luck,
Mavis Wanczyk.
^ permalink raw reply
* [PATCH 1/1] Update maintainers for bnx2/bnx2x/qlge/qlcnic drivers.
From: Sudarsana Reddy Kalluru @ 2018-09-27 4:57 UTC (permalink / raw)
To: davem; +Cc: netdev, Ameen.Rahman
Signed-off-by: Sudarsana Reddy Kalluru <Sudarsana.Kalluru@cavium.com>
Signed-off-by: Ameen Rahman <Ameen.Rahman@cavium.com>
---
MAINTAINERS | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 15565de..e941d1b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2956,7 +2956,6 @@ F: include/linux/bcm963xx_tag.h
BROADCOM BNX2 GIGABIT ETHERNET DRIVER
M: Rasesh Mody <rasesh.mody@cavium.com>
-M: Harish Patil <harish.patil@cavium.com>
M: Dept-GELinuxNICDev@cavium.com
L: netdev@vger.kernel.org
S: Supported
@@ -2977,6 +2976,7 @@ F: drivers/scsi/bnx2i/
BROADCOM BNX2X 10 GIGABIT ETHERNET DRIVER
M: Ariel Elior <ariel.elior@cavium.com>
+M: Sudarsana Kalluru <sudarsana.kalluru@cavium.com>
M: everest-linux-l2@cavium.com
L: netdev@vger.kernel.org
S: Supported
@@ -11982,7 +11982,7 @@ F: Documentation/scsi/LICENSE.qla4xxx
F: drivers/scsi/qla4xxx/
QLOGIC QLCNIC (1/10)Gb ETHERNET DRIVER
-M: Harish Patil <harish.patil@cavium.com>
+M: Shahed Shaikh <Shahed.Shaikh@cavium.com>
M: Manish Chopra <manish.chopra@cavium.com>
M: Dept-GELinuxNICDev@cavium.com
L: netdev@vger.kernel.org
@@ -11990,7 +11990,6 @@ S: Supported
F: drivers/net/ethernet/qlogic/qlcnic/
QLOGIC QLGE 10Gb ETHERNET DRIVER
-M: Harish Patil <harish.patil@cavium.com>
M: Manish Chopra <manish.chopra@cavium.com>
M: Dept-GELinuxNICDev@cavium.com
L: netdev@vger.kernel.org
--
1.8.3.1
^ permalink raw reply related
* Re: KMSAN: uninit-value in memcmp (2)
From: Vladis Dronov @ 2018-09-27 11:17 UTC (permalink / raw)
To: Dmitry Vyukov; +Cc: syzbot, syzkaller-bugs, LKML, Networking
In-Reply-To: <CACT4Y+a8_4=dmZavdmZjPOraqYAtjBB228TjurbwLKSgJ9+J7Q@mail.gmail.com>
Hello, Dmirty,
Thank you for the explanation of how syzkaller/syzbot works in this and
other emails. I understand that is it a complicated task to determine
and categorize bugs based on just crash dump and messages, and syzkaller
does a great job of doing so.
> Re __hw_addr_add_ex bug, as Alex noted the crash was detected _after_
> the fixing commit went in. So it's something new and different and
> can't be fixed by the older commit.
Indeed, you're right, there is another issue with tun/tap devices which
leads to this bug. I've posted a patch (https://lkml.org/lkml/2018/9/26/416)
to fix it.
I hope I did not do much damage, reporting previous fix as a fix for this bug,
as syzkaller will probably create another "KMSAN: uninit-value in <...>"
report.
Best regards,
Vladis Dronov | Red Hat, Inc. | Product Security Engineer
----- Original Message -----
> From: "Dmitry Vyukov" <dvyukov@google.com>
> To: "Alexander Potapenko" <glider@google.com>
> Cc: "Vladis Dronov" <vdronov@redhat.com>, "syzbot" <syzbot+d3402c47f680ff24b29c@syzkaller.appspotmail.com>,
> "syzkaller-bugs" <syzkaller-bugs@googlegroups.com>, "David Miller" <davem@davemloft.net>, "Eric Dumazet"
> <edumazet@google.com>, "LKML" <linux-kernel@vger.kernel.org>, "Networking" <netdev@vger.kernel.org>, "sunlianwen"
> <sunlw.fnst@cn.fujitsu.com>
> Sent: Monday, September 24, 2018 11:39:08 AM
> Subject: Re: KMSAN: uninit-value in memcmp (2)
>
> On Mon, Sep 24, 2018 at 8:53 AM, Alexander Potapenko <glider@google.com>
> wrote:
> > On Mon, Sep 24, 2018 at 12:09 AM Vladis Dronov <vdronov@redhat.com> wrote:
> >>
> >> Hello, Dmirty,
> >>
> >> Thank you for the reply. Can we please, discuss this further?
> > Hi Vladis,
> >> > You can see on dashboard that the last crash
> >> > for the second version (2) happened just few days ago. So this is a
> >> > different bug.
> > FWIW I've just double-checked that the reproducer provided by
> > syzkaller in the original message still triggers the report from the
> > original message in the latest KMSAN tree (which already contains the
> > __hw_addr_add_ex() fix from April).
> >> Well... yes and no. When I was looking at this bug (bug?id=088efeac32fd) I
> >> was looking
> >> at the report at "2018/05/09 18:55"
> >> (https://syzkaller.appspot.com/text?tag=CrashReport&x=141b707b800000),
> >> since it was the only report with a reproducer. This was my error.
> >>
> >> The error and the call trace in this report are:
> >>
> >> >>>
> >> BUG: KMSAN: uninit-value in memcmp+0x119/0x180 lib/string.c:861
> >> CPU: 0 PID: 38 Comm: kworker/0:1 Not tainted 4.17.0-rc3+ #88
> >> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> >> Google 01/01/2011
> >> Workqueue: ipv6_addrconf addrconf_dad_work
> >> Call Trace:
> >> __dump_stack lib/dump_stack.c:77 [inline]
> >> dump_stack+0x185/0x1d0 lib/dump_stack.c:113
> >> kmsan_report+0x142/0x240 mm/kmsan/kmsan.c:1067
> >> __msan_warning_32+0x6c/0xb0 mm/kmsan/kmsan_instr.c:683
> >> memcmp+0x119/0x180 lib/string.c:861
> >> __hw_addr_add_ex net/core/dev_addr_lists.c:61 [inline]
> >> __dev_mc_add+0x1fc/0x900 net/core/dev_addr_lists.c:670
> >> dev_mc_add+0x6d/0x80 net/core/dev_addr_lists.c:687
> >> igmp6_group_added+0x2db/0xa00 net/ipv6/mcast.c:662
> >> ipv6_dev_mc_inc+0xe9e/0x1130 net/ipv6/mcast.c:914
> >> addrconf_join_solict net/ipv6/addrconf.c:2103 [inline]
> >> addrconf_dad_begin net/ipv6/addrconf.c:3853 [inline]
> >> addrconf_dad_work+0x462/0x2a20 net/ipv6/addrconf.c:3979
> >> process_one_work+0x12c6/0x1f60 kernel/workqueue.c:2145
> >> worker_thread+0x113c/0x24f0 kernel/workqueue.c:2279
> >> kthread+0x539/0x720 kernel/kthread.c:239
> >> ret_from_fork+0x35/0x40 arch/x86/entry/entry_64.S:412
> >>
> >> Local variable description: ----buf@igmp6_group_added
> >> Variable was created at:
> >> igmp6_group_added+0x4a/0xa00 net/ipv6/mcast.c:650
> >> ipv6_dev_mc_inc+0xe9e/0x1130 net/ipv6/mcast.c:914
> >> <<<
> >>
> >> It is the same like in bug?id=3887c0d99aecb27d085180c5222d245d08a30806
> >> which, after some more test, made me believe these bugs are duplicate
> >> and are fixed by the same commit.
> >>
> >> But let's look at another report at "2018/09/12 21:00"
> >> (https://syzkaller.appspot.com/text?tag=CrashReport&x=14f99b71400000)
> >> at the bug (bug?id=088efeac32fd), the one you've mentioned as
> >> "the last crash for the second version (2) happened just few days ago".
> >>
> >> Its error and the call trace are completely different:
> >>
> >> >>>
> >> BUG: KMSAN: uninit-value in memcmp+0x11d/0x180 lib/string.c:863
> >> CPU: 0 PID: 6107 Comm: syz-executor4 Not tainted 4.19.0-rc3+ #45
> >> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> >> Google 01/01/2011
> >> Call Trace:
> >> __dump_stack lib/dump_stack.c:77 [inline]
> >> dump_stack+0x14b/0x190 lib/dump_stack.c:113
> >> kmsan_report+0x183/0x2b0 mm/kmsan/kmsan.c:956
> >> __msan_warning+0x70/0xc0 mm/kmsan/kmsan_instr.c:645
> >> memcmp+0x11d/0x180 lib/string.c:863
> >> dev_uc_add_excl+0x165/0x7b0 net/core/dev_addr_lists.c:464
> >> ndo_dflt_fdb_add net/core/rtnetlink.c:3463 [inline]
> >> rtnl_fdb_add+0x1081/0x1270 net/core/rtnetlink.c:3558
> >> rtnetlink_rcv_msg+0xa0b/0x1530 net/core/rtnetlink.c:4715
> >> netlink_rcv_skb+0x36e/0x5f0 net/netlink/af_netlink.c:2454
> >> rtnetlink_rcv+0x50/0x60 net/core/rtnetlink.c:4733
> >> netlink_unicast_kernel net/netlink/af_netlink.c:1317 [inline]
> >> netlink_unicast+0x1638/0x1720 net/netlink/af_netlink.c:1343
> >> netlink_sendmsg+0x1205/0x1290 net/netlink/af_netlink.c:1908
> >> sock_sendmsg_nosec net/socket.c:621 [inline]
> >> sock_sendmsg net/socket.c:631 [inline]
> >> ...
> >> Uninit was created at:
> >> ...
> >> slab_post_alloc_hook mm/slab.h:446 [inline]
> >> slab_alloc_node mm/slub.c:2718 [inline]
> >> __kmalloc_node_track_caller+0x9e7/0x1160 mm/slub.c:4351
> >> __kmalloc_reserve net/core/skbuff.c:138 [inline]
> >> __alloc_skb+0x2f5/0x9e0 net/core/skbuff.c:206
> >> alloc_skb include/linux/skbuff.h:996 [inline]
> >> netlink_alloc_large_skb net/netlink/af_netlink.c:1189 [inline]
> >> netlink_sendmsg+0xb49/0x1290 net/netlink/af_netlink.c:1883
> >> sock_sendmsg_nosec net/socket.c:621 [inline]
> >> sock_sendmsg net/socket.c:631 [inline]
> >> ___sys_sendmsg+0xe70/0x1290 net/socket.c:2114
> >> <<<
> >>
> >> This is a different bug. How come these 2 different reports for 2
> >> different
> >> bugs have ended in the same syzkaller report (bug?id=088efeac32fd) ?
> >
> > I suspect this is because syzbot used the top stack frame as the
> > report signature.
> > There's a mechanism to ignore frames like memcmp() in the reports, not
> > sure why didn't it work in this case (maybe it just wasn't in place at
> > the time the report happened).
> >> One bug is fixed by the "net: fix uninit-value in __hw_addr_add_ex()"
> >> commit,
> >> the second one is not, but they are still in the same syzkaller report.
> >>
> >> This was the reason of my confusion. I'm not sure how to fix this. If it
> >> is possible,
> >> probably we need to cancel/revoke "#syz fix: net: fix uninit-value in
> >> __hw_addr_add_ex()"
> >> for this syzkaller report (bug?id=088efeac32fd). And then "split" it into
> >> 2 or
> >> more different reports, but I'm not sure if this is possible.
> >>
> >> Probably, syzkaller needs to look deeper into the KMSAN reports to
> >> differentiate
> >> KMSAN errors happening because of different reasons.
> >>
> >> > On Sun, Sep 23, 2018 at 6:02 PM, Vladis Dronov <vdronov@redhat.com>
> >> > wrote:
> >> > > #syz fix: net: fix uninit-value in __hw_addr_add_ex()
> >> >
> >> > Hi Vladis,
> >> >
> >> > This can be fixed with "net: fix uninit-value in __hw_addr_add_ex()".
> >> > That commit landed in April, syzbot waited till the commit reached all
> >> > tested trees, and then closed the bug.
> >> > But the similar bug continued to happen, so syzbot created second
> >> > version of this bug (2). You can see on dashboard that the last crash
> >> > for the second version (2) happened just few days ago. So this is a
> >> > different bug.
>
>
> Precisely discriminating bugs (root causes) bases on crash text is
> generally undecidable problem, even for humans. We even can have
> literally equal crash texts, which are still different bugs. And we
> can have significantly differently looking crash texts, which are
> actually caused by the same root cause. syzbot extracts some
> "identity" string for each crash and than uses that string to
> discriminate crashes and sort them into bins. This identity string is
> what you see in email subject and bug title on dashboard. This method
> can have both false positives and false negatives, but works
> reasonably well in most cases and looks like the best practical
> option.
>
> For this exact instance (memcmp) we actually improved the analysis
> logic recently:
> https://github.com/google/syzkaller/commit/0e29942f77715486995d996f80f82742812d75a2#diff-abe1515f011fad2659ff218f9eea9ae1
> But this crash was analyzed and reported before the change. So if this
> crash happens again it should be reported as "in __hw_addr_add_ex"
> now.
>
> Re __hw_addr_add_ex bug, as Alex noted the crash was detected _after_
> the fixing commit went in. So it's something new and different and
> can't be fixed by the older commit.
>
> There are no general, single guideline as to what to do when several
> different bugs glued together into a single bug. Fixing at least one
> of them (any) in the context of the bug is good, fixing both is good
> too. When/if a bug is closed, new occurrences of similar crashes (the
> same identity string) will lead to creation of a new bug. So if we fix
> only one and close the bug, eventually the second one will lead to a
> new bug (won't be lost), now dedicated to this second crash.
>
> Now syzbot thinks that this bug is fixed/closed:
> https://syzkaller.appspot.com/bug?extid=d3402c47f680ff24b29c
> There is specifically no "undo" functionality, because it's inherently
> racy with creation of a new version of this bugs by new crashes. So if
> of these crashes will happen again, syzbot will open new bugs (now
> with better discriminated titles). We can wait for that. Or we can
> submit new fixes without waiting for new syzbot bugs (adding
> Reported-by to new commits referencing this bug should not do any
> harm).
>
> Hope this clarifies things a bit.
>
> Thanks
^ permalink raw reply
* [PATCH 2/2] MAINTAINERS: update files maintained under DPAA2 PTP/ETHERNET
From: Yangbo Lu @ 2018-09-27 11:12 UTC (permalink / raw)
To: linux-kernel, devel, netdev, Richard Cochran, David S . Miller,
Ioana Radulescu, Greg Kroah-Hartman
Cc: Yangbo Lu
In-Reply-To: <20180927111228.46118-1-yangbo.lu@nxp.com>
The files maintained under DPAA2 PTP/ETHERNET needs to
be updated since dpaa2 ptp driver had been moved into
drivers/net/ethernet/freescale/dpaa2/.
Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com>
---
MAINTAINERS | 11 ++++++++---
1 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 15565de..ba6f441 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4530,7 +4530,11 @@ DPAA2 ETHERNET DRIVER
M: Ioana Radulescu <ruxandra.radulescu@nxp.com>
L: netdev@vger.kernel.org
S: Maintained
-F: drivers/net/ethernet/freescale/dpaa2
+F: drivers/net/ethernet/freescale/dpaa2/dpaa2-eth*
+F: drivers/net/ethernet/freescale/dpaa2/dpni*
+F: drivers/net/ethernet/freescale/dpaa2/dpkg.h
+F: drivers/net/ethernet/freescale/dpaa2/Makefile
+F: drivers/net/ethernet/freescale/dpaa2/Kconfig
DPAA2 ETHERNET SWITCH DRIVER
M: Ioana Radulescu <ruxandra.radulescu@nxp.com>
@@ -4541,9 +4545,10 @@ F: drivers/staging/fsl-dpaa2/ethsw
DPAA2 PTP CLOCK DRIVER
M: Yangbo Lu <yangbo.lu@nxp.com>
-L: linux-kernel@vger.kernel.org
+L: netdev@vger.kernel.org
S: Maintained
-F: drivers/staging/fsl-dpaa2/rtc
+F: drivers/net/ethernet/freescale/dpaa2/rtc*
+F: drivers/net/ethernet/freescale/dpaa2/dprtc*
DPT_I2O SCSI RAID DRIVER
M: Adaptec OEM Raid Solutions <aacraid@microsemi.com>
--
1.7.1
^ permalink raw reply related
* Re: [PATCH v2 0/3] Add can support to RZ/G2M
From: Marc Kleine-Budde @ 2018-09-27 10:45 UTC (permalink / raw)
To: Fabrizio Castro, Wolfgang Grandegger, Rob Herring, Mark Rutland
Cc: David S. Miller, Sergei Shtylyov, Simon Horman, Magnus Damm,
Chris Paterson, linux-can, netdev, devicetree, linux-renesas-soc,
linux-kernel, Geert Uytterhoeven, Biju Das
In-Reply-To: <1536576195-11520-1-git-send-email-fabrizio.castro@bp.renesas.com>
[-- Attachment #1.1: Type: text/plain, Size: 532 bytes --]
On 09/10/2018 12:43 PM, Fabrizio Castro wrote:
> Dear All,
>
> this series contains all that's necessary to add CAN support
> for RZ/G2M (a.k.a. r8a774a1).
>
> v1-v2:
> * applied Geert's comments
Added 1/3 and 2/3 to linux-can.
Tnx.
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH] hv_netvsc: Make sure out channel is fully opened on send
From: Mohammed Gamal @ 2018-09-27 10:31 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Haiyang Zhang, Stephen Hemminger, netdev@vger.kernel.org,
otubo@redhat.com, linux-kernel@vger.kernel.org,
devel@linuxdriverproject.org, vkuznets
In-Reply-To: <20180927122355.470df119@shemminger-XPS-13-9360>
On Thu, 2018-09-27 at 12:23 +0200, Stephen Hemminger wrote:
> On Thu, 27 Sep 2018 10:57:05 +0200
> Mohammed Gamal <mgamal@redhat.com> wrote:
>
> > On Wed, 2018-09-26 at 17:13 +0000, Haiyang Zhang wrote:
> > > > -----Original Message-----
> > > > From: Mohammed Gamal <mgamal@redhat.com>
> > > > Sent: Wednesday, September 26, 2018 12:34 PM
> > > > To: Stephen Hemminger <sthemmin@microsoft.com>; netdev@vger.ker
> > > > nel.
> > > > org
> > > > Cc: KY Srinivasan <kys@microsoft.com>; Haiyang Zhang
> > > > <haiyangz@microsoft.com>; vkuznets <vkuznets@redhat.com>;
> > > > otubo@redhat.com; cavery <cavery@redhat.com>; linux-
> > > > kernel@vger.kernel.org; devel@linuxdriverproject.org; Mohammed
> > > > Gamal
> > > > <mgamal@redhat.com>
> > > > Subject: [PATCH] hv_netvsc: Make sure out channel is fully
> > > > opened
> > > > on send
> > > >
> > > > Dring high network traffic changes to network interface
> > > > parameters
> > > > such as
> > > > number of channels or MTU can cause a kernel panic with a NULL
> > > > pointer
> > > > dereference. This is due to netvsc_device_remove() being called
> > > > and
> > > > deallocating the channel ring buffers, which can then be
> > > > accessed
> > > > by
> > > > netvsc_send_pkt() before they're allocated on calling
> > > > netvsc_device_add()
> > > >
> > > > The patch fixes this problem by checking the channel state and
> > > > returning
> > > > ENODEV if not yet opened. We also move the call to
> > > > hv_ringbuf_avail_percent()
> > > > which may access the uninitialized ring buffer.
> > > >
> > > > Signed-off-by: Mohammed Gamal <mgamal@redhat.com>
> > > > ---
> > > > drivers/net/hyperv/netvsc.c | 7 ++++++-
> > > > 1 file changed, 6 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/drivers/net/hyperv/netvsc.c
> > > > b/drivers/net/hyperv/netvsc.c index
> > > > fe01e14..75f1b31 100644
> > > > --- a/drivers/net/hyperv/netvsc.c
> > > > +++ b/drivers/net/hyperv/netvsc.c
> > > > @@ -825,7 +825,12 @@ static inline int netvsc_send_pkt(
> > > > struct netdev_queue *txq = netdev_get_tx_queue(ndev,
> > > > packet->q_idx);
> > > > u64 req_id;
> > > > int ret;
> > > > - u32 ring_avail =
> > > > hv_get_avail_to_write_percent(&out_channel-
> > > > > outbound);
> > > >
> > > > + u32 ring_avail;
> > > > +
> > > > + if (out_channel->state != CHANNEL_OPENED_STATE)
> > > > + return -ENODEV;
> > > > +
> > > > + ring_avail =
> > > > hv_get_avail_to_write_percent(&out_channel-
> > > > > outbound);
> > >
> > > When you reproducing the NULL ptr panic, does your kernel include
> > > the
> > > following patch?
> > > hv_netvsc: common detach logic
> > > https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.g
> > > it/c
> > > ommit/?id=7b2ee50c0cd513a176a26a71f2989facdd75bfea
> > >
> >
> > Yes it is included. And the commit did reduce the occurrence of
> > this
> > race condition, but it still nevertheless occurs albeit rarely.
> >
> > > We call netif_tx_disable(ndev) and netif_device_detach(ndev)
> > > before
> > > doing the changes
> > > on MTU or #channels. So there should be no call to start_xmit()
> > > when
> > > channel is not ready.
> > >
> > > If you see the check for CHANNEL_OPENED_STATE is still necessary
> > > on
> > > upstream kernel (including
> > > the patch " common detach logic "), we should debug further on
> > > the
> > > code and find out the
> > > root cause.
> > >
> > > Thanks,
> > > - Haiyang
> > >
> >
> > _______________________________________________
> > devel mailing list
> > devel@linuxdriverproject.org
> > http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-
> > devel
>
> Is there some workload, that can be used to reproduce this?
> The stress test from Vitaly with changing parameters while running
> network traffic
> passes now.
>
> Can you reproduce this with the upstream current kernel?
>
> Adding the check in start xmit is still racy, and won't cure the
> problem.
>
> Another solution would be to add a grace period in the netvsc detach
> logic.
>
Steps to reproduce are listed here:
https://bugzilla.redhat.com/show_bug.cgi?id=1632653
We've also managed to reproduce the same issue upstream. It's more
likely to be reproduced on Windows 2012R2 than 2016.
Regards,
Mohammed
^ 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