* Re: [PATCH bpf-next] bpf, capabilities: introduce CAP_BPF
From: Andy Lutomirski @ 2019-08-27 23:01 UTC (permalink / raw)
To: Alexei Starovoitov, Kees Cook, LSM List, James Morris, Jann Horn,
Peter Zijlstra, Masami Hiramatsu, Steven Rostedt
Cc: David S. Miller, Daniel Borkmann, Network Development, bpf,
kernel-team, Linux API
In-Reply-To: <20190827205213.456318-1-ast@kernel.org>
[adding some security and tracing folks to cc]
On Tue, Aug 27, 2019 at 1:52 PM Alexei Starovoitov <ast@kernel.org> wrote:
>
> Introduce CAP_BPF that allows loading all types of BPF programs,
> create most map types, load BTF, iterate programs and maps.
> CAP_BPF alone is not enough to attach or run programs.
>
> Networking:
>
> CAP_BPF and CAP_NET_ADMIN are necessary to:
> - attach to cgroup-bpf hooks like INET_INGRESS, INET_SOCK_CREATE, INET4_CONNECT
> - run networking bpf programs (like xdp, skb, flow_dissector)
>
> Tracing:
>
> CAP_BPF and perf_paranoid_tracepoint_raw() (which is kernel.perf_event_paranoid == -1)
> are necessary to:
> - attach bpf program to raw tracepoint
> - use bpf_trace_printk() in all program types (not only tracing programs)
> - create bpf stackmap
>
> To attach bpf to perf_events perf_event_open() needs to succeed as usual.
>
> CAP_BPF controls BPF side.
> CAP_NET_ADMIN controls intersection where BPF calls into networking.
> perf_paranoid_tracepoint_raw controls intersection where BPF calls into tracing.
>
> In the future CAP_TRACING could be introduced to control
> creation of kprobe/uprobe and attaching bpf to perf_events.
> In such case bpf_probe_read() thin wrapper would be controlled by CAP_BPF.
> Whereas probe_read() would be controlled by CAP_TRACING.
> CAP_TRACING would also control generic kprobe+probe_read.
> CAP_BPF and CAP_TRACING would be necessary for tracing bpf programs
> that want to use bpf_probe_read.
First, some high-level review:
Can you write up some clear documentation aimed at administrators that
says what CAP_BPF does? For example, is it expected that CAP_BPF by
itself permits reading all kernel memory? Why might one grant it?
Can you give at least one fully described use case where CAP_BPF
solves a real-world problem that is not solved by existing mechanisms?
Changing the capability that some existing operation requires could
break existing programs. The old capability may need to be accepted
as well.
I'm inclined to suggest that CAP_TRACING be figured out or rejected
before something like this gets applied.
>
> Signed-off-by: Alexei Starovoitov <ast@kernel.org>
> ---
> I would prefer to introduce CAP_TRACING soon, since it
> will make tracing and networking permission model symmetrical.
>
Here's my proposal for CAP_TRACING, documentation-style:
--- begin ---
CAP_TRACING enables a task to use various kernel features to trace
running user programs and the kernel itself. CAP_TRACING also enables
a task to bypass some speculation attack countermeasures. A task in
the init user namespace with CAP_TRACING will be able to tell exactly
what kernel code is executed and when, and will be able to read kernel
registers and kernel memory. It will, similarly, be able to read the
state of other user tasks.
Specifically, CAP_TRACING allows the following operations. It may
allow more operations in the future:
- Full use of perf_event_open(), similarly to the effect of
kernel.perf_event_paranoid == -1.
- Loading and attaching tracing BPF programs, including use of BPF
raw tracepoints.
- Use of BPF stack maps.
- Use of bpf_probe_read() and bpf_trace_printk().
- Use of unsafe pointer-to-integer conversions in BPF.
- Bypassing of BPF's speculation attack hardening measures and
constant blinding. (Note: other mechanisms might also allow this.)
CAP_TRACING does not override normal permissions on sysfs or debugfs.
This means that, unless a new interface for programming kprobes and
such is added, it does not directly allow use of kprobes.
If CAP_TRACING, by itself, enables a task to crash or otherwise
corrupt the kernel or other tasks, this will be considered a kernel
bug.
CAP_TRACING in a non-init user namespace may, in the future, allow
tracing of other tasks in that user namespace or its descendants. It
will not enable kernel tracing or tracing of tasks outside the user
namespace in question.
--- end ---
Does this sound good? The idea here is that CAP_TRACING should be
very useful even without CAP_BPF, which allows CAP_BPF to be less
powerful.
> +bool cap_bpf_tracing(void)
> +{
> + return capable(CAP_SYS_ADMIN) ||
> + (capable(CAP_BPF) && !perf_paranoid_tracepoint_raw());
> +}
If auditing is on, this will audit the wrong thing. James, I think a
helper like:
bool ns_either_cap(struct user_ns *ns, int preferred_cap, int other_cap);
would help. ns_either_cap returns true if either cap is held (i.e.
effective, as usual). On success, it audits preferred_cap if held and
other_cap otherwise. On failure, it audits preferred_cap. Does this
sound right?
Also, for reference, perf_paranoid_tracepoint_raw() is this:
static inline bool perf_paranoid_tracepoint_raw(void)
{
return sysctl_perf_event_paranoid > -1;
}
so the overall effect of cap_bpf_tracing() is rather odd, and it seems
to control a few things that don't obvious all have similar security
effects.
> @@ -2080,7 +2083,10 @@ static int bpf_prog_test_run(const union bpf_attr *attr,
> struct bpf_prog *prog;
> int ret = -ENOTSUPP;
>
> - if (!capable(CAP_SYS_ADMIN))
> + if (!capable(CAP_NET_ADMIN) || !capable(CAP_BPF))
> + /* test_run callback is available for networking progs only.
> + * Add cap_bpf_tracing() above when tracing progs become runable.
> + */
I think test_run should probably be CAP_SYS_ADMIN forever. test_run
is the only way that one can run a bpf program and call helper
functions via the program if one doesn't have permission to attach the
program. Also, if there's a way to run a speculation attack via a bpf
program, test_run will make it much easier to do in a controlled
environment. Finally, when debugging bpf programs, developers can use
their own computers or a VM.
^ permalink raw reply
* Re: [E1000-devel] SFP+ EEPROM readouts fail on X722 (ethtool -m: Invalid argument)
From: Jakub Jankowski @ 2019-08-27 23:01 UTC (permalink / raw)
To: Fujinaka, Todd, e1000-devel@lists.sourceforge.net
Cc: netdev@vger.kernel.org, mhemsley@open-systems.com
In-Reply-To: <9B4A1B1917080E46B64F07F2989DADD69B013DB0@ORSMSX115.amr.corp.intel.com>
Hi,
On 8/27/19 7:56 PM, Fujinaka, Todd wrote:
> The hints should be:
> # ethtool -m eth10
> Cannot get module EEPROM information: Invalid argument # dmesg | tail -n 1 [ 445.971974] i40e 0000:3d:00.3 eth10: Module EEPROM memory read not supported. Please update the NVM image.
>
> # ethtool -i eth10
> driver: i40e
> version: 2.9.21
> firmware-version: 3.31 0x80000d31 1.1767.0
>
> And the working case:
> # ethtool -i eth8
> driver: i40e
> version: 2.9.21
> firmware-version: 6.01 0x800035cf 1.1876.0
>
> If you don't see it, 6.01 > 3.31.
The reason why firmware between the two is (that much) different is
because the non-working case is from X722 NIC, while the working one is
from X710.
> The NVM update tool should be available on downloadcenter.intel.com
Thanks for the pointer to NVM updater. I'd like to offer some additional
comments about my experience with the newest one (v4.00):
a) running ./nvmupdate64e (from X722_NVMUpdate_Linux_x64 subdir) errors
out without really saying what's wrong:
# ./nvmupdate64e
Intel(R) Ethernet NVM Update Tool
NVMUpdate version 1.30.2.11
Copyright (C) 2013 - 2017 Intel Corporation.
WARNING: To avoid damage to your device, do not stop the update or
reboot or power off the system during this update.
Inventory in progress. Please wait [+.........]
Tool execution completed with the following status: The configuration
file could not be opened/read, or a syntax error was discovered in the file
Press any key to exit.
after enabling logging (-l out.log) a bit more is revealed:
# tail -n 2 out.log
Error: Config file line 2: Not supported config file version.
Error: Missing CONFIG VERSION parameter in configuration file.
but that's not entirely true, CONFIG VERSION is set in the default
configuration file:
# head -n 2 nvmupdate.cfg
CURRENT FAMILY: 1.0.0
CONFIG VERSION: 1.14.0
so why isn't this understood?
Manually editing nvmupdate.cfg and setting CONFIG VERSION: 1.11.0 seems
to make this particular problem go away.
b) Re-doing this with downgraded config version exposes another problem:
Config file read.
Error: Can't open NVM map file [Immediate_offset_2.txt]
and indeed, there is no Immediate_offset_2.txt in
NVMUpdatePackage_WFT_WFQ&WF0_v4.00/X722_NVMUpdate_Linux_x64/
There is one, however, in
NVMUpdatePackage_WFT_WFQ&WF0_v4.00/X722_NVMUpdate_EFIx64/ subdir.
Copying it over to the _Linux_x64 resolves this particular problem
c) Re-doing this with Immediate_offset_2.txt in place exposes third problem:
Error: Can't open NVM image file
[LBG_B2_Wolf_Pass_WFT_X557_P01_PHY_Auto_Detect_P23_NCSI_v3.31_800016DB.bin]
and once again - same story. It exists in
NVMUpdatePackage_WFT_WFQ&WF0_v4.00/X722_NVMUpdate_EFIx64/ but not
NVMUpdatePackage_WFT_WFQ&WF0_v4.00/X722_NVMUpdate_Linux_x64/ - had to
copy it over.
Once I managed to get all these out of the way, the tool finally ran:
Num Description Ver. DevId S:B Status
=== ======================================== ===== ===== ======
===============
01) Intel(R) Ethernet Server Adapter I350-T4 1.99 1521 00:024
Update not
available
02) Intel(R) Ethernet Connection X722 for 3.49 37D2 00:061 Update
10GBASE-T available
03) Intel(R) Ethernet Server Adapter I350-T4 1.99 1521 00:175
Update not
available
The initial starting point was:
0) firmware-version: 3.31 0x80000d31 1.1767.0
After first update+reboot, this was bumped to:
1) firmware-version: 3.1d 0x800016db 1.1767.0 (but ethtool -m ethX
still doesn't work)
So I ran the tool the second time, it said 'Update available' again, but
this time:
Num Description Ver. DevId S:B Status
=== ======================================== ===== ===== ======
===============
01) Intel(R) Ethernet Server Adapter I350-T4 1.99 1521 00:024
Update not
available
02) Intel(R) Ethernet Connection X722 for 3.29 37D2 00:061 Update
10GBASE-T available
03) Intel(R) Ethernet Server Adapter I350-T4 1.99 1521 00:175
Update not
available
Options: Adapter Index List (comma-separated), [A]ll, e[X]it
Enter selection:02
Would you like to back up the NVM images? [Y]es/[N]o: Y
Update in progress. This operation may take several minutes.
[*******+..]
Tool execution completed with the following status: <---------- why
is there no status printed?
Press any key to exit.
Checking output log:
# cat out3.log
Intel(R) Ethernet NVM Update Tool
NVMUpdate version 1.30.2.11
Copyright (C) 2013 - 2017 Intel Corporation.
./nvmupdate64e -c nvmupdate.cfg -l out3.log
Config file read.
Inventory
[00:061:00:00]: Intel(R) Ethernet Connection X722 for 10GBASE-T
Flash inventory started
Shadow RAM inventory started
Alternate MAC address is not set
Shadow RAM inventory finished
Flash inventory finished
OROM inventory started
OROM inventory finished
PHY NVM inventory started
PHY NVM inventory finished
[00:061:00:01]: Intel(R) Ethernet Connection X722 for 10GBASE-T
Device already inventoried.
[00:061:00:02]: Intel(R) Ethernet Connection X722 for 10GbE SFP+
Device already inventoried.
PHY NVM inventory started
PHY NVM inventory finished
[00:061:00:03]: Intel(R) Ethernet Connection X722 for 10GbE SFP+
Device already inventoried.
Update
[00:061:00:00]: Intel(R) Ethernet Connection X722 for 10GBASE-T
Creating backup images in directory: A4BF0164884A
Backup images created.
Flash update started
NVM image verification started
Shadow RAM image verification started
Image differences found at offset 0x3AE [Device=0xF, Buffer=0x0] -
update required.
Error: Flash update failed
[00:061:00:02]: Intel(R) Ethernet Connection X722 for 10GbE SFP+
#
However, ethtool -i suggests that firmware was updated to:
2) firmware-version: 4.00 0x80001577 1.1580.0 <------- so it did
_something_ after all?
At this point, every subsequent attempt to run the NVM updater yields
the same results: an update is available, but attempting to apply it
fails with the same message in log.
And my initial issue still persists - ethtool -m <iface> still returns
"invalid argument" with "Module EEPROM memory read not supported. Please
update the NVM image" logged in dmesg.
How can I resolve this?
Cheers,
Jakub.
>
> Todd Fujinaka
> Software Application Engineer
> Datacenter Engineering Group
> Intel Corporation
> todd.fujinaka@intel.com
>
>
> -----Original Message-----
> From: Jakub Jankowski [mailto:shasta@toxcorp.com]
> Sent: Tuesday, August 27, 2019 4:03 AM
> To: e1000-devel@lists.sourceforge.net
> Cc: netdev@vger.kernel.org; shasta@toxcorp.com; mhemsley@open-systems.com
> Subject: [E1000-devel] SFP+ EEPROM readouts fail on X722 (ethtool -m: Invalid argument)
>
> Hi,
>
> We can't get SFP+ EEPROM readouts for X722 to work at all:
>
> # ethtool -m eth10
> Cannot get module EEPROM information: Invalid argument # dmesg | tail -n 1 [ 445.971974] i40e 0000:3d:00.3 eth10: Module EEPROM memory read not supported. Please update the NVM image.
> # lspci | grep 3d:00.3
> 3d:00.3 Ethernet controller: Intel Corporation Ethernet Connection X722 for 10GbE SFP+ (rev 09)
>
>
> We're running 4.19.65 kernel at the moment, testing using the newest out-of-tree Intel module
>
> # modinfo -F version i40e
> 2.9.21
>
> We also tried:
> - 4.19.65 with in-tree i40e (2.3.2-k)
> - stock Arch Linux (kernel 5.2.5, driver 2.8.20-k) and the results are the same, as shown above.
>
> # ethtool -i eth10
> driver: i40e
> version: 2.9.21
> firmware-version: 3.31 0x80000d31 1.1767.0
> expansion-rom-version:
> bus-info: 0000:3d:00.3
> supports-statistics: yes
> supports-test: yes
> supports-eeprom-access: yes
> supports-register-dump: yes
> supports-priv-flags: yes
> # dmidecode -s baseboard-manufacturer
> Intel Corporation
> # dmidecode -s baseboard-product-name
> S2600WFT
> # dmidecode -s baseboard-version
> H48104-853
>
> # lspci -vvv
> (...)
> 3d:00.3 Ethernet controller: Intel Corporation Ethernet Connection X722 for 10GbE SFP+ (rev 09)
> DeviceName: Intel PCH Integrated 10 Gigabit Ethernet Controller
> Subsystem: Intel Corporation Ethernet Connection X722 for 10GbE SFP+
> Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B- DisINTx+
> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
> Latency: 0, Cache Line Size: 32 bytes
> Interrupt: pin A routed to IRQ 112
> NUMA node: 0
> Region 0: Memory at ab000000 (64-bit, prefetchable) [size=16M]
> Region 3: Memory at b0000000 (64-bit, prefetchable) [size=32K]
> Expansion ROM at <ignored> [disabled]
> Capabilities: [40] Power Management version 3
> Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
> Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=1 PME-
> Capabilities: [50] MSI: Enable- Count=1/1 Maskable+ 64bit+
> Address: 0000000000000000 Data: 0000
> Masking: 00000000 Pending: 00000000
> Capabilities: [70] MSI-X: Enable+ Count=129 Masked-
> Vector table: BAR=3 offset=00000000
> PBA: BAR=3 offset=00001000
> Capabilities: [a0] Express (v2) Endpoint, MSI 00
> DevCap: MaxPayload 512 bytes, PhantFunc 0, Latency L0s <512ns, L1 <64us
> ExtTag+ AttnBtn- AttnInd- PwrInd- RBE+ FLReset+ SlotPowerLimit 0.000W
> DevCtl: CorrErr+ NonFatalErr+ FatalErr+ UnsupReq+
> RlxdOrd+ ExtTag+ PhantFunc- AuxPwr- NoSnoop- FLReset-
> MaxPayload 256 bytes, MaxReadReq 512 bytes
> DevSta: CorrErr+ NonFatalErr- FatalErr- UnsupReq+ AuxPwr+ TransPend-
> LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Exit Latency L0s <64ns, L1 <1us
> ClockPM- Surprise- LLActRep- BwNot- ASPMOptComp+
> LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- CommClk+
> ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
> LnkSta: Speed 2.5GT/s (ok), Width x1 (ok)
> TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
> DevCap2: Completion Timeout: Range AB, TimeoutDis+, LTR-, OBFF Not Supported
> AtomicOpsCap: 32bit- 64bit- 128bitCAS-
> DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR-, OBFF Disabled
> AtomicOpsCtl: ReqEn-
> LnkSta2: Current De-emphasis Level: -6dB, EqualizationComplete-, EqualizationPhase1-
> EqualizationPhase2-, EqualizationPhase3-, LinkEqualizationRequest-
> Capabilities: [e0] Vital Product Data
> Product Name: Example VPD
> Read-only fields:
> [V0] Vendor specific:
> [RV] Reserved: checksum good, 0 byte(s) reserved
> End
> Capabilities: [100 v2] Advanced Error Reporting
> UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
> UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq+ ACSViol-
> UESvrt: DLP+ SDES- TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
> CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- AdvNonFatalErr+
> CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- AdvNonFatalErr+
> AERCap: First Error Pointer: 00, ECRCGenCap+ ECRCGenEn- ECRCChkCap+ ECRCChkEn-
> MultHdrRecCap- MultHdrRecEn- TLPPfxPres- HdrLogCap-
> HeaderLog: 00000000 00000000 00000000 00000000
> Capabilities: [150 v1] Alternative Routing-ID Interpretation (ARI)
> ARICap: MFVC- ACS-, Next Function: 0
> ARICtl: MFVC- ACS-, Function Group: 0
> Capabilities: [160 v1] Single Root I/O Virtualization (SR-IOV)
> IOVCap: Migration-, Interrupt Message Number: 000
> IOVCtl: Enable- Migration- Interrupt- MSE- ARIHierarchy-
> IOVSta: Migration-
> Initial VFs: 32, Total VFs: 32, Number of VFs: 0, Function Dependency Link: 03
> VF offset: 109, stride: 1, Device ID: 37cd
> Supported Page Size: 00000553, System Page Size: 00000001
> Region 0: Memory at 00000000af000000 (64-bit, prefetchable)
> Region 3: Memory at 00000000b0020000 (64-bit, prefetchable)
> VF Migration: offset: 00000000, BIR: 0
> Capabilities: [1a0 v1] Transaction Processing Hints
> Device specific mode supported
> No steering table available
> Capabilities: [1b0 v1] Access Control Services
> ACSCap: SrcValid- TransBlk- ReqRedir- CmpltRedir- UpstreamFwd- EgressCtrl- DirectTrans-
> ACSCtl: SrcValid- TransBlk- ReqRedir- CmpltRedir- UpstreamFwd- EgressCtrl- DirectTrans-
> Kernel driver in use: i40e
> Kernel modules: i40e
>
>
> Same kernel+i40e, same SFP+ module - but on Intel X710, works like a treat:
>
> # lspci | grep X7
> 81:00.0 Ethernet controller: Intel Corporation Ethernet Controller X710 for 10GbE SFP+ (rev 01)
> 81:00.1 Ethernet controller: Intel Corporation Ethernet Controller X710 for 10GbE SFP+ (rev 01) # ethtool -m eth8
> Identifier : 0x03 (SFP)
> Extended identifier : 0x04 (GBIC/SFP defined by 2-wire interface ID)
> Connector : 0x07 (LC)
> Transceiver codes : 0x10 0x00 0x00 0x01 0x00 0x00 0x00 0x00 0x00
> Transceiver type : 10G Ethernet: 10G Base-SR
> Transceiver type : Ethernet: 1000BASE-SX
> Encoding : 0x06 (64B/66B)
> BR, Nominal : 10300MBd
> (...)
> # ethtool -i eth8
> driver: i40e
> version: 2.9.21
> firmware-version: 6.01 0x800035cf 1.1876.0
> expansion-rom-version:
> bus-info: 0000:81:00.0
> supports-statistics: yes
> supports-test: yes
> supports-eeprom-access: yes
> supports-register-dump: yes
> supports-priv-flags: yes
> #
>
>
> Is this a known problem?
>
>
> Best regards,
> Jakub
>
>
>
> _______________________________________________
> E1000-devel mailing list
> E1000-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/e1000-devel
> To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
^ permalink raw reply
* Re: [PATCH bpf-next] selftests/bpf: remove wrong nhoff in flow dissector test
From: Daniel Borkmann @ 2019-08-27 22:44 UTC (permalink / raw)
To: Stanislav Fomichev, netdev, bpf; +Cc: davem, ast
In-Reply-To: <20190826222712.171177-1-sdf@google.com>
On 8/27/19 12:27 AM, Stanislav Fomichev wrote:
> .nhoff = 0 is (correctly) reset to ETH_HLEN on the next line so let's
> drop it.
>
> Signed-off-by: Stanislav Fomichev <sdf@google.com>
Applied, thanks!
^ permalink raw reply
* Re: [PATCH bpf-next v3 0/4] selftests/bpf: test_progs: misc fixes
From: Daniel Borkmann @ 2019-08-27 22:44 UTC (permalink / raw)
To: Stanislav Fomichev, netdev, bpf; +Cc: davem, ast, Andrii Nakryiko
In-Reply-To: <20190821234427.179886-1-sdf@google.com>
On 8/22/19 1:44 AM, Stanislav Fomichev wrote:
> * add test__skip to indicate skipped tests
> * remove global success/error counts (use environment)
> * remove asserts from the tests
> * remove unused ret from send_signal test
>
> v3:
> * QCHECK -> CHECK_FAIL (Daniel Borkmann)
>
> v2:
> * drop patch that changes output to keep consistent with test_verifier
> (Alexei Starovoitov)
> * QCHECK instead of test__fail (Andrii Nakryiko)
> * test__skip count number of subtests (Andrii Nakryiko)
>
> Cc: Andrii Nakryiko <andriin@fb.com>
Applied, thanks!
^ permalink raw reply
* Re: [PATCH bpf-next 0/4] bpf: precision tracking tests
From: Daniel Borkmann @ 2019-08-27 22:43 UTC (permalink / raw)
To: Alexei Starovoitov, davem; +Cc: netdev, bpf, kernel-team
In-Reply-To: <20190823055215.2658669-1-ast@kernel.org>
On 8/23/19 7:52 AM, Alexei Starovoitov wrote:
> Add few additional tests for precision tracking in the verifier.
>
> Alexei Starovoitov (4):
> bpf: introduce verifier internal test flag
> tools/bpf: sync bpf.h
> selftests/bpf: verifier precise tests
> selftests/bpf: add precision tracking test
>
> include/linux/bpf_verifier.h | 1 +
> include/uapi/linux/bpf.h | 3 +
> kernel/bpf/syscall.c | 1 +
> kernel/bpf/verifier.c | 5 +-
> tools/include/uapi/linux/bpf.h | 3 +
> tools/testing/selftests/bpf/test_verifier.c | 68 +++++++--
> .../testing/selftests/bpf/verifier/precise.c | 142 ++++++++++++++++++
> 7 files changed, 211 insertions(+), 12 deletions(-)
> create mode 100644 tools/testing/selftests/bpf/verifier/precise.c
>
Applied, thanks!
^ permalink raw reply
* Re: libbpf distro packaging
From: Julia Kartseva @ 2019-08-27 22:30 UTC (permalink / raw)
To: Jiri Olsa, Alexei Starovoitov
Cc: Andrii Nakryiko, labbott@redhat.com, acme@kernel.org,
debian-kernel@lists.debian.org, netdev@vger.kernel.org,
Andrey Ignatov, Yonghong Song, jolsa@kernel.org, Daniel Borkmann
In-Reply-To: <20190826064235.GA17554@krava>
On 8/25/19, 11:42 PM, "Jiri Olsa" <jolsa@redhat.com> wrote:
> On Fri, Aug 23, 2019 at 04:00:01PM +0000, Alexei Starovoitov wrote:
> >
> > Technically we can bump it at any time.
> > The goal was to bump it only when new kernel is released
> > to capture a collection of new APIs in a given 0.0.X release.
> > So that libbpf versions are synchronized with kernel versions
> > in some what loose way.
> > In this case we can make an exception and bump it now.
>
> I see, I dont think it's worth of the exception now,
> the patch is simple or we'll start with 0.0.3
PR introducing 0.0.5 ABI was merged:
https://github.com/libbpf/libbpf/commit/476e158
Jiri, you'd like to avoid patching, you can start w/ 0.0.5.
Also if you're planning to use *.spec from libbpf as a source of truth,
It may be enhanced by syncing spec and ABI versions, similar to
https://github.com/libbpf/libbpf/commit/d60f568
^ permalink raw reply
* Re: [PATCH net-next v2 2/3] dt-bindings: net: dsa: mt7530: Add support for port 5
From: Rob Herring @ 2019-08-27 22:22 UTC (permalink / raw)
To: René van Dorst
Cc: Sean Wang, Andrew Lunn, Vivien Didelot, Florian Fainelli,
David S . Miller, Matthias Brugger, netdev, linux-arm-kernel,
linux-mediatek, John Crispin, linux-mips, Frank Wunderlich,
devicetree
In-Reply-To: <20190821144547.15113-3-opensource@vdorst.com>
On Wed, Aug 21, 2019 at 04:45:46PM +0200, René van Dorst wrote:
> MT7530 port 5 has many modes/configurations.
> Update the documentation how to use port 5.
>
> Signed-off-by: René van Dorst <opensource@vdorst.com>
> Cc: devicetree@vger.kernel.org
> Cc: Rob Herring <robh@kernel.org>
> v1->v2:
> * Adding extra note about RGMII2 and gpio use.
> rfc->v1:
> * No change
The changelog goes below the '---'
> ---
> .../devicetree/bindings/net/dsa/mt7530.txt | 218 ++++++++++++++++++
> 1 file changed, 218 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/net/dsa/mt7530.txt b/Documentation/devicetree/bindings/net/dsa/mt7530.txt
> index 47aa205ee0bd..43993aae3f9c 100644
> --- a/Documentation/devicetree/bindings/net/dsa/mt7530.txt
> +++ b/Documentation/devicetree/bindings/net/dsa/mt7530.txt
> @@ -35,6 +35,42 @@ Required properties for the child nodes within ports container:
> - phy-mode: String, must be either "trgmii" or "rgmii" for port labeled
> "cpu".
>
> +Port 5 of the switch is muxed between:
> +1. GMAC5: GMAC5 can interface with another external MAC or PHY.
> +2. PHY of port 0 or port 4: PHY interfaces with an external MAC like 2nd GMAC
> + of the SOC. Used in many setups where port 0/4 becomes the WAN port.
> + Note: On a MT7621 SOC with integrated switch: 2nd GMAC can only connected to
> + GMAC5 when the gpios for RGMII2 (GPIO 22-33) are not used and not
> + connected to external component!
> +
> +Port 5 modes/configurations:
> +1. Port 5 is disabled and isolated: An external phy can interface to the 2nd
> + GMAC of the SOC.
> + In the case of a build-in MT7530 switch, port 5 shares the RGMII bus with 2nd
> + GMAC and an optional external phy. Mind the GPIO/pinctl settings of the SOC!
> +2. Port 5 is muxed to PHY of port 0/4: Port 0/4 interfaces with 2nd GMAC.
> + It is a simple MAC to PHY interface, port 5 needs to be setup for xMII mode
> + and RGMII delay.
> +3. Port 5 is muxed to GMAC5 and can interface to an external phy.
> + Port 5 becomes an extra switch port.
> + Only works on platform where external phy TX<->RX lines are swapped.
> + Like in the Ubiquiti ER-X-SFP.
> +4. Port 5 is muxed to GMAC5 and interfaces with the 2nd GAMC as 2nd CPU port.
> + Currently a 2nd CPU port is not supported by DSA code.
> +
> +Depending on how the external PHY is wired:
> +1. normal: The PHY can only connect to 2nd GMAC but not to the switch
> +2. swapped: RGMII TX, RX are swapped; external phy interface with the switch as
> + a ethernet port. But can't interface to the 2nd GMAC.
> +
> +Based on the DT the port 5 mode is configured.
> +
> +Driver tries to lookup the phy-handle of the 2nd GMAC of the master device.
> +When phy-handle matches PHY of port 0 or 4 then port 5 set-up as mode 2.
> +phy-mode must be set, see also example 2 below!
> + * mt7621: phy-mode = "rgmii-txid";
> + * mt7623: phy-mode = "rgmii";
> +
> See Documentation/devicetree/bindings/net/dsa/dsa.txt for a list of additional
> required, optional properties and how the integrated switch subnodes must
> be specified.
> @@ -94,3 +130,185 @@ Example:
> };
> };
> };
> +
> +Example 2: MT7621: Port 4 is WAN port: 2nd GMAC -> Port 5 -> PHY port 4.
> +
> +ð {
> + status = "okay";
Don't show status in examples.
This should show the complete node.
> +
> + gmac0: mac@0 {
> + compatible = "mediatek,eth-mac";
> + reg = <0>;
> + phy-mode = "rgmii";
> +
> + fixed-link {
> + speed = <1000>;
> + full-duplex;
> + pause;
> + };
> + };
> +
> + gmac1: mac@1 {
> + compatible = "mediatek,eth-mac";
> + reg = <1>;
> + phy-mode = "rgmii-txid";
> + phy-handle = <&phy4>;
> + };
> +
> + mdio: mdio-bus {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + /* Internal phy */
> + phy4: ethernet-phy@4 {
> + reg = <4>;
> + };
> +
> + mt7530: switch@1f {
> + compatible = "mediatek,mt7621";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0x1f>;
> + pinctrl-names = "default";
> + mediatek,mcm;
> +
> + resets = <&rstctrl 2>;
> + reset-names = "mcm";
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> + label = "lan0";
> + };
> +
> + port@1 {
> + reg = <1>;
> + label = "lan1";
> + };
> +
> + port@2 {
> + reg = <2>;
> + label = "lan2";
> + };
> +
> + port@3 {
> + reg = <3>;
> + label = "lan3";
> + };
> +
> +/* Commented out. Port 4 is handled by 2nd GMAC.
> + port@4 {
> + reg = <4>;
> + label = "lan4";
> + };
> +*/
> +
> + cpu_port0: port@6 {
> + reg = <6>;
> + label = "cpu";
> + ethernet = <&gmac0>;
> + phy-mode = "rgmii";
> +
> + fixed-link {
> + speed = <1000>;
> + full-duplex;
> + pause;
> + };
> + };
> + };
> + };
> + };
> +};
> +
> +Example 3: MT7621: Port 5 is connected to external PHY: Port 5 -> external PHY.
> +
> +ð {
> + status = "okay";
> +
> + gmac0: mac@0 {
> + compatible = "mediatek,eth-mac";
> + reg = <0>;
> + phy-mode = "rgmii";
> +
> + fixed-link {
> + speed = <1000>;
> + full-duplex;
> + pause;
> + };
> + };
> +
> + mdio: mdio-bus {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + /* External phy */
> + ephy5: ethernet-phy@7 {
> + reg = <7>;
> + };
> +
> + mt7530: switch@1f {
> + compatible = "mediatek,mt7621";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0x1f>;
> + pinctrl-names = "default";
> + mediatek,mcm;
> +
> + resets = <&rstctrl 2>;
> + reset-names = "mcm";
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> + label = "lan0";
> + };
> +
> + port@1 {
> + reg = <1>;
> + label = "lan1";
> + };
> +
> + port@2 {
> + reg = <2>;
> + label = "lan2";
> + };
> +
> + port@3 {
> + reg = <3>;
> + label = "lan3";
> + };
> +
> + port@4 {
> + reg = <4>;
> + label = "lan4";
> + };
> +
> + port@5 {
> + reg = <5>;
> + label = "lan5";
> + phy-mode = "rgmii";
> + phy-handle = <&ephy5>;
> + };
> +
> + cpu_port0: port@6 {
> + reg = <6>;
> + label = "cpu";
> + ethernet = <&gmac0>;
> + phy-mode = "rgmii";
> +
> + fixed-link {
> + speed = <1000>;
> + full-duplex;
> + pause;
> + };
> + };
> + };
> + };
> + };
> +};
> --
> 2.20.1
>
^ permalink raw reply
* Re: [Patch net] net_sched: fix a NULL pointer deref in ipt action
From: David Miller @ 2019-08-27 22:06 UTC (permalink / raw)
To: xiyou.wangcong; +Cc: netdev, itugrok, jhs, jiri
In-Reply-To: <20190825170132.31174-1-xiyou.wangcong@gmail.com>
From: Cong Wang <xiyou.wangcong@gmail.com>
Date: Sun, 25 Aug 2019 10:01:32 -0700
> The net pointer in struct xt_tgdtor_param is not explicitly
> initialized therefore is still NULL when dereferencing it.
> So we have to find a way to pass the correct net pointer to
> ipt_destroy_target().
>
> The best way I find is just saving the net pointer inside the per
> netns struct tcf_idrinfo, which could make this patch smaller.
>
> Fixes: 0c66dc1ea3f0 ("netfilter: conntrack: register hooks in netns when needed by ruleset")
> Reported-and-tested-by: itugrok@yahoo.com
> Cc: Jamal Hadi Salim <jhs@mojatatu.com>
> Cc: Jiri Pirko <jiri@resnulli.us>
> Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH v2] bonding: force enable lacp port after link state recovery for 802.3ad
From: David Miller @ 2019-08-27 22:04 UTC (permalink / raw)
To: zhangsha.zhang
Cc: j.vosburgh, vfalico, andy, netdev, linux-kernel, yuehaibing,
hunongda, alex.chen
In-Reply-To: <20190823034209.14596-1-zhangsha.zhang@huawei.com>
From: <zhangsha.zhang@huawei.com>
Date: Fri, 23 Aug 2019 11:42:09 +0800
> - If speed/duplex getting failed here, the link status
> will be changed to BOND_LINK_FAIL;
How does it fail at this step? I suspect this is a driver specific
problem.
^ permalink raw reply
* Re: [PATCH net-next v5] sched: Add dualpi2 qdisc
From: David Miller @ 2019-08-27 22:03 UTC (permalink / raw)
To: olivier.tilmans
Cc: eric.dumazet, stephen, olga, koen.de_schepper, research, henrist,
jhs, xiyou.wangcong, jiri, linux-kernel, netdev
In-Reply-To: <20190822080045.27609-1-olivier.tilmans@nokia-bell-labs.com>
From: "Tilmans, Olivier (Nokia - BE/Antwerp)" <olivier.tilmans@nokia-bell-labs.com>
Date: Thu, 22 Aug 2019 08:10:48 +0000
> +static inline struct dualpi2_skb_cb *dualpi2_skb_cb(struct sk_buff *skb)
Please do not use the inline keyword in foo.c files, let the compiler decide.
> +static struct sk_buff *dualpi2_qdisc_dequeue(struct Qdisc *sch)
> +{
> + struct dualpi2_sched_data *q = qdisc_priv(sch);
> + struct sk_buff *skb;
> + int qlen_c, credit_change;
Reverse christmas tree here, please.
> +static void dualpi2_timer(struct timer_list *timer)
> +{
> + struct dualpi2_sched_data *q = from_timer(q, timer, pi2.timer);
> + struct Qdisc *sch = q->sch;
> + spinlock_t *root_lock; /* Lock to access the head of both queues. */
Likewise, and please remove this comment it makes the variable declarations
look odd.
^ permalink raw reply
* Re: [PATCH v2 net] Add genphy_c45_config_aneg() function to phy-c45.c
From: David Miller @ 2019-08-27 22:01 UTC (permalink / raw)
To: marco.hartmann
Cc: andrew, f.fainelli, hkallweit1, netdev, linux-kernel,
christian.herber
In-Reply-To: <1566385208-23523-1-git-send-email-marco.hartmann@nxp.com>
From: Marco Hartmann <marco.hartmann@nxp.com>
Date: Wed, 21 Aug 2019 11:00:46 +0000
> Commit 34786005eca3 ("net: phy: prevent PHYs w/o Clause 22 regs from calling
> genphy_config_aneg") introduced a check that aborts phy_config_aneg()
> if the phy is a C45 phy.
> This causes phy_state_machine() to call phy_error() so that the phy
> ends up in PHY_HALTED state.
>
> Instead of returning -EOPNOTSUPP, call genphy_c45_config_aneg()
> (analogous to the C22 case) so that the state machine can run
> correctly.
>
> genphy_c45_config_aneg() closely resembles mv3310_config_aneg()
> in drivers/net/phy/marvell10g.c, excluding vendor specific
> configurations for 1000BaseT.
>
> Fixes: 22b56e827093 ("net: phy: replace genphy_10g_driver with genphy_c45_driver")
>
> Signed-off-by: Marco Hartmann <marco.hartmann@nxp.com>
Andrew, gentle ping to respond to Heiner who said:
> For me this patch would be ok, even though this generic config_aneg
> doesn't support 1000BaseT.
> 1. The whole genphy_c45 driver doesn't make sense w/o a config_aneg
> callback implementation.
> 2. It can serve as a temporary fallback for new C45 PHY's that don't
> have a dedicated driver yet.
> 3. We may have C45 PHYs not supporting 1000BaseT (e.g. T1).
>
> Andrew?
Thanks.
^ permalink raw reply
* Re: [PATCH] net/mlx5: fix a -Wstringop-truncation warning
From: Saeed Mahameed @ 2019-08-27 21:51 UTC (permalink / raw)
To: cai@lca.pw
Cc: linux-rdma@vger.kernel.org, davem@davemloft.net, Moshe Shemesh,
Feras Daoud, linux-kernel@vger.kernel.org, Eran Ben Elisha,
netdev@vger.kernel.org, leon@kernel.org
In-Reply-To: <1566590183-9898-1-git-send-email-cai@lca.pw>
On Fri, 2019-08-23 at 15:56 -0400, Qian Cai wrote:
> In file included from ./arch/powerpc/include/asm/paca.h:15,
> from ./arch/powerpc/include/asm/current.h:13,
> from ./include/linux/thread_info.h:21,
> from ./include/asm-generic/preempt.h:5,
> from
> ./arch/powerpc/include/generated/asm/preempt.h:1,
> from ./include/linux/preempt.h:78,
> from ./include/linux/spinlock.h:51,
> from ./include/linux/wait.h:9,
> from ./include/linux/completion.h:12,
> from ./include/linux/mlx5/driver.h:37,
> from
> drivers/net/ethernet/mellanox/mlx5/core/lib/eq.h:6,
> from
> drivers/net/ethernet/mellanox/mlx5/core/diag/fw_tracer.c:33:
> In function 'strncpy',
> inlined from 'mlx5_fw_tracer_save_trace' at
> drivers/net/ethernet/mellanox/mlx5/core/diag/fw_tracer.c:549:2,
> inlined from 'mlx5_tracer_print_trace' at
> drivers/net/ethernet/mellanox/mlx5/core/diag/fw_tracer.c:574:2:
> ./include/linux/string.h:305:9: warning: '__builtin_strncpy' output
> may
> be truncated copying 256 bytes from a string of length 511
> [-Wstringop-truncation]
> return __builtin_strncpy(p, q, size);
> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> Fix it by using the new strscpy_pad() since the commit 458a3bf82df4
> ("lib/string: Add strscpy_pad() function") which will always
> NUL-terminate the string, and avoid possibly leak data through the
> ring
> buffer where non-admin account might enable these events through
> perf.
>
> Fixes: fd1483fe1f9f ("net/mlx5: Add support for FW reporter dump")
> Signed-off-by: Qian Cai <cai@lca.pw>
>
Applied to mlx5-next, Thanks !
^ permalink raw reply
* Re: [PATCH net-next v2 3/3] dt-bindings: net: ethernet: Update mt7622 docs and dts to reflect the new phylink API
From: Rob Herring @ 2019-08-27 21:51 UTC (permalink / raw)
To: René van Dorst
Cc: John Crispin, Sean Wang, Nelson Chang, David S . Miller,
Matthias Brugger, netdev, linux-arm-kernel, linux-mediatek,
linux-mips, Frank Wunderlich, Stefan Roese, devicetree
In-Reply-To: <20190821144336.9259-4-opensource@vdorst.com>
On Wed, Aug 21, 2019 at 04:43:36PM +0200, René van Dorst wrote:
> This patch the removes the recently added mediatek,physpeed property.
> Use the fixed-link property speed = <2500> to set the phy in 2.5Gbit.
> See mt7622-bananapi-bpi-r64.dts for a working example.
>
> Signed-off-by: René van Dorst <opensource@vdorst.com>
> Cc: devicetree@vger.kernel.org
> Cc: Rob Herring <robh@kernel.org>
> --
> v1->v2:
> * SGMII port only support BASE-X at 2.5Gbit.
> ---
> .../arm/mediatek/mediatek,sgmiisys.txt | 2 --
Bindings and dts files should be separate patches.
> .../dts/mediatek/mt7622-bananapi-bpi-r64.dts | 28 +++++++++++++------
> arch/arm64/boot/dts/mediatek/mt7622.dtsi | 1 -
> 3 files changed, 19 insertions(+), 12 deletions(-)
In any case,
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH] net/mlx5: fix a -Wstringop-truncation warning
From: Saeed Mahameed @ 2019-08-27 21:46 UTC (permalink / raw)
To: cai@lca.pw
Cc: linux-rdma@vger.kernel.org, davem@davemloft.net, Moshe Shemesh,
Feras Daoud, linux-kernel@vger.kernel.org, Eran Ben Elisha,
netdev@vger.kernel.org, leon@kernel.org
In-Reply-To: <1566936733.5576.16.camel@lca.pw>
On Tue, 2019-08-27 at 16:12 -0400, Qian Cai wrote:
> On Mon, 2019-08-26 at 21:11 +0000, Saeed Mahameed wrote:
> > On Fri, 2019-08-23 at 15:56 -0400, Qian Cai wrote:
> > > In file included from ./arch/powerpc/include/asm/paca.h:15,
> > > from ./arch/powerpc/include/asm/current.h:13,
> > > from ./include/linux/thread_info.h:21,
> > > from ./include/asm-generic/preempt.h:5,
> > > from
> > > ./arch/powerpc/include/generated/asm/preempt.h:1,
> > > from ./include/linux/preempt.h:78,
> > > from ./include/linux/spinlock.h:51,
> > > from ./include/linux/wait.h:9,
> > > from ./include/linux/completion.h:12,
> > > from ./include/linux/mlx5/driver.h:37,
> > > from
> > > drivers/net/ethernet/mellanox/mlx5/core/lib/eq.h:6,
> > > from
> > > drivers/net/ethernet/mellanox/mlx5/core/diag/fw_tracer.c:33:
> > > In function 'strncpy',
> > > inlined from 'mlx5_fw_tracer_save_trace' at
> > > drivers/net/ethernet/mellanox/mlx5/core/diag/fw_tracer.c:549:2,
> > > inlined from 'mlx5_tracer_print_trace' at
> > > drivers/net/ethernet/mellanox/mlx5/core/diag/fw_tracer.c:574:2:
> > > ./include/linux/string.h:305:9: warning: '__builtin_strncpy'
> > > output
> > > may
> > > be truncated copying 256 bytes from a string of length 511
> > > [-Wstringop-truncation]
> > > return __builtin_strncpy(p, q, size);
> > > ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > >
> > > Fix it by using the new strscpy_pad() since the commit
> > > 458a3bf82df4
> > > ("lib/string: Add strscpy_pad() function") which will always
> > > NUL-terminate the string, and avoid possibly leak data through
> > > the
> > > ring
> > > buffer where non-admin account might enable these events through
> > > perf.
> > >
> > > Fixes: fd1483fe1f9f ("net/mlx5: Add support for FW reporter
> > > dump")
> > > Signed-off-by: Qian Cai <cai@lca.pw>
> >
> > Hi Qian and thanks for your patch,
> >
> > We already have a patch that handles this issue, please check it
> > out:
> > https://git.kernel.org/pub/scm/linux/kernel/git/saeed/linux.git/commit/?h=net-
> > next-mlx5
> >
>
> That commit will make "struct mlx5_fw_tracer" too large and trigger a
> warning in
> __alloc_pages_nodemask(),
>
I see! thanks for the input, the patch is still under review and not
yet passed to regression queue.
I will take your patch.. and will fix our patch on top of yours.
> /*
> * There are several places where we assume that the order
> value is sane
> * so bail out early if the request is out of bound.
> */
> if (unlikely(order >= MAX_ORDER)) {
> WARN_ON_ONCE(!(gfp_mask & __GFP_NOWARN));
> return NULL;
> }
>
> [ 98.339576][ T914] WARNING: CPU: 0 PID: 914 at
> mm/page_alloc.c:4705
> __alloc_pages_nodemask+0x441/0x1bb0
> [ 98.349174][ T914] Modules linked in: smartpqi(+)
> scsi_transport_sas tg3
> mlx5_core(+) libphy firmware_class dm_mirror dm_region_hash dm_log
> dm_mod
> efivarfs
> [ 98.363495][ T914] CPU: 0 PID: 914 Comm: kworker/0:2 Not tainted
> 5.3.0-rc6-
> next-20190827+ #14
> [ 98.372243][ T914] Hardware name: HPE ProLiant DL385
> Gen10/ProLiant DL385
> Gen10, BIOS A40 07/10/2019
> [ 98.381627][ T914] Workqueue: events work_for_cpu_fn
> [ 98.386720][ T914] RIP: 0010:__alloc_pages_nodemask+0x441/0x1bb0
> [ 98.392917][ T914] Code: 17 00 00 48 8d 65 d8 5b 41 5c 41 5d 41
> 5e 41 5f 5d
> c3 89 85 3c fe ff ff bb 01 00 00 00 e9 96 fd ff ff 81 e7 00 20 00 00
> 75 02 <0f>
> 0b 48 c7 85 50 fe ff ff 00 00 00 00 eb 82 31 d2 be 36 12 00 00
> [ 98.412740][ T914] RSP: 0018:ffff88853418f948 EFLAGS: 00010246
> [ 98.418704][ T914] RAX: 0000000000000000 RBX: ffffffff9571a860
> RCX:
> 1ffff110a6831f3e
> [ 98.426652][ T914] RDX: 0000000000000000 RSI: 000000000000000b
> RDI:
> 0000000000000000
> [ 98.434661][ T914] RBP: ffff88853418fb58 R08: ffffed1108808465
> R09:
> ffffed1108808465
> [ 98.442613][ T914] R10: ffffed1108808464 R11: ffff888844042323
> R12:
> 0000000000000000
> [ 98.450548][ T914] R13: 000000000000000b R14: 0000000000000000
> R15:
> 0000000000000001
> [ 98.458434][ T914] FS: 0000000000000000(0000)
> GS:ffff888844000000(0000)
> knlGS:0000000000000000
> [ 98.467350][ T914] CS: 0010 DS: 0000 ES: 0000 CR0:
> 0000000080050033
> [ 98.473911][ T914] CR2: 0000555c64680148 CR3: 0000000550412000
> CR4:
> 00000000003406b0
> [ 98.481838][ T914] Call Trace:
> [ 98.485011][ T914] ? find_next_bit+0x2c/0xa0
> [ 98.489490][ T914] ? __kasan_check_write+0x14/0x20
> [ 98.494506][ T914] ? graph_lock+0xb8/0x120
> [ 98.498811][ T914] ? __free_zapped_classes+0x740/0x740
> [ 98.504239][ T914] ? gfp_pfmemalloc_allowed+0xc0/0xc0
> [ 98.509504][ T914] ? __kasan_check_read+0x11/0x20
> [ 98.514443][ T914] ? register_lock_class+0x5ef/0x960
> [ 98.519624][ T914] ? rcu_read_lock_sched_held+0xac/0xe0
> [ 98.525152][ T914] ? rcu_read_lock_any_held.part.5+0x20/0x20
> [ 98.531130][ T914] ? find_next_bit+0x2c/0xa0
> [ 98.535610][ T914] alloc_pages_current+0x9c/0x110
> [ 98.540638][ T914] kmalloc_order+0x22/0x70
> [ 98.544943][ T914] kmalloc_order_trace+0x23/0x100
> [ 98.550072][ T914] mlx5_fw_tracer_create+0x51/0x870 [mlx5_core]
> [ 98.556213][ T914] ? __mutex_init+0x94/0xa0
> [ 98.560744][ T914] ? mlx5_init_rl_table+0x144/0x210 [mlx5_core]
> [ 98.566929][ T914] mlx5_load_one+0x199/0x980 [mlx5_core]
> [ 98.572637][ T914] init_one+0x494/0x760 [mlx5_core]
> [ 98.577771][ T914] ? mlx5_pci_resume+0xd0/0xd0 [mlx5_core]
> [ 98.583574][ T914] local_pci_probe+0x7a/0xc0
> [ 98.588054][ T914] ? pci_dma_configure+0xa0/0xa0
> [ 98.592938][ T914] work_for_cpu_fn+0x2e/0x50
> [ 98.597416][ T914] process_one_work+0x53b/0xa70
> [ 98.602220][ T914] ? pwq_dec_nr_in_flight+0x170/0x170
> [ 98.607485][ T914] ? move_linked_works+0x113/0x150
> [ 98.612497][ T914] worker_thread+0x363/0x5b0
> [ 98.616976][ T914] kthread+0x1df/0x200
> [ 98.620932][ T914] ? process_one_work+0xa70/0xa70
> [ 98.625847][ T914] ? kthread_park+0xd0/0xd0
> [ 98.630240][ T914] ret_from_fork+0x22/0x40
^ permalink raw reply
* Re: [PATCH v5 net-next 03/18] ionic: Add port management commands
From: Shannon Nelson @ 2019-08-27 21:44 UTC (permalink / raw)
To: Jakub Kicinski; +Cc: netdev, davem
In-Reply-To: <20190826213631.37b8f56d@cakuba.netronome.com>
On 8/26/19 9:36 PM, Jakub Kicinski wrote:
> On Mon, 26 Aug 2019 14:33:24 -0700, Shannon Nelson wrote:
>> The port management commands apply to the physical port
>> associated with the PCI device, which might be shared among
>> several logical interfaces.
>>
>> Signed-off-by: Shannon Nelson <snelson@pensando.io>
[...]
>> diff --git a/drivers/net/ethernet/pensando/ionic/ionic_dev.h b/drivers/net/ethernet/pensando/ionic/ionic_dev.h
>> index 30a5206bba4e..5b83f21af18a 100644
>> --- a/drivers/net/ethernet/pensando/ionic/ionic_dev.h
>> +++ b/drivers/net/ethernet/pensando/ionic/ionic_dev.h
>> @@ -122,6 +122,10 @@ struct ionic_dev {
>> struct ionic_intr __iomem *intr_ctrl;
>> u64 __iomem *intr_status;
>>
>> + u32 port_info_sz;
>> + struct ionic_port_info *port_info;
>> + dma_addr_t port_info_pa;
>> +
>> struct ionic_devinfo dev_info;
>> };
>>
>> @@ -140,4 +144,15 @@ void ionic_dev_cmd_identify(struct ionic_dev *idev, u8 ver);
>> void ionic_dev_cmd_init(struct ionic_dev *idev);
>> void ionic_dev_cmd_reset(struct ionic_dev *idev);
>>
>> +void ionic_dev_cmd_port_identify(struct ionic_dev *idev);
>> +void ionic_dev_cmd_port_init(struct ionic_dev *idev);
>> +void ionic_dev_cmd_port_reset(struct ionic_dev *idev);
>> +void ionic_dev_cmd_port_state(struct ionic_dev *idev, u8 state);
>> +void ionic_dev_cmd_port_speed(struct ionic_dev *idev, u32 speed);
>> +void ionic_dev_cmd_port_mtu(struct ionic_dev *idev, u32 mtu);
>> +void ionic_dev_cmd_port_autoneg(struct ionic_dev *idev, u8 an_enable);
>> +void ionic_dev_cmd_port_fec(struct ionic_dev *idev, u8 fec_type);
>> +void ionic_dev_cmd_port_pause(struct ionic_dev *idev, u8 pause_type);
>> +void ionic_dev_cmd_port_loopback(struct ionic_dev *idev, u8 loopback_mode);
> I don't think you call most of these functions in this patch.
No, but most get used in the ethtool code added a few patches later.
The port_mtu probably won't get used, so I can pull that out. The
port_loopback will get used when I add a loopback test, but I can pull
that out for now until that test is added.
>
>> #endif /* _IONIC_DEV_H_ */
>> diff --git a/drivers/net/ethernet/pensando/ionic/ionic_main.c b/drivers/net/ethernet/pensando/ionic/ionic_main.c
>> index f52eb6c50358..47928f184230 100644
>> --- a/drivers/net/ethernet/pensando/ionic/ionic_main.c
>> +++ b/drivers/net/ethernet/pensando/ionic/ionic_main.c
>> @@ -309,6 +309,92 @@ int ionic_reset(struct ionic *ionic)
>> return err;
>> }
>>
>> +int ionic_port_identify(struct ionic *ionic)
>> +{
>> + struct ionic_identity *ident = &ionic->ident;
>> + struct ionic_dev *idev = &ionic->idev;
>> + size_t sz;
>> + int err;
>> +
>> + mutex_lock(&ionic->dev_cmd_lock);
>> +
>> + ionic_dev_cmd_port_identify(idev);
>> + err = ionic_dev_cmd_wait(ionic, devcmd_timeout);
>> + if (!err) {
>> + sz = min(sizeof(ident->port), sizeof(idev->dev_cmd_regs->data));
>> + memcpy_fromio(&ident->port, &idev->dev_cmd_regs->data, sz);
>> + }
>> +
>> + mutex_unlock(&ionic->dev_cmd_lock);
>> +
>> + return err;
>> +}
>> +
>> +int ionic_port_init(struct ionic *ionic)
>> +{
>> + struct ionic_identity *ident = &ionic->ident;
>> + struct ionic_dev *idev = &ionic->idev;
>> + size_t sz;
>> + int err;
>> +
>> + if (idev->port_info)
>> + return 0;
>> +
>> + idev->port_info_sz = ALIGN(sizeof(*idev->port_info), PAGE_SIZE);
>> + idev->port_info = dma_alloc_coherent(ionic->dev, idev->port_info_sz,
>> + &idev->port_info_pa,
>> + GFP_KERNEL);
>> + if (!idev->port_info) {
>> + dev_err(ionic->dev, "Failed to allocate port info, aborting\n");
>> + return -ENOMEM;
>> + }
>> +
>> + sz = min(sizeof(ident->port.config), sizeof(idev->dev_cmd_regs->data));
>> +
>> + mutex_lock(&ionic->dev_cmd_lock);
>> +
>> + memcpy_toio(&idev->dev_cmd_regs->data, &ident->port.config, sz);
>> + ionic_dev_cmd_port_init(idev);
>> + err = ionic_dev_cmd_wait(ionic, devcmd_timeout);
>> +
>> + ionic_dev_cmd_port_state(&ionic->idev, IONIC_PORT_ADMIN_STATE_UP);
>> + (void)ionic_dev_cmd_wait(ionic, devcmd_timeout);
>> +
>> + mutex_unlock(&ionic->dev_cmd_lock);
>> + if (err) {
>> + dev_err(ionic->dev, "Failed to init port\n");
> The lifetime of port_info seems a little strange. Why is it left in
> place even if the command failed? Doesn't this leak memory?
>
>> + return err;
>> + }
>> +
>> + return 0;
> return err; work for both paths
>
>> +}
>> +
>> +int ionic_port_reset(struct ionic *ionic)
>> +{
>> + struct ionic_dev *idev = &ionic->idev;
>> + int err;
>> +
>> + if (!idev->port_info)
>> + return 0;
>> +
>> + mutex_lock(&ionic->dev_cmd_lock);
>> + ionic_dev_cmd_port_reset(idev);
>> + err = ionic_dev_cmd_wait(ionic, devcmd_timeout);
>> + mutex_unlock(&ionic->dev_cmd_lock);
>> + if (err) {
>> + dev_err(ionic->dev, "Failed to reset port\n");
>> + return err;
> Again, memory leak if command fails? (nothing frees port_info)
>
>> + }
>> +
>> + dma_free_coherent(ionic->dev, idev->port_info_sz,
>> + idev->port_info, idev->port_info_pa);
>> +
>> + idev->port_info = NULL;
>> + idev->port_info_pa = 0;
>> +
>> + return err;
> Well, with current code err can only be 0 at this point.
I'll revisit these bits.
sln
^ permalink raw reply
* Re: Unable to create htb tc classes more than 64K
From: Dave Taht @ 2019-08-27 21:41 UTC (permalink / raw)
To: Eric Dumazet
Cc: Cong Wang, Akshat Kakkar, Anton Danilov, NetFilter, lartc, netdev,
bloat
In-Reply-To: <48a3284b-e8ba-f169-6a2d-9611f8538f07@gmail.com>
On Tue, Aug 27, 2019 at 2:09 PM Eric Dumazet <eric.dumazet@gmail.com> wrote:
>
>
>
> On 8/27/19 10:53 PM, Dave Taht wrote:
> >
> > Although this is very cool, I think in this case the OP is being
> > a router, not server?
>
> This mechanism is generic. EDT has not been designed for servers only.
>
> One HTB class (with one associated qdisc per leaf) per rate limiter
> does not scale, and consumes a _lot_ more memory.
>
> We have abandoned HTB at Google for these reasons.
>
> Nice thing with EDT is that you can stack arbitrary number of rate limiters,
> and still keep a single queue (in FQ or another layer downstream)
There's a lot of nice things about EDT! I'd followed along on the
theory, timerwheels, virtual clocks, etc, and went
seeking ethernet hw that could do it (directly) on the low end and
came up empty - and doing anything with the concept required a
complete rethink on everything we were already doing in
wifi/fq_codel/cake ;(, and after we shipped cake in 4.19, I bought a
sailboat, and logged out for a while.
The biggest problem bufferbloat.net has left is more efficient inbound
shaping/policing on cheap hw.
I don't suppose you've solved that already? :puppy dog eyes:
Next year's version of openwrt we can maybe try to do something
coherent with EDT.
>
--
Dave Täht
CTO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-831-205-9740
^ permalink raw reply
* Re: [PATCH net] tcp: inherit timestamp on mtu probe
From: Eric Dumazet @ 2019-08-27 21:23 UTC (permalink / raw)
To: Willem de Bruijn; +Cc: netdev, David Miller, Jakub Kicinski
In-Reply-To: <CA+FuTSeVKSJHXY_LwJBiVreqm+MUSoJt+Dp3mdATKvB48DUz-g@mail.gmail.com>
On Tue, Aug 27, 2019 at 11:16 PM Willem de Bruijn
<willemdebruijn.kernel@gmail.com> wrote:
>
> On Tue, Aug 27, 2019 at 4:58 PM Eric Dumazet <edumazet@google.com> wrote:
> >
> > On Tue, Aug 27, 2019 at 10:54 PM Willem de Bruijn
> > <willemdebruijn.kernel@gmail.com> wrote:
> >
> > > Sure, that's more descriptive.
> > >
> > > One caveat, the function is exposed in a header, so it's a
> > > bit more churn. If you don't mind that, I'll send the v2.
> >
> > Oh right it is also used from tcp_shifted_skb() after Martin KaFai Lau fix ...
>
> Leave as is then?
Not a big deal really ;)
Signed-off-by: Eric Dumazet <edumazet@google.com>
^ permalink raw reply
* Re: [PATCH v5 net-next 02/18] ionic: Add hardware init and device commands
From: Shannon Nelson @ 2019-08-27 21:22 UTC (permalink / raw)
To: Jakub Kicinski; +Cc: netdev, davem
In-Reply-To: <20190826212404.77348857@cakuba.netronome.com>
On 8/26/19 9:24 PM, Jakub Kicinski wrote:
> On Mon, 26 Aug 2019 14:33:23 -0700, Shannon Nelson wrote:
>> The ionic device has a small set of PCI registers, including a
>> device control and data space, and a large set of message
>> commands.
>>
>> Signed-off-by: Shannon Nelson <snelson@pensando.io>
>> diff --git a/drivers/net/ethernet/pensando/ionic/Makefile b/drivers/net/ethernet/pensando/ionic/Makefile
>> index f174e8f7bce1..a23d58519c63 100644
>> --- a/drivers/net/ethernet/pensando/ionic/Makefile
>> +++ b/drivers/net/ethernet/pensando/ionic/Makefile
>> @@ -3,4 +3,5 @@
>>
>> obj-$(CONFIG_IONIC) := ionic.o
>>
>> -ionic-y := ionic_main.o ionic_bus_pci.o ionic_devlink.o
>> +ionic-y := ionic_main.o ionic_bus_pci.o ionic_devlink.o ionic_dev.o \
>> + ionic_debugfs.o
>> diff --git a/drivers/net/ethernet/pensando/ionic/ionic.h b/drivers/net/ethernet/pensando/ionic/ionic.h
>> index d40077161214..1f3c4a916849 100644
>> --- a/drivers/net/ethernet/pensando/ionic/ionic.h
>> +++ b/drivers/net/ethernet/pensando/ionic/ionic.h
>> @@ -4,6 +4,10 @@
>> #ifndef _IONIC_H_
>> #define _IONIC_H_
>>
>> +#include "ionic_if.h"
>> +#include "ionic_dev.h"
>> +#include "ionic_devlink.h"
>> +
>> #define IONIC_DRV_NAME "ionic"
>> #define IONIC_DRV_DESCRIPTION "Pensando Ethernet NIC Driver"
>> #define IONIC_DRV_VERSION "0.15.0-k"
>> @@ -17,10 +21,27 @@
>> #define IONIC_SUBDEV_ID_NAPLES_100_4 0x4001
>> #define IONIC_SUBDEV_ID_NAPLES_100_8 0x4002
>>
>> +#define devcmd_timeout 10
> nit: upper case?
Sure
>
>> struct ionic {
>> struct pci_dev *pdev;
>> struct device *dev;
>> struct devlink *dl;
>> + struct devlink_port dl_port;
> devlink_port is not used in this patch
I can move that to patch 09 where it gets used
>
>> + struct ionic_dev idev;
>> + struct mutex dev_cmd_lock; /* lock for dev_cmd operations */
>> + struct dentry *dentry;
>> + struct ionic_dev_bar bars[IONIC_BARS_MAX];
>> + unsigned int num_bars;
>> + struct ionic_identity ident;
>> };
>> + err = ionic_init(ionic);
>> + if (err) {
>> + dev_err(dev, "Cannot init device: %d, aborting\n", err);
>> + goto err_out_teardown;
>> + }
>> +
>> + err = ionic_devlink_register(ionic);
>> + if (err)
>> + dev_err(dev, "Cannot register devlink: %d\n", err);
>>
>> return 0;
>> +
>> +err_out_teardown:
>> + ionic_dev_teardown(ionic);
>> +err_out_unmap_bars:
>> + ionic_unmap_bars(ionic);
>> + pci_release_regions(pdev);
>> +err_out_pci_clear_master:
>> + pci_clear_master(pdev);
>> +err_out_pci_disable_device:
>> + pci_disable_device(pdev);
>> +err_out_debugfs_del_dev:
>> + ionic_debugfs_del_dev(ionic);
>> +err_out_clear_drvdata:
>> + mutex_destroy(&ionic->dev_cmd_lock);
>> + ionic_devlink_free(ionic);
>> +
>> + return err;
>> }
>>
>> static void ionic_remove(struct pci_dev *pdev)
>> {
>> struct ionic *ionic = pci_get_drvdata(pdev);
>>
>> + if (!ionic)
> How can this be NULL? Usually if this is NULL that means probe()
> failed but 'err' was not set properly. Perhaps WARN_ON() here?
Yes, pretty unlikely, but seems worth checking.
>
>> + return;
>> +
>> + ionic_devlink_unregister(ionic);
>> + ionic_reset(ionic);
>> + ionic_dev_teardown(ionic);
>> + ionic_unmap_bars(ionic);
>> + pci_release_regions(pdev);
>> + pci_clear_master(pdev);
>> + pci_disable_device(pdev);
>> + ionic_debugfs_del_dev(ionic);
>> + mutex_destroy(&ionic->dev_cmd_lock);
>> ionic_devlink_free(ionic);
>> }
>>
>> diff --git a/drivers/net/ethernet/pensando/ionic/ionic_dev.h b/drivers/net/ethernet/pensando/ionic/ionic_dev.h
>> new file mode 100644
>> index 000000000000..30a5206bba4e
>> --- /dev/null
>> +++ b/drivers/net/ethernet/pensando/ionic/ionic_dev.h
>> @@ -0,0 +1,143 @@
>> +/* SPDX-License-Identifier: GPL-2.0 */
>> +/* Copyright(c) 2017 - 2019 Pensando Systems, Inc */
>> +
>> +#ifndef _IONIC_DEV_H_
>> +#define _IONIC_DEV_H_
>> +
>> +#include <linux/mutex.h>
>> +#include <linux/workqueue.h>
>> +
>> +#include "ionic_if.h"
>> +#include "ionic_regs.h"
>> +
>> +struct ionic_dev_bar {
>> + void __iomem *vaddr;
>> + phys_addr_t bus_addr;
>> + unsigned long len;
>> + int res_index;
>> +};
>> +
>> +static inline void ionic_struct_size_checks(void)
>> +{
>> + /* Registers */
>> + BUILD_BUG_ON(sizeof(struct ionic_intr) != 32);
>> +
>> + BUILD_BUG_ON(sizeof(struct ionic_doorbell) != 8);
>> + BUILD_BUG_ON(sizeof(struct ionic_intr_status) != 8);
>> +
>> + BUILD_BUG_ON(sizeof(union ionic_dev_regs) != 4096);
>> + BUILD_BUG_ON(sizeof(union ionic_dev_info_regs) != 2048);
>> + BUILD_BUG_ON(sizeof(union ionic_dev_cmd_regs) != 2048);
>> +
>> + BUILD_BUG_ON(sizeof(struct ionic_lif_stats) != 1024);
>> +
>> + BUILD_BUG_ON(sizeof(struct ionic_admin_cmd) != 64);
>> + BUILD_BUG_ON(sizeof(struct ionic_admin_comp) != 16);
>> + BUILD_BUG_ON(sizeof(struct ionic_nop_cmd) != 64);
>> + BUILD_BUG_ON(sizeof(struct ionic_nop_comp) != 16);
>> +
>> + /* Device commands */
>> + BUILD_BUG_ON(sizeof(struct ionic_dev_identify_cmd) != 64);
>> + BUILD_BUG_ON(sizeof(struct ionic_dev_identify_comp) != 16);
>> + BUILD_BUG_ON(sizeof(struct ionic_dev_init_cmd) != 64);
>> + BUILD_BUG_ON(sizeof(struct ionic_dev_init_comp) != 16);
>> + BUILD_BUG_ON(sizeof(struct ionic_dev_reset_cmd) != 64);
>> + BUILD_BUG_ON(sizeof(struct ionic_dev_reset_comp) != 16);
>> + BUILD_BUG_ON(sizeof(struct ionic_dev_getattr_cmd) != 64);
>> + BUILD_BUG_ON(sizeof(struct ionic_dev_getattr_comp) != 16);
>> + BUILD_BUG_ON(sizeof(struct ionic_dev_setattr_cmd) != 64);
>> + BUILD_BUG_ON(sizeof(struct ionic_dev_setattr_comp) != 16);
>> +
>> + /* Port commands */
>> + BUILD_BUG_ON(sizeof(struct ionic_port_identify_cmd) != 64);
>> + BUILD_BUG_ON(sizeof(struct ionic_port_identify_comp) != 16);
>> + BUILD_BUG_ON(sizeof(struct ionic_port_init_cmd) != 64);
>> + BUILD_BUG_ON(sizeof(struct ionic_port_init_comp) != 16);
>> + BUILD_BUG_ON(sizeof(struct ionic_port_reset_cmd) != 64);
>> + BUILD_BUG_ON(sizeof(struct ionic_port_reset_comp) != 16);
>> + BUILD_BUG_ON(sizeof(struct ionic_port_getattr_cmd) != 64);
>> + BUILD_BUG_ON(sizeof(struct ionic_port_getattr_comp) != 16);
>> + BUILD_BUG_ON(sizeof(struct ionic_port_setattr_cmd) != 64);
>> + BUILD_BUG_ON(sizeof(struct ionic_port_setattr_comp) != 16);
>> +
>> + /* LIF commands */
>> + BUILD_BUG_ON(sizeof(struct ionic_lif_init_cmd) != 64);
>> + BUILD_BUG_ON(sizeof(struct ionic_lif_init_comp) != 16);
>> + BUILD_BUG_ON(sizeof(struct ionic_lif_reset_cmd) != 64);
>> + BUILD_BUG_ON(sizeof(ionic_lif_reset_comp) != 16);
>> + BUILD_BUG_ON(sizeof(struct ionic_lif_getattr_cmd) != 64);
>> + BUILD_BUG_ON(sizeof(struct ionic_lif_getattr_comp) != 16);
>> + BUILD_BUG_ON(sizeof(struct ionic_lif_setattr_cmd) != 64);
>> + BUILD_BUG_ON(sizeof(struct ionic_lif_setattr_comp) != 16);
>> +
>> + BUILD_BUG_ON(sizeof(struct ionic_q_init_cmd) != 64);
>> + BUILD_BUG_ON(sizeof(struct ionic_q_init_comp) != 16);
>> + BUILD_BUG_ON(sizeof(struct ionic_q_control_cmd) != 64);
>> + BUILD_BUG_ON(sizeof(ionic_q_control_comp) != 16);
>> +
>> + BUILD_BUG_ON(sizeof(struct ionic_rx_mode_set_cmd) != 64);
>> + BUILD_BUG_ON(sizeof(ionic_rx_mode_set_comp) != 16);
>> + BUILD_BUG_ON(sizeof(struct ionic_rx_filter_add_cmd) != 64);
>> + BUILD_BUG_ON(sizeof(struct ionic_rx_filter_add_comp) != 16);
>> + BUILD_BUG_ON(sizeof(struct ionic_rx_filter_del_cmd) != 64);
>> + BUILD_BUG_ON(sizeof(ionic_rx_filter_del_comp) != 16);
>> +
>> + /* RDMA commands */
>> + BUILD_BUG_ON(sizeof(struct ionic_rdma_reset_cmd) != 64);
>> + BUILD_BUG_ON(sizeof(struct ionic_rdma_queue_cmd) != 64);
>> +
>> + /* Events */
>> + BUILD_BUG_ON(sizeof(struct ionic_notifyq_cmd) != 4);
>> + BUILD_BUG_ON(sizeof(union ionic_notifyq_comp) != 64);
>> + BUILD_BUG_ON(sizeof(struct ionic_notifyq_event) != 64);
>> + BUILD_BUG_ON(sizeof(struct ionic_link_change_event) != 64);
>> + BUILD_BUG_ON(sizeof(struct ionic_reset_event) != 64);
>> + BUILD_BUG_ON(sizeof(struct ionic_heartbeat_event) != 64);
>> + BUILD_BUG_ON(sizeof(struct ionic_log_event) != 64);
>> +
>> + /* I/O */
>> + BUILD_BUG_ON(sizeof(struct ionic_txq_desc) != 16);
>> + BUILD_BUG_ON(sizeof(struct ionic_txq_sg_desc) != 128);
>> + BUILD_BUG_ON(sizeof(struct ionic_txq_comp) != 16);
>> +
>> + BUILD_BUG_ON(sizeof(struct ionic_rxq_desc) != 16);
>> + BUILD_BUG_ON(sizeof(struct ionic_rxq_sg_desc) != 128);
>> + BUILD_BUG_ON(sizeof(struct ionic_rxq_comp) != 16);
> static_assert() for all of those? That way you don't need this fake
> function.
Sure
>
>> +}
>> +
>> +struct ionic_devinfo {
>> + u8 asic_type;
>> + u8 asic_rev;
>> + char fw_version[IONIC_DEVINFO_FWVERS_BUFLEN + 1];
>> + char serial_num[IONIC_DEVINFO_SERIAL_BUFLEN + 1];
>> +};
>> +
>> +struct ionic_dev {
>> + union ionic_dev_info_regs __iomem *dev_info_regs;
>> + union ionic_dev_cmd_regs __iomem *dev_cmd_regs;
>> +
>> + u64 __iomem *db_pages;
>> + dma_addr_t phy_db_pages;
>> +
>> + struct ionic_intr __iomem *intr_ctrl;
>> + u64 __iomem *intr_status;
>> +
>> + struct ionic_devinfo dev_info;
>> +};
>> +
>> +struct ionic;
>> +
>> +void ionic_init_devinfo(struct ionic *ionic);
>> +int ionic_dev_setup(struct ionic *ionic);
>> +void ionic_dev_teardown(struct ionic *ionic);
>> +
>> +void ionic_dev_cmd_go(struct ionic_dev *idev, union ionic_dev_cmd *cmd);
>> +u8 ionic_dev_cmd_status(struct ionic_dev *idev);
>> +bool ionic_dev_cmd_done(struct ionic_dev *idev);
>> +void ionic_dev_cmd_comp(struct ionic_dev *idev, union ionic_dev_cmd_comp *comp);
>> +
>> +void ionic_dev_cmd_identify(struct ionic_dev *idev, u8 ver);
>> +void ionic_dev_cmd_init(struct ionic_dev *idev);
>> +void ionic_dev_cmd_reset(struct ionic_dev *idev);
>> +
>> +#endif /* _IONIC_DEV_H_ */
>> diff --git a/drivers/net/ethernet/pensando/ionic/ionic_devlink.c b/drivers/net/ethernet/pensando/ionic/ionic_devlink.c
>> index e24ef6971cd5..1ca1e33cca04 100644
>> --- a/drivers/net/ethernet/pensando/ionic/ionic_devlink.c
>> +++ b/drivers/net/ethernet/pensando/ionic/ionic_devlink.c
>> @@ -11,8 +11,28 @@
>> static int ionic_dl_info_get(struct devlink *dl, struct devlink_info_req *req,
>> struct netlink_ext_ack *extack)
>> {
>> + struct ionic *ionic = devlink_priv(dl);
>> + struct ionic_dev *idev = &ionic->idev;
>> + char buf[16];
>> +
>> devlink_info_driver_name_put(req, IONIC_DRV_NAME);
>>
>> + devlink_info_version_running_put(req,
>> + DEVLINK_INFO_VERSION_GENERIC_FW_MGMT,
>> + idev->dev_info.fw_version);
> Are you sure this is not the FW that controls the data path?
There is only one FW rev to report, and this covers mgmt and data.
>
>> + snprintf(buf, sizeof(buf), "0x%x", idev->dev_info.asic_type);
>> + devlink_info_version_fixed_put(req,
>> + DEVLINK_INFO_VERSION_GENERIC_BOARD_ID,
>> + buf);
> Board ID is not ASIC. This is for identifying a board version with all
> its components which surround the main ASIC.
>
>> + snprintf(buf, sizeof(buf), "0x%x", idev->dev_info.asic_rev);
>> + devlink_info_version_fixed_put(req,
>> + DEVLINK_INFO_VERSION_GENERIC_BOARD_REV,
>> + buf);
> ditto
Since I don't have any board info available at this point, shall I use
my own "asic.id" and "asic.rev" strings, or in this patch shall I add
something like this to devlink.h and use them here:
/* Part number, identifier of asic design */
#define DEVLINK_INFO_VERSION_GENERIC_ASIC_ID "asic.id"
/* Revision of asic design */
#define DEVLINK_INFO_VERSION_GENERIC_ASIC_REV "asic.rev"
>> + devlink_info_serial_number_put(req, idev->dev_info.serial_num);
>> +
>> return 0;
>> }
>>
>> @@ -41,3 +61,22 @@ void ionic_devlink_free(struct ionic *ionic)
>> {
>> devlink_free(ionic->dl);
>> }
>> +
>> +int ionic_devlink_register(struct ionic *ionic)
>> +{
>> + int err;
>> +
>> + err = devlink_register(ionic->dl, ionic->dev);
>> + if (err)
>> + dev_warn(ionic->dev, "devlink_register failed: %d\n", err);
>> +
>> + return err;
>> +}
>> +
>> +void ionic_devlink_unregister(struct ionic *ionic)
>> +{
>> + if (!ionic || !ionic->dl)
>> + return;
> Impossiblu
Sure.
Thanks,
sln
^ permalink raw reply
* Re: [PATCH net] ipv6: Default fib6_type to RTN_UNICAST when not set
From: David Miller @ 2019-08-27 21:21 UTC (permalink / raw)
To: dsahern; +Cc: Joakim.Tjernlund, netdev, greg, stable
In-Reply-To: <b644d367-53a3-c2cc-2a84-28a7caae480c@gmail.com>
From: David Ahern <dsahern@gmail.com>
Date: Tue, 27 Aug 2019 11:51:32 -0600
> Specific request is for commit c7036d97acd2527cef145b5ef9ad1a37ed21bbe6
> ("ipv6: Default fib6_type to RTN_UNICAST when not set") to be queued for
> stable releases prior to v5.2
Ok, I'll take care of this in my next round.
^ permalink raw reply
* Re: [PATCH v2 1/1] netfilter: nf_tables: fib: Drop IPV6 packages if IPv6 is disabled on boot
From: David Miller @ 2019-08-27 21:19 UTC (permalink / raw)
To: leonardo
Cc: pablo, netfilter-devel, coreteam, netdev, linux-kernel, kadlec,
fw, kuznet, yoshfuji
In-Reply-To: <77c43754ff72e9a2e8048ccd032351cf0186080a.camel@linux.ibm.com>
From: Leonardo Bras <leonardo@linux.ibm.com>
Date: Tue, 27 Aug 2019 14:34:14 -0300
> I could reproduce this bug on a host ('ipv6.disable=1') starting a
> guest with a virtio-net interface with 'filterref' over a virtual
> bridge. It crashes the host during guest boot (just before login).
>
> By that I could understand that a guest IPv6 network traffic
> (viavirtio-net) may cause this kernel panic.
Really this is bad and I suspected bridging to be involved somehow.
If ipv6 is disabled ipv6 traffic should not pass through the machine
by any means whatsoever. Otherwise there is no point to the knob
and we will keep having to add hack checks all over the tree instead
of fixing the fundamental issue.
^ permalink raw reply
* [PATCH net] net/sched: pfifo_fast: fix wrong dereference in pfifo_fast_enqueue
From: Davide Caratti @ 2019-08-27 21:18 UTC (permalink / raw)
To: Cong Wang, Jamal Hadi Salim, Jiri Pirko, David S. Miller, netdev
Cc: Paolo Abeni, Stefano Brivio, Li Shuang
Now that 'TCQ_F_CPUSTATS' bit can be cleared, depending on the value of
'TCQ_F_NOLOCK' bit in the parent qdisc, we can't assume anymore that
per-cpu counters are there in the error path of skb_array_produce().
Otherwise, the following splat can be seen:
Unable to handle kernel paging request at virtual address 0000600dea430008
Mem abort info:
ESR = 0x96000005
Exception class = DABT (current EL), IL = 32 bits
SET = 0, FnV = 0
EA = 0, S1PTW = 0
Data abort info:
ISV = 0, ISS = 0x00000005
CM = 0, WnR = 0
user pgtable: 64k pages, 48-bit VAs, pgdp = 000000007b97530e
[0000600dea430008] pgd=0000000000000000, pud=0000000000000000
Internal error: Oops: 96000005 [#1] SMP
[...]
pstate: 10000005 (nzcV daif -PAN -UAO)
pc : pfifo_fast_enqueue+0x524/0x6e8
lr : pfifo_fast_enqueue+0x46c/0x6e8
sp : ffff800d39376fe0
x29: ffff800d39376fe0 x28: 1ffff001a07d1e40
x27: ffff800d03e8f188 x26: ffff800d03e8f200
x25: 0000000000000062 x24: ffff800d393772f0
x23: 0000000000000000 x22: 0000000000000403
x21: ffff800cca569a00 x20: ffff800d03e8ee00
x19: ffff800cca569a10 x18: 00000000000000bf
x17: 0000000000000000 x16: 0000000000000000
x15: 0000000000000000 x14: ffff1001a726edd0
x13: 1fffe4000276a9a4 x12: 0000000000000000
x11: dfff200000000000 x10: ffff800d03e8f1a0
x9 : 0000000000000003 x8 : 0000000000000000
x7 : 00000000f1f1f1f1 x6 : ffff1001a726edea
x5 : ffff800cca56a53c x4 : 1ffff001bf9a8003
x3 : 1ffff001bf9a8003 x2 : 1ffff001a07d1dcb
x1 : 0000600dea430000 x0 : 0000600dea430008
Process ping (pid: 6067, stack limit = 0x00000000dc0aa557)
Call trace:
pfifo_fast_enqueue+0x524/0x6e8
htb_enqueue+0x660/0x10e0 [sch_htb]
__dev_queue_xmit+0x123c/0x2de0
dev_queue_xmit+0x24/0x30
ip_finish_output2+0xc48/0x1720
ip_finish_output+0x548/0x9d8
ip_output+0x334/0x788
ip_local_out+0x90/0x138
ip_send_skb+0x44/0x1d0
ip_push_pending_frames+0x5c/0x78
raw_sendmsg+0xed8/0x28d0
inet_sendmsg+0xc4/0x5c0
sock_sendmsg+0xac/0x108
__sys_sendto+0x1ac/0x2a0
__arm64_sys_sendto+0xc4/0x138
el0_svc_handler+0x13c/0x298
el0_svc+0x8/0xc
Code: f9402e80 d538d081 91002000 8b010000 (885f7c03)
Fix this by testing the value of 'TCQ_F_CPUSTATS' bit in 'qdisc->flags',
before dereferencing 'qdisc->cpu_qstats'.
Fixes: 8a53e616de29 ("net: sched: when clearing NOLOCK, clear TCQ_F_CPUSTATS, too")
CC: Paolo Abeni <pabeni@redhat.com>
CC: Stefano Brivio <sbrivio@redhat.com>
Reported-by: Li Shuang <shuali@redhat.com>
Signed-off-by: Davide Caratti <dcaratti@redhat.com>
---
net/sched/sch_generic.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/net/sched/sch_generic.c b/net/sched/sch_generic.c
index 099797e5409d..137db1cbde85 100644
--- a/net/sched/sch_generic.c
+++ b/net/sched/sch_generic.c
@@ -624,8 +624,12 @@ static int pfifo_fast_enqueue(struct sk_buff *skb, struct Qdisc *qdisc,
err = skb_array_produce(q, skb);
- if (unlikely(err))
- return qdisc_drop_cpu(skb, qdisc, to_free);
+ if (unlikely(err)) {
+ if (qdisc_is_percpu_stats(qdisc))
+ return qdisc_drop_cpu(skb, qdisc, to_free);
+ else
+ return qdisc_drop(skb, qdisc, to_free);
+ }
qdisc_update_stats_at_enqueue(qdisc, pkt_len);
return NET_XMIT_SUCCESS;
--
2.20.1
^ permalink raw reply related
* Re: [PATCH net] tcp: inherit timestamp on mtu probe
From: Willem de Bruijn @ 2019-08-27 21:15 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev, David Miller, Jakub Kicinski
In-Reply-To: <CANn89i++59nk_RFMOgor6XL3ZZY7t9QLa70sppKe6eQBrObagQ@mail.gmail.com>
On Tue, Aug 27, 2019 at 4:58 PM Eric Dumazet <edumazet@google.com> wrote:
>
> On Tue, Aug 27, 2019 at 10:54 PM Willem de Bruijn
> <willemdebruijn.kernel@gmail.com> wrote:
>
> > Sure, that's more descriptive.
> >
> > One caveat, the function is exposed in a header, so it's a
> > bit more churn. If you don't mind that, I'll send the v2.
>
> Oh right it is also used from tcp_shifted_skb() after Martin KaFai Lau fix ...
Leave as is then?
^ permalink raw reply
* Re: [PATCH -next] net: mlx5: Kconfig: Fix MLX5_CORE_EN dependencies
From: Saeed Mahameed @ 2019-08-27 21:15 UTC (permalink / raw)
To: wharms@bfs.de, maowenan@huawei.com
Cc: linux-rdma@vger.kernel.org, kernel-janitors@vger.kernel.org,
davem@davemloft.net, netdev@vger.kernel.org, leon@kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <092f56bf-3e94-a3b6-926c-da33ba26ee37@huawei.com>
On Tue, 2019-08-27 at 17:51 +0800, maowenan wrote:
>
> On 2019/8/27 15:24, walter harms wrote:
> >
> > Am 27.08.2019 05:12, schrieb Mao Wenan:
> > > When MLX5_CORE_EN=y and PCI_HYPERV_INTERFACE is not set, below
> > > errors are found:
> > > drivers/net/ethernet/mellanox/mlx5/core/en_main.o: In function
> > > `mlx5e_nic_enable':
> > > en_main.c:(.text+0xb649): undefined reference to
> > > `mlx5e_hv_vhca_stats_create'
> > > drivers/net/ethernet/mellanox/mlx5/core/en_main.o: In function
> > > `mlx5e_nic_disable':
> > > en_main.c:(.text+0xb8c4): undefined reference to
> > > `mlx5e_hv_vhca_stats_destroy'
> > >
> > > This because CONFIG_PCI_HYPERV_INTERFACE is newly introduced by
> > > 'commit 348dd93e40c1
> > > ("PCI: hv: Add a Hyper-V PCI interface driver for software
> > > backchannel interface"),
> > > Fix this by making MLX5_CORE_EN imply PCI_HYPERV_INTERFACE.
> > >
> > > Fixes: cef35af34d6d ("net/mlx5e: Add mlx5e HV VHCA stats agent")
> > > Signed-off-by: Mao Wenan <maowenan@huawei.com>
> > > ---
> > > drivers/net/ethernet/mellanox/mlx5/core/Kconfig | 1 +
> > > 1 file changed, 1 insertion(+)
> > >
> > > diff --git a/drivers/net/ethernet/mellanox/mlx5/core/Kconfig
> > > b/drivers/net/ethernet/mellanox/mlx5/core/Kconfig
> > > index 37fef8c..a6a70ce 100644
> > > --- a/drivers/net/ethernet/mellanox/mlx5/core/Kconfig
> > > +++ b/drivers/net/ethernet/mellanox/mlx5/core/Kconfig
> > > @@ -35,6 +35,7 @@ config MLX5_CORE_EN
> > > depends on IPV6=y || IPV6=n || MLX5_CORE=m
> >
> > OT but ...
> > is that IPV6 needed at all ? can there be something else that yes
> > or no ?
only needed for en_rep.c/en_tc.c which are only compiled when
MLX5_ESWITCH is selected, so actually such condition should be for
MLX5_ESWITCH and not MLX5_CORE_EN
tested with:
MLX5_CORE=y
MLX5_CORE_EN=y
IPV6=m
and removed the dependency.
so if ipv6 is a module but mlx5 is builtin this will happen..
ld: drivers/net/ethernet/mellanox/mlx5/core/en_rep.o: in function
`mlx5e_rep_neigh_update_init_interval':
/home/saeedm/devel/linux/drivers/net/ethernet/mellanox/mlx5/core/en_rep
.c:505: undefined reference to `nd_tbl'
ld: drivers/net/ethernet/mellanox/mlx5/core/en_rep.o: in function
`mlx5e_rep_netevent_event':
/home/saeedm/devel/linux/drivers/net/ethernet/mellanox/mlx5/core/en_rep
.c:946: undefined reference to `nd_tbl'
ld:
/home/saeedm/devel/linux/drivers/net/ethernet/mellanox/mlx5/core/en_rep
.c:919: undefined reference to `nd_tbl'
ld: drivers/net/ethernet/mellanox/mlx5/core/en_tc.o: in function
`mlx5e_tc_update_neigh_used_value':
/home/saeedm/devel/linux/drivers/net/ethernet/mellanox/mlx5/core/en_tc.
c:1497: undefined reference to `nd_tbl'
the problem is that mlx5_core can't be builtin if ipv6 is a module due
to this nd_tbl dependency
I think this is solvable by using ipv6_stub->nd_tbl, instead of
referencing md_tbl directly from mlx5.
>
> If I set IPV6=m, errors are found as below:
> drivers/net/ethernet/mellanox/mlx5/core/main.o: In function
> `mlx5_unload':
> main.c:(.text+0x275): undefined reference to `mlx5_hv_vhca_cleanup'
> drivers/net/ethernet/mellanox/mlx5/core/main.o: In function
> `mlx5_cleanup_once':
> main.c:(.text+0x2e8): undefined reference to `mlx5_hv_vhca_destroy'
> drivers/net/ethernet/mellanox/mlx5/core/main.o: In function
> `mlx5_load_one':
> main.c:(.text+0x23c1): undefined reference to `mlx5_hv_vhca_create'
> main.c:(.text+0x248f): undefined reference to `mlx5_hv_vhca_init'
> main.c:(.text+0x25e0): undefined reference to `mlx5_hv_vhca_cleanup
this is not related, i think there is something wrong with your local
repository.
^ permalink raw reply
* Re: Unable to create htb tc classes more than 64K
From: Eric Dumazet @ 2019-08-27 21:09 UTC (permalink / raw)
To: Dave Taht, Eric Dumazet
Cc: Cong Wang, Akshat Kakkar, Anton Danilov, NetFilter, lartc, netdev
In-Reply-To: <CAA93jw6TWUmqsvBDT4tFPgwjGxAmm_S5bUibj16nwp1F=AwyRA@mail.gmail.com>
On 8/27/19 10:53 PM, Dave Taht wrote:
>
> Although this is very cool, I think in this case the OP is being
> a router, not server?
This mechanism is generic. EDT has not been designed for servers only.
One HTB class (with one associated qdisc per leaf) per rate limiter
does not scale, and consumes a _lot_ more memory.
We have abandoned HTB at Google for these reasons.
Nice thing with EDT is that you can stack arbitrary number of rate limiters,
and still keep a single queue (in FQ or another layer downstream)
^ permalink raw reply
* RE: [PATCH 4/4] net: dsa: microchip: avoid hard-codded port count
From: Tristram.Ha @ 2019-08-27 21:03 UTC (permalink / raw)
To: Razvan.Stefanescu
Cc: netdev, linux-kernel, Razvan.Stefanescu, Woojung.Huh,
vivien.didelot, UNGLinuxDriver, andrew, f.fainelli, davem
In-Reply-To: <20190827093110.14957-5-razvan.stefanescu@microchip.com>
> Subject: [PATCH 4/4] net: dsa: microchip: avoid hard-codded port count
>
> Use port_cnt value to disable interrupts on switch reset.
>
> Signed-off-by: Razvan Stefanescu <razvan.stefanescu@microchip.com>
> ---
> drivers/net/dsa/microchip/ksz9477.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/dsa/microchip/ksz9477.c
> b/drivers/net/dsa/microchip/ksz9477.c
> index 187be42de5f1..54fc05595d48 100644
> --- a/drivers/net/dsa/microchip/ksz9477.c
> +++ b/drivers/net/dsa/microchip/ksz9477.c
> @@ -213,7 +213,7 @@ static int ksz9477_reset_switch(struct ksz_device
> *dev)
>
> /* disable interrupts */
> ksz_write32(dev, REG_SW_INT_MASK__4, SWITCH_INT_MASK);
> - ksz_write32(dev, REG_SW_PORT_INT_MASK__4, 0x7F);
> + ksz_write32(dev, REG_SW_PORT_INT_MASK__4, dev->port_cnt);
> ksz_read32(dev, REG_SW_PORT_INT_STATUS__4, &data32);
>
> /* set broadcast storm protection 10% rate */
The register value is a portmap, so using port_cnt may be wrong.
The chip is a 7-port switch. There is a 6-port variant, but it is okay to write 0x7F.
There is also a 3-port variant which uses a different design. It is a bit of stretch to use 0x7F on it.
It is more a code readability or correctness than incorrect hardware operation.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox