~thopiekar/linux/+git/linux-stable:linux-2.6.18.y

Last commit made on 2007-02-23
Get this branch:
git clone -b linux-2.6.18.y https://git.launchpad.net/~thopiekar/linux/+git/linux-stable

Branch merges

Branch information

Name:
linux-2.6.18.y
Repository:
lp:~thopiekar/linux/+git/linux-stable

Recent commits

299a247... by Greg Kroah-Hartman <email address hidden> on 2007-02-23

Linux 2.6.18.8

b3008f6... by Hugh Dickins <email address hidden> on 2007-02-23

fix umask when noACL kernel meets extN tuned for ACLs

Fix insecure default behaviour reported by Tigran Aivazian: if an ext2
or ext3 filesystem is tuned to mount with "acl", but mounted by
a kernel built without ACL support, then umask was ignored when creating
inodes - though root or user has umask 022, touch creates files as 0666,
and mkdir creates directories as 0777.

This appears to have worked right until 2.6.11, when a fix to the default
mode on symlinks (always 0777) assumed VFS applies umask: which it does,
unless the mount is marked for ACLs; but ext[23] set MS_POSIXACL in
s_flags according to s_mount_opt set according to def_mount_opts.

We could revert to the 2.6.10 ext[23]_init_acl (adding an S_ISLNK test);
but other filesystems only set MS_POSIXACL when ACLs are configured. We
could fix this at another level; but it seems most robust to avoid setting
the s_mount_opt flag in the first place (at the expense of more ifdefs).

Likewise don't set the XATTR_USER flag when built without XATTR support.

Signed-off-by: Hugh Dickins <email address hidden>
Acked-by: Andreas Gruenbacher <email address hidden>
Cc: Tigran Aivazian <email address hidden>
Signed-off-by: Chris Wright <email address hidden>
Signed-off-by: Greg Kroah-Hartman <email address hidden>

4f1e627... by Badari Pulavarty on 2006-12-22

Fix for shmem_truncate_range() BUG_ON()

Ran into BUG() while doing madvise(REMOVE) testing. If we are punching a
hole into shared memory segment using madvise(REMOVE) and the entire hole
is below the indirect blocks, we hit following assert.

         BUG_ON(limit <= SHMEM_NR_DIRECT);

Signed-off-by: Badari Pulavarty <email address hidden>
Cc: Hugh Dickins <email address hidden>
Signed-off-by: Andrew Morton <email address hidden>
Signed-off-by: Chris Wright <email address hidden>
Signed-off-by: Greg Kroah-Hartman <email address hidden>

f102c84... by Hugh Dickins <email address hidden> on 2007-01-04

make ppc64 current preempt-safe

Repeated -j20 kernel builds on a G5 Quad running an SMP PREEMPT kernel
would often collapse within a day, some exec failing with "Bad address".
In each case examined, load_elf_binary was doing a kernel_read, but
generic_file_aio_read's access_ok saw current->thread.fs.seg as USER_DS
instead of KERNEL_DS.

objdump of filemap.o shows gcc 4.1.0 emitting "mr r5,r13 ... ld r9,416(r5)"
here for get_paca()->__current, instead of the expected and much more usual
"ld r9,416(r13)"; I've seen other gcc4s do the same, but perhaps not gcc3s.

So, if the task is preempted and rescheduled on a different cpu in between
the mr and the ld, r5 will be looking at a different paca_struct from the
one it's now on, pick up the wrong __current, and perhaps the wrong seg.
Presumably much worse could happen elsewhere, though that split is rare.

Other architectures appear to be safe (x86_64's read_pda is more limiting
than get_paca), but ppc64 needs to force "current" into one instruction.

Signed-off-by: Hugh Dickins <email address hidden>
Signed-off-by: Chris Wright <email address hidden>
Signed-off-by: Greg Kroah-Hartman <email address hidden>

700019f... by Hugh Dickins <email address hidden> on 2007-01-04

fix msync error on unmapped area

Fix the 2.6.18 sys_msync to report -ENOMEM correctly when an unmapped area
falls within its range, and not to overshoot: to satisfy LSB 3.1 tests and
to fix Debian Bug#394392. Took the 2.6.19 sys_msync as starting point
(including its cleanup of repeated "current->mm"s), reintroducing the
msync_interval and balance_dirty_pages_ratelimited_nr needed in 2.6.18.

The misbehaviour fixed here may not seem very serious; but it was enough
to mislead Debian into backporting 2.6.19's dirty page tracking patches,
with attendant mayhem when those resulted in unsuspected file corruption.

Signed-off-by: Hugh Dickins <email address hidden>
Signed-off-by: Chris Wright <email address hidden>
Signed-off-by: Greg Kroah-Hartman <email address hidden>

dbee2bf... by Hugh Dickins <email address hidden> on 2006-12-10

read_zero_pagealigned() locking fix

Ramiro Voicu hits the BUG_ON(!pte_none(*pte)) in zeromap_pte_range: kernel
bugzilla 7645. Right: read_zero_pagealigned uses down_read of mmap_sem,
but another thread's racing read of /dev/zero, or a normal fault, can
easily set that pte again, in between zap_page_range and zeromap_page_range
getting there. It's been wrong ever since 2.4.3.

The simple fix is to use down_write instead, but that would serialize reads
of /dev/zero more than at present: perhaps some app would be badly
affected. So instead let zeromap_page_range return the error instead of
BUG_ON, and read_zero_pagealigned break to the slower clear_user loop in
that case - there's no need to optimize for it.

Use -EEXIST for when a pte is found: BUG_ON in mmap_zero (the other user of
zeromap_page_range), though it really isn't interesting there. And since
mmap_zero wants -EAGAIN for out-of-memory, the zeromaps better return that
than -ENOMEM.

Signed-off-by: Hugh Dickins <email address hidden>
Cc: Ramiro Voicu: <email address hidden>
Signed-off-by: Andrew Morton <email address hidden>
Signed-off-by: Chris Wright <email address hidden>
Signed-off-by: Greg Kroah-Hartman <email address hidden>

d84ad2c... by Linus Torvalds <email address hidden> on 2006-12-16

Fix incorrect user space access locking in mincore() (CVE-2006-4814)

Doug Chapman noticed that mincore() will doa "copy_to_user()" of the
result while holding the mmap semaphore for reading, which is a big
no-no. While a recursive read-lock on a semaphore in the case of a page
fault happens to work, we don't actually allow them due to deadlock
schenarios with writers due to fairness issues.

Doug and Marcel sent in a patch to fix it, but I decided to just rewrite
the mess instead - not just fixing the locking problem, but making the
code smaller and (imho) much easier to understand.

Cc: Doug Chapman <email address hidden>
Cc: Marcel Holtmann <email address hidden>
Cc: Hugh Dickins <email address hidden>
Cc: Andrew Morton <email address hidden>
[chrisw: fold in subsequent fix: 4fb23e439ce0]
Acked-by: Hugh Dickins <email address hidden>
[chrisw: fold in subsequent fix: 825020c3866e]
Signed-off-by: Oleg Nesterov <email address hidden>
Signed-off-by: Linus Torvalds <email address hidden>
Signed-off-by: Chris Wright <email address hidden>
Signed-off-by: Greg Kroah-Hartman <email address hidden>

45cbffd... by Paolo 'Blaisorblade' Giarrusso <email address hidden> on 2007-02-15

x86_64: fix 2.6.18 regression - PTRACE_OLDSETOPTIONS should be accepted

Also PTRACE_OLDSETOPTIONS should be accepted, as done by kernel/ptrace.c and
forced by binary compatibility. UML/32bit breaks because of this - since it is wise
enough to use PTRACE_OLDSETOPTIONS to be binary compatible with 2.4 host
kernels.

Until 2.6.17 (commit f0f2d6536e3515b5b1b7ae97dc8f176860c8c2ce) we had:

       default:
                return sys_ptrace(request, pid, addr, data);

Instead here we have:
        case PTRACE_GET_THREAD_AREA:
 case ...:
                return sys_ptrace(request, pid, addr, data);

        default:
                return -EINVAL;

This change was a style change - when a case is added, it must be explicitly
tested this way. In this case, not enough testing was done.

Cc: Andi Kleen <email address hidden>
Signed-off-by: Paolo 'Blaisorblade' Giarrusso <email address hidden>
Signed-off-by: Greg Kroah-Hartman <email address hidden>

6a6a029... by Oleg Nesterov <email address hidden> on 2007-01-23

V4L: buf_qbuf: fix videobuf_queue->stream corruption and lockup

We are doing ->buf_prepare(buf) before adding buf to q->stream list. This
means that videobuf_qbuf() should not try to re-add a STATE_PREPARED buffer.

(cherry picked from commit 419dd8378dfa32985672ab7927b4bc827f33b332)

Signed-off-by: Oleg Nesterov <email address hidden>
Signed-off-by: Mauro Carvalho Chehab <email address hidden>
Signed-off-by: Michael Krufky <email address hidden>
Signed-off-by: Greg Kroah-Hartman <email address hidden>

0761fce... by Michael Krufky on 2007-01-12

V4L: tveeprom: autodetect LG TAPC G701D as tuner type 37

Autodetect LG TAPC G701D as tuner type 37, fixing
mis-detected tuners in some Hauppauge tv tuner cards.

Thanks to Adonis Papas, for pointing this out.

(cherry picked from commit 1323fbda1343f50f198bc8bd6d1d59c8b7fc45bf)

Signed-off-by: Michael Krufky <email address hidden>
Signed-off-by: Mauro Carvalho Chehab <email address hidden>
Signed-off-by: Greg Kroah-Hartman <email address hidden>