1. 28 4月, 2008 3 次提交
  2. 19 4月, 2008 3 次提交
  3. 31 3月, 2008 1 次提交
  4. 19 3月, 2008 1 次提交
  5. 05 3月, 2008 1 次提交
  6. 15 2月, 2008 2 次提交
  7. 09 2月, 2008 2 次提交
  8. 08 2月, 2008 1 次提交
  9. 07 2月, 2008 2 次提交
  10. 06 2月, 2008 1 次提交
    • C
      Pagecache zeroing: zero_user_segment, zero_user_segments and zero_user · eebd2aa3
      Christoph Lameter 提交于
      Simplify page cache zeroing of segments of pages through 3 functions
      
      zero_user_segments(page, start1, end1, start2, end2)
      
              Zeros two segments of the page. It takes the position where to
              start and end the zeroing which avoids length calculations and
      	makes code clearer.
      
      zero_user_segment(page, start, end)
      
              Same for a single segment.
      
      zero_user(page, start, length)
      
              Length variant for the case where we know the length.
      
      We remove the zero_user_page macro. Issues:
      
      1. Its a macro. Inline functions are preferable.
      
      2. The KM_USER0 macro is only defined for HIGHMEM.
      
         Having to treat this special case everywhere makes the
         code needlessly complex. The parameter for zeroing is always
         KM_USER0 except in one single case that we open code.
      
      Avoiding KM_USER0 makes a lot of code not having to be dealing
      with the special casing for HIGHMEM anymore. Dealing with
      kmap is only necessary for HIGHMEM configurations. In those
      configurations we use KM_USER0 like we do for a series of other
      functions defined in highmem.h.
      
      Since KM_USER0 is depends on HIGHMEM the existing zero_user_page
      function could not be a macro. zero_user_* functions introduced
      here can be be inline because that constant is not used when these
      functions are called.
      
      Also extract the flushing of the caches to be outside of the kmap.
      
      [akpm@linux-foundation.org: fix nfs and ntfs build]
      [akpm@linux-foundation.org: fix ntfs build some more]
      Signed-off-by: NChristoph Lameter <clameter@sgi.com>
      Cc: Steven French <sfrench@us.ibm.com>
      Cc: Michael Halcrow <mhalcrow@us.ibm.com>
      Cc: <linux-ext4@vger.kernel.org>
      Cc: Steven Whitehouse <swhiteho@redhat.com>
      Cc: Trond Myklebust <trond.myklebust@fys.uio.no>
      Cc: "J. Bruce Fields" <bfields@fieldses.org>
      Cc: Anton Altaparmakov <aia21@cantab.net>
      Cc: Mark Fasheh <mark.fasheh@oracle.com>
      Cc: David Chinner <dgc@sgi.com>
      Cc: Michael Halcrow <mhalcrow@us.ibm.com>
      Cc: Steven French <sfrench@us.ibm.com>
      Cc: Steven Whitehouse <swhiteho@redhat.com>
      Cc: Trond Myklebust <trond.myklebust@fys.uio.no>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      eebd2aa3
  11. 03 2月, 2008 1 次提交
  12. 06 12月, 2007 1 次提交
    • A
      proc: fix proc_dir_entry refcounting · 5a622f2d
      Alexey Dobriyan 提交于
      Creating PDEs with refcount 0 and "deleted" flag has problems (see below).
      Switch to usual scheme:
      * PDE is created with refcount 1
      * every de_get does +1
      * every de_put() and remove_proc_entry() do -1
      * once refcount reaches 0, PDE is freed.
      
      This elegantly fixes at least two following races (both observed) without
      introducing new locks, without abusing old locks, without spreading
      lock_kernel():
      
      1) PDE leak
      
      remove_proc_entry			de_put
      -----------------			------
      			[refcnt = 1]
      if (atomic_read(&de->count) == 0)
      					if (atomic_dec_and_test(&de->count))
      						if (de->deleted)
      							/* also not taken! */
      							free_proc_entry(de);
      else
      	de->deleted = 1;
      		[refcount=0, deleted=1]
      
      2) use after free
      
      remove_proc_entry			de_put
      -----------------			------
      			[refcnt = 1]
      
      					if (atomic_dec_and_test(&de->count))
      if (atomic_read(&de->count) == 0)
      	free_proc_entry(de);
      						/* boom! */
      						if (de->deleted)
      							free_proc_entry(de);
      
      BUG: unable to handle kernel paging request at virtual address 6b6b6b6b
      printing eip: c10acdda *pdpt = 00000000338f8001 *pde = 0000000000000000
      Oops: 0000 [#1] PREEMPT SMP
      Modules linked in: af_packet ipv6 cpufreq_ondemand loop serio_raw psmouse k8temp hwmon sr_mod cdrom
      Pid: 23161, comm: cat Not tainted (2.6.24-rc2-8c086340 #4)
      EIP: 0060:[<c10acdda>] EFLAGS: 00210097 CPU: 1
      EIP is at strnlen+0x6/0x18
      EAX: 6b6b6b6b EBX: 6b6b6b6b ECX: 6b6b6b6b EDX: fffffffe
      ESI: c128fa3b EDI: f380bf34 EBP: ffffffff ESP: f380be44
       DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
      Process cat (pid: 23161, ti=f380b000 task=f38f2570 task.ti=f380b000)
      Stack: c10ac4f0 00000278 c12ce000 f43cd2a8 00000163 00000000 7da86067 00000400
             c128fa20 00896b18 f38325a8 c128fe20 ffffffff 00000000 c11f291e 00000400
             f75be300 c128fa20 f769c9a0 c10ac779 f380bf34 f7bfee70 c1018e6b f380bf34
      Call Trace:
       [<c10ac4f0>] vsnprintf+0x2ad/0x49b
       [<c10ac779>] vscnprintf+0x14/0x1f
       [<c1018e6b>] vprintk+0xc5/0x2f9
       [<c10379f1>] handle_fasteoi_irq+0x0/0xab
       [<c1004f44>] do_IRQ+0x9f/0xb7
       [<c117db3b>] preempt_schedule_irq+0x3f/0x5b
       [<c100264e>] need_resched+0x1f/0x21
       [<c10190ba>] printk+0x1b/0x1f
       [<c107c8ad>] de_put+0x3d/0x50
       [<c107c8f8>] proc_delete_inode+0x38/0x41
       [<c107c8c0>] proc_delete_inode+0x0/0x41
       [<c1066298>] generic_delete_inode+0x5e/0xc6
       [<c1065aa9>] iput+0x60/0x62
       [<c1063c8e>] d_kill+0x2d/0x46
       [<c1063fa9>] dput+0xdc/0xe4
       [<c10571a1>] __fput+0xb0/0xcd
       [<c1054e49>] filp_close+0x48/0x4f
       [<c1055ee9>] sys_close+0x67/0xa5
       [<c10026b6>] sysenter_past_esp+0x5f/0x85
      =======================
      Code: c9 74 0c f2 ae 74 05 bf 01 00 00 00 4f 89 fa 5f 89 d0 c3 85 c9 57 89 c7 89 d0 74 05 f2 ae 75 01 4f 89 f8 5f c3 89 c1 89 c8 eb 06 <80> 38 00 74 07 40 4a 83 fa ff 75 f4 29 c8 c3 90 90 90 57 83 c9
      EIP: [<c10acdda>] strnlen+0x6/0x18 SS:ESP 0068:f380be44
      
      Also, remove broken usage of ->deleted from reiserfs: if sget() succeeds,
      module is already pinned and remove_proc_entry() can't happen => nobody
      can mark PDE deleted.
      
      Dummy proc root in netns code is not marked with refcount 1. AFAICS, we
      never get it, it's just for proper /proc/net removal. I double checked
      CLONE_NETNS continues to work.
      
      Patch survives many hours of modprobe/rmmod/cat loops without new bugs
      which can be attributed to refcounting.
      Signed-off-by: NAlexey Dobriyan <adobriyan@sw.ru>
      Cc: "Eric W. Biederman" <ebiederm@xmission.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      5a622f2d
  13. 15 11月, 2007 2 次提交
    • F
      reiserfs: don't drop PG_dirty when releasing sub-page-sized dirty file · c06a018f
      Fengguang Wu 提交于
      This is not a new problem in 2.6.23-git17.  2.6.22/2.6.23 is buggy in the
      same way.
      
      Reiserfs could accumulate dirty sub-page-size files until umount time.
      They cannot be synced to disk by pdflush routines or explicit `sync'
      commands.  Only `umount' can do the trick.
      
      The direct cause is: the dirty page's PG_dirty is wrongly _cleared_.
      Call trace:
      	 [<ffffffff8027e920>] cancel_dirty_page+0xd0/0xf0
      	 [<ffffffff8816d470>] :reiserfs:reiserfs_cut_from_item+0x660/0x710
      	 [<ffffffff8816d791>] :reiserfs:reiserfs_do_truncate+0x271/0x530
      	 [<ffffffff8815872d>] :reiserfs:reiserfs_truncate_file+0xfd/0x3b0
      	 [<ffffffff8815d3d0>] :reiserfs:reiserfs_file_release+0x1e0/0x340
      	 [<ffffffff802a187c>] __fput+0xcc/0x1b0
      	 [<ffffffff802a1ba6>] fput+0x16/0x20
      	 [<ffffffff8029e676>] filp_close+0x56/0x90
      	 [<ffffffff8029fe0d>] sys_close+0xad/0x110
      	 [<ffffffff8020c41e>] system_call+0x7e/0x83
      
      Fix the bug by removing the cancel_dirty_page() call. Tests show that
      it causes no bad behaviors on various write sizes.
      
      === for the patient ===
      Here are more detailed demonstrations of the problem.
      
      1) the page has both PG_dirty(D)/PAGECACHE_TAG_DIRTY(d) after being written to;
         and then only PAGECACHE_TAG_DIRTY(d) remains after the file is closed.
      
      ------------------------------ screen 0 ------------------------------
      [T0] root /home/wfg# cat > /test/tiny
      [T1] hi
      [T2] root /home/wfg#
      
      ------------------------------ screen 1 ------------------------------
      [T1] root /home/wfg# echo /test/tiny > /proc/filecache
      [T1] root /home/wfg# cat /proc/filecache
           # file /test/tiny
           # flags R:referenced A:active M:mmap U:uptodate D:dirty W:writeback O:owner B:buffer d:dirty w:writeback
           # idx   len     state   refcnt
           0       1       ___UD__Bd_      2
      [T2] root /home/wfg# cat /proc/filecache
           # file /test/tiny
           # flags R:referenced A:active M:mmap U:uptodate D:dirty W:writeback O:owner B:buffer d:dirty w:writeback
           # idx   len     state   refcnt
           0       1       ___U___Bd_      2
      
      2) note the non-zero 'cancelled_write_bytes' after /tmp/hi is copied.
      
      ------------------------------ screen 0 ------------------------------
      [T0] root /home/wfg# echo hi > /tmp/hi
      [T1] root /home/wfg# cp /tmp/hi /dev/stdin /test
      [T2] hi
      [T3] root /home/wfg#
      
      ------------------------------ screen 1 ------------------------------
      [T1] root /proc/4397# cd /proc/`pidof cp`
      [T1] root /proc/4713# cat io
           rchar: 8396
           wchar: 3
           syscr: 20
           syscw: 1
           read_bytes: 0
           write_bytes: 20480
           cancelled_write_bytes: 4096
      [T2] root /proc/4713# cat io
           rchar: 8399
           wchar: 6
           syscr: 21
           syscw: 2
           read_bytes: 0
           write_bytes: 24576
           cancelled_write_bytes: 4096
      
      //Question: the 'write_bytes' is a bit more than expected ;-)
      Tested-by: NMaxim Levitsky <maximlevitsky@gmail.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Jeff Mahoney <jeffm@suse.com>
      Signed-off-by: NFengguang Wu <wfg@mail.ustc.edu.cn>
      Reviewed-by: NChris Mason <chris.mason@oracle.com>
      Cc: <stable@kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      c06a018f
    • J
      Forbid user to change file flags on quota files · e47776a0
      Jan Kara 提交于
      Forbid user from changing file flags on quota files.  User has no bussiness
      in playing with these flags when quota is on.  Furthermore there is a
      remote possibility of deadlock due to a lock inversion between quota file's
      i_mutex and transaction's start (i_mutex for quota file is locked only when
      trasaction is started in quota operations) in ext3 and ext4.
      Signed-off-by: NJan Kara <jack@suse.cz>
      Cc: LIOU Payphone <lioupayphone@gmail.com>
      Cc: <linux-ext4@vger.kernel.org>
      Acked-by: NDave Kleikamp <shaggy@austin.ibm.com>
      Cc: <reiserfs-dev@namesys.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      e47776a0
  14. 22 10月, 2007 2 次提交
  15. 20 10月, 2007 8 次提交
  16. 19 10月, 2007 1 次提交
  17. 17 10月, 2007 8 次提交
新手
引导
客服 返回
顶部