Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1491638 > unrolled thread

linux-next: build failure after merge of the rdma tree

Started byStephen Rothwell <sfr@canb.auug.org.au>
First post2016-09-27 03:30 +0200
Last post2016-09-28 23:50 +0200
Articles 10 — 4 participants

Back to article view | Back to linux.kernel

Contents

  linux-next: build failure after merge of the rdma tree Stephen Rothwell <sfr@canb.auug.org.au> - 2016-09-27 03:30 +0200
    Re: linux-next: build failure after merge of the rdma tree Christoph Hellwig <hch@lst.de> - 2016-09-27 07:10 +0200
      Re: linux-next: build failure after merge of the rdma tree Stephen Rothwell <sfr@canb.auug.org.au> - 2016-09-27 07:50 +0200
        Re: linux-next: build failure after merge of the rdma tree Christoph Hellwig <hch@lst.de> - 2016-09-27 15:50 +0200
          Re: linux-next: build failure after merge of the rdma tree Doug Ledford <dledford@redhat.com> - 2016-09-27 19:20 +0200
    Re: linux-next: build failure after merge of the rdma tree Stephen Rothwell <sfr@canb.auug.org.au> - 2016-09-28 03:50 +0200
      Re: linux-next: build failure after merge of the rdma tree Doug Ledford <dledford@redhat.com> - 2016-09-28 17:10 +0200
        Re: linux-next: build failure after merge of the rdma tree Doug Ledford <dledford@redhat.com> - 2016-09-28 17:30 +0200
        Re: linux-next: build failure after merge of the rdma tree Greg KH <greg@kroah.com> - 2016-09-28 17:30 +0200
        Re: linux-next: build failure after merge of the rdma tree Stephen Rothwell <sfr@canb.auug.org.au> - 2016-09-28 23:50 +0200

#1491638 — linux-next: build failure after merge of the rdma tree

FromStephen Rothwell <sfr@canb.auug.org.au>
Date2016-09-27 03:30 +0200
Subjectlinux-next: build failure after merge of the rdma tree
Message-ID<slPnz-31r-7@gated-at.bofh.it>
Hi Doug,

After merging the rdma tree, today's linux-next build (x86_64
allmodconfig) failed like this:

drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c: In function 'kiblnd_hdev_setup_mrs':
drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c:2317:7: error: implicit declaration of function 'ib_get_dma_mr' [-Werror=implicit-function-declaration]
  mr = ib_get_dma_mr(hdev->ibh_pd, acflags);
       ^
drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c:2317:5: warning: assignment makes pointer from integer without a cast [-Wint-conversion]
  mr = ib_get_dma_mr(hdev->ibh_pd, acflags);
     ^

Caused by commit

  5ef990f06bd7 ("IB/core: remove ib_get_dma_mr")

I have used the rdma tree from next-20160923 for today.

-- 
Cheers,
Stephen Rothwell

[toc] | [next] | [standalone]

#1491684

FromChristoph Hellwig <hch@lst.de>
Date2016-09-27 07:10 +0200
Message-ID<slSOu-5nJ-1@gated-at.bofh.it>
In reply to#1491638
On Tue, Sep 27, 2016 at 11:23:34AM +1000, Stephen Rothwell wrote:
> Hi Doug,
> 
> After merging the rdma tree, today's linux-next build (x86_64
> allmodconfig) failed like this:

Please just disable broken staging code like lustre for the linux-next
builds. We had that discussion before, didn't we?

[toc] | [prev] | [next] | [standalone]

#1491696

FromStephen Rothwell <sfr@canb.auug.org.au>
Date2016-09-27 07:50 +0200
Message-ID<slTrc-5Aj-5@gated-at.bofh.it>
In reply to#1491684
Hi Christoph,

On Tue, 27 Sep 2016 07:04:15 +0200 Christoph Hellwig <hch@lst.de> wrote:
>
> On Tue, Sep 27, 2016 at 11:23:34AM +1000, Stephen Rothwell wrote:
> > Hi Doug,
> > 
> > After merging the rdma tree, today's linux-next build (x86_64
> > allmodconfig) failed like this:  
> 
> Please just disable broken staging code like lustre for the linux-next
> builds. We had that discussion before, didn't we?

Yeah, sorry.  Note, however, that you bothered to fix up this same
staging file in another of your patches ...

-- 
Cheers,
Stephen Rothwell

[toc] | [prev] | [next] | [standalone]

#1491914

FromChristoph Hellwig <hch@lst.de>
Date2016-09-27 15:50 +0200
Message-ID<sm0VI-1H1-19@gated-at.bofh.it>
In reply to#1491696
On Tue, Sep 27, 2016 at 03:48:20PM +1000, Stephen Rothwell wrote:
> Yeah, sorry.  Note, however, that you bothered to fix up this same
> staging file in another of your patches ...

It's generally not that I don't fix them up because I hate them, it's
just because they are doing something so incredibly stupid that it would
take forever to fix up (and something that would have been could if it
ever had been through review).   For this particular case I think everyone
would be served much better if this module was simply dropped from the
tree, as there will be lots of future patches that will break it.

[toc] | [prev] | [next] | [standalone]

#1492055

FromDoug Ledford <dledford@redhat.com>
Date2016-09-27 19:20 +0200
Message-ID<sm4cW-3RC-35@gated-at.bofh.it>
In reply to#1491914

[Multipart message — attachments visible in raw view] — view raw

On 9/27/16 9:39 AM, Christoph Hellwig wrote:
> On Tue, Sep 27, 2016 at 03:48:20PM +1000, Stephen Rothwell wrote:
>> Yeah, sorry.  Note, however, that you bothered to fix up this same
>> staging file in another of your patches ...
> 
> It's generally not that I don't fix them up because I hate them, it's
> just because they are doing something so incredibly stupid that it would
> take forever to fix up (and something that would have been could if it
> ever had been through review).   For this particular case I think everyone
> would be served much better if this module was simply dropped from the
> tree, as there will be lots of future patches that will break it.
> 

I don't know that I would drop them, but certainly turn them off.  They
can keep their driver up to date.

-- 
Doug Ledford <dledford@redhat.com>    GPG Key ID: 0E572FDD
  Red Hat, Inc.
  100 E. Davie St
  Raleigh, NC 27601 USA

[toc] | [prev] | [next] | [standalone]

#1492232

FromStephen Rothwell <sfr@canb.auug.org.au>
Date2016-09-28 03:50 +0200
Message-ID<smcau-hm-3@gated-at.bofh.it>
In reply to#1491638
Hi Stephen,

On Tue, 27 Sep 2016 11:23:34 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Hi Doug,
> 
> After merging the rdma tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
> 
> drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c: In function 'kiblnd_hdev_setup_mrs':
> drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c:2317:7: error: implicit declaration of function 'ib_get_dma_mr' [-Werror=implicit-function-declaration]
>   mr = ib_get_dma_mr(hdev->ibh_pd, acflags);
>        ^
> drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c:2317:5: warning: assignment makes pointer from integer without a cast [-Wint-conversion]
>   mr = ib_get_dma_mr(hdev->ibh_pd, acflags);
>      ^
> 
> Caused by commit
> 
>   5ef990f06bd7 ("IB/core: remove ib_get_dma_mr")
> 
> I have used the rdma tree from next-20160923 for today.

As pointed out by Christoph, I should have just disabled the driver in
staging, so today I just applied the patch below.  Doug, that should
probably be applied to the rdma tree so that you don't break Linus'
tree when it gets merged.

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Wed, 28 Sep 2016 11:35:28 +1000
Subject: [PATCH] starging/lustre: disable LNET infiniband support

Commit 5ef990f06bd7 ("IB/core: remove ib_get_dma_mr") broke the
lustre LNET infiniband support.  Since this is in drivers/staging,
lets just disable it for now until ti can be fixed properly.

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 drivers/staging/lustre/lnet/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/staging/lustre/lnet/Kconfig b/drivers/staging/lustre/lnet/Kconfig
index 2b5930150cda..13b43278a38d 100644
--- a/drivers/staging/lustre/lnet/Kconfig
+++ b/drivers/staging/lustre/lnet/Kconfig
@@ -35,6 +35,7 @@ config LNET_SELFTEST
 config LNET_XPRT_IB
 	tristate "LNET infiniband support"
 	depends on LNET && INFINIBAND && INFINIBAND_ADDR_TRANS
+	depends on BROKEN
 	default LNET && INFINIBAND
 	help
 	  This option allows the LNET users to use infiniband as an
-- 
2.8.1

-- 
Cheers,
Stephen Rothwell

[toc] | [prev] | [next] | [standalone]

#1492644

FromDoug Ledford <dledford@redhat.com>
Date2016-09-28 17:10 +0200
Message-ID<smoEF-8kS-9@gated-at.bofh.it>
In reply to#1492232

[Multipart message — attachments visible in raw view] — view raw

On 9/27/16 9:43 PM, Stephen Rothwell wrote:
> Hi Stephen,
> 
> On Tue, 27 Sep 2016 11:23:34 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>>
>> Hi Doug,
>>
>> After merging the rdma tree, today's linux-next build (x86_64
>> allmodconfig) failed like this:
>>
>> drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c: In function 'kiblnd_hdev_setup_mrs':
>> drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c:2317:7: error: implicit declaration of function 'ib_get_dma_mr' [-Werror=implicit-function-declaration]
>>   mr = ib_get_dma_mr(hdev->ibh_pd, acflags);
>>        ^
>> drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c:2317:5: warning: assignment makes pointer from integer without a cast [-Wint-conversion]
>>   mr = ib_get_dma_mr(hdev->ibh_pd, acflags);
>>      ^
>>
>> Caused by commit
>>
>>   5ef990f06bd7 ("IB/core: remove ib_get_dma_mr")
>>
>> I have used the rdma tree from next-20160923 for today.
> 
> As pointed out by Christoph, I should have just disabled the driver in
> staging, so today I just applied the patch below.  Doug, that should
> probably be applied to the rdma tree so that you don't break Linus'
> tree when it gets merged.
> 
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Wed, 28 Sep 2016 11:35:28 +1000
> Subject: [PATCH] starging/lustre: disable LNET infiniband support
> 
> Commit 5ef990f06bd7 ("IB/core: remove ib_get_dma_mr") broke the
> lustre LNET infiniband support.  Since this is in drivers/staging,
> lets just disable it for now until ti can be fixed properly.
> 
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
>  drivers/staging/lustre/lnet/Kconfig | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/staging/lustre/lnet/Kconfig b/drivers/staging/lustre/lnet/Kconfig
> index 2b5930150cda..13b43278a38d 100644
> --- a/drivers/staging/lustre/lnet/Kconfig
> +++ b/drivers/staging/lustre/lnet/Kconfig
> @@ -35,6 +35,7 @@ config LNET_SELFTEST
>  config LNET_XPRT_IB
>  	tristate "LNET infiniband support"
>  	depends on LNET && INFINIBAND && INFINIBAND_ADDR_TRANS
> +	depends on BROKEN
>  	default LNET && INFINIBAND
>  	help
>  	  This option allows the LNET users to use infiniband as an
> 

That doesn't seem like a particularly good thing to put in.  Wouldn't
you end up just reverting it later when they fix lustre?  And are you
going to revert the revert when it breaks again and revert the revert of
the revert when it's fixed again?  That just seems a lot of churn.  I
thought it was generally accepted that things in staging might or might
not work and if they don't, we don't care?  Am I wrong on that?

-- 
Doug Ledford <dledford@redhat.com>    GPG Key ID: 0E572FDD
  Red Hat, Inc.
  100 E. Davie St
  Raleigh, NC 27601 USA

[toc] | [prev] | [next] | [standalone]

#1492651

FromDoug Ledford <dledford@redhat.com>
Date2016-09-28 17:30 +0200
Message-ID<smoY1-8rL-9@gated-at.bofh.it>
In reply to#1492644

[Multipart message — attachments visible in raw view] — view raw

On 9/28/16 11:23 AM, Greg KH wrote:
> On Wed, Sep 28, 2016 at 11:00:11AM -0400, Doug Ledford wrote:
>> On 9/27/16 9:43 PM, Stephen Rothwell wrote:
>>> Hi Stephen,
>>>
>>> On Tue, 27 Sep 2016 11:23:34 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>>>>
>>>> Hi Doug,
>>>>
>>>> After merging the rdma tree, today's linux-next build (x86_64
>>>> allmodconfig) failed like this:
>>>>
>>>> drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c: In function 'kiblnd_hdev_setup_mrs':
>>>> drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c:2317:7: error: implicit declaration of function 'ib_get_dma_mr' [-Werror=implicit-function-declaration]
>>>>   mr = ib_get_dma_mr(hdev->ibh_pd, acflags);
>>>>        ^
>>>> drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c:2317:5: warning: assignment makes pointer from integer without a cast [-Wint-conversion]
>>>>   mr = ib_get_dma_mr(hdev->ibh_pd, acflags);
>>>>      ^
>>>>
>>>> Caused by commit
>>>>
>>>>   5ef990f06bd7 ("IB/core: remove ib_get_dma_mr")
>>>>
>>>> I have used the rdma tree from next-20160923 for today.
>>>
>>> As pointed out by Christoph, I should have just disabled the driver in
>>> staging, so today I just applied the patch below.  Doug, that should
>>> probably be applied to the rdma tree so that you don't break Linus'
>>> tree when it gets merged.
>>>
>>> From: Stephen Rothwell <sfr@canb.auug.org.au>
>>> Date: Wed, 28 Sep 2016 11:35:28 +1000
>>> Subject: [PATCH] starging/lustre: disable LNET infiniband support
>>>
>>> Commit 5ef990f06bd7 ("IB/core: remove ib_get_dma_mr") broke the
>>> lustre LNET infiniband support.  Since this is in drivers/staging,
>>> lets just disable it for now until ti can be fixed properly.
>>>
>>> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
>>> ---
>>>  drivers/staging/lustre/lnet/Kconfig | 1 +
>>>  1 file changed, 1 insertion(+)
>>>
>>> diff --git a/drivers/staging/lustre/lnet/Kconfig b/drivers/staging/lustre/lnet/Kconfig
>>> index 2b5930150cda..13b43278a38d 100644
>>> --- a/drivers/staging/lustre/lnet/Kconfig
>>> +++ b/drivers/staging/lustre/lnet/Kconfig
>>> @@ -35,6 +35,7 @@ config LNET_SELFTEST
>>>  config LNET_XPRT_IB
>>>  	tristate "LNET infiniband support"
>>>  	depends on LNET && INFINIBAND && INFINIBAND_ADDR_TRANS
>>> +	depends on BROKEN
>>>  	default LNET && INFINIBAND
>>>  	help
>>>  	  This option allows the LNET users to use infiniband as an
>>>
>>
>> That doesn't seem like a particularly good thing to put in.  Wouldn't
>> you end up just reverting it later when they fix lustre?  And are you
>> going to revert the revert when it breaks again and revert the revert of
>> the revert when it's fixed again?
> 
> Yup :)
> 
> Well, in reality just keep adding and removing the line without dealing
> with reverts, much simpler...
> 
>> That just seems a lot of churn.  I
>> thought it was generally accepted that things in staging might or might
>> not work and if they don't, we don't care?  Am I wrong on that?
> 
> Nope, you are not wrong, but it is nice to not break some people's
> builds if it's possible.

Okie dokie, got it.


-- 
Doug Ledford <dledford@redhat.com>    GPG Key ID: 0E572FDD
  Red Hat, Inc.
  100 E. Davie St
  Raleigh, NC 27601 USA

[toc] | [prev] | [next] | [standalone]

#1492653

FromGreg KH <greg@kroah.com>
Date2016-09-28 17:30 +0200
Message-ID<smoY1-8rL-11@gated-at.bofh.it>
In reply to#1492644
On Wed, Sep 28, 2016 at 11:00:11AM -0400, Doug Ledford wrote:
> On 9/27/16 9:43 PM, Stephen Rothwell wrote:
> > Hi Stephen,
> > 
> > On Tue, 27 Sep 2016 11:23:34 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >>
> >> Hi Doug,
> >>
> >> After merging the rdma tree, today's linux-next build (x86_64
> >> allmodconfig) failed like this:
> >>
> >> drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c: In function 'kiblnd_hdev_setup_mrs':
> >> drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c:2317:7: error: implicit declaration of function 'ib_get_dma_mr' [-Werror=implicit-function-declaration]
> >>   mr = ib_get_dma_mr(hdev->ibh_pd, acflags);
> >>        ^
> >> drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c:2317:5: warning: assignment makes pointer from integer without a cast [-Wint-conversion]
> >>   mr = ib_get_dma_mr(hdev->ibh_pd, acflags);
> >>      ^
> >>
> >> Caused by commit
> >>
> >>   5ef990f06bd7 ("IB/core: remove ib_get_dma_mr")
> >>
> >> I have used the rdma tree from next-20160923 for today.
> > 
> > As pointed out by Christoph, I should have just disabled the driver in
> > staging, so today I just applied the patch below.  Doug, that should
> > probably be applied to the rdma tree so that you don't break Linus'
> > tree when it gets merged.
> > 
> > From: Stephen Rothwell <sfr@canb.auug.org.au>
> > Date: Wed, 28 Sep 2016 11:35:28 +1000
> > Subject: [PATCH] starging/lustre: disable LNET infiniband support
> > 
> > Commit 5ef990f06bd7 ("IB/core: remove ib_get_dma_mr") broke the
> > lustre LNET infiniband support.  Since this is in drivers/staging,
> > lets just disable it for now until ti can be fixed properly.
> > 
> > Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> > ---
> >  drivers/staging/lustre/lnet/Kconfig | 1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/drivers/staging/lustre/lnet/Kconfig b/drivers/staging/lustre/lnet/Kconfig
> > index 2b5930150cda..13b43278a38d 100644
> > --- a/drivers/staging/lustre/lnet/Kconfig
> > +++ b/drivers/staging/lustre/lnet/Kconfig
> > @@ -35,6 +35,7 @@ config LNET_SELFTEST
> >  config LNET_XPRT_IB
> >  	tristate "LNET infiniband support"
> >  	depends on LNET && INFINIBAND && INFINIBAND_ADDR_TRANS
> > +	depends on BROKEN
> >  	default LNET && INFINIBAND
> >  	help
> >  	  This option allows the LNET users to use infiniband as an
> > 
> 
> That doesn't seem like a particularly good thing to put in.  Wouldn't
> you end up just reverting it later when they fix lustre?  And are you
> going to revert the revert when it breaks again and revert the revert of
> the revert when it's fixed again?

Yup :)

Well, in reality just keep adding and removing the line without dealing
with reverts, much simpler...

> That just seems a lot of churn.  I
> thought it was generally accepted that things in staging might or might
> not work and if they don't, we don't care?  Am I wrong on that?

Nope, you are not wrong, but it is nice to not break some people's
builds if it's possible.

thanks,

greg k-h

[toc] | [prev] | [next] | [standalone]

#1493003

FromStephen Rothwell <sfr@canb.auug.org.au>
Date2016-09-28 23:50 +0200
Message-ID<smuTL-3OR-7@gated-at.bofh.it>
In reply to#1492644
Hi Doug,

On Wed, 28 Sep 2016 11:00:11 -0400 Doug Ledford <dledford@redhat.com> wrote:
>
> That doesn't seem like a particularly good thing to put in.  Wouldn't
> you end up just reverting it later when they fix lustre?  And are you
> going to revert the revert when it breaks again and revert the revert of
> the revert when it's fixed again?  That just seems a lot of churn.  I
> thought it was generally accepted that things in staging might or might
> not work and if they don't, we don't care?  Am I wrong on that?

The allmodconfig build needs to work.  Linus does an allmodconfig build
as part of his testing ...

Part of the fix patch should reenable building of the currently broken code.
-- 
Cheers,
Stephen Rothwell

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web