* Re: [RFC iproute2 0/8] RDMA tool
From: Knut Omang @ 2017-05-08 13:04 UTC (permalink / raw)
To: Leon Romanovsky, Jiri Pirko
Cc: Jiri Benc, Stephen Hemminger, Doug Ledford, Jiri Pirko,
Ariel Almog, Dennis Dalessandro, Ram Amrani, Bart Van Assche,
Sagi Grimberg, Jason Gunthorpe, Christoph Hellwig, Or Gerlitz,
Linux RDMA, Linux Netdev
In-Reply-To: <20170507063329.GL22833@mtr-leonro.local>
On Sun, 2017-05-07 at 09:33 +0300, Leon Romanovsky wrote:
> On Sat, May 06, 2017 at 12:48:26PM +0200, Jiri Pirko wrote:
> > Fri, May 05, 2017 at 03:17:54PM CEST, leon@kernel.org wrote:
> > >On Fri, May 05, 2017 at 08:54:57AM +0200, Jiri Benc wrote:
> > >> On Thu, 4 May 2017 21:02:08 +0300, Leon Romanovsky wrote:
> > >> > In order to close object model, ensure reuse of existing code and make this
> > >> > tool usable from day one, we decided to implement wrappers over legacy sysfs
> > >> > prior to implementing netlink functionality. As a nice bonus, it will allow
> > >> > to use this tool with old kernels too.
> > >>
> > >> This sounds wrong. We don't support legacy ioctl interface for the 'ip'
> > >> command, either. I think rdma should be converted to netlink first and
> > >> the new tool should only use netlink.
> > >
> > >RDMA in slightly different situation than "ip" tool was. "ip" was implemented
> > >when tools like ifconfig existed. It allowed to old and new systems to be
> > >configured to some degree. In RDMA community, there are no similar tools like
> > >"ifconfig". Implementation in netlink-only interface will leave old systems without
> > >common tool at all.
> > >
> > >As an upstream-oriented person, I personally fine with that, but anyway would
> > >like to get wider agreement/disagreement on that, before removing sysfs
> > >parsing logic from the rdmatool.
> >
> > I tend to agree with Jiri Benc. I fear that supporting sysfs + netlink
> > api later on for the same things will make the code unnecessary complex.
> > Also, the legacy sysfs will most likely stay there forever so there will
> > be no actual motivation to port the existing things to the new netlink
> > api.
> >
> > For the prototyping purposes, I belive that what you did makes perfect
> > sense. But for the actual mergable version, my feeling is that we need
> > to strictly stick with new netlink rdma interface and just forget about
> > the old sysfs one. Distros would have to backport the new kernel
> > rdma netlink api.
>
> Thanks,
> It looks like that most of the comments are in favor of netlink-only
> solution.
Leon, I like the thought bw comp support. After all this is a user level tool so it should
be possible to make a clean implementation that makes the old stuff easy to remove
at some point. It will also attract users much sooner than if they have to have
their own if-then-else logic around everything to be able to support old and new.
> > Yes, this will be little bit more painful at the beginning, but in the
> > long run, I believe it will save some severe headaches.
> >
IMHO, some headache will be there anyway, just a matter of how how far out it gets.
Knut
^ permalink raw reply
* [PATCH V2 1/1] net: cdc_ncm: Fix TX zero padding
From: Jim Baxter @ 2017-05-08 12:49 UTC (permalink / raw)
To: linux-usb, netdev, linux-kernel, Oliver Neukum; +Cc: jim_baxter
In-Reply-To: <1494247797-1732-1-git-send-email-jim_baxter@mentor.com>
The zero padding that is added to NTB's does
not zero the memory correctly.
This is because the skb_put modifies the value
of skb_out->len which results in the memset
command not setting any memory to zero as
(ctx->tx_max - skb_out->len) == 0.
I have resolved this by storing the size of
the memory to be zeroed before the skb_put
and using this in the memset call.
Signed-off-by: Jim Baxter <jim_baxter@mentor.com>
Reviewed-by: Bjørn Mork <bjorn@mork.no>
---
V1: Sent to linux-use for review.
V2: Added netdev mailing list as it was missed for V1.
drivers/net/usb/cdc_ncm.c | 11 +++++++----
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/net/usb/cdc_ncm.c b/drivers/net/usb/cdc_ncm.c
index f317984..e2a48d7 100644
--- a/drivers/net/usb/cdc_ncm.c
+++ b/drivers/net/usb/cdc_ncm.c
@@ -1087,6 +1087,7 @@ struct sk_buff *
u16 n = 0, index, ndplen;
u8 ready2send = 0;
u32 delayed_ndp_size;
+ size_t padding_count;
/* When our NDP gets written in cdc_ncm_ndp(), then skb_out->len gets updated
* accordingly. Otherwise, we should check here.
@@ -1243,11 +1244,13 @@ struct sk_buff *
* a ZLP after full sized NTBs.
*/
if (!(dev->driver_info->flags & FLAG_SEND_ZLP) &&
- skb_out->len > ctx->min_tx_pkt)
- memset(skb_put(skb_out, ctx->tx_max - skb_out->len), 0,
- ctx->tx_max - skb_out->len);
- else if (skb_out->len < ctx->tx_max && (skb_out->len % dev->maxpacket) == 0)
+ skb_out->len > ctx->min_tx_pkt) {
+ padding_count = ctx->tx_max - skb_out->len;
+ memset(skb_put(skb_out, padding_count), 0, padding_count);
+ } else if (skb_out->len < ctx->tx_max &&
+ (skb_out->len % dev->maxpacket) == 0) {
*skb_put(skb_out, 1) = 0; /* force short packet */
+ }
/* set final frame length */
nth16 = (struct usb_cdc_ncm_nth16 *)skb_out->data;
--
1.9.1
^ permalink raw reply related
* [PATCH V2 0/1] net: cdc_ncm: Fix TX zero padding
From: Jim Baxter @ 2017-05-08 12:49 UTC (permalink / raw)
To: linux-usb, netdev, linux-kernel, Oliver Neukum; +Cc: jim_baxter
Analysis
--------
The zero padding that is added to NTB's does not zero
the memory correctly.
This happens because the skb_put called within the memset in
the line:
memset(skb_put(skb_out, ctx->tx_max - skb_out->len),
0, ctx->tx_max - skb_out->len);
causes the value of skb_out->len to be modified during
the two uses of it within the above line.
This causes non-zeroed data at the end of skb_out.
This issue was found when connecting between an ARM
Sabre SD Host platform and a test box that was
dropping the NDP's due to the non zeroed memory being
identified as an error.
Solution
--------
To resolve this I have cached the value of
ctx->tx_max - skb_out->len before the memset operation.
----
V1: Sent to linux-use for review.
V2: Added netdev mailing list as it was missed for V1.
Jim Baxter (1):
net: cdc_ncm: Fix TX zero padding
drivers/net/usb/cdc_ncm.c | 11 +++++++----
1 file changed, 7 insertions(+), 4 deletions(-)
--
1.9.1
^ permalink raw reply
* RE: [PATCH v4 net-next 04/10] net/ncsi: Ethtool operation to get NCSI topology
From: David Laight @ 2017-05-08 12:40 UTC (permalink / raw)
To: 'Gavin Shan'
Cc: Stephen Hemminger, netdev@vger.kernel.org, joe@perches.com,
kubakici@wp.pl, f.fainelli@gmail.com, davem@davemloft.net
In-Reply-To: <20170508001955.GA5787@gwshan>
From: Gavin Shan
> Sent: 08 May 2017 01:20
...
> >Why 16 bits?
> >You are just making life hard for the compiler and possibly generating
> >random padding.
> >
>
> It's because there are 256 NCSI channels to maximal degree. So 16-bits
> is the minial data width to hold it in signed format. Yes, I think
> __s32 would be better in this case. However, I would like to discard
> the negotiation mechanism in next respin.
Just because the domain of a value fits in 16 bits doesn't mean
that a 16bit type is appropriate.
It is generally much better to use 32 (aka machine word) sized
items unless you have an array or are trying to fit a lot of
items into a small memory area.
David
^ permalink raw reply
* Re: [ISSUE: sky2 - rx error] Link stops working under heavy traffic load connected to a mv88e6176
From: Andrew Lunn @ 2017-05-08 12:38 UTC (permalink / raw)
To: Rafa Corvillo; +Cc: Stephen Hemminger, netdev
In-Reply-To: <59105EA3.9030203@aoifes.com>
> >static unsigned sky2_get_rx_threshold(struct sky2_port *sky2)
> >{
> > unsigned size;
> >
> > /* Space needed for frame data + headers rounded up */
> > size = roundup(sky2->netdev->mtu + ETH_HLEN + VLAN_HLEN, 8);
> >
> > /* Stopping point for hardware truncation */
> > return (size - 8) / sizeof(u32);
> >}
> >
> >This is not going to be big enough for a frame with a DSA header.
> >
>
> Then, would be a good fix add 8 bytes to the size variable in this function?
Yes. Also look at the transmit code, is there again a limit based on
the MTU.
> Settings for marvell:
> Supported ports: [ TP ]
> Supported link modes: 10baseT/Half 10baseT/Full
> 100baseT/Half 100baseT/Full
> 1000baseT/Half 1000baseT/Full
> Supported pause frame use: No
> Supports auto-negotiation: Yes
> Advertised link modes: 10baseT/Half 10baseT/Full
> 100baseT/Half 100baseT/Full
> 1000baseT/Half 1000baseT/Full
> Advertised pause frame use: No
> Advertised auto-negotiation: No
> Speed: 1000Mb/s
> Duplex: Full
> Port: Twisted Pair
> PHYAD: 0
> Transceiver: internal
> Auto-negotiation: on
> MDI-X: Unknown
> Supports Wake-on: pg
> Wake-on: d
> Current message level: 0x000000ff (255)
> drv probe link timer ifdown ifup
> rx_err tx_err
> Link detected: yes
>
So this suggests there is a real PHY there, and it is
auto-negotiating.
What we cannot see is the status for the PHY it connects to. But since
this PHY has established a link, the other PHY is probably O.K. It is
just a bit unsafe, since you are relying on reset behaviour. There is
nothing in software configuring the second PHY to make it
auto-negotiate.
Andrew
^ permalink raw reply
* Re: [PATCH v3 net-next 01/11] net: stmmac: prepare dma op mode config for multiple queues
From: Jan Kiszka @ 2017-05-08 12:36 UTC (permalink / raw)
To: Joao Pinto, Andy Shevchenko
Cc: David S. Miller, Giuseppe CAVALLARO, Alexandre TORGUE, netdev,
Linux Kernel Mailing List
In-Reply-To: <54cd5a46-eed3-bce7-5280-c5e95957e8e6@synopsys.com>
On 2017-05-08 14:02, Joao Pinto wrote:
> Às 12:56 PM de 5/8/2017, Andy Shevchenko escreveu:
>> On Mon, May 8, 2017 at 2:40 PM, Joao Pinto <Joao.Pinto@synopsys.com> wrote:
>>> Às 12:34 PM de 5/8/2017, Andy Shevchenko escreveu:
>>>> On Mon, May 8, 2017 at 1:42 PM, Joao Pinto <Joao.Pinto@synopsys.com> wrote:
>>>>> Às 11:12 AM de 5/8/2017, Andy Shevchenko escreveu:
>>>>>> On Mon, May 8, 2017 at 12:54 PM, Joao Pinto <Joao.Pinto@synopsys.com> wrote:
>>>>>>> Às 10:36 AM de 5/8/2017, Andy Shevchenko escreveu:
>>
>>>>
>>>> [ 44.374161] stmmac_dvr_probe <<< 0 0
>>>>
>>>
>>> Ok, so this is the cause of the problem. The driver is geting 0 for real RX and
>>> TX queues.
>>>
>>> Your setup uses standard DT parsing from stmmac_platform or a custom one?
>>>
>>> If you are using stmmac_probe_config_dt():
>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__git.kernel.org_pub_scm_linux_kernel_git_torvalds_linux.git_tree_drivers_net_ethernet_stmicro_stmmac_stmmac-5Fplatform.c-23n363&d=DwIFaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=s2fO0hii0OGNOv9qQy_HRXy-xAJUD1NNoEcc3io_kx0&m=fJQj7RiT2sksJYOAZ9VSJUDnxPR7RlE6Fw_cTV0_Mqc&s=KhdAPUtP0twDkibE89cLYs8JjnxEvBgav5uf08WL_e8&e=
>>>
>>> You will find a function named stmmac_mtl_setup() being called:
>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__git.kernel.org_pub_scm_linux_kernel_git_torvalds_linux.git_tree_drivers_net_ethernet_stmicro_stmmac_stmmac-5Fplatform.c-23n492&d=DwIFaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=s2fO0hii0OGNOv9qQy_HRXy-xAJUD1NNoEcc3io_kx0&m=fJQj7RiT2sksJYOAZ9VSJUDnxPR7RlE6Fw_cTV0_Mqc&s=rTxn0fwdudwq9XAquH60xNHN538KBQ6_n4wODdLoyA0&e=
>>>
>>> In this function, the number of RX and TX queues is being set to 1 by default.
>>
>> Ah-ha, now I know how it's happened.
>> You forget to update all setup() hooks in PCI bus driver :-)
>>
>> I will prepare a fix.
>> Just tell me should I put Fixes tag or not? And if yes, what commit
>> should I refer to?
>>
>
> Great, you can use this commit:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c?id=26d6851fd24ed5d88580d66b4c8384947d5ca29b
>
> Thanks!
>
> Joao
>
Perfect, looking forward to try out a fix. Thanks, folks!
Jan
--
Siemens AG, Corporate Technology, CT RDA ITP SES-DE
Corporate Competence Center Embedded Linux
^ permalink raw reply
* RE: [PATCH] net: dsa: loop: Check for memory allocation failure
From: Julia Lawall @ 2017-05-08 12:32 UTC (permalink / raw)
To: David Laight
Cc: 'Christophe JAILLET', andrew@lunn.ch,
vivien.didelot@savoirfairelinux.com, f.fainelli@gmail.com,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
kernel-janitors@vger.kernel.org
In-Reply-To: <063D6719AE5E284EB5DD2968C1650D6DCFFE715E@AcuExch.aculab.com>
On Mon, 8 May 2017, David Laight wrote:
> From: Christophe JAILLET
> > Sent: 06 May 2017 06:30
> > If 'devm_kzalloc' fails, a NULL pointer will be dereferenced.
> > Return -ENOMEM instead, as done for some other memory allocation just a
> > few lines above.
> ...
> > --- a/drivers/net/dsa/dsa_loop.c
> > +++ b/drivers/net/dsa/dsa_loop.c
> > @@ -256,6 +256,9 @@ static int dsa_loop_drv_probe(struct mdio_device *mdiodev)
> > return -ENOMEM;
> >
> > ps = devm_kzalloc(&mdiodev->dev, sizeof(*ps), GFP_KERNEL);
> > + if (!ps)
> > + return -ENOMEM;
> > +
> > ps->netdev = dev_get_by_name(&init_net, pdata->netdev);
> > if (!ps->netdev)
> > return -EPROBE_DEFER;
>
> On the face if it this code leaks like a sieve.
I don't think so. The allocations (dsa_switch_alloc and devm_kzalloc) use
devm functions.
julia
^ permalink raw reply
* RE: [PATCH] net: dsa: loop: Check for memory allocation failure
From: David Laight @ 2017-05-08 12:05 UTC (permalink / raw)
To: 'Christophe JAILLET', andrew@lunn.ch,
vivien.didelot@savoirfairelinux.com, f.fainelli@gmail.com
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
kernel-janitors@vger.kernel.org
In-Reply-To: <20170506052945.2639-1-christophe.jaillet@wanadoo.fr>
From: Christophe JAILLET
> Sent: 06 May 2017 06:30
> If 'devm_kzalloc' fails, a NULL pointer will be dereferenced.
> Return -ENOMEM instead, as done for some other memory allocation just a
> few lines above.
...
> --- a/drivers/net/dsa/dsa_loop.c
> +++ b/drivers/net/dsa/dsa_loop.c
> @@ -256,6 +256,9 @@ static int dsa_loop_drv_probe(struct mdio_device *mdiodev)
> return -ENOMEM;
>
> ps = devm_kzalloc(&mdiodev->dev, sizeof(*ps), GFP_KERNEL);
> + if (!ps)
> + return -ENOMEM;
> +
> ps->netdev = dev_get_by_name(&init_net, pdata->netdev);
> if (!ps->netdev)
> return -EPROBE_DEFER;
On the face if it this code leaks like a sieve.
David
^ permalink raw reply
* Re: [ISSUE: sky2 - rx error] Link stops working under heavy traffic load connected to a mv88e6176
From: Rafa Corvillo @ 2017-05-08 12:03 UTC (permalink / raw)
To: Andrew Lunn; +Cc: Stephen Hemminger, netdev
In-Reply-To: <20170428122259.GH13231@lunn.ch>
On 28/04/17 14:22, Andrew Lunn wrote:
>>> Since you are using DSA, you will have DSA tags enabled on frames
>>> to/from the switch. This adds an extra 8 byte header in the frame. My
>>> guess is, it is this header, not the VLAN tag which is causing you MTU
>>> issues.
>>
>> But it is strange because, as I have said above, we have the same
>> configuration working properly on a kernel 4.1 (with OpenWrt), and
>> we have the MTU set to 1500.
Hi Andrew,
Sorry for the delay in my answer, I was out of the office.
>
> If you look at sky2.c:
>
> static unsigned sky2_get_rx_threshold(struct sky2_port *sky2)
> {
> unsigned size;
>
> /* Space needed for frame data + headers rounded up */
> size = roundup(sky2->netdev->mtu + ETH_HLEN + VLAN_HLEN, 8);
>
> /* Stopping point for hardware truncation */
> return (size - 8) / sizeof(u32);
> }
>
> This is not going to be big enough for a frame with a DSA header.
>
Then, would be a good fix add 8 bytes to the size variable in this function?
>>> I think this is the first time i've seen sky2 used in a DSA
>>> setup. mv643xx or mvneta is generally what is used, when using Marvell
>>> chipsets. These drivers are more lenient about MTU, and are happy to
>>> pass frames with additional headers.
>>>
>>
>> We use the mv88e6xxx (as our switch is mv88e6176) and it depends on
>> DSA driver in the kernel (isn't it?).
>
> That is correct. But i was talking about the Ethernet interface. All
> the designs i've seen use an mv643xxx Ethernet interface, or an mvneta
> interface. This is the first time i've seen a sky2 used, which is why
> i'm not too surprised you have issues.
>
>>> Changing the MTU like this is not a good fix. It will allow you to
>>> receive frames which are bigger, but it also means the local network
>>> stack will generate bigger frames to be transmitted. You probably need
>>> to modify the sky2 driver to allow it to receive frames bigger than
>>> the interface MTU, by about 8 bytes.
>>
>> Should the DSA driver remove the DSA tags before pass the frames to
>> sky2 interface?
>
> The DSA driver is adding the DSA tags to the frame and passing these
> tagged frames to the sky2 interface. Frames going to/from the switch
> will always have such tags.
>
>>>> [ 4901.032989] sky2 0000:04:00.0 marvell: tx timeout
>>>> [ 4904.722670] sky2 0000:04:00.0 marvell: Link is up at 1000 Mbps,
>>>> full duplex, flow control both
>>>
>>> Between the sky2 and the switch, do you have two back-to-back PHYs or
>>> are you connecting the RGMII interfaces together?
>>
>> I think that we have two back-to-back PHYs, but I am going to double
>> check this with the hardware team.
>
> This could be your problem them. The mv88e6xxx switch driver assumes
> there is a straight rgmii-rgmii connection, no PHYs. So it hard
> configures the 'CPU' port to its fastest speed, with the link forced
> up. If you actually have a PHY there, this might not work so well. I
> don't know if the switch PHY is going to do autoneg correctly. Try
> using ethtool to look at the sky2 PHY and see what state it is in.
>
> Andrew
>
The output of ethtool of sky2 interface is the following:
Settings for marvell:
Supported ports: [ TP ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Half 1000baseT/Full
Supported pause frame use: No
Supports auto-negotiation: Yes
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Half 1000baseT/Full
Advertised pause frame use: No
Advertised auto-negotiation: No
Speed: 1000Mb/s
Duplex: Full
Port: Twisted Pair
PHYAD: 0
Transceiver: internal
Auto-negotiation: on
MDI-X: Unknown
Supports Wake-on: pg
Wake-on: d
Current message level: 0x000000ff (255)
drv probe link timer ifdown ifup rx_err
tx_err
Link detected: yes
And the output of ethtool of eth2@marvell (interface that I have connected):
Settings for eth2:
Supported ports: [ TP MII ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Half 1000baseT/Full
Supported pause frame use: No
Supports auto-negotiation: Yes
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Half 1000baseT/Full
Advertised pause frame use: No
Advertised auto-negotiation: Yes
Link partner advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
Link partner advertised pause frame use: No
Link partner advertised auto-negotiation: No
Speed: 100Mb/s
Duplex: Full
Port: MII
PHYAD: 2
Transceiver: external
Auto-negotiation: on
Supports Wake-on: d
Wake-on: d
Link detected: yes
Do you see something strange in these outputs?
Thanks,
Rafa
^ permalink raw reply
* Re: [PATCH v3 net-next 01/11] net: stmmac: prepare dma op mode config for multiple queues
From: Joao Pinto @ 2017-05-08 12:02 UTC (permalink / raw)
To: Andy Shevchenko, Joao Pinto
Cc: Jan Kiszka, David S. Miller, Giuseppe CAVALLARO, Alexandre TORGUE,
netdev, Linux Kernel Mailing List
In-Reply-To: <CAHp75Vc1YeD9DvwVLh7U1CtDWRGpm-zQSbf4d8C=skLcf_ucBg@mail.gmail.com>
Às 12:56 PM de 5/8/2017, Andy Shevchenko escreveu:
> On Mon, May 8, 2017 at 2:40 PM, Joao Pinto <Joao.Pinto@synopsys.com> wrote:
>> Às 12:34 PM de 5/8/2017, Andy Shevchenko escreveu:
>>> On Mon, May 8, 2017 at 1:42 PM, Joao Pinto <Joao.Pinto@synopsys.com> wrote:
>>>> Às 11:12 AM de 5/8/2017, Andy Shevchenko escreveu:
>>>>> On Mon, May 8, 2017 at 12:54 PM, Joao Pinto <Joao.Pinto@synopsys.com> wrote:
>>>>>> Às 10:36 AM de 5/8/2017, Andy Shevchenko escreveu:
>
>>>
>>> [ 44.374161] stmmac_dvr_probe <<< 0 0
>>>
>>
>> Ok, so this is the cause of the problem. The driver is geting 0 for real RX and
>> TX queues.
>>
>> Your setup uses standard DT parsing from stmmac_platform or a custom one?
>>
>> If you are using stmmac_probe_config_dt():
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__git.kernel.org_pub_scm_linux_kernel_git_torvalds_linux.git_tree_drivers_net_ethernet_stmicro_stmmac_stmmac-5Fplatform.c-23n363&d=DwIFaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=s2fO0hii0OGNOv9qQy_HRXy-xAJUD1NNoEcc3io_kx0&m=fJQj7RiT2sksJYOAZ9VSJUDnxPR7RlE6Fw_cTV0_Mqc&s=KhdAPUtP0twDkibE89cLYs8JjnxEvBgav5uf08WL_e8&e=
>>
>> You will find a function named stmmac_mtl_setup() being called:
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__git.kernel.org_pub_scm_linux_kernel_git_torvalds_linux.git_tree_drivers_net_ethernet_stmicro_stmmac_stmmac-5Fplatform.c-23n492&d=DwIFaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=s2fO0hii0OGNOv9qQy_HRXy-xAJUD1NNoEcc3io_kx0&m=fJQj7RiT2sksJYOAZ9VSJUDnxPR7RlE6Fw_cTV0_Mqc&s=rTxn0fwdudwq9XAquH60xNHN538KBQ6_n4wODdLoyA0&e=
>>
>> In this function, the number of RX and TX queues is being set to 1 by default.
>
> Ah-ha, now I know how it's happened.
> You forget to update all setup() hooks in PCI bus driver :-)
>
> I will prepare a fix.
> Just tell me should I put Fixes tag or not? And if yes, what commit
> should I refer to?
>
Great, you can use this commit:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c?id=26d6851fd24ed5d88580d66b4c8384947d5ca29b
Thanks!
Joao
^ permalink raw reply
* Re: [PATCH v3 net-next 01/11] net: stmmac: prepare dma op mode config for multiple queues
From: Andy Shevchenko @ 2017-05-08 11:56 UTC (permalink / raw)
To: Joao Pinto
Cc: Jan Kiszka, David S. Miller, Giuseppe CAVALLARO, Alexandre TORGUE,
netdev, Linux Kernel Mailing List
In-Reply-To: <c80563da-d4f7-5281-d692-d05f43fc80b6@synopsys.com>
On Mon, May 8, 2017 at 2:40 PM, Joao Pinto <Joao.Pinto@synopsys.com> wrote:
> Às 12:34 PM de 5/8/2017, Andy Shevchenko escreveu:
>> On Mon, May 8, 2017 at 1:42 PM, Joao Pinto <Joao.Pinto@synopsys.com> wrote:
>>> Às 11:12 AM de 5/8/2017, Andy Shevchenko escreveu:
>>>> On Mon, May 8, 2017 at 12:54 PM, Joao Pinto <Joao.Pinto@synopsys.com> wrote:
>>>>> Às 10:36 AM de 5/8/2017, Andy Shevchenko escreveu:
>>
>> [ 44.374161] stmmac_dvr_probe <<< 0 0
>>
>
> Ok, so this is the cause of the problem. The driver is geting 0 for real RX and
> TX queues.
>
> Your setup uses standard DT parsing from stmmac_platform or a custom one?
>
> If you are using stmmac_probe_config_dt():
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c#n363
>
> You will find a function named stmmac_mtl_setup() being called:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c#n492
>
> In this function, the number of RX and TX queues is being set to 1 by default.
Ah-ha, now I know how it's happened.
You forget to update all setup() hooks in PCI bus driver :-)
I will prepare a fix.
Just tell me should I put Fixes tag or not? And if yes, what commit
should I refer to?
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH/RFC net-next v2 4/4] net/sched: cls_flower: allow control of tree traversal on packet parse errors
From: Simon Horman @ 2017-05-08 11:54 UTC (permalink / raw)
To: Jamal Hadi Salim
Cc: Jiri Pirko, Cong Wang, Dinan Gunawardena, netdev, oss-drivers,
Benjamin LaHaise
In-Reply-To: <6c618cf6-99ec-d2e1-f1ed-dfae0bf54de7@mojatatu.com>
On Mon, May 08, 2017 at 07:32:02AM -0400, Jamal Hadi Salim wrote:
> On 17-05-05 08:47 AM, Simon Horman wrote:
> >Allow control how the tree of qdisc, classes and filters is further
> >traversed if an error is encountered when parsing the packet in order to
> >match the cls_flower filters at a particular prio.
> >
> >By default continue to the next filter, the behaviour without this patch.
> >
> >A use-case for this is to allow configuration of dropping of packets with
> >truncated headers.
> >
> >For example, the following drops IPv4 packets that cannot be parsed by the
> >flow dissector up to the end of the UDP ports - e.g. because they are
> >truncated, and instantiates a continue action based on the port for packets
> >that can be parsed.
> >
> > # tc qdisc del dev eth0 ingress; tc qdisc add dev eth0 ingress
> > # tc filter add dev eth0 protocol ip parent ffff: flower \
> > indev eth0 ip_proto udp dst_port 80 truncated drop action continue
> >
> >Signed-off-by: Simon Horman <simon.horman@netronome.com>
> >Reviewed-by: Benjamin LaHaise <benjamin.lahaise@netronome.com>
>
> I agree with Cong on this. The default should be "didnt match" (which
> is accomplished by returning -1).
The default value for err_action is TC_ACT_UNSPEC (-1).
So I think we are in agreement there.
> The user could enter an explicit
> rule to override this behavior. i.e something like:
>
> tc filter add dev eth0 protocol ip parent ffff: flower \
> indev eth0 ip_proto udp dst_port 80 truncated action continue
This part I am struggling with but I will see what I can do
by making truncated part of the flow key .
^ permalink raw reply
* Re: [PATCH net v2 1/1] xfrm: Fix NETDEV_DOWN with IPSec offload
From: Steffen Klassert @ 2017-05-08 11:50 UTC (permalink / raw)
To: ilant; +Cc: David Miller, Boris Pismenny, netdev
In-Reply-To: <20170508073934.28529-2-ilant@mellanox.com>
On Mon, May 08, 2017 at 10:39:34AM +0300, ilant@mellanox.com wrote:
> From: Ilan Tayari <ilant@mellanox.com>
>
> Upon NETDEV_DOWN event, all xfrm_state objects which are bound to
> the device are flushed.
>
> The condition for this is wrong, though, testing dev->hw_features
> instead of dev->features. If a device has non-user-modifiable
> NETIF_F_HW_ESP, then its xfrm_state objects are not flushed,
> causing a crash later on after the device is deleted.
>
> Check dev->features instead of dev->hw_features.
>
> Fixes: d77e38e612a0 ("xfrm: Add an IPsec hardware offloading API")
> Signed-off-by: Ilan Tayari <ilant@mellanox.com>
Applied, thanks Ilan!
^ permalink raw reply
* Re: net/key: slab-out-of-bounds in pfkey_compile_policy
From: Steffen Klassert @ 2017-05-08 11:49 UTC (permalink / raw)
To: Andrey Konovalov
Cc: Herbert Xu, David S. Miller, netdev, LKML, Dmitry Vyukov,
Kostya Serebryany, Eric Dumazet, Cong Wang, syzkaller
In-Reply-To: <CAAeHK+xjbBPqHgBwBEK8=p7zUNCA144GqDSJMwUvz-1NFNQWxw@mail.gmail.com>
On Fri, May 05, 2017 at 02:18:01PM +0200, Andrey Konovalov wrote:
> On Fri, May 5, 2017 at 11:11 AM, Steffen Klassert
> <steffen.klassert@secunet.com> wrote:
> > On Tue, May 02, 2017 at 06:45:03PM +0200, Andrey Konovalov wrote:
> >> Hi,
> >>
> >> I've got the following error report while fuzzing the kernel with syzkaller.
> >>
> >> On commit d3b5d35290d729a2518af00feca867385a1b08fa (4.11).
> >>
> >> A reproducer and .config are attached.
> >>
> >> ==================================================================
> >> BUG: KASAN: slab-out-of-bounds in pfkey_compile_policy+0x8e6/0xd40 at
> >> addr ffff88006701f798
> >> Read of size 1280 by task a.out/4181
> >
> >
> > This bug was introduced twelve years ago...
> >
> > This patch is based just on code review, I don't have an option to
> > function test this. But I see that we now exit with -EINVAL before the
> > memcpy that causes the slab-out-of-bounds when using your reproducer,
> > so it should at least fix the bug.
>
> Hi Steffen,
>
> This patch fixes the issue for me.
>
> Thanks!
>
> Tested-by: Andrey Konovalov <andreyknvl@google.com>
Patch is now applied to the ipsec tree.
Thanks for reporting and testing!
^ permalink raw reply
* Re: [PATCH v3 net-next 01/11] net: stmmac: prepare dma op mode config for multiple queues
From: Joao Pinto @ 2017-05-08 11:40 UTC (permalink / raw)
To: Andy Shevchenko, Joao Pinto
Cc: Jan Kiszka, David S. Miller, Giuseppe CAVALLARO, Alexandre TORGUE,
netdev, Linux Kernel Mailing List
In-Reply-To: <CAHp75Vea1jke4yp0=762B0XvFkcP+YrW=KA7C-v6w61_s4EzUA@mail.gmail.com>
Às 12:34 PM de 5/8/2017, Andy Shevchenko escreveu:
> On Mon, May 8, 2017 at 1:42 PM, Joao Pinto <Joao.Pinto@synopsys.com> wrote:
>> Às 11:12 AM de 5/8/2017, Andy Shevchenko escreveu:
>>> On Mon, May 8, 2017 at 12:54 PM, Joao Pinto <Joao.Pinto@synopsys.com> wrote:
>>>> Às 10:36 AM de 5/8/2017, Andy Shevchenko escreveu:
>
>>>>> JFYI: With today's linux-next when _kexec:ed_ kernel boots I tried and
>>>>> got the following:
>
>>>> Are you using the same version of Ethernet IP, 10/100?
>>>
>>> I'm running on Intel Galileo Gen2 board (v4.11 by the way works fine
>>> with direct boot from SD card)
>>>
>>>> Could you please verify if the crash you are experiencing is this place?
>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__git.kernel.org_pub_scm_linux_kernel_git_torvalds_linux.git_tree_drivers_net_ethernet_stmicro_stmmac_stmmac-5Fmain.c-23n2956&d=DwIFaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=s2fO0hii0OGNOv9qQy_HRXy-xAJUD1NNoEcc3io_kx0&m=UF269QZ9ExFRw1XXpgdvO2QeTCLEp-GquRe8OqZwRf0&s=yZu3uME5PK-3nJlxz-H-HfHh3Shjzg0je5If_jSXVb4&e=
>>>>
>>>> I would say that for rather old IPs, the napi is not capable of giving a valid
>>>> queue number. Could you please print the queue index returned by this line?
>>>>
>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__git.kernel.org_pub_scm_linux_kernel_git_torvalds_linux.git_tree_drivers_net_ethernet_stmicro_stmmac_stmmac-5Fmain.c-23n2948&d=DwIFaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=s2fO0hii0OGNOv9qQy_HRXy-xAJUD1NNoEcc3io_kx0&m=UF269QZ9ExFRw1XXpgdvO2QeTCLEp-GquRe8OqZwRf0&s=p_TgHODJum23I2N4AldR4oIaOPffSDpk9agmbRMQgoM&e=
>>>
>>> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
>>> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
>>> @@ -2953,7 +2953,9 @@ static netdev_tx_t stmmac_xmit(struct sk_buff
>>> *skb, struct net_device *dev)
>>> unsigned int enh_desc;
>>> unsigned int des;
>>>
>>> + pr_info("%s <<< 1: priv %p, queue: %u\n", __func__, priv, queue);
>>> tx_q = &priv->tx_queue[queue];
>>> + pr_info("%s <<< 2: priv %p, queue: %u tx_q: %p\n", __func__,
>>> priv, queue, tx_q);
>>>
>>>
>>> [ 101.591040] stmmac_xmit <<< 1: priv cdd1c4c0, queue: 7
>>> [ 101.596377] stmmac_xmit <<< 2: priv cdd1c4c0, queue: 7 tx_q: cdd1caac
>
>> I assume that the queue index is always 7 right? By return 7, the napi interface
>> 'thinks' that your setup is using 8 TX queues which I assume it is not and thats
>> the problem causing your board to malfuntion.
>>
>> Could you please check the values of the 'real' tx and rx queues count in this line?
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__git.kernel.org_pub_scm_linux_kernel_git_torvalds_linux.git_tree_drivers_net_ethernet_stmicro_stmmac_stmmac-5Fmain.c-23n4107&d=DwIFaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=s2fO0hii0OGNOv9qQy_HRXy-xAJUD1NNoEcc3io_kx0&m=6PN46fgWi1XTHkxFzV9wkYHPkKJWvkRC1OOlEhyKdcA&s=cyYmWeYuPwacYmVRzJbhRm3Krz6XNyHbxq8t7ZUi8Ec&e=
>>
>> For default they are =1, so napi should be assuming 1RX and 1TX, and so you
>> should be getting queue index =0 in reception and transmission.
>>
>> In terms of reception, could you print the queue index that stmmac_poll is using
>> here:
>>
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__git.kernel.org_pub_scm_linux_kernel_git_torvalds_linux.git_tree_drivers_net_ethernet_stmicro_stmmac_stmmac-5Fmain.c-23n3468&d=DwIFaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=s2fO0hii0OGNOv9qQy_HRXy-xAJUD1NNoEcc3io_kx0&m=6PN46fgWi1XTHkxFzV9wkYHPkKJWvkRC1OOlEhyKdcA&s=Xli0e7Key3FA7Rve_opcwc6W7nd4khVX15wwoNpFHL4&e=
>
> + pr_info("%s <<< %u\n", __func__, rx_q->queue_index);
> work_done = stmmac_rx(priv, budget, rx_q->queue_index);
> if (work_done < budget) {
> napi_complete_done(napi, work_done);
>
> /* Configure real RX and TX queues */
> netif_set_real_num_rx_queues(ndev, priv->plat->rx_queues_to_use);
> netif_set_real_num_tx_queues(ndev, priv->plat->tx_queues_to_use);
> + pr_info("%s <<< %hhu %hhu\n", __func__,
> priv->plat->rx_queues_to_use, priv->plat->tx_queues_to_use);
>
>
> [ 44.374161] stmmac_dvr_probe <<< 0 0
>
Ok, so this is the cause of the problem. The driver is geting 0 for real RX and
TX queues.
Your setup uses standard DT parsing from stmmac_platform or a custom one?
If you are using stmmac_probe_config_dt():
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c#n363
You will find a function named stmmac_mtl_setup() being called:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c#n492
In this function, the number of RX and TX queues is being set to 1 by default.
Joao
> [ 109.014763] stmmac_xmit <<< 1: priv cdcea4c0, queue: 2
> [ 109.020099] stmmac_xmit <<< 2: priv cdcea4c0, queue: 2 tx_q: cdcea9e4
>
> That's all, no poll activated.
>
^ permalink raw reply
* Re: [PATCH v3 net-next 01/11] net: stmmac: prepare dma op mode config for multiple queues
From: Andy Shevchenko @ 2017-05-08 11:34 UTC (permalink / raw)
To: Joao Pinto
Cc: Jan Kiszka, David S. Miller, Giuseppe CAVALLARO, Alexandre TORGUE,
netdev, Linux Kernel Mailing List
In-Reply-To: <967da95a-cc4e-a0ac-c702-e659bd4f0481@synopsys.com>
On Mon, May 8, 2017 at 1:42 PM, Joao Pinto <Joao.Pinto@synopsys.com> wrote:
> Às 11:12 AM de 5/8/2017, Andy Shevchenko escreveu:
>> On Mon, May 8, 2017 at 12:54 PM, Joao Pinto <Joao.Pinto@synopsys.com> wrote:
>>> Às 10:36 AM de 5/8/2017, Andy Shevchenko escreveu:
>>>> JFYI: With today's linux-next when _kexec:ed_ kernel boots I tried and
>>>> got the following:
>>> Are you using the same version of Ethernet IP, 10/100?
>>
>> I'm running on Intel Galileo Gen2 board (v4.11 by the way works fine
>> with direct boot from SD card)
>>
>>> Could you please verify if the crash you are experiencing is this place?
>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__git.kernel.org_pub_scm_linux_kernel_git_torvalds_linux.git_tree_drivers_net_ethernet_stmicro_stmmac_stmmac-5Fmain.c-23n2956&d=DwIFaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=s2fO0hii0OGNOv9qQy_HRXy-xAJUD1NNoEcc3io_kx0&m=UF269QZ9ExFRw1XXpgdvO2QeTCLEp-GquRe8OqZwRf0&s=yZu3uME5PK-3nJlxz-H-HfHh3Shjzg0je5If_jSXVb4&e=
>>>
>>> I would say that for rather old IPs, the napi is not capable of giving a valid
>>> queue number. Could you please print the queue index returned by this line?
>>>
>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__git.kernel.org_pub_scm_linux_kernel_git_torvalds_linux.git_tree_drivers_net_ethernet_stmicro_stmmac_stmmac-5Fmain.c-23n2948&d=DwIFaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=s2fO0hii0OGNOv9qQy_HRXy-xAJUD1NNoEcc3io_kx0&m=UF269QZ9ExFRw1XXpgdvO2QeTCLEp-GquRe8OqZwRf0&s=p_TgHODJum23I2N4AldR4oIaOPffSDpk9agmbRMQgoM&e=
>>
>> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
>> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
>> @@ -2953,7 +2953,9 @@ static netdev_tx_t stmmac_xmit(struct sk_buff
>> *skb, struct net_device *dev)
>> unsigned int enh_desc;
>> unsigned int des;
>>
>> + pr_info("%s <<< 1: priv %p, queue: %u\n", __func__, priv, queue);
>> tx_q = &priv->tx_queue[queue];
>> + pr_info("%s <<< 2: priv %p, queue: %u tx_q: %p\n", __func__,
>> priv, queue, tx_q);
>>
>>
>> [ 101.591040] stmmac_xmit <<< 1: priv cdd1c4c0, queue: 7
>> [ 101.596377] stmmac_xmit <<< 2: priv cdd1c4c0, queue: 7 tx_q: cdd1caac
> I assume that the queue index is always 7 right? By return 7, the napi interface
> 'thinks' that your setup is using 8 TX queues which I assume it is not and thats
> the problem causing your board to malfuntion.
>
> Could you please check the values of the 'real' tx and rx queues count in this line?
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c#n4107
>
> For default they are =1, so napi should be assuming 1RX and 1TX, and so you
> should be getting queue index =0 in reception and transmission.
>
> In terms of reception, could you print the queue index that stmmac_poll is using
> here:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c#n3468
+ pr_info("%s <<< %u\n", __func__, rx_q->queue_index);
work_done = stmmac_rx(priv, budget, rx_q->queue_index);
if (work_done < budget) {
napi_complete_done(napi, work_done);
/* Configure real RX and TX queues */
netif_set_real_num_rx_queues(ndev, priv->plat->rx_queues_to_use);
netif_set_real_num_tx_queues(ndev, priv->plat->tx_queues_to_use);
+ pr_info("%s <<< %hhu %hhu\n", __func__,
priv->plat->rx_queues_to_use, priv->plat->tx_queues_to_use);
[ 44.374161] stmmac_dvr_probe <<< 0 0
[ 109.014763] stmmac_xmit <<< 1: priv cdcea4c0, queue: 2
[ 109.020099] stmmac_xmit <<< 2: priv cdcea4c0, queue: 2 tx_q: cdcea9e4
That's all, no poll activated.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH/RFC net-next v2 4/4] net/sched: cls_flower: allow control of tree traversal on packet parse errors
From: Jamal Hadi Salim @ 2017-05-08 11:32 UTC (permalink / raw)
To: Simon Horman, Jiri Pirko, Cong Wang
Cc: Dinan Gunawardena, netdev, oss-drivers, Benjamin LaHaise
In-Reply-To: <1493988426-22854-5-git-send-email-simon.horman@netronome.com>
On 17-05-05 08:47 AM, Simon Horman wrote:
> Allow control how the tree of qdisc, classes and filters is further
> traversed if an error is encountered when parsing the packet in order to
> match the cls_flower filters at a particular prio.
>
> By default continue to the next filter, the behaviour without this patch.
>
> A use-case for this is to allow configuration of dropping of packets with
> truncated headers.
>
> For example, the following drops IPv4 packets that cannot be parsed by the
> flow dissector up to the end of the UDP ports - e.g. because they are
> truncated, and instantiates a continue action based on the port for packets
> that can be parsed.
>
> # tc qdisc del dev eth0 ingress; tc qdisc add dev eth0 ingress
> # tc filter add dev eth0 protocol ip parent ffff: flower \
> indev eth0 ip_proto udp dst_port 80 truncated drop action continue
>
> Signed-off-by: Simon Horman <simon.horman@netronome.com>
> Reviewed-by: Benjamin LaHaise <benjamin.lahaise@netronome.com>
I agree with Cong on this. The default should be "didnt match" (which
is accomplished by returning -1). The user could enter an explicit
rule to override this behavior. i.e something like:
tc filter add dev eth0 protocol ip parent ffff: flower \
indev eth0 ip_proto udp dst_port 80 truncated action continue
cheers,
jamal
^ permalink raw reply
* [PATCH] net/fsl: remove func xgmac_wait_until_free() as duplicate
From: Alexandru Ardelean @ 2017-05-08 11:31 UTC (permalink / raw)
To: netdev; +Cc: Shaohui.Xie, davem, Alexandru Ardelean
Looking at xgmac_wait_until_done() and xgmac_wait_until_free()
functions, they seem to have turned out completely identical.
Though, judging from the git history it seems they
initially weren't.
Remove xgmac_wait_until_free() in favor of xgmac_wait_until_done().
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
---
drivers/net/ethernet/freescale/xgmac_mdio.c | 33 ++++-------------------------
1 file changed, 4 insertions(+), 29 deletions(-)
diff --git a/drivers/net/ethernet/freescale/xgmac_mdio.c b/drivers/net/ethernet/freescale/xgmac_mdio.c
index e03b30c..54597a8 100644
--- a/drivers/net/ethernet/freescale/xgmac_mdio.c
+++ b/drivers/net/ethernet/freescale/xgmac_mdio.c
@@ -71,31 +71,6 @@ static void xgmac_write32(u32 value,
}
/*
- * Wait until the MDIO bus is free
- */
-static int xgmac_wait_until_free(struct device *dev,
- struct tgec_mdio_controller __iomem *regs,
- bool is_little_endian)
-{
- unsigned int timeout;
-
- /* Wait till the bus is free */
- timeout = TIMEOUT;
- while ((xgmac_read32(®s->mdio_stat, is_little_endian) &
- MDIO_STAT_BSY) && timeout) {
- cpu_relax();
- timeout--;
- }
-
- if (!timeout) {
- dev_err(dev, "timeout waiting for bus to be free\n");
- return -ETIMEDOUT;
- }
-
- return 0;
-}
-
-/*
* Wait till the MDIO read or write operation is complete
*/
static int xgmac_wait_until_done(struct device *dev,
@@ -147,7 +122,7 @@ static int xgmac_mdio_write(struct mii_bus *bus, int phy_id, int regnum, u16 val
xgmac_write32(mdio_stat, ®s->mdio_stat, endian);
- ret = xgmac_wait_until_free(&bus->dev, regs, endian);
+ ret = xgmac_wait_until_done(&bus->dev, regs, endian);
if (ret)
return ret;
@@ -159,7 +134,7 @@ static int xgmac_mdio_write(struct mii_bus *bus, int phy_id, int regnum, u16 val
if (regnum & MII_ADDR_C45) {
xgmac_write32(regnum & 0xffff, ®s->mdio_addr, endian);
- ret = xgmac_wait_until_free(&bus->dev, regs, endian);
+ ret = xgmac_wait_until_done(&bus->dev, regs, endian);
if (ret)
return ret;
}
@@ -201,7 +176,7 @@ static int xgmac_mdio_read(struct mii_bus *bus, int phy_id, int regnum)
xgmac_write32(mdio_stat, ®s->mdio_stat, endian);
- ret = xgmac_wait_until_free(&bus->dev, regs, endian);
+ ret = xgmac_wait_until_done(&bus->dev, regs, endian);
if (ret)
return ret;
@@ -213,7 +188,7 @@ static int xgmac_mdio_read(struct mii_bus *bus, int phy_id, int regnum)
if (regnum & MII_ADDR_C45) {
xgmac_write32(regnum & 0xffff, ®s->mdio_addr, endian);
- ret = xgmac_wait_until_free(&bus->dev, regs, endian);
+ ret = xgmac_wait_until_done(&bus->dev, regs, endian);
if (ret)
return ret;
}
--
2.7.4
^ permalink raw reply related
* Re: [PATCH/RFC net-next v2 3/4] net/sched: cls_flower: do not match if dissection fails
From: Jamal Hadi Salim @ 2017-05-08 11:26 UTC (permalink / raw)
To: Simon Horman, Jiri Pirko, Cong Wang
Cc: Dinan Gunawardena, netdev, oss-drivers, Benjamin LaHaise
In-Reply-To: <1493988426-22854-4-git-send-email-simon.horman@netronome.com>
On 17-05-05 08:47 AM, Simon Horman wrote:
> If the flow skb_flow_dissect() returns an error it indicates that
> dissection was incomplete for some reason. Matching using the result of an
> incomplete dissection may cause unexpected results. For example:
>
> * A match on zero layer 4 ports will also match packets truncated at
> the end of the IP header; that is packets where ports are missing are
> treated the same way as packets with zero ports.
> * Likewise, a match on zero ICMP code or type will also match packets
> truncated at the end of the IP header; that is packets where the ICMP
> type and code are missing will be treated the same way as packets with
> zero ICMP code and type.
>
> Separate patches to the flow dissector are required in order for it to
> return errors in the above cases.
>
> Fixes: 77b9900ef53a ("tc: introduce Flower classifier")
> Signed-off-by: Simon Horman <simon.horman@netronome.com>
> Reviewed-by: Benjamin LaHaise <benjamin.lahaise@netronome.com>
Acked-by: Jamal Hadi Salim <jhs@mojatatu.com>
cheers,
jamal
^ permalink raw reply
* Re: [PATCH/RFC net-next v2 2/4] flow dissector: return error on icmp dissection under-run
From: Jamal Hadi Salim @ 2017-05-08 11:21 UTC (permalink / raw)
To: Simon Horman, Jiri Pirko, Cong Wang
Cc: Dinan Gunawardena, netdev, oss-drivers, Benjamin LaHaise
In-Reply-To: <1493988426-22854-3-git-send-email-simon.horman@netronome.com>
On 17-05-05 08:47 AM, Simon Horman wrote:
> Return an error from __skb_flow_dissect() if insufficient packet data is
> present when dissecting icmp type and code.
>
> Without this patch the absence of the ICMP type and code in truncated
> ICMPv4 or IPVPv6 packets is treated the way same as the presence of a code
> and type of value of zero. And without this patch the flower classifier is
> unable to differentiate between these two cases which may lead to
> unexpected matching of truncated packets.
>
> With this patch the flow dissector and in turn the flower classifier can
> differentiate between packets with zero ICMP type and code, and truncated
> packets.
>
> The approach taken here is to return an error if the IP protocol indicates
> ICMP but the type and code data is not present in the packet - an error
> return value from __skb_header_pointer().
>
> This should only effect the flower classifier as it is the only user of
> W_DISSECTOR_KEY_ICMP. The behavioural update for flower only takes effect
> with a separate patch to have it refuse to match if dissection fails.
>
> Signed-off-by: Simon Horman <simon.horman@netronome.com>
> Reviewed-by: Benjamin LaHaise <benjamin.lahaise@netronome.com>
Reviewed-by: Jamal Hadi Salim <jhs@mojatatu.com>
cheers,
jamal
^ permalink raw reply
* Re: [PATCH/RFC net-next v2 1/4] flow dissector: return error on port dissection under-run
From: Jamal Hadi Salim @ 2017-05-08 11:21 UTC (permalink / raw)
To: Simon Horman, Jiri Pirko, Cong Wang
Cc: Dinan Gunawardena, netdev, oss-drivers, Benjamin LaHaise
In-Reply-To: <1493988426-22854-2-git-send-email-simon.horman@netronome.com>
On 17-05-05 08:47 AM, Simon Horman wrote:
> Return an error from __skb_flow_dissect() if insufficient packet data is
> present when dissecting layer 4 ports.
>
> Without this patch the absence of ports in truncated - e.g. UDP - packets
> is treated the same way by the flow dissector as the presence of ports with
> a value of zero. And without this patch the flower classifier is unable to
> differentiate between these two cases which may lead to unexpected matching
> of truncated packets.
>
> With this patch the flow dissector and in turn the flower classifier can
> differentiate between packets with zero L4 ports and truncated packets.
>
> The approach taken here is to only return an error if the offset of ports
> for the previously dissected IP protocol is known - a non error return from
> proto_ports_offset() - but port data is not present in the packet - an
> error return value from __skb_header_pointer().
>
> The behaviour for callers of __skb_flow_get_ports() is changed but the only
> callers are skb_flow_get_ports() and the flow dissector. The former has
> been updated so that its behaviour is unchanged. Behavioural change of the
> latter is the intended purpose of this patch but will only take effect with
> a separate patch to have it refuse to match if dissection fails.
>
> This change will lead to behavioural changes of the users of the dissector
> with FLOW_DISSECTOR_KEY_PORTS - flower, and users of
> flow_keys_dissector_keys[] and flow_keys_dissector_symmetric_keys[]. The
> behavioural change for *_keys[] changes seem reasonable as the change will
> should only be for truncated packets.
>
> Signed-off-by: Simon Horman <simon.horman@netronome.com>
> Reviewed-by: Benjamin LaHaise <benjamin.lahaise@netronome.com>
Reviewed-by: Jamal Hadi Salim <jhs@mojatatu.com>
cheers,
jamal
^ permalink raw reply
* [PATCH net] ip6_tunnel: remove unreachable ICMP_REDIRECT code
From: Hangbin Liu @ 2017-05-08 11:11 UTC (permalink / raw)
To: netdev; +Cc: Hangbin Liu
After call ip6_tnl_err(), the rel_type will be ether ICMPV6_DEST_UNREACH
or ICMPV6_PKT_TOOBIG. We will never reach ICMP_REDIRECT. So remove it.
Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
---
net/ipv6/ip6_tunnel.c | 5 -----
1 file changed, 5 deletions(-)
diff --git a/net/ipv6/ip6_tunnel.c b/net/ipv6/ip6_tunnel.c
index 6eb2ae5..16f8d42 100644
--- a/net/ipv6/ip6_tunnel.c
+++ b/net/ipv6/ip6_tunnel.c
@@ -591,9 +591,6 @@ ip4ip6_err(struct sk_buff *skb, struct inet6_skb_parm *opt,
rel_type = ICMP_DEST_UNREACH;
rel_code = ICMP_FRAG_NEEDED;
break;
- case NDISC_REDIRECT:
- rel_type = ICMP_REDIRECT;
- rel_code = ICMP_REDIR_HOST;
default:
return 0;
}
@@ -652,8 +649,6 @@ ip4ip6_err(struct sk_buff *skb, struct inet6_skb_parm *opt,
skb_dst(skb2)->ops->update_pmtu(skb_dst(skb2), NULL, skb2, rel_info);
}
- if (rel_type == ICMP_REDIRECT)
- skb_dst(skb2)->ops->redirect(skb_dst(skb2), NULL, skb2);
icmp_send(skb2, rel_type, rel_code, htonl(rel_info));
--
2.5.5
^ permalink raw reply related
* Re: bpf pointer alignment validation
From: Daniel Borkmann @ 2017-05-08 10:49 UTC (permalink / raw)
To: David Miller, ast; +Cc: netdev
In-Reply-To: <20170505.224709.1156323937148435706.davem@davemloft.net>
On 05/06/2017 04:47 AM, David Miller wrote:
> From: David Miller <davem@davemloft.net>
> Date: Fri, 05 May 2017 16:20:44 -0400 (EDT)
>
>> Anyways, I'll play with this design and see what happens...
>> Feedback is of course welcome.
>
> Here is a prototype that works for me with test_pkt_access.c,
> which otherwise won't load on sparc.
Code looks good to me as far as I can tell, thanks for working
on this.
Could you also add test cases specifically to this for test_verifier
in bpf selftests? I'm thinking of the cases when we have no pkt id
and offset originated from reg->off (accumulated through const imm
ops on reg) and insn->off, where we had i) no pkt id and ii) a
specific pkt id (so we can probe for aux_off_align rejection as well).
I believe we do have coverage to some extend in some of the tests
(more on the map_value_adj though), but it would be good to keep
tracking this specifically as well.
Thanks a lot,
Daniel
^ permalink raw reply
* Re: [PATCH v3 net-next 01/11] net: stmmac: prepare dma op mode config for multiple queues
From: Joao Pinto @ 2017-05-08 10:42 UTC (permalink / raw)
To: Andy Shevchenko, Joao Pinto
Cc: Jan Kiszka, David S. Miller, Giuseppe CAVALLARO, Alexandre TORGUE,
netdev, Linux Kernel Mailing List
In-Reply-To: <CAHp75VcO13o0BgZ75Ssxav2jwP_g+WXLjob8x5QTB6Mdoynpzg@mail.gmail.com>
Às 11:12 AM de 5/8/2017, Andy Shevchenko escreveu:
> On Mon, May 8, 2017 at 12:54 PM, Joao Pinto <Joao.Pinto@synopsys.com> wrote:
>> Hi Andy and Jan,
>>
>> Às 10:36 AM de 5/8/2017, Andy Shevchenko escreveu:
>>> On Mon, May 8, 2017 at 9:56 AM, Jan Kiszka <jan.kiszka@siemens.com> wrote:
>>>> On 2017-03-15 12:04, Joao Pinto wrote:
>>>>> This patch prepares DMA Operation Mode configuration for multiple queues.
>>>>> The work consisted on breaking the DMA operation Mode configuration function
>>>>> into RX and TX scope and adapting its mechanism in stmmac_main.
>>>
>>>> Starting with this patch, the stmmac-based network adapters of the Intel
>>>> Quark SoC stop working. I'm getting an IP via DHCP, I can ping, but TCP
>>>> connections can no longer be established.
>
>>> JFYI: With today's linux-next when _kexec:ed_ kernel boots I tried and
>>> got the following:
>>>
snip (...)
>>>
>>>
>>
>> Are you using the same version of Ethernet IP, 10/100?
>
> I'm running on Intel Galileo Gen2 board (v4.11 by the way works fine
> with direct boot from SD card)
>
>> Could you please verify if the crash you are experiencing is this place?
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__git.kernel.org_pub_scm_linux_kernel_git_torvalds_linux.git_tree_drivers_net_ethernet_stmicro_stmmac_stmmac-5Fmain.c-23n2956&d=DwIFaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=s2fO0hii0OGNOv9qQy_HRXy-xAJUD1NNoEcc3io_kx0&m=UF269QZ9ExFRw1XXpgdvO2QeTCLEp-GquRe8OqZwRf0&s=yZu3uME5PK-3nJlxz-H-HfHh3Shjzg0je5If_jSXVb4&e=
>>
>> I would say that for rather old IPs, the napi is not capable of giving a valid
>> queue number. Could you please print the queue index returned by this line?
>>
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__git.kernel.org_pub_scm_linux_kernel_git_torvalds_linux.git_tree_drivers_net_ethernet_stmicro_stmmac_stmmac-5Fmain.c-23n2948&d=DwIFaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=s2fO0hii0OGNOv9qQy_HRXy-xAJUD1NNoEcc3io_kx0&m=UF269QZ9ExFRw1XXpgdvO2QeTCLEp-GquRe8OqZwRf0&s=p_TgHODJum23I2N4AldR4oIaOPffSDpk9agmbRMQgoM&e=
>
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> @@ -2953,7 +2953,9 @@ static netdev_tx_t stmmac_xmit(struct sk_buff
> *skb, struct net_device *dev)
> unsigned int enh_desc;
> unsigned int des;
>
> + pr_info("%s <<< 1: priv %p, queue: %u\n", __func__, priv, queue);
> tx_q = &priv->tx_queue[queue];
> + pr_info("%s <<< 2: priv %p, queue: %u tx_q: %p\n", __func__,
> priv, queue, tx_q);
>
>
> [ 101.591040] stmmac_xmit <<< 1: priv cdd1c4c0, queue: 7
> [ 101.596377] stmmac_xmit <<< 2: priv cdd1c4c0, queue: 7 tx_q: cdd1caac
>
I assume that the queue index is always 7 right? By return 7, the napi interface
'thinks' that your setup is using 8 TX queues which I assume it is not and thats
the problem causing your board to malfuntion.
Could you please check the values of the 'real' tx and rx queues count in this line?
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c#n4107
For default they are =1, so napi should be assuming 1RX and 1TX, and so you
should be getting queue index =0 in reception and transmission.
In terms of reception, could you print the queue index that stmmac_poll is using
here:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c#n3468
>
> Also noticed warning that have to be addressed:
>
> drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:2504:49: warning:
> incorrect type in argument 1 (different address spaces)
> drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:2504:49: expected
> void [noderef] <asn:2>*ioaddr
> drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:2504:49: got
> struct mac_device_info *hw
This one was well caught! Although it has no influence in your setup, since you
don't have this callback implemented, eQOS (>= 4.00) and 1000 cores will have
issues if using PCS. I can make a patch for this one.
>
> drivers/net/ethernet/stmicro/stmmac/stmmac_main.c: In function
> ‘init_dma_rx_desc_rings’:
> drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:1274:15: warning:
> comparison of
> unsigned expression >= 0 is always true [-Wtype-limits]
> while (queue >= 0) {
> ^~
This one I have in my agenda to improve it, I also talked about it with Dan
Carpenter about it.
^ permalink raw reply
* Re: [PATCH v3 net-next 01/11] net: stmmac: prepare dma op mode config for multiple queues
From: Andy Shevchenko @ 2017-05-08 10:12 UTC (permalink / raw)
To: Joao Pinto
Cc: Jan Kiszka, David S. Miller, Giuseppe CAVALLARO, Alexandre TORGUE,
netdev, Linux Kernel Mailing List
In-Reply-To: <96c988c8-2d4a-33df-0d20-cc8adac3b01c@synopsys.com>
On Mon, May 8, 2017 at 12:54 PM, Joao Pinto <Joao.Pinto@synopsys.com> wrote:
> Hi Andy and Jan,
>
> Às 10:36 AM de 5/8/2017, Andy Shevchenko escreveu:
>> On Mon, May 8, 2017 at 9:56 AM, Jan Kiszka <jan.kiszka@siemens.com> wrote:
>>> On 2017-03-15 12:04, Joao Pinto wrote:
>>>> This patch prepares DMA Operation Mode configuration for multiple queues.
>>>> The work consisted on breaking the DMA operation Mode configuration function
>>>> into RX and TX scope and adapting its mechanism in stmmac_main.
>>
>>> Starting with this patch, the stmmac-based network adapters of the Intel
>>> Quark SoC stop working. I'm getting an IP via DHCP, I can ping, but TCP
>>> connections can no longer be established.
>> JFYI: With today's linux-next when _kexec:ed_ kernel boots I tried and
>> got the following:
>>
>>
>> # ip a s
>> 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue qlen 1000
>> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
>> inet 127.0.0.1/8 scope host lo
>> valid_lft forever preferred_lft forever
>> inet6 ::1/128 scope host
>> valid_lft forever preferre[ 130.403995] random: fast init done
>> d_lft forever
>> 2: eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop qlen 1000
>> link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
>> 3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop qlen 1000
>> link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
>> 4: sit0@NONE: <NOARP> mtu 1480 qdisc noop qlen 1000
>> link/sit 0.0.0.0 brd 0.0.0.0
>> # udhcpc -i eth0
>> udhcpc: started, v1.26.2
>> [ 140.825131] stmmaceth 0000:00:14.6 eth0: device MAC address 98:4f:ee:05:ac:47
>> [ 140.834304] Generic PHY stmmac-a6:01: attached PHY driver [Generic
>> PHY] (mii_bus:phy_addr=stmmac-a6:01, irq=-1)
>> [ 140.930871] stmmaceth 0000:00:14.6 eth0: IEEE 1588-2008 Advanced
>> Timestamp supported
>> [ 140.941109] stmmaceth 0000:00:14.6 eth0: registered PTP clock
>> [ 140.953626] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
>> udhcpc: sending discover
>> [ 142.979557] stmmaceth 0000:00:14.6 eth0: Link is Up - 100Mbps/Full
>> - flow control off
>> [ 142.988756] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
>> [ 142.998810] BUG: unable to handle kernel NULL pointer dereference at (null)
>> [ 143.006193] IP: stmmac_xmit+0xf1/0x1080
>> [ 143.010168] *pde = 00000000
>> [ 143.010177]
>> [ 143.014762] Oops: 0002 [#1]
>> [ 143.017672] Modules linked in: at24 nvmem_core pwm_pca9685
>> [ 143.023338] CPU: 0 PID: 0 Comm: swapper Not tainted 4.11.0-next-20170508+ #2
>> [ 143.030539] task: c8533580 task.stack: c852c000
>> [ 143.035237] EIP: stmmac_xmit+0xf1/0x1080
>> [ 143.039302] EFLAGS: 00010216 CPU: 0
>> [ 143.042915] EAX: 00000000 EBX: 00000050 ECX: 00000000 EDX: ceb6a0c0
>> [ 143.049326] ESI: 00000000 EDI: cdd16000 EBP: cdc25d70 ESP: cdc25d20
>> [ 143.055735] DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068
>> [ 143.061271] CR0: 80050033 CR2: 00000000 CR3: 0eb5c000 CR4: 00100010
>> [ 143.067671] Call Trace:
>> [ 143.070238] <SOFTIRQ>
>> [ 143.072763] dev_hard_start_xmit+0x7c/0x1a0
>> [ 143.077120] sch_direct_xmit+0xf0/0x120
>> [ 143.081130] __dev_queue_xmit+0x181/0x430
>> [ 143.085311] ? eth_commit_mac_addr_change+0x20/0x20
>> [ 143.090362] dev_queue_xmit+0xa/0x10
>> [ 143.094100] neigh_resolve_output+0xdb/0x190
>> [ 143.098561] ip6_finish_output2+0x184/0x500
>> [ 143.102945] ip6_finish_output+0x91/0xe0
>> [ 143.107057] ? ip6_finish_output+0x91/0xe0
>> [ 143.111338] ip6_output+0x36/0x110
>> [ 143.114924] ? ip6_fragment+0xb00/0xb00
>> [ 143.118935] mld_sendpack+0x191/0x2b0
>> [ 143.122769] ? mld_newpack+0xda/0x180
>> [ 143.126598] ? ipv6_icmp_sysctl_init+0x30/0x30
>> [ 143.131224] mld_ifc_timer_expire+0x158/0x240
>> [ 143.135756] ? find_next_bit+0xa/0x10
>> [ 143.139584] ? mld_dad_timer_expire+0x50/0x50
>> [ 143.144112] call_timer_fn+0x2a/0xf0
>> [ 143.147862] ? mld_dad_timer_expire+0x50/0x50
>> [ 143.152395] run_timer_softirq+0x158/0x300
>> [ 143.156668] ? file_free_rcu+0x1e/0x30
>> [ 143.160589] __do_softirq+0xc4/0x200
>> [ 143.164341] ? __hrtimer_tasklet_trampoline+0x30/0x30
>> [ 143.169575] do_softirq_own_stack+0x1e/0x30
>> [ 143.173902] </SOFTIRQ>
>> [ 143.176502] irq_exit+0x95/0xa0
>> [ 143.179812] smp_apic_timer_interrupt+0x31/0x40
>> [ 143.184530] apic_timer_interrupt+0x32/0x40
>> [ 143.188889] EIP: default_idle+0xc/0x70
>> [ 143.192774] EFLAGS: 00000246 CPU: 0
>> [ 143.196386] EAX: 00000000 EBX: 00000000 ECX: 00000001 EDX: 00000000
>> [ 143.202795] ESI: 00000000 EDI: c8533580 EBP: c852df54 ESP: c852df4c
>> [ 143.209205] DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068
>> [ 143.214780] arch_cpu_idle+0x9/0x10
>> [ 143.218446] default_idle_call+0x17/0x30
>> [ 143.222551] do_idle+0xed/0x130
>> [ 143.225873] cpu_startup_entry+0x15/0x20
>> [ 143.229965] rest_init+0x5c/0x60
>> [ 143.233370] start_kernel+0x313/0x318
>> [ 143.237221] i386_start_kernel+0x98/0x9c
>> [ 143.241315] startup_32_smp+0x16b/0x16d
>> [ 143.245289] Code: 84 45 06 00 00 c1 e2 05 03 94 c7 9c 09 00 00 89
>> 55 b0 8b 45 c8 8b 75 bc 8b 55 d8 8d 1c 80 89
>> 75 e4 c1 e3 03 8b 84 1f a4 09 00 00 <89> 14 b0 8b 87 40 0d 00 00 8b 40
>> 24 85 c0 89 45 b8 0f 85 68 02
>> [ 143.264746] EIP: stmmac_xmit+0xf1/0x1080 SS:ESP: 0068:cdc25d20
>> [ 143.270727] CR2: 0000000000000000
>> [ 143.274175] ---[ end trace 79da8ef70f8b98d7 ]---
>> [ 143.278925] Kernel panic - not syncing: Fatal exception in interrupt
>> [ 143.285433] Kernel Offset: 0x6a00000 from 0xc1000000 (relocation
>> range: 0xc0000000-0xd05effff)
>> [ 143.294268] ---[ end Kernel panic - not syncing: Fatal exception in interrupt
>>
>>
>
> Are you using the same version of Ethernet IP, 10/100?
I'm running on Intel Galileo Gen2 board (v4.11 by the way works fine
with direct boot from SD card)
> Could you please verify if the crash you are experiencing is this place?
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c#n2956
>
> I would say that for rather old IPs, the napi is not capable of giving a valid
> queue number. Could you please print the queue index returned by this line?
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c#n2948
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -2953,7 +2953,9 @@ static netdev_tx_t stmmac_xmit(struct sk_buff
*skb, struct net_device *dev)
unsigned int enh_desc;
unsigned int des;
+ pr_info("%s <<< 1: priv %p, queue: %u\n", __func__, priv, queue);
tx_q = &priv->tx_queue[queue];
+ pr_info("%s <<< 2: priv %p, queue: %u tx_q: %p\n", __func__,
priv, queue, tx_q);
[ 101.591040] stmmac_xmit <<< 1: priv cdd1c4c0, queue: 7
[ 101.596377] stmmac_xmit <<< 2: priv cdd1c4c0, queue: 7 tx_q: cdd1caac
Also noticed warning that have to be addressed:
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:2504:49: warning:
incorrect type in argument 1 (different address spaces)
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:2504:49: expected
void [noderef] <asn:2>*ioaddr
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:2504:49: got
struct mac_device_info *hw
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c: In function
‘init_dma_rx_desc_rings’:
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:1274:15: warning:
comparison of
unsigned expression >= 0 is always true [-Wtype-limits]
while (queue >= 0) {
^~
--
With Best Regards,
Andy Shevchenko
^ 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