Skip to content

L
linux-davinci
Switch branch/tag
  1. 30 Sep, 2009 1 commit
  3. 13 Aug, 2009 1 commit
  5. 24 Jul, 2009 1 commit
  7. 30 Sep, 2009 2 commits
    • Sage Weil's avatar
      Get rid of the goto by flipping the if (!result) over. Make the comments · b5f53b38
      Sage Weil authored 
      a bit more descriptive.  Fix a few kernel style problems.  No functional
changes.

Cc: Ian Kent <raven@themaw.net>
Cc: Christoph Hellwig <hch@infradead.org>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Andreas Dilger <adilger@sun.com>
Signed-off-by: default avatarYehuda Sadeh <yehuda@newdream.net>
Signed-off-by: default avatarSage Weil <sage@newdream.net>
Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      b5f53b38
    • Sage Weil's avatar
      real_lookup() is called by do_lookup() if dentry revalidation fails. If · 6220eef6
      Sage Weil authored 
      the cache is re-populated while waiting for i_mutex, it may find that a
d_lookup() subsequently succeeds (see the "Uhhuh!  Nasty case" comment).

Previously, real_lookup() would drop i_mutex and do_revalidate() again. 
If revalidate failed _again_, however, it would give up with -ENOENT.  The
problem here that network file systems may be invalidating dentries via
server callbacks, e.g.  due to concurrent access from another client, and
-ENOENT is frequently the wrong answer.

This problem has been seen with both Lustre and Ceph.  It seems possible
to hit this case with NFS as well if the cache lifetime is very short.

Instead, we should do_revalidate() while i_mutex is still held.  If
revalidation fails, we can move on to a ->lookup() and ensure a correct
result without worrying about any subsequent races.

Note that do_revalidate() is called with i_mutex held elsewhere.  For
example, do_filp_open(), lookup_create(), do_unlinkat(), do_rmdir(), and
possibly others all take the directory i_mutex, and then

-> lookup_hash
        -> __lookup_hash
                -> cached_lookup
                        -> do_revalidate

so this does not introduce any new locking rules for d_revalidate
implementations.

Yes, the goto is ugly.  A cleanup patch follows.

Cc: Ian Kent <raven@themaw.net>
Cc: Christoph Hellwig <hch@infradead.org>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Andreas Dilger <adilger@sun.com>
Signed-off-by: default avatarYehuda Sadeh <yehuda@newdream.net>
Signed-off-by: default avatarSage Weil <sage@newdream.net>
Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      6220eef6
  9. 24 Sep, 2009 2 commits
    • Nick Piggin's avatar
      Invalidate sb->s_bdev on remount,ro. · d7dde392
      Nick Piggin authored 
      Fixes a problem reported by Jorge Boncompte who is seeing corruption
trying to snapshot a minix filesystem image.  Some filesystems modify
their metadata via a path other than the bdev buffer cache (eg.  they may
use a private linear mapping for their metadata, or implement directories
in pagecache, etc).  Also, file data modifications usually go to the bdev
via their own mappings.

These updates are not coherent with buffercache IO (eg.  via /dev/bdev)
and never have been.  However there could be a reasonable expectation that
after a mount -oremount,ro operation then the buffercache should
subsequently be coherent with previous filesystem modifications.

So invalidate the bdev mappings on a remount,ro operation to provide a
coherency point.

The problem was exposed when we switched the old rd to brd because old rd
didn't really function like a normal block device and updates to rd via
mappings other than the buffercache would still end up going into its
buffercache.  But the same problem has always affected other "normal"
block devices, including loop.

[akpm@linux-foundation.org: repair comment layout]
Reported-by: default avatar"Jorge Boncompte [DTI2]" <jorge@dti2.net>
Tested-by: default avatar"Jorge Boncompte [DTI2]" <jorge@dti2.net>
Signed-off-by: default avatarNick Piggin <npiggin@suse.de>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      d7dde392
    • Nick Piggin's avatar
      Filesystems outside the regular namespace do not have to clear · 4bca9bd4
      Nick Piggin authored 
      DCACHE_UNHASHED in order to have a working /proc/$pid/fd/XXX.  Nothing in
proc prevents the fd link from being used if its dentry is not in the
hash.

Also, it does not get put into the dcache hash if DCACHE_UNHASHED is
clear; that depends on the filesystem calling d_add or d_rehash.

So delete the misleading comments and needless code.
Acked-by: default avatarMiklos Szeredi <mszeredi@suse.cz>
Signed-off-by: default avatarNick Piggin <npiggin@suse.de>
Cc: Davide Libenzi <davidel@xmailserver.org>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Jens Axboe <jens.axboe@oracle.com>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      4bca9bd4
  11. 25 Sep, 2009 1 commit
    • Roland Dreier's avatar
      > ============================================= · a470a30a
      Roland Dreier authored 
       >  [ INFO: possible recursive locking detected ]
 >  2.6.31-2-generic #14~rbd3
 >  ---------------------------------------------
 >  firefox-3.5/4162 is trying to acquire lock:
 >   (&s->s_vfs_rename_mutex){+.+.+.}, at: [<ffffffff81139d31>] lock_rename+0x41/0xf0
 >
 >  but task is already holding lock:
 >   (&s->s_vfs_rename_mutex){+.+.+.}, at: [<ffffffff81139d31>] lock_rename+0x41/0xf0
 >
 >  other info that might help us debug this:
 >  3 locks held by firefox-3.5/4162:
 >   #0:  (&s->s_vfs_rename_mutex){+.+.+.}, at: [<ffffffff81139d31>] lock_rename+0x41/0xf0
 >   #1:  (&sb->s_type->i_mutex_key#11/1){+.+.+.}, at: [<ffffffff81139d5a>] lock_rename+0x6a/0xf0
 >   #2:  (&sb->s_type->i_mutex_key#11/2){+.+.+.}, at: [<ffffffff81139d6f>] lock_rename+0x7f/0xf0
 >
 >  stack backtrace:
 >  Pid: 4162, comm: firefox-3.5 Tainted: G         C 2.6.31-2-generic #14~rbd3
 >  Call Trace:
 >   [<ffffffff8108ae74>] print_deadlock_bug+0xf4/0x100
 >   [<ffffffff8108ce26>] validate_chain+0x4c6/0x750
 >   [<ffffffff8108d2e7>] __lock_acquire+0x237/0x430
 >   [<ffffffff8108d585>] lock_acquire+0xa5/0x150
 >   [<ffffffff81139d31>] ? lock_rename+0x41/0xf0
 >   [<ffffffff815526ad>] __mutex_lock_common+0x4d/0x3d0
 >   [<ffffffff81139d31>] ? lock_rename+0x41/0xf0
 >   [<ffffffff81139d31>] ? lock_rename+0x41/0xf0
 >   [<ffffffff8120eaf9>] ? ecryptfs_rename+0x99/0x170
 >   [<ffffffff81552b36>] mutex_lock_nested+0x46/0x60
 >   [<ffffffff81139d31>] lock_rename+0x41/0xf0
 >   [<ffffffff8120eb2a>] ecryptfs_rename+0xca/0x170
 >   [<ffffffff81139a9e>] vfs_rename_dir+0x13e/0x160
 >   [<ffffffff8113ac7e>] vfs_rename+0xee/0x290
 >   [<ffffffff8113c212>] ? __lookup_hash+0x102/0x160
 >   [<ffffffff8113d512>] sys_renameat+0x252/0x280
 >   [<ffffffff81133eb4>] ? cp_new_stat+0xe4/0x100
 >   [<ffffffff8101316a>] ? sysret_check+0x2e/0x69
 >   [<ffffffff8108c34d>] ? trace_hardirqs_on_caller+0x14d/0x190
 >   [<ffffffff8113d55b>] sys_rename+0x1b/0x20
 >   [<ffffffff81013132>] system_call_fastpath+0x16/0x1b

The trace above is totally reproducible by doing a cross-directory
rename on an ecryptfs directory.

The issue seems to be that sys_renameat() does lock_rename() then calls
into the filesystem; if the filesystem is ecryptfs, then
ecryptfs_rename() again does lock_rename() on the lower filesystem, and
lockdep can't tell that the two s_vfs_rename_mutexes are different.  It
seems an annotation like the following is sufficient to fix this (it
does get rid of the lockdep trace in my simple tests); however I would
like to make sure I'm not misunderstanding the locking, hence the CC
list...
Signed-off-by: default avatarRoland Dreier <rdreier@cisco.com>
Cc: Tyler Hicks <tyhicks@linux.vnet.ibm.com>
Cc: Dustin Kirkland <kirkland@canonical.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      a470a30a
  13. 20 Apr, 2009 1 commit
  15. 24 Aug, 2009 1 commit
    • Al Viro's avatar
      RAW_SETBIND and RAW_GETBIND 32bit versions are fscked in interesting ways. · cb8c8dac
      Al Viro authored 
      1) fs/compat_ioctl.c has COMPATIBLE_IOCTL(RAW_SETBIND) followed by
HANDLE_IOCTL(RAW_SETBIND, raw_ioctl).  The latter is ignored.

2) on amd64 (and itanic) the damn thing is broken - we have int + u64 + u64
and layouts on i386 and amd64 are _not_ the same.  raw_ioctl() would
work there, but it's never called due to (1).  As it is, i386 /sbin/raw
definitely doesn't work on amd64 boxen.

3) switching to raw_ioctl() as is would *not* work on e.g. sparc64 and ppc64,
which would be rather sad, seeing that normal userland there is 32bit.
The thing is, slapping __packed on the struct in question does not DTRT -
it eliminates *all* padding.  The real solution is to use compat_u64.

4) of course, all that stuff has no business being outside of raw.c in the
first place - there should be ->compat_ioctl() for /dev/rawctl instead of
messing with compat_ioctl.c.

[akpm@linux-foundation.org: coding-style fixes]
Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      cb8c8dac
  17. 25 Sep, 2009 1 commit
    • Miklos Szeredi's avatar
      vfs_rename_dir() doesn't properly account for filesystems with · 07431498
      Miklos Szeredi authored 
      FS_RENAME_DOES_D_MOVE.  If new_dentry has a target inode attached, it
unhashes the new_dentry prior to the rename() iop and rehashes it after,
but doesn't account for the possibility that rename() may have swapped
{old,new}_dentry.  For FS_RENAME_DOES_D_MOVE filesystems, it rehashes
new_dentry (now the old renamed-from name, which d_move() expected to go
away), such that a subsequent lookup will find it.

This was caught by the recently posted POSIX fstest suite, rename/10.t
test 62 (and others) on ceph.

The bug was introduced by: commit 349457cc
"[PATCH] Allow file systems to manually d_move() inside of ->rename()"

Fix by not rehashing the new dentry.  Rehashing used to be needed by
d_move() but isn't anymore.
Reported-by: default avatarSage Weil <sage@newdream.net>
Cc: Zach Brown <zach.brown@oracle.com>
Signed-off-by: default avatarMiklos Szeredi <mszeredi@suse.cz>
Cc: Mark Fasheh <mark.fasheh@oracle.com>
Cc: Trond Myklebust <trond.myklebust@fys.uio.no>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Christoph Hellwig <hch@lst.de>
Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      07431498
  19. 06 Oct, 2009 1 commit
  21. 13 Oct, 2009 1 commit
  23. 09 Oct, 2009 1 commit
  25. 10 Oct, 2009 1 commit
  27. 09 Oct, 2009 1 commit
  29. 15 Oct, 2009 1 commit
  31. 14 Oct, 2009 1 commit
  33. 29 Sep, 2009 1 commit
  35. 19 Sep, 2009 1 commit
  37. 25 Sep, 2009 2 commits
  39. 20 Aug, 2009 1 commit
  41. 04 Aug, 2009 2 commits
  43. 29 Jul, 2009 1 commit
  45. 25 Sep, 2009 1 commit
  47. 29 Jul, 2009 1 commit
  49. 25 Sep, 2009 1 commit
  51. 19 Sep, 2009 1 commit
  53. 11 Aug, 2009 1 commit
  55. 06 Oct, 2009 1 commit
    • Andrew Morton's avatar
      do_div() takes a u64. The mips build warns: · 069b4675
      Andrew Morton authored 
      In file included from include/trace/ftrace.h:635,
                 from include/trace/define_trace.h:61,
                 from include/trace/events/lockdep.h:96,
                 from kernel/lockdep.c:52:
include/trace/events/lockdep.h: In function `ftrace_raw_event_lock_acquired':
include/trace/events/lockdep.h:71: warning: comparison of distinct pointer types lacks a cast

from the check in include/asm-generic/div64.h:do_div().

Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      069b4675
  57. 16 Oct, 2009 1 commit
    • Stephen Boyd's avatar
      dmar_ir_support() references dmar_tbl which is annotated with · b8882458
      Stephen Boyd authored 
      __initdata. The only caller of dmar_ir_support() is
intr_remapping_supported() also annotated with __init.

WARNING: drivers/pci/built-in.o(.text+0xa110): Section mismatch in
reference from the function dmar_ir_support() to the variable
.init.data:dmar_tbl
The function dmar_ir_support() references
the variable __initdata dmar_tbl.
This is often because dmar_ir_support lacks a __initdata
annotation or the annotation of dmar_tbl is wrong.
Signed-off-by: default avatarStephen Boyd <bebarino@gmail.com>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: David Woodhouse <David.Woodhouse@intel.com>
Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      b8882458
  59. 14 Oct, 2009 1 commit
  61. 31 Oct, 2009 1 commit
  63. 30 Sep, 2009 1 commit
    • sonic zhang's avatar
      Fit blackfin uart over sport driver into common uart inftrastructure. It · 855d8f84
      sonic zhang authored 
      is based on the early platform interfaces to get the platform data early
when the console is initilized.

1. Enable sport uart driver to change uart baud, data bit, stop bit at
   runtime.  Bind the index of uart device nodes to physical index of
   sports.

2. Move all platform data into arch specific board files.  Register
   and probe platform device data in both early and normal stages.

3. Console is registered in sport uart driver as well.

4. Remove 500 us block waiting in sport tx stop code by putting a
   dummy data into tx fifo to make sure the sport tx stops when all bytes
   are shifted out except for the dummy data.

5. clean up a bit and fix up coding style.
Signed-off-by: default avatarSonic Zhang <sonic.zhang@analog.com>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Mike Frysinger <vapier@gentoo.org>
Cc: Bryan Wu <cooloney@kernel.org>
Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      855d8f84
  65. 13 Jul, 2009 1 commit
  67. 25 Sep, 2009 2 commits
    • Lamarque Vieira Souza's avatar
      Work around one problem with my Acer Bluetooth Optical Rechargeable Mouse · 2f89b8bd
      Lamarque Vieira Souza authored 
      where the cursor gets stuck at screen's upper-left corner.

Even my notebook's touchpad is not able to move cursor when the bluetooth
mouse is connected to my Acer Ferrari 4005 notebook.

Using input session instead of hid session solves this problem although
the cursor still moves a little sluggishly with the bluetooth mouse,
cursor moves correctly using the touchpad.

My bluetooth mouse used to work well (no sluggish) until kernel 2.6.21,
since then the problems are getting worse with each kernel release (it got
sluggish in 2.6.22 and this this upper-left corner problem appeared in
2.6.28 or 2.6.27).

The patch adds a general quirk handling framework to the HIDP core and
then uses this framework to implement a quirk for this device.

[akpm@linux-foundation.org: use ARRAY_SIZE()-based search]
Signed-off-by: default avatarLamarque V. Souza <lamarque@gmail.com>
Cc: Marcel Holtmann <marcel@holtmann.org>
Cc: Dave Young <hidave.darkstar@gmail.com>
Cc: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      2f89b8bd
    • Sergei Shtylyov's avatar
      The driver wrongly claimed I/O ports at an address returned by pci_iomap() · 85d8c0b0
      Sergei Shtylyov authored 
      -- even if it was passed an MMIO address.  Fix this by claiming/releasing
all PCI resources in the PCI driver probe/remove handlers instead and get
rid of the must_free_region flag weirdness (why would Cardbus claim
anything for us?).

Also, the remove handler was trying to talk to the chip after having
disabled its address decoders (at least on x86) -- fix this and get rid of
useless VORTEX_PCI() calls.

While at it, fix some cases of the overly indented code...

[akpm@linux-foundation.org: coding-style fixes]
Signed-off-by: default avatarSergei Shtylyov <sshtylyov@ru.mvista.com>
Cc: Steffen Klassert <klassert@mathematik.tu-chemnitz.de>
Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      85d8c0b0
  69. 14 Oct, 2009 1 commit