Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752893AbbGNCAI (ORCPT ); Mon, 13 Jul 2015 22:00:08 -0400 Received: from szxga02-in.huawei.com ([119.145.14.65]:12345 "EHLO szxga02-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751697AbbGNCAE (ORCPT ); Mon, 13 Jul 2015 22:00:04 -0400 From: He Kuang To: , , , , , , , CC: , , , Subject: [RFC PATCH v5 1/3] tracing/events: Fix wrong sample output by storing array length instead of size Date: Tue, 14 Jul 2015 01:59:29 +0000 Message-ID: <1436839171-31527-2-git-send-email-hekuang@huawei.com> X-Mailer: git-send-email 1.8.3.4 In-Reply-To: <1436839171-31527-1-git-send-email-hekuang@huawei.com> References: <1436839171-31527-1-git-send-email-hekuang@huawei.com> MIME-Version: 1.0 Content-Type: text/plain X-Originating-IP: [10.107.197.210] X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3506 Lines: 91 The output result of trace_foo_bar event in traceevent samples is wrong. This problem can be reproduced as following: (Build kernel with SAMPLE_TRACE_EVENTS=m) $ insmod trace-events-sample.ko $ echo 1 > /sys/kernel/debug/tracing/events/sample-trace/foo_bar/enable $ cat /sys/kernel/debug/tracing/trace event-sample-980 [000] .... 43.649559: foo_bar: foo hello 21 0x15 BIT1|BIT3|0x10 {0x1,0x6f6f6e53,0xff007970,0xffffffff} Snoopy ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ The array length is not right, should be {0x1}. (ffffffff,ffffffff) event-sample-980 [000] .... 44.653827: foo_bar: foo hello 22 0x16 BIT2|BIT3|0x10 {0x1,0x2,0x646e6147,0x666c61,0xffffffff,0xffffffff,0x750aeffe,0x7} ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ The array length is not right, should be {0x1,0x2}. Gandalf (ffffffff,ffffffff) The event defined in samples/trace_events/trace-events-sample.h uses this helper function to output dynamic list: __print_array(__get_dynamic_array(list), __get_dynamic_array_len(list), sizeof(int)) Currently, __get_dynamic_array_len() returns the total size of the array instead of the number of items by referencing the high 16 bits of entry->data_loc_##item. The element size for calculating the number of items can not be fetched by referencing fields from __entry, so macro __get_dynamic_array_len can not return the expected value. This patch stores array item number instead of the total size in entry->__data_loc_##item, and makes __get_dynamic_array_len get the right value directly. Because the function __get_bitmask() is affected by this change, __bitmask_size is assigned to the array len by multiplied bitmask type size. After this patch: event-sample-993 [000] .... 692.348562: foo_bar: foo hello 201 0xc9 BIT1|BIT4|0xc0 {0x1} Snoopy (ffffffff,ffffffff) ^^^^^ Array length fixed. event-sample-993 [000] .... 693.349276: foo_bar: foo hello 202 0xca BIT2|BIT4|0xc0 {0x1,0x2} Gandalf (ffffffff,ffffffff) ^^^^^^^^^ Array length fixed. Signed-off-by: He Kuang --- include/trace/trace_events.h | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/include/trace/trace_events.h b/include/trace/trace_events.h index 43be3b0..5abe027 100644 --- a/include/trace/trace_events.h +++ b/include/trace/trace_events.h @@ -257,7 +257,8 @@ TRACE_MAKE_SYSTEM_STR(); ({ \ void *__bitmask = __get_dynamic_array(field); \ unsigned int __bitmask_size; \ - __bitmask_size = __get_dynamic_array_len(field); \ + __bitmask_size = (__get_dynamic_array_len(field) * \ + sizeof(unsigned long)); \ trace_print_bitmask_seq(p, __bitmask, __bitmask_size); \ }) @@ -453,7 +454,7 @@ trace_event_define_fields_##call(struct trace_event_call *event_call) \ __item_length = (len) * sizeof(type); \ __data_offsets->item = __data_size + \ offsetof(typeof(*entry), __data); \ - __data_offsets->item |= __item_length << 16; \ + __data_offsets->item |= (len) << 16; \ __data_size += __item_length; #undef __string -- 1.8.5.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/