[lkml]   [2010]   [Feb]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Split 'flush_old_exec' into two functions - 221af7f87b97431e3ee21ce4b0e77d5411cf1549
    Linus Torvalds wrote:
    > On Mon, 1 Feb 2010, Michal Simek wrote:
    >> Hi Peter and Linus,
    >> commit 221af7f87b97431e3ee21ce4b0e77d5411cf1549 breaks anything on Microblaze.
    > Gaah. My original version of that patch very much tried to make it a no-op
    > semantically, but then Peter made some preparatory changes for the next
    > patch, so it actually changes semantics a bit. I was expecting that to be
    > benign, but clearly there are issues.

    Would it be possible to cc me or send that patches to linux-next? I am
    doing every day tests and report results on my site. I would be able to
    catch up bugs earlier.

    >> None reported any problem that's why I think that is Microblaze related.
    > Well, our previous handling of the critical stage of 'execve()' when we
    > actually switch from the old process to the new was _so_ grotty that many
    > architectures ended up playing some really subtle games there. The whole
    > point of the patch is to get rid of the games, but it's entirely possible
    > that Microblaze (and others) had crazy things going on that broke when we
    > made the ordering more straightforward.
    > That said, Microblaze is not one of the architectures I would have
    > expected to have problems. It has one of the most straightforward
    > "flush_thread()" implementations in the whole kernel (it's a no-op ;), and
    > that's where most of the hacky things were for the architectures that
    > needed the change. And it has no "arch_pick_mmap_layout()" issues or
    > anything else that tends to depend on personality bits or whatever.
    > Microblaze is a no-MMU platform, isn't it?

    Microblaze has support for both platforms MMU and noMMU. Only MMU
    version is affected. noMMU version is without any problem.

    Which binary format does it
    > use? It looks like _some_ binaries work (it seems to happily be running a
    > shell to actually do those startup scripts) while others have problems. Is
    > there a difference between "/bin/sh" and the binaries that seem to be
    > problematic (like /bin/mount and /bin/ifup).

    Most of them is busybox ELF with shared libraries. I tried non-shared
    ELF and the problem is the same.

    > Are the failing binaries all setuid ones, for example? Or shared vs
    > non-shared? Or ELF vs FLAT or whatever?

    no setuid.


    > Linus

    Michal Simek, Ing. (M.Eng)
    PetaLogix - Linux Solutions for a Reconfigurable World
    w: p: +61-7-30090663,+42-0-721842854 f: +61-7-30090663

     \ /
      Last update: 2010-02-02 11:21    [W:0.023 / U:1.048 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site