Re: linux-next: build failure after merge of the vhost tree

From: "Michael S. Tsirkin" <mst@redhat.com>
To: Stephen Rothwell <sfr@canb.auug.org.au>
Cc: linux-next@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: linux-next: build failure after merge of the vhost tree
Date: Wed, 22 May 2013 12:03:40 +0300	[thread overview]
Message-ID: <20130522090340.GA19482@redhat.com> (raw)
In-Reply-To: <20130522143704.3431658328f8f879f55b0910@canb.auug.org.au>

On Wed, May 22, 2013 at 02:37:04PM +1000, Stephen Rothwell wrote:
> Hi Michael,
> 
> After merging the vhost tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
> 
> In file included from arch/powerpc/include/asm/uaccess.h:12:0,
>                  from arch/powerpc/lib/checksum_wrappers_64.c:24:
> include/asm-generic/uaccess.h: In function 'might_fault':
> include/asm-generic/uaccess.h:36:2: error: implicit declaration of function 'segment_eq' [-Werror=implicit-function-declaration]
>   if (_might_fault())
>   ^
> include/asm-generic/uaccess.h:36:2: error: implicit declaration of function 'get_fs' [-Werror=implicit-function-declaration]
> include/asm-generic/uaccess.h:29:47: error: 'KERNEL_DS' undeclared (first use in this function)
>  #define _might_fault() (!segment_eq(get_fs(), KERNEL_DS) && !in_atomic())
>                                                ^
> include/asm-generic/uaccess.h:36:6: note: in expansion of macro '_might_fault'
>   if (_might_fault())
>       ^
> 
> and many, many more.
> 
> Caused by commit d198a8acf543 ("kernel: might_fault does not imply
> might_sleep").
> 
> I have used the version of the vhost tree from next-20130521 for today.

Aha I see what happened. I fixed it and made sure the
changes build and work, but didn't commit and pushed from
a dirty tree.

> 
> It was unexpected that such patches would turn up in the "vhost" tree ...
> 
> -- 
> Cheers,
> Stephen Rothwell                    sfr@canb.auug.org.au

vhost wants to use these changes but these patches are still
work in progress. Since the changes are all over the
tree I thought looking at how they interact with
everyone's work at an early stage is a good idea.

Of course breaking builds for everyone is not acceptable,
I'm very sorry about that.
I'll make double sure by tree is clean before push next time,
will also look at whether git push can check this automatically.

-- 
MST