lkml.org 
[lkml]   [2013]   [Sep]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH] staging: Disable lustre file system for MIPS, SH, and XTENSA
    On Mon, Sep 09, 2013 at 09:11:25PM +0200, Geert Uytterhoeven wrote:
    > On Mon, Sep 9, 2013 at 7:22 PM, Greg Kroah-Hartman
    > <gregkh@linuxfoundation.org> wrote:
    > > On Mon, Sep 09, 2013 at 10:08:19AM -0700, Guenter Roeck wrote:
    > >> On Mon, Sep 09, 2013 at 09:39:02AM -0700, Greg Kroah-Hartman wrote:
    > >> > On Mon, Sep 09, 2013 at 06:40:12AM -0700, Christoph Hellwig wrote:
    > >> > > On Sun, Sep 08, 2013 at 06:59:45PM -0700, Greg Kroah-Hartman wrote:
    > >> > > > Can't we just export the functions for those arches? Surely lutre
    > >> > > > isn't the first/only driver that needs this?
    > >> > >
    > >> > > Lustre is. These are core mm helpers, and lustre uses them to
    > >> > > reimplement another core VM function. It then uses it to access
    > >> > > userspace environment variable.
    > >> > >
    > >> > > In short all this code should be nuked, and no new symbols should be
    > >> > > exported.
    > >> >
    > >> > Ugh, you are right, the lustre code needs to be fixed here.
    > >> >
    > >> Given that, should I send another patch marking it as BROKEN again ?
    > >
    > > Well, on those arches it's "broken", so I'll dig up your original patch
    > > on this thread. It's just "normal" for staging drivers to duplicate
    > > core code, it needs to be fixed up before it can be merged into the
    > > kernel tree, so no need to do anything special.
    >
    > It's not only broken on MIPS, SH, and XTENSA, but also on at least parisc
    > and m68k[*].
    >
    > It's no longer broken on sparc64, as the missing export already got
    > into mainline.
    > In light of the above, perhaps that should be reverted?
    >
    Agreed.

    > [*] Why does m68k allmodconfig still succeed on kissb???
    > It does fail for me, as m68k's copy_from_user_page() calls
    > flush_icache_user_range(), which is not exported.
    >
    I don't see a build failure in m68k:allmodconfig either.

    flush_icache_user_range() is called from copy_to_user_page(), not from
    copy_from_user_page(). copy_from_user_page() calls flush_cache_page()
    which calls __flush_cache_030(). The first is inline, the second is
    assembler, so I would expect it to work. Which doesn't answer
    the question why it fails for you.

    powerpc and frm export flush_icache_user_range(). Wonder if that is really
    necessary or points to other abuses.

    On parisc I currently only test defconfig. I'll check if allmodconfig passes
    in 3.10 and/or 3.11; if yes I'll add it to my test suite.

    Guenter


    \
     
     \ /
      Last update: 2013-09-09 22:21    [W:6.564 / U:0.020 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site