Skip to content

L
linux-davinci
Switch branch/tag
  1. 09 Nov, 2009 2 commits
    • Al Viro's avatar
      RAW_SETBIND and RAW_GETBIND 32bit versions are fscked in interesting ways. · 45382bef
      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>
      45382bef
    • Miklos Szeredi's avatar
      vfs_rename_dir() doesn't properly account for filesystems with · 920a06de
      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>
      920a06de
  3. 10 Nov, 2009 1 commit
  5. 09 Nov, 2009 1 commit
  7. 12 Nov, 2009 1 commit
    • Alex Chiang's avatar
      No need to export those device attributes. · 6a5248d6
      Alex Chiang authored 
      In fact, without this patch, we can trip over a build error if cciss
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

Cc: Stephen M. Cameron <scameron@beardog.cce.hp.com>
Signed-off-by: default avatarAlex Chiang <achiang@hp.com>
Cc: <mike.miller@hp.com>
Cc: Jens Axboe <jens.axboe@oracle.com>
Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      6a5248d6
  9. 06 Oct, 2009 1 commit
  11. 03 Nov, 2009 2 commits
  13. 12 Nov, 2009 14 commits
  15. 13 Oct, 2009 1 commit
  17. 09 Oct, 2009 1 commit
  19. 10 Oct, 2009 1 commit
  21. 09 Nov, 2009 1 commit
  23. 03 Nov, 2009 1 commit
  25. 14 Oct, 2009 1 commit
  27. 29 Sep, 2009 1 commit
  29. 19 Sep, 2009 1 commit
  31. 09 Nov, 2009 1 commit
  33. 25 Sep, 2009 1 commit
  35. 20 Aug, 2009 1 commit
  37. 04 Aug, 2009 2 commits
  39. 29 Jul, 2009 1 commit
  41. 25 Sep, 2009 1 commit
  43. 29 Jul, 2009 1 commit
  45. 25 Sep, 2009 1 commit
  47. 09 Nov, 2009 1 commit