lkml.org 
[lkml]   [2008]   [Jan]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [patch] scsi: revert "[SCSI] Get rid of scsi_cmnd->done"

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

> > I can repeat this bug, both with and without the scsi patch that is
> > claimed to make a difference, both with an external USB drive and an
> > internal IDE drive.
> >
> > To repeat:
> >
> > 1. Start with an empty drive.
> > 2. pktsetup 0 /dev/scd0
> > 3. Insert a CD containing an isofs filesystem.
> > 4. mount /dev/pktcdvd/0 /mnt/tmp
> > 5. umount /mnt/tmp
> > 6. Press the eject button.
> > 7. Insert a DVD containing a non-writable filesystem.
> > 8. mount /dev/scd0 /mnt/tmp
> > 9. find /mnt/tmp -type f -print0 | xargs -0 sha1sum >/dev/null
> > 10. If the DVD contains data beyond the physical size of a CD, you
> > get I/O errors in the terminal, and dmesg reports lots of
> > "attempt to access beyond end of device" errors.
>
> Brilliant! I can confirm the reproduction of the bug too (that's with
> the originally fingered commit reverted).

may i point out the obvious at this stage? The thing that finally got
movement into this bug was ... :

exposure on lkml

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.

_THAT_ is the power of lkml. People who are not generally interested in
your subsystem come and help. There is extra noise, but it's manageable.

so may i at this point suggest that you as the SCSI maintainer start
reading SCSI bugreports on lkml and start participating in SCSI topics
there, without extra prompting? It _is_ an important aggregation mailing
list for development, just like -mm or the upstream kernel is an
aggregation point of all things Linux.

I believe the "I only read linux-scsi, please post bugs there" approach
is harmful. If lkml traffic is too big then i'd suggest to set up email
filters to separate out mails that have 'SCSI' in their subject line or
body. Fortunately it's a really easy key to filter on. [ Scheduler mails
are much harder to filter out :-/ ] In fact i'd suggest to do all SCSI
development on lkml. We've got one upstream kernel codebase, one git
stream of commits and hence we should use one lkml feed to discuss
things on.

Ingo


\
 
 \ /
  Last update: 2008-01-06 15:55    [W:0.214 / U:0.076 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site