1. 12 5月, 2010 13 次提交
    • M
      hugetlbfs: kill applications that use MAP_NORESERVE with SIGBUS instead of OOM-killer · 4a6018f7
      Mel Gorman 提交于
      Ordinarily, application using hugetlbfs will create mappings with
      reserves.  For shared mappings, these pages are reserved before mmap()
      returns success and for private mappings, the caller process is guaranteed
      and a child process that cannot get the pages gets killed with sigbus.
      
      An application that uses MAP_NORESERVE gets no reservations and mmap()
      will always succeed at the risk the page will not be available at fault
      time.  This might be used for example on very large sparse mappings where
      the developer is confident the necessary huge pages exist to satisfy all
      faults even though the whole mapping cannot be backed by huge pages.
      Unfortunately, if an allocation does fail, VM_FAULT_OOM is returned to the
      fault handler which proceeds to trigger the OOM-killer.  This is
      unhelpful.
      
      Even without hugetlbfs mounted, a user using mmap() can trivially trigger
      the OOM-killer because VM_FAULT_OOM is returned (will provide example
      program if desired - it's a whopping 24 lines long).  It could be
      considered a DOS available to an unprivileged user.
      
      This patch alters hugetlbfs to kill a process that uses MAP_NORESERVE
      where huge pages were not available with SIGBUS instead of triggering the
      OOM killer.
      
      This change affects hugetlb_cow() as well.  I feel there is a failure case
      in there, but I didn't create one.  It would need a fairly specific target
      in terms of the faulting application and the hugepage pool size.  The
      hugetlb_no_page() path is much easier to hit but both might as well be
      closed.
      Signed-off-by: NMel Gorman <mel@csn.ul.ie>
      Cc: Lee Schermerhorn <lee.schermerhorn@hp.com>
      Cc: David Rientjes <rientjes@google.com>
      Cc: Andi Kleen <andi@firstfloor.org>
      Cc: <stable@kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      4a6018f7
    • V
      kexec: fix OOPS in crash_kernel_shrink · 475f9aa6
      Vitaly Mayatskikh 提交于
      Two "echo 0 > /sys/kernel/kexec_crash_size" OOPSes kernel.  Also content
      of this file is invalid after first shrink to zero: it shows 1 instead of
      0.
      
      This scenario is unlikely to happen often (root privs, valid crashkernel=
      in cmdline, dump-capture kernel not loaded), I hit it only by chance.
      
      This patch fixes it.
      Signed-off-by: NVitaly Mayatskikh <v.mayatskih@gmail.com>
      Cc: Cong Wang <amwang@redhat.com>
      Cc: Neil Horman <nhorman@tuxdriver.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      475f9aa6
    • N
      mmc: atmel-mci: fix in debugfs: response value printing · d586ebbb
      Nicolas Ferre 提交于
      In debugfs, printing of command response reports resp[2] twice: fix it to
      resp[3].
      Signed-off-by: NNicolas Ferre <nicolas.ferre@atmel.com>
      Haavard Skinnemoen <hskinnemoen@atmel.com>
      Cc: <linux-mmc@vger.kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      d586ebbb
    • N
      mmc: atmel-mci: remove data error interrupt after xfer · abc2c9fd
      Nicolas Ferre 提交于
      Disable data error interrupts while we are actually recording that there
      is not such errors.  This will prevent, in some cases, the warning message
      printed at new request queuing (in atmci_start_request()).
      Signed-off-by: NNicolas Ferre <nicolas.ferre@atmel.com>
      Cc: Haavard Skinnemoen <hskinnemoen@atmel.com>
      Cc: <linux-mmc@vger.kernel.org>
      Cc: <stable@kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      abc2c9fd
    • N
      mmc: atmel-mci: prevent kernel oops while removing card · 009a891b
      Nicolas Ferre 提交于
      The removing of an SD card in certain circumstances can lead to a kernel
      oops if we do not make sure that the "data" field of the host structure is
      valid.  This patch adds a test in atmci_dma_cleanup() function and also
      calls atmci_stop_dma() before throwing away the reference to data.
      Signed-off-by: NNicolas Ferre <nicolas.ferre@atmel.com>
      Cc: Haavard Skinnemoen <hskinnemoen@atmel.com>
      Cc: <linux-mmc@vger.kernel.org>
      Cc: <stable@kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      009a891b
    • N
      mmc: atmel-mci: fix two parameters swapped · ebb1fea9
      Nicolas Ferre 提交于
      Two parameters were swapped in the calls to atmci_init_slot().
      Signed-off-by: NNicolas Ferre <nicolas.ferre@atmel.com>
      Reported-by: NAnders Grahn <anders.grahn@hd-wireless.se>
      Cc: Haavard Skinnemoen <hskinnemoen@atmel.com>
      Cc: <linux-mmc@vger.kernel.org>
      Cc: <stable@kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      ebb1fea9
    • R
      revert "procfs: provide stack information for threads" and its fixup commits · 34441427
      Robin Holt 提交于
      Originally, commit d899bf7b ("procfs: provide stack information for
      threads") attempted to introduce a new feature for showing where the
      threadstack was located and how many pages are being utilized by the
      stack.
      
      Commit c44972f1 ("procfs: disable per-task stack usage on NOMMU") was
      applied to fix the NO_MMU case.
      
      Commit 89240ba0 ("x86, fs: Fix x86 procfs stack information for threads on
      64-bit") was applied to fix a bug in ia32 executables being loaded.
      
      Commit 9ebd4eba ("procfs: fix /proc/<pid>/stat stack pointer for kernel
      threads") was applied to fix a bug which had kernel threads printing a
      userland stack address.
      
      Commit 1306d603 ('proc: partially revert "procfs: provide stack
      information for threads"') was then applied to revert the stack pages
      being used to solve a significant performance regression.
      
      This patch nearly undoes the effect of all these patches.
      
      The reason for reverting these is it provides an unusable value in
      field 28.  For x86_64, a fork will result in the task->stack_start
      value being updated to the current user top of stack and not the stack
      start address.  This unpredictability of the stack_start value makes
      it worthless.  That includes the intended use of showing how much stack
      space a thread has.
      
      Other architectures will get different values.  As an example, ia64
      gets 0.  The do_fork() and copy_process() functions appear to treat the
      stack_start and stack_size parameters as architecture specific.
      
      I only partially reverted c44972f1 ("procfs: disable per-task stack usage
      on NOMMU") .  If I had completely reverted it, I would have had to change
      mm/Makefile only build pagewalk.o when CONFIG_PROC_PAGE_MONITOR is
      configured.  Since I could not test the builds without significant effort,
      I decided to not change mm/Makefile.
      
      I only partially reverted 89240ba0 ("x86, fs: Fix x86 procfs stack
      information for threads on 64-bit") .  I left the KSTK_ESP() change in
      place as that seemed worthwhile.
      Signed-off-by: NRobin Holt <holt@sgi.com>
      Cc: Stefani Seibold <stefani@seibold.net>
      Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
      Cc: Michal Simek <monstr@monstr.eu>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: <stable@kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      34441427
    • D
      it8761e_gpio: fix bug in gpio numbering · 3c904afd
      Denis Turischev 提交于
      The SIO chip contains 16 possible gpio lines, not 14.  The schematic was
      not read carefully.
      Signed-off-by: NDenis Turischev <denis@compulab.co.il>
      Cc: David Brownell <david-b@pacbell.net>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      3c904afd
    • F
      dma-mapping: fix dma_sync_single_range_* · f33d7e2d
      FUJITA Tomonori 提交于
      dma_sync_single_range_for_cpu() and dma_sync_single_range_for_device() use
      a wrong address with a partial synchronization.
      Signed-off-by: NFUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
      Reviewed-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Cc: <stable@kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      f33d7e2d
    • L
      Merge branch 'drm-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6 · fc2a093e
      Linus Torvalds 提交于
      * 'drm-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6:
        drm/radeon: Fix 3 regressions - since buffer rework
      fc2a093e
    • L
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6 · 9fc282ba
      Linus Torvalds 提交于
      * git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6:
        net: Fix FDDI and TR config checks in ipv4 arp and LLC.
        IPv4: unresolved multicast route cleanup
        mac80211: remove association work when processing deauth request
        ar9170: wait for asynchronous firmware loading
        ipv4: udp: fix short packet and bad checksum logging
        phy: Fix initialization in micrel driver.
        sctp: Fix a race between ICMP protocol unreachable and connect()
        veth: Dont kfree_skb() after dev_forward_skb()
        IPv6: fix IPV6_RECVERR handling of locally-generated errors
        net/gianfar: drop recycled skbs on MTU change
        iwlwifi: work around passive scan issue
      9fc282ba
    • D
      CacheFiles: Fix occasional EIO on call to vfs_unlink() · c61ea31d
      David Howells 提交于
      Fix an occasional EIO returned by a call to vfs_unlink():
      
      	[ 4868.465413] CacheFiles: I/O Error: Unlink failed
      	[ 4868.465444] FS-Cache: Cache cachefiles stopped due to I/O error
      	[ 4947.320011] CacheFiles: File cache on md3 unregistering
      	[ 4947.320041] FS-Cache: Withdrawing cache "mycache"
      	[ 5127.348683] FS-Cache: Cache "mycache" added (type cachefiles)
      	[ 5127.348716] CacheFiles: File cache on md3 registered
      	[ 7076.871081] CacheFiles: I/O Error: Unlink failed
      	[ 7076.871130] FS-Cache: Cache cachefiles stopped due to I/O error
      	[ 7116.780891] CacheFiles: File cache on md3 unregistering
      	[ 7116.780937] FS-Cache: Withdrawing cache "mycache"
      	[ 7296.813394] FS-Cache: Cache "mycache" added (type cachefiles)
      	[ 7296.813432] CacheFiles: File cache on md3 registered
      
      What happens is this:
      
       (1) A cached NFS file is seen to have become out of date, so NFS retires the
           object and immediately acquires a new object with the same key.
      
       (2) Retirement of the old object is done asynchronously - so the lookup/create
           to generate the new object may be done first.
      
           This can be a problem as the old object and the new object must exist at
           the same point in the backing filesystem (i.e. they must have the same
           pathname).
      
       (3) The lookup for the new object sees that a backing file already exists,
           checks to see whether it is valid and sees that it isn't.  It then deletes
           that file and creates a new one on disk.
      
       (4) The retirement phase for the old file is then performed.  It tries to
           delete the dentry it has, but ext4_unlink() returns -EIO because the inode
           attached to that dentry no longer matches the inode number associated with
           the filename in the parent directory.
      
      The trace below shows this quite well.
      
      	[md5sum] ==> __fscache_relinquish_cookie(ffff88002d12fb58{NFS.fh,ffff88002ce62100},1)
      	[md5sum] ==> __fscache_acquire_cookie({NFS.server},{NFS.fh},ffff88002ce62100)
      
      NFS has retired the old cookie and asked for a new one.
      
      	[kslowd] ==> fscache_object_state_machine({OBJ52,OBJECT_ACTIVE,24})
      	[kslowd] <== fscache_object_state_machine() [->OBJECT_DYING]
      	[kslowd] ==> fscache_object_state_machine({OBJ53,OBJECT_INIT,0})
      	[kslowd] <== fscache_object_state_machine() [->OBJECT_LOOKING_UP]
      	[kslowd] ==> fscache_object_state_machine({OBJ52,OBJECT_DYING,24})
      	[kslowd] <== fscache_object_state_machine() [->OBJECT_RECYCLING]
      
      The old object (OBJ52) is going through the terminal states to get rid of it,
      whilst the new object - (OBJ53) - is coming into being.
      
      	[kslowd] ==> fscache_object_state_machine({OBJ53,OBJECT_LOOKING_UP,0})
      	[kslowd] ==> cachefiles_walk_to_object({ffff88003029d8b8},OBJ53,@68,)
      	[kslowd] lookup '@68'
      	[kslowd] next -> ffff88002ce41bd0 positive
      	[kslowd] advance
      	[kslowd] lookup 'Es0g00og0_Nd_XCYe3BOzvXrsBLMlN6aw16M1htaA'
      	[kslowd] next -> ffff8800369faac8 positive
      
      The new object has looked up the subdir in which the file would be in (getting
      dentry ffff88002ce41bd0) and then looked up the file itself (getting dentry
      ffff8800369faac8).
      
      	[kslowd] validate 'Es0g00og0_Nd_XCYe3BOzvXrsBLMlN6aw16M1htaA'
      	[kslowd] ==> cachefiles_bury_object(,'@68','Es0g00og0_Nd_XCYe3BOzvXrsBLMlN6aw16M1htaA')
      	[kslowd] remove ffff8800369faac8 from ffff88002ce41bd0
      	[kslowd] unlink stale object
      	[kslowd] <== cachefiles_bury_object() = 0
      
      It then checks the file's xattrs to see if it's valid.  NFS says that the
      auxiliary data indicate the file is out of date (obvious to us - that's why NFS
      ditched the old version and got a new one).  CacheFiles then deletes the old
      file (dentry ffff8800369faac8).
      
      	[kslowd] redo lookup
      	[kslowd] lookup 'Es0g00og0_Nd_XCYe3BOzvXrsBLMlN6aw16M1htaA'
      	[kslowd] next -> ffff88002cd94288 negative
      	[kslowd] create -> ffff88002cd94288{ffff88002cdaf238{ino=148247}}
      
      CacheFiles then redoes the lookup and gets a negative result in a new dentry
      (ffff88002cd94288) which it then creates a file for.
      
      	[kslowd] ==> cachefiles_mark_object_active(,OBJ53)
      	[kslowd] <== cachefiles_mark_object_active() = 0
      	[kslowd] === OBTAINED_OBJECT ===
      	[kslowd] <== cachefiles_walk_to_object() = 0 [148247]
      	[kslowd] <== fscache_object_state_machine() [->OBJECT_AVAILABLE]
      
      The new object is then marked active and the state machine moves to the
      available state - at which point NFS can start filling the object.
      
      	[kslowd] ==> fscache_object_state_machine({OBJ52,OBJECT_RECYCLING,20})
      	[kslowd] ==> fscache_release_object()
      	[kslowd] ==> cachefiles_drop_object({OBJ52,2})
      	[kslowd] ==> cachefiles_delete_object(,OBJ52{ffff8800369faac8})
      
      The old object, meanwhile, goes on with being retired.  If allocation occurs
      first, cachefiles_delete_object() has to wait for dir->d_inode->i_mutex to
      become available before it can continue.
      
      	[kslowd] ==> cachefiles_bury_object(,'@68','Es0g00og0_Nd_XCYe3BOzvXrsBLMlN6aw16M1htaA')
      	[kslowd] remove ffff8800369faac8 from ffff88002ce41bd0
      	[kslowd] unlink stale object
      	EXT4-fs warning (device sda6): ext4_unlink: Inode number mismatch in unlink (148247!=148193)
      	CacheFiles: I/O Error: Unlink failed
      	FS-Cache: Cache cachefiles stopped due to I/O error
      
      CacheFiles then tries to delete the file for the old object, but the dentry it
      has (ffff8800369faac8) no longer points to a valid inode for that directory
      entry, and so ext4_unlink() returns -EIO when de->inode does not match i_ino.
      
      	[kslowd] <== cachefiles_bury_object() = -5
      	[kslowd] <== cachefiles_delete_object() = -5
      	[kslowd] <== fscache_object_state_machine() [->OBJECT_DEAD]
      	[kslowd] ==> fscache_object_state_machine({OBJ53,OBJECT_AVAILABLE,0})
      	[kslowd] <== fscache_object_state_machine() [->OBJECT_ACTIVE]
      
      (Note that the above trace includes extra information beyond that produced by
      the upstream code).
      
      The fix is to note when an object that is being retired has had its object
      deleted preemptively by a replacement object that is being created, and to
      skip the second removal attempt in such a case.
      Reported-by: NGreg M <gregm@servu.net.au>
      Reported-by: NMark Moseley <moseleymark@gmail.com>
      Reported-by: NRomain DEGEZ <romain.degez@smartjog.com>
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      c61ea31d
    • A
      ACPI: sleep: eliminate duplicate entries in acpisleep_dmi_table[] · 7d6fb7bd
      Alex Chiang 提交于
      Duplicate entries ended up acpisleep_dmi_table[] by accident.
      They don't hurt functionality, but they are ugly, so let's get
      rid of them.
      
      Cc: stable@kernel.org
      Signed-off-by: NAlex Chiang <achiang@canonical.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      7d6fb7bd
  2. 11 5月, 2010 5 次提交
  3. 10 5月, 2010 7 次提交
  4. 08 5月, 2010 12 次提交
  5. 07 5月, 2010 3 次提交
    • N
      md: restore ability of spare drives to spin down. · 1176568d
      NeilBrown 提交于
      Some time ago we stopped the clean/active metadata updates
      from being written to a 'spare' device in most cases so that
      it could spin down and say spun down.  Device failure/removal
      etc are still recorded on spares.
      
      However commit 51d5668c broke this 50% of the time,
      depending on whether the event count is even or odd.
      The change log entry said:
      
         This means that the alignment between 'odd/even' and
          'clean/dirty' might take a little longer to attain,
      
      how ever the code makes no attempt to create that alignment, so it
      could take arbitrarily long.
      
      So when we find that clean/dirty is not aligned with odd/even,
      force a second metadata-update immediately.  There are already cases
      where a second metadata-update is needed immediately (e.g. when a
      device fails during the metadata update).  We just piggy-back on that.
      Reported-by: NJoe Bryant <tenminjoe@yahoo.com>
      Signed-off-by: NNeilBrown <neilb@suse.de>
      Cc: stable@kernel.org
      1176568d
    • G
      md/raid6: Fix raid-6 read-error correction in degraded state · 87aa6300
      Gabriele A. Trombetti 提交于
      Fix: Raid-6 was not trying to correct a read-error when in
      singly-degraded state and was instead dropping one more device, going to
      doubly-degraded state. This patch fixes this behaviour.
      Tested-by: NJanos Haar <janos.haar@netcenter.hu>
      Signed-off-by: NGabriele A. Trombetti <g.trombetti.lkrnl1213@logicschema.com>
      Reported-by: NJanos Haar <janos.haar@netcenter.hu>
      Signed-off-by: NNeilBrown <neilb@suse.de>
      Cc: stable@kernel.org
      87aa6300
    • W
      ALSA: hda - fix DG45ID SPDIF output · 4d26f446
      Wu Fengguang 提交于
      This reverts part of commit 52dc4386, in order to fix a regression:
      broken SPDIF output on Intel DG45FC motherboard (IDT 92HD73E1X5 codec).
      
      	--- DG45FC-IDT-codec-2.6.32  (SPDIF OK)
      	+++ DG45FC-IDT-codec-2.6.33  (SPDIF broken)
      
      	 Node 0x22 [Pin Complex] wcaps 0x400301: Stereo Digital
      	   Pincap 0x00000010: OUT
      	-  Pin Default 0x40f000f0: [N/A] Other at Ext N/A
      	-    Conn = Unknown, Color = Unknown
      	-    DefAssociation = 0xf, Sequence = 0x0
      	-  Pin-ctls: 0x00:
      	+  Pin Default 0x014510a0: [Jack] SPDIF Out at Ext Rear
      	+    Conn = Optical, Color = Black
      	+    DefAssociation = 0xa, Sequence = 0x0
      	+  Pin-ctls: 0x40: OUT
      	   Connection: 3
      	      0x25* 0x20 0x21
      	 Node 0x23 [Pin Complex] wcaps 0x400301: Stereo Digital
      	   Pincap 0x00000010: OUT
      	-  Pin Default 0x01451140: [Jack] SPDIF Out at Ext Rear
      	+  Pin Default 0x074510b0: [Jack] SPDIF Out at Ext Rear Panel
      	     Conn = Optical, Color = Black
      	-    DefAssociation = 0x4, Sequence = 0x0
      	-    Misc = NO_PRESENCE
      	-  Pin-ctls: 0x40: OUT
      	+    DefAssociation = 0xb, Sequence = 0x0
      	+  Pin-ctls: 0x00:
      	   Connection: 3
      	      0x26* 0x20 0x21
      
      Cc: <stable@kernel.org>
      Cc: Alexey Fisher <bug-track@fisher-privat.net>
      Tested-by: NDavid Härdeman <david@hardeman.nu>
      Signed-off-by: NWu Fengguang <fengguang.wu@intel.com>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      4d26f446