* Re: Designing a safe RX-zero-copy Memory Model for Networking
From: Christoph Lameter @ 2016-12-15 16:38 UTC (permalink / raw)
To: Jesper Dangaard Brouer
Cc: Alexander Duyck, John Fastabend, David Miller, rppt, Netdev,
linux-mm, willemdebruijn.kernel, Björn Töpel,
magnus.karlsson, Mel Gorman, Tom Herbert, Brenden Blanco,
Tariq Toukan, Saeed Mahameed, Brandeburg, Jesse, METH,
Vlad Yasevich
In-Reply-To: <20161215092841.2f7065b5@redhat.com>
On Thu, 15 Dec 2016, Jesper Dangaard Brouer wrote:
> > It sounds like Christoph's RDMA approach might be the way to go.
>
> I'm getting more and more fond of Christoph's RDMA approach. I do
> think we will end-up with something close to that approach. I just
> wanted to get review on my idea first.
>
> IMHO the major blocker for the RDMA approach is not HW filters
> themselves, but a common API that applications can call to register
> what goes into the HW queues in the driver. I suspect it will be a
> long project agreeing between vendors. And agreeing on semantics.
Some of the methods from the RDMA subsystem (like queue pairs, the various
queues etc) could be extracted and used here. Multiple vendors already
support these features and some devices operate both in an RDMA and a
network stack mode. Having that all supported by the networks stack would
reduce overhead for those vendors.
Multiple new vendors are coming up in the RDMA subsystem because the
regular network stack does not have the right performance for high speed
networking. I would rather see them have a way to get that functionality
from the regular network stack. Please add some extensions so that the
RDMA style I/O can be made to work. Even the hardware of the new NICs is
already prepared to work with the data structures of the RDMA subsystem.
That provides an area of standardization where we could hook into but do
that properly and in a nice way in the context of main stream network
support.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH net] sctp: sctp_epaddr_lookup_transport should be protected by rcu_read_lock
From: Marcelo Ricardo Leitner @ 2016-12-15 16:43 UTC (permalink / raw)
To: Xin Long; +Cc: network dev, linux-sctp, davem, Neil Horman, Dmitry Vyukov
In-Reply-To: <eb70a1f54c102c728a5572f1aa2842940fc3f5a5.1481814055.git.lucien.xin@gmail.com>
On Thu, Dec 15, 2016 at 11:00:55PM +0800, Xin Long wrote:
> Since commit 7fda702f9315 ("sctp: use new rhlist interface on sctp transport
> rhashtable"), sctp has changed to use rhlist_lookup to look up transport, but
> rhlist_lookup doesn't call rcu_read_lock inside, unlike rhashtable_lookup_fast.
>
> It is called in sctp_epaddr_lookup_transport and sctp_addrs_lookup_transport.
> sctp_addrs_lookup_transport is always in the protection of rcu_read_lock(),
> as __sctp_lookup_association is called in rx path or sctp_lookup_association
> which are in the protection of rcu_read_lock() already.
>
> But sctp_epaddr_lookup_transport is called by sctp_endpoint_lookup_assoc, it
> doesn't call rcu_read_lock, which may cause "suspicious rcu_dereference_check
> usage' in __rhashtable_lookup.
>
> This patch is to fix it by adding rcu_read_lock in sctp_endpoint_lookup_assoc
> before calling sctp_epaddr_lookup_transport.
>
> Fixes: 7fda702f9315 ("sctp: use new rhlist interface on sctp transport rhashtable")
> Reported-by: Dmitry Vyukov <dvyukov@google.com>
> Signed-off-by: Xin Long <lucien.xin@gmail.com>
Acked-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
> ---
> net/sctp/endpointola.c | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/net/sctp/endpointola.c b/net/sctp/endpointola.c
> index 1f03065..410ddc1 100644
> --- a/net/sctp/endpointola.c
> +++ b/net/sctp/endpointola.c
> @@ -331,7 +331,9 @@ struct sctp_association *sctp_endpoint_lookup_assoc(
> * on this endpoint.
> */
> if (!ep->base.bind_addr.port)
> - goto out;
> + return NULL;
> +
> + rcu_read_lock();
> t = sctp_epaddr_lookup_transport(ep, paddr);
> if (!t)
> goto out;
> @@ -339,6 +341,7 @@ struct sctp_association *sctp_endpoint_lookup_assoc(
> *transport = t;
> asoc = t->asoc;
> out:
> + rcu_read_unlock();
> return asoc;
> }
>
> --
> 2.1.0
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sctp" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCH] net: wan: Use dma_pool_zalloc
From: Joe Perches @ 2016-12-15 16:48 UTC (permalink / raw)
To: Souptick Joarder, Krzysztof Hałasa, netdev; +Cc: Rameshwar Sahu
In-Reply-To: <CAFqt6zaHJ_YP-inLm8_XRDrX8FtcU86NqYG=+DRn9-Y3zR4cyg@mail.gmail.com>
On Thu, 2016-12-15 at 10:41 +0530, Souptick Joarder wrote:
> On Mon, Dec 12, 2016 at 10:12 AM, Souptick Joarder <jrdr.linux@gmail.com> wrote:
> > On Fri, Dec 9, 2016 at 6:33 PM, Krzysztof Hałasa <khalasa@piap.pl> wrote:
> > > Souptick Joarder <jrdr.linux@gmail.com> writes:
> > >
> > > > We should use dma_pool_zalloc instead of dma_pool_alloc/memset
[]
> > > > diff --git a/drivers/net/wan/ixp4xx_hss.c b/drivers/net/wan/ixp4xx_hss.c
[]
> > > > @@ -976,10 +976,9 @@ static int init_hdlc_queues(struct port *port)
> > > > return -ENOMEM;
> > > > }
> > > >
> > > > - if (!(port->desc_tab = dma_pool_alloc(dma_pool, GFP_KERNEL,
> > > > - &port->desc_tab_phys)))
> > > > + if (!(port->desc_tab = dma_pool_zalloc(dma_pool, GFP_KERNEL,
> > > > + &port->desc_tab_phys)))
> > > > return -ENOMEM;
> > > > - memset(port->desc_tab, 0, POOL_ALLOC_SIZE);
> > > > memset(port->rx_buff_tab, 0, sizeof(port->rx_buff_tab)); /* tables */
> > > > memset(port->tx_buff_tab, 0, sizeof(port->tx_buff_tab));
> > >
> > > This look fine, feel free to send it to the netdev mailing list for
> > > inclusion.
> >
> > Including netdev mailing list based as requested.
> > > Acked-by: Krzysztof Halasa <khalasa@piap.pl>
[]
> Any comment on this patch ?
Shouldn't the one in drivers/net/ethernet/xscale/ixp4xx_eth.c
also be changed?
^ permalink raw reply
* Re: [PATCH net] sctp: sctp_transport_lookup_process should rcu_read_unlock when transport is null
From: Marcelo Ricardo Leitner @ 2016-12-15 16:48 UTC (permalink / raw)
To: Xin Long; +Cc: network dev, linux-sctp, davem, Neil Horman
In-Reply-To: <3d4f0205d5b5c64d372dffb37602f48e4a173612.1481814352.git.lucien.xin@gmail.com>
On Thu, Dec 15, 2016 at 11:05:52PM +0800, Xin Long wrote:
> Prior to this patch, sctp_transport_lookup_process didn't rcu_read_unlock
> when it failed to find a transport by sctp_addrs_lookup_transport.
>
> This patch is to fix it by moving up rcu_read_unlock right before checking
> transport and also to remove the out path.
>
> Fixes: 1cceda784980 ("sctp: fix the issue sctp_diag uses lock_sock in rcu_read_lock")
> Signed-off-by: Xin Long <lucien.xin@gmail.com>
Acked-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
> ---
> net/sctp/socket.c | 7 +++----
> 1 file changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/net/sctp/socket.c b/net/sctp/socket.c
> index d5f4b4a..318c678 100644
> --- a/net/sctp/socket.c
> +++ b/net/sctp/socket.c
> @@ -4472,18 +4472,17 @@ int sctp_transport_lookup_process(int (*cb)(struct sctp_transport *, void *),
> const union sctp_addr *paddr, void *p)
> {
> struct sctp_transport *transport;
> - int err = -ENOENT;
> + int err;
>
> rcu_read_lock();
> transport = sctp_addrs_lookup_transport(net, laddr, paddr);
> + rcu_read_unlock();
> if (!transport)
> - goto out;
> + return -ENOENT;
>
> - rcu_read_unlock();
> err = cb(transport, p);
> sctp_transport_put(transport);
>
> -out:
> return err;
> }
> EXPORT_SYMBOL_GPL(sctp_transport_lookup_process);
> --
> 2.1.0
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sctp" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [RFC v2 00/10] HFI Virtual Network Interface Controller (VNIC)
From: Jason Gunthorpe @ 2016-12-15 16:56 UTC (permalink / raw)
To: Vishwanathapura, Niranjana
Cc: dledford, linux-rdma, netdev, dennis.dalessandro, ira.weiny
In-Reply-To: <1481788782-89964-1-git-send-email-niranjana.vishwanathapura@intel.com>
On Wed, Dec 14, 2016 at 11:59:32PM -0800, Vishwanathapura, Niranjana wrote:
> create mode 100644 drivers/infiniband/sw/intel/hfi_vnic/Kconfig
> create mode 100644 drivers/infiniband/sw/intel/hfi_vnic/Makefile
Stil NAK on these paths, I already explained why 'sw' is totally
unsuitable. Put it in drivers/net or drivers/infiniband/ulp
Jason
^ permalink raw reply
* Re: [RFC v2 03/10] IB/hfi-vnic: Virtual Network Interface Controller (VNIC) netdev
From: Jason Gunthorpe @ 2016-12-15 17:01 UTC (permalink / raw)
To: Vishwanathapura, Niranjana
Cc: dledford-H+wXaHxf7aLQT0dZR+AlfA,
linux-rdma-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
dennis.dalessandro-ral2JQCrhuEAvxtiuMwx3w,
ira.weiny-ral2JQCrhuEAvxtiuMwx3w, Sadanand Warrier, Sudeep Dutt,
Tanya K Jajodia, Andrzej Kacprowski
In-Reply-To: <1481788782-89964-4-git-send-email-niranjana.vishwanathapura-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
On Wed, Dec 14, 2016 at 11:59:35PM -0800, Vishwanathapura, Niranjana wrote:
> +/**
> + * union hfi_vnic_bypass_hdr - VNIC bypass header
> + * @slid: source lid
> + * @length: length of packet
> + * @becn: backward explicit congestion notification
> + * @dlid: destination lid
> + * @sc: service class
> + * @fecn: forward explicit congestion notification
> + * @l2: L2 type (2=16B)
> + * @lt: link transfer field
> + * @l4: L4 type
> + * @slid_high: upper 4 bits of source lid
> + * @dlid_high: upper 4 bits of destination lid
> + * @pkey: partition key
> + * @entropy: entropy
> + * @age: packet age
> + * @l4_hdr: L4 header
> + */
> +union hfi_vnic_bypass_hdr {
> + struct {
> + struct {
> + uint64_t slid : 20;
> + uint64_t length : 11;
> + uint64_t becn : 1;
> + uint64_t dlid : 20;
> + uint64_t sc : 5;
> + uint64_t rsvd : 3;
> + uint64_t fecn : 1;
> + uint64_t l2 : 2;
> + uint64_t lt : 1;
> + };
> + struct {
> + uint64_t l4 : 8;
> + uint64_t slid_high : 4;
> + uint64_t dlid_high : 4;
> + uint64_t pkey : 16;
> + uint64_t entropy : 16;
> + uint64_t age : 8;
> + uint64_t rsvd1 : 8;
> + };
> + struct {
> + uint32_t rsvd2 : 16;
> + uint32_t l4_hdr : 16;
> + };
> + } __packed;
> + u32 dw[5];
> +};
This isn't going to work on BE, please fix it.
> +/**
> + * struct __hfi_vesw_info - HFI vnic virtual switch info
> + */
> +struct __hfi_vesw_info {
> + u16 fabric_id;
> + u16 vesw_id;
> +
> + u8 rsvd0[6];
> + u16 def_port_mask;
> +
> + u8 rsvd1[2];
> + u16 pkey;
> +
> + u8 rsvd2[4];
> + u32 u_mcast_dlid;
> + u32 u_ucast_dlid[HFI_VESW_MAX_NUM_DEF_PORT];
> +
> + u8 rsvd3[44];
> + u16 eth_mtu[HFI_VNIC_MAX_NUM_PCP];
> + u16 eth_mtu_non_vlan;
> + u8 rsvd4[2];
> +} __packed;
This goes on the network too? Also looks like it has endian problems.
Ditto for all the __packed structures.
> +#define v_dbg(format, arg...) \
> + netdev_dbg(adapter->netdev, format, ## arg)
> +#define v_err(format, arg...) \
> + netdev_err(adapter->netdev, format, ## arg)
> +#define v_info(format, arg...) \
> + netdev_info(adapter->netdev, format, ## arg)
> +#define v_warn(format, arg...) \
> + netdev_warn(adapter->netdev, format, ## arg)
Relies on an 'adapter' local varable?? Ugly.
Jason
--
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: [RFC v2 00/10] HFI Virtual Network Interface Controller (VNIC)
From: Jason Gunthorpe @ 2016-12-15 17:07 UTC (permalink / raw)
To: Doug Ledford
Cc: ira.weiny, Leon Romanovsky, Jeff Kirsher, David S. Miller,
Vishwanathapura, Niranjana, linux-rdma-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
dennis.dalessandro-ral2JQCrhuEAvxtiuMwx3w
In-Reply-To: <380b05bf-a18e-1f20-7e8e-10b61f77dec7-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
On Thu, Dec 15, 2016 at 11:28:06AM -0500, Doug Ledford wrote:
> 1) Since your intent is to make this work with multiple versions of the
> hfi drivers, I disagree with Jason that just because there is only one
> driver today that we should keep it simple. Design it right from the
> beginning of multi driver is your intent is, IMO, a better way to go.
> You'll work out the bugs in the initial implementation and when it comes
> time to add the second driver, things will go much more smoothly.
If that is your position then this should be a straight up IB ULP that
works with any IB hardware.
There is nothing HFI specific about it except for the
micro-optimization of pushing packets via SDMA instead of post_send,
and that same micro optimization probably applies to ipoib.
In other words, lets see the first version as a straight ULP with no
special HFI hooks, then we can discuss how best to micro optimize it
for HFI SDMA.
Jason
--
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] net: sfc: use new api ethtool_{get|set}_link_ksettings
From: Bert Kenward @ 2016-12-15 17:18 UTC (permalink / raw)
To: Philippe Reynes, linux-net-drivers, ecree; +Cc: netdev, linux-kernel
In-Reply-To: <1481757173-16000-1-git-send-email-tremyfr@gmail.com>
On 14/12/16 23:12, Philippe Reynes wrote:
> The ethtool api {get|set}_settings is deprecated.
> We move this driver to new api {get|set}_link_ksettings.
>
> Signed-off-by: Philippe Reynes <tremyfr@gmail.com>
Tested-by: Bert Kenward <bkenward@solarflare.com>
Acked-by: Bert Kenward <bkenward@solarflare.com>
^ permalink raw reply
* Re: [PATCH net-next 1/3] net:dsa:mv88e6xxx: use hashtable to store multicast entries
From: Vivien Didelot @ 2016-12-15 17:21 UTC (permalink / raw)
To: Volodymyr Bendiuga, Andrew Lunn
Cc: Volodymyr Bendiuga, Florian Fainelli, netdev, Volodymyr Bendiuga,
John Crispin
In-Reply-To: <CABHmqqDpiN2kwkTgrM8Qu8EEx3Sjk2yVBy8QQAJppGfJ6-MV5Q@mail.gmail.com>
Hi Volodymyr,
Volodymyr Bendiuga <volodymyr.bendiuga@gmail.com> writes:
> Hi Andrew,
>
> I have tested the approach you wrote in previous mails, the one
> with setting next.mac to address we are looking for -1. It seems
> to be as slow as the original implementation, unfortunately.
Hum, that is what I was expecting... The ATU GetNext operation
(alongside an ether_addr_equal() call) should be quite fast.
> We use 6097 and 6352 chips, and both of them can not do any port
> filtering in hardware for fdb dump operation. Seems like they would
> benefit from cache. But I am not sure about other switches.
>
> Does anyone know about such feature in other switches?
Marvell switches cannot filter ATU entries for a specific port, they
contain a port vector.
I guess Florian might answer for Broadcom switches, and John might
answer for Qualcomm switches.
In all cases *if caching is really needed*, I think it won't hurt to do
it in DSA core even if a switch support FDB dump operations on a
per-port basis, as Andrew mentioned.
Thanks,
Vivien
^ permalink raw reply
* RE: [RFC v2 03/10] IB/hfi-vnic: Virtual Network Interface Controller (VNIC) netdev
From: Hefty, Sean @ 2016-12-15 17:21 UTC (permalink / raw)
To: Jason Gunthorpe, Vishwanathapura, Niranjana
Cc: dledford@redhat.com, linux-rdma@vger.kernel.org,
netdev@vger.kernel.org, Dalessandro, Dennis, Weiny, Ira,
Warrier, Sadanand, Dutt, Sudeep, Jajodia, Tanya K,
Kacprowski, Andrzej
In-Reply-To: <20161215170109.GC3264@obsidianresearch.com>
> This goes on the network too? Also looks like it has endian problems.
I don't think OPA supports BE systems, and I think it uses LE on the wire for at least some portions of its protocol.
^ permalink raw reply
* Re: [RFC v2 03/10] IB/hfi-vnic: Virtual Network Interface Controller (VNIC) netdev
From: Jason Gunthorpe @ 2016-12-15 17:24 UTC (permalink / raw)
To: Hefty, Sean
Cc: Vishwanathapura, Niranjana, dledford@redhat.com,
linux-rdma@vger.kernel.org, netdev@vger.kernel.org,
Dalessandro, Dennis, Weiny, Ira, Warrier, Sadanand, Dutt, Sudeep,
Jajodia, Tanya K, Kacprowski, Andrzej
In-Reply-To: <1828884A29C6694DAF28B7E6B8A82373AB0C9556@ORSMSX109.amr.corp.intel.com>
On Thu, Dec 15, 2016 at 05:21:05PM +0000, Hefty, Sean wrote:
> > This goes on the network too? Also looks like it has endian problems.
>
> I don't think OPA supports BE systems, and I think it uses LE on the
> wire for at least some portions of its protocol.
This is a linux driver for a PCI device.
It needs to support big endian systems, that is how we do things in
Linux.
If it uses LE on the wire then mark with __le and make it sparse clean.
Do not use bitfields without providing a BE version of the bitfield.
Jason
^ permalink raw reply
* Re: [RFC v2 03/10] IB/hfi-vnic: Virtual Network Interface Controller (VNIC) netdev
From: Christoph Hellwig @ 2016-12-15 17:26 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Hefty, Sean, Vishwanathapura, Niranjana, dledford@redhat.com,
linux-rdma@vger.kernel.org, netdev@vger.kernel.org,
Dalessandro, Dennis, Weiny, Ira, Warrier, Sadanand, Dutt, Sudeep,
Jajodia, Tanya K, Kacprowski, Andrzej
In-Reply-To: <20161215172437.GA11387@obsidianresearch.com>
On Thu, Dec 15, 2016 at 10:24:37AM -0700, Jason Gunthorpe wrote:
> Do not use bitfields without providing a BE version of the bitfield.
Do not use bitfields ever for protocol defintions, period.
^ permalink raw reply
* Re: [PATCH 5/8] linux: drop __bitwise__ everywhere
From: Krzysztof Kozlowski @ 2016-12-15 17:28 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: linux-kernel, Kukjin Kim, Krzysztof Kozlowski,
Javier Martinez Canillas, Russell King, Alasdair Kergon,
Mike Snitzer, dm-devel, Shaohua Li, Johannes Berg,
Emmanuel Grumbach, Luca Coelho, Intel Linux Wireless, Kalle Valo,
Greg Kroah-Hartman, Jiri Slaby, Lee Duncan, Chris Leech,
James E.J. Bottomley, Martin K. Petersen, Nicholas A. Bellinger,
Jason Wang, Alexander Aring
In-Reply-To: <1481778865-27667-6-git-send-email-mst@redhat.com>
On Thu, Dec 15, 2016 at 07:15:20AM +0200, Michael S. Tsirkin wrote:
> __bitwise__ used to mean "yes, please enable sparse checks
> unconditionally", but now that we dropped __CHECK_ENDIAN__
> __bitwise is exactly the same.
> There aren't many users, replace it by __bitwise everywhere.
>
> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> ---
> arch/arm/plat-samsung/include/plat/gpio-cfg.h | 2 +-
> drivers/md/dm-cache-block-types.h | 6 +++---
> drivers/net/ethernet/sun/sunhme.h | 2 +-
> drivers/net/wireless/intel/iwlwifi/iwl-fw-file.h | 4 ++--
> include/linux/mmzone.h | 2 +-
> include/linux/serial_core.h | 4 ++--
> include/linux/types.h | 4 ++--
> include/scsi/iscsi_proto.h | 2 +-
> include/target/target_core_base.h | 2 +-
> include/uapi/linux/virtio_types.h | 6 +++---
> net/ieee802154/6lowpan/6lowpan_i.h | 2 +-
> net/mac80211/ieee80211_i.h | 4 ++--
> 12 files changed, 20 insertions(+), 20 deletions(-)
>
> diff --git a/arch/arm/plat-samsung/include/plat/gpio-cfg.h b/arch/arm/plat-samsung/include/plat/gpio-cfg.h
> index 21391fa..e55d1f5 100644
> --- a/arch/arm/plat-samsung/include/plat/gpio-cfg.h
> +++ b/arch/arm/plat-samsung/include/plat/gpio-cfg.h
> @@ -26,7 +26,7 @@
>
> #include <linux/types.h>
>
> -typedef unsigned int __bitwise__ samsung_gpio_pull_t;
> +typedef unsigned int __bitwise samsung_gpio_pull_t;
>
> /* forward declaration if gpio-core.h hasn't been included */
> struct samsung_gpio_chip;
For plat-samsung:
Acked-by: Krzysztof Kozlowski <krzk@kernel.org>
Best regards,
Krzysztof
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH net-next 1/3] net:dsa:mv88e6xxx: use hashtable to store multicast entries
From: Florian Fainelli @ 2016-12-15 17:32 UTC (permalink / raw)
To: Vivien Didelot, Volodymyr Bendiuga, Andrew Lunn
Cc: Volodymyr Bendiuga, netdev, Volodymyr Bendiuga, John Crispin
In-Reply-To: <87eg19hzw1.fsf@weeman.i-did-not-set--mail-host-address--so-tickle-me>
On 12/15/2016 09:21 AM, Vivien Didelot wrote:
> Hi Volodymyr,
>
> Volodymyr Bendiuga <volodymyr.bendiuga@gmail.com> writes:
>
>> Hi Andrew,
>>
>> I have tested the approach you wrote in previous mails, the one
>> with setting next.mac to address we are looking for -1. It seems
>> to be as slow as the original implementation, unfortunately.
>
> Hum, that is what I was expecting... The ATU GetNext operation
> (alongside an ether_addr_equal() call) should be quite fast.
>
>> We use 6097 and 6352 chips, and both of them can not do any port
>> filtering in hardware for fdb dump operation. Seems like they would
>> benefit from cache. But I am not sure about other switches.
>>
>> Does anyone know about such feature in other switches?
>
> Marvell switches cannot filter ATU entries for a specific port, they
> contain a port vector.
>
> I guess Florian might answer for Broadcom switches, and John might
> answer for Qualcomm switches.
For Broadcom switches, we use the ARL search and then apply software
filtering to discard entries that are not for the target port bridge fdb
show was called with.
>
> In all cases *if caching is really needed*, I think it won't hurt to do
> it in DSA core even if a switch support FDB dump operations on a
> per-port basis, as Andrew mentioned.
Agreed, and there does not appear to be any need to new dsa_switch_ops
operations to be introduced?
--
Florian
^ permalink raw reply
* Re: [PATCH iproute2 v2 1/3] ifstat: Add extended statistics to ifstat
From: Stephen Hemminger @ 2016-12-15 17:33 UTC (permalink / raw)
To: Nogah Frankel; +Cc: netdev, roopa, jiri, eladr, yotamg, idosch, ogerlitz
In-Reply-To: <1481806845-63384-2-git-send-email-nogahf@mellanox.com>
On Thu, 15 Dec 2016 15:00:43 +0200
Nogah Frankel <nogahf@mellanox.com> wrote:
> Extended stats are part of the RTM_GETSTATS method. This patch adds them
> to ifstat.
> While extended stats can come in many forms, we support only the
> rtnl_link_stats64 struct for them (which is the 64 bits version of struct
> rtnl_link_stats).
> We support stats in the main nesting level, or one lower.
> The extension can be called by its name or any shorten of it. If there is
> more than one matched, the first one will be picked.
>
> To get the extended stats the flag -x <stats type> is used.
>
> Signed-off-by: Nogah Frankel <nogahf@mellanox.com>
> Reviewed-by: Jiri Pirko <jiri@mellanox.com>
> ---
> misc/ifstat.c | 161 ++++++++++++++++++++++++++++++++++++++++++++++++++++------
> 1 file changed, 146 insertions(+), 15 deletions(-)
>
> diff --git a/misc/ifstat.c b/misc/ifstat.c
> index 92d67b0..d17ae21 100644
> --- a/misc/ifstat.c
> +++ b/misc/ifstat.c
> @@ -35,6 +35,7 @@
>
> #include <SNAPSHOT.h>
>
> +#include "utils.h"
> int dump_zeros;
> int reset_history;
> int ignore_history;
Minor nit, please cleanup include order here (original code was wrong).
Standard practice is:
#include system headers (like stdio.h etc)
#include "xxx.h" local headers.
Should be:
#include <getopt.h>
#include <linux/if.h>
#include <linux/if_link.h>
#include "json_writer.h"
#include "libnetlink.h"
#include "utils.h"
#include "SNAPSHOT.h"
^ permalink raw reply
* Re: [RFC v2 02/10] IB/hfi-vnic: Virtual Network Interface Controller (VNIC) interface
From: Stephen Hemminger @ 2016-12-15 17:36 UTC (permalink / raw)
To: Vishwanathapura, Niranjana
Cc: dledford, linux-rdma, netdev, dennis.dalessandro, ira.weiny
In-Reply-To: <20161215085349.GA90068@knc-06.sc.intel.com>
On Thu, 15 Dec 2016 00:53:49 -0800
"Vishwanathapura, Niranjana" <niranjana.vishwanathapura@intel.com> wrote:
> On Wed, Dec 14, 2016 at 11:59:34PM -0800, Vishwanathapura, Niranjana wrote:
> >+
> >+static inline bool is_hfi_ibdev(struct ib_device *ibdev)
> >+{
> >+ return !memcmp(ibdev->name, "hfi", 3);
> >+}
>
> I am thinking of adding a device capability flag to indicate HFI VNIC capabilty
> instead of relying on the device name as above to identify a hfi ib deice.
> Any comments? Probably it can be addressed by a separate patch later.
>
> Niranjana
>
> >
Agreed. device name can change at anytime.
^ permalink raw reply
* Re: [PATCH net-next 1/3] net:dsa:mv88e6xxx: use hashtable to store multicast entries
From: John Crispin @ 2016-12-15 17:47 UTC (permalink / raw)
To: Vivien Didelot, Volodymyr Bendiuga, Andrew Lunn
Cc: Volodymyr Bendiuga, Florian Fainelli, netdev, Volodymyr Bendiuga
In-Reply-To: <87eg19hzw1.fsf@weeman.i-did-not-set--mail-host-address--so-tickle-me>
On 15/12/2016 18:21, Vivien Didelot wrote:
> Hi Volodymyr,
>
> Volodymyr Bendiuga <volodymyr.bendiuga@gmail.com> writes:
>
>> Hi Andrew,
>>
>> I have tested the approach you wrote in previous mails, the one
>> with setting next.mac to address we are looking for -1. It seems
>> to be as slow as the original implementation, unfortunately.
>
> Hum, that is what I was expecting... The ATU GetNext operation
> (alongside an ether_addr_equal() call) should be quite fast.
>
>> We use 6097 and 6352 chips, and both of them can not do any port
>> filtering in hardware for fdb dump operation. Seems like they would
>> benefit from cache. But I am not sure about other switches.
>>
>> Does anyone know about such feature in other switches?
>
> Marvell switches cannot filter ATU entries for a specific port, they
> contain a port vector.
>
> I guess Florian might answer for Broadcom switches, and John might
> answer for Qualcomm switches.
>
> In all cases *if caching is really needed*, I think it won't hurt to do
> it in DSA core even if a switch support FDB dump operations on a
> per-port basis, as Andrew mentioned.
QCA switches allow defining a port mask in a fdb search/iterate
operation. just had a look in the brcm driver and it filters in software
John
^ permalink raw reply
* Re: [PATCH net-next 1/3] net:dsa:mv88e6xxx: use hashtable to store multicast entries
From: Vivien Didelot @ 2016-12-15 17:50 UTC (permalink / raw)
To: Florian Fainelli, Volodymyr Bendiuga, Andrew Lunn
Cc: Volodymyr Bendiuga, netdev, Volodymyr Bendiuga, John Crispin
In-Reply-To: <be3b69b7-b6a3-a939-cf77-c62e5a1fe719@gmail.com>
Florian Fainelli <f.fainelli@gmail.com> writes:
>> In all cases *if caching is really needed*, I think it won't hurt to do
>> it in DSA core even if a switch support FDB dump operations on a
>> per-port basis, as Andrew mentioned.
>
> Agreed, and there does not appear to be any need to new dsa_switch_ops
> operations to be introduced?
Nope.
^ permalink raw reply
* [PATCH net] r6040: move spinlock in r6040_close as SOFTIRQ-unsafe lock order detected
From: Manuel Bessler @ 2016-12-15 17:46 UTC (permalink / raw)
To: netdev; +Cc: Manuel Bessler
'ifconfig eth0 down' makes r6040_close() trigger:
INFO: HARDIRQ-safe -> HARDIRQ-unsafe lock order detected
Fixed by moving calls to phy_stop(), napi_disable(), netif_stop_queue()
to outside of the module's private spin_lock_irq block.
Found on a Versalogic Tomcat SBC with a Vortex86 SoC
s1660e_5150:~# sudo ifconfig eth0 down
[ 61.306415] ======================================================
[ 61.306415] [ INFO: SOFTIRQ-safe -> SOFTIRQ-unsafe lock order detected ]
[ 61.306415] 4.9.0-gb898d2d-manuel #1 Not tainted
[ 61.306415] ------------------------------------------------------
[ 61.306415] ifconfig/449 [HC0[0]:SC0[0]:HE0:SE1] is trying to acquire:
[ 61.306415] (&dev->lock){+.+...}, at: [<c1336276>] phy_stop+0x16/0x80
[ 61.306415] and this task is already holding:
[ 61.306415] (&(&lp->lock)->rlock){+.-...}, at: [<d0934c84>] r6040_close+0x24/0x230 [r6040]
which would create a new lock dependency:
[ 61.306415] (&(&lp->lock)->rlock){+.-...} -> (&dev->lock){+.+...}
[ 61.306415] but this new dependency connects a SOFTIRQ-irq-safe lock:
[ 61.306415] (&(&lp->lock)->rlock){+.-...}
[ 61.306415] ... which became SOFTIRQ-irq-safe at:
[ 61.306415] [ 61.306415] [<c1075bc5>] __lock_acquire+0x555/0x1770
[ 61.306415] [ 61.306415] [<c107717c>] lock_acquire+0x7c/0x150
[ 61.306415] [ 61.306415] [<c14bb334>] _raw_spin_lock_irqsave+0x24/0x40
[ 61.306415] [ 61.306415] [<d0934ac0>] r6040_start_xmit+0x30/0x1d0 [r6040]
[ 61.306415] [ 61.306415] [<c13a7d4d>] dev_hard_start_xmit+0x9d/0x2d0
[ 61.306415] [ 61.306415] [<c13c8a38>] sch_direct_xmit+0xa8/0x140
[ 61.306415] [ 61.306415] [<c13a8436>] __dev_queue_xmit+0x416/0x780
[ 61.306415] [ 61.306415] [<c13a87aa>] dev_queue_xmit+0xa/0x10
[ 61.306415] [ 61.306415] [<c13b4837>] neigh_resolve_output+0x147/0x220
[ 61.306415] [ 61.306415] [<c144541b>] ip6_finish_output2+0x2fb/0x910
[ 61.306415] [ 61.306415] [<c14494e6>] ip6_finish_output+0xa6/0x1a0
[ 61.306415] [ 61.306415] [<c1449635>] ip6_output+0x55/0x320
[ 61.306415] [ 61.306415] [<c146f4d2>] mld_sendpack+0x352/0x560
[ 61.306415] [ 61.306415] [<c146fe55>] mld_ifc_timer_expire+0x155/0x280
[ 61.306415] [ 61.306415] [<c108b081>] call_timer_fn+0x81/0x270
[ 61.306415] [ 61.306415] [<c108b331>] expire_timers+0xc1/0x180
[ 61.306415] [ 61.306415] [<c108b4f7>] run_timer_softirq+0x77/0x150
[ 61.306415] [ 61.306415] [<c1043d04>] __do_softirq+0xb4/0x3d0
[ 61.306415] [ 61.306415] [<c101a15c>] do_softirq_own_stack+0x1c/0x30
[ 61.306415] [ 61.306415] [<c104416e>] irq_exit+0x8e/0xa0
[ 61.306415] [ 61.306415] [<c1019d31>] do_IRQ+0x51/0x100
[ 61.306415] [ 61.306415] [<c14bc176>] common_interrupt+0x36/0x40
[ 61.306415] [ 61.306415] [<c1134928>] set_root+0x68/0xf0
[ 61.306415] [ 61.306415] [<c1136120>] path_init+0x400/0x640
[ 61.306415] [ 61.306415] [<c11386bf>] path_lookupat+0xf/0xe0
[ 61.306415] [ 61.306415] [<c1139ebc>] filename_lookup+0x6c/0x100
[ 61.306415] [ 61.306415] [<c1139fd5>] user_path_at_empty+0x25/0x30
[ 61.306415] [ 61.306415] [<c11298c6>] SyS_faccessat+0x86/0x1e0
[ 61.306415] [ 61.306415] [<c1129a30>] SyS_access+0x10/0x20
[ 61.306415] [ 61.306415] [<c100179f>] do_int80_syscall_32+0x3f/0x110
[ 61.306415] [ 61.306415] [<c14bba3f>] restore_all+0x0/0x61
[ 61.306415]
[ 61.306415] to a SOFTIRQ-irq-unsafe lock:
[ 61.306415] (&dev->lock){+.+...}
[ 61.306415] ... which became SOFTIRQ-irq-unsafe at:
[ 61.306415] ...[ 61.306415]
[ 61.306415] [<c1075c0c>] __lock_acquire+0x59c/0x1770
[ 61.306415] [ 61.306415] [<c107717c>] lock_acquire+0x7c/0x150
[ 61.306415] [ 61.306415] [<c14b7add>] mutex_lock_nested+0x2d/0x4a0
[ 61.306415] [ 61.306415] [<c133747d>] phy_probe+0x4d/0xc0
[ 61.306415] [ 61.306415] [<c1338afe>] phy_attach_direct+0xbe/0x190
[ 61.306415] [ 61.306415] [<c1338ca7>] phy_connect_direct+0x17/0x60
[ 61.306415] [ 61.306415] [<c1338d23>] phy_connect+0x33/0x70
[ 61.306415] [ 61.306415] [<d09357a0>] r6040_init_one+0x3a0/0x500 [r6040]
[ 61.306415] [ 61.306415] [<c12a78c7>] pci_device_probe+0x77/0xd0
[ 61.306415] [ 61.306415] [<c12f5e15>] driver_probe_device+0x145/0x280
[ 61.306415] [ 61.306415] [<c12f5fd9>] __driver_attach+0x89/0x90
[ 61.306415] [ 61.306415] [<c12f43ef>] bus_for_each_dev+0x4f/0x80
[ 61.306415] [ 61.306415] [<c12f5954>] driver_attach+0x14/0x20
[ 61.306415] [ 61.306415] [<c12f55b7>] bus_add_driver+0x197/0x210
[ 61.306415] [ 61.306415] [<c12f6a21>] driver_register+0x51/0xd0
[ 61.306415] [ 61.306415] [<c12a6955>] __pci_register_driver+0x45/0x50
[ 61.306415] [ 61.306415] [<d0938017>] 0xd0938017
[ 61.306415] [ 61.306415] [<c100043f>] do_one_initcall+0x2f/0x140
[ 61.306415] [ 61.306415] [<c10e48c0>] do_init_module+0x4a/0x19b
[ 61.306415] [ 61.306415] [<c10a680e>] load_module+0x1b2e/0x2070
[ 61.306415] [ 61.306415] [<c10a6eb9>] SyS_finit_module+0x69/0x80
[ 61.306415] [ 61.306415] [<c100179f>] do_int80_syscall_32+0x3f/0x110
[ 61.306415] [ 61.306415] [<c14bba3f>] restore_all+0x0/0x61
[ 61.306415]
[ 61.306415] other info that might help us debug this:
[ 61.306415]
[ 61.306415] Possible interrupt unsafe locking scenario:
[ 61.306415]
[ 61.306415] CPU0 CPU1
[ 61.306415] ---- ----
[ 61.306415] lock(&dev->lock);
[ 61.306415] local_irq_disable();
[ 61.306415] lock(&(&lp->lock)->rlock);
[ 61.306415] lock(&dev->lock);
[ 61.306415] <Interrupt>
[ 61.306415] lock(&(&lp->lock)->rlock);
[ 61.306415]
[ 61.306415] *** DEADLOCK ***
[ 61.306415]
[ 61.306415] 2 locks held by ifconfig/449:
[ 61.306415] #0: (rtnl_mutex){+.+.+.}, at: [<c13b68ef>] rtnl_lock+0xf/0x20
[ 61.306415] #1: (&(&lp->lock)->rlock){+.-...}, at: [<d0934c84>] r6040_close+0x24/0x230 [r6040]
[ 61.306415]
[ 61.306415] the dependencies between SOFTIRQ-irq-safe lock and the holding lock:
[ 61.306415] -> (&(&lp->lock)->rlock){+.-...} ops: 3049 {
[ 61.306415] HARDIRQ-ON-W at:
[ 61.306415] [ 61.306415] [<c1075be7>] __lock_acquire+0x577/0x1770
[ 61.306415] [ 61.306415] [<c107717c>] lock_acquire+0x7c/0x150
[ 61.306415] [ 61.306415] [<c14bb21b>] _raw_spin_lock+0x1b/0x30
[ 61.306415] [ 61.306415] [<d09343cc>] r6040_poll+0x2c/0x330 [r6040]
[ 61.306415] [ 61.306415] [<c13a5577>] net_rx_action+0x197/0x340
[ 61.306415] [ 61.306415] [<c1043d04>] __do_softirq+0xb4/0x3d0
[ 61.306415] [ 61.306415] [<c1044037>] run_ksoftirqd+0x17/0x40
[ 61.306415] [ 61.306415] [<c105fe91>] smpboot_thread_fn+0x141/0x180
[ 61.306415] [ 61.306415] [<c105c84e>] kthread+0xde/0x110
[ 61.306415] [ 61.306415] [<c14bb949>] ret_from_fork+0x19/0x30
[ 61.306415] IN-SOFTIRQ-W at:
[ 61.306415] [ 61.306415] [<c1075bc5>] __lock_acquire+0x555/0x1770
[ 61.306415] [ 61.306415] [<c107717c>] lock_acquire+0x7c/0x150
[ 61.306415] [ 61.306415] [<c14bb334>] _raw_spin_lock_irqsave+0x24/0x40
[ 61.306415] [ 61.306415] [<d0934ac0>] r6040_start_xmit+0x30/0x1d0 [r6040]
[ 61.306415] [ 61.306415] [<c13a7d4d>] dev_hard_start_xmit+0x9d/0x2d0
[ 61.306415] [ 61.306415] [<c13c8a38>] sch_direct_xmit+0xa8/0x140
[ 61.306415] [ 61.306415] [<c13a8436>] __dev_queue_xmit+0x416/0x780
[ 61.306415] [ 61.306415] [<c13a87aa>] dev_queue_xmit+0xa/0x10
[ 61.306415] [ 61.306415] [<c13b4837>] neigh_resolve_output+0x147/0x220
[ 61.306415] [ 61.306415] [<c144541b>] ip6_finish_output2+0x2fb/0x910
[ 61.306415] [ 61.306415] [<c14494e6>] ip6_finish_output+0xa6/0x1a0
[ 61.306415] [ 61.306415] [<c1449635>] ip6_output+0x55/0x320
[ 61.306415] [ 61.306415] [<c146f4d2>] mld_sendpack+0x352/0x560
[ 61.306415] [ 61.306415] [<c146fe55>] mld_ifc_timer_expire+0x155/0x280
[ 61.306415] [ 61.306415] [<c108b081>] call_timer_fn+0x81/0x270
[ 61.306415] [ 61.306415] [<c108b331>] expire_timers+0xc1/0x180
[ 61.306415] [ 61.306415] [<c108b4f7>] run_timer_softirq+0x77/0x150
[ 61.306415] [ 61.306415] [<c1043d04>] __do_softirq+0xb4/0x3d0
[ 61.306415] [ 61.306415] [<c101a15c>] do_softirq_own_stack+0x1c/0x30
[ 61.306415] [ 61.306415] [<c104416e>] irq_exit+0x8e/0xa0
[ 61.306415] [ 61.306415] [<c1019d31>] do_IRQ+0x51/0x100
[ 61.306415] [ 61.306415] [<c14bc176>] common_interrupt+0x36/0x40
[ 61.306415] [ 61.306415] [<c1134928>] set_root+0x68/0xf0
[ 61.306415] [ 61.306415] [<c1136120>] path_init+0x400/0x640
[ 61.306415] [ 61.306415] [<c11386bf>] path_lookupat+0xf/0xe0
[ 61.306415] [ 61.306415] [<c1139ebc>] filename_lookup+0x6c/0x100
[ 61.306415] [ 61.306415] [<c1139fd5>] user_path_at_empty+0x25/0x30
[ 61.306415] [ 61.306415] [<c11298c6>] SyS_faccessat+0x86/0x1e0
[ 61.306415] [ 61.306415] [<c1129a30>] SyS_access+0x10/0x20
[ 61.306415] [ 61.306415] [<c100179f>] do_int80_syscall_32+0x3f/0x110
[ 61.306415] [ 61.306415] [<c14bba3f>] restore_all+0x0/0x61
[ 61.306415] INITIAL USE at:
[ 61.306415] [ 61.306415] [<c107586e>] __lock_acquire+0x1fe/0x1770
[ 61.306415] [ 61.306415] [<c107717c>] lock_acquire+0x7c/0x150
[ 61.306415] [ 61.306415] [<c14bb334>] _raw_spin_lock_irqsave+0x24/0x40
[ 61.306415] [ 61.306415] [<d093474e>] r6040_get_stats+0x1e/0x60 [r6040]
[ 61.306415] [ 61.306415] [<c139fb16>] dev_get_stats+0x96/0xc0
[ 61.306415] [ 61.306415] [<c14b416e>] rtnl_fill_stats+0x36/0xfd
[ 61.306415] [ 61.306415] [<c13b7b3c>] rtnl_fill_ifinfo+0x47c/0xce0
[ 61.306415] [ 61.306415] [<c13bc08e>] rtmsg_ifinfo_build_skb+0x4e/0xd0
[ 61.306415] [ 61.306415] [<c13bc120>] rtmsg_ifinfo.part.20+0x10/0x40
[ 61.306415] [ 61.306415] [<c13bc16b>] rtmsg_ifinfo+0x1b/0x20
[ 61.306415] [ 61.306415] [<c13a9d19>] register_netdevice+0x409/0x550
[ 61.306415] [ 61.306415] [<c13a9e72>] register_netdev+0x12/0x20
[ 61.306415] [ 61.306415] [<d09357e8>] r6040_init_one+0x3e8/0x500 [r6040]
[ 61.306415] [ 61.306415] [<c12a78c7>] pci_device_probe+0x77/0xd0
[ 61.306415] [ 61.306415] [<c12f5e15>] driver_probe_device+0x145/0x280
[ 61.306415] [ 61.306415] [<c12f5fd9>] __driver_attach+0x89/0x90
[ 61.306415] [ 61.306415] [<c12f43ef>] bus_for_each_dev+0x4f/0x80
[ 61.306415] [ 61.306415] [<c12f5954>] driver_attach+0x14/0x20
[ 61.306415] [ 61.306415] [<c12f55b7>] bus_add_driver+0x197/0x210
[ 61.306415] [ 61.306415] [<c12f6a21>] driver_register+0x51/0xd0
[ 61.306415] [ 61.306415] [<c12a6955>] __pci_register_driver+0x45/0x50
[ 61.306415] [ 61.306415] [<d0938017>] 0xd0938017
[ 61.306415] [ 61.306415] [<c100043f>] do_one_initcall+0x2f/0x140
[ 61.306415] [ 61.306415] [<c10e48c0>] do_init_module+0x4a/0x19b
[ 61.306415] [ 61.306415] [<c10a680e>] load_module+0x1b2e/0x2070
[ 61.306415] [ 61.306415] [<c10a6eb9>] SyS_finit_module+0x69/0x80
[ 61.306415] [ 61.306415] [<c100179f>] do_int80_syscall_32+0x3f/0x110
[ 61.306415] [ 61.306415] [<c14bba3f>] restore_all+0x0/0x61
[ 61.306415] }
[ 61.306415] ... key at: [<d0936280>] __key.45893+0x0/0xfffff739 [r6040]
[ 61.306415] ... acquired at:
[ 61.306415] [ 61.306415] [<c1074a32>] check_irq_usage+0x42/0xb0
[ 61.306415] [ 61.306415] [<c107677c>] __lock_acquire+0x110c/0x1770
[ 61.306415] [ 61.306415] [<c107717c>] lock_acquire+0x7c/0x150
[ 61.306415] [ 61.306415] [<c14b7add>] mutex_lock_nested+0x2d/0x4a0
[ 61.306415] [ 61.306415] [<c1336276>] phy_stop+0x16/0x80
[ 61.306415] [ 61.306415] [<d0934ce9>] r6040_close+0x89/0x230 [r6040]
[ 61.306415] [ 61.306415] [<c13a0a91>] __dev_close_many+0x61/0xa0
[ 61.306415] [ 61.306415] [<c13a0bbf>] __dev_close+0x1f/0x30
[ 61.306415] [ 61.306415] [<c13a9127>] __dev_change_flags+0x87/0x150
[ 61.306415] [ 61.306415] [<c13a9213>] dev_change_flags+0x23/0x60
[ 61.306415] [ 61.306415] [<c1416238>] devinet_ioctl+0x5f8/0x6f0
[ 61.306415] [ 61.306415] [<c1417f75>] inet_ioctl+0x65/0x90
[ 61.306415] [ 61.306415] [<c1389b54>] sock_ioctl+0x124/0x2b0
[ 61.306415] [ 61.306415] [<c113cf7c>] do_vfs_ioctl+0x7c/0x790
[ 61.306415] [ 61.306415] [<c113d6b8>] SyS_ioctl+0x28/0x50
[ 61.306415] [ 61.306415] [<c100179f>] do_int80_syscall_32+0x3f/0x110
[ 61.306415] [ 61.306415] [<c14bba3f>] restore_all+0x0/0x61
[ 61.306415]
[ 61.306415]
the dependencies between the lock to be acquired[ 61.306415] and SOFTIRQ-irq-unsafe lock:
[ 61.306415] -> (&dev->lock){+.+...} ops: 56 {
[ 61.306415] HARDIRQ-ON-W at:
[ 61.306415] [ 61.306415] [<c1075be7>] __lock_acquire+0x577/0x1770
[ 61.306415] [ 61.306415] [<c107717c>] lock_acquire+0x7c/0x150
[ 61.306415] [ 61.306415] [<c14b7add>] mutex_lock_nested+0x2d/0x4a0
[ 61.306415] [ 61.306415] [<c133747d>] phy_probe+0x4d/0xc0
[ 61.306415] [ 61.306415] [<c1338afe>] phy_attach_direct+0xbe/0x190
[ 61.306415] [ 61.306415] [<c1338ca7>] phy_connect_direct+0x17/0x60
[ 61.306415] [ 61.306415] [<c1338d23>] phy_connect+0x33/0x70
[ 61.306415] [ 61.306415] [<d09357a0>] r6040_init_one+0x3a0/0x500 [r6040]
[ 61.306415] [ 61.306415] [<c12a78c7>] pci_device_probe+0x77/0xd0
[ 61.306415] [ 61.306415] [<c12f5e15>] driver_probe_device+0x145/0x280
[ 61.306415] [ 61.306415] [<c12f5fd9>] __driver_attach+0x89/0x90
[ 61.306415] [ 61.306415] [<c12f43ef>] bus_for_each_dev+0x4f/0x80
[ 61.306415] [ 61.306415] [<c12f5954>] driver_attach+0x14/0x20
[ 61.306415] [ 61.306415] [<c12f55b7>] bus_add_driver+0x197/0x210
[ 61.306415] [ 61.306415] [<c12f6a21>] driver_register+0x51/0xd0
[ 61.306415] [ 61.306415] [<c12a6955>] __pci_register_driver+0x45/0x50
[ 61.306415] [ 61.306415] [<d0938017>] 0xd0938017
[ 61.306415] [ 61.306415] [<c100043f>] do_one_initcall+0x2f/0x140
[ 61.306415] [ 61.306415] [<c10e48c0>] do_init_module+0x4a/0x19b
[ 61.306415] [ 61.306415] [<c10a680e>] load_module+0x1b2e/0x2070
[ 61.306415] [ 61.306415] [<c10a6eb9>] SyS_finit_module+0x69/0x80
[ 61.306415] [ 61.306415] [<c100179f>] do_int80_syscall_32+0x3f/0x110
[ 61.306415] [ 61.306415] [<c14bba3f>] restore_all+0x0/0x61
[ 61.306415] SOFTIRQ-ON-W at:
[ 61.306415] [ 61.306415] [<c1075c0c>] __lock_acquire+0x59c/0x1770
[ 61.306415] [ 61.306415] [<c107717c>] lock_acquire+0x7c/0x150
[ 61.306415] [ 61.306415] [<c14b7add>] mutex_lock_nested+0x2d/0x4a0
[ 61.306415] [ 61.306415] [<c133747d>] phy_probe+0x4d/0xc0
[ 61.306415] [ 61.306415] [<c1338afe>] phy_attach_direct+0xbe/0x190
[ 61.306415] [ 61.306415] [<c1338ca7>] phy_connect_direct+0x17/0x60
[ 61.306415] [ 61.306415] [<c1338d23>] phy_connect+0x33/0x70
[ 61.306415] [ 61.306415] [<d09357a0>] r6040_init_one+0x3a0/0x500 [r6040]
[ 61.306415] [ 61.306415] [<c12a78c7>] pci_device_probe+0x77/0xd0
[ 61.306415] [ 61.306415] [<c12f5e15>] driver_probe_device+0x145/0x280
[ 61.306415] [ 61.306415] [<c12f5fd9>] __driver_attach+0x89/0x90
[ 61.306415] [ 61.306415] [<c12f43ef>] bus_for_each_dev+0x4f/0x80
[ 61.306415] [ 61.306415] [<c12f5954>] driver_attach+0x14/0x20
[ 61.306415] [ 61.306415] [<c12f55b7>] bus_add_driver+0x197/0x210
[ 61.306415] [ 61.306415] [<c12f6a21>] driver_register+0x51/0xd0
[ 61.306415] [ 61.306415] [<c12a6955>] __pci_register_driver+0x45/0x50
[ 61.306415] [ 61.306415] [<d0938017>] 0xd0938017
[ 61.306415] [ 61.306415] [<c100043f>] do_one_initcall+0x2f/0x140
[ 61.306415] [ 61.306415] [<c10e48c0>] do_init_module+0x4a/0x19b
[ 61.306415] [ 61.306415] [<c10a680e>] load_module+0x1b2e/0x2070
[ 61.306415] [ 61.306415] [<c10a6eb9>] SyS_finit_module+0x69/0x80
[ 61.306415] [ 61.306415] [<c100179f>] do_int80_syscall_32+0x3f/0x110
[ 61.306415] [ 61.306415] [<c14bba3f>] restore_all+0x0/0x61
[ 61.306415] INITIAL USE at:
[ 61.306415] [ 61.306415] [<c107586e>] __lock_acquire+0x1fe/0x1770
[ 61.306415] [ 61.306415] [<c107717c>] lock_acquire+0x7c/0x150
[ 61.306415] [ 61.306415] [<c14b7add>] mutex_lock_nested+0x2d/0x4a0
[ 61.306415] [ 61.306415] [<c133747d>] phy_probe+0x4d/0xc0
[ 61.306415] [ 61.306415] [<c1338afe>] phy_attach_direct+0xbe/0x190
[ 61.306415] [ 61.306415] [<c1338ca7>] phy_connect_direct+0x17/0x60
[ 61.306415] [ 61.306415] [<c1338d23>] phy_connect+0x33/0x70
[ 61.306415] [ 61.306415] [<d09357a0>] r6040_init_one+0x3a0/0x500 [r6040]
[ 61.306415] [ 61.306415] [<c12a78c7>] pci_device_probe+0x77/0xd0
[ 61.306415] [ 61.306415] [<c12f5e15>] driver_probe_device+0x145/0x280
[ 61.306415] [ 61.306415] [<c12f5fd9>] __driver_attach+0x89/0x90
[ 61.306415] [ 61.306415] [<c12f43ef>] bus_for_each_dev+0x4f/0x80
[ 61.306415] [ 61.306415] [<c12f5954>] driver_attach+0x14/0x20
[ 61.306415] [ 61.306415] [<c12f55b7>] bus_add_driver+0x197/0x210
[ 61.306415] [ 61.306415] [<c12f6a21>] driver_register+0x51/0xd0
[ 61.306415] [ 61.306415] [<c12a6955>] __pci_register_driver+0x45/0x50
[ 61.306415] [ 61.306415] [<d0938017>] 0xd0938017
[ 61.306415] [ 61.306415] [<c100043f>] do_one_initcall+0x2f/0x140
[ 61.306415] [ 61.306415] [<c10e48c0>] do_init_module+0x4a/0x19b
[ 61.306415] [ 61.306415] [<c10a680e>] load_module+0x1b2e/0x2070
[ 61.306415] [ 61.306415] [<c10a6eb9>] SyS_finit_module+0x69/0x80
[ 61.306415] [ 61.306415] [<c100179f>] do_int80_syscall_32+0x3f/0x110
[ 61.306415] [ 61.306415] [<c14bba3f>] restore_all+0x0/0x61
[ 61.306415] }
[ 61.306415] ... key at: [<c1f28f39>] __key.43998+0x0/0x8
[ 61.306415] ... acquired at:
[ 61.306415] [ 61.306415] [<c1074a32>] check_irq_usage+0x42/0xb0
[ 61.306415] [ 61.306415] [<c107677c>] __lock_acquire+0x110c/0x1770
[ 61.306415] [ 61.306415] [<c107717c>] lock_acquire+0x7c/0x150
[ 61.306415] [ 61.306415] [<c14b7add>] mutex_lock_nested+0x2d/0x4a0
[ 61.306415] [ 61.306415] [<c1336276>] phy_stop+0x16/0x80
[ 61.306415] [ 61.306415] [<d0934ce9>] r6040_close+0x89/0x230 [r6040]
[ 61.306415] [ 61.306415] [<c13a0a91>] __dev_close_many+0x61/0xa0
[ 61.306415] [ 61.306415] [<c13a0bbf>] __dev_close+0x1f/0x30
[ 61.306415] [ 61.306415] [<c13a9127>] __dev_change_flags+0x87/0x150
[ 61.306415] [ 61.306415] [<c13a9213>] dev_change_flags+0x23/0x60
[ 61.306415] [ 61.306415] [<c1416238>] devinet_ioctl+0x5f8/0x6f0
[ 61.306415] [ 61.306415] [<c1417f75>] inet_ioctl+0x65/0x90
[ 61.306415] [ 61.306415] [<c1389b54>] sock_ioctl+0x124/0x2b0
[ 61.306415] [ 61.306415] [<c113cf7c>] do_vfs_ioctl+0x7c/0x790
[ 61.306415] [ 61.306415] [<c113d6b8>] SyS_ioctl+0x28/0x50
[ 61.306415] [ 61.306415] [<c100179f>] do_int80_syscall_32+0x3f/0x110
[ 61.306415] [ 61.306415] [<c14bba3f>] restore_all+0x0/0x61
[ 61.306415]
[ 61.306415]
[ 61.306415] stack backtrace:
[ 61.306415] CPU: 0 PID: 449 Comm: ifconfig Not tainted 4.9.0-gb898d2d-manuel #1
[ 61.306415] Call Trace:
[ 61.306415] dump_stack+0x16/0x19
[ 61.306415] check_usage+0x3f6/0x550
[ 61.306415] ? check_usage+0x4d/0x550
[ 61.306415] check_irq_usage+0x42/0xb0
[ 61.306415] __lock_acquire+0x110c/0x1770
[ 61.306415] lock_acquire+0x7c/0x150
[ 61.306415] ? phy_stop+0x16/0x80
[ 61.306415] mutex_lock_nested+0x2d/0x4a0
[ 61.306415] ? phy_stop+0x16/0x80
[ 61.306415] ? r6040_close+0x24/0x230 [r6040]
[ 61.306415] ? __delay+0x9/0x10
[ 61.306415] phy_stop+0x16/0x80
[ 61.306415] r6040_close+0x89/0x230 [r6040]
[ 61.306415] __dev_close_many+0x61/0xa0
[ 61.306415] __dev_close+0x1f/0x30
[ 61.306415] __dev_change_flags+0x87/0x150
[ 61.306415] dev_change_flags+0x23/0x60
[ 61.306415] devinet_ioctl+0x5f8/0x6f0
[ 61.306415] inet_ioctl+0x65/0x90
[ 61.306415] sock_ioctl+0x124/0x2b0
[ 61.306415] ? dlci_ioctl_set+0x30/0x30
[ 61.306415] do_vfs_ioctl+0x7c/0x790
[ 61.306415] ? trace_hardirqs_on+0xb/0x10
[ 61.306415] ? call_rcu_sched+0xd/0x10
[ 61.306415] ? __put_cred+0x32/0x50
[ 61.306415] ? SyS_faccessat+0x178/0x1e0
[ 61.306415] SyS_ioctl+0x28/0x50
[ 61.306415] do_int80_syscall_32+0x3f/0x110
[ 61.306415] entry_INT80_32+0x2f/0x2f
[ 61.306415] EIP: 0xb764d364
[ 61.306415] EFLAGS: 00000286 CPU: 0
[ 61.306415] EAX: ffffffda EBX: 00000004 ECX: 00008914 EDX: bfa99d7c
[ 61.306415] ESI: bfa99e4c EDI: fffffffe EBP: 00000004 ESP: bfa99d58
[ 61.306415] DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 007b
[ 63.836607] r6040 0000:00:08.0 eth0: Link is Down
Signed-off-by: Manuel Bessler <manuel.bessler@sensus.com>
---
drivers/net/ethernet/rdc/r6040.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/rdc/r6040.c b/drivers/net/ethernet/rdc/r6040.c
index 9a37247..1b4a653 100644
--- a/drivers/net/ethernet/rdc/r6040.c
+++ b/drivers/net/ethernet/rdc/r6040.c
@@ -473,8 +473,6 @@ static void r6040_down(struct net_device *dev)
iowrite16(adrp[0], ioaddr + MID_0L);
iowrite16(adrp[1], ioaddr + MID_0M);
iowrite16(adrp[2], ioaddr + MID_0H);
-
- phy_stop(lp->phydev);
}
static int r6040_close(struct net_device *dev)
@@ -482,12 +480,12 @@ static int r6040_close(struct net_device *dev)
struct r6040_private *lp = netdev_priv(dev);
struct pci_dev *pdev = lp->pdev;
- spin_lock_irq(&lp->lock);
+ phy_stop(lp->phydev);
napi_disable(&lp->napi);
netif_stop_queue(dev);
- r6040_down(dev);
- free_irq(dev->irq, dev);
+ spin_lock_irq(&lp->lock);
+ r6040_down(dev);
/* Free RX buffer */
r6040_free_rxbufs(dev);
@@ -497,6 +495,8 @@ static int r6040_close(struct net_device *dev)
spin_unlock_irq(&lp->lock);
+ free_irq(dev->irq, dev);
+
/* Free Descriptor memory */
if (lp->rx_ring) {
pci_free_consistent(pdev,
--
2.7.4
^ permalink raw reply related
* Re: [RFC v2 00/10] HFI Virtual Network Interface Controller (VNIC)
From: Doug Ledford @ 2016-12-15 18:19 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: ira.weiny, Leon Romanovsky, Jeff Kirsher, David S. Miller,
Vishwanathapura, Niranjana, linux-rdma, netdev,
dennis.dalessandro
In-Reply-To: <20161215170713.GD3264@obsidianresearch.com>
[-- Attachment #1.1: Type: text/plain, Size: 1181 bytes --]
On 12/15/2016 12:07 PM, Jason Gunthorpe wrote:
> On Thu, Dec 15, 2016 at 11:28:06AM -0500, Doug Ledford wrote:
>
>> 1) Since your intent is to make this work with multiple versions of the
>> hfi drivers, I disagree with Jason that just because there is only one
>> driver today that we should keep it simple. Design it right from the
>> beginning of multi driver is your intent is, IMO, a better way to go.
>> You'll work out the bugs in the initial implementation and when it comes
>> time to add the second driver, things will go much more smoothly.
>
> If that is your position then this should be a straight up IB ULP that
> works with any IB hardware.
Yes, see my comments in point #3 of my previous email...
> There is nothing HFI specific about it except for the
> micro-optimization of pushing packets via SDMA instead of post_send,
> and that same micro optimization probably applies to ipoib.
>
> In other words, lets see the first version as a straight ULP with no
> special HFI hooks, then we can discuss how best to micro optimize it
> for HFI SDMA.
>
> Jason
>
--
Doug Ledford <dledford@redhat.com>
GPG Key ID: 0E572FDD
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]
^ permalink raw reply
* [PATCH v2 net] rebased to master
From: Manuel Bessler @ 2016-12-15 18:21 UTC (permalink / raw)
To: netdev; +Cc: Manuel Bessler
In-Reply-To: <1481823997-11604-1-git-send-email-manuel.bessler@sensus.com>
'ifconfig eth0 down' makes r6040_close() trigger:
INFO: HARDIRQ-safe -> HARDIRQ-unsafe lock order detected
Fixed by moving calls to phy_stop(), napi_disable(), netif_stop_queue()
to outside of the module's private spin_lock_irq block.
Found on a Versalogic Tomcat SBC with a Vortex86 SoC
s1660e_5150:~# sudo ifconfig eth0 down
[ 61.306415] ======================================================
[ 61.306415] [ INFO: SOFTIRQ-safe -> SOFTIRQ-unsafe lock order detected ]
[ 61.306415] 4.9.0-gb898d2d-manuel #1 Not tainted
[ 61.306415] ------------------------------------------------------
[ 61.306415] ifconfig/449 [HC0[0]:SC0[0]:HE0:SE1] is trying to acquire:
[ 61.306415] (&dev->lock){+.+...}, at: [<c1336276>] phy_stop+0x16/0x80
[ 61.306415] and this task is already holding:
[ 61.306415] (&(&lp->lock)->rlock){+.-...}, at: [<d0934c84>] r6040_close+0x24/0x230 [r6040]
which would create a new lock dependency:
[ 61.306415] (&(&lp->lock)->rlock){+.-...} -> (&dev->lock){+.+...}
[ 61.306415] but this new dependency connects a SOFTIRQ-irq-safe lock:
[ 61.306415] (&(&lp->lock)->rlock){+.-...}
[ 61.306415] ... which became SOFTIRQ-irq-safe at:
[ 61.306415] [ 61.306415] [<c1075bc5>] __lock_acquire+0x555/0x1770
[ 61.306415] [ 61.306415] [<c107717c>] lock_acquire+0x7c/0x150
[ 61.306415] [ 61.306415] [<c14bb334>] _raw_spin_lock_irqsave+0x24/0x40
[ 61.306415] [ 61.306415] [<d0934ac0>] r6040_start_xmit+0x30/0x1d0 [r6040]
[ 61.306415] [ 61.306415] [<c13a7d4d>] dev_hard_start_xmit+0x9d/0x2d0
[ 61.306415] [ 61.306415] [<c13c8a38>] sch_direct_xmit+0xa8/0x140
[ 61.306415] [ 61.306415] [<c13a8436>] __dev_queue_xmit+0x416/0x780
[ 61.306415] [ 61.306415] [<c13a87aa>] dev_queue_xmit+0xa/0x10
[ 61.306415] [ 61.306415] [<c13b4837>] neigh_resolve_output+0x147/0x220
[ 61.306415] [ 61.306415] [<c144541b>] ip6_finish_output2+0x2fb/0x910
[ 61.306415] [ 61.306415] [<c14494e6>] ip6_finish_output+0xa6/0x1a0
[ 61.306415] [ 61.306415] [<c1449635>] ip6_output+0x55/0x320
[ 61.306415] [ 61.306415] [<c146f4d2>] mld_sendpack+0x352/0x560
[ 61.306415] [ 61.306415] [<c146fe55>] mld_ifc_timer_expire+0x155/0x280
[ 61.306415] [ 61.306415] [<c108b081>] call_timer_fn+0x81/0x270
[ 61.306415] [ 61.306415] [<c108b331>] expire_timers+0xc1/0x180
[ 61.306415] [ 61.306415] [<c108b4f7>] run_timer_softirq+0x77/0x150
[ 61.306415] [ 61.306415] [<c1043d04>] __do_softirq+0xb4/0x3d0
[ 61.306415] [ 61.306415] [<c101a15c>] do_softirq_own_stack+0x1c/0x30
[ 61.306415] [ 61.306415] [<c104416e>] irq_exit+0x8e/0xa0
[ 61.306415] [ 61.306415] [<c1019d31>] do_IRQ+0x51/0x100
[ 61.306415] [ 61.306415] [<c14bc176>] common_interrupt+0x36/0x40
[ 61.306415] [ 61.306415] [<c1134928>] set_root+0x68/0xf0
[ 61.306415] [ 61.306415] [<c1136120>] path_init+0x400/0x640
[ 61.306415] [ 61.306415] [<c11386bf>] path_lookupat+0xf/0xe0
[ 61.306415] [ 61.306415] [<c1139ebc>] filename_lookup+0x6c/0x100
[ 61.306415] [ 61.306415] [<c1139fd5>] user_path_at_empty+0x25/0x30
[ 61.306415] [ 61.306415] [<c11298c6>] SyS_faccessat+0x86/0x1e0
[ 61.306415] [ 61.306415] [<c1129a30>] SyS_access+0x10/0x20
[ 61.306415] [ 61.306415] [<c100179f>] do_int80_syscall_32+0x3f/0x110
[ 61.306415] [ 61.306415] [<c14bba3f>] restore_all+0x0/0x61
[ 61.306415]
[ 61.306415] to a SOFTIRQ-irq-unsafe lock:
[ 61.306415] (&dev->lock){+.+...}
[ 61.306415] ... which became SOFTIRQ-irq-unsafe at:
[ 61.306415] ...[ 61.306415]
[ 61.306415] [<c1075c0c>] __lock_acquire+0x59c/0x1770
[ 61.306415] [ 61.306415] [<c107717c>] lock_acquire+0x7c/0x150
[ 61.306415] [ 61.306415] [<c14b7add>] mutex_lock_nested+0x2d/0x4a0
[ 61.306415] [ 61.306415] [<c133747d>] phy_probe+0x4d/0xc0
[ 61.306415] [ 61.306415] [<c1338afe>] phy_attach_direct+0xbe/0x190
[ 61.306415] [ 61.306415] [<c1338ca7>] phy_connect_direct+0x17/0x60
[ 61.306415] [ 61.306415] [<c1338d23>] phy_connect+0x33/0x70
[ 61.306415] [ 61.306415] [<d09357a0>] r6040_init_one+0x3a0/0x500 [r6040]
[ 61.306415] [ 61.306415] [<c12a78c7>] pci_device_probe+0x77/0xd0
[ 61.306415] [ 61.306415] [<c12f5e15>] driver_probe_device+0x145/0x280
[ 61.306415] [ 61.306415] [<c12f5fd9>] __driver_attach+0x89/0x90
[ 61.306415] [ 61.306415] [<c12f43ef>] bus_for_each_dev+0x4f/0x80
[ 61.306415] [ 61.306415] [<c12f5954>] driver_attach+0x14/0x20
[ 61.306415] [ 61.306415] [<c12f55b7>] bus_add_driver+0x197/0x210
[ 61.306415] [ 61.306415] [<c12f6a21>] driver_register+0x51/0xd0
[ 61.306415] [ 61.306415] [<c12a6955>] __pci_register_driver+0x45/0x50
[ 61.306415] [ 61.306415] [<d0938017>] 0xd0938017
[ 61.306415] [ 61.306415] [<c100043f>] do_one_initcall+0x2f/0x140
[ 61.306415] [ 61.306415] [<c10e48c0>] do_init_module+0x4a/0x19b
[ 61.306415] [ 61.306415] [<c10a680e>] load_module+0x1b2e/0x2070
[ 61.306415] [ 61.306415] [<c10a6eb9>] SyS_finit_module+0x69/0x80
[ 61.306415] [ 61.306415] [<c100179f>] do_int80_syscall_32+0x3f/0x110
[ 61.306415] [ 61.306415] [<c14bba3f>] restore_all+0x0/0x61
[ 61.306415]
[ 61.306415] other info that might help us debug this:
[ 61.306415]
[ 61.306415] Possible interrupt unsafe locking scenario:
[ 61.306415]
[ 61.306415] CPU0 CPU1
[ 61.306415] ---- ----
[ 61.306415] lock(&dev->lock);
[ 61.306415] local_irq_disable();
[ 61.306415] lock(&(&lp->lock)->rlock);
[ 61.306415] lock(&dev->lock);
[ 61.306415] <Interrupt>
[ 61.306415] lock(&(&lp->lock)->rlock);
[ 61.306415]
[ 61.306415] *** DEADLOCK ***
[ 61.306415]
[ 61.306415] 2 locks held by ifconfig/449:
[ 61.306415] #0: (rtnl_mutex){+.+.+.}, at: [<c13b68ef>] rtnl_lock+0xf/0x20
[ 61.306415] #1: (&(&lp->lock)->rlock){+.-...}, at: [<d0934c84>] r6040_close+0x24/0x230 [r6040]
[ 61.306415]
[ 61.306415] the dependencies between SOFTIRQ-irq-safe lock and the holding lock:
[ 61.306415] -> (&(&lp->lock)->rlock){+.-...} ops: 3049 {
[ 61.306415] HARDIRQ-ON-W at:
[ 61.306415] [ 61.306415] [<c1075be7>] __lock_acquire+0x577/0x1770
[ 61.306415] [ 61.306415] [<c107717c>] lock_acquire+0x7c/0x150
[ 61.306415] [ 61.306415] [<c14bb21b>] _raw_spin_lock+0x1b/0x30
[ 61.306415] [ 61.306415] [<d09343cc>] r6040_poll+0x2c/0x330 [r6040]
[ 61.306415] [ 61.306415] [<c13a5577>] net_rx_action+0x197/0x340
[ 61.306415] [ 61.306415] [<c1043d04>] __do_softirq+0xb4/0x3d0
[ 61.306415] [ 61.306415] [<c1044037>] run_ksoftirqd+0x17/0x40
[ 61.306415] [ 61.306415] [<c105fe91>] smpboot_thread_fn+0x141/0x180
[ 61.306415] [ 61.306415] [<c105c84e>] kthread+0xde/0x110
[ 61.306415] [ 61.306415] [<c14bb949>] ret_from_fork+0x19/0x30
[ 61.306415] IN-SOFTIRQ-W at:
[ 61.306415] [ 61.306415] [<c1075bc5>] __lock_acquire+0x555/0x1770
[ 61.306415] [ 61.306415] [<c107717c>] lock_acquire+0x7c/0x150
[ 61.306415] [ 61.306415] [<c14bb334>] _raw_spin_lock_irqsave+0x24/0x40
[ 61.306415] [ 61.306415] [<d0934ac0>] r6040_start_xmit+0x30/0x1d0 [r6040]
[ 61.306415] [ 61.306415] [<c13a7d4d>] dev_hard_start_xmit+0x9d/0x2d0
[ 61.306415] [ 61.306415] [<c13c8a38>] sch_direct_xmit+0xa8/0x140
[ 61.306415] [ 61.306415] [<c13a8436>] __dev_queue_xmit+0x416/0x780
[ 61.306415] [ 61.306415] [<c13a87aa>] dev_queue_xmit+0xa/0x10
[ 61.306415] [ 61.306415] [<c13b4837>] neigh_resolve_output+0x147/0x220
[ 61.306415] [ 61.306415] [<c144541b>] ip6_finish_output2+0x2fb/0x910
[ 61.306415] [ 61.306415] [<c14494e6>] ip6_finish_output+0xa6/0x1a0
[ 61.306415] [ 61.306415] [<c1449635>] ip6_output+0x55/0x320
[ 61.306415] [ 61.306415] [<c146f4d2>] mld_sendpack+0x352/0x560
[ 61.306415] [ 61.306415] [<c146fe55>] mld_ifc_timer_expire+0x155/0x280
[ 61.306415] [ 61.306415] [<c108b081>] call_timer_fn+0x81/0x270
[ 61.306415] [ 61.306415] [<c108b331>] expire_timers+0xc1/0x180
[ 61.306415] [ 61.306415] [<c108b4f7>] run_timer_softirq+0x77/0x150
[ 61.306415] [ 61.306415] [<c1043d04>] __do_softirq+0xb4/0x3d0
[ 61.306415] [ 61.306415] [<c101a15c>] do_softirq_own_stack+0x1c/0x30
[ 61.306415] [ 61.306415] [<c104416e>] irq_exit+0x8e/0xa0
[ 61.306415] [ 61.306415] [<c1019d31>] do_IRQ+0x51/0x100
[ 61.306415] [ 61.306415] [<c14bc176>] common_interrupt+0x36/0x40
[ 61.306415] [ 61.306415] [<c1134928>] set_root+0x68/0xf0
[ 61.306415] [ 61.306415] [<c1136120>] path_init+0x400/0x640
[ 61.306415] [ 61.306415] [<c11386bf>] path_lookupat+0xf/0xe0
[ 61.306415] [ 61.306415] [<c1139ebc>] filename_lookup+0x6c/0x100
[ 61.306415] [ 61.306415] [<c1139fd5>] user_path_at_empty+0x25/0x30
[ 61.306415] [ 61.306415] [<c11298c6>] SyS_faccessat+0x86/0x1e0
[ 61.306415] [ 61.306415] [<c1129a30>] SyS_access+0x10/0x20
[ 61.306415] [ 61.306415] [<c100179f>] do_int80_syscall_32+0x3f/0x110
[ 61.306415] [ 61.306415] [<c14bba3f>] restore_all+0x0/0x61
[ 61.306415] INITIAL USE at:
[ 61.306415] [ 61.306415] [<c107586e>] __lock_acquire+0x1fe/0x1770
[ 61.306415] [ 61.306415] [<c107717c>] lock_acquire+0x7c/0x150
[ 61.306415] [ 61.306415] [<c14bb334>] _raw_spin_lock_irqsave+0x24/0x40
[ 61.306415] [ 61.306415] [<d093474e>] r6040_get_stats+0x1e/0x60 [r6040]
[ 61.306415] [ 61.306415] [<c139fb16>] dev_get_stats+0x96/0xc0
[ 61.306415] [ 61.306415] [<c14b416e>] rtnl_fill_stats+0x36/0xfd
[ 61.306415] [ 61.306415] [<c13b7b3c>] rtnl_fill_ifinfo+0x47c/0xce0
[ 61.306415] [ 61.306415] [<c13bc08e>] rtmsg_ifinfo_build_skb+0x4e/0xd0
[ 61.306415] [ 61.306415] [<c13bc120>] rtmsg_ifinfo.part.20+0x10/0x40
[ 61.306415] [ 61.306415] [<c13bc16b>] rtmsg_ifinfo+0x1b/0x20
[ 61.306415] [ 61.306415] [<c13a9d19>] register_netdevice+0x409/0x550
[ 61.306415] [ 61.306415] [<c13a9e72>] register_netdev+0x12/0x20
[ 61.306415] [ 61.306415] [<d09357e8>] r6040_init_one+0x3e8/0x500 [r6040]
[ 61.306415] [ 61.306415] [<c12a78c7>] pci_device_probe+0x77/0xd0
[ 61.306415] [ 61.306415] [<c12f5e15>] driver_probe_device+0x145/0x280
[ 61.306415] [ 61.306415] [<c12f5fd9>] __driver_attach+0x89/0x90
[ 61.306415] [ 61.306415] [<c12f43ef>] bus_for_each_dev+0x4f/0x80
[ 61.306415] [ 61.306415] [<c12f5954>] driver_attach+0x14/0x20
[ 61.306415] [ 61.306415] [<c12f55b7>] bus_add_driver+0x197/0x210
[ 61.306415] [ 61.306415] [<c12f6a21>] driver_register+0x51/0xd0
[ 61.306415] [ 61.306415] [<c12a6955>] __pci_register_driver+0x45/0x50
[ 61.306415] [ 61.306415] [<d0938017>] 0xd0938017
[ 61.306415] [ 61.306415] [<c100043f>] do_one_initcall+0x2f/0x140
[ 61.306415] [ 61.306415] [<c10e48c0>] do_init_module+0x4a/0x19b
[ 61.306415] [ 61.306415] [<c10a680e>] load_module+0x1b2e/0x2070
[ 61.306415] [ 61.306415] [<c10a6eb9>] SyS_finit_module+0x69/0x80
[ 61.306415] [ 61.306415] [<c100179f>] do_int80_syscall_32+0x3f/0x110
[ 61.306415] [ 61.306415] [<c14bba3f>] restore_all+0x0/0x61
[ 61.306415] }
[ 61.306415] ... key at: [<d0936280>] __key.45893+0x0/0xfffff739 [r6040]
[ 61.306415] ... acquired at:
[ 61.306415] [ 61.306415] [<c1074a32>] check_irq_usage+0x42/0xb0
[ 61.306415] [ 61.306415] [<c107677c>] __lock_acquire+0x110c/0x1770
[ 61.306415] [ 61.306415] [<c107717c>] lock_acquire+0x7c/0x150
[ 61.306415] [ 61.306415] [<c14b7add>] mutex_lock_nested+0x2d/0x4a0
[ 61.306415] [ 61.306415] [<c1336276>] phy_stop+0x16/0x80
[ 61.306415] [ 61.306415] [<d0934ce9>] r6040_close+0x89/0x230 [r6040]
[ 61.306415] [ 61.306415] [<c13a0a91>] __dev_close_many+0x61/0xa0
[ 61.306415] [ 61.306415] [<c13a0bbf>] __dev_close+0x1f/0x30
[ 61.306415] [ 61.306415] [<c13a9127>] __dev_change_flags+0x87/0x150
[ 61.306415] [ 61.306415] [<c13a9213>] dev_change_flags+0x23/0x60
[ 61.306415] [ 61.306415] [<c1416238>] devinet_ioctl+0x5f8/0x6f0
[ 61.306415] [ 61.306415] [<c1417f75>] inet_ioctl+0x65/0x90
[ 61.306415] [ 61.306415] [<c1389b54>] sock_ioctl+0x124/0x2b0
[ 61.306415] [ 61.306415] [<c113cf7c>] do_vfs_ioctl+0x7c/0x790
[ 61.306415] [ 61.306415] [<c113d6b8>] SyS_ioctl+0x28/0x50
[ 61.306415] [ 61.306415] [<c100179f>] do_int80_syscall_32+0x3f/0x110
[ 61.306415] [ 61.306415] [<c14bba3f>] restore_all+0x0/0x61
[ 61.306415]
[ 61.306415]
the dependencies between the lock to be acquired[ 61.306415] and SOFTIRQ-irq-unsafe lock:
[ 61.306415] -> (&dev->lock){+.+...} ops: 56 {
[ 61.306415] HARDIRQ-ON-W at:
[ 61.306415] [ 61.306415] [<c1075be7>] __lock_acquire+0x577/0x1770
[ 61.306415] [ 61.306415] [<c107717c>] lock_acquire+0x7c/0x150
[ 61.306415] [ 61.306415] [<c14b7add>] mutex_lock_nested+0x2d/0x4a0
[ 61.306415] [ 61.306415] [<c133747d>] phy_probe+0x4d/0xc0
[ 61.306415] [ 61.306415] [<c1338afe>] phy_attach_direct+0xbe/0x190
[ 61.306415] [ 61.306415] [<c1338ca7>] phy_connect_direct+0x17/0x60
[ 61.306415] [ 61.306415] [<c1338d23>] phy_connect+0x33/0x70
[ 61.306415] [ 61.306415] [<d09357a0>] r6040_init_one+0x3a0/0x500 [r6040]
[ 61.306415] [ 61.306415] [<c12a78c7>] pci_device_probe+0x77/0xd0
[ 61.306415] [ 61.306415] [<c12f5e15>] driver_probe_device+0x145/0x280
[ 61.306415] [ 61.306415] [<c12f5fd9>] __driver_attach+0x89/0x90
[ 61.306415] [ 61.306415] [<c12f43ef>] bus_for_each_dev+0x4f/0x80
[ 61.306415] [ 61.306415] [<c12f5954>] driver_attach+0x14/0x20
[ 61.306415] [ 61.306415] [<c12f55b7>] bus_add_driver+0x197/0x210
[ 61.306415] [ 61.306415] [<c12f6a21>] driver_register+0x51/0xd0
[ 61.306415] [ 61.306415] [<c12a6955>] __pci_register_driver+0x45/0x50
[ 61.306415] [ 61.306415] [<d0938017>] 0xd0938017
[ 61.306415] [ 61.306415] [<c100043f>] do_one_initcall+0x2f/0x140
[ 61.306415] [ 61.306415] [<c10e48c0>] do_init_module+0x4a/0x19b
[ 61.306415] [ 61.306415] [<c10a680e>] load_module+0x1b2e/0x2070
[ 61.306415] [ 61.306415] [<c10a6eb9>] SyS_finit_module+0x69/0x80
[ 61.306415] [ 61.306415] [<c100179f>] do_int80_syscall_32+0x3f/0x110
[ 61.306415] [ 61.306415] [<c14bba3f>] restore_all+0x0/0x61
[ 61.306415] SOFTIRQ-ON-W at:
[ 61.306415] [ 61.306415] [<c1075c0c>] __lock_acquire+0x59c/0x1770
[ 61.306415] [ 61.306415] [<c107717c>] lock_acquire+0x7c/0x150
[ 61.306415] [ 61.306415] [<c14b7add>] mutex_lock_nested+0x2d/0x4a0
[ 61.306415] [ 61.306415] [<c133747d>] phy_probe+0x4d/0xc0
[ 61.306415] [ 61.306415] [<c1338afe>] phy_attach_direct+0xbe/0x190
[ 61.306415] [ 61.306415] [<c1338ca7>] phy_connect_direct+0x17/0x60
[ 61.306415] [ 61.306415] [<c1338d23>] phy_connect+0x33/0x70
[ 61.306415] [ 61.306415] [<d09357a0>] r6040_init_one+0x3a0/0x500 [r6040]
[ 61.306415] [ 61.306415] [<c12a78c7>] pci_device_probe+0x77/0xd0
[ 61.306415] [ 61.306415] [<c12f5e15>] driver_probe_device+0x145/0x280
[ 61.306415] [ 61.306415] [<c12f5fd9>] __driver_attach+0x89/0x90
[ 61.306415] [ 61.306415] [<c12f43ef>] bus_for_each_dev+0x4f/0x80
[ 61.306415] [ 61.306415] [<c12f5954>] driver_attach+0x14/0x20
[ 61.306415] [ 61.306415] [<c12f55b7>] bus_add_driver+0x197/0x210
[ 61.306415] [ 61.306415] [<c12f6a21>] driver_register+0x51/0xd0
[ 61.306415] [ 61.306415] [<c12a6955>] __pci_register_driver+0x45/0x50
[ 61.306415] [ 61.306415] [<d0938017>] 0xd0938017
[ 61.306415] [ 61.306415] [<c100043f>] do_one_initcall+0x2f/0x140
[ 61.306415] [ 61.306415] [<c10e48c0>] do_init_module+0x4a/0x19b
[ 61.306415] [ 61.306415] [<c10a680e>] load_module+0x1b2e/0x2070
[ 61.306415] [ 61.306415] [<c10a6eb9>] SyS_finit_module+0x69/0x80
[ 61.306415] [ 61.306415] [<c100179f>] do_int80_syscall_32+0x3f/0x110
[ 61.306415] [ 61.306415] [<c14bba3f>] restore_all+0x0/0x61
[ 61.306415] INITIAL USE at:
[ 61.306415] [ 61.306415] [<c107586e>] __lock_acquire+0x1fe/0x1770
[ 61.306415] [ 61.306415] [<c107717c>] lock_acquire+0x7c/0x150
[ 61.306415] [ 61.306415] [<c14b7add>] mutex_lock_nested+0x2d/0x4a0
[ 61.306415] [ 61.306415] [<c133747d>] phy_probe+0x4d/0xc0
[ 61.306415] [ 61.306415] [<c1338afe>] phy_attach_direct+0xbe/0x190
[ 61.306415] [ 61.306415] [<c1338ca7>] phy_connect_direct+0x17/0x60
[ 61.306415] [ 61.306415] [<c1338d23>] phy_connect+0x33/0x70
[ 61.306415] [ 61.306415] [<d09357a0>] r6040_init_one+0x3a0/0x500 [r6040]
[ 61.306415] [ 61.306415] [<c12a78c7>] pci_device_probe+0x77/0xd0
[ 61.306415] [ 61.306415] [<c12f5e15>] driver_probe_device+0x145/0x280
[ 61.306415] [ 61.306415] [<c12f5fd9>] __driver_attach+0x89/0x90
[ 61.306415] [ 61.306415] [<c12f43ef>] bus_for_each_dev+0x4f/0x80
[ 61.306415] [ 61.306415] [<c12f5954>] driver_attach+0x14/0x20
[ 61.306415] [ 61.306415] [<c12f55b7>] bus_add_driver+0x197/0x210
[ 61.306415] [ 61.306415] [<c12f6a21>] driver_register+0x51/0xd0
[ 61.306415] [ 61.306415] [<c12a6955>] __pci_register_driver+0x45/0x50
[ 61.306415] [ 61.306415] [<d0938017>] 0xd0938017
[ 61.306415] [ 61.306415] [<c100043f>] do_one_initcall+0x2f/0x140
[ 61.306415] [ 61.306415] [<c10e48c0>] do_init_module+0x4a/0x19b
[ 61.306415] [ 61.306415] [<c10a680e>] load_module+0x1b2e/0x2070
[ 61.306415] [ 61.306415] [<c10a6eb9>] SyS_finit_module+0x69/0x80
[ 61.306415] [ 61.306415] [<c100179f>] do_int80_syscall_32+0x3f/0x110
[ 61.306415] [ 61.306415] [<c14bba3f>] restore_all+0x0/0x61
[ 61.306415] }
[ 61.306415] ... key at: [<c1f28f39>] __key.43998+0x0/0x8
[ 61.306415] ... acquired at:
[ 61.306415] [ 61.306415] [<c1074a32>] check_irq_usage+0x42/0xb0
[ 61.306415] [ 61.306415] [<c107677c>] __lock_acquire+0x110c/0x1770
[ 61.306415] [ 61.306415] [<c107717c>] lock_acquire+0x7c/0x150
[ 61.306415] [ 61.306415] [<c14b7add>] mutex_lock_nested+0x2d/0x4a0
[ 61.306415] [ 61.306415] [<c1336276>] phy_stop+0x16/0x80
[ 61.306415] [ 61.306415] [<d0934ce9>] r6040_close+0x89/0x230 [r6040]
[ 61.306415] [ 61.306415] [<c13a0a91>] __dev_close_many+0x61/0xa0
[ 61.306415] [ 61.306415] [<c13a0bbf>] __dev_close+0x1f/0x30
[ 61.306415] [ 61.306415] [<c13a9127>] __dev_change_flags+0x87/0x150
[ 61.306415] [ 61.306415] [<c13a9213>] dev_change_flags+0x23/0x60
[ 61.306415] [ 61.306415] [<c1416238>] devinet_ioctl+0x5f8/0x6f0
[ 61.306415] [ 61.306415] [<c1417f75>] inet_ioctl+0x65/0x90
[ 61.306415] [ 61.306415] [<c1389b54>] sock_ioctl+0x124/0x2b0
[ 61.306415] [ 61.306415] [<c113cf7c>] do_vfs_ioctl+0x7c/0x790
[ 61.306415] [ 61.306415] [<c113d6b8>] SyS_ioctl+0x28/0x50
[ 61.306415] [ 61.306415] [<c100179f>] do_int80_syscall_32+0x3f/0x110
[ 61.306415] [ 61.306415] [<c14bba3f>] restore_all+0x0/0x61
[ 61.306415]
[ 61.306415]
[ 61.306415] stack backtrace:
[ 61.306415] CPU: 0 PID: 449 Comm: ifconfig Not tainted 4.9.0-gb898d2d-manuel #1
[ 61.306415] Call Trace:
[ 61.306415] dump_stack+0x16/0x19
[ 61.306415] check_usage+0x3f6/0x550
[ 61.306415] ? check_usage+0x4d/0x550
[ 61.306415] check_irq_usage+0x42/0xb0
[ 61.306415] __lock_acquire+0x110c/0x1770
[ 61.306415] lock_acquire+0x7c/0x150
[ 61.306415] ? phy_stop+0x16/0x80
[ 61.306415] mutex_lock_nested+0x2d/0x4a0
[ 61.306415] ? phy_stop+0x16/0x80
[ 61.306415] ? r6040_close+0x24/0x230 [r6040]
[ 61.306415] ? __delay+0x9/0x10
[ 61.306415] phy_stop+0x16/0x80
[ 61.306415] r6040_close+0x89/0x230 [r6040]
[ 61.306415] __dev_close_many+0x61/0xa0
[ 61.306415] __dev_close+0x1f/0x30
[ 61.306415] __dev_change_flags+0x87/0x150
[ 61.306415] dev_change_flags+0x23/0x60
[ 61.306415] devinet_ioctl+0x5f8/0x6f0
[ 61.306415] inet_ioctl+0x65/0x90
[ 61.306415] sock_ioctl+0x124/0x2b0
[ 61.306415] ? dlci_ioctl_set+0x30/0x30
[ 61.306415] do_vfs_ioctl+0x7c/0x790
[ 61.306415] ? trace_hardirqs_on+0xb/0x10
[ 61.306415] ? call_rcu_sched+0xd/0x10
[ 61.306415] ? __put_cred+0x32/0x50
[ 61.306415] ? SyS_faccessat+0x178/0x1e0
[ 61.306415] SyS_ioctl+0x28/0x50
[ 61.306415] do_int80_syscall_32+0x3f/0x110
[ 61.306415] entry_INT80_32+0x2f/0x2f
[ 61.306415] EIP: 0xb764d364
[ 61.306415] EFLAGS: 00000286 CPU: 0
[ 61.306415] EAX: ffffffda EBX: 00000004 ECX: 00008914 EDX: bfa99d7c
[ 61.306415] ESI: bfa99e4c EDI: fffffffe EBP: 00000004 ESP: bfa99d58
[ 61.306415] DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 007b
[ 63.836607] r6040 0000:00:08.0 eth0: Link is Down
Signed-off-by: Manuel Bessler <manuel.bessler@sensus.com>
---
drivers/net/ethernet/rdc/r6040.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/rdc/r6040.c b/drivers/net/ethernet/rdc/r6040.c
index 4ff4e04..aa11b70 100644
--- a/drivers/net/ethernet/rdc/r6040.c
+++ b/drivers/net/ethernet/rdc/r6040.c
@@ -472,8 +472,6 @@ static void r6040_down(struct net_device *dev)
iowrite16(adrp[0], ioaddr + MID_0L);
iowrite16(adrp[1], ioaddr + MID_0M);
iowrite16(adrp[2], ioaddr + MID_0H);
-
- phy_stop(dev->phydev);
}
static int r6040_close(struct net_device *dev)
@@ -481,12 +479,12 @@ static int r6040_close(struct net_device *dev)
struct r6040_private *lp = netdev_priv(dev);
struct pci_dev *pdev = lp->pdev;
- spin_lock_irq(&lp->lock);
+ phy_stop(dev->phydev);
napi_disable(&lp->napi);
netif_stop_queue(dev);
- r6040_down(dev);
- free_irq(dev->irq, dev);
+ spin_lock_irq(&lp->lock);
+ r6040_down(dev);
/* Free RX buffer */
r6040_free_rxbufs(dev);
@@ -496,6 +494,8 @@ static int r6040_close(struct net_device *dev)
spin_unlock_irq(&lp->lock);
+ free_irq(dev->irq, dev);
+
/* Free Descriptor memory */
if (lp->rx_ring) {
pci_free_consistent(pdev,
--
2.7.4
^ permalink raw reply related
* Re: [PATCH perf/core REBASE 2/5] samples/bpf: Switch over to libbpf
From: Arnaldo Carvalho de Melo @ 2016-12-15 18:29 UTC (permalink / raw)
To: Joe Stringer
Cc: linux-kernel, netdev, wangnan0, ast, daniel,
Arnaldo Carvalho de Melo
In-Reply-To: <20161215155022.GE6866@kernel.org>
Em Thu, Dec 15, 2016 at 12:50:22PM -0300, Arnaldo Carvalho de Melo escreveu:
> Em Wed, Dec 14, 2016 at 02:43:39PM -0800, Joe Stringer escreveu:
> > Now that libbpf under tools/lib/bpf/* is synced with the version from
> > samples/bpf, we can get rid most of the libbpf library here.
> >
> > Signed-off-by: Joe Stringer <joe@ovn.org>
> > Cc: Alexei Starovoitov <ast@fb.com>
> > Cc: Daniel Borkmann <daniel@iogearbox.net>
> > Cc: Wang Nan <wangnan0@huawei.com>
> > Link: http://lkml.kernel.org/r/20161209024620.31660-6-joe@ovn.org
> > [ Use -I$(srctree)/tools/lib/ to support out of source code tree builds, as noticed by Wang Nan ]
So, the above comment no longer applied to this adjusted patch from you,
as you removed one hunk too much, that, after applied, gets samples/bpf/
to build successfully:
diff --git a/samples/bpf/Makefile b/samples/bpf/Makefile
index add514e2984a..81b0ef2f7994 100644
--- a/samples/bpf/Makefile
+++ b/samples/bpf/Makefile
@@ -107,6 +107,7 @@ always += lwt_len_hist_kern.o
always += xdp_tx_iptunnel_kern.o
HOSTCFLAGS += -I$(objtree)/usr/include
+HOSTCFLAGS += -I$(srctree)/tools/lib/
HOSTCFLAGS += -I$(srctree)/tools/testing/selftests/bpf/
HOSTCFLAGS_bpf_load.o += -I$(objtree)/usr/include -Wno-unused-variable
---------------------
I added it, continuing...
- Arnaldo
> > Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
>
> So, right before this patch building samples/bpf works, then, after, it fails,
> investigating:
>
> [root@1e797fdfbf4f linux]# make -j4 O=/tmp/build/linux/ headers_install
> make[1]: Entering directory '/tmp/build/linux'
> CHK include/generated/uapi/linux/version.h
> make[1]: Leaving directory '/tmp/build/linux'
> [root@1e797fdfbf4f linux]# make -j4 O=/tmp/build/linux/ samples/bpf/
> make[1]: Entering directory '/tmp/build/linux'
> CHK include/config/kernel.release
> GEN ./Makefile
> CHK include/generated/uapi/linux/version.h
> Using /git/linux as source for kernel
> CHK include/generated/utsrelease.h
> CHK include/generated/timeconst.h
> CHK include/generated/bounds.h
> CHK include/generated/asm-offsets.h
> CALL /git/linux/scripts/checksyscalls.sh
> HOSTCC samples/bpf/test_lru_dist.o
> HOSTCC samples/bpf/libbpf.o
> HOSTCC samples/bpf/sock_example.o
> HOSTCC samples/bpf/bpf_load.o
> In file included from /git/linux/samples/bpf/libbpf.c:12:0:
> /git/linux/samples/bpf/libbpf.h:5:21: fatal error: bpf/bpf.h: No such file or directory
> #include <bpf/bpf.h>
> ^
> compilation terminated.
> In file included from /git/linux/samples/bpf/test_lru_dist.c:24:0:
> /git/linux/samples/bpf/libbpf.h:5:21: fatal error: bpf/bpf.h: No such file or directory
> #include <bpf/bpf.h>
> ^
> compilation terminated.
> make[2]: *** [scripts/Makefile.host:124: samples/bpf/test_lru_dist.o] Error 1
> make[2]: *** Waiting for unfinished jobs....
> make[2]: *** [scripts/Makefile.host:124: samples/bpf/libbpf.o] Error 1
> In file included from /git/linux/samples/bpf/bpf_load.c:24:0:
> /git/linux/samples/bpf/libbpf.h:5:21: fatal error: bpf/bpf.h: No such file or directory
> #include <bpf/bpf.h>
> ^
> compilation terminated.
> make[2]: *** [scripts/Makefile.host:124: samples/bpf/bpf_load.o] Error 1
> In file included from /git/linux/samples/bpf/sock_example.c:29:0:
> /git/linux/samples/bpf/libbpf.h:5:21: fatal error: bpf/bpf.h: No such file or directory
> #include <bpf/bpf.h>
> ^
> compilation terminated.
> make[2]: *** [scripts/Makefile.host:124: samples/bpf/sock_example.o] Error 1
> make[1]: *** [/git/linux/Makefile:1659: samples/bpf/] Error 2
> make[1]: Leaving directory '/tmp/build/linux'
> make: *** [Makefile:150: sub-make] Error 2
> [root@1e797fdfbf4f linux]#
^ permalink raw reply related
* Re: [PATCH perf/core REBASE 2/5] samples/bpf: Switch over to libbpf
From: Joe Stringer @ 2016-12-15 18:29 UTC (permalink / raw)
To: Arnaldo Carvalho de Melo
Cc: LKML, netdev, Wang Nan, ast, Daniel Borkmann,
Arnaldo Carvalho de Melo
In-Reply-To: <20161215155022.GE6866@kernel.org>
On 15 December 2016 at 07:50, Arnaldo Carvalho de Melo <acme@kernel.org> wrote:
> Em Wed, Dec 14, 2016 at 02:43:39PM -0800, Joe Stringer escreveu:
>> Now that libbpf under tools/lib/bpf/* is synced with the version from
>> samples/bpf, we can get rid most of the libbpf library here.
>>
>> Signed-off-by: Joe Stringer <joe@ovn.org>
>> Cc: Alexei Starovoitov <ast@fb.com>
>> Cc: Daniel Borkmann <daniel@iogearbox.net>
>> Cc: Wang Nan <wangnan0@huawei.com>
>> Link: http://lkml.kernel.org/r/20161209024620.31660-6-joe@ovn.org
>> [ Use -I$(srctree)/tools/lib/ to support out of source code tree builds, as noticed by Wang Nan ]
>> Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
>
> So, right before this patch building samples/bpf works, then, after, it fails,
> investigating:
>
> [root@1e797fdfbf4f linux]# make -j4 O=/tmp/build/linux/ headers_install
> make[1]: Entering directory '/tmp/build/linux'
> CHK include/generated/uapi/linux/version.h
> make[1]: Leaving directory '/tmp/build/linux'
> [root@1e797fdfbf4f linux]# make -j4 O=/tmp/build/linux/ samples/bpf/
> make[1]: Entering directory '/tmp/build/linux'
> CHK include/config/kernel.release
> GEN ./Makefile
> CHK include/generated/uapi/linux/version.h
> Using /git/linux as source for kernel
> CHK include/generated/utsrelease.h
> CHK include/generated/timeconst.h
> CHK include/generated/bounds.h
> CHK include/generated/asm-offsets.h
> CALL /git/linux/scripts/checksyscalls.sh
> HOSTCC samples/bpf/test_lru_dist.o
> HOSTCC samples/bpf/libbpf.o
> HOSTCC samples/bpf/sock_example.o
> HOSTCC samples/bpf/bpf_load.o
> In file included from /git/linux/samples/bpf/libbpf.c:12:0:
> /git/linux/samples/bpf/libbpf.h:5:21: fatal error: bpf/bpf.h: No such file or directory
> #include <bpf/bpf.h>
> ^
> compilation terminated.
> In file included from /git/linux/samples/bpf/test_lru_dist.c:24:0:
> /git/linux/samples/bpf/libbpf.h:5:21: fatal error: bpf/bpf.h: No such file or directory
> #include <bpf/bpf.h>
> ^
> compilation terminated.
> make[2]: *** [scripts/Makefile.host:124: samples/bpf/test_lru_dist.o] Error 1
> make[2]: *** Waiting for unfinished jobs....
> make[2]: *** [scripts/Makefile.host:124: samples/bpf/libbpf.o] Error 1
> In file included from /git/linux/samples/bpf/bpf_load.c:24:0:
> /git/linux/samples/bpf/libbpf.h:5:21: fatal error: bpf/bpf.h: No such file or directory
> #include <bpf/bpf.h>
> ^
> compilation terminated.
> make[2]: *** [scripts/Makefile.host:124: samples/bpf/bpf_load.o] Error 1
> In file included from /git/linux/samples/bpf/sock_example.c:29:0:
> /git/linux/samples/bpf/libbpf.h:5:21: fatal error: bpf/bpf.h: No such file or directory
> #include <bpf/bpf.h>
> ^
> compilation terminated.
> make[2]: *** [scripts/Makefile.host:124: samples/bpf/sock_example.o] Error 1
> make[1]: *** [/git/linux/Makefile:1659: samples/bpf/] Error 2
> make[1]: Leaving directory '/tmp/build/linux'
> make: *** [Makefile:150: sub-make] Error 2
> [root@1e797fdfbf4f linux]#
Sorry about that.
It looks like this fragment which ended up in "samples/bpf: Remove
perf_event_open() declaration" patch should be here instead:
diff --git a/samples/bpf/Makefile b/samples/bpf/Makefile
index add514e2984a..9718f664fedf 100644
--- a/samples/bpf/Makefile
+++ b/samples/bpf/Makefile
@@ -108,6 +108,8 @@ always += xdp_tx_iptunnel_kern.o
HOSTCFLAGS += -I$(objtree)/usr/include
HOSTCFLAGS += -I$(srctree)/tools/testing/selftests/bpf/
+HOSTCFLAGS += -I$(srctree)/tools/lib/ -I$(srctree)/tools/include
+HOSTCFLAGS += -I$(srctree)/tools/perf
HOSTCFLAGS_bpf_load.o += -I$(objtree)/usr/include -Wno-unused-variable
HOSTLOADLIBES_fds_example += -lelf
^ permalink raw reply related
* Re: [PATCH perf/core REBASE 2/5] samples/bpf: Switch over to libbpf
From: Arnaldo Carvalho de Melo @ 2016-12-15 18:34 UTC (permalink / raw)
To: Joe Stringer
Cc: linux-kernel, netdev, wangnan0, ast, daniel,
Arnaldo Carvalho de Melo
In-Reply-To: <20161215182918.GG6866@kernel.org>
Em Thu, Dec 15, 2016 at 03:29:18PM -0300, Arnaldo Carvalho de Melo escreveu:
> Em Thu, Dec 15, 2016 at 12:50:22PM -0300, Arnaldo Carvalho de Melo escreveu:
> > Em Wed, Dec 14, 2016 at 02:43:39PM -0800, Joe Stringer escreveu:
> > > Now that libbpf under tools/lib/bpf/* is synced with the version from
> > > samples/bpf, we can get rid most of the libbpf library here.
> > >
> > > Signed-off-by: Joe Stringer <joe@ovn.org>
> > > Cc: Alexei Starovoitov <ast@fb.com>
> > > Cc: Daniel Borkmann <daniel@iogearbox.net>
> > > Cc: Wang Nan <wangnan0@huawei.com>
> > > Link: http://lkml.kernel.org/r/20161209024620.31660-6-joe@ovn.org
> > > [ Use -I$(srctree)/tools/lib/ to support out of source code tree builds, as noticed by Wang Nan ]
>
> So, the above comment no longer applied to this adjusted patch from you,
> as you removed one hunk too much, that, after applied, gets samples/bpf/
> to build successfully:
>
> diff --git a/samples/bpf/Makefile b/samples/bpf/Makefile
> index add514e2984a..81b0ef2f7994 100644
> --- a/samples/bpf/Makefile
> +++ b/samples/bpf/Makefile
> @@ -107,6 +107,7 @@ always += lwt_len_hist_kern.o
> always += xdp_tx_iptunnel_kern.o
>
> HOSTCFLAGS += -I$(objtree)/usr/include
> +HOSTCFLAGS += -I$(srctree)/tools/lib/
> HOSTCFLAGS += -I$(srctree)/tools/testing/selftests/bpf/
>
> HOSTCFLAGS_bpf_load.o += -I$(objtree)/usr/include -Wno-unused-variable
>
> ---------------------
>
> I added it, continuing...
But then, when I tried to run offwaketime with it, it fails:
[root@jouet bpf]# ./offwaketime ls
bpf_load_program() err=22
BPF_LDX uses reserved fields
bpf_load_program() err=22
BPF_LDX uses reserved fields
[root@jouet bpf]#
If I remove this patch and try again, it works:
[root@jouet bpf]# ./offwaketime | head -4
swapper/1;start_secondary;cpu_startup_entry;schedule_preempt_disabled;schedule;__schedule;-;---;; 46
chrome;return_from_SYSCALL_64;do_syscall_64;exit_to_usermode_loop;schedule;__schedule;-;try_to_wake_up;do_futex;sys_futex;do_syscall_64;return_from_SYSCALL_64;;Chrome_ChildIOT 1
firefox;entry_SYSCALL_64_fastpath;sys_poll;do_sys_poll;poll_schedule_timeout;schedule_hrtimeout_range;schedule_hrtimeout_range_clock;schedule;__schedule;-;try_to_wake_up;pollwake;__wake_up_common;__wake_up_sync_key;pipe_write;__vfs_write;vfs_write;sys_write;entry_SYSCALL_64_fastpath;;Timer 3
dockerd-current;entry_SYSCALL_64_fastpath;sys_select;core_sys_select;do_select;poll_schedule_timeout;schedule_hrtimeout_range;schedule_hrtimeout_range_clock;schedule;__schedule;-;try_to_wake_up;futex_wake;do_futex;sys_futex;entry_SYSCALL_64_fastpath;;dockerd-current 2
[root@jouet bpf]#
So, I'm stopping here so that I can push what I have to Ingo, then I'll get
back to this, hopefully by then you beat me and I have just to retest 8-)
- Arnaldo
^ permalink raw reply
* Re: [PATCH perf/core REBASE 2/5] samples/bpf: Switch over to libbpf
From: Arnaldo Carvalho de Melo @ 2016-12-15 18:36 UTC (permalink / raw)
To: Joe Stringer
Cc: linux-kernel, netdev, wangnan0, ast, daniel,
Arnaldo Carvalho de Melo
In-Reply-To: <20161215183440.GH6866@kernel.org>
Em Thu, Dec 15, 2016 at 03:34:40PM -0300, Arnaldo Carvalho de Melo escreveu:
>
> So, I'm stopping here so that I can push what I have to Ingo, then I'll get
> back to this, hopefully by then you beat me and I have just to retest 8-)
Ah, I left what I have in the tmp.perf/samples-libbpf branch in my tree
at git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git.
I'll remove just the HEAD one and push the rest to Ingo.
- Arnaldo
^ 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