* Re: [Qemu-devel] TCP performance problems - GSO/TSO, MSS, 8139cp related
From: Stefan Hajnoczi @ 2016-11-14 16:25 UTC (permalink / raw)
To: Russell King - ARM Linux, David Woodhouse
Cc: jasowang, vyasevic, stefanha, netdev, qemu-devel,
igor.v.kovalenko, dgilbert
In-Reply-To: <20161114092947.GB2031@work-vm>
[-- Attachment #1: Type: text/plain, Size: 3792 bytes --]
On Mon, Nov 14, 2016 at 09:29:48AM +0000, Dr. David Alan Gilbert wrote:
> * Russell King - ARM Linux (linux@armlinux.org.uk) wrote:
> > On Fri, Nov 11, 2016 at 09:23:43PM +0000, David Woodhouse wrote:
> > > It's also *fairly* unlikely that the kernel in the guest has developed
> > > a bug and isn't setting gso_size sanely. I'm more inclined to suspect
> > > that qemu isn't properly emulating those bits. But at first glance at
> > > the code, it looks like *that's* been there for the last decade too...
> >
> > I take issue with that, having looked at the qemu rtl8139 code:
> >
> > if ((txdw0 & CP_TX_LGSEN) && ip_protocol == IP_PROTO_TCP)
> > {
> > int large_send_mss = (txdw0 >> 16) & CP_TC_LGSEN_MSS_MASK;
> >
> > DPRINTF("+++ C+ mode offloaded task TSO MTU=%d IP data %d "
> > "frame data %d specified MSS=%d\n", ETH_MTU,
> > ip_data_len, saved_size - ETH_HLEN, large_send_mss);
> >
> > That's the only reference to "large_send_mss" there, other than that,
> > the MSS value that gets stuck into the field by 8139cp.c is completely
> > unused. Instead, qemu does this:
> >
> > eth_payload_data = saved_buffer + ETH_HLEN;
> > eth_payload_len = saved_size - ETH_HLEN;
> >
> > ip = (ip_header*)eth_payload_data;
> >
> > hlen = IP_HEADER_LENGTH(ip);
> > ip_data_len = be16_to_cpu(ip->ip_len) - hlen;
> >
> > tcp_header *p_tcp_hdr = (tcp_header*)(eth_payload_data + hlen);
> > int tcp_hlen = TCP_HEADER_DATA_OFFSET(p_tcp_hdr);
> >
> > /* ETH_MTU = ip header len + tcp header len + payload */
> > int tcp_data_len = ip_data_len - tcp_hlen;
> > int tcp_chunk_size = ETH_MTU - hlen - tcp_hlen;
> >
> > for (tcp_send_offset = 0; tcp_send_offset < tcp_data_len; tcp_send_offset += tcp_chunk_size)
> > {
> >
> > It uses a fixed value of ETH_MTU to calculate the size of the TCP
> > data chunks, and this is not surprisingly the well known:
> >
> > #define ETH_MTU 1500
> >
> > Qemu seems to be buggy - it ignores the MSS value, and always tries to
> > send 1500 byte frames.
>
> cc'ing in Stefan who last touched that code and Jason and Vlad who
> know the net code.
CCing Igor Kovalenko who implemented "fixed for TCP segmentation
offloading - removed dependency on slirp.h" in 2006. I don't actually
expect him to remember this from 10 years ago though :).
Looking at the history the large_send_mss variable was never used for
anything beyond the debug printf.
The datasheet for this NIC is here:
http://realtek.info/pdf/rtl8139cp.pdf. See 9.2.1 Transmit.
Does this untested patch work for you?
diff --git a/hw/net/rtl8139.c b/hw/net/rtl8139.c
index f05e59c..a3f1af5 100644
--- a/hw/net/rtl8139.c
+++ b/hw/net/rtl8139.c
@@ -2167,9 +2167,13 @@ static int rtl8139_cplus_transmit_one(RTL8139State *s)
goto skip_offload;
}
- /* ETH_MTU = ip header len + tcp header len + payload */
+ /* MSS too small */
+ if (tcp_hlen + hlen >= large_send_mss) {
+ goto skip_offload;
+ }
+
int tcp_data_len = ip_data_len - tcp_hlen;
- int tcp_chunk_size = ETH_MTU - hlen - tcp_hlen;
+ int tcp_chunk_size = large_send_mss - hlen - tcp_hlen;
DPRINTF("+++ C+ mode TSO IP data len %d TCP hlen %d TCP "
"data len %d TCP chunk size %d\n", ip_data_len,
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]
^ permalink raw reply related
* Re: [PATCH v3] ip6_output: ensure flow saddr actually belongs to device
From: Hannes Frederic Sowa @ 2016-11-14 16:44 UTC (permalink / raw)
To: Jason A. Donenfeld, David Ahern, Netdev, WireGuard mailing list,
LKML, YOSHIFUJI Hideaki
In-Reply-To: <20161113232813.28926-1-Jason@zx2c4.com>
On Mon, Nov 14, 2016, at 00:28, Jason A. Donenfeld wrote:
> This puts the IPv6 routing functions in parity with the IPv4 routing
> functions. Namely, we now check in v6 that if a flowi6 requests an
> saddr, the returned dst actually corresponds to a net device that has
> that saddr. This mirrors the v4 logic with __ip_dev_find in
> __ip_route_output_key_hash. In the event that the returned dst is not
> for a dst with a dev that has the saddr, we return -EINVAL, just like
> v4; this makes it easy to use the same error handlers for both cases.
>
> Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
> Cc: David Ahern <dsa@cumulusnetworks.com>
> ---
> Changes from v2:
> It turns out ipv6_chk_addr already has the device enumeration
> logic that we need by simply passing NULL.
>
> net/ipv6/ip6_output.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c
> index 6001e78..b3b5cb6 100644
> --- a/net/ipv6/ip6_output.c
> +++ b/net/ipv6/ip6_output.c
> @@ -926,6 +926,10 @@ static int ip6_dst_lookup_tail(struct net *net,
> const struct sock *sk,
> int err;
> int flags = 0;
>
> + if (!ipv6_addr_any(&fl6->saddr) &&
> + !ipv6_chk_addr(net, &fl6->saddr, NULL, 1))
> + return -EINVAL;
Hmm, this check is too permissive, no?
E.g. what happens if you move a link local address from one interface to
another? In this case this code would still allow the saddr to be used.
I just also quickly read up on the history (sorry was travelling last
week) and wonder if you ever saw a user space facing bug or if this is
basically some difference you saw while writing out of tree code?
Thanks,
Hannes
^ permalink raw reply
* Re: [PATCH v3] ip6_output: ensure flow saddr actually belongs to device
From: Jason A. Donenfeld @ 2016-11-14 16:54 UTC (permalink / raw)
To: David Ahern, David Miller
Cc: Netdev, Hannes Frederic Sowa, YOSHIFUJI Hideaki,
WireGuard mailing list, LKML
In-Reply-To: <CAHmME9qC4xqGOwJnauXrJBDkAtmmuJ+kJKL6ufuU9_XWKNFdSA@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 201 bytes --]
On Nov 14, 2016 17:19, "David Ahern" <dsa@cumulusnetworks.com> wrote:
>
> LGTM
>
> Acked-by: David Ahern <dsa@cumulusnetworks.com>
Great.
@DaveM: can we get this in 4.9 and in stable?
Thanks,
Jason
[-- Attachment #1.2: Type: text/html, Size: 410 bytes --]
[-- Attachment #2: Type: text/plain, Size: 147 bytes --]
_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/wireguard
^ permalink raw reply
* Re: [PATCH v3] ip6_output: ensure flow saddr actually belongs to device
From: David Ahern @ 2016-11-14 16:55 UTC (permalink / raw)
To: Hannes Frederic Sowa, Jason A. Donenfeld, Netdev,
WireGuard mailing list, LKML, YOSHIFUJI Hideaki
In-Reply-To: <1479141867.3723362.787321689.4A3DCFD6@webmail.messagingengine.com>
On 11/14/16 9:44 AM, Hannes Frederic Sowa wrote:
> On Mon, Nov 14, 2016, at 00:28, Jason A. Donenfeld wrote:
>> This puts the IPv6 routing functions in parity with the IPv4 routing
>> functions. Namely, we now check in v6 that if a flowi6 requests an
>> saddr, the returned dst actually corresponds to a net device that has
>> that saddr. This mirrors the v4 logic with __ip_dev_find in
>> __ip_route_output_key_hash. In the event that the returned dst is not
>> for a dst with a dev that has the saddr, we return -EINVAL, just like
>> v4; this makes it easy to use the same error handlers for both cases.
>>
>> Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
>> Cc: David Ahern <dsa@cumulusnetworks.com>
>> ---
>> Changes from v2:
>> It turns out ipv6_chk_addr already has the device enumeration
>> logic that we need by simply passing NULL.
>>
>> net/ipv6/ip6_output.c | 4 ++++
>> 1 file changed, 4 insertions(+)
>>
>> diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c
>> index 6001e78..b3b5cb6 100644
>> --- a/net/ipv6/ip6_output.c
>> +++ b/net/ipv6/ip6_output.c
>> @@ -926,6 +926,10 @@ static int ip6_dst_lookup_tail(struct net *net,
>> const struct sock *sk,
>> int err;
>> int flags = 0;
>>
>> + if (!ipv6_addr_any(&fl6->saddr) &&
>> + !ipv6_chk_addr(net, &fl6->saddr, NULL, 1))
>> + return -EINVAL;
>
> Hmm, this check is too permissive, no?
>
> E.g. what happens if you move a link local address from one interface to
> another? In this case this code would still allow the saddr to be used.
This check -- like the ipv4 variant -- only verifies the saddr is locally assigned. If the address moves interfaces it should be fine.
>
> I just also quickly read up on the history (sorry was travelling last
> week) and wonder if you ever saw a user space facing bug or if this is
> basically some difference you saw while writing out of tree code?
I checked the userspace API this morning. bind and cmsg for example check that the address is valid with calls to ipv6_chk_addr.
^ permalink raw reply
* Re: [PATCH v3] ip6_output: ensure flow saddr actually belongs to device
From: Hannes Frederic Sowa @ 2016-11-14 17:04 UTC (permalink / raw)
To: David Ahern, Jason A. Donenfeld, Netdev, WireGuard mailing list,
LKML, YOSHIFUJI Hideaki
In-Reply-To: <fd1c804d-3e44-0321-8a3e-67d6ff7357fa@cumulusnetworks.com>
On 14.11.2016 17:55, David Ahern wrote:
> On 11/14/16 9:44 AM, Hannes Frederic Sowa wrote:
>> On Mon, Nov 14, 2016, at 00:28, Jason A. Donenfeld wrote:
>>> This puts the IPv6 routing functions in parity with the IPv4 routing
>>> functions. Namely, we now check in v6 that if a flowi6 requests an
>>> saddr, the returned dst actually corresponds to a net device that has
>>> that saddr. This mirrors the v4 logic with __ip_dev_find in
>>> __ip_route_output_key_hash. In the event that the returned dst is not
>>> for a dst with a dev that has the saddr, we return -EINVAL, just like
>>> v4; this makes it easy to use the same error handlers for both cases.
>>>
>>> Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
>>> Cc: David Ahern <dsa@cumulusnetworks.com>
>>> ---
>>> Changes from v2:
>>> It turns out ipv6_chk_addr already has the device enumeration
>>> logic that we need by simply passing NULL.
>>>
>>> net/ipv6/ip6_output.c | 4 ++++
>>> 1 file changed, 4 insertions(+)
>>>
>>> diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c
>>> index 6001e78..b3b5cb6 100644
>>> --- a/net/ipv6/ip6_output.c
>>> +++ b/net/ipv6/ip6_output.c
>>> @@ -926,6 +926,10 @@ static int ip6_dst_lookup_tail(struct net *net,
>>> const struct sock *sk,
>>> int err;
>>> int flags = 0;
>>>
>>> + if (!ipv6_addr_any(&fl6->saddr) &&
>>> + !ipv6_chk_addr(net, &fl6->saddr, NULL, 1))
>>> + return -EINVAL;
>>
>> Hmm, this check is too permissive, no?
>>
>> E.g. what happens if you move a link local address from one interface to
>> another? In this case this code would still allow the saddr to be used.
>
> This check -- like the ipv4 variant -- only verifies the saddr is locally assigned. If the address moves interfaces it should be fine.
But in this case we should actually bail out, no?
Let's say, user assumes we are on ifindex eth0 with LL address from
eth0. Suddenly the LL address from eth0 is moved to eth1, we can't
accept this source address anymore and need to return -EINVAL, too.
>> I just also quickly read up on the history (sorry was travelling last
>> week) and wonder if you ever saw a user space facing bug or if this is
>> basically some difference you saw while writing out of tree code?
>
> I checked the userspace API this morning. bind and cmsg for example check that the address is valid with calls to ipv6_chk_addr.
Hmm, so it fixes no real bug.
Because of translations of flowi6_oif we actually can't do a correct
check of source address for cases like the one I outlined above? Hmm,
maybe we should simply depend on user space checks.
Bye,
Hannes
^ permalink raw reply
* Assalamu`Alaikum.
From: mohammad ouattara @ 2016-11-14 17:00 UTC (permalink / raw)
In-Reply-To: <1854474938.4647011.1479142846322.ref@mail.yahoo.com>
Dear Sir/Madam.
Assalamu`Alaikum.
I am Dr mohammad ouattara, I have ($10.6 Million us dollars) to transfer into your account,
I will send you more details about this deal and the procedures to follow when I receive a positive response from you,
Have a great day,
Dr mohammad ouattara.
^ permalink raw reply
* Re: [PATCH v3] ip6_output: ensure flow saddr actually belongs to device
From: David Ahern @ 2016-11-14 17:17 UTC (permalink / raw)
To: Hannes Frederic Sowa, Jason A. Donenfeld, Netdev,
WireGuard mailing list, LKML, YOSHIFUJI Hideaki
In-Reply-To: <7d8c0210-9132-c755-9053-6ec19409e343@stressinduktion.org>
On 11/14/16 10:04 AM, Hannes Frederic Sowa wrote:
> On 14.11.2016 17:55, David Ahern wrote:
>> On 11/14/16 9:44 AM, Hannes Frederic Sowa wrote:
>>> On Mon, Nov 14, 2016, at 00:28, Jason A. Donenfeld wrote:
>>>> This puts the IPv6 routing functions in parity with the IPv4 routing
>>>> functions. Namely, we now check in v6 that if a flowi6 requests an
>>>> saddr, the returned dst actually corresponds to a net device that has
>>>> that saddr. This mirrors the v4 logic with __ip_dev_find in
>>>> __ip_route_output_key_hash. In the event that the returned dst is not
>>>> for a dst with a dev that has the saddr, we return -EINVAL, just like
>>>> v4; this makes it easy to use the same error handlers for both cases.
>>>>
>>>> Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
>>>> Cc: David Ahern <dsa@cumulusnetworks.com>
>>>> ---
>>>> Changes from v2:
>>>> It turns out ipv6_chk_addr already has the device enumeration
>>>> logic that we need by simply passing NULL.
>>>>
>>>> net/ipv6/ip6_output.c | 4 ++++
>>>> 1 file changed, 4 insertions(+)
>>>>
>>>> diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c
>>>> index 6001e78..b3b5cb6 100644
>>>> --- a/net/ipv6/ip6_output.c
>>>> +++ b/net/ipv6/ip6_output.c
>>>> @@ -926,6 +926,10 @@ static int ip6_dst_lookup_tail(struct net *net,
>>>> const struct sock *sk,
>>>> int err;
>>>> int flags = 0;
>>>>
>>>> + if (!ipv6_addr_any(&fl6->saddr) &&
>>>> + !ipv6_chk_addr(net, &fl6->saddr, NULL, 1))
>>>> + return -EINVAL;
>>>
>>> Hmm, this check is too permissive, no?
>>>
>>> E.g. what happens if you move a link local address from one interface to
>>> another? In this case this code would still allow the saddr to be used.
>>
>> This check -- like the ipv4 variant -- only verifies the saddr is locally assigned. If the address moves interfaces it should be fine.
>
> But in this case we should actually bail out, no?
>
> Let's say, user assumes we are on ifindex eth0 with LL address from
> eth0. Suddenly the LL address from eth0 is moved to eth1, we can't
> accept this source address anymore and need to return -EINVAL, too.
so you mean if rt6_need_strict(&fl6->saddr) then the dev needs to be considered.
>
>>> I just also quickly read up on the history (sorry was travelling last
>>> week) and wonder if you ever saw a user space facing bug or if this is
>>> basically some difference you saw while writing out of tree code?
>>
>> I checked the userspace API this morning. bind and cmsg for example check that the address is valid with calls to ipv6_chk_addr.
>
> Hmm, so it fixes no real bug.
>
> Because of translations of flowi6_oif we actually can't do a correct
> check of source address for cases like the one I outlined above? Hmm,
> maybe we should simply depend on user space checks.
I believe Jason's case is forwarding path and the ipv6_stub->ipv6_dst_lookup API.
^ permalink raw reply
* Re: Kernel 4.8.7 crashing
From: Cong Wang @ 2016-11-14 17:18 UTC (permalink / raw)
To: Ashton Holmes; +Cc: LKML, Linux Kernel Network Developers
In-Reply-To: <CAM_iQpUiBE93MsYsMWKcSRBTCNMPvWRqiqAkH3DDqFP1cCSdtw@mail.gmail.com>
(Really Cc'ing netdev.. ;-p )
On Mon, Nov 14, 2016 at 9:18 AM, Cong Wang <xiyou.wangcong@gmail.com> wrote:
> Cc'ing netdev.
>
> On Sat, Nov 12, 2016 at 2:17 PM, Ashton Holmes <scoopta@gmail.com> wrote:
>> I upgraded to 4.8.7 and the system boots and my root partition gets
>> decrypted but right after that both of my monitors turn off and
>> looking at syslog from 4.8.6 shows the following:
>>
>> Nov 12 11:54:24 user-desktop kernel: [ 19.853197] ------------[ cut
>> here ]------------
>> Nov 12 11:54:24 user-desktop kernel: [ 19.853206] WARNING: CPU: 2
>> PID: 177 at fs/proc/proc_sysctl.c:1607 ops_exit_list.isra.4+0x33/0x60
>
> Probably this warning in source code:
>
> void retire_sysctl_set(struct ctl_table_set *set)
> {
> WARN_ON(!RB_EMPTY_ROOT(&set->dir.root));
> }
>
>
>> Nov 12 11:54:24 user-desktop kernel: [ 19.853210] Modules linked in:
>> amdgpu eeepc_wmi i2c_algo_bit asus_wmi drm_kms_helper video rfkill
>> snd_hda_codec_realtek ttm snd_hda_codec_generic snd_hda_codec_hdmi drm
>> snd_hda_intel snd_usb_audio sparse_keymap snd_hda_codec mxm_wmi
>> snd_usbmidi_lib snd_hda_core efi_pstore snd_hwdep snd_rawmidi evdev
>> snd_seq_device joydev snd_pcm serio_raw pcspkr efivars fam15h_power
>> k10temp snd_timer snd sp5100_tco i2c_piix4 sg soundcore i2c_core
>> shpchp tpm_infineon tpm_tis tpm_tis_core tpm wmi button it87 hwmon_vid
>> autofs4 ext4 crc16 jbd2 mbcache algif_skcipher af_alg dm_crypt dm_mod
>> hid_generic usbhid hid sr_mod cdrom sd_mod ohci_pci crct10dif_pclmul
>> crc32_pclmul crc32c_intel aesni_intel aes_x86_64 glue_helper lrw
>> gf128mul ablk_helper cryptd psmouse ohci_hcd ahci libahci ehci_pci
>> ehci_hcd libata xhci_pci xhci_hcd e1000e usbcore scsi_mod ptp
>> usb_common pps_core
>> Nov 12 11:54:24 user-desktop kernel: [ 19.853264] CPU: 2 PID: 177
>> Comm: kworker/u16:2 Not tainted 4.8.7 #1
>> Nov 12 11:54:24 user-desktop kernel: [ 19.853267] Hardware name: To
>> be filled by O.E.M. To be filled by O.E.M./CROSSHAIR V FORMULA-Z, BIOS
>> 2201 03/23/2015
>> Nov 12 11:54:24 user-desktop kernel: [ 19.853273] Workqueue: netns cleanup_net
>> Nov 12 11:54:24 user-desktop kernel: [ 19.853276] 0000000000000286
>> 00000000b98071d2 ffffffff81302a8f 0000000000000000
>> Nov 12 11:54:24 user-desktop kernel: [ 19.853281] 0000000000000000
>> ffffffff81076f54 ffff880814f88040 ffff8808140efdf0
>> Nov 12 11:54:24 user-desktop kernel: [ 19.853285] ffffffff818f11d8
>> ffffffff818f11e0 ffff8808140efde0 0000000000000200
>> Nov 12 11:54:24 user-desktop kernel: [ 19.853290] Call Trace:
>> Nov 12 11:54:24 user-desktop kernel: [ 19.853295]
>> [<ffffffff81302a8f>] ? dump_stack+0x5c/0x7d
>> Nov 12 11:54:24 user-desktop kernel: [ 19.853299]
>> [<ffffffff81076f54>] ? __warn+0xc4/0xe0
>> Nov 12 11:54:24 user-desktop kernel: [ 19.853302]
>> [<ffffffff8149e243>] ? ops_exit_list.isra.4+0x33/0x60
>> Nov 12 11:54:24 user-desktop kernel: [ 19.853305]
>> [<ffffffff8149f230>] ? cleanup_net+0x1b0/0x290
>> Nov 12 11:54:24 user-desktop kernel: [ 19.853309]
>> [<ffffffff8108fefd>] ? process_one_work+0x14d/0x410
>> Nov 12 11:54:24 user-desktop kernel: [ 19.853312]
>> [<ffffffff81090cc2>] ? worker_thread+0x62/0x490
>> Nov 12 11:54:24 user-desktop kernel: [ 19.853315]
>> [<ffffffff81090c60>] ? rescuer_thread+0x340/0x340
>> Nov 12 11:54:24 user-desktop kernel: [ 19.853318]
>> [<ffffffff81095f3f>] ? kthread+0xdf/0x100
>> Nov 12 11:54:24 user-desktop kernel: [ 19.853322]
>> [<ffffffff8102b78b>] ? __switch_to+0x2bb/0x710
>> Nov 12 11:54:24 user-desktop kernel: [ 19.853325]
>> [<ffffffff815a371f>] ? ret_from_fork+0x1f/0x40
>> Nov 12 11:54:24 user-desktop kernel: [ 19.853328]
>> [<ffffffff81095e60>] ? kthread_park+0x50/0x50
>> Nov 12 11:54:24 user-desktop kernel: [ 19.853331] ---[ end trace
>> c4840b46b58dbe12 ]---
>
> Looks like net->sysctls is not empty when unregistering,
> perhaps unregister_net_sysctl_table() is missing somewhere.
^ permalink raw reply
* Re: [PATCH 1/6] dt-bindings: mdio-mux: Add documentation for mdio mux for NSP SoC
From: Rob Herring @ 2016-11-14 17:22 UTC (permalink / raw)
To: Yendapally Reddy Dhananjaya Reddy
Cc: Mark Rutland, Russell King, Ray Jui, Scott Branden, Jon Mason,
Florian Fainelli, Kishon Vijay Abraham I,
bcm-kernel-feedback-list-dY08KVG/lbpWk0Htik3J/w,
netdev-u79uwXL29TY76Z2rM5mHXA, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <1478683994-12008-2-git-send-email-yendapally.reddy-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
On Wed, Nov 09, 2016 at 04:33:09AM -0500, Yendapally Reddy Dhananjaya Reddy wrote:
> Add documentation for mdio mux available in Broadcom NSP SoC
>
> Signed-off-by: Yendapally Reddy Dhananjaya Reddy <yendapally.reddy-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
> ---
> .../devicetree/bindings/net/brcm,mdio-mux-nsp.txt | 57 ++++++++++++++++++++++
> 1 file changed, 57 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/net/brcm,mdio-mux-nsp.txt
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" 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 2/6] dt-bindings: phy: Add documentation for NSP USB3 PHY
From: Rob Herring @ 2016-11-14 17:23 UTC (permalink / raw)
To: Yendapally Reddy Dhananjaya Reddy
Cc: Mark Rutland, Russell King, Ray Jui, Scott Branden, Jon Mason,
Florian Fainelli, Kishon Vijay Abraham I,
bcm-kernel-feedback-list, netdev, devicetree, linux-kernel,
linux-arm-kernel
In-Reply-To: <1478683994-12008-3-git-send-email-yendapally.reddy@broadcom.com>
On Wed, Nov 09, 2016 at 04:33:10AM -0500, Yendapally Reddy Dhananjaya Reddy wrote:
> Add documentation for USB3 PHY available in Northstar plus SoC
>
> Signed-off-by: Yendapally Reddy Dhananjaya Reddy <yendapally.reddy@broadcom.com>
> ---
> .../devicetree/bindings/phy/brcm,nsp-usb3-phy.txt | 39 ++++++++++++++++++++++
> 1 file changed, 39 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/phy/brcm,nsp-usb3-phy.txt
>
> diff --git a/Documentation/devicetree/bindings/phy/brcm,nsp-usb3-phy.txt b/Documentation/devicetree/bindings/phy/brcm,nsp-usb3-phy.txt
> new file mode 100644
> index 0000000..30cf4b9
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/phy/brcm,nsp-usb3-phy.txt
> @@ -0,0 +1,39 @@
> +Broadcom USB3 phy binding northstar plus SoC
> +This is a child bus node of "brcm,mdio-mux-nsp" node.
> +
> +Required mdio bus properties:
> +- reg: MDIO Bus number for the MDIO interface
> +- #address-cells: must be 1
> +- #size-cells: must be 0
> +
> +Required PHY properties:
> +- compatible: should be "brcm,nsp-usb3-phy"
> +- reg: Phy address in the MDIO interface
> +- usb3-ctrl-syscon: handler of syscon node defining physical address
> + of usb3 control register.
> +- #phy-cells: must be 0
> +
> +Required usb3 control properties:
> +- compatible: should be "brcm,nsp-usb3-ctrl"
> +- reg: offset and length of the control registers
> +
> +Example:
> +
> + mdio@0 {
> + reg = <0x0>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + usb3_phy: usb3-phy@10 {
Just 'usb-phy@10'. With that,
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH 3/5] net: thunderx: Fix configuration of L3/L4 length checking
From: Sunil Kovvuri @ 2016-11-14 17:26 UTC (permalink / raw)
To: Corentin Labbe; +Cc: Linux Netdev List, Sunil Goutham, LKML, LAKML
In-Reply-To: <20161114123350.GA2449@Red>
>>You could use the BIT() macro here
Thanks, will change and resubmit.
Sunil.
^ permalink raw reply
* Re: [PATCH 0/5] net: thunderx: Miscellaneous fixes
From: Sunil Kovvuri @ 2016-11-14 17:27 UTC (permalink / raw)
To: Matthias Brugger
Cc: Robert Richter, Linux Netdev List, Sunil Goutham, LKML, LAKML
In-Reply-To: <2948c47d-0f15-8153-440b-7a2c753b7251@suse.com>
>>If so, please add "Cc: stable@vger.kernel.org" to the Sigend-off list.
Yes they are, thanks, will do that along with resubmission.
Sunil.
^ permalink raw reply
* Re: [PATCH net 2/2] r8152: rx descriptor check
From: David Miller @ 2016-11-14 17:27 UTC (permalink / raw)
To: hayeswang; +Cc: mlord, netdev, nic_swsd, linux-kernel, linux-usb
In-Reply-To: <0835B3720019904CB8F7AA43166CEEB20104EBCC@RTITMBSV03.realtek.com.tw>
From: Hayes Wang <hayeswang@realtek.com>
Date: Mon, 14 Nov 2016 07:23:51 +0000
> Mark Lord [mailto:mlord@pobox.com]
>> Sent: Monday, November 14, 2016 4:34 AM
> [...]
>> Perhaps the driver
>> is somehow accessing the buffer space again after doing usb_submit_urb()?
>> That would certainly produce this kind of behaviour.
>
> I don't think so. First, the driver only read the received buffer.
> That is, the driver would not change (or write) the data. Second,
> The driver would lose the point address of the received buffer
> after submitting the urb to the USB host controller, until the
> transfer is completed by the USB host controller. That is, the
> driver doesn't how to access the buffer after calling usb_submit_urb().
This is why it's most likely some DMA implementation issue or similar.
^ permalink raw reply
* Re: [PATCH v2 0/2] bnx2: Wait for in-flight DMA to complete at probe stage
From: David Miller @ 2016-11-14 17:28 UTC (permalink / raw)
To: pmenzel
Cc: bhe, netdev, michael.chan, linux-kernel, Dept-GELinuxNICDev,
rasesh.mody, harish.patil, frank, jsr, jroedel, dyoung
In-Reply-To: <8010f40d-e7ca-8fd1-7317-f576289c112f@molgen.mpg.de>
From: Paul Menzel <pmenzel@molgen.mpg.de>
Date: Mon, 14 Nov 2016 09:25:47 +0100
> Dear Baoquan,
>
> On 11/13/16 06:01, Baoquan He wrote:
>> This is v2 post.
>>
>> In commit 3e1be7a ("bnx2: Reset device during driver initialization"),
>> firmware requesting code was moved from open stage to probe stage.
>> The reason is in kdump kernel hardware iommu need device be reset in
>> driver probe stage, otherwise those in-flight DMA from 1st kernel
>> will continue going and look up into the newly created io-page tables.
>> However bnx2 chip resetting involves firmware requesting issue, that
>> need be done in open stage.
>>
>> Michale Chan suggested we can just wait for the old in-flight DMA to
>> complete at probe stage, then though without device resetting, we
>> don't need to worry the old in-flight DMA could continue looking up
>> the newly created io-page tables.
>>
>> v1->v2:
>> Michael suggested to wait for the in-flight DMA to complete at probe
>> stage. So give up the old method of trying to reset chip at probe
>> stage, take the new way accordingly.
>
> thank you for posting the updated series. Could you please resend a v3
> with stable@vger.kernel.org added [1]?
This is not the proper procedure for networking patches.
^ permalink raw reply
* Re: Long delays creating a netns after deleting one (possibly RCU related)
From: Hannes Frederic Sowa @ 2016-11-14 17:29 UTC (permalink / raw)
To: Cong Wang, Paul E. McKenney
Cc: Rolf Neugebauer, LKML, Linux Kernel Network Developers,
Justin Cormack, Ian Campbell
In-Reply-To: <CAM_iQpUDnPfVayQv7Q+ZtC_2_ZbX9MRX=514gFpF3E6XY+GtSA@mail.gmail.com>
Hi Cong,
On Sat, Nov 12, 2016, at 01:55, Cong Wang wrote:
> On Fri, Nov 11, 2016 at 4:23 PM, Paul E. McKenney
> <paulmck@linux.vnet.ibm.com> wrote:
> >
> > Ah! This net_mutex is different than RTNL. Should synchronize_net() be
> > modified to check for net_mutex being held in addition to the current
> > checks for RTNL being held?
> >
>
> Good point!
>
> Like commit be3fc413da9eb17cce0991f214ab0, checking
> for net_mutex for this case seems to be an optimization, I assume
> synchronize_rcu_expedited() and synchronize_rcu() have the same
> behavior...
>
> diff --git a/net/core/dev.c b/net/core/dev.c
> index eaad4c2..3415b6b 100644
> --- a/net/core/dev.c
> +++ b/net/core/dev.c
> @@ -7762,7 +7762,7 @@ EXPORT_SYMBOL(free_netdev);
> void synchronize_net(void)
> {
> might_sleep();
> - if (rtnl_is_locked())
> + if (rtnl_is_locked() || lockdep_is_held(&net_mutex))
> synchronize_rcu_expedited();
I don't think we should depend on lockdep for this check but rather use
mutex_is_locked here (I think it would fail to build like this without
CONFIG_LOCKDEP).
Bye,
Hannes
^ permalink raw reply
* Re: [PATCH net-next v5] cadence: Add LSO support.
From: David Miller @ 2016-11-14 17:30 UTC (permalink / raw)
To: rafalo; +Cc: nicolas.ferre, netdev, linux-kernel
In-Reply-To: <BN3PR07MB2516C30913D2FB8D4788071AC9BC0@BN3PR07MB2516.namprd07.prod.outlook.com>
From: Rafal Ozieblo <rafalo@cadence.com>
Date: Mon, 14 Nov 2016 09:32:34 +0000
>> If UFO is in use it should not silently disable UDP checksums.
>>
>> If you cannot support UFO with proper checksumming, then you cannot enable support for that feature.
>
> According Cadence Gigabit Ethernet MAC documentation:
>
> "Hardware will not calculate the UDP checksum or modify the UDP checksum field. Therefore software
> must set a value of zero in the checksum field in the UDP header (in the first payload buffer)
> to indicate to the receiver that the UDP datagram does not include a checksum."
>
> It is hardware requirement.
I do not doubt that it is a hardware restriction.
But I am saying that you cannot enable this feature under Linux if
this is how it operates on your hardware.
^ permalink raw reply
* Re: [PATCH net-next v7 03/10] dpaa_eth: add option to use one buffer pool set
From: David Miller @ 2016-11-14 17:31 UTC (permalink / raw)
To: madalin.bucur
Cc: netdev, linuxppc-dev, linux-kernel, oss, ppc, joe, pebolle,
joakim.tjernlund
In-Reply-To: <AM4PR04MB16040D32960405FD16007950ECBC0@AM4PR04MB1604.eurprd04.prod.outlook.com>
From: Madalin-Cristian Bucur <madalin.bucur@nxp.com>
Date: Mon, 14 Nov 2016 10:25:13 +0000
> I've introduced this Kconfig option as a backwards compatible option, to
> be able to run comparative tests between the independent buffer pool setup
> and the previous common buffer pool setup. There are not so many reasons
> to use the same buffer pool besides "having the old setup", the memory
> saving is marginal, in all other aspects the separate buffer pools setup
> fares better.
>
> I'll remove this patch from the next submission. Should anyone care for
> this I can add an entry to the feature backlog to add runtime support but
> it will be quite low in priority.
If it's a debugging feature then that's certainly how this should be
handled.
^ permalink raw reply
* Re: Debugging Ethernet issues
From: Florian Fainelli @ 2016-11-14 17:32 UTC (permalink / raw)
To: Mason, Andrew Lunn
Cc: netdev, Mans Rullgard, Sergei Shtylyov, Tom Lendacky, Zach Brown,
Shaohui Xie, Tim Beale, Brian Hill, Vince Bridgers,
Balakumaran Kannan, David S. Miller, Sebastian Frias,
Kirill Kapranov
In-Reply-To: <5829D95C.6060509@free.fr>
On 11/14/2016 07:33 AM, Mason wrote:
> On 14/11/2016 15:58, Mason wrote:
>
>> nb8800 26000.ethernet eth0: Link is Up - 100Mbps/Full - flow control rx/tx
>> vs
>> nb8800 26000.ethernet eth0: Link is Up - 100Mbps/Full - flow control off
>>
>> I'm not sure whether "flow control" is relevant...
>
> Based on phy_print_status()
> phydev->pause ? "rx/tx" : "off"
> I added the following patch.
>
> diff --git a/drivers/net/ethernet/aurora/nb8800.c b/drivers/net/ethernet/aurora/nb8800.c
> index defc22a15f67..4e758c1cfa4e 100644
> --- a/drivers/net/ethernet/aurora/nb8800.c
> +++ b/drivers/net/ethernet/aurora/nb8800.c
> @@ -667,6 +667,8 @@ static void nb8800_link_reconfigure(struct net_device *dev)
> struct phy_device *phydev = priv->phydev;
> int change = 0;
>
> + printk("%s from %pf\n", __func__, __builtin_return_address(0));
> +
> if (phydev->link) {
> if (phydev->speed != priv->speed) {
> priv->speed = phydev->speed;
> @@ -1274,9 +1276,9 @@ static int nb8800_hw_init(struct net_device *dev)
> nb8800_writeb(priv, NB8800_PQ2, val & 0xff);
>
> /* Auto-negotiate by default */
> - priv->pause_aneg = true;
> - priv->pause_rx = true;
> - priv->pause_tx = true;
> + priv->pause_aneg = false;
> + priv->pause_rx = false;
> + priv->pause_tx = false;
>
> nb8800_mc_init(dev, 0);
>
>
> Connected to 1000 Mbps switch:
>
> # time udhcpc | while read LINE; do date; echo $LINE; done
> Thu Jan 1 00:00:22 UTC 1970
> udhcpc (v1.22.1) started
> Thu Jan 1 00:00:22 UTC 1970
> Sending discover...
> [ 24.565346] nb8800_link_reconfigure from phy_state_machine
> Thu Jan 1 00:00:25 UTC 1970
> Sending discover...
> [ 26.575402] nb8800_link_reconfigure from phy_state_machine
> [ 26.580972] nb8800 26000.ethernet eth0: Link is Up - 1Gbps/Full - flow control rx/tx
> Thu Jan 1 00:00:28 UTC 1970
> Sending discover...
> Thu Jan 1 00:00:29 UTC 1970
> Sending select for 172.27.64.58...
> Thu Jan 1 00:00:29 UTC 1970
> Lease of 172.27.64.58 obtained, lease time 604800
> Thu Jan 1 00:00:29 UTC 1970
> deleting routers
> Thu Jan 1 00:00:29 UTC 1970
> adding dns 172.27.0.17
>
> real 0m7.388s
> user 0m0.040s
> sys 0m0.090s
>
>
>
> Connected to 100 Mbps switch:
>
> # time udhcpc | while read LINE; do date; echo $LINE; done
> Thu Jan 1 00:00:14 UTC 1970
> udhcpc (v1.22.1) started
> Thu Jan 1 00:00:15 UTC 1970
> Sending discover...
> [ 16.968621] nb8800_link_reconfigure from phy_state_machine
> [ 17.975359] nb8800_link_reconfigure from phy_state_machine
> [ 17.980923] nb8800 26000.ethernet eth0: Link is Up - 100Mbps/Full - flow control rx/tx
> Thu Jan 1 00:00:18 UTC 1970
> Sending discover...
> Thu Jan 1 00:00:19 UTC 1970
> Sending select for 172.27.64.58...
> Thu Jan 1 00:00:19 UTC 1970
> Lease of 172.27.64.58 obtained, lease time 604800
> Thu Jan 1 00:00:19 UTC 1970
> deleting routers
> Thu Jan 1 00:00:19 UTC 1970
> adding dns 172.27.0.17
>
> real 0m4.355s
> user 0m0.043s
> sys 0m0.083s
>
And the time difference is clearly accounted for auto-negotiation time
here, as you can see it takes about 3 seconds for Gigabit Ethernet to
auto-negotiate and that seems completely acceptable and normal to me
since it is a more involved process than lower speeds.
>
>
> OK, so now it works (by accident?) even on 100 Mbps switch, but it still
> prints "flow control rx/tx"...
Because your link partner advertises flow control, and that's what
phydev->pause and phydev->asym_pause report (I know it's confusing, but
that's what it is at the moment).
>
> # ethtool -a eth0
> Pause parameters for eth0:
> Autonegotiate: off
> RX: off
> TX: off
>
> These values make sense considering my changes in the driver.
>
> Are 100 Mbps switches supposed to support these pause features,
> and are they supposed to be able to auto-negotiate them?
Yes, switches can support flow control aka pause frames, and unless they
are configurable, they typically advertise what their EEPROM has defined
for them, so most likely the full auto-negotiated spectrum:
10/100/1000Mbps and support for flow control, but your mileage may vary
of course.
--
Florian
^ permalink raw reply
* Re: [PATCH 0/5] net: thunderx: Miscellaneous fixes
From: David Miller @ 2016-11-14 17:32 UTC (permalink / raw)
To: mbrugger; +Cc: sunil.kovvuri, netdev, sgoutham, linux-kernel, linux-arm-kernel
In-Reply-To: <2948c47d-0f15-8153-440b-7a2c753b7251@suse.com>
From: Matthias Brugger <mbrugger@suse.com>
Date: Mon, 14 Nov 2016 13:01:25 +0100
>
>
> On 14/11/16 11:54, sunil.kovvuri@gmail.com wrote:
>> From: Sunil Goutham <sgoutham@cavium.com>
>>
>> This patchset includes fixes for incorrect LMAC credits,
>> unreliable driver statistics, memory leak upon interface
>> down e.t.c
>>
>
> Are these fixes relevant to for older kernels as well?
> If so, please add "Cc: stable@vger.kernel.org" to the Sigend-off list.
This is not appropriate for networking patches.
People instead explicitly request -stable inclusion when the
submit networking changes to me, and I queue them up for
later submission.
^ permalink raw reply
* Re: [PATCH v3] ip6_output: ensure flow saddr actually belongs to device
From: Hannes Frederic Sowa @ 2016-11-14 17:33 UTC (permalink / raw)
To: David Ahern, Jason A. Donenfeld, Netdev, WireGuard mailing list,
LKML, YOSHIFUJI Hideaki
In-Reply-To: <c75290bd-7ea2-0bf8-7ac0-fc5a3c81e312@cumulusnetworks.com>
On 14.11.2016 18:17, David Ahern wrote:
> On 11/14/16 10:04 AM, Hannes Frederic Sowa wrote:
>> On 14.11.2016 17:55, David Ahern wrote:
>>> On 11/14/16 9:44 AM, Hannes Frederic Sowa wrote:
>>>> On Mon, Nov 14, 2016, at 00:28, Jason A. Donenfeld wrote:
>>>>> This puts the IPv6 routing functions in parity with the IPv4 routing
>>>>> functions. Namely, we now check in v6 that if a flowi6 requests an
>>>>> saddr, the returned dst actually corresponds to a net device that has
>>>>> that saddr. This mirrors the v4 logic with __ip_dev_find in
>>>>> __ip_route_output_key_hash. In the event that the returned dst is not
>>>>> for a dst with a dev that has the saddr, we return -EINVAL, just like
>>>>> v4; this makes it easy to use the same error handlers for both cases.
>>>>>
>>>>> Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
>>>>> Cc: David Ahern <dsa@cumulusnetworks.com>
>>>>> ---
>>>>> Changes from v2:
>>>>> It turns out ipv6_chk_addr already has the device enumeration
>>>>> logic that we need by simply passing NULL.
>>>>>
>>>>> net/ipv6/ip6_output.c | 4 ++++
>>>>> 1 file changed, 4 insertions(+)
>>>>>
>>>>> diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c
>>>>> index 6001e78..b3b5cb6 100644
>>>>> --- a/net/ipv6/ip6_output.c
>>>>> +++ b/net/ipv6/ip6_output.c
>>>>> @@ -926,6 +926,10 @@ static int ip6_dst_lookup_tail(struct net *net,
>>>>> const struct sock *sk,
>>>>> int err;
>>>>> int flags = 0;
>>>>>
>>>>> + if (!ipv6_addr_any(&fl6->saddr) &&
>>>>> + !ipv6_chk_addr(net, &fl6->saddr, NULL, 1))
>>>>> + return -EINVAL;
>>>>
>>>> Hmm, this check is too permissive, no?
>>>>
>>>> E.g. what happens if you move a link local address from one interface to
>>>> another? In this case this code would still allow the saddr to be used.
>>>
>>> This check -- like the ipv4 variant -- only verifies the saddr is locally assigned. If the address moves interfaces it should be fine.
>>
>> But in this case we should actually bail out, no?
>>
>> Let's say, user assumes we are on ifindex eth0 with LL address from
>> eth0. Suddenly the LL address from eth0 is moved to eth1, we can't
>> accept this source address anymore and need to return -EINVAL, too.
>
> so you mean if rt6_need_strict(&fl6->saddr) then the dev needs to be considered.
Exactly, like we do in the user space facing APIs.
>>>> I just also quickly read up on the history (sorry was travelling last
>>>> week) and wonder if you ever saw a user space facing bug or if this is
>>>> basically some difference you saw while writing out of tree code?
>>>
>>> I checked the userspace API this morning. bind and cmsg for example check that the address is valid with calls to ipv6_chk_addr.
>>
>> Hmm, so it fixes no real bug.
>>
>> Because of translations of flowi6_oif we actually can't do a correct
>> check of source address for cases like the one I outlined above? Hmm,
>> maybe we should simply depend on user space checks.
>
> I believe Jason's case is forwarding path and the ipv6_stub->ipv6_dst_lookup API.
It is not a kernel API, because we don't support something like that for
external kernel modules. We basically exported ipv6_dst_lookup to allow
some IPv4 code to do ipv6 stunts when the IPv6 module is loaded. ;)
Bye,
Hannes
^ permalink raw reply
* Re: [PATCH v2 0/2] bnx2: Wait for in-flight DMA to complete at probe stage
From: Paul Menzel @ 2016-11-14 17:35 UTC (permalink / raw)
To: David Miller
Cc: bhe, netdev, michael.chan, linux-kernel, Dept-GELinuxNICDev,
rasesh.mody, harish.patil, frank, jsr, jroedel, dyoung
In-Reply-To: <20161114.122838.1039215178593568702.davem@davemloft.net>
On 11/14/16 18:28, David Miller wrote:
> From: Paul Menzel <pmenzel@molgen.mpg.de>
> Date: Mon, 14 Nov 2016 09:25:47 +0100
>> On 11/13/16 06:01, Baoquan He wrote:
>>> This is v2 post.
>>>
>>> In commit 3e1be7a ("bnx2: Reset device during driver initialization"),
>>> firmware requesting code was moved from open stage to probe stage.
>>> The reason is in kdump kernel hardware iommu need device be reset in
>>> driver probe stage, otherwise those in-flight DMA from 1st kernel
>>> will continue going and look up into the newly created io-page tables.
>>> However bnx2 chip resetting involves firmware requesting issue, that
>>> need be done in open stage.
>>>
>>> Michale Chan suggested we can just wait for the old in-flight DMA to
>>> complete at probe stage, then though without device resetting, we
>>> don't need to worry the old in-flight DMA could continue looking up
>>> the newly created io-page tables.
>>>
>>> v1->v2:
>>> Michael suggested to wait for the in-flight DMA to complete at probe
>>> stage. So give up the old method of trying to reset chip at probe
>>> stage, take the new way accordingly.
>>
>> thank you for posting the updated series. Could you please resend a v3
>> with stable@vger.kernel.org added [1]?
>
> This is not the proper procedure for networking patches.
Oh, I didn’t know that. Sorry for spreading false information.
Kind regards,
Paul
^ permalink raw reply
* Re: [PATCH net 2/3] bpf, mlx5: fix various refcount/prog issues in mlx5e_xdp_set
From: Alexei Starovoitov @ 2016-11-14 17:35 UTC (permalink / raw)
To: Daniel Borkmann; +Cc: davem, bblanco, tariqt, zhiyisun, ranas, netdev
In-Reply-To: <58297AAD.8060003@iogearbox.net>
On Mon, Nov 14, 2016 at 09:49:49AM +0100, Daniel Borkmann wrote:
> On 11/14/2016 03:49 AM, Alexei Starovoitov wrote:
> >On Mon, Nov 14, 2016 at 01:43:41AM +0100, Daniel Borkmann wrote:
> [...]
> >>diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c
> >>index 751e806..a0fca9f 100644
> >>--- a/kernel/bpf/syscall.c
> >>+++ b/kernel/bpf/syscall.c
> >>@@ -682,6 +682,17 @@ struct bpf_prog *bpf_prog_add(struct bpf_prog *prog, int i)
> >> }
> >> EXPORT_SYMBOL_GPL(bpf_prog_add);
> >>
> >>+void bpf_prog_sub(struct bpf_prog *prog, int i)
> >>+{
> >>+ /* Only to be used for undoing previous bpf_prog_add() in some
> >>+ * error path. We still know that another entity in our call
> >>+ * path holds a reference to the program, thus atomic_sub() can
> >>+ * be safely used in such cases!
> >>+ */
> >>+ WARN_ON(atomic_sub_return(i, &prog->aux->refcnt) == 0);
> >>+}
> >>+EXPORT_SYMBOL_GPL(bpf_prog_sub);
> >
> >the patches look good. I'm only worried about net/net-next merge
> >conflict here. (I would have to deal with it as well).
> >So instead of copying the above helper can we apply net-next's
> >'bpf, mlx4: fix prog refcount in mlx4_en_try_alloc_resources error path'
> >patch to net without mlx4_xdp_set hunk and then apply
> >the rest of this patch?
> >Even better is to send this patch 2/3 to net-next?
> >yes, it's an issue, but very small one. There is no security
> >concern here, so I would prefer to avoid merge conflict.
> >Did you do a test merge of net/net-next by any chance?
>
> Yes, I did a test merge and git resolved the above just fine w/o
> any conflicts. I have no strong opinion whether net or net-next.
> If preferred, I can just resend this series in the evening against
> net-next instead, perhaps that's a bit better.
I have slight preference to go via net-next, but since it merges fine,
I don't mind net route too.
^ permalink raw reply
* Re: [PATCH 0/5] net: thunderx: Miscellaneous fixes
From: Matthias Brugger @ 2016-11-14 17:35 UTC (permalink / raw)
To: David Miller
Cc: sunil.kovvuri, netdev, sgoutham, linux-kernel, linux-arm-kernel
In-Reply-To: <20161114.123253.476733911183519472.davem@davemloft.net>
On 11/14/2016 06:32 PM, David Miller wrote:
> From: Matthias Brugger <mbrugger@suse.com>
> Date: Mon, 14 Nov 2016 13:01:25 +0100
>
>>
>>
>> On 14/11/16 11:54, sunil.kovvuri@gmail.com wrote:
>>> From: Sunil Goutham <sgoutham@cavium.com>
>>>
>>> This patchset includes fixes for incorrect LMAC credits,
>>> unreliable driver statistics, memory leak upon interface
>>> down e.t.c
>>>
>>
>> Are these fixes relevant to for older kernels as well?
>> If so, please add "Cc: stable@vger.kernel.org" to the Sigend-off list.
>
> This is not appropriate for networking patches.
>
> People instead explicitly request -stable inclusion when the
> submit networking changes to me, and I queue them up for
> later submission.
>
Ok, thanks for clarification.
^ permalink raw reply
* Re: Long delays creating a netns after deleting one (possibly RCU related)
From: Cong Wang @ 2016-11-14 17:44 UTC (permalink / raw)
To: Paul E. McKenney
Cc: Rolf Neugebauer, LKML, Linux Kernel Network Developers,
Justin Cormack, Ian Campbell
In-Reply-To: <20161114162417.GJ4127@linux.vnet.ibm.com>
On Mon, Nov 14, 2016 at 8:24 AM, Paul E. McKenney
<paulmck@linux.vnet.ibm.com> wrote:
> On Sun, Nov 13, 2016 at 10:47:01PM -0800, Cong Wang wrote:
>> On Fri, Nov 11, 2016 at 4:55 PM, Cong Wang <xiyou.wangcong@gmail.com> wrote:
>> > On Fri, Nov 11, 2016 at 4:23 PM, Paul E. McKenney
>> > <paulmck@linux.vnet.ibm.com> wrote:
>> >>
>> >> Ah! This net_mutex is different than RTNL. Should synchronize_net() be
>> >> modified to check for net_mutex being held in addition to the current
>> >> checks for RTNL being held?
>> >>
>> >
>> > Good point!
>> >
>> > Like commit be3fc413da9eb17cce0991f214ab0, checking
>> > for net_mutex for this case seems to be an optimization, I assume
>> > synchronize_rcu_expedited() and synchronize_rcu() have the same
>> > behavior...
>>
>> Thinking a bit more, I think commit be3fc413da9eb17cce0991f
>> gets wrong on rtnl_is_locked(), the lock could be locked by other
>> process not by the current one, therefore it should be
>> lockdep_rtnl_is_held() which, however, is defined only when LOCKDEP
>> is enabled... Sigh.
>>
>> I don't see any better way than letting callers decide if they want the
>> expedited version or not, but this requires changes of all callers of
>> synchronize_net(). Hm.
>
> I must confess that I don't understand how it would help to use an
> expedited grace period when some other process is holding RTNL.
> In contrast, I do well understand how it helps when the current process
> is holding RTNL.
Yeah, this is exactly my point. And same for ASSERT_RTNL() which checks
rtnl_is_locked(), clearly we need to assert "it is held by the current process"
rather than "it is locked by whatever process".
But given *_is_held() is always defined by LOCKDEP, so we probably need
mutex to provide such a helper directly, mutex->owner is not always defined
either. :-/
^ permalink raw reply
* Re: [PATCH v3] ip6_output: ensure flow saddr actually belongs to device
From: David Ahern @ 2016-11-14 17:48 UTC (permalink / raw)
To: Hannes Frederic Sowa, Jason A. Donenfeld, Netdev,
WireGuard mailing list, LKML, YOSHIFUJI Hideaki
In-Reply-To: <7779da88-08dc-0adb-42dd-8e00502693df@stressinduktion.org>
On 11/14/16 10:33 AM, Hannes Frederic Sowa wrote:
>>>>> I just also quickly read up on the history (sorry was travelling last
>>>>> week) and wonder if you ever saw a user space facing bug or if this is
>>>>> basically some difference you saw while writing out of tree code?
>>>>
>>>> I checked the userspace API this morning. bind and cmsg for example check that the address is valid with calls to ipv6_chk_addr.
>>>
>>> Hmm, so it fixes no real bug.
>>>
>>> Because of translations of flowi6_oif we actually can't do a correct
>>> check of source address for cases like the one I outlined above? Hmm,
>>> maybe we should simply depend on user space checks.
>>
>> I believe Jason's case is forwarding path and the ipv6_stub->ipv6_dst_lookup API.
>
> It is not a kernel API, because we don't support something like that for
> external kernel modules. We basically exported ipv6_dst_lookup to allow
> some IPv4 code to do ipv6 stunts when the IPv6 module is loaded. ;)
???
ipv6_stub is exported for modules (EXPORT_SYMBOL_GPL(ipv6_stub)).
ipv6_stub->ipv6_dst_lookup is used by several modules -- geneve, tipc, vxlan, mpls -- for IPv6 lookups, not IPv4 code do IPv6 stunts.
So how do you say that is not an exported kernel API?
^ 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