1. 01 Apr, 2004 11 commits
    • Andrew Morton's avatar
      [PATCH] loop setup calling bd_set_size too soon · 840d5d40
      Andrew Morton authored
      From: Chris Mason <mason@suse.com>
      
      I think Andrew and I managed to mismerge the loop setup race fix. 
      loop_set_fd is using get_capacity() to read the size of the disk and
      sending that to bd_set_size.
      
      But, it is doing this before calling set_capacity, so the size being used
      is wrong.  This should clean things up.
      840d5d40
    • Andrew Morton's avatar
      [PATCH] Replace MAX_MAP_COUNT with /proc/sys/vm/max_map_count · 56d93842
      Andrew Morton authored
      From: David Mosberger <davidm@napali.hpl.hp.com>
      
      Below is a warmed up version of a patch originally done by Werner Almesberger
      (see http://tinyurl.com/25zra) to replace the MAX_MAP_COUNT limit with a
      sysctl variable.  I thought this had gone into the tree a long time ago but
      alas it has not and as luck would have it, the hard limit bit someone today
      once again with a large app on a large machine.
      
      Here is a small test app:
      56d93842
    • Andrew Morton's avatar
      [PATCH] ksoftirqd: missing barrier · bc5c1743
      Andrew Morton authored
      Spotted by Andrea: we need the barriers in there to prevent reads passing
      ahead of the setting of current->state.
      bc5c1743
    • Andrew Morton's avatar
      [PATCH] remove __ARCH_SI_BAND_T · e5f64bc8
      Andrew Morton authored
      All architectures now make this `long', so we can remove the arch override.
      e5f64bc8
    • Andrew Morton's avatar
      [PATCH] Fix hugetlb-vs-memory overcommit · c1c0d518
      Andrew Morton authored
      From: Andy Whitcroft <apw@shadowen.org>
      
      Two problems:
      
      a) The memory overcommit code fails oto take into account all the pages
         which are pinned by being reserved for the hugetlbpage pool
      
      b) We're performing overcommit accounting and checking on behalf of
         hugetlbpage vmas.
      
      The main thrust is to ensure that VM_ACCOUNT actually only gets set on
      vma's which are indeed accountable.  With that ensured much of the rest
      comes out in the wash.  It also removes the hugetlb memory for the
      overcommit_memory=2 case.
      c1c0d518
    • Andrew Morton's avatar
      [PATCH] siginfo.si_band is long · 112347bb
      Andrew Morton authored
      From: Marcus Meissner <meissner@suse.de>
      
      After discussion on the glibc list the result was that=20 si_band is "long
      int" according to POSIX:
      
      	http://www.opengroup.org/onlinepubs/007904975/basedefs/signal.h.html
      
      Ulrich Drepper refused a patch to fix glibc due to this reason:
      	http://sources.redhat.com/ml/libc-alpha/2004-03/msg00254.html
      
      so here is the patch to fix it in the kernel.
      
      ppc64 and s390x were broken before and are fixed by this patch too.
      112347bb
    • Andrew Morton's avatar
      [PATCH] ppc64: add useful warning message in hugepage code · 8d507e4e
      Andrew Morton authored
      From: David Gibson <david@gibson.dropbear.id.au>
      
      This patch adds a debugging message to the ppc64 hugepage code when we
      attempt to open the "low" (32-bit) hugepage window on PPC64, but can't
      because a (non-hugepage) mapping already exists in the region.
      8d507e4e
    • Andrew Morton's avatar
      [PATCH] ppc64: allow MAP_FIXED hugepage mappings · e9acfc13
      Andrew Morton authored
      From: David Gibson <david@gibson.dropbear.id.au>
      
      On PowerPC64 the "low" hugepage range (at 2-3G for use by 32-bit processes)
      needs to be activated before it can be used.  hugetlb_get_unmapped_area()
      automatically activates the range for hugepage mappings in 32-bit processes
      which are not MAP_FIXED.  However for MAP_FIXED mmap()s, even at a suitable
      address will fail if the region is not already activated, because there is
      no suitable callback from the generic MAP_FIXED code path into the arch
      code.
      
      This patch corrects this problem and allows PPC64 to do MAP_FIXED hugepage
      mappings in the low hugepage range.
      e9acfc13
    • Andrew Morton's avatar
      [PATCH] ppc64: bugfix for hugepage support · ccfcbaed
      Andrew Morton authored
      From: David Gibson <david@gibson.dropbear.id.au>
      
      Due to a misunderstanding of pmd_offset() the PPC64 hugepage code could end
      up looking at bogus pages as if they were PMD pages.
      ccfcbaed
    • Andrew Morton's avatar
      [PATCH] ppc64: create dma_mapping_error · 007658d4
      Andrew Morton authored
      From: Anton Blanchard <anton@samba.org>
      
      From: Stephen Rothwell <sfr@canb.auug.org.au>
      
      This creates DMA_ERROR_CODE and uses it everywhere instead of
      PCI_DMA_ERROR_CODE as we really want the three DMA mapping API's to return
      a single error code.  Also we now have dma_mapping_error and
      vio_dma_mapping_error - and this latter and pci_dma_mapping_error both just
      call the former.
      
      Also a small fix in the vscsi - dma_map_sg returns 0 to indicate an error.
      007658d4
    • Andrew Morton's avatar
      [PATCH] PPC32 build fix · a460c410
      Andrew Morton authored
      From: Matt Porter <mporter@kernel.crashing.org>
      
      This fixes the build on non cache coherent PPC32 platforms.
      a460c410
  2. 31 Mar, 2004 2 commits
  3. 01 Apr, 2004 1 commit
  4. 31 Mar, 2004 4 commits
  5. 01 Apr, 2004 16 commits
  6. 31 Mar, 2004 6 commits