* Re: linux-next: ip6tables *broken* - last base chain position %u doesn't match underflow %u (hook %u
From: valdis.kletnieks @ 2018-03-20 15:57 UTC (permalink / raw)
To: Florian Westphal; +Cc: Pablo Neira Ayuso, netdev, linux-kernel
In-Reply-To: <20180320154842.GC24075@breakpoint.cc>
[-- Attachment #1: Type: text/plain, Size: 477 bytes --]
On Tue, 20 Mar 2018 16:48:42 +0100, Florian Westphal said:
> valdis.kletnieks@vt.edu <valdis.kletnieks@vt.edu> wrote:
> > (Resending because I haven't heard anything)
> [ ip6tables broken ]
>
> Sorry, did not see this email before.
>
> I'll investigate asap, thanks for the detailed report.
No problem, it reverts cleanly and looks like it's 4.17 material,
and finding stuff like this is why I build linux-next kernels :)
Just remember to stick a Reported-By: on the fix :)
[-- Attachment #2: Type: application/pgp-signature, Size: 486 bytes --]
^ permalink raw reply
* Re: [PATCH] net: dev_forward_skb(): Scrub packet's per-netns info only when crossing netns
From: David Miller @ 2018-03-20 16:00 UTC (permalink / raw)
To: LIRAN.ALON; +Cc: netdev, linux-kernel, idan.brown, yuval.shaia
In-Reply-To: <5AB12A0E.2060704@ORACLE.COM>
From: Liran Alon <LIRAN.ALON@ORACLE.COM>
Date: Tue, 20 Mar 2018 17:34:38 +0200
> I personally don't understand why we should maintain
> backwards-comparability to this behaviour.
The reason is because not breaking things is a cornerstone of Linux
kernel development.
> This feature is not documented to user-mode and I don't see why it
> is legit for the user to rely on it.
Whether it is documented or not is irrelevant. A lot of our
interfaces and behaviors are not documented or poorly documented
at best.
> In addition, even if we do want to maintain backwards-comparability to
> this behaviour, I think it is enough to have an opt-in flag in
> /proc/sys/net/core/ that when set to 1 will activate the fix in
> dev_forward_skb() provided by this patch. That would also be a very
> simple change to the patch provided here.
Making it opt-in makes it more palatable, that's for sure.
^ permalink raw reply
* Re: [PATCH] test_bpf: Fix testing with CONFIG_BPF_JIT_ALWAYS_ON=y on other arches
From: Yonghong Song @ 2018-03-20 16:05 UTC (permalink / raw)
To: Thadeu Lima de Souza Cascardo, netdev
Cc: linux-kernel, Daniel Borkmann, Alexei Starovoitov
In-Reply-To: <20180320125851.19650-1-cascardo@canonical.com>
On 3/20/18 5:58 AM, Thadeu Lima de Souza Cascardo wrote:
> Function bpf_fill_maxinsns11 is designed to not be able to be JITed on
> x86_64. So, it fails when CONFIG_BPF_JIT_ALWAYS_ON=y, and
> commit 09584b406742 ("bpf: fix selftests/bpf test_kmod.sh failure when
> CONFIG_BPF_JIT_ALWAYS_ON=y") makes sure that failure is detected on that
> case.
>
> However, it does not fail on other architectures, which have a different
> JIT compiler design. So, test_bpf has started to fail to load on those.
Here, you mentioned that it did not fail on other architectures. Have
you verified all of them or just looked through the algorithm.
Could you give a little bit details about other architectures are okay
while x86 is not? Maybe, x86 JIT can be improved some how?
Thanks!
>
> After this fix, test_bpf loads fine on both x86_64 and ppc64el.
>
> Fixes: 09584b406742 ("bpf: fix selftests/bpf test_kmod.sh failure when CONFIG_BPF_JIT_ALWAYS_ON=y")
> Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
> ---
> lib/test_bpf.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/lib/test_bpf.c b/lib/test_bpf.c
> index 2efb213716faa..3e9335493fe49 100644
> --- a/lib/test_bpf.c
> +++ b/lib/test_bpf.c
> @@ -5467,7 +5467,7 @@ static struct bpf_test tests[] = {
> {
> "BPF_MAXINSNS: Jump, gap, jump, ...",
> { },
> -#ifdef CONFIG_BPF_JIT_ALWAYS_ON
> +#if defined(CONFIG_BPF_JIT_ALWAYS_ON) && defined(CONFIG_X86)
> CLASSIC | FLAG_NO_DATA | FLAG_EXPECTED_FAIL,
> #else
> CLASSIC | FLAG_NO_DATA,
>
^ permalink raw reply
* Re: [PATCH v2] net: ethernet: arc: Fix a potential memory leak if an optional regulator is deferred
From: David Miller @ 2018-03-20 16:07 UTC (permalink / raw)
To: christophe.jaillet
Cc: heiko, branislav, netdev, linux-arm-kernel, linux-rockchip,
linux-kernel, kernel-janitors
In-Reply-To: <7fd57a4e79da41dccf55430cbc43de340a7f1826.1521061530.git.christophe.jaillet@wanadoo.fr>
From: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date: Sun, 18 Mar 2018 23:59:36 +0100
> If the optional regulator is deferred, we must release some resources.
> They will be re-allocated when the probe function will be called again.
>
> Fixes: 6eacf31139bf ("ethernet: arc: Add support for Rockchip SoC layer device tree bindings")
> Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
> ---
> v2: v1 did not compile because of an erroneous variable name. s/ret/err/
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH net] ipv6: old_dport should be a __be16 in __ip6_datagram_connect()
From: Guillaume Nault @ 2018-03-20 16:09 UTC (permalink / raw)
To: Stefano Brivio; +Cc: David S . Miller, Paolo Abeni, Wei Wang, netdev
In-Reply-To: <f747595846809aa8626a2fc6b4bdcda5af75d42a.1521417707.git.sbrivio@redhat.com>
On Mon, Mar 19, 2018 at 11:24:58AM +0100, Stefano Brivio wrote:
> Fixes: 2f987a76a977 ("net: ipv6: keep sk status consistent after datagram connect failure")
> Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
> Acked-by: Paolo Abeni <pabeni@redhat.com>
> ---
> net/ipv6/datagram.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/net/ipv6/datagram.c b/net/ipv6/datagram.c
> index 8a9ac2d0f5d3..a9f7eca0b6a3 100644
> --- a/net/ipv6/datagram.c
> +++ b/net/ipv6/datagram.c
> @@ -149,7 +149,7 @@ int __ip6_datagram_connect(struct sock *sk, struct sockaddr *uaddr,
> struct in6_addr *daddr, old_daddr;
> __be32 fl6_flowlabel = 0;
> __be32 old_fl6_flowlabel;
> - __be32 old_dport;
> + __be16 old_dport;
> int addr_type;
> int err;
>
Acked-by: Guillaume Nault <g.nault@alphalink.fr>
^ permalink raw reply
* Re: [PATCH] net: gemini: fix memory leak
From: David Miller @ 2018-03-20 16:09 UTC (permalink / raw)
To: igor.pylypiv; +Cc: netdev, ulli.kroll, linus.walleij, linux-arm-kernel
In-Reply-To: <1521441651-19753-1-git-send-email-igor.pylypiv@gmail.com>
From: Igor Pylypiv <igor.pylypiv@gmail.com>
Date: Sun, 18 Mar 2018 23:40:51 -0700
> cppcheck report:
> [drivers/net/ethernet/cortina/gemini.c:543]: (error) Memory leak: skb_tab
>
> Signed-off-by: Igor Pylypiv <igor.pylypiv@gmail.com>
Applied, thanks.
^ permalink raw reply
* Re: [RFC] ethtool: Support ETHTOOL_GSTATS2 command.
From: Steve deRosier @ 2018-03-20 16:11 UTC (permalink / raw)
To: Ben Greear
Cc: Michal Kubecek, linux-wireless,
ath10k-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <37830d46-762b-2a92-4506-5792a65d2ebd-my8/4N5VtI7c+919tysfdA@public.gmane.org>
On Tue, Mar 20, 2018 at 8:39 AM, Ben Greear <greearb-my8/4N5VtI7c+919tysfdA@public.gmane.org> wrote:
> On 03/20/2018 03:37 AM, Michal Kubecek wrote:
>>
>> On Wed, Mar 07, 2018 at 11:51:29AM -0800, greearb-my8/4N5VtI7c+919tysfdA@public.gmane.org wrote:
>>>
>>> From: Ben Greear <greearb-my8/4N5VtI7c+919tysfdA@public.gmane.org>
>>>
>>> This is similar to ETHTOOL_GSTATS, but it allows you to specify
>>> a 'level'. This level can be used by the driver to decrease the
>>> amount of stats refreshed. In particular, this helps with ath10k
>>> since getting the firmware stats can be slow.
>>>
>>> Signed-off-by: Ben Greear <greearb-my8/4N5VtI7c+919tysfdA@public.gmane.org>
>>> ---
>>>
>>> NOTE: I know to make it upstream I would need to split the patch and
>>> remove the #define for 'backporting' that I added. But, is the
>>> feature in general wanted? If so, I'll do the patch split and
>>> other tweaks that might be suggested.
>>
>>
>
> Yes, but that would require changing all drivers at once, and would make
> backporting
> and out-of-tree drivers harder to manage. I had low hopes that this feature
> would
> make it upstream, so I didn't want to propose any large changes up front.
>
Hi Ben,
I find the feature OK, but I'm not thrilled with the arbitrary scale
of "level". Maybe there could be some named values, either on a
spectrum as level already is, similar to the kernel log DEBUG, WARN,
INFO.... type levels. Or named bit flags like the way the ath drivers
do their debug flags for granular results. Thoughts?
- Steve
^ permalink raw reply
* Re: [PATCH net-next 0/4] mlxsw: Adapt driver to upcoming firmware versions
From: David Miller @ 2018-03-20 16:11 UTC (permalink / raw)
To: idosch; +Cc: netdev, jiri, mlxsw
In-Reply-To: <20180319075103.17671-1-idosch@mellanox.com>
From: Ido Schimmel <idosch@mellanox.com>
Date: Mon, 19 Mar 2018 09:50:59 +0200
> The first two patches make sure that reserved fields are set to zero, as
> required by the device's programmer's reference manual (PRM).
>
> Last two patches prevent the driver from performing an invalid operation
> that is going to be denied by upcoming firmware versions.
Series applied, thank you.
^ permalink raw reply
* Re: [PATCH] net: dev_forward_skb(): Scrub packet's per-netns info only when crossing netns
From: Liran Alon @ 2018-03-20 16:11 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-kernel, idan.brown, yuval.shaia
In-Reply-To: <20180320.120036.1999626754164343704.davem@davemloft.net>
On 20/03/18 18:00, David Miller wrote:
> From: Liran Alon <LIRAN.ALON@ORACLE.COM>
> Date: Tue, 20 Mar 2018 17:34:38 +0200
>
>> I personally don't understand why we should maintain
>> backwards-comparability to this behaviour.
>
> The reason is because not breaking things is a cornerstone of Linux
> kernel development.
>
>> This feature is not documented to user-mode and I don't see why it
>> is legit for the user to rely on it.
>
> Whether it is documented or not is irrelevant. A lot of our
> interfaces and behaviors are not documented or poorly documented
> at best.
>
>> In addition, even if we do want to maintain backwards-comparability to
>> this behaviour, I think it is enough to have an opt-in flag in
>> /proc/sys/net/core/ that when set to 1 will activate the fix in
>> dev_forward_skb() provided by this patch. That would also be a very
>> simple change to the patch provided here.
>
> Making it opt-in makes it more palatable, that's for sure.
>
1. Do we want to make a flag for every bug that is user-space visible? I
think there is place for consideration on a per-case basis. I still
don't see how a user can utilize this behaviour. He is basically loosing
information (skb->mark) without this patch.
2. Having said that, I don't mind changing patch to maintain backwards
compatibility here. However, there was also a discussion here on where
the flag should sit. I think that a global /proc/sys/net/core/ flag
should be enough. Do you agree it's sufficient for now?
Thanks,
-Liran
^ permalink raw reply
* Re: [PATCH linux-stable-4.14] tcp: reset sk_send_head in tcp_write_queue_purge
From: Willy Tarreau @ 2018-03-20 16:13 UTC (permalink / raw)
To: davem
Cc: yongjian xu, Soheil Hassas Yeganeh, netdev, ycheng, ncardwell,
nefelim4ag, Soheil Hassas Yeganeh, Eric Dumazet
In-Reply-To: <CACrmbvZzCvO6pTpvq=mE54s3CwAaBB4npc+E7Fa8zvMArL3t7A@mail.gmail.com>
Hi David,
regarding the patch below, I'm not certain whether you planned to take
it since it's marked "not applicable" on patchwork, but I suspect it's
only because it doesn't apply to mainline.
However, please note that there are two typos in commit IDs referenced in
the commit message that might be nice to fix before merging :
> > For example, after 27fid7a8ed38 (tcp: purge write queue upon RST),
- here it's "a27fd7a8ed38" (missing 'a' and extra 'i' in the middle)
- and lower in the fixes tag there's the extra 'i' as well :
> > Fixes: a27fid7a8ed38 (tcp: purge write queue upon RST)
There was another report today on the stable list for a similar crash
on 4.14.28 and I suspect it's the one I saw this week-end on my firewall
after upgrading from 4.14.10 to 4.14.27 though I didn't have the symbols
to confirm.
Thanks,
Willy
^ permalink raw reply
* Re: NETDEV WATCHDOG: eth0 (tg3): transmit queue 0 timed out
From: Borislav Petkov @ 2018-03-20 16:18 UTC (permalink / raw)
To: Satish Baddipadige
Cc: Siva Reddy Kallam, Linux Netdev List, Prashant Sreedharan,
Michael Chan, Linux Kernel list
In-Reply-To: <CA+oDAx8CCW8rUfdqSZJpKFzHUBocY_Q1xbJXB0y8qa6qP0iUAg@mail.gmail.com>
On Tue, Mar 20, 2018 at 11:41:06AM +0530, Satish Baddipadige wrote:
> Can you please test the attached patch?
Sure, will do when I get back next week.
Thx.
--
Regards/Gruss,
Boris.
ECO tip #101: Trim your mails when you reply. Srsly.
^ permalink raw reply
* Re: [PATCH net-next 1/1] net/ipv4: disable SMC TCP option with SYN Cookies
From: Eric Dumazet @ 2018-03-20 16:21 UTC (permalink / raw)
To: Ursula Braun, davem
Cc: netdev, linux-s390, schwidefsky, heiko.carstens, raspl
In-Reply-To: <20180320155340.18017-2-ubraun@linux.vnet.ibm.com>
On 03/20/2018 08:53 AM, Ursula Braun wrote:
> From: Hans Wippel <hwippel@linux.vnet.ibm.com>
>
> Currently, the SMC experimental TCP option in a SYN packet is lost on
> the server side when SYN Cookies are active. However, the corresponding
> SYNACK sent back to the client contains the SMC option. This causes an
> inconsistent view of the SMC capabilities on the client and server.
>
> This patch disables the SMC option in the SYNACK when SYN Cookies are
> active to avoid this issue.
>
> Signed-off-by: Hans Wippel <hwippel@linux.vnet.ibm.com>
> Signed-off-by: Ursula Braun <ubraun@linux.vnet.ibm.com>
> ---
> net/ipv4/tcp_output.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
> index 383cac0ff0ec..22894514feae 100644
> --- a/net/ipv4/tcp_output.c
> +++ b/net/ipv4/tcp_output.c
> @@ -3199,6 +3199,8 @@ struct sk_buff *tcp_make_synack(const struct sock *sk, struct dst_entry *dst,
> /* Under synflood, we do not attach skb to a socket,
> * to avoid false sharing.
> */
> + if (IS_ENABLED(CONFIG_SMC))
> + ireq->smc_ok = 0;
> break;
> case TCP_SYNACK_FASTOPEN:
> /* sk is a const pointer, because we want to express multiple
>
I disagree with net-next qualification.
This fixes a bug, so please send it for net tree, and including an appropriate Fixes: tag.
Thanks !
^ permalink raw reply
* Re: [PATCH net-next v2 2/5] net: Revert "ipv4: fix a deadlock in ip_ra_control"
From: David Miller @ 2018-03-20 16:23 UTC (permalink / raw)
To: ktkhai
Cc: yoshfuji, edumazet, yanhaishuang, nikolay, yotamg, soheil, avagin,
nicolas.dichtel, ebiederm, fw, roman.kapl, netdev, xiyou.wangcong,
dvyukov, andreyknvl, lkp
In-Reply-To: <152145089432.7718.3981942805167545803.stgit@localhost.localdomain>
From: Kirill Tkhai <ktkhai@virtuozzo.com>
Date: Mon, 19 Mar 2018 12:14:54 +0300
> This reverts commit 1215e51edad1.
> Since raw_close() is used on every RAW socket destruction,
> the changes made by 1215e51edad1 scale sadly. This clearly
> seen on endless unshare(CLONE_NEWNET) test, and cleanup_net()
> kwork spends a lot of time waiting for rtnl_lock() introduced
> by this commit.
>
> Next patches in series will rework this in another way,
> so now we revert 1215e51edad1. Also, it doesn't seen
> mrtsock_destruct() takes sk_lock, and the comment to the commit
> does not show the actual stack dump. So, there is a question
> did we really need in it.
>
> Signed-off-by: Kirill Tkhai <ktkhai@virtuozzo.com>
Kirill, I think the commit you are reverting is legitimate.
The IP_RAW_CONTROL path has an ABBA deadlock with other paths once
you revert this, so you are reintroducing a bug.
All code paths that must take both RTNL and the socket lock must
do them in the same order. And that order is RTNL then socket
lock.
But you are breaking that here by getting us back into a state
where IP_RAW_CONTROL setsockopt will take the socket lock and
then RTNL.
Again, we can't take, or retake, RTNL if we have the socket lock
currently.
The only valid locking order is socket lock then RTNL.
Thank you.
^ permalink raw reply
* Re: [PATCH] net: dev_forward_skb(): Scrub packet's per-netns info only when crossing netns
From: Eric W. Biederman @ 2018-03-20 16:24 UTC (permalink / raw)
To: Liran Alon
Cc: shmulik.ladkani, netdev, mrv, daniel, davem, linux-kernel,
yuval.shaia, idan.brown
In-Reply-To: <0d84d286-9965-45cb-93c8-379ca1b2441e@default>
Liran Alon <liran.alon@oracle.com> writes:
> ----- shmulik.ladkani@gmail.com wrote:
>
>> On Thu, 15 Mar 2018 09:35:51 -0700 (PDT) Liran Alon
>> <liran.alon@oracle.com> wrote:
>> > ----- shmulik.ladkani@gmail.com wrote:
>> >
>> > > On Thu, 15 Mar 2018 08:01:03 -0700 (PDT) Liran Alon
>> > > <liran.alon@oracle.com> wrote:
>> > > >
>> > > > I still think that default behavior should be to zero skb->mark
>> only
>> > > when skb
>> > > > cross netdevs in different netns.
>> > >
>> > > But the previous default was scrub the mark in *both* xnet and
>> > > non-xnet
>> > > situations.
>> > >
>> > > Therefore, there might be users which RELY on this (strange)
>> default
>> > > behavior in their same-netns-veth-pair setups.
>> > > Meaning, changing the default behavior might break their apps
>> relying
>> > > on
>> > > the former default behavior.
>> > >
>> > > This is why the "disable mark scrubbing in non-xnet case" should
>> be
>> > > opt-in.
>> >
>> > We think the same.
>> > The only difference is that I think this for now should be
>> controllable
>> > by a global /proc/sys/net/core file instead of giving a flexible
>> per-netdev
>> > control.
>> > Because that is a larger change that could be done later.
>>
>> A flags attribute to veth newlink is a very scoped change.
>> User controls this per veth creation.
>> This is way more neat than /proc/sys/net and provides the desired
>> granular
>> control.
>>
>> Also, scoping this to veth has the advantage of not affecting the many
>> other
>> dev_forward_skb callers.
>
> Agreed. But isn't this an issue also for the
> many others (& future) callers of dev_forward_skb()?
> This seems problematic to me.
>
> This will kinda leave a kernel interface with broken default behavior
> for backwards comparability.
>
> A flag to netdev or /proc/sys/net/core to "fix" default behavior
> will avoid this.
I don't believe the current behavior is a bug.
I looked through the history. Basically skb_scrub_packet
started out as the scrubbing needed for crossing network
namespaces.
Then tunnels which needed 90% of the functionality started
calling it, with the xnet flag added. Because the tunnels
needed to preserve their historic behavior.
Then dev_forward_skb started calling skb_scrub_packet.
A veth pair is supposed to give the same behavior as a cross-over
cable plugged into two local nics. A cross over cable won't
preserve things like the skb mark. So I don't see why anyone would
expect a veth pair to preserve the mark.
Right now I don't see the point of handling packets that don't cross
network namespace boundaries specially, other than to preserve backwards
compatibility.
Eric
^ permalink raw reply
* Re: [RFC] ethtool: Support ETHTOOL_GSTATS2 command.
From: Ben Greear @ 2018-03-20 16:24 UTC (permalink / raw)
To: Steve deRosier
Cc: Michal Kubecek, linux-wireless,
ath10k-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <CALLGbRKU_PCk-3ZMBRu6CC-QyaEEPTAOavGVzPpQUdEMQ+s9BQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On 03/20/2018 09:11 AM, Steve deRosier wrote:
> On Tue, Mar 20, 2018 at 8:39 AM, Ben Greear <greearb-my8/4N5VtI7c+919tysfdA@public.gmane.org> wrote:
>> On 03/20/2018 03:37 AM, Michal Kubecek wrote:
>>>
>>> On Wed, Mar 07, 2018 at 11:51:29AM -0800, greearb-my8/4N5VtI7c+919tysfdA@public.gmane.org wrote:
>>>>
>>>> From: Ben Greear <greearb-my8/4N5VtI7c+919tysfdA@public.gmane.org>
>>>>
>>>> This is similar to ETHTOOL_GSTATS, but it allows you to specify
>>>> a 'level'. This level can be used by the driver to decrease the
>>>> amount of stats refreshed. In particular, this helps with ath10k
>>>> since getting the firmware stats can be slow.
>>>>
>>>> Signed-off-by: Ben Greear <greearb-my8/4N5VtI7c+919tysfdA@public.gmane.org>
>>>> ---
>>>>
>>>> NOTE: I know to make it upstream I would need to split the patch and
>>>> remove the #define for 'backporting' that I added. But, is the
>>>> feature in general wanted? If so, I'll do the patch split and
>>>> other tweaks that might be suggested.
>>>
>>>
>>
>> Yes, but that would require changing all drivers at once, and would make
>> backporting
>> and out-of-tree drivers harder to manage. I had low hopes that this feature
>> would
>> make it upstream, so I didn't want to propose any large changes up front.
>>
>
> Hi Ben,
>
> I find the feature OK, but I'm not thrilled with the arbitrary scale
> of "level". Maybe there could be some named values, either on a
> spectrum as level already is, similar to the kernel log DEBUG, WARN,
> INFO.... type levels. Or named bit flags like the way the ath drivers
> do their debug flags for granular results. Thoughts?
Yes, that would be easier to code too. If there are any other drivers
out there that might take advantage of this, maybe they could chime in with
what levels and/or bit-fields they would like to see.
For instance a bit that says 'refresh-stats-from-firmware' would be great for ath10k,
but maybe useless for everyone else....
Thanks,
Ben
>
> - Steve
>
--
Ben Greear <greearb-my8/4N5VtI7c+919tysfdA@public.gmane.org>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [PATCH v12 net-next 12/12] crypto: chtls - Makefile Kconfig
From: kbuild test robot @ 2018-03-20 16:28 UTC (permalink / raw)
To: Atul Gupta
Cc: kbuild-all, davem, herbert, davejwatson, sd, sbrivio,
linux-crypto, netdev, ganeshgr
In-Reply-To: <1521467745-23201-13-git-send-email-atul.gupta@chelsio.com>
[-- Attachment #1: Type: text/plain, Size: 3051 bytes --]
Hi Atul,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on next-20180309]
[also build test ERROR on v4.16-rc6]
[cannot apply to v4.16-rc4 v4.16-rc3 v4.16-rc2]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Atul-Gupta/Chelsio-Inline-TLS/20180320-101600
config: mips-allmodconfig (attached as .config)
compiler: mips-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=mips
All errors (new ones prefixed by >>):
drivers/crypto/chelsio/chtls/chtls_main.c: In function 'chtls_uld_state_change':
>> drivers/crypto/chelsio/chtls/chtls_main.c:319:7: error: 'CXGB4_STATE_FATAL_ERROR' undeclared (first use in this function); did you mean 'CXGB4_STATE_DETACH'?
case CXGB4_STATE_FATAL_ERROR:
^~~~~~~~~~~~~~~~~~~~~~~
CXGB4_STATE_DETACH
drivers/crypto/chelsio/chtls/chtls_main.c:319:7: note: each undeclared identifier is reported only once for each function it appears in
vim +319 drivers/crypto/chelsio/chtls/chtls_main.c
29f9f684 Atul Gupta 2018-03-19 307
29f9f684 Atul Gupta 2018-03-19 308 static int chtls_uld_state_change(void *handle, enum cxgb4_state new_state)
29f9f684 Atul Gupta 2018-03-19 309 {
29f9f684 Atul Gupta 2018-03-19 310 struct chtls_dev *cdev = handle;
29f9f684 Atul Gupta 2018-03-19 311
29f9f684 Atul Gupta 2018-03-19 312 switch (new_state) {
29f9f684 Atul Gupta 2018-03-19 313 case CXGB4_STATE_UP:
29f9f684 Atul Gupta 2018-03-19 314 chtls_register_dev(cdev);
29f9f684 Atul Gupta 2018-03-19 315 break;
29f9f684 Atul Gupta 2018-03-19 316 case CXGB4_STATE_DOWN:
29f9f684 Atul Gupta 2018-03-19 317 break;
29f9f684 Atul Gupta 2018-03-19 318 case CXGB4_STATE_START_RECOVERY:
29f9f684 Atul Gupta 2018-03-19 @319 case CXGB4_STATE_FATAL_ERROR:
29f9f684 Atul Gupta 2018-03-19 320 break;
29f9f684 Atul Gupta 2018-03-19 321 case CXGB4_STATE_DETACH:
29f9f684 Atul Gupta 2018-03-19 322 mutex_lock(&cdev_mutex);
29f9f684 Atul Gupta 2018-03-19 323 list_del(&cdev->list);
29f9f684 Atul Gupta 2018-03-19 324 mutex_unlock(&cdev_mutex);
29f9f684 Atul Gupta 2018-03-19 325 chtls_free_uld(cdev);
29f9f684 Atul Gupta 2018-03-19 326 break;
29f9f684 Atul Gupta 2018-03-19 327 }
29f9f684 Atul Gupta 2018-03-19 328 return 0;
29f9f684 Atul Gupta 2018-03-19 329 }
29f9f684 Atul Gupta 2018-03-19 330
:::::: The code at line 319 was first introduced by commit
:::::: 29f9f68416a9775029d6cc8135cf3f01995dd9f4 crypto: chtls - Register chtls with net tls
:::::: TO: Atul Gupta <atul.gupta@chelsio.com>
:::::: CC: 0day robot <fengguang.wu@intel.com>
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 55197 bytes --]
^ permalink raw reply
* Re: [PATCH v2 0/3] net: dsa: mv88e6xxx: some fixes
From: David Miller @ 2018-03-20 16:30 UTC (permalink / raw)
To: u.kleine-koenig
Cc: andrew, vivien.didelot, kernel, gregory.clement, netdev,
f.fainelli
In-Reply-To: <20180320094442.18368-1-u.kleine-koenig@pengutronix.de>
From: Uwe Kleine-K�nig <u.kleine-koenig@pengutronix.de>
Date: Tue, 20 Mar 2018 10:44:39 +0100
> these patches target net-next and got approved by Andrew Lunn.
>
> Compared to (implicit) v1, I dropped the patch that I didn't know if it
> was right because of missing documentation on my side. But Andrew
> already cared for that in a patch that is now adfccf118211 in net-next.
Series applied, thank you.
^ permalink raw reply
* Re: [PATCH] net: dev_forward_skb(): Scrub packet's per-netns info only when crossing netns
From: David Miller @ 2018-03-20 16:34 UTC (permalink / raw)
To: LIRAN.ALON; +Cc: netdev, linux-kernel, idan.brown, yuval.shaia
In-Reply-To: <5AB132C5.5010806@ORACLE.COM>
From: Liran Alon <LIRAN.ALON@ORACLE.COM>
Date: Tue, 20 Mar 2018 18:11:49 +0200
> 1. Do we want to make a flag for every bug that is user-space visible?
> I think there is place for consideration on a per-case basis. I still
> don't see how a user can utilize this behaviour. He is basically
> loosing information (skb->mark) without this patch.
And maybe people trying to work in this situation have added code to
get the mark set some other way, or to validate that it is in fact
zero after passing through, which we would break with this change.
If it's set to zero now, it's reasonable to expect it to be zero.
By changing it to non-zero, different rules and routes will match
and this for sure has potential to break things.
^ permalink raw reply
* Re: [PATCH] net: dev_forward_skb(): Scrub packet's per-netns info only when crossing netns
From: Liran Alon @ 2018-03-20 16:39 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-kernel, idan.brown, yuval.shaia
In-Reply-To: <20180320.123401.2138083793709750726.davem@davemloft.net>
On 20/03/18 18:34, David Miller wrote:
> From: Liran Alon <LIRAN.ALON@ORACLE.COM>
> Date: Tue, 20 Mar 2018 18:11:49 +0200
>
>> 1. Do we want to make a flag for every bug that is user-space visible?
>> I think there is place for consideration on a per-case basis. I still
>> don't see how a user can utilize this behaviour. He is basically
>> loosing information (skb->mark) without this patch.
>
> And maybe people trying to work in this situation have added code to
> get the mark set some other way, or to validate that it is in fact
> zero after passing through, which we would break with this change.
>
> If it's set to zero now, it's reasonable to expect it to be zero.
>
> By changing it to non-zero, different rules and routes will match
> and this for sure has potential to break things.
>
OK.
What is your opinion in regards if it's OK to put the flag enabling this
"fix" in /proc/sys/net/core? Do you think it's sufficient?
^ permalink raw reply
* Re: [PATCH net-next 1/1] net/ipv4: disable SMC TCP option with SYN Cookies
From: Eric Dumazet @ 2018-03-20 16:43 UTC (permalink / raw)
To: Eric Dumazet, Ursula Braun, davem
Cc: netdev, linux-s390, schwidefsky, heiko.carstens, raspl
In-Reply-To: <435f82d0-407e-6675-194a-102d83f418f8@gmail.com>
On 03/20/2018 09:21 AM, Eric Dumazet wrote:
>
>
> On 03/20/2018 08:53 AM, Ursula Braun wrote:
>> From: Hans Wippel <hwippel@linux.vnet.ibm.com>
>>
>> Currently, the SMC experimental TCP option in a SYN packet is lost on
>> the server side when SYN Cookies are active. However, the corresponding
>> SYNACK sent back to the client contains the SMC option. This causes an
>> inconsistent view of the SMC capabilities on the client and server.
>>
>> This patch disables the SMC option in the SYNACK when SYN Cookies are
>> active to avoid this issue.
>>
>> Signed-off-by: Hans Wippel <hwippel@linux.vnet.ibm.com>
>> Signed-off-by: Ursula Braun <ubraun@linux.vnet.ibm.com>
>> ---
>> net/ipv4/tcp_output.c | 2 ++
>> 1 file changed, 2 insertions(+)
>>
>> diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
>> index 383cac0ff0ec..22894514feae 100644
>> --- a/net/ipv4/tcp_output.c
>> +++ b/net/ipv4/tcp_output.c
>> @@ -3199,6 +3199,8 @@ struct sk_buff *tcp_make_synack(const struct sock *sk, struct dst_entry *dst,
>> /* Under synflood, we do not attach skb to a socket,
>> * to avoid false sharing.
>> */
>> + if (IS_ENABLED(CONFIG_SMC))
>> + ireq->smc_ok = 0;
>> break;
>> case TCP_SYNACK_FASTOPEN:
>> /* sk is a const pointer, because we want to express multiple
>>
>
> I disagree with net-next qualification.
>
> This fixes a bug, so please send it for net tree, and including an appropriate Fixes: tag.
>
Also, please do not add the fix in tcp_make_synack()
tcp_make_synack() builds an skb, and really should not modify ireq, ideally.
The only reason ireq is not const is because of the skb_set_owner_w().
I would clear it in cookie_v4_check()/cookie_v6_check()
(We could have a common helper to allocate a TCP ireq btw, but this will wait a future patch for net-next)
^ permalink raw reply
* Re: [PATCH] net: dev_forward_skb(): Scrub packet's per-netns info only when crossing netns
From: Liran Alon @ 2018-03-20 16:44 UTC (permalink / raw)
To: Eric W. Biederman
Cc: shmulik.ladkani, netdev, mrv, daniel, davem, linux-kernel,
yuval.shaia, idan.brown
In-Reply-To: <87tvta67gl.fsf@xmission.com>
On 20/03/18 18:24, ebiederm@xmission.com wrote:
>
> I don't believe the current behavior is a bug.
>
> I looked through the history. Basically skb_scrub_packet
> started out as the scrubbing needed for crossing network
> namespaces.
>
> Then tunnels which needed 90% of the functionality started
> calling it, with the xnet flag added. Because the tunnels
> needed to preserve their historic behavior.
>
> Then dev_forward_skb started calling skb_scrub_packet.
>
> A veth pair is supposed to give the same behavior as a cross-over
> cable plugged into two local nics. A cross over cable won't
> preserve things like the skb mark. So I don't see why anyone would
> expect a veth pair to preserve the mark.
I disagree with this argument.
I think that a skb crossing netns is what simulates a real packet
crossing physical computers. Following your argument, why would
skb->mark should be preserved when crossing netdevs on same netns via
routing? But this does today preserve skb->mark.
Therefore, I do think that skb->mark should conceptually only be
scrubbed when crossing netns. Regardless of the netdev used to cross it.
>
> Right now I don't see the point of handling packets that don't cross
> network namespace boundaries specially, other than to preserve backwards
> compatibility.
>
> Eric
>
^ permalink raw reply
* Re: pull-request: can 2018-03-19
From: David Miller @ 2018-03-20 16:45 UTC (permalink / raw)
To: mkl; +Cc: netdev, linux-can, kernel
In-Reply-To: <20180319101431.11032-1-mkl@pengutronix.de>
From: Marc Kleine-Budde <mkl@pengutronix.de>
Date: Mon, 19 Mar 2018 11:14:30 +0100
> this is a pull reqeust of one patch for net/master.
>
> The patch is by Andri Yngvason and fixes a potential use-after-free bug
> in the cc770 driver introduced in the previous pull-request.
Pulled, thank you.
^ permalink raw reply
* Re: [PATCH net] ipv6: old_dport should be a __be16 in __ip6_datagram_connect()
From: David Miller @ 2018-03-20 16:45 UTC (permalink / raw)
To: sbrivio; +Cc: pabeni, weiwan, g.nault, netdev
In-Reply-To: <f747595846809aa8626a2fc6b4bdcda5af75d42a.1521417707.git.sbrivio@redhat.com>
From: Stefano Brivio <sbrivio@redhat.com>
Date: Mon, 19 Mar 2018 11:24:58 +0100
> Fixes: 2f987a76a977 ("net: ipv6: keep sk status consistent after datagram connect failure")
> Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
> Acked-by: Paolo Abeni <pabeni@redhat.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next nfs 6/6] net: Convert rxrpc_net_ops
From: David Howells @ 2018-03-20 16:49 UTC (permalink / raw)
To: Kirill Tkhai
Cc: dhowells, davem, trond.myklebust, anna.schumaker, bfields,
jlayton, keescook, dwindsor, ishkamiel, elena.reshetova,
linux-nfs, linux-afs, netdev
In-Reply-To: <152093820653.8636.15794912193976988473.stgit@localhost.localdomain>
Kirill Tkhai <ktkhai@virtuozzo.com> wrote:
> These pernet_operations modifies rxrpc_net_id-pointed
> per-net entities. There is external link to AF_RXRPC
> in fs/afs/Kconfig, but it seems there is no other
> pernet_operations interested in that per-net entities.
The fs/afs/ namespacing stuff isn't active yet as I'm trying to decide on how
to deal with the DNS cache which also needs namespacing.
> Signed-off-by: Kirill Tkhai <ktkhai@virtuozzo.com>
DaveM: Can you take this into net-next and add:
Acked-by: David Howells <dhowells@redhat.com>
^ permalink raw reply
* Re: tg3 crashes under high load, when using 100Mbits
From: Kai-Heng Feng @ 2018-03-20 16:57 UTC (permalink / raw)
To: Satish Baddipadige
Cc: Siva Reddy Kallam, Prashant Sreedharan, Michael Chan,
Linux Netdev List, Linux Kernel Mailing List, Stanley Hsiao,
Tim Chen
In-Reply-To: <CA+oDAx908Dpn93-c4ogS5F1XZJri9GC_WaFR8wuDKO47kygB5w@mail.gmail.com>
Satish Baddipadige <satish.baddipadige@broadcom.com> wrote:
> On Thu, Feb 15, 2018 at 7:37 PM, Siva Reddy Kallam
> <siva.kallam@broadcom.com> wrote:
>> On Mon, Feb 12, 2018 at 10:59 AM, Siva Reddy Kallam
>> <siva.kallam@broadcom.com> wrote:
>>> On Fri, Feb 9, 2018 at 10:41 AM, Kai Heng Feng
>>> <kai.heng.feng@canonical.com> wrote:
>>>> Hi Broadcom folks,
>>>>
>>>> We are now enabling a new platform with tg3 nic, unfortunately we
>>>> observed
>>>> the bug [1] that dated back to 2015.
>>>> I tried commit 4419bb1cedcd ("tg3: Add workaround to restrict 5762
>>>> MRRS to
>>>> 2048”) but it does’t work.
>>>>
>>>> Do you have any idea how to solve the issue?
>>>>
>>>> [1] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1447664
>>>>
>>>> Kai-Heng
>>> Thank you for reporting. We will check and update you.
>> With link aware mode, the clock speed could be slow and boot code does not
>> complete within the expected time with lower link speeds. Need to override
>> and the clock in driver. We are checking the feasibility of adding
>> this in driver or firmware.
>
> Hi Kai-Heng,
>
> Can you please test the attached patch?
I built a kernel and asked affected users to try.
Thanks for your work.
Kai-Heng
>
> Thanks,
> Satish
> <tg3_5762_clock_override.patch>
^ 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