* Re: Re: [PATCH 2/4] dt-bindings: add binding for RTL8211E Ethernet PHY
From: Florian Fainelli @ 2017-08-21 19:54 UTC (permalink / raw)
To: icenowy-h8G6r0blFSE
Cc: Andrew Lunn, Rob Herring, netdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, Icenowy Zheng
In-Reply-To: <19ad1316a74e344d3e1c783458eb4d59-h8G6r0blFSE@public.gmane.org>
On 08/21/2017 07:53 AM, icenowy-h8G6r0blFSE@public.gmane.org wrote:
> 在 2017-05-05 02:29，Florian Fainelli 写道：
>> On 05/04/2017 11:26 AM, Icenowy Zheng wrote:
>>>
>>>
>>> 于 2017年5月5日 GMT+08:00 上午2:21:29, Florian Fainelli
>>> <f.fainelli-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 写到:
>>>> On 05/04/2017 11:10 AM, icenowy-h8G6r0blFSE@public.gmane.org wrote:
>>>>> 在 2017-04-22 08:22，Florian Fainelli 写道：
>>>>>> On 04/21/2017 04:24 PM, Icenowy Zheng wrote:
>>>>>>> From: Icenowy Zheng <icenowy-ymACFijhrKM@public.gmane.org>
>>>>>>>
>>>>>>> Some RTL8211E Ethernet PHY have an issue that needs a workaround
>>>>>>> indicated with device tree.
>>>>>>>
>>>>>>> Add the binding for a property that indicates this workaround.
>>>>>>>
>>>>>>> Signed-off-by: Icenowy Zheng <icenowy-ymACFijhrKM@public.gmane.org>
>>>>>>> ---
>>>>>>> .../devicetree/bindings/net/realtek,rtl8211e.txt | 22
>>>>>>> ++++++++++++++++++++++
>>>>>>> 1 file changed, 22 insertions(+)
>>>>>>> create mode 100644
>>>>>>> Documentation/devicetree/bindings/net/realtek,rtl8211e.txt
>>>>>>>
>>>>>>> diff --git
>>>>>>> a/Documentation/devicetree/bindings/net/realtek,rtl8211e.txt
>>>>>>> b/Documentation/devicetree/bindings/net/realtek,rtl8211e.txt
>>>>>>> new file mode 100644
>>>>>>> index 000000000000..c1913301bfe8
>>>>>>> --- /dev/null
>>>>>>> +++ b/Documentation/devicetree/bindings/net/realtek,rtl8211e.txt
>>>>>>> @@ -0,0 +1,22 @@
>>>>>>> +Realtek RTL8211E Ethernet PHY
>>>>>>> +
>>>>>>> +One batch of RTL8211E is slight broken, that needs some special
>>>> (and
>>>>>>> +full of magic numbers) tweaking in order to make GbE to operate
>>>>>>> properly.
>>>>>>> +The only well-known board that used the broken batch is Pine64+.
>>>>>>> +Configure it through an Ethernet OF device node.
>>>>>>> +
>>>>>>> +Optional properties:
>>>>>>> +
>>>>>>> +- realtek,disable-rx-delay:
>>>>>>> + If set, RX delay will be completely disabled (according to
>>>>>>> Realtek). This
>>>>>>> + will affect the performance on non-broken boards.
>>>>>>> + default: do not disable RX delay.
>>>>>>
>>>>>> Please don't introduce custom properties to do that, instead correct
>>>>>> specify the "phy-mode" such that it is e.g: "rgmii-txid" which
>>>> indicates
>>>>>> that there should be no RX internal delay, but a TX internal delay
>>>> added
>>>>>> by the PHY.
>>>>>
>>>>> Checked the document, the meaning of "rgmii-txid" is not correct
>>>> here.
>>>>>
>>>>> This doesn't effect the MAC, and the MAC should still add TX delay.
>>>>>
>>>>> The definition of "rgmii-txid" in
>>>>> Documentation/devicetree/binding/net/ethernet.txt is "RGMII with
>>>>> internal TX delay provided by the PHY, the MAC should not add an TX
>>>> delay
>>>>> in this case". However, this do not indicate that the MAC doesn't add
>>>> TX
>>>>> delay; in fact that just totally disabled the PHY to provide the RX
>>>> delay.
>>>>> MAC still should to add delay on both TX/RX, which is the semantic of
>>>>> standard "rgmii".
>>>>>
>>>>> So I cannot used "rgmii-txid" here, but should continue to use this
>>>>> custom property.
>
> Sorry for replying an old email, but it's because the driver of the MAC I
> used is merged (dwmac-sun8i).
>
> The driver of the MAC currently only supports "mii", "rmii", and "rgmii",
> and according to the SoC's user manual, the MAC cannot has its delays
> disabled.
>
> How should it handle this "rgmii-txid" here? Just treat it as "rgmii"?
Considering there are no configurable delays on the MAC side, all you
can do is treat all RGMII variants the same by configuring the MAC for
RGMII mode (with no additional capabilities and as opposed to MII, RMII
which are other clocking/data pins modes) and let the PHY configure the
delay accordingly based on "phy-mode"/phy_interface_t. You can use
phy_interface_is_rgmii() as a helper function to cover all 4 variants.
--
Florian
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* Re: [PATCH net-next] net: sched: Add the invalid handle check in qdisc_class_find
From: Cong Wang @ 2017-08-21 19:58 UTC (permalink / raw)
To: David Miller; +Cc: Gao Feng, Linux Kernel Network Developers, Jamal Hadi Salim
In-Reply-To: <20170821.104749.419102990180912192.davem@davemloft.net>
On Mon, Aug 21, 2017 at 10:47 AM, David Miller <davem@davemloft.net> wrote:
> From: gfree.wind@vip.163.com
> Date: Fri, 18 Aug 2017 15:23:24 +0800
>
>> From: Gao Feng <gfree.wind@vip.163.com>
>>
>> Add the invalid handle "0" check to avoid unnecessary search, because
>> the qdisc uses the skb->priority as the handle value to look up, and
>> it is "0" usually.
>>
>> Signed-off-by: Gao Feng <gfree.wind@vip.163.com>
>
> Jamal, Cong, please review.
>
> If 'id' zero is never hashed into the tables, this change looks
> legitimate.
Looks good to me.
Gao, in the future please Cc maintainers directly, you can
use ./scripts/get_maintainer.pl.
Thanks.
^ permalink raw reply
* [PATCH net] net/hsr: Check skb_put_padto() return value
From: Florian Fainelli @ 2017-08-21 19:59 UTC (permalink / raw)
To: netdev
Cc: mail, peter.heise, Florian Fainelli, Arvid Brodin,
David S. Miller, open list
skb_put_padto() will free the sk_buff passed as reference in case of
errors, but we still need to check its return value and decide what to
do.
Detected by CoverityScan, CID#1416688 ("CHECKED_RETURN")
Fixes: ee1c27977284 ("net/hsr: Added support for HSR v1")
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
net/hsr/hsr_device.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/net/hsr/hsr_device.c b/net/hsr/hsr_device.c
index 4e7bdb213cd0..172d8309f89e 100644
--- a/net/hsr/hsr_device.c
+++ b/net/hsr/hsr_device.c
@@ -314,7 +314,8 @@ static void send_hsr_supervision_frame(struct hsr_port *master,
hsr_sp = skb_put(skb, sizeof(struct hsr_sup_payload));
ether_addr_copy(hsr_sp->MacAddressA, master->dev->dev_addr);
- skb_put_padto(skb, ETH_ZLEN + HSR_HLEN);
+ if (skb_put_padto(skb, ETH_ZLEN + HSR_HLEN))
+ return;
hsr_forward_skb(skb, master);
return;
--
2.9.3
^ permalink raw reply related
* Re: [PATCH RESEND 1/2] net: enable high resolution timer mode to timeout datagram sockets
From: Cong Wang @ 2017-08-21 20:10 UTC (permalink / raw)
To: Vallish Vaidyeshwara
Cc: David Miller, shuah, Linux Kernel Network Developers, LKML,
Eduardo Valentin, anchalag
In-Reply-To: <1503081850-10671-2-git-send-email-vallish@amazon.com>
On Fri, Aug 18, 2017 at 11:44 AM, Vallish Vaidyeshwara
<vallish@amazon.com> wrote:
> - *timeo_p = schedule_timeout(*timeo_p);
> + /* Wait using highres timer */
> + expires = ktime_add_ns(ktime_get(), jiffies_to_nsecs(*timeo_p));
> + pre_sched_time = jiffies;
> + if (schedule_hrtimeout(&expires, HRTIMER_MODE_ABS))
Does this work with MAX_SCHEDULE_TIMEOUT too??
^ permalink raw reply
* Re: [PATCH net-next] net: sched: Add the invalid handle check in qdisc_class_find
From: Jamal Hadi Salim @ 2017-08-21 20:17 UTC (permalink / raw)
To: Cong Wang, David Miller; +Cc: Gao Feng, Linux Kernel Network Developers
In-Reply-To: <CAM_iQpW_odL=iqONVX2cLqPr_XQ-J40Ruv+kYMvwPThR42Udrg@mail.gmail.com>
On 17-08-21 03:58 PM, Cong Wang wrote:
> On Mon, Aug 21, 2017 at 10:47 AM, David Miller <davem@davemloft.net> wrote:
>> From: gfree.wind@vip.163.com
>> Date: Fri, 18 Aug 2017 15:23:24 +0800
>>
>>> From: Gao Feng <gfree.wind@vip.163.com>
>>>
>>> Add the invalid handle "0" check to avoid unnecessary search, because
>>> the qdisc uses the skb->priority as the handle value to look up, and
>>> it is "0" usually.
>>>
>>> Signed-off-by: Gao Feng <gfree.wind@vip.163.com>
>>
>> Jamal, Cong, please review.
>>
>> If 'id' zero is never hashed into the tables, this change looks
>> legitimate.
>
> Looks good to me.
>
Looks good to me as well...
cheers,
jamal
^ permalink raw reply
* Re: [PATCH v3 net-next] bpf/verifier: track liveness for pruning
From: Edward Cree @ 2017-08-21 20:24 UTC (permalink / raw)
To: Alexei Starovoitov, davem, Alexei Starovoitov, Daniel Borkmann
Cc: netdev, linux-kernel, iovisor-dev
In-Reply-To: <b8a46388-74ea-81f9-df08-3b6b88042229@solarflare.com>
On 18/08/17 15:16, Edward Cree wrote:
> On 18/08/17 04:21, Alexei Starovoitov wrote:
>> It seems you're trying to sort-of do per-fake-basic block liveness
>> analysis, but our state_list_marks are not correct if we go with
>> canonical basic block definition, since we mark the jump insn and
>> not insn after the branch and not every basic block boundary is
>> properly detected.
> I think the reason this works is that jump insns can't do writes.
> [snip]
> the sl->state will never have any write marks and it'll all just work.
> But I should really test that!
I tested this, and found that, no, sl->state can have write marks, and the
algorithm will get the wrong answer in that case. So I've got a patch to
make the first iteration ignore write marks, as part of a series which I
will post shortly. When I do so, please re-do your tests with adding
state_list_marks in strange and exciting places; it should work wherever
you put them. Like you say, it "magically doesn't depend on proper basic
block boundaries", and that's because really pruning is just a kind of
checkpointing that just happens to be most effective when done just after
a jump (pop_stack).
Can I have a SOB for your "grr" test program, so I can include it in the
series?
-Ed
^ permalink raw reply
* Re: [PATCH v3 net-next] bpf/verifier: track liveness for pruning
From: Daniel Borkmann via iovisor-dev @ 2017-08-21 20:27 UTC (permalink / raw)
To: Edward Cree, Alexei Starovoitov, davem-fT/PcQaiUtIeIZ0/mPfg9Q,
Alexei Starovoitov
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, iovisor-dev,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <b39b4a6f-907e-c684-b9e4-285ff9c7ca9a-s/n/eUQHGBpZroRs9YW3xA@public.gmane.org>
On 08/21/2017 08:36 PM, Edward Cree wrote:
> On 19/08/17 00:37, Alexei Starovoitov wrote:
[...]
> I'm tempted to just rip out env->varlen_map_value_access and always check
> the whole thing, because honestly I don't know what it was meant to do
> originally or how it can ever do any useful pruning. While drastic, it
> does cause your test case to pass.
Original intention from 484611357c19 ("bpf: allow access into map
value arrays") was that it wouldn't potentially make pruning worse
if PTR_TO_MAP_VALUE_ADJ was not used, meaning that we wouldn't need
to take reg state's min_value and max_value into account for state
checking; this was basically due to min_value / max_value is being
adjusted/tracked on every alu/jmp ops for involved regs (e.g.
adjust_reg_min_max_vals() and others that mangle them) even if we
have the case that no actual dynamic map access is used throughout
the program. To give an example on net tree, the bpf_lxc.o prog's
section increases from 36,386 to 68,226 when env->varlen_map_value_access
is always true, so it does have an effect. Did you do some checks
on this on net-next?
^ permalink raw reply
* Re: [net-next 1/1] tipc: don't reset stale broadcast send link
From: David Miller @ 2017-08-21 20:38 UTC (permalink / raw)
To: jon.maloy; +Cc: ying.xue, netdev, tipc-discussion
In-Reply-To: <1503331170-21745-1-git-send-email-jon.maloy@ericsson.com>
From: Jon Maloy <jon.maloy@ericsson.com>
Date: Mon, 21 Aug 2017 17:59:30 +0200
> When the broadcast send link after 100 attempts has failed to
> transfer a packet to all peers, we consider it stale, and reset
> it. Thereafter it needs to re-synchronize with the peers, something
> currently done by just resetting and re-establishing all links to
> all peers. This has turned out to be overkill, with potentially
> unwanted consequences for the remaining cluster.
>
> A closer analysis reveals that this can be done much simpler. When
> this kind of failure happens, for reasons that may lie outside the
> TIPC protocol, it is typically only one peer which is failing to
> receive and acknowledge packets. It is hence sufficient to identify
> and reset the links only to that peer to resolve the situation, without
> having to reset the broadcast link at all. This solution entails a much
> lower risk of negative consequences for the own node as well as for
> the overall cluster.
>
> We implement this change in this commit.
>
> Reviewed-by: Parthasarathy Bhuvaragan <parthasarathy.bhuvaragan@ericsson.com>
> Acked-by: Ying Xue <ying.xue@windriver.com>
> Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Applied, thanks Jon.
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
^ permalink raw reply
* Re: [PATCH net-next] net: sched: Add the invalid handle check in qdisc_class_find
From: David Miller @ 2017-08-21 20:40 UTC (permalink / raw)
To: gfree.wind; +Cc: netdev
In-Reply-To: <1503041004-105572-1-git-send-email-gfree.wind@vip.163.com>
From: gfree.wind@vip.163.com
Date: Fri, 18 Aug 2017 15:23:24 +0800
> From: Gao Feng <gfree.wind@vip.163.com>
>
> Add the invalid handle "0" check to avoid unnecessary search, because
> the qdisc uses the skb->priority as the handle value to look up, and
> it is "0" usually.
>
> Signed-off-by: Gao Feng <gfree.wind@vip.163.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH v3 net-next] bpf/verifier: track liveness for pruning
From: Edward Cree via iovisor-dev @ 2017-08-21 20:44 UTC (permalink / raw)
To: Daniel Borkmann, Alexei Starovoitov, davem-fT/PcQaiUtIeIZ0/mPfg9Q,
Alexei Starovoitov
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, iovisor-dev,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <599B4231.3080405-FeC+5ew28dpmcu3hnIyYJQ@public.gmane.org>
On 21/08/17 21:27, Daniel Borkmann wrote:
> On 08/21/2017 08:36 PM, Edward Cree wrote:
>> On 19/08/17 00:37, Alexei Starovoitov wrote:
> [...]
>> I'm tempted to just rip out env->varlen_map_value_access and always check
>> the whole thing, because honestly I don't know what it was meant to do
>> originally or how it can ever do any useful pruning. While drastic, it
>> does cause your test case to pass.
>
> Original intention from 484611357c19 ("bpf: allow access into map
> value arrays") was that it wouldn't potentially make pruning worse
> if PTR_TO_MAP_VALUE_ADJ was not used, meaning that we wouldn't need
> to take reg state's min_value and max_value into account for state
> checking; this was basically due to min_value / max_value is being
> adjusted/tracked on every alu/jmp ops for involved regs (e.g.
> adjust_reg_min_max_vals() and others that mangle them) even if we
> have the case that no actual dynamic map access is used throughout
> the program. To give an example on net tree, the bpf_lxc.o prog's
> section increases from 36,386 to 68,226 when env->varlen_map_value_access
> is always true, so it does have an effect. Did you do some checks
> on this on net-next?
I tested with the cilium progs and saw no change in insn count. I
suspect that for the normal case I already killed this optimisation
when I did my unification patch, it was previously about ignoring
min/max values on all regs (including scalars), whereas on net-next
it only ignores them on map_value pointers; in practice this is
useless because we tend to still have the offset scalar sitting in
a register somewhere. (Come to think of it, this may have been
behind a large chunk of the #insn increase that my patches caused.)
Since we use umax_value in find_good_pkt_pointers() now (to check
against MAX_PACKET_OFF and ensure our reg->range is really ok), we
can't just stop caring about all min/max values just because we
haven't done any variable map accesses.
I don't see a way around this.
-Ed
^ permalink raw reply
* [PATCH] mt7601u: check memory allocation failure
From: Christophe JAILLET @ 2017-08-21 20:59 UTC (permalink / raw)
To: kubakici, kvalo, matthias.bgg
Cc: linux-wireless, netdev, linux-arm-kernel, linux-mediatek,
linux-kernel, kernel-janitors, Christophe JAILLET
Check memory allocation failure and return -ENOMEM in such a case, as
already done a few lines below
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
---
drivers/net/wireless/mediatek/mt7601u/dma.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/wireless/mediatek/mt7601u/dma.c b/drivers/net/wireless/mediatek/mt7601u/dma.c
index 660267b359e4..fa0173579d32 100644
--- a/drivers/net/wireless/mediatek/mt7601u/dma.c
+++ b/drivers/net/wireless/mediatek/mt7601u/dma.c
@@ -484,6 +484,8 @@ static int mt7601u_alloc_tx(struct mt7601u_dev *dev)
dev->tx_q = devm_kcalloc(dev->dev, __MT_EP_OUT_MAX,
sizeof(*dev->tx_q), GFP_KERNEL);
+ if (!dev->tx_q)
+ return -ENOMEM;
for (i = 0; i < __MT_EP_OUT_MAX; i++)
if (mt7601u_alloc_tx_queue(dev, &dev->tx_q[i]))
--
2.11.0
^ permalink raw reply related
* Re: [PATCH v3 net-next] bpf/verifier: track liveness for pruning
From: Daniel Borkmann @ 2017-08-21 21:00 UTC (permalink / raw)
To: Edward Cree, Alexei Starovoitov, davem, Alexei Starovoitov
Cc: netdev, linux-kernel, iovisor-dev
In-Reply-To: <128a84cd-234d-f505-95e2-7561db974981@solarflare.com>
On 08/21/2017 10:44 PM, Edward Cree wrote:
> On 21/08/17 21:27, Daniel Borkmann wrote:
>> On 08/21/2017 08:36 PM, Edward Cree wrote:
>>> On 19/08/17 00:37, Alexei Starovoitov wrote:
>> [...]
>>> I'm tempted to just rip out env->varlen_map_value_access and always check
>>> the whole thing, because honestly I don't know what it was meant to do
>>> originally or how it can ever do any useful pruning. While drastic, it
>>> does cause your test case to pass.
>>
>> Original intention from 484611357c19 ("bpf: allow access into map
>> value arrays") was that it wouldn't potentially make pruning worse
>> if PTR_TO_MAP_VALUE_ADJ was not used, meaning that we wouldn't need
>> to take reg state's min_value and max_value into account for state
>> checking; this was basically due to min_value / max_value is being
>> adjusted/tracked on every alu/jmp ops for involved regs (e.g.
>> adjust_reg_min_max_vals() and others that mangle them) even if we
>> have the case that no actual dynamic map access is used throughout
>> the program. To give an example on net tree, the bpf_lxc.o prog's
>> section increases from 36,386 to 68,226 when env->varlen_map_value_access
>> is always true, so it does have an effect. Did you do some checks
>> on this on net-next?
> I tested with the cilium progs and saw no change in insn count. I
> suspect that for the normal case I already killed this optimisation
> when I did my unification patch, it was previously about ignoring
> min/max values on all regs (including scalars), whereas on net-next
> it only ignores them on map_value pointers; in practice this is
> useless because we tend to still have the offset scalar sitting in
> a register somewhere. (Come to think of it, this may have been
> behind a large chunk of the #insn increase that my patches caused.)
Yeah, this would seem plausible.
> Since we use umax_value in find_good_pkt_pointers() now (to check
> against MAX_PACKET_OFF and ensure our reg->range is really ok), we
> can't just stop caring about all min/max values just because we
> haven't done any variable map accesses.
> I don't see a way around this.
Agree, was thinking the same. If there's not really a regression in
terms of complexity, then lets kill the flag.
^ permalink raw reply
* Re: [PATCH net-next 3/3 v6] drivers: net: ethernet: qualcomm: rmnet: Initial implementation
From: David Miller @ 2017-08-21 21:07 UTC (permalink / raw)
To: subashab; +Cc: netdev, fengguang.wu, dcbw, jiri, stephen, David.Laight, marcel
In-Reply-To: <1503120931-30092-4-git-send-email-subashab@codeaurora.org>
From: Subash Abhinov Kasiviswanathan <subashab@codeaurora.org>
Date: Fri, 18 Aug 2017 23:35:31 -0600
> diff --git a/drivers/net/ethernet/qualcomm/Makefile b/drivers/net/ethernet/qualcomm/Makefile
> index 92fa7c4..c4f38bd 100644
> --- a/drivers/net/ethernet/qualcomm/Makefile
> +++ b/drivers/net/ethernet/qualcomm/Makefile
> @@ -9,3 +9,5 @@ obj-$(CONFIG_QCA7000_UART) += qcauart.o
> qcauart-objs := qca_uart.o
>
> obj-y += emac/
> +
> +obj-$(CONFIG_RMNET) += rmnet/
> \ No newline at end of file
Missing final newline in this file.
> diff --git a/drivers/net/ethernet/qualcomm/rmnet/rmnet_config.c b/drivers/net/ethernet/qualcomm/rmnet/rmnet_config.c
> new file mode 100644
> index 0000000..5338bab
> --- /dev/null
> +++ b/drivers/net/ethernet/qualcomm/rmnet/rmnet_config.c
...
> +static inline int
> +rmnet_is_real_dev_registered(const struct net_device *real_dev)
> +{
Do not declare functions as inline in foo.c files, let the compiler decide.
> +static inline struct rmnet_real_dev_info*
> +__rmnet_get_real_dev_info(const struct net_device *real_dev)
> +{
Likewise.
> diff --git a/drivers/net/ethernet/qualcomm/rmnet/rmnet_handlers.c b/drivers/net/ethernet/qualcomm/rmnet/rmnet_handlers.c
> new file mode 100644
> index 0000000..f34fe9e
> --- /dev/null
> +++ b/drivers/net/ethernet/qualcomm/rmnet/rmnet_handlers.c
...
> +static inline void rmnet_set_skb_proto(struct sk_buff *skb)
> +{
Likewise.
> diff --git a/drivers/net/ethernet/qualcomm/rmnet/rmnet_main.c b/drivers/net/ethernet/qualcomm/rmnet/rmnet_main.c
> new file mode 100644
> index 0000000..80c3920
...
> +/* Startup/Shutdown */
> +
> +static int __init rmnet_init(void)
> +{
> + rmnet_config_init();
> + return 0;
> +}
> +
> +static void __exit rmnet_exit(void)
> +{
> + rmnet_config_exit();
> +}
> +
> +module_init(rmnet_init)
> +module_exit(rmnet_exit)
> +MODULE_LICENSE("GPL v2");
Unless you intend to do something different here, having a completely separate foo.c file
just to invoke functions in another file at module init and exit time is wasteful. Just
do the module_init()/module_exit() where the rmnet_config_{init,exit}() functions are.
^ permalink raw reply
* Re: [RFC] about net: Fix inconsistent teardown and release of private netdev state.
From: David Miller @ 2017-08-21 21:13 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1503114001.14953.8.camel@edumazet-glaptop3.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Fri, 18 Aug 2017 20:40:01 -0700
> Let look at tun->pcpu_stats, for example.
>
> It is allocated at line 1831, before the register_netdevice()
>
> drivers/net/tun.c does not provide ndo_init()
I see the problem now.
And it's done this way because several steps need to occur, with
various kinds of dependencies, before the register_netdevice() call is
made.
I'll see if I can untangle this somehow.
^ permalink raw reply
* Re: [PATCH v3 net-next] bpf/verifier: track liveness for pruning
From: Alexei Starovoitov via iovisor-dev @ 2017-08-21 21:18 UTC (permalink / raw)
To: Edward Cree, davem-fT/PcQaiUtIeIZ0/mPfg9Q, Alexei Starovoitov,
Daniel Borkmann
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, iovisor-dev,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <e4075575-b12c-5c6f-bac3-0c7ba8e04802-s/n/eUQHGBpZroRs9YW3xA@public.gmane.org>
On 8/21/17 1:24 PM, Edward Cree wrote:
> On 18/08/17 15:16, Edward Cree wrote:
>> On 18/08/17 04:21, Alexei Starovoitov wrote:
>>> It seems you're trying to sort-of do per-fake-basic block liveness
>>> analysis, but our state_list_marks are not correct if we go with
>>> canonical basic block definition, since we mark the jump insn and
>>> not insn after the branch and not every basic block boundary is
>>> properly detected.
>> I think the reason this works is that jump insns can't do writes.
>> [snip]
>> the sl->state will never have any write marks and it'll all just work.
>> But I should really test that!
> I tested this, and found that, no, sl->state can have write marks, and the
> algorithm will get the wrong answer in that case. So I've got a patch to
> make the first iteration ignore write marks, as part of a series which I
> will post shortly. When I do so, please re-do your tests with adding
> state_list_marks in strange and exciting places; it should work wherever
> you put them. Like you say, it "magically doesn't depend on proper basic
> block boundaries", and that's because really pruning is just a kind of
> checkpointing that just happens to be most effective when done just after
> a jump (pop_stack).
>
> Can I have a SOB for your "grr" test program, so I can include it in the
> series?
yes. of course. just give the test some reasonable name :)
^ permalink raw reply
* Re: [PATCH v3 net-next] bpf/verifier: track liveness for pruning
From: Alexei Starovoitov via iovisor-dev @ 2017-08-21 21:23 UTC (permalink / raw)
To: Daniel Borkmann, Edward Cree, davem-fT/PcQaiUtIeIZ0/mPfg9Q,
Alexei Starovoitov
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, iovisor-dev,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <599B49DB.6010008-FeC+5ew28dpmcu3hnIyYJQ@public.gmane.org>
On 8/21/17 2:00 PM, Daniel Borkmann wrote:
> On 08/21/2017 10:44 PM, Edward Cree wrote:
>> On 21/08/17 21:27, Daniel Borkmann wrote:
>>> On 08/21/2017 08:36 PM, Edward Cree wrote:
>>>> On 19/08/17 00:37, Alexei Starovoitov wrote:
>>> [...]
>>>> I'm tempted to just rip out env->varlen_map_value_access and always
>>>> check
>>>> the whole thing, because honestly I don't know what it was meant
>>>> to do
>>>> originally or how it can ever do any useful pruning. While
>>>> drastic, it
>>>> does cause your test case to pass.
>>>
>>> Original intention from 484611357c19 ("bpf: allow access into map
>>> value arrays") was that it wouldn't potentially make pruning worse
>>> if PTR_TO_MAP_VALUE_ADJ was not used, meaning that we wouldn't need
>>> to take reg state's min_value and max_value into account for state
>>> checking; this was basically due to min_value / max_value is being
>>> adjusted/tracked on every alu/jmp ops for involved regs (e.g.
>>> adjust_reg_min_max_vals() and others that mangle them) even if we
>>> have the case that no actual dynamic map access is used throughout
>>> the program. To give an example on net tree, the bpf_lxc.o prog's
>>> section increases from 36,386 to 68,226 when
>>> env->varlen_map_value_access
>>> is always true, so it does have an effect. Did you do some checks
>>> on this on net-next?
>> I tested with the cilium progs and saw no change in insn count. I
>> suspect that for the normal case I already killed this optimisation
>> when I did my unification patch, it was previously about ignoring
>> min/max values on all regs (including scalars), whereas on net-next
>> it only ignores them on map_value pointers; in practice this is
>> useless because we tend to still have the offset scalar sitting in
>> a register somewhere. (Come to think of it, this may have been
>> behind a large chunk of the #insn increase that my patches caused.)
>
> Yeah, this would seem plausible.
>
>> Since we use umax_value in find_good_pkt_pointers() now (to check
>> against MAX_PACKET_OFF and ensure our reg->range is really ok), we
>> can't just stop caring about all min/max values just because we
>> haven't done any variable map accesses.
>> I don't see a way around this.
>
> Agree, was thinking the same. If there's not really a regression in
> terms of complexity, then lets kill the flag.
+1
diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
index 2489e67b65f6..908d13b2a2aa 100644
--- a/kernel/bpf/verifier.c
+++ b/kernel/bpf/verifier.c
@@ -3582,7 +3582,7 @@ static int do_check(struct bpf_verifier_env *env)
init_reg_state(regs);
state->parent = NULL;
insn_idx = 0;
- env->varlen_map_value_access = false;
+ env->varlen_map_value_access = true;
makes _zero_ difference on cilium*.o tests, so let's just kill
that workaround.
^ permalink raw reply related
* Re: [PATCH] mt7601u: check memory allocation failure
From: Jakub Kicinski @ 2017-08-21 21:34 UTC (permalink / raw)
To: Christophe JAILLET
Cc: kvalo, matthias.bgg, linux-wireless, netdev, linux-arm-kernel,
linux-mediatek, linux-kernel, kernel-janitors
In-Reply-To: <20170821205956.20859-1-christophe.jaillet@wanadoo.fr>
On Mon, 21 Aug 2017 22:59:56 +0200, Christophe JAILLET wrote:
> Check memory allocation failure and return -ENOMEM in such a case, as
> already done a few lines below
>
> Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Acked-by: Jakub Kicinski <kubakici@wp.pl>
Thanks!
^ permalink raw reply
* [PATCH net] udp: on peeking bad csum, drop packets even if not at head
From: Willem de Bruijn @ 2017-08-21 21:39 UTC (permalink / raw)
To: netdev; +Cc: davem, pabeni, Willem de Bruijn
From: Willem de Bruijn <willemb@google.com>
When peeking, if a bad csum is discovered, the skb is unlinked from
the queue with __sk_queue_drop_skb and the peek operation restarted.
__sk_queue_drop_skb only drops packets that match the queue head. With
sk_peek_off, the skb need not be at head, causing the call to fail and
the same skb to be found again on restart.
Walk the queue to find the correct skb. Limit the walk to sk_peek_off,
to bound cycle cost to at most twice the original skb_queue_walk in
__skb_try_recv_from_queue.
The operation may race with updates to sk_peek_off. As the operation
is retried, it will eventually succeed.
Signed-off-by: Willem de Bruijn <willemb@google.com>
---
Simpler would be to check (skb->csum_complete_sw && !sbk->csum_valid)
in __skb_try_recv_from_queue to ignore skbs with bad checksum. But
__udp_lib_checksum_complete does not update those fields if called
while peeking, because the skb is shared. I found no way around that.
---
net/core/datagram.c | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/net/core/datagram.c b/net/core/datagram.c
index a21ca8dee5ea..5cf32b2372d3 100644
--- a/net/core/datagram.c
+++ b/net/core/datagram.c
@@ -360,9 +360,17 @@ int __sk_queue_drop_skb(struct sock *sk, struct sk_buff_head *sk_queue,
int err = 0;
if (flags & MSG_PEEK) {
+ struct sk_buff *lskb;
+ int off = sk_peek_offset(sk, flags);
+
err = -ENOENT;
spin_lock_bh(&sk_queue->lock);
- if (skb == skb_peek(sk_queue)) {
+ lskb = skb_peek(sk_queue);
+ while (lskb != skb && lskb && off >= lskb->len) {
+ off -= lskb->len;
+ lskb = skb_peek_next(lskb, sk_queue);
+ }
+ if (lskb == skb) {
__skb_unlink(skb, sk_queue);
refcount_dec(&skb->users);
if (destructor)
--
2.14.1.480.gb18f417b89-goog
^ permalink raw reply related
* Re: [PATCH] mt7601u: check memory allocation failure
From: Jakub Kicinski @ 2017-08-21 21:41 UTC (permalink / raw)
To: Christophe JAILLET
Cc: kvalo, matthias.bgg, linux-wireless, netdev, linux-arm-kernel,
linux-mediatek, linux-kernel, kernel-janitors
In-Reply-To: <20170821143430.635e4b92@cakuba.netronome.com>
On Mon, 21 Aug 2017 14:34:30 -0700, Jakub Kicinski wrote:
> On Mon, 21 Aug 2017 22:59:56 +0200, Christophe JAILLET wrote:
> > Check memory allocation failure and return -ENOMEM in such a case, as
> > already done a few lines below
> >
> > Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
>
> Acked-by: Jakub Kicinski <kubakici@wp.pl>
Wait, I take that back. This code is a bit weird. We would return an
error, then mt7601u_dma_init() will call mt7601u_free_tx_queue() which
doesn't check for tx_q == NULL condition.
Looks like mt7601u_free_tx() has to check for dev->tx_q == NULL and
return early if that's the case. Or mt7601u_alloc_tx() should really
clean things up on it's own on failure. Ugh.
^ permalink raw reply
* [PATCH net-next,1/4] hv_netvsc: Clean up unused parameter from netvsc_get_hash()
From: Haiyang Zhang @ 2017-08-21 21:55 UTC (permalink / raw)
To: davem, netdev; +Cc: haiyangz, kys, olaf, vkuznets, linux-kernel
From: Haiyang Zhang <haiyangz@microsoft.com>
The parameter "sk" is not in use.
Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
---
drivers/net/hyperv/netvsc_drv.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/hyperv/netvsc_drv.c b/drivers/net/hyperv/netvsc_drv.c
index b33f050..4677d21 100644
--- a/drivers/net/hyperv/netvsc_drv.c
+++ b/drivers/net/hyperv/netvsc_drv.c
@@ -193,7 +193,7 @@ static int netvsc_close(struct net_device *net)
/* Azure hosts don't support non-TCP port numbers in hashing yet. We compute
* hash for non-TCP traffic with only IP numbers.
*/
-static inline u32 netvsc_get_hash(struct sk_buff *skb, struct sock *sk)
+static inline u32 netvsc_get_hash(struct sk_buff *skb)
{
struct flow_keys flow;
u32 hash;
@@ -227,7 +227,7 @@ static inline int netvsc_get_tx_queue(struct net_device *ndev,
struct sock *sk = skb->sk;
int q_idx;
- q_idx = ndc->tx_send_table[netvsc_get_hash(skb, sk) &
+ q_idx = ndc->tx_send_table[netvsc_get_hash(skb) &
(VRSS_SEND_TAB_SIZE - 1)];
/* If queue index changed record the new value */
--
1.7.1
^ permalink raw reply related
* [PATCH net-next,2/4] hv_netvsc: Clean up unused parameter from netvsc_get_rss_hash_opts()
From: Haiyang Zhang @ 2017-08-21 21:55 UTC (permalink / raw)
To: davem, netdev; +Cc: haiyangz, kys, olaf, vkuznets, linux-kernel
In-Reply-To: <1503352555-9256-1-git-send-email-haiyangz@exchange.microsoft.com>
From: Haiyang Zhang <haiyangz@microsoft.com>
The parameter "nvdev" is not in use.
Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
---
drivers/net/hyperv/netvsc_drv.c | 5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/net/hyperv/netvsc_drv.c b/drivers/net/hyperv/netvsc_drv.c
index 4677d21..d8612b1 100644
--- a/drivers/net/hyperv/netvsc_drv.c
+++ b/drivers/net/hyperv/netvsc_drv.c
@@ -1228,8 +1228,7 @@ static void netvsc_get_strings(struct net_device *dev, u32 stringset, u8 *data)
}
static int
-netvsc_get_rss_hash_opts(struct netvsc_device *nvdev,
- struct ethtool_rxnfc *info)
+netvsc_get_rss_hash_opts(struct ethtool_rxnfc *info)
{
info->data = RXH_IP_SRC | RXH_IP_DST;
@@ -1267,7 +1266,7 @@ static void netvsc_get_strings(struct net_device *dev, u32 stringset, u8 *data)
return 0;
case ETHTOOL_GRXFH:
- return netvsc_get_rss_hash_opts(nvdev, info);
+ return netvsc_get_rss_hash_opts(info);
}
return -EOPNOTSUPP;
}
--
1.7.1
^ permalink raw reply related
* [PATCH net-next,3/4] hv_netvsc: Add ethtool handler to set and get UDP hash levels
From: Haiyang Zhang @ 2017-08-21 21:55 UTC (permalink / raw)
To: davem, netdev; +Cc: haiyangz, kys, olaf, vkuznets, linux-kernel
In-Reply-To: <1503352555-9256-1-git-send-email-haiyangz@exchange.microsoft.com>
From: Haiyang Zhang <haiyangz@microsoft.com>
The patch add the functions to switch UDP hash level between
L3 and L4 by ethtool command. UDP over IPv4 and v6 can be set
differently. The default hash level is L4. We currently only
allow switching TX hash level from within the guests.
On Azure, fragmented UDP packets have high loss rate with L4
hashing. Using L3 hashing is recommended in this case.
For example, for UDP over IPv4 on eth0:
To include UDP port numbers in hasing:
ethtool -N eth0 rx-flow-hash udp4 sdfn
To exclude UDP port numbers in hasing:
ethtool -N eth0 rx-flow-hash udp4 sd
To show UDP hash level:
ethtool -n eth0 rx-flow-hash udp4
Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
---
drivers/net/hyperv/hyperv_net.h | 2 +
drivers/net/hyperv/netvsc_drv.c | 78 +++++++++++++++++++++++++++++++++++----
2 files changed, 72 insertions(+), 8 deletions(-)
diff --git a/drivers/net/hyperv/hyperv_net.h b/drivers/net/hyperv/hyperv_net.h
index 9198dd1..ff1c0c8 100644
--- a/drivers/net/hyperv/hyperv_net.h
+++ b/drivers/net/hyperv/hyperv_net.h
@@ -720,6 +720,8 @@ struct net_device_context {
u32 tx_send_table[VRSS_SEND_TAB_SIZE];
/* Ethtool settings */
+ bool udp4_l4_hash;
+ bool udp6_l4_hash;
u8 duplex;
u32 speed;
struct netvsc_ethtool_stats eth_stats;
diff --git a/drivers/net/hyperv/netvsc_drv.c b/drivers/net/hyperv/netvsc_drv.c
index d8612b1..c0c4c91 100644
--- a/drivers/net/hyperv/netvsc_drv.c
+++ b/drivers/net/hyperv/netvsc_drv.c
@@ -190,10 +190,12 @@ static int netvsc_close(struct net_device *net)
return ppi;
}
-/* Azure hosts don't support non-TCP port numbers in hashing yet. We compute
- * hash for non-TCP traffic with only IP numbers.
+/* Azure hosts don't support non-TCP port numbers in hashing for fragmented
+ * packets. We can use ethtool to change UDP hash level when necessary.
*/
-static inline u32 netvsc_get_hash(struct sk_buff *skb)
+static inline u32 netvsc_get_hash(
+ struct sk_buff *skb,
+ const struct net_device_context *ndc)
{
struct flow_keys flow;
u32 hash;
@@ -204,7 +206,11 @@ static inline u32 netvsc_get_hash(struct sk_buff *skb)
if (!skb_flow_dissect_flow_keys(skb, &flow, 0))
return 0;
- if (flow.basic.ip_proto == IPPROTO_TCP) {
+ if (flow.basic.ip_proto == IPPROTO_TCP ||
+ (flow.basic.ip_proto == IPPROTO_UDP &&
+ ((flow.basic.n_proto == htons(ETH_P_IP) && ndc->udp4_l4_hash) ||
+ (flow.basic.n_proto == htons(ETH_P_IPV6) &&
+ ndc->udp6_l4_hash)))) {
return skb_get_hash(skb);
} else {
if (flow.basic.n_proto == htons(ETH_P_IP))
@@ -227,7 +233,7 @@ static inline int netvsc_get_tx_queue(struct net_device *ndev,
struct sock *sk = skb->sk;
int q_idx;
- q_idx = ndc->tx_send_table[netvsc_get_hash(skb) &
+ q_idx = ndc->tx_send_table[netvsc_get_hash(skb, ndc) &
(VRSS_SEND_TAB_SIZE - 1)];
/* If queue index changed record the new value */
@@ -891,6 +897,9 @@ static void netvsc_init_settings(struct net_device *dev)
{
struct net_device_context *ndc = netdev_priv(dev);
+ ndc->udp4_l4_hash = true;
+ ndc->udp6_l4_hash = true;
+
ndc->speed = SPEED_UNKNOWN;
ndc->duplex = DUPLEX_FULL;
}
@@ -1228,7 +1237,8 @@ static void netvsc_get_strings(struct net_device *dev, u32 stringset, u8 *data)
}
static int
-netvsc_get_rss_hash_opts(struct ethtool_rxnfc *info)
+netvsc_get_rss_hash_opts(struct net_device_context *ndc,
+ struct ethtool_rxnfc *info)
{
info->data = RXH_IP_SRC | RXH_IP_DST;
@@ -1236,9 +1246,20 @@ static void netvsc_get_strings(struct net_device *dev, u32 stringset, u8 *data)
case TCP_V4_FLOW:
case TCP_V6_FLOW:
info->data |= RXH_L4_B_0_1 | RXH_L4_B_2_3;
- /* fallthrough */
+ break;
+
case UDP_V4_FLOW:
+ if (ndc->udp4_l4_hash)
+ info->data |= RXH_L4_B_0_1 | RXH_L4_B_2_3;
+
+ break;
+
case UDP_V6_FLOW:
+ if (ndc->udp6_l4_hash)
+ info->data |= RXH_L4_B_0_1 | RXH_L4_B_2_3;
+
+ break;
+
case IPV4_FLOW:
case IPV6_FLOW:
break;
@@ -1266,11 +1287,51 @@ static void netvsc_get_strings(struct net_device *dev, u32 stringset, u8 *data)
return 0;
case ETHTOOL_GRXFH:
- return netvsc_get_rss_hash_opts(info);
+ return netvsc_get_rss_hash_opts(ndc, info);
}
return -EOPNOTSUPP;
}
+static int netvsc_set_rss_hash_opts(struct net_device_context *ndc,
+ struct ethtool_rxnfc *info)
+{
+ if (info->data == (RXH_IP_SRC | RXH_IP_DST |
+ RXH_L4_B_0_1 | RXH_L4_B_2_3)) {
+ if (info->flow_type == UDP_V4_FLOW)
+ ndc->udp4_l4_hash = true;
+ else if (info->flow_type == UDP_V6_FLOW)
+ ndc->udp6_l4_hash = true;
+ else
+ return -EOPNOTSUPP;
+
+ return 0;
+ }
+
+ if (info->data == (RXH_IP_SRC | RXH_IP_DST)) {
+ if (info->flow_type == UDP_V4_FLOW)
+ ndc->udp4_l4_hash = false;
+ else if (info->flow_type == UDP_V6_FLOW)
+ ndc->udp6_l4_hash = false;
+ else
+ return -EOPNOTSUPP;
+
+ return 0;
+ }
+
+ return -EOPNOTSUPP;
+}
+
+static int
+netvsc_set_rxnfc(struct net_device *ndev, struct ethtool_rxnfc *info)
+{
+ struct net_device_context *ndc = netdev_priv(ndev);
+
+ if (info->cmd == ETHTOOL_SRXFH)
+ return netvsc_set_rss_hash_opts(ndc, info);
+
+ return -EOPNOTSUPP;
+}
+
#ifdef CONFIG_NET_POLL_CONTROLLER
static void netvsc_poll_controller(struct net_device *dev)
{
@@ -1469,6 +1530,7 @@ static int netvsc_set_ringparam(struct net_device *ndev,
.set_channels = netvsc_set_channels,
.get_ts_info = ethtool_op_get_ts_info,
.get_rxnfc = netvsc_get_rxnfc,
+ .set_rxnfc = netvsc_set_rxnfc,
.get_rxfh_key_size = netvsc_get_rxfh_key_size,
.get_rxfh_indir_size = netvsc_rss_indir_size,
.get_rxfh = netvsc_get_rxfh,
--
1.7.1
^ permalink raw reply related
* [PATCH net-next,4/4] hv_netvsc: Update netvsc Document for UDP hash level setting
From: Haiyang Zhang @ 2017-08-21 21:55 UTC (permalink / raw)
To: davem, netdev; +Cc: haiyangz, kys, olaf, vkuznets, linux-kernel
In-Reply-To: <1503352555-9256-1-git-send-email-haiyangz@exchange.microsoft.com>
From: Haiyang Zhang <haiyangz@microsoft.com>
Update Documentation/networking/netvsc.txt for UDP hash level setting
and related info.
Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
---
Documentation/networking/netvsc.txt | 22 +++++++++++++++++-----
1 files changed, 17 insertions(+), 5 deletions(-)
diff --git a/Documentation/networking/netvsc.txt b/Documentation/networking/netvsc.txt
index 4ddb4e4..fa8d863 100644
--- a/Documentation/networking/netvsc.txt
+++ b/Documentation/networking/netvsc.txt
@@ -21,11 +21,23 @@ Features
--------------------
Hyper-V supports receive side scaling. For TCP, packets are
distributed among available queues based on IP address and port
- number. Current versions of Hyper-V host, only distribute UDP
- packets based on the IP source and destination address.
- The port number is not used as part of the hash value for UDP.
- Fragmented IP packets are not distributed between queues;
- all fragmented packets arrive on the first channel.
+ number.
+
+ For UDP, we can switch UDP hash level between L3 and L4 by ethtool
+ command. UDP over IPv4 and v6 can be set differently. The default
+ hash level is L4. We currently only allow switching TX hash level
+ from within the guests.
+
+ On Azure, fragmented UDP packets have high loss rate with L4
+ hashing. Using L3 hashing is recommended in this case.
+
+ For example, for UDP over IPv4 on eth0:
+ To include UDP port numbers in hasing:
+ ethtool -N eth0 rx-flow-hash udp4 sdfn
+ To exclude UDP port numbers in hasing:
+ ethtool -N eth0 rx-flow-hash udp4 sd
+ To show UDP hash level:
+ ethtool -n eth0 rx-flow-hash udp4
Generic Receive Offload, aka GRO
--------------------------------
--
1.7.1
^ permalink raw reply related
* [PATCH v2] mt7601u: check memory allocation failure
From: Christophe JAILLET @ 2017-08-21 22:06 UTC (permalink / raw)
To: kubakici, kvalo, matthias.bgg
Cc: linux-wireless, netdev, linux-arm-kernel, linux-mediatek,
linux-kernel, kernel-janitors, Christophe JAILLET
Check memory allocation failure and return -ENOMEM in such a case, as
already done a few lines below.
As 'dev->tx_q' can be NULL, we also need to check for that in
'mt7601u_free_tx()', and return early.
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
---
v2: avoid another NULL pointer dereference in 'mt7601u_free_tx()' if the
allocation had failed.
---
drivers/net/wireless/mediatek/mt7601u/dma.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/net/wireless/mediatek/mt7601u/dma.c b/drivers/net/wireless/mediatek/mt7601u/dma.c
index 660267b359e4..7f3e3983b781 100644
--- a/drivers/net/wireless/mediatek/mt7601u/dma.c
+++ b/drivers/net/wireless/mediatek/mt7601u/dma.c
@@ -457,6 +457,9 @@ static void mt7601u_free_tx(struct mt7601u_dev *dev)
{
int i;
+ if (!dev->tx_q)
+ return;
+
for (i = 0; i < __MT_EP_OUT_MAX; i++)
mt7601u_free_tx_queue(&dev->tx_q[i]);
}
@@ -484,6 +487,8 @@ static int mt7601u_alloc_tx(struct mt7601u_dev *dev)
dev->tx_q = devm_kcalloc(dev->dev, __MT_EP_OUT_MAX,
sizeof(*dev->tx_q), GFP_KERNEL);
+ if (!dev->tx_q)
+ return -ENOMEM;
for (i = 0; i < __MT_EP_OUT_MAX; i++)
if (mt7601u_alloc_tx_queue(dev, &dev->tx_q[i]))
--
2.11.0
^ permalink raw reply related
* Re: [PATCH net-next 03/11] net: dsa: debugfs: add tree
From: Florian Fainelli @ 2017-08-21 22:06 UTC (permalink / raw)
To: Vivien Didelot, netdev
Cc: linux-kernel, kernel, David S. Miller, Andrew Lunn,
Egil Hjelmeland, John Crispin, Woojung Huh, Sean Wang,
Volodymyr Bendiuga, Nikita Yushchenko, Maxime Hadjinlian,
Chris Healy, Maxim Uvarov, Stefan Eichenberger, Jason Cobham,
Juergen Borleis, Tobias Waldekranz
In-Reply-To: <20170814222242.10643-4-vivien.didelot@savoirfairelinux.com>
On 08/14/2017 03:22 PM, Vivien Didelot wrote:
> This commit adds the boiler plate to create a DSA related debug
> filesystem entry as well as a "tree" file, containing the tree index.
>
> # cat switch1/tree
> 0
>
> Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
--
Florian
^ 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