lkml.org 
[lkml]   [2003]   [Aug]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH 2.6] 2/3 Serio: possible race in handle_events
Date
On Saturday 23 August 2003 02:19 am, Andrew Morton wrote:
> Dmitry Torokhov <dtor_core@ameritech.net> wrote:
> > On Saturday 23 August 2003 02:00 am, Andrew Morton wrote:
> > > Dmitry Torokhov <dtor_core@ameritech.net> wrote:
> > > > +static int is_known_serio(struct serio *serio)
> > > > +{
> > > > + struct serio *s;
> > > > +
> > > > + list_for_each_entry(s, &serio_list, node)
> > > > + if (s == serio)
> > > > + return 1;
> > > > + return 0;
> > > > +}
> > >
> > > Could this just be
> > >
> > > return !list_empty(&serio->node);
> > >
> > > ?
> >
> > The serio could be free()d, I dont think we want to call list_empty with
> > a dangling pointer. Or am I missing something?
>
> Well if we're playing around with a freed pointer then something is
> seriously wrong. Like, someone could have allocated a new one and got the
> same address.
>
> If event->serio can point at freed memory and there's any doubt over it
> then we should be nulling out event->serio to indicate that.

Right now we can't as events are queued in an event list and are processed by
other thread; serio does not know that it's queued and even existence of the
event list is not known outside of serio.c module.

Do you think we should introduce allocate_serio/free_serio pair for dynamically
allocated serios; free_serio would scan event_list and invalidate events that
refer to freed serio?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:48    [W:0.062 / U:0.504 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site