Skip to content

L
linux-davinci
Switch branch/tag
  1. 11 Nov, 2009 4 commits
    • Roland Dreier's avatar
      > ============================================= · 399da0ba
      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>
      399da0ba
    • Tony Battersby's avatar
      Improve the description of fget_light(), which is currently incorrect · bc95777a
      Tony Battersby authored 
      about needing a prior refcnt (judging by the way it is actually used).
Signed-off-by: default avatarTony Battersby <tonyb@cybernetics.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      bc95777a
    • Al Viro's avatar
      RAW_SETBIND and RAW_GETBIND 32bit versions are fscked in interesting ways. · 0083395f
      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>
      0083395f
    • Miklos Szeredi's avatar
      vfs_rename_dir() doesn't properly account for filesystems with · ca05021f
      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>
      ca05021f
  3. 10 Nov, 2009 1 commit
  5. 09 Nov, 2009 1 commit
  7. 06 Oct, 2009 1 commit
  9. 03 Nov, 2009 2 commits
  11. 12 Nov, 2009 1 commit
    • Alex Chiang's avatar
      No need to export those device attributes. · 7b53d30e
      Alex Chiang authored 
      In fact, without this patch, we can trip over a build error if hpsa
is a built-in and another driver also declares and exports attributes
with the same name.

You'll see errors like:

	drivers/scsi/built-in.o: multiple definition of `dev_attr_lunid'
	drivers/block/built-in.o: first defined here
Signed-off-by: default avatarAlex Chiang <achiang@hp.com>
Cc: Stephen M. Cameron <scameron@beardog.cce.hp.com>
Cc: Mike Miller <mikem@beardog.cce.hp.com>
Cc: Jens Axboe <jens.axboe@oracle.com>
Cc: James Bottomley <James.Bottomley@HansenPartnership.com>
Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      7b53d30e
  13. 17 Nov, 2009 1 commit
  15. 03 Nov, 2009 1 commit
  17. 14 Oct, 2009 1 commit
  19. 29 Sep, 2009 1 commit
  21. 18 Sep, 2009 1 commit
  23. 11 Nov, 2009 1 commit
  25. 25 Sep, 2009 1 commit
  27. 20 Aug, 2009 1 commit
  29. 04 Aug, 2009 2 commits
  31. 29 Jul, 2009 1 commit
  33. 25 Sep, 2009 1 commit
  35. 29 Jul, 2009 1 commit
  37. 25 Sep, 2009 1 commit
  39. 11 Nov, 2009 1 commit
  41. 17 Sep, 2009 1 commit
  43. 16 Oct, 2009 1 commit
    • Stephen Boyd's avatar
      dmar_ir_support() references dmar_tbl which is annotated with · c38a8607
      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>
      c38a8607
  45. 14 Nov, 2009 1 commit
    • Dick Hollenbeck's avatar
      When controlling an industrial radio modem it can be necessary to · 4f36dc27
      Dick Hollenbeck authored 
      manipulate the handshake lines in order to control the radio modem's
transmitter, from userspace.

The transmitter should not be turned off before all characters have been
transmitted.  serial8250_tx_empty() was reporting that all characters were
transmitted before they actually were.

===

Discovered in parallel with more testing and analysis by Kees Schoenmakers
as follows:

I ran into an NetMos 9835 serial pci board which behaves a little
different than the standard.  This type of expansion board is very common.

"Standard" 8250 compatible devices clear the 'UART_LST_TEMT" bit together
with the "UART_LSR_THRE" bit when writing data to the device.

The NetMos device does it slightly different

I believe that the TEMT bit is coupled to the shift register.  The problem
is that after writing data to the device and very quickly after that one
does call serial8250_tx_empty, it returns the wrong information.

My patch makes the test more robust (and solves the problem) and it does
not affect the already correct devices.


Alan:

  We may yet need to quirk this but now we know which chips we have a
  way to do that should we find this breaks some other 8250 clone with
  dodgy THRE.
Signed-off-by: default avatarDick Hollenbeck <dick@softplc.com>
Signed-off-by: default avatarAlan Cox <alan@linux.intel.com>
Cc: Kees Schoenmakers <k.schoenmakers@sigmae.nl>
Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      4f36dc27
  47. 12 Nov, 2009 3 commits
  49. 11 Nov, 2009 2 commits
  51. 30 Sep, 2009 1 commit
    • sonic zhang's avatar
      Fit blackfin uart over sport driver into common uart inftrastructure. It · 195fd228
      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>
      195fd228
  53. 17 Sep, 2009 1 commit
  55. 25 Sep, 2009 1 commit
    • Lamarque Vieira Souza's avatar
      Work around one problem with my Acer Bluetooth Optical Rechargeable Mouse · f4ab3880
      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>
      f4ab3880
  57. 11 Nov, 2009 1 commit
  59. 16 Nov, 2009 1 commit
  61. 12 Nov, 2009 1 commit
  63. 17 Nov, 2009 1 commit