Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
Commits on Nov 5, 2007
  1. @gregkh

    Linux 2.6.22.12

    gregkh authored
  2. @torvalds @gregkh

    Revert "x86_64: allocate sparsemem memmap above 4G"

    torvalds authored gregkh committed
    patch 6a22c57 in mainline.
    
    This reverts commit 2e1c49d.
    
    First off, testing in Fedora has shown it to cause boot failures,
    bisected down by Martin Ebourne, and reported by Dave Jobes.  So the
    commit will likely be reverted in the 2.6.23 stable kernels.
    
    Secondly, in the 2.6.24 model, x86-64 has now grown support for
    SPARSEMEM_VMEMMAP, which disables the relevant code anyway, so while the
    bug is not visible any more, it's become invisible due to the code just
    being irrelevant and no longer enabled on the only architecture that
    this ever affected.
    
    backported to 2.6.22 by Chuck Ebbert
    
    Reported-by: Dave Jones <davej@redhat.com>
    Tested-by: Martin Ebourne <fedora@ebourne.me.uk>
    Cc: Zou Nan hai <nanhai.zou@intel.com>
    Cc: Suresh Siddha <suresh.b.siddha@intel.com>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Acked-by: Andy Whitcroft <apw@shadowen.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Chuck Ebbert <cebbert@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  3. @gregkh

    dm snapshot: fix invalidation deadlock

    Milan Broz authored gregkh committed
    patch fcac03a in mainline
    
    Process persistent exception store metadata IOs in a separate thread.
    
    A snapshot may become invalid while inside generic_make_request().
    A synchronous write is then needed to update the metadata while still
    inside that function.  Since the introduction of
    md-dm-reduce-stack-usage-with-stacked-block-devices.patch this has to
    be performed by a separate thread to avoid deadlock.
    
    Signed-off-by: Milan Broz <mbroz@redhat.com>
    Signed-off-by: Alasdair G Kergon <agk@redhat.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Chuck Ebbert <cebbert@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  4. @gregkh

    x86: fix global_flush_tlb() bug

    Ingo Molnar authored gregkh committed
    patch 9a24d04 upstream
    
    While we were reviewing pageattr_32/64.c for unification,
    Thomas Gleixner noticed the following serious SMP bug in
    global_flush_tlb():
    
    	down_read(&init_mm.mmap_sem);
    	list_replace_init(&deferred_pages, &l);
    	up_read(&init_mm.mmap_sem);
    
    this is SMP-unsafe because list_replace_init() done on two CPUs in
    parallel can corrupt the list.
    
    This bug has been introduced about a year ago in the 64-bit tree:
    
           commit ea7322d
           Author: Andi Kleen <ak@suse.de>
           Date:   Thu Dec 7 02:14:05 2006 +0100
    
           [PATCH] x86-64: Speed and clean up cache flushing in change_page_attr
    
                    down_read(&init_mm.mmap_sem);
            -       dpage = xchg(&deferred_pages, NULL);
            +       list_replace_init(&deferred_pages, &l);
                    up_read(&init_mm.mmap_sem);
    
    the xchg() based version was SMP-safe, but list_replace_init() is not.
    So this "cleanup" introduced a nasty bug.
    
    why this bug never become prominent is a mystery - it can probably be
    explained with the (still) relative obscurity of the x86_64 architecture.
    
    the safe fix for now is to write-lock init_mm.mmap_sem.
    
    Signed-off-by: Ingo Molnar <mingo@elte.hu>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Cc: Andi Kleen <ak@suse.de>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  5. @hidave @gregkh

    param_sysfs_builtin memchr argument fix

    hidave authored gregkh committed
    patch faf8c71 in mainline.
    
    If memchr argument is longer than strlen(kp->name), there will be some
    weird result.
    
    It will casuse duplicate filenames in sysfs for the "nousb".  kernel
    warning messages are as bellow:
    
    sysfs: duplicate filename 'usbcore' can not be created
    WARNING: at fs/sysfs/dir.c:416 sysfs_add_one()
     [<c01c4750>] sysfs_add_one+0xa0/0xe0
     [<c01c4ab8>] create_dir+0x48/0xb0
     [<c01c4b69>] sysfs_create_dir+0x29/0x50
     [<c024e0fb>] create_dir+0x1b/0x50
     [<c024e3b6>] kobject_add+0x46/0x150
     [<c024e2da>] kobject_init+0x3a/0x80
     [<c053b880>] kernel_param_sysfs_setup+0x50/0xb0
     [<c053b9ce>] param_sysfs_builtin+0xee/0x130
     [<c053ba33>] param_sysfs_init+0x23/0x60
     [<c024d062>] __next_cpu+0x12/0x20
     [<c052aa30>] kernel_init+0x0/0xb0
     [<c052aa30>] kernel_init+0x0/0xb0
     [<c052a856>] do_initcalls+0x46/0x1e0
     [<c01bdb12>] create_proc_entry+0x52/0x90
     [<c0158d4c>] register_irq_proc+0x9c/0xc0
     [<c01bda94>] proc_mkdir_mode+0x34/0x50
     [<c052aa30>] kernel_init+0x0/0xb0
     [<c052aa92>] kernel_init+0x62/0xb0
     [<c0104f83>] kernel_thread_helper+0x7/0x14
     =======================
    kobject_add failed for usbcore with -EEXIST, don't try to register things with the same name in the same directory.
     [<c024e466>] kobject_add+0xf6/0x150
     [<c053b880>] kernel_param_sysfs_setup+0x50/0xb0
     [<c053b9ce>] param_sysfs_builtin+0xee/0x130
     [<c053ba33>] param_sysfs_init+0x23/0x60
     [<c024d062>] __next_cpu+0x12/0x20
     [<c052aa30>] kernel_init+0x0/0xb0
     [<c052aa30>] kernel_init+0x0/0xb0
     [<c052a856>] do_initcalls+0x46/0x1e0
     [<c01bdb12>] create_proc_entry+0x52/0x90
     [<c0158d4c>] register_irq_proc+0x9c/0xc0
     [<c01bda94>] proc_mkdir_mode+0x34/0x50
     [<c052aa30>] kernel_init+0x0/0xb0
     [<c052aa92>] kernel_init+0x62/0xb0
     [<c0104f83>] kernel_thread_helper+0x7/0x14
     =======================
    Module 'usbcore' failed to be added to sysfs, error number -17
    The system will be unstable now.
    
    Signed-off-by: Dave Young <hidave.darkstar@gmail.com>
    Cc: Greg KH <greg@kroah.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Chuck Ebbert <cebbert@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  6. @gregkh

    minixfs: limit minixfs printks on corrupted dir i_size (CVE-2006-6058)

    Eric Sandeen authored gregkh committed
    patch 44ec6f3f89889a469773b1fd894f8fcc07c29cf in mainline
    
    This attempts to address CVE-2006-6058
    http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6058
    
    first reported at http://projects.info-pull.com/mokb/MOKB-17-11-2006.html
    
    Essentially a corrupted minix dir inode reporting a very large
    i_size will loop for a very long time in minix_readdir, minix_find_entry,
    etc, because on EIO they just move on to try the next page.  This is
    under the BKL, printk-storming as well.  This can lock up the machine
    for a very long time.  Simply ratelimiting the printks gets things back
    under control.  Make the message a bit more informative while we're here.
    
    Signed-off-by: Eric Sandeen <sandeen@redhat.com>
    Cc: Bodo Eggert <7eggert@gmx.de>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  7. @gregkh

    IB/uverbs: Fix checking of userspace object ownership

    Roland Dreier authored gregkh committed
    Upstream as cbfb50e
    
    Commit 9ead190 ("IB/uverbs: Don't serialize with ib_uverbs_idr_mutex")
    rewrote how userspace objects are looked up in the uverbs module's
    idrs, and introduced a severe bug in the process: there is no checking
    that an operation is being performed by the right process any more.
    Fix this by adding the missing check of uobj->context in __idr_get_uobj().
    
    Apparently everyone is being very careful to only touch their own
    objects, because this bug was introduced in June 2006 in 2.6.18, and
    has gone undetected until now.
    
    Signed-off-by: Roland Dreier <rolandd@cisco.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  8. @gregkh

    genirq: mark io_apic level interrupts to avoid resend

    Thomas Gleixner authored gregkh committed
    patch cc75b92 in mainline.
    
    Level type interrupts do not need to be resent.  It was also found that
    some chipsets get confused in case of the resend.
    
    Mark the ioapic level type interrupts as such to avoid the resend
    functionality in the generic irq code.
    
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Chuck Ebbert <cebbert@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  9. @gregkh

    genirq: suppress resend of level interrupts

    Thomas Gleixner authored gregkh committed
    patch 2464286 in mainline.
    
    Level type interrupts are resent by the interrupt hardware when they are
    still active at irq_enable().
    
    Suppress the resend mechanism for interrupts marked as level.
    
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Chuck Ebbert <cebbert@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  10. @gregkh

    genirq: cleanup mismerge artifact

    Thomas Gleixner authored gregkh committed
    patch 4966342 in mainline.
    
    Commit 5a43a06: "genirq: Allow fasteoi
    handler to retrigger disabled interrupts" was erroneously applied to
    handle_level_irq().  This added the irq retrigger / resend functionality
    to the level irq handler.
    
    Revert the offending bits.
    
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Chuck Ebbert <cebbert@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Commits on Nov 2, 2007
  1. @gregkh

    Linux 2.6.22.11

    gregkh authored
  2. @gregkh

    lockdep: fix mismatched lockdep_depth/curr_chain_hash

    Gregory Haskins authored gregkh committed
    patch 3aa416b in mainline.
    
    lockdep: fix mismatched lockdep_depth/curr_chain_hash
    
    It is possible for the current->curr_chain_key to become inconsistent with the
    current index if the chain fails to validate.  The end result is that future
    lock_acquire() operations may inadvertently fail to find a hit in the cache
    resulting in a new node being added to the graph for every acquire.
    
    [ peterz: this might explain some of the lockdep is so _slow_ complaints. ]
    [ mingo: this does not impact the correctness of validation, but may slow
      down future operations significantly, if the chain gets very long. ]
    
    Signed-off-by: Gregory Haskins <ghaskins@novell.com>
    Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
    Signed-off-by: Ingo Molnar <mingo@elte.hu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  3. @kumargala @gregkh

    POWERPC: Fix handling of stfiwx math emulation

    kumargala authored gregkh committed
    patch ba02946 in mainline
    
    Its legal for the stfiwx instruction to have RA = 0 as part of its
    effective address calculation.  This is illegal for all other XE
    form instructions.
    
    Add code to compute the proper effective address for stfiwx if
    RA = 0 rather than treating it as illegal.
    
    Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  4. @gregkh

    i915: fix vbl swap allocation size.

    Dave Airlie authored gregkh committed
    This is upstream as 54583bf
    
    Oops...
    
    Signed-off-by: Dave Airlie <airlied@linux.ie>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  5. @gregkh

    hwmon/w83627hf: Don't assume bank 0

    Jean Delvare authored gregkh committed
    Already in Linus' tree:
    http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=d58df9cd788e6fb4962e1c8d5ba7b8b95d639a44
    
    The bank switching code assumes that the bank selector is set to 0
    when the driver is loaded. This might not be the case. This is exactly
    the same bug as was fixed in the w83627ehf driver two months ago:
    http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=0956895aa6f8dc6a33210967252fd7787652537d
    
    In practice, this bug was causing the sensor thermal types to be
    improperly reported for my W83627THF the first time I was loading the
    w83627hf driver. From the driver history, I'd say that it has been
    broken since September 2005 (when we stopped resetting the chip by
    default at driver load.)
    
    Signed-off-by: Jean Delvare <khali@linux-fr.org>
    Signed-off-by: Mark M. Hoffman <mhoffman@lightlink.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  6. @gregkh

    hwmon/w83627hf: Fix setting fan min right after driver load

    Jean Delvare authored gregkh committed
    Already in Linus' tree:
    http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=c09c5184a26158da32801e89d5849d774605f0dd
    
    We need to read the fan clock dividers at initialization time,
    otherwise the code in store_fan_min() may use uninitialized values.
    That's pretty much the same bug and same fix as for the w83627ehf
    driver last month.
    
    Signed-off-by: Jean Delvare <khali@linux-fr.org>
    Signed-off-by: Mark M. Hoffman <mhoffman@lightlink.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  7. @gregkh

    hwmon/lm87: Disable VID when it should be

    Jean Delvare authored gregkh committed
    Already in Linus' tree:
    http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=889af3d5d9586db795a06c619e416b4baee11da8
    
    A stupid bit shifting bug caused the VID value to be always exported
    even when the hardware is configured for something different.
    
    Signed-off-by: Jean Delvare <khali@linux-fr.org>
    Signed-off-by: Mark M. Hoffman <mhoffman@lightlink.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  8. @gregkh

    hwmon/lm87: Fix a division by zero

    Jean Delvare authored gregkh committed
    Already in Linus' tree:
    http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=b965d4b7f614522170af6a7e450be0333792ccd2
    
    Missing parentheses in the definition of FAN_FROM_REG cause a
    division by zero for a specific register value.
    
    Signed-off-by: Jean Delvare <khali@linux-fr.org>
    Acked-by: Hans de Goede <j.w.r.degoede@hhs.nl>
    Signed-off-by: Mark M. Hoffman <mhoffman@lightlink.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  9. @gregkh

    V4L: ivtv: fix udma yuv bug

    Ian Armstrong authored gregkh committed
    Based on cb50f54 in mainline
    
    [PATCH] V4L: ivtv: fix udma yuv bug
    
    Using udma yuv causes the driver to become locked into that mode. This
    prevents use of the mpeg decoder & non-udma yuv output.
    
    This patch clears the operating mode when the device is closed.
    
    Signed-off-by: Ian Armstrong <ian@iarmst.demon.co.uk>
    Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
    Signed-off-by: Michael Krufky <mkrufky@linuxtv.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  10. @gregkh

    dm9601: Fix receive MTU

    Peter Korsgaard authored gregkh committed
    patch f662fe5 in mainline.
    
    dm9601: Fix receive MTU
    
    dm9601 didn't take the ethernet header into account when calculating
    RX MTU, causing packets bigger than 1486 to fail.
    
    Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
    Signed-off-by: Jeff Garzik <jeff@garzik.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  11. @gregkh

    netdrvr: natsemi: Fix device removal bug

    Jeff Garzik authored gregkh committed
    This episode illustrates how an overused warning can train people to
    ignore that warning, which winds up hiding bugs.
    
    The warning
    
    drivers/net/natsemi.c: In function ‘natsemi_remove1’:
    drivers/net/natsemi.c:3222: warning: ignoring return value of
    ‘device_create_file’, declared with attribute warn_unused_result
    
    is oft-ignored, even though at close inspection one notices this occurs
    in the /remove/ function, not normally where creation occurs.  A quick
    s/create/remove/ and we are fixed, with the warning gone.
    
    Signed-off-by: Jeff Garzik <jeff@garzik.org>
    Cc: Karsten Keil <kkeil@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  12. @gregkh

    firewire: fix unloading of fw-ohci while devices are attached

    Stefan Richter authored gregkh committed
    Fix panic in run_timer_softirq right after "modprobe -r firewire-ohci"
    if a FireWire disk was attached and firewire-sbp2 loaded.
    
    Same as commit 8a2d9ed.
    
    Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  13. @warmcat @gregkh

    Add get_unaligned to ieee80211_get_radiotap_len

    warmcat authored gregkh committed
    patch dfe6e81 in mainline.
    
    ieee80211_get_radiotap_len() tries to dereference radiotap length without
    taking care that it is completely unaligned and get_unaligned()
    is required.
    
    Signed-off-by: Andy Green <andy@warmcat.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  14. @gregkh

    libertas: more endianness breakage

    Al Viro authored gregkh committed
    based on patch 8362cd4 in mainline.
    
    	domain->header.len is le16 and has just been assigned
    cpu_to_le16(arithmetical expression).  And all fields of adapter->logmsg
    are __le32; not a single 16-bit among them...
    	That's incremental to the previous one
    
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Dan Williams <dcbw@redhat.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  15. @gregkh

    libertas: fix endianness breakage

    Al Viro authored gregkh committed
    patch 5707708 in mainline.
    
    	wep->keytype[] is u8
    
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Dan Williams <dcbw@redhat.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
  16. @linvjw @gregkh

    mac80211: filter locally-originated multicast frames

    linvjw authored gregkh committed
    patch b331615 in mainline.
    
    In STA mode, the AP will echo our traffic.  This includes multicast
    traffic.
    
    Receiving these frames confuses some protocols and applications,
    notably IPv6 Duplicate Address Detection.
    
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
    Acked-by: Michael Wu <flamingice@sourmilk.net>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  17. @gregkh

    Fix TCP initial sequence number selection.

    Eric Dumazet authored gregkh committed
    changeset 162f6690a65075b49f242d3c8cdb5caaa959a060 in mainline.
    
    TCP V4 sequence numbers are 32bits, and RFC 793 assumed a 250 KHz clock.
    In order to follow network speed increase, we can use a faster clock, but
    we should limit this clock so that the delay between two rollovers is
    greater than MSL (TCP Maximum Segment Lifetime : 2 minutes)
    
    Choosing a 64 nsec clock should be OK, since the rollovers occur every
    274 seconds.
    
    Problem spotted by Denys Fedoryshchenko
    
    [ This bug was introduced by f859581 ]
    
    Signed-off-by: Eric Dumazet <dada1@cosmosbay.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  18. @davem330 @gregkh

    Fix TCP MD5 on big-endian.

    davem330 authored gregkh committed
    changeset f8ab18d in mainline.
    
    Based upon a report and initial patch by Peter Lieven.
    
    tcp4_md5sig_key and tcp6_md5sig_key need to start with
    the exact same members as tcp_md5sig_key.  Because they
    are both cast to that type by tcp_v{4,6}_md5_do_lookup().
    
    Unfortunately tcp{4,6}_md5sig_key use a u16 for the key
    length instead of a u8, which is what tcp_md5sig_key
    uses.  This just so happens to work by accident on
    little-endian, but on big-endian it doesn't.
    
    Instead of casting, just place tcp_md5sig_key as the first member of
    the address-family specific structures, adjust the access sites, and
    kill off the ugly casts.
    
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  19. @gregkh

    Fix TCP's ->fastpath_cnt_hit handling.

    Ilpo Järvinen authored gregkh committed
    changeset 48611c4 in mainline.
    
    When only GSO skb was partially ACKed, no hints are reset,
    therefore fastpath_cnt_hint must be tweaked too or else it can
    corrupt fackets_out. The corruption to occur, one must have
    non-trivial ACK/SACK sequence, so this bug is not very often
    that harmful. There's a fackets_out state reset in TCP because
    fackets_out is known to be inaccurate and that fixes the issue
    eventually anyway.
    
    In case there was also at least one skb that got fully ACKed,
    the fastpath_skb_hint is set to NULL which causes a recount for
    fastpath_cnt_hint (the old value won't be accessed anymore),
    thus it can safely be decremented without additional checking.
    
    Reported by Cedric Le Goater <clg@fr.ibm.com>
    
    Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  20. @davem330 @gregkh

    Fix sys_ipc() SEMCTL on sparc64.

    davem330 authored gregkh committed
    changeset 6536a6b331d3225921c398eb7c6e4ecedb9b05e0 from mainline
    
    Thanks to Tom Callaway for the excellent bug report and
    test case.
    
    sys_ipc() has several problems, most to due with semaphore
    call handling:
    
    1) 'err' return should be a 'long'
    2) "union semun" is passed in a register on 64-bit compared
       to 32-bit which provides it on the stack and therefore
       by reference
    3) Second and third arguments to SEMCTL are swapped compared
       to 32-bit.
    
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  21. @davem330 @gregkh

    Fix zero length socket write() semantics.

    davem330 authored gregkh committed
    changeset e79ad71 from mainline.
    
    This fixes kernel bugzilla #5731
    
    It should generate an empty packet for datagram protocols when the
    socket is connected, for one.
    
    The check is doubly-wrong because all that a write() can be is a
    sendmsg() call with a NULL msg_control and a single entry iovec.  No
    special semantics should be assigned to it, therefore the zero length
    check should be removed entirely.
    
    This matches the behavior of BSD and several other systems.
    
    Alan Cox notes that SuSv3 says the behavior of a zero length write on
    non-files is "unspecified", but that's kind of useless since BSD has
    defined this behavior for a quarter century and BSD is essentially
    what application folks code to.
    
    Based upon a patch from Stephen Hemminger.
    
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  22. @gregkh

    Fix ROSE module unload oops.

    Alexey Dobriyan authored gregkh committed
    changeset 891e6a9 from mainline.
    
    Commit a3d3840 aka
    "[AX.25]: Fix unchecked rose_add_loopback_neigh uses"
    transformed rose_loopback_neigh var into statically allocated one.
    However, on unload it will be kfree's which can't work.
    
    Steps to reproduce:
    
    	modprobe rose
    	rmmod rose
    
    BUG: unable to handle kernel NULL pointer dereference at virtual address 00000008
     printing eip:
    c014c664
    *pde = 00000000
    Oops: 0000 [#1]
    PREEMPT DEBUG_PAGEALLOC
    Modules linked in: rose ax25 fan ufs loop usbhid rtc snd_intel8x0 snd_ac97_codec ehci_hcd ac97_bus uhci_hcd thermal usbcore button processor evdev sr_mod cdrom
    CPU:    0
    EIP:    0060:[<c014c664>]    Not tainted VLI
    EFLAGS: 00210086   (2.6.23-rc9 #3)
    EIP is at kfree+0x48/0xa1
    eax: 00000556   ebx: c1734aa0   ecx: f6a5e000   edx: f7082000
    esi: 00000000   edi: f9a55d20   ebp: 00200287   esp: f6a5ef28
    ds: 007b   es: 007b   fs: 0000  gs: 0033  ss: 0068
    Process rmmod (pid: 1823, ti=f6a5e000 task=f7082000 task.ti=f6a5e000)
    Stack: f9a55d20 f9a5200c 00000000 00000000 00000000 f6a5e000 f9a5200c f9a55a00
           00000000 bf818cf0 f9a51f3f f9a55a00 00000000 c0132c60 65736f72 00000000
           f69f9630 f69f9528 c014244a f6a4e900 00200246 f7082000 c01025e6 00000000
    Call Trace:
     [<f9a5200c>] rose_rt_free+0x1d/0x49 [rose]
     [<f9a5200c>] rose_rt_free+0x1d/0x49 [rose]
     [<f9a51f3f>] rose_exit+0x4c/0xd5 [rose]
     [<c0132c60>] sys_delete_module+0x15e/0x186
     [<c014244a>] remove_vma+0x40/0x45
     [<c01025e6>] sysenter_past_esp+0x8f/0x99
     [<c012bacf>] trace_hardirqs_on+0x118/0x13b
     [<c01025b6>] sysenter_past_esp+0x5f/0x99
     =======================
    Code: 05 03 1d 80 db 5b c0 8b 03 25 00 40 02 00 3d 00 40 02 00 75 03 8b 5b 0c 8b 73 10 8b 44 24 18 89 44 24 04 9c 5d fa e8 77 df fd ff <8b> 56 08 89 f8 e8 84 f4 fd ff e8 bd 32 06 00 3b 5c 86 60 75 0f
    EIP: [<c014c664>] kfree+0x48/0xa1 SS:ESP 0068:f6a5ef28
    
    Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  23. @brianphaley @gregkh

    Fix ipv6 redirect processing, leads to TAHI failures.

    brianphaley authored gregkh committed
    changeset bf0b48d from mainline.
    
    When the ICMPv6 Target address is multicast, Linux processes the
    redirect instead of dropping it.  The problem is in this code in
    ndisc_redirect_rcv():
    
             if (ipv6_addr_equal(dest, target)) {
                     on_link = 1;
             } else if (!(ipv6_addr_type(target) & IPV6_ADDR_LINKLOCAL)) {
                     ND_PRINTK2(KERN_WARNING
                                "ICMPv6 Redirect: target address is not
    link-local.\n");
                     return;
             }
    
    This second check will succeed if the Target address is, for example,
    FF02::1 because it has link-local scope.  Instead, it should be checking
    if it's a unicast link-local address, as stated in RFC 2461/4861 Section
    8.1:
    
           - The ICMP Target Address is either a link-local address (when
             redirected to a router) or the same as the ICMP Destination
             Address (when redirected to the on-link destination).
    
    I know this doesn't explicitly say unicast link-local address, but it's
    implied.
    
    This bug is preventing Linux kernels from achieving IPv6 Logo Phase II
    certification because of a recent error that was found in the TAHI test
    suite - Neighbor Disovery suite test 206 (v6LC.2.3.6_G) had the
    multicast address in the Destination field instead of Target field, so
    we were passing the test.  This won't be the case anymore.
    
    The patch below fixes this problem, and also fixes ndisc_send_redirect()
    to not send an invalid redirect with a multicast address in the Target
    field.  I re-ran the TAHI Neighbor Discovery section to make sure Linux
    passes all 245 tests now.
    
    Signed-off-by: Brian Haley <brian.haley@hp.com>
    Acked-by: David L Stevens <dlstevens@us.ibm.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  24. @gregkh

    Fix some cases of missed IPV6 DAD

    Mitsuru Chinen authored gregkh committed
    changeset 0fcace22d38ce9216f5ba52f929a99d284aa7e49 from mainline
    
    To judge the timing for DAD, netif_carrier_ok() is used. However,
    there is a possibility that dev->qdisc stays noop_qdisc even if
    netif_carrier_ok() returns true. In that case, DAD NS is not sent out.
    We need to defer the IPv6 device initialization until a valid qdisc
    is specified.
    
    Signed-off-by: Mitsuru Chinen <mitch@linux.vnet.ibm.com>
    Signed-off-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  25. @linvjw @gregkh

    Fix ieee80211 handling of bogus hdrlength field

    linvjw authored gregkh committed
    changeset 04045f9 from mainline
    
    Reported by Chris Evans <scarybeasts@gmail.com>:
    
    > The summary is that an evil 80211 frame can crash out a victim's
    > machine. It only applies to drivers using the 80211 wireless code, and
    > only then to certain drivers (and even then depends on a card's
    > firmware not dropping a dubious packet). I must confess I'm not
    > keeping track of Linux wireless support, and the different protocol
    > stacks etc.
    >
    > Details are as follows:
    >
    > ieee80211_rx() does not explicitly check that "skb->len >= hdrlen".
    > There are other skb->len checks, but not enough to prevent a subtle
    > off-by-two error if the frame has the IEEE80211_STYPE_QOS_DATA flag
    > set.
    >
    > This leads to integer underflow and crash here:
    >
    > if (frag != 0)
    >    flen -= hdrlen;
    >
    > (flen is subsequently used as a memcpy length parameter).
    
    How about this?
    
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Something went wrong with that request. Please try again.