On Mon, May 15, 2017 at 08:30:19PM +0200, Martin Wilck wrote:
> please be assured that I'm not trying to paper over anything. Your
> concern about sdev->handler_data is justified. While I think that it's
> a separate issue from what my patches were supposed to address, let me
> see if I can come
On Mon, 2017-05-15 at 16:03 +, Bart Van Assche wrote:
> On Mon, 2017-05-15 at 10:16 +0200, Martin Wilck wrote:
> > On Fri, 2017-05-12 at 16:24 +, Bart Van Assche wrote:
> > > Allowing races like the one this patch tries to address to exist
> > > makes the ALUA code harder to maintain than
On Mon, 2017-05-15 at 10:16 +0200, Martin Wilck wrote:
> On Fri, 2017-05-12 at 16:24 +, Bart Van Assche wrote:
> > Allowing races like the one this patch tries to address to exist
> > makes the ALUA code harder to maintain than necessary. Have you
> > considered to make alua_bus_detach() wait
On Fri, 2017-05-12 at 16:24 +, Bart Van Assche wrote:
>
> Hello Martin,
>
> Allowing races like the one this patch tries to address to exist
> makes
> the ALUA code harder to maintain than necessary. Have you considered
> to
> make alua_bus_detach() wait until ALUA work has finished by
On Fri, 2017-05-12 at 15:15 +0200, Martin Wilck wrote:
> alua_rtpg() can race with alua_bus_detach(). The assertion that
> alua_dh_data *h->sdev must be non-NULL is not guaranteed because
> alua_bus_detach sets this field to NULL before removing the entry
> from the port group's dh_list.
>
> This
alua_rtpg() can race with alua_bus_detach(). The assertion that
alua_dh_data *h->sdev must be non-NULL is not guaranteed because
alua_bus_detach sets this field to NULL before removing the entry
from the port group's dh_list.
This happens when a device is about to be removed, so don't BUG out
but
6 matches
Mail list logo
