hw-breakpoints: Fix task-bound breakpoint slot allocation
authorFrederic Weisbecker <fweisbec@gmail.com>
Mon, 7 Dec 2009 05:46:48 +0000 (06:46 +0100)
committerFrederic Weisbecker <fweisbec@gmail.com>
Mon, 7 Dec 2009 06:05:28 +0000 (07:05 +0100)
commit56053170ea2a2c0dc17420e9b94aa3ca51d80408
treeaf54e4816e53a8bd0fb5852236c381ce53fadcf6
parented872d09effd54aa8ecb4ceedbc4dbab9592f337
hw-breakpoints: Fix task-bound breakpoint slot allocation

Whatever the context nature of a breakpoint, we always perform the
following constraint checks before allocating it a slot:

- Check the number of pinned breakpoint bound the concerned cpus
- Check the max number of task-bound breakpoints that are belonging
  to a task.
- Add both and see if we have a reamining slot for the new breakpoint

This is the right thing to do when we are about to register a cpu-only
bound breakpoint. But not if we are dealing with a task bound
breakpoint. What we want in this case is:

- Check the number of pinned breakpoint bound the concerned cpus
- Check the number of breakpoints that already belong to the task
  in which the breakpoint to register is bound to.
- Add both

This fixes a regression that makes the "firefox -g" command fail to
register breakpoints once we deal with a secondary thread.

Reported-by: Walt <w41ter@gmail.com>
Signed-off-by: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Prasad <prasad@linux.vnet.ibm.com>
kernel/hw_breakpoint.c