Re: [kbuild-all] Re: [PATCH] btrfs: fix devid 0 without a replace item by failing the mount

[Rong Chen <rong.a.chen@intel.com>]

On 10/7/20 10:07 AM, Anand Jain wrote:
> On 6/10/20 10:54 pm, kernel test robot wrote:
>> Hi Anand,
>>
>> Thank you for the patch! Yet something to improve:
>>
>> [auto build test ERROR on kdave/for-next]
>> [also build test ERROR on v5.9-rc8 next-20201006]
>> [If your patch is applied to the wrong git tree, kindly drop us a note.
>> And when submitting patch, we suggest to use '--base' as documented in
>> https://git-scm.com/docs/git-format-patch]
>>
>> url: 
>> https://github.com/0day-ci/linux/commits/Anand-Jain/btrfs-fix-devid-0-without-a-replace-item-by-failing-the-mount/20201006-210957
>> base: https://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux.git 
>> for-next
>> config: i386-randconfig-s001-20201005 (attached as .config)
>> compiler: gcc-9 (Debian 9.3.0-15) 9.3.0
>> reproduce:
>>          # apt-get install sparse
>>          # sparse version: v0.6.2-201-g24bdaac6-dirty
>>          # 
>> https://github.com/0day-ci/linux/commit/ed4ebb4eb3f213f048ea5f6a2ed80f6bd728c9e1
>>          git remote add linux-review https://github.com/0day-ci/linux
>>          git fetch --no-tags linux-review 
>> Anand-Jain/btrfs-fix-devid-0-without-a-replace-item-by-failing-the-mount/20201006-210957
>>          git checkout ed4ebb4eb3f213f048ea5f6a2ed80f6bd728c9e1
>>          # save the attached .config to linux build tree
>>          make W=1 C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' 
>> ARCH=i386
>>
>> 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 >>):
>>
>>     fs/btrfs/dev-replace.c: In function 'btrfs_init_dev_replace':
>>>> fs/btrfs/dev-replace.c:98:7: error: too few arguments to function 
>>>> 'btrfs_find_device'
>>        98 |   if (btrfs_find_device(fs_info->fs_devices,
>>           |       ^~~~~~~~~~~~~~~~~
>>     In file included from fs/btrfs/dev-replace.c:18:
>>     fs/btrfs/volumes.h:455:22: note: declared here
>>       455 | struct btrfs_device *btrfs_find_device(struct 
>> btrfs_fs_devices *fs_devices,
>>           |                      ^~~~~~~~~~~~~~~~~
>>     fs/btrfs/dev-replace.c:161:7: error: too few arguments to 
>> function 'btrfs_find_device'
>>       161 |   if (btrfs_find_device(fs_info->fs_devices,
>>           |       ^~~~~~~~~~~~~~~~~
>>     In file included from fs/btrfs/dev-replace.c:18:
>>     fs/btrfs/volumes.h:455:22: note: declared here
>>       455 | struct btrfs_device *btrfs_find_device(struct 
>> btrfs_fs_devices *fs_devices,
>>           |                      ^~~~~~~~~~~~~~~~~
>>
>
>  Is there is a way to mention the patch dependencies, so that 0-Day 
> tests would understand. As in the patch's changelog, two dependent 
> patches [1] aren't in the misc-next yet.
>
> [1]
> https://patchwork.kernel.org/patch/11818635
> https://patchwork.kernel.org/patch/11796905

HI Anand,

The '--base' option in git format-patch may help, from man git format-patch:

BASE TREE INFORMATION
        The base tree information block is used for maintainers or third 
party testers to know the exact state the patch series applies to. It 
consists of the base commit, which is a well-known commit that is part 
of the stable part of the project history everybody else works
        off of, and zero or more prerequisite patches, which are 
well-known patches in flight that is not yet part of the base commit 
that need to be applied on top of base commit in topological order 
before the patches can be applied.

        The base commit is shown as "base-commit: " followed by the 
40-hex of the commit object name. A prerequisite patch is shown as 
"prerequisite-patch-id: " followed by the 40-hex patch id, which can be 
obtained by passing the patch through the git patch-id --stable
        command.

        Imagine that on top of the public commit P, you applied 
well-known patches X, Y and Z from somebody else, and then built your 
three-patch series A, B, C, the history would be like:

            ---P---X---Y---Z---A---B---C

        With git format-patch --base=P -3 C (or variants thereof, e.g. 
with --cover-letter or using Z..C instead of -3 C to specify the range), 
the base tree information block is shown at the end of the first message 
the command outputs (either the first patch, or the cover
        letter), like this:

            base-commit: P
            prerequisite-patch-id: X
            prerequisite-patch-id: Y
            prerequisite-patch-id: Z

        For non-linear topology, such as

            ---P---X---A---M---C
                \         /
                 Y---Z---B

        You can also use git format-patch --base=P -3 C to generate 
patches for A, B and C, and the identifiers for P, X, Y, Z are appended 
at the end of the first message.

        If set --base=auto in cmdline, it will track base commit 
automatically, the base commit will be the merge base of tip commit of 
the remote-tracking branch and revision-range specified in cmdline. For 
a local branch, you need to track a remote branch by git branch
        --set-upstream-to before using this option.

Best Regards,
Rong Chen