* Re: Compiler warnings in kernel 4.14.51
From: David Ahern @ 2018-07-02 15:18 UTC (permalink / raw)
To: Enrico Mioso, netdev
Cc: David S. Miller, Daniel Borkmann, Kirill Tkhai, Jakub Kicinski,
Alexei Starovoitov, Rasmus Villemoes, John Fastabend,
Jesper Dangaard Brouer
In-Reply-To: <20180701203507.GA15211@mStation.localdomain>
On 7/1/18 2:35 PM, Enrico Mioso wrote:
> Hello!
>
> While compiling kernel 4.14.51 I got the following warnings:
> CC net/core/dev.o
> net/core/dev.c: In function 'validate_xmit_skb_list':
> net/core/dev.c:3121:15: warning: 'tail' may be used uninitialized in this function [-Wmaybe-uninitialized]
> ...
>
> CC net/ipv4/fib_trie.o
> net/ipv4/fib_trie.c: In function 'fib_trie_unmerge':
> net/ipv4/fib_trie.c:1749:8: warning: 'local_tp' may be used uninitialized in this function [-Wmaybe-uninitialized]
>
> The kernel has been compiled for the MIPS architecture, little-endian 32-bit.
Not seen with x86-64, Debian stretch. In both cases the compiler should
be able to see they are set before use.
^ permalink raw reply
* Re: [PATCH] net: stmmac_tc: use 64-bit arithmetic instead of 32-bit
From: Jose Abreu @ 2018-07-02 15:19 UTC (permalink / raw)
To: Gustavo A. R. Silva, Giuseppe Cavallaro, Alexandre Torgue,
Jose Abreu, David S. Miller
Cc: netdev, linux-kernel
In-Reply-To: <20180702120932.GA13079@embeddedor.com>
On 02-07-2018 13:09, Gustavo A. R. Silva wrote:
> Add suffix UL to constant 1024 in order to give the compiler complete
> information about the proper arithmetic to use. Notice that this
> constant is used in a context that expects an expression of type
> u64 (64 bits, unsigned) and following expressions are currently
> being evaluated using 32-bit arithmetic:
>
> qopt->idleslope * 1024 * ptr
> qopt->hicredit * 1024 * 8
> qopt->locredit * 1024 * 8
>
> Addresses-Coverity-ID: 1470246 ("Unintentional integer overflow")
> Addresses-Coverity-ID: 1470248 ("Unintentional integer overflow")
> Addresses-Coverity-ID: 1470249 ("Unintentional integer overflow")
> Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
>
Acked-by: Jose Abreu <joabreu@synopsys.com>
Thanks!
Best Regards,
Jose Miguel Abreu
^ permalink raw reply
* Re: [PATCH v4 net-next 0/9] Handle multiple received packets at each stage
From: David Ahern @ 2018-07-02 15:40 UTC (permalink / raw)
To: Edward Cree, davem; +Cc: netdev
In-Reply-To: <5bf84d99-8f77-54ee-7543-ada13a730361@solarflare.com>
On 7/2/18 9:11 AM, Edward Cree wrote:
> This patch series adds the capability for the network stack to receive a
> list of packets and process them as a unit, rather than handling each
> packet singly in sequence. This is done by factoring out the existing
> datapath code at each layer and wrapping it in list handling code.
>
...
> drivers/net/ethernet/sfc/efx.c | 12 +++
> drivers/net/ethernet/sfc/net_driver.h | 3 +
> drivers/net/ethernet/sfc/rx.c | 7 +-
> include/linux/list.h | 30 ++++++
> include/linux/netdevice.h | 4 +
> include/linux/netfilter.h | 22 +++++
> include/net/ip.h | 2 +
> include/trace/events/net.h | 7 ++
> net/core/dev.c | 174 ++++++++++++++++++++++++++++++++--
> net/ipv4/af_inet.c | 1 +
> net/ipv4/ip_input.c | 114 ++++++++++++++++++++--
> 11 files changed, 360 insertions(+), 16 deletions(-)
>
Nice work. Have you looked at IPv6 support yet?
^ permalink raw reply
* Re: [RFC net-next 15/15] net: lora: Add Semtech SX1301
From: Mark Brown @ 2018-07-02 16:12 UTC (permalink / raw)
To: Andreas Färber
Cc: Steve deRosier, Matthias Brugger, Jiri Pirko, Ben Whitten, netdev,
Marcel Holtmann, Dollar Chen, linux-kernel, Michael Röder,
Janus Piwek, linux-spi, Jian-Hong Pan, Ken Yu, David S . Miller,
linux-arm-kernel
In-Reply-To: <20180701110804.32415-16-afaerber@suse.de>
[-- Attachment #1.1: Type: text/plain, Size: 1719 bytes --]
On Sun, Jul 01, 2018 at 01:08:04PM +0200, Andreas Färber wrote:
> +static void sx1301_radio_spi_set_cs(struct spi_device *spi, bool enable)
> +{
> + int ret;
> +
> + dev_dbg(&spi->dev, "setting SPI CS to %s\n", enable ? "1" : "0");
> +
> + if (enable)
> + return;
> +
> + ret = sx1301_radio_set_cs(spi->controller, enable);
> + if (ret)
> + dev_warn(&spi->dev, "failed to write CS (%d)\n", ret);
> +}
So we never disable chip select?
> + if (tx_buf) {
> + ret = sx1301_write(ssx->parent, ssx->regs + REG_RADIO_X_ADDR, tx_buf ? tx_buf[0] : 0);
This looks confused. We're in an if (tx_buf) block but there's a use of
the ternery operator that appears to be checking if we have a tx_buf?
> + if (ret) {
> + dev_err(&spi->dev, "SPI radio address write failed\n");
> + return ret;
> + }
> +
> + ret = sx1301_write(ssx->parent, ssx->regs + REG_RADIO_X_DATA, (tx_buf && xfr->len >= 2) ? tx_buf[1] : 0);
> + if (ret) {
> + dev_err(&spi->dev, "SPI radio data write failed\n");
> + return ret;
> + }
This looks awfully like you're coming in at the wrong abstraction layer
and the hardware actually implements a register abstraction rather than
a SPI one so you should be using regmap as the abstraction.
> + if (rx_buf) {
> + ret = sx1301_read(ssx->parent, ssx->regs + REG_RADIO_X_DATA_READBACK, &rx_buf[xfr->len - 1]);
> + if (ret) {
> + dev_err(&spi->dev, "SPI radio data read failed\n");
> + return ret;
> + }
> + }
For a read we never set an address?
> +static void sx1301_radio_setup(struct spi_controller *ctrl)
> +{
> + ctrl->mode_bits = SPI_CS_HIGH | SPI_NO_CS;
This controller has no chip select but we provided a set_cs operation?
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RFC net-next 05/15] HACK: net: lora: Deal with .poll_mask in 4.18-rc2
From: Jiri Pirko @ 2018-07-02 16:22 UTC (permalink / raw)
To: Andreas Färber
Cc: netdev, linux-arm-kernel, linux-kernel, Jian-Hong Pan,
Marcel Holtmann, David S . Miller, Matthias Brugger, Janus Piwek,
Michael Röder, Dollar Chen, Ken Yu
In-Reply-To: <20180701110804.32415-6-afaerber@suse.de>
Sun, Jul 01, 2018 at 01:07:54PM CEST, afaerber@suse.de wrote:
>linux-next and 4.18-rc2 both identify as LINUX_VERSION(4,18,0), but
>commit a11e1d432b51f63ba698d044441284a661f01144 (Revert changes to
>convert to ->poll_mask() and aio IOCB_CMD_POLL) reverted .poll_mask
>to .poll again.
>
>Signed-off-by: Andreas Färber <afaerber@suse.de>
>---
> net/lora/dgram.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
>diff --git a/net/lora/dgram.c b/net/lora/dgram.c
>index 4d931fd3778a..ef56fd90e762 100644
>--- a/net/lora/dgram.c
>+++ b/net/lora/dgram.c
>@@ -217,7 +217,11 @@ const struct proto_ops dgram_proto_ops = {
> .socketpair = sock_no_socketpair,
> .accept = sock_no_accept,
> .getname = dgram_getname,
>+#if 0 /* LINUX_VERSION_CODE >= LINUX_VERSION(4, 18, 0) */
>+ .poll_mask = datagram_poll_mask,
>+#else
I guess that you sent this patch by mistake...
> .poll = datagram_poll,
>+#endif
> .ioctl = dgram_ioctl,
> .listen = sock_no_listen,
> .shutdown = sock_no_shutdown,
>--
>2.16.4
>
^ permalink raw reply
* Re: [RFC net-next 08/15] net: lora: sx1276: Add debugfs
From: Jiri Pirko @ 2018-07-02 16:26 UTC (permalink / raw)
To: Andreas Färber
Cc: netdev, linux-arm-kernel, linux-kernel, Jian-Hong Pan,
Marcel Holtmann, David S . Miller, Matthias Brugger, Janus Piwek,
Michael Röder, Dollar Chen, Ken Yu
In-Reply-To: <20180701110804.32415-9-afaerber@suse.de>
Sun, Jul 01, 2018 at 01:07:57PM CEST, afaerber@suse.de wrote:
>Allow some interactive inspection at runtime via debugfs.
>
>Signed-off-by: Andreas Färber <afaerber@suse.de>
>---
> drivers/net/lora/sx1276.c | 132 ++++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 132 insertions(+)
>
>diff --git a/drivers/net/lora/sx1276.c b/drivers/net/lora/sx1276.c
>index d6732111247a..1072019cfcc1 100644
>--- a/drivers/net/lora/sx1276.c
>+++ b/drivers/net/lora/sx1276.c
>@@ -5,6 +5,7 @@
> * Copyright (c) 2016-2018 Andreas Färber
> */
>
>+#include <linux/debugfs.h>
> #include <linux/delay.h>
> #include <linux/lora.h>
> #include <linux/module.h>
>@@ -61,6 +62,8 @@ struct sx1276_priv {
>
> struct workqueue_struct *wq;
> struct work_struct tx_work;
>+
>+ struct dentry *debugfs;
> };
>
> static int sx1276_read_single(struct spi_device *spi, u8 reg, u8 *val)
>@@ -416,6 +419,128 @@ static const struct net_device_ops sx1276_netdev_ops = {
> .ndo_start_xmit = sx1276_loradev_start_xmit,
> };
>
>+static ssize_t sx1276_freq_read(struct file *file, char __user *user_buf,
>+ size_t count, loff_t *ppos)
>+{
>+ struct net_device *netdev = file->private_data;
>+ struct sx1276_priv *priv = netdev_priv(netdev);
>+ struct spi_device *spi = priv->spi;
>+ ssize_t size;
>+ char *buf;
>+ int ret;
>+ u8 msb, mid, lsb;
>+ u32 freq_xosc;
>+ unsigned long long frf;
>+
>+ ret = of_property_read_u32(spi->dev.of_node, "clock-frequency", &freq_xosc);
>+ if (ret)
>+ return 0;
>+
>+ mutex_lock(&priv->spi_lock);
>+
>+ ret = sx1276_read_single(spi, REG_FRF_MSB, &msb);
>+ if (!ret)
>+ ret = sx1276_read_single(spi, REG_FRF_MID, &mid);
>+ if (!ret)
>+ ret = sx1276_read_single(spi, REG_FRF_LSB, &lsb);
>+
>+ mutex_unlock(&priv->spi_lock);
>+
>+ if (ret)
>+ return 0;
>+
>+ frf = freq_xosc;
>+ frf *= ((ulong)msb << 16) | ((ulong)mid << 8) | lsb;
>+ frf /= (1 << 19);
>+
>+ buf = kasprintf(GFP_KERNEL, "%llu\n", frf);
>+ if (!buf)
>+ return 0;
>+
>+ size = simple_read_from_buffer(user_buf, count, ppos, buf, strlen(buf));
>+ kfree(buf);
>+
>+ return size;
>+}
>+
>+static const struct file_operations sx1276_freq_fops = {
>+ .owner = THIS_MODULE,
>+ .open = simple_open,
>+ .read = sx1276_freq_read,
>+};
>+
>+static ssize_t sx1276_state_read(struct file *file, char __user *user_buf,
>+ size_t count, loff_t *ppos)
>+{
>+ struct net_device *netdev = file->private_data;
>+ struct sx1276_priv *priv = netdev_priv(netdev);
>+ struct spi_device *spi = priv->spi;
>+ ssize_t size;
>+ char *buf;
>+ int len = 0;
>+ int ret;
>+ u8 val;
>+ bool lora_mode = true;
>+ const int max_len = 4096;
>+
>+ buf = kzalloc(max_len, GFP_KERNEL);
>+ if (!buf)
>+ return 0;
>+
>+ mutex_lock(&priv->spi_lock);
>+
>+ ret = sx1276_read_single(spi, REG_OPMODE, &val);
>+ if (!ret) {
>+ len += snprintf(buf + len, max_len - len, "RegOpMode = 0x%02x\n", val);
>+ lora_mode = (val & REG_OPMODE_LONG_RANGE_MODE) != 0;
>+ }
>+
>+ ret = sx1276_read_single(spi, REG_FRF_MSB, &val);
>+ if (!ret)
>+ len += snprintf(buf + len, max_len - len, "RegFrMsb = 0x%02x\n", val);
>+ ret = sx1276_read_single(spi, REG_FRF_MID, &val);
>+ if (!ret)
>+ len += snprintf(buf + len, max_len - len, "RegFrMid = 0x%02x\n", val);
>+ ret = sx1276_read_single(spi, REG_FRF_LSB, &val);
>+ if (!ret)
>+ len += snprintf(buf + len, max_len - len, "RegFrLsb = 0x%02x\n", val);
>+
>+ ret = sx1276_read_single(spi, REG_PA_CONFIG, &val);
>+ if (!ret)
>+ len += snprintf(buf + len, max_len - len, "RegPaConfig = 0x%02x\n", val);
>+
>+ if (lora_mode) {
>+ ret = sx1276_read_single(spi, LORA_REG_IRQ_FLAGS_MASK, &val);
>+ if (!ret)
>+ len += snprintf(buf + len, max_len - len, "RegIrqFlagsMask = 0x%02x\n", val);
>+
>+ ret = sx1276_read_single(spi, LORA_REG_IRQ_FLAGS, &val);
>+ if (!ret)
>+ len += snprintf(buf + len, max_len - len, "RegIrqFlags = 0x%02x\n", val);
>+
>+ ret = sx1276_read_single(spi, LORA_REG_SYNC_WORD, &val);
>+ if (!ret)
>+ len += snprintf(buf + len, max_len - len, "RegSyncWord = 0x%02x\n", val);
>+ }
>+
>+ ret = sx1276_read_single(spi, REG_PA_DAC, &val);
>+ if (!ret)
>+ len += snprintf(buf + len, max_len - len, "RegPaDac = 0x%02x\n", val);
>+
>+ mutex_unlock(&priv->spi_lock);
>+
>+ size = simple_read_from_buffer(user_buf, count, ppos, buf, len);
>+ kfree(buf);
>+
>+ return size;
>+}
>+
>+static const struct file_operations sx1276_state_fops = {
>+ .owner = THIS_MODULE,
>+ .open = simple_open,
>+ .read = sx1276_state_read,
>+};
>+
> static int sx1276_probe(struct spi_device *spi)
> {
> struct net_device *netdev;
>@@ -566,6 +691,10 @@ static int sx1276_probe(struct spi_device *spi)
> return ret;
> }
>
>+ priv->debugfs = debugfs_create_dir(dev_name(&spi->dev), NULL);
>+ debugfs_create_file("state", S_IRUGO, priv->debugfs, netdev, &sx1276_state_fops);
>+ debugfs_create_file("frequency", S_IRUGO, priv->debugfs, netdev, &sx1276_freq_fops);
Hmm. These look like useful information not only for debugging. I think
it would be worth to expose these via some standard uapi. Like generic
netlink, similar to nl80211
>+
> dev_info(&spi->dev, "SX1276 module probed (SX%d)", model);
>
> return 0;
>@@ -574,6 +703,9 @@ static int sx1276_probe(struct spi_device *spi)
> static int sx1276_remove(struct spi_device *spi)
> {
> struct net_device *netdev = spi_get_drvdata(spi);
>+ struct sx1276_priv *priv = netdev_priv(netdev);
>+
>+ debugfs_remove_recursive(priv->debugfs);
>
> unregister_loradev(netdev);
> free_loradev(netdev);
>--
>2.16.4
>
^ permalink raw reply
* RE: [External] Re: incomplete firmware-version shown in ethtool -i
From: Gang Gang10 Liu @ 2018-07-02 16:35 UTC (permalink / raw)
To: John W. Linville; +Cc: netdev@vger.kernel.org
In-Reply-To: <20180702150641.GA6339@tuxdriver.com>
Hi John,
Thanks for your answer!
-----Original Message-----
From: John W. Linville [mailto:linville@tuxdriver.com]
Sent: Monday, July 2, 2018 11:07 PM
To: Gang Gang10 Liu <liugang10@lenovo.com>
Cc: netdev@vger.kernel.org
Subject: [External] Re: incomplete firmware-version shown in ethtool -i
On Wed, Jun 27, 2018 at 07:54:39AM +0000, Gang Gang10 Liu wrote:
> Dear,
>
> I study that the ethtool only can show 31 characters firmware version,
> is it NIC driver not followed ethtool spec or Can we have any other way to get the full firmware version?
>
I think the bnxt team is doing what they can to make as much information available as possible. In this case, they seem to be trying to make versioning info about the firmware package available along with the info about the firmware version itself, and together just barely overflowing the available space in the ethtool structure.
I'll leave it to you and/or Broadcom to determine whether or not that is a bug that needs to be changed.
In the meanwhile, from your quoted message it seems that lspci can give you the correct package version information for the device.
Good luck!
John
>
> Thanks!
>
>
> [http://lenovocentral.lenovo.com/marketing/branding/email_signature/im
> ages/gradient.gif]
>
> Gang Liu 刘刚
> Global Advisory Testing Engineer
>
> DCG Test Strategy and Automation
> Lenovo SZ
>
> [http://lenovocentral.lenovo.com/marketing/branding/email_signature/im
> ages/Email%20Gifs/T.gif]+86 13620981830
> [http://lenovocentral.lenovo.com/marketing/branding/email_signature/im
> ages/Email%20Gifs/E.gif]liugang10@lenovo.com<mailto:rrivera2@lenovo.co
> m>
>
>
>
> Lenovo.com <http://www.lenovo.com/>
> Twitter<http://twitter.com/lenovo> |
> Facebook<http://www.facebook.com/lenovo> |
> Instagram<https://instagram.com/lenovo> |
> Blogs<http://blog.lenovo.com/> | Forums<http://forums.lenovo.com/>
>
>
> [The-Lenovo-Way]
>
>
>
>
>
>
> From: Gang Gang10 Liu
> Sent: Wednesday, June 27, 2018 3:13 PM
> To: Ken Cheng4 <kcheng4@lenovo.com>; Yuhong YH6 Wu <wuyh6@lenovo.com>;
> Qinwei QW1 Yu <yuqw1@lenovo.com>; Vincent HY1 Long
> <longhy1@lenovo.com>; -Product GTE <-Product_GTE@lenovo.com>
> Cc: Frank Y Wu <frankwu@lenovo.com>
> Subject: RE: common fw
> brcm-lnvgy_fw_nic_nxe-212.0.112.0-a_linux_x86-64 issue
>
> Hi all,
>
>
> From ethtool source code, the root cause for this issue is:
>
> the internal buffer for firmware-version in ethtool is 32 (include the string tail zero), so it only can show 31 characters version.
> But the actual firmware-version got from NIC driver is large than 32.
>
> struct ethtool_drvinfo {
> __u32 cmd;
> char driver[32];
> char version[32];
> char fw_version[ETHTOOL_FWVERS_LEN];
> …
>
> #define ETHTOOL_FWVERS_LEN 32
>
>
>
>
> From: Ken Cheng4
> Sent: Wednesday, June 27, 2018 2:44 PM
> To: Yuhong YH6 Wu <wuyh6@lenovo.com<mailto:wuyh6@lenovo.com>>; Qinwei
> QW1 Yu <yuqw1@lenovo.com<mailto:yuqw1@lenovo.com>>; Vincent HY1 Long
> <longhy1@lenovo.com<mailto:longhy1@lenovo.com>>; -Product GTE
> <-Product_GTE@lenovo.com<mailto:-Product_GTE@lenovo.com>>; Gang Gang10
> Liu <liugang10@lenovo.com<mailto:liugang10@lenovo.com>>
> Cc: Frank Y Wu <frankwu@lenovo.com<mailto:frankwu@lenovo.com>>
> Subject: RE: common fw
> brcm-lnvgy_fw_nic_nxe-212.0.112.0-a_linux_x86-64 issue
>
> Yuhong,
>
> A merge request for common had been raised to fix the failure from this ethtool bug while testing firmware level of Broadcom cards.
> https://l3-prd01-rtp.labs.lenovo.com:4443/te/common/merge_requests/151
> 3
>
>
> ===Background===
> Ethtool can not return correctly when the last number is zero like "212.0.107/1.9.1 pkg 212.0.112." <--missing 0 in the end.
>
> Code change is to:
>
> (1) get incomplete version like: 212.0.112
> (2) get complete version from lspci like "[V0] Vendor specific: 212.0.112.0"
> (3) compare the first three numbers with the firmware level from
> ethtool, ex:212.0.112
> (4) if the first three numbers match, fill incomplete firmware version from ethtool with correct one from lspci like: "212.0.107/1.9.1 pkg 212.0.112.0"
>
> I will let Liu Gang to review first and then submit another merge request for more_common.
>
>
>
> Ken Cheng
> Global TE Engineer
> LME
> Taiwan
>
>
> kcheng4@lenovo.com<mailto:e-mail>
> Ph: +886 2 8170-7580
> Fax: +886 2 2651-8246
>
>
> Shipping Address:
> Lenovo Technology B.V. Taiwan Branch
> 4F, No. 66 SanChong Road, NanGang,
> Taipei, Taiwan, 11502
> 荷蘭商聯想股份有限公司台灣分公司
> 台北市南港區三重路66號4樓
>
> [描述: Lenovo-For-Those-Who-Do]
>
>
>
> From: Ken Cheng4
> Sent: Tuesday, June 26, 2018 12:35 PM
> To: Yuhong YH6 Wu; Qinwei QW1 Yu; Vincent HY1 Long; -Product GTE
> Cc: Frank Y Wu
> Subject: RE: common fw
> brcm-lnvgy_fw_nic_nxe-212.0.112.0-a_linux_x86-64 issue
>
> Yuhong,
>
> We may need more time to investigate whether his statement is valid for the other component cards:
>
> === quoted from Qinwei === I believe it has
> same problem for other vendor adapters when the last number of FW version is 0.
>
> But for now I think a quick patch might be better for EOQ support. I was thinking to add an additional zero in the end of fw string when the last digit returned from ethtool is period ‘.’ in order to avoid that tuple error.
>
> For example, to add an additional 0 after “212.0.112.” before it is
> sent to tuple actual_parts = version_tuple(actual)
>
>
> Ken Cheng
> Global TE Engineer
> LME
> Taiwan
>
>
> kcheng4@lenovo.com<mailto:e-mail>
> Ph: +886 2 8170-7580
> Fax: +886 2 2651-8246
>
>
> Shipping Address:
> Lenovo Technology B.V. Taiwan Branch
> 4F, No. 66 SanChong Road, NanGang,
> Taipei, Taiwan, 11502
> 荷蘭商聯想股份有限公司台灣分公司
> 台北市南港區三重路66號4樓
>
> [描述: Lenovo-For-Those-Who-Do]
>
>
>
> From: Yuhong YH6 Wu
> Sent: Tuesday, June 26, 2018 10:41 AM
> To: Qinwei QW1 Yu; Vincent HY1 Long; -Product GTE; Ken Cheng4
> Cc: Frank Y Wu
> Subject: RE: common fw
> brcm-lnvgy_fw_nic_nxe-212.0.112.0-a_linux_x86-64 issue
>
> Hi Ken,
>
> Pre talk with Dev Qinwei brcm fw show have some problem by ethtool whether able to use lspci common replace ethtool to read fw level as below.
>
> [6/26/2018 10:07 AM] Yuhong YH6 Wu:
>
> [root@localhost ~]# ethtool -i eth2
> driver: bnxt_en
> version: 1.7.25
> firmware-version: 212.0.107/1.9.1 pkg 212.0.112. – missing 0
> expansion-rom-version:
> bus-info: 0000:06:00.0
> supports-statistics: yes
> supports-test: yes
> supports-eeprom-access: yes
> supports-register-dump: no
> supports-priv-flags: no
> 重启之后那个0就没了
> [6/26/2018 10:09 AM] Yuhong YH6 Wu:
>
> [root@localhost ~]# lspci -vv -s 06:00.0 |grep V0 -- lspci can read out complete string character.
> [V0] Vendor specific: 212.0.112.0
> 这里看到有
>
>
>
> From: Yuhong YH6 Wu
> Sent: Tuesday, June 26, 2018 9:20 AM
> To: Qinwei QW1 Yu <yuqw1@lenovo.com<mailto:yuqw1@lenovo.com>>; Vincent
> HY1 Long <longhy1@lenovo.com<mailto:longhy1@lenovo.com>>; -Product GTE
> <-Product_GTE@lenovo.com<mailto:-Product_GTE@lenovo.com>>; Ken Cheng4
> <kcheng4@lenovo.com<mailto:kcheng4@lenovo.com>>
> Cc: Frank Y Wu <frankwu@lenovo.com<mailto:frankwu@lenovo.com>>
> Subject: RE: common fw
> brcm-lnvgy_fw_nic_nxe-212.0.112.0-a_linux_x86-64 issue
>
> Hi Qinwei，
> But actual fw level is ‘212.0.112.’ and chg log is ‘Firmware Version: 212.0.112.0’ are you sure this is correct ?
>
> Hi Ken,
>
> If ‘212.0.112.’ fw is correct we need change the common code fix below issue from Broadcom.py.
>
> 180625-11:26:32 INFO ----------------------------------------------------------------------------------------------------
> 180625-11:26:32 INFO | Broadcom FW Flash |
> 180625-11:26:32 INFO
> ----------------------------------------------------------------------
> ------------------------------
> 180625-11:26:32 INFO Fetching Broadcom information for location Rear
> Slot 2
> 180625-11:26:36 INFO Configuring <eth0>...
> 180625-11:26:36 INFO Configuring <eth1>...
> 180625-11:26:38 INFO Configuring <eth2>...
> 180625-11:26:40 INFO Configuring <eth3>...
> 180625-11:26:42 INFO Configuring <eth4>...
> 180625-11:26:44 INFO Configuring <eth5>...
> 180625-11:26:46 INFO Configuring <eth6>...
> 180625-11:26:46 INFO Configuring <eth7>...
> 180625-11:26:48 INFO Configuring <eth8>...
> 180625-11:26:50 INFO Configuring <eth9>...
> 180625-11:26:52 INFO Configuring <eth10>...
> 180625-11:26:54 INFO <LANTools.NETIF object at 0x7f18b5bdef98>
> 180625-11:26:54 INFO <LANTools.NETIF object at 0x7f18b5bdef98>
> 180625-11:26:56 INFO <LANTools.NETIF object at 0x7f18b5bdef98>
> 180625-11:26:56 INFO <LANTools.NETIF object at 0x7f18b5bdef98>
> 180625-11:26:56 INFO pattern:\.|-v|-,version:5719-v1.47
> 180625-11:26:56 INFO pattern:\.|-v|-,version:5719-v1.47
> 180625-11:26:56 INFO Verified Broadcom [Slot 2] firmware level
> actual(=5719-v1.47) == expected(=5719-v1.47)
> 180625-11:26:56 INFO Fetching Broadcom information for location Rear
> Slot 1
> 180625-11:26:56 INFO <LANTools.NETIF object at 0x7f18b5be2dd8>
> 180625-11:26:56 INFO <LANTools.NETIF object at 0x7f18b5be2dd8>
> 180625-11:26:56 INFO bnxt_en:212.0.107/1.9.1 pkg 212.0.112.
> 180625-11:26:57 INFO <LANTools.NETIF object at 0x7f18b5be2dd8>
> 180625-11:26:57 INFO <LANTools.NETIF object at 0x7f18b5be2dd8>
> 180625-11:26:57 INFO bnxt_en:212.0.107/1.9.1 pkg 212.0.112.
> 180625-11:26:57 INFO pattern:\.|-v|-,version:212.0.112.
> 180625-11:26:57 ERR* Unhandled Exception has been thrown
> 180625-11:26:57 EXC** Traceback (most recent call last):
> 180625-11:26:57 EXC** File "/dfcxact/mtsn/J3002240/debug_yuhongw_18b_brcm/platform/modules/Run.py", line 384, in runmain
> 180625-11:26:57 EXC** result = func(*bares, **keywords)
> 180625-11:26:57 EXC** File "/dfcxact/mtsn/J3002240/debug_yuhongw_18b_brcm/repos/common/tests/broadcom_code_test.py", line 37, in main
> 180625-11:26:57 EXC** broadcom.verify_firmware_level(location)
> 180625-11:26:57 EXC** File "/dfcxact/mtsn/J3002240/debug_yuhongw_18b_brcm/repos/common/modules/Broadcom.py", line 180, in verify_firmware_level
> 180625-11:26:57 EXC** result, expected, actual = self._verify_firmware_level(location)
> 180625-11:26:57 EXC** File "/dfcxact/mtsn/J3002240/debug_yuhongw_18b_brcm/repos/common/modules/Broadcom.py", line 193, in _verify_firmware_level
> 180625-11:26:57 EXC** actual_parts = version_tuple(actual)
> 180625-11:26:57 EXC** File "/dfcxact/mtsn/J3002240/debug_yuhongw_18b_brcm/repos/common/modules/Broadcom.py", line 59, in version_tuple
> 180625-11:26:57 EXC** return tuple(int(v, base) for v in re.split(pattern, version))
> 180625-11:26:57 EXC** File "/dfcxact/mtsn/J3002240/debug_yuhongw_18b_brcm/repos/common/modules/Broadcom.py", line 59, in <genexpr>
> 180625-11:26:57 EXC** return tuple(int(v, base) for v in re.split(pattern, version))
> 180625-11:26:57 EXC** ValueError: invalid literal for int() with base 16: ''
> 180625-11:26:57 FAIL FAIL
> 180625-11:26:57 TESTE FAIL broadcom_code_test.py flash
>
>
> From: Qinwei QW1 Yu
> Sent: Monday, June 25, 2018 6:50 PM
> To: Yuhong YH6 Wu <wuyh6@lenovo.com<mailto:wuyh6@lenovo.com>>; Vincent
> HY1 Long <longhy1@lenovo.com<mailto:longhy1@lenovo.com>>; -Product GTE
> <-Product_GTE@lenovo.com<mailto:-Product_GTE@lenovo.com>>
> Cc: Frank Y Wu <frankwu@lenovo.com<mailto:frankwu@lenovo.com>>
> Subject: RE: common fw
> brcm-lnvgy_fw_nic_nxe-212.0.112.0-a_linux_x86-64 issue
>
> Hi Yuhong
>
> The version in adapter VPD is correct.
> I suppose it is caused by ethtool.
> Different ethtool version has different display. See attachment.
> I believe it has same problem for other vendor adapters when the last number of FW version is 0.
>
> Best Regards!
>
> -Qinwei
> NIC Engineer
>
> From: Yuhong YH6 Wu
> Sent: Monday, June 25, 2018 1:29 PM
> To: Qinwei QW1 Yu <yuqw1@lenovo.com<mailto:yuqw1@lenovo.com>>; Vincent
> HY1 Long <longhy1@lenovo.com<mailto:longhy1@lenovo.com>>; -Product GTE
> <-Product_GTE@lenovo.com<mailto:-Product_GTE@lenovo.com>>
> Cc: Frank Y Wu <frankwu@lenovo.com<mailto:frankwu@lenovo.com>>
> Subject: common fw brcm-lnvgy_fw_nic_nxe-212.0.112.0-a_linux_x86-64
> issue
>
> Hi Qinwei,
> Per talk in lync bnxt_en fw show at ‘212.0.112.’ but actually need is ‘212.0.112.0’ from 18b bin file ‘brcm-lnvgy_fw_nic_nxe-212.0.112.0-a_linux_x86-64.bin’
> Pls help to confirm this.
>
> [root@localhost ~]# ethtool -i eth5
> driver: bnxt_en
> version: 1.7.25
> firmware-version: 212.0.107/1.9.1 pkg 212.0.112.
> expansion-rom-version:
> bus-info: 0000:30:00.0
> supports-statistics: yes
> supports-test: yes
> supports-eeprom-access: yes
> supports-register-dump: no
> supports-priv-flags: no
>
> failed in test process as below info:
>
>
> 180625-11:26:32 INFO ----------------------------------------------------------------------------------------------------
> 180625-11:26:32 INFO | Broadcom FW Flash |
> 180625-11:26:32 INFO
> ----------------------------------------------------------------------
> ------------------------------
> 180625-11:26:32 INFO Fetching Broadcom information for location Rear
> Slot 2
> 180625-11:26:36 INFO Configuring <eth0>...
> 180625-11:26:36 INFO Configuring <eth1>...
> 180625-11:26:38 INFO Configuring <eth2>...
> 180625-11:26:40 INFO Configuring <eth3>...
> 180625-11:26:42 INFO Configuring <eth4>...
> 180625-11:26:44 INFO Configuring <eth5>...
> 180625-11:26:46 INFO Configuring <eth6>...
> 180625-11:26:46 INFO Configuring <eth7>...
> 180625-11:26:48 INFO Configuring <eth8>...
> 180625-11:26:50 INFO Configuring <eth9>...
> 180625-11:26:52 INFO Configuring <eth10>...
> 180625-11:26:54 INFO <LANTools.NETIF object at 0x7f18b5bdef98>
> 180625-11:26:54 INFO <LANTools.NETIF object at 0x7f18b5bdef98>
> 180625-11:26:56 INFO <LANTools.NETIF object at 0x7f18b5bdef98>
> 180625-11:26:56 INFO <LANTools.NETIF object at 0x7f18b5bdef98>
> 180625-11:26:56 INFO pattern:\.|-v|-,version:5719-v1.47
> 180625-11:26:56 INFO pattern:\.|-v|-,version:5719-v1.47
> 180625-11:26:56 INFO Verified Broadcom [Slot 2] firmware level
> actual(=5719-v1.47) == expected(=5719-v1.47)
> 180625-11:26:56 INFO Fetching Broadcom information for location Rear
> Slot 1
> 180625-11:26:56 INFO <LANTools.NETIF object at 0x7f18b5be2dd8>
> 180625-11:26:56 INFO <LANTools.NETIF object at 0x7f18b5be2dd8>
> 180625-11:26:56 INFO bnxt_en:212.0.107/1.9.1 pkg 212.0.112.
> 180625-11:26:57 INFO <LANTools.NETIF object at 0x7f18b5be2dd8>
> 180625-11:26:57 INFO <LANTools.NETIF object at 0x7f18b5be2dd8>
> 180625-11:26:57 INFO bnxt_en:212.0.107/1.9.1 pkg 212.0.112.
> 180625-11:26:57 INFO pattern:\.|-v|-,version:212.0.112.
> 180625-11:26:57 ERR* Unhandled Exception has been thrown
> 180625-11:26:57 EXC** Traceback (most recent call last):
> 180625-11:26:57 EXC** File "/dfcxact/mtsn/J3002240/debug_yuhongw_18b_brcm/platform/modules/Run.py", line 384, in runmain
> 180625-11:26:57 EXC** result = func(*bares, **keywords)
> 180625-11:26:57 EXC** File "/dfcxact/mtsn/J3002240/debug_yuhongw_18b_brcm/repos/common/tests/broadcom_code_test.py", line 37, in main
> 180625-11:26:57 EXC** broadcom.verify_firmware_level(location)
> 180625-11:26:57 EXC** File "/dfcxact/mtsn/J3002240/debug_yuhongw_18b_brcm/repos/common/modules/Broadcom.py", line 180, in verify_firmware_level
> 180625-11:26:57 EXC** result, expected, actual = self._verify_firmware_level(location)
> 180625-11:26:57 EXC** File "/dfcxact/mtsn/J3002240/debug_yuhongw_18b_brcm/repos/common/modules/Broadcom.py", line 193, in _verify_firmware_level
> 180625-11:26:57 EXC** actual_parts = version_tuple(actual)
> 180625-11:26:57 EXC** File "/dfcxact/mtsn/J3002240/debug_yuhongw_18b_brcm/repos/common/modules/Broadcom.py", line 59, in version_tuple
> 180625-11:26:57 EXC** return tuple(int(v, base) for v in re.split(pattern, version))
> 180625-11:26:57 EXC** File "/dfcxact/mtsn/J3002240/debug_yuhongw_18b_brcm/repos/common/modules/Broadcom.py", line 59, in <genexpr>
> 180625-11:26:57 EXC** return tuple(int(v, base) for v in re.split(pattern, version))
> 180625-11:26:57 EXC** ValueError: invalid literal for int() with base 16: ''
> 180625-11:26:57 FAIL FAIL
> 180625-11:26:57 TESTE FAIL broadcom_code_test.py flash
>
> Globa Test Engineer
> Email: wuyh6@lenovo.com<mailto:wuyh6@lenovo.com>
>
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* [PATCH] lib: rhashtable: Correct self-assignment in rhashtable.c
From: Rishabh Bhatnagar @ 2018-07-02 16:35 UTC (permalink / raw)
To: netdev, neilb, tgraf, herbert; +Cc: linux-arm-msm, Rishabh Bhatnagar
In file lib/rhashtable.c line 777, skip variable is assigned to
itself. The following error was observed:
lib/rhashtable.c:777:41: warning: explicitly assigning value of
variable of type 'int' to itself [-Wself-assign] error, forbidden
warning: rhashtable.c:777
This error was found when compiling with Clang 6.0. Change it to iter->skip.
Signed-off-by: Rishabh Bhatnagar <rishabhb@codeaurora.org>
Acked-by: Herbert Xu <herbert@gondor.apana.org.au>
Reviewed-by: NeilBrown <neilb@suse.com>
---
lib/rhashtable.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/rhashtable.c b/lib/rhashtable.c
index 9427b57..3109b2e 100644
--- a/lib/rhashtable.c
+++ b/lib/rhashtable.c
@@ -774,7 +774,7 @@ int rhashtable_walk_start_check(struct rhashtable_iter *iter)
skip++;
if (list == iter->list) {
iter->p = p;
- skip = skip;
+ iter->skip = skip;
goto found;
}
}
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply related
* Re: [RFC net-next 05/15] HACK: net: lora: Deal with .poll_mask in 4.18-rc2
From: Andreas Färber @ 2018-07-02 16:59 UTC (permalink / raw)
To: Jiri Pirko
Cc: netdev, linux-arm-kernel, linux-kernel, Jian-Hong Pan,
Marcel Holtmann, David S . Miller, Matthias Brugger, Janus Piwek,
Michael Röder, Dollar Chen, Ken Yu
In-Reply-To: <20180702162238.GB2737@nanopsycho.orion>
Am 02.07.2018 um 18:22 schrieb Jiri Pirko:
> Sun, Jul 01, 2018 at 01:07:54PM CEST, afaerber@suse.de wrote:
>> linux-next and 4.18-rc2 both identify as LINUX_VERSION(4,18,0), but
>> commit a11e1d432b51f63ba698d044441284a661f01144 (Revert changes to
>> convert to ->poll_mask() and aio IOCB_CMD_POLL) reverted .poll_mask
>> to .poll again.
>>
>> Signed-off-by: Andreas Färber <afaerber@suse.de>
>> ---
>> net/lora/dgram.c | 4 ++++
>> 1 file changed, 4 insertions(+)
>>
>> diff --git a/net/lora/dgram.c b/net/lora/dgram.c
>> index 4d931fd3778a..ef56fd90e762 100644
>> --- a/net/lora/dgram.c
>> +++ b/net/lora/dgram.c
>> @@ -217,7 +217,11 @@ const struct proto_ops dgram_proto_ops = {
>> .socketpair = sock_no_socketpair,
>> .accept = sock_no_accept,
>> .getname = dgram_getname,
>> +#if 0 /* LINUX_VERSION_CODE >= LINUX_VERSION(4, 18, 0) */
>> + .poll_mask = datagram_poll_mask,
>> +#else
>
> I guess that you sent this patch by mistake...
No mistake, it's clearly marked as "HACK", and the cover letter states
this is not for merging but for the design discussion. You wanted to see
patches for discussing the topic, so I sent you my current draft.
On my development machine with -rc2 I still use .poll_mask. I will be
able to drop the patch once we have -rc3 built, unless .poll_mask gets
reintroduced later in the cycle. If you know of some macro to check
whether we're -rc2 or -rc3 of 4.18 I'm all ears, otherwise grep'ing in
the Makefile and defining some custom macro would be an alternative.
Some other places in this series have similar, not-commented-out
compatibility code to allow me to test individual modules quickly
without having to build and boot a full kernel for every change. Like
some sk function got/lost a parameter at some point. Originally I kept
compatibility with openSUSE Leap 42.3's 4.4 kernel, now 15.0's 4.12.
https://github.com/afaerber/lora-modules has a Makefile and load.sh
script for that purpose, plus a small C example to send a packet.
Cheers,
Andreas
--
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
^ permalink raw reply
* Re: [PATCH v3 1/4] Simplify usbnet_cdc_update_filter
From: Bjørn Mork @ 2018-07-02 17:13 UTC (permalink / raw)
To: Oliver Neukum; +Cc: Miguel Rodríguez Pérez, gregkh, linux-usb, netdev
In-Reply-To: <1530519944.18402.10.camel@suse.com>
Oliver Neukum <oneukum@suse.com> writes:
> On So, 2018-07-01 at 11:05 +0200, Miguel Rodríguez Pérez wrote:
>> Remove some unneded varibles to make the code easier to read
>> and, replace the generic usb_control_msg function for the
>> more specific usbnet_write_cmd.
>>
>> Signed-off-by: Miguel Rodríguez Pérez <miguel@det.uvigo.gal>
>
> No,
>
> sorry, but this is not good. The reason is a bit subtle.
> Drivers need to reset the filters when handling post_reset()
> [ and reset_resume() ] usbnet_write_cmd() falls back to
> kmemdup() with GFP_KERNEL. Usbnet is a framework with class
> drivers and some of the devices we drive have a storage
> interface. Thence we are on the block error handling path here.
Right. I knew there had to be some reason this was left out when the
rest of these were converted. But I don't think the reason is
valid... usbnet_write_cmd() will never call kmemdup when data is NULL.
There is of course also little advantage in using usbnet_write_cmd when
we don't need to allocate a buffer. But I'd still prefer to see it for
consistency, power management and debug logging.
Or if it is left as-is: Maybe add a comment so that I don't ask the same
stupid questions in 3 weeks time? :-) My memory is los^Husy...
> The simplest solution is to leave out this patch in the sequence.
As Miguel noted: That won't work. The switch from dev->data->control to
dev->intf is necessary to make this function reusable by other
minidrivers.
Bjørn
^ permalink raw reply
* Re: [PATCH bpf-next 2/3] bpf: btf: add btf json print functionality
From: Jakub Kicinski @ 2018-07-02 17:19 UTC (permalink / raw)
To: Okash Khawaja
Cc: Daniel Borkmann, Martin KaFai Lau, Alexei Starovoitov,
Yonghong Song, Quentin Monnet, David S. Miller, netdev,
kernel-team, linux-kernel
In-Reply-To: <20180701103146.GA1388@w1t1fb>
On Sun, 1 Jul 2018 11:31:47 +0100, Okash Khawaja wrote:
> On Wed, Jun 27, 2018 at 02:56:49PM +0200, Daniel Borkmann wrote:
> > On 06/27/2018 01:47 PM, Okash Khawaja wrote:
> > > On Wed, Jun 27, 2018 at 12:34:35PM +0200, Daniel Borkmann wrote:
> > >> On 06/27/2018 12:35 AM, Jakub Kicinski wrote:
> > >>> On Tue, 26 Jun 2018 15:27:09 -0700, Martin KaFai Lau wrote:
> > >>>> On Tue, Jun 26, 2018 at 01:31:33PM -0700, Jakub Kicinski wrote:
> > >> [...]
> > >>>>> Implementing both outputs in one series will help you structure your
> > >>>>> code to best suit both of the formats up front.
> > >>>> hex and "formatted" are the only things missing? As always, things
> > >>>> can be refactored when new use case comes up. Lets wait for
> > >>>> Okash input.
> > >>>>
> > >>>> Regardless, plaintext is our current use case. Having the current
> > >>>> patchset in does not stop us or others from contributing other use
> > >>>> cases (json, "bpftool map find"...etc), and IMO it is actually
> > >>>> the opposite. Others may help us get there faster than us alone.
> > >>>> We should not stop making forward progress and take this patch
> > >>>> as hostage because "abc" and "xyz" are not done together.
> > >>>
> > >>> Parity between JSON and plain text output is non negotiable.
> > >>
> > >> Longish discussion and some confusion in this thread. :-) First of all
> > >> thanks a lot for working on it, very useful!
> > > Thanks :)
> > >
> > >> My $0.02 on it is that so far
> > >> great care has been taken in bpftool to indeed have feature parity between
> > >> JSON and plain text, so it would be highly desirable to keep continuing
> > >> this practice if the consensus is that it indeed is feasible and makes
> > >> sense wrt BTF data. There has been mentioned that given BTF data can be
> > >> dynamic depending on what the user loads via bpf(2) so a potential JSON
> > >> output may look different/break each time anyway. This however could all be
> > >> embedded under a container object that has a fixed key like 'formatted'
> > >> where tools like jq(1) can query into it. I think this would be fine since
> > >> the rest of the (non-dynamic) output is still retained as-is and then
> > >> wouldn't confuse or collide with existing users, and anyone programmatically
> > >> parsing deeper into the BTF data under such JSON container object needs
> > >> to have awareness of what specific data it wants to query from it; so
> > >> there's no conflict wrt breaking anything here. Imho, both outputs would
> > >> be very valuable.
> > > Okay I can add "formatted" object under json output.
> > >
> > > One thing to note here is that the fixed output will change if the map
> > > itself changes. So someone writing a program that consumes that fixed
> > > output will have to account for his program breaking in future, thus
> >
> > Yes, that aspect is fine though, any program/script parsing this would need
> > to be aware of the underlying map type to make sense of it (e.g. per-cpu vs
> > non per-cpu maps to name one). But that info it could query/verify already
> > beforehand via bpftool as well (via normal map info dump for a given id).
> >
> > > breaking backward compatibility anyway as far as the developer is
> > > concerned :)
> > >
> > > I will go ahead with work on "formatted" object.
> >
> > Cool, thanks,
> > Daniel
>
>
> hi,
>
> couple of questions:
>
> 1. just to be sure, formatted section will be on the same level as "key"
> and "value"? so something like following:
>
>
> $ bpftool map dump -p id 8
> [{
> "key": ["0x00","0x00","0x00","0x00"
> ],
> "value": [...
> ],
> "formatted": {
> "key": 0,
> "value": {
> "int_field": 3,
> "pointerfield": 2152930552,
> ...
> }
> }
> }]
Looks good, yes!
> 2. i noticed that the ouput in v1 has all the keys and values on the
> same level. in v2, i'll change them so that each key-value pair is a
> separate object. let me know what you think.
For non-JSON output? No preference, whatever looks better :) Empty
line between key/value pairs to visually separate them could also
work. But up to you.
> finally, i noticed there is a map lookup command which also prints map
> entries. do want that to also be btf-printed in this patchset?
It would be nice to share the printing code for the two, yes.
^ permalink raw reply
* [PATCH net] tls: fix skb_to_sgvec returning unhandled error.
From: Doron Roberts-Kedes @ 2018-07-02 17:25 UTC (permalink / raw)
To: David S . Miller; +Cc: Dave Watson, netdev, Doron Roberts-Kedes
The current code does not inspect the return value of skb_to_sgvec. This
can cause a nullptr kernel panic when the malformed sgvec is passed into
the crypto request.
Checking the return value of skb_to_sgvec and skipping decryption if it
is negative fixes this problem.
Fixes: c46234ebb4d1 ("tls: RX path for ktls")
Acked-by: Dave Watson <davejwatson@fb.com>
Signed-off-by: Doron Roberts-Kedes <doronrk@fb.com>
---
net/tls/tls_sw.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/net/tls/tls_sw.c b/net/tls/tls_sw.c
index 173d8b89072d..b6e118499083 100644
--- a/net/tls/tls_sw.c
+++ b/net/tls/tls_sw.c
@@ -701,6 +701,10 @@ static int decrypt_skb(struct sock *sk, struct sk_buff *skb,
nsg = skb_to_sgvec(skb, &sgin[1],
rxm->offset + tls_ctx->rx.prepend_size,
rxm->full_len - tls_ctx->rx.prepend_size);
+ if (nsg < 0) {
+ ret = nsg;
+ goto out;
+ }
tls_make_aad(ctx->rx_aad_ciphertext,
rxm->full_len - tls_ctx->rx.overhead_size,
@@ -712,6 +716,7 @@ static int decrypt_skb(struct sock *sk, struct sk_buff *skb,
rxm->full_len - tls_ctx->rx.overhead_size,
skb, sk->sk_allocation);
+out:
if (sgin != &sgin_arr[0])
kfree(sgin);
--
2.17.1
^ permalink raw reply related
* Re: [PATCH 0/9] Fix references for some missing documentation files
From: Jonathan Corbet @ 2018-07-02 17:27 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Mark Rutland, James Morris, kvm, Linux Doc Mailing List,
virtualization, linux-leds, linux-scsi, Ingo Molnar,
intel-wired-lan, Jeff Kirsher, linux-input, devicetree,
Steven Rostedt, Mauro Carvalho Chehab, linux-gpio,
Jacek Anaszewski, Andy Whitcroft, netdev, linux-kernel,
Changbin Du, Masami Hiramatsu, linux-kernel, Joe Perches,
Andrew Morton, linuxppc-dev, "
In-Reply-To: <cover.1530005114.git.mchehab+samsung@kernel.org>
On Tue, 26 Jun 2018 06:49:02 -0300
Mauro Carvalho Chehab <mchehab+samsung@kernel.org> wrote:
> Having nothing to do while waiting for my plane to arrive while
> returning back from Japan, I ended by writing a small series of
> patches meant to reduce the number of bad Documentation/*
> links that are detected by:
> ./scripts/documentation-file-ref-check
I've applied everything except the two networking patches, since I expect
those to go through Dave's tree.
Thanks,
jon
^ permalink raw reply
* Re: [RFC net-next 15/15] net: lora: Add Semtech SX1301
From: Andreas Färber @ 2018-07-02 17:34 UTC (permalink / raw)
To: Mark Brown
Cc: netdev, linux-arm-kernel, linux-kernel, Jian-Hong Pan, Jiri Pirko,
Marcel Holtmann, David S . Miller, Matthias Brugger, Janus Piwek,
Michael Röder, Dollar Chen, Ken Yu, Ben Whitten,
Steve deRosier, linux-spi, LoRa_Community_Support
In-Reply-To: <20180702161258.GA18744@sirena.org.uk>
[-- Attachment #1.1: Type: text/plain, Size: 5074 bytes --]
Hi Mark,
This driver is still evolving, there's newer code on my lora-next branch
already: https://github.com/afaerber/linux/commits/lora-next
The reason you're in CC on this RFC is two-fold:
1) You applied Ben's patch to associate "semtech,sx1301" with spidev,
whereas I am now preparing a new driver for the same compatible.
2) This SPI device is in turn exposing the two SPI masters that you
already found below, and I didn't see a sane way to split that code out
into drivers/spi/, so it's in drivers/net/lora/ here - has there been
any precedence either way?
More inline ...
Am 02.07.2018 um 18:12 schrieb Mark Brown:
> On Sun, Jul 01, 2018 at 01:08:04PM +0200, Andreas Färber wrote:
>
>> +static void sx1301_radio_spi_set_cs(struct spi_device *spi, bool enable)
>> +{
>> + int ret;
>> +
>> + dev_dbg(&spi->dev, "setting SPI CS to %s\n", enable ? "1" : "0");
>> +
>> + if (enable)
>> + return;
>> +
>> + ret = sx1301_radio_set_cs(spi->controller, enable);
>> + if (ret)
>> + dev_warn(&spi->dev, "failed to write CS (%d)\n", ret);
>> +}
>
> So we never disable chip select?
Not here, I instead did that in transfer_one below.
Unfortunately there seems to be no documentation, only reference code:
https://github.com/Lora-net/lora_gateway/blob/master/libloragw/src/loragw_radio.c#L121
https://github.com/Lora-net/lora_gateway/blob/master/libloragw/src/loragw_radio.c#L165
It sets CS to 0 before writing to address and data registers, then
immediately sets CS to 1 and back to 0 before reading or ending the
write transaction. I've tried to force the same behavior in this driver.
My guess was that CS is high-active during the short 1-0 cycle, because
if it's low-active during the register writes then why the heck is it
set to 0 again in the end instead of keeping at 1... confusing.
Maybe the Semtech folks CC'ed can comment how these registers work?
>> + if (tx_buf) {
>> + ret = sx1301_write(ssx->parent, ssx->regs + REG_RADIO_X_ADDR, tx_buf ? tx_buf[0] : 0);
>
> This looks confused. We're in an if (tx_buf) block but there's a use of
> the ternery operator that appears to be checking if we have a tx_buf?
Yeah, as mentioned this RFC is not ready for merging - checkpatch.pl
will complain about lines too long, and TODOs are sprinkled all over or
not even mentioned. It's a Proof of Concept that a net_device could work
for a wide range of spi and serdev based drivers, and on top this device
has more than one channel, which may influence network-level design
discussions.
That said, I'll happily drop the second check. Thanks for spotting!
>> + if (ret) {
>> + dev_err(&spi->dev, "SPI radio address write failed\n");
>> + return ret;
>> + }
>> +
>> + ret = sx1301_write(ssx->parent, ssx->regs + REG_RADIO_X_DATA, (tx_buf && xfr->len >= 2) ? tx_buf[1] : 0);
>> + if (ret) {
>> + dev_err(&spi->dev, "SPI radio data write failed\n");
>> + return ret;
>> + }
>
> This looks awfully like you're coming in at the wrong abstraction layer
> and the hardware actually implements a register abstraction rather than
> a SPI one so you should be using regmap as the abstraction.
I don't understand. Ben has suggested using regmap for the SPI _device_
that we're talking to, which may be a good idea. But this SX1301 device
in turn has two SPI _masters_ talking to an SX125x slave each. I don't
see how using regmap instead of my wrappers avoids this spi_controller?
The whole point of this spi_controller is to abstract and separate the
SX1255 vs. SX1257 vs. whatever-radio-attached into a separate driver,
instead of mixing it into the SX1301 driver - to me that looks cleaner
and more extensible. It also has the side-effect that we could configure
the two radios via DT (frequencies, clk output, etc.).
You will find a datasheet with some diagrams mentioning "SPI" at:
https://www.semtech.com/products/wireless-rf/lora-gateways/SX1301
>> + if (rx_buf) {
>> + ret = sx1301_read(ssx->parent, ssx->regs + REG_RADIO_X_DATA_READBACK, &rx_buf[xfr->len - 1]);
>> + if (ret) {
>> + dev_err(&spi->dev, "SPI radio data read failed\n");
>> + return ret;
>> + }
>> + }
>
> For a read we never set an address?
To read, you first write the address via tx_buf, then either in the same
transfer in the third byte or in a subsequent one-byte transfer as first
byte you get the data.
If you have better ideas how to structure this, do let me know.
>> +static void sx1301_radio_setup(struct spi_controller *ctrl)
>> +{
>> + ctrl->mode_bits = SPI_CS_HIGH | SPI_NO_CS;
>
> This controller has no chip select but we provided a set_cs operation?
Oops, I played around with those two options and was hoping SPI_NO_CS
would avoid the undesired set_cs invocations, but it didn't work as
expected and so I added the "if (enabled)" check above.
Thanks for your review,
Andreas
--
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH] ieee802154: add rx LQI from userspace
From: Alexander Aring @ 2018-07-02 17:53 UTC (permalink / raw)
To: Clément Péron
Cc: Romuald Cari, linux-wpan, Alexander Aring, Stefan Schmidt,
David S . Miller, netdev, linux-kernel, Clément Peron
In-Reply-To: <CAJiuCcdCE42FvWc0svNpQDD0rczYi7Xz-RW5PbbjAuvZe9dgwg@mail.gmail.com>
Hi,
On Mon, Jul 02, 2018 at 03:28:04PM +0200, Clément Péron wrote:
> Could you review it please ?
>
sorry... I was thinking a lot what I can contribute to this patch, I
want to make it short.
I see your use case and your use case has of course a valid point.
What I can say about the code? This socket layer was contributed a lot
in a time where the subsystem was unmaintained. Stefan has some
experience with this socket layer by doing some examples [0].
In my opinion I am confused that a lot of netlink handling is needed to
do "something" with this socket layer. I already thought that we need
some af802154ng for next generation.
Known bug is also RAW sockets on af802154 are totally messed up... but
we don't need them, this can be done by AF_PACKET (just need to think
about similar handling there).
---
Now to your patch, you use skb->cb there. The tc ingress part can
_maybe_? use this control block information. I think this issue is out
of scope because we have also other parts in the code how we pass data
between driver and packet layer with skb->cb -> we simply do it wrong.
I have no problems to have this patch inside but for future we should
tackle a af802154ng with a better UAPI handling.
If we fix skb->cb we just need to think about how to pass such data up
to socket layer.
- Alex
[0] https://github.com/linux-wpan/wpan-tools/tree/master/examples
^ permalink raw reply
* Re: [RFC net-next 08/15] net: lora: sx1276: Add debugfs
From: Andreas Färber @ 2018-07-02 17:57 UTC (permalink / raw)
To: Jiri Pirko
Cc: netdev, linux-arm-kernel, linux-kernel, Jian-Hong Pan,
Marcel Holtmann, David S . Miller, Matthias Brugger, Janus Piwek,
Michael Röder, Dollar Chen, Ken Yu
In-Reply-To: <20180702162649.GC2737@nanopsycho.orion>
Am 02.07.2018 um 18:26 schrieb Jiri Pirko:
> Sun, Jul 01, 2018 at 01:07:57PM CEST, afaerber@suse.de wrote:
>> Allow some interactive inspection at runtime via debugfs.
>>
>> Signed-off-by: Andreas Färber <afaerber@suse.de>
[...]
>> @@ -566,6 +691,10 @@ static int sx1276_probe(struct spi_device *spi)
>> return ret;
>> }
>>
>> + priv->debugfs = debugfs_create_dir(dev_name(&spi->dev), NULL);
>> + debugfs_create_file("state", S_IRUGO, priv->debugfs, netdev, &sx1276_state_fops);
>> + debugfs_create_file("frequency", S_IRUGO, priv->debugfs, netdev, &sx1276_freq_fops);
>
> Hmm. These look like useful information not only for debugging. I think
> it would be worth to expose these via some standard uapi. Like generic
> netlink, similar to nl80211
Which API to use for reading/writing such config data was question 4) in
my cover letter. :)
"frequency" was added first and helped me debug a calculation overflow.
Netlink might indeed be an option here, haven't worked on it before,
I'll look into nl80211. Thanks.
"state" was just a partial dump of SPI registers, to monitor status
changes after the initial probe or other callbacks with printks, while
debugging GPIO interrupts iirc. So I'd think merging that to mainline
would be unnecessary, but it could remain useful during development.
Cheers,
Andreas
--
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
^ permalink raw reply
* [PATCH net-next 0/2] More mirror-to-gretap tests with bridge in UL
From: Petr Machata @ 2018-07-02 17:58 UTC (permalink / raw)
To: netdev, linux-kselftest; +Cc: davem, shuah
This patchset adds two more tests where the mirror-to-gretap has a
bridge in underlay packet path, without a VLAN above or below that
bridge.
In patch #1, a non-VLAN-filtering bridge is tested.
In patch #2, a VLAN-filtering bridge is tested.
Petr Machata (2):
selftests: forwarding: Test mirror-to-gretap w/ UL 802.1d
selftests: forwarding: Test mirror-to-gretap w/ UL 802.1q
.../net/forwarding/mirror_gre_bridge_1d.sh | 132 +++++++++++++++++++++
.../net/forwarding/mirror_gre_bridge_1q.sh | 126 ++++++++++++++++++++
2 files changed, 258 insertions(+)
create mode 100755 tools/testing/selftests/net/forwarding/mirror_gre_bridge_1d.sh
create mode 100755 tools/testing/selftests/net/forwarding/mirror_gre_bridge_1q.sh
--
2.4.11
^ permalink raw reply
* [PATCH net-next 1/2] selftests: forwarding: Test mirror-to-gretap w/ UL 802.1d
From: Petr Machata @ 2018-07-02 17:58 UTC (permalink / raw)
To: netdev, linux-kselftest; +Cc: davem, shuah
In-Reply-To: <cover.1530553971.git.petrm@mellanox.com>
Test for "tc action mirred egress mirror" that mirrors to gretap when
the underlay route points at a VLAN-unaware bridge (802.1d).
Signed-off-by: Petr Machata <petrm@mellanox.com>
---
.../net/forwarding/mirror_gre_bridge_1d.sh | 132 +++++++++++++++++++++
1 file changed, 132 insertions(+)
create mode 100755 tools/testing/selftests/net/forwarding/mirror_gre_bridge_1d.sh
diff --git a/tools/testing/selftests/net/forwarding/mirror_gre_bridge_1d.sh b/tools/testing/selftests/net/forwarding/mirror_gre_bridge_1d.sh
new file mode 100755
index 000000000000..c5095da7f6bf
--- /dev/null
+++ b/tools/testing/selftests/net/forwarding/mirror_gre_bridge_1d.sh
@@ -0,0 +1,132 @@
+#!/bin/bash
+# SPDX-License-Identifier: GPL-2.0
+
+# Test for "tc action mirred egress mirror" when the underlay route points at a
+# bridge device without vlan filtering (802.1d).
+#
+# This test uses standard topology for testing mirror-to-gretap. See
+# mirror_gre_topo_lib.sh for more details. The full topology is as follows:
+#
+# +---------------------+ +---------------------+
+# | H1 | | H2 |
+# | + $h1 | | $h2 + |
+# | | 192.0.2.1/28 | | 192.0.2.2/28 | |
+# +-----|---------------+ +---------------|-----+
+# | |
+# +-----|-------------------------------------------------------------|-----+
+# | SW o---> mirror | |
+# | +---|-------------------------------------------------------------|---+ |
+# | | + $swp1 + br1 (802.1q bridge) $swp2 + | |
+# | +---------------------------------------------------------------------+ |
+# | |
+# | +---------------------------------------------------------------------+ |
+# | | + br2 (802.1d bridge) | |
+# | | 192.0.2.129/28 | |
+# | | + $swp3 2001:db8:2::1/64 | |
+# | +---|-----------------------------------------------------------------+ |
+# | | ^ ^ |
+# | | + gt6 (ip6gretap) | + gt4 (gretap) | |
+# | | : loc=2001:db8:2::1 | : loc=192.0.2.129 | |
+# | | : rem=2001:db8:2::2 -+ : rem=192.0.2.130 -+ |
+# | | : ttl=100 : ttl=100 |
+# | | : tos=inherit : tos=inherit |
+# +-----|---------------------:----------------------:----------------------+
+# | : :
+# +-----|---------------------:----------------------:----------------------+
+# | H3 + $h3 + h3-gt6(ip6gretap) + h3-gt4 (gretap) |
+# | 192.0.2.130/28 loc=2001:db8:2::2 loc=192.0.2.130 |
+# | 2001:db8:2::2/64 rem=2001:db8:2::1 rem=192.0.2.129 |
+# | ttl=100 ttl=100 |
+# | tos=inherit tos=inherit |
+# +-------------------------------------------------------------------------+
+
+ALL_TESTS="
+ test_gretap
+ test_ip6gretap
+"
+
+NUM_NETIFS=6
+source lib.sh
+source mirror_lib.sh
+source mirror_gre_lib.sh
+source mirror_gre_topo_lib.sh
+
+setup_prepare()
+{
+ h1=${NETIFS[p1]}
+ swp1=${NETIFS[p2]}
+
+ swp2=${NETIFS[p3]}
+ h2=${NETIFS[p4]}
+
+ swp3=${NETIFS[p5]}
+ h3=${NETIFS[p6]}
+
+ vrf_prepare
+ mirror_gre_topo_create
+
+ ip link add name br2 type bridge vlan_filtering 0
+ ip link set dev br2 up
+
+ ip link set dev $swp3 master br2
+ ip route add 192.0.2.130/32 dev br2
+ ip -6 route add 2001:db8:2::2/128 dev br2
+
+ ip address add dev br2 192.0.2.129/28
+ ip address add dev br2 2001:db8:2::1/64
+
+ ip address add dev $h3 192.0.2.130/28
+ ip address add dev $h3 2001:db8:2::2/64
+}
+
+cleanup()
+{
+ pre_cleanup
+
+ ip address del dev $h3 2001:db8:2::2/64
+ ip address del dev $h3 192.0.2.130/28
+ ip link del dev br2
+
+ mirror_gre_topo_destroy
+ vrf_cleanup
+}
+
+test_gretap()
+{
+ full_test_span_gre_dir gt4 ingress 8 0 "mirror to gretap"
+ full_test_span_gre_dir gt4 egress 0 8 "mirror to gretap"
+}
+
+test_ip6gretap()
+{
+ full_test_span_gre_dir gt6 ingress 8 0 "mirror to ip6gretap"
+ full_test_span_gre_dir gt6 egress 0 8 "mirror to ip6gretap"
+}
+
+test_all()
+{
+ slow_path_trap_install $swp1 ingress
+ slow_path_trap_install $swp1 egress
+
+ tests_run
+
+ slow_path_trap_uninstall $swp1 egress
+ slow_path_trap_uninstall $swp1 ingress
+}
+
+trap cleanup EXIT
+
+setup_prepare
+setup_wait
+
+tcflags="skip_hw"
+test_all
+
+if ! tc_offload_check; then
+ echo "WARN: Could not test offloaded functionality"
+else
+ tcflags="skip_sw"
+ test_all
+fi
+
+exit $EXIT_STATUS
--
2.4.11
^ permalink raw reply related
* [PATCH net-next 2/2] selftests: forwarding: Test mirror-to-gretap w/ UL 802.1q
From: Petr Machata @ 2018-07-02 17:58 UTC (permalink / raw)
To: netdev, linux-kselftest; +Cc: davem, shuah
In-Reply-To: <cover.1530553971.git.petrm@mellanox.com>
Test for "tc action mirred egress mirror" that mirrors to gretap when
the underlay route points at a VLAN-aware bridge (802.1q).
Signed-off-by: Petr Machata <petrm@mellanox.com>
---
.../net/forwarding/mirror_gre_bridge_1q.sh | 126 +++++++++++++++++++++
1 file changed, 126 insertions(+)
create mode 100755 tools/testing/selftests/net/forwarding/mirror_gre_bridge_1q.sh
diff --git a/tools/testing/selftests/net/forwarding/mirror_gre_bridge_1q.sh b/tools/testing/selftests/net/forwarding/mirror_gre_bridge_1q.sh
new file mode 100755
index 000000000000..a3402cd8d5b6
--- /dev/null
+++ b/tools/testing/selftests/net/forwarding/mirror_gre_bridge_1q.sh
@@ -0,0 +1,126 @@
+#!/bin/bash
+# SPDX-License-Identifier: GPL-2.0
+
+# Test for "tc action mirred egress mirror" when the underlay route points at a
+# bridge device with vlan filtering (802.1q).
+#
+# This test uses standard topology for testing mirror-to-gretap. See
+# mirror_gre_topo_lib.sh for more details. The full topology is as follows:
+#
+# +---------------------+ +---------------------+
+# | H1 | | H2 |
+# | + $h1 | | $h2 + |
+# | | 192.0.2.1/28 | | 192.0.2.2/28 | |
+# +-----|---------------+ +---------------|-----+
+# | |
+# +-----|---------------------------------------------------------------|-----+
+# | SW o---> mirror | |
+# | +---|---------------------------------------------------------------|---+ |
+# | | + $swp1 + br1 (802.1q bridge) $swp2 + | |
+# | | 192.0.2.129/28 | |
+# | | + $swp3 2001:db8:2::1/64 | |
+# | | | vid555 vid555[pvid,untagged] | |
+# | +---|-------------------------------------------------------------------+ |
+# | | ^ ^ |
+# | | + gt6 (ip6gretap) | + gt4 (gretap) | |
+# | | : loc=2001:db8:2::1 | : loc=192.0.2.129 | |
+# | | : rem=2001:db8:2::2 -+ : rem=192.0.2.130 -+ |
+# | | : ttl=100 : ttl=100 |
+# | | : tos=inherit : tos=inherit |
+# +-----|---------------------:------------------------:----------------------+
+# | : :
+# +-----|---------------------:------------------------:----------------------+
+# | H3 + $h3 + h3-gt6(ip6gretap) + h3-gt4 (gretap) |
+# | | loc=2001:db8:2::2 loc=192.0.2.130 |
+# | + $h3.555 rem=2001:db8:2::1 rem=192.0.2.129 |
+# | 192.0.2.130/28 ttl=100 ttl=100 |
+# | 2001:db8:2::2/64 tos=inherit tos=inherit |
+# +---------------------------------------------------------------------------+
+
+ALL_TESTS="
+ test_gretap
+ test_ip6gretap
+"
+
+NUM_NETIFS=6
+source lib.sh
+source mirror_lib.sh
+source mirror_gre_lib.sh
+source mirror_gre_topo_lib.sh
+
+setup_prepare()
+{
+ h1=${NETIFS[p1]}
+ swp1=${NETIFS[p2]}
+
+ swp2=${NETIFS[p3]}
+ h2=${NETIFS[p4]}
+
+ swp3=${NETIFS[p5]}
+ h3=${NETIFS[p6]}
+
+ vrf_prepare
+ mirror_gre_topo_create
+
+ ip link set dev $swp3 master br1
+ bridge vlan add dev br1 vid 555 pvid untagged self
+ ip address add dev br1 192.0.2.129/28
+ ip address add dev br1 2001:db8:2::1/64
+
+ ip -4 route add 192.0.2.130/32 dev br1
+ ip -6 route add 2001:db8:2::2/128 dev br1
+
+ vlan_create $h3 555 v$h3 192.0.2.130/28 2001:db8:2::2/64
+ bridge vlan add dev $swp3 vid 555
+}
+
+cleanup()
+{
+ pre_cleanup
+
+ ip link set dev $swp3 nomaster
+ vlan_destroy $h3 555
+
+ mirror_gre_topo_destroy
+ vrf_cleanup
+}
+
+test_gretap()
+{
+ full_test_span_gre_dir gt4 ingress 8 0 "mirror to gretap"
+ full_test_span_gre_dir gt4 egress 0 8 "mirror to gretap"
+}
+
+test_ip6gretap()
+{
+ full_test_span_gre_dir gt6 ingress 8 0 "mirror to ip6gretap"
+ full_test_span_gre_dir gt6 egress 0 8 "mirror to ip6gretap"
+}
+
+tests()
+{
+ slow_path_trap_install $swp1 ingress
+ slow_path_trap_install $swp1 egress
+
+ tests_run
+
+ slow_path_trap_uninstall $swp1 egress
+ slow_path_trap_uninstall $swp1 ingress
+}
+
+trap cleanup EXIT
+
+setup_prepare
+setup_wait
+
+tcflags="skip_hw"
+tests
+
+if ! tc_offload_check; then
+ echo "WARN: Could not test offloaded functionality"
+else
+ tcflags="skip_sw"
+ tests
+fi
+
+exit $EXIT_STATUS
--
2.4.11
^ permalink raw reply related
* Re: [PATCH v4 net-next 0/9] Handle multiple received packets at each stage
From: Edward Cree @ 2018-07-02 18:09 UTC (permalink / raw)
To: David Ahern, davem; +Cc: netdev
In-Reply-To: <d7092205-ff36-e982-e8fb-1a056df8b0bc@gmail.com>
On 02/07/18 16:40, David Ahern wrote:
> Nice work. Have you looked at IPv6 support yet?
I hadn't looked at it yet, no. After a quick glance at ip6_rcv() and
ip6_rcv_finish(), it looks like it'd be basically the same as the IPv4
code in patches 7 and 8. I'll probably add it in a followup when (if)
this series gets applied.
-Ed
^ permalink raw reply
* [PATCH] liquidio: make timeout HZ independent and readable
From: Nicholas Mc Guire @ 2018-07-02 18:13 UTC (permalink / raw)
To: Derek Chickles
Cc: Satanand Burla, Felix Manlunas, Raghu Vatsavayi, David S. Miller,
netdev, linux-kernel, Nicholas Mc Guire
schedule_timeout_* takes a timeout in jiffies but the code currently is
passing in a constant which makes this timeout HZ dependent. So define
a constant with (hopefully) meaningful name and pass it through
msecs_to_jiffies() to fix the HZ dependency.
Signed-off-by: Nicholas Mc Guire <hofrat@osadl.org>
commit f21fb3ed364b ("Add support of Cavium Liquidio ethernet adapters")
---
Problem found by experimental coccinelle script
The current wait time can vary by a factor 10 depending on the HZ
setting chose, which does not seem reasonable here.
The below patch sets the timeout to 1s - which is the current duration
assuming a setting of HZ== 100. It is though not clear if this is the
intent or if it should be shorter as it is not clear what HZ setting
was assumed during design and used for testing.
This needs an ack by someone who knows the device and can confirm that
waiting 1s for in-flight requests on device removal is reasonable.
Patch was compile tested with: x86_64_defconfig (implies
CONFIG_NET_VENDOR_CAVIUM=y)
(with a large number of sparse warnings though unrelated to the
proposed change)
Patch is against 4.18-rc2 (localversion-next is -next-20180702)
drivers/net/ethernet/cavium/liquidio/lio_main.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/cavium/liquidio/lio_main.c b/drivers/net/ethernet/cavium/liquidio/lio_main.c
index 7cb4e75..b2d0598 100644
--- a/drivers/net/ethernet/cavium/liquidio/lio_main.c
+++ b/drivers/net/ethernet/cavium/liquidio/lio_main.c
@@ -91,6 +91,9 @@ static int octeon_console_debug_enabled(u32 console)
*/
#define LIO_SYNC_OCTEON_TIME_INTERVAL_MS 60000
+/* time to wait for possible in-flight requests in milliseconds */
+#define WAIT_INFLIGHT_REQUEST msecs_to_jiffies(1000)
+
struct lio_trusted_vf_ctx {
struct completion complete;
int status;
@@ -259,7 +262,7 @@ static inline void pcierror_quiesce_device(struct octeon_device *oct)
force_io_queues_off(oct);
/* To allow for in-flight requests */
- schedule_timeout_uninterruptible(100);
+ schedule_timeout_uninterruptible(WAIT_INFLIGHT_REQUEST);
if (wait_for_pending_requests(oct))
dev_err(&oct->pci_dev->dev, "There were pending requests\n");
--
2.1.4
^ permalink raw reply related
* [RFC PATCH v2] ipv6: make ipv6_renew_options() interrupt/kernel safe
From: Paul Moore @ 2018-07-02 18:20 UTC (permalink / raw)
To: netdev; +Cc: Al Viro, selinux, linux-security-module
From: Paul Moore <paul@paul-moore.com>
At present the ipv6_renew_options_kern() function ends up calling into
access_ok() which is problematic if done from inside an interrupt as
access_ok() calls WARN_ON_IN_IRQ() on some (all?) architectures
(x86-64 is affected). Example warning/backtrace is shown below:
WARNING: CPU: 1 PID: 3144 at lib/usercopy.c:11 _copy_from_user+0x85/0x90
...
Call Trace:
<IRQ>
ipv6_renew_option+0xb2/0xf0
ipv6_renew_options+0x26a/0x340
ipv6_renew_options_kern+0x2c/0x40
calipso_req_setattr+0x72/0xe0
netlbl_req_setattr+0x126/0x1b0
selinux_netlbl_inet_conn_request+0x80/0x100
selinux_inet_conn_request+0x6d/0xb0
security_inet_conn_request+0x32/0x50
tcp_conn_request+0x35f/0xe00
? __lock_acquire+0x250/0x16c0
? selinux_socket_sock_rcv_skb+0x1ae/0x210
? tcp_rcv_state_process+0x289/0x106b
tcp_rcv_state_process+0x289/0x106b
? tcp_v6_do_rcv+0x1a7/0x3c0
tcp_v6_do_rcv+0x1a7/0x3c0
tcp_v6_rcv+0xc82/0xcf0
ip6_input_finish+0x10d/0x690
ip6_input+0x45/0x1e0
? ip6_rcv_finish+0x1d0/0x1d0
ipv6_rcv+0x32b/0x880
? ip6_make_skb+0x1e0/0x1e0
__netif_receive_skb_core+0x6f2/0xdf0
? process_backlog+0x85/0x250
? process_backlog+0x85/0x250
? process_backlog+0xec/0x250
process_backlog+0xec/0x250
net_rx_action+0x153/0x480
__do_softirq+0xd9/0x4f7
do_softirq_own_stack+0x2a/0x40
</IRQ>
...
While not present in the backtrace, ipv6_renew_option() ends up calling
access_ok() via the following chain:
access_ok()
_copy_from_user()
copy_from_user()
ipv6_renew_option()
The fix presented in this patch is to perform the userspace copy
earlier in the call chain such that it is only called when the option
data is actually coming from userspace; that place is
do_ipv6_setsockopt(). Not only does this solve the problem seen in
the backtrace above, it also allows us to simplify the code quite a
bit by removing ipv6_renew_options_kern() completely. We also take
this opportunity to cleanup ipv6_renew_options()/ipv6_renew_option()
a small amount as well.
This patch is heavily based on a rough patch by Al Viro. I've taken
his original patch, converted a kmemdup() call in do_ipv6_setsockopt()
to a memdup_user() call, made better use of the e_inval jump target in
the same function, and cleaned up the use ipv6_renew_option() by
ipv6_renew_options().
CC: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Paul Moore <paul@paul-moore.com>
--
v2:
- handle opt == NULL properly in ipv6_renew_options()
---
include/net/ipv6.h | 9 ----
net/ipv6/calipso.c | 9 +---
net/ipv6/exthdrs.c | 111 ++++++++++++----------------------------------
net/ipv6/ipv6_sockglue.c | 27 ++++++++---
4 files changed, 53 insertions(+), 103 deletions(-)
diff --git a/include/net/ipv6.h b/include/net/ipv6.h
index 16475c269749..d02881e4ad1f 100644
--- a/include/net/ipv6.h
+++ b/include/net/ipv6.h
@@ -355,14 +355,7 @@ struct ipv6_txoptions *ipv6_dup_options(struct sock *sk,
struct ipv6_txoptions *ipv6_renew_options(struct sock *sk,
struct ipv6_txoptions *opt,
int newtype,
- struct ipv6_opt_hdr __user *newopt,
- int newoptlen);
-struct ipv6_txoptions *
-ipv6_renew_options_kern(struct sock *sk,
- struct ipv6_txoptions *opt,
- int newtype,
- struct ipv6_opt_hdr *newopt,
- int newoptlen);
+ struct ipv6_opt_hdr *newopt);
struct ipv6_txoptions *ipv6_fixup_options(struct ipv6_txoptions *opt_space,
struct ipv6_txoptions *opt);
diff --git a/net/ipv6/calipso.c b/net/ipv6/calipso.c
index 1323b9679cf7..1c0bb9fb76e6 100644
--- a/net/ipv6/calipso.c
+++ b/net/ipv6/calipso.c
@@ -799,8 +799,7 @@ static int calipso_opt_update(struct sock *sk, struct ipv6_opt_hdr *hop)
{
struct ipv6_txoptions *old = txopt_get(inet6_sk(sk)), *txopts;
- txopts = ipv6_renew_options_kern(sk, old, IPV6_HOPOPTS,
- hop, hop ? ipv6_optlen(hop) : 0);
+ txopts = ipv6_renew_options(sk, old, IPV6_HOPOPTS, hop);
txopt_put(old);
if (IS_ERR(txopts))
return PTR_ERR(txopts);
@@ -1222,8 +1221,7 @@ static int calipso_req_setattr(struct request_sock *req,
if (IS_ERR(new))
return PTR_ERR(new);
- txopts = ipv6_renew_options_kern(sk, req_inet->ipv6_opt, IPV6_HOPOPTS,
- new, new ? ipv6_optlen(new) : 0);
+ txopts = ipv6_renew_options(sk, req_inet->ipv6_opt, IPV6_HOPOPTS, new);
kfree(new);
@@ -1260,8 +1258,7 @@ static void calipso_req_delattr(struct request_sock *req)
if (calipso_opt_del(req_inet->ipv6_opt->hopopt, &new))
return; /* Nothing to do */
- txopts = ipv6_renew_options_kern(sk, req_inet->ipv6_opt, IPV6_HOPOPTS,
- new, new ? ipv6_optlen(new) : 0);
+ txopts = ipv6_renew_options(sk, req_inet->ipv6_opt, IPV6_HOPOPTS, new);
if (!IS_ERR(txopts)) {
txopts = xchg(&req_inet->ipv6_opt, txopts);
diff --git a/net/ipv6/exthdrs.c b/net/ipv6/exthdrs.c
index 5bc2bf3733ab..d44591b51328 100644
--- a/net/ipv6/exthdrs.c
+++ b/net/ipv6/exthdrs.c
@@ -1015,29 +1015,21 @@ ipv6_dup_options(struct sock *sk, struct ipv6_txoptions *opt)
}
EXPORT_SYMBOL_GPL(ipv6_dup_options);
-static int ipv6_renew_option(void *ohdr,
- struct ipv6_opt_hdr __user *newopt, int newoptlen,
- int inherit,
- struct ipv6_opt_hdr **hdr,
- char **p)
+static void ipv6_renew_option(int renewtype,
+ struct ipv6_opt_hdr **dest,
+ struct ipv6_opt_hdr *old,
+ struct ipv6_opt_hdr *new,
+ int newtype, char **p)
{
- if (inherit) {
- if (ohdr) {
- memcpy(*p, ohdr, ipv6_optlen((struct ipv6_opt_hdr *)ohdr));
- *hdr = (struct ipv6_opt_hdr *)*p;
- *p += CMSG_ALIGN(ipv6_optlen(*hdr));
- }
- } else {
- if (newopt) {
- if (copy_from_user(*p, newopt, newoptlen))
- return -EFAULT;
- *hdr = (struct ipv6_opt_hdr *)*p;
- if (ipv6_optlen(*hdr) > newoptlen)
- return -EINVAL;
- *p += CMSG_ALIGN(newoptlen);
- }
- }
- return 0;
+ struct ipv6_opt_hdr *src;
+
+ src = (renewtype == newtype ? new : old);
+ if (!src)
+ return;
+
+ memcpy(*p, src, ipv6_optlen(src));
+ *dest = (struct ipv6_opt_hdr *)*p;
+ p += CMSG_ALIGN(ipv6_optlen(*dest));
}
/**
@@ -1063,13 +1055,11 @@ static int ipv6_renew_option(void *ohdr,
*/
struct ipv6_txoptions *
ipv6_renew_options(struct sock *sk, struct ipv6_txoptions *opt,
- int newtype,
- struct ipv6_opt_hdr __user *newopt, int newoptlen)
+ int newtype, struct ipv6_opt_hdr *newopt)
{
int tot_len = 0;
char *p;
struct ipv6_txoptions *opt2;
- int err;
if (opt) {
if (newtype != IPV6_HOPOPTS && opt->hopopt)
@@ -1082,8 +1072,8 @@ ipv6_renew_options(struct sock *sk, struct ipv6_txoptions *opt,
tot_len += CMSG_ALIGN(ipv6_optlen(opt->dst1opt));
}
- if (newopt && newoptlen)
- tot_len += CMSG_ALIGN(newoptlen);
+ if (newopt)
+ tot_len += CMSG_ALIGN(ipv6_optlen(newopt));
if (!tot_len)
return NULL;
@@ -1098,29 +1088,19 @@ ipv6_renew_options(struct sock *sk, struct ipv6_txoptions *opt,
opt2->tot_len = tot_len;
p = (char *)(opt2 + 1);
- err = ipv6_renew_option(opt ? opt->hopopt : NULL, newopt, newoptlen,
- newtype != IPV6_HOPOPTS,
- &opt2->hopopt, &p);
- if (err)
- goto out;
-
- err = ipv6_renew_option(opt ? opt->dst0opt : NULL, newopt, newoptlen,
- newtype != IPV6_RTHDRDSTOPTS,
- &opt2->dst0opt, &p);
- if (err)
- goto out;
-
- err = ipv6_renew_option(opt ? opt->srcrt : NULL, newopt, newoptlen,
- newtype != IPV6_RTHDR,
- (struct ipv6_opt_hdr **)&opt2->srcrt, &p);
- if (err)
- goto out;
-
- err = ipv6_renew_option(opt ? opt->dst1opt : NULL, newopt, newoptlen,
- newtype != IPV6_DSTOPTS,
- &opt2->dst1opt, &p);
- if (err)
- goto out;
+ ipv6_renew_option(IPV6_HOPOPTS, &opt2->hopopt,
+ (opt ? opt->hopopt : NULL),
+ newopt, newtype, &p);
+ ipv6_renew_option(IPV6_RTHDRDSTOPTS, &opt2->dst0opt,
+ (opt ? opt->dst0opt : NULL),
+ newopt, newtype, &p);
+ ipv6_renew_option(IPV6_RTHDR,
+ (struct ipv6_opt_hdr **)&opt2->srcrt,
+ (opt ? (struct ipv6_opt_hdr *)opt->srcrt : NULL),
+ newopt, newtype, &p);
+ ipv6_renew_option(IPV6_DSTOPTS, &opt2->dst1opt,
+ (opt ? opt->dst1opt : NULL),
+ newopt, newtype, &p);
opt2->opt_nflen = (opt2->hopopt ? ipv6_optlen(opt2->hopopt) : 0) +
(opt2->dst0opt ? ipv6_optlen(opt2->dst0opt) : 0) +
@@ -1128,37 +1108,6 @@ ipv6_renew_options(struct sock *sk, struct ipv6_txoptions *opt,
opt2->opt_flen = (opt2->dst1opt ? ipv6_optlen(opt2->dst1opt) : 0);
return opt2;
-out:
- sock_kfree_s(sk, opt2, opt2->tot_len);
- return ERR_PTR(err);
-}
-
-/**
- * ipv6_renew_options_kern - replace a specific ext hdr with a new one.
- *
- * @sk: sock from which to allocate memory
- * @opt: original options
- * @newtype: option type to replace in @opt
- * @newopt: new option of type @newtype to replace (kernel-mem)
- * @newoptlen: length of @newopt
- *
- * See ipv6_renew_options(). The difference is that @newopt is
- * kernel memory, rather than user memory.
- */
-struct ipv6_txoptions *
-ipv6_renew_options_kern(struct sock *sk, struct ipv6_txoptions *opt,
- int newtype, struct ipv6_opt_hdr *newopt,
- int newoptlen)
-{
- struct ipv6_txoptions *ret_val;
- const mm_segment_t old_fs = get_fs();
-
- set_fs(KERNEL_DS);
- ret_val = ipv6_renew_options(sk, opt, newtype,
- (struct ipv6_opt_hdr __user *)newopt,
- newoptlen);
- set_fs(old_fs);
- return ret_val;
}
struct ipv6_txoptions *ipv6_fixup_options(struct ipv6_txoptions *opt_space,
diff --git a/net/ipv6/ipv6_sockglue.c b/net/ipv6/ipv6_sockglue.c
index 4d780c7f0130..c95c3486d904 100644
--- a/net/ipv6/ipv6_sockglue.c
+++ b/net/ipv6/ipv6_sockglue.c
@@ -398,6 +398,12 @@ static int do_ipv6_setsockopt(struct sock *sk, int level, int optname,
case IPV6_DSTOPTS:
{
struct ipv6_txoptions *opt;
+ struct ipv6_opt_hdr *new = NULL;
+
+ /* hop-by-hop / destination options are privileged option */
+ retv = -EPERM;
+ if (optname != IPV6_RTHDR && !ns_capable(net->user_ns, CAP_NET_RAW))
+ break;
/* remove any sticky options header with a zero option
* length, per RFC3542.
@@ -409,17 +415,22 @@ static int do_ipv6_setsockopt(struct sock *sk, int level, int optname,
else if (optlen < sizeof(struct ipv6_opt_hdr) ||
optlen & 0x7 || optlen > 8 * 255)
goto e_inval;
-
- /* hop-by-hop / destination options are privileged option */
- retv = -EPERM;
- if (optname != IPV6_RTHDR && !ns_capable(net->user_ns, CAP_NET_RAW))
- break;
+ else {
+ new = memdup_user(optval, optlen);
+ if (IS_ERR(new)) {
+ retv = PTR_ERR(new);
+ break;
+ }
+ if (unlikely(ipv6_optlen(new) > optlen)) {
+ kfree(new);
+ goto e_inval;
+ }
+ }
opt = rcu_dereference_protected(np->opt,
lockdep_sock_is_held(sk));
- opt = ipv6_renew_options(sk, opt, optname,
- (struct ipv6_opt_hdr __user *)optval,
- optlen);
+ opt = ipv6_renew_options(sk, opt, optname, new);
+ kfree(new);
if (IS_ERR(opt)) {
retv = PTR_ERR(opt);
break;
^ permalink raw reply related
* Re: [GIT] Networking
From: Linus Torvalds @ 2018-07-02 18:29 UTC (permalink / raw)
To: David Miller, Ursula Braun
Cc: Andrew Morton, Network Development, Linux Kernel Mailing List
In-Reply-To: <20180702.220348.527254946062449999.davem@davemloft.net>
On Mon, Jul 2, 2018 at 6:03 AM David Miller <davem@davemloft.net> wrote:
>
> are available in the Git repository at:
>
> gitolite@ra.kernel.org:/pub/scm/linux/kernel/git/davem/net.git
So the af_smc poll fixes clashed with the revert of the commit that
caused those fixed to be done in the first place.
See the changes to net/smc/af_smc.c in my commit
a11e1d432b51 ("Revert changes to convert to ->poll_mask() and aio
IOCB_CMD_POLL")
vs Ursula's
24ac3a08e658 ("net/smc: rebuild nonblocking connect")
I (briefly) considered just dropping Ursula's changes entirely, but
they looked like a nice cleanup on their own, so what I did instead
was to try to fix up my revert instead.
That involved removing the release_sock/lock_sock pair around the
->poll() call, and removing the special "sock_poll_wait()" that got
re-introduced by my revert, but that Ursula's changes seem to obviate.
However, while I can look at the code and say "my merge makes sense to
me", (a) I can't test it, (b) I don't actually know the rules for SMC
sockets in the first place, and (c) I may be just incompetent.
So Ursula - mind checking and testing the end result? I _think_ it's
fine and the merge looked pretty obvious, but maybe af_smc got broken
again.
[ It's still going through by basic build tests, so I haven't pushed
out my merge yet, but it should be in the usual places in a short
while ]
Thanks,
Linus
^ permalink raw reply
* [PATCH bpf-next v2 0/3] bpf: btf: print bpftool map data with btf
From: Okash Khawaja @ 2018-07-02 18:39 UTC (permalink / raw)
To: Daniel Borkmann, Martin KaFai Lau, Alexei Starovoitov,
Yonghong Song, Quentin Monnet, Jakub Kicinski, David S. Miller
Cc: netdev, kernel-team, linux-kernel
Hi,
This is v2. There are two key changes which mostly affect patches 2 and 3.
First, we have two BTF outputs:
1. when -j or -p switches are supplied to a map command - this is json- and
backward- compatible
2. when neither of -j and -p is supplied - this makes no promises on json- or
backward- compatibility, and aimed for humans
Second, in addition to map dump command, map lookup command has also been
updated to print data with btf. The rules around -j and -p are same as above.
Here is a summary of changes in v2:
patch 1:
- line continuation alignment fixes + other style fixes
patch 2:
- introduce struct btf_dumper which contains context for btf_dumper operation
- line continuation alignment fixes + other style fixes
- fix SPDX licence comment style to be C++ style
- reverse christmas tree style comments
- in btf_dumper_array() ensure we end json_writer array in case of error
patch 3:
- btf output for humans is shown when neither -j nor -p is supplied
- when -j or -p are supplied, augment output with "formatted" object which shows btf data in json
- added btf output to map lookup command also
- declarations to follow reverse christmas tree style
- error message grammar fix and remove full stop
- line continuation alignment fixes + other style fixes
- reorganise do_dump_btf() to remove goto and make it clearer
- remove misleading comment about end of root json object
- add comment to explain allocation btf buffer
- brackets around else clause to harmonise with braces on if clause
Thanks,
Okash
^ permalink raw reply
* [PATCH bpf-next v2 2/3] bpf: btf: add btf print functionality
From: Okash Khawaja @ 2018-07-02 18:39 UTC (permalink / raw)
To: Daniel Borkmann, Martin KaFai Lau, Alexei Starovoitov,
Yonghong Song, Quentin Monnet, Jakub Kicinski, David S. Miller
Cc: netdev, kernel-team, linux-kernel
In-Reply-To: <20180702183913.669030439@fb.com>
[-- Attachment #1: 02-add-btf-dump-map.patch --]
[-- Type: text/plain, Size: 9608 bytes --]
This consumes functionality exported in the previous patch. It does the
main job of printing with BTF data. This is used in the following patch
to provide a more readable output of a map's dump. It relies on
json_writer to do json printing. Below is sample output where map keys
are ints and values are of type struct A:
typedef int int_type;
enum E {
E0,
E1,
};
struct B {
int x;
int y;
};
struct A {
int m;
unsigned long long n;
char o;
int p[8];
int q[4][8];
enum E r;
void *s;
struct B t;
const int u;
int_type v;
unsigned int w1: 3;
unsigned int w2: 3;
};
$ sudo bpftool map dump id 14
[{
"key": 0,
"value": {
"m": 1,
"n": 2,
"o": "c",
"p": [15,16,17,18,15,16,17,18
],
"q": [[25,26,27,28,25,26,27,28
],[35,36,37,38,35,36,37,38
],[45,46,47,48,45,46,47,48
],[55,56,57,58,55,56,57,58
]
],
"r": 1,
"s": 0x7ffd80531cf8,
"t": {
"x": 5,
"y": 10
},
"u": 100,
"v": 20,
"w1": 0x7,
"w2": 0x3
}
}
]
This patch uses json's {} and [] to imply struct/union and array. More
explicit information can be added later. For example, a command line
option can be introduced to print whether a key or value is struct
or union, name of a struct etc. This will however come at the expense
of duplicating info when, for example, printing an array of structs.
enums are printed as ints without their names.
Signed-off-by: Okash Khawaja <osk@fb.com>
---
tools/bpf/bpftool/btf_dumper.c | 263 +++++++++++++++++++++++++++++++++++++++++
tools/bpf/bpftool/btf_dumper.h | 23 +++
2 files changed, 286 insertions(+)
--- /dev/null
+++ b/tools/bpf/bpftool/btf_dumper.c
@@ -0,0 +1,263 @@
+// SPDX-License-Identifier: GPL-2.0
+/* Copyright (c) 2018 Facebook */
+
+#include <linux/btf.h>
+#include <linux/err.h>
+#include <stdio.h> /* for (FILE *) used by json_writer */
+#include <linux/bitops.h>
+#include <string.h>
+#include <ctype.h>
+
+#include "btf.h"
+#include "json_writer.h"
+#include "btf_dumper.h"
+
+#define BITS_PER_BYTE_MASK (BITS_PER_BYTE - 1)
+#define BITS_PER_BYTE_MASKED(bits) ((bits) & BITS_PER_BYTE_MASK)
+#define BITS_ROUNDDOWN_BYTES(bits) ((bits) >> 3)
+#define BITS_ROUNDUP_BYTES(bits) \
+ (BITS_ROUNDDOWN_BYTES(bits) + !!BITS_PER_BYTE_MASKED(bits))
+
+static int btf_dumper_do_type(const struct btf_dumper *d, uint32_t type_id,
+ uint8_t bit_offset, const void *data);
+
+static void btf_dumper_ptr(const void *data, json_writer_t *jw,
+ bool is_plain_text)
+{
+ if (is_plain_text)
+ jsonw_printf(jw, "%p", *((uintptr_t *)data));
+ else
+ jsonw_printf(jw, "%u", *((uintptr_t *)data));
+}
+
+static int btf_dumper_modifier(const struct btf_dumper *d, uint32_t type_id,
+ const void *data)
+{
+ int32_t actual_type_id = btf__resolve_type(d->btf, type_id);
+ int ret;
+
+ if (actual_type_id < 0)
+ return actual_type_id;
+
+ ret = btf_dumper_do_type(d, actual_type_id, 0, data);
+
+ return ret;
+}
+
+static void btf_dumper_enum(const void *data, json_writer_t *jw)
+{
+ jsonw_printf(jw, "%d", *((int32_t *)data));
+}
+
+static int btf_dumper_array(const struct btf_dumper *d, uint32_t type_id,
+ const void *data)
+{
+ const struct btf_type *t = btf__type_by_id(d->btf, type_id);
+ struct btf_array *arr = (struct btf_array *)(t + 1);
+ int64_t elem_size;
+ int ret = 0;
+ uint32_t i;
+
+ elem_size = btf__resolve_size(d->btf, arr->type);
+ if (elem_size < 0)
+ return elem_size;
+
+ jsonw_start_array(d->jw);
+ for (i = 0; i < arr->nelems; i++) {
+ ret = btf_dumper_do_type(d, arr->type, 0,
+ data + (i * elem_size));
+ if (ret)
+ break;
+ }
+
+ jsonw_end_array(d->jw);
+ return ret;
+}
+
+static void btf_dumper_int_bits(uint32_t int_type, uint8_t bit_offset,
+ const void *data, json_writer_t *jw,
+ bool is_plain_text)
+{
+ uint32_t bits = BTF_INT_BITS(int_type);
+ uint16_t total_bits_offset;
+ uint16_t bytes_to_copy;
+ uint16_t bits_to_copy;
+ uint8_t upper_bits;
+ union {
+ uint64_t u64_num;
+ uint8_t u8_nums[8];
+ } print_num;
+
+ total_bits_offset = bit_offset + BTF_INT_OFFSET(int_type);
+ data += BITS_ROUNDDOWN_BYTES(total_bits_offset);
+ bit_offset = BITS_PER_BYTE_MASKED(total_bits_offset);
+ bits_to_copy = bits + bit_offset;
+ bytes_to_copy = BITS_ROUNDUP_BYTES(bits_to_copy);
+
+ print_num.u64_num = 0;
+ memcpy(&print_num.u64_num, data, bytes_to_copy);
+
+ upper_bits = BITS_PER_BYTE_MASKED(bits_to_copy);
+ if (upper_bits) {
+ uint8_t mask = (1 << upper_bits) - 1;
+
+ print_num.u8_nums[bytes_to_copy - 1] &= mask;
+ }
+
+ print_num.u64_num >>= bit_offset;
+
+ if (is_plain_text)
+ jsonw_printf(jw, "0x%llx", print_num.u64_num);
+ else
+ jsonw_printf(jw, "%llu", print_num.u64_num);
+}
+
+static int btf_dumper_int(const struct btf_type *t, uint8_t bit_offset,
+ const void *data, json_writer_t *jw,
+ bool is_plain_text)
+{
+ uint32_t *int_type = (uint32_t *)(t + 1);
+ uint32_t bits = BTF_INT_BITS(*int_type);
+ int ret = 0;
+
+ /* if this is bit field */
+ if (bit_offset || BTF_INT_OFFSET(*int_type) ||
+ BITS_PER_BYTE_MASKED(bits)) {
+ btf_dumper_int_bits(*int_type, bit_offset, data, jw,
+ is_plain_text);
+ return ret;
+ }
+
+ switch (BTF_INT_ENCODING(*int_type)) {
+ case 0:
+ if (BTF_INT_BITS(*int_type) == 64)
+ jsonw_printf(jw, "%lu", *((uint64_t *)data));
+ else if (BTF_INT_BITS(*int_type) == 32)
+ jsonw_printf(jw, "%u", *((uint32_t *)data));
+ else if (BTF_INT_BITS(*int_type) == 16)
+ jsonw_printf(jw, "%hu", *((uint16_t *)data));
+ else if (BTF_INT_BITS(*int_type) == 8)
+ jsonw_printf(jw, "%hhu", *((uint8_t *)data));
+ else
+ btf_dumper_int_bits(*int_type, bit_offset, data, jw,
+ is_plain_text);
+ break;
+ case BTF_INT_SIGNED:
+ if (BTF_INT_BITS(*int_type) == 64)
+ jsonw_printf(jw, "%ld", *((int64_t *)data));
+ else if (BTF_INT_BITS(*int_type) == 32)
+ jsonw_printf(jw, "%d", *((int32_t *)data));
+ else if (BTF_INT_BITS(*int_type) == 16)
+ jsonw_printf(jw, "%hd", *((int16_t *)data));
+ else if (BTF_INT_BITS(*int_type) == 8)
+ jsonw_printf(jw, "%hhd", *((int8_t *)data));
+ else
+ btf_dumper_int_bits(*int_type, bit_offset, data, jw,
+ is_plain_text);
+ break;
+ case BTF_INT_CHAR:
+ if (*((char *)data) == '\0')
+ jsonw_null(jw);
+ else if (isprint(*((char *)data)))
+ jsonw_printf(jw, "\"%c\"", *((char *)data));
+ else
+ if (is_plain_text)
+ jsonw_printf(jw, "%hhx", *((char *)data));
+ else
+ jsonw_printf(jw, "%hhd", *((char *)data));
+ break;
+ case BTF_INT_BOOL:
+ jsonw_bool(jw, *((int *)data));
+ break;
+ default:
+ /* shouldn't happen */
+ ret = -EINVAL;
+ break;
+ }
+
+ return ret;
+}
+
+static int btf_dumper_struct(const struct btf_dumper *d, uint32_t type_id,
+ const void *data)
+{
+ const struct btf_type *t = btf__type_by_id(d->btf, type_id);
+ struct btf_member *m;
+ int ret = 0;
+ int i, vlen;
+
+ if (!t)
+ return -EINVAL;
+
+ vlen = BTF_INFO_VLEN(t->info);
+ jsonw_start_object(d->jw);
+ m = (struct btf_member *)(t + 1);
+
+ for (i = 0; i < vlen; i++) {
+ jsonw_name(d->jw, btf__name_by_offset(d->btf, m[i].name_off));
+ ret = btf_dumper_do_type(d, m[i].type,
+ BITS_PER_BYTE_MASKED(m[i].offset), data
+ + BITS_ROUNDDOWN_BYTES(m[i].offset));
+ if (ret)
+ return ret;
+ }
+
+ jsonw_end_object(d->jw);
+
+ return 0;
+}
+
+static int btf_dumper_do_type(const struct btf_dumper *d, uint32_t type_id,
+ uint8_t bit_offset, const void *data)
+{
+ const struct btf_type *t = btf__type_by_id(d->btf, type_id);
+ int ret = 0;
+
+ switch (BTF_INFO_KIND(t->info)) {
+ case BTF_KIND_INT:
+ ret = btf_dumper_int(t, bit_offset, data, d->jw,
+ d->is_plain_text);
+ break;
+ case BTF_KIND_STRUCT:
+ case BTF_KIND_UNION:
+ ret = btf_dumper_struct(d, type_id, data);
+ break;
+ case BTF_KIND_ARRAY:
+ ret = btf_dumper_array(d, type_id, data);
+ break;
+ case BTF_KIND_ENUM:
+ btf_dumper_enum(data, d->jw);
+ break;
+ case BTF_KIND_PTR:
+ btf_dumper_ptr(data, d->jw, d->is_plain_text);
+ break;
+ case BTF_KIND_UNKN:
+ jsonw_printf(d->jw, "(unknown)");
+ break;
+ case BTF_KIND_FWD:
+ /* map key or value can't be forward */
+ ret = -EINVAL;
+ break;
+ case BTF_KIND_TYPEDEF:
+ case BTF_KIND_VOLATILE:
+ case BTF_KIND_CONST:
+ case BTF_KIND_RESTRICT:
+ ret = btf_dumper_modifier(d, type_id, data);
+ break;
+ default:
+ jsonw_printf(d->jw, "(unsupported-kind");
+ ret = -EINVAL;
+ break;
+ }
+
+ return ret;
+}
+
+int32_t btf_dumper_type(const struct btf_dumper *d, uint32_t type_id,
+ const void *data)
+{
+ if (!d)
+ return -EINVAL;
+
+ return btf_dumper_do_type(d, type_id, 0, data);
+}
--- /dev/null
+++ b/tools/bpf/bpftool/btf_dumper.h
@@ -0,0 +1,23 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/* Copyright (c) 2018 Facebook */
+
+#ifndef BTF_DUMPER_H
+#define BTF_DUMPER_H
+
+struct btf_dumper {
+ const struct btf *btf;
+ json_writer_t *jw;
+ bool is_plain_text;
+};
+
+/* btf_dumper_type - print data along with type information
+ * @d: an instance containing context for dumping types
+ * @type_id: index in btf->types array. this points to the type to be dumped
+ * @data: pointer the actual data, i.e. the values to be printed
+ *
+ * Returns zero on success and negative error code otherwise
+ */
+int32_t btf_dumper_type(const struct btf_dumper *d, uint32_t type_id,
+ const void *data);
+
+#endif
^ 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