* WARNING at net/mac80211/sta_info.c:1057 (__sta_info_destroy_part2())
From: Linus Torvalds @ 2019-09-11 10:05 UTC (permalink / raw)
To: Johannes Berg, David S. Miller
Cc: linux-wireless, Netdev, Linux List Kernel Mailing
So I'm at LCA, reading email, using my laptop more than I normally do,
and with different networking than I normally do.
And I just had a 802.11 WARN_ON() trigger, followed by essentially a
dead machine due to some lock held (maybe rtnl_lock).
It's possible that the lock held thing happened before, and is the
_reason_ for the delay, I don't know. I had to reboot the machine, but
I gathered as much information as made sense and was obvious before I
did so. That's appended.
Linus
---
Selected dmesg from the WARN_ON_ONCE() and just before, followed by
info from "sysrq-w":
Previous resume looks normal:
PM: suspend exit
ath10k_pci 0000:02:00.0: UART prints enabled
ath10k_pci 0000:02:00.0: unsupported HTC service id: 1536
wlp2s0: authenticate with 54:ec:2f:05:70:2c
wlp2s0: send auth to 54:ec:2f:05:70:2c (try 1/3)
wlp2s0: send auth to 54:ec:2f:05:70:2c (try 2/3)
wlp2s0: send auth to 54:ec:2f:05:70:2c (try 3/3)
wlp2s0: authentication with 54:ec:2f:05:70:2c timed out
wlp2s0: authenticate with 54:ec:2f:05:70:28
wlp2s0: send auth to 54:ec:2f:05:70:28 (try 1/3)
wlp2s0: authenticated
wlp2s0: associate with 54:ec:2f:05:70:28 (try 1/3)
wlp2s0: RX AssocResp from 54:ec:2f:05:70:28 (capab=0x1431 status=0 aid=1)
wlp2s0: associated
wlp2s0: Limiting TX power to 20 (20 - 0) dBm as advertised by
54:ec:2f:05:70:28
ath: EEPROM regdomain: 0x826c
ath: EEPROM indicates we should expect a country code
ath: doing EEPROM country->regdmn map search
ath: country maps to regdmn code: 0x37
ath: Country alpha2 being used: PT
ath: Regpair used: 0x37
ath: regdomain 0x826c dynamically updated by country element
IPv6: ADDRCONF(NETDEV_CHANGE): wlp2s0: link becomes ready
wlp2s0: disconnect from AP 54:ec:2f:05:70:28 for new auth to
54:ec:2f:05:70:2c
wlp2s0: authenticate with 54:ec:2f:05:70:2c
wlp2s0: send auth to 54:ec:2f:05:70:2c (try 1/3)
wlp2s0: authenticated
wlp2s0: associate with 54:ec:2f:05:70:2c (try 1/3)
wlp2s0: RX ReassocResp from 54:ec:2f:05:70:2c (capab=0x1011 status=0 aid=2)
wlp2s0: associated
ath: EEPROM regdomain: 0x826c
ath: EEPROM indicates we should expect a country code
ath: doing EEPROM country->regdmn map search
ath: country maps to regdmn code: 0x37
ath: Country alpha2 being used: PT
ath: Regpair used: 0x37
ath: regdomain 0x826c dynamically updated by country element
wlp2s0: Limiting TX power to 23 (23 - 0) dBm as advertised by
54:ec:2f:05:70:2c
Another _almost_ successful suspend/resume:
PM: suspend entry (s2idle)
Filesystems sync: 0.028 seconds
Freezing user space processes ... (elapsed 0.126 seconds) done.
OOM killer disabled.
Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
printk: Suspending console(s) (use no_console_suspend to debug)
wlp2s0: deauthenticating from 54:ec:2f:05:70:2c by local choice
(Reason: 3=DEAUTH_LEAVING)
ath10k_pci 0000:02:00.0: UART prints enabled
ath10k_pci 0000:02:00.0: unsupported HTC service id: 1536
OOM killer enabled.
Restarting tasks ... done.
PM: suspend exit
ath10k_pci 0000:02:00.0: UART prints enabled
ath10k_pci 0000:02:00.0: unsupported HTC service id: 1536
wlp2s0: authenticate with 54:ec:2f:05:70:2c
wlp2s0: send auth to 54:ec:2f:05:70:2c (try 1/3)
wlp2s0: authenticated
wlp2s0: associate with 54:ec:2f:05:70:2c (try 1/3)
wlp2s0: RX AssocResp from 54:ec:2f:05:70:2c (capab=0x1011 status=0 aid=2)
wlp2s0: associated
wlp2s0: Limiting TX power to 23 (23 - 0) dBm as advertised by
54:ec:2f:05:70:2c
ath: EEPROM regdomain: 0x826c
ath: EEPROM indicates we should expect a country code
ath: doing EEPROM country->regdmn map search
ath: country maps to regdmn code: 0x37
ath: Country alpha2 being used: PT
ath: Regpair used: 0x37
ath: regdomain 0x826c dynamically updated by country element
IPv6: ADDRCONF(NETDEV_CHANGE): wlp2s0: link becomes ready
I say _almost_, because I don't see the "No TX power limit" for the
country lookup (yes, Portugal) this time?
But wait!
... then 10+ minutes later:
ath10k_pci 0000:02:00.0: wmi command 16387 timeout, restarting hardware
ath10k_pci 0000:02:00.0: failed to set 5g txpower 23: -11
ath10k_pci 0000:02:00.0: failed to setup tx power 23: -11
ath10k_pci 0000:02:00.0: failed to recalc tx power: -11
ath10k_pci 0000:02:00.0: failed to set inactivity time for vdev 0: -108
ath10k_pci 0000:02:00.0: failed to setup powersave: -108
That certainly looks like something did try to set a power limit, but
eventually failed.
Immediately after that:
wlp2s0: deauthenticating from 54:ec:2f:05:70:2c by local choice
(Reason: 3=DEAUTH_LEAVING)
ath10k_pci 0000:02:00.0: failed to read hi_board_data address: -16
ath10k_pci 0000:02:00.0: failed to receive initialized event from
target: 00000000
ath10k_pci 0000:02:00.0: failed to receive initialized event from
target: 00000000
ath10k_pci 0000:02:00.0: failed to wait for target init: -110
ieee80211 phy0: Hardware restart was requested
ath10k_pci 0000:02:00.0: failed to set inactivity time for vdev 0: -108
ath10k_pci 0000:02:00.0: failed to setup powersave: -108
ath10k_pci 0000:02:00.0: failed to set PS Mode 0 for vdev 0: -108
ath10k_pci 0000:02:00.0: failed to setup powersave: -108
ath10k_pci 0000:02:00.0: failed to setup ps on vdev 0: -108
ath10k_pci 0000:02:00.0: failed to flush transmit queue (skip 1
ar-state 2): 5000
ath10k_pci 0000:02:00.0: failed to delete peer 54:ec:2f:05:70:2c
for vdev 0: -108
and this then results in:
WARNING: CPU: 4 PID: 1246 at net/mac80211/sta_info.c:1057
__sta_info_destroy_part2+0x147/0x150 [mac80211]
Modules linked in: ccm fuse rfcomm xt_CHECKSUM xt_MASQUERADE tun
bridge stp llc nf_conntrack_netbios_ns nf_conntrack_broadcast xt_CT
ip6t_rpfilter ip6t_REJECT nf_reject_ipv6 xt_conntrack ebtable_nat
ip6table_nat ip6table_mangle ip6table_raw ip6table_security
iptable_nat nf_nat iptable_mangle iptable_raw iptable_security
nf_conntrack nf_defrag_ipv6 libcrc32c nf_defrag_ipv4 ip_set nfnetlink
ebtable_filter ebtables ip6table_filter ip6_tables cmac bnep vfat fat
hid_multitouch iTCO_wdt iTCO_vendor_support snd_hda_codec_hdmi
snd_soc_skl snd_soc_hdac_hda snd_hda_ext_core snd_hda_codec_realtek
snd_soc_core snd_hda_codec_generic snd_soc_acpi_intel_match
snd_soc_acpi snd_soc_skl_ipc snd_soc_sst_ipc snd_soc_sst_dsp
dell_laptop snd_hda_intel ledtrig_audio dell_wmi dell_smbios
x86_pkg_temp_thermal snd_hda_codec ath10k_pci intel_powerclamp
wmi_bmof dell_wmi_descriptor intel_wmi_thunderbolt snd_hwdep coretemp
ath10k_core snd_hda_core kvm_intel snd_seq ath snd_seq_device kvm
btusb btrtl
intel_rapl_msr btbcm btintel mac80211 irqbypass snd_pcm bluetooth
intel_cstate dcdbas intel_uncore intel_rapl_perf joydev snd_timer snd
ecdh_generic i2c_i801 cfg80211 ecc idma64 soundcore rtsx_pci_ms
processor_thermal_device mei_me memstick rfkill libarc4 intel_lpss_pci
ucsi_acpi intel_soc_dts_iosf mei typec_ucsi intel_lpss
intel_pch_thermal intel_rapl_common typec wmi int3403_thermal
int340x_thermal_zone intel_hid sparse_keymap int3400_thermal acpi_pad
acpi_thermal_rel dm_crypt i915 crct10dif_pclmul crc32_pclmul
crc32c_intel rtsx_pci_sdmmc mmc_core i2c_algo_bit drm_kms_helper
syscopyarea sysfillrect sysimgblt nvme fb_sys_fops ghash_clmulni_intel
drm serio_raw nvme_core rtsx_pci i2c_hid pinctrl_cannonlake video
pinctrl_intel
CPU: 4 PID: 1246 Comm: NetworkManager Not tainted
5.3.0-rc8-00004-g56037cadf604-dirty #5
Hardware name: Dell Inc. XPS 13 9380/0KTW76, BIOS 1.5.0 06/03/2019
RIP: 0010:__sta_info_destroy_part2+0x147/0x150 [mac80211]
Code: bd 0c 01 00 00 00 0f 84 4e ff ff ff 45 31 c0 b9 01 00 00 00
48 89 ea 48 89 de 4c 89 e7 e8 e1 aa ff ff 85 c0 0f 84 30 ff ff ff <0f>
0b e9 29 ff ff ff 66 90 0f 1f 44 00 00 41 54 55 48 89 fd e8 40
RSP: 0018:ffff98fc00daba90 EFLAGS: 00010282
RAX: 00000000ffffff94 RBX: ffff8e1355ad2880 RCX: 0000000000000000
RDX: ffff8e1355901ec0 RSI: 0000000000000000 RDI: ffff8e1357902e38
RBP: ffff8e135bb08000 R08: 0000000000000000 R09: 0000000000000574
R10: 000000000001cc5c R11: 0000000000000000 R12: ffff8e13579007a0
R13: ffff8e1355ad2880 R14: 0000000000000001 R15: ffff8e1357900d58
FS: 00007fbd99372bc0(0000) GS:ffff8e135e500000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00001cdbd7408000 CR3: 00000004708a2001 CR4: 00000000003606e0
Call Trace:
__sta_info_flush+0x125/0x170 [mac80211]
ieee80211_set_disassoc+0xc2/0x590 [mac80211]
ieee80211_mgd_deauth.cold+0x4a/0x1b8 [mac80211]
cfg80211_mlme_deauth+0xb3/0x1d0 [cfg80211]
? startup_64+0x3/0x30
cfg80211_mlme_down+0x66/0x90 [cfg80211]
cfg80211_disconnect+0x129/0x1e0 [cfg80211]
cfg80211_leave+0x27/0x40 [cfg80211]
cfg80211_netdev_notifier_call+0x1a7/0x4e0 [cfg80211]
? ieee80211_iter_chan_contexts_atomic+0x3e/0x50 [mac80211]
? ath10k_monitor_recalc+0x38f/0x5d0 [ath10k_core]
? __schedule+0x143/0x660
? ath10k_config_ps+0x4e/0x70 [ath10k_core]
? inetdev_event+0x46/0x560
notifier_call_chain+0x4c/0x70
__dev_close_many+0x57/0x100
dev_close_many+0x8d/0x140
dev_close.part.0+0x44/0x70
cfg80211_shutdown_all_interfaces+0x71/0xd0 [cfg80211]
cfg80211_rfkill_set_block+0x22/0x30 [cfg80211]
rfkill_set_block+0x92/0x140 [rfkill]
rfkill_fop_write+0x11f/0x1c0 [rfkill]
vfs_write+0xb6/0x1a0
ksys_write+0xa7/0xe0
do_syscall_64+0x59/0x1c0
entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x7fbd9a36c92f
Code: 89 54 24 18 48 89 74 24 10 89 7c 24 08 e8 19 fd ff ff 48 8b
54 24 18 48 8b 74 24 10 41 89 c0 8b 7c 24 08 b8 01 00 00 00 0f 05 <48>
3d 00 f0 ff ff 77 2d 44 89 c7 48 89 44 24 08 e8 4c fd ff ff 48
RSP: 002b:00007fff9a1ee220 EFLAGS: 00000293 ORIG_RAX: 0000000000000001
RAX: ffffffffffffffda RBX: 000055f18ef5eaad RCX: 00007fbd9a36c92f
RDX: 0000000000000008 RSI: 00007fff9a1ee258 RDI: 0000000000000019
RBP: 0000000000000019 R08: 0000000000000000 R09: 0000000000000001
R10: 0000000000000000 R11: 0000000000000293 R12: 000055f190502090
R13: 0000000000000000 R14: 0000000000000000 R15: 000055f1904ffbb0
---[ end trace 4d7c87877e20badd ]---
ath10k_pci 0000:02:00.0: failed to recalculate rts/cts prot for vdev 0: -108
ath10k_pci 0000:02:00.0: failed to set cts protection for vdev 0: -108
and it looks like it leaves some lock held.
Because after this, nothing network-related stops working, and the
machine eventually dies because workqueues don't make any progress (due
to rtnl_lock, I suspect):
Workqueue: events_freezable ieee80211_restart_work [mac80211]
Call Trace:
schedule+0x39/0xa0
schedule_preempt_disabled+0xa/0x10
__mutex_lock.isra.0+0x263/0x4b0
ieee80211_restart_work+0x54/0xe0 [mac80211]
process_one_work+0x1cf/0x370
worker_thread+0x4a/0x3c0
kthread+0xfb/0x130
ret_from_fork+0x35/0x40
Workqueue: events disconnect_work [cfg80211]
Call Trace:
schedule+0x39/0xa0
schedule_preempt_disabled+0xa/0x10
__mutex_lock.isra.0+0x263/0x4b0
disconnect_work+0x12/0xd0 [cfg80211]
process_one_work+0x1cf/0x370
worker_thread+0x4a/0x3c0
kthread+0xfb/0x130
ret_from_fork+0x35/0x40
kworker/3:0 D 0 6313 2 0x80004000
Workqueue: events linkwatch_event
Call Trace:
schedule+0x39/0xa0
schedule_preempt_disabled+0xa/0x10
__mutex_lock.isra.0+0x263/0x4b0
linkwatch_event+0xa/0x30
process_one_work+0x1cf/0x370
worker_thread+0x4a/0x3c0
kthread+0xfb/0x130
ret_from_fork+0x35/0x40
ping D 0 6619 6568 0x80000002
Call Trace:
schedule+0x39/0xa0
schedule_preempt_disabled+0xa/0x10
__mutex_lock.isra.0+0x263/0x4b0
ip6mr_sk_done+0x2e/0xd0
rawv6_close+0x19/0x30
inet_release+0x34/0x60
__sock_release+0x3d/0xa0
sock_close+0x11/0x20
__fput+0xc1/0x250
task_work_run+0x81/0xa0
do_exit+0x2e5/0xaa0
do_group_exit+0x3a/0x90
__x64_sys_exit_group+0x14/0x20
do_syscall_64+0x59/0x1c0
entry_SYSCALL_64_after_hwframe+0x44/0xa9
gdbus D 0 6629 1949 0x80004000
Call Trace:
schedule+0x39/0xa0
do_exit+0x1da/0xaa0
do_group_exit+0x3a/0x90
get_signal+0x14f/0x830
do_signal+0x36/0x620
exit_to_usermode_loop+0x6f/0xf0
do_syscall_64+0x17d/0x1c0
entry_SYSCALL_64_after_hwframe+0x44/0xa9
^ permalink raw reply
* RE: [RFC PATCH 3/3] Enable ptp_kvm for arm64
From: Jianyong Wu (Arm Technology China) @ 2019-09-11 10:06 UTC (permalink / raw)
To: Marc Zyngier
Cc: netdev@vger.kernel.org, pbonzini@redhat.com,
sean.j.christopherson@intel.com, richardcochran@gmail.com,
Mark Rutland, Will Deacon, Suzuki Poulose,
linux-kernel@vger.kernel.org, Steve Capper,
Kaly Xin (Arm Technology China), Justin He (Arm Technology China)
In-Reply-To: <HE1PR0801MB16769814863B26F3B5DC708FF4B60@HE1PR0801MB1676.eurprd08.prod.outlook.com>
Hi Marc,
I think there are three points for the migration issue of ptp_kvm, where a VM using ptp_kvm migrates to a host without ptp_kvm support.
First: how does it impact the VM having migrated?
I run a VM with ptp_kvm support in guest but not support in host. the ptp0 will return 0 when get time from it which can't pass the check
of chrony, then chrony will choose another clocksource. From this point, VM will only get lost in precision of time sync.
Second: how to check the failure of the ptp kvm service
when there is no ptp kvm service, hypercall will go into default ops, so we can check the return value which can inform us the failure.
Third: how to inform VMM
There is ioctl cmd call "KVM_CHECK_EXTENSION" in kvm, which may do that thing. Accordingly, qemu should be offered the support which will block us.
We can try to add this support in kvm but we are not sure the response from qemu side.
WDYT?
Jianyong Wu
Thanks
> -----Original Message-----
> From: Jianyong Wu (Arm Technology China)
> Sent: Tuesday, September 10, 2019 6:29 PM
> To: Marc Zyngier <maz@kernel.org>
> Cc: netdev@vger.kernel.org; pbonzini@redhat.com;
> sean.j.christopherson@intel.com; richardcochran@gmail.com; Mark Rutland
> <Mark.Rutland@arm.com>; Will Deacon <Will.Deacon@arm.com>; Suzuki
> Poulose <Suzuki.Poulose@arm.com>; linux-kernel@vger.kernel.org; Steve
> Capper <Steve.Capper@arm.com>; Kaly Xin (Arm Technology China)
> <Kaly.Xin@arm.com>; Justin He (Arm Technology China)
> <Justin.He@arm.com>
> Subject: RE: [RFC PATCH 3/3] Enable ptp_kvm for arm64
>
> Hi Marc,
>
> > -----Original Message-----
> > From: Marc Zyngier <maz@kernel.org>
> > Sent: Monday, September 9, 2019 7:25 PM
> > To: Jianyong Wu (Arm Technology China) <Jianyong.Wu@arm.com>
> > Cc: netdev@vger.kernel.org; pbonzini@redhat.com;
> > sean.j.christopherson@intel.com; richardcochran@gmail.com; Mark
> > Rutland <Mark.Rutland@arm.com>; Will Deacon <Will.Deacon@arm.com>;
> > Suzuki Poulose <Suzuki.Poulose@arm.com>; linux-kernel@vger.kernel.org;
> > Steve Capper <Steve.Capper@arm.com>; Kaly Xin (Arm Technology China)
> > <Kaly.Xin@arm.com>; Justin He (Arm Technology China)
> > <Justin.He@arm.com>
> > Subject: Re: [RFC PATCH 3/3] Enable ptp_kvm for arm64
> >
> >
> > > > > > Other questions: how does this works with VM migration?
> > > > > > Specially when moving from a hypervisor that supports the
> > > > > > feature to one that
> > > > doesn't?
> > > > > >
> > > > > I think it won't solve the problem generated by VM migration and
> > > > > only for VMs in a single machine. Ptp_kvm only works for VMs in
> > > > > the same machine. But using ptp (not ptp_kvm) clock, all the
> > > > > machines in a low latency network environment can keep time sync
> > > > > in high precision, Then VMs move from one machine to another
> > > > > will obtain a high precision time sync.
> > > >
> > > > That's a problem. Migration must be possible from one host to
> > > > another, even if that means temporarily loosing some (or a lot of)
> > > > precision. The service must be discoverable from userspace on the
> > > > host so that the MVV can decie whether a migration is possible or not.
> > > >
> > > Don't worry, things will be not that bad. ptp_kvm will not trouble
> > > the VM migration. This ptp_kvm is one clocksource of the clock pool
> > > for chrony. Chrony will choose the highest precision clock from the
> > > pool. If host does not support ptp_kvm, the ptp_kvm will not be
> > > chosen as the clocksouce of chrony. We have roughly the same logic
> > > of implementation of ptp_kvm with x86, and ptp_kvm works well in
> > > x86. so I think that will be the case for arm64.
> > >
> > > Maybe I miss your point, I have no idea of MVV and can't get related
> > > info from google. Also I'm not clear of your last words of how to
> > > decide VM migration is possible?
> >
> > Sorry. s/MVV/VMM/. Basically userspace, such as QEMU.
> >
> > Here's an example: The guest runs on a PTP aware host, starts using
> > the PTP service and uses HVC calls to get its clock. We now migrate
> > the guest to a non PTP-aware host. The hypercalls are now going to
> > fail unexpectedly. Is that something that is acceptable? I don't think
> > it is. Once you've allowed a guest to use a service, this service
> > should be preserved. I'd be more confident if we gave to userspace the
> > indication that the hypervisor supports PTP. Userspace can then decide
> whether to perform migration or not.
> >
>
> It's really a point we should consider. let me check the behavior of chrony in
> this scenario first.
>
> Thanks
> Jianyong Wu
>
> > Thanks,
> >
> > M.
> >
> > --
> > Jazz is not dead, it just smells funny.
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
^ permalink raw reply
* Re: [PATCH 04/11] net: phylink: switch to using fwnode_gpiod_get_index()
From: Russell King - ARM Linux admin @ 2019-09-11 10:10 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Andy Shevchenko, Linus Walleij, Mika Westerberg, linux-kernel,
linux-gpio, Andrew Lunn, David S. Miller, Florian Fainelli,
Heiner Kallweit, netdev
In-Reply-To: <20190911095511.GB108334@dtor-ws>
On Wed, Sep 11, 2019 at 02:55:11AM -0700, Dmitry Torokhov wrote:
> On Wed, Sep 11, 2019 at 10:49:29AM +0100, Russell King - ARM Linux admin wrote:
> > On Wed, Sep 11, 2019 at 12:46:19PM +0300, Andy Shevchenko wrote:
> > > On Wed, Sep 11, 2019 at 10:39:14AM +0100, Russell King - ARM Linux admin wrote:
> > > > On Wed, Sep 11, 2019 at 12:25:14PM +0300, Andy Shevchenko wrote:
> > > > > On Wed, Sep 11, 2019 at 12:52:08AM -0700, Dmitry Torokhov wrote:
> > > > > > Instead of fwnode_get_named_gpiod() that I plan to hide away, let's use
> > > > > > the new fwnode_gpiod_get_index() that mimics gpiod_get_index(), bit
> > > > > > works with arbitrary firmware node.
> > e > >
> > > > > I'm wondering if it's possible to step forward and replace
> > > > > fwnode_get_gpiod_index by gpiod_get() / gpiod_get_index() here and
> > > > > in other cases in this series.
> > > >
> > > > No, those require a struct device, but we have none. There are network
> > > > drivers where there is a struct device for the network complex, but only
> > > > DT nodes for the individual network interfaces. So no, gpiod_* really
> > > > doesn't work.
> > >
> > > In the following patch the node is derived from struct device. So, I believe
> > > some cases can be handled differently.
> >
> > phylink is not passed a struct device - it has no knowledge what the
> > parent device is.
> >
> > In any case, I do not have "the following patch".
>
> Andy is talking about this one:
>
> diff --git a/drivers/net/phy/mdio_bus.c b/drivers/net/phy/mdio_bus.c
> index ce940871331e..9ca51d678123 100644
> --- a/drivers/net/phy/mdio_bus.c
> +++ b/drivers/net/phy/mdio_bus.c
> @@ -46,8 +46,8 @@ static int mdiobus_register_gpiod(struct mdio_device *mdiodev)
>
> /* Deassert the optional reset signal */
> if (mdiodev->dev.of_node)
> - gpiod = fwnode_get_named_gpiod(&mdiodev->dev.of_node->fwnode,
> - "reset-gpios", 0,
> GPIOD_OUT_LOW,
> + gpiod = fwnode_gpiod_get_index(&mdiodev->dev.of_node->fwnode,
> + "reset", 0, GPIOD_OUT_LOW,
> "PHY reset");
> Here if we do not care about "PHY reset" label, we could use
> gpiod_get(&mdiodev->dev, "reset", GPIOD_OUT_LOW).
Here, you have a struct device, so yes, it's possible.
Referring back to my comment, notice that I said we have none for the
phylink case, so it's not possible there.
I'm not sure why Andy replied the way he did, unless he mis-read my
comment.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
^ permalink raw reply
* Re: [PATCH V2 net-next 4/7] net: hns3: fix port setting handle for fibre port
From: Sergei Shtylyov @ 2019-09-11 10:16 UTC (permalink / raw)
To: Huazhong Tan, davem
Cc: netdev, linux-kernel, salil.mehta, yisen.zhuang, linuxarm,
jakub.kicinski
In-Reply-To: <1568169639-43658-5-git-send-email-tanhuazhong@huawei.com>
Hello!
On 11.09.2019 5:40, Huazhong Tan wrote:
> From: Guangbin Huang <huangguangbin2@huawei.com>
>
> For hardware doesn't support use specified speed and duplex
Can't pasre that. "For hardware that does not support using", perhaps?
> to negotiate, it's unnecessary to check and modify the port
> speed and duplex for fibre port when autoneg is on.
>
> Fixes: 22f48e24a23d ("net: hns3: add autoneg and change speed support for fibre port")
> Signed-off-by: Guangbin Huang <huangguangbin2@huawei.com>
> Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com>
> ---
> drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c | 15 +++++++++++++++
> 1 file changed, 15 insertions(+)
>
> diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c b/drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c
> index f5a681d..680c350 100644
> --- a/drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c
> +++ b/drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c
> @@ -726,6 +726,12 @@ static int hns3_check_ksettings_param(const struct net_device *netdev,
> u8 duplex;
> int ret;
>
> + /* hw doesn't support use specified speed and duplex to negotiate,
I can't parse that, did you mean "using"?
> + * unnecessary to check them when autoneg on.
> + */
> + if (cmd->base.autoneg)
> + return 0;
> +
> if (ops->get_ksettings_an_result) {
> ops->get_ksettings_an_result(handle, &autoneg, &speed, &duplex);
> if (cmd->base.autoneg == autoneg && cmd->base.speed == speed &&
> @@ -787,6 +793,15 @@ static int hns3_set_link_ksettings(struct net_device *netdev,
> return ret;
> }
>
> + /* hw doesn't support use specified speed and duplex to negotiate,
Here too...
> + * ignore them when autoneg on.
> + */
> + if (cmd->base.autoneg) {
> + netdev_info(netdev,
> + "autoneg is on, ignore the speed and duplex\n");
> + return 0;
> + }
> +
> if (ops->cfg_mac_speed_dup_h)
> ret = ops->cfg_mac_speed_dup_h(handle, cmd->base.speed,
> cmd->base.duplex);
MBR, Sergei
^ permalink raw reply
* Re: [PATCH V2 net-next 4/7] net: hns3: fix port setting handle for fibre port
From: Sergei Shtylyov @ 2019-09-11 10:17 UTC (permalink / raw)
To: Huazhong Tan, davem
Cc: netdev, linux-kernel, salil.mehta, yisen.zhuang, linuxarm,
jakub.kicinski
In-Reply-To: <1568169639-43658-5-git-send-email-tanhuazhong@huawei.com>
Hello!
On 11.09.2019 5:40, Huazhong Tan wrote:
> From: Guangbin Huang <huangguangbin2@huawei.com>
>
> For hardware doesn't support use specified speed and duplex
Can't parse that. "For hardware that does not support using", perhaps?
> to negotiate, it's unnecessary to check and modify the port
> speed and duplex for fibre port when autoneg is on.
>
> Fixes: 22f48e24a23d ("net: hns3: add autoneg and change speed support for fibre port")
> Signed-off-by: Guangbin Huang <huangguangbin2@huawei.com>
> Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com>
> ---
> drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c | 15 +++++++++++++++
> 1 file changed, 15 insertions(+)
>
> diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c b/drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c
> index f5a681d..680c350 100644
> --- a/drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c
> +++ b/drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c
> @@ -726,6 +726,12 @@ static int hns3_check_ksettings_param(const struct net_device *netdev,
> u8 duplex;
> int ret;
>
> + /* hw doesn't support use specified speed and duplex to negotiate,
I can't parse that, did you mean "using"?
> + * unnecessary to check them when autoneg on.
> + */
> + if (cmd->base.autoneg)
> + return 0;
> +
> if (ops->get_ksettings_an_result) {
> ops->get_ksettings_an_result(handle, &autoneg, &speed, &duplex);
> if (cmd->base.autoneg == autoneg && cmd->base.speed == speed &&
> @@ -787,6 +793,15 @@ static int hns3_set_link_ksettings(struct net_device *netdev,
> return ret;
> }
>
> + /* hw doesn't support use specified speed and duplex to negotiate,
Here too...
> + * ignore them when autoneg on.
> + */
> + if (cmd->base.autoneg) {
> + netdev_info(netdev,
> + "autoneg is on, ignore the speed and duplex\n");
> + return 0;
> + }
> +
> if (ops->cfg_mac_speed_dup_h)
> ret = ops->cfg_mac_speed_dup_h(handle, cmd->base.speed,
> cmd->base.duplex);
MBR, Sergei
^ permalink raw reply
* [PATCH iproute2-next] man: ss.8: add documentation for drop counter
From: Andrea Claudi @ 2019-09-11 10:19 UTC (permalink / raw)
To: netdev; +Cc: stephen, dsahern
After commit 6df9c7a06a845 ("ss: add SK_MEMINFO_DROPS display") ss -m
displays also a drop counter for each socket.
This commit properly document it into the man page.
Signed-off-by: Andrea Claudi <aclaudi@redhat.com>
---
man/man8/ss.8 | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/man/man8/ss.8 b/man/man8/ss.8
index f428e60cc1949..023d771b17878 100644
--- a/man/man8/ss.8
+++ b/man/man8/ss.8
@@ -99,13 +99,13 @@ skmem:(r<rmem_alloc>,rb<rcv_buf>,t<wmem_alloc>,tb<snd_buf>,
.br
.RS
.RS
-f<fwd_alloc>,w<wmem_queued>,
+f<fwd_alloc>,w<wmem_queued>,o<opt_mem>,
.RE
.RE
.br
.RS
.RS
-o<opt_mem>,bl<back_log>)
+bl<back_log>,d<sock_drop>)
.RE
.RE
.P
@@ -146,6 +146,10 @@ The memory used for the sk backlog queue. On a process context, if the
process is receiving packet, and a new packet is received, it will be
put into the sk backlog queue, so it can be received by the process
immediately
+.P
+.TP
+.B <sock_drop>
+the number of packets dropped before they are de-multiplexed into the socket
.RE
.TP
.B \-p, \-\-processes
--
2.21.0
^ permalink raw reply related
* Re: WARNING at net/mac80211/sta_info.c:1057 (__sta_info_destroy_part2())
From: Johannes Berg @ 2019-09-11 10:26 UTC (permalink / raw)
To: Linus Torvalds, David S. Miller, Kalle Valo
Cc: linux-wireless, Netdev, Linux List Kernel Mailing
In-Reply-To: <CAHk-=wgBuu8PiYpD7uWgxTSY8aUOJj6NJ=ivNQPYjAKO=cRinA@mail.gmail.com>
Hi,
> So I'm at LCA
When did LCA move to Portugal? ;-))
> , reading email, using my laptop more than I normally do,
> and with different networking than I normally do.
>
> And I just had a 802.11 WARN_ON() trigger, followed by essentially a
> dead machine due to some lock held (maybe rtnl_lock).
yes, it's definitely stuck on the RTNL, all the lot of the workqueues
are trying to acquire it (linkwatch, ipv6, but oddly enough even the
mac80211 restart work).
> It's possible that the lock held thing happened before, and is the
> _reason_ for the delay, I don't know.
No, we do have the lock in the WARN_ON(), somewhere around
dev_close_many() it is acquired.
> Previous resume looks normal:
> [snip]
> wlp2s0: Limiting TX power to 23 (23 - 0) dBm as advertised by
> 54:ec:2f:05:70:2c
Is that the message you meant?
> Another _almost_ successful suspend/resume:
> [snip
> wlp2s0: RX AssocResp from 54:ec:2f:05:70:2c (capab=0x1011 status=0 aid=2)
> wlp2s0: associated
> wlp2s0: Limiting TX power to 23 (23 - 0) dBm as advertised by
> 54:ec:2f:05:70:2c
> ath: EEPROM regdomain: 0x826c
> ath: EEPROM indicates we should expect a country code
> ath: doing EEPROM country->regdmn map search
> ath: country maps to regdmn code: 0x37
> ath: Country alpha2 being used: PT
> ath: Regpair used: 0x37
> ath: regdomain 0x826c dynamically updated by country element
> IPv6: ADDRCONF(NETDEV_CHANGE): wlp2s0: link becomes ready
>
> I say _almost_, because I don't see the "No TX power limit" for the
> country lookup (yes, Portugal) this time?
because here you had it too, just a bit earlier. It usually comes when a
beacon is received the first time, which depends on the AP timing.
> ath10k_pci 0000:02:00.0: wmi command 16387 timeout, restarting hardware
> ath10k_pci 0000:02:00.0: failed to set 5g txpower 23: -11
> ath10k_pci 0000:02:00.0: failed to setup tx power 23: -11
> ath10k_pci 0000:02:00.0: failed to recalc tx power: -11
> ath10k_pci 0000:02:00.0: failed to set inactivity time for vdev 0: -108
> ath10k_pci 0000:02:00.0: failed to setup powersave: -108
>
> That certainly looks like something did try to set a power limit, but
> eventually failed.
Yeah, that does seem a bit fishy. Kalle would have to comment for
ath10k.
> Immediately after that:
>
> wlp2s0: deauthenticating from 54:ec:2f:05:70:2c by local choice
> (Reason: 3=DEAUTH_LEAVING)
I don't _think_ any of the above would be a reason to disconnect, but it
clearly looks like the device got stuck at this point, since everything
just fails afterwards.
> ath10k_pci 0000:02:00.0: failed to delete peer 54:ec:2f:05:70:2c
> for vdev 0: -108
>
> and this then results in:
>
> WARNING: CPU: 4 PID: 1246 at net/mac80211/sta_info.c:1057
> __sta_info_destroy_part2+0x147/0x150 [mac80211]
Not really a surprise. Perhaps we shouldn't even WARN_ON() this, if the
driver is stuck completely and returning errors to everything that
doesn't help so much.
Then again, the stack trace was helpful this time:
> ieee80211_set_disassoc+0xc2/0x590 [mac80211]
> ieee80211_mgd_deauth.cold+0x4a/0x1b8 [mac80211]
> cfg80211_mlme_deauth+0xb3/0x1d0 [cfg80211]
> cfg80211_mlme_down+0x66/0x90 [cfg80211]
> cfg80211_disconnect+0x129/0x1e0 [cfg80211]
> cfg80211_leave+0x27/0x40 [cfg80211]
> cfg80211_netdev_notifier_call+0x1a7/0x4e0 [cfg80211]
> notifier_call_chain+0x4c/0x70
> __dev_close_many+0x57/0x100
> dev_close_many+0x8d/0x140
> dev_close.part.0+0x44/0x70
> cfg80211_shutdown_all_interfaces+0x71/0xd0 [cfg80211]
> cfg80211_rfkill_set_block+0x22/0x30 [cfg80211]
> rfkill_set_block+0x92/0x140 [rfkill]
> rfkill_fop_write+0x11f/0x1c0 [rfkill]
> vfs_write+0xb6/0x1a0
Since we see that something actually did an rfkill operation. Did you
push a button there?
Like I said above, the fact that we get into notifier_call_chain() from
rfkill_set_block() means that we acquired the RTNL here somewhere
between these.
> ath10k_pci 0000:02:00.0: failed to recalculate rts/cts prot for vdev 0: -108
> ath10k_pci 0000:02:00.0: failed to set cts protection for vdev 0: -108
>
> and it looks like it leaves some lock held.
Yeah, the RTNL.
You don't happen to have timing information on these logs, perhaps
recorded in the logfile/journal?
It seems odd to me, since the RTNL is acquired by
cfg80211_rfkill_set_block() and that doesn't even have an error path, it
just does
rtnl_lock();
cfg80211_shutdown_all_interfaces(&rdev->wiphy);
rtnl_unlock();
The only explanation I therefore have is that something is just taking
*forever* in that code path, hence my question about timing information
on the logs.
Looks like indeed the driver gives the device at least *3 seconds* for
every command, see ath10k_wmi_cmd_send(), so most likely this would
eventually have finished, but who knows how many firmware commands it
would still have attempted to send...
Perhaps the driver should mark the device as dead and fail quickly once
it timed out once, or so, but I'll let Kalle comment on that.
johannes
^ permalink raw reply
* [PATCH] NFC: st95hf: fix spelling mistake "receieve" -> "receive"
From: Colin King @ 2019-09-11 10:38 UTC (permalink / raw)
To: David S . Miller, Greg Kroah-Hartman, netdev
Cc: kernel-janitors, linux-kernel
From: Colin Ian King <colin.king@canonical.com>
There is a spelling mistake in a dev_err message. Fix it.
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
drivers/nfc/st95hf/core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/nfc/st95hf/core.c b/drivers/nfc/st95hf/core.c
index 6034c5bf49d9..ce38782ebf80 100644
--- a/drivers/nfc/st95hf/core.c
+++ b/drivers/nfc/st95hf/core.c
@@ -316,7 +316,7 @@ static int st95hf_echo_command(struct st95hf_context *st95context)
&echo_response);
if (result) {
dev_err(&st95context->spicontext.spidev->dev,
- "err: echo response receieve error = 0x%x\n", result);
+ "err: echo response receive error = 0x%x\n", result);
return result;
}
--
2.20.1
^ permalink raw reply related
* Re: [PATCH] bpf: validate bpf_func when BPF_JIT is enabled
From: Björn Töpel @ 2019-09-11 10:39 UTC (permalink / raw)
To: Yonghong Song, Sami Tolvanen
Cc: Alexei Starovoitov, Daniel Borkmann, Kees Cook, Martin Lau,
Song Liu, netdev@vger.kernel.org, bpf@vger.kernel.org,
linux-kernel@vger.kernel.org, Toke Høiland-Jørgensen,
Jesper Dangaard Brouer
In-Reply-To: <c7c7668e-6336-0367-42b3-2f6026c466dd@fb.com>
On 2019-09-11 09:42, Yonghong Song wrote:
> I am not an expert in XDP testing. Toke, Björn, could you give some
> suggestions what to test for XDP performance here?
I ran the "xdp_rxq_info" sample with and without Sami's patch:
$ sudo ./xdp_rxq_info --dev enp134s0f0 --action XDP_DROP
Before:
Running XDP on dev:enp134s0f0 (ifindex:6) action:XDP_DROP options:no_touch
XDP stats CPU pps issue-pps
XDP-RX CPU 20 23923874 0
XDP-RX CPU total 23923874
RXQ stats RXQ:CPU pps issue-pps
rx_queue_index 20:20 23923878 0
rx_queue_index 20:sum 23923878
After Sami's patch:
Running XDP on dev:enp134s0f0 (ifindex:6) action:XDP_DROP options:no_touch
XDP stats CPU pps issue-pps
XDP-RX CPU 20 22998700 0
XDP-RX CPU total 22998700
RXQ stats RXQ:CPU pps issue-pps
rx_queue_index 20:20 22998705 0
rx_queue_index 20:sum 22998705
So, roughly ~4% for this somewhat naive scenario.
As for XDP performance tests; I guess some of the XDP selftests could be
used as well!
Björn
^ permalink raw reply
* Re: [PATCH bpf-next 01/11] samples: bpf: makefile: fix HDR_PROBE "echo"
From: Sergei Shtylyov @ 2019-09-11 11:02 UTC (permalink / raw)
To: ast, daniel, yhs, davem, jakub.kicinski, hawk, john.fastabend,
linux-kernel, netdev, bpf, clang-built-linux
In-Reply-To: <20190910145359.GD3053@khorivan>
On 10.09.2019 17:54, Ivan Khoronzhuk wrote:
>> Hello!
>>
>> On 10.09.2019 13:38, Ivan Khoronzhuk wrote:
>>
>>> echo should be replaced on echo -e to handle \n correctly, but instead,
>>
>> s/on/with/?
> s/echo/printf/ instead of s/echo/echo -e/
I only pointed that 'on' is incorrect there. You replace something /with/
something other...
>
> printf looks better.
>
>>
>>> replace it on printf as some systems can't handle echo -e.
>>
>> Likewise?
Same grammatical mistake.
> I can guess its Mac vs Linux, but it does mean nothing if it's defined as
> implementation dependent, can be any.
>
>>> Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org>
>> [...]
MBR, Sergei
^ permalink raw reply
* [PATCH net-next 0/2] devlink: add unknown 'fw_load_policy' value
From: Simon Horman @ 2019-09-11 11:08 UTC (permalink / raw)
To: David Miller
Cc: Jakub Kicinski, netdev, oss-drivers, Dirk van der Merwe,
Simon Horman
Dirk says:
Recently we added an unknown value for the 'reset_dev_on_drv_probe' devlink
parameter. Extend the 'fw_load_policy' parameter in the same way.
The only driver that uses this right now is the nfp driver.
Dirk van der Merwe (2):
devlink: add unknown 'fw_load_policy' value
nfp: devlink: set unknown fw_load_policy
drivers/net/ethernet/netronome/nfp/devlink_param.c | 3 ++-
include/uapi/linux/devlink.h | 1 +
2 files changed, 3 insertions(+), 1 deletion(-)
--
2.11.0
^ permalink raw reply
* [PATCH net-next 1/2] devlink: add unknown 'fw_load_policy' value
From: Simon Horman @ 2019-09-11 11:08 UTC (permalink / raw)
To: David Miller
Cc: Jakub Kicinski, netdev, oss-drivers, Dirk van der Merwe,
Simon Horman
In-Reply-To: <20190911110833.9005-1-simon.horman@netronome.com>
From: Dirk van der Merwe <dirk.vandermerwe@netronome.com>
Similar to the 'reset_dev_on_drv_probe' devlink parameter, it is useful
to have an unknown value which can be used by drivers to report that the
hardware value isn't recognized or is otherwise invalid instead of
failing the operation.
This is especially useful for u8/enum parameters.
Suggested-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Signed-off-by: Dirk van der Merwe <dirk.vandermerwe@netronome.com>
Signed-off-by: Simon Horman <simon.horman@netronome.com>
---
include/uapi/linux/devlink.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/uapi/linux/devlink.h b/include/uapi/linux/devlink.h
index 1da3e83f1fd4..8da5365850cd 100644
--- a/include/uapi/linux/devlink.h
+++ b/include/uapi/linux/devlink.h
@@ -203,6 +203,7 @@ enum devlink_param_fw_load_policy_value {
DEVLINK_PARAM_FW_LOAD_POLICY_VALUE_DRIVER,
DEVLINK_PARAM_FW_LOAD_POLICY_VALUE_FLASH,
DEVLINK_PARAM_FW_LOAD_POLICY_VALUE_DISK,
+ DEVLINK_PARAM_FW_LOAD_POLICY_VALUE_UNKNOWN,
};
enum devlink_param_reset_dev_on_drv_probe_value {
--
2.11.0
^ permalink raw reply related
* [PATCH net-next 2/2] nfp: devlink: set unknown fw_load_policy
From: Simon Horman @ 2019-09-11 11:08 UTC (permalink / raw)
To: David Miller
Cc: Jakub Kicinski, netdev, oss-drivers, Dirk van der Merwe,
Simon Horman
In-Reply-To: <20190911110833.9005-1-simon.horman@netronome.com>
From: Dirk van der Merwe <dirk.vandermerwe@netronome.com>
If the 'app_fw_from_flash' HWinfo key is invalid, set the
'fw_load_policy' devlink parameter value to unknown.
Suggested-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Signed-off-by: Dirk van der Merwe <dirk.vandermerwe@netronome.com>
Signed-off-by: Simon Horman <simon.horman@netronome.com>
---
drivers/net/ethernet/netronome/nfp/devlink_param.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/netronome/nfp/devlink_param.c b/drivers/net/ethernet/netronome/nfp/devlink_param.c
index 4a8141b4d625..36491835ac65 100644
--- a/drivers/net/ethernet/netronome/nfp/devlink_param.c
+++ b/drivers/net/ethernet/netronome/nfp/devlink_param.c
@@ -32,7 +32,8 @@ static const struct nfp_devlink_param_u8_arg nfp_devlink_u8_args[] = {
[DEVLINK_PARAM_GENERIC_ID_FW_LOAD_POLICY] = {
.hwinfo_name = "app_fw_from_flash",
.default_hi_val = NFP_NSP_APP_FW_LOAD_DEFAULT,
- .invalid_dl_val = -EINVAL,
+ .invalid_dl_val =
+ DEVLINK_PARAM_FW_LOAD_POLICY_VALUE_UNKNOWN,
.hi_to_dl = {
[NFP_NSP_APP_FW_LOAD_DISK] =
DEVLINK_PARAM_FW_LOAD_POLICY_VALUE_DISK,
--
2.11.0
^ permalink raw reply related
* Re: VRF Issue Since kernel 5
From: Gowen @ 2019-09-11 11:19 UTC (permalink / raw)
To: David Ahern, Alexis Bauvin; +Cc: netdev@vger.kernel.org
In-Reply-To: <CWLP265MB1554C88316ACF2BDD4692ECAFDB10@CWLP265MB1554.GBRP265.PROD.OUTLOOK.COM>
Hi there,
Your perf command:
isc-worker0000 20261 [000] 2215.013849: fib:fib_table_lookup: table 10 oif 0 iif 0 proto 0 0.0.0.0/0 -> 127.0.0.1/0 tos 0 scope 0 flags 0 ==> dev eth0 gw 10.24.12.1 src 10.24.12.10 err 0
isc-worker0000 20261 [000] 2215.013915: fib:fib_table_lookup: table 10 oif 4 iif 1 proto 17 0.0.0.0/52138 -> 127.0.0.53/53 tos 0 scope 0 flags 4 ==> dev eth0 gw 10.24.12.1 src 10.24.12.10 err 0
isc-worker0000 20261 [000] 2220.014006: fib:fib_table_lookup: table 10 oif 4 iif 1 proto 17 0.0.0.0/52138 -> 127.0.0.53/53 tos 0 scope 0 flags 4 ==> dev eth0 gw 10.24.12.1 src 10.24.12.10 err 0
Also I set all iptables to policy ACCEPT and flushed the rules, enabled forwarding, checked the sysctl settings are all '1'. I've looked at tracing DNS through the iptables and I see that DNS uses a loopback interface as source and destination - this would be odd on a Cisco box but having looked around this appears to be normal?
I also gathered an strace of updating the package cache as well as a perf of the same command - will send if interested (is more verbose and not sure if the spam filter will block it)
Gareth
From: Gowen
Sent: 11 September 2019 06:09
To: David Ahern <dsahern@gmail.com>; Alexis Bauvin <abauvin@online.net>
Cc: netdev@vger.kernel.org <netdev@vger.kernel.org>
Subject: RE: VRF Issue Since kernel 5
Thanks for the link - that's really useful. I did re-order ip rules Friday (I think) - no change
-----Original Message-----
From: David Ahern <dsahern@gmail.com>
Sent: 10 September 2019 17:36
To: Alexis Bauvin <abauvin@online.net>; Gowen <gowen@potatocomputing.co.uk>
Cc: netdev@vger.kernel.org
Subject: Re: VRF Issue Since kernel 5
On 9/9/19 1:01 PM, Alexis Bauvin wrote:
> Could you try swapping the local and l3mdev rules?
>
> `ip rule del pref 0; ip rule add from all lookup local pref 1001`
yes, the rules should be re-ordered so that local rule is after l3mdev rule (VRF is implemented as policy routing). In general, I would reverse the order of those commands to ensure no breakage.
Also, 5.0 I think it was (too many kernel versions) added a new l3mdev sysctl (raw_l3mdev_accept). Check all 3 of them and nmake sure they are set properly for your use case.
These slides do not cover 5.0 changes but are still the best collection of notes on VRF:
http://schd.ws/hosted_files/ossna2017/fe/vrf-tutorial-oss.pdf
^ permalink raw reply
* Re: [PATCH 0/7] net: dsa: mv88e6xxx: features to handle network storms
From: Ido Schimmel @ 2019-09-11 11:21 UTC (permalink / raw)
To: Florian Fainelli
Cc: Robert Beckett, netdev@vger.kernel.org, Andrew Lunn,
Vivien Didelot, David S. Miller, Jiri Pirko
In-Reply-To: <545d6473-848f-3194-02a6-011b7c89a2ca@gmail.com>
On Tue, Sep 10, 2019 at 09:49:46AM -0700, Florian Fainelli wrote:
> +Ido, Jiri,
>
> On 9/10/19 8:41 AM, Robert Beckett wrote:
> > This patch-set adds support for some features of the Marvell switch
> > chips that can be used to handle packet storms.
> >
> > The rationale for this was a setup that requires the ability to receive
> > traffic from one port, while a packet storm is occuring on another port
> > (via an external switch with a deliberate loop). This is needed to
> > ensure vital data delivery from a specific port, while mitigating any
> > loops or DoS that a user may introduce on another port (can't guarantee
> > sensible users).
>
> The use case is reasonable, but the implementation is not really. You
> are using Device Tree which is meant to describe hardware as a policy
> holder for setting up queue priorities and likewise for queue scheduling.
>
> The tool that should be used for that purpose is tc and possibly an
> appropriately offloaded queue scheduler in order to map the desired
> scheduling class to what the hardware supports.
>
> Jiri, Ido, how do you guys support this with mlxsw?
Hi Florian,
Are you referring to policing traffic towards the CPU using a policer on
the egress of the CPU port? At least that's what I understand from the
description of patch 6 below.
If so, mlxsw sets policers for different traffic types during its
initialization sequence. These policers are not exposed to the user nor
configurable. While the default settings are good for most users, we do
want to allow users to change these and expose current settings.
I agree that tc seems like the right choice, but the question is where
are we going to install the filters?
>
> >
> > [patch 1/7] configures auto negotiation for CPU ports connected with
> > phys to enable pause frame propogation.
> >
> > [patch 2/7] allows setting of port's default output queue priority for
> > any ingressing packets on that port.
> >
> > [patch 3/7] dt-bindings for patch 2.
> >
> > [patch 4/7] allows setting of a port's queue scheduling so that it can
> > prioritise egress of traffic routed from high priority ports.
> >
> > [patch 5/7] dt-bindings for patch 4.
> >
> > [patch 6/7] allows ports to rate limit their egress. This can be used to
> > stop the host CPU from becoming swamped by packet delivery and exhasting
> > descriptors.
> >
> > [patch 7/7] dt-bindings for patch 6.
> >
> >
> > Robert Beckett (7):
> > net/dsa: configure autoneg for CPU port
> > net: dsa: mv88e6xxx: add ability to set default queue priorities per
> > port
> > dt-bindings: mv88e6xxx: add ability to set default queue priorities
> > per port
> > net: dsa: mv88e6xxx: add ability to set queue scheduling
> > dt-bindings: mv88e6xxx: add ability to set queue scheduling
> > net: dsa: mv88e6xxx: add egress rate limiting
> > dt-bindings: mv88e6xxx: add egress rate limiting
> >
> > .../devicetree/bindings/net/dsa/marvell.txt | 38 +++++
> > drivers/net/dsa/mv88e6xxx/chip.c | 122 ++++++++++++---
> > drivers/net/dsa/mv88e6xxx/chip.h | 5 +-
> > drivers/net/dsa/mv88e6xxx/port.c | 140 +++++++++++++++++-
> > drivers/net/dsa/mv88e6xxx/port.h | 24 ++-
> > include/dt-bindings/net/dsa-mv88e6xxx.h | 22 +++
> > net/dsa/port.c | 10 ++
> > 7 files changed, 327 insertions(+), 34 deletions(-)
> > create mode 100644 include/dt-bindings/net/dsa-mv88e6xxx.h
> >
>
>
> --
> Florian
^ permalink raw reply
* Re: [RFC PATCH 3/3] Enable ptp_kvm for arm64
From: Marc Zyngier @ 2019-09-11 11:30 UTC (permalink / raw)
To: Jianyong Wu (Arm Technology China)
Cc: netdev@vger.kernel.org, pbonzini@redhat.com,
sean.j.christopherson@intel.com, richardcochran@gmail.com,
Mark Rutland, Will Deacon, Suzuki Poulose,
linux-kernel@vger.kernel.org, Steve Capper,
Kaly Xin (Arm Technology China), Justin He (Arm Technology China)
In-Reply-To: <HE1PR0801MB1676847C0A84473797BF4346F4B10@HE1PR0801MB1676.eurprd08.prod.outlook.com>
On Wed, 11 Sep 2019 11:06:18 +0100,
"Jianyong Wu (Arm Technology China)" <Jianyong.Wu@arm.com> wrote:
>
> Hi Marc,
>
> I think there are three points for the migration issue of ptp_kvm,
> where a VM using ptp_kvm migrates to a host without ptp_kvm support.
>
> First: how does it impact the VM having migrated?
> I run a VM with ptp_kvm support in guest but not support in
> host. the ptp0 will return 0 when get time from it which can't pass
> the check of chrony, then chrony will choose another clocksource.
> From this point, VM will only get lost in precision of time sync.
"only" is a bit of an understatement. Once the guest has started
relying on a service, it seems rather harsh to pretend this service
doesn't exist anymore. It could well be that the VM cannot perform its
function if the precision is not good enough.
The analogy is the Spectre-v2 mitigation, which is implemented as a
hypercall. Nothing will break if you migrate to a host that doesn't
support the mitigation, but the guest will now be unsafe. Is that
acceptable? the answer is of course "no".
> Second: how to check the failure of the ptp kvm service
> when there is no ptp kvm service, hypercall will go into default
> ops, so we can check the return value which can inform us the
> failure.
Sure. But that's still an issue. The VM relied on the service, and the
service isn't available anymore.
> Third: how to inform VMM
> There is ioctl cmd call "KVM_CHECK_EXTENSION" in kvm, which may do
> that thing. Accordingly, qemu should be offered the support which
> will block us. We can try to add this support in kvm but we are not
> sure the response from qemu side.
It doesn't matter whether QEMU implements that check or . The
important thing is that we give userspace a way to check this for
this, and having a capability that can be checked against is probably
the right thing to do.
Thanks,
M.
--
Jazz is not dead, it just smells funny.
^ permalink raw reply
* [PATCH] net: lmc: fix spelling mistake "runnin" -> "running"
From: Colin King @ 2019-09-11 11:37 UTC (permalink / raw)
To: David S . Miller, netdev; +Cc: kernel-janitors, linux-kernel
From: Colin Ian King <colin.king@canonical.com>
There is a spelling mistake in the lmc_trace message. Fix it.
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
drivers/net/wan/lmc/lmc_main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wan/lmc/lmc_main.c b/drivers/net/wan/lmc/lmc_main.c
index d74349628db2..0e6a51525d91 100644
--- a/drivers/net/wan/lmc/lmc_main.c
+++ b/drivers/net/wan/lmc/lmc_main.c
@@ -1115,7 +1115,7 @@ static void lmc_running_reset (struct net_device *dev) /*fold00*/
sc->lmc_cmdmode |= (TULIP_CMD_TXRUN | TULIP_CMD_RXRUN);
LMC_CSR_WRITE (sc, csr_command, sc->lmc_cmdmode);
- lmc_trace(dev, "lmc_runnin_reset_out");
+ lmc_trace(dev, "lmc_running_reset_out");
}
--
2.20.1
^ permalink raw reply related
* [vhost:linux-next 8/9] drivers/vhost/vhost.c:2076:5: note: in expansion of macro 'array_index_nospec'
From: kbuild test robot @ 2019-09-11 11:38 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: kbuild-all, kvm, virtualization, netdev
[-- Attachment #1: Type: text/plain, Size: 8189 bytes --]
tree: https://kernel.googlesource.com/pub/scm/linux/kernel/git/mst/vhost.git linux-next
head: f2c4b499aecc0c5a1ec67f3a2a7310cb7168a8ab
commit: 4c145987a955269da79312a79ec26638712644bb [8/9] vhost: block speculation of translated descriptors
config: mips-malta_kvm_defconfig (attached as .config)
compiler: mipsel-linux-gcc (GCC) 7.4.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 4c145987a955269da79312a79ec26638712644bb
# save the attached .config to linux build tree
GCC_VERSION=7.4.0 make.cross ARCH=mips
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot <lkp@intel.com>
All error/warnings (new ones prefixed by >>):
In file included from include/linux/kernel.h:11:0,
from include/linux/list.h:9,
from include/linux/wait.h:7,
from include/linux/eventfd.h:13,
from drivers/vhost/vhost.c:13:
drivers/vhost/vhost.c: In function 'translate_desc':
>> include/linux/compiler.h:350:38: error: call to '__compiletime_assert_2077' declared with attribute error: BUILD_BUG_ON failed: sizeof(_s) > sizeof(long)
_compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)
^
include/linux/compiler.h:331:4: note: in definition of macro '__compiletime_assert'
prefix ## suffix(); \
^~~~~~
include/linux/compiler.h:350:2: note: in expansion of macro '_compiletime_assert'
_compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)
^~~~~~~~~~~~~~~~~~~
include/linux/build_bug.h:39:37: note: in expansion of macro 'compiletime_assert'
#define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
^~~~~~~~~~~~~~~~~~
include/linux/build_bug.h:50:2: note: in expansion of macro 'BUILD_BUG_ON_MSG'
BUILD_BUG_ON_MSG(condition, "BUILD_BUG_ON failed: " #condition)
^~~~~~~~~~~~~~~~
>> include/linux/nospec.h:55:2: note: in expansion of macro 'BUILD_BUG_ON'
BUILD_BUG_ON(sizeof(_i) > sizeof(long)); \
^~~~~~~~~~~~
>> drivers/vhost/vhost.c:2076:5: note: in expansion of macro 'array_index_nospec'
array_index_nospec(addr - node->start,
^~~~~~~~~~~~~~~~~~
>> include/linux/compiler.h:350:38: error: call to '__compiletime_assert_2077' declared with attribute error: BUILD_BUG_ON failed: sizeof(_s) > sizeof(long)
_compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)
^
include/linux/compiler.h:331:4: note: in definition of macro '__compiletime_assert'
prefix ## suffix(); \
^~~~~~
include/linux/compiler.h:350:2: note: in expansion of macro '_compiletime_assert'
_compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)
^~~~~~~~~~~~~~~~~~~
include/linux/build_bug.h:39:37: note: in expansion of macro 'compiletime_assert'
#define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
^~~~~~~~~~~~~~~~~~
include/linux/build_bug.h:50:2: note: in expansion of macro 'BUILD_BUG_ON_MSG'
BUILD_BUG_ON_MSG(condition, "BUILD_BUG_ON failed: " #condition)
^~~~~~~~~~~~~~~~
include/linux/nospec.h:56:2: note: in expansion of macro 'BUILD_BUG_ON'
BUILD_BUG_ON(sizeof(_s) > sizeof(long)); \
^~~~~~~~~~~~
>> drivers/vhost/vhost.c:2076:5: note: in expansion of macro 'array_index_nospec'
array_index_nospec(addr - node->start,
^~~~~~~~~~~~~~~~~~
--
In file included from include/linux/kernel.h:11:0,
from include/linux/list.h:9,
from include/linux/wait.h:7,
from include/linux/eventfd.h:13,
from drivers//vhost/vhost.c:13:
drivers//vhost/vhost.c: In function 'translate_desc':
>> include/linux/compiler.h:350:38: error: call to '__compiletime_assert_2077' declared with attribute error: BUILD_BUG_ON failed: sizeof(_s) > sizeof(long)
_compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)
^
include/linux/compiler.h:331:4: note: in definition of macro '__compiletime_assert'
prefix ## suffix(); \
^~~~~~
include/linux/compiler.h:350:2: note: in expansion of macro '_compiletime_assert'
_compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)
^~~~~~~~~~~~~~~~~~~
include/linux/build_bug.h:39:37: note: in expansion of macro 'compiletime_assert'
#define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
^~~~~~~~~~~~~~~~~~
include/linux/build_bug.h:50:2: note: in expansion of macro 'BUILD_BUG_ON_MSG'
BUILD_BUG_ON_MSG(condition, "BUILD_BUG_ON failed: " #condition)
^~~~~~~~~~~~~~~~
>> include/linux/nospec.h:55:2: note: in expansion of macro 'BUILD_BUG_ON'
BUILD_BUG_ON(sizeof(_i) > sizeof(long)); \
^~~~~~~~~~~~
drivers//vhost/vhost.c:2076:5: note: in expansion of macro 'array_index_nospec'
array_index_nospec(addr - node->start,
^~~~~~~~~~~~~~~~~~
>> include/linux/compiler.h:350:38: error: call to '__compiletime_assert_2077' declared with attribute error: BUILD_BUG_ON failed: sizeof(_s) > sizeof(long)
_compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)
^
include/linux/compiler.h:331:4: note: in definition of macro '__compiletime_assert'
prefix ## suffix(); \
^~~~~~
include/linux/compiler.h:350:2: note: in expansion of macro '_compiletime_assert'
_compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)
^~~~~~~~~~~~~~~~~~~
include/linux/build_bug.h:39:37: note: in expansion of macro 'compiletime_assert'
#define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
^~~~~~~~~~~~~~~~~~
include/linux/build_bug.h:50:2: note: in expansion of macro 'BUILD_BUG_ON_MSG'
BUILD_BUG_ON_MSG(condition, "BUILD_BUG_ON failed: " #condition)
^~~~~~~~~~~~~~~~
include/linux/nospec.h:56:2: note: in expansion of macro 'BUILD_BUG_ON'
BUILD_BUG_ON(sizeof(_s) > sizeof(long)); \
^~~~~~~~~~~~
drivers//vhost/vhost.c:2076:5: note: in expansion of macro 'array_index_nospec'
array_index_nospec(addr - node->start,
^~~~~~~~~~~~~~~~~~
vim +/array_index_nospec +2076 drivers/vhost/vhost.c
2039
2040 static int translate_desc(struct vhost_virtqueue *vq, u64 addr, u32 len,
2041 struct iovec iov[], int iov_size, int access)
2042 {
2043 const struct vhost_umem_node *node;
2044 struct vhost_dev *dev = vq->dev;
2045 struct vhost_umem *umem = dev->iotlb ? dev->iotlb : dev->umem;
2046 struct iovec *_iov;
2047 u64 s = 0;
2048 int ret = 0;
2049
2050 while ((u64)len > s) {
2051 u64 size;
2052 if (unlikely(ret >= iov_size)) {
2053 ret = -ENOBUFS;
2054 break;
2055 }
2056
2057 node = vhost_umem_interval_tree_iter_first(&umem->umem_tree,
2058 addr, addr + len - 1);
2059 if (node == NULL || node->start > addr) {
2060 if (umem != dev->iotlb) {
2061 ret = -EFAULT;
2062 break;
2063 }
2064 ret = -EAGAIN;
2065 break;
2066 } else if (!(node->perm & access)) {
2067 ret = -EPERM;
2068 break;
2069 }
2070
2071 _iov = iov + ret;
2072 size = node->size - addr + node->start;
2073 _iov->iov_len = min((u64)len - s, size);
2074 _iov->iov_base = (void __user *)(unsigned long)
2075 (node->userspace_addr +
> 2076 array_index_nospec(addr - node->start,
2077 node->size));
2078 s += size;
2079 addr += size;
2080 ++ret;
2081 }
2082
2083 if (ret == -EAGAIN)
2084 vhost_iotlb_miss(vq, addr, access);
2085 return ret;
2086 }
2087
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 20549 bytes --]
^ permalink raw reply
* [vhost:linux-next 16/17] include/linux/page_reporting.h:9:34: note: in expansion of macro 'pageblock_order'
From: kbuild test robot @ 2019-09-11 11:38 UTC (permalink / raw)
To: Alexander Duyck
Cc: kbuild-all, kvm, virtualization, netdev, Michael S. Tsirkin
[-- Attachment #1: Type: text/plain, Size: 23931 bytes --]
tree: https://kernel.googlesource.com/pub/scm/linux/kernel/git/mst/vhost.git linux-next
head: 39c226b6b576b23d6d558331e6895f02b0892555
commit: 990055c63121520ad29deca72b1167b392563ddd [16/17] virtio-balloon: Add support for providing unused page reports to host
config: riscv-allmodconfig (attached as .config)
compiler: riscv64-linux-gcc (GCC) 7.4.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 990055c63121520ad29deca72b1167b392563ddd
# save the attached .config to linux build tree
GCC_VERSION=7.4.0 make.cross ARCH=riscv
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot <lkp@intel.com>
All warnings (new ones prefixed by >>):
In file included from arch/riscv/include/asm/thread_info.h:11:0,
from include/linux/thread_info.h:38,
from include/asm-generic/preempt.h:5,
from ./arch/riscv/include/generated/asm/preempt.h:1,
from include/linux/preempt.h:78,
from include/linux/radix-tree.h:14,
from include/linux/idr.h:15,
from include/linux/kernfs.h:13,
from include/linux/sysfs.h:16,
from include/linux/kobject.h:20,
from include/linux/device.h:16,
from drivers/scsi/snic/snic_attrs.c:19:
include/linux/page_reporting.h: In function '__del_page_from_reported_list':
arch/riscv/include/asm/page.h:24:22: error: 'PMD_SHIFT' undeclared (first use in this function); did you mean 'NMI_SHIFT'?
#define HPAGE_SHIFT PMD_SHIFT
^
arch/riscv/include/asm/page.h:27:34: note: in expansion of macro 'HPAGE_SHIFT'
#define HUGETLB_PAGE_ORDER (HPAGE_SHIFT - PAGE_SHIFT)
^~~~~~~~~~~
include/linux/pageblock-flags.h:41:26: note: in expansion of macro 'HUGETLB_PAGE_ORDER'
#define pageblock_order HUGETLB_PAGE_ORDER
^~~~~~~~~~~~~~~~~~
>> include/linux/page_reporting.h:9:34: note: in expansion of macro 'pageblock_order'
#define PAGE_REPORTING_MIN_ORDER pageblock_order
^~~~~~~~~~~~~~~
include/linux/page_reporting.h:61:44: note: in expansion of macro 'PAGE_REPORTING_MIN_ORDER'
zone->reported_pages[page_private(page) - PAGE_REPORTING_MIN_ORDER]--;
^~~~~~~~~~~~~~~~~~~~~~~~
arch/riscv/include/asm/page.h:24:22: note: each undeclared identifier is reported only once for each function it appears in
#define HPAGE_SHIFT PMD_SHIFT
^
arch/riscv/include/asm/page.h:27:34: note: in expansion of macro 'HPAGE_SHIFT'
#define HUGETLB_PAGE_ORDER (HPAGE_SHIFT - PAGE_SHIFT)
^~~~~~~~~~~
include/linux/pageblock-flags.h:41:26: note: in expansion of macro 'HUGETLB_PAGE_ORDER'
#define pageblock_order HUGETLB_PAGE_ORDER
^~~~~~~~~~~~~~~~~~
>> include/linux/page_reporting.h:9:34: note: in expansion of macro 'pageblock_order'
#define PAGE_REPORTING_MIN_ORDER pageblock_order
^~~~~~~~~~~~~~~
include/linux/page_reporting.h:61:44: note: in expansion of macro 'PAGE_REPORTING_MIN_ORDER'
zone->reported_pages[page_private(page) - PAGE_REPORTING_MIN_ORDER]--;
^~~~~~~~~~~~~~~~~~~~~~~~
include/linux/page_reporting.h: In function 'get_unreported_tail':
arch/riscv/include/asm/page.h:24:22: error: 'PMD_SHIFT' undeclared (first use in this function); did you mean 'NMI_SHIFT'?
#define HPAGE_SHIFT PMD_SHIFT
^
arch/riscv/include/asm/page.h:27:34: note: in expansion of macro 'HPAGE_SHIFT'
#define HUGETLB_PAGE_ORDER (HPAGE_SHIFT - PAGE_SHIFT)
^~~~~~~~~~~
include/linux/pageblock-flags.h:41:26: note: in expansion of macro 'HUGETLB_PAGE_ORDER'
#define pageblock_order HUGETLB_PAGE_ORDER
^~~~~~~~~~~~~~~~~~
>> include/linux/page_reporting.h:9:34: note: in expansion of macro 'pageblock_order'
#define PAGE_REPORTING_MIN_ORDER pageblock_order
^~~~~~~~~~~~~~~
include/linux/page_reporting.h:77:15: note: in expansion of macro 'PAGE_REPORTING_MIN_ORDER'
if (order >= PAGE_REPORTING_MIN_ORDER &&
^~~~~~~~~~~~~~~~~~~~~~~~
include/linux/page_reporting.h: In function 'add_page_to_reported_list':
arch/riscv/include/asm/page.h:24:22: error: 'PMD_SHIFT' undeclared (first use in this function); did you mean 'NMI_SHIFT'?
#define HPAGE_SHIFT PMD_SHIFT
^
arch/riscv/include/asm/page.h:27:34: note: in expansion of macro 'HPAGE_SHIFT'
#define HUGETLB_PAGE_ORDER (HPAGE_SHIFT - PAGE_SHIFT)
^~~~~~~~~~~
include/linux/pageblock-flags.h:41:26: note: in expansion of macro 'HUGETLB_PAGE_ORDER'
#define pageblock_order HUGETLB_PAGE_ORDER
^~~~~~~~~~~~~~~~~~
>> include/linux/page_reporting.h:9:34: note: in expansion of macro 'pageblock_order'
#define PAGE_REPORTING_MIN_ORDER pageblock_order
^~~~~~~~~~~~~~~
include/linux/page_reporting.h:99:31: note: in expansion of macro 'PAGE_REPORTING_MIN_ORDER'
zone->reported_pages[order - PAGE_REPORTING_MIN_ORDER]++;
^~~~~~~~~~~~~~~~~~~~~~~~
include/linux/page_reporting.h: In function 'page_reporting_notify_free':
arch/riscv/include/asm/page.h:24:22: error: 'PMD_SHIFT' undeclared (first use in this function); did you mean 'NMI_SHIFT'?
#define HPAGE_SHIFT PMD_SHIFT
^
arch/riscv/include/asm/page.h:27:34: note: in expansion of macro 'HPAGE_SHIFT'
#define HUGETLB_PAGE_ORDER (HPAGE_SHIFT - PAGE_SHIFT)
^~~~~~~~~~~
include/linux/pageblock-flags.h:41:26: note: in expansion of macro 'HUGETLB_PAGE_ORDER'
#define pageblock_order HUGETLB_PAGE_ORDER
^~~~~~~~~~~~~~~~~~
>> include/linux/page_reporting.h:9:34: note: in expansion of macro 'pageblock_order'
#define PAGE_REPORTING_MIN_ORDER pageblock_order
^~~~~~~~~~~~~~~
include/linux/page_reporting.h:159:14: note: in expansion of macro 'PAGE_REPORTING_MIN_ORDER'
if (order < PAGE_REPORTING_MIN_ORDER)
^~~~~~~~~~~~~~~~~~~~~~~~
--
In file included from include/linux/page_reporting.h:5:0,
from <command-line>:0:
include/linux/mmzone.h: In function 'add_to_free_list_tail':
include/linux/mmzone.h:791:27: error: implicit declaration of function 'get_unreported_tail' [-Werror=implicit-function-declaration]
struct list_head *tail = get_unreported_tail(zone, order, migratetype);
^~~~~~~~~~~~~~~~~~~
include/linux/mmzone.h:791:27: warning: initialization makes pointer from integer without a cast [-Wint-conversion]
include/linux/mmzone.h: In function 'move_to_free_list':
include/linux/mmzone.h:807:27: warning: initialization makes pointer from integer without a cast [-Wint-conversion]
struct list_head *tail = get_unreported_tail(zone, order, migratetype);
^~~~~~~~~~~~~~~~~~~
include/linux/mmzone.h:815:3: error: implicit declaration of function 'move_page_to_reported_list'; did you mean 'move_to_free_list'? [-Werror=implicit-function-declaration]
move_page_to_reported_list(page, zone, migratetype);
^~~~~~~~~~~~~~~~~~~~~~~~~~
move_to_free_list
include/linux/mmzone.h: In function 'del_page_from_free_list':
include/linux/mmzone.h:831:3: error: implicit declaration of function 'del_page_from_reported_list'; did you mean 'del_page_from_free_list'? [-Werror=implicit-function-declaration]
del_page_from_reported_list(page, zone);
^~~~~~~~~~~~~~~~~~~~~~~~~~~
del_page_from_free_list
In file included from arch/riscv/include/asm/thread_info.h:11:0,
from include/linux/thread_info.h:38,
from include/asm-generic/preempt.h:5,
from ./arch/riscv/include/generated/asm/preempt.h:1,
from include/linux/preempt.h:78,
from include/linux/spinlock.h:51,
from include/linux/mmzone.h:8,
from include/linux/page_reporting.h:5,
from <command-line>:0:
include/linux/page_reporting.h: In function '__del_page_from_reported_list':
arch/riscv/include/asm/page.h:24:22: error: 'PMD_SHIFT' undeclared (first use in this function); did you mean 'NMI_SHIFT'?
#define HPAGE_SHIFT PMD_SHIFT
^
arch/riscv/include/asm/page.h:27:34: note: in expansion of macro 'HPAGE_SHIFT'
#define HUGETLB_PAGE_ORDER (HPAGE_SHIFT - PAGE_SHIFT)
^~~~~~~~~~~
include/linux/pageblock-flags.h:41:26: note: in expansion of macro 'HUGETLB_PAGE_ORDER'
#define pageblock_order HUGETLB_PAGE_ORDER
^~~~~~~~~~~~~~~~~~
>> include/linux/page_reporting.h:9:34: note: in expansion of macro 'pageblock_order'
#define PAGE_REPORTING_MIN_ORDER pageblock_order
^~~~~~~~~~~~~~~
include/linux/page_reporting.h:61:44: note: in expansion of macro 'PAGE_REPORTING_MIN_ORDER'
zone->reported_pages[page_private(page) - PAGE_REPORTING_MIN_ORDER]--;
^~~~~~~~~~~~~~~~~~~~~~~~
arch/riscv/include/asm/page.h:24:22: note: each undeclared identifier is reported only once for each function it appears in
#define HPAGE_SHIFT PMD_SHIFT
^
arch/riscv/include/asm/page.h:27:34: note: in expansion of macro 'HPAGE_SHIFT'
#define HUGETLB_PAGE_ORDER (HPAGE_SHIFT - PAGE_SHIFT)
^~~~~~~~~~~
include/linux/pageblock-flags.h:41:26: note: in expansion of macro 'HUGETLB_PAGE_ORDER'
#define pageblock_order HUGETLB_PAGE_ORDER
^~~~~~~~~~~~~~~~~~
>> include/linux/page_reporting.h:9:34: note: in expansion of macro 'pageblock_order'
#define PAGE_REPORTING_MIN_ORDER pageblock_order
^~~~~~~~~~~~~~~
include/linux/page_reporting.h:61:44: note: in expansion of macro 'PAGE_REPORTING_MIN_ORDER'
zone->reported_pages[page_private(page) - PAGE_REPORTING_MIN_ORDER]--;
^~~~~~~~~~~~~~~~~~~~~~~~
In file included from <command-line>:0:0:
include/linux/page_reporting.h: At top level:
include/linux/page_reporting.h:74:1: error: conflicting types for 'get_unreported_tail'
get_unreported_tail(struct zone *zone, unsigned int order, int migratetype)
^~~~~~~~~~~~~~~~~~~
In file included from include/linux/page_reporting.h:5:0,
from <command-line>:0:
include/linux/mmzone.h:791:27: note: previous implicit declaration of 'get_unreported_tail' was here
struct list_head *tail = get_unreported_tail(zone, order, migratetype);
^~~~~~~~~~~~~~~~~~~
In file included from arch/riscv/include/asm/thread_info.h:11:0,
from include/linux/thread_info.h:38,
from include/asm-generic/preempt.h:5,
from ./arch/riscv/include/generated/asm/preempt.h:1,
from include/linux/preempt.h:78,
from include/linux/spinlock.h:51,
from include/linux/mmzone.h:8,
from include/linux/page_reporting.h:5,
from <command-line>:0:
include/linux/page_reporting.h: In function 'get_unreported_tail':
arch/riscv/include/asm/page.h:24:22: error: 'PMD_SHIFT' undeclared (first use in this function); did you mean 'NMI_SHIFT'?
#define HPAGE_SHIFT PMD_SHIFT
^
arch/riscv/include/asm/page.h:27:34: note: in expansion of macro 'HPAGE_SHIFT'
#define HUGETLB_PAGE_ORDER (HPAGE_SHIFT - PAGE_SHIFT)
^~~~~~~~~~~
include/linux/pageblock-flags.h:41:26: note: in expansion of macro 'HUGETLB_PAGE_ORDER'
#define pageblock_order HUGETLB_PAGE_ORDER
^~~~~~~~~~~~~~~~~~
>> include/linux/page_reporting.h:9:34: note: in expansion of macro 'pageblock_order'
#define PAGE_REPORTING_MIN_ORDER pageblock_order
^~~~~~~~~~~~~~~
include/linux/page_reporting.h:77:15: note: in expansion of macro 'PAGE_REPORTING_MIN_ORDER'
if (order >= PAGE_REPORTING_MIN_ORDER &&
^~~~~~~~~~~~~~~~~~~~~~~~
include/linux/page_reporting.h: In function 'add_page_to_reported_list':
arch/riscv/include/asm/page.h:24:22: error: 'PMD_SHIFT' undeclared (first use in this function); did you mean 'NMI_SHIFT'?
#define HPAGE_SHIFT PMD_SHIFT
^
arch/riscv/include/asm/page.h:27:34: note: in expansion of macro 'HPAGE_SHIFT'
#define HUGETLB_PAGE_ORDER (HPAGE_SHIFT - PAGE_SHIFT)
^~~~~~~~~~~
include/linux/pageblock-flags.h:41:26: note: in expansion of macro 'HUGETLB_PAGE_ORDER'
#define pageblock_order HUGETLB_PAGE_ORDER
^~~~~~~~~~~~~~~~~~
>> include/linux/page_reporting.h:9:34: note: in expansion of macro 'pageblock_order'
#define PAGE_REPORTING_MIN_ORDER pageblock_order
^~~~~~~~~~~~~~~
include/linux/page_reporting.h:99:31: note: in expansion of macro 'PAGE_REPORTING_MIN_ORDER'
zone->reported_pages[order - PAGE_REPORTING_MIN_ORDER]++;
^~~~~~~~~~~~~~~~~~~~~~~~
In file included from <command-line>:0:0:
include/linux/page_reporting.h: At top level:
include/linux/page_reporting.h:106:20: warning: conflicting types for 'del_page_from_reported_list'
static inline void del_page_from_reported_list(struct page *page,
^~~~~~~~~~~~~~~~~~~~~~~~~~~
include/linux/page_reporting.h:106:20: error: static declaration of 'del_page_from_reported_list' follows non-static declaration
In file included from include/linux/page_reporting.h:5:0,
from <command-line>:0:
include/linux/mmzone.h:831:3: note: previous implicit declaration of 'del_page_from_reported_list' was here
del_page_from_reported_list(page, zone);
^~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from <command-line>:0:0:
include/linux/page_reporting.h:118:20: warning: conflicting types for 'move_page_to_reported_list'
static inline void move_page_to_reported_list(struct page *page,
^~~~~~~~~~~~~~~~~~~~~~~~~~
include/linux/page_reporting.h:118:20: error: static declaration of 'move_page_to_reported_list' follows non-static declaration
In file included from include/linux/page_reporting.h:5:0,
from <command-line>:0:
include/linux/mmzone.h:815:3: note: previous implicit declaration of 'move_page_to_reported_list' was here
move_page_to_reported_list(page, zone, migratetype);
^~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from arch/riscv/include/asm/thread_info.h:11:0,
from include/linux/thread_info.h:38,
from include/asm-generic/preempt.h:5,
from ./arch/riscv/include/generated/asm/preempt.h:1,
from include/linux/preempt.h:78,
from include/linux/spinlock.h:51,
from include/linux/mmzone.h:8,
from include/linux/page_reporting.h:5,
from <command-line>:0:
include/linux/page_reporting.h: In function 'page_reporting_notify_free':
arch/riscv/include/asm/page.h:24:22: error: 'PMD_SHIFT' undeclared (first use in this function); did you mean 'NMI_SHIFT'?
#define HPAGE_SHIFT PMD_SHIFT
^
arch/riscv/include/asm/page.h:27:34: note: in expansion of macro 'HPAGE_SHIFT'
#define HUGETLB_PAGE_ORDER (HPAGE_SHIFT - PAGE_SHIFT)
^~~~~~~~~~~
include/linux/pageblock-flags.h:41:26: note: in expansion of macro 'HUGETLB_PAGE_ORDER'
#define pageblock_order HUGETLB_PAGE_ORDER
^~~~~~~~~~~~~~~~~~
>> include/linux/page_reporting.h:9:34: note: in expansion of macro 'pageblock_order'
#define PAGE_REPORTING_MIN_ORDER pageblock_order
^~~~~~~~~~~~~~~
include/linux/page_reporting.h:159:14: note: in expansion of macro 'PAGE_REPORTING_MIN_ORDER'
if (order < PAGE_REPORTING_MIN_ORDER)
^~~~~~~~~~~~~~~~~~~~~~~~
cc1: some warnings being treated as errors
--
In file included from arch/riscv/include/asm/thread_info.h:11:0,
from include/linux/thread_info.h:38,
from include/asm-generic/preempt.h:5,
from ./arch/riscv/include/generated/asm/preempt.h:1,
from include/linux/preempt.h:78,
from include/linux/radix-tree.h:14,
from include/linux/idr.h:15,
from include/linux/kernfs.h:13,
from include/linux/sysfs.h:16,
from include/linux/kobject.h:20,
from include/linux/of.h:17,
from include/linux/irqdomain.h:35,
from include/linux/acpi.h:13,
from drivers/soundwire/slave.c:4:
include/linux/page_reporting.h: In function '__del_page_from_reported_list':
arch/riscv/include/asm/page.h:24:22: error: 'PMD_SHIFT' undeclared (first use in this function); did you mean 'NMI_SHIFT'?
#define HPAGE_SHIFT PMD_SHIFT
^
arch/riscv/include/asm/page.h:27:34: note: in expansion of macro 'HPAGE_SHIFT'
#define HUGETLB_PAGE_ORDER (HPAGE_SHIFT - PAGE_SHIFT)
^~~~~~~~~~~
include/linux/pageblock-flags.h:41:26: note: in expansion of macro 'HUGETLB_PAGE_ORDER'
#define pageblock_order HUGETLB_PAGE_ORDER
^~~~~~~~~~~~~~~~~~
>> include/linux/page_reporting.h:9:34: note: in expansion of macro 'pageblock_order'
#define PAGE_REPORTING_MIN_ORDER pageblock_order
^~~~~~~~~~~~~~~
include/linux/page_reporting.h:61:44: note: in expansion of macro 'PAGE_REPORTING_MIN_ORDER'
zone->reported_pages[page_private(page) - PAGE_REPORTING_MIN_ORDER]--;
^~~~~~~~~~~~~~~~~~~~~~~~
arch/riscv/include/asm/page.h:24:22: note: each undeclared identifier is reported only once for each function it appears in
#define HPAGE_SHIFT PMD_SHIFT
^
arch/riscv/include/asm/page.h:27:34: note: in expansion of macro 'HPAGE_SHIFT'
#define HUGETLB_PAGE_ORDER (HPAGE_SHIFT - PAGE_SHIFT)
^~~~~~~~~~~
include/linux/pageblock-flags.h:41:26: note: in expansion of macro 'HUGETLB_PAGE_ORDER'
#define pageblock_order HUGETLB_PAGE_ORDER
^~~~~~~~~~~~~~~~~~
>> include/linux/page_reporting.h:9:34: note: in expansion of macro 'pageblock_order'
#define PAGE_REPORTING_MIN_ORDER pageblock_order
^~~~~~~~~~~~~~~
include/linux/page_reporting.h:61:44: note: in expansion of macro 'PAGE_REPORTING_MIN_ORDER'
zone->reported_pages[page_private(page) - PAGE_REPORTING_MIN_ORDER]--;
^~~~~~~~~~~~~~~~~~~~~~~~
include/linux/page_reporting.h: In function 'get_unreported_tail':
arch/riscv/include/asm/page.h:24:22: error: 'PMD_SHIFT' undeclared (first use in this function); did you mean 'NMI_SHIFT'?
#define HPAGE_SHIFT PMD_SHIFT
^
arch/riscv/include/asm/page.h:27:34: note: in expansion of macro 'HPAGE_SHIFT'
#define HUGETLB_PAGE_ORDER (HPAGE_SHIFT - PAGE_SHIFT)
^~~~~~~~~~~
include/linux/pageblock-flags.h:41:26: note: in expansion of macro 'HUGETLB_PAGE_ORDER'
#define pageblock_order HUGETLB_PAGE_ORDER
^~~~~~~~~~~~~~~~~~
>> include/linux/page_reporting.h:9:34: note: in expansion of macro 'pageblock_order'
#define PAGE_REPORTING_MIN_ORDER pageblock_order
^~~~~~~~~~~~~~~
include/linux/page_reporting.h:77:15: note: in expansion of macro 'PAGE_REPORTING_MIN_ORDER'
if (order >= PAGE_REPORTING_MIN_ORDER &&
^~~~~~~~~~~~~~~~~~~~~~~~
include/linux/page_reporting.h: In function 'add_page_to_reported_list':
arch/riscv/include/asm/page.h:24:22: error: 'PMD_SHIFT' undeclared (first use in this function); did you mean 'NMI_SHIFT'?
#define HPAGE_SHIFT PMD_SHIFT
^
arch/riscv/include/asm/page.h:27:34: note: in expansion of macro 'HPAGE_SHIFT'
#define HUGETLB_PAGE_ORDER (HPAGE_SHIFT - PAGE_SHIFT)
^~~~~~~~~~~
include/linux/pageblock-flags.h:41:26: note: in expansion of macro 'HUGETLB_PAGE_ORDER'
#define pageblock_order HUGETLB_PAGE_ORDER
^~~~~~~~~~~~~~~~~~
>> include/linux/page_reporting.h:9:34: note: in expansion of macro 'pageblock_order'
#define PAGE_REPORTING_MIN_ORDER pageblock_order
^~~~~~~~~~~~~~~
include/linux/page_reporting.h:99:31: note: in expansion of macro 'PAGE_REPORTING_MIN_ORDER'
zone->reported_pages[order - PAGE_REPORTING_MIN_ORDER]++;
^~~~~~~~~~~~~~~~~~~~~~~~
include/linux/page_reporting.h: In function 'page_reporting_notify_free':
arch/riscv/include/asm/page.h:24:22: error: 'PMD_SHIFT' undeclared (first use in this function); did you mean 'NMI_SHIFT'?
#define HPAGE_SHIFT PMD_SHIFT
^
arch/riscv/include/asm/page.h:27:34: note: in expansion of macro 'HPAGE_SHIFT'
#define HUGETLB_PAGE_ORDER (HPAGE_SHIFT - PAGE_SHIFT)
^~~~~~~~~~~
include/linux/pageblock-flags.h:41:26: note: in expansion of macro 'HUGETLB_PAGE_ORDER'
#define pageblock_order HUGETLB_PAGE_ORDER
^~~~~~~~~~~~~~~~~~
>> include/linux/page_reporting.h:9:34: note: in expansion of macro 'pageblock_order'
#define PAGE_REPORTING_MIN_ORDER pageblock_order
^~~~~~~~~~~~~~~
include/linux/page_reporting.h:159:14: note: in expansion of macro 'PAGE_REPORTING_MIN_ORDER'
if (order < PAGE_REPORTING_MIN_ORDER)
^~~~~~~~~~~~~~~~~~~~~~~~
At top level:
drivers/soundwire/slave.c:16:12: warning: 'sdw_slave_add' defined but not used [-Wunused-function]
static int sdw_slave_add(struct sdw_bus *bus,
^~~~~~~~~~~~~
vim +/pageblock_order +9 include/linux/page_reporting.h
50ed0c2ecb2e25 Alexander Duyck 2019-09-07 8
50ed0c2ecb2e25 Alexander Duyck 2019-09-07 @9 #define PAGE_REPORTING_MIN_ORDER pageblock_order
50ed0c2ecb2e25 Alexander Duyck 2019-09-07 10 #define PAGE_REPORTING_HWM 32
50ed0c2ecb2e25 Alexander Duyck 2019-09-07 11
:::::: The code at line 9 was first introduced by commit
:::::: 50ed0c2ecb2e254a50e4ad775840f29d42cf6c00 mm: Introduce Reported pages
:::::: TO: Alexander Duyck <alexander.h.duyck@linux.intel.com>
:::::: CC: Michael S. Tsirkin <mst@redhat.com>
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 59248 bytes --]
^ permalink raw reply
* Re: [PATCH] net/mlx5: Declare 'rt' as corresponding enum type
From: Austin Kim @ 2019-09-11 11:39 UTC (permalink / raw)
To: Saeed Mahameed
Cc: leon@kernel.org, linux-rdma@vger.kernel.org,
linux-kernel@vger.kernel.org, Mark Bloch, davem@davemloft.net,
netdev@vger.kernel.org, Alex Vesker, Erez Shitrit
In-Reply-To: <61418cb7514460e24bfcd431eee9c540e795fcbc.camel@mellanox.com>
It is good to hear that similar patch was submitted.
Thanks for notification.
Thanks,
Austin Kim
2019년 9월 11일 (수) 오전 2:59, Saeed Mahameed <saeedm@mellanox.com>님이 작성:
>
> On Tue, 2019-09-10 at 18:27 +0900, Austin Kim wrote:
> > When building kernel with clang, we can observe below warning
> > message:
> >
> > drivers/net/ethernet/mellanox/mlx5/core/steering/dr_action.c:1080:9:
> > warning: implicit conversion from enumeration type 'enum
> > mlx5_reformat_ctx_type'
> > to different enumeration type 'enum mlx5dr_action_type' [- Wenum-
> > conversion]
> > rt = MLX5_REFORMAT_TYPE_L2_TO_L2_TUNNEL;
> > ~ ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > drivers/net/ethernet/mellanox/mlx5/core/steering/dr_action.c:1082:9:
> > warning: implicit conversion from enumeration type 'enum
> > mlx5_reformat_ctx_type'
> > to different enumeration type 'enum mlx5dr_action_type' [- Wenum-
> > conversion]
> > rt = MLX5_REFORMAT_TYPE_L2_TO_L3_TUNNEL;
> > ~ ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > drivers/net/ethernet/mellanox/mlx5/core/steering/dr_action.c:1084:51:
> > warning: implicit conversion from enumeration type 'enum
> > mlx5dr_action_type'
> > to different enumeration type 'enum mlx5_reformat_ctx_type'
> > [- Wenum-conversion]
> > ret = mlx5dr_cmd_create_reformat_ctx(dmn->mdev, rt, data_sz,
> > data,
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ^~
> >
> > Declare 'rt' as corresponding enum mlx5_reformat_ctx_type type.
> >
> > Signed-off-by: Austin Kim <austindh.kim@gmail.com>
> Hi Austin, Thanks for the patch:
>
> We already have a similar patch queued for submission.
> https://patchwork.ozlabs.org/patch/1158175/
>
> > ---
> > drivers/net/ethernet/mellanox/mlx5/core/steering/dr_action.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git
> > a/drivers/net/ethernet/mellanox/mlx5/core/steering/dr_action.c
> > b/drivers/net/ethernet/mellanox/mlx5/core/steering/dr_action.c
> > index a02f87f..7d81a77 100644
> > --- a/drivers/net/ethernet/mellanox/mlx5/core/steering/dr_action.c
> > +++ b/drivers/net/ethernet/mellanox/mlx5/core/steering/dr_action.c
> > @@ -1074,7 +1074,7 @@ dr_action_create_reformat_action(struct
> > mlx5dr_domain *dmn,
> > case DR_ACTION_TYP_L2_TO_TNL_L2:
> > case DR_ACTION_TYP_L2_TO_TNL_L3:
> > {
> > - enum mlx5dr_action_type rt;
> > + enum mlx5_reformat_ctx_type rt;
> >
> > if (action->action_type == DR_ACTION_TYP_L2_TO_TNL_L2)
> > rt = MLX5_REFORMAT_TYPE_L2_TO_L2_TUNNEL;
^ permalink raw reply
* Re: [PATCH net-next 01/11] net: aquantia: PTP skeleton declarations and callbacks
From: Igor Russkikh @ 2019-09-11 11:41 UTC (permalink / raw)
To: Andrew Lunn
Cc: netdev@vger.kernel.org, richardcochran@gmail.com,
davem@davemloft.net, Egor Pomozov, Sergey Samoilenko,
Dmitry Bezrukov
In-Reply-To: <20190910191029.GE9761@lunn.ch>
Hi Andrew,
>> + struct ptp_clock *clock;
>> + struct aq_ptp_s *self;
>
> I find the use of self in this code quite confusing. It does not
> appear to have a clear meaning. It can be a aq_ring_s, aq_nic_c,
> aq_hw_s, aq_vec_s.
>
> Looking at this code i always have to figure out what self is. Could
> you not just use struct aq_ptp_s aq_ptp consistently in the code?
Agreed,
>> +
>> + self = kzalloc(sizeof(*self), GFP_KERNEL);
>
> Using devm_kzalloc() will make your clean up easier.
>> +
>> + kfree(self);
>
> kfree() is happy to take a NULL pointer. But this could all go away
> with devm_kzalloc().
You are probably right, that'll be easier,
>> +static int hw_atl_b0_adj_sys_clock(struct aq_hw_s *self, s64 delta)
>> +{
>> + ptp_clk_offset += delta;
>> +
>> + return 0;
>> +}
>
> Does this work when i have a box with 42 NICs in it? Does not each NIC
> need its own clock offset? Just seeing code like this causes alarm
> bells. So if it is correct, i would expect some sort of comment to
> prevent those alarm bells.
No comment is needed, that is obviously a per-device variable,
Thanks for catching this!
Will fix that, as well as kbuild robot discovered issues.
Regards,
Igor
^ permalink raw reply
* [PATCH net-next 0/2] qed* Fix series.
From: Sudarsana Reddy Kalluru @ 2019-09-11 11:42 UTC (permalink / raw)
To: davem; +Cc: netdev, mkalderon, aelior
The patch series addresses couple of issues in the recent commits.
Patch (1) populates the actual dump-size of config attribute instead of
providing a fixed size value.
Patch(2) updates frame format of flash config buffer as required by
management FW (MFW).
Please consider applying it to net-next.
Sudarsana Reddy Kalluru (2):
qed*: Fix size of config attribute dump.
qed: Fix Config attribute frame format.
drivers/net/ethernet/qlogic/qed/qed_main.c | 47 +++++++++++++++++++------
drivers/net/ethernet/qlogic/qede/qede_ethtool.c | 14 ++++----
include/linux/qed/qed_if.h | 8 +++++
3 files changed, 53 insertions(+), 16 deletions(-)
--
1.8.3.1
^ permalink raw reply
* [PATCH net-next 1/2] qed*: Fix size of config attribute dump.
From: Sudarsana Reddy Kalluru @ 2019-09-11 11:42 UTC (permalink / raw)
To: davem; +Cc: netdev, mkalderon, aelior
In-Reply-To: <20190911114251.7013-1-skalluru@marvell.com>
Driver currently returns max-buf-size as size of the config attribute.
This patch incorporates changes to read this value from MFW (if available)
and provide it to the user. Also did a trivial clean up in this path.
Fixes: d44a3ced7023 ("qede: Add support for reading the config id attributes.")
Signed-off-by: Sudarsana Reddy Kalluru <skalluru@marvell.com>
Signed-off-by: Ariel Elior <aelior@marvell.com>
---
drivers/net/ethernet/qlogic/qed/qed_main.c | 26 +++++++++++++++++++++++++
drivers/net/ethernet/qlogic/qede/qede_ethtool.c | 14 +++++++------
include/linux/qed/qed_if.h | 8 ++++++++
3 files changed, 42 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/qlogic/qed/qed_main.c b/drivers/net/ethernet/qlogic/qed/qed_main.c
index ac1511a8..38c0ec3 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_main.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_main.c
@@ -2300,6 +2300,31 @@ static int qed_nvm_flash_cfg_write(struct qed_dev *cdev, const u8 **data)
return rc;
}
+#define QED_MAX_NVM_BUF_LEN 32
+static int qed_nvm_flash_cfg_len(struct qed_dev *cdev, u32 cmd)
+{
+ struct qed_hwfn *hwfn = QED_LEADING_HWFN(cdev);
+ u8 buf[QED_MAX_NVM_BUF_LEN];
+ struct qed_ptt *ptt;
+ u32 len;
+ int rc;
+
+ ptt = qed_ptt_acquire(hwfn);
+ if (!ptt)
+ return QED_MAX_NVM_BUF_LEN;
+
+ rc = qed_mcp_nvm_get_cfg(hwfn, ptt, cmd, 0, QED_NVM_CFG_GET_FLAGS, buf,
+ &len);
+ if (rc || !len) {
+ DP_ERR(cdev, "Error %d reading %d\n", rc, cmd);
+ len = QED_MAX_NVM_BUF_LEN;
+ }
+
+ qed_ptt_release(hwfn, ptt);
+
+ return len;
+}
+
static int qed_nvm_flash_cfg_read(struct qed_dev *cdev, u8 **data,
u32 cmd, u32 entity_id)
{
@@ -2657,6 +2682,7 @@ static u8 qed_get_affin_hwfn_idx(struct qed_dev *cdev)
.read_module_eeprom = &qed_read_module_eeprom,
.get_affin_hwfn_idx = &qed_get_affin_hwfn_idx,
.read_nvm_cfg = &qed_nvm_flash_cfg_read,
+ .read_nvm_cfg_len = &qed_nvm_flash_cfg_len,
.set_grc_config = &qed_set_grc_config,
};
diff --git a/drivers/net/ethernet/qlogic/qede/qede_ethtool.c b/drivers/net/ethernet/qlogic/qede/qede_ethtool.c
index ec27a43..8a426af 100644
--- a/drivers/net/ethernet/qlogic/qede/qede_ethtool.c
+++ b/drivers/net/ethernet/qlogic/qede/qede_ethtool.c
@@ -49,7 +49,6 @@
#define QEDE_SELFTEST_POLL_COUNT 100
#define QEDE_DUMP_VERSION 0x1
-#define QEDE_DUMP_NVM_BUF_LEN 32
#define QEDE_DUMP_NVM_ARG_COUNT 2
static const struct {
@@ -2026,7 +2025,8 @@ static int qede_get_dump_flag(struct net_device *dev,
switch (edev->dump_info.cmd) {
case QEDE_DUMP_CMD_NVM_CFG:
dump->flag = QEDE_DUMP_CMD_NVM_CFG;
- dump->len = QEDE_DUMP_NVM_BUF_LEN;
+ dump->len = edev->ops->common->read_nvm_cfg_len(edev->cdev,
+ edev->dump_info.args[0]);
break;
case QEDE_DUMP_CMD_GRCDUMP:
dump->flag = QEDE_DUMP_CMD_GRCDUMP;
@@ -2051,9 +2051,8 @@ static int qede_get_dump_data(struct net_device *dev,
if (!edev->ops || !edev->ops->common) {
DP_ERR(edev, "Edev ops not populated\n");
- edev->dump_info.cmd = QEDE_DUMP_CMD_NONE;
- edev->dump_info.num_args = 0;
- return -EINVAL;
+ rc = -EINVAL;
+ goto err;
}
switch (edev->dump_info.cmd) {
@@ -2062,7 +2061,8 @@ static int qede_get_dump_data(struct net_device *dev,
DP_ERR(edev, "Arg count = %d required = %d\n",
edev->dump_info.num_args,
QEDE_DUMP_NVM_ARG_COUNT);
- return -EINVAL;
+ rc = -EINVAL;
+ goto err;
}
rc = edev->ops->common->read_nvm_cfg(edev->cdev, (u8 **)&buf,
edev->dump_info.args[0],
@@ -2078,8 +2078,10 @@ static int qede_get_dump_data(struct net_device *dev,
break;
}
+err:
edev->dump_info.cmd = QEDE_DUMP_CMD_NONE;
edev->dump_info.num_args = 0;
+ memset(edev->dump_info.args, 0, sizeof(edev->dump_info.args));
return rc;
}
diff --git a/include/linux/qed/qed_if.h b/include/linux/qed/qed_if.h
index e354638..b5db1ee 100644
--- a/include/linux/qed/qed_if.h
+++ b/include/linux/qed/qed_if.h
@@ -1143,6 +1143,14 @@ struct qed_common_ops {
*/
int (*read_nvm_cfg)(struct qed_dev *cdev, u8 **buf, u32 cmd,
u32 entity_id);
+/**
+ * @brief read_nvm_cfg - Read NVM config attribute value.
+ * @param cdev
+ * @param cmd - NVM CFG command id
+ *
+ * @return config id length, 0 on error.
+ */
+ int (*read_nvm_cfg_len)(struct qed_dev *cdev, u32 cmd);
/**
* @brief set_grc_config - Configure value for grc config id.
--
1.8.3.1
^ permalink raw reply related
* [PATCH net-next 2/2] qed: Fix Config attribute frame format.
From: Sudarsana Reddy Kalluru @ 2019-09-11 11:42 UTC (permalink / raw)
To: davem; +Cc: netdev, mkalderon, aelior
In-Reply-To: <20190911114251.7013-1-skalluru@marvell.com>
MFW associates the entity id to a config attribute instead of assigning
one entity id for all the config attributes.
This patch incorporates driver changes to link entity id to a config id
attribute.
Fixes: 0dabbe1bb3a4 ("qed: Add driver API for flashing the config attributes.")
Signed-off-by: Sudarsana Reddy Kalluru <skalluru@marvell.com>
Signed-off-by: Ariel Elior <aelior@marvell.com>
---
drivers/net/ethernet/qlogic/qed/qed_main.c | 21 +++++++++++----------
1 file changed, 11 insertions(+), 10 deletions(-)
diff --git a/drivers/net/ethernet/qlogic/qed/qed_main.c b/drivers/net/ethernet/qlogic/qed/qed_main.c
index 38c0ec3..2ce7009 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_main.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_main.c
@@ -2240,12 +2240,13 @@ static int qed_nvm_flash_image_validate(struct qed_dev *cdev,
/* Binary file format -
* /----------------------------------------------------------------------\
* 0B | 0x5 [command index] |
- * 4B | Entity ID | Reserved | Number of config attributes |
- * 8B | Config ID | Length | Value |
+ * 4B | Number of config attributes | Reserved |
+ * 4B | Config ID | Entity ID | Length |
+ * 4B | Value |
* | |
* \----------------------------------------------------------------------/
- * There can be several cfg_id-Length-Value sets as specified by 'Number of...'.
- * Entity ID - A non zero entity value for which the config need to be updated.
+ * There can be several cfg_id-entity_id-Length-Value sets as specified by
+ * 'Number of config attributes'.
*
* The API parses config attributes from the user provided buffer and flashes
* them to the respective NVM path using Management FW inerface.
@@ -2265,18 +2266,17 @@ static int qed_nvm_flash_cfg_write(struct qed_dev *cdev, const u8 **data)
/* NVM CFG ID attribute header */
*data += 4;
- entity_id = **data;
- *data += 2;
count = *((u16 *)*data);
- *data += 2;
+ *data += 4;
DP_VERBOSE(cdev, NETIF_MSG_DRV,
- "Read config ids: entity id %02x num _attrs = %0d\n",
- entity_id, count);
+ "Read config ids: num_attrs = %0d\n", count);
/* NVM CFG ID attributes */
for (i = 0; i < count; i++) {
cfg_id = *((u16 *)*data);
*data += 2;
+ entity_id = **data;
+ (*data)++;
len = **data;
(*data)++;
memcpy(buf, *data, len);
@@ -2286,7 +2286,8 @@ static int qed_nvm_flash_cfg_write(struct qed_dev *cdev, const u8 **data)
QED_NVM_CFG_SET_FLAGS;
DP_VERBOSE(cdev, NETIF_MSG_DRV,
- "cfg_id = %d len = %d\n", cfg_id, len);
+ "cfg_id = %d entity = %d len = %d\n", cfg_id,
+ entity_id, len);
rc = qed_mcp_nvm_set_cfg(hwfn, ptt, cfg_id, entity_id, flags,
buf, len);
if (rc) {
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH v5.1-rc] iwlwifi: make locking in iwl_mvm_tx_mpdu() BH-safe
From: Jiri Kosina @ 2019-09-11 11:42 UTC (permalink / raw)
To: Johannes Berg
Cc: Emmanuel Grumbach, Luca Coelho, Intel Linux Wireless, Kalle Valo,
David S. Miller, netdev, linux-kernel
In-Reply-To: <01d55c5cf513554d9cbdee0b14f9360a8df859c8.camel@sipsolutions.net>
On Mon, 15 Apr 2019, Johannes Berg wrote:
> > If there are other reasons why disable BH for the whole function (are
> > there?), then this bigger hammer works as well of course.
>
> I thought there are, but seeing the commit log here I'm not sure.
>
> In any case, even if not, the function itself is part of the TX fast
> path, but the caller from the workqueue is very uncommon (basically only
> happens for a handful of packets on each new RA/TID), so I'd say that'd
> be a good reason to use the slightly bigger hammer (it's not that much
> different really, if you look at how much code is covered by the lock)
> and avoid doing it all the time when we know it to be not needed.
So this now popped up on me with current Linus' tree from a different
codepath, see below. Therefore I'd like to propose bringing my previous
patch back to life.
Thanks.
From: Jiri Kosina <jkosina@suse.cz>
Subject: [PATCH] iwlwifi: make locking in iwl_mvm_tx_mpdu() BH-safe
iwl_mvm_sta->lock can be taken from BH, and therefore BH must be disabled if
taking it from other contexts.
This fixes the lockdep warning below.
================================
WARNING: inconsistent lock state
5.3.0-rc8 #3 Tainted: G W
--------------------------------
inconsistent {IN-SOFTIRQ-W} -> {SOFTIRQ-ON-W} usage.
kworker/u8:2/28401 [HC0[0]:SC0[0]:HE1:SE1] takes:
000000009c020e13 (&(&mvm_sta->lock)->rlock){+.?.}, at: iwl_mvm_tx_mpdu+0xae/0x600 [iwlmvm]
{IN-SOFTIRQ-W} state was registered at:
lock_acquire+0xbd/0x1e0
_raw_spin_lock+0x35/0x50
iwl_mvm_tx_mpdu+0xae/0x600 [iwlmvm]
iwl_mvm_tx_skb+0x1f8/0x460 [iwlmvm]
iwl_mvm_mac_itxq_xmit+0xcc/0x200 [iwlmvm]
ieee80211_queue_skb+0x290/0x4c0 [mac80211]
ieee80211_xmit_fast+0x814/0xa70 [mac80211]
__ieee80211_subif_start_xmit+0x132/0x380 [mac80211]
ieee80211_subif_start_xmit+0x49/0x370 [mac80211]
dev_hard_start_xmit+0xaf/0x340
__dev_queue_xmit+0x98d/0xd20
ip6_finish_output2+0x323/0x960
ip6_output+0x19d/0x2d0
mld_sendpack+0x361/0x3a0
mld_ifc_timer_expire+0x19f/0x2e0
call_timer_fn+0x97/0x300
run_timer_softirq+0x233/0x590
__do_softirq+0x12c/0x448
irq_exit+0xa5/0xb0
smp_apic_timer_interrupt+0xac/0x2a0
apic_timer_interrupt+0xf/0x20
cpuidle_enter_state+0xbf/0x450
cpuidle_enter+0x29/0x40
do_idle+0x1cc/0x290
cpu_startup_entry+0x19/0x20
start_secondary+0x15f/0x1a0
secondary_startup_64+0xa4/0xb0
[ ... snip ... ]
stack backtrace:
CPU: 1 PID: 28401 Comm: kworker/u8:2 Tainted: G W 5.3.0-rc8 #3
Hardware name: LENOVO 20K5S22R00/20K5S22R00, BIOS R0IET38W (1.16 ) 05/31/2017
Workqueue: phy0 ieee80211_beacon_connection_loss_work [mac80211]
Call Trace:
dump_stack+0x78/0xb3
mark_lock+0x28a/0x2a0
__lock_acquire+0x568/0x1020
? iwl_mvm_set_tx_cmd+0x1c5/0x400 [iwlmvm]
lock_acquire+0xbd/0x1e0
? iwl_mvm_tx_mpdu+0xae/0x600 [iwlmvm]
_raw_spin_lock+0x35/0x50
? iwl_mvm_tx_mpdu+0xae/0x600 [iwlmvm]
iwl_mvm_tx_mpdu+0xae/0x600 [iwlmvm]
? ieee80211_tx_h_select_key+0xf1/0x4a0 [mac80211]
iwl_mvm_tx_skb+0x1f8/0x460 [iwlmvm]
iwl_mvm_mac_itxq_xmit+0xcc/0x200 [iwlmvm]
? iwl_mvm_mac_itxq_xmit+0x55/0x200 [iwlmvm]
_ieee80211_wake_txqs+0x2cf/0x660 [mac80211]
? _ieee80211_wake_txqs+0x5/0x660 [mac80211]
? __ieee80211_wake_queue+0x219/0x340 [mac80211]
ieee80211_wake_queues_by_reason+0x64/0xa0 [mac80211]
ieee80211_set_disassoc+0x3b1/0x520 [mac80211]
__ieee80211_disconnect+0x81/0x110 [mac80211]
process_one_work+0x1f0/0x5b0
? process_one_work+0x16a/0x5b0
worker_thread+0x4c/0x3f0
kthread+0x103/0x140
? process_one_work+0x5b0/0x5b0
? kthread_bind+0x10/0x10
ret_from_fork+0x3a/0x50
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
---
drivers/net/wireless/intel/iwlwifi/mvm/tx.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/tx.c b/drivers/net/wireless/intel/iwlwifi/mvm/tx.c
index 6ac114a393cc..bcfb290beaaf 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/tx.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/tx.c
@@ -1106,7 +1106,7 @@ static int iwl_mvm_tx_mpdu(struct iwl_mvm *mvm, struct sk_buff *skb,
*/
info->flags &= ~IEEE80211_TX_STATUS_EOSP;
- spin_lock(&mvmsta->lock);
+ spin_lock_bh(&mvmsta->lock);
/* nullfunc frames should go to the MGMT queue regardless of QOS,
* the condition of !ieee80211_is_qos_nullfunc(fc) keeps the default
@@ -1145,7 +1145,7 @@ static int iwl_mvm_tx_mpdu(struct iwl_mvm *mvm, struct sk_buff *skb,
if (WARN_ONCE(txq_id == IWL_MVM_INVALID_QUEUE, "Invalid TXQ id")) {
iwl_trans_free_tx_cmd(mvm->trans, dev_cmd);
- spin_unlock(&mvmsta->lock);
+ spin_unlock_bh(&mvmsta->lock);
return 0;
}
@@ -1181,7 +1181,7 @@ static int iwl_mvm_tx_mpdu(struct iwl_mvm *mvm, struct sk_buff *skb,
if (tid < IWL_MAX_TID_COUNT && !ieee80211_has_morefrags(fc))
mvmsta->tid_data[tid].seq_number = seq_number + 0x10;
- spin_unlock(&mvmsta->lock);
+ spin_unlock_bh(&mvmsta->lock);
if (iwl_mvm_tx_pkt_queued(mvm, mvmsta,
tid == IWL_MAX_TID_COUNT ? 0 : tid))
@@ -1191,7 +1191,7 @@ static int iwl_mvm_tx_mpdu(struct iwl_mvm *mvm, struct sk_buff *skb,
drop_unlock_sta:
iwl_trans_free_tx_cmd(mvm->trans, dev_cmd);
- spin_unlock(&mvmsta->lock);
+ spin_unlock_bh(&mvmsta->lock);
drop:
IWL_DEBUG_TX(mvm, "TX to [%d|%d] dropped\n", mvmsta->sta_id, tid);
return -1;
--
Jiri Kosina
SUSE Labs
^ 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