Permalink
Commits on Mar 17, 2012
  1. Linux 2.6.27.62

    Signed-off-by: Willy Tarreau <w@1wt.eu>
    Willy Tarreau committed Mar 17, 2012
  2. cdrom: use copy_to_user() without the underscores

    commit 822bfa5 upstream.
    
    "nframes" comes from the user and "nframes * CD_FRAMESIZE_RAW" can wrap
    on 32 bit systems.  That would have been ok if we used the same wrapped
    value for the copy, but we use a shifted value.  We should just use the
    checked version of copy_to_user() because it's not going to make a
    difference to the speed.
    
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Willy Tarreau <w@1wt.eu>
    Dan Carpenter committed with Willy Tarreau Feb 6, 2012
  3. relay: prevent integer overflow in relay_open()

    commit f6302f1 upstream.
    
    "subbuf_size" and "n_subbufs" come from the user and they need to be
    capped to prevent an integer overflow.
    
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Willy Tarreau <w@1wt.eu>
    Dan Carpenter committed with Willy Tarreau Feb 10, 2012
  4. @fengguang

    lib: proportion: lower PROP_MAX_SHIFT to 32 on 64-bit kernel

    commit 3310225 upstream.
    
    PROP_MAX_SHIFT should be set to <=32 on 64-bit box. This fixes two bugs
    in the below lines of bdi_dirty_limit():
    
    	bdi_dirty *= numerator;
    	do_div(bdi_dirty, denominator);
    
    1) divide error: do_div() only uses the lower 32 bit of the denominator,
       which may trimmed to be 0 when PROP_MAX_SHIFT > 32.
    
    2) overflow: (bdi_dirty * numerator) could easily overflow if numerator
       used up to 48 bits, leaving only 16 bits to bdi_dirty
    
    Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
    Reported-by: Ilya Tumaykin <librarian_rus@yahoo.com>
    Tested-by: Ilya Tumaykin <librarian_rus@yahoo.com>
    Signed-off-by: Wu Fengguang <fengguang.wu@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Willy Tarreau <w@1wt.eu>
    fengguang committed with Willy Tarreau Jan 9, 2012
  5. @hfeurstein

    atmel_lcdfb: fix usage of CONTRAST_CTR in suspend/resume

    commit 9f10650 upstream.
    
    An error was existing in the saving of CONTRAST_CTR register
    across suspend/resume.
    
    Signed-off-by: Hubert Feurstein <h.feurstein@gmail.com>
    Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
    Acked-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
    Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Willy Tarreau <w@1wt.eu>
    hfeurstein committed with Willy Tarreau Jan 9, 2012
  6. eCryptfs: Clear i_nlink in rmdir

    commit 0785055 upstream.
    
    eCryptfs wasn't clearing the eCryptfs inode's i_nlink after a successful
    vfs_rmdir() on the lower directory. This resulted in the inode evict and
    destroy paths to be missed.
    
    https://bugs.launchpad.net/ecryptfs/+bug/723518
    
    Signed-off-by: Tyler Hicks <tyhicks@linux.vnet.ibm.com>
    Signed-off-by: Colin King <colin.king@canonical.com>
    Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Willy Tarreau <w@1wt.eu>
    Tyler Hicks committed with Willy Tarreau Apr 29, 2011
  7. eCryptfs: Remove extra d_delete in ecryptfs_rmdir

    commit 35ffa94 upstream.
    
    vfs_rmdir() already calls d_delete() on the lower dentry. That was being
    duplicated in ecryptfs_rmdir() and caused a NULL pointer dereference
    when NFSv3 was the lower filesystem.
    
    BugLink: http://bugs.launchpad.net/bugs/723518
    Signed-off-by: Tyler Hicks <tyhicks@linux.vnet.ibm.com>
    Signed-off-by: Colin King <colin.king@canonical.com>
    Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Willy Tarreau <w@1wt.eu>
    Tyler Hicks committed with Willy Tarreau Apr 12, 2011
  8. ecryptfs: read on a directory should return EISDIR if not supported

    commit 323ef68 upstream.
    
    read() calls against a file descriptor connected to a directory are
    incorrectly returning EINVAL rather than EISDIR:
    
      [EISDIR]
        [XSI] [Option Start] The fildes argument refers to a directory and the
        implementation does not allow the directory to be read using read()
        or pread(). The readdir() function should be used instead. [Option End]
    
    This occurs because we do not have a .read operation defined for
    ecryptfs directories.  Connect this up to generic_read_dir().
    
    BugLink: http://bugs.launchpad.net/bugs/719691
    Signed-off-by: Andy Whitcroft <apw@canonical.com>
    Signed-off-by: Tyler Hicks <tyhicks@linux.vnet.ibm.com>
    Signed-off-by: Willy Tarreau <w@1wt.eu>
    Andy Whitcroft committed with Willy Tarreau Feb 16, 2011
  9. eCryptfs: Remove mmap from directory operations

    backported from 38e3eae
    
    Adrian reported that mkfontscale didn't work inside of eCryptfs mounts.
    Strace revealed the following:
    
    open("./", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = 3
    fcntl64(3, F_GETFD) = 0x1 (flags FD_CLOEXEC)
    open("./fonts.scale", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 4
    getdents(3, /* 80 entries */, 32768) = 2304
    open("./.", O_RDONLY) = 5
    fcntl64(5, F_SETFD, FD_CLOEXEC) = 0
    fstat64(5, {st_mode=S_IFDIR|0755, st_size=16384, ...}) = 0
    mmap2(NULL, 16384, PROT_READ, MAP_PRIVATE, 5, 0) = 0xb7fcf000
    close(5) = 0
     --- SIGBUS (Bus error) @ 0 (0) ---
     +++ killed by SIGBUS +++
    
    The mmap2() on a directory was successful, resulting in a SIGBUS
    signal later.  This patch removes mmap() from the list of possible
    ecryptfs_dir_fops so that mmap() isn't possible on eCryptfs directory
    files.
    
    http://bugs.launchpad.net/bugs/400443
    
    Reported-by: Adrian C. <anrxc@sysphere.org>
    Signed-off-by: Tyler Hicks <tyhicks@linux.vnet.ibm.com>
    Signed-off-by: Colin Ian King <colin.king@canonical.com>
    Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Willy Tarreau <w@1wt.eu>
    Tyler Hicks committed with Willy Tarreau Feb 15, 2012
  10. eCryptfs: Infinite loop due to overflow in ecryptfs_write()

    commit 684a3ff upstream.
    
    ecryptfs_write() can enter an infinite loop when truncating a file to a
    size larger than 4G. This only happens on architectures where size_t is
    represented by 32 bits.
    
    This was caused by a size_t overflow due to it incorrectly being used to
    store the result of a calculation which uses potentially large values of
    type loff_t.
    
    [tyhicks@canonical.com: rewrite subject and commit message]
    Signed-off-by: Li Wang <liwang@nudt.edu.cn>
    Signed-off-by: Yunchuan Wen <wenyunchuan@kylinos.com.cn>
    Reviewed-by: Cong Wang <xiyou.wangcong@gmail.com>
    Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    
    Signed-off-by: Willy Tarreau <w@1wt.eu>
    Li Wang committed with Willy Tarreau Jan 19, 2012
  11. @jankara

    udf: Mark LVID buffer as uptodate before marking it dirty

    commit 853a0c2 upstream.
    
    When we hit EIO while writing LVID, the buffer uptodate bit is cleared.
    This then results in an anoying warning from mark_buffer_dirty() when we
    write the buffer again. So just set uptodate flag unconditionally.
    
    Reviewed-by: Namjae Jeon <linkinjeon@gmail.com>
    Signed-off-by: Jan Kara <jack@suse.cz>
    Cc: Dave Jones <davej@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Willy Tarreau <w@1wt.eu>
    jankara committed with Willy Tarreau Dec 23, 2011
  12. mm/filemap_xip.c: fix race condition in xip_file_fault()

    commit 99f02ef upstream.
    
    Fix a race condition that shows in conjunction with xip_file_fault() when
    two threads of the same user process fault on the same memory page.
    
    In this case, the race winner will install the page table entry and the
    unlucky loser will cause an oops: xip_file_fault calls vm_insert_pfn (via
    vm_insert_mixed) which drops out at this check:
    
    	retval = -EBUSY;
    	if (!pte_none(*pte))
    		goto out_unlock;
    
    The resulting -EBUSY return value will trigger a BUG_ON() in
    xip_file_fault.
    
    This fix simply considers the fault as fixed in this case, because the
    race winner has successfully installed the pte.
    
    [akpm@linux-foundation.org: use conventional (and consistent) comment layout]
    Reported-by: David Sadler <dsadler@us.ibm.com>
    Signed-off-by: Carsten Otte <cotte@de.ibm.com>
    Reported-by: Louis Alex Eisner <leisner@cs.ucsd.edu>
    Cc: Hugh Dickins <hughd@google.com>
    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@linuxfoundation.org>
    
    Signed-off-by: Willy Tarreau <w@1wt.eu>
    Carsten Otte committed with Willy Tarreau Feb 3, 2012
  13. IB/mlx4: pass SMP vendor-specific attribute MADs to firmware

    commit a6f7fea upstream.
    
    In the current code, vendor-specific MADs (e.g with the FDR-10
    attribute) are silently dropped by the driver, resulting in timeouts
    at the sending side and inability to query/configure the relevant
    feature.  However, the ConnectX firmware is able to handle such MADs.
    For unsupported attributes, the firmware returns a GET_RESPONSE MAD
    containing an error status.
    
    For example, for a FDR-10 node with LID 11:
    
        # ibstat mlx4_0 1
    
        CA: 'mlx4_0'
        Port 1:
        State: Active
        Physical state: LinkUp
        Rate: 40 (FDR10)
        Base lid: 11
        LMC: 0
        SM lid: 24
        Capability mask: 0x02514868
        Port GUID: 0x0002c903002e65d1
        Link layer: InfiniBand
    
    Extended Port Query (EPI) vendor mad timeouts before the patch:
    
        # smpquery MEPI 11 -d
    
        ibwarn: [4196] smp_query_via: attr 0xff90 mod 0x0 route Lid 11
        ibwarn: [4196] _do_madrpc: retry 1 (timeout 1000 ms)
        ibwarn: [4196] _do_madrpc: retry 2 (timeout 1000 ms)
        ibwarn: [4196] _do_madrpc: timeout after 3 retries, 3000 ms
        ibwarn: [4196] mad_rpc: _do_madrpc failed; dport (Lid 11)
        smpquery: iberror: [pid 4196] main: failed: operation EPI: ext port info query failed
    
    EPI query works OK with the patch:
    
        # smpquery MEPI 11 -d
    
        ibwarn: [6548] smp_query_via: attr 0xff90 mod 0x0 route Lid 11
        ibwarn: [6548] mad_rpc: data offs 64 sz 64
        mad data
        0000 0000 0000 0001 0000 0001 0000 0001
        0000 0000 0000 0000 0000 0000 0000 0000
        0000 0000 0000 0000 0000 0000 0000 0000
        0000 0000 0000 0000 0000 0000 0000 0000
        # Ext Port info: Lid 11 port 0
        StateChangeEnable:...............0x00
        LinkSpeedSupported:..............0x01
        LinkSpeedEnabled:................0x01
        LinkSpeedActive:.................0x01
    
    Signed-off-by: Jack Morgenstein <jackm@mellanox.com>
    Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
    Acked-by: Ira Weiny <weiny2@llnl.gov>
    Signed-off-by: Roland Dreier <roland@purestorage.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Willy Tarreau <w@1wt.eu>
    Jack Morgenstein committed with Willy Tarreau Jan 26, 2012
  14. @mikey

    powerpc: Add more Power7 specific definitions

    stable-2.6.27.60 added c24cb8e which uses PV_POWER7 but it's not
    defined.  Following patch adds these definitions.
    
    From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    
    commit 50fb8eb upstream
    
    powerpc: Add more Power7 specific definitions
    
    This adds more SPR definitions used on newer processors when running
    in hypervisor mode. Along with some other P7 specific bits and pieces
    
    Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    Signed-off-by: Michael Neuling <mikey@neuling.org>
    Signed-off-by: Willy Tarreau <w@1wt.eu>
    mikey committed with Willy Tarreau Feb 13, 2012
Commits on Feb 12, 2012
  1. Linux 2.6.27.61

    Willy Tarreau committed Feb 12, 2012
  2. Revert "x86: Make Dell Latitude E5420 use reboot=pci"

    This reverts commit 8b752bf.
    
    Stefan Cososchi reported a build breakage on 32-bit (only worked
    fine on x86_64). It needs a backport of 6c6c51e to work. Revert
    this patch as it's not critical anyway.
    
    Signed-off-by: Willy Tarreau <w@1wt.eu>
    Willy Tarreau committed Feb 12, 2012
Commits on Feb 11, 2012
  1. Linux 2.6.27.60

    Signed-off-by: Willy Tarreau <w@1wt.eu>
    Willy Tarreau committed Feb 11, 2012
  2. @bonzini

    dm: do not forward ioctls from logical volumes to the underlying device

    commit ec8013b upstream.
    
    A logical volume can map to just part of underlying physical volume.
    In this case, it must be treated like a partition.
    
    Based on a patch from Alasdair G Kergon.
    
    Cc: Alasdair G Kergon <agk@redhat.com>
    Cc: dm-devel@redhat.com
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    [bwh: Backport to 2.6.32 - drop change to drivers/md/dm-flakey.c]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    
    Signed-off-by: Willy Tarreau <w@1wt.eu>
    bonzini committed with Willy Tarreau Jan 17, 2012
  3. @bonzini

    block: fail SCSI passthrough ioctls on partition devices

    commit 0bfc96c upstream.
    
    [ Changes with respect to 3.3: return -ENOTTY from scsi_verify_blk_ioctl
      and -ENOIOCTLCMD from sd_compat_ioctl. ]
    
    Linux allows executing the SG_IO ioctl on a partition or LVM volume, and
    will pass the command to the underlying block device.  This is
    well-known, but it is also a large security problem when (via Unix
    permissions, ACLs, SELinux or a combination thereof) a program or user
    needs to be granted access only to part of the disk.
    
    This patch lets partitions forward a small set of harmless ioctls;
    others are logged with printk so that we can see which ioctls are
    actually sent.  In my tests only CDROM_GET_CAPABILITY actually occurred.
    Of course it was being sent to a (partition on a) hard disk, so it would
    have failed with ENOTTY and the patch isn't changing anything in
    practice.  Still, I'm treating it specially to avoid spamming the logs.
    
    In principle, this restriction should include programs running with
    CAP_SYS_RAWIO.  If for example I let a program access /dev/sda2 and
    /dev/sdb, it still should not be able to read/write outside the
    boundaries of /dev/sda2 independent of the capabilities.  However, for
    now programs with CAP_SYS_RAWIO will still be allowed to send the
    ioctls.  Their actions will still be logged.
    
    This patch does not affect the non-libata IDE driver.  That driver
    however already tests for bd != bd->bd_contains before issuing some
    ioctl; it could be restricted further to forbid these ioctls even for
    programs running with CAP_SYS_ADMIN/CAP_SYS_RAWIO.
    
    Cc: linux-scsi@vger.kernel.org
    Cc: Jens Axboe <axboe@kernel.dk>
    Cc: James Bottomley <JBottomley@parallels.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    [ Make it also print the command name when warning - Linus ]
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    [bwh: Backport to 2.6.32 - ENOIOCTLCMD does not get converted to
     ENOTTY, so we must return ENOTTY directly]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    
    Signed-off-by: Willy Tarreau <w@1wt.eu>
    bonzini committed with Willy Tarreau Jan 17, 2012
  4. @bonzini

    block: add and use scsi_blk_cmd_ioctl

    commit 577ebb3 upstream.
    
    Introduce a wrapper around scsi_cmd_ioctl that takes a block device.
    
    The function will then be enhanced to detect partition block devices
    and, in that case, subject the ioctls to whitelisting.
    
    Cc: linux-scsi@vger.kernel.org
    Cc: Jens Axboe <axboe@kernel.dk>
    Cc: James Bottomley <JBottomley@parallels.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    [bwh: Backport to 2.6.32 - adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    [wt: slightly changed the interface to match 2.6.27's scsi_cmd_ioctl()
         which still needs the file pointer but has no mode parameter].
    
    Signed-off-by: Willy Tarreau <w@1wt.eu>
    bonzini committed with Willy Tarreau Jan 12, 2012
  5. @tettamanti

    i8k: Avoid lahf in 64-bit code

    commit bc1f419 upstream.
    
    i8k uses lahf to read the flag register in 64-bit code; early x86-64
    CPUs, however, lack this instruction and we get an invalid opcode
    exception at runtime.
    Use pushf to load the flag register into the stack instead.
    
    Signed-off-by: Luca Tettamanti <kronos.it@gmail.com>
    Reported-by: Jeff Rickman <jrickman@myamigos.us>
    Tested-by: Jeff Rickman <jrickman@myamigos.us>
    Tested-by: Harry G McGavran Jr <w5pny@arrl.net>
    Cc: Massimo Dal Zotto <dz@debian.org>
    Signed-off-by: Jean Delvare <khali@linux-fr.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    Signed-off-by: Willy Tarreau <w@1wt.eu>
    tettamanti committed with Willy Tarreau May 25, 2011
  6. @michal42

    kbuild: Fix passing -Wno-* options to gcc 4.4+

    commit 8417da6 upstream.
    
    Starting with 4.4, gcc will happily accept -Wno-<anything> in the
    cc-option test and complain later when compiling a file that has some
    other warning. This rather unexpected behavior is intentional as per
    http://gcc.gnu.org/PR28322, so work around it by testing for support of
    the opposite option (without the no-). Introduce a new Makefile function
    cc-disable-warning that does this and update two uses of cc-option in
    the toplevel Makefile.
    
    Reported-and-tested-by: Stephen Rothwell <sfr@canb.auug.org.au>
    Signed-off-by: Michal Marek <mmarek@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    Signed-off-by: Willy Tarreau <w@1wt.eu>
    michal42 committed with Willy Tarreau May 2, 2011
  7. @kernelslacker

    kbuild: Disable -Wunused-but-set-variable for gcc 4.6.0

    commit af0e5d5 upstream.
    
    Disable the new -Wunused-but-set-variable that was added in gcc 4.6.0
    It produces more false positives than useful warnings.
    
    This can still be enabled using W=1
    [gregkh - No it can not for 2.6.32, but we don't care]
    
    Signed-off-by: Dave Jones <davej@redhat.com>
    Acked-by: Sam Ravnborg <sam@ravnborg.org>
    Tested-by: Sam Ravnborg <sam@ravnborg.org>
    Signed-off-by: Michal Marek <mmarek@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    Signed-off-by: Willy Tarreau <w@1wt.eu>
    kernelslacker committed with Willy Tarreau Apr 21, 2011
  8. Fix gcc 4.5.1 miscompiling drivers/char/i8k.c (again)

    commit 22d3243 upstream.
    
    The fix in commit 6b4e81d ("i8k: Tell gcc that *regs gets
    clobbered") to work around the gcc miscompiling i8k.c to add "+m
    (*regs)" caused register pressure problems and a build failure.
    
    Changing the 'asm' statement to 'asm volatile' instead should prevent
    that and works around the gcc bug as well, so we can remove the "+m".
    
    [ Background on the gcc bug: a memory clobber fails to mark the function
      the asm resides in as non-pure (aka "__attribute__((const))"), so if
      the function does nothing else that triggers the non-pure logic, gcc
      will think that that function has no side effects at all. As a result,
      callers will be mis-compiled.
    
      Adding the "+m" made gcc see that it's not a pure function, and so
      does "asm volatile". The problem was never really the need to mark
      "*regs" as changed, since the memory clobber did that part - the
      problem was just a bug in the gcc "pure" function analysis  - Linus ]
    
    Signed-off-by: Jim Bos <jim876@xs4all.nl>
    Acked-by: Jakub Jelinek <jakub@redhat.com>
    Cc: Andi Kleen <andi@firstfloor.org>
    Cc: Andreas Schwab <schwab@linux-m68k.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    Signed-off-by: Willy Tarreau <w@1wt.eu>
    Jim Bos committed with Willy Tarreau Nov 15, 2010
  9. i8k: Tell gcc that *regs gets clobbered

    commit 6b4e81d upstream.
    
    More recent GCC caused the i8k driver to stop working, on Slackware
    compiler was upgraded from gcc-4.4.4 to gcc-4.5.1 after which it didn't
    work anymore, meaning the driver didn't load or gave total nonsensical
    output.
    
    As it turned out the asm(..) statement forgot to mention it modifies the
    *regs variable.
    
    Credits to Andi Kleen and Andreas Schwab for providing the fix.
    
    Signed-off-by: Jim Bos <jim876@xs4all.nl>
    Cc: Andi Kleen <andi@firstfloor.org>
    Cc: Andreas Schwab <schwab@linux-m68k.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    Signed-off-by: Willy Tarreau <w@1wt.eu>
    Jim Bos committed with Willy Tarreau Nov 13, 2010
  10. @lnussel

    x86: Fix mmap random address range

    commit 9af0c7a upstream.
    
    On x86_32 casting the unsigned int result of get_random_int() to
    long may result in a negative value.  On x86_32 the range of
    mmap_rnd() therefore was -255 to 255.  The 32bit mode on x86_64
    used 0 to 255 as intended.
    
    The bug was introduced by 675a081 ("x86: unify mmap_{32|64}.c")
    in January 2008.
    
    Signed-off-by: Ludwig Nussel <ludwig.nussel@suse.de>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: harvey.harrison@gmail.com
    Cc: "H. Peter Anvin" <hpa@zytor.com>
    Cc: Harvey Harrison <harvey.harrison@gmail.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Link: http://lkml.kernel.org/r/201111152246.pAFMklOB028527@wpaz5.hot.corp.google.com
    Signed-off-by: Ingo Molnar <mingo@elte.hu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    Signed-off-by: Willy Tarreau <w@1wt.eu>
    lnussel committed with Willy Tarreau Nov 15, 2011
  11. @msmeissn

    net/ipv4: Check for mistakenly passed in non-IPv4 address

    [ Upstream commit d0733d2 ]
    
    Check against mistakenly passing in IPv6 addresses (which would result
    in an INADDR_ANY bind) or similar incompatible sockaddrs.
    
    Signed-off-by: Marcus Meissner <meissner@suse.de>
    Cc: Reinhard Max <max@suse.de>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    Signed-off-by: Willy Tarreau <w@1wt.eu>
    msmeissn committed with Willy Tarreau Jun 2, 2011
  12. Fix time() inconsistencies caused by intermediate xtime_cache values …

    …being read
    
    Currently with 2.6.32-longterm, its possible for time() to occasionally
    return values one second earlier then the previous time() call.
    
    This happens because update_xtime_cache() does:
    	xtime_cache = xtime;
    	timespec_add_ns(&xtime_cache, nsec);
    
    Its possible that xtime is 1sec,999msecs, and nsecs is 1ms, resulting in
    a xtime_cache that is 2sec,0ms.
    
    get_seconds() (which is used by sys_time()) does not take the
    xtime_lock, which is ok as the xtime.tv_sec value is a long and can be
    atomically read safely.
    
    The problem occurs the next call to update_xtime_cache() if xtime has
    not increased:
    	/* This sets xtime_cache back to 1sec, 999msec */
    	xtime_cache = xtime;
    	/* get_seconds, calls here, and sees a 1second inconsistency */
    	timespec_add_ns(&xtime_cache, nsec);
    
    In order to resolve this, we could add locking to get_seconds(), but it
    needs to be lock free, as it is called from the machine check handler,
    opening a possible deadlock.
    
    So instead, this patch introduces an intermediate value for the
    calculations, so that we only assign xtime_cache once with the correct
    time, using ACCESS_ONCE to make sure the compiler doesn't optimize out
    any intermediate values.
    
    The xtime_cache manipulations were removed with 2.6.35, so that kernel
    and later do not need this change.
    
    In 2.6.33 and 2.6.34 the logarithmic accumulation should make it so
    xtime is updated each tick, so it is unlikely that two updates to
    xtime_cache could occur while the difference between xtime and
    xtime_cache crosses the second boundary. However, the paranoid might
    want to pull this into 2.6.33/34-longterm just to be sure.
    
    Thanks to Stephen for helping finally narrow down the root cause and
    many hours of help with testing and validation. Also thanks to Max,
    Andi, Eric and Paul for review of earlier attempts and helping clarify
    what is possible with regard to out of order execution.
    
    Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
    Signed-off-by: John Stultz <johnstul@us.ibm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    Signed-off-by: Willy Tarreau <w@1wt.eu>
    john stultz committed with Willy Tarreau May 11, 2011
  13. af_packet: prevent information leak

    [ Upstream commit 13fcb7b ]
    
    In 2.6.27, commit 393e52e (packet: deliver VLAN TCI to userspace)
    added a small information leak.
    
    Add padding field and make sure its zeroed before copy to user.
    
    Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
    CC: Patrick McHardy <kaber@trash.net>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    Signed-off-by: Willy Tarreau <w@1wt.eu>
    Eric Dumazet committed with Willy Tarreau Jun 7, 2011
  14. @JoePerches

    MAINTAINERS: stable: Update address

    commit bc7a2f3 upstream.
    
    The old address hasn't worked since the great intrusion of August 2011.
    
    Signed-off-by: Joe Perches <joe@perches.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    Signed-off-by: Willy Tarreau <w@1wt.eu>
    JoePerches committed with Willy Tarreau Dec 9, 2011
  15. @jirislaby

    SCSI: scsi_lib: fix potential NULL dereference

    commit 03b1470 upstream.
    
    Stanse found a potential NULL dereference in scsi_kill_request.
    
    Instead of triggering BUG() in 'if (unlikely(cmd == NULL))' branch,
    the kernel will Oops earlier on cmd dereference.
    
    Move the dereferences after the if.
    
    [ WT: starget is not set in 2.6.27 ]
    
    Signed-off-by: Jiri Slaby <jirislaby@gmail.com>
    Signed-off-by: James Bottomley <James.Bottomley@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    Signed-off-by: Willy Tarreau <w@1wt.eu>
    jirislaby committed with Willy Tarreau Sep 23, 2009
  16. x86, 64-bit: Fix copy_[to/from]_user() checks for the userspace addre…

    …ss limit
    
    commit 26afb7c upstream.
    
    As reported in BZ #30352:
    
      https://bugzilla.kernel.org/show_bug.cgi?id=30352
    
    there's a kernel bug related to reading the last allowed page on x86_64.
    
    The _copy_to_user() and _copy_from_user() functions use the following
    check for address limit:
    
      if (buf + size >= limit)
    	fail();
    
    while it should be more permissive:
    
      if (buf + size > limit)
    	fail();
    
    That's because the size represents the number of bytes being
    read/write from/to buf address AND including the buf address.
    So the copy function will actually never touch the limit
    address even if "buf + size == limit".
    
    Following program fails to use the last page as buffer
    due to the wrong limit check:
    
     #include <sys/mman.h>
     #include <sys/socket.h>
     #include <assert.h>
    
     #define PAGE_SIZE       (4096)
     #define LAST_PAGE       ((void*)(0x7fffffffe000))
    
     int main()
     {
            int fds[2], err;
            void * ptr = mmap(LAST_PAGE, PAGE_SIZE, PROT_READ | PROT_WRITE,
                              MAP_ANONYMOUS | MAP_PRIVATE | MAP_FIXED, -1, 0);
            assert(ptr == LAST_PAGE);
            err = socketpair(AF_LOCAL, SOCK_STREAM, 0, fds);
            assert(err == 0);
            err = send(fds[0], ptr, PAGE_SIZE, 0);
            perror("send");
            assert(err == PAGE_SIZE);
            err = recv(fds[1], ptr, PAGE_SIZE, MSG_WAITALL);
            perror("recv");
            assert(err == PAGE_SIZE);
            return 0;
     }
    
    The other place checking the addr limit is the access_ok() function,
    which is working properly. There's just a misleading comment
    for the __range_not_ok() macro - which this patch fixes as well.
    
    The last page of the user-space address range is a guard page and
    Brian Gerst observed that the guard page itself due to an erratum on K8 cpus
    (#121 Sequential Execution Across Non-Canonical Boundary Causes Processor
    Hang).
    
    However, the test code is using the last valid page before the guard page.
    The bug is that the last byte before the guard page can't be read
    because of the off-by-one error. The guard page is left in place.
    
    This bug would normally not show up because the last page is
    part of the process stack and never accessed via syscalls.
    
    [WT: in 2.6.27 use include/asm-x86/uaccess.h]
    
    Signed-off-by: Jiri Olsa <jolsa@redhat.com>
    Acked-by: Brian Gerst <brgerst@gmail.com>
    Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
    Link: http://lkml.kernel.org/r/1305210630-7136-1-git-send-email-jolsa@redhat.com
    Signed-off-by: Ingo Molnar <mingo@elte.hu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    Signed-off-by: Willy Tarreau <w@1wt.eu>
    Jiri Olsa committed with Willy Tarreau May 12, 2011
  17. block: add proper state guards to __elv_next_request

    commit 0a58e07 upstream.
    
    blk_cleanup_queue() calls elevator_exit() and after this, we can't
    touch the elevator without oopsing.  __elv_next_request() must check
    for this state because in the refcounted queue model, we can still
    call it after blk_cleanup_queue() has been called.
    
    This was reported as causing an oops attributable to scsi.
    
    [WT: in 2.6.27, __elv_next_request() is in elevator.c]
    
    Signed-off-by: James Bottomley <James.Bottomley@suse.de>
    Signed-off-by: Jens Axboe <jaxboe@fusionio.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    Signed-off-by: Willy Tarreau <w@1wt.eu>
    James Bottomley committed with Willy Tarreau May 18, 2011
  18. bonding: Ensure that we unshare skbs prior to calling pskb_may_pull

    commit b305325 upstream.
    
    Recently reported oops:
    
    kernel BUG at net/core/skbuff.c:813!
    invalid opcode: 0000 [#1] SMP
    last sysfs file: /sys/devices/virtual/net/bond0/broadcast
    CPU 8
    Modules linked in: sit tunnel4 cpufreq_ondemand acpi_cpufreq freq_table bonding
    ipv6 dm_mirror dm_region_hash dm_log cdc_ether usbnet mii serio_raw i2c_i801
    i2c_core iTCO_wdt iTCO_vendor_support shpchp ioatdma i7core_edac edac_core bnx2
    ixgbe dca mdio sg ext4 mbcache jbd2 sd_mod crc_t10dif mptsas mptscsih mptbase
    scsi_transport_sas dm_mod [last unloaded: microcode]
    
    Modules linked in: sit tunnel4 cpufreq_ondemand acpi_cpufreq freq_table bonding
    ipv6 dm_mirror dm_region_hash dm_log cdc_ether usbnet mii serio_raw i2c_i801
    i2c_core iTCO_wdt iTCO_vendor_support shpchp ioatdma i7core_edac edac_core bnx2
    ixgbe dca mdio sg ext4 mbcache jbd2 sd_mod crc_t10dif mptsas mptscsih mptbase
    scsi_transport_sas dm_mod [last unloaded: microcode]
    Pid: 0, comm: swapper Not tainted 2.6.32-71.el6.x86_64 #1 BladeCenter HS22
    -[7870AC1]-
    RIP: 0010:[<ffffffff81405b16>]  [<ffffffff81405b16>]
    pskb_expand_head+0x36/0x1e0
    RSP: 0018:ffff880028303b70  EFLAGS: 00010202
    RAX: 0000000000000002 RBX: ffff880c6458ec80 RCX: 0000000000000020
    RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff880c6458ec80
    RBP: ffff880028303bc0 R08: ffffffff818a6180 R09: ffff880c6458ed64
    R10: ffff880c622b36c0 R11: 0000000000000400 R12: 0000000000000000
    R13: 0000000000000180 R14: ffff880c622b3000 R15: 0000000000000000
    FS:  0000000000000000(0000) GS:ffff880028300000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0018 ES: 0018 CR0: 000000008005003b
    CR2: 00000038653452a4 CR3: 0000000001001000 CR4: 00000000000006e0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
    Process swapper (pid: 0, threadinfo ffff8806649c2000, task ffff880c64f16ab0)
    Stack:
     ffff880028303bc0 ffffffff8104fff9 000000000000001c 0000000100000000
    <0> ffff880000047d80 ffff880c6458ec80 000000000000001c ffff880c6223da00
    <0> ffff880c622b3000 0000000000000000 ffff880028303c10 ffffffff81407f7a
    Call Trace:
    <IRQ>
     [<ffffffff8104fff9>] ? __wake_up_common+0x59/0x90
     [<ffffffff81407f7a>] __pskb_pull_tail+0x2aa/0x360
     [<ffffffffa0244530>] bond_arp_rcv+0x2c0/0x2e0 [bonding]
     [<ffffffff814a0857>] ? packet_rcv+0x377/0x440
     [<ffffffff8140f21b>] netif_receive_skb+0x2db/0x670
     [<ffffffff8140f788>] napi_skb_finish+0x58/0x70
     [<ffffffff8140fc89>] napi_gro_receive+0x39/0x50
     [<ffffffffa01286eb>] ixgbe_clean_rx_irq+0x35b/0x900 [ixgbe]
     [<ffffffffa01290f6>] ixgbe_clean_rxtx_many+0x136/0x240 [ixgbe]
     [<ffffffff8140fe53>] net_rx_action+0x103/0x210
     [<ffffffff81073bd7>] __do_softirq+0xb7/0x1e0
     [<ffffffff810d8740>] ? handle_IRQ_event+0x60/0x170
     [<ffffffff810142cc>] call_softirq+0x1c/0x30
     [<ffffffff81015f35>] do_softirq+0x65/0xa0
     [<ffffffff810739d5>] irq_exit+0x85/0x90
     [<ffffffff814cf915>] do_IRQ+0x75/0xf0
     [<ffffffff81013ad3>] ret_from_intr+0x0/0x11
     <EOI>
     [<ffffffff8101bc01>] ? mwait_idle+0x71/0xd0
     [<ffffffff814cd80a>] ? atomic_notifier_call_chain+0x1a/0x20
     [<ffffffff81011e96>] cpu_idle+0xb6/0x110
     [<ffffffff814c17c8>] start_secondary+0x1fc/0x23f
    
    Resulted from bonding driver registering packet handlers via dev_add_pack and
    then trying to call pskb_may_pull. If another packet handler (like for AF_PACKET
    sockets) gets called first, the delivered skb will have a user count > 1, which
    causes pskb_may_pull to BUG halt when it does its skb_shared check.  Fix this by
    calling skb_share_check prior to the may_pull call sites in the bonding driver
    to clone the skb when needed.  Tested by myself and the reported successfully.
    
    Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
    CC: Andy Gospodarek <andy@greyhouse.net>
    CC: Jay Vosburgh <fubar@us.ibm.com>
    CC: "David S. Miller" <davem@davemloft.net>
    Signed-off-by: Jay Vosburgh <fubar@us.ibm.com>
    Signed-off-by: Andy Gospodarek <andy@greyhouse.net>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    Signed-off-by: Willy Tarreau <w@1wt.eu>
    Neil Horman committed with Willy Tarreau Jan 20, 2011
  19. @gospo

    bonding: correctly process non-linear skbs

    commit ab12811 upstream.
    
    It was recently brought to my attention that 802.3ad mode bonds would no
    longer form when using some network hardware after a driver update.
    After snooping around I realized that the particular hardware was using
    page-based skbs and found that skb->data did not contain a valid LACPDU
    as it was not stored there.  That explained the inability to form an
    802.3ad-based bond.  For balance-alb mode bonds this was also an issue
    as ARPs would not be properly processed.
    
    This patch fixes the issue in my tests and should be applied to 2.6.36
    and as far back as anyone cares to add it to stable.
    
    Thanks to Alexander Duyck <alexander.h.duyck@intel.com> and Jesse
    Brandeburg <jesse.brandeburg@intel.com> for the suggestions on this one.
    
    Signed-off-by: Andy Gospodarek <andy@greyhouse.net>
    CC: Alexander Duyck <alexander.h.duyck@intel.com>
    CC: Jesse Brandeburg <jesse.brandeburg@intel.com>
    Signed-off-by: Jay Vosburgh <fubar@us.ibm.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    Signed-off-by: Willy Tarreau <w@1wt.eu>
    gospo committed with Willy Tarreau Sep 10, 2010