All of lore.kernel.org
 help / color / mirror / Atom feed
From: Denis Kenzior <denkenz@gmail.com>
To: ell@lists.01.org
Subject: Re: [PATCH v2 3/3] main: Safely free watch_data structures
Date: Wed, 16 Mar 2016 18:35:33 -0500	[thread overview]
Message-ID: <56E9EDC5.3030803@gmail.com> (raw)
In-Reply-To: <alpine.OSX.2.20.1603161550420.19388@mjmartin-mac01.wa.intel.com>

[-- Attachment #1: Type: text/plain, Size: 1078 bytes --]

Hi Mat,

 >>> be optimized (use a bitmap to flag which ones to free), but there's
>>> another problem: watch_list is indexed by an fd which was likely closed
>>> by the data->destroy() callback. It's possible for the fd to get re-used
>>> and a new watch to be created on that fd even before the data->destroy
>>> callback returns.
>>
>> But then won't you be calling the watch's callback erroneously anyway?
>> If this is a concern, then all new watches need to be postponed until
>> after the epoll processing has been completed.
>>
>
> No, the stale data is a pointer to watch_data not an fd value. By
> deferring the free we can make sure the event loop is calling something
> valid. The contents of watch_data can be reset however we need to. The
> problem is with pointer values stored in watch_list getting clobbered
> before they get used to free memory.

Now I get it.  I'm good with the proposed solution, but can we avoid 
having dummy callbacks?  Why not simply set the callback to zero (or set 
some flag) and not call it.

Regards,
-Denis

      reply	other threads:[~2016-03-16 23:35 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-16 20:01 [PATCH v2 1/3] build: Add sanitizer options Mat Martineau
2016-03-16 20:01 ` [PATCH v2 2/3] unit: Add race condition test to test-main Mat Martineau
2016-03-16 20:01 ` [PATCH v2 3/3] main: Safely free watch_data structures Mat Martineau
2016-03-16 20:12   ` Denis Kenzior
2016-03-16 22:10     ` Mat Martineau
2016-03-16 22:40       ` Denis Kenzior
2016-03-16 23:24         ` Mat Martineau
2016-03-16 23:35           ` Denis Kenzior [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=56E9EDC5.3030803@gmail.com \
    --to=denkenz@gmail.com \
    --cc=ell@lists.01.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.