[libata] resync with kernel 2.6.13

Minor update, no major changes/fixes.

ahci: add MODULE_VERSION()
ata_piix: disable AHCI if active
sata_sx4: fix DMA length setting bug
bump libata/driver versions where appropriate
[libata sata_sx4] trim trailing whitespace

Preparation for resync with 2.6.14.
[libata] resync with 2.6.14

* Change license from OSL+GPL to GPL
* Minor additions for new hardware support
* Minor bug fixes
* __iomem markers
* EH locking cleanup (note, causes bug, which will be fixed in later cset)
* use generic pci_intx()
* use pci_iomap(), pci_iounmap()
* ata_piix: fix probe
* 'atapi_enabled' module option, replaces #define
* PIO data xfer fixes
* ATAPI interrupt handling fixes
* support START STOP UNIT scsi command
* scsi READ/WRITE translation edge case fixes
* sata_sil: go faster, on controllers without mod15write support
[libata] resync with 2.6.15-rc3

* ->host_stop() cleanups
* remove ata_chk_err(), ->chk_err()
* many ATAPI fixes
* error handling fixes
* use stub pci_set_consistent_dma_mask(), for easier sync with 2.6.x
* use pdev_printk() for easier sync with 2.6.x dev_printk()
* PATA updates (unused for now)
* PIO updates
* ATA passthru support
* new PCI IDs
[libata] fix build
[libata] fix potential oops in pdev_printk() compat helper
[PATCH] IPv6: small fix for ip6_mc_msfilter

Multicast source filters aren't widely used yet, and that's really
the only feature that's affected if an application actually exercises
this bug, as far as I can tell. An ordinary filter-less multicast join
should still work, and only forwarded multicast traffic making use of
filters and doing empty-source filters with the MSFILTER ioctl would
be at risk of not getting multicast traffic forwarded to them because
the reports generated would not be based on the correct counts.
Initial 2.6 patch by Yan Zheng, bug explanation by David Stevens,
patch ACKed by David.

Signed-off-by: Willy Tarreau <willy@w.ods.org>
[PATCH] Fix ptrace self-attach rule (2.6 backport)

Patch-mainline: v2.6.14.2
Acked-by: Karsten Keil <kkeil@suse.de>
X-Git-Url: http://www.kernel.org/git/?p=linux/kernel/git/gregkh/linux-2.6.14.y.git;a=commitdiff;h=082d52c56f642d21b771a13221068d40915a1409

  [PATCH] Fix ptrace self-attach rule

  Before we did CLONE_THREAD, the way to check whether we were attaching
  to ourselves was to just check "current == task", but with CLONE_THREAD
  we should check that the thread group ID matches instead.

  Signed-off-by: Linus Torvalds <torvalds@osdl.org>
[PATCH] dcache: avoid race when updating nr_unused count of unused dentries

 ChangeSet
   2004/05/29 10:58:56-07:00 akpm@osdl.org
   [PATCH] fs/dcache.c: avoid race when updating nr_unused count of unused dentries.

   From: NeilBrown <neilb@cse.unsw.edu.au>

   d_count == 1 is no guarantee that dentry is on the dentry_unused list, even
   if it has just been incremented inside dcache_lock, as dput can decrement
   at any time.

   This test from Greg Banks is much safer, and is more transparently correct.

   Cc: Maneesh Soni <maneesh@in.ibm.com>, Dipankar Sarma <dipankar@in.ibm.com>
   From: Greg Banks <gnb@melbourne.sgi.com>
   Signed-off-by: Neil Brown <neilb@cse.unsw.edu.au>
   Signed-off-by: Andrew Morton <akpm@osdl.org>
   Signed-off-by: Linus Torvalds <torvalds@osdl.org>
[PATCH] MTD: kernel stuck in tight loop occasionally on flash access

We are running a Timesys modified version of the 2.4 kernel.
Occasionally we see board lockups on heavy file system and direct MTD
flash accesses. I have traced this down to a bug in the 2.4 MTD code
(chip driver to be specific) and see this problem even in the latest 2.4
kernel (2.4.32). I realize that this problem may not be seen by others
using the stock kernel, but I think it needs to be fixed anyway for
correctness.

The problem is in cfi_cmdset_0001.c, and is present in drivers for other
chips as well. In the function cfi_intelext_sync() function before
calling schedule(), the current process needs to be put to sleep by
calling set_current_state(TASK_UNINTERRUPTIBLE). If it is not put to
sleep, the task remains in the run queue of the kernel and if its
priority is high enough, the kernel will constantly keep scheduling this
process, the state of the chip will never change.

Adding this one line seems to make our lockups go away. There were
questions raised as to why TASK_UNINTERRUPTIBLE. The same driver uses
TASK_UNINTERRUPTIBLE in other similar places while waiting for hardware
to complete erasing etc. I chose the same thing.

I am not subscribed to the mailing list, so please CC me on any replies.

Signed-off-by: Vijay Sampath <vijay.sampath@aktino.com>
[PATCH] local denial-of-service with file lease

    [PATCH] VFS: local denial-of-service with file leases

    Remove time_out_leases() printk that's easily triggered by users.

    Signed-off-by: Chris Wright <chrisw@osdl.org>
    Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>

    Above is the signoff information for
    f3a9388e4ebea57583272007311fffa26ebbb305 included in Linus's 2.6 tree.
    As this is CVE-2005-3857 I am proposing its inclusion in 2.4

    Signed-off-by: Horms <horms@verge.net.au>
[PATCH] Fix SATA update KM_IRQ issue with highmem

On Tue, Dec 13, 2005 at 12:04:51AM -0500, Jeff Garzik wrote:
> Best place to add compat defines/enums such as the proposed is
> include/linux/libata-compat.h.

This seems fair to me, particularly since it does not exist in 2.6. I've
checked that there does not seem to exist any file included after it which
need to know about kmap types (even on ia64), so it should be safe to
redefine KM_IRQ0 in libata-compat.h.
[PATCH] usb: ehci in 2.4 with async_unlink

This is a long-standing problem. I had people hitting it from time to time,
but they would always go under instead of testing and reporting. Now one
gentleman reports stepping on this bug under simpler to reproduce conditions
than before. In his case, I/O stops when two DVD drives are connected
to the same bus.

I would like this to be in a test release after 2.4.32.

-- Pete
[PATCH] x86-64: user code panics kernel in exec.c (CVE-2005-2708)

There seems to be a local DoS in exec on AMD64 / linux 2.4
when the system is under memory pressure.

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=161925

Comment #9 From Dave Anderson  	 on 2005-08-31 14:36 EST

I don't particularly care for either patch suggestion. The problem is
that load_elf_binary() -- which is trying to load a legitimate ELF
binary, is returning -ENOEXEC back to search_binary_handler() because
load_elf_interp() has returned a BAD_ADDR:

        if (elf_interpreter) {
                if (interpreter_type == INTERPRETER_AOUT)
                        elf_entry = load_aout_interp(&interp_ex,
                                                     interpreter);
                else
                        elf_entry = load_elf_interp(&interp_elf_ex,
                                                    interpreter,
                                                    &interp_load_addr);

                if (BAD_ADDR(elf_entry)) {
                        printk(KERN_ERR "Unable to load interpreter\n");
                        send_sig(SIGSEGV, current, 0);
                        retval = -ENOEXEC; /* Nobody gets to see this, but.. */
                        goto out_free_dentry;
                }
                reloc_func_desc = interp_load_addr;

                allow_write_access(interpreter);
                fput(interpreter);
                kfree(elf_interpreter);
        }

and *because* search_binary_handler() sees the -ENOEXEC, it kicks off
the attempt to load the bogus module. And therein lies the problem, for
whatever reason, the modprobe process results in the double-fault, and
the original exec operation continues, and fails as it should. But that
all may be a red herring, since ENOEXEC with respect to execve means:

      ENOEXEC An  executable  is  not in a recognised format, is for the wrong
              architecture, or has some other format error that means it  can-
              not be executed.

However in this case, that's not at all true. It's legitimate, but the
attempt to load the /lib64/ld-linux-x86-64.so.2 interpreter into the
limited address space fails, and load_elf_interp() returns -ENOMEM. But
the ENOMEM is "lost" in the elf_entry variable. However, if -ENOMEM is
in fact returned back to search_binary_handler(), it all works just
fine. ENOMEM with respect to execve means:

       ENOMEM Insufficient kernel memory was available.

which isn't *exactly* what's going on here, but pretty close...

There's also the question of why the modprobe is failing, given that the
bogus module name doesn't exist. You would think that shouldn't cause
the kernel to double-fault. I mean do *all* of the request_module()
calls in the kernel require that the target module pre-exist? Since the
kernel seems to handle it differently/successfully on at least i386
and ia64, I haven't determined whether the request_module() is even
attempted on those architectures, or whether the operation fails in a
different code path.
[PATCH] fs/smbfs/proc.c: fix data corruption in smb_proc_setattr_unix()

This patch fixes a data corruption in smb_proc_setattr_unix().

smb_filetype_from_mode() returns an u32, and there are only four bytes
reserved for it in data.

Signed-off-by: Adrian Bunk <bunk@stusta.de>