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

From: Martin Schwidefsky
Date: Wed Mar 17 2004 - 07:07:56 EST






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.

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/