[<prev] [next>] [day] [month] [year] [list]
Message-ID: <d48b2b1b-201a-d350-6bda-943a66f1abfb@videotron.qc.ca>
Date: Wed, 24 Oct 2018 19:52:40 -0400
From: sebhtml <sebhtml@...eotron.qc.ca>
To: Andrew Morton <akpm@...ux-foundation.org>,
Dan Williams <dan.j.williams@...el.com>
Cc: Steven Rostedt <rostedt@...dmis.org>, acme@...hat.com,
tz.stoyanov@...il.com, Namhyung Kim <namhyung@...nel.org>,
zwisler@...nel.org, arangradient@...il.com,
linux-perf-users@...r.kernel.org,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] pfn_t: force '~' to be parsed as an unary operator
On 2018-10-24 6:43 p.m., Andrew Morton wrote:
>
> I grabbed it, and added cc:stable.
>
> But aren't we fixing this in the wrong place? That's a valid
> expression and if this isn't addressed in perf then we may hit a
> similar issue elsewhere...
>
Right.
Based on:
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 01aa9d518eae8a4d75cd3049defc6ed0b6d0a658
In perf, the warning
[fs_dax:dax_pmd_insert_mapping] unknown op '~'
comes from tools/lib/traceevent/event-parse.c at line 2045:
do_warning_event(event, "unknown op '%s'", token);
This is in this function:
static enum tep_event_type
process_op(struct tep_event_format *event, struct tep_print_arg *arg, char **tok);
The code path to reach the good '~' case needs:
if (arg->type == TEP_PRINT_OP && !arg->op.left) {
I assume that here arg->op.left is not NULL because of (u64) on the left.
~(((u64) ~(~(((1UL) << 12)-1)))
^
However, I fail to see where '~' is parsed as a binary operator though.
Any pointer would be welcome.
Powered by blists - more mailing lists