1. 08 11月, 2009 2 次提交
    • R
      nilfs2: fix missing cleanup of gc cache on error cases · c083234f
      Ryusuke Konishi 提交于
      This fixes an -rc1 regression brought by the commit:
      1cf58fa8 ("nilfs2: shorten freeze
      period due to GC in write operation v3").
      
      Although the patch moved out a function call of
      nilfs_ioctl_move_blocks() to nilfs_ioctl_clean_segments() from
      nilfs_ioctl_prepare_clean_segments(), it didn't move corresponding
      cleanup job needed for the error case.
      
      This will move the missing cleanup job to the destination function.
      Signed-off-by: NRyusuke Konishi <konishi.ryusuke@lab.ntt.co.jp>
      Acked-by: NJiro SEKIBA <jir@unicus.jp>
      c083234f
    • R
      nilfs2: fix kernel oops in error case of nilfs_ioctl_move_blocks · 5399dd1f
      Ryusuke Konishi 提交于
      This fixes a kernel oops reported by Markus Trippelsdorf in the email
      titled "[NILFS users] kernel Oops while running nilfs_cleanerd".
      
      The oops was caused by a bug of error path in
      nilfs_ioctl_move_blocks() function, which was inlined in
      nilfs_ioctl_clean_segments().
      
      nilfs_ioctl_move_blocks checks duplication of blocks which will be
      moved in garbage collection.  But, the check should have be done
      within nilfs_ioctl_move_inode_block() to prevent list corruption among
      buffers storing the target blocks.
      
      To fix the kernel oops, this moves forward the duplication check
      before the list insertion.
      
      I also tested this for stable trees [2.6.30, 2.6.31].
      Reported-by: NMarkus Trippelsdorf <markus@trippelsdorf.de>
      Signed-off-by: NRyusuke Konishi <konishi.ryusuke@lab.ntt.co.jp>
      Cc: stable <stable@kernel.org>
      5399dd1f
  2. 07 11月, 2009 2 次提交
    • J
      cifs: don't use CIFSGetSrvInodeNumber in is_path_accessible · f475f677
      Jeff Layton 提交于
      Because it's lighter weight, CIFS tries to use CIFSGetSrvInodeNumber to
      verify the accessibility of the root inode and then falls back to doing a
      full QPathInfo if that fails with -EOPNOTSUPP. I have at least a report
      of a server that returns NT_STATUS_INTERNAL_ERROR rather than something
      that translates to EOPNOTSUPP.
      
      Rather than trying to be clever with that call, just have
      is_path_accessible do a normal QPathInfo. That call is widely
      supported and it shouldn't increase the overhead significantly.
      
      Cc: Stable <stable@kernel.org>
      Signed-off-by: NJeff Layton <jlayton@redhat.com>
      Signed-off-by: NSteve French <sfrench@us.ibm.com>
      f475f677
    • J
      cifs: clean up handling when server doesn't consistently support inode numbers · ec06aedd
      Jeff Layton 提交于
      It's possible that a server will return a valid FileID when we query the
      FILE_INTERNAL_INFO for the root inode, but then zeroed out inode numbers
      when we do a FindFile with an infolevel of
      SMB_FIND_FILE_ID_FULL_DIR_INFO.
      
      In this situation turn off querying for server inode numbers, generate a
      warning for the user and just generate an inode number using iunique.
      Once we generate any inode number with iunique we can no longer use any
      server inode numbers or we risk collisions, so ensure that we don't do
      that in cifs_get_inode_info either.
      
      Cc: Stable <stable@kernel.org>
      Reported-by: NTimothy Normand Miller <theosib@gmail.com>
      Signed-off-by: NJeff Layton <jlayton@redhat.com>
      Signed-off-by: NSteve French <sfrench@us.ibm.com>
      ec06aedd
  3. 05 11月, 2009 1 次提交
  4. 04 11月, 2009 4 次提交
  5. 03 11月, 2009 4 次提交
  6. 02 11月, 2009 5 次提交
  7. 30 10月, 2009 3 次提交
  8. 29 10月, 2009 3 次提交
  9. 27 10月, 2009 2 次提交
  10. 26 10月, 2009 3 次提交
  11. 24 10月, 2009 2 次提交
    • T
      NFSv4: Fix a bug when the server returns NFS4ERR_RESOURCE · 52567b03
      Trond Myklebust 提交于
      RFC 3530 states that when we recieve the error NFS4ERR_RESOURCE, we are not
      supposed to bump the sequence number on OPEN, LOCK, LOCKU, CLOSE, etc
      operations. The problem is that we map that error into EREMOTEIO in the XDR
      layer, and so the NFSv4 middle-layer routines like seqid_mutating_err(),
      and nfs_increment_seqid() don't recognise it.
      
      The fix is to defer the mapping until after the middle layers have
      processed the error.
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      52567b03
    • T
      nfs: Panic when commit fails · a8b40bc7
      Terry Loftin 提交于
      Actually pass the NFS_FILE_SYNC option to the server to avoid a
      Panic in nfs_direct_write_complete() when a commit fails.
      
      At the end of an nfs write, if the nfs commit fails, all the writes
      will be rescheduled.  They are supposed to be rescheduled as NFS_FILE_SYNC
      writes, but the rpc_task structure is not completely intialized and so
      the option is not passed.  When the rescheduled writes complete, the
      return indicates that they are NFS_UNSTABLE and we try to do another
      commit.  This leads to a Panic because the commit data structure pointer
      was set to null in the initial (failed) commit attempt.
      Signed-off-by: NTerry Loftin <terry.loftin@hp.com>
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      a8b40bc7
  12. 22 10月, 2009 2 次提交
    • Y
      nfs: Fix nfs_parse_mount_options() kfree() leak · 4223a4a1
      Yinghai Lu 提交于
      Fix a (small) memory leak in one of the error paths of the NFS mount
      options parsing code.
      
      Regression introduced in 2.6.30 by commit a67d18f8 (NFS: load the
      rpc/rdma transport module automatically).
      Reported-by: NYinghai Lu <yinghai@kernel.org>
      Reported-by: NPekka Enberg <penberg@cs.helsinki.fi>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      Cc: stable@kernel.org
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      4223a4a1
    • E
      fs: pipe.c null pointer dereference · ad396024
      Earl Chew 提交于
      This patch fixes a null pointer exception in pipe_rdwr_open() which
      generates the stack trace:
      
      > Unable to handle kernel NULL pointer dereference at 0000000000000028 RIP:
      >  [<ffffffff802899a5>] pipe_rdwr_open+0x35/0x70
      >  [<ffffffff8028125c>] __dentry_open+0x13c/0x230
      >  [<ffffffff8028143d>] do_filp_open+0x2d/0x40
      >  [<ffffffff802814aa>] do_sys_open+0x5a/0x100
      >  [<ffffffff8021faf3>] sysenter_do_call+0x1b/0x67
      
      The failure mode is triggered by an attempt to open an anonymous
      pipe via /proc/pid/fd/* as exemplified by this script:
      
      =============================================================
      while : ; do
         { echo y ; sleep 1 ; } | { while read ; do echo z$REPLY; done ; } &
         PID=$!
         OUT=$(ps -efl | grep 'sleep 1' | grep -v grep |
              { read PID REST ; echo $PID; } )
         OUT="${OUT%% *}"
         DELAY=$((RANDOM * 1000 / 32768))
         usleep $((DELAY * 1000 + RANDOM % 1000 ))
         echo n > /proc/$OUT/fd/1                 # Trigger defect
      done
      =============================================================
      
      Note that the failure window is quite small and I could only
      reliably reproduce the defect by inserting a small delay
      in pipe_rdwr_open(). For example:
      
       static int
       pipe_rdwr_open(struct inode *inode, struct file *filp)
       {
             msleep(100);
             mutex_lock(&inode->i_mutex);
      
      Although the defect was observed in pipe_rdwr_open(), I think it
      makes sense to replicate the change through all the pipe_*_open()
      functions.
      
      The core of the change is to verify that inode->i_pipe has not
      been released before attempting to manipulate it. If inode->i_pipe
      is no longer present, return ENOENT to indicate so.
      
      The comment about potentially using atomic_t for i_pipe->readers
      and i_pipe->writers has also been removed because it is no longer
      relevant in this context. The inode->i_mutex lock must be used so
      that inode->i_pipe can be dealt with correctly.
      Signed-off-by: NEarl Chew <earl_chew@agilent.com>
      Cc: stable@kernel.org
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      ad396024
  13. 21 10月, 2009 1 次提交
    • A
      dnotify: ignore FS_EVENT_ON_CHILD · 94552684
      Andreas Gruenbacher 提交于
      Mask off FS_EVENT_ON_CHILD in dnotify_handle_event().  Otherwise, when there
      is more than one watch on a directory and dnotify_should_send_event()
      succeeds, events with FS_EVENT_ON_CHILD set will trigger all watches and cause
      spurious events.
      
      This case was overlooked in commit e42e2773.
      
      	#define _GNU_SOURCE
      
      	#include <stdio.h>
      	#include <stdlib.h>
      	#include <unistd.h>
      	#include <signal.h>
      	#include <sys/types.h>
      	#include <sys/stat.h>
      	#include <fcntl.h>
      	#include <string.h>
      
      	static void create_event(int s, siginfo_t* si, void* p)
      	{
      		printf("create\n");
      	}
      
      	static void delete_event(int s, siginfo_t* si, void* p)
      	{
      		printf("delete\n");
      	}
      
      	int main (void) {
      		struct sigaction action;
      		char *tmpdir, *file;
      		int fd1, fd2;
      
      		sigemptyset (&action.sa_mask);
      		action.sa_flags = SA_SIGINFO;
      
      		action.sa_sigaction = create_event;
      		sigaction (SIGRTMIN + 0, &action, NULL);
      
      		action.sa_sigaction = delete_event;
      		sigaction (SIGRTMIN + 1, &action, NULL);
      
      	#	define TMPDIR "/tmp/test.XXXXXX"
      		tmpdir = malloc(strlen(TMPDIR) + 1);
      		strcpy(tmpdir, TMPDIR);
      		mkdtemp(tmpdir);
      
      	#	define TMPFILE "/file"
      		file = malloc(strlen(tmpdir) + strlen(TMPFILE) + 1);
      		sprintf(file, "%s/%s", tmpdir, TMPFILE);
      
      		fd1 = open (tmpdir, O_RDONLY);
      		fcntl(fd1, F_SETSIG, SIGRTMIN);
      		fcntl(fd1, F_NOTIFY, DN_MULTISHOT | DN_CREATE);
      
      		fd2 = open (tmpdir, O_RDONLY);
      		fcntl(fd2, F_SETSIG, SIGRTMIN + 1);
      		fcntl(fd2, F_NOTIFY, DN_MULTISHOT | DN_DELETE);
      
      		if (fork()) {
      			/* This triggers a create event */
      			creat(file, 0600);
      			/* This triggers a create and delete event (!) */
      			unlink(file);
      		} else {
      			sleep(1);
      			rmdir(tmpdir);
      		}
      
      		return 0;
      	}
      Signed-off-by: NAndreas Gruenbacher <agruen@suse.de>
      Signed-off-by: NEric Paris <eparis@redhat.com>
      94552684
  14. 19 10月, 2009 3 次提交
    • H
      HWPOISON: fix/proc/meminfo alignment · 5d5429af
      Hugh Dickins 提交于
      Given such a long name, the kB count in /proc/meminfo's HardwareCorrupted
      line is being shown too far right (it does align with x86_64's VmallocChunk
      above, but I hope nobody will ever have that much corrupted!).  Align it.
      Signed-off-by: NHugh Dickins <hugh.dickins@tiscali.co.uk>
      Signed-off-by: NAndi Kleen <ak@linux.intel.com>
      5d5429af
    • W
      inotify: fix coalesce duplicate events into a single event in special case · 3de0ef4f
      Wei Yongjun 提交于
      If we do rename a dir entry, like this:
      
        rename("/tmp/ino7UrgoJ.rename1", "/tmp/ino7UrgoJ.rename2")
        rename("/tmp/ino7UrgoJ.rename2", "/tmp/ino7UrgoJ")
      
      The duplicate events should be coalesced into a single event. But those two
      events do not be coalesced into a single event, due to some bad check in
      event_compare(). It can not match the two NULL inodes as the same event.
      Signed-off-by: NWei Yongjun <yjwei@cn.fujitsu.com>
      Signed-off-by: NEric Paris <eparis@redhat.com>
      3de0ef4f
    • E
      fsnotify: do not set group for a mark before it is on the i_list · 9f0d793b
      Eric Paris 提交于
      fsnotify_add_mark is supposed to add a mark to the g_list and i_list and to
      set the group and inode for the mark.  fsnotify_destroy_mark_by_entry uses
      the fact that ->group != NULL to know if this group should be destroyed or
      if it's already been done.
      
      But fsnotify_add_mark sets the group and inode before it actually adds the
      mark to the i_list and g_list.  This can result in a race in inotify, it
      requires 3 threads.
      
      sys_inotify_add_watch("file")	sys_inotify_add_watch("file")	sys_inotify_rm_watch([a])
      inotify_update_watch()
      inotify_new_watch()
      inotify_add_to_idr()
         ^--- returns wd = [a]
      				inotfiy_update_watch()
      				inotify_new_watch()
      				inotify_add_to_idr()
      				fsnotify_add_mark()
      				   ^--- returns wd = [b]
      				returns to userspace;
      								inotify_idr_find([a])
      								   ^--- gives us the pointer from task 1
      fsnotify_add_mark()
         ^--- this is going to set the mark->group and mark->inode fields, but will
      return -EEXIST because of the race with [b].
      								fsnotify_destroy_mark()
      								   ^--- since ->group != NULL we call back
      									into inotify_freeing_mark() which calls
      								inotify_remove_from_idr([a])
      
      since fsnotify_add_mark() failed we call:
      inotify_remove_from_idr([a])     <------WHOOPS it's not in the idr, this could
      					have been any entry added later!
      
      The fix is to make sure we don't set mark->group until we are sure the mark is
      on the inode and fsnotify_add_mark will return success.
      Signed-off-by: NEric Paris <eparis@redhat.com>
      9f0d793b
  15. 15 10月, 2009 2 次提交
  16. 14 10月, 2009 1 次提交
    • C
      Btrfs: always pin metadata in discard mode · 444528b3
      Chris Mason 提交于
      We have an optimization in btrfs to allow blocks to be
      immediately freed if they were allocated in this transaction and never
      written.  Otherwise they are pinned and freed when the transaction
      commits.
      
      This isn't optimal for discard mode because immediately freeing
      them means immediately discarding them.  It is better to give the
      block to the pinning code and letting the (slow) discard happen later.
      Signed-off-by: NChris Mason <chris.mason@oracle.com>
      444528b3