headers
wfg | 16 Jun 2012 02:02
Picon

[driver-core:driver-core-linus 6/6] drivers/firmware/iscsi_ibft_find.o: In function `kmsg_dump_rewind': (.text+0x18): multiple definition of `kmsg_dump_rewind'

Hi Kay,

Kernel build failed on

tree:   git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git driver-core-linus
head:   e2ae715d66bf4becfb85eb84b7150e23cf27df30
commit: e2ae715d66bf4becfb85eb84b7150e23cf27df30 [6/6] kmsg - kmsg_dump() use iterator to receive
log buffer content
config: i386-randconfig-usb1 (attached as .config)

All related error/warning messages are:

drivers/firmware/iscsi_ibft_find.o: In function `kmsg_dump_rewind': (.text+0x18): multiple
definition of `kmsg_dump_rewind'
drivers/firmware/iscsi_ibft_find.o: In function `kmsg_dump_get_buffer': (.text+0xc): multiple
definition of `kmsg_dump_get_buffer'
drivers/firmware/iscsi_ibft_find.o: In function `kmsg_dump_get_line': (.text+0x0): multiple
definition of `kmsg_dump_get_line'
kernel/printk.o: In function `kmsg_dump_rewind': (.text+0x41c): multiple definition of `kmsg_dump_rewind'
kernel/printk.o: In function `kmsg_dump_get_buffer': (.text+0x410): multiple definition of `kmsg_dump_get_buffer'
kernel/printk.o: In function `kmsg_dump_get_line': (.text+0x404): multiple definition of `kmsg_dump_get_line'
kernel/sys.o: In function `kmsg_dump_rewind': (.text+0x59a): multiple definition of `kmsg_dump_rewind'
kernel/sys.o: In function `kmsg_dump_get_buffer': (.text+0x58e): multiple definition of `kmsg_dump_get_buffer'
kernel/sys.o: In function `kmsg_dump_get_line': (.text+0x582): multiple definition of `kmsg_dump_get_line'
arch/x86/kernel/reboot.o: In function `kmsg_dump_rewind': (.text+0x1ea): multiple definition of `kmsg_dump_rewind'
arch/x86/kernel/reboot.o: In function `kmsg_dump_get_buffer': (.text+0x1de): multiple definition
of `kmsg_dump_get_buffer'
arch/x86/kernel/reboot.o: In function `kmsg_dump_get_line': (.text+0x1d2): multiple definition of `kmsg_dump_get_line'
arch/x86/kernel/paravirt.o: In function `kmsg_dump_rewind': (.text+0x565): multiple definition of `kmsg_dump_rewind'
arch/x86/kernel/paravirt.o: In function `kmsg_dump_get_buffer': (.text+0x559): multiple
(Continue reading)

Permalink | Reply |
headers
Stephen Rothwell | 16 Jun 2012 03:15
Picon
Picon

Re: [driver-core:driver-core-linus 6/6] drivers/firmware/iscsi_ibft_find.o: In function `kmsg_dump_rewind': (.text+0x18): multiple definition of `kmsg_dump_rewind'

Hi,

On Sat, 16 Jun 2012 08:02:55 +0800 wfg <at> linux.intel.com wrote:
>
> Kernel build failed on
> 
> tree:   git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git driver-core-linus
> head:   e2ae715d66bf4becfb85eb84b7150e23cf27df30
> commit: e2ae715d66bf4becfb85eb84b7150e23cf27df30 [6/6] kmsg - kmsg_dump() use iterator to receive
log buffer content
> config: i386-randconfig-usb1 (attached as .config)

Please have a good look at what you are sending out.  I don't understand
why this report has come to linuxppc-dev (the patch touches an
arch/powerpc file, but none of the problems reported are in that file).
You should put the .config on a web site somewhere and include the URL and
you should not include the whole patch (these were all quite large) -
people can find them given a tree and commit (like above).

And you sent out 7 reports for the same patch!

I approved this bunch, but will not (unless pressured) approve any more.
This scatter gun automated approach is like the boy crying wolf.

I appreciate the effort, but please tone down the reports considerably.
--

-- 
Cheers,
Stephen Rothwell                    sfr <at> canb.auug.org.au

(Continue reading)






Permalink
| Reply
| 



  


  

  








headers


Fengguang Wu
 | 
16 Jun 2012 03:53






Picon





Re: [driver-core:driver-core-linus 6/6] drivers/firmware/iscsi_ibft_find.o: In function `kmsg_dump_rewind': (.text+0x18): multiple definition of `kmsg_dump_rewind'


Hi Stephen,

On Sat, Jun 16, 2012 at 11:15:50AM +1000, Stephen Rothwell wrote:
> Hi,
> 
> On Sat, 16 Jun 2012 08:02:55 +0800 wfg <at> linux.intel.com wrote:
> >
> > Kernel build failed on
> > 
> > tree:   git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git driver-core-linus
> > head:   e2ae715d66bf4becfb85eb84b7150e23cf27df30
> > commit: e2ae715d66bf4becfb85eb84b7150e23cf27df30 [6/6] kmsg - kmsg_dump() use iterator to receive
log buffer content
> > config: i386-randconfig-usb1 (attached as .config)
> 
> Please have a good look at what you are sending out.  I don't understand
> why this report has come to linuxppc-dev (the patch touches an
> arch/powerpc file, but none of the problems reported are in that file).

Because I blindly used the lists reported by scripts/get_maintainer.pl ...

I'll build a "mailing list <=> git tree" mapping based on MAINTAINERS
and use that to build CC list, rather than depending on the source files
that the patch randomly touch.

> You should put the .config on a web site somewhere and include the URL and
> you should not include the whole patch (these were all quite large) -
> people can find them given a tree and commit (like above).

That's a valid option. Unfortunately I don't have a website to run

(Continue reading)






Permalink
| Reply
| 



  


  

  










headers


Fengguang Wu
 | 
16 Jun 2012 03:53






Picon





Re: [driver-core:driver-core-linus 6/6] drivers/firmware/iscsi_ibft_find.o: In function `kmsg_dump_rewind': (.text+0x18): multiple definition of `kmsg_dump_rewind'


Hi Stephen,

On Sat, Jun 16, 2012 at 11:15:50AM +1000, Stephen Rothwell wrote:
> Hi,
> 
> On Sat, 16 Jun 2012 08:02:55 +0800 wfg <at> linux.intel.com wrote:
> >
> > Kernel build failed on
> > 
> > tree:   git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git driver-core-linus
> > head:   e2ae715d66bf4becfb85eb84b7150e23cf27df30
> > commit: e2ae715d66bf4becfb85eb84b7150e23cf27df30 [6/6] kmsg - kmsg_dump() use iterator to receive
log buffer content
> > config: i386-randconfig-usb1 (attached as .config)
> 
> Please have a good look at what you are sending out.  I don't understand
> why this report has come to linuxppc-dev (the patch touches an
> arch/powerpc file, but none of the problems reported are in that file).

Because I blindly used the lists reported by scripts/get_maintainer.pl ...

I'll build a "mailing list <=> git tree" mapping based on MAINTAINERS
and use that to build CC list, rather than depending on the source files
that the patch randomly touch.

> You should put the .config on a web site somewhere and include the URL and
> you should not include the whole patch (these were all quite large) -
> people can find them given a tree and commit (like above).

That's a valid option. Unfortunately I don't have a website to run

(Continue reading)






Permalink
| Reply
| 



  


  

  












headers


Fengguang Wu
 | 
16 Jun 2012 03:16






Picon





Re: [driver-core:driver-core-linus 6/6] drivers/firmware/iscsi_ibft_find.o: In function `kmsg_dump_rewind': (.text+0x18): multiple definition of `kmsg_dump_rewind'


Hi list,

I'm sorry if this pile of build errors disturbed you too much. If
the error notification is too permissive, I can limit it in two ways:

1) only notify build errors on the first kconfig. There may be a few
   new error messages show up in the other kconfig builds, however
   mostly are just irritating duplications.

2) only notify the mailing list directly associated with the git tree.
   In this particular case, to only CC devel <at> driverdev.osuosl.org, and
   to avoid the linux-mtd and linuxppc-dev lists.

Thanks,
Fengguang

On Sat, Jun 16, 2012 at 08:02:55AM +0800, wfg <at> linux.intel.com wrote:
> Hi Kay,
> 
> Kernel build failed on
> 
> tree:   git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git driver-core-linus
> head:   e2ae715d66bf4becfb85eb84b7150e23cf27df30
> commit: e2ae715d66bf4becfb85eb84b7150e23cf27df30 [6/6] kmsg - kmsg_dump() use iterator to receive log buffer content
> config: i386-randconfig-usb1 (attached as .config)
> 
> All related error/warning messages are:
> 
> drivers/firmware/iscsi_ibft_find.o: In function `kmsg_dump_rewind': (.text+0x18): multiple definition of `kmsg_dump_rewind'
> drivers/firmware/iscsi_ibft_find.o: In function `kmsg_dump_get_buffer': (.text+0xc): multiple definition of `kmsg_dump_get_buffer'

(Continue reading)






Permalink
| Reply
| 



  


  

  








headers


Greg Kroah-Hartman
 | 
16 Jun 2012 03:47






Favicon

Gravatar





Re: [driver-core:driver-core-linus 6/6] drivers/firmware/iscsi_ibft_find.o: In function `kmsg_dump_rewind': (.text+0x18): multiple definition of `kmsg_dump_rewind'


On Sat, Jun 16, 2012 at 09:16:46AM +0800, Fengguang Wu wrote:
> Hi list,
> 
> I'm sorry if this pile of build errors disturbed you too much. If
> the error notification is too permissive, I can limit it in two ways:
> 
> 1) only notify build errors on the first kconfig. There may be a few
>    new error messages show up in the other kconfig builds, however
>    mostly are just irritating duplications.

Duplicates should be suppressed, they are just annoying.

> 2) only notify the mailing list directly associated with the git tree.
>    In this particular case, to only CC devel <at> driverdev.osuosl.org, and
>    to avoid the linux-mtd and linuxppc-dev lists.

Yes, that would be the best thing to do to start with, then let the
developers take it from there.

thanks,

greg k-h






Permalink
| Reply
| 



  


  

  








headers


Fengguang Wu
 | 
16 Jun 2012 04:50






Picon





Reducing the noise level of build error notifications to 0


[switch to LKML]

On Fri, Jun 15, 2012 at 06:47:32PM -0700, Greg Kroah-Hartman wrote:
> On Sat, Jun 16, 2012 at 09:16:46AM +0800, Fengguang Wu wrote:
> > Hi list,
> > 
> > I'm sorry if this pile of build errors disturbed you too much. If
> > the error notification is too permissive, I can limit it in two ways:
> > 
> > 1) only notify build errors on the first kconfig. There may be a few
> >    new error messages show up in the other kconfig builds, however
> >    mostly are just irritating duplications.
> 
> Duplicates should be suppressed, they are just annoying.

OK!  I'll suppress noises in four ways:

rule 1: all newly shown-up error messages will be only notified for
        the current commit and remembered to be "known bug" thereafter.

rule 2: when one bad commit triggers build errors in multiple kconfigs,
        only one of them will be CCed. The patch author will still get
        full information in private emails.

rule 3: when one bad commit triggers build errors in the _subsequent_
        innocent commits of the same branch, the emails will be sent
        to myself for manual check first. This will inevitably lead to
        more delays (esp. when I'm sleeping), however 2+ bad commits
        should not happen frequently.


(Continue reading)






Permalink
| Reply
| 



  


  

  








headers


Greg Kroah-Hartman
 | 
16 Jun 2012 05:44






Favicon

Gravatar





Re: Reducing the noise level of build error notifications to 0


On Sat, Jun 16, 2012 at 10:50:31AM +0800, Fengguang Wu wrote:
> [switch to LKML]
> 
> On Fri, Jun 15, 2012 at 06:47:32PM -0700, Greg Kroah-Hartman wrote:
> > On Sat, Jun 16, 2012 at 09:16:46AM +0800, Fengguang Wu wrote:
> > > Hi list,
> > > 
> > > I'm sorry if this pile of build errors disturbed you too much. If
> > > the error notification is too permissive, I can limit it in two ways:
> > > 
> > > 1) only notify build errors on the first kconfig. There may be a few
> > >    new error messages show up in the other kconfig builds, however
> > >    mostly are just irritating duplications.
> > 
> > Duplicates should be suppressed, they are just annoying.
> 
> OK!  I'll suppress noises in four ways:
> 
> rule 1: all newly shown-up error messages will be only notified for
>         the current commit and remembered to be "known bug" thereafter.
> 
> rule 2: when one bad commit triggers build errors in multiple kconfigs,
>         only one of them will be CCed. The patch author will still get
>         full information in private emails.
> 
> rule 3: when one bad commit triggers build errors in the _subsequent_
>         innocent commits of the same branch, the emails will be sent
>         to myself for manual check first. This will inevitably lead to
>         more delays (esp. when I'm sleeping), however 2+ bad commits
>         should not happen frequently.

(Continue reading)






Permalink
| Reply
| 



  


  

  








headers


Fengguang Wu
 | 
16 Jun 2012 06:11






Picon





Re: Reducing the noise level of build error notifications to 0


Hi Greg,

On Fri, Jun 15, 2012 at 08:44:20PM -0700, Greg Kroah-Hartman wrote:
> On Sat, Jun 16, 2012 at 10:50:31AM +0800, Fengguang Wu wrote:
> > [switch to LKML]
> > 
> > On Fri, Jun 15, 2012 at 06:47:32PM -0700, Greg Kroah-Hartman wrote:
> > > On Sat, Jun 16, 2012 at 09:16:46AM +0800, Fengguang Wu wrote:
> > > > Hi list,
> > > > 
> > > > I'm sorry if this pile of build errors disturbed you too much. If
> > > > the error notification is too permissive, I can limit it in two ways:
> > > > 
> > > > 1) only notify build errors on the first kconfig. There may be a few
> > > >    new error messages show up in the other kconfig builds, however
> > > >    mostly are just irritating duplications.
> > > 
> > > Duplicates should be suppressed, they are just annoying.
> > 
> > OK!  I'll suppress noises in four ways:
> > 
> > rule 1: all newly shown-up error messages will be only notified for
> >         the current commit and remembered to be "known bug" thereafter.
> > 
> > rule 2: when one bad commit triggers build errors in multiple kconfigs,
> >         only one of them will be CCed. The patch author will still get
> >         full information in private emails.
> > 
> > rule 3: when one bad commit triggers build errors in the _subsequent_
> >         innocent commits of the same branch, the emails will be sent

(Continue reading)






Permalink
| Reply
| 



  


  

  








headers


Fengguang Wu
 | 
16 Jun 2012 06:20






Picon





Re: Reducing the noise level of build error notifications to 0


On Sat, Jun 16, 2012 at 12:11:44PM +0800, Fengguang Wu wrote:
> Hi Greg,
> 
> On Fri, Jun 15, 2012 at 08:44:20PM -0700, Greg Kroah-Hartman wrote:
> > On Sat, Jun 16, 2012 at 10:50:31AM +0800, Fengguang Wu wrote:
> > > [switch to LKML]
> > > 
> > > On Fri, Jun 15, 2012 at 06:47:32PM -0700, Greg Kroah-Hartman wrote:
> > > > On Sat, Jun 16, 2012 at 09:16:46AM +0800, Fengguang Wu wrote:
> > > > > Hi list,
> > > > > 
> > > > > I'm sorry if this pile of build errors disturbed you too much. If
> > > > > the error notification is too permissive, I can limit it in two ways:
> > > > > 
> > > > > 1) only notify build errors on the first kconfig. There may be a few
> > > > >    new error messages show up in the other kconfig builds, however
> > > > >    mostly are just irritating duplications.
> > > > 
> > > > Duplicates should be suppressed, they are just annoying.
> > > 
> > > OK!  I'll suppress noises in four ways:
> > > 
> > > rule 1: all newly shown-up error messages will be only notified for
> > >         the current commit and remembered to be "known bug" thereafter.
> > > 
> > > rule 2: when one bad commit triggers build errors in multiple kconfigs,
> > >         only one of them will be CCed. The patch author will still get
> > >         full information in private emails.
> > > 
> > > rule 3: when one bad commit triggers build errors in the _subsequent_

(Continue reading)






Permalink
| Reply
| 



  


  

  








headers


Greg Kroah-Hartman
 | 
16 Jun 2012 17:27






Favicon

Gravatar





Re: Reducing the noise level of build error notifications to 0


On Sat, Jun 16, 2012 at 12:20:10PM +0800, Fengguang Wu wrote:
> > > How about also cc: not only the author where you mention it above, but
> > > everyone who signed-off on the patch?  That would provide a bit of peer
> > > pressure to ensure that the problems get fixed.
> > 
> > That's (interesting and) good point. If me understand you right:
> > 
> > - TO: author, CC: Signed-off-by, CC: (sub-)subsystem mailing list
> >   for build errors
> > 
> > - TO: author, CC: Signed-off-by (but sure, remove the top level busy maintainers)
> >   for gcc warnings

Well, if I sign-off on a patch, I want to know about gcc warnings that
were added by it, don't not email me just because you think I'm busy.

> Or, just remove the committer from CC: and add Reviewed-by to CC: 
> By reviewing, one should already be familiar with the patch.

I don't think you should drop the committer, but maybe that's just me.

> > - TO: author
> >   for sparse warnings (however I'm still too afraid to enable sparse checks)

This might get tougher in some areas of the kernel like the
drivers/staging/ tree where people incrementally fix things up, like fix
trailing space issues on one patch, which doesn't change the rest of the
line that might have had coding style or sparse issues in it.  That's
why I can't always run checkpatch.pl on patches sent to me, and why
sparse might not help out.

(Continue reading)






Permalink
| Reply
| 



  


  

  








headers


Fengguang Wu
 | 
17 Jun 2012 05:35






Picon





Re: Reducing the noise level of build error notifications to 0


On Sat, Jun 16, 2012 at 08:27:20AM -0700, Greg Kroah-Hartman wrote:
> On Sat, Jun 16, 2012 at 12:20:10PM +0800, Fengguang Wu wrote:
> > > > How about also cc: not only the author where you mention it above, but
> > > > everyone who signed-off on the patch?  That would provide a bit of peer
> > > > pressure to ensure that the problems get fixed.
> > > 
> > > That's (interesting and) good point. If me understand you right:
> > > 
> > > - TO: author, CC: Signed-off-by, CC: (sub-)subsystem mailing list
> > >   for build errors
> > > 
> > > - TO: author, CC: Signed-off-by (but sure, remove the top level busy maintainers)
> > >   for gcc warnings
> 
> Well, if I sign-off on a patch, I want to know about gcc warnings that
> were added by it, don't not email me just because you think I'm busy.

OK :)

> > Or, just remove the committer from CC: and add Reviewed-by to CC: 
> > By reviewing, one should already be familiar with the patch.
> 
> I don't think you should drop the committer, but maybe that's just me.

Understand. Let's default to CC all signers and committer.

> > > - TO: author
> > >   for sparse warnings (however I'm still too afraid to enable sparse checks)
> 
> This might get tougher in some areas of the kernel like the

(Continue reading)






Permalink
| Reply
| 



  


  

  






















headers


Greg Kroah-Hartman
 | 
16 Jun 2012 03:47






Favicon

Gravatar





Re: [driver-core:driver-core-linus 6/6] drivers/firmware/iscsi_ibft_find.o: In function `kmsg_dump_rewind': (.text+0x18): multiple definition of `kmsg_dump_rewind'


On Sat, Jun 16, 2012 at 09:16:46AM +0800, Fengguang Wu wrote:
> Hi list,
> 
> I'm sorry if this pile of build errors disturbed you too much. If
> the error notification is too permissive, I can limit it in two ways:
> 
> 1) only notify build errors on the first kconfig. There may be a few
>    new error messages show up in the other kconfig builds, however
>    mostly are just irritating duplications.

Duplicates should be suppressed, they are just annoying.

> 2) only notify the mailing list directly associated with the git tree.
>    In this particular case, to only CC devel <at> driverdev.osuosl.org, and
>    to avoid the linux-mtd and linuxppc-dev lists.

Yes, that would be the best thing to do to start with, then let the
developers take it from there.

thanks,

greg k-h






Permalink
| Reply
| 



  


  

  












headers


Stephen Rothwell
 | 
16 Jun 2012 03:15






Picon

Picon





Re: [driver-core:driver-core-linus 6/6] drivers/firmware/iscsi_ibft_find.o: In function `kmsg_dump_rewind': (.text+0x18): multiple definition of `kmsg_dump_rewind'


Hi,

On Sat, 16 Jun 2012 08:02:55 +0800 wfg <at> linux.intel.com wrote:
>
> Kernel build failed on
> 
> tree:   git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git driver-core-linus
> head:   e2ae715d66bf4becfb85eb84b7150e23cf27df30
> commit: e2ae715d66bf4becfb85eb84b7150e23cf27df30 [6/6] kmsg - kmsg_dump() use iterator to receive
log buffer content
> config: i386-randconfig-usb1 (attached as .config)

Please have a good look at what you are sending out.  I don't understand
why this report has come to linuxppc-dev (the patch touches an
arch/powerpc file, but none of the problems reported are in that file).
You should put the .config on a web site somewhere and include the URL and
you should not include the whole patch (these were all quite large) -
people can find them given a tree and commit (like above).

And you sent out 7 reports for the same patch!

I approved this bunch, but will not (unless pressured) approve any more.
This scatter gun automated approach is like the boy crying wolf.

I appreciate the effort, but please tone down the reports considerably.
--

-- 
Cheers,
Stephen Rothwell                    sfr <at> canb.auug.org.au



(Continue reading)






Permalink
| Reply
| 



  


  

  










headers


Fengguang Wu
 | 
16 Jun 2012 03:16






Picon





Re: [driver-core:driver-core-linus 6/6] drivers/firmware/iscsi_ibft_find.o: In function `kmsg_dump_rewind': (.text+0x18): multiple definition of `kmsg_dump_rewind'


Hi list,

I'm sorry if this pile of build errors disturbed you too much. If
the error notification is too permissive, I can limit it in two ways:

1) only notify build errors on the first kconfig. There may be a few
   new error messages show up in the other kconfig builds, however
   mostly are just irritating duplications.

2) only notify the mailing list directly associated with the git tree.
   In this particular case, to only CC devel <at> driverdev.osuosl.org, and
   to avoid the linux-mtd and linuxppc-dev lists.

Thanks,
Fengguang

On Sat, Jun 16, 2012 at 08:02:55AM +0800, wfg <at> linux.intel.com wrote:
> Hi Kay,
> 
> Kernel build failed on
> 
> tree:   git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git driver-core-linus
> head:   e2ae715d66bf4becfb85eb84b7150e23cf27df30
> commit: e2ae715d66bf4becfb85eb84b7150e23cf27df30 [6/6] kmsg - kmsg_dump() use iterator to receive log buffer content
> config: i386-randconfig-usb1 (attached as .config)
> 
> All related error/warning messages are:
> 
> drivers/firmware/iscsi_ibft_find.o: In function `kmsg_dump_rewind': (.text+0x18): multiple definition of `kmsg_dump_rewind'
> drivers/firmware/iscsi_ibft_find.o: In function `kmsg_dump_get_buffer': (.text+0xc): multiple definition of `kmsg_dump_get_buffer'

(Continue reading)






Permalink
| Reply
| 



  


  

  








  





    



Gmane