* Re: AM43x boot broken on linux-next
From: Keerthy @ 2018-01-09 9:52 UTC (permalink / raw)
To: linux-omap; +Cc: Grygorii Strashko, netdev
In-Reply-To: <bf1fc3d2-b882-7850-4afd-c1e753e2a1a7@ti.com>
On Tuesday 09 January 2018 02:03 PM, Keerthy wrote:
> Hi,
Adding netdev@vger.kernel.org
>
> Seems like AM437x boot is broken on latest linux-next.
> Log here:
>
> https://pastebin.ubuntu.com/26351906/
>
> "Unable to handle kernel paging request at virtual address 000013e8
> [ 2.367045] pgd = c0350bf7
> [ 2.370019] [000013e8] *pgd=00000000
> [ 2.373823] Internal error: Oops: 5 [#1] SMP ARM
> [ 2.378709] Modules linked in:
> [ 2.381949] CPU: 0 PID: 1 Comm: swapper/0 Not tainted
> 4.15.0-rc6-next-20180108-38410-g895c0dd #4
> [ 2.391242] Hardware name: Generic AM43 (Flattened Device Tree)
> [ 2.397523] PC is at phy_attached_print+0xc/0x10c
> [ 2.402506] LR is at cpsw_slave_open+0x16c/0x258"
>
> Regards,
> Keerthy
>
^ permalink raw reply
* Re: [PATCH net-next v2 1/6] net: Fix netdev_WARN_ONCE macro
From: Gal Pressman @ 2018-01-09 9:51 UTC (permalink / raw)
To: David Miller, joe; +Cc: netdev, tariqt, saeedm
In-Reply-To: <20180108.220541.1359488060683672177.davem@davemloft.net>
On 09-Jan-18 05:05, David Miller wrote:
> From: Joe Perches <joe@perches.com>
> Date: Mon, 08 Jan 2018 18:42:01 -0800
>
>> On Sun, 2018-01-07 at 12:08 +0200, Gal Pressman wrote:
>>> netdev_WARN_ONCE is broken (whoops..), this fix will remove the
>>> unnecessary "condition" parameter, add the missing comma and change
>>> "arg" to "args".
>>>
>>> Fixes: 375ef2b1f0d0 ("net: Introduce netdev_*_once functions")
>>> Signed-off-by: Gal Pressman <galp@mellanox.com>
>>> Reviewed-by: Saeed Mahameed <saeedm@mellanox.com>
>>> ---
>>> include/linux/netdevice.h | 4 ++--
>>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
>>> index 352066e..5ff1ef9 100644
>>> --- a/include/linux/netdevice.h
>>> +++ b/include/linux/netdevice.h
>>> @@ -4407,8 +4407,8 @@ do { \
>>> WARN(1, "netdevice: %s%s\n" format, netdev_name(dev), \
>>> netdev_reg_state(dev), ##args)
>>>
>>> -#define netdev_WARN_ONCE(dev, condition, format, arg...) \
>>> - WARN_ONCE(1, "netdevice: %s%s\n" format, netdev_name(dev) \
>>> +#define netdev_WARN_ONCE(dev, format, args...) \
>>> + WARN_ONCE(1, "netdevice: %s%s\n" format, netdev_name(dev), \
>>
>> You sure you want the newline before the format?
>
> Hmmm, Gal please send me a relative fix for this.
>
The newline is removed in the next patch, which handles the formatting of both macros.
Do you want to remove it as part of this bug fix?
^ permalink raw reply
* Re: [PATCH v2] b43: Replace mdelay with usleep_range in b43_radio_2057_init_post
From: Jia-Ju Bai @ 2018-01-09 9:47 UTC (permalink / raw)
To: Arend van Spriel, Greg KH, Larry.Finger
Cc: kvalo, kstewart, johannes.berg, tiwai, colin.king,
andrew.zaborowski, linux-kernel, linux-wireless, netdev, b43-dev
In-Reply-To: <5A54864A.8020006@broadcom.com>
On 2018/1/9 17:07, Arend van Spriel wrote:
> On 1/9/2018 9:39 AM, Jia-Ju Bai wrote:
>>
>>
>> On 2018/1/9 16:35, Greg KH wrote:
>>> On Tue, Jan 09, 2018 at 09:40:06AM +0800, Jia-Ju Bai wrote:
>>>> b43_radio_2057_init_post is not called in an interrupt handler
>>>> nor holding a spinlock.
>>>> The function mdelay in it can be replaced with usleep_range,
>>>> to reduce busy wait.
>>>>
>>>> Signed-off-by: Jia-Ju Bai <baijiaju1990@gmail.com>
>>>> ---
>>>> v2:
>>>> * Replace mdelay with usleep_range, instead of msleep in v1.
>>>> Thank Larry for good advice.
>>>> ---
>>>> drivers/net/wireless/broadcom/b43/phy_n.c | 2 +-
>>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>>
>>>> diff --git a/drivers/net/wireless/broadcom/b43/phy_n.c
>>>> b/drivers/net/wireless/broadcom/b43/phy_n.c
>>>> index a5557d7..f2a2f41 100644
>>>> --- a/drivers/net/wireless/broadcom/b43/phy_n.c
>>>> +++ b/drivers/net/wireless/broadcom/b43/phy_n.c
>>>> @@ -1031,7 +1031,7 @@ static void b43_radio_2057_init_post(struct
>>>> b43_wldev *dev)
>>>> b43_radio_set(dev, R2057_RFPLL_MISC_CAL_RESETN, 0x78);
>>>> b43_radio_set(dev, R2057_XTAL_CONFIG2, 0x80);
>>>> - mdelay(2);
>>>> + usleep_range(2000, 3000);
>>> Where did 3000 come from? Are you sure about that?
>>
>> I am not very sure, and I use it according to Larry's message:
>
> Hi Jia-Ju Bai,
>
> The duration here is for settling the registers so hardware can pick
> it up. Right after this they are written again. Now this is during
> initialization of the radio so not time critical, but probably
> anything in the range of 2000..3000 would also have been fine.
Hi Arend,
Thanks for your detailed explanation :)
So I think usleep_range(2000, 3000) is okay.
Thanks,
Jia-Ju Bai
^ permalink raw reply
* Re: BUG: 4.14.11 unable to handle kernel NULL pointer dereference in xfrm_lookup
From: Steffen Klassert @ 2018-01-09 9:26 UTC (permalink / raw)
To: Tobias Hommel; +Cc: netdev
In-Reply-To: <20180109090651.wuxcdju5ynlkq25l@arbeitstier>
On Tue, Jan 09, 2018 at 10:06:51AM +0100, Tobias Hommel wrote:
> >
> > You have CONFIG_INET_ESP_OFFLOAD enabled, this is new maybe it
> > still has some problems. You should not hit an offload codepath
> > because all your SAs are configured with UDP encapsulation which
> > is still not supported with offload.
> >
> > Please try to disable GRO on both interfaces and see what happens:
> >
> > ethtool -K eth0 gro off
> > ethtool -K eth1 gro off
> I actually already tried that with only eth1 off, to verify I turned offloading
> off for both interfaces. The same problem: see attached panic.gro_off.log
>
> >
> > Then disable CONFIG_INET_ESP_OFFLOAD and try again.
> Rebuild with CONFIG_INET_ESP_OFFLOAD disabled, same problem: see attached
> panic.esp_offload_disabled.log
So ESP offload is not the problem. Next thing that comes to my mind
is the flowcache removal, this was introduced with v4.14.
>
> >
> > This should show us if this feature is responsible for the bug.
> >
>
> I will try narrowing down the problem by trying out some older kernels for now.
Thanks!
Let me know about the results.
^ permalink raw reply
* Re: [v2] net: gianfar_ptp: move set_fipers() to spinlock protecting area
From: Fabio Estevam @ 2018-01-09 9:15 UTC (permalink / raw)
To: Yangbo Lu; +Cc: Claudiu Manoil, Richard Cochran, netdev, linux-kernel
In-Reply-To: <20180109030233.16013-1-yangbo.lu@nxp.com>
On Tue, Jan 9, 2018 at 1:02 AM, Yangbo Lu <yangbo.lu@nxp.com> wrote:
> set_fipers() calling should be protected by spinlock in
> case that any interrupt breaks related registers setting
> and the function we expect. This patch is to move set_fipers()
> to spinlock protecting area in ptp_gianfar_adjtime().
>
> Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com>
> ---
> Changes for v2:
> - explained why spinlock was needed in commit message.
Thanks for improving the commit log:
Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
^ permalink raw reply
* Re: [PATCH v2] b43: Replace mdelay with usleep_range in b43_radio_2057_init_post
From: Arend van Spriel @ 2018-01-09 9:07 UTC (permalink / raw)
To: Jia-Ju Bai, Greg KH
Cc: Larry.Finger, kvalo, kstewart, johannes.berg, tiwai, colin.king,
andrew.zaborowski, linux-kernel, linux-wireless, netdev, b43-dev
In-Reply-To: <4201e8cd-81ba-ab7d-2a0d-af957c5dfed6@gmail.com>
On 1/9/2018 9:39 AM, Jia-Ju Bai wrote:
>
>
> On 2018/1/9 16:35, Greg KH wrote:
>> On Tue, Jan 09, 2018 at 09:40:06AM +0800, Jia-Ju Bai wrote:
>>> b43_radio_2057_init_post is not called in an interrupt handler
>>> nor holding a spinlock.
>>> The function mdelay in it can be replaced with usleep_range,
>>> to reduce busy wait.
>>>
>>> Signed-off-by: Jia-Ju Bai <baijiaju1990@gmail.com>
>>> ---
>>> v2:
>>> * Replace mdelay with usleep_range, instead of msleep in v1.
>>> Thank Larry for good advice.
>>> ---
>>> drivers/net/wireless/broadcom/b43/phy_n.c | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/net/wireless/broadcom/b43/phy_n.c
>>> b/drivers/net/wireless/broadcom/b43/phy_n.c
>>> index a5557d7..f2a2f41 100644
>>> --- a/drivers/net/wireless/broadcom/b43/phy_n.c
>>> +++ b/drivers/net/wireless/broadcom/b43/phy_n.c
>>> @@ -1031,7 +1031,7 @@ static void b43_radio_2057_init_post(struct
>>> b43_wldev *dev)
>>> b43_radio_set(dev, R2057_RFPLL_MISC_CAL_RESETN, 0x78);
>>> b43_radio_set(dev, R2057_XTAL_CONFIG2, 0x80);
>>> - mdelay(2);
>>> + usleep_range(2000, 3000);
>> Where did 3000 come from? Are you sure about that?
>
> I am not very sure, and I use it according to Larry's message:
Hi Jia-Ju Bai,
The duration here is for settling the registers so hardware can pick it
up. Right after this they are written again. Now this is during
initialization of the radio so not time critical, but probably anything
in the range of 2000..3000 would also have been fine.
Regards,
Arend
^ permalink raw reply
* Re: BUG: 4.14.11 unable to handle kernel NULL pointer dereference in xfrm_lookup
From: Tobias Hommel @ 2018-01-09 9:06 UTC (permalink / raw)
To: Steffen Klassert; +Cc: netdev
In-Reply-To: <20180109081939.qs2nrkuvmi3lw2dl@gauss3.secunet.de>
[-- Attachment #1: Type: text/plain, Size: 5736 bytes --]
On Tue, Jan 09, 2018 at 09:19:39AM +0100, Steffen Klassert wrote:
> On Mon, Jan 08, 2018 at 02:53:48PM +0100, Tobias Hommel wrote:
>
> ...
>
> > [ 439.095554] BUG: unable to handle kernel NULL pointer dereference at 0000000000000020
> > [ 439.103664] IP: xfrm_lookup+0x2a/0x7d0
> > [ 439.107551] PGD 0 P4D 0
> > [ 439.110144] Oops: 0000 [#1] SMP PTI
> > [ 439.113653] Modules linked in:
> > [ 439.116774] CPU: 6 PID: 0 Comm: swapper/6 Not tainted 4.14.12 #1
> > [ 439.122900] Hardware name: To be filled by O.E.M. CAR-2051/CAR, BIOS 1.01 07/11/2016
> > [ 439.130769] task: ffff8cf33b0ea280 task.stack: ffff9492c0090000
> > [ 439.136726] RIP: 0010:xfrm_lookup+0x2a/0x7d0
> > [ 439.141005] RSP: 0018:ffff8cf33fd83bd0 EFLAGS: 00010246
> > [ 439.146315] RAX: 0000000000000000 RBX: ffffffff87074080 RCX: 0000000000000000
> > [ 439.153537] RDX: ffff8cf33fd83c48 RSI: 0000000000000000 RDI: ffffffff87074080
> > [ 439.160780] RBP: ffffffff87074080 R08: 0000000000000002 R09: 0000000000000000
> > [ 439.167958] R10: 0000000000000020 R11: 0000000000000020 R12: ffff8cf33fd83c48
> > [ 439.175115] R13: 0000000000000000 R14: 0000000000000002 R15: ffff8cf33b240078
> > [ 439.182337] FS: 0000000000000000(0000) GS:ffff8cf33fd80000(0000) knlGS:0000000000000000
> > [ 439.190456] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> > [ 439.196227] CR2: 0000000000000020 CR3: 000000013200a000 CR4: 00000000001006e0
> > [ 439.203386] Call Trace:
> > [ 439.205869] <IRQ>
> > [ 439.207886] __xfrm_route_forward+0xa4/0x110
> > [ 439.212195] ip_forward+0x3da/0x450
> > [ 439.215696] ? ip_rcv_finish+0x61/0x390
> > [ 439.219542] ip_rcv+0x2b5/0x380
> > [ 439.222716] ? inet_del_offload+0x30/0x30
> > [ 439.226736] __netif_receive_skb_core+0x751/0xb00
> > [ 439.231469] ? netif_receive_skb_internal+0x47/0xf0
> > [ 439.236391] netif_receive_skb_internal+0x47/0xf0
> > [ 439.241150] napi_gro_flush+0x50/0x70
> > [ 439.244831] napi_complete_done+0x90/0xd0
> > [ 439.248872] igb_poll+0x8fd/0xe80
> > [ 439.252190] net_rx_action+0x1fc/0x310
> > [ 439.255978] __do_softirq+0xd5/0x1cf
> > [ 439.259584] irq_exit+0xa3/0xb0
> > [ 439.262763] do_IRQ+0x45/0xc0
> > [ 439.265772] common_interrupt+0x95/0x95
> > [ 439.269609] </IRQ>
> > [ 439.271733] RIP: 0010:cpuidle_enter_state+0x120/0x200
> > [ 439.276810] RSP: 0018:ffff9492c0093eb8 EFLAGS: 00000282 ORIG_RAX: ffffffffffffff5d
> > [ 439.284436] RAX: ffff8cf33fd9ea80 RBX: 0000000000000002 RCX: 000000663c21ea0f
> > [ 439.291604] RDX: 0000000000000000 RSI: 00000000355556ca RDI: 0000000000000000
> > [ 439.298772] RBP: ffff8cf33fda71e8 R08: 0000000000000003 R09: 0000000000000018
> > [ 439.305930] R10: 00000000ffffffff R11: 000000000000057c R12: 000000663c21ea0f
> > [ 439.313089] R13: 000000663c1c6c33 R14: 0000000000000002 R15: 0000000000000000
> > [ 439.320259] ? cpuidle_enter_state+0x11c/0x200
> > [ 439.324740] do_idle+0xd6/0x170
> > [ 439.327885] cpu_startup_entry+0x67/0x70
> > [ 439.331837] start_secondary+0x167/0x190
> > [ 439.335788] secondary_startup_64+0xa5/0xb0
> > [ 439.340001] Code: 00 41 57 41 56 45 89 c6 41 55 41 54 49 89 f5 55 53 49 89 d4 48 89 fb 48 83 ec 40 65 48 8b 04 25 28 00 00 00 48 89 44 24 38 31 c0 <48> 8b 46 20 48 85 c9 44 0f b7 38 c7 44 24 0c 00 00 00 00 0f 84
> > [ 439.358988] RIP: xfrm_lookup+0x2a/0x7d0 RSP: ffff8cf33fd83bd0
> > [ 439.364759] CR2: 0000000000000020
> > [ 439.368105] ---[ end trace c6b298b556ea7769 ]---
> > [ 439.372752] Kernel panic - not syncing: Fatal exception in interrupt
> > [ 439.379255] Kernel Offset: 0x5000000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)
> > [ 439.390029] Rebooting in 10 seconds..
>
> ...
>
> > 0000000000004230 <xfrm_lookup>:
> > 4230: 41 57 push %r15
> > 4232: 41 56 push %r14
> > 4234: 45 89 c6 mov %r8d,%r14d
> > 4237: 41 55 push %r13
> > 4239: 41 54 push %r12
> > 423b: 49 89 f5 mov %rsi,%r13
> > 423e: 55 push %rbp
> > 423f: 53 push %rbx
> > 4240: 49 89 d4 mov %rdx,%r12
> > 4243: 48 89 fb mov %rdi,%rbx
> > 4246: 48 83 ec 40 sub $0x40,%rsp
> > 424a: 65 48 8b 04 25 28 00 mov %gs:0x28,%rax
> > 4251: 00 00
> > 4253: 48 89 44 24 38 mov %rax,0x38(%rsp)
> > 4258: 31 c0 xor %eax,%eax
> > 425a: 48 8b 46 20 mov 0x20(%rsi),%rax
>
>
> The above is the failing instruction, RSI holds the second argument
> of the called function which is a NULL pointer. The second argument
> of xfrm_lookup() is dst_orig, so it is as I thought. Now let's find
> out why. I don't see anything obvious, so we need to narrow it down.
>
> > CONFIG_INET_ESP=y
> > CONFIG_INET_ESP_OFFLOAD=y
>
> You have CONFIG_INET_ESP_OFFLOAD enabled, this is new maybe it
> still has some problems. You should not hit an offload codepath
> because all your SAs are configured with UDP encapsulation which
> is still not supported with offload.
>
> Please try to disable GRO on both interfaces and see what happens:
>
> ethtool -K eth0 gro off
> ethtool -K eth1 gro off
I actually already tried that with only eth1 off, to verify I turned offloading
off for both interfaces. The same problem: see attached panic.gro_off.log
>
> Then disable CONFIG_INET_ESP_OFFLOAD and try again.
Rebuild with CONFIG_INET_ESP_OFFLOAD disabled, same problem: see attached
panic.esp_offload_disabled.log
>
> This should show us if this feature is responsible for the bug.
>
I will try narrowing down the problem by trying out some older kernels for now.
[-- Attachment #2: panic.esp_offload_disabled.log --]
[-- Type: text/plain, Size: 3344 bytes --]
[ 510.217190] BUG: unable to handle kernel NULL pointer dereference at 0000000000000020
[ 510.225167] IP: xfrm_lookup+0x2a/0x7d0
[ 510.228934] PGD 0 P4D 0
[ 510.231508] Oops: 0000 [#1] SMP PTI
[ 510.235006] Modules linked in:
[ 510.238085] CPU: 5 PID: 0 Comm: swapper/5 Not tainted 4.14.12 #2
[ 510.244116] Hardware name: To be filled by O.E.M. CAR-2051/CAR, BIOS 1.01 07/11/2016
[ 510.251881] task: ffff9cb6bb0e8000 task.stack: ffffb2ffc0088000
[ 510.257829] RIP: 0010:xfrm_lookup+0x2a/0x7d0
[ 510.262127] RSP: 0018:ffff9cb6bfd43c40 EFLAGS: 00010246
[ 510.267387] RAX: 0000000000000000 RBX: ffffffff83074080 RCX: 0000000000000000
[ 510.274570] RDX: ffff9cb6bfd43cb8 RSI: 0000000000000000 RDI: ffffffff83074080
[ 510.281729] RBP: ffffffff83074080 R08: 0000000000000002 R09: 0000000000000001
[ 510.288888] R10: 0000000000000032 R11: 0000000000000000 R12: ffff9cb6bfd43cb8
[ 510.296055] R13: 0000000000000000 R14: 0000000000000002 R15: ffff9cb6bb244078
[ 510.303215] FS: 0000000000000000(0000) GS:ffff9cb6bfd40000(0000) knlGS:0000000000000000
[ 510.311361] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 510.317135] CR2: 0000000000000020 CR3: 000000014c00a000 CR4: 00000000001006e0
[ 510.324317] Call Trace:
[ 510.326798] <IRQ>
[ 510.328855] __xfrm_route_forward+0xa4/0x110
[ 510.333152] ip_forward+0x3da/0x450
[ 510.336644] ? ip_rcv_finish+0x61/0x390
[ 510.340507] ip_rcv+0x2b5/0x380
[ 510.343654] ? inet_del_offload+0x30/0x30
[ 510.347693] __netif_receive_skb_core+0x751/0xb00
[ 510.352426] ? inet_gro_receive+0x1fb/0x2b0
[ 510.356646] ? netif_receive_skb_internal+0x47/0xf0
[ 510.361550] netif_receive_skb_internal+0x47/0xf0
[ 510.366284] napi_gro_receive+0x70/0x90
[ 510.370132] gro_cell_poll+0x53/0x90
[ 510.373736] net_rx_action+0x1fc/0x310
[ 510.377518] __do_softirq+0xd5/0x1cf
[ 510.381123] irq_exit+0xa3/0xb0
[ 510.384294] do_IRQ+0x45/0xc0
[ 510.387282] common_interrupt+0x95/0x95
[ 510.391148] </IRQ>
[ 510.393272] RIP: 0010:cpuidle_enter_state+0x120/0x200
[ 510.398350] RSP: 0018:ffffb2ffc008beb8 EFLAGS: 00000282 ORIG_RAX: ffffffffffffff3c
[ 510.405967] RAX: ffff9cb6bfd5ea80 RBX: 0000000000000002 RCX: 00000076cb4fb64c
[ 510.413150] RDX: 0000000000000000 RSI: 00000000355556ca RDI: 0000000000000000
[ 510.420326] RBP: ffff9cb6bfd671e8 R08: 0000000000000003 R09: 0000000000000018
[ 510.427485] R10: 00000000ffffffff R11: 0000000000000139 R12: 00000076cb4fb64c
[ 510.434695] R13: 00000076cb468ed2 R14: 0000000000000002 R15: 0000000000000000
[ 510.441866] ? cpuidle_enter_state+0x11c/0x200
[ 510.446330] do_idle+0xd6/0x170
[ 510.449491] cpu_startup_entry+0x67/0x70
[ 510.453443] start_secondary+0x167/0x190
[ 510.457397] secondary_startup_64+0xa5/0xb0
[ 510.461616] Code: 00 41 57 41 56 45 89 c6 41 55 41 54 49 89 f5 55 53 49 89 d4 48 89 fb 48 83 ec 40 65 48 8b 04 25 28 00 00 00 48 89 44 24 38 31 c0 <48> 8b 46 20 48 85 c9 44 0f b7 38 c7 44 24 0c 00 00 00 00 0f 84
[ 510.480605] RIP: xfrm_lookup+0x2a/0x7d0 RSP: ffff9cb6bfd43c40
[ 510.486411] CR2: 0000000000000020
[ 510.489758] ---[ end trace dc7eee0efd22329c ]---
[ 510.494411] Kernel panic - not syncing: Fatal exception in interrupt
[ 510.500923] Kernel Offset: 0x1000000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)
[ 510.511676] Rebooting in 10 seconds..
[-- Attachment #3: panic.gro_off.log --]
[-- Type: text/plain, Size: 2711 bytes --]
[ 1425.327056] BUG: unable to handle kernel NULL pointer dereference at 0000000000000020
[ 1425.335100] IP: xfrm_lookup+0x2a/0x7d0
[ 1425.339062] PGD 0 P4D 0
[ 1425.341645] Oops: 0000 [#1] SMP PTI
[ 1425.345275] Modules linked in:
[ 1425.348484] CPU: 2 PID: 22 Comm: ksoftirqd/2 Not tainted 4.14.12 #1
[ 1425.354958] Hardware name: To be filled by O.E.M. CAR-2051/CAR, BIOS 1.01 07/11/2016
[ 1425.363044] task: ffff986b3b210000 task.stack: ffff9c23000f0000
[ 1425.369234] RIP: 0010:xfrm_lookup+0x2a/0x7d0
[ 1425.373667] RSP: 0018:ffff9c23000f3b20 EFLAGS: 00010246
[ 1425.379032] RAX: 0000000000000000 RBX: ffffffff8e074080 RCX: 0000000000000000
[ 1425.386505] RDX: ffff9c23000f3b98 RSI: 0000000000000000 RDI: ffffffff8e074080
[ 1425.394062] RBP: ffffffff8e074080 R08: 0000000000000002 R09: 0000000000000000
[ 1425.401420] R10: 0000000000000020 R11: 0000000000000020 R12: ffff9c23000f3b98
[ 1425.408786] R13: 0000000000000000 R14: 0000000000000002 R15: ffff986b3b244078
[ 1425.416162] FS: 0000000000000000(0000) GS:ffff986b3fc80000(0000) knlGS:0000000000000000
[ 1425.424568] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 1425.430566] CR2: 0000000000000020 CR3: 000000006e00a000 CR4: 00000000001006e0
[ 1425.437940] Call Trace:
[ 1425.440486] __xfrm_route_forward+0xa4/0x110
[ 1425.444886] ip_forward+0x3da/0x450
[ 1425.448552] ? ip_rcv_finish+0x61/0x390
[ 1425.452519] ip_rcv+0x2b5/0x380
[ 1425.455727] ? inet_del_offload+0x30/0x30
[ 1425.459896] __netif_receive_skb_core+0x751/0xb00
[ 1425.464819] ? __alloc_pages_nodemask+0xc6/0x1f0
[ 1425.469723] ? netif_receive_skb_internal+0x47/0xf0
[ 1425.474931] netif_receive_skb_internal+0x47/0xf0
[ 1425.479768] napi_gro_receive+0x70/0x90
[ 1425.483781] igb_poll+0x600/0xe80
[ 1425.487283] ? xfrm4_dst_destroy+0x6d/0x90
[ 1425.491544] net_rx_action+0x1fc/0x310
[ 1425.495465] __do_softirq+0xd5/0x1cf
[ 1425.499156] run_ksoftirqd+0x14/0x30
[ 1425.502943] smpboot_thread_fn+0xf9/0x150
[ 1425.507250] kthread+0xf2/0x130
[ 1425.510577] ? sort_range+0x20/0x20
[ 1425.514269] ? kthread_park+0x60/0x60
[ 1425.518021] ret_from_fork+0x1f/0x30
[ 1425.521757] Code: 00 41 57 41 56 45 89 c6 41 55 41 54 49 89 f5 55 53 49 89 d4 48 89 fb 48 83 ec 40 65 48 8b 04 25 28 00 00 00 48 89 44 24 38 31 c0 <48> 8b 46 20 48 85 c9 44 0f b7 38 c7 44 24 0c 00 00 00 00 0f 84
[ 1425.541379] RIP: xfrm_lookup+0x2a/0x7d0 RSP: ffff9c23000f3b20
[ 1425.547367] CR2: 0000000000000020
[ 1425.550748] ---[ end trace 9cc9a035940887e0 ]---
[ 1425.555444] Kernel panic - not syncing: Fatal exception in interrupt
[ 1425.562184] Kernel Offset: 0xc000000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)
[ 1425.572955] Rebooting in 10 seconds..
^ permalink raw reply
* Re: [Intel-wired-lan] [PATCH 01/27] timecounter: Make cyclecounter struct part of timecounter struct
From: Sagar Arun Kamble @ 2018-01-09 9:01 UTC (permalink / raw)
To: Brown, Aaron F, linux-kernel@vger.kernel.org
Cc: alsa-devel@alsa-project.org, linux-rdma@vger.kernel.org,
netdev@vger.kernel.org, Richard Cochran, Stephen Boyd,
Chris Wilson, John Stultz, intel-wired-lan@lists.osuosl.org,
Thomas Gleixner, kvmarm@lists.cs.columbia.edu,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <309B89C4C689E141A5FF6A0C5FB2118B8C734DF8@ORSMSX101.amr.corp.intel.com>
Thanks Aaron.
Regards,
Sagar
On 1/9/2018 3:50 AM, Brown, Aaron F wrote:
>> From: Intel-wired-lan [mailto:intel-wired-lan-bounces@osuosl.org] On
>> Behalf Of Sagar Arun Kamble
>> Sent: Thursday, December 14, 2017 11:38 PM
>> To: linux-kernel@vger.kernel.org
>> Cc: alsa-devel@alsa-project.org; linux-rdma@vger.kernel.org;
>> netdev@vger.kernel.org; Richard Cochran <richardcochran@gmail.com>;
>> Stephen Boyd <sboyd@codeaurora.org>; Chris Wilson <chris@chris-
>> wilson.co.uk>; John Stultz <john.stultz@linaro.org>; intel-wired-
>> lan@lists.osuosl.org; Thomas Gleixner <tglx@linutronix.de>; Kamble, Sagar A
>> <sagar.a.kamble@intel.com>; kvmarm@lists.cs.columbia.edu; linux-arm-
>> kernel@lists.infradead.org
>> Subject: [Intel-wired-lan] [PATCH 01/27] timecounter: Make cyclecounter
>> struct part of timecounter struct
>>
>> There is no real need for the users of timecounters to define cyclecounter
>> and timecounter variables separately. Since timecounter will always be
>> based on cyclecounter, have cyclecounter struct as member of timecounter
>> struct.
>>
>> v2: Rebase.
>>
>> Suggested-by: Chris Wilson <chris@chris-wilson.co.uk>
>> Signed-off-by: Sagar Arun Kamble <sagar.a.kamble@intel.com>
>> Cc: Chris Wilson <chris@chris-wilson.co.uk>
>> Cc: Richard Cochran <richardcochran@gmail.com>
>> Cc: John Stultz <john.stultz@linaro.org>
>> Cc: Thomas Gleixner <tglx@linutronix.de>
>> Cc: Stephen Boyd <sboyd@codeaurora.org>
>> Cc: linux-kernel@vger.kernel.org
>> Cc: linux-arm-kernel@lists.infradead.org
>> Cc: netdev@vger.kernel.org
>> Cc: intel-wired-lan@lists.osuosl.org
>> Cc: linux-rdma@vger.kernel.org
>> Cc: alsa-devel@alsa-project.org
>> Cc: kvmarm@lists.cs.columbia.edu
>> Acked-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> (Intel drivers)
>> ---
>> arch/microblaze/kernel/timer.c | 20 ++++++------
>> drivers/clocksource/arm_arch_timer.c | 19 ++++++------
>> drivers/net/ethernet/amd/xgbe/xgbe-dev.c | 3 +-
>> drivers/net/ethernet/amd/xgbe/xgbe-ptp.c | 9 +++---
>> drivers/net/ethernet/amd/xgbe/xgbe.h | 1 -
>> drivers/net/ethernet/broadcom/bnx2x/bnx2x.h | 1 -
>> drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c | 20 ++++++------
>> drivers/net/ethernet/freescale/fec.h | 1 -
>> drivers/net/ethernet/freescale/fec_ptp.c | 30 +++++++++---------
>> drivers/net/ethernet/intel/e1000e/e1000.h | 1 -
>> drivers/net/ethernet/intel/e1000e/netdev.c | 27 ++++++++--------
>> drivers/net/ethernet/intel/e1000e/ptp.c | 2 +-
>> drivers/net/ethernet/intel/igb/igb.h | 1 -
>> drivers/net/ethernet/intel/igb/igb_ptp.c | 25 ++++++++-------
>> drivers/net/ethernet/intel/ixgbe/ixgbe.h | 1 -
>> drivers/net/ethernet/intel/ixgbe/ixgbe_ptp.c | 17 +++++-----
>> drivers/net/ethernet/mellanox/mlx4/en_clock.c | 28 ++++++++---------
>> drivers/net/ethernet/mellanox/mlx4/mlx4_en.h | 1 -
>> .../net/ethernet/mellanox/mlx5/core/lib/clock.c | 34 ++++++++++----------
>> drivers/net/ethernet/qlogic/qede/qede_ptp.c | 20 ++++++------
>> drivers/net/ethernet/ti/cpts.c | 36 ++++++++++++----------
>> drivers/net/ethernet/ti/cpts.h | 1 -
>> include/linux/mlx5/driver.h | 1 -
>> include/linux/timecounter.h | 4 +--
>> include/sound/hdaudio.h | 1 -
>> kernel/time/timecounter.c | 28 ++++++++---------
>> sound/hda/hdac_stream.c | 7 +++--
>> virt/kvm/arm/arch_timer.c | 6 ++--
>> 28 files changed, 163 insertions(+), 182 deletions(-)
>>
> For Intel e1000e and igb drivers:
> Tested-by: Aaron Brown <aaron.f.brown@intel.com>
^ permalink raw reply
* [PATCH net-next v3 4/4] net: mvpp2: 2500baseX support
From: Antoine Tenart @ 2018-01-09 8:59 UTC (permalink / raw)
To: davem, kishon
Cc: Antoine Tenart, andrew, gregory.clement, linux, mw, stefanc,
ymarkman, thomas.petazzoni, miquel.raynal, nadavh, netdev,
linux-arm-kernel, linux-kernel
In-Reply-To: <20180109085945.11916-1-antoine.tenart@free-electrons.com>
This patch adds the 2500Base-X PHY mode support in the Marvell PPv2
driver. 2500Base-X is quite close to 1000Base-X and SGMII modes and uses
nearly the same code path.
Signed-off-by: Antoine Tenart <antoine.tenart@free-electrons.com>
---
drivers/net/ethernet/marvell/mvpp2.c | 50 +++++++++++++++++++++++++++++-------
1 file changed, 41 insertions(+), 9 deletions(-)
diff --git a/drivers/net/ethernet/marvell/mvpp2.c b/drivers/net/ethernet/marvell/mvpp2.c
index 257a6b99b4ca..290f891421d1 100644
--- a/drivers/net/ethernet/marvell/mvpp2.c
+++ b/drivers/net/ethernet/marvell/mvpp2.c
@@ -4502,6 +4502,7 @@ static int mvpp22_gop_init(struct mvpp2_port *port)
break;
case PHY_INTERFACE_MODE_SGMII:
case PHY_INTERFACE_MODE_1000BASEX:
+ case PHY_INTERFACE_MODE_2500BASEX:
mvpp22_gop_init_sgmii(port);
break;
case PHY_INTERFACE_MODE_10GKR:
@@ -4540,7 +4541,8 @@ static void mvpp22_gop_unmask_irq(struct mvpp2_port *port)
if (phy_interface_mode_is_rgmii(port->phy_interface) ||
port->phy_interface == PHY_INTERFACE_MODE_SGMII ||
- port->phy_interface == PHY_INTERFACE_MODE_1000BASEX) {
+ port->phy_interface == PHY_INTERFACE_MODE_1000BASEX ||
+ port->phy_interface == PHY_INTERFACE_MODE_2500BASEX) {
/* Enable the GMAC link status irq for this port */
val = readl(port->base + MVPP22_GMAC_INT_SUM_MASK);
val |= MVPP22_GMAC_INT_SUM_MASK_LINK_STAT;
@@ -4571,7 +4573,8 @@ static void mvpp22_gop_mask_irq(struct mvpp2_port *port)
if (phy_interface_mode_is_rgmii(port->phy_interface) ||
port->phy_interface == PHY_INTERFACE_MODE_SGMII ||
- port->phy_interface == PHY_INTERFACE_MODE_1000BASEX) {
+ port->phy_interface == PHY_INTERFACE_MODE_1000BASEX ||
+ port->phy_interface == PHY_INTERFACE_MODE_2500BASEX) {
val = readl(port->base + MVPP22_GMAC_INT_SUM_MASK);
val &= ~MVPP22_GMAC_INT_SUM_MASK_LINK_STAT;
writel(val, port->base + MVPP22_GMAC_INT_SUM_MASK);
@@ -4584,7 +4587,8 @@ static void mvpp22_gop_setup_irq(struct mvpp2_port *port)
if (phy_interface_mode_is_rgmii(port->phy_interface) ||
port->phy_interface == PHY_INTERFACE_MODE_SGMII ||
- port->phy_interface == PHY_INTERFACE_MODE_1000BASEX) {
+ port->phy_interface == PHY_INTERFACE_MODE_1000BASEX ||
+ port->phy_interface == PHY_INTERFACE_MODE_2500BASEX) {
val = readl(port->base + MVPP22_GMAC_INT_MASK);
val |= MVPP22_GMAC_INT_MASK_LINK_STAT;
writel(val, port->base + MVPP22_GMAC_INT_MASK);
@@ -4599,6 +4603,16 @@ static void mvpp22_gop_setup_irq(struct mvpp2_port *port)
mvpp22_gop_unmask_irq(port);
}
+/* Sets the PHY mode of the COMPHY (which configures the serdes lanes).
+ *
+ * The PHY mode used by the PPv2 driver comes from the network subsystem, while
+ * the one given to the COMPHY comes from the generic PHY subsystem. Hence they
+ * differ.
+ *
+ * The COMPHY configures the serdes lanes regardless of the actual use of the
+ * lanes by the physical layer. This is why configurations like
+ * "PPv2 (2500BaseX) - COMPHY (2500SGMII)" are valid.
+ */
static int mvpp22_comphy_init(struct mvpp2_port *port)
{
enum phy_mode mode;
@@ -4612,6 +4626,9 @@ static int mvpp22_comphy_init(struct mvpp2_port *port)
case PHY_INTERFACE_MODE_1000BASEX:
mode = PHY_MODE_SGMII;
break;
+ case PHY_INTERFACE_MODE_2500BASEX:
+ mode = PHY_MODE_2500SGMII;
+ break;
case PHY_INTERFACE_MODE_10GKR:
mode = PHY_MODE_10GKR;
break;
@@ -4631,7 +4648,8 @@ static void mvpp2_port_mii_gmac_configure_mode(struct mvpp2_port *port)
u32 val;
if (port->phy_interface == PHY_INTERFACE_MODE_SGMII ||
- port->phy_interface == PHY_INTERFACE_MODE_1000BASEX) {
+ port->phy_interface == PHY_INTERFACE_MODE_1000BASEX ||
+ port->phy_interface == PHY_INTERFACE_MODE_2500BASEX) {
val = readl(port->base + MVPP22_GMAC_CTRL_4_REG);
val |= MVPP22_CTRL4_SYNC_BYPASS_DIS | MVPP22_CTRL4_DP_CLK_SEL |
MVPP22_CTRL4_QSGMII_BYPASS_ACTIVE;
@@ -4647,7 +4665,8 @@ static void mvpp2_port_mii_gmac_configure_mode(struct mvpp2_port *port)
}
val = readl(port->base + MVPP2_GMAC_CTRL_0_REG);
- if (port->phy_interface == PHY_INTERFACE_MODE_1000BASEX)
+ if (port->phy_interface == PHY_INTERFACE_MODE_1000BASEX ||
+ port->phy_interface == PHY_INTERFACE_MODE_2500BASEX)
val |= MVPP2_GMAC_PORT_TYPE_MASK;
else
val &= ~MVPP2_GMAC_PORT_TYPE_MASK;
@@ -4660,6 +4679,11 @@ static void mvpp2_port_mii_gmac_configure_mode(struct mvpp2_port *port)
if (port->phy_interface == PHY_INTERFACE_MODE_SGMII)
val |= MVPP2_GMAC_IN_BAND_AUTONEG;
+ /* Clear all fields we may want to explicitly set below */
+ val &= ~(MVPP2_GMAC_CONFIG_FULL_DUPLEX | MVPP2_GMAC_CONFIG_GMII_SPEED |
+ MVPP2_GMAC_CONFIG_MII_SPEED | MVPP2_GMAC_AN_SPEED_EN |
+ MVPP2_GMAC_AN_DUPLEX_EN);
+
if (port->phy_interface == PHY_INTERFACE_MODE_1000BASEX)
/* 1000BaseX port cannot negotiate speed nor can it
* negotiate duplex: they are always operating with a
@@ -4668,6 +4692,10 @@ static void mvpp2_port_mii_gmac_configure_mode(struct mvpp2_port *port)
*/
val |= MVPP2_GMAC_CONFIG_GMII_SPEED |
MVPP2_GMAC_CONFIG_FULL_DUPLEX;
+ else if (port->phy_interface == PHY_INTERFACE_MODE_2500BASEX)
+ val |= MVPP2_GMAC_CONFIG_GMII_SPEED |
+ MVPP2_GMAC_CONFIG_MII_SPEED |
+ MVPP2_GMAC_CONFIG_FULL_DUPLEX;
else
val |= MVPP2_GMAC_AN_SPEED_EN |
MVPP2_GMAC_AN_DUPLEX_EN;
@@ -4693,7 +4721,8 @@ static void mvpp2_port_mii_gmac_configure(struct mvpp2_port *port)
/* Configure the PCS and in-band AN */
val = readl(port->base + MVPP2_GMAC_CTRL_2_REG);
if (port->phy_interface == PHY_INTERFACE_MODE_SGMII ||
- port->phy_interface == PHY_INTERFACE_MODE_1000BASEX) {
+ port->phy_interface == PHY_INTERFACE_MODE_1000BASEX ||
+ port->phy_interface == PHY_INTERFACE_MODE_2500BASEX) {
val |= MVPP2_GMAC_INBAND_AN_MASK | MVPP2_GMAC_PCS_ENABLE_MASK;
} else if (phy_interface_mode_is_rgmii(port->phy_interface)) {
val &= ~MVPP2_GMAC_PCS_ENABLE_MASK;
@@ -4756,7 +4785,8 @@ static void mvpp2_port_mii_set(struct mvpp2_port *port)
if (phy_interface_mode_is_rgmii(port->phy_interface) ||
port->phy_interface == PHY_INTERFACE_MODE_SGMII ||
- port->phy_interface == PHY_INTERFACE_MODE_1000BASEX)
+ port->phy_interface == PHY_INTERFACE_MODE_1000BASEX ||
+ port->phy_interface == PHY_INTERFACE_MODE_2500BASEX)
mvpp2_port_mii_gmac_configure(port);
else if (port->phy_interface == PHY_INTERFACE_MODE_10GKR)
mvpp2_port_mii_xlg_configure(port);
@@ -4834,7 +4864,8 @@ static void mvpp2_port_loopback_set(struct mvpp2_port *port)
val &= ~MVPP2_GMAC_GMII_LB_EN_MASK;
if (port->phy_interface == PHY_INTERFACE_MODE_SGMII ||
- port->phy_interface == PHY_INTERFACE_MODE_1000BASEX)
+ port->phy_interface == PHY_INTERFACE_MODE_1000BASEX ||
+ port->phy_interface == PHY_INTERFACE_MODE_2500BASEX)
val |= MVPP2_GMAC_PCS_LB_EN_MASK;
else
val &= ~MVPP2_GMAC_PCS_LB_EN_MASK;
@@ -6048,7 +6079,8 @@ static irqreturn_t mvpp2_link_status_isr(int irq, void *dev_id)
}
} else if (phy_interface_mode_is_rgmii(port->phy_interface) ||
port->phy_interface == PHY_INTERFACE_MODE_SGMII ||
- port->phy_interface == PHY_INTERFACE_MODE_1000BASEX) {
+ port->phy_interface == PHY_INTERFACE_MODE_1000BASEX ||
+ port->phy_interface == PHY_INTERFACE_MODE_2500BASEX) {
val = readl(port->base + MVPP22_GMAC_INT_STAT);
if (val & MVPP22_GMAC_INT_STAT_LINK) {
event = true;
--
2.14.3
^ permalink raw reply related
* [PATCH net-next v3 3/4] net: mvpp2: 1000baseX support
From: Antoine Tenart @ 2018-01-09 8:59 UTC (permalink / raw)
To: davem, kishon
Cc: thomas.petazzoni, andrew, ymarkman, netdev, Antoine Tenart, linux,
linux-kernel, nadavh, miquel.raynal, gregory.clement, stefanc, mw,
linux-arm-kernel
In-Reply-To: <20180109085945.11916-1-antoine.tenart@free-electrons.com>
This patch adds the 1000Base-X PHY mode support in the Marvell PPv2
driver. 1000Base-X is quite close the SGMII and uses nearly the same
code path.
Signed-off-by: Antoine Tenart <antoine.tenart@free-electrons.com>
---
drivers/net/ethernet/marvell/mvpp2.c | 45 ++++++++++++++++++++++++++++--------
1 file changed, 35 insertions(+), 10 deletions(-)
diff --git a/drivers/net/ethernet/marvell/mvpp2.c b/drivers/net/ethernet/marvell/mvpp2.c
index a19760736b71..257a6b99b4ca 100644
--- a/drivers/net/ethernet/marvell/mvpp2.c
+++ b/drivers/net/ethernet/marvell/mvpp2.c
@@ -4501,6 +4501,7 @@ static int mvpp22_gop_init(struct mvpp2_port *port)
mvpp22_gop_init_rgmii(port);
break;
case PHY_INTERFACE_MODE_SGMII:
+ case PHY_INTERFACE_MODE_1000BASEX:
mvpp22_gop_init_sgmii(port);
break;
case PHY_INTERFACE_MODE_10GKR:
@@ -4538,7 +4539,8 @@ static void mvpp22_gop_unmask_irq(struct mvpp2_port *port)
u32 val;
if (phy_interface_mode_is_rgmii(port->phy_interface) ||
- port->phy_interface == PHY_INTERFACE_MODE_SGMII) {
+ port->phy_interface == PHY_INTERFACE_MODE_SGMII ||
+ port->phy_interface == PHY_INTERFACE_MODE_1000BASEX) {
/* Enable the GMAC link status irq for this port */
val = readl(port->base + MVPP22_GMAC_INT_SUM_MASK);
val |= MVPP22_GMAC_INT_SUM_MASK_LINK_STAT;
@@ -4568,7 +4570,8 @@ static void mvpp22_gop_mask_irq(struct mvpp2_port *port)
}
if (phy_interface_mode_is_rgmii(port->phy_interface) ||
- port->phy_interface == PHY_INTERFACE_MODE_SGMII) {
+ port->phy_interface == PHY_INTERFACE_MODE_SGMII ||
+ port->phy_interface == PHY_INTERFACE_MODE_1000BASEX) {
val = readl(port->base + MVPP22_GMAC_INT_SUM_MASK);
val &= ~MVPP22_GMAC_INT_SUM_MASK_LINK_STAT;
writel(val, port->base + MVPP22_GMAC_INT_SUM_MASK);
@@ -4580,7 +4583,8 @@ static void mvpp22_gop_setup_irq(struct mvpp2_port *port)
u32 val;
if (phy_interface_mode_is_rgmii(port->phy_interface) ||
- port->phy_interface == PHY_INTERFACE_MODE_SGMII) {
+ port->phy_interface == PHY_INTERFACE_MODE_SGMII ||
+ port->phy_interface == PHY_INTERFACE_MODE_1000BASEX) {
val = readl(port->base + MVPP22_GMAC_INT_MASK);
val |= MVPP22_GMAC_INT_MASK_LINK_STAT;
writel(val, port->base + MVPP22_GMAC_INT_MASK);
@@ -4605,6 +4609,7 @@ static int mvpp22_comphy_init(struct mvpp2_port *port)
switch (port->phy_interface) {
case PHY_INTERFACE_MODE_SGMII:
+ case PHY_INTERFACE_MODE_1000BASEX:
mode = PHY_MODE_SGMII;
break;
case PHY_INTERFACE_MODE_10GKR:
@@ -4625,7 +4630,8 @@ static void mvpp2_port_mii_gmac_configure_mode(struct mvpp2_port *port)
{
u32 val;
- if (port->phy_interface == PHY_INTERFACE_MODE_SGMII) {
+ if (port->phy_interface == PHY_INTERFACE_MODE_SGMII ||
+ port->phy_interface == PHY_INTERFACE_MODE_1000BASEX) {
val = readl(port->base + MVPP22_GMAC_CTRL_4_REG);
val |= MVPP22_CTRL4_SYNC_BYPASS_DIS | MVPP22_CTRL4_DP_CLK_SEL |
MVPP22_CTRL4_QSGMII_BYPASS_ACTIVE;
@@ -4640,9 +4646,11 @@ static void mvpp2_port_mii_gmac_configure_mode(struct mvpp2_port *port)
writel(val, port->base + MVPP22_GMAC_CTRL_4_REG);
}
- /* The port is connected to a copper PHY */
val = readl(port->base + MVPP2_GMAC_CTRL_0_REG);
- val &= ~MVPP2_GMAC_PORT_TYPE_MASK;
+ if (port->phy_interface == PHY_INTERFACE_MODE_1000BASEX)
+ val |= MVPP2_GMAC_PORT_TYPE_MASK;
+ else
+ val &= ~MVPP2_GMAC_PORT_TYPE_MASK;
writel(val, port->base + MVPP2_GMAC_CTRL_0_REG);
val = readl(port->base + MVPP2_GMAC_AUTONEG_CONFIG);
@@ -4651,6 +4659,19 @@ static void mvpp2_port_mii_gmac_configure_mode(struct mvpp2_port *port)
MVPP2_GMAC_AN_DUPLEX_EN;
if (port->phy_interface == PHY_INTERFACE_MODE_SGMII)
val |= MVPP2_GMAC_IN_BAND_AUTONEG;
+
+ if (port->phy_interface == PHY_INTERFACE_MODE_1000BASEX)
+ /* 1000BaseX port cannot negotiate speed nor can it
+ * negotiate duplex: they are always operating with a
+ * fixed speed of 1000Mbps in full duplex, so force
+ * 1000 speed and full duplex here.
+ */
+ val |= MVPP2_GMAC_CONFIG_GMII_SPEED |
+ MVPP2_GMAC_CONFIG_FULL_DUPLEX;
+ else
+ val |= MVPP2_GMAC_AN_SPEED_EN |
+ MVPP2_GMAC_AN_DUPLEX_EN;
+
writel(val, port->base + MVPP2_GMAC_AUTONEG_CONFIG);
}
@@ -4671,7 +4692,8 @@ static void mvpp2_port_mii_gmac_configure(struct mvpp2_port *port)
/* Configure the PCS and in-band AN */
val = readl(port->base + MVPP2_GMAC_CTRL_2_REG);
- if (port->phy_interface == PHY_INTERFACE_MODE_SGMII) {
+ if (port->phy_interface == PHY_INTERFACE_MODE_SGMII ||
+ port->phy_interface == PHY_INTERFACE_MODE_1000BASEX) {
val |= MVPP2_GMAC_INBAND_AN_MASK | MVPP2_GMAC_PCS_ENABLE_MASK;
} else if (phy_interface_mode_is_rgmii(port->phy_interface)) {
val &= ~MVPP2_GMAC_PCS_ENABLE_MASK;
@@ -4733,7 +4755,8 @@ static void mvpp2_port_mii_set(struct mvpp2_port *port)
mvpp22_port_mii_set(port);
if (phy_interface_mode_is_rgmii(port->phy_interface) ||
- port->phy_interface == PHY_INTERFACE_MODE_SGMII)
+ port->phy_interface == PHY_INTERFACE_MODE_SGMII ||
+ port->phy_interface == PHY_INTERFACE_MODE_1000BASEX)
mvpp2_port_mii_gmac_configure(port);
else if (port->phy_interface == PHY_INTERFACE_MODE_10GKR)
mvpp2_port_mii_xlg_configure(port);
@@ -4810,7 +4833,8 @@ static void mvpp2_port_loopback_set(struct mvpp2_port *port)
else
val &= ~MVPP2_GMAC_GMII_LB_EN_MASK;
- if (port->phy_interface == PHY_INTERFACE_MODE_SGMII)
+ if (port->phy_interface == PHY_INTERFACE_MODE_SGMII ||
+ port->phy_interface == PHY_INTERFACE_MODE_1000BASEX)
val |= MVPP2_GMAC_PCS_LB_EN_MASK;
else
val &= ~MVPP2_GMAC_PCS_LB_EN_MASK;
@@ -6023,7 +6047,8 @@ static irqreturn_t mvpp2_link_status_isr(int irq, void *dev_id)
link = true;
}
} else if (phy_interface_mode_is_rgmii(port->phy_interface) ||
- port->phy_interface == PHY_INTERFACE_MODE_SGMII) {
+ port->phy_interface == PHY_INTERFACE_MODE_SGMII ||
+ port->phy_interface == PHY_INTERFACE_MODE_1000BASEX) {
val = readl(port->base + MVPP22_GMAC_INT_STAT);
if (val & MVPP22_GMAC_INT_STAT_LINK) {
event = true;
--
2.14.3
^ permalink raw reply related
* [PATCH net-next v3 2/4] phy: cp110-comphy: 2.5G SGMII mode
From: Antoine Tenart @ 2018-01-09 8:59 UTC (permalink / raw)
To: davem, kishon
Cc: thomas.petazzoni, andrew, ymarkman, netdev, Antoine Tenart, linux,
linux-kernel, nadavh, miquel.raynal, gregory.clement, stefanc, mw,
linux-arm-kernel
In-Reply-To: <20180109085945.11916-1-antoine.tenart@free-electrons.com>
This patch allow the CP100 comphy to configure some lanes in the
2.5G SGMII mode. This mode is quite close to SGMII and uses nearly the
same code path.
Signed-off-by: Antoine Tenart <antoine.tenart@free-electrons.com>
---
drivers/phy/marvell/phy-mvebu-cp110-comphy.c | 17 ++++++++++++++---
1 file changed, 14 insertions(+), 3 deletions(-)
diff --git a/drivers/phy/marvell/phy-mvebu-cp110-comphy.c b/drivers/phy/marvell/phy-mvebu-cp110-comphy.c
index a0d522154cdf..4ef429250d7b 100644
--- a/drivers/phy/marvell/phy-mvebu-cp110-comphy.c
+++ b/drivers/phy/marvell/phy-mvebu-cp110-comphy.c
@@ -135,19 +135,25 @@ struct mvebu_comhy_conf {
static const struct mvebu_comhy_conf mvebu_comphy_cp110_modes[] = {
/* lane 0 */
MVEBU_COMPHY_CONF(0, 1, PHY_MODE_SGMII, 0x1),
+ MVEBU_COMPHY_CONF(0, 1, PHY_MODE_2500SGMII, 0x1),
/* lane 1 */
MVEBU_COMPHY_CONF(1, 2, PHY_MODE_SGMII, 0x1),
+ MVEBU_COMPHY_CONF(1, 2, PHY_MODE_2500SGMII, 0x1),
/* lane 2 */
MVEBU_COMPHY_CONF(2, 0, PHY_MODE_SGMII, 0x1),
+ MVEBU_COMPHY_CONF(2, 0, PHY_MODE_2500SGMII, 0x1),
MVEBU_COMPHY_CONF(2, 0, PHY_MODE_10GKR, 0x1),
/* lane 3 */
MVEBU_COMPHY_CONF(3, 1, PHY_MODE_SGMII, 0x2),
+ MVEBU_COMPHY_CONF(3, 1, PHY_MODE_2500SGMII, 0x2),
/* lane 4 */
MVEBU_COMPHY_CONF(4, 0, PHY_MODE_SGMII, 0x2),
+ MVEBU_COMPHY_CONF(4, 0, PHY_MODE_2500SGMII, 0x2),
MVEBU_COMPHY_CONF(4, 0, PHY_MODE_10GKR, 0x2),
MVEBU_COMPHY_CONF(4, 1, PHY_MODE_SGMII, 0x1),
/* lane 5 */
MVEBU_COMPHY_CONF(5, 2, PHY_MODE_SGMII, 0x1),
+ MVEBU_COMPHY_CONF(5, 2, PHY_MODE_2500SGMII, 0x1),
};
struct mvebu_comphy_priv {
@@ -206,6 +212,10 @@ static void mvebu_comphy_ethernet_init_reset(struct mvebu_comphy_lane *lane,
if (mode == PHY_MODE_10GKR)
val |= MVEBU_COMPHY_SERDES_CFG0_GEN_RX(0xe) |
MVEBU_COMPHY_SERDES_CFG0_GEN_TX(0xe);
+ else if (mode == PHY_MODE_2500SGMII)
+ val |= MVEBU_COMPHY_SERDES_CFG0_GEN_RX(0x8) |
+ MVEBU_COMPHY_SERDES_CFG0_GEN_TX(0x8) |
+ MVEBU_COMPHY_SERDES_CFG0_HALF_BUS;
else if (mode == PHY_MODE_SGMII)
val |= MVEBU_COMPHY_SERDES_CFG0_GEN_RX(0x6) |
MVEBU_COMPHY_SERDES_CFG0_GEN_TX(0x6) |
@@ -296,13 +306,13 @@ static int mvebu_comphy_init_plls(struct mvebu_comphy_lane *lane,
return 0;
}
-static int mvebu_comphy_set_mode_sgmii(struct phy *phy)
+static int mvebu_comphy_set_mode_sgmii(struct phy *phy, enum phy_mode mode)
{
struct mvebu_comphy_lane *lane = phy_get_drvdata(phy);
struct mvebu_comphy_priv *priv = lane->priv;
u32 val;
- mvebu_comphy_ethernet_init_reset(lane, PHY_MODE_SGMII);
+ mvebu_comphy_ethernet_init_reset(lane, mode);
val = readl(priv->base + MVEBU_COMPHY_RX_CTRL1(lane->id));
val &= ~MVEBU_COMPHY_RX_CTRL1_CLK8T_EN;
@@ -487,7 +497,8 @@ static int mvebu_comphy_power_on(struct phy *phy)
switch (lane->mode) {
case PHY_MODE_SGMII:
- ret = mvebu_comphy_set_mode_sgmii(phy);
+ case PHY_MODE_2500SGMII:
+ ret = mvebu_comphy_set_mode_sgmii(phy, lane->mode);
break;
case PHY_MODE_10GKR:
ret = mvebu_comphy_set_mode_10gkr(phy);
--
2.14.3
^ permalink raw reply related
* [PATCH net-next v3 1/4] phy: add 2.5G SGMII mode to the phy_mode enum
From: Antoine Tenart @ 2018-01-09 8:59 UTC (permalink / raw)
To: davem, kishon
Cc: Antoine Tenart, andrew, gregory.clement, linux, mw, stefanc,
ymarkman, thomas.petazzoni, miquel.raynal, nadavh, netdev,
linux-arm-kernel, linux-kernel
In-Reply-To: <20180109085945.11916-1-antoine.tenart@free-electrons.com>
This patch adds one more generic PHY mode to the phy_mode enum, to allow
configuring generic PHYs to the 2.5G SGMII mode by using the set_mode
callback.
Signed-off-by: Antoine Tenart <antoine.tenart@free-electrons.com>
---
include/linux/phy/phy.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h
index 4f8423a948d5..5a80e9de3686 100644
--- a/include/linux/phy/phy.h
+++ b/include/linux/phy/phy.h
@@ -28,6 +28,7 @@ enum phy_mode {
PHY_MODE_USB_DEVICE,
PHY_MODE_USB_OTG,
PHY_MODE_SGMII,
+ PHY_MODE_2500SGMII,
PHY_MODE_10GKR,
PHY_MODE_UFS_HS_A,
PHY_MODE_UFS_HS_B,
--
2.14.3
^ permalink raw reply related
* [PATCH net-next v3 0/4] net: mvpp2: 1000BaseX and 2500BaseX support
From: Antoine Tenart @ 2018-01-09 8:59 UTC (permalink / raw)
To: davem, kishon
Cc: thomas.petazzoni, andrew, ymarkman, netdev, Antoine Tenart, linux,
linux-kernel, nadavh, miquel.raynal, gregory.clement, stefanc, mw,
linux-arm-kernel
Hi all,
This series adds 1000BaseX and 2500BaseX support to the Marvell PPv2
driver. In order to use it, the 2.5 SGMII mode is added in the Marvell
common PHY driver (cp110-comphy).
This was tested on a mcbin.
All patches should probably go through net-next as patch 4/4 depends on
patch 1/4 to build and work.
Please note the two mvpp2 patches do not conflict with the ACPI series
v2 Marcin sent a few days ago, and the two series can be processed in
parallel. (Marcin is aware of me sending this series).
Thanks!
Antoine
Since v2:
- Added a comment before mvpp22_comphy_init() about the different PHY modes
used and why they differ between the PPv2 driver and the COMPHY one.
Since v1:
- s/PHY_MODE_SGMII_2_5G/PHY_MODE_2500SGMII/
- Fixed a build error in 'net: mvpp2: 1000baseX support' (which was solved in
the 2500baseX support one, but the bisection was broken).
- Removed the dt patches, as the fourth network interface on the mcbin also
needs PHYLINK support in the PPv2 driver to be correctly supported.
Antoine Tenart (4):
phy: add 2.5G SGMII mode to the phy_mode enum
phy: cp110-comphy: 2.5G SGMII mode
net: mvpp2: 1000baseX support
net: mvpp2: 2500baseX support
drivers/net/ethernet/marvell/mvpp2.c | 77 ++++++++++++++++++++++++----
drivers/phy/marvell/phy-mvebu-cp110-comphy.c | 17 ++++--
include/linux/phy/phy.h | 1 +
3 files changed, 82 insertions(+), 13 deletions(-)
--
2.14.3
^ permalink raw reply
* [PATCH] doc: clarification about setting SO_ZEROCOPY
From: Kornilios Kourtis @ 2018-01-09 8:52 UTC (permalink / raw)
To: netdev; +Cc: Willem de Bruijn
Signed-off-by: Kornilios Kourtis <kou@zurich.ibm.com>
---
Documentation/networking/msg_zerocopy.rst | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/Documentation/networking/msg_zerocopy.rst b/Documentation/networking/msg_zerocopy.rst
index 77f6d7e..c3380f4 100644
--- a/Documentation/networking/msg_zerocopy.rst
+++ b/Documentation/networking/msg_zerocopy.rst
@@ -72,6 +72,10 @@ this flag, a process must first signal intent by setting a socket option:
if (setsockopt(fd, SOL_SOCKET, SO_ZEROCOPY, &one, sizeof(one)))
error(1, errno, "setsockopt zerocopy");
+Setting the socket option only works when the socket is in its initial
+(TCP_CLOSED) state. Trying to set the option for a socket returned by accept(),
+for example, will lead to an EBUSY error. In this case, the option should be set
+to the listening socket and it will be inherited by the accepted sockets.
Transmission
------------
--
2.4.3
^ permalink raw reply related
* Re: [PATCH 07/18] [media] uvcvideo: prevent bounds-check bypass via speculative execution
From: Laurent Pinchart @ 2018-01-09 8:40 UTC (permalink / raw)
To: Greg KH
Cc: Dan Williams, linux-kernel, linux-arch, alan, peterz, netdev,
tglx, Mauro Carvalho Chehab, torvalds, Elena Reshetova,
linux-media
In-Reply-To: <20180106094026.GA11525@kroah.com>
Hi Greg,
On Saturday, 6 January 2018 11:40:26 EET Greg KH wrote:
> On Sat, Jan 06, 2018 at 10:09:07AM +0100, Greg KH wrote:
> > On Fri, Jan 05, 2018 at 05:10:32PM -0800, Dan Williams wrote:
> >> Static analysis reports that 'index' may be a user controlled value that
> >> is used as a data dependency to read 'pin' from the
> >> 'selector->baSourceID' array. In order to avoid potential leaks of
> >> kernel memory values, block speculative execution of the instruction
> >> stream that could issue reads based on an invalid value of 'pin'.
> >>
> >> Based on an original patch by Elena Reshetova.
> >>
> >> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> >> Cc: Mauro Carvalho Chehab <mchehab@kernel.org>
> >> Cc: linux-media@vger.kernel.org
> >> Signed-off-by: Elena Reshetova <elena.reshetova@intel.com>
> >> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
> >> ---
> >>
> >> drivers/media/usb/uvc/uvc_v4l2.c | 7 +++++--
> >> 1 file changed, 5 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/drivers/media/usb/uvc/uvc_v4l2.c
> >> b/drivers/media/usb/uvc/uvc_v4l2.c index 3e7e283a44a8..7442626dc20e
> >> 100644
> >> --- a/drivers/media/usb/uvc/uvc_v4l2.c
> >> +++ b/drivers/media/usb/uvc/uvc_v4l2.c
> >> @@ -22,6 +22,7 @@
> >> #include <linux/mm.h>
> >> #include <linux/wait.h>
> >> #include <linux/atomic.h>
> >> +#include <linux/compiler.h>
> >>
> >> #include <media/v4l2-common.h>
> >> #include <media/v4l2-ctrls.h>
> >> @@ -810,6 +811,7 @@ static int uvc_ioctl_enum_input(struct file *file,
> >> void *fh,
> >> struct uvc_entity *iterm = NULL;
> >> u32 index = input->index;
> >> int pin = 0;
> >> + __u8 *elem;
> >>
> >> if (selector == NULL ||
> >> (chain->dev->quirks & UVC_QUIRK_IGNORE_SELECTOR_UNIT)) {
> >> @@ -820,8 +822,9 @@ static int uvc_ioctl_enum_input(struct file *file,
> >> void *fh,
> >> break;
> >> }
> >> pin = iterm->id;
> >> - } else if (index < selector->bNrInPins) {
> >> - pin = selector->baSourceID[index];
> >> + } else if ((elem = nospec_array_ptr(selector->baSourceID, index,
> >> + selector->bNrInPins))) {
> >> + pin = *elem;
> >
> > I dug through this before, and I couldn't find where index came from
> > userspace, I think seeing the coverity rule would be nice.
>
> Ok, I take it back, this looks correct. Ugh, the v4l ioctl api is
> crazy complex (rightfully so), it's amazing that coverity could navigate
> that whole thing :)
>
> While I'm all for fixing this type of thing, I feel like we need to do
> something "else" for this as playing whack-a-mole for this pattern is
> going to be a never-ending battle for all drivers for forever.
That's my concern too, as even if we managed to find and fix all the
occurrences of the problematic patterns (and we won't), new ones will keep
being merged all the time.
> Either we need some way to mark this data path to make it easy for tools
> like sparse to flag easily, or we need to catch the issue in the driver
> subsystems, which unfortunatly, would harm the drivers that don't have
> this type of issue (like here.)
But how would you do so ?
> I'm guessing that other operating systems, which don't have the luxury
> of auditing all of their drivers are going for the "big hammer in the
> subsystem" type of fix, right?
Other operating systems that ship closed-source drivers authored by hardware
vendors and not reviewed by third parties will likely stay vulnerable forever.
That's a small concern though as I expect those drivers to contain much large
security holes anyway.
> I don't have a good answer for this, but if there was some better way to
> rewrite these types of patterns to just prevent the need for the
> nospec_array_ptr() type thing, that might be the best overall for
> everyone. Much like ebpf did with their changes. That way a simple
> coccinelle rule would be able to catch the pattern and rewrite it.
>
> Or am I just dreaming?
Likely, but sometimes dreams come true :-) Do you have an idea how this could
be done ?
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH v2] b43: Replace mdelay with usleep_range in b43_radio_2057_init_post
From: Jia-Ju Bai @ 2018-01-09 8:39 UTC (permalink / raw)
To: Greg KH
Cc: Larry.Finger, kvalo, kstewart, johannes.berg, tiwai, colin.king,
andrew.zaborowski, linux-kernel, linux-wireless, netdev, b43-dev
In-Reply-To: <20180109083541.GA13460@kroah.com>
On 2018/1/9 16:35, Greg KH wrote:
> On Tue, Jan 09, 2018 at 09:40:06AM +0800, Jia-Ju Bai wrote:
>> b43_radio_2057_init_post is not called in an interrupt handler
>> nor holding a spinlock.
>> The function mdelay in it can be replaced with usleep_range,
>> to reduce busy wait.
>>
>> Signed-off-by: Jia-Ju Bai <baijiaju1990@gmail.com>
>> ---
>> v2:
>> * Replace mdelay with usleep_range, instead of msleep in v1.
>> Thank Larry for good advice.
>> ---
>> drivers/net/wireless/broadcom/b43/phy_n.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/net/wireless/broadcom/b43/phy_n.c b/drivers/net/wireless/broadcom/b43/phy_n.c
>> index a5557d7..f2a2f41 100644
>> --- a/drivers/net/wireless/broadcom/b43/phy_n.c
>> +++ b/drivers/net/wireless/broadcom/b43/phy_n.c
>> @@ -1031,7 +1031,7 @@ static void b43_radio_2057_init_post(struct b43_wldev *dev)
>>
>> b43_radio_set(dev, R2057_RFPLL_MISC_CAL_RESETN, 0x78);
>> b43_radio_set(dev, R2057_XTAL_CONFIG2, 0x80);
>> - mdelay(2);
>> + usleep_range(2000, 3000);
> Where did 3000 come from? Are you sure about that?
I am not very sure, and I use it according to Larry's message:
> I had negative comments on one of those due to the possibility of
> msleep(2) extending as long as 20 msec. Until the author, or someone
> else, can test that this is OK, then the mdelay(2) can only be
> replaced with usleep_range(2000, 3000).
Thanks,
Jia-Ju Bai
^ permalink raw reply
* Re: [PATCH 0/2] net: dsa: lan9303: check error value from devm_gpiod_get_optional()
From: Phil Reid @ 2018-01-09 8:38 UTC (permalink / raw)
To: Egil Hjelmeland, andrew, vivien.didelot, f.fainelli, netdev,
linux-kernel, bianpan2016, stable
In-Reply-To: <7efb44a6-d8f1-6c00-e966-efc9329075e4@egil-hjelmeland.no>
On 7/01/2018 00:54, Egil Hjelmeland wrote:
> Den 13. nov. 2017 09:07, skrev Phil Reid:
>> Replaces Pan Bian <bianpan2016@163.com> patch
>> "net: dsa: lan9303: correctly check return value of devm_gpiod_get_optional"
>>
>> Errors need to be prograted back from probe.
>>
>> Note: I have only compile tested the code as I don't have the hardware.
>>
>> Phil Reid (2):
>> net: dsa: lan9303: make lan9303_handle_reset() a void function
>> net: dsa: lan9303: check error value from devm_gpiod_get_optional()
>>
>> drivers/net/dsa/lan9303-core.c | 21 ++++++++++++---------
>> 1 file changed, 12 insertions(+), 9 deletions(-)
>>
>
> Evidently this one did not make it through. Do you care to rebase and try again?
>
> Thanks
> Egil
>
>
Sure I'll give it another go.
--
Regards
Phil Reid
^ permalink raw reply
* Re: [PATCH net, v2] of_mdio: avoid MDIO bus removal when a PHY is missing
From: Geert Uytterhoeven @ 2018-01-09 8:35 UTC (permalink / raw)
To: Madalin-cristian Bucur
Cc: Andrew Lunn, Florian Fainelli, David S. Miller,
Geert Uytterhoeven, Rob Herring, Frank Rowand, netdev, devicetree,
Linux Kernel Mailing List
In-Reply-To: <1515486819-8954-1-git-send-email-madalin.bucur@nxp.com>
Hi Madalin,
On Tue, Jan 9, 2018 at 9:33 AM, Madalin Bucur <madalin.bucur@nxp.com> wrote:
> If one of the child devices is missing the of_mdiobus_register_phy()
> call will return -ENODEV. When a missing device is encountered the
> registration of the remaining PHYs is stopped and the MDIO bus will
> fail to register. Propagate all errors except ENODEV to avoid it.
>
> Signed-off-by: Madalin Bucur <madalin.bucur@nxp.com>
Thanks for your patch!
> ---
> v2: add an error print for the first change; the second place has
> some noise aleady generated by the exing code
>
> drivers/of/of_mdio.c | 12 +++++++++---
> 1 file changed, 9 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/of/of_mdio.c b/drivers/of/of_mdio.c
> index 3481e69..a249370 100644
> --- a/drivers/of/of_mdio.c
> +++ b/drivers/of/of_mdio.c
> @@ -231,8 +231,14 @@ int of_mdiobus_register(struct mii_bus *mdio, struct device_node *np)
> rc = of_mdiobus_register_phy(mdio, child, addr);
> else
> rc = of_mdiobus_register_device(mdio, child, addr);
> - if (rc)
> - goto unregister;
> +
> + if (rc == -ENODEV)
> + dev_err(&mdio->dev,
> + "MDIO device at address %d is missing.\n",
> + addr);
> + else
> + if (rc)
You can merge the two lines above into a single line.
> + goto unregister;
... dropping the need to reindent the above line.
> }
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH v2] b43: Replace mdelay with usleep_range in b43_radio_2057_init_post
From: Greg KH @ 2018-01-09 8:35 UTC (permalink / raw)
To: Jia-Ju Bai
Cc: Larry.Finger, kvalo, kstewart, johannes.berg, tiwai, colin.king,
andrew.zaborowski, linux-kernel, linux-wireless, netdev, b43-dev
In-Reply-To: <1515462006-6144-1-git-send-email-baijiaju1990@gmail.com>
On Tue, Jan 09, 2018 at 09:40:06AM +0800, Jia-Ju Bai wrote:
> b43_radio_2057_init_post is not called in an interrupt handler
> nor holding a spinlock.
> The function mdelay in it can be replaced with usleep_range,
> to reduce busy wait.
>
> Signed-off-by: Jia-Ju Bai <baijiaju1990@gmail.com>
> ---
> v2:
> * Replace mdelay with usleep_range, instead of msleep in v1.
> Thank Larry for good advice.
> ---
> drivers/net/wireless/broadcom/b43/phy_n.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/broadcom/b43/phy_n.c b/drivers/net/wireless/broadcom/b43/phy_n.c
> index a5557d7..f2a2f41 100644
> --- a/drivers/net/wireless/broadcom/b43/phy_n.c
> +++ b/drivers/net/wireless/broadcom/b43/phy_n.c
> @@ -1031,7 +1031,7 @@ static void b43_radio_2057_init_post(struct b43_wldev *dev)
>
> b43_radio_set(dev, R2057_RFPLL_MISC_CAL_RESETN, 0x78);
> b43_radio_set(dev, R2057_XTAL_CONFIG2, 0x80);
> - mdelay(2);
> + usleep_range(2000, 3000);
Where did 3000 come from? Are you sure about that?
thanks,
greg k-h
^ permalink raw reply
* [PATCH net, v2] of_mdio: avoid MDIO bus removal when a PHY is missing
From: Madalin Bucur @ 2018-01-09 8:33 UTC (permalink / raw)
To: andrew, f.fainelli, davem
Cc: geert+renesas, robh+dt, frowand.list, netdev, devicetree,
linux-kernel, Madalin Bucur
If one of the child devices is missing the of_mdiobus_register_phy()
call will return -ENODEV. When a missing device is encountered the
registration of the remaining PHYs is stopped and the MDIO bus will
fail to register. Propagate all errors except ENODEV to avoid it.
Signed-off-by: Madalin Bucur <madalin.bucur@nxp.com>
---
v2: add an error print for the first change; the second place has
some noise aleady generated by the exing code
drivers/of/of_mdio.c | 12 +++++++++---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/of/of_mdio.c b/drivers/of/of_mdio.c
index 3481e69..a249370 100644
--- a/drivers/of/of_mdio.c
+++ b/drivers/of/of_mdio.c
@@ -231,8 +231,14 @@ int of_mdiobus_register(struct mii_bus *mdio, struct device_node *np)
rc = of_mdiobus_register_phy(mdio, child, addr);
else
rc = of_mdiobus_register_device(mdio, child, addr);
- if (rc)
- goto unregister;
+
+ if (rc == -ENODEV)
+ dev_err(&mdio->dev,
+ "MDIO device at address %d is missing.\n",
+ addr);
+ else
+ if (rc)
+ goto unregister;
}
if (!scanphys)
@@ -255,7 +261,7 @@ int of_mdiobus_register(struct mii_bus *mdio, struct device_node *np)
if (of_mdiobus_child_is_phy(child)) {
rc = of_mdiobus_register_phy(mdio, child, addr);
- if (rc)
+ if (rc && rc != -ENODEV)
goto unregister;
}
}
--
2.1.0
^ permalink raw reply related
* Re: [V2] wcn36xx: fix incorrect assignment to msg_body.min_ch_time
From: Kalle Valo @ 2018-01-09 8:20 UTC (permalink / raw)
To: Colin Ian King
Cc: Eugene Krasnikov, wcn36xx, linux-wireless, netdev,
kernel-janitors, linux-kernel
In-Reply-To: <20171229090732.14928-1-colin.king@canonical.com>
Colin Ian King <colin.king@canonical.com> wrote:
> The second assignment to msg_body.min_ch_time is incorrect, it
> should actually be to msg_body.max_ch_time.
>
> Thanks to Bjorn Andersson for identifying the correct way to fix
> this as my original fix was incorrect.
>
> Detected by CoverityScan, CID#1463042 ("Unused Value")
>
> Fixes: 2f3bef4b247e ("wcn36xx: Add hardware scan offload support")
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
> Acked-by: Bjorn Andersson <bjorn.andersson@linaro.org>
> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Patch applied to ath-next branch of ath.git, thanks.
4c8cf8df2f42 wcn36xx: fix incorrect assignment to msg_body.min_ch_time
--
https://patchwork.kernel.org/patch/10136929/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: BUG: 4.14.11 unable to handle kernel NULL pointer dereference in xfrm_lookup
From: Steffen Klassert @ 2018-01-09 8:19 UTC (permalink / raw)
To: Tobias Hommel; +Cc: netdev
In-Reply-To: <20180108135347.3gvr5dhkzqb7pzhm@arbeitstier>
On Mon, Jan 08, 2018 at 02:53:48PM +0100, Tobias Hommel wrote:
...
> [ 439.095554] BUG: unable to handle kernel NULL pointer dereference at 0000000000000020
> [ 439.103664] IP: xfrm_lookup+0x2a/0x7d0
> [ 439.107551] PGD 0 P4D 0
> [ 439.110144] Oops: 0000 [#1] SMP PTI
> [ 439.113653] Modules linked in:
> [ 439.116774] CPU: 6 PID: 0 Comm: swapper/6 Not tainted 4.14.12 #1
> [ 439.122900] Hardware name: To be filled by O.E.M. CAR-2051/CAR, BIOS 1.01 07/11/2016
> [ 439.130769] task: ffff8cf33b0ea280 task.stack: ffff9492c0090000
> [ 439.136726] RIP: 0010:xfrm_lookup+0x2a/0x7d0
> [ 439.141005] RSP: 0018:ffff8cf33fd83bd0 EFLAGS: 00010246
> [ 439.146315] RAX: 0000000000000000 RBX: ffffffff87074080 RCX: 0000000000000000
> [ 439.153537] RDX: ffff8cf33fd83c48 RSI: 0000000000000000 RDI: ffffffff87074080
> [ 439.160780] RBP: ffffffff87074080 R08: 0000000000000002 R09: 0000000000000000
> [ 439.167958] R10: 0000000000000020 R11: 0000000000000020 R12: ffff8cf33fd83c48
> [ 439.175115] R13: 0000000000000000 R14: 0000000000000002 R15: ffff8cf33b240078
> [ 439.182337] FS: 0000000000000000(0000) GS:ffff8cf33fd80000(0000) knlGS:0000000000000000
> [ 439.190456] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [ 439.196227] CR2: 0000000000000020 CR3: 000000013200a000 CR4: 00000000001006e0
> [ 439.203386] Call Trace:
> [ 439.205869] <IRQ>
> [ 439.207886] __xfrm_route_forward+0xa4/0x110
> [ 439.212195] ip_forward+0x3da/0x450
> [ 439.215696] ? ip_rcv_finish+0x61/0x390
> [ 439.219542] ip_rcv+0x2b5/0x380
> [ 439.222716] ? inet_del_offload+0x30/0x30
> [ 439.226736] __netif_receive_skb_core+0x751/0xb00
> [ 439.231469] ? netif_receive_skb_internal+0x47/0xf0
> [ 439.236391] netif_receive_skb_internal+0x47/0xf0
> [ 439.241150] napi_gro_flush+0x50/0x70
> [ 439.244831] napi_complete_done+0x90/0xd0
> [ 439.248872] igb_poll+0x8fd/0xe80
> [ 439.252190] net_rx_action+0x1fc/0x310
> [ 439.255978] __do_softirq+0xd5/0x1cf
> [ 439.259584] irq_exit+0xa3/0xb0
> [ 439.262763] do_IRQ+0x45/0xc0
> [ 439.265772] common_interrupt+0x95/0x95
> [ 439.269609] </IRQ>
> [ 439.271733] RIP: 0010:cpuidle_enter_state+0x120/0x200
> [ 439.276810] RSP: 0018:ffff9492c0093eb8 EFLAGS: 00000282 ORIG_RAX: ffffffffffffff5d
> [ 439.284436] RAX: ffff8cf33fd9ea80 RBX: 0000000000000002 RCX: 000000663c21ea0f
> [ 439.291604] RDX: 0000000000000000 RSI: 00000000355556ca RDI: 0000000000000000
> [ 439.298772] RBP: ffff8cf33fda71e8 R08: 0000000000000003 R09: 0000000000000018
> [ 439.305930] R10: 00000000ffffffff R11: 000000000000057c R12: 000000663c21ea0f
> [ 439.313089] R13: 000000663c1c6c33 R14: 0000000000000002 R15: 0000000000000000
> [ 439.320259] ? cpuidle_enter_state+0x11c/0x200
> [ 439.324740] do_idle+0xd6/0x170
> [ 439.327885] cpu_startup_entry+0x67/0x70
> [ 439.331837] start_secondary+0x167/0x190
> [ 439.335788] secondary_startup_64+0xa5/0xb0
> [ 439.340001] Code: 00 41 57 41 56 45 89 c6 41 55 41 54 49 89 f5 55 53 49 89 d4 48 89 fb 48 83 ec 40 65 48 8b 04 25 28 00 00 00 48 89 44 24 38 31 c0 <48> 8b 46 20 48 85 c9 44 0f b7 38 c7 44 24 0c 00 00 00 00 0f 84
> [ 439.358988] RIP: xfrm_lookup+0x2a/0x7d0 RSP: ffff8cf33fd83bd0
> [ 439.364759] CR2: 0000000000000020
> [ 439.368105] ---[ end trace c6b298b556ea7769 ]---
> [ 439.372752] Kernel panic - not syncing: Fatal exception in interrupt
> [ 439.379255] Kernel Offset: 0x5000000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)
> [ 439.390029] Rebooting in 10 seconds..
...
> 0000000000004230 <xfrm_lookup>:
> 4230: 41 57 push %r15
> 4232: 41 56 push %r14
> 4234: 45 89 c6 mov %r8d,%r14d
> 4237: 41 55 push %r13
> 4239: 41 54 push %r12
> 423b: 49 89 f5 mov %rsi,%r13
> 423e: 55 push %rbp
> 423f: 53 push %rbx
> 4240: 49 89 d4 mov %rdx,%r12
> 4243: 48 89 fb mov %rdi,%rbx
> 4246: 48 83 ec 40 sub $0x40,%rsp
> 424a: 65 48 8b 04 25 28 00 mov %gs:0x28,%rax
> 4251: 00 00
> 4253: 48 89 44 24 38 mov %rax,0x38(%rsp)
> 4258: 31 c0 xor %eax,%eax
> 425a: 48 8b 46 20 mov 0x20(%rsi),%rax
The above is the failing instruction, RSI holds the second argument
of the called function which is a NULL pointer. The second argument
of xfrm_lookup() is dst_orig, so it is as I thought. Now let's find
out why. I don't see anything obvious, so we need to narrow it down.
> CONFIG_INET_ESP=y
> CONFIG_INET_ESP_OFFLOAD=y
You have CONFIG_INET_ESP_OFFLOAD enabled, this is new maybe it
still has some problems. You should not hit an offload codepath
because all your SAs are configured with UDP encapsulation which
is still not supported with offload.
Please try to disable GRO on both interfaces and see what happens:
ethtool -K eth0 gro off
ethtool -K eth1 gro off
Then disable CONFIG_INET_ESP_OFFLOAD and try again.
This should show us if this feature is responsible for the bug.
^ permalink raw reply
* Re: [PATCH net-next 00/18] ipv6: Align nexthop behaviour with IPv4
From: Ido Schimmel @ 2018-01-09 8:04 UTC (permalink / raw)
To: David Ahern
Cc: Ido Schimmel, netdev, davem, roopa, nicolas.dichtel, weiwan,
kafai, yoshfuji, mlxsw
In-Reply-To: <5c10b955-161d-9cb1-edd1-7a49d88e46ad@gmail.com>
On Sun, Jan 07, 2018 at 10:20:11AM -0700, David Ahern wrote:
> One of many follow on changes that would be beneficial is to remove the
> idev dereference in the hot path to check the
> ignore_routes_with_linkdown sysctl.
When a netdev loses its carrier we can set the RTNH_F_DEAD flag for all
the nexthops using it as their nexthop device, in case the sysctl is
set. Similarly, when the sysctl is toggled we can walk the routing
tables and toggle the flag where appropriate.
You have a different idea?
Thanks for reviewing!
^ permalink raw reply
* Re: [PATCH net-next 1/3] ethtool: Ensure new ring parameters are within bounds during SRINGPARAM
From: Jakub Kicinski @ 2018-01-09 7:35 UTC (permalink / raw)
To: Tariq Toukan; +Cc: David S. Miller, netdev, Eran Ben Elisha, Eugenia Emantayev
In-Reply-To: <d87fd32a-474f-fccf-fecc-29301e592869@mellanox.com>
On Tue, 9 Jan 2018 09:30:05 +0200
Tariq Toukan <tariqt@mellanox.com> wrote:
> >> diff --git a/net/core/ethtool.c b/net/core/ethtool.c
> >> index 50a79203043b..9ea7cd52fde0 100644
> >> --- a/net/core/ethtool.c
> >> +++ b/net/core/ethtool.c
> >> @@ -1704,14 +1704,23 @@ static int ethtool_get_ringparam(struct
> >> net_device *dev, void __user *useraddr)
> >> static int ethtool_set_ringparam(struct net_device *dev, void
> >> __user *useraddr) {
> >> - struct ethtool_ringparam ringparam;
> >> + struct ethtool_ringparam ringparam, max = { .cmd =
> >> ETHTOOL_GRINGPARAM };
> >> - if (!dev->ethtool_ops->set_ringparam)
> >> + if (!dev->ethtool_ops->set_ringparam
> >> || !dev->ethtool_ops->get_ringparam) return -EOPNOTSUPP;
> >>
> >> if (copy_from_user(&ringparam, useraddr,
> >> sizeof(ringparam))) return -EFAULT;
> >>
> >> + dev->ethtool_ops->get_ringparam(dev, &max);
> >
> > Perhaps check the return value here? It's pretty unlikely but
> > get_ringparam may fail.
> >
>
> get_ringparam NDO returns void.
Ah, you're right, I looked at the return of ethtool_get_ringparam().
^ permalink raw reply
* [patch iproute2 v7 2/2] tc: Add batchsize feature for filter and actions
From: Chris Mi @ 2018-01-09 6:59 UTC (permalink / raw)
To: netdev; +Cc: gerlitz.or, stephen, dsahern, marcelo.leitner, phil
In-Reply-To: <20180109065908.19754-1-chrism@mellanox.com>
Currently in tc batch mode, only one command is read from the batch
file and sent to kernel to process. With this support, at most 128
commands can be accumulated before sending to kernel.
Now it only works for the following successive commands:
filter and actions add/delete/change/replace.
Signed-off-by: Chris Mi <chrism@mellanox.com>
---
tc/m_action.c | 60 +++++++++++++++++----------
tc/tc.c | 127 ++++++++++++++++++++++++++++++++++++++++++++++++++-------
tc/tc_common.h | 5 ++-
tc/tc_filter.c | 97 +++++++++++++++++++++++++------------------
4 files changed, 210 insertions(+), 79 deletions(-)
diff --git a/tc/m_action.c b/tc/m_action.c
index fc422364..e5c53a80 100644
--- a/tc/m_action.c
+++ b/tc/m_action.c
@@ -546,40 +546,56 @@ bad_val:
return ret;
}
+struct tc_action_req {
+ struct nlmsghdr n;
+ struct tcamsg t;
+ char buf[MAX_MSG];
+};
+
static int tc_action_modify(int cmd, unsigned int flags,
- int *argc_p, char ***argv_p)
+ int *argc_p, char ***argv_p,
+ void *buf)
{
- int argc = *argc_p;
+ struct tc_action_req *req, action_req;
char **argv = *argv_p;
+ struct rtattr *tail;
+ int argc = *argc_p;
+ struct iovec iov;
int ret = 0;
- struct {
- struct nlmsghdr n;
- struct tcamsg t;
- char buf[MAX_MSG];
- } req = {
- .n.nlmsg_len = NLMSG_LENGTH(sizeof(struct tcamsg)),
- .n.nlmsg_flags = NLM_F_REQUEST | flags,
- .n.nlmsg_type = cmd,
- .t.tca_family = AF_UNSPEC,
- };
- struct rtattr *tail = NLMSG_TAIL(&req.n);
+
+ if (buf)
+ req = buf;
+ else
+ req = &action_req;
+
+ req->n.nlmsg_len = NLMSG_LENGTH(sizeof(struct tcamsg));
+ req->n.nlmsg_flags = NLM_F_REQUEST | flags;
+ req->n.nlmsg_type = cmd;
+ req->t.tca_family = AF_UNSPEC;
+ tail = NLMSG_TAIL(&req->n);
argc -= 1;
argv += 1;
- if (parse_action(&argc, &argv, TCA_ACT_TAB, &req.n)) {
+ if (parse_action(&argc, &argv, TCA_ACT_TAB, &req->n)) {
fprintf(stderr, "Illegal \"action\"\n");
return -1;
}
- tail->rta_len = (void *) NLMSG_TAIL(&req.n) - (void *) tail;
+ tail->rta_len = (void *) NLMSG_TAIL(&req->n) - (void *) tail;
+
+ *argc_p = argc;
+ *argv_p = argv;
- if (rtnl_talk(&rth, &req.n, NULL) < 0) {
+ iov.iov_base = &req->n;
+ iov.iov_len = req->n.nlmsg_len;
+
+ if (buf)
+ return 0;
+
+ if (rtnl_talk_iov(&rth, &iov, 1, NULL) < 0) {
fprintf(stderr, "We have an error talking to the kernel\n");
ret = -1;
}
- *argc_p = argc;
- *argv_p = argv;
-
return ret;
}
@@ -679,7 +695,7 @@ bad_val:
return ret;
}
-int do_action(int argc, char **argv)
+int do_action(int argc, char **argv, void *buf)
{
int ret = 0;
@@ -689,12 +705,12 @@ int do_action(int argc, char **argv)
if (matches(*argv, "add") == 0) {
ret = tc_action_modify(RTM_NEWACTION,
NLM_F_EXCL | NLM_F_CREATE,
- &argc, &argv);
+ &argc, &argv, buf);
} else if (matches(*argv, "change") == 0 ||
matches(*argv, "replace") == 0) {
ret = tc_action_modify(RTM_NEWACTION,
NLM_F_CREATE | NLM_F_REPLACE,
- &argc, &argv);
+ &argc, &argv, buf);
} else if (matches(*argv, "delete") == 0) {
argc -= 1;
argv += 1;
diff --git a/tc/tc.c b/tc/tc.c
index ad9f07e9..f32e4978 100644
--- a/tc/tc.c
+++ b/tc/tc.c
@@ -193,16 +193,16 @@ static void usage(void)
" -nm | -nam[es] | { -cf | -conf } path } | -j[son]\n");
}
-static int do_cmd(int argc, char **argv)
+static int do_cmd(int argc, char **argv, void *buf)
{
if (matches(*argv, "qdisc") == 0)
return do_qdisc(argc-1, argv+1);
if (matches(*argv, "class") == 0)
return do_class(argc-1, argv+1);
if (matches(*argv, "filter") == 0)
- return do_filter(argc-1, argv+1);
+ return do_filter(argc-1, argv+1, buf);
if (matches(*argv, "actions") == 0)
- return do_action(argc-1, argv+1);
+ return do_action(argc-1, argv+1, buf);
if (matches(*argv, "monitor") == 0)
return do_tcmonitor(argc-1, argv+1);
if (matches(*argv, "exec") == 0)
@@ -217,11 +217,39 @@ static int do_cmd(int argc, char **argv)
return -1;
}
+static bool batchsize_enabled(int argc, char *argv[])
+{
+ if (argc < 2)
+ return false;
+ if ((strcmp(argv[0], "filter") && strcmp(argv[0], "action"))
+ || (strcmp(argv[1], "add") && strcmp(argv[1], "delete")
+ && strcmp(argv[1], "change") && strcmp(argv[1], "replace")))
+ return false;
+
+ return true;
+}
+
+struct batch_buf {
+ struct batch_buf *next;
+ char buf[16420]; /* sizeof (struct nlmsghdr) +
+ sizeof (struct tcmsg) +
+ MAX_MSG */
+};
+
static int batch(const char *name)
{
- char *line = NULL;
+ struct batch_buf *head = NULL, *tail = NULL, *buf;
+ char *largv[100], *largv_next[100];
+ char *line, *line_next = NULL;
+ bool bs_enabled_next = false;
+ bool bs_enabled = false;
+ bool lastline = false;
+ int largc, largc_next;
+ bool bs_enabled_saved;
+ int batchsize = 0;
size_t len = 0;
- int ret = 0;
+ int ret = 0, i;
+ bool send;
batch_mode = 1;
if (name && strcmp(name, "-") != 0) {
@@ -240,23 +268,92 @@ static int batch(const char *name)
}
cmdlineno = 0;
- while (getcmdline(&line, &len, stdin) != -1) {
- char *largv[100];
- int largc;
+ if (getcmdline(&line, &len, stdin) == -1)
+ goto Exit;
+ largc = makeargs(line, largv, 100);
+ bs_enabled = batchsize_enabled(largc, largv);
+ bs_enabled_saved = bs_enabled;
+ do {
+ if (getcmdline(&line_next, &len, stdin) == -1)
+ lastline = true;
+
+ largc_next = makeargs(line_next, largv_next, 100);
+ bs_enabled_next = batchsize_enabled(largc_next, largv_next);
+ if (bs_enabled) {
+ buf = calloc(1, sizeof (struct batch_buf));
+ if (head == NULL) {
+ head = tail = buf;
+ buf->next = NULL;
+ } else {
+ buf->next = NULL;
+ tail->next = buf;
+ tail = buf;
+ }
+ ++batchsize;
+ }
+
+ /*
+ * In batch mode, if we haven't accumulated enough commands
+ * and this is not the last command and this command & next
+ * command both support the batchsize feature, don't send the
+ * message immediately.
+ */
+ if (!lastline && bs_enabled && bs_enabled_next
+ && batchsize != MSG_IOV_MAX)
+ send = false;
+ else
+ send = true;
+
+ line = line_next;
+ line_next = NULL;
+ len = 0;
+ bs_enabled_saved = bs_enabled;
+ bs_enabled = bs_enabled_next;
+ bs_enabled_next = false;
- largc = makeargs(line, largv, 100);
if (largc == 0)
continue; /* blank line */
- if (do_cmd(largc, largv)) {
- fprintf(stderr, "Command failed %s:%d\n", name, cmdlineno);
+ ret = do_cmd(largc, largv, tail == NULL ? NULL : tail->buf);
+ if (ret != 0) {
+ fprintf(stderr, "Command failed %s:%d\n", name,
+ cmdlineno - 1);
ret = 1;
if (!force)
break;
}
- }
- if (line)
- free(line);
+ largc = largc_next;
+ for (i = 0; i < largc; i ++)
+ largv[i] = largv_next[i];
+
+ if (send && bs_enabled_saved) {
+ struct iovec *iov, *iovs;
+ struct nlmsghdr *n;
+ iov = iovs = malloc(batchsize * sizeof (struct iovec));
+ for (buf = head; buf != NULL; buf = buf->next, ++iov) {
+ n = (struct nlmsghdr *)&buf->buf;
+ iov->iov_base = n;
+ iov->iov_len = n->nlmsg_len;
+ }
+
+ ret = rtnl_talk_iov(&rth, iovs, batchsize, NULL);
+ if (ret < 0) {
+ fprintf(stderr, "Command failed %s:%d\n", name,
+ cmdlineno - (batchsize + ret) - 1);
+ return 2;
+ }
+ for (buf = head; buf != NULL; buf = head) {
+ head = buf->next;
+ free(buf);
+ }
+ head = tail = NULL;
+ batchsize = 0;
+ free(iovs);
+ }
+ } while (!lastline);
+
+Exit:
+ free(line);
rtnl_close(&rth);
return ret;
@@ -341,7 +438,7 @@ int main(int argc, char **argv)
goto Exit;
}
- ret = do_cmd(argc-1, argv+1);
+ ret = do_cmd(argc-1, argv+1, NULL);
Exit:
rtnl_close(&rth);
diff --git a/tc/tc_common.h b/tc/tc_common.h
index 264fbdac..59018da5 100644
--- a/tc/tc_common.h
+++ b/tc/tc_common.h
@@ -1,13 +1,14 @@
/* SPDX-License-Identifier: GPL-2.0 */
#define TCA_BUF_MAX (64*1024)
+#define MSG_IOV_MAX 128
extern struct rtnl_handle rth;
extern int do_qdisc(int argc, char **argv);
extern int do_class(int argc, char **argv);
-extern int do_filter(int argc, char **argv);
-extern int do_action(int argc, char **argv);
+extern int do_filter(int argc, char **argv, void *buf);
+extern int do_action(int argc, char **argv, void *buf);
extern int do_tcmonitor(int argc, char **argv);
extern int do_exec(int argc, char **argv);
diff --git a/tc/tc_filter.c b/tc/tc_filter.c
index 545cc3a1..7db4964b 100644
--- a/tc/tc_filter.c
+++ b/tc/tc_filter.c
@@ -42,28 +42,38 @@ static void usage(void)
"OPTIONS := ... try tc filter add <desired FILTER_KIND> help\n");
}
-static int tc_filter_modify(int cmd, unsigned int flags, int argc, char **argv)
+struct tc_filter_req {
+ struct nlmsghdr n;
+ struct tcmsg t;
+ char buf[MAX_MSG];
+};
+
+static int tc_filter_modify(int cmd, unsigned int flags, int argc, char **argv,
+ void *buf)
{
- struct {
- struct nlmsghdr n;
- struct tcmsg t;
- char buf[MAX_MSG];
- } req = {
- .n.nlmsg_len = NLMSG_LENGTH(sizeof(struct tcmsg)),
- .n.nlmsg_flags = NLM_F_REQUEST | flags,
- .n.nlmsg_type = cmd,
- .t.tcm_family = AF_UNSPEC,
- };
+ struct tc_filter_req *req, filter_req;
struct filter_util *q = NULL;
- __u32 prio = 0;
- __u32 protocol = 0;
- int protocol_set = 0;
- __u32 chain_index;
+ struct tc_estimator est = {};
+ char k[FILTER_NAMESZ] = {};
int chain_index_set = 0;
+ char d[IFNAMSIZ] = {};
+ int protocol_set = 0;
char *fhandle = NULL;
- char d[IFNAMSIZ] = {};
- char k[FILTER_NAMESZ] = {};
- struct tc_estimator est = {};
+ __u32 protocol = 0;
+ __u32 chain_index;
+ struct iovec iov;
+ __u32 prio = 0;
+ int ret;
+
+ if (buf)
+ req = buf;
+ else
+ req = &filter_req;
+
+ req->n.nlmsg_len = NLMSG_LENGTH(sizeof(struct tcmsg));
+ req->n.nlmsg_flags = NLM_F_REQUEST | flags;
+ req->n.nlmsg_type = cmd;
+ req->t.tcm_family = AF_UNSPEC;
if (cmd == RTM_NEWTFILTER && flags & NLM_F_CREATE)
protocol = htons(ETH_P_ALL);
@@ -75,37 +85,37 @@ static int tc_filter_modify(int cmd, unsigned int flags, int argc, char **argv)
duparg("dev", *argv);
strncpy(d, *argv, sizeof(d)-1);
} else if (strcmp(*argv, "root") == 0) {
- if (req.t.tcm_parent) {
+ if (req->t.tcm_parent) {
fprintf(stderr,
"Error: \"root\" is duplicate parent ID\n");
return -1;
}
- req.t.tcm_parent = TC_H_ROOT;
+ req->t.tcm_parent = TC_H_ROOT;
} else if (strcmp(*argv, "ingress") == 0) {
- if (req.t.tcm_parent) {
+ if (req->t.tcm_parent) {
fprintf(stderr,
"Error: \"ingress\" is duplicate parent ID\n");
return -1;
}
- req.t.tcm_parent = TC_H_MAKE(TC_H_CLSACT,
+ req->t.tcm_parent = TC_H_MAKE(TC_H_CLSACT,
TC_H_MIN_INGRESS);
} else if (strcmp(*argv, "egress") == 0) {
- if (req.t.tcm_parent) {
+ if (req->t.tcm_parent) {
fprintf(stderr,
"Error: \"egress\" is duplicate parent ID\n");
return -1;
}
- req.t.tcm_parent = TC_H_MAKE(TC_H_CLSACT,
+ req->t.tcm_parent = TC_H_MAKE(TC_H_CLSACT,
TC_H_MIN_EGRESS);
} else if (strcmp(*argv, "parent") == 0) {
__u32 handle;
NEXT_ARG();
- if (req.t.tcm_parent)
+ if (req->t.tcm_parent)
duparg("parent", *argv);
if (get_tc_classid(&handle, *argv))
invarg("Invalid parent ID", *argv);
- req.t.tcm_parent = handle;
+ req->t.tcm_parent = handle;
} else if (strcmp(*argv, "handle") == 0) {
NEXT_ARG();
if (fhandle)
@@ -152,26 +162,26 @@ static int tc_filter_modify(int cmd, unsigned int flags, int argc, char **argv)
argc--; argv++;
}
- req.t.tcm_info = TC_H_MAKE(prio<<16, protocol);
+ req->t.tcm_info = TC_H_MAKE(prio<<16, protocol);
if (chain_index_set)
- addattr32(&req.n, sizeof(req), TCA_CHAIN, chain_index);
+ addattr32(&req->n, sizeof(*req), TCA_CHAIN, chain_index);
if (k[0])
- addattr_l(&req.n, sizeof(req), TCA_KIND, k, strlen(k)+1);
+ addattr_l(&req->n, sizeof(*req), TCA_KIND, k, strlen(k)+1);
if (d[0]) {
ll_init_map(&rth);
- req.t.tcm_ifindex = ll_name_to_index(d);
- if (req.t.tcm_ifindex == 0) {
+ req->t.tcm_ifindex = ll_name_to_index(d);
+ if (req->t.tcm_ifindex == 0) {
fprintf(stderr, "Cannot find device \"%s\"\n", d);
return 1;
}
}
if (q) {
- if (q->parse_fopt(q, fhandle, argc, argv, &req.n))
+ if (q->parse_fopt(q, fhandle, argc, argv, &req->n))
return 1;
} else {
if (fhandle) {
@@ -190,10 +200,17 @@ static int tc_filter_modify(int cmd, unsigned int flags, int argc, char **argv)
}
if (est.ewma_log)
- addattr_l(&req.n, sizeof(req), TCA_RATE, &est, sizeof(est));
+ addattr_l(&req->n, sizeof(*req), TCA_RATE, &est, sizeof(est));
- if (rtnl_talk(&rth, &req.n, NULL) < 0) {
- fprintf(stderr, "We have an error talking to the kernel\n");
+ iov.iov_base = &req->n;
+ iov.iov_len = req->n.nlmsg_len;
+
+ if (buf)
+ return 0;
+
+ ret = rtnl_talk_iov(&rth, &iov, 1, NULL);
+ if (ret < 0) {
+ fprintf(stderr, "We have an error talking to the kernel, %d\n", ret);
return 2;
}
@@ -636,20 +653,20 @@ static int tc_filter_list(int argc, char **argv)
return 0;
}
-int do_filter(int argc, char **argv)
+int do_filter(int argc, char **argv, void *buf)
{
if (argc < 1)
return tc_filter_list(0, NULL);
if (matches(*argv, "add") == 0)
return tc_filter_modify(RTM_NEWTFILTER, NLM_F_EXCL|NLM_F_CREATE,
- argc-1, argv+1);
+ argc-1, argv+1, buf);
if (matches(*argv, "change") == 0)
- return tc_filter_modify(RTM_NEWTFILTER, 0, argc-1, argv+1);
+ return tc_filter_modify(RTM_NEWTFILTER, 0, argc-1, argv+1, buf);
if (matches(*argv, "replace") == 0)
return tc_filter_modify(RTM_NEWTFILTER, NLM_F_CREATE, argc-1,
- argv+1);
+ argv+1, buf);
if (matches(*argv, "delete") == 0)
- return tc_filter_modify(RTM_DELTFILTER, 0, argc-1, argv+1);
+ return tc_filter_modify(RTM_DELTFILTER, 0, argc-1, argv+1, buf);
if (matches(*argv, "get") == 0)
return tc_filter_get(RTM_GETTFILTER, 0, argc-1, argv+1);
if (matches(*argv, "list") == 0 || matches(*argv, "show") == 0
--
2.14.3
^ permalink raw reply related
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