* [ 1/7] random: run random_int_secret_init() run after all late_initcalls
2013-10-18 19:52 [ 0/7] 3.0.101-stable review Greg Kroah-Hartman
@ 2013-10-18 19:52 ` Greg Kroah-Hartman
2013-10-18 19:52 ` [ 2/7] vfs: allow O_PATH file descriptors for fstatfs() Greg Kroah-Hartman
` (8 subsequent siblings)
9 siblings, 0 replies; 14+ messages in thread
From: Greg Kroah-Hartman @ 2013-10-18 19:52 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Theodore Tso
3.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Theodore Ts'o <tytso@mit.edu>
commit 47d06e532e95b71c0db3839ebdef3fe8812fca2c upstream.
The some platforms (e.g., ARM) initializes their clocks as
late_initcalls for some unknown reason. So make sure
random_int_secret_init() is run after all of the late_initcalls are
run.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/char/random.c | 3 +--
include/linux/random.h | 1 +
init/main.c | 2 ++
3 files changed, 4 insertions(+), 2 deletions(-)
--- a/drivers/char/random.c
+++ b/drivers/char/random.c
@@ -1435,12 +1435,11 @@ ctl_table random_table[] = {
static u32 random_int_secret[MD5_MESSAGE_BYTES / 4] ____cacheline_aligned;
-static int __init random_int_secret_init(void)
+int random_int_secret_init(void)
{
get_random_bytes(random_int_secret, sizeof(random_int_secret));
return 0;
}
-late_initcall(random_int_secret_init);
/*
* Get a random word for internal kernel use only. Similar to urandom but
--- a/include/linux/random.h
+++ b/include/linux/random.h
@@ -56,6 +56,7 @@ extern void add_interrupt_randomness(int
extern void get_random_bytes(void *buf, int nbytes);
extern void get_random_bytes_arch(void *buf, int nbytes);
void generate_random_uuid(unsigned char uuid_out[16]);
+extern int random_int_secret_init(void);
#ifndef MODULE
extern const struct file_operations random_fops, urandom_fops;
--- a/init/main.c
+++ b/init/main.c
@@ -68,6 +68,7 @@
#include <linux/shmem_fs.h>
#include <linux/slab.h>
#include <linux/perf_event.h>
+#include <linux/random.h>
#include <asm/io.h>
#include <asm/bugs.h>
@@ -717,6 +718,7 @@ static void __init do_basic_setup(void)
init_irq_proc();
do_ctors();
do_initcalls();
+ random_int_secret_init();
}
static void __init do_pre_smp_initcalls(void)
^ permalink raw reply [flat|nested] 14+ messages in thread* [ 2/7] vfs: allow O_PATH file descriptors for fstatfs()
2013-10-18 19:52 [ 0/7] 3.0.101-stable review Greg Kroah-Hartman
2013-10-18 19:52 ` [ 1/7] random: run random_int_secret_init() run after all late_initcalls Greg Kroah-Hartman
@ 2013-10-18 19:52 ` Greg Kroah-Hartman
2013-10-18 19:52 ` [ 3/7] ext4: fix memory leak in xattr Greg Kroah-Hartman
` (7 subsequent siblings)
9 siblings, 0 replies; 14+ messages in thread
From: Greg Kroah-Hartman @ 2013-10-18 19:52 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Al Viro, Linus Torvalds
3.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Linus Torvalds <torvalds@linux-foundation.org>
commit 9d05746e7b16d8565dddbe3200faa1e669d23bbf upstream.
Olga reported that file descriptors opened with O_PATH do not work with
fstatfs(), found during further development of ksh93's thread support.
There is no reason to not allow O_PATH file descriptors here (fstatfs is
very much a path operation), so use "fdget_raw()". See commit
55815f70147d ("vfs: make O_PATH file descriptors usable for 'fstat()'")
for a very similar issue reported for fstat() by the same team.
Reported-and-tested-by: ольга крыжановская <olga.kryzhanovska@gmail.com>
Acked-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/statfs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/fs/statfs.c
+++ b/fs/statfs.c
@@ -86,7 +86,7 @@ int user_statfs(const char __user *pathn
int fd_statfs(int fd, struct kstatfs *st)
{
- struct file *file = fget(fd);
+ struct file *file = fget_raw(fd);
int error = -EBADF;
if (file) {
error = vfs_statfs(&file->f_path, st);
^ permalink raw reply [flat|nested] 14+ messages in thread* [ 3/7] ext4: fix memory leak in xattr
2013-10-18 19:52 [ 0/7] 3.0.101-stable review Greg Kroah-Hartman
2013-10-18 19:52 ` [ 1/7] random: run random_int_secret_init() run after all late_initcalls Greg Kroah-Hartman
2013-10-18 19:52 ` [ 2/7] vfs: allow O_PATH file descriptors for fstatfs() Greg Kroah-Hartman
@ 2013-10-18 19:52 ` Greg Kroah-Hartman
2013-10-21 21:30 ` Felipe Pena
2013-10-18 19:52 ` [ 4/7] parisc: fix interruption handler to respect pagefault_disable() Greg Kroah-Hartman
` (6 subsequent siblings)
9 siblings, 1 reply; 14+ messages in thread
From: Greg Kroah-Hartman @ 2013-10-18 19:52 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Dave Jones, Theodore Tso,
Eric Sandeen
3.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dave Jones <davej@redhat.com>
commit 6e4ea8e33b2057b85d75175dd89b93f5e26de3bc upstream.
If we take the 2nd retry path in ext4_expand_extra_isize_ea, we
potentionally return from the function without having freed these
allocations. If we don't do the return, we over-write the previous
allocation pointers, so we leak either way.
Spotted with Coverity.
[ Fixed by tytso to set is and bs to NULL after freeing these
pointers, in case in the retry loop we later end up triggering an
error causing a jump to cleanup, at which point we could have a double
free bug. -- Ted ]
Signed-off-by: Dave Jones <davej@fedoraproject.org>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Reviewed-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/ext4/xattr.c | 2 ++
1 file changed, 2 insertions(+)
--- a/fs/ext4/xattr.c
+++ b/fs/ext4/xattr.c
@@ -1271,6 +1271,8 @@ retry:
s_min_extra_isize) {
tried_min_extra_isize++;
new_extra_isize = s_min_extra_isize;
+ kfree(is); is = NULL;
+ kfree(bs); bs = NULL;
goto retry;
}
error = -1;
^ permalink raw reply [flat|nested] 14+ messages in thread* Re: [ 3/7] ext4: fix memory leak in xattr
2013-10-18 19:52 ` [ 3/7] ext4: fix memory leak in xattr Greg Kroah-Hartman
@ 2013-10-21 21:30 ` Felipe Pena
0 siblings, 0 replies; 14+ messages in thread
From: Felipe Pena @ 2013-10-21 21:30 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: linux-kernel, stable, Dave Jones, Theodore Tso, Eric Sandeen
Hi,
On Fri, Oct 18, 2013 at 4:52 PM, Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
> 3.0-stable review patch. If anyone has any objections, please let me know.
>
> ------------------
>
> From: Dave Jones <davej@redhat.com>
>
> commit 6e4ea8e33b2057b85d75175dd89b93f5e26de3bc upstream.
>
> If we take the 2nd retry path in ext4_expand_extra_isize_ea, we
> potentionally return from the function without having freed these
> allocations. If we don't do the return, we over-write the previous
> allocation pointers, so we leak either way.
>
> Spotted with Coverity.
>
> [ Fixed by tytso to set is and bs to NULL after freeing these
> pointers, in case in the retry loop we later end up triggering an
> error causing a jump to cleanup, at which point we could have a double
> free bug. -- Ted ]
>
> Signed-off-by: Dave Jones <davej@fedoraproject.org>
> Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
> Reviewed-by: Eric Sandeen <sandeen@redhat.com>
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
> ---
> fs/ext4/xattr.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> --- a/fs/ext4/xattr.c
> +++ b/fs/ext4/xattr.c
> @@ -1271,6 +1271,8 @@ retry:
> s_min_extra_isize) {
> tried_min_extra_isize++;
> new_extra_isize = s_min_extra_isize;
> + kfree(is); is = NULL;
> + kfree(bs); bs = NULL;
Looks like such lines are not conforming to coding style, or?
> goto retry;
> }
> error = -1;
>
>
> --
> 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/
--
Regards,
Felipe Pena
^ permalink raw reply [flat|nested] 14+ messages in thread
* [ 4/7] parisc: fix interruption handler to respect pagefault_disable()
2013-10-18 19:52 [ 0/7] 3.0.101-stable review Greg Kroah-Hartman
` (2 preceding siblings ...)
2013-10-18 19:52 ` [ 3/7] ext4: fix memory leak in xattr Greg Kroah-Hartman
@ 2013-10-18 19:52 ` Greg Kroah-Hartman
2013-10-18 19:52 ` [ 5/7] watchdog: ts72xx_wdt: locking bug in ioctl Greg Kroah-Hartman
` (5 subsequent siblings)
9 siblings, 0 replies; 14+ messages in thread
From: Greg Kroah-Hartman @ 2013-10-18 19:52 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Helge Deller, John David Anglin
3.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Helge Deller <deller@gmx.de>
commit 59b33f148cc08fb33cbe823fca1e34f7f023765e upstream.
Running an "echo t > /proc/sysrq-trigger" crashes the parisc kernel. The
problem is, that in print_worker_info() we try to read the workqueue info via
the probe_kernel_read() functions which use pagefault_disable() to avoid
crashes like this:
probe_kernel_read(&pwq, &worker->current_pwq, sizeof(pwq));
probe_kernel_read(&wq, &pwq->wq, sizeof(wq));
probe_kernel_read(name, wq->name, sizeof(name) - 1);
The problem here is, that the first probe_kernel_read(&pwq) might return zero
in pwq and as such the following probe_kernel_reads() try to access contents of
the page zero which is read protected and generate a kernel segfault.
With this patch we fix the interruption handler to call parisc_terminate()
directly only if pagefault_disable() was not called (in which case
preempt_count()==0). Otherwise we hand over to the pagefault handler which
will try to look up the faulting address in the fixup tables.
Signed-off-by: Helge Deller <deller@gmx.de>
Signed-off-by: John David Anglin <dave.anglin@bell.net>
Signed-off-by: Helge Deller <deller@gmx.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/parisc/kernel/traps.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
--- a/arch/parisc/kernel/traps.c
+++ b/arch/parisc/kernel/traps.c
@@ -811,14 +811,14 @@ void notrace handle_interruption(int cod
else {
/*
- * The kernel should never fault on its own address space.
+ * The kernel should never fault on its own address space,
+ * unless pagefault_disable() was called before.
*/
- if (fault_space == 0)
+ if (fault_space == 0 && !in_atomic())
{
pdc_chassis_send_status(PDC_CHASSIS_DIRECT_PANIC);
parisc_terminate("Kernel Fault", regs, code, fault_address);
-
}
}
^ permalink raw reply [flat|nested] 14+ messages in thread* [ 5/7] watchdog: ts72xx_wdt: locking bug in ioctl
2013-10-18 19:52 [ 0/7] 3.0.101-stable review Greg Kroah-Hartman
` (3 preceding siblings ...)
2013-10-18 19:52 ` [ 4/7] parisc: fix interruption handler to respect pagefault_disable() Greg Kroah-Hartman
@ 2013-10-18 19:52 ` Greg Kroah-Hartman
2013-10-18 19:52 ` [ 6/7] drm/radeon: fix hw contexts for SUMO2 asics Greg Kroah-Hartman
` (4 subsequent siblings)
9 siblings, 0 replies; 14+ messages in thread
From: Greg Kroah-Hartman @ 2013-10-18 19:52 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Dan Carpenter, Guenter Roeck,
Wim Van Sebroeck, Jonghwan Choi
3.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dan Carpenter <dan.carpenter@oracle.com>
commit 8612ed0d97abcf1c016d34755b7cf2060de71963 upstream.
Calling the WDIOC_GETSTATUS & WDIOC_GETBOOTSTATUS and twice will cause a
interruptible deadlock.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
Cc: Jonghwan Choi <jhbird.choi@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/watchdog/ts72xx_wdt.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/drivers/watchdog/ts72xx_wdt.c
+++ b/drivers/watchdog/ts72xx_wdt.c
@@ -310,7 +310,8 @@ static long ts72xx_wdt_ioctl(struct file
case WDIOC_GETSTATUS:
case WDIOC_GETBOOTSTATUS:
- return put_user(0, p);
+ error = put_user(0, p);
+ break;
case WDIOC_KEEPALIVE:
ts72xx_wdt_kick(wdt);
^ permalink raw reply [flat|nested] 14+ messages in thread* [ 6/7] drm/radeon: fix hw contexts for SUMO2 asics
2013-10-18 19:52 [ 0/7] 3.0.101-stable review Greg Kroah-Hartman
` (4 preceding siblings ...)
2013-10-18 19:52 ` [ 5/7] watchdog: ts72xx_wdt: locking bug in ioctl Greg Kroah-Hartman
@ 2013-10-18 19:52 ` Greg Kroah-Hartman
2013-10-18 19:52 ` [ 7/7] ipv6: tcp: fix panic in SYN processing Greg Kroah-Hartman
` (3 subsequent siblings)
9 siblings, 0 replies; 14+ messages in thread
From: Greg Kroah-Hartman @ 2013-10-18 19:52 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, wojciech kapuscinski, Alex Deucher
3.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: wojciech kapuscinski <wojtask9@wp.pl>
commit 50b8f5aec04ebec7dbdf2adb17220b9148c99e63 upstream.
They have 4 rather than 8.
Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=63599
Signed-off-by: wojciech kapuscinski <wojtask9@wp.pl>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/radeon/evergreen.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -1749,7 +1749,7 @@ static void evergreen_gpu_init(struct ra
rdev->config.evergreen.sx_max_export_size = 256;
rdev->config.evergreen.sx_max_export_pos_size = 64;
rdev->config.evergreen.sx_max_export_smx_size = 192;
- rdev->config.evergreen.max_hw_contexts = 8;
+ rdev->config.evergreen.max_hw_contexts = 4;
rdev->config.evergreen.sq_num_cf_insts = 2;
rdev->config.evergreen.sc_prim_fifo_size = 0x40;
^ permalink raw reply [flat|nested] 14+ messages in thread* [ 7/7] ipv6: tcp: fix panic in SYN processing
2013-10-18 19:52 [ 0/7] 3.0.101-stable review Greg Kroah-Hartman
` (5 preceding siblings ...)
2013-10-18 19:52 ` [ 6/7] drm/radeon: fix hw contexts for SUMO2 asics Greg Kroah-Hartman
@ 2013-10-18 19:52 ` Greg Kroah-Hartman
2013-10-19 0:08 ` [ 0/7] 3.0.101-stable review Steven Rostedt
` (2 subsequent siblings)
9 siblings, 0 replies; 14+ messages in thread
From: Greg Kroah-Hartman @ 2013-10-18 19:52 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Eric Dumazet, David S. Miller,
Willy Tarreau
3.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Eric Dumazet <eric.dumazet@gmail.com>
commit c16a98ed91597b40b22b540c6517103497ef8e74 upstream.
commit 72a3effaf633bc ([NET]: Size listen hash tables using backlog
hint) added a bug allowing inet6_synq_hash() to return an out of bound
array index, because of u16 overflow.
Bug can happen if system admins set net.core.somaxconn &
net.ipv4.tcp_max_syn_backlog sysctls to values greater than 65536
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Cc: Willy Tarreau <w@1wt.eu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/ipv6/inet6_connection_sock.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/net/ipv6/inet6_connection_sock.c
+++ b/net/ipv6/inet6_connection_sock.c
@@ -85,7 +85,7 @@ struct dst_entry *inet6_csk_route_req(st
* request_sock (formerly open request) hash tables.
*/
static u32 inet6_synq_hash(const struct in6_addr *raddr, const __be16 rport,
- const u32 rnd, const u16 synq_hsize)
+ const u32 rnd, const u32 synq_hsize)
{
u32 c;
^ permalink raw reply [flat|nested] 14+ messages in thread* Re: [ 0/7] 3.0.101-stable review
2013-10-18 19:52 [ 0/7] 3.0.101-stable review Greg Kroah-Hartman
` (6 preceding siblings ...)
2013-10-18 19:52 ` [ 7/7] ipv6: tcp: fix panic in SYN processing Greg Kroah-Hartman
@ 2013-10-19 0:08 ` Steven Rostedt
2013-10-19 0:19 ` Guenter Roeck
2013-10-19 3:39 ` Shuah Khan
9 siblings, 0 replies; 14+ messages in thread
From: Steven Rostedt @ 2013-10-19 0:08 UTC (permalink / raw)
To: Greg Kroah-Hartman; +Cc: linux-kernel, torvalds, akpm, stable
On Fri, 18 Oct 2013 12:52:47 -0700
Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
> NOTE:
> This is the LAST 3.0.x stable kernel release that I will be doing.
> After this release, 3.0.x is End-Of-Life, please move to the 3.10.x,
> or if you must, 3.4.x series. For more information about longterm
> stable releases and how long they will be maintained, please see
> https://www.kernel.org/category/releases.html
Yeah! Yippee! Hooray!
-- Steve
^ permalink raw reply [flat|nested] 14+ messages in thread* Re: [ 0/7] 3.0.101-stable review
2013-10-18 19:52 [ 0/7] 3.0.101-stable review Greg Kroah-Hartman
` (7 preceding siblings ...)
2013-10-19 0:08 ` [ 0/7] 3.0.101-stable review Steven Rostedt
@ 2013-10-19 0:19 ` Guenter Roeck
2013-10-19 4:49 ` Greg Kroah-Hartman
2013-10-19 3:39 ` Shuah Khan
9 siblings, 1 reply; 14+ messages in thread
From: Guenter Roeck @ 2013-10-19 0:19 UTC (permalink / raw)
To: Greg Kroah-Hartman; +Cc: linux-kernel, torvalds, akpm, stable
On Fri, Oct 18, 2013 at 12:52:47PM -0700, Greg Kroah-Hartman wrote:
> NOTE:
> This is the LAST 3.0.x stable kernel release that I will be doing.
> After this release, 3.0.x is End-Of-Life, please move to the 3.10.x,
> or if you must, 3.4.x series. For more information about longterm
> stable releases and how long they will be maintained, please see
> https://www.kernel.org/category/releases.html
>
> This is the start of the stable review cycle for the 3.0.101 release.
> There are 7 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Sun Oct 20 19:50:26 UTC 2013.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.0.101-rc1.gz
> and the diffstat can be found below.
>
Build results:
total: 98 pass: 71 skipped: 16 fail: 11
qemu tests all passed.
This matches the results seen with 3.0.100.
Details are available at http://server.roeck-us.net:8010/builders.
Thank
Guenter
^ permalink raw reply [flat|nested] 14+ messages in thread* Re: [ 0/7] 3.0.101-stable review
2013-10-19 0:19 ` Guenter Roeck
@ 2013-10-19 4:49 ` Greg Kroah-Hartman
0 siblings, 0 replies; 14+ messages in thread
From: Greg Kroah-Hartman @ 2013-10-19 4:49 UTC (permalink / raw)
To: Guenter Roeck; +Cc: linux-kernel, torvalds, akpm, stable
On Fri, Oct 18, 2013 at 05:19:32PM -0700, Guenter Roeck wrote:
> On Fri, Oct 18, 2013 at 12:52:47PM -0700, Greg Kroah-Hartman wrote:
> > NOTE:
> > This is the LAST 3.0.x stable kernel release that I will be doing.
> > After this release, 3.0.x is End-Of-Life, please move to the 3.10.x,
> > or if you must, 3.4.x series. For more information about longterm
> > stable releases and how long they will be maintained, please see
> > https://www.kernel.org/category/releases.html
> >
> > This is the start of the stable review cycle for the 3.0.101 release.
> > There are 7 patches in this series, all will be posted as a response
> > to this one. If anyone has any issues with these being applied, please
> > let me know.
> >
> > Responses should be made by Sun Oct 20 19:50:26 UTC 2013.
> > Anything received after that time might be too late.
> >
> > The whole patch series can be found in one patch at:
> > kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.0.101-rc1.gz
> > and the diffstat can be found below.
> >
> Build results:
> total: 98 pass: 71 skipped: 16 fail: 11
>
> qemu tests all passed.
>
> This matches the results seen with 3.0.100.
Great, thanks for testing and letting me know.
greg k-h
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [ 0/7] 3.0.101-stable review
2013-10-18 19:52 [ 0/7] 3.0.101-stable review Greg Kroah-Hartman
` (8 preceding siblings ...)
2013-10-19 0:19 ` Guenter Roeck
@ 2013-10-19 3:39 ` Shuah Khan
2013-10-19 4:49 ` Greg Kroah-Hartman
9 siblings, 1 reply; 14+ messages in thread
From: Shuah Khan @ 2013-10-19 3:39 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: linux-kernel, torvalds, akpm, stable, Shuah Khan,
shuahkhan@gmail.com
On 10/18/2013 01:52 PM, Greg Kroah-Hartman wrote:
> NOTE:
> This is the LAST 3.0.x stable kernel release that I will be doing.
> After this release, 3.0.x is End-Of-Life, please move to the 3.10.x,
> or if you must, 3.4.x series. For more information about longterm
> stable releases and how long they will be maintained, please see
> https://www.kernel.org/category/releases.html
>
> This is the start of the stable review cycle for the 3.0.101 release.
> There are 7 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Sun Oct 20 19:50:26 UTC 2013.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.0.101-rc1.gz
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
>
> -------------
Patch applied cleanly yes
Compile testing passed
Boot testing passed
dmesg regression testing passed
Cross-compile testing passed
dmesgs look good. No regressions compared to the previous dmesgs for
this release. dmesg emerg, crit, alert, err are clean. No regressions
in warn.
Test systems
Samsung Series 9 900X4C Intel Corei5 (3.4 and later)
HP ProBook 6475b AMD A10-4600M APU with Radeon(tm) HD Graphics
HP Compaq dc7700 SFF desktop: x86-64 Intel Core-i2 (cross-compile
testing)
alpha defconfig Passed
arm defconfig not applicable
arm64 defconfig Not applicable
blackfin defconfig Passed
c6x defconfig Not applicable
mips defconfig Passed
mipsel defconfig Passed
powerpc wii_defconfig Passed
sh defconfig Passed
sparc defconfig Passed
tile tilegx_defconfig Passed
-- Shuah
--
Shuah Khan
Senior Linux Kernel Developer - Open Source Group
Samsung Research America(Silicon Valley)
shuah.kh@samsung.com | (970) 672-0658
^ permalink raw reply [flat|nested] 14+ messages in thread* Re: [ 0/7] 3.0.101-stable review
2013-10-19 3:39 ` Shuah Khan
@ 2013-10-19 4:49 ` Greg Kroah-Hartman
0 siblings, 0 replies; 14+ messages in thread
From: Greg Kroah-Hartman @ 2013-10-19 4:49 UTC (permalink / raw)
To: Shuah Khan; +Cc: linux-kernel, torvalds, akpm, stable, shuahkhan@gmail.com
On Fri, Oct 18, 2013 at 09:39:51PM -0600, Shuah Khan wrote:
> On 10/18/2013 01:52 PM, Greg Kroah-Hartman wrote:
> > NOTE:
> > This is the LAST 3.0.x stable kernel release that I will be doing.
> > After this release, 3.0.x is End-Of-Life, please move to the 3.10.x,
> > or if you must, 3.4.x series. For more information about longterm
> > stable releases and how long they will be maintained, please see
> > https://www.kernel.org/category/releases.html
> >
> > This is the start of the stable review cycle for the 3.0.101 release.
> > There are 7 patches in this series, all will be posted as a response
> > to this one. If anyone has any issues with these being applied, please
> > let me know.
> >
> > Responses should be made by Sun Oct 20 19:50:26 UTC 2013.
> > Anything received after that time might be too late.
> >
> > The whole patch series can be found in one patch at:
> > kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.0.101-rc1.gz
> > and the diffstat can be found below.
> >
> > thanks,
> >
> > greg k-h
> >
> > -------------
>
> Patch applied cleanly yes
> Compile testing passed
> Boot testing passed
> dmesg regression testing passed
> Cross-compile testing passed
>
> dmesgs look good. No regressions compared to the previous dmesgs for
> this release. dmesg emerg, crit, alert, err are clean. No regressions
> in warn.
Thanks for testing and letting me know.
greg k-h
^ permalink raw reply [flat|nested] 14+ messages in thread