Skip to content
This repository

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
branch: linux-3.0.15

Jan 03, 2012

  1. Greg Kroah-Hartman

    Linux 3.0.15

    authored January 03, 2012
  2. Linus Torvalds

    Revert "clockevents: Set noop handler in clockevents_exchange_device()"

    commit 3b87487 upstream.
    
    This reverts commit de28f25.
    
    It results in resume problems for various people. See for example
    
      http://thread.gmane.org/gmane.linux.kernel/1233033
      http://thread.gmane.org/gmane.linux.kernel/1233389
      http://thread.gmane.org/gmane.linux.kernel/1233159
      http://thread.gmane.org/gmane.linux.kernel/1227868/focus=1230877
    
    and the fedora and ubuntu bug reports
    
      https://bugzilla.redhat.com/show_bug.cgi?id=767248
      https://bugs.launchpad.net/ubuntu/+source/linux/+bug/904569
    
    which got bisected down to the stable version of this commit.
    
    Reported-by: Jonathan Nieder <jrnieder@gmail.com>
    Reported-by: Phil Miller <mille121@illinois.edu>
    Reported-by: Philip Langdale <philipl@overt.org>
    Reported-by: Tim Gardner <tim.gardner@canonical.com>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    authored December 30, 2011 gregkh committed January 03, 2012

Dec 21, 2011

  1. Greg Kroah-Hartman

    Linux 3.0.14

    authored December 21, 2011
  2. Stephen Warren

    ASoC: core: Don't schedule deferred_resume_work twice

    commit 82e14e8 upstream.
    
    For cards that have two or more DAIs, snd_soc_resume's loop over all
    DAIs ends up calling schedule_work(deferred_resume_work) once per DAI.
    Since this is the same work item each time, the 2nd and subsequent
    calls return 0 (work item already queued), and trigger the dev_err
    message below stating that a work item may have been lost.
    
    Solve this by adjusting the loop to simply calculate whether to run the
    resume work immediately or defer it, and then call schedule work (or not)
    one time based on that.
    
    Note: This has not been tested in mainline, but only in chromeos-2.6.38;
    mainline doesn't support suspend/resume on Tegra, nor does the mainline
    Tegra ASoC driver contain multiple DAIs. It has been compile-checked in
    mainline.
    
    Signed-off-by: Stephen Warren <swarren@nvidia.com>
    Acked-by: Liam Girdwood <lrg@ti.com>
    Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    authored May 25, 2011 gregkh committed December 21, 2011
  3. Bjørn Mork

    USB: option: Removing one bogus and adding some new Huawei combinations

    commit 02a551c upstream.
    
    Huawei use the product code HUAWEI_PRODUCT_E353 (0x1506) for a
    number of different devices, which each can appear with a number
    of different descriptor sets.  Different types of interfaces
    can be identified by looking at the subclass and protocol fields
    
    Subclass 1 protocol 8 is actually the data interface of a CDC
    ECM set, with subclass 1 protocol 9 as the control interface.
    Neither support serial data communcation, and cannot therefore
    be supported by this driver.
    
    At the same time, add a few other sets which appear if the
    device is configured in "Windows mode" using this modeswitch
    message:
    55534243000000000000000000000011060000000100000000000000000000
    
    Signed-off-by: Bjørn Mork <bjorn@mork.no>
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    authored December 13, 2011 gregkh committed December 21, 2011
  4. usb: option: Add Huawei E398 controlling interfaces

    commit 414b591 upstream.
    
    This patch adds the controlling interfaces for the Huawei E398.
    
    Thanks to Bjørn Mork <bjorn@mork.no> for extracting the interface
    numbers from the windows driver.
    
    Signed-off-by: Alex Hermann <alex@wenlex.nl>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    authored December 12, 2011 gregkh committed December 21, 2011
  5. USB: cdc-acm: add IDs for Motorola H24 HSPA USB module.

    commit 6abff5d upstream.
    
    Add USB IDs for Motorola H24 HSPA USB module.
    
    Signed-off-by: Krzysztof Hałasa <khalasa@piap.pl>
    Acked-by: Oliver Neukum <oneukum@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    authored December 12, 2011 gregkh committed December 21, 2011
  6. ibft: Fix finding IBFT ACPI table on UEFI

    commit 935a9fe upstream.
    
    Found one system with UEFI/iBFT, kernel does not detect the iBFT during
    iscsi_ibft module loading.
    
    Root cause: on x86 (UEFI), we are calling of find_ibft_region() much earlier
    - specifically in setup_arch() before ACPI is enabled.
    
    Try to split acpi checking code out and call that later
    
    At that time ACPI iBFT already get permanent mapped with ioremap.
    So isa_virt_to_bus() will get wrong phys from right virt address.
    We could just skip that phys address printing.
    
    For legacy one, print the found address early.
    
    -v2: update comments and description according to Konrad.
    -v3: fix problem about module use case that is found by Konrad.
    -v4: use acpi_get_table() instead of acpi_table_parse() to handle module use case that is found by Konrad again..
    Signed-off-by: Yinghai Lu <yinghai@kernel.org>
    Signed-off-by: Konrad Rzeszutek Wilk <konrad@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    authored December 12, 2011 gregkh committed December 21, 2011
  7. drm/radeon/kms: add some new pci ids

    commit cd5cfce upstream.
    
    Fixes:
    https://bugs.freedesktop.org/show_bug.cgi?id=43739
    
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Dave Airlie <airlied@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    authored December 12, 2011 gregkh committed December 21, 2011
  8. lwfinger

    staging: r8712u: Add new USB ID

    commit c7caf4d upstream.
    
    Add USB ID for Sitecom WLA-2000 v1.001 WLAN.
    
    Reported-and-tested-by: Roland Gruber <post@rolandgruber.de>
    Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    authored December 11, 2011 gregkh committed December 21, 2011
  9. fuse: fix fuse_retrieve

    commit 48706d0 upstream.
    
    Fix two bugs in fuse_retrieve():
    
     - retrieving more than one page would yield repeated instances of the
       first page
    
     - if more than FUSE_MAX_PAGES_PER_REQ pages were requested than the
       request page array would overflow
    
    fuse_retrieve() was added in 2.6.36 and these bugs had been there since the
    beginning.
    
    Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    authored December 13, 2011 gregkh committed December 21, 2011
  10. Yongqiang Yang

    ext4: handle EOF correctly in ext4_bio_write_page()

    commit 5a0dc73 upstream.
    
    We need to zero out part of a page which beyond EOF before setting uptodate,
    otherwise, mapread or write will see non-zero data beyond EOF.
    
    Signed-off-by: Yongqiang Yang <xiaoqiangnk@gmail.com>
    Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    authored December 13, 2011 gregkh committed December 21, 2011
  11. Yongqiang Yang

    ext4: avoid potential hang in mpage_submit_io() when blocksize < page…

    …size
    
    commit 13a79a4 upstream.
    
    If there is an unwritten but clean buffer in a page and there is a
    dirty buffer after the buffer, then mpage_submit_io does not write the
    dirty buffer out.  As a result, da_writepages loops forever.
    
    This patch fixes the problem by checking dirty flag.
    
    Signed-off-by: Yongqiang Yang <xiaoqiangnk@gmail.com>
    Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    authored December 13, 2011 gregkh committed December 21, 2011
  12. ext4: avoid hangs in ext4_da_should_update_i_disksize()

    commit ea51d13 upstream.
    
    If the pte mapping in generic_perform_write() is unmapped between
    iov_iter_fault_in_readable() and iov_iter_copy_from_user_atomic(), the
    "copied" parameter to ->end_write can be zero. ext4 couldn't cope with
    it with delayed allocations enabled. This skips the i_disksize
    enlargement logic if copied is zero and no new data was appeneded to
    the inode.
    
     gdb> bt
     #0  0xffffffff811afe80 in ext4_da_should_update_i_disksize (file=0xffff88003f606a80, mapping=0xffff88001d3824e0, pos=0x1\
     08000, len=0x1000, copied=0x0, page=0xffffea0000d792e8, fsdata=0x0) at fs/ext4/inode.c:2467
     #1  ext4_da_write_end (file=0xffff88003f606a80, mapping=0xffff88001d3824e0, pos=0x108000, len=0x1000, copied=0x0, page=0\
     xffffea0000d792e8, fsdata=0x0) at fs/ext4/inode.c:2512
     #2  0xffffffff810d97f1 in generic_perform_write (iocb=<value optimized out>, iov=<value optimized out>, nr_segs=<value o\
     ptimized out>, pos=0x108000, ppos=0xffff88001e26be40, count=<value optimized out>, written=0x0) at mm/filemap.c:2440
     #3  generic_file_buffered_write (iocb=<value optimized out>, iov=<value optimized out>, nr_segs=<value optimized out>, p\
     os=0x108000, ppos=0xffff88001e26be40, count=<value optimized out>, written=0x0) at mm/filemap.c:2482
     #4  0xffffffff810db5d1 in __generic_file_aio_write (iocb=0xffff88001e26bde8, iov=0xffff88001e26bec8, nr_segs=0x1, ppos=0\
     xffff88001e26be40) at mm/filemap.c:2600
     #5  0xffffffff810db853 in generic_file_aio_write (iocb=0xffff88001e26bde8, iov=0xffff88001e26bec8, nr_segs=<value optimi\
     zed out>, pos=<value optimized out>) at mm/filemap.c:2632
     #6  0xffffffff811a71aa in ext4_file_write (iocb=0xffff88001e26bde8, iov=0xffff88001e26bec8, nr_segs=0x1, pos=0x108000) a\
     t fs/ext4/file.c:136
     #7  0xffffffff811375aa in do_sync_write (filp=0xffff88003f606a80, buf=<value optimized out>, len=<value optimized out>, \
     ppos=0xffff88001e26bf48) at fs/read_write.c:406
     #8  0xffffffff81137e56 in vfs_write (file=0xffff88003f606a80, buf=0x1ec2960 <Address 0x1ec2960 out of bounds>, count=0x4\
     000, pos=0xffff88001e26bf48) at fs/read_write.c:435
     #9  0xffffffff8113816c in sys_write (fd=<value optimized out>, buf=0x1ec2960 <Address 0x1ec2960 out of bounds>, count=0x\
     4000) at fs/read_write.c:487
     #10 <signal handler called>
     #11 0x00007f120077a390 in __brk_reservation_fn_dmi_alloc__ ()
     #12 0x0000000000000000 in ?? ()
     gdb> print offset
     $22 = 0xffffffffffffffff
     gdb> print idx
     $23 = 0xffffffff
     gdb> print inode->i_blkbits
     $24 = 0xc
     gdb> up
     #1  ext4_da_write_end (file=0xffff88003f606a80, mapping=0xffff88001d3824e0, pos=0x108000, len=0x1000, copied=0x0, page=0\
     xffffea0000d792e8, fsdata=0x0) at fs/ext4/inode.c:2512
     2512                    if (ext4_da_should_update_i_disksize(page, end)) {
     gdb> print start
     $25 = 0x0
     gdb> print end
     $26 = 0xffffffffffffffff
     gdb> print pos
     $27 = 0x108000
     gdb> print new_i_size
     $28 = 0x108000
     gdb> print ((struct ext4_inode_info *)((char *)inode-((int)(&((struct ext4_inode_info *)0)->vfs_inode))))->i_disksize
     $29 = 0xd9000
     gdb> down
     2467            for (i = 0; i < idx; i++)
     gdb> print i
     $30 = 0xd44acbee
    
    This is 100% reproducible with some autonuma development code tuned in
    a very aggressive manner (not normal way even for knumad) which does
    "exotic" changes to the ptes. It wouldn't normally trigger but I don't
    see why it can't happen normally if the page is added to swap cache in
    between the two faults leading to "copied" being zero (which then
    hangs in ext4). So it should be fixed. Especially possible with lumpy
    reclaim (albeit disabled if compaction is enabled) as that would
    ignore the young bits in the ptes.
    
    Signed-off-by: Andrea Arcangeli <aarcange@redhat.com>
    Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    authored December 13, 2011 gregkh committed December 21, 2011
  13. Theodore Ts'o

    ext4: display the correct mount option in /proc/mounts for [no]init_i…

    …table
    
    commit fc6cb1c upstream.
    
    /proc/mounts was showing the mount option [no]init_inode_table when
    the correct mount option that will be accepted by parse_options() is
    [no]init_itable.
    
    Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    authored December 12, 2011 gregkh committed December 21, 2011
  14. xen: only limit memory map to maximum reservation for domain 0.

    commit d3db728 upstream.
    
    d312ae878b6a "xen: use maximum reservation to limit amount of usable RAM"
    clamped the total amount of RAM to the current maximum reservation. This is
    correct for dom0 but is not correct for guest domains. In order to boot a guest
    "pre-ballooned" (e.g. with memory=1G but maxmem=2G) in order to allow for
    future memory expansion the guest must derive max_pfn from the e820 provided by
    the toolstack and not the current maximum reservation (which can reflect only
    the current maximum, not the guest lifetime max). The existing algorithm
    already behaves this correctly if we do not artificially limit the maximum
    number of pages for the guest case.
    
    For a guest booted with maxmem=512, memory=128 this results in:
     [    0.000000] BIOS-provided physical RAM map:
     [    0.000000]  Xen: 0000000000000000 - 00000000000a0000 (usable)
     [    0.000000]  Xen: 00000000000a0000 - 0000000000100000 (reserved)
    -[    0.000000]  Xen: 0000000000100000 - 0000000008100000 (usable)
    -[    0.000000]  Xen: 0000000008100000 - 0000000020800000 (unusable)
    +[    0.000000]  Xen: 0000000000100000 - 0000000020800000 (usable)
    ...
     [    0.000000] NX (Execute Disable) protection: active
     [    0.000000] DMI not present or invalid.
     [    0.000000] e820 update range: 0000000000000000 - 0000000000010000 (usable) ==> (reserved)
     [    0.000000] e820 remove range: 00000000000a0000 - 0000000000100000 (usable)
    -[    0.000000] last_pfn = 0x8100 max_arch_pfn = 0x1000000
    +[    0.000000] last_pfn = 0x20800 max_arch_pfn = 0x1000000
     [    0.000000] initial memory mapped : 0 - 027ff000
     [    0.000000] Base memory trampoline at [c009f000] 9f000 size 4096
    -[    0.000000] init_memory_mapping: 0000000000000000-0000000008100000
    -[    0.000000]  0000000000 - 0008100000 page 4k
    -[    0.000000] kernel direct mapping tables up to 8100000 @ 27bb000-27ff000
    +[    0.000000] init_memory_mapping: 0000000000000000-0000000020800000
    +[    0.000000]  0000000000 - 0020800000 page 4k
    +[    0.000000] kernel direct mapping tables up to 20800000 @ 26f8000-27ff000
     [    0.000000] xen: setting RW the range 27e8000 - 27ff000
     [    0.000000] 0MB HIGHMEM available.
    -[    0.000000] 129MB LOWMEM available.
    -[    0.000000]   mapped low ram: 0 - 08100000
    -[    0.000000]   low ram: 0 - 08100000
    +[    0.000000] 520MB LOWMEM available.
    +[    0.000000]   mapped low ram: 0 - 20800000
    +[    0.000000]   low ram: 0 - 20800000
    
    With this change "xl mem-set <domain> 512M" will successfully increase the
    guest RAM (by reducing the balloon).
    
    There is no change for dom0.
    
    Reported-and-Tested-by:  George Shuklin <george.shuklin@gmail.com>
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Reviewed-by: David Vrabel <david.vrabel@citrix.com>
    Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    authored December 14, 2011 gregkh committed December 21, 2011
  15. NeilBrown

    md/raid5: fix bug that could result in reads from a failed device.

    commit 355840e upstream.
    
    commit a847627 in linux-3.0.9
    attempted to backport this to 3.0 but only made one change were two
    were necessary.  This add the second change.
    
    This bug was introduced in 415e72d
    which was in 2.6.36.
    
    There is a small window of time between when a device fails and when
    it is removed from the array.  During this time we might still read
    from it, but we won't write to it - so it is possible that we could
    read stale data.
    
    We didn't need the test of 'Faulty' before because the test on
    In_sync is sufficient.  Since we started allowing reads from the early
    part of non-In_sync devices we need a test on Faulty too.
    
    This is suitable for any kernel from 2.6.36 onwards, though the patch
    might need a bit of tweaking in 3.0 and earlier.
    
    Signed-off-by: NeilBrown <neilb@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    authored December 15, 2011 gregkh committed December 21, 2011
  16. xfs: avoid synchronous transactions when deleting attr blocks

    commit 859f57c upstream.
    
    [slightly different from the upstream version because of a previous cleanup]
    
    Currently xfs_attr_inactive causes a synchronous transactions if we are
    removing a file that has any extents allocated to the attribute fork, and
    thus makes XFS extremely slow at removing files with out of line extended
    attributes. The code looks a like a relict from the days before the busy
    extent list, but with the busy extent list we avoid reusing data and attr
    extents that have been freed but not commited yet, so this code is just
    as superflous as the synchronous transactions for data blocks.
    
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Reported-by: Bernd Schubert <bernd.schubert@itwm.fraunhofer.de>
    Reviewed-by: Dave Chinner <dchinner@redhat.com>
    Signed-off-by: Alex Elder <aelder@sgi.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    authored December 12, 2011 gregkh committed December 21, 2011
  17. xfs: fix nfs export of 64-bit inodes numbers on 32-bit kernels

    commit c29f7d4 upstream.
    
    The i_ino field in the VFS inode is of type unsigned long and thus can't
    hold the full 64-bit inode number on 32-bit kernels.  We have the full
    inode number in the XFS inode, so use that one for nfs exports.  Note
    that I've also switched the 32-bit file handles types to it, just to make
    the code more consistent and copy & paste errors less likely to happen.
    
    Reported-by: Guoquan Yang <ygq51@hotmail.com>
    Reported-by: Hank Peng <pengxihan@gmail.com>
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Ben Myers <bpm@sgi.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    authored December 12, 2011 gregkh committed December 21, 2011
  18. hwmon: (coretemp) Fix oops on CPU offlining

    This is for stable kernel branch 3.0 only. Previous and later versions
    have different code paths and are not affected by this bug.
    
    This is the same fix as "hwmon: (coretemp) Fix oops on driver load"
    but for the CPU offlining case. Sorry for missing it at first.
    
    Signed-off-by: Jean Delvare <khali@linux-fr.org>
    Cc: Durgadoss R <durgadoss.r@intel.com>
    Acked-by: Guenter Roeck <guenter.roeck@ericsson.com>
    Cc: Fenghua Yu <fenghua.yu@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    authored December 13, 2011 gregkh committed December 21, 2011
  19. hfs: fix hfs_find_init() sb->ext_tree NULL ptr oops

    commit 434a964 upstream.
    
    Clement Lecigne reports a filesystem which causes a kernel oops in
    hfs_find_init() trying to dereference sb->ext_tree which is NULL.
    
    This proves to be because the filesystem has a corrupted MDB extent
    record, where the extents file does not fit into the first three extents
    in the file record (the first blocks).
    
    In hfs_get_block() when looking up the blocks for the extent file
    (HFS_EXT_CNID), it fails the first blocks special case, and falls
    through to the extent code (which ultimately calls hfs_find_init())
    which is in the process of being initialised.
    
    Hfs avoids this scenario by always having the extents b-tree fitting
    into the first blocks (the extents B-tree can't have overflow extents).
    
    The fix is to check at mount time that the B-tree fits into first
    blocks, i.e.  fail if HFS_I(inode)->alloc_blocks >=
    HFS_I(inode)->first_blocks
    
    Note, the existing commit 47f365e ("hfs: fix oops on mount with
    corrupted btree extent records") becomes subsumed into this as a special
    case, but only for the extents B-tree (HFS_EXT_CNID), it is perfectly
    acceptable for the catalog B-Tree file to grow beyond three extents,
    with the remaining extent descriptors in the extents overfow.
    
    This fixes CVE-2011-2203
    
    Reported-by: Clement LECIGNE <clement.lecigne@netasq.com>
    Signed-off-by: Phillip Lougher <plougher@redhat.com>
    Cc: Jeff Mahoney <jeffm@suse.com>
    Cc: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Moritz Mühlenhoff <jmm@inutil.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    authored November 02, 2011 gregkh committed December 21, 2011
  20. Linus Torvalds

    Make TASKSTATS require root access

    commit 1a51410 upstream.
    
    Ok, this isn't optimal, since it means that 'iotop' needs admin
    capabilities, and we may have to work on this some more.  But at the
    same time it is very much not acceptable to let anybody just read
    anybody elses IO statistics quite at this level.
    
    Use of the GENL_ADMIN_PERM suggested by Johannes Berg as an alternative
    to checking the capabilities by hand.
    
    Reported-by: Vasiliy Kulikov <segoon@openwall.com>
    Cc: Johannes Berg <johannes.berg@intel.com>
    Acked-by: Balbir Singh <bsingharora@gmail.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Moritz Mühlenhoff <jmm@inutil.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    authored September 19, 2011 gregkh committed December 21, 2011
  21. Eryu Guan

    jbd/jbd2: validate sb->s_first in journal_get_superblock()

    commit 8762202 upstream.
    
    I hit a J_ASSERT(blocknr != 0) failure in cleanup_journal_tail() when
    mounting a fsfuzzed ext3 image. It turns out that the corrupted ext3
    image has s_first = 0 in journal superblock, and the 0 is passed to
    journal->j_head in journal_reset(), then to blocknr in
    cleanup_journal_tail(), in the end the J_ASSERT failed.
    
    So validate s_first after reading journal superblock from disk in
    journal_get_superblock() to ensure s_first is valid.
    
    The following script could reproduce it:
    
    fstype=ext3
    blocksize=1024
    img=$fstype.img
    offset=0
    found=0
    magic="c0 3b 39 98"
    
    dd if=/dev/zero of=$img bs=1M count=8
    mkfs -t $fstype -b $blocksize -F $img
    filesize=`stat -c %s $img`
    while [ $offset -lt $filesize ]
    do
            if od -j $offset -N 4 -t x1 $img | grep -i "$magic";then
                    echo "Found journal: $offset"
                    found=1
                    break
            fi
            offset=`echo "$offset+$blocksize" | bc`
    done
    
    if [ $found -ne 1 ];then
            echo "Magic \"$magic\" not found"
            exit 1
    fi
    
    dd if=/dev/zero of=$img seek=$(($offset+23)) conv=notrunc bs=1 count=1
    
    mkdir -p ./mnt
    mount -o loop $img ./mnt
    
    Cc: Jan Kara <jack@suse.cz>
    Signed-off-by: Eryu Guan <guaneryu@gmail.com>
    Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
    Cc: Moritz Mühlenhoff <jmm@inutil.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    authored November 01, 2011 gregkh committed December 21, 2011
  22. x86, hpet: Immediately disable HPET timer 1 if rtc irq is masked

    commit 2ded6e6 upstream.
    
    When HPET is operating in RTC mode, the TN_ENABLE bit on timer1
    controls whether the HPET or the RTC delivers interrupts to irq8. When
    the system goes into suspend, the RTC driver sends a signal to the
    HPET driver so that the HPET releases control of irq8, allowing the
    RTC to wake the system from suspend. The switchover is accomplished by
    a write to the HPET configuration registers which currently only
    occurs while servicing the HPET interrupt.
    
    On some systems, I have seen the system suspend before an HPET
    interrupt occurs, preventing the write to the HPET configuration
    register and leaving the HPET in control of the irq8. As the HPET is
    not active during suspend, it does not generate a wake signal and RTC
    alarms do not work.
    
    This patch forces the HPET driver to immediately transfer control of
    the irq8 channel to the RTC instead of waiting until the next
    interrupt event.
    
    Signed-off-by: Mark Langsdorf <mark.langsdorf@amd.com>
    Link: http://lkml.kernel.org/r/20111118153306.GB16319@alberich.amd.com
    Tested-by: Andreas Herrmann <andreas.herrmann3@amd.com>
    Signed-off-by: Andreas Herrmann <andreas.herrmann3@amd.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    authored November 18, 2011 gregkh committed December 21, 2011
  23. mmc: mxcmmc: fix falling back to PIO

    commit e58f516 upstream.
    
    When we can't configure the dma channel we want to fall
    back to PIO. We do this by setting host->do_dma to zero.
    This does not work as do_dma is used to see whether dma
    can be used for the current transfer. Instead, we have
    to set host->dma to NULL.
    
    Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
    Signed-off-by: Chris Ball <cjb@laptop.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    authored November 11, 2011 gregkh committed December 21, 2011
  24. Axel Lin

    hwmon: (jz4740) fix signedness bug

    commit 0b57d76 upstream.
    
    wait_for_completion_interruptible_timeout() may return negative value.
    In this case, checking if (t > 0)  will return true if t is unsigned.
    
    Signed-off-by: Axel Lin <axel.lin@gmail.com>
    Acked-by: Lars-Peter Clausen <lars@metafoo.de>
    Signed-off-by: Guenter Roeck <guenter.roeck@ericsson.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    authored December 08, 2011 gregkh committed December 21, 2011
  25. Linus Torvalds

    linux/log2.h: Fix rounddown_pow_of_two(1)

    commit 13c07b0 upstream.
    
    Exactly like roundup_pow_of_two(1), the rounddown version was buggy for
    the case of a compile-time constant '1' argument.  Probably because it
    originated from the same code, sharing history with the roundup version
    from before the bugfix (for that one, see commit 1a06a52: "Fix
    roundup_pow_of_two(1)").
    
    However, unlike the roundup version, the fix for rounddown is to just
    remove the broken special case entirely.  It's simply not needed - the
    generic code
    
        1UL << ilog2(n)
    
    does the right thing for the constant '1' argment too.  The only reason
    roundup needed that special case was because rounding up does so by
    subtracting one from the argument (and then adding one to the result)
    causing the obvious problems with "ilog2(0)".
    
    But rounddown doesn't do any of that, since ilog2() naturally truncates
    (ie "rounds down") to the right rounded down value.  And without the
    ilog2(0) case, there's no reason for the special case that had the wrong
    value.
    
    tl;dr: rounddown_pow_of_two(1) should be 1, not 0.
    
    Acked-by: Dmitry Torokhov <dtor@vmware.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    authored December 12, 2011 gregkh committed December 21, 2011
  26. Nikolay Martynov

    mac80211: fix race condition caused by late addBA response

    Upstream commit d305a65.
    
    If addBA responses comes in just after addba_resp_timer has
    expired mac80211 will still accept it and try to open the
    aggregation session. This causes drivers to be confused and
    in some cases even crash.
    
    This patch fixes the race condition and makes sure that if
    addba_resp_timer has expired addBA response is not longer
    accepted and we do not try to open half-closed session.
    
    Signed-off-by: Nikolay Martynov <mar.kolya@gmail.com>
    [some adjustments]
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    authored December 10, 2011 gregkh committed December 21, 2011
  27. iwlwifi: do not re-configure HT40 after associated

    commit 34a5b4b upstream.
    
    The ht40 setting should not change after association unless channel switch
    
    This fix a problem we are seeing which cause uCode assert because driver
    sending invalid information and make uCode confuse
    
    Here is the firmware assert message:
    kernel: iwlagn 0000:03:00.0: Microcode SW error detected.  Restarting 0x82000000.
    kernel: iwlagn 0000:03:00.0: Loaded firmware version: 17.168.5.3 build 42301
    kernel: iwlagn 0000:03:00.0: Start IWL Error Log Dump:
    kernel: iwlagn 0000:03:00.0: Status: 0x000512E4, count: 6
    kernel: iwlagn 0000:03:00.0: 0x00002078 | ADVANCED_SYSASSERT
    kernel: iwlagn 0000:03:00.0: 0x00009514 | uPc
    kernel: iwlagn 0000:03:00.0: 0x00009496 | branchlink1
    kernel: iwlagn 0000:03:00.0: 0x00009496 | branchlink2
    kernel: iwlagn 0000:03:00.0: 0x0000D1F2 | interruptlink1
    kernel: iwlagn 0000:03:00.0: 0x00000000 | interruptlink2
    kernel: iwlagn 0000:03:00.0: 0x01008035 | data1
    kernel: iwlagn 0000:03:00.0: 0x0000C90F | data2
    kernel: iwlagn 0000:03:00.0: 0x000005A7 | line
    kernel: iwlagn 0000:03:00.0: 0x5080B520 | beacon time
    kernel: iwlagn 0000:03:00.0: 0xCC515AE0 | tsf low
    kernel: iwlagn 0000:03:00.0: 0x00000003 | tsf hi
    kernel: iwlagn 0000:03:00.0: 0x00000000 | time gp1
    kernel: iwlagn 0000:03:00.0: 0x29703BF0 | time gp2
    kernel: iwlagn 0000:03:00.0: 0x00000000 | time gp3
    kernel: iwlagn 0000:03:00.0: 0x000111A8 | uCode version
    kernel: iwlagn 0000:03:00.0: 0x000000B0 | hw version
    kernel: iwlagn 0000:03:00.0: 0x00480303 | board version
    kernel: iwlagn 0000:03:00.0: 0x09E8004E | hcmd
    kernel: iwlagn 0000:03:00.0: CSR values:
    kernel: iwlagn 0000:03:00.0: (2nd byte of CSR_INT_COALESCING is CSR_INT_PERIODIC_REG)
    kernel: iwlagn 0000:03:00.0:        CSR_HW_IF_CONFIG_REG: 0X00480303
    kernel: iwlagn 0000:03:00.0:          CSR_INT_COALESCING: 0X0000ff40
    kernel: iwlagn 0000:03:00.0:                     CSR_INT: 0X00000000
    kernel: iwlagn 0000:03:00.0:                CSR_INT_MASK: 0X00000000
    kernel: iwlagn 0000:03:00.0:           CSR_FH_INT_STATUS: 0X00000000
    kernel: iwlagn 0000:03:00.0:                 CSR_GPIO_IN: 0X00000030
    kernel: iwlagn 0000:03:00.0:                   CSR_RESET: 0X00000000
    kernel: iwlagn 0000:03:00.0:                CSR_GP_CNTRL: 0X080403c5
    kernel: iwlagn 0000:03:00.0:                  CSR_HW_REV: 0X000000b0
    kernel: iwlagn 0000:03:00.0:              CSR_EEPROM_REG: 0X07d60ffd
    kernel: iwlagn 0000:03:00.0:               CSR_EEPROM_GP: 0X90000001
    kernel: iwlagn 0000:03:00.0:              CSR_OTP_GP_REG: 0X00030001
    kernel: iwlagn 0000:03:00.0:                 CSR_GIO_REG: 0X00080044
    kernel: iwlagn 0000:03:00.0:            CSR_GP_UCODE_REG: 0X000093bb
    kernel: iwlagn 0000:03:00.0:           CSR_GP_DRIVER_REG: 0X00000000
    kernel: iwlagn 0000:03:00.0:           CSR_UCODE_DRV_GP1: 0X00000000
    kernel: iwlagn 0000:03:00.0:           CSR_UCODE_DRV_GP2: 0X00000000
    kernel: iwlagn 0000:03:00.0:                 CSR_LED_REG: 0X00000078
    kernel: iwlagn 0000:03:00.0:        CSR_DRAM_INT_TBL_REG: 0X88214dd2
    kernel: iwlagn 0000:03:00.0:        CSR_GIO_CHICKEN_BITS: 0X27800200
    kernel: iwlagn 0000:03:00.0:             CSR_ANA_PLL_CFG: 0X00000000
    kernel: iwlagn 0000:03:00.0:           CSR_HW_REV_WA_REG: 0X0001001a
    kernel: iwlagn 0000:03:00.0:        CSR_DBG_HPET_MEM_REG: 0Xffff0010
    kernel: iwlagn 0000:03:00.0: FH register values:
    kernel: iwlagn 0000:03:00.0:         FH_RSCSR_CHNL0_STTS_WPTR_REG: 0X21316d00
    kernel: iwlagn 0000:03:00.0:        FH_RSCSR_CHNL0_RBDCB_BASE_REG: 0X021479c0
    kernel: iwlagn 0000:03:00.0:                  FH_RSCSR_CHNL0_WPTR: 0X00000060
    kernel: iwlagn 0000:03:00.0:         FH_MEM_RCSR_CHNL0_CONFIG_REG: 0X80819104
    kernel: iwlagn 0000:03:00.0:          FH_MEM_RSSR_SHARED_CTRL_REG: 0X000000fc
    kernel: iwlagn 0000:03:00.0:            FH_MEM_RSSR_RX_STATUS_REG: 0X07030000
    kernel: iwlagn 0000:03:00.0:    FH_MEM_RSSR_RX_ENABLE_ERR_IRQ2DRV: 0X00000000
    kernel: iwlagn 0000:03:00.0:                FH_TSSR_TX_STATUS_REG: 0X07ff0001
    kernel: iwlagn 0000:03:00.0:                 FH_TSSR_TX_ERROR_REG: 0X00000000
    kernel: iwlagn 0000:03:00.0: Start IWL Event Log Dump: display last 20 entries
    kernel: ------------[ cut here ]------------
    WARNING: at net/mac80211/util.c:1208 ieee80211_reconfig+0x1f1/0x407()
    kernel: Hardware name: 4290W4H
    kernel: Pid: 1896, comm: kworker/0:0 Not tainted 3.1.0 #2
    kernel: Call Trace:
    kernel:  [<ffffffff81036558>] ? warn_slowpath_common+0x73/0x87
    kernel:  [<ffffffff813b8966>] ? ieee80211_reconfig+0x1f1/0x407
    kernel:  [<ffffffff8139e8dc>] ? ieee80211_recalc_smps_work+0x32/0x32
    kernel:  [<ffffffff8139e95a>] ? ieee80211_restart_work+0x7e/0x87
    kernel:  [<ffffffff810472fa>] ? process_one_work+0x1c8/0x2e3
    kernel:  [<ffffffff810480c9>] ? worker_thread+0x17a/0x23a
    kernel:  [<ffffffff81047f4f>] ? manage_workers.clone.18+0x15b/0x15b
    kernel:  [<ffffffff81047f4f>] ? manage_workers.clone.18+0x15b/0x15b
    kernel:  [<ffffffff8104ba97>] ? kthread+0x7a/0x82
    kernel:  [<ffffffff813d21b4>] ? kernel_thread_helper+0x4/0x10
    kernel:  [<ffffffff8104ba1d>] ? kthread_flush_work_fn+0x11/0x11
    kernel:  [<ffffffff813d21b0>] ? gs_change+0xb/0xb
    
    Reported-by: Udo Steinberg <udo@hypervisor.org>
    Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    authored December 02, 2011 gregkh committed December 21, 2011
  28. percpu: fix chunk range calculation

    commit a855b84 upstream.
    
    Percpu allocator recorded the cpus which map to the first and last
    units in pcpu_first/last_unit_cpu respectively and used them to
    determine the address range of a chunk - e.g. it assumed that the
    first unit has the lowest address in a chunk while the last unit has
    the highest address.
    
    This simply isn't true.  Groups in a chunk can have arbitrary positive
    or negative offsets from the previous one and there is no guarantee
    that the first unit occupies the lowest offset while the last one the
    highest.
    
    Fix it by actually comparing unit offsets to determine cpus occupying
    the lowest and highest offsets.  Also, rename pcu_first/last_unit_cpu
    to pcpu_low/high_unit_cpu to avoid confusion.
    
    The chunk address range is used to flush cache on vmalloc area
    map/unmap and decide whether a given address is in the first chunk by
    per_cpu_ptr_to_phys() and the bug was discovered by invalid
    per_cpu_ptr_to_phys() translation for crash_note.
    
    Kudos to Dave Young for tracking down the problem.
    
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Reported-by: WANG Cong <xiyou.wangcong@gmail.com>
    Reported-by: Dave Young <dyoung@redhat.com>
    Tested-by: Dave Young <dyoung@redhat.com>
    LKML-Reference: <4EC21F67.10905@redhat.com>
    Signed-off-by: Thomas Renninger <trenn@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    authored November 18, 2011 gregkh committed December 21, 2011
  29. yaknella

    intel-iommu: fix superpage support in pfn_to_dma_pte()

    commit 4399c8b upstream.
    
    If target_level == 0, current code breaks out of the while-loop if
    SUPERPAGE bit is set. We should also break out if PTE is not present.
    If we don't do this, KVM calls to iommu_iova_to_phys() will cause
    pfn_to_dma_pte() to create mapping for 4KiB pages.
    
    Signed-off-by: Allen Kay <allen.m.kay@intel.com>
    Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
    Signed-off-by: Youquan Song <youquan.song@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    authored October 14, 2011 gregkh committed December 21, 2011
  30. yaknella

    intel-iommu: set iommu_superpage on VM domains to lowest common denom…

    …inator
    
    commit 8140a95 upstream.
    
    set dmar->iommu_superpage field to the smallest common denominator
    of super page sizes supported by all active VT-d engines.  Initialize
    this field in intel_iommu_domain_init() API so intel_iommu_map() API
    will be able to use iommu_superpage field to determine the appropriate
    super page size to use.
    
    Signed-off-by: Allen Kay <allen.m.kay@intel.com>
    Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
    Signed-off-by: Youquan Song <youquan.song@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    authored October 14, 2011 gregkh committed December 21, 2011
  31. yaknella

    intel-iommu: fix return value of iommu_unmap() API

    commit 292827c upstream.
    
    iommu_unmap() API expects IOMMU drivers to return the actual page order
    of the address being unmapped.  Previous code was just returning page
    order passed in from the caller.  This patch fixes this problem.
    
    Signed-off-by: Allen Kay <allen.m.kay@intel.com>
    Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
    Signed-off-by: Youquan Song <youquan.song@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    authored October 14, 2011 gregkh committed December 21, 2011
  32. Roland Dreier

    target: Handle 0 correctly in transport_get_sectors_6()

    commit 9b5cd7f upstream.
    
    SBC-3 says:
    
        A TRANSFER LENGTH field set to zero specifies that 256 logical
        blocks shall be written.  Any other value specifies the number
        of logical blocks that shall be written.
    
    The old code was always just returning the value in the TRANSFER LENGTH
    byte.  Fix this to return 256 if the byte is 0.
    
    Signed-off-by: Roland Dreier <roland@purestorage.com>
    Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    authored November 22, 2011 gregkh committed December 21, 2011
  33. fix apparmor dereferencing potentially freed dentry, sanitize __d_pat…

    …h() API
    
    commit 02125a8 upstream.
    
    __d_path() API is asking for trouble and in case of apparmor d_namespace_path()
    getting just that.  The root cause is that when __d_path() misses the root
    it had been told to look for, it stores the location of the most remote ancestor
    in *root.  Without grabbing references.  Sure, at the moment of call it had
    been pinned down by what we have in *path.  And if we raced with umount -l, we
    could have very well stopped at vfsmount/dentry that got freed as soon as
    prepend_path() dropped vfsmount_lock.
    
    It is safe to compare these pointers with pre-existing (and known to be still
    alive) vfsmount and dentry, as long as all we are asking is "is it the same
    address?".  Dereferencing is not safe and apparmor ended up stepping into
    that.  d_namespace_path() really wants to examine the place where we stopped,
    even if it's not connected to our namespace.  As the result, it looked
    at ->d_sb->s_magic of a dentry that might've been already freed by that point.
    All other callers had been careful enough to avoid that, but it's really
    a bad interface - it invites that kind of trouble.
    
    The fix is fairly straightforward, even though it's bigger than I'd like:
    	* prepend_path() root argument becomes const.
    	* __d_path() is never called with NULL/NULL root.  It was a kludge
    to start with.  Instead, we have an explicit function - d_absolute_root().
    Same as __d_path(), except that it doesn't get root passed and stops where
    it stops.  apparmor and tomoyo are using it.
    	* __d_path() returns NULL on path outside of root.  The main
    caller is show_mountinfo() and that's precisely what we pass root for - to
    skip those outside chroot jail.  Those who don't want that can (and do)
    use d_path().
    	* __d_path() root argument becomes const.  Everyone agrees, I hope.
    	* apparmor does *NOT* try to use __d_path() or any of its variants
    when it sees that path->mnt is an internal vfsmount.  In that case it's
    definitely not mounted anywhere and dentry_path() is exactly what we want
    there.  Handling of sysctl()-triggered weirdness is moved to that place.
    	* if apparmor is asked to do pathname relative to chroot jail
    and __d_path() tells it we it's not in that jail, the sucker just calls
    d_absolute_path() instead.  That's the other remaining caller of __d_path(),
    BTW.
            * seq_path_root() does _NOT_ return -ENAMETOOLONG (it's stupid anyway -
    the normal seq_file logics will take care of growing the buffer and redoing
    the call of ->show() just fine).  However, if it gets path not reachable
    from root, it returns SEQ_SKIP.  The only caller adjusted (i.e. stopped
    ignoring the return value as it used to do).
    
    Reviewed-by: John Johansen <john.johansen@canonical.com>
    ACKed-by: John Johansen <john.johansen@canonical.com>
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    authored December 05, 2011 gregkh committed December 21, 2011
Something went wrong with that request. Please try again.