* [PATCH iproute2 1/4] man: drop references to Debian-specific paths
From: Luca Boccassi @ 2017-12-29 22:01 UTC (permalink / raw)
To: netdev
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=UTF-8, Size: 1699 bytes --]
Documentation should be distribution-agnostic - any specific quirks
should be handled by downstream maintainers, if necessary.
Remove mentions of Debian paths and package names.
Signed-off-by: Luca Boccassi <bluca@debian.org>
---
man/man8/lnstat.8 | 3 +--
man/man8/ss.8 | 3 +--
2 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/man/man8/lnstat.8 b/man/man8/lnstat.8
index acd5f4a2..b98241bf 100644
--- a/man/man8/lnstat.8
+++ b/man/man8/lnstat.8
@@ -254,8 +254,7 @@ Number of hash table list traversals for output traffic. Deprecated since IP
route cache removal, therefore always zero.
.SH SEE ALSO
-.BR ip (8),
-and /usr/share/doc/iproute-doc/README.lnstat (package iproute-doc on Debian)
+.BR ip (8)
.br
.SH AUTHOR
lnstat was written by Harald Welte <laforge@gnumonks.org>.
diff --git a/man/man8/ss.8 b/man/man8/ss.8
index 0d526734..973afbe0 100644
--- a/man/man8/ss.8
+++ b/man/man8/ss.8
@@ -327,7 +327,7 @@ Read filter information from FILE.
Each line of FILE is interpreted like single command line option. If FILE is - stdin is used.
.TP
.B FILTER := [ state STATE-FILTER ] [ EXPRESSION ]
-Please take a look at the official documentation (Debian package iproute-doc) for details regarding filters.
+Please take a look at the official documentation for details regarding filters.
.SH STATE-FILTER
@@ -382,7 +382,6 @@ Find all local processes connected to X server.
List all the tcp sockets in state FIN-WAIT-1 for our apache to network 193.233.7/24 and look at their timers.
.SH SEE ALSO
.BR ip (8),
-.BR /usr/share/doc/iproute-doc/ss.html " (package iproutedoc)",
.br
.BR RFC " 793 "
- https://tools.ietf.org/rfc/rfc793.txt (TCP states)
--
2.14.2
^ permalink raw reply related
* [PATCH iproute2 2/4] man: add more keywords to ip.8 short description
From: Luca Boccassi @ 2017-12-29 22:01 UTC (permalink / raw)
To: netdev
In-Reply-To: <20171229220125.13579-1-bluca@debian.org>
A Debian user suggested adding more network-related keywords to the
ip manpage, so that manpage-scraping and indexing software like
apropos can do a better job of categorizing the programs.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=877983
Suggested-by: Lynoure Braakman <lynoure@gmail.com>
Signed-off-by: Luca Boccassi <bluca@debian.org>
---
man/man8/ip.8 | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/man/man8/ip.8 b/man/man8/ip.8
index ae018fdf..94e64319 100644
--- a/man/man8/ip.8
+++ b/man/man8/ip.8
@@ -1,6 +1,6 @@
.TH IP 8 "20 Dec 2011" "iproute2" "Linux"
.SH NAME
-ip \- show / manipulate routing, devices, policy routing and tunnels
+ip \- show / manipulate routing, network devices, policy routing, interfaces (ethernet and more) and tunnels
.SH SYNOPSIS
.ad l
--
2.14.2
^ permalink raw reply related
* [PATCH iproute2 3/4] man: ip-address: document 15-char limit for LABEL
From: Luca Boccassi @ 2017-12-29 22:01 UTC (permalink / raw)
To: netdev
In-Reply-To: <20171229220125.13579-1-bluca@debian.org>
Trying to set a label longer than 15 characters returns an error:
RTNETLINK answers: Numerical result out of range
Document the limit in the manpage.
Originally reported as a Debian bug:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=661886
Reported-by: Gabor Kiss <kissg@ssg.ki.iif.hu>
Signed-off-by: Luca Boccassi <bluca@debian.org>
---
man/man8/ip-address.8.in | 1 +
1 file changed, 1 insertion(+)
diff --git a/man/man8/ip-address.8.in b/man/man8/ip-address.8.in
index eaa179c6..e7f14533 100644
--- a/man/man8/ip-address.8.in
+++ b/man/man8/ip-address.8.in
@@ -190,6 +190,7 @@ Each address may be tagged with a label string.
In order to preserve compatibility with Linux-2.0 net aliases,
this string must coincide with the name of the device or must be prefixed
with the device name followed by colon.
+The maximum allowed length is 15 characters.
.TP
.BI scope " SCOPE_VALUE"
--
2.14.2
^ permalink raw reply related
* [PATCH iproute2 4/4] man: routel/routef: don't mention filesystem paths
From: Luca Boccassi @ 2017-12-29 22:01 UTC (permalink / raw)
To: netdev
In-Reply-To: <20171229220125.13579-1-bluca@debian.org>
The filesytem paths to these scripts might be different on various
distros, so don't mention it in the manpages. It is not really useful
information anyway.
Originally submitted as Debian bug:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=561424
Reported-by: jidanni@jidanni.org
Signed-off-by: Luca Boccassi <bluca@debian.org>
---
man/man8/routel.8 | 5 -----
1 file changed, 5 deletions(-)
diff --git a/man/man8/routel.8 b/man/man8/routel.8
index 82d580fb..2270eacb 100644
--- a/man/man8/routel.8
+++ b/man/man8/routel.8
@@ -17,11 +17,6 @@ The routel script will list routes in a format that some might consider easier t
.br
The routef script does not take any arguments and will simply flush the routing table down the drain. Beware! This means deleting all routes which will make your network unusable!
-.SH "FILES"
-.LP
-\fI/usr/bin/routef\fP
-.br
-\fI/usr/bin/routel\fP
.SH "AUTHORS"
.LP
The routel script was written by Stephen R. van den Berg <srb@cuci.nl>, 1999/04/18 and donated to the public domain.
--
2.14.2
^ permalink raw reply related
* Re: [PATCH net-next 2/2] l2tp: add peer_offset parameter
From: Lorenzo Bianconi @ 2017-12-29 22:21 UTC (permalink / raw)
To: James Chapman; +Cc: Guillaume Nault, David S. Miller, netdev, Hangbin Liu
In-Reply-To: <27e0a7c8-b95b-04eb-d808-bcae67e417b1@katalix.com>
> Sorry for only just seeing this (vacation).
>
>
> On 28/12/17 19:45, Guillaume Nault wrote:
>>
>> On Thu, Dec 28, 2017 at 07:23:48PM +0100, Lorenzo Bianconi wrote:
>>>
>>> On Dec 28, Guillaume Nault wrote:
>>>>
>>>> After a quick review of L2TPv3 and pseudowires RFCs, I still don't see
>>>> how adding some padding between the L2TPv3 header and the payload could
>>>> constitute a valid frame. Of course, the base feature is already there,
>>>> but after a quick test, it looks like the padding bits aren't
>>>> initialised and leak memory.
>>>
>>> Do you mean for L2TPv2 or L2TPv3? For L2TPv3 offset/peer_offset are
>>> initialized
>>> in l2tp_nl_cmd_session_create()
>>>
>> That's the offsets stored in the l2tp_session_cfg structure. But I was
>> talking about the xmit path: l2tp_build_l2tpv3_header() doesn't
>> initialise the padding between the header and the payload. So when
>> someone activates this option, then every transmitted packet leaks
>> memory on the wire.
>>
>>> Setting session data offset is already supported in L2TP kernel module
>>> (and could be already used by userspace applications);
>>> for L2TPv2 there is an optional 16-bit value in the header while for
>>> L2TPv3
>>> the offset is configured by userspace.
>>> At the moment the kernel (for L2TPv3) uses offset for both tx and rx
>>> side.
>>> Userspace (iproute2) allows to distinguish tx offset (offset) from rx one
>>> (peer_offset) but since the rx part is not handled at the moment
>>> (I fixed peer_offset support in iproute2, I have not sent the patch
>>> upstream yet, attached below)
>>> this leads to a misalignment between tunnel endpoints.
>>> You can easily reproduce the issue using this setup (and the below patch
>>> for iproute2):
>>>
>>> ip l2tp add tunnel local <ip0> remote <ip1> tunnel_id <id0>
>>> peer_tunnel_id <id1> udp_sport <p0> udp_dport <p1>
>>> ip l2tp add tunnel local <ip1> remote <ip0> tunnel_id <id1>
>>> peer_tunnel_id <id0> udp_sport <p1> udp_dport <p0>
>>>
>>> ip l2tp add session name l2tp0 tunnel_id <id0> session_id <s0>
>>> peer_session_id <s1> offset 8 peer_offset 16
>>> ip l2tp add session name l2tp0 tunnel_id <id1> session_id <s1>
>>> peer_session_id <s0> offset 16 peer_offset 8
>>>
>> Yes, I'm well aware of that. And thanks for having worked on a full
>> solution including iproute2. But does one really need to set
>> asymetrical offset values? It doesn't look wrong to require setting the
>> same value on both sides. Other options need this, like "l2spec_type".
>>
>> Here we have an option that:
>> * creates invalid packets (AFAIK),
>> * is buggy and leaks memory on the network,
>> * doesn't seem to have any use case (even the manpage
>> says "This is hardly ever used").
>>
>> So I'm sorry, but I don't see the point in expanding this option to
>> allow even stranger setups. If there's a use case, then fine.
>> Otherwise, let's just acknowledge that the "peer_offset" option of
>> iproute2 is a noop (and maybe remove it from the manpage).
>>
>> And the kernel "offset" option needs to be fixed. Actually, I wouldn't
>> mind if it was converted to be a noop, or even rejected. L2TP already
>> has its share of unused features that complicate the code and hamper
>> evolution and bug fixing. As I said earlier, if it's buggy, unused and
>> can't even produce valid packets, then why bothering with it?
>>
>> But that's just my point of view. James, do you have an opinion on
>> this?
>
>
> I agree, Guillaume.
>
> The L2TPv3 protocol RFC dropped the configurable offset of L2TPv2 - instead,
> the Layer-2-Specific-Sublayer is supposed to handle any transport-specific
> data alignment requirements. I think a configurable offset has found its way
> into iproute2 l2tp commands by mistake, perhaps because the netlink API
> defines an attribute for it, but which was only intended for use with
> L2TPv2. For L2TPv2, we only configure the offset for transmitted packets. In
> received packets, the offset (if present) is obtained from the L2TPv2 header
> in each received packet. There is no need to add a peer-offset netlink
> attribute to set the offset expected in received packets.
>
> Lorenzo, is this being added to fix interoperability with another L2TPv3
> implementation? If so, can you share more details?
>
Hi James,
I introduced peer_offset parameter to fix a specific setup where
tunnel endpoints
running L2TPv3 would use different values for tx offset (since in
iproute2 there is no
restriction on it), not to fix a given an interoperability issue.
I introduced this feature since:
- offset has been added for long time to L2TPv3 implementation
(commit f7faffa3ff8ef6ae712ef16312b8a2aa7a1c95fe and
commit 309795f4bec2d69cd507a631f82065c2198a0825) and I wanted to
preserve UABI
- have the same degree of freedom for offset parameter we have in
L2TPv2 and fix the issue
described above
Now what we can do I guess is:
- as suggested by Guillaume drop completely the offset support without removing
netlink attribute in order to not break UABI
- fix offset support initializing properly padding bits
I think at the moment we can skip the option to impose to have the
same offset value
for both tx and rx side.
Regards,
Lorenzo
^ permalink raw reply
* Re: [RFT net-next v3 0/5] dwmac-meson8b: RGMII clock fixes for Meson8b
From: Emiliano Ingrassia @ 2017-12-29 23:00 UTC (permalink / raw)
To: Jerome Brunet, Martin Blumenstingl
Cc: netdev, linus.luessing, khilman, linux-amlogic, Neil Armstrong,
peppe.cavallaro, alexandre.torgue
In-Reply-To: <1514570663.7439.19.camel@baylibre.com>
Hi Jerome, Hi Martin,
On Fri, Dec 29, 2017 at 07:04:23PM +0100, Jerome Brunet wrote:
> On Fri, 2017-12-29 at 02:31 +0100, Emiliano Ingrassia wrote:
> > Hi Martin, Hi Dave,
> >
> > On Thu, Dec 28, 2017 at 11:21:23PM +0100, Martin Blumenstingl wrote:
> > > Hi Dave,
> > >
> > > please do not apply this series until it got a Tested-by from Emiliano.
> > >
> > >
> > > Hi Emiliano,
> > >
> > > you reported [0] that you couldn't get dwmac-meson8b to work on your
> > > Odroid-C1. With your findings (register dumps, clk_summary output, etc.)
> > > I think I was able to find a fix: it consists of two patches (which you
> > > find in this series)
> > >
> > > Unfortunately I don't have any Meson8b boards with RGMII PHY so I could
> > > only partially test this (I could only check if the clocks were
> > > calculated correctly when using a dummy 500002394Hz input clock instead
> > > of MPLL2).
> > >
> > > Could you please give this series a try and let me know about the
> > > results?
> > > You obviously still need your two "ARM: dts: meson8b" patches which
> > > - add the amlogic,meson8b-dwmac" compatible to meson8b.dtsi
> > > - enable Ethernet on the Odroid-C1
> > >
> > > When testing on Meson8b this also needs a fix for the MPLL clock driver:
> > > "clk: meson: mpll: use 64-bit maths in params_from_rate", see:
> > > https://patchwork.kernel.org/patch/10131677/
> > >
> > >
> > > I have tested this myself on a Khadas VIM (GXL SoC, internal RMII PHY)
> > > and a Khadas VIM2 (GXM SoC, external RGMII PHY). Both are still working
> > > fine (so let's hope that this also fixes your Meson8b issue :)).
> > >
> > >
> > > changes since v1 at [1]:
> > > - changed the subject of the cover-letter to indicate that this is all
> > > about the RGMII clock
> > > - added PATCH #1 which ensures that we don't unnecessarily change the
> > > parent clocks in RMII mode (and also makes the code easier to
> > > understand)
> > > - changed subject of PATCH #2 (formerly PATCH #1) to state that this
> > > is about the RGMII clock
> > > - added Jerome's Reviewed-by to PATCH #2 (formerly PATCH #1)
> > > - replaced PATCH #3 (formerly PATCH #2) with one that sets
> > > CLK_SET_RATE_PARENT on the mux and thus re-configures the MPLL2 clock
> > > on Meson8b correctly
> > >
> > > changes since v2 at [2]:
> > > - added PATCH #2 to make the following patch easier
> > > - Emiliano reported that there's currently another bug in the
> > > dwmac-meson8b driver which prevents it from working with RGMII PHYs on
> > > Meson8b: bit 10 of the PRG_ETH0 register is configures a clock gate
> > > (instead of a divide by 5 or divide by 10 clock divider). This has not
> > > been visible on GXBB and later due to the input clock which always led
> > > to a selection of "divide by 10" (which is done internally in the IP
> > > block, but the bit actually means "enable RGMII clock output").
> > > PATCH #3 was added to address this issue.
> > > - the commit message of PATCH #4 and #5 (formerly PATCH #2 and #3) were
> > > updated and the patch itself rebased because the m25_div clock was
> > > removed with the new PATCH #3 (so some of the statements were not
> > > valid anymore)
> > >
> >
> > Here is the clk_summary relative to ethernet on Odroid-C1+
> > with this new series applied:
> >
> > xtal 1 1 24000000 0 0
> > sys_pll 0 0 1200000000 0 0
> > cpu_clk 0 0 1200000000 0 0
> > vid_pll 0 0 732000000 0 0
> > fixed_pll 2 2 2550000000 0 0
> > mpll2 1 1 249999701 0 0
> > c9410000.ethernet#m250_sel 1 1 249999701 0 0
> > c9410000.ethernet#m250_div 1 1 249999701 0 0
> > c9410000.ethernet#fixed_div10 1 1 24999970 0 0
> > c9410000.ethernet#m25_en 1 1 24999970 0 0
> >
> > The ethernet prg0 register is set to 0x74A1 which should be correct with
> > respect to the information contained in the S805 SoC manual.
> > Actually, the ethernet is not yet fully functional.
> > Trying to ping the board, I can see ARP request from host to board using
> > tcpdump. However, the host can't see any response.
>
> If the rx path is ok-ish, I suppose the clock setting applied is good.
> Maybe you could try to play with the tx delay (BIT 5-6 of the register) ?
>
Thanks for the suggestion. Finally the ethernet works correctly using 4
ns as tx-delay.
The clock summary is the same reported above. The prg0 ethernet register
value is 0x74c1 as expected.
I would like to thanks Martin for the support!
As soon as this patch series [v3] will be submitted, I'll submit my patch for
the device tree.
Let me know if you have any question.
Thanks again,
Emiliano
> >
> > Following the U-Boot value for prg0 register, which is 0x7d21, I also
> > tried to set bit 11. As expected, this did not have any influence.
> > Another thing that we should check is the "Ethernet Memory PD" (see S805
> > manual - sec. 5.4) register which bits 3-2 enable/disable ethernet
> > normal operation. However, those bits are already cleared by U-Boot.
> >
> > Thank you for the support.
> >
> > Best regards,
> >
> > Emiliano
> >
> > >
> > > [0] http://lists.infradead.org/pipermail/linux-amlogic/2017-December/005596.html
> > > [1] http://lists.infradead.org/pipermail/linux-amlogic/2017-December/005848.html
> > > [2] http://lists.infradead.org/pipermail/linux-amlogic/2017-December/005861.html
> > >
> > >
> > > Martin Blumenstingl (5):
> > > net: stmmac: dwmac-meson8b: only configure the clocks in RGMII mode
> > > net: stmmac: dwmac-meson8b: simplify generating the clock names
> > > net: stmmac: dwmac-meson8b: fix internal RGMII clock configuration
> > > net: stmmac: dwmac-meson8b: fix setting the RGMII clock on Meson8b
> > > net: stmmac: dwmac-meson8b: propagate rate changes to the parent clock
> > >
> > > .../net/ethernet/stmicro/stmmac/dwmac-meson8b.c | 119 +++++++++++----------
> > > 1 file changed, 63 insertions(+), 56 deletions(-)
> > >
> > > --
> > > 2.15.1
> > >
>
^ permalink raw reply
* [net-next v2] ipv6: sr: export some functions of seg6local
From: Ahmed Abdelsalam @ 2017-12-29 23:08 UTC (permalink / raw)
To: davem; +Cc: david.lebrun, netdev, linux-kernel, amsalam20
Some functions of seg6local are very useful to process SRv6
encapsulated packets
This patch exports some functions of seg6local that are useful and
can be re-used at different parts of the kernel.
The set of exported functions are:
(1) seg6_get_srh()
(2) seg6_advance_nextseg()
(3) seg6_lookup_nexthop
Signed-off-by: Ahmed Abdelsalam <amsalam20@gmail.com>
---
Functions names are prefixed with seg6_
include/net/seg6.h | 5 +++++
net/ipv6/seg6_local.c | 37 ++++++++++++++++++++-----------------
2 files changed, 25 insertions(+), 17 deletions(-)
diff --git a/include/net/seg6.h b/include/net/seg6.h
index 099bad5..5d308e9b 100644
--- a/include/net/seg6.h
+++ b/include/net/seg6.h
@@ -60,6 +60,11 @@ extern int seg6_local_init(void);
extern void seg6_local_exit(void);
extern bool seg6_validate_srh(struct ipv6_sr_hdr *srh, int len);
+extern struct ipv6_sr_hdr *seg6_get_srh(struct sk_buff *skb);
+extern void seg6_advance_nextseg(struct ipv6_sr_hdr *srh,
+ struct in6_addr *daddr);
+extern void seg6_lookup_nexthop(struct sk_buff *skb, struct in6_addr *nhaddr,
+ u32 tbl_id);
extern int seg6_do_srh_encap(struct sk_buff *skb, struct ipv6_sr_hdr *osrh,
int proto);
extern int seg6_do_srh_inline(struct sk_buff *skb, struct ipv6_sr_hdr *osrh);
diff --git a/net/ipv6/seg6_local.c b/net/ipv6/seg6_local.c
index 825b8e0..ea86ba8 100644
--- a/net/ipv6/seg6_local.c
+++ b/net/ipv6/seg6_local.c
@@ -59,7 +59,7 @@ static struct seg6_local_lwt *seg6_local_lwtunnel(struct lwtunnel_state *lwt)
return (struct seg6_local_lwt *)lwt->data;
}
-static struct ipv6_sr_hdr *get_srh(struct sk_buff *skb)
+struct ipv6_sr_hdr *seg6_get_srh(struct sk_buff *skb)
{
struct ipv6_sr_hdr *srh;
int len, srhoff = 0;
@@ -82,12 +82,13 @@ static struct ipv6_sr_hdr *get_srh(struct sk_buff *skb)
return srh;
}
+EXPORT_SYMBOL_GPL(seg6_get_srh);
static struct ipv6_sr_hdr *get_and_validate_srh(struct sk_buff *skb)
{
struct ipv6_sr_hdr *srh;
- srh = get_srh(skb);
+ srh = seg6_get_srh(skb);
if (!srh)
return NULL;
@@ -107,7 +108,7 @@ static bool decap_and_validate(struct sk_buff *skb, int proto)
struct ipv6_sr_hdr *srh;
unsigned int off = 0;
- srh = get_srh(skb);
+ srh = seg6_get_srh(skb);
if (srh && srh->segments_left > 0)
return false;
@@ -131,7 +132,7 @@ static bool decap_and_validate(struct sk_buff *skb, int proto)
return true;
}
-static void advance_nextseg(struct ipv6_sr_hdr *srh, struct in6_addr *daddr)
+void seg6_advance_nextseg(struct ipv6_sr_hdr *srh, struct in6_addr *daddr)
{
struct in6_addr *addr;
@@ -139,9 +140,10 @@ static void advance_nextseg(struct ipv6_sr_hdr *srh, struct in6_addr *daddr)
addr = srh->segments + srh->segments_left;
*daddr = *addr;
}
+EXPORT_SYMBOL_GPL(seg6_advance_nextseg);
-static void lookup_nexthop(struct sk_buff *skb, struct in6_addr *nhaddr,
- u32 tbl_id)
+void seg6_lookup_nexthop(struct sk_buff *skb, struct in6_addr *nhaddr,
+ u32 tbl_id)
{
struct net *net = dev_net(skb->dev);
struct ipv6hdr *hdr = ipv6_hdr(skb);
@@ -188,6 +190,7 @@ static void lookup_nexthop(struct sk_buff *skb, struct in6_addr *nhaddr,
skb_dst_drop(skb);
skb_dst_set(skb, dst);
}
+EXPORT_SYMBOL_GPL(seg6_lookup_nexthop);
/* regular endpoint function */
static int input_action_end(struct sk_buff *skb, struct seg6_local_lwt *slwt)
@@ -198,9 +201,9 @@ static int input_action_end(struct sk_buff *skb, struct seg6_local_lwt *slwt)
if (!srh)
goto drop;
- advance_nextseg(srh, &ipv6_hdr(skb)->daddr);
+ seg6_advance_nextseg(srh, &ipv6_hdr(skb)->daddr);
- lookup_nexthop(skb, NULL, 0);
+ seg6_lookup_nexthop(skb, NULL, 0);
return dst_input(skb);
@@ -218,9 +221,9 @@ static int input_action_end_x(struct sk_buff *skb, struct seg6_local_lwt *slwt)
if (!srh)
goto drop;
- advance_nextseg(srh, &ipv6_hdr(skb)->daddr);
+ seg6_advance_nextseg(srh, &ipv6_hdr(skb)->daddr);
- lookup_nexthop(skb, &slwt->nh6, 0);
+ seg6_lookup_nexthop(skb, &slwt->nh6, 0);
return dst_input(skb);
@@ -237,9 +240,9 @@ static int input_action_end_t(struct sk_buff *skb, struct seg6_local_lwt *slwt)
if (!srh)
goto drop;
- advance_nextseg(srh, &ipv6_hdr(skb)->daddr);
+ seg6_advance_nextseg(srh, &ipv6_hdr(skb)->daddr);
- lookup_nexthop(skb, NULL, slwt->table);
+ seg6_lookup_nexthop(skb, NULL, slwt->table);
return dst_input(skb);
@@ -331,7 +334,7 @@ static int input_action_end_dx6(struct sk_buff *skb,
if (!ipv6_addr_any(&slwt->nh6))
nhaddr = &slwt->nh6;
- lookup_nexthop(skb, nhaddr, 0);
+ seg6_lookup_nexthop(skb, nhaddr, 0);
return dst_input(skb);
drop:
@@ -380,7 +383,7 @@ static int input_action_end_dt6(struct sk_buff *skb,
if (!pskb_may_pull(skb, sizeof(struct ipv6hdr)))
goto drop;
- lookup_nexthop(skb, NULL, slwt->table);
+ seg6_lookup_nexthop(skb, NULL, slwt->table);
return dst_input(skb);
@@ -406,7 +409,7 @@ static int input_action_end_b6(struct sk_buff *skb, struct seg6_local_lwt *slwt)
ipv6_hdr(skb)->payload_len = htons(skb->len - sizeof(struct ipv6hdr));
skb_set_transport_header(skb, sizeof(struct ipv6hdr));
- lookup_nexthop(skb, NULL, 0);
+ seg6_lookup_nexthop(skb, NULL, 0);
return dst_input(skb);
@@ -426,7 +429,7 @@ static int input_action_end_b6_encap(struct sk_buff *skb,
if (!srh)
goto drop;
- advance_nextseg(srh, &ipv6_hdr(skb)->daddr);
+ seg6_advance_nextseg(srh, &ipv6_hdr(skb)->daddr);
skb_reset_inner_headers(skb);
skb->encapsulation = 1;
@@ -438,7 +441,7 @@ static int input_action_end_b6_encap(struct sk_buff *skb,
ipv6_hdr(skb)->payload_len = htons(skb->len - sizeof(struct ipv6hdr));
skb_set_transport_header(skb, sizeof(struct ipv6hdr));
- lookup_nexthop(skb, NULL, 0);
+ seg6_lookup_nexthop(skb, NULL, 0);
return dst_input(skb);
--
2.1.4
^ permalink raw reply related
* Re: [RFT net-next v3 3/5] net: stmmac: dwmac-meson8b: fix internal RGMII clock configuration
From: Martin Blumenstingl @ 2017-12-29 23:40 UTC (permalink / raw)
To: Jerome Brunet
Cc: netdev, ingrassia, linus.luessing, khilman, linux-amlogic,
Neil Armstrong, peppe.cavallaro, alexandre.torgue
In-Reply-To: <1514570234.7439.15.camel@baylibre.com>
Hi Jerome,
On Fri, Dec 29, 2017 at 6:57 PM, Jerome Brunet <jbrunet@baylibre.com> wrote:
> On Thu, 2017-12-28 at 23:21 +0100, Martin Blumenstingl wrote:
>> While testing the dwmac-meson8b with an RGMII PHY on Meson8b we
>> discovered that the m25_div is not actually a divider but rather a gate.
>> This matches with the datasheet which describes bit 10 as "Generate
>> 25MHz clock for PHY". Back when the driver was written it was assumed
>> that this was a divider (which could divide by 5 or 10) because other
>> clock bits in the datasheet were documented incorrectly.
>
> Maybe this bit 10 is indeed a 5/10 divider, as amlogic claims it is. Maybe, as
> Emiliano suggested, the output rate of div250 actually needs to be 250Mhz in
> RGMII, before being divided by 10 to produce the 25MHz of div25
>
> IOW, maybe we need this intermediate rate.
I am starting to believe that you (Emiliano and Jerome) are both right
does anyone of you have access to a scope so we can measure the actual
clock output?
> It would not be surprising, 1GBps usually requires a 125MHz clock somewhere.
this could mean that two clocks are derived from m250_div (names are
not final obviously):
- phy_ref_clk (25MHz or 50MHz)
- rgmii_tx_clk (fixed divide by 2, 125MHz)
> This is still doable:
> * Keep the divider
> * drop CLK_SET_RATE_PARENT on div25
> * call set_rate on div250 with 250MHz then on div25 with 25Mhz
yep, I will try this next
this would also be work with the assumption that the rgmii_tx_clk is
derived from m250_div
>
>>
>> Tests have shown that without bit 10 set the RTL8211F RGMII PHY on
>> Odroid-C1 (using a Meson8b SoC) does not work.
>> On GXBB and newer SoCs (where the driver was initially tested with RGMII
>> PHYs) this is not a problem because the input clock is running at 1GHz.
>> The m250_div clock's biggest possible divider is 7 (3-bit divider, with
>> value 0 being reserved). Thus we end up with a m250_div of 4 and a
>> "m25_div" of 10 (= register value 1).
>>
>> Instead it turns out that the Ethernet IP block seems to have a fixed
>> "divide by 10" clock internally. This means that bit 10 is a gate clock
>> which enables the RGMII clock output.
>>
>> This replaces the "m25_div" clock with a clock gate called "m25_en"
>> which ensures that we can set this bit to 1 whenever we enable RGMII
>> mode. This however means that we are now missing a "divide by 10" after
>> the m250_div (and before our new m25_en), otherwise the common clock
>> framework thinks that the rate of the m25_en clock is 10-times higher
>> than it is in the actual hardware. That is solved by adding a
>> fixed-factor clock which divides the m250_div output by 10.
>>
>> Fixes: 566e8251625304 ("net: stmmac: add a glue driver for the Amlogic Meson 8b / GXBB DWMAC")
>> Reported-by: Emiliano Ingrassia <ingrassia@epigenesys.com>
>> Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
>> ---
>> .../net/ethernet/stmicro/stmmac/dwmac-meson8b.c | 66 +++++++++++++---------
>> 1 file changed, 38 insertions(+), 28 deletions(-)
>>
>> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c
>> index 1c14210df465..7199e8c08536 100644
>> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c
>> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c
>> @@ -40,9 +40,7 @@
>> #define PRG_ETH0_CLK_M250_DIV_SHIFT 7
>> #define PRG_ETH0_CLK_M250_DIV_WIDTH 3
>>
>> -/* divides the result of m25_sel by either 5 (bit unset) or 10 (bit set) */
>> -#define PRG_ETH0_CLK_M25_DIV_SHIFT 10
>> -#define PRG_ETH0_CLK_M25_DIV_WIDTH 1
>> +#define PRG_ETH0_GENERATE_25M_PHY_CLOCK 10
>>
>> #define PRG_ETH0_INVERTED_RMII_CLK BIT(11)
>> #define PRG_ETH0_TX_AND_PHY_REF_CLK BIT(12)
>> @@ -63,8 +61,11 @@ struct meson8b_dwmac {
>> struct clk_divider m250_div;
>> struct clk *m250_div_clk;
>>
>> - struct clk_divider m25_div;
>> - struct clk *m25_div_clk;
>> + struct clk_fixed_factor fixed_div10;
>> + struct clk *fixed_div10_clk;
>> +
>> + struct clk_gate m25_en;
>> + struct clk *m25_en_clk;
>
> Maybe it could be the topic of another series but we don't need to keep all
> those structures around, thanks to devm
>
> all clk_divider, fixed_factor, gate and mux can go away
> You only need to keep the'struct clk*' you are going to use later on
>
> at the moment it would be m25_en_clk only.
let's get the whole thing to work first, then I will have another look
at the struct members (it already annoyed me too)
PS: on another note: the title of this series and most patches is
wrong as I just discovered:
the 25MHz clock is *NOT* the RGMII clock, but it's the "PHY reference
clock". Hardkernel calls it "ETH_PHY_REF_CLK_25MOUT" in their
Odroid-C1 schematics [4] on page 23, which is the only actual
description I could find for this pin (on the Khadas VIM2 schematics
for example there's a 25MHz clock seemingly coming out of nowhere)
I used three publicly available datasheets for reference:
1) TI DP83822 (MII/RMII/RGMII): [0]
page: 5
pin: XI
description for MII and RGMII: Reference clock 25-MHz ±50
ppm-tolerance crystal or oscillator input. The device supports either
an external crystal resonator connected across pins XI and XO, or an
external CMOS-level oscillator connected to pin XI only
description for RMII: RMII reference clock: Reference clock 50-MHz ±50
ppm-tolerance CMOS-level oscillator in RMII Slave mode. Reference
clock 25-MHz ±50 ppm-tolerance crystal or oscillator in RMII Master
mode.
2) micrel DP83822 (RGMII): [1]
page: 13
pin: XI
description: Crystal / Oscillator / External Clock Input
25MHz ±50ppm tolerance
3) Realtek RTL8211E (RGMII, should be close to the RTL8211F PHY on our
Amlogic boards): [2]
page: 17
pin: CKXTAL1
description: 25/50MHz Crystal Input
this shows that Ethernet PHYs "typically" support 25MHz and 50MHz as
"reference clock input"
it also supports Emiliano's and Jerome's suggestion that m250_div
should run at 250MHz and m25_div might act as a divide-by-5 or
divide-by-10 bit.
Regards
Martin
[0] http://www.ti.com/lit/ds/symlink/dp83822h.pdf
[1] https://datasheet.lcsc.com/szlcsc/KSZ9031RNXCA_C58758.pdf
[2] https://www.pine64.pro/download/documents/realtek-10-100-1000-ethernet.pdf
[3] https://dn.odroid.com/S805/Schematics/odroid-c1+_rev0.4_20160226.pdf
^ permalink raw reply
* [PATCH] af_key: fix buffer overread in verify_address_len()
From: Eric Biggers @ 2017-12-30 0:13 UTC (permalink / raw)
To: netdev, Steffen Klassert, Herbert Xu, David S . Miller
Cc: Alexander Potapenko, Dmitry Vyukov, Kostya Serebryany, syzkaller,
Eric Biggers, stable
In-Reply-To: <CACT4Y+bVLWvMTqf4PoOJtu4_r5GseVAjDqE53kvm87ocxQz-ww@mail.gmail.com>
From: Eric Biggers <ebiggers@google.com>
If a message sent to a PF_KEY socket ended with one of the extensions
that takes a 'struct sadb_address' but there were not enough bytes
remaining in the message for the ->sa_family member of the 'struct
sockaddr' which is supposed to follow, then verify_address_len() read
past the end of the message, into uninitialized memory. Fix it by
returning -EINVAL in this case.
This bug was found using syzkaller with KMSAN.
Reproducer:
#include <linux/pfkeyv2.h>
#include <sys/socket.h>
#include <unistd.h>
int main()
{
int sock = socket(PF_KEY, SOCK_RAW, PF_KEY_V2);
char buf[24] = { 0 };
struct sadb_msg *msg = (void *)buf;
struct sadb_address *addr = (void *)(msg + 1);
msg->sadb_msg_version = PF_KEY_V2;
msg->sadb_msg_type = SADB_DELETE;
msg->sadb_msg_len = 3;
addr->sadb_address_len = 1;
addr->sadb_address_exttype = SADB_EXT_ADDRESS_SRC;
write(sock, buf, 24);
}
Reported-by: Alexander Potapenko <glider@google.com>
Cc: stable@vger.kernel.org
Signed-off-by: Eric Biggers <ebiggers@google.com>
---
net/key/af_key.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/net/key/af_key.c b/net/key/af_key.c
index 3dffb892d52c..596499cc8b2f 100644
--- a/net/key/af_key.c
+++ b/net/key/af_key.c
@@ -401,6 +401,11 @@ static int verify_address_len(const void *p)
#endif
int len;
+ if (sp->sadb_address_len <
+ DIV_ROUND_UP(sizeof(*sp) + offsetofend(typeof(*addr), sa_family),
+ sizeof(uint64_t)))
+ return -EINVAL;
+
switch (addr->sa_family) {
case AF_INET:
len = DIV_ROUND_UP(sizeof(*sp) + sizeof(*sin), sizeof(uint64_t));
--
2.15.1
^ permalink raw reply related
* Re: [PATCH v3 bpf-next 1/2] tools/bpftool: use version from the kernel source tree
From: Daniel Borkmann @ 2017-12-30 0:13 UTC (permalink / raw)
To: Roman Gushchin, netdev; +Cc: linux-kernel, kernel-team, Alexei Starovoitov
In-Reply-To: <20171227191629.4920-1-guro@fb.com>
On 12/27/2017 08:16 PM, Roman Gushchin wrote:
> Bpftool determines it's own version based on the kernel
> version, which is picked from the linux/version.h header.
>
> It's strange to use the version of the installed kernel
> headers, and makes much more sense to use the version
> of the actual source tree, where bpftool sources are.
>
> Fix this by building kernelversion target and use
> the resulting string as bpftool version.
Series applied to bpf-next, thanks everyone!
^ permalink raw reply
* [PATCH] af_key: fix buffer overread in parse_exthdrs()
From: Eric Biggers @ 2017-12-30 0:15 UTC (permalink / raw)
To: netdev, Steffen Klassert, Herbert Xu, David S . Miller
Cc: Alexander Potapenko, Dmitry Vyukov, Kostya Serebryany, syzkaller,
Eric Biggers, stable
From: Eric Biggers <ebiggers@google.com>
If a message sent to a PF_KEY socket ended with an incomplete extension
header (fewer than 4 bytes remaining), then parse_exthdrs() read past
the end of the message, into uninitialized memory. Fix it by returning
-EINVAL in this case.
Reproducer:
#include <linux/pfkeyv2.h>
#include <sys/socket.h>
#include <unistd.h>
int main()
{
int sock = socket(PF_KEY, SOCK_RAW, PF_KEY_V2);
char buf[17] = { 0 };
struct sadb_msg *msg = (void *)buf;
msg->sadb_msg_version = PF_KEY_V2;
msg->sadb_msg_type = SADB_DELETE;
msg->sadb_msg_len = 2;
write(sock, buf, 17);
}
Cc: stable@vger.kernel.org
Signed-off-by: Eric Biggers <ebiggers@google.com>
---
net/key/af_key.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/net/key/af_key.c b/net/key/af_key.c
index 596499cc8b2f..d40861a048fe 100644
--- a/net/key/af_key.c
+++ b/net/key/af_key.c
@@ -516,6 +516,9 @@ static int parse_exthdrs(struct sk_buff *skb, const struct sadb_msg *hdr, void *
uint16_t ext_type;
int ext_len;
+ if (len < sizeof(*ehdr))
+ return -EINVAL;
+
ext_len = ehdr->sadb_ext_len;
ext_len *= sizeof(uint64_t);
ext_type = ehdr->sadb_ext_type;
--
2.15.1
^ permalink raw reply related
* Re: KMSAN reports use of uninitialized memory in pfkey_sendmsg()
From: Eric Biggers @ 2017-12-30 0:19 UTC (permalink / raw)
To: Dmitry Vyukov
Cc: Alexander Potapenko, David Miller, Steffen Klassert, Herbert Xu,
Networking, syzkaller, Kostya Serebryany
In-Reply-To: <CACT4Y+bVLWvMTqf4PoOJtu4_r5GseVAjDqE53kvm87ocxQz-ww@mail.gmail.com>
On Fri, Dec 29, 2017 at 05:49:34PM +0100, Dmitry Vyukov wrote:
> On Fri, Dec 29, 2017 at 5:48 PM, Alexander Potapenko <glider@google.com> wrote:
> > Hi all,
> >
> > KMSAN reports a use of uninitialized value on the following program:
> >
> > ==========================
> > // autogenerated by syzkaller (http://github.com/google/syzkaller)
> >
> > #include <string.h>
> > #include <sys/types.h>
> > #include <sys/socket.h>
> >
> > int main()
> > {
> > int sock = socket(PF_KEY, SOCK_RAW, 2);
> > char buf[24];
> > memset(buf, 0, 24);
> > buf[0] = 2;
> > buf[1] = 4;
> > buf[4] = 3;
> > buf[16] = 1;
> > buf[18] = 0x17; // SADB_X_EXT_NAT_T_OA
> > struct msghdr hdr;
> > memset(&hdr, 0, sizeof(struct msghdr));
> > struct iovec iov;
> > hdr.msg_iov = &iov;
> > hdr.msg_iovlen = 1;
> > iov.iov_base = buf;
> > iov.iov_len = 0x18;
> > sendmsg(sock, &hdr, 0);
> > }
> > ==========================
> >
> > the report is below:
> >
> > ==================================================================
> > BUG: KMSAN: use of uninitialized memory in pfkey_sendmsg+0x11ad/0x1900
> > CPU: 0 PID: 2946 Comm: probe Not tainted 4.13.0+ #3626
> > Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
> > Call Trace:
> > show_stack+0x12f/0x180 arch/x86/kernel/dumpstack.c:177
> > __dump_stack lib/dump_stack.c:16
> > dump_stack+0x185/0x1d0 lib/dump_stack.c:52
> > kmsan_report+0x137/0x1c0 mm/kmsan/kmsan.c:1066
> > __msan_warning_32+0x69/0xb0 mm/kmsan/kmsan_instr.c:676
> > verify_address_len net/key/af_key.c:404
> > parse_exthdrs net/key/af_key.c:532
> > pfkey_process net/key/af_key.c:2811
> > pfkey_sendmsg+0x11ad/0x1900 net/key/af_key.c:3654
> > sock_sendmsg_nosec net/socket.c:633
> > sock_sendmsg net/socket.c:643
> > ___sys_sendmsg+0xed5/0x1330 net/socket.c:2035
> > __sys_sendmsg net/socket.c:2069
> > SYSC_sendmsg+0x2a6/0x3d0 net/socket.c:2080
> > SyS_sendmsg+0x54/0x80 net/socket.c:2076
> > do_syscall_64+0x2f4/0x420 arch/x86/entry/common.c:284
> > entry_SYSCALL64_slow_path+0x25/0x25 arch/x86/entry/entry_64.S:245
> > RIP: 0033:0x401140
> > RSP: 002b:00007ffe52abc9e8 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
> > RAX: ffffffffffffffda RBX: 00000000004002b0 RCX: 0000000000401140
> > RDX: 0000000000000000 RSI: 00007ffe52abca10 RDI: 0000000000000003
> > RBP: 00007ffe52abca80 R08: 0000000000000002 R09: 0000000000000004
> > R10: 0000000000000004 R11: 0000000000000246 R12: 0000000000000000
> > R13: 00000000004063e0 R14: 0000000000406470 R15: 0000000000000000
> > origin:
> > save_stack_trace+0x16/0x20 arch/x86/kernel/stacktrace.c:63
> > kmsan_save_stack_with_flags mm/kmsan/kmsan.c:303
> > kmsan_internal_poison_shadow+0xb8/0x1b0 mm/kmsan/kmsan.c:213
> > kmsan_kmalloc+0x94/0x100 mm/kmsan/kmsan.c:339
> > kmsan_slab_alloc+0x11/0x20 mm/kmsan/kmsan.c:346
> > slab_post_alloc_hook mm/slab.h:442
> > slab_alloc_node mm/slub.c:2724
> > __kmalloc_node_track_caller+0xa46/0x1230 mm/slub.c:4335
> > __kmalloc_reserve net/core/skbuff.c:139
> > __alloc_skb+0x2c6/0x9f0 net/core/skbuff.c:232
> > alloc_skb ./include/linux/skbuff.h:904
> > pfkey_sendmsg+0x201/0x1900 net/key/af_key.c:3641
> > sock_sendmsg_nosec net/socket.c:633
> > sock_sendmsg net/socket.c:643
> > ___sys_sendmsg+0xed5/0x1330 net/socket.c:2035
> > __sys_sendmsg net/socket.c:2069
> > SYSC_sendmsg+0x2a6/0x3d0 net/socket.c:2080
> > SyS_sendmsg+0x54/0x80 net/socket.c:2076
> > do_syscall_64+0x2f4/0x420 arch/x86/entry/common.c:284
> > return_from_SYSCALL_64+0x0/0x6a arch/x86/entry/entry_64.S:245
> > ==================================================================
> >
> > Apparently pfkey_sendmsg reads skb past the end of the buffer copied
> > from the userspace.
> > Could someone please take a look?
>
Thanks for reporting this! The problem is that verify_address_len() doesn't
verify that the buffer has space for the ->sa_family field before reading it.
I've sent out a patch.
I also noticed a similar bug in parse_exthdrs(); it doesn't verify that the
buffer has space for the 'struct sadb_ext' before reading it. I've sent out a
patch for that as well.
Eric
^ permalink raw reply
* RE: ATTENTION!!!
From: Loretta Robles @ 2017-12-30 0:28 UTC (permalink / raw)
To: Loretta Robles
In-Reply-To: <35D4F79A8B8138489F38DE5CF6200454E570015C@HCI-EX-MB2.hci.utah.edu>
________________________________
From: Loretta Robles
Sent: Friday, December 29, 2017 1:01 PM
To: Loretta Robles
Subject: ATTENTION!!!
You have been randomly selected for a donation. Contact soriz4040@gmail.com for claims.
^ permalink raw reply
* Re: b53 tags on bpi-r1 (bcm53125)
From: Florian Fainelli @ 2017-12-30 3:22 UTC (permalink / raw)
To: Jochen Friedrich; +Cc: netdev
In-Reply-To: <1552ddff-4c48-689f-d941-15d5b0a52f47@gmail.com>
Le 12/29/17 à 13:56, Florian Fainelli a écrit :
> Le 12/29/17 à 12:21, Florian Fainelli a écrit :
>> Hi Jochen,
>>
>> Le 12/18/17 à 02:44, Jochen Friedrich a écrit :
>>> Hi Florian,
>>>
>>> unfortunately, this doesn't make any difference.
>>>
>>> Just out of curiosity, BPI-R1 has pull-down resistors on LED6 and 7
>>> (MII_MODE0/1). However, the public available 53125U sheet doesn't
>>> document these pins:
>>>
>>> LED[6] IMP_MODE[0] Pull-up Active low (since IMP Mode is not used)
>>> LED[7] IMP_MODE[1] Pull-up Active low (since IMP Mode is not used)
>>>
>>> Is this MII mode maybe incompatible with Broadcom tags?
>>
>> AFAICT, it should not, this is largely independent from enabling
>> Broadcom tags.
>>
>> I have now reproduced this on my BPI-R1 as well and am looking at what
>> might be going wrong.
>
> OK, so I have been able to find out what was going on. On BCM53125 and
> earlier switches, we need to do a couple of things for Broadcom tags to
> be usable:
>
> - turn on managed mode (SM_SW_FWD_MODE)
> - configure Port 8 for IMP mode (B53_GLOBAL_CONFIG, setting bit
> GC_FRM_MGMT_PORT_MII)
>
> After doing that, I can now see the correct outgoing packets on my host,
> however, the replies don't seem to be delivered to the per-port DSA
> network devices, and I suspect it's because of stmmac, so I am
> investigating this now.
>
So stmmac was indeed part of the problem. I had to clear the
GMAC_CONTROL_ACS bit in GMAC_CORE_INIT in order to allow stmmac to
properly receive packets, otherwise, packets were truncated to 8 bytes
on reception which I assume is because the Broadcom tags may look like
some sort of weird LLC/SNAP packet which was confusing the hardware.
This is all working correctly now after a bunch of changes that I will
submit in the next few days.
Preliminary patches available here:
https://github.com/ffainelli/linux/commits/stmmac-fixes
Thank you very much for your patience!
--
Florian
^ permalink raw reply
* [PATCH net-next 0/2] net: stmmac: Couple of debug prints improvements
From: Florian Fainelli @ 2017-12-30 3:56 UTC (permalink / raw)
To: netdev
Cc: davem, Florian Fainelli, Giuseppe Cavallaro, Alexandre Torgue,
open list
Hi all,
While working on a particular problem, I had to turn on debug prints and found
them to be useful, but could deserve some improvements in order to help debug
situations.
Florian Fainelli (2):
net: stmmac: Pad ring number with zeroes in display_ring()
net: stmmac: Allow debug prints of frame_len/COE
drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.c | 2 +-
drivers/net/ethernet/stmicro/stmmac/enh_desc.c | 2 +-
drivers/net/ethernet/stmicro/stmmac/norm_desc.c | 2 +-
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 5 ++---
4 files changed, 5 insertions(+), 6 deletions(-)
--
2.14.1
^ permalink raw reply
* [PATCH net-next 1/2] net: stmmac: Pad ring number with zeroes in display_ring()
From: Florian Fainelli @ 2017-12-30 3:56 UTC (permalink / raw)
To: netdev
Cc: davem, Florian Fainelli, Giuseppe Cavallaro, Alexandre Torgue,
open list
In-Reply-To: <20171230035633.29514-1-f.fainelli@gmail.com>
Make the printing of the ring number consistent and properly aligned by
padding the ring number with up to 3 zeroes, which covers the maximum
ring size. This makes it a lot easier to see outliers in debug prints.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.c | 2 +-
drivers/net/ethernet/stmicro/stmmac/enh_desc.c | 2 +-
drivers/net/ethernet/stmicro/stmmac/norm_desc.c | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.c b/drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.c
index 7e089bf906b4..2fd8456999f6 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.c
@@ -406,7 +406,7 @@ static void dwmac4_display_ring(void *head, unsigned int size, bool rx)
pr_info("%s descriptor ring:\n", rx ? "RX" : "TX");
for (i = 0; i < size; i++) {
- pr_info("%d [0x%x]: 0x%x 0x%x 0x%x 0x%x\n",
+ pr_info("%03d [0x%x]: 0x%x 0x%x 0x%x 0x%x\n",
i, (unsigned int)virt_to_phys(p),
le32_to_cpu(p->des0), le32_to_cpu(p->des1),
le32_to_cpu(p->des2), le32_to_cpu(p->des3));
diff --git a/drivers/net/ethernet/stmicro/stmmac/enh_desc.c b/drivers/net/ethernet/stmicro/stmmac/enh_desc.c
index 2a828a312814..b47cb5c4da51 100644
--- a/drivers/net/ethernet/stmicro/stmmac/enh_desc.c
+++ b/drivers/net/ethernet/stmicro/stmmac/enh_desc.c
@@ -428,7 +428,7 @@ static void enh_desc_display_ring(void *head, unsigned int size, bool rx)
u64 x;
x = *(u64 *)ep;
- pr_info("%d [0x%x]: 0x%x 0x%x 0x%x 0x%x\n",
+ pr_info("%03d [0x%x]: 0x%x 0x%x 0x%x 0x%x\n",
i, (unsigned int)virt_to_phys(ep),
(unsigned int)x, (unsigned int)(x >> 32),
ep->basic.des2, ep->basic.des3);
diff --git a/drivers/net/ethernet/stmicro/stmmac/norm_desc.c b/drivers/net/ethernet/stmicro/stmmac/norm_desc.c
index db4cee57bb24..ebd9e5e00f16 100644
--- a/drivers/net/ethernet/stmicro/stmmac/norm_desc.c
+++ b/drivers/net/ethernet/stmicro/stmmac/norm_desc.c
@@ -288,7 +288,7 @@ static void ndesc_display_ring(void *head, unsigned int size, bool rx)
u64 x;
x = *(u64 *)p;
- pr_info("%d [0x%x]: 0x%x 0x%x 0x%x 0x%x",
+ pr_info("%03d [0x%x]: 0x%x 0x%x 0x%x 0x%x",
i, (unsigned int)virt_to_phys(p),
(unsigned int)x, (unsigned int)(x >> 32),
p->des2, p->des3);
--
2.14.1
^ permalink raw reply related
* [PATCH net-next 2/2] net: stmmac: Allow debug prints of frame_len/COE
From: Florian Fainelli @ 2017-12-30 3:56 UTC (permalink / raw)
To: netdev
Cc: davem, Florian Fainelli, Giuseppe Cavallaro, Alexandre Torgue,
open list
In-Reply-To: <20171230035633.29514-1-f.fainelli@gmail.com>
There is no reason not to allow printing the frame_len/COE value and put
that under a check for ETH_FRAME_LEN, drop it so we can see what the
descriptor reports.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 0323d672e1c5..d9c98fd810bb 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -3436,9 +3436,8 @@ static int stmmac_rx(struct stmmac_priv *priv, int limit, u32 queue)
if (netif_msg_rx_status(priv)) {
netdev_dbg(priv->dev, "\tdesc: %p [entry %d] buff=0x%x\n",
p, entry, des);
- if (frame_len > ETH_FRAME_LEN)
- netdev_dbg(priv->dev, "frame size %d, COE: %d\n",
- frame_len, status);
+ netdev_dbg(priv->dev, "frame size %d, COE: %d\n",
+ frame_len, status);
}
/* The zero-copy is always used for all the sizes
--
2.14.1
^ permalink raw reply related
* Re: iproute2 net-next
From: Stephen Hemminger @ 2017-12-30 4:00 UTC (permalink / raw)
To: Jiri Pirko; +Cc: Daniel Borkmann, Leon Romanovsky, netdev, dsa
In-Reply-To: <20171229085823.GA2000@nanopsycho>
On Fri, 29 Dec 2017 09:58:23 +0100
Jiri Pirko <jiri@resnulli.us> wrote:
> Fri, Dec 29, 2017 at 12:46:31AM CET, daniel@iogearbox.net wrote:
> >On 12/26/2017 10:35 AM, Leon Romanovsky wrote:
> >> On Mon, Dec 25, 2017 at 10:14:26PM -0800, Stephen Hemminger wrote:
> >>> On Tue, 26 Dec 2017 06:47:43 +0200
> >>> Leon Romanovsky <leon@kernel.org> wrote:
> >>>
> >>>> On Mon, Dec 25, 2017 at 10:49:19AM -0800, Stephen Hemminger wrote:
> >>>>> David Ahern has agreed to take over managing the net-next branch of iproute2.
> >>>>> The new location is:
> >>>>> https://git.kernel.org/pub/scm/linux/kernel/git/dsahern/iproute2-next.git/
> >>>>>
> >>>>> In the past, I have accepted new features into iproute2 master branch, but
> >>>>> am changing the policy so that outside of the merge window (up until -rc1)
> >>>>> new features will get put into net-next to get some more review and testing
> >>>>> time. This means that things like the proposed batch streaming mode will
> >>>>> go through net-next.
> >>>>
> >>>> Did you consider to create one shared repo for the iproute2 to allow
> >>>> multiple committers workflow?
> >>>
> >>> For now having separate trees is best, there is no need for multiple
> >>> committers the load is very light.
> >>>
> >>>> It will be much convenient for the users to have one place for
> >>>> master/stable/net-next branches, instead of actually following two
> >>>> different repositories.
> >>>
> >>> If you are doing network development, you already need to deal with
> >>> multiple repo's on the kernel side so there is no difference.
> >>
> >> I agree with you that one extra "git remote add .." is not so huge and
> >> all people who develop for the netdev will do it. My concern is about
> >> Documentation and newcomers, who will have a hard time to find a right
> >> tree.
> >
> >I guess it would certainly help to identify the official repo to rebase
> >against much quicker if it would be under a common group on korg e.g.
> >
> > * iproute2/iproute2.git - for current cycle
> > * iproute2/iproute2-next.git - for net-next bits
> >
> >and also be in line with other tooling (ethtool and others), even if
> >not as high volume, but it would make it unambiguous right away from
> >the other, private iproute2 repos on korg, imho. Just a thought.
>
> +1
>
> I was about to suggest this. This is nice opportunity to do such change.
>
>
> >
> >>>> Example, of such shared repo:
> >>>> BPF: https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git/
> >>>> Bluetooth: https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git/
> >>>> RDMA: https://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma.git/
> >>>
> >>> Most of these are high volume or vendor silo'd which is not the case here.
> >Cheers,
> >Daniel
Good news
kup does support links so could make links from personal to iproute2 directory
Bad news
kup won't allow me to make iproute2 directory right now. Will have to wait for
Konstantin
^ permalink raw reply
* Re: [PATCH iproute2 2/4] man: add more keywords to ip.8 short description
From: Stephen Hemminger @ 2017-12-30 4:02 UTC (permalink / raw)
To: Luca Boccassi; +Cc: netdev
In-Reply-To: <20171229220125.13579-2-bluca@debian.org>
On Fri, 29 Dec 2017 23:01:23 +0100
Luca Boccassi <bluca@debian.org> wrote:
> A Debian user suggested adding more network-related keywords to the
> ip manpage, so that manpage-scraping and indexing software like
> apropos can do a better job of categorizing the programs.
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=877983
>
> Suggested-by: Lynoure Braakman <lynoure@gmail.com>
> Signed-off-by: Luca Boccassi <bluca@debian.org>
> ---
> man/man8/ip.8 | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/man/man8/ip.8 b/man/man8/ip.8
> index ae018fdf..94e64319 100644
> --- a/man/man8/ip.8
> +++ b/man/man8/ip.8
> @@ -1,6 +1,6 @@
> .TH IP 8 "20 Dec 2011" "iproute2" "Linux"
> .SH NAME
> -ip \- show / manipulate routing, devices, policy routing and tunnels
> +ip \- show / manipulate routing, network devices, policy routing, interfaces (ethernet and more) and tunnels
Let's just keep it short and drop out policy routing (since that is part of routing anyway
and drop the (ethernet and more).
^ permalink raw reply
* Re: [PATCH iproute2 3/4] man: ip-address: document 15-char limit for LABEL
From: Stephen Hemminger @ 2017-12-30 4:04 UTC (permalink / raw)
To: Luca Boccassi; +Cc: netdev
In-Reply-To: <20171229220125.13579-3-bluca@debian.org>
On Fri, 29 Dec 2017 23:01:24 +0100
Luca Boccassi <bluca@debian.org> wrote:
> Trying to set a label longer than 15 characters returns an error:
> RTNETLINK answers: Numerical result out of range
>
> Document the limit in the manpage.
>
> Originally reported as a Debian bug:
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=661886
>
> Reported-by: Gabor Kiss <kissg@ssg.ki.iif.hu>
> Signed-off-by: Luca Boccassi <bluca@debian.org>
> ---
> man/man8/ip-address.8.in | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/man/man8/ip-address.8.in b/man/man8/ip-address.8.in
> index eaa179c6..e7f14533 100644
> --- a/man/man8/ip-address.8.in
> +++ b/man/man8/ip-address.8.in
> @@ -190,6 +190,7 @@ Each address may be tagged with a label string.
> In order to preserve compatibility with Linux-2.0 net aliases,
> this string must coincide with the name of the device or must be prefixed
> with the device name followed by colon.
> +The maximum allowed length is 15 characters.
Since these are aliases, lets be precise:
The maximum allowed total length of label is 15 characters.
^ permalink raw reply
* Re: [PATCH iproute2 4/4] man: routel/routef: don't mention filesystem paths
From: Stephen Hemminger @ 2017-12-30 4:05 UTC (permalink / raw)
To: Luca Boccassi; +Cc: netdev
In-Reply-To: <20171229220125.13579-4-bluca@debian.org>
On Fri, 29 Dec 2017 23:01:25 +0100
Luca Boccassi <bluca@debian.org> wrote:
> The filesytem paths to these scripts might be different on various
> distros, so don't mention it in the manpages. It is not really useful
> information anyway.
>
> Originally submitted as Debian bug:
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=561424
>
> Reported-by: jidanni@jidanni.org
> Signed-off-by: Luca Boccassi <bluca@debian.org>
> ---
> man/man8/routel.8 | 5 -----
> 1 file changed, 5 deletions(-)
>
> diff --git a/man/man8/routel.8 b/man/man8/routel.8
> index 82d580fb..2270eacb 100644
> --- a/man/man8/routel.8
> +++ b/man/man8/routel.8
> @@ -17,11 +17,6 @@ The routel script will list routes in a format that some might consider easier t
> .br
> The routef script does not take any arguments and will simply flush the routing table down the drain. Beware! This means deleting all routes which will make your network unusable!
>
> -.SH "FILES"
> -.LP
> -\fI/usr/bin/routef\fP
> -.br
> -\fI/usr/bin/routel\fP
> .SH "AUTHORS"
> .LP
> The routel script was written by Stephen R. van den Berg <srb@cuci.nl>, 1999/04/18 and donated to the public domain.
Sure hardcode paths are not good.
Alternative would be generate man page like ipaddress is.
^ permalink raw reply
* Re: [PATCH net-next v5 0/5] Introduce NETIF_F_GRO_HW
From: Michael Chan @ 2017-12-30 5:20 UTC (permalink / raw)
To: Alexander Duyck; +Cc: Sabrina Dubroca, David Miller, Netdev, Andrew Gospodarek
In-Reply-To: <CAKgT0Ufzvnf=0Sg3S9jkGKK+ze+7j_sLdqkw4q=-OdEcyRU=GA@mail.gmail.com>
On Fri, Dec 29, 2017 at 7:12 AM, Alexander Duyck
<alexander.duyck@gmail.com> wrote:
> On Fri, Dec 29, 2017 at 4:43 AM, Sabrina Dubroca <sd@queasysnail.net> wrote:
>> 2017-12-22, 10:14:32 -0800, Alexander Duyck wrote:
>>> On Fri, Dec 22, 2017 at 6:57 AM, Sabrina Dubroca <sd@queasysnail.net> wrote:
>>> > IIUC, with the patches that were applied, each driver can define
>>> > whether GRO_HW depends on GRO? From a user's perspective, this
>>> > inconsistent behavior is going to be quite confusing.
>>> >
>>> > Worse than inconsistent behavior, it looks like a driver deciding that
>>> > GRO_HW doesn't depend on GRO is going to introduce a change of
>>> > behavior. Previously, when GRO was disabled, there wouldn't be any
>>> > packet over MTU handed to the network stack. Now, even if GRO is
>>> > disabled, GRO_HW might still be enabled, so we might get over-MTU
>>> > packets because of hardware GRO.
>>>
>>> This isn't actually true. LRO was still handling packets larger than
>>> MTU over even when GRO was disabled.
>>
>> Sure, LRO will also cause that, but we're speaking in the context of
>> GRO here, which means no LRO.
>
> We are talking about GRO_HW. Which is basically aggregation being
> performed in hardware. The choice of name is unfortunate though since
> it implies this is GRO when what is actually happening is just
> GRO-like. Really the only difference between LRO and GRO_HW is that
> the frames are better formed in the final result. It is a matter of
> what is performed versus where it is performed.
I think the name GRO_HW is perfectly fine. It is GRO aggregation done
in hardware, and hardware providing extra information to the driver to
setup the SKB just like GRO. I don't know what better name to call it
than GRO_HW.
^ permalink raw reply
* RE: [PATCH v3] igb: Free IRQs when device is hotplugged
From: Brown, Aaron F @ 2017-12-30 5:51 UTC (permalink / raw)
To: Lyude Paul, intel-wired-lan@lists.osuosl.org
Cc: Fujinaka, Todd, Stephen Hemminger, stable@vger.kernel.org,
Kirsher, Jeffrey T, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <20171212193130.5971-1-lyude@redhat.com>
> From: netdev-owner@vger.kernel.org [mailto:netdev-
> owner@vger.kernel.org] On Behalf Of Lyude Paul
> Sent: Tuesday, December 12, 2017 11:32 AM
> To: intel-wired-lan@lists.osuosl.org
> Cc: Fujinaka, Todd <todd.fujinaka@intel.com>; Stephen Hemminger
> <stephen@networkplumber.org>; stable@vger.kernel.org; Kirsher, Jeffrey T
> <jeffrey.t.kirsher@intel.com>; netdev@vger.kernel.org; linux-
> kernel@vger.kernel.org
> Subject: [PATCH v3] igb: Free IRQs when device is hotplugged
>
> Recently I got a Caldigit TS3 Thunderbolt 3 dock, and noticed that upon
> hotplugging my kernel would immediately crash due to igb:
>
> [ 680.825801] kernel BUG at drivers/pci/msi.c:352!
> [ 680.828388] invalid opcode: 0000 [#1] SMP
> [ 680.829194] Modules linked in: igb(O) thunderbolt i2c_algo_bit joydev vfat
> fat btusb btrtl btbcm btintel bluetooth ecdh_generic hp_wmi
> sparse_keymap rfkill wmi_bmof iTCO_wdt intel_rapl
> x86_pkg_temp_thermal coretemp crc32_pclmul snd_pcm rtsx_pci_ms
> mei_me snd_timer memstick snd pcspkr mei soundcore i2c_i801 tpm_tis
> psmouse shpchp wmi tpm_tis_core tpm video hp_wireless acpi_pad
> rtsx_pci_sdmmc mmc_core crc32c_intel serio_raw rtsx_pci mfd_core
> xhci_pci xhci_hcd i2c_hid i2c_core [last unloaded: igb]
> [ 680.831085] CPU: 1 PID: 78 Comm: kworker/u16:1 Tainted: G O
> 4.15.0-rc3Lyude-Test+ #6
> [ 680.831596] Hardware name: HP HP ZBook Studio G4/826B, BIOS P71 Ver.
> 01.03 06/09/2017
> [ 680.832168] Workqueue: kacpi_hotplug acpi_hotplug_work_fn
> [ 680.832687] RIP: 0010:free_msi_irqs+0x180/0x1b0
> [ 680.833271] RSP: 0018:ffffc9000030fbf0 EFLAGS: 00010286
> [ 680.833761] RAX: ffff8803405f9c00 RBX: ffff88033e3d2e40 RCX:
> 000000000000002c
> [ 680.834278] RDX: 0000000000000000 RSI: 00000000000000ac RDI:
> ffff880340be2178
> [ 680.834832] RBP: 0000000000000000 R08: ffff880340be1ff0 R09:
> ffff8803405f9c00
> [ 680.835342] R10: 0000000000000000 R11: 0000000000000040 R12:
> ffff88033d63a298
> [ 680.835822] R13: ffff88033d63a000 R14: 0000000000000060 R15:
> ffff880341959000
> [ 680.836332] FS: 0000000000000000(0000) GS:ffff88034f440000(0000)
> knlGS:0000000000000000
> [ 680.836817] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [ 680.837360] CR2: 000055e64044afdf CR3: 0000000001c09002 CR4:
> 00000000003606e0
> [ 680.837954] Call Trace:
> [ 680.838853] pci_disable_msix+0xce/0xf0
> [ 680.839616] igb_reset_interrupt_capability+0x5d/0x60 [igb]
> [ 680.840278] igb_remove+0x9d/0x110 [igb]
> [ 680.840764] pci_device_remove+0x36/0xb0
> [ 680.841279] device_release_driver_internal+0x157/0x220
> [ 680.841739] pci_stop_bus_device+0x7d/0xa0
> [ 680.842255] pci_stop_bus_device+0x2b/0xa0
> [ 680.842722] pci_stop_bus_device+0x3d/0xa0
> [ 680.843189] pci_stop_and_remove_bus_device+0xe/0x20
> [ 680.843627] trim_stale_devices+0xf3/0x140
> [ 680.844086] trim_stale_devices+0x94/0x140
> [ 680.844532] trim_stale_devices+0xa6/0x140
> [ 680.845031] ? get_slot_status+0x90/0xc0
> [ 680.845536] acpiphp_check_bridge.part.5+0xfe/0x140
> [ 680.846021] acpiphp_hotplug_notify+0x175/0x200
> [ 680.846581] ? free_bridge+0x100/0x100
> [ 680.847113] acpi_device_hotplug+0x8a/0x490
> [ 680.847535] acpi_hotplug_work_fn+0x1a/0x30
> [ 680.848076] process_one_work+0x182/0x3a0
> [ 680.848543] worker_thread+0x2e/0x380
> [ 680.848963] ? process_one_work+0x3a0/0x3a0
> [ 680.849373] kthread+0x111/0x130
> [ 680.849776] ? kthread_create_worker_on_cpu+0x50/0x50
> [ 680.850188] ret_from_fork+0x1f/0x30
> [ 680.850601] Code: 43 14 85 c0 0f 84 d5 fe ff ff 31 ed eb 0f 83 c5 01 39 6b 14 0f
> 86 c5 fe ff ff 8b 7b 10 01 ef e8 b7 e4 d2 ff 48 83 78 70 00 74 e3 <0f> 0b 49 8d b5
> a0 00 00 00 e8 62 6f d3 ff e9 c7 fe ff ff 48 8b
> [ 680.851497] RIP: free_msi_irqs+0x180/0x1b0 RSP: ffffc9000030fbf0
>
> As it turns out, normally the freeing of IRQs that would fix this is called
> inside of the scope of __igb_close(). However, since the device is
> already gone by the point we try to unregister the netdevice from the
> driver due to a hotplug we end up seeing that the netif isn't present
> and thus, forget to free any of the device IRQs.
>
> So: make sure that if we're in the process of dismantling the netdev, we
> always allow __igb_close() to be called so that IRQs may be freed
> normally. Additionally, only allow igb_close() to be called from
> __igb_close() if it hasn't already been called for the given adapter.
>
> Signed-off-by: Lyude Paul <lyude@redhat.com>
> Fixes: 9474933caf21 ("igb: close/suspend race in netif_device_detach")
> Cc: Todd Fujinaka <todd.fujinaka@intel.com>
> Cc: Stephen Hemminger <stephen@networkplumber.org>
> Cc: stable@vger.kernel.org
> ---
> Changes since v2:
> - Remove hunk in __igb_close() that was left over by accident, it's
> not needed
>
> drivers/net/ethernet/intel/igb/igb_main.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
^ permalink raw reply
* Re: general protection fault in skb_segment
From: Willem de Bruijn @ 2017-12-30 7:42 UTC (permalink / raw)
To: syzbot
Cc: David Miller, LKML, linux-sctp, Network Development, nhorman,
syzkaller-bugs, vyasevich, marcelo.leitner
In-Reply-To: <001a1137452496ffc305617e5fe0@google.com>
> syzkaller hit the following crash on
> 37759fa6d0fa9e4d6036d19ac12f555bfc0aeafd
> git://git.cmpxchg.org/linux-mmots.git/master
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached
> Raw console output is attached.
> C reproducer is attached
> syzkaller reproducer is attached. See https://goo.gl/kgGztJ
> for information about syzkaller reproducers
Reproduced with the C reproducer on v4.15-rc1 and mainline
going back at least to v4.8, but not v4.7. SCTP GSO was
introduced in v4.8-rc1, so a patch in this set is likely the starting
point. Indeed crashes at 90017accff61 ("sctp: Add GSO support"),
but not at 90017accff61~4.
The reproducer with its sandbox removed shows this invocation in strace -f
# strace -f ./repro2
[... skipped ...]
socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 3
open("/dev/net/tun", O_RDONLY) = 4
fcntl(4, F_DUPFD, 3) = 5
socket(PF_PACKET, SOCK_RAW|SOCK_CLOEXEC, 8) = 6
ioctl(4, TUNSETIFF, 0x20e63000) = 0
ioctl(3, SIOCSIFFLAGS, {ifr_name="syz0",
ifr_flags=IFF_UP|IFF_PROMISC|IFF_ALLMULTI}) = 0
setsockopt(6, SOL_PACKET, 0xf /* PACKET_??? */, [4096], 4) = 0
ioctl(6, SIOCGIFINDEX, {ifr_name="syz0", ifr_index=24}) = 0
bind(6, {sa_family=AF_PACKET, proto=0000, if24, pkttype=PACKET_HOST,
addr(6)={1, aaaaaaaaaa00}, 20) = 0
dup2(6, 5) = 5
write(5, "\0\201\1\0\350\367\0\0\3\0E\364\0 \0d\0\0\7\2042\342\0\0\0
\177\0\0\1\0\t"..., 42
where 0xf in setsockopt is PACKET_VNET_HDR
So this is a packet socket writing something that apparently looks
like an SCTP packet, is only 42 bytes long, but has GSO set in its
virtio_net_hdr struct.
It crashes in skb_segment seemingly on a NULL list_skb.
(gdb) list *(skb_segment+0x2a4)
0xffffffff8167cc24 is in skb_segment (net/core/skbuff.c:3566).
3561 if (hsize < 0)
3562 hsize = 0;
3563 if (hsize > len || !sg)
3564 hsize = len;
3565
3566 if (!hsize && i >= nfrags && skb_headlen(list_skb) &&
3567 (skb_headlen(list_skb) == len || sg)) {
3568 BUG_ON(skb_headlen(list_skb) > len);
3569
3570 i = 0;
Likely there is a hidden assumption about SCTP GSO packets that does
not hold for such packets generated by PF_PACKET.
SCTP GSO introduced the GSO_BY_FRAGS mss value, so the code
takes a different path for SCTP packets generated by the SCTP stack.
PF_PACKET does not necessarily set gso_size to GSO_BY_FRAGS, so
does not take the branch that requires list_skb to be non-zero here:
if (unlikely(mss == GSO_BY_FRAGS)) {
len = list_skb->len;
} else {
len = head_skb->len - offset;
if (len > mss)
len = mss;
}
hsize = skb_headlen(head_skb) - offset;
if (hsize < 0)
hsize = 0;
if (hsize > len || !sg)
hsize = len;
if (!hsize && i >= nfrags && skb_headlen(list_skb) &&
(skb_headlen(list_skb) == len || sg)) {
Somewhat tangential, but any PF_PACKET socket can set this
magic gso_size value in its virtio_net_hdr, so if it is assumed to
be an SCTP GSO specific option, setting it for a TCP GSO packet
may also cause unexpected results.
The crash requires a kernel with CONFIG_IP_SCTP enabled.
^ permalink raw reply
* Re: [PATCHv3 0/2] capability controlled user-namespaces
From: James Morris @ 2017-12-30 8:31 UTC (permalink / raw)
To: Mahesh Bandewar (महेश बंडेवार)
Cc: LKML, Netdev, Kernel-hardening, Linux API, Kees Cook,
Serge Hallyn, Eric W . Biederman, Eric Dumazet, David Miller,
Mahesh Bandewar
In-Reply-To: <CAF2d9jit74_VCdD-pEFy3bJo2W1-0cDo0BOJC5beJiy8yFPCWg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 4949 bytes --]
On Wed, 27 Dec 2017, Mahesh Bandewar (महेश बंडेवार) wrote:
> Hello James,
>
> Seems like I missed your name to be added into the review of this
> patch series. Would you be willing be pull this into the security
> tree? Serge Hallyn has already ACKed it.
Sure!
>
> Thanks,
> --mahesh..
>
> On Tue, Dec 5, 2017 at 2:30 PM, Mahesh Bandewar <mahesh@bandewar.net> wrote:
> > From: Mahesh Bandewar <maheshb@google.com>
> >
> > TL;DR version
> > -------------
> > Creating a sandbox environment with namespaces is challenging
> > considering what these sandboxed processes can engage into. e.g.
> > CVE-2017-6074, CVE-2017-7184, CVE-2017-7308 etc. just to name few.
> > Current form of user-namespaces, however, if changed a bit can allow
> > us to create a sandbox environment without locking down user-
> > namespaces.
> >
> > Detailed version
> > ----------------
> >
> > Problem
> > -------
> > User-namespaces in the current form have increased the attack surface as
> > any process can acquire capabilities which are not available to them (by
> > default) by performing combination of clone()/unshare()/setns() syscalls.
> >
> > #define _GNU_SOURCE
> > #include <stdio.h>
> > #include <sched.h>
> > #include <netinet/in.h>
> >
> > int main(int ac, char **av)
> > {
> > int sock = -1;
> >
> > printf("Attempting to open RAW socket before unshare()...\n");
> > sock = socket(AF_INET6, SOCK_RAW, IPPROTO_RAW);
> > if (sock < 0) {
> > perror("socket() SOCK_RAW failed: ");
> > } else {
> > printf("Successfully opened RAW-Sock before unshare().\n");
> > close(sock);
> > sock = -1;
> > }
> >
> > if (unshare(CLONE_NEWUSER | CLONE_NEWNET) < 0) {
> > perror("unshare() failed: ");
> > return 1;
> > }
> >
> > printf("Attempting to open RAW socket after unshare()...\n");
> > sock = socket(AF_INET6, SOCK_RAW, IPPROTO_RAW);
> > if (sock < 0) {
> > perror("socket() SOCK_RAW failed: ");
> > } else {
> > printf("Successfully opened RAW-Sock after unshare().\n");
> > close(sock);
> > sock = -1;
> > }
> >
> > return 0;
> > }
> >
> > The above example shows how easy it is to acquire NET_RAW capabilities
> > and once acquired, these processes could take benefit of above mentioned
> > or similar issues discovered/undiscovered with malicious intent. Note
> > that this is just an example and the problem/solution is not limited
> > to NET_RAW capability *only*.
> >
> > The easiest fix one can apply here is to lock-down user-namespaces which
> > many of the distros do (i.e. don't allow users to create user namespaces),
> > but unfortunately that prevents everyone from using them.
> >
> > Approach
> > --------
> > Introduce a notion of 'controlled' user-namespaces. Every process on
> > the host is allowed to create user-namespaces (governed by the limit
> > imposed by per-ns sysctl) however, mark user-namespaces created by
> > sandboxed processes as 'controlled'. Use this 'mark' at the time of
> > capability check in conjunction with a global capability whitelist.
> > If the capability is not whitelisted, processes that belong to
> > controlled user-namespaces will not be allowed.
> >
> > Once a user-ns is marked as 'controlled'; all its child user-
> > namespaces are marked as 'controlled' too.
> >
> > A global whitelist is list of capabilities governed by the
> > sysctl which is available to (privileged) user in init-ns to modify
> > while it's applicable to all controlled user-namespaces on the host.
> >
> > Marking user-namespaces controlled without modifying the whitelist is
> > equivalent of the current behavior. The default value of whitelist includes
> > all capabilities so that the compatibility is maintained. However it gives
> > admins fine-grained ability to control various capabilities system wide
> > without locking down user-namespaces.
> >
> > Please see individual patches in this series.
> >
> > Mahesh Bandewar (2):
> > capability: introduce sysctl for controlled user-ns capability whitelist
> > userns: control capabilities of some user namespaces
> >
> > Documentation/sysctl/kernel.txt | 21 +++++++++++++++++
> > include/linux/capability.h | 7 ++++++
> > include/linux/user_namespace.h | 25 ++++++++++++++++++++
> > kernel/capability.c | 52 +++++++++++++++++++++++++++++++++++++++++
> > kernel/sysctl.c | 5 ++++
> > kernel/user_namespace.c | 4 ++++
> > security/commoncap.c | 8 +++++++
> > 7 files changed, 122 insertions(+)
> >
> > --
> > 2.15.0.531.g2ccb3012c9-goog
> >
>
--
James Morris
<james.l.morris@oracle.com>
^ 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