linux-kernel - Re: [PATCH 2/4] leds-lp5523: set the brightness to 0 forcely on removing the driver

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <CAK5ve-J0LsUM1vJL_su1bg+gRoz9g0i1Jzmt5mgSLgyhftoqJA@mail.gmail.com>
Date:	Wed, 22 Aug 2012 15:22:10 +0800
From:	Bryan Wu <bryan.wu@...onical.com>
To:	"Kim, Milo" <Milo.Kim@...com>
Cc:	Tejun Heo <tj@...nel.org>, Richard Purdie <rpurdie@...ys.net>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-leds@...r.kernel.org" <linux-leds@...r.kernel.org>
Subject: Re: [PATCH 2/4] leds-lp5523: set the brightness to 0 forcely on
 removing the driver

On Wed, Aug 22, 2012 at 1:46 PM, Kim, Milo <Milo.Kim@...com> wrote:
>> Hmmm, I think we still should use cancel_work() here based on your
>> idea. Please find the patch from Tejun and add him to this loop
>> [PATCH 4/6] workqueue: deprecate flush[_delayed]_work_sync()
>> ---
>> Before this patchset,
>>
>>  flush_work()
>>
>>         flush the last queued instance of the work item.  If it got
>>         queued on multple CPUs, it only considers the last queued
>>         instance.  The work item could still be executing on other
>>         CPUs and the flush might become noop if there are competing
>>         queueing operation on another CPU.
>>
>>  flush_work_sync()
>>
>>         flush_work() + wait for executing instances on all CPUs.  The
>>         flush_work() part may still become noop if there's competing
>>         queueing operation.
>>
>>  cancel_work()
>>
>>         Dequeue the work item if it's pending.  Doesn't care about
>>         whether it's executing or not.
>>
>>  cancel_work_sync()
>>
>>         cancel_work() + flush_work_sync().
>>
>>
>> After this patchset,
>>
>>  flush_work()
>>
>>         flush the work item.  Any queueing happened previously is
>>         guaranteed to have finished execution on return.  If no
>>         further queueing happened after flush started, the work item
>>         is guaranteed to be idle on return.
>>
>>  cancel_work()
>>
>>         Same as before.
>>
>>  cancel_work_sync()
>>
>>         cancel_work() followed by flush_work().  The same semantics as
>>         del_timer_sync().
>> ---
>>
>> cancel_work_sync() won't execute the work item at all just cancel
>> them, but flush will execute them and return.
>>
>
> Thanks a lot for the updates!
>
> Then, I think flush_work() should be used for executing remaining brightness work
> rather than cancel_work_sync().
>

Yeah, I agree here. I made a mistake about your original patch's description.

-Bryan
--
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/