linux-kernel - Re: [ANNOUNCE] 3.6.11-rt26

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <5110B552.9030903@huawei.com>
Date:	Tue, 5 Feb 2013 15:31:30 +0800
From:	Qiang Huang <h.huangqiang@...wei.com>
To:	Thomas Gleixner <tglx@...utronix.de>
CC:	LKML <linux-kernel@...r.kernel.org>,
	linux-rt-users <linux-rt-users@...r.kernel.org>,
	<peterz@...radead.org>
Subject: Re: [ANNOUNCE] 3.6.11-rt26

On 2013/2/4 22:58, Thomas Gleixner wrote:
> Dear RT Folks,
> 
> I'm pleased to announce the 3.6.11-rt26 release.
> 
> Changes since 3.6.11-rt25:
> 
>    1) Fix the RT highmem implementation on x86

Hi Thomas,

>From patches-3.6.11-rt28.patch.gz, your patch x86-highmem-make-it-work.patch
did this work. And you said
"It had been enabled quite some time, but never really worked."

But I think there is a previous patch mm-rt-kmap-atomic-scheduling.patch did
the job, so I think RT highmem on x86 should have worked.

Now with your patch, if we use kmap instead of kmap_atomic on RT, do we need
to revert Peter's patch as well?

I haven't tested it, but if Peter's patch did solved the problem, is his way
better than use kmap? Because we can use more highmem virtual address,
although with some switch latency in some small probability scenarios.

> 
>    2) Support highmem + RT on ARM
> 
>    3) Fix an one off error in the generic highmem code (upstream fix
>       did not make it into 3.6.stable)
> 
>    4) Upstream SLUB fixes (Christoph Lameter)
> 
>    5) Fix a few RT issues in mmc and amba drivers
> 
>    6) Initialize local locks in mm/swap.c early
> 
>    7) Use simple wait queues for completions. This is a performance
>       improvement.
> 
>       Completions do not have complex callbacks and the wakeup path is
>       disabling interrupts anyway. So using simple wait locks with the
>       raw spinlock is not a latency problem, but the "sleeping lock"
>       in the normal waitqueue is a source for lock bouncing:
> 
>       T1  	 	   T2
>       lock(WQ)
>       wakeup(T2)
>       ---> preemption
> 			   lock(WQ)
> 			   pi_boost(T1)
> 			   wait_for_lock(WQ)
>       unlock(WQ)
>       deboost(T1)
>       ---> preemption
> 			   ....
> 
>       The simple waitqueue reduces this to:
> 		   
>       T1  	 	   T2
>       raw_lock(WQ)
>       wakeup(T2)
>       raw_unlock(WQ)
>       ---> preemption
> 			   raw_lock(WQ)	
> 			   ....
> 
> @Steven: Sorry, I forgot the stable tags on:
> 	 drivers-tty-pl011-irq-disable-madness.patch
> 	 mmci-remove-bogus-irq-save.patch
> 	 idle-state.patch
> 	 might-sleep-check-for-idle.patch
> 	 mm-swap-fix-initialization.patch
> 
> I'm still digging through my mail backlog, so I have not yet decided
> whether this is the last RT release for 3.6.
> 
> 
> The delta patch against 3.6.11-rt25 is appended below and can be found
> here:
> 
>   http://www.kernel.org/pub/linux/kernel/projects/rt/3.6/incr/patch-3.6.11-rt25-rt26.patch.xz
> 
> The RT patch against 3.6.11 can be found here:
> 
>   http://www.kernel.org/pub/linux/kernel/projects/rt/3.6/patch-3.6.11-rt26.patch.xz
> 
> The split quilt queue is available at:
> 
>   http://www.kernel.org/pub/linux/kernel/projects/rt/3.6/patches-3.6.11-rt26.tar.xz
> 
> Enjoy,
> 
> 	tglx
> 


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