* Re: [PATCHv2 net] sctp: check and update stream->out_curr when allocating stream_out
From: Tuxdriver @ 2019-01-29 18:58 UTC (permalink / raw)
To: Marcelo Ricardo Leitner, Xin Long; +Cc: network dev, linux-sctp, davem
In-Reply-To: <20190129120531.GC10665@localhost.localdomain>
I was initially under the impression that with Kent's repost, the radixtree
(which is what I think you meant by rhashtables) updates would be merged
imminently, but that doesn't seem to be the case. I'd really like to know
what the hold up there is, as that patch seems to have been stalled for
months. I hate the notion of breaking the radixtree patch, but if it's
status is indeterminate, then, yes, we probably need to go with xins patch
for the short term, and let Kent fix it up in due course.
Neil
On January 29, 2019 1:06:33 PM Marcelo Ricardo Leitner
<marcelo.leitner@gmail.com> wrote:
> On Thu, Nov 29, 2018 at 02:42:56PM +0800, Xin Long wrote:
>> Now when using stream reconfig to add out streams, stream->out
>> will get re-allocated, and all old streams' information will
>> be copied to the new ones and the old ones will be freed.
>>
>> So without stream->out_curr updated, next time when trying to
>> send from stream->out_curr stream, a panic would be caused.
>>
>> This patch is to check and update stream->out_curr when
>> allocating stream_out.
>>
>> v1->v2:
>> - define fa_index() to get elem index from stream->out_curr.
>>
>> Fixes: 5bbbbe32a431 ("sctp: introduce stream scheduler foundations")
>> Reported-by: Ying Xu <yinxu@redhat.com>
>> Reported-by: syzbot+e33a3a138267ca119c7d@syzkaller.appspotmail.com
>> Signed-off-by: Xin Long <lucien.xin@gmail.com>
>
> We are sort of mixing things up here. We have a bug on SCTP stack that
> triggers panics. As good practices recommends, the code should be as
> generic as possible and the SCTP-only was dropped in favor of a more
> generic one, fixing rhashtables instead. Okay. But then we discovered
> rhashtables are going away and we are now waiting on a restructing
> to fix the panic. That's not good, especially because it cannot and
> should not be backported into -stable trees.
>
> That said, we should not wait for the restructuring to _implicitly_
> fix the bug. We should pursuit both fixes here:
> - Apply this patch, to fix SCTP stack and allow it to be easily
> backportable.
> - Apply the generic fix, which is the restructuring, whenever it
> actually lands.
>
> Thoughts?
>
> Thanks,
> Marcelo
Sent with AquaMail for Android
https://www.mobisystems.com/aqua-mail
^ permalink raw reply
* Re: [PATCH net] net: tls: Save iv in tls_rec for async crypto requests
From: David Miller @ 2019-01-29 18:57 UTC (permalink / raw)
To: davejwatson; +Cc: netdev
In-Reply-To: <20190129172215.cnzhluzzqpj3l6sd@davejwatson-mba.local>
From: Dave Watson <davejwatson@fb.com>
Date: Tue, 29 Jan 2019 17:21:41 +0000
> I'd like to merge TLS1.3 support to net-next, which depends on this
> commit. Can we get a net->net-next merge when convenient? Thanks
Sure thing Dave, I'll let you know when that happens.
^ permalink raw reply
* Re: [PATCH net-next] cxgb4: cxgb4_tc_u32: use struct_size() in kvzalloc()
From: David Miller @ 2019-01-29 18:57 UTC (permalink / raw)
To: gustavo; +Cc: arjun, netdev, linux-kernel
In-Reply-To: <20190129170523.GA29824@embeddedor>
From: "Gustavo A. R. Silva" <gustavo@embeddedor.com>
Date: Tue, 29 Jan 2019 11:05:23 -0600
> One of the more common cases of allocation size calculations is finding the
> size of a structure that has a zero-sized array at the end, along with memory
> for some number of elements for that array. For example:
>
> struct foo {
> int stuff;
> struct boo entry[];
> };
>
> instance = kvzalloc(sizeof(struct foo) + count * sizeof(struct boo), GFP_KERNEL);
>
> Instead of leaving these open-coded and prone to type mistakes, we can now
> use the new struct_size() helper:
>
> instance = kvzalloc(struct_size(instance, entry, count), GFP_KERNEL);
>
> This code was detected with the help of Coccinelle.
>
> Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next] cxgb4: clip_tbl: Use struct_size() in kvzalloc()
From: David Miller @ 2019-01-29 18:57 UTC (permalink / raw)
To: gustavo; +Cc: arjun, netdev, linux-kernel
In-Reply-To: <20190129164444.GA27988@embeddedor>
From: "Gustavo A. R. Silva" <gustavo@embeddedor.com>
Date: Tue, 29 Jan 2019 10:44:44 -0600
> One of the more common cases of allocation size calculations is finding the
> size of a structure that has a zero-sized array at the end, along with memory
> for some number of elements for that array. For example:
>
> struct foo {
> int stuff;
> struct boo entry[];
> };
>
> instance = kvzalloc(sizeof(struct foo) + count * sizeof(struct boo), GFP_KERNEL);
>
> Instead of leaving these open-coded and prone to type mistakes, we can now
> use the new struct_size() helper:
>
> instance = kvzalloc(struct_size(instance, entry, count), GFP_KERNEL);
>
> This code was detected with the help of Coccinelle.
>
> Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Applied.
^ permalink raw reply
* Re: [PATCH] mwifiex: don't print error message on coex event
From: Brian Norris @ 2019-01-29 18:52 UTC (permalink / raw)
To: Stefan Agner
Cc: amit karwar, Nishant Sarmukadam, Ganapathi Bhat, huxinming820,
Kalle Valo, davem, linux-wireless, netdev, Linux Kernel
In-Reply-To: <20190128154310.17322-1-stefan@agner.ch>
On Mon, Jan 28, 2019 at 7:43 AM Stefan Agner <stefan@agner.ch> wrote:
>
> The BT coex event is not an error condition. Don't print an error
> message in this case. The same even in sta_event.c prints a
> message using the debug level already.
For some reason, that one (and a handful of others) uses dev_dbg()
instead of mwifiex_dbg() with an appropriate mask (e.g., EVENT). But
mwifiex_dbg() seems preferable for consistency.
> Signed-off-by: Stefan Agner <stefan@agner.ch>
Reviewed-by: Brian Norris <briannorris@chromium.org>
> ---
> drivers/net/wireless/marvell/mwifiex/uap_event.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/marvell/mwifiex/uap_event.c b/drivers/net/wireless/marvell/mwifiex/uap_event.c
> index e86217a6b9ca..ca759d9c0253 100644
> --- a/drivers/net/wireless/marvell/mwifiex/uap_event.c
> +++ b/drivers/net/wireless/marvell/mwifiex/uap_event.c
> @@ -300,7 +300,7 @@ int mwifiex_process_uap_event(struct mwifiex_private *priv)
> mwifiex_11h_handle_radar_detected(priv, adapter->event_skb);
> break;
> case EVENT_BT_COEX_WLAN_PARA_CHANGE:
> - dev_err(adapter->dev, "EVENT: BT coex wlan param update\n");
> + mwifiex_dbg(adapter, EVENT, "event: BT coex wlan param update\n");
> mwifiex_bt_coex_wlan_param_update_event(priv,
> adapter->event_skb);
> break;
> --
> 2.20.1
>
^ permalink raw reply
* Re: [PATCH] r8169: Load MAC address from device tree if present
From: Heiner Kallweit @ 2019-01-29 18:51 UTC (permalink / raw)
To: Thierry Reding
Cc: David S. Miller, Realtek linux nic maintainers, netdev,
devicetree, linux-kernel
In-Reply-To: <20190129174035.GA25929@ulmo>
On 29.01.2019 18:40, Thierry Reding wrote:
> On Fri, Jan 25, 2019 at 07:34:31PM +0100, Heiner Kallweit wrote:
>> On 25.01.2019 11:18, Thierry Reding wrote:
>>> From: Thierry Reding <treding@nvidia.com>
>>>
>>> If the system was booted using a device tree and if the device tree
>>> contains a MAC address, use it instead of reading one from the EEPROM.
>>> This is useful in situations where the EEPROM isn't properly programmed
>>> or where the firmware wants to override the existing MAC address.
>>>
>> I rarely see DT-configured boards with RTL8168 network. Do you add this
>> patch because of a specific board?
>> And you state "if EEPROM isn't properly programmed": Did you come across
>> such a case?
>
> We use these Realtek chips on some of our boards that customers can
> either purchase individually and integrate into their own designs or
> they can get the module as part of a product.
>
> In order to easily allow customers to reprogram the device (they may
> want to do that if integrating the module into their own products), a
> so-called ID EEPROM is part of the module that stores various bits of
> information. The ethernet MAC address is part of that EEPROM.
>
> Typically the ID EEPROM will contain a valid MAC address if the module
> is part of a product, but if customers purchase the module individually,
> it is expected that they use a MAC address from their own pool.
>
> Typically early boot firmware will load the MAC address from the EEPROM
> and store it in the ethernet device's device tree node so that the MAC
> address programmed into the ID EEPROM will be used by the ethernet
> device at runtime.
>
Thanks for the explanation.
>> In general the patch is fine with me, I just want to understand the
>> motivation. One further comment see inline.
>> As of today we already have the option to set a MAC from userspace
>> via ethtool.
>>
>>> Signed-off-by: Thierry Reding <treding@nvidia.com>
>>> ---
>>> Based on net-next.
>>>
>>> drivers/net/ethernet/realtek/r8169.c | 35 +++++++++++++++++-----------
>>> 1 file changed, 22 insertions(+), 13 deletions(-)
>>>
>>> diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c
>>> index f574b6b557f9..fd9edd643ca5 100644
>>> --- a/drivers/net/ethernet/realtek/r8169.c
>>> +++ b/drivers/net/ethernet/realtek/r8169.c
>>> @@ -6957,6 +6957,21 @@ static int rtl_alloc_irq(struct rtl8169_private *tp)
>>> return pci_alloc_irq_vectors(tp->pci_dev, 1, 1, flags);
>>> }
>>>
>> [...]
>>> @@ -7252,20 +7268,13 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
>>> u64_stats_init(&tp->rx_stats.syncp);
>>> u64_stats_init(&tp->tx_stats.syncp);
>>>
>>> - /* Get MAC address */
>>> - switch (tp->mac_version) {
>>> - u8 mac_addr[ETH_ALEN] __aligned(4);
>>> - case RTL_GIGA_MAC_VER_35 ... RTL_GIGA_MAC_VER_38:
>>> - case RTL_GIGA_MAC_VER_40 ... RTL_GIGA_MAC_VER_51:
>>> - *(u32 *)&mac_addr[0] = rtl_eri_read(tp, 0xe0, ERIAR_EXGMAC);
>>> - *(u16 *)&mac_addr[4] = rtl_eri_read(tp, 0xe4, ERIAR_EXGMAC);
>>> + /* get MAC address */
>>> + if (eth_platform_get_mac_address(&pdev->dev, mac_addr))
>>> + rtl_read_mac_address(tp, mac_addr);
>>> +
>>> + if (is_valid_ether_addr(mac_addr))
>>
>> Here array mac_addr may be uninitialized (if platform defines no MAC
>> and chip version is not covered by the switch statement).
>
> Good point. I can memset() mac_addr to make sure it is invalid, rather
> than undefined, for chip versions that are not covered.
>
An empty initializer would work as well.
> Thierry
>
Heiner
^ permalink raw reply
* Re: [PATCH 4/7] sh_eth: offload RX checksum on R8A7740
From: Geert Uytterhoeven @ 2019-01-29 18:20 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: netdev, David S. Miller, Linux-Renesas, Linux-sh list
In-Reply-To: <e43f07fd-1407-a87a-7fe5-67a522da9e19@cogentembedded.com>
Hi Sergei,
On Sun, Jan 27, 2019 at 6:41 PM Sergei Shtylyov
<sergei.shtylyov@cogentembedded.com> wrote:
> The R-Mobile A1 (R8A7740) SoC manual describes the Ether MAC's RX checksum
> offload the same way as it's implemented in the EtherAVB MAC...
>
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Thanks for your patch!
Running netperf as described in patch 2/7, perf tells me there's a reduction
for csum_partial from ca. 1.9% to 0.01%, so this feature seems to work.
Hence:
Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
However, while effective according to perf results, using ethtool to
enable/disable
the feature prints an error message:
root@armadillo:~# ethtool -K eth0 rx on
Cannot get device udp-fragmentation-offload settings: Operation not supported
Cannot get device udp-fragmentation-offload settings: Operation not supported
root@armadillo:~# ethtool -K eth0 rx off
Cannot get device udp-fragmentation-offload settings: Operation not supported
Cannot get device udp-fragmentation-offload settings: Operation not supported
root@armadillo:~#
Do you have any clue?
Does this needs testing on R-Mobile A1 with VLAN enabled, too, or is that
independent from the underlying sh-eth hardware version?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH] ath10k: snoc: remove set but not used variable 'ar_snoc'
From: Brian Norris @ 2019-01-29 18:12 UTC (permalink / raw)
To: YueHaibing; +Cc: Kalle Valo, ath10k, netdev, linux-wireless, kernel-janitors
In-Reply-To: <4b16caf3-9a25-99d0-5b35-f27d6e5a5c65@huawei.com>
On Mon, Jan 28, 2019 at 9:53 PM YueHaibing <yuehaibing@huawei.com> wrote:
>
> ping...
For some reason, your patch shows up as Deferred in patchwork:
https://patchwork.kernel.org/patch/10589789/
So the maintainers have accidentally (?) ignored it. I'm not what the
official suggestion is for that, but you might just resend.
In any case...
> On 2018/9/6 10:29, YueHaibing wrote:
> > From: Yue Haibing <yuehaibing@huawei.com>
> >
> > Fixes gcc '-Wunused-but-set-variable' warning:
> >
> > drivers/net/wireless/ath/ath10k/snoc.c: In function 'ath10k_snoc_tx_pipe_cleanup':
> > drivers/net/wireless/ath/ath10k/snoc.c:681:22: warning:
> > variable 'ar_snoc' set but not used [-Wunused-but-set-variable]
> >
> > Signed-off-by: Yue Haibing <yuehaibing@huawei.com>
...patch looks fine to me:
Reviewed-by: Brian Norris <briannorris@chromium.org>
^ permalink raw reply
* Re: [RFC PATCH net-next 6/6 v2] net/sched: act_ct: Add tc recirc id set/del support
From: Marcelo Leitner @ 2019-01-29 18:12 UTC (permalink / raw)
To: Paul Blakey
Cc: Guy Shattah, Aaron Conole, John Hurley, Simon Horman,
Justin Pettit, Gregory Rose, Eelco Chaudron, Flavio Leitner,
Florian Westphal, Jiri Pirko, Rashid Khan, Sushil Kulkarni,
Andy Gospodarek, Roi Dayan, Yossi Kuperman, Or Gerlitz,
Rony Efraim, davem@davemloft.net, netdev
In-Reply-To: <1548748926-23822-7-git-send-email-paulb@mellanox.com>
On Tue, Jan 29, 2019 at 10:02:06AM +0200, Paul Blakey wrote:
> Set or clears (free) the skb tc recirc id extension.
> If used with OVS, OVS can clear this recirc id after it reads it.
>
> Signed-off-by: Paul Blakey <paulb@mellanox.com>
> ---
> include/net/tc_act/tc_ct.h | 2 ++
> include/uapi/linux/tc_act/tc_ct.h | 2 ++
> net/sched/act_ct.c | 18 ++++++++++++++++++
> 3 files changed, 22 insertions(+)
>
> diff --git a/include/net/tc_act/tc_ct.h b/include/net/tc_act/tc_ct.h
> index 4a16375..6ea19d8 100644
> --- a/include/net/tc_act/tc_ct.h
> +++ b/include/net/tc_act/tc_ct.h
> @@ -16,6 +16,8 @@ struct tcf_ct {
> u32 mark_mask;
> u16 zone;
> bool commit;
> + uint32_t set_recirc;
> + bool del_recirc;
> };
>
> #define to_ct(a) ((struct tcf_ct *)a)
> diff --git a/include/uapi/linux/tc_act/tc_ct.h b/include/uapi/linux/tc_act/tc_ct.h
> index 6dbd771..2279a9b 100644
> --- a/include/uapi/linux/tc_act/tc_ct.h
> +++ b/include/uapi/linux/tc_act/tc_ct.h
> @@ -14,6 +14,8 @@ struct tc_ct {
> __u32 labels_mask[4];
> __u32 mark;
> __u32 mark_mask;
> + uint32_t set_recirc;
> + bool del_recirc;
> bool commit;
> };
Have you considered adding a specific action for this? Asking because
setting recirc_id can be useful outside of ct context too: decap, set
recirc_id, reclassify.
>
> diff --git a/net/sched/act_ct.c b/net/sched/act_ct.c
> index 61155cc..7822385 100644
> --- a/net/sched/act_ct.c
> +++ b/net/sched/act_ct.c
> @@ -117,6 +117,11 @@ static int tcf_ct_act(struct sk_buff *skb, const struct tc_action *a,
> u_int8_t family;
> bool cached;
>
> + if (ca->del_recirc) {
> + skb_ext_del(skb, SKB_EXT_TC_RECIRC_ID);
> + return ca->tcf_action;
> + }
> +
> /* The conntrack module expects to be working at L3. */
> nh_ofs = skb_network_offset(skb);
> skb_pull_rcsum(skb, nh_ofs);
> @@ -243,6 +248,15 @@ static int tcf_ct_act(struct sk_buff *skb, const struct tc_action *a,
> skb_postpush_rcsum(skb, skb->data, nh_ofs);
>
> spin_unlock(&ca->tcf_lock);
> +
> + if (ca->set_recirc) {
> + u32 recirc = ca->set_recirc;
> + uint32_t *recircp = skb_ext_add(skb, SKB_EXT_TC_RECIRC_ID);
> +
> + if (recircp)
> + *recircp = recirc;
> + }
> +
> return ca->tcf_action;
>
> drop:
> @@ -305,6 +319,8 @@ static int tcf_ct_init(struct net *net, struct nlattr *nla,
> ci->net = net;
> ci->commit = parm->commit;
> ci->zone = parm->zone;
> + ci->set_recirc = parm->set_recirc;
> + ci->del_recirc = parm->del_recirc;
> #if !IS_ENABLED(CONFIG_NF_CONNTRACK_MARK)
> if (parm->mark_mask) {
> NL_SET_ERR_MSG_MOD(extack, "Mark not supported by kernel config");
> @@ -378,6 +394,8 @@ static inline int tcf_ct_dump(struct sk_buff *skb, struct tc_action *a,
> opt.mark_mask = ci->mark_mask,
> memcpy(opt.labels, ci->labels, sizeof(opt.labels));
> memcpy(opt.labels_mask, ci->labels_mask, sizeof(opt.labels_mask));
> + opt.set_recirc = ci->set_recirc;
> + opt.del_recirc = ci->del_recirc;
>
> if (nla_put(skb, TCA_CT_PARMS, sizeof(opt), &opt))
> goto nla_put_failure;
> --
> 1.8.3.1
>
^ permalink raw reply
* Re: [PATCH net] net: b44: replace dev_kfree_skb_xxx by dev_consume_skb_xxx for drop profiles
From: David Miller @ 2019-01-29 18:11 UTC (permalink / raw)
To: albin_yang; +Cc: netdev, michael.chan, yang.wei9
In-Reply-To: <1548774280-5757-1-git-send-email-albin_yang@163.com>
From: Yang Wei <albin_yang@163.com>
Date: Tue, 29 Jan 2019 23:04:40 +0800
> From: Yang Wei <yang.wei9@zte.com.cn>
>
> The skb should be freed by dev_consume_skb_any() in b44_start_xmit()
> when bounce_skb is used. The skb is be replaced by bounce_skb, so the
> original skb should be consumed(not drop).
>
> dev_consume_skb_irq() should be called in b44_tx() when skb xmit
> done. It makes drop profiles(dropwatch, perf) more friendly.
>
> Signed-off-by: Yang Wei <yang.wei9@zte.com.cn>
Applied.
^ permalink raw reply
* Re: [PATCH net] net: caif: call dev_consume_skb_any when skb xmit done
From: David Miller @ 2019-01-29 18:11 UTC (permalink / raw)
To: albin_yang; +Cc: netdev, dmitry.tarnyagin, yang.wei9
In-Reply-To: <1548775942-6476-1-git-send-email-albin_yang@163.com>
From: Yang Wei <albin_yang@163.com>
Date: Tue, 29 Jan 2019 23:32:22 +0800
> From: Yang Wei <yang.wei9@zte.com.cn>
>
> The skb shouled be consumed when xmit done, it makes drop profiles
> (dropwatch, perf) more friendly.
> dev_kfree_skb_irq()/kfree_skb() shouled be replaced by
> dev_consume_skb_any(), it makes code cleaner.
>
> Signed-off-by: Yang Wei <yang.wei9@zte.com.cn>
Applied.
^ permalink raw reply
* Re: [PATCH 01/28] net: thunderbolt: Unregister ThunderboltIP protocol handler when suspending
From: David Miller @ 2019-01-29 18:10 UTC (permalink / raw)
To: mika.westerberg
Cc: linux-kernel, michael.jamet, YehezkelShB, andreas.noever, lukas,
andriy.shevchenko, netdev
In-Reply-To: <20190129150143.12681-2-mika.westerberg@linux.intel.com>
From: Mika Westerberg <mika.westerberg@linux.intel.com>
Date: Tue, 29 Jan 2019 18:01:16 +0300
> The XDomain protocol messages may start as soon as Thunderbolt control
> channel is started. This means that if the other host starts sending
> ThunderboltIP packets early enough they will be passed to the network
> driver which then gets confused because its resume hook is not called
> yet.
>
> Fix this by unregistering the ThunderboltIP protocol handler when
> suspending and registering it back on resume.
>
> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Acked-by: David S. Miller <davem@davemloft.net>
^ permalink raw reply
* Re: [RFC PATCH net-next 3/6 v2] net/sched: cls_flower: Add ematch support
From: Marcelo Leitner @ 2019-01-29 18:08 UTC (permalink / raw)
To: Paul Blakey
Cc: Guy Shattah, Aaron Conole, John Hurley, Simon Horman,
Justin Pettit, Gregory Rose, Eelco Chaudron, Flavio Leitner,
Florian Westphal, Jiri Pirko, Rashid Khan, Sushil Kulkarni,
Andy Gospodarek, Roi Dayan, Yossi Kuperman, Or Gerlitz,
Rony Efraim, davem@davemloft.net, netdev
In-Reply-To: <1548748926-23822-4-git-send-email-paulb@mellanox.com>
On Tue, Jan 29, 2019 at 10:02:03AM +0200, Paul Blakey wrote:
> TODO: handle EEXist.
>
> Signed-off-by: Paul Blakey <paulb@mellanox.com>
> ---
> include/uapi/linux/pkt_cls.h | 2 ++
> net/sched/cls_flower.c | 22 ++++++++++++++++++----
> 2 files changed, 20 insertions(+), 4 deletions(-)
>
> diff --git a/include/uapi/linux/pkt_cls.h b/include/uapi/linux/pkt_cls.h
> index 121f1ef..d848d6d 100644
> --- a/include/uapi/linux/pkt_cls.h
> +++ b/include/uapi/linux/pkt_cls.h
> @@ -506,6 +506,8 @@ enum {
> TCA_FLOWER_KEY_CT_LABELS,
> TCA_FLOWER_KEY_CT_LABELS_MASK,
>
> + TCA_FLOWER_EMATCHES,
> +
> __TCA_FLOWER_MAX,
> };
>
> diff --git a/net/sched/cls_flower.c b/net/sched/cls_flower.c
> index bf74a31..f11fda0 100644
> --- a/net/sched/cls_flower.c
> +++ b/net/sched/cls_flower.c
> @@ -104,6 +104,7 @@ struct cls_fl_filter {
> struct rhash_head ht_node;
> struct fl_flow_key mkey;
> struct tcf_exts exts;
> + struct tcf_ematch_tree ematches;
> struct tcf_result res;
> struct fl_flow_key key;
> struct list_head list;
> @@ -332,10 +333,14 @@ static int fl_classify(struct sk_buff *skb, const struct tcf_proto *tp,
> fl_set_masked_key(&skb_mkey, &skb_key, mask);
>
> f = fl_lookup(mask, &skb_mkey, &skb_key);
> - if (f && !tc_skip_sw(f->flags)) {
> - *res = f->res;
> - return tcf_exts_exec(skb, &f->exts, res);
> - }
> + if (!f || tc_skip_sw(f->flags))
> + continue;
> +
> + if (!tcf_em_tree_match(skb, &f->ematches, NULL))
> + continue;
Considering just the recirc_id (and not the other fields supported by
ematch), have you considered integrating recirc_id match on flow
dissector instead? It would avoid the matching in 2 steps here and
benefit from the hashing.
> +
> + *res = f->res;
> + return tcf_exts_exec(skb, &f->exts, res);
> }
> return -1;
> }
> @@ -388,6 +393,7 @@ static bool fl_mask_put(struct cls_fl_head *head, struct fl_flow_mask *mask,
> static void __fl_destroy_filter(struct cls_fl_filter *f)
> {
> tcf_exts_destroy(&f->exts);
> + tcf_em_tree_destroy(&f->ematches);
> tcf_exts_put_net(&f->exts);
> kfree(f);
> }
> @@ -523,6 +529,7 @@ static void *fl_get(struct tcf_proto *tp, u32 handle)
> static const struct nla_policy fl_policy[TCA_FLOWER_MAX + 1] = {
> [TCA_FLOWER_UNSPEC] = { .type = NLA_UNSPEC },
> [TCA_FLOWER_CLASSID] = { .type = NLA_U32 },
> + [TCA_FLOWER_EMATCHES] = { .type = NLA_NESTED },
> [TCA_FLOWER_INDEV] = { .type = NLA_STRING,
> .len = IFNAMSIZ },
> [TCA_FLOWER_KEY_ETH_DST] = { .len = ETH_ALEN },
> @@ -1348,6 +1355,10 @@ static int fl_set_parms(struct net *net, struct tcf_proto *tp,
> if (err < 0)
> return err;
>
> + err = tcf_em_tree_validate(tp, tb[TCA_FLOWER_EMATCHES], &f->ematches);
> + if (err < 0)
> + return err;
> +
> if (tb[TCA_FLOWER_CLASSID]) {
> f->res.classid = nla_get_u32(tb[TCA_FLOWER_CLASSID]);
> tcf_bind_filter(tp, &f->res, base);
> @@ -2143,6 +2154,9 @@ static int fl_dump(struct net *net, struct tcf_proto *tp, void *fh,
> nla_put_u32(skb, TCA_FLOWER_CLASSID, f->res.classid))
> goto nla_put_failure;
>
> + if (tcf_em_tree_dump(skb, &f->ematches, TCA_FLOWER_EMATCHES) < 0)
> + goto nla_put_failure;
> +
> key = &f->key;
> mask = &f->mask->key;
>
> --
> 1.8.3.1
>
^ permalink raw reply
* Re: [PATCH net] net: 8139cp: replace dev_kfree_skb_irq by dev_consume_skb_irq for drop profiles
From: David Miller @ 2019-01-29 18:07 UTC (permalink / raw)
To: albin_yang; +Cc: netdev, yang.wei9
In-Reply-To: <1548772851-4692-1-git-send-email-albin_yang@163.com>
From: Yang Wei <albin_yang@163.com>
Date: Tue, 29 Jan 2019 22:40:51 +0800
> From: Yang Wei <yang.wei9@zte.com.cn>
>
> dev_consume_skb_irq() should be called in cp_tx() when skb xmit
> done. It makes drop profiles(dropwatch, perf) more friendly.
>
> Signed-off-by: Yang Wei <yang.wei9@zte.com.cn>
Applied, thanks.
^ permalink raw reply
* Re: [RFC PATCH net-next 0/6 v2] connection tracking in tc and OVS offload
From: Marcelo Leitner @ 2019-01-29 18:07 UTC (permalink / raw)
To: Paul Blakey
Cc: Guy Shattah, Aaron Conole, John Hurley, Simon Horman,
Justin Pettit, Gregory Rose, Eelco Chaudron, Flavio Leitner,
Florian Westphal, Jiri Pirko, Rashid Khan, Sushil Kulkarni,
Andy Gospodarek, Roi Dayan, Yossi Kuperman, Or Gerlitz,
Rony Efraim, davem@davemloft.net, netdev
In-Reply-To: <1548748753-22540-1-git-send-email-paulb@mellanox.com>
On Tue, Jan 29, 2019 at 09:59:07AM +0200, Paul Blakey wrote:
> Hi,
> As you may know, we are working on connection tracking for a while, and we already
> had patches for tc that matched our connection tracking offload RFC.
>
> Marcelo already shared his tc patches for a similar action ct and flower match on ct_info state,
> and this patches are pretty close to his. We would like to share ours and see what's the difference
> so maybe we can merge the two.
>
> I think the main difference here is that we propose the usage of a new metadata that resembles
> ovs recirc id, so one can use tc recirculation in a similar way that ovs does.
This is a very interesting approach. Seems it can avoid the necessity
of offloading multiple chains at all and, with that, we don't need a
special fallback path for when chain X is not present in HW: it will
be just another miss. Such skb may have an extra meta data, but no
need to look for a special chain and so.
Two points on it for further discussion. I'll reply on the specific
patches.
>
> The plan is to support offloading of OVS rules to tc, so this recirculation id will
> be shared with and from OVS.
>
> The following is an example using the recirc id metadata (aa_rep and bb_rep are two veth devices)
>
> tc qdisc add dev bb_rep ingress
> tc qdisc add dev aa_rep ingress
> tc filter add dev aa_rep ingress prio 1 chain 0 proto ip flower match 'meta(tc_recirc mask 0xffffffff eq 0x1)' ct_state +trk+est ip_proto tcp action mirred egress redirect dev bb_rep
> tc filter add dev aa_rep ingress prio 1 chain 0 proto ip flower ct_state -trk ip_proto tcp action ct recirc 1 reclassify
> tc filter add dev aa_rep ingress prio 1 chain 0 proto ip flower match 'meta(tc_recirc mask 0xffffffff eq 0x1)' ct_state +trk+new ip_proto tcp action ct commit pipe action mirred egress redirect dev bb_rep
>
> tc filter add dev bb_rep ingress prio 1 chain 0 proto ip flower ct_state -trk ip_proto tcp action ct recirc 2 reclassify
> tc filter add dev bb_rep ingress prio 1 chain 0 proto ip flower match 'meta(tc_recirc mask 0xffffffff eq 0x2)' ct_state +trk+est ip_proto tcp action mirred egress redirect dev aa_rep
>
> of course, goto chain instead of reclassify will also work.
>
> There might be some difference in how we handle action ct and I'll follow up on that.
>
>
> Changelog:
> v1->v2:
> Missed first patch :|
> Added netdev mailing list
>
> Paul Blakey (6):
> net/sched: Introduce act_ct
> net/sched: cls_flower: add match on ct info
> net/sched: cls_flower: Add ematch support
> net: Add new tc recirc id skb extension
> net/sched: em_meta: add match on tc recirc id skb extension
> net/sched: act_ct: Add tc recirc id set/del support
>
> include/linux/skbuff.h | 1 +
> include/net/tc_act/tc_ct.h | 2 +
> include/uapi/linux/pkt_cls.h | 19 ++++
> include/uapi/linux/tc_act/tc_ct.h | 2 +
> include/uapi/linux/tc_ematch/tc_em_meta.h | 1 +
> net/core/skbuff.c | 2 +
> net/sched/act_ct.c | 18 ++++
> net/sched/cls_flower.c | 148 ++++++++++++++++++++++++++++--
> net/sched/em_meta.c | 8 ++
> 9 files changed, 194 insertions(+), 7 deletions(-)
>
> --
> 1.8.3.1
>
^ permalink raw reply
* [PATCH] can: mark expected switch fall-throughs
From: Gustavo A. R. Silva @ 2019-01-29 18:06 UTC (permalink / raw)
To: Wolfgang Grandegger, Marc Kleine-Budde, David S. Miller,
Nicolas Ferre, Alexandre Belloni, Ludovic Desroches
Cc: linux-can, netdev, linux-arm-kernel, linux-kernel,
Gustavo A. R. Silva
In preparation to enabling -Wimplicit-fallthrough, mark switch cases
where we are expecting to fall through.
This patch fixes the following warnings:
drivers/net/can/peak_canfd/peak_pciefd_main.c:668:3: warning: this statement may fall through [-Wimplicit-fallthrough=]
drivers/net/can/spi/mcp251x.c:875:7: warning: this statement may fall through [-Wimplicit-fallthrough=]
drivers/net/can/usb/peak_usb/pcan_usb.c:422:6: warning: this statement may fall through [-Wimplicit-fallthrough=]
drivers/net/can/at91_can.c:895:6: warning: this statement may fall through [-Wimplicit-fallthrough=]
drivers/net/can/at91_can.c:953:15: warning: this statement may fall through [-Wimplicit-fallthrough=]
drivers/net/can/usb/peak_usb/pcan_usb.c: In function ‘pcan_usb_decode_error’:
drivers/net/can/usb/peak_usb/pcan_usb.c:422:6: warning: this statement may fall through [-Wimplicit-fallthrough=]
if (n & PCAN_USB_ERROR_BUS_LIGHT) {
^
drivers/net/can/usb/peak_usb/pcan_usb.c:428:2: note: here
case CAN_STATE_ERROR_WARNING:
^~~~
Warning level 3 was used: -Wimplicit-fallthrough=3
This patch is part of the ongoing efforts to enabling
-Wimplicit-fallthrough.
Notice that in some cases spelling mistakes were fixed.
In other cases, the /* fall through */ comment is placed
at the bottom of the case statement, which is what GCC
is expecting to find.
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
---
drivers/net/can/at91_can.c | 6 ++++--
drivers/net/can/peak_canfd/peak_pciefd_main.c | 2 +-
drivers/net/can/spi/mcp251x.c | 3 ++-
drivers/net/can/usb/peak_usb/pcan_usb.c | 2 +-
4 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/net/can/at91_can.c b/drivers/net/can/at91_can.c
index d98c69045b17..1718c20f9c99 100644
--- a/drivers/net/can/at91_can.c
+++ b/drivers/net/can/at91_can.c
@@ -902,7 +902,8 @@ static void at91_irq_err_state(struct net_device *dev,
CAN_ERR_CRTL_TX_WARNING :
CAN_ERR_CRTL_RX_WARNING;
}
- case CAN_STATE_ERROR_WARNING: /* fallthrough */
+ /* fall through */
+ case CAN_STATE_ERROR_WARNING:
/*
* from: ERROR_ACTIVE, ERROR_WARNING
* to : ERROR_PASSIVE, BUS_OFF
@@ -951,7 +952,8 @@ static void at91_irq_err_state(struct net_device *dev,
netdev_dbg(dev, "Error Active\n");
cf->can_id |= CAN_ERR_PROT;
cf->data[2] = CAN_ERR_PROT_ACTIVE;
- case CAN_STATE_ERROR_WARNING: /* fallthrough */
+ /* fall through */
+ case CAN_STATE_ERROR_WARNING:
reg_idr = AT91_IRQ_ERRA | AT91_IRQ_WARN | AT91_IRQ_BOFF;
reg_ier = AT91_IRQ_ERRP;
break;
diff --git a/drivers/net/can/peak_canfd/peak_pciefd_main.c b/drivers/net/can/peak_canfd/peak_pciefd_main.c
index c458d5fdc8d3..e4f4d65a76b4 100644
--- a/drivers/net/can/peak_canfd/peak_pciefd_main.c
+++ b/drivers/net/can/peak_canfd/peak_pciefd_main.c
@@ -668,7 +668,7 @@ static int pciefd_can_probe(struct pciefd_board *pciefd)
pciefd_can_writereg(priv, CANFD_CLK_SEL_80MHZ,
PCIEFD_REG_CAN_CLK_SEL);
- /* fallthough */
+ /* fall through */
case CANFD_CLK_SEL_80MHZ:
priv->ucan.can.clock.freq = 80 * 1000 * 1000;
break;
diff --git a/drivers/net/can/spi/mcp251x.c b/drivers/net/can/spi/mcp251x.c
index e90817608645..17257c73c302 100644
--- a/drivers/net/can/spi/mcp251x.c
+++ b/drivers/net/can/spi/mcp251x.c
@@ -875,7 +875,8 @@ static irqreturn_t mcp251x_can_ist(int irq, void *dev_id)
if (new_state >= CAN_STATE_ERROR_WARNING &&
new_state <= CAN_STATE_BUS_OFF)
priv->can.can_stats.error_warning++;
- case CAN_STATE_ERROR_WARNING: /* fallthrough */
+ /* fall through */
+ case CAN_STATE_ERROR_WARNING:
if (new_state >= CAN_STATE_ERROR_PASSIVE &&
new_state <= CAN_STATE_BUS_OFF)
priv->can.can_stats.error_passive++;
diff --git a/drivers/net/can/usb/peak_usb/pcan_usb.c b/drivers/net/can/usb/peak_usb/pcan_usb.c
index 13238a72a338..eca785532b6b 100644
--- a/drivers/net/can/usb/peak_usb/pcan_usb.c
+++ b/drivers/net/can/usb/peak_usb/pcan_usb.c
@@ -423,7 +423,7 @@ static int pcan_usb_decode_error(struct pcan_usb_msg_context *mc, u8 n,
new_state = CAN_STATE_ERROR_WARNING;
break;
}
- /* else: fall through */
+ /* fall through */
case CAN_STATE_ERROR_WARNING:
if (n & PCAN_USB_ERROR_BUS_HEAVY) {
--
2.20.1
^ permalink raw reply related
* [PATCH net v5 2/2] net/mlx5e: Don't overwrite pedit action when multiple pedit used
From: xiangxia.m.yue @ 2019-01-28 23:28 UTC (permalink / raw)
To: saeedm, gerlitz.or, davem; +Cc: netdev, Tonghao Zhang, Or Gerlitz
In-Reply-To: <1548718086-20924-1-git-send-email-xiangxia.m.yue@gmail.com>
From: Tonghao Zhang <xiangxia.m.yue@gmail.com>
In some case, we may use multiple pedit actions to modify packets.
The command shown as below: the last pedit action is effective.
$ tc filter add dev netdev_rep parent ffff: protocol ip prio 1 \
flower skip_sw ip_proto icmp dst_ip 3.3.3.3 \
action pedit ex munge ip dst set 192.168.1.100 pipe \
action pedit ex munge eth src set 00:00:00:00:00:01 pipe \
action pedit ex munge eth dst set 00:00:00:00:00:02 pipe \
action csum ip pipe \
action tunnel_key set src_ip 1.1.1.100 dst_ip 1.1.1.200 dst_port 4789 id 100 \
action mirred egress redirect dev vxlan0
To fix it, we add max_mod_hdr_actions to mlx5e_tc_flow_parse_attr struction,
max_mod_hdr_actions will store the max pedit action number we support and
num_mod_hdr_actions indicates how many pedit action we used, and store all
pedit action to mod_hdr_actions.
Fixes: d79b6df6b10a ("net/mlx5e: Add parsing of TC pedit actions to HW format")
Cc: Or Gerlitz <ogerlitz@mellanox.com>
Signed-off-by: Tonghao Zhang <xiangxia.m.yue@gmail.com>
Reviewed-by: Or Gerlitz <ogerlitz@mellanox.com>
---
v3: Remove the unnecessary init.
v2: Fix comment message and change tag from net-next to net.
---
drivers/net/ethernet/mellanox/mlx5/core/en_tc.c | 25 +++++++++++++++----------
1 file changed, 15 insertions(+), 10 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c b/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c
index cae6c6d..a21724d0 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c
@@ -128,6 +128,7 @@ struct mlx5e_tc_flow_parse_attr {
struct net_device *filter_dev;
struct mlx5_flow_spec spec;
int num_mod_hdr_actions;
+ int max_mod_hdr_actions;
void *mod_hdr_actions;
int mirred_ifindex[MLX5_MAX_FLOW_FWD_VPORTS];
};
@@ -1934,9 +1935,9 @@ struct mlx5_fields {
OFFLOAD(UDP_DPORT, 2, udp.dest, 0),
};
-/* On input attr->num_mod_hdr_actions tells how many HW actions can be parsed at
- * max from the SW pedit action. On success, it says how many HW actions were
- * actually parsed.
+/* On input attr->max_mod_hdr_actions tells how many HW actions can be parsed at
+ * max from the SW pedit action. On success, attr->num_mod_hdr_actions
+ * says how many HW actions were actually parsed.
*/
static int offload_pedit_fields(struct pedit_headers *masks,
struct pedit_headers *vals,
@@ -1960,9 +1961,11 @@ static int offload_pedit_fields(struct pedit_headers *masks,
add_vals = &vals[TCA_PEDIT_KEY_EX_CMD_ADD];
action_size = MLX5_UN_SZ_BYTES(set_action_in_add_action_in_auto);
- action = parse_attr->mod_hdr_actions;
- max_actions = parse_attr->num_mod_hdr_actions;
- nactions = 0;
+ action = parse_attr->mod_hdr_actions +
+ parse_attr->num_mod_hdr_actions * action_size;
+
+ max_actions = parse_attr->max_mod_hdr_actions;
+ nactions = parse_attr->num_mod_hdr_actions;
for (i = 0; i < ARRAY_SIZE(fields); i++) {
f = &fields[i];
@@ -2073,7 +2076,7 @@ static int alloc_mod_hdr_actions(struct mlx5e_priv *priv,
if (!parse_attr->mod_hdr_actions)
return -ENOMEM;
- parse_attr->num_mod_hdr_actions = max_actions;
+ parse_attr->max_mod_hdr_actions = max_actions;
return 0;
}
@@ -2119,9 +2122,11 @@ static int parse_tc_pedit_action(struct mlx5e_priv *priv,
goto out_err;
}
- err = alloc_mod_hdr_actions(priv, a, namespace, parse_attr);
- if (err)
- goto out_err;
+ if (!parse_attr->mod_hdr_actions) {
+ err = alloc_mod_hdr_actions(priv, a, namespace, parse_attr);
+ if (err)
+ goto out_err;
+ }
err = offload_pedit_fields(masks, vals, parse_attr, extack);
if (err < 0)
--
1.8.3.1
^ permalink raw reply related
* [PATCH net v5 1/2] net/mlx5e: Update hw flows when encap source mac changed
From: xiangxia.m.yue @ 2019-01-28 23:28 UTC (permalink / raw)
To: saeedm, gerlitz.or, davem; +Cc: netdev, Tonghao Zhang, Hadar Hen Zion
From: Tonghao Zhang <xiangxia.m.yue@gmail.com>
When we offload tc filters to hardware, hardware flows can
be updated when mac of encap destination ip is changed.
But we ignore one case, that the mac of local encap ip can
be changed too, so we should also update them.
To fix it, add route_dev in mlx5e_encap_entry struct to save
the local encap netdevice, and when mac changed, kernel will
flush all the neighbour on the netdevice and send NETEVENT_NEIGH_UPDATE
event. The mlx5 driver will delete the flows and add them when neighbour
available again.
Fixes: 232c001398ae ("net/mlx5e: Add support to neighbour update flow")
Cc: Hadar Hen Zion <hadarh@mellanox.com>
Signed-off-by: Tonghao Zhang <xiangxia.m.yue@gmail.com>
Reviewed-by: Or Gerlitz <ogerlitz@mellanox.com>
---
drivers/net/ethernet/mellanox/mlx5/core/en/tc_tun.c | 2 ++
drivers/net/ethernet/mellanox/mlx5/core/en_rep.c | 4 ++++
drivers/net/ethernet/mellanox/mlx5/core/en_rep.h | 1 +
3 files changed, 7 insertions(+)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en/tc_tun.c b/drivers/net/ethernet/mellanox/mlx5/core/en/tc_tun.c
index 046948e..114e0a2 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en/tc_tun.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en/tc_tun.c
@@ -256,6 +256,7 @@ int mlx5e_tc_tun_create_header_ipv4(struct mlx5e_priv *priv,
e->m_neigh.family = n->ops->family;
memcpy(&e->m_neigh.dst_ip, n->primary_key, n->tbl->key_len);
e->out_dev = out_dev;
+ e->route_dev = route_dev;
/* It's important to add the neigh to the hash table before checking
* the neigh validity state. So if we'll get a notification, in case the
@@ -369,6 +370,7 @@ int mlx5e_tc_tun_create_header_ipv6(struct mlx5e_priv *priv,
e->m_neigh.family = n->ops->family;
memcpy(&e->m_neigh.dst_ip, n->primary_key, n->tbl->key_len);
e->out_dev = out_dev;
+ e->route_dev = route_dev;
/* It's importent to add the neigh to the hash table before checking
* the neigh validity state. So if we'll get a notification, in case the
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_rep.c b/drivers/net/ethernet/mellanox/mlx5/core/en_rep.c
index 96cc0c6..c4b9073 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_rep.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_rep.c
@@ -594,6 +594,10 @@ static void mlx5e_rep_update_flows(struct mlx5e_priv *priv,
if (neigh_connected && !(e->flags & MLX5_ENCAP_ENTRY_VALID)) {
ether_addr_copy(e->h_dest, ha);
ether_addr_copy(eth->h_dest, ha);
+ /* Update the encap source mac, in case that we delete
+ * the flows when encap source mac changed.
+ */
+ ether_addr_copy(eth->h_source, e->route_dev->dev_addr);
mlx5e_tc_encap_flows_add(priv, e);
}
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_rep.h b/drivers/net/ethernet/mellanox/mlx5/core/en_rep.h
index edd7228..36eafc8 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_rep.h
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_rep.h
@@ -148,6 +148,7 @@ struct mlx5e_encap_entry {
unsigned char h_dest[ETH_ALEN]; /* destination eth addr */
struct net_device *out_dev;
+ struct net_device *route_dev;
int tunnel_type;
int tunnel_hlen;
int reformat_type;
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH net-next] MAINTAINERS: update cxgb4 and cxgb3 maintainer
From: David Miller @ 2019-01-29 18:01 UTC (permalink / raw)
To: arjun; +Cc: netdev, nirranjan, indranil, dt, leedom
In-Reply-To: <20190129100842.19926-1-arjun@chelsio.com>
From: Arjun Vynipadath <arjun@chelsio.com>
Date: Tue, 29 Jan 2019 15:38:42 +0530
> Vishal Kulkarni will be the new maintainer for Chelsio cxgb3/cxgb4
> drivers.
>
> Signed-off-by: Arjun Vynipadath <arjun@chelsio.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] cxgb4vf: Update port information in cxgb4vf_open()
From: David Miller @ 2019-01-29 17:50 UTC (permalink / raw)
To: arjun; +Cc: netdev, nirranjan, indranil, dt, leedom
In-Reply-To: <20190129095019.19304-1-arjun@chelsio.com>
From: Arjun Vynipadath <arjun@chelsio.com>
Date: Tue, 29 Jan 2019 15:20:19 +0530
> It's possible that the basic port information could have
> changed since we first read it.
>
> Signed-off-by: Arjun Vynipadath <arjun@chelsio.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net v4 2/2] net/mlx5e: Don't overwrite pedit action when multiple pedit used
From: Tonghao Zhang @ 2019-01-29 17:47 UTC (permalink / raw)
To: Or Gerlitz; +Cc: Saeed Mahameed, Linux Netdev List, Or Gerlitz
In-Reply-To: <CAJ3xEMjHnoP8c17pki40vGs2S8xOSxP9Gm2RagtUxxBw_B7aLw@mail.gmail.com>
On Tue, Jan 29, 2019 at 11:44 PM Or Gerlitz <gerlitz.or@gmail.com> wrote:
>
> On Mon, Jan 28, 2019 at 6:18 PM Tonghao Zhang <xiangxia.m.yue@gmail.com> wrote:
> > On Mon, Jan 28, 2019 at 11:34 PM Or Gerlitz <gerlitz.or@gmail.com> wrote:
> > > On Mon, Jan 28, 2019 at 2:10 PM Tonghao Zhang <xiangxia.m.yue@gmail.com> wrote:
> > > > On Mon, Jan 28, 2019 at 12:40 AM Or Gerlitz <gerlitz.or@gmail.com> wrote:
> > > > >
> > > > > On Sun, Jan 27, 2019 at 1:06 PM <xiangxia.m.yue@gmail.com> wrote:
> > > > > > From: Tonghao Zhang <xiangxia.m.yue@gmail.com>
> > > > > >
> > > > > > In some case, we may use multiple pedit actions to modify packets.
> > > > > > The command shown as below: the last pedit action is effective.
> > > > >
> > > > > > @@ -2073,7 +2076,8 @@ static int alloc_mod_hdr_actions(struct mlx5e_priv *priv,
> > > > > > if (!parse_attr->mod_hdr_actions)
> > > > > > return -ENOMEM;
> > > > > >
> > > > > > - parse_attr->num_mod_hdr_actions = max_actions;
> > > > > > + parse_attr->max_mod_hdr_actions = max_actions;
> > > > > > + parse_attr->num_mod_hdr_actions = 0;
> > > > >
> > > > > why would we want to do this zeroing? what purpose does it serve?
> > > > Because we use the num_mod_hdr_actions to store the number of actions
> > > > we have parsed,
> > > > and when we alloc it, we init it 0 as default.
> > > >
> > > > > On a probably related note, I suspect that the patch broke the caching
> > > > > we do for modify header contexts, see mlx5e_attach_mod_hdr where we
> > > > > look if a given set of modify header operations already has hw modify header
> > > > > context and we use it.
> > > > >
> > > > > To test that, put two tc rules with different matching but same set of
> > > > > modify header
> > > > > (pedit) actions and see that only one modify header context is used.
> > >
> > > > The patch does't break the cache, I think that different matching may
> > > > share the same set of pedit actions.
> > >
> > > I suspect it does break it.. at [1] we have this code for the cache lookup:
> > >
> > > num_actions = parse_attr->num_mod_hdr_actions;
> > > [..]
> > > key.actions = parse_attr->mod_hdr_actions;
> > > key.num_actions = num_actions;
> > >
> > > hash_key = hash_mod_hdr_info(&key);
> > >
> > > so we are doing the cached insertion and lookup with
> > > parse_attr->num_mod_hdr_actions
> > > which was zeroed along the way and not accounting for the full set of
> > > pedit actions, agree?
>
> > not really, before calling the mlx5e_attach_mod_hdr, we have call
> > the offload_pedit_fields that will
> > update the attr->num_mod_hdr_actions that indicate how many pedit
> > action we parsed.
>
> ok, got you, so why do we need this line
>
> parse_attr->num_mod_hdr_actions = 0;
>
> in alloc_mod_hdr_actions()? this should be zero
> by kzalloc somewhere, it got to confuse me..
yes, should be removed
> I suggest to remove this zeroing, otherwise the patch LGTM, once you fix it
>
> Reviewed-by: Or Gerlitz <ogerlitz@mellanox.com>
^ permalink raw reply
* Re: [PATCH v2] net: macb: Apply RXUBR workaround only to versions with errata
From: David Miller @ 2019-01-29 17:41 UTC (permalink / raw)
To: harini.katakam
Cc: nicolas.ferre, claudiu.beznea, brandon.streiff, netdev,
linux-kernel, michal.simek, harinikatakamlinux
In-Reply-To: <1548755403-361-1-git-send-email-harini.katakam@xilinx.com>
From: Harini Katakam <harini.katakam@xilinx.com>
Date: Tue, 29 Jan 2019 15:20:03 +0530
> The interrupt handler contains a workaround for RX hang applicable
> to Zynq and AT91RM9200 only. Subsequent versions do not need this
> workaround. This workaround unnecessarily resets RX whenever RX used
> bit read is observed, which can be often under heavy traffic. There
> is no other action performed on RX UBR interrupt. Hence introduce a
> CAPS mask; enable this interrupt and workaround only on affected
> versions.
>
> Signed-off-by: Harini Katakam <harini.katakam@xilinx.com>
Applied, thank you.
^ permalink raw reply
* Re: [PATCH] r8169: Load MAC address from device tree if present
From: Thierry Reding @ 2019-01-29 17:40 UTC (permalink / raw)
To: Heiner Kallweit
Cc: David S. Miller, Realtek linux nic maintainers, netdev,
devicetree, linux-kernel
In-Reply-To: <59aa73fd-9cdc-8db8-b58e-ed106b084637@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3459 bytes --]
On Fri, Jan 25, 2019 at 07:34:31PM +0100, Heiner Kallweit wrote:
> On 25.01.2019 11:18, Thierry Reding wrote:
> > From: Thierry Reding <treding@nvidia.com>
> >
> > If the system was booted using a device tree and if the device tree
> > contains a MAC address, use it instead of reading one from the EEPROM.
> > This is useful in situations where the EEPROM isn't properly programmed
> > or where the firmware wants to override the existing MAC address.
> >
> I rarely see DT-configured boards with RTL8168 network. Do you add this
> patch because of a specific board?
> And you state "if EEPROM isn't properly programmed": Did you come across
> such a case?
We use these Realtek chips on some of our boards that customers can
either purchase individually and integrate into their own designs or
they can get the module as part of a product.
In order to easily allow customers to reprogram the device (they may
want to do that if integrating the module into their own products), a
so-called ID EEPROM is part of the module that stores various bits of
information. The ethernet MAC address is part of that EEPROM.
Typically the ID EEPROM will contain a valid MAC address if the module
is part of a product, but if customers purchase the module individually,
it is expected that they use a MAC address from their own pool.
Typically early boot firmware will load the MAC address from the EEPROM
and store it in the ethernet device's device tree node so that the MAC
address programmed into the ID EEPROM will be used by the ethernet
device at runtime.
> In general the patch is fine with me, I just want to understand the
> motivation. One further comment see inline.
> As of today we already have the option to set a MAC from userspace
> via ethtool.
>
> > Signed-off-by: Thierry Reding <treding@nvidia.com>
> > ---
> > Based on net-next.
> >
> > drivers/net/ethernet/realtek/r8169.c | 35 +++++++++++++++++-----------
> > 1 file changed, 22 insertions(+), 13 deletions(-)
> >
> > diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c
> > index f574b6b557f9..fd9edd643ca5 100644
> > --- a/drivers/net/ethernet/realtek/r8169.c
> > +++ b/drivers/net/ethernet/realtek/r8169.c
> > @@ -6957,6 +6957,21 @@ static int rtl_alloc_irq(struct rtl8169_private *tp)
> > return pci_alloc_irq_vectors(tp->pci_dev, 1, 1, flags);
> > }
> >
> [...]
> > @@ -7252,20 +7268,13 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
> > u64_stats_init(&tp->rx_stats.syncp);
> > u64_stats_init(&tp->tx_stats.syncp);
> >
> > - /* Get MAC address */
> > - switch (tp->mac_version) {
> > - u8 mac_addr[ETH_ALEN] __aligned(4);
> > - case RTL_GIGA_MAC_VER_35 ... RTL_GIGA_MAC_VER_38:
> > - case RTL_GIGA_MAC_VER_40 ... RTL_GIGA_MAC_VER_51:
> > - *(u32 *)&mac_addr[0] = rtl_eri_read(tp, 0xe0, ERIAR_EXGMAC);
> > - *(u16 *)&mac_addr[4] = rtl_eri_read(tp, 0xe4, ERIAR_EXGMAC);
> > + /* get MAC address */
> > + if (eth_platform_get_mac_address(&pdev->dev, mac_addr))
> > + rtl_read_mac_address(tp, mac_addr);
> > +
> > + if (is_valid_ether_addr(mac_addr))
>
> Here array mac_addr may be uninitialized (if platform defines no MAC
> and chip version is not covered by the switch statement).
Good point. I can memset() mac_addr to make sure it is invalid, rather
than undefined, for chip versions that are not covered.
Thierry
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [net-next] cxgb4/cxgb4vf: Program hash region for {t4/t4vf}_change_mac()
From: David Miller @ 2019-01-29 17:39 UTC (permalink / raw)
To: arjun; +Cc: netdev, nirranjan, indranil, dt, leedom
In-Reply-To: <20190129094850.19203-1-arjun@chelsio.com>
From: Arjun Vynipadath <arjun@chelsio.com>
Date: Tue, 29 Jan 2019 15:18:50 +0530
> diff --git a/drivers/net/ethernet/chelsio/cxgb4vf/cxgb4vf_main.c b/drivers/net/ethernet/chelsio/cxgb4vf/cxgb4vf_main.c
> index 2fab87e..a8f78ea 100644
> --- a/drivers/net/ethernet/chelsio/cxgb4vf/cxgb4vf_main.c
> +++ b/drivers/net/ethernet/chelsio/cxgb4vf/cxgb4vf_main.c
> @@ -236,6 +236,74 @@ void t4vf_os_portmod_changed(struct adapter *adapter, int pidx)
> "inserted\n", dev->name, pi->mod_type);
> }
>
> +static inline int cxgb4vf_set_addr_hash(struct port_info *pi)
...
> +static inline int cxgb4vf_change_mac(struct port_info *pi, unsigned int viid,
> + int *tcam_idx, const u8 *addr,
> + bool persistent)
Please do not use the inline keyword in foo.c files.
Thank you.
^ permalink raw reply
* INFO: trying to register non-static key in icmp_send
From: syzbot @ 2019-01-29 17:33 UTC (permalink / raw)
To: davem, kuznet, linux-kernel, netdev, syzkaller-bugs, yoshfuji
Hello,
syzbot found the following crash on:
HEAD commit: 4aa9fc2a435a Revert "mm, memory_hotplug: initialize struct..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=168581ef400000
kernel config: https://syzkaller.appspot.com/x/.config?x=4fceea9e2d99ac20
dashboard link: https://syzkaller.appspot.com/bug?extid=e1628a5e87492e6f1b76
compiler: gcc (GCC) 9.0.0 20181231 (experimental)
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=175c96ef400000
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+e1628a5e87492e6f1b76@syzkaller.appspotmail.com
Enabling of bearer <udp:syz1> rejected, already enabled
Enabling of bearer <udp:syz1> rejected, already enabled
Enabling of bearer <udp:syz1> rejected, already enabled
Enabling of bearer <udp:syz1> rejected, already enabled
Enabling of bearer <udp:syz1> rejected, already enabled
INFO: trying to register non-static key.
the code is fine but needs lockdep annotation.
Enabling of bearer <udp:syz1> rejected, already enabled
turning off the locking correctness validator.
CPU: 1 PID: 3867 Comm: udevd Not tainted 5.0.0-rc4+ #50
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
<IRQ>
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x1db/0x2d0 lib/dump_stack.c:113
assign_lock_key kernel/locking/lockdep.c:731 [inline]
register_lock_class+0x19dc/0x1e60 kernel/locking/lockdep.c:757
__lock_acquire+0x149/0x4a30 kernel/locking/lockdep.c:3224
Enabling of bearer <udp:syz1> rejected, already enabled
Enabling of bearer <udp:syz1> rejected, already enabled
lock_acquire+0x1db/0x570 kernel/locking/lockdep.c:3841
Enabling of bearer <udp:syz1> rejected, already enabled
Enabling of bearer <udp:syz1> rejected, already enabled
__raw_spin_trylock include/linux/spinlock_api_smp.h:90 [inline]
_raw_spin_trylock+0x62/0x80 kernel/locking/spinlock.c:128
spin_trylock include/linux/spinlock.h:339 [inline]
icmp_xmit_lock net/ipv4/icmp.c:219 [inline]
icmp_send+0x582/0x1bc0 net/ipv4/icmp.c:665
__udp4_lib_rcv+0x23a8/0x3180 net/ipv4/udp.c:2321
Enabling of bearer <udp:syz1> rejected, already enabled
udp_rcv+0x22/0x30 net/ipv4/udp.c:2480
ip_protocol_deliver_rcu+0xb6/0xa20 net/ipv4/ip_input.c:208
Enabling of bearer <udp:syz1> rejected, already enabled
ip_local_deliver_finish+0x23b/0x390 net/ipv4/ip_input.c:234
NF_HOOK include/linux/netfilter.h:289 [inline]
NF_HOOK include/linux/netfilter.h:283 [inline]
ip_local_deliver+0x1f0/0x740 net/ipv4/ip_input.c:255
Enabling of bearer <udp:syz1> rejected, already enabled
dst_input include/net/dst.h:450 [inline]
ip_rcv_finish+0x1f4/0x2f0 net/ipv4/ip_input.c:414
NF_HOOK include/linux/netfilter.h:289 [inline]
NF_HOOK include/linux/netfilter.h:283 [inline]
ip_rcv+0xed/0x620 net/ipv4/ip_input.c:524
__netif_receive_skb_one_core+0x160/0x210 net/core/dev.c:4973
__netif_receive_skb+0x2c/0x1c0 net/core/dev.c:5083
process_backlog+0x206/0x750 net/core/dev.c:5923
napi_poll net/core/dev.c:6346 [inline]
net_rx_action+0x76d/0x1930 net/core/dev.c:6412
__do_softirq+0x30b/0xb11 kernel/softirq.c:292
invoke_softirq kernel/softirq.c:373 [inline]
irq_exit+0x180/0x1d0 kernel/softirq.c:413
exiting_irq arch/x86/include/asm/apic.h:536 [inline]
smp_apic_timer_interrupt+0x1b7/0x760 arch/x86/kernel/apic/apic.c:1062
Enabling of bearer <udp:syz1> rejected, already enabled
apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:807
</IRQ>
RIP: 0010:arch_local_irq_restore arch/x86/include/asm/paravirt.h:766
[inline]
RIP: 0010:lock_acquire+0x259/0x570 kernel/locking/lockdep.c:3844
Code: 00 00 00 00 00 48 c1 e8 03 80 3c 10 00 0f 85 64 02 00 00 48 83 3d 66
30 2e 08 00 0f 84 d0 01 00 00 48 8b bd 48 ff ff ff 57 9d <0f> 1f 44 00 00
48 b8 00 00 00 00 00 fc ff df 48 03 85 40 ff ff ff
RSP: 0018:ffff888097c57640 EFLAGS: 00000282 ORIG_RAX: ffffffffffffff13
RAX: 1ffffffff1325046 RBX: ffff888097c4c2c0 RCX: 0000000000000000
RDX: dffffc0000000000 RSI: 0000000000000eb8 RDI: 0000000000000282
RBP: ffff888097c57710 R08: 0000000000000001 R09: ffff888097c4cb88
R10: ffff888097c4cb68 R11: 0000000000000001 R12: ffff88808954e7b8
R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
__raw_spin_lock include/linux/spinlock_api_smp.h:142 [inline]
_raw_spin_lock+0x2f/0x40 kernel/locking/spinlock.c:144
spin_lock include/linux/spinlock.h:329 [inline]
__d_lookup+0x2b6/0x960 fs/dcache.c:2272
lookup_fast+0x480/0x1260 fs/namei.c:1617
do_last fs/namei.c:3284 [inline]
path_openat+0x4db/0x5650 fs/namei.c:3534
do_filp_open+0x26f/0x370 fs/namei.c:3564
do_sys_open+0x59a/0x7c0 fs/open.c:1063
__do_sys_open fs/open.c:1081 [inline]
__se_sys_open fs/open.c:1076 [inline]
__x64_sys_open+0x7e/0xc0 fs/open.c:1076
do_syscall_64+0x1a3/0x800 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x7f902edde120
Code: 48 8b 15 1b 4d 2b 00 f7 d8 64 89 02 83 c8 ff c3 90 90 90 90 90 90 90
90 90 90 83 3d d5 a4 2b 00 00 75 10 b8 02 00 00 00 0f 05 <48> 3d 01 f0 ff
ff 73 31 c3 48 83 ec 08 e8 5e 8c 01 00 48 89 04 24
RSP: 002b:00007ffc8e9d9588 EFLAGS: 00000246 ORIG_RAX: 0000000000000002
RAX: ffffffffffffffda RBX: 0000000000b35bb0 RCX: 00007f902edde120
RDX: 0000000000000000 RSI: 0000000000000001 RDI: 00007ffc8e9da200
RBP: 0000000000b35360 R08: 000000000041f4f1 R09: 00007f902ee347d0
R10: 7269762f73656369 R11: 0000000000000246 R12: 0000000000000003
R13: 0000000000000000 R14: 0000000000b35bb0 R15: 0000000000b25250
kasan: CONFIG_KASAN_INLINE enabled
Enabling of bearer <udp:syz1> rejected, already enabled
kasan: GPF could be caused by NULL-ptr deref or user memory access
general protection fault: 0000 [#1] PREEMPT SMP KASAN
CPU: 1 PID: 3867 Comm: udevd Not tainted 5.0.0-rc4+ #50
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
RIP: 0010:__ip_append_data.isra.0+0x301/0x3350 net/ipv4/ip_output.c:898
Code: c7 85 64 fe ff ff 00 00 00 00 0f 85 78 15 00 00 e8 d4 c5 f0 fa 48 8b
95 d8 fe ff ff 48 b8 00 00 00 00 00 fc ff df 48 c1 ea 03 <80> 3c 02 00 0f
85 60 2f 00 00 48 8b 85 d8 fe ff ff 48 8b 18 48 b8
RSP: 0018:ffff8880ae706e38 EFLAGS: 00010246
RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffffff86913e0c
RDX: 0000000000000000 RSI: ffffffff86913e8c RDI: 0000000000000001
RBP: ffff8880ae707010 R08: ffff888097c4c2c0 R09: ffffffff86a3da70
R10: ffff8880ae707180 R11: ffff888096919343 R12: ffff88808dba2a70
R13: ffff88808dba2f10 R14: 0000000000000001 R15: dead4ead00000000
FS: 00007f902f6d67a0(0000) GS:ffff8880ae700000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fffb4062fe4 CR3: 00000000981e9000 CR4: 00000000001406e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
<IRQ>
Enabling of bearer <udp:syz1> rejected, already enabled
Enabling of bearer <udp:syz1> rejected, already enabled
ip_append_data.part.0+0xf2/0x170 net/ipv4/ip_output.c:1220
Enabling of bearer <udp:syz1> rejected, already enabled
ip_append_data+0x6e/0x90 net/ipv4/ip_output.c:1209
icmp_push_reply+0x189/0x510 net/ipv4/icmp.c:375
Enabling of bearer <udp:syz1> rejected, already enabled
icmp_send+0x1535/0x1bc0 net/ipv4/icmp.c:736
Enabling of bearer <udp:syz1> rejected, already enabled
__udp4_lib_rcv+0x23a8/0x3180 net/ipv4/udp.c:2321
udp_rcv+0x22/0x30 net/ipv4/udp.c:2480
ip_protocol_deliver_rcu+0xb6/0xa20 net/ipv4/ip_input.c:208
Enabling of bearer <udp:syz1> rejected, already enabled
ip_local_deliver_finish+0x23b/0x390 net/ipv4/ip_input.c:234
NF_HOOK include/linux/netfilter.h:289 [inline]
NF_HOOK include/linux/netfilter.h:283 [inline]
ip_local_deliver+0x1f0/0x740 net/ipv4/ip_input.c:255
Enabling of bearer <udp:syz1> rejected, already enabled
dst_input include/net/dst.h:450 [inline]
ip_rcv_finish+0x1f4/0x2f0 net/ipv4/ip_input.c:414
NF_HOOK include/linux/netfilter.h:289 [inline]
NF_HOOK include/linux/netfilter.h:283 [inline]
ip_rcv+0xed/0x620 net/ipv4/ip_input.c:524
__netif_receive_skb_one_core+0x160/0x210 net/core/dev.c:4973
Enabling of bearer <udp:syz1> rejected, already enabled
Enabling of bearer <udp:syz1> rejected, already enabled
__netif_receive_skb+0x2c/0x1c0 net/core/dev.c:5083
process_backlog+0x206/0x750 net/core/dev.c:5923
Enabling of bearer <udp:syz1> rejected, already enabled
napi_poll net/core/dev.c:6346 [inline]
net_rx_action+0x76d/0x1930 net/core/dev.c:6412
Enabling of bearer <udp:syz1> rejected, already enabled
__do_softirq+0x30b/0xb11 kernel/softirq.c:292
invoke_softirq kernel/softirq.c:373 [inline]
irq_exit+0x180/0x1d0 kernel/softirq.c:413
exiting_irq arch/x86/include/asm/apic.h:536 [inline]
smp_apic_timer_interrupt+0x1b7/0x760 arch/x86/kernel/apic/apic.c:1062
apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:807
</IRQ>
RIP: 0010:arch_local_irq_restore arch/x86/include/asm/paravirt.h:766
[inline]
RIP: 0010:lock_acquire+0x259/0x570 kernel/locking/lockdep.c:3844
Code: 00 00 00 00 00 48 c1 e8 03 80 3c 10 00 0f 85 64 02 00 00 48 83 3d 66
30 2e 08 00 0f 84 d0 01 00 00 48 8b bd 48 ff ff ff 57 9d <0f> 1f 44 00 00
48 b8 00 00 00 00 00 fc ff df 48 03 85 40 ff ff ff
RSP: 0018:ffff888097c57640 EFLAGS: 00000282 ORIG_RAX: ffffffffffffff13
RAX: 1ffffffff1325046 RBX: ffff888097c4c2c0 RCX: 0000000000000000
RDX: dffffc0000000000 RSI: 0000000000000eb8 RDI: 0000000000000282
RBP: ffff888097c57710 R08: 0000000000000001 R09: ffff888097c4cb88
R10: ffff888097c4cb68 R11: 0000000000000001 R12: ffff88808954e7b8
R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
__raw_spin_lock include/linux/spinlock_api_smp.h:142 [inline]
_raw_spin_lock+0x2f/0x40 kernel/locking/spinlock.c:144
spin_lock include/linux/spinlock.h:329 [inline]
__d_lookup+0x2b6/0x960 fs/dcache.c:2272
lookup_fast+0x480/0x1260 fs/namei.c:1617
do_last fs/namei.c:3284 [inline]
path_openat+0x4db/0x5650 fs/namei.c:3534
do_filp_open+0x26f/0x370 fs/namei.c:3564
do_sys_open+0x59a/0x7c0 fs/open.c:1063
__do_sys_open fs/open.c:1081 [inline]
__se_sys_open fs/open.c:1076 [inline]
__x64_sys_open+0x7e/0xc0 fs/open.c:1076
do_syscall_64+0x1a3/0x800 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x7f902edde120
Code: 48 8b 15 1b 4d 2b 00 f7 d8 64 89 02 83 c8 ff c3 90 90 90 90 90 90 90
90 90 90 83 3d d5 a4 2b 00 00 75 10 b8 02 00 00 00 0f 05 <48> 3d 01 f0 ff
ff 73 31 c3 48 83 ec 08 e8 5e 8c 01 00 48 89 04 24
RSP: 002b:00007ffc8e9d9588 EFLAGS: 00000246 ORIG_RAX: 0000000000000002
RAX: ffffffffffffffda RBX: 0000000000b35bb0 RCX: 00007f902edde120
RDX: 0000000000000000 RSI: 0000000000000001 RDI: 00007ffc8e9da200
RBP: 0000000000b35360 R08: 000000000041f4f1 R09: 00007f902ee347d0
R10: 7269762f73656369 R11: 0000000000000246 R12: 0000000000000003
R13: 0000000000000000 R14: 0000000000b35bb0 R15: 0000000000b25250
Modules linked in:
---[ end trace 6d5f724bc69e6c3e ]---
Enabling of bearer <udp:syz1> rejected, already enabled
RIP: 0010:__ip_append_data.isra.0+0x301/0x3350 net/ipv4/ip_output.c:898
Code: c7 85 64 fe ff ff 00 00 00 00 0f 85 78 15 00 00 e8 d4 c5 f0 fa 48 8b
95 d8 fe ff ff 48 b8 00 00 00 00 00 fc ff df 48 c1 ea 03 <80> 3c 02 00 0f
85 60 2f 00 00 48 8b 85 d8 fe ff ff 48 8b 18 48 b8
RSP: 0018:ffff8880ae706e38 EFLAGS: 00010246
Enabling of bearer <udp:syz1> rejected, already enabled
RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffffff86913e0c
RDX: 0000000000000000 RSI: ffffffff86913e8c RDI: 0000000000000001
RBP: ffff8880ae707010 R08: ffff888097c4c2c0 R09: ffffffff86a3da70
Enabling of bearer <udp:syz1> rejected, already enabled
R10: ffff8880ae707180 R11: ffff888096919343 R12: ffff88808dba2a70
R13: ffff88808dba2f10 R14: 0000000000000001 R15: dead4ead00000000
FS: 00007f902f6d67a0(0000) GS:ffff8880ae700000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fffb4062fe4 CR3: 00000000981e9000 CR4: 00000000001406e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with
syzbot.
syzbot can test patches for this bug, for details see:
https://goo.gl/tpsmEJ#testing-patches
^ 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