headers
Ossama Othman | 1 Aug 2009 01:20
Picon
Favicon

[PATCH] Moorestown RAR Handler driver, MRST 2.6.31-rc3

This driver implements an allocator interface for Moorestown
restricted access regions (RAR), which are regions of RAM that are
inaccessible by the CPU when locked down.  It is implemented in the
kernel space since both user space applications and kernel drivers
will be allocating buffers in Moorestown RARs.

The canonical kernel allocators (slab, etc) are not used since they
are too tightly coupled with paging.  The CPU will not be accessing
the memory, meaning an allocation mechanism that does not place
metadata in the RAR memory area in question was needed.  The simple
allocator included in this patch satisfies my needs.  However, I was
recently made aware of the existence of the lib/genalloc.c allocator.
It appears promising in terms of the RAR handler driver needs, so I
may use it instead.

Work is still ongoing with this driver so I appreciate any
constructive feedback regarding the implementation, particularly with
respect to the allocator (or alternatives) since it is a critical part
of the functionality.  Thanks!!

Note this driver depends on the (previously submitted) Moorestown
rar_register driver (RAR_REGISTER).

Signed-off-by: Ossama Othman <ossama.othman <at> intel.com>
---
 drivers/misc/Kconfig            |   12 +
 drivers/misc/Makefile           |    2 +
 drivers/misc/memrar_allocator.c |  337 ++++++++++++++++++++
 drivers/misc/memrar_allocator.h |  162 ++++++++++
 drivers/misc/memrar_handler.c   |  669 +++++++++++++++++++++++++++++++++++++++
(Continue reading)

Permalink | Reply | 8 comments |
headers
Darren Hart | 1 Aug 2009 01:18
Picon
Favicon

Re: [PATCH] futex: futex_wait_requeue_pi commentary corrections

Darren Hart wrote:
> futex: futex_wait_requeue_pi commentary corrections
> 
> From: Darren Hart <dvhltc <at> us.ibm.com>
> 
> The state machine described in the comments wasn't updated with a follow-on
> fix.  Address that and cleanup the corresponding commentary in the 
> function.
> 
> Signed-off-by: Darren Hart <dvhltc <at> us.ibm.com>
> Cc: Thomas Gleixner <tglx <at> linutronix.de>
> Cc: Peter Zijlstra <peterz <at> infradead.org>
> Cc: Steven Rostedt <rostedt <at> goodmis.org>
> Cc: Ingo Molnar <mingo <at> elte.hu>
> ---
> 
> kernel/futex.c |   23 ++++++++++-------------
> 1 files changed, 10 insertions(+), 13 deletions(-)
> 
> 
> diff --git a/kernel/futex.c b/kernel/futex.c
> index 0672ff8..18752ae 100644
> --- a/kernel/futex.c
> +++ b/kernel/futex.c
>  <at>  <at>  -2102,11 +2102,11  <at>  <at>  int handle_early_requeue_pi_wakeup(struct 
> futex_hash_bucket *hb,
>  * We call schedule in futex_wait_queue_me() when we enqueue and return 
> there
>  * via the following:
>  * 1) wakeup on uaddr2 after an atomic lock acquisition by futex_requeue()
(Continue reading)

Permalink | Reply | 0 comments |
headers
Darren Hart | 1 Aug 2009 01:20
Picon
Favicon

[PATCH V2] futex: futex_wait_requeue_pi commentary corrections

futex: futex_wait_requeue_pi commentary corrections

From: Darren Hart <dvhltc <at> us.ibm.com>

The state machine described in the comments wasn't updated with a follow-on
fix.  Address that and cleanup the corresponding commentary in the function.

Signed-off-by: Darren Hart <dvhltc <at> us.ibm.com>
Cc: Thomas Gleixner <tglx <at> linutronix.de>
Cc: Peter Zijlstra <peterz <at> infradead.org>
Cc: Steven Rostedt <rostedt <at> goodmis.org>
Cc: Ingo Molnar <mingo <at> elte.hu>
---

 kernel/futex.c |   23 ++++++++++-------------
 1 files changed, 10 insertions(+), 13 deletions(-)

diff --git a/kernel/futex.c b/kernel/futex.c
index 0672ff8..d077201 100644
--- a/kernel/futex.c
+++ b/kernel/futex.c
 <at>  <at>  -2102,11 +2102,11  <at>  <at>  int handle_early_requeue_pi_wakeup(struct futex_hash_bucket *hb,
  * We call schedule in futex_wait_queue_me() when we enqueue and return there
  * via the following:
  * 1) wakeup on uaddr2 after an atomic lock acquisition by futex_requeue()
- * 2) wakeup on uaddr2 after a requeue and subsequent unlock
- * 3) signal (before or after requeue)
- * 4) timeout (before or after requeue)
+ * 2) wakeup on uaddr2 after a requeue
+ * 3) signal
(Continue reading)

Permalink | Reply | 1 comment |
headers
Frederic Weisbecker | 1 Aug 2009 01:22
Picon

Re: [ANNOUNCE] 2.6.31-rc4-rt1

On Thu, Jul 30, 2009 at 02:48:04AM +0200, Thomas Gleixner wrote:
> We are pleased to announce the next update to our new preempt-rt
> series.
>  
>     - update to 2.6.31-rc4
> 
> This is a major rework of the rt patch series. Thanks to Clark
> Williams and John Kacur for providing the merge to 2.6.30 while I was
> stabilizing .29-rt. While the 30-rt series looked quite stable, we
> decided to skip 30-rt entirely to keep track with the ongoing mainline
> development for various reaons. The .31-rt series is planned to be
> stabilized as we have done with .29-rt.
> 
> The main changes in this release are:
> 
> - interrupt threading
> 
>     interrupt threading is now a pure extension of the mainline
>     threaded interrupt infrastructure. This reduced the patch size of
>     the forced irq threading to mere
> 
>       8 files changed, 178 insertions(+), 13 deletions(-)
> 
>     Another interesting detail is that the new forced threaded code
>     uses per device threads instead of per interrupt line threads as
>     we have done in the past. This was just a logical consequence of
>     the per device thread (voluntary threading) infrastructure in
>     mainline and allows us now to share an interrupt line between a
>     hardirq based handler and a threaded handler device. One use case
>     which comes to my mind is AT91 which shares the timer and the
(Continue reading)

Permalink | Reply | 4 comments |
headers
Richard Henderson | 1 Aug 2009 01:30

Re: [PATCH 1/2] alpha: use .data.init_task instead of .data.init_thread.

On 07/31/2009 03:02 PM, Tim Abbott wrote:
> The INIT_TASK_DATA(THREAD_SIZE) macro call aligns to THREAD_SIZE (=
> 2*PAGE_SIZE).  So I'm not removing the 2 page alignment; I'm just moving
> it along with the code that needs to be aligned.

Sure.

>
> This change:
>
> -	. = ALIGN(2 * PAGE_SIZE);
> +	. = ALIGN(PAGE_SIZE);
>   	__init_end = .;
>
> removes the now-unnecessary (2 * PAGE_SIZE) alignment for __init_end
> caused by moving .data.init_task (it should have been in the first patch).

While it's technically unnecessary, it's also very much desired.

Think about it.  Suppose we have 9 pages of init, followed by the
two-page-aligned INIT_TASK_DATA.  So we get a page worth of padding
added.  It's better to have the two-page-alignment within the init
section so as to get 10 pages of init followed by no padding.  In
this way the page of padding gets freed with the rest of init.

Are you following me at all here?

r~
--
To unsubscribe from this list: send the line "unsubscribe linux-alpha" in
(Continue reading)

Permalink | Reply | 4 comments |
headers
john stultz | 1 Aug 2009 01:32
Picon
Favicon

Re: [RFC][patch 10/12] move NTP adjusted clock multiplier to struct timekeeper

On Fri, 2009-07-31 at 11:00 +0200, Martin Schwidefsky wrote:
> On Fri, 31 Jul 2009 01:12:59 -0700
> john stultz <johnstul <at> us.ibm.com> wrote:
> 
> > On Fri, 2009-07-31 at 09:52 +0200, Martin Schwidefsky wrote:
> > > On Thu, 30 Jul 2009 15:04:48 -0700
> > > john stultz <johnstul <at> us.ibm.com> wrote:
> > > 
> > > > On Wed, 2009-07-29 at 15:41 +0200, Martin Schwidefsky wrote:
> > > > > plain text document attachment (timekeeper-mult.diff)
> > > > > From: Martin Schwidefsky <schwidefsky <at> de.ibm.com>
> > > > > 
> > > > > The clocksource structure has two multipliers, the unmodified multiplier
> > > > > clock->mult_orig and the NTP corrected multiplier clock->mult. The NTP
> > > > > multiplier is misplaced in the struct clocksource, this is private
> > > > > information of the timekeeping code. Add the mult field to the struct
> > > > > timekeeper to contain the NTP corrected value, keep the unmodifed
> > > > > multiplier in clock->mult and remove clock->mult_orig. For consistency
> > > > > add the shift value associated with the NTP corrected mult value to
> > > > > struct timekeeper as well.
> > > > > 
> > > > > Cc: Ingo Molnar <mingo <at> elte.hu>
> > > > > Cc: Thomas Gleixner <tglx <at> linutronix.de>
> > > > > Cc: john stultz <johnstul <at> us.ibm.com>
> > > > > Cc: Daniel Walker <dwalker <at> fifo99.com>
> > > > > Signed-off-by: Martin Schwidefsky <schwidefsky <at> de.ibm.com>
> > > > > ---
> > > > >  arch/arm/plat-omap/common.c |    2 +-
> > > > >  include/linux/clocksource.h |    4 +---
> > > > >  kernel/time/timekeeping.c   |   43 +++++++++++++++++++++++++------------------
(Continue reading)

Permalink | Reply | 1 comment |
headers
Tim Abbott | 1 Aug 2009 01:44

Re: [PATCH 1/2] alpha: use .data.init_task instead of .data.init_thread.

On Fri, 31 Jul 2009, Richard Henderson wrote:

> On 07/31/2009 02:23 PM, Richard Henderson wrote:
> > Similarly it is *not* a bug that the page_aligned sections were before
> > data, because we already knew we had 2 page alignment from the end of
> > init + 2 pages of init_thread.
> 
> Indeed, I'll go further and say that the common definition of RW_DATA_SECTION
> is buggy.
[...]
> Given that we align the entire .data section why have interior padding to
> re-align for page-aligned data?  Surely a better ordering would be
[...]

Agreed.  I actually commented on this issue in one of the drafts of 
RW_DATA_SECTION, but forgot to check again whether Sam had addressed it 
when reviewing the final version.  Fortunately we're talking about a small 
inefficiency, not something more serious.  Below is your proposed change 
in patch form; I hope Sam will take a look at it.

	-Tim Abbott

Optimize the ordering of sections in RW_DATA_SECTION.

The current RW_DATA_SECTION macro doesn't place the various 
PAGE_SIZE-aligned sections next to each other.  This could result in up to 
a page of memory being wasted realigning to PAGE_SIZE twice.

Signed-off-by: Tim Abbott <tabbott <at> ksplice.com>
---
(Continue reading)

Permalink | Reply | 0 comments |
headers
Tim Abbott | 1 Aug 2009 01:56

Re: [PATCH 1/2] alpha: use .data.init_task instead of .data.init_thread.

On Fri, 31 Jul 2009, Richard Henderson wrote:

> On 07/31/2009 03:02 PM, Tim Abbott wrote:
> > 
> > This change:
> > 
> > -	. = ALIGN(2 * PAGE_SIZE);
> > +	. = ALIGN(PAGE_SIZE);
> >   	__init_end = .;
> > 
> > removes the now-unnecessary (2 * PAGE_SIZE) alignment for __init_end
> > caused by moving .data.init_task (it should have been in the first patch).
> 
> While it's technically unnecessary, it's also very much desired.
> 
> Think about it.  Suppose we have 9 pages of init, followed by the
> two-page-aligned INIT_TASK_DATA.  So we get a page worth of padding
> added.  It's better to have the two-page-alignment within the init
> section so as to get 10 pages of init followed by no padding.  In
> this way the page of padding gets freed with the rest of init.
> 
> Are you following me at all here?

Yeah, okay, that makes total sense (nice optimization).  New version of 
the patch below, with the alignment changed to THREAD_SIZE (and I added a 
comment explaining why).

	-Tim Abbott

From: Geoffrey Thomas <geofft <at> ksplice.com>
(Continue reading)

Permalink | Reply | 2 comments |
headers
Linus Torvalds | 1 Aug 2009 02:28
Gravatar

Re: [PATCH] information leak in sigaltstack


[ Cc'ing jakub, since that code generation looks crappy, and I think he 
  has worked on gcc memset(). I wonder if it's because we use -Os, and gcc 
  tries to avoid one REX prefix on the 'stosq'.

  I also wonder why gcc doesn't just notice that it should really only 
  initialize a single 4-byte word (no rep, no prefix, no nothing, just a 
  single "movl $0,44(%ebp)") - so even with the -Os, that is just wrong, 
  and it would have been better to do as multiple stores and then noticing 
  that most of them end up dead ]

On Fri, 31 Jul 2009, Ulrich Drepper wrote:
> 
> I was just composing a reply with basically this.  So  you'll apply this
> and don't wait for me to send a new version of the patch, right?

Grr. Gcc creates truly crap code for this trivial 24-byte memset. Why does 
it do that?

gcc knows the alignment is 8 bytes, but it still uses 6 4-byte stores 
instead of 3 8-byte ones. And it does it with this:

        xorl    %eax, %eax      # tmp88
        leaq    -48(%rbp), %rsi #, tmp86
        movl    $6, %ecx        #, tmp89
        movq    %rsi, %rdi      # tmp86, tmp87
        rep stosl

which is just incredibly lame in so many ways.
(Continue reading)

Permalink | Reply | 3 comments |
headers
Linus Torvalds | 1 Aug 2009 02:38
Gravatar

Re: + execve-must-clear-current-clear_child_tid.patch added to -mm tree


On Sat, 1 Aug 2009, Oleg Nesterov wrote:
> 
> Perhaps it is better to change mm_release() ? It has to play with
> ->clear_child_tid anyway.

Ahh. I take back my previous Ack. Your patch is better. I'll ack that 
instead.

		Linus
Permalink | Reply | 5 comments |

Gmane