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


* James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxx

this bug was obscure and hidden on linux-scsi@xxxxxxxxxxxxxxx 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@xxxxxxxx>
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@xxxxxxxxxxxxxxxxxxxxx

[...]
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@xxxxxxxxxxxxxxxxxxxxx
L: acpi4asus-user@xxxxxxxxxxxxxxxxxxxxx
L: alsa-devel@xxxxxxxxxxxxxxxx (subscribers-only)
L: atl1-devel@xxxxxxxxxxxxxxxxxxxxx
L: autofs@xxxxxxxxxxxxxxxx
L: blinux-list@xxxxxxxxxx
L: bluesmoke-devel@xxxxxxxxxxxxxxxxxxxxx
L: bluez-devel@xxxxxxxxxxxx
L: bonding-devel@xxxxxxxxxxxxxxxxxxxxx
L: bridge@xxxxxxxxxxxxxxxxxxxxxxxxxx
L: cbe-oss-dev@xxxxxxxxxx
L: cluster-devel@xxxxxxxxxx
L: codalist@xxxxxxxxxxxxxxx
L: coreteam@xxxxxxxxxxxxx
L: cpufreq@xxxxxxxxxxxxxxxxxx
L: dc395x@xxxxxxxxxxx
L: dccp@xxxxxxxxxxxxxxx
L: dev-etrax@xxxxxxxx
L: discuss@xxxxxxxxxx
L: DL-MPTFusionLinux@xxxxxxx
L: dm-devel@xxxxxxxxxx
L: dri-devel@xxxxxxxxxxxxxxxxxxxxx
L: e1000-devel@xxxxxxxxxxxxxxxxxxxxx
L: ebtables-devel@xxxxxxxxxxxxxxxxxxxxx
L: ebtables-user@xxxxxxxxxxxxxxxxxxxxx
L: ecryptfs-devel@xxxxxxxxxxxxxxxxxxxxx
L: Eng.Linux@xxxxxxxx
L: fuse-devel@xxxxxxxxxxxxxxxxxxxxx
L: general@xxxxxxxxxxxxxxxxxxxxx
L: gigaset307x-common@xxxxxxxxxxxxxxxxxxxxx
L: hostap@xxxxxxxxx (subscribers-only)
L: http://lists.twibble.org/mailman/listinfo/dc395x/
L: i2c@xxxxxxxxxxxxxx
L: ibm-acpi-devel@xxxxxxxxxxxxxxxxxxxxx
L: info-linux@xxxxxxxxxxxxx
L: ipw2100-devel@xxxxxxxxxxxxxxxxxxxxx
L: ipw3945-devel@xxxxxxxxxxxxxxxxxxxxx
L: irda-users@xxxxxxxxxxxxxxxxxxxxx (subscribers-only)
L: isdn4linux@xxxxxxxxxxxxxxxxxxxxxx
L: iss_storagedev@xxxxxx
L: jfs-discussion@xxxxxxxxxxxxxxxxxxxxx
L: kernel@xxxxxxxxxxxxxx
L: kernel-discuss@xxxxxxxxxxxxx
L: kernel-janitors@xxxxxxxxxxxxxxx
L: kexec@xxxxxxxxxxxxxxxxxxx
L: kpreempt-tech@xxxxxxxxxxxxxxxxxxxxx
L: kvm-devel@xxxxxxxxxxxxxxxxxxxxx
L: legousb-devel@xxxxxxxxxxxxxxxxxxxxx
L: lguest@xxxxxxxxxx
L: libertas-dev@xxxxxxxxxxxxxxxxxxx
L: linux1394-devel@xxxxxxxxxxxxxxxxxxxxx
L: linux-abi-devel@xxxxxxxxxxxxxxxxxxxxx
L: linux-acenic@xxxxxxxxxx
L: linux-acpi@xxxxxxxxxxxxxxx
L: linux-aio@xxxxxxxxx
L: linux-altix@xxxxxxx
L: linux-arm-kernel@xxxxxxxxxxxxxxxxxxxxxx (subscribers-only)
L: linux-atm-general@xxxxxxxxxxxxxxxxxxxxx (subscribers-only)
L: linux-audit@xxxxxxxxxx (subscribers-only)
L: linux-cifs-client@xxxxxxxxxxxxxxx
L: linux-crypto@xxxxxxxxxxxxxxx
L: linux-decnet-user@xxxxxxxxxxxxxxxxxxxxx
L: linux-dvb@xxxxxxxxxxx (subscription required)
L: linux-eata@xxxxxxxxxxxxx, linux-scsi@xxxxxxxxxxxxxxx
L: linux-ext4@xxxxxxxxxxxxxxx
L: linux-fbdev-devel@xxxxxxxxxxxxxxxxxxxxx (subscribers-only)
L: linux-fsdevel@xxxxxxxxxxxxxxx
L: linux-hams@xxxxxxxxxxxxxxx
L: linux-hippi@xxxxxxxxxx
L: linux-ia64@xxxxxxxxxxxxxxx
L: linux-ide@xxxxxxxxxxxxxxx
L: linux-input@xxxxxxxxxxxxxxx
L: linux-kbuild@xxxxxxxxxxxxxxx
L: linux-kernel@xxxxxxxxxxxxxxx
L: linux-laptop@xxxxxxxxxxxxxxx
L: linux-m32r-ja@xxxxxxxxxxxxxxxxx (in Japanese)
L: linux-m32r@xxxxxxxxxxxxxxxxx
L: linux-m68k@xxxxxxxxxxxxxxxxxxxx
L: linux-mips@xxxxxxxxxxxxxx
L: linux-mm@xxxxxxxxx
L: linux-mtd@xxxxxxxxxxxxxxxxxxx
L: linux-nfs@xxxxxxxxxxxxxxx
L: linux-ntfs-dev@xxxxxxxxxxxxxxxxxxxxx
L: linux-nvidia@xxxxxxxxxxxxxxxxxxx
L: linux-parisc@xxxxxxxxxxxxxxx
L: linux-parport@xxxxxxxxxxxxxxxxxxx (subscribers-only)
L: linux-pci@xxxxxxxxxxxxxxxxxxxxxxxx
L: linux-pcmcia@xxxxxxxxxxxxxxxxxxx
L: linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx
L: linuxppc-dev@xxxxxxxxxx
L: linux-ppp@xxxxxxxxxxxxxxx
L: linux-raid@xxxxxxxxxxxxxxx
L: linux-s390@xxxxxxxxxxxxxxx
L: linux-scsi@xxxxxxxxxxxxxxx
L: linux-security-module@xxxxxxxxxxxxxxx
L: linux-serial@xxxxxxxxxxxxxxx
L: linux-sh@xxxxxxxxxxxxxxx
L: linux-tr@xxxxxxxxxxx
L: linux-usb@xxxxxxxxxxxxxxx
L: linux-usb@xxxxxxxxxxxxxxx
L: linux-video@xxxxxxxxxxxxxxxxxxxxxxxx
L: linux-visws-devel@xxxxxxxxxxxx
L: linux-wireless@xxxxxxxxxxxxxxx
L: linux-x25@xxxxxxxxxxxxxxx
L: linware@xxxxxxxxxx
L: lksctp-developers@xxxxxxxxxxxxxxxxxxxxx
L: lm-sensors@xxxxxxxxxxxxxx
L: mactel-linux-devel@xxxxxxxxxxxxxxxxxxxxx
L: mjpeg-users@xxxxxxxxxxxxxxxxxxxxx
L: netdev@xxxxxxxxxxxxxxx
L: netem@xxxxxxxxxxxxxxxxxxxxxxxxxx
L: netfilter-devel@xxxxxxxxxxxxxxx
L: netfilter@xxxxxxxxxxxxxxx
L: nfs@xxxxxxxxxxxxxxxxxxxxx
L: ocfs2-devel@xxxxxxxxxxxxxx
L: openipmi-developer@xxxxxxxxxxxxxxxxxxxxx
L: open-iscsi@xxxxxxxxxxxxxxxx
L: oprofile-list@xxxxxxxxxxxx
L: orinoco-devel@xxxxxxxxxxxxxxxxxxxxx
L: orinoco-users@xxxxxxxxxxxxxxxxxxxxx
L: osst-users@xxxxxxxxxxxxxxxxxxxxx
L: pcihpd-discuss@xxxxxxxxxxxxxxxxxxxxx
L: pvrusb2@xxxxxxxxx (subscribers-only)
L: reiserfs-devel@xxxxxxxxxxxxxxx
L: rio500-users@xxxxxxxxxxxxxxxxxxxxx
L: rt2400-devel@xxxxxxxxxxxxxxxxxxxxx
L: rtc-linux@xxxxxxxxxxxxxxxx
L: samba-technical@xxxxxxxxxxxxxxx
L: sdhci-devel@xxxxxxxxxxxxxx
L: selinux@xxxxxxxxxxxxx (subscribers-only, general discussion)
L: sparclinux@xxxxxxxxxxxxxxx
L: spi-devel-general@xxxxxxxxxxxxxxxxxxxxx
L: stable@xxxxxxxxxx
L: tipc-discussion@xxxxxxxxxxxxxxxxxxxxx
L: tlan-devel@xxxxxxxxxxxxxxxxxxxxx (subscribers-only)
L: tlinux-users@xxxxxxxxxxxxxxxxxxxxx
L: tpmdd-devel@xxxxxxxxxxxxxxxxxxxxx
L: tulip-users@xxxxxxxxxxxxxxxxxxxxx
L: uclinux-dev@xxxxxxxxxxx (subscribers-only)
L: uclinux-dist-devel@xxxxxxxxxxxxxxxxxxxx (subscribers-only)
L: usbb2k-api-dev@xxxxxxxxxx
L: usb-storage@xxxxxxxxxxxxxxxxxxxxxxxx
L: user-mode-linux-devel@xxxxxxxxxxxxxxxxxxxxx
L: user-mode-linux-user@xxxxxxxxxxxxxxxxxxxxx
L: v9fs-developer@xxxxxxxxxxxxxxxxxxxxx
L: video4linux-list@xxxxxxxxxx
L: virtualization@xxxxxxxxxxxxxx
L: vtun@xxxxxxxxxxxxxxxx
L: xen-devel@xxxxxxxxxxxxxxxxxxx
L: xfs@xxxxxxxxxxx
L: zd1211-devs@xxxxxxxxxxxxxxxxxxxxx (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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Relevant Pages

  • Re: Linux 2.6.21
    ... The kernel Bugzilla currently contains 1600 open bugs. ... Adrian, why do you keep harping on this, and ignoring reality? ... I suspect some bug reports get ignored deliberately. ... engage some developers on a bug report. ...
    (Linux-Kernel)
  • Re: Mantis package bombs
    ... for you to report problems in the place that's most accommodating ... things to bugzilla personally. ... implied when I described the bug as "outstanding" rather than "still ... if a bug is likely to be an upstream bug (not ...
    (Fedora)
  • Re: [patch] scsi: revert "[SCSI] Get rid of scsi_cmnd->done"
    ... Noone knows how many thousand bug reports have never reached lkml ... filing or get back to terminate the report. ... But I would like kernel people to become less egocentric ... Send _one_ email to lkml and you'll get forever spam to this address. ...
    (Linux-Kernel)
  • Re: [patch] scsi: revert "[SCSI] Get rid of scsi_cmnd->done"
    ... Noone knows how many thousand bug reports have never reached lkml ... filing or get back to terminate the report. ... But I would like kernel people to become less egocentric ... Send _one_ email to lkml and you'll get forever spam to this address. ...
    (Linux-Kernel)
  • Re: Linux 2.6.21
    ... you can see the _history_ of each bug report sent to LKML ... I didn't want to say that one could entirely replace a bug-tracking system ...
    (Linux-Kernel)