All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: Michael Halcrow <mhalcrow@us.ibm.com>
Cc: linux-kernel@vger.kernel.org, prussell@au1.ibm.com,
	shaggy@us.ibm.com, sergeh@us.ibm.com
Subject: Re: [PATCH] eCryptfs: Clean up kthread synchronization
Date: Thu, 22 May 2008 12:41:42 -0700	[thread overview]
Message-ID: <20080522124142.a850ab0e.akpm@linux-foundation.org> (raw)
In-Reply-To: <20080522193155.GB4057@halcrowt61p.ibm.com>

On Thu, 22 May 2008 14:31:55 -0500
Michael Halcrow <mhalcrow@us.ibm.com> wrote:

> > > +void ecryptfs_destroy_kthread(void)
> > > +{
> > > +	struct ecryptfs_open_req tmp_req;
> > > +	struct ecryptfs_open_req *req;
> > > +
> > > +	mutex_lock(&ecryptfs_kthread_ctl.mux);
> > > +	ecryptfs_kthread_ctl.flags |= ECRYPTFS_KTHREAD_ZOMBIE;
> > > +	list_for_each_entry(req, &ecryptfs_kthread_ctl.req_list,
> > > +			    kthread_ctl_list) {
> > > +		mutex_lock(&req->mux);
> > > +		req->flags |= ECRYPTFS_REQ_ZOMBIE;
> > > +		wake_up_process(req->requesting_task);
> > > +		mutex_unlock(&req->mux);
> > > +	}
> > > +	memset(&tmp_req, 0, sizeof(tmp_req));
> > > +	tmp_req.flags = ECRYPTFS_REQ_ZOMBIE;
> > > +	list_add_tail(&tmp_req.kthread_ctl_list,
> > > +		      &ecryptfs_kthread_ctl.req_list);
> > > +	mutex_unlock(&ecryptfs_kthread_ctl.mux);
> > > +	wake_up(&ecryptfs_kthread_ctl.wait);
> > > +}
> > 
> > eh?  We attach a local variable to a global list and then return?
> > That won't last very long.
> 
> Adding this dummy entry to the list is just my own way of getting the
> kthread to wake up and shut down. This actually works, albeit a little
> ugly. The list and its contents get dropped on the floor at this point
> because (ecryptfs_kthread_ctl.flags & ECRYPTFS_KTHREAD_ZOMBIE). The
> only consumer of this list (the kthread) checks for this flag
> immediately after getting the mux, and if it is there, it just
> exits. The only producer on this list (ecryptfs_privileged_open())
> checks for this flag immediately after getting the mux and bows out if
> it is set. In other words, once this flag is set, the list and its
> contents become untouchable by anything other than
> ecryptfs_destroy_kthread().

Unconvinced.

As soon as ecryptfs_destroy_kthread() returns, tmp_req is destroyed. 
But it remains on ecryptfs_kthread_ctl.req_list.

> 	memset(&tmp_req, 0, sizeof(tmp_req));
> 	tmp_req.flags = ECRYPTFS_REQ_ZOMBIE;
> 	list_add_tail(&tmp_req.kthread_ctl_list,
> 		      &ecryptfs_kthread_ctl.req_list);
> 	mutex_unlock(&ecryptfs_kthread_ctl.mux);
> 	wake_up(&ecryptfs_kthread_ctl.wait);

-> it's dead.

> }


  reply	other threads:[~2008-05-22 19:42 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-05-20 21:46 [PATCH] eCryptfs: Privileged kthread for lower file opens Michael Halcrow
2008-05-20 23:16 ` Andrea Righi
2008-05-21 15:14   ` Michael Halcrow
2008-05-21 15:39     ` [PATCH] eCryptfs: Remove useless lock Michael Halcrow
2008-05-21 22:59 ` [PATCH] eCryptfs: Privileged kthread for lower file opens Andrew Morton
2008-05-22 19:31   ` [PATCH] eCryptfs: Clean up kthread synchronization Michael Halcrow
2008-05-22 19:41     ` Andrew Morton [this message]
2008-05-22 21:16       ` Michael Halcrow
2008-05-22 21:44         ` [PATCH] eCryptfs: Use kthread_should_stop() instead of the non-empty list hack Michael Halcrow
2008-05-22 22:03         ` [PATCH] eCryptfs: Clean up kthread synchronization Andrew Morton

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=20080522124142.a850ab0e.akpm@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mhalcrow@us.ibm.com \
    --cc=prussell@au1.ibm.com \
    --cc=sergeh@us.ibm.com \
    --cc=shaggy@us.ibm.com \
    /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.