- 05 Jul, 2017 14 commits
-
-
Murali Karicheri authored
The data manual for DP83867IR/CR, SNLS484E[1], revised march 2017, advises that strapping RX_DV/RX_CTRL pin in mode 1 and 2 is not supported (see note below Table 5 (4-Level Strap Pins)). There are some boards which have the pin strapped this way and need software workaround suggested by the data manual. Bit[7] of Configuration Register 4 (address 0x0031) must be cleared to 0. This ensures proper operation of the PHY. Implement driver support for device-tree property meant to advertise the wrong strapping. [1] http://www.ti.com/lit/ds/snls484e/snls484e.pdfSigned-off-by:
Murali Karicheri <m-karicheri2@ti.com> [nsekhar@ti.com: rebase to mainline, code simplification] Signed-off-by:
Sekhar Nori <nsekhar@ti.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Murali Karicheri authored
The data manual for DP83867IR/CR, SNLS484E[1], revised march 2017, advises that strapping RX_DV/RX_CTRL pin in mode 1 and 2 is not supported (see note below Table 5 (4-Level Strap Pins)). It further advises that if a board has this pin strapped in mode 1 and mode 2, then to ensure proper operation of the PHY, a software workaround must be implemented. Since it is not possible to detect in software if RX_DV/RX_CTRL pin is incorrectly strapped, add a device-tree property for the board to advertise this and allow corrective action in software. [1] http://www.ti.com/lit/ds/snls484e/snls484e.pdfSigned-off-by:
-
David S. Miller authored
Atul Gupta says: ==================== cxgb4: Add PTP Hardware Clock (PHC) support V4: Splitting the patch again V3: Releasing lock in the exit paths V2: Splitting the patch ==================== Signed-off-by: -
Atul Gupta authored
Cc: Richard Cochran <richardcochran@gmail.com> Signed-off-by:
Atul Gupta <atul.gupta@chelsio.com> Signed-off-by:
Ganesh Goudar <ganeshgr@chelsio.com> Signed-off-by:
-
Atul Gupta authored
Add PTP IEEE-1588 support and make it accessible via PHC subsystem. The functionality is enabled for T5/T6 adapters. Driver interfaces with Firmware to program and adjust the clock offset. Cc: Richard Cochran <richardcochran@gmail.com> Signed-off-by:
-
Atul Gupta authored
Supports hardware and software time stamping via the Linux SO_TIMESTAMPING socket option. Cc: Richard Cochran <richardcochran@gmail.com> Signed-off-by:
-
David S. Miller authored
Jakub Kicinski says: ==================== nfp: port enumeration change and FW ABI adjustment This set changes the way ports are numbered internally to avoid MAC address changes and invalid link information when breakout is configured. Second patch gets rid of old way of looking up MAC addresses in device information which caused all this confusion. Patch 3 is a small adjustment to the new FW ABI version we introduced in this release cycle. ==================== Signed-off-by: -
Jakub Kicinski authored
ABI 4.x introduced the chained metadata format and made it the only one possible. There are cases, however, where the old format is preferred - mostly to make interoperation with VFs using ABI 3.x easier for the datapath. In ABI 5.x we allowed for more flexibility by selecting the metadata format based on capabilities. The default was left to non-chained. In case of fallback traffic, there is no capability telling the driver there may be chained metadata. With a very stripped- -down FW the default old metadata format would be selected making the driver drop all fallback traffic. This patch changes the default selection in the driver. It should not hurt with old firmwares, because if they don't advertise RSS they will not produce metadata anyway. New firmwares advertising ABI 5.x, however, can depend on the driver defaulting to chained format. Fixes: f9380629 ("nfp: advertise support for NFD ABI 0.5") Suggested-by:
Michael Rapson <michael.rapson@netronome.com> Signed-off-by:
Jakub Kicinski <jakub.kicinski@netronome.com> Signed-off-by:
-
Jakub Kicinski authored
The legacy MAC address lookup doesn't work well with breakout cables. We are probably better off picking random addresses than the wrong ones in the theoretical scenario where management FW didn't tell us what the port config is. Signed-off-by:
-
Jakub Kicinski authored
For historical reasons we enumerate the vNICs in order. This means that if user configures breakout on a multiport card, the first interface of the second port will have its MAC address changed. What's worse, when moved from static information (HWInfo) to using management FW (NSP), more features started depending on the port ids. Right now in case of breakout first subport of the second port and second subport of the first port will have their link info swapped. Revise the ordering scheme so that first subport maintains its address. Side effect of this change is that we will use base lane ids in devlink (i.e. 40G ports will be 4 ids apart), e.g.: pci/0000:04:00.0/0: type eth netdev p6p1 pci/0000:04:00.0/4: type eth netdev p6p2 Note that behaviour of phys_port_id is not changed since there is a separate id number for the subport there. Fixes: ec8b1fbe ("nfp: support port splitting via devlink") Signed-off-by:
-
Colin Ian King authored
When macro MACB_EXT_DESC is defined we end up with two identical return statements and just one is sufficient. Remove the extra return. Detected by CoverityScan, CID#1449361 ("Structurally dead code") Signed-off-by:Colin Ian King <colin.king@canonical.com> Acked-by:
Nicolas Ferre <nicolas.ferre@microchip.com> Signed-off-by:
-
Colin Ian King authored
There appears to be a missing break in the TCP_BPF_SNDCWND_CLAMP case. Currently the non-error path where val is greater than zero falls through to the default case that sets the error return to -EINVAL. Add in the missing break. Detected by CoverityScan, CID#1449376 ("Missing break in switch") Fixes: 13bf9641 ("bpf: Adds support for setting sndcwnd clamp") Signed-off-by:Daniel Borkmann <daniel@iogearbox.net> Acked-by:
Lawrence Brakmo <brakmo@fb.com> Signed-off-by:
-
Lawrence Brakmo authored
The function load_bpf_file ignores the return value of load_and_attach(), so even if load_and_attach() returns an error, load_bpf_file() will return 0. Now, load_bpf_file() can call load_and_attach() multiple times and some can succeed and some could fail. I think the correct behavor is to return error on the first failed load_and_attach(). v2: Added missing SOB Signed-off-by:
-
Roopa Prabhu authored
fix rtm policy name typo in mpls_getroute and also remove export of rtm_ipv4_policy Fixes: 397fc9e5 ("mpls: route get support") Reported-by:
Roopa Prabhu <roopa@cumulusnetworks.com> Signed-off-by:
-
- 04 Jul, 2017 26 commits
-
-
David S. Miller authored
Elena Reshetova says: ==================== v2 net subsystem misc refcounter conversions Changes in v2: * rebase on top of net-next * currently by default refcount_t = atomic_t (*) and uses all atomic standard operations unless CONFIG_REFCOUNT_FULL is enabled. This is a compromise for the systems that are critical on performance (such as net) and cannot accept even slight delay on the refcounter operations. This series, for various misc network components, replaces atomic_t reference counters with the new refcount_t type and API (see include/linux/refcount.h). By doing this we prevent intentional or accidental underflows or overflows that can led to use-after-free vulnerabilities. These are the last networking-related conversions with the exception of network drivers (to be send separately). Please excuse the long patch set, but seems like breaking it up won't save that much on CC list and most of the changes are trivial. The patches are fully independent and can be cherry-picked separately. In order to try with refcount functionality enabled in run-time, CONFIG_REFCOUNT_FULL must be enabled. NOTE: automatic kernel builder for some reason doesn't like all my network branches and regularly times out the builds on these branches. Suggestion for "waiting a day for a good coverage" doesn't work, as we have seen with generic network conversions. So please wait for the full report from kernel test rebot before merging further up. This has been compile-tested in 116 configs, but 71 timed out (including all s390-related configs again). I am trying to see if they can fix build coverage for me in meanwhile. * The respective change is currently merged into -next as "locking/refcount: Create unchecked atomic_t implementation". ==================== Signed-off-by: -
Reshetova, Elena authored
refcount_t type and corresponding API should be used instead of atomic_t when the variable is used as a reference counter. This allows to avoid accidental refcounter overflows that might lead to use-after-free situations. Signed-off-by:
Elena Reshetova <elena.reshetova@intel.com> Signed-off-by:
Hans Liljestrand <ishkamiel@gmail.com> Signed-off-by:
Kees Cook <keescook@chromium.org> Signed-off-by:
David Windsor <dwindsor@gmail.com> Signed-off-by:
-
Reshetova, Elena authored
refcount_t type and corresponding API should be used instead of atomic_t when the variable is used as a reference counter. This allows to avoid accidental refcounter overflows that might lead to use-after-free situations. Signed-off-by:
-
Reshetova, Elena authored
refcount_t type and corresponding API should be used instead of atomic_t when the variable is used as a reference counter. This allows to avoid accidental refcounter overflows that might lead to use-after-free situations. Signed-off-by:
-
Reshetova, Elena authored
refcount_t type and corresponding API should be used instead of atomic_t when the variable is used as a reference counter. This allows to avoid accidental refcounter overflows that might lead to use-after-free situations. Signed-off-by:
-
Reshetova, Elena authored
refcount_t type and corresponding API should be used instead of atomic_t when the variable is used as a reference counter. This allows to avoid accidental refcounter overflows that might lead to use-after-free situations. Signed-off-by:
-
Reshetova, Elena authored
refcount_t type and corresponding API should be used instead of atomic_t when the variable is used as a reference counter. This allows to avoid accidental refcounter overflows that might lead to use-after-free situations. Signed-off-by:
-
Reshetova, Elena authored
refcount_t type and corresponding API should be used instead of atomic_t when the variable is used as a reference counter. This allows to avoid accidental refcounter overflows that might lead to use-after-free situations. Signed-off-by:
-
Reshetova, Elena authored
refcount_t type and corresponding API should be used instead of atomic_t when the variable is used as a reference counter. This allows to avoid accidental refcounter overflows that might lead to use-after-free situations. Signed-off-by:
-
Reshetova, Elena authored
refcount_t type and corresponding API should be used instead of atomic_t when the variable is used as a reference counter. This allows to avoid accidental refcounter overflows that might lead to use-after-free situations. Signed-off-by:
-
Reshetova, Elena authored
refcount_t type and corresponding API should be used instead of atomic_t when the variable is used as a reference counter. This allows to avoid accidental refcounter overflows that might lead to use-after-free situations. Signed-off-by:
-
Reshetova, Elena authored
refcount_t type and corresponding API should be used instead of atomic_t when the variable is used as a reference counter. This allows to avoid accidental refcounter overflows that might lead to use-after-free situations. Signed-off-by:
-
Reshetova, Elena authored
refcount_t type and corresponding API should be used instead of atomic_t when the variable is used as a reference counter. This allows to avoid accidental refcounter overflows that might lead to use-after-free situations. Signed-off-by:
-
Reshetova, Elena authored
refcount_t type and corresponding API should be used instead of atomic_t when the variable is used as a reference counter. This allows to avoid accidental refcounter overflows that might lead to use-after-free situations. Signed-off-by:
-
Reshetova, Elena authored
refcount_t type and corresponding API should be used instead of atomic_t when the variable is used as a reference counter. This allows to avoid accidental refcounter overflows that might lead to use-after-free situations. Signed-off-by:
-
Reshetova, Elena authored
refcount_t type and corresponding API should be used instead of atomic_t when the variable is used as a reference counter. This allows to avoid accidental refcounter overflows that might lead to use-after-free situations. Signed-off-by:
-
Reshetova, Elena authored
refcount_t type and corresponding API should be used instead of atomic_t when the variable is used as a reference counter. This allows to avoid accidental refcounter overflows that might lead to use-after-free situations. Signed-off-by:
-
Reshetova, Elena authored
refcount_t type and corresponding API should be used instead of atomic_t when the variable is used as a reference counter. This allows to avoid accidental refcounter overflows that might lead to use-after-free situations. Signed-off-by:
-
Reshetova, Elena authored
refcount_t type and corresponding API should be used instead of atomic_t when the variable is used as a reference counter. This allows to avoid accidental refcounter overflows that might lead to use-after-free situations. Signed-off-by:
-
Reshetova, Elena authored
refcount_t type and corresponding API should be used instead of atomic_t when the variable is used as a reference counter. This allows to avoid accidental refcounter overflows that might lead to use-after-free situations. Signed-off-by:
-
Reshetova, Elena authored
refcount_t type and corresponding API should be used instead of atomic_t when the variable is used as a reference counter. This allows to avoid accidental refcounter overflows that might lead to use-after-free situations. Signed-off-by:
-
Reshetova, Elena authored
refcount_t type and corresponding API should be used instead of atomic_t when the variable is used as a reference counter. This allows to avoid accidental refcounter overflows that might lead to use-after-free situations. Signed-off-by:
-
Reshetova, Elena authored
refcount_t type and corresponding API should be used instead of atomic_t when the variable is used as a reference counter. This allows to avoid accidental refcounter overflows that might lead to use-after-free situations. Signed-off-by:
-
Reshetova, Elena authored
refcount_t type and corresponding API should be used instead of atomic_t when the variable is used as a reference counter. This allows to avoid accidental refcounter overflows that might lead to use-after-free situations. Signed-off-by:
-
Reshetova, Elena authored
refcount_t type and corresponding API should be used instead of atomic_t when the variable is used as a reference counter. This allows to avoid accidental refcounter overflows that might lead to use-after-free situations. Signed-off-by:
-
Reshetova, Elena authored
refcount_t type and corresponding API should be used instead of atomic_t when the variable is used as a reference counter. This allows to avoid accidental refcounter overflows that might lead to use-after-free situations. Signed-off-by:
-
