* Re: [PATCH 0/2] cxgb4 FR_NSMR_TPTE_WR support
From: Doug Ledford @ 2016-10-03 14:50 UTC (permalink / raw)
To: Steve Wise; +Cc: netdev, linux-rdma, 'David Miller'
In-Reply-To: <023401d2190b$03b00e50$0b102af0$@opengridcomputing.com>
[-- Attachment #1.1: Type: text/plain, Size: 710 bytes --]
On 9/27/2016 6:03 PM, Steve Wise wrote:
>>
>>>
>>>>
>>>> From: Steve Wise <swise@opengridcomputing.com>
>>>> Date: Fri, 16 Sep 2016 07:54:55 -0700
>>>>
>>>>> This series enables a new work request to optimize small REG_MR
>>>>> operations. This is intended for 4.9. If everyone agrees, I suggest
>>>>> Doug take both the cxgb4 and iw_cxgb4 patches through his tree.
>>>>
>>>> I'm assuming this mean that I do _not_ apply these to my tree.
>>>
>>> Yes, if you're ok with that.
>>
>> I am.
>
> Doug, please include this for 4.9 if it looks good to you. Let me know.
>
> Thanks,
>
> Steve.
>
Applied, thanks.
--
Doug Ledford <dledford@redhat.com>
GPG Key ID: 0E572FDD
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]
^ permalink raw reply
* Re: [PATCH 3/3] net: smsc911x: add u16 workaround for pxa platforms
From: Jeremy Linton @ 2016-10-03 15:21 UTC (permalink / raw)
To: Robert Jarzmik, Rob Herring, Mark Rutland, Nicolas Pitre,
Russell King - ARM Linux, Arnd Bergmann
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1475485553-18747-3-git-send-email-robert.jarzmik-GANU6spQydw@public.gmane.org>
Hi Robert,
On 10/03/2016 04:05 AM, Robert Jarzmik wrote:
> Add a workaround for mainstone, idp and stargate2 boards, for u16 writes
> which must be aligned on 32 bits addresses.
>
> Signed-off-by: Robert Jarzmik <robert.jarzmik-GANU6spQydw@public.gmane.org>
> ---
> Documentation/devicetree/bindings/net/smsc911x.txt | 2 ++
> 1 file changed, 2 insertions(+)
I think this might be the wrong doc file. I think you want the
smsc-lan91c111.txt file.
Thanks,
>
> diff --git a/Documentation/devicetree/bindings/net/smsc911x.txt b/Documentation/devicetree/bindings/net/smsc911x.txt
> index 3fed3c124411..224965b7453c 100644
> --- a/Documentation/devicetree/bindings/net/smsc911x.txt
> +++ b/Documentation/devicetree/bindings/net/smsc911x.txt
> @@ -13,6 +13,8 @@ Optional properties:
> - reg-io-width : Specify the size (in bytes) of the IO accesses that
> should be performed on the device. Valid value for SMSC LAN is
> 2 or 4. If it's omitted or invalid, the size would be 2.
> +- reg-u16-align4 : Boolean, put in place the workaround the force all
> + u16 writes to be 32 bits aligned
> - smsc,irq-active-high : Indicates the IRQ polarity is active-high
> - smsc,irq-push-pull : Indicates the IRQ type is push-pull
> - smsc,force-internal-phy : Forces SMSC LAN controller to use
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 3/3] net: smsc911x: add u16 workaround for pxa platforms
From: Mark Rutland @ 2016-10-03 15:46 UTC (permalink / raw)
To: Robert Jarzmik
Cc: Rob Herring, Nicolas Pitre, Russell King - ARM Linux,
Arnd Bergmann, netdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1475485553-18747-3-git-send-email-robert.jarzmik-GANU6spQydw@public.gmane.org>
On Mon, Oct 03, 2016 at 11:05:53AM +0200, Robert Jarzmik wrote:
> Add a workaround for mainstone, idp and stargate2 boards, for u16 writes
> which must be aligned on 32 bits addresses.
>
> Signed-off-by: Robert Jarzmik <robert.jarzmik-GANU6spQydw@public.gmane.org>
> ---
> Documentation/devicetree/bindings/net/smsc911x.txt | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/net/smsc911x.txt b/Documentation/devicetree/bindings/net/smsc911x.txt
> index 3fed3c124411..224965b7453c 100644
> --- a/Documentation/devicetree/bindings/net/smsc911x.txt
> +++ b/Documentation/devicetree/bindings/net/smsc911x.txt
> @@ -13,6 +13,8 @@ Optional properties:
> - reg-io-width : Specify the size (in bytes) of the IO accesses that
> should be performed on the device. Valid value for SMSC LAN is
> 2 or 4. If it's omitted or invalid, the size would be 2.
> +- reg-u16-align4 : Boolean, put in place the workaround the force all
> + u16 writes to be 32 bits aligned
This property name and description is confusing.
How exactly does this differ from having reg-io-width = <4>, which is
documented immediately above?
Thanks,
Mark.
> - smsc,irq-active-high : Indicates the IRQ polarity is active-high
> - smsc,irq-push-pull : Indicates the IRQ type is push-pull
> - smsc,force-internal-phy : Forces SMSC LAN controller to use
> --
> 2.1.4
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 3/3] net: smsc911x: add u16 workaround for pxa platforms
From: Russell King - ARM Linux @ 2016-10-03 16:09 UTC (permalink / raw)
To: Mark Rutland
Cc: Robert Jarzmik, Rob Herring, Nicolas Pitre, Arnd Bergmann, netdev,
devicetree, linux-kernel
In-Reply-To: <20161003154624.GG7632@leverpostej>
On Mon, Oct 03, 2016 at 04:46:25PM +0100, Mark Rutland wrote:
> On Mon, Oct 03, 2016 at 11:05:53AM +0200, Robert Jarzmik wrote:
> > Add a workaround for mainstone, idp and stargate2 boards, for u16 writes
> > which must be aligned on 32 bits addresses.
> >
> > Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
> > ---
> > Documentation/devicetree/bindings/net/smsc911x.txt | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/net/smsc911x.txt b/Documentation/devicetree/bindings/net/smsc911x.txt
> > index 3fed3c124411..224965b7453c 100644
> > --- a/Documentation/devicetree/bindings/net/smsc911x.txt
> > +++ b/Documentation/devicetree/bindings/net/smsc911x.txt
> > @@ -13,6 +13,8 @@ Optional properties:
> > - reg-io-width : Specify the size (in bytes) of the IO accesses that
> > should be performed on the device. Valid value for SMSC LAN is
> > 2 or 4. If it's omitted or invalid, the size would be 2.
> > +- reg-u16-align4 : Boolean, put in place the workaround the force all
> > + u16 writes to be 32 bits aligned
>
> This property name and description is confusing.
>
> How exactly does this differ from having reg-io-width = <4>, which is
> documented immediately above?
Please note that the binding doc for smsc,lan91c111.txt is slightly wrong
on two counts:
1) compatible property:
compatible = "smsc,lan91c111";
vs the code:
static const struct of_device_id smc91x_match[] = {
{ .compatible = "smsc,lan91c94", },
{ .compatible = "smsc,lan91c111", },
{},
};
MODULE_DEVICE_TABLE(of, smc91x_match);
So the binding document needs to mention that smsc,lan91c94 is a valid
compatible for this device.
2) reg-io-width property:
- reg-io-width : Mask of sizes (in bytes) of the IO accesses that
are supported on the device. Valid value for SMSC LAN91c111 are
1, 2 or 4. If it's omitted or invalid, the size would be 2 meaning
16-bit access only.
The SMC requires at least one of byte or 16-bit access sizes, with
32-bit access sizes being optional on top. So, the legal values here
are: 1, 2, 3, 5, 6, and 7. 4 is illegal, and has never been supported
by the driver.
Note that the driver will always use byte accesses if '1' is specified
and emulate 16-bit accesses. If '2' is specified, the driver will
always use 16-bit accesses, and emulate byte accesses for the 8-bit
registers using a read-modify-write scheme. If '3' is specified, the
driver will use both 16-bit and byte accesses as appropriate for the
register being accessed with no emulation. Byte or 16-bit access are
required for non-data register access.
Including 32-bit accesses on top of this allows the packet transfer
(iow, data register accesses) to use 32-bit access instructions, which
is a performance boost.
Moreover, look at the property name vs the binding description. It's
property name says it's a width, but the description says it's a mask
of sizes - these really aren't the same thing. Once you start
specifying these other legal masks, it makes a nonsense of the "width"
part of the name. It's too late to try and fix this now though.
The binding document really needs to get fixed - I'll try to cook up a
patch during this week to correct these points, but it probably needs
coordination if others are going to be changing this as well.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* Re: [PATCH 3/3] net: smsc911x: add u16 workaround for pxa platforms
From: Robert Jarzmik @ 2016-10-03 16:11 UTC (permalink / raw)
To: Mark Rutland
Cc: Rob Herring, Nicolas Pitre, Russell King - ARM Linux,
Arnd Bergmann, netdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20161003154624.GG7632@leverpostej>
Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org> writes:
> On Mon, Oct 03, 2016 at 11:05:53AM +0200, Robert Jarzmik wrote:
>> Add a workaround for mainstone, idp and stargate2 boards, for u16 writes
>> which must be aligned on 32 bits addresses.
>>
>> Signed-off-by: Robert Jarzmik <robert.jarzmik-GANU6spQydw@public.gmane.org>
>> ---
>> Documentation/devicetree/bindings/net/smsc911x.txt | 2 ++
>> 1 file changed, 2 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/net/smsc911x.txt b/Documentation/devicetree/bindings/net/smsc911x.txt
>> index 3fed3c124411..224965b7453c 100644
>> --- a/Documentation/devicetree/bindings/net/smsc911x.txt
>> +++ b/Documentation/devicetree/bindings/net/smsc911x.txt
>> @@ -13,6 +13,8 @@ Optional properties:
>> - reg-io-width : Specify the size (in bytes) of the IO accesses that
>> should be performed on the device. Valid value for SMSC LAN is
>> 2 or 4. If it's omitted or invalid, the size would be 2.
>> +- reg-u16-align4 : Boolean, put in place the workaround the force all
>> + u16 writes to be 32 bits aligned
>
> This property name and description is confusing.
>
> How exactly does this differ from having reg-io-width = <4>, which is
> documented immediately above?
reg-io-width specifies the IO size, ie. how many data lines are physically
connected from the system bus to the lan adapter.
reg-u16-align4 tells that a specific hardware doesn't support 16 bit writes not
being 32 bits aligned, or said differently that a "store" 16 bits wide on an
address of the format 4*n + 2 deserves a special handling in the driver, while a
store 16 bits wide on an address of the format 4*n can follow the simple casual
case.
I'm pretty open to any name you might suggest, these 3 hardwares I know of are
really crazy, you can see them in patch 1/3, in the _SMC_outw_align4() function
...
Cheers.
--
Robert
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 3/3] net: smsc911x: add u16 workaround for pxa platforms
From: Robert Jarzmik @ 2016-10-03 16:14 UTC (permalink / raw)
To: Jeremy Linton
Cc: Rob Herring, Mark Rutland, Nicolas Pitre,
Russell King - ARM Linux, Arnd Bergmann,
netdev-u79uwXL29TY76Z2rM5mHXA, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <5b835e36-d53b-7510-25fb-649abc7df775-5wv7dgnIgG8@public.gmane.org>
Jeremy Linton <jeremy.linton-5wv7dgnIgG8@public.gmane.org> writes:
> Hi Robert,
>
> On 10/03/2016 04:05 AM, Robert Jarzmik wrote:
>> Add a workaround for mainstone, idp and stargate2 boards, for u16 writes
>> which must be aligned on 32 bits addresses.
>>
>> Signed-off-by: Robert Jarzmik <robert.jarzmik-GANU6spQydw@public.gmane.org>
>> ---
>> Documentation/devicetree/bindings/net/smsc911x.txt | 2 ++
>> 1 file changed, 2 insertions(+)
>
> I think this might be the wrong doc file. I think you want the
> smsc-lan91c111.txt file.
Ah yes, thanks for spoting that.
Cheers.
--
Robert
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] phy: micrel.c: Support ksz9031 energy-detect power-down mode
From: Mike Looijmans @ 2016-10-03 16:30 UTC (permalink / raw)
To: Andrew Lunn; +Cc: netdev, devicetree, linux-kernel, f.fainelli
In-Reply-To: <20161003143508.GA26382@lunn.ch>
On 03-10-16 16:35, Andrew Lunn wrote:
>> + Boolean:
>> +
>> + - enable-edpd : Not related to timing. Specify this property to enable
>> + energy-detect power-down mode in the PHY.
>
> The Broadcom PHYs unconditionally enable this feature.
>
> The SMSC driver has an option: smsc,disable-energy-detect because it
> seems to have a rare hardware bug when it is enabled.
>
> And you would like to make it off by default.
>
> Could we avoid having three drivers doing three different things?
> Could you have it unconditionally on, and see if anybody reports it
> being broken?
Good suggestion I think. It's a feature found on many PHYs, apparently
without any ill effects, so just enabling unconditionally simplifies
things. And it's good for the environment...
I'll post a v2 patch (which won't need devicetree changes then).
--
Mike Looijmans
^ permalink raw reply
* [PATCH net-next] openvswitch: correctly fragment packet with mpls headers
From: Jiri Benc @ 2016-10-03 16:33 UTC (permalink / raw)
To: netdev; +Cc: David Ahern, pravin shelar
If mpls headers were pushed to a defragmented packet, the refragmentation no
longer works correctly after 48d2ab609b6b ("net: mpls: Fixups for GSO"). The
network header has to be shifted after the mpls headers for the
fragmentation and restored afterwards.
Fixes: 48d2ab609b6b ("net: mpls: Fixups for GSO")
Signed-off-by: Jiri Benc <jbenc@redhat.com>
---
net/openvswitch/actions.c | 26 +++++++++++++++++++++-----
1 file changed, 21 insertions(+), 5 deletions(-)
diff --git a/net/openvswitch/actions.c b/net/openvswitch/actions.c
index 4e03f64709bc..370b2ba3df4c 100644
--- a/net/openvswitch/actions.c
+++ b/net/openvswitch/actions.c
@@ -62,7 +62,8 @@ struct ovs_frag_data {
struct vport *vport;
struct ovs_skb_cb cb;
__be16 inner_protocol;
- __u16 vlan_tci;
+ u16 network_offset; /* valid only if inner_protocol is set */
+ u16 vlan_tci;
__be16 vlan_proto;
unsigned int l2_len;
u8 l2_data[MAX_L2_LEN];
@@ -656,7 +657,6 @@ static int ovs_vport_output(struct net *net, struct sock *sk, struct sk_buff *sk
__skb_dst_copy(skb, data->dst);
*OVS_CB(skb) = data->cb;
- skb->inner_protocol = data->inner_protocol;
skb->vlan_tci = data->vlan_tci;
skb->vlan_proto = data->vlan_proto;
@@ -666,6 +666,13 @@ static int ovs_vport_output(struct net *net, struct sock *sk, struct sk_buff *sk
skb_postpush_rcsum(skb, skb->data, data->l2_len);
skb_reset_mac_header(skb);
+ if (data->inner_protocol) {
+ skb->inner_protocol = data->inner_protocol;
+ skb->inner_network_header = skb->network_header;
+ skb_set_network_header(skb, data->network_offset);
+ }
+ skb_reset_mac_len(skb);
+
ovs_vport_send(vport, skb);
return 0;
}
@@ -684,7 +691,8 @@ static struct dst_ops ovs_dst_ops = {
/* prepare_frag() is called once per (larger-than-MTU) frame; its inverse is
* ovs_vport_output(), which is called once per fragmented packet.
*/
-static void prepare_frag(struct vport *vport, struct sk_buff *skb)
+static void prepare_frag(struct vport *vport, struct sk_buff *skb,
+ u16 orig_network_offset)
{
unsigned int hlen = skb_network_offset(skb);
struct ovs_frag_data *data;
@@ -694,6 +702,7 @@ static void prepare_frag(struct vport *vport, struct sk_buff *skb)
data->vport = vport;
data->cb = *OVS_CB(skb);
data->inner_protocol = skb->inner_protocol;
+ data->network_offset = orig_network_offset;
data->vlan_tci = skb->vlan_tci;
data->vlan_proto = skb->vlan_proto;
data->l2_len = hlen;
@@ -706,6 +715,13 @@ static void prepare_frag(struct vport *vport, struct sk_buff *skb)
static void ovs_fragment(struct net *net, struct vport *vport,
struct sk_buff *skb, u16 mru, __be16 ethertype)
{
+ u16 orig_network_offset = 0;
+
+ if (skb->inner_protocol) {
+ orig_network_offset = skb_network_offset(skb);
+ skb->network_header = skb->inner_network_header;
+ }
+
if (skb_network_offset(skb) > MAX_L2_LEN) {
OVS_NLERR(1, "L2 header too long to fragment");
goto err;
@@ -715,7 +731,7 @@ static void ovs_fragment(struct net *net, struct vport *vport,
struct dst_entry ovs_dst;
unsigned long orig_dst;
- prepare_frag(vport, skb);
+ prepare_frag(vport, skb, orig_network_offset);
dst_init(&ovs_dst, &ovs_dst_ops, NULL, 1,
DST_OBSOLETE_NONE, DST_NOCOUNT);
ovs_dst.dev = vport->dev;
@@ -735,7 +751,7 @@ static void ovs_fragment(struct net *net, struct vport *vport,
goto err;
}
- prepare_frag(vport, skb);
+ prepare_frag(vport, skb, orig_network_offset);
memset(&ovs_rt, 0, sizeof(ovs_rt));
dst_init(&ovs_rt.dst, &ovs_dst_ops, NULL, 1,
DST_OBSOLETE_NONE, DST_NOCOUNT);
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH 3/3] net: smsc911x: add u16 workaround for pxa platforms
From: Mark Rutland @ 2016-10-03 16:42 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Robert Jarzmik, Rob Herring, Nicolas Pitre, Arnd Bergmann,
netdev-u79uwXL29TY76Z2rM5mHXA, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20161003160913.GQ1041-l+eeeJia6m9URfEZ8mYm6t73F7V6hmMc@public.gmane.org>
On Mon, Oct 03, 2016 at 05:09:13PM +0100, Russell King - ARM Linux wrote:
> Please note that the binding doc for smsc,lan91c111.txt is slightly wrong
> on two counts:
>
> 1) compatible property:
>
> compatible = "smsc,lan91c111";
>
> vs the code:
>
> static const struct of_device_id smc91x_match[] = {
> { .compatible = "smsc,lan91c94", },
> { .compatible = "smsc,lan91c111", },
> {},
> };
> MODULE_DEVICE_TABLE(of, smc91x_match);
>
> So the binding document needs to mention that smsc,lan91c94 is a valid
> compatible for this device.
Yes, it should.
> 2) reg-io-width property:
>
> - reg-io-width : Mask of sizes (in bytes) of the IO accesses that
> are supported on the device. Valid value for SMSC LAN91c111 are
> 1, 2 or 4. If it's omitted or invalid, the size would be 2 meaning
> 16-bit access only.
> Moreover, look at the property name vs the binding description. It's
> property name says it's a width, but the description says it's a mask
> of sizes - these really aren't the same thing. Once you start
> specifying these other legal masks, it makes a nonsense of the "width"
> part of the name. It's too late to try and fix this now though.
Indeed, as-is this is nonsense. :(
The best we can do here is to add a big fat notice regarding the
misnaming; adding a new property is only giong to cause more confusion.
> The binding document really needs to get fixed - I'll try to cook up a
> patch during this week to correct these points, but it probably needs
> coordination if others are going to be changing this as well.
Thanks for handling both of these.
Given the historical rate of change of the binding document, I suspect
the stuff for pxa platforms is going to be the only potential conflict.
Either all of that can go via the DT tree (independent of any new code),
or we can ack the whole lot and it can all go via the net tree in one
go.
Thanks,
Mark.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* RE: [PATCH 3/3] net: fec: align IP header in hardware
From: David Laight @ 2016-10-03 16:42 UTC (permalink / raw)
To: 'Russell King - ARM Linux', Eric Nelson
Cc: netdev@vger.kernel.org, andrew@lunn.ch, fugang.duan@nxp.com,
otavio@ossystems.com.br, edumazet@google.com,
troy.kisky@boundarydevices.com, davem@davemloft.net,
u.kleine-koenig@pengutronix.de
In-Reply-To: <20161001195215.GP1041@n2100.armlinux.org.uk>
From: Russell King - ARM Linux
> Sent: 01 October 2016 20:52
> On Fri, Sep 30, 2016 at 07:16:12AM -0700, Eric Nelson wrote:
> > On ARM, the CPU can't handle misaligned memory cycles without
> > taking an alignment fault and NET_IP_ALIGN is set to 2.
>
> Let's get this right... With Linux on MMU parts:
>
> On ARMv6+, unaligned memory cycles using the LDR, LDRH and corresponding
> store instructions are handled in hardware without any exception being
> raised.
>
> On pre-ARMv6, such instructions raise an alignment exception, and we fix
> up the load/store manually.
I'm not sure that is a good idea but...
> Where things behave the same is with the LDM (load multiple) and STM
> (store multiple) instructions. Hardware does not fix these up if they
> are unaligned: it is expected that the base address will always be
> aligned to a 32-bit word.
>
> For some reason, the compiler guys have decided it's okay to use these
> instructions as an optimisation, and I see no way to disable this
> behaviour.
...
> The issue with the networking layer is that it passes around structure
> pointers which may not be "naturally aligned" - technically it goes
> against the C standard specs. However, you'll find it hard to argue
> against this, so we have to accept that the networking people expect
> it to work.
I think it 'only' casts misaligned pointers to structure on systems
where unaligned accesses are allowed.
It is almost impossible to do a 'realignment copy' on (for example) sparc.
> The optimisation that the C compiler uses (using LDM to access multiple
> 32-bit consecutive words) is legal and efficient when the structure
> pointers are aligned as it expects, but that all breaks if the pointer
> is not so aligned. So, raising it as a bug against the C compiler isn't
> going to work either.
>
> What may work is to raise a feature request with compiler people to have
> a mechanism to disable the LDM/STM optimisation for code where we know
> that pointers may not be naturally aligned.
What happens is the relevant structures are marked 'packed'?
If the compiler still generates LDM/STM that is a bug.
Assuming the compiler is targeting v6+ it shouldn't generate byte accesses.
David
^ permalink raw reply
* Re: [PATCH 3/3] net: smsc911x: add u16 workaround for pxa platforms
From: Mark Rutland @ 2016-10-03 16:50 UTC (permalink / raw)
To: Robert Jarzmik
Cc: Rob Herring, Nicolas Pitre, Russell King - ARM Linux,
Arnd Bergmann, netdev, devicetree, linux-kernel
In-Reply-To: <87oa319zv8.fsf@belgarion.home>
On Mon, Oct 03, 2016 at 06:11:23PM +0200, Robert Jarzmik wrote:
> Mark Rutland <mark.rutland@arm.com> writes:
>
> > On Mon, Oct 03, 2016 at 11:05:53AM +0200, Robert Jarzmik wrote:
> >> Add a workaround for mainstone, idp and stargate2 boards, for u16 writes
> >> which must be aligned on 32 bits addresses.
> >>
> >> Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
> >> ---
> >> Documentation/devicetree/bindings/net/smsc911x.txt | 2 ++
> >> 1 file changed, 2 insertions(+)
> >>
> >> diff --git a/Documentation/devicetree/bindings/net/smsc911x.txt b/Documentation/devicetree/bindings/net/smsc911x.txt
> >> index 3fed3c124411..224965b7453c 100644
> >> --- a/Documentation/devicetree/bindings/net/smsc911x.txt
> >> +++ b/Documentation/devicetree/bindings/net/smsc911x.txt
> >> @@ -13,6 +13,8 @@ Optional properties:
> >> - reg-io-width : Specify the size (in bytes) of the IO accesses that
> >> should be performed on the device. Valid value for SMSC LAN is
> >> 2 or 4. If it's omitted or invalid, the size would be 2.
> >> +- reg-u16-align4 : Boolean, put in place the workaround the force all
> >> + u16 writes to be 32 bits aligned
> >
> > This property name and description is confusing.
> >
> > How exactly does this differ from having reg-io-width = <4>, which is
> > documented immediately above?
>
> reg-io-width specifies the IO size, ie. how many data lines are physically
> connected from the system bus to the lan adapter.
>
> reg-u16-align4 tells that a specific hardware doesn't support 16 bit writes not
> being 32 bits aligned, or said differently that a "store" 16 bits wide on an
> address of the format 4*n + 2 deserves a special handling in the driver, while a
> store 16 bits wide on an address of the format 4*n can follow the simple casual
> case.
If I've understood correctly, effectively the low 2 address lines to the
device are hard-wired to zero, e.g. a 16-bit access to 4*n + 2 would go
to 4*n + 0 on the device? Or is the failure case distinct from that?
Do we have other platforms where similar is true? e.g. u8 accesses
requiring 16-bit alignment?
Thanks,
Mark.
^ permalink raw reply
* Re: [PATCH v2 net-next 1/2] net: centralize net_device min/max MTU checking
From: Jarod Wilson @ 2016-10-03 17:46 UTC (permalink / raw)
To: David Miller; +Cc: jkbs, linux-kernel, netdev
In-Reply-To: <20161002.224322.740109807229746275.davem@davemloft.net>
On Sun, Oct 02, 2016 at 10:43:22PM -0400, David Miller wrote:
> From: Jakub Sitnicki <jkbs@redhat.com>
> Date: Fri, 30 Sep 2016 11:37:24 +0200
>
> > On Wed, Sep 28, 2016 at 10:20 PM GMT, Jarod Wilson wrote:
> >> While looking into an MTU issue with sfc, I started noticing that almost
> >> every NIC driver with an ndo_change_mtu function implemented almost
> >> exactly the same range checks, and in many cases, that was the only
> >> practical thing their ndo_change_mtu function was doing. Quite a few
> >> drivers have either 68, 64, 60 or 46 as their minimum MTU value checked,
> >> and then various sizes from 1500 to 65535 for their maximum MTU value. We
> >> can remove a whole lot of redundant code here if we simple store min_mtu
> >> and max_mtu in net_device, and check against those in net/core/dev.c's
> >> dev_set_mtu().
> >>
> >> In theory, there should be zero functional change with this patch, it just
> >> puts the infrastructure in place. Subsequent patches will attempt to start
> >> using said infrastructure, with theoretically zero change in
> >> functionality.
> >>
> >> CC: "David S. Miller" <davem@davemloft.net>
> >> CC: netdev@vger.kernel.org
> >> Signed-off-by: Jarod Wilson <jarod@redhat.com>
> >> ---
> >
> > [...]
> >
> >> diff --git a/net/core/dev.c b/net/core/dev.c
> >> index c0c291f..5343799 100644
> >> --- a/net/core/dev.c
> >> +++ b/net/core/dev.c
> >> @@ -6493,9 +6493,17 @@ int dev_set_mtu(struct net_device *dev, int new_mtu)
> >> if (new_mtu == dev->mtu)
> >> return 0;
> >>
> >> - /* MTU must be positive. */
> >> - if (new_mtu < 0)
> >> + if (new_mtu < dev->min_mtu) {
> >
> > Ouch, integral promotions. Looks like you need to keep the < 0 check.
> > Otherwise new_mtu gets promoted to unsigned int and negative values will
> > pass the check.
>
> Agreed, the < 0 test must be reintroduced.
Gah, yeah, okay, will add it back in. Thinking like this:
if (new_mtu < 0 || new_mtu < dev->min_mtu) {
Alternatively, could have the negative value check on it's own, with a
harsher warning about negative values.
--
Jarod Wilson
jarod@redhat.com
^ permalink raw reply
* Re: [PATCH 2/7] ethtool: avoid resource leak of strings in do_gprivflags
From: Jarod Wilson @ 2016-10-03 17:54 UTC (permalink / raw)
To: John W. Linville; +Cc: netdev
In-Reply-To: <1475265381-28937-3-git-send-email-linville@tuxdriver.com>
On Fri, Sep 30, 2016 at 03:56:16PM -0400, John W. Linville wrote:
> Coverity issue: 1363119
> Fixes: e1ee596326ae ("Add support for querying and setting private flags")
>
> Signed-off-by: John W. Linville <linville@tuxdriver.com>
> ---
> ethtool.c | 18 +++++++++++++-----
> 1 file changed, 13 insertions(+), 5 deletions(-)
>
> diff --git a/ethtool.c b/ethtool.c
> index aa3ef5ed2f75..0885a61097ad 100644
> --- a/ethtool.c
> +++ b/ethtool.c
> @@ -4205,7 +4205,7 @@ static int do_gprivflags(struct cmd_context *ctx)
> struct ethtool_gstrings *strings;
> struct ethtool_value flags;
> unsigned int i;
> - int max_len = 0, cur_len;
> + int max_len = 0, cur_len, rc;
>
> if (ctx->argc != 0)
> exit_bad_args();
> @@ -4215,11 +4215,13 @@ static int do_gprivflags(struct cmd_context *ctx)
> 1);
> if (!strings) {
> perror("Cannot get private flag names");
> - return 1;
> + rc = 1;
> + goto err;
This goto looks redundant, since all you're doing at err is re-checking if
strings is non-null to free it.
> if (strings->len == 0) {
> fprintf(stderr, "No private flags defined\n");
> - return 1;
> + rc = 1;
> + goto err;
> }
> if (strings->len > 32) {
> /* ETHTOOL_GPFLAGS can only cover 32 flags */
> @@ -4230,7 +4232,8 @@ static int do_gprivflags(struct cmd_context *ctx)
> flags.cmd = ETHTOOL_GPFLAGS;
> if (send_ioctl(ctx, &flags)) {
> perror("Cannot get private flags");
> - return 1;
> + rc = 1;
> + goto err;
> }
>
> /* Find longest string and align all strings accordingly */
> @@ -4248,7 +4251,12 @@ static int do_gprivflags(struct cmd_context *ctx)
> (const char *)strings->data + i * ETH_GSTRING_LEN,
> (flags.data & (1U << i)) ? "on" : "off");
>
> - return 0;
> + rc = 0;
> +
> +err:
> + if (strings)
> + free(strings);
> + return rc;
> }
>
> static int do_sprivflags(struct cmd_context *ctx)
> --
> 2.7.4
>
--
Jarod Wilson
jarod@redhat.com
^ permalink raw reply
* Re: [PATCH net-next] openvswitch: correctly fragment packet with mpls headers
From: Pravin Shelar @ 2016-10-03 18:04 UTC (permalink / raw)
To: Jiri Benc; +Cc: Linux Kernel Network Developers, David Ahern
In-Reply-To: <b0cb6efc9bfda8381af880f10fa6b3447f7d3d5d.1475512190.git.jbenc@redhat.com>
On Mon, Oct 3, 2016 at 9:33 AM, Jiri Benc <jbenc@redhat.com> wrote:
> If mpls headers were pushed to a defragmented packet, the refragmentation no
> longer works correctly after 48d2ab609b6b ("net: mpls: Fixups for GSO"). The
> network header has to be shifted after the mpls headers for the
> fragmentation and restored afterwards.
>
> Fixes: 48d2ab609b6b ("net: mpls: Fixups for GSO")
> Signed-off-by: Jiri Benc <jbenc@redhat.com>
> ---
> net/openvswitch/actions.c | 26 +++++++++++++++++++++-----
> 1 file changed, 21 insertions(+), 5 deletions(-)
>
> diff --git a/net/openvswitch/actions.c b/net/openvswitch/actions.c
> index 4e03f64709bc..370b2ba3df4c 100644
> --- a/net/openvswitch/actions.c
> +++ b/net/openvswitch/actions.c
> @@ -62,7 +62,8 @@ struct ovs_frag_data {
> struct vport *vport;
> struct ovs_skb_cb cb;
> __be16 inner_protocol;
> - __u16 vlan_tci;
> + u16 network_offset; /* valid only if inner_protocol is set */
> + u16 vlan_tci;
> __be16 vlan_proto;
> unsigned int l2_len;
> u8 l2_data[MAX_L2_LEN];
> @@ -656,7 +657,6 @@ static int ovs_vport_output(struct net *net, struct sock *sk, struct sk_buff *sk
>
> __skb_dst_copy(skb, data->dst);
> *OVS_CB(skb) = data->cb;
> - skb->inner_protocol = data->inner_protocol;
> skb->vlan_tci = data->vlan_tci;
> skb->vlan_proto = data->vlan_proto;
>
> @@ -666,6 +666,13 @@ static int ovs_vport_output(struct net *net, struct sock *sk, struct sk_buff *sk
> skb_postpush_rcsum(skb, skb->data, data->l2_len);
> skb_reset_mac_header(skb);
>
> + if (data->inner_protocol) {
> + skb->inner_protocol = data->inner_protocol;
> + skb->inner_network_header = skb->network_header;
> + skb_set_network_header(skb, data->network_offset);
> + }
> + skb_reset_mac_len(skb);
> +
> ovs_vport_send(vport, skb);
> return 0;
> }
> @@ -684,7 +691,8 @@ static struct dst_ops ovs_dst_ops = {
> /* prepare_frag() is called once per (larger-than-MTU) frame; its inverse is
> * ovs_vport_output(), which is called once per fragmented packet.
> */
> -static void prepare_frag(struct vport *vport, struct sk_buff *skb)
> +static void prepare_frag(struct vport *vport, struct sk_buff *skb,
> + u16 orig_network_offset)
> {
> unsigned int hlen = skb_network_offset(skb);
> struct ovs_frag_data *data;
> @@ -694,6 +702,7 @@ static void prepare_frag(struct vport *vport, struct sk_buff *skb)
> data->vport = vport;
> data->cb = *OVS_CB(skb);
> data->inner_protocol = skb->inner_protocol;
> + data->network_offset = orig_network_offset;
> data->vlan_tci = skb->vlan_tci;
> data->vlan_proto = skb->vlan_proto;
> data->l2_len = hlen;
> @@ -706,6 +715,13 @@ static void prepare_frag(struct vport *vport, struct sk_buff *skb)
> static void ovs_fragment(struct net *net, struct vport *vport,
> struct sk_buff *skb, u16 mru, __be16 ethertype)
> {
> + u16 orig_network_offset = 0;
> +
> + if (skb->inner_protocol) {
> + orig_network_offset = skb_network_offset(skb);
> + skb->network_header = skb->inner_network_header;
> + }
> +
This is not correct way to detect MPLS packet. inner_protocol can be
set by any tunnel device for using tunnel offloads. So this would
break the fragmentation for encapsulated packets. How about using
eth_p_mpls() as done in do-output()?
^ permalink raw reply
* Re: [PATCH net] Panic when tc_lookup_action_n finds a partially initialized action.
From: Cong Wang @ 2016-10-03 18:22 UTC (permalink / raw)
To: Krister Johansen; +Cc: Jamal Hadi Salim, Linux Kernel Network Developers
In-Reply-To: <20161002031349.GB2635@templeofstupid.com>
[-- Attachment #1: Type: text/plain, Size: 790 bytes --]
On Sat, Oct 1, 2016 at 8:13 PM, Krister Johansen
<kjlx@templeofstupid.com> wrote:
> A tc_action_ops structure is visibile as soon as it is placed in the
> act_base list. When tcf_regsiter_action adds an item to this list and
> drops act_mod_lock, registration is not complete until
> register_pernet_subsys() finishes.
Hmm, good catch, but does the fix have to be so complicated?
How about moving register_pernet_subsys() under act_mod_lock?
Similar is needed for unregister too of course. This also means
we need to convert act_mod_lock to a mutex which allows blocking.
Fortunately, we don't have to take act_mod_lock in any atomic context.
Please try the attached patch. I also convert the read path to RCU
to avoid a possible deadlock. A quick test shows no lockdep splat.
Thanks!
[-- Attachment #2: act_api.diff --]
[-- Type: text/plain, Size: 3031 bytes --]
diff --git a/net/sched/act_api.c b/net/sched/act_api.c
index d09d068..4aac846 100644
--- a/net/sched/act_api.c
+++ b/net/sched/act_api.c
@@ -330,7 +330,22 @@ void tcf_hashinfo_destroy(const struct tc_action_ops *ops,
EXPORT_SYMBOL(tcf_hashinfo_destroy);
static LIST_HEAD(act_base);
-static DEFINE_RWLOCK(act_mod_lock);
+static DEFINE_MUTEX(act_mod_lock);
+
+static int __tcf_unregister_action(struct tc_action_ops *act)
+{
+ struct tc_action_ops *a;
+ int err = -ENOENT;
+
+ list_for_each_entry(a, &act_base, head) {
+ if (a == act) {
+ list_del_rcu(&act->head);
+ err = 0;
+ break;
+ }
+ }
+ return err;
+}
int tcf_register_action(struct tc_action_ops *act,
struct pernet_operations *ops)
@@ -341,22 +356,23 @@ int tcf_register_action(struct tc_action_ops *act,
if (!act->act || !act->dump || !act->init || !act->walk || !act->lookup)
return -EINVAL;
- write_lock(&act_mod_lock);
+ mutex_lock(&act_mod_lock);
list_for_each_entry(a, &act_base, head) {
if (act->type == a->type || (strcmp(act->kind, a->kind) == 0)) {
- write_unlock(&act_mod_lock);
+ mutex_unlock(&act_mod_lock);
return -EEXIST;
}
}
- list_add_tail(&act->head, &act_base);
- write_unlock(&act_mod_lock);
+ list_add_tail_rcu(&act->head, &act_base);
ret = register_pernet_subsys(ops);
if (ret) {
- tcf_unregister_action(act, ops);
+ __tcf_unregister_action(act);
+ mutex_unlock(&act_mod_lock);
return ret;
}
+ mutex_unlock(&act_mod_lock);
return 0;
}
EXPORT_SYMBOL(tcf_register_action);
@@ -364,20 +380,13 @@ EXPORT_SYMBOL(tcf_register_action);
int tcf_unregister_action(struct tc_action_ops *act,
struct pernet_operations *ops)
{
- struct tc_action_ops *a;
int err = -ENOENT;
+ mutex_lock(&act_mod_lock);
unregister_pernet_subsys(ops);
+ err = __tcf_unregister_action(act);
+ mutex_unlock(&act_mod_lock);
- write_lock(&act_mod_lock);
- list_for_each_entry(a, &act_base, head) {
- if (a == act) {
- list_del(&act->head);
- err = 0;
- break;
- }
- }
- write_unlock(&act_mod_lock);
return err;
}
EXPORT_SYMBOL(tcf_unregister_action);
@@ -388,15 +397,15 @@ static struct tc_action_ops *tc_lookup_action_n(char *kind)
struct tc_action_ops *a, *res = NULL;
if (kind) {
- read_lock(&act_mod_lock);
- list_for_each_entry(a, &act_base, head) {
+ rcu_read_lock();
+ list_for_each_entry_rcu(a, &act_base, head) {
if (strcmp(kind, a->kind) == 0) {
if (try_module_get(a->owner))
res = a;
break;
}
}
- read_unlock(&act_mod_lock);
+ rcu_read_unlock();
}
return res;
}
@@ -407,15 +416,15 @@ static struct tc_action_ops *tc_lookup_action(struct nlattr *kind)
struct tc_action_ops *a, *res = NULL;
if (kind) {
- read_lock(&act_mod_lock);
- list_for_each_entry(a, &act_base, head) {
+ rcu_read_lock();
+ list_for_each_entry_rcu(a, &act_base, head) {
if (nla_strcmp(kind, a->kind) == 0) {
if (try_module_get(a->owner))
res = a;
break;
}
}
- read_unlock(&act_mod_lock);
+ rcu_read_unlock();
}
return res;
}
^ permalink raw reply related
* Re: [PATCH 3/3] net: fec: align IP header in hardware
From: Eric Nelson @ 2016-10-03 18:48 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: David Laight, netdev@vger.kernel.org, andrew@lunn.ch,
fugang.duan@nxp.com, otavio@ossystems.com.br, edumazet@google.com,
troy.kisky@boundarydevices.com, davem@davemloft.net,
u.kleine-koenig@pengutronix.de
In-Reply-To: <20161001195215.GP1041@n2100.armlinux.org.uk>
Hi Russell,
On 10/01/2016 09:52 PM, Russell King - ARM Linux wrote:
> On Fri, Sep 30, 2016 at 07:16:12AM -0700, Eric Nelson wrote:
>> On ARM, the CPU can't handle misaligned memory cycles without
>> taking an alignment fault and NET_IP_ALIGN is set to 2.
>
> Let's get this right... With Linux on MMU parts:
>
> On ARMv6+, unaligned memory cycles using the LDR, LDRH and corresponding
> store instructions are handled in hardware without any exception being
> raised.
>
> On pre-ARMv6, such instructions raise an alignment exception, and we fix
> up the load/store manually.
>
> Where things behave the same is with the LDM (load multiple) and STM
> (store multiple) instructions. Hardware does not fix these up if they
> are unaligned: it is expected that the base address will always be
> aligned to a 32-bit word.
>
Thanks for the clarification. This helps me understand why I didn't
see the exceptions that Eric warned about:
https://www.spinics.net/lists/netdev/msg397012.html
> For some reason, the compiler guys have decided it's okay to use these
> instructions as an optimisation, and I see no way to disable this
> behaviour.
>
>> On ARM, we have CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS=y
>> but I find it hard to believe that taking alignment faults is more
>> efficient than adding two bytes to the start of the frame.
>
> ... see above, hence why CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS is set.
> It's only when the compiler decides to do silly things that things go
> wrong. However, net code does not care about that configuration
> setting, so it's irrelevant to this discussion.
>
The obfuscated optimization in ip_gro_receive doesn't help by
reading two 16-bit values as a __be32:
id = ntohl(*(__be32 *)&iph->id);
flush = (u16)((ntohl(*(__be32 *)iph) ^ skb_gro_len(skb)) | (id & ~IP_DF));
id >>= 16;
> The issue with the networking layer is that it passes around structure
> pointers which may not be "naturally aligned" - technically it goes
> against the C standard specs. However, you'll find it hard to argue
> against this, so we have to accept that the networking people expect
> it to work.
>
> The optimisation that the C compiler uses (using LDM to access multiple
> 32-bit consecutive words) is legal and efficient when the structure
> pointers are aligned as it expects, but that all breaks if the pointer
> is not so aligned. So, raising it as a bug against the C compiler isn't
> going to work either.
>
> What may work is to raise a feature request with compiler people to have
> a mechanism to disable the LDM/STM optimisation for code where we know
> that pointers may not be naturally aligned.
>
Agreed, but that's a long path even if the compiler folks agree
immediately.
It's probably to just fix the driver with known issues for now.
Did you have any comments on the patch? I tried to pull what I found
from your patch set, but only the enabling of the SHIFT16 bit.
Please advise,
Eric
^ permalink raw reply
* Re: [PATCH 3/3] net: smsc911x: add u16 workaround for pxa platforms
From: Robert Jarzmik @ 2016-10-03 19:12 UTC (permalink / raw)
To: Mark Rutland
Cc: Rob Herring, Nicolas Pitre, Russell King - ARM Linux,
Arnd Bergmann, netdev, devicetree, linux-kernel
In-Reply-To: <20161003165032.GB15313@leverpostej>
Mark Rutland <mark.rutland@arm.com> writes:
> On Mon, Oct 03, 2016 at 06:11:23PM +0200, Robert Jarzmik wrote:
>> Mark Rutland <mark.rutland@arm.com> writes:
>>
>> reg-u16-align4 tells that a specific hardware doesn't support 16 bit writes not
>> being 32 bits aligned, or said differently that a "store" 16 bits wide on an
>> address of the format 4*n + 2 deserves a special handling in the driver, while a
>> store 16 bits wide on an address of the format 4*n can follow the simple casual
>> case.
>
> If I've understood correctly, effectively the low 2 address lines to the
> device are hard-wired to zero, e.g. a 16-bit access to 4*n + 2 would go
> to 4*n + 0 on the device? Or is the failure case distinct from that?
It is distinct.
The "awful truth" is that an FPGA lies between the system bus and the
smc91c111. And this FPGA cannot handle correctly the 4*n + 2 u16 writes.
> Do we have other platforms where similar is true? e.g. u8 accesses
> requiring 16-bit alignment?
Not really, ie. not with a alignement requirement.
But there are of course these ones are handled by reg-io-width and the
SMC_USE_xxx_BITS flags as far as I understand it. These cases are when a
platform declares SMC91X_USE_16BIT or SMC91X_USE_32BIT, but not SMC91X_USE_8BIT,
which would make me think of :
- CONFIG_SH_SH4202_MICRODEV,
- CONFIG_M32R
- several omap1 boards
- 1 sa1100 board
- several MMP and realview boards
With all these platforms, each u8 access is replaced with a u16 access and a
mask / shift + mask.
Cheers.
--
Robert
^ permalink raw reply
* Re: [PATCH net-next 1/3] net: ethernet: mediatek: get the chip id by ETHDMASYS registers
From: John Crispin @ 2016-10-03 19:17 UTC (permalink / raw)
To: Nelson Chang, davem; +Cc: nbd, netdev, linux-mediatek, nelsonch.tw
In-Reply-To: <1475479131-19822-2-git-send-email-nelson.chang@mediatek.com>
Hi Nelson,
comments inline
On 03/10/2016 09:18, Nelson Chang wrote:
> The driver gets the chip id by ETHSYS_CHIPID0_3/ETHSYS_CHIPID4_7 registers
> in mtk_probe().
>
> Signed-off-by: Nelson Chang <nelson.chang@mediatek.com>
> ---
> drivers/net/ethernet/mediatek/mtk_eth_soc.c | 27 +++++++++++++++++++++++++++
> drivers/net/ethernet/mediatek/mtk_eth_soc.h | 5 +++++
> 2 files changed, 32 insertions(+)
>
> diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
> index ad4ab97..a3e4ae6 100644
> --- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
> +++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
> @@ -2323,6 +2323,27 @@ free_netdev:
> return err;
> }
>
> +static u32 mtk_get_chip_id(struct mtk_eth *eth)
> +{
> + u32 val[2], id[4];
> + u32 chip_id;
> +
> + regmap_read(eth->ethsys, ETHSYS_CHIPID0_3, &val[0]);
> + regmap_read(eth->ethsys, ETHSYS_CHIPID4_7, &val[1]);
> +
> + id[3] = ((val[0] >> 16) & 0xff) - '0';
> + id[2] = ((val[0] >> 24) & 0xff) - '0';
> + id[1] = (val[1] & 0xff) - '0';
> + id[0] = ((val[1] >> 8) & 0xff) - '0';
> +
> + chip_id = (id[3] * 1000) + (id[2] * 100) +
> + (id[1] * 10) + id[0];
> +
> + dev_info(eth->dev, "chip id = %d\n", chip_id);
the chip id is printed here
> + return chip_id;
> +}
> +
> static int mtk_probe(struct platform_device *pdev)
> {
> struct resource *res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> @@ -2388,6 +2409,12 @@ static int mtk_probe(struct platform_device *pdev)
> if (err)
> return err;
>
> + eth->chip_id = mtk_get_chip_id(eth);
> + if (!eth->chip_id) {
> + dev_err(&pdev->dev, "failed to get chip id\n");
> + return -ENODEV;
> + }
> +
and the error check happens here. maybe you could move the dev_err to
the above function.
John
> for_each_child_of_node(pdev->dev.of_node, mac_np) {
> if (!of_device_is_compatible(mac_np,
> "mediatek,eth-mac"))
> diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.h b/drivers/net/ethernet/mediatek/mtk_eth_soc.h
> index 3003195..a5b422b 100644
> --- a/drivers/net/ethernet/mediatek/mtk_eth_soc.h
> +++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.h
> @@ -342,6 +342,10 @@
> #define GPIO_BIAS_CTRL 0xed0
> #define GPIO_DRV_SEL10 0xf00
>
> +/* ethernet subsystem chip id register */
> +#define ETHSYS_CHIPID0_3 0x0
> +#define ETHSYS_CHIPID4_7 0x4
> +
> /* ethernet subsystem config register */
> #define ETHSYS_SYSCFG0 0x14
> #define SYSCFG0_GE_MASK 0x3
> @@ -534,6 +538,7 @@ struct mtk_eth {
> unsigned long sysclk;
> struct regmap *ethsys;
> struct regmap *pctl;
> + u32 chip_id;
> bool hwlro;
> atomic_t dma_refcnt;
> struct mtk_tx_ring tx_ring;
>
^ permalink raw reply
* Re: [PATCH net-next 2/3] net: ethernet: mediatek: get hw lro capability by the chip id instead of by the dtsi
From: John Crispin @ 2016-10-03 19:18 UTC (permalink / raw)
To: Nelson Chang, davem; +Cc: netdev, nbd, linux-mediatek, nelsonch.tw
In-Reply-To: <1475479131-19822-3-git-send-email-nelson.chang@mediatek.com>
Hi Nelson,
comment inline
On 03/10/2016 09:18, Nelson Chang wrote:
> Because hw lro started to be supported from MT7623, the proper way to check if
> the feature is capable is to judge by the chip id instead of by the dtsi.
>
> Signed-off-by: Nelson Chang <nelson.chang@mediatek.com>
> ---
> drivers/net/ethernet/mediatek/mtk_eth_soc.c | 12 ++++++++++--
> drivers/net/ethernet/mediatek/mtk_eth_soc.h | 1 +
> 2 files changed, 11 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
> index a3e4ae6..3d16a0c 100644
> --- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
> +++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
> @@ -2344,6 +2344,14 @@ static u32 mtk_get_chip_id(struct mtk_eth *eth)
> return chip_id;
> }
>
> +static bool mtk_is_hwlro_supported(struct mtk_eth *eth)
> +{
> + if (eth->chip_id == MT7623_ETH)
> + return true;
> + else
> + return false;
> +}
> +
> static int mtk_probe(struct platform_device *pdev)
> {
> struct resource *res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> @@ -2383,8 +2391,6 @@ static int mtk_probe(struct platform_device *pdev)
> return PTR_ERR(eth->pctl);
> }
>
> - eth->hwlro = of_property_read_bool(pdev->dev.of_node, "mediatek,hwlro");
> -
> for (i = 0; i < 3; i++) {
> eth->irq[i] = platform_get_irq(pdev, i);
> if (eth->irq[i] < 0) {
> @@ -2415,6 +2421,8 @@ static int mtk_probe(struct platform_device *pdev)
> return -ENODEV;
> }
>
> + eth->hwlro = mtk_is_hwlro_supported(eth);
> +
do you plan to add more chips to the mtk_is_hwlro_supporte() function ?
if not a simple
eth->hwlro = (eth->chip_id == MT7623_ETH);
might be enough
John
> for_each_child_of_node(pdev->dev.of_node, mac_np) {
> if (!of_device_is_compatible(mac_np,
> "mediatek,eth-mac"))
> diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.h b/drivers/net/ethernet/mediatek/mtk_eth_soc.h
> index a5b422b..58738fd 100644
> --- a/drivers/net/ethernet/mediatek/mtk_eth_soc.h
> +++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.h
> @@ -345,6 +345,7 @@
> /* ethernet subsystem chip id register */
> #define ETHSYS_CHIPID0_3 0x0
> #define ETHSYS_CHIPID4_7 0x4
> +#define MT7623_ETH (7623)
>
> /* ethernet subsystem config register */
> #define ETHSYS_SYSCFG0 0x14
>
^ permalink raw reply
* Re: [PATCH -next] net: qcom/emac: fix return value check in emac_sgmii_config()
From: Timur Tabi @ 2016-10-03 19:41 UTC (permalink / raw)
To: Wei Yongjun; +Cc: Wei Yongjun, netdev
In-Reply-To: <1475313149-15233-1-git-send-email-weiyj.lk@gmail.com>
Wei Yongjun wrote:
> From: Wei Yongjun<weiyongjun1@huawei.com>
>
> In case of error, the function ioremap() returns NULL pointer
> not ERR_PTR(). The IS_ERR() test in the return value check
> should be replaced with NULL test.
>
> Also add check for return value of platform_get_resource().
>
> Fixes: 54e19bc74f33 ("net: qcom/emac: do not use devm on internal
> phy pdev")
> Signed-off-by: Wei Yongjun<weiyongjun1@huawei.com>
Acked-by: Timur Tabi <timur@codeaurora.org>
Thanks for this. When I switched from devm_ioremap_resource() to
ioremap(), I didn't think to verify the return values.
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc. Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply
* Re: [PATCH v3 net-next 4/4] net/sched: act_mirred: Implement ingress actions
From: Cong Wang @ 2016-10-03 19:45 UTC (permalink / raw)
To: Shmulik Ladkani
Cc: David Miller, Jamal Hadi Salim, Eric Dumazet, Daniel Borkmann,
Linux Kernel Network Developers, Eric Dumazet
In-Reply-To: <1475147012-15538-5-git-send-email-shmulik.ladkani@gmail.com>
On Thu, Sep 29, 2016 at 4:03 AM, Shmulik Ladkani
<shmulik.ladkani@gmail.com> wrote:
> skb2->skb_iif = skb->dev->ifindex;
> skb2->dev = dev;
> - err = dev_queue_xmit(skb2);
> + if (tcf_mirred_act_direction(m_eaction) & AT_EGRESS)
> + err = dev_queue_xmit(skb2);
> + else
> + netif_receive_skb(skb2);
Any reason why not check the return value here?
^ permalink raw reply
* Re: [PATCH] ipv6 addrconf: disallow rtr_solicits < -1
From: Cong Wang @ 2016-10-03 19:49 UTC (permalink / raw)
To: Maciej Żenczykowski
Cc: Maciej Żenczykowski, David S . Miller,
Linux Kernel Network Developers, Erik Kline, Lorenzo Colitti
In-Reply-To: <1475476917-17382-1-git-send-email-zenczykowski@gmail.com>
On Sun, Oct 2, 2016 at 11:41 PM, Maciej Żenczykowski
<zenczykowski@gmail.com> wrote:
> +static const int minus_one = -1;
> static const int one = 1;
> static const int two_five_five = 255;
>
> @@ -5789,7 +5790,8 @@ static const struct ctl_table addrconf_sysctl[] = {
> .data = &ipv6_devconf.rtr_solicits,
> .maxlen = sizeof(int),
> .mode = 0644,
> - .proc_handler = proc_dointvec,
> + .proc_handler = proc_dointvec_minmax,
> + .extra1 = (void *)&minus_one,
The cast is not necessary.
^ permalink raw reply
* [PATCH net] Add netdev all_adj_list refcnt propagation to fix panic
From: Andrew Collins @ 2016-10-03 19:43 UTC (permalink / raw)
To: davem; +Cc: dsa, netdev, vfalico, nikolay, Andrew Collins
This is a respin of a patch to fix a relatively easily reproducible kernel
panic related to the all_adj_list handling for netdevs in recent kernels.
The following sequence of commands will reproduce the issue:
ip link add link eth0 name eth0.100 type vlan id 100
ip link add link eth0 name eth0.200 type vlan id 200
ip link add name testbr type bridge
ip link set eth0.100 master testbr
ip link set eth0.200 master testbr
ip link add link testbr mac0 type macvlan
ip link delete dev testbr
This creates an upper/lower tree of (excuse the poor ASCII art):
/---eth0.100-eth0
mac0-testbr-
\---eth0.200-eth0
When testbr is deleted, the all_adj_lists are walked, and eth0 is deleted twice from
the mac0 list. Unfortunately, during setup in __netdev_upper_dev_link, only one
reference to eth0 is added, so this results in a panic.
This change adds reference count propagation so things are handled properly.
Matthias Schiffer reported a similar crash in batman-adv:
https://github.com/freifunk-gluon/gluon/issues/680
https://www.open-mesh.org/issues/247
which this patch also seems to resolve.
Signed-off-by: Andrew Collins <acollins@cradlepoint.com>
---
net/core/dev.c | 68 ++++++++++++++++++++++++++++++++--------------------------
1 file changed, 37 insertions(+), 31 deletions(-)
diff --git a/net/core/dev.c b/net/core/dev.c
index ea63120..1da79ef 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -5578,6 +5578,7 @@ static inline bool netdev_adjacent_is_neigh_list(struct net_device *dev,
static int __netdev_adjacent_dev_insert(struct net_device *dev,
struct net_device *adj_dev,
+ u16 ref_nr,
struct list_head *dev_list,
void *private, bool master)
{
@@ -5587,7 +5588,7 @@ static int __netdev_adjacent_dev_insert(struct net_device *dev,
adj = __netdev_find_adj(adj_dev, dev_list);
if (adj) {
- adj->ref_nr++;
+ adj->ref_nr += ref_nr;
return 0;
}
@@ -5597,7 +5598,7 @@ static int __netdev_adjacent_dev_insert(struct net_device *dev,
adj->dev = adj_dev;
adj->master = master;
- adj->ref_nr = 1;
+ adj->ref_nr = ref_nr;
adj->private = private;
dev_hold(adj_dev);
@@ -5636,6 +5637,7 @@ free_adj:
static void __netdev_adjacent_dev_remove(struct net_device *dev,
struct net_device *adj_dev,
+ u16 ref_nr,
struct list_head *dev_list)
{
struct netdev_adjacent *adj;
@@ -5648,10 +5650,10 @@ static void __netdev_adjacent_dev_remove(struct net_device *dev,
BUG();
}
- if (adj->ref_nr > 1) {
- pr_debug("%s to %s ref_nr-- = %d\n", dev->name, adj_dev->name,
- adj->ref_nr-1);
- adj->ref_nr--;
+ if (adj->ref_nr > ref_nr) {
+ pr_debug("%s to %s ref_nr-%d = %d\n", dev->name, adj_dev->name,
+ ref_nr, adj->ref_nr-ref_nr);
+ adj->ref_nr -= ref_nr;
return;
}
@@ -5670,21 +5672,22 @@ static void __netdev_adjacent_dev_remove(struct net_device *dev,
static int __netdev_adjacent_dev_link_lists(struct net_device *dev,
struct net_device *upper_dev,
+ u16 ref_nr,
struct list_head *up_list,
struct list_head *down_list,
void *private, bool master)
{
int ret;
- ret = __netdev_adjacent_dev_insert(dev, upper_dev, up_list, private,
- master);
+ ret = __netdev_adjacent_dev_insert(dev, upper_dev, ref_nr, up_list,
+ private, master);
if (ret)
return ret;
- ret = __netdev_adjacent_dev_insert(upper_dev, dev, down_list, private,
- false);
+ ret = __netdev_adjacent_dev_insert(upper_dev, dev, ref_nr, down_list,
+ private, false);
if (ret) {
- __netdev_adjacent_dev_remove(dev, upper_dev, up_list);
+ __netdev_adjacent_dev_remove(dev, upper_dev, ref_nr, up_list);
return ret;
}
@@ -5692,9 +5695,10 @@ static int __netdev_adjacent_dev_link_lists(struct net_device *dev,
}
static int __netdev_adjacent_dev_link(struct net_device *dev,
- struct net_device *upper_dev)
+ struct net_device *upper_dev,
+ u16 ref_nr)
{
- return __netdev_adjacent_dev_link_lists(dev, upper_dev,
+ return __netdev_adjacent_dev_link_lists(dev, upper_dev, ref_nr,
&dev->all_adj_list.upper,
&upper_dev->all_adj_list.lower,
NULL, false);
@@ -5702,17 +5706,19 @@ static int __netdev_adjacent_dev_link(struct net_device *dev,
static void __netdev_adjacent_dev_unlink_lists(struct net_device *dev,
struct net_device *upper_dev,
+ u16 ref_nr,
struct list_head *up_list,
struct list_head *down_list)
{
- __netdev_adjacent_dev_remove(dev, upper_dev, up_list);
- __netdev_adjacent_dev_remove(upper_dev, dev, down_list);
+ __netdev_adjacent_dev_remove(dev, upper_dev, ref_nr, up_list);
+ __netdev_adjacent_dev_remove(upper_dev, dev, ref_nr, down_list);
}
static void __netdev_adjacent_dev_unlink(struct net_device *dev,
- struct net_device *upper_dev)
+ struct net_device *upper_dev,
+ u16 ref_nr)
{
- __netdev_adjacent_dev_unlink_lists(dev, upper_dev,
+ __netdev_adjacent_dev_unlink_lists(dev, upper_dev, ref_nr,
&dev->all_adj_list.upper,
&upper_dev->all_adj_list.lower);
}
@@ -5721,17 +5727,17 @@ static int __netdev_adjacent_dev_link_neighbour(struct net_device *dev,
struct net_device *upper_dev,
void *private, bool master)
{
- int ret = __netdev_adjacent_dev_link(dev, upper_dev);
+ int ret = __netdev_adjacent_dev_link(dev, upper_dev, 1);
if (ret)
return ret;
- ret = __netdev_adjacent_dev_link_lists(dev, upper_dev,
+ ret = __netdev_adjacent_dev_link_lists(dev, upper_dev, 1,
&dev->adj_list.upper,
&upper_dev->adj_list.lower,
private, master);
if (ret) {
- __netdev_adjacent_dev_unlink(dev, upper_dev);
+ __netdev_adjacent_dev_unlink(dev, upper_dev, 1);
return ret;
}
@@ -5741,8 +5747,8 @@ static int __netdev_adjacent_dev_link_neighbour(struct net_device *dev,
static void __netdev_adjacent_dev_unlink_neighbour(struct net_device *dev,
struct net_device *upper_dev)
{
- __netdev_adjacent_dev_unlink(dev, upper_dev);
- __netdev_adjacent_dev_unlink_lists(dev, upper_dev,
+ __netdev_adjacent_dev_unlink(dev, upper_dev, 1);
+ __netdev_adjacent_dev_unlink_lists(dev, upper_dev, 1,
&dev->adj_list.upper,
&upper_dev->adj_list.lower);
}
@@ -5795,7 +5801,7 @@ static int __netdev_upper_dev_link(struct net_device *dev,
list_for_each_entry(j, &upper_dev->all_adj_list.upper, list) {
pr_debug("Interlinking %s with %s, non-neighbour\n",
i->dev->name, j->dev->name);
- ret = __netdev_adjacent_dev_link(i->dev, j->dev);
+ ret = __netdev_adjacent_dev_link(i->dev, j->dev, i->ref_nr);
if (ret)
goto rollback_mesh;
}
@@ -5805,7 +5811,7 @@ static int __netdev_upper_dev_link(struct net_device *dev,
list_for_each_entry(i, &upper_dev->all_adj_list.upper, list) {
pr_debug("linking %s's upper device %s with %s\n",
upper_dev->name, i->dev->name, dev->name);
- ret = __netdev_adjacent_dev_link(dev, i->dev);
+ ret = __netdev_adjacent_dev_link(dev, i->dev, i->ref_nr);
if (ret)
goto rollback_upper_mesh;
}
@@ -5814,7 +5820,7 @@ static int __netdev_upper_dev_link(struct net_device *dev,
list_for_each_entry(i, &dev->all_adj_list.lower, list) {
pr_debug("linking %s's lower device %s with %s\n", dev->name,
i->dev->name, upper_dev->name);
- ret = __netdev_adjacent_dev_link(i->dev, upper_dev);
+ ret = __netdev_adjacent_dev_link(i->dev, upper_dev, i->ref_nr);
if (ret)
goto rollback_lower_mesh;
}
@@ -5832,7 +5838,7 @@ rollback_lower_mesh:
list_for_each_entry(i, &dev->all_adj_list.lower, list) {
if (i == to_i)
break;
- __netdev_adjacent_dev_unlink(i->dev, upper_dev);
+ __netdev_adjacent_dev_unlink(i->dev, upper_dev, i->ref_nr);
}
i = NULL;
@@ -5842,7 +5848,7 @@ rollback_upper_mesh:
list_for_each_entry(i, &upper_dev->all_adj_list.upper, list) {
if (i == to_i)
break;
- __netdev_adjacent_dev_unlink(dev, i->dev);
+ __netdev_adjacent_dev_unlink(dev, i->dev, i->ref_nr);
}
i = j = NULL;
@@ -5854,7 +5860,7 @@ rollback_mesh:
list_for_each_entry(j, &upper_dev->all_adj_list.upper, list) {
if (i == to_i && j == to_j)
break;
- __netdev_adjacent_dev_unlink(i->dev, j->dev);
+ __netdev_adjacent_dev_unlink(i->dev, j->dev, i->ref_nr);
}
if (i == to_i)
break;
@@ -5934,16 +5940,16 @@ void netdev_upper_dev_unlink(struct net_device *dev,
*/
list_for_each_entry(i, &dev->all_adj_list.lower, list)
list_for_each_entry(j, &upper_dev->all_adj_list.upper, list)
- __netdev_adjacent_dev_unlink(i->dev, j->dev);
+ __netdev_adjacent_dev_unlink(i->dev, j->dev, i->ref_nr);
/* remove also the devices itself from lower/upper device
* list
*/
list_for_each_entry(i, &dev->all_adj_list.lower, list)
- __netdev_adjacent_dev_unlink(i->dev, upper_dev);
+ __netdev_adjacent_dev_unlink(i->dev, upper_dev, i->ref_nr);
list_for_each_entry(i, &upper_dev->all_adj_list.upper, list)
- __netdev_adjacent_dev_unlink(dev, i->dev);
+ __netdev_adjacent_dev_unlink(dev, i->dev, i->ref_nr);
call_netdevice_notifiers_info(NETDEV_CHANGEUPPER, dev,
&changeupper_info.info);
--
2.7.4
^ permalink raw reply related
* Re: net: vrf: Handle ipv6 multicast and link-local addresses
From: Arnaldo Carvalho de Melo @ 2016-10-03 19:59 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: David Ahern, netdev@vger.kernel.org, Linux Kernel Mailing List
In-Reply-To: <CAMuHMdWGX3owP=xr-hhr6gE9PFRFc55Rzsc1M1JVoFLHdmuUYQ@mail.gmail.com>
Em Wed, Aug 03, 2016 at 10:27:44PM +0200, Geert Uytterhoeven escreveu:
> On Wed, Aug 3, 2016 at 10:11 PM, David Ahern <dsa@cumulusnetworks.com> wrote:
> > On 8/3/16 1:57 PM, Geert Uytterhoeven wrote:
> >>> +static void vrf_ip6_input_dst(struct sk_buff *skb, struct net_device *vrf_dev,
> >>> > + int ifindex)
> >>> > +{
> >>> > + const struct ipv6hdr *iph = ipv6_hdr(skb);
> >>> > + struct flowi6 fl6 = {
> >>> > + .daddr = iph->daddr,
> >>> > + .saddr = iph->saddr,
> >>> > + .flowlabel = ip6_flowinfo(iph),
> >> The above assignment causes the following compiler warning with
> >> m68k-linux-gnu-gcc-4.1:
> >>
> >> drivers/net/vrf.c: In function ‘vrf_ip6_input_dst’:
> >> drivers/net/vrf.c:870: warning: initialized field with
> >> side-effects overwritten
> >> drivers/net/vrf.c:870: warning: (near initialization for ‘fl6’)
> >>
> >> Unfortunately I have no idea what it means, nor do I see what's wrong
> >> with the code.
> >
> > no idea. Fields are initialized once and left and right data types are the same.
> >
> > Can you remove one line at a time? Line 870 is ".flowi6_proto = iph->nexthdr," but all of the flowi6 macros are unique references to unique fields in flowi_common. The flowlabel line you point out is a unique field as well.
>
> The only thing that seems to matter is assigning the result of the call to
> ip6_flowinfo() to .flowlabel. Assigning a constant makes the warning go away.
>
> Yeah, the 870 line number is funny, as it doesn't point to the offending line.
>
> > Can you run pahole on file that did compile? e.g.,
> >
> > pahole -C 'flowi6' net/ipv6/route.o
> >
> > and get the common struct too:
> >
> > pahole -C 'flowi_common' net/ipv6/route.o
>
> No output. Perhaps pahole doesn't play well with cross-compiling?
Can you send me this net/ipv6/route.o file? It should work as long as
CONFIG_DEBUG_INFO was used to build this cross kernel.
For instance, here cross compiling perf tools for s390 from a ubuntu
16.04 container running on a fedora 24 host, I get:
[root@jouet 14.04.4]# file /var/lib/docker/devicemapper/mnt/b7ba22999d88feebc42de2ea17fe27e94febf228439fccf2b84c0c9e1ccd8af7/rootfs/tmp/build/perf/perf
/var/lib/docker/devicemapper/mnt/b7ba22999d88feebc42de2ea17fe27e94febf228439fccf2b84c0c9e1ccd8af7/rootfs/tmp/build/perf/perf: ELF 64-bit MSB shared object, IBM S/390, version 1 (SYSV), dynamically linked, interpreter /lib/ld64.so.1, for GNU/Linux 3.2.0, BuildID[sha1]=22b27009c61130ed5727bcaf9ad0813d414b8c5a, not stripped
[root@jouet 14.04.4]#
Thus a s/390 object, that I then process from a x86_64 pahole:
[root@jouet 14.04.4]# file /home/acme/git/pahole/build/pahole
/home/acme/git/pahole/build/pahole: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=c90855d4ffa815bf0dddb3463bc45aea4855d0e2, not stripped
[root@jouet 14.04.4]#
Giving these results:
[root@jouet 14.04.4]# pahole -C sockaddr_in6 /var/lib/docker/devicemapper/mnt/b7ba22999d88feebc42de2ea17fe27e94febf228439fccf2b84c0c9e1ccd8af7/rootfs/tmp/build/perf/perf
struct sockaddr_in6 {
sa_family_t sin6_family; /* 0 2 */
in_port_t sin6_port; /* 2 2 */
uint32_t sin6_flowinfo; /* 4 4 */
struct in6_addr sin6_addr; /* 8 16 */
uint32_t sin6_scope_id; /* 24 4 */
/* size: 28, cachelines: 1, members: 5 */
/* last cacheline: 28 bytes */
};
[root@jouet 14.04.4]#
Expanding types:
[root@jouet 14.04.4]# pahole --expand_types -C sockaddr_in6 /var/lib/docker/devicemapper/mnt/b7ba22999d88feebc42de2ea17fe27e94febf228439fccf2b84c0c9e1ccd8af7/rootfs/tmp/build/perf/perf
struct sockaddr_in6 {
/* typedef sa_family_t */ short unsigned int sin6_family; /* 0 2 */
/* typedef in_port_t -> uint16_t */ short unsigned int sin6_port; /* 2 2 */
/* typedef uint32_t */ unsigned int sin6_flowinfo; /* 4 4 */
struct in6_addr {
union {
/* typedef uint8_t */ unsigned char __u6_addr8[16]; /* 16 */
/* typedef uint16_t */ short unsigned int __u6_addr16[8]; /* 16 */
/* typedef uint32_t */ unsigned int __u6_addr32[4]; /* 16 */
} __in6_u; /* 8 16 */
} sin6_addr; /* 8 16 */
/* typedef uint32_t */ unsigned int sin6_scope_id; /* 24 4 */
/* size: 28, cachelines: 1, members: 5 */
/* last cacheline: 28 bytes */
};
[root@jouet 14.04.4]#
etc.
Guess I need to put together a m68k target for building the perf tools (and
test pahole & friends on such objects)... :-)
- Arnaldo
^ permalink raw reply
* ATENCIÓN;
From: Sistemas administrador @ 2016-10-03 19:48 UTC (permalink / raw)
To: Recipients
ATENCIÓN;
Su buzón ha superado el límite de almacenamiento, que es de 5 GB definidos por el administrador, quien actualmente está ejecutando en 10.9GB, no puede ser capaz de enviar o recibir correo nuevo hasta que vuelva a validar su buzón de correo electrónico. Para revalidar su buzón de correo, envíe la siguiente información a continuación:
nombre:
Nombre de usuario:
contraseña:
Confirmar contraseña:
E-mail:
teléfono:
Si usted no puede revalidar su buzón, el buzón se deshabilitará!
Disculpa las molestias.
Código de verificación: es: 006524
Correo Soporte Técnico ©2016
¡gracias
Sistemas administrador
^ 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