1. 29 5月, 2011 1 次提交
    • E
      ns: Wire up the setns system call · 7b21fddd
      Eric W. Biederman 提交于
      32bit and 64bit on x86 are tested and working.  The rest I have looked
      at closely and I can't find any problems.
      
      setns is an easy system call to wire up.  It just takes two ints so I
      don't expect any weird architecture porting problems.
      
      While doing this I have noticed that we have some architectures that are
      very slow to get new system calls.  cris seems to be the slowest where
      the last system calls wired up were preadv and pwritev.  avr32 is weird
      in that recvmmsg was wired up but never declared in unistd.h.  frv is
      behind with perf_event_open being the last syscall wired up.  On h8300
      the last system call wired up was epoll_wait.  On m32r the last system
      call wired up was fallocate.  mn10300 has recvmmsg as the last system
      call wired up.  The rest seem to at least have syncfs wired up which was
      new in the 2.6.39.
      
      v2: Most of the architecture support added by Daniel Lezcano <dlezcano@fr.ibm.com>
      v3: ported to v2.6.36-rc4 by: Eric W. Biederman <ebiederm@xmission.com>
      v4: Moved wiring up of the system call to another patch
      v5: ported to v2.6.39-rc6
      v6: rebased onto parisc-next and net-next to avoid syscall  conflicts.
      v7: ported to Linus's latest post 2.6.39 tree.
      
      >  arch/blackfin/include/asm/unistd.h     |    3 ++-
      >  arch/blackfin/mach-common/entry.S      |    1 +
      Acked-by: NMike Frysinger <vapier@gentoo.org>
      
      Oh - ia64 wiring looks good.
      Acked-by: NTony Luck <tony.luck@intel.com>
      Signed-off-by: NEric W. Biederman <ebiederm@xmission.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      7b21fddd
  2. 27 5月, 2011 1 次提交
  3. 26 5月, 2011 3 次提交
    • M
      x86, efi: Retain boot service code until after switching to virtual mode · 916f676f
      Matthew Garrett 提交于
      UEFI stands for "Unified Extensible Firmware Interface", where "Firmware"
      is an ancient African word meaning "Why do something right when you can
      do it so wrong that children will weep and brave adults will cower before
      you", and "UEI" is Celtic for "We missed DOS so we burned it into your
      ROMs". The UEFI specification provides for runtime services (ie, another
      way for the operating system to be forced to depend on the firmware) and
      we rely on these for certain trivial tasks such as setting up the
      bootloader. But some hardware fails to work if we attempt to use these
      runtime services from physical mode, and so we have to switch into virtual
      mode. So far so dreadful.
      
      The specification makes it clear that the operating system is free to do
      whatever it wants with boot services code after ExitBootServices() has been
      called. SetVirtualAddressMap() can't be called until ExitBootServices() has
      been. So, obviously, a whole bunch of EFI implementations call into boot
      services code when we do that. Since we've been charmingly naive and
      trusted that the specification may be somehow relevant to the real world,
      we've already stuffed a picture of a penguin or something in that address
      space. And just to make things more entertaining, we've also marked it
      non-executable.
      
      This patch allocates the boot services regions during EFI init and makes
      sure that they're executable. Then, after SetVirtualAddressMap(), it
      discards them and everyone lives happily ever after. Except for the ones
      who have to work on EFI, who live sad lives haunted by the knowledge that
      someone's eventually going to write yet another firmware specification.
      
      [ hpa: adding this to urgent with a stable tag since it fixes currently-broken
        hardware.  However, I do not know what the dependencies are and so I do
        not know which -stable versions this may be a candidate for. ]
      Signed-off-by: NMatthew Garrett <mjg@redhat.com>
      Link: http://lkml.kernel.org/r/1306331593-28715-1-git-send-email-mjg@redhat.comSigned-off-by: NH. Peter Anvin <hpa@linux.intel.com>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: <stable@kernel.org>
      916f676f
    • R
      x86/ftrace: Fix compiler warning in ftrace.c · 0d098a7d
      Rakib Mullick 提交于
       Due to commit dc326fca (x86, cpu: Clean up and unify the NOP selection infrastructure), we get the following warning:
      
      arch/x86/kernel/ftrace.c: In function ‘ftrace_make_nop’:
      arch/x86/kernel/ftrace.c:308:6: warning: assignment discards qualifiers from pointer target type
      arch/x86/kernel/ftrace.c: In function ‘ftrace_make_call’:
      arch/x86/kernel/ftrace.c:318:6: warning: assignment discards qualifiers from pointer target type
      
      ftrace_nop_replace() now returns const unsigned char *, so change its associated function/variable to its compatible type to keep compiler clam.
      Signed-off-by: NRakib Mullick <rakib.mullick@gmail.com>
      Link: http://lkml.kernel.org/r/1305221620.7986.4.camel@localhost.localdomain
      
      [ updated for change of const void *src in probe_kernel_write() ]
      Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>
      0d098a7d
    • N
      x86: Remove unnecessary check in detect_ht() · 8b27f2ff
      Nikhil P Rao 提交于
      This patch removes a check that causes incorrect scheduler
      domain setup (SMP instead of SMT) and bootlog warning messages
      when cpuid extensions for topology enumeration are not supported
      and the number of processors reported to the OS is smaller than
      smp_num_siblings.
      Acked-by: NSuresh Siddha <suresh.b.siddha@intel.com>
      Signed-off-by: NNikhil P Rao <nikhil.rao@intel.com>
      Link: http://lkml.kernel.org/r/1306343921.19325.1.camel@fedora13Signed-off-by: NIngo Molnar <mingo@elte.hu>
      8b27f2ff
  4. 25 5月, 2011 4 次提交
  5. 24 5月, 2011 7 次提交
  6. 23 5月, 2011 2 次提交
  7. 22 5月, 2011 5 次提交
  8. 21 5月, 2011 1 次提交
  9. 20 5月, 2011 16 次提交