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

[linux at brodo.de]

[Inadvertedly didn't CC in reply before]

> > I'd prefer an -partial- different approach: let's remove struct
> > pcmcia_bus_socket at all, and put the necessary information into
struct
> > pcmcia_socket. This means that most of the code which is currently in
ds.c
> > needs to move into cs.c, or maybe a new pcmcia.c. However, we'll have
only
> > one reference counting for pcmcia devices; the "border" between ds.c
and
> > cs.c and between structs pcmcia_socket and pcmcia_bus_socket is
somewhat 
> > fuzzy. IMO it would be better to separate 
> > 	a) core functions needed for socket management by both 16- and
> > 	   32-bit cards,
> > 	b) 32-bit card support, and
> > 	c) 16-bit card support.
> > 
> > If you want me to, I can write a patch within a week.
> 
> Err, no.
> 
> Firstly, you seem to have completely changed direction on this.  Not 6
> months ago, you wanted to separate out the cardbus support from the
> PCMCIA stuff.  Now you seem to be wanting to put everything into cs.c.

Please re-read my suggestion. I _still_ want to separate 16-bit and 32-bit
support from the core. The problem is that the current ds/cs separation is
_not_ a 16-bit / {32-bit and core} separation, but a parts-of-16-bit /
{16-bit, 32-bit and core} separation. So I have not changed the direction,
but have showed a path which might make reaching the aim easier.

> Secondly, I'm completely happy with the separation of ds.c from cs.c -
> it makes sense as is.  If anything, we should be moving code from cs.c
> to ds.c and data from struct pcmcia_socket to struct pcmcia_bus_socket
> which is specific to 16-bit cards.

With this I still agree - on the long term. It might be _easier_, though,
to merge ds.c and cs.c first and to separate this later -- along a clear
line between 16-bit support, 32-bit support and core functions.
 
> Thirdly, and this is the killer, Linus said to the people who committed
> code for 2.6.0-test7:
> ... 
> 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 exatly the reason for
my statement yesterday where I said that now is not the time of large
development.


    Dominik