* RE: rdma-core release?
From: Woodruff, Robert J @ 2016-10-12 18:17 UTC (permalink / raw)
To: Jason Gunthorpe, 'Christoph Hellwig'
Cc: Steve Wise, 'Doug Ledford', 'Leon Romanovsky',
'linux-rdma', 'Vladimir Sokolovsky',
Davis, Arlin R
In-Reply-To: <20161012164759.GB18838-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
Jason wrote,
>One of the best ways to get it tested is to get it to go through the full OFED process.
>Woody, what could we do to help make that happen? Do you know of any blocker?
>I think this will be the best for everyone. I also predict that OFED will be under pressure to quickly take up the new drivers that will land in >4.9, and their user space will live in rdma-core.
>I also propose we give someone from the OFED team repo access and they can maintain a public branch for ofed-4.8 with any backported >fixes.
>Jason
We have just started work on OFED-4.8, so there is still a possibility to move to the new tree as the basis for the user-space code that
that goes into OFED. I think that Vlad (who is the OFED integration engineer) was waiting till things were a little more finalized
and wait till all packaging was flushed out before moving to the new code base. I think it would be desirable if there were some kind of official release tar ball or at least official release git tag that is recommended by you guys that we should use in OFED.
Currently the way OFED handles user-space packages is that we wait till the maintainer of a user-space package produces a release for their user-space component, which is a tar ball with the spec files that can be used to produce SRPMS.
I have not followed this really closely, but have you guys finalized how the packaging in SRPMs will/should work ? Or is that an exercise left up to the Linux distros and/or OFED to decide on ?
In any case, Vlad is on vacation for a couple weeks, so he probably cannot re-look at this until after Nov 1 when he returns, so you have some time to decide on how you want to handle releases for this.
woody
--
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: rdma-core release?
From: Doug Ledford @ 2016-10-12 18:15 UTC (permalink / raw)
To: Leon Romanovsky, Jason Gunthorpe
Cc: 'Christoph Hellwig', Steve Wise, 'linux-rdma',
robert.j.woodruff-ral2JQCrhuEAvxtiuMwx3w
In-Reply-To: <20161012173702.GW9282-2ukJVAZIZ/Y@public.gmane.org>
[-- Attachment #1.1: Type: text/plain, Size: 2238 bytes --]
On 10/12/2016 1:37 PM, Leon Romanovsky wrote:
> On Wed, Oct 12, 2016 at 10:47:59AM -0600, Jason Gunthorpe wrote:
>> On Wed, Oct 12, 2016 at 09:31:49AM -0700, 'Christoph Hellwig' wrote:
>>> On Wed, Oct 12, 2016 at 09:43:08AM -0500, Steve Wise wrote:
>>>> I recommend we release something for OFED-4.8 to pull in. That
>>>> might help flush out the release process earlier rather than
>>>> later. Either way, though, I want the latest libcxgb4 in OFED-4.8
>>>> to support the new chelsio HW. But we talked about the repo being
>>>> "always stable", so I guess the OFA could just pull the code and
>>>> use it? Still would be nice to have it released...
>>>
>>> Yeah, I'd much prefer to release early, release often. If people
>>> don't feel quite comfortable with the new bundle yet we can officially
>>> call it a pre-release.
>>
>> One of the best ways to get it tested is to get it to go through the
>> full OFED process.
>
> No problem, I'll grab all remaining patches from ML tomorrow and we will
> be ready for first release.
I wouldn't mind a pre-release, but I know for a fact that Jarod is
working on proper distro specific spec file(s), systemd units, etc. So,
I wouldn't call it a release because until we sort out the specifics of
how we want the package to build/look/etc., it might change. It would
be bad from for release 1 to have things packaged one way, and release 2
to totally revamp that. We need to give Jarod time to sort through what
he's working on and post it to the list.
>>
>> Woody, what could we do to help make that happen? Do you know of any
>> blocker?
>>
>> I think this will be the best for everyone. I also predict that OFED
>> will be under pressure to quickly take up the new drivers that will
>> land in 4.9, and their user space will live in rdma-core.
>>
>> I also propose we give someone from the OFED team repo access and they
>> can maintain a public branch for ofed-4.8 with any backported fixes.
>
> First of them, they need to express desire :)
> Let's start from pull request model and see if it is enough/not enough.
>
>>
>> Jason
--
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
GPG Key ID: 0E572FDD
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]
^ permalink raw reply
* Re: [PATCH 26/28] Avoid gcc 5.4 warning -Wunused-result
From: Doug Ledford @ 2016-10-12 18:07 UTC (permalink / raw)
To: Yishai Hadas, Jason Gunthorpe
Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA, Devesh Sharma, Hal Rosenstock,
Mike Marciniszyn, Moni Shoua, Sean Hefty, Steve Wise,
Tatyana Nikolova, Vladimir Sokolovsky, Yishai Hadas
In-Reply-To: <1e022827-f28c-e2cd-2b6a-edfb713ed0b5-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org>
[-- Attachment #1.1: Type: text/plain, Size: 853 bytes --]
On 10/10/2016 6:06 AM, Yishai Hadas wrote:
> On 10/10/2016 2:19 AM, Jason Gunthorpe wrote:
>> On Sun, Oct 09, 2016 at 04:31:17PM +0300, Yishai Hadas wrote:
>>
>>>> - if (write(connfd, msg, sizeof msg) != sizeof msg) {
>>>> - fprintf(stderr, "Couldn't send local address\n");
>>>> + if (write(connfd, msg, sizeof msg) != sizeof msg ||
>>>> + read(connfd, msg, sizeof msg) != sizeof msg) {
>>>> + fprintf(stderr, "Couldn't send/recv local address\n");
>>>
>>> At that step the server expects to read a "done" response from its
>>> client,
>>> checking whether the read was done for sizeof msg which is much
>>> larger will
>>> fail.
>>
>> This OK?
>
> Yes, below patch solves the issue.
Merged, thanks.
--
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
GPG Key ID: 0E572FDD
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]
^ permalink raw reply
* Re: [PATCH rdma-core 0/5] clang support
From: Doug Ledford @ 2016-10-12 18:07 UTC (permalink / raw)
To: Jason Gunthorpe, linux-rdma-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1475879772-29458-1-git-send-email-jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
[-- Attachment #1.1: Type: text/plain, Size: 1518 bytes --]
On 10/7/2016 6:36 PM, Jason Gunthorpe wrote:
> This series gets clang running warning free and has travis run the build
> through clang-3.9 so we don't break it again.
>
> Jason Gunthorpe (5):
> Pull uninitialized_var into util/compiler.h
> ibacm: Avoid clang 3.8 warning -Wmissing-field-initializers
> mthca: Avoid bogus gcc 4.8 warning -Wmaybe-uninitialized
> Improve linker flag detection to work with clang and -Werror
> Update TravisCI to use clang 3.9 as well
>
> .travis.yml | 20 +++++++++++++++++---
> CMakeLists.txt | 22 ++++++++++++++--------
> buildlib/FindLDSymVer.cmake | 16 ++++++++++++----
> buildlib/RDMA_EnableCStd.cmake | 25 +++++++++++++++++++++++++
> ibacm/prov/acmp/src/acmp.c | 2 +-
> providers/cxgb4/cq.c | 1 +
> providers/cxgb4/libcxgb4.h | 2 --
> providers/cxgb4/qp.c | 1 +
> providers/mlx4/mlx4.h | 4 ----
> providers/mlx4/qp.c | 1 +
> providers/mlx5/mlx5.h | 4 ----
> providers/mlx5/qp.c | 1 +
> providers/mthca/qp.c | 23 +++++------------------
> util/CMakeLists.txt | 3 +++
> util/compiler.h | 18 ++++++++++++++++++
> 15 files changed, 99 insertions(+), 44 deletions(-)
> create mode 100644 util/CMakeLists.txt
> create mode 100644 util/compiler.h
>
Series merged. Thanks.
--
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
GPG Key ID: 0E572FDD
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]
^ permalink raw reply
* Re: rdma-core release?
From: Leon Romanovsky @ 2016-10-12 17:37 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: 'Christoph Hellwig', Steve Wise, 'Doug Ledford',
'linux-rdma', robert.j.woodruff-ral2JQCrhuEAvxtiuMwx3w
In-Reply-To: <20161012164759.GB18838-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1548 bytes --]
On Wed, Oct 12, 2016 at 10:47:59AM -0600, Jason Gunthorpe wrote:
> On Wed, Oct 12, 2016 at 09:31:49AM -0700, 'Christoph Hellwig' wrote:
> > On Wed, Oct 12, 2016 at 09:43:08AM -0500, Steve Wise wrote:
> > > I recommend we release something for OFED-4.8 to pull in. That
> > > might help flush out the release process earlier rather than
> > > later. Either way, though, I want the latest libcxgb4 in OFED-4.8
> > > to support the new chelsio HW. But we talked about the repo being
> > > "always stable", so I guess the OFA could just pull the code and
> > > use it? Still would be nice to have it released...
> >
> > Yeah, I'd much prefer to release early, release often. If people
> > don't feel quite comfortable with the new bundle yet we can officially
> > call it a pre-release.
>
> One of the best ways to get it tested is to get it to go through the
> full OFED process.
No problem, I'll grab all remaining patches from ML tomorrow and we will
be ready for first release.
>
> Woody, what could we do to help make that happen? Do you know of any
> blocker?
>
> I think this will be the best for everyone. I also predict that OFED
> will be under pressure to quickly take up the new drivers that will
> land in 4.9, and their user space will live in rdma-core.
>
> I also propose we give someone from the OFED team repo access and they
> can maintain a public branch for ofed-4.8 with any backported fixes.
First of them, they need to express desire :)
Let's start from pull request model and see if it is enough/not enough.
>
> Jason
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH] add a build.sh helper to allow for a one-stop build
From: Leon Romanovsky @ 2016-10-12 17:31 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Christoph Hellwig, Bart Van Assche,
linux-rdma-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20161012163834.GA18838-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 262 bytes --]
On Wed, Oct 12, 2016 at 10:38:34AM -0600, Jason Gunthorpe wrote:
> On Wed, Oct 12, 2016 at 03:22:20PM +0300, Leon Romanovsky wrote:
>
> > Done, applied.
>
> Are you going to sweep up the rest of the list patches too?
Yes, I'll do it tomorrow.
Thanks
>
> Jason
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: rdma-core release?
From: Jason Gunthorpe @ 2016-10-12 16:47 UTC (permalink / raw)
To: 'Christoph Hellwig'
Cc: Steve Wise, 'Doug Ledford', 'Leon Romanovsky',
'linux-rdma', robert.j.woodruff-ral2JQCrhuEAvxtiuMwx3w
In-Reply-To: <20161012163149.GA20174-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
On Wed, Oct 12, 2016 at 09:31:49AM -0700, 'Christoph Hellwig' wrote:
> On Wed, Oct 12, 2016 at 09:43:08AM -0500, Steve Wise wrote:
> > I recommend we release something for OFED-4.8 to pull in. That
> > might help flush out the release process earlier rather than
> > later. Either way, though, I want the latest libcxgb4 in OFED-4.8
> > to support the new chelsio HW. But we talked about the repo being
> > "always stable", so I guess the OFA could just pull the code and
> > use it? Still would be nice to have it released...
>
> Yeah, I'd much prefer to release early, release often. If people
> don't feel quite comfortable with the new bundle yet we can officially
> call it a pre-release.
One of the best ways to get it tested is to get it to go through the
full OFED process.
Woody, what could we do to help make that happen? Do you know of any
blocker?
I think this will be the best for everyone. I also predict that OFED
will be under pressure to quickly take up the new drivers that will
land in 4.9, and their user space will live in rdma-core.
I also propose we give someone from the OFED team repo access and they
can maintain a public branch for ofed-4.8 with any backported fixes.
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] add a build.sh helper to allow for a one-stop build
From: Jason Gunthorpe @ 2016-10-12 16:38 UTC (permalink / raw)
To: Leon Romanovsky
Cc: Christoph Hellwig, Bart Van Assche,
linux-rdma-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20161012122220.GU9282-2ukJVAZIZ/Y@public.gmane.org>
On Wed, Oct 12, 2016 at 03:22:20PM +0300, Leon Romanovsky wrote:
> Done, applied.
Are you going to sweep up the rest of the list patches too?
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: rdma-core release?
From: 'Christoph Hellwig' @ 2016-10-12 16:31 UTC (permalink / raw)
To: Steve Wise
Cc: 'Doug Ledford', 'Leon Romanovsky',
'Christoph Hellwig', 'linux-rdma'
In-Reply-To: <00c801d22496$f31798f0$d946cad0$@opengridcomputing.com>
On Wed, Oct 12, 2016 at 09:43:08AM -0500, Steve Wise wrote:
> I recommend we release something for OFED-4.8 to pull in. That might help flush out the release process earlier rather than later. Either way, though, I want the latest libcxgb4 in OFED-4.8 to support the new chelsio HW. But we talked about the repo being "always stable", so I guess the OFA could just pull the code and use it? Still would be nice to have it released...
Yeah, I'd much prefer to release early, release often. If people
don't feel quite comfortable with the new bundle yet we can officially
call it a pre-release.
--
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: rdma-core release?
From: Steve Wise @ 2016-10-12 14:43 UTC (permalink / raw)
To: 'Doug Ledford', 'Leon Romanovsky',
'Christoph Hellwig'
Cc: 'linux-rdma'
In-Reply-To: <59ebde13-0fcd-0640-e750-bb6e57bfb921-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
>
> On 10/12/2016 7:43 AM, Leon Romanovsky wrote:
> > On Wed, Oct 12, 2016 at 1:51 PM, Christoph Hellwig <hch-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org> wrote:
> >> Are we planning on having a rdma-core release now that 4.8 is out
> >> and we want a matching userspace release?
> >
> > As far as I remember, the initial plan was to use this library
> > immediately, but first release was planned to be at the 4.9
> > announcement to ensure that it runs smoothly.
>
> Correct.
>
I recommend we release something for OFED-4.8 to pull in. That might help flush out the release process earlier rather than later. Either way, though, I want the latest libcxgb4 in OFED-4.8 to support the new chelsio HW. But we talked about the repo being "always stable", so I guess the OFA could just pull the code and use it? Still would be nice to have it released...
Steve.
--
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
* [PATCH v2] IB/ipoib: move back IB LL address into the hard header
From: Paolo Abeni @ 2016-10-12 14:30 UTC (permalink / raw)
To: linux-rdma
Cc: Doug Ledford, Sean Hefty, Hal Rosenstock, Jason Gunthorpe, netdev
After the commit 9207f9d45b0a ("net: preserve IP control block
during GSO segmentation"), the GSO CB and the IPoIB CB conflict.
That destroy the IPoIB address information cached there,
causing a severe performance regression, as better described here:
http://marc.info/?l=linux-kernel&m=146787279825501&w=2
This change moves the data cached by the IPoIB driver from the
skb control lock into the IPoIB hard header, as done before
the commit 936d7de3d736 ("IPoIB: Stop lying about hard_header_len
and use skb->cb to stash LL addresses").
In order to avoid GRO issue, on packet reception, the IPoIB driver
stash into the skb a dummy pseudo header, so that the received
packets have actually a hard header matching the declared length.
To avoid changing the connected mode maximum mtu, the allocated
head buffer size is increased by the pseudo header length.
After this commit, IPoIB performances are back to pre-regression
value.
v1 -> v2: avoid changing the max mtu, increasing the head buf size
Fixes: 9207f9d45b0a ("net: preserve IP control block during GSO segmentation")
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
---
drivers/infiniband/ulp/ipoib/ipoib.h | 20 +++++++---
drivers/infiniband/ulp/ipoib/ipoib_cm.c | 15 +++----
drivers/infiniband/ulp/ipoib/ipoib_ib.c | 12 +++---
drivers/infiniband/ulp/ipoib/ipoib_main.c | 54 ++++++++++++++++----------
drivers/infiniband/ulp/ipoib/ipoib_multicast.c | 6 ++-
5 files changed, 64 insertions(+), 43 deletions(-)
diff --git a/drivers/infiniband/ulp/ipoib/ipoib.h b/drivers/infiniband/ulp/ipoib/ipoib.h
index 9dbfcc0..5ff64af 100644
--- a/drivers/infiniband/ulp/ipoib/ipoib.h
+++ b/drivers/infiniband/ulp/ipoib/ipoib.h
@@ -63,6 +63,8 @@ enum ipoib_flush_level {
enum {
IPOIB_ENCAP_LEN = 4,
+ IPOIB_PSEUDO_LEN = 20,
+ IPOIB_HARD_LEN = IPOIB_ENCAP_LEN + IPOIB_PSEUDO_LEN,
IPOIB_UD_HEAD_SIZE = IB_GRH_BYTES + IPOIB_ENCAP_LEN,
IPOIB_UD_RX_SG = 2, /* max buffer needed for 4K mtu */
@@ -134,15 +136,21 @@ struct ipoib_header {
u16 reserved;
};
-struct ipoib_cb {
- struct qdisc_skb_cb qdisc_cb;
- u8 hwaddr[INFINIBAND_ALEN];
+struct ipoib_pseudo_header {
+ u8 hwaddr[INFINIBAND_ALEN];
};
-static inline struct ipoib_cb *ipoib_skb_cb(const struct sk_buff *skb)
+static inline void skb_add_pseudo_hdr(struct sk_buff *skb)
{
- BUILD_BUG_ON(sizeof(skb->cb) < sizeof(struct ipoib_cb));
- return (struct ipoib_cb *)skb->cb;
+ char *data = skb_push(skb, IPOIB_PSEUDO_LEN);
+
+ /*
+ * only the ipoib header is present now, make room for a dummy
+ * pseudo header and set skb field accordingly
+ */
+ memset(data, 0, IPOIB_PSEUDO_LEN);
+ skb_reset_mac_header(skb);
+ skb_pull(skb, IPOIB_HARD_LEN);
}
/* Used for all multicast joins (broadcast, IPv4 mcast and IPv6 mcast) */
diff --git a/drivers/infiniband/ulp/ipoib/ipoib_cm.c b/drivers/infiniband/ulp/ipoib/ipoib_cm.c
index 4ad297d..339a1ee 100644
--- a/drivers/infiniband/ulp/ipoib/ipoib_cm.c
+++ b/drivers/infiniband/ulp/ipoib/ipoib_cm.c
@@ -63,6 +63,8 @@ MODULE_PARM_DESC(cm_data_debug_level,
#define IPOIB_CM_RX_DELAY (3 * 256 * HZ)
#define IPOIB_CM_RX_UPDATE_MASK (0x3)
+#define IPOIB_CM_RX_RESERVE (ALIGN(IPOIB_HARD_LEN, 16) - IPOIB_ENCAP_LEN)
+
static struct ib_qp_attr ipoib_cm_err_attr = {
.qp_state = IB_QPS_ERR
};
@@ -146,15 +148,15 @@ static struct sk_buff *ipoib_cm_alloc_rx_skb(struct net_device *dev,
struct sk_buff *skb;
int i;
- skb = dev_alloc_skb(IPOIB_CM_HEAD_SIZE + 12);
+ skb = dev_alloc_skb(ALIGN(IPOIB_CM_HEAD_SIZE + IPOIB_PSEUDO_LEN, 16));
if (unlikely(!skb))
return NULL;
/*
- * IPoIB adds a 4 byte header. So we need 12 more bytes to align the
+ * IPoIB adds a IPOIB_ENCAP_LEN byte header, this will align the
* IP header to a multiple of 16.
*/
- skb_reserve(skb, 12);
+ skb_reserve(skb, IPOIB_CM_RX_RESERVE);
mapping[0] = ib_dma_map_single(priv->ca, skb->data, IPOIB_CM_HEAD_SIZE,
DMA_FROM_DEVICE);
@@ -624,9 +626,9 @@ void ipoib_cm_handle_rx_wc(struct net_device *dev, struct ib_wc *wc)
if (wc->byte_len < IPOIB_CM_COPYBREAK) {
int dlen = wc->byte_len;
- small_skb = dev_alloc_skb(dlen + 12);
+ small_skb = dev_alloc_skb(dlen + IPOIB_CM_RX_RESERVE);
if (small_skb) {
- skb_reserve(small_skb, 12);
+ skb_reserve(small_skb, IPOIB_CM_RX_RESERVE);
ib_dma_sync_single_for_cpu(priv->ca, rx_ring[wr_id].mapping[0],
dlen, DMA_FROM_DEVICE);
skb_copy_from_linear_data(skb, small_skb->data, dlen);
@@ -663,8 +665,7 @@ void ipoib_cm_handle_rx_wc(struct net_device *dev, struct ib_wc *wc)
copied:
skb->protocol = ((struct ipoib_header *) skb->data)->proto;
- skb_reset_mac_header(skb);
- skb_pull(skb, IPOIB_ENCAP_LEN);
+ skb_add_pseudo_hdr(skb);
++dev->stats.rx_packets;
dev->stats.rx_bytes += skb->len;
diff --git a/drivers/infiniband/ulp/ipoib/ipoib_ib.c b/drivers/infiniband/ulp/ipoib/ipoib_ib.c
index be11d5d..830fecb 100644
--- a/drivers/infiniband/ulp/ipoib/ipoib_ib.c
+++ b/drivers/infiniband/ulp/ipoib/ipoib_ib.c
@@ -128,16 +128,15 @@ static struct sk_buff *ipoib_alloc_rx_skb(struct net_device *dev, int id)
buf_size = IPOIB_UD_BUF_SIZE(priv->max_ib_mtu);
- skb = dev_alloc_skb(buf_size + IPOIB_ENCAP_LEN);
+ skb = dev_alloc_skb(buf_size + IPOIB_HARD_LEN);
if (unlikely(!skb))
return NULL;
/*
- * IB will leave a 40 byte gap for a GRH and IPoIB adds a 4 byte
- * header. So we need 4 more bytes to get to 48 and align the
- * IP header to a multiple of 16.
+ * the IP header will be at IPOIP_HARD_LEN + IB_GRH_BYTES, that is
+ * 64 bytes aligned
*/
- skb_reserve(skb, 4);
+ skb_reserve(skb, sizeof(struct ipoib_pseudo_header));
mapping = priv->rx_ring[id].mapping;
mapping[0] = ib_dma_map_single(priv->ca, skb->data, buf_size,
@@ -253,8 +252,7 @@ static void ipoib_ib_handle_rx_wc(struct net_device *dev, struct ib_wc *wc)
skb_pull(skb, IB_GRH_BYTES);
skb->protocol = ((struct ipoib_header *) skb->data)->proto;
- skb_reset_mac_header(skb);
- skb_pull(skb, IPOIB_ENCAP_LEN);
+ skb_add_pseudo_hdr(skb);
++dev->stats.rx_packets;
dev->stats.rx_bytes += skb->len;
diff --git a/drivers/infiniband/ulp/ipoib/ipoib_main.c b/drivers/infiniband/ulp/ipoib/ipoib_main.c
index cc1c1b0..823a528 100644
--- a/drivers/infiniband/ulp/ipoib/ipoib_main.c
+++ b/drivers/infiniband/ulp/ipoib/ipoib_main.c
@@ -925,9 +925,12 @@ static void neigh_add_path(struct sk_buff *skb, u8 *daddr,
ipoib_neigh_free(neigh);
goto err_drop;
}
- if (skb_queue_len(&neigh->queue) < IPOIB_MAX_PATH_REC_QUEUE)
+ if (skb_queue_len(&neigh->queue) <
+ IPOIB_MAX_PATH_REC_QUEUE) {
+ /* put pseudoheader back on for next time */
+ skb_push(skb, IPOIB_PSEUDO_LEN);
__skb_queue_tail(&neigh->queue, skb);
- else {
+ } else {
ipoib_warn(priv, "queue length limit %d. Packet drop.\n",
skb_queue_len(&neigh->queue));
goto err_drop;
@@ -964,7 +967,7 @@ err_drop:
}
static void unicast_arp_send(struct sk_buff *skb, struct net_device *dev,
- struct ipoib_cb *cb)
+ struct ipoib_pseudo_header *phdr)
{
struct ipoib_dev_priv *priv = netdev_priv(dev);
struct ipoib_path *path;
@@ -972,16 +975,18 @@ static void unicast_arp_send(struct sk_buff *skb, struct net_device *dev,
spin_lock_irqsave(&priv->lock, flags);
- path = __path_find(dev, cb->hwaddr + 4);
+ path = __path_find(dev, phdr->hwaddr + 4);
if (!path || !path->valid) {
int new_path = 0;
if (!path) {
- path = path_rec_create(dev, cb->hwaddr + 4);
+ path = path_rec_create(dev, phdr->hwaddr + 4);
new_path = 1;
}
if (path) {
if (skb_queue_len(&path->queue) < IPOIB_MAX_PATH_REC_QUEUE) {
+ /* put pseudoheader back on for next time */
+ skb_push(skb, IPOIB_PSEUDO_LEN);
__skb_queue_tail(&path->queue, skb);
} else {
++dev->stats.tx_dropped;
@@ -1009,10 +1014,12 @@ static void unicast_arp_send(struct sk_buff *skb, struct net_device *dev,
be16_to_cpu(path->pathrec.dlid));
spin_unlock_irqrestore(&priv->lock, flags);
- ipoib_send(dev, skb, path->ah, IPOIB_QPN(cb->hwaddr));
+ ipoib_send(dev, skb, path->ah, IPOIB_QPN(phdr->hwaddr));
return;
} else if ((path->query || !path_rec_start(dev, path)) &&
skb_queue_len(&path->queue) < IPOIB_MAX_PATH_REC_QUEUE) {
+ /* put pseudoheader back on for next time */
+ skb_push(skb, IPOIB_PSEUDO_LEN);
__skb_queue_tail(&path->queue, skb);
} else {
++dev->stats.tx_dropped;
@@ -1026,13 +1033,15 @@ static int ipoib_start_xmit(struct sk_buff *skb, struct net_device *dev)
{
struct ipoib_dev_priv *priv = netdev_priv(dev);
struct ipoib_neigh *neigh;
- struct ipoib_cb *cb = ipoib_skb_cb(skb);
+ struct ipoib_pseudo_header *phdr;
struct ipoib_header *header;
unsigned long flags;
+ phdr = (struct ipoib_pseudo_header *) skb->data;
+ skb_pull(skb, sizeof(*phdr));
header = (struct ipoib_header *) skb->data;
- if (unlikely(cb->hwaddr[4] == 0xff)) {
+ if (unlikely(phdr->hwaddr[4] == 0xff)) {
/* multicast, arrange "if" according to probability */
if ((header->proto != htons(ETH_P_IP)) &&
(header->proto != htons(ETH_P_IPV6)) &&
@@ -1045,13 +1054,13 @@ static int ipoib_start_xmit(struct sk_buff *skb, struct net_device *dev)
return NETDEV_TX_OK;
}
/* Add in the P_Key for multicast*/
- cb->hwaddr[8] = (priv->pkey >> 8) & 0xff;
- cb->hwaddr[9] = priv->pkey & 0xff;
+ phdr->hwaddr[8] = (priv->pkey >> 8) & 0xff;
+ phdr->hwaddr[9] = priv->pkey & 0xff;
- neigh = ipoib_neigh_get(dev, cb->hwaddr);
+ neigh = ipoib_neigh_get(dev, phdr->hwaddr);
if (likely(neigh))
goto send_using_neigh;
- ipoib_mcast_send(dev, cb->hwaddr, skb);
+ ipoib_mcast_send(dev, phdr->hwaddr, skb);
return NETDEV_TX_OK;
}
@@ -1060,16 +1069,16 @@ static int ipoib_start_xmit(struct sk_buff *skb, struct net_device *dev)
case htons(ETH_P_IP):
case htons(ETH_P_IPV6):
case htons(ETH_P_TIPC):
- neigh = ipoib_neigh_get(dev, cb->hwaddr);
+ neigh = ipoib_neigh_get(dev, phdr->hwaddr);
if (unlikely(!neigh)) {
- neigh_add_path(skb, cb->hwaddr, dev);
+ neigh_add_path(skb, phdr->hwaddr, dev);
return NETDEV_TX_OK;
}
break;
case htons(ETH_P_ARP):
case htons(ETH_P_RARP):
/* for unicast ARP and RARP should always perform path find */
- unicast_arp_send(skb, dev, cb);
+ unicast_arp_send(skb, dev, phdr);
return NETDEV_TX_OK;
default:
/* ethertype not supported by IPoIB */
@@ -1086,11 +1095,13 @@ send_using_neigh:
goto unref;
}
} else if (neigh->ah) {
- ipoib_send(dev, skb, neigh->ah, IPOIB_QPN(cb->hwaddr));
+ ipoib_send(dev, skb, neigh->ah, IPOIB_QPN(phdr->hwaddr));
goto unref;
}
if (skb_queue_len(&neigh->queue) < IPOIB_MAX_PATH_REC_QUEUE) {
+ /* put pseudoheader back on for next time */
+ skb_push(skb, sizeof(*phdr));
spin_lock_irqsave(&priv->lock, flags);
__skb_queue_tail(&neigh->queue, skb);
spin_unlock_irqrestore(&priv->lock, flags);
@@ -1122,8 +1133,8 @@ static int ipoib_hard_header(struct sk_buff *skb,
unsigned short type,
const void *daddr, const void *saddr, unsigned len)
{
+ struct ipoib_pseudo_header *phdr;
struct ipoib_header *header;
- struct ipoib_cb *cb = ipoib_skb_cb(skb);
header = (struct ipoib_header *) skb_push(skb, sizeof *header);
@@ -1132,12 +1143,13 @@ static int ipoib_hard_header(struct sk_buff *skb,
/*
* we don't rely on dst_entry structure, always stuff the
- * destination address into skb->cb so we can figure out where
+ * destination address into skb hard header so we can figure out where
* to send the packet later.
*/
- memcpy(cb->hwaddr, daddr, INFINIBAND_ALEN);
+ phdr = (struct ipoib_pseudo_header *) skb_push(skb, sizeof(*phdr));
+ memcpy(phdr->hwaddr, daddr, INFINIBAND_ALEN);
- return sizeof *header;
+ return IPOIB_HARD_LEN;
}
static void ipoib_set_mcast_list(struct net_device *dev)
@@ -1759,7 +1771,7 @@ void ipoib_setup(struct net_device *dev)
dev->flags |= IFF_BROADCAST | IFF_MULTICAST;
- dev->hard_header_len = IPOIB_ENCAP_LEN;
+ dev->hard_header_len = IPOIB_HARD_LEN;
dev->addr_len = INFINIBAND_ALEN;
dev->type = ARPHRD_INFINIBAND;
dev->tx_queue_len = ipoib_sendq_size * 2;
diff --git a/drivers/infiniband/ulp/ipoib/ipoib_multicast.c b/drivers/infiniband/ulp/ipoib/ipoib_multicast.c
index d3394b6..1909dd2 100644
--- a/drivers/infiniband/ulp/ipoib/ipoib_multicast.c
+++ b/drivers/infiniband/ulp/ipoib/ipoib_multicast.c
@@ -796,9 +796,11 @@ void ipoib_mcast_send(struct net_device *dev, u8 *daddr, struct sk_buff *skb)
__ipoib_mcast_add(dev, mcast);
list_add_tail(&mcast->list, &priv->multicast_list);
}
- if (skb_queue_len(&mcast->pkt_queue) < IPOIB_MAX_MCAST_QUEUE)
+ if (skb_queue_len(&mcast->pkt_queue) < IPOIB_MAX_MCAST_QUEUE) {
+ /* put pseudoheader back on for next time */
+ skb_push(skb, sizeof(struct ipoib_pseudo_header));
skb_queue_tail(&mcast->pkt_queue, skb);
- else {
+ } else {
++dev->stats.tx_dropped;
dev_kfree_skb_any(skb);
}
--
1.8.3.1
^ permalink raw reply related
* false checkpatch finding?
From: Marciniszyn, Mike @ 2016-10-12 14:04 UTC (permalink / raw)
To: Andy Whitcroft, Joe Perches
Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
<4.8 tree>/scripts/checkpatch.pl -F foo.h
WARNING: Missing a blank line after declarations
#3: FILE: foo.h:3:
+ unsigned long f1;
+ volatile __le64 f2.
WARNING: Use of volatile is usually wrong: see Documentation/volatile-considered-harmful.txt
#3: FILE: foo.h:3:
+ volatile __le64 f2.
total: 0 errors, 2 warnings, 4 lines checked
NOTE: For some of the reported defects, checkpatch may be able to
mechanically convert to the typical style using --fix or --fix-inplace.
foo.h has style problems, please review.
NOTE: If any of the errors are false positives, please report
them to the maintainer, see CHECKPATCH in MAINTAINERS.
Adding a gratuitous blank line after f1 silences the bogus warning.
The volatile warning is ok because this is a hardware written field.
Snip the test file from below.
Mike
<snip foo.h>
struct foo {
unsigned long f1;
volatile __le64 f2.
};
</snip foo.h>
--
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: [bug report] IB/hfi1: Prevent NULL pointer deferences in caching code
From: Dalessandro, Dennis @ 2016-10-12 13:43 UTC (permalink / raw)
To: Haralanov, Mitko,
dan.carpenter-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org
Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <20161012060402.GC12841@mwanda>
Thanks Dan, we'll take care of it.
-Denny
On Wed, 2016-10-12 at 09:06 +0300, Dan Carpenter wrote:
> Hello Mitko Haralanov,
>
> The patch f19bd643dbde: "IB/hfi1: Prevent NULL pointer deferences in
> caching code" from Apr 12, 2016, leads to the following static
> checker warning:
>
> drivers/infiniband/hw/hfi1/user_sdma.c:1147 pin_vector_pages()
> warn: 'rb_node' isn't an ERR_PTR
>
> drivers/infiniband/hw/hfi1/user_sdma.c
> 1135 static int pin_vector_pages(struct user_sdma_request *req,
> 1136 struct user_sdma_iovec *iovec)
> 1137 {
> 1138 int ret = 0, pinned, npages, cleared;
> 1139 struct page **pages;
> 1140 struct hfi1_user_sdma_pkt_q *pq = req->pq;
> 1141 struct sdma_mmu_node *node = NULL;
> 1142 struct mmu_rb_node *rb_node;
> 1143
> 1144 rb_node = hfi1_mmu_rb_extract(pq->handler,
> 1145 (unsigned long)iovec-
> >iov.iov_base,
> 1146 iovec->iov.iov_len);
> 1147 if (rb_node && !IS_ERR(rb_node))
> ^^^^^^^^^^^^^^^
>
> hfi1_mmu_rb_extract() never returns error pointers. Plz delete.
>
> 1148 node = container_of(rb_node, struct
> sdma_mmu_node, rb);
> 1149 else
> 1150 rb_node = NULL;
> 1151
> 1152 if (!node) {
> 1153 node = kzalloc(sizeof(*node), GFP_KERNEL);
> 1154 if (!node)
> 1155 return -ENOMEM;
> 1156
> 1157 node->rb.addr = (unsigned long)iovec-
> >iov.iov_base;
> 1158 node->pq = pq;
> 1159 atomic_set(&node->refcount, 0);
> 1160 }
>
> regards,
> dan carpenter
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rdma"
> 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: rdma-core release?
From: Doug Ledford @ 2016-10-12 13:00 UTC (permalink / raw)
To: Leon Romanovsky, Christoph Hellwig; +Cc: linux-rdma
In-Reply-To: <CALq1K=JEkvN_4tZL9D53c6-EH9E4efay8rmoyBEyB-7Sxr6H-w-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
[-- Attachment #1.1: Type: text/plain, Size: 566 bytes --]
On 10/12/2016 7:43 AM, Leon Romanovsky wrote:
> On Wed, Oct 12, 2016 at 1:51 PM, Christoph Hellwig <hch-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org> wrote:
>> Are we planning on having a rdma-core release now that 4.8 is out
>> and we want a matching userspace release?
>
> As far as I remember, the initial plan was to use this library
> immediately, but first release was planned to be at the 4.9
> announcement to ensure that it runs smoothly.
Correct.
--
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
GPG Key ID: 0E572FDD
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]
^ permalink raw reply
* Re: [PATCH] add a build.sh helper to allow for a one-stop build
From: Leon Romanovsky @ 2016-10-12 12:22 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Jason Gunthorpe, Bart Van Assche,
linux-rdma-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20161012121845.GT9282-2ukJVAZIZ/Y@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 466 bytes --]
On Wed, Oct 12, 2016 at 03:18:45PM +0300, Leon Romanovsky wrote:
> On Wed, Oct 12, 2016 at 12:52:08PM +0200, Christoph Hellwig wrote:
> > [full quote deleted, sigh..]
> >
> > > What do you think about following code, instead of 3 lines above?
> > >
> > > + mkdir -p "$BUILDDIR"
> >
> > Fine with me. Feel free to send an incremental patch.
>
> https://github.com/linux-rdma/rdma-core/pull/17
>
> I'll apply it once travis will finish.
Done, applied.
>
> Thanks
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH] add a build.sh helper to allow for a one-stop build
From: Leon Romanovsky @ 2016-10-12 12:18 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Jason Gunthorpe, Bart Van Assche,
linux-rdma-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20161012105208.GA9491-jcswGhMUV9g@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 357 bytes --]
On Wed, Oct 12, 2016 at 12:52:08PM +0200, Christoph Hellwig wrote:
> [full quote deleted, sigh..]
>
> > What do you think about following code, instead of 3 lines above?
> >
> > + mkdir -p "$BUILDDIR"
>
> Fine with me. Feel free to send an incremental patch.
https://github.com/linux-rdma/rdma-core/pull/17
I'll apply it once travis will finish.
Thanks
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: rdma-core release?
From: Leon Romanovsky @ 2016-10-12 11:43 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: linux-rdma
In-Reply-To: <20161012105103.GA30534-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
On Wed, Oct 12, 2016 at 1:51 PM, Christoph Hellwig <hch-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org> wrote:
> Are we planning on having a rdma-core release now that 4.8 is out
> and we want a matching userspace release?
As far as I remember, the initial plan was to use this library
immediately, but first release was planned to be at the 4.9
announcement to ensure that it runs smoothly.
> --
> 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
--
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] add a build.sh helper to allow for a one-stop build
From: Christoph Hellwig @ 2016-10-12 10:52 UTC (permalink / raw)
To: Leon Romanovsky
Cc: Jason Gunthorpe, Bart Van Assche, Christoph Hellwig,
linux-rdma-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20161012093015.GS9282-2ukJVAZIZ/Y@public.gmane.org>
[full quote deleted, sigh..]
> What do you think about following code, instead of 3 lines above?
>
> + mkdir -p "$BUILDDIR"
Fine with me. Feel free to send an incremental patch.
--
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
* rdma-core release?
From: Christoph Hellwig @ 2016-10-12 10:51 UTC (permalink / raw)
To: linux-rdma-u79uwXL29TY76Z2rM5mHXA
Are we planning on having a rdma-core release now that 4.8 is out
and we want a matching userspace release?
--
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] add a build.sh helper to allow for a one-stop build
From: Leon Romanovsky @ 2016-10-12 9:30 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Bart Van Assche, Christoph Hellwig,
linux-rdma-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20161010164758.GB1796-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 2916 bytes --]
On Mon, Oct 10, 2016 at 10:47:58AM -0600, Jason Gunthorpe wrote:
> On Mon, Oct 10, 2016 at 09:17:11AM -0700, Bart Van Assche wrote:
> > On 10/10/16 08:59, Christoph Hellwig wrote:
> > >On Mon, Oct 10, 2016 at 08:56:33AM -0700, Bart Van Assche wrote:
> > >>Have you considered to make this script stop immediately if one of the
> > >>steps fails, e.g. as follows?
> > >
> > >How about just ading a
> > >
> > >set -e
> > >
> > >to the beginning to get this automatically?
> >
> > That would also work. But if there is a space anywhere in the path in which
> > the rdma-core repository exists, mkdir $BUILDDIR will have to be changed
> > into mkdir "$BUILDDIR".
>
> Is this OK?
>
> From 6362ec4c1ddec0f6b2a1bf052cdfde63cbf73d90 Mon Sep 17 00:00:00 2001
> From: Jason Gunthorpe <jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
> Date: Mon, 10 Oct 2016 10:46:47 -0600
> Subject: [PATCH] Add a build.sh helper to allow for a one-stop build
>
> This allows for a quick build instead of typing the whole mkdir, cd,
> cmake and ninja sequence.
>
> Signed-off-by: Christoph Hellwig <hch-jcswGhMUV9g@public.gmane.org>
> Signed-off-by: Jason Gunthorpe <jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
> ---
> README.md | 17 +----------------
> build.sh | 33 +++++++++++++++++++++++++++++++++
> 2 files changed, 34 insertions(+), 16 deletions(-)
> create mode 100755 build.sh
>
> diff --git a/README.md b/README.md
> index 98ec5a7d695f..66aee3f49f00 100644
> --- a/README.md
> +++ b/README.md
> @@ -36,10 +36,7 @@ Additional service daemons are provided for:
> This project uses a cmake based build system. Quick start:
>
> ```sh
> -$ mkdir build
> -$ cd build
> -$ cmake -GNinja ..
> -$ ninja
> +$ bash build.sh
> ```
>
> *build/bin* will contain the sample programs and *build/lib* will contain the
> @@ -76,16 +73,6 @@ Install required packages:
> $ yum install cmake gcc libnl3-devel make pkgconfig valgrind-devel
> ```
>
> -For end users, the package can be built using GNU Make and the old cmake
> -included with the distro:
> -
> -```sh
> -$ mkdir build
> -$ cd build
> -$ cmake ..
> -$ make
> -```
> -
> Developers are suggested to install more modern tooling for the best experience.
>
> ```sh
> @@ -96,8 +83,6 @@ $ unzip ninja-linux.zip
> $ install -m755 ninja /usr/local/bin/ninja
> ```
>
> -Use the 'cmake3' program in place of `cmake` in the above instructions.
> -
> # Reporting bugs
>
> Bugs should be reported to the <linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org> mailing list
> diff --git a/build.sh b/build.sh
> new file mode 100755
> index 000000000000..76205e6af921
> --- /dev/null
> +++ b/build.sh
> @@ -0,0 +1,33 @@
> +#!/bin/bash
> +set -e
> +
> +SRCDIR=`dirname $0`
> +BUILDDIR="$SRCDIR/build"
> +
> +if [ ! -d "$BUILDDIR" ]; then
> + mkdir "$BUILDDIR"
> +fi
What do you think about following code, instead of 3 lines above?
+ mkdir -p "$BUILDDIR"
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH V2 net-next] net/mlx5: Add MLX5_ARRAY_SET64 to fix BUILD_BUG_ON
From: Leon Romanovsky @ 2016-10-12 8:50 UTC (permalink / raw)
To: David S. Miller, Doug Ledford
Cc: Saeed Mahameed, netdev-u79uwXL29TY76Z2rM5mHXA, Tom Herbert,
David Laight, kernel-team-b10kYP2dOMg, RDMA mailing list,
Steve Wise
In-Reply-To: <1476237430-11756-1-git-send-email-saeedm-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 4097 bytes --]
On Wed, Oct 12, 2016 at 04:57:10AM +0300, Saeed Mahameed wrote:
> From: Tom Herbert <tom-BjP2VixgY4xUbtYUoyoikg@public.gmane.org>
>
> I am hitting this in mlx5:
>
> drivers/net/ethernet/mellanox/mlx5/core/pagealloc.c: In function
> reclaim_pages_cmd.clone.0:
> drivers/net/ethernet/mellanox/mlx5/core/pagealloc.c:346: error: call
> to __compiletime_assert_346 declared with attribute error:
> BUILD_BUG_ON failed: __mlx5_bit_off(manage_pages_out, pas[i]) % 64
> drivers/net/ethernet/mellanox/mlx5/core/pagealloc.c: In function give_pages:
> drivers/net/ethernet/mellanox/mlx5/core/pagealloc.c:291: error: call
> to __compiletime_assert_291 declared with attribute error:
> BUILD_BUG_ON failed: __mlx5_bit_off(manage_pages_in, pas[i]) % 64
>
> Problem is that this is doing a BUILD_BUG_ON on a non-constant
> expression because of trying to take offset of pas[i] in the
> structure.
>
> Fix is to create MLX5_ARRAY_SET64 that takes an additional argument
> that is the field index to separate between BUILD_BUG_ON on the array
> constant field and the indexed field to assign the value to.
> There are two callers of MLX5_SET64 that are trying to get a variable
> offset, change those to call MLX5_ARRAY_SET64 passing 'pas' and 'i'
> as the arguments to use in the offset check and the indexed value
> assignment.
>
> Fixes: a533ed5e179cd ("net/mlx5: Pages management commands via mlx5 ifc")
> Signed-off-by: Tom Herbert <tom-BjP2VixgY4xUbtYUoyoikg@public.gmane.org>
> Signed-off-by: Saeed Mahameed <saeedm-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
> ---
>
> Hi Dave,
>
> I hope this version of this patch will make it to -rc1, I made
> some changes to the original version Tom submitted. Following David Laight
> suggestion to separate the array index from the constant array field to have
> a more natural API.
>
> Thanks,
> Saeed.
>
>
> drivers/net/ethernet/mellanox/mlx5/core/pagealloc.c | 4 ++--
> include/linux/mlx5/device.h | 13 +++++++++++--
> 2 files changed, 13 insertions(+), 4 deletions(-)
Hi Dave and Doug,
Any chances that this fix will be forwarded to Linus in merge window?
I don't know if you (Dave) had in mind to send additional pull request to
Linus in this merge window, but Doug is definitely planning, and it will
be awesome if it includes this fix in it.
Thanks
>
> diff --git a/drivers/net/ethernet/mellanox/mlx5/core/pagealloc.c b/drivers/net/ethernet/mellanox/mlx5/core/pagealloc.c
> index d458515..cc4fd61 100644
> --- a/drivers/net/ethernet/mellanox/mlx5/core/pagealloc.c
> +++ b/drivers/net/ethernet/mellanox/mlx5/core/pagealloc.c
> @@ -287,7 +287,7 @@ retry:
>
> goto retry;
> }
> - MLX5_SET64(manage_pages_in, in, pas[i], addr);
> + MLX5_ARRAY_SET64(manage_pages_in, in, pas, i, addr);
> }
>
> MLX5_SET(manage_pages_in, in, opcode, MLX5_CMD_OP_MANAGE_PAGES);
> @@ -344,7 +344,7 @@ static int reclaim_pages_cmd(struct mlx5_core_dev *dev,
> if (fwp->func_id != func_id)
> continue;
>
> - MLX5_SET64(manage_pages_out, out, pas[i], fwp->addr);
> + MLX5_ARRAY_SET64(manage_pages_out, out, pas, i, fwp->addr);
> i++;
> }
>
> diff --git a/include/linux/mlx5/device.h b/include/linux/mlx5/device.h
> index 77c1417..5827614 100644
> --- a/include/linux/mlx5/device.h
> +++ b/include/linux/mlx5/device.h
> @@ -92,12 +92,21 @@ __mlx5_mask(typ, fld))
> ___t; \
> })
>
> -#define MLX5_SET64(typ, p, fld, v) do { \
> +#define __MLX5_SET64(typ, p, fld, v) do { \
> BUILD_BUG_ON(__mlx5_bit_sz(typ, fld) != 64); \
> - BUILD_BUG_ON(__mlx5_bit_off(typ, fld) % 64); \
> *((__be64 *)(p) + __mlx5_64_off(typ, fld)) = cpu_to_be64(v); \
> } while (0)
>
> +#define MLX5_SET64(typ, p, fld, v) do { \
> + BUILD_BUG_ON(__mlx5_bit_off(typ, fld) % 64); \
> + __MLX5_SET64(typ, p, fld, v); \
> +} while (0)
> +
> +#define MLX5_ARRAY_SET64(typ, p, fld, idx, v) do { \
> + BUILD_BUG_ON(__mlx5_bit_off(typ, fld) % 64); \
> + __MLX5_SET64(typ, p, fld[idx], v); \
> +} while (0)
> +
> #define MLX5_GET64(typ, p, fld) be64_to_cpu(*((__be64 *)(p) + __mlx5_64_off(typ, fld)))
>
> #define MLX5_GET64_PR(typ, p, fld) ({ \
> --
> 2.7.4
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: build failure on linus' latest master branch
From: Leon Romanovsky @ 2016-10-12 8:42 UTC (permalink / raw)
To: Doug Ledford; +Cc: Steve Wise, linux-rdma-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <c2dffb44-d600-40d6-ec5d-09ef917da877-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 957 bytes --]
On Tue, Oct 11, 2016 at 04:47:53PM -0400, Doug Ledford wrote:
> On 10/11/2016 3:36 PM, Leon Romanovsky wrote:
> > On Tue, Oct 11, 2016 at 09:30:35AM -0500, Steve Wise wrote:
> >>>> Is there a fix for this?
> >>>
> >>> We investigated a lot this failure and it appears on specific and very
> >>> old GCC 4.4.
> >>> http://www.spinics.net/lists/linux-rdma/msg39135.html
> >>> http://marc.info/?t=147614305200001&r=1&w=2
> >>>
> >>> And the fix is http://marc.info/?l=linux-netdev&m=147615976207362&w=2
> >>>
> >>
> >> Thanks. So was it ever merged?
> >
> > Not yet, I hope that Dave or Doug will forward that patch to Linus
> > before -rc1 is released.
>
> That patch isn't even on my radar.
I had in mind to wait till v2 will be sent before asking you and/or Dave
forward it to Linus.
http://marc.info/?l=linux-netdev&m=147623786131380&w=2
Thanks
>
>
> --
> Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> GPG Key ID: 0E572FDD
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* [bug report] IB/hfi1: Prevent NULL pointer deferences in caching code
From: Dan Carpenter @ 2016-10-12 6:06 UTC (permalink / raw)
To: mitko.haralanov-ral2JQCrhuEAvxtiuMwx3w; +Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA
Hello Mitko Haralanov,
The patch f19bd643dbde: "IB/hfi1: Prevent NULL pointer deferences in
caching code" from Apr 12, 2016, leads to the following static
checker warning:
drivers/infiniband/hw/hfi1/user_sdma.c:1147 pin_vector_pages()
warn: 'rb_node' isn't an ERR_PTR
drivers/infiniband/hw/hfi1/user_sdma.c
1135 static int pin_vector_pages(struct user_sdma_request *req,
1136 struct user_sdma_iovec *iovec)
1137 {
1138 int ret = 0, pinned, npages, cleared;
1139 struct page **pages;
1140 struct hfi1_user_sdma_pkt_q *pq = req->pq;
1141 struct sdma_mmu_node *node = NULL;
1142 struct mmu_rb_node *rb_node;
1143
1144 rb_node = hfi1_mmu_rb_extract(pq->handler,
1145 (unsigned long)iovec->iov.iov_base,
1146 iovec->iov.iov_len);
1147 if (rb_node && !IS_ERR(rb_node))
^^^^^^^^^^^^^^^
hfi1_mmu_rb_extract() never returns error pointers. Plz delete.
1148 node = container_of(rb_node, struct sdma_mmu_node, rb);
1149 else
1150 rb_node = NULL;
1151
1152 if (!node) {
1153 node = kzalloc(sizeof(*node), GFP_KERNEL);
1154 if (!node)
1155 return -ENOMEM;
1156
1157 node->rb.addr = (unsigned long)iovec->iov.iov_base;
1158 node->pq = pq;
1159 atomic_set(&node->refcount, 0);
1160 }
regards,
dan carpenter
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 7/7] [RFC] nvme: Fix a race condition
From: Bart Van Assche @ 2016-10-12 0:41 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Jens Axboe, James Bottomley, Martin K. Petersen, Mike Snitzer,
Doug Ledford, Keith Busch, linux-block@vger.kernel.org,
linux-scsi@vger.kernel.org, linux-rdma@vger.kernel.org,
linux-nvme@lists.infradead.org
In-Reply-To: <20161011164601.GC18822@lst.de>
On 10/11/16 09:46, Christoph Hellwig wrote:
> On Wed, Sep 28, 2016 at 05:01:45PM -0700, Bart Van Assche wrote:
>> Avoid that nvme_queue_rq() is still running when nvme_stop_queues()
>> returns. Untested.
>>
>> Signed-off-by: Bart Van Assche <bart.vanassche@sandisk.com>
>> Cc: Keith Busch <keith.busch@intel.com>
>> Cc: Christoph Hellwig <hch@lst.de>
>> Cc: Sagi Grimberg <sagi@grimberg.me>
>> ---
>> drivers/nvme/host/core.c | 20 ++++++++++++--------
>> 1 file changed, 12 insertions(+), 8 deletions(-)
>>
>> diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c
>> index d791fba..98f1f29 100644
>> --- a/drivers/nvme/host/core.c
>> +++ b/drivers/nvme/host/core.c
>> @@ -201,13 +201,9 @@ fail:
>>
>> void nvme_requeue_req(struct request *req)
>> {
>> - unsigned long flags;
>> -
>> blk_mq_requeue_request(req);
>> - spin_lock_irqsave(req->q->queue_lock, flags);
>> - if (!blk_mq_queue_stopped(req->q))
>> - blk_mq_kick_requeue_list(req->q);
>> - spin_unlock_irqrestore(req->q->queue_lock, flags);
>> + WARN_ON_ONCE(blk_mq_queue_stopped(req->q));
>> + blk_mq_kick_requeue_list(req->q);
>> }
>> EXPORT_SYMBOL_GPL(nvme_requeue_req);
>
> Can we just add a 'bool kick' argument to blk_mq_requeue_request and
> move all this handling to the core?
Hello Christoph,
That sounds like a good idea to me. Thanks also for the other review
comments you posted on this patch series. I will rework patch 6/7 such
that the code for waiting is moved into the SCSI core.
Bart.
^ permalink raw reply
* Re: build failure on linus' latest master branch
From: Doug Ledford @ 2016-10-11 20:47 UTC (permalink / raw)
To: Leon Romanovsky, Steve Wise; +Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20161011193633.GN9282-2ukJVAZIZ/Y@public.gmane.org>
[-- Attachment #1.1: Type: text/plain, Size: 715 bytes --]
On 10/11/2016 3:36 PM, Leon Romanovsky wrote:
> On Tue, Oct 11, 2016 at 09:30:35AM -0500, Steve Wise wrote:
>>>> Is there a fix for this?
>>>
>>> We investigated a lot this failure and it appears on specific and very
>>> old GCC 4.4.
>>> http://www.spinics.net/lists/linux-rdma/msg39135.html
>>> http://marc.info/?t=147614305200001&r=1&w=2
>>>
>>> And the fix is http://marc.info/?l=linux-netdev&m=147615976207362&w=2
>>>
>>
>> Thanks. So was it ever merged?
>
> Not yet, I hope that Dave or Doug will forward that patch to Linus
> before -rc1 is released.
That patch isn't even on my radar.
--
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
GPG Key ID: 0E572FDD
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]
^ 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