* RE: [PATCH net 3/4] lan78xx: Fix for eeprom read/write when device autosuspend
From: Nisar.Sayed @ 2017-09-06 17:34 UTC (permalink / raw)
To: andrew; +Cc: davem, UNGLinuxDriver, netdev
In-Reply-To: <20170906140605.GD11864@lunn.ch>
Thanks, will make separate patch.
> Hi Nisar
>
> > + else if ((ee->magic == LAN78XX_EEPROM_MAGIC) &&
> > + (ee->offset >= 0 && ee->offset < MAX_EEPROM_SIZE) &&
> > + (ee->len > 0 && (ee->offset + ee->len) <=
> MAX_EEPROM_SIZE))
> > + ret = lan78xx_write_raw_eeprom(dev, ee->offset, ee->len,
> data);
>
> This change does not appear to have anything to do with auto suspend.
> Please make it a separate patch.
>
> Andrew
^ permalink raw reply
* RE: [PATCH net 2/4] lan78xx: Add fixed_phy device support for LAN7801 device
From: Nisar.Sayed @ 2017-09-06 17:34 UTC (permalink / raw)
To: andrew; +Cc: davem, UNGLinuxDriver, netdev
In-Reply-To: <20170906140233.GC11864@lunn.ch>
Thanks Andrew, will try to change as suggested.
> On Wed, Sep 06, 2017 at 10:51:44AM +0000, Nisar.Sayed@microchip.com
> wrote:
> > From: Nisar Sayed <Nisar.Sayed@microchip.com>
> >
> > Add fixed_phy device support for LAN7801 device
> >
> > When LAN7801 device connected to PHY Device which does not have
> > MDIO/MDC access, fixex_phy device will be added.
>
> Please try to find a way to do this without all the #ifdefs. They can be
> acceptable in header files, but should be avoided in .c files.
>
> Andrew
^ permalink raw reply
* RE: [PATCH net 1/4] lan78xx: Fix for crash associated with System suspend
From: Nisar.Sayed @ 2017-09-06 17:34 UTC (permalink / raw)
To: andrew; +Cc: davem, UNGLinuxDriver, netdev
In-Reply-To: <20170906135908.GB11864@lunn.ch>
Thanks Andrew inputs.
> On Wed, Sep 06, 2017 at 10:51:31AM +0000, Nisar.Sayed@microchip.com
> wrote:
> > From: Nisar Sayed <Nisar.Sayed@microchip.com>
> >
> > Fix for crash associated with System suspend
> >
> > Since ndo_stop removes phydev which makes phydev NULL.
> > Whenever system suspend is initiated or after "ifconfig <interface>
> > down", if set_wol or get_wol is triggered phydev is NULL leads system
> crash.
> > Hence phy_start/phy_stop for ndo_start/ndo_stop fixes the issues
> > instead of adding/removing phydevice
>
> Looking at this patch, there apears to be lots of different things going on.
> Please can you split it up into multiple patches.
Sure will split it up.
>
> > Signed-off-by: Nisar Sayed <Nisar.Sayed@microchip.com>
> > ---
> > drivers/net/usb/lan78xx.c | 44
> > ++++++++++++++++++++++++++++----------------
> > 1 file changed, 28 insertions(+), 16 deletions(-)
> >
> > diff --git a/drivers/net/usb/lan78xx.c b/drivers/net/usb/lan78xx.c
> > index b99a7fb..955ab3b 100644
> > --- a/drivers/net/usb/lan78xx.c
> > +++ b/drivers/net/usb/lan78xx.c
> > @@ -2024,6 +2024,8 @@ static int lan78xx_phy_init(struct lan78xx_net
> *dev)
> > lan8835_fixup);
> > if (ret < 0) {
> > netdev_err(dev->net, "fail to register fixup\n");
> > + phy_unregister_fixup_for_uid(PHY_KSZ9031RNX,
> > + 0xfffffff0);
>
> goto error; would be better. phy_unregister_fixup_for_uid() does not care if
> you try to unregister something which has not been registered.
>
> Also, this should be a separate patch.
Ok, will make it as separate patch
>
> > return ret;
> > }
> > /* add more external PHY fixup here if needed */ @@ -
> 2031,8 +2033,7
> > @@ static int lan78xx_phy_init(struct lan78xx_net *dev)
> > phydev->is_internal = false;
> > } else {
> > netdev_err(dev->net, "unknown ID found\n");
> > - ret = -EIO;
> > - goto error;
> > + return -EIO;
> > }
> >
> > /* if phyirq is not set, use polling mode in phylib */ @@ -2051,7
> > +2052,10 @@ static int lan78xx_phy_init(struct lan78xx_net *dev)
> > if (ret) {
> > netdev_err(dev->net, "can't attach PHY to %s\n",
> > dev->mdiobus->id);
> > - return -EIO;
> > + ret = -EIO;
> > + if (dev->chipid == ID_REV_CHIP_ID_7801_)
> > + goto error;
> > + return ret;
>
> Why not add the if (dev->chipid == ID_REV_CHIP_ID_7801_) after the
> error: label?
>
>
Yes, will correct it
>
> > }
> >
> > /* MAC doesn't support 1000T Half */ @@ -2067,8 +2071,6 @@ static
> > int lan78xx_phy_init(struct lan78xx_net *dev)
> >
> > dev->fc_autoneg = phydev->autoneg;
> >
> > - phy_start(phydev);
> > -
> > netif_dbg(dev, ifup, dev->net, "phy initialised successfully");
> >
> > return 0;
> > @@ -2497,9 +2499,9 @@ static int lan78xx_open(struct net_device *net)
> > if (ret < 0)
> > goto done;
> >
> > - ret = lan78xx_phy_init(dev);
> > - if (ret < 0)
> > - goto done;
> > + if (dev->domain_data.phyirq > 0)
> > + phy_start_interrupts(dev->net->phydev);
>
> This is unusual. I don't see any other MAC driver starting interrupts.
> This needs explaining.
>
> Andrew
Since "lan78xx_open" calls "lan78xx_reset" (Device reset) it is required to start/enable interrupt back
Initially when "phydev->state = PHY_READY" state "phy_start" will not enable interrupts,
However after "lan78xx_stop" when "phy_stop" makes "phydev->state = PHY_HALTED"
Subsequent call to "phy_start" will enable interrupt.
Hence "phy_start_interrupts" used after "lan78xx_reset"
- Nisar
^ permalink raw reply
* Re: [Patch net] net_sched: fix a memory leak of filter chain
From: Cong Wang @ 2017-09-06 17:25 UTC (permalink / raw)
To: Jiri Pirko; +Cc: Linux Kernel Network Developers, Jakub Kicinski, Jiri Pirko
In-Reply-To: <20170906073839.GD2523@nanopsycho>
On Wed, Sep 6, 2017 at 12:38 AM, Jiri Pirko <jiri@resnulli.us> wrote:
> Wed, Sep 06, 2017 at 07:03:10AM CEST, xiyou.wangcong@gmail.com wrote:
>>tcf_chain_destroy() is called by tcf_block_put() and tcf_chain_put().
>>tcf_chain_put() is refcn'ed and paired with tcf_chain_get(),
>>but tcf_block_put() is not, it should be paired with tcf_block_get()
>>and we still need to decrease the refcnt. However, tcf_block_put()
>>is special, it stores the chains too, we have to detach them if
>>it is not the last user.
>
> You don't describe the original issue, or I am missing that from your
> description.
The original issue is the mismatch of tcf_block_put() and tcf_block_get()
w.r.t. refcnt. Think it in this way: if you call tcf_bock_put() immediately
after tcf_block_get(), would you get effectively a nop?
>
>
>>
>>What's more, index 0 is not special at all, it should be treated
>>like other chains. This also makes the code more readable.
>
> [...]
>
>
>>@@ -246,10 +246,7 @@ EXPORT_SYMBOL(tcf_chain_get);
>>
>> void tcf_chain_put(struct tcf_chain *chain)
>> {
>>- /* Destroy unused chain, with exception of chain 0, which is the
>>- * default one and has to be always present.
>>- */
>>- if (--chain->refcnt == 0 && !chain->filter_chain && chain->index != 0)
>>+ if (--chain->refcnt == 0)
>
> The refcounting is only done for actions holding reference to the chain.
> You still need to check is the filter chain is not empty.
> See tc_ctl_tfilter.
With my patch refcnt is done for block too, if you notice the
tcf_chain_put() in tcf_block_put().
>
> Also, chain 0 is created by default on a block creation. It has to be
> present always for a reason. Please see tcf_block_get. The pointer to
> chain 0 is assigned to the qdisc filter list pointer.
Sure, this is why block holds a refcnt to chain (not just chain 0) with
my patch, aka why the initial refcnt is 1 rather than 0.
^ permalink raw reply
* Re: [PATCH] DSA support for Micrel KSZ8895
From: Andrew Lunn @ 2017-09-06 17:09 UTC (permalink / raw)
To: Tristram.Ha
Cc: muvarov, pavel, Woojung.Huh, nathan.leigh.conrad, vivien.didelot,
f.fainelli, netdev, linux-kernel
In-Reply-To: <93AF473E2DA327428DE3D46B72B1E9FD41120E4D@CHN-SV-EXMX02.mchp-main.com>
> The patches are under review internally and will need to be updated
> and approved by Woojung before formal submission. Problem is
> although KSZ8795 and KSZ8895 drivers are new code and will be
> submitted as RFC, they depend on the change of KSZ9477 driver
> currently in the kernel, which require more rigorous review.
Please be aware that they will also go though review when you post
them. This can be anything from great, nice job, to throw them away
and start again. Since you are submitting RFCs we understand it is
early code, issues still to be solved, and we can make suggestions how
to solve those issues.
Post early, post often...
Andrew
^ permalink raw reply
* Re: [PATCH net-next] xdp: implement xdp_redirect_map for generic XDP
From: Daniel Borkmann @ 2017-09-06 17:02 UTC (permalink / raw)
To: Jesper Dangaard Brouer, netdev, David S. Miller
Cc: John Fastabend, Andy Gospodarek
In-Reply-To: <59B02127.5020904@iogearbox.net>
On 09/06/2017 06:24 PM, Daniel Borkmann wrote:
[...]
> Otherwise it looks good, but note that it also doesn't really
> resolve the issue you mention wrt stale map pointers by the
> way. This would need a different way to clear out the pointers
> from redirect_info, I'm thinking when we have devmap dismantle
> time after RCU grace period we should check whether there are
> still stale pointers from this map around and clear them under
> disabled preemption, but need to brainstorm a bit more on that
> first.
Scratch that approach, doesn't work. So thinking bit more on
this, what we could do here is the following: verifier knows
we called bpf_xdp_redirect_map() helper, so it could do a small
insn rewrite in the sense that it fills R4 with a pointer to
the bpf_prog. We have that at verification time anyway and R4
is allowed to be populated since we scratch it per convention.
Then, the helper would store the prog pointer in struct redirect_info.
Later in xdp_do_*_redirect() we check whether the redirect_info's
prog pointer is the same as passed xdp_prog pointer, and if
that's the case then all good, since the prog holds a ref on
the map anyway, if they are not equal in the unlikely case, it
means stale pointer, so we bail out right there. That would
work imo, will see to code it up and check it out.
^ permalink raw reply
* Re: [PATCH v2 rfc 0/8] IGMP snooping for local traffic
From: Andrew Lunn @ 2017-09-06 17:01 UTC (permalink / raw)
To: Vivien Didelot; +Cc: netdev, jiri, nikolay, Florian Fainelli
In-Reply-To: <874lsfg87t.fsf@weeman.i-did-not-set--mail-host-address--so-tickle-me>
On Wed, Sep 06, 2017 at 11:25:26AM -0400, Vivien Didelot wrote:
> Hi Andrew, Nikolay,
>
> Andrew Lunn <andrew@lunn.ch> writes:
>
> > Then starts the work passing down to the hardware that the host has
> > joined/left a group. The existing switchdev mdb object cannot be used,
> > since the semantics are different. The existing
> > SWITCHDEV_OBJ_ID_PORT_MDB is used to indicate a specific multicast
> > group should be forwarded out that port of the switch. However here we
> > require the exact opposite. We want multicast frames for the group
> > received on the port to the forwarded to the host. Hence add a new
> > object SWITCHDEV_OBJ_ID_HOST_MDB, a multicast database entry to
> > forward to the host. This new object is then propagated through the
> > DSA layers. No DSA driver changes should be needed, this should just
> > work...
>
> I'm not sure if you already explained that, if so, sorry in advance.
>
> I don't understand why SWITCHDEV_OBJ_ID_PORT_MDB cannot be used. Isn't
> setting the obj->orig_dev to the bridge device itself enough to
> distinguish br0 from a switch port?
Hi Vivien
I did consider this. But conceptually, it seems wrong.
SWITCHDEV_OBJ_ID_PORT_MDB has always been about egress. I don't like
adding a special case for ingress. Adding a new switchdev object
avoids this special case.
> static int dsa_slave_port_obj_add(struct net_device *dev,
> const struct switchdev_obj *obj,
> struct switchdev_trans *trans)
> {
> struct dsa_slave_priv *p = netdev_priv(dev);
> struct dsa_port *port = p->dp;
>
> /* Is the target port the bridge device itself? */
> if (obj->orig_dev == port->br)
> port = port->cpu_dp;
>
> return dsa_port_mdb_add(port, obj, trans);
> }
>
> The main problem is that we will soon want support for multiple CPU
> ports.
We keep saying that, but it never actually happens. We should solve
multiple CPU problems when we actually add support for multiple CPUs.
Probably at that point, we need to push SWITCHDEV_OBJ_ID_PORT_HOST_MDB
right down to a port, so that port can setup what needs setting up so
its frames goes to its CPU port.
> So adding the MDB entry to all CPU ports as you did in a patch 5/8 in
> dsa_switch_host_mdb_*() is not correct because you can have CPU port
> sw0p0 being a member of br0 and CPU port sw0p10 being a member of br1.
Be careful, you are making assumptions about mapping cpu ports to
bridges. That is not been defined yet.
Andrew
^ permalink raw reply
* [iproute PATCH] utils: Review strlcpy() and strlcat()
From: Phil Sutter @ 2017-09-06 16:51 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev
In-Reply-To: <063D6719AE5E284EB5DD2968C1650D6DD006EC26@AcuExch.aculab.com>
As David Laight correctly pointed out, the first version of strlcpy()
modified dst buffer behind the string copied into it. Fix this by
writing NUL to the byte immediately following src string instead of to
the last byte in dst. Doing so also allows to reduce overhead by using
memcpy().
Improve strlcat() by avoiding the call to strlcpy() if dst string is
already full, not just as sanity check.
Signed-off-by: Phil Sutter <phil@nwl.cc>
---
lib/utils.c | 12 ++++++++----
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/lib/utils.c b/lib/utils.c
index 330ab073c2068..bbd3cbc46a0e5 100644
--- a/lib/utils.c
+++ b/lib/utils.c
@@ -1233,18 +1233,22 @@ int get_real_family(int rtm_type, int rtm_family)
size_t strlcpy(char *dst, const char *src, size_t size)
{
+ size_t srclen = strlen(src);
+
if (size) {
- strncpy(dst, src, size - 1);
- dst[size - 1] = '\0';
+ size_t minlen = min(srclen, size - 1);
+
+ memcpy(dst, src, minlen);
+ dst[minlen] = '\0';
}
- return strlen(src);
+ return srclen;
}
size_t strlcat(char *dst, const char *src, size_t size)
{
size_t dlen = strlen(dst);
- if (dlen > size)
+ if (dlen >= size)
return dlen + strlen(src);
return dlen + strlcpy(dst + dlen, src, size - dlen);
--
2.13.1
^ permalink raw reply related
* Re: [PATCH net v2] rds: Fix incorrect statistics counting
From: Santosh Shilimkar @ 2017-09-06 16:48 UTC (permalink / raw)
To: Håkon Bugge, David S . Miller
Cc: netdev, linux-rdma, rds-devel, linux-kernel, knut.omang
In-Reply-To: <20170906163551.20387-1-Haakon.Bugge@oracle.com>
On 9/6/2017 9:35 AM, Håkon Bugge wrote:
> In rds_send_xmit() there is logic to batch the sends. However, if
> another thread has acquired the lock and has incremented the send_gen,
> it is considered a race and we yield. The code incrementing the
> s_send_lock_queue_raced statistics counter did not count this event
> correctly.
>
> This commit counts the race condition correctly.
>
> Changes from v1:
> - Removed check for *someone_on_xmit()*
> - Fixed incorrect indentation
>
> Signed-off-by: Håkon Bugge <haakon.bugge@oracle.com>
> Reviewed-by: Knut Omang <knut.omang@oracle.com>
> ---
Thanks for the update.
Acked-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
^ permalink raw reply
* RE: [PATCH] DSA support for Micrel KSZ8895
From: Tristram.Ha @ 2017-09-06 16:47 UTC (permalink / raw)
To: muvarov
Cc: pavel, Woojung.Huh, nathan.leigh.conrad, vivien.didelot,
f.fainelli, netdev, linux-kernel, andrew
In-Reply-To: <CAJGZr0+WueUjZJTLmcJRXtLtgUTUGnPCgiHQir=v5cRf3ido_g@mail.gmail.com>
> -----Original Message-----
> From: Maxim Uvarov [mailto:muvarov@gmail.com]
> Sent: Wednesday, September 06, 2017 2:15 AM
> To: Tristram Ha - C24268
> Cc: Pavel Machek; Woojung Huh - C21699; Nathan Conrad; Vivien Didelot;
> Florian Fainelli; netdev; linux-kernel@vger.kernel.org; Andrew Lunn
> Subject: Re: [PATCH] DSA support for Micrel KSZ8895
>
> 2017-08-31 0:32 GMT+03:00 <Tristram.Ha@microchip.com>:
> >> On Mon 2017-08-28 16:09:27, Andrew Lunn wrote:
> >> > > I may be confused here, but AFAICT:
> >> > >
> >> > > 1) Yes, it has standard layout when accessed over MDIO.
> >> >
> >> >
> >> > Section 4.8 of the datasheet says:
> >> >
> >> > All the registers defined in this section can be also accessed
> >> > via the SPI interface.
> >> >
> >> > Meaning all PHY registers can be access via the SPI interface. So
> >> > you should be able to make a standard Linux MDIO bus driver which
> >> > performs SPI reads.
> >>
> >> As far as I can tell (and their driver confirms) -- yes, all those
> >> registers can be accessed over the SPI, they are just shuffled
> >> around... hence MDIO emulation code. I copied it from their code (see
> >> the copyrights) so no, I don't believe there's nicer solution.
> >>
> >> Best regards,
> >>
> >>
> >> Pavel
> >
> > Can you hold on your developing work on KSZ8895 driver? I am afraid your
> effort may be in vain. We at Microchip are planning to release DSA drivers
> for all KSZ switches, starting at KSZ8795, then KSZ8895, and KSZ8863.
> >
> > The driver files all follow the structures of the current KSZ9477 DSA driver,
> and the file tag_ksz.c will be updated to handle the tail tag of different chips,
> which requires including the ksz_priv.h header. That is required
> nevertheless to support using the offload_fwd_mark indication.
> >
> > The KSZ8795 driver will be submitted after Labor Day (9/4) if testing reveals
> no problem. The KSZ8895 driver will be submitted right after that. You
> should have no problem using the driver right away.
> >
>
> Hello Tristram, is there any update for that driver?
>
> Maxim.
>
The patches are under review internally and will need to be updated and approved by Woojung before formal submission. Problem is although KSZ8795 and KSZ8895 drivers are new code and will be submitted as RFC, they depend on the change of KSZ9477 driver currently in the kernel, which require more rigorous review.
^ permalink raw reply
* Re: [PATCH v2 rfc 0/8] IGMP snooping for local traffic
From: Andrew Lunn @ 2017-09-06 16:42 UTC (permalink / raw)
To: Florian Fainelli
Cc: Roopa Prabhu, netdev, Vivien Didelot, Woojung.Huh, jbe, sean.wang,
john
In-Reply-To: <9ECEF4E4-A39B-4578-8BDC-7842D20F3C81@gmail.com>
> >On the switch asics we work with, the driver has information if the
> >packet was
> >forwarded in hardware. This is per packet reason code telling why the
> >CPU is seeing the packet.
> >The driver can use this information to reset skb->offload_fwd_mark to
> >allow software forward.
> I am not positive this is universally available across different
> switch vendors.
It is not universally available. We cannot rely on it being available
with switches supported by DSA.
We have a few choices:
1) We assume anything the switch forwards to the CPU has also been
sent out whatever ports of the switch it needs to. Set
offload_fwd_mark.
2) We assume anything the switch forwards to the CPU has not gone
anywhere else, and the bridge needs to send it out whatever ports
it thinks. Don't set offload_fwd_mark.
3) We define some rules about what packets the switch should handle,
and then do some deep packet inspection to decide if
offload_fwd_mark should be set or not.
I don't see 3) being possible. We are dealing with a fixed silicon
data path, not something which is fully programmable.
So it is down to 1) or 2). I've been assuming 1), but maybe we need to
discuss that as well.
Andrew
^ permalink raw reply
* [PATCH net v2] rds: Fix incorrect statistics counting
From: Håkon Bugge @ 2017-09-06 16:35 UTC (permalink / raw)
To: Santosh Shilimkar, David S . Miller
Cc: netdev, linux-rdma, rds-devel, linux-kernel, knut.omang
In rds_send_xmit() there is logic to batch the sends. However, if
another thread has acquired the lock and has incremented the send_gen,
it is considered a race and we yield. The code incrementing the
s_send_lock_queue_raced statistics counter did not count this event
correctly.
This commit counts the race condition correctly.
Changes from v1:
- Removed check for *someone_on_xmit()*
- Fixed incorrect indentation
Signed-off-by: Håkon Bugge <haakon.bugge@oracle.com>
Reviewed-by: Knut Omang <knut.omang@oracle.com>
---
net/rds/send.c | 10 +++++++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/net/rds/send.c b/net/rds/send.c
index 058a407..b52cdc8 100644
--- a/net/rds/send.c
+++ b/net/rds/send.c
@@ -428,14 +428,18 @@ int rds_send_xmit(struct rds_conn_path *cp)
* some work and we will skip our goto
*/
if (ret == 0) {
+ bool raced;
+
smp_mb();
+ raced = send_gen != READ_ONCE(cp->cp_send_gen);
+
if ((test_bit(0, &conn->c_map_queued) ||
- !list_empty(&cp->cp_send_queue)) &&
- send_gen == READ_ONCE(cp->cp_send_gen)) {
- rds_stats_inc(s_send_lock_queue_raced);
+ !list_empty(&cp->cp_send_queue)) && !raced) {
if (batch_count < send_batch_count)
goto restart;
queue_delayed_work(rds_wq, &cp->cp_send_w, 1);
+ } else if (raced) {
+ rds_stats_inc(s_send_lock_queue_raced);
}
}
out:
--
2.9.3
^ permalink raw reply related
* Re: [PATCH net-next 1/1] hv_netvsc: fix deadlock on hotplug
From: Stephen Hemminger @ 2017-09-06 16:36 UTC (permalink / raw)
To: Haiyang Zhang
Cc: devel@linuxdriverproject.org, Stephen Hemminger,
netdev@vger.kernel.org
In-Reply-To: <DM5PR21MB0475451095CC657BB54C4E50CA970@DM5PR21MB0475.namprd21.prod.outlook.com>
On Wed, 6 Sep 2017 16:23:45 +0000
Haiyang Zhang <haiyangz@microsoft.com> wrote:
> > -----Original Message-----
> > From: Stephen Hemminger [mailto:stephen@networkplumber.org]
> > Sent: Wednesday, September 6, 2017 11:19 AM
> > To: KY Srinivasan <kys@microsoft.com>; Haiyang Zhang
> > <haiyangz@microsoft.com>; Stephen Hemminger <sthemmin@microsoft.com>
> > Cc: devel@linuxdriverproject.org; netdev@vger.kernel.org
> > Subject: [PATCH net-next 1/1] hv_netvsc: fix deadlock on hotplug
> >
> > When a virtual device is added dynamically (via host console), then
> > the vmbus sends an offer message for the primary channel. The processing
> > of this message for networking causes the network device to then
> > initialize the sub channels.
> >
> > The problem is that setting up the sub channels needs to wait until
> > the subsequent subchannel offers have been processed. These offers
> > come in on the same ring buffer and work queue as where the primary
> > offer is being processed; leading to a deadlock.
> >
> > This did not happen in older kernels, because the sub channel waiting
> > logic was broken (it wasn't really waiting).
> >
> > The solution is to do the sub channel setup in its own work queue
> > context that is scheduled by the primary channel setup; and then
> > happens later.
> >
> > Fixes: 732e49850c5e ("netvsc: fix race on sub channel creation")
> > Reported-by: Dexuan Cui <decui@microsoft.com>
> > Signed-off-by: Stephen Hemminger <sthemmin@microsoft.com>
> > ---
> > Should also go to stable, but this version does not apply cleanly
> > to 4.13. Have another patch for that.
> >
> > drivers/net/hyperv/hyperv_net.h | 1 +
> > drivers/net/hyperv/netvsc_drv.c | 8 +--
> > drivers/net/hyperv/rndis_filter.c | 106 ++++++++++++++++++++++++++-----
> > -------
> > 3 files changed, 74 insertions(+), 41 deletions(-)
>
> The patch looks overall. I just have a question:
>
> With this patch, after module load and probe is done, there may still be
> subchannels being processed. If rmmod immediately, the subchannel offers
> may hit half-way removed device structures... Do we also need to add
> cancel_work_sync(&dev->subchan_work) to the top of netvsc_remove()?
>
> unregister_netdevice() includes device close, but it's only called later
> in the netvsc_remove() when rndis is already removed.
>
> Thanks,
> - Haiyang
Good catch.
If the driver called unregister_netdevice first before doing rndis_filter_device_remove
that would solve the problem. That wouldn't cause additional problems and it makes
sense to close the network layer first.
^ permalink raw reply
* Re: [PATCH v2 rfc 8/8] net: dsa: Fix SWITCHDEV_ATTR_ID_PORT_PARENT_ID
From: Andrew Lunn @ 2017-09-06 16:29 UTC (permalink / raw)
To: Florian Fainelli; +Cc: Vivien Didelot, netdev, jiri, nikolay
In-Reply-To: <0D9EF30F-ED95-486E-91B0-E18D5E8689FE@gmail.com>
> >Yes, you are correct. I will change this.
>
> A switch cluster should be tied to the same dsa_switch_tree though,
> can we use dst->tree as an unique identifier?
Yes, that is what Vivien was suggesting.
Andrew
^ permalink raw reply
* Re: [PATCH net-next] xdp: implement xdp_redirect_map for generic XDP
From: Daniel Borkmann @ 2017-09-06 16:24 UTC (permalink / raw)
To: Jesper Dangaard Brouer, netdev, David S. Miller
Cc: John Fastabend, Andy Gospodarek
In-Reply-To: <150471158528.3727.12324542627400287360.stgit@firesoul>
On 09/06/2017 05:26 PM, Jesper Dangaard Brouer wrote:
> Using bpf_redirect_map is allowed for generic XDP programs, but the
> appropriate map lookup was never performed in xdp_do_generic_redirect().
>
> Instead the map-index is directly used as the ifindex. For the
Good point, but ...
[...]
> net/core/filter.c | 29 +++++++++++++++++++++++++++++
> 1 file changed, 29 insertions(+)
>
> diff --git a/net/core/filter.c b/net/core/filter.c
> index 5912c738a7b2..6a4745bf2c9f 100644
> --- a/net/core/filter.c
> +++ b/net/core/filter.c
> @@ -2562,6 +2562,32 @@ int xdp_do_redirect(struct net_device *dev, struct xdp_buff *xdp,
> }
> EXPORT_SYMBOL_GPL(xdp_do_redirect);
>
> +static int xdp_do_generic_redirect_map(struct net_device *dev,
> + struct sk_buff *skb,
> + struct bpf_prog *xdp_prog)
> +{
> + struct redirect_info *ri = this_cpu_ptr(&redirect_info);
> + struct bpf_map *map = ri->map;
> + u32 index = ri->ifindex;
> + struct net_device *fwd;
> + int err;
> +
> + ri->ifindex = 0;
> + ri->map = NULL;
> +
> + fwd = __dev_map_lookup_elem(map, index);
> + if (!fwd) {
> + err = -EINVAL;
> + goto err;
> + }
> + skb->dev = fwd;
> + _trace_xdp_redirect_map(dev, xdp_prog, fwd, map, index);
> + return 0;
> +err:
> + _trace_xdp_redirect_map_err(dev, xdp_prog, fwd, map, index, err);
> + return err;
> +}
> +
> int xdp_do_generic_redirect(struct net_device *dev, struct sk_buff *skb,
> struct bpf_prog *xdp_prog)
> {
> @@ -2571,6 +2597,9 @@ int xdp_do_generic_redirect(struct net_device *dev, struct sk_buff *skb,
> unsigned int len;
> int err = 0;
>
> + if (ri->map)
> + return xdp_do_generic_redirect_map(dev, skb, xdp_prog);
This is not quite correct. Really, the only thing you want
to do here is more or less ...
int xdp_do_generic_redirect(struct net_device *dev, struct sk_buff *skb,
struct bpf_prog *xdp_prog)
{
struct redirect_info *ri = this_cpu_ptr(&redirect_info);
struct bpf_map *map = ri->map;
u32 index = ri->ifindex;
struct net_device *fwd;
unsigned int len;
int err = 0;
ri->ifindex = 0;
ri->map = NULL;
if (map)
fwd = __dev_map_lookup_elem(map, index);
else
fwd = dev_get_by_index_rcu(dev_net(dev), index);
if (unlikely(!fwd)) {
err = -EINVAL;
goto err;
}
[...]
... such that you have a common path to also do the IFF_UP
and MTU checks that are done here, but otherwise omitted in
your patch.
Otherwise it looks good, but note that it also doesn't really
resolve the issue you mention wrt stale map pointers by the
way. This would need a different way to clear out the pointers
from redirect_info, I'm thinking when we have devmap dismantle
time after RCU grace period we should check whether there are
still stale pointers from this map around and clear them under
disabled preemption, but need to brainstorm a bit more on that
first.
> fwd = dev_get_by_index_rcu(dev_net(dev), index);
> ri->ifindex = 0;
> if (unlikely(!fwd)) {
>
^ permalink raw reply
* RE: [PATCH net-next 1/1] hv_netvsc: fix deadlock on hotplug
From: Haiyang Zhang @ 2017-09-06 16:23 UTC (permalink / raw)
To: Stephen Hemminger, KY Srinivasan, Stephen Hemminger
Cc: devel@linuxdriverproject.org, netdev@vger.kernel.org
In-Reply-To: <20170906151925.15221-2-sthemmin@microsoft.com>
> -----Original Message-----
> From: Stephen Hemminger [mailto:stephen@networkplumber.org]
> Sent: Wednesday, September 6, 2017 11:19 AM
> To: KY Srinivasan <kys@microsoft.com>; Haiyang Zhang
> <haiyangz@microsoft.com>; Stephen Hemminger <sthemmin@microsoft.com>
> Cc: devel@linuxdriverproject.org; netdev@vger.kernel.org
> Subject: [PATCH net-next 1/1] hv_netvsc: fix deadlock on hotplug
>
> When a virtual device is added dynamically (via host console), then
> the vmbus sends an offer message for the primary channel. The processing
> of this message for networking causes the network device to then
> initialize the sub channels.
>
> The problem is that setting up the sub channels needs to wait until
> the subsequent subchannel offers have been processed. These offers
> come in on the same ring buffer and work queue as where the primary
> offer is being processed; leading to a deadlock.
>
> This did not happen in older kernels, because the sub channel waiting
> logic was broken (it wasn't really waiting).
>
> The solution is to do the sub channel setup in its own work queue
> context that is scheduled by the primary channel setup; and then
> happens later.
>
> Fixes: 732e49850c5e ("netvsc: fix race on sub channel creation")
> Reported-by: Dexuan Cui <decui@microsoft.com>
> Signed-off-by: Stephen Hemminger <sthemmin@microsoft.com>
> ---
> Should also go to stable, but this version does not apply cleanly
> to 4.13. Have another patch for that.
>
> drivers/net/hyperv/hyperv_net.h | 1 +
> drivers/net/hyperv/netvsc_drv.c | 8 +--
> drivers/net/hyperv/rndis_filter.c | 106 ++++++++++++++++++++++++++-----
> -------
> 3 files changed, 74 insertions(+), 41 deletions(-)
The patch looks overall. I just have a question:
With this patch, after module load and probe is done, there may still be
subchannels being processed. If rmmod immediately, the subchannel offers
may hit half-way removed device structures... Do we also need to add
cancel_work_sync(&dev->subchan_work) to the top of netvsc_remove()?
unregister_netdevice() includes device close, but it's only called later
in the netvsc_remove() when rndis is already removed.
Thanks,
- Haiyang
^ permalink raw reply
* Re: [PATCH net] rds: Fix incorrect statistics counting
From: Santosh Shilimkar @ 2017-09-06 16:21 UTC (permalink / raw)
To: Håkon Bugge
Cc: David S . Miller, netdev, OFED mailing list, rds-devel,
linux-kernel, Knut Omang
In-Reply-To: <715EA84D-6ACA-45DE-9EA2-6122E11545E8@oracle.com>
On 9/6/2017 9:12 AM, Håkon Bugge wrote:
>
[...]
>
> Hi Santosh,
>
>
> Yes, I agree with accuracy of s_send_lock_queue_raced. But the main point is that the existing code counts some partial share of when it is _not_ raced.
>
> So, in the critical path, my patch adds one test_bit(), which hits the local CPU cache, if not raced. If raced, some other thread is in control, so I would not think the added cycles would make any big difference.
>
Cycles added for no good reason is the point.
> I can send a v2 where the race tightening is removed if you like.
>
Yes please.
Regards,
Santosh
^ permalink raw reply
* Re: [pull request][net-next 0/3] Mellanox, mlx5 GRE tunnel offloads
From: Tom Herbert @ 2017-09-06 16:17 UTC (permalink / raw)
To: Alexander Duyck
Cc: Hannes Frederic Sowa, Saeed Mahameed, Saeed Mahameed,
David S. Miller, Linux Netdev List
In-Reply-To: <CAKgT0UeHbs3cM=yvSAdQMN92mWZjaqsq5Pyk1SkC8V_DK8pf3A@mail.gmail.com>
On Tue, Sep 5, 2017 at 8:06 PM, Alexander Duyck
<alexander.duyck@gmail.com> wrote:
> On Tue, Sep 5, 2017 at 2:13 PM, Tom Herbert <tom@herbertland.com> wrote:
>>> The situation with encapsulation is even more complicated:
>>>
>>> We are basically only interested in the UDP/vxlan/Ethernet/IP/UDP
>>> constellation. If we do the fragmentation inside the vxlan tunnel and
>>> carry over the skb hash to all resulting UDP/vxlan packets source ports,
>>> we are fine and reordering on the receiver NIC won't happen in this
>>> case. If the fragmentation happens on the outer UDP header, this will
>>> result in reordering of the inner L2 flow. Unfortunately this depends on
>>> how the vxlan tunnel was set up, how other devices do that and (I
>>> believe so) on the kernel version.
>>>
>> This really isn't that complicated. The assumption that an IP network
>> always delivers packets in order is simply wrong. The inventors of
>> VXLAN must have know full well that when you use IP, packets can and
>> eventually will be delivered out of order. This isn't just because of
>> fragmentation, there are many other reasons that packets can be
>> delivered OOO. This also must have been known when IP/GRE and any
>> other protocol that carries L2 over IP was invented. If OOO is an
>> issue for these protocols then they need to be fixed-- this is not a
>> concern with IP protocol nor the stack.
>>
>> Tom
>
> As far as a little background on the original patch I believe the
> issue that was fixed by the patch was a video streaming application
> that was sending/receiving a mix of fragmented and non-fragmented
> packets. Receiving them out of order due to the fragmentation was
> causing issues with stutters in the video and so we ended up disabling
> UDP by default in the NICs listed. We decided to go that way as UDP
> RSS was viewed as a performance optimization, while the out-of-order
> problems were viewed as a functionality issue.
>
Hi Alex,
Thanks for the details! Were you able to find the root cause for this?
In particular, it would be interesting to know if it is the kernel or
device that introduced the jitter, or if it's the application that
doesn't handle OOO well...
Tom
^ permalink raw reply
* Re: [PATCH net] rds: Fix incorrect statistics counting
From: Håkon Bugge @ 2017-09-06 16:12 UTC (permalink / raw)
To: Santosh Shilimkar
Cc: David S . Miller, netdev, OFED mailing list, rds-devel,
linux-kernel, Knut Omang
In-Reply-To: <b620a15a-e60e-5c35-ffef-ee485d338774@oracle.com>
> On 6 Sep 2017, at 17:58, Santosh Shilimkar <santosh.shilimkar@oracle.com> wrote:
>
> On 9/6/2017 8:29 AM, Håkon Bugge wrote:
>> In rds_send_xmit() there is logic to batch the sends. However, if
>> another thread has acquired the lock, it is considered a race and we
>> yield. The code incrementing the s_send_lock_queue_raced statistics
>> counter did not count this event correctly.
>> This commit removes a small race in determining the race and
>> increments the statistics counter correctly.
>> Signed-off-by: Håkon Bugge <haakon.bugge@oracle.com>
>> Reviewed-by: Knut Omang <knut.omang@oracle.com>
>> ---
>> net/rds/send.c | 16 +++++++++++++---
>> 1 file changed, 13 insertions(+), 3 deletions(-)
> Those counters are not really to give that accurate so
> am not very keen to add additional cycles in send paths
> and add additional code. Have you seen any real issue
> or this is just a observation. s_send_lock_queue_raced
> counter is never used to check for smaller increments
> and hence the question.
Hi Santosh,
Yes, I agree with accuracy of s_send_lock_queue_raced. But the main point is that the existing code counts some partial share of when it is _not_ raced.
So, in the critical path, my patch adds one test_bit(), which hits the local CPU cache, if not raced. If raced, some other thread is in control, so I would not think the added cycles would make any big difference.
I can send a v2 where the race tightening is removed if you like.
Thxs, Håkon
^ permalink raw reply
* Re: [PATCH v2 rfc 8/8] net: dsa: Fix SWITCHDEV_ATTR_ID_PORT_PARENT_ID
From: Florian Fainelli @ 2017-09-06 16:09 UTC (permalink / raw)
To: Andrew Lunn, Vivien Didelot; +Cc: netdev, jiri, nikolay
In-Reply-To: <20170906150825.GB15315@lunn.ch>
On September 6, 2017 8:08:25 AM PDT, Andrew Lunn <andrew@lunn.ch> wrote:
>> > Use the MAC address of the master interface as the parent ID. This
>is
>> > the same for all switches in a cluster, and should be unique if
>there
>> > are multiple clusters.
>>
>> That is not correct. Support for multiple CPU ports is coming and in
>> this case, you can have two CPU host interfaces wired to two switch
>> ports of the same tree. So two different master MAC addresses.
>
>Yes, you are correct. I will change this.
A switch cluster should be tied to the same dsa_switch_tree though, can we use dst->tree as an unique identifier?
--
Florian
^ permalink raw reply
* Re: [PATCH v2 rfc 0/8] IGMP snooping for local traffic
From: Florian Fainelli @ 2017-09-06 16:06 UTC (permalink / raw)
To: Roopa Prabhu, Andrew Lunn
Cc: netdev, Vivien Didelot, Woojung.Huh, jbe, sean.wang, john
In-Reply-To: <CAJieiUj-ObfKAZa18JxnWSswLGK-mRLjqE7qyCrZ5tsVftf46w@mail.gmail.com>
On September 6, 2017 8:54:33 AM PDT, Roopa Prabhu <roopa@cumulusnetworks.com> wrote:
>On Tue, Sep 5, 2017 at 5:47 PM, Andrew Lunn <andrew@lunn.ch> wrote:
>>> The third and last issue will be explained in a followup email.
>>
>> Hi DSA hackers
>>
>> So there is the third issue. It affects just DSA, but it possible
>> affects all DSA drivers.
>>
>> This patchset broken broadcast with the Marvell drivers. It could
>> break broadcast on others drivers as well.
>>
>> What i found is that the Marvell chips don't flood broadcast frames
>> between bridged ports. What appears to happen is there is a fdb miss,
>> so it gets forwarded to the CPU port for the host to deal with. The
>> software bridge when floods it out all ports of the bridge.
>>
>> But the set offload_fwd_mark patch changes this. The software bridge
>> now assumes the hardware has already flooded broadcast out all ports
>> of the switch as needed. So it does not do any flooding itself. As a
>> result, on Marvell devices, broadcast packets don't get flooded at
>> all.
>>
>> The issue can be fixed. I just need to add an mdb entry for the
>> broadcast address to each port of the bridge in the switch, and the
>> CPU port. But i don't know at what level to do this.
>>
>> Should this be done at the DSA level, or at the driver level? Do any
>> chips do broadcast flooding in hardware already? Hence they currently
>> see broadcast duplication? If i add a broadcast mdb at the DSA level,
>> and the chip is already hard wired to flooding broadcast, is it going
>> to double flood?
>>
>
>On the switch asics we work with, the driver has information if the
>packet was
>forwarded in hardware. This is per packet reason code telling why the
>CPU is seeing the packet.
>The driver can use this information to reset skb->offload_fwd_mark to
>allow software forward.
I am not positive this is universally available across different switch vendors. In Broadcom tag (net/dsa/tag_brcm.c) the reason code definitely tells you that but it also largely depends on whether you have configured SW managed forwarding or not and that translates in having either the HW do all the address learning itself or having SW do it which is less desirable since you end-up with a possibility huge FDB of 4k entries to manage in SW.
--
Florian
^ permalink raw reply
* Re: [PATCH net-next] xdp: implement xdp_redirect_map for generic XDP
From: Jesper Dangaard Brouer @ 2017-09-06 16:01 UTC (permalink / raw)
To: Andy Gospodarek
Cc: netdev@vger.kernel.org, David S. Miller, John Fastabend, brouer
In-Reply-To: <CAHashqBPDDETq2qdj3n8uL3hE61f=a5cv_eF6a9apoRzNVqaxA@mail.gmail.com>
On Wed, 6 Sep 2017 11:44:18 -0400
Andy Gospodarek <andy@greyhouse.net> wrote:
> On Wed, Sep 6, 2017 at 11:26 AM, Jesper Dangaard Brouer
> <brouer@redhat.com> wrote:
> > Using bpf_redirect_map is allowed for generic XDP programs, but the
> > appropriate map lookup was never performed in xdp_do_generic_redirect().
> >
> > Instead the map-index is directly used as the ifindex. For the
> > xdp_redirect_map sample in SKB-mode '-S', this resulted in trying
> > sending on ifindex 0 which isn't valid, resulting in getting SKB
> > packets dropped. Thus, the reported performance numbers are wrong in
> > commit 24251c264798 ("samples/bpf: add option for native and skb mode
> > for redirect apps") for the 'xdp_redirect_map -S' case.
> >
> > It might seem innocent this was lacking, but it can actually crash the
> > kernel. The potential crash is caused by not consuming redirect_info->map.
> > The bpf_redirect_map helper will set this_cpu_ptr(&redirect_info)->map
> > pointer, which will survive even after unloading the xdp bpf_prog and
> > deallocating the devmap data-structure. This leaves a dead map
> > pointer around. The kernel will crash when loading the xdp_redirect
> > sample (in native XDP mode) as it doesn't reset map (via bpf_redirect)
> > and returns XDP_REDIRECT, which will cause it to dereference the map
> > pointer.
>
> Nice catch!
>
> Since 'net-next' is closed and this is a bugfix it seems like this is
> a good candidate for 'net' right?
Yes, I know 'net-next' is closed, but 'net' doesn't contain the
XDP_REDIRECT code yet... thus I had to base it on net-next ;-)
> >
> > Fixes: 6103aa96ec07 ("net: implement XDP_REDIRECT for xdp generic")
> > Fixes: 24251c264798 ("samples/bpf: add option for native and skb mode for redirect apps")
> > Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
>
> Acked-by: Andy Gospodarek <andy@greyhouse.net>
Thanks
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
LinkedIn: http://www.linkedin.com/in/brouer
^ permalink raw reply
* Re: [PATCH net] rds: Fix incorrect statistics counting
From: Santosh Shilimkar @ 2017-09-06 15:58 UTC (permalink / raw)
To: Håkon Bugge, David S . Miller
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, linux-rdma-u79uwXL29TY76Z2rM5mHXA,
rds-devel-N0ozoZBvEnrZJqsBc5GL+g,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
knut.omang-QHcLZuEGTsvQT0dZR+AlfA
In-Reply-To: <20170906152950.17766-1-Haakon.Bugge-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
On 9/6/2017 8:29 AM, Håkon Bugge wrote:
> In rds_send_xmit() there is logic to batch the sends. However, if
> another thread has acquired the lock, it is considered a race and we
> yield. The code incrementing the s_send_lock_queue_raced statistics
> counter did not count this event correctly.
>
> This commit removes a small race in determining the race and
> increments the statistics counter correctly.
>
> Signed-off-by: Håkon Bugge <haakon.bugge-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
> Reviewed-by: Knut Omang <knut.omang-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
> ---
> net/rds/send.c | 16 +++++++++++++---
> 1 file changed, 13 insertions(+), 3 deletions(-)
>
Those counters are not really to give that accurate so
am not very keen to add additional cycles in send paths
and add additional code. Have you seen any real issue
or this is just a observation. s_send_lock_queue_raced
counter is never used to check for smaller increments
and hence the question.
Regards,
Santosh
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" 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 v2 rfc 0/8] IGMP snooping for local traffic
From: Roopa Prabhu @ 2017-09-06 15:54 UTC (permalink / raw)
To: Andrew Lunn
Cc: netdev, Florian Fainelli, Vivien Didelot, Woojung.Huh, jbe,
sean.wang, john
In-Reply-To: <20170906004703.GB27385@lunn.ch>
On Tue, Sep 5, 2017 at 5:47 PM, Andrew Lunn <andrew@lunn.ch> wrote:
>> The third and last issue will be explained in a followup email.
>
> Hi DSA hackers
>
> So there is the third issue. It affects just DSA, but it possible
> affects all DSA drivers.
>
> This patchset broken broadcast with the Marvell drivers. It could
> break broadcast on others drivers as well.
>
> What i found is that the Marvell chips don't flood broadcast frames
> between bridged ports. What appears to happen is there is a fdb miss,
> so it gets forwarded to the CPU port for the host to deal with. The
> software bridge when floods it out all ports of the bridge.
>
> But the set offload_fwd_mark patch changes this. The software bridge
> now assumes the hardware has already flooded broadcast out all ports
> of the switch as needed. So it does not do any flooding itself. As a
> result, on Marvell devices, broadcast packets don't get flooded at
> all.
>
> The issue can be fixed. I just need to add an mdb entry for the
> broadcast address to each port of the bridge in the switch, and the
> CPU port. But i don't know at what level to do this.
>
> Should this be done at the DSA level, or at the driver level? Do any
> chips do broadcast flooding in hardware already? Hence they currently
> see broadcast duplication? If i add a broadcast mdb at the DSA level,
> and the chip is already hard wired to flooding broadcast, is it going
> to double flood?
>
On the switch asics we work with, the driver has information if the packet was
forwarded in hardware. This is per packet reason code telling why the
CPU is seeing the packet.
The driver can use this information to reset skb->offload_fwd_mark to
allow software forward.
^ permalink raw reply
* Re: [PATCH net] Revert "net: phy: Correctly process PHY_HALTED in phy_stop_machine()"
From: Mason @ 2017-09-06 15:51 UTC (permalink / raw)
To: Florian Fainelli, Andrew Lunn
Cc: Marc Gonzalez, David Daney, netdev, Geert Uytterhoeven,
David Miller, Mans Rullgard, Thibaud Cornic
In-Reply-To: <7b1c1dc9-b6e3-a1bd-2e36-474946741a79@gmail.com>
On 31/08/2017 21:18, Florian Fainelli wrote:
> On 08/31/2017 12:09 PM, Mason wrote:
>
>> On 31/08/2017 19:03, Florian Fainelli wrote:
>>
>>> On 08/31/2017 05:29 AM, Marc Gonzalez wrote:
>>>
>>>> On 31/08/2017 02:49, Florian Fainelli wrote:
>>>>
>>>>> The original motivation for this change originated from Marc Gonzalez
>>>>> indicating that his network driver did not have its adjust_link callback
>>>>> executing with phydev->link = 0 while he was expecting it.
>>>>
>>>> I expect the core to call phy_adjust_link() for link changes.
>>>> This used to work back in 3.4 and was broken somewhere along
>>>> the way.
>>>
>>> If that was working correctly in 3.4 surely we can look at the diff and
>>> figure out what changed, even maybe find the offending commit, can you
>>> do that?
>>
>> Bisecting would a be a huge pain because my platform was
>> not upstream until v4.4
>
> Then just diff the file and try to pinpoint which commit may have
> changed that?
Running 'ip link set eth0 down' on the command-line.
In v3.4 => adjust_link() callback is called
In v4.5 => adjust_link() callback is NOT called
$ git log --oneline --no-merges v3.4..v4.5 drivers/net/phy/phy.c | wc -l
59
I'm not sure what "just diff the file" entails.
I can't move 3.4 up, nor move 4.5 down.
I'm not even sure the problem comes from drivers/net/phy/phy.c
to be honest.
Regards.
^ 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