{"push_id":2658813439,"size":2,"distinct_size":2,"ref":"refs/heads/feature/footer-header","head":"9aab22ecd81160858e3dcd73db21b74e0473e403","before":"627b6d3a67d3ee536eb947d9ac6b927b00e979cd","commits":[{"sha":"d601984f5601ebb2567e9920e72dde7e09717c66","author":{"name":"Joel","email":"4d60a67c06f64f7da11cc7e4a924336c2efa9ab5@gmail.com"},"message":"criticalstat: Fix check for invalid stacks (#1839)\n\nWhile changing the stack_id to be signed, I accidentally screwed the\r\ncheck for an invalid stack_id. Some reason I didn't catch this even in\r\nmy tests. This patch fixes the issue (thanks Erick Reyes for reporting).\r\n\r\nBy the way, one weirdness I see is invalid stack_id is printed as -17\r\nwhen I print it in python.\r\n\r\nWhen I do bpf_trace_printk, I get these ids:\r\nroot@localhost:/# cat /d/tracing/trace_pipe\r\n          <idle>-0     [003] .n.3   942.100225: : sid: 15\r\n          <idle>-0     [002] .n.3   943.140393: : sid: 15\r\n     kworker/3:3-1798  [003] ...3   943.422768: : sid: 6\r\n     kworker/3:3-1798  [003] ...3   943.423419: : sid: 6\r\n     kworker/3:3-1798  [003] ...3   943.423967: : sid: 6\r\n   BootAnimation-650   [003] .n.3   949.840268: : sid: 8\r\n          <idle>-0     [003] .n.3   952.360226: : sid: 15\r\n          <idle>-0     [000] ...3   953.100116: : sid: 11\r\n    Binder:571_3-1469  [000] .n.3   953.513328: : sid: 3\r\n          <idle>-0     [003] .n.3   954.760215: : sid: 15\r\n    Binder:571_3-1469  [000] ...3   955.460271: : sid: 18446744073709551599\r\n          <idle>-0     [003] .n.3   957.420275: : sid: 15\r\n irq/296-cs35l36-662   [000] ...3   958.422890: : sid: 5\r\n     kworker/1:3-1729  [001] ...3   960.485247: : sid: 18446744073709551599\r\n     kworker/1:3-1729  [001] ...3   960.485888: : sid: 18446744073709551599\r\n\r\nAs an equivalent, when I do a print of the stack_id from the python\r\ncode, I get:\r\nstack_id 15\r\nstack_id 15\r\nstack_id 6\r\nstack_id 6\r\nstack_id 6\r\nstack_id 8\r\nstack_id 15\r\nstack_id 11\r\nstack_id 3\r\nstack_id 15\r\nstack_id -17\r\nstack_id 15\r\nstack_id 5\r\nstack_id -17\r\nstack_id -17\r\n\r\nThis isn't a big deal since the valid stack_ids match, but still\r\n1.8446744e+19 is -1 in 64-bit speak. So I do find that odd.\r\n\r\nReported-by: Erick Reyes <erickreyes@google.com>\r\nSigned-off-by: Joel Fernandes (Google) <joel@joelfernandes.org>","distinct":true,"url":"https://api.github.com/repos/oriolarcas/bcc/commits/d601984f5601ebb2567e9920e72dde7e09717c66"},{"sha":"9aab22ecd81160858e3dcd73db21b74e0473e403","author":{"name":"Oriol Arcas","email":"a98c9d4e37de3d71db2e1a293b51c579a914c4ae@starflownetworks.com"},"message":"Added new footer.h header where BPF_LICENSE is set if not defined\n\nThe helpers.h header specifies the BPF program license as 'GPL'.\nHowever, other GPL-compatible licenses are possible (e.g., Dual BSD/GPL)\nor even proprietary licenses (e.g., cachetop can run with a proprietary\nlicense).\n\nWith this commit, the user can specify a BPF_LICENSE macro in the source\ncode:\n\n  #define BPF_LICENSE Custom license\n\nNote it supports multiple words and the absence of quotes. If the BPF\ndoesn't have a GPL-compatible license and it uses any GPL-only helpers,\nthe kernel will reject it with:\n\n  cannot call GPL only function from proprietary program\n\nIf no license is specified, it will fall back to GPL (the current\nbehavior before this commit) so that the BCC tools and examples remain\nusable.\n\nUpdated the documentation with BPF_LICENSE description, licensing error\ndescription, and licenses for each helper.\n\nSigned-off-by: Oriol Arcas <oriol@starflownetworks.com>","distinct":true,"url":"https://api.github.com/repos/oriolarcas/bcc/commits/9aab22ecd81160858e3dcd73db21b74e0473e403"}]}
{"actor":{"display_login":"oriolarcas"}}