freebsd-scsi Digest, Vol 363, Issue 6
freebsd-sc...@freebsd.org
freebs...@freebsd.org
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.freebsd.org/mailman/listinfo/freebsd-scsi
or, via email, send a message with subject or body 'help' to
freebsd-sc...@freebsd.org
You can reach the person managing the list at
freebsd-s...@freebsd.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of freebsd-scsi digest..."
Today's Topics:
1. cam_periph, and locking? (Matthew Jacob)
2. Re: virtual drive errors (Ulrich Sp?rlein)
----------------------------------------------------------------------
Message: 1
Date: Sat, 10 Apr 2010 09:30:55 -0700
From: Matthew Jacob <m...@feral.com>
Subject: cam_periph, and locking?
To: freebs...@freebsd.org
Message-ID: <4BC0A7BF...@feral.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
This subject seems to have petered out a bit.....
Where are we on the locking for the list? I personally like Alexander's
unit_lock change.
On my own front, some work priorities shifted, so I haven't (yet)
finished a lot of the test to destruction stuff, but I have made some
findings and found some (partial, incomplete) remedies.
Here are my notes from the other day on this. Bear with me on this- they
aren't the most polished, it's WIP. Comments welcome.
A) Four basic problems
+ Periph invalidation can occur after a periph_find. Not all calls are
protected by a sim lock.
+ The probe state machine can (sometimes) continue despite a failure
that caused a periph invalidation
+ Some of the periph driver callbacks (dasysctlinit, some side effects
of disk_create) are not cognizant of periph invalidation and blindly use
pointers, etc.
+ periph invalidation *during* probe can lead to reference after free or
bad reference (panics)
Note that some of this stuff is not really affected by locking.
(minor addendum- cam_periph_release_locked can cause the ref count to go
negative)
B) Remedies
=> periph_find bumps a refcount (this has obvious MFC and other
implications, as you have to have the caller remember to release)
=> the probe periph driver should do a periph_hold so that the periph
doesn't disappear until the periph driver explicitly unholds it
=> periph drivers can't use callbacks that just have pointers to an
unheld periph structure.
With these changes in place, my simulated unit test ran much better-
still ended up with a bug where cam_periph_runccb never came back, but
at least I wasn't stuck in panics and ref's after free instantly like I
was before.
------------------------------
Message: 2
Date: Sun, 11 Apr 2010 10:36:19 +0200
From: Ulrich Sp?rlein <u...@spoerlein.net>
Subject: Re: virtual drive errors
To: Andriy Gapon <a...@icyb.net.ua>
Cc: freebs...@freebsd.org, Hans Petter Selasky <hsel...@c2i.net>,
Markus Wild <m.w...@cybernet.ch>, freebsd...@freebsd.org
Message-ID: <20100411083...@acme.spoerlein.net>
Content-Type: text/plain; charset=us-ascii
On Thu, 08.04.2010 at 00:50:40 +0300, Andriy Gapon wrote:
> Looking at cdcheckmedia and at the logged READ TOC (0x43) SCSI command errors
> (as reported by Markus) I see the following problem. Even if cdsize() call at
> the beginning of cdcheckmedia() succeeds, a subsequent failure of cdreadtoc()
> throws us to 'bailout' label which is past the code that sets d_mediasize.
>
> I think that the following patch should help with this situation (and possibly
> other cases with READ TOC problems):
>
> --- a/sys/cam/scsi/scsi_cd.c
> +++ b/sys/cam/scsi/scsi_cd.c
>[snip]
This patch, much like the one in kern/138789 makes my external Plextor
PX-755A drive successfully read "mastered" DVD media, i.e., the retail
kind, not DVD-R/RW.
So, please commit some version of this patch. Thanks!
Regards,
Uli
------------------------------
End of freebsd-scsi Digest, Vol 363, Issue 6
********************************************