Re: linux-next: build failure after merge of the scsi tree

Re: linux-next: build failure after merge of the scsi tree

[James Bottomley]

On Fri, 2013-01-11 at 12:03 +1100, Stephen Rothwell wrote:
> Hi James,
> 
> After merging the scsi tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
> 
> drivers/scsi/ipr.c:9138:22: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'ipr_enable_msix'
> drivers/scsi/ipr.c:9165:22: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'ipr_enable_msi'
> drivers/scsi/ipr.c:9188:23: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'name_msi_vectors'
> drivers/scsi/ipr.c:9200:22: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'ipr_request_other_msi_irqs'
> drivers/scsi/ipr.c: In function 'ipr_probe_ioa':
> drivers/scsi/ipr.c:9422:4: error: implicit declaration of function 'ipr_enable_msix' [-Werror=implicit-function-declaration]
> drivers/scsi/ipr.c:9425:4: error: implicit declaration of function 'ipr_enable_msi' [-Werror=implicit-function-declaration]
> drivers/scsi/ipr.c:9517:3: error: implicit declaration of function 'name_msi_vectors' [-Werror=implicit-function-declaration]
> drivers/scsi/ipr.c:9523:4: error: implicit declaration of function 'ipr_request_other_msi_irqs' [-Werror=implicit-function-declaration]

OK, fine, I'll drop all the ipr patches.  I've been waiting for a month
for them to fix the smatch and sparse warnings.  Please resend the
series with all the fixes.

Thanks,

James

Re: linux-next: build failure after merge of the scsi tree

[Brian King]

It looks like this was a due to the fact that the new patches
added __devinit tags in the same merge window the __devinit tag
itself was getting removed.

As to the sparse warnings, this patch fixed the ones that
were actual bugs in the new code, although we could have
made that more clear in the patch description.

http://marc.info/?l=linux-scsi&m=135716576204083&w=2

There is one outstanding issue I am aware of which was an
array bounds compiler warning which looks to be a misdetection
by the compiler. Wendy and I discussed adding a BUG_ON
to stop the compiler from complaining.

Wendy - lets queue these two changes up ASAP. They should both
be very simple changes.

Thanks,

Brian


On 01/11/2013 01:34 AM, James Bottomley wrote:
> On Fri, 2013-01-11 at 12:03 +1100, Stephen Rothwell wrote:
>> Hi James,
>>
>> After merging the scsi tree, today's linux-next build (powerpc
>> ppc64_defconfig) failed like this:
>>
>> drivers/scsi/ipr.c:9138:22: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'ipr_enable_msix'
>> drivers/scsi/ipr.c:9165:22: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'ipr_enable_msi'
>> drivers/scsi/ipr.c:9188:23: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'name_msi_vectors'
>> drivers/scsi/ipr.c:9200:22: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'ipr_request_other_msi_irqs'
>> drivers/scsi/ipr.c: In function 'ipr_probe_ioa':
>> drivers/scsi/ipr.c:9422:4: error: implicit declaration of function 'ipr_enable_msix' [-Werror=implicit-function-declaration]
>> drivers/scsi/ipr.c:9425:4: error: implicit declaration of function 'ipr_enable_msi' [-Werror=implicit-function-declaration]
>> drivers/scsi/ipr.c:9517:3: error: implicit declaration of function 'name_msi_vectors' [-Werror=implicit-function-declaration]
>> drivers/scsi/ipr.c:9523:4: error: implicit declaration of function 'ipr_request_other_msi_irqs' [-Werror=implicit-function-declaration]
> 
> OK, fine, I'll drop all the ipr patches.  I've been waiting for a month
> for them to fix the smatch and sparse warnings.  Please resend the
> series with all the fixes.
> 
> Thanks,
> 
> James
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 


-- 
Brian King
Power Linux I/O
IBM Linux Technology Center

Re: linux-next: build failure after merge of the scsi tree

[James Bottomley]

On Fri, 2013-01-11 at 09:27 -0600, Brian King wrote:
> It looks like this was a due to the fact that the new patches
> added __devinit tags in the same merge window the __devinit tag
> itself was getting removed.

Not exactly.  The patch which makes them nops went into 3.8.  Now
there's a patch queued in, Gregs tree I presume, to remove them all and
the #defines which causes the compile failure.

> As to the sparse warnings, this patch fixed the ones that
> were actual bugs in the new code, although we could have
> made that more clear in the patch description.
> 
> http://marc.info/?l=linux-scsi&m=135716576204083&w=2

Ah, thanks ... I've been on holiday for a while, so I did miss that.

> There is one outstanding issue I am aware of which was an
> array bounds compiler warning which looks to be a misdetection
> by the compiler. Wendy and I discussed adding a BUG_ON
> to stop the compiler from complaining.
> 
> Wendy - lets queue these two changes up ASAP. They should both
> be very simple changes.

If it's a simple gcc bug, just ignore it.

I do need you to redo the patches to remove the __dev annotations,
though.  We can't risk introducing a bisect killing compile breakage if
Greg's tree merges before mine in the next merge window.

James

Re: linux-next: build failure after merge of the scsi tree

[Greg KH]

On Fri, Jan 11, 2013 at 03:37:17PM +0000, James Bottomley wrote:
> On Fri, 2013-01-11 at 09:27 -0600, Brian King wrote:
> > It looks like this was a due to the fact that the new patches
> > added __devinit tags in the same merge window the __devinit tag
> > itself was getting removed.
> 
> Not exactly.  The patch which makes them nops went into 3.8.  Now
> there's a patch queued in, Gregs tree I presume, to remove them all and
> the #defines which causes the compile failure.
> 
> > As to the sparse warnings, this patch fixed the ones that
> > were actual bugs in the new code, although we could have
> > made that more clear in the patch description.
> > 
> > http://marc.info/?l=linux-scsi&m=135716576204083&w=2
> 
> Ah, thanks ... I've been on holiday for a while, so I did miss that.
> 
> > There is one outstanding issue I am aware of which was an
> > array bounds compiler warning which looks to be a misdetection
> > by the compiler. Wendy and I discussed adding a BUG_ON
> > to stop the compiler from complaining.
> > 
> > Wendy - lets queue these two changes up ASAP. They should both
> > be very simple changes.
> 
> If it's a simple gcc bug, just ignore it.
> 
> I do need you to redo the patches to remove the __dev annotations,
> though.  We can't risk introducing a bisect killing compile breakage if
> Greg's tree merges before mine in the next merge window.

This change should be pushed to Linus in time for 3.8-final, so there
should not be any bisect issues.

thanks,

greg k-h

Re: linux-next: build failure after merge of the scsi tree

[Brian King]

On 01/11/2013 10:05 AM, Greg KH wrote:
> On Fri, Jan 11, 2013 at 03:37:17PM +0000, James Bottomley wrote:
>> On Fri, 2013-01-11 at 09:27 -0600, Brian King wrote:
>>> It looks like this was a due to the fact that the new patches
>>> added __devinit tags in the same merge window the __devinit tag
>>> itself was getting removed.
>>
>> Not exactly.  The patch which makes them nops went into 3.8.  Now
>> there's a patch queued in, Gregs tree I presume, to remove them all and
>> the #defines which causes the compile failure.
>>
>>> As to the sparse warnings, this patch fixed the ones that
>>> were actual bugs in the new code, although we could have
>>> made that more clear in the patch description.
>>>
>>> http://marc.info/?l=linux-scsi&m=135716576204083&w=2
>>
>> Ah, thanks ... I've been on holiday for a while, so I did miss that.
>>
>>> There is one outstanding issue I am aware of which was an
>>> array bounds compiler warning which looks to be a misdetection
>>> by the compiler. Wendy and I discussed adding a BUG_ON
>>> to stop the compiler from complaining.
>>>
>>> Wendy - lets queue these two changes up ASAP. They should both
>>> be very simple changes.
>>
>> If it's a simple gcc bug, just ignore it.
>>
>> I do need you to redo the patches to remove the __dev annotations,
>> though.  We can't risk introducing a bisect killing compile breakage if
>> Greg's tree merges before mine in the next merge window.
> 
> This change should be pushed to Linus in time for 3.8-final, so there
> should not be any bisect issues.

We can do this either way.

James - what is your preference? Drop everything and do a resend of the
entire series or delta patches on top of what is currently in your tree?

Thanks,

Brian


-- 
Brian King
Power Linux I/O
IBM Linux Technology Center

Re: linux-next: build failure after merge of the scsi tree

[James Bottomley]

On Fri, 2013-01-11 at 11:35 -0600, Brian King wrote:
> On 01/11/2013 10:05 AM, Greg KH wrote:
> > On Fri, Jan 11, 2013 at 03:37:17PM +0000, James Bottomley wrote:
> >> On Fri, 2013-01-11 at 09:27 -0600, Brian King wrote:
> >>> It looks like this was a due to the fact that the new patches
> >>> added __devinit tags in the same merge window the __devinit tag
> >>> itself was getting removed.
> >>
> >> Not exactly.  The patch which makes them nops went into 3.8.  Now
> >> there's a patch queued in, Gregs tree I presume, to remove them all and
> >> the #defines which causes the compile failure.
> >>
> >>> As to the sparse warnings, this patch fixed the ones that
> >>> were actual bugs in the new code, although we could have
> >>> made that more clear in the patch description.
> >>>
> >>> http://marc.info/?l=linux-scsi&m=135716576204083&w=2
> >>
> >> Ah, thanks ... I've been on holiday for a while, so I did miss that.
> >>
> >>> There is one outstanding issue I am aware of which was an
> >>> array bounds compiler warning which looks to be a misdetection
> >>> by the compiler. Wendy and I discussed adding a BUG_ON
> >>> to stop the compiler from complaining.
> >>>
> >>> Wendy - lets queue these two changes up ASAP. They should both
> >>> be very simple changes.
> >>
> >> If it's a simple gcc bug, just ignore it.
> >>
> >> I do need you to redo the patches to remove the __dev annotations,
> >> though.  We can't risk introducing a bisect killing compile breakage if
> >> Greg's tree merges before mine in the next merge window.
> > 
> > This change should be pushed to Linus in time for 3.8-final, so there
> > should not be any bisect issues.
> 
> We can do this either way.
> 
> James - what is your preference? Drop everything and do a resend of the
> entire series or delta patches on top of what is currently in your tree?

Drop everything and resend still, I think.  There's still a rebase
problem, because the merge failure will happen if I rebase the misc tree
to beyond Greg's merge point and I'd rather not have to worry about it.

Thanks,

James

Re: linux-next: build failure after merge of the scsi tree

[wenxiong]

Quoting James Bottomley <James.Bottomley@hansenpartnership.com>:

> On Fri, 2013-01-11 at 11:35 -0600, Brian King wrote:
>> On 01/11/2013 10:05 AM, Greg KH wrote:
>> > On Fri, Jan 11, 2013 at 03:37:17PM +0000, James Bottomley wrote:
>> >> On Fri, 2013-01-11 at 09:27 -0600, Brian King wrote:
>> >>> It looks like this was a due to the fact that the new patches
>> >>> added __devinit tags in the same merge window the __devinit tag
>> >>> itself was getting removed.
>> >>
>> >> Not exactly.  The patch which makes them nops went into 3.8.  Now
>> >> there's a patch queued in, Gregs tree I presume, to remove them all and
>> >> the #defines which causes the compile failure.
>> >>
>> >>> As to the sparse warnings, this patch fixed the ones that
>> >>> were actual bugs in the new code, although we could have
>> >>> made that more clear in the patch description.
>> >>>
>> >>> http://marc.info/?l=linux-scsi&m=135716576204083&w=2
>> >>
>> >> Ah, thanks ... I've been on holiday for a while, so I did miss that.
>> >>
>> >>> There is one outstanding issue I am aware of which was an
>> >>> array bounds compiler warning which looks to be a misdetection
>> >>> by the compiler. Wendy and I discussed adding a BUG_ON
>> >>> to stop the compiler from complaining.
>> >>>
>> >>> Wendy - lets queue these two changes up ASAP. They should both
>> >>> be very simple changes.
>> >>
>> >> If it's a simple gcc bug, just ignore it.
>> >>
>> >> I do need you to redo the patches to remove the __dev annotations,
>> >> though.  We can't risk introducing a bisect killing compile breakage if
>> >> Greg's tree merges before mine in the next merge window.
>> >
>> > This change should be pushed to Linus in time for 3.8-final, so there
>> > should not be any bisect issues.
>>
>> We can do this either way.
>>
>> James - what is your preference? Drop everything and do a resend of the
>> entire series or delta patches on top of what is currently in your tree?
>
> Drop everything and resend still, I think.  There's still a rebase
> problem, because the merge failure will happen if I rebase the misc tree
> to beyond Greg's merge point and I'd rather not have to worry about it.
>
> Thanks,
>
> James

Hi James, I just re-sent all patches which are against
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git.
This kernel already have Greg's "Drivers: scsi: remove _dev*  
attributes" patch.

Let me know if you have any questions for these patches.

Thanks for for your help!
Wendy

Re: linux-next: build failure after merge of the scsi tree

[James Bottomley]

On Wed, 2015-02-04 at 17:29 +1100, Stephen Rothwell wrote:
> Hi James,
> 
> After merging the scsi tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
> 
> drivers/scsi/scsi_logging.c: In function 'sdev_prefix_printk':
> drivers/scsi/scsi_logging.c:119:6: error: void value not ignored as it ought to be
>   ret = dev_printk(level, &sdev->sdev_gendev, "%s", logbuf);
>       ^
> drivers/scsi/scsi_logging.c: In function 'scmd_printk':
> drivers/scsi/scsi_logging.c:146:6: error: void value not ignored as it ought to be
>   ret = dev_printk(level, &scmd->device->sdev_gendev, "%s", logbuf);
>       ^
> 
> Caused by commit ded85c193a39 ("scsi: Implement per-cpu logging
> buffer") interacting with commit d1f1052c5204 ("device: Change
> dev_<level> logging functions to return void") from the driver-core
> tree.
> 
> I added the following merge resolution patch.  Someone will have to
> remember to tell Linus.  Also, the void return may be able to be
> propagated further up the chain since these two new affected functions
> now always return 0.

Hannes posted a more correct fix for it today to the scsi list.
However, sorting this out isn't just about the short term fix:  We can't
afford the bisection failure of SCSI not building over a wide range of
commits, so our tree will need to be pulled ahead of the driver-core
tree.

I've got to say, while it's great that linux-next spotted this ahead of
time (saves us all a massive beating from Linus, thanks Stephen) it's
unfortunate to have this type of thing turn up on the edge of a merge
window, especially caused by a trivial commit which perhaps shouldn't
have gone in so late.

James