[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <af2db7e9-5fd4-2120-8308-99b58f9ad1a6@nfschina.com>
Date: Wed, 21 Jun 2023 14:28:44 +0800
From: Su Hui <suhui@...china.com>
To: Dan Carpenter <dan.carpenter@...aro.org>,
oe-kbuild@...ts.linux.dev, alexander.deucher@....com,
christian.koenig@....com, Xinhui.Pan@....com, airlied@...il.com,
daniel@...ll.ch
Cc: lkp@...el.com, oe-kbuild-all@...ts.linux.dev, Jane.Jian@....com,
David.Francis@....com, kernel-janitors@...r.kernel.org,
linux-kernel@...r.kernel.org, dri-devel@...ts.freedesktop.org,
amd-gfx@...ts.freedesktop.org, Likun.Gao@....com
Subject: Re: [PATCH] drm/amd/amdgpu: Use “__packed“ instead of "pragma pack()"
On 2023/6/21 14:11, Dan Carpenter wrote:
> When there was a #pragma then Sparse just turned off. The Sparse
> warnings are places where people forgot to put the __user in their casts
> or didn't annotate endianness correctly. It's not a "bug" to forget
> to annotate endianness or user pointers. That's how we used to do it
> prior to 2003. But these days it feels strange and dangerous to see
> these sorts of warnings.
Got it. And it is really strange when I first saw these warnings.
Thanks for your explanation!
Su Hui
>
> Smatch also disabled some uninitialized variable checks. These are
> mostly false positives where we have a loop:
>
> int r;
>
> while (something) {
> r = frob();
> }
>
> return r;
>
> Smatch complains that we don't necessarily enter the loop. I think
> I'm going to disable this type of "enter the loop" warning when you
> don't have the cross function database available. That will silence
> these for the kbuild bot.
>
> regards,
> dan carpenter
>
Powered by blists - more mailing lists