From: Dmitry Torokhov <[EMAIL PROTECTED]>
Date: Tue, 10 Apr 2007 02:29:31 -0400
> On Tuesday 10 April 2007 01:58, Dmitry Torokhov wrote:
> > Hi,
> >
> > This is a modified version of rfkill patch that provides infrastructure
> > for controlling state of RF transmitters found on various cards.
>
> Well, Andrew found bunch of issues with the patch so here is an
> updated version...
Patch applied, although one part of the locking is slightly
suspect:
> +static void rfkill_task_handler(struct work_struct *work)
> +{
> + struct rfkill_task *task = container_of(work, struct rfkill_task, work);
> + enum rfkill_state state;
> +
> + mutex_lock(&task->mutex);
> +
> + spin_lock_irq(&task->lock);
> + state = task->desired_state;
> + spin_unlock_irq(&task->lock);
> +
> + if (state != task->current_state) {
> + rfkill_switch_all(task->type, state);
> + task->current_state = state;
> + }
> +
> + mutex_unlock(&task->mutex);
> +}
I applied this, but...
That lock around the read doesn't make any sense, reads
are atomic on all SMP processors. You're not going to
see a partial word-update if you take away that lock so
it isn't doing anything.
If locking is really needed here, it probably need to protect
the whole read-modify-write operation transferring the
desired_state to the current_state.
In another code block, this ->desired_state thing is
treated like a boolean instead of the enumeration that
it is supposed to be:
+static void rfkill_schedule_toggle(struct rfkill_task *task)
+{
+ unsigned int flags;
+
+ spin_lock_irqsave(&task->lock, flags);
+
+ if (time_after(jiffies, task->last + msecs_to_jiffies(200))) {
+ task->desired_state = !task->desired_state;
+ task->last = jiffies;
+ schedule_work(&task->work);
+ }
+
+ spin_unlock_irqrestore(&task->lock, flags);
+}
What is going on here?
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
