1. 02 May, 2009 2 commits
  2. 26 Apr, 2009 1 commit
  3. 21 Apr, 2009 1 commit
    • David Howells's avatar
      FRV: Fix the section attribute on UP DECLARE_PER_CPU() · 9b8de747
      David Howells authored
      In non-SMP mode, the variable section attribute specified by DECLARE_PER_CPU()
      does not agree with that specified by DEFINE_PER_CPU().  This means that
      architectures that have a small data section references relative to a base
      register may throw up linkage errors due to too great a displacement between
      where the base register points and the per-CPU variable.
      On FRV, the .h declaration says that the variable is in the .sdata section, but
      the .c definition says it's actually in the .data section.  The linker throws
      up the following errors:
      kernel/built-in.o: In function `release_task':
      kernel/exit.c:78: relocation truncated to fit: R_FRV_GPREL12 against symbol `per_cpu__process_counts' defined in .data section in kernel/built-in.o
      kernel/exit.c:78: relocation truncated to fit: R_FRV_GPREL12 against symbol `per_cpu__process_counts' defined in .data section in kernel/built-in.o
      To fix this, DECLARE_PER_CPU() should simply apply the same section attribute
      as does DEFINE_PER_CPU().  However, this is made slightly more complex by
      virtue of the fact that there are several variants on DEFINE, so these need to
      be matched by variants on DECLARE.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
  4. 02 Apr, 2009 2 commits
  5. 01 Apr, 2009 3 commits
  6. 30 Mar, 2009 1 commit
    • Alexey Dobriyan's avatar
      proc 2/2: remove struct proc_dir_entry::owner · 99b76233
      Alexey Dobriyan authored
      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
      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.
      Signed-off-by: default avatarAlexey Dobriyan <adobriyan@gmail.com>
  7. 27 Mar, 2009 1 commit
  8. 19 Mar, 2009 1 commit
    • Ivan Kokshaysky's avatar
      PCI/alpha: pci sysfs resources · 10a0ef39
      Ivan Kokshaysky authored
      This closes http://bugzilla.kernel.org/show_bug.cgi?id=10893
      which is a showstopper for X development on alpha.
      The generic HAVE_PCI_MMAP code (drivers/pci-sysfs.c) is not
      very useful since we have to deal with three different types
      of MMIO address spaces: sparse and dense mappings for old
      ev4/ev5 machines and "normal" 1:1 MMIO space (bwx) for ev56 and
      Also "write combine" mappings are meaningless on alpha - roughly
      speaking, alpha does write combining, IO reordering and other
      optimizations by default, unless user splits IO accesses
      with memory barriers.
      I think the cleanest way to deal with resource files on alpha
      is to convert the default no-op pci_create_resource_files() and
      pci_remove_resource_files() for !HAVE_PCI_MMAP case into __weak
      functions and override them with alpha specific ones.
      Another alpha hook is needed for "legacy_" resource files
      to handle sparse addressing (pci_adjust_legacy_attr).
      With the "standard" resourceN files on ev56/ev6 libpciaccess
      works "out of the box". Handling of resourceN_sparse/resourceN_dense
      files on older machines obviously requires some userland work.
      Sparse/dense stuff has been tested on sx164 (pca56/pyxis, normally
      uses bwx IO) with the kernel hacked into "cia compatible" mode.
      Signed-off-by: default avatarIvan Kokshaysky <ink@jurassic.park.msu.ru>
      Signed-off-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
  9. 02 Mar, 2009 1 commit
  10. 01 Mar, 2009 1 commit
  11. 23 Feb, 2009 1 commit
    • Tejun Heo's avatar
      vmalloc: add @align to vm_area_register_early() · c0c0a293
      Tejun Heo authored
      Impact: allow larger alignment for early vmalloc area allocation
      Some early vmalloc users might want larger alignment, for example, for
      custom large page mapping.  Add @align to vm_area_register_early().
      While at it, drop docbook comment on non-existent @size.
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Cc: Nick Piggin <nickpiggin@yahoo.com.au>
      Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
  12. 20 Feb, 2009 1 commit
    • Tejun Heo's avatar
      vmalloc: implement vm_area_register_early() · f0aa6617
      Tejun Heo authored
      Impact: allow multiple early vm areas
      There are places where kernel VM area needs to be allocated before
      vmalloc is initialized.  This is done by allocating static vm_struct,
      initializing several fields and linking it to vmlist and later vmalloc
      initialization picking up these from vmlist.  This is currently done
      manually and if there's more than one such areas, there's no defined
      way to arbitrate who gets which address.
      This patch implements vm_area_register_early(), which takes vm_area
      struct with flags and size initialized, assigns address to it and puts
      it on the vmlist.  This way, multiple early vm areas can determine
      which addresses they should use.  The only current user - alpha mm
      init - is converted to use it.
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
  13. 16 Feb, 2009 1 commit
  14. 15 Feb, 2009 1 commit
    • Patrick Ohly's avatar
      net: new user space API for time stamping of incoming and outgoing packets · cb9eff09
      Patrick Ohly authored
      User space can request hardware and/or software time stamping.
      Reporting of the result(s) via a new control message is enabled
      separately for each field in the message because some of the
      fields may require additional computation and thus cause overhead.
      User space can tell the different kinds of time stamps apart
      and choose what suits its needs.
      When a TX timestamp operation is requested, the TX skb will be cloned
      and the clone will be time stamped (in hardware or software) and added
      to the socket error queue of the skb, if the skb has a socket
      associated with it.
      The actual TX timestamp will reach userspace as a RX timestamp on the
      cloned packet. If timestamping is requested and no timestamping is
      done in the device driver (potentially this may use hardware
      timestamping), it will be done in software after the device's
      start_hard_xmit routine.
      Signed-off-by: default avatarPatrick Ohly <patrick.ohly@intel.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
  15. 12 Feb, 2009 1 commit
    • Steven Rostedt's avatar
      preempt-count: force hardirq-count to max of 10 · 5a5fb7db
      Steven Rostedt authored
      To add a bit in the preempt_count to be set when in NMI context, we
      found that some archs did not have enough bits to spare. This is
      due to the hardirq_count being a mask that can hold NR_IRQS.
      Some archs allow for over 16000 IRQs, and that would require a mask
      of 14 bits. The sofitrq mask is 8 bits and the preempt disable mask
      is also 8 bits.  The PREEMP_ACTIVE bit is bit 30, and bit 31 would
      make the preempt_count (which is type int) a negative number.
      A negative preempt_count is a sign of failure.
      Add them up 14+8+8+1+1 you get 32 bits. No room for the NMI bit.
      But the hardirq_count is to track the number of nested IRQs, not
      the number of total IRQs.  This originally took the paranoid approach
      of setting the max nesting to NR_IRQS. But when we have archs with
      over 1000 IRQs, it is not practical to think they will ever all
      nest on a single CPU. Not to mention that this would most definitely
      cause a stack overflow.
      This patch sets a max of 10 bits to be used for IRQ nesting.
      I did a 'git grep HARDIRQ' to examine all users of HARDIRQ_BITS and
      HARDIRQ_MASK, and found that making it a max of 10 would not hurt
      anyone. I did find that the m68k expected it to be 8 bits, so
      I allow for the archs to set the number to be less than 10.
      I removed the setting of HARDIRQ_BITS from the archs that set it
      to more than 10. This includes ALPHA, ia64 and avr32.
      This will always allow room for the NMI bit, and if we need to allow
      for NMI nesting, we have 4 bits to play with.
      Signed-off-by: default avatarSteven Rostedt <srostedt@redhat.com>
  16. 05 Feb, 2009 1 commit
  17. 31 Jan, 2009 2 commits
  18. 30 Jan, 2009 1 commit
  19. 29 Jan, 2009 3 commits
  20. 15 Jan, 2009 5 commits
  21. 14 Jan, 2009 2 commits
  22. 12 Jan, 2009 2 commits
  23. 07 Jan, 2009 2 commits
  24. 06 Jan, 2009 2 commits
  25. 03 Jan, 2009 1 commit