1. 06 10月, 2009 1 次提交
  2. 16 9月, 2009 1 次提交
  3. 12 9月, 2009 3 次提交
  4. 11 9月, 2009 1 次提交
  5. 09 9月, 2009 2 次提交
  6. 07 9月, 2009 5 次提交
  7. 05 9月, 2009 1 次提交
    • N
      ARM: 5691/1: fix cache aliasing issues between kmap() and kmap_atomic() with highmem · 7929eb9c
      Nicolas Pitre 提交于
      Let's suppose a highmem page is kmap'd with kmap().  A pkmap entry is
      used, the page mapped to it, and the virtual cache is dirtied.  Then
      kunmap() is used which does virtually nothing except for decrementing a
      usage count.
      
      Then, let's suppose the _same_ page gets mapped using kmap_atomic().
      It is therefore mapped onto a fixmap entry instead, which has a
      different virtual address unaware of the dirty cache data for that page
      sitting in the pkmap mapping.
      
      Fortunately it is easy to know if a pkmap mapping still exists for that
      page and use it directly with kmap_atomic(), thanks to kmap_high_get().
      
      And actual testing with a printk in the added code path shows that this
      condition is actually met *extremely* frequently.  Seems that we've been
      quite lucky that things have worked so well with highmem so far.
      
      Cc: stable@kernel.org
      Signed-off-by: NNicolas Pitre <nico@marvell.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      7929eb9c
  8. 02 9月, 2009 7 次提交
    • D
      KEYS: Add a keyctl to install a process's session keyring on its parent [try #6] · ee18d64c
      David Howells 提交于
      Add a keyctl to install a process's session keyring onto its parent.  This
      replaces the parent's session keyring.  Because the COW credential code does
      not permit one process to change another process's credentials directly, the
      change is deferred until userspace next starts executing again.  Normally this
      will be after a wait*() syscall.
      
      To support this, three new security hooks have been provided:
      cred_alloc_blank() to allocate unset security creds, cred_transfer() to fill in
      the blank security creds and key_session_to_parent() - which asks the LSM if
      the process may replace its parent's session keyring.
      
      The replacement may only happen if the process has the same ownership details
      as its parent, and the process has LINK permission on the session keyring, and
      the session keyring is owned by the process, and the LSM permits it.
      
      Note that this requires alteration to each architecture's notify_resume path.
      This has been done for all arches barring blackfin, m68k* and xtensa, all of
      which need assembly alteration to support TIF_NOTIFY_RESUME.  This allows the
      replacement to be performed at the point the parent process resumes userspace
      execution.
      
      This allows the userspace AFS pioctl emulation to fully emulate newpag() and
      the VIOCSETTOK and VIOCSETTOK2 pioctls, all of which require the ability to
      alter the parent process's PAG membership.  However, since kAFS doesn't use
      PAGs per se, but rather dumps the keys into the session keyring, the session
      keyring of the parent must be replaced if, for example, VIOCSETTOK is passed
      the newpag flag.
      
      This can be tested with the following program:
      
      	#include <stdio.h>
      	#include <stdlib.h>
      	#include <keyutils.h>
      
      	#define KEYCTL_SESSION_TO_PARENT	18
      
      	#define OSERROR(X, S) do { if ((long)(X) == -1) { perror(S); exit(1); } } while(0)
      
      	int main(int argc, char **argv)
      	{
      		key_serial_t keyring, key;
      		long ret;
      
      		keyring = keyctl_join_session_keyring(argv[1]);
      		OSERROR(keyring, "keyctl_join_session_keyring");
      
      		key = add_key("user", "a", "b", 1, keyring);
      		OSERROR(key, "add_key");
      
      		ret = keyctl(KEYCTL_SESSION_TO_PARENT);
      		OSERROR(ret, "KEYCTL_SESSION_TO_PARENT");
      
      		return 0;
      	}
      
      Compiled and linked with -lkeyutils, you should see something like:
      
      	[dhowells@andromeda ~]$ keyctl show
      	Session Keyring
      	       -3 --alswrv   4043  4043  keyring: _ses
      	355907932 --alswrv   4043    -1   \_ keyring: _uid.4043
      	[dhowells@andromeda ~]$ /tmp/newpag
      	[dhowells@andromeda ~]$ keyctl show
      	Session Keyring
      	       -3 --alswrv   4043  4043  keyring: _ses
      	1055658746 --alswrv   4043  4043   \_ user: a
      	[dhowells@andromeda ~]$ /tmp/newpag hello
      	[dhowells@andromeda ~]$ keyctl show
      	Session Keyring
      	       -3 --alswrv   4043  4043  keyring: hello
      	340417692 --alswrv   4043  4043   \_ user: a
      
      Where the test program creates a new session keyring, sticks a user key named
      'a' into it and then installs it on its parent.
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      Signed-off-by: NJames Morris <jmorris@namei.org>
      ee18d64c
    • D
      KEYS: Extend TIF_NOTIFY_RESUME to (almost) all architectures [try #6] · d0420c83
      David Howells 提交于
      Implement TIF_NOTIFY_RESUME for most of those architectures in which isn't yet
      available, and, whilst we're at it, have it call the appropriate tracehook.
      
      After this patch, blackfin, m68k* and xtensa still lack support and need
      alteration of assembly code to make it work.
      
      Resume notification can then be used (by a later patch) to install a new
      session keyring on the parent of a process.
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      Acked-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      
      cc: linux-arch@vger.kernel.org
      Signed-off-by: NJames Morris <jmorris@namei.org>
      d0420c83
    • N
      ARM: 5687/1: fix an oops with highmem · 13f96d8f
      Nicolas Pitre 提交于
      In xdr_partial_copy_from_skb() there is that sequence:
      
      		kaddr = kmap_atomic(*ppage, KM_SKB_SUNRPC_DATA);
      		[...]
      		flush_dcache_page(*ppage);
      		kunmap_atomic(kaddr, KM_SKB_SUNRPC_DATA);
      
      Mixing flush_dcache_page() and kmap_atomic() is a bit odd,
      especially since kunmap_atomic() must deal with cache issues
      already.  OTOH the non-highmem case must use flush_dcache_page()
      as kunmap_atomic() becomes a no op with no cache maintenance.
      
      Problem is that with highmem the implementation of kmap_atomic()
      doesn't set page->virtual, and page_address(page) returns 0 in
      that case. Here flush_dcache_page() calls __flush_dcache_page()
      which calls __cpuc_flush_dcache_page(page_address(page)) resulting
      in a kernel oops.
      
      None of the kmap_atomic() implementations uses set_page_address().
      Hence we can assume page_address() is always expected to return 0 in
      that case. Let's conditionally call __cpuc_flush_dcache_page() only
      when the page address is non zero, and perform that test only when
      highmem is configured.
      Signed-off-by: NNicolas Pitre <nico@marvell.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      13f96d8f
    • W
      ARM: 5684/1: Add nuc960 platform to w90x900 · 8e22676e
      wanzongshun 提交于
      Add nuc960 platform to w90x900.
      Signed-off-by: NWan ZongShun <mcuos.com@gmail.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      8e22676e
    • W
      ARM: 5683/1: Add nuc950 platform to w90x900 · 936fbe9e
      wanzongshun 提交于
      Add nuc950 platform to w90x900.
      Signed-off-by: NWan ZongShun <mcuos.com@gmail.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      936fbe9e
    • W
      ARM: 5682/1: Add cpu.c and dev.c and modify some files of w90p910 platform · 35c9221a
      wanzongshun 提交于
      Add the cpu.c and dev.c and modify w90p910 platform
      to apply to use the common API(provided by cpu.c and dev.c)
      at the same time, I renamed all w90x900 to nuc900 in every
      c file of w90x900 platform and touchscreen's driver name.
      Signed-off-by: NWan ZongShun <mcuos.com@gmail.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      35c9221a
    • R
      98b0979f
  9. 25 8月, 2009 3 次提交
  10. 24 8月, 2009 2 次提交
  11. 21 8月, 2009 14 次提交