While changing the stack_id to be signed, I accidentally screwed the
check for an invalid stack_id. Some reason I didn't catch this even in
my tests. This patch fixes the issue (thanks Erick Reyes for reporting).

By the way, one weirdness I see is invalid stack_id is printed as -17
when I print it in python.

When I do bpf_trace_printk, I get these ids:
root@localhost:/# cat /d/tracing/trace_pipe
          <idle>-0     [003] .n.3   942.100225: : sid: 15
          <idle>-0     [002] .n.3   943.140393: : sid: 15
     kworker/3:3-1798  [003] ...3   943.422768: : sid: 6
     kworker/3:3-1798  [003] ...3   943.423419: : sid: 6
     kworker/3:3-1798  [003] ...3   943.423967: : sid: 6
   BootAnimation-650   [003] .n.3   949.840268: : sid: 8
          <idle>-0     [003] .n.3   952.360226: : sid: 15
          <idle>-0     [000] ...3   953.100116: : sid: 11
    Binder:571_3-1469  [000] .n.3   953.513328: : sid: 3
          <idle>-0     [003] .n.3   954.760215: : sid: 15
    Binder:571_3-1469  [000] ...3   955.460271: : sid: 18446744073709551599
          <idle>-0     [003] .n.3   957.420275: : sid: 15
 irq/296-cs35l36-662   [000] ...3   958.422890: : sid: 5
     kworker/1:3-1729  [001] ...3   960.485247: : sid: 18446744073709551599
     kworker/1:3-1729  [001] ...3   960.485888: : sid: 18446744073709551599

As an equivalent, when I do a print of the stack_id from the python
code, I get:
stack_id 15
stack_id 15
stack_id 6
stack_id 6
stack_id 6
stack_id 8
stack_id 15
stack_id 11
stack_id 3
stack_id 15
stack_id -17
stack_id 15
stack_id 5
stack_id -17
stack_id -17

This isn't a big deal since the valid stack_ids match, but still
1.8446744e+19 is -1 in 64-bit speak. So I do find that odd.
Reported-by: Erick Reyes <erickreyes@google.com>
Signed-off-by: Joel Fernandes (Google) <joel@joelfernandes.org>