* Re: [PATCH] cgroup: move CONFIG_SOCK_CGROUP_DATA to init/Kconfig
From: David Miller @ 2017-01-11 14:48 UTC (permalink / raw)
To: arnd; +Cc: netdev, ast, luto, augustocaringi, linux-kernel
In-Reply-To: <20170110120825.2984218-1-arnd@arndb.de>
From: Arnd Bergmann <arnd@arndb.de>
Date: Tue, 10 Jan 2017 13:08:06 +0100
> We now 'select SOCK_CGROUP_DATA' but Kconfig complains that this is
> not right when CONFIG_NET is disabled and there is no socket interface:
>
> warning: (CGROUP_BPF) selects SOCK_CGROUP_DATA which has unmet direct dependencies (NET)
>
> I don't know what the correct solution for this is, but simply removing
> the dependency on NET from SOCK_CGROUP_DATA by moving it out of the
> 'if NET' section avoids the warning and does not produce other build
> errors.
>
> Fixes: 483c4933ea09 ("cgroup: Fix CGROUP_BPF config")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> There was an earlier patch by Augusto Mecking Caringi, which added
> a dependency, see https://lkml.org/lkml/2017/1/2/296.
>
> I could not figure out whether CGROUP_BPF is meaningful without
> CONFIG_NET, my version of the patch assumes that it is.
> Applying either my version Augusto's to v4.10-rc will kill the
> warning.
CGROUP_BPF doesn't is not currently meaningful without CONFIG_NET,
and especially SOCK_CGROUP_DATA is not meaningful without CONFIG_NET.
Patch applied, thanks.
^ permalink raw reply
* Re: [PATCH v2 0/2] remove dwc_eth_qos and rename stmicro/stmmac
From: Alexandre Torgue @ 2017-01-11 14:39 UTC (permalink / raw)
To: Joao Pinto, davem; +Cc: lars.persson, niklass, peppe.cavallaro, netdev
In-Reply-To: <a91d92f0-21a5-2225-88c3-162c8fb005f5@synopsys.com>
On 01/11/2017 03:29 PM, Joao Pinto wrote:
>
> Alex,
>
> Às 2:25 PM de 1/11/2017, Alexandre Torgue escreveu:
>> Jao,
>>
>> On 01/11/2017 12:54 PM, Joao Pinto wrote:
>>>
>>> Hi Alex,
>>>
>>> Às 11:39 AM de 1/11/2017, Alexandre Torgue escreveu:
>>>> Hi Jao,
>>>>
>>>> On 01/10/2017 03:52 PM, Joao Pinto wrote:
>>>>> This patch set removes the synopsys/dwc_eth_qos since it was merged recently
>>>>> to stmmac (dwmac-dwc-qos-eth glue driver).
>>>>>
>>>>> It also renames stmicro/stmmac to synopsys/ since it is a standard ethernet
>>>>> software package regarding synopsys ethernet controllers, supporting the
>>>>> majority of Synopsys Ethernet IPs.
>>>>
>>>> I understand the reason to rename stmmac driver. The only risk I see is that
>>>> usual user will be a little bit lost to find code. It seems there no risk of
>>>> backward compatibility with current/old DT (I assume you already checked this
>>>> point).
>>>
>>> I understand your concern, but for the Synopsys IPs users will be clearer what
>>> drivers to use and what current stmmac has to offer.
>>
>> I agree.
>>
>>>
>>> In terms of tests, I tested it and worked out of the box because the same
>>> Kconfig IDs were used assuring the retro-compatibility that David suggested a
>>> few weeks ago. For DT users no problems are expected as well.
>>
>> Ok, sounds good.
>>
>> I see that you rename also Documentation/devicetree/bindings/net/stmmac.txt. You
>> have also to change some words inside as it talks about Stmicroelectronics.
>
> You are right. Going to change that and send a v3. Counting on your ack :)
I continue to review ;)
There is another point to talk. It will be strange to have the driver
named "synopsys" but all file inside will continue to be called "stmmac"
(and also function inside files). So either you plan to keep it as it is
(and it is a little bit confusing) or you plan to change all file name +
function name (+ few variable name) ?
regards
Alex
> Thanks!
>
>>
>> Regards
>> Alex
>>
>>>
>>> Thanks,
>>> Joao
>>>
>>>> Let's see what David think about that but if there no risk of backward
>>>> compatibility with DT, I agree with the series.
>>>>
>>>> Regards
>>>> Alex
>>>>
>>>>
>>>>
>>>>>
>>>>> In the future we should make an effort to migrate to this new synopsys/
>>>>> driver package all the Ethernet Synopsys IP drivers scattered in net/ethernet.
>>>>>
>>>>> Joao Pinto (2):
>>>>> synopsys: remove dwc_eth_qos driver
>>>>> stmmac: rename it to synopsys
>>>>>
>>>>> .../bindings/net/{stmmac.txt => synopsys.txt} | 0
>>>>> MAINTAINERS | 11 +-
>>>>> arch/arm/configs/multi_v7_defconfig | 3 +-
>>>>> drivers/net/ethernet/Kconfig | 3 +-
>
^ permalink raw reply
* Re: [PATCH] sctp: Fix spelling mistake: "Atempt" -> "Attempt"
From: Neil Horman @ 2017-01-11 14:39 UTC (permalink / raw)
To: Colin King
Cc: Vlad Yasevich, David S . Miller, linux-sctp, netdev, linux-kernel
In-Reply-To: <20170110225306.14880-1-colin.king@canonical.com>
On Tue, Jan 10, 2017 at 10:53:06PM +0000, Colin King wrote:
> From: Colin Ian King <colin.king@canonical.com>
>
> Trivial fix to spelling mistake in WARN_ONCE message
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
> ---
> net/sctp/outqueue.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/net/sctp/outqueue.c b/net/sctp/outqueue.c
> index e540826..34efaa4 100644
> --- a/net/sctp/outqueue.c
> +++ b/net/sctp/outqueue.c
> @@ -1048,7 +1048,7 @@ static void sctp_outq_flush(struct sctp_outq *q, int rtx_timeout, gfp_t gfp)
> (new_transport->state == SCTP_PF)))
> new_transport = asoc->peer.active_path;
> if (new_transport->state == SCTP_UNCONFIRMED) {
> - WARN_ONCE(1, "Atempt to send packet on unconfirmed path.");
> + WARN_ONCE(1, "Attempt to send packet on unconfirmed path.");
> sctp_chunk_fail(chunk, 0);
> sctp_chunk_free(chunk);
> continue;
> --
> 2.10.2
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sctp" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
^ permalink raw reply
* Re: [PATCH] wext: handle NULL exta data in iwe_stream_add_point better
From: Johannes Berg @ 2017-01-11 14:38 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linux-wireless, David S. Miller, netdev, linux-kernel
In-Reply-To: <20170111143532.485827-1-arnd@arndb.de>
On Wed, 2017-01-11 at 15:35 +0100, Arnd Bergmann wrote:
> gcc-7 complains that wl3501_cs passes NULL into a function that
> then uses the argument as the input for memcpy:
>
> drivers/net/wireless/wl3501_cs.c: In function 'wl3501_get_scan':
> include/net/iw_handler.h:559:3: error: argument 2 null where non-null
> expected [-Werror=nonnull]
> memcpy(stream + point_len, extra, iwe->u.data.length);
I love wext ;-)
> This works fine here because iwe->u.data.length is guaranteed to be
> NULL, and the memcpy doesn't actually have an effect.
I think you mean 0, not NULL, but I can fix that when I apply it.
johannes
^ permalink raw reply
* Re: net/atm: warning in alloc_tx/__might_sleep
From: Chas Williams @ 2017-01-11 14:37 UTC (permalink / raw)
To: Andrey Konovalov, David S. Miller, Alexey Kuznetsov, James Morris,
Hideaki YOSHIFUJI, Patrick McHardy, netdev, LKML, Al Viro
Cc: Dmitry Vyukov, Kostya Serebryany, Eric Dumazet, syzkaller
In-Reply-To: <CAAeHK+yZ16SKcmJbv2ARafGgAuX2wwQNE0HGdiFy1WgqPjxLMg@mail.gmail.com>
On Mon, 2017-01-09 at 18:20 +0100, Andrey Konovalov wrote:
> Hi!
>
> I've got the following error report while running the syzkaller fuzzer.
>
> On commit a121103c922847ba5010819a3f250f1f7fc84ab8 (4.10-rc3).
>
> A reproducer is attached.
>
> ------------[ cut here ]------------
> WARNING: CPU: 0 PID: 4114 at kernel/sched/core.c:7737 __might_sleep+0x149/0x1a0
> do not call blocking ops when !TASK_RUNNING; state=1 set at
> [<ffffffff813fcb22>] prepare_to_wait+0x182/0x530
> Modules linked in:
> CPU: 0 PID: 4114 Comm: a.out Not tainted 4.10.0-rc3+ #59
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
> Call Trace:
> __dump_stack lib/dump_stack.c:15
> dump_stack+0x292/0x398 lib/dump_stack.c:51
> __warn+0x19f/0x1e0 kernel/panic.c:547
> warn_slowpath_fmt+0xc5/0x110 kernel/panic.c:562
> __might_sleep+0x149/0x1a0 kernel/sched/core.c:7732
> slab_pre_alloc_hook mm/slab.h:408
> slab_alloc_node mm/slub.c:2634
> kmem_cache_alloc_node+0x14a/0x280 mm/slub.c:2744
> __alloc_skb+0x10f/0x800 net/core/skbuff.c:219
> alloc_skb ./include/linux/skbuff.h:926
> alloc_tx net/atm/common.c:75
This is likely alloc_skb(..., GFP_KERNEL) in alloc_tx(). The simplest
fix for this would be simply to switch this GFP_ATOMIC. See if this is
any better.
diff --git a/net/atm/common.c b/net/atm/common.c
index a3ca922..d84220c 100644
--- a/net/atm/common.c
+++ b/net/atm/common.c
@@ -72,7 +72,7 @@ static struct sk_buff *alloc_tx(struct atm_vcc *vcc, unsigned int size)
sk_wmem_alloc_get(sk), size, sk->sk_sndbuf);
return NULL;
}
- while (!(skb = alloc_skb(size, GFP_KERNEL)))
+ while (!(skb = alloc_skb(size, GFP_ATOMIC)))
schedule();
pr_debug("%d += %d\n", sk_wmem_alloc_get(sk), skb->truesize);
atomic_add(skb->truesize, &sk->sk_wmem_alloc);
^ permalink raw reply related
* [PATCH] bnxt_en: hide unused bnxt_get_max_func_{vnics,rss_ctxs} functions
From: Arnd Bergmann @ 2017-01-11 14:36 UTC (permalink / raw)
To: Michael Chan
Cc: Arnd Bergmann, David S. Miller, Prashant Sreedharan,
Satish Baddipadige, Alexander Duyck, netdev, linux-kernel
There are lots of #ifdefs in this file, and a recent patch got one
of them wrong, leading to a harmless warning in some randconfig
builds:
ethernet/broadcom/bnxt/bnxt.c:4956:21: error: 'bnxt_get_max_func_vnics' defined but not used [-Werror=unused-function]
ethernet/broadcom/bnxt/bnxt.c:4947:21: error: 'bnxt_get_max_func_rss_ctxs' defined but not used [-Werror=unused-function]
Ideally we'd just remove all of them and use 'if (IS_ENABLED())'
checks instead, which don't have this problem, but for now, I'm
adding one more #ifdef to shut up the new warning.
Fixes: 8079e8f107bf ("bnxt_en: Refactor code that determines RFS capability.")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
drivers/net/ethernet/broadcom/bnxt/bnxt.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt.c b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
index 7bd2a85694dd..c0918507fdb4 100644
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt.c
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
@@ -4944,6 +4944,7 @@ static int bnxt_setup_int_mode(struct bnxt *bp)
return rc;
}
+#ifdef CONFIG_RFS_ACCEL
static unsigned int bnxt_get_max_func_rss_ctxs(struct bnxt *bp)
{
#if defined(CONFIG_BNXT_SRIOV)
@@ -4961,6 +4962,7 @@ static unsigned int bnxt_get_max_func_vnics(struct bnxt *bp)
#endif
return bp->pf.max_vnics;
}
+#endif
unsigned int bnxt_get_max_func_stat_ctxs(struct bnxt *bp)
{
--
2.9.0
^ permalink raw reply related
* [PATCH] wext: handle NULL exta data in iwe_stream_add_point better
From: Arnd Bergmann @ 2017-01-11 14:35 UTC (permalink / raw)
To: Johannes Berg
Cc: linux-wireless, Arnd Bergmann, David S. Miller, Johannes Berg,
netdev, linux-kernel
gcc-7 complains that wl3501_cs passes NULL into a function that
then uses the argument as the input for memcpy:
drivers/net/wireless/wl3501_cs.c: In function 'wl3501_get_scan':
include/net/iw_handler.h:559:3: error: argument 2 null where non-null expected [-Werror=nonnull]
memcpy(stream + point_len, extra, iwe->u.data.length);
This works fine here because iwe->u.data.length is guaranteed to be
NULL, and the memcpy doesn't actually have an effect.
Making the length check explicit avoids the warning and should have
no other effect here.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
include/net/iw_handler.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/include/net/iw_handler.h b/include/net/iw_handler.h
index e0f4109e64c6..1a41043688bc 100644
--- a/include/net/iw_handler.h
+++ b/include/net/iw_handler.h
@@ -556,7 +556,8 @@ iwe_stream_add_point(struct iw_request_info *info, char *stream, char *ends,
memcpy(stream + lcp_len,
((char *) &iwe->u) + IW_EV_POINT_OFF,
IW_EV_POINT_PK_LEN - IW_EV_LCP_PK_LEN);
- memcpy(stream + point_len, extra, iwe->u.data.length);
+ if (iwe->u.data.length)
+ memcpy(stream + point_len, extra, iwe->u.data.length);
stream += event_len;
}
return stream;
--
2.9.0
^ permalink raw reply related
* RE: [RFC PATCH net-next v4 1/2] macb: Add 1588 support in Cadence GEM.
From: Andrei.Pistirica @ 2017-01-11 14:34 UTC (permalink / raw)
To: richardcochran, rafalo, harinikatakamlinux, nicolas.ferre,
harini.katakam
Cc: tbultel, boris.brezillon, netdev, alexandre.belloni, linux-kernel,
michals, anirudh, punnaia, davem, linux-arm-kernel
In-Reply-To: <20170103111447.GA26488@localhost.localdomain>
> On Tue, Jan 03, 2017 at 10:47:56AM +0000, Rafal Ozieblo wrote:
> > We could use only descriptor approach but there are many Atmel's cores
> on the market which support only event registers.
>
> As I said in my other reply in this thread, the Atmel cores cannot possibly be
> made to work correctly.
>
> Sad, but true.
In conscience, I will make a patch containing only the common code (just to benefit from this effort) and then Rafal can add the driver for the GXL version on top of it.
Everybody agrees with this?
Best regards,
Andrei
>
> Thanks,
> Richard
^ permalink raw reply
* Re: [PATCH v2 0/2] remove dwc_eth_qos and rename stmicro/stmmac
From: Joao Pinto @ 2017-01-11 14:29 UTC (permalink / raw)
To: Alexandre Torgue, Joao Pinto, davem
Cc: lars.persson, niklass, peppe.cavallaro, netdev
In-Reply-To: <d814eabb-ec19-9df4-1f44-4405ece6995f@st.com>
Alex,
Às 2:25 PM de 1/11/2017, Alexandre Torgue escreveu:
> Jao,
>
> On 01/11/2017 12:54 PM, Joao Pinto wrote:
>>
>> Hi Alex,
>>
>> Às 11:39 AM de 1/11/2017, Alexandre Torgue escreveu:
>>> Hi Jao,
>>>
>>> On 01/10/2017 03:52 PM, Joao Pinto wrote:
>>>> This patch set removes the synopsys/dwc_eth_qos since it was merged recently
>>>> to stmmac (dwmac-dwc-qos-eth glue driver).
>>>>
>>>> It also renames stmicro/stmmac to synopsys/ since it is a standard ethernet
>>>> software package regarding synopsys ethernet controllers, supporting the
>>>> majority of Synopsys Ethernet IPs.
>>>
>>> I understand the reason to rename stmmac driver. The only risk I see is that
>>> usual user will be a little bit lost to find code. It seems there no risk of
>>> backward compatibility with current/old DT (I assume you already checked this
>>> point).
>>
>> I understand your concern, but for the Synopsys IPs users will be clearer what
>> drivers to use and what current stmmac has to offer.
>
> I agree.
>
>>
>> In terms of tests, I tested it and worked out of the box because the same
>> Kconfig IDs were used assuring the retro-compatibility that David suggested a
>> few weeks ago. For DT users no problems are expected as well.
>
> Ok, sounds good.
>
> I see that you rename also Documentation/devicetree/bindings/net/stmmac.txt. You
> have also to change some words inside as it talks about Stmicroelectronics.
You are right. Going to change that and send a v3. Counting on your ack :)
Thanks!
>
> Regards
> Alex
>
>>
>> Thanks,
>> Joao
>>
>>> Let's see what David think about that but if there no risk of backward
>>> compatibility with DT, I agree with the series.
>>>
>>> Regards
>>> Alex
>>>
>>>
>>>
>>>>
>>>> In the future we should make an effort to migrate to this new synopsys/
>>>> driver package all the Ethernet Synopsys IP drivers scattered in net/ethernet.
>>>>
>>>> Joao Pinto (2):
>>>> synopsys: remove dwc_eth_qos driver
>>>> stmmac: rename it to synopsys
>>>>
>>>> .../bindings/net/{stmmac.txt => synopsys.txt} | 0
>>>> MAINTAINERS | 11 +-
>>>> arch/arm/configs/multi_v7_defconfig | 3 +-
>>>> drivers/net/ethernet/Kconfig | 3 +-
^ permalink raw reply
* Re: [PATCH net-next v3] net: dsa: make "label" property optional for dsa2
From: David Miller @ 2017-01-11 14:27 UTC (permalink / raw)
To: vivien.didelot
Cc: netdev, linux-kernel, kernel, f.fainelli, andrew, jiri, uwe,
andrew.smirnov
In-Reply-To: <20170109231351.5023-1-vivien.didelot@savoirfairelinux.com>
From: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
Date: Mon, 9 Jan 2017 18:13:51 -0500
> In the new DTS bindings for DSA (dsa2), the "ethernet" and "link"
> phandles are respectively mandatory and exclusive to CPU port and DSA
> link device tree nodes.
>
> Simplify dsa2.c a bit by checking the presence of such phandle instead
> of checking the redundant "label" property.
>
> Then the Linux philosophy for Ethernet switch ports is to expose them to
> userspace as standard NICs by default. Thus use the standard enumerated
> "eth%d" device name if no "label" property is provided for a user port.
> This allows to save DTS files from subjective net device names.
>
> If one wants to rename an interface, udev rules can be used as usual.
>
> Of course the current behavior is unchanged, and the optional "label"
> property for user ports has precedence over the enumerated name.
>
> Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
> Acked-by: Uwe Kleine-König <uwe@kleine-koenig.org>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH v2 0/2] remove dwc_eth_qos and rename stmicro/stmmac
From: Alexandre Torgue @ 2017-01-11 14:25 UTC (permalink / raw)
To: Joao Pinto, davem; +Cc: lars.persson, niklass, peppe.cavallaro, netdev
In-Reply-To: <298670a0-7074-a590-9498-7a9db68d499e@synopsys.com>
Jao,
On 01/11/2017 12:54 PM, Joao Pinto wrote:
>
> Hi Alex,
>
> Às 11:39 AM de 1/11/2017, Alexandre Torgue escreveu:
>> Hi Jao,
>>
>> On 01/10/2017 03:52 PM, Joao Pinto wrote:
>>> This patch set removes the synopsys/dwc_eth_qos since it was merged recently
>>> to stmmac (dwmac-dwc-qos-eth glue driver).
>>>
>>> It also renames stmicro/stmmac to synopsys/ since it is a standard ethernet
>>> software package regarding synopsys ethernet controllers, supporting the
>>> majority of Synopsys Ethernet IPs.
>>
>> I understand the reason to rename stmmac driver. The only risk I see is that
>> usual user will be a little bit lost to find code. It seems there no risk of
>> backward compatibility with current/old DT (I assume you already checked this
>> point).
>
> I understand your concern, but for the Synopsys IPs users will be clearer what
> drivers to use and what current stmmac has to offer.
I agree.
>
> In terms of tests, I tested it and worked out of the box because the same
> Kconfig IDs were used assuring the retro-compatibility that David suggested a
> few weeks ago. For DT users no problems are expected as well.
Ok, sounds good.
I see that you rename also
Documentation/devicetree/bindings/net/stmmac.txt. You have also to
change some words inside as it talks about Stmicroelectronics.
Regards
Alex
>
> Thanks,
> Joao
>
>> Let's see what David think about that but if there no risk of backward
>> compatibility with DT, I agree with the series.
>>
>> Regards
>> Alex
>>
>>
>>
>>>
>>> In the future we should make an effort to migrate to this new synopsys/
>>> driver package all the Ethernet Synopsys IP drivers scattered in net/ethernet.
>>>
>>> Joao Pinto (2):
>>> synopsys: remove dwc_eth_qos driver
>>> stmmac: rename it to synopsys
>>>
>>> .../bindings/net/{stmmac.txt => synopsys.txt} | 0
>>> MAINTAINERS | 11 +-
>>> arch/arm/configs/multi_v7_defconfig | 3 +-
>>> drivers/net/ethernet/Kconfig | 3 +-
>>> drivers/net/ethernet/Makefile | 3 +-
>>> drivers/net/ethernet/stmicro/Kconfig | 21 -
>>> drivers/net/ethernet/stmicro/Makefile | 5 -
>>> drivers/net/ethernet/stmicro/stmmac/Kconfig | 162 --
>>> drivers/net/ethernet/stmicro/stmmac/Makefile | 25 -
>>> drivers/net/ethernet/synopsys/Kconfig | 165 +-
>>> drivers/net/ethernet/synopsys/Makefile | 28 +-
>>> .../{stmicro/stmmac => synopsys}/altr_tse_pcs.c | 0
>>> .../{stmicro/stmmac => synopsys}/altr_tse_pcs.h | 0
>>> .../{stmicro/stmmac => synopsys}/chain_mode.c | 0
>>> .../ethernet/{stmicro/stmmac => synopsys}/common.h | 0
>>> .../ethernet/{stmicro/stmmac => synopsys}/descs.h | 0
>>> .../{stmicro/stmmac => synopsys}/descs_com.h | 0
>>> drivers/net/ethernet/synopsys/dwc_eth_qos.c | 2996 --------------------
>>> .../stmmac => synopsys}/dwmac-dwc-qos-eth.c | 0
>>> .../{stmicro/stmmac => synopsys}/dwmac-generic.c | 0
>>> .../{stmicro/stmmac => synopsys}/dwmac-ipq806x.c | 0
>>> .../{stmicro/stmmac => synopsys}/dwmac-lpc18xx.c | 0
>>> .../{stmicro/stmmac => synopsys}/dwmac-meson.c | 0
>>> .../{stmicro/stmmac => synopsys}/dwmac-meson8b.c | 0
>>> .../{stmicro/stmmac => synopsys}/dwmac-oxnas.c | 0
>>> .../{stmicro/stmmac => synopsys}/dwmac-rk.c | 0
>>> .../{stmicro/stmmac => synopsys}/dwmac-socfpga.c | 0
>>> .../{stmicro/stmmac => synopsys}/dwmac-sti.c | 0
>>> .../{stmicro/stmmac => synopsys}/dwmac-stm32.c | 0
>>> .../{stmicro/stmmac => synopsys}/dwmac-sunxi.c | 0
>>> .../{stmicro/stmmac => synopsys}/dwmac100.h | 0
>>> .../{stmicro/stmmac => synopsys}/dwmac1000.h | 0
>>> .../{stmicro/stmmac => synopsys}/dwmac1000_core.c | 0
>>> .../{stmicro/stmmac => synopsys}/dwmac1000_dma.c | 0
>>> .../{stmicro/stmmac => synopsys}/dwmac100_core.c | 0
>>> .../{stmicro/stmmac => synopsys}/dwmac100_dma.c | 0
>>> .../ethernet/{stmicro/stmmac => synopsys}/dwmac4.h | 0
>>> .../{stmicro/stmmac => synopsys}/dwmac4_core.c | 0
>>> .../{stmicro/stmmac => synopsys}/dwmac4_descs.c | 0
>>> .../{stmicro/stmmac => synopsys}/dwmac4_descs.h | 0
>>> .../{stmicro/stmmac => synopsys}/dwmac4_dma.c | 0
>>> .../{stmicro/stmmac => synopsys}/dwmac4_dma.h | 0
>>> .../{stmicro/stmmac => synopsys}/dwmac4_lib.c | 0
>>> .../{stmicro/stmmac => synopsys}/dwmac_dma.h | 0
>>> .../{stmicro/stmmac => synopsys}/dwmac_lib.c | 0
>>> .../{stmicro/stmmac => synopsys}/enh_desc.c | 0
>>> .../ethernet/{stmicro/stmmac => synopsys}/mmc.h | 0
>>> .../{stmicro/stmmac => synopsys}/mmc_core.c | 0
>>> .../{stmicro/stmmac => synopsys}/norm_desc.c | 0
>>> .../{stmicro/stmmac => synopsys}/ring_mode.c | 0
>>> .../ethernet/{stmicro/stmmac => synopsys}/stmmac.h | 0
>>> .../{stmicro/stmmac => synopsys}/stmmac_ethtool.c | 0
>>> .../{stmicro/stmmac => synopsys}/stmmac_hwtstamp.c | 0
>>> .../{stmicro/stmmac => synopsys}/stmmac_main.c | 0
>>> .../{stmicro/stmmac => synopsys}/stmmac_mdio.c | 0
>>> .../{stmicro/stmmac => synopsys}/stmmac_pci.c | 0
>>> .../{stmicro/stmmac => synopsys}/stmmac_pcs.h | 0
>>> .../{stmicro/stmmac => synopsys}/stmmac_platform.c | 0
>>> .../{stmicro/stmmac => synopsys}/stmmac_platform.h | 0
>>> .../{stmicro/stmmac => synopsys}/stmmac_ptp.c | 0
>>> .../{stmicro/stmmac => synopsys}/stmmac_ptp.h | 0
>>> 61 files changed, 180 insertions(+), 3242 deletions(-)
>>> rename Documentation/devicetree/bindings/net/{stmmac.txt => synopsys.txt} (100%)
>>> delete mode 100644 drivers/net/ethernet/stmicro/Kconfig
>>> delete mode 100644 drivers/net/ethernet/stmicro/Makefile
>>> delete mode 100644 drivers/net/ethernet/stmicro/stmmac/Kconfig
>>> delete mode 100644 drivers/net/ethernet/stmicro/stmmac/Makefile
>>> rename drivers/net/ethernet/{stmicro/stmmac => synopsys}/altr_tse_pcs.c (100%)
>>> rename drivers/net/ethernet/{stmicro/stmmac => synopsys}/altr_tse_pcs.h (100%)
>>> rename drivers/net/ethernet/{stmicro/stmmac => synopsys}/chain_mode.c (100%)
>>> rename drivers/net/ethernet/{stmicro/stmmac => synopsys}/common.h (100%)
>>> rename drivers/net/ethernet/{stmicro/stmmac => synopsys}/descs.h (100%)
>>> rename drivers/net/ethernet/{stmicro/stmmac => synopsys}/descs_com.h (100%)
>>> delete mode 100644 drivers/net/ethernet/synopsys/dwc_eth_qos.c
>>> rename drivers/net/ethernet/{stmicro/stmmac => synopsys}/dwmac-dwc-qos-eth.c
>>> (100%)
>>> rename drivers/net/ethernet/{stmicro/stmmac => synopsys}/dwmac-generic.c (100%)
>>> rename drivers/net/ethernet/{stmicro/stmmac => synopsys}/dwmac-ipq806x.c (100%)
>>> rename drivers/net/ethernet/{stmicro/stmmac => synopsys}/dwmac-lpc18xx.c (100%)
>>> rename drivers/net/ethernet/{stmicro/stmmac => synopsys}/dwmac-meson.c (100%)
>>> rename drivers/net/ethernet/{stmicro/stmmac => synopsys}/dwmac-meson8b.c (100%)
>>> rename drivers/net/ethernet/{stmicro/stmmac => synopsys}/dwmac-oxnas.c (100%)
>>> rename drivers/net/ethernet/{stmicro/stmmac => synopsys}/dwmac-rk.c (100%)
>>> rename drivers/net/ethernet/{stmicro/stmmac => synopsys}/dwmac-socfpga.c (100%)
>>> rename drivers/net/ethernet/{stmicro/stmmac => synopsys}/dwmac-sti.c (100%)
>>> rename drivers/net/ethernet/{stmicro/stmmac => synopsys}/dwmac-stm32.c (100%)
>>> rename drivers/net/ethernet/{stmicro/stmmac => synopsys}/dwmac-sunxi.c (100%)
>>> rename drivers/net/ethernet/{stmicro/stmmac => synopsys}/dwmac100.h (100%)
>>> rename drivers/net/ethernet/{stmicro/stmmac => synopsys}/dwmac1000.h (100%)
>>> rename drivers/net/ethernet/{stmicro/stmmac => synopsys}/dwmac1000_core.c (100%)
>>> rename drivers/net/ethernet/{stmicro/stmmac => synopsys}/dwmac1000_dma.c (100%)
>>> rename drivers/net/ethernet/{stmicro/stmmac => synopsys}/dwmac100_core.c (100%)
>>> rename drivers/net/ethernet/{stmicro/stmmac => synopsys}/dwmac100_dma.c (100%)
>>> rename drivers/net/ethernet/{stmicro/stmmac => synopsys}/dwmac4.h (100%)
>>> rename drivers/net/ethernet/{stmicro/stmmac => synopsys}/dwmac4_core.c (100%)
>>> rename drivers/net/ethernet/{stmicro/stmmac => synopsys}/dwmac4_descs.c (100%)
>>> rename drivers/net/ethernet/{stmicro/stmmac => synopsys}/dwmac4_descs.h (100%)
>>> rename drivers/net/ethernet/{stmicro/stmmac => synopsys}/dwmac4_dma.c (100%)
>>> rename drivers/net/ethernet/{stmicro/stmmac => synopsys}/dwmac4_dma.h (100%)
>>> rename drivers/net/ethernet/{stmicro/stmmac => synopsys}/dwmac4_lib.c (100%)
>>> rename drivers/net/ethernet/{stmicro/stmmac => synopsys}/dwmac_dma.h (100%)
>>> rename drivers/net/ethernet/{stmicro/stmmac => synopsys}/dwmac_lib.c (100%)
>>> rename drivers/net/ethernet/{stmicro/stmmac => synopsys}/enh_desc.c (100%)
>>> rename drivers/net/ethernet/{stmicro/stmmac => synopsys}/mmc.h (100%)
>>> rename drivers/net/ethernet/{stmicro/stmmac => synopsys}/mmc_core.c (100%)
>>> rename drivers/net/ethernet/{stmicro/stmmac => synopsys}/norm_desc.c (100%)
>>> rename drivers/net/ethernet/{stmicro/stmmac => synopsys}/ring_mode.c (100%)
>>> rename drivers/net/ethernet/{stmicro/stmmac => synopsys}/stmmac.h (100%)
>>> rename drivers/net/ethernet/{stmicro/stmmac => synopsys}/stmmac_ethtool.c (100%)
>>> rename drivers/net/ethernet/{stmicro/stmmac => synopsys}/stmmac_hwtstamp.c
>>> (100%)
>>> rename drivers/net/ethernet/{stmicro/stmmac => synopsys}/stmmac_main.c (100%)
>>> rename drivers/net/ethernet/{stmicro/stmmac => synopsys}/stmmac_mdio.c (100%)
>>> rename drivers/net/ethernet/{stmicro/stmmac => synopsys}/stmmac_pci.c (100%)
>>> rename drivers/net/ethernet/{stmicro/stmmac => synopsys}/stmmac_pcs.h (100%)
>>> rename drivers/net/ethernet/{stmicro/stmmac => synopsys}/stmmac_platform.c
>>> (100%)
>>> rename drivers/net/ethernet/{stmicro/stmmac => synopsys}/stmmac_platform.h
>>> (100%)
>>> rename drivers/net/ethernet/{stmicro/stmmac => synopsys}/stmmac_ptp.c (100%)
>>> rename drivers/net/ethernet/{stmicro/stmmac => synopsys}/stmmac_ptp.h (100%)
>>>
>
^ permalink raw reply
* Re: [PATCH net-next] net: ipv6: put autoconf routes into per-interface tables
From: David Miller @ 2017-01-11 14:11 UTC (permalink / raw)
To: lorenzo; +Cc: temnota.am, netdev
In-Reply-To: <CAKD1Yr3nfOp1LNfvVuTGZyThwu8Z+gaSN-DVaa11ZJYR+tMemg@mail.gmail.com>
From: Lorenzo Colitti <lorenzo@google.com>
Date: Wed, 11 Jan 2017 02:47:55 +0900
> On Tue, Jan 10, 2017 at 10:21 PM, Andrey Jr. Melnikov
> <temnota.am@gmail.com> wrote:
>>
>> > >>> I have no firsthand experience of this myself, but if the problems
>> > >>> that Andrey reports above in this thread are real, then those would
>> > >>> indicate that the code is not well-supported. Being unable to accept
>> > >>> DAD is a pretty serious issue. Andrey, what version of the kernel did
>> > >>> you see this on?
>>
>> Good catch. I'm running 4.8 without this patch. Current 4.10-rc works. Sorry
>> for noise.
>
> Ack. As I said before, I haven't seen this myself. Shouldn't have made
> assertions without firsthand evidence.
>
> That said, I think this patch is useful even though autoconf on VRFs
> works the same way. One reason is the example I provided above: it
> works even for interfaces that don't exist yet, whereas a VRF has to
> be created ahead of time, which means that the interface cannot
> immediately come up and receive an RA or its configuration will be
> incorrect.
>
> I also think that from a configuration perspective it's not
> necessarily useful to have one VRF for every interface, but that sort
> of depends on your point of view. Perhaps it's fine on a client system
> to have both vrf-wlan0 and wlan0, and vrf-eth0 and eth0. That might be
> confusing to users but maybe users don't really care?
>
> More in general I think that using a VRFs is buying into a bigger set
> of assumptions/restrictions than this patch does. For example, if I'm
> reading ipv6_dev_get_saddr correctly, once you put an interface in a
> VRF you can't really use the weak host model any more, because the
> stack won't pick a source address from outside the VRF if the route
> lookup returned a route in the VRF. Turning on the functionality in
> patch is a more minimal change that only affects autoconf.
I understand what you're saying, but if you look at how apps can be
put into hierarchical control groups, and automatically bind to VRF's
based upon where they are in that cgroup hierarchy, it matches your
use case precisely.
Maybe the setup is not ideal, but architectually it does everything
you want. And we strongly try to avoid adding multiple ways to do the
same thing.
^ permalink raw reply
* Re: [PATCH net-next 13/13] s390/qeth: remove OSN-devices
From: David Miller @ 2017-01-11 14:05 UTC (permalink / raw)
To: ubraun; +Cc: netdev, linux-s390, schwidefsky, heiko.carstens, stable
In-Reply-To: <20170111115600.4524-14-ubraun@linux.vnet.ibm.com>
From: Ursula Braun <ubraun@linux.vnet.ibm.com>
Date: Wed, 11 Jan 2017 12:56:00 +0100
> CHPID type "OSN" is a device type which had been used by IBM product
> "Communication Controller for Linux". This product has reached end of
> service in March 2016. Thus OSN support can be removed from the qeth
> driver.
>
> Signed-off-by: Ursula Braun <ubraun@linux.vnet.ibm.com>
> Reviewed-by: Julian Wiedmann <jwi@linux.vnet.ibm.com>
> Reviewed-by: Thomas Richter <tmricht@linux.vnet.ibm.com>
IBM can certainly decide what physical products it wants to support
or not, but this doesn't directly apply to what the Linux kernel
driver supports.
We do not unilaterally remove support for a chip from a driver just
because the vendor decides to stop supporting that chip. In fact this
is one of the main benefits and value-adds of Linux.
I'm not applying a patch series that removes support for a chipset
for this reason, sorry.
^ permalink raw reply
* Reply urgent Please
From: Mrs Sandra Udo @ 2017-01-11 13:26 UTC (permalink / raw)
Dearest Beloved in the Lord.
I pray that God will protect you and your family. My name is Engineer.
Mrs Sandra Udo; I am an Esophageal Cancer patient, and presently
hospitalized. My doctor says I have a few months to live. I have been
touched by God to donate from what I have inherited from my late
husband to you for good work of God.
I will be going in for an operation soon. I decided to WILL/donate the
sum of $5,500,000.00 to you for the good work of God, to set up a
foundation for the Orphanage.
I will provide you more details information after knowing your
willingness to handle this fund with fear of God.
E-mail: ( mrssandrau@gmail.com )
Thanks and God bless.
Yours Sincerely,
Engineer. Mrs Sandra Udo.
^ permalink raw reply
* Re: [net-next PATCH v6 0/3] net: dummy: Introduce dummy virtual functions
From: Phil Sutter @ 2017-01-11 13:38 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20170106.203804.2023763441703979123.davem@davemloft.net>
Hi David,
On Fri, Jan 06, 2017 at 08:38:04PM -0500, David Miller wrote:
> From: Phil Sutter <phil@nwl.cc>
> Date: Thu, 5 Jan 2017 20:09:10 +0100
>
> > This series adds VF support to dummy device driver after adding the
> > necessary infrastructure changes:
> >
> > Patch 1 adds a netdevice callback for device-specific VF count
> > retrieval. Patch 2 then changes dev_num_vf() implementation to make use
> > of that new callback (if implemented), falling back to the old
> > behaviour. Patch 3 then implements VF support in dummy, without the fake
> > PCI parent device hack from v5.
>
> Please don't make this a netdev specific method and interface.
>
> Put the method in "struct bus_device", thereby making it a generic
> "device" layer thing.
>
> So the pci BUS type will implement pci_bus_type.num_vf(). And you'll
> make a bus type for the dummy device to attach to which will implement
> it's own.
Following your approach, I'm running into a weird issue with conflicting
sysfs symlink names after calling register_netdevice for the dummy
device which has dev->dev.bus set to the dummy bus type I introduced:
In netdev_register_kobject, dev->class is set to &net_class. This means
that later in device_add, the call to device_add_class_symlinks will
create symlink to the class named devices/virtual/net/dummy0/subsystem.
The following call to bus_add_device by device_add though tries to
create a symlink to the bus with identical name.
This seems like a bug in device_add, but things apparently work for
other devices and I don't get what's different for them. Can you maybe
give me a hint what to look for or do you have an idea what I am
missing?
Thanks, Phil
^ permalink raw reply
* Re: [PATCH net-next 2/2] net/sched: cls_flower: Support matching on ARP
From: Jiri Pirko @ 2017-01-11 13:27 UTC (permalink / raw)
To: Simon Horman
Cc: David Miller, Jiri Pirko, Dinan Gunawardena, netdev, oss-drivers
In-Reply-To: <1484139943-18199-3-git-send-email-simon.horman@netronome.com>
Wed, Jan 11, 2017 at 02:05:43PM CET, simon.horman@netronome.com wrote:
>Support matching on ARP operation, and hardware and protocol addresses
>for Ethernet hardware and IPv4 protocol addresses.
>
>Example usage:
>
>tc qdisc add dev eth0 ingress
>
>tc filter add dev eth0 protocol arp parent ffff: flower indev eth0 \
> arp_op request arp_sip 10.0.0.1 action drop
>tc filter add dev eth0 protocol rarp parent ffff: flower indev eth0 \
> arp_op reply arp_tha 52:54:3f:00:00:00/24 action drop
>
>Signed-off-by: Simon Horman <simon.horman@netronome.com>
Acked-by: Jiri Pirko <jiri@mellanox.com>
^ permalink raw reply
* Re: [PATCH net-next 1/2] flow disector: ARP support
From: Jiri Pirko @ 2017-01-11 13:26 UTC (permalink / raw)
To: Simon Horman
Cc: David Miller, Jiri Pirko, Dinan Gunawardena, netdev, oss-drivers
In-Reply-To: <1484139943-18199-2-git-send-email-simon.horman@netronome.com>
Wed, Jan 11, 2017 at 02:05:42PM CET, simon.horman@netronome.com wrote:
>Allow dissection of (R)ARP operation hardware and protocol addresses
>for Ethernet hardware and IPv4 protocol addresses.
>
>There are currently no users of FLOW_DISSECTOR_KEY_ARP.
>A follow-up patch will allow FLOW_DISSECTOR_KEY_ARP to be used by the
>flower classifier.
>
>Signed-off-by: Simon Horman <simon.horman@netronome.com>
Acked-by: Jiri Pirko <jiri@mellanox.com>
^ permalink raw reply
* Re: [PATCH net] gro: use min_t() in skb_gro_reset_offset()
From: David Miller @ 2017-01-11 13:16 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, herbert, slavash, willemb, edumazet
In-Reply-To: <1484106763.21472.49.camel@edumazet-glaptop3.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Tue, 10 Jan 2017 19:52:43 -0800
> From: Eric Dumazet <edumazet@google.com>
>
> On 32bit arches, (skb->end - skb->data) is not 'unsigned int',
> so we shall use min_t() instead of min() to avoid a compiler error.
>
> Fixes: 1272ce87fa01 ("gro: Enter slow-path if there is no tailroom")
> Reported-by: kernel test robot <fengguang.wu@intel.com>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Applied, thanks Eric.
^ permalink raw reply
* [PATCH iproute2/net-next] tc: ife: correct spelling of prio in example
From: Simon Horman @ 2017-01-11 13:10 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Dinan Gunawardena, netdev, Simon Horman, Lucas Bates
Correct typo in example in ife man page.
Fixes: 06f9a59170c0 ("man: tc-ife.8: man page for ife action")
Cc: Lucas Bates <lucasb@mojatatu.com>
Signed-off-by: Simon Horman <simon.horman@netronome.com>
---
man/man8/tc-ife.8 | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/man/man8/tc-ife.8 b/man/man8/tc-ife.8
index aaf0f97d5c8d..dae8b9be9bcb 100644
--- a/man/man8/tc-ife.8
+++ b/man/man8/tc-ife.8
@@ -99,7 +99,7 @@ classification so that it will match ICMP on the next rule, at prio 3:
# tc filter add dev eth0 parent ffff: prio 2 protocol 0xdead \\
u32 match u32 0 0 flowid 1:1 \\
action ife decode reclassify
-# tc filter add dev eth0 parent ffff: priod 3 protocol ip \\
+# tc filter add dev eth0 parent ffff: prio 3 protocol ip \\
u32 match ip protocol 0xff flowid 1:1 \\
action continue
.EE
--
2.7.0.rc3.207.g0ac5344
^ permalink raw reply related
* Re: [PATCH/RFC net-next 0/2] net/sched: cls_flower: Support matching ARP
From: Simon Horman @ 2017-01-11 13:07 UTC (permalink / raw)
To: Jiri Pirko; +Cc: Jiri Pirko, Dinan Gunawardena, netdev, oss-drivers
In-Reply-To: <20170111102707.GG1852@nanopsycho>
On Wed, Jan 11, 2017 at 11:27:07AM +0100, Jiri Pirko wrote:
> Wed, Jan 11, 2017 at 11:02:20AM CET, simon.horman@netronome.com wrote:
> >Add support for support matching on ARP operation, and hardware and
> >protocol addresses for Ethernet hardware and IPv4 protocol addresses.
>
> This patchset looks fine to me. Please feel free to submit it.
Thanks, done.
^ permalink raw reply
* [PATCH net-next 2/2] net/sched: cls_flower: Support matching on ARP
From: Simon Horman @ 2017-01-11 13:05 UTC (permalink / raw)
To: David Miller, Jiri Pirko
Cc: Dinan Gunawardena, netdev, oss-drivers, Simon Horman
In-Reply-To: <1484139943-18199-1-git-send-email-simon.horman@netronome.com>
Support matching on ARP operation, and hardware and protocol addresses
for Ethernet hardware and IPv4 protocol addresses.
Example usage:
tc qdisc add dev eth0 ingress
tc filter add dev eth0 protocol arp parent ffff: flower indev eth0 \
arp_op request arp_sip 10.0.0.1 action drop
tc filter add dev eth0 protocol rarp parent ffff: flower indev eth0 \
arp_op reply arp_tha 52:54:3f:00:00:00/24 action drop
Signed-off-by: Simon Horman <simon.horman@netronome.com>
---
include/uapi/linux/pkt_cls.h | 11 ++++++++++
net/sched/cls_flower.c | 51 ++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 62 insertions(+)
diff --git a/include/uapi/linux/pkt_cls.h b/include/uapi/linux/pkt_cls.h
index a081efbd61a2..1e5e1ddfdaca 100644
--- a/include/uapi/linux/pkt_cls.h
+++ b/include/uapi/linux/pkt_cls.h
@@ -416,6 +416,17 @@ enum {
TCA_FLOWER_KEY_ICMPV6_TYPE, /* u8 */
TCA_FLOWER_KEY_ICMPV6_TYPE_MASK,/* u8 */
+ TCA_FLOWER_KEY_ARP_SIP, /* be32 */
+ TCA_FLOWER_KEY_ARP_SIP_MASK, /* be32 */
+ TCA_FLOWER_KEY_ARP_TIP, /* be32 */
+ TCA_FLOWER_KEY_ARP_TIP_MASK, /* be32 */
+ TCA_FLOWER_KEY_ARP_OP, /* u8 */
+ TCA_FLOWER_KEY_ARP_OP_MASK, /* u8 */
+ TCA_FLOWER_KEY_ARP_SHA, /* ETH_ALEN */
+ TCA_FLOWER_KEY_ARP_SHA_MASK, /* ETH_ALEN */
+ TCA_FLOWER_KEY_ARP_THA, /* ETH_ALEN */
+ TCA_FLOWER_KEY_ARP_THA_MASK, /* ETH_ALEN */
+
__TCA_FLOWER_MAX,
};
diff --git a/net/sched/cls_flower.c b/net/sched/cls_flower.c
index 970db7a41684..a3bfda3091a4 100644
--- a/net/sched/cls_flower.c
+++ b/net/sched/cls_flower.c
@@ -40,6 +40,7 @@ struct fl_flow_key {
};
struct flow_dissector_key_ports tp;
struct flow_dissector_key_icmp icmp;
+ struct flow_dissector_key_arp arp;
struct flow_dissector_key_keyid enc_key_id;
union {
struct flow_dissector_key_ipv4_addrs enc_ipv4;
@@ -401,6 +402,16 @@ static const struct nla_policy fl_policy[TCA_FLOWER_MAX + 1] = {
[TCA_FLOWER_KEY_ICMPV6_TYPE_MASK] = { .type = NLA_U8 },
[TCA_FLOWER_KEY_ICMPV6_CODE] = { .type = NLA_U8 },
[TCA_FLOWER_KEY_ICMPV6_CODE_MASK] = { .type = NLA_U8 },
+ [TCA_FLOWER_KEY_ARP_SIP] = { .type = NLA_U32 },
+ [TCA_FLOWER_KEY_ARP_SIP_MASK] = { .type = NLA_U32 },
+ [TCA_FLOWER_KEY_ARP_TIP] = { .type = NLA_U32 },
+ [TCA_FLOWER_KEY_ARP_TIP_MASK] = { .type = NLA_U32 },
+ [TCA_FLOWER_KEY_ARP_OP] = { .type = NLA_U8 },
+ [TCA_FLOWER_KEY_ARP_OP_MASK] = { .type = NLA_U8 },
+ [TCA_FLOWER_KEY_ARP_SHA] = { .len = ETH_ALEN },
+ [TCA_FLOWER_KEY_ARP_SHA_MASK] = { .len = ETH_ALEN },
+ [TCA_FLOWER_KEY_ARP_THA] = { .len = ETH_ALEN },
+ [TCA_FLOWER_KEY_ARP_THA_MASK] = { .len = ETH_ALEN },
};
static void fl_set_key_val(struct nlattr **tb,
@@ -572,6 +583,23 @@ static int fl_set_key(struct net *net, struct nlattr **tb,
&mask->icmp.code,
TCA_FLOWER_KEY_ICMPV4_CODE_MASK,
sizeof(key->icmp.code));
+ } else if (key->basic.n_proto == htons(ETH_P_ARP) ||
+ key->basic.n_proto == htons(ETH_P_RARP)) {
+ fl_set_key_val(tb, &key->arp.sip, TCA_FLOWER_KEY_ARP_SIP,
+ &mask->arp.sip, TCA_FLOWER_KEY_ARP_SIP_MASK,
+ sizeof(key->arp.sip));
+ fl_set_key_val(tb, &key->arp.tip, TCA_FLOWER_KEY_ARP_TIP,
+ &mask->arp.tip, TCA_FLOWER_KEY_ARP_TIP_MASK,
+ sizeof(key->arp.tip));
+ fl_set_key_val(tb, &key->arp.op, TCA_FLOWER_KEY_ARP_OP,
+ &mask->arp.op, TCA_FLOWER_KEY_ARP_OP_MASK,
+ sizeof(key->arp.op));
+ fl_set_key_val(tb, key->arp.sha, TCA_FLOWER_KEY_ARP_SHA,
+ mask->arp.sha, TCA_FLOWER_KEY_ARP_SHA_MASK,
+ sizeof(key->arp.sha));
+ fl_set_key_val(tb, key->arp.tha, TCA_FLOWER_KEY_ARP_THA,
+ mask->arp.tha, TCA_FLOWER_KEY_ARP_THA_MASK,
+ sizeof(key->arp.tha));
}
if (tb[TCA_FLOWER_KEY_ENC_IPV4_SRC] ||
@@ -689,6 +717,8 @@ static void fl_init_dissector(struct cls_fl_head *head,
FL_KEY_SET_IF_MASKED(&mask->key, keys, cnt,
FLOW_DISSECTOR_KEY_ICMP, icmp);
FL_KEY_SET_IF_MASKED(&mask->key, keys, cnt,
+ FLOW_DISSECTOR_KEY_ARP, arp);
+ FL_KEY_SET_IF_MASKED(&mask->key, keys, cnt,
FLOW_DISSECTOR_KEY_VLAN, vlan);
FL_KEY_SET_IF_MASKED(&mask->key, keys, cnt,
FLOW_DISSECTOR_KEY_ENC_KEYID, enc_key_id);
@@ -1112,6 +1142,27 @@ static int fl_dump(struct net *net, struct tcf_proto *tp, unsigned long fh,
TCA_FLOWER_KEY_ICMPV6_CODE_MASK,
sizeof(key->icmp.code))))
goto nla_put_failure;
+ else if ((key->basic.n_proto == htons(ETH_P_ARP) ||
+ key->basic.n_proto == htons(ETH_P_RARP)) &&
+ (fl_dump_key_val(skb, &key->arp.sip,
+ TCA_FLOWER_KEY_ARP_SIP, &mask->arp.sip,
+ TCA_FLOWER_KEY_ARP_SIP_MASK,
+ sizeof(key->arp.sip)) ||
+ fl_dump_key_val(skb, &key->arp.tip,
+ TCA_FLOWER_KEY_ARP_TIP, &mask->arp.tip,
+ TCA_FLOWER_KEY_ARP_TIP_MASK,
+ sizeof(key->arp.tip)) ||
+ fl_dump_key_val(skb, &key->arp.op,
+ TCA_FLOWER_KEY_ARP_OP, &mask->arp.op,
+ TCA_FLOWER_KEY_ARP_OP_MASK,
+ sizeof(key->arp.op)) ||
+ fl_dump_key_val(skb, key->arp.sha, TCA_FLOWER_KEY_ARP_SHA,
+ mask->arp.sha, TCA_FLOWER_KEY_ARP_SHA_MASK,
+ sizeof(key->arp.sha)) ||
+ fl_dump_key_val(skb, key->arp.tha, TCA_FLOWER_KEY_ARP_THA,
+ mask->arp.tha, TCA_FLOWER_KEY_ARP_THA_MASK,
+ sizeof(key->arp.tha))))
+ goto nla_put_failure;
if (key->enc_control.addr_type == FLOW_DISSECTOR_KEY_IPV4_ADDRS &&
(fl_dump_key_val(skb, &key->enc_ipv4.src,
--
2.7.0.rc3.207.g0ac5344
^ permalink raw reply related
* [PATCH net-next 1/2] flow disector: ARP support
From: Simon Horman @ 2017-01-11 13:05 UTC (permalink / raw)
To: David Miller, Jiri Pirko
Cc: Dinan Gunawardena, netdev, oss-drivers, Simon Horman
In-Reply-To: <1484139943-18199-1-git-send-email-simon.horman@netronome.com>
Allow dissection of (R)ARP operation hardware and protocol addresses
for Ethernet hardware and IPv4 protocol addresses.
There are currently no users of FLOW_DISSECTOR_KEY_ARP.
A follow-up patch will allow FLOW_DISSECTOR_KEY_ARP to be used by the
flower classifier.
Signed-off-by: Simon Horman <simon.horman@netronome.com>
---
include/net/flow_dissector.h | 19 +++++++++++++++
net/core/flow_dissector.c | 57 ++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 76 insertions(+)
diff --git a/include/net/flow_dissector.h b/include/net/flow_dissector.h
index d896a33e00d4..ac9703018a3a 100644
--- a/include/net/flow_dissector.h
+++ b/include/net/flow_dissector.h
@@ -89,6 +89,24 @@ struct flow_dissector_key_addrs {
};
/**
+ * flow_dissector_key_arp:
+ * @ports: Operation, source and target addresses for an ARP header
+ * for Ethernet hardware addresses and IPv4 protocol addresses
+ * sip: Sender IP address
+ * tip: Target IP address
+ * op: Operation
+ * sha: Sender hardware address
+ * tpa: Target hardware address
+ */
+struct flow_dissector_key_arp {
+ __u32 sip;
+ __u32 tip;
+ __u8 op;
+ unsigned char sha[ETH_ALEN];
+ unsigned char tha[ETH_ALEN];
+};
+
+/**
* flow_dissector_key_tp_ports:
* @ports: port numbers of Transport header
* src: source port number
@@ -141,6 +159,7 @@ enum flow_dissector_key_id {
FLOW_DISSECTOR_KEY_ICMP, /* struct flow_dissector_key_icmp */
FLOW_DISSECTOR_KEY_ETH_ADDRS, /* struct flow_dissector_key_eth_addrs */
FLOW_DISSECTOR_KEY_TIPC_ADDRS, /* struct flow_dissector_key_tipc_addrs */
+ FLOW_DISSECTOR_KEY_ARP, /* struct flow_dissector_key_arp */
FLOW_DISSECTOR_KEY_VLAN, /* struct flow_dissector_key_flow_vlan */
FLOW_DISSECTOR_KEY_FLOW_LABEL, /* struct flow_dissector_key_flow_tags */
FLOW_DISSECTOR_KEY_GRE_KEYID, /* struct flow_dissector_key_keyid */
diff --git a/net/core/flow_dissector.c b/net/core/flow_dissector.c
index fe4e1531976c..5b3800fe20f3 100644
--- a/net/core/flow_dissector.c
+++ b/net/core/flow_dissector.c
@@ -138,6 +138,7 @@ bool __skb_flow_dissect(const struct sk_buff *skb,
struct flow_dissector_key_control *key_control;
struct flow_dissector_key_basic *key_basic;
struct flow_dissector_key_addrs *key_addrs;
+ struct flow_dissector_key_arp *key_arp;
struct flow_dissector_key_ports *key_ports;
struct flow_dissector_key_icmp *key_icmp;
struct flow_dissector_key_tags *key_tags;
@@ -379,6 +380,62 @@ bool __skb_flow_dissect(const struct sk_buff *skb,
nhoff += FCOE_HEADER_LEN;
goto out_good;
+
+ case htons(ETH_P_ARP):
+ case htons(ETH_P_RARP): {
+ struct {
+ unsigned char ar_sha[ETH_ALEN];
+ unsigned char ar_sip[4];
+ unsigned char ar_tha[ETH_ALEN];
+ unsigned char ar_tip[4];
+ } *arp_eth, _arp_eth;
+ const struct arphdr *arp;
+ struct arphdr *_arp;
+
+ arp = __skb_header_pointer(skb, nhoff, sizeof(_arp), data,
+ hlen, &_arp);
+ if (!arp)
+ goto out_bad;
+
+ if (arp->ar_hrd != htons(ARPHRD_ETHER) ||
+ arp->ar_pro != htons(ETH_P_IP) ||
+ arp->ar_hln != ETH_ALEN ||
+ arp->ar_pln != 4 ||
+ (arp->ar_op != htons(ARPOP_REPLY) &&
+ arp->ar_op != htons(ARPOP_REQUEST)))
+ goto out_bad;
+
+ arp_eth = __skb_header_pointer(skb, nhoff + sizeof(_arp),
+ sizeof(_arp_eth), data,
+ hlen - sizeof(_arp),
+ &_arp_eth);
+ if (!arp)
+ goto out_bad;
+
+ if (dissector_uses_key(flow_dissector,
+ FLOW_DISSECTOR_KEY_ARP)) {
+
+ key_arp = skb_flow_dissector_target(flow_dissector,
+ FLOW_DISSECTOR_KEY_ARP,
+ target_container);
+
+ memcpy(&key_arp->sip, arp_eth->ar_sip,
+ sizeof(key_arp->sip));
+ memcpy(&key_arp->tip, arp_eth->ar_tip,
+ sizeof(key_arp->tip));
+
+ /* Only store the lower byte of the opcode;
+ * this covers ARPOP_REPLY and ARPOP_REQUEST.
+ */
+ key_arp->op = ntohs(arp->ar_op) & 0xff;
+
+ ether_addr_copy(key_arp->sha, arp_eth->ar_sha);
+ ether_addr_copy(key_arp->tha, arp_eth->ar_tha);
+ }
+
+ goto out_good;
+ }
+
default:
goto out_bad;
}
--
2.7.0.rc3.207.g0ac5344
^ permalink raw reply related
* [PATCH net-next 0/2] net/sched: cls_flower: Support matching ARP
From: Simon Horman @ 2017-01-11 13:05 UTC (permalink / raw)
To: David Miller, Jiri Pirko
Cc: Dinan Gunawardena, netdev, oss-drivers, Simon Horman
Add support for support matching on ARP operation, and hardware and
protocol addresses for Ethernet hardware and IPv4 protocol addresses.
Changes since RFC:
* None other than dropping RFC designation after positive feedback from Jiri
Simon Horman (2):
flow disector: ARP support
net/sched: cls_flower: Support matching on ARP
include/net/flow_dissector.h | 19 +++++++++++++++
include/uapi/linux/pkt_cls.h | 11 +++++++++
net/core/flow_dissector.c | 57 ++++++++++++++++++++++++++++++++++++++++++++
net/sched/cls_flower.c | 51 +++++++++++++++++++++++++++++++++++++++
4 files changed, 138 insertions(+)
--
2.7.0.rc3.207.g0ac5344
^ permalink raw reply
* Re: [PATCH v2 0/7] uapi: export all headers under uapi directories
From: Jesper Nilsson @ 2017-01-11 12:42 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linuxppc-dev, linux-kbuild, Nicolas Dichtel, linux-mips,
alsa-devel, linux-ia64, linux-doc, airlied, linux-fbdev,
dri-devel, linux-mtd, sparclinux, linux-arch, linux-s390,
linux-am33-list, linux-c6x-dev, linux-rdma, linux-hexagon,
linux-sh, coreteam, fcoe-devel, xen-devel, linux-snps-arc,
linux-media, uclinux-h8-devel, adi-buildroot-devel, l
In-Reply-To: <3131144.4Ej3KFWRbz@wuerfel>
On Mon, Jan 09, 2017 at 12:33:58PM +0100, Arnd Bergmann wrote:
> On Friday, January 6, 2017 10:43:52 AM CET Nicolas Dichtel wrote:
> > Here is the v2 of this series. The first 5 patches are just cleanup: some
> > exported headers were still under a non-uapi directory.
>
> Since this is meant as a cleanup, I commented on this to point out a cleaner
> way to do the same.
>
> > The patch 6 was spotted by code review: there is no in-tree user of this
> > functionality.
> > The last patch remove the use of header-y. Now all files under an uapi
> > directory are exported.
>
> Very nice!
>
> > asm is a bit special, most of architectures export asm/<arch>/include/uapi/asm
> > only, but there is two exceptions:
> > - cris which exports arch/cris/include/uapi/arch-v[10|32];
>
> This is interesting, though not your problem. Maybe someone who understands
> cris better can comment on this: How is the decision made about which of
> the arch/user.h headers gets used? I couldn't find that in the sources,
> but it appears to be based on kernel compile-time settings, which is
> wrong for user space header files that should be independent of the kernel
> config.
I believe it's since the CRISv10 and CRISv32 are very different beasts,
and that is selected via kernel config...
This part of the CRIS port has been transformed a couple of times from
the original layout without uapi, and there's still some legacy silliness,
where some files might have been exported but never used from userspace
except for some corner cases.
> > - tile which exports arch/tile/include/uapi/arch.
> > Because I don't know if the output of 'make headers_install_all' can be changed,
> > I introduce subdir-y in Kbuild file. The headers_install_all target copies all
> > asm/<arch>/include/uapi/asm to usr/include/asm-<arch> but
> > arch/cris/include/uapi/arch-v[10|32] and arch/tile/include/uapi/arch are not
> > prefixed (they are put asis in usr/include/). If it's acceptable to modify the
> > output of 'make headers_install_all' to export asm headers in
> > usr/include/asm-<arch>/asm, then I could remove this new subdir-y and exports
> > everything under arch/<arch>/include/uapi/.
>
> I don't know if anyone still uses "make headers_install_all", I suspect
> distros these days all use "make headers_install", so it probably
> doesn't matter much.
>
> In case of cris, it should be easy enough to move all the contents of the
> uapi/arch-*/*.h headers into the respective uapi/asm/*.h headers, they
> only seem to be referenced from there.
This would seem to be a reasonable change.
> For tile, I suspect that would not work as the arch/*.h headers are
> apparently defined as interfaces for both user space and kernel.
>
> > Note also that exported files for asm are a mix of files listed by:
> > - include/uapi/asm-generic/Kbuild.asm;
> > - arch/x86/include/uapi/asm/Kbuild;
> > - arch/x86/include/asm/Kbuild.
> > This complicates a lot the processing (arch/x86/include/asm/Kbuild is also
> > used by scripts/Makefile.asm-generic).
> >
> > This series has been tested with a 'make headers_install' on x86 and a
> > 'make headers_install_all'. I've checked the result of both commands.
> >
> > This patch is built against linus tree. I don't know if it should be
> > made against antoher tree.
>
> The series should probably get merged through the kbuild tree, but testing
> it on mainline is fine here.
>
> Arnd
/^JN - Jesper Nilsson
--
Jesper Nilsson -- jesper.nilsson@axis.com
^ permalink raw reply
* Re: [PATCH net-next] bridge: multicast to unicast
From: Felix Fietkau @ 2017-01-11 12:21 UTC (permalink / raw)
To: IgorMitsyanko, Johannes Berg, Linus Lüssing,
Stephen Hemminger
Cc: netdev, bridge, linux-wireless, linux-kernel, David S . Miller,
M. Braun
In-Reply-To: <ee946686-699c-da64-4932-f58e3f1a83ad@quantenna.com>
On 2017-01-11 13:15, IgorMitsyanko wrote:
> On 01/11/2017 02:30 PM, Felix Fietkau wrote:
>> On 2017-01-11 12:26, IgorMitsyanko wrote:
>>> On 01/11/2017 12:27 AM, Felix Fietkau wrote:
>>>> On 2017-01-10 11:56, Johannes Berg wrote:
>>>>> On Tue, 2017-01-10 at 05:18 +0100, Linus Lüssing wrote:
>>>>>> On Mon, Jan 09, 2017 at 01:30:32PM -0800, Stephen Hemminger wrote:
>>>>>>> I wonder if MAC80211 should be doing IGMP snooping and not bridge
>>>>>>> in this environment.
>>>>>> In the long term, yes. For now, not quite sure.
>>>>> There's no "for now" in the kernel. Code added now will have to be
>>>>> maintained essentially forever.
>>>> I'm not sure that putting the IGMP snooping code in mac80211 is a good
>>>> idea, that would be quite a bit of code duplication.
>>>> This implementation works, it's very simple, and it's quite flexible for
>>>> a number of use cases.
>>>>
>>>> Is there any remaining objection to merging this in principle (aside
>>>> from potential issues with the code)?
>>>>
>>>> - Felix
>>>>
>>>
>>> Hi Felix, can we consider two examples configurations with multicast
>>> traffic:
>>>
>>> 1. AP is a source of multicast traffic itself, no bridge on AP. For
>>> example, wireless video server streaming to several clients.
>>> In this situation, we can not make use of possible advantages given by
>>> mc-to-uc conversion?
>> You could simply put the AP interface in a bridge, no need to have any
>> other bridge members present.
>>
>>> 2. A configuration with AP + STA + 3 client devices behind STA.
>>> ----|client 1|
>>> |
>>> | mc |----|AP|----|STA|---|---|client 2|
>>> |server| |
>>> ----|client 3|
>>>
>>> Multicast server behind AP streams MC video traffic. All 3 clients
>>> behind the STA have joined the multicast group.
>>> I'm not sure if this case will be handled correctly with mc-to-uc
>>> conversion in bridge on AP?
>> What do you mean by "3 client devices behind STA"? Are you using a
>> 4-addr STA, multicast routing, or some kind of vendor specific "client
>> bridge" hackery?
>
> 3 client devices connected by backbone Ethernet network. Generic
> case is probably STA/AP operating in 4-addr mode (more or less standard
> solution as far as I know).
If the AP is running in 4-addr mode, it will need to have a bridge
interface anyway, because the link to the STA will be split out into a
separate virtual interface (AP_VLAN iftype).
In this case you don't actually need any multicast-to-unicast
conversion, because the multicast traffic will be unicast on 802.11
already (due to use of 4-addr mode).
- Felix
^ 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