linux-kernel - [PATCH] eCryptfs: Use kthread_should_stop() instead of the non-empty list hack

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20080522214454.GB942@halcrowt61p.austin.ibm.com>
Date:	Thu, 22 May 2008 16:44:54 -0500
From:	Michael Halcrow <mhalcrow@...ibm.com>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	linux-kernel@...r.kernel.org, prussell@....ibm.com,
	shaggy@...ibm.com, sergeh@...ibm.com
Subject: [PATCH] eCryptfs: Use kthread_should_stop() instead of the
	non-empty list hack

On Thu, May 22, 2008 at 04:16:25PM -0500, Michael Halcrow wrote:
> This is what gets woken up:
> 
> ---
>                 wait_event_freezable(
>                         ecryptfs_kthread_ctl.wait,
>                         !list_empty(&ecryptfs_kthread_ctl.req_list));
>                 mutex_lock(&ecryptfs_kthread_ctl.mux);
>                 if (ecryptfs_kthread_ctl.flags &
>                         ECRYPTFS_KTHREAD_ZOMBIE) {
>                         mutex_unlock(&ecryptfs_kthread_ctl.mux);
>                         goto out;
>                 }
> ---
> 
> So the flag causes the kthread to just quit, ignoring the list
> altogether.

The code for shutting down the kthread is ugly. This patch uses the
kthread_stop() call to shut down the kthread instead.

Signed-off-by: Michael Halcrow <mhalcrow@...ibm.com>
---
 fs/ecryptfs/kthread.c |   10 +++-------
 1 files changed, 3 insertions(+), 7 deletions(-)

diff --git a/fs/ecryptfs/kthread.c b/fs/ecryptfs/kthread.c
index 4295296..c440c6b 100644
--- a/fs/ecryptfs/kthread.c
+++ b/fs/ecryptfs/kthread.c
@@ -55,7 +55,8 @@ static int ecryptfs_threadfn(void *ignored)
 
 		wait_event_freezable(
 			ecryptfs_kthread_ctl.wait,
-			!list_empty(&ecryptfs_kthread_ctl.req_list));
+			(!list_empty(&ecryptfs_kthread_ctl.req_list)
+			 || kthread_should_stop()));
 		mutex_lock(&ecryptfs_kthread_ctl.mux);
 		if (ecryptfs_kthread_ctl.flags & ECRYPTFS_KTHREAD_ZOMBIE) {
 			mutex_unlock(&ecryptfs_kthread_ctl.mux);
@@ -103,7 +104,6 @@ int ecryptfs_init_kthread(void)
 
 void ecryptfs_destroy_kthread(void)
 {
-	struct ecryptfs_open_req tmp_req;
 	struct ecryptfs_open_req *req;
 
 	mutex_lock(&ecryptfs_kthread_ctl.mux);
@@ -115,12 +115,8 @@ void ecryptfs_destroy_kthread(void)
 		wake_up(&req->wait);
 		mutex_unlock(&req->mux);
 	}
-	memset(&tmp_req, 0, sizeof(tmp_req));
-	tmp_req.flags = ECRYPTFS_REQ_ZOMBIE;
-	/* Both the list and dummy entry are entirely defunct at this point */
-	list_add_tail(&tmp_req.kthread_ctl_list,
-		      &ecryptfs_kthread_ctl.req_list);
 	mutex_unlock(&ecryptfs_kthread_ctl.mux);
+	kthread_stop(ecryptfs_kthread);
 	wake_up(&ecryptfs_kthread_ctl.wait);
 }
 
-- 
1.5.3.6

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/