Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
IronPort-SDR: YMQ30CfEgG85iAvpEFD43tCgsbCXchP7vwdHTHQ5666SLDpeRZ/UBEyFxGrPO+Qw0fufbV5+UC
 eRhz5Gjh0m4JEhwnuGxZxN/g3jeSc4AcHdQYMOBSQjrbiqjPuvOug63OTopqClc+oQU9HbFqGz
 AY+DEMBWK3V5zQAz3LZ2PTY0l9+i2xEgx3kLBvinKoOl4npxiyK3G4Gp72eNZu06XGm0Ef4MhE
 stfX5gpyWJNw4nQ0JL9Dz5exwjTvXZ0cwY/86a1G6Qwurnub6Z6+N10358T3F8WUlwDtUrFPBY
 4nE=
From:   Chaitanya Kulkarni <Chaitanya.Kulkarni@wdc.com>
To:     Steven Rostedt <rostedt@goodmis.org>,
        kernel test robot <oliver.sang@intel.com>
CC:     0day robot <lkp@intel.com>, LKML <linux-kernel@vger.kernel.org>,
        "lkp@lists.01.org" <lkp@lists.01.org>,
        "axboe@kernel.dk" <axboe@kernel.dk>,
        "viro@zeniv.linux.org.uk" <viro@zeniv.linux.org.uk>,
        "mingo@redhat.com" <mingo@redhat.com>,
        Johannes Thumshirn <Johannes.Thumshirn@wdc.com>,
        Damien Le Moal <Damien.LeMoal@wdc.com>,
        "bvanassche@acm.org" <bvanassche@acm.org>,
        "dongli.zhang@oracle.com" <dongli.zhang@oracle.com>,
        Aravind Ramesh <Aravind.Ramesh@wdc.com>,
        "joshi.k@samsung.com" <joshi.k@samsung.com>,
        Niklas Cassel <Niklas.Cassel@wdc.com>,
        "hch@lst.de" <hch@lst.de>, "osandov@fb.com" <osandov@fb.com>,
        "martin.petersen@oracle.com" <martin.petersen@oracle.com>,
        "linux-block@vger.kernel.org" <linux-block@vger.kernel.org>,
        "linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>
Subject: Re: [blktrace] c055908abe:
 WARNING:at_kernel/trace/trace.c:#create_trace_option_files
Thread-Topic: [blktrace] c055908abe:
 WARNING:at_kernel/trace/trace.c:#create_trace_option_files
Thread-Index: AQHXDUHnzYyhD4IqkU+G7Zy6VLI44g==
Date:   Sat, 27 Feb 2021 19:51:14 +0000
Message-ID: <BYAPR04MB49650C1C244E99AB1FFC590E869C9@BYAPR04MB4965.namprd04.prod.outlook.com>
References: <20210225070231.21136-34-chaitanya.kulkarni@wdc.com>
 <20210227114440.GA22871@xsang-OptiPlex-9020>
 <20210227094916.701a8a50@oasis.local.home>
Accept-Language: en-US
Content-Language: en-US
wdcipoutbound: EOP-TRUE
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 9c8c3ad8-2467-4922-d8a0-08d8db590a28
X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Feb 2021 19:51:14.0457
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: b61c8803-16f3-4c35-9b17-6f65f441df86
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 5G3N9bmR9EOAXcuQCfs+7pVNqKjKHqCjctMYtP0529oUjN4myC7X9Cljq1mdfMBOxEPejRI5LwvlD8ESeJRB0g8pkiPWWhH8Oa3thl1AUCA=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR04MB5893
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 2/27/21 06:49, Steven Rostedt wrote:=0A=
> On Sat, 27 Feb 2021 19:44:40 +0800=0A=
> kernel test robot <oliver.sang@intel.com> wrote:=0A=
>=0A=
>> [   20.216017] WARNING: CPU: 0 PID: 1 at kernel/trace/trace.c:8370 creat=
e_trace_option_files (kbuild/src/consumer/kernel/trace/trace.c:8370 (discri=
minator 1)) =0A=
>> [   20.218480] Modules linked in:=0A=
>> [   20.219395] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.11.0-09341-gc=
055908abe0d #1=0A=
>> [   20.221182] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BI=
OS 1.12.0-1 04/01/2014=0A=
>> [   20.224540] EIP: create_trace_option_files (kbuild/src/consumer/kerne=
l/trace/trace.c:8370 (discriminator 1)) =0A=
>> [ 20.225816] Code: d5 01 83 15 2c b7 08 d5 00 83 c0 01 39 c8 0f 84 c7 00=
 00 00 8b 14 c7 39 72 44 75 df 83 05 10 b7 08 d5 01 83 15 14 b7 08 d5 00 <0=
f> 0b 83 05 18 b7 08 d5 01 83 15 1c b7 08 d5 00 83 05 20 b7 08 d5=0A=
> Looks to be from this:=0A=
>=0A=
>> +static struct tracer blk_tracer_ext __read_mostly =3D {=0A=
>> +	.name		=3D "blkext",=0A=
>> +	.init		=3D blk_tracer_init,=0A=
>> +	.reset		=3D blk_tracer_reset,=0A=
>> +	.start		=3D blk_tracer_start,=0A=
>> +	.stop		=3D blk_tracer_stop,=0A=
>> +	.print_header	=3D blk_tracer_print_header,=0A=
>> +	.print_line	=3D blk_tracer_print_line_ext,=0A=
>> +	.flags		=3D &blk_tracer_flags,=0A=
>                           ^^^=0A=
>=0A=
> As blk_tracer already registers those flags, when it gets registered as=
=0A=
> a tracer, and flag names can not be duplicated.=0A=
>=0A=
> I could fix the infrastructure to detect the same set of flags being=0A=
> registered by two different tracers, but in the mean time, it may still=
=0A=
> work to use the blk_trace_flags from blk_tracer, and keep .flags NULL=0A=
> here.=0A=
>=0A=
> -- Steve=0A=
Thanks for the reply Steve. This is still under currently discussion and=0A=
I'm still=0A=
waiting formore people to reply on this approach, if we end up having=0A=
this as=0A=
a part of final implementation we may need to fix that.=0A=
=0A=
>=0A=
>> +	.set_flag	=3D blk_tracer_set_flag,=0A=
>> +};=0A=
>> +=0A=
=0A=