linux.kernel - 25 new messages in 12 topics - digest

linux.kernel
http://groups.google.com/group/linux.kernel?hl=en

linux.kernel@googlegroups.com

Today's topics:

* x86, ptrace: prepare regset get/set routines for user specified lengths - 3
messages, 2 authors
http://groups.google.com/group/linux.kernel/t/06e74467e61eef71?hl=en
* cris: use include/linux/pci-dma.h - 3 messages, 1 author
http://groups.google.com/group/linux.kernel/t/f6e9088abc30bc23?hl=en
* CRYPTO: Fix checkpatch errors & warnings in crc32.c - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/ec66ed13d52dd02b?hl=en
* CRYPTO: Fix checkpatch errors & warnings in aes_generic - 1 messages, 1
author
http://groups.google.com/group/linux.kernel/t/bc5431d0acefd319?hl=en
* adds include/linux/pci-dma.h - 8 messages, 1 author
http://groups.google.com/group/linux.kernel/t/fa2e329c49e4c232?hl=en
* usbnet: convert dev(dbg|err|warn|info) macros to usbnet_(dbg|err|warn|info) -
1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/7ae1dd4510edc70f?hl=en
* sysfs: differentiate between locking links and non-links - 3 messages, 2
authors
http://groups.google.com/group/linux.kernel/t/dc53e1c9066cca04?hl=en
* linux-next: manual merge of the sound tree with the i.MX tree - 1 messages,
1 author
http://groups.google.com/group/linux.kernel/t/fab2e768ba4b603e?hl=en
* x86, apic: Don't use logical-flat mode when CPU hotplug may exceed 8 CPUs -
1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/d53db1d17addede5?hl=en
* Failure to fallback to nfsd-v3 (?) - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/88441ff8fd85e18f?hl=en
* (none) - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/f500786faca6fb52?hl=en
* : cpuidle: Design documentation patch - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/32650ac38a3d07b9?hl=en

==============================================================================
TOPIC: x86, ptrace: prepare regset get/set routines for user specified lengths
http://groups.google.com/group/linux.kernel/t/06e74467e61eef71?hl=en
==============================================================================

== 1 of 3 ==
Date: Tues, Feb 9 2010 5:40 pm
From: Roland McGrath

This change is unnecessary and IMHO misguided. The arch user_regset.get
and user_regset.set functions are not required to worry about bogus
arguments. Their callers are required to pass values that don't violate
the .n, .size, and .align constraints in the user_regset. The right place
to enforce these constraints on parameters coming from userland is in the
arch-independent code that calls the arch user_regset functions.

Thanks,
Roland
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

== 2 of 3 ==
Date: Tues, Feb 9 2010 6:00 pm
From: Roland McGrath

> 'addr' parameter for the ptrace system call encode the REGSET type and
> the buffer length. 'data' parameter points to the user buffer.
>
> ptrace(PTRACE_GETREGSET/PTRACE_SETREGSET, pid,
> (NT_TYPE << 20) | buf_length, buf);

IMHO this bit swizzling is a non-starter. The NT_* codes can use a full 32
bits. NT_PRXFPREG uses 31 bits. The comments about ignoring the high bits
for this as a special case just seem insane to me. Pass a full 32 bit word
for NT_* and a full word for the buffer size. What's so terrible about
just having an obvious and comprehensible API?

IMHO if you insist on an insane bit swizzling approach, you should mix the
buffer size bits into the request code, leaving the "addr" argument free
for the unmolested NT_* code. There is just no earthly reason that we
should suddenly impose a new and arcane constraint on what NT_* values can
be, even if there is no particular reason for future values not to be small.

> +int generic_ptrace_regset(struct task_struct *child, long request, long addr,
> + long data);

There is no need for a global function for this. It should all be static
in kernel/ptrace.c, called only by ptrace_request()/compat_ptrace_request().

> +#ifdef PTRACE_EXPORT_REGSET
> + case PTRACE_GETREGSET:
> + case PTRACE_SETREGSET:
> + return generic_ptrace_regset(child, request, addr, data);
> +