* RE: [PATCH net v2 2/2] net: ixgbe: Use new PCI_DEV_FLAGS_NO_RELAXED_ORDERING flag
From: Tantilov, Emil S @ 2017-08-18 5:04 UTC (permalink / raw)
To: Ding Tianhong, davem@davemloft.net, Kirsher, Jeffrey T,
keescook@chromium.org, linux-kernel@vger.kernel.org,
sparclinux@vger.kernel.org, intel-wired-lan@lists.osuosl.org,
alexander.duyck@gmail.com, netdev@vger.kernel.org,
linuxarm@huawei.com
In-Reply-To: <2a7fc27b-c2f4-a7a1-9318-3a93531e7670@huawei.com>
>-----Original Message-----
>From: Ding Tianhong [mailto:dingtianhong@huawei.com]
>Sent: Thursday, August 17, 2017 5:39 PM
>To: Tantilov, Emil S <emil.s.tantilov@intel.com>; davem@davemloft.net;
>Kirsher, Jeffrey T <jeffrey.t.kirsher@intel.com>; keescook@chromium.org;
>linux-kernel@vger.kernel.org; sparclinux@vger.kernel.org; intel-wired-
>lan@lists.osuosl.org; alexander.duyck@gmail.com; netdev@vger.kernel.org;
>linuxarm@huawei.com
>Subject: Re: [PATCH net v2 2/2] net: ixgbe: Use new
>PCI_DEV_FLAGS_NO_RELAXED_ORDERING flag
>
>
>
>On 2017/8/17 22:17, Tantilov, Emil S wrote:
>
>>> ret_val = ixgbe_start_hw_generic(hw);
>>>
>>> -#ifndef CONFIG_SPARC
>>> - /* Disable relaxed ordering */
>>> - for (i = 0; ((i < hw->mac.max_tx_queues) &&
>>> - (i < IXGBE_DCA_MAX_QUEUES_82598)); i++) {
>>> - regval = IXGBE_READ_REG(hw, IXGBE_DCA_TXCTRL(i));
>>> - regval &= ~IXGBE_DCA_TXCTRL_DESC_WRO_EN;
>>> - IXGBE_WRITE_REG(hw, IXGBE_DCA_TXCTRL(i), regval);
>>> - }
>>> + if (!pcie_relaxed_ordering_enabled(adapter->pdev)) {
>>
>> As Alex mentioned there is no need for this check in any form.
>>
>> The HW defaults to Relaxed Ordering enabled unless it is disabled in
>> the PCIe Device Control Register. So the above logic is already done by
>HW.
>>
>> All you have to do is strip the code disabling relaxed ordering.
>>
>
>Hi Tantilov:
>
>I misunderstood Alex's suggestion, But I still couldn't find the logic
>where
>the HW disable the Relaxed Ordering when the PCIe Device Control Register
>disable it, can you point it out?
If you look at the datasheet (82599) - the description of CTRL_EXT.RO_DIS (bit 17, 0b):
Relaxed Ordering Disable. When set to 1b, the device does not request any relaxed
ordering transactions. When this bit is cleared and the Enable Relaxed Ordering bit in
the Device Control register is set, the device requests relaxed ordering transactions per queues as configured in the DCA_RXCTRL[n] and DCA_TXCTRL[n] registers.
So if you remove the code that clears the bits in DCA_T/RXCTRL relaxed ordering should
be enabled by HW when the bus allows it.
Thanks,
Emil
^ permalink raw reply
* Re: [PATCH V5 net-next 01/21] net-next/hinic: Initialize hw interface
From: David Miller @ 2017-08-18 5:03 UTC (permalink / raw)
To: stephen
Cc: aviad.krawczyk, linux-kernel, netdev, bc.y, victor.gissin,
zhaochen6, tony.qu
In-Reply-To: <20170817174540.46986450@xeon-e3>
From: Stephen Hemminger <stephen@networkplumber.org>
Date: Thu, 17 Aug 2017 17:45:40 -0700
> On Thu, 17 Aug 2017 19:52:42 +0800
> Aviad Krawczyk <aviad.krawczyk@huawei.com> wrote:
>
>> + nic_dev = (struct hinic_dev *)netdev_priv(netdev);
>
> Since netdev_priv() returns void *, a cast is not necessary here.
Agreed.
^ permalink raw reply
* Re: [PATCH V5 net-next 01/21] net-next/hinic: Initialize hw interface
From: David Miller @ 2017-08-18 5:03 UTC (permalink / raw)
To: stephen
Cc: aviad.krawczyk, linux-kernel, netdev, bc.y, victor.gissin,
zhaochen6, tony.qu
In-Reply-To: <20170817174205.6a1b12b6@xeon-e3>
From: Stephen Hemminger <stephen@networkplumber.org>
Date: Thu, 17 Aug 2017 17:42:05 -0700
> Please drop these functions, they do nothing and are not used
> as stubs in any operations table.
It might have been helpful to scan the entire series to understand
why it looks this way.
He's building the driver up, one piece at a time, filling in the full
implementation as is possible as more and more infrastructure is added.
So some functions start empty when a method is needed to be filled in,
and then gradually obtains more and more content throughout the
series.
And this is a fine way to add a huge new driver (although not my
personal preference).
^ permalink raw reply
* Re: [PATCH net-next v1 05/14] amd-xgbe: Add additional debugfs support
From: David Miller @ 2017-08-18 5:02 UTC (permalink / raw)
To: andrew; +Cc: thomas.lendacky, netdev
In-Reply-To: <20170818003057.GA11030@lunn.ch>
From: Andrew Lunn <andrew@lunn.ch>
Date: Fri, 18 Aug 2017 02:30:57 +0200
> On Thu, Aug 17, 2017 at 07:02:50PM -0500, Tom Lendacky wrote:
>> Add additional debugfs support for reading / writing registers of any
>> attached external phy devices as well as the SFP eeprom data.
>
> Hi Tom
>
> What is wrong with using the standard APIs for this?
>
> ethtool --moduile-info
>
> ioctls SIOCGMIIREG and SIOCSMIIREG.
Yeah debugfs is a horrible choice for this.
debugfs in general should be strongly avoided. We have rich eneough
facilities to export just about anything that is actually appropriate
and useful, and where we do not existing facilities should be extended
as needed rather than ignored.
^ permalink raw reply
* Re: [PATCH REPOST v5 iproute2 0/8] RDMAtool
From: Leon Romanovsky @ 2017-08-18 4:45 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Doug Ledford, linux-rdma-u79uwXL29TY76Z2rM5mHXA,
Dennis Dalessandro, Jason Gunthorpe, Jiri Pirko, Ariel Almog,
David Laight, Linux Netdev
In-Reply-To: <20170817180118.6631382c@xeon-e3>
[-- Attachment #1: Type: text/plain, Size: 12099 bytes --]
On Thu, Aug 17, 2017 at 06:01:18PM -0700, Stephen Hemminger wrote:
> On Thu, 17 Aug 2017 09:56:06 +0300
> Leon Romanovsky <leonro-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org> wrote:
>
> > This is fifth revision of series implementing the RDAMtool - the tool
> > to configure RDMA devices.
> >
> > It looks like everyone who was interested to read cover letter already did it,
> > so I'll start from the changelog:
> >
> > Changelog:
> > v4->v5:
> > * Rebased to latest net-next branch
> > * Moved BIT() macro from devlink to general utils.h file - Patch #1.
> > * Changed the order of patches - moved man pages to be last patch.
> > * Rewrote all switch->case->return_string constructions to be static
> > tables with help of David's macro magic. Thanks a lot.
> > * Dropped dependency on exported device and port properties. Now tool depends
> > on RDMA netlink only and all needed code is already in Doug's for-next.
> > * Added two OPA specific physical link states, because their names is
> > too broad - TEST and OFFLINE, I named it as OPA_TEST and OPA_OFFLINE.
> > v3->v4:
> > * Rebased to latest net-next branch
> > * Added JSON output -j (json) and -p (pretty output)
> > * Exported and reused kernel UAPIs and defines instead of hard coded
> > version.
> > v2->v3:
> > * Removed MAX()
> > * Reduced scope of rd_argv_match
> > * Removed return from rdma_free_devmap
> > * Added extra break at rdma_send_msg
> > v1->v2:
> > * Squashed multiple (and similar) patches to be one patch for dev object
> > and one patch for link object.
> > * Removed port_map struct
> > * Removed global netlink dump during initialization, it removed the need to store
> > the intermediate variables and reuse ability of netlink to signal if variable
> > exists or doesn't.
> > * Added "-d" --details option and put all CAPs under it.
> >
> > v0->v1:
> > * Moved hunk with changes in man/Makefile from first patch to the last patch
> > * Removed the "unknown command" from the examples in commit messages
> > * Removed special "caps" parsing command and put it to be part of general "show" command
> > * Changed parsed capability format to be similar to iproute2 suite
> > * Added FW version as an output of show command.
> > * Added forgotten CAP_FLAGS to the nla_policy list
> > RFC->v0:
> > * Removed everything that is not implemented yet.
> > * Abandoned sysfs interfaces in favor of netlink.
> >
> > -----
> > The initial proposal was sent as RFC [1] and was based on sysfs entries as POC.
> >
> > The current series was rewritten completely to work with RDMA netlinks as
> > a source of user<->kernel communications. In order to achieve that, the
> > RDMA netlinks were extensively refactored and modernized [2, 3, 4 and 5].
> >
> > The Doug's for-next tag includes most of the needed patches for this tool.
> >
> > The following is an example of various runs on my machine with 5 devices
> > (4 in IB mode and one in Ethernet mode).
> >
> > ### Without parameters
> > $ rdma
> > Usage: rdma [ OPTIONS ] OBJECT { COMMAND | help }
> > where OBJECT := { dev | link | help }
> > OPTIONS := { -V[ersion] | -d[etails] | -j[son] | -p[retty]}
> >
> > ### With unspecified device name
> > $ rdma dev
> > 1: mlx5_0: node_type ca fw 2.8.9999 node_guid 5254:00c0:fe12:3457 sys_image_guid 5254:00c0:fe12:3457
> > 2: mlx5_1: node_type ca fw 2.8.9999 node_guid 5254:00c0:fe12:3458 sys_image_guid 5254:00c0:fe12:3458
> > 3: mlx5_2: node_type ca fw 2.8.9999 node_guid 5254:00c0:fe12:3459 sys_image_guid 5254:00c0:fe12:3459
> > 4: mlx5_3: node_type ca fw 2.8.9999 node_guid 5254:00c0:fe12:345a sys_image_guid 5254:00c0:fe12:345a
> > 5: mlx5_4: node_type ca fw 2.8.9999 node_guid 5254:00c0:fe12:345b sys_image_guid 5254:00c0:fe12:345b
> >
> > ### Detailed mode
> > $ rdma -d dev
> > 1: mlx5_0: node_type ca fw 2.8.9999 node_guid 5254:00c0:fe12:3457 sys_image_guid 5254:00c0:fe12:3457
> > caps: <BAD_PKEY_CNTR, BAD_QKEY_CNTR, CHANGE_PHY_POR, PORT_ACTIVE_EVENT, SYS_IMAGE_GUID, RC_RNR_NAK_GEN, MEM_WINDOW, UD_IP_CSUM, UD_TSO, XRC, MEM_MGT_EXTENSIONS, BLOCK_MULTICAST_LOOPBACK, MEM_WINDOW_TYPE_2B, RAW_IP_CSUM, MANAGED_FLOW_STEERING, RESIZE_MAX_WR>
> > 2: mlx5_1: node_type ca fw 2.8.9999 node_guid 5254:00c0:fe12:3458 sys_image_guid 5254:00c0:fe12:3458
> > caps: <BAD_PKEY_CNTR, BAD_QKEY_CNTR, CHANGE_PHY_POR, PORT_ACTIVE_EVENT, SYS_IMAGE_GUID, RC_RNR_NAK_GEN, MEM_WINDOW, UD_IP_CSUM, UD_TSO, XRC, MEM_MGT_EXTENSIONS, BLOCK_MULTICAST_LOOPBACK, MEM_WINDOW_TYPE_2B, RAW_IP_CSUM, MANAGED_FLOW_STEERING, RESIZE_MAX_WR>
> > 3: mlx5_2: node_type ca fw 2.8.9999 node_guid 5254:00c0:fe12:3459 sys_image_guid 5254:00c0:fe12:3459
> > caps: <BAD_PKEY_CNTR, BAD_QKEY_CNTR, CHANGE_PHY_POR, PORT_ACTIVE_EVENT, SYS_IMAGE_GUID, RC_RNR_NAK_GEN, MEM_WINDOW, UD_IP_CSUM, UD_TSO, XRC, MEM_MGT_EXTENSIONS, BLOCK_MULTICAST_LOOPBACK, MEM_WINDOW_TYPE_2B, RAW_IP_CSUM, MANAGED_FLOW_STEERING, RESIZE_MAX_WR>
> > 4: mlx5_3: node_type ca fw 2.8.9999 node_guid 5254:00c0:fe12:345a sys_image_guid 5254:00c0:fe12:345a
> > caps: <BAD_PKEY_CNTR, BAD_QKEY_CNTR, CHANGE_PHY_POR, PORT_ACTIVE_EVENT, SYS_IMAGE_GUID, RC_RNR_NAK_GEN, MEM_WINDOW, UD_IP_CSUM, UD_TSO, XRC, MEM_MGT_EXTENSIONS, BLOCK_MULTICAST_LOOPBACK, MEM_WINDOW_TYPE_2B, RAW_IP_CSUM, MANAGED_FLOW_STEERING, RESIZE_MAX_WR>
> > 5: mlx5_4: node_type ca fw 2.8.9999 node_guid 5254:00c0:fe12:345b sys_image_guid 5254:00c0:fe12:345b
> > caps: <BAD_PKEY_CNTR, BAD_QKEY_CNTR, CHANGE_PHY_POR, PORT_ACTIVE_EVENT, SYS_IMAGE_GUID, RC_RNR_NAK_GEN, MEM_WINDOW, UD_IP_CSUM, UD_TSO, XRC, MEM_MGT_EXTENSIONS, BLOCK_MULTICAST_LOOPBACK, MEM_WINDOW_TYPE_2B, RAW_IP_CSUM, MANAGED_FLOW_STEERING, RESIZE_MAX_WR>
> >
> > ### Specific device
> > $ rdma dev show mlx5_4
> > 5: mlx5_4: node_type ca fw 2.8.9999 node_guid 5254:00c0:fe12:345b sys_image_guid 5254:00c0:fe12:345b
> >
> > ### Specific device in detailed mode
> > $ rdma dev show mlx5_4 -d
> > 5: mlx5_4: node_type ca fw 2.8.9999 node_guid 5254:00c0:fe12:345b sys_image_guid 5254:00c0:fe12:345b
> > caps: <BAD_PKEY_CNTR, BAD_QKEY_CNTR, CHANGE_PHY_POR, PORT_ACTIVE_EVENT, SYS_IMAGE_GUID, RC_RNR_NAK_GEN, MEM_WINDOW, UD_IP_CSUM, UD_TSO, XRC, MEM_MGT_EXTENSIONS, BLOCK_MULTICAST_LOOPBACK, MEM_WINDOW_TYPE_2B, RAW_IP_CSUM, MANAGED_FLOW_STEERING, RESIZE_MAX_WR>
> >
> > ### Unknown command (caps)
> > $ rdma dev show mlx5_4 caps
> > Unknown parameter 'caps'.
> >
> > ### Link properties without device name
> > $ rdma link
> > 1/1: mlx5_0/1: subnet_prefix fe80:0000:0000:0000 lid 13399 sm_lid 49151 lmc 0 state ACTIVE physical_state LINK_UP
> > 2/1: mlx5_1/1: subnet_prefix fe80:0000:0000:0000 lid 13400 sm_lid 49151 lmc 0 state ACTIVE physical_state LINK_UP
> > 3/1: mlx5_2/1: subnet_prefix fe80:0000:0000:0000 lid 13401 sm_lid 49151 lmc 0 state ACTIVE physical_state LINK_UP
> > 4/1: mlx5_3/1: state DOWN physical_state DISABLED
> > 5/1: mlx5_4/1: subnet_prefix fe80:0000:0000:0000 lid 13403 sm_lid 49151 lmc 0 state ACTIVE physical_state LINK_UP
> >
> > ### Link properties in detailed mode
> > $ rdma link -d
> > 1/1: mlx5_0/1: subnet_prefix fe80:0000:0000:0000 lid 13399 sm_lid 49151 lmc 0 state ACTIVE physical_state LINK_UP
> > caps: <AUTO_MIGR>
> > 2/1: mlx5_1/1: subnet_prefix fe80:0000:0000:0000 lid 13400 sm_lid 49151 lmc 0 state ACTIVE physical_state LINK_UP
> > caps: <AUTO_MIGR>
> > 3/1: mlx5_2/1: subnet_prefix fe80:0000:0000:0000 lid 13401 sm_lid 49151 lmc 0 state ACTIVE physical_state LINK_UP
> > caps: <AUTO_MIGR>
> > 4/1: mlx5_3/1: state DOWN physical_state DISABLED
> > caps: <CM, IP_BASED_GIDS>
> > 5/1: mlx5_4/1: subnet_prefix fe80:0000:0000:0000 lid 13403 sm_lid 49151 lmc 0 state ACTIVE physical_state LINK_UP
> > caps: <AUTO_MIGR>
> >
> > ### All links for specific device
> > $ rdma link show mlx5_3
> > 1/1: mlx5_0/1: subnet_prefix fe80:0000:0000:0000 lid 13399 sm_lid 49151 lmc 0 state ACTIVE physical_state LINK_UP
> >
> > ### Detailed link properties for specific device
> > $ rdma link -d show mlx5_3
> > 1/1: mlx5_0/1: subnet_prefix fe80:0000:0000:0000 lid 13399 sm_lid 49151 lmc 0 state ACTIVE physical_state LINK_UP
> > caps: <AUTO_MIGR>
> >
> > ### Specific port for specific device
> > $ rdma link show mlx5_4/1
> > 1/1: mlx5_0/1: subnet_prefix fe80:0000:0000:0000 lid 13399 sm_lid 49151 lmc 0 state ACTIVE physical_state LINK_UP
> >
> > ### Unknown parameter
> > $ rdma link show mlx5_4/1 caps
> > Unknown parameter 'caps'.
> >
> > Thanks
> >
> > Available in the "topic/rdmatool-netlink-v5" topic branch of this git repo:
> > git://git.kernel.org/pub/scm/linux/kernel/git/leon/iproute2.git
> >
> > Or for browsing:
> > https://git.kernel.org/cgit/linux/kernel/git/leon/iproute2.git/log/?h=topic/rdmatool-netlink-v5
> >
> > Thanks
> >
> > [1] https://www.spinics.net/lists/linux-rdma/msg49575.html
> > [2] https://patchwork.kernel.org/patch/9752865/
> > [3] https://www.spinics.net/lists/linux-rdma/msg50827.html
> > [4] https://www.spinics.net/lists/linux-rdma/msg51210.html
> > [5] https://patchwork.kernel.org/patch/9811729/ and https://patchwork.kernel.org/patch/9811731/]
> >
> > Cc: Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> > Cc: Dennis Dalessandro <dennis.dalessandro-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
> > Cc: Jason Gunthorpe <jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
> > Cc: Jiri Pirko <jiri-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
> > Cc: Ariel Almog <ariela-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
> > Cc: David Laight <David.Laight-ZS65k/vG3HxXrIkS9f7CXA@public.gmane.org>
> > Cc: Linux Netdev <netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
> >
> > Leon Romanovsky (8):
> > utils: Move BIT macro to common header
> > rdma: Add basic infrastructure for RDMA tool
> > rdma: Add dev object
> > rdma: Add link object
> > rdma: Add json and pretty outputs
> > rdma: Implement json output for dev object
> > rdma: Add json output to link object
> > rdma: Add initial manual for the tool
> >
> > Makefile | 2 +-
> > devlink/devlink.c | 2 +-
> > include/utils.h | 2 +
> > man/man8/rdma-dev.8 | 55 +++++++++
> > man/man8/rdma-link.8 | 55 +++++++++
> > man/man8/rdma.8 | 102 +++++++++++++++
> > rdma/.gitignore | 1 +
> > rdma/Makefile | 22 ++++
> > rdma/dev.c | 284 ++++++++++++++++++++++++++++++++++++++++++
> > rdma/link.c | 343 +++++++++++++++++++++++++++++++++++++++++++++++++++
> > rdma/rdma.c | 143 +++++++++++++++++++++
> > rdma/rdma.h | 93 ++++++++++++++
> > rdma/utils.c | 266 +++++++++++++++++++++++++++++++++++++++
> > 13 files changed, 1368 insertions(+), 2 deletions(-)
> > create mode 100644 man/man8/rdma-dev.8
> > create mode 100644 man/man8/rdma-link.8
> > create mode 100644 man/man8/rdma.8
> > create mode 100644 rdma/.gitignore
> > create mode 100644 rdma/Makefile
> > create mode 100644 rdma/dev.c
> > create mode 100644 rdma/link.c
> > create mode 100644 rdma/rdma.c
> > create mode 100644 rdma/rdma.h
> > create mode 100644 rdma/utils.c
> >
> > --
> > 2.14.1
> >
>
> Wanted to apply this (to net-next), but build fails:
>
> rdma
> make[1]: Entering directory '/var/src/iproute2-net-next/rdma'
> CC rdma.o
> rdma.c: In function ‘rd_init’:
> rdma.c:64:21: error: ‘RDMA_NLDEV_CMD_GET’ undeclared (first use in this function)
> rd_prepare_msg(rd, RDMA_NLDEV_CMD_GET,
> ^~~~~~~~~~~~~~~~~~
>
>
>
> I think you are depending on some header file that has a more recent version
> on your system. Iproute2 has its own include/ directory to deal with this
> type of override. Already have headers for kernel and iptables.
Yes, I'm building against Doug's for-next branch.
https://git.kernel.org/pub/scm/linux/kernel/git/dledford/rdma.git/tree/include/uapi/rdma/rdma_netlink.h?h=k.o/for-next#n241
I'll copy that file to iproute2/include/ and resubmit.
Thanks
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH] PCI: Allow PCI express root ports to find themselves
From: Michael Ellerman @ 2017-08-18 4:32 UTC (permalink / raw)
To: Thierry Reding, David Miller, Bjorn Helgaas, Ding Tianhong
Cc: leedom, ashok.raj, werner, ganeshgr, asit.k.mallick,
patrick.j.cramer, Suravee.Suthikulpanit, Bob.Shaw, l.stach, amira,
gabriele.paoloni, David.Laight, jeffrey.t.kirsher,
catalin.marinas, will.deacon, mark.rutland, robin.murphy,
alexander.duyck, eric.dumazet, linux-arm-kernel, netdev,
linux-pci, linux-kernel, linuxarm
In-Reply-To: <20170817110614.11454-1-thierry.reding@gmail.com>
Thierry Reding <thierry.reding@gmail.com> writes:
> From: Thierry Reding <treding@nvidia.com>
>
> If the pci_find_pcie_root_port() function is called on a root port
> itself, return the root port rather than NULL.
>
> This effectively reverts commit 0e405232871d6 ("PCI: fix oops when
> try to find Root Port for a PCI device") which added an extra check
> that would now be redundant.
>
> Fixes: a99b646afa8a ("PCI: Disable PCIe Relaxed Ordering if unsupported")
> Fixes: c56d4450eb68 ("PCI: Turn off Request Attributes to avoid Chelsio T5 Completion erratum")
> Signed-off-by: Thierry Reding <treding@nvidia.com>
> ---
> This applies on top of and was tested on next-20170817.
>
> Michael, it'd be great if you could test this one again to clarify
> whether or not the fix that's already in Linus' tree is still needed, or
> whether it's indeed obsoleted by this patch.
This works fine for me, applied on top of Linus' tree (d33a2a914319).
cheers
^ permalink raw reply
* using PASIDs to enable a safe variant of direct ring access
From: Michael S. Tsirkin @ 2017-08-18 3:39 UTC (permalink / raw)
To: John Fastabend, fw, gerlitz.or, hannes
Cc: netdev, john.ronciak, amirv, eric.dumazet, danny.zhou,
Ilan Tayari, Raj, Ashok, Tian, Kevin
Back in 2014, patches "net: sched: af_packet support for direct ring
access" were rejected since there was no memory protection performed by
any part of the system.
The point of the patchset was
to split off a set of driver queues
from the driver and map the queues into user space via mmap. This
allows the queues to be directly manipulated from user space. For
raw packet interface this removes any overhead from the kernel network
stack.
In other words this was proposed to help people using userspace drivers -
they don't really need them to be in full control of their devices. Only
data path operations need to avoid system call overhead, all setup is
better off managed by the kernel (maybe they should stop using userspace
drivers, but that's a different discussion).
Unfortunately the patches were insecure: as all dma memory accesses by the
same device are tagged with the same source (bus/device/function) the
iommu can not differentiate between kernel and userspace queues and so
can not protect us from a malicious userspace. So from security POV
this is not much better than userspace banging hardware registers
directly really.
However, there actually exists a way to attach an extra tag
to each pci express transaction, and that's with PASID support
which has been supported in the kernel for a while now.
So all we need is a NIC that will allow the kernel to attach a PASID tag
to queues that are given to userspace, and the patches could then be
made safe for this NIC by using the IOMMU for protection.
GPUs commonly support PASIDs and utilize this for security more or less
exactly like this, but I do not think any NICs do, so far.
Why not?
Could this be something that's easy to add to existing/future hardware?
Maybe with a firmware update? What we need is just ability to specify
for each queue which PASID to use when doing DMA to send/receive
packets.
Not working for a hardware vendor, I'd love to hear from people who are.
Thanks,
--
MST
^ permalink raw reply
* Re: [PATCH v3 net-next] bpf/verifier: track liveness for pruning
From: Alexei Starovoitov via iovisor-dev @ 2017-08-18 3:21 UTC (permalink / raw)
To: Edward Cree, davem-fT/PcQaiUtIeIZ0/mPfg9Q, Alexei Starovoitov,
Daniel Borkmann
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, iovisor-dev,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <f40d3d54-c88a-7348-99ca-66db8075a8d5-s/n/eUQHGBpZroRs9YW3xA@public.gmane.org>
On 8/15/17 12:34 PM, Edward Cree wrote:
> State of a register doesn't matter if it wasn't read in reaching an exit;
> a write screens off all reads downstream of it from all explored_states
> upstream of it.
> This allows us to prune many more branches; here are some processed insn
> counts for some Cilium programs:
> Program before after
> bpf_lb_opt_-DLB_L3.o 6515 3361
> bpf_lb_opt_-DLB_L4.o 8976 5176
> bpf_lb_opt_-DUNKNOWN.o 2960 1137
> bpf_lxc_opt_-DDROP_ALL.o 95412 48537
> bpf_lxc_opt_-DUNKNOWN.o 141706 78718
> bpf_netdev.o 24251 17995
> bpf_overlay.o 10999 9385
>
> The runtime is also improved; here are 'time' results in ms:
> Program before after
> bpf_lb_opt_-DLB_L3.o 24 6
> bpf_lb_opt_-DLB_L4.o 26 11
> bpf_lb_opt_-DUNKNOWN.o 11 2
> bpf_lxc_opt_-DDROP_ALL.o 1288 139
> bpf_lxc_opt_-DUNKNOWN.o 1768 234
> bpf_netdev.o 62 31
> bpf_overlay.o 15 13
>
> Signed-off-by: Edward Cree <ecree-s/n/eUQHGBpZroRs9YW3xA@public.gmane.org>
this is one ingenious hack. Love it!
I took me whole day to understand most of it, but I still have
few questions:
> +
> +static void propagate_liveness(const struct bpf_verifier_state *state,
> + struct bpf_verifier_state *parent)
here the name 'parent' is very confusing, since for the first
iteration of the loop below it transfers lives from 'neighbor'
state to the current state and only then traverses the link
of parents in the current.
Would be good to document it, since I was struggling the most
with this name until I realized that the way you build parent link list
in is_state_visited() is actual sequence of roughly basic blocks and
the name 'parent' applies there, but not for the first iteration
of this function.
> @@ -3407,6 +3501,14 @@ static int is_state_visited(struct bpf_verifier_env *env, int insn_idx)
> memcpy(&new_sl->state, &env->cur_state, sizeof(env->cur_state));
> new_sl->next = env->explored_states[insn_idx];
> env->explored_states[insn_idx] = new_sl;
> + /* connect new state to parentage chain */
> + env->cur_state.parent = &new_sl->state;
> + /* clear liveness marks in current state */
> + for (i = 0; i < BPF_REG_FP; i++)
> + env->cur_state.regs[i].live = REG_LIVE_NONE;
> + for (i = 0; i < MAX_BPF_STACK / BPF_REG_SIZE; i++)
> + if (env->cur_state.stack_slot_type[i * BPF_REG_SIZE] == STACK_SPILL)
> + env->cur_state.spilled_regs[i].live = REG_LIVE_NONE;
and this part I don't get at all.
It seems you're trying to sort-of do per-fake-basic block liveness
analysis, but our state_list_marks are not correct if we go with
canonical basic block definition, since we mark the jump insn and
not insn after the branch and not every basic block boundary is
properly detected.
So if algorithm should only work for basic blocks (for sequences of
instructions without control flow changes) then it's broken.
If it should work with control flow insns then it should also work
for the whole chain of insns from the first one till bpf_exit...
So I tried removing two above clearing loops and results are much
better:
before after
bpf_lb-DLB_L3.o 2604 1120
bpf_lb-DLB_L4.o 11159 1371
bpf_lb-DUNKNOWN.o 1116 485
bpf_lxc-DDROP_ALL.o 34566 12758
bpf_lxc-DUNKNOWN.o 53267 18337
bpf_netdev.o 17843 10564
bpf_overlay.o 8672 5513
but it feels too good to be true and probably not correct.
So either way we need to fix something it seems.
^ permalink raw reply
* RE: [PATCH] vsock: only load vmci transport on VMware hypervisor by default
From: Dexuan Cui @ 2017-08-18 3:07 UTC (permalink / raw)
To: Jorgen S. Hansen, Stefan Hajnoczi
Cc: Michal Kubecek, joe@perches.com, olaf@aepfle.de,
Stephen Hemminger, jasowang@redhat.com, netdev@vger.kernel.org,
Haiyang Zhang, Dave Scott, apw@canonical.com,
linux-kernel@vger.kernel.org, Vitaly Kuznetsov, Rolf Neugebauer,
gregkh@linuxfoundation.org, Marcelo Cerri,
devel@linuxdriverproject.org, Asias He, davem@davemloft.net,
George Zhang, Dan Carpenter
In-Reply-To: <04460E3B-B213-4090-96CD-00CEEBE6AC32@vmware.com>
> From: Jorgen S. Hansen [mailto:jhansen@vmware.com]
> Sent: Thursday, August 17, 2017 08:17
> >
> > Putting aside nested virtualization, I want to load the transport (vmci,
> > Hyper-V, vsock) for which there is paravirtualized hardware present
> > inside the guest.
>
> Good points. Completely agree that this is the desired behavior for a guest.
>
>
> > It's a little tricker on the host side (doesn't matter for Hyper-V and
> > probably also doesn't for VMware) because the host-side driver is a
> > software device with no hardware backing it. In KVM we assume the
> > vhost_vsock.ko kernel module will be loaded sufficiently early.
>
> Since the vmci driver is currently tied to PF_VSOCK it hasn’t been a problem,
> but on the host side the VMCI driver has no hardware backing it either, so
> when we move to a more appropriate solution, this will be an issue for VMCI as
> well. I’ll check our shipped products, but they most likely assume that if an
> upstreamed vmci module is present, it will be loaded automatically.
Hyper-V Sockets is a standard feature of VMBus v4.0, so we can easily know
we can and should load iff vmbus_proto_version >= VERSION_WIN10.
> > Things get trickier with nested virtualization because the VM might want
> > to talk to its host but also to its nested VMs. The simple way of
> > fixing this would be to allow two transports loaded simultaneously and
> > route traffic destined to CID 2 to the host transport and all other
> > traffic to the guest transport.
This sounds like a little tricky to me.
CID is not really used by us, because we only support guest<->host communication,
and don't support guest<->guest communication. The Hyper-V host references
every VM by VmID (which is invisible to the VM), and a VM can only talk to the
host via this feature.
> This is close to the routing the VMCI driver does in a nested environment, but
> that is with the assumption that there is only one type of transport. Having two
> different transports would require that we delay resolving the transport type
> until the socket endpoint has been bound to an address. Things get trickier if
> listening sockets use VMADDR_CID_ANY - if only one transport is present, this
> would allow the socket to accept connections from both guests and outer host,
> but with multiple transports that won’t work, since we can’t associate a socket
> with a transport until the socket is bound.
>
> >
> > Perhaps we should discuss these cases a bit more to figure out how to
> > avoid conflicts over MODULE_ALIAS_NETPROTO(PF_VSOCK).
>
> Agreed.
Can we use the 'protocol' parameter in the socket() function:
int socket(int domain, int type, int protocol)
IMO currently the 'protocol' is not really used.
I think we can modify __vsock_core_init() to allow multiple transport layers to
be registered, and we can define different 'protocol' numbers for
VMware/KVM/Hyper-V, and ask the application to explicitly specify what should
be used. Considering compatibility, we can use the default transport in a given
VM depending on the underlying hypervisor.
-- Dexuan
_______________________________________________
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
^ permalink raw reply
* [PATCHv2 net] net: sched: fix NULL pointer dereference when action calls some targets
From: Xin Long @ 2017-08-18 3:01 UTC (permalink / raw)
To: network dev; +Cc: davem, Cong Wang, pablo
As we know in some target's checkentry it may dereference par.entryinfo
to check entry stuff inside. But when sched action calls xt_check_target,
par.entryinfo is set with NULL. It would cause kernel panic when calling
some targets.
It can be reproduce with:
# tc qd add dev eth1 ingress handle ffff:
# tc filter add dev eth1 parent ffff: u32 match u32 0 0 action xt \
-j ECN --ecn-tcp-remove
It could also crash kernel when using target CLUSTERIP or TPROXY.
By now there's no proper value for par.entryinfo in ipt_init_target,
but it can not be set with NULL. This patch is to void all these
panics by setting it with an ipt_entry obj with all members = 0.
Note that this issue has been there since the very beginning.
Signed-off-by: Xin Long <lucien.xin@gmail.com>
---
net/sched/act_ipt.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/net/sched/act_ipt.c b/net/sched/act_ipt.c
index d516ba8..5417078 100644
--- a/net/sched/act_ipt.c
+++ b/net/sched/act_ipt.c
@@ -41,6 +41,7 @@ static int ipt_init_target(struct net *net, struct xt_entry_target *t,
{
struct xt_tgchk_param par;
struct xt_target *target;
+ struct ipt_entry e = {};
int ret = 0;
target = xt_request_find_target(AF_INET, t->u.user.name,
@@ -52,6 +53,7 @@ static int ipt_init_target(struct net *net, struct xt_entry_target *t,
memset(&par, 0, sizeof(par));
par.net = net;
par.table = table;
+ par.entryinfo = &e;
par.target = target;
par.targinfo = t->data;
par.hook_mask = hook;
--
2.1.0
^ permalink raw reply related
* [PATCH net v2] datagram: When peeking datagrams with offset < 0 don't skip empty skbs
From: Matthew Dawson @ 2017-08-18 2:11 UTC (permalink / raw)
To: netdev; +Cc: Matthew Dawson, Macieira, Thiago, willemdebruijn.kernel,
Paolo Abeni
Due to commit e6afc8ace6dd5cef5e812f26c72579da8806f5ac ("udp: remove
headers from UDP packets before queueing"), when udp packets are being
peeked the requested extra offset is always 0 as there is no need to skip
the udp header. However, when the offset is 0 and the next skb is
of length 0, it is only returned once. The behaviour can be seen with
the following python script:
from socket import *;
f=socket(AF_INET6, SOCK_DGRAM | SOCK_NONBLOCK, 0);
g=socket(AF_INET6, SOCK_DGRAM | SOCK_NONBLOCK, 0);
f.bind(('::', 0));
addr=('::1', f.getsockname()[1]);
g.sendto(b'', addr)
g.sendto(b'b', addr)
print(f.recvfrom(10, MSG_PEEK));
print(f.recvfrom(10, MSG_PEEK));
Where the expected output should be the empty string twice.
Instead, make sk_peek_offset return negative values, and pass those values
to __skb_try_recv_datagram/__skb_try_recv_from_queue. If the passed offset
to __skb_try_recv_from_queue is negative, the checked skb is never skipped.
__skb_try_recv_from_queue will then ensure the offset is reset back to 0
if a peek is requested without an offset, unless no packets are found.
Also simplify the if condition in __skb_try_recv_from_queue. If _off is
greater then 0, and off is greater then or equal to skb->len, then
(_off || skb->len) must always be true assuming skb->len >= 0 is always
true.
Also remove a redundant check around a call to sk_peek_offset in af_unix.c,
as it double checked if MSG_PEEK was set in the flags.
V2:
- Moved the negative fixup into __skb_try_recv_from_queue, and remove now
redundant checks
- Fix peeking in udp{,v6}_recvmsg to report the right value when the
offset is 0
Signed-off-by: Matthew Dawson <matthew@mjdsystems.ca>
---
include/net/sock.h | 4 +---
net/core/datagram.c | 12 +++++++++---
net/ipv4/udp.c | 3 ++-
net/ipv6/udp.c | 3 ++-
net/unix/af_unix.c | 5 +----
5 files changed, 15 insertions(+), 12 deletions(-)
diff --git a/include/net/sock.h b/include/net/sock.h
index 7c0632c7e870..aeeec62992ca 100644
--- a/include/net/sock.h
+++ b/include/net/sock.h
@@ -507,9 +507,7 @@ int sk_set_peek_off(struct sock *sk, int val);
static inline int sk_peek_offset(struct sock *sk, int flags)
{
if (unlikely(flags & MSG_PEEK)) {
- s32 off = READ_ONCE(sk->sk_peek_off);
- if (off >= 0)
- return off;
+ return READ_ONCE(sk->sk_peek_off);
}
return 0;
diff --git a/net/core/datagram.c b/net/core/datagram.c
index ee5647bd91b3..4b558503bef5 100644
--- a/net/core/datagram.c
+++ b/net/core/datagram.c
@@ -169,14 +169,20 @@ struct sk_buff *__skb_try_recv_from_queue(struct sock *sk,
int *peeked, int *off, int *err,
struct sk_buff **last)
{
+ bool peek_at_off = false;
struct sk_buff *skb;
- int _off = *off;
+ int _off = 0;
+
+ if (flags & MSG_PEEK && *off >= 0) {
+ peek_at_off = true;
+ _off = *off;
+ }
*last = queue->prev;
skb_queue_walk(queue, skb) {
if (flags & MSG_PEEK) {
- if (_off >= skb->len && (skb->len || _off ||
- skb->peeked)) {
+ if (peek_at_off && _off >= skb->len &&
+ (_off || skb->peeked)) {
_off -= skb->len;
continue;
}
diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
index a7c804f73990..cd1d044a7fa5 100644
--- a/net/ipv4/udp.c
+++ b/net/ipv4/udp.c
@@ -1574,7 +1574,8 @@ int udp_recvmsg(struct sock *sk, struct msghdr *msg, size_t len, int noblock,
return ip_recv_error(sk, msg, len, addr_len);
try_again:
- peeking = off = sk_peek_offset(sk, flags);
+ peeking = flags & MSG_PEEK;
+ off = sk_peek_offset(sk, flags);
skb = __skb_recv_udp(sk, flags, noblock, &peeked, &off, &err);
if (!skb)
return err;
diff --git a/net/ipv6/udp.c b/net/ipv6/udp.c
index 578142b7ca3e..20039c8501eb 100644
--- a/net/ipv6/udp.c
+++ b/net/ipv6/udp.c
@@ -362,7 +362,8 @@ int udpv6_recvmsg(struct sock *sk, struct msghdr *msg, size_t len,
return ipv6_recv_rxpmtu(sk, msg, len, addr_len);
try_again:
- peeking = off = sk_peek_offset(sk, flags);
+ peeking = flags & MSG_PEEK;
+ off = sk_peek_offset(sk, flags);
skb = __skb_recv_udp(sk, flags, noblock, &peeked, &off, &err);
if (!skb)
return err;
diff --git a/net/unix/af_unix.c b/net/unix/af_unix.c
index 7b52a380d710..be8982b4f8c0 100644
--- a/net/unix/af_unix.c
+++ b/net/unix/af_unix.c
@@ -2304,10 +2304,7 @@ static int unix_stream_read_generic(struct unix_stream_read_state *state,
*/
mutex_lock(&u->iolock);
- if (flags & MSG_PEEK)
- skip = sk_peek_offset(sk, flags);
- else
- skip = 0;
+ skip = max(sk_peek_offset(sk, flags), 0);
do {
int chunk;
--
2.13.0
^ permalink raw reply related
* Re: [PATCH net-next] bpf: Fix map-in-map checking in the verifier
From: John Fastabend @ 2017-08-18 2:08 UTC (permalink / raw)
To: Alexei Starovoitov, Martin KaFai Lau, netdev; +Cc: Daniel Borkmann, kernel-team
In-Reply-To: <eb62aeba-487b-e3fe-3c9d-85c0b8eeaf04@fb.com>
On 08/17/2017 06:17 PM, Alexei Starovoitov wrote:
> On 8/17/17 6:14 PM, Martin KaFai Lau wrote:
>> In check_map_func_compatibility(), a 'break' has been accidentally
>> removed for the BPF_MAP_TYPE_ARRAY_OF_MAPS and BPF_MAP_TYPE_HASH_OF_MAPS
>> cases. This patch adds it back.
>>
>> Fixes: 174a79ff9515 ("bpf: sockmap with sk redirect support")
>> Cc: John Fastabend <john.fastabend@gmail.com>
>> Signed-off-by: Martin KaFai Lau <kafai@fb.com>
>
> Nice catch!
> Acked-by: Alexei Starovoitov <ast@kernel.org>
>
Thanks a lot!
Acked-by: John Fastabend <john.fastabend@gmail.com>
^ permalink raw reply
* Re: [PATCH] PCI: Allow PCI express root ports to find themselves
From: Shawn Lin @ 2017-08-18 1:29 UTC (permalink / raw)
To: Thierry Reding, David Miller, Bjorn Helgaas, Ding Tianhong,
Michael Ellerman
Cc: shawn.lin, leedom, ashok.raj, werner, ganeshgr, asit.k.mallick,
patrick.j.cramer, Suravee.Suthikulpanit, Bob.Shaw, l.stach, amira,
gabriele.paoloni, David.Laight, jeffrey.t.kirsher,
catalin.marinas, will.deacon, mark.rutland, robin.murphy,
alexander.duyck, eric.dumazet, linux-arm-kernel, netdev,
linux-pci, linux-kernel, linuxarm
In-Reply-To: <20170817110614.11454-1-thierry.reding@gmail.com>
Hi
On 2017/8/17 19:06, Thierry Reding wrote:
> From: Thierry Reding <treding@nvidia.com>
>
> If the pci_find_pcie_root_port() function is called on a root port
> itself, return the root port rather than NULL.
>
> This effectively reverts commit 0e405232871d6 ("PCI: fix oops when
> try to find Root Port for a PCI device") which added an extra check
> that would now be redundant.
>
> Fixes: a99b646afa8a ("PCI: Disable PCIe Relaxed Ordering if unsupported")
> Fixes: c56d4450eb68 ("PCI: Turn off Request Attributes to avoid Chelsio T5 Completion erratum")
> Signed-off-by: Thierry Reding <treding@nvidia.com>
Tested-by: Shawn Lin <shawn.lin@rock-chips.com>
> ---
> This applies on top of and was tested on next-20170817.
>
> Michael, it'd be great if you could test this one again to clarify
> whether or not the fix that's already in Linus' tree is still needed, or
> whether it's indeed obsoleted by this patch.
>
> drivers/pci/pci.c | 9 ++++-----
> 1 file changed, 4 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> index b05c587e335a..dd56c1c05614 100644
> --- a/drivers/pci/pci.c
> +++ b/drivers/pci/pci.c
> @@ -514,7 +514,7 @@ EXPORT_SYMBOL(pci_find_resource);
> */
> struct pci_dev *pci_find_pcie_root_port(struct pci_dev *dev)
> {
> - struct pci_dev *bridge, *highest_pcie_bridge = NULL;
> + struct pci_dev *bridge, *highest_pcie_bridge = dev;
>
> bridge = pci_upstream_bridge(dev);
> while (bridge && pci_is_pcie(bridge)) {
> @@ -522,11 +522,10 @@ struct pci_dev *pci_find_pcie_root_port(struct pci_dev *dev)
> bridge = pci_upstream_bridge(bridge);
> }
>
> - if (highest_pcie_bridge &&
> - pci_pcie_type(highest_pcie_bridge) == PCI_EXP_TYPE_ROOT_PORT)
> - return highest_pcie_bridge;
> + if (pci_pcie_type(highest_pcie_bridge) != PCI_EXP_TYPE_ROOT_PORT)
> + return NULL;
>
> - return NULL;
> + return highest_pcie_bridge;
> }
> EXPORT_SYMBOL(pci_find_pcie_root_port);
>
>
^ permalink raw reply
* Re: [PATCH v2] bpf: Update sysctl documentation to list all supported architectures
From: Michael Ellerman @ 2017-08-18 1:27 UTC (permalink / raw)
To: Daniel Borkmann, ast; +Cc: davem, netdev, linux-kernel
In-Reply-To: <59958304.7030702@iogearbox.net>
Daniel Borkmann <daniel@iogearbox.net> writes:
> On 08/17/2017 12:30 PM, Michael Ellerman wrote:
>> The sysctl documentation states that the JIT is only available on
>> x86_64, which is no longer correct.
>>
>> Update the list, and break it out to indicate which architectures
>> support the cBPF JIT (via HAVE_CBPF_JIT) or the eBPF JIT
>> (HAVE_EBPF_JIT).
>>
>> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
>
> The last paragraph speaking about tcpdump, I can take care of
> later, also given the patch is about updating list of archs, so
> lgtm, thanks!
Thanks.
cheers
^ permalink raw reply
* Re: Thoughts on staging and on fixing up drivers?
From: Larry Finger @ 2017-08-18 1:22 UTC (permalink / raw)
To: whiteheadm, Dan Carpenter
Cc: devel, PJ Waskiewicz, Ping-Ke Shih, Yan-Hsuan Chuang,
Greg Kroah-Hartman, Shaofu, Birming Chiu, netdev, Steven Ting
In-Reply-To: <CAP8WD_aSE7f31Y9HNJ0h_6CNocB0Yjm_qeDjk=wnBJV16T=F7A@mail.gmail.com>
On 08/17/2017 04:07 PM, tedheadster wrote:
>>
>> Larry, you've migrated a bunch of staging code, and tried various
>> approaches. Do you have any lessons on what has worked and what hasn't
>> and if there is anything we can do to make the process better?
>
> I am also quite interested in such work. We asked for a Birds of
> Feather discussion at the upcoming Linux Plumbers conference on
> exactly this sort of work.
Matthew and Dan,
I will try to answer the question as best I can.
I got started in working with Realtek wireless devices at roughly the time that
staging was created. At that time, Realtek published drivers sporadically. They
would accumulate fixes in their internal svn repositories, then take a snapshot,
and publish that with no information regarding what was changed. Even trying to
diff the two versions was not useful. Obviously this mode of code development is
not consistent with the Linux model.
After I was able to get driver r8712u into staging, I received an E-mail from
Realtek asking if I would be willing to help them get their drivers into the
kernel. They have provided sample chips and extenders to let me test drivers on
my laptops, but I have not gotten any remuneration from Realtek. This
collaboration has led to the rtlwifi family of drivers. A few of them have gone
through staging because there was some urgency in getting them added to Linux.
That is the case for today's submission of a driver for the RTL8822BE, which is
appearing in some computers. This particular device implements a new Realtek
model for hardware abstraction of the MAC, PHY, and dynamic management
functions, which has increased the number of new lines of code to about 120K.
Getting that much new code through the review process in the wireless tree would
take a lot of time. Essentially, staging allows users to have access to the
functionality while that review is in progress. Another card now appearing in
the wild is the RTL8723DE. It will likely also reside initially in staging.
Besides getting wifi drivers for these cards into Linux, I have also been
training the Realtek engineers and getting them to issue fixes as many small
changes. That part of my "job" has been going very well, and I will soon be
getting them to submit their material directly. That change is necessary as I am
now 77, with the question of how long I will be continuing.
As you can tell, I am very pleased with the staging tree and its usage for new
drivers, particularly where the regular trees move more slowly than the
marketplace. Staging is a big help in supporting the users that otherwise will
have no wifi under Linux. Their distro may not build staging drivers in their
standard kernels, but configuring and building kernels is not too difficult.
The part that does not work is best exemplified by the driver that got me
started, namely r8712u. The USB section at Realtek has not been as cooperative
as the PCI/SDIO group. As a result, there is no path from staging to wireless
and that driver will be left in staging as long as GregKH allows it. Now, I put
that sort of material in a GitHub repo and force users to build it as an
out-of-kernel driver. Of course, that method has its own problems. How many
times a week do you want to tell another user that they need to install the
kernel-headers, and no, I do not know how to do it on your distro. Now we have
one example (rtl8723bs) where the GitHub driver was placed in staging. That one
is likely to be moved to wireless.
This reply is getting rather long. I will be happy to answer any further questions.
Larry
^ permalink raw reply
* Re: [PATCH net-next] bpf: Fix map-in-map checking in the verifier
From: Alexei Starovoitov @ 2017-08-18 1:17 UTC (permalink / raw)
To: Martin KaFai Lau, netdev; +Cc: Daniel Borkmann, kernel-team, John Fastabend
In-Reply-To: <20170818011443.562793-1-kafai@fb.com>
On 8/17/17 6:14 PM, Martin KaFai Lau wrote:
> In check_map_func_compatibility(), a 'break' has been accidentally
> removed for the BPF_MAP_TYPE_ARRAY_OF_MAPS and BPF_MAP_TYPE_HASH_OF_MAPS
> cases. This patch adds it back.
>
> Fixes: 174a79ff9515 ("bpf: sockmap with sk redirect support")
> Cc: John Fastabend <john.fastabend@gmail.com>
> Signed-off-by: Martin KaFai Lau <kafai@fb.com>
Nice catch!
Acked-by: Alexei Starovoitov <ast@kernel.org>
^ permalink raw reply
* [PATCH net-next] bpf: Fix map-in-map checking in the verifier
From: Martin KaFai Lau @ 2017-08-18 1:14 UTC (permalink / raw)
To: netdev; +Cc: Alexei Starovoitov, Daniel Borkmann, kernel-team, John Fastabend
In check_map_func_compatibility(), a 'break' has been accidentally
removed for the BPF_MAP_TYPE_ARRAY_OF_MAPS and BPF_MAP_TYPE_HASH_OF_MAPS
cases. This patch adds it back.
Fixes: 174a79ff9515 ("bpf: sockmap with sk redirect support")
Cc: John Fastabend <john.fastabend@gmail.com>
Signed-off-by: Martin KaFai Lau <kafai@fb.com>
---
kernel/bpf/verifier.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
index 40f669ddb571..4f6e7eb42ba0 100644
--- a/kernel/bpf/verifier.c
+++ b/kernel/bpf/verifier.c
@@ -1523,6 +1523,7 @@ static int check_map_func_compatibility(struct bpf_map *map, int func_id)
case BPF_MAP_TYPE_HASH_OF_MAPS:
if (func_id != BPF_FUNC_map_lookup_elem)
goto error;
+ break;
case BPF_MAP_TYPE_SOCKMAP:
if (func_id != BPF_FUNC_sk_redirect_map &&
func_id != BPF_FUNC_sock_map_update &&
--
2.9.5
^ permalink raw reply related
* Re: [PATCH iproute2 json v2 00/27] ip: add -json support to 'ip link show'
From: Stephen Hemminger @ 2017-08-18 1:04 UTC (permalink / raw)
To: Julien Fortin; +Cc: netdev, roopa, nikolay, dsa
In-Reply-To: <20170817173614.54987-1-julien@cumulusnetworks.com>
On Thu, 17 Aug 2017 10:35:47 -0700
Julien Fortin <julien@cumulusnetworks.com> wrote:
> From: Julien Fortin <julien@cumulusnetworks.com>
>
> This patch series adds json support to 'ip [-details] link show [dev DEV]'
> Each patch describes the json schema it adds and provides some examples.
>
> Julien Fortin (27):
> color: add new COLOR_NONE and disable_color function
> ip: add new command line argument -json (mutually exclusive with
> -color)
> json_writer: add new json handlers (null, float with format, lluint,
> hu)
> ip: ip_print: add new API to print JSON or regular format output
> ip: ipaddress.c: add support for json output
> ip: iplink.c: open/close json obj for ip -brief -json link show dev
> DEV
> ip: iplink_bond.c: add json output support
> ip: iplink_bond_slave.c: add json output support (info_slave_data)
> ip: iplink_hsr.c: add json output support
> ip: iplink_bridge.c: add json output support
> ip: iplink_bridge_slave.c: add json output support
> ip: iplink_can.c: add json output support
> ip: iplink_geneve.c: add json output support
> ip: iplink_ipoib.c: add json output support
> ip: iplink_ipvlan.c: add json output support
> ip: iplink_vrf.c: add json output support
> ip: iplink_vxlan.c: add json output support
> ip: iplink_xdp.c: add json output support
> ip: ipmacsec.c: add json output support
> ip: link_gre.c: add json output support
> ip: link_gre6.c: add json output support
> ip: link_ip6tnl.c: add json output support
> ip: link_iptnl.c: add json output support
> ip: link_vti.c: add json output support
> ip: link_vti6.c: add json output support
> ip: link_macvlan.c: add json output support
> ip: iplink_vlan.c: add json output support
>
> include/color.h | 2 +
> include/json_writer.h | 9 +
> include/utils.h | 1 +
> ip/Makefile | 2 +-
> ip/ip.c | 6 +
> ip/ip_common.h | 56 +++
> ip/ip_print.c | 233 ++++++++++
> ip/ipaddress.c | 1064 ++++++++++++++++++++++++++++++++--------------
> ip/iplink.c | 2 +
> ip/iplink_bond.c | 231 ++++++----
> ip/iplink_bond_slave.c | 57 ++-
> ip/iplink_bridge.c | 293 ++++++++-----
> ip/iplink_bridge_slave.c | 185 ++++----
> ip/iplink_can.c | 282 ++++++++----
> ip/iplink_geneve.c | 86 +++-
> ip/iplink_hsr.c | 36 +-
> ip/iplink_ipoib.c | 30 +-
> ip/iplink_ipvlan.c | 8 +-
> ip/iplink_macvlan.c | 37 +-
> ip/iplink_vlan.c | 62 ++-
> ip/iplink_vrf.c | 13 +-
> ip/iplink_vxlan.c | 161 ++++---
> ip/iplink_xdp.c | 31 +-
> ip/ipmacsec.c | 84 +++-
> ip/link_gre.c | 147 ++++---
> ip/link_gre6.c | 142 +++++--
> ip/link_ip6tnl.c | 172 +++++---
> ip/link_iptnl.c | 155 ++++---
> ip/link_vti.c | 24 +-
> ip/link_vti6.c | 22 +-
> lib/color.c | 12 +-
> lib/json_writer.c | 44 +-
> 32 files changed, 2663 insertions(+), 1026 deletions(-)
> create mode 100644 ip/ip_print.c
>
This looks good, Thanks Julien et all.
Applied to net-next branch.
You may need to make sure that as new features get added that json support
continues to work.
^ permalink raw reply
* Re: [PATCH REPOST v5 iproute2 0/8] RDMAtool
From: Stephen Hemminger @ 2017-08-18 1:01 UTC (permalink / raw)
To: Leon Romanovsky
Cc: Doug Ledford, linux-rdma-u79uwXL29TY76Z2rM5mHXA,
Dennis Dalessandro, Jason Gunthorpe, Jiri Pirko, Ariel Almog,
David Laight, Linux Netdev
In-Reply-To: <20170817065614.1393-1-leonro-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
On Thu, 17 Aug 2017 09:56:06 +0300
Leon Romanovsky <leonro-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org> wrote:
> This is fifth revision of series implementing the RDAMtool - the tool
> to configure RDMA devices.
>
> It looks like everyone who was interested to read cover letter already did it,
> so I'll start from the changelog:
>
> Changelog:
> v4->v5:
> * Rebased to latest net-next branch
> * Moved BIT() macro from devlink to general utils.h file - Patch #1.
> * Changed the order of patches - moved man pages to be last patch.
> * Rewrote all switch->case->return_string constructions to be static
> tables with help of David's macro magic. Thanks a lot.
> * Dropped dependency on exported device and port properties. Now tool depends
> on RDMA netlink only and all needed code is already in Doug's for-next.
> * Added two OPA specific physical link states, because their names is
> too broad - TEST and OFFLINE, I named it as OPA_TEST and OPA_OFFLINE.
> v3->v4:
> * Rebased to latest net-next branch
> * Added JSON output -j (json) and -p (pretty output)
> * Exported and reused kernel UAPIs and defines instead of hard coded
> version.
> v2->v3:
> * Removed MAX()
> * Reduced scope of rd_argv_match
> * Removed return from rdma_free_devmap
> * Added extra break at rdma_send_msg
> v1->v2:
> * Squashed multiple (and similar) patches to be one patch for dev object
> and one patch for link object.
> * Removed port_map struct
> * Removed global netlink dump during initialization, it removed the need to store
> the intermediate variables and reuse ability of netlink to signal if variable
> exists or doesn't.
> * Added "-d" --details option and put all CAPs under it.
>
> v0->v1:
> * Moved hunk with changes in man/Makefile from first patch to the last patch
> * Removed the "unknown command" from the examples in commit messages
> * Removed special "caps" parsing command and put it to be part of general "show" command
> * Changed parsed capability format to be similar to iproute2 suite
> * Added FW version as an output of show command.
> * Added forgotten CAP_FLAGS to the nla_policy list
> RFC->v0:
> * Removed everything that is not implemented yet.
> * Abandoned sysfs interfaces in favor of netlink.
>
> -----
> The initial proposal was sent as RFC [1] and was based on sysfs entries as POC.
>
> The current series was rewritten completely to work with RDMA netlinks as
> a source of user<->kernel communications. In order to achieve that, the
> RDMA netlinks were extensively refactored and modernized [2, 3, 4 and 5].
>
> The Doug's for-next tag includes most of the needed patches for this tool.
>
> The following is an example of various runs on my machine with 5 devices
> (4 in IB mode and one in Ethernet mode).
>
> ### Without parameters
> $ rdma
> Usage: rdma [ OPTIONS ] OBJECT { COMMAND | help }
> where OBJECT := { dev | link | help }
> OPTIONS := { -V[ersion] | -d[etails] | -j[son] | -p[retty]}
>
> ### With unspecified device name
> $ rdma dev
> 1: mlx5_0: node_type ca fw 2.8.9999 node_guid 5254:00c0:fe12:3457 sys_image_guid 5254:00c0:fe12:3457
> 2: mlx5_1: node_type ca fw 2.8.9999 node_guid 5254:00c0:fe12:3458 sys_image_guid 5254:00c0:fe12:3458
> 3: mlx5_2: node_type ca fw 2.8.9999 node_guid 5254:00c0:fe12:3459 sys_image_guid 5254:00c0:fe12:3459
> 4: mlx5_3: node_type ca fw 2.8.9999 node_guid 5254:00c0:fe12:345a sys_image_guid 5254:00c0:fe12:345a
> 5: mlx5_4: node_type ca fw 2.8.9999 node_guid 5254:00c0:fe12:345b sys_image_guid 5254:00c0:fe12:345b
>
> ### Detailed mode
> $ rdma -d dev
> 1: mlx5_0: node_type ca fw 2.8.9999 node_guid 5254:00c0:fe12:3457 sys_image_guid 5254:00c0:fe12:3457
> caps: <BAD_PKEY_CNTR, BAD_QKEY_CNTR, CHANGE_PHY_POR, PORT_ACTIVE_EVENT, SYS_IMAGE_GUID, RC_RNR_NAK_GEN, MEM_WINDOW, UD_IP_CSUM, UD_TSO, XRC, MEM_MGT_EXTENSIONS, BLOCK_MULTICAST_LOOPBACK, MEM_WINDOW_TYPE_2B, RAW_IP_CSUM, MANAGED_FLOW_STEERING, RESIZE_MAX_WR>
> 2: mlx5_1: node_type ca fw 2.8.9999 node_guid 5254:00c0:fe12:3458 sys_image_guid 5254:00c0:fe12:3458
> caps: <BAD_PKEY_CNTR, BAD_QKEY_CNTR, CHANGE_PHY_POR, PORT_ACTIVE_EVENT, SYS_IMAGE_GUID, RC_RNR_NAK_GEN, MEM_WINDOW, UD_IP_CSUM, UD_TSO, XRC, MEM_MGT_EXTENSIONS, BLOCK_MULTICAST_LOOPBACK, MEM_WINDOW_TYPE_2B, RAW_IP_CSUM, MANAGED_FLOW_STEERING, RESIZE_MAX_WR>
> 3: mlx5_2: node_type ca fw 2.8.9999 node_guid 5254:00c0:fe12:3459 sys_image_guid 5254:00c0:fe12:3459
> caps: <BAD_PKEY_CNTR, BAD_QKEY_CNTR, CHANGE_PHY_POR, PORT_ACTIVE_EVENT, SYS_IMAGE_GUID, RC_RNR_NAK_GEN, MEM_WINDOW, UD_IP_CSUM, UD_TSO, XRC, MEM_MGT_EXTENSIONS, BLOCK_MULTICAST_LOOPBACK, MEM_WINDOW_TYPE_2B, RAW_IP_CSUM, MANAGED_FLOW_STEERING, RESIZE_MAX_WR>
> 4: mlx5_3: node_type ca fw 2.8.9999 node_guid 5254:00c0:fe12:345a sys_image_guid 5254:00c0:fe12:345a
> caps: <BAD_PKEY_CNTR, BAD_QKEY_CNTR, CHANGE_PHY_POR, PORT_ACTIVE_EVENT, SYS_IMAGE_GUID, RC_RNR_NAK_GEN, MEM_WINDOW, UD_IP_CSUM, UD_TSO, XRC, MEM_MGT_EXTENSIONS, BLOCK_MULTICAST_LOOPBACK, MEM_WINDOW_TYPE_2B, RAW_IP_CSUM, MANAGED_FLOW_STEERING, RESIZE_MAX_WR>
> 5: mlx5_4: node_type ca fw 2.8.9999 node_guid 5254:00c0:fe12:345b sys_image_guid 5254:00c0:fe12:345b
> caps: <BAD_PKEY_CNTR, BAD_QKEY_CNTR, CHANGE_PHY_POR, PORT_ACTIVE_EVENT, SYS_IMAGE_GUID, RC_RNR_NAK_GEN, MEM_WINDOW, UD_IP_CSUM, UD_TSO, XRC, MEM_MGT_EXTENSIONS, BLOCK_MULTICAST_LOOPBACK, MEM_WINDOW_TYPE_2B, RAW_IP_CSUM, MANAGED_FLOW_STEERING, RESIZE_MAX_WR>
>
> ### Specific device
> $ rdma dev show mlx5_4
> 5: mlx5_4: node_type ca fw 2.8.9999 node_guid 5254:00c0:fe12:345b sys_image_guid 5254:00c0:fe12:345b
>
> ### Specific device in detailed mode
> $ rdma dev show mlx5_4 -d
> 5: mlx5_4: node_type ca fw 2.8.9999 node_guid 5254:00c0:fe12:345b sys_image_guid 5254:00c0:fe12:345b
> caps: <BAD_PKEY_CNTR, BAD_QKEY_CNTR, CHANGE_PHY_POR, PORT_ACTIVE_EVENT, SYS_IMAGE_GUID, RC_RNR_NAK_GEN, MEM_WINDOW, UD_IP_CSUM, UD_TSO, XRC, MEM_MGT_EXTENSIONS, BLOCK_MULTICAST_LOOPBACK, MEM_WINDOW_TYPE_2B, RAW_IP_CSUM, MANAGED_FLOW_STEERING, RESIZE_MAX_WR>
>
> ### Unknown command (caps)
> $ rdma dev show mlx5_4 caps
> Unknown parameter 'caps'.
>
> ### Link properties without device name
> $ rdma link
> 1/1: mlx5_0/1: subnet_prefix fe80:0000:0000:0000 lid 13399 sm_lid 49151 lmc 0 state ACTIVE physical_state LINK_UP
> 2/1: mlx5_1/1: subnet_prefix fe80:0000:0000:0000 lid 13400 sm_lid 49151 lmc 0 state ACTIVE physical_state LINK_UP
> 3/1: mlx5_2/1: subnet_prefix fe80:0000:0000:0000 lid 13401 sm_lid 49151 lmc 0 state ACTIVE physical_state LINK_UP
> 4/1: mlx5_3/1: state DOWN physical_state DISABLED
> 5/1: mlx5_4/1: subnet_prefix fe80:0000:0000:0000 lid 13403 sm_lid 49151 lmc 0 state ACTIVE physical_state LINK_UP
>
> ### Link properties in detailed mode
> $ rdma link -d
> 1/1: mlx5_0/1: subnet_prefix fe80:0000:0000:0000 lid 13399 sm_lid 49151 lmc 0 state ACTIVE physical_state LINK_UP
> caps: <AUTO_MIGR>
> 2/1: mlx5_1/1: subnet_prefix fe80:0000:0000:0000 lid 13400 sm_lid 49151 lmc 0 state ACTIVE physical_state LINK_UP
> caps: <AUTO_MIGR>
> 3/1: mlx5_2/1: subnet_prefix fe80:0000:0000:0000 lid 13401 sm_lid 49151 lmc 0 state ACTIVE physical_state LINK_UP
> caps: <AUTO_MIGR>
> 4/1: mlx5_3/1: state DOWN physical_state DISABLED
> caps: <CM, IP_BASED_GIDS>
> 5/1: mlx5_4/1: subnet_prefix fe80:0000:0000:0000 lid 13403 sm_lid 49151 lmc 0 state ACTIVE physical_state LINK_UP
> caps: <AUTO_MIGR>
>
> ### All links for specific device
> $ rdma link show mlx5_3
> 1/1: mlx5_0/1: subnet_prefix fe80:0000:0000:0000 lid 13399 sm_lid 49151 lmc 0 state ACTIVE physical_state LINK_UP
>
> ### Detailed link properties for specific device
> $ rdma link -d show mlx5_3
> 1/1: mlx5_0/1: subnet_prefix fe80:0000:0000:0000 lid 13399 sm_lid 49151 lmc 0 state ACTIVE physical_state LINK_UP
> caps: <AUTO_MIGR>
>
> ### Specific port for specific device
> $ rdma link show mlx5_4/1
> 1/1: mlx5_0/1: subnet_prefix fe80:0000:0000:0000 lid 13399 sm_lid 49151 lmc 0 state ACTIVE physical_state LINK_UP
>
> ### Unknown parameter
> $ rdma link show mlx5_4/1 caps
> Unknown parameter 'caps'.
>
> Thanks
>
> Available in the "topic/rdmatool-netlink-v5" topic branch of this git repo:
> git://git.kernel.org/pub/scm/linux/kernel/git/leon/iproute2.git
>
> Or for browsing:
> https://git.kernel.org/cgit/linux/kernel/git/leon/iproute2.git/log/?h=topic/rdmatool-netlink-v5
>
> Thanks
>
> [1] https://www.spinics.net/lists/linux-rdma/msg49575.html
> [2] https://patchwork.kernel.org/patch/9752865/
> [3] https://www.spinics.net/lists/linux-rdma/msg50827.html
> [4] https://www.spinics.net/lists/linux-rdma/msg51210.html
> [5] https://patchwork.kernel.org/patch/9811729/ and https://patchwork.kernel.org/patch/9811731/]
>
> Cc: Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> Cc: Dennis Dalessandro <dennis.dalessandro-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
> Cc: Jason Gunthorpe <jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
> Cc: Jiri Pirko <jiri-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
> Cc: Ariel Almog <ariela-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
> Cc: David Laight <David.Laight-ZS65k/vG3HxXrIkS9f7CXA@public.gmane.org>
> Cc: Linux Netdev <netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
>
> Leon Romanovsky (8):
> utils: Move BIT macro to common header
> rdma: Add basic infrastructure for RDMA tool
> rdma: Add dev object
> rdma: Add link object
> rdma: Add json and pretty outputs
> rdma: Implement json output for dev object
> rdma: Add json output to link object
> rdma: Add initial manual for the tool
>
> Makefile | 2 +-
> devlink/devlink.c | 2 +-
> include/utils.h | 2 +
> man/man8/rdma-dev.8 | 55 +++++++++
> man/man8/rdma-link.8 | 55 +++++++++
> man/man8/rdma.8 | 102 +++++++++++++++
> rdma/.gitignore | 1 +
> rdma/Makefile | 22 ++++
> rdma/dev.c | 284 ++++++++++++++++++++++++++++++++++++++++++
> rdma/link.c | 343 +++++++++++++++++++++++++++++++++++++++++++++++++++
> rdma/rdma.c | 143 +++++++++++++++++++++
> rdma/rdma.h | 93 ++++++++++++++
> rdma/utils.c | 266 +++++++++++++++++++++++++++++++++++++++
> 13 files changed, 1368 insertions(+), 2 deletions(-)
> create mode 100644 man/man8/rdma-dev.8
> create mode 100644 man/man8/rdma-link.8
> create mode 100644 man/man8/rdma.8
> create mode 100644 rdma/.gitignore
> create mode 100644 rdma/Makefile
> create mode 100644 rdma/dev.c
> create mode 100644 rdma/link.c
> create mode 100644 rdma/rdma.c
> create mode 100644 rdma/rdma.h
> create mode 100644 rdma/utils.c
>
> --
> 2.14.1
>
Wanted to apply this (to net-next), but build fails:
rdma
make[1]: Entering directory '/var/src/iproute2-net-next/rdma'
CC rdma.o
rdma.c: In function ‘rd_init’:
rdma.c:64:21: error: ‘RDMA_NLDEV_CMD_GET’ undeclared (first use in this function)
rd_prepare_msg(rd, RDMA_NLDEV_CMD_GET,
^~~~~~~~~~~~~~~~~~
I think you are depending on some header file that has a more recent version
on your system. Iproute2 has its own include/ directory to deal with this
type of override. Already have headers for kernel and iptables.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH V5 net-next 01/21] net-next/hinic: Initialize hw interface
From: Stephen Hemminger @ 2017-08-18 0:45 UTC (permalink / raw)
To: Aviad Krawczyk
Cc: davem, linux-kernel, netdev, bc.y, victor.gissin, zhaochen6,
tony.qu
In-Reply-To: <544e2ccb65ea083d9b736df6ea0bdd59353da815.1502970631.git.aviad.krawczyk@huawei.com>
On Thu, 17 Aug 2017 19:52:42 +0800
Aviad Krawczyk <aviad.krawczyk@huawei.com> wrote:
> + nic_dev = (struct hinic_dev *)netdev_priv(netdev);
Sinc netdev_priv() returns void *, a cast is not necessary here.
^ permalink raw reply
* Re: [PATCH V5 net-next 01/21] net-next/hinic: Initialize hw interface
From: Stephen Hemminger @ 2017-08-18 0:42 UTC (permalink / raw)
To: Aviad Krawczyk
Cc: davem, linux-kernel, netdev, bc.y, victor.gissin, zhaochen6,
tony.qu
In-Reply-To: <544e2ccb65ea083d9b736df6ea0bdd59353da815.1502970631.git.aviad.krawczyk@huawei.com>
On Thu, 17 Aug 2017 19:52:42 +0800
Aviad Krawczyk <aviad.krawczyk@huawei.com> wrote:
> +
> +/**
> + * init_pfhwdev - Initialize the extended components of PF
> + * @pfhwdev: the HW device for PF
> + *
> + * Return 0 - success, negative - failure
> + **/
> +static int init_pfhwdev(struct hinic_pfhwdev *pfhwdev)
> +{
> + /* Initialize PF HW device extended components */
> + return 0;
> +}
> +
> +/**
> + * free_pfhwdev - Free the extended components of PF
> + * @pfhwdev: the HW device for PF
> + **/
> +static void free_pfhwdev(struct hinic_pfhwdev *pfhwdev)
> +{
> +}
Please drop these functions, they do nothing and are not used
as stubs in any operations table.
^ permalink raw reply
* Re: [PATCH net v2 2/2] net: ixgbe: Use new PCI_DEV_FLAGS_NO_RELAXED_ORDERING flag
From: Ding Tianhong @ 2017-08-18 0:39 UTC (permalink / raw)
To: Tantilov, Emil S, davem@davemloft.net, Kirsher, Jeffrey T,
keescook@chromium.org, linux-kernel@vger.kernel.org,
sparclinux@vger.kernel.org, intel-wired-lan@lists.osuosl.org,
alexander.duyck@gmail.com, netdev@vger.kernel.org,
linuxarm@huawei.com
In-Reply-To: <87618083B2453E4A8714035B62D67992B4094F7A@FMSMSX105.amr.corp.intel.com>
On 2017/8/17 22:17, Tantilov, Emil S wrote:
>> ret_val = ixgbe_start_hw_generic(hw);
>>
>> -#ifndef CONFIG_SPARC
>> - /* Disable relaxed ordering */
>> - for (i = 0; ((i < hw->mac.max_tx_queues) &&
>> - (i < IXGBE_DCA_MAX_QUEUES_82598)); i++) {
>> - regval = IXGBE_READ_REG(hw, IXGBE_DCA_TXCTRL(i));
>> - regval &= ~IXGBE_DCA_TXCTRL_DESC_WRO_EN;
>> - IXGBE_WRITE_REG(hw, IXGBE_DCA_TXCTRL(i), regval);
>> - }
>> + if (!pcie_relaxed_ordering_enabled(adapter->pdev)) {
>
> As Alex mentioned there is no need for this check in any form.
>
> The HW defaults to Relaxed Ordering enabled unless it is disabled in
> the PCIe Device Control Register. So the above logic is already done by HW.
>
> All you have to do is strip the code disabling relaxed ordering.
>
Hi Tantilov:
I misunderstood Alex's suggestion, But I still couldn't find the logic where
the HW disable the Relaxed Ordering when the PCIe Device Control Register
disable it, can you point it out?
Thanks
Ding
> Thanks,
> Emil
>
>
> .
>
^ permalink raw reply
* RE: [PATCH net-next 2/3] vsock: fix vsock_dequeue/enqueue_accept race
From: Dexuan Cui @ 2017-08-18 0:37 UTC (permalink / raw)
To: Jorgen S. Hansen, davem@davemloft.net
Cc: netdev@vger.kernel.org, gregkh@linuxfoundation.org,
devel@linuxdriverproject.org, KY Srinivasan, Haiyang Zhang,
Stephen Hemminger, George Zhang, Michal Kubecek, Stefan Hajnoczi,
Vitaly Kuznetsov, Cathy Avery, jasowang@redhat.com,
Rolf Neugebauer, Dave Scott, Marcelo Cerri, apw@canonical.com,
olaf@aepfle.de, joe@perches.com
In-Reply-To: <E062F976-DF33-46CB-AB17-07F014AE138A@vmware.com>
> > On Aug 16, 2017, at 12:15 AM, Dexuan Cui <decui@microsoft.com> wrote:
> > With the current code, when vsock_dequeue_accept() is removing a sock
> > from the list, nothing prevents vsock_enqueue_accept() from adding a new
> > sock into the list concurrently. We should add a lock to protect the list.
>
> For the VMCI socket transport, we always lock the sockets before calling into
> vsock_enqueue_accept and af_vsock.c locks the socket before calling
> vsock_dequeue_accept, so from our point of view these operations are already
> protected, but with finer granularity than a single global lock. As far as I can see,
> the virtio transport also locks the socket before calling vsock_enqueue_accept,
> so they should be fine with the current version as well, but Stefan can comment
> on that.
>
> Jorgen
Hi Jorgen,
Thanks, you're correct.
Please ignore this patch. I'll update the hv_sock driver to add proper
lock_sock()/relesae_sock().
Thanks,
-- Dexuan
^ permalink raw reply
* Re: [PATCH net-next v1 05/14] amd-xgbe: Add additional debugfs support
From: Andrew Lunn @ 2017-08-18 0:30 UTC (permalink / raw)
To: Tom Lendacky; +Cc: netdev, David Miller
In-Reply-To: <20170818000250.10005.87855.stgit@tlendack-t1.amdoffice.net>
On Thu, Aug 17, 2017 at 07:02:50PM -0500, Tom Lendacky wrote:
> Add additional debugfs support for reading / writing registers of any
> attached external phy devices as well as the SFP eeprom data.
Hi Tom
What is wrong with using the standard APIs for this?
ethtool --moduile-info
ioctls SIOCGMIIREG and SIOCSMIIREG.
Andrew
^ permalink raw reply
* [PATCH] rtlwifi: btcoex: 23b 1ant: fix duplicated code for different branches
From: Gustavo A. R. Silva @ 2017-08-18 0:22 UTC (permalink / raw)
To: Larry Finger, Chaoming Li, Kalle Valo
Cc: linux-wireless, netdev, linux-kernel, Gustavo A. R. Silva
Refactor code in order to avoid identical code for different branches.
This issue was detected with the help of Coccinelle.
Addresses-Coverity-ID: 1415177
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
---
This issue was reported by Coverity and it was tested by compilation only.
.../net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b1ant.c | 10 ++--------
1 file changed, 2 insertions(+), 8 deletions(-)
diff --git a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b1ant.c b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b1ant.c
index 03998d2..c044252 100644
--- a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b1ant.c
+++ b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b1ant.c
@@ -600,14 +600,8 @@ static void halbtc8723b1ant_coex_table_with_type(struct btc_coexist *btcoexist,
0xffffff, 0x3);
break;
case 5:
- if ((coex_sta->cck_ever_lock) && (coex_sta->scan_ap_num <= 5))
- halbtc8723b1ant_coex_table(btcoexist, force_exec,
- 0x5a5a5a5a, 0x5aaa5a5a,
- 0xffffff, 0x3);
- else
- halbtc8723b1ant_coex_table(btcoexist, force_exec,
- 0x5a5a5a5a, 0x5aaa5a5a,
- 0xffffff, 0x3);
+ halbtc8723b1ant_coex_table(btcoexist, force_exec, 0x5a5a5a5a,
+ 0x5aaa5a5a, 0xffffff, 0x3);
break;
case 6:
halbtc8723b1ant_coex_table(btcoexist, force_exec, 0x55555555,
--
2.5.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox