1. 08 4月, 2009 3 次提交
  2. 03 4月, 2009 1 次提交
  3. 31 3月, 2009 1 次提交
    • A
      proc 2/2: remove struct proc_dir_entry::owner · 99b76233
      Alexey Dobriyan 提交于
      Setting ->owner as done currently (pde->owner = THIS_MODULE) is racy
      as correctly noted at bug #12454. Someone can lookup entry with NULL
      ->owner, thus not pinning enything, and release it later resulting
      in module refcount underflow.
      
      We can keep ->owner and supply it at registration time like ->proc_fops
      and ->data.
      
      But this leaves ->owner as easy-manipulative field (just one C assignment)
      and somebody will forget to unpin previous/pin current module when
      switching ->owner. ->proc_fops is declared as "const" which should give
      some thoughts.
      
      ->read_proc/->write_proc were just fixed to not require ->owner for
      protection.
      
      rmmod'ed directories will be empty and return "." and ".." -- no harm.
      And directories with tricky enough readdir and lookup shouldn't be modular.
      We definitely don't want such modular code.
      
      Removing ->owner will also make PDE smaller.
      
      So, let's nuke it.
      
      Kudos to Jeff Layton for reminding about this, let's say, oversight.
      
      http://bugzilla.kernel.org/show_bug.cgi?id=12454Signed-off-by: NAlexey Dobriyan <adobriyan@gmail.com>
      99b76233
  4. 30 3月, 2009 3 次提交
  5. 28 3月, 2009 1 次提交
  6. 27 3月, 2009 2 次提交
    • D
      sparc64: Fix MM refcount check in smp_flush_tlb_pending(). · f9384d41
      David S. Miller 提交于
      As explained by Benjamin Herrenschmidt:
      
      > CPU 0 is running the context, task->mm == task->active_mm == your
      > context. The CPU is in userspace happily churning things.
      >
      > CPU 1 used to run it, not anymore, it's now running fancyfsd which
      > is a kernel thread, but current->active_mm still points to that
      > same context.
      >
      > Because there's only one "real" user, mm_users is 1 (but mm_count is
      > elevated, it's just that the presence on CPU 1 as active_mm has no
      > effect on mm_count().
      >
      > At this point, fancyfsd decides to invalidate a mapping currently mapped
      > by that context, for example because a networked file has changed
      > remotely or something like that, using unmap_mapping_ranges().
      >
      > So CPU 1 goes into the zapping code, which eventually ends up calling
      > flush_tlb_pending(). Your test will succeed, as current->active_mm is
      > indeed the target mm for the flush, and mm_users is indeed 1. So you
      > will -not- send an IPI to the other CPU, and CPU 0 will continue happily
      > accessing the pages that should have been unmapped.
      
      To fix this problem, check ->mm instead of ->active_mm, and this
      means:
      
      > So if you test current->mm, you effectively account for mm_users == 1,
      > so the only way the mm can be active on another processor is as a lazy
      > mm for a kernel thread. So your test should work properly as long
      > as you don't have a HW that will do speculative TLB reloads into the
      > TLB on that other CPU (and even if you do, you flush-on-switch-in should
      > get rid of any crap here).
      
      And therefore we should be OK.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f9384d41
    • D
      sparc64: Fix build of timer_interrupt(). · e2ab3dff
      David Miller 提交于
      arch/sparc/kernel/time_64.c: In function ‘timer_interrupt’:
        arch/sparc/kernel/time_64.c:732: error: ‘struct kernel_stat’ has no member named ‘irqs’
        make[1]: *** [arch/sparc/kernel/time_64.o] Error 1
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      e2ab3dff
  7. 19 3月, 2009 2 次提交
  8. 16 3月, 2009 7 次提交
  9. 05 3月, 2009 1 次提交
    • D
      sparc64: Fix lost interrupts on sun4u. · d0cac39e
      David S. Miller 提交于
      Based upon a report by Meelis Roos.
      
      Sparc64 SBUS and PCI controllers use a combination of IMAP and ICLR
      registers to manage device interrupts.
      
      The IMAP register contains the "valid" enable bit as well as CPU
      targetting information.  Whereas the ICLR register is written with
      zero at the end of handling an interrupt to reset the state machine
      for that interrupt to IDLE so it can be sent again.
      
      For PCI slot and SBUS slot devices we can have multiple interrupts
      sharing the same IMAP register.  There are individual ICLR registers
      but only one IMAP register for managing those.
      
      We represent each shared case with individual virtual IRQs so the
      generic IRQ layer thinks there is only one user of the IRQ instance.
      
      In such shared IMAP cases this is wrong, so if there are multiple
      active users then a free_irq() call will prematurely turn off the
      interrupt by clearing the Valid bit in the IMAP register even though
      there are other active users.
      
      Fix this by simply doing nothing in sun4u_disable_irq() and checking
      IRQF_DISABLED during IRQ dispatch.
      
      This situation doesn't exist in the hypervisor sun4v cases, so I left
      those alone.
      Tested-by: NMeelis Roos <mroos@linux.ee>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d0cac39e
  10. 11 2月, 2009 1 次提交
  11. 09 2月, 2009 1 次提交
    • D
      sparc64: Kill .fixup section bloat. · 40bdac7d
      David S. Miller 提交于
      This is an implementation of a suggestion made by Chris Torek:
      --------------------
      Something else I noticed in passing: the EX and EX_LD/EX_ST macros
      scattered throughout the various .S files make a fair bit of .fixup
      code, all of which does the same thing.  At the cost of one symbol
      in copy_in_user.S, you could just have one common two-instruction
      retl-and-mov-1 fixup that they all share.
      --------------------
      
      The following is with a defconfig build:
      
         text	   data	    bss	    dec	    hex	filename
      3972767	 344024	 584449	4901240	 4ac978	vmlinux.orig
      39688877	 344024	 584449	4897360	 4aba50	vmlinux
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      40bdac7d
  12. 06 2月, 2009 1 次提交
  13. 05 2月, 2009 1 次提交
  14. 03 2月, 2009 2 次提交
  15. 30 1月, 2009 1 次提交
  16. 29 1月, 2009 2 次提交
  17. 22 1月, 2009 2 次提交
  18. 20 1月, 2009 3 次提交
  19. 18 1月, 2009 1 次提交
  20. 15 1月, 2009 1 次提交
    • M
      irq: update all arches for new irq_desc, fix · d2287f5e
      Mike Travis 提交于
      Impact: fix build errors
      
      Since the SPARSE IRQS changes redefined how the kstat irqs are
      organized, arch's must use the new accessor function:
      
      	kstat_incr_irqs_this_cpu(irq, DESC);
      
      If CONFIG_SPARSE_IRQS is set, then DESC is a pointer to the
      irq_desc which has a pointer to the kstat_irqs.  If not, then
      the .irqs field of struct kernel_stat is used instead.
      Signed-off-by: NMike Travis <travis@sgi.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      d2287f5e
  21. 14 1月, 2009 3 次提交