* [PATCH net 1/1] net/smc: fix byte_order for rx_curs_confirmed
From: Ursula Braun @ 2019-02-07 13:52 UTC (permalink / raw)
To: davem
Cc: netdev, linux-s390, linux-rdma, schwidefsky, heiko.carstens,
raspl, ubraun
The recent change in the rx_curs_confirmed assignment disregards
byte order, which causes problems on little endian architectures.
This patch fixes it.
Fixes: b8649efad879 ("net/smc: fix sender_free computation") (net-tree)
Signed-off-by: Ursula Braun <ubraun@linux.ibm.com>
---
net/smc/smc_cdc.c | 4 +---
net/smc/smc_cdc.h | 19 ++++++++++---------
2 files changed, 11 insertions(+), 12 deletions(-)
diff --git a/net/smc/smc_cdc.c b/net/smc/smc_cdc.c
index a712c9f8699b..fb07ad8d69a6 100644
--- a/net/smc/smc_cdc.c
+++ b/net/smc/smc_cdc.c
@@ -101,9 +101,7 @@ int smc_cdc_msg_send(struct smc_connection *conn,
conn->tx_cdc_seq++;
conn->local_tx_ctrl.seqno = conn->tx_cdc_seq;
- smc_host_msg_to_cdc((struct smc_cdc_msg *)wr_buf,
- &conn->local_tx_ctrl, conn);
- smc_curs_copy(&cfed, &((struct smc_host_cdc_msg *)wr_buf)->cons, conn);
+ smc_host_msg_to_cdc((struct smc_cdc_msg *)wr_buf, conn, &cfed);
rc = smc_wr_tx_send(link, (struct smc_wr_tx_pend_priv *)pend);
if (!rc)
smc_curs_copy(&conn->rx_curs_confirmed, &cfed, conn);
diff --git a/net/smc/smc_cdc.h b/net/smc/smc_cdc.h
index 271e2524dc8f..f1cdde9d4b89 100644
--- a/net/smc/smc_cdc.h
+++ b/net/smc/smc_cdc.h
@@ -211,26 +211,27 @@ static inline int smc_curs_diff_large(unsigned int size,
static inline void smc_host_cursor_to_cdc(union smc_cdc_cursor *peer,
union smc_host_cursor *local,
+ union smc_host_cursor *save,
struct smc_connection *conn)
{
- union smc_host_cursor temp;
-
- smc_curs_copy(&temp, local, conn);
- peer->count = htonl(temp.count);
- peer->wrap = htons(temp.wrap);
+ smc_curs_copy(save, local, conn);
+ peer->count = htonl(save->count);
+ peer->wrap = htons(save->wrap);
/* peer->reserved = htons(0); must be ensured by caller */
}
static inline void smc_host_msg_to_cdc(struct smc_cdc_msg *peer,
- struct smc_host_cdc_msg *local,
- struct smc_connection *conn)
+ struct smc_connection *conn,
+ union smc_host_cursor *save)
{
+ struct smc_host_cdc_msg *local = &conn->local_tx_ctrl;
+
peer->common.type = local->common.type;
peer->len = local->len;
peer->seqno = htons(local->seqno);
peer->token = htonl(local->token);
- smc_host_cursor_to_cdc(&peer->prod, &local->prod, conn);
- smc_host_cursor_to_cdc(&peer->cons, &local->cons, conn);
+ smc_host_cursor_to_cdc(&peer->prod, &local->prod, save, conn);
+ smc_host_cursor_to_cdc(&peer->cons, &local->cons, save, conn);
peer->prod_flags = local->prod_flags;
peer->conn_state_flags = local->conn_state_flags;
}
--
2.16.4
^ permalink raw reply related
* Re: Compiler warning
From: Koen Vandeputte @ 2019-02-07 13:55 UTC (permalink / raw)
To: David Ahern, netdev
In-Reply-To: <e5d6fb7f-715c-2959-8a1b-24629a2bb2a1@gmail.com>
On 05.02.19 03:55, David Ahern wrote:
> On 2/4/19 3:43 AM, Koen Vandeputte wrote:
>> Hi All,
>>
>> I'm seeing following compiler warning during kernel compilation
>> (5.0-rc5 and 4.14.96):
>>
>>
>> net/core/dev.c: In function 'validate_xmit_skb_list':
>> net/core/dev.c:3405:15: warning: 'tail' may be used uninitialized in
>> this function [-Wmaybe-uninitialized]
>> tail->next = skb;
>> ~~~~~~~~~~~^~~~~
>>
>>
>> Source shows this:
>>
>> https://elixir.bootlin.com/linux/v5.0-rc5/source/net/core/dev.c#L3387
>>
>> Looks like "tail" can get deferenced while it indeed doesn't get
>> initialized? Kind regards, Koen
>>
> same with this one - false positive. head is initialized to NULL. tail
> is set on the first pass through the loop.
>
> What compiler / version is this?
Thanks for confirming David. (for both of the warnings)
This is seen using GCC 7.4.0
I don't know the policy upstream regarding compiler warnings .. so
thought I should report these. :)
Regards,
Koen
^ permalink raw reply
* Re: [PATCH net-next v2 01/10] net: phy: Update PHY linkmodes after config_init
From: Maxime Chevallier @ 2019-02-07 13:55 UTC (permalink / raw)
To: Andrew Lunn
Cc: davem, netdev, linux-kernel, Florian Fainelli, Heiner Kallweit,
Russell King, linux-arm-kernel, Antoine Tenart, thomas.petazzoni,
gregory.clement, miquel.raynal, nadavh, stefanc, mw
In-Reply-To: <20190207134807.GD23970@lunn.ch>
Hello Andrew,
On Thu, 7 Feb 2019 14:48:07 +0100
Andrew Lunn <andrew@lunn.ch> wrote:
>On Thu, Feb 07, 2019 at 10:49:30AM +0100, Maxime Chevallier wrote:
>> We want to be able to update a PHY's supported list in the config_init
>> callback, so move the Pause parameters settings from phydrv->features
>> after calling config_init to make sure these parameters aren't
>> overwritten.
>
>Hi Maxime
>
>I have a patch which makes some core changes to support PHY doing
>runtime feature detection. I would prefer to use them, than this.
>
>Either I or Heiner will post them soon.
Sure, no problem, thanks for doing this. I'll be happy to review and
test that on my side.
As I said, I lack the big picture view on that part so my approach was
pretty naive, I'm glad you can take care of this :)
Thanks,
Maxime
^ permalink raw reply
* Re: [PATCH net-next v2 02/10] net: phy: Mask-out non-compatible modes when setting the max-speed
From: Andrew Lunn @ 2019-02-07 13:59 UTC (permalink / raw)
To: Maxime Chevallier
Cc: davem, netdev, linux-kernel, Florian Fainelli, Heiner Kallweit,
Russell King, linux-arm-kernel, Antoine Tenart, thomas.petazzoni,
gregory.clement, miquel.raynal, nadavh, stefanc, mw
In-Reply-To: <20190207094939.27369-3-maxime.chevallier@bootlin.com>
On Thu, Feb 07, 2019 at 10:49:31AM +0100, Maxime Chevallier wrote:
> When setting a PHY's max speed using either the max-speed DT property
> or ethtool, we should mask-out all non-compatible modes according to the
> settings table, instead of just the 10/100BASET modes.
>
> Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
> Suggested-by: Russell King <rmk+kernel@armlinux.org.uk>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* RE: [PATCH net] vsock: cope with memory allocation failure at socket creation time
From: Jorgen S. Hansen @ 2019-02-07 14:00 UTC (permalink / raw)
To: 'Paolo Abeni', netdev@vger.kernel.org
Cc: David S. Miller, Stefano Garzarella
In-Reply-To: <9ad578fedcc2888319e4ec222d11f6fe51afd613.1549545195.git.pabeni@redhat.com>
> In the unlikely event that the kmalloc call in vmci_transport_socket_init()
> fails, we end-up calling vmci_transport_destruct() with a NULL vmci_trans()
> and oopsing.
>
> This change addresses the above explicitly checking for zero vmci_trans() at
> destruction time.
>
> Reported-by: Xiumei Mu <xmu@redhat.com>
> Fixes: d021c344051a ("VSOCK: Introduce VM Sockets")
> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
> ---
> net/vmw_vsock/vmci_transport.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/net/vmw_vsock/vmci_transport.c
> b/net/vmw_vsock/vmci_transport.c index c361ce782412..c3d5ab01fba7
> 100644
> --- a/net/vmw_vsock/vmci_transport.c
> +++ b/net/vmw_vsock/vmci_transport.c
> @@ -1651,6 +1651,10 @@ static void vmci_transport_cleanup(struct
> work_struct *work)
>
> static void vmci_transport_destruct(struct vsock_sock *vsk) {
> + /* transport can be NULL if we hit a failure at init() time */
> + if (!vmci_trans(vsk))
> + return;
> +
> /* Ensure that the detach callback doesn't use the sk/vsk
> * we are about to destruct.
> */
> --
> 2.20.1
Reviewed-by: Jorgen Hansen <jhansen@vmware.com>
Thanks for fixing this,
Jorgen
^ permalink raw reply
* Re: [PATCH net-next v2 03/10] net: phy: Move of_set_phy_eee_broken to phy-core.c
From: Andrew Lunn @ 2019-02-07 14:01 UTC (permalink / raw)
To: Maxime Chevallier
Cc: davem, netdev, linux-kernel, Florian Fainelli, Heiner Kallweit,
Russell King, linux-arm-kernel, Antoine Tenart, thomas.petazzoni,
gregory.clement, miquel.raynal, nadavh, stefanc, mw
In-Reply-To: <20190207094939.27369-4-maxime.chevallier@bootlin.com>
On Thu, Feb 07, 2019 at 10:49:32AM +0100, Maxime Chevallier wrote:
> Since of_set_phy_supported was moved to phy-core.c, we can also move
> of_set_phy_eee_broken to the same location, so that we have all OF
> functions in the same place.
>
> This patch doesn't intend to introduce any change in behaviour.
>
> Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: [PATCH bpf-next v7 2/6] bpf: implement BPF_LWT_ENCAP_IP mode in bpf_lwt_push_encap
From: kbuild test robot @ 2019-02-07 14:04 UTC (permalink / raw)
To: Peter Oskolkov
Cc: kbuild-all, Alexei Starovoitov, Daniel Borkmann, netdev,
Peter Oskolkov, David Ahern, Willem de Bruijn, Peter Oskolkov
In-Reply-To: <20190207003720.51096-3-posk@google.com>
[-- Attachment #1: Type: text/plain, Size: 1550 bytes --]
Hi Peter,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on bpf-next/master]
url: https://github.com/0day-ci/linux/commits/Peter-Oskolkov/bpf-add-BPF_LWT_ENCAP_IP-option-to-bpf_lwt_push_encap/20190207-205725
base: https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git master
config: i386-defconfig (attached as .config)
compiler: gcc-8 (Debian 8.2.0-14) 8.2.0
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All errors (new ones prefixed by >>):
net//core/filter.c: In function 'bpf_push_ip_encap':
>> net//core/filter.c:4808:9: error: implicit declaration of function 'bpf_lwt_push_ip_encap'; did you mean 'bpf_push_ip_encap'? [-Werror=implicit-function-declaration]
return bpf_lwt_push_ip_encap(skb, hdr, len, ingress);
^~~~~~~~~~~~~~~~~~~~~
bpf_push_ip_encap
At top level:
net//core/filter.c:4805:12: warning: 'bpf_push_ip_encap' defined but not used [-Wunused-function]
static int bpf_push_ip_encap(struct sk_buff *skb, void *hdr, u32 len,
^~~~~~~~~~~~~~~~~
cc1: some warnings being treated as errors
vim +4808 net//core/filter.c
4804
4805 static int bpf_push_ip_encap(struct sk_buff *skb, void *hdr, u32 len,
4806 bool ingress)
4807 {
> 4808 return bpf_lwt_push_ip_encap(skb, hdr, len, ingress);
4809 }
4810
---
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: 26942 bytes --]
^ permalink raw reply
* Re: [PATCH net-next v2 04/10] net: phy: Automatically fill the generic TP, FIBRE and Backplane modes
From: Andrew Lunn @ 2019-02-07 14:09 UTC (permalink / raw)
To: Maxime Chevallier
Cc: davem, netdev, linux-kernel, Florian Fainelli, Heiner Kallweit,
Russell King, linux-arm-kernel, Antoine Tenart, thomas.petazzoni,
gregory.clement, miquel.raynal, nadavh, stefanc, mw
In-Reply-To: <20190207094939.27369-5-maxime.chevallier@bootlin.com>
On Thu, Feb 07, 2019 at 10:49:33AM +0100, Maxime Chevallier wrote:
> PHY advertised and supported linkmodes contain both specific modes such
> as 1000BASET Half/Full and generic ones such as TP that represent a
> class of modes.
>
> Since some modes such as Fibre, TP or Backplane match a wide range of
> specific modes, we can automatically set these bits if one of the
> specific modes it corresponds to is present in the list.
>
> The 'TP' bit is set whenever there's a BaseT linkmode in
> phydev->supported.
>
> The 'FIBRE' bit is set for BaseL, BaseS and BaseE linkmodes.
>
> Finally, the 'Backplane' is set whenever a BaseK mode is supported.
Hi Maxime
Interesting idea.
But what exactly are we supposed to be representing here? That PHY
can do these modes, or that the port exists on the device? The
marvell10g can do fibre, but do all boards have an SFP/SFF, or do some
only have an RJ-45 for TP? Are there boards without TP and just
SFP/SFF?
Is there documentation in ethtool which gives a clue as to what is
expected?
Thanks
Andrew
^ permalink raw reply
* Re: [PATCH net-next v2 07/10] net: phy: marvell10g: Add support for 2.5GBASET
From: Andrew Lunn @ 2019-02-07 14:15 UTC (permalink / raw)
To: Maxime Chevallier
Cc: davem, netdev, linux-kernel, Florian Fainelli, Heiner Kallweit,
Russell King, linux-arm-kernel, Antoine Tenart, thomas.petazzoni,
gregory.clement, miquel.raynal, nadavh, stefanc, mw
In-Reply-To: <20190207094939.27369-8-maxime.chevallier@bootlin.com>
> if (phydev->speed == SPEED_10000)
> phydev->interface = PHY_INTERFACE_MODE_10GKR;
> + else if (phydev->speed == SPEED_2500)
> + phydev->interface = PHY_INTERFACE_MODE_2500BASEX;
> else if (phydev->speed >= SPEED_10 &&
> - phydev->speed < SPEED_10000)
> + phydev->speed < SPEED_2500)
> phydev->interface = PHY_INTERFACE_MODE_SGMII;
> }
Maybe swap to a switch statement?
> static struct phy_driver mv3310_drivers[] = {
> {
> - .phy_id = 0x002b09aa,
> + .phy_id = MARVELL_PHY_ID_88X3310,
What does the datasheet say about the lower nibble? Often it is a
silicon revision field, so you don't match on it. But 0xa is a rather
odd revision.
Thanks
Andrew
^ permalink raw reply
* Re: [PATCH net-next v2 09/10] net: mvpp2: Add 2.5GBaseT support
From: Andrew Lunn @ 2019-02-07 14:17 UTC (permalink / raw)
To: Maxime Chevallier
Cc: davem, netdev, linux-kernel, Florian Fainelli, Heiner Kallweit,
Russell King, linux-arm-kernel, Antoine Tenart, thomas.petazzoni,
gregory.clement, miquel.raynal, nadavh, stefanc, mw
In-Reply-To: <20190207094939.27369-10-maxime.chevallier@bootlin.com>
On Thu, Feb 07, 2019 at 10:49:38AM +0100, Maxime Chevallier wrote:
> The PPv2 controller is able to support 2.5G speeds, allowing to use
> 2.5GBASET in conjunction with PHYs that use 2500BASEX as their MII
> interface when using this mode.
>
> Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: [PATCH bpf-next v7 1/6] bpf: add plumbing for BPF_LWT_ENCAP_IP in bpf_lwt_push_encap
From: Jesper Dangaard Brouer @ 2019-02-07 14:20 UTC (permalink / raw)
To: Peter Oskolkov
Cc: brouer, Alexei Starovoitov, Daniel Borkmann, netdev,
Peter Oskolkov, David Ahern, Willem de Bruijn
In-Reply-To: <20190207003720.51096-2-posk@google.com>
On Wed, 6 Feb 2019 16:37:15 -0800
Peter Oskolkov <posk@google.com> wrote:
> This patch adds all needed plumbing in preparation to allowing
> bpf programs to do IP encapping via bpf_lwt_push_encap. Actual
> implementation is added in the next patch in the patchset.
>
> Of note:
> - bpf_lwt_push_encap can now be called from BPF_PROG_TYPE_LWT_XMIT
> prog types in addition to BPF_PROG_TYPE_LWT_IN;
> - if the skb being encapped has GSO set, encapsulation is limited
> to IPIP/IP+GRE/IP+GUE (both IPv4 and IPv6);
> - as route lookups are different for ingress vs egress, the single
> external bpf_lwt_push_encap BPF helper is routed internally to
> either bpf_lwt_in_push_encap or bpf_lwt_xmit_push_encap BPF_CALLs,
> depending on prog type.
>
> Signed-off-by: Peter Oskolkov <posk@google.com>
> ---
> include/uapi/linux/bpf.h | 26 +++++++++++++++++++++--
> net/core/filter.c | 46 +++++++++++++++++++++++++++++++++++-----
> 2 files changed, 65 insertions(+), 7 deletions(-)
>
> diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
> index 1777fa0c61e4..138089ff24cf 100644
> --- a/include/uapi/linux/bpf.h
> +++ b/include/uapi/linux/bpf.h
> @@ -2016,6 +2016,19 @@ union bpf_attr {
> * Only works if *skb* contains an IPv6 packet. Insert a
> * Segment Routing Header (**struct ipv6_sr_hdr**) inside
> * the IPv6 header.
> + * **BPF_LWT_ENCAP_IP**
> + * IP encapsulation (GRE/GUE/IPIP/etc). The outer header
> + * must be IPv4 or IPv6, followed by zero or more
> + * additional headers, up to LWT_BPF_MAX_HEADROOM total
> + * bytes in all prepended headers. PLease note that
^^
Trivial typo PLease
> + * if skb_is_gso(skb) is true, no more than two headers
> + * can be prepended, and the inner header, if present,
> + * should be either GRE or UDP/GUE.
> +
^ permalink raw reply
* [PATCH net-next 0/2] qed*: SmartAN query support
From: Sudarsana Reddy Kalluru @ 2019-02-07 14:20 UTC (permalink / raw)
To: davem; +Cc: netdev, aelior, mkalderon
SmartAN feature detects the peer/cable capabilities and establishes the
link in the best possible configuration.
The patch series adds support for querying the capability. Please consider
applying it net-next.
Sudarsana Reddy Kalluru (2):
qed: Add API for SmartAN query.
qede: Add ethtool interface for SmartAN query.
drivers/net/ethernet/qlogic/qed/qed_hsi.h | 1 +
drivers/net/ethernet/qlogic/qed/qed_main.c | 2 ++
drivers/net/ethernet/qlogic/qed/qed_mcp.c | 6 ++++++
drivers/net/ethernet/qlogic/qed/qed_mcp.h | 10 ++++++++++
drivers/net/ethernet/qlogic/qede/qede_ethtool.c | 11 ++++++++++-
include/linux/qed/qed_if.h | 1 +
6 files changed, 30 insertions(+), 1 deletion(-)
--
1.8.3.1
^ permalink raw reply
* [PATCH net-next 2/2] qede: Add ethtool interface for SmartAN query.
From: Sudarsana Reddy Kalluru @ 2019-02-07 14:20 UTC (permalink / raw)
To: davem; +Cc: netdev, aelior, mkalderon
In-Reply-To: <20190207142012.4521-1-skalluru@marvell.com>
The patch adds driver support to query SmartAN capability via ethtool.
Signed-off-by: Sudarsana Reddy Kalluru <skalluru@marvell.com>
Signed-off-by: Ariel Elior <aelior@marvell.com>
Signed-off-by: Michal Kalderon <mkalderon@marvell.com>
---
drivers/net/ethernet/qlogic/qede/qede_ethtool.c | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/qlogic/qede/qede_ethtool.c b/drivers/net/ethernet/qlogic/qede/qede_ethtool.c
index 16331c6..c623808 100644
--- a/drivers/net/ethernet/qlogic/qede/qede_ethtool.c
+++ b/drivers/net/ethernet/qlogic/qede/qede_ethtool.c
@@ -186,11 +186,13 @@
enum {
QEDE_PRI_FLAG_CMT,
+ QEDE_PRI_FLAG_SMART_AN_SUPPORT, /* MFW supports SmartAN */
QEDE_PRI_FLAG_LEN,
};
static const char qede_private_arr[QEDE_PRI_FLAG_LEN][ETH_GSTRING_LEN] = {
"Coupled-Function",
+ "SmartAN capable",
};
enum qede_ethtool_tests {
@@ -404,8 +406,15 @@ static int qede_get_sset_count(struct net_device *dev, int stringset)
static u32 qede_get_priv_flags(struct net_device *dev)
{
struct qede_dev *edev = netdev_priv(dev);
+ u32 flags = 0;
- return (!!(edev->dev_info.common.num_hwfns > 1)) << QEDE_PRI_FLAG_CMT;
+ if (edev->dev_info.common.num_hwfns > 1)
+ flags |= BIT(QEDE_PRI_FLAG_CMT);
+
+ if (edev->dev_info.common.smart_an)
+ flags |= BIT(QEDE_PRI_FLAG_SMART_AN_SUPPORT);
+
+ return flags;
}
struct qede_link_mode_mapping {
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH v2 00/28] thunderbolt: Software connection manager improvements
From: Andy Shevchenko @ 2019-02-07 14:22 UTC (permalink / raw)
To: Mika Westerberg
Cc: linux-kernel, Michael Jamet, Yehezkel Bernat, Andreas Noever,
Lukas Wunner, David S . Miller, netdev
In-Reply-To: <20190206131738.43696-1-mika.westerberg@linux.intel.com>
On Wed, Feb 06, 2019 at 04:17:10PM +0300, Mika Westerberg wrote:
> Hi,
>
> Software connection manager (drivers/thunderbolt/tb.c) is used on older
> Apple hardware with Light Ridge, Cactus Ridge or Falcon Ridge controllers
> to create PCIe tunnels when a Thunderbolt device is connected. Currently
> only one PCIe tunnel is supported. On newer Alpine Ridge based Apple
> systems the driver starts the firmware which then takes care creating
> tunnels.
>
> This series improves the software connection manager so that it will
> support:
>
> - Full PCIe daisy chains (up to 6 devices)
> - Display Port tunneling
> - P2P networking
>
> We also add support for Titan Ridge based Apple systems where we can use
> the same flows than with Alpine Ridge to start the firmware.
>
> Note in order to prevent possible DMA attacks on these systems we should
> make sure IOMMU is enabled. One option is to force dmar_platform_optin()
> return true on Apple hardware. However, it is not part of this series. I'm
> trusting people using Linux on such systems to take care of it. :-)
>
> Previous version of the patch series can be viewed here:
>
> https://lkml.org/lkml/2019/1/29/924
From code style and some other things we discussed off list the series looks
good to me.
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Though minor comments per individual patches are provided.
>
> Changes from v1:
>
> * Added ACK from David
>
> * Add constant (TMU_ACCESS_EN) for BIT(20) when TMU access is enabled. We
> keep it in cap.c close to the LR/ER workaround. Also we enable/disable
> only during capability walk. If it turns we need to have it enabled
> elsewhere we can move it to switch.c and enable just once during
> switch enumeration.
>
> * Use 0 to mean no cap_adap instead of negative value. This follows
> cap_phy.
>
> * Use correct PCI IDs (_BRIDGE) in the last patch where we start firmware
> on Titan Ridge. It wrongly used NHI PCI IDs in v1.
>
> Mika Westerberg (28):
> net: thunderbolt: Unregister ThunderboltIP protocol handler when suspending
> thunderbolt: Do not allocate switch if depth is greater than 6
> thunderbolt: Enable TMU access when accessing port space on legacy devices
> thunderbolt: Add dummy read after port capability list walk on Light Ridge
> thunderbolt: Move LC specific functionality into a separate file
> thunderbolt: Configure lanes when switch is initialized
> thunderbolt: Set sleep bit when suspending switch
> thunderbolt: Properly disable path
> thunderbolt: Cache adapter specific capability offset into struct port
> thunderbolt: Rename tunnel_pci to tunnel
> thunderbolt: Generalize tunnel creation functionality
> thunderbolt: Add functions for allocating and releasing hop IDs
> thunderbolt: Add helper function to iterate from one port to another
> thunderbolt: Extend tunnel creation to more than 2 adjacent switches
> thunderbolt: Deactivate all paths before restarting them
> thunderbolt: Discover preboot PCIe paths the boot firmware established
> thunderbolt: Add support for full PCIe daisy chains
> thunderbolt: Scan only valid NULL adapter ports in hotplug
> thunderbolt: Generalize port finding routines to support all port types
> thunderbolt: Rework NFC credits handling
> thunderbolt: Add support for Display Port tunnels
> thunderbolt: Run tb_xdp_handle_request() in system workqueue
> thunderbolt: Add XDomain UUID exchange support
> thunderbolt: Add support for DMA tunnels
> thunderbolt: Make tb_switch_alloc() return ERR_PTR()
> thunderbolt: Add support for XDomain connections
> thunderbolt: Make rest of the logging to happen at debug level
> thunderbolt: Start firmware on Titan Ridge Apple systems
>
> drivers/net/thunderbolt.c | 3 +
> drivers/thunderbolt/Makefile | 4 +-
> drivers/thunderbolt/cap.c | 90 +++-
> drivers/thunderbolt/ctl.c | 2 +-
> drivers/thunderbolt/icm.c | 15 +-
> drivers/thunderbolt/lc.c | 179 ++++++++
> drivers/thunderbolt/path.c | 326 +++++++++++++--
> drivers/thunderbolt/switch.c | 466 ++++++++++++++++++---
> drivers/thunderbolt/tb.c | 529 ++++++++++++++++++------
> drivers/thunderbolt/tb.h | 67 ++-
> drivers/thunderbolt/tb_msgs.h | 11 +
> drivers/thunderbolt/tb_regs.h | 50 ++-
> drivers/thunderbolt/tunnel.c | 681 +++++++++++++++++++++++++++++++
> drivers/thunderbolt/tunnel.h | 75 ++++
> drivers/thunderbolt/tunnel_pci.c | 226 ----------
> drivers/thunderbolt/tunnel_pci.h | 31 --
> drivers/thunderbolt/xdomain.c | 142 ++++++-
> include/linux/thunderbolt.h | 8 +
> 18 files changed, 2389 insertions(+), 516 deletions(-)
> create mode 100644 drivers/thunderbolt/lc.c
> create mode 100644 drivers/thunderbolt/tunnel.c
> create mode 100644 drivers/thunderbolt/tunnel.h
> delete mode 100644 drivers/thunderbolt/tunnel_pci.c
> delete mode 100644 drivers/thunderbolt/tunnel_pci.h
>
> --
> 2.20.1
>
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* [PATCH net-next 1/2] qed: Add API for SmartAN query.
From: Sudarsana Reddy Kalluru @ 2019-02-07 14:20 UTC (permalink / raw)
To: davem; +Cc: netdev, aelior, mkalderon
In-Reply-To: <20190207142012.4521-1-skalluru@marvell.com>
The patch adds driver interface to read the SmartAN capability from
management firmware.
Signed-off-by: Sudarsana Reddy Kalluru <skalluru@marvell.com>
Signed-off-by: Ariel Elior <aelior@marvell.com>
Signed-off-by: Michal Kalderon <mkalderon@marvell.com>
---
drivers/net/ethernet/qlogic/qed/qed_hsi.h | 1 +
drivers/net/ethernet/qlogic/qed/qed_main.c | 2 ++
drivers/net/ethernet/qlogic/qed/qed_mcp.c | 6 ++++++
drivers/net/ethernet/qlogic/qed/qed_mcp.h | 10 ++++++++++
include/linux/qed/qed_if.h | 1 +
5 files changed, 20 insertions(+)
diff --git a/drivers/net/ethernet/qlogic/qed/qed_hsi.h b/drivers/net/ethernet/qlogic/qed/qed_hsi.h
index 417121e..37edaa8 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_hsi.h
+++ b/drivers/net/ethernet/qlogic/qed/qed_hsi.h
@@ -12796,6 +12796,7 @@ struct public_drv_mb {
#define FW_MB_PARAM_GET_PF_RDMA_BOTH 0x3
/* get MFW feature support response */
+#define FW_MB_PARAM_FEATURE_SUPPORT_SMARTLINQ 0x00000001
#define FW_MB_PARAM_FEATURE_SUPPORT_EEE 0x00000002
#define FW_MB_PARAM_FEATURE_SUPPORT_VLINK 0x00010000
diff --git a/drivers/net/ethernet/qlogic/qed/qed_main.c b/drivers/net/ethernet/qlogic/qed/qed_main.c
index b473526..f164d4a 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_main.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_main.c
@@ -281,6 +281,8 @@ int qed_fill_dev_info(struct qed_dev *cdev,
if (hw_info->b_wol_support == QED_WOL_SUPPORT_PME)
dev_info->wol_support = true;
+ dev_info->smart_an = qed_mcp_is_smart_an_supported(p_hwfn);
+
dev_info->abs_pf_id = QED_LEADING_HWFN(cdev)->abs_pf_id;
} else {
qed_vf_get_fw_version(&cdev->hwfns[0], &dev_info->fw_major,
diff --git a/drivers/net/ethernet/qlogic/qed/qed_mcp.c b/drivers/net/ethernet/qlogic/qed/qed_mcp.c
index bb85418..cc27fd6 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_mcp.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_mcp.c
@@ -3654,6 +3654,12 @@ void qed_mcp_resc_lock_default_init(struct qed_resc_lock_params *p_lock,
}
}
+bool qed_mcp_is_smart_an_supported(struct qed_hwfn *p_hwfn)
+{
+ return !!(p_hwfn->mcp_info->capabilities &
+ FW_MB_PARAM_FEATURE_SUPPORT_SMARTLINQ);
+}
+
int qed_mcp_get_capabilities(struct qed_hwfn *p_hwfn, struct qed_ptt *p_ptt)
{
u32 mcp_resp;
diff --git a/drivers/net/ethernet/qlogic/qed/qed_mcp.h b/drivers/net/ethernet/qlogic/qed/qed_mcp.h
index 6e1d72a..2799e67 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_mcp.h
+++ b/drivers/net/ethernet/qlogic/qed/qed_mcp.h
@@ -1148,6 +1148,16 @@ void qed_mcp_resc_lock_default_init(struct qed_resc_lock_params *p_lock,
struct qed_resc_unlock_params *p_unlock,
enum qed_resc_lock
resource, bool b_is_permanent);
+
+/**
+ * @brief - Return whether management firmware support smart AN
+ *
+ * @param p_hwfn
+ *
+ * @return bool - true if feature is supported.
+ */
+bool qed_mcp_is_smart_an_supported(struct qed_hwfn *p_hwfn);
+
/**
* @brief Learn of supported MFW features; To be done during early init
*
diff --git a/include/linux/qed/qed_if.h b/include/linux/qed/qed_if.h
index 35170f7..f6165d3 100644
--- a/include/linux/qed/qed_if.h
+++ b/include/linux/qed/qed_if.h
@@ -643,6 +643,7 @@ struct qed_dev_info {
u16 mtu;
bool wol_support;
+ bool smart_an;
/* MBI version */
u32 mbi_version;
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH v2 21/28] thunderbolt: Add support for Display Port tunnels
From: Andy Shevchenko @ 2019-02-07 14:28 UTC (permalink / raw)
To: Mika Westerberg
Cc: linux-kernel, Michael Jamet, Yehezkel Bernat, Andreas Noever,
Lukas Wunner, David S . Miller, netdev
In-Reply-To: <20190206131738.43696-22-mika.westerberg@linux.intel.com>
On Wed, Feb 06, 2019 at 04:17:31PM +0300, Mika Westerberg wrote:
> Display Port tunnels are somewhat more complex than PCIe tunnels as it
> requires 3 tunnels (AUX Rx/Tx and Video). In addition we are not
> supposed to create the tunnels immediately when a DP OUT is enumerated.
> Instead we need to wait until we get hotplug event to that adapter port
> or check if the port has HPD set before tunnels can be established. This
> adds Display Port tunneling support to the software connection manager.
> +static int tb_tunnel_dp(struct tb *tb, struct tb_port *out)
> +{
> + struct tb_cm *tcm = tb_priv(tb);
> + struct tb_switch *sw = out->sw;
> + struct tb_tunnel *tunnel;
> + struct tb_port *in;
> +
> + if (tb_port_is_enabled(out))
> + return 0;
> +
> + do {
> + sw = tb_to_switch(sw->dev.parent);
> + if (!sw)
> + return 0;
> + in = tb_find_unused_port(sw, TB_TYPE_DP_HDMI_IN);
> + } while (!in);
> +
> + tunnel = tb_tunnel_alloc_dp(tb, in, out);
> + if (!tunnel) {
> + tb_port_dbg(out, "DP tunnel allocation failed\n");
> + return -EIO;
In the same way how you done for XDomains it makes sense to return here -ENOMEM.
> + }
> +
> + if (tb_tunnel_activate(tunnel)) {
> + tb_port_info(out, "DP tunnel activation failed, aborting\n");
> + tb_tunnel_free(tunnel);
> + return -EIO;
> + }
> +
> + list_add_tail(&tunnel->list, &tcm->tunnel_list);
> + return 0;
> +}
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v2 13/28] thunderbolt: Add helper function to iterate from one port to another
From: Andy Shevchenko @ 2019-02-07 14:33 UTC (permalink / raw)
To: Mika Westerberg
Cc: linux-kernel, Michael Jamet, Yehezkel Bernat, Andreas Noever,
Lukas Wunner, David S . Miller, netdev
In-Reply-To: <20190206131738.43696-14-mika.westerberg@linux.intel.com>
On Wed, Feb 06, 2019 at 04:17:23PM +0300, Mika Westerberg wrote:
> We need to be able to walk from one port to another when we are creating
> paths where there are multiple switches between two ports. For this
> reason introduce a new function tb_port_get_next() and a new macro
> tb_for_each_port().
> +struct tb_port *tb_port_get_next(struct tb_port *start, struct tb_port *end,
> + struct tb_port *prev)
> +{
> + struct tb_port *port, *next;
> +
> + if (!prev)
> + return start;
> +
> + if (prev->sw == end->sw) {
> + if (prev != end)
> + return end;
> + return NULL;
I would prefer to see the similar pattern as you used below, i.e. when we have
an "bail out" condition, check for it.
if (prev == end)
return NULL;
return end;
> + }
> +
> + /* Switch back to use primary links for walking */
> + if (prev->dual_link_port && prev->link_nr)
> + port = prev->dual_link_port;
> + else
> + port = prev;
> +
> + if (start->sw->config.depth < end->sw->config.depth) {
> + if (port->remote &&
> + port->remote->sw->config.depth > port->sw->config.depth)
> + next = port->remote;
> + else
> + next = tb_port_at(tb_route(end->sw), port->sw);
> + } else if (start->sw->config.depth > end->sw->config.depth) {
> + if (tb_is_upstream_port(port))
> + next = port->remote;
> + else
> + next = tb_upstream_port(port->sw);
> + } else {
> + /* Must be the same switch then */
> + if (start->sw != end->sw)
> + return NULL;
> + return end;
Here is a good pattern.
> + }
> +
> + /* If prev was dual link return another end of that link then */
> + if (next->dual_link_port && next->link_nr != prev->link_nr)
> + return next->dual_link_port;
> +
> + return next;
> +}
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* [RFC, PATCH] net: page_pool: Don't use page->private to store dma_addr_t
From: Ilias Apalodimas @ 2019-02-07 14:36 UTC (permalink / raw)
To: brouer, tariqt, toke; +Cc: davem, netdev, mgorman, linux-mm, Ilias Apalodimas
As pointed out in
https://www.mail-archive.com/netdev@vger.kernel.org/msg257926.html
the current page_pool implementation stores dma_addr_t in page->private.
This won't work on 32-bit platforms with 64-bit DMA addresses since the
page->private is an unsigned long and the dma_addr_t a u64.
Since no driver is yet using the DMA mapping capabilities of the API let's
try and fix this by shadowing struct_page and use 'struct list_head lru'
to store and retrieve DMA addresses from network drivers.
As long as the addresses returned from dma_map_page() are aligned the
first bit, used by the compound pages code should not be set.
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
---
include/net/page_pool.h | 55 +++++++++++++++++++++++++++++++++++++++++++++++++
net/core/page_pool.c | 18 ++++++++++++----
2 files changed, 69 insertions(+), 4 deletions(-)
diff --git a/include/net/page_pool.h b/include/net/page_pool.h
index 694d055..618f2e5 100644
--- a/include/net/page_pool.h
+++ b/include/net/page_pool.h
@@ -98,6 +98,52 @@ struct page_pool {
struct ptr_ring ring;
};
+/* Until we can update struct-page, have a shadow struct-page, that
+ * include our use-case
+ * Used to store retrieve dma addresses from network drivers.
+ * Never access this directly, use helper functions provided
+ * page_pool_get_dma_addr()
+ */
+struct page_shadow {
+ unsigned long flags; /* Atomic flags, some possibly
+ * updated asynchronously
+ */
+ /*
+ * Five words (20/40 bytes) are available in this union.
+ * WARNING: bit 0 of the first word is used for PageTail(). That
+ * means the other users of this union MUST NOT use the bit to
+ * avoid collision and false-positive PageTail().
+ */
+ union {
+ struct { /* Page cache and anonymous pages */
+ /**
+ * @lru: Pageout list, eg. active_list protected by
+ * zone_lru_lock. Sometimes used as a generic list
+ * by the page owner.
+ */
+ struct list_head lru;
+ /* See page-flags.h for PAGE_MAPPING_FLAGS */
+ struct address_space *mapping;
+ pgoff_t index; /* Our offset within mapping. */
+ /**
+ * @private: Mapping-private opaque data.
+ * Usually used for buffer_heads if PagePrivate.
+ * Used for swp_entry_t if PageSwapCache.
+ * Indicates order in the buddy system if PageBuddy.
+ */
+ unsigned long private;
+ };
+ struct { /* page_pool used by netstack */
+ /**
+ * @dma_addr: Page_pool need to store DMA-addr, and
+ * cannot use @private, as DMA-mappings can be 64bit
+ * even on 32-bit Architectures.
+ */
+ dma_addr_t dma_addr; /* Shares area with @lru */
+ };
+ };
+};
+
struct page *page_pool_alloc_pages(struct page_pool *pool, gfp_t gfp);
static inline struct page *page_pool_dev_alloc_pages(struct page_pool *pool)
@@ -141,4 +187,13 @@ static inline bool is_page_pool_compiled_in(void)
#endif
}
+static inline dma_addr_t page_pool_get_dma_addr(struct page *page)
+{
+ struct page_shadow *_page;
+
+ _page = (struct page_shadow *)page;
+
+ return _page->dma_addr;
+}
+
#endif /* _NET_PAGE_POOL_H */
diff --git a/net/core/page_pool.c b/net/core/page_pool.c
index 43a932c..1a956a6 100644
--- a/net/core/page_pool.c
+++ b/net/core/page_pool.c
@@ -111,6 +111,7 @@ noinline
static struct page *__page_pool_alloc_pages_slow(struct page_pool *pool,
gfp_t _gfp)
{
+ struct page_shadow *_page;
struct page *page;
gfp_t gfp = _gfp;
dma_addr_t dma;
@@ -136,7 +137,7 @@ static struct page *__page_pool_alloc_pages_slow(struct page_pool *pool,
if (!(pool->p.flags & PP_FLAG_DMA_MAP))
goto skip_dma_map;
- /* Setup DMA mapping: use page->private for DMA-addr
+ /* Setup DMA mapping: use struct-page area for storing DMA-addr
* This mapping is kept for lifetime of page, until leaving pool.
*/
dma = dma_map_page(pool->p.dev, page, 0,
@@ -146,7 +147,8 @@ static struct page *__page_pool_alloc_pages_slow(struct page_pool *pool,
put_page(page);
return NULL;
}
- set_page_private(page, dma); /* page->private = dma; */
+ _page = (struct page_shadow *)page;
+ _page->dma_addr = dma;
skip_dma_map:
/* When page just alloc'ed is should/must have refcnt 1. */
@@ -175,13 +177,21 @@ EXPORT_SYMBOL(page_pool_alloc_pages);
static void __page_pool_clean_page(struct page_pool *pool,
struct page *page)
{
+ struct page_shadow *_page = (struct page_shadow *)page;
+ dma_addr_t dma;
+
if (!(pool->p.flags & PP_FLAG_DMA_MAP))
return;
+ dma = _page->dma_addr;
+
/* DMA unmap */
- dma_unmap_page(pool->p.dev, page_private(page),
+ dma_unmap_page(pool->p.dev, dma,
PAGE_SIZE << pool->p.order, pool->p.dma_dir);
- set_page_private(page, 0);
+ _page->dma_addr = 0;
+ /* 1. Make sure we don't need to list-init page->lru.
+ * 2. What does it mean: bit 0 of LRU first word is used for PageTail()
+ */
}
/* Return a page to the page allocator, cleaning up our state */
--
2.7.4
^ permalink raw reply related
* Re: [PATCH bpf-next v7 4/6] bpf: add handling of BPF_LWT_REROUTE to lwt_bpf.c
From: kbuild test robot @ 2019-02-07 14:40 UTC (permalink / raw)
To: Peter Oskolkov
Cc: kbuild-all, Alexei Starovoitov, Daniel Borkmann, netdev,
Peter Oskolkov, David Ahern, Willem de Bruijn, Peter Oskolkov
In-Reply-To: <20190207003720.51096-5-posk@google.com>
[-- Attachment #1: Type: text/plain, Size: 1306 bytes --]
Hi Peter,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on bpf-next/master]
url: https://github.com/0day-ci/linux/commits/Peter-Oskolkov/bpf-add-BPF_LWT_ENCAP_IP-option-to-bpf_lwt_push_encap/20190207-205725
base: https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git master
config: m68k-sun3_defconfig (attached as .config)
compiler: m68k-linux-gnu-gcc (Debian 8.2.0-11) 8.2.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=8.2.0 make.cross ARCH=m68k
All errors (new ones prefixed by >>):
m68k-linux-gnu-ld: drivers/rtc/proc.o: in function `is_rtc_hctosys.isra.0':
proc.c:(.text+0x178): undefined reference to `strcmp'
m68k-linux-gnu-ld: net/core/lwt_bpf.o: in function `bpf_lwt_xmit_reroute':
>> lwt_bpf.c:(.text+0x256): undefined reference to `ip6_route_output_flags'
m68k-linux-gnu-ld: net/core/lwt_bpf.o: in function `bpf_input':
>> lwt_bpf.c:(.text+0x836): undefined reference to `ip6_route_input'
---
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: 12133 bytes --]
^ permalink raw reply
* Re: [PATCH net] sctp: make sctp_setsockopt_events() less strict about the option length
From: Neil Horman @ 2019-02-07 14:44 UTC (permalink / raw)
To: Julien Gomes
Cc: Marcelo Ricardo Leitner, netdev, linux-sctp, linux-kernel, davem,
vyasevich, lucien.xin
In-Reply-To: <a21b3ca1-fb51-99cd-4979-62a8c6476cd7@arista.com>
On Wed, Feb 06, 2019 at 01:48:42PM -0800, Julien Gomes wrote:
>
>
> On 2/6/19 1:23 PM, Neil Horman wrote:
> > On Wed, Feb 06, 2019 at 07:07:23PM -0200, Marcelo Ricardo Leitner wrote:
> >> On Wed, Feb 06, 2019 at 12:48:38PM -0800, Julien Gomes wrote:
> >>>
> >>>
> >>> On 2/6/19 12:37 PM, Marcelo Ricardo Leitner wrote:
> >>>> On Wed, Feb 06, 2019 at 12:14:30PM -0800, Julien Gomes wrote:
> >>>>> Make sctp_setsockopt_events() able to accept sctp_event_subscribe
> >>>>> structures longer than the current definitions.
> >>>>>
> >>>>> This should prevent unjustified setsockopt() failures due to struct
> >>>>> sctp_event_subscribe extensions (as in 4.11 and 4.12) when using
> >>>>> binaries that should be compatible, but were built with later kernel
> >>>>> uapi headers.
> >>>>
> >>>> Not sure if we support backwards compatibility like this?
> >>>>
> >>>> My issue with this change is that by doing this, application will have
> >>>> no clue if the new bits were ignored or not and it may think that an
> >>>> event is enabled while it is not.
> >>>>
> >>>> A workaround would be to do a getsockopt and check the size that was
> >>>> returned. But then, it might as well use the right struct here in the
> >>>> first place.
> >>>>
> >>>> I'm seeing current implementation as an implicitly versioned argument:
> >>>> it will always accept setsockopt calls with an old struct (v4.11 or
> >>>> v4.12), but if the user tries to use v3 on a v1-only system, it will
> >>>> be rejected. Pretty much like using a newer setsockopt on an old
> >>>> system.
> >>>
> >>> With the current implementation, given sources that say are supposed to
> >>> run on a 4.9 kernel (no use of any newer field added in 4.11 or 4.12),
> >>> we can't rebuild the exact same sources on a 4.19 kernel and still run
> >>> them on 4.9 without messing with structures re-definition.
> >>
> >> Maybe what we want(ed) here then is explicit versioning, to have the 3
> >> definitions available. Then the application is able to use, say struct
> >> sctp_event_subscribe, and be happy with it, while there is struct
> >> sctp_event_subscribe_v2 and struct sctp_event_subscribe_v3 there too.
> >>
> >> But it's too late for that now because that would break applications
> >> already using the new fields in sctp_event_subscribe.
> >>
> > Yeah, I'm not supportive of codifying that knoweldge in the kernel. If we were
> > to support bi-directional versioning, I would encode it into lksctp-tools rather
> > than the kernel.
>
> I'm not sure that forcing a library on users is a good reason to break UAPI.
>
Thats a misleading statement. We've never supported running newer applications
on older kernels, and no one is forcing anyone to use the lksctp-tools library,
I was only suggesting that, if we were to support this compatibility, that might
be a place to offer it.
Its also worth noting that we have precident for this. If you look at the git
log, this particular structure has been extended about 6 times in the life of
sctp.
> >
> >>>
> >>> I understand your point, but this still looks like a sort of uapi
> >>> breakage to me.
> >>
> >> Not disagreeing. I really just don't know how supported that is.
> >> Willing to know so I can pay more attention to this on future changes.
> >>
> >> Btw, is this the only occurrence?
> >>
> > No, I think there are a few others (maybe paddrparams?)
> >
> >>>
> >>>
> >>> I also had another way to work-around this in mind, by copying optlen
> >>> bytes and checking that any additional field (not included in the
> >>> "current" kernel structure definition) is not set, returning EINVAL in
> >>> such case to keep a similar to current behavior.
> >>> The issue with this is that I didn't find a suitable (ie not totally
> >>> arbitrary such as "twice the existing structure size") upper limit to
> >>> optlen.
> >>
> >> Seems interesting. Why would it need that upper limit to optlen?
> >>
> > I think the thought was to differentiate between someone passing a legit larger
> > structure from a newer UAPI, from someone just passing in a massive
> > inappropriately sized buffer (even if the return on both is the same).
> >
> >> Say struct v1 had 4 bytes, v3 now had 12. The user supplies 12 bytes
> >> to the kernel that only knows about 4 bytes. It can check that (12-4)
> >> bytes in the end, make sure no bit is on and use only the first 4.
> >>
> >> The fact that it was 12 or 200 shouldn't matter, should it? As long as
> >> the (200-4) bytes are 0'ed, only the first 4 will be used and it
> >> should be ok, otherwise EINVAL. No need to know how big the current
> >> current actually is because it wouldn't be validating that here: just
> >> that it can safely use the first 4 bytes.
> >>
> > I'm less than excited about making the kernel check an unbounded user space
> > buffer, thats seems like a potential DOS attack from an unpriviledged user to
> > me. I'm also still hung up on the notion that, despite how we do this, this
> > patch is going into the latest kernel, so it will only work on a kernel that
> > already understands the most recent set of subscriptions. It would work if we,
> > again someday in the future extended this struct, someone built against that
> > newer UAPI, and then tried to run it on a kernel that had this patch.
>
> The patch is going into the latest, but can also be backported on future
> stables.
> I don't think "not fixing it because it's not fixed yet" is a good
> reason to keep things the way they are. But maybe that's just me.
> Given that the structure has already been extended several times, there
> is pretty much nothing to keep this from happening again and again.
>
Also misleading, as it assumes that we're not intentionally doing this. I get
wanting to support running applications built for newer kernels on older
kernels, but thats just not something that we do, and to say thats broken is
misleading. Older applications are required to run on newer kernels, but not
vice versa, which is what you are asking for.
And yes, this patch can be backported to older stable kernels, but by that same
token, so can the patches that extend the struct, which would also fix the
problem, while supporting the newer features, which seems to me to be the better
solution for applications which are looking for that support.
> >
> > FWIW, there is an existing implied method to determine the available
> > subscription events. sctp_getsockopt_events does clamp the size of the output
> > buffer, and returns that information in the optlen field via put_user. An
> > application that was build against UAPIs from 4.19 could pass in the 4.19
> > sctp_event_subscribe struct to sctp_getsockopt_events, and read the output
> > length, whcih would inform the application of the events that the kernel is
> > capable of reporting, and limit itself to only using those events. Its not a
> > perfect solution, but its direct, understandable and portable.
> >
> > Neil
> >
> >>>
> >>>>
> >>>>>
> >>>>> Signed-off-by: Julien Gomes <julien@arista.com>
> >>>>> ---
> >>>>> net/sctp/socket.c | 2 +-
> >>>>> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>>>>
> >>>>> diff --git a/net/sctp/socket.c b/net/sctp/socket.c
> >>>>> index 9644bdc8e85c..f9717e2789da 100644
> >>>>> --- a/net/sctp/socket.c
> >>>>> +++ b/net/sctp/socket.c
> >>>>> @@ -2311,7 +2311,7 @@ static int sctp_setsockopt_events(struct sock *sk, char __user *optval,
> >>>>> int i;
> >>>>>
> >>>>> if (optlen > sizeof(struct sctp_event_subscribe))
> >>>>> - return -EINVAL;
> >>>>> + optlen = sizeof(struct sctp_event_subscribe);
> >>>>>
> >>>>> if (copy_from_user(&subscribe, optval, optlen))
> >>>>> return -EFAULT;
> >>>>> --
> >>>>> 2.20.1
> >>>>>
> >>>
> >>
>
> --
> Julien Gomes
>
^ permalink raw reply
* Re: [PATCH net-next v2 04/10] net: phy: Automatically fill the generic TP, FIBRE and Backplane modes
From: Maxime Chevallier @ 2019-02-07 14:49 UTC (permalink / raw)
To: Andrew Lunn
Cc: davem, netdev, linux-kernel, Florian Fainelli, Heiner Kallweit,
Russell King, linux-arm-kernel, Antoine Tenart, thomas.petazzoni,
gregory.clement, miquel.raynal, nadavh, stefanc, mw
In-Reply-To: <20190207140939.GI32483@lunn.ch>
Hello Andrew,
On Thu, 7 Feb 2019 15:09:39 +0100
Andrew Lunn <andrew@lunn.ch> wrote:
>On Thu, Feb 07, 2019 at 10:49:33AM +0100, Maxime Chevallier wrote:
>> PHY advertised and supported linkmodes contain both specific modes such
>> as 1000BASET Half/Full and generic ones such as TP that represent a
>> class of modes.
>>
>> Since some modes such as Fibre, TP or Backplane match a wide range of
>> specific modes, we can automatically set these bits if one of the
>> specific modes it corresponds to is present in the list.
>>
>> The 'TP' bit is set whenever there's a BaseT linkmode in
>> phydev->supported.
>>
>> The 'FIBRE' bit is set for BaseL, BaseS and BaseE linkmodes.
>>
>> Finally, the 'Backplane' is set whenever a BaseK mode is supported.
>
>Hi Maxime
>
>Interesting idea.
>
>But what exactly are we supposed to be representing here? That PHY
>can do these modes, or that the port exists on the device? The
>marvell10g can do fibre, but do all boards have an SFP/SFF, or do some
>only have an RJ-45 for TP? Are there boards without TP and just
>SFP/SFF?
My understanding is that this would represent what the PHY is capable
of, at least when set in the supported field, but I agree that this
doesn't reflect what's on the device.
I extrapolated this logic from the ability detection in marvell10g,
that would set these bits according to the abilities reported by the
PHY. This was done based on the PHY register values, instead of the
linkmodes in the 'supported' field.
>Is there documentation in ethtool which gives a clue as to what is
>expected?
Not really, at least to my knowledge. I think this would be used by
"ethtool -s ethX port tp|fibre|aui|etc". Maybe this could be useful if
we decide to implement port selection with ethtool on the MCBin, but I'm
getting a bit ahead of myself.
Thanks,
Maxime
^ permalink raw reply
* Re: [PATCH net] sctp: make sctp_setsockopt_events() less strict about the option length
From: Neil Horman @ 2019-02-07 14:48 UTC (permalink / raw)
To: Julien Gomes
Cc: Marcelo Ricardo Leitner, netdev, linux-sctp, linux-kernel, davem,
vyasevich, lucien.xin
In-Reply-To: <271b88ca-ae7c-7d07-330a-242e8ba7322d@arista.com>
On Wed, Feb 06, 2019 at 01:48:44PM -0800, Julien Gomes wrote:
>
>
> On 2/6/19 1:39 PM, Neil Horman wrote:
> > On Wed, Feb 06, 2019 at 01:26:55PM -0800, Julien Gomes wrote:
> >>
> >>
> >> On 2/6/19 1:07 PM, Marcelo Ricardo Leitner wrote:
> >>> On Wed, Feb 06, 2019 at 12:48:38PM -0800, Julien Gomes wrote:
> >>>>
> >>>>
> >>>> On 2/6/19 12:37 PM, Marcelo Ricardo Leitner wrote:
> >>>>> On Wed, Feb 06, 2019 at 12:14:30PM -0800, Julien Gomes wrote:
> >>>>>> Make sctp_setsockopt_events() able to accept sctp_event_subscribe
> >>>>>> structures longer than the current definitions.
> >>>>>>
> >>>>>> This should prevent unjustified setsockopt() failures due to struct
> >>>>>> sctp_event_subscribe extensions (as in 4.11 and 4.12) when using
> >>>>>> binaries that should be compatible, but were built with later kernel
> >>>>>> uapi headers.
> >>>>>
> >>>>> Not sure if we support backwards compatibility like this?
> >>>>>
> >>>>> My issue with this change is that by doing this, application will have
> >>>>> no clue if the new bits were ignored or not and it may think that an
> >>>>> event is enabled while it is not.
> >>>>>
> >>>>> A workaround would be to do a getsockopt and check the size that was
> >>>>> returned. But then, it might as well use the right struct here in the
> >>>>> first place.
> >>>>>
> >>>>> I'm seeing current implementation as an implicitly versioned argument:
> >>>>> it will always accept setsockopt calls with an old struct (v4.11 or
> >>>>> v4.12), but if the user tries to use v3 on a v1-only system, it will
> >>>>> be rejected. Pretty much like using a newer setsockopt on an old
> >>>>> system.
> >>>>
> >>>> With the current implementation, given sources that say are supposed to
> >>>> run on a 4.9 kernel (no use of any newer field added in 4.11 or 4.12),
> >>>> we can't rebuild the exact same sources on a 4.19 kernel and still run
> >>>> them on 4.9 without messing with structures re-definition.
> >>>
> >>> Maybe what we want(ed) here then is explicit versioning, to have the 3
> >>> definitions available. Then the application is able to use, say struct
> >>> sctp_event_subscribe, and be happy with it, while there is struct
> >>> sctp_event_subscribe_v2 and struct sctp_event_subscribe_v3 there too.
> >>>
> >>> But it's too late for that now because that would break applications
> >>> already using the new fields in sctp_event_subscribe.
> >>
> >> Right.
> >>
> >>>
> >>>>
> >>>> I understand your point, but this still looks like a sort of uapi
> >>>> breakage to me.
> >>>
> >>> Not disagreeing. I really just don't know how supported that is.
> >>> Willing to know so I can pay more attention to this on future changes.
> >>>
> >>> Btw, is this the only occurrence?
> >>
> >> Can't really say, this is one I witnessed, I haven't really looked for
> >> others.
> >>
> >>>
> >>>>
> >>>>
> >>>> I also had another way to work-around this in mind, by copying optlen
> >>>> bytes and checking that any additional field (not included in the
> >>>> "current" kernel structure definition) is not set, returning EINVAL in
> >>>> such case to keep a similar to current behavior.
> >>>> The issue with this is that I didn't find a suitable (ie not totally
> >>>> arbitrary such as "twice the existing structure size") upper limit to
> >>>> optlen.
> >>>
> >>> Seems interesting. Why would it need that upper limit to optlen?
> >>>
> >>> Say struct v1 had 4 bytes, v3 now had 12. The user supplies 12 bytes
> >>> to the kernel that only knows about 4 bytes. It can check that (12-4)
> >>> bytes in the end, make sure no bit is on and use only the first 4.
> >>>
> >>> The fact that it was 12 or 200 shouldn't matter, should it? As long as
> >>> the (200-4) bytes are 0'ed, only the first 4 will be used and it
> >>> should be ok, otherwise EINVAL. No need to know how big the current
> >>> current actually is because it wouldn't be validating that here: just
> >>> that it can safely use the first 4 bytes.
> >>
> >> The upper limit concern is more regarding the call to copy_from_user
> >> with an unrestricted/unchecked value.
> > Copy_from_user should be safe to copy an arbitrary amount, the only restriction
> > is that optlen can't exceed the size of the buffer receiving the data in the
> > kernel. From that standpoint your patch is safe. However, that exposes the
> > problem of checking any tail data on the userspace buffer. That is to say, if
> > you want to ensure that any extra data that gets sent from userspace isn't
> > 'set', you would have to copy that extra data in consumable chunks and check
> > them individaully, and that screams DOS to me (i.e. imagine a user passing in a
> > 4GB buffer, and having to wait for the kernel to copy each X sized chunk,
> > looking for non-zero values).
>
> There probably is a decent compromise to find between "not accepting a
> single additional byte" and accepting several GB.
> For example how likely is it that the growth of this structure make it
> go over a page? I would hope not at all.
>
Probably not, but I'm not going to pick a magic number to gate whats ok and
whats not for sockopt validation.
> By choosing a large but decent high limit, I think we can find a
> future-compatible compromise that doesn't rely on a preliminary
> getsockopt() just for structure trucation decision...
>
We really don't have to, I refer you to my previous not referencing the fact
that the getsockopt variant of this call will return the expected length of this
option for the running kernel, allowing userspace to know explicitly what the
buffer size should be, and by extension, what options are supported
Neil
> >
> >> I am not sure of how much of a risk/how exploitable this could be,
> >> that's why I cautiously wanted to limit it in the first place just in case.
> >>
> >>>
> >>>>
> >>>>>
> >>>>>>
> >>>>>> Signed-off-by: Julien Gomes <julien@arista.com>
> >>>>>> ---
> >>>>>> net/sctp/socket.c | 2 +-
> >>>>>> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>>>>>
> >>>>>> diff --git a/net/sctp/socket.c b/net/sctp/socket.c
> >>>>>> index 9644bdc8e85c..f9717e2789da 100644
> >>>>>> --- a/net/sctp/socket.c
> >>>>>> +++ b/net/sctp/socket.c
> >>>>>> @@ -2311,7 +2311,7 @@ static int sctp_setsockopt_events(struct sock *sk, char __user *optval,
> >>>>>> int i;
> >>>>>>
> >>>>>> if (optlen > sizeof(struct sctp_event_subscribe))
> >>>>>> - return -EINVAL;
> >>>>>> + optlen = sizeof(struct sctp_event_subscribe);
> >>>>>>
> >>>>>> if (copy_from_user(&subscribe, optval, optlen))
> >>>>>> return -EFAULT;
> >>>>>> --
> >>>>>> 2.20.1
> >>>>>>
> >>>>
> >>
> >> --
> >> Julien Gomes
> >>
>
> --
> Julien Gomes
>
^ permalink raw reply
* Re: [PATCH][RESEND] ath10k: snoc: remove set but not used variable 'ar_snoc'
From: Kalle Valo @ 2019-02-07 14:54 UTC (permalink / raw)
To: YueHaibing
Cc: davem, ath10k, linux-kernel, netdev, linux-wireless, YueHaibing
In-Reply-To: <20190130030900.18764-1-yuehaibing@huawei.com>
YueHaibing <yuehaibing@huawei.com> wrote:
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> drivers/net/wireless/ath/ath10k/snoc.c: In function 'ath10k_snoc_tx_pipe_cleanup':
> drivers/net/wireless/ath/ath10k/snoc.c:681:22: warning:
> variable 'ar_snoc' set but not used [-Wunused-but-set-variable]
>
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
> Reviewed-by: Brian Norris <briannorris@chromium.org>
> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Patch applied to ath-next branch of ath.git, thanks.
f9a4b7f45ff5 ath10k: snoc: remove set but not used variable 'ar_snoc'
--
https://patchwork.kernel.org/patch/10787609/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] ath10k: do not return invalid pointers as a *dentry
From: Kalle Valo @ 2019-02-07 14:55 UTC (permalink / raw)
To: Greg Kroah-Hartman; +Cc: ath10k, linux-wireless, netdev
In-Reply-To: <20190131131556.GB19807@kroah.com>
Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
> When calling debugfs functions, they can now return error values if
> something went wrong. If that happens, return a NULL as a *dentry to
> the relay core instead of passing it an illegal pointer.
>
> The relay core should be able to handle an illegal pointer, but add this
> check to be safe.
>
> Cc: Kalle Valo <kvalo@codeaurora.org>
> Cc: ath10k@lists.infradead.org
> Cc: linux-wireless@vger.kernel.org
> Cc: netdev@vger.kernel.org
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Patch applied to ath-next branch of ath.git, thanks.
0b38b4b44516 ath10k: do not return invalid pointers as a *dentry
--
https://patchwork.kernel.org/patch/10790493/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* [PATCH net-next 1/7] s390/net: move pnet constants
From: Ursula Braun @ 2019-02-07 14:56 UTC (permalink / raw)
To: davem; +Cc: netdev, linux-s390, schwidefsky, heiko.carstens, raspl, ubraun
In-Reply-To: <20190207145620.92811-1-ubraun@linux.ibm.com>
There is no need to define these PNETID related constants in
the pnet.h file, since they are just used locally within pnet.c.
Just code cleanup, no functional change.
Signed-off-by: Ursula Braun <ubraun@linux.ibm.com>
---
arch/s390/include/asm/pnet.h | 8 --------
arch/s390/net/pnet.c | 8 ++++++++
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/arch/s390/include/asm/pnet.h b/arch/s390/include/asm/pnet.h
index 6e278584f8f1..5739276b458d 100644
--- a/arch/s390/include/asm/pnet.h
+++ b/arch/s390/include/asm/pnet.h
@@ -11,13 +11,5 @@
#include <linux/device.h>
#include <linux/types.h>
-#define PNETIDS_LEN 64 /* Total utility string length in bytes
- * to cover up to 4 PNETIDs of 16 bytes
- * for up to 4 device ports
- */
-#define MAX_PNETID_LEN 16 /* Max.length of a single port PNETID */
-#define MAX_PNETID_PORTS (PNETIDS_LEN / MAX_PNETID_LEN)
- /* Max. # of ports with a PNETID */
-
int pnet_id_by_dev_port(struct device *dev, unsigned short port, u8 *pnetid);
#endif /* _ASM_S390_PNET_H */
diff --git a/arch/s390/net/pnet.c b/arch/s390/net/pnet.c
index e22f1b10a6c7..9ecdbdf59781 100644
--- a/arch/s390/net/pnet.c
+++ b/arch/s390/net/pnet.c
@@ -13,6 +13,14 @@
#include <asm/ccwdev.h>
#include <asm/pnet.h>
+#define PNETIDS_LEN 64 /* Total utility string length in bytes
+ * to cover up to 4 PNETIDs of 16 bytes
+ * for up to 4 device ports
+ */
+#define MAX_PNETID_LEN 16 /* Max.length of a single port PNETID */
+#define MAX_PNETID_PORTS (PNETIDS_LEN / MAX_PNETID_LEN)
+ /* Max. # of ports with a PNETID */
+
/*
* Get the PNETIDs from a device.
* s390 hardware supports the definition of a so-called Physical Network
--
2.16.4
^ 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