Home » Mailing lists » Devel » Remaining straight forward kthread API conversions...
|
|
|
|
| Re: [PATCH] mtd_blkdevs: Convert to use the kthread API [message #18365 is a reply to message #18283] |
Thu, 19 April 2007 19:13   |
ebiederm
Messages: 1354
Registered: February 2006
|
Senior Member |
|
|
Christoph Hellwig <hch@infradead.org> writes:
> On Thu, Apr 19, 2007 at 12:55:28AM -0600, Eric W. Biederman wrote:
>> From: Eric W. Biederman <ebiederm@xmission.com> - unquoted
>>
>> thread_run is used intead of kernel_thread, daemonize, and mucking
>> around blocking signals directly.
>
> Please don't do incomplete transitions like that. We don't really
> want people to use kthread_run, but not the kthread stopping
> mechanisms, because people will simply forget about that bit and
> we'll never get rid of the enormous amount of, erm creativity, in
> handling kernel thread stopping.
>
> This is just the first patch in your series where the thread is mutable,
> but it equally applies to all following patches where this is the case
> aswell.
I don't really care about the creativity. Although it would
be nice if it wasn't there. I deliberately left it in so I would be
certain my patches were correct.
I care about killing the maintenance and forward development roadblocks
that are kernel_thread and daemonize. And the user interface problem
that is handling signals in kernel threads.
Eric
_______________________________________________
Containers mailing list
Containers@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers
|
|
|
|
|
|
|
|
|
|
|
|
| Re: [PATCH] mtd_blkdevs: Convert to use the kthread API [message #18372 is a reply to message #18365] |
Thu, 19 April 2007 22:26 |
akpm
Messages: 224
Registered: March 2007
|
Senior Member |
|
|
On Thu, 19 Apr 2007 13:13:22 -0600
ebiederm@xmission.com (Eric W. Biederman) wrote:
> Christoph Hellwig <hch@infradead.org> writes:
>
> > On Thu, Apr 19, 2007 at 12:55:28AM -0600, Eric W. Biederman wrote:
> >> From: Eric W. Biederman <ebiederm@xmission.com> - unquoted
> >>
> >> thread_run is used intead of kernel_thread, daemonize, and mucking
> >> around blocking signals directly.
> >
> > Please don't do incomplete transitions like that. We don't really
> > want people to use kthread_run, but not the kthread stopping
> > mechanisms, because people will simply forget about that bit and
> > we'll never get rid of the enormous amount of, erm creativity, in
> > handling kernel thread stopping.
> >
> > This is just the first patch in your series where the thread is mutable,
> > but it equally applies to all following patches where this is the case
> > aswell.
>
> I don't really care about the creativity. Although it would
> be nice if it wasn't there. I deliberately left it in so I would be
> certain my patches were correct.
>
> I care about killing the maintenance and forward development roadblocks
> that are kernel_thread and daemonize. And the user interface problem
> that is handling signals in kernel threads.
>
Yes, I think that is a practical position, if not an ideal one.
MTD (to pick one example) does need to be decruftified: remove
r->blkcore_priv->exiting, probably ->blkcore_priv->thread_dead, switch
deregister_mtd_blktrans() to use kthread_stop(). But it's a bit much to
expect Eric to make that conversion, and to suitably test it. All he can
do is to make a best-effort and hope that someone else tests it, which
isn't very reliable.
This partial patch at least gets us some of the way there, and serves as a
gentle reminder to dwmwyouknowwho to finish cleaning this stuff up.
I'd be more concerned about a part-conversion in a subsystem which has no
identifiable maintainer, because in that case the chances are that we'll
just forget about it an the conversion would never be completed.
And of course, these are not simply cleanup patches: we actually need to get
the kernel threads out of the daemonize() and signalling game to complete
the virtualisation work.
_______________________________________________
Containers mailing list
Containers@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Re: [PATCH] bluetooth rfcomm: Convert to kthread API. [message #18378 is a reply to message #18341] |
Thu, 19 April 2007 23:12 |
akpm
Messages: 224
Registered: March 2007
|
Senior Member |
|
|
On Thu, 19 Apr 2007 01:58:54 -0600
"Eric W. Biederman" <ebiederm@xmission.com> wrote:
> From: Eric W. Biederman <ebiederm@xmission.com>
>
> This patch starts krfcommd using kthread_run instead of a combination
> of kernel_thread and daemonize making the code slightly simpler
> and more maintainable.
gargh, the more I look at these things, the more I agree with Christoph.
> Cc: Marcel Holtmann <marcel@holtmann.org>
> Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
> ---
> net/bluetooth/rfcomm/core.c | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/net/bluetooth/rfcomm/core.c b/net/bluetooth/rfcomm/core.c
> index 34f993a..baaad49 100644
> --- a/net/bluetooth/rfcomm/core.c
> +++ b/net/bluetooth/rfcomm/core.c
> @@ -38,6 +38,7 @@
> #include <linux/net.h>
> #include <linux/mutex.h>
> #include <linux/freezer.h>
> +#include <linux/kthread.h>
>
> #include <net/sock.h>
> #include <asm/uaccess.h>
> @@ -1938,7 +1939,6 @@ static int rfcomm_run(void *unused)
>
> atomic_inc(&running);
>
> - daemonize("krfcommd");
> set_user_nice(current, -10);
>
> BT_DBG("");
> @@ -2058,7 +2058,7 @@ static int __init rfcomm_init(void)
>
> hci_register_cb(&rfcomm_cb);
>
> - kernel_thread(rfcomm_run, NULL, CLONE_KERNEL);
> + kthread_run(rfcomm_run, NULL, "krfcommd");
>
> if (class_create_file(bt_class, &class_attr_rfcomm_dlc) < 0)
> BT_ERR("Failed to create RFCOMM info file");
We should remove the file-wide `terminate' and `running' and switch the
thread management over to kthread_run(), kthread_stop() and
kthread_should_stop().
btw, this:
static void rfcomm_worker(void)
{
BT_DBG("");
while (!atomic_read(&terminate)) {
try_to_freeze();
if (!test_bit(RFCOMM_SCHED_WAKEUP, &rfcomm_event)) {
/* No pending events. Let's sleep.
* Incoming connections and data will wake us up. */
set_current_state(TASK_INTERRUPTIBLE);
schedule();
}
/* Process stuff */
clear_bit(RFCOMM_SCHED_WAKEUP, &rfcomm_event);
rfcomm_process_sessions();
}
set_current_state(TASK_RUNNING);
return;
}
appears to have the classic sleep/wakeup bug: if the wakeup happens after
we tested RFCOMM_SCHED_WAKEUP we will miss it.
Easy fix:
From: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
net/bluetooth/rfcomm/core.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff -puN net/bluetooth/rfcomm/core.c~rfcomm_worker-fix-wakeup-race net/bluetooth/rfcomm/core.c
--- a/net/bluetooth/rfcomm/core.c~rfcomm_worker-fix-wakeup-race
+++ a/net/bluetooth/rfcomm/core.c
@@ -1855,18 +1855,18 @@ static void rfcomm_worker(void)
while (!atomic_read(&terminate)) {
try_to_freeze();
+ set_current_state(TASK_INTERRUPTIBLE);
if (!test_bit(RFCOMM_SCHED_WAKEUP, &rfcomm_event)) {
/* No pending events. Let's sleep.
* Incoming connections and data will wake us up. */
- set_current_state(TASK_INTERRUPTIBLE);
schedule();
}
+ set_current_state(TASK_RUNNING);
/* Process stuff */
clear_bit(RFCOMM_SCHED_WAKEUP, &rfcomm_event);
rfcomm_process_sessions();
}
- set_current_state(TASK_RUNNING);
return;
}
_
(I think it's safer and saner to always run rfcomm_process_sessions() while
in state TASK_RUNNING, not maybe-in-state-TASK_INTERRUPTIBLE)
_______________________________________________
Containers mailing list
Containers@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Re: [PATCH] sas_scsi_host: Convert to use the kthread API [message #18388 is a reply to message #18325] |
Fri, 20 April 2007 00:37 |
akpm
Messages: 224
Registered: March 2007
|
Senior Member |
|
|
On Thu, 19 Apr 2007 01:58:38 -0600
"Eric W. Biederman" <ebiederm@xmission.com> wrote:
> From: Eric W. Biederman <ebiederm@xmission.com>
>
> This patch modifies the sas scsi host thread startup
> to use kthread_run not kernel_thread and deamonize.
> kthread_run is slightly simpler and more maintainable.
>
Again, I'll rename this to "partially convert...". This driver should be
using kthread_should_stop() and kthread_stop() rather than the
apparently-unnecessary ->queue_thread_kill thing.
This driver was merged two and a half years after the kthread API was
available. Our coding-vs-reviewing effort is out of balance.
> ---
> drivers/scsi/libsas/sas_scsi_host.c | 11 ++++++-----
> 1 files changed, 6 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/scsi/libsas/sas_scsi_host.c b/drivers/scsi/libsas/sas_scsi_host.c
> index 46ba3a7..7a38ac5 100644
> --- a/drivers/scsi/libsas/sas_scsi_host.c
> +++ b/drivers/scsi/libsas/sas_scsi_host.c
> @@ -40,6 +40,7 @@
> #include <linux/blkdev.h>
> #include <linux/scatterlist.h>
> #include <linux/freezer.h>
> +#include <linux/kthread.h>
>
> /* ---------- SCSI Host glue ---------- */
>
> @@ -870,7 +871,6 @@ static int sas_queue_thread(void *_sas_ha)
> struct sas_ha_struct *sas_ha = _sas_ha;
> struct scsi_core *core = &sas_ha->core;
>
> - daemonize("sas_queue_%d", core->shost->host_no);
> current->flags |= PF_NOFREEZE;
>
> complete(&queue_th_comp);
> @@ -891,19 +891,20 @@ static int sas_queue_thread(void *_sas_ha)
>
> int sas_init_queue(struct sas_ha_struct *sas_ha)
> {
> - int res;
> struct scsi_core *core = &sas_ha->core;
> + struct task_struct *task;
>
> spin_lock_init(&core->task_queue_lock);
> core->task_queue_size = 0;
> INIT_LIST_HEAD(&core->task_queue);
> init_MUTEX_LOCKED(&core->queue_thread_sema);
>
> - res = kernel_thread(sas_queue_thread, sas_ha, 0);
> - if (res >= 0)
> + task = kthread_run(sas_queue_thread, sas_ha,
> + "sas_queue_%d", core->shost->host_no);
> + if (!IS_ERR(task))
> wait_for_completion(&queue_th_comp);
>
> - return res < 0 ? res : 0;
> + return IS_ERR(task) ? PTR_ERR(task) : 0;
Does that wait_for_completion(&queue_th_comp) actually do anything useful?
If so, what is serialising access to the single queue_th_comp?
_______________________________________________
Containers mailing list
Containers@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers
|
|
|
|
| Re: [PATCH] mtd_blkdevs: Convert to use the kthread API [message #18389 is a reply to message #18283] |
Thu, 19 April 2007 16:47 |
Christoph Hellwig
Messages: 59
Registered: April 2006
|
Member |
|
|
On Thu, Apr 19, 2007 at 12:55:28AM -0600, Eric W. Biederman wrote:
> From: Eric W. Biederman <ebiederm@xmission.com> - unquoted
>
> thread_run is used intead of kernel_thread, daemonize, and mucking
> around blocking signals directly.
Please don't do incomplete transitions like that. We don't really
want people to use kthread_run, but not the kthread stopping
mechanisms, because people will simply forget about that bit and
we'll never get rid of the enormous amount of, erm creativity, in
handling kernel thread stopping.
This is just the first patch in your series where the thread is mutable,
but it equally applies to all following patches where this is the case
aswell.
_______________________________________________
Containers mailing list
Containers@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers
|
|
|
|
|
|
| Re: [PATCH] nfs lockd reclaimer: Convert to kthread API [message #18391 is a reply to message #18370] |
Thu, 19 April 2007 22:04 |
Trond Myklebust
Messages: 24
Registered: July 2006
|
Junior Member |
|
|
On Thu, 2007-04-19 at 14:40 -0700, Andrew Morton wrote:
> Using signals to communicate with kernel threads is fairly unpleasant, IMO.
> We have much simpler, faster and more idiomatic ways of communicating
> between threads in-kernel and there are better ways in which userspace can
> communicate with the kernel - system calls, for example...
>
> So I think generally any move which gets us away from using signals in
> kernel threads is moving in a good direction.
I have yet to see a proposal which did. Eric's patch was eliminating
signals in kernel threads that used them without proposing any
replacement mechanism or showing that he had plans to do so. That is a
good reason for a veto.
> > > With pid namespaces all kernel threads will disappear so how do
> > > we cope with the problem when the sysadmin can not see the kernel
> > > threads?
> >
> > Then you have a usability problem. How does the sysadmin reboot the
> > system if there is no way to shut down the processes that are hanging on
> > an unresponsive filesystem?
>
> Where's the hang? A user process is stuck on h_rwsem?
>
> If so, would it be appropriate to convert the user process to use
> down_foo_interruptible(), so that the operator can just kill the user
> process as expected, rather than having to futz around killing kernel
> threads?
If an NFS server reboots, then the locks held by user processes on the
client need to be re-established by when it comes up again. Otherwise,
the processes that thought they were holding locks will suddenly fail.
This recovery job is currently the done by a kernel thread.
The question is then what to do if the server crashes again while the
kernel thread is re-establishing the locks. Particularly if it never
comes back again.
Currently, the administrator can intervene by killing anything that has
open files on that volume and kill the recovery kernel thread.
You'll also note that lockd_down(), nfsd_down() etc all use signals to
inform lockd(), nfsd() etc that they should be shutting down. Since the
reclaimer thread is started by the lockd() thread using CLONE_SIGHAND,
this means that we also automatically kill any lingering recovery
threads whenever we shutdown lockd().
These mechanisms need to be replaced _before_ we start shooting down
sigallow() etc in the kernel.
Trond
_______________________________________________
Containers mailing list
Containers@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers
|
|
|
|
|
|
|
|
|
|
| Re: [PATCH] dvb_en_50221: Convert to kthread API [message #18395 is a reply to message #18373] |
Fri, 20 April 2007 06:37 |
Christoph Hellwig
Messages: 59
Registered: April 2006
|
Member |
|
|
On Thu, Apr 19, 2007 at 03:34:13PM -0700, Andrew Morton wrote:
> On Thu, 19 Apr 2007 01:59:04 -0600
> "Eric W. Biederman" <ebiederm@xmission.com> wrote:
>
> > This patch is a minimal transformation to use the kthread API
> > doing it's best to preserve the existing logic.
> >
> > Instead of starting kdvb-ca by calling kernel_thread,
> > daemonize and sigfillset we kthread_run is used.
> >
> > Instead of tracking the pid of the running thread we instead
> > simply keep a flag to indicate that the current thread is
> > running, as that is all the pid is really used for.
> >
> > And finally the kill_proc sending signal 0 to the kernel thread to
> > ensure it is alive before we wait for it to shutdown is removed.
> > The kthread API does not provide the pid so we don't have that
> > information readily available and the test is just silly. If there
> > is no shutdown race the test is a useless confirmation of that the
> > thread is running. If there is a race the test doesn't fix it and
> > we should fix the race properly.
>
> urgh, yes, this is just sad. We should convert this driver fully to
> the kthread API - it will end up much better.
>
> I'll queue this up as a -mm-only thing as a gentle reminder that
> we should do it properly.
Here's an attempted update to the full kthread API + wake_up_process:
Index: linux-2.6/drivers/media/dvb/dvb-core/dvb_ca_en50221.c
===================================================================
--- linux-2.6.orig/drivers/media/dvb/dvb-core/dvb_ca_en50221.c 2007-04-20 07:25:07.000000000 +0200
+++ linux-2.6/drivers/media/dvb/dvb-core/dvb_ca_en50221.c 2007-04-20 07:35:54.000000000 +0200
@@ -37,6 +37,7 @@
#include <linux/delay.h>
#include <linux/spinlock.h>
#include <linux/sched.h>
+#include <linux/kthread.h>
#include "dvb_ca_en50221.h"
#include "dvb_ringbuffer.h"
@@ -140,13 +141,7 @@ struct dvb_ca_private {
wait_queue_head_t wait_queue;
/* PID of the monitoring thread */
- pid_t thread_pid;
-
- /* Wait queue used when shutting thread down */
- wait_queue_head_t thread_queue;
-
- /* Flag indicating when thread should exit */
- unsigned int exit:1;
+ struct task_struct *thread;
/* Flag indicating if the CA device is open */
unsigned int open:1;
@@ -902,28 +897,10 @@ static void dvb_ca_en50221_thread_wakeup
ca->wakeup = 1;
mb();
- wake_up_interruptible(&ca->thread_queue);
+ wake_up_process(ca->thread);
}
/**
- * Used by the CA thread to determine if an early wakeup is necessary
- *
- * @param ca CA instance.
- */
-static int dvb_ca_en50221_thread_should_wakeup(struct dvb_ca_private *ca)
-{
- if (ca->wakeup) {
- ca->wakeup = 0;
- return 1;
- }
- if (ca->exit)
- return 1;
-
- return 0;
-}
-
-
-/**
* Update the delay used by the thread.
*
* @param ca CA instance.
@@ -982,7 +959,6 @@ static void dvb_ca_en50221_thread_update
static int dvb_ca_en50221_thread(void *data)
{
struct dvb_ca_private *ca = data;
- char name[15];
int slot;
int flags;
int status;
@@ -991,28 +967,17 @@ static int dvb_ca_en50221_thread(void *d
dprintk("%s\n", __FUNCTION__);
- /* setup kernel thread */
- snprintf(name, sizeof(name), "kdvb-ca-%i:%i", ca->dvbdev->adapter->num, ca->dvbdev->id);
-
- lock_kernel();
- daemonize(name);
- sigfillset(¤t->blocked);
- unlock_kernel();
-
/* choose the correct initial delay */
dvb_ca_en50221_thread_update_delay(ca);
/* main loop */
- while (!ca->exit) {
+ while (!kthread_should_stop()) {
/* sleep for a bit */
- if (!ca->wakeup) {
- flags = wait_event_interruptible_timeout(ca->thread_queue,
- dvb_ca_en50221_thread_should_wakeup(ca),
- ca->delay);
- if ((flags == -ERESTARTSYS) || ca->exit) {
- /* got signal or quitting */
- break;
- }
+ while (!ca->wakeup) {
+ set_current_state(TASK_INTERRUPTIBLE);
+ schedule_timeout(ca->delay);
+ if (kthread_should_stop())
+ return 0;
}
ca->wakeup = 0;
@@ -1181,10 +1146,6 @@ static int dvb_ca_en50221_thread(void *d
}
}
- /* completed */
- ca->thread_pid = 0;
- mb();
- wake_up_interruptible(&ca->thread_queue);
return 0;
}
@@ -1682,9 +1643,6 @@ int dvb_ca_en50221_init(struct dvb_adapt
goto error;
}
init_waitqueue_head(&ca->wait_queue);
- ca->thread_pid = 0;
- init_waitqueue_head(&ca->thread_queue);
- ca->exit = 0;
ca->open = 0;
ca->wakeup = 0;
ca->next_read_slot = 0;
@@ -1710,14 +1668,14 @@ int dvb_ca_en50221_init(struct dvb_adapt
mb();
/* create a kthread for monitoring this CA device */
-
- ret = kernel_thread(dvb_ca_en50221_thread, ca, 0);
-
- if (ret < 0) {
- printk("dvb_ca_init: failed to start kernel_thread (%d)\n", ret);
+ ca->thread = kthread_run(dvb_ca_en50221_thread, ca, "kdvb-ca-%i:%i",
+ ca->dvbdev->adapter->num, ca->dvbdev->id);
+ if (IS_ERR(ca->thread)) {
+ ret = PTR_ERR(ca->thread);
+ printk("dvb_ca_init: failed to start kernel_thread (%d)\n",
+ ret);
goto error;
}
- ca->thread_pid = ret;
return 0;
error:
@@ -1748,17 +1706,7 @@ void dvb_ca_en50221_release(struct dvb_c
dprintk("%s\n", __FUNCTION__);
/* shutdown the thread if there was one */
- if (ca->thread_pid) {
- if (kill_proc(ca->thread_pid, 0, 1) == -ESRCH) {
- printk("dvb_ca_release adapter %d: thread PID %d already died\n",
- ca->dvbdev->adapter->num, ca->thread_pid);
- } else {
- ca->exit = 1;
- mb();
- dvb_ca_en50221_thread_wakeup(ca);
- wait_event_interruptible(ca->thread_queue, ca->thread_pid == 0);
- }
- }
+ kthread_stop(ca->thread);
for (i = 0; i < ca->slot_count; i++) {
dvb_ca_en50221_slot_shutdown(ca, i);
_______________________________________________
Containers mailing list
Containers@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Re: [PATCH] saa7134-tvaudio: Convert to kthread API. [message #18416 is a reply to message #18308] |
Fri, 20 April 2007 12:48 |
Cedric Le Goater
Messages: 443
Registered: February 2006
|
Senior Member |
|
|
Eric W. Biederman wrote:
> From: Eric W. Biederman <ebiederm@xmission.com> - unquoted
>
> It is my goal to replace all kernel code that handles signals
> from user space, calls kernel_thread or calls daemonize. All
> of which the kthread_api makes unncessary. Handling signals
> from user space is a maintenance problem becuase using a
> kernel thread is an implementation detail and if user space
> cares it does not allow us to change the implementation. Calling
> daemonize is a problem because it has to undo a continually changing
> set of state generated by user space, requiring the implemetation
> to change continually. kernel_thread is a problem because it
> returns a pid_t value. Numeric pids are inherently racy and
> in the presence of a pid namespace they are no longer global
> making them useless for general use in the kernel.
>
> So this patch renames the pid member of struct saa7134_thread
> started and changes it's type from pid_t to int. All it
> has ever been used for is to detect if the kernel thread
> is has been started so this works.
>
> allow_signal(SIGTERM) and the calls to signal_pending have
> been removed they are needed for the driver to operation.
>
> The startup of tvaudio_thread and tvaudio_thread_dep have
> been modified to use kthread_run instead of a combination
> of kernel_thread and daemonize.
>
> The result is code that is slightly simpler and more
> maintainable.
Here's a refreshed attempt using kthread_should_stop().
Unfortunately, not tested bc we don't have the hardware.
cheers,
C.
From: Sukadev Bhattiprolu <sukadev@us.ibm.com>
Replace kernel_thread() with kthread_run() since kernel_thread()
is deprecated in drivers/modules. Also remove signalling code
as it is not needed in the driver.
Signed-off-by: Sukadev Bhattiprolu <sukadev@us.ibm.com>
Signed-off-by: Cedric Le Goater <clg@fr.ibm.com>
Cc: Mauro Carvalho Chehab <mchehab@infradead.org>
Cc: Containers@lists.osdl.org
Cc: video4linux-list@redhat.com
Cc: v4l-dvb-maintainer@linuxtv.org
---
drivers/media/video/saa7134/saa7134-tvaudio.c | 45 +++++++++++++-------------
drivers/media/video/saa7134/saa7134.h | 4 --
2 files changed, 24 insertions(+), 25 deletions(-)
Index: 2.6.21-rc6-mm1/drivers/media/video/saa7134/saa7134.h
===================================================================
--- 2.6.21-rc6-mm1.orig/drivers/media/video/saa7134/saa7134.h
+++ 2.6.21-rc6-mm1/drivers/media/video/saa7134/saa7134.h
@@ -324,10 +324,8 @@ struct saa7134_pgtable {
/* tvaudio thread status */
struct saa7134_thread {
- pid_t pid;
- struct completion exit;
+ struct task_struct * task;
wait_queue_head_t wq;
- unsigned int shutdown;
unsigned int scan1;
unsigned int scan2;
unsigned int mode;
Index: 2.6.21-rc6-mm1/drivers/media/video/saa7134/saa7134-tvaudio.c
===================================================================
--- 2.6.21-rc6-mm1.orig/drivers/media/video/saa7134/saa7134-tvaudio.c
+++ 2.6.21-rc6-mm1/drivers/media/video/saa7134/saa7134-tvaudio.c
@@ -27,6 +27,7 @@
#include <linux/kernel.h>
#include <linux/slab.h>
#include <linux/delay.h>
+#include <linux/kthread.h>
#include <asm/div64.h>
#include "saa7134-reg.h"
@@ -344,16 +345,22 @@ static int tvaudio_sleep(struct saa7134_
DECLARE_WAITQUEUE(wait, current);
add_wait_queue(&dev->thread.wq, &wait);
- if (dev->thread.scan1 == dev->thread.scan2 && !dev->thread.shutdown) {
+
+ set_current_state(TASK_INTERRUPTIBLE);
+
+ if (dev->thread.scan1 == dev->thread.scan2 && !kthread_should_stop()) {
if (timeout < 0) {
- set_current_state(TASK_INTERRUPTIBLE);
schedule();
} else {
schedule_timeout_interruptible
(msecs_to_jiffies(timeout));
}
}
+
+ set_current_state(TASK_RUNNING);
+
remove_wait_queue(&dev->thread.wq, &wait);
+
return dev->thread.scan1 != dev->thread.scan2;
}
@@ -505,11 +512,9 @@ static int tvaudio_thread(void *data)
unsigned int i, audio, nscan;
int max1,max2,carrier,rx,mode,lastmode,default_carrier;
- daemonize("%s", dev->name);
- allow_signal(SIGTERM);
for (;;) {
tvaudio_sleep(dev,-1);
- if (dev->thread.shutdown || signal_pending(current))
+ if (kthread_should_stop())
goto done;
restart:
@@ -618,7 +623,7 @@ static int tvaudio_thread(void *data)
for (;;) {
if (tvaudio_sleep(dev,5000))
goto restart;
- if (dev->thread.shutdown || signal_pending(current))
+ if (kthread_should_stop())
break;
if (UNSET == dev->thread.mode) {
rx = tvaudio_getstereo(dev,&tvaudio[i]);
@@ -634,7 +639,6 @@ static int tvaudio_thread(void *data)
}
done:
- complete_and_exit(&dev->thread.exit, 0);
return 0;
}
@@ -782,9 +786,6 @@ static int tvaudio_thread_ddep(void *dat
struct saa7134_dev *dev = data;
u32 value, norms, clock;
- daemonize("%s", dev->name);
- allow_signal(SIGTERM);
-
clock = saa7134_boards[dev->board].audio_clock;
if (UNSET != audio_clock_override)
clock = audio_clock_override;
@@ -796,7 +797,7 @@ static int tvaudio_thread_ddep(void *dat
for (;;) {
tvaudio_sleep(dev,-1);
- if (dev->thread.shutdown || signal_pending(current))
+ if (kthread_should_stop())
goto done;
restart:
@@ -876,7 +877,6 @@ static int tvaudio_thread_ddep(void *dat
}
done:
- complete_and_exit(&dev->thread.exit, 0);
return 0;
}
@@ -986,15 +986,16 @@ int saa7134_tvaudio_init2(struct saa7134
break;
}
- dev->thread.pid = -1;
+ dev->thread.task = NULL;
if (my_thread) {
/* start tvaudio thread */
init_waitqueue_head(&dev->thread.wq);
- init_completion(&dev->thread.exit);
- dev->thread.pid = kernel_thread(my_thread,dev,0);
- if (dev->thread.pid < 0)
- printk(KERN_WARNING "%s: kernel_thread() failed\n",
+ dev->thread.task = kthread_run(my_thread, dev, dev->name);
+ if (IS_ERR(dev->thread.task)) {
+ printk(KERN_WARNING "%s: failed to create kthread\n",
dev->name);
+ dev->thread.task = NULL;
+ }
saa7134_tvaudio_do_scan(dev);
}
@@ -1005,10 +1006,10 @@ int saa7134_tvaudio_init2(struct saa7134
int saa7134_tvaudio_fini(struct saa7134_dev *dev)
{
/* shutdown tvaudio thread */
- if (dev->thread.pid >= 0) {
- dev->thread.shutdown = 1;
- wake_up_interruptible(&dev->thread.wq);
- wait_for_completion(&dev->thread.exit);
+ if (dev->thread.task) {
+ /* kthread_stop() wakes up the thread */
+ kthread_stop(dev->thread.task);
+ dev->thread.task = NULL;
}
saa_andorb(SAA7134_ANALOG_IO_SELECT, 0x07, 0x00); /* LINE1 */
return 0;
@@ -1020,7 +1021,7 @@ int saa7134_tvaudio_do_scan(struct saa71
dprintk("sound IF not in use, skipping scan\n");
dev->automute = 0;
saa7134_tvaudio_setmute(dev);
- } else if (dev->thread.pid >= 0) {
+ } else if (dev->thread.task) {
dev->thread.mode = UNSET;
dev->thread.scan2++;
wake_up_interruptible(&dev->thread.wq);
_______________________________________________
Containers mailing list
Containers@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers
|
|
|
|
|
|
|
|
Goto Forum:
Current Time: Mon Nov 18 22:18:42 GMT 2024
Total time taken to generate the page: 0.03186 seconds
|
OpenVZ Forum
Members
Search
Help
Register
Login
Home
