Re: [PATCH] s390 (8/10): zfcp fixes.

[Martin Schwidefsky]

Hi Greg,

> > This is not ok.  If you have to do something like this, I really suggest
> > that you not allow the "sub modules" be able to unload before the upper
> > module can.  In fact, why would you want to do such a thing?
> How do sub modules help with the release function problem? The unit/port
> objects get unregistered in zfcp_unit_dequeue. This happens e.g. when
> a zfcp adapter gets removed because of a detach. After the last zfcp
> adapter got removed the module is in principle ready to be removed.
> Now there are two cases. 1) The module count of the zfcp module (or one
> of the non-existent sub-modules) is NOT increase because of the outstanding
> call to the release function. It obvious that the release function can't
> be part of the zfcp module(s) in this case. 2) The module count of the
> zfcp module(s) is elevated because of the outstanding call to release.
> Who does the module_put in this case? The release function only can do it
> if it is not part of ANY of the modules. If it is part of a zfcp module
> the cpu doing the module_put might not be able to get out of the release
> function fast enough before another cpu has removed the module(s)
> (including the sub-modules).
> Did I miss something ?
>
> > I still really strongly object to this patch.  If it's a scsi problem,
> > fix it there, but odds are it's your driver's problem as no other scsi
> > driver needs this.
> If we can move the port/unit objects to the scsi mid layer that would
> "solve" the problem for the zfcp module. But the problem itself doesn't
> go away. It's just moved one step up the ladder.

Did I manage to convince you or are you just fed up with the discussion?
I'll ask because the zfcp patches are still pending and I want to get this
issue resolved before the next try to get them integrated.

blue skies,
   Martin

Linux/390 Design & Development, IBM Deutschland Entwicklung GmbH
Schönaicherstr. 220, D-71032 Böblingen, Telefon: 49 - (0)7031 - 16-2247
E-Mail: schwidefsky@xxxxxxxxxx



-
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/