On Thu, Aug 01, 2002 at 11:15:32AM -0700, Seth Arnold wrote:
> On Thu, Aug 01, 2002 at 01:39:55PM -0400, anton wilson wrote:
> > driver_read(){
> > spin_lockirq_save(&(data->spinlock), flags)
> > /* use data*/
> > spinlock_irq_restore(&(data->spinlock), flags);
> > }
> >
> > driver_disconnect()
> > {
> > if(data)
> > {
> > kfree(data);
> > }
> > }
> > I see a problem here if for instance disconnect freed the data while read was
> > using it. Am I right?
>
> There is probably going to be a problem to use the lock when freeing the
> datastructure. If you move the lock somewhere else (say a hashtable of
> locks) you could then use the lock to protect the kfree(data);.
Where do the functions get the "data" variable?
If it's global, then the lock should be a separate global variable and
you can lock the free (I would just lock setting the variable to NULL
and free later; on the other hand you have to lock before you check it's
not NULL in read).
If it's an argument or is figured out from some argument, then you need
to check how the function can be called with that given argument. The
caller somewhere up the call stack must look it up somehow. So you have
to make sure that it has no way to look it up and call read when
disconnect is called. That means correct garbage-collected. Either
"data" is referenced from only one "handle" (file handle, device
structure, inode ...) - then just make sure disconnect is called from
destructor of this structure and no locking is needed as these
structures are properly ref-counted. Else you need to ref-count the
"data" either using lock and counter or better using atomic_t counter.
then free it if ref count drops to zero. No locking in disconnect is
needed in these cases.
-------------------------------------------------------------------------------
Jan 'Bulb' Hudec <bulb@ucw.cz>
--
Kernelnewbies: Help each other learn about the Linux kernel.
Archive: http://mail.nl.linux.org/kernelnewbies/
FAQ: http://kernelnewbies.org/faq/
