diff mbox

KVM: MIPS: Add missing uaccess.h include

Message ID d852b5f35e84e60c930589eeb14a6df21ea9b1cb.1476834183.git-series.james.hogan@imgtec.com (mailing list archive)
State New, archived
Headers show

Commit Message

James Hogan Oct. 18, 2016, 11:45 p.m. UTC
MIPS KVM uses user memory accessors but mips.c doesn't directly include
uaccess.h, so include it now.

This wasn't too much of a problem before v4.9-rc1 as asm/module.h
included asm/uaccess.h, however since commit 29abfbd9cbba ("mips:
separate extable.h, switch module.h to it") this is no longer the case.

This resulted in build failures when trace points were disabled, as
trace/define_trace.h includes trace/trace_events.h only ifdef
TRACEPOINTS_ENABLED, which goes on to include asm/uaccess.h via a couple
of other headers.

Fixes: 29abfbd9cbba ("mips: separate extable.h, switch module.h to it")
Signed-off-by: James Hogan <james.hogan@imgtec.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: "Radim Krčmář" <rkrcmar@redhat.com>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: linux-mips@linux-mips.org
Cc: kvm@vger.kernel.org
---
 arch/mips/kvm/mips.c | 1 +
 1 file changed, 1 insertion(+), 0 deletions(-)

Comments

Radim Krčmář Oct. 20, 2016, 1:10 p.m. UTC | #1
2016-10-19 00:45+0100, James Hogan:
> MIPS KVM uses user memory accessors but mips.c doesn't directly include
> uaccess.h, so include it now.
> 
> This wasn't too much of a problem before v4.9-rc1 as asm/module.h
> included asm/uaccess.h, however since commit 29abfbd9cbba ("mips:
> separate extable.h, switch module.h to it") this is no longer the case.
> 
> This resulted in build failures when trace points were disabled, as
> trace/define_trace.h includes trace/trace_events.h only ifdef
> TRACEPOINTS_ENABLED, which goes on to include asm/uaccess.h via a couple
> of other headers.
> 
> Fixes: 29abfbd9cbba ("mips: separate extable.h, switch module.h to it")
> Signed-off-by: James Hogan <james.hogan@imgtec.com>
> Cc: Paolo Bonzini <pbonzini@redhat.com>
> Cc: "Radim Krčmář" <rkrcmar@redhat.com>
> Cc: Ralf Baechle <ralf@linux-mips.org>
> Cc: linux-mips@linux-mips.org
> Cc: kvm@vger.kernel.org
> ---

We'd like to have this patch in 4.9-rc2 and I see it in kvm-mips/next.
Would you prefer to send a pull request?
(I can apply it directly just as well.)

Thanks.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
James Hogan Oct. 20, 2016, 1:16 p.m. UTC | #2
Hi Radim,

On Thu, Oct 20, 2016 at 03:10:54PM +0200, Radim Krčmář wrote:
> 2016-10-19 00:45+0100, James Hogan:
> > MIPS KVM uses user memory accessors but mips.c doesn't directly include
> > uaccess.h, so include it now.
> > 
> > This wasn't too much of a problem before v4.9-rc1 as asm/module.h
> > included asm/uaccess.h, however since commit 29abfbd9cbba ("mips:
> > separate extable.h, switch module.h to it") this is no longer the case.
> > 
> > This resulted in build failures when trace points were disabled, as
> > trace/define_trace.h includes trace/trace_events.h only ifdef
> > TRACEPOINTS_ENABLED, which goes on to include asm/uaccess.h via a couple
> > of other headers.
> > 
> > Fixes: 29abfbd9cbba ("mips: separate extable.h, switch module.h to it")
> > Signed-off-by: James Hogan <james.hogan@imgtec.com>
> > Cc: Paolo Bonzini <pbonzini@redhat.com>
> > Cc: "Radim Krčmář" <rkrcmar@redhat.com>
> > Cc: Ralf Baechle <ralf@linux-mips.org>
> > Cc: linux-mips@linux-mips.org
> > Cc: kvm@vger.kernel.org
> > ---
> 
> We'd like to have this patch in 4.9-rc2 and I see it in kvm-mips/next.
> Would you prefer to send a pull request?

Yes, I've applied it to my next branch and was going to send a pull
request this afternoon.

BTW, generally speaking do you always prefer pull requests to have the
patches sent in reply to it, or only if they haven't already been posted
for review?

> (I can apply it directly just as well.)

Thanks
James
Radim Krčmář Oct. 20, 2016, 5:53 p.m. UTC | #3
2016-10-20 14:16+0100, James Hogan:
> BTW, generally speaking do you always prefer pull requests to have the
> patches sent in reply to it, or only if they haven't already been posted
> for review?

I strongly prefer pull requests that include only patches that were
already posted on the list and slightly prefer to omit the patch
replies.

At least for me, a patch in a pull request has a FYI status instead of a
RFC status that a normal posting has.

[I'd like if all patches in pull requests were already (re)viewed by
 interested parties, so merge discussions could be high level or focus
 on things that we learned while/after applying the patches, hence there
 would be little benefit from reposting patches to the mailing list.]
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
James Hogan Oct. 20, 2016, 7:15 p.m. UTC | #4
On Thu, Oct 20, 2016 at 07:53:23PM +0200, Radim Krčmář wrote:
> 2016-10-20 14:16+0100, James Hogan:
> > BTW, generally speaking do you always prefer pull requests to have the
> > patches sent in reply to it, or only if they haven't already been posted
> > for review?
> 
> I strongly prefer pull requests that include only patches that were
> already posted on the list and slightly prefer to omit the patch
> replies.
> 
> At least for me, a patch in a pull request has a FYI status instead of a
> RFC status that a normal posting has.
> 
> [I'd like if all patches in pull requests were already (re)viewed by
>  interested parties, so merge discussions could be high level or focus
>  on things that we learned while/after applying the patches, hence there
>  would be little benefit from reposting patches to the mailing list.]

Good, I absolutely agree.

Thanks
James
diff mbox

Patch

diff --git a/arch/mips/kvm/mips.c b/arch/mips/kvm/mips.c
index ce961495b5e1..622037d851a3 100644
--- a/arch/mips/kvm/mips.c
+++ b/arch/mips/kvm/mips.c
@@ -14,6 +14,7 @@ 
 #include <linux/err.h>
 #include <linux/kdebug.h>
 #include <linux/module.h>
+#include <linux/uaccess.h>
 #include <linux/vmalloc.h>
 #include <linux/fs.h>
 #include <linux/bootmem.h>