01 Aug, 2014

22 commits

  • commit a800bad36619ce47ac0222004635448e6c91ff72 upstream.

    Default s_time_gran is 1, don't overwrite that if userspace didn't
    explicitly specify one.

    Signed-off-by: Miklos Szeredi
    Signed-off-by: Greg Kroah-Hartman

    Miklos Szeredi
     
  • commit aed8adb7688d5744cb484226820163af31d2499a upstream.

    Commit 079148b919d0 ("coredump: factor out the setting of PF_DUMPCORE")
    cleaned up the setting of PF_DUMPCORE by removing it from all the
    linux_binfmt->core_dump() and moving it to zap_threads().But this ended
    up clearing all the previously set flags. This causes issues during
    core generation when tsk->flags is checked again (eg. for PF_USED_MATH
    to dump floating point registers). Fix this.

    Signed-off-by: Silesh C V
    Acked-by: Oleg Nesterov
    Cc: Mandeep Singh Baines
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds
    Signed-off-by: Greg Kroah-Hartman

    Silesh C V
     
  • commit 50c5d36dab930b1f1b1e3348b8608aa8b9ee7610 upstream.

    We attempt to remove noise from coordinates reported by devices in
    input_handle_abs_event(), unfortunately, unless we were dropping the
    event altogether, we were ignoring the adjusted value and were passing
    on the original value instead.

    Reviewed-by: Andrew de los Reyes
    Reviewed-by: Benson Leung
    Reviewed-by: David Herrmann
    Reviewed-by: Henrik Rydberg
    Signed-off-by: Dmitry Torokhov
    Signed-off-by: Greg Kroah-Hartman

    Dmitry Torokhov
     
  • commit e76aed9da7189eeb41b9856552ce5721181e8e8d upstream.

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

    Signed-off-by: Hans de Goede
    Signed-off-by: Dmitry Torokhov
    Signed-off-by: Greg Kroah-Hartman

    Hans de Goede
     
  • commit 694617474e33b8603fc76e090ed7d09376514b1a upstream.

    The patch 3e374919b314f20e2a04f641ebc1093d758f66a4 is supposed to fix the
    problem where kmem_cache_create incorrectly reports duplicate cache name
    and fails. The problem is described in the header of that patch.

    However, the patch doesn't really fix the problem because of these
    reasons:

    * the logic to test for debugging is reversed. It was intended to perform
    the check only if slub debugging is enabled (which implies that caches
    with the same parameters are not merged). Therefore, there should be
    #if !defined(CONFIG_SLUB) || defined(CONFIG_SLUB_DEBUG_ON)
    The current code has the condition reversed and performs the test if
    debugging is disabled.

    * slub debugging may be enabled or disabled based on kernel command line,
    CONFIG_SLUB_DEBUG_ON is just the default settings. Therefore the test
    based on definition of CONFIG_SLUB_DEBUG_ON is unreliable.

    This patch fixes the problem by removing the test
    "!defined(CONFIG_SLUB_DEBUG_ON)". Therefore, duplicate names are never
    checked if the SLUB allocator is used.

    Note to stable kernel maintainers: when backporint this patch, please
    backport also the patch 3e374919b314f20e2a04f641ebc1093d758f66a4.

    Acked-by: David Rientjes
    Acked-by: Christoph Lameter
    Signed-off-by: Mikulas Patocka
    Signed-off-by: Pekka Enberg
    Signed-off-by: Greg Kroah-Hartman

    Mikulas Patocka
     
  • commit 97a9a7179aad701ab676e6f29eb90766a1acfde2 upstream.

    Commit 75b57ecf9 refactored device tree nodes to use kobjects such that they
    can be exposed via /sysfs. A secondary commit 0829f6d1f furthered this rework
    by moving the kobect initialization logic out of of_node_add into its own
    of_node_init function. The inital commit removed the existing kref_init calls
    in the pseries dlpar code with the assumption kobject initialization would
    occur in of_node_add. The second commit had the side effect of triggering a
    BUG_ON during DLPAR, migration and suspend/resume operations as a result of
    dynamically added nodes being uninitialized.

    This patch fixes this by adding of_node_init calls in place of the previously
    removed kref_init calls.

    Fixes: 0829f6d1f69e ("of: device_node kobject lifecycle fixes")
    Signed-off-by: Tyrel Datwyler
    Acked-by: Nathan Fontenot
    Acked-by: Grant Likely
    Signed-off-by: Benjamin Herrenschmidt
    Signed-off-by: Greg Kroah-Hartman

    Tyrel Datwyler
     
  • commit b4c5c60920e3b0c4598f43e7317559f6aec51531 upstream.

    Sasha reported lockdep warning [1] introduced by [2].

    It could be fixed by doing disk revalidation out of the init_lock. It's
    okay because disk capacity change is protected by init_lock so that
    revalidate_disk always sees up-to-date value so there is no race.

    [1] https://lkml.org/lkml/2014/7/3/735
    [2] zram: revalidate disk after capacity change

    Fixes 2e32baea46ce ("zram: revalidate disk after capacity change").

    Signed-off-by: Minchan Kim
    Reported-by: Sasha Levin
    Cc: "Alexander E. Patrakov"
    Cc: Nitin Gupta
    Cc: Jerome Marchand
    Cc: Sergey Senozhatsky
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds
    Signed-off-by: Greg Kroah-Hartman

    Minchan Kim
     
  • commit 58d4e21e50ff3cc57910a8abc20d7e14375d2f61 upstream.

    The "uptime" trace clock added in:

    commit 8aacf017b065a805d27467843490c976835eb4a5
    tracing: Add "uptime" trace clock that uses jiffies

    has wraparound problems when the system has been up more
    than 1 hour 11 minutes and 34 seconds. It converts jiffies
    to nanoseconds using:
    (u64)jiffies_to_usecs(jiffy) * 1000ULL
    but since jiffies_to_usecs() only returns a 32-bit value, it
    truncates at 2^32 microseconds. An additional problem on 32-bit
    systems is that the argument is "unsigned long", so fixing the
    return value only helps until 2^32 jiffies (49.7 days on a HZ=1000
    system).

    Avoid these problems by using jiffies_64 as our basis, and
    not converting to nanoseconds (we do convert to clock_t because
    user facing API must not be dependent on internal kernel
    HZ values).

    Link: http://lkml.kernel.org/p/99d63c5bfe9b320a3b428d773825a37095bf6a51.1405708254.git.tony.luck@intel.com

    Fixes: 8aacf017b065 "tracing: Add "uptime" trace clock that uses jiffies"
    Signed-off-by: Tony Luck
    Signed-off-by: Steven Rostedt
    Signed-off-by: Greg Kroah-Hartman

    Tony Luck
     
  • commit 0b462c89e31f7eb6789713437eb551833ee16ff3 upstream.

    While a queue is being destroyed, all the blkgs are destroyed and its
    ->root_blkg pointer is set to NULL. If someone else starts to drain
    while the queue is in this state, the following oops happens.

    NULL pointer dereference at 0000000000000028
    IP: [] blk_throtl_drain+0x84/0x230
    PGD e4a1067 PUD b773067 PMD 0
    Oops: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC
    Modules linked in: cfq_iosched(-) [last unloaded: cfq_iosched]
    CPU: 1 PID: 537 Comm: bash Not tainted 3.16.0-rc3-work+ #2
    Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
    task: ffff88000e222250 ti: ffff88000efd4000 task.ti: ffff88000efd4000
    RIP: 0010:[] [] blk_throtl_drain+0x84/0x230
    RSP: 0018:ffff88000efd7bf0 EFLAGS: 00010046
    RAX: 0000000000000000 RBX: ffff880015091450 RCX: 0000000000000001
    RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
    RBP: ffff88000efd7c10 R08: 0000000000000000 R09: 0000000000000001
    R10: ffff88000e222250 R11: 0000000000000000 R12: ffff880015091450
    R13: ffff880015092e00 R14: ffff880015091d70 R15: ffff88001508fc28
    FS: 00007f1332650740(0000) GS:ffff88001fa80000(0000) knlGS:0000000000000000
    CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
    CR2: 0000000000000028 CR3: 0000000009446000 CR4: 00000000000006e0
    Stack:
    ffffffff8144e8f6 ffff880015091450 0000000000000000 ffff880015091d80
    ffff88000efd7c28 ffffffff8144ae2f ffff880015091450 ffff88000efd7c58
    ffffffff81427641 ffff880015091450 ffffffff82401f00 ffff880015091450
    Call Trace:
    [] blkcg_drain_queue+0x1f/0x60
    [] __blk_drain_queue+0x71/0x180
    [] blk_queue_bypass_start+0x6e/0xb0
    [] blkcg_deactivate_policy+0x38/0x120
    [] blk_throtl_exit+0x34/0x50
    [] blkcg_exit_queue+0x35/0x40
    [] blk_release_queue+0x26/0xd0
    [] kobject_cleanup+0x38/0x70
    [] kobject_put+0x28/0x60
    [] blk_put_queue+0x15/0x20
    [] scsi_device_dev_release_usercontext+0x16b/0x1c0
    [] execute_in_process_context+0x89/0xa0
    [] scsi_device_dev_release+0x1c/0x20
    [] device_release+0x32/0xa0
    [] kobject_cleanup+0x38/0x70
    [] kobject_put+0x28/0x60
    [] put_device+0x17/0x20
    [] __scsi_remove_device+0xa9/0xe0
    [] scsi_remove_device+0x2b/0x40
    [] sdev_store_delete+0x27/0x30
    [] dev_attr_store+0x18/0x30
    [] sysfs_kf_write+0x3e/0x50
    [] kernfs_fop_write+0xe7/0x170
    [] vfs_write+0xaf/0x1d0
    [] SyS_write+0x4d/0xc0
    [] system_call_fastpath+0x16/0x1b

    776687bce42b ("block, blk-mq: draining can't be skipped even if
    bypass_depth was non-zero") made it easier to trigger this bug by
    making blk_queue_bypass_start() drain even when it loses the first
    bypass test to blk_cleanup_queue(); however, the bug has always been
    there even before the commit as blk_queue_bypass_start() could race
    against queue destruction, win the initial bypass test but perform the
    actual draining after blk_cleanup_queue() already destroyed all blkgs.

    Fix it by skippping calling into policy draining if all the blkgs are
    already gone.

    Signed-off-by: Tejun Heo
    Reported-by: Shirish Pargaonkar
    Reported-by: Sasha Levin
    Reported-by: Jet Chen
    Tested-by: Shirish Pargaonkar
    Signed-off-by: Jens Axboe
    Signed-off-by: Greg Kroah-Hartman

    Tejun Heo
     
  • commit b32bfc06aefab61acc872dec3222624e6cd867ed upstream.

    Add support of the Promise FastTrak TX8660 SATA HBA in ahci mode by
    registering the board in the ahci_pci_tbl[].

    Note: this HBA also provide a hardware RAID mode when activated in
    BIOS but specific drivers from the manufacturer are required in this
    case.

    Signed-off-by: Romain Degez
    Tested-by: Romain Degez
    Signed-off-by: Tejun Heo
    Signed-off-by: Greg Kroah-Hartman

    Romain Degez
     
  • commit dab6cf55f81a6e16b8147aed9a843e1691dcd318 upstream.

    The PSW mask check of the PTRACE_POKEUSR_AREA command is incorrect.
    The PSW_MASK_USER define contains the PSW_MASK_ASC bits, the ptrace
    interface accepts all combinations for the address-space-control
    bits. To protect the kernel space the PSW mask check in ptrace needs
    to reject the address-space-control bit combination for home space.

    Fixes CVE-2014-3534

    Signed-off-by: Martin Schwidefsky
    Signed-off-by: Greg Kroah-Hartman

    Martin Schwidefsky
     
  • commit 1a112d10f03e83fb3a2fdc4c9165865dec8a3ca6 upstream.

    1871ee134b73 ("libata: support the ata host which implements a queue
    depth less than 32") directly used ata_port->scsi_host->can_queue from
    ata_qc_new() to determine the number of tags supported by the host;
    unfortunately, SAS controllers doing SATA don't initialize ->scsi_host
    leading to the following oops.

    BUG: unable to handle kernel NULL pointer dereference at 0000000000000058
    IP: [] ata_qc_new_init+0x188/0x1b0
    PGD 0
    Oops: 0002 [#1] SMP
    Modules linked in: isci libsas scsi_transport_sas mgag200 drm_kms_helper ttm
    CPU: 1 PID: 518 Comm: udevd Not tainted 3.16.0-rc6+ #62
    Hardware name: Intel Corporation S2600CO/S2600CO, BIOS SE5C600.86B.02.02.0002.122320131210 12/23/2013
    task: ffff880c1a00b280 ti: ffff88061a000000 task.ti: ffff88061a000000
    RIP: 0010:[] [] ata_qc_new_init+0x188/0x1b0
    RSP: 0018:ffff88061a003ae8 EFLAGS: 00010012
    RAX: 0000000000000001 RBX: ffff88000241ca80 RCX: 00000000000000fa
    RDX: 0000000000000020 RSI: 0000000000000020 RDI: ffff8806194aa298
    RBP: ffff88061a003ae8 R08: ffff8806194a8000 R09: 0000000000000000
    R10: 0000000000000000 R11: ffff88000241ca80 R12: ffff88061ad58200
    R13: ffff8806194aa298 R14: ffffffff814e67a0 R15: ffff8806194a8000
    FS: 00007f3ad7fe3840(0000) GS:ffff880627620000(0000) knlGS:0000000000000000
    CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 0000000000000058 CR3: 000000061a118000 CR4: 00000000001407e0
    Stack:
    ffff88061a003b20 ffffffff814e96e1 ffff88000241ca80 ffff88061ad58200
    ffff8800b6bf6000 ffff880c1c988000 ffff880619903850 ffff88061a003b68
    ffffffffa0056ce1 ffff88061a003b48 0000000013d6e6f8 ffff88000241ca80
    Call Trace:
    [] ata_sas_queuecmd+0xa1/0x430
    [] sas_queuecommand+0x191/0x220 [libsas]
    [] scsi_dispatch_cmd+0x10e/0x300 [] scsi_request_fn+0x2f5/0x550
    [] __blk_run_queue+0x33/0x40
    [] queue_unplugged+0x2a/0x90
    [] blk_flush_plug_list+0x1b4/0x210
    [] blk_finish_plug+0x14/0x50
    [] __do_page_cache_readahead+0x198/0x1f0
    [] force_page_cache_readahead+0x31/0x50
    [] page_cache_sync_readahead+0x3e/0x50
    [] generic_file_read_iter+0x496/0x5a0
    [] blkdev_read_iter+0x37/0x40
    [] new_sync_read+0x7e/0xb0
    [] vfs_read+0x94/0x170
    [] SyS_read+0x46/0xb0
    [] ? SyS_lseek+0x91/0xb0
    [] system_call_fastpath+0x16/0x1b
    Code: 00 00 00 88 50 29 83 7f 08 01 19 d2 83 e2 f0 83 ea 50 88 50 34 c6 81 1d 02 00 00 40 c6 81 17 02 00 00 00 5d c3 66 0f 1f 44 00 00 14 25 58 00 00 00

    Fix it by introducing ata_host->n_tags which is initialized to
    ATA_MAX_QUEUE - 1 in ata_host_init() for SAS controllers and set to
    scsi_host_template->can_queue in ata_host_register() for !SAS ones.
    As SAS hosts are never registered, this will give them the same
    ATA_MAX_QUEUE - 1 as before. Note that we can't use
    scsi_host->can_queue directly for SAS hosts anyway as they can go
    higher than the libata maximum.

    Signed-off-by: Tejun Heo
    Reported-by: Mike Qiu
    Reported-by: Jesse Brandeburg
    Reported-by: Peter Hurley
    Reported-by: Peter Zijlstra
    Tested-by: Alexey Kardashevskiy
    Fixes: 1871ee134b73 ("libata: support the ata host which implements a queue depth less than 32")
    Cc: Kevin Hao
    Cc: Dan Williams
    Signed-off-by: Greg Kroah-Hartman

    Tejun Heo
     
  • commit 1871ee134b73fb4cadab75752a7152ed2813c751 upstream.

    The sata on fsl mpc8315e is broken after the commit 8a4aeec8d2d6
    ("libata/ahci: accommodate tag ordered controllers"). The reason is
    that the ata controller on this SoC only implement a queue depth of
    16. When issuing the commands in tag order, all the commands in tag
    16 ~ 31 are mapped to tag 0 unconditionally and then causes the sata
    malfunction. It makes no senses to use a 32 queue in software while
    the hardware has less queue depth. So consider the queue depth
    implemented by the hardware when requesting a command tag.

    Fixes: 8a4aeec8d2d6 ("libata/ahci: accommodate tag ordered controllers")
    Signed-off-by: Kevin Hao
    Acked-by: Dan Williams
    Signed-off-by: Tejun Heo
    Signed-off-by: Greg Kroah-Hartman

    Kevin Hao
     
  • commit d45b3279a5a2252cafcd665bbf2db8c9b31ef783 upstream.

    There is no inherent reason why the last put of a tag structure must be
    the one for the Scsi_Host, as device model objects can be held for
    arbitrary periods. Merge blk_free_tags and __blk_free_tags into a single
    funtion that just release a references and get rid of the BUG() when the
    host reference wasn't the last.

    Signed-off-by: Christoph Hellwig
    Signed-off-by: Jens Axboe
    Signed-off-by: Greg Kroah-Hartman

    Christoph Hellwig
     
  • commit 3b3a1814d1703027f9867d0f5cbbfaf6c7482474 upstream.

    This patch provides the compat BLKZEROOUT ioctl. The argument is a pointer
    to two uint64_t values, so there is no need to translate it.

    Signed-off-by: Mikulas Patocka
    Acked-by: Martin K. Petersen
    Signed-off-by: Jens Axboe
    Signed-off-by: Greg Kroah-Hartman

    Mikulas Patocka
     
  • commit be6ae382dc153da51cf066c8dd523aa955f02531 upstream.

    When sysmem reservation occurs exactly at the end of an existing block
    that block is deleted, because it is incorrectly included in the range
    of memblocks to remove. Fix that by skipping such block.

    Signed-off-by: Max Filippov
    Signed-off-by: Greg Kroah-Hartman

    Max Filippov
     
  • commit 74adf83f5d7720925499b4938f930591f947b660 upstream.

    The big ACL switched nfs to use generic_listxattr, which calls all existing
    ->list handlers. Add a custom .listxattr implementation that only lists
    the ACLs if they actually are present on the given inode.

    Signed-off-by: Christoph Hellwig
    Reported-by: Philippe Troin
    Tested-by: Philippe Troin
    Fixes: 013cdf1088d7 (nfs: use generic posix ACL infrastructure ...)
    Signed-off-by: Trond Myklebust
    Signed-off-by: Greg Kroah-Hartman

    Christoph Hellwig
     
  • commit db4175ae2095634dbecd4c847da439f9c83e1b3b upstream.

    Only supported modulation for DVB-S is QPSK. Modulation parameter
    contains invalid value for DVB-S on some cases, which leads driver
    refusing tuning attempt. Due to that, hard code modulation to QPSK
    in case of DVB-S.

    Signed-off-by: Antti Palosaari
    Signed-off-by: Mauro Carvalho Chehab
    Signed-off-by: Greg Kroah-Hartman

    Antti Palosaari
     
  • commit 3445857b22eafb70a6ac258979e955b116bfd2c6 upstream.

    When the audio encoding is changed the driver calls hdpvr_set_audio
    with the current opt->audio_input value. However, that should have
    been opt->audio_input + 1. So changing the audio encoding inadvertently
    changes the input as well. This bug has always been there.

    The second bug was introduced in kernel 3.10 and that broke the
    default_audio_input module option handling: the audio encoding was
    never switched to AC3 if default_audio_input was set to 2 (SPDIF input).

    In addition, since starting with 3.10 the audio encoding is always set
    at the start the first bug now always happens when the driver is loaded.
    In the past this bug would only surface if the user would change the
    audio encoding after the driver was loaded.

    Also fixes a small trivial typo (bufffer -> buffer).

    Signed-off-by: Hans Verkuil
    Reported-by: Scott Doty
    Signed-off-by: Mauro Carvalho Chehab
    Signed-off-by: Greg Kroah-Hartman

    Hans Verkuil
     
  • commit 1cbbf90d0406913ad4b44194b07f4f41bde84e54 upstream.

    Tuner ID set into EEPROM is wrong in some cases, which causes driver
    to select wrong tuner profile. That leads device non-working. Fix
    issue by overriding known bad tuner IDs with suitable default value.

    Thanks to MX-NET Telekomunikace s.r.o. for providing non-working
    DTV stick, that I could fix the bug!

    Signed-off-by: Antti Palosaari
    Signed-off-by: Mauro Carvalho Chehab
    Signed-off-by: Greg Kroah-Hartman

    Antti Palosaari
     
  • commit f71920efb1066d71d74811e1dbed658173adf9bf upstream.

    Wrong value used in same cases for the aspect ratio.

    Signed-off-by: Rickard Strandqvist
    Acked-by: Lad, Prabhakar
    Signed-off-by: Hans Verkuil
    Signed-off-by: Mauro Carvalho Chehab
    Signed-off-by: Greg Kroah-Hartman

    Rickard Strandqvist
     
  • commit 4856fbd12d69965d3ab680c686222db93872728d upstream.

    The OMAP4 camera support depends on I2C and VIDEO_V4L2, both
    of which can be loadable modules. This causes build failures
    if we want the camera driver to be built-in.

    This can be solved by turning the option into "tristate",
    which unfortunately causes another problem, because the
    driver incorrectly calls a platform-internal interface
    for omap4_ctrl_pad_readl/omap4_ctrl_pad_writel.

    Instead, this patch just forbids the invalid configurations
    and ensures that the driver can only be built if all its
    dependencies are built-in.

    Signed-off-by: Arnd Bergmann
    Signed-off-by: Laurent Pinchart
    Signed-off-by: Mauro Carvalho Chehab
    Signed-off-by: Greg Kroah-Hartman

    Arnd Bergmann
     

28 Jul, 2014

18 commits

  • Greg Kroah-Hartman
     
  • commit a4b6cb735b25aa84a462a1985e3e43bebaf5beb4 upstream.

    This patch adds implementation of GET_THREAD_AREA ptrace request type. This
    is required by GDB to debug NPTL applications.

    Signed-off-by: Anton Kolesov
    Signed-off-by: Vineet Gupta
    Signed-off-by: Greg Kroah-Hartman

    Anton Kolesov
     
  • commit b738d764652dc5aab1c8939f637112981fce9e0e upstream.

    shrink_inactive_list() used to wait 0.1s to avoid congestion when all
    the pages that were isolated from the inactive list were dirty but not
    under active writeback. That makes no real sense, and apparently causes
    major interactivity issues under some loads since 3.11.

    The ostensible reason for it was to wait for kswapd to start writing
    pages, but that seems questionable as well, since the congestion wait
    code seems to trigger for kswapd itself as well. Also, the logic behind
    delaying anything when we haven't actually started writeback is not
    clear - it only delays actually starting that writeback.

    We'll still trigger the congestion waiting if

    (a) the process is kswapd, and we hit pages flagged for immediate
    reclaim

    (b) the process is not kswapd, and the zone backing dev writeback is
    actually congested.

    This probably needs to be revisited, but as it is this fixes a reported
    regression.

    Reported-by: Felipe Contreras
    Pinpointed-by: Hillf Danton
    Cc: Michal Hocko
    Cc: Andrew Morton
    Cc: Mel Gorman
    Signed-off-by: Linus Torvalds
    Signed-off-by: Greg Kroah-Hartman

    [mhocko@suse.cz: backport to 3.12 stable tree]
    Fixes: e2be15f6c3ee ('mm: vmscan: stall page reclaim and writeback pages based on dirty/writepage pages encountered')
    Reported-by: Felipe Contreras
    Pinpointed-by: Hillf Danton
    Cc: Michal Hocko
    Cc: Andrew Morton
    Cc: Mel Gorman
    Signed-off-by: Linus Torvalds
    Signed-off-by: Michal Hocko
    Signed-off-by: Greg Kroah-Hartman

    Linus Torvalds
     
  • commit dc271ee0d04d12d6bfabacbec803289a7072fbd9 upstream.

    Firmware folks seem say that this flag can make trouble.
    Drop it. The advantage of CTS to self is that it slightly
    reduces the cost of the protection, but make the protection
    less reliable.

    Signed-off-by: Emmanuel Grumbach
    Signed-off-by: Greg Kroah-Hartman

    Emmanuel Grumbach
     
  • commit 22970070e027cbbb9b2878f8f7c31d0d7f29e94d upstream.

    Add alias for FEC ethernet on i.MX to allow bootloaders (like U-Boot)
    patch-in the MAC address for FEC using this alias.

    Signed-off-by: Marek Vasut
    Signed-off-by: Shawn Guo
    Signed-off-by: Greg Kroah-Hartman

    Marek Vasut
     
  • commit 11d3d334af07408ce3a68860c40006ddcd343da5 upstream.

    The driver calls irq_alloc_domain_generic_chips() which creates a gc and
    adds it to gc_list. The driver later then calls irq_setup_generic_chip()
    which also initializes the gc and adds it to the gc_list() and this
    corrupts the list. Enable LIST_DEBUG and you see the kernel complain.
    This isn't required, irq_alloc_domain_generic_chips() did the init.

    Signed-off-by: Sebastian Andrzej Siewior
    Tested-by: Alan Tull
    Signed-off-by: Linus Walleij
    Signed-off-by: dann frazier
    Signed-off-by: Greg Kroah-Hartman

    Sebastian Andrzej Siewior
     
  • commit 263782c1c95bbddbb022dc092fd89a36bb8d5577 upstream.

    As of commit f8567a3845ac05bb28f3c1b478ef752762bd39ef it is now possible to
    have put_reqs_available() called from irq context. While put_reqs_available()
    is per cpu, it did not protect itself from interrupts on the same CPU. This
    lead to aio_complete() corrupting the available io requests count when run
    under a heavy O_DIRECT workloads as reported by Robert Elliott. Fix this by
    disabling irq updates around the per cpu batch updates of reqs_available.

    Many thanks to Robert and folks for testing and tracking this down.

    Reported-by: Robert Elliot
    Tested-by: Robert Elliot
    Signed-off-by: Benjamin LaHaise
    Cc: Jens Axboe , Christoph Hellwig
    Signed-off-by: Greg Kroah-Hartman

    Benjamin LaHaise
     
  • commit 652c1a05171695d21b84dd3a723606b50eeb80fd upstream.

    In commit f360d88a2efd, we advertise blocking multicast loopback to both
    kernel and userspace consumers, but don't allow kernel consumers (e.g IPoIB)
    to use it with their UD QPs. Fix that.

    Fixes: f360d88a2efd ("IB/mlx5: Add block multicast loopback support")
    Reported-by: Haggai Eran
    Signed-off-by: Eli Cohen
    Signed-off-by: Or Gerlitz
    Signed-off-by: Roland Dreier
    Signed-off-by: Greg Kroah-Hartman

    Or Gerlitz
     
  • commit c7fb93ec51d462ec3540a729ba446663c26a0505 upstream.

    The PE/COFF headers currently describe only the initialised-data
    portions of the image, and result in no space being allocated for the
    uninitialised-data portions. Consequently, the EFI boot stub will end
    up overwriting unexpected areas of memory, with unpredictable results.

    Fix by including a .bss section in the PE/COFF headers (functionally
    equivalent to the init_size field in the bzImage header).

    Signed-off-by: Michael Brown
    Cc: Thomas Bächler
    Cc: Josh Boyer
    Signed-off-by: Matt Fleming
    Signed-off-by: Greg Kroah-Hartman

    Michael Brown
     
  • commit b0ab99e7736af88b8ac1b7ae50ea287fffa2badc upstream.

    proc_sched_show_task() does:

    if (nr_switches)
    do_div(avg_atom, nr_switches);

    nr_switches is unsigned long and do_div truncates it to 32 bits, which
    means it can test non-zero on e.g. x86-64 and be truncated to zero for
    division.

    Fix the problem by using div64_ul() instead.

    As a side effect calculations of avg_atom for big nr_switches are now correct.

    Signed-off-by: Mateusz Guzik
    Signed-off-by: Peter Zijlstra
    Cc: Linus Torvalds
    Link: http://lkml.kernel.org/r/1402750809-31991-1-git-send-email-mguzik@redhat.com
    Signed-off-by: Ingo Molnar
    Signed-off-by: Greg Kroah-Hartman

    Mateusz Guzik
     
  • commit 4badad352a6bb202ec68afa7a574c0bb961e5ebc upstream.

    The optimistic spin code assumes regular stores and cmpxchg() play nice;
    this is found to not be true for at least: parisc, sparc32, tile32,
    metag-lock1, arc-!llsc and hexagon.

    There is further wreckage, but this in particular seemed easy to
    trigger, so blacklist this.

    Opt in for known good archs.

    Signed-off-by: Peter Zijlstra
    Reported-by: Mikulas Patocka
    Cc: David Miller
    Cc: Chris Metcalf
    Cc: James Bottomley
    Cc: Vineet Gupta
    Cc: Jason Low
    Cc: Waiman Long
    Cc: "James E.J. Bottomley"
    Cc: Paul McKenney
    Cc: John David Anglin
    Cc: James Hogan
    Cc: Linus Torvalds
    Cc: Davidlohr Bueso
    Cc: Benjamin Herrenschmidt
    Cc: Catalin Marinas
    Cc: Russell King
    Cc: Will Deacon
    Cc: linux-arm-kernel@lists.infradead.org
    Cc: linux-kernel@vger.kernel.org
    Cc: linuxppc-dev@lists.ozlabs.org
    Cc: sparclinux@vger.kernel.org
    Link: http://lkml.kernel.org/r/20140606175316.GV13930@laptop.programming.kicks-ass.net
    Signed-off-by: Ingo Molnar
    Signed-off-by: Greg Kroah-Hartman

    Peter Zijlstra
     
  • commit 4320f6b1d9db4ca912c5eb6ecb328b2e090e1586 upstream.

    The commit [247bc037: PM / Sleep: Mitigate race between the freezer
    and request_firmware()] introduced the finer state control, but it
    also leads to a new bug; for example, a bug report regarding the
    firmware loading of intel BT device at suspend/resume:
    https://bugzilla.novell.com/show_bug.cgi?id=873790

    The root cause seems to be a small window between the process resume
    and the clear of usermodehelper lock. The request_firmware() function
    checks the UMH lock and gives up when it's in UMH_DISABLE state. This
    is for avoiding the invalid f/w loading during suspend/resume phase.
    The problem is, however, that usermodehelper_enable() is called at the
    end of thaw_processes(). Thus, a thawed process in between can kick
    off the f/w loader code path (in this case, via btusb_setup_intel())
    even before the call of usermodehelper_enable(). Then
    usermodehelper_read_trylock() returns an error and request_firmware()
    spews WARN_ON() in the end.

    This oneliner patch fixes the issue just by setting to UMH_FREEZING
    state again before restarting tasks, so that the call of
    request_firmware() will be blocked until the end of this function
    instead of returning an error.

    Fixes: 247bc0374254 (PM / Sleep: Mitigate race between the freezer and request_firmware())
    Link: https://bugzilla.novell.com/show_bug.cgi?id=873790
    Signed-off-by: Takashi Iwai
    Signed-off-by: Rafael J. Wysocki
    Signed-off-by: Greg Kroah-Hartman

    Takashi Iwai
     
  • commit 6b54d54dea82ae214e4a45a503c4ef755a8ecee8 upstream.

    The status page is mapped to user processes and allows sharing the
    device state between the kernel and user processes. This state isn't
    getting initialized and thus intermittently causes problems. Namely,
    the user process can mistakenly think the user doorbell writes are
    disabled which causes SQ work requests to never get fetched by HW.

    Fixes: 05eb23893c2c ("cxgb4/iw_cxgb4: Doorbell Drop Avoidance Bug Fixes").
    Signed-off-by: Steve Wise
    Signed-off-by: Roland Dreier
    Signed-off-by: Greg Kroah-Hartman

    Steve Wise
     
  • commit 048e5a07f282c57815b3901d4a68a77fa131ce0a upstream.

    The block size for the dm-cache's data device must remained fixed for
    the life of the cache. Disallow any attempt to change the cache's data
    block size.

    Signed-off-by: Mike Snitzer
    Acked-by: Joe Thornber
    Signed-off-by: Greg Kroah-Hartman

    Mike Snitzer
     
  • commit 9aec8629ec829fc9403788cd959e05dd87988bd1 upstream.

    The block size for the thin-pool's data device must remained fixed for
    the life of the thin-pool. Disallow any attempt to change the
    thin-pool's data block size.

    It should be noted that attempting to change the data block size via
    thin-pool table reload will be ignored as a side-effect of the thin-pool
    handover that the thin-pool target does during thin-pool table reload.

    Here is an example outcome of attempting to load a thin-pool table that
    reduced the thin-pool's data block size from 1024K to 512K.

    Before:
    kernel: device-mapper: thin: 253:4: growing the data device from 204800 to 409600 blocks

    After:
    kernel: device-mapper: thin metadata: changing the data block size (from 2048 to 1024) is not supported
    kernel: device-mapper: table: 253:4: thin-pool: Error creating metadata object
    kernel: device-mapper: ioctl: error adding target to table

    Signed-off-by: Mike Snitzer
    Acked-by: Joe Thornber
    Signed-off-by: Greg Kroah-Hartman

    Mike Snitzer
     
  • commit 6938ad40cb97a52d88a763008935340729a4acc7 upstream.

    These two function's switch case lack the 'break' that make them always
    return error.

    Signed-off-by: Ted Juan
    Acked-by: Pekon Gupta
    Signed-off-by: Brian Norris
    Signed-off-by: Greg Kroah-Hartman

    Ted Juan
     
  • commit 79a8468747c5f95ed3d5ce8376a3e82e0c5857fc upstream.

    The expression entropy_count -= ibytes << (ENTROPY_SHIFT + 3) could
    actually increase entropy_count if during assignment of the unsigned
    expression on the RHS (mind the -=) we reduce the value modulo
    2^width(int) and assign it to entropy_count. Trinity found this.

    [ Commit modified by tytso to add an additional safety check for a
    negative entropy_count -- which should never happen, and to also add
    an additional paranoia check to prevent overly large count values to
    be passed into urandom_read(). ]

    Reported-by: Dave Jones
    Signed-off-by: Hannes Frederic Sowa
    Signed-off-by: Theodore Ts'o
    Signed-off-by: Greg Kroah-Hartman

    Hannes Frederic Sowa
     
  • commit 92c14bd9477a20a83144f08c0ca25b0308bf0730 upstream.

    This is only relevant to implementations with multiple clusters, where clusters
    have separate clock lines but all CPUs within a cluster share it.

    Consider a dual cluster platform with 2 cores per cluster. During suspend we
    start hot unplugging CPUs in order 1 to 3. When CPU2 is removed, policy->kobj
    would be moved to CPU3 and when CPU3 goes down we wouldn't free policy or its
    kobj as we want to retain permissions/values/etc.

    Now on resume, we will get CPU2 before CPU3 and will call __cpufreq_add_dev().
    We will recover the old policy and update policy->cpu from 3 to 2 from
    update_policy_cpu().

    But the kobj is still tied to CPU3 and isn't moved to CPU2. We wouldn't create a
    link for CPU2, but would try that for CPU3 while bringing it online. Which will
    report errors as CPU3 already has kobj assigned to it.

    This bug got introduced with commit 42f921a, which overlooked this scenario.

    To fix this, lets move kobj to the new policy->cpu while bringing first CPU of a
    cluster back. Also do a WARN_ON() if kobject_move failed, as we would reach here
    only for the first CPU of a non-boot cluster. And we can't recover from this
    situation, if kobject_move() fails.

    Fixes: 42f921a6f10c (cpufreq: remove sysfs files for CPUs which failed to come back after resume)
    Reported-and-tested-by: Bu Yitian
    Reported-by: Saravana Kannan
    Reviewed-by: Srivatsa S. Bhat
    Signed-off-by: Viresh Kumar
    Signed-off-by: Rafael J. Wysocki
    Signed-off-by: Greg Kroah-Hartman

    Viresh Kumar