* [PATCH v2 net] sctp: potential read out of bounds in sctp_ulpevent_type_enabled()
From: Dan Carpenter @ 2017-09-13 23:00 UTC (permalink / raw)
To: Vlad Yasevich
Cc: Neil Horman, David S. Miller, linux-sctp, netdev, kernel-janitors
In-Reply-To: <20170913.092522.934509429497822082.davem@davemloft.net>
This code causes a static checker warning because Smatch doesn't trust
anything that comes from skb->data. I've reviewed this code and I do
think skb->data can be controlled by the user here.
The sctp_event_subscribe struct has 13 __u8 fields and we want to see
if ours is non-zero. sn_type can be any value in the 0-USHRT_MAX range.
We're subtracting SCTP_SN_TYPE_BASE which is 1 << 15 so we could read
either before the start of the struct or after the end.
This is a very old bug and it's surprising that it would go undetected
for so long but my theory is that it just doesn't have a big impact so
it would be hard to notice.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
---
v2: Use reverse-christmas-tree local variable ordering.
diff --git a/include/net/sctp/ulpevent.h b/include/net/sctp/ulpevent.h
index 1060494ac230..b8c86ec1a8f5 100644
--- a/include/net/sctp/ulpevent.h
+++ b/include/net/sctp/ulpevent.h
@@ -153,8 +153,12 @@ __u16 sctp_ulpevent_get_notification_type(const struct sctp_ulpevent *event);
static inline int sctp_ulpevent_type_enabled(__u16 sn_type,
struct sctp_event_subscribe *mask)
{
+ int offset = sn_type - SCTP_SN_TYPE_BASE;
char *amask = (char *) mask;
- return amask[sn_type - SCTP_SN_TYPE_BASE];
+
+ if (offset >= sizeof(struct sctp_event_subscribe))
+ return 0;
+ return amask[offset];
}
/* Given an event subscription, is this event enabled? */
^ permalink raw reply related
* Re: [PATCH] net: Convert int functions to bool
From: Joe Perches @ 2017-09-13 22:55 UTC (permalink / raw)
To: Alexey Dobriyan; +Cc: netdev
In-Reply-To: <20170913223158.GA7860@avx2>
On Thu, 2017-09-14 at 01:31 +0300, Alexey Dobriyan wrote:
> > Global function ipv6_rcv_saddr_equal and static functions
> > ipv6_rcv_saddr_equal and ipv4_rcv_saddr_equal currently return int.
> >
> > bool is slightly more descriptive for these functions so change
> > their return type from int to bool.
>
> From code generation POV "int" is better for non-inlined functions
> especially on non-x86.
I don't agree with you here. For instance:
$ size net/ipv4/*.o*
text data bss dec hex filename
9832 26 0 9858 2682 net/ipv4/inet_connection_sock.o.arm.defconfig.new
9860 26 0 9886 269e net/ipv4/inet_connection_sock.o.arm.defconfig.old
^ permalink raw reply
* Re: 319554f284dd ("inet: don't use sk_v6_rcv_saddr directly") causes bind port regression
From: Cole Robinson @ 2017-09-13 22:49 UTC (permalink / raw)
To: Josef Bacik, Laura Abbott, David S. Miller, Alexey Kuznetsov,
Hideaki YOSHIFUJI
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <E068C58A-DC80-4D98-ADE6-8F05304EC7ED@fb.com>
On 09/13/2017 03:44 PM, Josef Bacik wrote:
> Alright thanks, this should fix it.
>
Still no luck with all three patches applied to fedora 4.12.8-300 RPM. Pretty
sure I didn't mess up the testing but since I rarely do kernel builds it's not
impossible...
Thanks,
Cole
^ permalink raw reply
* Re: [PATCH] net: Convert int functions to bool
From: Alexey Dobriyan @ 2017-09-13 22:31 UTC (permalink / raw)
To: Joe Perches; +Cc: netdev
> Global function ipv6_rcv_saddr_equal and static functions
> ipv6_rcv_saddr_equal and ipv4_rcv_saddr_equal currently return int.
>
> bool is slightly more descriptive for these functions so change
> their return type from int to bool.
>From code generation POV "int" is better for non-inlined functions
especially on non-x86.
Patch bloats even x86_64:
$ ./scripts/bloat-o-meter ../vmlinux-002-do-while ../obj/vmlinux
add/remove: 0/0 grow/shrink: 2/0 up/down: 3/0 (3)
function old new delta
inet_rcv_saddr_equal 38 40 +2
inet_csk_get_port 1300 1301 +1
Total: Before=6084708, After=6084711, chg +0.00%
^ permalink raw reply
* Re: [RFC PATCH] can: m_can: Support higher speed CAN-FD bitrates
From: Franklin S Cooper Jr @ 2017-09-13 21:58 UTC (permalink / raw)
To: wg, mkl, mario.huettel, socketcan, quentin.schulz, edumazet,
linux-can, netdev, linux-kernel, Nori, Sekhar
In-Reply-To: <20170818193947.27862-1-fcooper@ti.com>
On 08/18/2017 02:39 PM, Franklin S Cooper Jr wrote:
> During test transmitting using CAN-FD at high bitrates (4 Mbps) only
> resulted in errors. Scoping the signals I noticed that only a single bit
> was being transmitted and with a bit more investigation realized the actual
> MCAN IP would go back to initialization mode automatically.
>
> It appears this issue is due to the MCAN needing to use the Transmitter
> Delay Compensation Mode as defined in the MCAN User's Guide. When this
> mode is used the User's Guide indicates that the Transmitter Delay
> Compensation Offset register should be set. The document mentions that this
> register should be set to (1/dbitrate)/2*(Func Clk Freq).
>
> Additional CAN-CIA's "Bit Time Requirements for CAN FD" document indicates
> that this TDC mode is only needed for data bit rates above 2.5 Mbps.
> Therefore, only enable this mode and only set TDCO when the data bit rate
> is above 2.5 Mbps.
>
> Signed-off-by: Franklin S Cooper Jr <fcooper@ti.com>
> ---
> I'm pretty surprised that this hasn't been implemented already since
> the primary purpose of CAN-FD is to go beyond 1 Mbps and the MCAN IP
> supports up to 10 Mbps.
>
> So it will be nice to get comments from users of this driver to understand
> if they have been able to use CAN-FD beyond 2.5 Mbps without this patch.
> If they haven't what did they do to get around it if they needed higher
> speeds.
>
> Meanwhile I plan on testing this using a more "realistic" CAN bus to insure
> everything still works at 5 Mbps which is the max speed of my CAN
> transceiver.
ping. Anyone has any thoughts on this?
>
> drivers/net/can/m_can/m_can.c | 24 +++++++++++++++++++++++-
> 1 file changed, 23 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/can/m_can/m_can.c b/drivers/net/can/m_can/m_can.c
> index f4947a7..720e073 100644
> --- a/drivers/net/can/m_can/m_can.c
> +++ b/drivers/net/can/m_can/m_can.c
> @@ -126,6 +126,12 @@ enum m_can_mram_cfg {
> #define DBTP_DSJW_SHIFT 0
> #define DBTP_DSJW_MASK (0xf << DBTP_DSJW_SHIFT)
>
> +/* Transmitter Delay Compensation Register (TDCR) */
> +#define TDCR_TDCO_SHIFT 8
> +#define TDCR_TDCO_MASK (0x7F << TDCR_TDCO_SHIFT)
> +#define TDCR_TDCF_SHIFT 0
> +#define TDCR_TDCF_MASK (0x7F << TDCR_TDCO_SHIFT)
> +
> /* Test Register (TEST) */
> #define TEST_LBCK BIT(4)
>
> @@ -977,6 +983,8 @@ static int m_can_set_bittiming(struct net_device *dev)
> const struct can_bittiming *dbt = &priv->can.data_bittiming;
> u16 brp, sjw, tseg1, tseg2;
> u32 reg_btp;
> + u32 enable_tdc = 0;
> + u32 tdco;
>
> brp = bt->brp - 1;
> sjw = bt->sjw - 1;
> @@ -991,9 +999,23 @@ static int m_can_set_bittiming(struct net_device *dev)
> sjw = dbt->sjw - 1;
> tseg1 = dbt->prop_seg + dbt->phase_seg1 - 1;
> tseg2 = dbt->phase_seg2 - 1;
> +
> + /* TDC is only needed for bitrates beyond 2.5 MBit/s
> + * Specified in the "Bit Time Requirements for CAN FD" document
> + */
> + if (dbt->bitrate > 2500000) {
> + enable_tdc = DBTP_TDC;
> + /* Equation based on Bosch's M_CAN User Manual's
> + * Transmitter Delay Compensation Section
> + */
> + tdco = priv->can.clock.freq / (dbt->bitrate * 2);
> + m_can_write(priv, M_CAN_TDCR, tdco << TDCR_TDCO_SHIFT);
> + }
> +
> reg_btp = (brp << DBTP_DBRP_SHIFT) | (sjw << DBTP_DSJW_SHIFT) |
> (tseg1 << DBTP_DTSEG1_SHIFT) |
> - (tseg2 << DBTP_DTSEG2_SHIFT);
> + (tseg2 << DBTP_DTSEG2_SHIFT) | enable_tdc;
> +
> m_can_write(priv, M_CAN_DBTP, reg_btp);
> }
>
>
^ permalink raw reply
* Re: [patch net] net: sched: fix use-after-free in tcf_action_destroy and tcf_del_walker
From: David Miller @ 2017-09-13 20:59 UTC (permalink / raw)
To: jiri; +Cc: netdev, jhs, xiyou.wangcong, kubakici, mlxsw
In-Reply-To: <20170913205006.GD1981@nanopsycho>
From: Jiri Pirko <jiri@resnulli.us>
Date: Wed, 13 Sep 2017 22:50:06 +0200
> Wed, Sep 13, 2017 at 06:34:28PM CEST, davem@davemloft.net wrote:
>>From: Jiri Pirko <jiri@resnulli.us>
>>Date: Wed, 13 Sep 2017 17:32:37 +0200
>>
>>> From: Jiri Pirko <jiri@mellanox.com>
>>>
>>> Recent commit d7fb60b9cafb ("net_sched: get rid of tcfa_rcu") removed
>>> freeing in call_rcu, which changed already existing hard-to-hit
>>> race condition into 100% hit:
>>>
>>> [ 598.599825] BUG: unable to handle kernel NULL pointer dereference at 0000000000000030
>>> [ 598.607782] IP: tcf_action_destroy+0xc0/0x140
>>>
>>> Or:
>>>
>>> [ 40.858924] BUG: unable to handle kernel NULL pointer dereference at 0000000000000030
>>> [ 40.862840] IP: tcf_generic_walker+0x534/0x820
>>>
>>> Fix this by storing the ops and use them directly for module_put call.
>>>
>>> Fixes: a85a970af265 ("net_sched: move tc_action into tcf_common")
>>> Signed-off-by: Jiri Pirko <jiri@mellanox.com>
>>
>>Applied, thanks Jiri.
>
> Oh, I forgot to mention, this would be nice to push to stable.
Ok, queued up.
^ permalink raw reply
* [PATCH] net: Convert int functions to bool
From: Joe Perches @ 2017-09-13 20:58 UTC (permalink / raw)
To: David S. Miller, Alexey Kuznetsov, Hideaki YOSHIFUJI; +Cc: netdev, linux-kernel
Global function ipv6_rcv_saddr_equal and static functions
ipv6_rcv_saddr_equal and ipv4_rcv_saddr_equal currently return int.
bool is slightly more descriptive for these functions so change
their return type from int to bool.
Signed-off-by: Joe Perches <joe@perches.com>
---
include/net/addrconf.h | 4 ++--
net/ipv4/inet_connection_sock.c | 36 ++++++++++++++++++------------------
2 files changed, 20 insertions(+), 20 deletions(-)
diff --git a/include/net/addrconf.h b/include/net/addrconf.h
index f44ff2476758..87981cd63180 100644
--- a/include/net/addrconf.h
+++ b/include/net/addrconf.h
@@ -94,8 +94,8 @@ int __ipv6_get_lladdr(struct inet6_dev *idev, struct in6_addr *addr,
u32 banned_flags);
int ipv6_get_lladdr(struct net_device *dev, struct in6_addr *addr,
u32 banned_flags);
-int inet_rcv_saddr_equal(const struct sock *sk, const struct sock *sk2,
- bool match_wildcard);
+bool inet_rcv_saddr_equal(const struct sock *sk, const struct sock *sk2,
+ bool match_wildcard);
void addrconf_join_solict(struct net_device *dev, const struct in6_addr *addr);
void addrconf_leave_solict(struct inet6_dev *idev, const struct in6_addr *addr);
diff --git a/net/ipv4/inet_connection_sock.c b/net/ipv4/inet_connection_sock.c
index 4089c013cb03..054b26295638 100644
--- a/net/ipv4/inet_connection_sock.c
+++ b/net/ipv4/inet_connection_sock.c
@@ -39,11 +39,11 @@ EXPORT_SYMBOL(inet_csk_timer_bug_msg);
* IPV6_ADDR_ANY only equals to IPV6_ADDR_ANY,
* and 0.0.0.0 equals to 0.0.0.0 only
*/
-static int ipv6_rcv_saddr_equal(const struct in6_addr *sk1_rcv_saddr6,
- const struct in6_addr *sk2_rcv_saddr6,
- __be32 sk1_rcv_saddr, __be32 sk2_rcv_saddr,
- bool sk1_ipv6only, bool sk2_ipv6only,
- bool match_wildcard)
+static bool ipv6_rcv_saddr_equal(const struct in6_addr *sk1_rcv_saddr6,
+ const struct in6_addr *sk2_rcv_saddr6,
+ __be32 sk1_rcv_saddr, __be32 sk2_rcv_saddr,
+ bool sk1_ipv6only, bool sk2_ipv6only,
+ bool match_wildcard)
{
int addr_type = ipv6_addr_type(sk1_rcv_saddr6);
int addr_type2 = sk2_rcv_saddr6 ? ipv6_addr_type(sk2_rcv_saddr6) : IPV6_ADDR_MAPPED;
@@ -52,29 +52,29 @@ static int ipv6_rcv_saddr_equal(const struct in6_addr *sk1_rcv_saddr6,
if (addr_type == IPV6_ADDR_MAPPED && addr_type2 == IPV6_ADDR_MAPPED) {
if (!sk2_ipv6only) {
if (sk1_rcv_saddr == sk2_rcv_saddr)
- return 1;
+ return true;
if (!sk1_rcv_saddr || !sk2_rcv_saddr)
return match_wildcard;
}
- return 0;
+ return false;
}
if (addr_type == IPV6_ADDR_ANY && addr_type2 == IPV6_ADDR_ANY)
- return 1;
+ return true;
if (addr_type2 == IPV6_ADDR_ANY && match_wildcard &&
!(sk2_ipv6only && addr_type == IPV6_ADDR_MAPPED))
- return 1;
+ return true;
if (addr_type == IPV6_ADDR_ANY && match_wildcard &&
!(sk1_ipv6only && addr_type2 == IPV6_ADDR_MAPPED))
- return 1;
+ return true;
if (sk2_rcv_saddr6 &&
ipv6_addr_equal(sk1_rcv_saddr6, sk2_rcv_saddr6))
- return 1;
+ return true;
- return 0;
+ return false;
}
#endif
@@ -82,20 +82,20 @@ static int ipv6_rcv_saddr_equal(const struct in6_addr *sk1_rcv_saddr6,
* match_wildcard == false: addresses must be exactly the same, i.e.
* 0.0.0.0 only equals to 0.0.0.0
*/
-static int ipv4_rcv_saddr_equal(__be32 sk1_rcv_saddr, __be32 sk2_rcv_saddr,
- bool sk2_ipv6only, bool match_wildcard)
+static bool ipv4_rcv_saddr_equal(__be32 sk1_rcv_saddr, __be32 sk2_rcv_saddr,
+ bool sk2_ipv6only, bool match_wildcard)
{
if (!sk2_ipv6only) {
if (sk1_rcv_saddr == sk2_rcv_saddr)
- return 1;
+ return true;
if (!sk1_rcv_saddr || !sk2_rcv_saddr)
return match_wildcard;
}
- return 0;
+ return false;
}
-int inet_rcv_saddr_equal(const struct sock *sk, const struct sock *sk2,
- bool match_wildcard)
+bool inet_rcv_saddr_equal(const struct sock *sk, const struct sock *sk2,
+ bool match_wildcard)
{
#if IS_ENABLED(CONFIG_IPV6)
if (sk->sk_family == AF_INET6)
--
2.10.0.rc2.1.g053435c
^ permalink raw reply related
* Re: [patch net] net: sched: fix use-after-free in tcf_action_destroy and tcf_del_walker
From: Jiri Pirko @ 2017-09-13 20:50 UTC (permalink / raw)
To: David Miller; +Cc: netdev, jhs, xiyou.wangcong, kubakici, mlxsw
In-Reply-To: <20170913.093428.806129519464331602.davem@davemloft.net>
Wed, Sep 13, 2017 at 06:34:28PM CEST, davem@davemloft.net wrote:
>From: Jiri Pirko <jiri@resnulli.us>
>Date: Wed, 13 Sep 2017 17:32:37 +0200
>
>> From: Jiri Pirko <jiri@mellanox.com>
>>
>> Recent commit d7fb60b9cafb ("net_sched: get rid of tcfa_rcu") removed
>> freeing in call_rcu, which changed already existing hard-to-hit
>> race condition into 100% hit:
>>
>> [ 598.599825] BUG: unable to handle kernel NULL pointer dereference at 0000000000000030
>> [ 598.607782] IP: tcf_action_destroy+0xc0/0x140
>>
>> Or:
>>
>> [ 40.858924] BUG: unable to handle kernel NULL pointer dereference at 0000000000000030
>> [ 40.862840] IP: tcf_generic_walker+0x534/0x820
>>
>> Fix this by storing the ops and use them directly for module_put call.
>>
>> Fixes: a85a970af265 ("net_sched: move tc_action into tcf_common")
>> Signed-off-by: Jiri Pirko <jiri@mellanox.com>
>
>Applied, thanks Jiri.
Oh, I forgot to mention, this would be nice to push to stable.
^ permalink raw reply
* Re: [PATCH] MAINTAINERS: review Renesas DT bindings as well
From: David Miller @ 2017-09-13 20:41 UTC (permalink / raw)
To: sergei.shtylyov; +Cc: netdev, linux-renesas-soc, linux-kernel
In-Reply-To: <20170913192913.138491844@cogentembedded.com>
From: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Date: Wed, 13 Sep 2017 22:28:53 +0300
> When adding myself as a reviewer for the Renesas Ethernet drivers
> I somehow forgot about the bindings -- I want to review them as well.
>
> Fixes: 8e6569af3a1b ("MAINTAINERS: add myself as Renesas Ethernet drivers reviewer")
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Applied.
^ permalink raw reply
* Re: [PATCH net] net_sched: gen_estimator: fix scaling error in bytes/packets samples
From: David Miller @ 2017-09-13 20:34 UTC (permalink / raw)
To: eric.dumazet; +Cc: nuclearcat, netdev, jhs, xiyou.wangcong, jiri
In-Reply-To: <1505326605.15310.193.camel@edumazet-glaptop3.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Wed, 13 Sep 2017 11:16:45 -0700
> From: Eric Dumazet <edumazet@google.com>
>
> Denys reported wrong rate estimations with HTB classes.
>
> It appears the bug was added in linux-4.10, since my tests
> where using intervals of one second only.
>
> HTB using 4 sec default rate estimators, reported rates
> were 4x higher.
>
> We need to properly scale the bytes/packets samples before
> integrating them in EWMA.
>
> Tested:
...
> Fixes: 1c0d32fde5bd ("net_sched: gen_estimator: complete rewrite of rate estimators")
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Reported-by: Denys Fedoryshchenko <nuclearcat@nuclearcat.com>
Applied and queued up for -stable, thanks Eric.
^ permalink raw reply
* Re: [PATCH v2] geneve: Fix setting ttl value in collect metadata mode
From: Pravin Shelar @ 2017-09-13 20:22 UTC (permalink / raw)
To: 严海双
Cc: David S. Miller, Girish Moodalbail,
Linux Kernel Network Developers, linux-kernel
In-Reply-To: <95A24784-0575-47CE-A485-B2A59911262A@cmss.chinamobile.com>
On Wed, Sep 13, 2017 at 4:15 AM, 严海双 <yanhaishuang@cmss.chinamobile.com> wrote:
>
>
>> On 2017年9月13日, at 上午7:43, Pravin Shelar <pshelar@ovn.org> wrote:
>>
>> On Tue, Sep 12, 2017 at 12:05 AM, Haishuang Yan
>> <yanhaishuang@cmss.chinamobile.com> wrote:
>>> Similar to vxlan/ipip tunnel, if key->tos is zero in collect metadata
>>> mode, tos should also fallback to ip{4,6}_dst_hoplimit.
>>>
>>> Signed-off-by: Haishuang Yan <yanhaishuang@cmss.chinamobile.com>
>>>
>>> ---
>>> Changes since v2:
>>> * Make the commit message more clearer.
>>> ---
>>> drivers/net/geneve.c | 6 ++----
>>> 1 file changed, 2 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/drivers/net/geneve.c b/drivers/net/geneve.c
>>> index f640407..d52a65f 100644
>>> --- a/drivers/net/geneve.c
>>> +++ b/drivers/net/geneve.c
>>> @@ -834,11 +834,10 @@ static int geneve_xmit_skb(struct sk_buff *skb, struct net_device *dev,
>>> sport = udp_flow_src_port(geneve->net, skb, 1, USHRT_MAX, true);
>>> if (geneve->collect_md) {
>>> tos = ip_tunnel_ecn_encap(key->tos, ip_hdr(skb), skb);
>>> - ttl = key->ttl;
>>> } else {
>>> tos = ip_tunnel_ecn_encap(fl4.flowi4_tos, ip_hdr(skb), skb);
>>> - ttl = key->ttl ? : ip4_dst_hoplimit(&rt->dst);
>>> }
>>> + ttl = key->ttl ? : ip4_dst_hoplimit(&rt->dst);
>>> df = key->tun_flags & TUNNEL_DONT_FRAGMENT ? htons(IP_DF) : 0;
>>>
>> This changes user API of Geneve collect-metadata mode. I do not see
>> good reason for this. Why user can not set right TTL for the flow?
>>
>
> For example, I test this case with script samples/bpf/test_tunnel_bpf.sh,
> and modify samples/bpf/tcbpf2_kern.c with following patch:
>
But user is suppose to specify the TTL in collect-md mode for Geneve
tunnel. That is the API.
^ permalink raw reply
* Re: 319554f284dd ("inet: don't use sk_v6_rcv_saddr directly") causes bind port regression
From: Josef Bacik @ 2017-09-13 20:11 UTC (permalink / raw)
To: Chuck Ebbert
Cc: Laura Abbott, David S. Miller, Alexey Kuznetsov,
Hideaki YOSHIFUJI, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, Cole Robinson
In-Reply-To: <20170913154750.100881c0@gmail.com>
> On Sep 13, 2017, at 12:46 PM, Chuck Ebbert <cebbert.lkml@gmail.com> wrote:
>
> On Wed, 13 Sep 2017 17:28:25 +0000
> Josef Bacik <jbacik@fb.com> wrote:
>
>> Sorry I thought I had made this other fix, can you apply this on top
>> of the other one and try that? I have more things to try if this
>> doesn’t work, sorry you are playing go between, but I want to make
>> sure I know _which_ fix actually fixes the problem, and then clean up
>> in followup patches. Thanks,
>>
>> Josef
>>
>> On 9/13/17, 8:45 AM, "Laura Abbott" <labbott@redhat.com> wrote:
>>
>> On 09/12/2017 04:12 PM, Josef Bacik wrote:
>>> First I’m super sorry for the top post, I’m at plumbers and I
>>> forgot to upload my muttrc to my new cloud instance, so I’m screwed
>>> using outlook.
>>>
>>> I have a completely untested, uncompiled patch that I think will
>>> fix the problem, would you mind giving it a go? Thanks,
>>>
>>> Josef
>>
>> Thanks for the quick turnaround. Unfortunately, the problem is still
>> reproducible according to the reporter.
>>
>> Thanks,
>> Laura
>
> I am confused by the patch that originally caused this:
>
> if (sk->sk_family == AF_INET6)
> return ipv6_rcv_saddr_equal(&sk->sk_v6_rcv_saddr,
> - &sk2->sk_v6_rcv_saddr,
> + inet6_rcv_saddr(sk2),
> sk->sk_rcv_saddr,
> sk2->sk_rcv_saddr,
>
> Shouldn't the first argument also be changed to use inet6_rcv_saddr()?
No we know sk is IPv6 so it's alright to use directly. Thanks,
Josef
^ permalink raw reply
* Re: 319554f284dd ("inet: don't use sk_v6_rcv_saddr directly") causes bind port regression
From: Chuck Ebbert @ 2017-09-13 19:47 UTC (permalink / raw)
To: Josef Bacik
Cc: Laura Abbott, David S. Miller, Alexey Kuznetsov,
Hideaki YOSHIFUJI, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, Cole Robinson
In-Reply-To: <EF55EF02-AD40-4F06-8C07-4F9F4221BFE6@fb.com>
On Wed, 13 Sep 2017 17:28:25 +0000
Josef Bacik <jbacik@fb.com> wrote:
> Sorry I thought I had made this other fix, can you apply this on top
> of the other one and try that? I have more things to try if this
> doesn’t work, sorry you are playing go between, but I want to make
> sure I know _which_ fix actually fixes the problem, and then clean up
> in followup patches. Thanks,
>
> Josef
>
> On 9/13/17, 8:45 AM, "Laura Abbott" <labbott@redhat.com> wrote:
>
> On 09/12/2017 04:12 PM, Josef Bacik wrote:
> > First I’m super sorry for the top post, I’m at plumbers and I
> > forgot to upload my muttrc to my new cloud instance, so I’m screwed
> > using outlook.
> >
> > I have a completely untested, uncompiled patch that I think will
> > fix the problem, would you mind giving it a go? Thanks,
> >
> > Josef
>
> Thanks for the quick turnaround. Unfortunately, the problem is still
> reproducible according to the reporter.
>
> Thanks,
> Laura
I am confused by the patch that originally caused this:
if (sk->sk_family == AF_INET6)
return ipv6_rcv_saddr_equal(&sk->sk_v6_rcv_saddr,
- &sk2->sk_v6_rcv_saddr,
+ inet6_rcv_saddr(sk2),
sk->sk_rcv_saddr,
sk2->sk_rcv_saddr,
Shouldn't the first argument also be changed to use inet6_rcv_saddr()?
^ permalink raw reply
* Re: 319554f284dd ("inet: don't use sk_v6_rcv_saddr directly") causes bind port regression
From: Josef Bacik @ 2017-09-13 19:44 UTC (permalink / raw)
To: Cole Robinson, Laura Abbott, David S. Miller, Alexey Kuznetsov,
Hideaki YOSHIFUJI
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <a4807126-1f17-20bd-dace-d9c6b6c4787b@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 731 bytes --]
Alright thanks, this should fix it.
Josef
On 9/13/17, 12:14 PM, "Cole Robinson" <crobinso@redhat.com> wrote:
On 09/13/2017 01:40 PM, Cole Robinson wrote:
> On 09/13/2017 01:28 PM, Josef Bacik wrote:
>> Sorry I thought I had made this other fix, can you apply this on top of the other one and try that? I have more things to try if this doesn’t work, sorry you are playing go between, but I want to make sure I know _which_ fix actually fixes the problem, and then clean up in followup patches. Thanks,
>>
>
> I'm the bug reporter. I'll combine the two patches and report back
>
Nope, issue is still present with both patches applied. Tried my own build and
a package Laura provided
Thanks,
Cole
[-- Attachment #2: 0001-net-don-t-fast-patch-mismatched-sockets-in-STRICT-mo.patch --]
[-- Type: application/octet-stream, Size: 1182 bytes --]
From 8d3da6d30a7c63034d4ff7d4fc33ea9e3f23cf41 Mon Sep 17 00:00:00 2001
From: Josef Bacik <josef@toxicpanda.com>
Date: Wed, 13 Sep 2017 12:42:13 -0700
Subject: [PATCH] net: don't fast patch mismatched sockets in STRICT mode
With FASTREUSE_STRICT we may have sockets on the tb that don't match our
fast_sk information, so if our new socket don't strictly match the
fast_sk info we need to not go down the fast path and do the
inet_csk_bind_conflict so we can look at the other sockets on the tb.
Signed-off-by: Josef Bacik <josef@toxicpanda.com>
---
net/ipv4/inet_connection_sock.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/net/ipv4/inet_connection_sock.c b/net/ipv4/inet_connection_sock.c
index ff8b15a99e42..fe9cf4862de2 100644
--- a/net/ipv4/inet_connection_sock.c
+++ b/net/ipv4/inet_connection_sock.c
@@ -263,6 +263,8 @@ static inline int sk_reuseport_match(struct inet_bind_bucket *tb,
*/
if (tb->fastreuseport == FASTREUSEPORT_ANY)
return 1;
+ if (tb->fast_ipv6_only && tb->fast_sk_family != sk->sk_family)
+ return 0;
#if IS_ENABLED(CONFIG_IPV6)
if (tb->fast_sk_family == AF_INET6)
return ipv6_rcv_saddr_equal(&tb->fast_v6_rcv_saddr,
--
2.13.5
^ permalink raw reply related
* Re: RFC: Audit Kernel Container IDs
From: Carlos O'Donell @ 2017-09-13 19:33 UTC (permalink / raw)
To: Richard Guy Briggs, cgroups, Linux Containers, Linux API,
Linux Audit, Linux FS Devel, Linux Kernel,
Linux Network Development
Cc: Aristeu Rozanski, David Howells, Eric W. Biederman, Eric Paris,
jlayton, Andy Lutomirski, mszeredi, Paul Moore, Serge E. Hallyn,
Steve Grubb, trondmy, Al Viro
In-Reply-To: <20170913171328.GP3405@madcap2.tricolour.ca>
On 09/13/2017 12:13 PM, Richard Guy Briggs wrote:
> Containers are a userspace concept. The kernel knows nothing of them.
I am looking at this RFC from a userspace perspective, particularly from
the loader's point of view and the unshare syscall and the semantics that
arise from the use of it.
At a high level what you are doing is providing a way to group, without
hierarchy, processes and namespaces. The processes can move between
container's if they have CAP_CONTAINER_ADMIN and can open and write to
a special proc file.
* With unshare a thread may dissociate part of its execution context and
therefore see a distinct mount namespace. When you say "process" in this
particular RFC do you exclude the fact that a thread might be in a
distinct container from the rest of the threads in the process?
> The Linux audit system needs a way to be able to track the container
> provenance of events and actions. Audit needs the kernel's help to do
> this.
* Why does the Linux audit system need to tracker container provenance?
- How does it help to provide better audit messages?
- Is it be enough to list the namespace that a process occupies?
* Why does it need the kernel's help?
- Is there a race condition that is only fixable with kernel support?
- Or is it easier with kernel help but not required?
Providing background on these questions would help clarify the
design requirements.
> Since the concept of a container is entirely a userspace concept, a
> trigger signal from the userspace container orchestration system
> initiates this. This will define a point in time and a set of resources
> associated with a particular container with an audit container ID.
Please don't use the word 'signal', I suggest 'register' since you are
writing to a filesystem.
> The trigger is a pseudo filesystem (proc, since PID tree already exists)
> write of a u64 representing the container ID to a file representing a
> process that will become the first process in a new container.
> This might place restrictions on mount namespaces required to define a
> container, or at least careful checking of namespaces in the kernel to
> verify permissions of the orchestrator so it can't change its own
> container ID.
> A bind mount of nsfs may be necessary in the container orchestrator's
> mntNS.
>
> Require a new CAP_CONTAINER_ADMIN to be able to write to the pseudo
> filesystem to have this action permitted. At that time, record the
> child container's user-supplied 64-bit container identifier along with
What is a "child container?" Containers don't have any hierarchy.
I assume that if you don't have CAP_CONTAINER_ADMIN, that nothing prevents
your continued operation as we have today?
> the child container's first process (which may become the container's
> "init" process) process ID (referenced from the initial PID namespace),
> all namespace IDs (in the form of a nsfs device number and inode number
> tuple) in a new auxilliary record AUDIT_CONTAINER with a qualifying
> op=$action field.
What kind of requirement is there on the first tid/pid registering
the container ID? What if the 8th tid/pid does the registration?
Would that mean that the first process of the container did not
register? It seems like you are suggesting that the registration
by the 8th tid/pid causes a cascading registration progress,
registering all tid/pids in the same grouping? Is that true?
> Issue a new auxilliary record AUDIT_CONTAINER_INFO for each valid
> container ID present on an auditable action or event.
>
> Forked and cloned processes inherit their parent's container ID,
> referenced in the process' audit_context struct.
So a cloned process with CLONE_NEWNS has the came container ID
as the parent process that called clone, at least until the clone
has time to change to a new container ID?
Do you forsee any case where someone might need a semantic that is
slightly different? For example wanting to set the container ID on
clone?
> Log the creation of every namespace, inheriting/adding its spawning
> process' containerID(s), if applicable. Include the spawning and
> spawned namespace IDs (device and inode number tuples).
> [AUDIT_NS_CREATE, AUDIT_NS_DESTROY] [clone(2), unshare(2), setns(2)]
> Note: At this point it appears only network namespaces may need to track
> container IDs apart from processes since incoming packets may cause an
> auditable event before being associated with a process.
OK.
> Log the destruction of every namespace when it is no longer used by any
> process, include the namespace IDs (device and inode number tuples).
> [AUDIT_NS_DESTROY] [process exit, unshare(2), setns(2)]
>
> Issue a new auxilliary record AUDIT_NS_CHANGE listing (opt: op=$action)
> the parent and child namespace IDs for any changes to a process'
> namespaces. [setns(2)]
> Note: It may be possible to combine AUDIT_NS_* record formats and
> distinguish them with an op=$action field depending on the fields
> required for each message type.
>
> A process can be moved from one container to another by using the
> container assignment method outlined above a second time.
OK.
> When a container ceases to exist because the last process in that
> container has exited and hence the last namespace has been destroyed and
> its refcount dropping to zero, log the fact.
> (This latter is likely needed for certification accountability.) A
> container object may need a list of processes and/or namespaces.
OK.
> A namespace cannot directly migrate from one container to another but
> could be assigned to a newly spawned container. A namespace can be
> moved from one container to another indirectly by having that namespace
> used in a second process in another container and then ending all the
> processes in the first container.
OK.
> Feedback please.
--
Cheers,
Carlos.
^ permalink raw reply
* [PATCH] MAINTAINERS: review Renesas DT bindings as well
From: Sergei Shtylyov @ 2017-09-13 19:28 UTC (permalink / raw)
To: netdev; +Cc: linux-renesas-soc, linux-kernel, Sergei Shtylyov
[-- Attachment #1: MAINTAINERS-review-Renesas-DT-bindings-as-well.patch --]
[-- Type: text/plain, Size: 880 bytes --]
When adding myself as a reviewer for the Renesas Ethernet drivers
I somehow forgot about the bindings -- I want to review them as well.
Fixes: 8e6569af3a1b ("MAINTAINERS: add myself as Renesas Ethernet drivers reviewer")
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
---
The patch is against DaveM's 'net.git' repo.
MAINTAINERS | 2 ++
1 file changed, 2 insertions(+)
Index: net/MAINTAINERS
===================================================================
--- net.orig/MAINTAINERS
+++ net/MAINTAINERS
@@ -11379,6 +11379,8 @@ RENESAS ETHERNET DRIVERS
R: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
L: netdev@vger.kernel.org
L: linux-renesas-soc@vger.kernel.org
+F: Documentation/devicetree/bindings/net/renesas,*.txt
+F: Documentation/devicetree/bindings/net/sh_eth.txt
F: drivers/net/ethernet/renesas/
F: include/linux/sh_eth.h
^ permalink raw reply
* Re: 319554f284dd ("inet: don't use sk_v6_rcv_saddr directly") causes bind port regression
From: Cole Robinson @ 2017-09-13 19:13 UTC (permalink / raw)
To: Josef Bacik, Laura Abbott, David S. Miller, Alexey Kuznetsov,
Hideaki YOSHIFUJI
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <370b38d5-346c-91df-4ad4-79886ae3a9ba@redhat.com>
On 09/13/2017 01:40 PM, Cole Robinson wrote:
> On 09/13/2017 01:28 PM, Josef Bacik wrote:
>> Sorry I thought I had made this other fix, can you apply this on top of the other one and try that? I have more things to try if this doesn’t work, sorry you are playing go between, but I want to make sure I know _which_ fix actually fixes the problem, and then clean up in followup patches. Thanks,
>>
>
> I'm the bug reporter. I'll combine the two patches and report back
>
Nope, issue is still present with both patches applied. Tried my own build and
a package Laura provided
Thanks,
Cole
^ permalink raw reply
* [PATCH] ath10k: make ath10k_hw_ce_regs const
From: Bhumika Goyal @ 2017-09-13 19:01 UTC (permalink / raw)
To: julia.lawall, kvalo, ath10k, linux-wireless, netdev, linux-kernel
Cc: Bhumika Goyal
Make them const as they are not modified in the file referencing
them. They are only stored in the const field 'hw_ce_reg' of an ath10k
structure. Also, make the declarations in the header const.
Signed-off-by: Bhumika Goyal <bhumirks@gmail.com>
---
drivers/net/wireless/ath/ath10k/hw.c | 4 ++--
drivers/net/wireless/ath/ath10k/hw.h | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/hw.c b/drivers/net/wireless/ath/ath10k/hw.c
index a860691..07df7c6 100644
--- a/drivers/net/wireless/ath/ath10k/hw.c
+++ b/drivers/net/wireless/ath/ath10k/hw.c
@@ -310,7 +310,7 @@
.wm_high = &wcn3990_dst_wm_high,
};
-struct ath10k_hw_ce_regs wcn3990_ce_regs = {
+const struct ath10k_hw_ce_regs wcn3990_ce_regs = {
.sr_base_addr = 0x00000000,
.sr_size_addr = 0x00000008,
.dr_base_addr = 0x0000000c,
@@ -457,7 +457,7 @@ struct ath10k_hw_ce_regs wcn3990_ce_regs = {
.wm_high = &qcax_dst_wm_high,
};
-struct ath10k_hw_ce_regs qcax_ce_regs = {
+const struct ath10k_hw_ce_regs qcax_ce_regs = {
.sr_base_addr = 0x00000000,
.sr_size_addr = 0x00000004,
.dr_base_addr = 0x00000008,
diff --git a/drivers/net/wireless/ath/ath10k/hw.h b/drivers/net/wireless/ath/ath10k/hw.h
index 0c089f6..f80840f 100644
--- a/drivers/net/wireless/ath/ath10k/hw.h
+++ b/drivers/net/wireless/ath/ath10k/hw.h
@@ -369,8 +369,8 @@ struct ath10k_hw_values {
extern const struct ath10k_hw_values qca9888_values;
extern const struct ath10k_hw_values qca4019_values;
extern const struct ath10k_hw_values wcn3990_values;
-extern struct ath10k_hw_ce_regs wcn3990_ce_regs;
-extern struct ath10k_hw_ce_regs qcax_ce_regs;
+extern const struct ath10k_hw_ce_regs wcn3990_ce_regs;
+extern const struct ath10k_hw_ce_regs qcax_ce_regs;
void ath10k_hw_fill_survey_time(struct ath10k *ar, struct survey_info *survey,
u32 cc, u32 rcc, u32 cc_prev, u32 rcc_prev);
--
1.9.1
^ permalink raw reply related
* Re: scheduling while atomic from vmci_transport_recv_stream_cb in 3.16 kernels
From: Jorgen S. Hansen @ 2017-09-13 18:58 UTC (permalink / raw)
To: Michal Hocko
Cc: Aditya Sarwade, Thomas Hellstrom, LKML, netdev@vger.kernel.org,
Masik Petr, Ben Hutchings, Sasha Levin, Stable tree
In-Reply-To: <20170913151939.gf7n6rvvjtz47tz7@dhcp22.suse.cz>
> On Sep 13, 2017, at 5:19 PM, Michal Hocko <mhocko@kernel.org> wrote:
>
> On Wed 13-09-17 15:07:26, Jorgen S. Hansen wrote:
>>
>>> On Sep 12, 2017, at 11:08 AM, Michal Hocko <mhocko@kernel.org> wrote:
>>>
>>> Hi,
>>> we are seeing the following splat with Debian 3.16 stable kernel
>>>
>>> BUG: scheduling while atomic: MATLAB/26771/0x00000100
>>> Modules linked in: veeamsnap(O) hmac cbc cts nfsv4 dns_resolver rpcsec_gss_krb5 nfsd auth_rpcgss oid_registry nfs_acl nfs lockd fscache sunrpc vmw_vso$
>>> CPU: 0 PID: 26771 Comm: MATLAB Tainted: G O 3.16.0-4-amd64 #1 Debian 3.16.7-ckt20-1+deb8u3
>>> Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 09/21/2015
>>> ffff88315c1e4c20 ffffffff8150db3f ffff88193f803dc8 ffffffff8150acdf
>>> ffffffff815103a2 0000000000012f00 ffff8819423dbfd8 0000000000012f00
>>> ffff88315c1e4c20 ffff88193f803dc8 ffff88193f803d50 ffff88193f803dc0
>>> Call Trace:
>>> <IRQ> [<ffffffff8150db3f>] ? dump_stack+0x41/0x51
>>> [<ffffffff8150acdf>] ? __schedule_bug+0x48/0x55
>>> [<ffffffff815103a2>] ? __schedule+0x5d2/0x700
>>> [<ffffffff8150f9b9>] ? schedule_timeout+0x229/0x2a0
>>> [<ffffffff8109ba70>] ? select_task_rq_fair+0x390/0x700
>>> [<ffffffff8109f780>] ? check_preempt_wakeup+0x120/0x1d0
>>> [<ffffffff81510eb8>] ? wait_for_completion+0xa8/0x120
>>> [<ffffffff81096de0>] ? wake_up_state+0x10/0x10
>>> [<ffffffff810c3da0>] ? call_rcu_bh+0x20/0x20
>>> [<ffffffff810c180b>] ? wait_rcu_gp+0x4b/0x60
>>> [<ffffffff810c17b0>] ? ftrace_raw_output_rcu_utilization+0x40/0x40
>>> [<ffffffffa02ca6f5>] ? vmci_event_unsubscribe+0x75/0xb0 [vmw_vmci]
>>> [<ffffffffa031f5cd>] ? vmci_transport_destruct+0x1d/0xe0 [vmw_vsock_vmci_transport]
>>> [<ffffffffa03167e3>] ? vsock_sk_destruct+0x13/0x60 [vsock]
>>> [<ffffffff81409f7a>] ? __sk_free+0x1a/0x130
>>> [<ffffffffa0320218>] ? vmci_transport_recv_stream_cb+0x1e8/0x2d0 [vmw_vsock_vmci_transport]
>>> [<ffffffffa02c9cba>] ? vmci_datagram_invoke_guest_handler+0xaa/0xd0 [vmw_vmci]
>>> [<ffffffffa02cab51>] ? vmci_dispatch_dgs+0xc1/0x200 [vmw_vmci]
>>> [<ffffffff8106c294>] ? tasklet_action+0xf4/0x100
>>> [<ffffffff8106c681>] ? __do_softirq+0xf1/0x290
>>> [<ffffffff8106ca55>] ? irq_exit+0x95/0xa0
>>> [<ffffffff81516b22>] ? do_IRQ+0x52/0xe0
>>> [<ffffffff8151496d>] ? common_interrupt+0x6d/0x6d
>>>
>>> AFAICS this has been fixed by 4ef7ea9195ea ("VSOCK: sock_put wasn't safe
>>> to call in interrupt context") but this patch hasn't been backported to
>>> stable trees. It applies cleanly on top of 3.16 stable tree but I am not
>>> familiar with the code to send the backport to the stable maintainer
>>> directly.
>>>
>>> Could you double check that the patch below (just a blind cherry-pick)
>>> is correct and it doesn't need additional patches on top?
>>
>> Hi,
>>
>> The patch below has been used to fix the above issue by other distros
>> - among them Redhat for the 3.10 kernel, so it should work for 3.16 as
>> well.
>
> Thanks for the confirmation. I do not see 4ef7ea9195ea ("VSOCK: sock_put
> wasn't safe to call in interrupt context") in 3.10 stable branch
> though.
>
>> In addition to the patch above, there are two other patches that
>> need to be applied on top for the fix to be correct:
>>
>> 8566b86ab9f0f45bc6f7dd422b21de9d0cf5415a "VSOCK: Fix lockdep issue."
>>
>> and
>>
>> 8ab18d71de8b07d2c4d6f984b718418c09ea45c5 "VSOCK: Detach QP check should filter out non matching QPs."
>
> Good to know. I will send all three patches cherry-picked on top of the
> current 3.16 stable branch. Could you have a look please?
The patch series look good to me.
Thanks for taking care of this,
Jorgen
^ permalink raw reply
* Re: [PATCH v5 05/10] dt-bindings: net: dwmac-sun8i: update documentation about integrated PHY
From: Rob Herring @ 2017-09-13 18:20 UTC (permalink / raw)
To: Corentin Labbe
Cc: Maxime Ripard, mark.rutland-5wv7dgnIgG8, wens-jdAy2FN1RRM,
linux-I+IVW8TIWO2tmTQ+vhA3Yw, catalin.marinas-5wv7dgnIgG8,
will.deacon-5wv7dgnIgG8, peppe.cavallaro-qxv4g6HH51o,
alexandre.torgue-qxv4g6HH51o, andrew-g2DYL2Zd6BY,
f.fainelli-Re5JQEeQqe8AvxtiuMwx3w, netdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20170908074325.GB29999@Red>
On Fri, Sep 08, 2017 at 09:43:25AM +0200, Corentin Labbe wrote:
> On Fri, Sep 08, 2017 at 09:25:38AM +0200, Maxime Ripard wrote:
> > On Fri, Sep 08, 2017 at 09:11:51AM +0200, Corentin Labbe wrote:
> > > This patch add documentation about the MDIO switch used on sun8i-h3-emac
> > > for integrated PHY.
> > >
> > > Signed-off-by: Corentin Labbe <clabbe.montjoie-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> > > ---
> > > .../devicetree/bindings/net/dwmac-sun8i.txt | 127 +++++++++++++++++++--
> > > 1 file changed, 120 insertions(+), 7 deletions(-)
> > >
> > > diff --git a/Documentation/devicetree/bindings/net/dwmac-sun8i.txt b/Documentation/devicetree/bindings/net/dwmac-sun8i.txt
> > > index 725f3b187886..3fa0e54825ea 100644
> > > --- a/Documentation/devicetree/bindings/net/dwmac-sun8i.txt
> > > +++ b/Documentation/devicetree/bindings/net/dwmac-sun8i.txt
> > > @@ -39,7 +39,7 @@ Optional properties for the following compatibles:
> > > - allwinner,leds-active-low: EPHY LEDs are active low
> > >
> > > Required child node of emac:
> > > -- mdio bus node: should be named mdio
> > > +- mdio bus node: should be labelled mdio
> >
> > labels do not end up in the final DT (while the names do) so why are
> > you making this change?
> >
>
> I misunderstood label/name.
> Anyway, this contrainst should leave due to "snps,dwmac-mdio MDIOs are automatically registered"
>
> > >
> > > Required properties of the mdio node:
> > > - #address-cells: shall be 1
> > > @@ -48,14 +48,28 @@ Required properties of the mdio node:
> > > The device node referenced by "phy" or "phy-handle" should be a child node
> > > of the mdio node. See phy.txt for the generic PHY bindings.
> > >
> > > -Required properties of the phy node with the following compatibles:
> > > +The following compatibles require an mdio-mux node called "mdio-mux":
> > > + - "allwinner,sun8i-h3-emac"
> > > + - "allwinner,sun8i-v3s-emac":
> > > +Required properties for the mdio-mux node:
> > > + - compatible = "mdio-mux"
> > > + - one child mdio for the integrated mdio
> > > + - one child mdio for the external mdio if present (V3s have none)
> > > +Required properties for the mdio-mux children node:
> > > + - reg: 0 for internal MDIO bus, 1 for external MDIO bus
> > > +
> > > +The following compatibles require a PHY node representing the integrated
> > > +PHY, under the integrated MDIO bus node if an mdio-mux node is used:
> > > - "allwinner,sun8i-h3-emac",
> > > - "allwinner,sun8i-v3s-emac":
> > > +
> > > +Required properties of the integrated phy node:
> > > - clocks: a phandle to the reference clock for the EPHY
> > > - resets: a phandle to the reset control for the EPHY
> > > +- phy-is-integrated
> > > +- Should be a child of the integrated mdio
> >
> > I'm not sure what you mean by that, you ask that it should (so not
> > required?) be a child of the integrated mdio...
> >
>
> I will change words to "must"
>
> > >
> > > -Example:
> > > -
> > > +Example with integrated PHY:
> > > emac: ethernet@1c0b000 {
> > > compatible = "allwinner,sun8i-h3-emac";
> > > syscon = <&syscon>;
> > > @@ -72,13 +86,112 @@ emac: ethernet@1c0b000 {
> > > phy-handle = <&int_mii_phy>;
> > > phy-mode = "mii";
> > > allwinner,leds-active-low;
> > > +
> > > + mdio0: mdio {
> >
> > (You don't label it mdio here, unlike what was asked before)
> >
> > > + #address-cells = <1>;
> > > + #size-cells = <0>;
> > > + compatible = "snps,dwmac-mdio";
> > > + };
> >
> > I think Rob wanted that node gone?
> >
>
> MDIO mux does not work without a parent MDIO, either gived by "parent-bus" or directly via mdio_mux_init() (like it is the case in dwmac-sun8i)
Is the MDIO controller "allwinner,sun8i-h3-emac" or "snps,dwmac-mdio"?
If the latter, then I think the node is fine, but then the mux should be
a child node of it. IOW, the child of an MDIO controller should either
be a mux node or slave devices.
>
> > > + mdio-mux {
> > > + compatible = "mdio-mux";
> > > + #address-cells = <1>;
> > > + #size-cells = <0>;
> > > +
> > > + int_mdio: mdio@1 {
> > > + reg = <0>;
unit address of 1 and reg prop of 0 don't match. Build your dtb with
W=2.
> > > + #address-cells = <1>;
> > > + #size-cells = <0>;
> > > + int_mii_phy: ethernet-phy@1 {
> > > + reg = <1>;
> > > + clocks = <&ccu CLK_BUS_EPHY>;
> > > + resets = <&ccu RST_BUS_EPHY>;
> > > + phy-is-integrated
Missing ;
> > > + };
> > > + };
> >
> > ... And in your example it's a child of the mdio mux?
> >
>
> So I confirm, integrated PHY must be a child of integrated MDIO (that must be a child of mdio-mux).
> The example is good.
>
> > > + ext_mdio: mdio@0 {
> > > + reg = <1>;
Another unit address mismatch.
Rob
--
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
* [PATCH net] net_sched: gen_estimator: fix scaling error in bytes/packets samples
From: Eric Dumazet @ 2017-09-13 18:16 UTC (permalink / raw)
To: Denys Fedoryshchenko
Cc: David Miller, netdev, Jamal Hadi Salim, Cong Wang, Jiri Pirko
In-Reply-To: <1505320949.15310.173.camel@edumazet-glaptop3.roam.corp.google.com>
From: Eric Dumazet <edumazet@google.com>
Denys reported wrong rate estimations with HTB classes.
It appears the bug was added in linux-4.10, since my tests
where using intervals of one second only.
HTB using 4 sec default rate estimators, reported rates
were 4x higher.
We need to properly scale the bytes/packets samples before
integrating them in EWMA.
Tested:
echo 1 >/sys/module/sch_htb/parameters/htb_rate_est
Setup HTB with one class with a rate/cail of 5Gbit
Generate traffic on this class
tc -s -d cl sh dev eth0 classid 7002:11
class htb 7002:11 parent 7002:1 prio 5 quantum 200000 rate 5Gbit ceil
5Gbit linklayer ethernet burst 80000b/1 mpu 0b cburst 80000b/1 mpu 0b
level 0 rate_handle 1
Sent 1488215421648 bytes 982969243 pkt (dropped 0, overlimits 0
requeues 0)
rate 5Gbit 412814pps backlog 136260b 2p requeues 0
TCP pkts/rtx 982969327/45 bytes 1488215557414/68130
lended: 22732826 borrowed: 0 giants: 0
tokens: -1684 ctokens: -1684
Fixes: 1c0d32fde5bd ("net_sched: gen_estimator: complete rewrite of rate estimators")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reported-by: Denys Fedoryshchenko <nuclearcat@nuclearcat.com>
---
net/core/gen_estimator.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/core/gen_estimator.c b/net/core/gen_estimator.c
index 0385dece1f6fe5e26df1ce5f40956a79a2eebbf4..7c1ffd6f950172c1915d8e5fa2b5e3f77e4f4c78 100644
--- a/net/core/gen_estimator.c
+++ b/net/core/gen_estimator.c
@@ -83,10 +83,10 @@ static void est_timer(unsigned long arg)
u64 rate, brate;
est_fetch_counters(est, &b);
- brate = (b.bytes - est->last_bytes) << (8 - est->ewma_log);
+ brate = (b.bytes - est->last_bytes) << (10 - est->ewma_log - est->intvl_log);
brate -= (est->avbps >> est->ewma_log);
- rate = (u64)(b.packets - est->last_packets) << (8 - est->ewma_log);
+ rate = (u64)(b.packets - est->last_packets) << (10 - est->ewma_log - est->intvl_log);
rate -= (est->avpps >> est->ewma_log);
write_seqcount_begin(&est->seq);
^ permalink raw reply related
* Re: [PATCH v5 02/10] dt-bindings: net: Restore sun8i dwmac binding
From: Rob Herring @ 2017-09-13 18:07 UTC (permalink / raw)
To: Corentin Labbe
Cc: mark.rutland, maxime.ripard, wens, linux, catalin.marinas,
will.deacon, peppe.cavallaro, alexandre.torgue, andrew,
f.fainelli, netdev, devicetree, linux-arm-kernel, linux-kernel
In-Reply-To: <20170908071156.5115-3-clabbe.montjoie@gmail.com>
On Fri, Sep 08, 2017 at 09:11:48AM +0200, Corentin Labbe wrote:
> This patch restore dt-bindings documentation about dwmac-sun8i
> This reverts commit 8aa33ec2f481 ("dt-bindings: net: Revert sun8i dwmac binding")
Why?
>
> Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
> ---
> .../devicetree/bindings/net/dwmac-sun8i.txt | 84 ++++++++++++++++++++++
> 1 file changed, 84 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/net/dwmac-sun8i.txt
Otherwise,
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: HTB going crazy over ~5Gbit/s (4.12.9, but problem present in older kernels as well)
From: Eric Dumazet @ 2017-09-13 18:03 UTC (permalink / raw)
To: Denys Fedoryshchenko; +Cc: Linux Kernel Network Developers, netdev-owner
In-Reply-To: <1505325534.15310.182.camel@edumazet-glaptop3.roam.corp.google.com>
On Wed, 2017-09-13 at 10:58 -0700, Eric Dumazet wrote:
> On Wed, 2017-09-13 at 20:35 +0300, Denys Fedoryshchenko wrote:
>
> > Overlimits never appear in HTB as i know, here is simulation on this
> > class that have constant "at least" 1G traffic, i throttled it to 1Kbit
> > to simulate forced drops:
> >
> > shapernew ~ # sh /etc/shaper.cfg;sleep 1;tc -s -d class show dev
> > eth3.777 classid 1:111;tc qdisc del dev eth3.777 root
> > class htb 1:111 parent 1:1 leaf 111: prio 0 quantum 50000 rate 1Kbit
> > ceil 1Kbit linklayer ethernet burst 31280b/1 mpu 0b cburst 31280b/1 mpu
> > 0b level 0
> > Sent 134350019 bytes 117520 pkt (dropped 7819, overlimits 0 requeues 0)
> > backlog 7902126b 4976p requeues 0
> > lended: 86694 borrowed: 0 giants: 0
> > tokens: -937500000 ctokens: -937500000
> >
>
> Oh right, I am using a local patch for this. Time to upstream :/
Please try :
diff --git a/net/sched/sch_htb.c b/net/sched/sch_htb.c
index 7e148376ba528efabe5a53a09653f9161c264be7..c6d7ae81b41f4e277afb93a3003fefcd3f27de35 100644
--- a/net/sched/sch_htb.c
+++ b/net/sched/sch_htb.c
@@ -142,6 +142,7 @@ struct htb_class {
struct rb_node node[TC_HTB_NUMPRIO]; /* node for self or feed tree */
unsigned int drops ____cacheline_aligned_in_smp;
+ unsigned int overlimits;
};
struct htb_level {
@@ -533,6 +534,9 @@ htb_change_class_mode(struct htb_sched *q, struct htb_class *cl, s64 *diff)
if (new_mode == cl->cmode)
return;
+ if (new_mode == HTB_CANT_SEND)
+ cl->overlimits++;
+
if (cl->prio_activity) { /* not necessary: speed optimization */
if (cl->cmode != HTB_CANT_SEND)
htb_deactivate_prios(q, cl);
@@ -1143,6 +1147,7 @@ htb_dump_class_stats(struct Qdisc *sch, unsigned long arg, struct gnet_dump *d)
struct htb_class *cl = (struct htb_class *)arg;
struct gnet_stats_queue qs = {
.drops = cl->drops,
+ .overlimits = cl->overlimits,
};
__u32 qlen = 0;
^ permalink raw reply related
* Re: HTB going crazy over ~5Gbit/s (4.12.9, but problem present in older kernels as well)
From: Eric Dumazet @ 2017-09-13 17:58 UTC (permalink / raw)
To: Denys Fedoryshchenko; +Cc: Linux Kernel Network Developers, netdev-owner
In-Reply-To: <5a95e6550a304545fbde95360985c018@nuclearcat.com>
On Wed, 2017-09-13 at 20:35 +0300, Denys Fedoryshchenko wrote:
> Overlimits never appear in HTB as i know, here is simulation on this
> class that have constant "at least" 1G traffic, i throttled it to 1Kbit
> to simulate forced drops:
>
> shapernew ~ # sh /etc/shaper.cfg;sleep 1;tc -s -d class show dev
> eth3.777 classid 1:111;tc qdisc del dev eth3.777 root
> class htb 1:111 parent 1:1 leaf 111: prio 0 quantum 50000 rate 1Kbit
> ceil 1Kbit linklayer ethernet burst 31280b/1 mpu 0b cburst 31280b/1 mpu
> 0b level 0
> Sent 134350019 bytes 117520 pkt (dropped 7819, overlimits 0 requeues 0)
> backlog 7902126b 4976p requeues 0
> lended: 86694 borrowed: 0 giants: 0
> tokens: -937500000 ctokens: -937500000
>
Oh right, I am using a local patch for this. Time to upstream :/
^ permalink raw reply
* Re: Memory leaks in conntrack
From: Cong Wang @ 2017-09-13 17:58 UTC (permalink / raw)
To: Florian Westphal; +Cc: netfilter-devel, Linux Kernel Network Developers
In-Reply-To: <CAM_iQpVk1X+ZV2Nzi28G0HJu+RZWJ-_=0AO+EF4HVZnqSjVQ8w@mail.gmail.com>
On Wed, Sep 13, 2017 at 9:45 AM, Cong Wang <xiyou.wangcong@gmail.com> wrote:
> On Wed, Sep 13, 2017 at 1:05 AM, Florian Westphal <fw@strlen.de> wrote:
>> Cong Wang <xiyou.wangcong@gmail.com> wrote:
>>> While testing my TC filter patches (so not related to conntrack), the
>>> following memory leaks are shown up:
>>>
>>> unreferenced object 0xffff9b19ba551228 (size 128):
>>> comm "chronyd", pid 338, jiffies 4294910829 (age 53.188s)
>>> hex dump (first 32 bytes):
>>> 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
>>> 00 00 00 00 18 00 00 30 00 00 00 00 00 00 00 00 .......0........
>>> backtrace:
>>> [<ffffffff9f1e1175>] create_object+0x169/0x2aa
>>> [<ffffffff9fb77fb2>] kmemleak_alloc+0x25/0x41
>>> [<ffffffff9f1c47ed>] slab_post_alloc_hook+0x44/0x65
>>> [<ffffffff9f1ca2db>] __kmalloc_track_caller+0x113/0x146
>>> [<ffffffff9f193c3b>] __krealloc+0x4a/0x69
>>> [<ffffffff9f948dbd>] nf_ct_ext_add+0xe1/0x145
>>> [<ffffffff9f942395>] init_conntrack+0x1f7/0x36e
>>> [<ffffffff9f942762>] nf_conntrack_in+0x1d3/0x326
>>> [<ffffffff9fa1ea69>] ipv4_conntrack_local+0x4d/0x50
>>> [<ffffffff9f93ad70>] nf_hook_slow+0x3c/0x9b
>>> [<ffffffff9f9c7999>] nf_hook.constprop.40+0xbe/0xd8
>>> [<ffffffff9f9c7ba2>] __ip_local_out+0xb3/0xbf
>>> [<ffffffff9f9c7bca>] ip_local_out+0x1c/0x36
>>> [<ffffffff9f9c9216>] ip_send_skb+0x19/0x3d
>>> [<ffffffff9f9ee3de>] udp_send_skb+0x17e/0x1df
>>> [<ffffffff9f9eea37>] udp_sendmsg+0x5a2/0x77c
>>> unreferenced object 0xffff9b19a69b3340 (size 336):
>>> comm "chronyd", pid 338, jiffies 4294910868 (age 53.032s)
>>> hex dump (first 32 bytes):
>>> 01 00 00 00 5a 5a 5a 5a 00 00 00 00 ad 4e ad de ....ZZZZ.....N..
>>> ff ff ff ff 5a 5a 5a 5a ff ff ff ff ff ff ff ff ....ZZZZ........
>>> backtrace:
>>> [<ffffffff9f1e1175>] create_object+0x169/0x2aa
>>> [<ffffffff9fb77fb2>] kmemleak_alloc+0x25/0x41
>>> [<ffffffff9f1c47ed>] slab_post_alloc_hook+0x44/0x65
>>> [<ffffffff9f1c7a7d>] kmem_cache_alloc+0xd7/0x1f1
>>> [<ffffffff9f941b78>] __nf_conntrack_alloc+0xa2/0x146
>>> [<ffffffff9f942250>] init_conntrack+0xb2/0x36e
>>> [<ffffffff9f942762>] nf_conntrack_in+0x1d3/0x326
>>> [<ffffffff9fa1ea69>] ipv4_conntrack_local+0x4d/0x50
>>> [<ffffffff9f93ad70>] nf_hook_slow+0x3c/0x9b
>>> [<ffffffff9f9c7999>] nf_hook.constprop.40+0xbe/0xd8
>>> [<ffffffff9f9c7ba2>] __ip_local_out+0xb3/0xbf
>>> [<ffffffff9f9c7bca>] ip_local_out+0x1c/0x36
>>> [<ffffffff9f9c9216>] ip_send_skb+0x19/0x3d
>>> [<ffffffff9f9ee3de>] udp_send_skb+0x17e/0x1df
>>> [<ffffffff9f9eea37>] udp_sendmsg+0x5a2/0x77c
>>> [<ffffffff9f9f8cb8>] inet_sendmsg+0x37/0x5e
>>>
>>> I don't touch chronyd in my VM, so I have no idea why it sends out UDP
>>> packets, my guess is it is some periodical packet.
>>>
>>> I don't think I use conntrack either, since /proc/net/ip_conntrack
>>> does not exist.
>>
>> You probably do, can you try "cat /proc/net/nf_conntrack" instead?
>>
>> (otherwise there should be no ipv4_conntrack_local() invocation
>> since we would not register this hook at all).
>
> Yeah it is very weird but it is true:
>
> [root@localhost ~]# echo scan > /sys/kernel/debug/kmemleak
> [ 133.450823] kmemleak: 18 new suspected memory leaks (see
> /sys/kernel/debug/kmemleak)
> [root@localhost ~]# cat /proc/net/ip_conntrack
> cat: /proc/net/ip_conntrack: No such file or directory
> [root@localhost ~]# cat /sys/kernel/debug/kmemleak
> unreferenced object 0xffff95c1e0b24040 (size 336):
> ...
Oops, you mean nf_conntrack... Here we go:
[root@localhost ~]# cat /proc/net/nf_conntrack
ipv4 2 udp 17 116 src=192.168.124.6 dst=204.2.134.162
sport=123 dport=123 src=204.2.134.162 dst=192.168.124.6 sport=123
dport=123 [ASSURED] mark=0 zone=0 use=2
ipv4 2 udp 17 117 src=192.168.124.6 dst=45.79.187.10
sport=123 dport=123 src=45.79.187.10 dst=192.168.124.6 sport=123
dport=123 [ASSURED] mark=0 zone=0 use=2
ipv4 2 udp 17 110 src=192.168.124.6 dst=192.168.124.1
sport=35486 dport=53 src=192.168.124.1 dst=192.168.124.6 sport=53
dport=35486 [ASSURED] mark=0 zone=0 use=2
ipv4 2 udp 17 110 src=192.168.124.6 dst=192.168.124.1
sport=52373 dport=53 src=192.168.124.1 dst=192.168.124.6 sport=53
dport=52373 [ASSURED] mark=0 zone=0 use=2
ipv4 2 unknown 2 518 src=192.168.124.6 dst=224.0.0.22 [UNREPLIED]
src=224.0.0.22 dst=192.168.124.6 mark=0 zone=0 use=2
ipv4 2 udp 17 110 src=192.168.124.6 dst=192.168.124.1
sport=43242 dport=53 src=192.168.124.1 dst=192.168.124.6 sport=53
dport=43242 [ASSURED] mark=0 zone=0 use=2
ipv4 2 udp 17 116 src=192.168.124.6 dst=96.226.123.196
sport=123 dport=123 src=96.226.123.196 dst=192.168.124.6 sport=123
dport=123 [ASSURED] mark=0 zone=0 use=2
ipv4 2 udp 17 110 src=192.168.124.6 dst=192.168.124.1
sport=42838 dport=53 src=192.168.124.1 dst=192.168.124.6 sport=53
dport=42838 [ASSURED] mark=0 zone=0 use=2
ipv4 2 udp 17 117 src=192.168.124.6 dst=97.127.104.4
sport=123 dport=123 src=97.127.104.4 dst=192.168.124.6 sport=123
dport=123 [ASSURED] mark=0 zone=0 use=2
^ 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