freebsd-scsi Digest, Vol 362, Issue 3
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. Re: How is supposed to be protected the units list? (Attilio Rao)
2. Re: How is supposed to be protected the units list?
(Matthew Jacob)
3. Re: How is supposed to be protected the units list? (Attilio Rao)
4. Re: How is supposed to be protected the units list?
(Matthew Jacob)
----------------------------------------------------------------------
Message: 1
Date: Tue, 30 Mar 2010 16:25:30 +0200
From: Attilio Rao <att...@freebsd.org>
Subject: Re: How is supposed to be protected the units list?
To: Alexander Motin <m...@freebsd.org>
Cc: freebs...@freebsd.org, "Justin T. Gibbs" <gi...@freebsd.org>,
m...@feral.com, Ed Maste <ema...@sandvine.com>
Message-ID:
<3bbf2fe11003300725vdb...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
2010/3/21 Alexander Motin <m...@freebsd.org>:
> Attilio Rao wrote:
>> So I made this new patch using the bus lock:
>> http://www.freebsd.org/~attilio/Sandvine/pdrv/xpt_lock.diff
>
> OK. I've looked on both and I think both have race window between unit
> number allocation and insertion into the list. I've changed last patch
> to not drop the lock in meantime. What do you think about this:
> http://people.freebsd.org/~mav/unit_lock.patch
> ?
>
> Part about scsi_da.c I don't like in both cases, as I am not sure that
> locks can't be recursed there in case of some errors. I don't see how
> adding second lock could solve it.
The lock recursion is going to happen because of the necessary
refcount acquisition as Matt pointed out?
Or there is another recursion?
In the former case, the global lock will help because you may just
acquire it, refcount the periph, cache them and run lockless.
You can't do this with xpt_lock_bus because of the recursion in
cam_periph_acquire.
So we want to live this unprotected and just live with this bug?
Attilio
--
Peace can only be achieved by understanding - A. Einstein
------------------------------
Message: 2
Date: Tue, 30 Mar 2010 07:34:24 -0700
From: Matthew Jacob <m...@feral.com>
Subject: Re: How is supposed to be protected the units list?
To: freebs...@freebsd.org
Message-ID: <4BB20BF0...@feral.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
I was distracted yesterday so didn't finish my testing.
There are still lots of issues that can occur. I'm still forming some
thoughts on this, but part of the problem is that there are things going
on with a periph that make this difficult. Pieces of it can change or be
changed- even under a lock- but the code surrounding the lock isn't
aware that it can change *between* the lock. For example, I think that
cam_periph alloc can have two different arrivals of something which
could be for the same periph can end up with two different periph
structures on the list with different unit numbers that point to the
same bus. It doesn't matter that there were locks to provide some
stability because the locks were dropped in between.
> The lock recursion is going to happen because of the necessary
> refcount acquisition as Matt pointed out?
> Or there is another recursion?
> In the former case, the global lock will help because you may just
> acquire it, refcount the periph, cache them and run lockless.
> You can't do this with xpt_lock_bus because of the recursion in
> cam_periph_acquire.
>
> So we want to live this unprotected and just live with this bug?
>
> Attilio
>
>
>
------------------------------
Message: 3
Date: Tue, 30 Mar 2010 16:43:50 +0200
From: Attilio Rao <att...@freebsd.org>
Subject: Re: How is supposed to be protected the units list?
To: Matthew Jacob <m...@feral.com>
Cc: freebs...@freebsd.org
Message-ID:
<3bbf2fe11003300743k704...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
2010/3/30 Matthew Jacob <m...@feral.com>:
>
> I was distracted yesterday so didn't finish my testing.
>
> There are still lots of issues that can occur. I'm still forming some
> thoughts on this, but part of the problem is that there are things going on
> with a periph that make this difficult. Pieces of it can change or be
> changed- even under a lock- but the code surrounding the lock isn't aware
> that it can change *between* the lock. For example, I think that cam_periph
> alloc can have two different arrivals of something which could be for the
> same periph can end up with two different periph structures on the list with
> different unit numbers that point to the same bus. It doesn't matter that
> there were locks to provide some stability because the locks were dropped in
> between.
May you please refer precisely to current code snippets (in terms of
functions, file, line, etc) in order to better explain this and the
other issues, when you have time?
Thanks,
Attilio
--
Peace can only be achieved by understanding - A. Einstein
------------------------------
Message: 4
Date: Tue, 30 Mar 2010 09:14:57 -0700
From: Matthew Jacob <m...@feral.com>
Subject: Re: How is supposed to be protected the units list?
To: freebs...@freebsd.org
Message-ID: <4BB22381...@feral.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Absolutely. I might also be insane. Working on finding that out.
> May you please refer precisely to current code snippets (in terms of
> functions, file, line, etc) in order to better explain this and the
> other issues, when you have time?
>
> Thanks,
> Attilio
>
>
>
------------------------------
End of freebsd-scsi Digest, Vol 362, Issue 3
********************************************