Linux Virtualization - Jan 2014 - [PATCH stable-only] virtio-net: fix build on m68k and sparc64

On Wed, Jan 15, 2014 at 09:36:13AM +0100, Geert Uytterhoeven
wrote:
> On Wed, Jan 15, 2014 at 9:26 AM, Michael S. Tsirkin <mst at
redhat.com> wrote:
> > As a result of backporting a bugfix, virtio_net started passing void *
> > to page_address, assuming that it will get silently converted to
struct
> > page *. But this does not happen on architectures where page_address
is
> > a macro, the result is build failure as the macro tries to dereference
> > void*.
> >
> > Fix by reordering code slightly, so we always pass
> > struct page * to page_address.
> 
> Thanks for the clue! I was just investigating a similar failure in -next.
> 
> Gr{oetje,eeting}s,
> 
>                         Geert
You don't mean linux-next? And not in virtio-net? I don't see
page_address
being used on void * anywhere there.
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at
linux-m68k.org
> 
> In personal conversations with technical people, I call myself a hacker.
But
> when I'm talking to journalists I just say "programmer" or
something like that.
>                                 -- Linus Torvalds

On Wed, Jan 15, 2014 at 9:46 AM, Michael S. Tsirkin <mst at redhat.com>
wrote:
> On Wed, Jan 15, 2014 at 09:36:13AM +0100, Geert Uytterhoeven wrote:
>> On Wed, Jan 15, 2014 at 9:26 AM, Michael S. Tsirkin <mst at
redhat.com> wrote:
>> > As a result of backporting a bugfix, virtio_net started passing
void *
>> > to page_address, assuming that it will get silently converted to
struct
>> > page *. But this does not happen on architectures where
page_address is
>> > a macro, the result is build failure as the macro tries to
dereference
>> > void*.
>> >
>> > Fix by reordering code slightly, so we always pass
>> > struct page * to page_address.
>>
>> Thanks for the clue! I was just investigating a similar failure in
-next.
>>
>> Gr{oetje,eeting}s,
>>
>>                         Geert
>
> You don't mean linux-next? And not in virtio-net? I don't see
page_address
> being used on void * anywhere there.
http://kisskb.ellerman.id.au/kisskb/buildresult/10469287/

I'm making {,set}page_address() static inline to fix this.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at
linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or
something like that.
                                -- Linus Torvalds

On Wed, Jan 15, 2014 at 10:01:49AM +0100, Geert Uytterhoeven
wrote:
> On Wed, Jan 15, 2014 at 9:46 AM, Michael S. Tsirkin <mst at
redhat.com> wrote:
> > On Wed, Jan 15, 2014 at 09:36:13AM +0100, Geert Uytterhoeven wrote:
> >> On Wed, Jan 15, 2014 at 9:26 AM, Michael S. Tsirkin <mst at
redhat.com> wrote:
> >> > As a result of backporting a bugfix, virtio_net started
passing void *
> >> > to page_address, assuming that it will get silently converted
to struct
> >> > page *. But this does not happen on architectures where
page_address is
> >> > a macro, the result is build failure as the macro tries to
dereference
> >> > void*.
> >> >
> >> > Fix by reordering code slightly, so we always pass
> >> > struct page * to page_address.
> >>
> >> Thanks for the clue! I was just investigating a similar failure in
-next.
> >>
> >> Gr{oetje,eeting}s,
> >>
> >>                         Geert
> >
> > You don't mean linux-next? And not in virtio-net? I don't see
page_address
> > being used on void * anywhere there.
> 
> http://kisskb.ellerman.id.au/kisskb/buildresult/10469287/
Wew, so it's not my fault :)
> I'm making {,set}page_address() static inline to fix this.
Yes, I don't see why it has to be a macro.
> Gr{oetje,eeting}s,
> 
>                         Geert
> 
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at
linux-m68k.org
> 
> In personal conversations with technical people, I call myself a hacker.
But
> when I'm talking to journalists I just say "programmer" or
something like that.
>                                 -- Linus Torvalds