* 4.9.80 compile failure with X86_VSYSCALL_EMULATION=n due to 9a0be5af
@ 2018-02-12 15:43 Lennart Sorensen
2018-03-21 16:04 ` Greg Kroah-Hartman
0 siblings, 1 reply; 5+ messages in thread
From: Lennart Sorensen @ 2018-02-12 15:43 UTC (permalink / raw)
To: LKML; +Cc: Ben Hutchings, Len Sorensen, Greg Kroah-Hartman
Commit 9a0be5af added a reference to vsyscall_pgprot in
arch/x86/mm/kaiser.c but that is undefined if X86_VSYSCALL_EMULATION=n
which on an embedded system where you know how all your software is
compiled is quite likely.
Of course the condition is always false with that config so the code
will never be run, but the compiler is unhappy.
--
Len Sorensen
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: 4.9.80 compile failure with X86_VSYSCALL_EMULATION=n due to 9a0be5af
2018-02-12 15:43 4.9.80 compile failure with X86_VSYSCALL_EMULATION=n due to 9a0be5af Lennart Sorensen
@ 2018-03-21 16:04 ` Greg Kroah-Hartman
2018-03-21 16:31 ` Ben Hutchings
0 siblings, 1 reply; 5+ messages in thread
From: Greg Kroah-Hartman @ 2018-03-21 16:04 UTC (permalink / raw)
To: Lennart Sorensen; +Cc: LKML, Ben Hutchings
On Mon, Feb 12, 2018 at 10:43:25AM -0500, Lennart Sorensen wrote:
> Commit 9a0be5af added a reference to vsyscall_pgprot in
> arch/x86/mm/kaiser.c but that is undefined if X86_VSYSCALL_EMULATION=n
> which on an embedded system where you know how all your software is
> compiled is quite likely.
>
> Of course the condition is always false with that config so the code
> will never be run, but the compiler is unhappy.
What is the compiler error? I have not had any reports of this with all
of the varied builds that we currently run on the stable trees.
thanks,
greg k-h
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: 4.9.80 compile failure with X86_VSYSCALL_EMULATION=n due to 9a0be5af
2018-03-21 16:04 ` Greg Kroah-Hartman
@ 2018-03-21 16:31 ` Ben Hutchings
2018-03-21 16:34 ` Lennart Sorensen
0 siblings, 1 reply; 5+ messages in thread
From: Ben Hutchings @ 2018-03-21 16:31 UTC (permalink / raw)
To: Greg Kroah-Hartman, Lennart Sorensen; +Cc: LKML
On Wed, 2018-03-21 at 17:04 +0100, Greg Kroah-Hartman wrote:
> On Mon, Feb 12, 2018 at 10:43:25AM -0500, Lennart Sorensen wrote:
> > Commit 9a0be5af added a reference to vsyscall_pgprot in
> > arch/x86/mm/kaiser.c but that is undefined if X86_VSYSCALL_EMULATION=n
> > which on an embedded system where you know how all your software is
> > compiled is quite likely.
> >
> > Of course the condition is always false with that config so the code
> > will never be run, but the compiler is unhappy.
>
> What is the compiler error? I have not had any reports of this with all
> of the varied builds that we currently run on the stable trees.
You already applied a fix for this ("kaiser: fix compile error without
vsyscall").
Ben.
--
Ben Hutchings
Software Developer, Codethink Ltd.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: 4.9.80 compile failure with X86_VSYSCALL_EMULATION=n due to 9a0be5af
2018-03-21 16:31 ` Ben Hutchings
@ 2018-03-21 16:34 ` Lennart Sorensen
2018-03-21 16:37 ` Greg Kroah-Hartman
0 siblings, 1 reply; 5+ messages in thread
From: Lennart Sorensen @ 2018-03-21 16:34 UTC (permalink / raw)
To: Ben Hutchings; +Cc: Greg Kroah-Hartman, LKML
On Wed, Mar 21, 2018 at 04:31:03PM +0000, Ben Hutchings wrote:
> On Wed, 2018-03-21 at 17:04 +0100, Greg Kroah-Hartman wrote:
> > On Mon, Feb 12, 2018 at 10:43:25AM -0500, Lennart Sorensen wrote:
> > > Commit 9a0be5af added a reference to vsyscall_pgprot in
> > > arch/x86/mm/kaiser.c but that is undefined if X86_VSYSCALL_EMULATION=n
> > > which on an embedded system where you know how all your software is
> > > compiled is quite likely.
> > >
> > > Of course the condition is always false with that config so the code
> > > will never be run, but the compiler is unhappy.
> >
> > What is the compiler error? I have not had any reports of this with all
> > of the varied builds that we currently run on the stable trees.
>
> You already applied a fix for this ("kaiser: fix compile error without
> vsyscall").
Yeah the fix certainly works fine. I was not the only one reporting it.
--
Len Sorensen
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: 4.9.80 compile failure with X86_VSYSCALL_EMULATION=n due to 9a0be5af
2018-03-21 16:34 ` Lennart Sorensen
@ 2018-03-21 16:37 ` Greg Kroah-Hartman
0 siblings, 0 replies; 5+ messages in thread
From: Greg Kroah-Hartman @ 2018-03-21 16:37 UTC (permalink / raw)
To: Lennart Sorensen; +Cc: Ben Hutchings, LKML
On Wed, Mar 21, 2018 at 12:34:38PM -0400, Lennart Sorensen wrote:
> On Wed, Mar 21, 2018 at 04:31:03PM +0000, Ben Hutchings wrote:
> > On Wed, 2018-03-21 at 17:04 +0100, Greg Kroah-Hartman wrote:
> > > On Mon, Feb 12, 2018 at 10:43:25AM -0500, Lennart Sorensen wrote:
> > > > Commit 9a0be5af added a reference to vsyscall_pgprot in
> > > > arch/x86/mm/kaiser.c but that is undefined if X86_VSYSCALL_EMULATION=n
> > > > which on an embedded system where you know how all your software is
> > > > compiled is quite likely.
> > > >
> > > > Of course the condition is always false with that config so the code
> > > > will never be run, but the compiler is unhappy.
> > >
> > > What is the compiler error? I have not had any reports of this with all
> > > of the varied builds that we currently run on the stable trees.
> >
> > You already applied a fix for this ("kaiser: fix compile error without
> > vsyscall").
>
> Yeah the fix certainly works fine. I was not the only one reporting it.
Ah, ok, sorry, was catching up on email...
greg k-h
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2018-03-21 16:37 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-02-12 15:43 4.9.80 compile failure with X86_VSYSCALL_EMULATION=n due to 9a0be5af Lennart Sorensen
2018-03-21 16:04 ` Greg Kroah-Hartman
2018-03-21 16:31 ` Ben Hutchings
2018-03-21 16:34 ` Lennart Sorensen
2018-03-21 16:37 ` Greg Kroah-Hartman
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).