linux-toradex.git, branch v2.6.30.5

Linux 2.6.30.5

2009-08-16T21:19:38+00:00

ide: fix memory leak when flush command is issued

2009-08-16T21:19:19+00:00

commit bc146d23d1358af43f03793c3ad8c9f16bbcffcb upstream.

I'm using ide on 2.6.30.1 with xfs filesystem. I noticed a kernel memory
leak after writing lots of data, the kmalloc-96 slab cache keeps
growing. It seems the struct ide_cmd kmalloced by idedisk_prepare_flush
is never kfreed.

Commit a09485df9cda49fbde2766c86eb18a9cae585162 ("ide: move request
type specific code from ide_end_drive_cmd() to callers (v3)") and
f505d49ffd25ed062e76ffd17568d3937fcd338c ("ide: fix barriers support")
cause this regression, cmd->rq must now be set for ide_complete_cmd to
honor the IDE_TFLAG_DYN flag.

Signed-off-by: Maxime Bizon 
Acked-by: Bartlomiej Zolnierkiewicz 
Signed-off-by: David S. Miller 
Cc: Simon Kirby 
Signed-off-by: Greg Kroah-Hartman

ALSA: hda - Add missing vmaster initialization for ALC269

2009-08-16T21:19:19+00:00

commit 100d5eb36ba20dc0b99a17ea2b9800c567bfc3d1 upstream.

Without the initialization of vmaster NID, the dB information got
confused for ALC269 codec.

Reference: Novell bnc#527361
	https://bugzilla.novell.com/show_bug.cgi?id=527361

Signed-off-by: Takashi Iwai 
Signed-off-by: Greg Kroah-Hartman

NFS: Fix an O_DIRECT Oops...

2009-08-16T21:19:18+00:00

commit 1ae88b2e446261c038f2c0c3150ffae142b227a2 upstream.

We can't call nfs_readdata_release()/nfs_writedata_release() without
first initialising and referencing args.context. Doing so inside
nfs_direct_read_schedule_segment()/nfs_direct_write_schedule_segment()
causes an Oops.

We should rather be calling nfs_readdata_free()/nfs_writedata_free() in
those cases.

Looking at the O_DIRECT code, the "struct nfs_direct_req" is already
referencing the nfs_open_context for us. Since the readdata and writedata
structures carry a reference to that, we can simplify things by getting rid
of the extra nfs_open_context references, so that we can replace all
instances of nfs_readdata_release()/nfs_writedata_release().

Reported-by: Catalin Marinas 
Signed-off-by: Trond Myklebust 
Tested-by: Catalin Marinas 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

ring-buffer: Fix advance of reader in rb_buffer_peek()

2009-08-16T21:19:16+00:00

Backport for 2.6.30-stable of:

 469535a ring-buffer: Fix advance of reader in rb_buffer_peek()

When calling rb_buffer_peek() from ring_buffer_consume() and a
padding event is returned, the function rb_advance_reader() is
called twice. This may lead to missing samples or under high
workloads to the warning below. This patch fixes this. If a padding
event is returned by rb_buffer_peek() it will be consumed by the
calling function now.

Also, I simplified some code in ring_buffer_consume().

------------[ cut here ]------------
WARNING: at /dev/shm/.source/linux/kernel/trace/ring_buffer.c:2289 rb_advance_reader+0x2e/0xc5()
Hardware name: Anaheim
Modules linked in:
Pid: 29, comm: events/2 Tainted: G        W  2.6.31-rc3-oprofile-x86_64-standard-00059-g5050dc2 #1
Call Trace:
[] ? rb_advance_reader+0x2e/0xc5
[] warn_slowpath_common+0x77/0x8f
[] warn_slowpath_null+0xf/0x11
[] rb_advance_reader+0x2e/0xc5
[] ring_buffer_consume+0xa0/0xd2
[] op_cpu_buffer_read_entry+0x21/0x9e
[] ? __find_get_block+0x4b/0x165
[] sync_buffer+0xa5/0x401
[] ? __find_get_block+0x4b/0x165
[] ? wq_sync_buffer+0x0/0x78
[] wq_sync_buffer+0x5b/0x78
[] worker_thread+0x113/0x1ac
[] ? autoremove_wake_function+0x0/0x38
[] ? worker_thread+0x0/0x1ac
[] kthread+0x88/0x92
[] child_rip+0xa/0x20
[] ? kthread+0x0/0x92
[] ? child_rip+0x0/0x20
---[ end trace f561c0a58fcc89bd ]---

Cc: Steven Rostedt 
Signed-off-by: Robert Richter 
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman

Make sock_sendpage() use kernel_sendpage()

2009-08-16T21:19:15+00:00

commit e694958388c50148389b0e9b9e9e8945cf0f1b98 upstream.

kernel_sendpage() does the proper default case handling for when the
socket doesn't have a native sendpage implementation.

Now, arguably this might be something that we could instead solve by
just specifying that all protocols should do it themselves at the
protocol level, but we really only care about the common protocols.
Does anybody really care about sendpage on something like Appletalk? Not
likely.

Acked-by: David S. Miller 
Acked-by: Julien TINNES 
Acked-by: Tavis Ormandy 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

mm_for_maps: take ->cred_guard_mutex to fix the race with exec

2009-08-16T21:19:14+00:00

commit 704b836cbf19e885f8366bccb2e4b0474346c02d upstream.

The problem is minor, but without ->cred_guard_mutex held we can race
with exec() and get the new ->mm but check old creds.

Now we do not need to re-check task->mm after ptrace_may_access(), it
can't be changed to the new mm under us.

Strictly speaking, this also fixes another very minor problem. Unless
security check fails or the task exits mm_for_maps() should never
return NULL, the caller should get either old or new ->mm.

Signed-off-by: Oleg Nesterov 
Acked-by: Serge Hallyn 
Signed-off-by: James Morris 
Signed-off-by: Greg Kroah-Hartman

mm_for_maps: shift down_read(mmap_sem) to the caller

2009-08-16T21:19:13+00:00

commit 00f89d218523b9bf6b522349c039d5ac80aa536d upstream.

mm_for_maps() takes ->mmap_sem after security checks, this looks
strange and obfuscates the locking rules. Move this lock to its
single caller, m_start().

Signed-off-by: Oleg Nesterov 
Acked-by: Serge Hallyn 
Signed-off-by: James Morris 
Signed-off-by: Greg Kroah-Hartman

mm_for_maps: simplify, use ptrace_may_access()

2009-08-16T21:19:08+00:00

commit 13f0feafa6b8aead57a2a328e2fca6a5828bf286 upstream.

It would be nice to kill __ptrace_may_access(). It requires task_lock(),
but this lock is only needed to read mm->flags in the middle.

Convert mm_for_maps() to use ptrace_may_access(), this also simplifies
the code a little bit.

Also, we do not need to take ->mmap_sem in advance. In fact I think
mm_for_maps() should not play with ->mmap_sem at all, the caller should
take this lock.

With or without this patch, without ->cred_guard_mutex held we can race
with exec() and get the new ->mm but check old creds.

Signed-off-by: Oleg Nesterov 
Reviewed-by: Serge Hallyn 
Signed-off-by: James Morris 
Signed-off-by: Greg Kroah-Hartman

x86: Fix VMI && stack protector

2009-08-16T21:19:07+00:00

commit 7d5b005652bc5ae3e1e0efc53fd0e25a643ec506 upstream.

With CONFIG_STACK_PROTECTOR turned on, VMI doesn't boot with
more than one processor. The problem is with the gs value not
being initialized correctly when registering the secondary
processor for VMI's case.

The patch below initializes the gs value for the AP to
__KERNEL_STACK_CANARY. Without this the secondary processor
keeps on taking a GP on every gs access.

Signed-off-by: Alok N Kataria 
LKML-Reference: <1249425262.18955.40.camel@ank32.eng.vmware.com>
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman