lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Fri, 23 Jan 2015 17:40:02 -0500
From:	Jérémie Galarneau 
	<jeremie.galarneau@...icios.com>
To:	Wang Nan <wangnan0@...wei.com>
Cc:	Jiri Olsa <jolsa@...hat.com>, Steven Rostedt <rostedt@...dmis.org>,
	Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
	Li Zefan <lizefan@...wei.com>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH RFC 2/2] perf: convert: fix duplicate field names and
 avoid reserved keywords.

On Thu, Jan 22, 2015 at 8:57 PM, Wang Nan <wangnan0@...wei.com> wrote:
> On 2015/1/22 21:27, Jiri Olsa wrote:
>> On Thu, Jan 22, 2015 at 01:36:43PM +0800, Wang Nan wrote:
>>> (If Steven Rostedt accept the previous patch which introduce a priv
>>>  field to 'struct format_field', we can use a relative simple method
>>>  for name conversion. If not , perf must track name conversion by
>>>  itself.)
>>>
>>> Some parameters of syscall tracepoints named as 'nr', 'event', etc.
>>> When dealing with them, perf convert to ctf meets some problem:
>>>
>>>  1. If a parameter with name 'nr', it will duplicate syscall's
>>>     common field 'nr'. One such syscall is io_submit().
>>>
>>>  2. If a parameter with name 'event', it is denied to be inserted
>>>     because 'event' is a babeltrace keywork. One such syscall is
>>>     epoll_ctl.
>>>
>>> This patch appends '_dupl_X' suffix to avoid problem 1, prepend a '_'
>>> prefix to avoid problem 2.
>>
>> I've got compilation error:
>>
>> util/data-convert-bt.c: In function ‘event_class_add_field’:
>> util/data-convert-bt.c:629:2: error: suggest parentheses around assignment used as truth value [-Werror=parentheses]
>>   while (t = bt_ctf_event_class_get_field_by_name(event_class, name)) {
>>
>> what's your gcc version? mine's caught that..
>>
>
> I also curious why you got so many Werror problems I'm not ever seen,
> until I found a '-w' in my gcc options, which is introduced by your commit
>
> 47810c1d429bc690e1f5e9467697538921962171: perf data: Disable Werror convert object.
>
> I'll revert that commit in my tree.
>
>> [jolsa@...va perf]$ gcc --version
>> gcc (GCC) 4.8.3 20140911 (Red Hat 4.8.3-7)
>>
>> SNIP
>>
>>>
>>> +/* If dup < 0, add a prefix. Else, add _dupl_X suffix. */
>>> +static char *change_name(char *name, char *orig_name, int dup)
>>> +{
>>> +    char *new_name = NULL;
>>> +    size_t len;
>>> +
>>> +    if (!name)
>>> +            name = orig_name;
>>> +
>>> +    if (dup >= 10)
>>> +            goto out;
>>> +
>>> +    if (dup < 0)
>>> +            len = strlen(name) + sizeof("_");
>>> +    else
>>> +            len = strlen(orig_name) + sizeof("_dupl_X");
>>
>> if we allow for _dupl_10, should we use 'sizeof("_dupl_x")' ^^^ in here?
>>
>>> +
>>> +    new_name = malloc(len);
>>> +    if (!new_name)
>>> +            goto out;
>>> +
>>> +    if (dup < 0)
>>> +            snprintf(new_name, len, "_%s", name);
>>> +    else
>>> +            snprintf(new_name, len, "%s_dupl_%d", orig_name, dup);
>>> +
>>> +out:
>>> +    if (name != orig_name)
>>> +            free(name);
>>> +    return new_name;
>>
>> SNIP
>>
>>> +
>>> +    name = field->name;
>>> +    while (t = bt_ctf_event_class_get_field_by_name(event_class, name)) {
>>> +            bt_ctf_field_type_put(t);
>>> +            name = change_name(name, field->name, dup++);
>>> +            if (!name) {
>>> +                    pr_err("Failed to create dup name for '%s'\n", field->name);
>>> +                    return -1;
>>> +            }
>>> +    }
>>> +
>>> +    ret = bt_ctf_event_class_add_field(event_class, type, name);
>>> +
>>> +    /* if failed, we may hit a keywork. try again with a '_' prefix */
>>> +    if (ret) {
>>> +            name = change_name(name, field->name, -1);
>>> +            if (!name) {
>>> +                    pr_err("Failed to alloc name for '_%s'\n", field->name);
>>> +                    return -1;
>>> +            }
>>> +            ret = bt_ctf_event_class_add_field(event_class, type, name);
>>
>> so there's no other way on checking up with the blacklist right?
>>
>
> AFAIK there's no official method to check blacklist right now. Utilizing existing
> functions to check blacklist is possible. For example, we can create a clock using
> bt_ctf_clock_create() with the checked name and then free it. However, it is hacky
> and I think you won't like it.

The prospect of seeing that code has convinced me to introduce
int bt_ctf_validate_identifier(const char *identifier);

commit 654c1444b546fd79b209288b93ed4e87d9bb8a2b
Author: Jérémie Galarneau <jeremie.galarneau@...icios.com>
Date:   Fri Jan 23 16:24:52 2015 -0500

    Add utility function to validate CTF identifiers

    Introduces bt_ctf_validate_identifier() which validates a given
    identifier against the list of CTF reserved keywords.

    This function may evolve to perform additional validity checks in
    the future as the CTF specification moves forward.

    Acked-by: Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
    Signed-off-by: Jérémie Galarneau <jeremie.galarneau@...icios.com>


Does that take care of the problem?

Jérémie

>
> I believe my solution should be acceptable before babeltrace export its
> validate_identifier() function to users. Jérémie Galarneau, do you have better
> idea on it?
>
> Thanks.
>
>> thanks,
>> jirka
>>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/



-- 
Jérémie Galarneau
EfficiOS Inc.
http://www.efficios.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ