tree af54e4816e53a8bd0fb5852236c381ce53fadcf6
parent ed872d09effd54aa8ecb4ceedbc4dbab9592f337
author Frederic Weisbecker <fweisbec@gmail.com> 1260164808 +0100
committer Frederic Weisbecker <fweisbec@gmail.com> 1260165928 +0100

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>