26 Sep, 2006

1 commit


24 Sep, 2006

2 commits


18 Sep, 2006

1 commit


12 Sep, 2006

1 commit

  • ... that should do it for all targets; the only remaining issues are
    mips (currently treated as non-biarch) and handling of other OS
    emulations (OSF/SunOS/Solaris/???). The latter would need to be
    assigned new AUDIT_ARCH_... ABI numbers anyway...

    Signed-off-by: Al Viro

    Al Viro
     

08 Sep, 2006

1 commit

  • This prevents cross-region mappings on IA64 and SPARC which could lead
    to system crash. They were correctly trapped for normal mmap() calls,
    but not for the kernel internal calls generated by executable loading.

    This code just moves the architecture-specific cross-region checks into
    an arch-specific "arch_mmap_check()" macro, and defines that for the
    architectures that needed it (ia64, sparc and sparc64).

    Architectures that don't have any special requirements can just ignore
    the new cross-region check, since the mmap() code will just notice on
    its own when the macro isn't defined.

    Signed-off-by: Pavel Emelianov
    Signed-off-by: Kirill Korotaev
    Acked-by: David Miller
    Signed-off-by: Greg Kroah-Hartman
    [ Cleaned up to not affect architectures that don't need it ]
    Signed-off-by: Linus Torvalds

    Kirill Korotaev
     

30 Aug, 2006

1 commit

  • This problem was introduced by changeset
    14778d9072e53d2171f66ffd9657daff41acfaed

    Unlike the hugetlb code paths, the normal fault code is not setup to
    propagate PTE changes for large page sizes correctly like the ones we
    make for I/O mappings in io_remap_pfn_range().

    It is absolutely necessary to update all sub-ptes of a largepage
    mapping on a fault. Adding special handling for this would add
    considerably complexity to tlb_batch_add(). So let's just side-step
    the issue and forcefully dirty any writable PTEs created by
    io_remap_pfn_range().

    The only other real option would be to disable to large PTE code of
    io_remap_pfn_range() and we really don't want to do that.

    Much thanks to Mikael Pettersson for tracking down this problem and
    testing debug patches.

    Signed-off-by: David S. Miller

    David S. Miller
     

25 Jul, 2006

1 commit


22 Jul, 2006

5 commits


15 Jul, 2006

3 commits


13 Jul, 2006

5 commits

  • There is an implicit assumption in the code that ranges will translate
    to something that can fit in 2 32-bit cells, or a 64-bit value. For
    certain kinds of things below PCI this isn't necessarily true.

    Here is what the relevant OF device hierarchy looks like for one of
    the serial controllers on an Ultra5:

    Node 0xf005f1e0
    ranges: 00000000.00000000.00000000.000001fe.01000000.00000000.01000000
    01000000.00000000.00000000.000001fe.02000000.00000000.01000000
    02000000.00000000.00000000.000001ff.00000000.00000001.00000000
    03000000.00000000.00000000.000001ff.00000000.00000001.00000000
    device_type: 'pci'
    model: 'SUNW,sabre'

    Node 0xf005f9d4
    device_type: 'pci'
    model: 'SUNW,simba'

    Node 0xf0060d24
    ranges: 00000010.00000000 82010810.00000000.f0000000 01000000
    00000014.00000000 82010814.00000000.f1000000 00800000
    name: 'ebus'

    Node 0xf0062dac
    reg: 00000014.003083f8.00000008 --> 0x1ff.f13083f8
    device_type: 'serial'
    name: 'su'

    So the correct translation here is:

    1) Match "su" register to second ranges entry of 'ebus', which translates
    into a PCI triplet "82010814.00000000.f1000000" of size 00800000, which
    gives us "82010814.00000000.f13083f8".

    2) Pass-through "SUNW,simba" since it lacks ranges property

    3) Match "82010814.00000000.f13083f8" to third ranges property of PCI
    controller node 'SUNW,sabre', and we arrive at the final physical
    MMIO address of "0x1fff13083f8".

    Due to the 2-cell assumption, we couldn't translate to a PCI 3-cell
    value, and we couldn't perform a pass-thru on it either.

    It was easiest to just stop splitting the ranges application operation
    between two methods, ->map and ->translate, and just let ->map do all
    the work. That way it would work purely on 32-bit cell arrays instead
    of having to "return" some value like a u64.

    It's still not %100 correct because the out-of-range check is still
    done using the 64 least significant bits of the range and address.
    But it does work for all the cases I've thrown at it so far.

    Signed-off-by: David S. Miller

    David S. Miller
     
  • It is only needed when there is a PCI-PCI bridge sitting
    between the device and the PCI host controller which is
    not a Simba APB bridge.

    Add logic to handle two special cases:

    1) device behind EBUS, which sits on PCI
    2) PCI controller interrupts

    Signed-off-by: David S. Miller

    David S. Miller
     
  • When installing the IRQ pre-handler, we were not setting up the second
    argument correctly. It should be a pointer to the sabre_irq_data, not
    the config space PIO address.

    Furthermore, we only need this pre-handler installed if the device
    sits behind a PCI bridge that is not Sabre or Simba/APB.

    Signed-off-by: David S. Miller

    David S. Miller
     
  • Signed-off-by: David S. Miller

    David S. Miller
     
  • device_create_file() can fail. This causes the sparc64 compile to
    fail when my fanatical __must_check patch is applied, due to -Werror.

    [ Added necessary identical fix for sparc32. -DaveM]

    Signed-off-by: Andrew Morton
    Signed-off-by: David S. Miller

    Andrew Morton
     

11 Jul, 2006

2 commits

  • Currently most architectures either always build binfmt_elf32 in the kernel
    image or make it a boolean option. Only sparc64 and s390 allow to build it
    modularly. This patch turns the option into a boolean aswell because elf
    requires various symbols that shouldn't be available to modules. The most
    urgent one is tasklist_lock whos export this patch series kills, but there
    are others like force_sgi aswell.

    Note that sparc doesn't allow a modular 32bit a.out handler either, and
    that would be the more useful case as only few people want 32bit sunos
    compatibility and 99.9% of all sparc64 users need 32bit linux native elf
    support.

    Signed-off-by: Christoph Hellwig
    Acked-by: "David S. Miller"
    Cc: Martin Schwidefsky
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Christoph Hellwig
     
  • screen_info.h doesn't have anything to do with the tty layer and shouldn't be
    included by tty.h. This patches removes the include and modifies all users to
    directly include screen_info.h. struct screen_info is mainly used to
    communicate with the console drivers in drivers/video/console. Note that this
    patch touches every arch and I have no way of testing it. If there is a
    mistake the worst thing that will happen is a compile error.

    [akpm@osdl.org: fix arm build]
    [akpm@osdl.org: fix alpha build]
    Signed-off-by: Jon Smirl
    Signed-off-by: Antonino Daplas
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Jon Smirl
     

06 Jul, 2006

2 commits


03 Jul, 2006

1 commit


01 Jul, 2006

6 commits


30 Jun, 2006

8 commits