From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934766Ab3BSW0F (ORCPT ); Tue, 19 Feb 2013 17:26:05 -0500 Received: from mail-pa0-f52.google.com ([209.85.220.52]:40682 "EHLO mail-pa0-f52.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934574Ab3BSW0C convert rfc822-to-8bit (ORCPT ); Tue, 19 Feb 2013 17:26:02 -0500 Date: Wed, 20 Feb 2013 07:25:52 +0900 Message-ID: <87621oc55b.wl%satoru.takeuchi@gmail.com> From: Satoru Takeuchi To: Ben Hutchings Cc: linux-kernel@vger.kernel.org, stable@vger.kernel.org, torvalds@linux-foundation.org, akpm@linux-foundation.org Subject: Re: [ 00/66] 3.2.39-stable review In-Reply-To: <20130217225001.621306883@decadent.org.uk> References: <20130217225001.621306883@decadent.org.uk> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/23.4 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org At Sun, 17 Feb 2013 22:50:01 +0000, Ben Hutchings wrote: > > This is the start of the stable review cycle for the 3.2.39 release. > There are 66 patches in this series, which will be posted as responses > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Tue Feb 19 23:00:00 UTC 2013. > Anything received after that time might be too late. > > A combined patch relative to 3.2.38 will be posted as an additional > response to this. A shortlog and diffstat can be found below. This kernel can be built and boot without any problem. Building a kernel with this kernel also works fine. - Build Machine: debian wheezy x86_64 CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz x 4 memory: 8GB - Test machine: debian wheezy x86_64(KVM guest on the Build Machine) vCPU: x2 memory: 2GB I reviewed the following patches and it looks good to me. > Oleg Nesterov (5): ... > wake_up_process() should be never used to wakeup a TASK_STOPPED/TRACED task > [9067ac85d533651b98c2ff903182a20cbb361fcb] ... > Shawn Bohrer (1): > sched/rt: Use root_domain of rt_rq not current processor > [aa7f67304d1a03180f463258aa6f15a8b434e77d] ... > Sjur Brændeland (1): > virtio_console: Don't access uninitialized data. > [aded024a12b32fc1ed9a80639681daae2d07ec25] > > Stephen Hemminger (1): > MAINTAINERS: Stephen Hemminger email change > [adbbf69d1a54abf424e91875746a610dcc80017d] Thanks, Satoru