linux-kernel - Re: [Path -tip 1/3] Tracing/ftrace: Change the type of the print

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]

Message-ID: <c62985530809290211l7df01459lf80456ab98fc6ed0@mail.gmail.com>
Date:	Mon, 29 Sep 2008 11:11:15 +0200
From:	"Frédéric Weisbecker" <fweisbec@...il.com>
To:	"Pekka Paalanen" <pq@....fi>
Cc:	mingo@...e.hu, rostedt@...dmis.org, linux-kernel@...r.kernel.org
Subject: Re: [Path -tip 1/3] Tracing/ftrace: Change the type of the print_line callback

2008/9/28 Pekka Paalanen <pq@....fi>:
> I might have chosen names like TRACE_PRINT_{RETRY,DONE,DEFAULT_FORMAT},
> but it's your call. I'm not sure which one is more self-explanatory
> when you see a "return TRACE_...;" or "if (ret == TRACE_...)"

Hmm yes that's perhaps more explicit.


> Shouldn't the return type be bool?
> If it's not, reading this function makes me wonder about the conversion
> from enum to int, i.e. what is the meaning of the int.

Actually it should be enum print_line_t. I forgot to change its type.
But we need to check its return value as an enum print_line_t.

> It would be shorter to write
> if (ret != TRACE_TYPE_UNHANDLED)
> and then one could even
> return (ret == TRACE_TYPE_HANDLED);

Yes, I corrected it in my "week-end patch" :-)

> Do these actually need checking? I don't think
> the default print functions would ever return
> TRACE_TYPE_UNHANDLED, could they?
> And even if they did, do all the different default print
> functions not handle the same set of entry types?

At this moment they don't. But I just wanted to set a security in case
of possible future changes in these functions.


> We have to find a proper way to prevent the pipe from closing
> early. I'm trying to look into this. I'd like you to leave
> that last hunk out. Other than that, very good.

I made a new patch this week-end and I found a way to prevent from
closing the pipe.
I will just change a bit my patch in the base of your comments.

> btw. there might be a corner case, when a single line does not
> fit even into an empty struct trace_seq in tracing_read_pipe(),
> but I haven't thought of that yet. I'd expect it to hang.

I should look at this possible issue too. I didn't think about it yet.
--
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/