* [PATCH v7 3/7] bnx2x: Replace doorbell barrier() with wmb()
From: Sinan Kaya @ 2018-03-25 14:39 UTC (permalink / raw)
To: netdev, timur, sulrich
Cc: linux-arm-msm, linux-arm-kernel, Sinan Kaya, Ariel Elior,
everest-linux-l2, linux-kernel
In-Reply-To: <1521988761-30344-1-git-send-email-okaya@codeaurora.org>
barrier() doesn't guarantee memory writes to be observed by the hardware on
all architectures. barrier() only tells compiler not to move this code
with respect to other read/writes.
If memory write needs to be observed by the HW, wmb() is the right choice.
Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
---
drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c | 3 ++-
drivers/net/ethernet/broadcom/bnx2x/bnx2x_ethtool.c | 3 ++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c
index d7c98e8..0f86f18 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c
@@ -4153,7 +4153,8 @@ netdev_tx_t bnx2x_start_xmit(struct sk_buff *skb, struct net_device *dev)
wmb();
txdata->tx_db.data.prod += nbd;
- barrier();
+ /* make sure descriptor update is observed by HW */
+ wmb();
DOORBELL(bp, txdata->cid, txdata->tx_db.raw);
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_ethtool.c b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_ethtool.c
index 1e33abd..39af4f8 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_ethtool.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_ethtool.c
@@ -2591,7 +2591,8 @@ static int bnx2x_run_loopback(struct bnx2x *bp, int loopback_mode)
wmb();
txdata->tx_db.data.prod += 2;
- barrier();
+ /* make sure descriptor update is observed by the HW */
+ wmb();
DOORBELL(bp, txdata->cid, txdata->tx_db.raw);
mmiowb();
--
2.7.4
^ permalink raw reply related
* [PATCH v7 4/7] bnx2x: Eliminate duplicate barriers on weakly-ordered archs
From: Sinan Kaya @ 2018-03-25 14:39 UTC (permalink / raw)
To: netdev, timur, sulrich
Cc: linux-arm-msm, linux-arm-kernel, Sinan Kaya, Ariel Elior,
everest-linux-l2, linux-kernel
In-Reply-To: <1521988761-30344-1-git-send-email-okaya@codeaurora.org>
Code includes wmb() followed by writel(). writel() already has a
barrier on some architectures like arm64.
This ends up CPU observing two barriers back to back before executing
the register write.
Since code already has an explicit barrier call, changing writel() to
writel_relaxed().
Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
---
drivers/net/ethernet/broadcom/bnx2x/bnx2x.h | 12 ++++++++----
drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c | 2 +-
drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.h | 4 ++--
drivers/net/ethernet/broadcom/bnx2x/bnx2x_ethtool.c | 2 +-
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c | 4 ++--
drivers/net/ethernet/broadcom/bnx2x/bnx2x_vfpf.c | 4 +++-
6 files changed, 17 insertions(+), 11 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x.h b/drivers/net/ethernet/broadcom/bnx2x/bnx2x.h
index 352beff..d847e1b 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x.h
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x.h
@@ -166,6 +166,12 @@ do { \
#define REG_RD8(bp, offset) readb(REG_ADDR(bp, offset))
#define REG_RD16(bp, offset) readw(REG_ADDR(bp, offset))
+#define REG_WR_RELAXED(bp, offset, val) \
+ writel_relaxed((u32)val, REG_ADDR(bp, offset))
+
+#define REG_WR16_RELAXED(bp, offset, val) \
+ writew_relaxed((u16)val, REG_ADDR(bp, offset))
+
#define REG_WR(bp, offset, val) writel((u32)val, REG_ADDR(bp, offset))
#define REG_WR8(bp, offset, val) writeb((u8)val, REG_ADDR(bp, offset))
#define REG_WR16(bp, offset, val) writew((u16)val, REG_ADDR(bp, offset))
@@ -758,10 +764,8 @@ struct bnx2x_fastpath {
#if (BNX2X_DB_SHIFT < BNX2X_DB_MIN_SHIFT)
#error "Min DB doorbell stride is 8"
#endif
-#define DOORBELL(bp, cid, val) \
- do { \
- writel((u32)(val), bp->doorbells + (bp->db_size * (cid))); \
- } while (0)
+#define DOORBELL_RELAXED(bp, cid, val) \
+ writel_relaxed((u32)(val), (bp)->doorbells + ((bp)->db_size * (cid)))
/* TX CSUM helpers */
#define SKB_CS_OFF(skb) (offsetof(struct tcphdr, check) - \
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c
index 0f86f18..95871576 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c
@@ -4156,7 +4156,7 @@ netdev_tx_t bnx2x_start_xmit(struct sk_buff *skb, struct net_device *dev)
/* make sure descriptor update is observed by HW */
wmb();
- DOORBELL(bp, txdata->cid, txdata->tx_db.raw);
+ DOORBELL_RELAXED(bp, txdata->cid, txdata->tx_db.raw);
mmiowb();
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.h b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.h
index a5265e1..a8ce5c5 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.h
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.h
@@ -522,8 +522,8 @@ static inline void bnx2x_update_rx_prod(struct bnx2x *bp,
wmb();
for (i = 0; i < sizeof(rx_prods)/4; i++)
- REG_WR(bp, fp->ustorm_rx_prods_offset + i*4,
- ((u32 *)&rx_prods)[i]);
+ REG_WR_RELAXED(bp, fp->ustorm_rx_prods_offset + i * 4,
+ ((u32 *)&rx_prods)[i]);
mmiowb(); /* keep prod updates ordered */
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_ethtool.c b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_ethtool.c
index 39af4f8..da18aa2 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_ethtool.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_ethtool.c
@@ -2593,7 +2593,7 @@ static int bnx2x_run_loopback(struct bnx2x *bp, int loopback_mode)
txdata->tx_db.data.prod += 2;
/* make sure descriptor update is observed by the HW */
wmb();
- DOORBELL(bp, txdata->cid, txdata->tx_db.raw);
+ DOORBELL_RELAXED(bp, txdata->cid, txdata->tx_db.raw);
mmiowb();
barrier();
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
index 74fc9af..146c40d 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
@@ -3817,8 +3817,8 @@ static void bnx2x_sp_prod_update(struct bnx2x *bp)
*/
mb();
- REG_WR16(bp, BAR_XSTRORM_INTMEM + XSTORM_SPQ_PROD_OFFSET(func),
- bp->spq_prod_idx);
+ REG_WR16_RELAXED(bp, BAR_XSTRORM_INTMEM + XSTORM_SPQ_PROD_OFFSET(func),
+ bp->spq_prod_idx);
mmiowb();
}
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_vfpf.c b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_vfpf.c
index 76a4668..8e0a317 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_vfpf.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_vfpf.c
@@ -170,7 +170,9 @@ static int bnx2x_send_msg2pf(struct bnx2x *bp, u8 *done, dma_addr_t msg_mapping)
wmb();
/* Trigger the PF FW */
- writeb(1, &zone_data->trigger.vf_pf_channel.addr_valid);
+ writeb_relaxed(1, &zone_data->trigger.vf_pf_channel.addr_valid);
+
+ mmiowb();
/* Wait for PF to complete */
while ((tout >= 0) && (!*done)) {
--
2.7.4
^ permalink raw reply related
* Re: [PATCH RFC v2 net-next 19/21] net/ipv6: separate handling of FIB entries from dst based routes
From: David Ahern @ 2018-03-25 14:49 UTC (permalink / raw)
To: Ido Schimmel; +Cc: netdev, davem, roopa, eric.dumazet, weiwan, kafai, yoshfuji
In-Reply-To: <20180324160209.GB15120@splinter>
On 3/24/18 10:02 AM, Ido Schimmel wrote:
>>
>> ok, I'll take a look. I thought I verified both paths (fib6_info and
>> dst) were freeing the metrics.
>
> I get this from kmemleak (applied your patchset on top of fe2d55d295cf):
>
> unreferenced object 0xffff88004e2c16c8 (size 96):
> comm "systemd-network", pid 1255, jiffies 4295166424 (age 957.858s)
> hex dump (first 32 bytes):
> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> backtrace:
> ip6_route_info_create (/net/ipv6/route.c:2849)
> ip6_route_add (/net/ipv6/route.c:2975)
> inet6_rtm_newroute (/net/ipv6/route.c:4357)
> rtnetlink_rcv_msg (/net/core/rtnetlink.c:4643)
> netlink_rcv_skb (/net/netlink/af_netlink.c:2445)
> netlink_unicast (/net/netlink/af_netlink.c:1309 /net/netlink/af_netlink.c:1334)
> netlink_sendmsg (/net/netlink/af_netlink.c:1897)
> sock_sendmsg (/net/socket.c:630 /net/socket.c:639)
> SYSC_sendto (/net/socket.c:1748)
> do_syscall_64 (/arch/x86/entry/common.c:287)
> entry_SYSCALL_64_after_hwframe (/arch/x86/entry/entry_64.S:239)
> 0xffffffffffffffff (/./include/asm-generic/sections.h:42)
>
Thanks for confirming. I'll take care of it.
^ permalink raw reply
* Re: [PATCH RFC v2 net-next 00/21] net/ipv6: Separate data structures for FIB and data path
From: David Ahern @ 2018-03-25 15:09 UTC (permalink / raw)
To: Ido Schimmel; +Cc: netdev, davem, roopa, eric.dumazet, weiwan, kafai, yoshfuji
In-Reply-To: <20180324155957.GA15120@splinter>
On 3/24/18 9:59 AM, Ido Schimmel wrote:
>> As you know, my preference is to move to nexthop objects (makes fib6_nh
>> optional). I have IPv4 done; IPv6 requires this patch set.
>
> After going over your presentation [1] I was under the impression that
> the fib6_info will be optional, not fib6_nh: "Idea is similar to adding
> id to fib_info that is exposed to userspace. Subsequent routes pass id
> to avoid fib_info overhead".
Just using that as an analogy to explain the idea in terms of something
that already exists.
>
> But I think misunderstood you. You want to introduce the nexthop API
> that will allow you to have multiple fib6_info pointing to the same
> fib6_nh?
>
> 1. http://vger.kernel.org/netconf2017_files/nexthop-objects.pdf
>
I see nexthop specs as device, gateway, lwtunnel_state and flags. That's
the basic building block. A nexthop group is multiple nexthops where
each nexthop in the group as its own weight.
The fib_info struct has more than that -- data unrelated to a netxthop
and is really a next level struct.
^ permalink raw reply
* Re: [PATCH RFC net-next 1/7] net: Fix fib notifer to return errno
From: Ido Schimmel @ 2018-03-25 15:37 UTC (permalink / raw)
To: David Ahern; +Cc: netdev, davem, roopa, shm, jiri, idosch, jakub.kicinski
In-Reply-To: <e2115470-778a-9923-35a3-04e5d9c8af91@cumulusnetworks.com>
On Sun, Mar 25, 2018 at 08:00:19AM -0600, David Ahern wrote:
> On 3/25/18 2:16 AM, Ido Schimmel wrote:
> > On Thu, Mar 22, 2018 at 03:57:51PM -0700, David Ahern wrote:
> >> Notifier handlers use notifier_from_errno to convert any potential error
> >> to an encoded format. As a consequence the other side, call_fib_notifiers
> >> in this case, needs to use notifier_to_errno to return the error from
> >> the handler back to its caller.
> >>
> >> Signed-off-by: David Ahern <dsa@cumulusnetworks.com>
> >> ---
> >> net/core/fib_notifier.c | 5 ++++-
> >> 1 file changed, 4 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/net/core/fib_notifier.c b/net/core/fib_notifier.c
> >> index 5ace0705a3f9..14ba52ebe8c9 100644
> >> --- a/net/core/fib_notifier.c
> >> +++ b/net/core/fib_notifier.c
> >> @@ -21,8 +21,11 @@ EXPORT_SYMBOL(call_fib_notifier);
> >> int call_fib_notifiers(struct net *net, enum fib_event_type event_type,
> >> struct fib_notifier_info *info)
> >
> > There's another (less interesting case) - call_fib_notifier(), which is
> > used to dump the FIB tables for the caller registering to the
> > notification chain.
> >
> > For example, if you have a non-default FIB rule in the system and you
> > modprobe mlxsw, you'll get a silent failure and routes will not be
> > offloaded. On the other hand, I'm not sure we want to fail the module
> > loading in such cases.
>
> right. In normal cases the driver is loaded to create the netdevices
> long before any networking config is done. So it seems to me the use
> case you refer to, some user would have go out of there way to create a
> situation where they install config that is not supported by the driver.
Yes.
> > A possible solution is to have the driver emit a warning via extack for
> > each route/rule being notified after the abort mechanism was triggered.
>
> extack is not available on module load.
I'm aware. I meant that during module load we'll trigger the abort
mechanism (due to an unsupported FIB rule for example), then when user
configures additional routes and extack is available we'll emit a
warning.
> Per past discussions, something you suggested, we need a message for
> "out-of-line" cases like this where a driver notifies userspace of a
> problem.
That's another possibility. We can implement both options to make it
perfectly clear to users and daemons what's going on.
^ permalink raw reply
* Hello Beautiful
From: Jack @ 2018-03-25 15:49 UTC (permalink / raw)
Hi Dear, my name is Jack and i am seeking for a relationship in which i will feel loved after a series of failed relationships.
I am hoping that you would be interested and we could possibly get to know each other more if you do not mind. I am open to answering questions from you as i think my approach is a little inappropriate. Hope to hear back from you.
Jack.
^ permalink raw reply
* Re: [PATCH net-next RFC V1 5/5] net: mdio: Add a driver for InES time stamping IP core.
From: Andrew Lunn @ 2018-03-25 15:59 UTC (permalink / raw)
To: Richard Cochran
Cc: netdev, devicetree, David Miller, Florian Fainelli, Mark Rutland,
Miroslav Lichvar, Rob Herring, Willem de Bruijn
In-Reply-To: <20180325045151.kq7mjopjwzo6w2vw@localhost>
On Sat, Mar 24, 2018 at 09:51:52PM -0700, Richard Cochran wrote:
> On Sat, Mar 24, 2018 at 07:48:58PM +0100, Andrew Lunn wrote:
> > As far as i can see, you have three basic problems:
> >
> > 1) How do you associate the PTP device to the netdev?
> > 2) How do you get the information you need to configure the PTP device
>
> Yes, yes.
>
> > 3) How do you limit the MAC/PHY to what the PTP device can do.
>
> Hm, I don't think this is important.
So you are happy that the PTP device will cause the MC/PHY link to
break down when it is asked to do something it cannot do? Take for
example a Marvell MAC connected to a Marvell PHY doing 2.5Gbps SGMII
because it can. But say the PTP device cannot be clocked that fast,
and the MII links break.... You as a PTP maintainer might be happy
with that, but as a PHY maintainer, i'm not too happy with this.
> Right, so phylib can operate on phydev->attached_dev->mdiots;
So first off, it is not an MDIO device. You current code is a horrible
hack which gets a NACK. Use a phandle, and have
of_mdiobus_register_phy() follow the phandle to get the device.
To keep lifecycle issues simple, i would also keep it in phydev, not
netdev.
mdiots as a name is completely wrong. It is not an MDIO device. Maybe
in the future some devices will be MDIO, or I2C, or SPI. Just call it
ptpdev. This ptpdev needs to be control bus agnostic. You need a
ptpdev core API exposing functions like ptpdev_hwtstamp,
ptpdev_rxtstamp, ptpdev_txtstamp, ptpdev_link_change, which take a
ptpdev. Have phy_link_change call ptpdev_link_change. You have the
flexibility in that if in the future you do care that your ptpdev
breaks the MAC-PHY link, you can add a ptpdev_validate_advertise,
which allows the ptpdev to mask out link modes it does not support.
Your ptp device, when probing needs to register with the ptpdev core,
passing a generic ptpdev_ops for the operations its support. How it
talks to the device, MMIO, SPI, I2C is hidden within the device
driver.
You can then clean up the code in timestamping.c. Code like:
phydev = skb->dev->phydev;
if (likely(phydev->drv->txtstamp)) {
clone = skb_clone_sk(skb);
if (!clone)
return;
phydev->drv->txtstamp(phydev, clone, type);
}
violates the layering, and the locking looks broken. Add a
phy_txtstamp() call to phylib. It can then either call into the PHY
driver, or use the call the ptpdev API, or -EOPNOTSUP.
Andrew
^ permalink raw reply
* Re: [net-next 03/15] net/mlx5e: PFC stall prevention support
From: Andrew Lunn @ 2018-03-25 16:18 UTC (permalink / raw)
To: Gal Pressman; +Cc: Saeed Mahameed, David S. Miller, netdev, Inbar Karmy
In-Reply-To: <220ed51e-5aeb-1a82-6c43-749e9cf8c4c1@mellanox.com>
> > Shouldn't you map a value of MLX5E_PFC_PREVEN_AUTO_TOUT_MSEC back to
> > PFC_STORM_PREVENTION_AUTO?
>
> We discussed this point internally, mapping MLX5E_PFC_PREVEN_AUTO_TOUT_MSEC (100) to
> PFC_STORM_PREVENTION_AUTO might cause confusion when the user explicitly asks for 100msec timeout
> and gets auto in his following query.
> Also, this way the "auto" timeout is visible to the user, which might help him get an initial
> clue of which values are recommended.
Yes, this is a fair point, which is why i asked the question. Either
way, it can cause confusion. 'I configured it to auto, but it always
returns 100, not auto.'
Whatever is decided, it should be consistent across drivers. So please
add some documentation to the ethtool header file about what is
expected.
Andrew
^ permalink raw reply
* [PATCH net 0/3] bonding: a bunch of fixes for dev hwaddr sync in bond_enslave
From: Xin Long @ 2018-03-25 17:16 UTC (permalink / raw)
To: network dev
Cc: davem, Jiri Pirko, Wang Chen, Veaceslav Falico,
Nikolay Aleksandrov
This patchset is mainly to fix a crash when adding vlan as slave of
bond which is also the parent link in patch 2/3, and also fix some
err process problems in bond_enslave in patch 1/3 and 3/3.
Xin Long (3):
bonding: fix the err path for dev hwaddr sync in bond_enslave
bonding: move dev_mc_sync after master_upper_dev_link in bond_enslave
bonding: process the err returned by dev_set_allmulti properly in
bond_enslave
drivers/net/bonding/bond_main.c | 73 +++++++++++++++++++++--------------------
1 file changed, 37 insertions(+), 36 deletions(-)
--
2.1.0
^ permalink raw reply
* [PATCH net 1/3] bonding: fix the err path for dev hwaddr sync in bond_enslave
From: Xin Long @ 2018-03-25 17:16 UTC (permalink / raw)
To: network dev
Cc: davem, Jiri Pirko, Wang Chen, Veaceslav Falico,
Nikolay Aleksandrov
In-Reply-To: <cover.1521997984.git.lucien.xin@gmail.com>
vlan_vids_add_by_dev is called right after dev hwaddr sync, so on
the err path it should unsync dev hwaddr. Otherwise, the slave
dev's hwaddr will never be unsync when this err happens.
Fixes: 1ff412ad7714 ("bonding: change the bond's vlan syncing functions with the standard ones")
Signed-off-by: Xin Long <lucien.xin@gmail.com>
---
drivers/net/bonding/bond_main.c | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index c669554..0c299de 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -1565,7 +1565,7 @@ int bond_enslave(struct net_device *bond_dev, struct net_device *slave_dev,
if (res) {
netdev_err(bond_dev, "Couldn't add bond vlan ids to %s\n",
slave_dev->name);
- goto err_close;
+ goto err_hwaddr_unsync;
}
prev_slave = bond_last_slave(bond);
@@ -1755,9 +1755,6 @@ int bond_enslave(struct net_device *bond_dev, struct net_device *slave_dev,
netdev_rx_handler_unregister(slave_dev);
err_detach:
- if (!bond_uses_primary(bond))
- bond_hw_addr_flush(bond_dev, slave_dev);
-
vlan_vids_del_by_dev(slave_dev, bond_dev);
if (rcu_access_pointer(bond->primary_slave) == new_slave)
RCU_INIT_POINTER(bond->primary_slave, NULL);
@@ -1771,6 +1768,10 @@ int bond_enslave(struct net_device *bond_dev, struct net_device *slave_dev,
synchronize_rcu();
slave_disable_netpoll(new_slave);
+err_hwaddr_unsync:
+ if (!bond_uses_primary(bond))
+ bond_hw_addr_flush(bond_dev, slave_dev);
+
err_close:
slave_dev->priv_flags &= ~IFF_BONDING;
dev_close(slave_dev);
--
2.1.0
^ permalink raw reply related
* [PATCH net 2/3] bonding: move dev_mc_sync after master_upper_dev_link in bond_enslave
From: Xin Long @ 2018-03-25 17:16 UTC (permalink / raw)
To: network dev
Cc: davem, Jiri Pirko, Wang Chen, Veaceslav Falico,
Nikolay Aleksandrov
In-Reply-To: <cover.1521997984.git.lucien.xin@gmail.com>
Beniamino found a crash when adding vlan as slave of bond which is also
the parent link:
ip link add bond1 type bond
ip link set bond1 up
ip link add link bond1 vlan1 type vlan id 80
ip link set vlan1 master bond1
The call trace is as below:
[<ffffffffa850842a>] queued_spin_lock_slowpath+0xb/0xf
[<ffffffffa8515680>] _raw_spin_lock+0x20/0x30
[<ffffffffa83f6f07>] dev_mc_sync+0x37/0x80
[<ffffffffc08687dc>] vlan_dev_set_rx_mode+0x1c/0x30 [8021q]
[<ffffffffa83efd2a>] __dev_set_rx_mode+0x5a/0xa0
[<ffffffffa83f7138>] dev_mc_sync_multiple+0x78/0x80
[<ffffffffc084127c>] bond_enslave+0x67c/0x1190 [bonding]
[<ffffffffa8401909>] do_setlink+0x9c9/0xe50
[<ffffffffa8403bf2>] rtnl_newlink+0x522/0x880
[<ffffffffa8403ff7>] rtnetlink_rcv_msg+0xa7/0x260
[<ffffffffa8424ecb>] netlink_rcv_skb+0xab/0xc0
[<ffffffffa83fe498>] rtnetlink_rcv+0x28/0x30
[<ffffffffa8424850>] netlink_unicast+0x170/0x210
[<ffffffffa8424bf8>] netlink_sendmsg+0x308/0x420
[<ffffffffa83cc396>] sock_sendmsg+0xb6/0xf0
This is actually a dead lock caused by sync slave hwaddr from master when
the master is the slave's 'slave'. This dead loop check is actually done
by netdev_master_upper_dev_link. However, Commit 1f718f0f4f97 ("bonding:
populate neighbour's private on enslave") moved it after dev_mc_sync.
This patch is to fix it by moving dev_mc_sync after master_upper_dev_link,
so that this loop check would be earlier than dev_mc_sync. It also moves
if (mode == BOND_MODE_8023AD) into if (!bond_uses_primary) clause as an
improvement.
Note team driver also has this issue, I will fix it in another patch.
Fixes: 1f718f0f4f97 ("bonding: populate neighbour's private on enslave")
Reported-by: Beniamino Galvani <bgalvani@redhat.com>
Signed-off-by: Xin Long <lucien.xin@gmail.com>
---
drivers/net/bonding/bond_main.c | 73 ++++++++++++++++++++---------------------
1 file changed, 35 insertions(+), 38 deletions(-)
diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index 0c299de..55e1985 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -1528,44 +1528,11 @@ int bond_enslave(struct net_device *bond_dev, struct net_device *slave_dev,
goto err_close;
}
- /* If the mode uses primary, then the following is handled by
- * bond_change_active_slave().
- */
- if (!bond_uses_primary(bond)) {
- /* set promiscuity level to new slave */
- if (bond_dev->flags & IFF_PROMISC) {
- res = dev_set_promiscuity(slave_dev, 1);
- if (res)
- goto err_close;
- }
-
- /* set allmulti level to new slave */
- if (bond_dev->flags & IFF_ALLMULTI) {
- res = dev_set_allmulti(slave_dev, 1);
- if (res)
- goto err_close;
- }
-
- netif_addr_lock_bh(bond_dev);
-
- dev_mc_sync_multiple(slave_dev, bond_dev);
- dev_uc_sync_multiple(slave_dev, bond_dev);
-
- netif_addr_unlock_bh(bond_dev);
- }
-
- if (BOND_MODE(bond) == BOND_MODE_8023AD) {
- /* add lacpdu mc addr to mc list */
- u8 lacpdu_multicast[ETH_ALEN] = MULTICAST_LACPDU_ADDR;
-
- dev_mc_add(slave_dev, lacpdu_multicast);
- }
-
res = vlan_vids_add_by_dev(slave_dev, bond_dev);
if (res) {
netdev_err(bond_dev, "Couldn't add bond vlan ids to %s\n",
slave_dev->name);
- goto err_hwaddr_unsync;
+ goto err_close;
}
prev_slave = bond_last_slave(bond);
@@ -1725,6 +1692,37 @@ int bond_enslave(struct net_device *bond_dev, struct net_device *slave_dev,
goto err_upper_unlink;
}
+ /* If the mode uses primary, then the following is handled by
+ * bond_change_active_slave().
+ */
+ if (!bond_uses_primary(bond)) {
+ /* set promiscuity level to new slave */
+ if (bond_dev->flags & IFF_PROMISC) {
+ res = dev_set_promiscuity(slave_dev, 1);
+ if (res)
+ goto err_sysfs_del;
+ }
+
+ /* set allmulti level to new slave */
+ if (bond_dev->flags & IFF_ALLMULTI) {
+ res = dev_set_allmulti(slave_dev, 1);
+ if (res)
+ goto err_sysfs_del;
+ }
+
+ netif_addr_lock_bh(bond_dev);
+ dev_mc_sync_multiple(slave_dev, bond_dev);
+ dev_uc_sync_multiple(slave_dev, bond_dev);
+ netif_addr_unlock_bh(bond_dev);
+
+ if (BOND_MODE(bond) == BOND_MODE_8023AD) {
+ /* add lacpdu mc addr to mc list */
+ u8 lacpdu_multicast[ETH_ALEN] = MULTICAST_LACPDU_ADDR;
+
+ dev_mc_add(slave_dev, lacpdu_multicast);
+ }
+ }
+
bond->slave_cnt++;
bond_compute_features(bond);
bond_set_carrier(bond);
@@ -1748,6 +1746,9 @@ int bond_enslave(struct net_device *bond_dev, struct net_device *slave_dev,
return 0;
/* Undo stages on error */
+err_sysfs_del:
+ bond_sysfs_slave_del(new_slave);
+
err_upper_unlink:
bond_upper_dev_unlink(bond, new_slave);
@@ -1768,10 +1769,6 @@ int bond_enslave(struct net_device *bond_dev, struct net_device *slave_dev,
synchronize_rcu();
slave_disable_netpoll(new_slave);
-err_hwaddr_unsync:
- if (!bond_uses_primary(bond))
- bond_hw_addr_flush(bond_dev, slave_dev);
-
err_close:
slave_dev->priv_flags &= ~IFF_BONDING;
dev_close(slave_dev);
--
2.1.0
^ permalink raw reply related
* [PATCH net 3/3] bonding: process the err returned by dev_set_allmulti properly in bond_enslave
From: Xin Long @ 2018-03-25 17:16 UTC (permalink / raw)
To: network dev
Cc: davem, Jiri Pirko, Wang Chen, Veaceslav Falico,
Nikolay Aleksandrov
In-Reply-To: <cover.1521997984.git.lucien.xin@gmail.com>
When dev_set_promiscuity(1) succeeds but dev_set_allmulti(1) fails,
dev_set_promiscuity(-1) should be done before going to the err path.
Otherwise, dev->promiscuity will leak.
Fixes: 7e1a1ac1fbaa ("bonding: Check return of dev_set_promiscuity/allmulti")
Signed-off-by: Xin Long <lucien.xin@gmail.com>
---
drivers/net/bonding/bond_main.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index 55e1985..b7b1130 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -1706,8 +1706,11 @@ int bond_enslave(struct net_device *bond_dev, struct net_device *slave_dev,
/* set allmulti level to new slave */
if (bond_dev->flags & IFF_ALLMULTI) {
res = dev_set_allmulti(slave_dev, 1);
- if (res)
+ if (res) {
+ if (bond_dev->flags & IFF_PROMISC)
+ dev_set_promiscuity(slave_dev, -1);
goto err_sysfs_del;
+ }
}
netif_addr_lock_bh(bond_dev);
--
2.1.0
^ permalink raw reply related
* [PATCH net] team: move dev_mc_sync after master_upper_dev_link in team_port_add
From: Xin Long @ 2018-03-25 17:25 UTC (permalink / raw)
To: network dev; +Cc: davem, Jiri Pirko
The same fix as in 'bonding: move dev_mc_sync after master_upper_dev_link
in bond_enslave' is needed for team driver.
The panic can be reproduced easily:
ip link add team1 type team
ip link set team1 up
ip link add link team1 vlan1 type vlan id 80
ip link set vlan1 master team1
Fixes: cb41c997d444 ("team: team should sync the port's uc/mc addrs when add a port")
Signed-off-by: Xin Long <lucien.xin@gmail.com>
---
drivers/net/team/team.c | 12 +++++-------
1 file changed, 5 insertions(+), 7 deletions(-)
diff --git a/drivers/net/team/team.c b/drivers/net/team/team.c
index 56c701b..befed2d 100644
--- a/drivers/net/team/team.c
+++ b/drivers/net/team/team.c
@@ -1197,11 +1197,6 @@ static int team_port_add(struct team *team, struct net_device *port_dev)
goto err_dev_open;
}
- netif_addr_lock_bh(dev);
- dev_uc_sync_multiple(port_dev, dev);
- dev_mc_sync_multiple(port_dev, dev);
- netif_addr_unlock_bh(dev);
-
err = vlan_vids_add_by_dev(port_dev, dev);
if (err) {
netdev_err(dev, "Failed to add vlan ids to device %s\n",
@@ -1241,6 +1236,11 @@ static int team_port_add(struct team *team, struct net_device *port_dev)
goto err_option_port_add;
}
+ netif_addr_lock_bh(dev);
+ dev_uc_sync_multiple(port_dev, dev);
+ dev_mc_sync_multiple(port_dev, dev);
+ netif_addr_unlock_bh(dev);
+
port->index = -1;
list_add_tail_rcu(&port->list, &team->port_list);
team_port_enable(team, port);
@@ -1265,8 +1265,6 @@ static int team_port_add(struct team *team, struct net_device *port_dev)
vlan_vids_del_by_dev(port_dev, dev);
err_vids_add:
- dev_uc_unsync(port_dev, dev);
- dev_mc_unsync(port_dev, dev);
dev_close(port_dev);
err_dev_open:
--
2.1.0
^ permalink raw reply related
* Re: [PATCH RFC net-next 7/7] netdevsim: Add simple FIB resource controller via devlink
From: Jakub Kicinski @ 2018-03-25 19:53 UTC (permalink / raw)
To: David Ahern; +Cc: netdev, davem, roopa, shm, jiri, idosch, David Ahern
In-Reply-To: <2c80d538-6881-709a-58b9-e0dfb669fac3@cumulusnetworks.com>
On Sun, 25 Mar 2018 08:27:42 -0600, David Ahern wrote:
> On 3/25/18 12:35 AM, Jakub Kicinski wrote:
> > On Sat, 24 Mar 2018 09:02:45 -0600, David Ahern wrote:
> >>>> diff --git a/drivers/net/netdevsim/Makefile b/drivers/net/netdevsim/Makefile
> >>>> index 09388c06171d..449b2a1a1800 100644
> >>>> --- a/drivers/net/netdevsim/Makefile
> >>>> +++ b/drivers/net/netdevsim/Makefile
> >>>> @@ -9,3 +9,7 @@ ifeq ($(CONFIG_BPF_SYSCALL),y)
> >>>> netdevsim-objs += \
> >>>> bpf.o
> >>>> endif
> >>>> +
> >>>> +ifneq ($(CONFIG_NET_DEVLINK),)
> >>>
> >>> Hm. Don't you need MAY_USE_DEVLINK dependency perhaps?
> >>
> >> mlxsw uses CONFIG_NET_DEVLINK in its Makefile.
> >>
> >> MAY_USE_DEVLINK seems to only be used in Kconfig files. Not clear to me
> >> why it is needed at all.
> >
> > NETDEVSIM=y && DEVLINK=m
> >
>
> ok. I purposely did not add DEVLINK as a dependency to netdevsim to make
> the resource controller truly optional. Can add it if you prefer.
Oh, no, I don't mind. I just thought NETDEVSIM=y DEVLINK=m case will
break the build, but I haven't tested. If it works perfect, let's not
add unnecessary dependencies :)
(FWIW the MAY_USE_DEVLINK dep is basically depend on DEVLINK ||
DEVLINK=n, so one can still build without devlink but if devlink is a
module netdevsim will also have to be.)
^ permalink raw reply
* Re: [PATCH net-next 00/13] liquidio: Tx queue cleanup
From: David Miller @ 2018-03-25 20:22 UTC (permalink / raw)
To: felix.manlunas
Cc: netdev, raghu.vatsavayi, derek.chickles, satananda.burla,
intiyaz.basha
In-Reply-To: <20180324003618.GA6457@felix-thinkpad.cavium.com>
From: Felix Manlunas <felix.manlunas@cavium.com>
Date: Fri, 23 Mar 2018 17:36:18 -0700
> From: Intiyaz Basha <intiyaz.basha@cavium.com>
>
> Moved some common function to octeon_network.h
> Removed some unwanted functions and checks.
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH v7 6/7] bnxt_en: Eliminate duplicate barriers on weakly-ordered archs
From: Michael Chan @ 2018-03-25 20:24 UTC (permalink / raw)
To: Sinan Kaya
Cc: Netdev, timur, sulrich, linux-arm-msm, linux-arm-kernel,
open list
In-Reply-To: <1521988761-30344-7-git-send-email-okaya@codeaurora.org>
On Sun, Mar 25, 2018 at 7:39 AM, Sinan Kaya <okaya@codeaurora.org> wrote:
> Code includes wmb() followed by writel(). writel() already has a barrier on
> some architectures like arm64.
>
> This ends up CPU observing two barriers back to back before executing the
> register write.
>
> Create a new wrapper function with relaxed write operator. Use the new
> wrapper when a write is following a wmb().
>
> Since code already has an explicit barrier call, changing writel() to
> writel_relaxed().
>
> Also add mmiowb() so that write code doesn't move outside of scope.
This line in the patch description is not needed anymore. Other than that,
Acked-by: Michael Chan <michael.chan@broadcom.com>
Thanks.
>
> Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
^ permalink raw reply
* Re: [net-next 00/12][pull request] 10GbE Intel Wired LAN Driver Updates 2018-03-23
From: David Miller @ 2018-03-25 20:26 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, nhorman, sassmann, jogreene
In-Reply-To: <20180323231631.32502-1-jeffrey.t.kirsher@intel.com>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Fri, 23 Mar 2018 16:16:19 -0700
> This series contains updates to ixgbe and ixgbevf only.
...
> Tony provides the much anticipated XDP support for ixgbevf. Currently,
> pass, drop and XDP_TX actions are supported, as well as meta data and
> stats reporting.
W00t!
> Björn Töpel tweaks the page counting for XDP_REDIRECT, since a page can
> have its reference count decreased via the xdp_do_redirect() call.
>
> The following are changes since commit f452518c982e57538e6d49da0a2c80eef22087ab:
> net: phy: intel-xway: add VR9 v1.1 phy ids
> and are available in the git repository at:
> git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next-queue 10GbE
Pulled, thanks Jeff.
^ permalink raw reply
* Re: [PATCH net-next 5/6] r8169: change type of driver_data
From: David Miller @ 2018-03-25 20:43 UTC (permalink / raw)
To: hkallweit1; +Cc: nic_swsd, netdev
In-Reply-To: <70541d5c-7a5e-3988-585d-2804ab41e4db@gmail.com>
From: Heiner Kallweit <hkallweit1@gmail.com>
Date: Sat, 24 Mar 2018 23:18:25 +0100
> Several functions accessing the device driver_data field don't need the
> net_device. All needed parameters can be accessed via struct
> rtl8169_private, therefore change type of driver_data accordingly.
>
> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
This doesn't work.
The pci_set_drvdata() call happens after register_netdevice().
At the exact moment register_netdevice() is called, any part of the
driver can be invoked before it returns.
Therefore this change will result in crashes because the drvdata won't
be initialized early enough.
I really think you're taking things too far with the cleanups of this
driver. It is a reasonably old driver used by a lot of people, and I
think avoiding regressions is 1000 times more important than
"streamlining" control plane functions that have not effect whatsoever
on real driver performance.
Thank you.
^ permalink raw reply
* hallo Schönheit
From: Wesley @ 2018-03-25 20:44 UTC (permalink / raw)
Es ist mir eine Freude, Sie kennenzulernen. Mein Name ist Wesley, ich komme aus dem Vereinigten Staaten von Amerika. Ich bin ledig und nie verheiratet. Ich werde mich gerne mit Ihnen bekannt machen, ich entschuldige mich für Ihre Privatsphäre. Ich hoffe, Sie werden freundlich sein genug, um mir mehr über dich zu erzählen, wenn es dir nichts ausmacht.
Hoffe bald von dir zu hören.
Grüße,
Wesley.
^ permalink raw reply
* Re: [PATCH net-next v6 0/2] net: permit skb_segment on head_frag frag_list skb
From: David Miller @ 2018-03-25 20:47 UTC (permalink / raw)
To: yhs; +Cc: edumazet, ast, daniel, diptanu, netdev, kernel-team
In-Reply-To: <20180321233104.2142764-1-yhs@fb.com>
From: Yonghong Song <yhs@fb.com>
Date: Wed, 21 Mar 2018 16:31:02 -0700
> One of our in-house projects, bpf-based NAT, hits a kernel BUG_ON at
> function skb_segment(), line 3667. The bpf program attaches to
> clsact ingress, calls bpf_skb_change_proto to change protocol
> from ipv4 to ipv6 or from ipv6 to ipv4, and then calls bpf_redirect
> to send the changed packet out.
> ...
> 3665 while (pos < offset + len) {
> 3666 if (i >= nfrags) {
> 3667 BUG_ON(skb_headlen(list_skb));
> ...
>
> The triggering input skb has the following properties:
> list_skb = skb->frag_list;
> skb->nfrags != NULL && skb_headlen(list_skb) != 0
> and skb_segment() is not able to handle a frag_list skb
> if its headlen (list_skb->len - list_skb->data_len) is not 0.
>
> Patch #1 provides a simple solution to avoid BUG_ON. If
> list_skb->head_frag is true, its page-backed frag will
> be processed before the list_skb->frags.
> Patch #2 provides a test case in test_bpf module which
> constructs a skb and calls skb_segment() directly. The test
> case is able to trigger the BUG_ON without Patch #1.
>
> The patch has been tested in the following setup:
> ipv6_host <-> nat_server <-> ipv4_host
> where nat_server has a bpf program doing ipv4<->ipv6
> translation and forwarding through clsact hook
> bpf_skb_change_proto.
Series applied, however I'm still not %100 convinced that allowing this
kind of protocol and MSS sized mucked GRO packet is a good idea.
^ permalink raw reply
* Re: [v2] vhost: add vsock compat ioctl
From: David Miller @ 2018-03-25 20:50 UTC (permalink / raw)
To: stefanha; +Cc: sonnyrao, netdev
In-Reply-To: <CAJSP0QUFjhq-X=vRH+qb0XPRm5daqWqouwHJf1Lo_sHhjD7vQg@mail.gmail.com>
From: Stefan Hajnoczi <stefanha@gmail.com>
Date: Thu, 22 Mar 2018 09:25:35 +0000
> On Fri, Mar 16, 2018 at 7:30 PM, David Miller <davem@davemloft.net> wrote:
>> Although the top level ioctls are probably size and layout compatible,
>> I do not think that the deeper ioctls can be called by compat binaries
>> without some translations in order for them to work.
>
> I audited the vhost ioctl code when reviewing this patch and was
> unable to find anything that would break for a 32-bit userspace
> process.
>
> drivers/vhost/net.c does the same thing already, which doesn't prove
> it's correct but makes me more confident I didn't miss something while
> auditing the vhost ioctl code.
>
> Did you have a specific ioctl in mind?
I walked over the vhost ioctl datastructures and they all appear like
they should be compatible.
So I guess it won't be a problem after all.
^ permalink raw reply
* [PATCH v2 net-next 1/2] net: dsa: mv88e6xxx: Use the DT IRQ trigger mode
From: Andrew Lunn @ 2018-03-25 20:56 UTC (permalink / raw)
To: David Miller; +Cc: netdev, u.kleine-koenig, Andrew Lunn
In-Reply-To: <1522011372-17080-1-git-send-email-andrew@lunn.ch>
By calling request_threaded_irq() with the flag IRQF_TRIGGER_FALLING
we override the trigger mode provided in device tree. And the
interrupt is actually active low, which is what all the current device
tree descriptions use.
Suggested-by: Uwe Kleine-Künig <u.kleine-koenig@pengutronix.de>
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
---
v2: Fix the ü in Künig
---
drivers/net/dsa/mv88e6xxx/chip.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c
index fd78378ad6b1..3ba77067a3dc 100644
--- a/drivers/net/dsa/mv88e6xxx/chip.c
+++ b/drivers/net/dsa/mv88e6xxx/chip.c
@@ -425,7 +425,7 @@ static int mv88e6xxx_g1_irq_setup(struct mv88e6xxx_chip *chip)
err = request_threaded_irq(chip->irq, NULL,
mv88e6xxx_g1_irq_thread_fn,
- IRQF_ONESHOT | IRQF_TRIGGER_FALLING,
+ IRQF_ONESHOT,
dev_name(chip->dev), chip);
if (err)
mv88e6xxx_g1_irq_free_common(chip);
--
2.16.2
^ permalink raw reply related
* [PATCH v2 net-next 2/2] net: dsa: mv88e6xxx: Call the common IRQ free code
From: Andrew Lunn @ 2018-03-25 20:56 UTC (permalink / raw)
To: David Miller; +Cc: netdev, u.kleine-koenig, Andrew Lunn
In-Reply-To: <1522011372-17080-1-git-send-email-andrew@lunn.ch>
When free'ing the polled IRQs, call the common irq free code.
Otherwise the interrupts are left registered, and when we come to load
the driver a second time, we get an Opps.
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
---
drivers/net/dsa/mv88e6xxx/chip.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c
index 3ba77067a3dc..9a5d786b4885 100644
--- a/drivers/net/dsa/mv88e6xxx/chip.c
+++ b/drivers/net/dsa/mv88e6xxx/chip.c
@@ -467,6 +467,8 @@ static int mv88e6xxx_irq_poll_setup(struct mv88e6xxx_chip *chip)
static void mv88e6xxx_irq_poll_free(struct mv88e6xxx_chip *chip)
{
+ mv88e6xxx_g1_irq_free_common(chip);
+
kthread_cancel_delayed_work_sync(&chip->irq_poll_work);
kthread_destroy_worker(chip->kworker);
}
--
2.16.2
^ permalink raw reply related
* [PATCH v2 net-next 0/2] Fixes to allow mv88e6xxx module to be reloaded
From: Andrew Lunn @ 2018-03-25 20:56 UTC (permalink / raw)
To: David Miller; +Cc: netdev, u.kleine-koenig, Andrew Lunn
As reported by Uwe Kleine-Künig, the interrupt trigger is first
configured by DT and then reconfigured to edge. This results in a
failure on EPROBE_DEFER, or if the module is unloaded and reloaded.
A second crash happens on module reload due to a missing call to the
common IRQ free code when using polled interrupts.
With these fixes in place, it becomes possible to load and unload the
kernel modules a few times without it crashing.
v2: Fix the ü in Künig a couple of times
Andrew Lunn (2):
net: dsa: mv88e6xxx: Use the DT IRQ trigger mode
net: dsa: mv88e6xxx: Call the common IRQ free code
drivers/net/dsa/mv88e6xxx/chip.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--
2.16.2
^ permalink raw reply
* Re: [PATCH] of_net: Implement of_get_nvmem_mac_address helper
From: Andrew Lunn @ 2018-03-25 21:04 UTC (permalink / raw)
To: Mike Looijmans
Cc: Florian Fainelli, netdev, linux-kernel, devicetree, robh+dt,
frowand.list
In-Reply-To: <d2dfee96-cd30-fa16-6c83-b55773e3aa91@topic.nl>
> I have no experience with Coccinelle though.
Hi Mike
I've very little either. But all the interactions i've had with
Coccinelle people have been very friendly and helpful. It could be, if
you can describe in words what you need help with, they can write the
script to do it.
Andrew
^ 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