Re: [patch] scsi: revert "[SCSI] Get rid of scsi_cmnd->done"

Ingo Molnar
2008-01-06T16:12:36Z

* James Bottomley <James.Bottomley@HansenPartnership.com> wrote:

> > The reproducer came to you via Peter Osterlund who has never
> > authored a single drivers/scsi/ commit before (according to git-log)
> > and who (and here i'm out on a limb guessing it) does not even
> > follow linux-scsi@vger.kernel.org.
> >
> > this bug was obscure and hidden on linux-scsi@vger.kernel.org for
> > _months_, (it is a rarely visited and rarely read mailing list) and
> > there was just not enough "critical mass" to get this issue fixed.
>
> If I were you, I'd actually make a cursory effort to get my facts
> straight before spouting off.
>
> This bug was actually hidden in bugzilla for ages, where Matthew
> Wilcox was trying to deal with it on his own. [...]

Huh? The bugzilla just tracked a bug reported to lkml. The very
description of the bugzilla says:

Subject : v2.6.24-rc2-409-g9418d5d: attempt to access beyond end of device
Submitter : Thomas Meyer <thomas@m3y3r.de>
References : http://lkml.org/lkml/2007/11/13/250

so no, it was evidently not "hidden in bugzilla for ages" - all the
important action happened on lkml.

> The whole problem with this bug was generated precisely because it was
> kept in bugzilla where too few people actually looked at it. You're
> the one who annotated the bugzilla entries with trite little homilies
> asking why there was no action *without* ever notifying any mailing
> list, I might add.

again, this bugzilla entry originated from lkml. I did ping the bugzilla
because i saw that the suspected commit's author was Cc:-ed already. Why
should every bug reporter and debugger be fully aware of the absolutely
SILLY little details and preferences of maintainers about how and whom
to report bugs?

YOU made the workflow fragile in the first place, by going away to
linux-scsi and ignoring lkml reports. Or in your own words, in the
bugzilla, comment #9:

http://bugzilla.kernel.org/show_bug.cgi?id=9370#c9

Reply-To: James.Bottomley@HansenPartnership.com

[...]
Erm, actually no ... this is the first I've heard of it, except as a
passing question from matthew. It's usually safe to assume if it's
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
not on linux-scsi I haven't seen it.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

that's fundamentally flawed. For testers there should be only one,
simple as possible rule:

"if you have a problem with the Linux kernel, then report it to lkml"

[ or report it to your distro or bugzilla.kernel.org, where it will be
propagated towards lkml by others. ]

not to "report it to one of the 100+ lists listed here - good luck
getting it right":

L: accessrunner-general@lists.sourceforge.net
L: acpi4asus-user@lists.sourceforge.net
L: alsa-devel@alsa-project.org (subscribers-only)
L: atl1-devel@lists.sourceforge.net
L: autofs@linux.kernel.org
L: blinux-list@redhat.com
L: bluesmoke-devel@lists.sourceforge.net
L: bluez-devel@lists.sf.net
L: bonding-devel@lists.sourceforge.net
L: bridge@lists.linux-foundation.org
L: cbe-oss-dev@ozlabs.org
L: cluster-devel@redhat.com
L: codalist@coda.cs.cmu.edu
L: coreteam@netfilter.org
L: cpufreq@lists.linux.org.uk
L: dc395x@twibble.org
L: dccp@vger.kernel.org
L: dev-etrax@axis.com
L: discuss@x86-64.org
L: DL-MPTFusionLinux@lsi.com
L: dm-devel@redhat.com
L: dri-devel@lists.sourceforge.net
L: e1000-devel@lists.sourceforge.net
L: ebtables-devel@lists.sourceforge.net
L: ebtables-user@lists.sourceforge.net
L: ecryptfs-devel@lists.sourceforge.net
L: Eng.Linux@digi.com
L: fuse-devel@lists.sourceforge.net
L: general@lists.openfabrics.org
L: gigaset307x-common@lists.sourceforge.net
L: hostap@shmoo.com (subscribers-only)
L: http://lists.twibble.org/mailman/listinfo/dc395x/
L: i2c@lm-sensors.org
L: ibm-acpi-devel@lists.sourceforge.net
L: info-linux@geode.amd.com
L: ipw2100-devel@lists.sourceforge.net
L: ipw3945-devel@lists.sourceforge.net
L: irda-users@lists.sourceforge.net (subscribers-only)
L: isdn4linux@listserv.isdn4linux.de
L: iss_storagedev@hp.com
L: jfs-discussion@lists.sourceforge.net
L: kernel@avr32linux.org
L: kernel-discuss@handhelds.org
L: kernel-janitors@vger.kernel.org
L: kexec@lists.infradead.org
L: kpreempt-tech@lists.sourceforge.net
L: kvm-devel@lists.sourceforge.net
L: legousb-devel@lists.sourceforge.net
L: lguest@ozlabs.org
L: libertas-dev@lists.infradead.org
L: linux1394-devel@lists.sourceforge.net
L: linux-abi-devel@lists.sourceforge.net
L: linux-acenic@sunsite.dk
L: linux-acpi@vger.kernel.org
L: linux-aio@kvack.org
L: linux-altix@sgi.com
L: linux-arm-kernel@lists.arm.linux.org.uk (subscribers-only)
L: linux-atm-general@lists.sourceforge.net (subscribers-only)
L: linux-audit@redhat.com (subscribers-only)
L: linux-cifs-client@lists.samba.org
L: linux-crypto@vger.kernel.org
L: linux-decnet-user@lists.sourceforge.net
L: linux-dvb@linuxtv.org (subscription required)
L: linux-eata@i-connect.net, linux-scsi@vger.kernel.org
L: linux-ext4@vger.kernel.org
L: linux-fbdev-devel@lists.sourceforge.net (subscribers-only)
L: linux-fsdevel@vger.kernel.org
L: linux-hams@vger.kernel.org
L: linux-hippi@sunsite.dk
L: linux-ia64@vger.kernel.org
L: linux-ide@vger.kernel.org
L: linux-input@vger.kernel.org
L: linux-kbuild@vger.kernel.org
L: linux-kernel@vger.kernel.org
L: linux-laptop@vger.kernel.org
L: linux-m32r-ja@ml.linux-m32r.org (in Japanese)
L: linux-m32r@ml.linux-m32r.org
L: linux-m68k@lists.linux-m68k.org
L: linux-mips@linux-mips.org
L: linux-mm@kvack.org
L: linux-mtd@lists.infradead.org
L: linux-nfs@vger.kernel.org
L: linux-ntfs-dev@lists.sourceforge.net
L: linux-nvidia@lists.surfsouth.com
L: linux-parisc@vger.kernel.org
L: linux-parport@lists.infradead.org (subscribers-only)
L: linux-pci@atrey.karlin.mff.cuni.cz
L: linux-pcmcia@lists.infradead.org
L: linux-pm@lists.linux-foundation.org
L: linuxppc-dev@ozlabs.org
L: linux-ppp@vger.kernel.org
L: linux-raid@vger.kernel.org
L: linux-s390@vger.kernel.org
L: linux-scsi@vger.kernel.org
L: linux-security-module@vger.kernel.org
L: linux-serial@vger.kernel.org
L: linux-sh@vger.kernel.org
L: linux-tr@linuxtr.net
L: linux-usb@vger.kernel.org
L: linux-usb@vger.kernel.org
L: linux-video@atrey.karlin.mff.cuni.cz
L: linux-visws-devel@lists.sf.net
L: linux-wireless@vger.kernel.org
L: linux-x25@vger.kernel.org
L: linware@sh.cvut.cz
L: lksctp-developers@lists.sourceforge.net
L: lm-sensors@lm-sensors.org
L: mactel-linux-devel@lists.sourceforge.net
L: mjpeg-users@lists.sourceforge.net
L: netdev@vger.kernel.org
L: netem@lists.linux-foundation.org
L: netfilter-devel@vger.kernel.org
L: netfilter@vger.kernel.org
L: nfs@lists.sourceforge.net
L: ocfs2-devel@oss.oracle.com
L: openipmi-developer@lists.sourceforge.net
L: open-iscsi@googlegroups.com
L: oprofile-list@lists.sf.net
L: orinoco-devel@lists.sourceforge.net
L: orinoco-users@lists.sourceforge.net
L: osst-users@lists.sourceforge.net
L: pcihpd-discuss@lists.sourceforge.net
L: pvrusb2@isely.net (subscribers-only)
L: reiserfs-devel@vger.kernel.org
L: rio500-users@lists.sourceforge.net
L: rt2400-devel@lists.sourceforge.net
L: rtc-linux@googlegroups.com
L: samba-technical@lists.samba.org
L: sdhci-devel@list.drzeus.cx
L: selinux@tycho.nsa.gov (subscribers-only, general discussion)
L: sparclinux@vger.kernel.org
L: spi-devel-general@lists.sourceforge.net
L: stable@kernel.org
L: tipc-discussion@lists.sourceforge.net
L: tlan-devel@lists.sourceforge.net (subscribers-only)
L: tlinux-users@tce.toshiba-dme.co.jp
L: tpmdd-devel@lists.sourceforge.net
L: tulip-users@lists.sourceforge.net
L: uclinux-dev@uclinux.org (subscribers-only)
L: uclinux-dist-devel@blackfin.uclinux.org (subscribers-only)
L: usbb2k-api-dev@nongnu.org
L: usb-storage@lists.one-eyed-alien.net
L: user-mode-linux-devel@lists.sourceforge.net
L: user-mode-linux-user@lists.sourceforge.net
L: v9fs-developer@lists.sourceforge.net
L: video4linux-list@redhat.com
L: virtualization@lists.osdl.org
L: vtun@office.satix.net
L: xen-devel@lists.xensource.com
L: xfs@oss.sgi.com
L: zd1211-devs@lists.sourceforge.net (subscribers-only)

yes, there can be other lists and mails, so this isnt a rigid rule in
any way, but the _default_ is for maintainers of major subsystems to be
aware of all bugs related (or suspected to be related) to their
subsystems reported to lkml. Not to be dragged on to lkml kicking and
screaming ;-) lkml isnt just for the core kernel, it's for the _whole_
kernel.

Ingo