1. 21 Aug, 2009 1 commit
    • Amerigo Wang's avatar
      vfs: allow file truncations when both suid and write permissions set · 939a9421
      Amerigo Wang authored
      When suid is set and the non-owner user has write permission, any writing
      into this file should be allowed and suid should be removed after that.
      
      However, current kernel only allows writing without truncations, when we
      do truncations on that file, we get EPERM.  This is a bug.
      
      Steps to reproduce this bug:
      
      % ls -l rootdir/file1
      -rwsrwsrwx 1 root root 3 Jun 25 15:42 rootdir/file1
      % echo h > rootdir/file1
      zsh: operation not permitted: rootdir/file1
      % ls -l rootdir/file1
      -rwsrwsrwx 1 root root 3 Jun 25 15:42 rootdir/file1
      % echo h >> rootdir/file1
      % ls -l rootdir/file1
      -rwxrwxrwx 1 root root 5 Jun 25 16:34 rootdir/file1
      Signed-off-by: default avatarWANG Cong <amwang@redhat.com>
      Cc: Eric Sandeen <esandeen@redhat.com>
      Acked-by: default avatarEric Paris <eparis@redhat.com>
      Cc: Eugene Teo <eteo@redhat.com>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
      Cc: Christoph Hellwig <hch@lst.de>
      Cc: Stephen Smalley <sds@tycho.nsa.gov>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarJames Morris <jmorris@namei.org>
      939a9421
  2. 18 Aug, 2009 4 commits
    • KOSAKI Motohiro's avatar
      mm: revert "oom: move oom_adj value" · 0753ba01
      KOSAKI Motohiro authored
      The commit 2ff05b2b (oom: move oom_adj value) moveed the oom_adj value to
      the mm_struct.  It was a very good first step for sanitize OOM.
      
      However Paul Menage reported the commit makes regression to his job
      scheduler.  Current OOM logic can kill OOM_DISABLED process.
      
      Why? His program has the code of similar to the following.
      
      	...
      	set_oom_adj(OOM_DISABLE); /* The job scheduler never killed by oom */
      	...
      	if (vfork() == 0) {
      		set_oom_adj(0); /* Invoked child can be killed */
      		execve("foo-bar-cmd");
      	}
      	....
      
      vfork() parent and child are shared the same mm_struct.  then above
      set_oom_adj(0) doesn't only change oom_adj for vfork() child, it's also
      change oom_adj for vfork() parent.  Then, vfork() parent (job scheduler)
      lost OOM immune and it was killed.
      
      Actually, fork-setting-exec idiom is very frequently used in userland program.
      We must not break this assumption.
      
      Then, this patch revert commit 2ff05b2b and related commit.
      
      Reverted commit list
      ---------------------
      - commit 2ff05b2b (oom: move oom_adj value from task_struct to mm_struct)
      - commit 4d8b9135 (oom: avoid unnecessary mm locking and scanning for OOM_DISABLE)
      - commit 81236810 (oom: only oom kill exiting tasks with attached memory)
      - commit 933b787b (mm: copy over oom_adj value at fork time)
      Signed-off-by: default avatarKOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
      Cc: Paul Menage <menage@google.com>
      Cc: David Rientjes <rientjes@google.com>
      Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
      Cc: Rik van Riel <riel@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Nick Piggin <npiggin@suse.de>
      Cc: Mel Gorman <mel@csn.ul.ie>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      0753ba01
    • Jeff Layton's avatar
      vfs: make get_sb_pseudo set s_maxbytes to value that can be cast to signed · 89a4eb4b
      Jeff Layton authored
      get_sb_pseudo sets s_maxbytes to ~0ULL which becomes negative when cast
      to a signed value.  Fix it to use MAX_LFS_FILESIZE which casts properly
      to a positive signed value.
      Signed-off-by: default avatarJeff Layton <jlayton@redhat.com>
      Reviewed-by: default avatarJohannes Weiner <hannes@cmpxchg.org>
      Acked-by: default avatarSteve French <smfrench@gmail.com>
      Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: Robert Love <rlove@google.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      89a4eb4b
    • Ryusuke Konishi's avatar
      nilfs2: fix oopses with doubly mounted snapshots · a9245860
      Ryusuke Konishi authored
      will fix kernel oopses like the following:
      
       # mount -t nilfs2 -r -o cp=20 /dev/sdb1 /test1
       # mount -t nilfs2 -r -o cp=20 /dev/sdb1 /test2
       # umount /test1
       # umount /test2
      
      BUG: sleeping function called from invalid context at arch/x86/mm/fault.c:1069
      in_atomic(): 0, irqs_disabled(): 1, pid: 3886, name: umount.nilfs2
      1 lock held by umount.nilfs2/3886:
       #0:  (&type->s_umount_key#31){+.+...}, at: [<c10b398a>] deactivate_super+0x52/0x6c
      irq event stamp: 1219
      hardirqs last  enabled at (1219): [<c135c774>] __mutex_unlock_slowpath+0xf8/0x119
      hardirqs last disabled at (1218): [<c135c6d5>] __mutex_unlock_slowpath+0x59/0x119
      softirqs last  enabled at (1214): [<c1033316>] __do_softirq+0x1a5/0x1ad
      softirqs last disabled at (1205): [<c1033354>] do_softirq+0x36/0x5a
      Pid: 3886, comm: umount.nilfs2 Not tainted 2.6.31-rc6 #55
      Call Trace:
       [<c1023549>] __might_sleep+0x107/0x10e
       [<c13603c0>] do_page_fault+0x246/0x397
       [<c136017a>] ? do_page_fault+0x0/0x397
       [<c135e753>] error_code+0x6b/0x70
       [<c136017a>] ? do_page_fault+0x0/0x397
       [<c104f805>] ? __lock_acquire+0x91/0x12fd
       [<c1050a62>] ? __lock_acquire+0x12ee/0x12fd
       [<c1050a62>] ? __lock_acquire+0x12ee/0x12fd
       [<c1050b2b>] lock_acquire+0xba/0xdd
       [<d0d17d3f>] ? nilfs_detach_segment_constructor+0x2f/0x2fa [nilfs2]
       [<c135d4fe>] down_write+0x2a/0x46
       [<d0d17d3f>] ? nilfs_detach_segment_constructor+0x2f/0x2fa [nilfs2]
       [<d0d17d3f>] nilfs_detach_segment_constructor+0x2f/0x2fa [nilfs2]
       [<c104ea2c>] ? mark_held_locks+0x43/0x5b
       [<c104ecb1>] ? trace_hardirqs_on_caller+0x10b/0x133
       [<c104ece4>] ? trace_hardirqs_on+0xb/0xd
       [<d0d09ac1>] nilfs_put_super+0x2f/0xca [nilfs2]
       [<c10b3352>] generic_shutdown_super+0x49/0xb8
       [<c10b33de>] kill_block_super+0x1d/0x31
       [<c10e6599>] ? vfs_quota_off+0x0/0x12
       [<c10b398f>] deactivate_super+0x57/0x6c
       [<c10c4bc3>] mntput_no_expire+0x8c/0xb4
       [<c10c5094>] sys_umount+0x27f/0x2a4
       [<c10c50c6>] sys_oldumount+0xd/0xf
       [<c10031a4>] sysenter_do_call+0x12/0x38
       ...
      
      This turns out to be a bug brought by an -rc1 patch ("nilfs2: simplify
      remaining sget() use").
      
      In the patch, a new "put resource" function, nilfs_put_sbinfo()
      was introduced to delay freeing nilfs_sb_info struct.
      
      But the nilfs_put_sbinfo() mistakenly used atomic_dec_and_test()
      function to check the reference count, and it caused the nilfs_sb_info
      was freed when user mounted a snapshot twice.
      
      This bug also suggests there was unseen memory leak in usual mount
      /umount operations for nilfs.
      Signed-off-by: default avatarRyusuke Konishi <konishi.ryusuke@lab.ntt.co.jp>
      a9245860
    • Zhang Qiang's avatar
      nilfs2: missing a read lock for segment writer in nilfs_attach_checkpoint() · 1154ecbd
      Zhang Qiang authored
      'ns_cno' of structure 'the_nilfs' must be protected from segment
      writer, in other words, the caller of nilfs_get_checkpoint should hold
      read lock for nilfs->ns_segctor_sem.  This patch adds the lock/unlock
      operations in nilfs_attach_checkpoint() when calling
      nilfs_cpfile_get_checkpoint().
      Signed-off-by: default avatarZhang Qiang <zhangqiang.buaa@gmail.com>
      Signed-off-by: default avatarRyusuke Konishi <konishi.ryusuke@lab.ntt.co.jp>
      1154ecbd
  3. 17 Aug, 2009 4 commits
    • Eric Paris's avatar
      inotify: start watch descriptor count at 1 · 08e53fcb
      Eric Paris authored
      The inotify_add_watch man page specifies that inotify_add_watch() will
      return a non-negative integer.  However, historically the inotify
      watches started at 1, not at 0.
      
      Turns out that the inotifywait program provided by the inotify-tools
      package doesn't properly handle a 0 watch descriptor.  In 7e790dd5 we
      changed from starting at 1 to starting at 0.  This patch starts at 1,
      just like in previous kernels, but also just like in previous kernels
      it's possible for it to wrap back to 0.  This preserves the kernel
      functionality exactly like it was before the patch (neither method broke
      the spec)
      Signed-off-by: default avatarEric Paris <eparis@redhat.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      08e53fcb
    • Eric Paris's avatar
      inotify: tail drop inotify q_overflow events · cd94c8bb
      Eric Paris authored
      In f44aebcc the tail drop logic of events with no file backing
      (q_overflow and in_ignored) was reversed so IN_IGNORED events would
      never be tail dropped.  This now means that Q_OVERFLOW events are NOT
      tail dropped.  The fix is to not tail drop IN_IGNORED, but to tail drop
      Q_OVERFLOW.
      Signed-off-by: default avatarEric Paris <eparis@redhat.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      cd94c8bb
    • Eric Paris's avatar
      notify: unused event private race · eef3a116
      Eric Paris authored
      inotify decides if private data it passed to get added to an event was
      used by checking list_empty().  But it's possible that the event may
      have been dequeued and the private event removed so it would look empty.
      
      The fix is to use the return code from fsnotify_add_notify_event rather
      than looking at the list.
      Signed-off-by: default avatarEric Paris <eparis@redhat.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      eef3a116
    • Christoph Hellwig's avatar
      xfs: fix locking in xfs_iget_cache_hit · bc990f5c
      Christoph Hellwig authored
      The locking in xfs_iget_cache_hit currently has numerous problems:
      
       - we clear the reclaim tag without i_flags_lock which protects
         modifications to it
       - we call inode_init_always which can sleep with pag_ici_lock
         held (this is oss.sgi.com BZ #819)
       - we acquire and drop i_flags_lock a lot and thus provide no
         consistency between the various flags we set/clear under it
      
      This patch fixes all that with a major revamp of the locking in
      the function.  The new version acquires i_flags_lock early and
      only drops it once we need to call into inode_init_always or before
      calling xfs_ilock.
      
      This patch fixes a bug seen in the wild where we race modifying the
      reclaim tag.
      Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
      Reviewed-by: default avatarFelix Blyakher <felixb@sgi.com>
      Reviewed-by: default avatarEric Sandeen <sandeen@sandeen.net>
      Signed-off-by: default avatarFelix Blyakher <felixb@sgi.com>
      bc990f5c
  4. 16 Aug, 2009 1 commit
  5. 14 Aug, 2009 1 commit
  6. 12 Aug, 2009 13 commits
  7. 10 Aug, 2009 6 commits
  8. 07 Aug, 2009 10 commits