On Wednesday 07 August 2002 10:58 am, anton wilson wrote:
> On Saturday 03 August 2002 09:42 am, Jan Hudec wrote:
> > 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);.
>
> what if i have to do something like this:
>
> driver_read(struct file *file)
> {
> data = (struct mydata *) file->private_data;
>
> if(data){
> spin_lockirq_save(&locktable[data->number], flags)
>
> /* .... */
>
> }
> }
>
> This is still bad because I have to access the data to find out which lock
> to use. Secondly, I don't have any guarantees that data is not null between
> the time I check and the time I access. The only think I can see is to have
> another global lock. . . Not sure what else I can do.
>
> Anton
The way I see other dirvers handle this is to lock the kernel while opening
and releasing.
--
Kernelnewbies: Help each other learn about the Linux kernel.
Archive: http://mail.nl.linux.org/kernelnewbies/
FAQ: http://kernelnewbies.org/faq/
