1. 18 Aug, 2010 12 commits
  2. 17 Aug, 2010 3 commits
  3. 16 Aug, 2010 21 commits
  4. 15 Aug, 2010 4 commits
    • Russell King's avatar
    • Mikael Pettersson's avatar
      ARM: 6329/1: wire up sys_accept4() on ARM · 21d93e2e
      Mikael Pettersson authored
      sys_accept4() was added in kernel 2.6.28, but ARM was not updated
      to include it.  The number and types of parameters is such that
      no ARM-specific processing is needed, so wiring up sys_accept4()
      just requires defining __NR_accept4 and adding a direct call in
      the syscall entry table.
      
      Tested with an EABI 2.6.35 kernel and Ulrich Drepper's original
      accept4() test program, modified to define __NR_accept4 for ARM.
      
      Using the updated unistd.h also eliminates a warning then building
      glibc (2.10.2 and newer) about accept4() being unimplemented.
      Signed-off-by: default avatarMikael Pettersson <mikpe@it.uu.se>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      21d93e2e
    • Chris Metcalf's avatar
      arch/tile: don't validate CROSS_COMPILE needlessly · a5854dd7
      Chris Metcalf authored
      With this change, the arch/tile Makefile will only check for a valid
      combination of CROSS_COMPILE vs "uname -m" for a few common targets
      that are typically the ones we get wrong (vmlinux, all, and modules).
      The change handles the case of an empty "make" goal like "make all".
      Signed-off-by: default avatarChris Metcalf <cmetcalf@tilera.com>
      Reviewed-by: default avatarSam Ravnborg <sam@ravnborg.org>
      a5854dd7
    • Linus Torvalds's avatar
      mm: fix up some user-visible effects of the stack guard page · d7824370
      Linus Torvalds authored
      This commit makes the stack guard page somewhat less visible to user
      space. It does this by:
      
       - not showing the guard page in /proc/<pid>/maps
      
         It looks like lvm-tools will actually read /proc/self/maps to figure
         out where all its mappings are, and effectively do a specialized
         "mlockall()" in user space.  By not showing the guard page as part of
         the mapping (by just adding PAGE_SIZE to the start for grows-up
         pages), lvm-tools ends up not being aware of it.
      
       - by also teaching the _real_ mlock() functionality not to try to lock
         the guard page.
      
         That would just expand the mapping down to create a new guard page,
         so there really is no point in trying to lock it in place.
      
      It would perhaps be nice to show the guard page specially in
      /proc/<pid>/maps (or at least mark grow-down segments some way), but
      let's not open ourselves up to more breakage by user space from programs
      that depends on the exact deails of the 'maps' file.
      
      Special thanks to Henrique de Moraes Holschuh for diving into lvm-tools
      source code to see what was going on with the whole new warning.
      
      Reported-and-tested-by: François Valenduc <francois.valenduc@tvcablenet.be
      Reported-by: default avatarHenrique de Moraes Holschuh <hmh@hmh.eng.br>
      Cc: stable@kernel.org
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      d7824370