Ubuntu 17.04 yayınlandı.

burak öztürk · 13 Nisan 2017 - 20:21:27

Ubuntu 17.04 hazır. Yayın takvimine uygun olarak planlandığı gibi zamanında yayınlanmış bulunuyor.

Neler yeni;

Linux Kernel 4.10
Libreoffice 5.3.1
Firefox 52.0.1
Chromium 57
Unity Shell 7.5.0
Gnome Shell 3.24
Plasma 5.9.4
.
Ubuntu'ya bir göz atmak ve fikir sahibi olmak için şurayı ziyaret edebilirsiniz; http://www.ubuntu-tr.net/tur/14.04/tr/index.html

İndirmek için bağlantılar:

Ubuntu: http://ftp.linux.org.tr/ubuntu-releases/zesty/
Ubuntu GNOME: http://cdimage.ubuntu.com/ubuntu-gnome/releases/zesty/release/
Ubuntu MATE: http://cdimage.ubuntu.com/ubuntu-mate/releases/zesty/
Xubuntu: http://cdimage.ubuntu.com/xubuntu/releases/zesty/
Kubuntu: http://cdimage.ubuntu.com/kubuntu/releases/zesty/
Lubuntu: http://cdimage.ubuntu.com/lubuntu/releases/zesty/
Ubuntu Studio: http://cdimage.ubuntu.com/ubuntustudio/releases/zesty/

Bigchefstarys · 13 Nisan 2017 - 20:34:02

Paylaşım için teşekkürler ben de öğlen saatlerin de görmüştüm ve bu konuda aklıma takılan soruları forumda sormak istiyordum ki konunuzu gördüm.

Linux kernel'in tam olarak ne manaya geldiğini ve ne işe yaradığını bilemiyorum. Bu yüzden spotify olsun atom olsun Discord Vb. bu gibi uygulamalarda yeni sürüm olduğu için tutarsızlık olma olasılığı varmıdır?

16.04'de yoğun şekilde çalışan 17.04'de hafifleme gibi bir şey yapabilirmi. Yani bilgisayarın çok yormasını engelleyebilir mi? yada tam tersi olabilir mi?

17.04 kullanıp gözlemleme yaptınız mı? Kullanım bakımından 16.04 ile kıyaslama yapabilirmisiniz iyi kötü.

teşekkürler.

lubuntu · 13 Nisan 2017 - 20:43:17

Ubuntu GNOME 17.04 sürümünden yazmaktayım. Kendime göre şekillendirdim v.s. sonuçta bu sefer olmuş. Tık ses gelmiyor laptoptan. Çalışması gerektiği gibi çalışıyor. Tabi burada kernel, gtk+ ve xorg'un da hakkını vermek lazım. Fan problemi yaşayan, intel ekran kartı sahibi arkadaşlara önerim bu sürüme geçmeleri fakat ek sürücülerden intel microcode'u pasif durumda bırakın, yararını göreceksiniz. Ayrıca Google Chrome şart gnome eklentileri indirebilmeniz için (Firefox desteği kalktı çünkü). Birde başlangıçta güncelleştirme ve driver, codec seçeneklerini açmayın, temiz kurulum gerçekleştirin.

Bigchefstarys · 13 Nisan 2017 - 20:45:33

Alıntı yapılan: lubuntu - 13 Nisan 2017 - 20:43:17
Ubuntu GNOME 17.04 sürümünden yazmaktayım. Kendime göre şekillendirdim v.s. sonuçta bu sefer olmuş. Tık ses gelmiyor laptoptan. Çalışması gerektiği gibi çalışıyor. Tabi burada kernel, gtk+ ve xorg'un da hakkını vermek lazım. Fan problemi yaşayan, intel ekran kartı sahibi arkadaşlara önerim bu sürüme geçmeleri fakat ek sürücülerden intel microcode'u pasif durumda bırakın, yararını göreceksiniz. Ayrıca Google Chrome şart gnome eklentileri indirebilmeniz için (Firefox desteği kalktı çünkü). Birde başlangıçta güncelleştirme ve driver, codec seçeneklerini açmayın, temiz kurulum gerçekleştirin.

Merhaba sizden bir konuda destek alabilirmiyim. ben gnome 16.04 kurmaya çalıştığım da Bios'un UEFİ olayında takıldım kaldım sistem hata düşüyordu format esnasında nitekim bu sorun 16.04 ubuntuda yaşanmadı sağlıklı bir şekilde format yaptı. UEFİ sorunu ile 17.04'de karşılaşabilirmiyim? Karşılaşırsam nasıl bir yol izlemeliyim?

lubuntu · 13 Nisan 2017 - 20:50:13

[mention=622839]@Yunus SENEM[/mention] Bunu denemeden bilemezsiniz ama sizden kaynaklı değilse problem sorun yaşama olasılığınız düşüktür. Ayrıca uefi kurulum şart değil sorun yaşarsanız normal kurulum yapın.

burak öztürk · 14 Nisan 2017 - 00:05:17

Alıntı yapılan: Yunus SENEM - 13 Nisan 2017 - 20:34:02
Paylaşım için teşekkürler ben de öğlen saatlerin de görmüştüm ve bu konuda aklıma takılan soruları forumda sormak istiyordum ki konunuzu gördüm.

Linux kernel'in tam olarak ne manaya geldiğini ve ne işe yaradığını bilemiyorum. Bu yüzden spotify olsun atom olsun Discord Vb. bu gibi uygulamalarda yeni sürüm olduğu için tutarsızlık olma olasılığı varmıdır?

16.04'de yoğun şekilde çalışan 17.04'de hafifleme gibi bir şey yapabilirmi. Yani bilgisayarın çok yormasını engelleyebilir mi? yada tam tersi olabilir mi?

17.04 kullanıp gözlemleme yaptınız mı? Kullanım bakımından 16.04 ile kıyaslama yapabilirmisiniz iyi kötü.

teşekkürler.

Çok fazla deneyemedim daha birkaç saat oldu kuralı. Eğer 16.04 ile sorunsuz ve memnun iseniz yeni sürümü kurmanız için pek neden yok. Linux işletim sisteminin çekirdeğidir. Kabaca donanım ile yazılım arasında iletişimi sağlar diyebiliriz. Yani bu bir arabanın motoru gibidir. Ubuntu da tıpkı Android gibi Linux çekrideğini kullanır.
Linux çekirdeğinin sürümü 17.04'te yüksek olabilir ama bu her şey değildir. Yani sürümü yüksek olunce hız yönünde fark asla yaşamazsınız. Hız farkı olsa ya da olmasa da bu milimliktir ve bunu siz fark edemezsiniz. Tek farkı mevcut kullandığımız yazılımların 16.04'te olanlara göre daha güncel olmasıdır.

lubuntu · 14 Nisan 2017 - 08:30:44

[mention=622862]@burak öztürk[/mention]Linux sadece çekirdektir, herhangi bir şeyin bir şeyi olarak tanımlanmaz! Donanım ile yazılım arasında iletişim sağlamaz, iletişimi sağlasınlar diye yer hazırlar. Ubuntu Linux ailesinden gelirken Android Unix-like ailesinden gelir. "Yani sürümü yüksek olunca hız yönünde fark asla yaşamazsınız" demişsin bu donanımdan donanıma farklılık gösterir, asla diyebilmek için kasıtlı olarak yavaşlatılması gereklidir (-ki böyle bir şey olmaz). Fark edilebilir düzeyde de hız artışı ya da yavaşlama görülebilir. Önceki sürümde göze yavaş gelen bu sürümde hızlı gelebilir neden olmasın? Tek farkı güncellik olması gerekmiyor, tasarım, işleyiş, uyumluluk gibi farklarda olabilir.

Bipolar_Disorder · 14 Nisan 2017 - 11:54:04

Çekirdeğin neler getirip neler getirmediğini anlamak için, Sürüm notlarına göz gezdirmek daha mantıklı * bir şey olucaktır.

Örnek vermek gerekirse, Linux 4.10.10 sürüm notlarına bakabilirisinz.

Kod Seç

commit e6925852d5b862bac749fab9c8d26491cda99e4e
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Wed Apr 12 12:43:04 2017 +0200

    Linux 4.10.10

commit e6c5fe2374cdfb4d2dce331d585b3f75665dad65
Author: Matjaz Hegedic <matjaz.hegedic@gmail.com>
Date:   Tue Apr 4 19:32:38 2017 +0000

    x86/reboot/quirks: Fix typo in ASUS EeeBook X205TA reboot quirk

    [ Upstream commit bba8376aea1dcbbe22bbda118c52abee317c7609 ]

    The reboot quirk for ASUS EeeBook X205TA contains a typo in
    DMI_PRODUCT_NAME, improperly referring to X205TAW instead of
    X205TA, which prevents the quirk from being triggered. The
    model X205TAW already has a reboot quirk of its own.

    This fix simply removes the inappropriate final letter W.

    Fixes: 90b28ded88dd ("x86/reboot/quirks: Add ASUS EeeBook X205TA reboot quirk")
    Signed-off-by: Matjaz Hegedic <matjaz.hegedic@gmail.com>
    Link: http://lkml.kernel.org/r/1489064417-7445-1-git-send-email-matjaz.hegedic@gmail.com
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a148ee8f715614fa097a85d90717c23f63ee852f
Author: Tobias Jakobi <tjakobi@math.uni-bielefeld.de>
Date:   Tue Apr 4 19:32:38 2017 +0000

    usb-storage: Add ignore-residue quirk for Initio INIC-3619

    [ Upstream commit d595259fbb7a7afed241b1afb2c4fe4b47de47fa ]

    This USB-SATA bridge chip is used in a StarTech enclosure for
    optical drives.

    Without the quirk MakeMKV fails during the key exchange with an
    installed BluRay drive:
    > Error 'Scsi error - ILLEGAL REQUEST:COPY PROTECTION KEY EXCHANGE FAILURE - KEY NOT ESTABLISHED'
    > occurred while issuing SCSI command AD010..080002400 to device 'SG:dev_11:2'

    Signed-off-by: Tobias Jakobi <tjakobi@math.uni-bielefeld.de>
    Acked-by: Alan Stern <stern@rowland.harvard.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 118b1ef49a330de0de1ccb3778ea2d2212b8fdbd
Author: Matjaz Hegedic <matjaz.hegedic@gmail.com>
Date:   Tue Apr 4 19:32:38 2017 +0000

    x86/reboot/quirks: Add ASUS EeeBook X205TA/W reboot quirk

    [ Upstream commit 3b3e78552d3077ec70d2640e629e07e3ab416a6a ]

    Without the parameter reboot=a, ASUS EeeBook X205TA/W will hang
    when it should reboot. This adds the appropriate quirk, thus
    fixing the problem.

    Signed-off-by: Matjaz Hegedic <matjaz.hegedic@gmail.com>
    Link: http://lkml.kernel.org/r/1488737804-20681-1-git-send-email-matjaz.hegedic@gmail.com
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2b0766deb0087ee7fd3103fe72a99e3a74b76541
Author: Matjaz Hegedic <matjaz.hegedic@gmail.com>
Date:   Tue Apr 4 19:32:37 2017 +0000

    x86/reboot/quirks: Add ASUS EeeBook X205TA reboot quirk

    [ Upstream commit 90b28ded88dda8bea82b4a86923e73ba0746d884 ]

    Without the parameter reboot=a, ASUS EeeBook X205TA will hang when it should reboot.

    This adds the appropriate quirk, thus fixing the problem.

    Signed-off-by: Matjaz Hegedic <matjaz.hegedic@gmail.com>
    Cc: Andy Lutomirski <luto@kernel.org>
    Cc: Borislav Petkov <bp@alien8.de>
    Cc: Brian Gerst <brgerst@gmail.com>
    Cc: Denys Vlasenko <dvlasenk@redhat.com>
    Cc: H. Peter Anvin <hpa@zytor.com>
    Cc: Josh Poimboeuf <jpoimboe@redhat.com>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3db435d09bc38cc25769bdcd5a64b96772e89d6e
Author: JoÃ£o Paulo Rechi Vita <jprvita@gmail.com>
Date:   Tue Apr 4 19:32:36 2017 +0000

    platform/x86: asus-wmi: Detect quirk_no_rfkill from the DSDT

    [ Upstream commit 71050ae7bf83e4d71a859257d11adc5de517073e ]

    Some Asus laptops that have an airplane-mode indicator LED, also have
    the WMI WLAN user bit set, and the following bits in their DSDT:

        Scope (_SB)
        {
          (...)
          Device (ATKD)
          {
            (...)
            Method (WMNB, 3, Serialized)
            {
              (...)
              If (LEqual (IIA0, 0x00010002))
              {
                OWGD (IIA1)
                Return (One)
              }
            }
          }
        }

    So when asus-wmi uses ASUS_WMI_DEVID_WLAN_LED (0x00010002) to store the
    wlan state, it drives the airplane-mode indicator LED (through the call
    to OWGD) in an inverted fashion: the LED is ON when airplane mode is OFF
    (since wlan is ON), and vice-versa.

    This commit skips registering RFKill switches at all for these laptops,
    to allow the asus-wireless driver to drive the airplane mode LED
    correctly through the ASHS ACPI device. Relying on the presence of ASHS
    and ASUS_WMI_DSTS_USER_BIT avoids adding DMI-based quirks for at least
    21 different laptops.

    Signed-off-by: JoÃ£o Paulo Rechi Vita <jprvita@endlessm.com>
    Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d0331c21a1a665f301529c47f5b626f135ab0f61
Author: Krzysztof Kozlowski <krzk@kernel.org>
Date:   Tue Apr 4 19:32:35 2017 +0000

    watchdog: s3c2410: Fix infinite interrupt in soft mode

    [ Upstream commit 0b445549ea6f91ffea78a976fe89b932db6e077a ]

    In soft (no-reboot) mode, the driver self-pings watchdog upon expiration
    of an interrupt.  However the interrupt itself was not cleared thus on
    first hit, the system enters infinite interrupt handling loop.

    On Odroid U3 (Exynos4412), when booted with s3c2410_wdt.soft_noboot=1
    argument the console is flooded:
            # killall -9 watchdog
            [   60.523760] s3c2410-wdt 10060000.watchdog: watchdog timer expired (irq)
            [   60.536744] s3c2410-wdt 10060000.watchdog: watchdog timer expired (irq)

    Fix this by writing something to the WTCLRINT register to clear the
    interrupt.  The register WTCLRINT however appeared in S3C6410 so a new
    watchdog quirk and flavor are needed.

    Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
    Reviewed-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 07371cd9ef21bc98ebd9aeb32f05dea8496c1c66
Author: Sinan Kaya <okaya@codeaurora.org>
Date:   Tue Apr 4 19:32:34 2017 +0000

    PCI: Add ACS quirk for Qualcomm QDF2400 and QDF2432

    [ Upstream commit 33be632b8443b6ac74aa293504f430604fb9abeb ]

    The Qualcomm QDF2xxx root ports don't advertise an ACS capability, but they
    do provide ACS-like features to disable peer transactions and validate bus
    numbers in requests.

    To be specific:
    * Hardware supports source validation but it will report the issue as
    Completer Abort instead of ACS Violation.

    * Hardware doesn't support peer-to-peer and each root port is a root
    complex with unique segment numbers.

    * It is not possible for one root port to pass traffic to the other root
    port.  All PCIe transactions are terminated inside the root port.

    Add an ACS quirk for the QDF2400 and QDF2432 products.

    [bhelgaas: changelog]
    Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Reviewed-by: Alex Williamson <alex.williamson@redhat.com>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e90d491bcf00487997addfc0d681004a3be69db1
Author: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Date:   Tue Apr 4 19:32:34 2017 +0000

    PCI: Sort the list of devices with D3 delay quirk by ID

    [ Upstream commit cd3e2eb8905d14fe28a2fc75362b8ecec16f0fb6 ]

    Sort the list of Intel devices that have no PCI D3 delay by ID.  Add a
    comment for group of devices that had not been marked yet.

    There is no functional change.

    Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9fd0dee948569432b72c0fa154537bc68b2019a2
Author: yangbo lu <yangbo.lu@nxp.com>
Date:   Tue Apr 4 19:32:33 2017 +0000

    mmc: sdhci-of-esdhc: remove default broken-cd for ARM

    [ Upstream commit e9acc77dd046b22c7ebf70e35f68968978445f8b ]

    Initially all QorIQ platforms were PowerPC architecture and they didn't
    support card detection except several platforms. The driver added the
    quirk SDHCI_QUIRK_BROKEN_CARD_DETECTION as default and this made broken-cd
    property in dts node didn't work. Now QorIQ platform turns to ARM
    architecture and most of them could support card detection. However it's
    a large number of dts trees that need to be fixed with broken-cd if we
    remove the default SDHCI_QUIRK_BROKEN_CARD_DETECTION in driver. And the
    users don't want to see this. So this patch is to remove this default
    quirk just for ARM and keep it for PowerPC.(Note, QorIQ PowerPC platform
    only has big-endian eSDHC while QorIQ ARM platform has big-endian or
    little-endian eSDHC) This makes broken-cd property work again for ARM.

    Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com>
    Acked-by: Adrian Hunter <adrian.hunter@intel.com>
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8f24ffc2f9a062a12dbde35dca0ed167758a908c
Author: Dongdong Liu <liudongdong3@huawei.com>
Date:   Tue Apr 4 19:32:33 2017 +0000

    PCI: Disable MSI for HiSilicon Hip06/Hip07 Root Ports

    [ Upstream commit 72f2ff0deb870145a5a2d24cd75b4f9936159a62 ]

    The PCIe Root Port in Hip06/Hip07 SoCs advertises an MSI capability, but it
    cannot generate MSIs.  It can transfer MSI/MSI-X from downstream devices,
    but does not support MSI/MSI-X itself.

    Add a quirk to prevent use of MSI/MSI-X by the Root Port.

    [bhelgaas: changelog, sort vendor ID #define, drop device ID #define]
    Signed-off-by: Dongdong Liu <liudongdong3@huawei.com>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Reviewed-by: Gabriele Paoloni <gabriele.paoloni@huawei.com>
    Reviewed-by: Zhou Wang <wangzhou1@hisilicon.com>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f2d9c08fc9b28c050f21e0a3e22d92ed6eaa5bf5
Author: Jon Mason <jon.mason@broadcom.com>
Date:   Tue Apr 4 19:32:33 2017 +0000

    PCI: Add Broadcom Northstar2 PAXC quirk for device class and MPSS

    [ Upstream commit ce709f86501a013e941e9986cb072eae375ddf3e ]

    The Broadcom Northstar2 SoC has a number of quirks for the PAXC
    (internal/fake) PCI bus.  Specifically, the PCI config space is shared
    between the root port and the first PF (ie., PF0), and a number of fields
    are tied to zero (thus preventing them from being set).  These cannot be
    "fixed" in device firmware, so we must fix them with a quirk.

    Signed-off-by: Jon Mason <jon.mason@broadcom.com>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0755d2b5fe9207c36a24342a39daf0f716940780
Author: Will Deacon <will.deacon@arm.com>
Date:   Tue Apr 4 19:32:32 2017 +0000

    ARM: smccc: Update HVC comment to describe new quirk parameter

    [ Upstream commit 3046ec674d441562c6bb3e4284cd866743042ef3 ]

    Commit 680a0873e193 ("arm: kernel: Add SMC structure parameter") added
    a new "quirk" parameter to the SMC and HVC SMCCC backends, but only
    updated the comment for the SMC version. This patch adds the new
    paramater to the comment describing the HVC version too.

    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7dd05d3661488c7aee4f756133c8edfcf2d168e9
Author: Andy Gross <andy.gross@linaro.org>
Date:   Tue Apr 4 19:32:32 2017 +0000

    firmware: qcom: scm: Fix interrupted SCM calls

    [ Upstream commit 82bcd087029f6056506ea929f11af02622230901 ]

    This patch adds a Qualcomm specific quirk to the arm_smccc_smc call.

    On Qualcomm ARM64 platforms, the SMC call can return before it has
    completed.  If this occurs, the call can be restarted, but it requires
    using the returned session ID value from the interrupted SMC call.

    The quirk stores off the session ID from the interrupted call in the
    quirk structure so that it can be used by the caller.

    This patch folds in a fix given by Sricharan R:
    https://lkml.org/lkml/2016/9/28/272

    Signed-off-by: Andy Gross <andy.gross@linaro.org>
    Reviewed-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cc9b9deb6197c51ed3d77f458377fc5ef930d953
Author: Andy Gross <andy.gross@linaro.org>
Date:   Tue Apr 4 19:32:31 2017 +0000

    arm: kernel: Add SMC structure parameter

    [ Upstream commit 680a0873e193bae666439f4b5e32c758e68f114c ]

    This patch adds a quirk parameter to the arm_smccc_(smc/hvc) calls.
    The quirk structure allows for specialized SMC operations due to SoC
    specific requirements.  The current arm_smccc_(smc/hvc) is renamed and
    macros are used instead to specify the standard arm_smccc_(smc/hvc) or
    the arm_smccc_(smc/hvc)_quirk function.

    This patch and partial implementation was suggested by Will Deacon.

    Signed-off-by: Andy Gross <andy.gross@linaro.org>
    Reviewed-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2dca786b85e236f84410c0421132e77b66aa9fd5
Author: Ping Cheng <pinglinux@gmail.com>
Date:   Tue Apr 4 19:32:31 2017 +0000

    HID: wacom: don't apply generic settings to old devices

    [ Upstream commit e7deb1570a527d3c74be4e21a72b1b459605c501 ]

    Non-generic devices have numbered_buttons set for both pen and
    touch interfaces by default. The actual number of buttons on the
    interface is normally manually decided later, which is different
    from what those HID generic devices are processed, where number
    of buttons are directly retrieved from HID descriptors.

    This patch adds the missed HID_GENERIC check and moves the statement
    to wacom_setup_pad_input_capabilities since it's not a quirk anymore.

    Signed-off-by: Ping Cheng <ping.cheng@wacom.com>
    Reviewed-by: Jason Gerecke <jason.gerecke@wacom.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6ac0617424d43e1c5cff654e73dbc333065b33f9
Author: MylÃ¨ne Josserand <mylene.josserand@free-electrons.com>
Date:   Tue Apr 4 19:32:30 2017 +0000

    ASoC: sun4i-i2s: Add quirks to handle a31 compatible

    [ Upstream commit 2ad6f30de7087515a0bc2a718fca6681a57739a0 ]

    Some SoCs have a reset line that must be asserted/deasserted.
    This patch adds a quirk to handle the new compatible
    "allwinner,sun6i-a31-i2s" which will deassert the reset
    line on probe function and assert it on remove's one.

    This new compatible is useful in case of A33 codec driver, for example.

    Signed-off-by: MylÃ¨ne Josserand <mylene.josserand@free-electrons.com>
    Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ab0b1f481fa986605fa99c215b3d739755f65d0f
Author: Zhang Rui <rui.zhang@intel.com>
Date:   Tue Apr 4 19:32:29 2017 +0000

    ACPI: save NVS memory for Lenovo G50-45

    [ Upstream commit cbc00c1310d34139a63946482b40a6b261a03fb9 ]

    In commit 821d6f0359b0 (ACPI / sleep: Do not save NVS for new machines to
    accelerate S3), to optimize S3 suspend/resume speed, code is introduced
    to ignore NVS memory saving during S3 for all the platforms later than
    2012.

    But, Lenovo G50-45, a platform released in 2015, still needs NVS memory
    saving during S3. A quirk is introduced for this platform.

    Link: https://bugzilla.kernel.org/show_bug.cgi?id=189431
    Tested-by: Przemek <soprwa@gmail.com>
    Signed-off-by: Zhang Rui <rui.zhang@intel.com>
    [ rjw: Drop unnecessary code ]
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 36426b3a31dcc8ef8064c2797b7f7816584e945a
Author: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Date:   Tue Apr 4 19:32:29 2017 +0000

    ASoC: Intel: cht_bsw_rt5645: add Baytrail MCLK support

    [ Upstream commit a50477e55fff69e1028f25624ee9fc9182d59b1f ]

    The existing code assumes a 19.2 MHz MCLK as the default
    hardware configuration. This is valid for CherryTrail but
    not for Baytrail.

    Add explicit MCLK configuration to set the 19.2 clock on/off
    depending on DAPM events.

    This is a prerequisite step to enable devices with Baytrail
    and RT5645 such as Asus X205TA

    Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bdbe9135ead6d3a8c5400949f190012536444a1f
Author: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Date:   Tue Apr 4 19:32:29 2017 +0000

    ASoC: Intel: cht_bsw_rt5645: harden ACPI device detection

    [ Upstream commit 42648c2270ca0c96935dfc5d0f5c4f8d2406cf75 ]

    Fix classic issue of having multiple codecs listed in DSDT
    but a single one actually enabled. The previous code did
    not handle such errors and could also lead to uninitalized
    configurations

    Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 88f1372e28b2f32bfb363f236af586f0ae798a7a
Author: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Date:   Tue Apr 4 19:32:28 2017 +0000

    ASoC: Intel: Baytrail: add quirk for Lenovo Thinkpad 10

    [ Upstream commit fd0138dc5d17c636477b371d99265c406437c583 ]

    the BIOS reports this codec as RT5640 but it's a rt5670. Use the
    quirk mechanism to use the cht_bsw_rt5672 machine driver

    Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 770049fddd84c9069eb4c27836d87266674c1e60
Author: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Date:   Tue Apr 4 19:32:28 2017 +0000

    ASoC: codecs: rt5670: add quirk for Lenovo Thinkpad 10

    [ Upstream commit 93ffeaa8ee3f10a0628ad135b552a2497e0bef2c ]

    the BIOS incorrectly reports this codec as 5640 but it is
    really a rt5670

    Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8d5dd97f55563634ad830ea47c709bc96606ad65
Author: Lv Zheng <lv.zheng@intel.com>
Date:   Tue Apr 4 19:32:27 2017 +0000

    ACPI / button: Change default behavior to lid_init_state=open

    [ Upstream commit 77e9a4aa9de10cc1418bf9a892366988802a8025 ]

    More and more platforms need the button.lid_init_state=open quirk. This
    patch sets it the default behavior.

    If a platform doesn't send lid open event or lid open event is lost due to
    the underlying system problems, then we can compare various combinations:
    1. systemd/acpid is used to suspend system or not, systemd has a special
       logic forcing open event after resuming;
    2. _LID returns a cached value or not.

    The result is as follows:

     1. lid_init_state=method
       1. cached
          1. resumed by lid:
             (x) event=close
             (x) systemd=suspends again
             (x) acpid=suspends again
             (x) state=close
          2. resumed by other:
             (o) event=close
             (x) systemd=suspends again
             (x) acpid=suspends again
             (o) state=close
       2. non-cached
          1. resumed by lid:
             (o) event=open
             (o) systemd=resumes
             (o) acpid=resumes
             (o) state=open
          2. resumed by other:
             (o) event=close
             (x) systemd=suspends again
             (x) acpid=suspends again
             (o) state=close
     2. lid_init_state=open
       1. cached
          1. resumed by lid:
             (o) event=open
             (o) systemd=resumes
             (o) acpid=resumes
             (x) state=close
          2. resumed by other:
             (x) event=open
             (o) systemd=resumes
             (o) acpid=resumes
             (o) state=close
       2. non-cached
          1. resumed by lid:
             (o) event=open
             (o) systemd=resumes
             (o) acpid=resumes
             (o) state=open
          2. resumed by other:
             (x) event=open
             (o) systemd=resumes
             (o) acpid=resumes
             (o) state=close
     3. lid_init_state=ignore
       1. cached
          1. resumed by lid:
             (o) event=none
             (x) systemd=suspends again
             (o) acpid=resumes
             (x) state=close
          2. resumed by other:
             (o) event=none
             (x) systemd=suspends again
             (o) acpid=resumes
             (o) state=close
       2. non-cached
          1. resumed by lid:
             (o) event=none
             (x) systemd=suspends again
             (o) acpid=resumes
             (o) state=open
          2. resumed by other:
             (o) event=none
             (x) systemd=suspends again
             (o) acpid=resumes
             (o) state=close

    As a conclusion:
     1. With systemd changed, lid_init_state=ignore has only one problem and the
        problem comes from an underlying issue, not userspace and kernel lid
        handling.
     2. Without systemd changed, lid_init_state=open can be the default
        behavior as the pass ratio is not much worse than lid_init_state=ignore.
     3. lid_init_state=method is buggy, we can have a separate patch to make it
        deprectated.

    Link: https://bugzilla.kernel.org/show_bug.cgi?id=187271
    Signed-off-by: Lv Zheng <lv.zheng@intel.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 53a898c2dc3bf12e1454011b4e438738a1c47e96
Author: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Date:   Tue Apr 4 19:32:27 2017 +0000

    sata: ahci-da850: implement a workaround for the softreset quirk

    [ Upstream commit f4d435f3265661d04e5290a0a0450e3a38898128 ]

    There's an issue with the da850 SATA controller: if port multiplier
    support is compiled in, but we're connecting the drive directly to
    the SATA port on the board, the drive can't be detected.

    To make SATA work on the da850-lcdk board: first try to softreset
    with pmp - if the operation fails with -EBUSY, retry without pmp.

    Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
    Acked-by: Tejun Heo <tj@kernel.org>
    Signed-off-by: Sekhar Nori <nsekhar@ti.com>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fcfd2ac4abfbeddaec28499481647b4db35bede2
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Tue Apr 4 19:32:26 2017 +0000

    PCI: xgene: Fix double free on init error

    [ Upstream commit 1ded56df3247d358390ae6dc09ccee620262ac5f ]

    The "port" variable was allocated with devm_kzalloc() so if we free it with
    kfree() it will be freed twice.  Also I changed it to propogate the error
    from devm_ioremap_resource() instead of returning -ENOMEM.

    Fixes: c5d460396100 ("PCI: Add MCFG quirks for X-Gene host controller")
    Also-posted-by: Shawn Lin <shawn.lin@rock-chips.com>
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Acked-by: Tanmay Inamdar <tinamdar@apm.com>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c259b9b74ebcaa9d9379d03b86eca20df3fb1e95
Author: Alex Williamson <alex.williamson@redhat.com>
Date:   Tue Apr 4 19:32:26 2017 +0000

    PCI: Add ACS quirk for Intel Union Point

    [ Upstream commit 7184f5b451cf3dc61de79091d235b5d2bba2782d ]

    Intel 200-series chipsets have the same errata as 100-series: the ACS
    capability doesn't follow the PCIe spec, the capability and control
    registers are dwords rather than words.  Add PCIe root port device IDs to
    existing quirk.

    Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8a4b2d4ba49c44b15bb25c35b83b753350504730
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Tue Apr 4 19:32:25 2017 +0000

    drm/mga: remove device_is_agp callback

    [ Upstream commit 858b2c1bf820ebfba89c5e2867ab882bdb5b2f5a ]

    It's only for a device quirk, and we might as well do that in the load
    callback.

    Acked-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
    Link: http://patchwork.freedesktop.org/patch/msgid/20170125062657.19270-10-daniel.vetter@ffwll.ch
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f08ae685954ef3fa4642e36959f04cc45338216e
Author: Felipe Balbi <felipe.balbi@linux.intel.com>
Date:   Tue Apr 4 19:32:25 2017 +0000

    usb: dwc3: host: pass quirk-broken-port-ped property for known broken revisions

    [ Upstream commit e42a5dbb8a3d14f5a35bffa3bf7dcb87883f767a ]

    dwc3 revisions <=3.00a have a limitation where Port Disable command
    doesn't work. Set the quirk-broken-port-ped property for such
    controllers so XHCI core can do the necessary workaround.

    [rogerq@ti.com] Updated code from platform data to device property.

    Signed-off-by: Roger Quadros <rogerq@ti.com>
    Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 41d6d9750ba33bc6620d173a355be2aed6e53d18
Author: Felipe Balbi <balbi@ti.com>
Date:   Tue Apr 4 19:32:24 2017 +0000

    usb: host: xhci-plat: enable BROKEN_PED quirk if platform requested

    [ Upstream commit 21939f003ad09355d9c975735750bb22aa37d8de ]

    In case 'quirk-broken-port-ped' property is passed in via device property,
    we should enable the corresponding BROKEN_PED quirk flag for XHCI core.

    [rogerq@ti.com] Updated code from platform data to device property
    and added DT binding.

    Signed-off-by: Felipe Balbi <balbi@ti.com>
    Signed-off-by: Roger Quadros <rogerq@ti.com>
    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9763fee4c38dcc8d9e8d06cf081dd55b5dc18658
Author: Felipe Balbi <balbi@ti.com>
Date:   Tue Apr 4 19:32:24 2017 +0000

    usb: xhci: add quirk flag for broken PED bits

    [ Upstream commit 41135de1e7fd14c6fcb9158404ba5c8fb97bf259 ]

    Some devices from Texas Instruments [1] suffer from
    a silicon bug where Port Enabled/Disabled bit
    should not be used to silence an erroneous device.

    The bug is so that if port is disabled with PED
    bit, an IRQ for device removal (or attachment)
    will never fire.

    Just for the sake of completeness, the actual
    problem lies with SNPS USB IP and this affects
    all known versions up to 3.00a. A separate
    patch will be added to dwc3 to enabled this
    quirk flag if version is <= 3.00a.

    [1] - AM572x Silicon Errata http://www.ti.com/lit/er/sprz429j/sprz429j.pdf
    Section i896â€" USB xHCI Port Disable Feature Does Not Work

    Signed-off-by: Felipe Balbi <balbi@ti.com>
    Signed-off-by: Roger Quadros <rogerq@ti.com>
    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit afdb6b99f54e9e71c6805d95118257a1ec2d2fd4
Author: Vignesh R <vigneshr@ti.com>
Date:   Tue Apr 4 19:32:22 2017 +0000

    serial: 8250_omap: Add OMAP_DMA_TX_KICK quirk for AM437x

    [ Upstream commit b6ffcf21082300519bc4f9c3d24f61207cc9eae4 ]

    UART uses as EDMA as dma engine on AM437x SoC and therefore, requires
    OMAP_DMA_TX_KICK quirk just like AM33xx. So, enable OMAP_DMA_TX_KICK
    quirk for AM437x platform as well. While at that, drop use of
    of_machine_is_compatible() and instead pass quirks via device data.

    Signed-off-by: Vignesh R <vigneshr@ti.com>
    Acked-by: Tony Lindgren <tony@atomide.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 99b4f57bffe5f50b399d3177aefeeea8f88c091b
Author: Stephen Boyd <stephen.boyd@linaro.org>
Date:   Tue Apr 4 19:32:21 2017 +0000

    usb: chipidea: msm: Rely on core to override AHBBURST

    [ Upstream commit dd3749099cfa2c80039193c438b90f3160eaf7f9 ]

    The core framework already handles setting this parameter with a
    platform quirk. Add the appropriate flag so that we always set
    AHBBURST to 0. Technically DT should be doing this, but we always
    do it for msm chipidea devices so setting the flag in the driver
    works just as well. If the burst needs to be anything besides 0,
    we expect the 'ahb-burst-config' dts property to be present.

    Acked-by: Peter Chen <peter.chen@nxp.com>
    Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Stephen Boyd <stephen.boyd@linaro.org>
    Signed-off-by: Peter Chen <peter.chen@nxp.com>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f576c28172a3b4d20b07de6c44381aca4a362367
Author: youling257 <youling257@gmail.com>
Date:   Tue Apr 4 19:32:19 2017 +0000

    ASoC: Intel: bytcr_rt5640: quirks for Insyde devices

    [ Upstream commit 571800487837263e914ef68681e4ad6a57d49c7f ]

    There are literally dozens of Insyde devices with a different
    name but with the same audio routing. Use a generic quirk to
    match on vendor name only to avoid recurring edits of the
    same thing.

    Signed-off-by: youling257 <youling257@gmail.com>
    Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 24fdd3f90f4cbce03f155e63d83fc154220b4fc5
Author: Paulo Zanoni <paulo.r.zanoni@intel.com>
Date:   Tue Apr 4 19:32:19 2017 +0000

    drm/i915: actually drive the BDW reserved IDs

    [ Upstream commit 98b2f01c8dfc8922a2af1fe82a1c40cac4911634 ]

    Back in 2014, commit fb7023e0e248 ("drm/i915: BDW: Adding Reserved PCI
    IDs.") added the reserved PCI IDs in order to try to make sure we had
    working drivers in case we ever released products using these IDs
    (since we had instances of this type of problem in the past). The
    problem is that the patch only touched the macros used by
    early-quirks.c and by the user space components that rely on
    i915_pciids.h, it didn't touch the macros used by i915_pci.c. So we
    correctly handled the stolen memory for these theoretical IDs, but we
    didn't actually drive the devices from i915.ko.

    So this patch fixes the original commit by actually making i915.ko
    drive these IDs, which was the goal. There's no information on what
    would be the GT count on these IDs, so we just go with the safer
    intel_broadwell_info, at the risk of ignoring a possibly inexistent
    BSD2_RING.

    I did some checking, and it seems that these IDs are driven by
    intel-gpu-tools, xf86-video-intel and libdrm (since they contain old
    copies of i915_pciids.h), but they are not checked by mesa.

    The alternative to this patch would be to just assume we're actually
    never going to use these IDs, and then remove them from our ID lists
    and make sure our user space components sync the latest i915_pciids.h
    copy. I'm fine with either approaches, as long as we make sure that
    every component tries to drive the same list of PCI IDs.

    Fixes: fb7023e0e248 ("drm/i915: BDW: Adding Reserved PCI IDs.")
    Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
    Cc: Ben Widawsky <ben@bwidawsk.net>
    Cc: Jani Nikula <jani.nikula@intel.com>
    Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
    Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
    Link: http://patchwork.freedesktop.org/patch/msgid/1483473860-17644-3-git-send-email-paulo.r.zanoni@intel.com
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0325b5e1b637161dd9b4b132d058b6527510badd
Author: Paulo Zanoni <paulo.r.zanoni@intel.com>
Date:   Tue Apr 4 19:32:19 2017 +0000

    drm/i915: more .is_mobile cleanups for BDW

    [ Upstream commit 0784bc624ae9be4269f8129572ee164ca680ca7c ]

    Commit 8d9c20e1d1e3 ("drm/i915: Remove .is_mobile field from platform
    struct") removed mobile vs desktop differences for HSW+, but forgot
    the Broadwell reserved IDs, so do it now.

    It's interesting to notice that these IDs are used by early-quirks.c
    but are *not* used by i915_pci.c.

    Cc: Carlos Santa <carlos.santa@intel.com>
    Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
    Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
    Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
    Link: http://patchwork.freedesktop.org/patch/msgid/1483473860-17644-2-git-send-email-paulo.r.zanoni@intel.com
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bb4c89250bcc466c19d781111e2a74329871a1d2
Author: Paulo Zanoni <paulo.r.zanoni@intel.com>
Date:   Tue Apr 4 19:32:18 2017 +0000

    drm/i915: fix INTEL_BDW_IDS definition

    [ Upstream commit 7fbd995ce4241e98d30859405504c3fb279c4ccb ]

    Remove duplicated IDs from the list. Currently, this definition is
    only used by early-quirks.c. From my understanding of the code, having
    duplicated IDs shouldn't be causing any bugs.

    Fixes: 8d9c20e1d1e3 ("drm/i915: Remove .is_mobile field from platform struct")
    Cc: Carlos Santa <carlos.santa@intel.com>
    Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
    Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
    Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
    Link: http://patchwork.freedesktop.org/patch/msgid/1483473860-17644-1-git-send-email-paulo.r.zanoni@intel.com
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d7f19357fe651ada1a00324823f791dad81dec80
Author: Jani Nikula <jani.nikula@intel.com>
Date:   Tue Apr 4 19:32:18 2017 +0000

    drm/edid: constify edid quirk list

    [ Upstream commit 23c4cfbdab494568600ae6073a2bf02be4b10f4e ]

    No reason not to be const.

    Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Signed-off-by: Jani Nikula <jani.nikula@intel.com>
    Link: http://patchwork.freedesktop.org/patch/msgid/1482923186-22430-1-git-send-email-jani.nikula@intel.com
    Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b04940e26f100c7d19fc0b5cab0210d4d924b002
Author: Paolo Bonzini <pbonzini@redhat.com>
Date:   Tue Jan 24 11:56:21 2017 +0100

    kvm: fix page struct leak in handle_vmon

    commit 06ce521af9558814b8606c0476c54497cf83a653 upstream.

    handle_vmon gets a reference on VMXON region page,
    but does not release it. Release the reference.

    Found by syzkaller; based on a patch by Dmitry.

    Reported-by: Dmitry Vyukov <dvyukov@google.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Cc: "Charles (Chas) Williams" <ciwillia@brocade.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit af72916015013680b25776eb43deafb9da37fbb0
Author: Jason A. Donenfeld <Jason@zx2c4.com>
Date:   Fri Jan 6 19:32:01 2017 +0100

    random: use chacha20 for get_random_int/long

    commit f5b98461cb8167ba362ad9f74c41d126b7becea7 upstream.

    Now that our crng uses chacha20, we can rely on its speedy
    characteristics for replacing MD5, while simultaneously achieving a
    higher security guarantee. Before the idea was to use these functions if
    you wanted random integers that aren't stupidly insecure but aren't
    necessarily secure either, a vague gray zone, that hopefully was "good
    enough" for its users. With chacha20, we can strengthen this claim,
    since either we're using an rdrand-like instruction, or we're using the
    same crng as /dev/urandom. And it's faster than what was before.

    We could have chosen to replace this with a SipHash-derived function,
    which might be slightly faster, but at the cost of having yet another
    RNG construction in the kernel. By moving to chacha20, we have a single
    RNG to analyze and verify, and we also already get good performance
    improvements on all platforms.

    Implementation-wise, rather than use a generic buffer for both
    get_random_int/long and memcpy based on the size needs, we use a
    specific buffer for 32-bit reads and for 64-bit reads. This way, we're
    guaranteed to always have aligned accesses on all platforms. While
    slightly more verbose in C, the assembly this generates is a lot
    simpler than otherwise.

    Finally, on 32-bit platforms where longs and ints are the same size,
    we simply alias get_random_int to get_random_long.

    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Suggested-by: Theodore Ts'o <tytso@mit.edu>
    Cc: Theodore Ts'o <tytso@mit.edu>
    Cc: Hannes Frederic Sowa <hannes@stressinduktion.org>
    Cc: Andy Lutomirski <luto@amacapital.net>
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d57c764a703b867a520a171a3430514bf51e71e4
Author: Chris Salls <salls@cs.ucsb.edu>
Date:   Fri Apr 7 23:48:11 2017 -0700

    mm/mempolicy.c: fix error handling in set_mempolicy and mbind.

    commit cf01fb9985e8deb25ccf0ea54d916b8871ae0e62 upstream.

    In the case that compat_get_bitmap fails we do not want to copy the
    bitmap to the user as it will contain uninitialized stack data and leak
    sensitive data.

    Signed-off-by: Chris Salls <salls@cs.ucsb.edu>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 596c2d180a9651b90b17653f48f4e6160e9808e9
Author: Johan Hovold <johan@kernel.org>
Date:   Mon Apr 3 15:53:34 2017 +0200

    Documentation: stable-kernel-rules: fix stable-tag format

    commit cf903e9d3a97f89b224d2d07be37c0f160db8192 upstream.

    A patch documenting how to specify which kernels a particular fix should
    be backported to (seemingly) inadvertently added a minus sign after the
    kernel version. This particular stable-tag format had never been used
    prior to this patch, and was neither present when the patch in question
    was first submitted (it was added in v2 without any comment).

    Drop the minus sign to avoid any confusion.

    Fixes: fdc81b7910ad ("stable_kernel_rules: Add clause about specification of kernel versions to patch.")
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 813e1ac7259b266bc84f89dee6f9268e68255dfd
Author: Janusz Dziedzic <januszx.dziedzic@intel.com>
Date:   Mon Mar 13 14:11:32 2017 +0200

    usb: dwc3: gadget: delay unmap of bounced requests

    commit de288e36fe33f7e06fa272bc8e2f85aa386d99aa upstream.

    In the case of bounced ep0 requests, we must delay DMA operation until
    after ->complete() otherwise we might overwrite contents of req->buf.

    This caused problems with RNDIS gadget.

    Signed-off-by: Janusz Dziedzic <januszx.dziedzic@intel.com>
    Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5e87a005ff574f9f580a8533193205331c135a74
Author: Changbin Du <changbin.du@intel.com>
Date:   Thu Mar 16 09:45:09 2017 +0800

    drm/i915/kvmgt: fix suspicious rcu dereference usage

    commit 5180edc2421117766fcb9c2d2dc6bfaeefdeb709 upstream.

    The srcu read lock must be held while accessing kvm memslots.
    This patch fix below warning for function kvmgt_rw_gpa().

    [  165.345093] [ ERR: suspicious RCU usage.  ]
    [  165.416538] Call Trace:
    [  165.418989]  dump_stack+0x85/0xc2
    [  165.422310]  lockdep_rcu_suspicious+0xd7/0x110
    [  165.426769]  kvm_read_guest_page+0x195/0x1b0 [kvm]
    [  165.431574]  kvm_read_guest+0x50/0x90 [kvm]
    [  165.440492]  kvmgt_rw_gpa+0x43/0xa0 [kvmgt]
    [  165.444683]  kvmgt_read_gpa+0x11/0x20 [kvmgt]
    [  165.449061]  gtt_get_entry64+0x4d/0xc0 [i915]
    [  165.453438]  ppgtt_populate_shadow_page_by_guest_entry+0x380/0xdc0 [i915]
    [  165.460254]  shadow_mm+0xd1/0x460 [i915]
    [  165.472488]  intel_vgpu_create_mm+0x1ab/0x210 [i915]
    [  165.477472]  intel_vgpu_g2v_create_ppgtt_mm+0x5f/0xc0 [i915]
    [  165.483154]  pvinfo_mmio_write+0x19b/0x1d0 [i915]
    [  165.499068]  intel_vgpu_emulate_mmio_write+0x3f9/0x600 [i915]
    [  165.504827]  intel_vgpu_rw+0x114/0x150 [kvmgt]
    [  165.509281]  intel_vgpu_write+0x16f/0x1a0 [kvmgt]
    [  165.513993]  vfio_mdev_write+0x20/0x30 [vfio_mdev]
    [  165.518793]  vfio_device_fops_write+0x24/0x30 [vfio]
    [  165.523770]  __vfs_write+0x28/0x120
    [  165.540529]  vfs_write+0xce/0x1f0

    v2: fix Cc format for stable

    Signed-off-by: Changbin Du <changbin.du@intel.com>
    Reviewed-by: Xiao Guangrong <guangrong.xiao@linux.intel.com>
    Reviewed-by: Jike Song <jike.song@intel.com>
    Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cccf8321af1c8c07abc83f4321d8a131b46d0af6
Author: Zhenyu Wang <zhenyuw@linux.intel.com>
Date:   Fri Mar 17 12:11:20 2017 +0800

    drm/i915/gvt: Fix gvt scheduler interval time

    commit 2958b9013fcbabeeba221161d0712f5259f1e15d upstream.

    Fix to correctly assign 1ms for gvt scheduler interval time,
    as previous code using HZ is pretty broken. And use no delay
    for start gvt scheduler function.

    Fixes: 4b63960ebd3f ("drm/i915/gvt: vGPU schedule policy framework")
    Cc: Zhi Wang <zhi.a.wang@intel.com>
    Acked-by: Chuanxiao Dong <chuanxiao.dong@intel.com>
    Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fba7cfc66b25a848b865357d2cab0034a370e5ce
Author: Huacai Chen <chenhc@lemote.com>
Date:   Thu Mar 16 21:00:29 2017 +0800

    MIPS: c-r4k: Fix Loongson-3's vcache/scache waysize calculation

    commit 0be032c190abcdcfa948082b6a1e0d461184ba4d upstream.

    If scache.waysize is 0, r4k___flush_cache_all() will do nothing and
    then cause bugs. BTW, though vcache.waysize isn't being used by now,
    we also fix its calculation.

    Signed-off-by: Huacai Chen <chenhc@lemote.com>
    Cc: John Crispin <john@phrozen.org>
    Cc: Steven J . Hill <Steven.Hill@caviumnetworks.com>
    Cc: Fuxin Zhang <zhangfx@lemote.com>
    Cc: Zhangjin Wu <wuzhangjin@gmail.com>
    Cc: linux-mips@linux-mips.org
    Patchwork: https://patchwork.linux-mips.org/patch/15756/
    Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 42ce8ecfd1418de518e0f9726ba380a54601d4d0
Author: Huacai Chen <chenhc@lemote.com>
Date:   Thu Mar 16 21:00:27 2017 +0800

    MIPS: Flush wrong invalid FTLB entry for huge page

    commit 0115f6cbf26663c86496bc56eeea293f85b77897 upstream.

    On VTLB+FTLB platforms (such as Loongson-3A R2), FTLB's pagesize is
    usually configured the same as PAGE_SIZE. In such a case, Huge page
    entry is not suitable to write in FTLB.

    Unfortunately, when a huge page is created, its page table entries
    haven't created immediately. Then the TLB refill handler will fetch an
    invalid page table entry which has no "HUGE" bit, and this entry may be
    written to FTLB. Since it is invalid, TLB load/store handler will then
    use tlbwi to write the valid entry at the same place. However, the
    valid entry is a huge page entry which isn't suitable for FTLB.

    Our solution is to modify build_huge_handler_tail. Flush the invalid
    old entry (whether it is in FTLB or VTLB, this is in order to reduce
    branches) and use tlbwr to write the valid new entry.

    Signed-off-by: Rui Wang <wangr@lemote.com>
    Signed-off-by: Huacai Chen <chenhc@lemote.com>
    Cc: John Crispin <john@phrozen.org>
    Cc: Steven J . Hill <Steven.Hill@caviumnetworks.com>
    Cc: Fuxin Zhang <zhangfx@lemote.com>
    Cc: Zhangjin Wu <wuzhangjin@gmail.com>
    Cc: Huacai Chen <chenhc@lemote.com>
    Cc: linux-mips@linux-mips.org
    Patchwork: https://patchwork.linux-mips.org/patch/15754/
    Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a854a7975ce0556ff3eda32b2f6944b1ead96214
Author: Huacai Chen <chenhc@lemote.com>
Date:   Thu Mar 16 21:00:25 2017 +0800

    MIPS: Add MIPS_CPU_FTLB for Loongson-3A R2

    commit 033cffeedbd11c140952b98e8639bf652091a17d upstream.

    Loongson-3A R2 and newer CPU have FTLB, but Config0.MT is 1, so add
    MIPS_CPU_FTLB to the CPU options.

    Signed-off-by: Huacai Chen <chenhc@lemote.com>
    Cc: John Crispin <john@phrozen.org>
    Cc: Steven J . Hill <Steven.Hill@caviumnetworks.com>
    Cc: Fuxin Zhang <zhangfx@lemote.com>
    Cc: Zhangjin Wu <wuzhangjin@gmail.com>
    Cc: linux-mips@linux-mips.org
    Patchwork: https://patchwork.linux-mips.org/patch/15752/
    Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5dc6659242085b75b2a738231828558f9b39feb2
Author: Huacai Chen <chenhc@lemote.com>
Date:   Thu Mar 16 21:00:26 2017 +0800

    MIPS: Check TLB before handle_ri_rdhwr() for Loongson-3

    commit 5a34133167dce36666ea054e30a561b7f4413b7f upstream.

    Loongson-3's micro TLB (ITLB) is not strictly a subset of JTLB. That
    means: when a JTLB entry is replaced by hardware, there may be an old
    valid entry exists in ITLB. So, a TLB miss exception may occur while
    handle_ri_rdhwr() is running because it try to access EPC's content.
    However, handle_ri_rdhwr() doesn't clear EXL, which makes a TLB Refill
    exception be treated as a TLB Invalid exception and tlbp may fail. In
    this case, if FTLB (which is usually set-associative instead of set-
    associative) is enabled, a tlbp failure will cause an invalid tlbwi,
    which will hang the whole system.

    This patch rename handle_ri_rdhwr_vivt to handle_ri_rdhwr_tlbp and use
    it for Loongson-3. It try to solve the same problem described as below,
    but more straightforwards.

    https://patchwork.linux-mips.org/patch/12591/

    I think Loongson-2 has the same problem, but it has no FTLB, so we just
    keep it as is.

    Signed-off-by: Huacai Chen <chenhc@lemote.com>
    Cc: Rui Wang <wangr@lemote.com>
    Cc: John Crispin <john@phrozen.org>
    Cc: Steven J . Hill <Steven.Hill@caviumnetworks.com>
    Cc: Fuxin Zhang <zhangfx@lemote.com>
    Cc: Zhangjin Wu <wuzhangjin@gmail.com>
    Cc: Huacai Chen <chenhc@lemote.com>
    Cc: linux-mips@linux-mips.org
    Patchwork: https://patchwork.linux-mips.org/patch/15753/
    Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 464d88e8a0adc37fee4a6c284d4beb172b199a1e
Author: Hauke Mehrtens <hauke@hauke-m.de>
Date:   Wed Mar 15 23:26:42 2017 +0100

    MIPS: Lantiq: fix missing xbar kernel panic

    commit 6ef90877eee63a0d03e83183bb44b64229b624e6 upstream.

    Commit 08b3c894e565 ("MIPS: lantiq: Disable xbar fpi burst mode")
    accidentally requested the resources from the pmu address region
    instead of the xbar registers region, but the check for the return
    value of request_mem_region() was wrong. Commit 98ea51cb0c8c ("MIPS:
    Lantiq: Fix another request_mem_region() return code check") fixed the
    check of the return value of request_mem_region() which made the kernel
    panics.
    This patch now makes use of the correct memory region for the cross bar.

    Fixes: 08b3c894e565 ("MIPS: lantiq: Disable xbar fpi burst mode")
    Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
    Cc: John Crispin <john@phrozen.org>
    Cc: james.hogan@imgtec.com
    Cc: arnd@arndb.de
    Cc: sergei.shtylyov@cogentembedded.com
    Cc: john@phrozen.org
    Cc: linux-mips@linux-mips.org
    Patchwork: https://patchwork.linux-mips.org/patch/15751
    Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 187b957634f01e31204c88e42b538eda76650210
Author: Paul Burton <paul.burton@imgtec.com>
Date:   Thu Feb 23 14:50:24 2017 +0000

    MIPS: End spinlocks with .insn

    commit 4b5347a24a0f2d3272032c120664b484478455de upstream.

    When building for microMIPS we need to ensure that the assembler always
    knows that there is code at the target of a branch or jump. Recent
    toolchains will fail to link a microMIPS kernel when this isn't the case
    due to what it thinks is a branch to non-microMIPS code.

    mips-mti-linux-gnu-ld kernel/built-in.o: .spinlock.text+0x2fc: Unsupported branch between ISA modes.
    mips-mti-linux-gnu-ld final link failed: Bad value

    This is due to inline assembly labels in spinlock.h not being followed
    by an instruction mnemonic, either due to a .subsection pseudo-op or the
    end of the inline asm block.

    Fix this with a .insn direction after such labels.

    Signed-off-by: Paul Burton <paul.burton@imgtec.com>
    Signed-off-by: James Hogan <james.hogan@imgtec.com>
    Reviewed-by: Maciej W. Rozycki <macro@imgtec.com>
    Cc: Ralf Baechle <ralf@linux-mips.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: linux-mips@linux-mips.org
    Cc: linux-kernel@vger.kernel.org
    Patchwork: https://patchwork.linux-mips.org/patch/15325/
    Signed-off-by: James Hogan <james.hogan@imgtec.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0c4b9fe703437dd051430395f46e624c01670b44
Author: John Crispin <john@phrozen.org>
Date:   Sat Feb 25 11:54:23 2017 +0100

    MIPS: ralink: Fix typos in rt3883 pinctrl

    commit 7c5a3d813050ee235817b0220dd8c42359a9efd8 upstream.

    There are two copy & paste errors in the definition of the 5GHz LNA and
    second ethernet pinmux.

    Fixes: f576fb6a0700 ("MIPS: ralink: cleanup the soc specific pinmux data")
    Signed-off-by: John Crispin <john@phrozen.org>
    Signed-off-by: Daniel Golle <daniel@makrotopia.org>
    Cc: linux-mips@linux-mips.org
    Patchwork: https://patchwork.linux-mips.org/patch/15328/
    Signed-off-by: James Hogan <james.hogan@imgtec.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e09e410969ef98b68dd6cadac6b11d31f565f7b1
Author: James Hogan <james.hogan@imgtec.com>
Date:   Thu Feb 16 12:39:01 2017 +0000

    MIPS: Force o32 fp64 support on 32bit MIPS64r6 kernels

    commit 2e6c7747730296a6d4fd700894286db1132598c4 upstream.

    When a 32-bit kernel is configured to support MIPS64r6 (CPU_MIPS64_R6),
    MIPS_O32_FP64_SUPPORT won't be selected as it should be because
    MIPS32_O32 is disabled (o32 is already the default ABI available on
    32-bit kernels).

    This results in userland FP breakage as CP0_Status.FR is read-only 1
    since r6 (when an FPU is present) so __enable_fpu() will fail to clear
    FR. This causes the FPU emulator to get used which will incorrectly
    emulate 32-bit FPU registers.

    Force o32 fp64 support in this case by also selecting
    MIPS_O32_FP64_SUPPORT from CPU_MIPS64_R6 if 32BIT.

    Fixes: 4e9d324d4288 ("MIPS: Require O32 FP64 support for MIPS64 with O32 compat")
    Signed-off-by: James Hogan <james.hogan@imgtec.com>
    Reviewed-by: Paul Burton <paul.burton@imgtec.com>
    Cc: Ralf Baechle <ralf@linux-mips.org>
    Cc: linux-mips@linux-mips.org
    Patchwork: https://patchwork.linux-mips.org/patch/15310/
    Signed-off-by: James Hogan <james.hogan@imgtec.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 94f3dd6b140a2490f150340e7ace2ecb0dace28d
Author: Heiko Carstens <heiko.carstens@de.ibm.com>
Date:   Mon Mar 27 09:48:04 2017 +0200

    s390/uaccess: get_user() should zero on failure (again)

    commit d09c5373e8e4eaaa09233552cbf75dc4c4f21203 upstream.

    Commit fd2d2b191fe7 ("s390: get_user() should zero on failure")
    intended to fix s390's get_user() implementation which did not zero
    the target operand if the read from user space faulted. Unfortunately
    the patch has no effect: the corresponding inline assembly specifies
    that the operand is only written to ("=") and the previous value is
    discarded.

    Therefore the compiler is free to and actually does omit the zero
    initialization.

    To fix this simply change the contraint modifier to "+", so the
    compiler cannot omit the initialization anymore.

    Fixes: c9ca78415ac1 ("s390/uaccess: provide inline variants of get_user/put_user")
    Fixes: fd2d2b191fe7 ("s390: get_user() should zero on failure")
    Cc: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
    Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5d4d57697aa1cbb46b4954b7f09600d2bae0ac2c
Author: Marcelo Henrique Cerri <marcelo.cerri@canonical.com>
Date:   Mon Mar 13 12:14:58 2017 -0300

    s390/decompressor: fix initrd corruption caused by bss clear

    commit d82c0d12c92705ef468683c9b7a8298dd61ed191 upstream.

    Reorder the operations in decompress_kernel() to ensure initrd is moved
    to a safe location before the bss section is zeroed.

    During decompression bss can overlap with the initrd and this can
    corrupt the initrd contents depending on the size of the compressed
    kernel (which affects where the initrd is placed by the bootloader) and
    the size of the bss section of the decompressor.

    Also use the correct initrd size when checking for overlaps with
    parmblock.

    Fixes: 06c0dd72aea3 ([S390] fix boot failures with compressed kernels)
    Reviewed-by: Joy Latten <joy.latten@canonical.com>
    Reviewed-by: Vineetha HariPai <vineetha.hari.pai@canonical.com>
    Signed-off-by: Marcelo Henrique Cerri <marcelo.cerri@canonical.com>
    Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
    Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a66f5106e71022ff90490f8c6f6c2bd389952e83
Author: Max Filippov <jcmvbkbc@gmail.com>
Date:   Wed Mar 29 15:44:47 2017 -0700

    xtensa: make __pa work with uncached KSEG addresses

    commit 2b83878dd74a7c73bedcb6600663c1c46836e8af upstream.

    When __pa is applied to virtual address in uncached KSEG region the
    result is incorrect. Fix it by checking if the original address is in
    the uncached KSEG and adjusting the result. It looks better than masking
    off bits because pfn_valid would correctly work with new __pa results
    and it may be made working in noMMU case, once we get definition for
    uncached memory view.

    This is required for the dma_common_mmap and DMA debug code to work
    correctly: they both indirectly use __pa with coherent DMA addresses.
    In case of DMA debug the visible effect is false reports that an address
    mapped for DMA is accessed by CPU.

    Tested-by: Boris Brezillon <boris.brezillon@free-electrons.com>
    Reviewed-by: Boris Brezillon <boris.brezillon@free-electrons.com>
    Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 36463a76abeb9d5f451ffdb5a55340051168a74c
Author: Tobias Klauser <tklauser@distanz.ch>
Date:   Sun Apr 2 20:08:04 2017 -0700

    nios2: reserve boot memory for device tree

    commit 921d701e6f31e1ffaca3560416af1aa04edb4c4f upstream.

    Make sure to reserve the boot memory for the flattened device tree.
    Otherwise it might get overwritten, e.g. when initial_boot_params is
    copied, leading to a corrupted FDT and a boot hang/crash:

      bootconsole [early0] enabled
      Early console on uart16650 initialized at 0xf8001600
      OF: fdt: Error -11 processing FDT
      Kernel panic - not syncing: setup_cpuinfo: No CPU found in devicetree!

      ---[ end Kernel panic - not syncing: setup_cpuinfo: No CPU found in devicetree!

    Guenter Roeck says:

    > I think I found the problem. In unflatten_and_copy_device_tree(), with added
    > debug information:
    >
    > OF: fdt: initial_boot_params=c861e400, dt=c861f000 size=28874 (0x70ca)
    >
    > ... and then initial_boot_params is copied to dt, which results in corrupted
    > fdt since the memory overlaps. Looks like the initial_boot_params memory
    > is not reserved and (re-)allocated by early_init_dt_alloc_memory_arch().

    Reported-by: Guenter Roeck <linux@roeck-us.net>
    Reference: http://lkml.kernel.org/r/20170226210338.GA19476@roeck-us.net
    Tested-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
    Acked-by: Ley Foon Tan <ley.foon.tan@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit be9fe9d4898827259e8fdfe2505074dfa1b6e63f
Author: Andi Kleen <ak@linux.intel.com>
Date:   Mon Mar 27 11:32:59 2017 +0200

    x86/mce: Don't print MCEs when mcelog is active

    commit cc66afea58f858ff6da7f79b8a595a67bbb4f9a9 upstream.

    Since:

      cd9c57cad3fe ("x86/MCE: Dump MCE to dmesg if no consumers")

    all MCEs are printed even when mcelog is running. Fix the regression to
    not print to dmesg when mcelog is running as it is a consumer too.

    Signed-off-by: Andi Kleen <ak@linux.intel.com>
    [ Massage commit message. ]
    Signed-off-by: Borislav Petkov <bp@suse.de>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Tony Luck <tony.luck@intel.com>
    Cc: linux-edac <linux-edac@vger.kernel.org>
    Fixes: cd9c57cad3fe ("x86/MCE: Dump MCE to dmesg if no consumers")
    Link: http://lkml.kernel.org/r/20170327093304.10683-2-bp@alien8.de
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fe96b265778a7ad8d14ce41be4ff2cbc8240e526
Author: Dmitry Bilunov <kmeaw@yandex-team.ru>
Date:   Thu Mar 30 18:14:26 2017 +0300

    dm raid: fix NULL pointer dereference for raid1 without bitmap

    commit 7a0c5c5b834fb60764b494b0e39c239da3b0774b upstream.

    Commit 4257e08 ("dm raid: support to change bitmap region size")
    introduced a bitmap resize call during preresume phase. User can create
    a DM device with "raid" target configured as raid1 with no metadata
    devices to hold superblock/bitmap info. It can be achieved using the
    following sequence:

      truncate -s 32M /dev/shm/raid-test
      LOOP=$(losetup --show -f /dev/shm/raid-test)
      dmsetup create raid-test-linear0 --table "0 1024 linear $LOOP 0"
      dmsetup create raid-test-linear1 --table "0 1024 linear $LOOP 1024"
      dmsetup create raid-test --table "0 1024 raid raid1 1 2048 2 - /dev/mapper/raid-test-linear0 - /dev/mapper/raid-test-linear1"

    This results in the following crash:

    [ 4029.110216] device-mapper: raid: Ignoring chunk size parameter for RAID 1
    [ 4029.110217] device-mapper: raid: Choosing default region size of 4MiB
    [ 4029.111349] md/raid1:mdX: active with 2 out of 2 mirrors
    [ 4029.114770] BUG: unable to handle kernel NULL pointer dereference at 0000000000000030
    [ 4029.114802] IP: bitmap_resize+0x25/0x7c0 [md_mod]
    [ 4029.114816] PGD 0
    â€¦
    [ 4029.115059] Hardware name: Aquarius Pro P30 S85 BUY-866/B85M-E, BIOS 2304 05/25/2015
    [ 4029.115079] task: ffff88015cc29a80 task.stack: ffffc90001a5c000
    [ 4029.115097] RIP: 0010:bitmap_resize+0x25/0x7c0 [md_mod]
    [ 4029.115112] RSP: 0018:ffffc90001a5fb68 EFLAGS: 00010246
    [ 4029.115127] RAX: 0000000000000005 RBX: 0000000000000000 RCX: 0000000000000000
    [ 4029.115146] RDX: 0000000000000000 RSI: 0000000000000400 RDI: 0000000000000000
    [ 4029.115166] RBP: ffffc90001a5fc28 R08: 0000000800000000 R09: 00000008ffffffff
    [ 4029.115185] R10: ffffea0005661600 R11: ffff88015cc29a80 R12: ffff88021231f058
    [ 4029.115204] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
    [ 4029.115223] FS:  00007fe73a6b4740(0000) GS:ffff88021ea80000(0000) knlGS:0000000000000000
    [ 4029.115245] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [ 4029.115261] CR2: 0000000000000030 CR3: 0000000159a74000 CR4: 00000000001426e0
    [ 4029.115281] Call Trace:
    [ 4029.115291]  ? raid_iterate_devices+0x63/0x80 [dm_raid]
    [ 4029.115309]  ? dm_table_all_devices_attribute.isra.23+0x41/0x70 [dm_mod]
    [ 4029.115329]  ? dm_table_set_restrictions+0x225/0x2d0 [dm_mod]
    [ 4029.115346]  raid_preresume+0x81/0x2e0 [dm_raid]
    [ 4029.115361]  dm_table_resume_targets+0x47/0xe0 [dm_mod]
    [ 4029.115378]  dm_resume+0xa8/0xd0 [dm_mod]
    [ 4029.115391]  dev_suspend+0x123/0x250 [dm_mod]
    [ 4029.115405]  ? table_load+0x350/0x350 [dm_mod]
    [ 4029.115419]  ctl_ioctl+0x1c2/0x490 [dm_mod]
    [ 4029.115433]  dm_ctl_ioctl+0xe/0x20 [dm_mod]
    [ 4029.115447]  do_vfs_ioctl+0x8d/0x5a0
    [ 4029.115459]  ? ____fput+0x9/0x10
    [ 4029.115470]  ? task_work_run+0x79/0xa0
    [ 4029.115481]  SyS_ioctl+0x3c/0x70
    [ 4029.115493]  entry_SYSCALL_64_fastpath+0x13/0x94

    The raid_preresume() function incorrectly assumes that the raid_set has
    a bitmap enabled if RT_FLAG_RS_BITMAP_LOADED is set.  But
    RT_FLAG_RS_BITMAP_LOADED is getting set in __load_dirty_region_bitmap()
    even if there is no bitmap present (and bitmap_load() happily returns 0
    even if a bitmap isn't present).  So the only way forward in the
    near-term is to check if the bitmap is present by seeing if
    mddev->bitmap is not NULL after bitmap_load() has been called.

    By doing so the above NULL pointer is avoided.

    Fixes: 4257e08 ("dm raid: support to change bitmap region size")
    Signed-off-by: Dmitry Bilunov <kmeaw@yandex-team.ru>
    Signed-off-by: Andrey Smetanin <asmetanin@yandex-team.ru>
    Acked-by: Heinz Mauelshagen <heinzm@redhat.com>
    Signed-off-by: Mike Snitzer <snitzer@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5c67d5410bbb98ae1f6eb1367edbf15a4ca9c9a7
Author: Michael Ellerman <mpe@ellerman.id.au>
Date:   Thu Apr 6 23:34:38 2017 +1000

    powerpc/crypto/crc32c-vpmsum: Fix missing preempt_disable()

    commit 4749228f022893faf54a3dbc70796f78b7d4f342 upstream.

    In crc32c_vpmsum() we call enable_kernel_altivec() without first
    disabling preemption, which is not allowed:

      WARNING: CPU: 9 PID: 2949 at ../arch/powerpc/kernel/process.c:277 enable_kernel_altivec+0x100/0x120
      Modules linked in: dm_thin_pool dm_persistent_data dm_bio_prison dm_bufio libcrc32c vmx_crypto ...
      CPU: 9 PID: 2949 Comm: docker Not tainted 4.11.0-rc5-compiler_gcc-6.3.1-00033-g308ac7563944 #381
      ...
      NIP [c00000000001e320] enable_kernel_altivec+0x100/0x120
      LR [d000000003df0910] crc32c_vpmsum+0x108/0x150 [crc32c_vpmsum]
      Call Trace:
        0xc138fd09 (unreliable)
        crc32c_vpmsum+0x108/0x150 [crc32c_vpmsum]
        crc32c_vpmsum_update+0x3c/0x60 [crc32c_vpmsum]
        crypto_shash_update+0x88/0x1c0
        crc32c+0x64/0x90 [libcrc32c]
        dm_bm_checksum+0x48/0x80 [dm_persistent_data]
        sb_check+0x84/0x120 [dm_thin_pool]
        dm_bm_validate_buffer.isra.0+0xc0/0x1b0 [dm_persistent_data]
        dm_bm_read_lock+0x80/0xf0 [dm_persistent_data]
        __create_persistent_data_objects+0x16c/0x810 [dm_thin_pool]
        dm_pool_metadata_open+0xb0/0x1a0 [dm_thin_pool]
        pool_ctr+0x4cc/0xb60 [dm_thin_pool]
        dm_table_add_target+0x16c/0x3c0
        table_load+0x184/0x400
        ctl_ioctl+0x2f0/0x560
        dm_ctl_ioctl+0x38/0x50
        do_vfs_ioctl+0xd8/0x920
        SyS_ioctl+0x68/0xc0
        system_call+0x38/0xfc

    It used to be sufficient just to call pagefault_disable(), because that
    also disabled preemption. But the two were decoupled in commit 8222dbe21e79
    ("sched/preempt, mm/fault: Decouple preemption from the page fault
    logic") in mid 2015.

    So add the missing preempt_disable/enable(). We should also call
    disable_kernel_fp(), although it does nothing by default, there is a
    debug switch to make it active and all enables should be paired with
    disables.

    Fixes: 6dd7a82cc54e ("crypto: powerpc - Add POWER8 optimised crc32c")
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d625e1a1530db309a03f1f166306a9b1f5dbd4d1
Author: Paul Mackerras <paulus@ozlabs.org>
Date:   Tue Apr 4 14:56:05 2017 +1000

    powerpc: Don't try to fix up misaligned load-with-reservation instructions

    commit 48fe9e9488743eec9b7c1addd3c93f12f2123d54 upstream.

    In the past, there was only one load-with-reservation instruction,
    lwarx, and if a program attempted a lwarx on a misaligned address, it
    would take an alignment interrupt and the kernel handler would emulate
    it as though it was lwzx, which was not really correct, but benign since
    it is loading the right amount of data, and the lwarx should be paired
    with a stwcx. to the same address, which would also cause an alignment
    interrupt which would result in a SIGBUS being delivered to the process.

    We now have 5 different sizes of load-with-reservation instruction. Of
    those, lharx and ldarx cause an immediate SIGBUS by luck since their
    entries in aligninfo[] overlap instructions which were not fixed up, but
    lqarx overlaps with lhz and will be emulated as such. lbarx can never
    generate an alignment interrupt since it only operates on 1 byte.

    To straighten this out and fix the lqarx case, this adds code to detect
    the l[hwdq]arx instructions and return without fixing them up, resulting
    in a SIGBUS being delivered to the process.

    Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b129e418406bc803090bd8ab190a1b7fe7dd35bd
Author: Oliver O'Halloran <oohall@gmail.com>
Date:   Mon Apr 3 13:25:12 2017 +1000

    powerpc/64: Fix flush_(d|i)cache_range() called from modules

    commit 8f5f525d5b83f7d76a6baf9c4e94d4bf312ea7f6 upstream.

    When the kernel is compiled to use 64bit ABIv2 the _GLOBAL() macro does
    not include a global entry point. A function's global entry point is
    used when the function is called from a different TOC context and in the
    kernel this typically means a call from a module into the vmlinux (or
    vice-versa).

    There are a few exported asm functions declared with _GLOBAL() and
    calling them from a module will likely crash the kernel since any TOC
    relative load will yield garbage.

    flush_icache_range() and flush_dcache_range() are both exported to
    modules, and use the TOC, so must use _GLOBAL_TOC().

    Fixes: 721aeaa9fdf3 ("powerpc: Build little endian ppc64 kernel with ABIv2")
    Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 12502ae4c9a18ef05a6837d925bebbf71272c4b1
Author: Frederic Barrat <fbarrat@linux.vnet.ibm.com>
Date:   Wed Mar 29 19:19:42 2017 +0200

    powerpc/mm: Add missing global TLB invalidate if cxl is active

    commit 88b1bf7268f56887ca88eb09c6fb0f4fc970121a upstream.

    Commit 4c6d9acce1f4 ("powerpc/mm: Add hooks for cxl") converted local
    TLB invalidates to global if the cxl driver is active. This is necessary
    because the CAPP snoops invalidations to forward them to the PSL on the
    cxl adapter. However one path was forgotten. native_flush_hash_range()
    still does local TLB invalidates, as found out the hard way recently.

    This patch fixes it by following the same logic as previously: if the
    cxl driver is active, the local TLB invalidates are 'upgraded' to
    global.

    Fixes: 4c6d9acce1f4 ("powerpc/mm: Add hooks for cxl")
    Signed-off-by: Frederic Barrat <fbarrat@linux.vnet.ibm.com>
    Reviewed-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2a3134e106d47d35dbaa5d45173dde5aafe343ef
Author: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Date:   Mon Mar 20 17:49:03 2017 +1100

    powerpc: Disable HFSCR[TM] if TM is not supported

    commit 7ed23e1bae8bf7e37fd555066550a00b95a3a98b upstream.

    On Power8 & Power9 the early CPU inititialisation in __init_HFSCR()
    turns on HFSCR[TM] (Hypervisor Facility Status and Control Register
    [Transactional Memory]), but that doesn't take into account that TM
    might be disabled by CPU features, or disabled by the kernel being built
    with CONFIG_PPC_TRANSACTIONAL_MEM=n.

    So later in boot, when we have setup the CPU features, clear HSCR[TM] if
    the TM CPU feature has been disabled. We use CPU_FTR_TM_COMP to account
    for the CONFIG_PPC_TRANSACTIONAL_MEM=n case.

    Without this a KVM guest might try use TM, even if told not to, and
    cause an oops in the host kernel. Typically the oops is seen in
    __kvmppc_vcore_entry() and may or may not be fatal to the host, but is
    always bad news.

    In practice all shipping CPU revisions do support TM, and all host
    kernels we are aware of build with TM support enabled, so no one should
    actually be able to hit this in the wild.

    Fixes: 2a3563b023e5 ("powerpc: Setup in HFSCR for POWER8")
    Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    Tested-by: Sam Bobroff <sam.bobroff@au1.ibm.com>
    [mpe: Rewrite change log with input from Sam, add Fixes/stable]
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit be5569719b5ccd1c14e93b4cc4bc80bcdb1500be
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Mon Mar 13 17:43:48 2017 +0100

    drm/msm: adreno: fix build error without debugfs

    commit 280489daa68bd20364b322c11e3f429a0212c611 upstream.

    The newly added a5xx support fails to build when debugfs is diabled:

    drivers/gpu/drm/msm/adreno/a5xx_gpu.c:849:4: error: 'struct msm_gpu_funcs' has no member named 'show'
    drivers/gpu/drm/msm/adreno/a5xx_gpu.c:849:11: error: 'a5xx_show' undeclared here (not in a function); did you mean 'a5xx_irq'?

    This adds a missing #ifdef.

    Fixes: b5f103ab98c7 ("drm/msm: gpu: Add A5XX target support")
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Rob Clark <robdclark@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 169b36bef88f2ad45b97383f99174b04fcf716f7
Author: James Hogan <james.hogan@imgtec.com>
Date:   Tue Apr 4 08:51:34 2017 +0100

    metag/usercopy: Add missing fixups

    commit b884a190afcecdbef34ca508ea5ee88bb7c77861 upstream.

    The rapf copy loops in the Meta usercopy code is missing some extable
    entries for HTP cores with unaligned access checking enabled, where
    faults occur on the instruction immediately after the faulting access.

    Add the fixup labels and extable entries for these cases so that corner
    case user copy failures don't cause kernel crashes.

    Fixes: 373cd784d0fc ("metag: Memory handling")
    Signed-off-by: James Hogan <james.hogan@imgtec.com>
    Cc: linux-metag@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 191e4c7355490666922aac49a3876dd76ed0f0c9
Author: James Hogan <james.hogan@imgtec.com>
Date:   Mon Apr 3 17:41:40 2017 +0100

    metag/usercopy: Fix src fixup in from user rapf loops

    commit 2c0b1df88b987a12d95ea1d6beaf01894f3cc725 upstream.

    The fixup code to rewind the source pointer in
    __asm_copy_from_user_{32,64}bit_rapf_loop() always rewound the source by
    a single unit (4 or 8 bytes), however this is insufficient if the fault
    didn't occur on the first load in the loop, as the source pointer will
    have been incremented but nothing will have been stored until all 4
    register [pairs] are loaded.

    Read the LSM_STEP field of TXSTATUS (which is already loaded into a
    register), a bit like the copy_to_user versions, to determine how many
    iterations of MGET[DL] have taken place, all of which need rewinding.

    Fixes: 373cd784d0fc ("metag: Memory handling")
    Signed-off-by: James Hogan <james.hogan@imgtec.com>
    Cc: linux-metag@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e6ca39ac0c0d7f4f80bfec18c3069dd0287eccc4
Author: James Hogan <james.hogan@imgtec.com>
Date:   Tue Apr 4 11:43:26 2017 +0100

    metag/usercopy: Set flags before ADDZ

    commit fd40eee1290ad7add7aa665e3ce6b0f9fe9734b4 upstream.

    The fixup code for the copy_to_user rapf loops reads TXStatus.LSM_STEP
    to decide how far to rewind the source pointer. There is a special case
    for the last execution of an MGETL/MGETD, since it leaves LSM_STEP=0
    even though the number of MGETLs/MGETDs attempted was 4. This uses ADDZ
    which is conditional upon the Z condition flag, but the AND instruction
    which masked the TXStatus.LSM_STEP field didn't set the condition flags
    based on the result.

    Fix that now by using ANDS which does set the flags, and also marking
    the condition codes as clobbered by the inline assembly.

    Fixes: 373cd784d0fc ("metag: Memory handling")
    Signed-off-by: James Hogan <james.hogan@imgtec.com>
    Cc: linux-metag@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b03dd10e4c585cbd0ab9e8067102afa767095997
Author: James Hogan <james.hogan@imgtec.com>
Date:   Fri Mar 31 11:14:02 2017 +0100

    metag/usercopy: Zero rest of buffer from copy_from_user

    commit 563ddc1076109f2b3f88e6d355eab7b6fd4662cb upstream.

    Currently we try to zero the destination for a failed read from userland
    in fixup code in the usercopy.c macros. The rest of the destination
    buffer is then zeroed from __copy_user_zeroing(), which is used for both
    copy_from_user() and __copy_from_user().

    Unfortunately we fail to zero in the fixup code as D1Ar1 is set to 0
    before the fixup code entry labels, and __copy_from_user() shouldn't even
    be zeroing the rest of the buffer.

    Move the zeroing out into copy_from_user() and rename
    __copy_user_zeroing() to raw_copy_from_user() since it no longer does
    any zeroing. This also conveniently matches the name needed for
    RAW_COPY_USER support in a later patch.

    Fixes: 373cd784d0fc ("metag: Memory handling")
    Reported-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: James Hogan <james.hogan@imgtec.com>
    Cc: linux-metag@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 60a0b56ea1190612f777ffb8640632f43c57ef42
Author: James Hogan <james.hogan@imgtec.com>
Date:   Fri Mar 31 13:35:01 2017 +0100

    metag/usercopy: Add early abort to copy_to_user

    commit fb8ea062a8f2e85256e13f55696c5c5f0dfdcc8b upstream.

    When copying to userland on Meta, if any faults are encountered
    immediately abort the copy instead of continuing on and repeatedly
    faulting, and worse potentially copying further bytes successfully to
    subsequent valid pages.

    Fixes: 373cd784d0fc ("metag: Memory handling")
    Reported-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: James Hogan <james.hogan@imgtec.com>
    Cc: linux-metag@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e61ffb12b6acd8ad23c6a827e42fe209d81c9ba7
Author: James Hogan <james.hogan@imgtec.com>
Date:   Fri Mar 31 11:23:18 2017 +0100

    metag/usercopy: Fix alignment error checking

    commit 2257211942bbbf6c798ab70b487d7e62f7835a1a upstream.

    Fix the error checking of the alignment adjustment code in
    raw_copy_from_user(), which mistakenly considers it safe to skip the
    error check when aligning the source buffer on a 2 or 4 byte boundary.

    If the destination buffer was unaligned it may have started to copy
    using byte or word accesses, which could well be at the start of a new
    (valid) source page. This would result in it appearing to have copied 1
    or 2 bytes at the end of the first (invalid) page rather than none at
    all.

    Fixes: 373cd784d0fc ("metag: Memory handling")
    Signed-off-by: James Hogan <james.hogan@imgtec.com>
    Cc: linux-metag@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 804453ff0993f5c712e6a7f2f0098a54f23ee01d
Author: James Hogan <james.hogan@imgtec.com>
Date:   Fri Mar 31 10:37:44 2017 +0100

    metag/usercopy: Drop unused macros

    commit ef62a2d81f73d9cddef14bc3d9097a57010d551c upstream.

    Metag's lib/usercopy.c has a bunch of copy_from_user macros for larger
    copies between 5 and 16 bytes which are completely unused. Before fixing
    zeroing lets drop these macros so there is less to fix.

    Signed-off-by: James Hogan <james.hogan@imgtec.com>
    Cc: Al Viro <viro@zeniv.linux.org.uk>
    Cc: linux-metag@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6d855e0275533af0db85ee5060f69f5c7240264f
Author: Arend Van Spriel <arend.vanspriel@broadcom.com>
Date:   Tue Mar 28 09:11:30 2017 +0100

    brcmfmac: use local iftype avoiding use-after-free of virtual interface

    commit d77facb88448cdeaaa3adba5b9704a48ac2ac8d6 upstream.

    A use-after-free was found using KASAN. In brcmf_p2p_del_if() the virtual
    interface is removed using call to brcmf_remove_interface(). After that
    the virtual interface instance has been freed and should not be referenced.
    Solve this by storing the nl80211 iftype in local variable, which is used
    in a couple of places anyway.

    Reported-by: Daniel J Blueman <daniel@quora.org>
    Reviewed-by: Hante Meuleman <hante.meuleman@broadcom.com>
    Reviewed-by: Pieter-Paul Giesberts <pieter-paul.giesberts@broadcom.com>
    Reviewed-by: Franky Lin <franky.lin@broadcom.com>
    Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 96499191fe6dada95c0486c420f58ce46e60ab44
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Wed Mar 29 14:15:24 2017 +0200

    mac80211: unconditionally start new netdev queues with iTXQ support

    commit 7d65f82954dadbbe7b6e1aec7e07ad17bc6d958b upstream.

    When internal mac80211 TXQs aren't supported, netdev queues must
    always started out started even when driver queues are stopped
    while the interface is added. This is necessary because with the
    internal TXQ support netdev queues are never stopped and packet
    scheduling/dropping is done in mac80211.

    Fixes: 80a83cfc434b1 ("mac80211: skip netdev queue control with software queuing")
    Reported-and-tested-by: Sven Eckelmann <sven.eckelmann@openmesh.com>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ab23a82a01763c4857a005ad2482125a61cc22e4
Author: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Date:   Fri Jun 17 17:33:59 2016 +0000

    ring-buffer: Fix return value check in test_ringbuffer()

    commit 62277de758b155dc04b78f195a1cb5208c37b2df upstream.

    In case of error, the function kthread_run() returns ERR_PTR()
    and never returns NULL. The NULL test in the return value check
    should be replaced with IS_ERR().

    Link: http://lkml.kernel.org/r/1466184839-14927-1-git-send-email-weiyj_lk@163.com

    Fixes: 6c43e554a ("ring-buffer: Add ring buffer startup selftest")
    Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
    Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 24d108e4dfecdba74470889b54d4ceab6ee24577
Author: Calvin Owens <calvinowens@fb.com>
Date:   Mon Apr 3 12:22:29 2017 -0700

    xfs: Honor FALLOC_FL_KEEP_SIZE when punching ends of files

    commit 3dd09d5a8589c640abb49cfcf92b4ed669eafad1 upstream.

    When punching past EOF on XFS, fallocate(mode=PUNCH_HOLE|KEEP_SIZE) will
    round the file size up to the nearest multiple of PAGE_SIZE:

      calvinow@vm-disks/generic-xfs-1 ~$ dd if=/dev/urandom of=test bs=2048 count=1
      calvinow@vm-disks/generic-xfs-1 ~$ stat test
        Size: 2048            Blocks: 8          IO Block: 4096   regular file
      calvinow@vm-disks/generic-xfs-1 ~$ fallocate -n -l 2048 -o 2048 -p test
      calvinow@vm-disks/generic-xfs-1 ~$ stat test
        Size: 4096            Blocks: 8          IO Block: 4096   regular file

    Commit 3c2bdc912a1cc050 ("xfs: kill xfs_zero_remaining_bytes") replaced
    xfs_zero_remaining_bytes() with calls to iomap helpers. The new helpers
    don't enforce that [pos,offset) lies strictly on [0,i_size) when being
    called from xfs_free_file_space(), so by "leaking" these ranges into
    xfs_zero_range() we get this buggy behavior.

    Fix this by reintroducing the checks xfs_zero_remaining_bytes() did
    against i_size at the bottom of xfs_free_file_space().

    Reported-by: Aaron Gao <gzh@fb.com>
    Fixes: 3c2bdc912a1cc050 ("xfs: kill xfs_zero_remaining_bytes")
    Cc: Christoph Hellwig <hch@lst.de>
    Cc: Brian Foster <bfoster@redhat.com>
    Signed-off-by: Calvin Owens <calvinowens@fb.com>
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
    Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1d656a4d8e879aa81adb6e813b7f67bf1ea8dc65
Author: Martin Brandenburg <martin@omnibond.com>
Date:   Thu Apr 6 18:11:00 2017 -0400

    orangefs: move features validation to fix filesystem hang

    commit cefdc26e86728812aea54248a534fd4a5da2a43d upstream.

    Without this fix (and another to the userspace component itself
    described later), the kernel will be unable to process any OrangeFS
    requests after the userspace component is restarted (due to a crash or
    at the administrator's behest).

    The bug here is that inside orangefs_remount, the orangefs_request_mutex
    is locked.  When the userspace component restarts while the filesystem
    is mounted, it sends a ORANGEFS_DEV_REMOUNT_ALL ioctl to the device,
    which causes the kernel to send it a few requests aimed at synchronizing
    the state between the two.  While this is happening the
    orangefs_request_mutex is locked to prevent any other requests going
    through.

    This is only half of the bugfix.  The other half is in the userspace
    component which outright ignores(!) requests made before it considers
    the filesystem remounted, which is after the ioctl returns.  Of course
    the ioctl doesn't return until after the userspace component responds to
    the request it ignores.  The userspace component has been changed to
    allow ORANGEFS_VFS_OP_FEATURES regardless of the mount status.

    Mike Marshall says:
     "I've tested this patch against the fixed userspace part. This patch is
      real important, I hope it can make it into 4.11...

      Here's what happens when the userspace daemon is restarted, without
      the patch:

        =============================================
        [ INFO: possible recursive locking detected ]
        [   4.10.0-00007-ge98bdb3 #1 Not tainted    ]
        ---------------------------------------------
        pvfs2-client-co/29032 is trying to acquire lock:
         (orangefs_request_mutex){+.+.+.}, at: service_operation+0x3c7/0x7b0 [orangefs]
                      but task is already holding lock:
         (orangefs_request_mutex){+.+.+.}, at: dispatch_ioctl_command+0x1bf/0x330 [orangefs]

        CPU: 0 PID: 29032 Comm: pvfs2-client-co Not tainted 4.10.0-00007-ge98bdb3 #1
        Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.9.3-1.fc25 04/01/2014
        Call Trace:
         __lock_acquire+0x7eb/0x1290
         lock_acquire+0xe8/0x1d0
         mutex_lock_killable_nested+0x6f/0x6e0
         service_operation+0x3c7/0x7b0 [orangefs]
         orangefs_remount+0xea/0x150 [orangefs]
         dispatch_ioctl_command+0x227/0x330 [orangefs]
         orangefs_devreq_ioctl+0x29/0x70 [orangefs]
         do_vfs_ioctl+0xa3/0x6e0
         SyS_ioctl+0x79/0x90"

    Signed-off-by: Martin Brandenburg <martin@omnibond.com>
    Acked-by: Mike Marshall <hubcap@omnibond.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b92a638e002b1546bdc4fdb1d7b290898e0f5f7c
Author: Gleb Fotengauer-Malinovskiy <glebfm@altlinux.org>
Date:   Mon Mar 20 20:15:53 2017 +0300

    jump label: fix passing kbuild_cflags when checking for asm goto support

    commit 7292ae3d5a18fb922be496e6bb687647193569b4 upstream.

    The latest change of asm goto support check added passing of KBUILD_CFLAGS
    to compiler.  When these flags reference gcc plugins that are not built yet,
    the check fails.

    When one runs "make bzImage" followed by "make modules", the kernel is always
    built with HAVE_JUMP_LABEL disabled, while the modules are built depending on
    CONFIG_JUMP_LABEL.  If HAVE_JUMP_LABEL macro happens to be different, modules
    are built with undefined references, e.g.:

    ERROR: "static_key_slow_inc" [net/netfilter/xt_TEE.ko] undefined!
    ERROR: "static_key_slow_dec" [net/netfilter/xt_TEE.ko] undefined!
    ERROR: "static_key_slow_dec" [net/netfilter/nft_meta.ko] undefined!
    ERROR: "static_key_slow_inc" [net/netfilter/nft_meta.ko] undefined!
    ERROR: "nf_hooks_needed" [net/netfilter/ipvs/ip_vs.ko] undefined!
    ERROR: "nf_hooks_needed" [net/ipv6/ipv6.ko] undefined!
    ERROR: "static_key_count" [net/ipv6/ipv6.ko] undefined!
    ERROR: "static_key_slow_inc" [net/ipv6/ipv6.ko] undefined!

    This change moves the check before all these references are added
    to KBUILD_CFLAGS.  This is correct because subsequent KBUILD_CFLAGS
    modifications are not relevant to this check.

    Reported-by: Anton V. Boyarshinov <boyarsh@altlinux.org>
    Fixes: 35f860f9ba6a ("jump label: pass kbuild_cflags when checking for asm goto support")
    Signed-off-by: Gleb Fotengauer-Malinovskiy <glebfm@altlinux.org>
    Signed-off-by: Dmitry V. Levin <ldv@altlinux.org>
    Acked-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
    Acked-by: David Lin <dtwlin@google.com>
    Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7b73b72fbf8234a7ecc34ac4d9b731c24931b0e8
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Fri Jan 13 16:40:01 2017 +0100

    Kbuild: use cc-disable-warning consistently for maybe-uninitialized

    commit b334e19ae9381f12a7521976883022385d2b7eef upstream.

    In commit a76bcf557ef4 ("Kbuild: enable -Wmaybe-uninitialized warning
    for "make W=1""), I reverted another change that happened to fix a problem
    with old compilers, and now we get this report again with old compilers
    (prior to gcc-4.8) and GCOV enabled:

       cc1: warnings being treated as errors
       drivers/gpu/drm/i915/intel_ringbuffer.c: In function 'intel_ring_setup_status_page':
       drivers/gpu/drm/i915/intel_ringbuffer.c:438: error: 'mmio.reg' may be used uninitialized in this function
       At top level:
    >> cc1: error: unrecognized command line option "-Wno-maybe-uninitialized"

    The problem is that we turn off the warning conditionally in a number
    of places as we should, but one of them does it unconditionally.
    Instead, change it to call cc-disable-warning as we do elsewhere.

    The original patch that caused it was merged into linux-4.7, then
    4.8 removed the change and 4.9 brought it back, so we probably want
    a backport to 4.9 once this is merged.

    Use a ':=' assignment instead of '=' to force the cc-disable-warning
    call to only be evaluated once instead of every time.

    Fixes: a76bcf557ef4 ("Kbuild: enable -Wmaybe-uninitialized warning for "make W=1"")
    Fixes: e72e2dfe7c16 ("gcov: disable -Wmaybe-uninitialized warning")
    Reported-by: kbuild test robot <fengguang.wu@intel.com>
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 52b38ad09a6c477892895b5179bff1a907d8eae1
Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Date:   Sat Apr 1 00:45:52 2017 +0200

    ACPI / scan: Prefer devices without _HID for _ADR matching

    commit fdad4e7a876a2cb3d2c1f04e5418c324e79fffef upstream.

    Commit c2a6bbaf0c5f (ACPI / scan: Prefer devices without _HID/_CID
    for _ADR matching) added a list_empty(&adev->pnp.ids) check to
    find_child_checks() so as to catch situations in which the ACPI
    core attempts to decode _ADR for a device having a _HID too which
    is strictly against the spec.  However, it overlooked the fact that
    the adev->pnp.ids list for the devices taken into account by
    find_child_checks() may contain device IDs set internally by the
    kernel, like "LNXVIDEO" (thanks to Zhang Rui for that realization),
    and it broke the enumeration of those devices as a result.

    To unbreak it, replace the overly coarse grained list_empty()
    check with a much more precise check against the pnp.type.platform_id
    flag which is only set for devices having a _HID (that's how it
    should be done from the start, as having both _ADR and _CID is
    actually permitted).

    Fixes: c2a6bbaf0c5f (ACPI / scan: Prefer devices without _HID/_CID for _ADR matching)
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=194889
    Reported-and-tested-by: Mike <mike@mikewilson.me.uk>
    Tested-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e56bb92202f764a9761e4138cdab33161b2abfce
Author: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Date:   Thu Mar 23 13:21:38 2017 -0700

    ACPI / gpio: do not fall back to parsing _CRS when we get a deferral

    commit 693bdaa164b40b7aa6018b98af6f7e40dbd52457 upstream.

    If, while locating GPIOs by name, we get probe deferral, we should
    immediately report it to caller rather than trying to fall back to parsing
    unnamed GPIOs from _CRS block.

    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
    Acked-and-Tested-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1c9925e63abbf8d08eb782447308c6683a5dbe3f
Author: Sami Tolvanen <samitolvanen@google.com>
Date:   Fri Mar 31 12:32:45 2017 -0700

    dm verity fec: fix bufio leaks

    commit 86e3e83b443669dd2bcc5c8a83b23e3aa0694c0d upstream.

    Buffers read through dm_bufio_read() were not released in all code paths.

    Fixes: a739ff3f543a ("dm verity: add support for forward error correction")
    Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
    Signed-off-by: Mike Snitzer <snitzer@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 88c358b1f453e34a635fc9bc5fb3a9a6e485c508
Author: Sami Tolvanen <samitolvanen@google.com>
Date:   Wed Mar 15 15:12:23 2017 -0700

    dm verity fec: limit error correction recursion

    commit f1a880a93baaadb14c10a348fd199f1cdb6bcccd upstream.

    If the hash tree itself is sufficiently corrupt in addition to data blocks,
    it's possible for error correction to end up in a deep recursive loop,
    which eventually causes a kernel panic.  This change limits the
    recursion to a reasonable level during a single I/O operation.

    Fixes: a739ff3f543a ("dm verity: add support for forward error correction")
    Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
    Signed-off-by: Mike Snitzer <snitzer@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 523a193242674a267d09c6c457b316d82dbeed57
Author: Ross Zwisler <ross.zwisler@linux.intel.com>
Date:   Fri Apr 7 16:04:57 2017 -0700

    dax: fix radix tree insertion race

    commit e11f8b7b6c4ea13bf8af6b8f42b45e15b554a92b upstream.

    While running generic/340 in my test setup I hit the following race.  It
    can happen with kernels that support FS DAX PMDs, so v4.10 thru
    v4.11-rc5.

    Thread 1                                Thread 2
    --------                                --------
    dax_iomap_pmd_fault()
      grab_mapping_entry()
        spin_lock_irq()
        get_unlocked_mapping_entry()
        'entry' is NULL, can't call lock_slot()
        spin_unlock_irq()
        radix_tree_preload()
                                            dax_iomap_pmd_fault()
                                              grab_mapping_entry()
                                                spin_lock_irq()
                                                get_unlocked_mapping_entry()
                                                ...
                                                lock_slot()
                                                spin_unlock_irq()
                                              dax_pmd_insert_mapping()
                                                <inserts a PMD mapping>
        spin_lock_irq()
        __radix_tree_insert() fails with -EEXIST
        <fall back to 4k fault, and die horribly
         when inserting a 4k entry where a PMD exists>

    The issue is that we have to drop mapping->tree_lock while calling
    radix_tree_preload(), but since we didn't have a radix tree entry to
    lock (unlike in the pmd_downgrade case) we have no protection against
    Thread 2 coming along and inserting a PMD at the same index.  For 4k
    entries we handled this with a special-case response to -EEXIST coming
    from the __radix_tree_insert(), but this doesn't save us for PMDs
    because the -EEXIST case can also mean that we collided with a 4k entry
    in the radix tree at a different index, but one that is covered by our
    PMD range.

    So, correctly handle both the 4k and 2M collision cases by explicitly
    re-checking the radix tree for an entry at our index once we reacquire
    mapping->tree_lock.

    This patch has made it through a clean xfstests run with the current
    v4.11-rc5 based linux/master, and it also ran generic/340 500 times in a
    loop.  It used to fail within the first 10 iterations.

    Link: http://lkml.kernel.org/r/20170406212944.2866-1-ross.zwisler@linux.intel.com
    Signed-off-by: Ross Zwisler <ross.zwisler@linux.intel.com>
    Cc: "Darrick J. Wong" <darrick.wong@oracle.com>
    Cc: Alexander Viro <viro@zeniv.linux.org.uk>
    Cc: Christoph Hellwig <hch@lst.de>
    Cc: Dan Williams <dan.j.williams@intel.com>
    Cc: Jan Kara <jack@suse.cz>
    Cc: Matthew Wilcox <mawilcox@microsoft.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>

commit 8bdc69ccb9f8298b207954a566d51d5fad33896c
Author: bsegall@google.com <bsegall@google.com>
Date:   Fri Apr 7 16:04:51 2017 -0700

    ptrace: fix PTRACE_LISTEN race corrupting task->state

    commit 5402e97af667e35e54177af8f6575518bf251d51 upstream.

    In PT_SEIZED + LISTEN mode STOP/CONT signals cause a wakeup against
    __TASK_TRACED.  If this races with the ptrace_unfreeze_traced at the end
    of a PTRACE_LISTEN, this can wake the task /after/ the check against
    __TASK_TRACED, but before the reset of state to TASK_TRACED.  This
    causes it to instead clobber TASK_WAKING, allowing a subsequent wakeup
    against TRACED while the task is still on the rq wake_list, corrupting
    it.

    Oleg said:
     "The kernel can crash or this can lead to other hard-to-debug problems.
      In short, "task->state = TASK_TRACED" in ptrace_unfreeze_traced()
      assumes that nobody else can wake it up, but PTRACE_LISTEN breaks the
      contract. Obviusly it is very wrong to manipulate task->state if this
      task is already running, or WAKING, or it sleeps again"

    [akpm@linux-foundation.org: coding-style fixes]
    Fixes: 9899d11f ("ptrace: ensure arch_ptrace/ptrace_request can never race with SIGKILL")
    Link: http://lkml.kernel.org/r/xm26y3vfhmkp.fsf_-_@bsegall-linux.mtv.corp.google.com
    Signed-off-by: Ben Segall <bsegall@google.com>
    Acked-by: Oleg Nesterov <oleg@redhat.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>

commit 0666cf6c9c1876a19019c25b3888a73212e42c0f
Author: Alexander Polakov <apolyakov@beget.ru>
Date:   Fri Apr 7 16:04:45 2017 -0700

    mm/page_alloc.c: fix print order in show_free_areas()

    commit 1f06b81aea5ecba2c1f8afd87e0ba1b9f8f90160 upstream.

    Fixes: 11fb998986a72a ("mm: move most file-based accounting to the node")
    Link: http://lkml.kernel.org/r/1490377730.30219.2.camel@beget.ru
    Signed-off-by: Alexander Polyakov <apolyakov@beget.com>
    Acked-by: Michal Hocko <mhocko@suse.com>
    Cc: Mel Gorman <mgorman@techsingularity.net>
    Cc: Vlastimil Babka <vbabka@suse.cz>
    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>

commit 674850494e19d6b234c91f04df76748d70702ace
Author: Jan-Marek Glogowski <glogow@fbihome.de>
Date:   Mon Feb 20 12:25:58 2017 +0100

    Reset TreeId to zero on SMB2 TREE_CONNECT

    commit 806a28efe9b78ffae5e2757e1ee924b8e50c08ab upstream.

    Currently the cifs module breaks the CIFS specs on reconnect as
    described in http://msdn.microsoft.com/en-us/library/cc246529.aspx:

    "TreeId (4 bytes): Uniquely identifies the tree connect for the
    command. This MUST be 0 for the SMB2 TREE_CONNECT Request."

    Signed-off-by: Jan-Marek Glogowski <glogow@fbihome.de>
    Reviewed-by: Aurelien Aptel <aaptel@suse.com>
    Tested-by: Aurelien Aptel <aaptel@suse.com>
    Signed-off-by: Steve French <smfrench@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c793e33749815e1415139b3157e76f3045bfe500
Author: Arend Van Spriel <arend.vanspriel@broadcom.com>
Date:   Tue Mar 28 09:11:31 2017 +0100

    cfg80211: check rdev resume callback only for registered wiphy

    commit b3ef5520c1eabb56064474043c7c55a1a65b8708 upstream.

    We got the following use-after-free KASAN report:

     BUG: KASAN: use-after-free in wiphy_resume+0x591/0x5a0 [cfg80211]
             at addr ffff8803fc244090
     Read of size 8 by task kworker/u16:24/2587
     CPU: 6 PID: 2587 Comm: kworker/u16:24 Tainted: G    B 4.9.13-debug+
     Hardware name: Dell Inc. XPS 15 9550/0N7TVV, BIOS 1.2.19 12/22/2016
     Workqueue: events_unbound async_run_entry_fn
      ffff880425d4f9d8 ffffffffaeedb541 ffff88042b80ef00 ffff8803fc244088
      ffff880425d4fa00 ffffffffae84d7a1 ffff880425d4fa98 ffff8803fc244080
      ffff88042b80ef00 ffff880425d4fa88 ffffffffae84da3a ffffffffc141f7d9
     Call Trace:
      [<ffffffffaeedb541>] dump_stack+0x85/0xc4
      [<ffffffffae84d7a1>] kasan_object_err+0x21/0x70
      [<ffffffffae84da3a>] kasan_report_error+0x1fa/0x500
      [<ffffffffc141f7d9>] ? cfg80211_bss_age+0x39/0xc0 [cfg80211]
      [<ffffffffc141f83a>] ? cfg80211_bss_age+0x9a/0xc0 [cfg80211]
      [<ffffffffae48d46d>] ? trace_hardirqs_on+0xd/0x10
      [<ffffffffc13fb1c0>] ? wiphy_suspend+0xc70/0xc70 [cfg80211]
      [<ffffffffae84def1>] __asan_report_load8_noabort+0x61/0x70
      [<ffffffffc13fb100>] ? wiphy_suspend+0xbb0/0xc70 [cfg80211]
      [<ffffffffc13fb751>] ? wiphy_resume+0x591/0x5a0 [cfg80211]
      [<ffffffffc13fb751>] wiphy_resume+0x591/0x5a0 [cfg80211]
      [<ffffffffc13fb1c0>] ? wiphy_suspend+0xc70/0xc70 [cfg80211]
      [<ffffffffaf3b206e>] dpm_run_callback+0x6e/0x4f0
      [<ffffffffaf3b31b2>] device_resume+0x1c2/0x670
      [<ffffffffaf3b367d>] async_resume+0x1d/0x50
      [<ffffffffae3ee84e>] async_run_entry_fn+0xfe/0x610
      [<ffffffffae3d0666>] process_one_work+0x716/0x1a50
      [<ffffffffae3d05c9>] ? process_one_work+0x679/0x1a50
      [<ffffffffafdd7b6d>] ? _raw_spin_unlock_irq+0x3d/0x60
      [<ffffffffae3cff50>] ? pwq_dec_nr_in_flight+0x2b0/0x2b0
      [<ffffffffae3d1a80>] worker_thread+0xe0/0x1460
      [<ffffffffae3d19a0>] ? process_one_work+0x1a50/0x1a50
      [<ffffffffae3e54c2>] kthread+0x222/0x2e0
      [<ffffffffae3e52a0>] ? kthread_park+0x80/0x80
      [<ffffffffae3e52a0>] ? kthread_park+0x80/0x80
      [<ffffffffae3e52a0>] ? kthread_park+0x80/0x80
      [<ffffffffafdd86aa>] ret_from_fork+0x2a/0x40
     Object at ffff8803fc244088, in cache kmalloc-1024 size: 1024
     Allocated:
     PID = 71
      save_stack_trace+0x1b/0x20
      save_stack+0x46/0xd0
      kasan_kmalloc+0xad/0xe0
      kasan_slab_alloc+0x12/0x20
      __kmalloc_track_caller+0x134/0x360
      kmemdup+0x20/0x50
      brcmf_cfg80211_attach+0x10b/0x3a90 [brcmfmac]
      brcmf_bus_start+0x19a/0x9a0 [brcmfmac]
      brcmf_pcie_setup+0x1f1a/0x3680 [brcmfmac]
      brcmf_fw_request_nvram_done+0x44c/0x11b0 [brcmfmac]
      request_firmware_work_func+0x135/0x280
      process_one_work+0x716/0x1a50
      worker_thread+0xe0/0x1460
      kthread+0x222/0x2e0
      ret_from_fork+0x2a/0x40
     Freed:
     PID = 2568
      save_stack_trace+0x1b/0x20
      save_stack+0x46/0xd0
      kasan_slab_free+0x71/0xb0
      kfree+0xe8/0x2e0
      brcmf_cfg80211_detach+0x62/0xf0 [brcmfmac]
      brcmf_detach+0x14a/0x2b0 [brcmfmac]
      brcmf_pcie_remove+0x140/0x5d0 [brcmfmac]
      brcmf_pcie_pm_leave_D3+0x198/0x2e0 [brcmfmac]
      pci_pm_resume+0x186/0x220
      dpm_run_callback+0x6e/0x4f0
      device_resume+0x1c2/0x670
      async_resume+0x1d/0x50
      async_run_entry_fn+0xfe/0x610
      process_one_work+0x716/0x1a50
      worker_thread+0xe0/0x1460
      kthread+0x222/0x2e0
      ret_from_fork+0x2a/0x40
     Memory state around the buggy address:
      ffff8803fc243f80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
      ffff8803fc244000: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
     >ffff8803fc244080: fc fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
                              ^
      ffff8803fc244100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
      ffff8803fc244180: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb

    What is happening is that brcmf_pcie_resume() detects a device that
    is no longer responsive and it decides to unbind resulting in a
    wiphy_unregister() and wiphy_free() call. Now the wiphy instance
    remains allocated, because PM needs to call wiphy_resume() for it.
    However, brcmfmac already does a kfree() for the struct
    cfg80211_registered_device::ops field. Change the checks in
    wiphy_resume() to only access the struct cfg80211_registered_device::ops
    if the wiphy instance is still registered at this time.

    Reported-by: Daniel J Blueman <daniel@quora.org>
    Reviewed-by: Hante Meuleman <hante.meuleman@broadcom.com>
    Reviewed-by: Pieter-Paul Giesberts <pieter-paul.giesberts@broadcom.com>
    Reviewed-by: Franky Lin <franky.lin@broadcom.com>
    Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b48b63d5f583f4e66f5efce4951679065b066c8a
Author: Victor Kamensky <kamensky@cisco.com>
Date:   Mon Apr 3 22:51:01 2017 -0700

    arm64: mm: unaligned access by user-land should be received as SIGBUS

    commit 09a6adf53d42ca3088fa3fb41f40b768efc711ed upstream.

    After 52d7523 (arm64: mm: allow the kernel to handle alignment faults on
    user accesses) commit user-land accesses that produce unaligned exceptions
    like in case of aarch32 ldm/stm/ldrd/strd instructions operating on
    unaligned memory received by user-land as SIGSEGV. It is wrong, it should
    be reported as SIGBUS as it was before 52d7523 commit.

    Changed do_bad_area function to take signal and code parameters out of esr
    value using fault_info table, so in case of do_alignment_fault fault
    user-land will receive SIGBUS. Wrapped access to fault_info table into
    esr_to_fault_info function.

    Fixes: 52d7523 (arm64: mm: allow the kernel to handle alignment faults on user accesses)
    Signed-off-by: Victor Kamensky <kamensky@cisco.com>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3d44ecc1206e4485f253da81da9f37da7502503a
Author: Quentin Schulz <quentin.schulz@free-electrons.com>
Date:   Tue Mar 21 16:52:14 2017 +0100

    iio: bmg160: reset chip when probing

    commit 4bdc9029685ac03be50b320b29691766d2326c2b upstream.

    The gyroscope chip might need to be reset to be used.

    Without the chip being reset, the driver stopped at the first
    regmap_read (to get the CHIP_ID) and failed to probe.

    The datasheet of the gyroscope says that a minimum wait of 30ms after
    the reset has to be done.

    This patch has been checked on a BMX055 and the datasheet of the BMG160
    and the BMI055 give the same reset register and bits.

    Signed-off-by: Quentin Schulz <quentin.schulz@free-electrons.com>
    Signed-off-by: Jonathan Cameron <jic23@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2501a0af173437929f17270221da0634410949c3
Author: Shrirang Bagul <shrirang.bagul@canonical.com>
Date:   Thu Mar 30 23:47:21 2017 +0800

    iio: st_pressure: initialize lps22hb bootime

    commit 51f528a1636f352ad776a912ac86026ac7a89a2a upstream.

    This patch initializes the bootime in struct st_sensor_settings for
    lps22hb sensor. Without this, sensor channels read from sysfs always
    report stale values.

    Signed-off-by: Shrirang Bagul <shrirang.bagul@canonical.com>
    Signed-off-by: Jonathan Cameron <jic23@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a16d8c4e8f77468dd280e3ff6d348e471af58787
Author: Nikolaus Schulz <nikolaus.schulz@avionic-design.de>
Date:   Fri Mar 24 13:41:51 2017 +0100

    iio: core: Fix IIO_VAL_FRACTIONAL_LOG2 for negative values

    commit 7fd6592d1287046f61bfd3cda3c03cd35be490f7 upstream.

    Fix formatting of negative values of type IIO_VAL_FRACTIONAL_LOG2 by
    switching from do_div(), which can't handle negative numbers, to
    div_s64_rem().  Also use shift_right for shifting, which is safe with
    negative values.

    Signed-off-by: Nikolaus Schulz <nikolaus.schulz@avionic-design.de>
    Reviewed-by: Lars-Peter Clausen <lars@metafoo.de>
    Signed-off-by: Jonathan Cameron <jic23@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0d50669ca41f6ef2ea2653ededbd49d76cdbb777
Author: Suzuki K Poulose <suzuki.poulose@arm.com>
Date:   Mon Apr 3 15:12:43 2017 +0100

    kvm: arm/arm64: Fix locking for kvm_free_stage2_pgd

    commit 8b3405e345b5a098101b0c31b264c812bba045d9 upstream.

    In kvm_free_stage2_pgd() we don't hold the kvm->mmu_lock while calling
    unmap_stage2_range() on the entire memory range for the guest. This could
    cause problems with other callers (e.g, munmap on a memslot) trying to
    unmap a range. And since we have to unmap the entire Guest memory range
    holding a spinlock, make sure we yield the lock if necessary, after we
    unmap each PUD range.

    Fixes: commit d5d8184d35c9 ("KVM: ARM: Memory virtualization setup")
    Cc: Paolo Bonzini <pbonzin@redhat.com>
    Cc: Marc Zyngier <marc.zyngier@arm.com>
    Cc: Christoffer Dall <christoffer.dall@linaro.org>
    Cc: Mark Rutland <mark.rutland@arm.com>
    Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
    [ Avoid vCPU starvation and lockup detector warnings ]
    Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
    Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
    Signed-off-by: Christoffer Dall <cdall@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e8c3d6542edb49c375572f4d7fe0cdf26cf036e0
Author: Marc Zyngier <marc.zyngier@arm.com>
Date:   Thu Mar 16 18:20:50 2017 +0000

    arm/arm64: KVM: Take mmap_sem in kvm_arch_prepare_memory_region

    commit 72f310481a08db821b614e7b5d00febcc9064b36 upstream.

    We don't hold the mmap_sem while searching for VMAs (via find_vma), in
    kvm_arch_prepare_memory_region, which can end up in expected failures.

    Fixes: commit 8eef91239e57 ("arm/arm64: KVM: map MMIO regions at creation time")
    Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
    Cc: Eric Auger <eric.auger@rehat.com>
    Reviewed-by: Christoffer Dall <cdall@linaro.org>
    [ Handle dirty page logging failure case ]
    Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
    Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fc29073a15e8ecc82d11efb4d561d544eff3df7c
Author: Marc Zyngier <marc.zyngier@arm.com>
Date:   Thu Mar 16 18:20:49 2017 +0000

    arm/arm64: KVM: Take mmap_sem in stage2_unmap_vm

    commit 90f6e150e44a0dc3883110eeb3ab35d1be42b6bb upstream.

    We don't hold the mmap_sem while searching for the VMAs when
    we try to unmap each memslot for a VM. Fix this properly to
    avoid unexpected results.

    Fixes: commit 957db105c997 ("arm/arm64: KVM: Introduce stage2_unmap_vm")
    Reviewed-by: Christoffer Dall <cdall@linaro.org>
    Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
    Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fb3ce7a852134cc09d83a02823d2a276b29612fc
Author: Shuxiao Zhang <zhangshuxiao@xiaomi.com>
Date:   Thu Apr 6 22:30:29 2017 +0800

    staging: android: ashmem: lseek failed due to no FMODE_LSEEK.

    commit 97fbfef6bd597888485b653175fb846c6998b60c upstream.

    vfs_llseek will check whether the file mode has
    FMODE_LSEEK, no return failure. But ashmem can be
    lseek, so add FMODE_LSEEK to ashmem file.

    Comment From Greg Hackmann:
            ashmem_llseek() passes the llseek() call through to the backing
            shmem file.  91360b02ab48 ("ashmem: use vfs_llseek()") changed
            this from directly calling the file's llseek() op into a VFS
            layer call.  This also adds a check for the FMODE_LSEEK bit, so
            without that bit ashmem_llseek() now always fails with -ESPIPE.

    Fixes: 91360b02ab48 ("ashmem: use vfs_llseek()")
    Signed-off-by: Shuxiao Zhang <zhangshuxiao@xiaomi.com>
    Tested-by: Greg Hackmann <ghackmann@google.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 38b4b8a0969d830d189340217894da1cf23dc019
Author: NeilBrown <neilb@suse.com>
Date:   Mon Apr 3 11:30:34 2017 +1000

    sysfs: be careful of error returns from ops->show()

    commit c8a139d001a1aab1ea8734db14b22dac9dd143b6 upstream.

    ops->show() can return a negative error code.
    Commit 65da3484d9be ("sysfs: correctly handle short reads on PREALLOC attrs.")
    (in v4.4) caused this to be stored in an unsigned 'size_t' variable, so errors
    would look like large numbers.
    As a result, if an error is returned, sysfs_kf_read() will return the
    value of 'count', typically 4096.

    Commit 17d0774f8068 ("sysfs: correctly handle read offset on PREALLOC attrs")
    (in v4.8) extended this error to use the unsigned large 'len' as a size for
    memmove().
    Consequently, if ->show returns an error, then the first read() on the
    sysfs file will return 4096 and could return uninitialized memory to
    user-space.
    If the application performs a subsequent read, this will trigger a memmove()
    with extremely large count, and is likely to crash the machine is bizarre ways.

    This bug can currently only be triggered by reading from an md
    sysfs attribute declared with __ATTR_PREALLOC() during the
    brief period between when mddev_put() deletes an mddev from
    the ->all_mddevs list, and when mddev_delayed_delete() - which is
    scheduled on a workqueue - completes.
    Before this, an error won't be returned by the ->show()
    After this, the ->show() won't be called.

    I can reproduce it reliably only by putting delay like
            usleep_range(500000,700000);
    early in mddev_delayed_delete(). Then after creating an
    md device md0 run
      echo clear > /sys/block/md0/md/array_state; cat /sys/block/md0/md/array_state

    The bug can be triggered without the usleep.

    Fixes: 65da3484d9be ("sysfs: correctly handle short reads on PREALLOC attrs.")
    Fixes: 17d0774f8068 ("sysfs: correctly handle read offset on PREALLOC attrs")
    Signed-off-by: NeilBrown <neilb@suse.com>
    Acked-by: Tejun Heo <tj@kernel.org>
    Reported-and-tested-by: Miroslav Benes <mbenes@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a709613559d6df9bc34d1d9283b0169cad1bbb65
Author: Tomasz Nowicki <tn@semihalf.com>
Date:   Fri Mar 31 17:06:44 2017 +0200

    PCI: thunder-pem: Fix legacy firmware PEM-specific resources

    commit feb199ebef488a9f2c3550fb10524f3dac9d8abe upstream.

    SZ_16M PEM resource size includes PEM-specific register and its children
    resources. Reservation of the whole SZ_16M range leads to child device
    driver failure when pcieport driver is requesting resources:

      pcieport 0004:1f:00.0: can't enable device: BAR 0 [mem 0x87e0c0f00000-0x87e0c0ffffff 64bit] not claimed

    So we cannot reserve full 16M here and instead we want to reserve
    PEM-specific register only which is SZ_64K.

    At the end increase PEM resource to SZ_16M since this is what
    thunder_pem_init() call expects for proper initialization.

    Fixes: 9abb27c7594a ("PCI: thunder-pem: Add legacy firmware support for Cavium ThunderX host controller")
    Signed-off-by: Tomasz Nowicki <tn@semihalf.com>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f8709a9ec8ae83a8322c526bd6965f58ae1a4c79
Author: Tomasz Nowicki <tn@semihalf.com>
Date:   Thu Mar 23 17:10:16 2017 -0500

    PCI: thunder-pem: Add legacy firmware support for Cavium ThunderX host controller

    commit 9abb27c7594a62bbf6385e20b7f5a90b4eceae2f upstream.

    During early days of PCI quirks support, ThunderX firmware did not provide
    PNP0c02 node with PCI configuration space and PEM-specific register ranges.
    This means that for legacy FW we are not reserving these resources and
    cannot gather PEM-specific resources for further PEM initialization.

    To support already deployed legacy FW, calculate PEM-specific ranges and
    provide resources reservation as fallback scenario into PEM driver when we
    could not gather PEM reg base from ACPI tables.

    Tested-by: Robert Richter <rrichter@cavium.com>
    Signed-off-by: Tomasz Nowicki <tn@semihalf.com>
    Signed-off-by: Vadim Lomovtsev <Vadim.Lomovtsev@caviumnetworks.com>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Acked-by: Robert Richter <rrichter@cavium.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 44eed6f024913d16004ce290d986dc59f4408c06
Author: Li Qiang <liq3ea@gmail.com>
Date:   Mon Mar 27 20:10:53 2017 -0700

    drm/vmwgfx: fix integer overflow in vmw_surface_define_ioctl()

    commit e7e11f99564222d82f0ce84bd521e57d78a6b678 upstream.

    In vmw_surface_define_ioctl(), the 'num_sizes' is the sum of the
    'req->mip_levels' array. This array can be assigned any value from
    the user space. As both the 'num_sizes' and the array is uint32_t,
    it is easy to make 'num_sizes' overflow. The later 'mip_levels' is
    used as the loop count. This can lead an oob write. Add the check of
    'req->mip_levels' to avoid this.

    Signed-off-by: Li Qiang <liqiang6-s@360.cn>
    Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a2d474ab560cae11b3d297471b32100a5a602d2a
Author: Thomas Hellstrom <thellstrom@vmware.com>
Date:   Mon Mar 27 13:06:05 2017 +0200

    drm/vmwgfx: Remove getparam error message

    commit 53e16798b0864464c5444a204e1bb93ae246c429 upstream.

    The mesa winsys sometimes uses unimplemented parameter requests to
    check for features. Remove the error message to avoid bloating the
    kernel log.

    Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
    Reviewed-by: Brian Paul <brianp@vmware.com>
    Reviewed-by: Sinclair Yeh <syeh@vmware.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 009eb75f7fb0fac9f2e896b6c70662a546a9c8d7
Author: Thomas Hellstrom <thellstrom@vmware.com>
Date:   Mon Mar 27 11:21:25 2017 +0200

    drm/ttm, drm/vmwgfx: Relax permission checking when opening surfaces

    commit fe25deb7737ce6c0879ccf79c99fa1221d428bf2 upstream.

    Previously, when a surface was opened using a legacy (non prime) handle,
    it was verified to have been created by a client in the same master realm.
    Relax this so that opening is also allowed recursively if the client
    already has the surface open.

    This works around a regression in svga mesa where opening of a shared
    surface is used recursively to obtain surface information.

    Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
    Reviewed-by: Sinclair Yeh <syeh@vmware.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7a392c9a45636d8740d8fcb40ac9d6c7ec950bbe
Author: Murray McAllister <murray.mcallister@insomniasec.com>
Date:   Mon Mar 27 11:15:12 2017 +0200

    drm/vmwgfx: avoid calling vzalloc with a 0 size in vmw_get_cap_3d_ioctl()

    commit 63774069d9527a1aeaa4aa20e929ef5e8e9ecc38 upstream.

    In vmw_get_cap_3d_ioctl(), a user can supply 0 for a size that is
    used in vzalloc(). This eventually calls dump_stack() (in warn_alloc()),
    which can leak useful addresses to dmesg.

    Add check to avoid a size of 0.

    Signed-off-by: Murray McAllister <murray.mcallister@insomniasec.com>
    Reviewed-by: Sinclair Yeh <syeh@vmware.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0570c0cd987f7ef0895c46cc715a66c6fe3984b3
Author: Murray McAllister <murray.mcallister@insomniasec.com>
Date:   Mon Mar 27 11:12:53 2017 +0200

    drm/vmwgfx: NULL pointer dereference in vmw_surface_define_ioctl()

    commit 36274ab8c596f1240c606bb514da329add2a1bcd upstream.

    Before memory allocations vmw_surface_define_ioctl() checks the
    upper-bounds of a user-supplied size, but does not check if the
    supplied size is 0.

    Add check to avoid NULL pointer dereferences.

    Signed-off-by: Murray McAllister <murray.mcallister@insomniasec.com>
    Reviewed-by: Sinclair Yeh <syeh@vmware.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3622a033c41936bf8fbcca4faa7ffa75bb773158
Author: Thomas Hellstrom <thellstrom@vmware.com>
Date:   Mon Mar 27 11:09:08 2017 +0200

    drm/vmwgfx: Type-check lookups of fence objects

    commit f7652afa8eadb416b23eb57dec6f158529942041 upstream.

    A malicious caller could otherwise hand over handles to other objects
    causing all sorts of interesting problems.

    Testing done: Ran a Fedora 25 desktop using both Xorg and
    gnome-shell/Wayland.

    Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
    Reviewed-by: Sinclair Yeh <syeh@vmware.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

özgürpenguen · 15 Nisan 2017 - 02:48:21

Merhabalar ortalama bir kullanıcı olarak ne zaman geçmem uygun olur mesela gtk temaları, ikonları vs. uygulayabilmek için unity8 için bir tweak programı ne zaman gelişir veya gerek kalır mı? Geçmek için yedeklememi neye göre yapmalıyım çünkü teker teker aynı şeyleri kurmak istemiyorum malum AKK. Veya gerek yok unity'ye gnome kullan şu şu yüzden diyen var mıdır?

lubuntu · 15 Nisan 2017 - 09:53:54

[mention=622963]@özgürpenguen[/mention]Unity 8 bitti artık geliştirilmeyecek onun yerine Gnome masaüstünü geliştirmeye odaklanacaklar. İster şimdi Ubuntu Gnome kullanın isterseniz 18.04 lts sürümünü bekleyin. Şu an sorunsuz kullanıyorsanız mevcut sistemi, bozmayın devam edin.

turkerataturk · 15 Nisan 2017 - 11:29:37

17.04 Beğendim, biraz hızlanmış, bazı hatalar düzenlenmiş gördüm.

Şu Ubuntu Software 'ın düzelmesi 20.04 ü bulacak sanırım

dolor · 15 Nisan 2017 - 11:30:06

16.04 güncellesek sorun olur mu ?

turkerataturk · 15 Nisan 2017 - 11:32:31

[mention=622979]@dolor[/mention]

Temiz kurulum her zaman iyidir.

lubuntu · 15 Nisan 2017 - 12:40:19

[mention=622978]@mustangank[/mention]appgrid uygulamasını örnek alsalar çok daha iyi olacak.

turkerataturk · 15 Nisan 2017 - 13:42:15

[mention=622986]@lubuntu[/mention]

Aynen,
Çok gerekli önemli yazılımları neden kullanmazlar neden kararlı yapmazlar hep merak etmişimdir. Örneğin Ubuntu da Ekran parlaklığı için kısa erişim yok en sinir olduğum şey.
Her kurulumdan sonra bellek biçimlendirme, ekran parlaklığı, java vs vs kuruyoruz.
Arkadaş koy üst Bar bölümüne ekran parlaklığı rahatca kullanalım.
Bu konuda Mint çok iyi.

edge35 · 16 Nisan 2017 - 03:42:56

Baştan kurmak yerine direk güncelleme şeklinde yükseltebiliyor muyuz?

burak öztürk · 16 Nisan 2017 - 13:28:27

Alıntı yapılan: edge35 - 16 Nisan 2017 - 03:42:56
Baştan kurmak yerine direk güncelleme şeklinde yükseltebiliyor muyuz?

Evet güncelleme ile yükseltilebiliyor ama temiz kurulum daha sağlam daha sorunsuz oluyor.

edge35 · 16 Nisan 2017 - 13:34:35

[mention=623055]@burak öztürk[/mention] teşekkür ederim. Peki temiz kurulum yapmadan önce nasıl bir yedekleme yolu izleyebilirim? Otomatik yedekleme yapabileceğim bir şey var mı yoksa elle dosyalarımı yedekleyip uygulamalarıda tekrar mı yüklemem gerekiyor? Bir de şu an yeni çıktığı için sıkıntıları var mıdır, biraz beklemek daha mı mantıklı olur?

burak öztürk · 16 Nisan 2017 - 13:51:06

Alıntı yapılan: edge35 - 16 Nisan 2017 - 13:34:35
[mention=623055]@burak öztürk[/mention] teşekkür ederim. Peki temiz kurulum yapmadan önce nasıl bir yedekleme yolu izleyebilirim? Otomatik yedekleme yapabileceğim bir şey var mı yoksa elle dosyalarımı yedekleyip uygulamalarıda tekrar mı yüklemem gerekiyor? Bir de şu an yeni çıktığı için sıkıntıları var mıdır, biraz beklemek daha mı mantıklı olur?

Hepsinden önce eğer 16.04 kullanıyorsanız va sıkıntı yoksa sistemi değiştirmenize gerek yok.
Evet kişisel dosyalarınızı alın. Sistemi kurunca uygulamalarınızı kurarsınız.
İki farklı bilgisayarda çıktığından bu yana kullanıyorum ve ciddi bir sorun ile karşılaşmadım. Sadece şununla karşılaştım https://forum.ubuntu-tr.net/index.php?topic=56091.0. Ama farklı bir bilgisayarda nasıl tepki verir denemek lazım. Dediğim gibi ciddi bir sorun yok. Uygulamalarım güncel olsun derseniz kurabilirsiniz.

edge35 · 16 Nisan 2017 - 14:08:10

Alıntı yapılan: burak öztürk - 16 Nisan 2017 - 13:51:06
Hepsinden önce eğer 16.04 kullanıyorsanız va sıkıntı yoksa sistemi değiştirmenize gerek yok.
Evet kişisel dosyalarınızı alın. Sistemi kurunca uygulamalarınızı kurarsınız.
İki farklı bilgisayarda çıktığından bu yana kullanıyorum ve ciddi bir sorun ile karşılaşmadım. Sadece şununla karşılaştım https://forum.ubuntu-tr.net/index.php?topic=56091.0. Ama farklı bir bilgisayarda nasıl tepki verir denemek lazım. Dediğim gibi ciddi bir sorun yok. Uygulamalarım güncel olsun derseniz kurabilirsiniz.

Açıkçası pek oyun oynayan biri değilim, arada sırada çok büyük olmayan bir kaç oyun oynuyorum sadece. Windows 10 kullanırken bir oyun dışında hiç bir zaman sesli bir şekilde fan çalışmamıştı, ısınma gerçekleşmemişti. Fakat ubuntuya geçince fan çalışmaya başladı. 17.04'e o yüzden geçmek istedim, bir iki yerde bu düzeltilmiş diye okudum. Kullandığınıza göre bu konuda bir şey farkettiniz mi acaba? Eğer hala aynısıysa geçmeme pek de gerek yok.

burak öztürk · 16 Nisan 2017 - 15:00:43

Bu ısınma sorunu optimus grafik kartlarında oluyor genelde -bende olmadığı için karşılaşmadım ama forumlardan takip edip gördüğüm bu.- sizde de o sebeple ısınma oluyor olabilir.
Açıkcası zesty nin sıcaklık değerlerinde çok olmasada, evet düşüş yaşadım.

şenol · 16 Nisan 2017 - 17:16:53

temiz sıfırdan 17.04 gnome 3 ( GNOME 3 ) YAPIN MASAÜSTÜNÜ !!!! bios dan uefi olaraktan gösterin uefi kursun ubuntuyu ! kurarken diski sil ve ubuntu yükle değin ! swap alanı açsın otomatik kurulum yapsın . hiçbirşeyi ellemeyin . EĞER ELLE KURARSANIZ SWAP ALANI VS GİBİ AYIRIRSANIZ DİSKİ . KURULUMDA İLERDE ( GRUB 2 ) YÜKLEMESİNDE HATA ALIRSINIZ !!! ve yüklenmez ubuntu . uefi kurulum yaptığınız için !!! ( diski sil ve ubuntu yükle değin o kadar ) steami indirin oyunları yükleyin bakın keyfinize

saygılar

Ubuntu Türkiye

Haberler:

Ubuntu 17.04 yayınlandı.

burak öztürk

Bigchefstarys

lubuntu

Bigchefstarys

lubuntu

burak öztürk

lubuntu

Bipolar_Disorder

özgürpenguen

lubuntu

turkerataturk

dolor

turkerataturk

lubuntu

turkerataturk

edge35

burak öztürk

edge35

burak öztürk

edge35

burak öztürk

şenol