1. 04 6月, 2011 8 次提交
  2. 03 6月, 2011 8 次提交
  3. 02 6月, 2011 9 次提交
  4. 01 6月, 2011 15 次提交
    • L
      Merge git://git.infradead.org/mtd-2.6 · 3f303103
      Linus Torvalds 提交于
      * git://git.infradead.org/mtd-2.6:
        mtd: fix physmap.h warnings
      3f303103
    • D
      intel-iommu: Fix off-by-one in RMRR setup · 70e535d1
      David Woodhouse 提交于
      We were mapping an extra byte (and hence usually an extra page):
      iommu_prepare_identity_map() expects to be given an 'end' argument which
      is the last byte to be mapped; not the first byte *not* to be mapped.
      Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>
      70e535d1
    • M
      intel-iommu: Add domain check in domain_remove_one_dev_info · 8519dc44
      Mike Habeck 提交于
      The comment in domain_remove_one_dev_info() states "No need to compare
      PCI domain; it has to be the same". But for the si_domain that isn't
      going to be true, as it consists of all the PCI devices that are
      identity mapped thus multiple PCI domains can be in si_domain.  The
      code needs to validate the PCI domain too.
      Signed-off-by: NMike Habeck <habeck@sgi.com>
      Signed-off-by: NMike Travis <travis@sgi.com>
      Cc: stable@kernel.org
      Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>
      8519dc44
    • M
      intel-iommu: Remove Host Bridge devices from identity mapping · 825507d6
      Mike Travis 提交于
      When using the 1:1 (identity) PCI DMA remapping, PCI Host Bridge devices
      that do not use the IOMMU causes a kernel panic.  Fix that by not
      inserting those devices into the si_domain.
      Signed-off-by: NMike Travis <travis@sgi.com>
      Reviewed-by: NMike Habeck <habeck@sgi.com>
      Cc: stable@kernel.org
      Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>
      825507d6
    • M
      intel-iommu: Use coherent DMA mask when requested · c681d0ba
      Mike Travis 提交于
      The __intel_map_single function is not honoring the passed in DMA mask.
      This results in not using the coherent DMA mask when called from
      intel_alloc_coherent().
      Signed-off-by: NMike Travis <travis@sgi.com>
      Acked-by: NChris Wright <chrisw@sous-sol.org>
      Reviewed-by: NMike Habeck <habeck@sgi.com>
      Cc: stable@kernel.org
      Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>
      c681d0ba
    • C
      intel-iommu: Dont cache iova above 32bit · 1c9fc3d1
      Chris Wright 提交于
      Mike Travis and Mike Habeck reported an issue where iova allocation
      would return a range that was larger than a device's dma mask.
      
      https://lkml.org/lkml/2011/3/29/423
      
      The dmar initialization code will reserve all PCI MMIO regions and copy
      those reservations into a domain specific iova tree.  It is possible for
      one of those regions to be above the dma mask of a device.  It is typical
      to allocate iovas with a 32bit mask (despite device's dma mask possibly
      being larger) and cache the result until it exhausts the lower 32bit
      address space.  Freeing the iova range that is >= the last iova in the
      lower 32bit range when there is still an iova above the 32bit range will
      corrupt the cached iova by pointing it to a region that is above 32bit.
      If that region is also larger than the device's dma mask, a subsequent
      allocation will return an unusable iova and cause dma failure.
      
      Simply don't cache an iova that is above the 32bit caching boundary.
      Reported-by: NMike Travis <travis@sgi.com>
      Reported-by: NMike Habeck <habeck@sgi.com>
      Cc: stable@kernel.org
      Acked-by: NMike Travis <travis@sgi.com>
      Tested-by: NMike Habeck <habeck@sgi.com>
      Signed-off-by: NChris Wright <chrisw@sous-sol.org>
      Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>
      1c9fc3d1
    • M
      intel-iommu: Speed up processing of the identity_mapping function · cb452a40
      Mike Travis 提交于
      When there are a large count of PCI devices, and the pass through
      option for iommu is set, much time is spent in the identity_mapping
      function hunting though the iommu domains to check if a specific
      device is "identity mapped".
      
      Speed up the function by checking the cached info to see if
      it's mapped to the static identity domain.
      Signed-off-by: NMike Travis <travis@sgi.com>
      Reviewed-by: NMike Habeck <habeck@sgi.com>
      Cc: stable@kernel.org
      Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>
      cb452a40
    • C
      intel-iommu: Check for identity mapping candidate using system dma mask · 8fcc5372
      Chris Wright 提交于
      The identity mapping code appears to make the assumption that if the
      devices dma_mask is greater than 32bits the device can use identity
      mapping.  But that is not true: take the case where we have a 40bit
      device in a 44bit architecture. The device can potentially receive a
      physical address that it will truncate and cause incorrect addresses
      to be used.
      
      Instead check to see if the device's dma_mask is large enough
      to address the system's dma_mask.
      Signed-off-by: NMike Travis <travis@sgi.com>
      Reviewed-by: NMike Habeck <habeck@sgi.com>
      Cc: stable@kernel.org
      Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>
      8fcc5372
    • A
      intel-iommu: Only unlink device domains from iommu · 9b4554b2
      Alex Williamson 提交于
      Commit a97590e5 added unlinking domains from iommus to reciprocate the
      iommu from domains unlinking that was already done.  We actually want
      to only do this for device domains and never for the static
      identity map domain or VM domains.  The SI domain is special and
      never freed, while VM domain->id lives in their own special address
      space, separate from iommu->domain_ids.
      
      In the current code, a VM can get domain->id zero, then mark that
      domain unused when unbound from pci-stub.  This leads to DMAR
      write faults when the device is re-bound to the host driver.
      Signed-off-by: NAlex Williamson <alex.williamson@redhat.com>
      Cc: stable@kernel.org
      Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>
      9b4554b2
    • Y
      intel-iommu: Enable super page (2MiB, 1GiB, etc.) support · 6dd9a7c7
      Youquan Song 提交于
      There are no externally-visible changes with this. In the loop in the
      internal __domain_mapping() function, we simply detect if we are mapping:
        - size >= 2MiB, and
        - virtual address aligned to 2MiB, and
        - physical address aligned to 2MiB, and
        - on hardware that supports superpages.
      
      (and likewise for larger superpages).
      
      We automatically use a superpage for such mappings. We never have to
      worry about *breaking* superpages, since we trust that we will always
      *unmap* the same range that was mapped. So all we need to do is ensure
      that dma_pte_clear_range() will also cope with superpages.
      
      Adjust pfn_to_dma_pte() to take a superpage 'level' as an argument, so
      it can return a PTE at the appropriate level rather than always
      extending the page tables all the way down to level 1. Again, this is
      simplified by the fact that we should never encounter existing small
      pages when we're creating a mapping; any old mapping that used the same
      virtual range will have been entirely removed and its obsolete page
      tables freed.
      
      Provide an 'intel_iommu=sp_off' argument on the command line as a
      chicken bit. Not that it should ever be required.
      
      ==
      
      The original commit seen in the iommu-2.6.git was Youquan's
      implementation (and completion) of my own half-baked code which I'd
      typed into an email. Followed by half a dozen subsequent 'fixes'.
      
      I've taken the unusual step of rewriting history and collapsing the
      original commits in order to keep the main history simpler, and make
      life easier for the people who are going to have to backport this to
      older kernels. And also so I can give it a more coherent commit comment
      which (hopefully) gives a better explanation of what's going on.
      
      The original sequence of commits leading to identical code was:
      
      Youquan Song (3):
            intel-iommu: super page support
            intel-iommu: Fix superpage alignment calculation error
            intel-iommu: Fix superpage level calculation error in dma_pfn_level_pte()
      
      David Woodhouse (4):
            intel-iommu: Precalculate superpage support for dmar_domain
            intel-iommu: Fix hardware_largepage_caps()
            intel-iommu: Fix inappropriate use of superpages in __domain_mapping()
            intel-iommu: Fix phys_pfn in __domain_mapping for sglist pages
      Signed-off-by: NYouquan Song <youquan.song@intel.com>
      Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>
      6dd9a7c7
    • R
      mtd: fix physmap.h warnings · 63da0290
      Randy Dunlap 提交于
      Fix build warnings in physmap.h:
      
      include/linux/mtd/physmap.h:25: warning: 'struct platform_device' declared inside parameter list
      include/linux/mtd/physmap.h:25: warning: its scope is only this definition or declaration, which is probably not what you want
      include/linux/mtd/physmap.h:26: warning: 'struct platform_device' declared inside parameter list
      include/linux/mtd/physmap.h:27: warning: 'struct platform_device' declared inside parameter list
      Signed-off-by: NRandy Dunlap <randy.dunlap@oracle.com>
      Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>
      63da0290
    • A
      UBIFS: fix recovery broken by the previous recovery fix · da8b94ea
      Artem Bityutskiy 提交于
      Unfortunately, the recovery fix d1606a59b6be4ea392eabd40d1250aa1eeb19efb
      (UBIFS: fix extremely rare mount failure) broke recovery. This commit make
      UBIFS drop the last min. I/O unit in all journal heads, but this is needed only
      for the GC head. And this does not work for non-GC heads. For example, if
      suppose we have min. I/O units A and B, and A contains a valid node X, which
      was fsynced, and then a group of nodes Y which spans the rest of A and B. In
      this case we'll drop not only Y, but also X, which is obviously incorrect.
      
      This patch fixes the issue and additionally makes recovery to drop last min.
      I/O unit only for the GC head, and leave things as they have been for ages for
      the other heads - this is safer.
      Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
      da8b94ea
    • A
      UBIFS: amend ubifs_recover_leb interface · efcfde54
      Artem Bityutskiy 提交于
      Instead of passing "grouped" parameter to 'ubifs_recover_leb()' which tells
      whether the nodes are grouped in the LEB to recover, pass the journal head
      number and let 'ubifs_recover_leb()' look at the journal head's 'grouped' flag.
      
      This patch is a preparation to a further fix where we'll need to know the
      journal head number for other purposes.
      Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
      efcfde54
    • A
      UBIFS: introduce a "grouped" journal head flag · 1a0b0699
      Artem Bityutskiy 提交于
      Journal heads are different in a way how UBIFS writes nodes there. All normal
      journal heads receive grouped nodes, while the GC journal heads receives
      ungrouped nodes. This patch adds a 'grouped' flag to 'struct ubifs_jhead' which
      describes this property.
      
      This patch is a preparation to a further recovery fix.
      Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
      1a0b0699
    • A
      UBIFS: supress false error messages · ab75950b
      Artem Bityutskiy 提交于
      Commit ab51afe05273741f72383529ef488aa1ea598ec6 was a good clean-up, but
      it introduced a regression - now UBIFS prints scary error messages during
      recovery on all corrupted nodes, even though the corruptions are expected
      (due to a power cut). This patch fixes the issue.
      
      Additionally fix a typo in a commentary introduced by the same commit.
      Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
      ab75950b