* [PATCH 2/4] Documentation: e1000: Use correct heading adornment
From: Tobin C. Harding @ 2018-06-22 0:37 UTC (permalink / raw)
To: Jonathan Corbet
Cc: Tobin C. Harding, Jeff Kirsher, David S. Miller, linux-doc,
netdev, linux-kernel
In-Reply-To: <20180622003708.31848-1-me@tobin.cc>
Recently documentation file was converted to rst. The document title
has the incorrect heading adornment. From kernel docs:
* Please stick to this order of heading adornments:
1. ``=`` with overline for document title::
==============
Document title
==============
Add overline heading adornment to document title.
Fixes commit (228046e76189 Documentation: e1000: Update kernel documentation)
CC: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: Tobin C. Harding <me@tobin.cc>
---
Documentation/networking/e1000.rst | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/networking/e1000.rst b/Documentation/networking/e1000.rst
index 616848940e63..55f28e5043b6 100644
--- a/Documentation/networking/e1000.rst
+++ b/Documentation/networking/e1000.rst
@@ -1,3 +1,4 @@
+===========================================================
Linux* Base Driver for Intel(R) Ethernet Network Connection
===========================================================
--
2.17.1
^ permalink raw reply related
* [PATCH 3/4] Documentation: e100: Fix docs build error
From: Tobin C. Harding @ 2018-06-22 0:37 UTC (permalink / raw)
To: Jonathan Corbet
Cc: Tobin C. Harding, Jeff Kirsher, David S. Miller, linux-doc,
netdev, linux-kernel
In-Reply-To: <20180622003708.31848-1-me@tobin.cc>
Recent patch updated e100 docs to rst format. Docs build (`make
htmldocs`) is currently failing due to this file with error:
(SEVERE/4) Unexpected section title.
This is because a section of the file is indented 2 spaces. Build error
can be cleared by aligning the text with column 0. While we are changing
these lines we can make sure line length does not exceed 72, that
newlines following headings are uniform, and that full stops are
followed by two spaces.
Align text with column 0, limit line length to 72, ensure two spaces
follow all full stops, ensure uniform use of newlines after heading.
Fixes commit (85d63445f411 Documentation: e100: Update the Intel 10/100 driver doc)
CC: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: Tobin C. Harding <me@tobin.cc>
---
Documentation/networking/e100.rst | 115 +++++++++++++++---------------
1 file changed, 58 insertions(+), 57 deletions(-)
diff --git a/Documentation/networking/e100.rst b/Documentation/networking/e100.rst
index 59b80608e27d..9708f5fa76de 100644
--- a/Documentation/networking/e100.rst
+++ b/Documentation/networking/e100.rst
@@ -87,83 +87,84 @@ Event Log Message Level: The driver uses the message level flag to log events
Additional Configurations
=========================
- Configuring the Driver on Different Distributions
- -------------------------------------------------
-
- Configuring a network driver to load properly when the system is started is
- distribution dependent. Typically, the configuration process involves adding
- an alias line to /etc/modprobe.d/*.conf as well as editing other system
- startup scripts and/or configuration files. Many popular Linux
- distributions ship with tools to make these changes for you. To learn the
- proper way to configure a network device for your system, refer to your
- distribution documentation. If during this process you are asked for the
- driver or module name, the name for the Linux Base Driver for the Intel
- PRO/100 Family of Adapters is e100.
-
- As an example, if you install the e100 driver for two PRO/100 adapters
- (eth0 and eth1), add the following to a configuration file in /etc/modprobe.d/
+Configuring the Driver on Different Distributions
+-------------------------------------------------
+
+Configuring a network driver to load properly when the system is started
+is distribution dependent. Typically, the configuration process involves
+adding an alias line to /etc/modprobe.d/*.conf as well as editing other
+system startup scripts and/or configuration files. Many popular Linux
+distributions ship with tools to make these changes for you. To learn
+the proper way to configure a network device for your system, refer to
+your distribution documentation. If during this process you are asked
+for the driver or module name, the name for the Linux Base Driver for
+the Intel PRO/100 Family of Adapters is e100.
+
+As an example, if you install the e100 driver for two PRO/100 adapters
+(eth0 and eth1), add the following to a configuration file in
+/etc/modprobe.d/::
alias eth0 e100
alias eth1 e100
- Viewing Link Messages
- ---------------------
- In order to see link messages and other Intel driver information on your
- console, you must set the dmesg level up to six. This can be done by
- entering the following on the command line before loading the e100 driver::
+Viewing Link Messages
+---------------------
- dmesg -n 6
-
- If you wish to see all messages issued by the driver, including debug
- messages, set the dmesg level to eight.
+In order to see link messages and other Intel driver information on your
+console, you must set the dmesg level up to six. This can be done by
+entering the following on the command line before loading the e100
+driver::
- NOTE: This setting is not saved across reboots.
+ dmesg -n 6
+If you wish to see all messages issued by the driver, including debug
+messages, set the dmesg level to eight.
- ethtool
- -------
+NOTE: This setting is not saved across reboots.
- The driver utilizes the ethtool interface for driver configuration and
- diagnostics, as well as displaying statistical information. The ethtool
- version 1.6 or later is required for this functionality.
+ethtool
+-------
- The latest release of ethtool can be found from
- https://www.kernel.org/pub/software/network/ethtool/
+The driver utilizes the ethtool interface for driver configuration and
+diagnostics, as well as displaying statistical information. The ethtool
+version 1.6 or later is required for this functionality.
- Enabling Wake on LAN* (WoL)
- ---------------------------
- WoL is provided through the ethtool* utility. For instructions on enabling
- WoL with ethtool, refer to the ethtool man page.
+The latest release of ethtool can be found from
+https://www.kernel.org/pub/software/network/ethtool/
- WoL will be enabled on the system during the next shut down or reboot. For
- this driver version, in order to enable WoL, the e100 driver must be
- loaded when shutting down or rebooting the system.
+Enabling Wake on LAN* (WoL)
+---------------------------
+WoL is provided through the ethtool* utility. For instructions on
+enabling WoL with ethtool, refer to the ethtool man page. WoL will be
+enabled on the system during the next shut down or reboot. For this
+driver version, in order to enable WoL, the e100 driver must be loaded
+when shutting down or rebooting the system.
- NAPI
- ----
+NAPI
+----
- NAPI (Rx polling mode) is supported in the e100 driver.
+NAPI (Rx polling mode) is supported in the e100 driver.
- See https://wiki.linuxfoundation.org/networking/napi for more information
- on NAPI.
+See https://wiki.linuxfoundation.org/networking/napi for more
+information on NAPI.
- Multiple Interfaces on Same Ethernet Broadcast Network
- ------------------------------------------------------
+Multiple Interfaces on Same Ethernet Broadcast Network
+------------------------------------------------------
- Due to the default ARP behavior on Linux, it is not possible to have
- one system on two IP networks in the same Ethernet broadcast domain
- (non-partitioned switch) behave as expected. All Ethernet interfaces
- will respond to IP traffic for any IP address assigned to the system.
- This results in unbalanced receive traffic.
+Due to the default ARP behavior on Linux, it is not possible to have one
+system on two IP networks in the same Ethernet broadcast domain
+(non-partitioned switch) behave as expected. All Ethernet interfaces
+will respond to IP traffic for any IP address assigned to the system.
+This results in unbalanced receive traffic.
- If you have multiple interfaces in a server, either turn on ARP
- filtering by
+If you have multiple interfaces in a server, either turn on ARP
+filtering by
- (1) entering:: echo 1 > /proc/sys/net/ipv4/conf/all/arp_filter
- (this only works if your kernel's version is higher than 2.4.5), or
+(1) entering:: echo 1 > /proc/sys/net/ipv4/conf/all/arp_filter
+ (this only works if your kernel's version is higher than 2.4.5), or
- (2) installing the interfaces in separate broadcast domains (either
- in different switches or in a switch partitioned to VLANs).
+(2) installing the interfaces in separate broadcast domains (either
+ in different switches or in a switch partitioned to VLANs).
Support
--
2.17.1
^ permalink raw reply related
* [PATCH 4/4] Documentation: e1000: Fix docs build error
From: Tobin C. Harding @ 2018-06-22 0:37 UTC (permalink / raw)
To: Jonathan Corbet
Cc: Tobin C. Harding, Jeff Kirsher, David S. Miller, linux-doc,
netdev, linux-kernel
In-Reply-To: <20180622003708.31848-1-me@tobin.cc>
Recent patch updated e1000 docs to rst format. Docs build (`make
htmldocs`) is currently failing due to this file with error:
(SEVERE/4) Unexpected section title.
This is because a section of the file is indented 2 spaces. Build error
can be cleared by aligning the text with column 0. While we are changing
these lines we can make sure line length does not exceed 72, that
newlines following headings are uniform, and that full stops are
followed by two spaces.
Align text with column 0, limit line length to 72, ensure two spaces
follow all full stops, ensure uniform use of newlines after heading.
Fixes commit (228046e76189 Documentation: e1000: Update kernel documentation)
CC: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: Tobin C. Harding <me@tobin.cc>
---
Documentation/networking/e1000.rst | 75 +++++++++++++++---------------
1 file changed, 38 insertions(+), 37 deletions(-)
diff --git a/Documentation/networking/e1000.rst b/Documentation/networking/e1000.rst
index 55f28e5043b6..144b87eef153 100644
--- a/Documentation/networking/e1000.rst
+++ b/Documentation/networking/e1000.rst
@@ -355,57 +355,58 @@ previously mentioned to force the adapter to the same speed and duplex.
Additional Configurations
=========================
- Jumbo Frames
- ------------
- Jumbo Frames support is enabled by changing the MTU to a value larger than
- the default of 1500. Use the ifconfig command to increase the MTU size.
- For example::
+Jumbo Frames
+------------
+Jumbo Frames support is enabled by changing the MTU to a value larger
+than the default of 1500. Use the ifconfig command to increase the MTU
+size. For example::
ifconfig eth<x> mtu 9000 up
- This setting is not saved across reboots. It can be made permanent if
- you add::
+This setting is not saved across reboots. It can be made permanent if
+you add::
MTU=9000
- to the file /etc/sysconfig/network-scripts/ifcfg-eth<x>. This example
- applies to the Red Hat distributions; other distributions may store this
- setting in a different location.
+to the file /etc/sysconfig/network-scripts/ifcfg-eth<x>. This example
+applies to the Red Hat distributions; other distributions may store this
+setting in a different location.
- Notes:
- Degradation in throughput performance may be observed in some Jumbo frames
- environments. If this is observed, increasing the application's socket buffer
- size and/or increasing the /proc/sys/net/ipv4/tcp_*mem entry values may help.
- See the specific application manual and /usr/src/linux*/Documentation/
- networking/ip-sysctl.txt for more details.
+Notes: Degradation in throughput performance may be observed in some
+Jumbo frames environments. If this is observed, increasing the
+application's socket buffer size and/or increasing the
+/proc/sys/net/ipv4/tcp_*mem entry values may help. See the specific
+application manual and /usr/src/linux*/Documentation/
+networking/ip-sysctl.txt for more details.
- - The maximum MTU setting for Jumbo Frames is 16110. This value coincides
- with the maximum Jumbo Frames size of 16128.
+- The maximum MTU setting for Jumbo Frames is 16110. This value
+ coincides with the maximum Jumbo Frames size of 16128.
- - Using Jumbo frames at 10 or 100 Mbps is not supported and may result in
- poor performance or loss of link.
+- Using Jumbo frames at 10 or 100 Mbps is not supported and may result
+ in poor performance or loss of link.
- - Adapters based on the Intel(R) 82542 and 82573V/E controller do not
- support Jumbo Frames. These correspond to the following product names:
- Intel(R) PRO/1000 Gigabit Server Adapter
- Intel(R) PRO/1000 PM Network Connection
+- Adapters based on the Intel(R) 82542 and 82573V/E controller do not
+ support Jumbo Frames. These correspond to the following product names:
+ Intel(R) PRO/1000 Gigabit Server Adapter Intel(R) PRO/1000 PM Network
+ Connection
- ethtool
- -------
- The driver utilizes the ethtool interface for driver configuration and
- diagnostics, as well as displaying statistical information. The ethtool
- version 1.6 or later is required for this functionality.
+ethtool
+-------
+The driver utilizes the ethtool interface for driver configuration and
+diagnostics, as well as displaying statistical information. The ethtool
+version 1.6 or later is required for this functionality.
+
+The latest release of ethtool can be found from
+https://www.kernel.org/pub/software/network/ethtool/
- The latest release of ethtool can be found from
- https://www.kernel.org/pub/software/network/ethtool/
+Enabling Wake on LAN* (WoL)
+---------------------------
+WoL is configured through the ethtool* utility.
- Enabling Wake on LAN* (WoL)
- ---------------------------
- WoL is configured through the ethtool* utility.
+WoL will be enabled on the system during the next shut down or reboot.
+For this driver version, in order to enable WoL, the e1000 driver must be
+loaded when shutting down or rebooting the system.
- WoL will be enabled on the system during the next shut down or reboot.
- For this driver version, in order to enable WoL, the e1000 driver must be
- loaded when shutting down or rebooting the system.
Support
=======
--
2.17.1
^ permalink raw reply related
* Re: [PATCH bpf-next 2/3] bpf: btf: add btf json print functionality
From: Martin KaFai Lau @ 2018-06-22 1:20 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Okash Khawaja, Daniel Borkmann, Alexei Starovoitov, Yonghong Song,
Quentin Monnet, David S. Miller, netdev, kernel-team,
linux-kernel
In-Reply-To: <20180621172523.6cd00ed1@cakuba.netronome.com>
On Thu, Jun 21, 2018 at 05:25:23PM -0700, Jakub Kicinski wrote:
> On Thu, 21 Jun 2018 16:58:15 -0700, Martin KaFai Lau wrote:
> > On Thu, Jun 21, 2018 at 04:07:19PM -0700, Jakub Kicinski wrote:
> > > On Thu, 21 Jun 2018 15:51:17 -0700, Martin KaFai Lau wrote:
> > > > On Thu, Jun 21, 2018 at 02:59:35PM -0700, Jakub Kicinski wrote:
> > > > > On Wed, 20 Jun 2018 13:30:53 -0700, Okash Khawaja wrote:
> > > > > > $ sudo bpftool map dump -p id 14
> > > > > > [{
> > > > > > "key": 0
> > > > > > },{
> > > > > > "value": {
> > > > > > "m": 1,
> > > > > > "n": 2,
> > > > > > "o": "c",
> > > > > > "p": [15,16,17,18,15,16,17,18
> > > > > > ],
> > > > > > "q": [[25,26,27,28,25,26,27,28
> > > > > > ],[35,36,37,38,35,36,37,38
> > > > > > ],[45,46,47,48,45,46,47,48
> > > > > > ],[55,56,57,58,55,56,57,58
> > > > > > ]
> > > > > > ],
> > > > > > "r": 1,
> > > > > > "s": 0x7ffff6f70568,
> > > > > > "t": {
> > > > > > "x": 5,
> > > > > > "y": 10
> > > > > > },
> > > > > > "u": 100,
> > > > > > "v": 20,
> > > > > > "w1": 0x7,
> > > > > > "w2": 0x3
> > > > > > }
> > > > > > }
> > > > > > ]
> > > > >
> > > > > I don't think this format is okay, JSON output is an API you shouldn't
> > > > > break. You can change the non-JSON output whatever way you like, but
> > > > > JSON must remain backwards compatible.
> > > > >
> > > > > The dump today has object per entry, e.g.:
> > > > >
> > > > > {
> > > > > "key":["0x00","0x00","0x00","0x00",
> > > > > ],
> > > > > "value": ["0x02","0x00","0x00","0x00","0x00","0x00","0x00","0x00"
> > > > > ]
> > > > > }
> > > > >
> > > > > This format must remain, you may only augment it with new fields. E.g.:
> > > > >
> > > > > {
> > > > > "key":["0x00","0x00","0x00","0x00",
> > > > > ],
> > > > > "key_struct":{
> > > > > "index":0
> > > > > },
Got a few questions.
When we support hashtab later, the key could be int
but reusing the name as "index" is weird.
The key could also be a struct (e.g. a struct to describe ip:port).
Can you suggest how the "key_struct" will look like?
> > > > > "value": ["0x02","0x00","0x00","0x00","0x00","0x00","0x00","0x00"
> > > > > ],
> > > > > "value_struct":{
> > > > > "src_ip":2,
If for the same map the user changes the "src_ip" to an array of int[4]
later (e.g. to support ipv6), it will become "src_ip": [1, 2, 3, 4].
Is it breaking backward compat?
i.e.
struct five_tuples {
- int src_ip;
+ int src_ip[4];
/* ... */
};
> > > > > "dst_ip:0
> > > > > }
> > > > > }
> > > > I am not sure how useful to have both "key|value" and "(key|value)_struct"
> > > > while most people would prefer "key_struct"/"value_struct" if it is
> > > > available.
> > >
> > > Agreed, it's not that useful, especially with the string-hex debacle :(
> > > It's just about the backwards compat.
> > >
> > > > How about introducing a new option, like "-b", to print the
> > > > map with BTF (if available) such that it won't break the existing
> > > > one (-j or -p) while the "-b" output can keep using the "key"
> > > > and "value".
> > > >
> > > > The existing json can be kept as is.
> > >
> > > That was my knee jerk reaction too, but on reflection it doesn't sound
> > > that great. We expect people with new-enough bpftool to use btf, so it
> > > should be available in the default output, without hiding it behind a
> > > switch. We could add a switch to hide the old output, but that doesn't
> > > give us back the names... What about Key and Value or k and v? Or
> > > key_fields and value_fields?
> > I thought the current default output is "plain" ;)
> > Having said that, yes, the btf is currently printed in json.
> >
> > Ideally, the default json output should do what most people want:
> > print btf and btf only (if it is available).
> > but I don't see a way out without new option if we need to
> > be backward compat :(
> >
> > Agree that showing the btf in the existing json output will be useful (e.g.
> > to hint people that BTF is available). If btf is showing in old json,
> > also agree that the names should be the same with the new json.
> > key_fields and value_fields may hint it has >1 fields though.
> > May be "formatted_key" and "formatted_value"?
>
> SGTM! Or even maybe as a "formatted" object?:
>
> {
> "key":["0x00","0x00","0x00","0x00",
> ],
> "value": ["0x02","0x00","0x00","0x00","0x00","0x00","0x00","0x00"
> ],
> "formatted":{
> "key":{
> "index":0
> },
> "value":{
> "src_ip":2,
> "dst_ip:0
> }
> }
hmm... that is an extra indentation (keep in mind that the "value" could
already have a few nested structs which itself consumes a few indentations)
but I guess adding another one may be ok-ish.
> }
>
> > > > > The name XYZ_struct may not be the best, perhaps you can come up with a
> > > > > better one?
> > > > >
> > > > > Does that make sense? Am I missing what you're doing here?
> > > > >
> > > > > One process note - please make sure you run checkpatch.pl --strict on
> > > > > bpftool patches before posting.
> > > > >
> > > > > Thanks for working on this!
>
^ permalink raw reply
* Re: [virtio-dev] Re: [Qemu-devel] [PATCH] qemu: Introduce VIRTIO_NET_F_STANDBY feature bit to virtio_net
From: Siwei Liu @ 2018-06-22 1:21 UTC (permalink / raw)
To: Cornelia Huck
Cc: Alexander Duyck, virtio-dev, Jiri Pirko, Michael S. Tsirkin,
Jakub Kicinski, Samudrala, Sridhar, konrad.wilk, qemu-devel,
virtualization, Venu Busireddy, Netdev, boris.ostrovsky,
aaron.f.brown, Joao Martins
In-Reply-To: <20180621165913.7e3f4faa.cohuck@redhat.com>
On Thu, Jun 21, 2018 at 7:59 AM, Cornelia Huck <cohuck@redhat.com> wrote:
> On Wed, 20 Jun 2018 22:48:58 +0300
> "Michael S. Tsirkin" <mst@redhat.com> wrote:
>
>> On Wed, Jun 20, 2018 at 06:06:19PM +0200, Cornelia Huck wrote:
>> > In any case, I'm not sure anymore why we'd want the extra uuid.
>>
>> It's mostly so we can have e.g. multiple devices with same MAC
>> (which some people seem to want in order to then use
>> then with different containers).
>>
>> But it is also handy for when you assign a PF, since then you
>> can't set the MAC.
>>
>
> OK, so what about the following:
>
> - introduce a new feature bit, VIRTIO_NET_F_STANDBY_UUID that indicates
> that we have a new uuid field in the virtio-net config space
> - in QEMU, add a property for virtio-net that allows to specify a uuid,
> offer VIRTIO_NET_F_STANDBY_UUID if set
> - when configuring, set the property to the group UUID of the vfio-pci
> device
If feature negotiation fails on VIRTIO_NET_F_STANDBY_UUID, is it safe
to still expose UUID in the config space on virtio-pci?
I'm not even sure if it's sane to expose group UUID on the PCI bridge
where the corresponding vfio-pci device attached to for a guest which
doesn't support the feature (legacy).
-Siwei
> - in the guest, use the uuid from the virtio-net device's config space
> if applicable; else, fall back to matching by MAC as done today
>
> That should work for all virtio transports.
^ permalink raw reply
* Re:
From: VIC J @ 2018-06-22 1:51 UTC (permalink / raw)
--
I'm soliciting your cooperation in a very important transaction
business that will benefit you and i, please i need your trust reply
for more details.
Kind regards.
^ permalink raw reply
* Re: [PATCH net V2 1/1] net/smc: coordinate wait queues for nonblocking connect
From: Cong Wang @ 2018-06-22 2:12 UTC (permalink / raw)
To: Ursula Braun
Cc: David Miller, Linux Kernel Network Developers, linux-s390,
schwidefsky, Heiko Carstens, raspl, Christoph Hellwig
In-Reply-To: <20180621142318.72681-1-ubraun@linux.ibm.com>
On Thu, Jun 21, 2018 at 7:23 AM, Ursula Braun <ubraun@linux.ibm.com> wrote:
> @@ -605,6 +606,13 @@ static int smc_connect(struct socket *sock, struct sockaddr *addr,
>
> smc_copy_sock_settings_to_clc(smc);
> tcp_sk(smc->clcsock->sk)->syn_smc = 1;
> + if (flags & O_NONBLOCK) {
> + rcu_read_lock();
> + smc->smcwq = rcu_dereference(sk->sk_wq);
> + rcu_assign_pointer(sock->sk->sk_wq,
> + rcu_dereference(smc->clcsock->sk->sk_wq));
> + rcu_read_unlock();
Are you really deref'ing any RCU pointer here?
^ permalink raw reply
* Re: Re: [Qemu-devel] [PATCH] qemu: Introduce VIRTIO_NET_F_STANDBY feature bit to virtio_net
From: Venu Busireddy @ 2018-06-22 2:25 UTC (permalink / raw)
To: Siwei Liu
Cc: Cornelia Huck, Michael S. Tsirkin, Samudrala, Sridhar,
Alexander Duyck, virtio-dev, aaron.f.brown, Jiri Pirko,
Jakub Kicinski, Netdev, qemu-devel, virtualization, konrad.wilk,
boris.ostrovsky, Joao Martins, vijay.balakrishna
In-Reply-To: <CADGSJ22B39JiS14L0yCYQ720-fZcwyUt1wCX1YO-6Y9FhmDKZg@mail.gmail.com>
On 2018-06-21 18:21:55 -0700, Siwei Liu wrote:
> On Thu, Jun 21, 2018 at 7:59 AM, Cornelia Huck <cohuck@redhat.com> wrote:
> > On Wed, 20 Jun 2018 22:48:58 +0300
> > "Michael S. Tsirkin" <mst@redhat.com> wrote:
> >
> >> On Wed, Jun 20, 2018 at 06:06:19PM +0200, Cornelia Huck wrote:
> >> > In any case, I'm not sure anymore why we'd want the extra uuid.
> >>
> >> It's mostly so we can have e.g. multiple devices with same MAC
> >> (which some people seem to want in order to then use
> >> then with different containers).
> >>
> >> But it is also handy for when you assign a PF, since then you
> >> can't set the MAC.
> >>
> >
> > OK, so what about the following:
> >
> > - introduce a new feature bit, VIRTIO_NET_F_STANDBY_UUID that indicates
> > that we have a new uuid field in the virtio-net config space
> > - in QEMU, add a property for virtio-net that allows to specify a uuid,
> > offer VIRTIO_NET_F_STANDBY_UUID if set
> > - when configuring, set the property to the group UUID of the vfio-pci
> > device
>
> If feature negotiation fails on VIRTIO_NET_F_STANDBY_UUID, is it safe
> to still expose UUID in the config space on virtio-pci?
Why is it not safe? When we expose VIRTIO_NET_F_STANDBY_UUID, it is up
to the driver to decide if it wants to use it or not. If it does not
want to use the feature, it would also imply that the driver will not
be interested in the UUID value in the config space. So, the UUID will
be some piece of data that simply sits around; nobody cares for it.
> I'm not even sure if it's sane to expose group UUID on the PCI bridge
> where the corresponding vfio-pci device attached to for a guest which
> doesn't support the feature (legacy).
Unfortunately, you don't know beforehand if the guest will be a legacy
guest that doesn't support the feature. As is the case with the UUID in
the virtio-pci device's config space, the UUID in the bridge's config
space will/should be ignored by the legacy guest.
Venu
> > - in the guest, use the uuid from the virtio-net device's config space
> > if applicable; else, fall back to matching by MAC as done today
> >
> > That should work for all virtio transports.
^ permalink raw reply
* Re: [virtio-dev] Re: [Qemu-devel] [PATCH] qemu: Introduce VIRTIO_NET_F_STANDBY feature bit to virtio_net
From: Michael S. Tsirkin @ 2018-06-22 2:32 UTC (permalink / raw)
To: Siwei Liu
Cc: Cornelia Huck, Samudrala, Sridhar, Alexander Duyck, virtio-dev,
aaron.f.brown, Jiri Pirko, Jakub Kicinski, Netdev, qemu-devel,
virtualization, konrad.wilk, boris.ostrovsky, Joao Martins,
Venu Busireddy, vijay.balakrishna
In-Reply-To: <CADGSJ22B39JiS14L0yCYQ720-fZcwyUt1wCX1YO-6Y9FhmDKZg@mail.gmail.com>
On Thu, Jun 21, 2018 at 06:21:55PM -0700, Siwei Liu wrote:
> On Thu, Jun 21, 2018 at 7:59 AM, Cornelia Huck <cohuck@redhat.com> wrote:
> > On Wed, 20 Jun 2018 22:48:58 +0300
> > "Michael S. Tsirkin" <mst@redhat.com> wrote:
> >
> >> On Wed, Jun 20, 2018 at 06:06:19PM +0200, Cornelia Huck wrote:
> >> > In any case, I'm not sure anymore why we'd want the extra uuid.
> >>
> >> It's mostly so we can have e.g. multiple devices with same MAC
> >> (which some people seem to want in order to then use
> >> then with different containers).
> >>
> >> But it is also handy for when you assign a PF, since then you
> >> can't set the MAC.
> >>
> >
> > OK, so what about the following:
> >
> > - introduce a new feature bit, VIRTIO_NET_F_STANDBY_UUID that indicates
> > that we have a new uuid field in the virtio-net config space
> > - in QEMU, add a property for virtio-net that allows to specify a uuid,
> > offer VIRTIO_NET_F_STANDBY_UUID if set
> > - when configuring, set the property to the group UUID of the vfio-pci
> > device
>
> If feature negotiation fails on VIRTIO_NET_F_STANDBY_UUID, is it safe
> to still expose UUID in the config space on virtio-pci?
Yes but guest is not supposed to read it.
> I'm not even sure if it's sane to expose group UUID on the PCI bridge
> where the corresponding vfio-pci device attached to for a guest which
> doesn't support the feature (legacy).
>
> -Siwei
Yes but you won't add the primary behind such a bridge.
>
> > - in the guest, use the uuid from the virtio-net device's config space
> > if applicable; else, fall back to matching by MAC as done today
> >
> > That should work for all virtio transports.
^ permalink raw reply
* Re: [PATCH net] net: sungem: fix rx checksum support
From: Eric Dumazet @ 2018-06-22 4:20 UTC (permalink / raw)
To: David Miller, edumazet; +Cc: netdev, mroos, malat, schwab, eric.dumazet
In-Reply-To: <20180620.143050.313454768369559179.davem@davemloft.net>
On 06/19/2018 10:30 PM, David Miller wrote:
> Tested-by: Andreas Schwab <schwab@linux-m68k.org>
>
> Applied and queued up for -stable, thanks Eric.
>
BTW, removing the FCS also means GRO is going to work, finally on this NIC ;)
GRO does not like packets with padding.
^ permalink raw reply
* Re: [PATCH 0/7] Assorted rhashtables cleanups.
From: David Miller @ 2018-06-22 4:43 UTC (permalink / raw)
To: neilb; +Cc: tgraf, herbert, netdev, linux-kernel
In-Reply-To: <152929034948.23173.8671757672560065344.stgit@noble>
From: NeilBrown <neilb@suse.com>
Date: Mon, 18 Jun 2018 12:52:50 +1000
> Following 7 patches are selections from a recent RFC series I posted
> that have all received suitable Acks.
>
> The most visible changes are that rhashtable-types.h is now preferred
> for inclusion in include/linux/*.h rather than rhashtable.h, and
> that the full hash is used - no bits a reserved for a NULLS pointer.
Series applied to net-next, thanks Neil.
^ permalink raw reply
* Re: [PATCH net-next] tcp: ignore rcv_rtt sample with old ts ecr value
From: David Miller @ 2018-06-22 4:45 UTC (permalink / raw)
To: weiwan; +Cc: netdev, edumazet, ncardwell
In-Reply-To: <20180620044250.33943-1-tracywwnj@gmail.com>
From: Wei Wang <weiwan@google.com>
Date: Tue, 19 Jun 2018 21:42:50 -0700
> From: Wei Wang <weiwan@google.com>
>
> When receiving multiple packets with the same ts ecr value, only try
> to compute rcv_rtt sample with the earliest received packet.
> This is because the rcv_rtt calculated by later received packets
> could possibly include long idle time or other types of delay.
> For example:
> (1) server sends last packet of reply with TS val V1
> (2) client ACKs last packet of reply with TS ecr V1
> (3) long idle time passes
> (4) client sends next request data packet with TS ecr V1 (again!)
> At this time, the rcv_rtt computed on server with TS ecr V1 will be
> inflated with the idle time and should get ignored.
>
> Signed-off-by: Wei Wang <weiwan@google.com>
> Signed-off-by: Neal Cardwell <ncardwell@google.com>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next 0/2] fixes for ipsec selftests
From: David Miller @ 2018-06-22 4:49 UTC (permalink / raw)
To: shannon.nelson; +Cc: netdev, anders.roxell
In-Reply-To: <1529473363-4036-1-git-send-email-shannon.nelson@oracle.com>
From: Shannon Nelson <shannon.nelson@oracle.com>
Date: Tue, 19 Jun 2018 22:42:41 -0700
> A couple of bad behaviors in the ipsec selftest were pointed out
> by Anders Roxell <anders.roxell@linaro.org> and are addressed here.
>
> Shannon Nelson (2):
> selftests: rtnetlink: hide complaint from terminated monitor
> selftests: rtnetlink: use a local IP address for IPsec tests
Series applied, but I wonder about patch #2.
The idea is that we don't make modifications to the actual system
networking configuration and therefore make changes that can't
possibly disrupt connectivity for the system under test.
Using a configured local IP address seems to subvert that.
^ permalink raw reply
* Re: ISDN: use irqsave() in URB completion + usb_fill_int_urb
From: David Miller @ 2018-06-22 4:54 UTC (permalink / raw)
To: bigeasy; +Cc: netdev, isdn, linux-usb, tglx
In-Reply-To: <20180620104028.18283-1-bigeasy@linutronix.de>
From: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Date: Wed, 20 Jun 2018 12:40:24 +0200
> This series is mostly about using _irqsave() primitives in the
> completion callback in order to get rid of local_irq_save() in
> __usb_hcd_giveback_urb(). While at it, I also tried to move drivers to
> use usb_fill_int_urb() otherwise it is hard find users of a certain API.
Series applied, thanks Sebastian.
^ permalink raw reply
* Re: [PATCH v2] ucc_geth: Add BQL support
From: David Miller @ 2018-06-22 4:56 UTC (permalink / raw)
To: joakim.tjernlund; +Cc: leoyang.li, netdev
In-Reply-To: <20180620162918.3609-1-joakim.tjernlund@infinera.com>
From: Joakim Tjernlund <joakim.tjernlund@infinera.com>
Date: Wed, 20 Jun 2018 18:29:18 +0200
> Signed-off-by: Joakim Tjernlund <joakim.tjernlund@infinera.com>
> ---
>
> v2 - Reoder varibles according to Dave
> Add call to netdev_reset_queue(dev) open/close
Applied.
^ permalink raw reply
* Re: net/usb: Use irqsave in USB's complete callback
From: David Miller @ 2018-06-22 4:58 UTC (permalink / raw)
To: bigeasy; +Cc: netdev, linux-usb, tglx
In-Reply-To: <20180620193121.24967-1-bigeasy@linutronix.de>
From: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Date: Wed, 20 Jun 2018 21:31:16 +0200
> This is about using _irqsave() primitives in the completion callback in
> order to get rid of local_irq_save() in __usb_hcd_giveback_urb().
Series applied.
^ permalink raw reply
* Re: [PATCH net-next] tcp_bbr: fix bbr pacing rate for internal pacing
From: David Miller @ 2018-06-22 5:04 UTC (permalink / raw)
To: yyd; +Cc: netdev, edumazet
In-Reply-To: <20180620200735.82085-1-yyd@google.com>
From: Kevin Yang <yyd@google.com>
Date: Wed, 20 Jun 2018 16:07:35 -0400
> From: Eric Dumazet <edumazet@google.com>
>
> This commit makes BBR use only the MSS (without any headers) to
> calculate pacing rates when internal TCP-layer pacing is used.
>
> This is necessary to achieve the correct pacing behavior in this case,
> since tcp_internal_pacing() uses only the payload length to calculate
> pacing delays.
>
> Signed-off-by: Kevin Yang <yyd@google.com>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Reviewed-by: Neal Cardwell <ncardwell@google.com>
Applied, thank you.
^ permalink raw reply
* bnx2x: kernel panic in the bnx2x driver
From: Vishwanath Pai @ 2018-06-22 5:07 UTC (permalink / raw)
To: ariel.elior, everest-linux-l2; +Cc: davem, netdev, dbanerje, pai.vishwain
Hi,
We recently noticed a kernel panic in the bnx2x driver when trying to set
rx-flow-hash parameters via ethtool during if-pre-up.d. I am running kernel
v4.17.2 from ubuntu-mainline-ppa. I have added the stack trace below:
[ 18.280209] BUG: unable to handle kernel NULL pointer dereference at 0000000000000000
[ 18.280212] PGD 8000000407a79067 P4D 8000000407a79067 PUD 40ce8a067 PMD 0
[ 18.280214] Oops: 0010 [#1] SMP PTI
[ 18.280215] Modules linked in: intel_rapl x86_pkg_temp_thermal intel_powerclamp kvm_intel joydev input_led kvm irqbypass crct10dif_pclmul crc32_pclmul ghash_clmulni_intel pcbc hid_eneric aesni_intel gpio_ich aes_x86_64 usbhid lpc_ich crpto_simd ie31200_edac cryptd glue_helper intel_cstate mac_hid intel_rapl_perf bnx2x mdio tcp_bbr netconsole ipmi_devintf ipmi_msghandler i2c_i801 coretemp autofs4 raid10 raid456 libcrc32c async_raid6_recov async_memcpy async_pq async_xor xor async_tx raid6_pq raid1 raid0 multipath linear sha26_mb mcryptd sha256_ssse3 hid ast i2c_algo_bit ttm drm_kms_helper syscopyarea sysfillrect sysimgblt mpt3sas fb_sys_fops drm raid_class scsi_transport_sas ahci libahci shpchp video
[ 18.280241] CPU: 6 PID: 1081 Comm: ethtool Not tainted 4.17.2-041702-generic #201806160433
[ 18.280242] Hardware name: Foxconn CangJie/CangJie, BIOS CC1F108D 02/26/2014
[ 18.280243] RIP: 0010: (null)
[ 18.280243] RSP: 0018:ffffb84bc260b9c0 EFLAGS: 00010246
[ 18.280244] RAX: 0000000000000000 RBX: ffff92f987f020f0 RCX: 0000000000000000
[ 18.280245] RDX: 0000000000000000 RSI: ffffb84bc260b9f8 RDI: ffff92f987f020f0
[ 18.280245] RBP: ffffb8bc260b9e8 R08: 0000000000000001 R09: 0000000000000000
[ 18.280246] R10: ffffb84bc260bd20 R11: 0000000000000000 R12: ffffb84bc260b9f8
[ 18.280246] R13: ffff92f987f008c0 R14: 00007ffdb75bec40 R15: 0000000000000000
[ 18.280247] FS: 00007fc0e8798700(0000) GS:ffff92f99fd80000(0000) knlGS:0000000000000000
[ 18.280248] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 18.280249] CR2: 0000000000000000 CR3: 0000000409b4c003 CR4: 00000000001606e0
[ 18.280249] Call Trace:
[ 18.280263] ? bnx2x_config_rss+0x2f/0xd0 [bnx2x]
[ 18.280270] bnx2x_rss+0x1d9/0x210 [bnx2x]
[ 18.280276] bnx2x_set_rxnfc+0x17d/0x380 [bnx2x]
[ 18.280279] ethtool_set_rxnfc+0x9b/0x110
[ 18.280281] ? __do_page_cache_readahead+0x1da/0x2c0
[ 18.280283] ? security_capable+0x3c/0x60
[ 18.280284] dev_ethtool+0350/0x2610
[ 18.280286] ? page_cache_async_readahead+0x71/0x80
[ 18.280288] ? page_add_file_rmap+0x5d/0x220
[ 18.280290] ? inet_ioctl+0x182/0x1a0
[ 18.280291] dev_ioctl+0x203/0x3f0
[ 18.280293] ? dev_ioctl+0x203/0x3f0
[ 18.280294] sock_do_ioctl+0xae/0x150
[ 18.280296] sock_ioctl+0x1e2/0x330
[ 18.280296] ? sock_ioctl+0x1e2/0x330
[ 18.280299] do_vfs_ioctl+0xa8/0x620
[ 18.280300] ? dlci_ioctl_set+0x30/0x30
[ 18.280301] ? do_vfs_ioctl+0xa8/0x620
[ 18.280302] ? handle_mm_fault+0xe3/0x220
[ 18.280304] ksys_ioctl+0x75/0x80
[ 18.280305] __x64_sys_ioctl+0x1a/0x20
[ 18.280307] do_syscall_64+0x5a/0x120
[ 18.280309] entry_SYSCALL_64_aftr_hwframe+0x44/0xa9
[ 18.280310] RIP: 0033:0x7fc0e7fba107
[ 18.280311] RSP: 002b:00007ffdb75beb78 EFLAGS: 00000206 ORIG_RAX: 0000000000000010
[ 18.280312] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fc0e7fba107
[ 18.280312] RDX: 00007ffdb75bed60 RSI: 0000000000008946 RDI: 0000000000000003
[ 18.280313] RBP: 00007ffdb75bed50 R08: 00007ffdb75bed60 R09: 0000000000000001
[ 18.280313] R10: 0000000000000541 R11: 0000000000000206 R12: 00007ffdb75beed0
[ 18.280314] R13: 0000000000421020 R14: 000000000041fe28 R15: 0000000000000003
[ 18.280315] Code: Bad RIP value.
[ 18.280317] RIP: (null) RSP: ffffb84bc260b9c0
[ 18.280318] CR2: 0000000000000000
[ 18.280319] ---[ end trace 5f361db3fb9059f1 ]---
To reproduce this I created a bash script in "/etc/network/if-pre-up.d/" with
these two lines:
ethtool -N $IFACE rx-flow-hash udp4 "sdfn"
ethtool -N $IFACE rx-flow-hash udp6 "sdfn"
The problem here is that rss_obj in bnx2x struct for the device hasn't been
initialized yet, which causes an exception in bnx2x_config_rss() when calling
"r->set_pending(r)" because r->set_pending is NULL. It looks like a lot many
things haven't been initialized at this point, most of that happens in this
function: "bnx2x_init_bp_objs()" which isn't called until ifup. Any thoughts on
how this can be fixed? Would it be possible to safely move bnx2x_init_bp_objs()
to maybe bnx2x_init_one() which runs much before ifup?
Thanks,
Vishwanath
^ permalink raw reply
* Re: [PATCH net-next v4 1/2] r8169: Don't disable ASPM in the driver
From: David Miller @ 2018-06-22 5:08 UTC (permalink / raw)
To: kai.heng.feng
Cc: ryankao, hayeswang, hau, hkallweit1, romieu, bhelgaas, acelan.kao,
netdev, linux-pci, linux-kernel
In-Reply-To: <20180621083039.22545-1-kai.heng.feng@canonical.com>
From: Kai-Heng Feng <kai.heng.feng@canonical.com>
Date: Thu, 21 Jun 2018 16:30:38 +0800
> Enable or disable ASPM should be done in PCI core instead of in the
> device driver.
>
> Commit ba04c7c93bbc ("r8169: disable ASPM") uses
> pci_disable_link_state() to disable ASPM, but it's not the best way to
> do it. If the device really wants to disable ASPM, we can use a quirk in
> PCI core to prevent the PCI core from setting ASPM before probe.
>
> Let's remove pci_disable_link_state() for now. Use PCI core quirks if
> any regression happens.
>
> Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next v4 2/2] r8169: Reinstate ASPM Support
From: David Miller @ 2018-06-22 5:08 UTC (permalink / raw)
To: kai.heng.feng
Cc: ryankao, hayeswang, hau, hkallweit1, romieu, bhelgaas, acelan.kao,
netdev, linux-pci, linux-kernel
In-Reply-To: <20180621083039.22545-2-kai.heng.feng@canonical.com>
From: Kai-Heng Feng <kai.heng.feng@canonical.com>
Date: Thu, 21 Jun 2018 16:30:39 +0800
> On Intel platforms (Skylake and newer), ASPM support in r8169 is the
> last missing puzzle to let CPU's Package C-State reaches PC8. Without
> ASPM support, the CPU cannot reach beyond PC3. PC8 can save additional
> ~3W in comparison with PC3 on a Coffee Lake platform, Dell G3 3779.
>
> This is based on the work from Chunhao Lin <hau@realtek.com>.
>
> Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Also applied.
Thank you for being so persistent.
^ permalink raw reply
* Re: KMSAN: uninit-value in ip_vs_lblc_check_expire
From: syzbot @ 2018-06-22 5:52 UTC (permalink / raw)
To: coreteam, davem, fw, horms, ja, kadlec, linux-kernel, lvs-devel,
netdev, netfilter-devel, pablo, syzkaller-bugs, wensong
In-Reply-To: <000000000000c66d94056a84011d@google.com>
syzbot has found a reproducer for the following crash on:
HEAD commit: 123906095e30 kmsan: introduce kmsan_interrupt_enter()/kmsa..
git tree: https://github.com/google/kmsan.git/master
console output: https://syzkaller.appspot.com/x/log.txt?x=134ad890400000
kernel config: https://syzkaller.appspot.com/x/.config?x=848e40757852af3e
dashboard link: https://syzkaller.appspot.com/bug?extid=3e9695f147fb529aa9bc
compiler: clang version 7.0.0 (trunk 334104)
syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=11505218400000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1168a490400000
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+3e9695f147fb529aa9bc@syzkaller.appspotmail.com
==================================================================
BUG: KMSAN: uninit-value in ip_vs_lblc_check_expire+0xe62/0xf10
net/netfilter/ipvs/ip_vs_lblc.c:315
CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.17.0+ #9
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
<IRQ>
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x185/0x1d0 lib/dump_stack.c:113
kmsan_report+0x188/0x2a0 mm/kmsan/kmsan.c:1125
__msan_warning_32+0x70/0xc0 mm/kmsan/kmsan_instr.c:620
ip_vs_lblc_check_expire+0xe62/0xf10 net/netfilter/ipvs/ip_vs_lblc.c:315
call_timer_fn+0x280/0x5d0 kernel/time/timer.c:1326
expire_timers kernel/time/timer.c:1363 [inline]
__run_timers+0xd96/0x11b0 kernel/time/timer.c:1666
run_timer_softirq+0x43/0x70 kernel/time/timer.c:1692
__do_softirq+0x592/0x979 kernel/softirq.c:285
invoke_softirq kernel/softirq.c:365 [inline]
irq_exit+0x202/0x240 kernel/softirq.c:405
exiting_irq+0xe/0x10 arch/x86/include/asm/apic.h:525
smp_apic_timer_interrupt+0x64/0x90 arch/x86/kernel/apic/apic.c:1055
apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:866
</IRQ>
RIP: 0010:native_safe_halt arch/x86/include/asm/irqflags.h:55 [inline]
RIP: 0010:arch_safe_halt arch/x86/include/asm/irqflags.h:97 [inline]
RIP: 0010:default_idle+0x20b/0x3e0 arch/x86/kernel/process.c:500
RSP: 0018:ffff8801d8e5fdf0 EFLAGS: 00000246 ORIG_RAX: ffffffffffffff13
RAX: ffff8801fd432f18 RBX: 0000000000000000 RCX: ffff880000000000
RDX: ffff8801fd032f18 RSI: aaaaaaaaaaaab000 RDI: ffffea0000000000
RBP: ffff8801d8e5fe28 R08: 0000000001080020 R09: 0000000000000002
R10: 00000030de3d75c0 R11: ffffffff89fef830 R12: ffff8801d8e5fe8f
R13: ffff8801d8da57c0 R14: ffff8801d8e5fe8c R15: ffff8801d8da6098
arch_cpu_idle+0x26/0x30 arch/x86/kernel/process.c:491
default_idle_call kernel/sched/idle.c:93 [inline]
cpuidle_idle_call kernel/sched/idle.c:153 [inline]
do_idle+0x36d/0x830 kernel/sched/idle.c:262
cpu_startup_entry+0x45/0x50 kernel/sched/idle.c:368
start_secondary+0x3c6/0x490 arch/x86/kernel/smpboot.c:272
secondary_startup_64+0xa5/0xb0 arch/x86/kernel/head_64.S:242
Uninit was created at:
kmsan_save_stack_with_flags mm/kmsan/kmsan.c:282 [inline]
kmsan_alloc_meta_for_pages+0x161/0x3a0 mm/kmsan/kmsan.c:819
kmsan_alloc_page+0x82/0xe0 mm/kmsan/kmsan.c:889
__alloc_pages_nodemask+0xf7b/0x5cc0 mm/page_alloc.c:4402
alloc_pages_current+0x6b1/0x970 mm/mempolicy.c:2093
alloc_pages include/linux/gfp.h:494 [inline]
kmalloc_order mm/slab_common.c:1148 [inline]
kmalloc_order_trace+0xbb/0x390 mm/slab_common.c:1159
kmalloc_large include/linux/slab.h:446 [inline]
__kmalloc+0x335/0x350 mm/slub.c:3805
kmalloc include/linux/slab.h:517 [inline]
ip_vs_lblc_init_svc+0x57/0x310 net/netfilter/ipvs/ip_vs_lblc.c:355
ip_vs_bind_scheduler+0xa9/0x1f0 net/netfilter/ipvs/ip_vs_sched.c:51
ip_vs_add_service+0xa9d/0x1d90 net/netfilter/ipvs/ip_vs_ctl.c:1265
do_ip_vs_set_ctl+0x2aa9/0x2cd0 net/netfilter/ipvs/ip_vs_ctl.c:2462
nf_sockopt net/netfilter/nf_sockopt.c:106 [inline]
nf_setsockopt+0x47c/0x4e0 net/netfilter/nf_sockopt.c:115
ip_setsockopt+0x24b/0x2b0 net/ipv4/ip_sockglue.c:1251
udp_setsockopt+0x108/0x1b0 net/ipv4/udp.c:2416
ipv6_setsockopt+0x311/0x350 net/ipv6/ipv6_sockglue.c:917
tcp_setsockopt+0x1c0/0x1f0 net/ipv4/tcp.c:2891
sock_common_setsockopt+0x13b/0x170 net/core/sock.c:3039
__sys_setsockopt+0x496/0x540 net/socket.c:1903
__do_sys_setsockopt net/socket.c:1914 [inline]
__se_sys_setsockopt net/socket.c:1911 [inline]
__x64_sys_setsockopt+0x15c/0x1c0 net/socket.c:1911
do_syscall_64+0x15b/0x230 arch/x86/entry/common.c:287
entry_SYSCALL_64_after_hwframe+0x44/0xa9
==================================================================
^ permalink raw reply
* Re: [PATCH net-next 0/2] fixes for ipsec selftests
From: Shannon Nelson @ 2018-06-22 6:50 UTC (permalink / raw)
To: David Miller; +Cc: netdev, anders.roxell
In-Reply-To: <20180622.134913.2049651808540037401.davem@davemloft.net>
On 6/21/2018 9:49 PM, David Miller wrote:
> From: Shannon Nelson <shannon.nelson@oracle.com>
> Date: Tue, 19 Jun 2018 22:42:41 -0700
>
>> A couple of bad behaviors in the ipsec selftest were pointed out
>> by Anders Roxell <anders.roxell@linaro.org> and are addressed here.
>>
>> Shannon Nelson (2):
>> selftests: rtnetlink: hide complaint from terminated monitor
>> selftests: rtnetlink: use a local IP address for IPsec tests
>
> Series applied, but I wonder about patch #2.
>
> The idea is that we don't make modifications to the actual system
> networking configuration and therefore make changes that can't
> possibly disrupt connectivity for the system under test.
>
> Using a configured local IP address seems to subvert that.
Yeah, I'm not so thrilled with it either. I've got a couple more
changes coming Real Soon Now that extend netdevsim and add a couple of
tests for ipsec-hw-offload, so while I finish those up I can change this
again and make use of netdevsim to leave existing devices alone.
For that matter, if you want to cut down on patch thrash, just drop patch 2.
sln
^ permalink raw reply
* Re: [PATCH v2] net: ethernet: stmmac: dwmac-rk: Add GMAC support for PX30
From: David Wu @ 2018-06-22 7:22 UTC (permalink / raw)
To: Heiko Stübner
Cc: davem, robh+dt, mark.rutland, huangtao, netdev, linux-arm-kernel,
linux-rockchip, linux-kernel
In-Reply-To: <2582999.2hZx6CH9S6@diego>
Hi Heiko,
在 2018年06月14日 16:30, Heiko Stübner 写道:
> And someone could convert the driver to use the new clk-bulk APIs [0],
> so the large number of clk_prepare_enable calls would be a bit
> trimmed down.
Some clocks need special treatment at special cases, may not know which
index is we need at clk_bulk_data struct.
1. At rmii mode, need to use mac_ref, mac_refout; but at rgmii, they are
not needed.
2. At rgmii mode, rx is coming in from external source, there is no
gate, and it is coming from mac_ref_clk at rmii mode, there is gate.
3. clk_mac needs to be configured rate 50M or 125M.
4. mac_clk_speed needs to be configured at PX30 Soc and next Socs.
It looks like use the clk-bulk, will not be more flexible, and we still
keep the present. What do you think?
^ permalink raw reply
* Re: [PATCH net-next 0/2] fixes for ipsec selftests
From: David Miller @ 2018-06-22 7:27 UTC (permalink / raw)
To: shannon.nelson; +Cc: netdev, anders.roxell
In-Reply-To: <20059528-5d1d-cb7c-26f8-f9055bd807c2@oracle.com>
From: Shannon Nelson <shannon.nelson@oracle.com>
Date: Thu, 21 Jun 2018 23:50:36 -0700
> For that matter, if you want to cut down on patch thrash, just drop
> patch 2.
Too late, already in my tree :)
Don't worry about it for now.
^ permalink raw reply
* Re: [PATCH v2] net: ethernet: stmmac: dwmac-rk: Add GMAC support for PX30
From: Heiko Stuebner @ 2018-06-22 7:28 UTC (permalink / raw)
To: David Wu
Cc: davem, robh+dt, mark.rutland, huangtao, netdev, linux-arm-kernel,
linux-rockchip, linux-kernel
In-Reply-To: <7173b45f-17d3-2356-fede-28bdd5c658f2@rock-chips.com>
Hi David,
Am Freitag, 22. Juni 2018, 09:22:35 CEST schrieb David Wu:
> 在 2018年06月14日 16:30, Heiko Stübner 写道:
> > And someone could convert the driver to use the new clk-bulk APIs [0],
> > so the large number of clk_prepare_enable calls would be a bit
> > trimmed down.
>
> Some clocks need special treatment at special cases, may not know which
> index is we need at clk_bulk_data struct.
> 1. At rmii mode, need to use mac_ref, mac_refout; but at rgmii, they are
> not needed.
> 2. At rgmii mode, rx is coming in from external source, there is no
> gate, and it is coming from mac_ref_clk at rmii mode, there is gate.
> 3. clk_mac needs to be configured rate 50M or 125M.
> 4. mac_clk_speed needs to be configured at PX30 Soc and next Socs.
>
> It looks like use the clk-bulk, will not be more flexible, and we still
> keep the present. What do you think?
yeah, you're probably right. I just saw all these clk_prepare_enable calls
and didn't think enough about the config side ;-) .
Heiko
^ 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