1. 17 6月, 2011 20 次提交
  2. 16 6月, 2011 20 次提交
    • D
      AFS: Use i_generation not i_version for the vnode uniquifier · d6e43f75
      David Howells 提交于
      Store the AFS vnode uniquifier in the i_generation field, not the i_version
      field of the inode struct.  i_version can then be given the AFS data version
      number.
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      d6e43f75
    • D
      AFS: Set s_id in the superblock to the volume name · 2e41ae22
      David Howells 提交于
      Set s_id in the superblock to the name of the AFS volume that this superblock
      corresponds to.
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      2e41ae22
    • J
      vfs: Fix data corruption after failed write in __block_write_begin() · f9f07b6c
      Jan Kara 提交于
      I've got a report of a file corruption from fsxlinux on ext3. The important
      operations to the page were:
      mapwrite to a hole
      partial write to the page
      read - found the page zeroed from the end of the normal write
      
      The culprit seems to be that if get_block() fails in __block_write_begin()
      (e.g. transient ENOSPC in ext3), the function does ClearPageUptodate(page).
      Thus when we retry the write, the logic in __block_write_begin() thinks zeroing
      of the page is needed and overwrites old data.  In fact, I don't see why we
      should ever need to zero the uptodate bit here - either the page was uptodate
      when we entered __block_write_begin() and it should stay so when we leave it,
      or it was not uptodate and noone had right to set it uptodate during
      __block_write_begin() so it remains !uptodate when we leave as well. So just
      remove clearing of the bit.
      Signed-off-by: NJan Kara <jack@suse.cz>
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      f9f07b6c
    • A
      afs: afs_fill_page reads too much, or wrong data · 5e7f2337
      Anton Blanchard 提交于
      afs_fill_page should read the page that is about to be written but
      the current implementation has a number of issues. If we aren't
      extending the file we always read PAGE_CACHE_SIZE at offset 0. If we
      are extending the file we try to read the entire file.
      
      Change afs_fill_page to read PAGE_CACHE_SIZE at the right offset,
      clamped to i_size.
      
      While here, avoid calling afs_fill_page when we are doing a
      PAGE_CACHE_SIZE write.
      Signed-off-by: NAnton Blanchard <anton@samba.org>
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      5e7f2337
    • R
      staging: fix iio builds when IIO_RING_BUFFER is not enabled · e1d76719
      Randy Dunlap 提交于
      Fix build by moving enum list outside of
      #ifdef CONFIG_IIO_RING_BUFFER.
      
        drivers/staging/iio/accel/adis16201_core.c:413: error: 'ADIS16201_SCAN_SUPPLY' undeclared here (not in a function)
        drivers/staging/iio/accel/adis16201_core.c:417: error: 'ADIS16201_SCAN_TEMP' undeclared here (not in a function)
        ..
      
        drivers/staging/iio/accel/adis16203_core.c:374: error: 'ADIS16203_SCAN_SUPPLY' undeclared here (not in a function)
        drivers/staging/iio/accel/adis16203_core.c:378: error: 'ADIS16203_SCAN_AUX_ADC' undeclared here (not in a function)
        ..
      Signed-off-by: NRandy Dunlap <randy.dunlap@oracle.com>
      Acked-by: NJonathan Cameron <jic23@cam.ac.uk>
      Cc: linux-iio@vger.kernel.org
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      e1d76719
    • A
      VFS: Fix vfsmount overput on simultaneous automount · 8aef1884
      Al Viro 提交于
      [Kudos to dhowells for tracking that crap down]
      
      If two processes attempt to cause automounting on the same mountpoint at the
      same time, the vfsmount holding the mountpoint will be left with one too few
      references on it, causing a BUG when the kernel tries to clean up.
      
      The problem is that lock_mount() drops the caller's reference to the
      mountpoint's vfsmount in the case where it finds something already mounted on
      the mountpoint as it transits to the mounted filesystem and replaces path->mnt
      with the new mountpoint vfsmount.
      
      During a pathwalk, however, we don't take a reference on the vfsmount if it is
      the same as the one in the nameidata struct, but do_add_mount() doesn't know
      this.
      
      The fix is to make sure we have a ref on the vfsmount of the mountpoint before
      calling do_add_mount().  However, if lock_mount() doesn't transit, we're then
      left with an extra ref on the mountpoint vfsmount which needs releasing.
      We can handle that in follow_managed() by not making assumptions about what
      we can and what we cannot get from lookup_mnt() as the current code does.
      
      The callers of follow_managed() expect that reference to path->mnt will be
      grabbed iff path->mnt has been changed.  follow_managed() and follow_automount()
      keep track of whether such reference has been grabbed and assume that it'll
      happen in those and only those cases that'll have us return with changed
      path->mnt.  That assumption is almost correct - it breaks in case of
      racing automounts and in even harder to hit race between following a mountpoint
      and a couple of mount --move.  The thing is, we don't need to make that
      assumption at all - after the end of loop in follow_manage() we can check
      if path->mnt has ended up unchanged and do mntput() if needed.
      
      The BUG can be reproduced with the following test program:
      
      	#include <stdio.h>
      	#include <sys/types.h>
      	#include <sys/stat.h>
      	#include <unistd.h>
      	#include <sys/wait.h>
      	int main(int argc, char **argv)
      	{
      		int pid, ws;
      		struct stat buf;
      		pid = fork();
      		stat(argv[1], &buf);
      		if (pid > 0) wait(&ws);
      		return 0;
      	}
      
      and the following procedure:
      
       (1) Mount an NFS volume that on the server has something else mounted on a
           subdirectory.  For instance, I can mount / from my server:
      
      	mount warthog:/ /mnt -t nfs4 -r
      
           On the server /data has another filesystem mounted on it, so NFS will see
           a change in FSID as it walks down the path, and will mark /mnt/data as
           being a mountpoint.  This will cause the automount code to be triggered.
      
           !!! Do not look inside the mounted fs at this point !!!
      
       (2) Run the above program on a file within the submount to generate two
           simultaneous automount requests:
      
      	/tmp/forkstat /mnt/data/testfile
      
       (3) Unmount the automounted submount:
      
      	umount /mnt/data
      
       (4) Unmount the original mount:
      
      	umount /mnt
      
           At this point the kernel should throw a BUG with something like the
           following:
      
      	BUG: Dentry ffff880032e3c5c0{i=2,n=} still in use (1) [unmount of nfs4 0:12]
      
      Note that the bug appears on the root dentry of the original mount, not the
      mountpoint and not the submount because sys_umount() hasn't got to its final
      mntput_no_expire() yet, but this isn't so obvious from the call trace:
      
       [<ffffffff8117cd82>] shrink_dcache_for_umount+0x69/0x82
       [<ffffffff8116160e>] generic_shutdown_super+0x37/0x15b
       [<ffffffffa00fae56>] ? nfs_super_return_all_delegations+0x2e/0x1b1 [nfs]
       [<ffffffff811617f3>] kill_anon_super+0x1d/0x7e
       [<ffffffffa00d0be1>] nfs4_kill_super+0x60/0xb6 [nfs]
       [<ffffffff81161c17>] deactivate_locked_super+0x34/0x83
       [<ffffffff811629ff>] deactivate_super+0x6f/0x7b
       [<ffffffff81186261>] mntput_no_expire+0x18d/0x199
       [<ffffffff811862a8>] mntput+0x3b/0x44
       [<ffffffff81186d87>] release_mounts+0xa2/0xbf
       [<ffffffff811876af>] sys_umount+0x47a/0x4ba
       [<ffffffff8109e1ca>] ? trace_hardirqs_on_caller+0x1fd/0x22f
       [<ffffffff816ea86b>] system_call_fastpath+0x16/0x1b
      
      as do_umount() is inlined.  However, you can see release_mounts() in there.
      
      Note also that it may be necessary to have multiple CPU cores to be able to
      trigger this bug.
      Tested-by: NJeff Layton <jlayton@redhat.com>
      Tested-by: NIan Kent <raven@themaw.net>
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      8aef1884
    • T
      fix wrong iput on d_inode introduced by e6bc45d6 · 50338b88
      Török Edwin 提交于
      Git bisection shows that commit e6bc45d6 causes
      BUG_ONs under high I/O load:
      
      kernel BUG at fs/inode.c:1368!
      [ 2862.501007] Call Trace:
      [ 2862.501007]  [<ffffffff811691d8>] d_kill+0xf8/0x140
      [ 2862.501007]  [<ffffffff81169c19>] dput+0xc9/0x190
      [ 2862.501007]  [<ffffffff8115577f>] fput+0x15f/0x210
      [ 2862.501007]  [<ffffffff81152171>] filp_close+0x61/0x90
      [ 2862.501007]  [<ffffffff81152251>] sys_close+0xb1/0x110
      [ 2862.501007]  [<ffffffff814c14fb>] system_call_fastpath+0x16/0x1b
      
      A reliable way to reproduce this bug is:
      Login to KDE, run 'rsnapshot sync', and apt-get install openjdk-6-jdk,
      and apt-get remove openjdk-6-jdk.
      
      The buggy part of the patch is this:
      	struct inode *inode = NULL;
      .....
      -               if (nd.last.name[nd.last.len])
      -                       goto slashes;
                      inode = dentry->d_inode;
      -               if (inode)
      -                       ihold(inode);
      +               if (nd.last.name[nd.last.len] || !inode)
      +                       goto slashes;
      +               ihold(inode)
      ...
      	if (inode)
      		iput(inode);	/* truncate the inode here */
      
      If nd.last.name[nd.last.len] is nonzero (and thus goto slashes branch is taken),
      and dentry->d_inode is non-NULL, then this code now does an additional iput on
      the inode, which is wrong.
      
      Fix this by only setting the inode variable if nd.last.name[nd.last.len] is 0.
      
      Reference: https://lkml.org/lkml/2011/6/15/50Reported-by: NNorbert Preining <preining@logic.at>
      Reported-by: NTörök Edwin <edwintorok@gmail.com>
      Cc: "Theodore Ts'o" <tytso@mit.edu>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: NTörök Edwin <edwintorok@gmail.com>
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      50338b88
    • L
      mm: get rid of the most spurious find_vma_prev() users · 9be34c9d
      Linus Torvalds 提交于
      We have some users of this function that date back to before the vma
      list was doubly linked, and just are silly.  These days, you can find
      the previous vma by just following the vma->vm_prev pointer.
      
      In some cases you don't need any find_vma() lookup at all, and in other
      cases you're better off with the regular "find_vma()" that uses the vma
      cache front-end lookup.
      
      Some "find_vma_prev()" users are still valid, though.  For example, in
      the case of a stack that grows up, it can be the case that we don't find
      any 'vma' at all (because we're looking up an address that is past the
      last vma), and that the stack that we want to grow is the 'prev' vma.
      
      But that kind of special case aside, we generally should prefer to use
      'find_vma()'.
      
      Noticed due to a totally unrelated POWER memory corruption bug that just
      happened to hit in 'find_vma_prev()' and made me go "Hmm - why are we
      using that function here?".
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      9be34c9d
    • C
      drivers/gpu/drm: use printk_ratelimited instead of printk_ratelimit · cafe8d84
      Christian Dietrich 提交于
      Since printk_ratelimit() shouldn't be used anymore (see comment in
      include/linux/printk.h), replace it with printk_ratelimited.
      Signed-off-by: NChristian Dietrich <christian.dietrich@informatik.uni-erlangen.de>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      cafe8d84
    • D
      drm/radeon: workaround a hw bug on some radeon chipsets with all-0 EDIDs. · 4a9a8b71
      Dave Airlie 提交于
      Some RS690 chipsets seem to end up with floating connectors, either
      a DVI connector isn't actually populated, or an add-in HDMI card
      is available but not installed. In this case we seem to get a NULL byte
      response for each byte of the i2c transaction, so we detect this
      case and if we see it we don't do anymore DDC transactions on this
      connector.
      
      I've tested this on my RS690 without the HDMI card installed and
      it seems to work fine.
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      Reviewed-by: NAlex Deucher <alexdeucher@gmail.com>
      4a9a8b71
    • D
      drm: make debug levels match in edid failure code. · f49dadb8
      Dave Airlie 提交于
      this puts the header and followup at the same loglevel as the
      hex dump code.
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      Reviewed-by: NAlex Deucher <alexdeucher@gmail.com>
      f49dadb8
    • A
      drm/radeon/kms: clear wb memory by default · e6ba7599
      Alex Deucher 提交于
      Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      e6ba7599
    • A
      drm/radeon/kms: be more pedantic about the g5 quirk (v2) · 7c88d2b8
      Alex Deucher 提交于
      I don't think Apple offered any other cards for
      this mac, so I doubt this will be an issue, but just
      to be on the safe side, check the pci ids as well.
      
      v2: fix spelling in commit message
      Reviewed-by: NMichel Dänzer <michel@daenzer.net>
      Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
      Cc: Joachim Henke <j-o@users.sourceforge.net>
      Cc: Michel Dänzer <michel@daenzer.net>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      7c88d2b8
    • A
      drm/radeon/kms: signed fix for evergreen thermal · 1c88d74f
      Alex Deucher 提交于
      temperature is signed.
      Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      1c88d74f
    • W
      drm: populate irq_by_busid-member for pci · 45e97ab6
      Wolfram Sang 提交于
      Commit 8410ea (drm: rework PCI/platform driver interface) implemented
      drm_pci_irq_by_busid() but forgot to make it available in the
      drm_pci_bus-struct.
      
      This caused a freeze on my Radeon9600-equipped laptop when executing glxgears.
      Thanks to Michel for noticing the flaw.
      
      [airlied: made function static also]
      Reported-by: NMichel Dänzer <daenzer@vmware.com>
      Signed-off-by: NWolfram Sang <w.sang@pengutronix.de>
      Cc: stable@kernel.org
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      45e97ab6
    • K
      261a9af6
    • K
      fb2e7394
    • L
      Merge branch 'fixes' of master.kernel.org:/home/rmk/linux-2.6-arm · 19a1166f
      Linus Torvalds 提交于
      * 'fixes' of master.kernel.org:/home/rmk/linux-2.6-arm:
        ARM: footbridge: fix clock event support
        ARM: footbridge: fix debug macros
        ARM: initrd: disable initrds outside of memory
        ARM: extend Code: line by one 16-bit quantity for Thumb instructions
        ARM: 6955/1: cmpxchg syscall should data abort if page not write
        ARM: 6954/1: zImage: fix Thumb2 breakage
        ARM: 6953/1: DT: don't try to access physical address zero
        ARM: 6949/2: mach-u300: fix compilaton warning in IO accessors
        Revert "ARM: 6944/1: mm: allow ASID 0 to be allocated to tasks"
        Revert "ARM: 6943/1: mm: use TTBR1 instead of reserved context ID"
        davinci: make PCM platform devices static
        arm: davinci: Fix fallout from generic irq chip conversion
        ARM: 6894/1: mmci: trigger card detect IRQs on falling and rising edges
        ARM: 6952/1: fix lockdep warning of "unannotated irqs-off"
        ARM: 6951/1: include .bss in memory layout information
        ARM: 6948/1: Fix .size directives for __arm{7,9}tdmi_proc_info
        ARM: 6947/2: mach-u300: fix compilation error in timer
        ARM: 6946/1: vexpress: move v2m clock init to init_early
        ARM: mx51/sdma: Check the chip revision in run-time
        arm: mxs: include asm/processor.h for cpu_relax()
      19a1166f
    • L
      Revert "fs/exec.c: use BUILD_BUG_ON for VM_STACK_FLAGS & VM_STACK_INCOMPLETE_SETUP" · 13fca640
      Linus Torvalds 提交于
      This reverts commit 7f81c889.
      
      It turns out that it's not actually a build-time check on x86-64 UML,
      which does some seriously crazy stuff with VM_STACK_FLAGS.
      
      The VM_STACK_FLAGS define depends on the arch-supplied
      VM_STACK_DEFAULT_FLAGS value, and on x86-64 UML we have
      
        arch/um/sys-x86_64/shared/sysdep/vm-flags.h:
      
      	#define VM_STACK_DEFAULT_FLAGS \
      		(test_thread_flag(TIF_IA32) ? vm_stack_flags32 : vm_stack_flags)
      
      	#define VM_STACK_DEFAULT_FLAGS vm_stack_flags
      
      (yes, seriously: two different #define's for that thing, with the first
      one being inside an "#ifdef TIF_IA32")
      
      It's possible that it is UML that should just be fixed in this area, but
      for now let's just undo the (very small) optimization.
      Reported-by: NRandy Dunlap <randy.dunlap@oracle.com>
      Acked-by: NAndrew Morton <akpm@linux-foundation.org>
      Cc: Michal Hocko <mhocko@suse.cz>
      Cc: Richard Weinberger <richard@nod.at>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      13fca640
    • J
      Documentation: fix cgroup typos and formatting · 67de0162
      Jörg Sommer 提交于
      Fix format and spelling.
      Signed-off-by: NJörg Sommer <joerg@alea.gnuu.de>
      Acked-by: NPaul Menage <menage@google.com>
      Signed-off-by: NRandy Dunlap <randy.dunlap@oracle.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      67de0162