1. 18 May, 2009 1 commit
    • Yinghai Lu's avatar
      x86, apic: introduce io_apic_irq_attr · e5198075
      Yinghai Lu authored
      according to Ingo, io_apic irq-setup related functions have too many
      parameters with a repetitive signature.
      
      So reduce related funcs to get less params by passing a pointer
      to a newly defined io_apic_irq_attr structure.
      
      v2: io_apic_irq ==> irq_attr
          triggering ==> trigger
      
      v3: add set_io_apic_irq_attr
      
      [ Impact: cleanup ]
      Signed-off-by: default avatarYinghai Lu <yinghai@kernel.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
      Cc: Len Brown <lenb@kernel.org>
      LKML-Reference: <4A08ACD3.2070401@kernel.org>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      e5198075
  2. 12 May, 2009 3 commits
    • Cyrill Gorcunov's avatar
      x86/pci: add 4 more return parameters to IO_APIC_get_PCI_irq_vector(), fix · b5710ce9
      Cyrill Gorcunov authored
      Fix trivial typo in the drivers/pci/hotplug/ibmphp_core.c changes.
      
      [ Impact: build fix ]
      Signed-off-by: default avatarCyrill Gorcunov <gorcunov@openvz.org>
      CC: Yinghai Lu <yinghai@kernel.org>
      Cc: eswierk@aristanetworks.com
      LKML-Reference: <20090512145128.GA10220@lenovo>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      b5710ce9
    • Yinghai Lu's avatar
      x86: read apic ID in the !acpi_lapic case · 4797f6b0
      Yinghai Lu authored
      Ed found that on 32-bit, boot_cpu_physical_apicid is not read right,
      when the mptable is broken.
      
      Interestingly, actually three paths use/set it:
      
       1. acpi: at that time that is already read from reg
       2. mptable: only read from mptable
       3. no madt, and no mptable, that use default apic id 0 for 64-bit, -1 for 32-bit
      
      so we could read the apic id for the 2/3 path. We trust the hardware
      register more than we trust a BIOS data structure (the mptable).
      
      We can also avoid the double set_fixmap() when acpi_lapic
      is used, and also need to move cpu_has_apic earlier and
      call apic_disable().
      
      Also when need to update the apic id, we'd better read and
      set the apic version as well - so that quirks are applied precisely.
      
      v2: make path 3 with 64bit, use -1 as apic id, so could read it later.
      v3: fix whitespace problem pointed out by Ed Swierk
      v5: fix boot crash
      
      [ Impact: get correct apic id for bsp other than acpi path ]
      Reported-by: default avatarEd Swierk <eswierk@aristanetworks.com>
      Signed-off-by: default avatarYinghai Lu <yinghai@kernel.org>
      Acked-by: default avatarCyrill Gorcunov <gorcunov@openvz.org>
      LKML-Reference: <49FC85A9.2070702@kernel.org>
      [ v4: sanity-check in the ACPI case too ]
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      4797f6b0
    • Ingo Molnar's avatar
      Merge branch 'x86/apic' into irq/numa · 6cda3eb6
      Ingo Molnar authored
      Merge reason: both topics modify the APIC code but were able to do it in
                    parallel so far. An upcoming patch generates a conflict so
                    merge them to avoid the conflict.
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      6cda3eb6
  3. 11 May, 2009 12 commits
    • Cyrill Gorcunov's avatar
      x86: apic: Fixmap apic address even if apic disabled · cec6be6d
      Cyrill Gorcunov authored
      In case if apic were disabled by boot option
      we still need read_apic operation. So fixmap
      a fake apic area if needed.
      
      [ Impact: fix boot crash ]
      Signed-off-by: default avatarCyrill Gorcunov <gorcunov@openvz.org>
      Cc: yinghai@kernel.org
      Cc: eswierk@aristanetworks.com
      LKML-Reference: <20090511134140.GH4624@lenovo>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      cec6be6d
    • Andreas Herrmann's avatar
      x86: display extended apic registers with print_local_APIC and cpu_debug code · 97a52714
      Andreas Herrmann authored
      Both print_local_APIC (used when apic=debug kernel param is set) and
      cpu_debug code missed support for some extended APIC registers that
      I'd like to see.
      
      This adds support to show:
      
       - extended APIC feature register
       - extended APIC control register
       - extended LVT registers
      
      [ Impact: print more debug info ]
      Signed-off-by: default avatarAndreas Herrmann <andreas.herrmann3@amd.com>
      Cc: Jaswinder Singh Rajput <jaswinder@kernel.org>
      Cc: Cyrill Gorcunov <gorcunov@openvz.org>
      LKML-Reference: <20090508162350.GO29045@alberich.amd.com>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      97a52714
    • Yinghai Lu's avatar
      x86: read apic ID in the !acpi_lapic case · 4401da61
      Yinghai Lu authored
      Ed found that on 32-bit, boot_cpu_physical_apicid is not read right,
      when the mptable is broken.
      
      Interestingly, actually three paths use/set it:
      
       1. acpi: at that time that is already read from reg
       2. mptable: only read from mptable
       3. no madt, and no mptable, that use default apic id 0 for 64-bit, -1 for 32-bit
      
      so we could read the apic id for the 2/3 path. We trust the hardware
      register more than we trust a BIOS data structure (the mptable).
      
      We can also avoid the double set_fixmap() when acpi_lapic
      is used, and also need to move cpu_has_apic earlier and
      call apic_disable().
      
      Also when need to update the apic id, we'd better read and
      set the apic version as well - so that quirks are applied precisely.
      
      v2: make path 3 with 64bit, use -1 as apic id, so could read it later.
      v3: fix whitespace problem pointed out by Ed Swierk
      
      [ Impact: get correct apic id for bsp other than acpi path ]
      Reported-by: default avatarEd Swierk <eswierk@aristanetworks.com>
      Signed-off-by: default avatarYinghai Lu <yinghai@kernel.org>
      Acked-by: default avatarCyrill Gorcunov <gorcunov@openvz.org>
      LKML-Reference: <49FC85A9.2070702@kernel.org>
      [ v4: sanity-check in the ACPI case too ]
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      4401da61
    • Yinghai Lu's avatar
      x86: apic: Check rev 3 fadt correctly for physical_apic bit · 61fe91e1
      Yinghai Lu authored
      Impact: fix fadt version checking
      
      FADT2_REVISION_ID has value 3 aka rev 3 FADT. So need to use >= instead
      of >, as other places in the code do.
      
      [ Impact: extend scope of APIC boot quirk ]
      Signed-off-by: default avatarYinghai Lu <yinghai@kernel.org>
      LKML-Reference: <new-submission>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      61fe91e1
    • Yinghai Lu's avatar
      x86/pci: update pirq_enable_irq() to setup io apic routing · b9c61b70
      Yinghai Lu authored
      So we can set io apic routing only when enabling the device irq.
      
      This is advantageous for IRQ descriptor allocation affinity: if we set up
      the IO-APIC entry later, we have a chance to allocate the IRQ descriptor
      later and know which device it is on and can set affinity accordingly.
      
      [ Impact: standardize/enhance irq-enabling sequence for mptable irqs ]
      Signed-off-by: default avatarYinghai Lu <yinghai@kernel.org>
      Acked-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      Cc: Len Brown <lenb@kernel.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      LKML-Reference: <4A01C46E.8000501@kernel.org>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      b9c61b70
    • Yinghai Lu's avatar
      x86/acpi: move setup io apic routing out of CONFIG_ACPI scope · 5ef21837
      Yinghai Lu authored
      So we could set io apic routing when ACPI is not enabled.
      
      [ Impact: prepare for new functionality ]
      Signed-off-by: default avatarYinghai Lu <yinghai@kernel.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
      Cc: Len Brown <lenb@kernel.org>
      LKML-Reference: <4A01C422.5070400@kernel.org>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      5ef21837
    • Yinghai Lu's avatar
      x86/pci: add 4 more return parameters to IO_APIC_get_PCI_irq_vector() · e20c06fd
      Yinghai Lu authored
      To prepare those params for pcibios_irq_enable() to call setup_io_apic_routing().
      
      [ Impact: extend function call API to prepare for new functionality ]
      Signed-off-by: default avatarYinghai Lu <yinghai@kernel.org>
      Acked-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      Cc: Len Brown <lenb@kernel.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      LKML-Reference: <4A01C406.2040303@kernel.org>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      e20c06fd
    • Yinghai Lu's avatar
      x86/acpi: move pin_programmed bit map to io_apic.c · bdfe8ac1
      Yinghai Lu authored
      Prepare to call setup_io_apic_routing() in pcibios_irq_enable()
      also remove not needed member apic_id.
      
      [ Impact: clean up, prepare for future change ]
      Signed-off-by: default avatarYinghai Lu <yinghai@kernel.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
      Cc: Len Brown <lenb@kernel.org>
      LKML-Reference: <4A01C3DD.3050104@kernel.org>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      bdfe8ac1
    • Yinghai Lu's avatar
      x86/acpi: call mp_config_acpi_gsi() in mp_register_gsi() · a31f8205
      Yinghai Lu authored
      The patch to call mp_config_acpi_gsi() from the ACPI IRQ registration
      code never got mainline because there were open discussions about it.
      
      This call is needed to properly update the kernel's copy of the mptable,
      when the update_mptable boot parameter is needed.
      
      Now that the dust has settled with the APIC unification, and since there
      were no objections when the patch was re-submitted, try this again.
      
      [ Impact: fix the update_mptable boot parameter ]
      Signed-off-by: default avatarYinghai Lu <yinghai@kernel.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
      Cc: Len Brown <lenb@kernel.org>
      LKML-Reference: <4A01C387.7090103@kernel.org>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      a31f8205
    • Yinghai Lu's avatar
      x86: fix alloc_mptable() · ee214558
      Yinghai Lu authored
      Fix the conditions when we stop updating the mptable due to
      running out of slots.
      
      [ Impact: fix memory corruption / non-working update_mptable boot parameter ]
      Signed-off-by: default avatarYinghai Lu <yinghai@kernel.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
      Cc: Len Brown <lenb@kernel.org>
      LKML-Reference: <4A01C3BB.1000609@kernel.org>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      ee214558
    • Yinghai Lu's avatar
      x86/acpi: remove irq-compression trick on 32-bit · b9e0353f
      Yinghai Lu authored
      We already have a per cpu vector on 32-bit via recent changes, and
      don't need this trick any more (which trick obfuscates the real GSI
      mappings and which only triggers on larger systems to begin with):
      
      On 3 ioapic system (24 per ioapic) before patch I got:
      
      ACPI: PCI Interrupt Link [ILSB] enabled at IRQ 71
      IOAPIC[2]: Set routing entry (10-23 -> 0xa9 -> IRQ 64 Mode:1 Active:1)
      pci 0000:80:01.1: PCI INT A -> Link[ILSB] -> GSI 71 (level, low) -> IRQ 64
      ACPI: PCI Interrupt Link [LE5B] enabled at IRQ 67
      IOAPIC[2]: Set routing entry (10-19 -> 0xb1 -> IRQ 65 Mode:1 Active:1)
      pci 0000:83:00.0: PCI INT B -> Link[LE5B] -> GSI 67 (level, low) -> IRQ 65
      ACPI: PCI Interrupt Link [LE5A] enabled at IRQ 66
      IOAPIC[2]: Set routing entry (10-18 -> 0xb9 -> IRQ 66 Mode:1 Active:1)
      pci 0000:83:00.1: PCI INT A -> Link[LE5A] -> GSI 66 (level, low) -> IRQ 66
      ACPI: PCI Interrupt Link [LE5D] enabled at IRQ 65
      IOAPIC[2]: Set routing entry (10-17 -> 0xc1 -> IRQ 67 Mode:1 Active:1)
      pci 0000:84:00.0: PCI INT B -> Link[LE5D] -> GSI 65 (level, low) -> IRQ 67
      ACPI: PCI Interrupt Link [LE5C] enabled at IRQ 64
      IOAPIC[2]: Set routing entry (10-16 -> 0xc9 -> IRQ 68 Mode:1 Active:1)
      pci 0000:84:00.1: PCI INT A -> Link[LE5C] -> GSI 64 (level, low) -> IRQ 68
      pci 0000:87:00.0: PCI INT B -> Link[LE5A] -> GSI 66 (level, low) -> IRQ 66
      pci 0000:87:00.1: PCI INT A -> Link[LE5D] -> GSI 65 (level, low) -> IRQ 67
      pci 0000:88:00.0: PCI INT B -> Link[LE5C] -> GSI 64 (level, low) -> IRQ 68
      pci 0000:88:00.1: PCI INT A -> Link[LE5B] -> GSI 67 (level, low) -> IRQ 65
      pci 0000:8b:00.0: PCI INT B -> Link[LE5A] -> GSI 66 (level, low) -> IRQ 66
      pci 0000:8b:00.1: PCI INT A -> Link[LE5D] -> GSI 65 (level, low) -> IRQ 67
      pci 0000:8c:00.0: PCI INT B -> Link[LE5C] -> GSI 64 (level, low) -> IRQ 68
      pci 0000:8c:00.1: PCI INT A -> Link[LE5B] -> GSI 67 (level, low) -> IRQ 65
      
      after the patch we get:
      
      ACPI: PCI Interrupt Link [ILSB] enabled at IRQ 71
      IOAPIC[2]: Set routing entry (10-23 -> 0xa9 -> IRQ 71 Mode:1 Active:1)
      pci 0000:80:01.1: PCI INT A -> Link[ILSB] -> GSI 71 (level, low) -> IRQ 71
      ACPI: PCI Interrupt Link [LE5B] enabled at IRQ 67
      IOAPIC[2]: Set routing entry (10-19 -> 0xb1 -> IRQ 67 Mode:1 Active:1)
      pci 0000:83:00.0: PCI INT B -> Link[LE5B] -> GSI 67 (level, low) -> IRQ 67
      ACPI: PCI Interrupt Link [LE5A] enabled at IRQ 66
      IOAPIC[2]: Set routing entry (10-18 -> 0xb9 -> IRQ 66 Mode:1 Active:1)
      pci 0000:83:00.1: PCI INT A -> Link[LE5A] -> GSI 66 (level, low) -> IRQ 66
      ACPI: PCI Interrupt Link [LE5D] enabled at IRQ 65
      IOAPIC[2]: Set routing entry (10-17 -> 0xc1 -> IRQ 65 Mode:1 Active:1)
      pci 0000:84:00.0: PCI INT B -> Link[LE5D] -> GSI 65 (level, low) -> IRQ 65
      ACPI: PCI Interrupt Link [LE5C] enabled at IRQ 64
      IOAPIC[2]: Set routing entry (10-16 -> 0xc9 -> IRQ 64 Mode:1 Active:1)
      pci 0000:84:00.1: PCI INT A -> Link[LE5C] -> GSI 64 (level, low) -> IRQ 64
      pci 0000:87:00.0: PCI INT B -> Link[LE5A] -> GSI 66 (level, low) -> IRQ 66
      pci 0000:87:00.1: PCI INT A -> Link[LE5D] -> GSI 65 (level, low) -> IRQ 65
      pci 0000:88:00.0: PCI INT B -> Link[LE5C] -> GSI 64 (level, low) -> IRQ 64
      pci 0000:88:00.1: PCI INT A -> Link[LE5B] -> GSI 67 (level, low) -> IRQ 67
      pci 0000:8b:00.0: PCI INT B -> Link[LE5A] -> GSI 66 (level, low) -> IRQ 66
      pci 0000:8b:00.1: PCI INT A -> Link[LE5D] -> GSI 65 (level, low) -> IRQ 65
      pci 0000:8c:00.0: PCI INT B -> Link[LE5C] -> GSI 64 (level, low) -> IRQ 64
      pci 0000:8c:00.1: PCI INT A -> Link[LE5B] -> GSI 67 (level, low) -> IRQ 67
      
      As it can be seen that GSIs now get mapped lineary.
      
      [ Impact: simplify irq number mapping on bigger 32-bit systems ]
      Signed-off-by: default avatarYinghai Lu <yinghai@kernel.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
      Cc: Len Brown <lenb@kernel.org>
      LKML-Reference: <4A01C35C.7060207@kernel.org>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      b9e0353f
    • Ingo Molnar's avatar
      Merge commit 'v2.6.30-rc5' into x86/apic · 7a309490
      Ingo Molnar authored
      Merge reason: this branch was on a .30-rc2 base - sync it up with
                    all the latest fixes.
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      7a309490
  4. 09 May, 2009 2 commits
  5. 08 May, 2009 14 commits
  6. 07 May, 2009 8 commits
    • David Howells's avatar
      NOMMU: Don't check vm_region::vm_start is page aligned in add_nommu_region() · 8c9ed899
      David Howells authored
      Don't check vm_region::vm_start is page aligned in add_nommu_region() because
      the region may reflect some non-page-aligned mapped file, such as could be
      obtained from RomFS XIP.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Acked-by: default avatarGreg Ungerer <gerg@uclinux.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      8c9ed899
    • Linus Torvalds's avatar
      Merge branch 'for-linus' of git://neil.brown.name/md · ee7fee0b
      Linus Torvalds authored
      * 'for-linus' of git://neil.brown.name/md:
        md: remove rd%d links immediately after stopping an array.
        md: remove ability to explicit set an inactive array to 'clean'.
        md: constify VFTs
        md: tidy up status_resync to handle large arrays.
        md: fix some (more) errors with bitmaps on devices larger than 2TB.
        md/raid10: don't clear bitmap during recovery if array will still be degraded.
        md: fix loading of out-of-date bitmap.
      ee7fee0b
    • Linus Torvalds's avatar
      random: make get_random_int() more random · 8a0a9bd4
      Linus Torvalds authored
      It's a really simple patch that basically just open-codes the current
      "secure_ip_id()" call, but when open-coding it we now use a _static_
      hashing area, so that it gets updated every time.
      
      And to make sure somebody can't just start from the same original seed of
      all-zeroes, and then do the "half_md4_transform()" over and over until
      they get the same sequence as the kernel has, each iteration also mixes in
      the same old "current->pid + jiffies" we used - so we should now have a
      regular strong pseudo-number generator, but we also have one that doesn't
      have a single seed.
      
      Note: the "pid + jiffies" is just meant to be a tiny tiny bit of noise. It
      has no real meaning. It could be anything. I just picked the previous
      seed, it's just that now we keep the state in between calls and that will
      feed into the next result, and that should make all the difference.
      
      I made that hash be a per-cpu data just to avoid cache-line ping-pong:
      having multiple CPU's write to the same data would be fine for randomness,
      and add yet another layer of chaos to it, but since get_random_int() is
      supposed to be a fast interface I did it that way instead. I considered
      using "__raw_get_cpu_var()" to avoid any preemption overhead while still
      getting the hash be _mostly_ ping-pong free, but in the end good taste won
      out.
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      8a0a9bd4
    • Linus Torvalds's avatar
      Merge master.kernel.org:/home/rmk/linux-2.6-arm · 2c66fa7e
      Linus Torvalds authored
      * master.kernel.org:/home/rmk/linux-2.6-arm:
        [ARM] 5507/1: support R_ARM_MOVW_ABS_NC and MOVT_ABS relocation types
        [ARM] 5506/1: davinci: DMA_32BIT_MASK --> DMA_BIT_MASK(32)
        i.MX31: Disable CPU_32v6K in mx3_defconfig.
        mx3fb: Fix compilation with CONFIG_PM
        mx27ads: move PBC mapping out of vmalloc space
        MXC: remove BUG_ON in interrupt handler
        mx31: remove mx31moboard_defconfig
        ARM: ARCH_MXC should select HAVE_CLK
        mxc : BUG in imx_dma_request
        mxc : Clean up properly when imx_dma_free() used without imx_dma_disable()
        [ARM] mv78xx0: update defconfig
        [ARM] orion5x: update defconfig
        [ARM] Kirkwood: update defconfig
        [ARM] Kconfig typo fix:  "PXA930" -> "CPU_PXA930".
        [ARM] S3C2412: Add missing cache flush in suspend code
        [ARM] S3C: Add UDIVSLOT support for newer UARTS
        [ARM] S3C64XX: Add S3C64XX_PA_IIS{0,1} to <mach/map.h>
      2c66fa7e
    • Paul Gortmaker's avatar
      [ARM] 5507/1: support R_ARM_MOVW_ABS_NC and MOVT_ABS relocation types · ae51e609
      Paul Gortmaker authored
      From: Bruce Ashfield <bruce.ashfield@windriver.com>
      
      To fully support the armv7-a instruction set/optimizations, support
      for the R_ARM_MOVW_ABS_NC and R_ARM_MOVT_ABS relocation types is
      required.
      
      The MOVW and MOVT are both load-immediate instructions, MOVW loads 16
      bits into the bottom half of a register, and MOVT loads 16 bits into the
      top half of a register.
      
      The relocation information for these instructions has a full 32 bit
      value, plus an addend which is stored in the 16 immediate bits in the
      instruction itself.  The immediate bits in the instruction are not
      contiguous (the register # splits it into a 4 bit and 12 bit value),
      so the addend has to be extracted accordingly and added to the value.
      The value is then split and put into the instruction; a MOVW uses the
      bottom 16 bits of the value, and a MOVT uses the top 16 bits.
      Signed-off-by: default avatarDavid Borman <david.borman@windriver.com>
      Signed-off-by: default avatarBruce Ashfield <bruce.ashfield@windriver.com>
      Signed-off-by: default avatarPaul Gortmaker <paul.gortmaker@windriver.com>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      ae51e609
    • Kevin Hilman's avatar
      [ARM] 5506/1: davinci: DMA_32BIT_MASK --> DMA_BIT_MASK(32) · a029b706
      Kevin Hilman authored
      As per commit 284901a9, use
      DMA_BIT_MASK(n)
      Signed-off-by: default avatarKevin Hilman <khilman@deeprootsystems.com>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      a029b706
    • NeilBrown's avatar
      md: remove rd%d links immediately after stopping an array. · c4647292
      NeilBrown authored
      md maintains link in sys/mdXX/md/ to identify which device has
      which role in the array. e.g.
         rd2 -> dev-sda
      
      indicates that the device with role '2' in the array is sda.
      
      These links are only present when the array is active.  They are
      created immediately after ->run is called, and so should be removed
      immediately after ->stop is called.
      However they are currently removed a little bit later, and it is
      possible for ->run to be called again, thus adding these links, before
      they are removed.
      
      So move the removal earlier so they are consistently only present when
      the array is active.
      Signed-off-by: default avatarNeilBrown <neilb@suse.de>
      c4647292
    • NeilBrown's avatar
      md: remove ability to explicit set an inactive array to 'clean'. · 5bf29597
      NeilBrown authored
      Being able to write 'clean' to an 'array_state' of an inactive array
      to activate it in 'clean' mode is both unnecessary and inconvenient.
      
      It is unnecessary because the same can be achieved by writing
      'active'.  This activates and array, but it still remains 'clean'
      until the first write.
      
      It is inconvenient because writing 'clean' is more often used to
      cause an 'active' array to revert to 'clean' mode (thus blocking
      any writes until a 'write-pending' is promoted to 'active').
      
      Allowing 'clean' to both activate an array and mark an active array as
      clean can lead to races:  One program writes 'clean' to mark the
      active array as clean at the same time as another program writes
      'inactive' to deactivate (stop) and active array.  Depending on which
      writes first, the array could be deactivated and immediately
      reactivated which isn't what was desired.
      
      So just disable the use of 'clean' to activate an array.
      
      This avoids a race that can be triggered with mdadm-3.0 and external
      metadata, so it suitable for -stable.
      Reported-by: default avatarRafal Marszewski <rafal.marszewski@intel.com>
      Acked-by: default avatarDan Williams <dan.j.williams@intel.com>
      Cc: <stable@kernel.org>
      Signed-off-by: default avatarNeilBrown <neilb@suse.de>
      5bf29597