AW: [CFT] 2.6.0-test7: Fix use-after-free bug in ds.

[Pavel Roskin]

On Wed, 15 Oct 2003, Russell King wrote:

> On Wed, Oct 15, 2003 at 03:55:19PM -0400, Pavel Roskin wrote:
> > On Wed, 15 Oct 2003 linux at brodo.de wrote:
> > > > Working on a patch to combine ds.c with cs.c is too risky, sounds too
> > > > developmental, and too much like a cleanup.
> > >
> > > Of this statement I know of, and that statement is exactly the reason for
> > > my statement yesterday where I said that now is not the time of large
> > > development.
> >
> > Why not?  We are having problems because we have two modules, ds and
> > yenta_socket (or another socket driver) that can be inserted and removed
> > in the random order.
>
> I don't believe we are having problems surrounding the ordering of
> these two modules anymore.  We could actually get around many of
> these problems by backing out some of the bug fixes for these, and
> restoring the "ds refuses to be inserted without socket driver
> present" condition.
>
> The current set of problems is due to the requirement to register
> the class device in the same thread as the initial socket detection
> because of an interaction between PCMCIA and the driver mode - we
> can not add locking between the cs.c functions and the pccard thread;
> doing so deadlocks the driver model.

Sorry, it's hard for me to understand all that, but I think you are
talking about locking between two user contexts (i.e. not irqs or
softirqs).  I think it can be accomplished by mutexes, and the risk of a
deadlock can be excluded if we know that the functions called inside the
critical section won't try to reenter it.  That's provided that we need
the locks.

> Therefore, since we can not guarantee that the class device will
> have registered by the time socket drivers regain control, we can
> not register class device files in their initialisation functions.
> Sysfs requires that the parent objects are registered prior to the
> children being registered.
>
> Note that my first paragraph above reinforces the reason to keep
> cs.c completely separate from ds.c - in fact, we may even have to
> revert back to that requirement to keep 2.6 working sanely.

That's unfortunate because it's an important user-visible step towards
making PCMCIA work just like other subsystems.

Please note that I not suggesting to merge ds.c and cs.c sources.  Keep
them as separate sources if you want.  I'm just saying that if we are
going to load ds code, let's load it together with the rest of the code in
pcmcia_core so that we don't waste time supporting different scenarios if
we don't have to.

I believe that the need to use locking should not be an argument against
doing things right.  Last time I looked at networking code, there was a
lot of locking done to prevent race conditions.  Nobody would want an
additional module on top of all network drivers and a userspace "network
manager" just to avoid locking.

-- 
Regards,
Pavel Roskin