workqueue: consider work function when searching for busy work items

To avoid executing the same work item concurrenlty, workqueue hashes
currently busy workers according to their current work items and looks
up the the table when it wants to execute a new work item.  If there
already is a worker which is executing the new work item, the new item
is queued to the found worker so that it gets executed only after the
current execution finishes.

Unfortunately, a work item may be freed while being executed and thus
recycled for different purposes.  If it gets recycled for a different
work item and queued while the previous execution is still in
progress, workqueue may make the new work item wait for the old one
although the two aren't really related in any way.

In extreme cases, this false dependency may lead to deadlock although
it's extremely unlikely given that there aren't too many self-freeing
work item users and they usually don't wait for other work items.

To alleviate the problem, record the current work function in each
busy worker and match it together with the work item address in
find_worker_executing_work().  While this isn't complete, it ensures
that unrelated work items don't interact with each other and in the
very unlikely case where a twisted wq user triggers it, it's always
onto itself making the culprit easy to spot.

Signed-off-by: Tejun Heo <tj@kernel.org>
Reported-by: Andrey Isakov <andy51@gmx.ru>
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=51701
Cc: stable@vger.kernel.org
Signed-off-by: Blechd0se <alex.christ@hotmail.de>

Conflicts:
	kernel/workqueue.c

Signed-off-by: Blechd0se <alex.christ@hotmail.de>
workqueue: fix find_worker_executing_work() brekage from hashtable conversion

42f8570f43 ("workqueue: use new hashtable implementation") incorrectly
made busy workers hashed by the pointer value of worker instead of
work.  This broke find_worker_executing_work() which in turn broke a
lot of fundamental operations of workqueue - non-reentrancy and
flushing among others.  The flush malfunction triggered warning in
disk event code in Fengguang's automated test.

 write_dev_root_ (3265) used greatest stack depth: 2704 bytes left
 ------------[ cut here ]------------
 WARNING: at /c/kernel-tests/src/stable/block/genhd.c:1574 disk_clear_events+0x\
cf/0x108()
 Hardware name: Bochs
 Modules linked in:
 Pid: 3328, comm: ata_id Not tainted 3.7.0-01930-gbff6343 #1167
 Call Trace:
  [<ffffffff810997c4>] warn_slowpath_common+0x83/0x9c
  [<ffffffff810997f7>] warn_slowpath_null+0x1a/0x1c
  [<ffffffff816aea77>] disk_clear_events+0xcf/0x108
  [<ffffffff811bd8be>] check_disk_change+0x27/0x59
  [<ffffffff822e48e2>] cdrom_open+0x49/0x68b
  [<ffffffff81ab0291>] idecd_open+0x88/0xb7
  [<ffffffff811be58f>] __blkdev_get+0x102/0x3ec
  [<ffffffff811bea08>] blkdev_get+0x18f/0x30f
  [<ffffffff811bebfd>] blkdev_open+0x75/0x80
  [<ffffffff8118f510>] do_dentry_open+0x1ea/0x295
  [<ffffffff8118f5f0>] finish_open+0x35/0x41
  [<ffffffff8119c720>] do_last+0x878/0xa25
  [<ffffffff8119c993>] path_openat+0xc6/0x333
  [<ffffffff8119cf37>] do_filp_open+0x38/0x86
  [<ffffffff81190170>] do_sys_open+0x6c/0xf9
  [<ffffffff8119021e>] sys_open+0x21/0x23
  [<ffffffff82c1c3d9>] system_call_fastpath+0x16/0x1b

Signed-off-by: Tejun Heo <tj@kernel.org>
Reported-by: Fengguang Wu <fengguang.wu@intel.com>
Cc: Sasha Levin <sasha.levin@oracle.com>
Signed-off-by: Blechd0se <alex.christ@hotmail.de>
cpufreq: interactive: remove problematic code.

Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
Signed-off-by: Blechd0se <alex.christ@hotmail.de>
cpufreq: interactive: restructure CPUFREQ_GOV_LIMITS

The cpufreq_interactive_timer gets cancelled and rescheduled
whenever the cpufreq_policy is changed. When the cpufreq policy is
changed at a rate faster than the sampling_rate of the interactive
governor, then the governor misses to change the target frequency
for long duration. The patch removes the need of cancelling the
timers when policy->min is changed.

Signed-off-by: Badhri Jagan Sridharan <Badhri@google.com>
Change-Id: I7862f1c8022a3b98a890e7537f93d02010e86764
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
Signed-off-by: Blechd0se <alex.christ@hotmail.de>
cpufreq: interactive: Optimize sync_freq implementation

Don't let frequency drop below sync_freq if either load or
frequency among other cpus is above a certain threshold,
not necessarily both.

Change-Id: Iada28e08e812498e16d5189b309a7314f88814dd
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
Signed-off-by: Blechd0se <alex.christ@hotmail.de>
cpufreq: interactive: Honor changed minimum frequency

This saves a few cycles in the timer routine.

Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
Signed-off-by: Blechd0se <alex.christ@hotmail.de>
cpufreq: interactive: Use parts of native boost routine

Not all governors are created equal. Set boostpulse_endtime
and floor_freq to smoothen the timer routine.

[franciscofranco] removed boostpulse_endtime from the
original commit because I'm not using it.

Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
Signed-off-by: Blechd0se <alex.christ@hotmail.de>
cpufreq: interactive: Use frequency dependent per cpu timings

This allows in-depth testing of the timer routine.

[franciscofranco] made some structural changes to compile on top
of my governor changes. Functionality was not changed.

[Blechd0se] adapted to use my implementation of sampling_down_factor.

Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
Signed-off-by: Blechd0se <alex.christ@hotmail.de>

Conflicts:
	drivers/cpufreq/cpufreq_interactive.c

Signed-off-by: Blechd0se <alex.christ@hotmail.de>
cpufreq: interactive: Honor boosted state when entering idle

The old logic didn't take the boosted state in account. Just
leave the comment intact because our temporary min is not
the regular policy->min it refers to.

[franciscofranco] not using boostpulse_endtime so change it something
else.

Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
Signed-off-by: Blechd0se <alex.christ@hotmail.de>