* [PATCH net-next] dpaa2-eth: Don't account Tx confirmation frames on NAPI poll
From: Ioana Ciocoi Radulescu @ 2018-10-08 14:16 UTC (permalink / raw)
To: netdev@vger.kernel.org, davem@davemloft.net; +Cc: Ioana Ciornei
Until now, both Rx and Tx confirmation frames handled during
NAPI poll were counted toward the NAPI budget. However, Tx
confirmations are lighter to process than Rx frames, which can
skew the amount of work actually done inside one NAPI cycle.
Update the code to only count Rx frames toward the NAPI budget
and set a separate threshold on how many Tx conf frames can be
processed in one poll cycle.
The NAPI poll routine stops when either the budget is consumed
by Rx frames or when Tx confirmation frames reach this threshold.
Signed-off-by: Ioana Radulescu <ruxandra.radulescu@nxp.com>
---
drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.c | 68 +++++++++++++++---------
drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.h | 5 ++
2 files changed, 47 insertions(+), 26 deletions(-)
diff --git a/drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.c b/drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.c
index 108c137..156080d 100644
--- a/drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.c
+++ b/drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.c
@@ -289,10 +289,11 @@ static void dpaa2_eth_rx(struct dpaa2_eth_priv *priv,
*
* Observance of NAPI budget is not our concern, leaving that to the caller.
*/
-static int consume_frames(struct dpaa2_eth_channel *ch)
+static int consume_frames(struct dpaa2_eth_channel *ch,
+ enum dpaa2_eth_fq_type *type)
{
struct dpaa2_eth_priv *priv = ch->priv;
- struct dpaa2_eth_fq *fq;
+ struct dpaa2_eth_fq *fq = NULL;
struct dpaa2_dq *dq;
const struct dpaa2_fd *fd;
int cleaned = 0;
@@ -311,12 +312,23 @@ static int consume_frames(struct dpaa2_eth_channel *ch)
fd = dpaa2_dq_fd(dq);
fq = (struct dpaa2_eth_fq *)(uintptr_t)dpaa2_dq_fqd_ctx(dq);
- fq->stats.frames++;
fq->consume(priv, ch, fd, &ch->napi, fq->flowid);
cleaned++;
} while (!is_last);
+ if (!cleaned)
+ return 0;
+
+ fq->stats.frames += cleaned;
+ ch->stats.frames += cleaned;
+
+ /* A dequeue operation only pulls frames from a single queue
+ * into the store. Return the frame queue type as an out param.
+ */
+ if (type)
+ *type = fq->type;
+
return cleaned;
}
@@ -921,14 +933,16 @@ static int pull_channel(struct dpaa2_eth_channel *ch)
static int dpaa2_eth_poll(struct napi_struct *napi, int budget)
{
struct dpaa2_eth_channel *ch;
- int cleaned = 0, store_cleaned;
struct dpaa2_eth_priv *priv;
+ int rx_cleaned = 0, txconf_cleaned = 0;
+ enum dpaa2_eth_fq_type type;
+ int store_cleaned;
int err;
ch = container_of(napi, struct dpaa2_eth_channel, napi);
priv = ch->priv;
- while (cleaned < budget) {
+ do {
err = pull_channel(ch);
if (unlikely(err))
break;
@@ -936,30 +950,32 @@ static int dpaa2_eth_poll(struct napi_struct *napi, int budget)
/* Refill pool if appropriate */
refill_pool(priv, ch, priv->bpid);
- store_cleaned = consume_frames(ch);
- cleaned += store_cleaned;
+ store_cleaned = consume_frames(ch, &type);
+ if (type == DPAA2_RX_FQ)
+ rx_cleaned += store_cleaned;
+ else
+ txconf_cleaned += store_cleaned;
- /* If we have enough budget left for a full store,
- * try a new pull dequeue, otherwise we're done here
+ /* If we either consumed the whole NAPI budget with Rx frames
+ * or we reached the Tx confirmations threshold, we're done.
*/
- if (store_cleaned == 0 ||
- cleaned > budget - DPAA2_ETH_STORE_SIZE)
- break;
- }
-
- if (cleaned < budget && napi_complete_done(napi, cleaned)) {
- /* Re-enable data available notifications */
- do {
- err = dpaa2_io_service_rearm(ch->dpio, &ch->nctx);
- cpu_relax();
- } while (err == -EBUSY);
- WARN_ONCE(err, "CDAN notifications rearm failed on core %d",
- ch->nctx.desired_cpu);
- }
+ if (rx_cleaned >= budget ||
+ txconf_cleaned >= DPAA2_ETH_TXCONF_PER_NAPI)
+ return budget;
+ } while (store_cleaned);
- ch->stats.frames += cleaned;
+ /* We didn't consume the entire budget, so finish napi and
+ * re-enable data availability notifications
+ */
+ napi_complete_done(napi, rx_cleaned);
+ do {
+ err = dpaa2_io_service_rearm(ch->dpio, &ch->nctx);
+ cpu_relax();
+ } while (err == -EBUSY);
+ WARN_ONCE(err, "CDAN notifications rearm failed on core %d",
+ ch->nctx.desired_cpu);
- return cleaned;
+ return max(rx_cleaned, 1);
}
static void enable_ch_napi(struct dpaa2_eth_priv *priv)
@@ -1076,7 +1092,7 @@ static u32 drain_channel(struct dpaa2_eth_priv *priv,
do {
pull_channel(ch);
- drained = consume_frames(ch);
+ drained = consume_frames(ch, NULL);
total += drained;
} while (drained);
diff --git a/drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.h b/drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.h
index 7a7a3e7..452a8e9 100644
--- a/drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.h
+++ b/drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.h
@@ -40,6 +40,11 @@
*/
#define DPAA2_ETH_TAILDROP_THRESH (64 * 1024)
+/* Maximum number of Tx confirmation frames to be processed
+ * in a single NAPI call
+ */
+#define DPAA2_ETH_TXCONF_PER_NAPI 256
+
/* Buffer quota per queue. Must be large enough such that for minimum sized
* frames taildrop kicks in before the bpool gets depleted, so we compute
* how many 64B frames fit inside the taildrop threshold and add a margin
--
2.7.4
^ permalink raw reply related
* Re: [PATCH net-next 19/19] net: usb: aqc111: Add support for wake on LAN by MAGIC packet
From: Igor Russkikh @ 2018-10-08 14:12 UTC (permalink / raw)
To: Andrew Lunn
Cc: David S . Miller, linux-usb@vger.kernel.org,
netdev@vger.kernel.org, Dmitry Bezrukov
In-Reply-To: <20181006174921.GG6990@lunn.ch>
Hi Andrew,
>> + if (aqc111_data->dpa) {
>> + aqc111_set_phy_speed(dev, AUTONEG_DISABLE, SPEED_100);
>
> I don't think that works. You should leave AUTONEG on, but only
> advertise SPEED_100 and trigger auto-neg. If you force it to 100,
> there is no guarantee the peer will figure out what the new link speed
> is. I've often seen failed auto-net result in 10/Half. So you will
> loose the link, making WoL pointless.
Phy does not support 10M, low power mode explicitly uses 100M
for power safety reasons.
It is meaningless here to add Autoneg to 100M because thats the only
speedmask bit anyway.
>> + aqc111_set_phy_speed(dev, aqc111_data->autoneg,
>> + aqc111_data->advertised_speed);
>> +
>
> Should that be conditional on aqc111_data->dpa?
Actually no, because set_phy_speed internally checks this flag.
>> + u8 rsvd[283];
>> +};
>
> Do you really need these 283 bytes??
>> struct aqc111_phy_options phy_ops;
>> + struct aqc111_wol_cfg wol_cfg;
>
> Those 283 bytes make this whole structure bigger...
FW interface expects the WOL config request WOL_CFG_SIZE bytes.
These reserved fields are just not used now by linux driver.
They configure extra wol features like a sleep proxy.
Thus, we anyway have to allocate this somewhere.
Regards,
Igor
^ permalink raw reply
* Re: [PATCH net-next 06/19] net: usb: aqc111: Introduce link management
From: Oliver Neukum @ 2018-10-08 13:59 UTC (permalink / raw)
To: Igor Russkikh, David S . Miller
Cc: Dmitry Bezrukov, linux-usb@vger.kernel.org,
netdev@vger.kernel.org
In-Reply-To: <cec5cd88988e0985e3fdd1343906ef649b01f646.1538734658.git.igor.russkikh@aquantia.com>
On Fr, 2018-10-05 at 10:24 +0000, Igor Russkikh wrote:
> From: Dmitry Bezrukov <dmitry.bezrukov@aquantia.com>
>
> +static void aqc111_configure_rx(struct usbnet *dev,
> + struct aqc111_data *aqc111_data)
> +{
> + u8 reg8 = 0;
> + u8 queue_num = 0;
> + u16 reg16 = 0;
> + u16 link_speed = 0, usb_host = 0;
> + u8 buf[5] = { 0 };
DMA on stack.
> + enum usb_device_speed usb_speed = dev->udev->speed;
> +
> + buf[0] = 0x00;
> + buf[1] = 0xF8;
> + buf[2] = 0x07;
> + switch (aqc111_data->link_speed) {
> + case AQ_INT_SPEED_5G:
> + {
> + link_speed = 5000;
> + reg8 = 0x05;
> + reg16 = 0x001F;
> + break;
> + }
> + case AQ_INT_SPEED_2_5G:
> + {
> + link_speed = 2500;
> + reg16 = 0x003F;
> + break;
> + }
> + case AQ_INT_SPEED_1G:
> + {
> + link_speed = 1000;
> + reg16 = 0x009F;
> + break;
> + }
> + case AQ_INT_SPEED_100M:
> + {
> + link_speed = 100;
> + queue_num = 1;
> + reg16 = 0x063F;
> + buf[1] = 0xFB;
> + buf[2] = 0x4;
> + break;
> + }
> + }
> +
> + if (aqc111_data->dpa) {
> + /* Set Phy Flow control */
> + aq_mdio_write_cmd(dev, AQ_GLB_ING_PAUSE_CTRL_REG,
> + AQ_PHY_AUTONEG_ADDR, 2, ®16);
> + aq_mdio_write_cmd(dev, AQ_GLB_EGR_PAUSE_CTRL_REG,
> + AQ_PHY_AUTONEG_ADDR, 2, ®16);
> + }
> +
> + aqc111_write_cmd(dev, AQ_ACCESS_MAC, SFR_INTER_PACKET_GAP_0,
> + 1, 1, ®8);
> +
> + aqc111_write_cmd(dev, AQ_ACCESS_MAC, SFR_TX_PAUSE_RESEND_T, 3, 3, buf);
> +
> + switch (usb_speed) {
Needs to handle all speeds. And please add a comment explaining the
rationale.
> + case USB_SPEED_SUPER:
> + {
> + usb_host = 3;
> + break;
> + }
> + case USB_SPEED_HIGH:
> + {
> + usb_host = 2;
> + break;
> + }
> + case USB_SPEED_FULL:
> + case USB_SPEED_LOW:
> + {
> + usb_host = 1;
> + queue_num = 0;
> + break;
> + }
> + default:
> + {
> + usb_host = 0;
> + break;
> + }
> + }
> +
> + memcpy(buf, &AQC111_BULKIN_SIZE[queue_num], 5);
> + /* RX bulk configuration */
> + aqc111_write_cmd(dev, AQ_ACCESS_MAC, SFR_RX_BULKIN_QCTRL, 5, 5, buf);
> +
> + /* Set high low water level */
> + reg16 = 0x0810;
> +
> + aqc111_write_cmd(dev, AQ_ACCESS_MAC, SFR_PAUSE_WATERLVL_LOW,
> + 2, 2, ®16);
> + netdev_info(dev->net, "Link Speed %d, USB %d", link_speed, usb_host);
> +}
Regards
Oliver
^ permalink raw reply
* Re: [PATCH] bpf: btf: Fix a missing check bug
From: valdis.kletnieks @ 2018-10-08 21:17 UTC (permalink / raw)
To: Song Liu
Cc: wang6495, kjlu, Alexei Starovoitov, Daniel Borkmann, Networking,
open list
In-Reply-To: <CAPhsuW5vnVjRS7DWFYPSmq5G-dAFxOrHCAOMkK-iaOoirzMazQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1069 bytes --]
On Mon, 08 Oct 2018 13:51:09 -0700, Song Liu said:
> On Sun, Oct 7, 2018 at 1:26 PM Wenwen Wang <wang6495@umn.edu> wrote:
> > same value. Given that the btf data is in the user space, a malicious user
> > can race to change the data between the two copies. By doing so, the user
> > can provide malicious data to the kernel and cause undefined behavior.
> These two numbers are copied from same memory location, right? So I
> think this check is not necessary?
Security researchers call this a TOCTOU bug - Time of Check - Time of Use.
What can happen:
1) We fetch the value (say we get 90) from userspace and stash it in hdr_len.
2) We do some other stuff like check the hdr_len isn't too big, etc..
meanwhile, on another CPU running another thread of the process...
3) malicious code stuffs a 117 into that field
4) We fetch the entire header, incliding a now-changed hdr_len (now 117) and
stick it in btf->hdr->hdr_len.
5) Any code that assumes that hdr_len and btf->hdr->hdr_len are the same value
explodes in interesting ways.
[-- Attachment #2: Type: application/pgp-signature, Size: 486 bytes --]
^ permalink raw reply
* Re: [PATCH net-next 05/19] net: usb: aqc111: Introduce PHY access
From: Oliver Neukum @ 2018-10-08 13:52 UTC (permalink / raw)
To: Igor Russkikh, David S . Miller
Cc: Dmitry Bezrukov, linux-usb@vger.kernel.org,
netdev@vger.kernel.org
In-Reply-To: <6b4837b970d7709bc2e11d89a7e21e5f10584e30.1538734658.git.igor.russkikh@aquantia.com>
On Fr, 2018-10-05 at 10:24 +0000, Igor Russkikh wrote:
> From: Dmitry Bezrukov <dmitry.bezrukov@aquantia.com>
>
> Implement PHY power up/down sequences.
> AQC111, depending on FW used, may has PHY being controlled either
> directly (dpa = 1) or via vendor command interface (dpa = 0).
> Drivers supports both themes.
> We determine this from firmware versioning agreement.
>
> Signed-off-by: Dmitry Bezrukov <dmitry.bezrukov@aquantia.com>
> Signed-off-by: Igor Russkikh <igor.russkikh@aquantia.com>
> ---
> drivers/net/usb/aqc111.c | 93 ++++++++++++++++++++++++++++++++++++++++++++++++
> drivers/net/usb/aqc111.h | 70 ++++++++++++++++++++++++++++++++++++
> 2 files changed, 163 insertions(+)
>
> diff --git a/drivers/net/usb/aqc111.c b/drivers/net/usb/aqc111.c
> index 22bb259d71fb..30219bb6ddfd 100644
> --- a/drivers/net/usb/aqc111.c
> +++ b/drivers/net/usb/aqc111.c
> @@ -138,15 +138,44 @@ static int aqc111_write_cmd(struct usbnet *dev, u8 cmd, u16 value,
> return __aqc111_write_cmd(dev, cmd, value, index, size, data, 0);
> }
>
> +static int aq_mdio_read_cmd(struct usbnet *dev, u16 value, u16 index,
> + u16 size, void *data)
> +{
> + return aqc111_read_cmd(dev, AQ_PHY_CMD, value, index, size, data);
> +}
> +
> +static int aq_mdio_write_cmd(struct usbnet *dev, u16 value, u16 index,
> + u16 size, void *data)
> +{
> + return aqc111_write_cmd(dev, AQ_PHY_CMD, value, index, size, data);
> +}
> +
> static const struct net_device_ops aqc111_netdev_ops = {
> .ndo_open = usbnet_open,
> .ndo_stop = usbnet_stop,
> };
>
> +static void aqc111_read_fw_version(struct usbnet *dev,
> + struct aqc111_data *aqc111_data)
> +{
> + aqc111_read_cmd(dev, AQ_ACCESS_MAC, AQ_FW_VER_MAJOR,
> + 1, 1, &aqc111_data->fw_ver.major);
> + aqc111_read_cmd(dev, AQ_ACCESS_MAC, AQ_FW_VER_MINOR,
> + 1, 1, &aqc111_data->fw_ver.minor);
> + aqc111_read_cmd(dev, AQ_ACCESS_MAC, AQ_FW_VER_REV,
> + 1, 1, &aqc111_data->fw_ver.rev);
Why read the stuff you don't need?
> +
> + if (aqc111_data->fw_ver.major & 0x80)
> + aqc111_data->fw_ver.major &= ~0x80;
> + else
> + aqc111_data->dpa = 1;
> +}
> +
> static int aqc111_bind(struct usbnet *dev, struct usb_interface *intf)
> {
> int ret;
> struct usb_device *udev = interface_to_usbdev(intf);
> + struct aqc111_data *aqc111_data;
>
> /* Check if vendor configuration */
> if (udev->actconfig->desc.bConfigurationValue != 1) {
> @@ -162,8 +191,18 @@ static int aqc111_bind(struct usbnet *dev, struct usb_interface *intf)
> return ret;
> }
>
> + aqc111_data = kzalloc(sizeof(*aqc111_data), GFP_KERNEL);
> + if (!aqc111_data)
> + return -ENOMEM;
> +
> + /* store aqc111_data pointer in device data field */
> + dev->data[0] = (unsigned long)aqc111_data;
> + memset(aqc111_data, 0, sizeof(*aqc111_data));
Either kzalloc() or a memset. Not both.
> +
> dev->net->netdev_ops = &aqc111_netdev_ops;
>
> + aqc111_read_fw_version(dev, aqc111_data);
> +
> return 0;
> }
Regards
Oliver
^ permalink raw reply
* Re: [PATCH v8 08/15] octeontx2-af: Add RVU block LF provisioning support
From: Sunil Kovvuri @ 2018-10-08 13:59 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Linux Netdev List, David S. Miller, linux-soc, Sunil Goutham
In-Reply-To: <CAK8P3a3koXRBzLmuaBOD2GmdV8v6AdKDNr+tGCTQCz5yjzQ7wQ@mail.gmail.com>
On Mon, Oct 8, 2018 at 5:41 PM Arnd Bergmann <arnd@arndb.de> wrote:
>
> On Sun, Oct 7, 2018 at 5:00 PM <sunil.kovvuri@gmail.com> wrote:
> >
> > +/* Structure for requesting resource provisioning.
> > + * 'modify' flag to be used when either requesting more
> > + * or to detach partial of a cetain resource type.
> > + * Rest of the fields specify how many of what type to
> > + * be attached.
> > + */
> > +struct rsrc_attach {
> > + struct mbox_msghdr hdr;
> > + u8 modify:1;
> > + u8 npalf:1;
> > + u8 nixlf:1;
> > + u16 sso;
> > + u16 ssow;
> > + u16 timlfs;
> > + u16 cptlfs;
> > +};
> > +
> > +/* Structure for relinquishing resources.
> > + * 'partial' flag to be used when relinquishing all resources
> > + * but only of a certain type. If not set, all resources of all
> > + * types provisioned to the RVU function will be detached.
> > + */
> > +struct rsrc_detach {
> > + struct mbox_msghdr hdr;
> > + u8 partial:1;
> > + u8 npalf:1;
> > + u8 nixlf:1;
> > + u8 sso:1;
> > + u8 ssow:1;
> > + u8 timlfs:1;
> > + u8 cptlfs:1;
> > +};
>
> Are these bitfields part of the message that gets sent to the
> underlying implementation? It seems there is still an endianess
> issue then.
>
> Arnd
No these structures are not used for kernel driver to firmware
communication where
register reads via readq are involved. These structures are used for
mailbox communication
between different PCI devices and this mailbox is a shared memory.
Sunil.
^ permalink raw reply
* Re: [PATCH 1/9] PCI: sysfs: Export available PCIe bandwidth
From: Alex_Gagniuc @ 2018-10-08 21:09 UTC (permalink / raw)
To: helgaas
Cc: mr.nuke.me, linux-pci, bhelgaas, keith.busch, Austin.Bolen,
Shyam.Iyer, ariel.elior, everest-linux-l2, davem, michael.chan,
ganeshgr, jeffrey.t.kirsher, tariqt, saeedm, leon, jakub.kicinski,
dirk.vandermerwe, netdev, linux-kernel, intel-wired-lan,
linux-rdma, oss-drivers, stephen, mj, alex.williamson
In-Reply-To: <20181004204549.GI120535@bhelgaas-glaptop.roam.corp.google.com>
On 10/04/2018 03:45 PM, Bjorn Helgaas wrote:
>
> [EXTERNAL EMAIL]
> Please report any suspicious attachments, links, or requests for sensitive information.
>
>
> [+cc Alex (VC mentioned below)]
>
> On Wed, Oct 03, 2018 at 10:00:19PM +0000, Alex_Gagniuc@Dellteam.com wrote:
>> On 10/03/2018 04:31 PM, Bjorn Helgaas wrote:
>>> On Mon, Sep 03, 2018 at 01:02:28PM -0500, Alexandru Gagniuc wrote:
>>>> For certain bandwidth-critical devices (e.g. multi-port network cards)
>>>> it is useful to know the available bandwidth to the root complex. This
>>>> information is only available via the system log, which doesn't
>>>> account for link degradation after probing.
>>>>
>>>> With a sysfs attribute, we can computes the bandwidth on-demand, and
>>>> will detect degraded links.
>>>>
>>>> Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
>>>> ---
>>>> drivers/pci/pci-sysfs.c | 13 +++++++++++++
>>>> 1 file changed, 13 insertions(+)
>>>>
>>>> diff --git a/drivers/pci/pci-sysfs.c b/drivers/pci/pci-sysfs.c
>>>> index 9ecfe13157c0..6658e927b1f5 100644
>>>> --- a/drivers/pci/pci-sysfs.c
>>>> +++ b/drivers/pci/pci-sysfs.c
>>>> @@ -218,6 +218,18 @@ static ssize_t current_link_width_show(struct device *dev,
>>>> }
>>>> static DEVICE_ATTR_RO(current_link_width);
>>>>
>>>> +static ssize_t available_bandwidth_show(struct device *dev,
>>>> + struct device_attribute *attr, char *buf)
>>>> +{
>>>> + struct pci_dev *pci_dev = to_pci_dev(dev);
>>>> + u32 bw_avail;
>>>> +
>>>> + bw_avail = pcie_bandwidth_available(pci_dev, NULL, NULL, NULL);
>>>> +
>>>> + return sprintf(buf, "%u.%03u Gb/s\n", bw_avail / 1000, bw_avail % 1000);
>>>> +}
>>>> +static DEVICE_ATTR_RO(available_bandwidth);
>>>
>>> Help me understand this. We already have these sysfs attributes:
>>>
>>> max_link_speed # eg, 16 GT/s
>>> max_link_width # eg, 8
>>> current_link_speed # eg, 16 GT/s
>>> current_link_width # eg, 8
>>>
>>> so I think the raw materials are already exposed.
>>>
>>> The benefits I see for this new file are that
>>>
>>> - pcie_bandwidth_available() does the work of traversing up the
>>> tree, doing the computations (link width * speed, reduced by
>>> encoding overhead), and finding the minimum, and
>>>
>>> - it re-traverses the path every time we look at it, while the
>>> boot-time check is a one-time event.
>>>
>>> In principle this could all be done in user space with the attributes
>>> that are already exported. There's some precedent for things like
>>> this in lspci, e.g., "NUMA node" [1], and lspci might even be a more
>>> user-friendly place for users to look for this, as opposed to
>>> searching through sysfs.
>>
>> Parsing the endpoint to root port bandwidth is, in principle, possible
>> from userspace. It's just that in practice it's very clumsy to do, and,
>> as you pointed out, not that reliable.
>
> I don't remember the reliability issue. Was that in a previous
> conversation? AFAICT, using current_link_speed and current_link_width
> should be as reliable as pcie_bandwidth_available() because they're
> both based on reading PCI_EXP_LNKSTA.
>
> This patch exposes only the available bandwidth, not the limiting
> device, link speed, or link width. Maybe that extra information isn't
> important in this context. Of course, it's easy to derive using
> current_link_speed and current_link_width, but if we do that, there's
> really no benefit to adding a new file.
>
> Linux doesn't really support Virtual Channels (VC) yet, and I don't
> know much about it, but it seems like Quality-of-Service features like
> VC could affect this idea of available bandwidth.
>
> Since we already expose the necessary information, and we might throw
> additional things like VC into the mix, I'm a little hesitant about
> adding things to sysfs because they're very difficult to change later.
I understand your concerns with VC and crazy PCIe outliers.
'available_bandwidth' is meant to mean physical bandwidth, rather than
"what comcast gives you". I see now the possibility for confusion.
My motivation is to save drivers from the hassle of having to call
pcie_print_link_status(), and prevent the rare duplicate syslog messages.
I prefer re-using the kernel logic over doing it over again from
userspace, but I won't insist over your doubts.
Alex
>> I understand it's not information that all users would jump in the air
>> to know. However, it was important enough for certain use cases, that
>> the kernel already has a very reliable way to calculate it.
>>
>> It seems to me that the most elegant way is to let the kernel tell us,
>> since the kernel already has this facility. To quote one of the texts
>> under Documentation/, it is an elegant way to "avoid reinventing kernel
>> wheels in userspace".
>>
>> Alex
>>
>>> [1] https://git.kernel.org/pub/scm/utils/pciutils/pciutils.git/commit/?id=90ec4a6d0ae8
>>>
>>>> static ssize_t secondary_bus_number_show(struct device *dev,
>>>> struct device_attribute *attr,
>>>> char *buf)
>>>> @@ -786,6 +798,7 @@ static struct attribute *pcie_dev_attrs[] = {
>>>> &dev_attr_current_link_width.attr,
>>>> &dev_attr_max_link_width.attr,
>>>> &dev_attr_max_link_speed.attr,
>>>> + &dev_attr_available_bandwidth.attr,
>>>> NULL,
>>>> };
>>>>
>>>> --
>>>> 2.17.1
>>>>
>>>
>>
>
^ permalink raw reply
* [PATCH net-next] net: mscc: ocelot: remove set but not used variable 'phy_mode'
From: YueHaibing @ 2018-10-08 14:07 UTC (permalink / raw)
To: Alexandre Belloni, David S. Miller; +Cc: YueHaibing, netdev, kernel-janitors
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/net/ethernet/mscc/ocelot_board.c: In function 'mscc_ocelot_probe':
drivers/net/ethernet/mscc/ocelot_board.c:262:17: warning:
variable 'phy_mode' set but not used [-Wunused-but-set-variable]
enum phy_mode phy_mode;
It never used since introduction in
commit 71e32a20cfbf ("net: mscc: ocelot: make use of SerDes PHYs for handling their configuration")
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
drivers/net/ethernet/mscc/ocelot_board.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/net/ethernet/mscc/ocelot_board.c b/drivers/net/ethernet/mscc/ocelot_board.c
index 953b326..0cf0b09 100644
--- a/drivers/net/ethernet/mscc/ocelot_board.c
+++ b/drivers/net/ethernet/mscc/ocelot_board.c
@@ -259,7 +259,6 @@ static int mscc_ocelot_probe(struct platform_device *pdev)
struct phy_device *phy;
struct resource *res;
struct phy *serdes;
- enum phy_mode phy_mode;
void __iomem *regs;
char res_name[8];
u32 port;
@@ -297,10 +296,8 @@ static int mscc_ocelot_probe(struct platform_device *pdev)
case PHY_INTERFACE_MODE_NA:
continue;
case PHY_INTERFACE_MODE_SGMII:
- phy_mode = PHY_MODE_SGMII;
break;
case PHY_INTERFACE_MODE_QSGMII:
- phy_mode = PHY_MODE_QSGMII;
break;
default:
dev_err(ocelot->dev,
^ permalink raw reply related
* Re: [PATCH net-next 04/19] net: usb: aqc111: Various callbacks implementation
From: Oliver Neukum @ 2018-10-08 13:47 UTC (permalink / raw)
To: Igor Russkikh, David S . Miller
Cc: Dmitry Bezrukov, linux-usb@vger.kernel.org,
netdev@vger.kernel.org
In-Reply-To: <ee389e525cfde23ab7dcdb0bd748915dd387d552.1538734658.git.igor.russkikh@aquantia.com>
On Fr, 2018-10-05 at 10:24 +0000, Igor Russkikh wrote:
> From: Dmitry Bezrukov <dmitry.bezrukov@aquantia.com>
>
> Reset, stop callbacks, driver unbind callback.
> More register defines required for these callbacks.
>
> Signed-off-by: Dmitry Bezrukov <dmitry.bezrukov@aquantia.com>
> Signed-off-by: Igor Russkikh <igor.russkikh@aquantia.com>
> ---
> drivers/net/usb/aqc111.c | 48 ++++++++++++++++++++++
> drivers/net/usb/aqc111.h | 101 +++++++++++++++++++++++++++++++++++++++++++++++
> 2 files changed, 149 insertions(+)
>
> diff --git a/drivers/net/usb/aqc111.c b/drivers/net/usb/aqc111.c
> index 7f3e5a615750..22bb259d71fb 100644
> --- a/drivers/net/usb/aqc111.c
> +++ b/drivers/net/usb/aqc111.c
> @@ -169,12 +169,60 @@ static int aqc111_bind(struct usbnet *dev, struct usb_interface *intf)
>
> static void aqc111_unbind(struct usbnet *dev, struct usb_interface *intf)
> {
> + u8 reg8;
> + u16 reg16;
> +
> + /* Force bz */
> + reg16 = SFR_PHYPWR_RSTCTL_BZ;
> + aqc111_write_cmd_nopm(dev, AQ_ACCESS_MAC, SFR_PHYPWR_RSTCTL,
> + 2, 2, ®16);
No, I am sorry, you are doing DMA on the kernel stack. That is not
allowed. These functions will all have to be fixed.
Regards
Oliver
^ permalink raw reply
* Re: [PATCH net-next 03/19] net: usb: aqc111: Add implementation of read and write commands
From: Oliver Neukum @ 2018-10-08 13:44 UTC (permalink / raw)
To: Igor Russkikh, David S . Miller
Cc: Dmitry Bezrukov, linux-usb@vger.kernel.org,
netdev@vger.kernel.org
In-Reply-To: <ebf0867900ae849581fbd20b52ee9e855e6345c8.1538734658.git.igor.russkikh@aquantia.com>
On Fr, 2018-10-05 at 10:24 +0000, Igor Russkikh wrote:
> From: Dmitry Bezrukov <dmitry.bezrukov@aquantia.com>
>
> Read/write command register defines and functions
>
> Signed-off-by: Dmitry Bezrukov <dmitry.bezrukov@aquantia.com>
> Signed-off-by: Igor Russkikh <igor.russkikh@aquantia.com>
> ---
> drivers/net/usb/aqc111.c | 124 +++++++++++++++++++++++++++++++++++++++++++++++
> drivers/net/usb/aqc111.h | 19 ++++++++
> 2 files changed, 143 insertions(+)
> create mode 100644 drivers/net/usb/aqc111.h
>
> diff --git a/drivers/net/usb/aqc111.c b/drivers/net/usb/aqc111.c
> index c914e19387f2..7f3e5a615750 100644
> --- a/drivers/net/usb/aqc111.c
> +++ b/drivers/net/usb/aqc111.c
> @@ -14,6 +14,130 @@
> #include <linux/usb/cdc.h>
> #include <linux/usb/usbnet.h>
>
> +#include "aqc111.h"
> +
> +static int __aqc111_read_cmd(struct usbnet *dev, u8 cmd, u16 value,
> + u16 index, u16 size, void *data, int nopm)
> +{
> + int ret;
> + int (*fn)(struct usbnet *dev, u8 cmd, u8 reqtype, u16 value,
> + u16 index, void *data, u16 size);
> +
> + if (nopm)
> + fn = usbnet_read_cmd_nopm;
> + else
> + fn = usbnet_read_cmd;
If you really want to do this, pass the function.
> +
> + ret = fn(dev, cmd, USB_DIR_IN | USB_TYPE_VENDOR | USB_RECIP_DEVICE,
> + value, index, data, size);
> + if (size == 2)
> + le16_to_cpus(data);
That is incredibly dirty
> +
> + if (unlikely(ret < 0))
> + netdev_warn(dev->net,
> + "Failed to read(0x%x) reg index 0x%04x: %d\n",
> + cmd, index, ret);
> + return ret;
> +}
> +
> +static int aqc111_read_cmd_nopm(struct usbnet *dev, u8 cmd, u16 value,
> + u16 index, u16 size, void *data)
> +{
> + return __aqc111_read_cmd(dev, cmd, value, index, size, data, 1);
> +}
> +
> +static int aqc111_read_cmd(struct usbnet *dev, u8 cmd, u16 value,
> + u16 index, u16 size, void *data)
> +{
> + return __aqc111_read_cmd(dev, cmd, value, index, size, data, 0);
> +}
> +
> +static int __aq_write_cmd(struct usbnet *dev, u8 cmd, u8 reqtype,
> + u16 value, u16 index, const void *data, u16 size)
> +{
> + void *buf = NULL;
> + int err = -ENOMEM;
> +
> + netdev_dbg(dev->net,
> + "%s cmd=%#x reqtype=%#x value=%#x index=%#x size=%d\n",
> + __func__, cmd, reqtype, value, index, size);
> +
> + if (data) {
> + buf = kmemdup(data, size, GFP_KERNEL);
Under which contexts is this used?
Regards
Oliver
^ permalink raw reply
* Re: [PATCH 2/2] bpftool: Allow add linker flags via EXTRA_LDFLAGS variable
From: Song Liu @ 2018-10-08 21:02 UTC (permalink / raw)
To: Jiri Olsa; +Cc: Alexei Starovoitov, Daniel Borkmann, open list, Networking
In-Reply-To: <20181008082259.26742-2-jolsa@kernel.org>
On Mon, Oct 8, 2018 at 1:23 AM Jiri Olsa <jolsa@kernel.org> wrote:
>
> Adding EXTRA_LDFLAGS allowing user to specify extra flags
> for LD_FLAGS variable. Also adding LDFLAGS to build command
> line.
>
> Signed-off-by: Jiri Olsa <jolsa@kernel.org>
Acked-by: Song Liu <songliubraving@fb.com>
> ---
> tools/bpf/bpftool/Makefile | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/tools/bpf/bpftool/Makefile b/tools/bpf/bpftool/Makefile
> index 5bfa07e3f2f7..dac7eff4c7e5 100644
> --- a/tools/bpf/bpftool/Makefile
> +++ b/tools/bpf/bpftool/Makefile
> @@ -49,6 +49,9 @@ CFLAGS += -DBPFTOOL_VERSION='"$(BPFTOOL_VERSION)"'
> ifneq ($(EXTRA_CFLAGS),)
> CFLAGS += $(EXTRA_CFLAGS)
> endif
> +ifneq ($(EXTRA_LDFLAGS),)
> +LDFLAGS += $(EXTRA_LDFLAGS)
> +endif
>
> LIBS = -lelf -lbfd -lopcodes $(LIBBPF)
>
> @@ -94,7 +97,7 @@ $(OUTPUT)disasm.o: $(srctree)/kernel/bpf/disasm.c
> $(QUIET_CC)$(COMPILE.c) -MMD -o $@ $<
>
> $(OUTPUT)bpftool: $(OBJS) $(LIBBPF)
> - $(QUIET_LINK)$(CC) $(CFLAGS) -o $@ $^ $(LIBS)
> + $(QUIET_LINK)$(CC) $(CFLAGS) $(LDFLAGS) -o $@ $^ $(LIBS)
>
> $(OUTPUT)%.o: %.c
> $(QUIET_CC)$(COMPILE.c) -MMD -o $@ $<
> --
> 2.17.2
>
^ permalink raw reply
* Re: [PATCH v8 01/15] octeontx2-af: Add Marvell OcteonTX2 RVU AF driver
From: Sunil Kovvuri @ 2018-10-08 13:50 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Linux Netdev List, David S. Miller, linux-soc, Sunil Goutham
In-Reply-To: <CAK8P3a2vgBVon8JU=y-4upF0ggLYt7WL-DJxby-6MqaM0Uvrqg@mail.gmail.com>
On Mon, Oct 8, 2018 at 5:52 PM Arnd Bergmann <arnd@arndb.de> wrote:
>
> On Sun, Oct 7, 2018 at 4:59 PM <sunil.kovvuri@gmail.com> wrote:
>
> > --- /dev/null
> > +++ b/drivers/net/ethernet/marvell/octeontx2/Kconfig
> > @@ -0,0 +1,12 @@
> > +#
> > +# Marvell OcteonTX2 drivers configuration
> > +#
> > +
> > +config OCTEONTX2_AF
> > + tristate "Marvell OcteonTX2 RVU Admin Function driver"
> > + depends on ARM64 && PCI
>
> You should try to allow building it on x86 and other architectures, even though
> the driver won't be used there this helps get reports from static
> build infrastructure.
> You could use e.g.
>
> depends on (64BIT && COMPILE_TEST) || ARM64
> depends on PCI
>
> Arnd
Thanks for the suggestion.
But going forward we will have few arm64 assembly instructions used in
the driver.
So a x86 build will fail. And i have built code using sparse and
coverity as well before
submitting patches upstream.
Sunil.
^ permalink raw reply
* Re: [PATCH 1/2] bpftool: Allow to add compiler flags via EXTRA_CFLAGS variable
From: Song Liu @ 2018-10-08 21:02 UTC (permalink / raw)
To: Jiri Olsa; +Cc: Alexei Starovoitov, Daniel Borkmann, open list, Networking
In-Reply-To: <20181008082259.26742-1-jolsa@kernel.org>
On Mon, Oct 8, 2018 at 1:24 AM Jiri Olsa <jolsa@kernel.org> wrote:
>
> Adding EXTRA_CFLAGS allowing user to specify extra flags
> for CFLAGS variable.
>
> Signed-off-by: Jiri Olsa <jolsa@kernel.org>
Acked-by: Song Liu <songliubraving@fb.com>
> ---
> tools/bpf/bpftool/Makefile | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/tools/bpf/bpftool/Makefile b/tools/bpf/bpftool/Makefile
> index 74288a2197ab..5bfa07e3f2f7 100644
> --- a/tools/bpf/bpftool/Makefile
> +++ b/tools/bpf/bpftool/Makefile
> @@ -46,6 +46,10 @@ CFLAGS += -DPACKAGE='"bpftool"' -D__EXPORTED_HEADERS__ \
> -I$(srctree)/tools/lib/bpf \
> -I$(srctree)/tools/perf
> CFLAGS += -DBPFTOOL_VERSION='"$(BPFTOOL_VERSION)"'
> +ifneq ($(EXTRA_CFLAGS),)
> +CFLAGS += $(EXTRA_CFLAGS)
> +endif
> +
> LIBS = -lelf -lbfd -lopcodes $(LIBBPF)
>
> INSTALL ?= install
> --
> 2.17.2
>
^ permalink raw reply
* Re: [PATCH net-next 14/19] net: usb: aqc111: Implement set_rx_mode callback
From: Igor Russkikh @ 2018-10-08 13:49 UTC (permalink / raw)
To: Andrew Lunn
Cc: David S . Miller, linux-usb@vger.kernel.org,
netdev@vger.kernel.org, Dmitry Bezrukov
In-Reply-To: <20181006170343.GB6990@lunn.ch>
Hi Andrew,
>> +{
>> + struct usbnet *dev = netdev_priv(net);
>> + struct aqc111_data *aqc111_data = (struct aqc111_data *)dev->data[0];
>
>> + u8 *m_filter = ((u8 *)dev->data) + 12;
>
> Please could you explain is.
Oh, that was a legacy code, the idea is it used spare area in dev->data array to
keep permanently 8 bytes for mcast filter request.
But the truth is usbnet_write anyway preallocates the data buffer and copies the data in there.
Therefore its really better to just allocate m_filter on stack to make the code clean.
Regards,
Igor
^ permalink raw reply
* Re: [PATCH net-next 08/19] net: usb: aqc111: Implement TX data path
From: Igor Russkikh @ 2018-10-08 13:43 UTC (permalink / raw)
To: Andrew Lunn
Cc: David S . Miller, linux-usb@vger.kernel.org,
netdev@vger.kernel.org, Dmitry Bezrukov
In-Reply-To: <20181006011325.GB32455@lunn.ch>
>> + skb_push(skb, AQ_TX_HEADER_SIZE);
>> + cpu_to_le64s(&tx_hdr);
>
> Is that portable? tx_hdr is a structure of 2x u32 bitfields. What
> endian have you tested that one?
>
You are right, this is wrong for BE hardware.
We don't have such a hardware to check unfortunately.
Think its better to drop endianess conversions and declare
the driver as little endian only.
Do you think that'll be acceptable?
Regards,
Igor
^ permalink raw reply
* Re: [PATCHv2 bpf-next] bpf: fix building without CONFIG_INET
From: Song Liu @ 2018-10-08 20:52 UTC (permalink / raw)
To: joe
Cc: Daniel Borkmann, Arnd Bergmann, Alexei Starovoitov,
David S . Miller, John Fastabend, Martin KaFai Lau,
makita.toshiaki, Lawrence Brakmo, Andrey Ignatov,
Jesper Dangaard Brouer, Jakub Kicinski, Mathieu Xhonneux,
David Ahern, Networking, open list
In-Reply-To: <20181008183001.10406-1-joe@wand.net.nz>
On Mon, Oct 8, 2018 at 11:30 AM Joe Stringer <joe@wand.net.nz> wrote:
>
> From: Arnd Bergmann <arnd@arndb.de>
>
> The newly added TCP and UDP handling fails to link when CONFIG_INET
> is disabled:
>
> net/core/filter.o: In function `sk_lookup':
> filter.c:(.text+0x7ff8): undefined reference to `tcp_hashinfo'
> filter.c:(.text+0x7ffc): undefined reference to `tcp_hashinfo'
> filter.c:(.text+0x8020): undefined reference to `__inet_lookup_established'
> filter.c:(.text+0x8058): undefined reference to `__inet_lookup_listener'
> filter.c:(.text+0x8068): undefined reference to `udp_table'
> filter.c:(.text+0x8070): undefined reference to `udp_table'
> filter.c:(.text+0x808c): undefined reference to `__udp4_lib_lookup'
> net/core/filter.o: In function `bpf_sk_release':
> filter.c:(.text+0x82e8): undefined reference to `sock_gen_put'
>
> Wrap the related sections of code in #ifdefs for the config option.
>
> Furthermore, sk_lookup() should always have been marked 'static', this
> also avoids a warning about a missing prototype when building with
> 'make W=1'.
>
> Fixes: 6acc9b432e67 ("bpf: Add helper to retrieve socket in BPF")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Signed-off-by: Joe Stringer <joe@wand.net.nz>
Acked-by: Song Liu <songliubraving@fb.com>
> ---
> v2: Modify the patch to remove the related code in preprocessor rather
> than relying on compiler optimizations to remove the code.
> ---
> net/core/filter.c | 10 ++++++++--
> 1 file changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/net/core/filter.c b/net/core/filter.c
> index 30c6b2d3ef16..4bbc6567fcb8 100644
> --- a/net/core/filter.c
> +++ b/net/core/filter.c
> @@ -4817,8 +4817,9 @@ static const struct bpf_func_proto bpf_lwt_seg6_adjust_srh_proto = {
> };
> #endif /* CONFIG_IPV6_SEG6_BPF */
>
> -struct sock *sk_lookup(struct net *net, struct bpf_sock_tuple *tuple,
> - struct sk_buff *skb, u8 family, u8 proto)
> +#ifdef CONFIG_INET
> +static struct sock *sk_lookup(struct net *net, struct bpf_sock_tuple *tuple,
> + struct sk_buff *skb, u8 family, u8 proto)
> {
> int dif = skb->dev->ifindex;
> bool refcounted = false;
> @@ -4951,6 +4952,7 @@ static const struct bpf_func_proto bpf_sk_release_proto = {
> .ret_type = RET_INTEGER,
> .arg1_type = ARG_PTR_TO_SOCKET,
> };
> +#endif /* CONFIG_INET */
>
> bool bpf_helper_changes_pkt_data(void *func)
> {
> @@ -5158,12 +5160,14 @@ tc_cls_act_func_proto(enum bpf_func_id func_id, const struct bpf_prog *prog)
> case BPF_FUNC_skb_ancestor_cgroup_id:
> return &bpf_skb_ancestor_cgroup_id_proto;
> #endif
> +#ifdef CONFIG_INET
> case BPF_FUNC_sk_lookup_tcp:
> return &bpf_sk_lookup_tcp_proto;
> case BPF_FUNC_sk_lookup_udp:
> return &bpf_sk_lookup_udp_proto;
> case BPF_FUNC_sk_release:
> return &bpf_sk_release_proto;
> +#endif
> default:
> return bpf_base_func_proto(func_id);
> }
> @@ -5264,12 +5268,14 @@ sk_skb_func_proto(enum bpf_func_id func_id, const struct bpf_prog *prog)
> return &bpf_sk_redirect_hash_proto;
> case BPF_FUNC_get_local_storage:
> return &bpf_get_local_storage_proto;
> +#ifdef CONFIG_INET
> case BPF_FUNC_sk_lookup_tcp:
> return &bpf_sk_lookup_tcp_proto;
> case BPF_FUNC_sk_lookup_udp:
> return &bpf_sk_lookup_udp_proto;
> case BPF_FUNC_sk_release:
> return &bpf_sk_release_proto;
> +#endif
> default:
> return bpf_base_func_proto(func_id);
> }
> --
> 2.17.1
>
^ permalink raw reply
* Re: [PATCH] bpf: btf: Fix a missing check bug
From: Song Liu @ 2018-10-08 20:51 UTC (permalink / raw)
To: wang6495; +Cc: kjlu, Alexei Starovoitov, Daniel Borkmann, Networking, open list
In-Reply-To: <1538943795-30895-1-git-send-email-wang6495@umn.edu>
On Sun, Oct 7, 2018 at 1:26 PM Wenwen Wang <wang6495@umn.edu> wrote:
>
> In btf_parse_hdr(), the length of the btf data header is firstly copied
> from the user space to 'hdr_len' and checked to see whether it is larger
> than 'btf_data_size'. If yes, an error code EINVAL is returned. Otherwise,
> the whole header is copied again from the user space to 'btf->hdr'.
> However, after the second copy, there is no check between
> 'btf->hdr->hdr_len' and 'hdr_len' to confirm that the two copies get the
> same value. Given that the btf data is in the user space, a malicious user
> can race to change the data between the two copies. By doing so, the user
> can provide malicious data to the kernel and cause undefined behavior.
>
> This patch adds a necessary check after the second copy, to make sure
> 'btf->hdr->hdr_len' has the same value as 'hdr_len'. Otherwise, an error
> code EINVAL will be returned.
These two numbers are copied from same memory location, right? So I
think this check is not necessary?
Thank,
Song
>
> Signed-off-by: Wenwen Wang <wang6495@umn.edu>
> ---
> kernel/bpf/btf.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/kernel/bpf/btf.c b/kernel/bpf/btf.c
> index 2590700..7cce7db 100644
> --- a/kernel/bpf/btf.c
> +++ b/kernel/bpf/btf.c
> @@ -2114,6 +2114,9 @@ static int btf_parse_hdr(struct btf_verifier_env *env, void __user *btf_data,
>
> hdr = &btf->hdr;
>
> + if (hdr->hdr_len != hdr_len)
> + return -EINVAL;
> +
> btf_verifier_log_hdr(env, btf_data_size);
>
> if (hdr->magic != BTF_MAGIC) {
> --
> 2.7.4
>
^ permalink raw reply
* Re: [PATCH v2 net-next 17/23] net/namespace: Update rtnl_net_dumpid for strict data checking
From: Christian Brauner @ 2018-10-08 13:37 UTC (permalink / raw)
To: David Ahern; +Cc: David Ahern, netdev, davem, jbenc, stephen
In-Reply-To: <a6fa1883-e4b0-79c9-2e1e-ebe331f3d80e@gmail.com>
On Mon, Oct 08, 2018 at 07:28:33AM -0600, David Ahern wrote:
> On 10/8/18 4:54 AM, Christian Brauner wrote:
> > On Sun, Oct 07, 2018 at 08:16:38PM -0700, David Ahern wrote:
> >> From: David Ahern <dsahern@gmail.com>
> >>
> >> Update rtnl_net_dumpid for strict data checking. If the flag is set,
> >> the dump request is expected to have an rtgenmsg struct as the header
> >> which has the family as the only element. No data may be appended.
> >>
> >> Signed-off-by: David Ahern <dsahern@gmail.com>
> >> ---
> >> net/core/net_namespace.c | 6 ++++++
> >> 1 file changed, 6 insertions(+)
> >>
> >> diff --git a/net/core/net_namespace.c b/net/core/net_namespace.c
> >> index 670c84b1bfc2..fefe72774aeb 100644
> >> --- a/net/core/net_namespace.c
> >> +++ b/net/core/net_namespace.c
> >> @@ -853,6 +853,12 @@ static int rtnl_net_dumpid(struct sk_buff *skb, struct netlink_callback *cb)
> >> .s_idx = cb->args[0],
> >> };
> >>
> >> + if (cb->strict_check &&
> >
> > Hm, shouldn't this also verify that the passed header is indeed struct
> > rtgenmsg before checking whether there are any attributes?
Thanks!
>
> rtgenmsg is only a struct with only the family as an element.
> rtnetlink_rcv_msg has already verified that the nl msg header contains
> at least the rtgenmsg struct.
>
>
> >
> >> + nlmsg_attrlen(cb->nlh, sizeof(struct rtgenmsg))) {
> >> + NL_SET_ERR_MSG(cb->extack, "Unknown data in network namespace id dump request");
> >> + return -EINVAL;
> >> + }
> >> +
> >> spin_lock_bh(&net->nsid_lock);
> >> idr_for_each(&net->netns_ids, rtnl_net_dumpid_one, &net_cb);
> >> spin_unlock_bh(&net->nsid_lock);
> >> --
> >> 2.11.0
> >>
>
^ permalink raw reply
* Re: selftests/bpf: test_kmod.sh hangs on all devices
From: Daniel Borkmann @ 2018-10-08 13:28 UTC (permalink / raw)
To: Naresh Kamboju, open list:KERNEL SELFTEST FRAMEWORK
Cc: Shuah Khan, Anders Roxell, Rafael Tinoco, ast, netdev,
songliubraving, willemb
In-Reply-To: <CA+G9fYumFxZghmxndq7STURbDbM4jgUzESr88yCgWvv=S+hbRA@mail.gmail.com>
On 10/08/2018 03:13 PM, Naresh Kamboju wrote:
> BPF test case test_kmod.sh hangs on all devices running linux next.
>
> + cd /opt/kselftests/default-in-kernel/bpf
> + ./test_kmod.sh
> sysctl: cannot stat /proc/sys/net/core/bpf_jit_enable: No such file or directory
> sysctl: cannot stat /proc/sys/net/core/bpf_jit_harden: No such file or directory
> sysctl: cannot stat /proc/sys/net/core/bpf_jit_enable: No such file or directory
> sysctl: cannot stat /proc/sys/net/core/bpf_jit_harden: No such file or directory
> [ JIT enabled:0 hardened:0 ]
>
> https://lkft.validation.linaro.org/scheduler/job/429726
>
> Test hangs started from 4.19.0-rc4-next-20180918.
> Linux version 4.19.0-rc4-next-20180918 (oe-user@oe-host) (gcc version
> 7.1.1 20170707 (Linaro GCC 7.1-2017.08)) #1 SMP Tue Sep 18 05:26:00
> UTC 2018
>
> History can be compared from this page.
> https://qa-reports.linaro.org/lkft/linux-next-oe/tests/kselftest/bpf_test_kmod.sh
>
> OTOH,
> There is a kernel BUG,
This is quite an old linux-next kernel, should be fixed by 100811936f89 ("bpf: test_bpf:
add init_net to dev for flow_dissector"). Please make sure you have that commit included
in your testing:
https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git/commit/?id=100811936f89fd455eda1984810c09003550555b
Thanks,
Daniel
> [ 41.003698] BUG: unable to handle kernel paging request at 0000000000001460
> [ 41.016603] PGD 800000045d648067 P4D 800000045d648067 PUD 4575c8067 PMD 0
> [ 41.023475] Oops: 0000 [#1] SMP PTI
> [ 41.026959] CPU: 3 PID: 2790 Comm: modprobe Not tainted
> 4.19.0-rc4-next-20180920 #1
> [ 41.034621] Hardware name: Supermicro SYS-5019S-ML/X11SSH-F, BIOS
> 2.0b 07/27/2017
> [ 41.042094] RIP: 0010:__skb_flow_dissect+0xd9/0x1740
> [ 41.047057] Code: 7b 79 ff 85 c0 41 5a 74 0d 80 3d 06 cd 00 01 00
> 0f 84 4f 05 00 00 4d 85 ff 0f 84 4a 02 00 00 49 8b 47 10 48 8b 80 40
> 05 00 00 <4c> 8b 80 60 14 00 00 4c 89 85 28 ff ff ff e8 54 7b 79 ff 85
> c0 4c
> [ 41.065795] RSP: 0018:ffff9accc1cf79c0 EFLAGS: 00010286
> [ 41.071019] RAX: 0000000000000000 RBX: 000000000000000e RCX: 000000002c29b266
> [ 41.078143] RDX: 0000000097969774 RSI: 0000000000000000 RDI: 0000000000000001
> [ 41.085268] RBP: ffff9accc1cf7ac0 R08: ffffffff9b7517e9 R09: 0000000000000002
> [ 41.092392] R10: ffffffff9b7517e9 R11: ffffffff9c662080 R12: ffffffff9c78b620
> [ 41.099517] R13: 0000000000000008 R14: ffff9accc1cf7aec R15: ffff882f575e6800
> [ 41.106640] FS: 00007fcb533fe740(0000) GS:ffff882f5fb80000(0000)
> knlGS:0000000000000000
> [ 41.114716] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [ 41.120454] CR2: 0000000000001460 CR3: 000000045b606002 CR4: 00000000003606e0
> [ 41.127590] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> [ 41.134737] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> [ 41.141860] Call Trace:
> [ 41.144305] ? find_held_lock+0x35/0xa0
> [ 41.148136] ? __lock_acquire+0x2b5/0x1340
> [ 41.152227] ? find_held_lock+0x35/0xa0
> [ 41.156057] skb_get_poff+0x4b/0x90
> [ 41.159542] ? skb_get_poff+0x4b/0x90
> [ 41.163207] bpf_skb_get_pay_offset+0xe/0x20
> [ 41.167471] ___bpf_prog_run+0x45f/0x10d0
> [ 41.171475] __bpf_prog_run32+0x39/0x50
> [ 41.175305] ? lockdep_hardirqs_on+0xef/0x180
> [ 41.179656] ? ktime_get+0x6b/0x110
> [ 41.183143] test_bpf_init+0x5ab/0x1000 [test_bpf]
> [ 41.187933] ? 0xffffffffc02e2000
> [ 41.191244] do_one_initcall+0x5f/0x2b7
> [ 41.195074] ? rcu_read_lock_sched_held+0x81/0x90
> [ 41.199770] ? kmem_cache_alloc_trace+0x1de/0x210
> [ 41.204469] ? do_init_module+0x27/0x212
> [ 41.208387] do_init_module+0x5f/0x212
> [ 41.212138] load_module+0x20f5/0x2640
> [ 41.215886] __do_sys_finit_module+0xd1/0xf0
> [ 41.220156] ? __do_sys_finit_module+0xd1/0xf0
> [ 41.224626] __x64_sys_finit_module+0x1a/0x20
> [ 41.228984] do_syscall_64+0x4f/0x190
> [ 41.232645] entry_SYSCALL_64_after_hwframe+0x49/0xbe
> [ 41.237697] RIP: 0033:0x7fcb52d087f9
> [ 41.241266] Code: 00 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00
> 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24
> 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 4f e6 2b 00 f7 d8 64 89
> 01 48
> [ 41.260004] RSP: 002b:00007ffe780dd828 EFLAGS: 00000206 ORIG_RAX:
> 0000000000000139
> [ 41.267589] RAX: ffffffffffffffda RBX: 00000000006aba70 RCX: 00007fcb52d087f9
> [ 41.274737] RDX: 0000000000000000 RSI: 0000000000418424 RDI: 0000000000000003
> [ 41.281861] RBP: 0000000000418424 R08: 0000000000000000 R09: 0000000000000000
> [ 41.288985] R10: 0000000000000003 R11: 0000000000000206 R12: 0000000000000000
> [ 41.296108] R13: 0000000000040000 R14: 0000000000000000 R15: 0000000000000000
> [ 41.303234] Modules linked in: test_bpf(+) x86_pkg_temp_thermal fuse
> [ 41.309590] CR2: 0000000000001460
> [ 41.312930] ---[ end trace a7d5229a26c41aad ]---
> [ 41.317541] RIP: 0010:__skb_flow_dissect+0xd9/0x1740
> [ 41.322497] Code: 7b 79 ff 85 c0 41 5a 74 0d 80 3d 06 cd 00 01 00
> 0f 84 4f 05 00 00 4d 85 ff 0f 84 4a 02 00 00 49 8b 47 10 48 8b 80 40
> 05 00 00 <4c> 8b 80 60 14 00 00 4c 89 85 28 ff ff ff e8 54 7b 79 ff 85
> c0 4c
> [ 41.341235] RSP: 0018:ffff9accc1cf79c0 EFLAGS: 00010286
> [ 41.346452] RAX: 0000000000000000 RBX: 000000000000000e RCX: 000000002c29b266
> [ 41.353588] RDX: 0000000097969774 RSI: 0000000000000000 RDI: 0000000000000001
> [ 41.360716] RBP: ffff9accc1cf7ac0 R08: ffffffff9b7517e9 R09: 0000000000000002
> [ 41.367841] R10: ffffffff9b7517e9 R11: ffffffff9c662080 R12: ffffffff9c78b620
> [ 41.374964] R13: 0000000000000008 R14: ffff9accc1cf7aec R15: ffff882f575e6800
> [ 41.382089] FS: 00007fcb533fe740(0000) GS:ffff882f5fb80000(0000)
> knlGS:0000000000000000
> [ 41.390165] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [ 41.395903] CR2: 0000000000001460 CR3: 000000045b606002 CR4: 00000000003606e0
> [ 41.403026] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> [ 41.410153] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> [ 41.417275] BUG: sleeping function called from invalid context at
> /srv/oe/build/tmp-rpb-glibc/work-shared/intel-corei7-64/kernel-source/include/linux/percpu-rwsem.h:34
> [ 41.432199] in_atomic(): 1, irqs_disabled(): 1, pid: 2790, name: modprobe
> [ 41.438977] INFO: lockdep is turned off.
> [ 41.442893] irq event stamp: 13766
> [ 41.446292] hardirqs last enabled at (13765): [<ffffffff9af037eb>]
> ktime_get+0x6b/0x110
> [ 41.454369] hardirqs last disabled at (13766): [<ffffffff9ae01c6b>]
> trace_hardirqs_off_thunk+0x1a/0x1c
> [ 41.463658] softirqs last enabled at (13728): [<ffffffff9be0032d>]
> __do_softirq+0x32d/0x42f
> [ 41.472084] softirqs last disabled at (13711): [<ffffffff9ae70679>]
> irq_exit+0xc9/0xd0
> [ 41.479996] CPU: 3 PID: 2790 Comm: modprobe Tainted: G D
> 4.19.0-rc4-next-20180920 #1
> [ 41.489026] Hardware name: Supermicro SYS-5019S-ML/X11SSH-F, BIOS
> 2.0b 07/27/2017
> [ 41.496496] Call Trace:
> [ 41.498943] dump_stack+0x70/0xa5
> [ 41.502261] ___might_sleep+0x152/0x240
> [ 41.506091] __might_sleep+0x4a/0x80
> [ 41.509679] exit_signals+0x33/0x240
> [ 41.513249] do_exit+0xb1/0xc60
> [ 41.516387] rewind_stack_do_exit+0x17/0x20
> [ 41.520587] RIP: 0033:0x7fcb52d087f9
> [ 41.524177] Code: 00 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00
> 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24
> 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 4f e6 2b 00 f7 d8 64 89
> 01 48
> [ 41.542914] RSP: 002b:00007ffe780dd828 EFLAGS: 00000206 ORIG_RAX:
> 0000000000000139
> [ 41.550471] RAX: ffffffffffffffda RBX: 00000000006aba70 RCX: 00007fcb52d087f9
> [ 41.557608] RDX: 0000000000000000 RSI: 0000000000418424 RDI: 0000000000000003
> [ 41.564735] RBP: 0000000000418424 R08: 0000000000000000 R09: 0000000000000000
> [ 41.571860] R10: 0000000000000003 R11: 0000000000000206 R12: 0000000000000000
> [ 41.578985] R13: 0000000000040000 R14: 0000000000000000 R15: 0000000000000000
> e)
>
> Bug reported,
> https://bugs.linaro.org/show_bug.cgi?id=4006
>
^ permalink raw reply
* Re: [PATCH v2 net-next 17/23] net/namespace: Update rtnl_net_dumpid for strict data checking
From: David Ahern @ 2018-10-08 13:28 UTC (permalink / raw)
To: Christian Brauner, David Ahern; +Cc: netdev, davem, jbenc, stephen
In-Reply-To: <20181008105430.cnpflmfwhkn3u2lq@brauner.io>
On 10/8/18 4:54 AM, Christian Brauner wrote:
> On Sun, Oct 07, 2018 at 08:16:38PM -0700, David Ahern wrote:
>> From: David Ahern <dsahern@gmail.com>
>>
>> Update rtnl_net_dumpid for strict data checking. If the flag is set,
>> the dump request is expected to have an rtgenmsg struct as the header
>> which has the family as the only element. No data may be appended.
>>
>> Signed-off-by: David Ahern <dsahern@gmail.com>
>> ---
>> net/core/net_namespace.c | 6 ++++++
>> 1 file changed, 6 insertions(+)
>>
>> diff --git a/net/core/net_namespace.c b/net/core/net_namespace.c
>> index 670c84b1bfc2..fefe72774aeb 100644
>> --- a/net/core/net_namespace.c
>> +++ b/net/core/net_namespace.c
>> @@ -853,6 +853,12 @@ static int rtnl_net_dumpid(struct sk_buff *skb, struct netlink_callback *cb)
>> .s_idx = cb->args[0],
>> };
>>
>> + if (cb->strict_check &&
>
> Hm, shouldn't this also verify that the passed header is indeed struct
> rtgenmsg before checking whether there are any attributes?
rtgenmsg is only a struct with only the family as an element.
rtnetlink_rcv_msg has already verified that the nl msg header contains
at least the rtgenmsg struct.
>
>> + nlmsg_attrlen(cb->nlh, sizeof(struct rtgenmsg))) {
>> + NL_SET_ERR_MSG(cb->extack, "Unknown data in network namespace id dump request");
>> + return -EINVAL;
>> + }
>> +
>> spin_lock_bh(&net->nsid_lock);
>> idr_for_each(&net->netns_ids, rtnl_net_dumpid_one, &net_cb);
>> spin_unlock_bh(&net->nsid_lock);
>> --
>> 2.11.0
>>
^ permalink raw reply
* Re: [PATCH v2 net-next 11/23] rtnetlink: Update rtnl_stats_dump for strict data checking
From: David Ahern @ 2018-10-08 13:25 UTC (permalink / raw)
To: Christian Brauner, David Ahern; +Cc: netdev, davem, jbenc, stephen
In-Reply-To: <20181008101725.zjdsnwcyww7tmwnr@brauner.io>
On 10/8/18 4:17 AM, Christian Brauner wrote:
>> @@ -4696,13 +4697,32 @@ static int rtnl_stats_dump(struct sk_buff *skb, struct netlink_callback *cb)
>>
>> cb->seq = net->dev_base_seq;
>>
>> - if (nlmsg_len(cb->nlh) < sizeof(*ifsm))
>> + if (nlmsg_len(cb->nlh) < sizeof(*ifsm)) {
>> + NL_SET_ERR_MSG(extack, "Invalid header for stats dump");
>> return -EINVAL;
>> + }
>>
>> ifsm = nlmsg_data(cb->nlh);
>> +
>> + /* only requests using NLM_F_DUMP_PROPER_HDR can pass data to
>
> That looks like an accidental leftover before we changed this to a
> socket option. :)
>
ugh. thanks for noticing.
^ permalink raw reply
* Re: [PATCH v3] rtw88: Add firmware file for driver rtw88
From: Josh Boyer @ 2018-10-08 13:23 UTC (permalink / raw)
To: Larry Finger; +Cc: Linux Firmware, Linux Wireless, netdev, yhchuang
In-Reply-To: <20181004193155.22669-1-Larry.Finger@lwfinger.net>
On Thu, Oct 4, 2018 at 3:32 PM Larry Finger <Larry.Finger@lwfinger.net> wrote:
>
> This file contains the firmware for the new driver rtw88 for Realtek
> RTL8822BE and RTL8822CE devices. It was provided by the Realtek
> developer.
>
> Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
> ---
> v2 - removed redundant information from subject
> v3 - drivers are for 802.11ac, not 802.11n
> added firmware for RL8822CE
> ---
> WHENCE | 10 ++++++++++
> rtw88/rtw8822b_fw.bin | Bin 0 -> 150984 bytes
> rtw88/rtw8822c_fw.bin | Bin 0 -> 162064 bytes
> 3 files changed, 10 insertions(+)
> create mode 100644 rtw88/rtw8822b_fw.bin
> create mode 100644 rtw88/rtw8822c_fw.bin
Applied and pushed out.
josh
^ permalink raw reply
* Re: [PATCH net-next 06/19] net: usb: aqc111: Introduce link management
From: Igor Russkikh @ 2018-10-08 13:22 UTC (permalink / raw)
To: Andrew Lunn
Cc: David S . Miller, linux-usb@vger.kernel.org,
netdev@vger.kernel.org, Dmitry Bezrukov
In-Reply-To: <20181005171158.GL4730@lunn.ch>
Hi Andrew,
> Hi Igor, Dmitry
>
> Please could you explain why you decided to not use drivers/net/phy?
> The previous patch introduced basically what you need to export a
> standard Linux MDIO bus. From that you can use a standard Linux PHY
> driver.
Thats again because of this product has tightly integrated MAC+Phy.
MAC FW controls system interface and reports/alters link state
as a joint state on copper and SIF (even in dpa direct phy mode).
We can't extract phy api into a standalone fully functional phylib therefore.
Also as far as I know this particular phy is not available in the wild.
Regards,
Igor
^ permalink raw reply
* Re: general protection fault in __handle_mm_fault
From: Willem de Bruijn @ 2018-10-08 20:33 UTC (permalink / raw)
To: syzbot+1577fbe983d20fe2e88f
Cc: David Miller, Eric Dumazet, Alexey Kuznetsov, LKML,
Network Development, syzkaller-bugs, Hideaki YOSHIFUJI,
Andrew Morton, kirill.shutemov, aneesh.kumar
In-Reply-To: <CAF=yD-+7NxN37Ez=3WXG0+2i6j30uSV8u9D7oJXEhp+SxzYCpA@mail.gmail.com>
On Mon, Oct 8, 2018 at 12:10 PM Willem de Bruijn
<willemdebruijn.kernel@gmail.com> wrote:
>
> On Fri, Oct 5, 2018 at 6:27 PM syzbot
> <syzbot+1577fbe983d20fe2e88f@syzkaller.appspotmail.com> wrote:
> >
> > Hello,
> >
> > syzbot found the following crash on:
> >
> > HEAD commit: 25bcda3e8b9f Add linux-next specific files for 20181004
> > git tree: linux-next
> > console output: https://syzkaller.appspot.com/x/log.txt?x=130e3bf1400000
> > kernel config: https://syzkaller.appspot.com/x/.config?x=603d7f9140c3368a
> > dashboard link: https://syzkaller.appspot.com/bug?extid=1577fbe983d20fe2e88f
> > compiler: gcc (GCC) 8.0.1 20180413 (experimental)
> > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=127e88d6400000
> > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=13cdb67e400000
>
> > RIP: 0010:copy_user_enhanced_fast_string+0xe/0x20
> > arch/x86/lib/copy_user_64.S:180
> > Code: 89 d1 c1 e9 03 83 e2 07 f3 48 a5 89 d1 f3 a4 31 c0 0f 1f 00 c3 0f 1f
> > 80 00 00 00 00 0f 1f 00 83 fa 40 0f 82 70 ff ff ff 89 d1 <f3> a4 31 c0 0f
> > 1f 00 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 83
> > RSP: 0018:ffff8801bbe675b8 EFLAGS: 00010202
> > RAX: 0000000000000000 RBX: 0000000000007a50 RCX: 0000000000001b40
> > RDX: 0000000000007a50 RSI: 0000000020077000 RDI: ffff8801ce615f10
> > RBP: ffff8801bbe675f0 R08: ffffed0039cc2f4a R09: ffffed0039cc2f4a
> > R10: ffffed0039cc2f49 R11: ffff8801ce617a4f R12: 0000000020078b40
> > R13: 00000000200710f0 R14: ffff8801ce610000 R15: 00007ffffffff000
> > _copy_from_iter_full+0x263/0xc20 lib/iov_iter.c:724
> > copy_from_iter_full include/linux/uio.h:124 [inline]
> > skb_do_copy_data_nocache include/net/sock.h:1951 [inline]
> > skb_copy_to_page_nocache include/net/sock.h:1977 [inline]
> > tcp_sendmsg_locked+0x159e/0x3f90 net/ipv4/tcp.c:1338
>
> This started on next-20181004. It still happens as of next-20181008.
>
> It does not trigger on next 20181003. It does not occur if
> CONFIG_DEBUG_KOBJECT is disabled.
Bisected to commit e4d0c281a4c9 ("mm/memory.c: recheck page table
entry with page table lock held").
Verified to not trigger on next-20181008 after reverting that commit.
^ permalink raw reply
* Re: [PATCH V1 net 0/5] minor bug fixes for ENA Ethernet driver
From: Bshara, Nafea @ 2018-10-08 12:47 UTC (permalink / raw)
To: Kiyanovski, Arthur, davem@davemloft.net, netdev@vger.kernel.org
Cc: Woodhouse, David, Machulsky, Zorik, Matushevsky, Alexander,
Bshara, Saeed, Wilson, Matt, Liguori, Anthony, Tzalik, Guy,
Belgazal, Netanel, Saidi, Ali
In-Reply-To: <1539001724-25980-1-git-send-email-akiyano@amazon.com>
Ship it
On 10/8/18, 5:28 AM, "akiyano@amazon.com" <akiyano@amazon.com> wrote:
From: Arthur Kiyanovski <akiyano@amazon.com>
Arthur Kiyanovski (5):
net: ena: fix indentations in ena_defs for better readability
net: ena: fix warning in rmmod caused by double iounmap
net: ena: fix rare bug when failed restart/resume is followed by
driver removal
net: ena: fix NULL dereference due to untimely napi initialization
net: ena: fix auto casting to boolean
drivers/net/ethernet/amazon/ena/ena_admin_defs.h | 308 +++++++++-------------
drivers/net/ethernet/amazon/ena/ena_eth_com.c | 8 +-
drivers/net/ethernet/amazon/ena/ena_eth_io_defs.h | 219 ++++++++-------
drivers/net/ethernet/amazon/ena/ena_netdev.c | 23 +-
drivers/net/ethernet/amazon/ena/ena_regs_defs.h | 206 +++++++--------
5 files changed, 341 insertions(+), 423 deletions(-)
--
2.7.4
^ 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