From mboxrd@z Thu Jan  1 00:00:00 1970
Content-Type: multipart/mixed; boundary="===============0146540154148727462=="
MIME-Version: 1.0
From: Jens Axboe <axboe@kernel.dk>
To: kbuild-all@lists.01.org
Subject: Re: [block:for-5.13/drivers 44/80] ./usr/include/linux/bcache-nvm.h:109:3: error: #error "Non-64bit platform is not supported"
Date: Tue, 20 Apr 2021 07:36:11 -0600
Message-ID: <9b494c21-574d-909a-68c2-300af284ec28@kernel.dk>
In-Reply-To: <660303d5-5c03-9196-4c76-3b225c744596@suse.de>
List-Id: <oe-kbuild-all.lists.linux.dev>

--===============0146540154148727462==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable

On 4/19/21 10:20 PM, Coly Li wrote:
> On 4/20/21 12:02 PM, kernel test robot wrote:
>> tree:   https://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux-bloc=
k.git for-5.13/drivers
>> head:   637d8f534626747ad165c9d28c6673d88d39399d
>> commit: 97d69b16cb973e04ea5309b9cb4356aa6b42c54e [44/80] bcache: add ini=
tial data structures for nvm pages
>> config: i386-randconfig-a012-20210419 (attached as .config)
>> compiler: gcc-9 (Debian 9.3.0-22) 9.3.0
>> reproduce (this is a W=3D1 build):
>>         # https://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux-bl=
ock.git/commit/?id=3D97d69b16cb973e04ea5309b9cb4356aa6b42c54e
>>         git remote add block https://git.kernel.org/pub/scm/linux/kernel=
/git/axboe/linux-block.git
>>         git fetch --no-tags block for-5.13/drivers
>>         git checkout 97d69b16cb973e04ea5309b9cb4356aa6b42c54e
>>         # save the attached .config to linux build tree
>>         make W=3D1 W=3D1 ARCH=3Di386 =

>>
>> If you fix the issue, kindly add following tag as appropriate
>> Reported-by: kernel test robot <lkp@intel.com>
>>
>> All errors (new ones prefixed by >>):
>>
>>    In file included from <command-line>:32:
>>>> ./usr/include/linux/bcache-nvm.h:109:3: error: #error "Non-64bit platf=
orm is not supported"
>>      109 |  #error "Non-64bit platform is not supported"
>>          |   ^~~~~
>>
> =

> This series is result of community cooperation, "#error" is to make sure
> this header won't be used in non-64bit platform. And following patches
> in this series make sure the "#error" won't be triggered.

It sounds like the series is ordered wrong, then. You don't introduce a
known failure point, then fix it up in subsequent patches. You ensure
that the condition can never happen, then introduce the change.
Otherwise you're left with broken bisection points, which is
problematic.

I need to take a closer look, but will any 32-bit kernel compile fail at
that commit???

-- =

Jens Axboe

--===============0146540154148727462==--