1. 19 May, 2009 1 commit
    • Stephen Smalley's avatar
      selinux: remove obsolete read buffer limit from sel_read_bool · c5642f4b
      Stephen Smalley authored
      
      On Tue, 2009-05-19 at 00:05 -0400, Eamon Walsh wrote:
      > Recent versions of coreutils have bumped the read buffer size from 4K to
      > 32K in several of the utilities.
      >
      > This means that "cat /selinux/booleans/xserver_object_manager" no longer
      > works, it returns "Invalid argument" on F11.  getsebool works fine.
      >
      > sel_read_bool has a check for "count > PAGE_SIZE" that doesn't seem to
      > be present in the other read functions.  Maybe it could be removed?
      
      Yes, that check is obsoleted by the conversion of those functions to
      using simple_read_from_buffer(), which will reduce count if necessary to
      what is available in the buffer.
      Signed-off-by: default avatarStephen Smalley <sds@tycho.nsa.gov>
      Signed-off-by: default avatarJames Morris <jmorris@namei.org>
      c5642f4b
  2. 18 May, 2009 1 commit
  3. 14 May, 2009 2 commits
  4. 13 May, 2009 1 commit
    • Eric Paris's avatar
      TPM: get_event_name stack corruption · b1033870
      Eric Paris authored
      
      get_event_name uses sprintf to fill a buffer declared on the stack.  It fills
      the buffer 2 bytes at a time.  What the code doesn't take into account is that
      sprintf(buf, "%02x", data) actually writes 3 bytes.  2 bytes for the data and
      then it nul terminates the string.  Since we declare buf to be 40 characters
      long and then we write 40 bytes of data into buf sprintf is going to write 41
      characters.  The fix is to leave room in buf for the nul terminator.
      Signed-off-by: default avatarEric Paris <eparis@redhat.com>
      Signed-off-by: default avatarJames Morris <jmorris@namei.org>
      b1033870
  5. 11 May, 2009 4 commits
  6. 10 May, 2009 2 commits
  7. 08 May, 2009 1 commit
  8. 07 May, 2009 6 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
  9. 06 May, 2009 22 commits
    • 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
    • Jan Engelhardt's avatar
      md: constify VFTs · 110518bc
      Jan Engelhardt authored
      Signed-off-by: default avatarJan Engelhardt <jengelh@medozas.de>
      Signed-off-by: default avatarNeilBrown <neilb@suse.de>
      110518bc
    • NeilBrown's avatar
      md: tidy up status_resync to handle large arrays. · dd71cf6b
      NeilBrown authored
      
      Two problems in status_resync.
      1/ It still used Kilobytes as the basic block unit, while most code
         now uses sectors uniformly.
      2/ It doesn't allow for the possibility that max_sectors exceeds
         the range of "unsigned long".
      
      So
       - change "max_blocks" to "max_sectors", and store sector numbers
         in there and in 'resync'
       - Make 'rt' a 'sector_t' so it can temporarily hold the number of
         remaining sectors.
       - use sector_div rather than normal division.
       - change the magic '100' used to preserve precision to '32'.
         + making it a power of 2 makes division easier
         + it doesn't need to be as large as it was chosen when we averaged
           speed over the entire run.  Now we average speed over the last 30
           seconds or so.
      Reported-by: default avatar"Mario 'BitKoenig' Holbe" <Mario.Holbe@TU-Ilmenau.DE>
      Signed-off-by: default avatarNeilBrown <neilb@suse.de>
      dd71cf6b
    • NeilBrown's avatar
      md: fix some (more) errors with bitmaps on devices larger than 2TB. · db305e50
      NeilBrown authored
      
      If a write intent bitmap covers more than 2TB, we sometimes work with
      values beyond 32bit, so these need to be sector_t.  This patches
      add the required casts to some unsigned longs that are being shifted
      up.
      
      This will affect any raid10 larger than 2TB, or any raid1/4/5/6 with
      member devices that are larger than 2TB.
      Signed-off-by: default avatarNeilBrown <neilb@suse.de>
      Reported-by: default avatar"Mario 'BitKoenig' Holbe" <Mario.Holbe@TU-Ilmenau.DE>
      Cc: stable@kernel.org
      db305e50
    • NeilBrown's avatar
      md/raid10: don't clear bitmap during recovery if array will still be degraded. · 18055569
      NeilBrown authored
      
      If we have a raid10 with multiple missing devices, and we recover just
      one of these to a spare, then we risk (depending on the bitmap and
      array chunk size) clearing bits of the bitmap for which recovery isn't
      complete (because a device is still missing).
      
      This can lead to a subsequent "re-add" being recovered without
      any IO happening, which would result in loss of data.
      
      This patch takes the safe approach of not clearing bitmap bits
      if the array will still be degraded.
      
      This patch is suitable for all active -stable kernels.
      
      Cc: stable@kernel.org
      Signed-off-by: default avatarNeilBrown <neilb@suse.de>
      18055569
    • NeilBrown's avatar
      md: fix loading of out-of-date bitmap. · b74fd282
      NeilBrown authored
      
      When md is loading a bitmap which it knows is out of date, it fills
      each page with 1s and writes it back out again.  However the
      write_page call makes used of bitmap->file_pages and
      bitmap->last_page_size which haven't been set correctly yet.  So this
      can sometimes fail.
      
      Move the setting of file_pages and last_page_size to before the call
      to write_page.
      
      This bug can cause the assembly on an array to fail, thus making the
      data inaccessible.  Hence I think it is a suitable candidate for
      -stable.
      
      Cc: stable@kernel.org
      Reported-by: default avatarVojtech Pavlik <vojtech@suse.cz>
      Signed-off-by: default avatarNeilBrown <neilb@suse.de>
      b74fd282
    • Andrew Morton's avatar
      drivers/base/iommu.c: add missing includes · 60db4027
      Andrew Morton authored
      
      Fix zillions of -mm x86_64 allmodconfig build errors - the file uses
      EXPORT_SYMBOL() and kmalloc but misses the needed includes.
      
      Cc: Greg Kroah-Hartman <gregkh@suse.de>
      Cc: Joerg Roedel <joerg.roedel@amd.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      60db4027
    • Eric Piel's avatar
      initramfs: clean up messages related to initramfs unpacking · a1e6b6c1
      Eric Piel authored
      With the removal of duplicate unpack_to_rootfs() (commit
      df52092f
      
      ) the messages displayed do not
      actually correspond to what the kernel is doing.  In addition, depending
      if ramdisks are supported or not, the messages are not at all the same.
      
      So keep the messages more in sync with what is really doing the kernel,
      and only display a second message in case of failure.  This also ensure
      that the printk message cannot be split by other printk's.
      Signed-off-by: default avatarEric Piel <eric.piel@tremplin-utc.net>
      Acked-by: default avatarH. Peter Anvin <hpa@zytor.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      a1e6b6c1
    • David Howells's avatar
      nommu: make the initial mmap allocation excess behaviour Kconfig configurable · fc4d5c29
      David Howells authored
      
      NOMMU mmap() has an option controlled by a sysctl variable that determines
      whether the allocations made by do_mmap_private() should have the excess
      space trimmed off and returned to the allocator.  Make the initial setting
      of this variable a Kconfig configuration option.
      
      The reason there can be excess space is that the allocator only allocates
      in power-of-2 size chunks, but mmap()'s can be made in sizes that aren't a
      power of 2.
      
      There are two alternatives:
      
       (1) Keep the excess as dead space.  The dead space then remains unused for the
           lifetime of the mapping.  Mappings of shared objects such as libc, ld.so
           or busybox's text segment may retain their dead space forever.
      
       (2) Return the excess to the allocator.  This means that the dead space is
           limited to less than a page per mapping, but it means that for a transient
           process, there's more chance of fragmentation as the excess space may be
           reused fairly quickly.
      
      During the boot process, a lot of transient processes are created, and
      this can cause a lot of fragmentation as the pagecache and various slabs
      grow greatly during this time.
      
      By turning off the trimming of excess space during boot and disabling
      batching of frees, Coldfire can manage to boot.
      
      A better way of doing things might be to have /sbin/init turn this option
      off.  By that point libc, ld.so and init - which are all long-duration
      processes - have all been loaded and trimmed.
      Reported-by: default avatarLanttor Guo <lanttor.guo@freescale.com>
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Tested-by: default avatarLanttor Guo <lanttor.guo@freescale.com>
      Cc: Greg Ungerer <gerg@snapgear.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      fc4d5c29
    • David Howells's avatar
      nommu: clamp zone_batchsize() to 0 under NOMMU conditions · 3a6be87f
      David Howells authored
      
      Clamp zone_batchsize() to 0 under NOMMU conditions to stop
      free_hot_cold_page() from queueing and batching frees.
      
      The problem is that under NOMMU conditions it is really important to be
      able to allocate large contiguous chunks of memory, but when munmap() or
      exit_mmap() releases big stretches of memory, return of these to the buddy
      allocator can be deferred, and when it does finally happen, it can be in
      small chunks.
      
      Whilst the fragmentation this incurs isn't so much of a problem under MMU
      conditions as userspace VM is glued together from individual pages with
      the aid of the MMU, it is a real problem if there isn't an MMU.
      
      By clamping the page freeing queue size to 0, pages are returned to the
      allocator immediately, and the buddy detector is more likely to be able to
      glue them together into large chunks immediately, and fragmentation is
      less likely to occur.
      
      By disabling batching of frees, and by turning off the trimming of excess
      space during boot, Coldfire can manage to boot.
      Reported-by: default avatarLanttor Guo <lanttor.guo@freescale.com>
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Tested-by: default avatarLanttor Guo <lanttor.guo@freescale.com>
      Cc: Greg Ungerer <gerg@snapgear.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      3a6be87f
    • David Howells's avatar
      mm: use roundown_pow_of_two() in zone_batchsize() · 9155203a
      David Howells authored
      
      Use roundown_pow_of_two(N) in zone_batchsize() rather than (1 <<
      (fls(N)-1)) as they are equivalent, and with the former it is easier to
      see what is going on.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Tested-by: default avatarLanttor Guo <lanttor.guo@freescale.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      9155203a
    • Daniel Mack's avatar
      isl29003: fix resume functionality · 74614f8d
      Daniel Mack authored
      
      The isl29003 does not interpret the return value of
      i2c_smbus_write_byte_data() correctly and hence causes an error on system
      resume.
      
      Also introduce power_state_before_suspend and restore the chip's power
      state upon wakeup.
      Signed-off-by: default avatarDaniel Mack <daniel@caiaq.de>
      Cc: "Rafael J. Wysocki" <rjw@sisk.pl>
      Cc: Jean Delvare <khali@linux-fr.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      74614f8d
    • Krzysztof Helt's avatar
      fbdev: remove makefile reference to removed driver · 57226e78
      Krzysztof Helt authored
      
      The cyblafb driver is removed so remove its last trace in the makefile.
      Signed-off-by: default avatarKrzysztof Helt <krzysztof.h1@wp.pl>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      57226e78
    • Ralph Wuerthner's avatar
      alloc_vmap_area: fix memory leak · 2498ce42
      Ralph Wuerthner authored
      
      If alloc_vmap_area() fails the allocated struct vmap_area has to be freed.
      Signed-off-by: default avatarRalph Wuerthner <ralphw@linux.vnet.ibm.com>
      Reviewed-by: default avatarChristoph Lameter <cl@linux-foundation.org>
      Reviewed-by: default avatarMinchan Kim <minchan.kim@gmail.com>
      Cc: Nick Piggin <npiggin@suse.de>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      2498ce42
    • Randy Dunlap's avatar
      doc: small kernel-parameters updates · ca1eda2d
      Randy Dunlap authored
      
      Change last "i386" to X86-32 as is used throughout the rest of the file.
      Change combination of X86-32,X86-64 to just X86, as is done throughout the
      rest of the file.
      
      Add a note that hyphens and underscores are equivalent in parameter names,
      with examples.
      Signed-off-by: default avatarRandy Dunlap <randy.dunlap@oracle.com>
      Cc: Jan Engelhardt <jengelh@medozas.de>
      Cc: Christopher Sylvain <chris.sylvain@gmail.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      ca1eda2d
    • Michal Januszewski's avatar
      fbdev: fix fillrect for 24bpp modes · bdca0f9b
      Michal Januszewski authored
      
      The software fillrect routines do not work properly when the number of
      pixels per machine word is not an integer.  To see that, run the following
      command on a fbdev console with a 24bpp video mode, using a
      non-accelerated driver such as (u)vesafb:
      
        reset ; echo -e '\e[41mtest\e[K'
      
      The expected result is 'test' displayed on a line with red background.
      Instead of that, 'test' has a red background, but the rest of the line
      (rendered using fillrect()) contains a distored colorful pattern.
      
      This patch fixes the problem by correctly computing rotation shifts.  It
      has been tested in a 24bpp mode on 32- and 64-bit little-endian machines.
      Signed-off-by: default avatarMichal Januszewski <spock@gentoo.org>
      Acked-by: default avatarKrzysztof Helt <krzysztof.h1@wp.pl>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      bdca0f9b
    • David Rientjes's avatar
      oom: prevent livelock when oom_kill_allocating_task is set · 184101bf
      David Rientjes authored
      
      When /proc/sys/vm/oom_kill_allocating_task is set for large systems that
      want to avoid the lengthy tasklist scan, it's possible to livelock if
      current is ineligible for oom kill.  This normally happens when it is set
      to OOM_DISABLE, but is also possible if any threads are sharing the same
      ->mm with a different tgid.
      
      So change __out_of_memory() to fall back to the full task-list scan if it
      was unable to kill `current'.
      
      Cc: Nick Piggin <npiggin@suse.de>
      Signed-off-by: default avatarDavid Rientjes <rientjes@google.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      184101bf
    • Josef Bacik's avatar
      fiemap: fix problem with setting FIEMAP_EXTENT_LAST · df3935ff
      Josef Bacik authored
      
      Fix a problem where the generic block based fiemap stuff would not
      properly set FIEMAP_EXTENT_LAST on the last extent.  I've reworked things
      to keep track if we go past the EOF, and mark the last extent properly.
      The problem was reported by and tested by Eric Sandeen.
      Tested-by: default avatarEric Sandeen <sandeen@redhat.com>
      Signed-off-by: default avatarJosef Bacik <jbacik@redhat.com>
      Cc: <linux-ext4@vger.kernel.org>
      Cc: <xfs-masters@oss.sgi.com>
      Cc: <linux-btrfs@vger.kernel.org>
      Cc: Steven Whitehouse <swhiteho@redhat.com>
      Cc: Mark Fasheh <mfasheh@suse.com>
      Cc: Joel Becker <Joel.Becker@oracle.com>
      Cc: <stable@kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      df3935ff
    • Andi Kleen's avatar
      Eliminate thousands of warnings with gcc 3.2 build · 57adc4d2
      Andi Kleen authored
      
      When building with gcc 3.2 I get thousands of warnings such as
      
      include/linux/gfp.h: In function `allocflags_to_migratetype':
      include/linux/gfp.h:105: warning: null format string
      
      due to passing a NULL format string to warn_slowpath() in
      
      #define __WARN()		warn_slowpath(__FILE__, __LINE__, NULL)
      
      Split this case out into a separate call.  This also shrinks the kernel
      slightly:
      
                text    data     bss     dec     hex filename
             4802274  707668  712704 6222646  5ef336 vmlinux
                text    data     bss     dec     hex filename
             4799027  703572  712704 6215303  5ed687 vmlinux
      
      due to removeing one argument from the commonly-called __WARN().
      
      [akpm@linux-foundation.org: reduce scope of `empty']
      Acked-by: default avatarJesper Nilsson <jesper.nilsson@axis.com>
      Acked-by: default avatarJohannes Weiner <hannes@cmpxchg.org>
      Acked-by: default avatarArjan van de Ven <arjan@linux.intel.com>
      Signed-off-by: default avatarAndi Kleen <ak@linux.intel.com>
      Cc: Hugh Dickins <hugh@veritas.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      57adc4d2
    • Hugh Dickins's avatar
      doc: hashdist defaults on for 64bit · 429aa0fc
      Hugh Dickins authored
      
      kernel boot parameter `hashdist' now defaults on for all 64bit NUMA.
      Signed-off-by: default avatarHugh Dickins <hugh@veritas.com>
      Acked-by: default avatarMel Gorman <mel@csn.ul.ie>
      Acked-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      429aa0fc
    • Wu Fengguang's avatar
      inotify: use GFP_NOFS in kernel_event() to work around a lockdep false-positive · 381a80e6
      Wu Fengguang authored
      
      There is what we believe to be a false positive reported by lockdep.
      
      inotify_inode_queue_event() => take inotify_mutex => kernel_event() =>
      kmalloc() => SLOB => alloc_pages_node() => page reclaim => slab reclaim =>
      dcache reclaim => inotify_inode_is_dead => take inotify_mutex => deadlock
      
      The plan is to fix this via lockdep annotation, but that is proving to be
      quite involved.
      
      The patch flips the allocation over to GFP_NFS to shut the warning up, for
      the 2.6.30 release.
      
      Hopefully we will fix this for real in 2.6.31.  I'll queue a patch in -mm
      to switch it back to GFP_KERNEL so we don't forget.
      
        =================================
        [ INFO: inconsistent lock state ]
        2.6.30-rc2-next-20090417 #203
        ---------------------------------
        inconsistent {RECLAIM_FS-ON-W} -> {IN-RECLAIM_FS-W} usage.
        kswapd0/380 [HC0[0]:SC0[0]:HE1:SE1] takes:
         (&inode->inotify_mutex){+.+.?.}, at: [<ffffffff8112f1b5>] inotify_inode_is_dead+0x35/0xb0
        {RECLAIM_FS-ON-W} state was registered at:
          [<ffffffff81079188>] mark_held_locks+0x68/0x90
          [<ffffffff810792a5>] lockdep_trace_alloc+0xf5/0x100
          [<ffffffff810f5261>] __kmalloc_node+0x31/0x1e0
          [<ffffffff81130652>] kernel_event+0xe2/0x190
          [<ffffffff81130826>] inotify_dev_queue_event+0x126/0x230
          [<ffffffff8112f096>] inotify_inode_queue_event+0xc6/0x110
          [<ffffffff8110444d>] vfs_create+0xcd/0x140
          [<ffffffff8110825d>] do_filp_open+0x88d/0xa20
          [<ffffffff810f6b68>] do_sys_open+0x98/0x140
          [<ffffffff810f6c50>] sys_open+0x20/0x30
          [<ffffffff8100c272>] system_call_fastpath+0x16/0x1b
          [<ffffffffffffffff>] 0xffffffffffffffff
        irq event stamp: 690455
        hardirqs last  enabled at (690455): [<ffffffff81564fe4>] _spin_unlock_irqrestore+0x44/0x80
        hardirqs last disabled at (690454): [<ffffffff81565372>] _spin_lock_irqsave+0x32/0xa0
        softirqs last  enabled at (690178): [<ffffffff81052282>] __do_softirq+0x202/0x220
        softirqs last disabled at (690157): [<ffffffff8100d50c>] call_softirq+0x1c/0x50
      
        other info that might help us debug this:
        2 locks held by kswapd0/380:
         #0:  (shrinker_rwsem){++++..}, at: [<ffffffff810d0bd7>] shrink_slab+0x37/0x180
         #1:  (&type->s_umount_key#17){++++..}, at: [<ffffffff8110cfbf>] shrink_dcache_memory+0x11f/0x1e0
      
        stack backtrace:
        Pid: 380, comm: kswapd0 Not tainted 2.6.30-rc2-next-20090417 #203
        Call Trace:
         [<ffffffff810789ef>] print_usage_bug+0x19f/0x200
         [<ffffffff81018bff>] ? save_stack_trace+0x2f/0x50
         [<ffffffff81078f0b>] mark_lock+0x4bb/0x6d0
         [<ffffffff810799e0>] ? check_usage_forwards+0x0/0xc0
         [<ffffffff8107b142>] __lock_acquire+0xc62/0x1ae0
         [<ffffffff810f478c>] ? slob_free+0x10c/0x370
         [<ffffffff8107c0a1>] lock_acquire+0xe1/0x120
         [<ffffffff8112f1b5>] ? inotify_inode_is_dead+0x35/0xb0
         [<ffffffff81562d43>] mutex_lock_nested+0x63/0x420
         [<ffffffff8112f1b5>] ? inotify_inode_is_dead+0x35/0xb0
         [<ffffffff8112f1b5>] ? inotify_inode_is_dead+0x35/0xb0
         [<ffffffff81012fe9>] ? sched_clock+0x9/0x10
         [<ffffffff81077165>] ? lock_release_holdtime+0x35/0x1c0
         [<ffffffff8112f1b5>] inotify_inode_is_dead+0x35/0xb0
         [<ffffffff8110c9dc>] dentry_iput+0xbc/0xe0
         [<ffffffff8110cb23>] d_kill+0x33/0x60
         [<ffffffff8110ce23>] __shrink_dcache_sb+0x2d3/0x350
         [<ffffffff8110cffa>] shrink_dcache_memory+0x15a/0x1e0
         [<ffffffff810d0cc5>] shrink_slab+0x125/0x180
         [<ffffffff810d1540>] kswapd+0x560/0x7a0
         [<ffffffff810ce160>] ? isolate_pages_global+0x0/0x2c0
         [<ffffffff81065a30>] ? autoremove_wake_function+0x0/0x40
         [<ffffffff8107953d>] ? trace_hardirqs_on+0xd/0x10
         [<ffffffff810d0fe0>] ? kswapd+0x0/0x7a0
         [<ffffffff8106555b>] kthread+0x5b/0xa0
         [<ffffffff8100d40a>] child_rip+0xa/0x20
         [<ffffffff8100cdd0>] ? restore_args+0x0/0x30
         [<ffffffff81065500>] ? kthread+0x0/0xa0
         [<ffffffff8100d400>] ? child_rip+0x0/0x20
      
      [eparis@redhat.com: fix audit too]
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: Matt Mackall <mpm@selenic.com>
      Cc: Christoph Lameter <clameter@sgi.com>
      Signed-off-by: default avatarWu Fengguang <fengguang.wu@intel.com>
      Signed-off-by: default avatarEric Paris <eparis@redhat.com>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      381a80e6