lkml.org 
[lkml]   [2015]   [Jul]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 6/6] Fix unsafe fw_event_list usage
On Friday 07/03 at 09:02 -0700, Christoph Hellwig wrote:
> On Mon, Jun 08, 2015 at 08:50:56PM -0700, Calvin Owens wrote:
> > Since the fw_event deletes itself from the list, cleanup_queue() can
> > walk onto garbage pointers or walk off into freed memory.
> >
> > This refactors the code in _scsih_fw_event_cleanup_queue() to not
> > iterate over the fw_event_list without a lock.
>
> I think this really should be folded into the previous one, with the
> fixes in this one the other refcounting change don't make a whole lot
> sense.
>
> > +static struct fw_event_work *dequeue_next_fw_event(struct MPT2SAS_ADAPTER *ioc)
> > +{
> > + unsigned long flags;
> > + struct fw_event_work *fw_event = NULL;
> > +
> > + spin_lock_irqsave(&ioc->fw_event_lock, flags);
> > + if (!list_empty(&ioc->fw_event_list)) {
> > + fw_event = list_first_entry(&ioc->fw_event_list,
> > + struct fw_event_work, list);
> > + list_del_init(&fw_event->list);
> > + fw_event_work_get(fw_event);
> > + }
> > + spin_unlock_irqrestore(&ioc->fw_event_lock, flags);
> > +
> > + return fw_event;
>
> Shouldn't we have a reference for each item on the list that gets
> transfer to whomever removes it from the list?

Yes, this was a bit weird the way I did it. I redid this in v2, hopefully
it's clearer.

> Additionally _firmware_event_work should call dequeue_next_fw_event
> first in the function so that item is off the list before we process
> it, and can then just drop the reference once it's done.

That works: cleanup_queue() won't wait on some already-running events, but
destroy_workqueue() drains the wq, so we won't run ahead and free things
from under the fw_event when unwinding.


\
 
 \ /
  Last update: 2015-07-12 06:41    [W:0.069 / U:0.660 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site